Here’s a nice article on selling expensive, niche software.
Out-Law had an interesting article yesterday about how Ryanair is taking a Dutch fare comparison website to court in Ireland for screenscraping.
There are lots of similar price comparison aggregator sites like Bravofly out there and a few of them may be getting worried at this. Most of the time companies are quite happy for their product information to be scraped in this way because it can generate more business, but Ryanair and Easyjet seem to be against it. Why? Could it be a PR stunt?
As an aside, it’s interesting to read in the same article that big players Lastminute.com and Expedia.co.uk have also allegedly been using screen-scraping (and have been asked and/or warned not to by the low-cost airlines).
It’s time to put your thinking cap on.
The UK government’s Power of Information Taskforce last week launched a £20,000 competition for good ideas about how to use a raft of public information. Alongside the launch, the government is making available a number of new sets of data and APIs, including a database of schools in England and Wales, public notices from the London Gazette, health care services information from the NHS, transport information from Transport Direct and a new API to access neighbourhood statistics from the Office of National Statistics.
To enter, all you need is an idea for now. The competition is open until the end of September and the winner is to be announced in the second week of October.
It’s great to see more public data being made available in this way!
I just came across these guys: http://www.brownbook.net/
They’re a sort of open yellow pages where anyone can add, edit or review businesses. This is very similar to what sites like WeLoveLocal and Yelp are already doing, but in a world where many small business owners have yet to really get to grips with online marketing, the analogy with something as familiar as the yellow pages could still be powerful.
BrownBook’s listings are currently mainly for the UK, but they are accepting entries from other parts of the world. Their revenue model is based on charging business owners to ‘claim’ their businesses. Looks like an interesting idea.
“Nine out of 10 say rules should govern social sites”
According to Bobby Johnson in yesterday’s Guardian (Facebook Information Should be Regulated, Survey Says), “89% of those surveyed by the Press Complaints Commission said there should be a set of widely accepted rules to help prevent personal information – such as private photographs – being abused.”
ReadWriteWeb has more coverage.
Are we going to see a big clampdown?
Newspapers as we know them are dying. Offline readership numbers are dwindling as more and more people find what they need on the Web. Owners and editors everywhere have been grappling for some time now with how to stay relevant in today’s increasingly online world. Some think the answer is to focus on what, they argue, newspapers do best: local news. That was presumably the inspiration behind the Washington Post’s launch last year of LoudounExtra.com, a local community portal.
The WSJ article explains how, since the site’s launch in July 2007, it never really gained traction. The main reason for the failure appears to have been a failure to engage the local community in the site due, seemingly to two factors:
- The community that was targeted (consisting of 7 different towns) did not have a strong common sense of identity.
- The team didn’t put enough emphasis on real-world networking and promotion of the site with local community groups.
In addition to this, it looks like the parent paper could have done more to support the site by directing Internet users towards it from its main Web site, perhaps at least until it reached some kind of critical mass.
It’s interesting to note that, despite this site not taking off, the head of the project had previously successfully run other local newspaper portals focusing on smaller (perhaps better-defined?) communities.
TechCrunch ran an interesting post-mortem article yesterday by the founder of Meetro, a location-aware instant messaging platform, that recently closed its doors.
Meetro’s idea was to let users download an application onto their wifi-enabled mobile phones that would then allow them to find other Meetro users nearby to chat with.
Paul Bragiel, the founder, cited the following reasons for the start-up’s demise:
- The location problem: the service only became interesting if there were other users nearby. Critical mass gained in one geography didn’t help in other geographies.
- The realtime problem: the service would only connect users who happened to be online at the same time. Multiplied by the location problem, this severely reduced the chances of finding other Meetro users nearby.
- The download problem: the service required an app to be downloaded and installed on a user’s mobile phone. Most people were not interested in doing that.
I’ve just been catching up with TechCrunch, and read that FatDoor, a social network for neighbours, has closed down. At one point it sounded promising (and had a fancy-looking neighbour-mapping feature), but I guess things didn’t look good in their beta testing. The founders have changed direction, launching a new site called Center’d, with an emphasis more on local event planning.
I was recently helping a friend out with his Rails project and we were trying to figure out the best way to handle queries in a RESTful Rails app, i.e. returning a subset of items meeting certain conditions. After a bit of poking around, here’s what looks like the most promising convention to follow (please post a comment if you disagree with the conclusion described here).
We had two inter-related questions:
- What should a query URI look like in a RESTful environment?
- What Rails coding pattern should be used to respond the RESTful query?
What should a query URI look like in a RESTful environment?
The main choices here seemed to be between including the query parameters in the path or placing them after a question mark, e.g.
/items/large or /items?size=large
The answer is: use the latter form: /items?size=large
[Note: the exception would be if you have a resource called LargeItem in your app. In that case you’re really just looking at a standard REST collection GET which should be handled by the index method of your LargeItem controller.]
What Rails coding pattern should be used to respond the RESTful query?
So you’ve now opted for the URIs of the form /items?size=large. What code do you need to respond to these queries?
If you’re using the default Rails 2.0 RESTful resource scheme, queries will now be routed to the index method of your Item controller and your query parameters will be accessible via params, e.g. params[:size].
Your index method needs to return different subsets of your items collection depending on which (if any) query parameters have been passed in. For now I’ll probably put the logic to sort between the different cases in the controller, but it might be better to move it into the model (following the skinny controller, fat model pattern). Any thoughts on this?
How to link to specific queries
You can link to specific queries using something like this:
items_path(:size => ‘large’)
Many thanks to the following sources: