Mike Zornek has produced a very nice screencast which introduces you to version control in general, and the Subversion system in particular.
Category Archives: Programming
TextMate
TextMate is a fabulous text editor for the Mac. The best way to get a feel for its capabilities and see what all the fuss is about is to look at some of the screencasts.
Here’s one about writing screenplays.
Here’s another about Python programming.
And there’s an excellent new one about how to customise it which is well-worth watching, especially if a bit of shell-scripting doesn’t disturb you.
Highly recommended.
Frameworks and Libraries
Benji Smith wrote a nice piece on Why I Hate Frameworks. Recommended reading for any coders out there, if only for amusement.
He has a follow-up amongst the comments, too, so it’s worth scrolling down a bit.
The problem with his argument, I think, is that programming always tends to move towards higher-level constructs. Assembly-language programming with macros was a great framework for those who had previously had to flick switches on the front of their PDP-8. And C offered greater productivity again, but is now considered pretty low-level. The scripting languages of yesterday become the programming languages of tomorrow.
But he draws a distinction between libraries and frameworks.
A library is something *contained* in my code. A framework is a *container* for my application.
And it’s true to say that many frameworks have come and gone which try to exert too much control over the code. (Anyone remember CASE tools?) Many frameworks put the programmer in a box and say, “Here’s where you can put your little bit of contribution to my mighty machine”. And programmers don’t like that. They like to know what’s happening when and feel that they’re in control of it.
This is the nice thing about software libraries: they’re servants which do your bidding and then return power to you. Frameworks are like big companies in which you must first find your office, and then work out what you are allowed to do in it. Both have their role. But I suspect that today’s libraries will become tomorrow’s programming languages.
Thanks to Frazer for the link. Oh, and P.S. Apple has a tendency to package up its libraries nicely and call them frameworks, but they’re still libraries in the sense of this article.
My (new) mate, TextMate
I wrote about TextMate a couple of days ago. Giles Turnbull is also a new convert.
Mac Editors
There are some very good text editors for the Mac.
SubEthaEdit is nothing short of wonderful for its collaboration features – if you haven’t tried this, you should find a friend with a Mac and do so – and it’s not at all bad as a general-purpose editor.
TextWrangler has a somewhat nostalgic Mac-classic feel to it, but has a wonderfully useful feature of being able to browse, open and save files on a remote machine via SFTP/FTP. You simply pres shift-cmd-O and shift-cmd-S instead of cmd-O and cmd-S. If, like me, you spend a lot of time editing config files and web pages on remote servers, this is very nice.
But the one I’ve recently converted to is TextMate. I’d seen people starting to rave about this app, but hadn’t quite worked out why. The more time I spent with it, though, the more I liked it, to the extent that I forked out the 39 EU to buy a license within a few days, not something I’d often do for a program that didn’t even have documentation. The Bundle system, which groups together the functionality associated with particular types of file, is very nice, and I find I’m starting to miss the various shortcuts, completion mechanisms and auto-expansions when I’m entering text into anything else.
It doesn’t have TextWrangler’s convenient access to remote files, but I’ve long been a fan of the Transmit FTP utility, and if you specify TextMate as the editor then everything’s pretty seamless.
And then this week, not only did documentation arrive, but people are starting to produce screencasts, showing how to get the most out of it. More info here.
Django and Rails
No conference which discusses the Web can consider itself cutting-edge these days unless at least a couple of the speakers make reference to Ruby on Rails. For those who haven’t come across it, Ruby is a very dynamic programming language which has been around for a long time, but because it originated in Japan, it’s taken a while to gain popularity in non-Japanese-speaking parts of the world. Rails is a framework which takes advantage of the dynamic nature of the language to map SQL databases neatly onto Ruby objects. It has scripts which create a lot of standard stub code for you, and so in general it makes it very easy to create web applications based around a SQL database back-end, which an awful lot of web apps are, nowadays.
I wrote briefly about Ruby on Rails three months ago, and since then I’ve been sipping at the kool-aid – watched the intro videos, bought a Ruby book, and played a bit with the software – but I never quite got a taste for it. Ruby is so named because it was meant to be a better PERL, and it certainly is that, but I think there’s a few too many Perl-isms still lingering in the background. Ruby enthusiasts claim that it’s a ‘pure’ object-oriented language, more like Smalltalk than most of its competitors, because everything is an object, so you can do things like calling a method on an integer:
5.upto(10) { |i| print i }
but somehow this just doesn’t feel very natural to me. You can do some lovely things in Ruby, but I don’t think a language can lay much claim to purity when it still has things like the global $_ variable from PERL.
And so I’ve been very pleased to discover Django, which is a very similar framework that slightly pre-dates Ruby on Rails, and which is based on Python rather than Ruby. Python has been one of my favourite languages for a long time – I first used it in 1991 – and to my mind it’s rather nicer than Ruby for most things. It’s much more widely known, and all the benchmarks I’ve seen also show Python as rather faster than Ruby, and Django as higher-performance than Rails.
Django works the opposite way to Rails; you create particular kinds of objects in Python and run a script which produces the SQL tables which store them for you. In practice this doesn’t make a huge difference. The Rails approach can be more flexible, but with Django’s you get all your canonical source code in the same language. They both have their merits. But the default framework that Django produces is much more useful than anything you get for free with Rails; it provides quite a nice ‘admin’ interface which you can start using immediately for entering data without grimacing too much about the user interface.
My wife Rose needed to store some data in several related tables and access them from home and from the University. In one day I was able to take her data, which was mostly in tables in Word documents and get it via Excel, text files, and some Python scripts into a MySQL database. Django provided the web front end and by the end of the day she was entering her data via her browser into a set of inter-related tables with various conditions attached. I was working in the next room and from time to time I’d come in and say – “Look – there’s a search box now!”.
Remember that this was my first attempt at using the platform. Now, of course, I’ll be tinkering with it for ages, but the ability to get something up and running and useful so quickly is a great tribute to Django’s design. I also have a feeling, though I haven’t tested this yet, that much of Django might be more useful than Rails for any web apps which are not based on a SQL database.
Anyway – highly recommended.
The Art of Computer Programming?
Thanks to Martin for pointing me at these amazing computer-generated pictures by Jared Tarbell.
As well as being beautiful, most of them come in Java applet form, so you can watch them being generated on your own machine, and they’re also accompanied by source code.
Specifications
I’m reading a book edited by Joel Spolsky and came across this nice footnote:
This reminds me of my rule: if you can’t understand the spec for a new technology, don’t worry; nobody else will understand it either, and the technology won’t be important.
Mac OS X and Subversion
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.
Modern Art?
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.
Drive me crazy
I powered up all my Firewire drives today. I don’t often do that.
Keep the customer satisfied
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.
Feeds
RSS feed© Copyright Quentin Stafford-Fraser
Recent Comments