Building Blocks

I’ve been playing around with the website grader by hubspot (nice toy), and there is one thing I never quite understood. That is the reason to list a site in the directory service DMOZ or similar directories. I mean how often do you go there and check for new interesting sites?

I spent some time looking at Yahoo’s Site Explorer, configuring my Morkeleb.com so that the siteindex.xml is published to Yahoo every time I update the post. From there I found a link explaining the reason.

Yahoo’s search engine wont index you if your not in DMOZ (or at least reduces the chance unless your not registered). Yahoo has their own directory service as well, that one costs 300 dollar per year. I hope they add the site to the index if you subscribe to their directory.

Looks like I signed up on Twitter just now, my account name is: “anshrak” if you wish to follow me. Top reasons, more playtime with my phone, cant sleep, and someone said I should.

Reasons I’ve been avoiding Twitter thus far?

Fear of Information overload. Since I have a limited amount of time to handle all the information I process, I’m selective in which information I subscribe too.

I also installed live writer to give it a test run, we’ll see how it goes.

Today they released a new version of the SDK for Google AppEngine.

Personally I’m very excited about the ability to recieve email.

Here is a link to the Java release notes. The blog post at Google only links to the python release notes.

http://code.google.com/p/googleappengine/wiki/SdkForJavaReleaseNotes

Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”

The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.

In a previous post I discussed how to get things done with teams.

Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.

With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.

With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.

The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.

This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.

At Least for me a check in to our shared source control system can mean one of two things:

• I want to make new code/features available to others
• I want to create a stable point in the source-control to which I can return to later

This opens up for the idea of using a Git setup with a master repository and a local repository. We’ll see when I move from Subversion for my own projects, and RemoteX will remain in TFS which doesn’t support two stage commits.

In a previous post I described a problem where the app-engine command would fail when enhancing the domain objects for persistence.

The problem was that the command line became too long to execute on windows, when executing the enhancement task.

I’ve been working on several workarounds for this problem.

• Enhancing the classes during compilation
• Enhancing the classes manually
• Enhancing the classes programmatically
• Modifying the ant target to produce shorter command line calls

Enhancing during compilation

Make sure you have version JDK 1.6 and add the enhancer and its requirements to the compilation class-path. Produces no errors during compilation, but no enhancement is done. Fails when not all libraries included, so something is happening. I’m not sure it can find the persistence.xml file to use.

Enhancing the classes manually

I had problems where the enhancer wouldn’t find the domain objects when compiled into a package. It would say that the classes we’re not included in my class-path, even though they were.

However, working with the manual enhancement I found a wonderful option called checkonly. So you could set the enhancement tool to just check if the classes are enhanced. This would be a excellent extra option for the grails app-engine plug-in, if you could call grails app-engine diagnostic and see which files that are enhanced.

Enhancing the classes programmatically

This seems to be a viable option. I modified the app-engine plugin for grails to do the enhancement programmatically, however it failed to enhance the files with two problems. Out of the box, the persistance.xml file is not located where it should be to enhance the compiled classes. It must be copied to a location where the enhancer can find it. The other problem was that of how grails organizes its compiled files.

Modifying the ant target to produce shorter command line calls

This is what I’ve got working right now. In the Google SDK I modify the ant-macros.xml

<macrodef name="enhance_war" description="Run the ORM enhancer on an exploded war">
 <attribute name="war" description="The exploded war directory containing the application"/>
 <element name="args" optional="true" description="Additional arguments to the enhancer"/>
 <sequential>
 <enhance failonerror="true" >
 <args/>
 <classpath>
 <pathelement path="${appengine.tools.classpath}"/>
 <pathelement path="@{war}/WEB-INF/classes"/>
 <fileset dir="@{war}/WEB-INF/lib" includes="*.jar"/>
 </classpath>
 <fileset dir="@{war}/WEB-INF/classes" includes="**/*.class"/>
 </enhance>
 </sequential>
 </macrodef>

becomes

<macrodef name="enhance_war" description="Run the ORM enhancer on an exploded war">
 <attribute name="war" description="The exploded war directory containing the application"/>
 <element name="args" optional="true" description="Additional arguments to the enhancer"/>
 <sequential>
 <enhance failonerror="true" >
 <args/>
 <classpath>
 <pathelement path="${appengine.tools.classpath}"/>
 <pathelement path="@{war}/WEB-INF/classes"/>
 <fileset dir="@{war}/WEB-INF/lib" includes="*.jar"/>
 </classpath>
 <fileset dir="@{war}/WEB-INF/classes/persisted" includes="**/*.class"/>
 </enhance>
 </sequential>
 </macrodef>

Now all my domain classes that requires persistence is in a package called persisted.  The macro should be modified to fit your needs or find a convention to follow in all your projects running on Google AppEngine.

There is a new version of the Google AppEngine SDK for Java.
Version 1.2.2.

The release notes are available here.

When merging conflicts between branches in TFS, there is a dialog for mering multiple conflicts. When you select more conflicts and wish to take either the target branches version or the source version. The Dialog uses the terms Server and Local changes instead. The end result I keep refeering to the following blogpost to make sure I select the correct option.

http://blogs.msdn.com/richardb/archive/2007/06/04/ui-bug-resolving-multiple-merge-conflicts.aspx

I hope they’ve fixed this in 2010, but I have yet to try it in the Beta.

I found a new tool for testing web-applications in IE today. It’s called IETester, and it allows me to test IE versions 5.5 to 8 in the same application. Which is great, since my Vista machine only runs 8 normally.

I use it to verify my Grails application in IE6. Tonight I managed to create a unit test capturing the issue I was experiencing in IE6, using IETester and QUnit, so now I know where to take off tomorrow.

However it isn’t that stable, I’m running it on a 64-bit machine which might add some extra strain on the application. But for me it needed to be re-started or crashed a few times while I was isolating the bug I am working on.