RailsApps

Prelaunch Signup Application

Fri, 26 Apr 2013 17:49:20 -0700

I’ve just added the Startup Prelaunch Site tutorial to the collection of RailsApps Tutorials.

Most startups need a site to announce the founders’ plans and encourage visitors to enter an email address for notification of the site’s launch. The tutorial will show you how to:

sign up visitors using a pop-up form
add buttons to encourage visitors to share the site on social networks
subscribe visitors to a MailChimp mailing list
send invitations (individually or in bulk) for beta testers or a site launch

Some startups use a service such as LaunchRock, KickoffLabs, or Unbounce to create a sign-up page but you might prefer to “own the code” that you can customize. This project aims to:

eliminate effort spent building an application that meets a common need;
offer code that is already implemented and tested by a large community;
provide a well-thought-out app containing most of the features you’ll need.

The tutorial shows how to use Devise to create user accounts that are not confirmed until an invitation is sent. Unlike a hosted page like LaunchRock, when your visitors sign up, they are creating real user accounts in a user database you can use after you launch. The tutorial explains how you can use git to create a branch for your sign-up application, deploy to Heroku, and continuing developing your “real” application to deploy when you are ready to launch. You’ll use the same database for users before and after launch.

I built the example application last year and released a preliminary tutorial. I was able to rewrite and extend the original tutorial, plus pay for user testing, because of financial support generated by subscriptions to the RailsApps Tutorials. So thank you subscribers!

Rails Girls Summer of Code

Tue, 23 Apr 2013 13:26:00 -0700

Here’s the question. The mission of the RailsApps project is to make it easier for people to develop Rails applications. What could a Summer Coder do to advance the mission? Here are some of my ideas. What else would be worthwhile?

Convert the example applications from Rails 3.2 to Rails 4.0
Help write new example applications (covering what topics?)
Help write new example applications aimed at a beginners’ level

I have my own ideas but I’d like to crowdsource this. Please give me your suggestions, either as comments or via Twitter to @rails_apps.

Huh? What’s This About?

Organizations such as Rails Girls and RailsBridge help newcomers get started who are not typical techies (white or Asian males). I’ve been enjoying teaching students at these workshops. The new developers are ambitious and enthusiastic. And it helps me to improve the RailsApps example applications and tutorials when I see the challenges encountered by learners who are new to Rails.

Rails Girls just announced a new program that takes their mission to a new level. It’s the Rails Girls Summer of Code and like Google Summer of Code, it aims to provide a stipend (tentatively $1500/mo) for students to work on open source projects. Unlike Google Summer of Code, Rails Girls doesn’t require applicants to be enrolled in a college. The program is open to any women who have participated in a RailsGirls or RailsBridge or similar workshop and are getting started with Ruby/Rails as newcomers.

Yesterday they began asking open source projects to apply to be matched with students. I jumped at the opportunity. Here’s my proposal:

The RailsApps project provides open source Rails example applications that help learners to close the gap between Ruby on Rails introductions for beginners and the piecemeal advice found on experts’ blogs. The example applications are popular, both among learners and intermediate-level developers who use the example applications as starter apps. There are eight example applications, all written for Rails 3.2, covering topics such as integrating authentication (Devise), authorization (CanCan), testing (RSpec and Cucumber), NoSQL (Mongoid), payments (Stripe), and subdomains.

In addition to benefiting the student directly with skill development and achievement, working on the RailsApps project will directly benefit other students by providing high quality Rails example code for study and the community at large by providing well-maintained starter applications. Just as important, the student will make a significant contribution to the RailsApps project by providing the perspective of a beginner to improve the example code and documentation.

Your Comments Please!

I talked to Sven Fuchs, one of the Rails Girls organizers, about my proposal and he was encouraging. He asked me to provide more specifics about what a Summer Coder could do. So now I’m asking for ideas from supporters of the RailsApps project. Can I get your suggestions? How could a Summer Coder contribute to the RailsApps project? Submit comments or suggest via Twitter to @rails_apps.

Rails Apps Composer on Guard

Thu, 04 Apr 2013 16:13:00 -0700

Paavo Leinonen frequently uses the rails_apps_composer gem when building applications for clients. He recently contributed support for continuous testing with Guard.

I wanted to ask him why Guard is important. Paavo has been very enthusiastic about Rails Apps Composer so we created this interview. I swear a public relations firm didn’t edit this, it’s just Paavo’s natural enthusiasm that comes across here.

Why do you use Rails Apps Composer?

I work for Protoverstas in Finland which provides an agile three-week program to launch application ideas. Rails Apps Composer is an invaluable tool when prototyping and pivoting applications at a fast pace for demanding clients. It would be way too tedious to always start with “rails new” without any template. So Rails Apps Composer means less typing work for us and faster profits for our clients!

Tell us what’s on your desktop.

I do full-stack test-driven Rails development on OS X. I like to keep my environment as minimal and esthetically pleasing as possible. On my main monitor I keep two windows open side by side: MacVim as my text editor (using the Janus distribution with its amazing plugins) and iTerm2 as the terminal (running automated tests with Guard in one tab and using the zsh command line in another tab). I use the Solarized color theme in both, so they are easy on my eyes.

What is your Rails stack?

I’m very opinionated as a developer. I prefer PostgreSQL or MongoDB for most projects. I couldn’t imagine writing plain HTML again, so HAML is a necessity for me, as well as Coffeescript and LESS. Fixtures feel way too old-school, so the Fabrication gem is my choice. So is all the manual work needed for default forms, so please, SimpleForm for me. I like to deploy to Unicorn (and of course use it for development, too). These more or less permanent preferences are included in my Defaults file as described in Rails Apps Composer documentation.

What else do you need in a starter application?

Twitter Bootstrap is handy in some cases, though sometimes it’s best just to normalize CSS. Most apps I write require some kind of user management, so it’s cool that Devise and Omniauth provide most of the boring stuff right out of the box! Their routes and basic views are set up when using Rails Apps Composer, just how I like it.

What about testing?

I really want to encourage more developers to make test-driven development part of their practice. For unit testing I use RSpec and request testing I do with RSpec and Capybara. In my opinion Cucumber doesn’t provide that much value itself and in many cases acts only as a proxy to Capybara’s functionalities. In an ideal world, testing controllers, views, helpers, and routes all as single entities would be nice, but in the real world… just not worth it. Thoughtfully designed and well-written unit tests and request tests can make your test coverage rock solid.

How does Guard fit in?

When I edit and save any file in my Rails project, Guard keeps track of tests that are affected and runs them automatically. I see results immediately in my terminal window without needing to touch anything! It’s easy to keep track of which tests are passing already and which still need some more work.

On my second monitor I keep a browser open. Luckily I don’t need to touch it much, because automated tests do the boring and repetitious clicking work for me! Even when I need to touch it, I can do it without using the mouse, thanks to the Vrome plugin providing Vim-like controls for Chrome. Guard also restarts the Rails development server when needed, and monitors the Gemfile (automatically running “bundle install” as needed).

Keeping the development process streamlined and my environment beautiful helps me focus and keeps my quality standards high. Writing ugly code, copy-pasting or leaving features untested would feel just plain wrong. The right tools are important. So thanks, Daniel, for making my daily work more pleasurable with Rails Apps Composer!

Thanks, Paavo, for letting me know how it serves you, and for taking time to describe your work environment. And especially, thanks for contributing the Guard option to Rails Apps Composer.

Project Gemsets with RVM

Wed, 03 Apr 2013 14:41:00 -0700

I use RVM, the Ruby Version Manager, because I often switch between projects that require different versions of Rails. I create an RVM gemset for each project.

RVM looks for a .rvmrc file in a project root directory and automatically switches to the required version of Ruby and the correct gemset. Now, with version 1.19, RVM looks for files named .ruby-version and .ruby-gemset in the root directory. RVM will prompt you to replace the .rvmrc file with the two new files. It’s a worthwhile change, for several reasons. Unlike the .rvmrc file, the two new files contain no shell commands so they don’t need “trusting” and performance is faster. The .ruby-version file is also recognized by other Ruby version switchers such as chruby or rbenv (though the .ruby-gemset file is unique to RVM). I’m delighted to see movement toward a unified standard. A big thanks to Fletcher Nichol (fnichol) for initiating the unification effort.

The Rails Composer tool and the rails_apps_composer gem now create the .ruby-version and .ruby-gemset files when you generate a starter application. I’m upgrading the RailsApps example applications as well.

Here’s details for users making the transition to the new files. If you have a simple .rvmrc file:

rvm use ruby-2.0.0@myapp

It can be transformed to .ruby-version:

2.0.0

And .ruby-gemset:

myapp

Be sure to remove the .rvmrc file as it takes precedence over any other project configuration files:

rm .rvmrc

Keep in mind that if you’ve extended your .rvmrc file with custom shell commands you won’t be able to replace it. No worries though, as RVM will continue to recognize the .rvmrc file.

For details on how RVM gets configured per project, see a discussion.

Now is a good time to say thank you to Michal Papis (@mpapis) for his efforts to improve RVM. As a utility, RVM is not an official part of Rails but it greatly improves the day-to-day developer experience.

Ruby 2.0 and Rails 4.0

Sat, 02 Mar 2013 11:25:00 -0800

This week brought a great leap forward for Rails development with the release of Ruby 2.0.0 (final) and Rails 4.0.0 (beta).

Ruby 2.0 makes Rails much faster. You’ll love the speed improvement.

Rails 4 brings new features with new twists on implementing Rails applications. Rails 4 final is a few months away but you can install Rails 4.0.0.beta1 now to get familiar with the changes coming in Rails 4.

For projects in production, or deploying to production in the next few months, upgrade your applications to Rails 3.2.13 which patches Rails to fully support Ruby 2.0.0.

I’ve written two articles to help you get started with Ruby 2.0 and Rails 4.0.

The first article details how to install Ruby 2.0 with two different versions of Rails so you can easily switch between versions to work on production applications or begin work on new applications with Rails 4.0.

In the second article, I suggest a process to follow in updating Rails applications.

I’ve updated all the RailsApps example applications in the RailsApps GitHub repository to use Rails 3.2.13.rc1 and they all run nicely with Ruby 2.0. The Ruby 2.0 speed improvement is sweet, especially when a Rails application initially launches.

If you like to generate starter applications for Ruby 2.0 and Rails 3.2, you can use the Rails Composer tool. If you’ve installed Ruby 2.0 and Rails 3.2.13.rc1, the Rails Composer application template will build any of the example applications as a Rails 3.2.13 application.

I’ll add a new suite of Rails 4.0 example applications and tutorials to the RailsApps project before Rails 4.0 final is released.

Rails Apps Composer version 2.2.32

Thu, 14 Feb 2013 14:51:00 -0800

I released version 2.2.32 of the Rails Apps Composer gem today.

Haml version 4.0 was released yesterday with a new implementation of the html2haml utility. The Rails Apps Composer gem uses the html2haml tool to convert ERB files to Haml files. That means you can use the Rails Composer tool to create a Haml version for any our example applications.

I like to use Haml for my own projects because it reduces the clutter in my Rails view templates. See the article Haml and Rails for a discussion of advantages and drawbacks.

I’m intrigued by Slim (an ERB or Haml alternative) because I’ve heard it is fast and even less cluttered than Haml. I found a haml2slim gem to convert Haml templates to Slim templates but it only serves as a preliminary tool for templates conversion. The Rails Composer tool offers an option of using Slim but marks it as “experimental” because most view files need to be manually tweaked before they will work.

I updated a few other gems for the release of version 2.2.32 of Rails Apps Composer (see the changelog).

Filling Rails Potholes

Wed, 30 Jan 2013 18:44:00 -0800

Yesterday I was at an open house for Code for America as the organization prepared to send off teams to help ten municipalities improve government services. It’s a great organization with an admirable mission and I was reminded how our skills as coders give us tools to make an impact on so many ordinary lives. The Code for America Fellows are all doing a service year so they can write apps that help citizens report potholes, monitor the status of neglected homes in blighted areas, and streamline the process of opening new businesses.

Something similar, improving the ordinary lives of Rails developers, was on my mind as I connected with several Rails developers, including some I met at the SF Rails Girls workshop last weekend. You see, I’d spent most of the afternoon tracking down an issue with FactoryGirl that had resulted in a storm of GitHub issues for the RailsApps example applications that I maintain. Four days ago, the FactoryGirl maintainers released factory_girl_rails version 4.2.0 and suddenly every application was broken immediately after being generated by the Rails Composer tool.

The error reports showed that the problem was related to FactoryGirl and I knew that the new version of FactoryGirl had just been released. I saw that several new and inexperienced Rails developers had tried to build applications using the RailsApps examples and were overwhelmed and frustrated, not sure why things were broken and unsure how to proceed. One of my most helpful volunteer contributors stepped up and tried to help but there was nothing in the FactoryGirl changelog or recent commits that offered any clues. It took me a few hours of hunting to determine that factory_girl_rails default behavior when used with RSpec had changed from version 4.1.0 to 4.2.0. See the issue; I don’t know whether the change was intentional or just an oversight. I’m now in the process of updating all the example applications and accompanying tutorials to accommodate the change.

If you work with Rails every day you’re used to dealing with similar situations. We get used to it. Less than two weeks ago I faced a similar issue. Devise version 2.2.0 changed a default password length. All the example applications broke because the example passwords in database initialization files and tests were too short. I spent a day updating example applications and accompanying tutorials to use longer passwords to accommodate the new Devise default. There are (usually) good reasons that our favorite gems change. As experienced Rails developers, we just deal with it. It goes with the territory. It’s not so easy for inexperienced developers, hobbyists and people who only work with Rails part-time or occasionally (I’m thinking particularly of the attendees at last weekend’s SF Rails Girls workshop).

Stand back if you are allergic to rhetorical figures because here comes the metaphor from the title of this post. We’re dealing with Rails potholes every day. Inevitably there will be potholes when every day we run the big trucks down Main Street. We get used to potholes and drive around them when we commute to work every day. It’s the out-of-towners who notice all the potholes on their first visit and see the blight we barely notice.

Appropriately, that was the topic of a conversation at the Code for America open house. I’d just met Moncef Belyamani, a Rails developer (and now a 2013 Code for America Fellow) who is an enthusiastic supporter of the RailsApps project. I was telling him that I had just launched the RailsApps Tutorials membership site to support the project but I was doubtful that people would see the benefit of spending $19/month to support the project by paying for access to periodically updated tutorials. He happily convinced me that I was underestimating the value of the project. The project is not fundamentally about delivering tutorials (though they are important). What is more important is the work that goes into keeping the example applications up to date. The real value for the community, both full-time developers and part-timers, is the availability of a reference implementation that uses the gems we use most often.

Steve Klabnik recently pointed out that “Rails has Two Default Stacks”. Chances are, if you are building a Rails application, you are going to be using ERB or Haml, MiniTest or RSpec, perhaps Cucumber, Twitter Bootstrap, likely Devise and maybe CanCan. Wouldn’t it be nice to know they all worked together? They do, on most days. And on the days they don’t, you can check the RailsApps example applications to see if anyone else is having the same problem. And hopefully find that someone worked out a fix if something is broken. Sometimes the problem is a gem in isolation, in which case the gem’s repo is the best place to report a problem. But sometimes, like the combination of factory_girl_rails and RSpec, there’s an integration issue that’s easiest to identify with a reference implementation.

That’s what it takes to fix the Rails potholes. We’ve got an app to report the potholes; it’s called GitHub issues. We’ve got a crew to fill the potholes; it’s the entire community but especially the people who are helping out with the RailsApps project.

And this is where another metaphor is appropriate: Fresh is not just for milk. Ultimately the utility of any reference implementation depends on how fresh it is. A blog post from 2009 can show you how to set up FactoryGirl and RSpec but is it still current? I’m doing all I can to keep the RailsApps example applications up to date. I don’t always hunt down bugs myself (I prefer to accept pull requests!) but as the project maintainer I’ve taken on the responsibility to keep the applications current.

That’s where the RailsApps Tutorials come in. Developers won’t pay to maintain an up-to-date reference implementation they find on GitHub (it is open source). But people will pay for comprehensive and up-to-date tutorials. By keeping the RailsApps Tutorials up to date, which are supported by the $19/month Pro subscription, I’m keeping the example applications up to date. Fresh is not just for milk; tutorials and example applications are valuable when they are fresh.

For more about subscription program, see the post RailsApps Tutorials Launches.

RailsApps Tutorials Launches

Sat, 19 Jan 2013 15:17:00 -0800

Hackers need help learning Rails. Not just beginners, but experienced developers making the transition to Rails, and especially people who have completed an introduction and want to take the next step to build real-world web applications. The RailsApps project aims to bridge the gap.

I released the first RailsApps tutorial two years ago. Since then, I’ve created eight example applications with accompanying tutorials and over a dozen in-depth articles helping Rails developers. Over time, the example applications have become more ambitious and the tutorials more detailed. Now I’m going to put the project on a solid footing as a business so it can continue to expand.

I’ve taken the first steps to creating a revenue stream that will support the RailsApps project. This week I’ve launched the RailsApps Tutorials website. I’ve done testing of various offers and found visitors are willing to support the project with a $19 monthly membership fee. Consequently, on the site I’m featuring a Pro Subscription Plan. For $19/month, you too can support the RailsApps project.

Example Applications Are Free

All the example applications remain publicly available in the RailsApps GitHub repository. This is an open source project and dozens of developers have contributed to the example applications, so of course they must remain free. As open source applications, they attract the constant fixes and improvements that keep an open source project alive and growing. This is the project’s first value proposition: to provide a reference implementation of common starter apps that can be a basis for real-world Rails applications. The tutorials $19/month Pro Subscription will help us sustain and expand the repository of example applications; the code itself will remain free.

Tutorials “Bridge the Gap”

Early on, I learned that developers appreciate the project because I write an in-depth tutorial to accompany each example application. There is no “mystery code”; the tutorials show each step needed to build a complete working Rails application and more importantly, explain the implementation decisions behind the code. This is the project’s second value proposition: to bridge the gap between Rails introductions for beginners and the piecemeal advice found on experts’ blogs.

I’ve been told many times, “You should charge for the tutorials!” With the RailsApps Tutorials website, I will. However, I believe that basic tutorials should remain free. The tutorials that help a Rails beginner get started with real-world web programming will be available with a free Hobo Subscription Plan (hoboes ride the rails for free!).

I’m aware that hobbyist and student developers may also need access to the more advanced tutorials (the Premium tutorials) but may not be able to support the project with a monthly membership. Consequently, an inexpensive Student Plan will allow anyone to download any individual Premium tutorial for a $9 one-time fee. I’m hoping that visitors who sample a single tutorial will see the value in purchasing access to the entire collection for $19/month and thus support the project’s ongoing expansion.

Value of Maintenance

I’ve discovered users like the example applications, love the tutorials, but appreciate that the project’s greatest value lies in its ongoing maintenance. Any Rails application or tutorial gets outdated quickly as Rails and its ecosystem of gems go through constant rounds of updates. This is the project’s third value proposition: keeping the example applications and tutorials up-to-date so developers can find a reference to current implementation practices. This is why I started the project. Every time I came back to working with Rails, even after only a few months, things had changed and I needed to see a current implementation. Ultimately, this is the value of the monthly Pro Subscription Plan. Professional developers have shown me they will support a project that provides up-to-date code and tutorials in the ever-changing Rails ecosystem.

Would You Like to Be a Hero?

Based on feedback from developers who work in the corporate world, I’m offering the Hero Subscription Plan. It gives you subscriptions for everyone on a team. In the enterprise it is easier to pay for a yearly subscription than to receive an invoice every month. At $349 a year, the cost for the entire team is less than the cost for two Pro subscriptions. If you’re in a position to make a purchase on your company’s corporate card, please consider supporting the RailsApps project with a purchase of the Hero Plan. You’ll be a hero to everyone on your team and you’ll be a hero by supporting a project that benefits the entire Rails community.

From Hoboes to Heroes

I hope you see the wisdom in monetizing the Premium tutorials as a way to support the growth of the RailsApps project. And I hope you see the value in offering a variety of subscription plans to accommodate all users. So far, in the first days since launch, most of the subscriptions have been for the Hobo Plan. After all, everyone likes something for free. I hope over time, more people will see the long-term value in supporting the project with a Pro Subscription or Hero Subscription.

How about you? Is the project valuable to you? Can you support it with a purchase of a subscription plan? Please let me know — by clicking “Subscribe” on the RailsApps Tutorials website.

Setting Local Environment Variables in Rails

Thu, 13 Dec 2012 08:05:00 -0800

As our RailsApps applications grow more popular, help requests are growing more frequent. Particularly with the release of the rails-stripe-membership-saas application, I’ve seen people having trouble with setting Unix environment variables. Granted, if you’re doing development with Rails, you really should be able to sort out your own problems with Unix environment variables. But telling newbies to school up is not really a solution. And sometimes the problems stem from rvm or other local shell complexities. Taylor Mock saw the problem and stepped up with solutions on two fronts. First, test suites to identify if the API keys required by the application are set properly; and second, a clever solution to set local environment variables through Rails, rather than the Unix shell.

Taylor Mock’s implementation takes advantage of Ruby’s ability to set environment variables as well as read them. We create a file named config/local_env.example.yml and then add some code to the Rails config/application.rb file to read key/value pairs from a YAML structure and set environment variables that can be used elsewhere in the Rails application. The result? A bulletproof way to set environment variables without the Unix shell.

Our approach was discussed on Hacker News today and several people suggested using the figaro gem which provides a similar implementation.

If you use the rails_apps_composer gem or the Rails Composer tool, there’s now an option to use the figaro gem and a config/application.yml file to set local environment variables.

For more about the solution, see the article Rails Environment Variables.

Special thanks to Taylor Mock this week. He’s making significant contributions to the RailsApps project with a combination of intelligence and dedication that’s overcoming obstacles and moving the project forward.

“Better Errors” Now an Option in Rails Composer The...

Sun, 09 Dec 2012 19:22:26 -0800

“Better Errors” Now an Option in Rails Composer

The Better Errors gem replaces the standard Rails error page with a much better and more useful error page. Better_errors is now an option when generating an application template with the rails_apps_composer gem or the Rails Composer tool.

"Unholy Rails" Explained

Thu, 27 Sep 2012 13:43:41 -0700

Most of the attention for the RailsApps project has come from people who follow me on Twitter plus occasional announcements on the RubyFlow community blog.

HN

Yesterday was awesome. My most recent article was discussed on Hacker News. You probably know it: HN is a popular discussion forum, probably the most active at the intersection of startups and coding. Making the front page of HN results in a lot of traffic. More importantly, the HN community is smart and often expert so comments are informative.

I was gratified the article got attention because I’d worked on it for more than two weeks, far longer than I expected (or wanted). The topic is complex and it was difficult to ascertain recommended practices. I solicited feedback from several experts and got great advice. It took a lot of time but I eventually got the clarity I wanted.

Here’s the article:

Unholy Rails: External Scripts, jQuery Plugins, and Page-Specific JavaScript

This article explains what to do when your application is not wholly Rails (hence the cute title).

Why Did I Do It?

Why did I make the effort to write the article? It certainly wasn’t for glory. The topic is a peculiar and obscure corner of Rails development practice that is not well documented. Despite the brief HN notoriety, the article will not get much traffic, save from a handful of desperate Google searches.

I got sidetracked into researching the article simply because I needed to know the best way to handle external JavaScript libraries and I couldn’t find authoritative answers.

My Current Project

Now that the article is complete, I’m going back to the current project, which is an effort to write a Rails tutorial for a membership site.

I’m showing how to build a subscription-based SaaS site that uses Stripe to manage recurring billing. It will be a few more weeks before the example application is complete (with the tutorial) but I expect it will be popular.

Would You Pay for Premium Tutorials?

While I’ve been working on the membership site example application, I’ve been running tests to see if there is a market for subscription-based access to premium tutorials. I’m pleased to see many developers are willing to pay for the tutorials I’ve been writing. Many people have urged me to find a business model to sustain the growth of the RailsApps project (and keep me writing) and it looks like I’ve found one: continuing to offer the example applications on GitHub for free and offering subscriptions for some of the tutorials.

I’ll use my own membership site example application to host the tutorials when I’ve finished the example application.

Necessary Detours

The “Unholy Rails” article was a detour, but a necessary one. It’s the nature of the project. I start out writing a useful example application, one that almost everyone needs, and I document all the development decisions and procedural steps as I build it. When I encounter something that is poorly understood, such as use of JavaScript libraries in Rails, it’s down the rabbit hole for me, until I get enough information to identify recommended practices and explain the issues. This time, when I came back up from the rabbit hole, there was a crowd on Hacker News cheering me on.

As always, thanks for the encouragement, it’s what fuels the project.

What's New in Rails Apps Composer

Sun, 26 Aug 2012 18:50:00 -0700

Just to recap, the Rails Apps Composer gem installs a command line tool to assemble a Rails application from a collection of “recipes.” It’s useful for creating and maintaining starter apps. I use it to maintain the RailsApps project example applications.

Progress Report

Six weeks ago, I announced an ambitious roadmap for Rails Apps Composer version 2.0.

I wanted to fix version 1.0’s shortcomings. It was cumbersome and difficult to maintain. I had a short list of ambitious improvements. I spent two weeks in coding, then a week writing detailed documentation (the Guide to the Rails Apps Composer Gem). After three weeks of concerted effort, I released Rails Apps Composer version 2.0, meeting my goals for improvement.

Now, three weeks after releasing version 2.0, with a rapid succession of releases, we’re at Rails Apps Composer version 2.2. I’ve gotten excellent code contributions from some capable and enthusiastic developers: notably Jim Riordan, tomykaira, Tom Scott, Michaël Witrant, and Vitaly Kushner. For me, it’s a great feeling to clean up a project and bring it closer to my vision. It’s even better when strangers see the value in the project and jump in to add features that exceed my ambitions. Thanks!

Of course, I’m particularly obligated to Michael Bleigh because Rails Apps Composer would not be possible without his creation of the original RailsWizard gem.

What’s New

Here’s a summary of the top features you’ll find in Rails Apps Composer version 2.2.

A “quiz” queries the user for preferences, including:

webserver (WEBrick, Thin, Unicorn, Puma)
database (SQLite, PostgreSQL, MySQL, MongoDB)
template engine (ERB, Haml, Slim)
testing (Test::Unit, RSpec, Capybara, Cucumber)
fixture replacement (Factory Girl, Machinist)
front-end framework (Twitter Bootstrap, Zurb Foundation, Skeleton)
email (Gmail, SMTP, SendGrid, Mandrill)
authentication (Devise, OmniAuth)
authorization (CanCan with Rolify)

The program will also:

create a GitHub repo
create a project-specific rvm gemset and .rvmrc
set a robots.txt file to ban spiders
add ‘therubyracer’ JavaScript runtime for Linux users

Gems can be added at a prompt without writing custom recipes.

To skip the quiz, the user can create a defaults file specifying recipes, gems, and preferences.

A user can write local recipes that can be added to the mix without forking the gem.

A new ‘copy_from_repo’ method adds powerful downloading of files to any recipe.

Downloading of files from the example app repos reduces the complexity of recipes.

The ‘copy_from_repo’ method converts ERB files to Haml or Slim at the user’s option.

A ‘rails apps’ recipe generates any of the RailsApps project example applications.

Lastly, a diagnostics module creates a README file that displays a list of recipes, gems, and preferences selected to create an application. The diagnostics make it easier to debug integration issues and identify which combinations of recipes, gems, and preferences work well together.

Rails Apps Composer version 2.2 is very powerful. Take a look at the Guide to the Rails Apps Composer Gem to learn about all its features.

The gem brings us closer to the possibility of automatic assembly of real world Rails applications. We can now build starter apps (and maintain them with the collaboration of an open source community) that are much more powerful than the starter apps we had a few years ago. Even though Rails itself has gotten more complex and powerful.

With the new Rails Apps Composer, I’ve been able to build the Rails Composer tool which can generate any of the five RailsApps project example applications from a single command. Five apps is just a start; I’ve got more high-quality, complex example applications in the works.

The Future

There are a few recipes I’d like to add in the near future. Top of the list is a deploy recipe that would offer the option of immediate deployment to Heroku, CloudFoundry, or EngineYard.

I’m also looking forward to new surprises coming from the developers who use the Rails Apps Composer gem. Thank you to all for making this a successful open source project!

Got a suggestion for a recipe or a feature you’d like to see in Rails Apps Composer? Leave a comment. Are we making it easier to build starter apps?

Roadmap for Rails Apps Composer Gem 2.0

Fri, 13 Jul 2012 12:50:26 -0700

I’m planning changes to the rails_apps_composer gem.

Rails Apps Composer is a gem with recipes to create Rails application templates you can use to generate Rails starter apps. It creates ready-to-run Rails web applications and makes it easy to create and maintain a starter app.

If you use the gem, please take a poll to let me know whether the app is useful or needs improvements. You can also make suggestions for improvements.

The rails_apps_composer gem is at the core of the RailsApps project. It generates the application templates and, in turn, the example apps. The rails_apps_composer gem is used by dozens of developers to maintain their own starter apps as well as starter apps from the RailsApps project. Maintaining the rails_apps_composer gem is key to keeping the example apps and tutorials current as the ecosystem of gems (and Rails itself) evolves. Right now, the gem is difficult to use, largely because it is structured around recipes that combine various popular gems with code that tweaks templates to accommodate each gem’s particular requirements. Frankly, the recipes are difficult to read and poorly organized. I intend to develop a rails_apps_composer version 2.0 that restructures the recipes and moves most of the code tweaking out of the recipes and into downloaded template files.

Here’s what I plan for rails_apps_composer 2.0:

improve the “quiz” that sets up the starter app
offer recipes for more complex and fully functional starter apps
base recipes on functionality (authentication, testing) instead of gems (Devise, RSpec)
reduce the manipulation of files with ‘gsub’ and use more downloaded template files
make it easier for developers to understand the code and make contributions
generate a README for any starter app that shows which gems are used

Please make suggestions for improvements you’d like to see.

You can see the poll results here.

Rails Apps Composer version 1.5.5

Fri, 13 Jul 2012 12:19:00 -0700

I released version 1.5.5 of the Rails Apps Composer gem today. Versions 1.5.3 and 1.5.4 were released within the past two weeks. It’s the gem you can use to generate a Rails starter app.

Version 1.5.5 is primarily intended to accommodate the release of Mongoid 3.0. This version and recent versions also offer a number of gem updates and small improvements. See the CHANGELOG for details.

There are new recipes for turnip (a Gherkin extension for RSpec) and unicorn (recommended as a faster web server).

Thank you for contributions to this update:

Jim Riordan
Bradley Grzesiak
Earl St Sauver
Andrew J Vargo
Michel Pavan Macedo
ngottlieb

With this release I’ve updated the application templates which are used to create and update the RailsApps example applications. And each example app has been updated to match the version generated by the templates.

Bug Fix for Rails Prelaunch Signup App

Sun, 24 Jun 2012 12:20:00 -0700

Closed issue #7 for the Rails Prelaunch Signup App. When visitors requested an invitation, a new account was created, and a password was created. Turns out I’d overlooked some code in the application.js file that was creating a password with the value “undefined.” I’ve fixed the bug by cleaning up the Javascript. Now it works as it should. When the administrator invites the user to confirm his or her account, the user will be prompted to choose a password.

If you’ve been running the app in production and have collected real visitor invitation requests, you’ll need to perform a bulk update to your database, setting the encrypted password field to null for all users except the administrator. If you don’t update the database, any visitor you invite will not be abel to set a password for their account.

Soft Launch for Rails Prelaunch Signup App

Wed, 20 Jun 2012 17:45:00 -0700

This is my favorite of all the example apps I’ve built. And it keeps getting better and better!

I’m in the middle of a “soft launch” for the app, which means I haven’t made a promotional push, but the app has been mentioned on Hacker News (with some very nice comments about the RailsApps project, too). I’m gathering user feedback and improving the app and the tutorial.

I’ve created a project page for the app subtitled, “An example Rails 3.2 app for a web startup prelaunch site.” When you visit the page, please give it a tweet (use the tweet button). This is a great time to let people know about the app, so I can gather feedback and make any needed improvements.

Version Updates for Rails 3.2.6

Wed, 20 Jun 2012 17:28:47 -0700

Today I updated all the RailsApps example apps to use Rails 3.2.6. Changes are minor.

Rails 3.2.6 was released eight days ago. No new features, just two important security fixes. See the announcement “Rails version 3.2.6 has been released.”

I released Rails Apps Composer versions 1.5.1 and 1.5.2 just before that, with updates to some gem versions, a fix for an incompatibility between Rolify 3.1 and Mongoid, and a “prelaunch_signup” recipe. See the changelog for details. No important features, just maintenance plus support for the new Rails Prelaunch Signup example app.

I’ve updated all the application generator templates in the rails3-application-templates repository to conform to Rails Apps Composer version 1.5.2.

Rails Apps Composer version 1.5.0

Mon, 21 May 2012 19:00:00 -0700

I’ve released version 1.5.0 of the Rails Apps Composer gem. It’s a gem you can use to generate a Rails starter app. Makes it easy to create and maintain a starter app from recipes that integrate commonly used gems.

This release includes a major new feature contributed by Bryan Stearns.

For the first time, you can create a “defaults” file so every time you generate an app, you can use the same set of recipes and preferences. Bryan Stearns really gave the feature a lot of thought, so it is very flexible. I’ve expanded the README to explain all that you can do with the Rails Apps Composer gem.

It’s been exactly a year since I saw that the popular Rails Wizard gem was no longer maintained and forked the code to create the Rails Apps Composer gem. In the last year, dozens of developers have contributed features, recipes, and patches. Over 400 people are watching the project on GitHub. I’ve been focused on using the gem to maintain the example apps for the RailsApps project and sometimes I forget that a lot of other people are using the gem, too. But I try to keep up with the stream of pull requests and issues. I initially hesitated to fork the Rails Wizard gem but now I feel it was worthwhile.

In the last month, there’s been renewed interest in the idea of generating starter apps for Rails. Probably because Rails continues to get more complicated and a gem like Rails Apps Composer helps to reduce the burden of integrating various popular gems into a Rails app. I’m aware of a similar project from Daniel Davey: the app_drone gem which is the basis of the drone.bz website. And last month, Dr. Nic Williams of EngineYard forked the Rails Wizard gem to create his App Scrolls gem. I’ve made a list of Rails application template projects if you’re interested. I’d love to see a united effort in this area to avoid duplication of effort. I’m not sure if that will be possible, given a divergent codebase, but I’d like to explore it.

Rails Apps Composer version 1.4.12

Thu, 17 May 2012 16:19:17 -0700

I’ve released version 1.4.12 of the Rails Apps Composer gem.

This is a minor release. There is one significant feature:

send email via SMTP, Gmail, or SendGrid accounts

The SendGrid option will be useful for the rails-prelaunch-signup app.

The rails_apps_composer CHANGELOG lists the improvements.

With this release I’ve updated the application templates which are used to create and update the RailsApps example applications.

Rails Apps Composer version 1.4.10

Fri, 11 May 2012 21:25:46 -0700

I’ve released version 1.4.10 of the Rails Apps Composer gem.

This is a minor release. It adds several small improvements and bug fixes. The rails_apps_composer CHANGELOG lists the improvements.

Thank you to

Alex Kravets
nrser
allen13

for identifying and reporting the issues that prompted this update.