New gem: greatest_common_factor
Ruby already provides the ability to find the greatest common factor (gcf) of two integers. What if we could determine the greatest common factor across a whole array of integers? Now we can.
I’ve just released greatest_common_factor on github.
Here is a sample of what you can do with it:
Enjoy!
Transparency, Responsibility, Accountability
Kent Beck speaking at RailsConf 2008. I think this is the most interesting and poignant presentation of the year.
statulo.us - how getting fit somehow still involves programming
First, David Heinemeier Hansson spoke of the surplus. Spend it on yourself, he said. Invest in you.
What does that mean to you? How do you interpret that? Jamis got into woodworking. Somebody else is playing the banjo. The ukulele perhaps? “Get out of your editor”, David said, and I somehow quickly forgot about that part.
When I heard David talk about that surplus, I could easily identify. I felt like a race car driving on city streets. I had more to give, but coudln’t find that perfect outlet. I spent a while digging into new technologies instead. I worked with git. I dug deeper into Ruby and Rails. I read classic programming language textbooks. Essentially, I did what I always do.
Then I went swimming. On a trip to Tahoe in early July this year, my family and I were at a pool when I heard a lifeguard shout something I hadn’t heard in years. “Adult Swim!” Sweet! The kids hopped out (mine included) and I decided to do some laps. The last time I swam laps in a pool, I was more concerned with Merit Badges than ROIs. Perhaps unsurprisingly, I sucked. I did two down-and-back laps in the olympic pool, and came up sucking wind like an idiot. I tried to reconcile my embarassment by thinking about the altitude. Sure, swimming at 6k feet may be a little harder than sea level, but yours truely was out of shape!
I’m an emphatic person. I do something emphatically, or not at all. If I was going to attempt to attain personal fitness, I was going to have to do it right. There are all sorts of paths. My friend Shawn is running a marathon. I could run to the edge of my driveway if my house was on fire, but I don’t think that marathon stuff would work for me. All the stuff I saw in traditional gym settings seemed lame. Use a stationary bike with a sweaty guy shouting at me over lame techno music? No thanks. I needed something intense and exciting. I needed something fun. This would fill my surplus.
What I needed, as it turns out, was to be Crossfit. I reconnected with a friend from high school who had spent some time as a Navy Seal. He was into this “Crossfit” thing, so I had to check it out. I won’t attempt to summarize for you, but do yourself a favor and check out that main website. Crossfit is intense. It’s exciting and it’s incredibly fun.
I found a local crossfit gym and signed up for group classes. I’ve also converted half of my garage into a reasonable home gym, but the intensity in the classes is what it’s all about! During my first class, we did a Crossfit named workout, and everyone was jotting down their times in a notebook. A notebook. The paper kind. See, Crossfit workouts are timed, because slow workouts are less efficient and do much less for your body. With timing being key, folks keep workout journals on paper, on the Crossfit forum or on their own blogs.
Opportunity was knocking. The thought of writing my workouts down in a notebook gave me the kindergarten willies, and using a forum or blog had their own set of problems. What was my last time for Fran? How much have I improved in the last month? It was all lost in paper or pagination. Lame.
Here I was, trying to fill my surplus by getting out of my editor, and my fitness choice led me right back in. My wife was going out of town for a weekend, so I had two solid nights of hacking available. Constraints are wonderful. I jotted down some ideas during the week, checked out some graphing libraries and got a general idea of what I wanted to do.
After two nights of hacking, the first version of statulo.us went live! I’ve added several features since, and have accumulated a reasonably sized user base, primarily from my local gym. The weekend project was such a testament to Rails, enabling a reasonably interesting web application, using graphs of user generated data, some RSS feeds and plenty of Crossfit-specific features.
The best part, though, is that by giving back to the Crossfit community immediately after jumping in, I get back that much more from them. The feedback on statulo.us has been great, and has brought me closer to my trainers and fellow Crossfiters.
This path of personal fitness has no end, and I’m looking forward to continuing my newly minted active lifestyle. Especially now that I know it also involves programming!
Check out statulo.us, the free Crossfit-based fitness tracker. Maybe you too will fill your surplus, and be all the better for it.
New gem: rails_framework_diff
It started on twitter:
It’s amazing how hard it is to find problems when caused by developers incorrectly modifying framework-generated files. - Chad Fowler
i’ve always wanted to write a rake task to diff framework-generated files against their generated default for that very reason. - Brian Doll
I would install that gem/plugin if you released it. - Chad Fowler
I had been looking forward to writing another gem ever since reading the Building a gem with BDD article in the initial issue of The Rubyist. In that article, Jamie van Dyke mentioned a gem called Mr. Bones for creating gem skeletons. It differs from other similar solutions in that it’s just a generator and does not insert itself as a dependency on your gems.
The problem is simple enough. The rails command builds a project skeleton which includes many key files. If those files are modified incorrectly, lots of badness can happen. Since they are automatically included in all rails projects though, they can look innocuous when auditing or reviewing a rails project. When they are the culpret, you’ve likely spent hours and hours reviewing eveything else first.
Now, with rails_framework_diff you can quickly see a diff against the rails framework-generated defaults and those corresponding files in your project. Nice and easy, nice and quick.
I should also note that without github, not only would the process of releasing a new gem into the world take a whole lot longer, it certainly wouldn’t be as fun. This gem was conceived, developed and released on a major gem server in under two hours. Awesome.
Deep Send: How to wrangle with large object graphs and come out alive
In a perfect world, all of our objects are small, orderly and well defined. They encapsulate data that is semantically obvious and easy to work with. And then… in an obvious homage to Jack Handey, we attack that world with large, complex and ugly object graphs, mostly the result of monolithic integration technologies like SOAP.
Sure, with gems like soap4r, the pain of dealing with SOAP is somewhat minimized, but at the end of the day, you’re still going to have to look deep into the eyes of a huge object graph, and get at the delicate properties you so covet.
What if we were able to reference deeply nested properties from within the bowels of these large object graphs, as easily as we could with neat and orderly objects? How nice would it be not to have to repeat yourself while asking the object graph to cough up two properties buried thirty chained-methods deep?
Deep Send
This is so simple it feels like cheating. The deep_send method could be attached somewhere high up in the SOAP hierarchy if you wish, but I like having it available everywhere.
As you can see, deep_send works like the regular send method, but takes chained method calls as arguments. Let’s see how this might work in a sample SOAP client:
In our example, we have a method appropriately called get_nasty_graph. Let’s assume this invokes a SOAP service method and returns all of it’s enormous goodness. We could write a million methods in this class to pull out a few related elements to make a reasonable API. The problem with this is that you’re always wrong. There is always a reason to pull out three of these properties and two of those, and your API just won’t accommodate. If an object needs to use two different API methods to get all that data, it may result in two SOAP calls, which is surely no good. Using that magic get method now allows us to construct our own method to pull out exactly what we want. Nothing more, nothing less.
Encapsulate, you must!
If we stopped here, we’d end up painting ourselves in a corner. Requiring the users of your SOAP client to know about the deep recesses of your nasty object graph is just bad manners. It’s also a leaky abstraction, so stop it!
Now that we’ve defined a few constants, the clients of our SOAP client can use our magic get method, without knowing how horrific it is to get at those name properties.
Gotcha! Order thy calls!
You may have noticed that rescue NoMethodError bit in our magic get method. Choosing to implement that method in this way is not without it’s faults (ha!). If you passed in a method chain that resulted in a NoMethodError being raised, you’ll need to decide what to do. In this example, I’ve chosen to swallow it and return what I got so far. This means that the order of your method chains is significant, if there is a higher likelihood that some of them will occasionally go missing. Isn’t SOAP marshaling awesome? You may decide, of course, to rescue the error, call the authorities and raise the threat level to red instead. Good luck with that.
