Fostering good code vs enforcing it

During my time with a previous employer I learned many lessons that one is confronted with when on team with a non-trivial percentage of permanently-junior-coders (my code word for those people Joel Spolsky would put in a rubber room away from production code.) One particular lesson I learned was the folly of trying to enforce good code by not only taking steps to foster ‘good’ code, but to also prevent bad code. The senior members of the team (including myself) agreed that a particular coding ‘act’ was a pretty strong code smell. And we decided to use a somwhat more complex classpathing arrangement to prevent any code from being able to give off that particular code smell. After awhile this started to rub me the wrong way when I realized certain sacrifices were being made in order to keep the safety net. But before much came of it I moved onto greener pastures with my current employer.

Well, some time later I learned that the safety net was abandoned. And not only was it abandoned, but the way it came to be abandoned was that one of the permanently-junior-coders had simply (and likely unknowingly) broken the safety net. Just brushed it away with a simple mouse click. And not only that, but no klaxons sounded or anything when it happened, so significant time had elapsed between the net being bypassed before anyone even knew it. Upon learning this I started to think a little about that experience. Trying to learn what there was to learn.

I had read Joel Spolsky’s book “Smart and Gets Things Done” at the suggestion of my fellow blogger Barry. And what Joel says about the “rubber room” has begun to hit home with me. There are folks who will claim the permanently-junior-code can be put to good use in many cases. And I’m not going to make a claim they are ALWAYS wrong. However, having senior coders spend time and effort making those permanently-junior-coders effective is a cost. And that cost should be weighed against the benefits to be gained by having the senior coders work on real code. To be sure I’m not saying senior coders shouldn’t have to make good readable maintainable code (I’m not trying to justify coding myself some job security.) But they shouldn’t have to make sacrifices that are only necessary to benefit the permanently-junior-coder.

Linux is Cool

I’ve been a Linux enthusiast for about a decade. Enough so to be able to get it running at home for various things, and be the one guy on a java/web development team to be able to have a somewhat in-depth convo with the server admins. Recently I’ve put together another server’s worth of hardware to host several services, mainly a JEE app server and DB. It’s certainly not new hardware (Athlon 2500++) but it’s easily the strongest hardware I’ve ever had in a Linux server. I chose to use Ubuntu Server but, admittedly, without a real strong reason. Ubuntu Desktop had just treated me well, and I’d heard a few good recommendations about it.

So you might be asking, why is this guy saying Linux is so cool? Well, it’s not gonna be anything new to those already familiar with Linux or who’ve heard those Linux-heads spouting their love for it. That is, that with some 4 year old hardware (and older in the case of a few pieces,) a few hours of work, and a bunch of FREE (as in I haven’t paid a freaking dime) software I now have a web server (apache), a code repository (SVN/webSVN), a relational database (mysql), a JEE appserver (glassfish v2), an SSH server (openSSH), as well as a bunch of other tools I don’t have a use for yet. And, imagine that, it’s secure to boot. I don’t think that is something someone is likely to setup as quickly and cheaply with M$ based stuff. And it would be even more unlikely if Linux hadn’t come along to challenge them.

While that alone makes Linux pretty cool, Barry and I have also learned a cool new use for the ssh server. That is as a SOCKS proxy for web browsing, IRC, and more secure administration of the DB server. This comes in handy when wanting at least the smallest semblence of security when wifi-ing at conferences, restaurants, etc. And again, very little work and absolutely no cash involved. SWEET!

Upcoming Star Wars video game

Barry pointed me to an article about the new Star Wars: The Force Unleashed game that is due to come out in the next quarter or so. I’m a huge Star Wars geek, so it doesn’t take much to get me going, but this game looks pretty cool. Not only from a game play standpoint, but also from a storyline standpoint, and maybe even most impressive: from a eye candy standpoint. They are taking advantage of the advanced capabilities of the latest generation game consoles. I’m soooo drooling over this thing already.

Pelini announces his assistants

I just read a post on JournalStar’s Husker blog that Pelini announced his assistant coaching staff:

The offensive staff includes Barney Cotton as associate head coach/offensive line coach; Shawn Watson as offensive coordinator/quarterbacks; Ted Gilmore as assistant head coach/receivers coach/recruiting coordinator; and Ron Brown as tight ends coach.

On the defensive side, the Husker staff will include Carl Pelini as defensive coordinator/defensive line coach, Mike Ekeler as linebackers coach, John Papuchis as defensive ends coach and Marvin Sanders as secondary coach.

I’m excited by the official news, especially because it means my personal best case scenario from a month or so ago (Callahan gone, Pelini as HC, Watson as OC) is going to be a reality. The only surprise (to me, anyway) was the couple of honorary designations on the offensive side: Associate Head Coach for Barney Cotton and Assistant Head Coach for Ted Gilmore. Which one is higher, Associate or Assistant? No idea. Pelini has apparently already said that the RBs coach won’t be filled until after the bowl season, and I’ve read some speculation that mentioned an RBs/Special Teams combo coach. From the above, it looks like those people were making a connection I wasn’t.

I’ve been excited about Watson being a part of our coaching staff since he joined up following his stint in Colorado. Now, I went to CU-Boulder, so I might’ve spent more time really evaluating the performance of the offense under Watson than alot of other Husker die-hards. I’d describe CU’s offense under Watson as being balanced between a reliable power running game and an efficient passing game that featured exceptionally well-coached play from the quarterback. Friggin Joel Klatt never should’ve performed the way he did against us, but I always admired how much was squeezed out of what they had to work with.

I think our offense with Watson as OC (or as however much of an OC as you could be under Callahan) showed more upside than the offense with Norvell as OC. When Watson came down to the sideline later in the season, our offense really took off. With Joe Ganz’s intuitive feel for the offense, things seemed to gel in a way we hadn’t seen before. I remember commenting to Erik at the time, “this might actually be the first time that we’ve really seen the West Coast Offense” at Nebraska. Perfect timing, dictating to a defense, involving our stars, etc all become more a part of the picture as Watson’s role increased.

Basically, I’m tickled pink. Can we skip straight to the Spring Game?

Erik adds:

I too am tickled scarlet (and cream,) but my focus is more on the defensive side of the ball. Don’t get me wrong, knowing the offense is likely going to pick up about where it left off (if not better) is really good and positively impacts how well the D plays (and vice versa.) But realistically believing that our D will likely be able to STOP SOMEONE now and then, will just rule for me. Not that I’m not suddenly expecting a top 10 defense. I’d just like something higher than say the bottom 5% next year (a partially sarcastic statement), and maybe something in the top 25% the year after that. It’s beyond that where I start to get a gleam in my eye and dream about top 5%.

While I don’t know much about Carl Pelini, having him as the DC worries me a small amount. It might be that Carl totally deserves the position and will make me eat my words (which I would love.) But it’s also consistent with nepotism/cronyism. Basically all of the defensive staff (other than Marvin Sanders to some extent) is brand new to me, and so suffers from the same skepticism. However, at this point I trust Bo (and TO) enough to not be real worried about it.

Worrying about recruiting is a big concern now, especially worrisome is whether or not the mainly young or recycled asst coaches will be good recruiters. And I do too, to some extent. Particularly since it sounds like this years recruiting class is crumbling more than most expected. We’ve certainly gotten spoiled with the classes Cally’s brought in the last couple of years, at least in the terms of rankings. What I’m less sure of is of the importance of a good recruiting class THIS YEAR. It understandable, to me, that getting a good class this year would be difficult. Right now I think the most important thing is getting the most out of the talent we have now. Once Pelini has done that for a year or two I think recruiting will go smoothly (though maybe never as well as under Cally.) So I’m not going to freak about this year’s class. But if he’s digging for scraps next year, I’ll be concerned.

I agree with Barry. Husker football can’t start too soon. BO BIG RED!!!!

Groovy/Ant

In the past I’ve used both ANT and Groovy. but independently. Ant for building J2EE EAR files for a large website, and Groovy as a shell scripting language for rather mundane admin-like functions on a Linux machine. Recently I used them together to implement another J2EE EAR file building process that is also somewhat user friendly for a non-ANT-or-Linux-familiar crowd.

At this point in time, what ANT is bringing to our table is just java classes that know how to call command like processes (like SVN) and know how to do standard things (like build a .war and/or .ear file.) And what Groovy is bringing to the table is a nicer way to invoke those classes, a la it’s AntBuilder class.

First off, the result is waaaay more readable. This is partially because Groovy’s syntax (while not exactly Java) is pretty readable for me as a Java developer who’s done a little Perl/shell scripting in the past. But is mostly due to the fact that you don’t have to write semi-complex code in XML. If you’ve ever had to wrap your head around someone else’s non-trivial build.xml file, you know what I mean.

Secondly you can easily implement conditionals/loops/user input. This is something that was sorely missing from plain ANT. An example of where this is handy for us is how we determine and retrieve which 3rd party jars we need to have on the classpath when compiling our Java code (in other words where I’d use Maven if I had a year to get it setup and working.)

The one unintuitive bit in all of this was that when I added the Ant-SVN tasks to the classpath I had to add them to Groovy’s classpath. That don’t make no sense. But also wasn’t too hard to deal with.

You can see the script here.

Blowhard, anyone?

OH YEAH!

I, too, would like to bust thru the proverbial wall, Kool Aid Man style, by leading with some small talk.

Hello, world.

Inaugural Blog Post

Well to much fanfare (well…in my head anyway) here is the inaugural FridayLunchCrew blog post. I’m not going to put much thought into this post, cause I’m not sure it’ll even catch on. But then again I may not be putting much thought into any posts I do even if it DOES catch on. So there you go.