Caffeinated Coder

I’ve been working a lot with Castle’s Active Record and Ruby on Rails in the last month and as a result have written significantly fewer basic CRUD operations and database access code. It’s been an addictive experience and has caused me to rethink the proper role of hand-written database code (sprocs) within an application.

Although I feel perfectly comfortable in a set-based world writing SQL, it has traditionally been one of my least favorite areas of coding. Besides being relatively repetitive and tedious, at least when it comes to basic CRUD operations, sprocs are much more difficult to handle when it comes to source control, versioning, debugging, and unit testing.

For example, at my last job we were tasked by auditors to come up with a build and deployment process that included version traceability and rollback capabilities. It was pretty easy to put together an acceptable solution for assemblies, since automatically versioning dll’s in a trusted way is simple via the AssemblyInfo and rolling them back is trivial since everything is contained in a manageable number of dlls that simply need to be copied from one folder to the next. When it came to sprocs, however, the best we could offer auditors was some hackery around adding comments about the version at the top of each sproc definition file along with a big disclaimer that there was no guarantee that files were not modified by DBA’s along the way.

At my current job, database code causes us even more trouble because the database is larger and contains more sensitive data (thus making restores more difficult), there is a heavier reliance on shared code, and only the deltas of database code are currently under source control. It feels like I am constantly tracking down some ghost bug that is caused by my local database schema somehow being out of sync with the codebase.

Despite these misgivings, I’ve dutifully followed the traditional Microsoft recommended best practice of funneling all data access through sprocs up until recently because sprocs were supposedly faster, more secure, and provided a beneficial layer of abstraction.

Although I have heard several arguments against sprocs in the last several years, I recently embarked on a more thorough investigation while trying to convince my team to switch over from using an in-house code generation\sproc-based solution for data access to using NHibernate\ActiveRecord. Here are a few resources I found that present good counter arguments against the conventional sproc wisdom.

1. Stored procedures are bad, m’kay?: This classic post that was written by Frans Bouma of LLBLGen fame in 2003 spawned quite the flame war on the topic. Most notably, Frans counters the “Sprocs are faster because they are compiled” argument by quoting passages from the SQL Server BOL documentation that clearly suggest otherwise. He also counters security arguments by pointing out that parameterized queries prevent SQL injection just as much as sprocs and that assigning permissions to views and roles provide just as much protection as assigning execute rights on sprocs.
2. Who Needs Stored Procedures, Anyways?: This is also an older post from Jeff Atwood where he nicely summarizes the negative aspects of SQL when compared with a traditional coding languages and came up with the quotable phrase “Stored Procedures should be considered database assembly language: for use in only the most performance critical situations”. I definitely think that some developers are reluctant to embrace ORM’s for the same reasons that many old C++ programmers scoffed at the idea of letting the CLR garbage collector manage memory for them instead of manually doing it themselves with raw pointers.
3. Why I do not use Stored Procedures: Jeremy Miller dismisses performance arguments by declaring them instances of premature optimization and elaborates on all the problems caused by sprocs when it comes to maintainability, testability, and architecture. He also points out that the touted benefit of allowing DBA’s to make changes is actually a dangerous practice since it represents a breaking API change from the application’s point of view and thus should go through thorough regression testing before any DBA should be allowed to make changes.
4. Foundations of Programming - Part 6 - NHibernate: Besides offering a nice introduction to NHibernate, Karl Sequine provides a nice summary of the historical sproc debate, including a counter point for the increased network traffic argument, which he says is a moot point since most traffic occurs between a app and database servers sitting on the same internal GigE networks where bandwidth is fast, plentiful, and free.
5. DotNetRocks ORM Smackdown: For a more balanced debate, listen to this podcast episode (or download the transcripts) where Oren Eini and Ted Neward face off over the value of ORM’s in the software industry. Be sure to check out the commentary on the episode in the comment section of this Ayende post as well as the rebuttal in this post by Ted Neward.

In my opinion, one of the strongest denunciations of traditional sproc dogma comes Redmond itself, which seems to be straying from its original sproc recommendations in favor of a more more dynamic SQL generation world-view with its recent release of LINQ to SQL and the Entity Framework.

If you follow the open source world or program in some language other than .NET, then you’re bound to feel a little smug right now because ORM’s have been around for a long time. In fact, I have a vivid memory from 6 years ago of a co-worker who was fresh from the Java world being dumb-founded that Microsoft didn’t have any ORM solution. He was used to using HIbernate and the thought of manually mapping database tables to domain objects was hard for him to grasp. Even in the .NET open source world, I’ve been reading blog posts that sing the praises of NHibernate and IBatis.NET, two popular .NET ORM ports, for several years.

On one hand, Microsoft’s entrance into the fray is good news for ORM enthusiasts since it means that a larger audience of developers will begin to see the technology as legitimate. On the other hand, Microsoft clearly has some catching up to do in this space, so you might want to think twice about starting off with Microsoft’s offering rather than one of the more proven open source or third party alternatives.

If you are a .NET developer and new to ORM’s, then I recommend starting out with Castle’s Active Record, which you can learn in less than an hour by reading this Getting Started with Active Record tutorial. My co-worker’s were reluctant to try NHibernate because of the perceived learning curve and the plethora of mapping files required, but they quickly agreed to use Active Record after only a short demo.

If you are a POCO purists, which means that you want to keep your domain objects free of any non-business related concerns (such as persistance), then you’ll want to follow the repository pattern using the ActiveRecordMediator class rather than inheriting from ActiveRecordBase like the tutorial shows. Some of the more experienced ORM users seem to see ActiveRecord as more of a gateway drug to NHibernate and ultimately prefer to forgo the conveniences offered by the ActiveRecord layer in favor of the increased flexibility and loosely coupled design offered by dealing directly with NHibernate instead.

Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM’s clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.

It’s definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM’s.

I’ve spent much of my free time over the last few weeks learning Ruby on Rails and thought I would record a few first impressions for anyone else who is thinking of dipping their toes in the RoR waters any time soon.

First…My Motivations

1. Curiosity - I’ve made a few snide remarks about Ruby over the past year in response to what I felt was the overuse of hyperbolic and cultish language by prominent Rubyists. After a while, I decided the only way to know for certain whether the buzz was more hype or more reality was to experience it for myself.
2. Project - I promised my wife I’d get a simple PayPal integration e-commerce site up and running for her soon. Since my hosting site only supports PHP or RoR and I’ve already played with PHP enough through WordPress tweaks for my blog, I decided to go the Rails route. This gives me a vested interest in giving it a fair shot because if I can’t get it to work, then the wife won’t be happy. Everyone knows that if the wife ain’t happy, then nobody’s happy.

Learning Curve Milestone

1. Over the Motivation Hump: In the beginning, I languished for several weeks in a state of motivational limbo. The pure Ruby language stuff wasn’t that interesting to me and I hadn’t quite invested enough time in Rails to understand what was going on yet. The “Aha” moments finally came once I got all the CRUD operations working for one of the pages of my eCommerce app (sample apps only get you so far) and then got it deployed to my hosting site. Every since getting past that hurdle, I’ve noticed that the time I’ve spent reading my Ruby book has increased dramatically along with my reading speed because I am suddenly much more interested in it now that I am starting to grok the potential.

Concepts I’m Sold On

1. Convention Over Configuration - As a .NET developer, I’ve written my share of data access code and SQL over the years and feel perfectly comfortable with it. But I have to admit that it was a nice feeling to have ActiveRecord (the ORM package for Rails) be able to glean the table structure based on my naming conventions and dynamically generate the SQL and plumbing code behind the scenes for me. I didn’t even have to look at a bunch of ugly generated code in a code-behind page. It just worked. I haven’t had any experience with Hibernate\NHibernate mapping XML files, but I imagine that it is still much more laborious than the Rails approach.
2. MVC structure - When I first tried debugging into CruiseControl.NET, which uses its own home-grown MVC style architecture, I was discombobulated because the url didn’t directly map to a code file. It seemed like an unnecessarily complex way to structure a web site. However, after experiencing how the url maps to a Controller/Action/Parameter in Rails, Django, and the .NET MVC framework, I am finally becoming a fan of this approach. Once I got used to where to look for everything, code suddenly seemed like it was much more organized and manageable than before.
3. Having Development Lifecycle Built Into Project Structure - The fact that Rails creats a Dev\Test\Prod folder and configuration files, thus embedding the natural development lifecycle into the project structure from the very start, is such an obvious improvement that I’m surprised that not everybody does this.

What I’m Excited To Try

1. Migrations - I’ve heard about this for a while, but only read about its full capabilities today. Managing database schemas and data across environments is one of the biggest pain points where I currently work. Having a tool that can manage incremental changes to databases and then automatically roll versions back sounds too good to be true.
2. RAKE - This is the Ruby version of Nant/MsBuild but it uses code syntax instead of XML. I’m not as much of an XML-hater as some people, but if given a choice I always prefer code because it usually means much better debugger support.
3. RSpec - This is the testing tool that encourages Behavior Driven Development by enforcing certain naming standards and the transforming executable tests into human readable documentation. I saw the .NET port of this last fall at the ALT.NET conference in Houston and finally saw this demonstrated at the last KC Ruby User Group Meeting. I’m still not convinced that it can simply be handed to users in lieu of documentation as many claim, but it is still the best effort to merge the world of tech specs and executable tests that I’ve seen yet.

What I Haven’t Made up my Mind on Yet

1. Documentation: I’ve read several complaints that the English documentation for Ruby, which originated in Japan, is lacking when compared to other languages like Perl or Python. As a beginner, this hasn’t been an issue for me yet because there are plenty of books and web-based tutorials available, but this is something I’ll watch out for down the road.
2. Complex data models: I’m curious how ActiveRecord will handle the traditional problem of impedance mismatch that all ORM systems face when trying to reconcile conceptual differences between how information is represented in a relational database versus an object model (it’s what prompted Ted Neward to call ORM the Vietnam of Computer Science). So far I have been impressed with Active Record, but the approach in all the Rails tutorials so far has been to start with the database tables, which seems to be the opposite approach of what noted architecture gurus like Rockford Lhotka have been recommending for years. I also saw a few references to things like composite keys not being supported by ActiveRecord, which makes me wonder how it will handle large, complex data models from legacy systems. Once again, I’ll just have to wait and see how this turns out.
3. Ruby & Rails vs Django & Python - I’ve seen some excellent debates, like the ones in this Bitwise article or this blog post, on which of these two popular web frameworks is better. Both frameworks rely on the MVC pattern, dynamic languages, and ORM magic to reduce boiler plate data access code. Django boasts faster speed, a more popular and widely applicable language, a more plugable architecture, and some extra administrative interfaces that help out for content management sites. However, since my hosting site doesn’t currently support Django, I’m going to have to wait and do a comparison for myself later this year.
4. Speed & Scalability - I don’t even want to open up the can of worms that Rob Conery did by suggesting Ruby is slow and has scalability issues. However, the general consensus is that Ruby is indeed slower than Python and both are much slower than most static languages like Java or C#. Rubyists contend that Rails is fast enough for most scenarios and that you can always drop down to C when performance is needed. I agree that performance isn’t something that most apps need to worry about these days, but I am more skeptical about the viability and ROI of dropping down to C for most development shops when performance is an issue. On the other hand, Rails is still pretty young, so I can only assume that future versions will improve in this respect.
5. Tools - The general consensus seems to be that tool support for Rails is lagging behind the powerhouse IDEs used in the Java and .NET worlds. Although I do think that Visual Studio is a bit bloated these days, I see Intellisense and visual debuggers as major productivity boosters and see it as a significant downside to doing development in Ruby. So far the attitude I’ve run into from Rubyists has been the equivalent of “real programmers don’t use tools”, which I’ve never agreed with. I did see an article about Ruby In Steel that has both intellisense and a visual debugger, so I plan to try that out. For the time being, Notepad2 will work.
6. Beauty? - Call me a cynic, but I’m afraid I side with Jeff Atwood here when I say that I just don’t feel comfortable using the word beautiful in reference to code syntax. I definitely have aesthetic preferences when it comes to code, but they seem a little too subjective to be able to definitively say that one language clearly reigns supreme over all others in this respect. To be honest, from what I’ve seen so far, I like about half of the syntax in Ruby better than C# and half of it worse. For example, all those end keywords that litter Ruby code give me nasty VB.NET flashbacks, so I’m not partial to them. I am willing to believe that my sense of aesthetics will change over time and that I might suddenly find Ruby syntax more appealing a year from now. However, I am also suspicious that there is an emperor’s new clothes phenomena at play here. This means that a few smart and influential people proclaiming that they see beauty can suddenly cause everyone to convince themselves that they also see beauty, not because it is really there, but because they don’t want to look stupid or feel left out.

Please remember that I am very new to Ruby on Rails, so I welcome any corrections or helpful insights that readers who have more experience in this area can offer.

As for the rest of you, I wisely chose to clip my section on “Tips for People Just Starting Out” because this post was so long, so tune in next time for some tips on how to avoid stumbling blocks early on in the Ruby learning path.

I’m a little bit tired today because I stayed up late the last couple of nights working my way through the Boo Primer on codehaus. I think I first heard about this relatively young (2003), open source .NET language through various posts by Ayende and Hanselman. I was intrigued by the some of the adjectives that I commonly heard in relation to this language such as ‘beautiful’ and ‘wrist-friendly’, so I incorporated learning Boo into my 6 Month Roadmap to becoming a better developer. If nothing else, I just really like looking at the project’s stellar green ghost logo that reminds me of a Pac-Man ghost and makes me smile every time I load up the project home page.

Since Boo is built upon the Common Language Infrastructure, it is really not that much of a stretch for .NET developer to start using it, especially since the majority of programming in .NET these days involves using the base class library which is accessible from any CLI language. You’ll be even more comfortable with Boo if you’ve ever played around with Python. Although Boo is officially described as a mixture of Python, C#, and Ruby, the extremely bare bones syntax (hence the adjective ‘wrist-friendly’) most closely resembles Python.

Probably the easiest way to get started with Boo is to install SharpDevelop, an open source IDE for .NET. Have no fear; this is not like the typical multi-hour Visual Studio installation process. Despite being very close in functionality to Visual Studio, it only takes a few minutes to install. In fact, due to its incredibly quick start up time, I think I’m going to use this environment for quick proof of concept code instead of Visual Studio from now on. It has built-in support for Boo, so all you have to do to get a hello world running in Boo is create a new Boo console project and hit f5. Then you can get all the debugging goodness that you’re used to when working with VB.Net or C#.

If you prefer the command line, however, you can get up and running even quicker by downloading the compiler (booc.exe) and associated dll’s from the project homepage and setting your machine’s environmental path variable to the Boo bin directory. It comes with a nifty command line utility called Booish that provides real time execution environment so that you can test boo syntax without having to compile code first.

I haven’t had a chance to make up my mind on the aesthetics yet, but it was very nice to have such an easy time getting started and it has definitely been very refreshing to learn something completely new without any expectation that I will somehow use it at work. I think it put a little more fun back into programming.

I’ve been spelunking Powershell lately with Bruce Payette’s excellent book, Powershell in Action, and thought I would take a step back from some of the lower level nuances, such as dynamic type conversion and parameter binding rules, and organize my thoughts at a higher level.

What is Powershell? - It is the new command line/scripting environment from Microsoft that replaces cmd.exe and WSH. You can install it as a small, free OS update on Windows XP, Windows 2003, and Vista as long as you have the 2.0 framework installed.

Why is it Significant? - Microsoft has traditionally been focused much more on the GUI portion of the OS, which made creating administrative tasks much more difficult in Windows than it typically is from non-MS shells like Bash. This new version of the shell not only addresses these shortcomings in functionality, but significantly raises the bar for other shells by being object-based rather than string based. This eliminates most of the text parsing craziness that is usually required in order to consume command line output. Powershell also achieves an enormous amount of functional coverage by exposing all of the major MS API’s, including XML, .NET,COM, ADO, WMI, and ADSI.

Some Basic Concepts

• Cmdlets - Commands that follow the verb-noun pattern, such as Get-Process or Get-Date. These are actually .net classes that inherit from the base Cmdlet class and can take traditional switches or parameters with arguments. The environment comes with a number of great built in commands, but you can supplement these by installing the Powershell Community Extensions from Codeplex or creating your own that will get automatically loaded into the environment when the shell opens. You can view the cmdlets available on your system by calling Get-Command and then using Get-Help to find out more information about a particular cmdlet.
• Pipeline - The pipe operator ( | ) allows you to chain together commands in a very concise way by taking the output from the command on the left side of the pipe operator and feeding it as input to the command on the right-side of the operator. This is where the object based paradigm really shines because it allows you to access specific information in the pipeline through properties instead of regular expressions and hard-coded column indexes.
• Expansive Syntax- Powershell makes extensive use of aliases and pattern matching to ease the transition from cmd.exe and to allow for the terse, write-only experience from the command line that maximizes productivity when producing throw away code. For example, you can use the familiar dir instead of Get-Children when navigating the file system or the shortened alias gps instead of Get-Process when retrieving processes. You can get a list of built-in aliases using Get-Alias and even create your own using Set-Alias.
• Provider Stores - These expose various data stores such as the registry, certs, and environmental variables as drives, thus allowing you to navigate a registry hive by simply typing cd hklm:. Open source projects have been created to expose VSS, SQL, and Exchange as providers. Use Get-PSDrive to enumerate the available drives.

A Quick Sample Script (Query top 5 CPU consuming process on a machine)

get-process | sort-object -desc CPU | select-object -first 5 processName, cpu | format-table -auto

Now a little more concisely with aliases

gps | sort -desc CPU | select -first 5 processName, cpu | ft -auto

If you want a good 20 minute introduction to the topic, I recommend listening to this old HanselMinutes podcast. It’s over a year old, so the podcast uses the old code-name Monad, but it provides a great high level overview. If you enjoy it, check out later episodes where he interviews Bruce Payette, the dev lead on the Powershell team, and Jeffrey Snover, the architect.