Actually I think active is probably the wrong word, so changed in the post, but to answer your question:
It's a system based on multiple web services and run across multiple hosts, and I've included all system checks in that number. So we have checks for:
* ping, ssh, disk, load, network io, etc.
* error rates from request logs
* request rates (warning on high values)
* smoke tests for key functionality (i.e. does the search engine return results, can you complete certain forms, etc.)
* connection tests from relevant hosts to relevant services or databases
I'll give it a good few weeks, say a month, and then get the results together. It depends on how popular it is, if I'm still seeing results come in and how much time I can grab.
Thanks. I'd kept off all identifying information as some folks prefer to keep operational information secret. I'm hoping the complete anonymity gets me more filled out questionnaires.
I'll give it a good few weeks, say a month, and then get the results together. I'll post them to my blog (http://morethanseven.net) and I'll post the link on here too.
RVM is great. But by design it's a solution to compiling software on every machine. This simply doesn't work for lots of sysadmins, especially with lots of machines - it means installing a complete build environment which opens up much more evil.
It's also guilty of being unattractive to the developers I'd love to see use it. The site says "Recent News: Dec 26th, 2009" and then concentrates on a NOTE TO SLACKWARE 8.0 USERS.
Showing the hello world of checkinstall would be much better imho, and it's what developers from the web world expect.
That wasn't my aim. In fact I'm not using Debian at the moment as I indicated, I just know the commands better to give examples. This isn't about a specific distro, it's about the huge benefits of system packages and their toolchains in general. I'm not even really concerned with official packages and the official blessed package repos.
To my knowledge no. I think this is one of the main problems in getting people to create system packages. I think this fosters the split between package maintainers and developers. It's not that the documentation is all bad, it's just not aimed at the audience I think it should be.
System packages just aren't what web savvy developers grew up on and the documentation feels out of step. But the capabilities and tools around system packages are awesome.
I might take a go a writing a simple guide, but I'd be more than happy to see other people have a go that know more than I do. Let me know if this sounds of interest.
In lots of cases the separate package maintainer's do a good but ultimately thankless task. The example I gave between the rabbitmq packages which are built as part of the development effort and made available on the rabbitmq site and the solr packages which are sometimes out of date and not referenced by the site highlights the point I'm trying to make.
Thanks for the advice. Good idea, the original aim was for a newsletter aimed at an existing community but from some mentions on Twitter it looks like other people are interested too.
I can also claim very little credit for the design, that goes to peterc who writes Ruby Weekly. I spoke to him first about launching a devops variant and he very kindly said I could borrow his design from http://rubyweekly.com/.
Personally I edit the code on my mac using gvim and run and use git on the VM. I've used ExpanDrive to mount the directory from the VM for editing previously but I've been moving towards using vagrant with it's NFS shares.
People might be interested in DoubleDown (http://blog.devstructure.com/introducing-doubledown) from the DevStructure guys. It uses rsync in a similar background manner and it's designed with this exact problem in mind.
I'll change the Ruby tool bit. I mentioned elsewhere in the post that it's a great tool whichever language you're using.
Regarding tools other than Chef for provisioning, while there is a Python clone somewhere Chef will very likely have the ability to use other languages for recipes very soon. I've seen at least Java and Python mentioned.
One of the things that I think is relevant to startups hiring is that (warning experience mixed with opinion ahead) there are lots and lots of PHP developers of wildly varying quality. This makes the initial stages of recruitment time consuming. By looking for people with skills or interest in Ruby, Python or Scala (or whatever is hot that month) you'll probably see less interest but, on average, the quality and enthusiasm will probably be greater. Which means it takes less time to hire (well, maybe), as well as getting the better people (hopefully).
I'll probably get round to opening up the code so people can run their own versions soonish. I want to test out a few things first and clean up the code. If anyone is particularly interested drop me an email at [email protected]
Paypal is good and pretty feature rich, but it's not the most straightforward thing to work with. It's not really that the API is under-documented, more that it can involve lots of back and forth and your code needs to deal with lots of cases. The advantage is ease of use. In terms of time to implement and wide spread user awareness it's a good starting point to get the money coming in - with more options provided as time permits.
It's a system based on multiple web services and run across multiple hosts, and I've included all system checks in that number. So we have checks for:
* ping, ssh, disk, load, network io, etc. * error rates from request logs * request rates (warning on high values) * smoke tests for key functionality (i.e. does the search engine return results, can you complete certain forms, etc.) * connection tests from relevant hosts to relevant services or databases