Fabio Maulo has announced the release of NHibernate 2.1.1 GA via Twitter.
Get the bits and/or code here:
http://sourceforge.net/projects/nhibernate/
NHibernate 2.1.1 GA Released!
Reactions to the Legacy Programmer Boss
There have been a couple blog responses to my “Legacy Programmer Boss” post. The first was by Krishna Kumar and the second was by Mike Marshall. Both bloggers really ran with the idea and came up with some very thoughtful and constructive posts. I’m very happy that neither of them reacted to the term as if I meant it in a pejorative way. Although I was a bit miffed at Joel, I didn’t mean it to be a pejorative. A person’s focus and expertise shift as they advance in their career. That being the case, it’s up to each and everyone of us to use our brain when assimilating advice from our peers and superiors. We are all responsible for thinking critically about any advice we take, no matter who it is from.
Grow Your Shop’s Maturity by Managing up via New Blood.
When I joined the organization about 6 years ago, I took a look at the build process, I said: 1) All builds need to be done from the same machine (not individual developer machines) and 2) the builds and possibly the deployments need to be automated.
When I joined and espoused these ideas we had severe build / deployment pain due to the manual process, but from management’s perspective, automated builds and deployments seemed too bleeding edge or too costly to implement.
Time went on; the pain continued for years. I repeated my opinion several times a year.
Eventually the economy tanked. We were in the position to hire new blood (both consultants and full-timers). I was fortunate enough to be either a part of the interview panel or have input on the “desired skills” of the want ads. Each time we interviewed new full-timers or consultants I specifically looked for people who had skills we required AND skills we didn’t have as an organization but I thought we needed.
Over time, more and more people said: “we should automate the build!” Many voices are louder than one voice.
We are now trying to automate the build.
Thank you new blood.
In Response to: “Where is C# in the Programming Language Lifecycle?”
The nearly 8 year production life of C# has been very interesting. As a former Java 1 / Java 2 developer I can honestly say that C# started out looking a lot like Java. However, it has evolved into its own over the years. Point in case: I recently wrote a framework that heavily leveraged the things introduced in .NET 2 and beyond (generics, lambdas, linq to objects, nullables, anonymous types, etc). Looking at the code, it barely resembles the C# we all wrote in the past and what the majority of C# coders are still writing. In fact it is rather illegible if you only know C# 1.x and semi-legible if you know C# 2.0. It seems that C# managed to become something else without bothering anyone who didn’t care to notice.
Although C# has successfully managed to be a shape-shifter in the ever evolving world of language trends, I think K. Scott Allen is onto something when he questions whether or not C# will continue to thrive in the multi-threaded / multi-CPU world. I have a hunch that C# may remain a first class language if the single threaded / parallel language interop pans out in an easy fashion. I think C# (and VB) will remain to be the best way to model a domain and perform OOP in the Microsoft world, but perhaps other languages will advance to be the main application control / host languages. If the interop story goes South, people will choose something else.
All that being said - how much change can a language go through before it falls under the weight of shims that allowed it to grow outside of its initial design? Eventually the need to implement a hot feature to keep the language popular could undermine the language. I do have to admit however, that the C# team seems to have managed to truly extend the language rather than shim it or fake it to get new features in. The way generics were introduced really allowed the 3.0 / 3.5 features to be added in a way that isn’t dissonant with the original base language. Anders and co. basically put in the the genetic possibility of growing another limb of indeterminate descent without disrupting the body.
So what is my answer to the original question? C# has definitely hit maturity. Based off of the trends I am seeing in online code samples and forum questions, I think C# as it was in .net 1.0/1.1 timeframe is on the verge of decay as 3.5# semantics are probably just past the adoption/acceptance stage.
The State of Spolsky or: How I Learned to Ignore the Legacy Programmer Boss.
If you don’t know who Joel Spolsky is, you can probably pass on this blog entry. I have a ton of respect for Joel. I’ve learned a lot from his posts over the years, and I still consider him to be a guru in the business of software. I’m sure I'll continue to learn from him yet.
In recent weeks, Joel has made some controversial posts regarding what many people think are the hallmarks of modern programming (design patterns, TDD, IoC, etc…). In this blog post, Joel espouses the ethic of the “Duct Tape Programmer”. In this stackoverflow.com answer he has this to say about IoC:
IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual.
I personally am perplexed at how the IoC community took a beautiful, elegant article by Martin Fowler and turned it into a bunch of complex frameworks typically with 200-300 page manuals.
I try not to be judgemental (HAHA!), but I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren't as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It's the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don't understand it.
The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode. For example, suppose you have two versions of your database access classes... one version which logged aggressively and did a lot of validation, which you used during development, and another version without logging or validation that was screamingly fast for production. It is nice to be able to switch between them in one place. On the other hand, this is a fairly trivial problem easily handled in a simpler way without the complexity of IoC containers.
I believe that if you use IoC containers, your code becomes, frankly, a lot harder to read. The number of places you have to look at to figure out what the code is trying to do goes up by at least one. And somewhere in heaven an angel cries out.
I see two things happening here:
- Joel continues his (very worthwhile IMHO) crusade against the “Architecture Astronaut” who is so far into the clouds that they aren’t writing code anymore but think they should tell people how to code, and the “shiny new toy” developers who have a solution looking for a problem. I’ve had very painful experiences with both of these archetypes.
- Joel inadvertently enters “Legacy Programmer Boss” territory as he discounts mainstream changes in programming that have happened since he stopped coding as his primary job.
There was a point in time where “design patterns” where purely academic. However now-a-days many design patterns have become as ubiquitous as the FOR loop (that was the idea behind defining these patterns). IoC is not difficult to understand by any developer who can understand the factory pattern. Frankly, the average developer can go to 0 – 60 with IoC by watching a 22 minute video from David Hayden. If a developer cannot understand the factory pattern, then they are doomed to be a duct tape programmer. I’ve worked with many duct tape programmers, and over time their code requires more duct tape.
Joel is justified in his efforts to decry the Architecture Astronaut, but his Duct Tape Programmer is just as bad. After years of experience in the field, I think Uncle Bob’s Clean Coder / Software Craftsman is the happy medium.
If you write software for a living, you should keep up with the current practices and use them as you see fit. If you see your opinion in the minority, you are either a genius, an early adoptor, or wrong.
This blog will be a’changin’
Until now, this blog has been primarily focused on retro-gaming / retro-computing. I plan on expanding it in the very near future to include .NET development, slice of life, and some music / media related content.
Things in the works:
Rework the theme to be wide enough for code.(DONE 10/3)Reorganize tags(DONE 10/3)Add RSS feeds based on tags so people can ignore the topics they don’t care about.(DONE 10/3)- Possibly move to a hosted Wordpress install on my Webhost4life site. I really haven’t made up my mind about this yet.
Vectrex
I finally got my hands on a Vectrex via ebay complete with 12 games, manuals, and overlays. My neighbor had one of these when I was a kid, and I've seriously been lusting after it ever since. I spent many hours playing Scramble and Star Trek on one of these in my youth.
The Vectrex has to be one of the most unique early 80s game systems. It's a vector graphics based console that came with its own CRT monitor. It had one built-in game (Minestorm) and a cartridge slot for purchased games. The screen displayed black and white vector graphics but used transparent overlays that were placed on the screen to add color and other graphical elements. In my opinion, it remains the best way to recreate vector graphics arcade games at home. Emulation is great, but nothing can beat seeing these graphics on a CRT.
Here is the system I acquired:
My camera's autofocus had a hell of a time dealing with the CRT's refresh rate. It tended to snap some trippy pictures. Here is the cleanest picture I could snap of Minestorm in action:
Here is one of the trippier interpretations my camera made of Minestorm:
If you are a fan of vector graphics, but are unfamiliar with the vectrex, you owe yourself a peek at the following video from Classic Game Room:
Here is a great retrospective video of several classic Vectrex games. This video is done via an emulator and I'll think you'll see that quite a bit of sparkle is missing. It's still cool nonetheless.
Finally, just to prove that the Vectrex was the shizzle back in the day:
The Vectrex has to be one of the most unique early 80s game systems. It's a vector graphics based console that came with its own CRT monitor. It had one built-in game (Minestorm) and a cartridge slot for purchased games. The screen displayed black and white vector graphics but used transparent overlays that were placed on the screen to add color and other graphical elements. In my opinion, it remains the best way to recreate vector graphics arcade games at home. Emulation is great, but nothing can beat seeing these graphics on a CRT.
Here is the system I acquired:
My camera's autofocus had a hell of a time dealing with the CRT's refresh rate. It tended to snap some trippy pictures. Here is the cleanest picture I could snap of Minestorm in action:
Here is one of the trippier interpretations my camera made of Minestorm:
If you are a fan of vector graphics, but are unfamiliar with the vectrex, you owe yourself a peek at the following video from Classic Game Room:
Here is a great retrospective video of several classic Vectrex games. This video is done via an emulator and I'll think you'll see that quite a bit of sparkle is missing. It's still cool nonetheless.
Finally, just to prove that the Vectrex was the shizzle back in the day:
