January 31, 2009

Server Side Sojourn

I'll been a little quite on the blogging front as of late, besides the occasional user group post. The main reason for that has been the last couple of months I've been heads down doing server side Java development for a cloud computing infrastructure using Amazon's Web Services for S3, EC2, SimpleDB, and CloudFront. All that is the back end for some amazing Flex based applications that Allurent has in the works.

Being back heavy on the server side is a mixed blessing. Its an area I've done a lot of work in, in fact many of my first technically oriented posts on this blog where about Java. As a result I'm not playing with that many new things. The flip side is that I've been able to crank out a bunch of high quality code which feels good. Using Eclipse for Java development has unfortunately made me realize how far Flex Builder has to go to be a truly productive editor. Top three things I'm missing when working on ActionScript and MXML code: code formatting , MXML organize imports, and right-click run as FlexUnit test.

Allurent practices peer review before check in and automated unit testing. In order to make reviews effective we've established a coding standard so that anyone looking at someone else's code won't be distracted by funky formatting. Consistent formatting also makes looking at file differences much easier, eliminating the angry fruit salad only the whitespace changed difference report. Alas, without automated formatting support time gets wasted tabbing and spacing files to keep them readable. Likewise the need to launch an external program and occasionally tweak files to run a single TestCase or method increases the barrier to writing unit tests, which is never a good thing. Thankfully, Flexcover helps us keep tabs on areas we are lacking.

Java does has a big head start on Flex/AS3 for getting the tooling in there. Progress is being made, but for someone coming from the Java/Eclipse world, it's frustrating at times.

Tags: aws eclipse flex ide java tdd

April 30, 2006

Pair Programming

Most of today and the later half of yesterday afternoon I spent pair programming. While I've collaborated for short periods of time with other coworkers, this is by far the first concentrated time I've spent doing it. Overall I'm inclined to believe most of what the advocates claim about pair programming. We created a lot of code and most of it worked on the first run. We didn't practice a TDD approach, but did make sure that good unit tests existed. Some of the simple issues that still came up even with two sets of eyes on the code were simple compile time errors like missing imports and changed method signatures on system APIs (the downside of working with a beta of Flex 2).

Unlike a "true" paired programming session, I didn't do much typing. I think this stemmed mostly from the fact that our development systems are laptops. It isn't as easy to slide the keyboard and mouse over to your partner in this case. Even though I wasn't doing the typing, I contributed to the code by helping spot potential issues (syntactic and strategic) while duplicating knowledge on some of the more potentially error prone plumbing of the system.

Tags: pair programming tdd work