I should have gone to Art and Code this year.

ART && CODE Symposium: Hackety Hack, why the lucky stiff from STUDIO for Creative Inquiry on Vimeo.

This is a talk by a certain lucky fellow at the CMU Art and Code Jamboree. Looks like fun.

Cleaning up after the great JavaScript Framework Explosion of 2006

For the past 3 years every web application I have worked on has used a JavaScript (JS) framework. Usually it is one of these guys:

• jQuery;
• Dojo;
• Prototype;

All of these guys are really good guys to know; especially if you find yourself in a dark alley being threatened by a mob of project managers wielding GWT manuals. These guys will save your bacon. I would go so far as to say that in this era of Ajaxified interfaces you really can't do without knowing one of these guys. You would be totally lost. Nowhere. If you don't know one of these guys then I pity you just like I pity the descendants of the lost tribe that never discovered fire and thus do all their cooking with friction. Nothing is more pitiful or unappetizing than a hamburger and fries that were cooked by rubbing them against a rock for 8 hours.

These libraries extend the JS language, make data exchange with the server more flexible, give you enhanced widgets and let you create effects on the page. Great! But should we really be doing all these things in JS? It seems like widgets and effects are more in line with what HTML and CSS are responsible for, not JS.

I hadn't really thought about this until today when I was reading about some of the new stuff in CSS3 (my favorites are the new selectors, transitions and animations). This is pretty exciting stuff that will really clean up alot of ugly things you end up doing in your JS code. For example, the Wolfire blog has a great, nontrivial sample of the sort of custom widgets that you can achieve with CSS3 animations and transitions. (see the animated gif, but please, do yourself a favor and go to the wolfire link above so you get the full context). This is a custom widget that is just pure CSS. You only use JS for activating state changes and sending data. You know, JS for behavior, CSS for appearance. Perfect.

It looks like CSS3 is going to put in order all the things that were dislodged by the "Great JavaScript Framework Explosion" of 2006. Of course I still want my JS frameworks, but let them help me with event handling, data transfer and writing concise, testable, maintainable JS code. Leave the appearance of my page for CSS to describe.

Meta Programming with a Barf Bag

Day one of the Open Source Bridge conference was action packed. I'll probably have to write a few posts, but I'm going to start things out with notes on my favorite talk of the day "Spindle, Mutilate and Metaprogram: How far can you push it before there be dragons?" by Markus Roberts and Matt Youell. Yes the picture is them wearing colanders on their heads.

This talk was 2 hours long so it is hard to cover it in all its glory. The crux is that programmers are generally very inhibited by the orthodoxy of each particular language community to the detriment of the code they are writing. Done properly, applying the magic of meta programming simplifies problems and makes code more understandable. Markus especially seemed to wipe his boots on some of the taboos. They mentioned ActiveRecord and jQuery as examples of effective meta magic.

The talk began with a gameshow where 3 volunteers were shown code snippets and the first person who could identify what language it was got a point. The first program looked like C but was in fact Ruby. Another looked like assembly language but was Perl, they even threw some Cobol in there, but it turns out it really was Cobol. :) Each time after they revealed what the real programming language was they showed the code that allowed them to mimic the other languages. It was really a cool way to start a presentation about meta programming.

At one point they showed some C that had been made to look like another language (I don't remember which). Somebody from the audience pointed out a memory leak. Markus responded by pointing out a table in the back where they had barf bags laid out and recommended he get one because there was going to be some spectacularly intolerable displays of metaprogramming. There was lots to learn about how you can shape your own destiny in a programming language if you are willing to amp up your level of meta skulduggery. Tomorrow when I see Markus and Matt again I'll ask about their slide deck, because it would be fun to share some of their code examples.

To ORM or Not to ORM.

Sara Taraporella recently added this very interesting post to her blog. In this post she argues for a separation between domain models and ORM models. There is a pretty lively discussion in the comments that I found useful.

For me it is situational and so for the most part I think being somewhere between these extremes is nice. Something that keeps me from having to do lots and lots of transformations but also keeps me from having to touch too many files when something changes. Active Record is the poster child for combining ORM with the domain, and in the situation where you have complete control to define and change your DB it is great, though I think it comes at the cost of testability. In the comments Clinton Begin describes a situation where other applications need to consume the same DB and require changes. In this case or in the case of a legacy DB you might find yourself gravitating towards the opposite end of the spectrum, which is what Sara is advocating. Complete separation of these concerns.

I recently attended a talk by Drew Olson at the Chicago ruby user group about Data Mapper (among other things). Data Mapper is definitely a step away from the the purity of active record. With active record your DB schema describes your domain model and so you stay DRY. Data mapper says you need an explicit mapping. This buys you flexibility at the cost of being explicit and potentially redundant in describing the relationship between the domain and the database.

I see Active Record as one extreme and Sara's perspective as the opposite. Datamapper is a step towards the middle, and with the changes in Rails 3 the door will be open for people to use data mapper instead of active record. So it appears that Rails is mellowing in its old age, going for a less extreme worldview. Or maybe the world has moved towards rails' view of the world. In the end a little of both are a good thing, I think.

JMX is my favorite rapper!

JMX rules! Some of his best songs: Where the Enterprise at, Xml Gon Give it to 'Ya, Ruff Ryders MBean Anthem, Can't Stop Being Greedy.

The biggie commerce (big e-commerce) project I've been working on is now dev complete and we are working on some production readiness tasks. My job today was instrumenting the most important pages of the application with JMX so we can get statistics on requests/sec, responses/sec, and successes and failures on a per page basis. Word.

I'm new to JMX and it took me some time to get it working in Jetty and Tomcat with Spring. Here are a few of the snags I ran into and what I was doing wrong.

1. Getting Jetty's MBean server to start when we are using the builtin jetty Ant task. There isn't lots of documentation out there about getting Jetty and JMX working when you are starting Jetty via the builtin Ant task. Here is what I did. I added the jettyXml attribute to the jetty tag like this:

   <jetty ... jettyXml="web/target/main/webapp/WEB-INF/jetty.xml"> ... </jetty>

   My jetty.xml file contains the following:
   

   <Configure id="Server" class="org.mortbay.jetty.Server">
   
    <Call id="MBeanServer"
       class="java.lang.management.ManagementFactory"
       name="getPlatformMBeanServer"/>
   
    <Get id="Container" name="container">
     <Call name="addEventListener">
      <Arg>
       <New class="org.mortbay.management.MBeanContainer">
        <Arg>
         <Ref id="MBeanServer"/>
        </Arg>
        <Call name="start"/>
       </New>
      </Arg>
     </Call>
    </Get>
   
   </Configure>

   
   The jetty.xml tells Jetty to start an MBean Server and adding the jettyXml attribute will let Jetty know where to find the jetty.xml file. It seems obvious, but I had to really scour the web to figure that one out. The tricky 'ah-ha' bit is the fact that you can define your jmx stuff in jetty.xml rather than in jetty-jmx.xml, because of course the jetty ant task doesn't have an attribute for jetty-jmx


2. Spring was silently ignoring my JMX annotations, thus none of my MBeans were being exposed. This took me hours to figure out. Here is the explanation I found buried in the spring JMX docs.

   Do not use interface-based AOP proxies in combination with autodetection of JMX annotations in your bean classes. Interface-based proxies 'hide' the target class, which also hides the JMX managed resource annotations. Hence, use target-class proxies in that case: through setting the 'proxy-target-class' flag on , , etc. Otherwise, your JMX beans might be silently ignored at startup...

   The nub of it is I don't get to use spring's fancy 'ManagedResource' annotations to define and name my MBeans. Instead I have to describe each one in XML. Not a huge deal, but unfortunate. Stupid AOP stuff!
3. Jconsole, which is the default tool Java gives you for connecting to JMX enabled systems, doesn't work in Ubuntu. Man oh man. If I could have the time back that I wasted before I realized that. You just get a blank window when you connect to your server with Jconsole in Ubuntu. I think the compiz desktop effects are probably the culprit here. Lame.
   

I spent most of the day dealing with my configuration woes, so I didn't get to work on the interesting part yet which is instrumenting the controllers. I'll post about that if it turns out to be interesting. This post is mostly a "what not to do" post. Hope it helps someone.

Building your resume

And when I say "building your resume" I literally mean creating a build system for a resume with config files, LaTeX and Rake. Why in the name of Knuth would I do such a thing?

1. Because it is AWESOME!?!
2. Version control! So how old will I be when my resume reaches 1.0?
3. Hosting on GitHub means my resume has an RSS feed!
   
4. LaTeX's Inline comments make for fun Easter eggs and color commentary.
5. A really keen potential employer could 'watch' my resume via GitHub. Heck they could even fork my resume and add things they would like to see me learn.
6. I could add a Rake task to publish my resume somewhere or to email it directly or even to tweet me whenever someone builds my resume.
7. Rake task for spellcheck.
   
8. I could have build parameters for adding or hiding certain sections of my resume... for example swapping out the objective at compile time.
   
9. They say "blogs are the new resumes" but I say, "GitHub is the new resume!"

Evolution of a Programmer

In a recent discussion about the Intentional language workbench on the Software Craftsmanship mailing list Dave Hoover made the following comment:

If programmers from 30 years ago looked at my typical day today, I bet they would think I was more of an analyst than a programmer. The high level code that I get to work with typically keeps me very close to the domain language of my customer... the problems I'm generally solving aren't related to computer science and optimizing milliseconds, they're translating my customer's desires into executable software.

I thought this was interesting and I agree with Dave. To some extent I wish this was even more true than it already is. Writing software and solving problems 'close to the metal' can be interesting and rewarding, but being able to bring my ideas and my customer's ideas to life quickly and elegantly is really what it is all about for me.