Brandon Dimcheff

Hacking Chrome with Git

2010-04-24T00:00:00-04:00

Motivations

I spent some time hacking around in Chrome the other day because I have been extremely frustrated with the behavior of the downloads bar in the Mac version of Chrome. When the user initiates a download, it appends the downloads bar to the bottom of your current window, causing your window to grow by the height of the download bar.

This behavior really bothers me, since I have my window set up with about 10px of padding around all sides so I can easily see my IM window and other things that I have docked to the top/side of my desktop. When Chrome grows the window, I have to manually shrink it and then scoot the window away from the title bar again. Then, when I close the downloads tab, I need to make the window bigger so there isn’t an enormous gap below the browser window.

I submitted a bug report about this issue, but a member of the Chrome team explains that they consider this to be the correct behavior:

This is by design, as we do not want to change the size of the web content. We do attempt to restore the original window size when you close the download shelf, although that logic seems to break at times (see Issue 39266).

If that’s their position, then fine, though it does contradict other behavior of Chrome’s. Chrome will, for instance, not enlarge the window when they display the “do you want Chrome to remember your password” alert bar and other similar things. It simply pushes the content down a small amount and then pulls it back up when you close the alert. This is far preferable to me over messing with the size of my window.

The Fix

Well, Chrome is open source, so I decided that if they won’t fix it, I would. At least for my build, anyways. Turns out that it’s a one-line patch to a single controller file. Here they check to see if the view that’s initiating a redraw is the download shelf or the bookmark bar. If it is, they add the height to the view to the window. In this case, I just removed the condition for the download shelf and voila!

How I built Chrome

Hopefully I can save you some time if you’d like to perform similar surgery to your copy of Chrome. It took me a few tries to get everything right, due to some incorrect documentation and the enormous size of the Chrome checkout. Naturally I want to use git, since it’ll make my patch sets so much easier to maintain. These instructions show you how to build a specific release version with your patches using git. This assumes you’re building 5.0.375.17. Substitute a different version if you’d like.

Follow the Chrome Git instructions steps 1-3. You’ll need to install depot tools as indicated in step 2.
Instead of using the URL specified in step 4, use http://src.chromium.org/svn/releases/5.0.375.17, or another version of your choice.
cd into ./src
git config --add svn-remote.375.url http://src.chromium.org/svn/branches/375/src
git config --add svn-remote.375.fetch :refs/remotes/375
git svn fetch 375 (this fetches branch 375 into your local git repo)
Look in http://src.chromium.org/svn/releases/5.0.375.17/DEPS and find in the deps dict where there is src alone. In this case, the value is /branches/375/src@45275. This means that version 375.17 is svn commit 45275. Remember that number.
git checkout refs/remotes/375
git log and search for 45275. Once you find the commit, note the git sha hash. In this case, it is 1bb2782587c269be10f842a468e2d26b38003daa.
git checkout -b 375.17 1bb2782587c269be10f842a468e2d26b38003daa (make a checkout of the exact version of the release)
Do steps 5-6 of the Chrome git instructions.
Apply your patches

You now have a specific version of Chrome and all its dependencies checked out and ready to build. You can now follow the Mac OS X build instructions, or just open src/chrome/chrome.xcodeproj and choose “chrome” from the build menu in the upper left. Choose “Release” if you want to build Chrome for actual use. Note that this took over an hour on my fancy new i7 MacBook Pro with 4GB of RAM. It also used enough resources that my computer was nearly unusable for part of the compile.

Chrome Build Process

A few notes about the Chrome build process: The git repo stores only the code for the browser itself. General libraries, both Google internal and external, are fetched by using the gclient sync command. This is somewhat similar to git submodules, in that it allows Google to pin specific revisions of dependencies to a release. The DEPS file stores all the revisions of the external repositories that are necessary to duplicate a build. The tricky part was to make sure that the git checkout and the dependencies both corresponded to the same release version.

I haven’t yet had to switch my build to use a different release. As soon as that happens, I will update this page to give instructions on how to do so.

Download

If you’d like, you can download a copy of the current dev channel of Chromium with my fix applied. Or you can follow the instructions above and patch it yourself.

The Future

The Chrome guys are working on eliminating the http:// scheme from standard HTTP urls. It turns out that this caused a lot of bugs when they released it into the dev channel so they reverted the change, but they have said that they will eventually revive this “feature”. I found it really annoying and my custom chrome build will likely do away with http hiding once it becomes part of Chrome. I’m happy to work with someone who’s also annoyed by this to set up an automatic build to release a new dev channel build with custom patches to fix some of these “features”… Let me know.

Ruby Brew at Great Lakes Ruby Bash

2010-04-17T00:00:00-04:00

John Roos of Roos Roast designed an excellent blend of coffee for Great Lakes Ruby Bash. John started Roos Roast while selling cars at Dunning Subaru. I met him there when I bought my WRX, when he gave me a free pound of coffee with my car. Not long after that, he quit selling cars and started roasting coffee full-time.

We have enough coffee to make 300 cups during the conference, plus we have 6 half-pound bags of coffee to raffle off for the attendees.

Huge thanks to John for doing this for us. If there’s enough demand, he might be convinced to roast more batches. Call him up or stop by his roasting operation and demand some Ruby Brew!

If you’re not in the Ann Arbor area, you can order his coffee by phone or online.

Working on this project with John was a lot of fun. I watched as he carved the Ruby Brew logo into a rubber stamp block. He also put me to work a bit. I stamped 300 of our cups, and weighed and ground our coffee for the conference.

Thanks, John!

Method of the Month 1: Ruby's sort vs. sort_by

2009-11-18T00:00:00-05:00

Ruby’s Array has 2 methods for sorting: sort and sort_by. Both methods sort your array (obviously) but they do it in slightly different ways.

Background

This article is based on a talk I gave at the Ann Arbor Ruby Brigade in August. The idea for this talk was conjured up at eRubyCon during a discussion between Gayle Craig and me. We decided we would each give a brief talk about the differences between sort and sort_by at our next user group meetings. Amazingly, we both followed through.

`sort`

A Ruby array’s sort method is pretty straightforward. If called without a block, it uses each objects’ comparison operator (<=>) to return a new array with all the elements sorted. If called with a block, you may specify your own comparator as shown below:

[1, 4, 3, 7, 2, 9].sort                   # => [1, 2, 3, 4, 7, 9]
[1, 4, 3, 7, 2, 9].sort {|a, b| b <=> a}  # => [9, 7, 4, 3, 2, 1]

Note that the block for sort accepts two parameters. The return value of the block must be -1, 0, or 1. -1 indicates that the first item is less than the second, 0 indicates they are equal, and 1 indicates that the first item is greater than the second one.

`sort_by`

The sort_by method is slightly different. Its block only takes one parameter instead of two. Your array is then sorted by the results of each of the block calls. For example:

[1, 4, 3, 7, 2, 9].sort_by {|i| -i}             # => [9, 7, 4, 3, 2, 1]
%w{ abcd ab abc abcde }.sort_by {|i| i.length}  # => ["ab", "abc", "abcd", "abcde"]

This is accomplished using something called a Schwartzian Transform.

The Schwartzian Transform

All a schwartzian transform does is turn each record of your array into a tuple with the first element being the item on which you wish to sort. That array of tuples is then sorted. Since the first item in the tuple gets precedence, it is effectively the same as sorting the array by the results of the sort_by block. Once sorted, the first element of the tuple is removed, leaving your original array in sorted order. Below is an example implementation in pure ruby:

module Enumerable
  # This is essentially the implementation of sort_by
  # It's written in C in MRI, so it's a little faster
  def my_sort_by
    self.map {|i| [yield(i), i]}.sort.map {|j| j[1]}
  end
end

Why choose one over the other?

If you’re sorting a small array, it really doesn’t matter which sort method you choose. Use whichever is easiest to code and understand. For larger arrays, however, the performance differences between sort and sort_by can be substantial.

You generally want to use sort_by over sort whenever comparisons are relatively expensive. Note that in Ruby, method dispatch is often enough to count as an expensive comparison. Unless you’re sorting things that end up as C primitives in MRI (like an Integer) you’ll likely want to use sort_by.

The performance varies so greatly because of the Schwartzian Transform. Using sort, each pairwise comparison that must be performed calls the <=> operator. In the case of sort_by, the comparison “calculation” is only done once at the beginning, and then the array is sorted on an Integer primitive much more quickly.

I hope this was helpful to someone. It’s probably more than anyone has written on the difference between these two methods.

Walk Like a Duck

2009-04-07T00:00:00-04:00

Introduction

In a duck-typed language like Ruby, it’s very important that you actually use duck typing. This is especially important when you’re designing a library or other code that could interact with objects that you don’t control. I have come across a few libraries lately that don’t follow duck typing conventions and have caused unexpected behavior when I’ve used them.

In this article, I’m going to pick on Shoulda. Thoughtbots, please do not take offense! I’m a fan, and I figured you guys could take it.

Duck Typing

Before I get into the details, I’ll say a word or two about duck typing for those who may need a refresher. The principle of duck typing basically says that if something “walks like a duck and talks like a duck” it probably is a duck. What this really means is that when you’re interacting with other objects, you should not care what they are, but rather how they behave. If you have an object that responds to #each, who cares if it’s an Array or Set or a custom collection?

Implementing Duck Typing

You should rarely ever use #is_a? on an object. You should be using #respond_to? instead. The whole point in duck typing is that you don’t care what kind of object you’ve received. The only thing you care about is that the object does what you want it to do. Let me show you an example from Shoulda.

The following code is from lib/shoulda/assertions.rb in Shoulda’s git repository. assert_contains is a custom assertion for Shoulda that allows you to easily test a collection for the presence of a particular element.

def assert_contains(collection, x, extra_msg = "")
  collection = [collection] unless collection.is_a?(Array)
  msg = "#{x.inspect} not found in #{collection.to_a.inspect} #{extra_msg}"
  case x
  when Regexp
    assert(collection.detect { |e| e =~ x }, msg)
  else         
    assert(collection.include?(x), msg)
  end
end

If you look at the first line of the method definition, you’ll notice that they are calling is_a?(Array) on the “collection” this is passed into the function. The code I was writing was using a Set instead of an Array. The trouble is, if you pass anything other than an array, that line will wrap whatever you passed in an array. So I ended up with an Array with a Set inside of it, which caused the rest of the assertion code to fail.

The solution to this problem is very easy. If you look at my fork, all I’ve done is change that one line (and add some tests, of course). Now we only wrap the collection in an array if it doesn’t respond to include?. It’ll work with an Array still. It’ll work with a Set. It’ll work with your custom data structure that can detect the presence of objects. That’s the power of duck typing.

def assert_contains(collection, x, extra_msg = "")
  collection = [collection] unless collection.respond_to? :include?
  msg = "#{x.inspect} not found in #{collection.to_a.inspect} #{extra_msg}"
  case x
  when Regexp
    assert(collection.detect { |e| e =~ x }, msg)
  else         
    assert(collection.include?(x), msg)
  end
end

Conclusion

Whenever you’re checking for an actual class of an object rather than examining how it behaves, take a second to think if you can duck type it instead. It will make your code more generic, and make it easier for others to use.

Again, thank you to Thoughtbot for Shoulda and I’m sorry I singled you out. Shoulda is great, and just happened to be in the wrong place at the wrong time for me to start a rant about duck typing.

Automatically log in on merb-auth account creation

2009-03-17T00:00:00-04:00

Recently I was adding new user registration to tasteb.in and I wanted my users to be automatically logged in as soon as they created their account. I’m using merb for tasteb.in, and consequently merb-auth for authentication. It turns out it’s really easy to implement, but it took me a while to get it right. All you need to do is add the following to your action that creates the new user:

session.user = @user

That’s it. All you must do is set the user in the session to the newly created user. I hope this saves somebody else some time.

Fix Missing Disqus Comment Form

2009-03-04T00:00:00-05:00

I had a bit of trouble with Disqus where it would only display a link saying “Discuss this topic on Disqus” instead of displaying an actual comment form. It turns out that this problem was caused by a mismatch between the URL configured in Disqus and the url where my blog was actually accessible. So if you’re missing a Disqus comment form, make sure that the URL listed under Settings -> Website URL in Disqus is the actual URL where your site resides.

tasteb.in is up!

2009-03-01T00:00:00-05:00

I’ve been working on a Merb-based recipe paste site for the past couple weeks called tasteb.in. It’s extremely simple for now. It lets you paste recipes in a very simple format and they show up on the site. You can access your recipes and all recipes on the site. And that’s about it.

I’ll be going into more details about how tasteb.in is built and where I’d like to take the site, but for now, just play with it if you like. Drop me a line with any problems you have, or features you would like to see.

Play in the Sandbox

2009-02-14T00:00:00-05:00

I needed to test some code that reads and writes files on the filesystem. I got sick of manually setting up a scratch area for my test files and cleaning them up when I was done, so I created Sandbox to keep my tests DRY.

See the Sandbox readme for more information, but the basic idea is this:

# inside a test somewhere

Sandbox.play do |path|
  file = File.join(path, 'foo')
  FileUtils.touch(file)  # build a sand castle

  assert File.exists?(file)  # test whatever you want in here
end

assert !File.exists?(file)  # path has been deleted

The project is currently only on github, but it will be on RubyForge once approved. If you want to use it now, you have to use the github gems source or install it from source.

Future plans

Optionally Dir.chdir to the temporary directory for even easier usage
Supply a template directory/archive to be used for the base state of the sandbox

How to learn Ruby

2009-02-05T00:00:00-05:00

UPDATE 4/20/2010: Well Grounded Rubyist is not prerelease anymore. Corrected.

UPDATE 6/30/2011: Fix links to _why’s poignant guide, since he vanished from the earth. Add a bit about finding live people to help you.

Several people have asked me for tutorials, books, and other resources to help them learn Ruby, so I’ve attempted to compile a list of resources I feel are particularly valuable for beginning Rubyists. None of these resources are Rails-specific, but being a good Ruby programmer will obviously help you use Rails more effectively. If there is interest, I will compile a similar (and likely longer) list of Rails resources.

Also, if I’ve missed anything that helped you learn or teach Ruby, please leave a comment and I will add it to the page. I am especially interested in resources that beginning Rubyists have found useful.

For these resources, I assume you already have programming experience and are attempting to pick up Ruby to widen your skillset. If you’re new to programming entirely, check out Chris Pine’s Learn to Program online tutorial.

The 100% Best Way to Learn Ruby

The best way (in my not so humble opinion) to learn Ruby is to find a Ruby expert who is willing to mentor you. Maybe this means tagging along with somebody at work, or pairing with somebody at a startup weekend. At our Ruby meetups in Ann Arbor, we occasionally do a Ruby tutorial where people take turns working on a simple problem that is projected up on a board. New rubyists have often found a permanent guide at these sorts of events. The value of having somebody close to you to be able to help is profound. Do this if you can. If you can’t, or for when you’re alone, this post has many other non-sentient resources that you can use.

Online Resources

The following is a list of freely available online resources that I’ve found particularly helpful for new Rubyists.

Ruby Koans: The newest kid on the block (no pun intended) that’s taking github by storm is EdgeCase’s Ruby Koans. The Koans are essentially a series of failing test cases that you need to figure out how to fix in order to move on to the next step. The best way to learn anything is by doing, and this tutorial will get you programming in no time flat. We use this one at our “ruby for noobies” meetings a lot.

Note that the point in the exercise is not to fix all the tests as fast as possible. In order to get the benefit of this exercise, you must read and understand what the code is showing you. Complete each Koan one by one. Run your tests after each time you change your code.

I think the best way to use these Koans is to get in a small (2-3 person) group and take turns solving the problems. Discuss what you are doing with each other. Don’t take anything for granted.

Why’s Poignant Guide: Why the Lucky Stiff put together an extremely silly tutorial on Ruby. While it may seem a bit campy, it really is a good tutorial. And it’s a lot of fun! It’s not nearly as exhaustive as the Koans, but it has more cartoon foxes and chunky bacon.

Ruby Quiz: Once you get your feet wet, you might want to check out the Ruby Quiz archives. There are over 150 small programming challenges that you can try to solve using Ruby. Don’t cheat and look at the answers before you try it for yourself!

10 Things Every Java Programmer Should Know About Ruby: If you’re a Java programmer trying to learn ruby, you should check out Jim Weirich’s 10 things presentation. He goes over many important differences between Java and Ruby, and this can really help you avoid mistakes that many Java programmers make when transitioning to Ruby.

The Humble Little Ruby Book: Jeremy McAnally’s free introductory online Ruby book. Covers the basics about a lot of stuff that every Ruby programmer needs to know. Also available in print.

Books

The following books are, in my opinion, the best books for aspiring Rubists to check out. None of them are Rails specific.

Beginning Ruby: From Novice to Professional: Peter Cooper’s Beginning Ruby book has received rave reviews, and is specifically targeted at beginning Rubyists. I’m a bit ashamed that I didn’t pick it up on the first pass at this article. Sorry Peter!

Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition (aka. The Pickaxe): This book has been the gold standard of Ruby books for years, and is a must have for ruby programmers. It has both a descriptive section and a reference section. The 2nd edition is from 2004, however, and does not cover Ruby 1.9 at all. The 3rd edition is available in beta, and the final version will be available in March.

The Ruby Way: Hal Fulton’s book is full of solutions to common problems, plus it really helps you learn many of the Ruby idioms that are used by experienced Ruby programmers. Ruby 1.8 only.

The Ruby Programming Language: Written by the creator of Ruby himself, this book covers ruby 1.8 and 1.9. It’s not a tutorial-style book, nor a complete reference, but more of description of the important parts of the Ruby programming language. It’s a great second book (after the Pickaxe) to help you understand more details about how Ruby works.

The Well Grounded Rubyist: David Black’s newest book The Well Grounded Rubyist is now available in its final edition. It’s in tutorial form, which is generally good for beginners. I have not had a chance to read it yet, but his last book was great and I hear this one’s even better.

Note: This is a work in progress. I will be updating it as new books and tutorials come out. I also don’t necessarily want an exhaustive list of every ruby resource. I’m looking for resources that are helpful for beginners. Too many choices may be overwhelming. Also, I haven’t been a Ruby beginner in a long time, so I am particularly interested in things that recent beginners have found helpful.

Sinatra block parameters!

2009-02-04T00:00:00-05:00

The latest master Sinatra now supports optional block parameters. It captures any parameters in the URL and passes them into the block that defines the action:

get '/hello/:name' do |n|
  "Hello #{n}!"
end

The params hash is still available as before, so this should not break any existing applications. It will also work with regular expressions. Any captures are yielded in order:

get %r{/hello/([\w]+)/([\w]+)} do |a, b|
  "Hello, #{a} and #{b}!"
end

Big thanks to rtomayko for accepting my patch, and working with me to get this solid enough to put into Sinatra!

One final note: this feature behaves slightly differently in ruby 1.8 and 1.9. Ruby 1.9 is much stricter about block arity than 1.8 is. If the number of captures in the URL and the arity of the block do not match, 1.9 will raise an exception. 1.8 will likely just ignore the extra parameters and throw up a warning. If you write code that is compatible with 1.9, it will also work with 1.8, as ruby 1.9 is simply more strict.

Run specs with autotest, er, autospec!

2009-01-26T00:00:00-05:00

It seems that it’s not well publicized, but if you want to run your RSpec files with autotest try autospec instead. It looks inside the spec/ directory for files named “*_spec.rb” by default for specs. autospec is part of the RSpec gem, and basically just sets up the proper environment and then shells out to autotest.

Also, if your files in lib/ match up with specs in spec/, autospec will automatically re-run your specs for changed files in lib/ on save. So if you have lib/foo/bar.rb, autospec will re-run lib/foo/bar_spec.rb when you save bar.rb.

Gearing up for CodeMash

2009-01-06T00:00:00-05:00

I’m getting all packed for CodeMash! Hope too see a lot of you there. I’m a little bit disappointed by the dearth of Ruby sessions, but there are enough of us that the open sessions will be rockin’. And the ever popular scotch track always helps.

Commit a linear git history to subversion

2009-01-04T00:00:00-05:00

Update: Deskin points out that there is a commit to git that fixes this problem by adding a --root option to rebase --onto. So when you get a new build of git, you can probably ignore everything here.

The other day I needed to commit a plain old (git-svn free) git repository to subversion. Why, you ask? I had been working on a small project at work in my own little git repository and needed to get it into our official version control. I could, of course, just commit the latest version that I had, but that would not record any of my git commit history in subversion. I needed a better option. git-svn can save each individual commit of a linear commit history to subversion, so I figured I could just apply git-svn metadata to my repository and go from there.

This post is a bit long, as I explain the whole process for the solution. If you’re interested in just the solution, scroll to the bottom.

I’m going to create a small git repository for illustrative purposes: $ git init Initialized empty Git repository in /Users/bdimchef/testgit/.git/

For this howto, I’m using a blank subversion repository, but you can use this method with any subversion repository that has an empty directory to put your new project.

$ svnadmin create /Users/bdimchef/testsvn
$ svn mkdir file:///Users/bdimchef/testsvn/trunk
$ svn mkdir file:///Users/bdimchef/testsvn/branches
$ svn mkdir file:///Users/bdimchef/testsvn/tags

Then, I added my svn metadata to my git repository and fetched the contents of svn:

$ git svn init -s file:///Users/bdimchef/testsvn
$ git svn fetch

Now I was ready to commit:

$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/libexec/git-core/git-svn line 425.

What this error means (in our case) is that it can’t figure out where to dcommit. If we try to rebase, it’s clearer what the problem is:

$ git svn rebase
Unable to determine upstream SVN information from working tree history

Our problem is that we have two disjoint histories in our git repository: The history that we made in git, and the history from our svn repository. Since they share no common ancestors, git svn can’t figure out where to commit its changes. Take a look at gitk to see what’s going on here.

It turns out that this problem is pretty easy to fix with svn rebase. But there is one little trick that will get you if you’re not careful. And before we get carried away doing too many rebases, lets just make a backup branch of master just in case.

$ git branch master.bak master

Lets try one approach. git rebase --onto A B C takes the commit range B..C and puts it onto A. In this case, we want to take all our commits and put them on to trunk:

$ git rebase --onto trunk master~2 master
Applying: added bar
Applying: added baz

Oops! That only applied bar and baz. It forgot about our first commit, foo. Lets go back one more.

$ git rebase --onto trunk master~3 master
fatal: Needed a single revision
invalid upstream master~3

Well, that didn’t work either. The problem is that git rebase --onto rebases the range beginning after commit B. In this case, the commit after foo, which is bar. And there is no commit before foo, so there’s no way to rebase a range starting with foo included. The simple solution to this problem is to git cherry-pick foo first, then do the rebase. First we’ll create a named branch for our rebase.

The Solution

$ git co -b svnrebase trunk                    # create a temporary branch
$ git cherry-pick master~2                     # cherry pick the first commit
$ git rebase --onto svnrebase master~2 master  # rebase the 2nd through current commit
$ git svn dcommit                              # finally commit the results to svn

And that worked! So, generally, the secret to joining two separate histories together is to cherry-pick the first commit, and then rebase the rest on top of it.

Thanks to charon on #git for the cherry-pick idea.

Use Capistrano to set your production database password

2009-01-03T00:00:00-05:00

This is a Capistrano recipe I use to configure my production database.yml. Before deploy:setup executes, this recipe will prompt for a database password and save a new database.yml file to the shared directory on your server. After each deploy, the database.yml file will be symlinked from the shared directory. You can reconfigure your database by executing cap db:configure.

Here are the goods. I’m pretty sure I got this from Jeremy Voorhis a while back, and modified it to work with Capistrano 2.