Status-Q

Non-geeks can skip all of this! Subversion is a very nice version-control system which fixes many of the problems with its predecessor, CVS. You can use, for example Martin Ott's packages to get an up-to-date copy for your Mac. There's some support for it in XCode, and in general it works very nicely on the Mac as long as you don't mind using the command line. I haven't found a Mac GUI for it yet that I like; the best is SvnX and frankly, that's not saying much, though I applaud Dominique Peretti for doing something.

Anyway, there is one thorny issue on the Mac. Many things which appear to be files in the Finder are in fact directories - 'bundles', they're officially called. In the past, they were mostly just used for applications, but an increasing number of document formats are now bundles as well. Apple's Pages and Keynote packages are examples.

When you check a directory tree out of Subversion onto your local disk, a hidden '.svn' directory is created in each directory in the hierarchy. That's where subversion keeps its stuff. Having this in a document bundle does not upset an application; they normally just ignore it. But some apps assume (reasonably) that they're the only ones interacting with the bundle. If you open a document in Pages, change something and then save the doc, it will overwrite the directory with a new one and in the process delete and .svn directories within it, which will confuse Subversion if you then try to check it back in. The latest version of Keynote doesn't do this; it reuses its old directory, but it's unusual in that respect - most things which create bundles will cause a problem if that bundle is managed using Subversion.

There are manual fixes for this (see 'Things to watch out for' at the bottom of this page, for example), but it's very inconvenient if you do this often. Especially if your bundle includes multiple subdirectories because you'll need to do it for each one.

Probably the right way to fix this is for Subversion to be able to view certain directories as untouchable, and store the information about them within the .svn directory of the parent. An alternative would be to tar and un-tar all such directories behind the scenes and check them in and out of the repository as if they were a single file. I discovered a thread from about three years ago discussing this, but I don't think anything was done.

I'm really hoping that Apple, having made a major step forward in file systems by making them searchable, will be the first to introduce decent version control at a fundamental level. Well, the first since VMS, anyway.

I powered up all my Firewire drives today. I don't often do that.

Here's my artistic creation for today, inspired by the work of George Eliot:

Actually, I created this rather by accident. I have been experimenting with the FXscript capabilities of Final Cut Pro. For those not familiar with these, FCP is a professional video-editing package which is widely used in the industry. It has a whole variety of effects filters to do things like changing the colour balance of your movie, adding lens flare effects and so forth. FXscript is a programming language in which you can write your own effects.

As part of my experiments I had created a filter which averages several past frames and then subtracts the result from the current frame. I then fed it some footage from the BBC's production of Middlemarch. Casaubon is walking morosely into the distance:

and there's a cut to Dr Lydgate, who is watching him depart:

And the result is what you see above.

John Dvorak on the official new name for Longhorn.

I've been reading Joel Spolsky's book "Joel on Software", which is very good. He has a lot of interesting articles on his web site, which I've read for some time, but I'm enjoying it in paper form.

One section struck me this morning:

If there's one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it's this: Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it.

He's quite right. He points out that so many software projects that fail, or deliver late, or run over budget, really boil down to this: "The customer didn't really know what they wanted, or they couldn't explain what they wanted, or they kept changing what they wanted, or we delivered exactly what they wanted and they weren't happy." (You can see the rest of this chapter on Joel's site.) I've seen an important variation of this in many startup companies. When the management guys or the VCs come on board they always talk about "changing it from being a technology-focused company to a customer-focused company", which is important. Technology for technology's sake actually can make quite a bit of money, but it's not a good business strategy. However, what the suits often forget is that where the technology is today is where the customers will be tomorrow. The customers don't know this. If you go and ask them what they'll want tomorrow, they don't know. They may know what they want today, though even that is often vague. So if you have something that can be built in a few weeks to meet their immediate needs, you have a chance. But if you're in the technology world and you're going to take a year or two to build it, remember that what they want will probably have changed by the time you're done. Take the case of internet-based telephony, for example. However low-quality, high-latency and occasionally unreliable VoIP may sometimes be at the moment, I don't think anybody with any sense doubts that it's what we'll all be using in a few years. But if you go to the vast majority of today's phone users and ask them what they want, they won't tell you much that will help you build a company in this new space. How many of those people now carrying iPods could have told you a few years ago that that was what they really wanted? Obviously, your focus must be on the customer. But in the words of Wayne Gretzky, you want to skate to where the puck is going to be, rather than where it is now. And to do that, you can't usually rely on the customers. Nor can you rely on the business guys, or the sales guys, or the marketing guys. They'll learn what the customer wants at about the same time as the customer does. No, to be ready for the future, at least to some degree, you need to be a technology-focused company.

The buzzphrase of the moment is AJAX. If you're a programmer, and you don't know about this, you will soon. It stands for Asynchronous Javascript And XML, which is an increasingly common technique for updating parts of a web page from a server without having to update the whole thing.

It's being heavily used by Google in Gmail and Google Maps, for example. And I think it my duty to keep Status-Q readers up to date with such terms so that you can casually drop them into conversations around the water cooler. "Oh no, it isn't using Flash. It's based on AJAX..."

Ruby is a language that's getting a lot of attention as a slightly cleaner and nicer alternative to Python and Perl. If you have some basic programming experience and want to learn Ruby, there's a very good tutorial here.

It's mostly used, it seems, in the Ruby on Rails framework for writing web apps.

Another goody from IT Conversations: Paul Graham on "Great Hackers". Here's a quote:

When you decide what infrastructure to use for a project, you're not just making a technical decision. You're also making a social decision, and this could be the more important of the two.

For example, if your company wants to write some software, it might seem a prudent decision to write it in Java. But if you write your program in Java, you won't be able to hire such smart people to work on it as if you wrote it in Python. And the quality of your hackers probably matters more to the success of your project than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages....

Business types prefer the most popular languages because they view languages as standards; they don't want to bet the company on Betamax. The thing about languages, though, is that they're not just standards. If you want to move bits over a network, by all means use TCP/IP. But a language isn't just a format; programming languages are mediums of expression...

Now, I'll take issue with him here a little bit. The assumption behind his argument is that the programming task is best compared to painting or creating a piece of music. Increasingly, however, it's more like engineering & can even be rather mechanical. Good engineers don't get to choose whether they work in metric or imperial units and often don't have much choice about the materials and many of the dimensions. Their skill is in creating something robust and reliable given the constraints. Ideally something that will be maintainable after they have gone. The world is certainly in a better place with Java as the dominant language for such tasks than it was when COBOL or Visual Basic had that honour, and, much as I love Python, it's probably not as good as Java for this role. Artists, on the other hand, are usually loners who can throw off the constraints because they need to accomplish a particular single task. It makes sense for them to use whatever medium they like best, even if, God forbid, that should be Perl. Paul's book is called 'Hackers and Painters, so it's natural that he should concentrate on this aspect. Python is a better language for exploration and invention. I've programmed in dozens of different languages, BTW, and in general Python is my language of choice, because it comes somewhere between the two extremes. But the best artist is one who can choose the optimal medium for his expression. And the best engineer is often one who can create the optimal expression for his medium. The real danger is that we will only train people to create nice Java boxes that fit together very neatly. This is great for building things that don't fall down. But we also need people who can think outside the boxes.

One aspect of my new situation is that I'm writing some code again, having been doing mostly managementy things for the last couple of years. It's fun to catch up.

I've been particularly impressed by Eclipse, a development environment that came from IBM originally, and has a large and growing community behind it. The recent eclipseCon conference had some influential keynote speakers, for example.

In my youth, serious programmers used the Emacs editor, which, if you could program in Lisp, could be made to do much more than just editing. There are Emacs games, mail readers, news readers and every variation of editing under the sun, all available from a few obscure keystrokes. The saying was that Emacs was "not so much an editor, more a way of life". I know people who still use it for reading news and mail.

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." - Zawinski's Law. Nowadays he would probably say "until it becomes a web browser".

Well, I think Eclipse is the new Emacs. Strictly, it's an environment for building development tools, and there are many many projects out there creating applications based around it. In more down-to-earth terms, the basic download gives you a really nice environment for Java development, and an easy system of plugins so you can get tools for other work as well - C/C++ coding, Quality Testing, GUI design, Nokia phone development, Web site creation, even COBOL programming. Eclipse is now apparently "the most popular Java IDE in North America". And it's not just because it's completely free. Having used it for the last two days, I'm very impressed.

There's an introduction to Eclipse on Apple's site, though being written in Java, it will run on most platforms. IBM even offer Eclipse Innovation Grants for people doing interesting things with it.

[Original Link]

Groovy is a scripting language for Java, and it looks as if it's appropriately named. A good introduction here. It has a lot of the best features of Python and Ruby, but integrates really well into the Java environment - Java code can be called from Groovy and vice versa very easily, the syntax is similar, with the Java rules relaxed a bit to suit the typically more informal nature of scripting, and Groovy code can be compiled into .class files and executed with the standard 'java' command. It has a neat syntax for XML/HTML generation and can be used for creating Ant scripts which are rather more readable than the standard XML.

Must find time to play with this.