Rodney Rehm

You could have my day job

nospam@example.com (Rodney Rehm) — Wed, 28 Sep 2016 22:44:00 +0200

Ok, you can't have my job, but one on my team. We currently have 3 open frontend development positions (junior to senior). In this post I'll outline my life at Deutsche Telekom to give you an impression of what working here is like. I'm not exactly a fan of official job descriptions. In fact, I wouldn't apply to them myself. While I can't do anything about that careers "website", I can share some insight…

My story

Let's start at the beginning. About 5 years ago I got to know Sebastian Golasch at a conference's dinner. That evening I declared that I would never ever work for Deutsche Telekom, after listening to a Freelancer rant about working on a Deutsche Telekom project. A few months later I was contracting on a Deutsche Telekom project. A year later I gave up 10 years of freelance and became a full-time magenta employee. I've been working on this product for 4 years and at the company for 3 years and I have no intention of leaving.

My motivation

I've always wanted to empower people. For the first half of the last decade that meant empowering not-very-technical mid-level managers to manage electronic workflows and data structures. While I certainly learned a lot doing that, I wasn't particularly connected to the product or its users.

I've always been a fan of misappropriation (today we'd call it "hacking"): Modifying tools (software, physical objects) so they can be used for tasks they were not originally designed for.

I grew up with Lego and I write software, so it's natural to think in small (insignificant) blocks that, when combined, solve a problem.

I've found all of that working on this product. A product that actually can change people's lives in ways we may not even understand yet.

My status quo

When I joined the product I saw a number of problems with how things were done (or not done at all). These problems weren't necessarily of technical nature. I wasn't happy with how the product was built. The separation of concerns (on a team level) was wrong. A few things looked like a pile of duct-tape spaghetti. The user experience wasn't great (euphemism). Communication and collaboration wasn't a thing. And. So. On.

I'm happy to report that most of these issues have been squatted since then. 4 years ago we were in "startup" mode, meaning we tried to get things done quick, rather than well. Today we've curbed the "quick" and (mostly) focus on the "well".

It certainly wasn't me improving all of that, but I've had a (Trump-sized) hand in a few of those topics. This led to a certain feeling of ability to improve things for us, the product and the consumer - and that's what's keeping me entertained.

Enough narcissism, let's get to what we work on and how we do that…

What we work on

The general topic is IoT (Internet of Things). My team builds the customer facing web frontends of the Qivicon Platform which is the base of Deutsche Telekom's Magenta Smart Home.

We connect "everyday objects" (e.g. Philips Hue, Netatmo, eQ-3, and lots more) and allow them to communicate with each other. Since these "smart devices" can be rather dumb, it's the web UI's job to make this stuff as simple as possible. In the end we take care of all the UIs for maintaining a smart home.

This product allows people to rewire how their home works - and we are making sure that it's managable by people without a degree in computer science.

The tools we use

We have a number of legacy apps built on top of Backbone and Marionette. New projects are starting with Vue.js. We're planning to gradually move everything over to Vue - and this is something you'd be working on with us. But changing stacks like that takes time, so you'd also help us maintain the legacy apps until they're converted.

The legacy apps use grunt and other prehistoric tools. The Vue stack is built on top of Webpack and offers some of the modern amenities that instantly make you a 10X developer, simply by knowing their names.

We are big proponents of web technology, meaning we favor standards like Web Components over things like React and JSX. If you're looking for Angular, React, Ember or whatever today's framework is, stop reading. You won't be chasing the newest hottest tools with us.

We manage our code in git repositories powered by Bitbucket (formerly Stash).

While the frontend stack pretty much is all JavaScript, we're part of a Java ecosystem. None of us frontend developers really do any Java, but we are using things like Maven and Nexus. Some parts of a website we maintain is written in PHP.

Everyone uses the editor or IDE they want. Some use a GUI for git, but most of us prefer the command line for git (and anything, really). Ultimately you're free to choose the tools you feel comfortable with.

Pretty much everyone here works on a MacBookPro. If you prefer Linux or Windows, you can have that, too.

Team work

Currently we're 4 frontend developers, 2 designers, 3 QA engineers, 1 product owner and 1 scrum master. And we're looking for 3 additional frontend developers.

We're split between Germany and Bulgaria. Ze Germans work in Darmstadt. Some are here for 3 days a week, working 2 from home. Some are here all the time - because they happen to actually live in Darmstadt. We also have offices in Bonn and Berlin, which could be used if you don't feel like Darmstadt is your city. We try to see everyone at the office on Tuesday and Wednesday.

The team communicates (in English) via chat and video conferencing. Official meetings are usually done with WebEx.

We manage our work with Jira and document things in Confluence. We generally try to avoid mail.

Development process

We currently work in Kanban and some of the other teams work in Scrum mode. Our process looks as follows:

Designers create their proposals consulting with developers early on.
Developers implement things, usually doing another dance with designers.
Implementation ends with a code review (pull requests via Bitbucket).
Once the product owner signs off, our QA engineers go to work creating automated tests and manually run things in various browsers.
If the testers don't find any issues (haha, of course they always do!), our code is delivered to the next stage of QA.
The central QA team runs another round of extensive end to end tests on all of the product's systems on a platform similar to the production servers.

Our sprint cycle is 2 weeks. With the QA team "lagging behind" by 1 sprint, our software reaches the customer approximately 1 month after we've written it.

We're working in these stages for a reason. In development and integration we have access to pretty much everything. In production we have access to nothing. We have to go through the proper channels to obtain log fragments from production servers. Data privacy is kind of a big deal around here.

To web developers accustomed to creating web sites the staging concept and the two instances of QA may seem a bit odd. But in a system where your customers' well-being can be at stake, you just can't have enough QA. And even with our setup lots of issues fall through - because this stuff is getting real complex real fast.

What about open source?

The system is based on eclipse smarthome. The project's lead sits in shouting distance. Our Runtime team contributes extensively. They also work on other projects like jUPnP and JmDNS.

The frontend developers don't have any official projects like that. But we've created and shared (and maintain) the odd project like wemo-client, ally.js, sass.js, viewport-units-buggyfill and more. A couple of years ago, when we were unhappy with how we write tests, Sebastian created DalekJS. And of course we've contributed bug fixes to most of the tools in our stack.

What are the perks?

We're not really into foosball tables and stuff like that - so, none of that "useless frathouse fun stuff", sorry. There's all-you-can-drink coffee, water and tea. If you need pop soda, candy or similar, get some at the kiosk downstairs. I'm not sure what to tell you here. I've seen Google's and Facebook's offices. While it sounds fun, I've never missed any of that.

Conference-wise we have different situations. Some of us attend one conference a year, with expenses covered by Deutsche Telekom. Others attend a few more and get that time off, but cover the expenses themselves. In 2016 I'll have attended 8 conferences). We'd be happy to take you along the ride :)

I think everyone has 30 days of vacation. Past 22:00 nobody gets into the office anymore because we shouldn't be working anymore anyway. We're told to work sustainable hours. It's up to us, nobody checks when or how much we really work. But if someone realizes that you're putting in too many hours, you'll be called out on that and asked to take more care of yourself.

I'm not saying there's no pressure to deliver things, but I haven't had to pull an all-nighter since I began working here in 2013. Things are done when they're done. While we may be asked to make something work by a certain deadline, it's far more common to push the deadline or re-define scope of delivery. People are here to create a great product, not to burn out.

Why this job is important

Smart Home and Internet of Things are fairly new consumer markets. Technology and devices have been around for a while, but emerged in silos and often with questionable user experience.

The product we work on is focused on breaking or connecting these silos. Our team is responsible for making the management of these connected devices as intuitive and easy as possible. We empower people with limited technical skills to accomplish technical tasks. We make this stuff usable.

What you'll learn on this job

I'll be pestering you with semantic html, accessibility, CSS, debugging and understanding browsers. We're working with the "Web Platform", and that means understanding it.
Sebastian will be annoying you with the newest technologies and performance tricks. We're working in a realm of constant change. While we don't adopt every new technology right away, we do need to be aware of them.
Timon will share his thoughts on how to write clean and maintainable code. We don't create projects that will be re-created from scratch by another agency 3 years down the road.
You'll learn that we have things to learn from you, too.

We transfer knowledge mostly through comments on pull requests. Also we have an hourly cigarette break that we use to catch each other up and pick each other's brains. (Not everyone smokes during these breaks, though ;)

What now?

If you're interested in what we're doing and how we're doing it, consider working with us!

On Telekom Careers search for "Smart Home" and chose the profile that suits you best ("Software Entwickler" also applies to the frontend positions). If German isn't your language, or you have questions, ping me on twitter.

Twitter pings

These questions popped up on twitter:

Do I need to know JavaScript? Yes. It's about 80% of what you write. We create reusable components, that once done mean we don't have to touch the HTML or CSS anymore. You won't need to invert a binary tree on a whiteboard, but you definitely need to know your way around JS.
Can I work from remote? Yes and no. As an employee of Deutsche Telekom you need to be "stationed" at one of its offices. In our case that's Berlin, Bonn or Darmstadt, where you'll have to spend 2-3 days of the week. (I don't live in either of these cities, but not everyone is comfy with living in hotels…)

jQuery ContextMenu Is Moving On

nospam@example.com (Rodney Rehm) — Tue, 18 Aug 2015 19:20:35 +0200

On July 7th 2011 I published my first "serious" jQuery plugin - a context menu manager. Today, 4 years later, I'm waving good bye and wishing it the best of luck on its upcoming journey with its new maintainers from swis.nl. In 2011 I was working on an application where a lot of UI elements needed to expose a context menu and none of the then "state of the art" jQuery plugins could handle the load. So I did what anyone does in that situation and created a new plugin. Back then HTML5 was still new, in flux and exciting and I wanted to make something that was along the lines of <menu> (which did not make it into HTML5, but is part of HTML5.1). With a little help by Addy Osmani my plugin was able to act as a polyfill and work with the "native context menu" implementation in Firefox. Features were added and the interest in the plugin grew. Over the course of 3 years almost 50 versions got released. And then I lost interest.

In late 2012 I abandoned the software I needed the context menu plugin for. Until January 2013 I kept maintaining the plugin and pushing updates without having any use for it myself. And then I realized that I did not have time to maintain software, that I did not use myself, for other people for free. I stopped maintaining the plugin, stopped replying to issues or looking at pull requests. On May 21st 2015 I decided things had gotten too hairy for anyone to use this plugin and put up a notice that the project was looking for a new maintainer. At that point some 89 issues and 27 pull requests were hanging high and dry. I needed a way out of the "obligation to maintain my software", and the notice did the job of clearing my conscience.

Last week Björn Brala of swis.nl got in touch and informed me of their interest to take over the project. He made sure there was a budget for maintaining the project beforehand. And made clear that they were not looking to commercialize the project itself, but continue maintaining it open source, so they could continue using it in their commercial projects.

Today we transferred the repository to its new home in the swisnl organization. The change-free version 1.6.8 has been published to bower and npm and a few gh-pages redirects will make sure that existing links to the project's website find their way to the new home. As of today Björn and the swisnl team are the owners and maintainers of jQuery-contextMenu. I wish you the best of luck with your new project!

Presentations Involving Physical Things

nospam@example.com (Rodney Rehm) — Sat, 13 Jun 2015 16:36:48 +0200

Let's assume you're in a situation where you have to show a physical object during a presentation to 20 or more people. The current default is showing a static picture of the thing on the projector and possibly holding up the real thing so the first few rows of the audience might get a glimpse. What if I told you there's a better way? Working in the Internet Of Things segment, I'm constantly dealing with, well, a lot of things. Those things tend to be small enough to fit in my hands. Considering we're "agile" (whatever that means to you), we have to present our work in two week intervals. Considering we're a distributed team, we live-stream those presentations all over the place. People may be sitting in one of three offices or even their homes while passively watching - or actively giving - the presentation.

In our biweekly reviews we use WebEx, in ad-hoc presentations we may use Google Hangouts or appear.in or Skype or whatever tool we could settle on. Most of us use macs, some are on Windows and everyone has an iPhone or some Android phone.

The goal is to stream what's happening in the room along with the actual presentation content to both, the projector and the remote client. The constraints are uncertain video conference tool and lack of specialized hardware. The solution is so simple, it took us ages to figure it out.

We're streaming our phone's camera image to our computer screens, which in turn end up on the projector and the remote client. In some scenarios you can manage this with built in mechanisms, in other situations you'll want to buy a $15 license for ReflectorApp. All you need to do is start the application on your computer, make your phone mirror its screen (using AirPlay, Google Cast, …) and open the phone's camera app. Et voila: instant wireless, handheld video camera that allows you to include the real-world in your presentation. It's so simple, it almost hurts.

Granted, we haven't used this technique particularly often and not at all in months. It's at conferences that I get reminded of this idea time and time again. I try to talk to the speakers after their shows containing little things on stage that nobody could see past the fifth row and explain that I couldn't see what they were showing off. Never mind the people watching the videos of the talks will likely not see all that much either. The discussion usually ends in a good laugh about not seeing the obvious: using your phone as a mobile camera to get your physical interactions on the big screen.

The same thing happened again just now - finally prompting me to write this post. I saw Tim Pietrusky showing his NERDDISCO at KarlsruheJS, luckily I was sitting in the first row and filmed a bit of what I was seeing

The show was partly about what was being projected - a web browser's canvas reacting to some audio and getting additional input from a midi device - and the comparably tiny LED cube Tim built and programmed to visualize sections of the browser's canvas. Tim created some fantastic stuff right there. His show was a far cry from bad. But people sitting away 15m from the pedestal couldn't enjoy what I was seeing.

Here's a screenshot of how streaming your phone's camera to your computer screen might look in real life.

Phone's camera mirrored onto computer screen

Ignore the camera app's interface and focus on the content. Ignore that you'll have to leave your fullscreen presentation for a moment. Ignore the little imperfections and focus on what you just gained: Everyone is able to see. A screencast will contain not only the presentation, but also the real life thing.

You may not need localtunnel or ngrok

nospam@example.com (Rodney Rehm) — Thu, 28 May 2015 01:09:20 +0200

It's become a custom amongst web developers to write »you may not need $insert_tool« posts. Continuing with that tradition, here's my stab at why you might not need localtunnel.me and ngrok.com. Today's tool in question:

localtunnel exposes your localhost to the world for easy testing and sharing! No need to mess with DNS or deploy just to have others test out your changes.

As naming things is hard, we have a JavaScript localtunnel via npm, a python localtunnel via ruby gems and a go localtunnel available to us. And there are the prominent services localtunnel.me and ngrok.com

When I shared that on Twitter the other day, I got two responses going different directions. On the "positive" side there was Dirk being surprised localtunnel was now on npm and explaining how useful the tool is for conferences and demos. The "negative" side was Tobias, complaining how you don't need any of that, if you'd only understood SSH. What he neglected to mention is that you also need your own server that you can connect to via SSH.

Having my own root servers and dot wanting to die dumb I investigated SSH Reverse Tunneling and with a bit of help from Christian finally figured out what I needed to do.

Configuring sshd

Let's first check if we even need to configure anything at all. Connect to your server ($server) and with privileges (su or sudo) run the following command:

sshd -T | grep -E 'gatewayports|allowtcpforwarding'

the output looks like this (with yes and no depending on your current configuration):

gatewayports no
allowtcpforwarding yes

We need to make sure both values are set to yes in the sshf config file - usually located at /etc/ssh/sshd_config, or /etc/sshd_config if you're on a Mac.

User-Specific sshd Configuration

You can limit the privilege of port forwarding to your own user by using a Match User statement:

# allow reverse tunneling only to the user rrehm
Match User rrehm
AllowTcpForwarding yes
GatewayPorts yes

To verify the configuration specific to your user, run the following command providing your username and port to bind. The other options don't really matter, unless you've added more limitations to Match (see Limit access to openssh features with the Match option for inspiration).

user=rrehm
port=12345
sshd -T \
-C user=${user} \
-C host=* \
-C addr=* \
-C laddr=* \
-C lport=${port} | grep -E 'gatewayports|allowtcpforwarding'

again, this should output

gatewayports yes
allowtcpforwarding yes

Opening SSH Reverse Tunnels

With sshd configured, all we need to do is tell ssh which port we want mapped:

user=rrehm
server=example.org
remotePort=1234
localPort=80
ssh ${user}@${server} -R ${remotePort}:localhost:${localPort}

If you only want to bind the ports but not actually have a shell opened, add -N:

ssh ${user}@${server} -N -R ${remotePort}:localhost:${localPort}

when you're done, Control C will terminate the SSH connection and your local server will no longer be available remotely.

Making SSH Reverse Tunnels Reconnect Automatically

If you want your tunnel(s) to automatically reconnect (when switching WiFis, for example), have a look at autossh (available via brew install autossh):

#!/bin/bash

# it's usually a good idea to exit upon error
set -e

# your connection parameters
user=rrehm
server=example.org
remotePort=1234
localPort=80

# some stuff autossh needs to know
AUTOSSH_SERVER_ALIVE_INTERVAL=30
AUTOSSH_SERVER_ALIVE_COUNT=2
export AUTOSSH_POLL=30
export AUTOSSH_GATETIME=0
export AUTOSSH_LOGFILE="/tmp/autossh.log"

# clean up log file on start
touch "${AUTOSSH_LOGFILE}"
rm "${AUTOSSH_LOGFILE}" || true

autossh -f -M 0 \
-o "ExitOnForwardFailure yes" \
-o "ServerAliveInterval ${AUTOSSH_SERVER_ALIVE_INTERVAL}" \
-o "ServerAliveCountMax ${AUTOSSH_SERVER_ALIVE_COUNT}" \
-A ${user}@${server} \
-R ${remotePort}:localhost:${localPort}

Conclusion

You can expose local services on your remote servers, given you have a server you can SSH to. Using autossh the tunnel can be re-established automatically when it collapses. While this solves most of my personal problems, it is still inferior to ngrok. The vanilla SSH approach knows nothing about the protocols in use. It simply forwards a port, regardless of the service (HTTP, MySQL, SMTP, …). With a simple ngrok http 8080 you'll have remote access to your local webserver through HTTP and HTTPS - even if your local webserver only sports HTTP.

Starting CLI Services In Sequence

nospam@example.com (Rodney Rehm) — Tue, 10 Jun 2014 18:08:08 +0200

Running a couple of scripts in a row is no problem for Bash, but running them in parallel is more tricky. It gets even more ridiculous when on script needs to reach a certain state before another can start. This post illustrates how I solved this work using AppleScript. ## The Problem ## {#problem}

Before we get to the solution, let's look at the problem first. The concrete task at hand (rather sequence thereof) looks like this:

open an SSH tunnel, let's call it Fred
open an SSH tunnel through Fred, let's call it Bob
download a couple of things through Bob
start a service that logs to the TTY
invoke a client that does something with the service,

Every task is dependent upon the one previous to it. It's a classic, linear dependency chain. Were these tasks finite, a bash script could look as simple as

./call-fred.sh
./call-bob.sh
./download-stuff.sh
./start-server.sh
./run-client.sh

But since, with the exception of download-stuff and run-client, everything is a service, the processes never end, so the next line of the bash file would never be invoked. You could "daemonize" the tasks, so they run in the background. But in the case of call-bob (where I get a remote shell) and start-server (where I get a local console) daemonizing wouldn't do much good.

Meet AppleScript

Luckily Apple has automation features built into OSX. For applications that expose themselves to this API all sorts of "funky" things are made possible. For iTerm this means that we can control the windows themselves, throw keyboard events at the terminal windows and more. They are scriptable through AppleScript - a language that does not only sound wrong, but looks like it was designed for three year olds. Have a look at this example.applescript for the basic boilerplate.

NOTE the ¬ character is the "ignore this line-break" escape like \ is in bash.

#!/usr/bin/osascript

tell application "iTerm"
tell the current terminal
activate current session

-- required to leave the session occupied by osascript
tell application "System Events" to keystroke "d" ¬
using {command down, shift down}
delay 0.5

tell the last session
-- run `echo 'Hello World'`
write text "echo 'Hello World'"
end tell

-- can be repeated as often as you want
tell application "System Events" to keystroke "d" ¬
using {command down, shift down}
delay 0.5

tell the last session
write text "echo 'Oh look, a Split Pane!'"
end tell

end tell
end tell

What this example doesn't show is that opening the third split pane will not wait for the first echo to finish. This is happening in parallel. But since we need to make sure that the preceding task is in a certain state, we can use the following snippet to block until we're certain we can continue:

#!/usr/bin/osascript

tell application "iTerm"
tell the current terminal
activate current session

-- required to leave the session occupied by osascript
tell application "System Events" to keystroke "d" ¬
using {command down, shift down}
delay 0.5

tell the last session
-- run `./call-fred.sh`
write text "/bin/bash /path/to/call-fred.sh"
repeat while contents does not contain ¬
"fred is ready for business"
delay 0.01
end repeat
-- won't reach this line before "fred is ready for business"
-- was printed to the terminal
end tell

end tell
end tell

Should I Repeat Myself? has some more example loops. That doesn't look very sexy, but it gets the job done. To make the thing a bit more readable, we can introduce functions:

#!/usr/bin/osascript

tell application "iTerm"
tell the current terminal
activate current session

-- required to leave the session occupied by osascript
my addSplitPane()
my runAndWait( ¬
"/bin/bash /path/to/call-fred.sh", ¬
"fred is ready for business" ¬
)

end tell
end tell

on addSplitPane()
tell application "iTerm"
tell the current terminal
activate
tell application "System Events" to keystroke "d" ¬
using {command down, shift down}
delay 0.5
end tell
end tell
end addSplitPane

on runAndWait(command, response)
tell application "iTerm"
tell the current terminal
activate
tell the last session
write text command
repeat while contents does not contain response
delay 0.01
end repeat
end tell
end tell
end tell
end runAndWait

I had hoped that you could save a session to a variable and replace the tell the last session with tell mySessionThing to interleave concurrent tasks. Well, you can, but a session refers to something that is not the split pane. To cover that I'd have had to send keyboard commands to navigate the split panes - making it necessary to know which one your in. That sounded like a very dumb idea, so I dropped the little optimization and ended up with simply opening new sessions instead:

#!/usr/bin/osascript

tell application "iTerm"
tell the current terminal
activate current session

-- open SSH tunnels
my addSplitPane()
my runAndWait( ¬
"/bin/bash /path/to/call-fred.sh", ¬
"fred is ready for business" ¬
)
my addSplitPane()
my runAndWait( ¬
"/bin/bash /path/to/call-bob.sh", ¬
"bob here, hello?" ¬
)

-- update code base
launch session "Default"
delay 0.5
tell the last session
write text "/bin/bash /path/to/update.sh"
end tell

-- start server (in parallel to code base update)
launch session "Default"
delay 0.5
my runAndWait( ¬
"/bin/bash /path/to/update-server.sh", ¬
"[INFO] BUILD SUCCESS" ¬
)
my runAndWait( ¬
"/bin/bash /path/to/start-server.sh", ¬
"State Change from INITIALIZING to ACTIVE" ¬
)

-- do something with server
launch session "Default"
delay 0.5
tell the last session
write text "/bin/bash /path/to/client.sh"
end tell

end tell
end tell

on addSplitPane()
tell application "iTerm"
tell the current terminal
activate
tell application "System Events" to keystroke "d" ¬
using {command down, shift down}
delay 0.5
end tell
end tell
end addSplitPane

on runAndWait(command, response)
tell application "iTerm"
tell the current terminal
activate
tell the last session
write text command
repeat while contents does not contain response
delay 0.01
end repeat
end tell
end tell
end tell
end runAndWait

And run the thing with osascript the-file.applescript && exit. The exit part is required for the (successfully) finished script runner to go away. Only if there was an error, would the output of osascript remain visible.

This may not seem like much, but in this particular case I simply boot my machine and 10 minutes later have an up-to-date and fully initialized system to work with. I'm looking forward to a new morning routine :)

Always Run Script As Root

nospam@example.com (Rodney Rehm) — Fri, 06 Jun 2014 14:42:54 +0200

Shell scripts (often referred to bash scripting, even though it's not necessarily bash) are a great way to automate certain things. Every now and then those scripts have to be run with privileges - in order to, say, register a network interface alias or bind a low-port.

## Force Root ## {#force-root}

# ensure running as root
if [ "$(id -u)" != "0" ]; then
exec sudo "$0" "$@"
fi

This allows me to call a script either with sudo ./the-script.sh or simply ./the-script.sh and thus not have to add sudo in front of all commands within the script.

Automatic Root

If you want to get rid of having to enter a password for a specific script, sudoers is your friend:

open terminal
run visudo
move down to the end of the file
press i (for "insert")
add username host = (root) NOPASSWD: command (which can be rrehm ALL = (root) NOPASSWD: /usr/local/bin/the-script.sh)
press ESC (escape)
press : (colon to enter command mode)
write wq (for "write quit")
press enter

Since you won't have to enter your root password anymore when running the-script.sh, you want to make sure that only root can edit the file so nobody can abuse this script to run arbitrary commands as root:

open terminal
run sudo chown root:wheel /usr/local/bin/the-script.sh
run sudo chmod u+rwx /usr/local/bin/the-script.sh (to allow root reading, writing and executing)
run sudo chmod go-w+rx /usr/local/bin/the-script.sh (to allow everyone to execute and read, but writing)

and that's it, run the-script.sh in the terminal, as root, without having to enter a password.

Including Data From Github

nospam@example.com (Rodney Rehm) — Sun, 16 Feb 2014 13:31:56 +0100

We use services like JSBin, JSFiddle, Dabblet and Codepen to quickly make examples and demos available online. We do this to show interactive things on our blogs and to provide a test-case when submitting issues. Some of us even use these services for development. All those services have one problem, though: including JSON files, scripts and resources from Github is not possible out of the box. ---

TL/DR: Use rawgithub.com and CORS Proxy to load resources from Github and use them in your fiddles. Read The Naughtyness Score for more information.

It's not the services fault that a simple JavaScript file can't be loaded from a repository on github. Github actively prevents anyone from hotlinking resources. And in all fairness, this is a good thing. If Github wasn't taking steps to prevent traffic abuse, people would simply load all their files from Github servers, rather than using CDNs or their own infrastructures.

This is important! Never abuse the advice given in this article in production systems. Only do this for tinkering and providing demos on one of the fiddle-platforms.

As a library author I'd like to provide fiddles to my libraries so people can play around with things. More importantly I want people to provide test-cases when filing bug reports.

Say I wanted to show you how URI.js does URI normalization, I'd provide a fiddle with the following content:

And that would work in Firefox, but fail in Chrome - try this fiddle in both browsers.

How Github Is Preventing Hotlinking

Before we get into solving the problem, let's first have a look at what is causing this behavior. We can see the HTTP headers sent by Github by using curl on the command line:

curl -I 'https://raw2.github.com/medialize/URI.js/master/src/URI.js'

stripping out the noise we're left with the following "offending" headers:

Content-Type: text/plain; charset=utf-8
Access-Control-Allow-Origin: https://render.github.com
Content-Disposition: inline
X-Content-Type-Options: nosniff
X-Frame-Options: deny

`Content-Type` and `Content-Disposition`

The first issue is Content-Type: text/plain. All text resources are sent as plain text, no matter what they really are (text/css, text/html, text/javascript, application/javascript, application/json, …). Unless a file is said to be text/html, a browser won't render the HTML, but print the text instead. (ignoring mime detection, explained later in this post)

For binary files, like videos, the proper mime-type is sent, e.g. Content-Type: audio/webm. But by using the Content-Disposition: attachment header, Github instructs the browser to show a save to disk dialog, rather than rendering the content.

Images (PNG, JPG, GIF) are served in a way that allow out-of-the-box inclusion.

`Access-Control-Allow-Origin` - preventing CORS

By setting the Access-Control-Allow-Origin header to https://render.github.com rather than * (everyone), Github explicitly forbids loading resources via XHR (XMLHTTPRequest - often referred to as AJAX).

`X-Content-Type-Options`

By setting the non-standard header X-Content-Type-Options: nosniff Github instructs browsers (currently Internet Explorer and Google Chrome) to not guess the content type by looking at the content. For compatibility reasons Internet Explorer could determine that the content is HTML and overwrite Content-Type: text/plain to Content-Type: text/html. More on this in IE8 Security Part V: Comprehensive Protection (scroll down to MIME-Handling Changes).

`X-Frame-Options`

By setting X-Frame-Options: deny Github forbids browsers to embed that content in an iFrame.

Using A Proxy To Circumvent Hotlink-Prevention

Now that we know why our browser's won't let us include raw Github resources, it's time to introduce rawgithub.com. It's a proxy service stripping Github's "offending" HTTP headers and adding a proper content type. By replacing your original URL https://raw.github.com/name/repo/… with https://rawgithub.com/name/repo/… (notice we only removed the . from raw.github) you're ready to go. The service's source is available at rgrove/rawgithub.com, should you want to run the proxy service yourself.

Caveat: rawgithub.com won't proxy binary files. Images and videos are forwarded (301 Moved Permanently) to the original location on Github. For images this works well, for videos it won't.

Because rawgithub.com also adds a wildcard CORS header (Access-Control-Allow-Origin: *), you can access all your data with XMLHttpRequest.

You may also want to load data off another domain than just your Github repositories. For use with XMLHttpRequest the corsproxy.com can ease your pain. Be aware that corsproxy does not work on Github's content.

Using rawgithub.com for a gist

On the rawgithub.com website they claim support for gist.github.com - and it works, but with a small caveat.

When you create a gist, you don't know its URL beforehand. The raw URLs of files within a gist aren't guessable, as they contain a hash that is unique to each file and revision. I'm not sure where this hash comes from, but it's got nothing to do with the git commit.

Anyway, you can create a gist containing multiple files (index.html, style.css, script.js) like I did in this this demo gist. Within the index.html you're likely to include style.css and script.js as relative resources. When asking the gist.github.com UI for the raw view of index.html, you're pointed to rodneyrehm/9020346/raw/9a835b17cd45b3ac2c0c91d7e5fd146ef32c65f3/index.html. One might assume changing the filename from index.html to script.js would show that file, but it doesn't, it still shows the content of index.html. So file identification is performed through the hash (9a835b17cd45b3ac2c0c91d7e5fd146ef32c65f3) rather than the file (index.html).

The next logical step would be to identify the proper raw URLs for style.css and script.js and change their inclusions within index.html accordingly. But it turns out this really isn't necessary. Removing the hash from the raw URL gives you the resource at the HEAD commit (i.e. the most recent version): rodneyrehm/9020346/raw/index.html. Change index.html to script.js and you'll actually see the script's content.

Now that relative URLs can be resolved properly, it's time to replace gist.github.com by rawgithub.com and view our gist properly rendered by the browers: https://rawgithub.com/rodneyrehm/9020346/raw/index.html.

Conclusion

There are ways around the Same Origin Policy and Github's foreign resource inclusion restrictions. Make use of them when tinkering with libraries hosted on github. Make use of them, when providing example fiddles. Never use this in production environment - See The Naughtyness Score for more information.

iOS7 - Mobile Safari And Viewport Units

nospam@example.com (Rodney Rehm) — Fri, 24 Jan 2014 09:33:43 +0100

The other day I decided it was time to start using viewport relative units - for example height: 100vh;. According to caniuse my all of "targeted browsers" should've worked fine. While The usual suspects - Android Stock Browser and Internet Explorer - behaved formidably, iOS 7 did not. ---

TL;DR: There's a "fix" for the viewport troubles on iOS: viewport-units-buggyfill.

If you haven't heard of viewport units, read CSS viewport units: vw, vh, vmin and vmax

Identifying The Problem

What's the first thing you do when you hit a WTF-moment in development? Exactly, you take a step back and build a minimal test case. You find the smallest amount of code that still reproduces your problem to nail things down. For this particular problem, my first test case looked like this:

<html>
<head>
<meta charset="utf-8" />
<title>viewport tester</title>
<meta name="viewport" content="width=device-width,initial-scale=1.0" />
<style>
* { margin: 0; padding: 0; }
#tester { height: 100vh; }
#spacer { height: 3000px }
</style>
</head>
<body>
<div id="spacer"></div>
<div id="tester"></div>
<script>
var windowHeight = window.innerHeight;
var bodyHeight = document.body.offsetHeight;
var tester = document.getElementById('tester');
var testerHeight = tester.offsetHeight;
console.log(windowHeight, bodyHeight, testerHeight);
</script>
</body>

Much to my surprise the numbers were ok. The tester element actually had the height I expected it would have (exactly that of window.innerHeight). It took me a while to realize that I had been adding things to the DOM dynamically. So I extended the the test by a simple function:

setTimeout(function() {
var el = document.createElement('div');
el.style.height = '100vh';
document.body.appendChild(el);
}, 1000);

Now the output looked more like what I was seeing in my app. 7303, 11606, 4303 On twitter I got pointed to iOS 6-7 handles viewport relative units really weird - a 7 month old issue describing what I was seeing on my test devices. According to that issue the problem already existed in iOS6, but my test devices disagreed - everything worked fine.

Working Around The Problem

You're probably familiar with the term deadline. I was on one. A colleague had already tried fixing this for 2 days and we had to present this thing the next day. A quick fix - a workaround - was all we were looking for at this point. We were in a lucky spot. Only two selectors were using the vh unit. The offending selectors only came into play when a certain view was rendered. Replacing the vh values with px values seemed crude, but simple enough to get the job done. Since the problem occurred on portable devices (tablets, phones), listening to orientationchange seemed like a good idea as well. The "solution" we shipped looks rather simple:

// WORKAROUND: converting 90vh to px
$element = $('.the-selector');
function fixMobileSafariViewport() {
$element.css('height', window.innerHeight * 0.9);
}
// listen to portrait/landscape changes
window.addEventListener('orientationchange', fixMobileSafariViewport, true);
fixMobileSafariViewport();

Adding this jewel of a UserAgent switch into the mix and we had the perfect recipe for being fired on the spot:

var IS_MOBILE_SAFARI_7 = !!navigator.userAgent.match(/i(Pad|Phone|Pod).+(Version\/7\.\d+ Mobile)/i);

This is what we had committed to SVN (yeah, sorry, CorporateIT™). The widget we had been working on for two weeks finally alive and kicking on all our test devices. We went back to the hotel. The hotel's bar. To drown our sorrow. We knew what we just did. We added a non-scaling time bomb to our code base.

Solving The Problem

A snowball had a better chance surviving hell than above hack polluting my code for more than a couple of days. While the QA (Quality Assurance) engineers were satisfied (the tool was "working" after all), I looked into using CSSOM to make those vh to px calculations more generic. We were planning on using viewport units for more things in the future, so it made sense to sacrifice another workday for this. viewport-units-buggyfill is the thing now running in our apps. A simple viewportUnitsBuggyfill.init() and we can stop thinking about Mobile Safari's short comings.

The buggyfill doesn't work on style attributes. The adapted test still fails on iOS until you load the buggyfill.

Conclusion

Don't leave quick browser-bug fixes in your code base. Separate things. Try to make it as generic as possible to cover similar problems in the future.

The term "Buggyfill" was coined by Sebastian Golasch.

libsass.js - An Emscripten Experiment

nospam@example.com (Rodney Rehm) — Wed, 15 Jan 2014 12:39:39 +0100

Sebastian Golasch and I set out to run the Sass compiler in the browser. Why, you ask? because we can! Or, well, we couldn't - and that needed changing. We'd heard about Emscripten, but never really used it. ---

TL;DR: See the Sass.js demo and the libsass.js repository for trying to compile it yourself.

It all started with Lea's tweet.

Now I wonder if there’s any JavaScript version of @SassCSS that I can use for @dabblet previewing. Long overdue.
— Lea Verou (@LeaVerou) January 8, 2014

Sebastian (@asciidisco), living in the hotel room next to mine at the time, thought it would be a good idea to have another look at Emscripten. Emscripten is a compiler that can turn C/C++ into JavaScript. Sebastian decided to go with sassc, a CLI (Command Line Interface) wrapper for libsass. It took him a few hours but he got sassc running in the browser.

You might wonder why we were even considering this hassle instead of just implementing Sass in JavaScript. The original Sass library was written in Ruby. Others have tried (e.g. scss-js) and failed at keeping it up to date. We didn't want to add to that growing list of dead-ware™.

Sebastian decided to use sassc so he wouldn't have to build an interface for the library. He's seen this approach work for pngcrush.js and gave it a try. While Sebastian was trying to figure out how to get the compiled program to run more than once, I started looking into emscripting libsass itself.

What follows is a write up of my experiences dabbling with Emscripten. If you are not interested in that but merely care about Sass in the browser stop reading here.

Incident Report

Let me, very quickly, explain who I am so you have a better picture of how things went down. I've been doing web things since 1998. I learned programming in PHP. I thought I knew C++ because I wrote a terminal based game Battleship at the University in 2006. The only exposure I had to C/C++ since, was reading through some of PHP's internals. It is 2014 and it's safe to say: I know jack shit about C/C++.

The steps necessary to compile libsass to JavaScript are detailed in the Readme. I won't repeat that here. Instead I'll explain why this endeavor took us 3 days instead of 3 hours.

I didn't know anything about the C/C++ build environment. I've been using MacPorts and Homebrew for years, but only very occasionally compiled something myself. And by "compiling" I mean typing make install or something I copied off some readme somewhere.

After installing Emscripten following their instructions, I ran emmake make and my terminal responded with env: python2: No such file or directory. It was 01:00 (1AM) and I didn't feel like I wanted to play with this anymore. I had given up before I got started. The next morning Sebastian, who had already fixed the issue on his machine, helped me get my installation up and running. If it wasn't for Sebastian pushing me, I'd not have continued pursuing libsass.js.

Once python2 was available, and modifying the Makefile we got Emscripten to compile libsass. The problem was, the resulting file only contained the Emscripten environment. Reading Calling Compiled Functions From Normal JavaScript helped. We got a JavaScript file exposing sass_compile(). The trouble was, we couldn't call it.

The C++ function sass_compile() expects a struct (if you're a JS person, think of a typed object) but the wiki didn't say how to handle that. Googling around we found out that working with structs is not recommended, as you'd have to do "all kinds of weird pointery things". At this point I decided to wrap sass_compile() in another function that would construct the struct from primitive parameters. This ended up becoming emscripten_wrapper.cpp.

The road to that little function was long and bumpy. It involved consulting Christian Kruse for the most basic things. Questions like "how do I copy a string" seem strange to JavaScript developer, because in JS it's a simple assign. In C++, when working with C strings, you need to #include <cstring> and execute strdup(). To someone actually knowing C/C++ this must seem ridiculous. At the time I felt a bit more like this.

Anyways, after making sure the Makefile used emcc and emar (instead of g++ and ar), I was able to compile valid SCSS to CSS. YAY! For invalid SCSS I got the following JavaScript error thrown:

"5323272 - Exception catching is disabled, this exception cannot be caught. Compile with -s DISABLE_EXCEPTION_CATCHING=0 or DISABLE_EXCEPTION_CATCHING=2 to catch."

I recompiled libsass.js with the proper flag and nothing happened. I got no error message and no exception. I figured the mentioned "exception catching" referred to something within Emscripten and had to do with passing an exception from C++ to JavaScript. This later turned out to be wrong. A day later. I wasted a day because I didn't understand that I needed to tell Emscripten that C++ code must be able to handle exceptions internally. Only after Andres Freund pointed this out, did I get my error message.

The error message was supposed to be returned via parameter (think "call by reference"). As Emscripten Pointers And Pointers shows, it's not as straight forward as I hoped it to be. Considering I'd already wasted a day of work, I did not pursue the idea of reading data from a pointer further, but returned the error message the same way the compiled CSS came back to me. By simply returning the string. This is about as ugly as it can get. It did the job though. I finally had a version that either returned compiled CSS or told me what was wrong. I thought my job was done.

Christian disagreed and figured out how to get all that pointery stuff working. Seeing the working example, I can even make sense of it. Maybe Alon can add that to the docs? Christian also managed to modify the Makefile in a way that would allow us to send the changes back to the original libsass project.

Emscripten API

I'm told people want to see code and stuff. Showing you some of the compiled libsass wouldn't satisfy that need, though. I mean, just look at this childsplay™:

allocate([0,0,0,0,0,0,36,64,0,0,0,0,0,0,89,64,0,0,0,0,0,136,195, …);
var f=0,g=0,h=0,j=0,k=0;f=i;i=i+24|0;g=f|0;qJ(g,c[d+4>>2]|0);z=0; …);

Let's have a look at how you can access the generated libsass.js instead. After loading the file, Emscpripten will litter itself all over the global scope. A quick comparison using Object.getOwnPropertyNames(window).length shows Emscripten declares ~400 (four hundred) global variables. Ouch! But then, that ~670KB light environment needs to do something, doesn't it? Short story is: you don't want this loaded in your document, but rather have it contained in a web worker. Seriously.

So let's have a look at how you interface with a C++ function from JavaScript:

// Module is one of the gazillion variables Emscripten creates,
// it gives you access to the environment
var result = Module.ccall(
// the name of the function to invoke
'the_function_name',
// the data type the function will return
'string',
// the data type the function expects as parameters
['string', 'number'],
// values to pass as arguments
['hello world', 123]
);

That looks pretty straight forward. That was about as far as I got from looking at various examples. It required Christian wasting another night to "reverse engineer" how to pass in a pointered pointer which you can read a result from:

// create pointer to pointer
var ptr_to_ptr = Module.allocate([0], 'i8', ALLOC_STACK);
// execute the C/C++ function
var result = Module.ccall(
'the_function_name',
'string',
['string', 'number', 'i8'],
['hello world', 123, ptr_to_ptr]
);
// pull pointer from pointer
var err_str = Module.getValue(ptr_to_ptr, '*');
if (err_str) {
// pull string from pointer
err_str = Module.Pointer_stringify(err_str);
}

Besides the obvious – C/C++ developers not liking CamelCase – what is happening here is quite simple, if you understand pointers. A pointer is an address to some space in memory. A pointered pointer (or pointer to a pointer) is an address to some space in memory, where an address to some space in memory is stored. A construct like a pointer to a string pointer is somewhat common in C, you allocate memory on the heap and let the parameter pointer point to this address. You would use the & (address of) operator to give the called function the address of the variable you want to have the string stored in.

Since JavaScript doesn't know pointers in this form, Emscripten has to emulate the memory management of C to be able to run such code. And I mean this literally: Emscripten takes the byte code generated by the compiler, turns it into JavaScript and emulates the necessary API to let that run. A pointer in JavaScript/Emscripten is basically just an offset for an array (think memory[pointer]). Memory like you have in C is emulated in JavaScript by "abusing" an array. The array is the memory, the pointer ("address to space") is an index of an element in that array. And in such a "space" we can either save data, or an address to another space. In C the stack is generated by the compiler, and the emulated memory array is generated by Emscripten.

After the C++ function was executed, we retrieve the first pointers value (another pointer) from memory. If it is 0, (the numeric presentation of NULL), there is no address. Otherwise we just got another pointer that we can resolve to string (think var address = memory[pointer]; var value = memory[address];) And that's it, we passed a string back to the caller via function parameter.

That sounded like Klingon to you? Maybe this snippet can help explain the idea:

// objects (that is everything but primitives) are references.
// We can't do any fancy pointer arithmetic, but we can pass
// an object into a function and have the function mutate its
// members
var pointer = {};
var nonPointer = 'mars';
function addProperty(reference, value) {
reference.pointer = 'world';
value = 'jupiter';
}
modifyObject(pointer);
console.log(pointer.pointer, value);
// "world", "mars"

Of course this is not even remotely the same thing. But I think it illustrates the mechanics – or rather basic idea – of pointered pointers quite nicely.

JavaScript API sass.js

We realized that working with the Emscripten API was going to turn people down. Hell, it turned me down. If anyone was actually going to use this thing, it needed a nice-enough API, so we created Sass.js. And there you have it, Sass in the browser:

var scss = '$someVar: 123px; .some-selector { width: $someVar; }';
var css = Sass.compile(scss);
console.log(css);
// .some-selector{
// width: 123px; }

Using the Filesystem

Sass has a feature to include other files using @import "path/to/file";. In our projects we use this quite frequently, because it allows us to split a larger style code base into small modules. I wanted this feature to work in the browser as well. Luckily Emscripten comes with it's own filesystem. This is not the File System API. The Emscripten environment offers low-level filesystem access, for example:

FS.writeFile('/test.txt', 'Hello World', {encoding: 'utf8'});
var result = FS.readFile('/test', {encoding: 'utf8'});
console.log(result);
// "Hello World"

If you were to writeFile() to a path that doesn't exist, the function throws an error. You can create directories using FS.mkdir('/some-path');. In this instance low-level means that mkdir doesn't support recursively creating parent directories, so FS.mkdir('/some/path/hello/world') will throw an Error. While these functions allow you to implement pretty much everything you want to, they're not particularly convenient.

By the way, finding out which functions FS provided and what they did was figured out by using Chrome's DevTools. Executing FS.readFile in the console is the same as running console.log(String(FS.readfile)) – it dumps the function's source code to the console. Because the DevTools approach worked so well, I can't even tell you if Emscripten's FS is documented anywhere. But we didn't want developers to have to figure out things on their own. Therefore we added file-support to Sass.js, hiding the ugly parts:

Sass.writeFile(
'/unknown/path/test.scss',
'.selector { content: "hello world"; }'
);

With that we can make @import directives work in the browser:

// enable line comments
Sass.options({ comments: true });
// add some files
Sass.writeFile('one.scss', '.one { width: 123px; }');
Sass.writeFile('some-dir/two.scss', '.two { width: 123px; }');
// compile the imports
var css = Sass.compile('@import "one"; @import "some-dir/two";');
console.log(css);

resulting in the following output:

/* line 1, /sass/one */
.one {
width: 123px; }

/* line 1, /sass/some-dir/two */
.two {
width: 123px; }

There's even a demo trying out loading individual SCSS files from the server and composing things in the browser. We're not quite there yet, but we actually had to get back to our jobs at some point.

Before any of this got published I contacted Lea so she could point out what needed fixing before "going live". It took her all but 3 minutes to find something. Turns out libsass has problems with interpolation. Not our problem - thank the Lords of Kobol!

Conclusion

Emscripten is a hell of a tool - if you know what you're doing. It's lacking - easily findable - documentation on how to interact with compiled code. I mean Interacting with Code is a great start, but doesn't cover "basic" things like structs and pointered parameters all that well.

Huge thanks go to Alon, Andres, Christian and Sebastian for making this work. I did all the failing so you guys could work things out. It was fun. Let's (not) repeat this (any time soon) ☺

Now go see the Sass.js demo and the libsass repository for trying to compile it yourself. Try shit out. Fail at things. Have fun. Sweat over compile errors at 2PM. Do things.

P.S. I really suck at C/C++.

Updating to iScroll 5

nospam@example.com (Rodney Rehm) — Tue, 31 Dec 2013 13:40:00 +0100

iScroll, the number one widget for managing scrollable panels, has been available in version 5 since October. This post documents my pain updating to iScroll 5.0.9. We've been using iScroll for ages. We've been using it long before we moved to package managers (npm and bower) and it so happened that the library got stuck at version 4.2.5. A patched version. A patched version of a patched version. A dark and ugly corner of our app infrastructure.

I considered the update important because of 3 things:

I don't like stale (as in untracked) dependencies
I don't like patched dependencies
Version 5 comes with PointerEvents support, interactive scrollbars, and quite a number of enhancements

I've looked at the source and it made a good impression. It's clean, well structured, moderately simple and easy to understand. From a coding perspective a job very well done. That said, I spent most of the afternoon cursing. Good code is one thing, completely missing documentation, changelog and upgrade guide paint a different picture.

Anyway, Matteo is working on it. As many of the smaller open source tools are side projects, they have to be dealt with in the author's personal time. Matteo is spending his Christmas holiday on writing the docs for iScroll 5. The official documentation (including tutorials) should be available early 2014. Until then I hope this post can help ease your upgrade pains.

Back to updating iScroll…

Changed API

The first breaking change is its name — it used to be window.iScroll, it now is window.IScroll. I'm just going to leave this here, without debating naming conventions.

iScroll 4 would accept a string as the element to scroll in new iScroll("id-of-wrapper");, version 5 uses querySelector() and thus needs a hash new IScroll("#id-of-wrapper");

No AMD support

Version 5 still only supports CommonJS modules, so AMD style systems like RequireJS have to be shimmed:

require.config({
paths: {
"iscroll": "path/to/iscroll"
},
shim: {
"iscroll": {
"exports": "IScroll"
}
}
});

Changed Styling

The scrollable content bled through the boundary. iScroll 4 used to add overflow: hidden to the wrapping element - iScroll 5 does not. Add overflow:hidden (or overflow-x:hidden) to whatever element you initialize iScroll for.

Option Properties

A lot, if not most, of the option properties known to iScroll 4 have been renamed in iScroll 5. What used to be called hScroll is now known as scrollX — still a boolean advising if the horizontal axis can be scrolled or not. Here's an incomplete map of changed names:

iScroll 4 property	iScroll 5 property	description
hScroll	scrollX	(boolean) allow horizontal scrolling
vScroll	scrollY	(boolean) allow vertical scrolling
vScrollbar	-	render vertical scrollbar
hScrollbar	-	render horizontal scrollbar
hideScrollbar	scrollbars	(boolean) render scrollbars or not - inverted meaning
draggableScrollbars	interactiveScrollbars	(boolean) make scrollbars tangible
lockDirection	freeScroll	(boolean) if scrolling one direction, lock the other - inverted meaning
wheelAction	mouseWheel	(string "scroll"\|"zoom") controlling the reaction to the mouse wheel
handleClick	tap, click	(boolean) issue click/tap events

Without spending too much time on reading the source, I can't say I fully understand what each and every option's side effects are. For example some kind of "custom styling" is triggered for scrollbar not being a string. But if it's a string, besides not triggering the default style I can't see what should happen with that string… We're not using custom styles, so I had to quit investigating at some point — sorry.

Note: The option useTransition used to default to false in iScroll 4, version 5 enables this by default.

Have a look at the demos to quickly figure out what options you need to pass. The way we use iScroll most is rather simple:

var scroller = new IScroll(scrollableElement, {
// scroll only vertically
scrollX: false,
scrollY: true,
// paint scrollbars
scrollbars: true,
// make scrollbars draggable
interactiveScrollbars: true,
// allow scrolling by wheel
mouseWheel: true
});

Callbacks vs. Events

In iScroll 4 we would register a function to be triggered after a scroll operation had finished, like so:

var scroller = new iScroll(element, {
// ... options ...
onScrollEnd: function() {
console.log("scolled!");
}
});

in iScroll 5 there all the callbacks have been replaced by events:

var scroller = new IScroll(element, {
// ... options ...
});
scroller.on("scrollEnd", function() {
console.log("scolled!");
});

The same is true for scrollEnd, scrollCancel, scrollStart, beforeScrollStart, refresh and destroy. Also a new event called flick was added.

The built file build/iscroll-zoom.js additionally knows the events zoomStart and zoomEnd.

Since I couldn't find anything in the source, I fear the following callbacks have been removed entirely: onBeforeScrollMove, onScrollMove, onBeforeScrollEnd, onTouchEnd, onZoom

Preventing Default

In case that never bit you, iScroll 4 called event.preventDefault() for pretty much every event, essentially making it impossible to focus form elements. We got around that by doing things like the following, to allow a <textarea> to be focused, even if they were inside an iScroll container:

var scroller = new iScroll(element, {
// ... options ...
onBeforeScrollStart: function (event) {
// do not preventDefault() for <textarea>s, as that makes them unfocusable
if (event.target.nodeName.toLowerCase() !== "textarea") {
event.preventDefault();
}
}
});

iScroll 5 deals with this differently. It has an option preventDefaultException that comes with a default value of { tagName: /^(INPUT|TEXTAREA|BUTTON|SELECT)$/ }. With this you can run any (string) property of HTMLElement through a filter, preventing the preventDefault():

var scroller = new IScroll(element, {
// ... options ...
preventDefaultException: {
// default config, all form elements,
// extended with a WebComponents Custom Element from the future
tagName: /^(INPUT|TEXTAREA|BUTTON|SELECT|X-WIDGET)$/,
// and allow any element that has an accessKey (because we can)
accessKey: /.+/
}
});

Conclusion

iScroll 5 is a solid improvement over iScroll 4. It's currently lacking the docs to upgrade easily, but that stuff is coming. Until then I hope the pointers in this post can get you started updating today.

Now go read iScroll, a small moan and do something about it. Ask your employer to give you some time to help with the project, or better yet, ask them to support the project financially. God knows your product has benefited from Matteo's work.

(My) Best Of 2013 Conference Talks

nospam@example.com (Rodney Rehm) — Sun, 29 Dec 2013 12:59:22 +0100

The 15 conference talks of 2013 I liked most. ---

[April] At Front-Trends 2013 Lea Verous talked about the Border-Radius. (Video from same talk at CSS Day)

https://vimeo.com/70171266

Talk on Lanyrd

[April] At Front-Trends 2013 Jake Archibald talked about rendering performance.

https://vimeo.com/67050197

Talk on Lanyrd

[May] At Beyond Tellerrand 2013 Jeremy Keith opened the show, setting the mood for thinking longer term.

https://vimeo.com/68352550

Talk on Lanyrd

[May] At Beyond Tellerrand 2013 Christian Heilmann talked about Fixing The Mobile Web.

https://vimeo.com/69790729

Talk on Lanyrd

[June] At CSS Day Tab Atkins explained CSS Variables and Conditions

https://vimeo.com/69531455

Talk on Lanyrd

[August] At Frontend Conference Zurich 2013 Rachel Nabors showed us how to create music videos in browser-land.

https://www.ustream.tv/recorded/37995827

Talk on Lanyrd

[August] At Frontend Conference Zurich 2013 Mike West talked about Locking the front door: browser-side security.

https://www.ustream.tv/recorded/38005119

Talk on Lanyrd

[September] At From The Front 2013 Bruce Lawson talked about How To Destroy The Web. A sarcastic view at how we build the web today. If you're a web professional, you're not going to learn anything here - but it's entertaining none the less. (Sadly From The Front did not (yet?) make any videos available, so here's Bruce giving the same talk at FOWA London.)

Talk on Lanyrd

[October] At Fronteers 2013 Bruce Lawson talked about What The Web Needs Next. In this talk you'll find a perspective on DRM you probably haven't thought about - at least I hadn't.

https://vimeo.com/77953783

Talk on Lanyrd

[October] At Fronteers 2013 Domenic Denicola talked about The State Of JavaScript.

https://vimeo.com/77953785

Talk on Lanyrd

[October] At Fronteers 2013 Marcos Caceres explained the state of Responsive Images. I don't care too much for responsive images as a thing, but in this talk Marcos managed to explain a couple of things surrounding the standardization process.

https://vimeo.com/77953782

Talk on Lanyrd

[October] At Border:None Jeremy Keith talked about the Power Of Simplicity.

https://vimeo.com/79556632

Talk on Lanyrd

[October] At Border:None Bastian Allgeier talked about building a better web. "Better" meaning solving the problem of data silos and not owning your personal data.

https://vimeo.com/78798346

Talk on Lanyrd

[November] At Full Frontal 2013 Kenneth Auchenberg introduced us to RemodeDebug, his initiative to make developer tools work cross-browser. I liked this talk because I had always been annoyed by the situation, but never figured we (the developer world) could do something about it.

Talk on Lanyrd

[December] At Beyond Tellerrand Play 'n' Make 2013 Jared Ficklin exposed us to Thinking By Making.

https://vimeo.com/82173290

Talk on Lanyrd

CSS-Polyfill-Preprocessor — It's A Myth

nospam@example.com (Rodney Rehm) — Mon, 23 Dec 2013 11:07:35 +0100

I want to share some thoughts on Myth.io — specifically its key idea of being a "CSS polyfill". The short story is: Pretending to be CSS but not matching its power will confuse people.

Myth is a CSS Preprocessor (like Sass, LESS, Stylus or one of the other five thousand). It wants to set itself apart from the existing tools by claiming to be "like a CSS polyfill". Only that, it's not, not really. It uses the syntax of modern CSS, without being (remotely) able to offer the functionality of modern CSS.

At work we use Sass (Compass actually, but we're trying to get rid of the ruby dependency…). One of the many helpful things provided by a preprocessor has been the ability to use variables and do math (Number Operations) in "CSS".

Ambiguous Math

In Sass I can easily spot where a computation is happening. The first line, being invalid CSS, is handled by the preprocessor, the second line is handed to the browser.

div {
width: 100px - 50px;
width: calc(100% - 50px);
}

In Myth both statements look the same:

div {
width: calc(100px - 50px);
width: calc(100% - 50px);
}

Both Sass and Myth compile to the same CSS:

div {
width: 50px;
width: calc(100% - 50px);
}

But in Myth it is up to me — the developer — to figure out which way a calc() will behave. I don't think the argument type (pixel value vs. percent value) should determine that. I'm not sure why exactly, but this is ringing all sorts of alarm bells.

CSS Variables

Myth decided to use the CSS Custom Properties notation for their variables:

:root {
var-width: 100px;
}
p {
width: var(width);
}

compiles to

p {
width: 100px;
}

There's not much of a difference comparing the example above to Sass:

$width: 100px;
p {
width: $width;
}

But since we're talking about a polyfilling preprocessor, we have to take a deeper look beyond the syntax of CSS Variables. Comparing preprocessor variables to CSS Custom Properties is like comparing a Fiat 500 to a battle tank.

Source Order

Both Myth and Sass use variables like "replacing static placeholders". They disagree on the declaration/usage order, though. Sass interprets the source sequentially. Every variable declaration it encounters is pushed onto map. Every variable usage looks at the map. This is what we'd call "source order":

$width: 100px;
p {
width: $width;
}
$width: 200px;

// yields: p { width: 100px; }

Myth, being a "CSS polyfill" complies with the "last valid declaration" character of CSS:

:root {
var-width: 100px;
}
p {
width: var(width);
}
:root {
var-width: 200px;
}

// yields: p { width: 200px; }

I don't think this would be a problem in cleanly maintained source. To anyone coming from a traditional precompiler this might be a WTF-moment. But really, it's more like CSS works than how preprocessors tend to deal with things.

Mind The Cascade

You might've noticed that the examples declared variables in the :root block. That is because a CSS rule (property: value;) must be declared in a block — it can't be a direct child of the document. In other words: there are no global CSS rules. That is, until you meet the cascade. If you apply html { font-size: 20px; } that will also be the inherited font-size of body (and any other descendant element, unless it's overwritten somewhere). CSS Variables follow the same rule and thus allows the following:

:root {
var-width: 100px;
}

div {
width: var(width);
background: red;
}

div.wide {
var-width: 200px;
}

For any <div> the width would be 100px, for any <div class="wide"> the width would be 200px. The cascade takes care of this for us in the browser. If we were to accomplish the same thing in a preprocessor, we would have to analyze the declaration and usage of each variable, map the graphs and fold selectors into an output like:

div {
width: 100px;
background: red;
}
div.foo {
width: 200px;
}

While only annoying to implement, this generates rather ugly CSS if your variable usage gets more complex than the example. Myth doesn't do it and forces you to declare variables in :root blocks. It's taking the easy way out.

Powerful API

You already know the DOM (Document Object Model). There's a similar thing for styles, the CSSOM (CSS Object Model). It gives you access to anything within your CSS. We've had a subset of this on a DOM Element basis for years, it's the style property. Of course CSS Variables are exposed through that API as well. You can easily change, add and remove variables at runtime. Consider the following CSS:

body {
var-width: 100px;
var-increment: 10;
}

div {
width: var(width);
}

and add a bit of JavaScript:

var button = document.getElementById('make-wider');
var style = document.body.style;
button.addEventListener('click', function() {
var width = style.var.get('width');
var increment = style.var.get('increment');
var incrementedWidth = parseInt(width) + parseInt(increment) + "px";
style.var.set('width', incrementedWidth);
});

Try the fiddle (in Firefox Nightly). As you can see, CSS Variables might just change the way we work with CSS altogether. We can use them to move styling related configuration from JavaScript to CSS. We can update a single value rather than having to deal with classes, specificity and overwriting declarations all the time.

CSS Variables can be optimized in a way that classes and styles can't. The rendering engine is likely maintaining a map of variable declarations and uses within the CSS. It can maintain another map referencing the affected DOM elements. It doesn't have to restyle the entire DOM tree in order to find out which nodes have changed simply because we added a class to <body>. Using those maps, it knows exactly what changed where. I'm not saying this is an easy thing and will be available from the get go. I'm saying that I can see this avenue being pursued by our beloved performance gurus.

Anyway, Myth — in its current form — won't allow you to build upon this feature. All var(name) instances are replaced at compilation. They could've allowed that by generating output that looks a bit like this:

:root {
var-width: 100px;
}
div {
width: 100px;
width: var(width);
}

Conclusion

it is not obvious if calc() is executed by the browser or the preprocessor
CSS Variable adhere to the cascade - Myth does not
CSS Variables are dynamic - Myth kills that feature

CSS Variables aren't too far away: CSS Variables in Firefox Nightly. In Chrome Canary you can enable them by activating Experimental Web Platform features in about:flags. We'll see this feature in stable releases in early 2014.

I looked into Myth because they made an interesting claim. A claim that the home page of Myth.io made me doubt. A claim I can (very much to my dissatisfaction) confirm is bollocks. I'm not saying Myth is bad, but I don't think it's going to work for me.

The problems with CSS Variables were explained in issue #10 and pretty much ignored, except for the one thing Tab suggested. I hope they figure things out and can live up to the "promise". I'll happily revisit the tool once they do.

Subliminal Learning

nospam@example.com (Rodney Rehm) — Fri, 20 Dec 2013 20:47:58 +0100

Let's talk about accidentally teaching something while explaining something entirely different. Conveying a message within the message. Presenting the reader with information we aren't even really covering. I didn't study psychology. I'm not big in educational science, either. There may very well be an official term for the thoughts I'm calling Subliminal Learning. Maybe Scientia doctrina inter lineas. Wouldn't that be giving this line of though much more substance? Anyway, this blog post is a question, not wisdom I'd like to share.

I've recently proof-read an article that contained a bit of example code. An HTML fragment that was used as the base of a tabbed panel implementation. Instead of using style="display: none" or class="hidden" or whatever, the author chose to use aria-hidden="true". There was no mention of accessibility. No explanation of what that weird-looking aria meant. Only the accompanying CSS [aria-hidden="true"] { display: none; } served as a hint to what this was supposed to accomplish. That was the only use of WAI ARIA in that article. But it was enough to get me interested.

To illustrate my point, have a look at this tab panel example using ARIA roles:

Now compare that to markup we've come to expect to see in examples on the web:

Until today I thought of aria as something you add to your markup (and subsequently never really looked into it). Only now do I realize that you can actually use this in place of other (less semantic) things you did.

Earlier I said I was going to ask a question, so here it is: Would I know more about WAI ARIA, had I seen it used in "everyday code examples" rather than only in articles covering accessibility? I think I would.

I would have - most probably - not looked up WAI ARIA at first. In fact, I would've probably just started using it - the way the examples taught me - without giving it a closer look. After all, it was quite a number of years after I started with web development, that I had my first look at an official specification document. The thing is, we learn a couple of things and we infer from there. (and by "we" I mean "me")

We tend to search for answers to the problem at hand. The above example shows a tab panel, so I'd likely be looking for something explaining how that works. All that aria stuff in there is just something I would pick up along the way. Possibly using it as a base to start investigations from the next time 'round. It's clearly not necessary information to build a tab panel - but it's important if you want to get it right.

The same holds true for pretty much everything else we know. How to write easily testable code is left up to articles covering the topic of testing. The problem is, people have to know that testing/testability is a thing to go looking for information on it. They're not - accidentally or consciously - nudged in the right direction. ("right direction", whatever we think that is…)

I remember Chris Heilmann explaining to me the problem he saw with the efforts to propagate HTML5 throughout the software industry (yep, the "enterprise" thingie). We are speaking at conferences for people interested in the web. We are writing articles for people interested in the web. Unless you're interested in the web, you're not going to attend our conferences, you're not going to read our blogs. We are - quite literally - ~~preaching~~living in an echo chamber. We reach the people we've always reached, but not those that could actually benefit the most.

I think we're experiencing a similar problem when writing about ES6 and calling it "ECMAScript6: The Future of JavaScript". Unless we start using WeakMap in code examples that are not about ES6, the majority won't care. Unless we start using role attributes in articles about UI Components, the majority won't care.

I handed this post to a couple of people before publishing it. I got responses like »I had no idea that ARIA could be useful for more than accessibility alone« and »Now I'm using ARIA everywhere, at least the role attribute«. Doesn't that kind of prove my point?

But is this really the problem I make it out to be? I don't know. Can we do Better? We can certainly try!

Running Keynote With 3 Monitors

nospam@example.com (Rodney Rehm) — Mon, 16 Dec 2013 13:15:25 +0100

I've recently given a presentation sitting on a couch on stage, about 5m away from my laptop. I needed a third display to show Keynote's presenter notes at a different location without using any cables. My iPad turned out to be a perfect fit. (Description for Mac OS X Mountain Lion.)

Keynote showing presentation notes on 2 displays

Using The iPad As An External Display

I already had iScreen installed. This 5$ app and the accompanying system preference plugin for the mac make the iPad show up as an external display in your Display System Preferences.

The connection works via WiFi. To be on the safe side, I created a computer to computer network (ad-hoc network) using WiFi MenuIcon > Create Network and made my iPad join that WiFi network. If you use a public network, you may get slow connection warnings in iScreen.

Mirroring Multiple External Displays

The Display System Preference has a checkbox to Mirror Displays. This option works well for 2 displays, but yields strange results for more devices. Also you don't want to mirror all of them, but rather mirror only two and have the third display extend the desktop. Once you've successfully connected the iPad with iScreen, your Display System Preferences look like this

Display System Preferences with three monitors

Make sure the projector is the primary display by dragging the white rectangle to the appropriate monitor. Hold the alt key while dragging the iPad display onto your laptop display.

Display System Preferences while synchronizing 2 of 3 monitors

You've just managed to synchronize 2 out of three displays. Virtually you now have two screens, where one is shown on one display and the other is shown own two displays.

Keynote Presenter Display

For some reason this trick only works when the presentation is displayed on the main monitor and the presenter information is shown on the alternate display. We already made that happen by dragging the white rectangle to the projector in the Display System Preferences. In Keynote you now need to enable the "use alternate display to view presenter information" checkbox:

Keynote presenter settings

And that's it. Once you play the presentation you should see the slides on your external display (projector) and the presenter notes on your laptop and the iPad. Since it runs on WiFi, you can take the iPad to anywhere you want.

TL;DR

use alt key while dropping one monitor onto the other in Display System Preferences to synchronize them
make sure Keynote is showing the presentation on the primary monitor and the synchronized displays run as secondary monitors

Dialog for Unsupported Browsers

nospam@example.com (Rodney Rehm) — Tue, 08 Oct 2013 18:04:05 +0200

There is no greater failure than showing a white screen. If an application can't run in a given environment ("old" browsers) telling users might not make them upgrade right away. But compared to a blank page they'll actually know what's going on. Here's a (debatable) method to achieve that. My day job is comprised of building web applications. Without bothering you with the details, our lowest end browsers are Internet Explorer 9 and Android 4.0.x Stock Browser. We chose to not support IE8 at all. This decision allowed us to go with ES5, SVG, CSS Transform etc. without having to polyfill anything. On top of using these technologies, we created BackboneJS applications which made our HTML pretty much look like <body></body>. There are reasons we don't render any HTML on the "server", but I'm not at liberty to discuss this any further at this point.

Of course all this lead to a blank blank page in old browsers. If that wasn't enough, the browsers would throw a myriad of JavaScript errors because it couldn't parse and or execute anything we shoved down their throats.

The Management™ agreed with the developer's pride: We needed some sort of "beautiful" masquerade for this.

The Or Else Approach

Our first draft looked a bit like the following snippet. We inlined the content targeting old browsers into our primary HTML files and had JS overwrite the content if necessary. To prevent old browsers from parsing and executing our JavaScript we only injected it if we were sure the browser could run it.

<head>
<link rel="stylesheet" href="style.css">
</head>
<body>
<script type="javascript/template" id="old-browser-html">
<p>Your Browser sucks!</p>
</script>
<script type="javascript/template" id="modern-browser-js">
<script src="main.js"></scr-ipt>
</script>
<script>
if (oldBrowser) {
// remove any existing CSS
var links = document.getElementsByTagName('link');
while (links.length) {
links[0].parentNode.removeChild(links[0]);
}

// inject old browser dialog
var html = document.getElementById("old-browser-html");
document.body.innerHTML = html.innerHTML;
} else {
// load primary JS
var script = document.getElementById('modern-browser-js');
script = script.innerHTML.replace(/<\/scr-ipt>/g, '</script>');
document.body.insertAdjacentHTML("beforeend", script);
}
</script>
</body>

I have cut down the document to the core ingredients and even omitted how we determine if oldBrowser is true or false for brevety sake. We're using the script template method (<script type="javascript/template">) to carry HTML fragments in our document that are not parsed as HTML, CSS or JavaScript. Note that within such a script template we had to "tweak" the closing script tags from </script> to </scr-ipt> in order to have the stuff parsed properly.

In case we are dealing with IE8 (oldBrowser = true), we have to remove any stylesheets that the document references itself. We then simply replace the document's <body> with the content of the template for old browsers.

In case we are dealing with a modern browser, we have to kick off loading the JavaScript. Because we were using grunt-usemin the <script> couldn't just be added to the DOM like you normally would:

var script = document.createElement('script');
script.src = 'main.js';
document.head.appendChild(script);

While this technique worked in the beginning, it has always suffered a couple of problemes and failed us completely in the end.

The HTML for old browsers is always transmitted to the client, although it is almost never rendered. Considering that our HTML is never cached, this seemed like a waste.
The JavaScript couldn't be identified and loaded by the pre parser - which we could've "fixed" in Chrome using <link rel="subresource" href="script.js">.
The fact that we had to rewrite the closing script tag (to </scr-ipt>) never made anyone smile

The approach really fell apart once we added inline <svg> (with more <script>s for animations). We were back to the blank page we saw without all this fuss.

The Unless Approach

We were getting close to the release date (In fact we were already 3 days past delivery, but you know how that works). I was handed this bug. I had no time (4 hours till I'd leave for Fronteers and not return in time for another round of bug fixing).

Lanyrd's mobile site uses the following trick to conditionally load scripts:

Which works fine if the content you're trying to escape doesn't contain any HTML comments. My content did, so that trick wasn't going to fly for me. But I remembered reading about a hack that allowed JavaScript to take over a document's content before the browser's parser had a chance to work its magic - MobifyJS. They inject a <plaintext> element, by which the parser exits HTML mode and simply treats everything that follows as plain text content of the <plaintext> element.

The <plaintext> element is deprecated since HTML2 - which became an IETF standard in 1995. MDN clearly marks this element as obsolete, yet MozHacks (implicitly) promotes the use of <plaintext> as late as March 2013 - nearly two decades after its demise.

After testing the support of <plaintext> on the various browsers and devices available to me, I decided to go forward with using it. My final run the app or GTFO hack looks simple enough in the document:

<body>
<script>
if (oldBrowser) {
document.write('<scr'+'ipt src="old-browser-dialog.js"></scr'+'ipt>');
}
</script>

</body>

and the old-browser-dialog.js looks a little something like this:

That solved all the problems we had.

Presenting old browsers an update dialog.
Preventing them from executing our JavaScript.
Being unobtrusive to the rest of the document's content.

Once I committed this to our SVN, I called my team to my screen and explained that I would shoot anyone that ever

Uses document.write()
Uses deprecated HTML Elements
Question my ability to break the web

(yeah yeah, the irony, I know…)

Rodney Rehm

You could have my day job

My story

My motivation

My status quo

What we work on

The tools we use

Team work

Development process

What about open source?

What are the perks?

Why this job is important

What you'll learn on this job

What now?

Twitter pings

jQuery ContextMenu Is Moving On

Presentations Involving Physical Things

You may not need localtunnel or ngrok

Configuring sshd

User-Specific sshd Configuration

Opening SSH Reverse Tunnels

Making SSH Reverse Tunnels Reconnect Automatically

Conclusion

Starting CLI Services In Sequence

Meet AppleScript

Always Run Script As Root

Automatic Root

Including Data From Github

How Github Is Preventing Hotlinking

Content-Type and Content-Disposition

Access-Control-Allow-Origin - preventing CORS

X-Content-Type-Options

X-Frame-Options

Using A Proxy To Circumvent Hotlink-Prevention

Using rawgithub.com for a gist

Conclusion

iOS7 - Mobile Safari And Viewport Units

Identifying The Problem

Working Around The Problem

Solving The Problem

Conclusion

libsass.js - An Emscripten Experiment

Incident Report

Emscripten API

JavaScript API sass.js

Using the Filesystem

Conclusion

Updating to iScroll 5

Changed API

No AMD support

Changed Styling

Option Properties

Callbacks vs. Events

Preventing Default

Conclusion

(My) Best Of 2013 Conference Talks

CSS-Polyfill-Preprocessor — It's A Myth

Ambiguous Math

CSS Variables

Source Order

Mind The Cascade

Powerful API

Conclusion

Subliminal Learning

Running Keynote With 3 Monitors

Using The iPad As An External Display

Mirroring Multiple External Displays

Keynote Presenter Display

TL;DR

Dialog for Unsupported Browsers

The Or Else Approach

The Unless Approach

`Content-Type` and `Content-Disposition`

`Access-Control-Allow-Origin` - preventing CORS

`X-Content-Type-Options`

`X-Frame-Options`