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:

Over the past few weeks I’ve been working on a facelift for my blog, which hasn’t really seen much of a change since I launched it over 4 years ago. One of the key factors that brought this about was the need to introduce some kind of responsive design, as the last version looked pretty terrible on mobile devices. This is particularly important nowadays as search engines have started to demote any sites which aren’t responsive.

Initially I had thought about just updating the Wordpress theme to something a bit more modern and simplistic, but then at the same time my shared hosting plan expired and I moved onto a completely new server. As I was installing things, I came around to porting my blog over. This of course would be pretty easy to do, but I would need to install Wordpress again on my shiny new server - something that suddenly really bothered me. As is common knowledge, Wordpress isn’t exactly small and lightweight, and I started to question why I would need this behemoth for my simple blog. I didn’t even use most of the features that Wordpress offered previously. I shouldn’t have to have a whole mess of PHP and a database just for my blog - so I started looking around for alternatives.

Luckily at this point a colleague at work had just gone though the exact same process. He directed me towards Jekyll, which he had just converted his old Wordpress blog over to. Jekyll is a template based blogging system that generates static html pages from Markdown files containing your posts. It doesn’t have all the bells and whistles of Wordpress, but it’s very simple and very fast as it just spits out html pages. Sounded good to me.

Jekyll itself is written in Ruby and was really quick and simple to get started with - basically just install a gem and create a new site using the jekyll command. After that you can write your posts in Markdown, which is everywhere these days anyway, and run jekyll build to generate your site in plain-old html.

There are some limitations of Jekyll which I may run through in some future post, but for the most part it’s lived up to it’s name of being very quick and simple. One of the best things about it is how everything is done through partials and layouts with standard HTML and SCSS (Jekyll will do the SCSS build for you). No horrible PHP to trawl through in the old Wordpress themes to just change a small detail. Everything is where it should be and everything is very easy to customise.

Converting my Wordpress posts over to Markdown was a bit of a pain, but at least it was just a one time thing and now I can forget about it. You also lose some of the things you take for granted in Wordpress like categories and search, but Jekyll is very expandable and has a wide array of plugins that you can make use of. So far I’m really enjoying my experience with Jekyll. No bloated Wordpress dashboard, security holes and mess of PHP themes and plugins - just Markdown and static HTML files. Page load times are also a real dream now by the way.

If you’re looking for a simpler alternative to Wordpressm I would recommend at least taking a look at Jekyll here and seeing if it fits your needs. A quick warning though - you do have to do some work in order to get things set up how you want them - something that I’m quite enjoying - but maybe not if you want a shiny dashboard and a fully featured blog up and running in 5 minutes.

In Java it’s not too easy to convert Date objects between timezones as they always like to store the time in UTC (even though they will happily print BST when converted to a String form). Normal timezone conversion in Java is done through the Calendar class which is, as all Java developers know, really heavy and a nightmare to use. Even using a Calendar though, getting a Date object out if it in a different timezone doesn’t seem to happen at all. But it can be useful to have a Date object represent a time in a different timezone, so here is a little helper method that gets around it. Included is also another handy helper method that creates a Date object at a certain time (something that you often want to do but don’t want to see or use a Calendar directly):

import java.util.Calendar;  
import java.util.Date;  
import java.util.TimeZone;

public class TimeZoneConversions {  
	public static void main(String[] args) {  
		Date date = dateOf(14, 30, 0, 20, 8, 2014);  
		TimeZone local = TimeZone.getTimeZone("Europe/London");  
		TimeZone dest = TimeZone.getTimeZone("America/New_York");

		System.out.println(date);  
		System.out.println(translateTime(date, local, dest));
	}

	public static Date dateOf(int hour, int minute, int second,  
		int dayOfMonth, int month, int year) {  
		Date date = new Date();  
		Calendar c = Calendar.getInstance();  
		c.setTime(date);

		c.set(Calendar.YEAR, year);  
		c.set(Calendar.MONTH, month - 1);  
		c.set(Calendar.DAY_OF_MONTH, dayOfMonth);  
		c.set(Calendar.HOUR_OF_DAY, hour);  
		c.set(Calendar.MINUTE, minute);  
		c.set(Calendar.SECOND, second);  
		c.set(Calendar.MILLISECOND, 0);  
		return c.getTime();  
	}

	public static Date translateTime(Date date, TimeZone src, TimeZone dest) {  
		long time = date.getTime();  
		int offset = (dest.getOffset(time) - src.getOffset(time));  
		return new Date(time - offset);  
	}  
}  

When working with Git repositories in Windows, it’s not rare to have to create .gitignore or even a .gitattributes file for your repo. Unfortunately, in Windows Explorer, creating files with a dot prefix isn’t so easy. If you try to rename a file to .gitignore for example in Windows Explorer, you will be met with this error message:

To get around this problem, you normally have to open up a command prompt window in your repo and manually rename an existing file using:

ren gitignore.txt .gitignore

There is however a much easier way. Instead of naming your newly created file .gitignore, add an extra period onto the end making .gitignore. and your file will be created without the errors:

As an aside those on Unix machines (or with Git Bash installed on Windows) can simply use this command and forget about the above:

touch .gitignore