About this site
This quaint little 'Web 1.5' site has served me well over the years. It's just a static, "non-responsive" site, but that suits me just fine. No security exploits to worry about and superfast performance. Even so, some effort went into the backend to make it work.
2.1. Standard compliance
Nowadays, the web is far more standardized than it used to be. But from the beginning, in 2007, this site has been completely standards compliant. That meant it didn't used to work well with Internet Explorer. Microsoft used to benefit from being non-standard, but with the small market share of Internet Explorer or Edge nowadays, they were forced to stick to the standards.
For some extra Web 1.0 feel to my site, I advertise the standard compliance in the footer.
2.2. Cool URLs don't change
What's more annoying than going to a webpage and getting a "404 Not Found" error? The links to your webpages are edged in stone, basically. Choose them well, and if you must change them, use redirects on the old URL's so that they link to the proper page.
2.3. Elegant URLs
"http://www.halfgaar.net/index.php?page_id=4". What the? The URL of a website is like the title, it should be elegant and descriptive, both for the user and for search engines. You shouldn't bother a user with telling them the page is PHP, ASP or whatever. "http://www.halfgaar.net/ferrari-f50" is what I call an elegant and descripte URL. Also, when using "multiviews" (URL's without extension) like I do, you are free to change the implementation of the page from one technology, like php, to another, like normal html, without the URL changhing. As I said, cool URL's don't change.
Elegant URLs are very commonplace today, luckily. So, this is hardly noteworthy, but still...
3.1. Hosting Provider
The hosting provider of my site is non other than me. It runs on my own co-located hardware in TCN data center in Groningen.
I use Rake to handle my processing pipeline. What this roughly entails, is collecting a list of pages to build the menu and a google sitemap, building the pages using XSLT and collecting all the relevant data and upload it to the server. "Make" is the classic way of doing this, but I find Rake much more convenient. And, Rakefiles are written in Ruby, which is a language I know and like pretty well.
This website is one of my few projects still in Subversion. For all my other stuff, I've moved to Git. The main reason it's still in Subversion, is the inclusion of the SVN revision log of each page (see footer). That can probably be done in Git as well, but I haven't gotten around to changing that.
3.4. XSLT, XHTML, HTML
I write my source documents in XHTML 1.0. My source documents are pages without the layout additions like header and footer, and without generated data such as chapter numbers. Layout data and generated data is added by an XSL transformation. The transformation sheet adds the commonly repeating data such as the menu or generates data such as a list of references for articles which require them. The generated pages are in HTML 4.01. The reason I use HTML as opposed to XHTML is because XHTML had not been adopted very well when I started the site (I'm not actually sure how well it would work today). For one, (old versions of?) Internet Explorer doesn't understand it when you serve it as an XML document, like you should. Not that I care too much about people not being able to view my site properly with Internet Explorer, but them not seeing anything is a little bit too extreme for me.
XSLT is relatively new to me, and thanks goes out to my buddy Bigsmoke for helping me out with it.
For syntax highlighting code, I use GeSHi. Migrations in MySQL demonstrates the use of it. The GeSHi library is called by my Rake processing pipeline, and the highlighted code is then inserted into the page.