Thursday, November 12, 2009

Ruby on Rails and Enterprise Architecture

As I stated in earlier posts, I am a fan of RoR and enjoy building web applications with this cool framework. I am constantly learning new features and am usually surprised by the structure and simplicity of the architecture that constitutes a Rails app. Rails is an excellent solution for building a web app that requires database support, period.

However, a business website rarely stands alone. An e-commerce site, for example, can be 100% Rails for all the user-facing operations, but once the user has filled in a shopping cart and has provided his payment and shipping information, the transaction moves into the fulfilment phase, which usually means passing the captured order off to some existing order fulfilment system, such as an ERP or some crufty old accounting system written in COBOL.

More to come...

Tuesday, August 04, 2009

Cities I have visited







Sunday, April 13, 2008

Cabin off-the-grid

Our family has had a cabin in the Sierra Nevada mountains since 1974. The location is a beautiful valley, 13 miles from the nearest town, and at 6000 feet elevation. The cabin itself is "quaint". It was originally built in 1908 as an ice cream stand on a dude ranch. Over the years, the owners added a kitchen on the front and a bathroom on the back, making the ice cream shack into the only bedroom. Our family added a living room wing and an outside deck.

The old cabin is sinking into the ground a bit more every year. The snow load is intense, and the old log and rock foundation is just getting lower and lower, which means that the floors have humps in the center of the rooms. We have discussed how to remodel the cabin, but each time we discuss it, we just come to the conclusion that there is little we can salvage. Better to start over.

So, we found a set of plans we liked, and a company that would supply all of the materials needed to build the cabin on a foundation that we provided. All we had to do was find a local contractor willing to provide the labor to do what was needed to get us to the point where we have a weather-proof shell before snowfall. It is April, so that sounds easy enough.

We finally found a local contractor, after going through the local phone book and talking to about a dozen prospective contractors. Five of them actually looked at the site and the plans. Two made bids about twice my estimate, two wanted to propose a cost-plus deal, while one came in with a bid that fits my budget. I checked his references around town and made a deal with him. He got his crew on the job when he said he would and did a very professional job.

The project was not without its warts though. The structural engineer did the snow load calculations (150 lbs per square foot!!) and specified that rafter spacing should be 12" between centers. Nobody told the people who loaded the trucks because I got just half as many rafters as required. What's more, a somewhat complicated roof section over the deck just could not be assembled with a 12" rafter spacing, something the structural engineer didn't even consider. The contractor is a professional and he simplified the roof design to make it perform better in a heavy snow-load environment.

The cabin project had its over-runs due to missing material in the kit, and due to the requirement for expensive earthquake tie-downs which were not in the original bill-of-materials. We also added a side porch with a roof, which also bumped up the costs.

We made our completion date before the first snows, the crew completed the exterior siding and wrapped up the project on Dec 3, 2007. Next spring we get to work on the interior and the solar power system.

In May 2008, we made it back into the cabin, since the snow was finally off the road. The cabin was structurally sound, but the roof had taken some damage. The chimney had been tipped over by the snow load, it seems the snow diverter I had requested installed did not get done. It will require a completely new set of stove pipes. Sigh.

The roof was also damaged on the other side of the cabin, where there is a gable extending out from the main roof. It looked from the ground that somehow snow and ice had got under the metal roofing and had simply peeled some of the metal off, leaving torn panels. Serious problem. Later in the summer, we got the roofer out to fix the roof, and he did a complete inspection. The results were surprising. The roofer found deep scratch marks on the metal roof, and it is now clear that the damage was due to a snowmobile driving up the valley between the main roof and the gable, and then sliding down the other side of the gable, putting the deep scratches in the roofing.

Now this roof is over 12 feet above grade on that side, so there had to be over 12 feet of snow in the yard to allow a snowmobile to get up there. I have seen 8 feet of snow in the yard in years past, but this is a new one on me. I guess I will just have to put a No Trespassing sign on a tree, at about 20 feet up! Either that or put concertina wire around my eaves.

Friday, January 11, 2008

Ruby-on-Rails, the appserver for the rest of us.

Ruby is a wonderful language, but a language in and of itself is not a solution. There needs to be well designed frameworks provided so that developers have a model to work from and extend. I had learned about the Model-View-Controller paradigm during my Smalltalk period, but noticed that even the adherents to the idea often violated the principles, adding business logic in a view object and so forth. Enterprise Java developers had a fairly clear model with the Enterprise Java Bean, but the using of servlets as controllers and Java Server Pages as views wasn’t backed up by a proper set of tools to keep things straight. I saw a lot of business logic embedded in servlets, and even in JSPs. When working on MS-Windows projects, developers routinely stuffed monolithic blocks of code into Window procedures, making some of the ugliest, hardest-to-manage code ever written. The lesson here is that MVC is a great idea, but requires a well-thought-out framework that supports and enforces separation of code and concerns within the framework. Ruby-on-Rails (RoR) is that framework.


Like the Programming Ruby book, I found Agile Web Development with Rails to be an outstanding text, full of good humor and good sense. The Rails framework is very elegant, a wonderful piece of design and implementation.

In my opinion, RoR is what Java J2EE could have been, if it hadn't been bloated by big corporations throwing their weight around in standards committees. There just doesn't seem to be a reality check there. Who really needs all that complexity? Too many features were added in order to achieve competitive advantage over another high-tech rival, and not the needs of the customer.

My colleague and I have built and deployed several RoR applications so far. Nothing terribly complicated, but complete 3-tier applications that accept input, store data into databases, support a wide variety of query and reporting operations, and look pretty good too. My admiration for Ruby-on-Rails increases with each project.

Programming in Ruby

I heard about Ruby in 2004 or thereabouts. I think there was an article on OSNews.com about it. I am a fan of object-oriented languages, having written my first Simula program in 1975, and I like typeless languages like Smalltalk, having used Digitalk Smalltalk on several projects in the late 80s. So Ruby looked interesting. I downloaded the compiler and bought the “PickAxe book”, Programming Ruby. I enjoyed reading that text like it was a novel. I found it engaging and a real page turner. I played around with the language, but didn’t have any real opportunity to apply it, since I was working for IBM as an Enterprise Architect.


We were promoting Java, J2EE, EJBs, Message-Driven-Beans, Enterprise Service Buses, web services, WSDL, and all the other stuff that IBM was out shoving down the throats of its enterprise customers. And I was helping, standing by with a glass of water and an explanation when a customer’s system choked on one of our latest offerings.

With the advent of Service-Oriented-Architecture, I thought that we had reached a tipping point in the complexity of our product offerings. There were very few customers who could absorb all this complexity, and in fact, they didn’t need it for about 90+% of their problems. We were focusing the big-guns on solutions that might reach 10% of the market.

There had to be a better way: Ruby-on-Rails

SWAN2B, a 1976 GMC motorhome

So, you might ask, "What is a 1976 GMC motorhome anyway?" Good question. Most motorhomes of that period were based on a standard truck or a van chassis. Motor in front, rear-drive. The living area made out of aluminum trailer material attached to a frame of wooden 2x2s, perched on top of the high truck frame. The construction technique did not hold up over time, they have a real tendency to leak, and it is nearly impossible to repair any damage in that flimsy structure. Very few 70's vintage motorhomes survive.

The GMC is very different.

The drivetrain of is based on the front-wheel drive system that GM developed at that time, and it is basically the same as used in the Oldsmobile Toronado, Buick Riviera, and Cadillac Eldorado.

The use of front wheel drive made it possible to build a motorhome that is not nearly as high as those that have a driveshaft running underneath. The floor is just much lower, requiring only a single step to enter. The skin of the GMC is done in aluminum, built much like an aircraft with aluminum skin riveted to aluminum ribs. The end caps front and rear are large fiberglass moldings.

I lusted for a GMC when they were new, but they were out of my price range, so I settled for one of the 2x2-aluminum things. Maybe they would get cheaper as they got older.

Well they did get cheaper, and they got older.

I finally bought my coach in 2004, and it was cheap. It was also a basket case.

I called my basket case 'SWAN2B', since the ugly duckling could become a beautiful swan, given enough time and money.

I did a complete mechanical rebuild. Engine, transmission, cooling system, brakes, suspension, wheels, and tires. A lot more than I had budgeted, to be sure.

Then came the exterior. I thought I would get the mechanicals done (focus first on Safety and Reliability), then I would work on the interior (plumbing, electrical, carpet, upholstery, etc.), and finally, go after the exterior (body repairs, new lights, windows, windshield, wipers, paint job). My spouse had other priorities. She just could not stand the way it looked, so the exterior had to be done before the interior. The majority of the exterior work is done, the paint job is cool, and all the leaks have been repaired (well, maybe most). The interior has a new water heater, lights, carpet, and some new upholstery. Still more to do.

I have never really attempted a major rebuild like this has turned out to be, but I am happy with the results thus far.

Virtual Machines

I have been fascinated with the idea of virtual machines since I first heard about the concept in the late 60s. I think it was the University of Michigan who modified an IBM 360/65 and made it capable of running multiple isolated program spaces on one box. They called it the 360/67 CP-CMS, and it became the basis for the new 370 line introduced a few years later. Virtual machines were in the domain of mainframes at that time, and it was impossible to visualize that I would be using the concept on my laptop 30 years later. Who knew?

In my work as an architect and presenter for IBM in the 90s, I had the need to have access to the latest web application server product we were selling. These were huge cranky beasts that often corrupted the operating system when they were installed. One version used DCE as a transport protocol, and that thing had the nasty habit of locking up your computer if you changed the timezone. Since I traveled constantly with my trusty ThinkPad laptop, I could not afford to have one of the early WebSphere installs screw up my critical presentations, contact, and email. So, I started playing with VMware workstation.

I think the first version of VMware I used was 4.5.x. I managed to host a Windows NT guest on a Windows NT host, and thought I had really accomplished something! In fact, the limits of memory (I had my laptop maxed out to 1GB) limited how big a VM I could deploy before page thrashing set in, and therefore limited its usefulness. Nevertheless, I knew that VMware was on to something.

When I retired from IBM, I decided to acquire a big desktop system to experiment with. I got a dual-core amd_64 box with 4GB of RAM and a 300GB sata drive. Add a decent video card and wide-screen monitor, and I now have credible Linux-based host system, which can support multiple VMs simultaneously. And it rarely pages to hard disk.

I also experimented with various open-source virtual machine monitors, such as Xen, Virtual Iron, VirtualBox, and KVM/Qemu. For various reasons, I found all of them lacking in some respect. Some just didn’t support the network card I have, some could not provide peer networking, some were so badly documented that I gave up in disgust. I settled on VMware Workstation 6.x because it is stable and it has a good set of features that make playing with VMs enjoyable. I am a advocate of open-source software, but in this case, the proprietary product has set a standard that the others have not yet met.

I maintain two VMs, one the latest Ubuntu, and one Windows 2000, as template systems. If I decide to build a new VM for some specific purpose, I clone it from one of the templates. This saves a lot of setup and configuration, and it gives me confidence that my test environment is stable.

I have found that not all Linux packages uninstall cleanly, often leaving cruft lying around after uninstalling. That is not unique to Linux, of course, but it makes installing and testing complex software sort of like climbing out on the wing of your airplane to service the motor. Things can go very wrong, and you could lose access to irreplaceable data and spend countless hours rebuilding systems if you are not careful. And, in my opinion, backups are not a sufficient safety measure.

So, my solution to that problem is the VM sandbox. I spin up a VM, give it a unique hostname, and voila, it is another peer workstation on my network, with access to data on other servers in my subnet and access to the internet in general. Now I can go ahead and download and install new packages and test them. If they prove useful and of general utility, then I promote them to the template system. If the package disappoints, I can always blow the sandbox image away and try something else.

Virtual machines are also very useful while building web applications. You can set up a VM to be the web server, another as the database server, and several more as mid-tier application servers. They all run as peers on the network and allow sophisticated testing in close-to-real-world environments.