Skip to content

Your 140 Seconds

I gave a talk about Adhearsion, the Ruby VoIP framework that interfaces with Asterisk, to ScotRUG. You can see the video on Vimeo. The talk wasn’t too well-prepared, in particular I hadn’t tested to see if Asterisk was working properly on my netbook. Of course, it wasn’t, and so I couldn’t do a demo.

The main application I’m building with Adhearsion’s not ready yet, so I decided to build something quickly that I could use to show how Adhearsion works. Hopefully it’ll be a fun little app/toy in its own right, too.

Your 140 Seconds lets you call up a number (0131 512 0050) and post up to 140 seconds of audio to a shared Twitter account @y140s. There’s no users, no identification (other than an area code extracted from the caller ID), just 140 seconds of randomness. It should be fun.

It’s been a good project for me – it’s helped a lot for pinning down what I’ll need for deploying the other project, and it’s always nice to actually finish something.

The source code is on GitHub, with some notes on deployment in assets/notes.

Adhearsion’s a great framework and doesn’t require that much Asterisk configuration. I’m going to go over how y140s is set up here.

I’m using phone numbers supplied by UKDDI. They have options for logging into their SIP server as if you were a remote client, which matches how I’ve used Asterisk/Adhearsion before with SIPGate and Gizmo5. More interestingly, they also have options for sending the calls directly to your SIP server. This keeps the configuration needed down quite a bit. In fact, you should be able to get away with one change to sip.conf and one new stanza in extensions.conf.

In extensions.conf:

[adhearsion]
exten => 666,1,AGI(agi://127.0.0.1)
exten => 666,n,Hangup

This takes any call to extension 666 and punts it to Adhearsion, then hangs up if Adhearsion happens to return the call control back. (Normally you’ll want to tell Adhearsion to explicitly hang up in your app, since you’ll be handling the whole call flow there.)

You’ll also need to ‘include’ it in the default context – the default file includes the ‘demo’ context, just switch it out there.

On the UKDDI site, you’ll need to set your routing to something like sip:666@your.server.net, where the extension used matches whatever you picked in extensions.conf

In sip.conf all you need to do is change the default context for incoming calls from ‘default’ to ‘adhearsion’. This is set right at the start of the [general] stanza. Adhearsion expects to find a block for the context the call is being made in, like this:

adhearsion {
...
}

If the context doesn’t match anything in dialplan.rb the call will fail, so it’s really important to get the contexts matching.

On receiving a call, Adhearsion executes the contents of that block. There’s some special methods you get (like play, record, and menu) and you can call your own functions too.

The menu function is how you do IVR menus – it has an extra over standard Asterisk in that the menus can be interrupted while playing prompts. It uses call-backs defined outside of the main block (on_save, on_retry in this example) or each option can call a block in-line (as seen for on_invalid).

In this example app I’m not using the Rails integration, but it’s as simple as putting a line like this in config/startup.rb:

config.enable_rails :path => '../webapp', :env => :development

There’s more notes on the GitHub project, including the details of a little bit of hoop-jumping required to get beanstalkd working on Ubuntu 8.04.

If you’ve not used message queuing before, now’s the time to start. By default, adhearsion throws an exception and dies when a caller hands up on you, so if you’ve not done your background processing before then it’ll never get done. Also, if you think people are impatient waiting on a web page to load while you do processing during the request cycle, imagine how much worse they are waiting on the phone?

If the call goes quiet for too long, they’re likely to assume that it’s failed and hang up – so it’s really vital that you keep it responsive by firing things off for processing elsewhere. Beanstalkd is a really lightweight system, which suits me. In a Rails app I’d just use delayed_job, and I am on my other telephony app, but it’s a bit of a pain to use without Rails.

My mechanism for picking items off the queue is really basic – a cron job calls a rake task once a minute. It’s simple and it works. It doesn’t scale very well, but if I’m seeing more than sixty calls an hour then other parts of the system will probably fall over first.

Overall, I’m quite pleased with this little app. It’s a good example of how things hook together when you’re using adhearsion and it’s been really useful for helping me consider deployment strategies for larger telephony applications. It’s definitely not perfect, so if anyone spots any bugs or has any suggests, please let me know – or even better, fork it on GitHub and send a pull request!

Posted 01 March 2010 † John § Adhearsion § Ruby § Software § Technology § Telephony ‡ Comments (0) °

Why the iPad makes me sad.

Apple launched the iPad and it was pretty much exactly what everyone was expecting. Depending on what model you buy it’s either a giant iPod touch or a giant iPhone, and I agree with Fraser Speirs – it’s the future of general-purpose computing devices.

And that makes me so sad.

I touched on the reason why in my article about ‘open sourcery‘ – I want to see a world where understanding the machines we use every day is common rather than extraordinary. I want to see a future where people – ordinary people, not computer geeks – can create their own tools for whatever purpose they have.

The iPad future promises general purpose computing devices that are much easier to use, but which are completely impenetrable. At the moment you still need a ‘normal’ computer to use an iPad, but that won’t be the case for very long. Once people buy iPad-like devices instead of a traditional desktop or laptop computer you’ll have a class of computer users who can never learn to make their own tools, even if they wanted to.

We exist in a world full of machines, mechanisms, and devices that almost all of us do not understand. We can barely grasp the basic principles of how these things function, let alone the details of any specific implementation. Do you know how common-rail fuel injection in a diesel car works? I don’t. I don’t even know how beer works. Most people have a terrible understanding of simple mechanical principles. I only learned about the Geneva wheel the other day, and I was struck by how elegant a design it was. It’s used in film projectors and mechanical watches – more things that I don’t really know how they work. Until I read about the Geneva wheel I’d never even thought about the need for a frame of film to stay still for a fraction of a second while running through the projector.

There’s a ‘hardware hacking’ movement that’s trying to encourage people to void their warranties and open up closed devices to learn how they work. Working on hardware is difficult, and there’s always the risk that you could permanently destroy some expensive piece of hardware. I can understand why no one knows how common-rail fuel injection works – who wants to poke around in their car? It’s all dirty, and if you poke the wrong thing you’re going to have to call the AA to tow you to a garage to get it fixed. Hardware hacking is inevitably going to be a niche. I can accept that.

Software hacking is much simpler. It’s much harder to do permanent damage to something. It’s much more accessible – you can do it indoors, you don’t need to risk setting the curtains on fire with a soldering iron, you don’t even need to buy anything – if your computer doesn’t come with a programming language you can download all sorts of things for free that will get you started.

Writing software tools is hugely accessible. In the ‘open sourcery’ article I point to the Organisation for Transformative Works and their Archive of Our Own project, and I think this is a brilliant example of how a community of non-computer-geeks (albeit a community of generally well-educated non-computer-geeks) can create tools which empower their community. There’s plenty of existing software and websites they could have used, but they wanted to create something which was designed specifically to suit their community. They wanted to make it themselves, and because of the astounding quality of the open source tools available they were able to do it.

They’ve turned a bunch of writers into software hackers, letting them take control over the computer in a way that will be impossible in the future promised by the iPad. A future that makes software hacking as hard as hardware hacking. A future where to write your own tools you need to buy a computer capable of running development tools. That will be a device restricted to professionals and hard-core hobbyists only, like the tools you find in a garage.

In the iPad future owning what we call a computer today would be like having your own welding kit. Yeah, some people do, but not normal people. Normal people would just burn their arm off if they tried to use it. Normal people leave that to trained professionals.

The idea of ’software’ – a complex tool that doesn’t exist in a physical form – is still very new. It’s completely different to the kind of tools we’re used to, this is why so much software pretends to be hardware – you have a ‘trash’, ‘paintbrushes’, little pictures of film reels and photo frames all over the place. The visual metaphors which have been used to make this entirely new concept accessible have tricked everyone into thinking that software is in any way like hardware. It’s not.

There is (essentially) no cost to copying software, to making small iterative changes. There’s no materials cost to trying out a new way of making a tool. If you want to take an existing tool and reshape it to do something different you don’t have to lose the existing tool. The cost of entry is extraordinarily low – a simple tutorial and a couple of downloads and you can make a simple tool. You’re not limited in the same way that physical objects are. Except in the iPad future.

In the iPad future software is just like hardware – it’s restricted and difficult to work with. You need to buy a bunch of weird stuff just to get started, and you can’t share what you’ve made with anyone unless it gets approved or you make a web application (and then you need a server and have to learn a thousand fiddly sysadmin tasks to get going – the cost of entry isn’t any lower there). It takes away, forever, the unique ability of software that can enable communities and individuals to create something of their own.

If someone released an iPad-clone with, say, Ruby on it, a decent text editor, a terminal application, and access to the filesystem it would pretty much eliminate my concerns. It could be used to create all manner of custom tools and it would be awesome. Except that it would also break the core changes that makes the iPad the future of general purpose computing: the control and simplicity. The single-application simplicity would make writing tools very difficult; the restriction on background processes – which is essential to keeping the system functioning at a ‘it just works’ level – would be horribly broken; the application restrictions that eliminate most malware risks would be lost; the whole system would fall apart and it would just be a very pretty old-style computer.

The iPad future doesn’t stop the normal person from creating new tools as a side-effect, it’s an intrinsic part of the entire concept. It forces software to behave like hardware because not even Apple have been able to find a way to make computers reliable without also making them unalterable black boxes.

As a device I think that iPad looks ace, as a concept I think it’s going to push the iPhone revolution into the mainstream computer space. I think that the people saying that this might change the world are absolutely correct and because that means the end of this brief period where software could enable and empower normal people, it makes me very, very sad.

Posted 30 January 2010 † John § Hardware § Social § Software § Technology § Technopaganism ‡ Comments (1) °

Scraping the money together.

I have a mortgage with Northern Rock, a UK bank which collapsed (triggering the first run on a UK bank) a couple of months after we got our mortgage. It’s a bit of a nightmare, and one of the (many) things that I lie in bed thinking about at 3am when I should be sleeping.

Northern Rock are splitting into two parts – one which will continue to trade as a normal bank and one which will hold all their crappy mortgages, but won’t be able to lend out any new money. They’re trying to get people to remortgage and move away from the ‘bad’ bank.

Obviously my mortgage is going to the ‘bad’ bank, and while their current standard variable rate (SVR) is about 2% less than the fixed rate we have at the moment, we expect this to rise rapidly over the coming months.

Our fixed rate ends in August 2012 and it’s probably not practical for us to move our mortgage elsewhere for several annoying reasons. As a result we’ll have to just suck up whatever Evil Northern Rock’s SVR is in 2012, and if it’s more than we can afford then we’ll lose the house.

So the SVR of Northern Rock Asset Management is suddenly of vital interest to me. Wouldn’t it be useful if I could somehow track this, perhaps by having Twitter tell me when it changes?

You can see where this is going, right?

Using the power of Nokogiri and SelectorGadget it’s really hugely easy to screen-scrape data off of a single page. A simple regex and application of the Twitter gem and now I’ve got a script that can be easily called from the crontab every night to see if the interest rate’s changed.

There’s actually a lot of people in the same situation as me, so maybe some others will find this useful. Even if it’s just me, it’ll let me know exactly how screwed I am and it was nice to play with screen-scraping and see how easy it was. (Easy, at least, until they change that page. The inevitable fail of screen-scraping.)

The Twitter account is NorthernRockSVR and I’ve put the code up as a gist on GitHub:

Posted 10 January 2010 † John § Money § Ruby § Software § Technology ‡ Comments (0) °

Trapping ideas

Like most people, I have ideas pop into my head which seem like they’re ZOMGAWESOME and will make me eleventy million pounds. Also like most people, I don’t take any steps to realise almost all of those ideas.

This year I want to try to realise more of them. While I’m pretty sure that none of them will make me an eleventy-millionaire, I’m hopeful that some of them will be financially profitable, some of them will be socially rewarding, and some of them will be interesting projects. Maybe even one of them will be all three!

My instinct is that the first thing I should do is write out all the idea fragments in my head, perhaps making use of a TiddlyWiki or two. I’m not going to do that just yet, though. Thinking back I’ve noticed that if I commit my ideas to the written word, I frequently lose interest in them. I’m not really sure why – maybe the act of documenting them is enough for me to feel I’ve expressed them, and implementation doesn’t matter? I don’t really know why this happens, but I do know that I need to follow through on some of these ideas and I can’t afford to go ‘blah’ on them just because I wrote stuff down.

By leaving the ideas in my head it’s harder to properly define them, and cool product concepts (like the two I just had in the shower) might be totally forgotten. But I’d rather lose out on a specific idea or concept if it helps to force me to implement enough of an idea to keep interested in working on it.

After all, the odds are that most of my ideas are crap – 90% of everything is crap – so it’s no great loss anyway.

If I actually follow through on any of this, I’ll post the results here. If 2010 is another year of under 20 posts, then I’ve probably not ‘realised’ many ideas. Either that or I’m too busy realising ideas to write about it, but that seems unlikely.

Posted 02 January 2010 † John § Mind Tricks § Psychology ‡ Comments (0) °

Scotfail.

A warning, gentle reader: this post is filed in the category ’swear-filled ranting’. When I say ’swear-filled’, I don’t mean I say ‘gosh-darned’ a lot. My goal here is The Thick Of It-level swearing. This particular post is the result of First Scotrail deciding that trains don’t need to run on time or finish their route, and that it’s fine to not actually tell passengers that the train they’re sitting on has been cancelled until after the doors have been locked and the conductor has left. I’ve written them a letter expressing my incandescent rage.

Continue Reading »

Posted 15 December 2009 † John § Swear-filled ranting ‡ Comments (6) °

Xen, LVM, CentOS, and a large hammer.

At work we’ve been trying to do more comprehensive release testing, on the basis that it’s a Good Idea to make sure our stuff works. Part of this is testing the deploy process.

Our software is installed into Linux appliance servers that are used specifically for this one purpose. One of our products works well enough in a VM that we have lots of customers deploying to virtual hardware instead of a physical machine, but another product is well-known to choke and die if run under virtualisation.

This is a huge pain for release testing, because what you really want to do is make a VM with a bare OS install, take a snapshot, and be able to roll back to that snapshot after each attempt at running the install tests.

Ideally you’d even want to be able to let the testers and developers do the rolling back without having to bother a sysadmin to go onto the VM host and do it for them.

Internally we use VMware exclusively for our VM hosting. We’ve got all sorts of different versions of it in use, but we’re a VMware-only shop. I’ve been happy with that – before I started working here I had only used Xen, so it’s been really good to get broader experience with another virtualisation platform. All of our various VMware set-ups have one thing in common: they’re all using file-backed virtual disks. I suspected that this might be what’s stopping our other big product from working in a VM. I also happen to know, from my experience with Xybur, that you can quite easily configure Xen to use physical disk partitions, and that you can use LVM to provide instant snapshots of those partitions.

Seemed simple at this point, but a couple of complications have left me wondering about the place of Xen for places that want virtualisation but aren’t setting up their own massive ‘cloud’.

First up, I couldn’t use Ubuntu for the dom0/host OS. Given the very specific use this system was being designed for I would have got around our blanket ban on using Ubuntu for non-desktop systems (mandated due to an SSH security vulnerability last year), but Ubuntu don’t provide a dom0 kernel any more anyway. They haven’t for some time, which is quite worrying – and may leave me having to use CentOS for my dom0 when I replace my own VM host.

CentOS 5 has support for Xen out of the box, and even ships with some nice tools to make it easy to manage. We use CentOS 4 for our application servers, so it seemed like a reasonable choice.

If you’ve been used to using Ubuntu and xen-tools then CentOS will be a bit weird at first. virt-manager is pretty good, but I found it difficult to create a paravirtualised VM from our netboot/kickstart setup. I quickly switched to creating a HVM (hardware VM, or fully virtualised machine) VM which I could netboot and install in our usual manner. At this point I was using the GUI virt-manager tool (with forwarded X11 over SSH from my hackintosh netboot, which I use as my main work machine now), which I found a bit glitchy – sometimes it wouldn’t release the keyboard/mouse and I had to use command-tab to switch out of X11.app on my Mac to Terminal so I could kill the SSH connection. I will say this: having access to the VGA console was invaluable and made using our existing netboot install process possible, which was a big win.

So I’ve got an LVM partition with a fully virtualised machine on it. So far, so good, right? Not quite. When you create a HVM Xen VM using these tools, it treats the partition you pass as a whole block device (think /dev/sda) instead of a partition (like /dev/sda1). If you manually tweak the Xen config file to pass through specific partitions, the VM won’t see them. virt-manager also defaults to creating /dev/hdX devices instead of /dev/sdX, which made the install process’s disk access slow until I caught it. I don’t know why it does that – is it something to placate crappy versions of Windows? Whatever the reason, it’s as annoying as HP’s servers defaulting to IDE mode instead of SATA. (Which they do. And it’s really annoying.)

You can’t mount the HVM partition as normal because it has a partition map, bootloader, and probably other stuff on it. This is less than awesome, since I was planning to turn it into a paravirtualised VM and pass it through as a partition with a separate LVM partition for swap.

In the end I found some documentation which helped and I got the partition mounted. To make it work as a standard partition I resorted to a brute-force cp -a to another, normal, ext3 LVM partition. I suspect I could have done something clever with dd, but this worked and was quick enough.

The CentOS wiki has some excellent documentation on turning a physical machine into a Xen VM. The same holds true for turning a fully virtualised VM into a paravirtualised one, and after following that guide I was able to boot up my test VM as a paravirtualised domU. I was also left quite impressed with pygrub, and I’m considering upgrading Xen on my own host so I can use it.

It was at this point I realised that I’d selected the wrong netboot option (I’d picked the one that does an unattended install of one of our products, instead of just installing the OS and nothing more) and had to do it all over again. Such is life.

Once I had the correct base OS image created it was really simple to write a quick shell script to automate turning off the VM, deleting its disk, creating a new disk as a snapshot of the base image, and turning the VM back on. A non-root user has been set up with sudo access just to that script, so our testers and developers can tear it down and rebuild it whenever they like.

A quick test by one of our developers showed that the system was performing as well as it would on the bare hardware – which wasn’t actually all that well since I was using a scavenged under-powered machine to build a proof-of-concept, but it’s enough for install testing, and much better than we’d see on one of our VMware hosts.

All that’s left is proper documentation and to find some more RAM for the scavenged box, and it’s ready for our next cycle of release testing. If it works out there, we might even use it to replace the VMware VM we use for our other main product – that way the testers have control over rolling it back and don’t need to wait until a sysadmin has time for it.

As happy as I am with what I’ve ended up with, it wasn’t straightforward. Creating a paravirtualised VM was difficult, the fully virtualised one had awkward disk requirements, and the whole experience – even using the GUI tools – wasn’t as slick as VMware. I wouldn’t be comfortable asking our client installations team to set up VMs using virt-manager but we do ask them to set up Windows VMs using VMware Workstation and VMware Server.

I really like Xen. It’s fast and it’s nicer to manage from the command-line than VMware. But this experience has left me wondering if it’s really a viable option if you’re not building up a custom virtualisation system? If someone just wanted to consolidate a bunch of servers, I’d tell them to use VMware, not Xen.

Posted 04 December 2009 † John § Software § Technology § Testing § VMWare § Virtualisation § Xen ‡ Comments (0) °

Twittermancy and Open Sourcery

This article was originally published at Witchvox.

At times, Technopaganism can seem like an almost invisible niche of Paganism. Mainstream books and online resources nearly always have a very heavy pastoral or rural slant and it can be very difficult to find real examples of everyday Technopagan practices. To help counter this, I am going to present both the use and source code of one tool I’ve developed – Twittermancy, available at http://twittermancy.com.

Twittermancy is a form of divination, which is somewhat akin to traditional bibliomancy. The idea is to generate a bunch of text, which you can then interpret according to the situation. In bibliomancy you might open up a book to a random page and pick a random line to start reading from. With Twittermancy you give the site a focus word and it generates a few lines of text based on what people have posted to the Twitter microblogging service. Twitter has hundreds of thousands of users posting a total of over three million messages per day, so this provides an excellent source of fresh text to pick from.

The ease with which we can generate ‘randomness’ – or ‘entropy’, as it’s known in cryptography jargon – is one of the strengths of using modern methods for producing material to interpret for divination. The key to divination is to have a suitably random source that your brain can use to see a connection between the seemingly disparate elements. Producing non-repeating randomness quickly can be difficult using traditional means.

A common example of real-world randomness, clouds, are a great source of randomness but they change relatively slowly. This makes it difficult to do multiple readings from the same source of randomness. In turn this makes it difficult to ‘ask’ follow-up questions or explore other lines of thinking.

Systems that do allow for a high degree of non-repeating randomness have tended to come with a well-defined stock of interpretations. For instance, I learned to use tarot cards from a book and have found that between the learnt interpretations and the overly-specific imagery it is very difficult to move to a more fluid interpretation. A system that produces just free text leaves me able to interpret the results using all my experience of language and meaning, which is much broader than the relatively static interpretations available through tarot cards.

Generating random free-form text quickly and without repeating elements is extremely difficult using traditional means. Bibliomancy is effective, but using the same text too frequently will bias the results and not every book is really suitable.

However, using a computer for this is easy, because there is a huge amount of text available through social networking services like Facebook, blogging/microblogging services like Twitter, and text search engines such as Google.

Beyond this the study of entropy is a vital part of cryptography (the use of encryption to protect data) . Cryptography is vital for the existence of the commercial Internet, so there are many good sources of randomness available on every computer. They can be harnessed to feed into different kinds of output, such as generating random pictures or text.

In addition to being available for use at http://twittermancy.com, I’ve also made the source code to the Twittermancy site available on GitHub – a service which hosts computer source code. It can be accessed at http://github.com/johnd/Twittermancy/tree/master.

Twittermancy is written in Ruby, a programming language that is quite easy to pick up and is growing in popularity as a web development language. Making the source code available allows other people to make their own customized – and improved! – versions of Twittermancy, or to take parts of the base idea and adapt them to other services or purposes.

The use of open source is absolutely essential for the growth and health of the Technopagan community. People drawn to Technopaganism are more likely to already be familiar with the concepts behind open source development. Primarily this means the idea of ‘viral’ licenses that allow you to reuse and modify code, but only if you release your new version under the same terms as the original code. This ensures that people who benefit from open source code contribute back to the community by publishing their improvements and alterations.

At its best, this can create a ‘virtuous cycle’ where the improvements to a project cause it to become more popular, which in turn causes more people to work on and improve the project. When this happens a project can undergo rapid evolution and can produce some really excellent tools.

If this were to happen with Technopagan tools, we could create new techniques and methods which Technopagan developers can adapt and customize to their specific needs but which could also be deployed more widely in more generic forms so that the entire community can benefit. This includes more traditional Pagan and Witchcraft communities, as Twittermancy can prove useful to anyone who is interested in divination!

I hope that Twittermancy can represent a new generation of Technopagan tools – tools which are easily usable by the entire Pagan community, but which can be adapted by the Technopagan community to produce new and interesting tools, which themselves will be available for use and further adaptation. By having a working tool to start from, I hope to make it easier for people new to Technopaganism and software development to start to create their own tools.

Programming a computer can be an incredibly empowering experience. Computers are the most complex machines we interact with and for most people they represent an unknowable ‘black box’. However, for me an important part of Technopaganism is being able to open the box and understand how it works. Being able to make your ideas reality can give you a huge sense of accomplishment and personal power – programming is not an unreachable goal!

An example of a community that has done this is the Organisation for Transformative Works. Their project to create a fanwork archive (http://transformativeworks.org/projects/archive) brought together many people who were interested in seeing the project succeed, but did not have any experience in creating this kind of software. Their developer community largely learned from each other and, almost uniquely for an open source project, have a majority of female participants.

The OTW are an excellent example of how people who traditionally would not have attempted to take control over the ‘black box’ were able to crack it open and learn to control it. They also chose Ruby to base their system on, and I believe that the accessibility of the Ruby programming language has been a major contributing factor to their success.

The Pagan community at large tends to have experience with cracking open things that are supposed to be ‘unknowable’. I see no reason why the wider Pagan community, which has a similar demographic make up to the OTW’s supporters, could not learn to take control over the unknowable artifact on their desks.

I hope that open sourcery will over time be able to provide new tools for all Pagans to use, provide multiple easy entry points into Technopaganism, and help people gain a better understanding of how they can create their own tools and express their own ideas and concepts through computer software.

Posted 31 October 2009 † John § Ruby § Software § Techniques § Technology § Technopaganism ‡ Comments (1) °

Article on Twittermancy

Witchvox, a more mainstream/general Paganism site, have just published an article I wrote about Twittermancy – Twittermancy and Open Sourcery.

I’m not sure how well it’s going to go down with the more general Pagan crowd, and I really wish it wasn’t next to an article about ‘never again the burning times!!’, but I hope it gets a little bit more attention for Twittermancy and maybe even encourages someone else to develop their own tool.

I’m considering writing another article on basic Technopagan techniques, but I’m not sure where best to submit it. Would Pagan Dawn publish an article like that?

If you’ve any comments on feedback on the article, please let me know: you can contact me through the Witchvox site (apparently, no idea how that works), leave comments here, contact me through Twitter, send out a homing pigeon, use smoke signals…

Posted 27 September 2009 † John § Technopaganism ‡ Comments (0) °

Doing it wrong.

I’m going to start by proposing the following:

Doing it right > doing it wrong > not doing it at all.

I do firmly believe that in terms of software development, test-driven development (or ‘test-first’, or ‘behaviour-driven’ development, which all seem to be variations on a theme) is the right way to do it. You get excellent automated test coverage and that gives you the confidence to say that your code does what it’s supposed to and to refactor it without worrying about breaking things. Especially in the Ruby community, tests are the norm and writing your tests first is held as both a ‘best practice’ and the norm for many developers.

I really suck at doing TDD, and that’s stopped me from doing any development at all. Because I know that I ’should’ be working in a certain way, but I’ve not quite grokked how to do it that way yet, I end up doing nothing at all. Ultimately I need to understand why TDD is messing me up like this, but in the meantime I’m going to just write code and worry about testing later. At this that way I’ll actually produce something non-trivial, and some of my more interesting projects might actually see the light of day. (One of them definitely will, but I’ll be writing about that later.)

I have some ideas for why TDD just doesn’t work in my head. As I understand it, the idea is to write tests for the ‘code you wish you had’, which will fail, and then you write that code. I can how that would be really useful for experienced or well-trained developers, but I’m neither of those. I don’t do software development in my day job (and when I am forced to write code, it’s horrific perl hacks, so I don’t even want to do software development in my day job). I don’t have an academic background in software development (I studied psychology mainly, and didn’t even graduate anyway). I think I make a fairly good Linux systems administrator (I have relevant experience in that area, and a really good Unix Beard), but knowing how a computer system works doesn’t magically grant you the knowledge of software application design that’s drilled into the heads of Software Engineering students at uni.

I think my problem is that I’m not sure what the ‘code I wish I had’ actually is until I write it. I’m not sure what to write tests for until I have some code already – and that violates the basic premise of TDD.

Over time I want to correct this, and I think the best approach is to write actual code and make it work – which will give me experience – and to perhaps spend my daily commute reading up on software engineering theory. I’m not entirely convinced about the second part, since it sounds really dull. I’m by no means certain that software development is what I ever want to do full time, but I am certain that whatever I end up doing for a living I’m still going to want to use software development to realise the ideas and share them with the world.

Posted 05 September 2009 † John § Mind Tricks § Psychology § Rails § Ruby § Software § Technology § Testing ‡ Comments (1) °

I did it for the lols

Many of the projects I’ve been working on aren’t terribly serious. Failcount couldn’t exactly be said to be the most important endeavour mankind has undertaken. If it’s used heavily within a group, I suppose it could have a worthwhile purpose, to see when people are overly stressed, but that’s kind of incidental.

This last week, though, I’ve knocked out two simple Sinatra-based applications which are entirely and absolutely frivolous, and which both probably seem like static pages.

Are We Dead Of Swine Flu works by using the Ruby ping class to see if Google is down. Google being down is, of course, one of the key indicators that the world has ended. If the world has ended, it blames swine flu and says ‘YES’ instead of ‘NO’.

Screenshot of http://arewestillpanickingaboutswineflu.com/

Screenshot of http://arewestillpanickingaboutswineflu.com/


Are We Still Panicking About Swine Flu does even more than that. It pulls the Twitter RSS feed for tweets containing ’swineflu’. If there’s been no tweets within the last five minutes, then it says that we’re not panicking, otherwise the world is still in an uproar over what I like to call ‘the piggy sniffles’. (It’s much harder to sensationalise that term.)

I particularly like ‘Are We Still Panicking…’ because I’ve abstracted most of the logic out into a reusable class, and to avoid hitting Twitter’s API rate-limiting it implements caching. Since this isn’t a Rails project, I’ve had to roll my own very basic and naïve file-based caching. I’m sure it’s nothing impressive to people who do this for a living, but it seemed like an elegant solution to me and made me happy.

And when you’re doing it for the lols, making someone, even yourself, happy is pretty much all that counts.

These aren’t the only new domains I’ve registered this week. There’s a third one, and it is definitely not for the lols. Hopefully I’ll be able to write about that project later.

Posted 03 May 2009 † John § Ruby § Social § Software § Technology ‡ Comments (0) °