As some others have mentioned, it’s that time of year where most people with blogs make their public announcements on what languages they’ll be concentrating on for the upcoming year. Last year I think my top focus was Ruby on Rails and Javascript; so safe to say I’ve gotten a little experience in those. Things have taken a bit of a turn though, and I’m going to switch things up for 2009 and concentrate a little on my weaknesses and a little on new growth.

Weaknesses? Yeah, everyone has them. Those areas where when you have to implement something you bite your lip and find a way to get through it — usually with a 10ft poll. If they’re something that ties into your daily routine in some way, this is kind of task that can be holding you back from potentially getting more work done, or higher quality work.

One of my weaknesses has always been testing. Maybe I’ve been surrounded by too many testers, but its definitely something I could improve on. I wouldn’t consider myself fully proficient in a language to the point where I’d feel confident teaching someone else until I was proficient testing in it. Some languages don’t make this easy of course. Testing Javascript isn’t the most common thing, but it’s important, especially with such a Javascript heavy application as CloudShout. There are some great new tools like FireUnit for testing in Javascript too. Testing in Python, especially within Django has to have great support — as long as you actually do it. With Rails there’s a million different ways to test; but I’d like to concentrate mostly on mochs and stubs for a swiftly running test suite. No point in having a test suite that takes so long to run that no one has the time to run it after all.

There are a few other topics of interest for the new year. Things I’d love to look into and play around with at least a least a little. XMPP and especially bosh look extreme interesting to me, and I look forward to cramming together the little I’ve learned so far into an Adogo presentation in a little over a week.

Collective intelligence looks like another interesting topic that I’ve always wanted to dig a little deeper into. The Netflix prize looks an great way to experiment a little with it in some different language — Python, C and Erlang seem to be the most commonly used for it. There’s at least one active Rails plugin for collective intelligence, acts_as_recommendable, that uses a C implementation for the heavy lifting and might be worth checking out as well.

Last year git took over in a lot of programming world thanks to an amazing killer app, Github. Getting familiar with git isn’t a big thing, but it’s worth it to have a little more shared language with your peers. Moving from CVS to Subversion wasn’t something that most people did overnight, but after the switch no one ever went back. Git is shaping up to be same, but has a long road of public support and client side tools ahead of it before it makes it that far. People that like git, really really like git. I’m ashamed to say I’ve made improvements to a few projects I’ve cloned from Github, but never got around to branching and committing my changes (or writing tests for my changes of course). This is something I’d love to get better at — more for fun and familiarity with git than anything else. That’s the goal for this year — work on projects that are fun!

The recent discussion of Form Validation – How do you do it?, had me wondering just what might be involved in creating an easy to use validation framework. It’s a task that might seem easy, but when you get down to all the special cases it’s anything but. ColdFusion is a language designed around rapid development, so why not attempt to create a Validation framework modeled around the idea that new rules can be added easily? Ok, that’s probably the case with any such framework, but it should be easy for a dynamic here. Today I’m mostly just brainstorming what I’d want and possible implementations. Over the next few days I’ll try to implement this.

So what should it be able to do? Well, Jeff’s post stated some very important requirements that I’d say are all must haves. To reiterate some of the points though, it should be able to validate entire business objects (cfcs with getters/setters OR named structs), it should be able to have a “strict” mode where it validates everything or a mode where only set fields are validated. It should be able to validate forms via ajax (funcational validation), as well as single fields via ajax. It should also be able to validate from the client side and return error messages (json/html) or validate on the server side and get back some sort of error collection.

We want this to be as easy to use as possible, so the validation rules should only exist in a single place. The ajax features should also automatically call the associated validation rules. One of the difficulties with ajax is always that it requires twice the work by definition, but what if by some convention both Javascript and validation could be written for us? Here’s what I’m talking about.

<form id="register" validate="onsubmit" message="before">
   <div class="group" id="required">
      <span id="register-first_name-field">
         <label for="register-first_name">First Name</label>
         <input type="text" id="register-first_name" name="user[first_name]" />
      </span>
      <span id="register-username-field">
         <label for="register-username">Username</label>
         <input type="text" id="register-username" validate="onkeyup" name="user[username]" />
      </span>
      <span id="register-email-field">
         <label for="register-email">Email</label>
         <input type="text" id="register-email" validate="onchange" name="user[email]" />
      </span>
   </div>
   <span>
      <input type="submit"/>
   </span>
</form>

This basic form would be the basis for how the front end would work. Based on the metadata we’re marking up on the form (namely those “validate” attributes). The idea is that a form has basic validation rules associated with it — when to validate it and where to put the return values. Each field in the form would then inherit the validation rules defined in the form, but could also overwrite them. For instance, this form would validate everything on submit by default, and place and error messages “before” the field they’re for. Other options might include “after”, “top” or “bottom” for the very top of the form, or “above” and “below” for errors to be put at the top of the current grouping. The HTML will require some kind of hooks for where to place these messages of course, which is where some the convention markup comes into place. The before/after messages would look for the formid-fieldid-field element and place it in an element before that. Top/Bottom would look for the formid and place based on that, and the grouping option would look for an element with the class of group that’s a parent element.

Now how would this know where to submit to for validation? That’s another easy convention to handle. Let say there’s three possible things that can be validated via ajax on a form — an entire form, a single object from a form or a single field from a form. Creating URLs for these to submit to might end up with something like this:

http://localhost/validate (validate.index)
http://localhost/validate/object (validate.object?object=objName)
http://localhost/validate/object/field (validate.field?object=objName&field=fieldName)

Using Coldcourse you could create these without much trouble, and the javascript could discover the validation URL to use based on the form field names. The fields are named in the form object[field] which is a Ruby on Rails/ColdFusion on Wheels convention. On the server side these are converted to structures before we ever have to start working with them. This validate controller would then call up some sort of ValidationService where the real meat of the work happens. The controller then knows to return the errors it gets back to the javascript handler based on some sort of Javascript view template.

This is just brainstorming at this point, but looks easy enough to implement. If there’s anything I’m overlooking, or any suggestions with this so far feel free to comment.

Tomorrow: start planning the service layer!

Recently, I stumbled across a very unexpected book at a trek to Barnes and Noble: Prototype and Scriptaculous in Action. Being a long time Prototype user and reader of Justin Palmer I was surprised there wasn’t more press on this one. Not to be outdone though, the Pragmatic Programmers series announced the new book Prototype and script.aculo.us – You never knew JavaScript could do this! beta book to be available. If you’re not familiar with beta books, the idea is basically that you can download the unfinished pdf right now, as well as updates along the way before eventually getting the pdf of the final version. For a little more you can have the finished book shipped to you as well. I did this for an earlier book by the Pragmatic Programmers and was impressed with how it worked, and the lack of problems I ran into.

If you search Amazon for Javascript books, you’re going to have a hard time getting started. There are a few that stand out that I’ve been wanting to read though including Pro JavaScript Techniques by John Resig (the creator of jQuery), ppk on JavaScript, 1/e by the guy who runs Quirksmode.org and the bestselling Ajax in Action. The problem with learning “Ajax” most people run into though is that it’s so abstracted by your Javascript framework of choice that very little of what you script is actual Ajax. For that reason these three and the Prototype ones above (which although I haven’t read cover to cover, I’ve probably skimmed through half of while at the bookstore) look like great ones for someone looking to further their JS skills.