A couple of days ago the Wicket in Action website was unavailable
without any notice. I’d like to explain why that was necessary and what
I have done to prevent such outages in the future. This outage also
presented an opportunity to work on the design of the Wicket in Action
Wicket in Action: hosted by Wordpress
Wicket in Action was powered by a self-hosted Wordpress
installation since the beginning of this blog in 2008.
So why not use Wicket to create a blogging engine? I always figured
that it was more important to write content, not the backend software.
Hosting a Wordpress blog is almost gratis, where Java hosting brought
considerable costs with it. The choice for Wordpress was quite simple
at that time.
Wordpress has been a great blogging platform that got better with each
release. Most notably the automatic updates were a boon and the admin
UI was evolving nicely. With a press of a button I could upgrade my
blogs to a new major release of Wordpress. And in the latest releases
they even upgraded Wordpress for you automatically to patch releases.
Saying goodbye to Wordpress
Unfortunately Wordpress has been the target of malicious software,
hackers and automated scripts. When you have to fully nuke and
reinstall because a new exploit has crippled your site it is time part
This caused quite a bit of a maintenance hassle, and a nagging feeling
that at any given moment the website could be used to distribute
malware or harvest information of blog visitors. A couple of months ago
the website suddenly was blocked by google for distributing malware,
causing visitors to see a big warning screen that the website could
harm their computers.
The final straw that pushed me to turn off Wordpress was that I noticed
in my access logs some weird pages that really had nothing to do with
These pages did not turn up in the Wordpress administration UI so it
was difficult to spot them.
I immediately shutdown this website and my own personal blog. I
have put a notice in place but somehow my hosting provider shows a ‘not
registered’ page instead.
Goodbye Wordpress, I will not miss you.
Say hello to jekyll
The first thing I wanted to achieve was being free of active executing
code on my hosting server. This led me to turning this website into
serving only static markup.
Faster, more secure, better scalability
A static web site is safer than running Wordpress. There’s nothing to
execute on the server! All the pages are pre-rendered and ready to be
sent to browsers without any code executing. There are no accounts to
break: all editing is done offline.
A static website is also much faster to serve by web servers. The web
server only has to copy a file from disk to a network socket. There is
no code execution inbetween: all pages are pre-rendered and nothing
needs to be updated dynamically. This makes it easy to cache each page:
in a file cache or in the HTTP server.
Having only static markup files makes it rather easy for a HTTP server
to serve thousands of requests. Here’s a list Wordpress has to perform
to serve a blog post:
- start a PHP process
- establish a connection to the database
- query the database to retrieve the post
- query the datebase to retrieve the author
- query the database to retrieve the comments
- query the database to retrieve active plugins
- render the markup whilst executing any number of plugins and themes
- close the connection to the database
I am sure I have missed quite a few steps in this list. While only a
single step, there’s no saying what a given plugin and theme in
Wordpress can do.
In the new, static content situation the HTTP server has the following
tasks to perform:
- read file from disk
- send file to network
This is more concise and a lot easier to execute for a HTTP server.
One of the telltale indicators that a website is running a CMS
(Wordpress) is when a highly trafficed site (for example Reddit,
HackerNews, Slashdot, Daringfireball or Twitter) features the site on
the front page, the server will crumble under the amount of incoming
requests. Typically the first thing to give up is the database: with a
couple of hundred concurrent requests it is bound to consume too much
memory and the server will typically give up.
Wicket in action has not received that much traffic but you never know
who will link to your blog post. Give a positive review of JEE 7 or
Java 8 and suddenly you have thousands of Java developers looking at
While not strictly necessary from a performance standpoint, moving to a
static website makes sense.
Jekyll as the powering engine
There were a couple of factors to choose Jekyll as the platform
for Wicket in Action and my other website:
- well known technology
- servable from github.com
- automatic migration from Wordpress
The Apache Wicket project uses Jekyll to generate the
website. As such the Wicket committers have ample experience with
Jekyll. The tooling is well understood and there’s ample documentation
Secondly github.com can serve Jekyll generated websites directly. You
create a project and push your Jekyll content to github. A few moments
later Github publishes the content. Github uses a CDN for the static websites. This gives our
blog a global presence and speedy delivery.
I did not want to loose 6 years of content, so being able to import the
Wordpress database and have all content available was a big plus.
I was able to replicate the URL schema of the Wordpress installation,
so all links pointing to articles will still work (no broken web)!
A new design
At first the Wicket in Action website had a nice design that followed
the book closely, but was tailored for a blog:
After a couple of Wordpress upgrades my custom theme did not work
anymore. So I had to either reimplement my custom theme, or just pick a
default theme. I chose the latter and Wicket in Action has used a
plain design for some time. I was never happy with that.
The migration to Jekyll also brought a really hidious default design,
so I had to do some design work.
The goals I set myself were:
- stay close to the Wicket in Action book (use the smoking person, use
the book color)
- few menu items visible
- clear, easy to read content
- enough room for content and code examples
I wanted a content area that was wider than the original design to
accomodate code better. I went into Keynote (my ‘design’ application)
for the initial sketch and after letting it sit for a day started to
implement it in the Jekyll site.
The result is what you see before you. It is not too snazzy, nor too
A couple of things I have yet to address or implement:
- author names instead of accounts
- metadata clean up
- code blocks design: better font and font-size
- typography (font sizes of headings)
- responsive UI (legibility on small devices)
- search functionality
- tags and categories (though who uses those anyway?)
- reimplement comments
- migrate all content from HTML to markdown
This new setup gives Wicket in Action (and my other blog) a good solid
foundation for the coming years. I hope you like the new design and
that new content keeps on flowing!