After Assembla’s frankly rather sneaky decision to start charging for its services, which I was using for code repositories both for pobo projects and for If Looks Could Kill, I took the hump and started looking around. A lot of people in this area offer a lot of stuff: project management, bug tracking, file storage etc etc. These kind of features always seemed nice but I never actually used them. I just wanted enough repositories for my needs, for my favourite price, with the option to have a handful of users join in if I needed it.

I looked at several, including Beanstalk (limited to one repository) and Project Locker, which offers a lot for nothing, but ultimately I chose Unfuddle for individual work. It only allows one project for the free option, but within that you can have unlimited repositories, and one more user if you need. It has a nice web interface, but the point with these services is that you can choose never to see that after you sign up: if it’s working, you just check in, update and commit in your SVN client (Subclipse is my choice) and that’s all.

Which helps my other winner, XP-Dev: it’s quite new and is still finding its feet, but it offers unlimited projects, repositories and users with a generous 1.5GB space limit. Its interface is pretty basic, but didn’t we just agree that that didn’t matter? Assembla has taught us (again) about free lunches, but the XP-Dev guys are aware of how annoyed that apparent U-turn made previously evangelical users, and seem determined to remain free. I’m already using them for a couple of projects and things look good: free, private, multi-user, multi-repository Subversion hosting. Too good? We’ll have to wait and see.

I’ve been researching PHP frameworks for a couple of projects that are coming up. These seemed to emerge from jealousy at the rapid development possible with Ruby on Rails, which uses a model-view-controller (MVC) arrangement and a lot of useful convention-based shortcuts.

Cake was the one I had heard of, but I came to hear about several others, including Symfony and CodeIgniter, and these three eventually formed my shortlist. There were a number of factors in the choice: documentation for something that involves a lot of assumptions and a fairly steep learning curve has to be clear and up-to-date. CodeIgniter is the winner here.

Secondly, the strictness of adherence to MVC. Cake and Symfony require all three, but the model is optional for CodeIgniter.

There is little to choose between the frameworks in the functions they offer, such as validation and helpers with such things as links, forms and sessions. So the only thing to do was build a blog and see which made most sense while doing it. CodeIgniter’s video tutorial was good (build a blog in 20 minutes, just like Ruby on Rails!), Cake’s documentation was exposed as inadequate and I gave up on Symfony altogether. The CodeIgniter blog is built without using any models, making it perhaps an easier transitional framework. So CodeIgniter it is…

I’ve just added a news section to Hand Up Media’s site, bringing in the latest in the fair trade world as supplied by the BBC and the Guardian. HUM previously had an HTML-only host, so the only way to include this news section was using javascript. Two problems – no javascript, no news, and also search engines, which rate fresh content highly, generally don’t run javascript.
Their host eventually upgraded and offered PHP, so I took the opportunity to grab the feeds on the server side, solving both those problems. PHP5 has much improved XML parsing over previous versions: the simplexml_load_file function reads in an xml file and makes it available as an object:


$bbc = "http://newsapi.bbc.co.uk/feeds/search/news+sport/fairtrade";
$bbcrss = simplexml_load_file($bbc);


Then, in the case of RSS, take the item element and loop through its contents:

$bbcitems = $bbcrss->channel->item;
foreach ($bbcitems as $item){
$item->source='the BBC';
if (time() - strtotime($item->pubDate) < 5259487){
$news[]=$item;
}
}

Also in there, I just check that the story is less than two months old before adding it to the $news array, and add a ’source’ element because that’s not included in the RSS in any proper form. Last thing to do (after adding news from other sources to the same array) is to sort it in date order using usort:

function _cmpAscA($m, $n) {
if (strtotime($m->pubDate) == strtotime($n->pubDate)) {
return 0;
}
return (strtotime($m->pubDate) > strtotime($n->pubDate)) ? -1 : 1;
}
usort($news,'_cmpAscA');

This function takes the array and a function as arguments: the function checks each element’s pubDate value (converting it to a UNIX timestamp) and changing its order in the original array accordingly. Then all that remains is to output it in a list and style it up…

I thought it might be interesting to put a moving portfolio image as my ‘featured project’ on the front page of the site. I needed to capture a 950px-wide website, and end up with a 600px-wide SWF. I tried a few different applications:-

RenderSoft’s CamStudio can capture direct to AVI or SWF (SWF was what I ultimately wanted) but neither gave the option to resize the video (I wanted to reduce the image from 950px wide to 600px). TechSmith’s Jing is a much more 2.0 type of affair, but while it seems really useful for quickly getting a point across over something like MSN, again it lacks resizing options. Nice app and well worth checking out; but not right for this.

Debugmode’s Wink is free and really easy to configure, at least for these purposes. It lets you choose the area of the screen you want to capture, then just press shift+pause and away you go. Then you can adjust the size of the resulting frames, delete frames and do whatever you need to do before rendering it as a reasonably lightweight SWF. It takes a few goes to get something reasonable, but if you’re not doing an actual screencast, with audio and timings, it’s a nice quick job.

Pobo has just completed a new contact form for Alice Melvin, an Edinburgh-based artist and illustrator. She was receiving industrial quantities of spam through her website’s contact form and had to take it offline. She was looking for a replacement and I was happy to accept the challenge.

Spam is a tricky and evolving beast, so any attempt to combat it needs a many-pronged approach. Single defences are vulnerable. Captcha, a method of distorting an image and asking the user to decipher it to prove he or she is really a human, is a popular method, but several of the most high-profile ones have been cracked recently. There are also reports of sweatshops run by hackers where huge numbers of captchas are sent by robots, read by humans and sent back so the robots can get on with their evil work.

The real problem, though, is that captcha is inaccessible to visually-impaired users, so it’s illegal (at least in the UK) unless an alternative is provided. Some sites offer an audio equivalent, but how would a deaf-dumb braille user submit such a form?

There are good overviews of the inaccessibility of captcha and the proposal of some alternatives in the W3C’s discussion and the slightly less dry Sitepoint article. Slightly depressing, because nothing strikes the perfect balance between accessibility and security, but they reinforced the impression that only a sequence of barriers would be effective and also have the capability to be tweaked in future without having to throw the whole thing out and start again if a particular technique is cracked. As will no doubt happen with captcha sooner or later.

At IfLooksCouldKill we have used the open source CFFormProtect, which wraps up some of the alternatives in a ColdFusion custom tag, and I took this as a basis for my PHP code.

There are five tests:
Time taken: the current time is recorded on the form. This is compared to the time it is received back. Too short and it is blocked. Spam robots can fill in a form in a second or two, but humans take much longer. The time is also encoded in a separate field and when the form is received back, this is checked to make sure the time value hasn’t been altered.

Hidden field: robots usually just fill everything in, making a guess at what is expected (e.g. an email address in an email field). This field expected to be empty when the form is submitted. It is hidden from view and screenreader users are asked not to fill it in. Robots will, and the form will be blocked.

Text check: the words in the form fields are checked against two lists: the first is bad words that no legimate user would write: one of these and it’s a red card. The second is words that in combination are good indicators of spam. A kind of points system adds these up and if the threshold is reached – sorry, you’re not getting in.

IP check: the user’s IP is recorded after a successful form submission and then that’s it; no more. For a while, anyway. Each time the form is submitted, the user’s IP is checked against a list of IPs and times and a decision is made on the validity of the submission.

This leaves us with a range of knobs and dials that we can tweak to raise or lower the barriers if spam finds its way through or users are being inconvenienced.