Is "preparing" a part of "doing"?

Well I've had a lot of extra time on my hands recently, and I've successfully procrastinated with about every task at hand. It's truly amazing how little you can get done, when you're petrified.

I've begun recoding Slick, using Java-style package names and a centralized namespace. (I got the idea from the fellas working on the dojo toolkit.) The process has caused me to extract the majority (and eventually all) of the nested functions and anonymous objects within my code, into object-definitions and prototype/method functions under a single tree.

The good news is that I'm working on it. The bad news, is that it's difficult work. Overall, this is the best practice to coding that I have ever taken on, and it will greatly support adoption, modification and documentation of the Slick system.

Instead of blathering on about my progress, and non-progress, my next few posts will focus on planning, tools, and workflow.

Using an under-disciplined language like JavaScript, as an amateur programmer, I've been at a lost as to good coding practices and tools. Sure, I've got my trusty text-editor (BBEdit!), and dabbled with version control (RCS - for individual use), but beyond that it's a toss-up with managing workflow, vision, scope, specifications and documentation.

That and more, next time - when I have the time!

Hard at work

Well I've had a lot of extra time on my hands recently, and I've successfully procrastinated with about every task at hand. It's truly amazing how little you can get done, when you're petrified.

I've begun recoding Slick, using Java-style package names and a centralized namespace. (I got the idea from the fellas working on the dojo toolkit.) The process has caused me to extract the majority (and eventually all) of the nested functions and anonymous objects within my code, into object-definitions and prototype/method functions under a single tree.

The good news is that I'm working on it. The bad news, is that it's difficult work. Overall, this is the best practice to coding that I have ever taken on, and it will greatly support adoption, modification and documentation of the Slick system.

Instead of blathering on about my progress, and non-progress, my next few posts will focus on planning, tools, and workflow.

Using an under-disciplined language like JavaScript, as an amateur programmer, I've been at a lost as to good coding practices and tools. Sure, I've got my trusty text-editor (BBEdit!), and dabbled with version control (RCS - for individual use), but beyond that it's a toss-up with managing workflow, vision, scope, specifications and documentation.

That and more, next time - when I have the time!

The tide of refactoring

I tried, but couldn't resist...Despite being incomplete, I'm refactoring Slick into a formal framework. The difference is small on the surface, but significantly impacts Slick's internals.

Basically, where I now define functions with

function S_initialize () {...}

I will now define them in a psuedo-class structure, like so

slick.core.initialize= function () {...}

JavaScript has been able to do this since day 1. It may simply be the evolution of good JavaScript practices, but I saw this in the dojo toolkit and decided it was the best way to implement Slick.

Using a centralized object model uses a smaller namespace footprint, contextualizes the relationship between objects and better encapsulation. More so, it should make it easier for developers to understand the system, and encourage improvements.

I'll share more, on how dojo's amazing toolkit has inspired me to complete Slick. Slick 1.5 (or 2.0) will eventually use dojo to manage it's event wiring functionality.

The code or document dance

Documentation has been a challenge for me. With no professional training, it's a wonder why I'm bent on looking professional. I've struggled with site structures (for the site that would eventually host the Slick library), tutorials, overviews, marketing statements - for OpenSource no doubt! How do I share this so people fully understand what it does. Speak vision? Speak functionality? Speak features? Speak benefits? Develop demonstrations that speak for themselves?

Whatever my initial approach for describing what this thing does and how it works, I usually digress into technical details or opine Slick's features and benefits. It's hard for me to communicate one thing, when I haven't said all the rest first (again, the vicious circle and then you're 30). Single sentences become whole paragraphs, and paragraphs become pages.

Nevertheless, seeing how Slick is still incomplete (I haven't touched the code in months), I've decided to dust off the old girl and write some routines this weekend. Not to say this entire puppy will be done soon, but I'd rather advance it's functionality than promote it's form.

I'll share my pitfalls in coding a large library like Slick another time. Plenty more to come!

It's about time

Well, folks - this is either my unveiling or undoing. Who am I? Just someone who's never been able to execute on his big ideas. Well I've got a few, and I'd like to make a difference... We'll start with JavaScript.

This blog is here to promote interest and development of one particular JavaScript effort, the Slick library. Slick began with a need for a lowest-common-denominator system for form validation. That turned out to be insuffecient, since most developers (like myself) want so much more than a boolean result from our form validation routines.

It's taken me three years to develop the library. No, it's not done yet, and no, I wasn't working on it for three years straight! The concept has refined itself naturally. Just this week, as I tackled documentation (again), I fell upon the term "forms processing" - don't know if I saw it anywhere before, but it's doesn't strike of a sensational buzzword anyway. Nevertheless, the concept of forms processing, along with a soon-to-be-revealed logo (finally), have injected a new zest for completing this bohemoth.

Recent excitement in the JavaScript world, specifically advancements in the "Web 2.0" domain have helped to clarify what I've been working towards. Along with my renewed interest in my work, along with the acceptance of high-level, robust, libraries, I've been encouraged that this is the right time to share my work.

That's been the hardest part. Candidly, as someone who's never completed any good idea, it's always hard to let one go before I think it ready - hence, the vicious circle, and then you're 30. Well, I'm human, and I hope you'll forgive the delay. With love in my life (we'll talk about that later), perhaps I have a renewed confidence to tackle projects I'd long since deserted.

Hope you enjoy this journey... I promise not to write so much in the future! I hope everyone who decides to contribute, has the intention of forwarding the conversation to bigger, better, and quality JavaScript. Remember, it's just a starting point. I am not my JavaScript!