mo:Blog (updated)

Monday, October 24, 2005

up until now I have used hblogger for writing and uploading from my Palm. MO:BLOG, from Tektonica, is an interesting alternative, first because it seems to support MovableType better than hblogger, and second because the interface is cleaner. It also seems to work over GPRS, unlike hblogger. So let's see how well it works... UPDATE: well, it works quite well. There are some flaws: retrieving blog ids from MovableType's XMLRPC API doesn't work correctly, or possibly they're not displayed correctly: the titles are associated with the wrong IDs. Retrieving categories does work, however. You can set titles, unlike in hblogger, which is a major plus. However, the interface is a little weird at first. There is one huge usability blunder, which is that you can easily lose a newly entered blog entry by clicking on the "back" (to list) icon before you click on "save". This should not happen, without a warning, in any application on any platform, but especially not on a PalmOS device. Also, whilst categories are useful, the way they are used is very clumsy. You cannot associate a category with an entry, but rather you have to (or can) select a category for a blog. You could, I suppose, define as many blogs as you have categories, and select the appropriate one when you write an entry, but this is very clumsy and seems totally out of step with an otherwise well thought out application. Image and attachment uploading is easy to configure, and a very nice file browser is included which makes selecting attachments easy (with hblogger you're flying blind). However, the dual process of selecting a file to upload and adding the link to the entry is a bit clumsy. Although mo:blog seems to be actively developed, getting in touch with support is far from simple. The only route seems to be via a Yahoo forum (which I loathe), for which you have to be registered to browse, and you have to request approval to register. I requested approval around 12 hours ago, so far no reply. This is not very confidence building. At least you can register yourself for hblogger's Yahoo forum, although the apparent total lack of development by Normsoft makes it pretty pointless. But in summary, you can reliably use mo:blog to post to MovableType from a Palm device without needing to do any clearing up afterwards, and therefore I recommend it. NB - side note ... the title of this post has been changed from MO:BLOG to MOBLOG, because the ":" made the MovableType MTFeeds plugin barf... Took me ages to track down. UPDATE AGAIN - I've replaced the MTFeeds stuff with some beautifully hand crafted Perl, which now allows me to reinstate the post title in its full glory

MovableType Trackback Spam

Sunday, October 23, 2005

In the last couple of days, a new deluge of trackback spams has flooded my site. Whilst the MovableType MT-Blacklist plug-in allows me to filter them out, I'm still getting an alert email for each spam, which is almost as bad as the spam itself. Since in any case the actual value of trackbacks is very limited, outside of the self-congratulary Californian blogging community, and I've never received a single one, I decided to disable them globally. It is perhaps indicative of the above community's mentality, which MovavbleType is such a part of, that the interface has no global switch to disable trackbacks - how could one ever want to completely turn off this "oooh, look, someone's talking about clever me" feature. Even Jay Allen's "Hacking Movable Type", which contains all sorts of esoteric (and often largely pointless) stuff, doesn't give a hint. However, a quick look at the MT database reveals what seems to be a SQL solution (globally for an installation - all blogs. For individual blogs, you have to add a blog_id WHERE clause): UPDATE mt_entry SET entry_allow_pings = 0 WHERE entry_allow_pings = 1; Then, probably, rebuild each blog. And you're done.

All Those Macs Ago

Thursday, October 06, 2005

I've just sold my "old" Mac, A G4 "Quicksilver" (merci, Alberto) with a number of upgrades, including a dual processor card. This got me thinking about it's ancestors, and what, if any, genuine progress comes from the ever accelerating technology landslide. The first computer I ever paid for myself was a Mac PowerPC 7200. If I remember correctly it had a massive 16Mb of RAM and a huge 80Mb disk drive. It ran MacOS 7.5.3, possibly the nadir of the Mac OS. For something like 6 months after buying it, I could not print to my Tektronix inkjet - the computer froze when I tried. I was one of several irate early adopters of eWorld complaining vociferously about this. Apple UK even wrote to me to complain...then sent an engineer to check it, in full knowledge, I'm sure that this was a total waste of time. Apple fixed it, eventually. The 7200 was the first Mac I bought, but not the first I used. I had a Powerbook Duo 230 at work at the time, and used that at home in it's dock. At the time I was mainly using the Mac for illustration, using Photoshop et al. I can remember things like going off to watch TV for an hour whilst the computer struggled to rotate a 10Mb image... The 7200 was replaced some time later by an 8600AV, a pretty good machine, which served me well for some years, and which I also used for video editing and as part of a music studio. I sold the 7200, but the 8600, upgraded with a G3 processor, lived on for years, finally using OS X Server 10.1 to run the public website of Vilkas Ltd, until the company closed in late 2004. I'm not sure where the 8600 ended up... When you consider that an 8600 is more less a contemporary of the first Pentium PCs, its longevity is pretty amazing. In parallel with the dektop machines, I also have had a series of laptops, starting with a second hand Duo 280, a tiny device, smaller I think than the current 12 inch Powerbook. This wasn't quite up to the multimedia tasks I started needing to do, so I replaced it with one of the first Powerbook G3s, which lasted me over 5 years. I acquired the G4 that I just sold in 2000, along with an Apple Cinema Display which cost more than the computer. At the time, I was briefly having money thrown at me by a dot com, which allowed me to indulge. The main use of my personal systems by then had become photography, and when I started to scan panoramic and medium format film, the 300Mb files I was producing were beginning to choke Photoshop. Also, I could not work in 16 bit mode without extreme reserves of patience. I upgraded the processor to a dual 1.2Ghz, which helped, but it still wasn't perfect. So finally I did what I'd never done before, and bought a top end system, a G5 with dual 2.5Ghz processors. So far, I am pleased to say, this has coped with everything I've thrown at it. On the laptop side, the G3 Powerbook was replaced by a 1Ghz TiBook in early 2004. Despite me nearly destroying it when it was two weeks old, it remains a trusty sidekick. Of course, the mountains of accessories and software should not be forgotten. Nor should the Newtons, a 120 and a 2100, and their accessories and software. I don't suppose the story ends here either. I'd love a smaller, lighter laptop... So has anything changed ? Well yes, basically. In the early days, there is no doubt that I frequently ran up against the limits of the machines. The G5 now rarely if ever gets flustered. I can handle image files over 1Gb with not too much hassle. I can't imagine a time where the G5 feels slow, but perhaps it will come. I do think the curve is flattening, although I daresay the next version of Photoshop will be even more demanding. Whatever, I'm fairly sure the next desktop system I buy will have an Intel processor in it. I don't know if anybody reads this stuff, but if you'll read this you'll read anything Thanks anyway - now go and have a look at something far more worthwhile.

The Art of Project Management

Wednesday, September 21, 2005

I really wanted to like this book. There is most certainly a place for a different angle on project management, other than the usual "how to use Microsoft Project" or other dry-as-dust doorstops, and Scott Berkun's "The Art of Project Management " enthusiastically tries to fill it. However, the informal, rambling and slightly egocentric style that he deploys to very good effect on his website writings gets irritating and doesn't scale to a book. I kept finding myself quietly screaming "Get To The Point!". "The art of project management" really boils down to a thinly disguised autobiography of Scott's time with Microsoft. From other articles it seems that either his heart wasn't really in it at Microsoft, or he has resolutely moved on, realizing that to deny his creative side was getting him nowhere (and apart from the paycheck, what satisfaction could anyone derive from managing a piece of such insipid bloatware as Microsoft Internet Explorer ?). I fully empathise with him on this, but not to the extent that I'm going to read his book with blinkers on. The main problem is that there are far too many glib, superficial observations on the dynamics of software development teams dressed up as profundity (actually, this reminds me of a far better book, also from a Microsoft staffer: Jim McCarthy's classic "Dynamics of Software Development", which should be required reading for anybody in any software company anywhere). There are just too many "so what" moments in Scott's book, and very little real creative thinking. I could take specific issue with a number of points ? just one example would be that the "basic" functional requirement he uses to illustrate a point, "There will be a barn and it must be green", it just wrong. It describes an implementation, not a user need. It would be better expressed as a series of statements "there shall be a covered space", "the covered space shall not be heated", etc, which would then lead to the solution space he talks about. But in any case, this is in the domain of requirements management, not project management, and it is hardly the only substantive digression. The text itself is full of minor digressions and little jokes, which start off ok, but get a little old very quickly. It is also illustrated with sketchy type diagrams, which look cute but convey nothing, and random photographs, a bit like Phil Greenspun's "Phil and Alex's Guide to Web Publishing", but nowhere near as good ? or indeed upfront (Greenspun declares openly that the photos are totally irrelevant). Actually, I get the feeling that Scott is a bit of a Phil Greenspun wannabe ? well so was I once, and there are plenty of others out there. Clearly Scott wanted to write, and the most marketable topic was going to be something like this that he could flog to O'Reilly. And clearly, there is a subject here to be written about in a new way. But to be honest, whilst I find his website very useful, and inspirational in places, and I'm sure I'd like him personally, I'm afraid the book is a total dud. With firmer editing and mentoring from a stronger publisher, he might have turned out a classic, but then again, since one gets the impression that despite what he says he couldn't wait to escape from Microsoft, I have my doubts. Perhaps he'll write the Great American Novel one day, but he'll have to tidy up his prose first

Use Cases: Requirements in Context

Friday, August 19, 2005

"Use Cases: Requirements in Context", by Daryl Kulak and Eamonn Guiney, professes to present a radical approach to gathering and defining software requirements, employing only Use Cases. Whilst many other writers embrace Use Cases as an important part of a requirements engineering process, here the authors take it all the way, and claim that not only is there no other workable alternative, but that any dilution by including other methods, such as narrative based approaches, is unacceptable. They take no prisoners, stomping all over Alistair Cockburn's notion of Use Case hierarchies (which I've always found a bit clumsy, to be honest), and generally being irreverent about everything else. It is quite entertaining, and presents an interesting thesis. Unfortunately, it is also appallingly edited, inconsistent, not terribly well written, and lacking in detail at crucial points. For example in section 2.3.4, the text refers to a sample Use Case which has nothing to do with the scenario under discussion, nominally based on this Use Case. However, on the next page, the discussion abruptly switches to something which seems relevant to the Use Case, but is a total non-sequitur in the text. There are many such examples of bad editing throughout the book. A really serious snafu comes on page 85: "NOTE: In the first edition of this book, we advocated a tool called system context level use case ? we formally disavow this technique in this new edition". Rather a pity, because in Section 4.4, Deliverables, we're told that the Facade iteration is complete when, amongst other things, a system context use case is documented. Whoops! In section 5.2, we're told that system context use case diagram shows the big picture, and each package's diagram will contain the detail for each set of use cases. Try "Find and Replace" in your word processor, chaps. It can be a surprisingly useful tool. Another irritating habit found in several places is introducing an interesting sounding concept and then failing to explain it properly. For example, the idea that non-functional requirements can be captured as Use Case stereotypes is, well, interesting ? but just one single example might help to convince the more sceptical reader. Equally, the much heralded "hierarchy killer" tool remains a complete mystery to me. It could be an interesting idea, but the author's writing skills do not reach a level where the odd example or diagram would not help a bit. However, if you are interested in the sharp end of requirements engineering, I do recommend you read the book, with the proviso to not treat it as gospel. It is provocative, sometimes funny, quite often entertaining, but the various errors and inconsistencies are jarring and left me rather disappointed. I did not believe that Use Cases offer a 100% proof solution to requirements definition, and I still don't, but in at least 80% of situations they work well, and this book provides some very valuable insights into applying them effectively. Publisher: Addison Wesley Pub Date: July 25, 2003 ISBN: 0-321-15498-3