Capistrano Bliss
Posted by admin in Tech Tidbits on June 12th, 2009
I’ve recently had the opportunity to build an application for a startup using Rails. While this certainly wasn’t my first experience with Rails, it would my first exposure to administering a Rails application in a soon to be production environment. Since I am inherently lazy (like most techies), I wanted to make sure I had an automated process for pushing out changes and re-deploying the application. After all, startups are notorious for rapid fire modifications based upon early feedback loops. This seemed like a great opportunity to try out Capistrano.
Capistrano is a build automation tool, similar to Ant. However, while Ant doesn’t make many assumptions about what (or how) your building and deploying, Capistrano makes a lot of assumptions (sound familiar?). As a result, Capistrano can quickly become the centerpiece of your deployment process. Capistrano leverages SSH to execute remote shell commands on one or more of your deployment servers, checking out code from your SCM (usually SVN or git), managing a directory structure of releases and creating symbolic links to your current release. It will even help you remotely start and stop your app and erect a maintenance page! All of this is accomplished via Capistrano Tasks and Recipes that are scoped by a namespace to avoid conflicts. Of course, you can easily create your own Recipes, but I didn’t have the need in my particular situation. The out of the box deploy script generated by Capistrano for me was more than adequate, although I did make some tweaks (see below) based on the fact that I was using Passenger (i.e. mod_rails) in my Apache configuration on the deployment server. Here is what I had to do to get my new application up and running with Capistrano:
Installation
Installation was a snap. Capistrano is ONLY installed on your development machine. It is a simple gem install:
$ sudo gem install capistrano
...(output omitted)...
Successfully installed capistrano-2.5.5
Setting up my project
Next I navigated to my rails project root and executed the following command:
$ capify .
[add] writing './Capfile'
[add] writing './config/deploy.rb'
[done] capified!
I’ve been capified! Well that wasn’t too painful.
Tweaking for environment
After capification (?) I updated the ./config/deploy.rb file generated by Capistrano. Mine looked similar to this (some values changed to protect the innocent). Note that I also put some nice comment dividers to help organize the information. They are not required:
#############################################################
# Application
#############################################################
set :application, "myrailsapp"
set :deploy_to, "/var/www/#{application}"
set :rails_env, "production"
#############################################################
# Settings
#############################################################
default_run_options[:pty] = true
set :use_sudo, true
#############################################################
# Servers
#############################################################
set :user, "some_user_name"
set :domain, "yourdomain.com"
server domain, :app, :web
role :db, domain, :primary => true
#############################################################
# Subversion
#############################################################
set :repository, "svn+ssh://www.yourdomain.com/repos/myrailsapp/trunk"
set :svn_username, "svn_user_name"
set :svn_password, "svn_password"
set :checkout, "export"
#############################################################
# Passenger
#############################################################
namespace :deploy do
task :start, :roles => :app do
run "touch #{current_release}/tmp/restart.txt"
end
task :stop, :roles => :app do
# Do nothing.
end
desc "Restart Application"
task :restart, :roles => :app do
run "touch #{current_release}/tmp/restart.txt"
end
end
Everything is pretty self explanatory. However, at the risk of pointing out the obvious… In the Application related properties, set the name of the rails app. This name can be anything but it will be used in the path to the deployment location in the next line so you may want to put some thought into this. I set the rails environment to ‘production’. I didn’t mess with the Settings related properties as I knew I would need to execute commands on the remote server as sudo. The server related properties include the user name that will attempt the SSH session. Domain could be something that resolves via DNS or an IP address, of course. I also needed to update the SVN properties with the path to my repository and my username/password.
For the most part, everything up to this point was out-of-the-box. All I needed to do was adjust some user names, passwords, and server paths. The last section (Recipe?) I added to accommodate the fact that I was using Passenger (i.e. mod_rails) on my Apache-based server as the glue between Apache and Ruby/Rails. This is really simple. The namespace used by Capistrano is ‘deploy’. All I am doing is overriding the default implementation of the :start, :stop, and :restart tasks. In the case of Passenger, all that is necessary is to “touch” a special file in the {RAILS_ROOT}/tmp directory called restart.txt. Passenger monitors this file and will reload when it sees that it has been modified.
That’s just about it. Well, almost. You’ll want to perform the task ‘cap deploy:setup’ from your RAILS_ROOT directory (again, on your development machine) first. This will set up a small directory structure under your target deployment location (adding directories ‘releases’, and ’shared’). I had a small problem with permissions on the server so I had to manually SSH to update the file permissions in my target directory (i.e. ‘/var/www/myrailsapp’ directory to allow for writing. That was the only glitch for me and it only had to be done once.
Deployment
Next, I executed the following commands:
$ cap deploy:cold
...(output ommitted) [be prepared to respond to the SSH password and sudo password prompt]...
This launched a remote SSH session, checked out the latest version from SVN, built a new timestamp directory under the ‘releases’ subdirectory and created a symbolic link called ‘current’ to the current release. This way, my Document Root setting in my Apache configuration could simply refer to the ‘/var/www/myrailsapp/current/public’ directory (don’t forget that you need to include the public directory in the Apache config). Future releases could be done with:
$ cap deploy
…from the RAILS_ROOT directory of the development machine and voila. It’s automation bliss. There are loads of out of the box tasks (execute ‘cap –tasks’ to see the full list) to help you in the deployment and management process. A couple that I have been using a lot are ‘cap deploy:web:disable’ and ‘cap deploy:web:enable’. This will have Capistrano put up a maintenance page when you ‘disable’ your website for maintenance and remove it when it is back online ‘enabled’. However, be sure to update your Apache mod_rewrite rules to enable this. Here is what I added to my Apache virtual host configuration:
RewriteCond %{REQUEST_URI} !\.(css|jpg|png)$
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L]
My experience was very positive with Capistrano thanks to the power of opinionated software. Your mileage may vary.
Focus and Discipline == Better Chance of Success
Posted by admin in Business Strategy on May 14th, 2009
Throughout my career I have had the opportunity to work with a number of companies and clients. Early in my career, I earned my stripes working in larger organizations, primarily as a profit center manager in the insurance industry. This provided a perspective on the challenges faced by big companies trying to shave a few points off its expense ratio or steal a fraction of a percent market share from a competitor. Over time, especially as I began to do more consulting work, I experienced life in smaller companies including numerous startups. This is an entirely different world altogether, where survival is often the primary short term objective.
Regardless of the size of the organization, I have observed 2 qualities that significantly increase the likelihood of success: focus and discipline. Others may say “operational excellence” or “people” are the biggest factors in driving success, however my experience suggests these attributes are by-products of focus and discipline or, at the least, difficult to achieve when there is a lack of focus.
Some of the basics I learned at Columbia Business School related to the fundamental discipline of market strategy, often hammered home via writings from Harvard’s Michael Porter. It goes something like this:
- Identify (and validate) a market need for a product or service
- Assemble a set of products and services that specifically address these needs
- Attack the market with unwavering discipline and focus
- After you’ve had a chance to assess the prospects for long term success, re-evaluate and repeat
Unfortunately, most companies skip step 3 or, at the least, compress this cycle into a [almost] daily activity. Usually, the temptation of a prospect with deep pockets or some other distraction will divert the focus of the organization while it branches out into a self-rationalized engagement. Meanwhile, resources of the organization are re-directed away from the original focus, watering down the ability of the organization to deliver best in class products and services to that segment. Unfortunately, saying “no” takes discipline and far too many CEO’s lack this quality in today’s short term world.
Of course, at some point you have to evaluate step 4 above and ask if you are on the right path. However, this should be a rigorous process executed with the implication that a change in course requires a significant investment over an extended period of time. This evaluation shouldn’t occur at weekly staff meetings or in response to a sales prospect that appears on the radar screen and wants something “a little different” than what you offer. If the sales prospect is too large to be ignored, then the organization should decide at that time if this new offering is the better way to move forward and re-channel its energy in this direction. Again, if this is done too often, employees will become confused and frustrated and you’ll have little change of actually developing any intellectual property or expertise.
When we started Kemper Auto and Home in 1996, as a direct marketing subsidiary of Kemper Insurance, we were certain that direct mail was the way to go. After all, that is what we knew and it seemed like a reasonable model if we could keep expenses down. Unfortunately, we learned within the first few months that times were changing and our assumptions regarding response rate were way off. We executed step number 4 at that time and decided to focus on the internet. We invested heavily in the web site, hitting remote rating servers, real-time communication with underwriting agencies, etc. Within 2 years we became one of the leading providers of auto insurance on the web (through relationships with portals such as Insweb). We did a nice job of adjusting course and focusing our energy.
However, we didn’t follow this formula about 2 years later. We allowed the prospect of writing a big chunk of business through an airline carrier affinity relationship to divert our attention. We weren’t in the affinity insurance business (a completely different underwriting and pricing model) and we got burned. We lost focus. It almost brought the company to its knees. Fortunately, we were able to scramble to get out of the relationship and re-direct the resources back to the internet business before it was too late. But it set us way back in our plan and schedule.
This experience had a profound re-enforcing impact on my academic learning. Unfortunately, I see it occur over and over.
Learning Rails – Book Review
Posted by admin in Book Reviews on May 13th, 2009
Okay, so I have to admit I am not entirely a Rails noob. I have built a couple of applications using Rails and continue to maintain an interest in its emergence in the enterprise. However, since Rails 2.x has come out, I’ve fallen a bit behind and needed a quick refresher. Learning Rails, by Simon St. Laurent and Edd Dumbill seemed to be a good candidate. It didn’t disappoint.
Learning Rails is an excellent book for quickly picking up the nuances of Rails, especially if you are looking for something that is an easy read and is based upon Rails 2.x+. The chapters are relatively short and the authors do an excellent job of knowing how far to push a concept before deferring (referring) to alternate texts for more information. Nonetheless, I picked up a few new tidbits along the way, including some practical suggestions for dealing with nested resources and a couple of ideas for routing. However, make no mistake about it, this is not an advanced Rails text. For more detail, I would look into Obie Fernandez’ excellent “Rails Way” or the myriad of books on specific topics such as AJAX, Active Record, etc.
What could have been better? I thought the chapter on AJAX was a bit weak. The example code didn’t seem as elegant as you may expect from a Rails purest. Also, there was not much coverage on the concept of layouts and how the location of the various view pages relate to MVC routing, etc. I suspect even the most inexperienced Rails developer will quickly embrace the idea of layouts and partials (which were covered to some extent in the forms section). Finally, there was not much mention of some of the newer features such as localization (probably more of an enterprise feature anyway).
One thing the author cautioned is that the book is written from the “outside in”. In the preface, this was clarified to mean that the approach taken in this book was to present it from more of a traditional web developer’s perspective rather than, say, an enterprise application developer’s perspective. It was cautioned that certain readers may be turned off by this approach. I suspect that I am likely in the category of enterprise developer since I do think in terms of MVC architectures, etc. My background is NOT in building simple scripted PHP web apps for low budget clients. However, I was NOT turned off by the approach. I thought everything was explained nicely and accurately, regardless of the audience. So for you Enterprise Java purists out there, don’t be put off by the subtitle.
This book is highly recommended for those just starting out in Rails.
Pro Flex on Spring – Book Review
Posted by admin in Book Reviews on May 1st, 2009
I just finished reading Pro Flex on Spring by Chris Giametta (APress). Unfortunately, I can’t bring myself to recommend it. I really wanted to, as I am getting more into Flex and I have been a Spring evangelist since before it was called Spring. My primary concerns center around organization and approach to the example application. I believe these things get in the way of presenting the core concepts.
The book starts off with the obligatory chapter on RIA and introduction to Flex and Spring. This is likely necessary to provide a context. Chris then proceeds to spend a chapter developing a lengthy project plan for the application to be developed throughout the book. This includes project objectives, wireframes, etc. I didn’t mind the chapter except that I was ready to launch into construction at this point. Hold your horses. First there is a chapter on exploring the various tools and means for developing Flex/Spring apps. At the end of the chapter there is a rather awkward lesson on creating 3 different Eclipse projects to hold the client, server (Spring/Hibernate), and library projects. They are rather oddly named but that is a personal preference. Okay now we should be ready to start.
Not quite. There are another 6 or 7 chapters to endure first, including another introduction to Flex applications (am I supposed to be adding these snippets/examples to the projects I just created?). The Flex deep dive gets off on some tangents that I believe would be best left for later. For example, diving into graphic manipulation (Matrix, Graphics, etc.) and skinning at this point is a little premature. I would have focused on the basics, perhaps demonstrating the technique of custom components by overriding a behavior or creating a component that combines a couple of UI widgets. So I am typing along, not knowing if this stuff is going to be used down the line or not, or where the heck I should be saving it.
Next is a chapter on Spring. Again, nothing wrong with Chris’ description. Unfortunately, he starts creating sample applications again. I am typing away thinking this somehow all ties together and if I quit now, I’ll only have to come back later. I don’t have any issues with his use of Spring in the examples, it’s just hard to cover the concepts in such limited space much less try to create a sample multi-tiered application within the same chapter. Again, I would have stuck to explaining the concepts and left the detailed code for the sample application (which I presume we will get to at some point).
Moving right along, we dive into Flex and Spring Integration Architecture. Now we are getting somewhere. This is probably one of the more valuable chapters in the book although I probably could have done without another example (RSS feed reader). Chris does a good job explaining the various means for interacting with the server side. He also includes a nice description of the Spring BlazeDS integration project designed to help simplify the configuration.
Chris then digs into Cairngorm and PureMVC, taking the opportunity to introduce yet another sample application – the Contact Manager. Again, I love examples. However, trying to introduce so many unrelated sample applications throughout the book draws attention away from the overall concepts. There is too much space wasted describing code required to make each example work. After all, once you dive into an example application you have to provide the complete code base or that will create other frustrations.
Chapter 8 is on Data Persistence and Chris feels obligated to describe (with examples) each technology that may be used to access data (iBatis, Spring JDBC, Hibernate, Hibernate with annotations, etc).
Chapter 9 is on Security and this was pretty nice as it focused on Flex integration with Spring Security. However, it did not mention the Spring BlazeDS Integration project and how it helps simplify the communication between Flex and Spring Security. Also, I don’t believe he needed to get as detailed on the implementation of the authentication example. There are simple pre-defined beans in the Spring Security library for facilitating authorization against an in-memory or persistent user directory. Perhaps those would have been adequate enough to explain the concepts.
In Chapter 10 we finally get around to the sample application set up in Chapter 2. The remaining chapters deal with building out various aspects of the example, including the database model, Spring Service tier, presentation, etc. I would say that Chris’ strength appears to be in the presentation tier with Flex/ActionScript. I’m not crazy about some of his design patterns/strategies on the server side. In particular, I have to admit that I never quite embraced his “object identifier” concepts and use of an “assocobjectID” field on every entity table. It seemed obtuse and non-descriptive. I’ve never seen this used in practice. I much prefer for green field projects to stay with conventions such as “id” or “xxxx_id” for the primary key and “xxxx_id” for the foreign key fields in many to one relationships. Anyway, I am picking at straws here.
The bottom line is that I am happy to start seeing books on Flex as an enterprise application technology. Unfortunately, this one makes it a little hard to get to the meat of the content. If you are thirsting for any content on the subject, I would pick up a copy. However, I would focus on reading through it rather than trying to work the examples. You may get frustrated.
Looking Forward
Posted by admin in Business Strategy on April 30th, 2009
Yesterday we learned that U.S. GDP shrank at a rate of 6.1% in the 1st quarter of 2009. This follows a 6.3% decline in the 4th quarter of 2008 and marks the first time since the 1974-75 recession that we saw 3 consecutive quarters of negative GDP growth. Things seem bad all around.
As leaders during this turbulent time it is important to remain focused on the end goal and not become distracted by the “radiation” of the economic slowdown. Sure, dips in revenue make it difficult to imagine launching that new infrastructure project or hiring that new employee. However, while most are hunkered down or retreating in a futile attempt to meet short term budget or executive compensation goals, long range thinkers see this as an opportunity.
Rather than running for the hills, we should be utilizing this opportunity to cut the fat from the organization and reallocate those resources on projects and personnel that will prepare your organization to capitalize on the eventual turn in the market. It will happen, trust me. Someone else in your industry will be thinking this way. If it isn’t you, you’ll become a dinosaur or at least seriously left behind.
As technology executives, we shouldn’t be afraid to let our CEO’s know when we think we are looking in the rear view mirror rather than through the binoculars at the distant horizon. Be proactive in suggesting appropriate savings opportunities, while simultaneous revisiting the CBA (Cost-Benefit-Analysis) for the most promising projects. Be a champion for these initiatives.
Resources migrated
Posted by admin in Uncategorized on April 30th, 2009
I migrated some links to resources from my old blog that some folks asked me to continue to make available. You can view/download these from the resources page.