Posts Tagged Tools
Twitterer
Posted by Morten in Uncategorized on November 16, 2009
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.
Google Appengine SDK 1.2.6
Posted by Morten in Uncategorized on October 14, 2009
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
Tooling idea for Getting things done with teams
Posted by Morten in Uncategorized on September 11, 2009
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.
Getting things done with teams
Posted by Morten in Uncategorized on September 9, 2009
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.
What is a checkin?
Posted by Morten in Uncategorized on September 7, 2009
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.
Grails and Google AppEngine on Windows
Posted by Morten in Uncategorized on July 27, 2009
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.
Version 1.2.2 of the Google AppEngine JavaSDK Released
Posted by Morten in Uncategorized on July 27, 2009
There is a new version of the Google AppEngine SDK for Java.
Version 1.2.2.
The release notes are available here.
TFS merge conflicts dialog
Posted by Morten in Uncategorized on June 24, 2009
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.
IETester
Posted by Morten in Uncategorized on May 27, 2009
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.
Changing the platform of ClickOnce deployed applications breaks automatic upgrade
Posted by Morten in Uncategorized on May 27, 2009
I wrote earlier about and issue with ClickOnce Deployment, where the processor of the deployment manifests need to match the processor the application is compiled for. Naturally of course, it turns out we need to compile for a specific platform.
By compiling for x86 and marking the deployment manifest as x86 we managed to get some applications running on 64-bit machines. These applications have dependencies on assemblies that crashes if they are run on 64-bit machines, but aren’t compiled for any specific architecture.
So we recently changed to x86 on most of our ClickOnce-deployments. This resulted in the following error when upgrading previous versions.
+ The deployment identity does not match the subscription.
Apparently when we change the application to compile using x86 the applications identity is changed. This means that the ClickOnce-deployment doesn’t work when we shift from All Platforms to x86.