Craig Pardey

I wanted to learn how to build mobile apps, so last weekend I bought Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa. I don’t have any problem learning a new language, in fact I really enjoy it, but I was reluctant to to pay serious dollars for a Mac just to learn the skill.

The book covers how to build a website that is tailored for the iPhone. It looks and behaves like an iPhone app, but is actually a website. After a few chapters I started to feel dirty. It documented hack after workaround after hack.

This week I encountered an interesting issue in Tapestry when I tried to dynamically load a component using Tapestry’s built-in EventListener functionality. The component in question had a .script file associated with it, which Tapestry loaded dynamically, but the JavaScript functions in the .script file were “not found” when I tried to execute them.

After a bit of digging around, a colleague of mine noticed that Tapestry was loading the .script file using an eval() statement instead of inserting the script into the DOM.

I had a problem recently where Eclipse couldn’t find my source files when remote debugging a particular application. It would stop and the breakpoint and show the class file with a “attach source” button, but pointing it to the source directory didn’t do anything.

It turns out that the solution was to add the project to the remote debug configuration.

This is done by “Run -> Debug configurations…”
Choose the remote config from the tree on the left
Click on the “Source” tab
Click on the “Add…” button
Follow the wizard.

I’ve recently started using Mercurial, which is a distributed version control system.

DVCSs initially struck me as a solution looking for a problem. SubVersion seemed good enough for our purposes at work, but we decided to try out Mercurial for one iteration to see what all the fuss was about.

Perhaps the most significant difference between SubVersion and Mercurial is that Mercurial uses a local repository. This subtle distinction significantly changes how you work because you can commit your changes without having to publish them. A ‘commit’ in Mercurial is like a savepoint in database-speak - it gives you a safe place to roll back to if things go awry. Once you’re happy with your changes you can use the patch queue to fold all your commits into a single changeset and ‘push’ (i.e. publish) your changes to the central repository.

I’ve recently started trialling JRebel at work. JRebel is a piece of software that hot-swaps your code so that changes made in your IDE are reflected in your application server without requiring a restart.

The benefits of this idea are fairly obvious. I no longer have to wait 1 - 2 minutes for JBoss to restart each time I correct a spelling mistake etc. The time saved by not restarting probably make the product worth the $US149 licensing fee.