Why we don't use a Rails template(thunderboltlabs.com)
thunderboltlabs.com
Why we don't use a Rails template
http://thunderboltlabs.com/posts/why-we-dont-use-a-rails-template
9 comments
I think, essentially, he is saying that you end up spending time maintaining your template, losing much of the benefit of the template, depending on how often you start new apps. I have found this to be true at a certain threshold of complication in the app template. However, if you are indeed starting a brand new Rails app every month, as you said, you likely don't have the same cost, as maintenance to the app template happens on a more regular basis. Even as a consultant, I don't start new Rails apps that often, and side projects tend to involve experimentation outside of what I might consider my "stable" stack.
> you end up spending time maintaining your template, losing much of the benefit of the template
It really depends on whether or not you start a lot of new projects. If you're a Rails dev shop that does a wide variety of apps on a regular basis, then the N=1 cost of maintaining the template is well worth the per-project getting-started cost.
It really depends on whether or not you start a lot of new projects. If you're a Rails dev shop that does a wide variety of apps on a regular basis, then the N=1 cost of maintaining the template is well worth the per-project getting-started cost.
I find it extremely useful to have a base foundation to start an app. Doing all of the mundane gem integrations and standard set-up is not fun. I agree that it's a challenge to keep the base app updated with improvements from the forks. I have repo on github that could benefit from some cherry-picking. It's great for working on multiple projects at the same time. You never have to go digging to see how the basics work, you just know. On top of that, my clients save at least a few days of work.
I never liked Rails templates because I felt the quality of the final product was never on par with what you would setup from scratch. To that end, I created my own system that I call a Rails application prototype. If you are interested you can learn more about it here.
https://github.com/metaskills/holy_grail_harness
I can see both sides of the argument here. My application prototype is really slim and focuses on bootstrapping an application with a major emphasis on testing tools. Even tho it has a JavaScript MVC framework (Spine.JS) it will remove all traces depending on your setup questions. This approach to a lean prototype means it can easily be updated like a normal Rails application and changed/forked as needed. Best of both worlds hopefully.
https://github.com/metaskills/holy_grail_harness
I can see both sides of the argument here. My application prototype is really slim and focuses on bootstrapping an application with a major emphasis on testing tools. Even tho it has a JavaScript MVC framework (Spine.JS) it will remove all traces depending on your setup questions. This approach to a lean prototype means it can easily be updated like a normal Rails application and changed/forked as needed. Best of both worlds hopefully.
This project from @metaskills is worth a close look, particularly to see the choices Ken's made in assembling a development stack. It's a great example of using a starter app as beginning point for a discussion about best practices. Carbon Five's RayGun is another. Compare the two and you'll learn a lot about high-powered Rails development and where it's going.
Plus, if you're new, templates are dangerous. The excitement of saving all that time on 'boilerplate' always turns into twelve hours of flailing around on StackOverflow, totally over your head, for the right way to override some Devise controller -- all because you wanted to save some time.
This post makes some good points about whether or not spending time working on rails templates for the use of your team will pay off. But if you're just using a template that someone else created -- RailsApps, by Daniel Kehoe, for example -- then there's no time lost to you or your team.
I also think that a great use case for templates is to try out new gems before deciding on whether or not you'd like to use them.
I also think that a great use case for templates is to try out new gems before deciding on whether or not you'd like to use them.
The larger point is more about the philosophy of using a template, and the impact on the culture of the team.
"Congratulations! You've now started your brand new project with technical debt."
Love it.
The tl;dr here is that almost all of the decisions that an app template makes are decisions the team should be discussing. Otherwise, the homogeny of an app template creates a "you're doing it wrong" cargo-culting attitude.
Great post. Glad I read this.
Love it.
The tl;dr here is that almost all of the decisions that an app template makes are decisions the team should be discussing. Otherwise, the homogeny of an app template creates a "you're doing it wrong" cargo-culting attitude.
Great post. Glad I read this.
I think this might work both ways though. I think that generating an app from a template allows the team to get up to speed quicker on particular gems, and thus might enable a better decision about whether or not to use those gems -- whether they use that gem in a generated app or build it from rails new.
What is a "Rails template"?
A rails template is what railway construction workers use when laying track. It’s a 2 feet wide rig with a place to put the lumber and iron pieces.
It's where you store all of your Ruby and Rails security vulnerabilities.
It's a place where well-crafted pieces of code are revered. Sometimes social gatherings are held there to discuss the ways in which these things were put together.
Err, that's a Rails Temple, sorry.
Err, that's a Rails Temple, sorry.
The problem with app templates is, how often do you start a new app vs. how often do you want to maintain every change you made to your base app template? Article pretty much nails it.
Many consulting companies and freelancers spin up projects on a regular basis. My experience working in an environment like that was that having an in-house generator saved time in the long run. Same goes for developers who spin up lots of personal projects whenever they have a new idea.
I maintain the RailsApps ecosystem, which includes a gem that assembles various application templates (rails_apps_composer, derived from Michael Bleigh's RailsWizard), Rails Composer (an application template that generates various starter apps), the RailsApps collection of example applications, and a collection of tutorials that explain how each example application works.
The OP argues against using a "Rails template" but ultimately his argument is against using a starter app to begin a Rails project. His concerns are reasonable but ultimately shortsighted.
You see, everyone uses a starter app. Here's your choices:
1) Use "rails new" to get the default Rails starter app. Add your favorite gems and tweak everything to work together.
2) Build a starter app with you favorite gems, store it in a repo, and make a copy every time you start a new project (search and replace to change the app name in ten locations).
3) Build a gem that copies a starter app with all your favorite gems. Build in a search-and-replace script that changes the app name.
4) Build an application template that generates a starter app using "rails new -m".
#2 is faster than #1 for starting up a project (except for a little time to copy the starter app to a repo) if you are using the same starter app more than once.
#3 and #4 are faster that #1 and #2 for starting up a project but more time is required to "build the tool." Fine if you can save more time running the tool than hand-assembling as in choice #1.
But there's a problem with #1, #2, #3, #4. All starter apps are time consuming because you need to take time to figure out what's changed since you last used your favorite gems and hunt down any new tweaks needed to get your favorite gems to work together. Most developers underestimate this effort and and most starter apps, application-generating gems, or application templates end up mired in the tar pits of neglect, abandoned in the constant change of Rails and its gem ecosystem.
There's another choice:
5) Participate in an open source project to maintain a set of starter apps with commonly used gems. Since you are always going to use a starter app (of some kind), why not use one that other developers are using? And benefit from a community effort to identify and patch integration issues.
That seems to be what's driving the popularity of the RailsApps project (800+ "stars" and 150+ forks on GitHub for the rails_apps_composer gem). Here's the link:
https://github.com/RailsApps
Now about what the OP said:
"Even after the first implementation, the template must be constantly tweaked and finagled to keep it up to date."
Yep, that's where you need the leverage of a community supporting an open source project.
"Each one of the decisions that the template makes for you should be discussions within the team."
There's no reason to have a single starter app or template that generates only one stack. Take a look at the RailsApps repo. You'll find starter apps that use MongoDB, others use SQL. The Rails Composer application template will give you a choice of ERB/Haml/Slim, Twitter Bootstrap or Zurb Foundation, PostgreSQL/MySQL/MongoDB, RSpec/MiniTest, OmniAuth/Devise, etc., etc. Have your team discussion; find out what the larger community is saying; make informed choices. You can have multiple starter apps and choose the one that is appropriate for the project at hand.
"The fact is, 'best practices' are a moving target. They evolve through team communication and cohesion."
Yep, and if your team participates in an open source project to build and maintain useful starter apps, you'll benefit from the efforts of a larger community and contribute to the growth and wider adoption of Rails.
The OP argues against using a "Rails template" but ultimately his argument is against using a starter app to begin a Rails project. His concerns are reasonable but ultimately shortsighted.
You see, everyone uses a starter app. Here's your choices:
1) Use "rails new" to get the default Rails starter app. Add your favorite gems and tweak everything to work together.
2) Build a starter app with you favorite gems, store it in a repo, and make a copy every time you start a new project (search and replace to change the app name in ten locations).
3) Build a gem that copies a starter app with all your favorite gems. Build in a search-and-replace script that changes the app name.
4) Build an application template that generates a starter app using "rails new -m".
#2 is faster than #1 for starting up a project (except for a little time to copy the starter app to a repo) if you are using the same starter app more than once.
#3 and #4 are faster that #1 and #2 for starting up a project but more time is required to "build the tool." Fine if you can save more time running the tool than hand-assembling as in choice #1.
But there's a problem with #1, #2, #3, #4. All starter apps are time consuming because you need to take time to figure out what's changed since you last used your favorite gems and hunt down any new tweaks needed to get your favorite gems to work together. Most developers underestimate this effort and and most starter apps, application-generating gems, or application templates end up mired in the tar pits of neglect, abandoned in the constant change of Rails and its gem ecosystem.
There's another choice:
5) Participate in an open source project to maintain a set of starter apps with commonly used gems. Since you are always going to use a starter app (of some kind), why not use one that other developers are using? And benefit from a community effort to identify and patch integration issues.
That seems to be what's driving the popularity of the RailsApps project (800+ "stars" and 150+ forks on GitHub for the rails_apps_composer gem). Here's the link:
https://github.com/RailsApps
Now about what the OP said:
"Even after the first implementation, the template must be constantly tweaked and finagled to keep it up to date."
Yep, that's where you need the leverage of a community supporting an open source project.
"Each one of the decisions that the template makes for you should be discussions within the team."
There's no reason to have a single starter app or template that generates only one stack. Take a look at the RailsApps repo. You'll find starter apps that use MongoDB, others use SQL. The Rails Composer application template will give you a choice of ERB/Haml/Slim, Twitter Bootstrap or Zurb Foundation, PostgreSQL/MySQL/MongoDB, RSpec/MiniTest, OmniAuth/Devise, etc., etc. Have your team discussion; find out what the larger community is saying; make informed choices. You can have multiple starter apps and choose the one that is appropriate for the project at hand.
"The fact is, 'best practices' are a moving target. They evolve through team communication and cohesion."
Yep, and if your team participates in an open source project to build and maintain useful starter apps, you'll benefit from the efforts of a larger community and contribute to the growth and wider adoption of Rails.
I fully agree with Daniel on this one. For a long time, I was looking for an app generator. I looked at many, and Rails App Composer (and the many RailsApps templates that come with the generator) is by and far the best thing I have come across.
I love being able to always know that when I want to create a new app, I have my core gems - that will always be up-to-date once I run the RailsApps generator.
One of the best tools in my toolbox as a Rails dev.
Thanks Daniel for all your awesome work.
I love being able to always know that when I want to create a new app, I have my core gems - that will always be up-to-date once I run the RailsApps generator.
One of the best tools in my toolbox as a Rails dev.
Thanks Daniel for all your awesome work.
I agree with the other commenters - RailsApps is a fantastic resource for the community. It's a great way to have a peer reviewed and curated set of high quality examples to learn from.
At the same time, I do agree with many of the points in Tammer's article. I think the danger with Rails templates, scaffolding and even Daniel's work is that it's very easy to take it and use it part and parcel without understanding what's really going on inside, and why certain decisions were made (this gem vs. that gem, or this code technique vs. that). I think there's a lot of value in starting from scratch (Daniel's option #1) and adding things step by step. As Tammer pointed out, this can lead to a positive team discussion and learning dynamic. And I don't mind the extra typing and time required.
The next time I start a new Rails app, I'll probably: - Look for a good example to learn from in RailsApps or elsewhere. - But then step back to "rails new" and add in the recommended gems bit by bit, with testing along the way. - Hopefully contribute back to RailsApp if I learn anything new :)
At the same time, I do agree with many of the points in Tammer's article. I think the danger with Rails templates, scaffolding and even Daniel's work is that it's very easy to take it and use it part and parcel without understanding what's really going on inside, and why certain decisions were made (this gem vs. that gem, or this code technique vs. that). I think there's a lot of value in starting from scratch (Daniel's option #1) and adding things step by step. As Tammer pointed out, this can lead to a positive team discussion and learning dynamic. And I don't mind the extra typing and time required.
The next time I start a new Rails app, I'll probably: - Look for a good example to learn from in RailsApps or elsewhere. - But then step back to "rails new" and add in the recommended gems bit by bit, with testing along the way. - Hopefully contribute back to RailsApp if I learn anything new :)
I really hope people will look at RailsApps as a result of this post. It looks like the author may have missed it. I can say that the RailsApps templates have been enormously valuable to me both a) as a way to try out new gems quickly and b) get started on production apps.
No, it's not. Manual effort is being automated. That manual effort includes calling to remembrance a list of gems, looking up their installation instructions on GitHub, modifying views, editing initializers, converting ERB files to Haml, setting up your test environment just so, and whatever else floats your boat. Assuming a team can agree on some sensible defaults, it can save significant amounts of time to have all those steps automated each time you want to spin up a new project.
"The technical and social friction in changing the template discourages evolution."
No, it doesn't. There is nothing stopping me from deviating from the norm once the application is generated. Or if I need to preempt a step in the generator, I just 'gem unpack' the generator, make my tweak, 'rake install', and generate from that. If it works out, I can push the change up in a branch and submit a pull request. The team can discuss.
Automation is good. From a business perspective I believe it's codifying your expertise. Clients benefit from that automation, because you spend 10 minutes spinning up their project instead of 2-8 hours recreating pretty much the same wheel you created last month.