I’m pleased to announce the re-launch of Know Leeds, your guide to city centre living. The site has been going for six years now and was in much need of a refresh. It now has a stronger focus on restaurant reviews, but still has listings as well as local news and more to come.
Following on from my recent post about adding JPEG support, I also needed to add PNG support. I couldn’t get the RPM’s to work, so I had to do this manually as well.
wget http://downloads.sourceforge.net/project/libpng/00-libpng-stable/1.2.39/libpng-1.2.39.tar.gz?use_mirror=kent tar -zxvf libpng-1.2.39 cd libpng-1.2.39/scripts cp makefile.linux ../makefile cd ../ make make install
Recently, there has been news coverage regarding the cost of car insurance for young drivers.
Everyone is asking how we can bring down the price for young drivers. Nobody seems to be asking whether the price is legitimately high because that is just how much it costs, but lets ignore that obvious question and assume that the prohibitive costs for young drivers are an issue that needs to be addressed.
If so, one easy way to bring down the cost for young drivers would be to ban insurance companies from discriminating based on age.
What way, everyone would pay the same regardless of how old they were. Of course, insurance companies would still be free to charge people higher premiums based on their driving history – if you’ve had an accident you pay more, if you have no claims you pay less. But it stops the companies charging people more just because of their age alone.
You can argue that it makes sense to make young drivers pay more because they are more likely to have an accident, but this is not a fair system. Why? Because it is entirely unfair to the young drivers who do drive safely. Why should they pay more for other people’s reckless behaviour?
This is almost the same situation as it was with insurance companies discriminating based on gender, and this has now been recognised by the EU and will be illegal from the end of this year. You can’t charge someone more for car insurance because of an arbitrary characteristic, such as gender or race.
People get angry when they think about young drivers costing them more money on their insurance premiums. But this isn’t the case! Young drivers don’t cost you any more money. Only reckless drivers do. A young driver who never crashes and doesn’t claim on their insurance doesn’t cause your premiums to go up. Whereas a 50-year-old who does crash, does cause your premium to go up. To blanket blame an entire demographic because of the actions of a minority is both ludicrous and morally wrong.
The one argument I think might carry some weight is the argument that it is fair to charge young drivers more because we’re all young at one point and then we all get old, so everyone gets the same fair deal in the end. However, I’m not sold on this being a better solution than banning age discrimination altogether, in which everyone gets the same fair deal, all the time.
Huzzah I hear you cry! Yes, I’m please to announce three new episodes of the podcast are on their way – the first one is available today, and the next two will follow on consecutive Fridays. This series features expert insight from Norm “The No Man”, Hugh and James (now possibly known as “Old James” given there is a new A-Soc president also called James).
I didn’t take any photos while we were recording, so here is a stock picture of Hugh.
Credit to The World Through My Specs.
You may have recently noticed that the Moon was quite close to the Earth recently (in relative terms). The media jumped on this and described it as a Super Moon. Unfortunately, the lack of a decent telephoto lens on my camera prevented me from capturing it in all it’s glory.
If you’re using Propel ORM, you may want to select a range of primary keys. According to the documentation, you should be able to do this using code similar to the following.
BookQuery::create()->filterById(array('min' => 1, 'max' => 100));
However, what you find you get is that will return books with the ID of 1 and 100, but nothing else.
That is because Propel does not support ranges on IDs. This has been noted on the Propel GitHub issue tracker and will be resolved at some point in the future, but until then you have two possibilities.
Firstly, if you’re only looking to specify one value in the range, you can pass a criteria constant to filter by that.
BookQuery::create()->filterById(30, \Criteria::GREATER_THAN)->find();
You can also use LESS_THAN in the same way. Or, if you need a range with both ends specified, you can resort to the where() method.
BookQuery::create()->where('id BETWEEN 1 AND 100')->find();
Though that method requires you to use the database column names, rather than the PHP names used in Propel (yours may be the same, but I often rename mine for legacy reasons).
We recently launched Village Chief, a Facebook game in which you take on the role of a local village chief with the aim of growing your community into a thriving settlement.
The project was designed from the ground up to be highly scalable – Facebook cames can go viral very quickly so you need a system which can scale up very quickly if your game suddenly becomes very popular, or you risk losing out on huge amounts of market capitalisation.
First off, it’s written in Ruby. Ruby is a cool scripting language that is similar to Python and it’s popular web framework Ruby on Rails has received a lot of praise being the framework that Twitter and 37signal’s suite (Basecamp, Highrise, etc) are written in. It’s a very forgiving language, even compared to PHP, so if you like your static typing consider Scala instead, but for rapid web development, Ruby is a gem.
Despite the popularity of the Rails framework, I was looking for something a little more lightweight, so Village Chief is built using Sinatra. The documentation is a little underdeveloped but is never the less sufficient to get buy and lets you get a web application up and running nice and fast.
Ruby also includes a great module system called Ruby Gems (spot the earlier pun now 😉 ), a system similar to PHP’s PECL. The game makes heavy use of these – for example, using Koala to interact with Facebook and Dalli to handle our caching.
For a data source, it made sense to use a NoSQL solution. I originally settled on Apache Cassandra. It doesn’t have the flexibility or functionally of Mongo but it terms of raw speed it’s hard to beat and scales onto multiple servers with eventual consistency beautifully.
When it came to deployment, I decided to go with Amazon AWS’s DynamoDB instead. I’ll discuss more about why this was later but this meant rewriting the database interaction. This was easy to do thanks to our database abstraction layer and allowed us to continue using Cassandra for our testing systems while rolling out the production environment on DynamoDB.
Some data was also rolled out using SQLite. This was used for data such as the product catalogue which doesn’t contain user data – just things you can buy. Keeping it in an SQLite database allows us get quick access while still being able to query against the records – and importantly, allows us to version control our product catalogue.
To keep the database load down, some of the sorting was moved into the web server layer instead. On top of this we built a caching system using Memcache to save a lot of the data in memory, thus making things much faster.
When it came to deployment, I decided that Amazon’s EC2 cloud. You can start up a new server in under a minute, which is fantastic for scalability. Thanks to Amazon’s Elastic IPs, you can maintain a set of public IPs and map them to any one of your EC2 servers.
The servers are based on the latest Ubuntu release and to make sure that they are delivering content at top speed, I choose to go with the nginx web server rather than Apache, which works in conjunction with Passenger to provide the platform.
One limitation of EC2 is that you either have to allocate EBS (Elastic Block Storage) which adds additional cost, or use the ephemeral storage which you lose every time you turn the box off. The solution? Put everything into an external database so that we can switch boxes on and off without a problem – hence the decision to use DynamoDB rather than running Cassandra on the servers.
Code is then deployed using Capistrano which goes onto each of the boxes and performs a structed deployment that you can easily roll back, pulling the code direct from our Git repository.
That is a whistle-stop tour of the technologies used in Village Chief. If you have any questions about any of them, feel free to post a comment.
If you have made the mistake I did of doing a fairly minimal install on Debian, you might have noticed it is missing a few fairly basic features – such as JPEG support! Luckily it’s fairly easy to install it.
wget ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz tar -zxvf jpegsrc.v6b.tar.gz cd jpeg-6b ./configure --enable-shared make make install
Recently, I attended the launch of ODDTV, the new social video platform for Open Door Design, the design agency I worked at. It was great to see some old faces and although we couldn’t stay for long, drink as much free lemonade as we possibly could.
ODDTV is an interesting mix of videos that ODD has been involved with or generally likes the look of. Check it out.