Jake Scruggs

We've been having some Oracle deadlock issues that have been hard to reproduce locally. After a lot of investigation and solving of important problems that happened not to be THE problem we figured out that while we've been pretty good creating integrity constraints in the database we have not been very good about making sure that every foreign key has a corresponding index. And that can lead to problems. So we had a situation were our documents table had a foreign key on the accounts table that was not indexed. So updating an account row lead to a whole table lock on documents (instead of just a row lock which would have happened if there was an index) and that was very bad when we had two separate processes where one was doing a bunch of accounts stuff and the other was doing a lot of documents stuff. Deadlocks for everyone! The sad thing is that if we had just drank the Rails cool-aid about having no integrity constraints in the db we would have been fine but we got into ...

Last night Matz gave a keynote entitled "Why do we Love Ruby?" He talked about how Ruby embodies Quality Without A Name (Qwan). Here's a description of Qwan . I think it might be time to retire this talk, as I've seen it more than a few times before. I'd much rather hear about interesting problems he's solved while designing Ruby or meditations on where the language is heading. A humble suggestion from a guy who's very grateful for Ruby. TDD: More than just "testing" - Evan Light Evan started out his talk by pointing out that lately we've been focusing more on tools and techniques more than the goal of testing. Testing is not the end, it is a way to help you get to the goal of a well designed application. He did a live BDD coding demo - which is very courageous. I've seen way too many presenter's brains melt under the hot lights and audience pressure. He managed to pull it off and show some Behavior Driven Development. Evan likes to ...

Agile's Too Slow: Developing a Facebook App for the Obama Campaign - Andy Slocum Andy worked on the Facebook application for the Obama campaign. In two months they build a Facebook app that could assist users in encouraging their friends to register and vote. There where only two people on the project and they came in with the common ideas of XP: continuous integration, weekly iterations, story estimates, developer testing, etc. Except that all of the above was way too heavy for the Obama campaign's pace. They'd have an Iteration planning meeting on Monday and by the Tuesday it was out of date because so much had changed. Also Facebook apps don't really run very well outside of Facebook so they could only write tests around code that was completely isolated from the Facebook stuff. So they basically moved to a lean process with priorities set at the standup meeting every day. They also ditched the idea of continuous integration as there were only two people to int...

It's been 5 years since I attended the granddaddy of Agile conferences and I have to say that the first day was damn good. My notes my be a little rough, so I apologize in advance, but if I don't type and post them on the day I pretty much never will. Workflow is Orthogonal to Schedule -- Mary Poppendieck Mary started out with an example of on time development from 1929: The Empire State Building. In September of 1929 they started cleaning the constructions site of previous buildings and by May 1st of 1931 the building was finished and open to the public. It was exactly on time and 18% under budget. Cash flow was king: Every day of construction was another day before they could start getting their money back. How did they do it? They focused on flow. They thought of the project as "A marching band going through the building and out the top." Key success factors: The owner, architect, and builder got along well and worked as a team. They had a deeply experienced ...

Lately I've been working with this guy Felix who likes to rip the application into shreds when confronted with a problem. Initially, it's a bit scary. I know we have source control and we can get it all back, but ripping out large crucial swaths of code just seems so violent and yet it's a pretty effective strategy. On this one project we've had a problem for well over a year of our tests not rolling back the database after each test. We've got all the configuration set up for that to happen, but it just doesn't and nobody could figure out why. One of the problems is that this is a Rails application that is 2.5ish years old and serves millions of users every day. So in order to make that happen back in the early days of Rails we had to extend and modify a lot of the Rails framework. Apparently one of those modification broke the mechanism for rolling back the database after every test. Not rolling back the database means that one tests creation/updating of...

Last night I chose quantity over quality and ate at a Brazilian steak house. Good times. Webrat: Rails Acceptance Testing Evolved Bryan Helmkamp (weplay) Bryan started out his presentation by handing out Tylenol for those who went out last night and Budwiser for those who didn't. The crowd was appreciative. Bryan show some typical Rails integration testing (simulating clicking through the app without opening up the browser) and compared it to the same test in Webrat. The difference between the integration test and the webrat enabled test was pretty dramatic. The Webrat test was much cleaner and easier to read. Webrat parses the returned html with Nokogiri (which he highly recommends) and so can do some pretty interesting stuff. click_link, fill_in, check (and uncheck), choose, select, attach_file, and click_button all have a simple syntax. Webrat automatically is checking for the success of the request so you don't have to assert success everywhere. It also verifies t...