Envy Labs

Rails 3 Interview

Gregg Pollack — Tue, 17 Aug 2010 02:11:35 +0000

In February of this year Nathaniel Bibler and I flew out to Engine Yard in San Francisco to spend a day with Carl Lerche and Yehuda Katz. The purpose of the trip was to interview both of them about Rails 3, doing some research for the upcoming Rails 3 Screencasts. We recorded the entire interview on about 5 hours of video, most of which would put you to sleep. Recently I dug out the footage and put it together into a 20 minute video which you can see below. I apologize in advance for the audio, I know it’s not the best.

View on Viddler.

For a good laugh, forward to 17:28

No Callbacks, No Threads & Ruby 1.9

Gregg Pollack — Mon, 26 Jul 2010 17:41:41 +0000

A few weeks ago at Railsconf I approached Ilya Grigorik about recording his awesome talk in the same style that I captured John Athadye and Joe Damato’s talk. He recommended I grab him at OSCON to redo the talk as it would be a little more polished by then, so i did!

In the talk he discusses the state of the Ruby VM and why we should standardize an asynchronous Ruby stack which takes advantage of Ruby 1.9, Fibers, and non-blocking database drivers to make Ruby (and Rails) more scalable.

View on Viddler

Resources

OSCON Interview

Gregg Pollack — Fri, 23 Jul 2010 07:46:34 +0000

This week Nate, Jacob, Thomas and I are at OSCON where we taught our Rails 3 tutorial on Tuesday. Yesterday at the conference I was interviewed in the OSCON booth, the results of which you can see below:

View on YouTube

Common Rails command shortcuts

Jacob Swanner — Thu, 15 Jul 2010 18:16:03 +0000

I know many people — including myself — use Bash aliases for common command line tasks. Some popular examples would be: ss short for script/server, sc for script/console, and sg for script/generate.

These are setup by putting the following code in a Bash configuration file — such as ~/.bash_login:
alias ss='script/server' alias sc='script/console' alias sg='script/generate'

That works great, until you switch to Rails 3; all of these script files have been removed, and you use the rails command in their place: rails server instead of script/server, rails console instead of script/console, etc. Rails 3 provides shortcuts for the common commands: rails s is short for rails server, rails c is short for rails console, and so on. Some have suggested aliasing the rails command to just r, allowing you to use r s to start a server.

These shortcuts are nice, and is much less typing. But, I don’t want to have to remember when I’m in a Rails 2 app to use ss and then when I’m in a Rails 3 app to use r s; I want ss to just work in every project. Unfortunately, you cannot use a Bash alias to solve this problem; you can however use a Bash function! The following is a drop in replacement for the old alias ss=... stuff in your Bash configuration file:


function ss {
  if [ -e script/rails ]; then
    script/rails server $@
  else
    script/server $@
  fi
}
function sc {
  if [ -e script/rails ]; then
    script/rails console $@
  else
    script/console $@
  fi
}
function sg {
  if [ -e script/rails ]; then
    script/rails generate $@
  else
    script/generate $@
  fi
}

They work by checking for the existence of a script/rails file, which is new to Rails 3; if the file exists use it, otherwise fall back to using the Rails 2 version of the command; any arguments given to the function are passed along to the script, which is the $@ bit above.

I’ve contributed these changes to the Terminal project by Pigment, which includes similar shortcuts for many other common tasks.

LiveReload Screencast

Gregg Pollack — Mon, 12 Jul 2010 03:48:30 +0000

Are you still hitting the refresh button every time you change some code / stylesheet? If yes, you may want to watch the following video and learn about LiveReload by Mikhail Gusarov.

View on YouTube

Yes, I know there are already a few other tools out there that do this, but I don’t think I’ve seen any that actually reload the CSS or Javascript without even reloading the page. I also forgot to mention in the video that it works in both Safari AND Chrome.

Ruby Tracker, the Ruby Dependency Manager

Nathaniel Bibler — Tue, 06 Jul 2010 21:23:07 +0000

This morning on the Ruby5 podcast, we announced the release of Ruby Tracker. Ruby Tracker is our newest community support project which monitors and reports on library dependencies in your Ruby software and was primarily spearheaded by myself and Mr. Jacob Swanner.

“A dependency tracker… What the h*ll does that mean?”

Well, thanks for the unsolicited question, good sir. The simplest explanation is this: We examine your project repositories and determine what gems – specifically what versions of each gem – you use and then let you know when one of them is updated.

“And just how do you do that?”

Well, it has only been since the release and adoption of Bundler that an application like this is even possible. Bundler provides us all with a common way to define and share information pertaining to the exact external libraries in which our Ruby projects’ depend. So, if I gave you the source for Ruby Tracker, for example, you’d know exactly what gems you’d need to install to get it up and running. That being said, once we begin tracking your project, we examine the Bundler Gemfile and Gemfile.lock (found in the root of your app) to then begin keeping tabs on those gems which you use. And, should one of them change, you’ll get an email and a flag on your dashboard indicating that your project is now out-of-date.

“Great. But, my project is private and hosted on my own server. I don’t like you or the community.”

Fair enough. I would just like to point out, however, that Ruby Tracker does work with private repositories. Each project is given a unique, 1024-bit SSH RSA key pair. If we notice that your project is private, we’ll give you that public key and ask you to add us to your repository. On GitHub, that’s as easy as adding a new Deployment Key in the Admin area of your project. And, that’s not to say that we only work with GitHub; in fact, we work with any Git repository that is internet-accessible, whether it’s publicly available, SSH-only, or HTTPS.

“You said this was good for the community, I just don’t see it.”

Well, beyond helping you to look like an Awesome Programmer by always using the newest and best code available, we also collect aggregate statistics on the dependencies that we track. But don’t worry, no one will see your project information without you inviting them to do so. Instead, we provide public stats pages on each library in the system to give the community (more specifically the library authors) a better idea of real-world library adoption rates and illustrate which versions are truly in use in the wild. Ultimately, this helps everybody because library authors can spend their time supporting projects which are important to the community and even help them channel efforts toward those versions which the community actually uses, whether that’s through continued support of an older, but highly used branch, or easier migration paths from popular versions to the latest.

“I’ve got a whole team of people and I don’t see the point.”

Well, we’ve got a whole team of people, too, and not a single one of them has ever walked into the office on a bright, Monday morning to say, “I’m going to check RubyGems and see which of our many projects have a library out-of-date and fix it before there’s a problem!” Instead, we generally only realize that we’re out of date when something begins breaking. And then, it’s far too late. It’s easy to get several major releases behind on multiple gems, at which point, your quick-update hopes and dreams go right out the window. Update early, update often for the simplest possible migration path, right? Not to mention that early adoption helps the community, immensely.

Oh yeah, and, while we certainly prefer RubyGems.org (I mean, who doesn’t?), we work with any, valid Rubygems source you provide. If your Gemfile says you use gems.mysuperawesomegemserver.com, well, we’ll track that one too (if it’s accessible, of course), just for you, you special person, you. We love you just that much. <3 Kisses.

The project is fresh and certainly a little rough around the edges… but really, we wanted to get it out there to see where you might want to take it. So, try it out, love it, hate it, get uttlerly confused/frustrated and burn our name in effigy. Either way, give us feedback! While we’ve already got ideas for where we’d like to go and what we think needs work, your thoughts will certainly affect our direction.

TL;DR: We released a new community application called Ruby Tracker which lets you know when gems you use are old. If that’s not short enough for you, here’s a video… because, well, we can’t read, either:

Garbage Collection & the Ruby Heap

Gregg Pollack — Tue, 06 Jul 2010 13:22:06 +0000

At Railsconf a few weeks ago I managed to get two of my favorite talks on video. Two weeks ago I published John Athayde’s talk on Beautiful Markup, and today I’m happy to publish Joe Damato’s talk on Garbage Collection & the Ruby Heap. If you really want to learn how to finely tune your Ruby interpreter and find memory leaks, then you’ll want to pay close attention to his talk. If you’re looking for additional information about Scaling Ruby, you may want to grab the EnvyCast I produced on the topic.

View video on viddler

Resources from the Video

Help Wanted

Gregg Pollack — Tue, 29 Jun 2010 04:13:25 +0000

In case you missed the tweets, Envy Labs is looking to currently fill two positions, a Senior Graphic Designer and a Project Manager. If you know anyone who might be interested in the position please send them our way. Including me, Envy Labs currently employs 11 people! Damn!

I put together a short video to show people around the place, which I thought I’d share here:

View on YouTube

Beautiful Markup

Gregg Pollack — Tue, 22 Jun 2010 02:24:46 +0000

One of the best talks at Railsconf was given by John Athayde on Curing Div-itis with Semantic Html, CSS, and Presenters. John was nice enough to redo his talk for me at the conference so I could properly capture it and share it with you. In his talk he goes through several techniques they employ at InfoEther to create beautiful markup in their web applications.

View video on viddler

If you dig this talk be sure to subscribe to the RSS feed, I have one other awesome Railsconf talk to crank out.

Useful Links from John’s Talk:

Ruby Hero Awards 2010

Gregg Pollack — Sun, 13 Jun 2010 03:00:38 +0000

This is the third year I ran the Ruby Hero Awards, and last Tuesday at Railsconf 2010 I gave away 6 more trophies to people in our community who deserved a little extra recognition. This year the awards went to José Valim, Nick Quaranto, Aaron Patterson, Wayne Seguin, Gregory Brown, and Xavier Noria. Here’s a video of the award ceremony at Railsconf if you want to learn more about each of these guys and see how it went:

View on YouTube