Archive for the ‘obtiva’ Category

Tools in the Studio

with one comment


Obtiva’s Studio is busy churning out projects and I thought it would be good to let the rest of the world what we are up to. Most of our rails projects are now using CruiseControl.rb, Zentest, restful_authentication, gems, query_trace, attachment_fu, Rcov, redgreen, exception_notification and mocha. While the list may seem long we are always looking for new tools. If you have any suggestions please comment.

As a team we’ve setup growl integrations for cruise, autotest and redgreen which is strongly suggested. Make TDD easier for yourself. As a team we really need to put out a tutorial on how to set all of this up properly. In my opinion you are doing yourself a disservice without them.

A quick side note, grep -r is mostly dead around here due to ack. Try ack, you’ll love it.


We’ve also pushed a lot of our interest into JRuby and Erlang. We are all extremely excited for the opportunities those two tools will provide. JRuby’s memory usage have our mouths drooling. If you are not paying attention to Charles Nutter’s blog you are missing out! The pace of everything surrounding JRuby is astounding. Merb and Sinatra are on our radar.


Joseph Leddy is deep in the bowels of ActiveWarehouse and FasterCSV where he is making millions of SQL rows consumable for our clients. Joseph is also exploring ETL Tool. He’s been aggressively implementing state machines alongside access control also. Tools unique to Joseph are query_analyzer and tail_logs which I’m eager to take a look at. Joseph recently implemented some multi-server file uploading using BackgrounDRB with tests!

Nate Jackson’s work involves sphinx via acts_as_sphinx mashed into will_paginate and aspell. He’s created an intelligent word suggestor for misspelled words and phrases using raspell. Nate spent a day or two scraping the web with hpricot, WWW:Mechanize , csspool and sass. Nate’s also pushing the studio into NetBeans for Ruby, RSpec, Dvorak and Leopard. Nate likes to include svn_tools and dot.rake in his projects.

Dave Hoover‘s working on innovative interfaces with Ajax and BackgroundDRB. Dave has picked up AR::Extensions as a hammer for memory and speed intensive ActiveRecord imports. He’s also weaving together fleximage and attachment_fu in a few projects. I don’t know much about it yet, but Dave seemed please with ZIYA and Flash chart delivery. Dave’s spent some of his time plunging into Sinatra too. Dave’s editor of choice is Textmate. Other things in his camp include: liquid, RedCloth, and chronic.

Dave also released a gem called TamTam using hpricot that will inline css. You can find the gem here. Dave and Nate paired up to create Obtiva’s first OS X widget here. I paired up with Dave to create a rails plugin for TamTam too which is named inline_css.

Ryan Platte has put together some sweet mashups with GWT, AIM Presence API, BackgrounDRb and ActiveScaffold. While Ryan wasn’t a huge fan of ActiveScaffold I was impressed. His editor of choice is rails.vim. For testing he is using UnitRecord to speed up his test suite among its other benefits. Ryan is now promoting the use of factories over fixtures. Ryan and Gareth demoed Ruby Prof to the rest of the studio. Ryan introduced me to the wonderful world of GNU Screen. The little exposure I’ve had to his projects has me very impressed.

Gareth Reeves is doing work in Event Driven Architecture and Event Driven Programming. He introduced me to testing Java with jMock.

I’ve been working with Amazon ECS, Streamlined and a session bridge between rails and Perl’s CGI Session. I strapped subdomain/SEO love onto a project using request_routing, url_for_domain, and acts_as_sluggable. Nate and I pulled ActiveMerchant into a project which was much less painful than expected. If you’re doing complex condition building my tool of choice is condition_builder. I also extended restful_authentication so that it can support authentication for multiple types of users.


Written by syntatic

November 30, 2007 at 9:42 am

Basecamp to Google Spreadsheets

with one comment

After a few months with Obtiva, I’m still happy and I’m bursting at the seams to write about all of the developments happening internally. One development that I can’t keep in is our switch to Google Spreadsheets with a few of our clients.

Traditionally, we’ve used Basecamp for client facing project management. For some projects Basecamp is a wonderful tool. If your client is technically savvy then Basecamp is fabulous, but many of our clients aren’t Web 2.0 compatible. As beautiful as Basecamp’s interface is some of the finer parts are not intuitive to someone who thinks in terms of Web 1.0. The technological rift that Basecamp created was a problem because it required our clients to think and live in our webish world. For some of our clients, who are baby steps beyond e-mail, a draggable editable list is inconceivable. They were intimidated by the complexity and I began to notice the number of days since last login rise past days and weeks until the last login was about a month ago.

Meanwhile, I was using the Stylish Firefox plugin to change some of the terminology that Basecamp uses. I like to think in terms of iterations instead of milstones and the word ‘To-Do’ doesn’t give enough context for an act of work that needs to be done. Our client also had some domain specific language that was causing problems. I was hoping to ease the mental translation that happened every time I logged into Basecamp and keep the language of our projects ubiquitous

As Basecamp usage died, conversations that could be posted in the messages section of Basecamp were being sent directly via e-mail and a client shared an excel spreadsheet that contained all a punchlist of work that should be in Basecamp. Dave uploaded the spreadsheet so that we could all edit the document and suddenly we were working on the same page as our client. I think it’s important to meet clients at their technical level. Thankfully, this client displayed their level of technical expertise perfectly. Spreadsheets.

In the corporate world, the interface overhead with spreadsheets is extremely low since everyone expects the spreadsheets to define themselves in the same way through names columns, rows, and some data. Sales representatives, financial advisors, CIOs, and secretaries can all read and edit spreadsheets with ease. Since our clients are comfortable with spreadsheets they are far more willing to share them. We found out our project spreadsheets were being opened up at many desks around their office. Internally our client used the spreadsheets for project planning meetings and progress meetings. With the documents available to everyone, our work became visible throughout their entire company.

Collaboration is the place where Spreadsheets shine the most. Once the right people have access to the document all at the same time the feedback loop becomes short. Briefly, I’d like to share some of the techniques I’ve used to increase productivity and communication. Take a look at this quickly made demonstration template since we’ll be running through the columns.

Story Spreadsheet

I use On to indicate which part of a project I’m currently working on. When I start a story, I make the On cell green so that our clients quickly spot what I’m working on. Using color instead of words makes glancing much easier for them.

Description and location set the context of the story.

Rank is used by our client to indicate what should be done next. Usually the first story on the list is most important, but our clients have multiple people deciding on the order of importance. Rank gives me the ‘official’ next story while they move stories around.

Difficulty is a quick estimation of how hard the story is when technical difficulty and time to completion are considered. When a new story is on the list I give it difficult so the client can rank with that information.

Completed is filled in the moment the story is done and then I turn the story light orange once that story is deployed to production or staging.

Questions and Answers are a quick way for either party to get details straight. When a new question is entered we highlight it until the other party answers and removes the highlighting.

Iterations are inserted between stories and take up an entire row, which we color light blue to match the Google theme. Matching the color makes it easier to focus on the current iteration.

So far, these few columns with a little color thrown in have a few of our customers feeling like they know exactly what is happening and they are much happier due to that knowledge. The difference between our simple spreadsheet and Basecamp is night and day and I thought you might benefit from that knowledge

Written by syntatic

July 24, 2007 at 10:28 pm

Posted in obtiva, process

Dynamic finders: modifying find_by_id for legacy tables

leave a comment »

One of my projects at Obtiva integrates heavily with a legacy database that isn’t “rails friendly”. None of the primary keys are named id so I use set_primay_key “model_id” all over the place along with some other workarounds.

I ran into an interesting problem when integrating techno weenie’s restful authentication into an existing user model. The plug-in raised an error when trying to run User.find_by_id and logged a no method error. I quickly found that, in their current state, dynamic finds aren’t aware of a primary key being set.

Since Rails advertises itself as opinionated software the behavior makes sense, however if you’re wanting to write highly portable code for say a plug-in when you might want to put a warning in the instructions. Some of your users can’t rely on a standard Model.find_by_id(1).

For the sake of time, I went ahead and modified the authentication plugin, but it would be nice if find_by_id checked for the set_primary_key and changed it to find_by_primary_key before raising an error. On that note, I think I have an idea for my first simplistic rails plug-in.

UPDATE: Instead of modifying the authentication plugin it is probably a better idea to override the find_by_id method in the User class, which would look something like this:

def find_by_id(id)

Written by syntatic

May 23, 2007 at 3:25 am

New beginnings with Obtiva

with 3 comments

My decision to transition to Obtiva wasn’t an easy one. I left a very stable job at Highgate where I would head an ever growing team of developers. In many respects, after a mere two years, I achieved the prize that many developers are striving after.

I had my own office with any equipment I wanted or mentioned. My work hours rarely went beyond forty. My salary steadily increased as I acquired more skills. I was paid to learn at my own pace. But more than all that, I had an employer that cared for me as a person. I was in a family and a family is what I left.

Joining Obtiva put me back at the bottom of the food chain. Now, I’m a green Software Apprentice and it’ll be awhile before I head a team of developers. Instead of leading I’ll be learning. I’ve been demoted.

Why would choose someone that?

First, being the worst on a team of oustanding developers can’t be compensated for with environment, equipment, or money. You can’t compensate for learning next to people who have already traveled the path and know how to avoid the holes on the road ahead. Pairing with great software developers is invaluable. If you’re new to programming and have not had the opportunity to pair then you need to demand the experience.

My first day at Obtiva I talked with Gareth Reeves and he showed me the ropes of rails.vim. One of my long-term apprenticeship goals is to master one of the ‘universal’ type editors inside and out. Right now, emacs and vim are more powerful than my ability to use them. I strongly dislike being the weak one in the relationship. I knew huge productivity gains were dormant in these and Gareth gave me a quick tour of rails.vim’s power. I’m impressed and excited to grow into vim.

Second working at Obtiva, I work with rails. Obtiva offered some of they first training classes for rails development and the continue to stay on the edge. Ruby and Ruby on Rails are a breath of fresh air. My first language is Perl and it has served me well, but I’m happy to say “Goodbye semicolon you won’t be missed.” Rails makes it so web development doesn’t suck, but Ruby makes it so refactoring doesn’t suck. Drying up code is painless and the number of keys I don’t press when writing Ruby is magic. Throw ActiveRecord into the mix and programming stops feeling like programming.

After two days working alongside Dave Hoover at Obtiva’s office. I’m excited again by what I don’t know about the world of programming. More importantly, I’m shocked at how easy software development can become. Obtiva takes best practices and continuous refactoring seriously. I’m beginning to seeing how much these tools can increase your productivity per hour. I’m even more convinced that the “right process will produce the right results” (see TPS).

Writing in Perl much of my programming was about syntax, data structures, and capturing errors. Dave and Rails have a great way of transitioning programming away from the those aspects of software development. The focus of our programming is on proper model relationships and business concepts. The transition is difficult to describe and is sure to be a constant theme on this blog.

Written by syntatic

May 18, 2007 at 4:04 am

Posted in obtiva, programming