Let me just preface this email by saying that I'm all for local dev environments on my own desktops/laptops, and that's how I work.
On Wed, Mar 23, 2011 at 6:16 PM, Mac Newbold <[email protected]> wrote: > One disadvantage of a local dev environment is that it is local to > exactly one computer. If you always develop on that box (i.e. a > laptop) then it can make sense, but if you have a box at work and a > different box at home or elsewhere that you sometimes use, or a > desktop and a laptop, then your dev environment is stranded on the one > box where it is set up, and when you pick up where you left off on a > different machine, none of your local changes are there. If it applies > to you, it's a showstopper though for having one local dev environment > rather than having a dev environment out in the cloud somewhere. I fit in this boat, even on the extremes since I have an iMac at work, and a Windows 7 laptop at home, but I don't agree with this at all. I finish up what I'm doing at work, and commit what I have regardless of the state to my personal remote git branch, then if I need to work on something at home, I pull the branch and continue right where I left off. Nothing changes except for the minor differences in rendered fonts on the site (I can't wait for this problem to mostly disappear with HTML5), heh. Also, who is concerned about uptime on a local dev machine? I'm not sure what that has to do with anything. Both my laptop and desktop are plenty reliable for serving up pages only to myself. > The other disadvantages are related to the other things you mention: > many of us haven't solved the whole "getting a dev environment set up > anywhere quickly" problem, nor do we need to set up new dev > environments often. Also, with a local dev environment it takes extra > steps (loading it onto some other remote environment) in order to > easily let others see your changes and play with them. With an > already-remote environment, other people can see changes just as fast > as you can, with no extra work, which in many cases I have used to > great advantage so I can tweak things as they watch and sign off. I completely disagree here. Both the XAMPP project (for Windows) and the MAMP project (for OSX) take just a few minutes to install and configure an entire dev environment with Apache, PHP, MySQL, phpMyAdmin, and even some other additional tools like a MTA for Windows for PHP mail(). But going even further, I didn't even use XAMPP on my laptop, I installed and configured the vanilla Apache, PHP, MySQL, and phpMyAdmin packages each by hand, and even though I hadn't done this on a Windows machine in probably over 8 years, it took me only an hour. As far as Ubuntu... apt-get anyone? heh If I have to meet with someone outside of the office to go over some things I'm working on to get it signed off, I take the laptop, and it's all there ready to go. I don't even have to ask them for their wifi password or tether up my phone (either to upload changes to the dev server and have them open the site up on their computer - assuming they even are in front of one, or to pull up the dev server on my own laptop). > Another major difference is that it is much easier to set up a > dev/staging environment that most closely matches production > environment by setting it up remotely rather than locally. I usually > set up dev/staging environments in the same place the site is hosted, > to minimize the potential that something that worked fine on my local > won't work the same in a more realistic (production-like) environment. > There's also a good argument for a remote environment as a more secure > place for your data - much easier to drop a laptop, have an electrical > or plumbing problem destroy a desktop at home or at the office, or > have your laptop get lost or stolen, etc, but your remote server will > be just fine if your local machine has any of those issues. There are very few cases where it might actually be required to push your changes to a dev/staging server for something you're working on to work correctly, most of these cases can be setup to work correctly on the developer's machines just fine without much hassle. It is true that there are cases where this happens, but that's fine because I'm not saying you shouldn't have a dev/staging server setup anyway where final testing is done by non-developers. Though, this doesn't mean you have to always do 100% of your development on a dev/staging server setup for this purpose. Data stability is a non-issue as well since you should be setup with a VCS of some kind anyway. At most, I'd only ever lose possibly one day's worth of work, ever. It's not like I always keep only one copy of the source code and it's entire change history all on one developer's machine. As far as speed in regards to local vs remote, I do actually see sort of a stalemate here. I see huge time saved simply editing local files with no need to upload anywhere, especially when I'm "in the zone". However, on local, your dev machine is rarely as beefy as a dedicated dev/staging server, and with every page refresh, Apache and PHP on your machine are working on serving up a completely un-cached version of the page you're working on at the exact same time your browser is working on rendering it, and I do notice that it can become much slower than loading pages from a remote server. Regards, Bryan Petty _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
