Lots of Changes

So it's been quite some time since I visited this blog, and I'm sure that at this point most people probably have figured it out that I don't do more then on blog a month anymore. And, since I have one day left before May starts, I best get this month's post in.

Things have been changing a lot around me. My backyard has thick, green grass growing in it. It's hard to imagine that two years ago, when we moved in, that it was nothing but a giant mud lot with absolutely no grass. I'm proud of my accomplishments of growing grass, but also am seeing the pains of actually mowing the stuff :) Along with the grass, the tree is growing again, dropping all kinds of stuff onto the backyard. This I am not happy about, and hope to have the tree removed this year.

Along with the exterior changes, there comes interior changes as well. I'm still spackling the living room, but am close to done. Nothing like taking a month-long project and stretching it over half a year. It's such a pain, but it will look good and that's what I care about, since it's the living room. I've also switched out our landline phone for a VOIP phone, but this time running my own PBX in the basement. The goal is to save money, and have fun with telemarketers when they call. I've already had the opportunity to play back farm noises in the phone on an unsuspecting victim.

And, the biggest of all changes, I'm on a Macbook Pro. After spending a lot of time making fun of these machines, I can now proudly say I was right. Nothing I've done on this thing has been easy -- it's taken me four days to set up a working development environment, and it's even still a bit flaky. There is no intuitive way of uninstalling anything, requiring me to manually remove all the file turds the thing left. And it is quite different from any other computer. If you include a Ctrl key on the keyboard, but map "cut" to Apple-X instead of Ctrl-X -- you're asking for gripes. They should have kept PC like mappings intact in my opinion. But, they are competing with Microsoft, so I guess I shouldn't complain too much.

In the long run, I'm getting used to all the changes. Hopefully as time goes on, I can forget about the season of change and just focus on the season ahead, which is hopefully full of kayaking endeavours.

Stressing is my business, business is good

It's funny how quickly things change in my life. One minute I'm bored with nothing to do, no vision or anything to focus on, and the next I'm so busy I work fourteen days in a row, many over ten hours for the day. But, needless to say in today's economy, I'd rather stay busy then not be.

As far as on the home front, most of the living room is complete. I have some spackling to do yet, but it's nothing major. I'm also going to look into making the cables nice behind the TV, but that's a minor detail. The insulation saved me a boat load of cash, which was nice, also knowing that it will work very much in the same way this summer.

In officially three days, I'll FINALLY order my kayak. It's been two years since Bridget and I started planning our hobby of whitewater kayaking, and I'll finally have my most important piece of equipment. I got some gear while in Florida last month, so I just need to get the essential five pieces.

Also a surprise, but Bridget's paintball gun arrived yesterday. Yes, you read that right, my wife has purchased a paintball gun and intends to "school" me in the woods at her parents. Unfortunately for her, she has trouble shooting a shotgun let alone a small sphere that doesn't stay straight, and will probably feel the slight sting of defeat when I shoot her. Despite who wins, I find it extremely attractive that she wants to play. Never in a million years did I ever think that I'd have a wife that wants to play paintball -- enough to own her own marker.

And finally, and most importantly, I'm crazy busy at work. I've gone from doing very little coding to working 10+ hours a day for weeks at a time. I can't disclose the projects or the products involved, but I can say I'm very much an expert on certain protocols now. Also, if this all pans out, I have some new API's to recommend for people.

Either way, life is stressful. But it sure does beat being bored out of my skull. Bring on spring, I have a wife to paint ;-)

Dude, where's my boat?

Yeah, so I'm playing off a famous movie title for my subject -- but you're reading this, aren't you?

I've spent the last 30min or so online looking up the whitewater boat I want to buy this year. I wanted to purchase it last year, but funds were short and I had show some restraint. This year though -- and I don't care if I have to sell a kidney -- I'm getting my boat.

The boat I hope to purchase is the Pyranha Everest -- an expedition boat made for bigger paddlers, which will allow Bridget and I to paddle into our camp sites rather then being restricted to just day trips. I fit in it like a glove, it's got some pretty good reviews, and I hope to take it over Medina Falls in NY someday. (That's 40 feet over a rock shelf waterfall, how's that for livin'?)

My goals this year are to get fit, and this will definitely help. Paddling in a creek or lake with a boat will help arm strength, and working on my lungs and cardio will help me hold my breath, because that's kind of a good skill to have in whitewater boating. I'm hoping Bridget and I can participate in some of the schools in the area to hone our skills, and hopefully in a couple years time we'll be paddling on our own around the country for vacation.

Either way, this is the year I get my boat. Plus, if the economy tanks and global warming does it's job, I'll just sell my wheels and have a new mode of transportation :)

January 2009 -- What I've done

We're now one month into the new year and I've done a ton of stuff on my own. Tickets have been a bit slow at work, but I've had plenty of time to help others out on projects and to do some research of my own. In the hopes of sharpening my skills as the Groovy expert in house, I've been looking into some complicated dynamic programming problems. Also, to keep myself grounded on relevant material, I've taken an interest in workflow systems and how they work.

First, I'll explain the dynamic problem that I'm finding to be most complex. A colleague at work has been using Grails (yay) to develop an internal application for company use. A situation that he brought up, which turns out to be documented as a wanted feature, is the ability to not just sort a column of a table on one object, but to allow for nested properties. For example, a tag of may have a sort on lets say a name. But, in some circumstances, we want to include an object as the column property being displayed. When we click on the column header, instead of using the default field of "id" for sorting, we want to be able to specify the property to sort on instead. An example of this might be sorting on the Foo object's name property like so:

However, this isn't as easy as it seems. In the controller, you have to accommodate for this in the "list" action by utilizing withCriteria. But, and this is what's sad, it seems you need to hardcode for the property at hand -- meaning that you'd need to do this in each controller for each possible property you might want to sort by at any given time. So, he's asked me to figure out a way to do this via Groovy to build a nested set of closures, which gets passed to withCriteria, to dynamically build a criteria. So -- if you send me foo.resource.name as what you want the sort on, I'd generate something like:

foo{
resource{
order(name,params.sort)
}
}

I have yet to get a complete working example that is fool-proof, but I need to thank him for the challenge. This is quite a headache, but is REALLY fun and a great puzzle for me to work on.

Second is workflows. Most systems on the market have a rather simple model, but find their complexities I believe in the business logic. A lot can and is going on at any given time -- tracking process status, history of the process, who a process should be assigned to, events being generated by interaction with the process, what the next transition is, etc etc. I will put in a pitch for a rather complex but easy to read system -- Grailsflow -- that has come to my attention thanks to the good guys running the Grails Podcast. This system is well broken down, utilizes the Grails plugin framework, and does most items out of the box.

I believe the code that was written for Grailsflow is a testimate to good coding practices in general, whether you write Java, Groovy, both or none. It utilizes interfaces correctly, abstract classes, configuration and dynamics (yay again) beautifully. I'm in the process of wrapping my head around the flow of the system and I'm about 70% complete.

All in all, it's been a great month for learning. I'm applying skills I've learned during the last half of last year. I'm learning about complex system development. And best of all, I'm not the only one who's recognized the potential of Grails in application development. Hopefully all this fun and excitement doesn't mean February is going to suck.

Cool Discovery

So I was poking around the Grails site and found the following plugin to be quite neat: http://www.grails.org/SpringMVC+Plugin

I think this is nice just because it makes sense. Grails at the end of the day is a Spring app. So, when I have a Spring app already, this makes it really easy (almost cut and paste) to turn existing Spring-only apps into Grails applications.

And secondly, it's a great example that Groovy, though being extremely powerful and cool, is not always the best choice. The argument here is that Java is faster then Groovy (which it is), and when dynamics aren't needed, it's helpful to use something like this plugin to get the best of both worlds when you want it. I believe next time, I'll have to try this plugin out on my application -- just as a proof of concept.

A Trend Setter? Or Just a Nag?

Thanks to Kratzer, it was exactly a year ago that I began working with Grails and Groovy. I was sent to Virginia to the Groovy/Grails Experience, where I was introduced to a lot of the features and how-to's of Groovy and Grails. Upon return, I was on fire -- no language or framework has got me so excited about programming like Groovy & Grails has.

So I've nagged the guys in the office. Every response is normally "If you programmed with Grails, it'd just work" or something of the like. I get a lot of crap for saying this type of stuff, but I enjoy it. It's kinda neat being a "resident expert" and I needed to learn more. In August, I got the opportunity to travel to Chicago to learn in-depth with Jeff Brown on Groovy & Grails. Again, I came back fired up, and this time knew what I was talking about.

It's now exactly one year. Groovy has become useful for a lot of the developers in my office, and Grails has started to spread a bit. I've implemented Grails in two production environments, and I'm looking to promote it into another. A colleague of mine took on Grails and created an internal application that he's impressed with -- and giving me some valuable feedback on his pain points. Rebuck I've been told is reading "The Definitive Guide to Grails" and I'm waiting to see if he starts using it. (Don't resist Mark, all your friends are doing it) And now I even got another co-worker looking to see if Grails will work for his model.

So is it all because I'm a nag? Or is it my trend setter roots? Or is everyone just afraid of the Giant and afraid of getting eaten if they don't comply to my wishes? Whatever the case, I think in another year, with the help of the SpringSource/G2One merger, we'll see Groovy, if not Grails, become much more mainstream. And when that happens, I'm making myself a cape and running around the office screaming "told you so". If it doesn't, well, then I guess this article will get me more ridicule, which to be honest, I'll deserve.

Special thanks to Kratzer: You created a monster and I don't think you intended to :-)

Source Code Pain-Points

Source Code Control seems like a relatively easy concept, yet seems to create large problems with teams of developers. I'm not really going to rant about all the different "hot topics" when it comes to source control, but I am going to rant on one I've bumped into today.

So the constant argument with every development team I'm on always seems to lead to this ultimate question: What is the latest-and-greatest codebase, trunk or a branch? And what happens if mid-stream we decide to change that?

We had a project where we cut a branch for every production release we had, leaving trunk as the latest-and-greatest. I put a significant amount of code onto trunk, as it waits to go to QA for testing. Somewhere in between, things changed, and trunk all of a sudden became the production code. Last night, some urgent fixes got published to production, including my large code piece not meant to be there yet. I forgot about this, and received an email this morning when my code broke a form in production.

It's just frustrating, because it feels like a no-win situation for me. Code I wrote, that needed tested for obvious reasons, ended up getting tested in the big lab, making our entire team look bad. However, to some degree it's not my fault, since I checked that code into trunk when it was "unstable" code, and then the model changed. Either way you look at it, this problem seems to be a real irritant and should be something solved back in the 90's.

So I'd be interested if my technical readers have a solution. I know the ultimate problem here is that someone decided to change our model midstream, creating a huge issue. But, how do you develop code, and what do you do to avoid this scenario? And how do you gracefully bow out without putting blame on yourself or someone else? Without keeping all my source code on my computer and do incremental check-in's (which is stupid but possible using Git), I really am starting to develop a complex over my check-in's, no matter what the model.