5 ms·

> minimize the time spent writing boilerplate code and performing repetitive setup tasks. The problem with this is that everyone likes his configuration be in

> 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. I personally don't see value in them at all.

brunofacca 9y ago
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.
msluyter 9y ago
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.
- weaksauce 9y ago
  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.
  - yellowapple 9y ago
    I'm sorry to say that the curation of those lists tends to need work. I know this because I have at least one project on the "awesome Elixir" list that is absolute rubbish :)
vinceguidry 9y ago
> 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.
- choward 9y ago
  > 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.
  - vinceguidry 9y ago
    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.
yellowapple 9y ago
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.
6t6t6t6 9y ago
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.

brunofacca 9y ago

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.

msluyter 9y ago

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.

weaksauce 9y ago
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.
- yellowapple 9y ago
  I'm sorry to say that the curation of those lists tends to need work. I know this because I have at least one project on the "awesome Elixir" list that is absolute rubbish :)

vinceguidry 9y ago

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

choward 9y ago
> 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.
- vinceguidry 9y ago
  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.

yellowapple 9y ago

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.

6t6t6t6 9y ago

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.