Caffeinated Coder

I’ve spent most of my free time over the last 3 months (…and by free time I mean after everyone else has gone to bed) building DosPecesCreations.com, which is a small e-commerce application for my wife’s new jewelry business.

I am a .NET developer by day, but I wrote the app in Ruby on Rails. I already mentioned some of my initial impressions about working with Rails, but since I just reached a new milestone by having finished and deployed version 1.0 of the app, I thought I would take a few moments to share some further reflections on the topic.

Why did I choose Rails?

Mostly practical reasons.

My hosting provider runs on a LAMP stack and the only options available to me were PHP or Rails. I suppose I could have moved to a .NET hosting site, but I’ve had good experiences with PrecisionEffect and like the idea of balancing my .NET experience with side projects that are built using other platforms.

I’ve  customized my blog, which runs on WordPress, enough to have already developed a distaste for PHP so that left Rails. I know that I’m 4-5 years late to the Rails party and that the cool kids have all moved on to more cutting edge things, but better late than never.

Am I glad I chose Ruby on Rails?

Definitely.

Don’t worry, I haven’t found religion. I’m not going to start spouting off about how Rails is so technically or artistically superior to .NET or other alternative web frameworks.

The main reason that I am glad I did the project in Rails is because it was a rejuvenating experience to immerse myself in a very different programming paradigm for a while. The simple act of starting over from a technical perspective allowed me to once again enter into that ‘hungry-and-excited-to-learn’ mode, a mind set which is very difficult to sustain when you stick to the same technology year after year.

I’m convinced that most of the annoying exuberance from early Rubyists had more to do with the psychology behind this experience than anything else.

Don’t get me wrong. I think Rails is a very innovative framework, but I’m pretty sure I would have felt the same level of excitement if I had worked in Django, Merb, or [insert new fangled web framework here] instead.

Was I able to develop DosPecesCreations faster in Rails than I would have been able to do in.NET?

Absolutely NOT.

Don’t tell my wife this, but I’m pretty sure I could have finished the whole thing in half the time if I had used .NET instead.

Before you start flaming me, I fully attribute this slowness to the newbie tax.

Anyone who has ever been burned by a clueless CIO that has trashed an IT department’s reputation by promising stakeholders extravagant productivity gains as justification for upgrading to the latest and greatest technology andor language knows about the dangers of this often forgotten tax.

The dirty truth is that your productivity is going to take an initial nose dive as you get acclimated to any new language, tool, or technology. It doesn’t matter if you are moving from Assembly language to Ruby++++, it’s going to take some time and patience before you see any dividends.

This initial learning curve slow down is exacerbated in the case of Rails by the fact that the documentation is terrible compared to .NET. Partly this is because no open source documentation that is maintained mostly by programmers who by their very nature hate documentation is ever going to compete with what legions of well paid technical writers hired by Microsoft can produce. It also doesn’t help that the Rails community plays much much faster and looser when it comes to backwards compatibility than Microsoft, thus making much of the existing free blogosphere documentation stale. The fact that Ruby was created in Japan and much of its primary documentation was never translated just doesn’t help either.

With that being said, I do think that if I were developing in Rails full time, then after a few months I would be able to whip out web applications with Rails much faster than I otherwise would with .NET.

This shouldn’t be much of a surprise since Rails is a high level DSL for web applications that relies heavily on the notion of convention over configuration to streamline development. Once again, not always a benefit for newbies since it often decreases discoverability, but it definitely speeds things up once you get the hang of it.

Finally, a shameless sales pitch on behalf of the spousal unit

Are you currently in the dog house with your significant other for playing World of Warcraft too late last night or trying to read your twitter feed on your smart phone while she was telling you something “important” or simply for working too much overtime? Why not bribe…er… show her how much you love her with a surprise gift of earrings, a necklace, or a bracelet? 

Each item is a unique creation from my wife and is very reasonably priced, which means you’ll have money left over for that that new solid state hard drive you’ve been wanting.

Even if you’re not currently in trouble with your wife, it is probably only a matter of time. If you’re reading this blog, then you’re probably both a guy and a geek, which means that the odds are stacked heavily against you.

Face it, you might as well start sucking up now so she’ll go easier on you later when the inevitable happens and you screw up. In fact, you may have already done it and she is just waiting for you to figure it out.

Most importantly, by purchasing jewelry from DosPecesCreations you will will keep my wife busy at night, thereby freeing up time for me to blog more. See? Win win win…

P.S.: Enter ‘SPCDLV’ for a coupon code and your shipping will be free.

Popularity: 7% [?]

What’s the difference between a spectator and a Newb?

In order to achieve spectatorhood, you really just need to run through a few samples in books and tutorials. If you want to be diligent spectator, you can even go as far as tweaking a few of the samples before passing judgement, but that is not strictly necessary and most certainly is not the norm.

When I wrote my initial impressions about Ruby on Rails post a while ago, I was definitely spectator.

I don’t think I graduated to a full fledged Newbie in Ruby on Rails until I started working on a code base that was destined for production and had someone other than myself making decisions about the functionality. This forced me to quickly abandon the safety net provided by the samples and start hacking away based on my initial, oftentimes faulty, assumptions.

Lest there be any confusion, I am not using the word ‘hacking’ in the technically artistic way, but rather in the brutish, blindly destructive, massively messy way that ends in stuff working, but only just barely and probably not for long.

In the spirit of full disclosure, I also must confess that this alleged code that is destined for production is really only a rather small and simple e-commerce app for my wife’s new side business of selling jewelry. Furthermore, I am not actually getting paid for my toil unless you consider the absence of persistent, not-so-subtle hints from the spousal unit a form of payment.

Despite these marks against me, I’m still claiming my status as Rails Newbie (not to be confused with n00b) and doing so with pride.

In honor of the occasion, I thought I would share a few thoughts that are, of course, heavily colored by my .NET centric developer background.

So far I’ve enjoyed…

• Writing Less Code - While I am always suspicious about claims of drastic code reduction, especially since these numbers are often confused with the total time it will take to deliver a project by misguided CIO types, I have noticed that my code files are pleasantly sparse compared to what I am used to as a .NET developer. While much of the code reduction can be achieved on the .NET side by using an implementation of an ORM and ActiveRecord framework (i.e. NHibernate and Castle’s Active Record), some of the niceties, such as the lack of redundant type names, curly braces, and keywords are unique to either dynamic languages as a whole or Ruby specifically. Some of my fellow developers who voted against including the new C# var keyword in our coding standards would hate the loss of explicitness, but I find it refreshing.
• Having Code Be Organized More Logically – My attitude towards the MVC (Model-View-Controller) approach to doing things has dramatically changed over the past year. I went from initial annoyance at not being able to map a url directly to a file name, to delight once I  got used to it and eventually realized that finding code was actually easier once it was split across three files according to function instead of all crammed into one file. I also like that I am immediately familiar with the directory structure whenever I open a new Rails project because it is mandated by convention and created automatically for each new project. This avoids the initial period of disorientation that I always feel whenever I open up an unfamiliar .NET project.
• Rapid Feedback – I have to admit that I like being able to pop open a file instantly in SciTE (think notepad with syntax highlighting) and then immediately seeing the results by simply saving and hitting refresh on the browser. It actually made me nostalgic for the good ole’ days of classic ASP when I didn’t have to suffer through 10-25 second compile times each time I wanted to verify whether a change would work or not.
• Managing Database Changes with Migrations – Being able to express database changes (both shema and data) in code rather than SQL and then roll the versions forward or backward in an automated and controlled way is definitely one of my favorite features of this new landscape. It’s such an obvious requirement for such a common pain-in-the ass task that I can’t believe that it isn’t built into the .NET development experience. My top TO DO item at work after our next release is to steal some time to integrate one of the .NET open source MIgrations clones that I’ve recently read about.

…but I have NOT enjoyed…

• Discoverability – While working on Rails, I’ve gained a new appreciation for how discoverable the functionality within the .NET framework is. When I want to figure out how to do something, I can usually find the functionality without ever having to leave the IDE. I simply use intellisense to start navigating through the namespaces until I find a good candidate and then simply glance at the tool tip popups to find out information about the parameters. The Microsoft framework is not only huge and comprehensive in the functionality it provides, but the designers have invested ungodly amounts of time into making the API well named, consistent, and logically organized according to namespace. I’ve been relying heavily on Google with all the Rails work I’ve done and it feels like I’ve wasted a lot of cycles just finding how to do stuff. While I often like the answer I get better when it comes to Rails, it still annoys me that it takes so much more effort to find the answers in the first place.  The main documentation site, http://api.rubyonrails.org/, contains good information if you can arrive at it via google, but simply trying to browse the site for information is a nightmare.
• Rails 2.0 breaking changes – This is also something that you just don’t see in the .NET world since Microsoft is so fanatical about maintaining backwards compatibility. It wouldn’t seem like this would be a big deal unless you had a big legacy app to worry about, but this actually made the whole discoverability and learning process all the more frustrating because there are so many stale nuggets of information out there. Although the main book I have been reading, Agile Web Development with Rails, was tremendously helpful for what I was trying to do, I still had to spend a decent amount of time figuring out why several of the code sample didn’t work because method calls that were renamed or simply stripped out of Rails 2.0.
• Hosting Site Support for Rails – I really like my hosting site, precisioneffect, because it has an awesome support staff that answers questions and solves problems extremely quickly. However, I was disappointed to learn that they were no longer going to offer Rails support on their newer servers because of some troubles they’ve had trying to support it. I was also dismayed that some of the reliance on command line tools in Rails didn’t always translate nicely into a web hosting environment. For example, I wasn’t able to execute my Migrations files to create my database so I had search around to figure out a way to generate a traditional sql file from my migrations script so that I could deploy it. I’m sure there are advanced tools to help in deployment situations, but I’m just barely a Newb so I haven’t gotten that far yet.
• Debugging -  Having easy access to an advanced visual debugger is such a central part of the out of the box experience in .NET that it is not uncommon for a .NET newb to be stepping through hello world example code in the debugger. Although Rails does have a command line debugger that allows you to step through code,  it is definitely no where near as accessible or usable as I’m used to with Visual Studio. I’ve seen several IDE’s mentioned that offer visual debugging for Rails, but so far I’ve only tried Aptana, which is so far most notable because it actually took longer to load than Visual Studio which I mistakenly thought was one of the more bloated pieces of software out there.

All in all, I have really enjoyed the last month of late night Rails development and feel pretty motivated to dig deeper into a few more books once I launch version one of my first Rails site. Who knows, perhaps someday I may even graduate to whatever level comes after the Newb stage.

Popularity: 9% [?]

Not too long ago, someone asked me to explain the fundamental differences between static languages, such as C# and Java, and dynamic languages, such as Ruby and Python.

Although I knew that duck typing and not resolving method references until runtime allowed for some nifty metaprogramming tricks that translated into not having to write as many lines of code, I was not able to provide any concrete examples of how this was done. This left both me and my friend feeling unsatisfied with my explanation.

Although learning about something at a high level through books, blogs, and podcasts can be useful, I often find that it tricks me into thinking I know more about something than I actually do. I’ve just had way too many experiences where I thought I understood something only to be proven wrong when I finally had the opportunity to roll up my sleeves and tackle some concrete examples and problems.

This is why I have recently been on the look out for some more concrete examples of how dynamic languages allow for some nifty feature that just aren’t possible in static languages (or at least too difficult to be feasible).

I finally found a good one this last week while reading about Dynamic Finders in the book Agile Web Development With Rails. These are convenience methods provided by Rails that allow you to query on various columns by simply following a naming convention for methods that concatenates Find_By or Find_All_By with the column names you want to filter on.

So, instead of having to create and implement a method like this (example from Castle’s Active Record):

   1: public static Card[] Find_By_CardType_And_ExpirationDate(int cardTypeId, DateTime expirationDate)

   2: {

   3:     return FindAll(Expression.And(Expression.Eq("CardTypeId", cardTypeId),

   4:                                Expression.Eq("ExpirationDate", expirationDate)));

   5: }

   6:

   7: ...

   8:

   9: Card[] cards = Card.Find_By_CardType_And_ExpirationDate(cardTypeId, expirationDate);

All you have to do is make the call to the non-existent method that contains your column names and Rails will dynamically generate the method for you.

   1: @cards = Card.find_all_by_cardType_and_expirationDate(cardTypeId, expirationDate)

How does this work?

Unlike with static languages, Ruby doesn’t require that this method actually exists at compile time. Instead it just throws a MethodMissing exception at runtime if the method you called doesn’t exist and then allows you to react to this condition by simply defining\overriding the required method_missing signature in your class.

In order to provide Dynamic Finder functionality, Rails uses something like the Regex logic below to parse the method name that was passed in to the method_missing override and then use the resulting tokens to dynamically generate the method and its implementation, “spot weld” it onto your class, and then execute it.

   1: def method_missing(method_id, *arguments)

   2:   if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(method_id.to_s)

   3:     # find...

   4:   elsif match = /find_or_create_by_([_a-zA-Z]\w*)/.match(method_id.to_s)

   5:     # find_or_create...

   6:   else

   7:     super

   8:   end

   9: end

Neat, huh?

I found this example particularly compelling because I am working with both frameworks right now and so far find Castle’s implementation to be remarkably similar to Rail’s Active Record even though it was created using a static language (C#).

The fact that Dynamic Finders aren’t available in Castle’s Active Record and that they are implemented by a decidedly dynamic feature leads me to believe that this was one of the areas that dynamic languages outshines static languages. However, I am a self-avowed newbie in this area, so I welcome anyone with a deeper knowledge of either framework to correct me if I’m wrong.

I would also love to hear about any other concrete examples of metaprogramming magic that is made possible (or much easier) by a dynamic language feature.

If you’re interested in learning more about dynamic languages, then I highly recommend Steve Yegge’s recent blog post, Dynamic Language Strike’s Back. It’s a rather lengthy transcription of a recent talk he did at Stanford on the topic, but it addresses some questions I had about dynamic languages in terms of tooling, performance, and maintainability in some very novel and comprehensive ways so it was well worth the reading investment.

Popularity: 21% [?]

I’m currently en route to Seattle to attend my second ALT.NET conference, so I thought I would take the opportunity to organize some pre-conference thoughts.

ALT.NET in a Nutshell (at least by my reckoning)

Alt.NET is a nascent, loosely organized ideology that started as a vibrant blogosphere reaction to this post by David Laribee and has since evolved into a number of conferences, user group meetings, and mailing list discussions.

Alt.NET conversations I’ve followed tend to focus on…

• Shifting the emphasis away from the latest and greatest API and towards a discussion of sound principles and practices that transcend specific technologies.
• Shunning “Demoware” and visual designers that offer quick, flashy functionality at the expense of long-term maintainability.
• Taking a “best of breed” approach to tools and frameworks and frequently looking to the open source community or competing vendors rather than the traditional Microsoft fare to enhance the .NET development experience.
• Fostering a healthy debate regarding the best way to develop software, thus shifting learning away from a vendor-centric, how-to learning experience toward a more interactive dialog.

The canonical example of an Alt.NET view of the world is the vocal criticism by many in this community of the Entity Framework. Most Alt.NET’ers prefer open source ORM alternatives, such as NHibernate or Ibatis.NET, because unlike the Entity Framework they follow the principal of persistence ignorance, which removes database dependencies from the code thus allowing business objects to be tested more easily and cheaply. While this position may seem like common sense to many, it is considered “Alternative” to most because it challenges the default behavior of many executives and mainstream developers who are more comfortable with following Microsoft’s lead on all technical issues.

If you want more information on the question of “What is Alt.NET?”, I recommend reading this short MSDN article by Jeremy Miller . If you have some free slots in your podcasting queue now that lawn-mowing season has started, then I also recommend the Hanselminutes episode with David Laribee or the recent DNR episode with Laribee and Jeremy Miller. You can also read about some of my own impressions of the first conference in Austin along with a humorous pictoral retort that I put together in response to some of the public criticisms of the conference being too elitist.

Why am I in the cheap seats?

A quick glance at the participants list reveals a high number of well-known speakers, authors, tool creators, and bloggers. I was a little bit star-struck by being surrounded by such a high concentration of geek fame during the last conference and this time around the participant list is even more impressive. I would consider this group to occupy the box seats in my little sports event analogy and I’m not even close to being there. In fact the guards would probably beat me mercilessly if I even deigned to stare wistfully at this section for too long.

Next comes the middle seats. These are the ones occupied by the B-List bloggers and dedicated open source contributors. I hadn’t heard of many in this group before, but was duly impressed last time with their extensive experience with topics that I only had a cursory knowledge of, such as Domain Driven Design, Behavior Driven Development, DSL’s, IoC Containers, MVC Frameworks, and Mocking containers. Unfortunately, I’m not in this group either.

That leaves the cheap seats. That is where those of us who are seasoned developers and agree with the alt.net principles, but have little experience with most of the tools and practices discussed at the event sit. Last time I mostly just shut up, listened, and tried to learn a few things while sitting in this section. Although lurkers are not generally appreciated at an open spaces event like this, I was at least comforted by the thought that I might eventually help spread the good word to my fellow Joe-developers back in the trenches.

I’m afraid I am destined to sit in the same section this time around. I’ll do my best to be a more active participant in conversations, but realistically I still don’t have enough experience with most of the popular ALT.NET tools and concepts to shed my lurker ways just yet. So, if you see a little unobtrusive speck high up in the nose bleed section of the conference, that is probably me.

What am I hoping to gain from the cheap seats of the conference?

1. Feel more stupid than I do now – My primary professional growth strategy so far has been to surround myself with really smart people in hopes that I will learn something by osmosis. I’m pretty sure this will be one of those situations. One unfortunate side effect of this approach is that I am perpetually humbled, which makes it really difficult to bask in the glow of a good old fashioned geek superiority complex. However, it is a small price to pay for all the fancy new developer tricks I learn.
2. Improve my criteria for evaluating tools and products – The one thing that prevents this type of gathering from devolving into a geek popularity contest based on which tools you use is the genuine attempt by most of the participants to define somewhat objective criteria by which to judge technology. For example, if I explain to my coworkers that we should use NHibernate instead of the Entity Framework and or the MVC Framework instead of WebForms, then I want to be able to articulate that these products are inherently more testable, which will help us modify our applications more quickly and with less risk. This type of approach tends to hold much more sway in the IT world than the old standby “all the cool kids are using it” argument.
3. Explore the development landscape – The .NET open source community may be relatively young and small compared to the Java community, but it nevertheless represents an overwhelmingly enormous amount of information for one person to sift through. When you throw on top of that the deluge of technologies being released by Microsoft as well as all of the relevant competing vendor products, then there is simply no way to adequately survey the development landscape other than through a sharing of ideas by passionate developers with diverse experiences in conferences like this.
4. Finally meet people I know – Huh? It sounds weird, but in the last year I’ve corresponded with a large number of people through blogging and tweeting. It seems that most of them will be in attendance this weekend. The small, open space format of this conference is ideal for making and strengthening professional contacts and becoming more engaged with the developer community. While google is still my fallback research tool of choice, I’ve been amazed at how valuable the daily conversations I have over email, twitter, and blog comment sections with like-minded developers all over the world can be. Hopefully this weekend will help me begin to tune into and use the developer community even more effectively.

In conclusion, I’m obviously excited about this weekend, despite my relatively lowly status on the ALT.NET food chain.

If you’re new to ALT.NET, I highly recommend attending one of the upcoming conferences or joining one the main mailing list to find out for yourself what all they hype is about.

Popularity: 12% [?]

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.

Popularity: 19% [?]

In case this post rides a reddit or Dzone wave, let me start out by saying that I am both from the United States and a .NET developer. Now on to my regularly scheduled point…

I’m fairly certain that most people would agree that Microsoft as a company is despised by a sizable segment of the software industry.

Since corporate politics bore me, I’m going to skip the part about why this is the case or whether this view is justified. Instead, I’m going to focus on the following corollary:

The same segment of the software industry that dislikes Microsoft also views developers who use Microsoft tools and languages as inherently less skilled and less capable.

That is a nice way of saying that when the typical Java\Python\Ruby developer conjures up an image of a .NET developer, it probably looks something like my esteemed blog sponsor on the right sidebar. In other words, I believe that the prevailing stereotype about .NET developers is that we wouldn’t know a software best practice or sound computer science principle if it recursively bit us in the arse.

Why does this stereotype exist and is it deserved?

Some harsh reddit feedback on one of my recent blog posts prompted me to seriously ponder this question and after going through various phases of anger, denial, and rationalization, I finally settled on the following theory.

Developers who don’t earn their living from Redmond-based technologies dislike Microsoft developers for some of the same reasons that people from other countries dislike Americans.

For any of my fellow countryman who are surprised by this, it is true. Most people in the world don’t like you. I’m sure books could be written on all of the social, political, economic, and cultural offenses that we unknowingly dole out on a daily basis, but I’m just going to focus on the one psychological offense that I’ve observed first hand numerous times in my travels.

Americans are inherently annoying because we rarely invest any effort into learning anything about the external world.

For example, If you are an American and meet someone who is well educated from another country, then statistically speaking the chances are good that:

1. You will not speak their language even though they will probably speak English.
2. You will not be able to locate their country on a map even though they could probably name all 50 states.
3. You won’t know who their national leader is even though they will not only tell you the name of our President, but also give you a nice summary of his foreign policy exploits over his last two terms in office.

You don’t have to have a political science degree to understand the psychological effects of this interaction. How did you feel the last time someone completely blew you off because you know they didn’t think you were important enough to bother with? Needless to say, it doesn’t help much on the diplomacy front.

I think a similar dynamic occurs with .NET developers who are so busy drinking from the firehose at Microsoft that they forget about the rest of the development world entirely.

The reddit comments that drove this home the most for me was the one said my opinion should be discounted because I “break the programming languages world into “languages by Microsoft” and “other languages”. Not a bad point.

Then there was my favorite wickedly sarcastic comment from Lepton3 (…come on reddit…you really need to de-anonymize this process a little). In response to my stated desire to learn finally learn Python, he quips… “Steady on there tiger! You wouldn’t want to rush in too soon.” A damn good point considering how long Python has been popular.

They both made me realize that despite my great efforts to study software best practices and learn no less than a dozen new Microsoft technologies in the last few years, I was still being pretty myopic in my approach to software development.

So, I hereby relinquish any guilt that I may feel for not keeping up with every new technology coming out of Redmond in the next several years. Instead, I’m going to do the programmer’s equivalent to a little world traveling so I can get better clued into what the rest of the software world has to offer.

I’m sure all the other kids will still make fun of me for feeding at the Microsoft teat, but at least I won’t stand out like a typical American tourist anymore.

Oh, and for all you .NET readers who may get inundated with posts on Ruby, Rails, Python, Django, and MySQL in the near future (at least that’s what I’ve been spending all my free time on in the last few weeks), hang in there. A little foreign culture is good for the programming soul. Also, since there’s no place like home, I’m sure I’ll continue to churn out .NET content as well.

Popularity: 100% [?]

I’ve been noticing my interest in non-Microsoft languages has been on the rise lately. I’ve been actively playing with Ruby and PHP and have been blog surfing for information on functional languages like Lisp and Erlang.

I guess that’s why I suddenly became curious about the current popularity ratings of programming languages and started to search for some hard data. The most comprehensive rating system that I found so far is the Programming Community Index published by Tiobe Software.

Here’s an excerpt from their February 2008 results:

Position Feb 2008	Position Feb 2007	Delta in Position	Programming Language	Ratings Feb 2008	Delta Feb 2007	Status
1	1		Java	21.483%	+2.50%	A
2	2		C	14.859%	-1.24%	A
3	5		(Visual) Basic	11.604%	+3.24%	A
4	4		PHP	9.890%	+1.04%	A
5	3		C++	9.274%	-1.49%	A
6	6		Perl	6.205%	+0.13%	A
7	7		Python	4.763%	+1.20%	A
8	8		C#	4.510%	+1.32%	A
9	12		Delphi	2.798%	+0.72%	A
10	9		JavaScript	2.334%	-0.65%	A
11	10		Ruby	1.862%	-0.67%	A

The list led me to a few surprising conclusions:

1. .NET isn’t as popular as I thought – It’s easy to lose perspective when you are surrounded by a single technology. For some reason I had assumed that C# and Java were equally popular. Although Java has declined about 5% on this survey over the last six years, it is still almost 5 times more popular than C#. In fact, C# is 8th on list behind C, C++, Perl, and even Visual Basic (oh the scandal!).
2. Ruby didn’t make the top 10 – Although there has been somewhat of a backlash against Ruby in the blogosphere over the last few months, I still assumed it was popular enough to be in the top 10. I suppose I should have guessed as much after the last recruiter I talked to told me that she never heard of the language.
3. COBOL refuses to die – I was saddened to see that COBOL is still 15th on the list. Some languages just don’t know when to quit. This shouldn’t surprise me since the bank I used to work at was at least 3-5 years from retiring their last COBOL program when I left and they were further ahead of the game than the vast majority of other financial institutions (they adopted .NET when it was still in Beta).
4. Python was language of the year for 2008 – Apparently Tiobe awarded Python this status at the end of last year due to its surging popularity. I noticed this right after I got an impassioned endorsement of the language from someone whose opinion I respect. I guess it’s time to check it out.
5. Functional languages are still on the fringe – DotNetRocks has had about a dozen shows on various functional programming in the last several months, so I thought that was a sure sign that the paradigm had gone main stream after a mere 50 years of relative obscurity. However, Functional Languages as a whole come in at a paltry 1.4% compared to the whopping 98% dominance of Object-Oriented and Procedural languages combined. LISP tops out the list at number 20, while Haskell is 36th, Erlang is 46th, and Scala barely made the top 100. Given the fact that we have hit the wall on processor speed and are well on our way to scaling out to a gajillion cores, I’m surprised that functional languages haven’t achieved a Ruby like cult status yet. Do you really want to spend your golden years debugging multi-threaded programs in Java or .NET? I didn’t think so. On a brighter note, Functional language searches rate quite high on reddit as indicated by this other poll. Perhaps there is still hope.
   

   Category	Ratings February 2008	Delta February 2007
   Object-Oriented Languages	54.8%	+3.1%
   Procedural Languages	42.9%	-1.9%
   Functional Languages	1.4%	-0.4%
   Logical Languages	0.9%	-0.8%

6. Dynamic languages are coming on strong - Rails has definitely proven the value that dynamic languages can bring to the table in terms of meta-programming magic and generally making life easier for the programmer, but I was surprised to see that dynamic languages were already almost as popular as static languages in overall usage. I obviously forgot about the prevalence of PHP, Python, and Perl.
   

   Category	Ratings February 2008	Delta February 2007
   Statically Typed Languages	57.2%	-0.2%
   Dynamically Typed Languages	42.8%	+0.2%

As an interesting side note, there were some languages that didn’t show up on the list because of the “Turing Complete” requirements that the site used.

A language is considered a programming language if it is Turing complete. As a consequence, HTML and XML are not considered programming languages. This also holds for data query language SQL. SQL is not a programming language because it is, for instance, impossible to write an infinite loop in it. On the other hand, SQL extensions PL/SQL and Transact-SQL are programming languages. ASP and ASP.NET are also not programming languages because they make use of other languages such as JavaScript and VBScript or .NET compatible languages. The same is true for frameworks such as Ruby on Rails, Cocoa, and AJAX. Finally, we have also excluded assembly languages, although Turing complete, because they have a very different nature.

No matter how you look at it, there are a lot of options out there that are being taken seriously these days and the number seems to only be growing.

It reminds me of a quote that I recently heard from Steven Forte. He stated in an interview that he won’t hire candidates if they have too much experience in any one language. He suggested only spending about 2 years on a language before moving on to something else. I was skeptical of his career advice at first, but now I’m starting to think that he had a point.

We are clearly entering the era of the polyglot programmer, which means that diversification is becoming more and more of a career asset.

Popularity: 45% [?]

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.

Popularity: 8% [?]