Utili-Tool, A Camping Application

Posted by ch0wda on April 10 2008 at 11:24 AM

Something that I use everyday that I’ve just released for public use is the Braintree Tools Site, which is just a Camping application frontend to the Braintree APIs. It’s also a simple collection of tools that will help you figure out if your ‘hashing’ is correct and what response look like. It’s kinda like a sandbox, but you don’t need to go so far as to write your own script. You can just do it from the web.

There is certainly truth in the statement that the best tools are created by the people who actually use them. A major part of my job at Braintree is to ease the task of integration for our customers. I come into contact with people who are using everything from Ruby on Rails to customized PHP to Oracle Forms. The nice thing about our API is that it doesn’t matter. You’re simply making HTTP GETS/POSTS to interact with the Gateway. For me, customer support at it’s most basic is just typing a query string into a browser address bar and looking at the response.

Prototyping with Camping 2

Posted by ch0wda on September 06 2007 at 03:50 PM

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.

Polymorphic Camping

Posted by ch0wda on June 08 2007 at 12:21 PM

For one of the projects I’m doing at Cardinal, I’m using a polymorphic association. The nature of Camping is to write terse, yet simple code. For example, creating a new record in a controller is normally done in a one-liner, like so:
1
2
3
4
5
6
7
8

class Add
  def post
    @person = Person.create(:name => input.person_name, :age => input.person_age)
    redirect R(List)
  end
end
  

Here’s something that I got caught up on for 20 minutes this morning. When adding polymorphic associations, make sure that the [polymorphic name]_type field includes all the namespace information. Here’s an example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# models
def Person < Base; has_many :addresses, :as => :addressable; end
def Address < Base; belongs_to :addressable, :polymorphic => true; end

# relevant portion of the views
...
label 'Type', :for => 'addressable_type'; br
addressable_select("addressable_type"); br
label 'person', :for => 'person_id'; br
person_select("person_id", @people); br
...

# controller
class Add
  def post
    @addressable = Person.find(input.person_id) if input.addressable_type == "Person"
    @address = Address.create(:street => input.address_street, 
                                          :city => input.address_city,
                                          :state => input.address_state, 
                                          :zip => input.address_zip,
                                          :addressable_type => @addressable.class,  #use the class name to get namespace
                                          :addressable_id => @addressable.id)
    redirect List
  end
end


There’s a number of ways to solve this, although I found this to be the simplest for a form where you can select multiple models. The point is to make sure that you have that namespace information in the database, otherwise you will receive “Uninitialized Constant” errors for the addressable class.

Happy Camping!

Gireviks.com, A Camping App

Posted by ch0wda on May 27 2007 at 10:29 AM

If you’re the type that likes to push yourself physically, I can’t say enough about Kettlebells, which are a Russian tool for building strength, agility and conditioning. To picture them, think of a cannonball with an iron handle on one side. I’ve been working out with them for roughly 2 months, and I’ve lost weight, gained muscle, and felt that my overall conditioning has improved. In the Russian culture, kettelbells (girya in Russian) are the most obvious form of strength, much like the old-school barbells with the balls on each end would be here in the United States. Those strongmen who worked out with them regularly were called Gireviks (meaning Kettlebell men).

Currently, I’m working out with the 53lb one, trying to work my way up to 225 One-Armed Snatches in 10 minutes. It’s really difficult, but I’m up to 111, as of yesterday. I like to keep strict records of my progress, and I hate using pen and paper. This has led me to create Gireviks, which is a very small Camping application. It’s less than 550 lines of code, and I think that I can make it ever shorter, with some “condensing metaprogramming”.

I hope I’ll have the time to continue to make this a nice domain-specific app, I’ve got some great ideas for it, but I’ve also got a lot of plates in the air. If you’re interested in learning more about kettlebell lifting, you should read Enter the Kettlebell by Pavel Tsatsouline, and if you’re interested in keeping track of your lifting progress, you should, of course use Gireviks.com.