Setting Up a Ruby on Rails Development Environment

All you need to start building Web applications using Ruby on Rails is:

• Ruby
• The Rails framework
• A relational database (MySQL, PostgreSQL, and SQLite are supported, out of the box)
• Your favorite text editor

Now, when I spent most of my time writing code, my favorite editor was vi. I learned to love vi, and I was very proficient in using it for development. It was simple, fast, and transparent. These days, I squeeze my coding time into a few hours a week, if I'm lucky. As a manager, I have seen the productivity improvements that come from using IDEs like Eclipse and Visual Studio .NET, along with the rich complement of plug-ins that are now available. So, rather than dust off my vi skills, I decided to base my Rails development environment on:

• Eclipse
• SubVersion
• The SubClipse SubVersion Client Plugin for Eclipse
• The Ruby Developer Tools Plugin for Eclipse
• The Web Developer Tools Plugin for Eclipse

Some other motivations for choosing Eclipse include:

• It's free!
• I'm planning on evaluating a Java-based architecture shortly, and Eclipse is probably the de-facto IDE for Java development.
• I'm planning on evaluating a LAMP-based architecture shortly, and there are PHP, Perl, and Python plugins available for Eclipse. No matter which 'P' I end up using, I should be covered under Eclipse.

I started with a step-by-step article called Setting up a Rails Development Environment on Windows Using Eclipse, by Brian Hogan. The article covers everything you need to do to setup Ruby, Rails, Eclipse, and the SubVersion plugin for Eclipse. It literally eliminated what I can only guess would be days of learning by trial and error! Thank you!!!

I found another article on the Ruby on Rails site about How To Use Rails With Subversion. It's concise and includes valuable guidelines for what parts of the Rails environment to place under source control.

To test everything out, I built the sample application described in Rolling with Ruby on Rails, by Curt Hibbs. It's the perfect guide, if you're like me and just want to dive into something new, without a clue of what you're getting yourself into!

In all, it took me around two days of effort to find and read all of these articles, install MySQL, setup my development environment, build the sample application, and commit everthing to SubVersion.

Architectures that Enable Velocity and Agility

No business leader will argue that their company needs to move slower or become less responsive to change.

Adapt or perish, now as ever, is nature's inexorable imperative.
-- H.G. Wells

In theory, software is a fantastic environment to build things that are designed to adapt to changing needs. Compared to brick and mortar, software is relatively maleable. The cost of making even major changes to software is relatively low.

Unfortunately, too much software is not explicitly designed with change in mind, resulting in systems that quickly become brittle. Some of this is due to lack of attention; some is due to architectures that aren't designed for change.

I plan to spend some time exploring some contemporary architectures for Web-based applications in terms of their ability to support changing requirements throughout the application lifecycle. For each architecture, I will evaluate the level of available support for practices like rapid prototyping, continuous integration, and test-first development. I will also explore the architecture's support for separation of concerns and its performance and scalability characteristics.

I'll start with Ruby on Rails. Ruby on Rails has been generating quite a bit of buzz with its claim of improving developer productivity by a factor of 10 and it's recent Jolt Award. I will also probably look at Java, .NET, and LAMP, since they are so commonly used. No promises, though; some of this will depend on how much time I will actually be able to devote to this exploration!

Next: setting up my Rails development environment...

Etymology of Technology

Greek tekhnologia, the systematic treatment of an art or craft
The American Heritage® Dictionary of the English Language, Fourth EditionCopyright © 2000 by Houghton Mifflin Company.
Published by Houghton Mifflin Company. All rights reserved.

Zen and the Art of Software Development

I first read Zen and the Art of Motorcycle Maintenance, by Robert M. Pirsig, almost twenty years ago, before I got involved with computers. I just finished re-reading it and found new relevance to the Art of software development.

While Pirsig weaves together many themes, one thesis is that we do not exist in a dualistic world of mind and matter or subjects and objects. Rather, there is a third entity, Quality, that is independent of the others.

We recognize Quality when we see it, but we cannot define it. We can only describe attributes of subjects or objects that provide evidence that Quality was present during the creation process.

Gumption is the glue that connects one with Quality and ensures that the objects that we create manifest our connection to Quality:

Gumption is the psychic gasoline that keeps the whole thing going. If you haven’t got it, there’s no way the motorcycle can possibly be fixed. But if you have got it and know how to keep it, there’s absolutely no way in this whole world that motorcycle can keep from getting fixed.

So what do Quality and gumption have to do with software development? Without them, you can't build great software. The trick is to start with plenty of gumption and control for everything that tries to take it away.

A gumption trap... can be defined as anything that causes one to lose sight of Quality, and thus lose one's enthusiasm for what one is doing.

Pirsig goes on to elaborate on several, common gumption traps, which he classifies into setbacks and hang-ups. I'll paraphrase and elaborate to connect Pirsig's examples from motorcycles to the computer world.

Setbacks consist of careless mistakes, intermittent failures, and parts problems. Anyone who has been around software for a while has deleted a critical file on a production system or broken a piece of code that used to work. Those are careless mistakes. Troubleshooting mysterious problems that do not appear to fit any pattern is also common. Integrating third-party components that are too expensive, aren't compatible with the rest of the system, and/or don't work as advertised is par for the course.

Hang-ups can be further broken down into value traps, truth traps, and muscle traps. Value traps consist of rigidity, ego, anxiety, boredom, and impatience. Truth traps basically involve being trapped in dualistic yes/no logic, and not being able to see the value outside of clear yes/no answers. Muscle traps consist of inadequate tools, bad surroundings, and something Pirsig calls "muscular insensitivity."

I had some trouble mapping muscular insensitivity to the software world, where there are no threads to strip and finely machined surfaces to damage. I liken muscular insensitivity to understanding the subtle characteristics of a system and its sensitivity to changes.

The software world talks about things like process, methodology, and best practice as ways of ensuring quality deliverables. These are really tools to help keep you from loosing gumption, and therefore help you from loosing sight of Quality. However, if you don't have sight of Quality in the first place, all of the processes and best practices in the World won't help produce great software.

Adding RSS Feeds to Blogger: Part 2

After implementing my del.icio.us RSS feed in both AJAX and Feed2JS, I decided to conduct a little bake-off between the two approaches:

• AJAX version
• Feed2JS version

Did you notice any difference in user experience? If so, which one do you prefer and why?

The AJAX version is based on sample client and server code that I downloaded (see Part 1 for references). I cleaned up the code a bit and added simple caching to the PHP-based proxy. Feel free to download the code and give it a try! You'll need a server than can run PHP - it uses CURL to make HTTP requests and it needs to read, write, and delete local cache files. Unzip the files to a directory on your server, change the rss_feed variable in index.html to point to delicious_proxy.php, and you're good to go!

Feed2JS is a free, hosted service that packages RSS feeds in JavaScript, which can then be included in any Web page, using an HTML <script> tag. You can also download the PHP code and run Feed2JS on your own server. Getting a feed to show up on my site couldn't have been more simple: enter some parameters, copy and paste a little JavaScript, and presto, the feed appears! Defining styles to seamlessly blend the feed into my site was a bit more complex for me, but for someone who is more hands-on with CSS, it should be a snap!

Both approaches are very easy to implement, but with zero technical footprint required, Feed2JS has to win, in terms of simplicity.

Adding RSS Feeds to Blogger

Blogger is very cool! It's just so easy to setup a nice looking site, manage your content, and tweak your template until everything is just right.

Once I decided to resurrect this blog, I looked at my templated and decided to spice things up, a bit. In particular, I really wanted to make my links dynamic, so that they would automatically reflect my current interests and areas of research. Luckily, I already have this content on del.icio.us. The question is, how can I get it to automatically update in my sidebar. Adding an RSS feed from del.icio.us was the obvious answer. You can see the results on in the sidebar, on the right side of the page.

I started by looking around Blogger for the ability to add RSS feeds to my blog from the Settings tab. Imagine the ability to go to "RSS Feeds", add a feed by entering a name, a link, and a number of items to display, and having the feed show up in a pre-determined area on my site (e.g. the sidebar). No such luck.

My next thought was to find client-side solution to displaying a third-party RSS feed in Blogger. I found two general approaches: an AJAX-based solution and an on-demand JavaScript-based solution. I chose the AJAX solution. Why? I really wanted to play around with AJAX. I will probably end up giving the on-demand JavaScript approach a try, as well.

A quick search produced an article from AJAX Magazine about how to build an AJAX-based RSS reader, complete with sample code. Testing and fine-tuning the sample code on my local computer was a breeze and I was consuming my del.icio.us RSS feed in minutes.

However, when I plugged the AJAX code into my Blogger template and previewed the page, I received error messages... an no del.icio.us feed. What happened?

I soon discovered that for security reasons, the JavaScript XMLHttpRequest object, on which AJAX is largely based, is only allowed to make calls back to the originating domain. I read some of the debate about whether or not this security measure makes sense. But all debate aside, I just wanted to make my feed work!

I searched again and found a great article on XML.com that outlines three approaches to working around the originating domain limitation in the XMLHttpRequest object.

• Write a proxy that runs on the originating domain that can be invoked by XMLHttpRequest (requires the ability to run scripts on the originating domain)
• Use Apache mod_proxy (requires access to the Apache httpd.conf file)
• Use on-demand JavaScript that can be invoked using an HTML <script> tag, bypassing the XMLHttpRequest object, alltogether.

Since I already had an AJAX RSS reader and I could only access a limited set of PHP functions on my host, I chose to write a proxy that can be invoked by the XMLHttpRequest object. A few more minutes, thanks to the sample code in the article, and my del.icio.us proxy was working!

It's a bit slow, since I haven't thought about caching the feed, either in the client or the proxy. Next, I'll add some simple caching to the proxy to test performance. I'll also test Feed2JS, a free, hosted on-demand JavaScript solution to embedding RSS feeds in Blogger.

Changing directions

Ok, so it's been a year since I last posted anything here. Please accept my apologies. I had the best of intentions when I started writing about global software development. Then I got very busy doing things that had little to do with global software development. Not a good mix!

Moving forward, rather than focusing on just one area of technology management, I have decided to write about whatever I am working on at the time. My goal is to provide myself with a narrative of projects, solutions, situations, and interesting areas of research that I encounter along my travels.

If anyone other than me reads this stuff, please let me know what you think!

Thanks!