HickoryTech

Larry vs. the Git Rebase Merge Conflict

Tue, 10 Jun 2008 08:30:00 -0400

While doing a "git svn rebase", if you have merge conflicts here are some things to remember:

While doing a rebase, if anything bad happens, you end up on a "(no-branch)" branch.
When doing a "git status", you'll see a ".dotest" file in your working directory. Just ignore it.
If you want to bail, do a "git rebase --abort". (Note there is no "git svn rebase --abort".)
Fix the merge conflict file manually, then do a "git add [file]".
Next do a "git rebase --continue". (Note there's no "svn" version of this either.)
If it complains about "did you forget to call 'git add'?", then evidently your edit turned the conflict into a no-op change. Do a "git rebase --skip" to skip it. (Very weird, but true.)
Rinse and repeat until the lather is gone, your scalp silky smooth, and the rebase is complete. At any time you can "git rebase --abort" to bail.

What happened to me? Well, I didn't realize what was going on, continued to work on the "not a branch" branch, commited changes, even dcommited changes back to Subversion. It was ugly, but not insurmountable. A buddy clued me into the "not a branch" situation, I was able to get back to my real branch and resurrect my code. It took a few "git rebase --continue" commands, and a tense moment around a "git rebase --skip", but now everything's hunky dory.

This very odd email really helped me a lot. You might be interested at some point.

Relevance @ RailsConf 2008

Thu, 29 May 2008 11:43:00 -0400

Today I'm attending my first RailsConf and coincidentally my first conference as a Relevance employee. Let me tell you, Relevance does conferences differently than anywhere else I've worked. I'll argue that they do them right.

First off, we put 80% of the company on one plane yesterday. (Hmm, okay, maybe that was a little scary.) We took up several rows on the plane, and we definitely made an impression on the passengers and staff. Several rows of geeks all sitting with MacBook Pros passing airplane power cords up and down the rows was a sight to see! Much hacking got done, for sure.

Secondly, pretty much the entire company is giving a tutorial together later this afternoon. Technically, the talk is being given by the company's founders, Stu Halloway and Justin Gehtland, and two of the principals, Rob Sanheim and Jason Rudolph, but in reality we're all pitching in. The session itself is a bit different -- it's a hands-on walk-through of how to approach a Ruby open source project and contribute. It's metric-tool heavy and really gives your average Ruby/Rails programmer a firm grasp of how to take a four hour coding session and turn it into useful patches for a real open source project. It's one of the most innovative and interesting tutorials I've seen in my several years as an open source guy, and I'm proud to be a part of it.

I hope y'all will stop by our tutorial today if you're in the conference. If you can't make it, be sure to stop one of the Relevance guys to say hello. You'll see us in our "think relevance" t-shirts all up and down the halls. Relevance is all-in at RailsConf.

Content-Length (Mostly) Does Not Matter: The Reverse Bob Barker Rule

Fri, 23 May 2008 11:30:00 -0400

Your webapp user needs to download a file, but you don't know the exact size of this file ahead of time. So what do you send as the content-length? Is an incorrect content-length okay? Do you even need a content-length? The Internet is pretty silent on the subject.

For example, my webapp users want to download several files as one zip file, but I don't want to create the zip file ahead of time just to know the content-length. I'd rather create the zip file on the fly and stream it to the user a chunk at a time, as it's created. This saves me time, process memory, code to clean up temporary zip files, etc. However, the problem here is -- how big will this zip file be? What do I send as the content-length?

More importantly, what does content length really do? Is it important? What happens if you don't set it?

Effects of Content Length

The web browser will NOT read more bytes than the content-length value. If you accidentally set your content-length too low, the download is halted prematurely and the downloaded file will most likely be corrupt. Do NOT set it too low. This is the only case where content-length can really hurt you.
If the content-length is set the web browser will show a progress bar while downloading. This is a very important usability feature for medium and large files, and you really want it. You want your user to know how far along they are, so they don't cancel the download and start it over, or worse just abandon your site.
If the content-length is not set, then the user gets an "Unknown Size" message while downloading, and they won't get a progress bar. Avoid this if possible, but it is sometimes okay for very small files that get downloaded so fast the user won't care they didn't see a progress bar. (Still, you want to avoid this.)
If you set the content-length to zero (usually only by accident), then your web browser will usually gleefully say they downloaded the file successfully, and save a zero-length empty file. Do not set the content length to zero.

The Reverse Bob Barker Rule

That first effect is the most important: Don't set the content-length too low, or your users will suffer corrupted files. So this brings us to the reverse-Bob-Barker rule.

"Get as close to the real content-length as possible without going UNDER."

Why Not Go WAY Over?

Okay, so we know not to go under, but why not just go way over? Why not, for example, just double our estimated size? Well, nothing terrible will happen. The browser will keep trying to read content, and when the server says "no more," the browser will safely finish the file and say done, even if it thought there was more content coming.

The only negative is that you want the user to get the best download experience possible. So if you guessed your content-length to be 100 MB, but the real download is actually 50 MB, the user will see a progress bar showing they are 50% of the way done, with probably another minute to download, and then suddenly the browser goes from 50% to 100%, from one minute left to done! The user will be confused.

We call this the "Goldilocks Effect" in usability. In this case, the porridge was too hot -- the user will be left wondering why the download dramatically sped up at the last minute. Did the file download successfully? Did the download really fail but the browser didn't tell us? Although nothing bad actually happened, the user is still left with a sense of unease. We definitely want to avoid this.

How Close is Close Enough?

So, all this boils down to:

If you don't know the exact content-length ahead of time, determine a good cheating algorithm and pad for safety.

But how much padding do you need? How much is enough? What's too much? My experience is this:

Aim for a padding of 1%.

Here's my scale:

Padding over 10% is so inaccurate that the user won't believe the progress bar. "We jumped from 90% to done immediately? Is this thing broken? Is my file corrupt?"
Padding of between 3% to 10% is less fantastic, but still pretty bad.
Padding of between 1% and 3% is the best you can expect in most cases. Depending on the size of the file, the download percentage usually jumps in 2-5% increments anyway. This is only unacceptable for the largest of files, where web browsers are showing download percentages in 1% increments. (And even there this is sometimes the best you can do.)
Padding under 1% is a bit dangerous unless you have a lot of confidence in your guessing algorithm. Remember, the only way to really lose here is to guess under the real content-length.

So this brings us to 1% padding. In most cases, this should be fairly easy to predict, and the web browser will show a 99% to 100% download progress, which is what the user wants to see anyway.

Where Does This Work?

I've tested this "extra content-length" technique on the following platforms, all with success:

Internet Explorer 6 on Windows XP (on VMWare on my Mac)
Internet Explorer 7 on Windows XP (on VMWare on my Mac)
Firefox 2 on Macintosh
Firefox 3 RC1 on Macintosh
Safari 3.1.1

Installing id3lib-ruby gem on Leopard

Thu, 27 Mar 2008 20:26:00 -0400

Took me a bit to figure this out (big thanks to Sam U!), but it's actually pretty easy.

Install id3lib using MacPorts like so:

$ sudo port install id3lib

Then the harder part, install the id3lib-ruby gem as so:

$ sudo env ARCHFLAGS="-arch i386" gem install id3lib-ruby  -- --build-flags --with-opt-dir=/opt/local

Note that you change the ARCHFLAGS to "-arch ppc" if you're using an older PowerPC Macintosh. Using the "/opt/local" build flag tells RubyGems to look in the MacPorts include directory for necessary headers (like id3.h).

Recurring Dates in Ruby iCalendar Using Runt, Ep. 1

Fri, 14 Mar 2008 16:00:00 -0400

What began as my "learn to write Ruby" project almost a year ago is finally taking shape thanks to Open Source Fridays at my new place of gainful employment -- Relevance!

iCalendar is the open standard for those ubiquitous *.ics files. These are the files we read and write with Apple's iCal, Google Calendars, and other standards-based calendaring programs. (Read that as "all calendars except Outlook.")

Ruby has a partial implementation of the specification at the Rubyforge iCalendar project. However, it's missing one important feature -- recurring dates.

For example, that 1pm Monday meeting that you have every week? The Ruby iCalendar project doesn't support it. Now, don't give the iCalendar folks a hard time -- recurring rules are damn hard to implement, and they've spent their time doing the most important stuff -- reading and writing the *.ics files. Also, since most webapps nowadays just export important dates as one-off dates anyway -- the Ruby implementation of iCalendar just hasn't really needed a recurring date implementation. (But we really want one!)

I started by brute forcing my way through the massive list of examples in the RFC 2445. I foolishly thought it was just a matter of hacking out an example using TDD and then refactoring all previous examples. No... I've found out it's just not that simple. (And let's face it, if that's all it took then the Ruby iCalendar folks would've added it ages ago! Poor, naive Larry.)

Then at one of the Raleigh.rb hack nights, Nathaniel Talbott recommended that I look at a little-known Ruby toolkit called Runt. This toolkit implements something called temporal expressions. You remember that weekly 1pm Monday meeting you have? Come to find out that with Runt they look like this:

  DIWeek.new(Mon) & REDay.new(13, 00,14, 00)

You read this as: "day in week: Monday, and range each day: from 1pm to 2pm". You can use this temporal expression either to generate a list of matching DateTimes or to check if a given DateTime matches. Very powerful stuff, incredibly powerful. (By the way, this all comes from an idea by Martin Fowler and implemented by Matthew Lipper.)

So, now my problem looks like this:

Take the iCalendar recurring rule (called a RRULE) syntax and convert it into an appropriate Runt temporal expression.
Let Runt do all the work.

I'm home free! Or... well, I'm not. Come to find out, Runt only implemented about 60% of what I needed to implement the full iCalendar spec. The biggest missing piece was the ability to handle dates at a "week precision". That is, I need to be able to know if a given day and another given day are in the same week. I finally got that feature in today!

So now with the weekly precision and a few other temporal expressions I added, I now have all but 14 of the 41 examples working as Test::Unit tests in Runt! That 65% may sound a little low, but it is actually something like 80% of the total iCalendar functionality. It's definitely all the key features. It definitely supports recurring rules based on a given day and month (mark November 15th on your calendar! it's my birthday!), and it definitely supports week-based recurring rules like the 1pm Monday meeting above. What else do you need?

Here's the patch for Runt's current Subversion trunk. I'm now working on my old iCalendar code. I'm going to do the same trick of using the RFC examples as Test::Unit tests.

I'm hoping to have more next week!

Playing MP3s with Rails! (SoundManager2 Rails Plugin)

Fri, 07 Mar 2008 09:55:00 -0500

So you want to play MP3s from your web application? The best tool I've found for that is Scott Schill's SoundManager2 Javascript API. It invisibly uses a very small Flash object to play the MP3s, and the whole thing is very scriptable through Javascript. Getting it set up is not difficult, but it's a little bit of a pain -- so I wrote a Rails plugin!

Here's what you do:

Install the Rails plugin like this: ./script/plugin install http://soundmanager2.rubyforge.org/svn/soundmanager2
Then run the generator to get the SoundManager2 files in your app: ./script/generate sound_manager2
You'll notice the following files are created: public/soundmanager2.swf public/javascripts/soundmanager2.js public/javascripts/soundmanager2-jsmin.js public/javascripts/soundmanager2-rails.js public/images/SoundManager2/pause-control.gif public/images/SoundManager2/play-control.gif
Then, to add basic play/stop functionality to your view, add the following to your ERB file:

<%= javascript_include_tag :defaults %>

<%= 
  sounds = [
      ["sound1", "http://url/to/sound1.mp3"],
      ["sound2", url_for(:controller => "sounds", :action => "listen", :id => "2")],
  ]
%>  

<%= initialize_sounds(sounds) %>

<div>Play sound 1: <%= toggle_sound "sound1" %></div> 
<div>Play sound 2: <%= toggle_sound "sound2" %></div>

Or, if you want more functionality, start calling the SoundManager2 Javascript APIs directly.

Here are some screenshots of this plugin in action. Here you're looking at part of a table with MP3s ready to play...

And then here you've clicked on the middle song. Note the MP3 will start playing immediately, even while it's downloading!

Clicking the "pause" button will stop the playback.

Here are the project links:

Oh, and by the way, both the Javascript API and Rails plugins are released with BSD/MIT licenses!

I'm definitely wanting to put more "off-the-shelf" behavior in this plugin, but for now the simple play/stop behavior is all my application needs. If you need something else, or want to send me some patches, please shoot me an email!

Way Past Due, But Better Late Than Never

Mon, 03 Mar 2008 11:45:00 -0500

My name is Larry Karnowski, and I've been blogging about twangy and traditional music over at Hickory Wind for over five years now. Hickory Wind has been a great outlet for my musical passion, and I've met some of my best friends through that site. (You can also indirectly trace my meeting of my fiancé-soon-wife through that site too, so it's been a great experience!) However, Hickory Wind has a music audience, not a technical one. I've never been able to wax geek over there, talking about how tired I was of Java, how cool Ruby and Rails are, etc.

Now I'm making a change in my career. Instead of being at a product-based company like I have for the past eight years, I'm starting at a contract-based custom software company called Relevance next Monday. I'm crazy excited about it, and I can't wait to immerse myself into their geeky, open-source-heavy culture!

As part of this change in my career, job, and geeky culture, I've decided it's definitely time to launch this geeky blog to service my other passion -- technology. Here I'll talk about software development, user interface design, and other geeky tangents like Tolkien books, World of Warcraft, and an occasional D&D analogy.

Hickory Wind will be my manic music side, and Hickory Tech will be my manic geek side. (Here's a tip -- I'm all Hulk and no Bruce Banner, baby.)

So, if you're interested in talking Typo versus Mephisto, MovableType versus WordPress, Rails versus Spring, anything versus Java, Rogues vs Bards, and phat l00tz versus role-playing, well then you're probably at the right place.

Welcome!