Topic Browser

It's been a great year for Ruby on Android, but no one knows it. You can start writing Ruby apps for Android devices TODAY. You don't need to install any SDK, you don't need to install some giant Eclipse IDE, and you certainly don't need to write any Java.

Mike Leone

In Turn your Android Phone Into a Remote Spy Camera with Ruby in 15 Minutes, Mike Leone demonstrates how to use Ruby, Sinatra and Scripting Layer for Android (SL4A) to build and deploy a phone-hosted "spy camera" Web service.

SL4A is a system that allows you to run "scripting language" scripts and interactive interpreters on the Android platform. It currently supports JRuby, Python, Perl, Lua, JavaScript, BeanShell, and Tcl. Mike demonstrates how to set up a Sinatra project to use SL4A to run on an Android phone using JRuby. Upon receiving a request, Mike's app takes a picture using the phone's camera and serves it back over HTTP. He has also released the source code to a larger Ruby app called Broadcast that implements general Android device management functionality over HTTP.

Even if you don't want to build a "spy camera", Mike's walkthrough is a must-read if building Web services in Ruby that can run directly on the Android platform is of interest to you.

With over 80,000 applications on Heroku, we are frequently asked what type of apps people are building. While there’s a wide range, one of the areas I’ve been most excited about is social apps. We have thousands of social applications around Twitter, Facebook, and other platforms. The Social App Workshop last month was proof of the interest with a sold out crowd of over 150 people filling a basement on a great summer Saturday.

Social platforms are sweeping enterprises as well. From internal communities for collaboration to external communities with millions of users, enterprises are finding social software essential to how they work. Today we’re announcing a partnership with the leader in this space – Jive Software. Over 3,000 leading companies, including over 25% of the Fortune 100, use the Jive platform to engage their employees, customers and partners.

If you are interested in building social applications for the enterprise and reaching millions of employees, we have a great opportunity for you. For the first time, Jive is opening up their platform to 3rd party application developers. Their new Jive Apps Market will make it easy for customers using the Jive platform to purchase cloud-based social app software. You’ll be able to deploy your applications to Heroku, and have companies from around the world view, purchase, and use your app within Jive. Jive is leading the way in bringing cloud social business applications into the enterprise, and we’re honored to be part of it.

To help you get started, Jive is holding their first ever Jive Apps Developer Event on September 16th at the San Francisco InterContinental Hotel. This is a great opportunity to both evaluate the size of the Jive Apps opportunity by mingling with enterprise customers as well as get the technical details from Jive engineers.

Jive and Heroku have teamed up to offer 10 free passes to the event. If you’d like to enter to win one of the passes, fill out this survey before Sept 2nd.

A few of us participated in the Node Knockout this weekend. Our team built a real-time, multiplayer tower defense game named after this very site.

We’re all fairly new to Node, but it was a breeze working with express, a Sinatra like framework, and socket.io, a socket library with several transports for cross-browser support. The client uses canvas, CSS and JavaScript with some fancy graphics. We’re really looking forwarding to working on it more after the voting ends this Friday.

If you can find time between games, vote for it and the other awesome entries. And if you participated this weekend in an attempt to win some awesome gloves let us know what libraries you used.

RubyDoc.info is a new, automatically updated Ruby documentation site by Loren Segal and Nick Plante that builds upon their earlier success with rdoc.info (which we posted about in 2009). It's powered by YARD, a tool that puts out great looking Ruby documentation (there'll be more about YARD in a post later this week).

RubyDoc.info automatically generates documentation for all gems on rubygems.org (it updates its index once per day) but it does GitHub-hosted projects too. For RubyDoc.info to automatically update with documentation for your Ruby-related GitHub project, use the "Add Project" link on RubyDoc.info and then add http://rubydoc.info/checkout as one of your post-commit hook URLs in your repository's settings - on each future commit, your latest documentation will be built on RubyDoc.info.

RubyKaigi is Japan's "home" Ruby conference and the organizers have just put 27 videos from the RubyKaigi 2010 conference online. Unfortunately I can't link to them individually as they're embedded on a single page, so head over to rubykaigi.tdiary.net and check them out.

Presentation titles include: Ruby 2.0, Ruby API is Improved Unix API, Rocking The Enterprise With Ruby, Mapping the World with DataMapper, The Necessity and Implementation of Speedy Tests, A Metaprogramming Spell Book, Conflicts and Resolutions in Ruby and Rails, and User Experience for Library Designers.

Two caveats: 1) Be aware that some of the presentations are in Japanese (unsurprisingly) although most of the slides include English and, of course, any Ruby is still readable. There were also several English language speakers including Sarah Mei, Carl Lerche, and Jake Scruggs. 2) The player/hosting for the videos seems to be super slow. Give it time and they'll load.

[jobs] Engine Yard are hiring! Did you know that Engine Yard - one of the biggest and brightest companies in the Ruby world - are hiring? They have Ruby Engineer and Ruby App Support Engineer positions open in San Francisco.

Rails 3.0 has been underway for a good two years, so it’s with immense pleasure that we can declare it’s finally here. We’ve brought the work of more than 1,600 contributors together to make everything better, faster, cleaner, and more beautiful.

David Heinemeier Hansson

DHH rings the bell and announces that Rails 3.0 (final) has been released after two years of determined effort by the Rails core team. Grab it now with gem install rails --version 3.0.0 or, if you're in no rush, Rails 3.0.1 might come along within a week or two.

The Videos

DHH gives a quick roundup of some of Rails 3's new features but like Emma Watson's head PhotoShopped onto yet another naked body, it's nothing you haven't seen before. If you're really fresh to Rails 3.0, though, Gregg does an admirable job of boiling everything down into a digestible format with his (free!) Dive Into Rails 3.0 screencast series:

• Getting Started and Action Dispatch
• Bundler and Action Mailer
• Active Relation and Active Model
• Cross-site scripting and Unobtrusive JS
• The New Action Controller

Ryan Bates has also produced a fistful of his typically succinct but precise RailsCasts videos on a wide array of Rails 3.0 topics. Ryan always focuses on code and practicalities so these are a good place to start if you want to follow along and do some coding yourself:

• Upgrading to Rails 3.0: Part 1, Part 2 and Part 3
• Routing in Rails 3
• Active Record Queries in Rails 3
• Advanced Queries in Rails 3
• Controllers in Rails 3
• Rack in Rails 3
• Subdomains in Rails 3
• Active Model
• Generators in Rails 3
• Making Generators in Rails 3
• Validations in Rails 3
• ERB Blocks in Rails 3
• Action Mailer in Rails 3
• XSS Protection in Rails 3
• Bundler

If you don't like videos, still follow the links, because there are links to the ASCIIcasts regular HTML versions of the Railscasts videos. These are regular blog posts that you can follow at your own pace.

EuRuKo is the brand of Europe's principal Ruby conference series and EuRuKo 2010 took place in late May. Why, then, am I posting about it in August? First, I'm a strong supporter of EuRuKo and promised to post a roundup of the event here. Secondly, it turns out it took a while for the videos to all be uploaded ;-) Third, I've taken my time in getting round to it. Nonetheless, there are some amazing presentations you can watch and they're still fewer than three months out of date!

One of the event's organizers, Ela Madej, gives a summary:

European Ruby Conference 2010 is now well over and the Berlin EuRuKo 2011 team are surely working on their opening song for the next year. Yes, we all know they sing well - their uber-strong German vocal was nothing but adorable.

Despite the flooding and changing the conference venue just one week before the event, EuRuKo was great! It was filled with fantastic talks and Rubyists from all over the planet. Here are some numbers: around 121 Poles (less than half of all 280 attendees), at least 40 Germans, Rubyists from Japan, Austria, Spain, UK, Switzerland, Uruguay, USA, Cuba, Slovakia, Czech Republic, Slovenia, Croatia, Estonia, The Netherlands, Latvia, Italy, France, Belgium, Brasil and more.

For everyone who missed the event, the videos from the conference are on Vimeo. There is also a great summary of the talks for Day One and
Day Two. Here are the links to EuRuKo official photos on Flickr for Day One and Day Two also.

Ela Madej

While there are 37 videos on offer, some standouts include:

• Let's Remodel That Game by Tim Lossen.
• How to Rate A Rails Application by Elise Huard.
• Mislav Marohnić talks about how code is loaded in Ruby (in quite some detail!)
• Spoiling the Youth with Ruby by Karel Minarik (organizer of EuRuKo 2008)
• Matz's keynote
• DSL or no DSL by Jose Valim (of Rails core)

EuRuKo is supported by not only by Rubyists paying to attend but by quite a few sponsors, with 2010's event no exception. The organizers asked me to specially thank their biggest sponsor Novelys - a team of French Ruby on Rails experts. On top of that, EuRuKo's afterparty sponsors were Applicake and Lunar Logic Polska, two Ruby development teams from Poland. Finally, 16 micro sponsors helped out too.

I've been a keen supporter of EuRuKo since the first event so a big thanks to all of the sponsors and attendees for supporting Ruby's principal Ruby conference. Now, go enjoy those videos.

We had a lot of fun last week on the Cape. Here’s a small recap of the mini-projects, open source work, and more that we managed to get done between hot tubbing, s’mores on the beach, and some Rock Band.

Code Katas

Dan Croak and Brian Mulligan sparred with Uncle Bob’s Bowling Game Kata as a TDD exercise. The fruits of their labor are on github. In related news, our pals at EdgeCase started Ruby Koans, a great site to be enlightened about Ruby.

Node.js Websocket Mice Explosion

I wanted to learn more about Node.js, and this blog post was a great inspiration. I ended up getting the small example from the Jeff’s blog working and showed it off during our lightning talks.

who

Mike Burns took a look at how we write controller actions and how conditionals are handled in languages like Smalltalk or the Either type in Haskell. He thinks we can do better in Rails. A little taste:

class UsersController < ApplicationController
  def create
    User.create_from(params[:user]) do |result|
      result.success(redirect_to_object_with("User created!"))
      result.failure do |user|
        flash[:error] = "You fail."
        redirect_to root_url
      end
    end
  end
end

This is still incubating but hopefully we’ll see it soon!

CSS3 Ralph

Our newest designer Phil LaPier whipped up an all CSS version of Thoughtbot’s mascot, Ralph. Feast your eyes upon its magnificence here. Make sure to bump the font size, too!

Loxosceles

Josh Clayton started learning C during the trip and got his toes wet by starting a graph database called Loxosceles. Also of interest: NoSQL Summer Boston is discussing graph transversals tonight, if you’re up for a swim.

Layer Tennis match

Inspired by the pros, Kevin and Phil decided to have their own match. Check out the results here.

I hope this will be a more regular event for our designers, how about you?

paperclip storage refactoring

Jon Yurek has a lot of requests for other storage engines with Paperclip, other than the filesystem and using S3. A new gem isn’t released yet, but the necessary refactoring was done to allow this to happen. Review the patch here!

GIT INCEPTION

I tossed together a little talk about some underused git tricks. My favorite from this set: git notes, which is now supported by GitHub too. Plant some ideas in your mind.

Gemcutter Hacking

Matt Mongeau and I worked on pushing out some changes on Gemcutter/RubyGems.org. We finally got around to deploying changes to move over to the fantastic Fog library for talking to S3, and also a new endpoint to hopefully speed Bundler up with some Redis magic. A small sample of what we whipped up is here.

PORM

Mike Burns and Harold Gimenez took a crack at a Ruby ORM for PostgreSQL that fully embraces PostgreSQL’s features making it Postgres-specific. They spent a few hours working on the DDL, INSERT, and SELECT aspects (which later influenced Who, mentioned above) before working on the Postgres fun: check constraints for validation, not null, unique, and foreign key constraints. They spent some time adding support for most postgres data types, and took a crack at supporting table inheritance.

The following is working code, which creates a users table and an admins table which inherits from users. No more STI.

class User
  include Porm::Table

  attributes do |t|
    t.string    :login, :null  => false
    t.integer   :age,   :check => '(age >= 18)'
    t.ip        :last_ip_address
  end
end

class Admin < User
  attributes do |t|
    t.boolean :super_user
  end
end

effigy on rails 3

Joe Ferris worked on Rails 3 integration for Effigy, his chaos-free view engine. Check out the README for more info on using it and integrating it with your app.

Awesome StyleSheets

Tristan Dunn cooked up a new alternative to CSS to ease the pain. Here’s some of the syntax his parser supports:

:button {
  font-size: 36px;
}
:button < div h1 {
  font-size: 72px;
}
div {
  background: #4C4;  
  padding: 16px;
}
div h1 {
  color: complementary;
}

Nothing’s released here yet, but if you’re interested let us know!

See you next time!

We’d love to see you at the next capeco.de, so make sure to stay posted by following us here. We had a lot of fun last week and we hope you’ll be along for the next one.

This upcoming Monday, September 20th is the Mongo Boston conference at the beautiful NERD center - with the best view of Boston in the area.

We have been developing a MongoDB-backed Rails application that has grown past the “small app” level. I will be presenting a talk about the state of MongoDB Ruby libraries, how we’ve used them, how we’ve integrated with testing frameworks and other libraries like Paperclip, and some of the pitfalls to look out for. There will be code.

There are many interesting talks lined up, a hack session for many languages including Ruby, and many talks around MongoDB schema design, indexing and other great topics. At only $20, don’t miss out!

It's time to unveil my latest project: Ruby Weekly, a once-weekly e-mail roundup of 10-20 Ruby related links with a few sentences on each. It's had a brief alpha testing period and it's now ready to roll.

Click here to subscribe to Ruby Weekly - it's a one click process. It's also ultra simple to unsubscribe if it's not eventually to your taste.

There's been a renaissance in e-mail newsletters in the last year or two and it seemed, to me, to be a great way to get programming related news. It's not for everyone (so Ruby Inside will be staying around, I assure you!) but if you want to avoid distractions and just get a summary once a week, it's a great alternative to reloading Twitter or Google Reader over and over. The popularity of the Ruby5 podcast proves there's an appetite for Ruby news in different media (and if you prefer audio, check them out).

As well as featuring links and (very) brief summaries, the weekly e-mail will also occasionally include new event, book, and job announcements and, if something significant is going on in Rubyland, a few paragraphs of editorial. The aim, though, is to keep the e-mail reasonably brief, in a plain format, and, above all, useful.

Ruby Weekly goes out once a week on Thursdays, so if you subscribe within the next 16 hours or so, you'll get this Thursday's edition (issue #4).

Being a designer, I’ve got a style I’m comfortable using to get the job done. This is a style that everyone is pleased with and can always be my go to method for creating a successful design. As fun as producing the same great design that impresses everyone is, I often want to explore new styles and try new things.

A predicament that I’ve always had with new projects is whether to try new things or stick with my tried and proven method of creating quality work. I’ve done both and never had a project fail or succeed because of the approach I chose to take. I have been happier with the result when using my standard styles and sticking inside my comfort zone. However, when experimenting with new styles I’ve grown as a designer and learned quite a bit. So which is the right path to take? In the end I definitely think the design path I choose to take needs to cater to the project specifics but that’s not to say the aesthetics won’t be influenced by styles I’m comfortable using.

Another issue that plays a factor is the thoughtbot design style. Do we have one? Do clients hire us in part because they like our specific style or just because they trust that we are good at design? I know some agencies like Happy Cog and MetaLab have very recognizable styles and are probably often hired because a client wants that style. If thoughtbot is hired to produce our style and I experiment with new things but still succeed in producing great design, is this a disservice to our clients?

I feel that since I’m a designer, I’m a creative individual and as long as it’s in the best interest of the project, I’m going to try whatever I want. I’m not a machine that just outputs good work, I am a constantly evolving source of fresh design. If you continue to produce the same exact work in any walk of life, you’ll never get better and it’s always a goal of mine to be constantly improving.

Jesse Bennett-Chamberlain had something very interesting to say about his recent Steinway project:

One of my personal goals for this project was to get away from relying on the same techniques that I’ve become comfortable with over the years… and it was actually harder than I thought it would be. I found myself resorting to the same button styles, shading techniques, etc… and having to force myself to go back and change things up. I figured that if these guys can spend a year making a single piano, I could probably spend an extra couple hours here and there on refining these details.

It’s nice to know that other designers make an effort to veer away from their comfort zones in an attempt to make the client happier. As a designer, how do you feel about experimenting during client projects? Do you always stick to your comfort zone or do you try new stuff? As a client how do you feel about a designer’s approach? I’ve always been curious about these things and look forward to hearing some responses in the comments.

SimpleCov is a code coverage analysis tool for Ruby 1.9. It uses 1.9’s built-in Coverage library to gather code coverage data, but makes processing it’s results much easier by providing a clean API to filter, group, merge, format and display those results, thus giving you a complete code coverage suite with just a couple lines of code.

Christoph Olszowka

SimpleCov builds on the ideas presented in Aaron Patterson's recent, and awesome, Writing a Code Coverage Tool with Ruby 1.9 blog post. The result is a powerful yet straightforward code coverage tool that puts out some well formatted stats.

http://github.com/jeremyevans/home_run (or on Ruby Inside)

home_run is an implementation of ruby’s Date/DateTime classes in C, with much better performance (20-200x) than the version in the standard library, while being almost completely compatible.

Jeremy Evans

Jeremy Evans (of Sequel fame) has created home_run, a performance-focused C reimplementation of Ruby's Date and DateTime classes. They work out to be significantly faster than the native Ruby classes while retaining compatibility (mostly).

Jeremy makes the surprising claim that "the standard library Date class is slow enough to be the bottleneck in much (if not most) of code that uses it", but goes on to prove the point with a Rails related benchmark where retrieving all objects for two different models get a 2x and 3x speedup when using home_run.

I hope that Jeremy ultimately aims to get his work included into MRI (as happened with FasterCSV replacing CSV in the stdlib) as standard.

I was stuck for a while when application maintained by me have started throw ArgumentError: marshal data too short errors in random places. Or at least they looked for random places. When user have encountered that problem then it was unable to use application at all.

Marshal CC http://www.flickr.com/photos/qmnonic/

Logs were showing that it happens when Rails was trying to create session object. Session store was in ActiveRecord and sessions table was not corrupted.

After watching that for a while it have shown that places in code were this exception was thrown were random but there was some pattern. Page visited before was common in each case.

It have turned out that application was storing in session whole ActiveRecord object. Like:

 session[:some_info] = @variable

And later we were trying to use that way:

@variable = Model.find session[:some_info]

Due to Rails magic AcitiveRecord’s find when provided with AR object will return that object (of course if is the same model). Code was working well (maybe not very effectively since You should avoid storing large objects in session) until object stored that way started to grow. Application was collecting some data and amount of data stored have grown to that point that after Marshal.dump size of string was more than 64 kB. And this is default size of text field used to store session data in MySQL.

When You try to store too much data in text field in MySQL, excessive data is being truncated, so Marshal.load throws that exception.

To have that error solved is enough to store just object id in session (session[:some_info] = @variable.id).

Last month’s Social App Workshop was a huge success. With a sold out crowd of over 150 people filling the basement of our new office, a great lineup of presenters and some fun coding in the afternoon it surpassed our expectations. Social App Workshop is a hacker event for new and experienced developers working on Twitter & Facebook apps. With a combination of presentations and coding the workshop brings developers together to work on social apps.

The morning was spent with a combination of 10 min talks and 30 min talks from Facebook, Twitter, Heroku, Apigee, Twilio, and Abraham Williams. After getting everyone amped up in the morning, we broke into groups in the afternoon to code up fun projects. Projects ranged from sample apps using oauth for twitter to a wake up call service for travelling moms.

If you weren’t able to make it, we’ve posted all the videos of the talks and embedded them below as well.

We’re working with Dave Nielsen to hold additional Social App Workshops, both here in San Francisco as well as around the world. If you have ideas or would like to see this type of event in your town, leave us a comment and let us know!

Yuki (Yugui) Sonoda has just announced the release of the stable version of Ruby 1.9.2!

Ruby 1.9.2 has been released. This is the newest release of Ruby 1.9 series. Ruby 1.9.2 is mostly compatible with 1.9.1, except the following changes:

• Many new methods
• New socket API (IPv6 support)
• New encodings
• Random class that supports various random number generators
• Time is reimplemented. There is no longer the year 2038 problem.
• some regexp enhancements
• $: no longer includes the current directory.
• dl is reimplemented on top of libffi.
• new psych library that wraps libyaml. You can use the library instead of syck.

Yuki Sonoda

Ruby 1.9.2 passes 99% of RubySpec and, if you haven't already given it a go, offers worthwhile performance increases over Ruby 1.9.1 and significant performance improvements over the 1.8.x series.

Intriguingly, Ruby 1.9.2 is only considered to have full, verified support on Debian Linux on 32 bit Intel architectures, with support for OS X 10.5 and 10.6, FreeBSD, Windows, and Solaris considered "best effort." Linux distributions other than Debian are listed in the lower "perhaps" category for support, so running your own tests is more essential than ever before moving to 1.9.2 in production.

Installing

As always, the source can be picked up from the official sources at ruby-lang.org:

http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.gz
http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.bz2
http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.zip

Or, you can use RVM, which has already been updated to support the release:

rvm update --head && rvm reload && rvm install 1.9.2 && rvm 1.9.2 --default

http://labs.headlondon.com/2010/07/skinny-daemons/ (or on Ruby Inside)

[W]e’ve been having a lot of fun writing a series of small, self-contained web apps .. When we’re building these kinds of applications, which are often meant as low-ceremony apps targeted at a very specific purpose, or as service utilities, a lot of the time we don’t want to go through the hassle associated with a “normal” web app. [..]

Dave Hrycyszyn

In Skinny Daemons, Dave Hrycyszyn presents a practical walkthrough of how he builds what he calls "skinny daemons" - small, HTTP based daemons to perform single tasks that are then packaged up into gems for easy installation (across multiple servers, for example). It's a practical demonstration and holds your hand the whole way. Useful stuff.

http://mongomatic.com/ (or on Ruby Inside)

Back in June, I did a comparison of Mongoid and MongoMapper, the two best known MongoDB libraries for Ruby. Now, Ben Myles has brought another to the fore: Mongomatic.

Mongomatic is a Ruby library that lets you easily model your MongoDB documents in your applications.

The primary design goals of Mongomatic are simplicity and adherence to MongoDB conventions. Mongomatic is not an ActiveRecord clone and has been designed to fit nicely with the document-oriented nature of MongoDB.

Features include cursors, hash access to your document and embedded documents, validations, callbacks and conventions for creating indexes and relationships.

Ben Myles

I haven't given it a try myself yet, but Ben's done a good job of presenting it, along with example code, so check it out if MongoDB is your bag.

If you want more MongoDB related news, check out coder.io's #mongodb tag. Lots of great stuff there.

SunnyConf is a single-track, one day conference taking place Sept. 25th in sunny Phoenix, AZ. There will be 8 speakers and a keynote, as well as lightning talks. Speakers include:

• Jeremy Ashkenas (keynote speaker)
• Les Hill & Jim Remsik of HashRocket
• Charles Nutter (of JRuby fame)
• Blake Mizerany (of Heroku and Sinatra fame)
• and more!

Check out the official SunnyConf Web site to see other speakers and keep up to date on the conference. Tickets are priced at $100. A limited number of seats are available, so get your tickets now!

If you missed out on RubyConf, which sold out just a few days ago, this could make for a good tonic.

http://engineering.attinteractive.com/2010/08/code-coverage-in-ruby-1-9/ (or on Ruby Inside)

Aaron Patterson (of Nokogiri fame) has written a post for the AT&T Interactive blog about writing a code coverage tool with Ruby 1.9:

You probably didn’t know this, but code coverage is actually a miracle. Who knows how it works? Oh wait, it’s exactly opposite of what I just said. It’s not a miracle, and we can learn how it works.

I’m not going to go in to depth, but this tool works by hooking in to Ruby's virtual machine...

Aaron Patterson

It turns out that Ruby 1.9 already comes with support for code coverage monitoring. Aaron looks at how it works and improves how we interact with it a shade.

Bundler is quickly shaping up to meet all it’s promise as THE best way to manage your application dependencies. This afternoon we updated Heroku to the latest version – 1.0.0RC5. RC5 addresses all known outstanding issues including the git sourced gems. You can see a full changelog on github.

One key problem Bundler was designed to address was the shifting sands of various gems updating and changing dependencies. As many of you have probably found in the past before Bundler, deploying could unexpectedly install new versions of gems on you, breaking your application. Bundler has added a new flag: “—deployment” for this very issue.

When you run “bundle install” on your local development machine, Bundler will automatically create a Gemfile.lock file. The lock file includes a pinned version of all of your gem dependencies, for all groups. When the deploy process then uses the —deployment flag, the installation will only install the version of gems that are listed in the Gemfile.lock, which was generated on your development machine. This ensures that even your dependent gems change, the dependencies on the dependencies change, etc, you won’t be surprised by updating to a different version than you tested against.

To work, the —deployment flag requires that you have a Gemfile.lock. Currently, Heroku runs “bundle install” against your application if you don’t have a Gemfile.lock, and “bundle install —deployment” if you do. Starting next month, we will begin to use the —deployment flag 100% of the time. This means you must commit a Gemfile.lock to your git repo. Simply run bundle install locally, git add your Gemfile.lock, and you’ll be all set for the future.

In "So You Want To Be a Ruby Dev" Kevin W Gisi presents a tongue in cheek narrative of a new Ruby developer being guided through the choices they have to make. (It's being discussed on Hacker News too - some good comments there.)

He asks a lot of questions: Which Ruby implementation to use? Which Web framework? Which Gems? Which version of Rails should you use? Which database adapter? And he caps it off with a conclusion of sorts:

Remember when Ruby and Rails was about getting stuff done? Note: New developers, Ruby is still a great place to be - even if there is an overabundance of choice at the moment.

Kevin W Gisi

I like Kevin and I saw a little merit in his tale, but right away mygut felt his concluding point was bogus. I wondered.. is there another problem here or does Ruby really suffer from an overabundance of choice?

If we're talking about the number of tools, implementations, or libraries, no. Abundance is Ruby's strength. It's the TIMTOWTDI (There Is More Than One Way To Do It) philosophy Ruby inherited from Perl, in contrast to Python's preference for only one obvious way to complete an operation. It's Ruby canon that Matz designed Ruby to be a fun programming language for himself but, also, a language flexible enough to adapt to other people's fancies and preferences. Rather than all of us reading from the same hymn sheets, we can bend, bolt onto, and monkey patch Ruby to fit our own personal or team preferences. This approach has its (much discussed) failings, but it's a philosophy nonetheless.

The overabundance is in the options we present

Still, I detected truth in Kevin's narrative. I realized, though, that it's not that Ruby is no longer about "getting stuff done" or that there's an "overabundance of choice" in libraries or tools. The problem is that Ruby's documentation, main advocacy sites, and even most sites for popular Ruby libraries (with one major exception - coming later) try too hard to demonstrate freedom, flexibility and choice from the get go without giving an opinionated, direct instructional approach for newcomers (e.g. on the official Ruby download page, the first thing you see is a link to Ruby's source code).

We need to be more specific in our READMEs and Web sites where we can and think about what a smart newcomer would want to see. We need "Getting Started" or "For Newcomers" pages that tell people exactly what to do without bending over backwards to cover edge cases or show off esoteric features. Tours that don't take diversions. Download X. Type Y. Run code Z. Instructing, rather than showing a smorgasbord of options, from which a new, confused user would choose none. Rather than offer 5 vaguely different alternatives on a "How To Install" page, give the simplest, most generic route, then discuss the alternatives for "advanced users."

Books are great at this sort of direction. Take almost any instructional Ruby book and even if it's out of date or not doing things "the accepted way", it will take a position and stick to it. Novices can follow along and make smarter judgements later. Let's bring that to our own work too, where we can (and I'm certainly aware there are people who do do this already - that's great!). I'll be going through my own libraries and future blog posts to keep an eye out for this and figure out how a newcomer might perceive them. Satish Talim's RubyLearning blog and courses have proven there's a gigantic population of people who consider themselves Ruby "newbies" reading what we write - it would be great if any of them could have a defined route to try out almost any library they stumble across.

Rails gets it right

Rails has been good at the instructional approach over the years. The "type this, type that, start a server, and bam, you've got an app" approach has been instrumental in the boom of Rails' popularity. Things like the "build a blog system in 15 minutes" screencasts were huge hits. Even complete non Rubyists could follow the same moves precisely and get the same results which they could then play around with further. Imagine if every good Ruby library had similar resources? (And if Railscasts has done a video for your library or tool and you're not making it a centerpiece of your site or README, sort that out!)

It's easy to forget that when we write about Ruby, the jargon and "do what you like" approach we frequently celebrate can seem alien to even the most intelligent newcomers who may well be used to more structured, directed "do X, then Y, just because" environments. We should provide hard and fast answers for those people, even if we run the risk of being a little wrong from time to time, without jeopardizing the richness of the number of tools, libraries, or implementations that exist.

In April, we wrote about IronRuby hitting 1.0 and Microsoft's "3 years with Ruby paid off." It's sad, then, to read today that program manager Jimmy Schementi is leaving Microsoft citing a rapidly decreasing interest in dynamic languages at the software giant.

[..] a year ago the team shrunk by half and our agility was severely limited. I’m omitting the internal reasons for this, as they are the typical big-company middle-management issues every software developer has. In short, the team is now very limited to do anything new, which is why the Visual Studio support for IronPython took so long. IronRuby’s IDE support in Visual Studio hasn’t been released yet for the same reasons. While this is just one example, many other roadblocks have cropped up that made my job not enjoyable anymore.

Overall, I see a serious lack of commitment to IronRuby, and dynamic language[s] on .NET in general. [..] That being said, I am still interested in implementing dynamic languages on .NET, so I will remain a IronRuby core-team member, ironically making me the first non-Microsoft core contributor. The bad-news is I will no longer be working on IronRuby full-time, but in the near future I’m definitely staying active. Also, Tomas will definitely continue working on IronRuby when he can; we weren’t the last two people left for no reason. :-)

Given that Tomas and I will only be working part-time on IronRuby now, I invite the Ruby and .NET communities to come help us figure out how to continue the IronRuby project, assuming that Microsoft will eventually stop funding it. I’ll start a thread on the IronRuby Mailing List shortly, so keep an eye on that if you’d like to help.

Jimmy Schementi

Schementi left Microsoft at the end of July and is on his way to work at a NYC-based financial technology consulting firm. I'm sure most Rubyists would be quick to join me in congratulating Schementi and the rest of the IronRuby team (including John Lam, who left in 2009) for making significant strides in a company and environment where the obstacles were piled high. We've wondered for years whether Windows is a first class platform for Ruby and now we know that Ruby certainly isn't even a second class language for Microsoft.

Schementi seems keen for people from outside of Microsoft to get involved with IronRuby to keep it alive. These sorts of efforts aren't often successful, because contributors usually bubble up over time to become more important, and he notes that he is now the first non-MS contributor merely by virtue of no longer working for MS. If, though, you're a .Net and Ruby hotshot and have the time and passion to become a hero in the worlds of DLR and "Ruby on Windows", there's a significant opportunity here for the taking.

When you’re viewing content on a mobile device one of the most common uses is to zoom in on content to view it larger so it’s easier to read or tap. This makes text look crisp and beautiful, especially on the latest high resolution mobile screens, but a side effect is something terrible: images look much much worse. Why should mobile users be punished for zooming in?

Normal image resolution

In the example below, we have a screenshot from an app prototype we’re working on. It has a normal sized (55px) user image which would look nice on a desktop machine, but be pixelated and ugly if you zoomed in.

Below is how it would usually look when a user in a mobile browser zooms in to read text. It’s blurry, pixelated and often plagued with compression artifacts.

Increase the resolution!

In this case, however, the image is actually 3X the size it should be. It’s secretly 165x165, but the height and width are set at 55px, so when you zoom in on a mobile device you are rewarded by seeing a sharper image that looks nice next to the enlarged text.

The effect may seem trivial at first but in practice it gives the user a sense that the page is a fluid, organic thing and not pixels on a screen. It’s a simple and effective trick that’s easy to implement until CSS3 methods become usable.

In a real world test with an actual photograph I found a 55px JPEG was around 6k and a 165px image was 16k. That’s a file size increase I can live with.

When not to increase resolution

This technique works particularly well for small images and logos. For images that are already large enough to look decent (around 500 pixels wide) this technique could add unnecessary loading times for some users. Use it sparingly and your mobile visitors will be rewarded with a unique and special experience.

Photos by Jamie Beck

Yesterday, Lyle Johnson of the FXRuby GUI toolkit project stood aside as the project's maintainer, effectively retiring the project:

When Jamis Buck wrote last year about ceasing development on Capistrano, his post really struck a chord with me. If this post reminds you of that one, it’s because I re-read it before sitting down to compose this one. [..]

It is with mixed feelings that I announce that I’m stepping away from FXRuby development, effective immediately. I will no longer be accepting bug reports, support requests, feature requests, or general emails related to FXRuby. [..]

Someone on the mailing list asked whether FOX and FXRuby are “pretty much dead.” I can’t speak for Jeroen or the FOX project. As for FXRuby, however, that’s up to you. FXRuby is, and always has been, an open source project. If you are interested in hacking on FXRuby, or even taking over maintenance of the project, please feel free to fork the project on GitHub and release updates as you see fit.

Lyle Johnson

The undertone here is that the FOX Toolkit, upon which FXRuby operates, isn't underseeing significant development and, perhaps, there is little more for FXRuby to be doing (at least, little in the way of exciting or interesting) and Lyle wants to shuffle the project off his plate.

Lyle cites Jamis Buck's dropping of his Capistrano deployment system project as an inspiration, though Capistrano's story turned out to be a happy one after being adopted, for the most part, by Lee Hambley.

With an open API, Hoptoad, the app error app, can track errors from any sort of app you want: Rails, Sinatra, Rack, PHP, C#… the list goes on. We didn’t want to leave front-end developers in the dark when their Javascript throws errors, so we’ve added a Hoptoad notifier for Javascript!

I’m sure you’re asking, “How do I participate in this awesomeness?”. It’s easy.

If you’re using the hoptoad_notifier gem, upgrade to the latest version (2.3.3) and update your config/initializers/hoptoad.rb:

HoptoadNotifier.configure do |config|
  config.api_key = 'YOUR-PROJECT-API-KEY'
  config.js_notifier = true # ADD ONE LINE FOR JAVASCRIPT ERROR TRACKING!
end

Yes, that’s it.

The gem injects Javascript right after your tag. If you’re not using the hoptoad_notifier gem, you’ll just need to include a couple of lines (at the top of your ):

You may be proclaiming, “Oh no, Javascript at the top of ! What are you thinking?” I’ll let you in on a little secret: we want our Javascript loaded before any other Javascript. That way, if one of those libraries throws an exception, we’re there to let you know!

The nitty-gritty details: we’re currently only supporting browsers that support the onerror event (Firefox 2+, IE6+). You’ll also be including your project API key on the page. This is different from your user API key, so there’s no need to worry about someone deleting your projects or users. We’ll continue to expand this feature and let you know as we progress. If you have any suggestions or spot a bug, let us know!

So, what’re you waiting for? It takes 30 seconds to sign up; go grab an account and start tracking your Javascript errors now!

http://avdi.org/devblog/2010/08/02/using-and-and-or-in-ruby/ (or on Ruby Inside)

If you use Ruby long enough, you will discover the and and or operators. These appear at first glance to be synonyms for && and ||. You will then be tempted to use these English oprators in place of && and ||, for the sake of improved readability. Assuming you yield to that temptation, you will eventually find yourself rudely surprised that and and or don’t behave quite like their symbolic kin...

Avdi Grimm

Avdi Grimm presents a concise guide to a matter that confuses the majority of Ruby developers from time to time.

Early bird registration for RubyConf 2010 - to be held in New Orleans November 11-13 - has just opened and you need to get in fast if you want to go. RubyConf has a reputation for selling out very quickly and even though some waiting list folks usually make it in, if you're dead set on going, buy your tickets immediately. They're $300.

Not got a second to waste? Go direct to the ticket ordering page by clicking here.

Note: I don't get a cut of ticket sales or even get asked to post about RubyConf. I just remember reading a torrent of endless misery on Twitter when it sold out so quickly last year ;-)

The Ruby on Rails Tutorial: Learn Rails by Example (a.k.a. railstutorial.org) by Michael Hartl has become a must read for developers learning how to build Rails apps. Michael has put together a great Rails 2.3 tutorial, releasing it all for free online chapter by chapter. Now, Michael's going three steps further:

1 — A new, Rails 3.0 focused version. The free online book previously covered Rails 2.3 but Michael's updated it to cover Rails 3.0 too. He's also selling it as a DRM-free PDF for $39 (you get a PDF of the Rails 2.3 version too). As a gesture of goodwill to Ruby Inside's readers, he's made a coupon code that works till the end of August - it's rubyinside01 and gets you 20% off (so a total of $31.20 in the end).

2 — Creative Commons licensing of the existing online text. Like all of us, Michael needs to make some money, but a side benefit is that he's making the existing Rails 2.3 focused text Creative Commons licensed! This will allow you to distribute it, translate it, put snippets on your blog, and so forth. (Update: Michael notes that this is sort of in the air at the moment pending more resources. He has more preparation to do to make this work properly, but the spirit is there.)

3 — A print book, published by Addison-Wesley. A print edition, Ruby on Rails 3 Tutorial: Learn Rails by Example, is due out in the fall as part of the Professional Ruby Series (the same series as The Rails 3 Way by Obie Fernandez), and is currently available for pre-order at Amazon.

As a bit of a "geek aside", the Ruby on Rails Tutorial book is written using PolyTeXnic, a pure-Ruby markup system built on top of the LaTeX typesetting system. PolyTeXnic converts a select subset of LaTeX to HTML, while also producing PDFs via the pdflatex command.

In addition to supporting code-heavy programming books such as Ruby on Rails Tutorial, PolyTeXnic can also produce mathematical documents; see, for example, Michael Hartl's anti-pi propaganda piece called The Tau Manifesto. Michael hopes to release PolyTeXnic as an open-source project some time later this year. I keep nagging him about it.

thoughtbot is pairing up with Ben Orenstein to present a Vim course, this time at WorkBar. As part of this collaboration WorkBar is offering $50 off your first month’s membership if you register for the Vim course.

One thing you will discover at this course is the history of the command `grep’. This all starts back with `ed’, the original unix editor. ed was a command-line editor that worked identically to the colon-commands in vi and vim—in fact, you can press Q to get into ed mode (then type vi to get back into vim). From the ed editor you can issue common line-oriented commands like s, d, y, and so on:

:%s/rdoc/docr/g
:/include/d

If you’re following along at home you may wonder “how can I see the contents of this file?” Well if you just want to see every line you can use %p (% is “the whole file”, and p is “print to screen”), though it’s more likely that you want to see a small series of lines. 10,20p will show you lines 10 through 20, but maybe it makes more sense to see all lines matching a regular expression.

From ed, to see all lines matching “include”, use g/include/p. To see all lines matching “docr” use g/docr/p. In general, to see all lines matching the regular expression “re”, use g/re/p.

… And that’s how grep got its name.

Sign up now for the Vim course at WorkBar with Ben Orenstein on September 1st from 5PM to 9PM.