Skip navigation

I’m really digging James Burke’s RequireJS library. Love the lazy loading, module separation, dependency management, and build optimization. Not to mention that RequireJS is essentially the loader from Dojo, which has a proven track record among many successful installs.

One of the things I appreciate most is the dictated JS file stucture. Module definitions always follow the same pattern, bringing sanity to a JS development stack.

Sanity — that’s why I need it. Maybe you do too? That is, follow RequireJS as a pattern for both your development and production environments and simply — be DONE with it.

There ya have it. Organization. Performance. Sanity. (Lovely, ain’t it?)

I’d really like to throw together a post with an actual implementation and some code, but I’ll have to settle for a link to James’ page for the time being.


Good luck — have fun.


I ran across an issue today where my Grails app was stuck in an infinite loop “compiling” on startup.

Command line symptons revealed the following:

Running Grails application..
Server running. Browse to http://localhost:8080/foo
[groovyc] Compiling 1 source file to /Users/cs44/.grails/1.1/projects/foo/classes
[groovyc] Compiling 1 source file to /Users/cs44/.grails/1.1/projects/foo/classes
Running Grails application..

Over and over….

Turns out I had a compiliaton failure of a groovy file in my “/src/groovy” directory. It sure would have been nice to ACTUALLY know of this compilation error as it happened. That said, the only way to find the culprit file is change to your grails class directory, which on my OS X box is the following: ~/.grails/1.1/projects/watch/classes

Next up — in a new shell, you’ll want to start the application, forcing the infinite compilation loop. While the app is failing to startup, run the following command in your classes directory: find . -name “*class” -ls

This will list all .class files, including our failed file(s), plus an “ls” style directory listing. From here examine the last modifed date and you should find your culprit.

Remove said file and recompile.

Hope that helps someone! I certainly chased my tail for bit…

If you’re using terminal in conjunction with Maven, the easiest way to increase the heap size on your JVM using OS X is as follows:

1) Using Sudo mode, open up you bash profile (mine lives at ‘/etc/profile’)
2) Add “MAVEN_OPTS=’-Xms256M -Xmx512M’; export MAVEN_OPTS;”
3) Save your profile.
4) Open a new shell and ensure the MAVEN_OPTS var exists by using the “set” command and searching for MAVEN_OPTS.
5) Enjoy your java.


Quick post: make sure your Java Preferences are giving priority to the 32-bit version of JRE 1.5. I had mine set to 64-bit JRE 1.6 and the damned installer kept dying.

I’m not sure if this is a known Eclipse issue, but all in all — FUN.

I spend a ton of time in DHTML land these days. Most of that development takes the form of a hybrid XP/Scrum Agile methodology. That said, I’m dealing with story cards. While the system works well, there’s nothing I dislike more than a story with endless acceptance criteria. I’m sure you’ve experienced one of these. There has to be a better way, right?

Let’s try screenshots, pictures, storyboards — call ’em what you want. I’d prefer a business analyst scribbling on a blank canvas much more than line items. Especially (ESPECIALLY) when we’re talking DHTML. Find a whiteboard, grab a marker, and bring the digital camera.


I’m officially a fanboy. That’s right – I’ve reached the point of no return concerning IntelliJ. It’s all about the features.

For starters, local history is great. It’s like a personal SVN right in your IDE. I’ve used the popular ‘e’ editor on previous projects, and while it has a similar feature – there’s simply no comparison. The feature is especially useful when you’re in an environment that discourages partial commits, etc. 

I’ve still yet to fire up a Flex project, as I’m pressed for free time. However, I’m growing more and more impressed with the native Grails support. The debugger is stellar and the ability to control a Grails console in the IDE in nice. I’ll admit that I am a bit annoyed by the lack of an in-place unit test reports, but I suppose I’ll live…

If you haven’t checked out IntelliJ – do your self a favor. Rock on computer!

I’ve recently switched over from developing on Windows XP to OS X. Now that I’ve been using OS X for a few months, I’m kicking myself for not switching over earlier.

However, in addition to the change in operating system, I’ve also decided to move over to the often acclaimed IntelliJ IDEA for all of my dev needs. It’s amazing what this IDE is capable of doing. It’s currently my one-stop dev shop. Everything from SVN, Java, Freemarker, Grails, Javascript, and even XHTML/CSS editing.

I’m currently using it for Java, Javascript (Dojo), Grails, and DHTML. There’s no turning back. Really, with OS X and it’s multiple desktop integration, I’m feeling productivity gains like never before.

I’ve yet to use IntelliJ for Flex development, as I’m already familiar with Flex Builder, but I’m edging closer and closer to giving it a try. I’ll blog more as I delve into Flex development with IntelliJ. I’m sure it will be fun.

Stay tuned.

By default OS X Leopard (10.5.5) ships with Java JDK 1.5 as the default JDK. This is fine until you actually need to compile an app dependent on 1.6, or even run an app that demands the latest API for JRuby or even Glassfish.

If you search the web for “OS X Java JDK 1.6” you’re likely to get blog posts related to the “SoyLatte” release of JDK 1.6. These blogs generally provide shell commands and environment setups that are required to compile the “SoyLatte” build of Java 1.6 for OS X. Aside from the lengthy process description, the real frustration comes in the contradictory experiences posted in the comments of said blogs. Quickly, the “upgrade” becomes disheartening.

There’s hope! (And it’s surprisingly easy…)

From Finder simply open “/Applications/Utilities/Java/Java Preferences” and drag “1.6” to the top of the list. You should now be able to confirm JDK 1.6 from the Terminal by typing “java -version”. You should see “1.6” (or something at least starting in 1.6.)

Now for Maven. The tricky part lies in your environmental $JAVA_HOME variable being set to the JDK 1.5 path. In the terminal, locate your Bash profile. (Mine lives at “/etc/profile”.) You’ll need to run “sudo” to edit and save the file.

Inside profile, you should have the following line as required by Maven:
JAVA_HOME=/Library/Java/Home; export JAVA_HOME;

If you do not see this line – I’m not sure this post applies to you…

Anyhow, “/Library/Java/Home” is a symbolic link that is still pointing to the JDK 1.5 “bin”, which prevents Maven from running the appropriate Java version. (This, of course, is correct if you’re forcing JDK versions through Maven.)

You’ll now want to alter the $JAVA_HOME variable to the following:
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home; export JAVA_HOME;

Save your profile, open a new Terminal session — that should do it. Via the OS X preferences pane, you’ve directed OS X to the JDK 1.6.  While through the $JAVA_HOME variable, you’ve pointed Maven to the appropriate JDK.

Hope that helps.

I ran across some significant layout issues in IE6 today when using Dojo’s fadeOut function. Essentially the div element I was fading out didn’t already have what IE6 (IE7 too) denotes as a “hasLayout” property. I came to this conclusion by reading the Dojo source of the function “dojo._fade”, which calls an IE specific helper function “_makeFadeable”. The code applies a CSS class of “zoom: 1”, of course – a proprietary IE CSS style, in order to trigger “hasLayout”.

For a better understanding of “hasLayout”, and what it means to the IE rendering engine – check out this article: “On Having Layout.”

As javascript becomes more viable on your development team, be sure to check out Dojo’s support for AOP.

I had the pleaseure of meeting Eugene Lazutkin at the recent Dojo Dev Day hosted by Google. He’s very dedicated to Dojo.gfx and I’m happy to hear he’s working on Dojox.aspect.