Rubenerd

The shared experience of Life of Brian

Thursday 16 January 2014 Thoughts

Photo of the outdoor screen showing Life of Brian

Clara and I just came back from a twilight screening of The Life of Brian. Watching the Sydney sky fade to darkness while watching possibly one of the greatest films of all time with my dear friends was absolutely wonderful.

On the most recent ATP, Casey, Marco and the mayor of Siracusa County regaled the fun times growing up and having LAN parties. John made the comment that Team Speak and high speed internet has replaced many of those gaming meet ups, which caused a hint of nostalgia in the other hosts. The games and vocal interactions are the same, so surely the experience would be.

Certainly, my friends and everyone else who turned out to Centennial Park could have watched Life of Brian on their laptops, or on their fancy surround sound 7.1 home theater systems while tweeting #LifeOfBrian. The magic of sitting there in the open air at night sharing in this classic cultural icon with likeminded people roaring with laugher together is just indescribable.

Even introverts need to bond sometimes :). Always look on the bright side of life~ ♫ Thank you to @Adasifs for organising this epic evening!

Total [Non–] Recall

Wednesday 15 January 2014 Thoughts

Photo of our RAINBOW (yes, rainbow!) gelati

I had quite the disconcerting experience this afternoon. Walking with Clara to grab some coffee, I made a quick stop at an ATM to withdraw the required funds that would allow us to sit at a café. A café of choice.

I put the card in as per normal, but then stared at the keypad blankly for a few moments. Despite years of entering it, for some reason at that specific moment I had no idea what my PIN was. I entered what vaguely seemed familiar, and the ATM allowed me to proceed.

Having selected my required amount and account, I eagerly awaited the slivers of thin plastic our society has deemed to be worth exchanging for goods and services. In our case, gelati and coffee. And no autocorrect, I did not mean gelatin!

“I’m afraid I can’t let you do that Ruben”, said the ATM in a decidedly HAL–like tone of voice (footnote #1). As I feared, I’d entered an incorrect PIN.

I tried it again, and still couldn't remember. Again, the ATM reported an incorrect PIN. Rather than risk it eating my card, I cancelled the transaction.

An hour or so later, Clara and I were enjoying our coffee and gelati, procured with our pooled shrapnel reserves. As I was otherwise occupied playing cards, the PIN appeared in my mind, as if it were a fluorescent neon tube glowing so bright its light burned into my eyes.

The number seemed so obvious. You've been typing it for years Ruben, of course you'd remember it!

Yet… why couldn't I remember it before? What was it about my circumstance that was different from all the other times I've approached an ATM armed with the correct numeric sequence to unlock thin sheets of plastic? Had I done psychology at university instead, perhaps I'd know the answer.

Footnote #1: My legal department has requested I refer to this ATM as “machine with malicious intent”, rather than the trademarked HAL. Legal department B proceeded to remind me I’m a valuable customer for whom the bank would harbour no malicious intent. Finally, my third legal department demands I stop pretending I have legal departments, thereby denying its own existance.

Validating HTML 3.2 pages, like it’s 1997

Tuesday 14 January 2014 Internet

HTML 3.2 & CGI Unleashed

Like any typical developer in 2014, I'm finding myself validating some HTML 3.2 documents. Unfortuantely, we're back to the old issue of conflicting DOCTYPE declarations.

The official W3C HTML 3.2 Reference Specification uses the following:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

This American university document suggests this:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN//ENC">

Both of these will pass the W3C Validator, but with the following warning:

For this document, the information available was not sufficient to determine the parsing mode unambiguously, because [..] the Document Type (-//W3C//DTD HTML 3.2//EN) is not in the validator's catalog

On a hunch, I refactored it into this, and the validator was happy. The Web Design Group also recommends it:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

No need to lavish praise, your silent appreciation is more than enough. Unless, you want to put me on your webring or something.

The wonderous new fcpbundle

Monday 13 January 2014 Software

For all the prognosticators decrying the demise of Apple's pro software, updates have continued to trickle out. Now we have Final Cut Pro X 10.1, which had the longest feature addition list of any application in the App Store I've ever seen!

Before we go any further, I must disclose my "prosumer" status when it comes to software like this. I believe the term refers to a consumer who thinks himself a professional, but in fact is not. Or maybe they're consumers who buy professional tools. You can't spell prosumer without pro!

Semantics aside, I am not the one to listen to when it comes to improvements in such software; I probably use said tools in a laughably limited way. What I will offer is my brief experience with the one feature which has greatly improved my life overnight: fcpbundles.

Wasn't that the whole point of this post?

You see, with Aperture (and many others), application data is stored in handy bundles. The Finder treats these as files, allowing you to double click them and launch their associated application. Click "View Package Contents", and you'll see its constituent parts. Ditto installed applications. It's one of the usability features of OS X that I think places it head and shoulders above any other contemporary OS.

Previously, Final Cut Pro X stored Projects and Events in directories. Save for selecting the volume you wanted to use, there was little control over where these went.

FCPX 10.1 merges these two elements together into "fcpbundles". You can create them anywhere, drag and drop them to new locations, back them up, whatever you want. For individual projects you want to work on, export then archive, this makes life for a "prosumer" like me infinitely easier.

If I were editing a video advertising a rustic wilderness retreat, I'd call myself a happy camper. Yes, I had a point to that image by kanokoga on Pixiv.

Using (or not) Markdown

Sunday 12 January 2014 Software

In response to my previous post about Markdown file extensions, a few people asked me what I use it for.

For the most part, I don’t use it for web authoring. I understand the argument that Markdown is not a replacement for HTML, but given it’s exporting to it I don’t find the distinction pragmatic or useful here. I use inline HTML attributes, styles, citations and such for accessibility, RSS portability and semantics, all of which are beyond the scope of Markdown.

Where I do use Markdown is in my notes files. I previously ran a local MediaWiki install for note taking and general life organisation; I adored the hassle-free structure it gave my notes, the way I was able to assign them to categories, and then link those notes together. Markdown and nvALT have since given me these same features with greatly reduced overhead. This will be a topic in a future post I’m drafting now.

I suppose it also comes down to inertia. I’m used to coding in HTML, and have developed quite a library of snippets and macros for dealing with it in an automated, easy fashion. My inner developer likes that the code I write is the exact code the browser sees. Conversely, my notes files didn’t take long to port to Markdown, and now I benefit from other programs being able to parse them.

TL;DR Markdown isn’t a HTML Panacea, but it’s crazy useful for text notes. You are using text notes, right?

#Anime Kantai Collect All The Things

Sunday 12 January 2014 Anime

The Moe Anthropomorphisation of All The Things™ continues unabated. As if World War II aircraft battling aliens weren’t enough, we now have an anime adaptation of this:

Kantai Collection, also known as Kancolle, is a online browser game in which one assumes the role of an admiral, assembles a fleet of kanmusu (“ship girl”, girls based on World War II era Japanese ships and submarines) and battles against fleets of alien enemy warships.

One of these days, I’ll stop being surprised by news like this!

Art by ふまたけ on Pixiv.

Client–side blogging

Sunday 12 January 2014 Internet

Back in 2006 (as I'm pictured above!), I moved my then–fledgling weblog from RapidWeaver to WordPress. I was pretty clear as to the reason:

Here's the problem: I want to have a blog, and at the moment I'm using RapidWeaver for Mac OS X. So when I go to Malaysia and Singapore for Christmas to see the Mumster and the Father (and the sissta) I won't have a Mac to post on this blog! [..] There's also something appealing with having a server-side program doing this stuff too, not a client based program; it would eliminate all the uploading step altogether.

At that time, my only Mac OS X machine was a PowerMac G5. Unless I was in my student housing block in Adelaide (again, as pictured above!), I couldn't use the RapidWeaver software to post to my blog. By installing WordPress at my webhost, I was able to write posts pretty much from anywhere, provided I had a laptop and an internet connection.

Six years later, I decided to move my site to Jekyll. Generating my entire site client-side then pushing it to the server has numerous benefits, which I elaborated at the time (though I've since switched back to self–hosting it).

It seems so obvious, but it wasn't until I read a recent post by Clara that I put two and two together.

Client-side blogging sucks without a nice client.

Does the iPad cut it?

For a surprising number of people, the iPad fills the role of a computer. I don't believe in the mythical "email and light web browsing" user that so much of the tech press likes to generalise about, but there's little question that if those are your primary requirements, an iPad would suit the role well.

Then there are those who's iPad plays second fiddle. As usual, Clara more succingly discusses the idea in a recent post, calling her iPad a supporting device. I couldn't have said it better myself.

For developers, perhaps the iPad would be suitable given the 'coding' apps that are available on the market that easily syntax highlight and provide Dropbox syncing. However this is largely only true if they also have another computer which they can remotely access in order to do what the iPad cannot.

While the developers of Textastic and other iOS editors have done a great job with what they can do, iPad development is still a poor substitute to using a real Terminal, text editors and IDEs. Syncing still isn't great, and as Clara points out we can't build or run parts of our toolchain.

She then explains how this is relevent to client–side blogging:

As much time as I spend outside the house, it sometime aggravating to not be able to do much of anything while away from my laptop. It strikes me that so many of these people that think Jekyll is great either have lightweight computers to carry around or have a machine sitting at home or work they can simply and easily ssh into.

Lightweight laptops are the way to go

I'll admit, my lightweight laptop does make Jekyll useful. As an author does with a pad of paper wherever inspiration strikies, I can whip our my MacBook Air and code from pretty much anywhere now. It's not as light as my iPad mini, but it passes that threshold where I'd be hard pressed not to have it with me most of the time.

If I didn't have this setup, I don't think I'd be as excited about Jekyll as I am.

That's not to say the iPad couldn't also be useful in this context. I'm researching ways to have a machine at home generate and push changes to our server once it detects a new post has been added. With that use case though, perhaps server-side blogging really would make more sense.

Wikipedia on DuckDuckGo and Google

Saturday 11 January 2014 Internet

Just out of curiosity, I did a search for "Wikipedia" on these two search engines. Okay fine, I accidentally typed Wikipedia into my search box, and was intrigued by the results.

DuckDuckGo returned a lot of sites using Wikipedia material.

Google returned nine pages hosted by the Wikimedia Foundation, followed by a list of news stories.

I don't log into Google anymore, I opt-out of their tracking cookies and use privacy extensions. It could still be possible they're bubbling me; if not I'd be very surprised that those articles are what most people are interested in.

When you use the same mouse as him

Saturday 11 January 2014 Hardware

Photo from the North Korean media agency depicting Kim Jong Un using the same mouse as me

Well, this is awkward.

Jekyll timezones

Friday 10 January 2014 Software

Photo I took of Singapore in 2012

UPDATE: This date issue seems to be resolved as of Jekyll 1.5.1. As such, this post should be considered ~~hysterical~~ historical.

With almost four thousand posts written in different countries over the last nine years, I often feel as though my use case really tests the limits of Jekyll. To be fair, it has performed admirably.

One area where I've continued to struggle is with timezones. According to the Jekyll documentation, you declare timezones within the date YAML front matter for a post, such as this:

date: 2014-01-10 12:06:21 +1100

For posts written in Singapore and KL, I set the date with "+0800", with Adelaide as "+0930" and Sydney as "+1000" or "+1100" depending on daylight savings. Suddently, my times are even more accurate than they were when I exported them from WordPress last year, a nice feature!

There's just one catch. When Jekyll generates my site, these dates are converted to UTC. Under most circumstances this is fine; it's a more universally understood representation of the same time. Where this becomes a problem is human readable dates.

Say for example I posted this entry at 01:00 +1100. This means I'd expect my site to say Friday 10 January. Because it gets converted to UTC internally however, my blog says it was posted Thursday 09 January.

A temporary workaround

It's not very elegant, but for now I define a separate timezone variable in my post YAML front matter:

layout: post
title: "Jekyll timezones"
date: "2014-01-10T12:06:21+1100
tz: "+1100"
[..]

Now, whenever I need to show the date in my Liquid markup, I substitute the default Jekyll date functions with these:

{{ page.date | date: "%Y-%m-%dT%H:%M:%S" }}{{ page.tz }}
{{ page.date | date: "%A %d %B %Y" }}

Which generates these:

(Update 2021: Seven years later, and while fixing some HTML I realised this post was truncated! I have no idea what was supposed to be here. I suppose it's a moot point, given the issue was resolved years ago. Cheers).