culture

There seems no CSS code smell because it is all CSS code smell

The biggest CSS code smell at all is all too frequently /* hidden from view */

The concept of code smells is admirably applied to CSS in this blogpost. CSS is rarely considered as a "proper" programming language, so it's nice to see it treated with as much rigour as other languages receive.

However, the more I read it, the more I worry that the biggest code smell I come across in CSS isn't even mentioned; worse, it's actually demonstrated, by the very CSS examples and accompanying text. You see, I'm worried that nowhere in the article is a single mention of comments, their use or their abuse. Meanwhile, over around 100 lines of quoted code, there are only two copies of the same comment, a comment that adds so little to the reader's understanding that it exemplifies bad comments.

I would suggest if there's one cross-platform, cross-technology "code smell" then it's not commenting your code. But certainly there's a belief I've encountered among frontend developers that good CSS is, by its declarative nature, self-explanatory; that LESS or SASS, combined with judicious attention to nesting, mean that you don't need any accompanying human-readable documentation. Maybe that's true; but if we're talking about code smells, then: if you discovered this culture in any other programming community, wouldn't you do a double-take?

Of course, the brilliant programmer can in theory code without comments; well-written, lucid code can be readable enough that extra human documentation isn't required. But who's that good a programmer, all the time? I'm certainly not, especially when it comes to CSS. What proportion of CSS authors, with a keen eye for visuals and understanding of how to achieve them, are also really good programmers, in the sense that they understand and appreciate dependency, modularity, refactoring, maintainability, etc.... Meanwhile, how does the Dunning-Kruger effect influence the opinions of the very worst programmers, bolstering their belief that they too are good enough to code without comments? How much CSS work is done by designers, or junior developers, who can be skilful in their own fields, but not trained to write good code?

The simplicity and accessibility of writing CSS means that, if we're not careful, we will all end up sitting on the plateau of mediocrity, because a plateau is a confortable place to be. Rigorous coding, through attention and attendance to code smells, is a great way to start to climb the foothills of expertise. So we can't let the assumptions of the prevailing culture keep us on that plateau: let's train ourselves to comment our CSS, until we're good enough to train ourselves not to.

How (not) to parse config files in Varnish and Apache

Good user experience is a key component of any tool, including those that check config file syntax.

Here's how you check the syntax of your Apache configuration:

/usr/sbin/apache2ctl -t

What's the equivalent in Varnish? Well, if you do a bit of Googling you discover that the nearest equivalent is:

  1. Run varnishd -C /etc/varnish/default.vcl to turn the file into C code that Varnish would understand.
  2. If the file compiles, you have to ignore the result as it scrolls past.
  3. If the file doesn't compile, it will raise an arcane and fairly verbose error, which you have to not ignore.

Whereas Apache has a simple "one parameter, simple result" method, Varnish doesn't; as far as its creator is concerned, Varnish doesn't need one either.

I want to explain why Varnish's solution is problematic and bad usability, but I should start off by saying that Varnish is an amazing piece of software: if you haven't installed it on your live servers yet, but you think you might have the tiniest chance of performance issues, then do it now. This blogpost can wait for you to finish. Go on.

In explaining why their method is a problem, I want to look at the user experience of using Varnish, of using its documentation and of encountering the "universe of all possible documentation" on the web. I don't want to dismiss anything as a user training issue as such, and I don't want to be told how what seems to be standard user practice is wrong. Good usability research consists in assessing the user's experience without judging it, in order to fix the tool to the user's tendencies, and not the other way around.

Objection #0: it's not obvious

This is the clearest objection, but it's the one that's most difficult to defend in the face of people saying "you don't need a dedicated check, because of -C". Steve Krug's seminal usability tome was even named after this core principle: don't make me think. If the user is already thinking about getting their VCL file working, they shouldn't have to also think about how to use your tool. The tool use should be obvious, rather than requiring the same counterintuitive thinking every time.

To me, the honest answer to the question "how do I check a VCL file syntax in Varnish?" really should be "You can't." Because you can't, not really. Running a compiler and looking at the output is not the same as requesting your system perform a simple check and return a straightforward response.

Imagine if Varnish were a car, and the VCL file were the oil level. If you were to ask me "how do I check the oil level in my car?" and I replied "Well, you need to warm the car up; then get it on axle stands; then crawl underneath with a big tupperware box and undo the sump pan drain bolt; then, once it's drained, work out how much oil your car has versus how much it should have...." If I said all this, then you'd quite rightly (a) tell me that that's not a check, but an engineering job! and (b) ask if someone could put an oil dipstick in future cars.

As far as I can see, the main reason why there's no -t option for Varnish, is that the people who maintain Varnish know their car so well that they themselves don't see the need for dipsticks. User testing, and user requests, are how you work out that you need dipsticks.

Objection #2: it's noisy

What do we want from a check? Let's say we want the same thing as we'd want from unit tests: when all is OK, we want simple and terse; if at all possible, silent. Lots of unit testing frameworks are very quiet indeed, showing maybe a handful of dots or green lights: until something goes wrong, at which point you want to be notified.

Or think about how a notification system like nagios works: only when there's a problem with your machine, do you even know it's running (to the point where sometimes it's nice to set up a heartbeat notification - similar to Apache's "Syntax OK" - to monitor your monitoring!) When a notification framework gets noisy - when you have to set up filters to remove emails from your inbox - you're training yourself to ignore the alarm; your application is shouting "fire!"

If the behaviour of a check on success should be quiet, then the default behaviour of Varnish's syntax checking is just plain wrong. You can make it quieter on success:

$ varnishd -C /etc/varnish/default.vcl >/dev/null

but why? Why is a syntax check outputting code to the screen? Because it's not a syntax check, not really: it's a code compile function that's being shoehorned into a syntax check.

Objection #3: it's unscriptable

Let's look a bit more closely at what apache2ctl does to the shell environment:

$ /usr/sbin/apache2ctl -t
Syntax OK
$ echo $?
0
# Now put some syntax error in your Apache config and try again
$ /usr/sbin/apache2ctl -t
/usr/sbin/apache2ctl: 87: ulimit: error setting limit (Operation not permitted)
Syntax error on line 2 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ThisDirectiveDoesNotExist', perhaps misspelled or defined by a module not included in the server configuration
Action '-t' failed.
The Apache error log may have more information.
$ echo $?
1

See how "all OK" returned 0, while "warning!" returned 1, a non-zero result? This is all part of being a "good shell citizen": the shell and its processes can only really communicate by zero/non-zero exit status; so it's a kind of "interprocess politeness" for processes to return a non-zero code, if anything goes "wrong". It means that commands can be trusted to report errors in a way that the shell can understand, and can therefore be scripted; for example, this command reloads Apache's configuration only if its syntax is OK:

$ /usr/sbin/apache2ctl -t && sudo /etc/init.d/apache2 reload

What about Varnish?

$ varnishd -C /etc/varnish/default.vcl > /dev/null
$ echo $?
0
# Now put some syntax error in your Varnish config and try again
$ varnishd -C /etc/varnish/default.vcl > /dev/null
/usr/sbin/apache2ctl: 87: ulimit: error setting limit (Operation not permitted)
Syntax error on line 2 of /etc/apache2/sites-enabled/000-default:
Invalid command 'ThisDirectiveDoesNotExist', perhaps misspelled or defined by a module not included in the server configuration
Action '-t' failed.
The Apache error log may have more information.
$ echo $?
0

This means that Varnish's "syntax checking" mode is unscriptable, as it behaves in a non-standard way to the shell.

Objection #3: it's dangerous

Objection #3.5: you'll have a damn hard time finding it, but there's actually a slightly better way to do this

Why are we here?

Lots of open-source projects have this reluctance to implement features that the maintainers don't see are necessary. I've picked on Varnish here because it was our most immediate problem, but the feature request queue of many an open-source project is littered with worksforme ticket closures: Psi always used to be my go-to example for this behaviour, although I can no longer find a link to the thread where people were pleading with the maintainers to stop the vCard from popping up on every server login just because you haven't yet filled in (unnecessary) details.

Whereas software development is gradually moving to much more user-focused development - UX is big in online applications - there's a sense in which command-line applications still either consider themselves too hardcore to worry about the people who are actually using them and their experience of doing so. I grant that some tools are difficult or dangerous to use: but that's why we have up-to-date documentation; and safety checks that provide a clear, unambiguous user experience.

Blog category:

Can free stuff exclude at conferences?

Really too much of a good thing? What if that good thing is addictive, expensive and ruins your liver?

When I'm planning an Oxford Geek Night, there's often a pressure to get drinks sponsorship: from the venue, from attendees and even from speakers. The first serious long-term drinks sponsors ended up so popular, that many events after they'd stopped sponsoring us, people were still asking me if they were going to provide a bar tab at the next one.

But a regular OGN attendee recently pulled me up on a brief burst of "BEER!" rhetoric by suggesting that, especially for someone teetotal, stressing free alcohol all the time could be alienating. He wasn't asking for a dry venue; he was just pointing out that, if you don't drink alcohol, then an event which stresses free drink (essentially alcoholic, given the venue is a pub, and the tab is at the upstairs bar where they don't do e.g. coffee) might just seem weird, and not something that was meant for you to attend.

There's a long, ranty but in many ways quite reasonable article about how free alcohol is bending the industry's social events out of shape. Certainly when you assemble all of the free-beer boasting in one place, it starts to look like web event marketing is run by someone with a serious problem.

It's fair to say in response, of course, that the culture of drinking in the UK is more accepted and indulged in to larger amounts, than in the USA; Europeans simply do drink more. And that part of the psychological damage of heavy drinking arises from social ostracization, in the same way as the tendency to drink in the first place comes from social acceptance. Moreover, while one should always listen to minority groups, because their more vocal members help to show when something more important is going wrong, then at the same time I've had more comments that any sponsorship is corporatizing the event, than I've had comments that we're stressing the drinking angle too much. Is that - thin end of the wedge aside - a reason to turn down all sponsorship?

I certainly don't want the image of OGNs to go from "Friend of Oxford Geeks" to "Fun Bobby". But my personal feeling - admittedly, as someone who does drink alcohol, at least occasionally - is that, as long as we stress the "sponsorship" in "drinks sponsorship", and avoid simply bellowing "BEER," then we at least tone down the alcoholic nature of it.

But I wonder what other people think. Leave a comment, or contact me on Twitter, if you've an opinion.

(By the way: we haven't had such sponsorship in ages, which arguably makes my worries moot. And do you know what? Every OGN is a dry OGN for me: having to ferry equipment around means I can never conscience having an alcoholic drink. It's not a lifestyle choice, though, which I imagine makes a difference.)

What happened at the first Refresh Oxford hack day on Saturday

We built stuff that works, is what happened. Apparently, this is rare for a hack day.

Yesterday I went to the inaugural Refresh Oxford hack day in the Incuna offices. It was great.

The local initiative is part of "Refreshing Cities," an attempt to provide vitality to local creative and technical culture, especially in the field of "new media," which one day we'll probably just call "media." As I've spent the last four years organizing the Oxford Geek Nights to do this very thing within the geek-social space, I can only applaud the idea.

The start of the hack day saw dozens of people present: a decent spread of designers, developers, UX/accessibility experts and similar webby folks. It was useful to begin immediately after another first, the inaugural European jQuery conference, also in Oxford; the conference brought a lot of both attention and attendees to the event. Although, the large amount of booze available at the conference means that a lot of people didn't turn up till considerably later; if indeed at all. 

For the first hour or so, we were all free to propose projects to everyone else. The idea was that these should be ideas that could either: be begun and brought to a fun if not necessarily successful conclusion in a day; or that were more long-term, already underway, but needed a day's worth of work from a few people to yield real returns. While we did a bit of horse-trading, we also ate pastries and drank tea and coffee.

Henry, Suzie and I formed a team of frontender, builder and programmer respectively for our own project and came up with a plan for development. Lunch turned up as we started work, and then... well, the next seven hours or so are frankly a bit of a blur. A fun, exciting blur; but a blur nonetheless, as we dipped down below the surface of our project and hammered away at it. By the end of it we had a cute little application with a server and a Chrome browser extension that even I was surprised actually worked (despite Henry's attempts to break it just before we were ready to show it to other people.)

We all finished with pizza, a demo, and then beer. Other demos included:

  • an in-browser horizontal-scrolling game with cats
  • work on making the first volume OED searchable through OCR
  • a prettifying Django views inspector 
  • and an attempt to script kinetic typography

In short, a pretty varied bunch of really neat one-day efforts from everyone. And we also got to meet other like-minded local geeks and find out what other people were up to in the city and its environs. This coincides completely with the whole reason I run the OGNs: geeks are paradoxically both shy and social animals; so encourage them to meet up with each other once in a while, overcome that initial barrier of shyness, and magic happens.

The all-important social aspect aside, it's astonishing what magic people did come up with, given only a day to work on it. Incuna were a really welcoming bunch and made everyone feel at home, and gave us just the right amount of herding: thanks to their foresight, most of the projects we worked on are now available via the Refresh Oxford github account, if you're interested in looking at some of our code. It ain't pretty; but if Rome wasn't built in a day, then these projects were. In your face, Rome.

Christmas wrapping paper and waste

When unnecessary packaging is a psychological imperative, how can environmental and social morals interact?

The Centre for Alternative Technology has blogged about the waste behind Christmas presents. They're absolutely right that, even if you accept that Christmas is going to be about increased consumption, there's far too much overconsumption at Christmas time: consuming above and beyond what you need to in order to have the good time you're after.

A lot of their advice seems to be along the lines of "if you're going to buy something, buy it from our shop." Which is fair enough, if you believe that your shop is the most environmentally aware shop in the country: my guess is it might be, although it's easy even for green enterprises to be non-green when it comes to culturally acceptable practices, especially in terms of postage and packing. I'd love to know how they handle that, and how they work towards close inspection of their own practices.

Speaking of culture, though: wrapping paper remains undiscussed by the end of that blogpost. Which again is fair enough if you're talking about the CAT as a commercial enterprise; but that doesn't stop it being the rustling elephant in the room under your Christmas tree. The post doesn't really tackle it, unless it implicitly proposes you get all your presents delivered directly with a "do not open until Christmas!" label on them and just in brown paper.

There's a huge cultural pressure against unostentatious gift wrapping. My family is predominantly working-class, and their shared culture is just something I don't understand: much as mine is one they wouldn't understand; they'd blanche if I tried to give them presents wrapped in, say, magazine- or newspaper. They'd probably think it was something weird and posh that I'd picked up down south, which isn't far from the truth.

The main problem with plain wrapping remains the sheer boringness of it, when applied to a festival like Christmas that's meant to be about aesthetic excitement and bright colours. A reusable compromise, still with visual impact, might be something like the Japanese Furoshiki tradition, where fabric is used instead of paper. 

This entails its own problems, though: the gift's recipient then has a square of fabric that they have to decide to do something with. If they bin it or even recycle it, then the embedded carbon lost is far worse than if you'd used thin wrapping paper in the first place. It's also a lot more faff than paper, and again, I can't imagine my family reacting well to something like that; although I wish they would!

Ideally it would be easy - and acceptable - for us all to have post-Christmas retrospectives of what resources we'd consumed, and when and why; that way we could take steps the next year to modify our behaviour. But even when so much recycling involves separating things out according to material, there's still that - again cultural - pressure to not look to closely at what you've already decided to throw out. Especially when it's the tinfoil at the bottom of the landfill bin, covered in week-old fat.

HSBC fail

Security reset questions!

https://forums.aws.amazon.com/thread.jspa?messageID=222623

Father's middle name - can't be my father's as his name is too short

Blog category:

Fast cars and big rockets at OGN20

Free drinks too, thanks to Historic Futures. Don't drink and orbit.

We've found the ideal complement to our first keynote for Oxford Geek Night 20 on February 9, 2011. Chris Govias and Andrew Godwin were already booked to talk to everyone present about the recent efforts by /dev/fort to put original NASA transcripts from space missions on the web in a searchable, linkable format. And now, alongside space exploration, we've got... car racing. Alex Powell from Soft Pauer is coming along to talk about their F1 mobile app, which presents real-time track positioning and timing data from the F1 official feeds.

We've already got four microslots booked, including discussions of the evil of pie charts and the joy of transparent swimwear. Before you start thinking about a roomful of geeks all dressed in transparent swimwear, let me distract you by saying that we still need volunteers for The Pitch, our sixty-second open-mic slot where people can pitch any ideas, vacancies, products, local events, meetups, organisations etc. The floor could be yours for up to a minute: email me, jp.stacey on the old GMail, or tweet me (@jpstacey) if you're interested.

On top of all this, Historic Futures have agreed to sponsor drinks: to the tune of one eagerly awaited drink per eagerly awaited geek attendee! They're based locally and they do research into supply-chain traceability. That means helping companies to work out just where all the components of their products come from and how, to improve transparency and good practice across lots of industries. They've also been good eggs in offering everyone at OGN20 a free drink.

Not only that, but we also have the regular sponsorship from Torchbox, meaning entry is still free. So: come along for the fast cars, big rockets and free drinks. How many geek events have that as their strapline, eh?

Blog category:

Even Wired loves OGN19

First Nokia Ovi Store, then data.gov.uk, and now... Wired Magazine?

Last week, Oxford Geek Nights received some brilliant news: OGN19 was going to be sponsored by both the Nokia Ovi Store and Data.gov.uk, HM Government. Organization was well under way, so I popped out for a couple of days to see my family (and to go to my granddad's 90th birthday celebrations. Ninety.)

Meanwhile, unbeknownst to me, top tech magazine Wired had recommended OGN19 on their diary for next week. This perfect storm has happened before, when .NET magazine mentioned OGN4. As I recall, that was one of our best-attended geek nights, despite being in November. I managed to actually be around for that earlier mention, but this one has taken me a bit by surprise.

All in all, OGN19 is shaping up to be a really great event already: as already mentioned we've got some smashing keynote talks planned from Leila Johnston, David Caruana and Florian Müller. Since then we've also booked four cracking microslots, on open-source mobile portals, "internet plumbing", controlling an industrial robot with Twitter, and the battle of J2EE vs Python for web development. And then the funding news arrived. Now that the Nokia Ovi Store are funding a drink per geek, we're almost certain to have a great evening.

So maybe it's no wonder that someone submitted OGN19 to the Wired UK diary. But it was a pleasant surprise nonetheless. I just hope the rather discerning Oxford geeks have all put it in their own diaries too: Wednesday 1 December. Otherwise it'll just be me and Wired UK, drinking a hundred and forty pints. Merry Christmas!

Vimeo and Oxford Geek Nights

Hosting your own mp4 files might get you geek cred, but it's not exactly great UX.

Since the dawn of time, Oxford Geek Nights have used Amazon S3 for delivering its video files. Videos were tidied and encoded into MP4 files, then uploaded to AWS and made available to everyone. On one level this has worked just fine: the cost of S3 per gigabytes of storage and monthly bandwidth is pretty low, and using Amazon's resource delivery framework makes a lot of sense.

But the user experience has been pretty poor: problems with a friend's machine recently really highlighted this, when codecs first of all refused to install, then ruined audio synching in the browser. The workaround of always remembering to click and download is all very well, but not particularly convenient.

With that in mind Wes West, co-worker at Torchbox and performer of that microslot, recently took it upon himself to set up an Oxford Geek Nights channel on Vimeo. If serving files from S3 makes sense, serving video from Vimeo makes even more sense. Vimeo channels are neat and look great, and their servers can deliver video in HTML5 and at a pretty high quality (although embedding still seems to try to force Flash.) Although Vimeo is free for non-commercial use, we did end up getting a Pro account, given the length of keynoter videos, but it's probably worth it in the long run.

Wes has written a bit more about Vimeo and Oxford Geek Nights on the Torchbox blog, but if you're so inclined then you should probably just sit down and watch perhaps our best keynote so far, by Russell Davies, served up by Vimeo. Welcome to the Oxford Geek Night future, maybe.

OGN18 in under two weeks' time

Summer OGN a week on Wednesday, and it looks like it's going to be fantastic.

The next Oxford Geek Night is on Wednesday 21 July, in less than two weeks' time. I for one am really looking forward to it.

We managed out of sheer luck and cheek to bagsy a fantastic speaker for OGN18, the ever-Interesting Russell Davies. Russell was the organizer of the 2007 and 2008 Interesting conferences, and is involved in lots of fantastic projects, including Speechification and Newspaper Club. He's also a writer for Wired, a speaker at many conferences including Lift 2010, and what one might frivolously call a futorologist or pundit. He's going to talk about his experiences turning internets into print, and what he's learned from doing it as part of projects like the Newspaper Club.

Along with our keynote speaker we've got half a dozen of the absolute best of local microslot volunteers. There's talks on topics as far ranging as "designing backwards", linked data, graphing 19th-century social networks, genomics, CSS and Rotacoo's Spotify #fridaymix tape. A few new faces and a few established (and deservedly so) local faces. As always we'll be putting video up on the site afterwards, so there'll be a permanent record of our high-quality speakers.

Finally, we hope to have space for the Pitches - our sixty-second open mic slots that anyone can volunteer for, even on the night - and a book raffle. All told it should be a great excuse to saunter over to the Jericho Tavern in the July sun / sudden downpour (delete as applicable.) Hope to see all the other Oxford geeks there.

Blog category:

Pages

Subscribe to RSS - culture