A great time and place to ask about diversity and inclusion

whiteboard code

There isn’t a single day going by right now where you can’t read a post or see a talk about diversity and inclusiveness in our market. And that’s a great thing. Most complain about the lack of them. And that’s a very bad thing.

It has been proven over and over that diverse teams create better products. Our users are all different and have different needs. If your product team structure reflects that you’re already one up against the competition. You’re also much less likely to build a product for yourself – and we are not our end users.

Let’s assume we are pro-diversity and pro-inclusiveness. And it should be simple for us – we come from a position of strength:

  • We’re expert workers and we get paid well.
  • We are educated and we have companies courting us and looking after our needs once we have been hired.
  • We’re not worried about being able to pay our bills or random people taking our jobs away.

I should say yet, because automation is on the rise and even our jobs can be optimised away sooner or later. Some of us are even working on that.

For now, though, we are in a very unique position of power. There are not enough expert workers to fill the jobs. We have job offers thrown at us and our hiring bonuses, perks and extra offers are reaching ridiculous levels. When you tell someone outside our world about them, you get shocked looks. We’re like the investment bankers and traders of the eighties and we should help to ensure that our image won’t turn into the same they have now.

If we really want to change our little world and become a shining beacon of inclusion, we need not to only talk about it – we should demand it. A large part of the lack of diversity in our market is that it is not part of our hiring practices. The demands to our new hires make it very hard for someone not from a privileged background or with a degree from a university of standing to get into our market. And that makes no sense. The people who can change that is us – the people in the market who tick all the marks.

To help the cause and make the things we demand in blog posts and keynotes happen, we should bring our demands to the table when and where they matter: in job interviews and application processes.

Instead of asking for our hardware, share options and perks like free food and dry cleaning we should ask for the things that really matter:

  • What is the maternity leave process in the company? Can paternity leave be matched? We need to make it impossible for an employer to pick a man over a woman because of this biological reason.
  • Why is a degree part of the job? I have none and had lots of jobs that required one. This seems like an old requirement that just got copied and pasted because of outdated reasons.
  • What is the long term plan the company has for me? We kept getting asked where we see ourselves in five years. This question has become cliché by now. Showing that the company knows what to do with you in the long term shows commitment, and it means you are not a young and gifted person to be burned out and expected to leave in a year.
  • Is there a chance for a 4 day week or flexible work hours? For a young person it is no problem doing an 18 hours shift in an office where all is provided for you. As soon as you have children all kind of other things add to your calendar that can’t me moved.
  • What does this company do to ensure diversity? This might be a bit direct, but it is easy to weed out those that pay lip service.
  • What is the process to move in between departments in this company? As you get older and you stay around for longer, you might want to change career. A change in your life might make that necessary. Is the company supporting this?
  • Is there a way to contribute to hiring and resourcing even when you are not in HR? This could give you the chance to ask the right questions to weed out applicants that are technically impressive but immature or terrible human beings.
  • What is done about accessibility in the internal company systems? I worked for a few companies where internal systems were inaccessible to visually impaired people. Instead of giving them extra materials we should strive for making internal systems available out-of-the-box.
  • What is the policy on moving to other countries or working remotely? Many talented people can not move or don’t want to start a new life somewhere else. And they shouldn’t have to. This is the internet we work on.
  • What do you do to prevent ageism in the company? A lot of companies have an environment that is catering to young developers. Is the beer-pong table really a good message to give?

I’ve added these questions to a repo on GitHub, please feel free to add more questions if you find them.

FWIW, I started where I am working right now because I got good answers to questions like these. My interviews were talking to mixed groups of people telling me their findings as teams and not one very aggressive person asking me to out-code them. It was such a great experience that I started here, and it wasn’t a simple impression. The year I’ve worked here now proved that even in interviewing, diversity very much matters.

Photo Credit: shawncplus

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

View Source Conference: 16 great reasons to join us in Portland

What, when, where

View Source is a brand new conference for web developers, presented by Mozilla and friends, produced by the folks who also bring you the Mozilla Developer Network, to share knowledge of the Open Web. It’s a single track event with plenty of time and space for discussion, demos, and hallway conversations. Talks will be pragmatic and inspiring, focused on topics relevant to front-end developers and people who design and build web sites and web apps.

View Source happens in Portland, Oregon, November 2-4, beginning with Ignite lightning talks on Monday evening, followed by two full days of great presenters, curated conversations, and sociable evenings. Learn best practices and new tools for creating powerful apps and websites “using modern techniques that work today and will thrive tomorrow.”

Thanks to the generosity of our awesome friends and sponsors, we’ve been able to reduce the ticket price for View Source (and refund all current ticket-holders)!

Here’s a quick look at our lineup of presenters — 16 great reasons to go! We’d love to meet you there. Don’t forget to use that MOZHACKS25 discount code for 25% off the ridiculously reasonable ticket price of $250. And if you live in the Portland area and want to lend a hand, you can volunteer for roughly half a day, and attend the full conference the rest of the time. And if you’ve got an Ignite talk proposal up your sleeve, we’d love to hear from you!

Sixteen reasons

Myles Borins – is a “musician, artist, developer and inventor. Hacks on @nodejs for @ibm.”

Josh Carpenter – Mozilla VR Team Lead. “Our goal is to help bring high performance virtual reality to the open web.”

Paul Ford – Co-founder, Writing a book about web pages for FSG. “…the only appropriate reward for people who write JavaScript is more JavaScript.”

Lyza Danger Gardner – Cloud Four co-founder & dev: I help make and share the mobile web. Co-author of Head First Mobile Web (O’Reilly).

Stephanie Hobson“I like to make websites everyone can use.”

Kate Hudson – Senior engineer at Mozilla. 6 ft awesome. Once fused a kettle to a glass top stove.

Josh Marinacci – coder, author, and all round client side wonk.

Rachel Nabors – Web animation ambassador. Training, speaking, consulting, projects. Made comics. Won awards. Working to be worthy of the good I’ve got.

Jarrod Overson – Engineer at Shape Security, JavaScript nerd, Speaker, Creator of Plato, RCL, preprocess, Co-author of Developing Web Components.

Inayaili de León Persson – Lead Web Designer at @Canonical. Love naps.

Sara Soueidan – (Freelance) Front-End Developer, Writer & Speaker • Author of the @Codrops #CSS Reference • #SVG advocate.

Lea Verou – HCI researcher @MIT_CSAIL, @CSSWG IE, @CSSSecretsBook author, Ex @W3C staff. Made @prismjs @dabblet @prefixfree. I ? standards, code, design, UX, life!

Luke Wagner – Research engineer at Mozilla working and works on JavaScript Engine performance, asm.js, and WebAssembly.

Tom Wesselman – Director of Communications Ecosystem Architecture, Plantronics.

Allen Wirfs-Brock – Dreaming and building the future of software; Project Editor of the ECMAScript 2015 Language Specification; Reformed Smalltalker.

Albert Yu“I see how system breaks.”

Many, many thanks!

Our stellar speaker lineup and wonderfully affordable tickets would not be possible without the generous support of our sponsors. Huge thanks to Yahoo!, Intel, jQuery Foundation, Plantronics, and Knowbility! See you all in Portland, at the Armory.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Be a great presenter: deliver on and off-stage

As a presenter at a conference, your job is to educate, entertain and explain. This means that the few minutes on stage are the most stressful, but should also be only a small part of your overall work.

Christian Heilmann listening to translations at TEDxThessaloniki

A great technical presentation needs a few things:

  • Research – make sure your information is up-to-date and don’t sell things that don’t work as working
  • Sensible demonstrations – by all means show what some code does before you talk about it. Make sure your demo is clean and sensible and easy to understand.
  • Engagement materials – images, videos, animations, flowcharts, infographics. Make sure you have the right to use those and you don’t just use them for the sake of using them.
  • Handover materials – where should people go after your talk to learn more and get their hands dirty?
  • An appropriate slide deck – your slides are wall-paper for your presentation. Make them supportive of your talk and informative enough. Your slides don’t have to make sense without your presentation, but they should also not be distracting. Consider each slide an emphasis of what you are telling people.
  • A good narration – it is not enough to show cool technical things. Tell a story, what are the main points you want to make, why should people remember your talk?
  • An engaging presentation – own the stage, own the talk, focus the audience on you.

All of this needs a lot of work, collecting on the web, converting, coding, rehearsing and learning to become better at conveying information. All of it results in materials you use in your talk, but may also not get to use whilst they are very valuable.

It is not about you, it is about what you deliver

A great presenter could carry a talking slot just with presence and the right stage manner. Most technical presentations should be more. They should leave the audience with a “oh wow, I want to try this and I feel confident that I can do this now” feeling. It is very easy to come across as “awesome” and show great things but leave the audience frustrated and confused just after they’ve been delighted by the cool things you are able to do.

Small audience, huge viewer numbers

Great stuff happens at conferences, great demos are being shown, great solutions explained and explanations given. The problem is that all of this only applies to a small audience, and those on the outside lack context.

This is why a lot of times parts of your presentation might get quoted out of context and demos you showed to make a point get presented as endorsed by you missing the original point.

In essence: conferences are cliquey by design. That’s OK, after all people pay to go to be part of that select group and deserve to get the best out of it. You managed to score a ticket – you get to be the first to hear and the first to talk about it with the others there.

It gets frustrating when parts of the conference get disseminated over social media. Many tweets talking about the “most amazing talk ever” or “I can’t believe the cool thing $x just showed” are not only noise to the outside world, they also can make people feel bad about missing out.

This gets exacerbated when you release your slides and they don’t make any sense, as they lack notes. Why should I get excited about 50MB of animated GIFs, memes and hints of awesome stuff? Don’t make me feel bad – I already feel I am missing out as I got no ticket or couldn’t travel to the amazing conference.

misleading infographic

If you release your talk materials, make them count. These are for people on the outside. Whilst everybody at an event will ask about the slides, the number of people really looking at them afterwards is much smaller than the ones who couldn’t go to see you live.

Waiting for recordings is frustrating

The boilerplate answer to people feeling bad about not getting what the whole twitter hype is about is “Oh, the videos will be released, just wait till you see that”. The issue with that is that in many cases the video production takes time and there is a few weeks up to months delay between the conference and the video being available. Which is OK, good video production is hard work. It does, however water down the argument that the outside world will get the hot cool information. By the time the video of the amazing talk right now is out we’re already talking about another unmissable talk happening at another conference.

Having a video recording of a talk is the best possible way to give an idea of how great the presentation was. It also expects a lot of dedication of the viewer. I watch presentation videos in my downtime – on trains, in the gym and so on. I’ve done this for a while but right now I find so much being released that it becomes impossible to catch up. I just deleted 20 talks from my iPod unwatched as their due-date has passed: the cool thing the presenter talked about is already outdated. This seems a waste, both for the presenter and the conference organiser who spent a lot of time and money on getting the video out.

Asynchronous presenting using multiple channels

Here’s something I try to do and I wished more presenters did: as a great presenter should be aware that you might involuntarily cause discontent and frustration outside the conference. People talk about the cool stuff you did without knowing what you did.

Instead of only delivering the talk, publish a technical post covering the same topic you talked about. Prepare the post using the materials you collected in preparation of your talk. If you want to, add the slides of your talk to the post. Release this post on the day of your conference talk using the hashtag of the conference and explaining where and when the talk happens and everybody wins:

  • People not at the conference get the gist of what you said instead of just soundbites they may quote out of context
  • You validate the message of your talk – a few times I re-wrote my slides after really trying to use the technology I wanted to promote
  • You get the engagement from people following the hashtag of the conference and give them something more than just a hint of what’s to come
  • You support the conference organisers by drumming up interest with real technical information
  • The up-to-date materials you prepared get heard web-wide when you talk about them, not later when the video is available
  • You re-use all the materials that might not have made it into your talk
  • Even when you fail to deliver an amazing talk, you managed to deliver a lot of value to people in and out of the conference

For extra bonus points, write a post right after the event explaining how it went and what other parts about the conference you liked. That way you give back to the organisers and you show people who went there that you were just another geek excited to be there. Who knows, maybe your materials and your enthusiasm might be the kick some people need to start proposing talks themselves.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Great Tech History: The digital examiner – electronic newspaper from 1981

Imagine, if you will, sitting down to your morning coffee, turning on your home computer to read today’s newspaper.

This amazing news item from 1981 talks about an experiment of the San Francisco Examiner and other newspapers trying to offer their content in a digital format using a mainframe computer and a telephone connection:

Wired covered this gem in detail and had some interesting details around it.

What excites me most is the purity of the idea back then as mentioned in the interview:

This is an experiment, we’re trying to figure out what it is going to mean for us as editors and reporters and what it means to the home user. And we’re not in it to make money, we’re probably not going to lose a lot, but we aren’t gonna make much either.

The newspaper men tried to reach the two to three-thousand home computers owners back then printing full-page ads and got over 500 subscribers who “sent in coupons”.

The next big thing to me in here is the reaction of the subscriber – a man who waited two hours for the transfer of the newspaper text content at $5/hour call rate. He very much understood the implication that this means you can keep a copy of the paper for yourself and that you can only keep what you need without having to get it all and discard parts of it.

Isn’t it a shame that this amazing gift of publication and distribution and archiving by users of our services is now going back to closed ideas like paywalls and apps?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

WebRTC Data Channels for Great Multiplayer

WebRTC is getting great press lately for it’s amazing applications in voice and video communication. But did you know that WebRTC also has support for peer-to-peer data? Below I’ll talk about the ‘what’ and ‘how’ of data channels, and then I’ll show you how we’re using them in BananaBread to support peer-to-peer multiplayer.

5-player BananaBread with WebRTC, filmed at Mozilla Toronto on a Friday afternoon.

Browser caveats

If you want to use WebRTC data channels, you’ll need the latest Firefox Nightly or Chrome Canary. BananaBread multiplayer requires binary message support for WebRTC data channels, which hasn’t landed just yet in Chrome.

What is a data channel?

A WebRTC data channel lets you send text or binary data over an active peer connection. Data channels come in two flavors. Reliable channels will guarantee that messages you send have arrived at the other peer. If you send multiple reliable messages, they will be received in the same order. You can also send unreliable message that are not guaranteed to arrive in the order they were sent, or they may not arrive at all. These are analogous to TCP and UDP.

Creating and using data channels

Unfortunately, setting up peer connections and creating data channels requires a non-trivial amount of work. It’s very reasonable to rely on a library to handle these things, as well as abstract away some of the implementation details between Firefox and Chrome.

The library used in the examples here is p2p. It provides a simple API for establishing peer connections and setting up streams and data channels. There’s also a broker server component and a hosted broker you can use instead of setting one up for yourself.

Using p2p

You can start with a simple web page. Something like this will do:

<script src=""></script>

In a simple configuration, one peer acts as host and listens for other peers that want to connect.

/* This is the address of a p2p broker server, possibly the example one at */
var broker = "http://";
/* We'll use this to store any active connections so we can get to them later. */
var connections = {};
/* This creates an object that will handle let us listen for incoming connections. */
var peer = new Peer(broker, {video: false, audio: false});
/* This is invoked whenever a new connection is established. */
peer.onconnection = function(connection) {
  connections[] = connection;
  connection.ondisconnect = function() {
    delete connections[];
  connection.onmessage = function(label, msg) {
/* This is called when your peer has received a routing address from the broker.
   The route is what lets other peers send messages through the broker that are used to
   establish the peer-to-peer connection. */
peer.onroute = function(route) {
/* This tells the broker that this peer is interested in hosting. */

The connection object pass into onconnection comes with two data channels, helpfully labelled reliable and unreliable. The label, along with the data, is passed to onmessage whenever that connection receives a message.

If your peer is hosting, it’s handy to capture the routing address assigned by the broker. Another peer needs both the broker URL and the route to connect to your peer.

Finally, the connection object also exposes the local and remote streams, in case you want to send video or audio as well:


If your peer is connecting to another peer, the code is the same as above except that instead of calling listen you should:

  /* Call this with the routing address that the host received from the broker. */

Sockets for Emscripten

In case you’re unfamiliar with Emscripten, the important thing to know is that it compiles C++ libraries and programs to JavaScript, allowing them to run in your browser. This is exactly what we used to turn Sauerbraten into BananaBread.

Sauerbraten has built-in multiplayer support that relies on the POSIX sockets that work very differently from WebRTC peer connections. C++ programs that use sockets expect to communicate with remote hosts by giving an IP address and a port number to the sockets API, along with a buffer containing some arbitrary data. BananaBread in particular only makes four kinds of API calls: socket, bind, recvmsg, and sendmsg.

Each time socket is called, we create a new JS object to hold an address, a port, and a message queue. The queue is important because we will need to hold onto messages that arrive from a data channel so they can be handled later by the application, which will call recvmsg. There’s also some space to build a small header that we will use for sending messages.

Since we’re using the same p2p library from above, the code to create a new Peer is identical except for the event handlers. Here’s the code for onconnection:

peer.onconnection = function(connection) {
  var addr;
  // Assign to the host
  if(route &amp;&amp; route === connection['route']) {
    addr = 0x0100000a; //
  } else {
    addr = Sockets.addrPool.shift();
  connection['addr'] = addr;
  Sockets.connections[addr] = connection;
  connection.ondisconnect = function() {
    // Don't return the host address ( to the pool
    if(!(route &amp;&amp; route === Sockets.connections[addr]['route']))
    delete Sockets.connections[addr];
  connection.onmessage = function(label, message) {
    var header = new Uint16Array(message, 0, 2);
    if(Sockets.portmap[header[1]]) {
      /* The queued message is retrived later when the program calls recvmsg. */
      Sockets.portmap[header[1]].inQueue.push([addr, message]);

Sockets.addrPool is a list of available IP addresses that we can assign to new connections. The address is used to find the right active connection when the C++ program wants to send or receive data.

socket: function(family, type, protocol) {
  var fd = Sockets.nextFd ++;
  Sockets.fds[fd] = {
    addr: undefined,
    port: undefined,
    inQueue: [],
    header: new Uint16Array(2),
  return fd;

Bind is invoked directly when a program wants to listen on a given port, and indirectly when sendmsg is used with an unbound socket (so that recvmsg can be called on the socket and the remote host can send a reply). In the latter case we can give the socket any unused port. We don’t need to worry about the IP address here.

bind: function(fd, addr, addrlen) {
  var info = Sockets.fds[fd];
  if (!info) return -1;
  if(addr) {
    /* The addr argument is actually a C++ pointer, so we need to read the value from the Emscripten heap. */
    info.port = _ntohs(getValue(addr + Sockets.sockaddr_in_layout.sin_port, 'i16'));
  } else {
    /* Finds and returns an unused port. */
    info.port = _mkport();
  /* We might need to pass the local address to C++ code so we should give it a meaningful value. */
  info.addr = 0xfe00000a; //
  /* This is used to find the socket associated with a port so we can deliver incoming messages. */
  Sockets.portmap[info.port] = info;

For sendmsg, we need find the socket associated with the given IP address. We also need to prepend a small header onto the message buffer that contains the destination port (so the remote host can deliver the message) and the source port (so the remote host can send a reply to the message). Recvmsg is very similar to sendmsg.

(Note that the code for reading and writing data to the msg argument is omitted because it’s quite dense and
doesn’t add very much.)

sendmsg: function(fd, msg, flags) {
  var info = Sockets.fds[fd];
  if (!info) return -1;
  /* Here's where we bind to an unused port if necessary. */
  if(!info.port) {
  /* The next three lines retrieve the destination address and port from the msg argument. */
  var name = {{{ makeGetValue('msg', 'Sockets.msghdr_layout.msg_name', '*') }}};
  var port = _ntohs(getValue(name + Sockets.sockaddr_in_layout.sin_port, 'i16'));
  var addr = getValue(name + Sockets.sockaddr_in_layout.sin_addr, 'i32');
  var connection = Sockets.connections[addr];
  if (!(connection &amp;&amp; connection.connected)) {
    /* Emscripten requires that all socket operations are non-blocking. */
    return -1;
  /* Copy the message data into a buffer so we can send it over the data channel. */
  var bytes = new Uint8Array();
  info.header[0] = info.port; // Source port
  info.header[1] = port; // Destination port
  /* Create a new array buffer that's big enough to hold the message bytes and the header. */
  var data = new Uint8Array(info.header.byteLength + bytes.byteLength);
  /* Copy the header and the bytes into the new buffer. */
  buffer.set(new Uint8Array(info.header.buffer));
  buffer.set(bytes, info.header.byteLength);
  connection.send('unreliable', buffer.buffer);
recvmsg: function(fd, msg, flags) {
  var info = Sockets.fds[fd];
  if (!info) return -1;
  /* There's no way to deliver messages to this socket if it doesn't have a port. */
  if (!info.port) {
    assert(false, 'cannot receive on unbound socket');
  /* Similar to sendmsg, if there are no messages waiting we return instead of blocking. */
  if (info.inQueue.length() == 0) {
    return -1;
  var entry = info.inQueue.shift();
  var addr = entry[0];
  var message = entry[1];
  var header = new Uint16Array(message, 0, info.header.length);
  var bytes = new Uint8Array(message, info.header.byteLength);
  /* Copy the address, port and bytes into the msg argument. */
  return bytes.byteLength;

What’s next

Both the p2p library and sockets for Emscripten were made to support multiplayer BananaBread, so they’re both missing features that would be useful for building other applications. Specifically,

  • Add support for peer-based brokering in the p2p library (so connected peers can broker new connections for each other)
  • Add support for connection-oriented and reliable webrtc-based sockets in Emscripten

If you’re building something cool with this, or you’d like to and you have questions, feel free to ask me on Twitter or in #games on

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)