I tend to use the radio in Spotify quite a bit. It’s never been the best of implementations out there, but recently it’s been more annoying than usual in terms of repeating. The radio has always liked to repeat some songs over and over again, but it has now decided to repeat entire sequences of songs.

For example, if I start a new radio I will get a sequence of songs as usual. If however I listen to something else (perhaps a random song or playlist etc) and then go back to the same radio station, I will be greeted with the exact same sequence of songs as before. As you can imagine, this has gotten annoying really quickly. Initially you can keep skipping until you get to something new, but eventually that gets way too long-winded.

A quick search on the support forums show multiple users with the same kind of issues as me, but none are recent and there are no real solutions. Thankfully, after snooping through the AppData files for Spotify, I was able to come up with a solution:

1. Navigate to the Local AppData folder for Spotify. This should be at C:/Users/<user>/AppData/Local/Spotify
2. Locate to the Local Storage directory inside the Browser directory. At this point you should be in AppData/Local/Spotify/Browser/Local Storage
3. There should be two files starting with http_radio. For me they are http\_radio.app.spotify.com\_0.localstorage and http\_radio.app.spotify.com\_0.localstorage-journal. Delete both of these files
4. Restart Spotify and the radio’s should be reset

This might just be an issue for me, or might be a bug that will be fixed at some point. If it’s a design decision they need to rethink their priorities. At least I have this relatively easy fix however. I’ve put it all into a batch file and tend to run it just before I start Spotify.

When I first launched my blog way back in 2011 I didn’t really know a whole lot about web hosting at all and just wanted to get something tangible up and running as quick as possible. Therefore of course I had no idea what constituted a half decent web hosting company. At the time I think I was just following some online tutorial which ran through the process of setting up and hosting your own site. I registered my domain with GoDaddy as recommended (and still do with no issues) and then had to move on to actually hosting my site. The tutorial recommended Hostgator and that seemed fine to me. They had pretty good reviews and the prices for shared hosting were good for a minimal setup like mine.

I got myself their most basic shared web hosting plan which consists of a single domain and unlimited (yeah, until you start using too much of course) bandwidth/email/databases. To be honest even by today’s standards that’s pretty good going. At the time I payed $5.95/mo for 2 years of hosting which included a 20% promotion (which I later learnt is pretty much a constant thing).

They provided a good service to me for the duration of my stay. I was able to host my Wordpress blog with no issues and could easily play around with FTP and a few MySql databases on the side. Most importantly actually was the ease of getting hold of personalised email with my domain - something that it turns out is quite messy without cPanel as I found out recently.

Throughout my use of Hostgator speed wasn’t an issue - although granted I wasn’t using it for any real strenuous activity. I also didn’t get notified of any usage issues as a lot of people do with shared hosting (again this was really only Wordpress so that’s to be as expected). cPanel is ridiculously easy to use as well so no issues there setting things up.

Then my initial two year contract expired and I realised why the initial price was so cheap. The renewal invoice was sent to me and the price had increased by a third (about $70 for the two years). Not only had the base price increased slightly, but you don’t get that nice 20% discount that you take for granted when you initially sign on. There are never any renewal discounts that I can make out. Even if you have marketing emails from them, their offers are always for new accounts - never for existing customers which is a real shame. I can of course understand why they do that in the business sense, but still I would expect some kind of special offer on renewals once in a blue moon. With hindsight, I should have threatened to leave which is when they start trying to discount things, but at the time I really didn’t want the hassle of moving everything over to a new host and was happy with the service I was getting. Another two years with Hostgator it was.

Sometimes in Git I find myself accidentally redoing my last commit - normally when I press up to get to the last command I ran - expecting it to be something else. This is especially annoying when using git commit -am which will include all of the changed files in the new commit.

Fortunately, in Git it’s easy to undo your last commit (as long as you haven’t pushed it to any remotes yet). Just the one command is needed to revert the last commit to your local repository:

git reset HEAD~1

This is demonstrated in the below contrived example where I do an accidental commit, undo the commit using the above command and finally do a quick git status to confirm that the file in the commit has been reverted and is outside of the staging area. After this, the commit is no longer included in the git log and you would be free to make further changes to it (and others) and do a new commit as normal when ready.

Typically, just after I had converted my blog over from Wordpress (you can read more about the conversion here), the guys at Jekyll decided to have a major release - up now to version 3.0 over the 2.5.3 before. Some of the new features introduced include:

• Incremental regeneration (experimental, enable with –incremental)
• Liquid profiler (add –profile to a build or serve)
• Hook plugin API (no more monkey-patching!)
• Dependencies reduced from 14 to 8, none contain C extensions. We’re hoping to reduce this even more in the future.
• Changed version support: no support for Ruby 1.9.3, added basic JRuby support. Better Windows support.
• Extension-less URLs
• Default highlighter is now Rouge instead of Pygments
• Lots of performance improvements

More information about the release can be found over at it’s news page.

Luckily, migrations up to the new version don’t seem to be too bad unless you are using a lot of plugins that haven’t yet received an update. In my case, as of writing, I am just using jekyll-sitemap and jekyll-paginate. The latter of which is now deprecated which I will come on to.

To upgrade versions I simply ran:

$ gem update jekyll

You can also omit the gem name which will update all gems you currently have installed. The update seemed to run fine and no errors were output, so I then tried a jekyll build (quietly hoping that it hadn’t broken too much). As expected I was greeted with this message:

/home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.4/lib/safe_yaml/psych_resolver.rb:4:in `<class:PsychResolver>': uninitialized constant Psych::Nodes (NameError)
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.4/lib/safe_yaml/psych_resolver.rb:2:in `<module:SafeYAML          >'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.4/lib/safe_yaml/psych_resolver.rb:1:in `<top (required)>          '
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.4/lib/safe_yaml/load.rb:131:in `<module:SafeYAML>'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/safe_yaml-1.0.4/lib/safe_yaml/load.rb:26:in `<top (required)>'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/jekyll-3.0.0/lib/jekyll.rb:27:in `<top (required)>'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:69:in `require'
    from /home/ryan/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/jekyll-3.0.0/bin/jekyll:6:in `<top (required)>'
    from /home/ryan/.rbenv/versions/2.2.3/bin/jekyll:23:in `load'
    from /home/ryan/.rbenv/versions/2.2.3/bin/jekyll:23:in `<main>'

It wasn’t quite the kind of error I was expecting, and after a quick Google search I found a GitHub issue which has a quick fix of running gem cleanup. Must have been some old files laying around messing things up. I ran a Jekyll build again and it was a lot happier this time. I was however faced with a deprecation warning for jekyll-paginate and it seemed as though no posts were being output into my site. This decision seems to have gone under the radar somewhat - the only reference I could find was a short forum post on their site - and might catch out quite a few users making the jump to 3.0. As stated in the error message, you can continue to use the plugin by simply adding it into the gems section of your config.yml file.

It seems as though they don’t want you to continue using jekyll-paginate, but haven’t really supplied us with much of an alternative. The only real option I can find is the Octopress Paginate plugin which looks slightly more involved than the current offering. I might revisit my own pagination implementation at some point, but at the moment at least, it seems to work well and fits my simple needs.

Other than that, the upgrade to Jekyll 3.0 seems to have been pretty smooth. I particularly like the new incremental build option which can reduce some of the long-ish build times that Jekyll sometimes gives you.

By default, Apache will provide you with a simple ‘Not Found’ page in the event of a 404 error. Although this does the job, it’s often better to provide users with a more relevant 404 page - perhaps including a link back to your homepage.

In the Apache web server, it is very quick to modify the page served when various errors occur. First, you need to create your new 404.html page and place it somewhere in your html folder (normally /var/www/html). You can place it inside a subfolder, but it normally resides in the root folder - something like /var/www/html/404.html. The name of the document is not important.

Next, you just need to modify an Apache config file to point to your new page in the event that a 404 error occurs. A lot of other guides direct you to create a .htaccess file, but I prefer to simply modify the main VirtualHost (plus you don’t get the slight performance hit of accessing the .htaccess file upon every page load). The config file is located in /etc/apache2/sites-enabled/000-default.conf. Open it up in your favourite text editor (in this case nano, although feel free to use vim if you know how to exit it). You will need root privileges to be able to modify this file.

$ sudo nano /etc/apache2/sites-enabled/000-default.conf

(this is really just a symlink to /etc/apache2/sites-available/000-default.conf, so you could also directly modify this file instead)

Inside this file, you will see the main Apache VirtualHost serving files from /var/www/html on port 80. By default it will look something like:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

To include your custom 404 page, it’s just a one line addition inside the VirtualHost tag. This basically just directs Apache to serve the 404.html file when it encounters a 404 error.

ErrorDocument 404 /404.html

Similarly, you can also add other custom pages for other error codes such as 500/503 etc. Afterwards, the file should look something like this (here I have also added custom pages for a couple other errors).

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    ErrorDocument 404 /404.html
    ErrorDocument 500 /500.html
    ErrorDocument 503 /503.html
</VirtualHost>

Finally, once you have made all your changes, restart the Apache server to pick up the new settings:

$ sudo service apache2 restart

Your new error pages should now be setup and running. To test, visit a page on your site which doesn’t exist. You should be greeted with your new 404 page: