LessCSS Filter

Last weekend I released the code for the LessCSS Filter (transforms LESS files into CSS files on the server instead of the user's browser) that I use on this site and that I talked about in this blog post. I created a public repository on GitHub, placed the source code into that repository for others to check out, and added a download link on the repository page for those who just want to use the filter without delving into the source code.

The GitHub repository can be found here: ultraq/lesscss-filter

YUI Compressor Filter

I did a similar thing for the YUI Compressor Filter (something also used on this site, performs server-side minification/compression of stylesheet (including LESS) and JavaScript resources).

That GitHub repository can be found here: ultraq/yuicompressor-filter

Out of memory

To split these 2 small pieces of functionality into their own self-contained packages, I took advantage of some features available in the latest version of Java Servlets, something called 'web fragments'. Then when I was folding the separated parts back into my website, I used 'Servlet 3.0 annotations' to swap configuration files for in-code annotations (which I'm a big fan of). Together these made things a lot more convenient for me and it left the whole website feeling a bit 'lighter', simply because there was less stuff in the code base for me to worry about.

So last weekend I stopped my server, uploaded all the new bits and pieces of this website that I had been working on, started the server up again, and... nothing happened. I did some digging and found that plenty actually did happen: hundreds of lines of logging about how the server was running out of memory!

How the hell can my website be consuming so much memory? I wondered. The VPS on which my website resides only has 512MB of memory, which isn't a lot by any modern-day PC standards, but is plenty when all the server has to do is host a small website like this. So I started breaking it all down, trying to find out how that 512MB got divvied up:

• 1/10th for the OS and other OS services I enabled (a necessity)
• 1/10th for the website database (reasonable)
• 6/10ths for the application server before the updates (whoa... wait a minute)
• over 8/10ths for the application server after the updates (...dammit)

I investigated further and found that the Servlet 3.0 annotations feature was the real memory killer - using it causes the startup memory usage to spike beyond the remaining memory before settling-down somewhere within it. Without any room for that spike to happen, the application server couldn't start up, and so I got out-of-memory errors.

For any Java web developers amongst you, the application server I was using was Tomcat - a very popular and lightweight application server that I've been using for the last 7 or so years. Apparently, 'lightweight' only applies when you don't use Servlet 3.0 annotations, so to keep my site running for the last week, that's exactly what I did: removed annotations and went back to using a configuration file to keep my memory budget in the black.

Doing this felt like I was taking a step back in time - having to use older programming methods to stick to my memory constraints - and I didn't like it. I already step back in time enough in my day job (which drives me insane when I have to think about or work with how held-back some of those systems are) that I didn't want to have to do it here as well. This website is supposed to be my way of keeping up with the latest and greatest stuff (or at least 2 steps ahead of whatever my work is using) that I had to find another way.

So I went to scope out the alternatives.

The only alternative to Tomcat that I hear or read about is an application server called Jetty. It's written to the same specifications that Tomcat is, and when I read some of the goals of Jetty on their project pages, my optimism started to kick-in: words like 'efficient', 'embeddable', and 'smallest footprint' were used throughout the place that I started thinking, This is exactly what I'm after!

I downloaded the Jetty application server, threw my website at it, and there were only 2 problems in the migration: both related to code that I wrote which contradicted itself; both of which Tomcat never picked up on. Jetty also started up much faster than Tomcat, somewhere between 3 and 4 times faster! As for the memory footprint: there was no memory spike when using annotations, and the memory usage after startup was about 100MB less than Tomcat!

Suffice it to say, I deployed Jetty to my VPS as soon as I was able :D

2 years ago I complained that the book Pride and Prejudice and Zombies was basically Pride and Prejudice, but with zombies thrown into the more boring plot points of the book:

[...] while the twist of having the story set during some zombie plague is definitely interesting, the impression I'm getting so far is that the zombies feel less like a clever plot device and more like a small recurring joke weaved into the boring bits of the story.

I mean, zombies are mostly encountered during what I imagine in the original novel as uneventful trips between towns/estates, and/or are only given a few paragraphs in which they appear. Within those paragraphs the zombies quickly get dispatched by our heroine Miss Bennett, and then the story continues as if nothing happened.

I then came to the conclusion that I was tricked into reading a sugar-coated Pride and Prejudice, proceeded to curse the publishers for their ploy, and then held the notion ever since those days that I now know the plot of the actual Pride and Prejudice.

Well, this week I found some proof to support my conclusion.

The Lizzie Bennet diaries (dot Tumblr dot com...) is the home for the vlog of one Elizabeth Bennet, chronicling the days of her life with her best friend Charlotte, younger sister Lydia, older sister Jane, a mother whose sole goal in life is to get her daughers wed, and her encounters with a guy called 'Darcy'.

Sound familiar? Yeah, that's because it's Pride and Prejudice for 2012.

The vlog and Tumblr started just a month ago so it didn't take long for me to watch all the videos posted thus far. After each video I came away with the thought of, Huh, this is surprisingly accurate. You know why I know it's accurate? Because I read the damn zombie version of the book that does nothing to the original story.

(Yeah, you can tell I'm still bitter about having bought that book.)

If you really want to know what Pride and Prejudice and Zombies is like but don't want to submit yourself to the pain of having to actually read the thing, then just watch The Lizzie Bennet diaries and imagine that after each video, every character you're introduced to fights off a horde of zombies, then dusts themselves off (and cleans up any and all evidence of the mayhem that occurred) just in time for the next video.

Does watching that next video seem like nothing zombie-related happened at all? Perfect! That's exactly how the book feels.

One of the new things I started using as part of this latest site redesign is a CSS framework called LessCSS. It's pretty handy in that it lets you write more concise CSS code that closely mimics the actual structure of your page, and I've found that it leads to much shorter CSS files. Well, when using LessCSS you're actually writing 'LESS' files instead of CSS files, but since LESS files are written using existing CSS conventions, the difference is minimal and the learning curve is ridiculously low.

The standard implementation of LessCSS is as a JavaScript file that parses a LESS file, turning it into a CSS file, all on the user's browser. There are pros/cons of post-processing a page on the user's machine, and I took some issue with a) the fact that it relies on the user having JavaScript, and b) created a noticeable FOUC (Flash Of Unstyled Content) on development versions of my site. (I can't put blame solely on LessCSS for the FOUC however. I was already incurring a bit of 'FOUC debt' with my reliance on additional resources like Google Web Fonts and Prefix free, so LessCSS was just making that situation worse.)

The LessCSS page does show some ways to run it on the server, but it was done using node.js, which I don't use. So I searched for whether someone else had already created a Java version of LessCSS that I could use/adapt, and of the handful that existed, they were either too old, too broken, too limited in how to use them, or too dependant on other stuff that I didn't want to bring into my server.

So, I wrote my own.

Fast-forward to now. I've got a working LessCSS filter/processor to work through the CSS requests on the server using Mozilla Rhino and Envjs, it's got some basic caching and other checks to save on processing (saves roughly 500ms on duplicate CSS file requests), and I was really proud of what I had put together.

Now that the redesign is complete, I wanted to share the LessCSS filter/processor code (I've got this and a few other projects I want to put online), so this morning I created a GitHub account, then thought, Hey, let's Google those other LessCSS projects to see if they've made any progress. What I found was that, in the 2 months that it took for me to do the website redesign, SOMEONE HAD WRITTEN AND UPLOADED A NEW LESSCSS PROCESSOR THAT DOES EXACTLY WHAT MINE DOES.

*deep breath*

Even though someone has already beaten me to the punch, I'll continue to work on my LessCSS filter/processor and upload it eventually (I've got that and a bunch of other projects I've been meaning to put online). It'll be my first project on GitHub, and my first real foray into online code contribution. Still, it's not helping to silence the part of me that wishes that guy's LessCSS processor project was uploaded, oh, about 2 and a half months ago! (Could've saved me about a week's worth of work dammit!)

Oh man this took a long time. I wrote back when I started this endeavour that I thought it'd take just a month of my spare time to complete. As usual, my estimate was way too optimistic, and 2-and-a-half months later (a month-and-a-half over-time (and arguably over-budget)), here we are.

There wasn't any single piece of work that caused me to take so long. I simply wanted to do a lot of things, too many things, all at once. Given that it's been 3 years since my last major site update, I initially started with just wanting to stay up-to-date - updating a lot of my server software (most of it is a major release behind), getting off JSPs and use a real template framework for creating pages, and taking advantage of HTML5 and CSS3. However, in implementing each of those goals, they led to even more things to do.
eg: while updating software, I also went and updated many of the libraries and frameworks my site is built on. A few of them have had major changes done to them (requiring a bit of work on my part to integrate it with my site again), others had simply ceased to exist (leaving me to choose whether to stick with an old version, or find a replacement that was still active).

It was a similar story with moving to use HTML5 and CSS3. HTML5 was mostly an educational thing - learning about the new tags and how to properly use them - whereas my CSS troubles were mostly about trying to get a CSS framework, LessCSS, to run on the server (it's normally run as JavaScript on the user's browser, but the way I was using it, it felt 'right' that I get it to go on the server). I think I'll write another blog post about this in future, since much of what I learned with this latest redesign was from the experiences of other web designers/developers on their personal blogs. It's about time I started posting some of the programming stuff I learned anyway.

A responsive website

Apart from the change in layout, colour, and typography (thank you Google Web Fonts), the only other thing really worth mentioning is that my website is now a responsive website. What this means is that the layout will change/reformat/adjust itself to the size of your screen, which is especially useful for those of you reading this on a mobile device.

I think this was the main driving force behind my redesign. I've already written about how I thought the old layout didn't look ideal on the iPad, then about how I cringed when I viewed my site on my brother's iPhone, to the point that it really made me understand how terrible the mobile web browsing experience really is. So much so that it made me go and do something about it.

If you're viewing this site on a large screen, then one way you can see how this site adapts to different screen sizes is to change the width of your browser window. If you can't be bothered doing that, here are some screenshots of my site at varying widths:

The only thing I haven't really figured out to further enhance the mobile browsing experience, is how to serve smaller images for smaller screen devices (and lower bandwidth connections). The thing is, nobody has really figured this out, and it's still being actively worked-on and debated. The 'responsive images' community have even enlisted the aid of a few browser developers to help things along and, while the solutions they have on offer so far are really impressive, there still isn't any universally accepted or cross-browser solution. In the meantime, I'm still serving the 'normal-sized' images, having them scale down to smaller screen widths, and sucking-up your bandwidth in the process.

As someone who is also on a rather limited 3G data plan where every KB is precious, this really sucks.

Although I've allowed the site to 'respond' to various screen sizes, I haven't had the luxury of testing across as many devices as I'd like. I was able to test across the usual selection of desktop browsers (Firefox, Chrome, Internet Explorer 7/8/9) on a large desktop screen, but for mobile devices I didn't have that many to choose from. There was my iPad and my brother's iPhone (Safari @ 1024px, 768px, 480px and 360px (and the iPhone may have that Retina display thing going for it, but it uses 4 'real' pixels for every 'virtual' pixel)), and two Android 2.x phones my parents have (stock Android browser @ 480px, 320px, and 240px).

Even with 4 mobile devices, I didn't have the opportunity to test other mobile browsers on Android (although from what I've heard, mobile Opera and Firefox are pretty much on-par with their desktop counterparts), nor did I have a chance to try Mobile Internet Explorer on a Windows phone.

Regardless, it felt pretty cool going home to my family's place one weekend, gathering all our mobile devices, and then testing everything on real devices - it really made me appreciate the challenge of creating a site that still delivered a good mobile experience when you have to squeeze everything down into a display the size of your fist.

Updated wallpapers

Last year I updated a handful of my space wallpapers for widescreen resolutions (Now in 16:10 - Part 1, Part 2). Last month I updated those same ones for 1280x1024, then updated the rest of the wallpapers for both widescreen and 1280x1024:

New/Old stories

As well as the First Dance short story I shared with you over February/March, I've also added another 2 stories (1 old, 1 new-ish) to the Writing section. These are from some long comments I made on friends' Facebook photos, initially as a bit of fun, which became a tad popular with other people (though not always with the recipient):

• Unimpressed face (Frances' photo, January 2012)
• A world of their own (John's and Alexey's photo, April 2010)

More to come

I think that's pretty much it. The only other things that are left to do aren't visible, or only really affect me: some CSS quirks I'm still trying to figure out, and maybe another responsive layout change to better take advantage of widescreen monitors. That, and the usual bug fixes I expect to do after a big piece of work such as this.

Either way, it feels good to finally get this thing out of the way. The large fraction of my year's spare time spent towards this project has made me feel like a recluse, shutting myself up in my apartment, toiling away endlessly working on this website... it'll be good to move on to other hobbies, get out of the building, and see some sunlight for a change.

Whenever I do a site redesign, it forces me to revisit this sections of the site that I don't usually think about, or don't normally pay attention to.

When I first put this website together, my main focus was the Campaign section since what I was working on most was my Red Alert campaign. I remember having all the other sections of this site as links in the sidebar, but crossed-out and un-clickable (back when leaving 'under construction' GIFs in places was still considered the norm). Then, when that was completed and my time freed-up for other hobbies, my focus shifted to the Artwork/Writing sections where I posted all the pictures I was drawing and silly stories I was writing. In the last couple of years, the focus has shifted to this blog.

So with this latest redesign, I worked on the blog first (it's usually the template for how the rest of the site will look/act), then moved on to the simpler, mostly-static pages of the Campaign and my dead-in-the-water Red Horizon project section. After that, I moved to the Writing area since I had a few new stories to add to that section.

This left the About and Artwork sections of this site, both of which can instil a feeling of embarrassment in me since they reach back the furthest in time and are sprinkled with reminders of things that aren't up to my 2012 standards.

In the About section I have links to screenshots of what my site used to look like, going all the way back to 2000 when I first put this site together using Netscape Composer, HTML frames, and littered it with pictures of anime-style drawings and quotes that had nothing at all to do with the site - and all in Times New Roman font!

And in the Artwork section I have drawings dating back to high school days which, as I've been reviewing them this past week, have made me cringe. Now that I'm facing these images from my past, I find myself thinking, over and over: OMG, I used to think these were GOOD?!!? I'm half tempted to remove many of the pictures from there, but then another part of me kicks in and prevents it from happening - the part that believes that this site should act as an archive of everything I've shared on the internet.

As much as I'd like to selectively filter parts of my past to make a better impression in the present, it wouldn't feel right for me to do that. In the case of the older versions of this site, it reminds me of what I've learned from all my previous years of web design and development. In the case of my old drawings, there's still a part of me that wants to pick up a pencil and start filling-up my sketchbooks once again.

I'm not really sure if there's a lesson to be learned in all of this, but it reminds me of all those those inspirational images/pages/quotes that rant about telling you to 'make a new you', to look to the future, etc, etc, but I can't seem to recall one that tells you to be proud of what you've done. Too often the theme of those things is to get people to start again, leaving the past behind, or 'shedding your skin'. Why? I wonder. Are people so often regretting their mistakes that they need to jettison their personal baggage on a regular basis? Somehow I doubt ignoring one's past and 'starting fresh' is the way to creating less mistakes, since the prevention of mistakes requires experience, hindsight, and the ability to reflect on the past.

If I choose to take down some of those older drawings, or screenshots of how my site used to look, how can I say I've really improved? If I take down those older drawings/screenshots, how will I know if what I do now, or what I'll do next, is really any better?

The past is there for a reason - it's not just for historians.