Earlier today, a tweet from a colleague got me wondering whether I could set up cron on my NAS drive to give me the ability to run scheduled tasks. I don't leave any machines on at home, but my NAS drive is on 24/7, so it could be useful - especially as a backup system if Google open an API to Takeout!

I managed to get it working with some help from this post, so I thought I blog the details here (it turned out to be simpler than that post suggested) should it be useful to you (or to me, should I ever need to do this again).

There was no requirement to do anything crazy to make this work. I didn't install anything on the NAS, everything was there - even the SSH access is enabled via the web app!

1. Log in to the My Book admin web app.
2. Go to the Advanced section.
3. Tick to enable SSH access at the top of the page (note: you may need to update your firmware to get this option).
4. SSH into to the IP address of your mybook, using the username "root" and the password displayed on the page where you enabled SSH access.
5. Create a folder to store our crontabs. Since /var/spool is mapped to /tmp it'll be wiped at rebooted, so we need to keep our own.

   mkdir /etc/crontabs

6. Create a job that touches /tmp/crontab.test every minute (for testing).

   echo "* * * * * touch /tmp/crontab.test" > /etc/crontabs/root

7. Create an entry in init.d to start crond using our /etc/crontabs folder.

   echo "/usr/sbin/crond -c /etc/crontabs" > /etc/init.d/S99crond

8. Set permissions for execution.

   chmod 755 /etc/init.d/S99crond

That was all there was to it. I ran "reboot" and let the NAS reboot, then confirmed that /tmp/crontab.test was being touched every minute (with "ls /tmp/crontab.test -l").

Note: You should disable SSH access when you're done, or change the password. Otherwise, anybody on your network may be able to gain root access to your NAS!

If you make changes, you'll need to restart crond. You can do this with:

1. killall crond

2. /usr/sbin/crond -c /etc/crontabs

Next up, I'd like to find a way to edit the cron scripts from my Chromebook via something like Cloud9IDE rather than SSH/Vi ;(

I like the possibilities that NativeClient in Chrome will open up, but I can't help think that we're going backwards... Do you remember when we used to see "Best viewed in Internet Explorer" and other crazy stuff written on websites?

Surely with Chrome/NaCl we're just going to end up with "This game/app only works in Google Chrome with NativeClient". This doesn't seem like a good thing for anyone (devs or consumers). We were just starting to get web standards right, with cross-platform coding easier than it's ever been.

I think it's highly unlikely that other browser makers will add NaCl. Certainly not Microsoft - it just makes Chrome, Chromebooks, ChromeOS more attractive to their Windows customers. I don't think they'll want to help that cause!

I love the Chromebook because it's designed for the web. It's apps are cross-browser/platform by design. It's not like Windows, Linux, iOS, Android, etc., where all the "default" apps are locked to the OS. My biggest problem with the recent take off in mobile computing is that apps are tied to the OS. This just isn't right. I should be able to pick an OS based on my preferences, and not lose all my apps, or have a restricted choice of what I can run. ChromeOS will only run things written in an open standard that work on every other common consumer OS. Do we really want to destroy this?

Don't get me wrong, I think the idea of being able to run near native code over the web is an *excellent* idea. Web-based apps solve so many problems with deployment, updates, security, etc., and being able to run performant apps in the same way is great. However, we need something open for the web, not another thing Google have gone away and built on their own and try to force upon others (just look at Wave, Dart, etc.). If they intend for NaCl to be in all browsers, then it needs to be developed openly with input from all parties, not just sprung on the world (note: I don't know if this is their intention).

Is NaCl just going to be the new ActiveX?

For a long time, I've been using the address of this blog to login to websites that support OpenID. Rather than handling this myself, I used OpenID Delegation to let Google handle the login for me. However, it's always bugged me that due to the requirement of Google Profiles, I've always had to use my GMail account to login:

<link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud?source=profiles">
<link rel="openid2.local_id" href="http://www.google.com/profiles/danny.tuppeny">

That was, until now. With Google+ launching for Google Apps yesterday, we now have profiles URLs for Google Apps accounts! It's as simple as changing the openid2.local_id tag to point at this URL, and now I can use my Google Apps account to login to websites using Open ID without being tied to Google in the future!

<link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud?source=profiles">
<link rel="openid2.local_id" href="https://plus.google.com/113181962167438638669">

With search engines using page loads times as a factor in ranking results, making sure your website loads quickly is becoming more and more important. Gone are the days when we used to say "If your website doesn't load in 10 seconds, people will go elsewhere". Nowadays, people expect websites to load in tenths of seconds, not seconds.

There are a huge number of browser addons/tools that will help you measure the performance of your website, but my current favourite way to check is using loads.in. Some of the things highlighted by loads.in when I entered the address of this blog were trivial to fix (loading Google's API and jQuery when neither are being used, for example!). Some others required a little more thought :(

The next-slowest target was the Disqus comments system. It wasn't particularly slow, but there was one part that frustrated me:

The request for http://dantup.disqus.com/count.js takes around 600ms and just returns a 302 redirect to http://mediacdn.disqus.com/1301599987/build/system/count.js.

I'm not entirely sure of the reason for this redirect, but it's adding 600ms to my page being ready. This extra round-trip will also be far slower on a mobile device, and with 3G tablets become more popular, it makes sense to try and eliminate this.

This looks pretty easy to "fix", but before changing the path to be hard-coded to the mediacdn address, I asked Disqus if they saw any problems with this (after all, the redirect might be because the mediacdn address may change). Unfortunately, they weren't really sure if this would be a problem :(

Another possible problem is that the redirect could be different depending on the user agent. If I hard-code it, this would be gone. After a little testing, I decided this wasn't the case, and the redirect was always the same (and this makes sense, because the work is still exactly the same regardless of the user agent - not to mention browser-sniffing this way being a terrible idea).

I decided to give it a try anyway. It's just comment counts. If the URL changes, the comment counts will be broken until I notice. That's hardly the end of the world. So, my change looks like this:

// Old Code
<script type="text/javascript">
    var disqus_shortname = 'dantup';

    (function () {
        var s = document.createElement('script'); s.async = true;
        s.type = 'text/javascript';
        s.src = 'http://' + disqus_shortname + '.disqus.com/count.js';
        (document.getElementsByTagName('HEAD')[0] || document.getElementsByTagName('BODY')[0]).appendChild(s);
    } ());
</script>

// New Code
<script type="text/javascript">
    var disqus_shortname = 'dantup';

    (function () {
        var s = document.createElement('script'); s.async = true;
        s.type = 'text/javascript';
        s.src = 'http://mediacdn.disqus.com/13015111111199987/build/system/count.js';
        (document.getElementsByTagName('HEAD')[0] || document.getElementsByTagName('BODY')[0]).appendChild(s);
    } ());
</script>

I tested this using loads.in, and it actually took two full seconds off the time until the onload event fired, from around 4s to 2s! As well as eliminating the extra round trip which was pretty slow, there's no longer a DNS lookup for dantup.disqus.com.

So, assuming Disqus don't change this, it looks like a fairly safe way to speed up a site with Disqus comment counts. If you're going to try it yourself, be sure you work out the correct count.js path by following your own redirect! I edited the numbers in the URL of my sample code to avoid people copy/pasting my URL in.

I'd love to see Disqus eliminate this roundtrip themselves, so everybody using Disqus would get this little boost. Until then, this seems to be a decent workaround.

Over the last few years, I've picked up a few O'Reilly books on my iPhone from the App Store. It's not particularly fun reading on an iPhone screen (especially pre-iPhone4), but the books are crazy cheap. Like £3 cheap!

I figured that the reason these books were so cheap, was that they're locked to the iPhone, and you can't read them on your PC or other device. So I was pretty made up when I realised that any (most) iPhone apps work sync to the iPad!

Unfortunately, I didn't realise the iPad would render text so nastily at double-size (I'm hoping iOS4 will fix this).

Nevermind. Today, I found a gem on the official O'Reilly site. How to extract EPUB books from those cheap book-apps we've been buying. This will allow you to read them in your browser, or any other device that supports the EPUB format. This means you can read those books in iBooks on your iPad :)

For the less technical, I've put together some screenshots showing how to do this. First, find the app in the Apps section of iTunes. Right-click and choose "Show in Explorer/Finder".

Windows Explorer (or Finder, if you're on a Mac) will open, and highlight the file for this book. Right-click and choose Copy.

Paste the file somewhere temporary, and rename it to end in ".zip".

Double-click the zip file, and navigate to the Payload folder.

Inside the Payload folder, you'll see a .app folder. Navigate into that.

Inside, you'll find a folder called "book". This is the interesting one. Right-click, and choose Copy.

Paste the folder somewhere, and navigate inside it. You'll see three items: A folder called "META-INF", a folder called "OEBPS" and a file called "mimetype". Highlight these files, right-click and choose Send To -> Zipped folder.

Rename the new folder to end with the extension ".epub" and copy it to a folder where you would like to store your books. Then from within iTunes, choose "File -> Add Folder to Library" and select this new folder. Alternatively, you can drag the epub file into iTunes.

That's it! Now your book will appear in the Books section of iTunes, and will sync into iBooks on your iPad. You can also transfer the file to other devices that can read this format.

This makes those very-attractive O'Reilly books look even more attractive!