GrokBlok

As you might know, I’ve been spending a lot of time at work writing some dashboard-type applications using _whytheluckystiff’s Camping Framework. I’ve been experiencing some incredible productivity gains by prototyping with this very small framework, and I think I’m only just beginning to realize exactly how much. I’ve recently undertaken rewriting one of these dashboards in Rails.

The Camping Application

Several months ago, I was tasked with providing some statistics on budget and project management performance for senior management. The maturity of datasources wasn’t very good, many of them were excel spreadsheet laden with macros, access databases, and csv files from 5 or 6 datasources. To further compound the problem, these datasources weren’t always in a consistent data format, so I made the design decision to just create a simple CRUD interface to manually enter the data. All compilation would be handled outside the application for the time being. The benefit of this approach would be that eventually, I could turn the data entry over to someone else.

I developed this solution over the course of about 2 weeks, working on and off until there was a format visually appealing to all parties. I wrote the most basic tests possible using Topfunky’s Mosquito Testing Framework. This solution worked until the application needed to be expanded to the entire organization, not just a subset. It was time to move to Rails.

The Rails Application

In addition to changing the domain to fit the entire organziation, I really wanted to have an extremely clean interface for someone else to enter the data. My goal was to have someone else take over entering the data, and I would just be responsible for the support of the application. Rails also gave me an opportunity to more easily explore automating some of the data entry.

In 2 days, working on it for 8 hours a day, I’m 90% complete, including adding the additional models and unit and functional tests. I realize that it’s a small Rails application, but now if there are enhancement that need to be made I’m on a much better platform.

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |   560 |   395 |       8 |      49 |   6 |     6 |
| Helpers              |    20 |    19 |       0 |       1 |   0 |    17 |
| Models               |   152 |   130 |       7 |      18 |   2 |     5 |
| Libraries            |    14 |    11 |       0 |       3 |   0 |     1 |
| Integration tests    |     0 |     0 |       0 |       0 |   0 |     0 |
| Functional tests     |   434 |   342 |      14 |      63 |   4 |     3 |
| Unit tests           |   745 |   565 |       8 |     154 |  19 |     1 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  1925 |  1462 |      37 |     288 |   7 |     3 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 555     Test LOC: 907     Code to Test Ratio: 1:1.6

So in proper enterprise +3/-3 format, here are some observations…

Eagles

• My models are almost an exact copy from Camping, with more validations and a couple of additional models that I needed to add for the extra functionality.
• I already knew the domain of what I needed to create so any reworking could be accomplished on the first pass with Rails.
• I already had lots of good data to use for Rails development as I just pulled fixtures down from the Camping app.

Turkeys

• I miss clean view syntax of Markaby in Rails. I realize that I could use Markaby, but if support for this application eventually gets turned over to another group, I thought that the barrier to entry would be lower for the JSP-style syntax of ERB templates.
• I had to manually copy and paste a lot of code from one Emacs screen to another. There was rumored to be a gem that would transistion a Camping application to Rails, DeCamper, but I couldn’t find any code that had been released. This bears further research.
• Rails migrations and Camping migrations aren’t very similar, and I wanted to have the cleanest Rails application possible. I reworked the models enough that it just didn’t transfer very well.

Summary

I’ve been in too many situations where I work on things for too long only to have the organziation go in a different direction. Using Camping to prototype before moving on to Rails gets something for my users to react to before I’m too invested in the outcome of my work. When, and if I do need to move to Rails, the transition is seemless and probably cuts down on the total time to get a finished product into production. I’ve been very pleased with this approach, but I think I can reduce the turn around time even further. I think some possible options would be to use ERB with Camping or Markaby with Rails. Also, I think I should have perhaps gone to Rails a few weeks ago, but time was just too hard to come by. The next time you come across a situation that warrants creating something of immediate use that may or may not be thrown away after an initial pass, you should think about this approach.

It’s that recently there has been a lot of interest in communicating with people through Internet Relay Chat, or at least in the corner of the internet that I frequent. I think it’s a really flexible medium that lends itself to instant collaboration. One of the areas that I think it could bear much fruit is in the way of online help.

That’s one of the reason’s that I suggested starting the #columbusrb channel. Think of it this way, if you are not working in an all Ruby shop, how do you get your help? Mailing lists? Blogs? These are all valid, but sometimes, there’s a more immediate need for help. I envision #columbusrb to be a place where people can come to for help, it’s my effort to help spur the community on to larger growth. If you work in a large company, and you’re trying to bring ruby in, look to some of these channels for instant help.

Do take the time and check out some of these channels, my nick is ch0wda, which is an obscure Mayor Quimby reference from a Simpson’s episode, if you must know. I plan on posting some more about IRC in the coming weeks.

• #columbusrb – Home of the Columbus Ruby Brigade
• #camping – Devoted to the greatest 4KB MVC framework on the interwebs, Camping
• #rails-contrib – Follow along as patches and tickets get worked on the Rails Trunk
• #midwest.rb – A great collection of Rubyists from all over the Midwest dedicated to helping each other out.

• #merb – A lot of really cool work is going into this framework of Mongrel + ERB
• #jruby – Many people keep a watchful eye over how this project is turning out
• #emacs – The IDE that acts as an operating system
• #ruby-lang – Discuss your favorite language

Some of you might know that I recently started working at Cardinal Health, which may or may not seem relevant until you realize that Cardinal is #19 on the Fortune 500. Taking that in conjunction with the fact that I worked at JPMorgan Chase & Co. for 5 years and they are listed at #11 on the Fortune 500 and I feel comfortable in saying that I know there is a spot in all enterprises for Ruby and Rails. I’m finding that decision makers are more open to open source, more open to going outside the enterprise comfort zone, and more open to selecting the solution is is done the quickest, with the most business value, and meets their needs the most.

So, what am I doing? In short, I’m helping technology leaderships make the best investment decisions, while becoming an industry leader, not an industry follower. I’m proving to them that you don’t needs teams of consultants or a pricey support contract to business value out of the data that your organization holds. I’m proving that Ruby belongs.

Rails at JPMorganChase

At JPMC, I led the team that created the 1st fully-supported and fully-funded Rails application inside the bank. Of course, things got complicated because we had to work with other technologies and people who weren’t receptive to Ruby, but that’s the real trick anyways, isn’t it? In 3 short months, we went from discussion and a single SVN commit to an application with a user community in excess of 10,000 people. We were hooked into the global authentication system, and living like good citizens of the enterprise application community. The benefit is that now people can more easily get access to the revenue generating systems and spend less time just sitting at their desk when they start new (which was the basic premise of the application that we created).

I’m a little unfamiliar with the current status of the application, but the current project lead, John Andrews has taken the ball and run with it. The user community continues to grow and the application continues to morph and integrate and become fully assimilated within the JPMC universe. One of JPMC Retail banks lead architects, who is a Smalltalk developer at heart is very interested in Rails and has been suggesting it to other teams in order to help him make a strategic decision. It could perhaps become as ubiquitous to them as Java or .NET. The part that I’m most proud of is that 1 year ago, there were no full-time Ruby/Rails jobs at JPMC, today there are 3, and that’s a great thing for the community.

Ruby at CardinalHealth

At Cardinal, I’m doing something that I think is even more edge-leading and innovative. I’m in the process of deploying several small Camping apps, which work together to create a dashboard of information for IT leadership to make investment decisions. It’s the simplest possible thing that could be done. I take several ruby scripts that use active record and I pull data, manipulate it into something a little more friendly and then load it into an SQLite database that my applications use. I’m not tied to the system of records, but since these data mover scripts are called from cron, they’ll give a very accurate depiction of the environment. I plan on blogging about this idea further.

What is the effect? In short, it’s been marvelous. I’ve done in several weeks something that probably would have taken much longer to do in other frameworks. It’s exactly what the decision makers needed at the time, no more, no less. The first taste has been enjoyed, and now they want more. Ruby has been established as a tool that gets things done. This will place dynamic languages into conversations in team AD team meetings where previously they would not have been. I’m really looking forward to extending on the work that I’ve started there.

Exhortations and Encouragement

If you are looking to try to get Ruby or Rails in the door at your job, take heart, there is a bright future on the horizon. Eyes are opening, discussions are being had, and Ruby is finding itself in some of the most unlikely places. What can you do? You can look for opportunities to present themselves. Start small, write ruby scripts instead of bash scripts for some automated tasks. Use ruby to parse files that get data moved from one system to another. Prove to your boss, and their boss that not only is Ruby an incredibly beautiful and capable language, but it’s also one that will provide them the quickest business value in their toolbox.

I’d like to announce the release of my first contribution to the open source community, Fosterite. This plugin fills a need that I’ve had in my last 2 jobs. I’ve deployed Rails apps in 2 large companies where I’m not allowed to have direct access to the database or the a login to the production server. Frustration abounded since I was responsible for the stability of said application. I’m not going to go off on a Dennis Miller Rant here but let’s just say that sometimes large companies aren’t the smartest.

What it is

This plugin is a generator that will allow you to do some very “crude” administering of your application from a web interface. Install the plugin, generate a model and controller, and hook it up to your already rock solid authentication system and you’re ready to rock. See instructions below for the full install.

What you can use it for

You can execute queries directly against the database. (Be careful!) You can also run rake tasks. (YMMV) Finally, you can just get some information about the environment that your application lives in.

Where you can get it

ruby script/plugin install fosterite http://svn.devjavu.com/grokblok/rails/plugins/fosterite
ruby script/generate fosterite MODELNAME [CONTROLLERNAME]
rake db:migrate

$APPLICATION_NAME = "[Insert your app's name]"

$LOG_PATH = config.log_path

For those that can be bothered, navigate on over to the Trac for more instructions and support.

Where I hope this is going

You can read about additional planned features on the wiki page. Something that I hinted at there, but haven’t put a lot of thought about is being able to restart your application from the web. Currently, if you had a rake task that would restart your mongrels or really any app server, I think it could be done, but you wouldn’t ever receive a response back. My line of reasoning is taking me down the path of perhaps using BackgrounDRB to pass the restart request to and then at least your could return a response before restarting.

Why would you want to do this? Well, say for instance you are at work and a rails security notice happens and you absolutely have to update to the latest tag. You’re somewhere that doesn’t allow SSH access, how would you currently do this? You couldn’t.

Useful Links

• Home http://www.grokblok.com/projects/fosterite
• SVN: http://svn.devjavu.com/grokblok/rails/plugins/fosterite
• Trac http://grokblok.devjavu.com/

...it[Rails] can have a dramatic impact on the speed at which a Web development team is able to build and maintain enterprise Web sites and applications.

The emphasis in the quote is mine, and I think it’s very telling that Rails is being billed as an enterprise solution for companies because of it’s speed and maintainability. That pretty much sums up my experience with Rails thus far, and I think the first fruits of early adopters are starting to be harvested. Being a member of the second wave, I feel that I’m in a great position to be able to speak with authority on ways to ease Rails in the door at large corporations.

Equal parts design philosophy and development environment, Rails offers developers a few key code-level advantages when constructing database-backed Web applications.

If you are running or working in a large monolithic corporation and you’re not at least evaluating Rails’ position in your company, why not?

It’s really old news, but my coworker, Dan Manges and I were featured on the Official Ruby on Rails podcast. This was a great opportunity to showcase for the Rails community some of the cool things that we’re able to do inside the bank. You can download the interview directly from here.

Last Monday, Dan Manges and I gave a talk at the Columbus Ruby Brigade about some techniques for bringing Rails into the enterprise. I believe that there are 2 ways of doing this. The first is attempting to make Rails a little more “enterprisey”, and I don’t mean sacrificing a lot of the things that make Rails great, but modifying some of it’s behaviors, such as support for composite keys and that type of thing. Basically, all the things that Dave Thomas talked about at RailsConf this year. The second approach is a bit more subversive, and that is to make the enterprise environment a little more Rails-like. It’s culture changing, and that’s what we focus on. This is the approach that would appear to be favored by DHH. I think both ways are valid because they have the same ends, just different means. Each situation is different and this approach works for us at JPMorganChase. So without further ado, here are the slides from the presentation, and I hope to have a podcast of our presentation edited by this weekend.

UPDATE The podcast is now available.

• PowerPoint: crb-enterprise-rails.zip
• Podcast: crb-enterprise-rails-podcast.mp3

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.

This message was posted by my company’s CTO this morning on the corporate internet, accessible to over 100,000 employees. The names and stats have been changed to protect the innocent.

We continue to see the four pillars – - client focus, speed, efficiency and delivery – - paying dividends in our organization.

Josh Schairbaum & Dan Manges engaged these precepts in their recent efforts on the IT web tools project for Production/ Operations and Risk Management. They have done an excellent job in delivering quality with speed.As a follow-up to their experience in developing the daily snapshot to our production and operations performance via the Production Site, they were asked to use their development skills to bring life to our Risk Management Agenda with core metrics. For the Risk challenge, Josh and Dan took the approach of “convention over configuration” to achieve speed in developing the web-based Risk Metrics Site with “Ruby on Rails” on a Linux Sever. Josh and Dan’s efforts tracked the amazing progress that the Risk management accomplished over the last 45 days.

Josh & Dan will continue their efforts through our web strategy in 2006; however, the biggest priority on their plate will be the Supersecret next application that is targeted for September 30, 2006. Great job to both teams!

Needless to say, I’m pretty pleased about the progress being made. Some of you might ask why the big deal about Linux? Well, it’s the only one in the environment. :) I also had another article posted on the intranet about how I keep my inbox clean. I promise to make another post sometime soon concerning our adventures with Rails.