Freelance Web Developer, Hampshire
Very pleased to see an article on 23/12/14 online at The Guardian that mentions and links to Made Closer. Enjoying a nice spike in traffic today.
You can read it here: http://www.theguardian.com/books/2014/dec/23/campaign-for-amazon-free-christmas-diverts-5-million
Try the tyre fuel efficiency calculator to see how much you could save by using tyres with a better rating.
Here are some calculations to compare a tyre rated C for fuel efficiency with an E rated one to see if it was worth the extra cost.
ATS Euromaster were selling the cheapest C rated tyre for my car for £83.99, the cheapest E rated one is £56.99, the difference is £27, neither are leading brands.
Assumptions:
Travelling 10,000 miles per year
Price of Petrol is £1.30 per Litre
Car does 50 mpg
Annual petrol expenditure = £1158
There is a 7.5% difference in fuel consumption between an A rated tyre and a G rated one. Assuming an even scale there could be a difference of 2.5% between the C and E.
That works out as a £28.95 per annum saving, but only if all four tyres are on the same rating. Individually it is £7.23 per tyre.
A good tyre may last 40,000 miles – so I could get 4 years use and the savings would add up. It takes us back to £28.95 saving over the average lifetime of the car, and that is approximately the price difference between the two options.
So what can I conclude from these calculations?
If the price is equal go for the best fuel economy.
Otherwise go for the cheapest tyre as any tyre could be damaged by a puncture or could wear prematurely if your wheel alignment is affected by hitting a pothole – the less investment in any one tyre the better.
But wait – there is another rating: Wet Grip.
There is roughly 3 metres braking distance between each grade on the Wet Grip rating.
Think of the number of times you have had to brake hard recently.
In my case to get an A rated tyre over the cheapest option it’s an extra £42 per wheel for Goodyear EfficientGrip Performance tyres – but over 4 years of driving you only ever need that reduced braking distance once to save you a whole load of inconvenience, raised insurance premiums and possibly injury.
If you’ve ever looked at the Euro NCAP ratings and chosen a vehicle with a better crash safety rating – then tyres with the best Wet Grip rating possible should be also be a priority.
Get the best tyres you can afford, preferably going for grade A where available.
Looking at it another way – it’s only another £15 more than the C rated tyre (which breaks even on lifetime cost with the E rated one) and that extra is paid for by the better fuel economy rating B over the life of the tyre anyway.
Next
Try my tyre fuel efficiency calculator to see how much you could save.
Read blog post on the best website to buy fuel efficient tyres.
Check out my other articles on cars.
It was hard to find a decent, active, jQuery event calendar plugin that was responsive so I’ve shared my research here.
FullCalendar seems to be the default choice for putting an event calendar on a website at the moment – but it isn’t responsive so no good for me. It’s late 2014, time for mobile first folks.
Calendario looks very nice (maybe overly styled), the last change on GitHub was six months ago and there are 7 open issues dating back by nearly a year, so I think it is safe to say it isn’t being actively developed at the moment.
Kalendar is free, but you are meant to link to the JavaScript file on the developers site instead of hosting it yourself. The documentation is basic – it doesn’t show how you can add an event to the calendar once it has been rendered, and the appearance – although flat and minimalistic – didn’t appeal to me.
I finally settled on Responsive Calendar. I think it looks great, it scales down for mobile devices and you can add events once the calendar has been rendered. It also integrates with Twitter Bootstrap. It is free for non commercial use.
WordPress brute force attacks are increasingly common at the time I write this – September 2014. Recently a server I look after was coming under attack and then after a few minutes the site would display ‘Error establishing a Database Connection’. 
When I logged into the server the MySQL service wasn’t running.
My first thoughts were that something in the attack was causing MySQL to crash, There was no information in the MySQL error.log to indicate why though so I spent time looking at plugins to help mitigate a brute force attacks, which tend to focus on the WordPress wp-login.php and xmlrpc.php files:
Disable XML-RPC will disable WordPress XML-RPC functionality meaning that nothing can be done to your content, however this does nothing to prevent initial database queries so MySQL can still be affected when running this, and it does nothing about wp-login.php either.
BruteProtect – I’ve seen comments that it will protect xmlrpc but I’ve seen it in action during an attack and as of version 2.2.2 it did nothing to stop it.
NinjaFirewall – there are a lot of configuration options but this one does the job. It sits in front of WordPress and so it can intercept the attack before all the database activity starts up. This worked great when I used it during an attack.
However you may host multiple WordPress sites on a single server and it could be tedious having to install this and configure it for each site, plus there is going to be duplication of what the code is doing and Apache still has to handle all the incoming requests.
It may be better to stop any attacks at the firewall because that’s the single point of entry to your server. This approach still requires a plugin – WP fail2ban but this one will log attacks to your systems auth.log which can be picked up by fail2ban and automatically added for a temporary period to your firewall rules. It is more complicated than the other plugins to install but once a malicious IP has been blocked it can’t affect any of the sites on your server will keep the system load much lower.
After getting the fail2ban solution in place the database was brought down yet again. I ended up looking in kern.log and at the time of the attack was the line ‘apache2 invoked oom-killer’ – that revealed the problem… Apache was using so many processes that it was running out of memory and as this particular server runs off an SSD the swap file is disabled. As there was nowhere else to get memory from it started killing off other processes, the biggest of these was MySQL.
What a relief to find the cause – MySQL wasn’t crashing at all. The solution was just to reduce the MaxClients value in apache2.conf – the default value of 150 is way too big for a modest sized server. If each process takes 40 MB then 150 processes require 6 GB of RAM. Getting a realistic value for this requires a little load testing plus the use of some tools to see how the memory usage increases as Apache has to handle more requests.
It is a good idea to use MySQL with sql-mode = NO_ZERO_DATE,NO_ZERO_IN_DATE (among other options)
If the NO_ZERO_DATE flag is not set, MySQL will allow ‘0000-00-00’ in date and datetime fields. This also allows the silent conversion of invalid dates to this zero date as well.
You probably don’t want to find zero dates being allowed into your database if there is a problem with any of the data validation you are carrying out before inserting/updating data.
However you have to use something as a default value when creating a table that uses date and datetime fields. My recommendation is to go for the minimum allowed value: ‘1000-01-01’ for a date field and ‘1000-01-01 00:00:00’ for a datetime, if the field is a timestamp then this is ‘1970-01-01 00:00:01’.