schneems

[schneems]

TIL: Symbol to Proc Trick not needed in Ruby Inject/Reduce 2.0.0

If you've been using Ruby for some time no doubt you've done something like this to sum up an array of integers:

[1,2,3].inject(&:+) # => 6

This works because Ruby will take the symbol :+ and turn it into a Proc, or anonymous function since we're putting the & in front of it (similar to how you would tell ruby you expect a block argument by using a &). The code above essentially boils down to:

[1,2,3].inject {|x,y| x + y} # => 6

Today I learned that you don't need to convert your symbol into a proc to do this, you can just pass in a symbol.

[1,2,3].inject(:+) # => 6

I like this version much better, hope you do to. I found out about this from watching Avdi code on his Ruby Tapas. If you know when this was added, or the source that makes this possible let me know.

Even old dogs can learn new tricks.

Update

This behavior is localized to only inject/reduce methods. For instance you cannot do this.

["a", "b"].map(:upcase) ArgumentError: wrong number of arguments (1 for 0) from (irb):3:in `map' from (irb):3 from /Users/schneems/.rbenv/versions/2.0.0-p247/bin/irb:12:in

You must:

["a", "b"].map(&:upcase) ["A", "B"]

Update 2

This feature has been around for a long time https://eval.in/67239 thanks @charliesome.

[schneems]

TIL how to null out or unset an ENVIRONMENT variable in bash

Heroku compiles your app without environment variables. This is all well and good, but how do you debug a problem that only shows up when an environment variable is missing? Not just set to an empty string "".

To do this bash has a great feature called --unset to remove an environment variable. For example if you wanted to run rake assets:precompile without the DATABASE_URL from your environment you could run:

$ env --unset=DATABASE_URL rake assets:precompile

This allows you to simulate missing any environment variables you want!

[schneems]

Why Do Heroku Builds Run Without Config by Default?

I got this question awhile ago and answered in Gist form. I recently stumbled on my answer and thought it was worth sharing, so here you go:

On Heroku compiles are run without environment variables. Why?

If you compile the same source code you will get the exact same compiled app output every time.

This is determinism. The app build is deterministic.

If you allow environment variables at build time, the output of the app is no-longer deterministic based solely on the code. You can deploy the same code and get different results.

If you are using user-env-compile your app builds are now non-deterministic.

Why is this bad?

It is harder to troubleshoot and reproduce problems. It means if you change your config, you technically need to recompile your app every time.

Add-on providers are allowed to change your environment variables (vendor prefixed for safety). But changing the variable does not trigger a new deploy. If you're app doesn't need user env compile this isn't a problem. Otherwise who knows.

Not only are you enabling your Heroku config to be available at compile/build/deploy time, you could be affecting internal environment variables as well like $PATH or $GEM_HOME, and if you mess those up, there isn't much we can do to fix them.

In short: Best practice is to not use user-env-compile.

[schneems]

Wicked 1.0.1 Released with Critical Security Fix

If you're using Wicked, the easy way to build step-by-step wizards in your Rails code please update to Wicked version 1.0.1 immediately a serious security bug was patched. If you do not upgrade, an attacker may be able to view arbitrary files on your server.

[schneems]

If at First you don't Succeed: Retrying Bundler

What do you do when you fail at a task?

What do you do when your computer fails at a task?

What about your code?

As programmers we deal with flaky network connections, crashing data stores, and user input day in and day out. It's important to remember that all of these things will fail, and our code should be prepared to get back on the horse, turn itself off and on again, and try again.

Retrying Bundler

In the Ruby buildpack for Heroku we deal with a staggaring array of uncertainties, so anything we can do to ensure a smooth experience is a good thing. About 2 months JD opened an issue requesting us to retry failed bundle installs, it's something travis does, and just because a network hiccupped for a split second is no reason to totally cancel an app compile. Besides all a user would do is simply try again. After talking the issue over with Terence Lee we decided to take on the problem. Though instead of solving it locally for the buildpack, we made the concious decision to work on pushing the change upstream into bundler itself. This means that the Ruby buildpack gets retry logic for free as well as every bundler user. Which is what I like to call a win win win scenario. After about a month from initial PR bundler/bundler#2601 was merged.

This patch allows several network operations to be retried, and even better, it defaults those operations to be retried twice (so the operation will run up to 3 times by default). To skip these retry attempts you would need to explicitly tell it to retry 0 times:

$ bundle install --retry 0

While I'm excited for this behavior and general interface for bundler, I'm more excited that it gives the project an extensable & re-usable retry class. So while for now we're only retrying the fetching of gemspecs and git commands we can easily extend any part of the bundler code to retry behavior cleanly reliably.

Retry Culture

This isn't the first bit of retry code I've worked on, about 8 months ago I wrote rrrretry which monkey patches enumerable to allow retry behavior:

require 'rrrretry' [0, 1, 2].each.retry { |i| 1/i } # => 1

It's a small library that I've used in several projects and find incredibly helpful. Since writing it I've found that many of the tools I use every day actually have retry behavior baked in. "Like what?" You might ask. Well have you ever used curl? It has a --retry option (defaulted to zero).

$ curl http://schneems.com --retry 3

Then there's Net HTTP Persistant, and my personal favorite ruby http lib Excon:

Excon.get("http://schneems.com", idempotent: true, retry_limit: 6)

Even strangely enough Tail

$ tail ./log/development.log --retry

Then there's retry logic burried deep in things we use every day like database connections.

Not just for Production

Sure it's important to keep failure out of your production environments, but I've found it to be equally as important in the Ruby buildpack's testing environment. We use rspec-retry to automatically re-run any failed tests. The buildpack uses full stack integration tests (it deploys real apps on Heroku using a tool called Hatchet which is testing framework agnostic) and any number of network effects can easily add up to create a heisen failure. If the same test fails twice in a row it's much more likely that it's a result of the code and not the network.

The deploy process is an especially network sensitive time, so in addition to rspec-retry, the hatchet library can retry deploys:

$ HATCHET_RETRIES=3 bundle exec parallel_rspec -n 7 spec/

While this doesn't guarantee we won't see false failures due to network, it drastically minimizes the chances and helps bump the signal to noise ratio of our tests.

Idempotent

Pronounced ˈī-dəm-ˌpō-tənt' is the idea that when run again, the result of your code should not change. If part of your code succeeds, and part of it fails and the whole thing re-runs, will everything work out? Network connections for most GET requests are easy to retry. While doing more complicated work or manipulating data inside of data stores you should use transactions to avoid getting partially applied code. While the entirety of your code being retried does not need to be idempotent, the individual pieces need to be.

When in doubt only retry the smallest amount of code possible.

Theirs but to do and Retry

If you're interested in adding some more retry logic to your own code, Jordan Sissel has some patterns: Retry on Failure Ruby software pattern. You can also check out my rrrretry gem, or one of its many many compatriots. You can even try writing your own (it's a fun kata).

While for some failure is not an option to make your code embrace, extend, and retry can give your programs a second chance, literally.

Richard @schneems works for Heroku and sometimes writes books, teaches at the University of Texas and runs Code Triage. If you didn't enjoy this article maybe you should come back later and give his writing a (re)try.

[schneems]

Explain Shell, from your Shell

If you aren't massively in love with Explain Shell then you've not been on the internet today (or at least following the same people I do on twitter). It's an easy way to see what a unix command does from a web interface. The web interface is great, but wouldn't it be cool if you could open it from your command line? If someone gave you a command like tar xzvf archive.tar.gz it would be amazing to be able to run:

$ explain tar xzvf archive.tar.gz

And have the results pop up in your browser. Well with a simple explain_shell script now you can!

First off you can install as a ruby gem or as a shell script. Then reload your environment (open a new tab) and explain commands to your hearts content!

$ explain git log --graph --abbrev-commit --pretty=oneline origin..mybranch

It's that simple.

[schneems]

Prepare, Do, Test: Make your Technical Writing Shine

Don't pump and dump information on your readers: build better community and better view numbers by following the Prepare, Do, Test pattern. Let's back up. If you're new to my site: I've been teaching Rails courses for a few years, I work with a ton of open source, and I generally get a kick out of explaining things to people. I've written for Rubysource, my own blog, and a fair bit of Heroku's devcenter documentation. When writing for a technical audience I cringe when I get a comment that says "I'm stuck", or "did it work?" and especially "what do I do next?". To solve these problems and more I follow this framework:

Prepare

Introduce the reader to what they will be doing at a high level and what they can expect in the end. It sounds simple but many articles just jump into the "how" and completely forget the "why". If you don't know what to write: try giving your article to someone new to that subject and writing down all the questions they ask as they go through the exercise. See if you can answer those questions in the article before they even need to ask them. I usually do this for the whole document (see my "what" section in the Ruby View Server Exercise), and I also do this before individual exercise "todo's" (such as in "Using a Layout to add content to all Pages"). Once they know where they're going send them on their way.

Do

This one is simple: give the user the directions you want them to follow. Focus on context, consistency, and completeness. Should the student by typing those words in a text editor, or the terminal? A little consistency goes a long way. I always make sure to preface all commands that go in the terminal with a $, and I make sure that the user knows this by adding a disclaimer to most tutorials on my site.

All code that starts with a $ indicates it is running in the terminal. You should not copy the $.

Again, the best way to see if your directions on doing worked is to give them to a real live person. Ideally you'll give it to 20 real live people. If one of them is tripped up by an unstated convention or inconsistent marking or command, then likely others will have the same problem. It's okay to not re-hash Comp-Sci 101 in every tutorial, but know your target audience's skill level and write accordingly. Put any assumptions or prerequisites early in your writing.

Test

The most important and most commonly missed step in technical writing is the test step. Did the command your student just ran work? How are they supposed to know? With the "prepare" done correctly, this section is where you give them the tools to verify they "did" everything correctly. I recently attended a Rails Girls session in Austin and got fed up of students accidentally running mkdir in the wrong section. So instead of just giving them the command they're now asked to verify using ls or dir after they run the command. Not only only does this answer the question "did it work", it lets them know that something has gone wrong before they get lost in the next step.

Outcome

Writing tutorials and technical docs like this gives your readers the content you're writing about, and it has the nice side effect of sharing your workflow. As you write using this pattern, you'll realize that you actually develop like this. You have a goal, make a change, and then test to see if the change took effect. When you tell your readers how to check their work, you're giving them insight into your workflow. With all the benifits there are a few downsides.

It takes Longer

Writing this way takes longer for sure, and in a world where there doesn't ever seem to be enough enough time to tweet what you're blogging about: time is precious. Sometimes taking longer is a good thing. Ernest Hemingway famously wrote using a pencil instead of a typewriter because it slowed his process and forced him to review his work. Maybe it's time you spent a little while meditating on your workflow. Sure sometimes you found a quick hack you wanted to share, but taking your time to write about a topic in-depth helps solidify it in your mind and can be reflective.

It Might Be an Overshare

Writing in this lock step of "do" and "test" can be tiresome for senior developers. When I wrote about my experience getting mruby running on my machine for Rubysource there were some comments complaining that I spent too long explaining trivial details. It's true you cannot please all the people all the time, so I choose to be inclusive in my writing. Senior developers can easily skim my articles and skip the "test" steps they already know. The opposite cannot be said for junior developers. You cannot write a terse article with no explanation and expect them to just "get it" 100% of the time. In that same article I got the comment "This post is a true work of love! The average layman thanks you.". I find for every one "this article is too verbose" comment, I get a dozen "thanks, I've struggled with this forever" comments.

Technical Writing

Is a skill that takes time to cultivate. I learn new things every time I put markdown to a blog. If you don't write technical stuff: start practicing now for when you need it later. If you are following an open source guide such as Railsgirls consider adding in checksums or tests that will help catch problems without extra assistance. The best way to proof any technical writing is to try it out on someone new to that topic. You can find these people in usergroups and meetups, or if you're really lucky, you might find you're married to them. Thanks for following along and next time you write technical material don't forget Prepare, Do, and Test.

Thanks for reading, if you liked these tips follow @schneems on twitter or tumblr.

[schneems]

Specify Different Gemfile while using Bundler

Travis has a great feature of being able to install gems using a custom Gemfile path. This lets you do things like test against multiple versions of Rails very easily. A project that uses this is sprockets-rails.

I wasn't sure how to bundle install that gemfile locally, it turns out bundler has a BUNDLE_GEMFILE environment variable you can use to point to a specific Gemfile. You can bundle install:

~/documents/projects/sprockets-rails $ BUNDLE_GEMFILE=test/gemfiles/Gemfile.rails-3.0.x bundle install

Then you can Run your tests:

$ BUNDLE_GEMFILE=test/gemfiles/Gemfile.rails-3.0.x bundle exec rake test

[schneems]

Hi Richard, Thanks for the tutorial it is great. I am following and I love it. Only I am not working on my mac directly I am woring on the Nitrous website so the database system I am using is sqlite 3. Can I continue to folow your course if I am using a different database than the one you are using ??? Thanks again and good luck.

Totally. I had one of the attendees at the last Rails Girls event in Austin I helped at use [Nitrous.io](https://www.nitrous.io/) and everything went well for them. Some of the instructions might be a little off terminology wise, but so far Nitrous looks like a great product. You could even write a post on the challenges you faced or things that went over well for you!

[schneems]

maildown - Write your ActionMailer email templates in Markdown, send in html and plain text

If you're anything like me, you can't stand writing email content twice, once for html, and once for plain-text. Yet both need to be sent out for supporting email clients that don't render html (such as mutt). So what is a savvy markdown loving programmer to do? Write the email once in markdown, and have the maildown gem translate it into text and html for you. Try it out today.

[schneems]

Just wanted to say thanks again for all the lessons. Congratulations on the wedding! I Finally have a working prototype for a user submitted event listing page here in upstate NY where there is no such thing. You've done well and although I was stuck many times, I poured over the documentation and hacked it out. Cheers.

Thanks! Sounds like a fun project you're working on!

[schneems]

Heroku API Demo

Whipped up a quick demo of the Heroku API using Sinatra and heroku-bouncer (heroku's oauth rack middleware).

Check out the source code and the live Heroku API demo

[schneems]

Maybe not programming related, but stil features plenty of "Ruby". My wedding was recently featured on style me pretty. Check it out:

Sometimes a wedding is so awesome, it's almost impossible to put into words; it's sooo gorgeous, sooo amazingly beautiful, there's not enough adjectives in the English language to really do it justice.  This, my friends, is one of those weddings.  A cultural fusion of Eastern and Western traditions mixed with the ultra-coolness of Austin and&

[schneems]

Testing Against Multiple Rails Versions

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.

[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.?

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.

[schneems]

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!

Glad you enjoyed the lessons :)

[schneems]

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.

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 :)