3 ms·

To make app setup even easier, you can write out scripts that bootstrap the application: http://githubengineering.com/scripts-to-rule-them-all/ http://githuben

by nemild 11y ago

To make app setup even easier, you can write out scripts that bootstrap the application: http://githubengineering.com/scripts-to-rule-them-all/ http://githubengineering.com/scripts-to-rule-them-all/

patio11 11y ago
I like this idea a lot. We're going to steal it.
mseebach 11y ago
Scripts like that need to be able to recover from a very wide range of error modes caused by subtle differences in how target machines are setup - or at least fail in a reasonably obvious way. Writing such a script is significantly more time consuming than writing a README, and for it to be worth the effort, it should be expected to save a fairly high multiple of the time it takes to write, debug and support. For GitHub, that multiple is definitely very high, for Patrick, it might not even be greater than one. YMMV.
leftnode 11y ago
Yup, it's a great idea! In all of our applications we have a build-dev shell script that builds the application for development purposes. New developers day 1: vagrant up; vagrant ssh; cd /path/to/app/on/vm; ./build-dev And they're ready to go.
peterwwillis 11y ago
Very similar to this, I like to say that automation is documentation. Of course, actual documentation is better, but compared to no documentation, a script or automation or test is better than nothing. I used to do this just because i'd forget how to do something so I wanted a written down example of it, and then I make it into an actual program, and then I automatize it. You wouldn't believe how many people end up depending on these crap little examples. And of course READMEs in every directory in a tree that explains what everything in that directory is and what it does.
abulman 11y ago
That's the background on a couple of tweets I've already sent today - part of a 56! post sequence (3/4 done, I'm splitting it up a bit). https://twitter.com/alister_b/status/636563590288437248 https://twitter.com/alister_b/status/636563590288437248 - 29/ If I start work and have to spend 3 days just getting the dev site running locally - we know the live site is also a pile of crap There's a plenty more of along similar lines about recruiting, interviewing, and the working environment - both for people, and the code. When I'm done, I'm putting them all together in a blog post with some extra thoughts as well.

by nemild 11y ago

To make app setup even easier, you can write out scripts that bootstrap the application: http://githubengineering.com/scripts-to-rule-them-all/ http://githubengineering.com/scripts-to-rule-them-all/

patio11 11y ago

I like this idea a lot. We're going to steal it.

mseebach 11y ago

Scripts like that need to be able to recover from a very wide range of error modes caused by subtle differences in how target machines are setup - or at least fail in a reasonably obvious way. Writing such a script is significantly more time consuming than writing a README, and for it to be worth the effort, it should be expected to save a fairly high multiple of the time it takes to write, debug and support. For GitHub, that multiple is definitely very high, for Patrick, it might not even be greater than one. YMMV.

leftnode 11y ago

Yup, it's a great idea! In all of our applications we have a build-dev shell script that builds the application for development purposes. New developers day 1: vagrant up; vagrant ssh; cd /path/to/app/on/vm; ./build-dev And they're ready to go.

peterwwillis 11y ago

Very similar to this, I like to say that automation is documentation. Of course, actual documentation is better, but compared to no documentation, a script or automation or test is better than nothing. I used to do this just because i'd forget how to do something so I wanted a written down example of it, and then I make it into an actual program, and then I automatize it. You wouldn't believe how many people end up depending on these crap little examples. And of course READMEs in every directory in a tree that explains what everything in that directory is and what it does.

abulman 11y ago

That's the background on a couple of tweets I've already sent today - part of a 56! post sequence (3/4 done, I'm splitting it up a bit). https://twitter.com/alister_b/status/636563590288437248 https://twitter.com/alister_b/status/636563590288437248 - 29/ If I start work and have to spend 3 days just getting the dev site running locally - we know the live site is also a pile of crap There's a plenty more of along similar lines about recruiting, interviewing, and the working environment - both for people, and the code. When I'm done, I'm putting them all together in a blog post with some extra thoughts as well.