Rails 3.0.8rc3

In this episode, Peter and Jason bring you the latest news on the Rails and Ruby fronts and give you the usual round up of gems and plugins.

Celadon Cedar

Super psyched to announce a major new version of Heroku, the Celadon Cedar stack, going into public beta today (previous stacks were Argent Aspen in 2009, and Badious Bamboo in 2010).

Cedar has many new features and updates, but most importantly introduces a new way of thinking about web application architecture and scaling apps on Heroku: the process model. Check it out:

New stack Celadon Cedar moves into public beta today:

$ heroku create –stack cedar
Creating blazing-galaxy-997… done, stack is cedar
http://blazing-galaxy-997.herokuapp.com/ | git@heroku.com:blazing-galaxy-997.git

Cedar Docs

Define your process types with Procfile:

$ cd myapp/
$ cat Procfile
web: bundle exec rails server mongrel -p $PORT
worker: bundle exec rake resque:work QUEUE=*
urgentworker: bundle exec rake resque:work QUEUE=urgent
tweetscan: bundle exec ruby tweetscan.rb
cron: bundle exec clockwork clock.rb

Procfile
Process Model

Then scale up dynos independently for each process type:

$ heroku scale web=4 worker=2 urgentworker=2 tweetscan=1 cron=1
Scaling processes… done

Scaling

Inspect the state of all your app’s dynos across the platform:

$ heroku ps
Process State Command
————- ————— ————————————
web.1 up for 6s bundle exec rails server mongrel …
web.2 up for 5s bundle exec rails server mongrel …
web.3 up for 4s bundle exec rails server mongrel …
web.4 up for 5s bundle exec rails server mongrel …
worker.1 up for 5s QUEUE=* bundle exec rake resque:work
worker.2 up for 4s QUEUE=* bundle exec rake resque:work
urgentworker.1 up for 5s QUEUE=urgent bundle exec rake re …
tweetscan.1 up for 5s bundle exec ruby tweetscan.rb
cron.1 up for 4s bundle exec clockwork clock.rb

ps Command

View detailed, consolidated, real-time logs:

$ heroku logs –tail
2011-05-31 04:04:40 heroku[api] Deploy fee72fc by james@example.com
2011-05-31 04:04:40 heroku[api] Release v5 created by james@example.com
2011-05-31 04:04:41 heroku[slugc] Slug compilation finished
2011-05-31 04:04:41 heroku[web.1] State changed from created to starting
2011-05-31 04:04:42 heroku[web.1] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:43 app[web.1] >> Listening on 0.0.0.0:50600, CTRL+C to stop
2011-05-31 04:04:44 heroku[web.1] State changed from starting to up
2011-05-31 04:04:44 heroku[worker.1] State changed from created to starting
2011-05-31 04:04:45 heroku[worker.1] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:45 heroku[worker.1] State changed from starting to up
2011-05-31 04:04:45 heroku[web.2] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:46 heroku[worker.2] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:46 heroku[worker.2] State changed from created to starting
2011-05-31 04:04:47 heroku[web.2] Running process with command: `bundle exec rails server mongrel -p 31878`
2011-05-31 04:04:47 heroku[worker.2] Running process with command: `QUEUE=* bundle exec rake resque:work`
2011-05-31 04:04:48 heroku[router] GET sushi.heroku.com/ dyno=web.1 queue=0 wait=0ms service=8ms bytes=179
2011-05-31 04:04:48 app[web.1] 66.75.123.123 – – [15/May/2011 04:05:03] “GET / HTTP/1.1” 200 1 0.0009
2011-05-31 04:04:49 app[worker.1] (in /app)

Logging
Visibility

Run one-off interactive processes in the cloud:

$ heroku run rake db:migrate
Running `rake db:migrate` attached to terminal… up, ps.1
(in /app)
Migrating to CreateWidgets (20110204210157)
== CreateWidgets: migrating ==================================================
— create_table(:widgets)
-> 0.0120s
== CreateWidgets: migrated (0.0121s) =========================================

$ heroku run ruby scripts/fix_bad_records.rb
Running `ruby scripts/fix_bad_records.rb` attached to terminal… up, ps.2

$ heroku run console
Running `console` attached to terminal… up, ps.3
Loading production environment (Rails 3.0.3)
irb(main):001:0>

One-off Processes

Official support for Node.js:

$ cd my-node-app/
$ ls
package.json Procfile web.js
$ cat Procfile
web: node web.js
$ git push heroku master
—–> Heroku receiving push
—–> Node.js app detected
—–> Vendoring node 0.4.7
—–> Installing dependencies with npm 1.0.6
mime@1.2.2 ./node_modules/express/node_modules/mime
connect@1.4.1 ./node_modules/express/node_modules/connect
qs@0.1.0 ./node_modules/express/node_modules/qs
express@2.1.0 ./node_modules/express
Dependencies installed
—–> Discovering process types
Procfile declares types -> web
—–> Compiled slug size is 3.1MB
—–> Launching… done, v4
http://radiant-river-296.herokuapp.com deployed to Heroku
$ heroku ps
Process State Command
———— —————— ——————————————–
web.1 up for 10s node web.js
$ heroku logs
2011-03-10T10:22:30-08:00 heroku[web.1]: State changed from created to starting
2011-03-10T10:22:32-08:00 heroku[web.1]: Running process with command: `node web.js`
2011-03-10T10:22:33-08:00 heroku[web.1]: Listening on 18320
2011-03-10T10:22:34-08:00 heroku[web.1]: State changed from starting to up
$ heroku run node
Running `node` attached to terminal… up, ps.1
>

Node.js on Cedar

Notes:

  • Cedar uses an entirely new HTTP stack which fully supports HTTP 1.1, long polling, chunked responses, async multi-connection webservers, and more.
  • Cedar features an unprecedented level of isolation and erosion-resistance, keeping dynos running and healthy, even through patches, updates, deploys, failures, and all kinds of app activity.
  • To make more sense with the new process model, we are switching billing units from dynos to dyno-hours, effective June 1, Pacific time. Free plans will be unaffected, just converting units from first dyno free to first 750 dyno-hours free, per app. With few exceptions, the cost of Heroku will be unchanged or less expensive for all users.

We’re really excited about the foundation all of this lays for the great stuff we’ll be releasing over the coming months. For a list of Cedar features, check out the official press release. We will be following up this post with a detailed look at each of the major new areas over the next couple of weeks.

Enjoy. (And please send us your feedback at cedar@heroku.com.)

[ANN] Rails 3.0.8.rc3 (third time is the charm!)

Hey everybody! I’ve pushed Rails 3.0.8.rc3.

Hopefully this release candidate takes care of all the outstanding issues remaining. To see what has changed between 3.0.8.rc2 and 3.0.8.rc3, check out this link on github.
If no regressions are found, I will release the final version 72 hours from now (Thursday, June 2nd around 1pm). Please let us know if this release candidate causes any regressions from the 3.0.7 version.

I’m still getting over my cold, so I promise that next release I will return to my normal level of excitement! 😉

Gem Versioning and Bundler: Doing it Right

Recently, an upgrade to Rake (from version 0.8.7 to version 0.9.0) has re-raised the issue of dependencies and versioning in the Ruby community. I wanted to take the opportunity to reiterate some of the things I talked about back when working on Bundler 1.0. First, I’ll lay out some basic rules for the road, and then go into some detail about the rationale.

Basic Versioning Rules for Apps

  1. After bundling, always check your Gemfile.lock into version control. If you do this, you do not need to specify exact versions of gems in your Gemfile. Bundler will take care of ensuring that all systems use the same versions.
  2. After updating your Gemfile, always run bundle install first. This will conservatively update your Gemfile.lock. This means that except for the gem that you changed in your Gemfile, no other gem will change.
  3. If a conservative update is impossible, bundler will prompt you to run bundle update [somegem]. This will update the gem and any necessary dependencies. It will not update unrelated gems.
  4. If you want to fully re-resolve all of your dependencies, run bundle update. This will re-resolve all dependencies from scratch.
  5. When running an executable, ALWAYS use bundle exec [command]. Quoting from the bundler documentation: In some cases, running executables without bundle exec may work, if the executable happens to be installed in your system and does not pull in any gems that conflict with your bundle. However, this is unreliable and is the source of considerable pain. Even if it looks like it works, it may not work in the future or on another machine. See below, “Executables” for more information and advanced usage.
  6. Remember that you can always go back to your old Gemfile.lock by using git checkout Gemfile.lock or the equivalent command in your version control.

Executables

When you install a gem to the system, Rubygems creates wrappers for every executable that the gem makes available. When you run an executable from the command line without bundle exec, this wrapper invokes Rubygems, which then uses the normal Rubygems activation mechanism to invoke the gem’s executable. This has changed in the past several months, but Rubygems will invoke the latest version of the gem installed in your system, even if your Gemfile.lock specifies a different version. In addition, it will activate the latest (compatible) installed version of dependencies of that gem, even if a different version is specified in your Gemfile.lock.

This means that invoking executables as normal system executables bypasses bundler’s locked dependencies. In many cases, this will not pose a problem, because developers of your app tend to have the right version of the system-installed executable. For a long time, the Rake gem was a good example of this phenomenon, as most Gemfile.locks declared Rake 0.8.7, and virtually all Ruby developers had Rake 0.8.7 installed in their system.

As a result, users fell into the unfortunate belief that running system executables was compatible with bundler’s locked dependencies. To work around some of the remaining cases, people often advocate the use of rvm gemsets. Combined with manually setting up application-specific gemsets, this can make sure that the “system executables” as provided via the gemset remain compatible with the Gemfile.lock.

Unfortunately, this kludge (and others) sufficiently reduced the pain that most people ignored the advice of the bundler documentation to always use bundle exec when running executables tied to gems in the application’s Gemfile.lock.

It’s worth noting that typing in rake foo (or anyexecutable foo) in the presence of a Gemfile.lock, and expecting it to execute in the bundler sandbox doesn’t make any sense, since you’re not invoking Bundler. Bundler’s sandbox relies on its ability to be present at the very beginning of the Ruby process, and to therefore have the ability to ensure that the versions of all loaded libraries will reflect the ones listed in the Gemfile.lock. By running a system executable, you are executing Ruby code before Bundler can modify the load path and replace the normal Rubygems loading mechanism, allowing arbitrary unmanaged gems to get loaded into memory. Once that happens, all bets are off.

bundle install –binstubs

In order to alleviate some of the noise of bundle exec, Bundler 1.0 ships with a --binstubs flag, which will create a bin directory containing each of the executables that the application’s gems expose. Running bin/cucumber, for instance, is the equivalent of running bundle exec cucumber.

The generated bin directory should contain portable versions of the executables, so it should be safe to add them to version control.

The rails Command

The only exception to the above rules is the rails executable. As of Rails 3.0, the executable simply looks for a script/rails file, and execs that file. The generated script/rails loads the local boot environment, which invokes bundler immediately:

# This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application.
 
APP_PATH = File.expand_path('../../config/application',  __FILE__)
require File.expand_path('../../config/boot',  __FILE__)
require 'rails/commands'

The generated boot.rb is very simple:

require 'rubygems'
 
# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)
 
require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])

In short, the rails executable does a bunch of work to guarantee that your application’s bootstrapping logic runs before any dependencies are loaded, and it uses Kernel#exec to purge the current process of any already-loaded gems. This is not something that general-purpose gems can or should do, and it’s an open question whether making the rails executable work without bundle exec sufficiently muddies the waters with regard to other gems as to render the benefit not worth it.

#268 Sass Basics

Sass extends CSS with variables, nesting, mixins and more. Here I show how to convert plain CSS to SCSS in a Rails 3.1 app.

#268 Sass Basics

Sass extends CSS with variables, nesting, mixins and more. Here I show how to convert plain CSS to SCSS in a Rails 3.1 app.

Practical Tips for Hiring Ruby Web Developers

The topic of ‘hiring’ always generates a lot of discussion. And why not? Talking about hiring is a convenient way to pass judgment on large groups of people while keeping a professional, detached demeanor.. Ouch! But the topic has enough technical basis to warrant the interest of experienced developers, so here we are.

This post is for those who handle the technical evaluation necessary to hire candidates, especially in the Ruby and Rails scenes, although the overall strategies are language-agnostic (though I’d hope if you’re hiring folks to work on missiles and nuclear power plants, all bets are off).

This is a guest post by Tim Goh of Trikeapps, an Australian software development company. More info at the bottom of this post.

Some Structure

While hiring processes differ, I’m organizing my advice by the following components that, assumedly, most processes include:

  • the job posting itself
  • the coding test
  • the phone screen

The Job Posting

You need a permanent “Careers” page

You should have a permanent careers page on your company site and constantly correspond with candidates, even if you’re not hiring at the time. The goal is to populate a queue of developers you can subsequently start to contact the moment you have an opening. This way you hire only after the need, while identifying talent before the need.

You can also continuously refine and test your hiring process against more candidates in this way as well as get a more accurate picture of who’s looking and who’s available, instead of peeking out your window to see who’s there only when you’re hiring.

Include a filter question

You want to easily distinguish the genuinely interested from those who are simply applying everywhere (blasting resumes out semi-automatically has become very common in these shaky times). With the right question you can design a mail filter around the answer and automate away those who aren’t paying attention.

Such a question might be as simple as:

What is the MD5 hash of the string ‘I am not a resume spammer’?

Make the question more difficult if you’re getting too many resumes that qualify at this stage. The Dropbox Challenges and Facebook Puzzles pages have good examples of non-trivial coding questions.

Providing a larger set of questions and making some optional allows candidates to signal their desire, and gives you an easy sorting function to use on your incoming applications. If you want to hire someone who’s particularly creative, their response to the question may also be an indicator of this.

Include more information about your company

Qualified applicants will be more choosy and select a small group of job ads to send their resumes to. Help them make that decision by providing as much information about your company and the role you’re hiring for as possible. Just as you would balk at a resume that solely said ‘I’ve been coding in Ruby since 2008’, a job description of ‘develop web applications using Rails’ would deny valuable data to the talent you’re looking for.

In days of yore it was popular to include the Joel Test in job postings. This is a high signal way to communicate about your company’s processes, and you could follow a similar template.

Job boards may not allow for the best presentation of your company (Ed: Tim is lying, the Ruby Inside Jobs Board is undoubtedly awesome! ;-)). Keep the big information dumps on specific landing pages on your site that you link to — this way you can use analytics to determine how often your ad is read by candidates who are really interested, not to mention which job site sends over more of those candidates.

The Matasano careers page is an excellent template to follow. It goes into exquisite detail and serves as a permanent ad for working at the company. Bonus points for describing their hiring process and even including an FAQ.

It is particularly important to describe what your existing developers are opinionated and passionate about. While you don’t want to turn away qualified candidates, being upfront about potential deal-breakers avoids wasting their time and yours.

Take a look at this YC W11 startup job ad. Although the name of the company and what it does is not revealed, you get a very good idea of what they’re like and who they’re looking for.

A Philosophical Interlude

The tips for the coding test and phone screen assume a set of principles. It is important to have some guiding philosophy when it comes to personnel at your company, lest your culture becomes scattershot and non-discerning.

Most of the time your principles can be boiled down to a single catchphrase, a motto if you will. Perhaps the most famous for developers is Spolsky’s ‘smart and gets things done’. Google has the Lake Wobegon strategy Investment banks and law firms often follow some variant of ‘hire alpha male assholes’.

The philosophy I go by when hiring is: test for the first derivative.

Eric Sink’s post on Career Calculus describes a formula C = G + LT as follows:

C is Cluefulness. It is the measure of how valuable you are to an employer.

G is Gifting. It is defined as the amount of natural cluefulness you were given ‘at the factory’.

L is Learning. It is defined as the rate at which you gain (or lose) cluefulness over time.

T is Time. It is on the horizontal axis of your career graph.

My adaptation: C is redefined ‘cluefulness about your company’s technology stack’. G then naturally becomes ‘existing knowledge of your stack’.

A High-L candidate is a better investment than a High-G

Unless you have a short-term need you have to absolutely fill ASAP, you should always prioritize L. So you should open your positions to Ruby experts who don’t know web development too well, or a highly experienced web developer who does not know Ruby. The latter is particularly valuable because they’ll bring a wealth of experience of alternate solutions for common web development problems.

Testing for G is easy — it’s a pre-defined set of knowledge determined by what you use. The coding test tips and phone screen tips that follow are geared more towards finding L, which dominates the final productivity of the candidate (ie the area under the graph) over time.

Another way of stating this principle is that you’re testing for second-order effects. What a candidate knows may be useful information; but we’re interested in actionable information: what a candidate can do with what they know.

The Coding Test(s)

Do not hire without seeing code written under time constraints. Code samples and open source contributions are great, but not entirely reliable: they often do not give an adequate idea of timeframe involved, plus most developers will naturally choose to code what they like/know.

In the same way you extract frameworks from an app, interview questions should be extracted from actual problems you encountered at work. Chances are you haven’t ever had to write atoi or quicksort recently. And I’ve certainly never output ‘Fizz‘ in any production code. By basing interview questions on a recently-solved problem, you already have a in-house solution to test against, and it is as accurate a simulation of real work you can get.

Note that when picking a recently-solved problem to include in an interview you have the benefit of context and hindsight, both of which the candidate will lack. Test your question on someone unfamiliar with it to gauge its difficulty.

The goal is to test for as many of the following as you can include in a short question:

  • data munging
  • corner case identification
  • working with existing code
  • understanding of complexity

Data Munging

One of the most common programming tasks is to take data in one structure/format and convert it into another. Some developers will do this elegantly in one line, chaining appropriate Enumerable/etc methods. Others will introduce intermediate variables, open up a core class or two (‘because my_array.extract_hash_elements just reads better!’), use a Tempfile, and hit S3 before their curtain call to the xmltojsonfordummies.com API.

A simple way to test this is to have a candidate access a web API that returns xml/json and have them munge the result into a particular format. Code smells to look out for: populating a Hash by hand instead of with inject, unnecessary use of nested arrays, clumsiness with string manipulation.

Here’s a template you can use to base such questions around:

Take the result from http://api.twitter.com/version/statuses/public_timeline.json and output an array that meets the following criteria:

  • has usernames as elements
  • that has the text ‘Ruby’ somewhere in the tweet
  • ordered by follower count of user who posted

If a candidate bloats a simple data munge in an interview, imagine the obesity they can inflict on a code base they work on daily. No hire.

Corner case identification

Even more destructive than a bloaty munger is the eternal optimist coder, who lives in a fantasy land where every input is sanitized, HTTP calls never time out, and exceptions are never raised.

Not being able to identify and deal with edge cases is a straight No Hire. Such developers are a tax on the rest of the team’s focus.

You shouldn’t have to gear a question specifically towards seeing how well candidates do in this regard — most questions have them for free. Just be sure to check for error handling when you review their answers.

Working with existing code

It is much easier to write new code than to grok and work with code you didn’t write. We need to test if a candidate can figure out where to add/remove code, given someone else’s coding style and assumptions.

This is one area that open source contributions predict very well, but should the candidate not have those available, there are many ways to test this:

  • debugging
  • refactoring
  • extending code to add a new feature

The code snippet used here should be similar to the code they’ll encounter on a regular basis. A simple source for such questions is from your company’s internal repository of custom patches for dependencies that never made it upstream.

Sample Questions:

  • Modify Sinatra’s send_file method to optionally support Nginx’s X-Accel-Redirect feature
  • You are trying to profile the load times of gems to figure out why your app takes so long to load. Show a diff of how you would modify Bundler and/or Rubygems to report the metrics you would need.

Understanding of complexity

The ideal half-hour code test question has an obvious n^2 or greater solution, and a not so obvious linear solution. This may be difficult to fit in with the other goals (especially if you’re trying not to reuse well-known questions), so it’s something you may have to test elsewhere.

I generally use algorithmic complexity as a proxy for theoretical knowledge in general. The industry is full of autodidacts, which is perfectly fine, but they need to have had the discipline to spend time grokking the fundamentals that would have been taught it a quality computer science curriculum instead of flitting between surface learning of the newest technologies.

The Phone Screen

Eventually you’ll want to get the candidate on the phone to get a more direct, “in-person” feel for what they’re like and how they express themselves. Welcome to the good old ‘phone screen.’

Structure the interview

Research (PDF) has shown that structured interviews provide a better indication of future job performance. For each question you have, have an established scale that the person conducting the phone screen scores candidates against immediately after each answer.

Phone screens are typically conducted by one person, so structuring the interview reduces bias and gives a better basis for comparing candidates screened by different developers.

Ask open-ended questions

While its meta-commentary on Ruby’s popularity is dated, Steve Yegge’s 2006 post Interviewing Ruby Programmers is still a good source for questions. You’ll notice that most of his questions are very open-ended. This is no coincidence. This is what Stevey has to say on syntax questions:

Language syntax trivia doth NOT a goode programmer maketh. Hiring based on syntax trivia is the last, desperate resort of a weak interviewer. Just say No.

When you ask a specific question for which you have already determined the answer, you are limiting the amount of information you get from their answer and worse still, capping the candidate’s ability to your own.

The basic rule of thumb:

Never test something that takes less than a minute of experimentation to find out in a REPL.

Sample questions:

  • if you were writing a gem to do mocking and stubbing in Ruby, what methods do you think you would use most in your implementation?
  • how would you implement session handling for a feature where site admins can log in as a specific user to test their actions on the site?
  • Jesse Robbins’s favorite interview question

Have conversations about trade-offs

This is something that happens in regular work all the time, and few interviews cater for it. Pick a problem, describe some solutions, and have candidates enumerate trade-offs, and situations in which they would pick one solution over another.

Many website features can be implemented at different layers, and this makes for a rich source of such questions.

Sample questions (note that these aren’t all mutually exclusive):

  • Rails’s use of before_save and after_save advice versus having developers override save.
  • config file in YAML versus configuration in Ruby
  • mocking and stubbing in tests versus hitting the database
  • ESI/SSI versus fragmented caching in templates
  • pre-rendering HTML in a template and toggling display versus adding/removing via Javascript
  • using the Accept-Language header versus IP address geolocation for i18n

Prefer why to how

This is actually a generalization of the trade-off conversation, but more geared towards specific code idioms in your language/framework.

Knowing why they do something is what differentiates quality developers from those who cargo cult. It shows that they deliberate on the code they’re writing and spend time understanding the internals.

Here’s an example of a ‘why’ question on database guidelines design. In the same vein you can ask what they think of an ORM’s naming conventions and the failure modes that it is designed to avoid.

Test protocol knowledge

HTTP is the most important protocol to test for, though you should also touch lightly on a candidate’s knowledge of DNS and SMTP. Candidates should know what request and response headers look like, and what the more common headers are.

Some quick and easy questions that serve as a minimum bar:

On one of your sites, clicking a link to an image results in a downloading the file instead of displaying an image. How would you fix this?

What is your favorite tool for inspecting HTTP traffic? Describe a situation you encountered where you needed to look at the HTTP headers to debug.

Test candidates outside of the framework you use

For many Ruby companies, this means Rails. I’ve encountered a lot of candidates who can do absolutely nothing without their security blanket of ActiveSupport. They can’t perform calculations on datetimes, can’t do metaprogramming without constantize, and generally flounder the instant they have to do something outside of a web request.

Conclusion

Hiring isn’t that painful as people make it out to be. By interviewing all the time and opening up positions to experienced developers unfamiliar with your stack, you should have a much larger pool of people to cull from.

Just make sure you evaluate candidates with the -Wall option enabled. Err towards ‘No hire’ the moment any warning flags are raised.

And while I have you..

Have excellent answers to the questions in this post? My company, TrikeApps, is always looking for Ruby developers in Melbourne, Australia 🙂

This post was contributed to Ruby Inside by Tim Goh — Tim Goh has been the tech lead on web-based Python and Ruby projects since 2006. He goes by ‘keyist’ on Hacker News and Twitter.

Picture credit: Milton’s Red Stapler and Driving! by Mike “Dakinewavamon” Kline – CC Attribution 2.0 Generic (CC BY 2.0) license.

The Rubinius Team Wants to Bribe You (With Stickers and T-Shirts)

You’ve given Rubinius a spin, right? And contributed code to the project? If you didn’t already know, Rubinius is an ‘alternative’ Ruby-sorta-written-in-Ruby implementation that’s production ready and has been going from strength to strength recently (I post about it quite a bit). And whatever your answers to those questions, the Rubinius team are kicking things up a notch by bribing you to get involved!

The Rubinius Rewards Program

The Rubinius team has announced the “Rubinius Rewards” program. The good part is that they have lots of “general availability” stickers and t-shirts available for anyone who wants to write in and claim one. Send an e-mail, get a reward. Until they run out, of course.

If you want to donate financially to Rubinius, they have a Pledgie campaign on the go too.

Special Stuff for Special People

The deeper part of the announcement, though, is that they have some special edition stickers and t-shirts for people who contribute in more direct ways:

  • First Commit Sticker – a sticker given to anyone who makes a single commit to the Rubinius project. Get a single commit into Rubinius and.. you’re good to go.
  • Tenth Commit Shirt – a committer-only t-shirt for people who’ve shown some dedication to the project by getting 10 commits into the project.
  • Quarterly Committer Merit Badges – a quarterly sticker (marked with the quarter and year) sent to all committers during that quarter. Keeping ya hooked.

If you’ve already committed to Rubinius and are hankering for a committer sticker, never fear. Just get in touch with the team as described in the post and they’ll hook you up.

C’mon.. It’s Easy

If you still haven’t got on the Rubinius bandwagon but you’re running RVM, there’s seriously no excuse not to at least give it a quick spin on your current project. Just go rvm install rbx-head and you’re on your way.

Want to go directly to the GitHub repository? You can do that too at https://github.com/evanphx/rubinius

I’ll be posting more about Rubinius, how to tinker with it, and how to get involved with the project over time, but perhaps a little bribery is enough to get some of you to give it a look 🙂

To Infinity and… no beyond – An ActionScript bug…I mean, feature.

So yesterday I was asked about a bug in a legacy Rails and Flex application. There was one company name that wasn’t displayed correctly on the front-end. “Infinity Corp Name” was just displayed as “Infinity”, so nothing beyond infinity. First I thought it was a joke, but not, a real bug that could cause issues.

So I looked at the code and the service call was a plain HttpService call with the resultFormat set to object. The server returns XML but the Flash Player converts the XML to a tree of objects. This is where it get’s funny. In fact when the player converts your hash to Objects it checks if a value is a number or a string…Hey guess what “Infinity followed by something” is a number.

Here are some conversion examples:

String Is Number Converted Number
“123” true 123
“123 Abc” false NaN
“Infinity” true Infinity
“Infinity Abc” true Infinity

It’s the last conversion which is the root of the problem as “Infinity Abc” is a number that when casted translates to Infinity!

So we found the problem but the solution is really don’t use the Flash Player to do the conversion for you using the return type “object”. Use “e4x” which would turn your object in XML or use JSON and do the conversion yourself.

To Infinity… and beyond!

Daniel

To Infinity and… no beyond – An ActionScript bug…I mean, feature.

So yesterday I was asked about a bug in a legacy Rails and Flex application. There was one company name that wasn’t displayed correctly on the front-end. “Infinity Corp Name” was just displayed as “Infinity”, so nothing beyond infinity. First I thought it was a joke, but not, a real bug that could cause issues.

So I looked at the code and the service call was a plain HttpService call with the resultFormat set to object. The server returns XML but the Flash Player converts the XML to a tree of objects. This is where it get’s funny. In fact when the player converts your hash to Objects it checks if a value is a number or a string…Hey guess what “Infinity followed by something” is a number.

Here are some conversion examples:

String Is Number Converted Number
“123” true 123
“123 Abc” false NaN
“Infinity” true Infinity
“Infinity Abc” true Infinity

It’s the last conversion which is the root of the problem as “Infinity Abc” is a number that when casted translates to Infinity!

So we found the problem but the solution is really don’t use the Flash Player to do the conversion for you using the return type “object”. Use “e4x” which would turn your object in XML or use JSON and do the conversion yourself.

To Infinity… and beyond!

Daniel

[ANN] Rails 3.0.8.rc2

Hey folks! I’ve pushed 3.0.8.rc2.

I want to give a big thanks to Philip Arndt and Robert Pankowecki for reporting regressions in 3.0.8.rc1! We’ve fixed the regressions, so I pushed an rc2.

To see the diffs for this rc, check out the commit list on github.

Since we’ve released a new release candidate, I’ll target the final release for June 1. If you find regressions between v3.0.7 and v3.0.8.rc2, please let me know and we’ll do another rc!

Thanks everyone!

$ curl 'http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/383777' | ruby -n -e'print $_.gsub(/rc1/, "rc2")'

To Infinity and… no beyond – An ActionScript bug…I mean, feature.

So yesterday I was asked about a bug in a legacy Rails and Flex application. There was one company name that wasn’t displayed correctly on the front-end. “Infinity Corp Name” was just displayed as “Infinity”, so nothing beyond infinity. First I thought it was a joke, but not, a real bug that could cause issues.

So I looked at the code and the service call was a plain HttpService call with the resultFormat set to object. The server returns XML but the Flash Player converts the XML to a tree of objects. This is where it get’s funny. In fact when the player converts your hash to Objects it checks if a value is a number or a string…Hey guess what “Infinity followed by something” is a number.

Here are some conversion examples:

String Is Number Converted Number
“123” true 123
“123 Abc” false NaN
“Infinity” true Infinity
“Infinity Abc” Continue reading “To Infinity and… no beyond – An ActionScript bug…I mean, feature.”

Building Rails Apps for Rich Client – Using the bulk_api from Flex.

In this screencast we are going to show how to build a Rails app in a couple of minutes that is optimized for Rich Client. The application is a todo application build in Flex connecting using the bulk_api to the Rails server using my new bulk data source Flex framework.

Enjoy!

Daniel

Building Rails Apps for Rich Client – Using the bulk_api from Flex.

In this screencast we are going to show how to build a Rails app in a couple of minutes that is optimized for Rich Client. The application is a todo application build in Flex connecting using the bulk_api to the Rails server using my new bulk data source Flex framework.

Enjoy!

Daniel

Can I have your attention please?

So, apropos of nothing, and after RailsConf, some thoughts on public technical speaking. You’re not going to read about how to arrange your slides here, not least because I’m pretty bad at the fancy slide thing. Instead, I want to talk about working the room. This is what I try to do when I give a technical talk.

You should think of this kind of presentation as a performance. You have a story to tell and information to share, and you want the audience to pay attention to you. (One reason why I don’t push too hard on fancy slides is that I want the audience to pay attention to me, not the screen.)

The key to a successful performance is energy. Energy means that you come off as excited and happy to be there, and interested in your subject — interested people are (to a point) the most interesting. Energy means speaking with inflection and volume. Energy doesn’t just come from the speaker, it comes from the audience, and their attention to the speaker. Even in a quiet room, you can tell the difference between an audience that is paying attention and one that is not.

Any stand-up comedian will tell you that you get the best energy from a room when people are close together and when you are relatively close to them. Picture your classic comedy club. The tables are close together, the performer is only a few inches higher, at most. Also, everybody is drunk, but that’s generally not an issue at a tech conference. At least not in the morning…

Anyway, picture your typical conference setup. A hotel ballroom, badly lit. The speaker can easily be 10 feet from the audience, and the audience somewhat spread out, and often with computers as distractions. Sometimes the speaker is set up far away from the projector screen and it’s not easy to move around. Granted, you’re not trying to be Bill Cosby up there, but your job is getting and keeping everybody’s attention, and that means fighting the room.

You’ll never have more attention than you will right at the beginning of your talk. Take advantage of that moment. Do something up front to engage the audience. Surprise them a little. This doesn’t mean “open with a joke” — for God’s sake, don’t open with a joke unless you are about 120% sure the joke will land. It does mean starting off by asking a question, or calling out to the audience in some way. At RailsConf, I started with an unrelated slide that was a kind-of-funny session title of a Medical conference in the same building. At RedDirt, Jeff Casimir dared the audience to close their laptops or give him the finger for twenty minutes, which got my attention.

It’s a classic stand-up trick to start with a “Hello, Cleveland” or something to get a cheap applause line up front. (When I was in college, I would go on stage with a tape recorder, and ask the audience to laugh and applaud so I could play it for my Mom. Cheap. Effective.)

The key, though, to dealing with an audience is to both be and appear responsive. Don’t hide behind a podium, if you can help it. Pay attention to whether people look confused. I like allowing questions during a talk unless there’s a really good reason not to, because interactive tends to be more engaging, but you do need to be ready to cut somebody off if needed to get on with your material.

Preparation always helps. It’ll also help you be less nervous. There are three kinds of useful practice for public speaking.

First, of course, is practicing the content of your presentation. I’m not really giving tips here on how to structure a technical talk, but your goal here is to be comfortable enough with your material to remove that as a source of nervousness as you speak. Another way to look at that is the less effort you need to place in deciding or remembering what to say, the more effort and attention you can pay during the presentation to observing the audience and monitoring how things are going.

I will say that I’m not a big advocate of writing down your talk verbatim — my experience is that it’s hard to read something word for word in public and have it sound natural. Normally I write an outline (usually it becomes my slides), and occasionally use brief notes to remind me of specific points I don’t want to forget. The reason for knowing your content well, though is not so that you can deliver it perfectly from memory, but so that you can free yourself up to be flexible during the actual presentation.

I find it hard to do a full-energy version of a practice talk when it’s only me, and I recommend not even trying — fake enthusiasm isn’t helpful. When you practice by yourself, it’s about the content first, and secondarily about the physicality of the performance itself. The actual physical act of delivering a talk is the thing that I suspect people don’t practice enough. Just standing in more-or-less one place is a challenge. Even at home, try to practice in as close to the real setup as possible. Stand up. Understand how far from your computer you can be and still have the remote work. Try not to pace unrealistically (I fail at that, I tend to walk all over when I practice). Try not to stop, so you get used to talking for 45 minutes.

On a related topic, if you get a chance to scope out the actual room before you talk, do that. Being early and making sure that technical stuff is in place will make you less nervous, and give you some time to scope out the audience before you start.

Finally, you want to practice in front of an audience in general. Every chance you get to realize that the audience is unlikely to eat you if things go badly is helpful. There are things you will only learn by getting used to seeing an audience in front of you. Talk to specific people. Try and get feedback. If possible, watch video of yourself, you’ll definitely see something you can get better at. When I was a high-school performer, a director had me watch a fast-forwarded version of a performance, which really exaggerated a habit I had of swaying back and forth. Being aware of these habits will help you get rid of them.

Oh, and that thing about picturing the audience in their underwear… Don’t do that. It doesn’t work.

Filed under: Uncategorized

[ANN] Rails 3.0.8.rc1

ZOMG HI EVERYBODY!!!! HAPPY WEDNESDAY (UTC-7).

I am EXCITED, PLEASED, and even MORE EXCITED to announce the release of the
Rails 3.0.8 released candidate NUMBER ONE!

OMG RELEASE CANDIDATE. WHAT DOES IT MEAN?

This is a release candidate! It means that we (the rails core team) are asking
you (our lovely users) to test out the code that we’d like to release!

This is your chance to VETO our release of Rails 3.0.8 final!

VETO?? WHY WOULD I DO THAT?

Well you see, dear public, let me explain. In order to bring you this latest
and greatest released of rails, we’ve made bug fixes and changed codes.
Unfortunately, that means that we may have inadvertently broken your
application. We don’t want to break your application, we want to fix bugs!

This is your chance to try our the release candidate and let us know if we’ve
broken your application!

HOW DO I TEST YOUR WONDERFUL AND AMAZING RELEASE CANDIDATE?

Very simple! If you’re using bundler, just update your Gemfile to point at
rails version ‘3.0.8.rc1’. Then do a bundle update, and you’re off to the
races! Make sure your application behaves normally, all your tests pass, etc.

I think I’ve found a boog! How do I veto???

It’s easy, breezy, beautiful, to veto! Just reply to this on the rails-core
mailing list
, and let us
know what went wrong! We’ll fix the problem and cut another release candidate.

Make sure to check that your failure does not occur on Rails 3.0.7, but does
occur on the release candidate. If the failure is also on 3.0.7, we still want
to know! It just won’t block our release.

TELLME THE CHANGES YOU’VE MADE!

Ok, just calm down. For now, go check out this link on github.

Or go check out the CHANGELOG files in each project. When we release the final,
I’ll add the changelog to the announce email.

WHEN WILL THE FINAL RELEASE BE??? TELL ME NOW!!!

Typically we release the final version 72 hours after the release candidate.
But this weekend is a holiday, so I don’t feel like doing a release this
weekend. Instead, I will target the final to be released on May 31st.

If we find show stopping bugs, we’ll release another RC and the 72hour counter
will reset!

WHY AREN’T YOU RELEASING ON THE WEEKEND? COMMON, BRO.

What?!?! Why aren’t you releasing on the weekend??? I’m going to be making
sausage. 😛

Thanks everybody!!!!

<3 <3 <3 <3 <3 <3

Thanking Ruby Inside’s April and May 2011 Sponsors (Training, Haml Conversion and More)

Ruby Inside wouldn’t be what it is without you, eager reader, but it’s time for us to thank the companies who help to keep Ruby Inside going by kindly sponsoring our work. Thanks to all of you! We take care not to accept sponsors who have little of interest to the Ruby scene so hopefully you’ll find out something useful from the below 🙂

Jumpstart Lab – Rails Training Experts

Jumpstart Lab, headed by Jeff Casimir, is a training company specializing in Ruby on Rails. Their classes are usually two days long and while their prescheduled classes tend to be in Washington DC, where they’re based, they’ll travel anywhere if you have (or can find) at least six attendees.

Jumpstart calls their training “computer science for normal people” because they jump straight into working on real projects right away and they promise to offer “the best training class you’ve ever taken, guaranteed.” Join NASA, Boeing, Raytheon, The Motley Fool, and GitHub in picking up some training from Jumpstart – they even have a 110% money back guarantee.

New Relic — On-demand Application Management

New Relic is a full-stack Java, Ruby, PHP, and soon Python, application performance and management app that started life as a Rails-only service.

New Relic has long dominated the performance monitoring scene, particularly amongst Rails apps (folks like 37signals and Shopify use them heavily), but they’ve not rested on their laurels. Just a couple of weeks ago they released a Real User Monitoring service which goes right down to the customer experience. How quick pages load, how quick the pages are to render, etc. Deep and powerful stuff and the most loyal sponsor we’ve had so far 🙂

Trivia I Always Have To Point Out: New Relic is an anagram of founder Lew Cirne’s name. Geddit?

Slicecraft – Your Designs Converted to Haml and Sass

Slicecraft is a ‘design to HTML’ conversion company with a difference – they work with Haml and Sass and can deliver your translated design in these formats, ready to drop into your Rails app. The first time I’ve seen this feature specifically highlighted – cool!

6sync – VPS Hosting for Rubyists

6sync is a VPS company that promises “hosting nirvana” in minutes! No strings month-to-month billing and instant deployment. They go from 256MB instances up to 4 processor 8GB behemoths.

Chef Tips

One of the best things that came out of using EngineYard Cloud was learning about Chef. Chef has changed my world when it comes to managing servers, and I now wouldn’t do any amount of system administration without the kind of automation and scriptability Chef provides. Here are a couple of tips on the reasons for and the benefits of using Chef.

Continue reading “Chef Tips”

Chef Tips

One of the best things that came out of using EngineYard Cloud was learning about Chef. Chef has changed my world when it comes to managing servers, and I now wouldn’t do any amount of system administration without the kind of automation and scriptability Chef provides. Here are a couple of tips on the reasons for and the benefits of using Chef.

Continue reading “Chef Tips”

Chef Tips

One of the best things that came out of using EngineYard Cloud was learning about Chef. Chef has changed my world when it comes to managing servers, and I now wouldn’t do any amount of system administration without the kind of automation and scriptability Chef provides. Here are a couple of tips on the reasons for and the benefits of using Chef.

Continue reading “Chef Tips”