JT Hopple - Home

Mysql/Ruby Thread Blocking

2008-06-25T17:48:00Z

It appears that the Mysql/Ruby library blocks all threads for the current process when executing a query. If you are running a multi-process web application this is not an issue, but for a multi-threaded application that has long-running queries this can be problematic.

I have a simple reporting service written with the Merb framework. In Merb you can make it handle multiple requests at once by setting use_mutex to false in the config/merb.yml file. This works great until you have a long running mysql query and it forcefully blocks ALL threads in the process. During this query your Merb app, which you thought was multi-threaded, is no longer multi-threaded.

Comedy

2008-06-11T20:36:00Z

One of my computer science professors at Depauw, Dave Berque, has been a closet comedian for years. He finally stepped up on a real stage. Check it out. It definitely made me laugh!

Passenger / Enterprise Ruby

2008-06-11T20:26:00Z

I finally tried out Passenger (mod_rails) and Ruby Enterprise Edition. Two words come to mind: easy and awesome!

For those of you that don't know, Passenger is an apache module that makes Ruby on Rails deployment super easy in the same way that deploying php can be super easy. You simply point apache at the public directory of your Rails application and you're good to go. Ruby Enterprise Edition is written by the same folks as Passenger and it improves Ruby's garbage collector and memory allocator. They claim that with Ruby Enterprise Edition your Rails apps will use 33% less memory.

I highly recommend checking it out.

Programmer Batting Order

2008-06-10T20:37:00Z

A programmer that I work with did something today that got me thinking about a twist on pair programming. He swept through the application we are working on and cleaned up some little things that have irked him lately. It's clear there are benefits in being a "cleanup" programmer once in a while, but are there benefits to being a "leadoff" programmer? What if we paired up on each task, but not at the same computer and instead in complementary roles -- a leadoff programmer and a cleanup programmer.

The way I see it, the main benefit of pair programming is having two sets of eyeballs on any given piece of code. I've tried pair programming in the past with varying levels of success. There's no doubt that the resulting code is of a higher quality, but it's been my experience that most people have different styles of getting stuff done; and trying to get stuff done at the same computer with another person can be tiring and frustrating. So let's pair up on tasks, but in a specific batting order rather than at the same terminal.

In a baseball batting order there are 9 positions. The first position is called the "leadoff," the fourth is the "cleanup hitter," and the ninth is the "last." In the spirit of pair programming I'm going to skip all but the first and fourth. Here's a brief description:

The "leadoff" batter is usually the fastest base-runner. He bats more often than anyone else and needs to have a high on base percentage so that he can score when the power hitters are up
The "cleanup" hitter (the fourth position in baseball) is usually a highly talented hitter whose job is to "clean" the bases by driving home the base-runners to score runs.

These two roles could work really well for programming. Put a programmer in the leadoff role that is a fast coder. A person that can whip through a task and get it to a functionally complete state. Then, put someone in the cleanup position that can review the task, tighten up the code, and push it out to production. Might work well. You get two sets of eyeballs on the code and the programmers can work in their own way focusing on their role for each task.

I think it would be very beneficial and refreshing to swap roles on different tasks, but I wonder if different programmers would ultimately settle into one position or another. On a given team, I would guess the lineup would become fairly stable after a while.

With a team of more than two programmers, what if you set an order for a given set of tasks and rotated through the line-up for each task? Let's say you had a team of 3 programmers. On the first task, the first batter would be the leadoff and the second the cleanup. On the second task, the third programmer would leadoff and the first would cleanup, and so on... It might be interesting.

What do you think?

Easy Mac Cleaning

2007-07-17T23:03:00Z

Like everything else, computers get messy! Even Macs. However, it turns out there are 3 little scripts hiding in your Mac that are intended to periodically clean your system. The problem is if you use a laptop they probably never get run. They're scheduled to run in the middle of the night and laptops are rarely left on overnight.

Whenever my Mac seems like it's getting a little sluggish I run these scripts. It may all be in my head, but I feel like the system is a bit more responsive after having run them. Here's how:

Open a terminal (for those of you that don't spend your days in a terminal like I do, open Finder, go to Applications > Utilities, and double-click Terminal)
Type:
```
sudo periodic daily
```
and hit return (it will ask you to enter your password).
Type:
```
sudo periodic weekly
```
and hit return (this one might take a few minutes).
Type:
```
sudo periodic monthly
```
and hit return.

It's that easy! If you're interested, read more for quick descriptions of what they do.

Daily

Removes long-lived system log files
Removes temporary junk files.
Removes system messages older than 21 days.
Does some account and security auditing
Rotates Log files
Deletes all system warning and info messages older than a few days.

Weekly

Rebuilds the locate database (this is what causes the weekly task to take a few minutes).
Rebuilds the whatis database.
Rotates the logs

Monthly

Performs login accounting
Rotates Log files

List View Partial Pattern

2007-07-10T16:35:00Z

Most applications display lists of various things and they usually display these lists in slightly different ways. In my opinion, there isn't a one-size-fits-all solution to building these lists, but there is a pattern that seems to work pretty well. It consists of three parts: the list, the list-item, and the item. In addition to partitioning your lists into smaller pieces that are easier to deal with, it also makes it very easy to add both css styling and ajax behaviors to your lists.

The examples below use Ruby on Rails, but this pattern should work for your language/framework of choice. Also, I'm not going to show any of the CRUD controller actions since they should all be very simple and are unaffected by this pattern.

To implement the pattern for, let's say, a people controller, create three partials: _list.rhtml, _list_item.rhtml, and _item.rhtml.

_list.rhtml <%= link_to "Add new", new_person_url %>

<%= render :partial => "people/list_item", :locals => { :person => person } %>

_list_item.rhtml

<%= render :partial => "people/item", :locals => { :person => person } %>

<%= link_to "edit", edit_person_url(person) %>
<%= link_to "delete", person_url(person), :method => :delete %>

_item.rhtml

<%= person.first_name %><%= person.last_name %>

...

Pretty simple partials, eh? You may be wondering what the big deal is. There really isn't one, but here's why I like to use this pattern. First, this pattern partitions your list display into small easy to work with semantical chunks. If you want to change something in the list you don't have to dig through a ton of code, and by using the suggested ids and class names in the markup you can easily style the list both globally for your application and specifically for a particular list id.

Though I recommend always building applications sans-ajax first, this pattern makes it easy to ajax-ify a list without having to refactor the list view. When you want to have your list items fade away when they're deleted, you can simply change the link_to to a link_to_remote (you can do this manually or unobtrusively) and then add a destroy.rjs template to update your page.

destroy.rjs page.visual_effect :fade, "Person_#{@person.id}"

Now, when you delete your items they'll gently fade from the list.

Next, lets say you want to use ajax to create new items. If you add an inline form to your list view that serializes the form fields and sends them to the server via ajax you can very easily have it respond with a chunk of javascript that inserts the newly rendered person, using the _list_item.rhtml partial, into the existing list. Ruby on Rails makes this a snap.

New person form <% remote_form_for :person, @person, :url => person_url do |f| %>

<label for="person_first_name">First Name</label> <%= f.text_field :first_name %>

<%= submit_tag "Save Person" %> <% end %>

Once this form is submitted via ajax, your controller will add the person and then render the create.rjs template in response to the javascript ajax call.

create.rjs page.insert :bottom, "PersonList", :partial => "person/list_item", :locals => { :person => @person } page.visual_effect :highlight, "Person_#{@person.id}"

Again, without having to modify the list partials it was very easy to add an ajax behavior for inserting new items into the list. I'm not going to go into all of the details, but adding behaviors for updating and sorting items should just as easy as creating and destroying them.

Without too much extra effort up front, this pattern will help clean up your list views, make them more maintainable, and will make it easier to add css and javascript behaviors to your lists when the time comes.

:disable_with

2007-03-29T16:11:00Z

About a week ago I stumbled across an option that you can pass to the submit_tag form helper in Rails — :disable_with.

<%= sumbit_tag "Save", :disable_with => "Saving..." %>

Now (thanks to some automatically injected javascript) when you press this "Save" button it will disable itself, change its text to "Saving...", and then submit the form. Cool, right?

Yeah, most of the time it's cool. It's nice to do anything that gives the user an indication of what's going on — especially in a way that prevents them from repeatedly pushing a button on a form that takes a second or two longer than it should.

However, there is one time it's not cool! It's not cool if you have a form that contains more than one submit button and you expect to do different things depending on which button is pushed. A button is simply an input tag just like any other input tag in a form. It has a type, "submit" in this case, a name and a value. The GOTCHA is that, like any other input field, if it's disabled it doesn't get posted to the server. Oooops! So much for using :disable_with on this particular form!

Destroying Models

2007-03-15T16:42:00Z

Surely you use the Rails generator script to create your models! You fill in the blanks in the migration for the new model, run the migration, work on the model and its tests, and then commit to Subversion. Right? And, surely after you've worked on a project for a while you've needed to remove one of these models. You write a new migration to remove the table that maps to your stupid_model and then you...

script/destroy model stupid_model --svn

Ooops! See what just happened?

D         db/migrations/002_create_stupid_model.rb

You conveniently used the --svn switch to delete the files from subversion and it not-so-conveniently deleted the initial migration for the model. It may not be obvious at first, but the next time someone tries to rake db:migrate through your series of migration scripts from start to finish it will fail when it tries to drop a table that never existed in their database (assuming it didn't fail earlier).

This morning I needed to remove a model and rather than doing it by hand (to avoid the above problem) I thought I'd take a quick look through the generator source to see if it would be easy to add an option that told the destroy model script to skip the migration. Turns out it's already there (--skip-migration) it just isn't documented!!

script/destroy model stupid_model --skip-migration --svn

Perfect! However, it might be nice if this were the default behavior...

Monkeycamp

2007-03-04T19:59:00Z

I recently started working on a project that needs to integrate with Basecamp. 37signals provides a ruby script, basecamp.rb, to ease the use of their API, but it hasn't kept up. Specifically, they expanded the API to expose the time-tracking functionality in Basecamp.

Being fond of monkey patching I thought I'd create a Ruby on Rails plugin so I can easily add whatever methods I need without having to alter the actual basecamp.rb file. I'm sure I'll be adding more methods in the near future, but right now the plugin just contains one method for grabbing time entries.

You can grab this plugin from svn:

svn co http://svn.jthopple.com/plugins/monkeycamp

Or, install it directly from the root of a Rails project:

script/plugin install -x http://svn.jthopple.com/plugins/monkeycamp

Check out the documentation for more information.

iTunes Backup

2007-03-04T17:55:00Z

I've been looking for an easy way to backup my iTunes library to an exteral hard drive. Here's a simple solution.

A great day...

2007-02-27T04:15:00Z

Some days are good; other days are great! This day started out like most others except that it was snowing really, really hard. It's actually been snowing quite a bit over the last 3 weeks, but this morning it was dumping. Snow can be a great motivator. Check out this day...

07:15 — Morning coffee with Barclay.
07:30 — Client work: Openmarket Wine
11:30 — Quick PB&J with Barclay... Or, PB&J with Salt & Vinegar chips smashed in side in her case.
12:00 — Gathered up tax information and dropped it at the accountant's (phew!)
14:00 — More client work using Ruby on Rails
15:00 — Teton Pass ...and Clint's cell phone camera.
<object height="355" width="425"><param name="movie" value="http://www.youtube.com/v/0gQjTDw4z6M&rel=1"></param><param name="wmode" value="transparent"></param><embed type="application/x-shockwave-flash" src="http://www.youtube.com/v/0gQjTDw4z6M&rel=1" height="355" wmode="transparent" width="425"></embed></object>
18:00 — Back to work!

Pull My Finger

2007-02-13T05:27:00Z

I just recently finished my first season of broomball — what a fun and crazy game! Running around on an outdoor ice rink in your tennis shoes trying to swat a small ball into a net with a stick resembling a modified broom, playing for a team named Pull My Finger.

I was hesitant to commit when I was first invited to join the team (and nearly quit after minorly injuring my shoulder during warm-ups before the first game), but I'm glad I did and stuck with it. It's been a long time since I've played a team sport — like, since seventh grade little league long — so it was a bit of an adjustment and kind of stressful at first. A couple of games, a few beers, and a handful of goals later and I was over my nerves, having fun, and just trying to help the team get the next win . . . or the next loss as it turned out.

The experience got me thinking a bit about teams and team-work. It seems really hard to get a team to come together and work towards a common goal. But I'm not sure it's the team-building part that's hard. The hard part is defining the common goal. With broomball it's easy — get the ball in your opponent's goal more times than they get it in yours. In business it's not so easy. Before you can start building your team you have to invent the game and clearly define the objective. Figure that out and I think the team might find you.

Pass the Hash

2007-02-03T01:37:00Z

Code readability is an undisputed contributor to increased programmer productivity. Ruby on Rails shines in this department by effectively using two main pieces of Ruby — the hash and the symbol. These two things are used all throughout Rails, but most importantly as method parameters. There are two keys to keep in mind when writing methods:

When passing multiple data parameters to a method, pass a hash
When telling a method how to behave, pass a symbol

From a code readability standpoint, this is huge. Using the ActiveRecord::Base.find method as an example, what's more readable?

Article.find(:all, nil, :tags, "tags.name = 'ruby'", "articles.created_at DESC")

or the way it's done in ActiveRecord...

Article.find(:all, :include => :tags, :conditions => "tags.name = 'ruby'", :order => "articles.created_at DESC")

The second example is more readable. When reading the second example it's very quick and easy to comprehend exactly what is being passed to the method. Sure, the first method works and requires less typing, but the only way to know for sure what's being passed is to either have the method's prototype memorized or look it up in the reference. The other thing to note about the find method used above is that it takes a symbol as it's first parameter. This symbol clearly and immediately specifies the desired behavior of the method.

Keep this in mind when writing new methods that accept more than one obvious parameter. In addition to writing code, programmers need to be able to read code. This simple habit of passing parameters as a hash or a symbol will increase code readability and improve programmer productivity.