Alice Kærast

The Worth Way in Yorkshire is absolutely terribly managed. There I’ve said it. It’s not properly mapped, it’s been moved and even blocked off by farmers, signposts are missing and it uses the same colour signs as the Millenium Way which merges with it.  The publicity on it dates back to 2005, and it feels somewhat abandoned.  This is a real shame because it takes in some rather nice countryside and villages, and should be enjoyed by a lot more people (I met two other hikers on the entire route last week).

I’ve added what I can of the route to OpenStreetMap, and intend to re-walk the entire route with gps so I can produce a new map, but it needs more than I can give.  It needs somebody to challenge the land owners who have re-routed or blocked paths and it needs the council to spend some money on adding signposts.  Now that we’re members of the Keighley Town Centre Association we might have some weight in getting this lovely route some tlc.

The BBC News website has an article linking climate change to CO2 levels today.  Their claim is that high levels of CO2 20 million years ago caused major climate change.  This is problematic for two reasons: first of all if there was no industry 20 million years ago then increasing and decreasing levels of CO2 is natural.  Secondly, if changing levels of CO2 isn’t natural then maybe it was the climate change that caused the increase in CO2 and not the other way round.

The global temperature has been increasing over the past 15 years, not decreasing.  Whilst CO2 levels may cause climate change, we can only really expect it to change in one direction – it can’t do one thing 20 million years ago and then do something different now unless there are other factors.

Any worthwhile software is not just developed, it is also used and should have at least some level of governance.  The application lifecycle involves all three of these areas, and they all need to be considered when managing the software.  This post will mostly discuss processes rather than software.

There are a number of documented processes that can be used in software development such as Agile, Scrum, Kanban and Continuous Integration.  We won’t go into these in any detail as they are documented elsewhere and most opensource development teams just build their own processes.

It is vital that the project’s scope and progress is well documented.  It should be possible to track work items, look at task listings and get reports on time usage.  This is the absolute basics that any open source project should have, more corporate development teams should spend more time on time tracking and produce burndown and velocity reports (which may also be possible for some open source teams).  Shareholders shouldn’t have to ask a developer to find out the status of a project, it should all be documented.

If teams are physically working together, daily standup meetings can be a great idea.  These should address just three issues, what did we do yesterday, what are we doing today, and what’s stopping us from doing that? These meetings aren’t always suitable for every development team’s style, but some variation of them should be considered for implementation.

The process for developing the code should be considered before any programming happens.  This should include things like branching strategies and what is required before code is allowed into the software.  Branching strategies are discussed on the codeplex website amongst other places, requirements for code acceptance aren’t often talked about and will vary.  The most important thing is to not break the build, doing so will delay everybody, and so stopping people from commiting code which fails to compile (and other basic tests) is top priority.  Doing smoketesting, ensuring checkins are commented and linking checkins to jobs are other good ideas.  If people do want to checkin code which isn’t entirely working (for review or to keep safe) they should use personal repositories.

Occasionally when I have too much time on my hands I let Helen talk me into making mashups. I’m not particularly good at audio editing and so usually they don’t work out.  This evening however I’m fairly happy with the results, I can certainly see somebody with better audio editing skills making a very good mashup from this.

Here we have Seu Jorge doing the Bowie classic Life on Mars vs. Frank Sinatra’s My Way vs. Justin Bond’s In The End (from the movie Shortbus). Mars did it my way (in the end)

We’ve all heard about there being money to be made in the underbelly of the internet, about all the money people are making through harvesting emails, sending out spam and link building but most of us aren’t aware of numbers and so I’ve spent the past week or two investigating blackhat marketing techniques and some average prices for decidedly dodgy behaviour.  So here are some numbers for you

• $25 is how much you will earn by selling a single subscription to many adult webcam/chat/porn sites.  Others will provide you with ongoing monthly subscriptions, and a few dollars a month for each subscription adds up to a tidy profit.  However, the market in porn is largely saturated; webcams are less saturated, especially if you know how to market yourself well, but it’s still a popular market.
• $15 will buy you 1000 Gmail or Hotmail or Yahoo accounts.  Depending on the provider, these can be custom addresses of your choice or can be configured to forward to a certain email address.  Customisation will usually cost a little more, this figure is average.
• $1 is how much you can earn by completing 1000 captcha tests.  You actually need to complete 3000 before you get paid, and incorrect captchas mean you will inevitably need to complete more than 1000 to make a dollar.  This is perhaps one of the lowest wages you can earn in blackhat marketing, and your efforts will often be used to sell email accounts (see above).
• 20 cents is the maximum you will earn each time somebody clicks on an advertising link you have posted to Twitter.  If you can build up a large number of followers and stay on-topic then you can earn a fair amount of money, but it takes work building up Twitter accounts with lots of followers.  There is also much discussion about whether the companies running these systems are trustworthy – there is no way of verifying they are telling the truth about number of clicks, they are keen to claim you have cheated, and don’t like paying out.

There are also many more schemes, stealing lots of content to make an autoblog and then filling it with affiliate adverts and mass emailing to name but two.  I’ve always been curious about blackhat and other ‘dodgy’ marketing techniques since somebody tried hiring me to setup spam servers in South America, but it’s a rather narrow line between investigating them and being accused of “Associating with malicious hackers” and “partaking in black hat activity”.

I’ve just come back from B Media’s monthly Open Coffee networking event for new-media professionals. As usual lots of good conversations were had, but the real reason for this post is to publicise BarCamp Bradford which is happening in November.  Manchester are planning on hosting a BarCamp on the same date, though haven’t managed to organise anything yet.

By November we should have enough experience with Folkevalg and Votecast to present something substantial, and hopefuly start a wider discussion on e-democracy and open government.

There has been much discussion recently about whether ID cards have or haven’t been hacked.  Adam Laurie claims to have copied an ID card, edited the data, and then written the modified data to a new card.  The government responded with “We are satisfied the personal data on the chip cannot be changed or modified and there is no evidence this has happened” and then gave many buzz words to explain why they can’t be edited.  Perhaps ID cards can’t be edited, but that isn’t what Adam claims to have done, Adam claims to have cloned and created an ID card which the government rather conveniently haven’t acknowledged.

There is doubtless exageration and carefully chosen words from both sides, and so it is difficult to tell what has actually happened.  It comes down to a matter of who you trust more, a security researcher or private companies selling their technology.  Either way, it doesn’t actually matter whether ID cards have or haven’t been hacked yet because, like any technology, one day they will be hacked.  It also doesn’t matter how secure the cards are, people will lose them, and because an ID card is always valid (the government claims they can’t be hacked, so you can’t possibly have an invalid ID card) they have to be accepted, even if there is doubt as to their authenticity – a valid ID card has to be accepted.  ID cards will therefore not only increase fraud, but will shift the responsibility of ensuring security from the government and banks to the individuals.

We required a method of using sms to activate users on our new site so that we can be sure that people aren’t creating duplicate accounts and are from the UK. We have now come up with two methods for achieving this, both of which are documented below. It took a long time to get this working, not because it is difficult, but because like anything in Drupal there are so many different ways of doing things. Finding methods which work the best can prove difficult.

Our first implementation was to send sms messages to users with a code to enter. This was easy to setup using our favourite sms gateway redsms. We used the smsframework module and sms_user, forcing the user to enter a mobile phone number on registration and adding some code in the code confirmation function to add the user to a new role. We never got as far as adding in a form to set which role the user gets promoted to because we spotted a problem, it was going to cost us up to 7.5 pence per new user and we’d have to keep an eye on our balance to keep it in credit. This was clearly not the best way of doing things.

We then spent quite a long time, many days, coming up with ideas on how to do it the other way round. We had code which would receive sms messages from redsms but wouldn’t integrate nicely with Drupal. We came up with all sorts of weird and wonderful ways of interacting with Drupal’s user apis, trauled through existing modules on drupal.org to come up with ideas, and still didn’t get anywhere. Then one day it hit me, switch to a gateway which can send us sms messages by HTTP POST (so we don’t have to poll their api or parse emails) and use the user_import module to automatically import users from a csv file.

The following code (which is protected through .htaccess/.htpasswd) will receive messages from txtlocal.co.uk, remove our keyword (which is 8 characters long), check that the sender has a uk mobile number, check that the number is unique, and finally append to a csv file.


<?php
$sender = $_REQUEST['sender'];
$content = $_REQUEST['content'];
$content = substr($content, 8);
if(substr_compare($sender, '447', 0, 3)!=0) {
die('non-uk number');
}
$existing = system("grep $sender sites/votecast.co.uk/modules/user_import/data.txt | wc -l");
if ($existing!='0') {
die('duplicate number');
}
$fp = fopen('sites/votecast.co.uk/modules/user_import/data.txt', 'a');
fwrite($fp, $sender);
fwrite($fp, ', ');
fwrite($fp, $content);
fwrite($fp, "\n");
fclose($fp);
?>


user_import can then use this csv file, and on every cron job will add the new users and email them a random username and password. Only it won’t. user_import isn’t designed to handle a csv file which is constantly being appended to. Luckily it’s a quick fix for now, which we can improve later on.