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:
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:
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!
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?
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 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.