Schneems

Testing Against Multiple Rails Versions

Tue, 21 May 2013 11:03:00 -0400

Upgrading major versions of Rails sucks. I was there from 0.9 to 1.0, all the way to the famed 2 to 3 release, and they were all painful. I have good news though: Rails 4 is right around the corner, and it’s a much cleaner upgrade. While you are getting your app ready for Rails 4 are you bringing the gems you’ve written up to speed? If the answer is “I don’t know”, keep reading - we will cover how to test the gems you’ve written against multiple versions of Rails including Rails 4 release candidate.

Multiple Versions Matter

Believe it or not, there are still a large number of people who are using Rails 2 in production today. While the path to upgrading to Rails 3 is well documented (there’s a whole book on it) often the biggest blocker isn’t the app, or even the Rails frameworks. The largest hurdle to upgrading is often an un-maintained third party library that can’t be replaced or re-written and doesn’t work in the latest versions. There are many reasons to quit maintaining a library, but “I didn’t know how to upgrade it to support the latest rails release” shouldn’t be one of them.

Testing your App

Step zero is writing tests for your gem if you don’t already have them, once you’re done with that: make sure you’ve got a CI server running, I prefer Travis CI which is free for open source repos. Once you’ve got your CI build green, you’ll need to re-work your Gemfile so you can install multiple versions of Rails and then set up Travis to run your tests multiple times, each with a different version of Rails.

Make Ready your Gemfile

If you you haven’t already, delete your Gemfile.lock and remove it from git:

$ git rm Gemfile.lock

Then ignore the file by adding it to your .gitignore. On a stable app - Gemfile.lock stores the exact version of libraries that are used such as Rails 3.2.13. This is good for normal use, but we need our gem to be able to be bundle install-ed against any version of Rails. Removing the Gemfile.lock allows us to do that.

The next thing we will need to do is to enable your app to load multiple Rails versions from the environment open up your libraries’ Gemfile remove where you’re specifying Rails or railties version:

gem 'rails' '>= 3.1.0'

If it’s in the gemspec, you don’t need to do anything, now add this code

rails_version = ENV["RAILS_VERSION"] || "default"

rails = case rails_version
when "master"
  {github: "rails/rails"}
when "default"
  ">= 3.1.0"
else
  "~> #{rails_version}"
end

gem "rails", rails

Make sure to replace the numeric value in the "default" case with whatever you had specified previously.

Now you can bundle different versions of Rails like so

$ RAILS_VERSION=3.1.0 bundle update
$ RAILS_VERSION=3.1.0 bundle exec rake test

or if you want a one liner:

$ export RAILS_VERSION=3.1.0; bundle update; bundle exec rake test

This will install Rails version ~> 3.1.0 and run tests against it. To run tests against Rails master you can use RAILS_VERSION=master and to run against the betas or release candidates you can run RAILS_VERSION=4.0.0.pre

Now you can run tests on your app using different versions of Rails. You can see an example of this style of Gemfile in my projects oPRO and Wicked. The next step is to configure Travis to automatically do this for you.

Running Multiple Rails Versions on Travis

In your project create a .travis.yml file if you haven’t already. You can add environment variables to your travis run matrix by adding them to this file:

env:
  - "RAILS_VERSION=3.1.0"
  - "RAILS_VERSION=3.2.0"
  - "RAILS_VERSION=4.0.0.pre"
  - "RAILS_VERSION=master"

This will make travis run your project 4x more times each with a different environment specified. While we’re testing against different versions of Rails, let’s make sure we’re testing against different versions of Rubies too. This will test MRI 1.9.3, 2.0.0, and master as well as JRuby in 1.9 mode:

rvm:
  - 1.9.3
  - 2.0.0
  - ruby-head
  - jruby-19mode

Any time you’re testing the head or master of a project such as ruby-head you may see failres because the branch is unstable and not due to your project. For these cases you may want to allow failures until official versions are released.

matrix:
  allow_failures:
    - env: "RAILS_VERSION=master"
    - rvm: ruby-head

This will still run tests against the most recent version of Ruby and against Rails master, but if they fail Travis will not flag the build as failed. If you want to fine tune your allowed failures you can add them together like this:

matrix:
  allow_failures:
    - env: "RAILS_VERSION=3.0.0"
      rvm: 2.0.0

This will allow failures against Rails version 3.0.0 only when using Ruby 2.0.0. You can see the .travis.yml files for oPRO and wicked for full examples.

Test with Pull Requests

Once you’ve got your .travis.yml and Gemfile set up. Commit your results to a branch and push to github:

$ git checkout -b test-rails-4
$ git add .
$ git commit -m "testing rails 4"
$ git push origin test-rails-4

Now go to your repo on Github and open up a pull request like this PR on wicked. If you have PR testing turned on with Travis, this will kick off a build. If you’re lucky all of your required tests will pass and it will look like this:

You can see the Travis build for Wicked here.

If your tests don’t all pass, not to worry: look at the output, reproduce locally, fix, push, and repeat. Sometimes you might not be able to get one version of your library to support all the versions of Rails/Ruby that you need, when that happens you’ve got diverging stable versions.

Diverging Stable Versions

Rails no longer supports version 2.0, but maintains version 3.2+ and 4.0.0.RC1+. Most of your users won’t immediately upgrade to the latest version, and while you’re waiting for them to do so, you may find security or other bugs in a version of your library. For this reason I encourage you to consider supporting at least two versions of Rails. There are a few different strategies you can take in order to accomplish this goal:

Do nothing: If you’re lucky your gem will work unmodified in all versions of Rails, and you’re good to go. Make sure you’re tested, and don’t introduce backwards incompatable changes later down the road.

Branch: Rails uses versions and branches to manage it’s codebase and you can too. If your gem needs a major overhaul to be compliant with the latest release you may want to branch out your codebase. One branch for Rails 3 and you can likely leave Rails 4 on master.

$ git checkout -b rails3

You’ll want to have clearly defined versions for your which version of rails your gem supports. You may want to break semver for a single gem push and shadow Rails versioning. So the Rails3 compatible code can be found in version 3.X and the Rails4 compatible code can be found in 4.X of your gem. Once you do this, release as normal using semver, just avoid rev-ing the major version if you don’t have to.

Separate Gems: If keeping different copies of code in different branches seems too hard, break out your gems into multiple libraries. If your library is named foo consider forking it and making a foo_rails4 gem. While easier on you, it makes it harder for your users to upgrade since they’ll have to know you released a separate gem.

Testing Other Software Versions

You may find that your library depends on other libraries for development or production that have their own dependencies on Rails. One popular library is Devise. You can see how we conditionally change the version of Devise based on our Rails version in oPRO’s Gemfile, I got this little trick from Steve’s work on Draper’s Gemfile.

JRuby Note

While upgrading to Rails 4 I found that a JRuby Gem doesn’t play nice. If you’re testing JRuby and using the JRuby Sqlite3 adapter for ActiveRecord you may need to specify this in your gemfile:

  gem "activerecord-jdbcsqlite3-adapter", '>= 1.3.0.beta', :platform => :jruby

If you’re not testing JRuby in your Travis matrix, why aren’t you? You can always set it as an allowed failure and then at least people who want to know if your lib works with JRuby can check the Travis builds.

The Importance of Release Candidates

Now that you know how to write tests for your libraries to run on multiple versions of Rails, you have no excuse for not having them fully tested and compatible when Rails4 is fully released. It’s important to test against the Release Candidates (RC’s) because these are what will eventually become the fully released version of Rails. If you wait till Rails4 is released and find a bug in the framework, it may be too late to fix. When I was testing Wicked, I found and fixed a regression from 3.2.13 to 4.0.0.RC1. Even better, you’ll know if your library works with Rails4 or not, and so will your users.

If are a connoisseur of Hacker News, you may remember a set of inflammatory comments towards the Rails release team over a number of regressions introduced in a minor version bump of the library. The thing is: there was a release candidate for that minor version and for all of the people who wailed and gnashed their teeth at the regressions, few if any bothered to test against the release candidate. Next time your app gets caught by a regression, ask why you didn’t catch it before that version was released. You could be part of the solution.

Test Today

With bundler and Travis CI testing against multiple versions of Rails couldn’t be easier. Don’t be the maintainer of that one Gem that isn’t compatible with the Rails4 release. Test your gems against all the Rails versions today.

update: @shime_rb pointed out there is a gem called Appraisal to help if you don’t want to manage your Gemfile manually. You can see an example travis.yml with appraisal. Travis also supports specifying multiple gemfiles which is how devise tests against multiple versions of rails .

Richard Schneeman works for Heroku and is married to Ruby, literally. He wrote the easiest way to get started helping in open source: Code Triage. Follow him on twitter @schneems.

Hi Richard. I love your videos; thanks so much (times a million!). I have a bit of a bigger question to ask. I'm just about to be a junior in college. I'm not studying anything technical. I've fallen in love with programming over the last month and a half. Previously, I just wanted to go into consulting: prestigious and great opportunities ahead. I enjoy that subject matter quite a bit. How can I decide if a career in software is for me? What is the career path/stability/future job titles/etc.?

Sat, 18 May 2013 19:16:52 -0400

Happy you’re enjoying them :)

As you may know i’m not a programmer by degree, I have a mechanical engineering BS from georgia tech. You don’t need a degree to get a job, but it is harder to get your first job without one. Not because people care about credentials, just that companies really stink at hiring programmers and may ask you a bunch of horribly lame CS questions in the interview that don’t have anything to do with modern web development.

I spent ~3 years programming Ruby/Rails in college and through my first job before I got my first Rails gig. While everyone is hiring now, it is difficult to find a position looking for junior or new devs. Then if they don’t have the right mentoring programs and experience in place, you may hate working there. For my first job in rails: Gowalla, i got around any interview questions by demoing a fully functioning site (now offline) that did some cool stuf. Then I showed them the repo, and we talked about some of the code. I also gave them ~8+ hours of me giving Rails tutorials…so that helped :)

For consulting: i’ve never done it but I have friends that have. Get involved at a local meetup group. See if you can find other consultants and ask how they got into it. Many that I know share work with one another. I.e. they never turn down a job (lest a door shut) but they might farm off the work to another developer. Look around for a consultant who might be willing to give you a hours of their work a week for a low hourly rate in exchange for pairing/mentoring sessions. 1-on-1 instruction is the fastest way to level up your skills. Go talk to a consultancy agency, they may have a program like this in place already.

If you’re into programming for the money, i say don’t. It’s a lot of time and effort and energy and if you’re not in love with it you will get burned out after a few years making the $$$ even out in the end. Go for it if only you enjoy building, creating, and maintaining meaningful projects. I never meant to learn to program, it just happened that I needed programming to build the things I wanted. The best way to see if this applies to you is to program more and then do the shower test. When you’re taking a shower before your day and getting excited about what you’re going to do, does thinking about programming get you more or less excited.

For career: consultants make tons of money (think 2x what a salary dev makes) but their work is not stable. Typically when a company hires a consultancy it is to do something that no-one at their company wants to do, so you might not be doing the most rewarding work in the world. Salary developers have more ownership and control of what they work on, but there can be little to no variation in the type of projects depending on the size/focus/scope of the company.

For promotions: consultants just raise their rates as they get better. The range I know of right now is anywhere from $80-200 per hour depending on skills and knowledge. Keep in mind they might work 5-80 hours a week depending on how busy they are. Salary workers: you will typically need to ask for a raise like any other job. Titles are typically meaningless. You can be a “senior” engineer at most companies fairly quickly. Other companies have a “flat” architecture and the only difference between engineers is salary. After being a programmer you can go into project management for programmers. While the pay is good here keep in mind a good PM does everything a programmer doesn’t want to: think email…lots of email. If salary isn’t your thing, you can always ask for more vacation, or for extra company time spent working on open source work, or whatever. Most long term programmers make good money, but care more about building and shipping good products than titles and cash.

Ok, so this got a little long. Hope that helps. Try to make community contacts to help with some of these questions, even if you don’t go into consulting…being well networked can only be a good thing. When in doubt go to a Rails meetup. Good question by the way.

You have the best lesson on Rails hands down. Coming from enterprise Java development..I felt that there was so much magic in Rails that other videos tend to skip over. Your through explanations and the Reddit on Rails project really helped to explain many of the details I was really confused about. Thank you!

Tue, 14 May 2013 11:47:42 -0400

Glad you enjoyed the lessons :)

Hello Richard, I was curious after you worked at Gowalla and used PostgreSQL and now work at Heroku which has MongoDB as an option for users. If you were going to do an app that has data like places as well as user data like posts, checkins which would you use today? Thanks for your response.

Sun, 05 May 2013 13:19:58 -0400

Heroku just announced support for postGIS https://devcenter.heroku.com/articles/postgis which helps give you geo location features in your DB. I’ve never used Mongo, so I can’t compare the two. I love postgres though :)

Hey man, I just wanted to say thank you for putting the UT rails course online. Seriously. I've tried a couple of different courses, and this is the first one that explains everything clearly and teaches in a way I understand and actually learn from. So yea, anyways, thank you x1000. If for some reason I ever run into you in the real world, I owe you a beer or three.

Sun, 05 May 2013 13:05:28 -0400

Happy to help :)

Dear Richard, I stumbled upon your videos after searching for a way to learn RoR online. Unfortunatey, I have no programming experience at all, and I was completely lost in the second video of week 2 (ActiveRecord). I didn't even know where to start to follow along. Is this intended for beginners with no database/programming knowledge? Finally, I noticed you also have a set of videos in beginner-to-builder-2011. Am I supposed to watch those videos before doing the UT Rails 10 wk course? Thanks!

Sun, 05 May 2013 13:02:39 -0400

The course is intended for an audience that has some programming background such as understanding variable assignment and flow control (if/else). If you’re just getting started in any kind of programming i recommend codecademy, either start with Javascript (http://www.codecademy.com/tracks/javascript) or Ruby (http://www.codecademy.com/courses/ruby-beginner-en-MxXx5/0/2).

If you get lost in my course i recommend skipping ahead to the exercises, a good amount of the lecture for the first 1-2 weeks is theory that isn’t used until later.

Git Minutes Podcast Interviews Schneems

Tue, 09 Apr 2013 12:28:11 -0400

Git Minutes Podcast Interviews Schneems:

Had a delightful time talking to GitMinutes about workflow, Rails issues, and more. Have a listen and tell me what you think.

Heroku Engineer Engaged to Ruby

Tue, 12 Mar 2013 11:16:35 -0400

It was a long day when @schneems typed $ git push heroku master, opened his website, and exclaimed “I love Ruby!”. Then as if inside of Pee-wee’s Playhouse he heard a voice say: “If you love Ruby so much why don’t you marry her?”. So on December 25th, he got down on one knee with his Grandmother’s engagement ring and proposed to Ruby Ku. She said yes!

You might think that to be the end of the story, dear readers, but it’s just the beginning. Fast forward to March, our young protagonist sits weary on a plane bound for Austin, Tx. He’s been away nearly a month, and has the jet lag to prove it. As he descended the airport escalator, destined to touch foot in the city he calls home, he heard a strange sound. As he lowered, the sound grew, and one-by-one: faces of his friends appeared at the base of the moving steps. As he stepped out he looked for his bride to be, but couldn’t find her. Then his friends part like sea from sky and suddenly…

Did you watch the video?

How are you still reading? Aren’t your eyes filled with tears, and you cheeks cramping from smiling? (I know mine were).

Ruby steps forward holding cue-card style signs. Then, in-time to the boom-box soundtrack, she drops the cards explaining one-by-one why she is in love. As the last card falls she drops to one knee, and with a bottle of 12 year old scotch - proposes to Richard (that’s me). He said yes!

The Couple

Richard met Ruby at a meeting of Austin on Rails when she was learning enough programming to make Hourschool.com. After many awkward moments, false starts, and months of waiting: he stole a kiss after a midnight social (bike) ride. She launched her company, while his got devoured by Facebook. They moved in together, he got a job at Heroku, her company won a design award from core77, and they found the light of their life: Cinco Dog. She sometimes teaches at Austin Center for Design and He sometimes teaches at the University of Texas. They are both massively addicted to coffee, sunny days, and dachshund kisses.

After their mutual proposals, Ruby and Richard will be married on an urban farm in Austin, Tx on April 27th, 2013. Cinco dog remains single and ready to mingle.

The Journey Begins

Tomorrow brings another sunrise, another sunset, and another day of Richard loving Ruby.

Open Source in your Inbox: Code Triage

Thu, 07 Feb 2013 11:12:50 -0500

“I don’t have time to contribute to open source”. But who does? We’re too busy shipping products and open source is so daunting and time consuming. Sure tools and technologies are our livelihood, but there’s just so much there. Even if you’ve got the time - where do you start?

What if giving back wasn’t so overwhelming, so time consuming, so vast and soul crushing? What if you could get bite-sized open source tasks delivered right to your inbox? You could work on them when you get some free time, while learning more about the underlying guts of the code you depend on. Well now you can with: Code Triage.

What is Code Triage?

Code triage sends you one issue a day from your favorite repos:

These issues come in one at a time and it could be anything: from a feature request, to a bug report, to code attached to a pull request. It’s up to you to figure out if you can fix, give feedback, or grab someone with more experience. The more you can help, the more free time the software maintainers have.

Do you want:

To have your name in the commit log of famous projects?
To gain a better understanding of the libraries you’re using?
To use less buggy software?
To be a better developer?
To be a better person?

Then Code Triage is for you.

Maintainers: Increase your Firepower

You’ve got open source libraries? Add your repos to Code Triage and subscribe to them. I’ve a few of my own libraries: Wicked and Sextant to triage. On the rare ocasion when I have issues pile up, I make sure I can work them off at a sustainable pace.

If you know someone interested in your project, suggest that they sign up to triage the repo. Also consider putting a link on your README.

It has already worked well for me. When I first launched Code Triage into Beta, @neilmiddleton helped so much on issues that I gave him commit bit to the github repo. Now he works on the project and sometimes fixes issues before I even get a chance to take a look at them.

In fact it has worked out so well, Neil ended up asking me to co-author a Heroku book. Legal Disclaimer: Code Triage cannot guarantee you co-authorship of an O’Reilly book.

Programmers: Make a Difference

Open up your favorite editor, click “Recently Opened”, and then find a project. Take a good hard look at your dependencies, pick one, and then sign up to triage. It’s really that simple.

The era of “too busy”, “too novice”, and “too lost to start” are over. Now is the time to solve bugs, merge good pull requests, and prevent maintainer burn-out. Together we can do it.

Go make an impact: one issue at a time Code Triage.

Anatomy of an Exploit: An In-depth Look at the Rails YAML Vulnerability

Mon, 04 Feb 2013 12:46:00 -0500

Exploits happens, and this month the Rails and Ruby communities have seen no shortage. From a major exploit in Rails to a slightly different Rubygems.org attack, there has never been a better time to brush up on software security.

Maybe you’re wondering why these vulnerabilities happen in the first place, why they weren’t caught in the first place, or maybe you just want to know the specifics of this attack. We’ll start off by taking a look at the anatomy of a security exploit, and then dive into the gory details of the YAML issue.

Continue Reading…

Use GIFs in your Pull Request for Good, not Evil

Mon, 21 Jan 2013 10:00:00 -0500

This weekend I made my OVER 9000 pull request to Rails, that features a demo of the functionality in GIF format. I’ve had a number of people ask the same question “what is your GIF workflow?”. For the detail oriented of you in the crowd, here it is.

The Content

I filmed my screen using Screen Flow, which I used to do all my work on UT on Rails, it’s not free at $99, but does editing, exporting, and managed to completely displace Final Cut Pro from my workflow. I recommend it. Another user suggests using quicktime which can do screen recording for free.

I took the video and then cropped it down to 560x315 and exported using H.264, this produced a teensy 619kb .mov file.

The GIF

Once I had a video I opened it up in Photoshop and used Save for Web to save as a .GIF. You can do this, or I’ve since learned that there is a free way to do this using FFMPEG and Image Magick that actually produces a smaller file. First install FFMPEG:

$ brew install ffmpeg

Then navigate to the correct directory, and assuming your file is named ScreenFlow.mov you can run this to produce a GIF:

$ ffmpeg -i ScreenFlow.mov -pix_fmt rgb24 output.gif

You’ll notice the output.gif is huge-normous, tipping the scales at over 100mb. To cut this down to size you can use image magick:

$ brew install imagemagick

Then run:

$ convert -layers Optimize output.gif output_optimized.gif

Thanks to this poster on super user for the shorthand. Here is a shell script to do that same thing, and if you’re looking for more vibrant results this user had some helpful tips.

Now you just need to post your amazing creation.

Posting

Now we’ve got a GIF sitting pretty around 182kb or so, but we need to put it into our PR somehow. You could drag and drop it into Github or you can upload it somewhere publicly accessible for re-use later. Use your favorite cloud storage service here, I like Cloud App. The service allows you to drag files to your menubar and share them. Make sure you’ve got the direct link (it should end in a .gif).

Once you’ve done that just add it as a markdown image ![title goes here](url goes here) and put it in your pull request, so this:

![Path Helper Demo](http://f.cl.ly/items/3C121F3E0P0A2o092I0w/output_optimized.gif)

Becomes this:

Enjoy

Submit your PR, kick back relax and enjoy the GIF you’ve bestowed upon humanity. Remember with great GIF power comes great GIF responsibility. Don’t post useless or unnecessary GIFs just because you can. Remember that maintaining a project is tough enough without having to look at looping cats all day long. So only add them when they truly benefit the conversation and when it is tasteful. If no-one abuses this functionality, then Github won’t have reason to disable gif support.

Thanks for sticking around, hope you learned something. Now go out and contribute to open source so you can feel like this:

Good, Simple Design

Tue, 15 Jan 2013 10:00:51 -0500

I’ve heard this re-framed again and again by many different programmers from @wycats at Ruby conf to @dhh in his parlay letter:

I consider this [the ease of getting started], like maintainability, to be a side effect of good, simple design.

I think this is a great way of looking at the “beginner” problem, but it doesn’t give much guidance. What exactly is good design for advanced developers? Why is it also good for beginners? Who counts as a beginner? Is a .NET dev with 5 years of industry experience learning rails lumped into the same category as a someone who had never previously viewed-source on a webpage?

In the Beginning

Let’s take it back a bit, to the era before one click purchases, and github signup buttons. The realm was ruled by the textbox and it’s mighty accomplices radio buttons, text areas, and submit buttons. Signing up for a new web app was a lesson in finger cramps. Eventually some people were clever enough to figure out that fewer fields meant fewer interactions, and less fatigue. This of course lead to fewer people dropping off and higher sign-up numbers. Good for the business, who now has more users. Good for you, who now has to type. In the end all they needed was a password and an email, the rest was just details.

What do web forms have to do with advanced programming? Everything. It doesn’t matter if you were browsing the BBS on a 28.8k or you just got your first taste of the Internet over AOL, you had to go through the same interaction. Experience was irrelevant. There was no “click here if you understand the internet” signup option. So when the pain of signing up for many many services by the elite trickled down to help the newbs signing up for their first service: every won.

Anectdotes aside, this is how coding for interaction should be. Build for the pros, don’t forget the nos. What can we as developers take away from the signup form? Treat each user interaction as a barrier to entry and productivity, slash cut and simplify until you can’t be simpler, and treat the interface as a tool to reduce activation energy.

PROTIP: Look for heavy process and cut it down to size

Sometimes the simplicity can come from an internal structure, let’s take a look at how re-thinking how routes are groked led us to a more productive programmer and eventually a smarter “beginner”.

Simplicity in Action: Sextant

A Sextant is an ancient tool for finding your route via the stars. My program Sextant is a tool for finding your rails routes via your browser. I started the project to save me from the pain of rake routes to slash my waiting time (counted in agonies per command, of course) from 20 to 0.

What started as a simple tool for saving time has since ballooned into a new way to visualize and think about a core part of our Rails coding experience, with over 39 thousand downloads. The key to it’s success was identifying that extra step that wasn’t needed, the boot time of the rails app. Now that sextant is shipping with Rails 4 we can start the process over again. What else isn’t needed, or what is missing?

The Evolution of an Interface

Once we got the routes into the browser we’ve now got a powerful set of interaction tools to work with, namely html and javascript. I was able to clean up the visuals of the routes a bit, but it always bothers me when the computer knows the answer to something and yet makes me do the work. Named routes which are a commonly used element in the views, are listed not as they are intended to be used, but instead only have their prefixes in the output. So instead of new_users_path I’ll often type new_users into a view by accident when I’m tired or distracted. When I hit refresh the page I see my problem, I forgot to do my mental math and add the _path suffix. When you’re already tired, already frustrated, just trying to ship a feature these seemingly small hoops to jump through grow ever larger with each mistake made. Why not remove them entirely?

The solution is to add this info into the view by displaying the full named route helper:

I think this is great. But why, what makes this a good idea?

‘Don’t make me think’

Rails is famously convention over configuration. This saves you, the developer, countless hours debating where to put your files or and what to name your folders. While this eliminating these extra steps is a great thing, something can get lost in the translation:

The first thing this current class of students asked me is “Where can I find the document that describes all of the Rails conventions.” - @steveklabnik

As you’re removing steps, if you miss some, then you’re secretly adding a hidden step to Google for for awhile. This Google tax only comes to: the new, the uninformed, the tired, and the overworked programmer trying to ship at the last minute. It’s easy to forget once you know the missing step by heart. This is why being explicit with route helpers in Sextant makes an impact. We took the hidden step “add _path to the end of these” and made it explicit without losing any information (you can still see that _url is an option):

PROTIP: Mental math leads to errors, where can we be more specific?

While you’re refining and iterating and slashing steps, don’t forget to keep context front and center. If you’re looking for places where you might need better docs, or more accessible information. I recommend you keep a …

Cheat Sheet

I use Evernote to keep track of the text snippets and docs links I end up finding useful. Not only does it help to organize my thoughts while I’m having issues, I can search it later if I run into the same problem, and even better when I’m bored or looking for something to productively procrastinate with, these notes are great places to see if we could add more docs, take away steps, or remove some mental math.

Design for All

If I can make my interface so simple it only needs one step, maybe one day we can eliminate the need entirely. This is exactly how automation is born and thrives. While it’s obvious saving developer time is a good thing, why had no one done this before, and how can you build better software for all levels?

Keep a cheat sheet
Look for duplicate or un-needed steps
Look for long complicated processes
Look for missing docs or implied information

Get up and make a difference, work with more beginners, contribute to open source and help close the gaps.

Richard “@schneems” (pronounced like Schnapps) Schneeman writes Ruby code for @heroku and teaches Rails at the University of Texas.

JRuby Support Live on Heroku

Thu, 13 Dec 2012 13:47:00 -0500

I’ve been quite lately, thats because we’ve been working on something amazing over at Heroku. So check out:

I had a ton of fun working with JRuby, and Heroku made it super easy. If you’ve never thought of using JRuby in Production, maybe you can give it a whirrl.

Hi there, I wonder what do you think about MongoDB and Mongoid? I'm confused to use them or not. I'm between PostgreSQL and MongoDB... Well, so a relational database and a document-oriented database. Thanks for your reply.

Fri, 23 Nov 2012 17:44:48 -0500

Stick with what you know unless you have a good reason for using something else. I have a video on nosql that may or may not help http://www.youtube.com/watch?v=oL-A4JYwgH4

Custom Wizard URLs in Rails with Wicked

Wed, 14 Nov 2012 10:00:00 -0500

I wrote this wizard controller library that people seem to really dig called Wicked. It works well to build after signup wizards and to incrementally build objects for the database but there is one thing it didn’t do very well until now: allow you to change the text in your wizard url’s quickly and easily.

If you’re new to Internationalization (I18n) it’s a process of making your website look native in more that one language. With the newly released Wicked you can translate your wizard urls or simply use it to change your custom urls in one language with no code changes. Check it out:

Internationalization of URLS (I18n)

If your site works in multiple languages, or if you just want more control over how your URL’s look you can now use I18n with wicked. To do so you need to replace this:

include Wicked::Wizard

With this:

include Wicked::Wizard::Translated

This will allow you to specify translation keys instead of literal step names. Let’s say you’ve got steps that look like this:

steps :first, :second

So the urls would be /after_signup/first and /after_signup/second. But you want them to show up differently for different locales. For example someone coming form a Spanish speaking locale should see /after_signup/uno and after_signup/dos.

To internationalize first you need to create your locales files under config/locales such as config/locales/es.yml for Spanish. You then need to add a first and second key under a wicked key like this:

es:
  hello: "hola mundo"
  wicked:
    first: "uno"
    second: "dos"

It would also be a good idea to create a english version under config/locales/en.yml or your english speaking friends will get errors. If your app already uses I18n you don’t need to do anything else, if not you will need to make sure that you set the I18n.locale on each request you could do this somewhere like a before filter in your application_controller.rb

before_filter :set_locale

private

def set_locale
  I18n.locale = params[:locale] if params[:locale].present?
end

def default_url_options(options = {})
  {locale: I18n.locale}
end

For a screencast on setting up and using I18n check out Railscasts. You can also read the free I18n Rails Guide.

Now when you visit your controller with the proper locale set your url’s should be more readable like /after_signup/uno and after_signup/dos.

Wicked expects your files to be named the same as your keys, so when a user visits after_signup/dos with the es locale it will render the second.html.erb file.

Important: When you do this the value of step as well as next_step and previous_step and all the values within steps will be translated to what locale you are using. To translate them to the “canonical” values that you’ve have in your controller you’ll need so use wizard_value method.

For example, if you had this in your controller, and you converted it to a use Wicked translations, so this will not work:

steps :confirm_password, :confirm_profile, :find_friends

def show
  case step
  when :find_friends
    @friends = current_user.find_friends
  end
  render_wizard
end

Instead you need to use wizard_value to get the “reverse translation” in your controller code like this:

steps :confirm_password, :confirm_profile, :find_friends

def show
  case wizard_value(step)
  when :find_friends
    @friends = current_user.find_friends
  end
  render_wizard
end

The important thing to remember is that step and the values in steps are always going to be in the same language if you’re using the Wicked translations. If you need any values to match the values set directly in your controller, or the names of your files (i.e. views/../confirm_password.html.erb, then you need to use wizard_value method.

Custom URL’s

Very similar to using I18n from above but instead of making new files for different languages, you can stick with one language. Make sure you are using the right module:

include Wicked::Wizard::Translated

Then you’ll need to specify translations in your language file. For me, the language I’m using is english so I can add translations to config/locales/en.yml

en:
  hello: "hello world"
  wicked:
    first: "verify_email"
    second: "if_you_are_popular_add_friends"

Now you can change the values in the URL’s to whatever you want without changing your controller or your files, just modify your en.yml. If you’re not using English you can set your default_locale to something other than en in your config/application.rb file.

config.i18n.default_locale = :de

Important: Don’t forget to use wizard_value() method to make sure you are using the right cannonical values of step, previous_step, next_step, etc. If you are comparing them to non wicked generate values.

Custom crafted wizard urls: just another way Wicked makes your app a little more saintly.

Richard @schneems (pronounced sorta like Schnapps), loves writing gems and works for Heroku. If you enjoy the wicked gem consider watching the repo or telling your friends.

Hacking mruby onto Heroku

Tue, 06 Nov 2012 13:59:33 -0500

If you’re in the Ruby world, you’ve likely heard about mruby, Matz’s latest experimental Ruby implementation. What I bet you didn’t know is that you can run mruby on Heroku right now. As a matter of fact you can run just anything on Heroku, as long as it can compile it into a binary on a Linux box.

If you’re new to mruby, or to compiling binaries take a look at my last article Try mruby Today. I cover getting mruby up and running on your local machine. If you are already up to speed then follow along as we use vulcan to package mruby as binary, wrap it up in a custom buildpack and then launch an app to use mruby on the Heroku cloud.

Yesterday

If you missed it yesterday we announced official support for Ruby 2.0.0 Preview1, and announced the dates for our developer conference, Waza 2013, including the Waza call for Speakers.

Ruby 2.0 Preview Available on Heroku

Mon, 05 Nov 2012 12:18:40 -0500

When Heroku first launched you could only use one version of Ruby: 1.8.6. As the Ruby implementation matured and improved, so did Heroku. We recently announced the ability to specify your ruby version on Heroku, and we are happy to announce the first preview-build of Ruby available: starting today you can use Ruby 2.0 preview1 on Heroku.

Reddit on Rails part 3: Last week of UT on Rails

Tue, 30 Oct 2012 10:00:15 -0400

I’m finally wrapping up my UT on Rails series. While people have been getting close to the end of the course, I’ve gotten the question “Now what?” plenty of times. Now that you’ve spent 40+ hours pouring over videos, exercises, and quizzes where do you go from here? To answer this question I made a short video. But first, the last exercise of the course:

Reddit on Rails: Part 3

This week we wrap up our Reddit on Rails exercise series by adding styling to our project, full text search, and some much needed integration tests. What are you waiting for go start on the exercise.

Where Do We Go Now

A programming course can’t make you a good programmer, watch this video to learn where to go from here. Don’t stop now, you’re so close to doing great things…

Additional Resources

Don’t forget to follow me on twitter @schneems and tumblr. Though the class might be over, I still talk about Ruby and Rails quite a bit. Thanks, and see you on the internets.

Try mruby Today

Tue, 23 Oct 2012 12:58:00 -0400

Ruby dominates the web: running popular sites like Github, Heroku, and Living Social. But why should web developers get to have all the fun? Wouldn’t it be great if game developers, embedded systems engineers, or anyone else could use the beautiful syntax of Ruby in their C programs? Lucky for us, that’s exactly what mruby plans to do…

continue reading my article on Rubysource: try mruby today

the boots in the corner: Hire junior devs!

Tue, 23 Oct 2012 10:05:28 -0400

the boots in the corner: Hire junior devs!:

amydoesntlai:

To employers:

Hire junior devs!

I am writing this not because it is self-serving — at least, not entirely because it is self-serving — but because I have been hearing people in the industry say so, and I didn’t want to be guilty of, you know, hoarding their knowledge.

On Wednesday, some of us…