• Read more about Sketch.js: HTML5 Canvas Sketchpads for Whyday

Last Friday I decided to celebrate _whyday by taking a departure from my normal open source path and writing some Javascript (well, technically Coffeescript). So today we're announcing Sketch.js, a simple jQuery library to enable HTML5 Canvas "sketchpads" for any web application.

Quick and Easy Doodling

Sketch.js allows you to initialize a canvas element as a sketchpad as well as draw with different colors, stroke sizes, and tools (currently only a marker and an eraser). These tools can be accessed programatically or using special links with data attributes. Here's a basic example:

<canvas id='mysketch' width='400' height='300'></canvas>  <script type='text/javascript'>   $('#mysketch').sketch(); </script> 

That's all there is to it! The canvas will now be drawable by your users and, thanks to a relatively straightforward API, you can customize it to your heart's content.

The HTML5 Canvas element is extremely powerful but it can be a bit daunting to get started. I took this as an opportuntiy both to learn it some myself and to provide a drop-in tool for others. Hopefully you find it useful!

Learning on Whyday

I set out on Whyday with the intent of learning a few new tricks. Here's some new things I tried out:

1. Sketch.js is coded in Coffeescript. I had used Coffeescript before but never its class system or more advanced features. I like it!
2. It's documented using Docco which has been one of the most straightforward and pleasant documentation experiences I've ever had. It also, as an annotated source engine, encourages clean source code.
3. I set up an awesome instant build environment that uses Guard to compile Coffeescript, generate docs with Docco, and minify the JS into a build directory. The workflow worked really well.
4. I tried to do a very little bit of unit testing using QUnit, which was my first major foray into Javascript testing. Unfortunately, with how much I was learning about Canvas at the same time, I didn't keep at the testing as much as I would have liked.

All in all it was a great chance to sharpen my skills on something that I hadn't had a ton of experience with. You can see the docs (and live examples) on its GitHub pages or visit the code on GitHub. Enjoy!

• Read more about 10 Tips For Open Source Citizens

This post is part of a series called Open Source Citizenry in which we discuss ways to eliminate the barriers that developers and companies face to fully participating in the open source community.

You might think there's not really anything to being a good user of open source. Install the library, use it how you need it, and move on. And honestly, for the most part that's a fine thing to do. But if you want to be more than one of the silent users, if you want to help the projects you use just by using them, there are lots of ways to do it. You could become a vital part of pushing forward your favorite open source projects without ever altering a single line of code.

Ultimately, being a good open source citizen is about respecting what open source is, how it's made, and how you can help. Open source software is made by many; that's its beauty and its curse. If you can help bring more order to the naturally chaotic development process by adding documentation, fielding support requests or even just encouraging maintainers to keep going, you are becoming a vital part of the open source ecosystem and helping it to grow.

• Read more about GemNotifier Goes Open Source

In April, I announced GemNotifier, a new Intridea SparkTime project. GemNotifier is a web app I created to send notifications to users when the gems they subscribe to are updated.

Open Source Announcement

Today, I'm excited to announce that we are open sourcing GemNotifier. At Intridea, we have a long history of support for open source development, and we make every effort to open source tools and projects that can be of use to the greater development community.

The code for GemNotifier is hosted at Github. Anyone who might be interested in contributing to the project can fork it from Github and make pull requests. You can also submit any issues you encounter, using Github Issues.

Improvements

Before open sourcing GemNotifier, I took the feedback I received from users and made some key changes to the UI and overall functionality. The most requested feature was to be able to subscribe with Gemfile, which I added recently. GemNotifier also now has 100% test coverage and uses SASS.

What is GemNotifier?

If you missed the detailed post about GemNotifier in April, you can read it here. But for a quick rundown:

GemNotifier is a notification service that updates users when the gems they have subscribed to are updated. Rubyists can subscribe to their favorite gems (now using their Gemfile!) and they will get timely email notifications when those gems are updated. The service helps to keep you informed of changes and updates to the gems your projects are dependent on.

I'm looking forward to more feedback on the app from the community, so please share your thoughts below!

• Read more about RefactorMyCode Goes Open Source

Earlier this week we gave you some updates on the RefactorMyCode project that we took over from its creator, Marc-André Cournoyer this April. When we made the announcement that we were taking over RefactorMyCode.com, we let everyone know that we intended to open source the project eventually. That day has come!

The Great Open Sourcing

We planned to open source the project once we converted it to Rails 3 and made various other improvements. Thanks to the work of a few of our developers, notably Andy Wang and Paul Ostazeski, RFMC is now running on Rails 3, has significantly improved test coverage, and has undergone several rounds of refactoring.

The RFMC History

RefactorMyCode is a community for - you guessed it - refactoring code. Marc-André came up with the idea in 2007 when he became frustrated with the way Wordpress blogs handled formatting of the code and the comment structure. Since its creation, RFMC blew up on Reddit, Digg and other niche sites. When Marc-André put out a call for someone to take over management of the site we were thrilled to rise to the occasion. We had a small team of developers that jumped on the chance to work on RFMC as their SparkTime project, and they've been working diligently to get the code cleaned up and ready for open source.

We're excited to make RFMC available to developers to hack on. At Intridea, we believe strongly in the philosophy and culture of open source development (see our list of open source projects on Github). The repo is on our Intridea Github account, and we encourage contributors to make pull requests and submit issues using Github Issues. Of course, we're happy to answer any questions and get feedback on the project!

Happy coding!

• Read more about RefactorMyCode: Updates

A few years ago, I found RefactorMyCode.com by accident while searching for programming tips. I registered on the site right away because I liked the way it fostered sharing code with other programmers. It was a strong community that I wanted to be a part of.

Three months ago when I began my career at Intridea, I was prompted to select a SparkTime Project to work on in my spare time. At Intridea we are encouraged to work on interesting projects as often as we can. The SparkTime initiative allows us to organize our efforts and team up to accomplish things more efficiently. I was surprised when I found that RefactorMyCode was on the SparkTime list, so I signed up happily to help out.

About RefactorMyCode

One of my colleagues, Jon, talked about the RefactorMyCode project two months ago in a blog post. It was originally running on Rails 2.0.2, which was really out of date. Thus, I decided to upgrade it to Rails 3.0 before open-sourcing it.

What's new with RefactorMyCode in last few months?

Upgrading from Rails 2.0.2 to Rails 3.0 has been time consuming since there is a two year gap between the two versions. The main difficulties have been to fix routes and ajax related issues. In this situation the rails_upgrade plugin has really helped out.

In our case, it helped to cancel some of the ajax requests and refactor them as direct requests for more flexibility. We removed the old will_paginate and used kaminari as the new pagination solution. Similar updates included upgrading to acts-as-taggable-on and syntax highlight functions with coderay.

We also refactored the existing authentication solution with omniauth, so the new Rails 3 version will allow you to login to RefactorMyCode via more third party services, such as Github, Twitter and LinkedIn etc.

Is It Ready for open source?

The answer is, YES! Or, yes, almost!

However, I am still adding RSpec test code to the Rails 3 version and I am also on the hunt for a better (pure Ruby) syntax highlighting solution. So far it seems that Albino will end up working well for this. The project will be open sourced very soon (in the next 1-2 weeks), and we'll make an announcement about that here on our blog and our Twitter account. We are looking forward to involving the community in this project!

• Read more about RailsConf To Go: OmniAuth from the Ground Up

I had the opportunity to speak at RailsConf 2011 about OmniAuth, outlining some of the reasoning behind it as well as some current and upcoming features of Intridea's own "authenticate with anything" middleware. While the session wasn't video recorded, a little trick I've picked up is to run a screencasting program in the background while I present to generate a "poor man's Confreaks" version of the talk. Well, that's exactly what I've done for OmniAuth: From the Ground Up!

I'm also embedding the slides below for a "click-through" tour of the talk, but there were a few livecoding sections that are only represented in the video form.

I had a great time at my fourth RailsConf and I hope those who had a chance to attend enjoyed my talk. I also want to say thanks to all of OmniAuth's contributors, they've given me the ability to really ratchet up the awesome on the library and I couldn't have done it without them.

• Read more about You Should Be An Open Source Developer

This post is part of a series called Open Source Citizenry in which I discuss ways to eliminate the barriers that developers and companies face to participating in the open source community.

Last week at Red Dirt Ruby Conf, a tweet came through my stream that seemed to fit quite well with what I was already thinking about for my Open Source Citizenry post this week:

.bbpBox61459124273168384 {background:url(http://a2.twimg.com/a/1303316982/images/themes/theme3/bg.gif) #EDECE9;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}

There are still too many developers who work with Open Source and not enough Open Source developers.less than a minute ago via Echofon Favorite Retweet Reply Mike Perham
mperham

In last week's post I tried to give some insight as to why open source is important for companies. This week, I'll be looking at the other end of the spectrum: why should you, as a developer, actively contribute to open source? For some, the answer to this question feels natural; however, for many developers the idea of contributing to open source can be daunting, confusing, and somewhat frightening.

It Will Help You Land Your Next Job

Are you unsatisfied with your current job? If you are, it's a great reason to start contributing to open source. If you're stuck using a language or framework that you don't enjoy, or a development practice that you don't believe in, it's practically imperative that you begin contributing to open source. Why, you ask?

Because the person that is in charge of hiring at the kind of company you really want to work at is going to be looking at an applicant's open source contributions as a way to gauge talent. The more (good) open source you release, the closer you will be to getting your dream job before you've even had an interview.

Open source contributions are a fantastic way to evaluate incoming employees. The very first thing I do when I'm evaluating a potential hire at Intridea is look them up on GitHub. That's not to say that we don't hire people who haven't done much in the way of open source contribution (there's more to the hiring process than a single factor). However, I can say that I am going to be much more adamant in my arguments to hire a person if I can see the way their mind works from the open source projects they've released.

You Will Write Better Code

Open source is open to the entire world. Everyone can see what you're writing. If you think this doesn't have an effect on your willingness to take hacky shortcuts, you're very wrong. Not only does the mere fact that it's open source make you write your best code, but open source also helps you to think about your problem domain from a wider perspective.

As I released more and more open source projects, I began to have a kind of Spidey Sense for when something would make a good abstraction. When I'm architecting a project I'm already thinking about how certain pieces could be built in a modular way to maximize reusability. Even if these pieces don't end up getting released as open source they are still useful extractions that get used in other projects down the road. The concept of building code for a community instead of just for an application makes the work more enjoyable.

Reputation is Real

For a software developer there are essentially two paths to extremely enviable positions of respect in the community: either you can be the tech genius behind a multi-billion dollar startup or you can release open source projects that thousands (not millions) of developers find useful. Guess which one is easier to accomplish?

Reputation isn't just about vanity, either. Sure, it can feel good to have someone say "Oh cool, I've used X!" when they meet you, but building a reputation brings real benefits for you:

1. If you love your company, your company is automatically more respected because you're a part of it if you have a good reputation.
2. You'll get the chance to meet, talk to, and learn from the people that you respect. Not that these people are otherwise inaccessible, but having your own "known" libraries gives you some common ground to strike up conversations, get input, and become a better developer.
3. It will get you hired at awesome places. See above.
4. You will get help when you want it. If you have a good reputation and embark on a new project you'll be able to round up volunteers more quickly if you're a known entity.

It can occasionally feel shallow or awkward (at least to me) to be thinking about and concentrating on my reputation in the community. However, look at it another way: open source reputation is built on real, honest-to-goodness work that is making people's lives easier. And if you start releasing bad code, guess how long that reputation will stick around? Reputation is simply a measure of the respect that others have for you based on the merits of your code. And that's not a bad thing.

That Warm Fuzzy Feeling

It just plain feels good to contribute to open source. The rush you get the first time (as an example) your patch is accepted into a major open source project is exciting. Seeing people using and talking about a library that you wrote is awesome. Hearing that some company that you really admire is using one of your libraries internally is amazing.

Open source feels good because it is good. You are offering value to a community of people free of charge, and in return you get to feel good about yourself and enjoy what you're doing. Don't be afraid to pat yourself on the back (maybe not too hard) for getting code out there. It's more than most people do, and even if only ten developers ever find it useful, that's ten people that saved hours or days of work because of something you did. And that's a warm fuzzy feeling.

Standing on the Shoulders of 1,000,000 Dwarves

Open source is amazing because it doesn't rely on the herculean efforts of a single person or even a few people. Open source is about thousands of people contributing tiny useful things that thousands of other people can build upon. It's not about building the biggest boat, it's about making the entire ocean rise. Each and every person who contributes to open source is making a difference to the ecosystem as a whole, and the more people that get involved the better the whole system works together. There can never be too many open source developers.

Barriers to Contribution

I think it's relatively clear to most developers why open source contribution is a good thing. Additionally, I think there is something intrinsic to the developer's mindset that drives us to crave the scrutiny and the ups and downs of publicly available code. So why doesn't everyone write lots of open source? Here are a few reasons with my responses:

1. I'm not good enough to release open source. Poppycock! My first open source release was literally forking another project and hacking at it until it did something I wanted it to do that it didn't do before. I had no idea what I was doing. I still don't, most of the time, and I've released dozens of open source projects.
2. People will think I suck because my code sucks. Nope, people will ignore your project if your code sucks. That's the worst case scenario. And, to be honest, if you're solving a problem that other people haven't solved, they'll probably use your code even if it sucks. And then they'll patch it so it doesn't suck anymore. Wins all around.
3. How do I even do it? It seems complicated. It's not, especially in the GitHub era. If you want to know how to do something, find a project that does something similar and steal their execution. Just steal and steal from everyone until you understand it well enough to forge your own path.
4. I don't have enough time! Find a way to make time! Identify a piece of your existing app code that other people would find useful and extract it out. This cuts your open source time down to abstraction instead of creation. Work on open source for half an hour a day. Convince your company to sponsor some open source time for employees. Contribute small patches to the libraries that you use on a regular basis. Where there's a will, there's a way.

I could go into detail and examples on each of these points (please feel free to ask me sometime), but the point is that whatever you think is holding you back from contributing to open source, the reality is much less frightening. Your first project will be the hardest to get out the door, but it gets exponentially easier each time after that.

In coming articles in the series, I'll talk specifically about how to be a good open source user, how to be a good contributor, and how to be a good project owner. But if you only needed a tiny push to start getting involved, hopefully I was able to supply it. Please feel free to discuss anything related to open source contribution in the comments, I'd be happy to lend what knowledge I have to the service of getting everyone more involved!

Open Source Citizenry Series

1. Why Open Source Company Culture is Important
2. Why You Should Be An Open Source Developer

• Read more about Why Open Source Company Culture is Important

This post is part of a series called Open Source Citizenry discussing ways to eliminate barriers developers and companies face to participating in the open source community.

Earlier this month I had the opportunity to speak at KCRuby about a topic of my choosing. Rather than use the opportunity to put together a trial run of my upcoming Red Dirt Ruby talk, I decided at the last minute to talk about something that's been on my mind for a long time. While open source participation is higher than it's likely ever been, I still see so many people too hesitant, confused, or intimidated to enter the open source community and start releasing. So I wanted to give a cheerleader talk about how everyone can and should be contributing to open source. You can see the showoff slides here, but I think the issue is important enough to merit a larger discourse. This is the first post in a series in which I will be writing about how and why every developer should participate in the open source community. First up, I aim to supply developers everywhere with some ammunition to bring open source culture to their company.

Why Open Source Company Culture is Important

Companies have many ways to benefit from an open source culture. While many arguments can be made about the philosophical implications of choosing to contribute to the open source community, at the end of the day philosophy isn't going to persuade any CEO to adopt open source. The real reason that open source culture is important to a business is because it's a business decision that can bring many real-world advantages over the proprietary-focused alternatives.

Defining Open Source Culture

There are many degrees of "openness" in a company's culture, just as there is a whole spectrum of licensing that is considered "open source" but can have vastly different ramifications for downstream users. Personally, I believe that many companies would benefit from embracing open source as a core aspect of their corporate identity. To me, fully embracing open source means changing the default. Rather than building things and thinking "Should we open source it?" the assumption should be that yes, we will open source it unless there are compelling reasons to avoid doing so.

This is a big leap for a company to take, and I don't think many are there. We recently acquired RefactorMyCode, and rather than simply taking it over and continuing with it as a product we decided to additionally open source it. There aren't a ton of reasons why open sourcing would necessarily be a huge win for Intridea, but there are even fewer reasons why it wouldn't be a good idea. It's a community-oriented project, it doesn't contain any kind of magic voodoo patentable algorithm, and we can give the public the chance to refactor RefactorMyCode.

It Leads to Better Code

You may run a tight ship when it comes to code quality and you may even have excellent processes in place to ensure that the code that you deliver is well-tested and sanity-checked before it ever reaches production. However, there is simply no review process that can compare to the power of opening up source code to the world at large and letting them take a look. The code quality bump is due to two primary reasons:

1. Developers building things for open source know that anyone in the world can look at the code they're writing. It will make them less likely to take easy shortcuts at the expense of good code.
2. Other people will start using your code way off the golden path you imagined when you designed it. This will cause your architecture to evolve to be more flexible, useful, and hardened.

I know that in many cases I've had to rewrite large sections of a project because the community use cases have revealed a superior architecture that will encompass a broad range of functionality. I then benefit from this architecture when I need a similar solution in the next project I'm working on for my company.

You Get Work For Free

This is probably the most commonly cited advantage of open source: once you build a community, the community gives you free bug fixes and feature updates without you having to code a single line! This is a real advantage, especially when there is a wide-open field for community addition (such as adding new strategies to my OmniAuth library).

Of course, you need to have a workable community involvement process before you can really reap the benefits of contribution. Thanks largely to GitHub, this process has never been easier, but there are still some things to keep in mind that I'll cover in a later post.

Your Developers Will Be Happier

There's a real sense of accomplishment that comes from releasing and contributing to open source. It makes your developers feel like they're giving back, becoming a real member of the development community, and investing themselves more in the craft of software development. The same can be said of encouraging developers to attend local meetups relevant to the field and conferences.

Why do you care about happier developers? Well, every company should care about happy employees, but software development is a black magic mix of science, artistry, and craftsmanship. While some work can be done by "forcing it", a good deal of that work requires inspiration and passion, something you won't be getting out of developers that feel stifled and isolated from the development community at large.

You Will Attract Better Talent

If your company becomes known as one that embraces open source and community involvement, you will begin to attract better talent when it comes time to hire. Sure, having a killer product, good benefits, competitive pay, and many more things affect this strongly as well. But the chance to be involved in open source without having to do so by moonlighting is a chance that is very attractive to the kinds of developers you want to have working at your company.

Open source is synonymous with credibility for many developers. The more well known your company is for having great open source, the higher you rank amongst the development community. It really is that simple.

You Will Gain General Technical Credibility

This may be more applicable to service-oriented companies that do consulting, but in some cases your portfolio of open source projects can be the validation your company needs to win a bid for a client. Intridea has won clients before when they check with their technical expert and he or she confirms "hey, I've heard of that company, they released X".

All of these reasons come about because contributing to and participating in the open source community changes the perception of your company for developers, customers, and other businesses alike. While a company that rabidly protects every scrap of its software might be seen as greedy or, well, basically "jerks", companies that embrace open source foster a general sense of well-being about them that is difficult to define but something that I've definitely experienced personally.

The Flip Side: Addressing Arguments for Proprietary Software

So if, as a developer, you've just made your pitch to the higher-ups to embrace open source, you might receive any of these as (valid, by the way) concerns about being more "open" as a company.

1. But we're a software company, aren't we giving away our most valuable assets? Nope. Well, maybe if you have a completely novel complex algorithm that solves a problem in a game-changing way, but the truth is that most software isn't some "secret sauce" that can't be duplicated by competitors. On the contrary, even with high-level tools and environments at the end of the day a good deal of software development is re-inventing the wheel. The more everyone is involved in open source, the fewer wheels have to be re-invented.
2. We're on a deadline, we don't have time for open source. This can be one of the biggest challenges to overcome. I'm not going to lie, supporting open source projects does take time and effort. However, think of it as a tradeoff: by putting in some time and some effort to maintain an open source project, you are gaining all of the free hours of community contribution.
3. What if people look at the code and think it's awful? Well, then you're learning a valuable lesson about the code quality you're producing and you'll probably be able to identify ways to improve it. Open source projects without tests, with brittle "golden-path" architectures, and even well-intentioned projects that are simply tackling a tough domain are probably going to get some flak. But being wrong isn't nearly as damaging to your company as being ignorant of the practices that you should be using every day.

This post (and this blog series) is more about starting a discussion than providing definitive answers. I'm not saying I know exactly what your company's needs are, but I do believe that embracing open source will do more good than harm. If you have any questions, comments, or rotten produce to throw, feel free to start some discussion below. Stay tuned for the next post in the series where I'll be talking about the benefits to individuals in contributing to open source. And if you're interested in checking out some of the open source work that Intridea has done, hit our Github page.

1. Why Open Source Company Culture is Important
2. Why You Should Be An Open Source Developer

• Read more about RefactorMyCode Lives on... with an Open Source Version Coming Soon!

We’re excited to announce that we are now the proud owners of RefactorMyCode.com. That’s not all, though; we’re also open sourcing the code behind RefactorMyCode! In February, creator Marc-André Cournoyer put out a call for someone to take over management of the site - we answered and now RefactorMyCode is live on Intridea servers.

A Little Background on RefactorMyCode

Refactormycode.com was greeted with enthusiasm by the programming community when it launched in 2007. Too much enthusiasm in fact - the load of over 100,000 visitors from Reddit, Digg and other sites quickly took RefactorMyCode down. It was a good problem to have, though, and a validation for Marc-André Cournoyer that it wasn’t just him and his friends who needed such a tool. He quickly brought the site back up and the people who continued to come back formed the community that still exists today.

How Marc-André Cournoyer Came up with the Idea

Marc-André, a Montreal based programmer, came up with the idea after noticing his friends and other programmers sharing code on their Wordpress blogs. Readers would then offer their code refactoring in the comments. Wordpress was a poor platform for this - code syntax was crudely formatted and tracking the different solutions posted in the comments was messy. So, Marc-André set out to create a site that loosely followed a blog format, but with properly formatted syntax and a much smoother commenting and sharing process.

Open Sourcing RefactorMyCode

Part of our taking over RefactorMyCode involves open sourcing the site. Once we are done running through the code, we will post the open source version on the Intridea Github account. We expect to have that done by the end of the week; we'll announce it on our twitter account when we do.

If you’ve never visited RefactorMyCode, take a look. Please let us know if you have any questions. A big thanks to Marc-Andre for giving us this opportunity - we're looking forward to the future with RefactorMyCode.

• Read more about RailsWizard Reimagined

TL;DR: I've rewritten RailsWizard from the ground up to be as fast and useful to developers as possible. You can now also run it through the command line with the RailsWizard Gem.

Last year for the RailsRumble I built a tool for Rails developers called RailsWizard.

RailsWizard allowed people to build a Rails 3 application template step by step, removing a lot of the tedious and repetetive setup that comes with building a new application. However, there were a few problems:

1. There was no way for the recipes to get updated by the community. This was a hoped-for feature but one that didn't have time to come to fruition within the confines of the contest.
2. I didn't love the design of the thing.
3. There was too much overhead to creating a recipe. There were multiple pages with multiple steps and it was all too complicated.

RailsWizard v2

So a short time after the rumble I decided to tackle the problems I saw with the site and built RailsWizard v2. This version was all on one page (a major improvement) and featured a dark, gradient-heavy design with some relatively slick "big click target" radio selectors and such.

When it was first released it still didn't address the community recipe problem (recipes for v1 and v2 were stored in MongoDB so not accessible from the git repo), but still seemed to be an improvement. Push it out, job well done, all that business.

But as time went on I still found myself very dissatisfied. So I added a community-submitted recipes feature via GitHub login that put things into a moderation queue (can't have arbitrary code running unchecked on your system). But I'm not even sure it ever worked, because no one seemed to pick up on the recipe submission process. I considered this to be mostly a failure.

Today: RailsWizard v3

Here is RailsWizard as it stands today:

I found myself coming upon a weekend with few to no plans and I decided to finally go for the gusto and build the tool I'd always wanted to have in the first place. My focuses for the rewrite were:

1. Fast
2. Configurable
3. Git-backed Recipes
4. A command line version of the wizard

For the interface, I wanted everything to be as fast as possible. Remove as many options as possible to make it the simplest thing that can possibly work. I wanted there to be configuration options for recipes, thinking of the needs for API keys or choices of database for ActiveRecord. I wanted everything to be stored in Git so that anyone could fork, add a recipe, and get it added via pull request. And I wanted to be able to run the wizard from the command line. RailsWizard v3, now public, allows you to do all of these things!

User Interface

I was inspired by (and used) the Isotope library to make filtering through recipes as fast as possible. Recipes, I decided, would be grouped into categories and would also have "exclusivity" in that if you select MongoMapper as your ORM ActiveRecord would automatically become unavilable. I wanted the whole thing to take less than a minute to completely choose all the recipes and generate your template.

Git-Backed Recipes

This took some real thought. I wanted git-backed recipes, but how was I going to store the metadata associated with them? Also, even though recipes would be Ruby code, they would not actually be needed as executable code in RailsWizard itself, only as text. However, I still wanted them to be as accessible and readable as Ruby code as possible. This is when I decided to get a little bit clever.

I wanted to borrow from Sinatra's clever "in-file template" system to allow for "in-file metadata" for each recipe. I found this blog post that walked through how to read the data afer __END__ in a Ruby file. I didn't find out until later that this only worked for the file that was being executed and could not really be used in a library setting (whoops!).

Undaunted, I decided on a new strategy: I would simply read in the strategy files as if they were text files, and split on the __END__ statement. Before the __END__ statement would be the code that would be executed for the recipe and after would be some YAML metadata "back-matter". This actually worked out incredibly well and made it easy and readable to develop new recipes. You can find out more about this part of the library on the wiki. I now feel that it is exceedingly easy for a person to write custom recipes and contribute them back to the RailsWizard Core.

Configuration

It will often be necessary/convenient for recipes to ask for some configuration information about themselves. For instance, if you're using Hoptoad, you might need an API (or know to install the Heroku) addon. I decided to put together a robust question-driven configuration system that would be as easy as adding something like this to the YAML back-matter:

config:   - key_name:       prompt: What is your favorite color?       type: string 

This allows recipe authors to get configuration details in a consistent manner without having to do the heavy lifting themselves. Again, more information about this aspect of RailsWizard is available on the wiki.

Command Line RailsWizard

This for me was the "holy grail" of my goals for RailsWizard. What if, when you wanted to build a new project, it was as simple to run RailsWizard as it was to run rails new. Now that's possible:

$ gem install rails_wizard $ rails_wizard new APP_NAME 

This will automatically let you type in desired recipes and build a template using the exact same code that drives the web version. It's all one library so they will be kept easily in sync. This, for me, is a big deal.

Endgame

All of this comes together to build a framework that I hope the community can really expand upon. I would love to see dozens of user-submitted recipes for every library imaginable. As the recipe collection grows there may be new challenges and features needed to support them all, but I believe that RailsWizard now has the proper foundation to encourage such growth.

If you're a Rails developer and find yourself frequently creating new Rails projects for experimentation, research, prototyping, or even if you only do it once in a while, RailsWizard can save you hours of initial setup and configuration time. It's all designed to work together seamlessly and without any complex requirements on you as a developer.

For developers who have built their own custom templates before, please try to break them down into RailsWizard recipes! If you look at the codebase you'll see how easy it is to build them. So what are you waiting for, get forking already!

Edit: One thing that I wanted to make note of is that for this iteration I focused on fast as the motivating factor for the web UI. This means that, as it stands now, RailsWizard is much more friendly for advanced Rails developers looking to speed up the project kick-off process than it is for beginning Rails developers looking for more explanation and help along the way. One of my future goals will be to provide interfaces to make it a great experience for both!