Ruby/Rails on Linux (oh yeah, Perl too)

So I’ve spent the last four months developing Rails apps, Ruby scripts, and Perl scripts on a Fedora desktop. I cut my teeth with Ruby/Rails on my Mac at home, so I was in on the TextMate and Growl goodness. It’s comical to see that 90% of Rails developers are on the Mac, and one would assume that it’s because if one must use a trendy framework, they must also choose a trendy development platform. The truth is, I just haven’t found sufficient analogues to Mac tools in the Linux environment.

The first editor I experienced (and the one I keep coming back to) is Eclipse/Aptana/RadRails. It is a beast of an IDE, taking several seconds to load on a capable dual core AMD 64. Here’s some other issues I run into on a daily basis with the 1.0 release (which, to me, would imply feature complete and stable):

• RadRails “forgets” about syntax highlighting and makes everything purple.  Sometimes, typing space at the end of a line and saving will fix it, but it’s a crap shoot.
• Eclipse will occasionally slow down to a crawl for about a minute.  The GNOME task monitor says the CPU is idle, but Eclipse would make you think it was sharing CPU time with a nuclear explosion simulator.
• The “go to resource” dialog doesn’t quite load results for every file that matches your criteria.  It also takes an extra arrow key press to get through the list.
• If left open for too long, the inevitable, “There was an error, would you like to exit the workbench?” dialog appears.  You can say “no” but then you’re just living on borrowed time.  Eventually, it will all come crashing down.
• Of course, there are not nearly as many cool shortcuts and scriptability that TextMate offers.

After getting frustrated with RadRails, I turned to gedit, GNOME’s text editor.  Apparently, there are several plugins you can get to make it act almost like TextMate.  It’s also very lean and responsive.  First of all, the gedit website was down when I tried to get the plugins.  Then, it became a confusing ordeal to get the plugins installed correctly.  Gedit also liked to keep backups of each file sitting right next to the real files.  This made SVN a bit messy when I would just run an svn commit on everything.  Furthermore, the plugins, like the quick file open, didn’t even work 100%.  After some gedit crashes, I decided to ditch it and look further.

After trying the two major open source editors, I looked into ActiveState’s Komodo IDE.  It’s a paid app running at $300.  This IDE was the most consistent, stable, and feature-rich app out there.  However, it had major performance issues.  Simply scrolling through the list of files in a project slowed the app to a crawl.  I installed the version compiled with gcc 5, which offered a slight speed improvement, but still wasn’t snappy enough to facilitate rapid development.  It wasn’t worth $300.

So now I’m back to Eclipse.  Yes, I know there’s always vi and emacs, but I’m feeling too lazy right now to learn all the keystrokes required for things as simple as highlighting text and switching files.  I’d rather just use the mouse that God gave me.

As far as a Linux analogue of Growl, there is Mumbles.  At this point, it seems like too much of a hassle to find all of the plugins to make Mumbles work with even simple services/apps.  I love how many apps now (like Firefox 3) have Growl support built right In.  

Which brings me to my point.  The Mac is sort of like a “GUI on Rails.”  Its API sets stricter conventions on how an app should work, but with those limits comes the benefits of simply getting things done and the ability to focus on the grander issues – like interoperability and bleeding edge features.  In the Linux world there is an amazing freedom of choice, but with it comes chaos and a lot more work that goes toward just getting things to talk to one another.  While the freedom is nice, sometimes it’s nicer to work within stricter guidelines and get something done quickly.

Happiness

A book I still have to read is [ed. I think it was called] The Science of Happiness whose author was interviewed recently on NPR.  The interviewers discussed the emerging branch of psychology that is studying happiness.  It got me thinking about how perceived happiness is a major market factor and how people now days are more willing to pony up extra cash and make an effort to buy your product or service if it causes them some happiness beyond the satisfaction of having a need met.  

There are so many examples of this:

Apple is the most obvious candidate.  Sure, you can buy and build a computer using the same parts Apple does for half the cost.  You can install Linux for free or pay for Windows and get your work done.  Why are people paying more for Macs?  The Mac OS and Apple’s software suites offer a more user-friendly and, ultimately, satisfying experience.  Apple’s users (like me) are happier.  

37 Signals recently posted about Zingerman’s deli in Ann Arbor and the philosophies they follow that make them a great company.  Yes, you pay $20 for a reuben and a root beer, but the experience of going to the deli outshines many other casual eating experiences.  Customers are showered with free samples of exotic foods and the staff are very personable.  The selection of products is also far beyond what you’d find in many other places.

This also brings to mind Ruby on Rails.  There are plenty of other MVC frameworks out there that do the same exact thing as Rails.  But there are so many positive externalities that Rails offers that put it above the rest: the community, the Ruby language itself, and the way agile development is baked into the framework and its related plugins.  It really makes for a pleasant development experience.

The bottom line is that Americans are becoming more willing to pay for products that make them feel better.  This has positive repercussions where a product can benefit the natural environment or society as a whole.  The challenge is to build a brand that offers that extra bit of happiness and (ideally) really does change the world for the better.

Industrialization and Web Development

On my way down to Illinois today, I listened to a podcast giving an overview of American history before 1870.  In it, Dr. Reilly talks about the industrial revolution.  I was enthralled as I contemplated the changes that the revolution brought about and the similarities to the changes taking place in web development.

In the 1800’s manufacturing moved from a guild system toward the use of unskilled labor and interchangeable parts.  Under the guild system, an apprentice would live and work for a master tradesman who provided food, shelter, and training.  Goods
were produced from start to finish by a single tradesman. Volume of production was limited and a great deal of skill was required of the tradesmen, who needed to have a holistic understanding of the products they produced.

The guild system remained primarily because it was most economical to have a local tradesman produce goods.  It was too costly to import goods from across a continent.  Once canals and railroads provided cheap freight services, it became economical to produce a high volume of goods and ship them to distant customers.  Thus, the need for mass production arose.  Instead of hiring ten times more tradesman to produce ten times more products, it made more sense to hire unskilled workers to perform specialized tasks, thus “pipelining” the production process.  Tradesman began to take more managerial roles, training the unskilled laborers in their specific jobs.

At the same time, the idea of using interchangeable parts arose.  With interchangeable parts, it was much easier to repair and maintain products.  Before the revolution, a product was custom made and its design was known intimately by the tradesman who made it.  If it needed to be fixed, the best person to fix it was the one who made it.  With interchangeable parts, a product’s parts could be easily replaced if broken and could be repaired or maintained by anyone familiar with the industry.  Furthermore, a factory producing widgets can make the widget almost completely out of interchangeable parts produced by other companies.  No specialized knowledge of how each part is made is required.  The factory can simply make new widgets out of preexisting components.

The industrial revolution was a drastic change for the tradesman who were accustomed to the old guild system.  The tradesman who prided themselves on quality (and high wages for specialized work) strongly opposed the revolution.  They considered the mass-produced goods to be inferior to their custom, hand-made products.  They formed unions to try and preserve their wages and job security. But ultimately, mass production won out and in many industries completely replaced the guild system.

So how does this relate to web development?  In many ways there has been an “industrialization” of how web applications are developed.  In many cases today, web applications are (or have been) written by one or a few programmers who are intimately familiar with their custom implementation.  If a programmer leaves, the web development company is in a bit of bind because knowledge of all of the intimate details of the system is lost and a great deal of time is required for new programmers to wrap their heads around the system in order to maintain or improve it.  Over the past seven or so years, there has been a trend toward specialization of work and an increase in the use of libraries, code generators, and frameworks, similar to the idea of interchangeable parts. 

Prior to our current days of web 2.0, the only division of labor that normally existed was between graphic design and programming.  As web applications have become more complex, many companies have moved from hiring jack-of-all-trades web developers to hiring specialized Flash developers, UI developers, database developers, and server-side develoeprs.  Companies seem to care more about whether a programmer is intimately familiar with J2EE or DOM scripting rather than a holistic understanding of web applications and computer science.  To run with the industrial revolution analogy, it’s like an employer who is more interested in how well a worker can operate a welder, rather than being able to build an entire car by hand.

Libraries, frameworks, code generators, web services, and mashups can be considered the “interchangeable parts” of the web.  As long as an unskilled programmer knows a specific framework, say CakePHP, he can jump into any CakePHP project and easily maintain it. Not as much specialized knowledge about the application is needed compared to a custom-written, classic PHP site.

While there are similarities between the effects that the industrial revolution had on industries like blacksmithing, shoe making, and automobile making, and the effects of industrialization on web development, there are some differences.  While the industrial revolution nearly completely replaced tradesmen with unskilled workers (and even robotics) in industries where simple products are produced, it has not replaced tradesman in every industry.  For example, in most cases skilled contractors are still needed to build houses and large buildings.

As I see it, there are currently three types of web applications being produced today.  The first type is the static, informational web site.  There’s not much for a programmer to do here.  Most of the work is for the designer.  At one time, someone who knew HTML was needed, but apps like Dreamweaver have replaced that need.  The second type is the CMS-style site that might have news, events, subscriptions, or blogs.  These sites used to require dedicated developers, but now packages like Drupal, PHPNuke, and wikis have replaced this need.  Some companies still develop these type of sites from scratch, but as customers become more educated and competitors outsell the custom shops with prepackaged CMS systems, the custom-designed CMS site is a dying breed.  The third type of web app either has complex business rules or it stands on the bleeding edge of technology.  These type of apps will need developers, but not necessarily the “jack of all trades” developer.

On the one hand, it is comforting to know that, at least for the time being, there is a need for skilled developers.  The web development guild system hasn’t yet been eliminated by unskilled labor.  However, it is a bit disturbing to see companies move toward hiring specialized developers who are “intimately familiar” with specific languages or platforms, rather than
developers who have a holistic understanding of web applications.  In addition, many companies are hiring programmers with little skills to churn out sloppily-coded applications.  What is a “craftsman developer” to do?