7 ms·

>If you love automation why is your development environment manual? Because I usually do it once in 5 years :-) My setup: Linux, Kubuntu LTS. Entire system is

by qwerta 13y ago

>If you love automation why is your development environment manual? Because I usually do it once in 5 years :-) My setup: Linux, Kubuntu LTS. Entire system is backed-up with rsync, so I have daily snapshots for last 6 months. There is also weekly backup to cloud and external hdd. I have primary 250GB SSD which usually sits in my workstation. Whan I travel I physically move SSD to laptop (takes 10 minutes). If something went wrong and my primary SSD would die: I just boot from Livecd, copy 200GB, setup bootloader and reboot. No need to 'reinstall' system from scratch. Every six months I take one afternoon and update all my tools (IDE, OS, apps...). I dont use automated updates except critical stuff such as browser.

peterwwillis 13y ago
Ditto. Backing up your dev environment is less time-consuming and more reliable than scripting it.
- StavrosK 13y ago
  I don't know, I script production provisioning anyway. Dev provisioning is free, I just change the hostname to the VM.
fideloper 13y ago
I think an important point in this post was more about not trying to setup a dev environment in your base Mac install (or similar). Use Virtual Machines.
- qwerta 13y ago
  In that case I just find it better to wipe MacOS and replace it with Linux.
  - gtaylor 13y ago
    It's not always a good solution for your entire team. I run Linux on my desktop, but have found that the touchpad drivers (even the experimental ones) just really suck on Linux+Macbook Pro to the point where it's either external mouse (not always possible) or decreased productivity. I have a feeling this is going to devolve into a "well, just use vim and a tiling WM or X other thing", but the point is that just replacing Mac OS with Linux isn't always going to be good for your whole team.
    - w1ntermute 13y ago
      If productivity is key, get a ThinkPad, install Linux on it (they're very Linux-friendly), and learn to use the TrackPoint exclusively. Watching people use MacBooks, even with all those fancy multitouch gestures, is like watching a slow-motion movie. And they are always amazed how quickly I can do stuff on my ThinkPad.
      - platz 13y ago
        TrackPoint is amazing; I hesitate to switch from ThinkPad's because of it.
      - zmjones 13y ago
        How is the battery life?
        deleted 13y ago
        [deleted]
        beatgammit 13y ago
        Why do you need battery life for development? Most of the time you'd probably be in the office anyway. Even so, ThinkPads have pretty good battery life, and on some models the CD drive can be replace with an extra battery. I've heard of some that can go nearly two working days before recharging.
        zmjones 13y ago
        I don't work at the office most of the time. I know thinkpads have good battery life generally, but I know there have been some battery life issues with linux in the past.
        lsiebert 13y ago
        Thinkpads have great battery life built in, or you can get extended batteries, or slice batteries. You can even stick a battery in the drive bay. You can also easily turn off ports you aren't using, at least in linux.
- Retric 13y ago
  The problem with VM's is each developer often customizes the, quite a bit. It does make adding someone new faster but unless you have rapid turnover I don't think it's worth the overhead.
  - hosh 13y ago
    That's why you manage the VMs with a configuration convergence tool such as Chef or Puppet. At that point, the VM doesn't matter. I tend to treat mine's as throw-aways, and have Chef rebuild the specific VM for the specific project. This lets me experiment with things and then reset it back to a known, good state.
to3m 13y ago
I've found this too, as an individual. When running Windows I used to have to reinstall everything about once every 2 years. Took about half a day each time. I've reinstalled everything once in 4 years on Mac OS, from Time Machine, so I just left it running overnight. I don't know how long it actually took but I got up the next day to find my computer just as it was. Reinstalling things is annoying, but just doesn't take up enough of my time to be a problem worth fixing. Then again, maybe if I had the ability to quickly set up a new development-ready VM, I'd come to find all sorts of unexpected uses for it? I've certainly found duplicating Parallels VMs handy a couple of times. But I have to say that I'm still skeptical that the time spent learning Chef and trying everything out would be worth it for me. If I were looking after 5 (10, 20...) programmers then my back of the envelope calculations would look a little different.
- dasil003 13y ago
  I hear what you're saying, but I don't think the time spent learning Chef (or Puppet) is ever wasted. It's sort of like mastering a unix shell or getting good at automated testing: initially there is this steep learning curve where you are definitely less productive, but over time it pays huge dividends. Have you ever had to install multiple versions of some package on the same machine? Have you ever had to help a colleague debug a weird issue that was particular to their setup? Have you ever had to work on the same project from multiple platforms and some component didn't work on one of them? Have you ever had a bug only appear in production because of a platform subtlety?
  - hosh 13y ago
    I don't think the time spent learning Chef (or Puppet) is ever wasted. Exactly! It might not look like it right now, but skills in using these tools are moving from cutting edge to essential job/contracting skills in the near future. I don't know much about the Puppet community, but I do know that within the Chef community, the learning curve is flattening. The big thing of 2012 was that we're very close to getting these VM+Chef+Berkshelf setup in a way where you can get onboarded on an existing open-source application without knowing you are using Chef under the cover. How deep you want to dive in is up to you from that point.
gtaylor 13y ago
It's a lot different when you're working with certain teams of mixed technical aptitudes. An automatically assembled VM image I can distribute means much less time supporting our less technical members of the dev team (front-end, designers, biz dev guys). If it's just you, absolutely, don't bother. But it gets much more difficult to support a variety of platforms and configurations as your team size grows. This is where vagrant+chef/puppet really shine.
- qwerta 13y ago
  > An automatically assembled VM image I can distribute means much less time supporting our less technical members of the dev team Absolutely. At my previous work we had 'standard' VM with all necessary tools such as Visual Studio 97. I just dont understand if it brings so much benefits if all you just need is different version of Ruby.
23david 13y ago
Have you ever tested restoring from your daily snapshots? :-) Seems like a good setup, but to be rigorous about it you should probably also schedule a full restore from backup every once in a while to ensure that your backups are actually working correctly.
- qwerta 13y ago
  http://www.mikerubel.org/computers/rsync_snapshots/ http://www.mikerubel.org/computers/rsync_snapshots/

by qwerta 13y ago

peterwwillis 13y ago

Ditto. Backing up your dev environment is less time-consuming and more reliable than scripting it.

StavrosK 13y ago
I don't know, I script production provisioning anyway. Dev provisioning is free, I just change the hostname to the VM.

fideloper 13y ago

I think an important point in this post was more about not trying to setup a dev environment in your base Mac install (or similar). Use Virtual Machines.

qwerta 13y ago
In that case I just find it better to wipe MacOS and replace it with Linux.
- gtaylor 13y ago
  It's not always a good solution for your entire team. I run Linux on my desktop, but have found that the touchpad drivers (even the experimental ones) just really suck on Linux+Macbook Pro to the point where it's either external mouse (not always possible) or decreased productivity. I have a feeling this is going to devolve into a "well, just use vim and a tiling WM or X other thing", but the point is that just replacing Mac OS with Linux isn't always going to be good for your whole team.
  - w1ntermute 13y ago
    If productivity is key, get a ThinkPad, install Linux on it (they're very Linux-friendly), and learn to use the TrackPoint exclusively. Watching people use MacBooks, even with all those fancy multitouch gestures, is like watching a slow-motion movie. And they are always amazed how quickly I can do stuff on my ThinkPad.
    - platz 13y ago
      TrackPoint is amazing; I hesitate to switch from ThinkPad's because of it.
    - zmjones 13y ago
      How is the battery life?
      - deleted 13y ago
        [deleted]
      - beatgammit 13y ago
        Why do you need battery life for development? Most of the time you'd probably be in the office anyway. Even so, ThinkPads have pretty good battery life, and on some models the CD drive can be replace with an extra battery. I've heard of some that can go nearly two working days before recharging.
        zmjones 13y ago
        I don't work at the office most of the time. I know thinkpads have good battery life generally, but I know there have been some battery life issues with linux in the past.
      - lsiebert 13y ago
        Thinkpads have great battery life built in, or you can get extended batteries, or slice batteries. You can even stick a battery in the drive bay. You can also easily turn off ports you aren't using, at least in linux.
Retric 13y ago
The problem with VM's is each developer often customizes the, quite a bit. It does make adding someone new faster but unless you have rapid turnover I don't think it's worth the overhead.
- hosh 13y ago
  That's why you manage the VMs with a configuration convergence tool such as Chef or Puppet. At that point, the VM doesn't matter. I tend to treat mine's as throw-aways, and have Chef rebuild the specific VM for the specific project. This lets me experiment with things and then reset it back to a known, good state.

to3m 13y ago

I've found this too, as an individual. When running Windows I used to have to reinstall everything about once every 2 years. Took about half a day each time. I've reinstalled everything once in 4 years on Mac OS, from Time Machine, so I just left it running overnight. I don't know how long it actually took but I got up the next day to find my computer just as it was. Reinstalling things is annoying, but just doesn't take up enough of my time to be a problem worth fixing. Then again, maybe if I had the ability to quickly set up a new development-ready VM, I'd come to find all sorts of unexpected uses for it? I've certainly found duplicating Parallels VMs handy a couple of times. But I have to say that I'm still skeptical that the time spent learning Chef and trying everything out would be worth it for me. If I were looking after 5 (10, 20...) programmers then my back of the envelope calculations would look a little different.

dasil003 13y ago
I hear what you're saying, but I don't think the time spent learning Chef (or Puppet) is ever wasted. It's sort of like mastering a unix shell or getting good at automated testing: initially there is this steep learning curve where you are definitely less productive, but over time it pays huge dividends. Have you ever had to install multiple versions of some package on the same machine? Have you ever had to help a colleague debug a weird issue that was particular to their setup? Have you ever had to work on the same project from multiple platforms and some component didn't work on one of them? Have you ever had a bug only appear in production because of a platform subtlety?
- hosh 13y ago
  I don't think the time spent learning Chef (or Puppet) is ever wasted. Exactly! It might not look like it right now, but skills in using these tools are moving from cutting edge to essential job/contracting skills in the near future. I don't know much about the Puppet community, but I do know that within the Chef community, the learning curve is flattening. The big thing of 2012 was that we're very close to getting these VM+Chef+Berkshelf setup in a way where you can get onboarded on an existing open-source application without knowing you are using Chef under the cover. How deep you want to dive in is up to you from that point.

gtaylor 13y ago

It's a lot different when you're working with certain teams of mixed technical aptitudes. An automatically assembled VM image I can distribute means much less time supporting our less technical members of the dev team (front-end, designers, biz dev guys). If it's just you, absolutely, don't bother. But it gets much more difficult to support a variety of platforms and configurations as your team size grows. This is where vagrant+chef/puppet really shine.

qwerta 13y ago
> An automatically assembled VM image I can distribute means much less time supporting our less technical members of the dev team Absolutely. At my previous work we had 'standard' VM with all necessary tools such as Visual Studio 97. I just dont understand if it brings so much benefits if all you just need is different version of Ruby.

23david 13y ago

Have you ever tested restoring from your daily snapshots? :-) Seems like a good setup, but to be rigorous about it you should probably also schedule a full restore from backup every once in a while to ensure that your backups are actually working correctly.

qwerta 13y ago
http://www.mikerubel.org/computers/rsync_snapshots/ http://www.mikerubel.org/computers/rsync_snapshots/