define( 'WPCACHEHOME', '/srv/www/www.ichilton.co.uk/html/blog/wp-content/plugins/wp-super-cache/' ); //Added by WP-Cache Manager March, 2011 | Ian Chilton

Archive

Archive for March, 2011

HTML5 Boilerplate Reaches v1.0

March 21st, 2011 No comments

This afternoon sees the HTML5 Boilerplate project (H5BP), led by Paul Irish, reach it’s much anticipated v1.0 release.

If you have not heard of the HTML5 Boilerplate (or H5BP as they started calling it recently) before, it’s an excellent and essential resource for web developers. It can either be used as a complete starting point for a new web project or as a large collection of cross browser recipes and best practices to incorporate into your existing projects.

To quote from the HTML5 Boilerplate Website:

HTML5 Boilerplate is the professional badass’s base HTML/CSS/JS template for a fast, robust and future-proof site.

After more than three years in iterative development, you get the best of the best practices baked in: cross-browser normalization, performance optimizations, even optional features like cross-domain Ajax and Flash.

A starter apache .htaccess config file hooks you the eff up with caching rules and preps your site to serve HTML5 video, use @font-face, and get your gzip zipple on.

Boilerplate is not a framework, nor does it prescribe any philosophy of development, it’s just got some tricks to get your project off the ground quickly and right-footed.

Today’s release of v1.0 isn’t just a bump from the Release Candidate to the final version, it also brings with it some exciting new material:

  • A Boilerplate Custom Builder – providing a custom package with only the features you require (similar to Paul’s previous Modernizr builder.
  • Improved Documentation
  • Improved Build Script
  • New video guides
  • Support for lighttpd, Google App Engine and Node.JS
  • Reduced size (50% smaller!)

You can find out more about the Boilerplate by watching the following videos. The latter is particularly entertaining and Paul is a great presenter.

Categories: development Tags: ,

DOM Monster

March 17th, 2011 No comments

There is an interesting new JavaScript tool circulating today – DOM Monster.

DOM Monster is our answer to JavaScript performance tools that just don’t give you the full picture.

DOM Monster is a cross-platform, cross-browser bookmarklet that will analyze the DOM & other features of the page you’re on, and give you its bill of health.

If there are problems, DOM Monster will point them out—and even make suggestions on how to fix ‘em.

You can read more and get it from here.

Categories: development Tags: , ,

Logging to Syslog with Kohana 3

March 16th, 2011 No comments

By default, the Kohana PHP Framework logs errors to files in the application/logs directory, separated into directories and files for each year, month and day (eg: application/logs/2011/03/16.php).

To change this behaviour to use the system log daemon, you change the following line in bootstrap.php:
Kohana::$log->attach(new Kohana_Log_File(APPPATH.'logs'));
to:
Kohana::$log->attach(new Kohana_Log_Syslog('site_identifier', LOG_LOCAL1));

By default, these will probably appear in your /var/log/syslog file (on Debian/Ubuntu anyway – some other distributions use /var/log/messages).

You can configure syslog to put these in their own file by adding this to your syslog configuration file (on Debian/Ubuntu it’s done by adding a file into /etc/rsyslog.d):
local1.* /var/log/local1.log

If something else is already logging to local1, you can change that and LOG_LOCAL1 above to local2 and LOG_LOCAL2.

If you would like to write your own messages to the log, you can do so with:
Kohana::$log->add(Log::ERROR, 'error text');

Instead of ERROR, you can also use EMERG, ALERT, CRITICAL, WARNING, NOTICE, INFO or DEBUG.

If you would like to pull out different types of errors into different files, you can use this in your syslog configuration:
local1.=alert /var/log/local1.strace.log

Note that the errors are not actually written until the request has completed. You can force them to be written with the following:
Kohana::$log->write();

You can also force this behaviour by setting Log::$write_on_add = TRUE; in bootstrap.php, but be aware there is an overhead to doing that.

If you would like to ensure that logging is setup before writing to the log, you can do the following:

if (is_object(Kohana::$log))
{
// Add this exception to the log:
Kohana::$log->add(Log::ERROR, $error);

// Make sure the logs are written:
Kohana::$log->write();
}

Categories: development Tags: ,

loads.in – how fast does your website load?

March 15th, 2011 1 comment

This is a very nice tool – loads.in.

You enter a URL and it shows you how long your site took to load, what was shown at certain intervals and a waterfall chart – from a certain location.

You can then choose another location from a whole list of continents and cities and repeat the test again from that location.

Categories: Uncategorized, Web Tags:

weinre – Web Inspector Remote

March 15th, 2011 No comments

I recently blogged about a remote JavaScript debugging tool that Remy Sharp had created.

Along the same lines, this is something similar going around today that re-uses the interface for the Webkit Web Inspector (which is a bit like Firebug).

You can read more information here or watch the video below for a cool demo.

Categories: development Tags: ,

Why Apple Didn’t Introduce a Retina Display in the iPad 2

March 12th, 2011 No comments

I talked in a previous post about the announcement of the iPad 2 (which went on sale yesterday in the US).

A lot of the announced features could have easily been (and were) guessed. One thing that was notably missing from the iPad 2′s specification though was the so called “Retina Display” that was introduced with the iPhone 4.

There is an interesting thread on Quora looking at the reasons this might be the case.

Basically, there are a number of plausible explanations:

  • Cost and availability of the parts
  • Adverse effect on battery life
  • Hardware requirements to drive such a display
  • Lack of competition
  • Hopefully we’ll see a Retina Display in the iPad 3.

    Categories: Apple Tags: , ,

    Technical Debt

    March 12th, 2011 No comments

    I listen to technical podcasts whenever I am driving alone in the car (i.e the daily commute). One of my favourites is Build & Analyze – A weekly news and discussion show about the world of iPhone, iPad, iOS, and mobile web development. Hosted by Dan Benjamin and Marco Arment (founder of Instapaper and the former cofounder of Tumblr).

    This week, one of the discussion points was an interesting topic in which Marco entitled “Technical Debt”, which I found very interesting (and from experience, very true!).

    The theory behind the concept of the term “Technical Debt” is this:

    As a developer, every time you cut a corner, implement a hack or a short cut, or implement something in a sub-optimal way, you incur technical debt. Technical debt can be caused by time pressure, deadlines, commercial pressure or simply not knowing any better. While the feature may work fine for a while, technical debt, like financial debt has a habit of coming back to bite us later.

    The re-percussions of technical debt can be things such as having to later re-write code to be able to add future improvements or tidy it up or it can be in the form of performance problems or outages – possibly brought about by a surge in popularity/traffic or increase in the amount of data in the system. You can guarantee that the effects will manifest themselves at the most inconvenient of times too.

    Martin Fowler and Jeff Atwood (of Stack Overflow fame) have both written interesting posts about this concept and it’s something to bare in mind in the future when there is a temptation to cut some corners to get code finished.

    EDIT: Here is another interesting article about Technical Debt.

    Categories: development Tags:

    Twitter – lost touch with the users?

    March 12th, 2011 No comments

    It’s been an interesting few weeks for the social networking site, Twitter.

    A few weeks ago, Twitter publishes a new version (3.3) of their iOS application. Amongst other changes, they introduced a very obtrusive and badly implemented quick bar feature which showed trending topics (including paid for ones) in a grey overlaid bar.

    The feature seems to be universally hated and seems to have caused quite a backlash. Straight after the release, Twitter streams and blog feeds are awash with complaints of the so called “Dickbar” – so called after Chicagoan Dick Costolo, the (relatively) new CEO of Twitter.

    Twitter reacted quite quickly and released an update which makes the feature slightly less annoying but doesn’t get rid of it. In amongst the flurry of complaints about the bar, i’ve seen a number of people who have changed to 3rd party applications or have resolved to stick with the older version of the application to avoid getting the bar.

    In relation to this, I recently read an interesting article by Oliver Cameron entitled R.I.P Tweetie. Tweetie was originally a 3rd party Twitter client written by developer Loren Brichter and his company, Atebits. Tweetie became a vastly popular Twitter client, especially after the release of the 2nd major version, Tweetie 2. I remember purchasing Tweetie 2 a few hours after it’s release and have not really used another Twitter client since. Some of his UI elements, for example the ‘pull down to refresh’ method have become almost a standard user interface element across a lot of different iOS applications. In April 2010, Twitter announced that it had purchased Tweetie and Loren would be employed by them to work on the app. Oliver explains in his article that Loren was a widely respected and competent developer and some of the traites in the latest updates to Twitter for iOS do not exhibit the same quality that Loren would usual be known for.

    As if the whole ‘Dickbar’ saga was not enough bad publicity, Twitter yesterday announced that despite their application originating as a third party client, they are now clamping down on 3rd party applications. Fred Oliveira has some interesting thoughts on this in his post, “Dear Twitter“. I quote:

    PS: for a company that cares about user experience as your roadmap email mentioned, you have certainly weirded a few people out (me included) with #Dickbar. Have you lost touch with what people really want?

    EDIT: a few more interesting posts have come out recently:

  • Twitter angers third-party developers with ‘no more timelines’ urging
  • Here’s Why Developers Are Scaring Twitter
  • Marco Arment has also come out with an interesting post.

    EDIT – April 2011: Twitter have released a new version of the app with the Quick Bar removed!

    Categories: Web Tags: ,

    Find and replace across multile files, recursivly

    March 12th, 2011 No comments

    In a previous post, I gave a command for doing a find and replace operation across multiple files in a directory.

    I have used that command a number of times over the years but the problem with it is that it only works if all of the files you want to change are in the same directory.

    I sometimes have need to perform this find and replace operation across files in different directories.

    For this, you can use the find command and use xargs to run sed:

    find . -name '*.txt' -print0 | xargs -0 sed -i 's|originaltext|replacementtext|g'

    This command will find any files with the .txt extension, in the current directory or any directory below it and run it through sed to replace ‘originaltext’ with ‘replacementtext’.

    Categories: UNIX Tags: , ,

    Kohana 3 (KO3) PHP Framework with Nginx (and PHP-FPM)

    March 7th, 2011 No comments

    The Kohana manual (or for 3.0) gives the following configuration for doing clean url rewriting with Nginx:

    location / {
    index index.php index.html index.htm;
    try_files $uri index.php;
    }

    location = index.php {
    include fastcgi.conf;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    }

    I hit two problems with this.

    Firstly, I had to change it to location = /index.php to get it to work.

    Once I had done that it seemed to work fine.

    However, I then realised that query string parameters were not working correctly. For example, if I had a URL of: http://mydomain.com/controller/param1/param2?myvar=123. Under Apache, that would work fine and $_GET['myvar'] would be set to 123. Under Nginx however, $_GET['myvar'] wouldn’t be set.

    I fixed this by using: try_files $uri /index.php?$query_string;

    My final, working config is therefore as follows:

    location / {
    try_files $uri /index.php?$query_string;
    }

    location = /index.php {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
    }

    This seems to be working fine on an Ubuntu 10.10 box with: nginx-full 0.8.54-4ppa14~maverick and php5-fpm 5.3.3-1ubuntu9.3.

    It’s worth noting that the above won’t let you put any other .php files in your web root. If you want to be able to do that, you’ll want to use:
    location ~ \.php$ {
    instead of:
    location = /index.php {

    Note though that there is a bit of a security problem to be aware of with doing \.php$ – i’ll blog about this soon.

    Categories: Web Tags: , ,