The other day I was listening to someone speaking about the rollout of an open source web-filtering solution to 20,000 pupils in the Yorkshire and Humber area. A mildly interesting story in itself, and a nice win for the OSS community, but it got me thinking.
When it comes to Internet access, Why do some companies literally treat their employees like children?
One of the questions for the panel at Wednesday’s Open Source event at BT Centre concerned the fact that most of the company doesn’t have a connection to the Internet; just proxied web access. Also, installing any software not on a relatively small approved list is forbidden.
“Given that we don’t have the Internet or any software, how are we supposed to work with Open Source?”
Doc Searls‘s response:
“The current policy is freaking insane! It’s utterly inconsistent with BT’s strategy, and I can’t understand why anyone would want to come and work here… Maybe we ought to go and storm the head office or something.”
[tags]policy, internet, open source, doc searls[/tags]
I was quite excited to see the announcement of improved Ruby and Rails support in Leopard, and one of the first things I did after upgrading was to delete my MacPorts installations of Ruby and RubyGems, and try using the built-in ones instead.
For a while, all seemed well. The milk was cold, the food stayed fresh, my specs still passed, my Rails projects still worked, and even the light worked when you opened the door.
But then the trouble started.
Firstly I tried updating and installing gems while behind a firewall. The gem command completely ignored my http_proxy setting, and when I explicitly provided the proxy using -p, I got this error:
ERROR: While executing gem ... (NoMethodError)
undefined method `[]=' for #
I worked round this by downloading the gems manually and installing the local copies (despite this being a pain, especially when there are dependencies).
I then tried using gemsonrails to freeze some gems, and it got confused by the fact that Leopard stores built-in gems separately from user-installed ones. Thinking about it, if I’d successfully frozen the gem, it might have turned out to have been tweaked in some Mac-specific way and broken on other platforms.
Forgetting about that issue, I carried on with other work for a while, then found that autotest wouldn’t work, and mysteriously was trying to run something from /opt/local (where MacPorts install lived). Even after removing any gem-related scripts from /opt/local/bin, the problem persisted.
Oh well, looks like I’ll be re-installing everything using MacPorts. I’m not sure whether all these problems are intrinsic to the Ruby installation that comes with the system, or whether some are caused by lingering remains of my MacPorts installation – I’d be interested to hear how others got on.
[tags]ruby, rails, mac, 10.5, leopard[/tags]
From the list of new features coming in Rails 2.0:
It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.
Ever wondered what would happen if you mixed lolcats with PostSecret?
Another day, another argument discussion with a colleague over the common misapprehension that you can have a process with discrete requirements capture, design, development and test phases, yet somehow still claim to be agile. Once again, I tried (with limited success) to explain that you don’t need to do all your designing up front before you start writing code, and that starting to write code almost immediately isn’t ‘hacking’, provided that you are continuously paying attention to good design as you go.
In other words, agile developers do just as much designing as those still following waterfall methods, but we do it at the same time as writing the code.
Reflecting afterwards, I realised that I’ve been phrasing the message the wrong way. As anyone who really ‘gets’ test-driven (and particularly behaviour-driven) development knows, it’s not really about the testing, but about the design process. A waterfall ‘designer’ starts from an understanding of the problem and builds up some kind of model for a solution, which they then pass on to the implementors An agile developer does exactly the same, but the language they use for the model happens to be executable source code rather than documents or UML. This choice of modeling language has the rather large benefit of being testable, and once your design is finished, you’re done. No need for someone to try to interpret and implement it. No scope for misunderstandings between designer and developer. No danger that the design is incomplete, or that part of it turns out to be unworkable.
It’s not that we start writing code and design as we go along.
We are always designing – we just write the code as we go along.
[tags]agile, tdd, bdd[/tags]
Steven Fry has written a detailed comparison of smartphones on his blog. It’s quite long, but very entertaining (as you would expect) and well worth a read.
As a ‘corporate software engineer’ myself, this in particular struck a chord:
Break free, all you corporate software engineers and designers: the excuse that you are under the rule of dullards, greedy share-price number crunchers and visually and ergonomically illiterate yahoos is not good enough. Persuade them. Otherwise we all get a digital environment that’s a vile as a 60s housing estate.
Amen to that.
So I was reading Jon’s post about Paul‘s SEO talk at Barcamp Brighton, and thought I’d give the tip for finding incoming links a whirl.
I searched Yahoo for linkdomain:www.kerrybuckley.com -site:www.kerrybuckley.com, and found pretty much what I expected – my blog comments, links from a couple of other blogs, links from my profiles on sites like Twitter.
Then I found this: Apple’s new iMac: blogger reaction – Times Online.
Of all the blog comments about the new iMac, I’m not sure why he chose mine.
[tags]times,imac[/tags]
I was lucky enough to attend BarcampBrighton at the weekend, thanks to a tip-off from psd and the fact that I had to be down the road in Eastbourne today anyway for our release planning.
For those unfamiliar with the Barcamp concept (which until recently included me), no schedule is set in advance, but attendees turn up with either a prepared talk or some ideas of subjects they think people might be interested in. On Saturday morning after the introduction we each scribbled a quick description of our session on a slip of paper, and stuck it in a free slot on the agenda grids, creating an instant [un]conference with five half-hour talks happening at once for the two days.
I’m not going to try to describe everything, or I’d be here forever (after all, I still haven’t finished writing up Agile2007), but highlights included being taught how to do this card trick by nicepaul, an audience discussion (neatly driven from a tiddywiki) on whether someone should buy a Wii, and talks about subjects ranging from web site accessibility and internationalisation to geocaching. Oh, and of course the obligatory (and my first) games of Werewolf. I did a demo of Selenium, which seemed to go down well, albeit with an audience of four (it was the last session on Sunday, and I was competing with Powerpoint Karaoke).
All in all, one of the best conferences I’ve been to. Which isn’t bad for free (with food and beer thrown in)!
In some ways the event almost seemed to run itself, but obviously that was largely down to the incredible efforts of all the organisers and helpers (especially the hosts, Madgex, who gave up their offices to nearly a hundred messy geeks for the weekend). A huge thank-you to them, and to the various companies who provided mountains of food and drink during the weekend.
[tags]barcamp barcampbrighton barcampbrighton07[/tags]