Looks great. There also is https://github.com/RailsApps/rails-composer which seems to be a little more modular in what it sets the app up with. It had a Rails 5.1 upgrade Kickstarter a while back, but I'm not sure what came out of that. The project looks a little abandoned.
I'll be honest, I use it a lot if I want to spin up a new Rails application and go through a quick CLI picking databases/auth approaches/test frameworks.
The only other tool I would consider looking at for this is Thoughtbot's Suspenders but at this moment I have no pain points with rails-composer.
In case I'm not the only one who likes to use it, I've added it to CodeTriage just now in case anyone would like to be involved in supporting this project. https://www.codetriage.com/railsapps/rails-composer
> minimize the time spent writing boilerplate code and performing repetitive setup tasks.
The problem with this is that everyone likes his configuration be in certain way. So in the end we have 100s of theses kinds of "boilerplate" starting apps.
Perhaps, or perhaps enough developers adopt a given project that it becomes a viable platform. I'm thinking of DropWizard, which is mostly an opinionated collection of libraries and which has a large impact. (Or at least it did... been a while since I've done Java.)
One problem I often find myself facing w/Python is that the ecosystem is so large that it's hard to keep up with the vast numbers of libraries. I have a list of a dozen or so in my head that for a large enough project I'd probably want to use. But personally keeping that list fresh is non-trivial. That, and of course, newer devs in an ecosystem don't have one.
I think these sorts of projects speak to that need.
Now, obviously as you suggest, people have differing needs/preferences, so there's room for competing visions, and in some cases this can become a sort of "now we have N+1 problems" meta-problem. But I don't think the fundamental impetus is misguided.
I typically search for "awesome $languagename" to get a list of curated libraries that people use and are stable. It's a decent shortcut to find what's good.
I understand where you're coming from. To be honest, I built that as a base for my applications and, for the reason you said, wondered whether is was worth sharing. I decided to share it just in case it's useful for people who have similar taste in tools and configurations. And apparently, it was helpful to some people, as the repo got 100+ stars in a couple of hours.
> So in the end we have 100s of theses kinds of "boilerplate" starting apps.
There's nothing wrong with this at all. Any time I want to get up and running with a new stack, I look around for a boilerplate. I choose the one which has the easiest-looking learning curve and just start trying to solve problems with it.
If it works well and requires a minimum amount of customization, I just put my customizations into a personal repo. Hopefully it's useful, a lot of the times it gets outdated.
Boilerplates are a nice thing to have in an era of constantly-improving software. Not having to do everything yourself is awesome.
> There's nothing wrong with this at all. Any time I want to get up and running with a new stack, I look around for a boilerplate.
How long do you spend looking for a boilerplate?
> I choose the one which has the easiest-looking learning curve and just start trying to solve problems with it.
How do you know without spending time trying it out?
> If it works well and requires a minimum amount of customization
Again, how do you know without using it?
> Boilerplates are a nice thing to have in an era of constantly-improving software. Not having to do everything yourself is awesome.
I agree completely about not having to do everything yourself. However, I have never have had a good experience with a boilerplate. It's usually missing something crucial where I end up spending a lot of time anyway.
Also, the boilerplate makes some assumptions that have to roll back to get the crucial thing to work so I end up re-implementing some things anyway.
So I can either throw it away and admit I pretty much wasted time and try another one, or I can just keep building on the boilerplate that doesn't actually solve my problems. Or I could have just started from scratch. It's a hard problem.
I only take a few minutes to actually find something. I ascertain them by looking at the technologies and the documentation. I don't know whether it actually works well without using it. But looking at the components and docs gives a good hint.
I usually look at what I'm trying to do pretty carefully before even looking for a boilerplate. I've usually been thinking about one of these excursions for quite some time before it's time to code.
I don't expect boilerplates to actually solve problems. Just to provide a base for me to solve the problem on.
Additionally, it's not exactly ideal to have to start with a bunch of boilerplate. If something changes in the template, you have to manually port that to every project using that template.
This is really the sort of thing that gems are designed to accomplish. The only boilerplate should be the Gemfile and maybe some configuration files; all the other shared functionality should be packaged up and distributed as versioned gems listed in that Gemfile.
If Rails in this day and age is somehow an obstacle to that (e.g. because it insists upon an excess of setup tasks that can't be encapsulated as a gem that provides a rake task), then it might be high time to consider an alternative.
For what I've seen, whereas Node projects tend to the fragmentation, Rails projects usually tend to the convergence. For each problem, there tend to be one, or maybe two, widely accepted solution and developer tend to maintain existing solutions, rather than forking or starting a new one from scratch.
Coming to Django, if you want to do auth via email instead of username, you are out of batteries. I say this criticism as a fan of both Django and Rails.
Edit: problem is that when starting a new project people often miss those 20 loc - as well as not noticing the documented best practices for accessing the user...
yeah, but i think by mentioning 'batteries' it means __no__ code is needed, simply a change in a config setting / changing a string to say.. 'username'-> 'email' somewhere.
It looks better than most attempts I've seen, but there is an actual pedantically standards-compliant regex. I think it's somewhere on Stack Overflow, and its character count has five digits.
In terms of standards, there's not a whole lot you can do beyond validate the domain if it includes one. You can take the HTML5 approach (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...), but that means leaving out at least theoretically valid email addresses.
Huh? RFC 2822 describes in detail what a valid email address looks like. (There might be newer ones superseding it; that's the one that was current back when I looked into this topic.)
In practice, a lot of theoretically valid email addresses are rejected by implementations, e.g. my favorite:
"@"@example.com
What's true, of course, is that you should never rely on an email address being syntactically correct. You should only use it after having done a validation process that involves sending mail to that address.
I agree with everything you're saying (though my favorite is probably addresses containing newlines). My point is just that in practice it's not terribly useful, e.g. why HTML5 defines its own: https://html.spec.whatwg.org/multipage/input.html#valid-e-ma....
I have something like this for my own projects, and my favorite piece is having detailed tests that I don't have to re-write every time: tests for Devise, tests for Stripe subscriptions, tests for many-to-many users and accounts, etc. I see this project has the same, which I really like.
I don't know why Devise doesn't have a generator to write all those tests for you, just like it will give you some starting views. Of course they won't match your app perfectly, but having the failures is helpful too, and probably it would be less effort to adjust them than to write new ones from scratch.
The idea isn't to "test the library"---Devise should have its own internal tests too---but to make sure that the features work as expected with your own configuration and customizations.
The other gem where a free battery of tests would really save time is Spree. (Maybe that exists; I don't know yet.)
Great concept. I've never understood why there weren't pre-configured SaaS-based Rails templates out there. Thank you for your contribution to the community!
Yes, it could. I might eventually do that, but currently the project has a narrower scope in the sense that it is meant to have a set of preselected defaults.
Rails is productive out of the box. The author has different preferences for some defaults and some plugins that require config. This is common for a consultancy to have a project like this so their rails apps are consistent around non-default add-ons and preferences.
It would be cool if you could
have a command line feature where we could select what packages we want to use and also add details about the app. Rails composer is pretty interesting too and it has this feature. https://github.com/RailsApps/rails-composer
> Base or "skeleton" application for Ruby on Rails 5.1 projects. Built to minimize the time spent writing boilerplate code and performing repetitive setup tasks.
Wasn't Rails 1.0 invented to solve this exact problem? A decade later and after 5 versions we are here?
Rails out of the box is ready to build a production ready project. These are for when developer preferences diverge from the out of the box rails defaults. I love RSpec and I always set that up when I start a new Rails/Ruby project. If you do consulting work, you definitely make new apps frequently and having your favorite things ready to go is a plus. Thoughtbot has a project called suspenders that includes their preferences for new apps.
40 comments
[ 269 ms ] story [ 2011 ms ] threadI'll be honest, I use it a lot if I want to spin up a new Rails application and go through a quick CLI picking databases/auth approaches/test frameworks.
The only other tool I would consider looking at for this is Thoughtbot's Suspenders but at this moment I have no pain points with rails-composer.
In case I'm not the only one who likes to use it, I've added it to CodeTriage just now in case anyone would like to be involved in supporting this project. https://www.codetriage.com/railsapps/rails-composer
The problem with this is that everyone likes his configuration be in certain way. So in the end we have 100s of theses kinds of "boilerplate" starting apps.
I personally don't see value in them at all.
One problem I often find myself facing w/Python is that the ecosystem is so large that it's hard to keep up with the vast numbers of libraries. I have a list of a dozen or so in my head that for a large enough project I'd probably want to use. But personally keeping that list fresh is non-trivial. That, and of course, newer devs in an ecosystem don't have one.
I think these sorts of projects speak to that need.
Now, obviously as you suggest, people have differing needs/preferences, so there's room for competing visions, and in some cases this can become a sort of "now we have N+1 problems" meta-problem. But I don't think the fundamental impetus is misguided.
I know this because I have at least one project on the "awesome Elixir" list that is absolute rubbish :)
There's nothing wrong with this at all. Any time I want to get up and running with a new stack, I look around for a boilerplate. I choose the one which has the easiest-looking learning curve and just start trying to solve problems with it.
If it works well and requires a minimum amount of customization, I just put my customizations into a personal repo. Hopefully it's useful, a lot of the times it gets outdated.
Boilerplates are a nice thing to have in an era of constantly-improving software. Not having to do everything yourself is awesome.
How long do you spend looking for a boilerplate?
> I choose the one which has the easiest-looking learning curve and just start trying to solve problems with it.
How do you know without spending time trying it out?
> If it works well and requires a minimum amount of customization
Again, how do you know without using it?
> Boilerplates are a nice thing to have in an era of constantly-improving software. Not having to do everything yourself is awesome.
I agree completely about not having to do everything yourself. However, I have never have had a good experience with a boilerplate. It's usually missing something crucial where I end up spending a lot of time anyway.
Also, the boilerplate makes some assumptions that have to roll back to get the crucial thing to work so I end up re-implementing some things anyway.
So I can either throw it away and admit I pretty much wasted time and try another one, or I can just keep building on the boilerplate that doesn't actually solve my problems. Or I could have just started from scratch. It's a hard problem.
I usually look at what I'm trying to do pretty carefully before even looking for a boilerplate. I've usually been thinking about one of these excursions for quite some time before it's time to code.
I don't expect boilerplates to actually solve problems. Just to provide a base for me to solve the problem on.
This is really the sort of thing that gems are designed to accomplish. The only boilerplate should be the Gemfile and maybe some configuration files; all the other shared functionality should be packaged up and distributed as versioned gems listed in that Gemfile.
If Rails in this day and age is somehow an obstacle to that (e.g. because it insists upon an excess of setup tasks that can't be encapsulated as a gem that provides a rake task), then it might be high time to consider an alternative.
I will definitely use this!
Edit: problem is that when starting a new project people often miss those 20 loc - as well as not noticing the documented best practices for accessing the user...
i was astounded how much manual code is needed: http://jeffthomas.xyz/many-to-many-relationships-in-rails
I don't believe such a thing exists.
In terms of standards, there's not a whole lot you can do beyond validate the domain if it includes one. You can take the HTML5 approach (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...), but that means leaving out at least theoretically valid email addresses.
In practice, a lot of theoretically valid email addresses are rejected by implementations, e.g. my favorite:
What's true, of course, is that you should never rely on an email address being syntactically correct. You should only use it after having done a validation process that involves sending mail to that address.Feedback welcome. I'm the contact person for the gem.
I have something like this for my own projects, and my favorite piece is having detailed tests that I don't have to re-write every time: tests for Devise, tests for Stripe subscriptions, tests for many-to-many users and accounts, etc. I see this project has the same, which I really like.
I don't know why Devise doesn't have a generator to write all those tests for you, just like it will give you some starting views. Of course they won't match your app perfectly, but having the failures is helpful too, and probably it would be less effort to adjust them than to write new ones from scratch.
The idea isn't to "test the library"---Devise should have its own internal tests too---but to make sure that the features work as expected with your own configuration and customizations.
The other gem where a free battery of tests would really save time is Spree. (Maybe that exists; I don't know yet.)
More details here: https://github.com/lewagon/rails-templates
I never used Rails, but I thought its motto was "conventon over configuration"?
Wasn't Rails 1.0 invented to solve this exact problem? A decade later and after 5 versions we are here?