3 ms·

"...but I’m not Facebook and having capacity problems means that I am probably already vacationing at my hollowed-out volcano lair." So now we finally know pat

by bryanh 16y ago

"...but I’m not Facebook and having capacity problems means that I am probably already vacationing at my hollowed-out volcano lair." So now we finally know patio11's grand scheme! But seriously, thanks for the writeup. I am using the lazy man's version control (Dropbox... ;-) ), but I definitely need to more to Git ASAP. I guess before now the time spent learning and setting Git up was better spent doing something else (at least in my mind).

enlil 16y ago
Having a staging server doesn't only help with capacity problems, but more so with deployment problems and differences in the environment. You might be running 32 Bit on your server but 64 Bit on your dev box. Or prod uses Amazon RDS, but locally you just have MySQL on the same box. And oh suprise, now your mysql gem doesn't want to be built. Or you ran each migration on your dev box separately as you build them and when you run them all at once during your prod deploy, things blow up. That's what a good staging environment should protect you from. And for all of that to be a problem, 2 users a minute are more than bad enough. You don't need to be Facebook for that. Even better, if you for example host your app on heroku, you get you staging and demo env for free in less than 30 minutes!
- getsat 16y ago
  +1 Staging environment must be IDENTICAL to production or ridiculous and disastrous errors will occur when you least expect them.
- ericlavigne 16y ago
  Patrick's reference to "capacity problems" was in regards to deciding whether to clear memcached. In a large scale deployment, such as Facebook, clearing the caches could overwhelm the servers. Patrick is small-scale enough to not worry about that, and prefers clearing the cache to avoid stale-cache-related bugs. I do agree regarding how nice it is to use Heroku. My only issue with them is that they only support Ruby and Node.js, so I need to take my Clojure applications elsewhere.
stoney 16y ago
Definitely get Git/Mercurial set up sooner rather than later - it's actually very easy to get the hang of the basics and it will give you a noticeable productivity boost (having a decent history of everything you've done is surprisingly helpful at times). You can still use dropbox as a kind of backup for your repository - no need to muck about setting up servers etc. If you don't mind going for mercurial instead of git then take a look at hginit.com. Then if you're on windows, go and install tortoiseHg.
teejae 16y ago
Any form of real source control is a better setup than just using Dropbox. I happen to do Git+Dropbox right now, but anything will do. Source control just provides lots of benefits for logging and rolling back and around. Git and Mercurial, as distributed version control systems, just happen to be easiest since you don't need to really setup a repository, and just have all the data on local disk. It really is practically free. Go to your source directory now: 1. git init # makes the directory a git repository 2. git add . # adds everything in that directory 3. git commit # commits it

by bryanh 16y ago

enlil 16y ago

Having a staging server doesn't only help with capacity problems, but more so with deployment problems and differences in the environment. You might be running 32 Bit on your server but 64 Bit on your dev box. Or prod uses Amazon RDS, but locally you just have MySQL on the same box. And oh suprise, now your mysql gem doesn't want to be built. Or you ran each migration on your dev box separately as you build them and when you run them all at once during your prod deploy, things blow up. That's what a good staging environment should protect you from. And for all of that to be a problem, 2 users a minute are more than bad enough. You don't need to be Facebook for that. Even better, if you for example host your app on heroku, you get you staging and demo env for free in less than 30 minutes!

getsat 16y ago
+1 Staging environment must be IDENTICAL to production or ridiculous and disastrous errors will occur when you least expect them.
ericlavigne 16y ago
Patrick's reference to "capacity problems" was in regards to deciding whether to clear memcached. In a large scale deployment, such as Facebook, clearing the caches could overwhelm the servers. Patrick is small-scale enough to not worry about that, and prefers clearing the cache to avoid stale-cache-related bugs. I do agree regarding how nice it is to use Heroku. My only issue with them is that they only support Ruby and Node.js, so I need to take my Clojure applications elsewhere.

stoney 16y ago

Definitely get Git/Mercurial set up sooner rather than later - it's actually very easy to get the hang of the basics and it will give you a noticeable productivity boost (having a decent history of everything you've done is surprisingly helpful at times). You can still use dropbox as a kind of backup for your repository - no need to muck about setting up servers etc. If you don't mind going for mercurial instead of git then take a look at hginit.com. Then if you're on windows, go and install tortoiseHg.

teejae 16y ago

Any form of real source control is a better setup than just using Dropbox. I happen to do Git+Dropbox right now, but anything will do. Source control just provides lots of benefits for logging and rolling back and around. Git and Mercurial, as distributed version control systems, just happen to be easiest since you don't need to really setup a repository, and just have all the data on local disk. It really is practically free. Go to your source directory now: 1. git init # makes the directory a git repository 2. git add . # adds everything in that directory 3. git commit # commits it