Our Chef-based stack(s) are open source and hosted on github. We are thinking of packaging them in a form that is convenient to run in a local Vagrant box or something of that sort, so that you can easily test your app without wrecking your production environment first.
Regarding cuisine vs. Chef Solo... I think it mostly depends on what your scripts do. In my opinion, Fabric/Cuisine make it absurdly easy to execute commands against a remote server and most of the time that's enough for a decent deployment. Chef's execution API is, to put it mildly, clumsy. I cringe every time I have to type something like:
execute "#{virtualenv_dir}/bin/pip install -r #{requirements_file}" do
user deploy_user
group deploy_user
end
IMO Chef shines when you have to move a lot of config files and generate node- and role-specific configs. I feel it's a lot simpler to just have recipe-specific files and templates packaged with the recipe and move them over with commands like cookbook_file and template.
Right now we are using both the technologies. Our stacks are Chef-based since we want people to be comfortable with reading (and possibly modifying) its code. We also reuse a lot of the Opscode recipes which simply do not exist for Fabric/Cuisine. Fabric and Cuisine have their place when we bootstrap a server and prepare the Chef environment and at several odd places where they keep things running together.
I'm all for server tweaking and I do it all the time, but sometimes it gets boring. I could probably do something better than configure php5-fpm for the thousandth time.
Right now, Stackful.io takes the pain from that when it comes to Node.js development. You just pick a server size and hit a button. 2 minutes later your machine is ready to rock and you can deploy your app with a simple Git push.
We are planning on doing the same for the other major web technologies. We have some pretty good progress with a Python stack and a PHP one is in our queue.
Thousands times this. I've seen situations like that in all sorts of businesses and software projects aren't unique in their inability to deal with complexities and bad communication.
On the other hand, learning to manage software projects gets you an almost unfair advantage at managing "simpler" and more mundane projects where everyone and his mother underestimates the complexities and all the ways things can go wrong.
Sound advice. I didn't mean to go to the SQL vs. NoSQL war zone and I have nothing against SQL DB's. All I wanted to say is that I find the current Redis solution easier to implement than the [clumsy] one I did in the past.
I took a look at it when starting work on those features, but decided against it. I wanted as much freedom as possible in storing, accessing, and displaying data since we'll need to build something more sophisticated in terms of analytics later on.
We use our analytics engine to show charts to our users as well. I can't do that with graphs generated from tools like Cacti/Ganglia/Graphite... As is the case with almost all sysadmin tools, they don't look too good.
ZSET's indexed by time_ts sound cool until you need to increment a value for a time since you'd have to change a key of the item in a set. I have no idea how that might work.
Thinking of it, you could probably remove the old value and insert the new (incremented) one, but that seems both slower and non-atomic.
Yes, learning some programming to be an iOS developer isn't enough, but that doesn't mean that guys like k-mcgrady can't learn on their own. Keep it up, man!
I know a programmer that knows so much of language and compiler theory he is always a source of knowledge and inspiration to me. He has a university degree in... accounting.
But I want the future generations to know that I praised Justin Bieber's haircut on twitter while listening to his latest song!
Yeah, I agree - completely irrelevant. That time better get spent integrating diff-able formats like textile, markdown, even TeX into writers' versioned workflows.
The postmortem is pretty weak and us, geeks, would have loved to see more detail. Tumblr would have gotten some good karma with a detailed explanation. Well, unless this is all made up just to look impressive and the real reason was something else like human error that wiped the production DB. But even in that case honesty would have paid off - remember GitHub's recent DB wipe and their excellent explanation?
On a side note - anyone know what DB they are using? The cynic in me is thinking "Hey, another MongoDB + FourSquare 'success' story of webscale awesomeness."
I started learnimg Scala in the midst of the "2.7 vs. 2.8" turmoil and all I can say is that it wasn't just fairies and unicorns. Hopefully that's gone now and everything I use seems to work with Scala 2.8. All I can say is that I love the language and I keep using it. It's fit for super-serious development.
I sometimes think the problems came from library authors that jumped to Scala 2.8 too soon. Kudos to the Lift framework guys for maintaining builds that work both with Scala 2.7 and 2.8!
Everyone has to make his/her choice of technology and MailChimp has chosen PHP. That's perfectly okay.
I know PHP, and I've used it to put food on my table. Luckily that is no more. I'd consider doing PHP again only if my wife and kid were starving.
My advice to people stuck with PHP codebases - start changing the site backend first. Write everything not related to spewing HTML in a real programming language, and slowly limit PHP use as a simple template-processing tool that generates your app's HTML. Which is probably the only thing PHP is good for.
This all VM thing is fine and dandy if you want to have an accessible mirror of your staging machine and reduce unnecessary stages. Although that in itself looks fishy - if developers want to stage something just to see if it works, then something is seriously wrong with your process or developers.
I'm amazed at the level of sophistication in this setup - using virtual machines and TCP proxies that do text replaces seems too much. They could have just built the configurability in the damn application. I have a .NET app that normally gets deployed on three servers and uses various remote resources like Amazon SQS queues, but I easily built a configuration abstraction similar to Rails' environments that lets me deploy on a single machine and even test locally with a debugger attached.
My point is that this problem looks as if it got solved at the wrong level of abstraction. Which, obviously, made it unnecessarily hard and complex. If I had to tackle it, I'd make sure developers do the right thing and try to make the app configurable enough first.
Yes, thanks to the websocket support that landed in recent Nginx releases.