If you build web applications, you've got to contend with Internet Explorer, versions 6 and 7. The quandary is that it's not clear how to have both versions installed at the same time. Some people have resorted to using several virtual machines, but this turns out to be overkill.
Lindsey Kuper comes to our rescue, and points out this article: Using IE6 and IE7 together.
The first approach in that article was especially helpful for me: there's a version of IE6 bundled with all the libraries, ready to go even if the updates have installed IE7 for you. It works great, in as far as IE6 can be said to "work great".
What is surprisingly nice is the Internet Explorer Developer Toolbar. This is from those cats in Redmond, and I'm surprised it's not more widely publicized. It comes with a very functional DOM inspector that users of Firebug will figure out pretty quickly, and it works with that standalone IE6.
So! Now you can more easily and precisely diagnose just which inane and hateful things the IE rendering engine is doing to your app!
Happy hacking, and good luck :)
Friday, February 29, 2008
Tuesday, February 26, 2008
Today's viewing: Linus on git.
Not too many months ago, Linus gave a talk at Google about git, the distributed version control system he built for use in managing the Linux kernel. He spoke, in typical non-diplomatic Linus style, about why everybody should switch to git and why CVS, Subversion, Perforce, and non-distributed source control in general is broken.
"There's a few of them in the room, I suspect -- you're stupid!"
-- Linus calls out the svn developers on hand
The Linux kernel team had previously been using the proprietary BitKeeper, which a number of kernel developers (including Alan Cox, with his Mighty Unix Beard) chose not to use. Before that, source control for the kernel was handled by sending patches around -- preferable to using centralized source control, according to Linus.
So let it be known that I haven't actually /used/ git yet, or in fact any distributed source control system -- but I like the idea so far. In this post, I'll outline the reasons Linus lays out for why we should be using git.
First off, the distributed nature of git also has performance and convenience benefits, from the simple fact that it doesn't need to make network roundtrips. Having your own repository on the local machine means that you're always set to go, even if the network is slow or unavailable.
Secondly, traditional source control makes branching and merging branches hard (Linus points out that many real-live software developers have never done it), so you don't want to commit your work until it's ready to be seen by others -- this means that you can't do much version control during the actual code-writing process. Contrastingly, in distributed source control, every checkout acts as its own branch, so each developer has at least one. This has the benefit that you can commit to your own repository whenever you want -- and then back up to previous versions whenever you like.
Centralized approaches to source control are particular drag when people are depending on your committed code as correct, or at least non-breaking -- you're not allowed to commit until your changes are ready for the rest of the team. As a project gets bigger, the associated test suite (hopefully) does as well, eventually leading to a pretty involved testing procedure that developers are supposed to complete before committing. And as Linus puts it, "... people make one-liner changes and ignore the test suite, because they know that those one-liners can't /possibly/, /possibly/ break." And then these breaking changes get pushed out to the rest of the team. The alternative approach, with git, is that you commit to your own version of the repository whenever you want, and when you're ready, your teammates can pull from you -- but in the mean time, you get all the benefits of having your own branch(es).
Thirdly -- social benefits! In his development process, Linus only pulls code from ten or fifteen other developers, whom he trusts to have filtered "up" appropriate changes from the people that they interact with. As he puts it, "if you have determined that somebody else is smarter than you -- go for it!" So the Linux kernel source control process mirrors the social networks of trust that make the whole thing happen. In the end, a lot of people end up only looking at the Linus branch, the defacto "official" one.
This dodges the social issue of giving out commit access to the central repository. Traditionally when managing a project, you create this class of people who are "ostensibly not morons", and typically, you make that group of people too small. Distributed model makes this go away, because everybody has his own branch. And if you happen to do good work in your own branch, then people start pulling from you! "That alone means that every single open-source project should use nothing but a distributed model."
So. That's what Linus said. Will everyone switch to git or some other distributed source control? We'll find out. Adoption would certainly be helped out if major project-hosting sites like Sourceforge or Google Code added git support. But sort of the point of the distributed model is that there's no one central hosting point...
Maybe I'll try it out. I'll let you know.
"There's a few of them in the room, I suspect -- you're stupid!"
-- Linus calls out the svn developers on hand
The Linux kernel team had previously been using the proprietary BitKeeper, which a number of kernel developers (including Alan Cox, with his Mighty Unix Beard) chose not to use. Before that, source control for the kernel was handled by sending patches around -- preferable to using centralized source control, according to Linus.
So let it be known that I haven't actually /used/ git yet, or in fact any distributed source control system -- but I like the idea so far. In this post, I'll outline the reasons Linus lays out for why we should be using git.
First off, the distributed nature of git also has performance and convenience benefits, from the simple fact that it doesn't need to make network roundtrips. Having your own repository on the local machine means that you're always set to go, even if the network is slow or unavailable.
Secondly, traditional source control makes branching and merging branches hard (Linus points out that many real-live software developers have never done it), so you don't want to commit your work until it's ready to be seen by others -- this means that you can't do much version control during the actual code-writing process. Contrastingly, in distributed source control, every checkout acts as its own branch, so each developer has at least one. This has the benefit that you can commit to your own repository whenever you want -- and then back up to previous versions whenever you like.
Centralized approaches to source control are particular drag when people are depending on your committed code as correct, or at least non-breaking -- you're not allowed to commit until your changes are ready for the rest of the team. As a project gets bigger, the associated test suite (hopefully) does as well, eventually leading to a pretty involved testing procedure that developers are supposed to complete before committing. And as Linus puts it, "... people make one-liner changes and ignore the test suite, because they know that those one-liners can't /possibly/, /possibly/ break." And then these breaking changes get pushed out to the rest of the team. The alternative approach, with git, is that you commit to your own version of the repository whenever you want, and when you're ready, your teammates can pull from you -- but in the mean time, you get all the benefits of having your own branch(es).
Thirdly -- social benefits! In his development process, Linus only pulls code from ten or fifteen other developers, whom he trusts to have filtered "up" appropriate changes from the people that they interact with. As he puts it, "if you have determined that somebody else is smarter than you -- go for it!" So the Linux kernel source control process mirrors the social networks of trust that make the whole thing happen. In the end, a lot of people end up only looking at the Linus branch, the defacto "official" one.
This dodges the social issue of giving out commit access to the central repository. Traditionally when managing a project, you create this class of people who are "ostensibly not morons", and typically, you make that group of people too small. Distributed model makes this go away, because everybody has his own branch. And if you happen to do good work in your own branch, then people start pulling from you! "That alone means that every single open-source project should use nothing but a distributed model."
So. That's what Linus said. Will everyone switch to git or some other distributed source control? We'll find out. Adoption would certainly be helped out if major project-hosting sites like Sourceforge or Google Code added git support. But sort of the point of the distributed model is that there's no one central hosting point...
Maybe I'll try it out. I'll let you know.
Subscribe to:
Posts (Atom)