“Loud pipes save lives” has always been one of my favorite bits of Harley rider wisdom. It turns out there may be something to it. Hybrid cars are twice as likely to be involved in accidents with pedestrians and bicycle riders as regular cars.
“Loud pipes save lives” has always been one of my favorite bits of Harley rider wisdom. It turns out there may be something to it. Hybrid cars are twice as likely to be involved in accidents with pedestrians and bicycle riders as regular cars.
I’ve discussed continuous deployment before. The idea is simple — ship more often — ideally, with every single commit. The last post was about blog post explaining continuous deployment by Eric Ries, CTO of IMVU. For more on the concept see this presentation by his colleague, Tim Fitz, on the same subject. I am very much intrigued by this concept, if only because it frustrates me when release cycles slow down so much as applications mature.
Tyler Cowen on Twitter:
Think of it as Google focused on one time-slice and giving the weight of crowd opinion no more than linear force. If an opinion is more common it will receive more tweets but otherwise your search brings up the splat, ordered by chronology, and thus it is more idiosyncratic than the first Google search page and often in a good way.
What’s interesting to me about Twitter is that it is different things to different people. Some people get lots of value from Twitter search — I hardly use it. But I find Twitter to be invaluable as a place to sound out ideas and keep in touch with people in my network. And I have very good luck seeking advice on Twitter.
A couple of years ago I described the bubble pattern. It’s basically a three four step pattern:
Chris Dixon explains how this pattern has manifested in venture capital.
Last week Firefox developer Alexander Limi posted about rough edges in the Firefox installation experience on the Mac. His article attracted a ton of thoughtful responses, and he posted a follow-up today discussing the options he looked at and describing the new installation experience that will be featured with Firefox 3.6.
The problem and solution are an interesting case study for user experience designers. Most Mac users are fine with the way the installation process, but clearly it is confusing to some users, and when you’re talking about an application with millions of users, it’s a big deal. What I liked about the way this worked out is that Limi clearly put a lot of thought into his original post, and the community responded with a ton of good ideas that led to an even better solution that the one he came up with. Now a lot of people are going to benefit.
This really is collaboration on the Web at its best — and I would hate to see it pass by unremarked upon.
On another note, the design of Alexander’s blog is just awesome.
I’ll be participating in the Walk to Cure Lupus for the third year in a row this year. You can see my post from last year about the walk. I’m soliciting donations this year as well and you can find my personal page here.
As I mentioned last year, I have friends and family members who suffer from the disease, which can be debilitating or even fatal. I’d really appreciate it if you could donate to the Walk. Nearly all of the money goes toward research, and it’s a cause that’s important to me personally.
I know that everybody is bombarded by requests for donations and that times are hard, so thanks in advance for even thinking about supporting lupus research.
Columbia Journalism Review has a great interview with Rick Perlstein explaining why the media shouldn’t be all over the ACORN story. In short, conservatives want to raise ACORN’s profile because they are embarrassing. If you can get people to equate ACORN and the White House, then any dirt you dig up on ACORN tars the President by association. The current ACORN mania really isn’t any different than the repeated attempts to equate Barack Obama with Bill Ayers during the campaign.
Google has thrown their hat into the ring when it comes to dealing with the Internet Explorer 6 issue, creating an IE plugin that replaces the IE rendering engine with Chrome. I think it’s a pretty brilliant idea, but I’ll be curious to monitor the adoption rate. My guess is that people who are stuck using IE6 for whatever reason won’t install the plugin, given that they haven’t installed any of the other excellent, free options that currently exist. It does let Google take another step away from supporting Internet Explorer, though, since now they can demand that users install the plugin.
Not buying nice computers for software developers is a mistake. I put this so bluntly because I think it’s an easy mistake to make if you don’t really understand developers. I’m not going to make an argument based on the productivity gains to be had through the use of more powerful computers and bigger monitors. Those are good reasons to make sure people have the tools that make them most effective, but the reasoning behind making sure developers have nice computers goes beyond that.
First of all, it should be noted that many developers are computer enthusiasts. The developers you most want to hire fall into this category. They know the difference between the laptops Dell sells for $600 and the Lenovo ThinkPads that sell for $2,000. They can tell the difference between the nice 20″ LCD monitor and the crappy one. And in most cases, they care about those differences. So when they get a hand me down laptop or a new computer that’s substandard when they start a job, most developers find it a little disheartening. They know they could have something better, and in many cases they do have something better sitting at home on their desk. Ideally, when you’re looking to save money, it should be in an area where people won’t notice. When it comes to their tools, people notice.
The second point is that providing developers with top of the line tools lets them know that the company takes their work seriously. It almost doesn’t matter what someone gets paid — if they are given substandard equipment, it makes them feel like the company doesn’t really value their work, probably because whoever is making the decision doesn’t understand their work. Going all out on equipment is a strong signal to prospective employees that you have a clue.
And third, it’s not that expensive. Software developers tend to be pretty well compensated, and when you add on the amount of money it costs to provide benefits, a work space, and everything else, the difference between a cheap computer and a nice computer is really small. The most expensive laptop in the Apple Store is $2,500. The cheapest is $1,000.
To make my point, I’m collecting job ads that promise nice computer hardware to developers. Here’s a job posting from Tumblr:
You’ll get to work in a nice office in New York City on a Mac Pro with giant monitors on something you actually care about that’s used by well over a million people.
And here’s what Mint.com offers:
Engineers get their own top-of-the-line laptop with 4GB RAM and a docking station, and flat LCD monitor for their desk. Built-in unlimited mobile broadband is a company-sponsored option. Having the right tools is important.
I worry more about equipment purchases as someone who’s gone out and hired developers than as an end user. Finding good developers is really, really difficult, and companies should give themselves every advantage that they can. Having an equipment policy you can brag about is a tangible advantage, and I’m always amazed when companies forgo that advantage.
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Preparing for continuous deployment
Since I watched the Tim Fitz video that I linked earlier, I’ve been thinking about continuous deployment. Whether you are really going to deploy every day or not, the idea that your code base is always in a position where it could be deployed immediately is enticing. As Tim points out, getting your code into that shape means that you’re getting a lot of things correct.
So I thought I’d break it down a bit and look at the steps required to get an application in shape for continuous deployment. From the presentation, it seems like the major steps are as follows:
Set up a continuous integration system. Once your tests are set up, you need to automate them so that they’re run every time code is committed. If necessary, you have to set up this system in parallel so that tests run quickly enough not to gum things up. (In the presentation, Fitz mentions that their full test suite takes 6 CPU hours to run and is split among 40 machines).
Build a monitoring system that is effective in catching post-deployment problems. When you’re deploying all the time and relying almost solely on automated testing to verify your builds, you want to monitor your application to make absolutely sure that everything is in order while it runs. This is your last and best line of defense against errors that are causing problems in production but that you haven’t noticed yourself.
While all of those things are necessary to implement a continuous deployment system effectively, it seems like these are all features you’d want for any application. I’m going to explore getting the application I work on into a state where it could move to a continuous deployment and write up what it takes to get all of the prerequisites set up.
The big question is whether it’s possible to invest the effort to put the work into setting things up so that continuous deployment could work if you aren’t actually going to do it. The truth is that while all of these features are really nice, there are a lot of applications out there that get by without them. Even so, I’d love to give it a shot.