9 ms·

Why we don't use a Rails template

27 points by ajsharp 14y ago

programminggeek 14y ago
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.
- aculver 14y ago
  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.
gyardley 14y ago
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.
aculver 14y ago
"But take a closer look, and you'll see that the time is simply being moved around." 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.
- mileszs 14y ago
  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.
  - snprbob86 14y ago
    > 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.
Mc_Big_G 14y ago
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.
ajsharp 14y ago
"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.
- fdschoeneman 14y ago
  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.
fdschoeneman 14y ago
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.
- thunderboltlabs 14y ago
  The larger point is more about the philosophy of using a template, and the impact on the culture of the team.
- tsaleh1 14y ago
  The larger point is more about the philosophy of using a template, and the impact on the culture of the team.
tenderlove 14y ago
What is a "Rails template"?
- bascule 14y ago
  I think it's like ERb or Haml
  - tsaleh1 14y ago
    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.
- thunderboltlabs 14y ago
  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.
- Happymrdave 14y ago
  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.
- caleb_land 14y ago
  It's where you store all of your Ruby and Rails security vulnerabilities.
metaskills 14y ago
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 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.
- DanielKehoe 14y ago
  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.
DanielKehoe 14y ago
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 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.

27 points by ajsharp 14y ago

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.

aculver 14y ago
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.

gyardley 14y ago

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.

aculver 14y ago

"But take a closer look, and you'll see that the time is simply being moved around." 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.

mileszs 14y ago
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.
- snprbob86 14y ago
  > 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.

Mc_Big_G 14y ago

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.

ajsharp 14y ago

"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.

fdschoeneman 14y ago
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.

fdschoeneman 14y ago

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.

thunderboltlabs 14y ago
The larger point is more about the philosophy of using a template, and the impact on the culture of the team.
tsaleh1 14y ago
The larger point is more about the philosophy of using a template, and the impact on the culture of the team.

tenderlove 14y ago

What is a "Rails template"?

bascule 14y ago
I think it's like ERb or Haml
- tsaleh1 14y ago
  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.
thunderboltlabs 14y ago
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.
Happymrdave 14y ago
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.
caleb_land 14y ago
It's where you store all of your Ruby and Rails security vulnerabilities.

metaskills 14y ago

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 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.

DanielKehoe 14y ago
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.

DanielKehoe 14y ago

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 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.