Performance Enhancements for the Asset Pipeline

Martha will be profiling, benchmarking and updating parts of our asset compilation process to
improve our asset [re]generation speed. The initial scope of this project covers CoffeeScript, Sass and
our Uglifier, but benchmarks will be guiding this effort to work where we can get the biggest
benefits in these four months.

Evented File System Monitoring

ActiveSupport::FileUpdateChecker, the
system we use for detecting changes in files (mostly for reloading purposes) has served us well over the years, but we're done with
polling. Puneet will be replacing our current design with a event-based approach that relies
on existing third-party monitors (e.g. inotify or FSEvent).

Asset Pipeline Support for Source Maps

The goal of Andrei's project is to give you good inspecting and debugging capabilities in environments
where your code goes through various transformations (e.g. your CoffeeScript file being compiled to
Javascript and then minified in your staging environment). With source maps you can use the existing
tools your browser provides to do things like reading the CoffeeScript source or setting breakpoints
on it.

Refactoring Action View and Active Support

Islam is adding some of the things we should already have in Rails, liked adding named arguments
for Action View helpers (goodbye counting commas!). He will also be researching how to improve some of our core abstractions like
ActionController::Parameters
and
ActionView::OutputBuffer
to enable better security and performance.

Web Console Browser Extensions

Following up on the work of previous GSoC projects, Hiroyuki will be creating browser extensions for
the Rails web console. Like the Source Maps project, this one will give you a better live
debugging experience using standard tools that everyone has available already.

Test Failure Prediction

Aaron Patterson has touched upon some interesting ideas on
predicting test
failures using the
experimental Coverage feature
available in recent Ruby versions. Genki will be experimenting with this to see if we can make it a
part of the Rails testing ecosystem.

Refactoring Cookies

Rails cookie handling is pretty basic, and although it works in most use cases, we can improve
it. Siddarth will be adding server-side expiration mechanisms and purpose fields to our existing
cookie jar, allowing us to have better control and security over our systems.

Improving RubyBench.org

In case you're not familiar with it, RubyBench is an amazing effort to keep
long running benchmarks for Ruby and related projects (like
Rails). As you can see, our own benchmarks could use
some love, so Kasif will be taking care of this. If everything goes well, JRuby support in
RubyBench would be the next step for this project.

Fun Fact: 4 of the 14 mentors we have this year participated as GSoC students in previous years. Today they're all
active contributors around the Ruby/Rails ecosystem!

We hope to keep you up on important updates during the summer, but if you're interested in staying
up to date (or maybe lending a hand?) please make sure to subscribe to our mailing list.

We're happy to announce that Ruby on Rails will once again be part of Google's Summer of Code
(GSoC) in 2015. The GSoC is a global program where students can contribute to open source projects
and get paid while doing so. Every project has at least one community member that will act
as mentor for the duration of the program. The only requirements for students applying are:

Being at least 18 years old.

Being enlisted as a part or full-time college student.

Some of the work done in the past years includes the web-console shipped with Rails 4.2 and
RubyBench.org, a long running suite of Ruby benchmarks. You can see the
full list of projects from previous years here: 2013, 2014.

We have started writing down a list of ideas for this year, you can find it in the Rails GSoC
Wiki. This summer we want to focus on fixing
existing problems instead of adding new user facing features. If you are interested in
getting involved please join our mailing list and let us know what you'd like to
work on.

Student applications can be submitted starting March 16 and the deadline is March 27. If you're
wondering what's involved in becoming a GSoC student then the Google Student
Guide has all the details on what's expected and what
you will gain from taking part in the program.

What if you're not a student? You can still help out by discussing ideas on the mailing list,
and if have previous experience contributing to Rails and are willing to make a strong commitment to
help out the next generation of developers, you can apply to be a
mentor.

Google has announced the list of projects that were accepted into the Google Summer of Code (GSoC) 2014 program.
I'm extremely excited and proud to announce that Rails has been granted eight project slots this year.
Here's what our students will be working on this summer and the mentors that they are working with:

Long-running Ruby and Rails benchmark

Bert Chang will be creating a set of long-running benchmarks for Ruby and Rails.
This will help both projects continuously monitor how their commits are impacting real-world performance, which
will help discover and respond to regressions much earlier in the development cycle.

Refactor URL generation and recognition code

He will be mentored by Andrew White, another member of the Rails core team.

Security upgrades

Xuchu Zhang will be picking up the task of improving Rails' security defaults and other
related features. This effort would help ensure that Rails remains secure out-of-the-box. Plans include implementing
support for the latest security features in modern browsers and auto-expiring cookie jars.

Towards a bright future

I don't know about you, but after seeing this list of amazing projects, I am genuinely getting very excited about the
bright future for Rails. By the end of this summer, not only would we gain a few great new features, but we are also
helping to nurture some new contributors in Rails and the wider OSS community, how great is that!

Finally, we'd like to thank every single student and mentor who participated in the Google Summer of Code selection
process. There were many great proposals and we're really excited to be able to work on so many of them this year.

<3 <3 <3 <3 <3

P.S. If you enjoyed this post, you should also check out GSoC's sister project – the Rails Girls Summer of Code
initiative, where another seven (Update: 15!) awesome teams will be working on some equally impressive projects in our
ecosystem. Did I mention how incredibly excited I am about this summer?

We're pleased to announce, Ruby on Rails has been accepted into Google Summer of Code 2014 as a mentoring organization. What does this mean to you? Potentially, if you're the right person, you can get paid to work on Rails this summer! The "right person" in this case is one who is at least 18 years old (sorry, Google's rule, not ours!) on or before April 21, 2014; a full or part-time college student; and passionate about improving Rails.

We're building a potential list of project ideas on a GitHub wiki, but we welcome other interesting proposals. If your proposal gets accepted, Google will pay you $5500 over the course of three months to work on the code. If you're interested, head over to the GSoC site and start reading about the process. Student applications can be submitted starting March 10 and the deadline is March 21.

If you're wondering what's involved in becoming a GSoC student then the Google Student Guide has all the details on what's expected and what you will gain from taking part. Any further questions can be directed either to the mailing list or to me directly.

What if you're not a student? You can still help out by discussing ideas on the special mailing list we've setup for this year's program. Or if you've got previous experience of contributing to Rails and are ready to make a strong commitment to help out the next generation of developers, you can apply to be a mentor.

We're looking forward to working with this year's students, and expecting some outstanding contributions to Rails as a result!

Google has announced the accepted projects for the Summer of Code 2013 and Rails has been granted five slots. Here's what our students will be working on this summer:

Genadi Samokovarov will be working on adding a web-based console for development, debugging and testing your Rails applications. He will be mentored by Rails Core Team member Guillermo Iguaran.

Łukasz Strzałkowski will be working on seperating Action View from Action Pack and adding support for custom view classes. He will be mentored by Piotr Sarnacki, who was a Rails Summer of Code student in 2010 and has been a consistent contributor to Rails.

Ujjwal Thaakar will be working on adding support to Rails for bulk/collection actions with RESTful resources. He will be mentored by Rails Core Team member Andrew White.

Kasper Timm Hansen will be working on replacing the venerable html-scanner in the Rails HTML Sanitization API with Loofah and adding improvements to the API. He will be mentored by Rails Core Team member Rafael França.

John Wang will be working on refactoring the configuration and initialization of Rails applications. He will be mentored by Rails Core Team member Santiago Pastorino.

We'd like to thank all of the students and mentors who participated in the Summer of Code selection process - it was tough to get down to five projects, considering all the great proposals we had. We're looking forward to seeing what all of our students bring to Rails this summer and we hope not to lose touch with others who are also excited about the prospects for Rails 4.0.

We're pleased to announce, Ruby on Rails has been accepted into Google Summer of Code 2013 as a mentoring organization. What does this mean to you? Potentially, if you're the right person, you can get paid to work on Rails this summer! The "right person" in this case is one who is at least 18 years old (sorry, Google's rule, not ours!) on or before May 27, 2013; a full or part-time college student; and passionate about improving Rails.

We're building a potential list of project ideas on a GitHub wiki, but we welcome other interesting proposals. If your proposal gets accepted, Google will pay you $5000 over the course of three months to work on the code. If you're interested, head over to the GSoC site and start reading about the process. Student applications can be submitted starting April 22 and the deadline is May 3.

If you're wondering what's involved in becoming a GSoC student then the Google Student Guide has all the details on what's expected and what you will gain from taking part. Any further questions can be directed either to the mailing list or to me directly.

What if you're not a student? You can still help out by discussing ideas on the special mailing list we've setup for this year's program. Or if you've got previous experience of contributing to Rails and are ready to make a strong commitment to help out the next generation of developers, you can apply to be a mentor.

We're looking forward to working with this year's students, and expecting some outstanding contributions to Rails as a result!

WHEN

WHERE

What could be better than gathering together in real life and hacking (and drinking?) on the weekend!? It's the best chance to get together and getting into the depth of Rails core. Contact your friends, your boss, your co-workers, and get them organized!

It’s that time again to take a moment to think about those who have impacted the Ruby community this year but have not received the recognition they deserve. We have given away eighteen awards in the past three years at Railsconf, and this year we are preparing to give away six more.

But we need your help.

So, if you know someone who has contributed greatly this year please take a moment to show some gratitude by nominating them on RubyHeroes.com. In two weeks the Ruby Heroes from last year will look at the nominations and decide who should receive the awards (this way there’s no popularity contest). However, your nominations do matter, so please take a moment and spread the gratitude.

One of the reasons the Ruby and Rails community is so strong and passionate is because of the awesome regional conferences that happen all around the globe on a yearly basis. Previously on this blog I’ve gone through the list and highlighted a bunch, but since then Ruby There has popped up.

So instead of listing out all the conferences I’m just going to send you over to RubyThere.com.

If you dig the Ruby and Rails community I highly recommend you attend one of these events and maybe volunteer to help or even sponsor if you can afford to. It’s hard work putting on a conference, and most of the organizers do it for the love of the community (and little to no compensation).

This morning my team over at Envy Labs released a free online tutorial called Rails for Zombies. The website combines screencasts with in-browser coding to provide an interactive learning experience teaching the basics of Ruby on Rails.

Learning Rails for the first time should be fun, and Rails for Zombies allows you to get your feet wet without any setup or configuration. At the moment the application has five episodes. Each episode consists of a single screencast followed by a group of exercises which must be completed before moving forward. Once you complete all the labs, you unlock a hidden video which shows you where to go to continue your Rails learning.

If you have any friends who need to get started with Rails, hopefully this will help.

The source for the finalized book will be pushed to GitHub and released under a Creative Commons License shortly after Rails 3 is done. If you’d like to help translate the book to your language of choice, feel free to contact Michael and he’ll get in touch when it’s time to make it happen.

Rails Guides

If you’re not a Rails newbie don’t forget about the Rails Guides, which have been updated for Rails 3.

Rails API Docs

There are two main websites I use to do API lookups. The first is Rails Searchable API Doc, which has online and offline searchable documentation. The second is APIdock which is online only, but has the ability to comment and easily compare different versions of documentation.

Rails 3 Free Screencasts

If you’re more of a visual learner (like me) then there are plenty of free screencasts to teach you about Rails 3. About 2 months ago I produced the Rails 3 Screencasts, which will get you started.

Ryan Bates has also produced an incredible amount of Rails 3 screencasts over on Railscasts.com. Ryan has been producing Railscasts for over 3 1/2 years, isn’t that crazy?

There’s also a few good free screencasts over on Teach me to Code by Charles Max Wood.

Keeping on the Edge

If you find yourself wondering how to keep up with all of the newest features / libraries for Rails 3, both the Ruby5 Podcast and the Ruby Show are going strong. Don’t listen to audio? It doesn’t matter, just subscribe to the Ruby5 RSS feed and get links with descriptions to all the newest libraries, tutorials, and more. You might also want to checkout Peter Cooper’s new Ruby Weekly, a Ruby email newsletter.

It’s that time again, to summarize a few interesting Rails links to highlight some of the best of the community. All of these were initially covered on the Ruby5 Podcast, the twice weekly Ruby newscast.

Rails 3 Content

The next Rails3 Bugmash is taking place May 15th and 16th. If you’ve never contributed to Rails, this is your chance to give back a little and do your part to make Rails 3 the best version ever.

To get a complete picture of routes in Rails 3, Rizwan Reza covered it best in an article over on the Engine Yard blog. If you dig the Engine Yard Rails 3 content, they recently created Rails Dispatch, where they have articles and screencasts published weekly.

Alex Maccaw recently used the Rails 3 ActiveModel abstraction to build an ActiveRecord-like in-memory database called Supermodel. You get all of the ActiveRecord goodness, such as validations, callbacks, and observers, but with none of that database headache.

As you may already know, the arel library from Rails 3 gives us a great new syntax for creating queries. Under the covers, arel converts your where conditions into sql is by using something called a PredicateBuilder. Ernie Miller recently put out a plugin called MetaWhere that takes advantage of these PredicateBuilders to give arel even more functionality.

Lastly, if it’s still not clear to you how awesome bundler is, go read Yehuda’s recent post on the topic.

Authorization

Do you ever find the need to access current_user in your models? This is often required when you’re logging model/table changes on a per user basis. There are many hacks to accomplish this, but David Bock has a gem called SentientUser which does this a little cleaner.

Once your websites goes big and you start to worry about malicious user attacks, you may want to take a look at Arto Bendiken and Brendon Murphy’s Rack::Throttle Middleware. Throttle does just want you think it does, allowing you to limit the number of requests a user can ping your site (per second).

Lastly, Ryan Bates released version 1.1 of CanCan, his authorization and permission library that allows you to restrict what your users can do throughout your application.

Service Libraries

You may have heard that the Facbook API is now adopting OAuth2. If you’re ready to jump in, Michael Bleigh released the OAuth2 gem just last week.

Rails makes a great RESTful backend for iPhone applications, and recently Anthony Moralez created APN_on_rails which makes it super easy to do Apple Push Notifications.

There’s no need to reinvent the wheel if your Rails application needs e-commerce, this is where the Spree gem comes in, which recently hit version 0.10.0, containing a bunch of new features.

Testing

Does your Rails application have a monster testing library that takes forever to run? Then it may be time to take a look at Hydra by Nick Gauthier, a distributed testing framework which allows you to run your tests in parallel locally or across remote servers.

Some people think cucumber can be too verbose for integration tests (which clients may never read). If you think cucumber is for vegetarians, then perhaps it’s time to taste some Steak by Luismi Cavalle. Steak is a small library which helps you generate quick and clean acceptance/integration tests using RSpec.

Talking about RSpec, there are some new conventions out there to clean up your old RSpec code. If you haven’t started using “Let”, then it may be time to look through a few of Jon Larkowski’s slides.

Additional Useful Libraries

If you ever find yourself with odd memory issues then it’s probably time to use memprof.com, a new web service by Joe Damato and Ruby Hero Aman Gupta. Memprof allows you to collect memory usage information from a Ruby process and immediately upload and view it using an intuitive web interface.

Rails applications are often full of forms, and sometimes you even need to give your clients the ability to create different types of forms or surveys. This is where the Census gem comes in, providing an admin interface for creating forms, and even the ability to search through the results.

To wrap things up, delayed_job recently hit 2.0, and you’ll want to upgrade if you have an older version. The new version has some performance improvements and adds support for non-ActiveRecord ORMs.

Additional Content

To keep track of Ruby conferences check out Ruby There, a listing of all the upcoming conferences and even when the Call for Proposals are due.

For more news and libraries check out the Ruby5 podcast. If you don’t usually listen to audio, you can just subscribe to the RSS feed which contains a summary of everything covered.

If you have any stories/libraries you’d like to spread the word about, feel free to email ruby5@envylabs.com and we’ll at least get you covered on the podcast. Thanks!

It’s that time again to take a moment to think about those people who have impacted Ruby community but have not received the recognition they deserve. We have given away twelve awards in the past two years at Railsconf, and this year we are preparing to give away six more.

But we need your help.

So, if you know someone who has contributed to our community this year please take a moment to show some gratitude by nominating them on RubyHeroes.com. A month from now the Ruby Heroes from last year will look at the nominations and decide who should receive the awards (this way there’s no popularity contest). However, your nominations do matter, so please take a moment and spread the gratitude.

The winners will be announced live on stage at Railsconf 2010, and posted here shortly there after.

If you have been in the Rails community for a little while, you have more than likely noticed the love/hate relationship that is entertained by the community vis-à-vis the Enterprise.
Some people hate the enterprise and publicly tell it to go f*ck itself (49:39), on the other hand, these same people are also proud to mention that some major players in the industry use Ruby and Rails.

The truth is that even though Ruby and Rails could still be more Enterprise ready, it is already a great combo that big corporations can start using today, and lots of then already do! Let's look at the state of Rails and the Enterprise.

So where are we at?

First things first, Rails was not designed for the enterprise or for the enterprise's needs. It was extracted from a successful startup project and has grown with the contribution of people using Rails daily. But Rails is also based on Ruby which became very popular and started to be used in different places, including NASA, for instance.

37signals still does NOT need "Enterprise features" and therefore don't expect any 37signals engineers to write an Oracle Adapter or a SOAP layer for ActiveResource and push for their adoption.

Rails is far more than a framework used by 37signals. It is an Open Source project with code being contributed daily by people on other projects. Most of the code does not directly benefit 37signals.

The Enterprise is evolving: economic crisis, a new generation of developers, new management, insane deadlines. Ruby and Rails have quickly become very attractive for the Enterprise and having big companies acting as startups is often something a lot of managers dream of. As a matter of fact, here is a quote from Sony Computer Entertainment America's President & CEO, Jack Tretton: "Be like a multi-billion dollar company on the outside, and act like a startup on the inside". This change has taken a while because the Enterprise is a big mammoth (or insert another of your favorite gigantic, slow-starting animal here), but it's happening.

Communication with/in big companies is not as straight forward as when dealing with startups who need/thrive for the outside attention and who don't have all the red tape of a PR department, etc. Here is a simple example: I work for Sony Playstation. My job description mentioned Redis, MongoDB, EventMachine and many other technologies I did not know Sony was using in production. I did not realize that my default production stack would be built on Ruby 1.9. Communicating when you're a part of a big company is more challenging than when you are a team of 5 engineers working on a cool project, and therefore a lot of people don't know what technologies are being used by Company X or Company Y.

Rails is used by lots of big companies. It might not be obvious and you might have to look at the job offers but people like AT&T, Sony and many others are always looking for talented Ruby developers. And, even though Java and .NET are still ruling the Enterprise kingdom, dynamic languages are slowly but surely catching up. Rubyists are climbing the social ladder and are now in positions to push the language they love.

Understanding the Enterprise's needs

It's kind of hard to define "the Enterprise's needs", however I can testify that the needs and requirements of a so called "Enterprise app" are slightly different than those encountered when you work on a startup app.
What the Enterprise needs/wants:

reliability

support

performance

advantage over the competition

integration and transition path

Reliability

I think that it was proven many many times that Rails scales and can be very reliable as long as you know what you are doing. We are not talking anymore about a buzz framework that just got realized and that cool kids play with but rather, a stable platform used by some of the most popular web applications out there.

Support

This point is something the Rails community can be proud of. We have lots of forums, blogs, books, local meetings, conferences... Yes, Rails is OpenSource and you can't buy yearly support from the core team but you will find all the help you need out there. (If you can't, feel free to contact me and I'll direct you to people who can help, and if you are new to Rails, take a look at http://railsbridge.org/)

Performance

Based on my own experience, the level of performance we have using Ruby and Rails is more than enough for the Enterprise world. This is especially true with Ruby 1.9 greatly improving performance and Rails3 optimizations.
If you really need part of your code to run as fast as C code, writing a C extension for Ruby is actually quite easy and will solve your speed issues.

Advantage over the competition

Rails comes with certain ways to do things, conventions that will get you up and running in much less time.
Ruby as a language is natural, intuitive and easy to maintain. By choosing the right tools for your project, you will definitely be able to get more done in less time and increase your business value faster. Let's not forget the strong value of testing in the community that will push your team to write tested code and more than likely improve the overall code quality of your products.

Integration and transition path

This is probably the part that is the most challenging when you live in the Enterprise and look into using Ruby & Rails.
I was recently talking to someone from Google who used to do a lot of Ruby before joining the Mountain View-based company. We were talking about how he loves Ruby but had such a hard time integrating with existing Enterprise solutions. He mentioned how he got frustrated by the lack of great XML tools, bad/complicated SOAP libraries and a few others I can't remember. The truth is that when my friend was using Ruby this all was true. REXML and soap4r are useful but might not perform that well. Luckily as the community has grown, new tools have come up and today Nokogiri (developed and maintained by AT&T engineer's Aaron Patterson) can easily be used instead of REXML and many libraries are known to be better than soap4r such as savon, handsoap and others.
The other good news is that major IT companies such as Apple, Microsoft and Sun(RIP) have adopted Ruby and you can now write your code in Ruby and use native libraries from other languages such as Java, .NET or Objective-C.
The transition path can be done smoothly without having to commit to a total rewrite.

Database-wise, Oracle is still a viable option for Rails developers thanks to the Oracle ActiveRecord adapter (by R.Simanovskis). Note that your DBA might curse you for not doing optimized queries using bind variables and all the Oracle Magic spells, in which case you can use Sequel, a great ORM supporting Oracle, and some of its unique features.

Deployment-wise, you can deploy on IIS, Tomcat, Glassfish, Apache, Nginx, or almost anything mainstream you are already using. Using Passenger, deployment is as easy as deploying a PHP app and you also get a series of great tools such as Capistrano, Vlad etc...

So basically, thanks to passionate Rubyists working 'for the man' such as Aaron Patterson, Raimonds Simanovskis and others, using Ruby in the Enterprise is much much easier. Ruby and Rails were not initially designed with the Enterprise in mind but with time, the integration has become smoother and both parties can now enjoy reciprocal benefits.

If I missed any (or have any information wrong) feel free to leave a comment and I’ll add it to the post. FYI, I’m purposely only showing conferences in the next 6 months. I’ll do another post in 6 months to show additional ones.

I’m always impressed by the continuous flow of innovation from the Rails community. Below are just a few of the highlights from the past month. These stories all came from the Ruby5 Podcast, which covers all the news from the Ruby and Rails community twice weekly.

Authentication

The talented Brazilian guys over at Plataformatec released the Devise gem this week, a new authentication option for your Rails app. Devise is a Rails Engine which sits on top of Warden, a Rack authentication framework. This makes Devise a little more flexible then other Rails authentication libraries, and is definitely worth a look.

On the otherhand if your application needs something more simple, check out Terry Heath’s OpenID Rails Engine. It should take you about 10 minutes to have an authentication system up and running, and you won’t have to worry about storing your users’ passwords.

Helpful Libraries

Thanks to Twitter’s new Streaming API we no longer have to poll every 5 seconds to discover new tweets. To start using it today check out the TweetStream Gem by Intridea.

With Rails 2.3 we gained the ability to utilize Rack Middleware in our Rails apps. If you don’t know what Rack middleware is yet go watch this screencast. Also, if you’d like some idea on how to use it, check out the CodeRack Middleware Contest, a competition to develop more useful and top quality Rack middleware.

A few weeks ago I heard about a javascript library called Validatious, which provides unobtrusive javascript for doing client side form validations. I know what you’re thinking though, “if I do both client side and server side validations I’ll have code which duplicates validation logic, and that makes me want to hurl.” Don’t hurl quite yet, first check out Jonas Grimfelt’s Validatious on Rails plugin which will auto-generate client-side validations using your existing model validations.

Optimization & Performance

If your Rails app needs to be able to handle many users uploading files at the same time (think Flickr), then you may want to look at ModPorter, an Apache module and Rails plugin created by Pratik Naik and Michael Koziarski. ModPorter parses incoming multipart requests storing the file to disk before it reaches your Rails app, so your Rails processes don’t get held up. We hear there is also support for nginx through a 3rd party module.

When you’re dealing with a database abstraction like ActiveRecord, it’s very important to ensure you’re writing optimal database queries. If you’re worried that your app may be doing more queries then it should or isn’t using eager loading properly, you may want to checkout the Bullet plugin by Richard Huang. Bullet can actually give you growl notifications when you’re missing an :include or should be using a counter cache.

Do you have mongrels that are consuming more then 150 Megs of RAM and you don’t know why? Do you suspect that it might be Ruby leaking all over the place? Then you’d probably be wrong, and Sudara Williams will tell you That’s not a Memory Leak, It’s Bloat. It’s more likely that you’re instantiating thousands of ActiveRecord objects, and Sudara gives you a few suggestions on how to find them.

Cleaning up code

The presenter pattern is very useful for encapsulating code that may be making your controller look fat, code that may not belong in your model. Dmyto Shteflyuk wrote up a great introduction to using presenters that’s worth a read if you’re not using them already.

Sending complex data-sets between Ruby and Javascript isn’t always easy. Don’t you wish there was a way to take that Ruby hash and just have it automatically transform into a javascript Map? If yes, then you may want to look at jsvars by Erick Schmitt, that’s what it does.

Deployment

You may already know about Chef (the system integration framework) but did you know that you can also deploy your Ruby app from chef using chef-deploy? Ezra Zygmuntovich created this gem which allows you to run your chef recipes and then if they pass (and only if they pass) deploy your code in a capistrano like fashion.

If you’re deploying a Rails cluster to Amazon EC2, then another solution aside from using Chef is a gem called rubber by Matthew Conway. Rubber keeps deployment a first class citizen, storing all your server configuration files inside your Rails app where they can quickly be tweaked under version control. It comes with many deployment best practices out of the box and can scale up or down at a moments notice.

Media

Have you ever wanted to run a Rails tutorial in your city, but you’re discouraged by the thought of writing all the course material? Then you need to checkout the Rails Bridge Open Workshop project where they have all the course material you’re going to need, for free! You have no excuse not to spread the word of Rails anymore.

Lastly, if you’re looking for additional Rails screencasts, you may want to checkout Teach Me To Code, and if you’re looking for additional Rails reading, then check out the past few issues of the Rails Magazine by Olimpiu Metiu.

Thanks for reading, and if you have any Ruby or Rails news you’d like to spread the word about, please send it into the Ruby5 podcast by emailing ruby5@envylabs.com.

Lots of great content coming out of the community in the past month. Below you’ll find some of the most useful tutorials and libraries I’ve found over the past few weeks. These stories came directly from the Ruby5 podcast, which covers news from the Ruby and Rails community twice weekly.

Improving your Rails code

James Golick released a gem called Observational recently which provides you with a better way of using observers in Rails. Instead of creating one file per observer, this gem allows you to define multiple observed objects and specific methods to call for each object’s events.

If you want to develop a Rails app that takes advantage of Subdomains Taylor Luk has the recipe. He recommends using subdomain-fu, shows how to use a Proxy PAC file in development, and introduces a piece of Rack middleware he wrote which allows you to use full custom domains in your application.

If you like to TATFT like the rest of us, I have two libraries to tell you about. The first is a gem by the guys over at Devver called Construct which makes it easy to test code which interacts with your filesystem. The second is Blue Ridge by Larry Karnowski and Chris Redinger which makes it easy to write tests for your javascript. Blue Ridge has been out for a while, but this week Noel Rappin wrote a great introductory article to get you started.

Just yesterday Fabio Akita put together a screencast showing how the “Weblog in 15 minutes” code could be simplified using Inherited Resources, a gem by José Valim which helps reduce controller code duplication. The gem uses the same sort of technique you may have seen before with make_resourceful or resource_controller, but has improved syntactic sugar.

Libraries you should know about

Patrick McKenzie released A/Bingo, a gem/plugin for your Rails application that makes A/B Testing easy. It uses a fairly intuitive and simple interface for defining your tests and provides information on which sample performed best and by what margins.

Steve Richert released a gem called vestal_versions which allows you to keep a history of all of your ActiveRecord model changes in your database. It takes advantage of several newer features in Rails 2.2+ including recognizing dirty objects.

David Bock released new gem called Crondonkulous which allows you to write crontab recipes in Ruby from within your Rails application. These recipes get automatically published to your server’s crontab when you deploy.

Security

James Harton released Lockbox and acts_as_lockbox, which provide a simple interface for securing sensitive data by managing RSA public key cryptography for your application. This allows you to define which attributes are sensitive and provides an application-wide locking and unlocking ability.

Hongli Lai wrote up a great article on keeping your user’s passwords secure. He writes about how to store passwords, hashing algorithms, salting, and more. Specifically, he recommends using Blowfish File Encryption, or “bcrypt,” because it’s a slower-running algorithm which will make it more difficult to crack.

In your Database

Mauricio Linhares released a plugin for Rails which allows you to do master / slave replication. Unlike masochism, master_slave_adapter works in conjunction with the Rails database connection pool and is implemented as a new database adapter. So, no monkey patching necessary.

Matt Jankowski provided a great article on properly indexing your database for your Rails application. He covers indexing validation and STI columns, state columns for state machines, association columns, and more.

The developers of xing created a plugin called FlagShihTzu. It’s not a dog.. or even a multiplayer game for your Tamagotchi. FlagShihTzu stores any number of ActiveRecord boolean model attributes as a single database field, using each bit as unique keys. But, the interesting part is that the interface remains exactly the same to the rest of your application.

Thanks for reading and if you have any news or libraries you’d like to get the word out about, feel free to drop me a line by submitting news over at Ruby5.

Last Friday, Apple released their new OS version: Snow Leopard.
Upgrading to SL is very easy and even gives you back quite a lot of HD space.
However a few things have changed in the OS and you need to understand what is going on so you won't get frustrated with the updating process and won't be wasting time fighting with the system.

The key change for us Ruby developers, is the fact that, in Snow Leopard, all the interpreted languages (including Ruby) are now running in 64-bit by default (obviously, only if you have a 64-bit machine).
For pure Ruby applications and libraries this shouldn't pose any problems. But if you are migrating from a Leopard environment where you compiled C extensions for 32-bit only, these gems won't properly load in Snow Leopard.
Same thing goes for libraries you might have compiled in 32-bit mode and that you might want to use on your migrated system.

Something else you need to know: Snow Leopard now comes bundled with Ruby 1.8.7 instead of 1.8.6.
This should not be a problem since Rails has been running on Ruby 1.8.7 for a long time and Rails 3 will require Ruby 1.8.7 and prefer Ruby 1.9.2.

Here is a quick rundown of common tasks you might have to do to migrate properly.

Install Snow Leopard developer tools

On the Snow Leopard DVD, under “Optional Installs”, install “Xcode.mpkg”. Use all default options.

Passenger

Press Enter when prompted. Passenger will compile and install its Apache module.
Press Enter when prompted the second time too.

$ cd /etc/apache2

Open httpd.conf in your text editor (if you use TextMate, try running mate httpd.conf from the command line) and look for a line like “LoadModule passenger_module” and some lines following that have “passenger” in them too. Delete them. If you don’t see them them, move your cursor to the end of the file.

MySQL

To avoid weird issues with MySQL, it's strongly recommended to upgrade to the 64-bit version.
Start by shutting down mysqld if it's running. (Depending on how you installed MySQL, you might be able to use the preference panel, or use
sudo /opt/local/share/mysql5/mysql/mysql.server stop
if you installed it using MacPorts)

When the disk image opens, first install “mysql-5.1.37-osx10.5-x86_64.pkg”. Use all default options.

Next install “MySQLStartupItem.pkg”. Use all default options.

Next install “MySQL.prefPane”. Double-click to install it. Choose to replace the existing preference pane when prompted. (Apparently the preference pane is still 32-bit.) At this point you can click “Start MySQL Server” to start the server and verify it works.

Unmount the MySQL disk image.

Since you are upgrading from Leopard, your mysql gem is compiled for 32-bit only and therefore needs to be recompiled.
However, it's not that simple, the mysql gem is a bit of an exception. Under Snow Leopard when you do a gem install for a C extension it tries to build the extension for two architectures: i386 (32-bit) as well as x86_64 (64-bit).
The problem is that the binary from mysql.com is not universal and therefore we need to force the C extension to be only compiled in 64-bit.

note: You shouldn't have to set the ARCHFLAGS to compile any other gems.

MacPorts

You should be all set. However, if you are relying on any libraries you compiled on Leopard, you probably will have to recompile them.
MacPorts users shouldn't think that it will be automatically done for them.

As Rubyists migrate from Ruby 1.8 to Ruby 1.9, new Ruby
implementations are gaining in maturity.
Recently, IBM's Antonio Cangiano wrote an interesting article comparing the performance between Ruby 1.8, 1.9 and IronRuby on Windows which surprised quite a lot of people.

Unfortunately, IronRuby isn't very well known in the Rails community yet.

Here is an interview with Jimmy Schementi, lead developer for IronRuby, to help give you a little insight.

Matt: Hi Jimmy, thank you very much for taking the time to answer our questions. Could you please introduce yourself?

Jimmy:
Thanks for sending me questions; it's great to see the ever-increasing interest in IronRuby!
I live in Seattle and work at Microsoft on a small team making an open-source implementation of Ruby called "IronRuby". I personally split my efforts between making the IronRuby codebase better, integrating IronRuby with .NET-related technologies like Silverlight or ASP.NET MVC, getting our monthly binary releases are in order, discussing IronRuby with the community, and making sure Microsoft's management knows how awesome Ruby is.
But I'm definitely not alone on the core team. John Lam fueled the interest of a .NET-Ruby implementation with the RubyCLR project, and started the IronRuby project. Tomas Matousek is the brains behind the IronRuby compiler, and gets credit for all the compiler code and the recent performance gains. Jim Deville is the man keeping IronRuby working with tons of tests and a fantastic test infrastructure. Shri Borde is our manager, and he spends his non-managing time fixing the libraries and hosting the infamous "IronRuby pair-programming" sessions. And of course all the IronRuby contributors over the past two years have been an enormous help.

Matt: As a follow up on a recent blog post, could you tell us know how you learned Ruby and maybe give some advice or an important point not to miss for people wanting to learn Ruby?

Jimmy:
I heard about Ruby from my Computer Science professor/advisor Gary Pollice, who taught all the programming language classes at Worcester Polytechnic Institute. I was searching for an expressive programming language for making games, and Ruby was a perfect fit. A couple years later I worked for the same university building a computer-tutoring system called Assistment, where myself and a couple of other people fed up with the Java codebase ported it to Ruby on Rails. It was a success, and http://assistment.org is now a Rails system. That's where I really learned everything about Ruby and became extremely interested in how Ruby worked.
I learned the most from Ruby when I had a substantial Ruby project to work on, since I got to see its expressiveness making me more productive on a large scale. I'd still suggest trying to learn Ruby on small things here and there, but you'll really be amazed if you use it for something larger.

Matt: IronRuby certainly looks very interesting, can you run Rails on it?

Jimmy:
Yes, at RailsConf 2009 I showed IronRuby running non-trivial Rails applications. IronRuby can run Rails on WEBrick, as well as on the web-server that comes with Windows, IIS. For the database you can use SQLServer Express (which is free), or any .NET based database, like the recent csharp-sqlite port. Here's a detailed post the IronRuby on Rails talk at RailsConf 2009: http://blog.jimmy.schementi.com/2009/05/ironruby-at-railsconf-2009.html.

Matt: Are there any limitations that our readers should be aware of before starting to develop on IronRuby?

Jimmy:
The main limitation is that IronRuby does not support any of the C-based Ruby libraries, and only after 1.0 will we consider building an interop layer between the Ruby C API and IronRuby. In the meantime, people have been porting their favorite C-based Ruby libraries over to C# so it can be used from IronRuby, like Hpricot.
While this seems like a large limitation, most of the C-based libraries Ruby code depends on have an equivalent API in the .NET framework, which IronRuby has direct integration with, making either using directly or porting really easy. For example, the Rails app I showed at RailsConf did image resizing directly with the System.Windows.Drawing APIs rather than ImageMagick.
If your code does not depend on anything outside of the Ruby standard library that is C-based, you should have no problems. Take a look at the documentation for running Rails on IronRuby to make sure things go smoothly: http://ironruby.net/Documentation/Rails.

Matt: What are the pros/cons of using IronRuby versus the standard Ruby (Ruby1.8 or Ruby1.9) on Windows?

Jimmy:
IronRuby is a very fast Ruby interpreter/compiler due to our own tricks we pull to make Ruby fast, the tricks the DLR does to make dynamic languages fast, and the CLR's just-in-time compiler which generates very efficient code. We're definitely aiming to be the fastest Ruby implementation on Windows. The most recent performance work we did was only in the core libraries ("Array", "Hash", etc), and that helped IronRuby surpass Ruby 1.8.6 on Windows and gets much closer to Ruby 1.9.1. IronRuby is continuing to investigate ways of gaining performance in each release.
IronRuby is also a very 1.8.6 compliant Ruby implementation. There is a "-19" flag for any 1.9 specific features you might need, and a "-20" flag for any Ruby 2.0 features we might have in there, but there are no guarantees on those; we only test the 1.8.6 behavior today. We pass ~85% of the RubySpec test suite, the best test suite for Ruby implementations to verify their correctness. However, the numbers I'm more concerned with are whether specific Ruby libraries' test-suites work. We pass Rails, RubyGems, Rake, and RSpec's test suites at well over 90%, and fix compatibility issues when asked about them, so please let us know if your applications run into any compatibility problems.
Other than the limitations that I mentioned in the previous question, you should have no problems. I love people to try running their Rails applications on the latest IronRuby bits hosted on GitHub, and please report any issues you find on http://ironruby.codeplex.com.

Matt: Are they any extra advantages to use IronRuby?

Jimmy:
The most notable advantage is that IronRuby works in Silverlight, a subset of the .NET framework which installs as a browser plugin in Mozilla-based browsers (eg. Firefox on Mac and Windows), Webkit-based browsers (eg. Safari on Windows), and IE (on Windows, duh). The Mono project is implementing an open-source version of Silverlight called "Moonlight" so Linux developers can run Silverlight applications, which I talked about at OSCON 2009. This enables you to write Ruby in the browser instead of JavaScript, for controlling HTML or vector graphics. The best place for documentation/examples today is on the Gestalt website, a little portal designed to bring awareness to Ruby and Python in Silverlight: http://visitmix.com/labs/gestalt. The IronRuby website is in flux at the moment, but clearer documentation is on its way. I also built a little Ruby on Rails plugin called "Silverline" to make it really easy to use Silverlight from Rails. Worth checking out if you want to use Ruby as a client scripting language.
IronRuby has direct integration with the .NET framework, so anything that is in, or run on, the .NET framework can be used directly from IronRuby. .NET namespaces are exposed as Ruby modules, .NET classes as Ruby classes, and you can call methods on them just like you call Ruby methods. This makes it really easy to build pieces of your system in a static language (if it makes sense to use, like for a high-performance message queue, game engine, etc) and then interact with it through Ruby.

Matt: Why is Microsoft interested in a Ruby project? What advantage do they find in sponsoring such a project?

Jimmy:
I see it as a "you scratch my back, I'll scratch yours" situation. Microsoft sponsoring IronRuby helps the Ruby community by making Ruby a first-class language on Windows and .NET, also giving the .NET crowd the choice of using Ruby, and in return the IronRuby project helps promote innovation in the languages that drive Visual Studio purchases (C#, VB.NET, and F#).
As a kind-of related side-note: some people feel it's a bad thing that there are so many implementations of Ruby, kind of like MRI is so bad that others had to fix it, but I completely disagree. IronRuby, JRuby, MacRuby, and most of the other implementations accomplish the same thing for their respective communities; building a bridge between Ruby developers and themselves. Rather than needing to recreate MRI, most have been inspired by it and wanted to bring the language to their platform. It's a great thing for the Ruby community because it gives access to more platforms, operating systems, and libraries than any other language.
Anyway, back to the question: as an example of how IronRuby has helped language innovation, the next version of C# will now have a "dynamic" keyword, indicating that the variable statically-typed as "dynamic" (=P) should perform dynamic dispatch on any method calls, rather than verify the method call at compile-time. This infrastructure uses the Dynamic Language Runtime directly, so C# can use Ruby objects just like they were defined in C#, or any other dynamic-enabled object.

Matt: How will IronRuby make Rails developer lives easier and what are the plans for the future of IronRuby?

Jimmy:
My hope is that IronRuby can benefit existing Rails developers by making Windows a great option to develop and deploy on. By building a Rack adapter specifically for IronRuby and IIS (like I showed at RailsConf), Rails applications can tie directly into the same web-server pipeline that ASP.NET does, significantly reducing the overhead deploying via IIS+FCGI gives you today. This makes deploying Rails applications on IIS just like deploying ASP.NET apps, so system administrators don't have to learn a whole new framework; to them it's just ASP.NET. Then any existing ASP.NET shops who want to offer Rails applications to their customers can, with the same infrastructure and deployment know-how. This is bringing choice to the technologies you choose to deploy on Windows, just like how Microsoft has helped make PHP run well on IIS.
The only definite future plans for IronRuby is continue pushing on performance on compatibility, as well as continue supporting the latest version of Silverlight and Mono. 1.0 will be released when the community is happy with the state of those metrics, and future work should be driven by what IronRuby users want. If you start using IronRuby and want a feature either by 1.0 or post 1.0, please post the request to the mailing list or to CodePlex. We have tons of hopes and dreams for what IronRuby can do in the future, so please come help out!

Matt: Is there anything you would like to add or share with the readers?

Where should I start? What should I do? What can I do to become a better Ruby/Rails developer etc.. (more common questions)

I wish there was a “simple/right” answer to these questions. Something like: “Read this book and you will become an awesome developer”.
Unfortunately, things are not that simple. We are all different and we learn differently, we also come from different backgrounds.

So instead of telling you what I think is the best way to learn, I decided to ask the community.
Here is a quick compilation of some of the responses I received:

What the community says:

How did you learn Ruby and/or Rails?

DHH: I learned Ruby by programming in anger. Attempting to make something real. Not just a toy program.

David Black: I learned ruby via pickaxe and lots of practice and both reading and answering questions on ruby-talk.

Ninh Bui: I was quite a java fanboy back, writing struts + j2ee enterprise apps, Hongli forced me to look at Ruby over a weekend and I learned the Ruby basics. I then learned Rails by googling, reading books and source code.

Tim Connor: the rails community habit of obsessively blogging was probably the biggest help

Lar Van Der Jagt: Ryan Bates’ railscasts for sure. The Rails Way once I knew enough to dig deeper. What I wish I’d done tho is work with experts!

Geoffrey Grosenbach: After I had read a few tutorials, I started by spending a few hours reading through the API docs. Even if you don’t understand everything, it’s a fantastic way to become familiar with what’s available.

Nate Todd: I learned MVC with a few CakePHP apps first. It helped me learn best practices in a language I was familiar with.

Chris Wanstrath: I learned Ruby on Rails by writing apps and reading the framework’s source.

What advice would you give?

Bob Martens: Get involved in the community in some way. They know more than you. ;)

Ismael Celis: understanding the relationship between the parts of MVC. Loads of people coming to Rails don’t know what a design pattern is.

@jeromegn: I find the best trick to learn RoR is to simply try building something. Rails docs and learning Ruby in parallel helped me the most

@johnbender: knowing why instance vars are available in templates, etc. Essentially knowing the basics of ruby would be my initial advice

Sunil Karkera: understanding MVC in Rails was the most important thing for me when I started.

Luke Burton: basic screencasts showing something impressive being achieved in small amounts of code were a great start

DHH: Pick a real project and program in anger. That’s how I’d recommend learning any language including Rails and Ruby.

Anthony Green: Accept that there’s a Rails Way and you need to learn it. What helped me most ? - the community.

Kent Fenwick: Learn by doing a REAL project. Pick something you want to build and slowly chip away at it.

Trevor Turk: learn by reading and writing code… meaning you should try to build something you want instead of dumbly following tutorials…

Ryan Bates: Rails is made up of many technologies (HTML, CSS, Ruby, OOP, SQL, etc.). If you’re struggling with Rails, focus on weakest part.

Geoffrey Grosenbach: And there are many examples throughout that will help a new developer get a feel for the philosophy of Rails. Many people have learned from the Rails from Scratch series at PeepCode

@eifon: A good grasp of MVC is invaluable as is knowing some Ruby before you start.

John Yerhot: don’t be afraid to ask questions and use support channels - irc, mail list, rails bridge, etc…

Roy Wright: use the same version of rails as is in the book you are using.

@brianthecoder: read other people’s code

Ninh Bui: I learned by having discussions with a lot of people, I can definitely recommend that

Chris Wanstrath: Stop asking other people for advice and start coding something.

Different opinions but very interesting answers.
I tried to compile some of what I thought were great resources that helped me and/or other people I talked to.

Never heard of Rails or Ruby, what is it?

Start by watching one of the many screencasts/presentations about Rails.
Rails and software developed using Rails are written in a programming language called Ruby.
If you are new to software developer, you can quickly learn Ruby and I would recommend a great book called Learn to program by Chris Pine.
Ruby is a very elegant and intuitive language that you will be able to pick up quickly while learning new tricks for many years.
However, don’t expect that after installing Rails, you will have a Drupal clone in Ruby.
Rails is a web framework, in other words, a tool to help you write your own web application quickly and efficiently.

Tip: The Ruby website has a lot of information and resource to get started.

I hacked some PHP/Perl/ scripts but I don’t know anything about MVC or Object Oriented development:

Here it really depends on how you learn things. Are you a “How” or a “Why” person?
A “How” person will learn by being shown how to do something and will then reproduce it and learn from it.
A “Why” person needs to understand why things are done a certain way so they can re apply their knowledge on other challenges.

The good news is that Rails uses many conventions and if you pick them up, you will quickly get things done and feel rewarded by what you have done.
That’s great for “How” people, but “Why” people might have to be a bit more patient and start playing with the framework before that can fully understand everything.

You should also check the Rails wiki and contribute info that might be potentially missing.
(If you have a problem that is not covered/discussed in the wiki, try to solve it and then post your solution. If you come across the same problem at a later time, you will be able to quickly find how you solved it. By contributing, you will also save other developers’ time.)

Tip: Start a blog and keep track of what you learned. That will help you and other people facing the same challenges

I started writing a Rails app but I feel limited by my knowledge of the framework and the language

That’s a normal stage, don’t give up! Here are a couple of great reads: The Ruby Way and The Rails Way.
the Ruby Way should satisfy primarily the “why” people, while the Rails way should primarily please the “how” people. I’d recommend to read both.
Don’t hesitate to ask questions, check google, use twitter, blog comments, mailing lists. Try to find some local rubyists to share knowledge with.
Pick a topic you would like to know better and prepare a talk for your friends/local Ruby group or write a blog post about it.
One thing for sure, don’t be ashamed or discouraged. Persevere, it’s worth it (or get out, relax for a while, and then come back and give it another go).

A good way to improve your Ruby/Rails skills is to look at other people’s code. Check GitHub and see how people have solved the same problems you are facing.
You can also attend a Ruby/Rails training, a lot of companies offer classes around the world.
RailsBridge is trying to reach out to people aspiring to become better developer, check their site.

Tip: I often use apiDock when I’m looking for documentation on a method/class.

I wrote a Rails app, I adopted and understood the Rails conventions and I feel comfortable writing new apps.

Congratulations, you should be proud of what you have accomplished! But don’t stop learning!
Did you write tests for your application?
Do your tests really test your application, or are they just there to make you feel better (i.e: change your code, are your tests still passing? they shouldn’t)?
Do you use plugins? Did you look at their code? Do you understand how they work?
Could you write your own plugin? What about a Ruby gem?
Also, how are your javascript skills? What about CSS and DBA stuff? focus on your weaknesses.

I would strongly suggest contributing code at this point. Contribute a patch to one of the many GitHub projects, or even Rails, you will learn a lot!

I wrote a couple of Rails app, I even wrote a plugin/gem.

That’s great, by now you probably are very familiar with Rails and Ruby.
You might want to dive in a bit deeper. Maybe check how to wisely use metaprogramming and/or check on how to write C/FFI extensions.
Why not look at Ruby’s source code to learn how things really work?

It’s also probably a good time for you to start learning new languages to see how other communities do things.
Look at other frameworks and try to understand how and why people chose other conventions/ways.
Play with Python, Java, Scala, Clojure, Objective-C, Ocaml, Scheme or whatever language sounds interesting to you.
You don’t have to master other languages, but you should try to understand the reasoning behind each approach and understand the pros/cons.
It will honestly help your Ruby skills and broaden your horizons.

Tip: Prepare a couple of talks and send proposals to various conferences. (Don’t limit yourself to Ruby conferences)

I know Ruby and Rails like nobody else, I could even quote Rails and MRI’s source code by heart. (just ask a LOC)

If you are reading this post, you are probably in one of the above categories.
Pairing and tutoring are great ways to learn, it’s all about karma. Helping others will help you becoming a better developer.
Feel free to leave advise, links and info in the comments.

Over the past few months, Rails core team member Yehuda Katz has posted a series of great blog articles describing some of the process and technique he’s used while coding Rails 3 with Carl Lerche. In case you haven’t followed his blog posts, I thought I’d repost them here for your educational reading.

Rails 3 Extension API
is where on the new wiki Yehuda has started documenting the new extension APIs which are being added for Rails 3. There’s not a whole lot there yet, but be sure to watch this space in the coming weeks.

The Ruby and Rails community is still growing strong and the sheer number of conferences coming up is proof of that. Below I’ve put together a list of all the conferences/events I could find before 2010 so you can hopefully make it out to at least one. ;-)

If you do attend one of these conferences, do me a favor and thank the organizer for taking the time to produce the event. Most of them spend a great deal of unpaid time making the event happen and most of them aren’t making a profit. Their passion and hard work helps keep our community strong.

Doing Test Driven Development (TDD) effectively is not something that comes easy, even when you’re working with a well structured Rails application. Up until March of this year there really was no guide I could recommend for developers who wanted to learn TDD with Rails.

Noel is a great teacher providing examples that are really easy to follow and code downloads if you want to try writing tests on your own. So if you’re not doing testing yet or you want to learn some best practices, definitely check out Rails Prescriptions.

It’s also worth mentioning that Noel has posted some pretty interesting blog posts on the Rails Prescriptions Blog going over a few testing topics and even some testing interviews with developers like Chad Fowler, James Golick, Ryan Bates, and Mike Gunderloy. Lastly I can’t talk about Noel without mentioning his contributions to the Pathfinder blog, I’m a big fan of his blog posts.

This week I’m happy to tell you about a new set of articles which will be appearing here on the Rails blog called “Community Highlights”. This new series will feature people/projects/sites from the Rails community that may deserve a little extra recognition.

This week, we’re going to start with a few people who received awards on stage at Railsconf 2009, this years Ruby Heroes.

Brian Helmkamp

Brian has been a contributing member of the Ruby community for 4 years now, but is most well known for his testing library Webrat. He’s a contributer to Rails, RSpec, Rubinius, and is a co-author on the recent RSpec Book. More recently he’s been helping out the Rails core team with Rack:Test, and Rack:Debug.

Aman has taken over the maintenance, new features, and the recent releases of EventMachine, which is an invaluable tool for writing fast ruby applications. He’s also the author behind amqp & xmpp4em gems which are deployed far and wide.

Luis has done a lot for the Ruby community in Argentina, but he’s most well known in our community for the work he’s done for windows users maintaining the One-Click Ruby Installer. Recently he’s put up a Plegie to help get the windows installer a new home.

Pat is the mastermind behind Thinking Sphinx which has become a standard when it comes to full-text search in Rails. He is also the author of the excellent Thinking SphinxPDF book and one of the founders of Railscamp, where I hear he makes some killer pancakes.

Dan been tirelessly working on one of the hardest Ruby projects around, DataMapper. He became the official maintainer after Sam Smoot and since then has completely rewritten the test suite to give DataMapper better coverage, has come up with a viable path to completion, and is currently working on making sure DataMapper works great with Rails 3.

Although John Nunemaker has released several widely used open source libraries, like HTTParty and HappyMapper, his main contribution in my opinion comes from his blog Rails Tips. Over the past year he’s written an incredible number educational blog posts on many Ruby and Rails topics.

Those are your six Ruby Hero’s for 2009. If you’re interested you can also watch a video of the award ceremony which talks more about the methodology about how they were chosen and see 5 of these guys receive their awards on stage at Railsconf 2009.

A few months ago, we announced the creation of a "forum" to discuss the future of Rails and what the community is interested in. Since then, many important suggestions/topics were addressed, many features were completed or started.
My goal in this post is to give you a quick overview on the status of the uservoice forum.

Suggestions mentioned and completed:

Nested Model forms
This is something that was actually started before we put the forum together and this feature is now available since Rails 2.3.x

Rails magazine
Olimpiu Metiu already released two issues of his Rails Magazine. The PDF versions are available for free but you can also purchase the print version.

Better Wiki
A lot of people have put efforts in building the new wiki and I'm sure a lot more content will be provided. We have also made the wiki available for translation.

Accepted/started suggestions:

Public and plugin API
This is something that's particularly important for 3rd party developers and therefore plugin users. There is still a lot of work to be done with 3rd party developers and "advanced users" before we can get a fixed API. However, once we will have this API, Rails updates and plugin compatibility should be much smoother.

Slices/Engine
Rails 2.3 came with the ability to have engines in your plugins and if you were at RailsConf, you might have attended Yehuda and Carl's talk on mountable apps. Thanks to some work done on the router and Action Controller, you should be able to mount a Rails app inside another one sometime in the future.

Easier to read code
The refactoring has already started and the internal code should be cleaner and easier to read. Remember that Rails is 5 years old, such a task isn't easy.

The Google Summer of Code program has announced this year’s funding winners, and Rails has four student slots. Here’s what our students will be working on this summer:

Joshua Peek will be refactoring some of the Rails internals, with the goal of finishing the work on Active Model. The idea behind this particular Rails component is to extract some of the commonalities from Active Record and Active Resource, which in turn will make it easier to maintain the higher-level components and make the more consistent.

Nelson Crespo is planning on adding some Dtrace probes into a Rack module. These probes should make it possible to see what’s going on in a Rails application (or any other Rack-based application) with much finer detail than can be easily retrieved now. When the probes are ready, he’ll be working up some visualizations.

Jose Valim is tackling a rewrite of the Rails generator code. Right now, the generators are tightly-coupled to particular architectural choices; the goal is to make it possible to select, for example, a testing library, an ORM, and a Javascript library when you choose to generate a scaffold, and have the generated code use your preferred pieces.

Emilio Tagua will be working on Active Relation. This is another refactoring of the ActiveRecord code, covering the query generation capabilities. With Active Relation as a separate component, Rails will be better positioned to move towards ORM agnosticism.

We’d like to thank all of the students and mentors who participated in the Summer of Code selection process – it was tough to get down to four projects, considering all the great proposals we had. In particular, we had six runners-up whose proposals were excellent: Carlos Kirkconnell, Florian Gross, Hector Gomez, Ian Ownbey, Luciano Panaro, and Daniel Luz. We’re looking forward to seeing what all of our students bring to Rails this summer, and hope not to lose touch with others who are also excited about the prospects for Rails 3.0.

What does this mean to you? Potentially, if you’re the right person, you can get paid to work on the Rails core code this summer!

The “right person” in this case is one who is at least 18 years old (sorry, Google’s rule, not ours!), a full- or part-time college student, and passionate about improving Rails. We’re building a potential list of project ideas on the Rails wiki, but we welcome other interesting proposals. We’re especially interested in work that meshes well with the plans for Rails 3.0, which will be in full swing by the time GSoC launches. If your proposal gets accepted, Google will pay you $4500 over the course of three months to work on the code.

If you’re interested, head over to the GSoC site and start reading about the process. Student applications can be submitted starting March 23.

What if you’re not a student? You can still help out by brainstorming ideas on the Rails wiki. Or if you’re a Rails guru and ready to make a strong commitment to help out the next generation of developers, you can apply to be a mentor.

We’re looking forward to working with this year’s students, and expecting some outstanding contributions to Rails as a result!

One of the measures of the health of a development platform is its ability to support a vibrant ecosystem of users, contributors, speakers, and authors. By this measure, Rails remains in excellent shape. The latest evidence: the release of the first issue of Rails Magazine – 36 pages of full-color glossy print.

The first issue includes 9 articles covering everything from delegation in Ruby to using Saasy for subscription-based applications to performance analysis and getting started with JRuby. The full content will be available on the web shortly, but if you’d like to support this effort (and help ensure that it doesn’t go away) you can order a paper copy for $8 in the US, UK, or Canada.

There are many people in the Ruby community who contribute to our blossoming ecosystem. Some do this by producing educational content and others by contributing to open source libraries or helping out newcomers to the Ruby language. Every week I do my best to help promote the work of these people by talking about the most interesting bits on the Rails Envy Podcast. However, sometimes it just doesn’t seem like enough.

There are some developers who contribute to the community above and beyond the others. These people don’t always get the recognition they deserve, which is why last year I put together the Ruby Hero Awards. Hundreds of people submitted nominations and at RailsConf 2008 we gave away 6 awards to people in our community who deserved a round of applause.

Last year we gave awards to Ryan Bates, Yehuda Katz, Ilya Grigorik, Evan Weaver, Tom Copeland, and James Edward Gray II. This year we’re looking for 6 more people to give awards to and we need your nominations to figure out who you think deserves one. Three things to keep in mind here:

We’re looking for people who do not get their deserved recognition. For example, any of those Rails Activists and Rails Core members are out of the running.

When you submit a nomination you’ll have to enter 25 words as to why you think someone should be nominated.

The final 6 award winners will be determined by having the 6 winners from the previous year voting on them. The nominations you submit will certainly play a big factor in this decision, but won’t be the determining factor (this keeps things from turning into a popularity contest). So please don’t post to your blog telling all your friends to “Nominate You”, it ain’t gonna work.

The 6 winners will be announced on stage at RailsConf 2009, which is just around the corner. So if you know someone Ruby or Rails community who deserves some recognition, please take 2 minutes and submit a nomination for them.

The new and revitalized Rails Wiki launched about two weeks ago, so it’s time for a progress report back to the Rails community. The short answer: things are going well. We’ve had nearly a hundred edits, dozens of topics put in place, and an active discussion on the wiki mailing list. Translators are already at work making the wiki content available in multiple languages. For topics ranging from a first Rails application walkthrough to handling timezones, the new wiki is already a spot to go for quality Rails content.

The wiki team has applied lessons learned from the old Rails wiki, which has gone from being a comfortable spot to find out a few things to a cluttered mess over the years. They started out by defining an overall structure and figuring out what warranted coverage in the wiki. Then they protected a few pages from edits and set up a login system to encourage accountability. The result, so far, is a very promising start at an information resource that can benefit all Rails developers.

But there’s plenty more to do. If you take a look at the new wiki home page you’ll find a bunch of topics in red with dashed underlines. Those are topics that we want, but that no one has written yet. If you have a few minutes to give back to the community, why not drop by? Whether it’s drafting a new topic from scratch, revising an existing topic to be more clear or correct, adding links to high-quality external resources, or translating the wiki into another language, there’s plenty left to do – and just about every Rails developer should be able to contribute.

One thing that has been a continuing challenge for many Rails developers is finding a good designer to work with. There are certainly plenty of fantastic designers out there, but it’s often difficult to find one who is comfortable working directly in a Rails project.

In an effort to help ease this challenge, and at the behest of some interested developers and designers, the Rails Activists have set up a group for Ruby Graphics Designers. The idea is to have a place for communication: a spot where designers can ask questions about git or erb, or where developers can try to find a designer to work with.

Of course, a group without participation is nothing to crow about. If you’re a developer – or especially if you’re a designer who works with Rails – we’d love to have your participation. If you’re interested in the visual design and information architecture of Rails applications, c’mon by and say hi! And if you have other ideas about how we can encourage closer collaboration between the Rails community and the design community, we’d love to hear them.

When the economy hits a downturn this typically has an immediate effect on tech conferences. Many tech conferences cannot run successfully without sponsorships, and with companies becoming more conservative with spending the marketing budget is usually the first item to get cut.

So yet another way you can help Ruby and Rails Activism is by attending (supporting) a conference. Below you’ll find conferences coming up in the next 6 months. If you think I’ve missed one, or if the information is incorrect, please post a comment.

It’s pretty cool to see more RubyCamps. I’m a big fan of BarCamp type events where you keep admission free. Perhaps in this financial climate these types of events will prosper more then they normally do. Feel free to bug me if you want help putting one of these together or need help with publicity.

With the recent revitalization of the Rails Wiki project, we’re seeing people ask how the various pieces of Rails documentation fit together. I thought it might be useful to lay out how the Rails Activists see everything fitting together as we move forward.

Rails is a large and mature framework, with a lot of functionality – and with the Merb merger, there will be even more to learn in the future. As such, it presents challenges for developers at all levels trying to understand how to use Rails effectively. There are many resources to help with the learning process, including commercial books and magazines, screencasts and podcasts, tutorials, blog entries, and training courses. But there is also a series of official written documentation projects.

There’s no such thing as one-size-fits-all documentation. Different developers bring different skill sets, backgrounds, and levels of professional maturity to learning Rails. There are at least four levels of official documentation, overlapping but serving different needs:

Inline documentation, with comments within the code itself (that you can see by running rake doc:rails within any Rails project).

Although at first glance there appears to be substantial overlap, our feeling is that the each of these projects occupies a distinct (and valuable) niche.

RDoc

Provides immediate help for syntax questions

Maintained by the actual core developers and generally up-to-date

Rails Guides:

Provides focused “how to” help for particular problem domains

Target the mid-level developer, possibly with Rails experience

Have a large amount of existing high-quality material

Are already being continuously revised to track changes in edge Rails

Can include version-specific tutorial code samples

Can be delivered as a part of core Rails to provide “guidance at your fingertips” for new developers

Rails Book:

Provides high-level architectural guidance and overview of how the pieces fit together

Digs into the philosophy of the “Rails Ways”, so readers can understand why the framework works the way it does

Targets the developer new to Rails or those wanting to go from the “trees” to the “forest” view

Offers help in conceptualizing Rails and choosing between alternative modules (ORMs, routing DSLs, etc.) in the Rails 3 timeframe

Can draw on the Merb experience in simultaneous translation and pulling in contributions from many writers

Largely version independent

Gives a structured path through end-to-end documentation in a way that standalone Guides do not

Rails Wiki

Community-driven documentation that can respond rapidly to new software and new questions

A good repository to links to external information

Potentially a showcase for Rails itself in the underlying software

A place to put the accumulated community knowledge, even the pieces that are not often needed

It’s important to note that we don’t see these four projects as entirely separate efforts that have no interaction with one another. In particular, it seems likely that the Book will link to the Guides for those seeking additional detail, while the Guides will link to the Book for those seeking additional high-level guidance. We also anticipate that the wiki will point readers to both Guides and Book (as well as to other sources of information).

So, what can you do to get involved? If you’re a writer, translator, or editor, any of these documentation projects would love to have your help:

To contribute to the RDoc, write a Rails patch with good comments or check out the docrails project.