Try telling me that the App Store has UI standards

One of the arguments for the iOS ecosystem is the supposed higher standards that developers are held to, both in terms of functionality and UI design.

Okay, so take a look at this and tell me that these standards still exist.

This is the official scheduling application for WAHCKon, Western Australia's best ever hacking conference. It's part of this conference's culture—as well as hacker culture in general—to make things that 'look bad' (Comic Sans, bright colours, and all that). This application was purposely made to look as bad as possible, a lot of effort went into it, and it's on the App Store right now!

The application is a single image view, which contains the official WAHCKon schedule from the website. The schedule is also an image.

The schedule is meant to replicate the typical corporate spreadsheet. Note the #DIV/0 error in the top right, the Bonzi Buddy, and the image filters that were graciously applied to make it look like the spreadsheet had been printed and badly scanned back in to a computer.

And it's still on the App Store.

Kudos to the WAHCKon guys for getting this through. It's obviously tongue in cheek, and I think it's hilarious. Still, it really shows how things have changed.

'Web developer' as a pejorative in the '10s.

image.jpg

In the beginning - well - before the rise of the Web, I'd say that most software development was done using compiled languages like C / C++. The result of all this development was 'traditional' desktop applications. The Web sorta popped up in a hobbyist / academia-sorta way and - due to the lack of proper Web technologies / frameworks / best practices, a lot of Web properties were either entirely static or only had rudimentary dynamic features. We all remember visitor counters, unfortunately.

When the dot-com bubble happened, people sorta somehow forged some Web technologies out of thin air and we started seeing more complex web applications. Web development morphed from a glorified way of saying 'writing HTML' to resemble something closer to traditional software development.

This continued for the decade or so between then and now, accelerated by the currently-occurring '2010s dot-ly bubble', where web developers are earning well over $100k in some areas.

Now I love tech culture as much as the next person, but if anyone tried to tell me that - even now - development culture wasn't filled to the brim with nerd snark, I'd reply with a series of questions about how they've managed to live under a rock for over a decade. One such manifestation of this fairly toxic elitism in the software development community is the unfounded or outdated notion that someone is a lesser developer because their code outputs HTML and CSS.

The shaky logic that perpetuates this point of view is mostly based around the false notion that web development == writing HTML. I'd classify myself as web developer, but I only touch HTML, CSS, or even JavaScript around 10 to 15 percent of my working week. Mind you, I work alongside front end developers and designers which also do a lot of work. My point is that - in modern web applications - there's enough back end work occurring that someone can be hired full time to do it exclusively.

This isn't to say that I'm excluding front end web developers from my argument. Given the current state of the web, front end web development is getting harder! Have you seen the new features in HTML5 and CSS3? How about the CSS preprocessors such a Less and Sass, a field which has evolved from 'overcomplicated hipster trash' to a legitimate way to overcome some of the drawbacks and limitations of CSS. Have you seen how much JavaScript is involved in modern front end development? Have you seen that JavaScript is getting less terrible?

And lastly, the one that really gets me. Writing closer to the metal isn't inherently harder than not doing so if you're solving different problems*. The domain knowledge is obviously a bit different; I don't need to think about function pointers to write something using a modern Web technology. However this doesn't automatically mean that the body of knowledge and situational awareness required to write something in C requires more mental energy than doing something in Rails or Django. You're still working within a system and there's a lot of shit going on that you need to think about, same same but different.

Obviously you need to do more to get less done in lower-level languages like C. The upside is good C code will run faster than higher level code doing roughly the same thing. Unless optimisation is a legitimate concern, you should only take so much pride in using the wrong tool for the job. Whilst I appreciate doing something in C that shouldn't be done in C for the sake of academic pursuit, I can't say the same for doing it as a form of ego masturbation. Chances are the Python standard library developers have done a better job than you anyway.

This is probably just another blog post by a salty web developer who's sick of having his profession being put down by self-professed Real Programmers™, but I figure that this post won't be completely biased and someone might be able to glean some sort of sensical point from it.

Image credit: XKCD - Real Programmers

Image credit: XKCD - Real Programmers

* The second part of that sentence is there to pay respect to Steve GIbson who still writes his win32 applications + website in assembly. What an absolute madman.

Interesting facts about Australian phone numbers

I have been doing some stuff with Australian phone numbers at work lately. It turns out that Australia's phone numbering system (both current and historic) has great documentation provided by ACMA and Wikipedia wizards. Here's a few of the less uninteresting facts.

1800 numbers usually take the form `1800 XXX XXX`, the only exception I can think of is `1800 REVERSE` (`1800 738 377 3`). I still can't really work out why this is even possible, but it breaks every phone number validation engine I have tried. EDIT: 1800 738 337 (1800 REVERS) works for 1800 REVERSE, they must count on the trailing 3 (E) being ignored by the phone / network.

There is also a seldom-used shorter 7-digit `1800` number format.

The community service numbers still work, you can actually call `1196` and get the weather for free. What a time to be alive.

`0` is actually Australia's internal trunk prefix, it isn't part of the area code. This is why a lot of our long-form numbers start with `0` (`089266926` -> `0 8 9266 9266`). This is also why you don't see the 0 when our phone numbers are formatted for international audiences. (e.g. `0413 131 313` vs `+61 413 131 313`).

The location of geographic land-line numbers can be identified using the first 3-4 digits.

Australia doesn't forward the GSM emergency number (`112`) to `000` on landlines. Stop telling people to use it!

ACMA has fictitious numbers set aside for use in radio, books, film, and television.

A bit of an old one, but there are a bunch of 'test numbers' that read back your number, check your DSL codes, do automated callback.etc. PROTIP: the phone number formatting information on the linked site is incorrect.

Installing VirtIO drivers on Windows

Installing VirtIO drivers on Windows is non-trivial at best. The first problem you'll hit is that only the source and unsigned binaries are made available on the VirtIO site, and some versions of Windows flat-out deny the use of unsigned drivers. The second issue is that Windows doesn’t let you install a driver unless there’s a piece of hardware that requires it; how is Windows going to boot from a VirtIO disk if it doesn’t have the driver?

To overcome this, you could slipstream the VirtIO drivers into the install ISO, or somehow shoehorn the driver into an already-running OS. These both look pretty unattractive. This said, I’m going to show you how to do the second one, because—like me—you thought that getting VirtIO working would be easy, and you've already gone ahead and configured the OS so it's too late for an ISO slipstream. Good for you!

Issue 1: unsigned drivers

The great guys at Red Hat have compiled and signed the drivers for us. They conveniently come in an ISO for us to mount on our virtual machine with virsh:

virsh # attach-disk vm1 images/virtio-drivers.iso hdc --type cdrom --mode readonly

Replace vm1 with the name of your virtual machine, and images/virtio-drivers.iso with the path to your newly downloaded VirtIO drivers ISO file.

If you aren't using virsh, you're own your own. You should know how to mount an ISO on your guest anyway.

A note for Ubuntu users

AppArmor was extremely strict on my VM setup, so you may have to change your VM’s AppArmor profile. If you're having issues mounting the ISO, this is probably your issue!

First, we need our VM’s UUID:

$ egrep "DENIED" /var/log/syslog

You should see libvirt- a few times, followed by a UUID (e.g. libvirt-004c9d52-8e04-6580-038f-c46991ead293). Grab that string, it’s important.

Now, edit the AppArmor rules for your VM. Replace the UUID in the path below with your own.

$ sudo vim /etc/apparmor.d/libvirt/libvirt-004c9d52-8e04-6580-038f-c46991ead293

Add a line, before the closing brace of the profile stanza, telling AppArmor to allow access to your ISO files. For example, if your ISO is stored in /home/kye/iso-images/, you could either allow access to JUST the ISO file with:

/home/kye/iso-images/libvirt-drivers.iso r,

the entire directory...

/home/kye/iso-images/* r,

or the entire directory, and all sub-directories

/home/kye/iso-images/** r,

Now tell AppArmor to read the new rule file.

$ sudo apparmor_parser -r /etc/apparmor.d/libvirt/libvirt-004c9d52-8e04-6580-038f-c46991ead293

And, unfortunately, you’re going to have to restart your VM. Shut down from inside Windows to make sure nothing breaks, and then:

$ virsh start vm1

You should now be able to run the attach-disk command from before.

Issue 2: forcing the driver installation

Now have to somehow tell Windows about the existence of VirtIO whilst still allowing it to boot. We can’t just change the interface used by the boot disk because that means we can’t boot to install the driver! The solution, as ugly as it is, is a second virtual disk! We create a ‘dummy’ disk that uses a VirtIO interface, and install the VirtIO drivers when Windows asks how to install the new hardware. We then change the boot disk’s interface to VirtIO, restart, and Windows automatically detects the change and sets itself up accordingly.

Create a sparse file to use as the virtual disk container:

$ dd if=/dev/zero of=~/images/sparse.img bs=1M seek=4096 count=0

Now to tell virsh to mount the new disk the next time the VM is restarted. We need to edit your VM’s XML configuration file

$ virsh edit vm1

This should open your text editor of choice. Scroll down until you find your <disk> blocks, and add this to the end:

<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/home/kye/images/sparse.img'/>
<target dev='hdb' bus='virtio'/>
</disk>

Change the dev='/home/kye/images/sparse.img' section to wherever you made your sparse file. If another disk already exists with the hdb device name, increment the last letter (e.g. hdc, hdd, hde).

While you’re at it, you might as well use VirtIO for the networking interface. Scroll down until you find either <interface type='bridge'> or <interface type='network'>. Change the model to virtio, and delete the address definition. You’ll end up with something like this:

<interface type='bridge'>
  <mac address='52:54:00:4b:73:f5'/>
  <source bridge='br0'/>
  <model type='virtio'/>
</interface>

Now restart your virtual machine. Be warned, networking isn’t going to work, so you’ll have to VNC in.

Windows should see the devices automatically and ask for drivers. If it doesn’t, go into Device Manager and apply the drivers yourself. You don’t need to format the new disk once you’ve installed the driver, just make sure you can see it inside Disk Utility. Networking should work automatically once you install the driver.

Once you’ve confirmed this, virsh edit vm1 again, and alter your boot disk’s configuration to use VirtIO. In my case, it looks like this:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw'/>
  <source dev='/dev/vm/vm1'/>
  <target dev='hda' bus='virtio'/>
</disk>

If your old disk configuration had any other elements (e.g. <address>) just delete them. VirtIO will autoconfigure the rest for you, this should be all you need.

Also, you’re safe to remove the sparse disk configuration, and of course you can delete the sparse.img file.

Now save, restart your virtual machine, and—if it boots—you’ve finished!