Has this skipped a human editor? Or, perhaps this formatting was intentional….

I’m ready to learn JavaScript again.

The last time I seriously developed anything using it was 1997, creating drag-and-drop games. It was a time when very little was standardized across browsers or HTML implementations. Anyone reading this who attempted to develop drag-and-drop in the web browser 11 years ago can empathize with the intense effort to debug and make the functions cross browser compatible.

Some years later, as web browser software progressed, the games no longer functioned; optimizing to use Netscape 4 is not advantageous when Netscape 4 becomes obsolete. As JavaScript progressed, I turned a blind eye and concentrated on server side technologies that were more stable and controllable.

Today, in 2008, nothing would work if you turned off your JavaScript. Users are not put off by a web site that requires JavaScript to function. Many developers don’t care if JavaScript is turned off either because, well, they keep JavaScript enabled while they build. There will undoubtedly be a growing wave of software vulnerabilities and inconsistencies because web based software was dependent on its JavaScript client-side environment. That’s a whole ‘nother topic.

Why should I learn JavaScript now? Browser compatibility and tools now available to developers is impressive. In comparison to the old days, JavaScript not breaking and actually working is enough to impress me. AJAX is the “killer app” for JavaScript, and is the basis for the web browser becoming the new de facto software platform. But I also like the visual effects that can be achieved without using Flash and ActiveX. Provided JavaScript does not disrupt the stability, security and accessibility of a web page, it is worth the effort to enhance the experience of using web applications.

Sometimes the biggest step is just to get started. If you have trouble getting something started, try to do the absolute smallest step that gets you in the right direction. Lao-tzu was right, “A journey of a thousand miles begins with a single step”. In taking the first step, it makes the second easier than if you had not begun.

The thought of opening Microsoft Word gives me feelings of trepidation, no doubt a result of countless battles with text styles, tab indents, and under a tight deadline. In fact, I’m not yet comfortable with the Wordpress blog interface for starting a blog post; the draft of this post was typed in TextPad.

Everything can begin with a text file. It is counterproductive to the formation and notation of a new idea than to be annoyed everytime to type a new paragraph, the font type changes, or the software decides that typing a hyphen is a reason to insert a bulleted list automatically. Write first, format later.

Many successful software programs rely on simple text files for their settings and configuration, including all the components used in LAMP architecture. Sometimes, the complexity you require will not exceed a simple text file.

dirification (noun) or to dirify (verb).

A relatively new and generally unknown word (there’s really no definition I can find), but credit goes to the developer community of the Movable Type blog software for bringing it to my attention. In its original use, it describes the conversion of space characters to either hyphens or underscores. It could have a more general meaning.

I suspect the creator of this word has either forgotten the words “derivation” (noun), “to derive” (verb), or perhaps found them inadequate to describe the process of character conversions. Add this to the list of words representing and erosion or evolution of the english language. How long will it be before the Oxford dictionary, or wikitionary, legitimizes its use?

The irony is not lost on me: it is not free to read the article about paying for free downloads.

Most of the processes in software development, in this specific case for a web application, happen in logical steps. Step one comes first, then step two, etc. - many situations are commonly so predictable. The end result is this logic is expressed in a programming language. More important for the developer, who must plan or write that code, is to decide what steps should occur and what decisions should be made to choose the correct steps.

Take the following example. A web interface depends on a database row existing for each day. If you didn’t create new rows for every day into eternity (arguably a less elegant solution), when the clock strikes midnight your flow cart looks like this:

If you think in flowcharts, and anticipate this gap in your earlier logic, you may imagine a flowchart like this:

I’d be surprised of an ORM will do all this thinking for you automatically. It’s the developer’s job to think of these situations to make more stable software. Personally, I don’t actually see a picture of a flow chart in my mind such as the above, but some synapses in my brain connect in some analytical way to just “know” this flowchart.

One caveat: Rarely you may be using threads in which your flowchart may be a little more complex - where step two might be attempted before step one - but a flowchart could probably solve that situation as well.

A post to get this blog underway. If you notice any theme problems, please leave a comment. It will be refined over the coming days, as I also compose some real content.