WindyCityRails News

Chat it up with Obtiva at the Obtiva Coding Dojo

2010-09-03T11:05:07-04:00

WindyCityRails is just over a week away, and we’ve been busy planning for the Obtiva Coding Dojo!

What conference doesn’t have an IRC channel? They always do. For this year’s Obtiva Coding Dojo at WindyCityRails, we’d like to build our own chat server using Redis and Rails 3. We’ll have the basics going before the first attendee arrives and we’ll let everyone know where they can go to hang out and chat in our sleek little Campfire clone. There will be two general types of projects to take on. For those seeking something involved we’ll have cards to develop new features for the chat client. For others seeking something light and fun we’ll have a number of simple chat bots you can build. I’ll talk about each of these areas in more detail.

Client Improvement

Ryan and I will be working throughout the day to improve the chat client with anyone who wants to stop by the Dojo and lend a hand. These stories will be more involved and take a little bit longer, but you’ll have a greater opportunity to pair with us and dig into Rails 3. Here’s a few of the features we’re planning to build:

Avatars
Show bot functions outside the chat room
create / join different rooms
Include images
Abbreviate long posts

Of course, you’re free to come up with your own ideas. We’ll help you build it!

BYOB (Build Your Own Bot)

Chat bots are fun little projects, most of which can be put together with little time commitment. As a bonus, you’ll be able to work on your bot from anywhere in the conference. Of course, we’d love it if you wanted to hang out in the Dojo room with us! Here’s a few ideas we’ll have cards for:

AI bots have a “conversation”
Math bot
Google feeling lucky bot
Google Image search bot
Bash.org quote bot
“Insultor” bot
IMDB bot
rubydoc bot
The DHH quote bot

We’re really excited about this Dojo, and I hope you are too. It’ll be a chance for attendees to clock some time with Rails 3 as well as explore the NoSQL landscape with Redis. Folks who aren’t participating in the Dojo will get to see the application evolve throughout the conference and interact with bots other attendees have built.

We look forward to seeing you at the Obtiva Coding Dojo! Get your tickets today if you haven’t already registered for WindyCityRails.

Implementing a TDD Process in a Legacy App

2010-09-03T11:00:57-04:00

My tutorial at WindyCityRails this year is about implementing a TDD process in a legacy application. But before you start working in a new application, you need to do an inspection, so that you understand the basic structure of the code, get a sense of where the weak spots are, and some idea of how the various pieces interact.

This kind of inspection can have a lot of different goals, but normally you are looking to get the thing running, and get a general sense of just how good or how awful the previous coders were. In a consulting practice, you may be asked to do this kind of an inspection before you put together an estimate for future work. (Or worse, you may have to do this kind of inspection after you’ve already done and estimate. This always reminds me a little bit of those home-flipping shows when the new buyer starts tearing out the drywall and discovers the lost colony of termites.)

Version and Plugins

The first thing I do is usually a quick glance to check what version of Rails the app runs under. Not having a vendor/rails or other lock to a specific Rails version is a negative mark. (At least in Rails 2. In Rails 3, I’d use the Gemfile to catch the version of everything. Of course, your odds of a legacy Rails 3 project at this point are pretty slim.) I also check to see what other gems and plugsins are installed, as that’s usually a pretty good high-level guide to what the functionality of the application is – ActiveMerchant implies e-commerce, for a simple example.

Tests

The first place I go in the actual code is the test suite. It’s often a much better indication of the quality of the entire code base than the application code. If the tests are poor or nonexistent that’s an extremely worrisome sign. Nonexistent is easy enough to spot. The worst case is a test base that’s was half-heartedly kept up, because it often won’t run.

Checking the quality of passing tests is a little more difficult. Lack of coverage is a nicely objective metric, although presence of coverage doesn’t necessarily mean good tests. Very long test methods generally indicate to me that TDD was not followed in the creation of the app, and that the tests are likely to be brittle and not map very well to the actual logic points of the system. It’s also common to see a lot of repetition in tests – often developers don’t spend as much time cleaning up test code. Again, that’s sign that future maintenance is going to be difficult.

rake:stats

Somewhere around here I usually fire up rake:stats just for the heck of it. I don’t put a whole lot of stock in it – it can be easy to fool. But a 1 - 0.2 test/code ratio is a red flag.

I also look at the ratio of controller to model code. Again, I don’t take it too seriously, but I’d rather see more code in the model then not.

If I’m feeling very ambitious, I try to install metric_fu, which gives a much truer picture of the quality of the app. The various best-practice parts of metric_fu are worth skimming, but there are often a lot of false-positives in there. I make it a point of going through the flog scores, which are a reliable guide to where the scariest code in the system is hanging out.

Run the App

At this point, I usually try to run the app. In theory, if the tests run, then the app should run. But, well… If there’s a Capistrano script, that often has some hints about other dependencies or quirks. Data is also another problem – some apps require some basic data in the database, often semi-static data like category names. If the code base doesn’t have a setup for this in the code migration, sometimes it’ll be in a rake task. Sometimes a snapshot of a real database will be made available, obviously that’s helpful. This step is less important in the inspection process than you might think, but if getting the thing up and running is a total bear, that generally means that there’s a lot of hidden scary stuff.

Application Code

Now it’s time to search the app directory. The first part of this is just opening each file. This is the kind of thing you could almost do with the font size way down… I’m not so much trying to understand the details of the code as the shape of it. A lot of small classes, or fewer, larger classes? How long are the methods? A lot of long methods really scare me, especially in conjunction with minimal unit tests. More subjectively, does the layout look sloppy? Are there coding constructs that indicate a Ruby-specific style, or does everything look like translated Java? Is metaprogramming used where appropriate? Is there code in the controllers that should be elsewhere? Are the views too knowledgeable about the rest of the system?

Through that quick glance I identify the most interesting bits of code, and then I go back to them in more detail, asking questions like: Can I understand what this is doing? Is this the best way of doing it? Is there an obvious time or space inefficiency? Does the design make sense?

Configuration

The config directory is usually my last standard stop. Destinations here include the Capistrano deploy script, it it’s there, any other configurations of interest (like an Amazon S3 setup). The environment.rb file is another good place to look for configurations, and you can’t overlook config/initializers – it’s a good place to hide dependencies and monkey patches that you might overlook.

The routes.rb file will give some ideas about the site in general – it’s the Rosetta stone between URL and controller, and it’s common to have to dig here to figure out what’s going on if the routing is at all complicated. It’s easy for this file to get out of control if nobody is paying attention, so it can tell a lot about the general nature of the programming team. A lot of additional methods added to a RESTful controller, for example, which might not be the best design solution.

In the end

At this point you should have a general feel for the quality of the code, and if not a complete understanding of how every piece interacts, at least a sense of where the trouble spots are going to be. If the answer is “everywhere”, double all your estimates…

Learning More

To learn more, be sure to register for Noel Rappin’s tutorial, Testing in a Legacy Environment.

Getting Started With Ruby on Rails

2010-09-03T11:01:20-04:00

Powerful Framework. Lots of Information

Ruby on Rails is a powerful web framework. It’s popularity has spawned an ever-changing, ever-growing ecosystem around it: blogs, documentation sites, screencasts, GitHub repositories, books, eBooks, training classes, mailing lists, IRC channels, and more.

And yet, despite this flood of information, the one thing that should be easy to do is often the hardest: getting started.

Making Sense of the Information

If that describes how you feel about Rails, then you’re in for a treat at WindyCityRails this year. The Getting Started With Rails workshop is geared for all newcomers to Rails, and provides a friendly, casual, beginners-only setting. While most workshop attendees should have a basic understanding of Ruby syntax, we won’t assume any advanced experience with the Ruby programming language, and certainly not with the Rails framework.

In about two hours, we will step through a comfortable, fun tour of many of the foundational concepts in Rails: from routes and actions, to forms and models.

So if you’re new to web programming, or if you have previously worked with .NET/Java/PHP and really want to get started with Rails, this is your chance. You’ll be in a roomful of beginning Rails students, in an interactive environment, getting familiar with

What Will I Learn?

By the end of this workshop, you’ll have a solid start with Rails, and confident that can learn the next steps on your own.

Intro to HTTP concepts, and what “REST” is all about
How to route a URL to your web page code
How to use the built-in code generators
How to embed Ruby code into your HTML templates
Introduction to understanding templates, partials, and layouts
How to use a database inside your application
Understanding the heart of Rails: its MVC architecture
How to write web services with Rails
Tips for debugging and using the Rails console
Recommneded best practices for all Rails developers

What Version of Rails Will I Learn?

We’ll be demonstrating the latest pre-release version of Rails 3.0 (RC1 at the time of this writing), so you’ll be ready for Rails 3.0.

Do I Need to Bring Anything?

You can come and watch the demonstrations and learn a lot; or bring a laptop if you prefer. If you bring a laptop to try some things out during class, be sure you have a proper installation of Ruby 1.8.7 and Rails. For step-by-step instructions on how to setup Ruby and Rails on Mac or Windows, we’ve created a workshop preparation guide for all attendees.

Regster Today!

Seating is very limited. Register today to secure your spot!

WindyCityRails 2010 Schedule Expanded!

2010-09-03T11:01:35-04:00

Great news! We’re happy to announce that Ryan Singer, lead UI Designer at 37signals, will once again be speaking at this year’s WindyCityRails. Ryan is planning an engaging talk on designer-developer interaction.

WindyCityRails will now feature seven full-length regular sessions, an hour of lightning talks, and the Obtiva Coding Dojo. In addition to Ryan’s talk, we’ve got great talks planned by Jake Scruggs, John McCaffrey, Kevin Gisi, Nick Gauthier, Les Hill & Jim Remsik, and Yehuda Katz.

In honor of our expanded schedule, we’ve decided to extend early bird registration by one week! You can now save $80 on your WindyCityRails registration through August 11, 2010. Register today.

Last year, Ryan spoke on UI Fundamental for Programmers. Here’s a video of that talk, in case you missed it:

UI Fundamentals for Programmers by Ryan Singer from ChicagoRuby on Vimeo.