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.
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:
Hopefully we’ll see a Retina Display in the iPad 3.
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.
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:
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!
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’.
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.
This is one of those small but really useful things – the iPad has started showing an INSTALL button in place of the BUY NOW button if you have previously purchased an app but don’t currently have it installed.
The App Store won’t let you buy something twice. If you’ve previously purchased something but don’t have it on your device, when you go to buy it again, it will pop up saying that you have previously purchased it and can install it for free.
However, it’s not until you click ‘Buy Now’ that it pops up….if you were to have not bought it before (or there was some kind of similar or duplicate app), it’s too late – you’ve just bought it so I always worry using that feature.
Now on the iPad, you will know for sure that you’ve previously bought it before clicking on it.
I really hope they implement this change across all iOS devices (i.e the iPhone).
In fact, why didn’t they do it long ago? 
Anyone who has done web development on a site that uses a https:// (SSL) secure connection will be familiar with the annoying “This Page Contains Both Secure and Non-Secure Items” error (or exclamation mark in other browsers) if you include an asset in http:// on the page.
This neat trick, which Paul Irish calls the “Protocol Relative URL”.
If you use // at the beginning of the URL, it will automatically use whichever protocol you are currently using.
eg:
<img src="//domain.com/images/logo.png">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>
.myclass { background: url(//domain.com/images/background.gif);
The only cavet is that you should avoid using it with <link> or @import to include stylesheets as IE7 and IE8 have a bug where it will load the stylesheet twice, which is in-efficient (especially since downloading a stylesheet is a blocking action so it will halt rendering the page while it downloads).
You wont find many a web developer around who doesn’t hate IE (and in particular, IE6). It’s buggy, doesn’t support newer technologies and exhibits all kinds of problems which don’t appear in other browsers.
Despite cross browser testing, it’s a regular occurrence for users to report problems that you can’t re-produce in your own browser.
IE6 is in particular old and pain to maintain and a lot of sites are now not supporting it – often serving up a standard style sheet which gives the user the content but without the site styling.
It comes as a pleasant treat for Microsoft to actively want to kill off IE6 and launching the IE6 Countdown site.
Steve Webster makes and interesting point though – IE9 isn’t supported on Windows XP, which is still very much in use. Therefore the latest version of IE that XP users can have is IE8, which is still a 2 year old browser.
Oh well, at least it’s a glimmer of hope! – the day IE6 dies will be a joyous day all round.
What I dont quite understand though is where they are getting the data from….
Here are some crude cron jobs I use to create nightly backups of svn repositories on the server (which will then get backed up elsewhere as part of the server backup).
The nightly backup will get overwritten each night, but a weekly backup is kept permanently.
When I say crude, they work fine for a quick job, but they are limited:
That said, here we go:
# At 01:05 each day, dump the repository to a file:
5 1 * * * svnadmin dump /home/svn/my_repository 2>/dev/null | gzip > ~/svn-backups/my_repository.svn.gz
# At 01:15 each Saturday, dump the repository out to a unique file:
15 1 * * 6 DATE=$(date +"%Y-%m-%d"); svnadmin dump /home/svn/my_repository 2>/dev/null | gzip > ~/svn-backups/week/my_repository-$DATE.svn.gz