Outside The Page

Time to stop Microsoft Bashing

Paul Sebborn — Sun, 06 Dec 2015 14:39:58 GMT

Microsoft. The company everyone loves to hate. Especially devs. It's a common theme in any dev circles, and has been for quite some time. People look over snootily at the 'poor, misinformed Windows' user, as if they can't be taken seriously as a dev. I know, I've been guilty of this in the past. But it's time we, as a dev community, stopped this bigotry.

It's bad enough dealing with fanboi-ism from Mac users (disclosure: I'm a Mac user at home, but at work I use Ubuntu), but are we that bitchy that we have to mock people's work based on the OPERATING SYSTEM they built it on? After all, we're all building for the World Wide Web, right? The whole point of the Internet is that it's platform agnostic, and thankfully you can write HTML on any text editor.

Yes, Microsoft have a patchy history. IE6 got a bad rep, but actually when it was released it was a good browser. They just didn't update it for years.. Try comparing it to Mozilla (it wasn't even called Firefox back then!)

In the past, it's arguably right they've had a bad name. The problem is as devs a lot of our attitudes don't seem to have changed. Maybe it's just like The Offspring said - "It's cool to hate" The thing is though, Microsoft's trying, and they've come a long way. They've got great people on their team now, people like Rey Bango, Martin Beeby and Christian Heilman. Also IE11 isn't bad at all!
I've not used Windows 10, but that looks pretty nice too, and I hear good things about Edge. Yes, the Windows Phone might not be as popular or ubiquitous as Android and iOS but that doesn't make it crap.

As for judging people for what platform they choose to write their code, that's just stupid. It's like saying people who have blinds instead of curtains in their house are idiots. Get over yourself and realise that as long as you are creating stuff on the web and having fun - who cares?!

CSS nth-child goodness

Paul Sebborn — Mon, 21 Sep 2015 11:03:50 GMT

Whilst working on a client site at work recently I came across an interesting design / CSS challenge.

Basically, the information on the page is represented by a series of boxes, let's imagine they're numbered 1 to 16. Every other row, the flow will be right-to-left, creating a sort of 'reverse S' layout (see the diagram below, and sorry for the terrible design skills!

If this was a fixed number of items, or even a fixed number of columns, this wouldn't be so difficult. Of course, we live in the modern world, the future web world, so has got to be scalable and responsive (mobile-first, naturally). Oh, and I know "just use jQuery and add a class" is an option, but not for me as I knew it should be possible in CSS.

Knowing that nth-child was a starting point (and knowing all the browsers we needed to support also supported that!) I started off by looking at the awesome article that Heydon Pickering wrote a few months back: Quantity Queries for CSS. This got me halfway there, and although slightly off-track I'd read it if you haven't already as it's brilliant.

Using nth-child(4n+1) would get me the 5th, 9th, 12th, etc elements which was not quite there. By using nth-child(8n+1) gets closer, but also matched the first element in the row. Settling on nth-child(8n+5) gave me what I wanted - the 5th, and 12th items. (An aside: this tool by Chris Coyier is very useful for testing nth-child patterns).

From there it's just a case of adding one for each element after that you want to me. For brevity I just added one layout, but the principle would apply e.g. for 3-columns. I ended up with this:

.item:nth-child(8n+5),
.item:nth-child(8n+6),
.item:nth-child(8n+7),
.item:nth-child(8n+8) {
    float: right;
    // Other fancy styling
}

For a different number of columns, you can work it out like this:

:nth-child(Xn+y)

Where X is the number of columns * 2 (for 3 cols, this would be 6), and Y is number of columns + 1 (so for 3 cols it's 5)

And there you have it! I created a little CodePen for the finished solution; it's a bit messy but you should hopefully get the idea..

DISCLOSURE: I work for Zoocha, so credit where credit's due as this was done on their time :)

Google Chrome and REM units - a little quirk

Paul Sebborn — Tue, 18 Aug 2015 10:48:09 GMT

I noticed something today whilst working on a new client project, that seems to be a bug in the way Chrome calculates rem units.
By default, I tend to set the body font size to 62.5% which works out to be 10px, then it makes the maths for font sizing easier. Today however I noticed that doing this:

html {
  font-size: 62.5%;
}

body {
  font-size: 1.4rem; /* should compute to 14px */
}

…in Chrome, the body text wasn't 14px but in fact 20px. It was ignoring the 62.5% declaration, but only for the body calculation.

Changing this use em instead of rem seems to fix the problem:

body {
  font-size: 1.4em; 
}

As the rest of the site uses rem nothing else is affected.

P.S I did find a bug that seems to suggest this is fixed: https://code.google.com/p/chromium/issues/detail?id=319623 however for me it's still a problem. The above fix worked well for me though :)

Graphical Git Tools

Paul Sebborn — Tue, 21 Jul 2015 11:34:37 GMT

If, like me, you're a dev and you work in a team of more than one (or in fact you work on any project, you probably use Git to track your changes. I personally prefer the command line for committing, pulling, pushing and all things Git-related. One thing I always do when I'm about to commit something (and it should really be a no-brainer) is to review what's changed. No matter how small, it serves as a mini code review and lets me sanity check what I'm about to commit.

The problem is, when you run git diff in Terminal it's a pretty ugly sight, and often baffling if you've changed more than two lines. See exhibit A:

Thankfully however, there are plenty of GUI tools to help out. If you've ever used an IDE with Git integration (such as WebStorm or Eclipse) then you may have seen a nice side-by-side comparison with your changes. Github does it too, and the desktop app also shows your changes nicely. If you're a Sublime Text or Vim (or anything else) user, you can configure Git to use an external diff program.

Try running git difftool in your terminal window. On OSX filemerge will normally be launched by default (in my experience), or meld if you're on Ubuntu. You now get a prettier view (OK, it's Linux so pretty is a relative term):

There are tons of diff tools out on the web, so you're not limited to what's installed by default. A couple of good tools I've stumbled on are:

Kdiff3 is an open source, thus free, tool. It's not the prettiest but it does work fairly well
Diffmerge - I prefer this as it's a bit nicer to reader, but of course it's not free. Probably explains why it's nicer :)

One last thing - where graphical git tools come into their own is with merge conflicts. They will show a 3-way merge between your original and incoming versions, with the merged result in the middle. Much better than spending hours tracking down the ====== and <<<<< combinations that appear in the file normally!
An example of this is here:

It's so much easier to see at a glance what's been changed so you can figure out which version to keep!

Finally - there's some config that needs to be done to tell Git what to do with your new mergetool (if you're using Diffmerge). This gist describes what you need to do (and actually probably summarises this post better!)

Enjoy :)

Handling Office Music Politics

Paul Sebborn — Sat, 07 Mar 2015 13:09:02 GMT

…with a Sonos / NodeJS Veto button!

We recently upgraded our sound system in the office, with a lovely shiny Sonos system. With our ever-increasing staff numbers we soon discovered that our music taste was broadening too! Our previous music choice was more of a dictatorship than a representation of the whole office's music tastes. We did have a shared Spotify playlist that people could add to, but as it was played from one person's computer it would invariably be monitored and offending songs removed. It became apparent this wouldn't really work

With Sonos everyone can install the Sonos app, and add their own choice of tunes to the playlist. A perfect balance: everyone adds music without the threat of filtration. Well, most of them - a good chunk of our devs run Linux and there's no Linux Sonos client. Then again everyone has a smartphone and there's an app for them, so problem solved, right?

Well, not quite. The Sonos app isn't the nicest in the world, plus having to get your phone out and load the app just to change a track seemed to be a pain. I started looking around to see if anyone had written a webclient that we could all access, and found two options:

a Perl-based controller called Purple. I'm irrationaly scared of Perl so I kept looking…
A NodeJS Web controller (Github link. This is more up my street, being a frontend dev!

The original thought was just to have the web player up and running, but then I did some digging and noticed that it's built on top of an API too. (see https://github.com/jishi/node-sonos-discovery)

Inspired by the store opening scene from Empire Records along with a desire to do something tactile and use some of the dev boards I have lying around, I decided to make the office a Veto Button.

The basic idea is simple: a big red button that you wallop if you don't like the song, and it'll skip to the next track.

Technology

I've already mentioned about the Sonos API. It looked like a nice, straightforward answer to my problems. I could write everything in Node for extra hipster points and it'd all be straightforward (I won't have get dirty and write Perl).

To hit Hipster Level: Ninja, I decided to use a Tessel. For those that don't know, Tessel is a microntroller board that runs Javascript. It also has built-in wifi. Perfect for this application: simply connect up a button and tessel push the code up.

The next go-to board was the Raspberry Pi. Being a fully fledged Linux machine this had no problems. It supports Node and has built in networking so it was all plain sailing. Also the GPIO pins provide a nice easy way of adding a physical buttong. I tested this circuit with a little breadboard push button but I've order a big ass red button which will become the final button

The Code

As I've mentioned above, the project is built on top of Node. I included a couple of packages to help:

"sonos-discovery": http://github.com/jishi/node-sonos-discovery
This is a nice package that allows us to find, and talk to, the Sonos system. There are lots of features such as set / get volume, group, etc but for this project I'm just using the discovery and nextTrack method
"onoff": "~0.3.2"
A little helper utility that makes talking to the GPIO pins on the RaspberryPi (including debouncing for example)

Connecting to Sonos

The code for this is pretty straightforward. Once you've reuquired the modules you're dependant on (in my case sonos-discovery, onoff and my Veto library, you can create a new instance with a nice oneliner:

var discovery = new SonosDiscovery();

There are a bunch of mehtods that you can now use to get at your Sonos. For example:

this.discovery.getZones()
this.discovery.getPlayer(playerName)

These should all be self-explanatory so I won't go into it here. There's also some documentation on the Github repo.

Setting up the GPIO

Using the onoff library you can quickly create a link to one of the Pi's GPIO pins, like this:

var button = new gpio(18, 'input', 'both', {
    debounceTimeout: 50
});

Once this is set up you can the watch method to – yep you guessed it – watch for change in value:

vetoButton.watch(function(err, value) {
    if(value == 1) {
      vetoSong();
    }
});

Here we're simply checking if the value is 1, i.e. the button is pressed, and then calling the vetoSong method.

Changing tracks

To change the track, we first need to get the player. As the office only has the one group we've hardcoded a player name ("Reception" in our case) and pass that to getPlayer.
Next, it's a simple case of calling the nextTrack() and BOOM. Track vetoed.

Other bits

We've written a couple of method, pauseAll and playAll, that do what they say. They're not used for anything yet but could be used further down the line (see below for the 'roadmap')

The Button

It's just a straightforward button. For testing I used a little breadboard mounted click switch, but I've ordered a big ass red button that we'll mount properly in the office when it turns up

Future improvements

There's a long list of features that I either want to add or have been suggested to me. A few that we'll add:

Cross-posting to slack
Record all vetoed songs and display on a webpage
- If a song has been vetoed more than three times in a week, automatically remove it from the playlist
Add a big flashing light and play a siren noise when the song's vetoed
Port over to Tessel (might be possible with Tessel 2 )
Hook in with our VOIP system to pause on ring / resume on call end

Full Code

All the code is available on Github, at https://github.com/psebborn/sonos-veto-controller:
Feel free to have a look and if you want to leave any comments, go for it!

Full Frontal 2014

Paul Sebborn — Mon, 10 Nov 2014 17:28:42 GMT

A scatter-brained round up of the day

Last Friday (7th November) was Full Frontal. It's the 3rd (I think) time I've been although I've missed the last couple of years, so I knew what to expect. As usual, my expectations were exceeded and I came away at the end both excited and dazed at the ridiculously good talks. What was nice this year was that while the topics were announced in advance, it wasn't 'til the day that we saw who was talking.

A quick side note: This might be a bit messy and incoherent, but it's content. I've been meaning to have a 'web presence' for a long time now. I've been working on the web for nearly 10 years so it's a bit odd not to have a site! Jeremy Keith said something which struck a chord with me at Responsive Day Out about content being king on the web. Just write something, anything, get it up and out on the web; that was his motto. So that's what this is. Hopefully it'll spur me on to have a 'proper' website but for the time being it's here anyway.

Building the Physical Web together

Scott Jenson

Scott opened the talks for the day, with a talk on The Physical Web project. It's a proof-of-concept type project from Google, about trying to find a better way of interacting with the web. "URLs are 70s s**t". His point was that we improved everything the browser displays, but we're stuck in the dark ages of manually typing in a web address each time.

Update: To clarify, Scott wasn't saying he was anti-URL entirely - just that typing them in isn't exactly user friendly. Technology has advanced in every other aspect of the browser, maybe it's time to update URL input?

QR codes went a way to solving that but they're pretty awful. iBeacon is a clever way but it's sandboxed to an app. 15 iBeacons from 15 stores = 15 different apps.
The Physical Web is an attempt to create a new standard for broadcast URLs over BLE (but not push; only when you request to find beacons - an important distinction)

Also, we all got a BLE beacon to play with, which is rather awesome!

Moving seamlessly through offline and online

Caolan McMahon

Picking up on the Offline First ideology of Hood.ie, Caolan's talk showed us a simple way of implementing an app offline, and then syncing it up with a CouchDB instance. A really slick presentation, he live coded the whole thing - LOLBin, an offline first joke database (poking fun at Remy's JSBin).

There were some nice concepts there including distinguishing between edited, saved and synced items to help the user know what's where. It's certainly given me inspiration for a project I've been meaning to do for ages, so fingers crossed I get round to it now!

Navigating Open Source

Hannah Wolfe

Hannah Wolfe gave a brilliant talk about Ghost, the open source blogging platform (in fact, this post is running off Ghost at the time of writing!). They always wanted to be an open source project, and she talks about the process they went through.

To start with Ghost was crowdfunded on Kickstarter, and developed as closed source. This was just to get the project up and running Hannah explained, and quickly they opened up to a few contributors as an invite-only model, to help flesh out the project. This meant that when they launched, and opened the source to everyone, they already had a history of open source - with commits, issues, etc that meant people could already get stuck into contributing.

Some interesting lessons learnt along the way, it's all about trust. Letting go and allowing certain trusted contributors commit rights was a tough decision but ultimately improved the end project. The key take-away was just three words: "Hi", "Welcome" and "Thank you" – words that are often forgotten in OpenSourceLand.

Self-hosted JS

Andy Wingo

Andy Wingo took the live coding to a different level. He is a contributor to V8 and other JS engines, and went through the process of adding to the JS core. Quite a bit of the JS engine is written using Javascript. I know. Weird. And Weird Javascript it is: for example you don't get real error handling because at the time of running your code, the error handling code isn't there yet!

I confess that most of this went over my head but it was fascinating to watch, and a really entertaining talk to sit through. It did make for an eye-opening session and left me thinking how little I know about the inner workings of JS engines.

Lean Mean CSS Machine

Tobias Ahlin

Tobias had the un-enviable position of post-lunch talk. Luckily for him he's a really engaging speaker, and kept everyone's attention talking about good quality CSS. This covered two parts: one part guidelines, and the other refactoring CSS.

The guidelines part was really intersting as I'm currently going through this process at Zoocha. It was nice to see that we both have similar ways of thinking (which I'm taking to mean I'm on the right track!)

The refactoring CSS demo was really interesting, and although it was a little drastic (binning some UI elements as unnecessary bloat), it showed a really simple, workable approach to cutting back on CSS cruft. This'll be handy in the future, definitely.

A Single Page Story

Henrik Joreteg

Henrik attacked the sensitive subject of single page apps, or web apps, or whatever you choose to call them. The challenge - "Is it OK to write web(app|sites) that rely on Javascript?". His take on it is yes, in certain cases.

He coined the name of Native Web Apps. I think this sums it up. There are some instances where latest technology e.g getUserMedia can't be progressive enhancement (there's no fallback currently). Serving JS-only sites is in his opinion OK. I'm not sure I agree with it, but I see where he's coming from.

There was a question raised about "server-side initial render" (where the HTML is first rendered on the server, then the JS takes over from there). AirBNB did this approach with their tool, Rendr, but Henrik's argument is that currently we don't have the tooling to make this feasible.

Jury's out, but a good talk nonetheless

Tools for the 21st century musician

Soledad Penadés

Soledad turned up the fun factor a bit in the afternoon, showing us all about the Web Audio API and what you can do with it. Synths, loops, crazy noises. It was all in there.

It also served as a springboard to talk about her new project, Open Music, which is well worth a look

Getting Close with the Web

Ben Foxall

In the Full Frontal's I've been to in the past, the last talk of the day is usually a showstopper (the first one had Seb Lee-Delisle live-coding a 3D Unity world!), and this one did not disappoint.
Ben used the crowd's mobile devices, to create an audience Jumbotron. Building on Seb Lee-Delisle's Pixelphones project, he used a simple three button (left, right, down) scan line approach to plot the locations. Then, each phone became a 'pixel' (and speaker), and was synced to show a rainbow effect, that moved around the room. Oh, and the sound moved round with it too.

All done with frontend technology, and according to this tweet, all done offline too!

Summing up

There's a reason Full Frontal sold out in 9 minutes this year: it's awesome! I did feel a similar anxiety when trying to get a ticket, that I feel when trying to get Glastonbury tickets. It's totally worth it though. I like how Remy hasn't bowed to pressure and put it in a bigger venue as I don't think it would work. Its intimacy is one of the things that sets it apart from the megabuck conferences like FOWA.

I want to recommend you go next year, but then there's more competition for my ticket, so how about you stay away?!