Here we are again – it’s Friday, the first full weekend of 2017 is nearly upon us, you made it through the first week! Let’s get some music going, add some disco visuals, party, and whilst we do all of this we get to do some maths too. It’s like a web devs dream over here 🤓

Really Ruth what is this all about?

I want to introduce a concept I’ve been considering for a while and something that needs me to start work on it. So this is the start, there’ll be more work to be done after this article, but it’s the new year, so let’s begin at the beginning.

If you don’t know me by now, I’m Ruth I would say ‘in my spare time’ here, but actually recently it’s ‘in my real time’ I create visualisations to music, in a browser, mostly with browser code (aka JavaScript). In 2016 I started a collective, it’s called { Live : JS }, it brings together a bunch of artists, like myself, who all build software and perform live shows with music, lights, projections, hardware, and, well JavaScript.

Yeh it’s crazy, it’s a little cool too, if you want to chat to us we have an open Slack Channel and we open source our code in our Github org too.

You were talking about audio?

Yes! Yes I was Specifically analysing audio, which is pretty important for what I do. Let’s take the analyser node of the web audio API for example – that’s pretty sweet. It returns velocity values for frequencies, (or volumes of individual pitch if that’s easier to understand). Up until now I’ve just been using those velocity values just as they are returned; let’s take this visual for example:

I’ve done it by creating a pretty small array to represent the frequencies, each ‘flare’ represents an item in the array, and as the velocity changes so does the size of that flare.

The thing is, it does that with frequencies between 0 Hertz and 20,000 Hertz. (Hertz is what we measure frequency in btw). OK that’s alright, that’s what the human ear hears.

That other thing is though – those super high frequencies don’t factor a lot in day to day sounds and not really in music, and I really want to start dealing specifically with music. So if we bear this in mind, we can reduce the range of frequencies we want to analyse.

And there is one more thing (probably the most significant). The web audio API means we receive back a linear distribution of those frequencies. Now that’s cool and everything but, let’s take a brief look at music frequencies… (have you read the word frequencies enough yet?).

Music notes are depicted by letters, namely A-G (there are sharps and flats, but for the purposes of this article we can concentrate on whole tones). The A note above the middle C note on a piano is 440 Hertz, the A an octave (8 notes/whole tones) below that is 220 Hertz, the A an octave above it is 880 Hertz. See what happened there, it halved and it doubled. That is a logarithmical scale, not a linear one.

So what’s really happening with this analysis is we’re getting data, but if we start being a little bit clever with that data, we can get better data.

I know right. Some days you gotta luv our jobs!

Why is this so important? Well let’s look at that demo again ⬆️ Yes it looks pretty cool, I made it myself, thank you ☺️ But I think it could look better. As the track plays, the vis itself stays pretty flat and there’s more activity around the bottom end of the spectrum (the top right in the case of the flares), and literally none at the top end (top left). This is all really due to our linear distribution and large range of frequencies detected.

Now I think I can pimp this visual, and not just this vis either. I’m currently knee deep in building out all my analysis, MIDI, visualisation hacks into a much more workable piece of software. A really great piece of functionality would be more control over the sound analysis.

Think about this: Beat detection – cool. High, mid and low frequencies – cool. Brightness – cool. We could even go as far as detecting what type of music is being played and adjusting things accordingly. Like if a piece of music is very bass-y then our high, mid and low frequency bands may differ to a piece of music that has overall higher sounds.

Now we can do this with the analysis node as is, but it would be better if the data we start with relates better to that which we need it to.

Oh I see your theory! How do we start?

Great, now we’re all on the same page. First thing’s first – reducing our frequency array. Instead of starting with a small array like before (we can end up choosing our array resolution later), we’ll chuck the item count up to get a more accurate analysis.

var freqDataArray = new Uint8Array(2048);

Now we could simply cut that array and just use the items from the first quarter, with the idea that up to 5,000 Hertz is the first 25% of an array representing 0 – 20,000 Hertz:

freqDataArray.slice(0,512);

Why 5,000 Hertz? This is where the majority of sound lies on the spectrum. We can adjust this value later depending on music we’re listening to and what instruments are used. I chose this value via an educated assumption, just as a starting point. (You can bear in mind for instance that speaking conversation sits under 3,000 Hertz).

Or we could filter the sound with the audio API considering we have that functionality anyway. Here I use the lowpass type of the biquadfilter which only let’s through frequencies in the sound up to 5,000 Hertz, at which I set.

const biQuadNodeFil = audioAPI.createBiquadFilter(),
biQuadNodeFil.type = "lowpass";
biQuadNodeFil.frequency.value = 5000;

audioTrack.connect(biQuadNodeFil);
biQuadNodeFil.connect(analyserNode);
analyserNode.connect(audioAPI.destination);

Check out the below CodePen, I’m spitting out the array of frequency velocities onto the page. When you hit the play button those values constantly start updating. If you toggle the filter on, you’ll notice the values in the top part of the array diminish. Also notice that the track playing hasn’t changed that much (as we’re still mostly within the range used in music).

If you’re interested there’s a cutOffVal var sitting in the JavaScript, you can reduce this down even more and see and hear more of a difference in frequencies being filtered out.

But it’s still a linear thingy bob…

Yes it is! We’ve only done the first part; capped the frequencies at 5,000 Hertz – yeah we could be missing a few high noises in certain musics, but for the purposes of this exercise this bit was the easy bit, so let’s keep it simple.

Caveat! ⚠️ I know your brain is flagging a little warning, the data is still going to be the data – regardless now of how we represent it in an array. Let’s take beat detection for example. One way of doing this is to look for a spike in the levels – which a certain number of array items go over a certain velocity (let’s say 75% of them go above the value 150), then there’s a spike in the music and that could be construed as a beat. We can detect that kind of thing on the array as it stands now or after we do the next stage of manipulation and we’d get very similar, if not the same, results. So if that’s all you were looking to do, you could probably just stop here and work with a smaller array and just be like , but if we wanted to look more into different ranges of frequencies (say I wanted my whole screen to ‘bulge’ on the bass) the next stage would be important. Read: There’s only so much we can do, this is essentially another stage of filtering, not re-analysing from the source.

So how do we spread apart these values and try to mimic the musical log scale. Here I’m going to pose one way and as I said at the top of the article this is the beginning of my studies in this area. I’m hoping as I progress with implementing better analysis within my applications, further ways will present themselves.

This method groups these array items, and averages out the values returned within them. The groups get bigger and bigger as the frequencies get higher, much like the gaps within frequencies get bigger the further up the piano we play.

function adjustFreqData() {
    // get frequency data, remove obsolete
  analyserNode.getByteFrequencyData(frequencyData);
  frequencyData.slice(0,512);

  var newFreqs = [], prevRangeStart = 0, prevItemCount = 0;
  // looping for my new 16 items
  for (let j=1; j<17; j++) {
      // define sample size
    var pow, itemCount, rangeStart;
    if (j%2 === 1) {
      pow = (j-1)/2;
    } else {
      pow = j/2;
    }
    itemCount = Math.pow(2, pow);
    if (prevItemCount === 1) {
      rangeStart = 0;
    } else {
      rangeStart = prevRangeStart + (prevItemCount/2);
    }

        // get average value, add to new array
    var newValue = 0, total = 0;
    for (let k=rangeStart; k<rangeStart+itemCount; k++) {
      // add up items and divide by total
      total += frequencyData[k];
      newValue = total/itemCount;
    }
    newFreqs.push(newValue);
    // update
    prevItemCount = itemCount;
    prevRangeStart = rangeStart;
  }
  return newFreqs;
}

Let’s take our modified array and use that in our original visualisation. Each part still represents an item in the array, it’s just you can visually see how better balanced the animation now is. Originally it was very bottom heavy, now the spread is more even and it moves more dramatically. Awesome.

Have a post NY party!

Chuck the music up, fullscreen your browser, celebrate 2017! It’s going to be a better year, surely ✨

So what’s next? Well back in November I started doing a bunch of experiments around audio vis in a browser for Codevember. This work is a little side step to add to the bigger picture, and make these vis more awesome. I’ll be sure to add some of this into the VJ software I’m starting to build too and any more work in this area I’m sure I will share.

Want to discuss anything in this article further? Just tweet me I’m always happy to chat about the things I write about, especially when they involve the audios

Credits: Big props to my dad for pairing with me on both the theory and code for this, there were times when I don’t think I understood myself but he still did. Also thanks to Kinnoha for happily providing some musical goodness for me to serve up, you can check out more of her ear magic on Soundcloud.

But what’s the implication for ongoing support of your services when you end up with multiple CDNs, data stores, queuing technologies, issue-tracking systems, communication tools, build and deployment tools, and languages? It’s all fine when a big team is working on the new shiny thing, but what happens when they leave and you have five people supporting all the “legacy” stuff?

Relatedly, how can the technology leadership make sure program teams still pay attention to department goals that may not match their short-term incentives? You want to save costs on AWS; they want to get stuff out there and optimise VM size later.

At the Financial Times, teams are pretty empowered to make the right decisions for themselves, but this means they’re very resistant to top-down diktats. As a result, company leadership has to find other ways to influence people to do the right thing.

Luckily there’s a fair amount of information out there on how to influence people rather than force them to do things, particularly in the realm of government.

In this article, I’m going to describe what Nudge Theory is, and talk about why I think it is relevant for software development.

What is nudge theory?

“a ‘nudge’ is essentially a means of encouraging or guiding behaviour” – David Halpern, Inside the Nudge unit

Nudges try to influence you rather than force you: putting healthy food on display at eye level, rather than banning sales of junk food; or making sure there are litter bins available and signs explaining that most people throw litter in bins, rather than imposing fines on the spot.

Nudge theory was named and popularised in a book by Richard Thaler and Cass Sunstein. It’s proven attractive to governments, because it’s about small changes, avoiding legislation (which is costly) or financial incentives (again, costly).

Schiphol airport urinals

The canonical example is in Schiphol airport.

The black fleck in the picture is a painting of a fly. It turns out that men like to aim at something, and the fly is in the best place to avoid splashback. This simple change has reduced the cleaning costs by 20%.

UK Organ Donation Register

Another example relates to the UK organ donation register. In the UK, this is an opt in register, and although 90% of people support the idea of organ donation, only 30% of people have signed up to the register.

When you renew your car tax online, you’re prompted to sign up. The Nudge Unit ran a randomised controlled trial, with eight alternative versions of the sign-up screen.

Those variants were:

1 – the control
2 – states what other people do in the same situation. There’s evidence that we’re affected by social norms
3 and 4 do the same thing as 2, but with pictures added. Previous research suggested adding relevant pictures increases the chance of someone donating to charity
5 – framed in terms of negative consequences
6 – framed in terms of positive consequences
7 – framed in terms of reciprocity – do to others what you want done to you
8 – pointing out the gap between the 90% that support organ donations vs the 30% that actually register

The results were statistically significant:

Reciprocity does the best. Notable is that adding a picture of ‘people’ to the social norms option was WORSE than the control, and framing in terms of negative outcome worked better than framing in terms of positive outcome.

What does this mean in terms of numbers? Well, in a year the difference between control and the best alternative would be around 96,000 extra registrations. Given there are about 21.8 million people registered in total, that’s about a 0.4% increase in the total number of organ donors for the sake of a few changes to a web page.

How can we apply this to software development?

The Nudge Unit came up with an acronym, EAST. They suggest that effective nudges are:

• Easy
• Attractive
• Social
• Timely

I think we can use each of these aspects to more effectively influence teams to do the things we care about as a company.

Easy

If you want someone to do something, you should make it easy: both to understand what the benefit is and to take the appropriate action.

Clear, simple messages, and a good choice of defaults go a long way. We have a strong tendency to stick with the default, which is why it matters whether something is opt in or opt out.

Things we can do to make stuff easy:

• Supply checklists, APIs, example code, libraries.
• Allow people to try your stuff out without having to wait for someone to allocate a key or set up a user account.
• Be customer-focused: make sure people know who to contact. Anytime I see a tumbleweed icon in a team’s slack channel, I wince.

At the FT, we have APIs for creating change requests, which have replaced Salesforce forms.

However, the team have made things even easier by also supplying shell scripts and github webhooks. I integrated the change requests for our systems in minutes thanks to this.

We use the power of defaults with our AWS instances, which default in our staging environments to being shut down overnight and at weekends. Teams have to actively choose to keep them running outside normal working hours rather than actively choosing to turn them off.

Attractive

There are two senses in which you need to make something attractive: firstly, you need to attract people’s attention so they know what you are asking them to do. Then secondly, you need to make that thing attractive by explaining why they should want to do this.

An example at the FT comes from our security team. They want us to use WhiteSource, a tool for scanning libraries in various languages to look for known vulnerabilities.

They’ve documented it comprehensively to explain what it is and why we should use it. They also have a one pager for getting started that tells you exactly what you need to do, and also shows the languages that can use this: I’d assumed there wouldn’t yet be support for Go, but I quickly realised from this one pager that my assumption was wrong.

Social

Humans are social animals. We’re influenced by what other people do: sending someone a letter telling them 95% of people pay their tax on time is proven to make it more likely that they do that too.

In software development, we can show how other people are doing: for example, wherever possible we want our teams at the FT to migrate to Amazon Linux, because it saves us money – and we have a website that shows each team how much they would save:

We also encourage people to talk about things that have worked for them, in lightning talks or blog posts. When we share information we can show how easy it is to do something and show what people can gain from it. My team adopted Graphite and Grafana because of a really good lightning talk that showed how useful it would be and how easy it would be to integrate it with our systems.

Timely

It’s important to pick the right time to ask people to do things. Usually, that’s when they are just starting to think about how they are going to approach their problem.

If you can provide a solution that already provides most of what the team wants, people are very likely to opt for that.

We have an Engineering checklist at the FT that covers the things we expect teams to do.

Here’s part of it:

For each item on the checklist, we link to documentation, libraries, code examples etc. When teams need to get something done, they’re given all the relevant information right then and there.

Having a checklist also makes it easy to do the right thing, and applies some social pressure on teams to do what the other teams are also doing, so it works across several of the levers.

Conclusion

My colleague Matt Chadburn has a great blog post about how a free market economy can be a great thing within a company: let teams pick the best tools, either internal or external. This encourages internal teams to behave like service providers: they need to build great tools, easy to use, well documented, fit for purpose.

Internal teams don’t have a captive market: but they should have a massive advantage. They have their customers right there, and they only need to build tools for a single specific situation.

I think our tooling teams now understand this. They changed the way they worked. They started creating small individual tools and APIs. This means as a client, I can pick and choose. It’s a bit like the unix philosophy in that it favours composability over monolithic design. We now have a set of tools that each do one thing, and do it well. The teams can then compose those however they wish.

But how can an internal team persuade other teams to pick their tools rather than going externally? By making sure those teams know how easy it is to use the tools, the benefits they can get from them, that other people are using them successfully, and making sure they get this information at a time that’s relevant to them. This means nudge theory and EAST can help.

A headless CMS

The new REST API in WordPress is a game-changer for developers. It transforms WordPress into a headless CMS, meaning the front-end delivery can decoupled from WordPress itself. Front-end developers no longer need to rely on WordPress’s built-in PHP templating system, and back-end developers can focus solely on WordPress without having to worry about tinkering with the front-end — Everybody can focus more on the areas they enjoy.

Additionally, content authors can continue to use the editorial tools within WordPress that make publishing easy and fast. The data created within WordPress can then be used to power multiple front-ends: traditional websites, native mobile apps, single-page applications, third-party apps such as Apple News, Facebook Instant Articles, Google AMP—anywhere users can consume content.

Decoupled development

For front-end devs, using a headless CMS means we can build the front-end completely independently of the backend. This has lots of advantages:

• It’s fast to setup, so new projects can get off the ground quickly
• There is more flexibility to change tools in future; We can easily change our front-end to use The Next Big Thing without worrying about how this will affect content
• We can build multiple front-ends using one set of data
• Changing the endpoint to switch between different sets of data makes it easy to develop locally using live content
• You don’t need any prior WordPress knowledge to get started, just the URLs of the endpoints you want to use

So what exactly is the REST API?

The REST API is a way to communicate with WordPress, without using the WordPress interface itself. APIs allow two programs to interact with each other, either inside a single piece of software or with a third-party. WordPress already has many internal APIs, such as the plugins API, which makes developing and extending WordPress easier. The term REST refers to the architectural style of the API, where the interaction is made through basic HTTP requests. Applications make requests to certain URLs, called endpoints, and receive data back in a standardised JSON format. This portable data can then be used by multiple technologies to display and distribute content. Data can also be posted to endpoints to push new content back into WordPress.

Retrieving content and data from WordPress

Endpoints give us a clear path to access data created in WordPress from any other application. The ones that have just been introduced into WordPress core are known as content endpoints, and give us access to public content such as posts, pages, users, and taxonomies out-of-the-box. So, we can easily start playing with the content within any website which is running WordPress 4.7 or later, including this one!

Retrieving posts

We can add the endpoint /wp-json/wp/v2/posts to any up-to-date WordPress website to get an array of JSON objects which contain post data. You can see a live example of what that looks like here:

http://OFFLINEZIP.wpshowp-json/wp/v2/posts

(I recommend the JSON Viewer Chrome extension for making JSON more human-readable).

Each post has lots of data attached to it, including post author, category, date published, etc. This is all standard data that is associated with every WordPress post, allowing us to build around this data knowing the structure will be the same for every site we want to get data from.

One property that is particularly useful when developing with the REST API is the _links object. This contains links to other endpoints in the API that are associated with this post. Each of these links can then be called if needed, to pull in peripheral data for each post. Notice that a few of these links, including author and category, have a property of "embeddable": true. This means we can embed the data from this link in our original request. To do this, we can pass a URL parameter of _embed:

http://OFFLINEZIP.wpshowp-json/wp/v2/posts?_embed

This adds a new property of _embedded to each post object, which contains all the data that is embeddable from the original post. We now have access to full author and taxonomy information without having to make further requests.

We can also modify the content we receive from WordPress by adding other query parameters to the URL. For example, if we want to retrieve a list of all the posts written by a certain author on a website, we can pass the ID of the author to get them:

http://OFFLINEZIP.wpshowp-json/wp/v2/posts?author=1

Similarly for all posts from a certain category, just pass the category ID:

http://OFFLINEZIP.wpshowp-json/wp/v2/posts?category=23

This gives us lots of control over exactly what content we display, filtering it before we use it. A full list of all the parameters available is on the WP-API docs site.

Retrieving other types of content

The word posts in the endpoint refers to the Posts content type, one of the default post types that is built into WordPress. We can swap this word out to retrieve other kinds of content, including pages, users, categories, and tags (see the full list of all the current endpoints available in WordPress). These endpoints present data in exactly the same way as to posts endpoint, allowing you to navigate around and pull in the data as you need it. It is possible for endpoints to be added for customised data, however this requires some additional PHP to implement. Let’s keep it simple here!

Pulling in content

Now we have seen where to get the content from, let’s take a look at a way to pull it into our work. The WordPress REST API has often been associated with React, with many websites and applications using the API and React together to build interactive experiences and fast-flowing websites. Because of this pairing, many people feel they need to learn React in order to work with the REST API—this is not the case. The REST API can be consumed using any programming language. Here is a very basic example that pulls in content using just a few lines of plain JavaScript:

If vanilla JavaScript is not your flavour, you can also use your weapon of choice: React, Angular, Vue; you can even get started with jQuery:

Because all WordPress sites will output the data in a standardised format, the above code will work with any website running WordPress 4.7—Try swapping out the 12 Devs of Xmas domain for CSS Tricks, for example. The WP-API site also has a demo site you can play around with.

Displaying content

Once we’ve retrieved the content, you can display it and use it however you like. One advantage of using the REST API means we can fetch lots of content in one request, then display it from local memory. Here is a simple example of how this could work using plain JavaScript; Each article has a button at the bottom to load in the next one:

The content is displayed instantly because everything is preloaded and available in the browser.

From here, we can start taking it one step further to improve performance and perceived page speed. We can asynchronously prefetch more content once the initial page has loaded, so it is ready and waiting to be displayed when the user clicks a link. This is great for news-style websites—you could load your top ten most popular articles in the background while the user browses headlines. Combine saving these in local storage and using service workers on top of that for offline management, and you’re on your way to building a fast, progressive app with a great content-driven backend. Who knew you could do that with WordPress?

Start playing!

Hopefully this has given you a few ideas about how you can start using WordPress as part of your development workflow. If you’d like a short project to get you started, how about creating a single-page website that showcases the 12 Devs of Xmas articles? You could also use this as an opportunity to build something with a new technology you’ve been meaning to play around with. I’d be really interested to see what you come up with, send me a tweet @sambulance with your creations!

But why should you embrace the human side of Open Source? What are the benefits? What are the challenges? How can the tough parts help us to be better humans? Let me explain.

Volunteer to help

Unsure about how to get started with Open Source? Approach an OS project or community and ask if anyone needs any help. Someone will always need help with something. Why ask for something to work on when you could just search for yourself? Asking others will reveal the biggest problems and needs of project. You also get to introduce yourself to people and possibly onboarded onto a project. It is much easier to collaborate and get things done once you connect with people and become part of a team.

Ask project maintainers if they need help organising a project or any specific help with issues. Find out if the Open Source project has an established communication channel that you can join. The Drupal community uses IRC and Slack channels for daily discussion and organises numerous local meetups and conferences all over the world. You can volunteer to help out with the code itself or you can write documentation. You can organise, volunteer and speak at events. You can participate in hackdays or contribution sprint events. There are endless opportunities to help out, you just need to track down the community or project leads and volunteer to help.

If an Open Source project doesn’t have a community or any events around you, try and create a small scale one yourself. Host a hack day in your office or at a coffee shop. Take a small group of friends or colleagues and work together on an open source project or tool for an afternoon. Start and promote an online community on Slack or Gitter. A community can start and easily grow from these small steps.

Volunteering is a great opportunity to try out new skills, tasks, roles and responsibilities. As a developer I had little opportunity and experience with things such as organising events and mentoring other people. When I volunteered, people suggested that I could help out with those tasks. I soon discovered that I thoroughly enjoy helping out people rather than the code. I can add those new skills into my career and continue to enjoy supporting Open Source communities in that way as much as I can.

Always be yourself

An Open Source community is a diverse place with many opportunities. Never try to be something you’re not or feel like you have to contribute in the same way as someone else. As long as you are helping a project or helping people, you are doing the right thing.

If you’re unsure of how to help, start by listing your strongest skills; things you would like to learn and things that interest you. Ask others how you can help and use your list find something that interests you and provides you with a sense of achievement. Try all of the opportunities offered to you and stick to the things that you enjoy the most. Don’t keep doing things that you don’t enjoy or get any value from out of a sense of obligation. The beauty of Open Source is that it’s a team effort and everything can carry on without you.

Consider your own time schedule and how Open Source contribution can fit into it. Do not feel guilty if you can’t contribute as much as other people or as much as you would like to. We all have busy lives as it is, don’t overcrowd yours, people will understand.

Don’t take negative feedback about yourself to heart. There are many ways of doing things and people will always have differing opinions. Earlier this year I received negative feedback about how I was maintaining a project. It devastated me. I thought I was going to have to change myself or worse completely step down from the role.

I eventually told others about the encounter and was immediately told to not get upset over one small piece of negative feedback from a stranger. Everyone does positive things that far outweigh a single vague piece of criticism. As long as you are helping others and having a positive effect on the work you are doing well. If in doubt, ask for feedback in a safe space with the people you closely collaborate with to see if you there is anything you can improve on.

Giving and receiving feedback

Open Source contribution aside from code, is mostly posting comments into an issue of some kind. Anyone, from anywhere, at anytime, can post something. It’s all too easy to lose a natural conversation flow in an issue queue or a forum. Written communication in itself is a tricky form of communication. Written words can be interpreted in so many ways by other people.

Here are some tips that I have collected over time from being amongst project bug trackers and issue queues.

You can never assume that the person who reads your comment is a native speaker of that language. This is one of the biggest challenges you will encounter. You need to make sure that your writing is as clear as possible for anyone to understand. Also you need to take into account that things can get completely lost in translation. If in doubt give or ask for further clarification.

When posting feedback always pause before posting. Take a minute to read it through again and see if anything could be misinterpreted by someone else. Rewrite your post if necessary. “Rage posting” or coming across bluntly can easily happen because you wrote and posted something in 30 seconds.

Ask someone else to review your response. Especially if you have drafted a lengthy review suggested improvements to a piece of work. Sometimes we just can’t see how we come across to others.

Remember that you are critiquing the work and not criticising the person who worked on it. Provide useful feedback for improvements and the context behind your suggestions. Avoid being purely negative with no constructive feedback.

If you are struggling to get your point across or can’t understand the point being given by someone else, take the conversation to a different medium. Use a messaging tool or have a video call to establish a real time conversation flow. If you can’t have a face to face conversation reinforce your thoughts with emoji. Make it absolutely clear when you are being positive about someone’s work and do mention the positives, it helps to outweigh the negatives. Try and be resourceful with your communication when situations gets tricky.

Always reply in the most positive way that you can. Even if someone is being completely disrespectful to you. Fighting back doesn’t help at all. Trust me it’s exhausting and doesn’t get yourselves anywhere. First ask the person if they are doing okay and explain in the nicest way possible that their comment is coming across as negative. The reasoning might be that they posted the comment in a rush, or it has been lost in translation, or they could just be going through a super hard time in their personal lives. All of these factors can easily creep into written communication.

If someone is being the absolute worst, ignore them and/or report them. More often or not someone else will be in the sidelines to support you and most Open Source communities have Codes of Conduct in place.

If appropriate, try and educate others on how to improve their communication in the future. And keep asking for feedback on yours. Communication takes a lot of practice and we can always improve. An Open Source community is a great environment to learn the ropes.

Listen and learn from others

There has been a lot of talk in 2016 about the downside of putting ourselves in a bubble. It’s a big world out there and we are all very different. We all have different backgrounds, cultures and opinions. Open Source communities are huge and diverse. The variety can be wonderful but we are always prone to making mistakes because there is so much to understand about culture and diversity. My best advice for Open Source and life in general is to always seek to understand the viewpoints of others, and to listen and learn from other people as much as we can.

Spare some time to engage with new people. Learn about their backgrounds and their cultures. Embrace the fact that you are in contact with people from all over the world who lead very different lives to you. When I travel to an event, I prefer to stay in apartments with friends I have previously met at events who are from all over the world. I use this opportunity to understand and appreciate their routines, their habits, and their mindsets based on their own culture and beliefs. It’s a fascinating and enriching thing to do. It helps you to be more empathetic and understanding of others. You will appreciate more and more that not everyone is like you.

The next time that you are at an event, break away from your company team or your usual group of friends and find a group of people you may not know that are seeking companionship and go do something together. My absolute favourite thing to do is to sit with a diverse group of people and talk. You can learn a lot in one evening and it’s interesting and fun at times to compare cultures and appreciate differences.

Let’s wrap this up insert gift emoji

Open Source projects and communities are wonderful environments to try new things and to seize opportunities offered to you by others. Open Source can enrich your life with new skills, opinions, culture and friends. Embrace being part of an Open Source community and collaborate together with others. Improve your communication skills through discussion and understanding of other people. Always strive to share your knowledge, your opinions and your values with others to help further enrich a project and the community behind it. But most of all have fun with what you do. Let yourself be supported by others and always strive to support other people. Have a fun productive Open Source filled 2017 everyone!

JavaScript took its syntax (and its name) from Java, which at the time was the hip new language. However, it gets much of its character from functional languages like Scheme, a language Eich particularly liked at the time.

Those features give JavaScript a special quality, an ability to combine and re-use functions like paint on a palette. In your Christmas stocking today, I’ll give you some classic functional techniques you can try to take advantage of this quality on even the smallest scale.

Purity

Functions receive inputs from their parameters, and give outputs using their return values. But functions can also have inputs and outputs that aren’t immediately obvious.

Here we have a function that sings “row, row, row your boat”. It takes the first line of the song, and logs it to the JavaScript console. It then waits a bit, and then repeats itself with the next line.

var song = [
  'Row row row your boat',
  'Gently down the stream',
  'Merrily merrily merrily merrily',
  'Life is but a dream'
];

function sing(lineNumber, colour) {
  if (lineNumber > 3) return;

  // Take the next line of the song
  var line = song.splice(0, 1);

  // Say it out loud
  console.debug('%c ' + line, 'color: ' + colour);

  // Wait a bit and repeat
  setTimeout(() => {
    sing(lineNumber + 1, colour)
  }, 500);
}

sing(0);

When we run it, it sings us the lines of the song.

Like any good campfire songs, row row row your boat is good fun to sing with your friends. What happens if we try to run “sing” more than once?

sing(0, 'red');
setTimeout(() => { sing(0, 'gold') }, 500);
setTimeout(() => { sing(0, 'blue') }, 1000);

When we run the code, the first singer steals lines from the others before they can sing them. That doesn’t happen in real life!

“Sing” uses a function called “splice”. Splice returns items from the array that allows us to pick out the first line of the song, but it also has a side effect. It removes items from the original array, which makes our “sing” function remove lines of the song as it sings them.

We’ve written a function that is a bad citizen. The function changes data that doesn’t belong to it, and when it also depends on that data things go wrong. We call these actions “side effects” – when functions change data outside of their own scope.

var song = [
'Row row row your boat',
'Gently down the stream',
'Merrily merrily merrily merrily',
'Life is but a dream'
];

function sing(lines, colour) {
if (lines.length === 0) return;
console.debug('%c ' + lines[0], 'color: ' + colour);
setTimeout(() => {
  sing(lines.slice(1, lines.length), colour)
}, 500);
}

sing(song, 'red');
setTimeout(() => { sing(song, 'gold') }, 500);
setTimeout(() => { sing(song, 'blue') }, 1000);

I’ve fixed the “sing” function to read the lines of the song using a parameter, and to use “slice” instead of “splice” which does not remove items from the original array. When we run our program again, all the lines should be sung as we’d expect.

Writing functions to work with their parameter inputs and their return outputs means they will always return the same output when given the same input and have no side effects. This is called “purity” by functional programmers because they are like functions in mathematics, but their benefits are plain to see:

By breaking code into simpler inputs and outputs, pure functions are easier to understand. They are testable, because they always give the same output for a given input. They are flexible, because they have no state of their own and can be used anywhere in your code.

Immutability

It’s unfortunate that JavaScript’s built-in functions incorporate hidden side-effects, because it makes using its functional features harder. Thankfully there is a way of working around this – immutable values.

Whereas JavaScript has built-in support for immutable values, using it is a faff so I recommend checking out Facebook’s Immutable.js library.

Immutable.js has a data structure like JavaScript’s arrays called “Lists”:

const Immutable = require('immutable');
const song = Immutable.List([
    'Row row row your boat',
    'Gently down the stream',
    'Merrily merrily merrily merrily',
    'Life is but a dream'
]);

Unlike normal arrays, their items cannot be changed at all. They remain the same from the point they are created until a new value is assigned or the scope they were created in is destroyed. The only way to make changes to items is by making new copies of the list:

const funnySong = song
  .set(2, 'If you see a crocodile')
  .set(3, 'don\'t forget to scream');

This leaves the original list intact, making side effects harder to introduce:

console.log(song);
List [
    "Row row row your boat",
    "Gently down the stream",
    "Merrily merrily merrily merrily",
    "Life is but a dream"
]

console.log(funnySong);
List [
    "Row row row your boat",
    "Gently down the stream",
    "if you see a crocodile",
    "don't forget to scream"
]

Immutable.js offers many methods and data structures to help you do practically anything you can do with native JavaScript arrays and objects, and more. In fact, when you’ve been using Immutable.js for a while its immutability features melt into the background and using is just like using a toolkit library like Underscore.js or Lodash. It really shines by encouraging us to write pure functions and to think carefully about how we work with data.

Currying

JavaScript’s functions are special – they can be passed to, and returned from other functions just like strings or numbers. This allows you to pre-program functions with settings you can use later.

Let’s look at a song called Old MacDonald Had a Farm. It goes like this:

var song = [
  'Old McDonald had a farm',
  'E I E I O',
  'And on that farm he had a cow',
  'E I E I O',
  'With a moo moo here',
  'And a moo moo there',
  'Here a moo',
  'There a moo',
  'Everywhere a moo moo'
];

What if we wanted to sing the next verse with a dog instead of a cow? Let’s write a special function called a curried function to do that for us.

function curriedReplace(search, replace) {
  return function(subject) {
      return subject.replace(search, replace);
  }
}

Currying allows you to write a function that is run in two stages. You call the function the first time to pre-program settings for later, such as text to search and replace. It then returns a function that can be called later to perform the searching and replacement. It’s really helpful when iterating over data and changing it – like changing words in a song.

var cowToDog = curriedReplace(/cow/g, 'dog');

When we call the function the first time, the settings we give it are saved for later. It doesn’t replace anything right away.

console.table(song.map(cowToDog));

0: "Old McDonald had a farm"
1: "E I E I O"
2: "And on that farm he had a dog"
3: "E I E I O"
4: "With a moo moo here"
5: "And a moo moo there"
6: "Here a moo"
7: "There a moo"
8: "Everywhere a moo moo"

When we pass it into map to iterate over the lines of the song, the second part of the function leaps into action and replaces the words using the settings we saved earlier.

This example might not seem like anything special on its own, and that’s okay. What is really magic is how functions allow you to re-use and combine code. Did you notice in my last example that we’ve replaced “cow” with “dog”, but the dog is saying “moo”? Let’s fix that.

Composition

Currying allows you compose a function out of two existing functions:

function compose(first, second) {
  return function(subject) {
      return second(first(subject));
  }
}

This function takes two functions as settings, and returns a function for later use that combines them both. This allows us to compose a single function that replaces both the name of the animal, and the sound it makes without writing a new function especially to do that.

var cowToDog = curriedReplace(/cow/g, 'dog');
var mooToBark = curriedReplace(/moo/g, 'bark');
var changeToDog = compose(cowToDog, mooToBark);

Now if we run iterate over the lines of the song using this new function, we should see the correct result.

console.log(song.map(changeToDog));
0: "Old McDonald had a farm"
1: "E I E I O"
2: "And on that farm he had a dog"
3: "E I E I O"
4: "With a bark bark here"
5: "And a bark bark there"
6: "Here a bark"
7: "There a bark"
8: "Everywhere a bark bark"

Breaking down code into smaller, single-purpose functions has allowed us to combine and re-use them. This spares us the effort of writing, testing and maintaining lots of specialised functions. If we wanted to make a new function to replace “cow” with “chicken”, and “moo” with “cluck”, we can do this without having to write a suite of new unit tests.

Conclusion

The influence of functional programming on JavaScript makes it a delightful and expressive language to use. The techniques I have introduced not only allow you to keep your code simple, they also enable your code to become more than the sum of its parts. I hope they also illustrate that writing code in a functional way is not as hard as some would have you think! Merry Christmas and happy holidays.

Some of the many benefits for the children being:

• Creative Expression
• Logical Thinking
• Problem solving
• It’s damn good fun

Where to Start?

You could read up on the classics of education theory: Piaget, Vygotsky and Bruner, but my summary is:

Go from where they are to where you want them to be.
Go from the concrete to the abstract.

Along with a few lines from Dorothy Nolte:

“…If a child lives with praise,
they learn to appreciate.
If a child lives with encouragement,
they learn confidence….”

Growing self-confidence, and enabling a child to feel that they are in an encouraging and safe environment, in which they are able to explore and make mistakes, is an essential foundation for all learning and development activities, whatever you are trying to achieve.

If you believe you can,
or you believe you can’t,
you are probably right.
(Henry Ford).

Start simple – make it work, then add complexity.
Start where they are comfortable, then draw them out into new areas.

Be actively on the lookout for any spark of interest, be it music , art, games, maths, and use these to draw them into coding. I’ve been running coding clubs in Primary Schools for 4 years (I’m also a former High School Physics Teacher), and have children aged 10 & 7 both of whom have enjoyed exploring coding in various forms – the examples below are drawn from these experiences:

Artists:

For children who already love painting and sketching – coding presents the opportunity to bring those paint-brushed and pencil-drawn worlds and characters to life.
So maybe start with sketches of the characters, then work with them to bring them into the game. Using a mouse, or trackpad to sketch can be quite frustrating at first, especially as there tends to be an initial drop in visual quality of their work as they adjust – but the excitement returns once they see their work start to come to life digitally, so you may need to encourage them to push through.

They subsequently learn more about what the digital characters can do, maybe starting to animate them, having them interact with other characters, or developing worlds in which they can explore. This often forms a positive feedback loop, with children then further exploring and sketching richer, more dynamic characters and environments, before translating them into digital form again.

One Year 5 (aged 9) pupil continued exploring at home, and created a staggering Sims-like game created in Scratch, where her character could interact with a world of her making. Including interacting with other in-game characters, currency which could be used to pay to go to the cinema, and large multi-environment game map.

Note: If you’re not familiar with Scratch, it’s a visual programming environment created by M.I.T. . There are some other great tools which offer similar functionality, but Code Club developed a superb set of projects based on Scratch, which I’ve used extensively, and has been incredibly effective for the children in my clubs. For inspiration or to contribute : the Code Club projects are managed on Github

I’ve heard from parents that their children were arranging sleepovers including building games in Scratch together. Self-guided junior hackathons!

Reading:

For children who are avid readers, this can be a way to bring their books to life, guiding them to translate some aspect of their favourite book into digital form.
Below is a game involving Hiccup Horrendous Haddock III trying to escape a Bouldertail Dragon, inspired by Cressida Cowell’s epic ‘How to Train Your Dragon’

In this instance, we used an app called Carbo to created flattened digital images of their pencil drawings, and then use a paint package to apply colour and transparency to graphic before importing as a sprite.

Maths:

For pupils who enjoy Maths, codifying their existing knowledge can be a fantastic vehicle to help them discover further patterns in maths, which often leads to a deeper understanding. The projects need to be tied into the appropriate level of maths for the individual pupils, but we’ve seen projects (in Scratch, and Python) such as:

• find all prime numbers up to 200
• Draw an N sided shape (using a few lines of code as possible)

Interestingly, children often enjoy the challenge of setting their own challenges for their classmates. Such as this maths multiplication quiz written in Scratch – they then self-differentiated, by adding further challenges like a timing element, or adaptive quizzes where as you get more answers correct, the questions get harder.

Music:

Music is a great driver for people of all ages, especially children. In Scratch there are built-in libraries of instruments, sounds and noises, and you can also use a microphone to record sounds which can then be employed in your projects. This can lead to some of the noisiest and most entertaining club sessions. Notably, in one session a group of children sampled some AC/DC (Thunderstruck) which led some exceedingly ‘attention grabbing’ projects… passing pupils came to see what was going on, which led to a wave of additional pupils being interested in joining the club.

Sonic Pi : is ‘The Live Coding Music Synth for Everyone’, and while the syntax can be a little challenging to get started with, can produce some phenomenal results

Linda Sandvik talked about the Makey Makey in a previous 12devs article and we’ve used these to great effect to extend the way that the children interact with their creations, by enabling external objects (such as bananas) to become an input device into the computer.

We had a group of pupils combine their own audio samples, with interesting (partially-conductive) objects from around the classroom to make some captivating and entertaining musical installations, which again drew in further pupils who wanted to join in.

Exploring interactions between the physical and digital worlds is something that I find particularly interesting, and also a great source of inspiration for lots of children.

Other ways we’ve explored for crossing the digital/physical divide, include things like the Leap Motion Controller which senses your hands moving naturally in 3D, and feeds that data into the computer for an extremely intuitive input mechanism. (you’ll see further examples below when we talk about Raspberry Pi’s GPIO and rf-controllers.)

Or Lego Mindstorm, which is a programmable Lego robot model, with sensors and motors, which you can program using Lego’s own drag and drop coding interface.

Minecraft

Minecraft is an amazing sandbox video game popular with a lot of the older primary school children. They love creating their own structures, or challenges (for example parkour (?? https://vimeo.com/178917981 ??)) which they then set for their friends to try to complete.

One of the many fantastic aspects of the Raspberry Pi (RPi) is that the standard OS (Raspbian) includes a free version of Minecraft and is ready setup with a Python API to interact with the game. Learning that they can start to programmatically interact with those objects and worlds is tremendously exciting for children, and can be the perfect gateway to introduce them to the Python programming language.

After all, who doesn’t want to be able to make lava fall from the sky, or programmatically generate ginormous structure made entirely from TNT.

Adventures in Minecraft is a brilliant book helping children explore the Python API for Minecraft. (It states it’s aimed at 11-15 year olds – but with some guidance, we’ve had 9/10 year olds find it really valuable.)

This can often lead to children being interested in exploring Python further, which then can take into more abstract activities such at interacting with Web Service Data via Python.

The Raspberry Pi

There are myraid ‘system-on-a-chip‘ solutions (such as Arduino, BeagleBone Black, Intel Edison and many more), offering low price computing power in an accessible package, and if you have access to one of these then they can certainly be fantastic to learn with. However, the Raspberry Pi seems to innately cause excitement with children, or at the least curiosity. One of the great things going for the ‘Raspberry Pi’ seems to be it’s name – it feels accessible, and I think pupils are very happy being opening excited talking about the Raspberry Pi, without it sounding too geeky.

The Raspberry Pi was setup with education in mind, and I think squarely hit the nail on the head – if you install the default OS (Raspbian) it comes pre-installed with Scratch, Sonic Pi, and a free version of Minecraft already setup to be used with the Python API. There is an incredible community surrounding the RPi, and an amazing array of accessories, kits (such as the CamJam EduKit) and projects including the epic Astro Pi.

Astro Pi is a Raspberry Pi, with Sense HAT (a HAT is an add-on which slots onto the RPi), in a specially constructed flight case, which is now in-situ in the International Space Station.

There were even competitions aimed at School children, where the winning entries became part of the Astro Pi payload that was launched to the International Space Station.

I don’t think I’ve yet met a single child in any of the clubs I’ve run, that doesn’t find this incredibly exciting and inspirational.

You can even purchase the equivalent Sense HAT and get the designs to enable you to 3D print your own flight case, meaning you can have your own fully operational version in your home or school here on Earth.

GPIO

Those pins you can see at the top of the Raspberry Pi image above are for GPIO – general purpose input/output. Enabling you to extend your RPi into the realm of electronics, by wiring in sensors, LEDs, matrix displays, servos and motors and many more component, which can then be interacted with programmatically.

The GPIO pins can also be used to add pre-built boards, such as the Sense HAT for the Astro Pi. One of my favourites is by Energenie which, coupled with some radio-frequency controlled electric mains plug sockets, means you can start to control devices around the home programmatically.

As you can imagine, once you start joining up all of the different pieces that we’ve discussed so far, coupled with other technological resources available, the potential is only really limited to one’s imagination – and as we’ve discussed, children’s imagination is pretty phenomenal.

In one of my favourite home projects from earlier in the year, we used the Python API to create a ‘magic block’ in Minecraft, which when you walk close enough to it, uses the energenie HAT, to trigger a disco light in the physical world. (Jack’s original intention was that it would trigger a loud klaxon in his sister’s room – but we agreed on a compromise :) )

This is again where I believe the knowledge of the art of the possible from those already in the industry is phenomenally valuable to help inspire and guide the imagination of the child

Our Own Private Web

The final project I’m going to mention is something I trialled with a group of 10 Year 5 pupils (9/10 years old) in a coding club last summer.

I took into school a box of 10 Raspberry Pi’s, router, switch, cat5 cables, and VGA adapters (fortunately the school had a batch of old monitors, keyboards and mice we could use) and we set about learning not just how to write basic HTML and CSS, but also ran local web servers, so that pupils had a more concrete grasp of what the web is.

I encouraged the pupils to setup the equipment (with mains power turned off at first) – which turned out to be utterly new to most of them, and turned out to be one of the most challenging parts of the project, taking around 45 minutes the first time.

With all of the RPi’s eventually plugged into the router/switch we discussed IP addresses and I’d setup more human-friendly names for each raspberry pi: rpi1.local, rpi2.local.

We then made a new file with a .html extension, put some very basic HTML into it, and showed them that they could view it in the browser. They made some basic edits, such as adding a personal message, saved and reloaded.

I’d already installed Apache (a freely available Web Server which is estimated to serve over 46% of all active websites) on the RPi’s and setup some directory aliasing (and permissions) such that those files they had just created were effectively now served live – and we then navigated to each other’s machines to view their personal pages. (This generates a LOT of excitement).

Finally they learned about the anchor tag, and started HREF’ing links into each others machine… and hey presto we had the beginnings of our ‘Own Private Web’.

I’d setup another RPi with a whole load of example files for them to explore, copy, and learn from, including using parts of Zen Garden to introduce CSS.

Final steps were to show them how to ‘view source’, and and they were off. Very much self-guided and learning independently, as well as helping each other – my role was then pretty much fielding occasional questions, which predominantly involved typo’s (scr instead of src), and why there wasn’t an H0, to also some really interesting areas like how hex colour codes worked.

One delightful aspect that the pupils undertook by their own volition was to share what they learned – a common theme in the web pages that they subsequently wrote, was instructional pages, sharing with the group a new aspect of HTML and CSS as they uncovered them.

I also run a headless RPi (v2) which is externally accessible, and mapped to a proper domain name. Which means we can discuss it end-to-end: Physical Server, OS, Apache Web Server, simple HTML/ CSS files, Domain names (DNS), the network, and finally the browsers on RPi’s in front of them.

As all-pervasive as the web is in daily life, as is depended upon by so many people on a daily basis, I wonder how many adults have a notion of how it works – but from my experience, if it’s presented in the right way, this is potentially accessible to a reasonable % of older primary school pupils.

(** If you do end up working with children in this area, you should definitely read up on children and internet safety – The schools I volunteer at already have their own policies and guides. Part of the reason for initially considering the local router/network approach was to enable me to have an environment which was completely disconnected from the web at large)

Where do I start as a parent/relative/neighbour/volunteer?

How early can children start?

In the photo below Zoe would have been 4 years old, and while I had to do a lot of the setup in advance of her using it, she loved exploring the Makey Makey to interact with the Scratch based piano.

There are some barriers to learning which are perhaps more acute for younger children, but some the items below could be factors affecting learning at any age:

• Fine motor skills
• Vocabulary / Language / (Reading skills)
• Attention / Fatigue
• Awareness of what is possible
• Confidence

Fine Motor Skills

Some people, especially younger children may find it challenging to use keyboards with keys that are too large or small for their hands.

I regularly encounter children struggling with double clicking a mouse – which can sometimes be greatly improved by changing the configuration settings on the machine they are using.

Using a trackpad, can be an unusual experience at first, in part at first due to the disconnect between this non-responsive rectangle rectangle near their body, and the relative movement of the pointer up on the screen

The touch interfaces on Tablets and Phones are wonderfully intuitive – I recall my daughter as a very young baby interacting with photos on our tablet in a completely instinctive manner. (which eventually leads to lots of grubby finger prints on your TV and laptop screen)

There are some fantastic learning resources for tablets such as Scratch Junior which can really make things accessible for younger audiences.

There are also some wonderful projects which enable logical/algorithmic thinking through interacting with tactile wooden blocks, such as Cubetto which is aimed at 4 year olds.

Vocabulary / Language / (Reading skills)

Even in a professional context, how recently were you in a meeting or presentation where someone use an acronym or abbreviation which left some of attendees either utterly baffled, or even a little uncertain that they understood what was being discussed. Abbreviations and acronyms are brilliant tools for discussing complex concepts in a short-hand way – but only if you can be sure that your target audience understands them.

For children, finding the appropriate language is even more crucial. A word like ‘icon’ might be completely alien to younger children (whereas ‘emoji’ might be more familiar).

You might need to put words on the whiteboard, while introducing a topic, to help them slowly build up their mental dictionary of these new terms.

Context and experience can also change the appropriate meaning of a spoken word (professionally think of: SAS vs. SaaS vs. Sass vs. sass), and of course the context for a 9 year old might be very different to you own.

(Hopefully, you have been able to establish an atmosphere such that the children are comfortable letting you know that they don’t understand.)

Even upper/lower case letters can be confusing, and I’ve had experiences where using an ‘uppercase keyboard’ confuses younger children. There are special keyboards available which can help:

From a British standpoint, children will consider ‘color’ to be spelt incorrectly in HTML/CSS, or shortening ‘source’ to ‘src’ for an img tag and can frequently lead to introducing errors into their code.

Attention / Fatigue

There are various studies about optimal focus time LINK for adult professionals, and many adult developers I know can focus for several hours at a time if they can achieve ‘flow state’. However for children younger, or those less practiced in longer periods of concentration, you need to be on lookout for concentration-fatigue… where giving them a short break mid-task, can reinvigorate them. In primary coding clubs I normally stop the session after around 25-30 minutes and do a ‘cool projects’ segment. This typically involves talking about, or watching short videos, ideally technology or coding related, but also often giving a narrative around the outcomes being through imagination coupled with artistic and technical skills. Some examples that have worked really well:

• Wintergatan – Marble Machine
• Action Movie Kid
• Pixel Pyros by Seb Lee-Delisle
• Mechanical Fuzzy Weather Machine () by Brendan Dawes
• CUBESTORMER 3 : Rubik’s cube solving lego robot

In my experience it gives everyone a mental-breather, while stoking their enthusiasm and focus for another 30 minute stint. You can gauge the room to determine if shorter or longer periods will work better for your group.

Awareness of what is possible

One question that I often get asked by parents is:

“What can we do with a Raspberry Pi?”

At first my response was “almost anything you could do with a computer”, which after repeatedly eliciting blank stares, made me appreciate that this is one of the key areas that I think we in the Web/Software/IT industry can greatly help, namely: extolling the art of the possible, in a way which is exciting, while forming some stepping stones to help them develop in the direction of their interests.

I think there also a need for greater support for parents, especially those who may have had little or no prior computing experience, and who would like to be better prepared to encourage and support their children in starting coding. In relation to this I have started an initiative called Code.Parents(), where further details and guidance can be found.

Confidence

Finishing right back where we started: Confidence is a foundational facilitator for learning, at all ages.

Be cautious using language like ‘simple’ or ‘just’. If someone (of any age) is struggling with something – you suggesting it’s ‘easy’, probably isn’t going to help their self-esteem.

Be positive.

Encourage the pupils to be positive and encouraging towards each other, and also with themselves. If needed, set expectations and boundaries that need to be met to be able to participate in the the club.

If someone is struggling with self-confidence, actively look for something, anything to praise them about. Maybe break the task into even smaller elements, or maybe change to a different activity altogether.

Go from where they are, to where you want them to be.
Use praise and encouragement to engender appreciation and confidence.

Your experience, passion and enthusiasm are just the sparks needed to ignite the tinder of their imagination.

I’d love to hear about, and to learn from, your experiences.
I’m also very happy to try to help if I can: @bseymour.

Being a self-taught developer, I remember how difficult I found it at the start, before I had colleagues or friends in the industry to ask questions of. Much of the time I didn’t know what I needed to ask, let alone who or where. I could spend hours on a problem and still not find its solution. It is the memory of this frustration that initially drove my desire to mentor junior developers, so that they wouldn’t have the terrible time I did, but mentoring has been so much more than just passing on knowledge. I’ve learned so much about myself, my skills, the industry, and life in general just from connecting and interacting with my students.

I thought I’d share some of the lessons that my students have taught me and how they’ve impacted my life as a developer, in the hope that maybe I can encourage more people to give mentoring a try.

You. Can. Teach.

I’ll admit that at first I was reluctant to join in when industry friends mentioned that they were coaching juniors. Imposter syndrome kicked in and I was certain that I’d never be any use to other developers. I’d be the first in line to tell you that I don’t know everything there is to know about front end development, but here’s the thing, no one expects you to know everything. If there is one thing that developers know, it is how to find the answer to a question. You teach what you do know and you and your student can explore together that which you do not. Which leads me nicely on to point two…

There is nothing like teaching to improve your own knowledge

It may be a tired aphorism, but seriously, teaching a subject helps you to get a better grip on that subject yourself. Making a concept accessible to a beginner forces you to consider it from new angles and to explore nuances you may have otherwise ignored. By the time you’ve explained how to use flexbox to five different students – each with their own set of problems, plans and questions – your knowledge will be so encyclopedic that when you next come across a misbehaving child element the answer will be at your fingertips and not at the end of a stack overflow dive.

Easy is subjective

I’ve lost count of the number of times that I’ve attended talks where the speaker uses words like ‘easy’ or ‘obvious’. ‘It’s not that obvious to some of us, why don’t you spell it out?!’ I’ve wanted to scream from the audience, and yet I still have made the mistake of telling my students that ‘CSS is easy’. Luckily, some of them have had the confidence to correct me, ‘It might be easy for you, but I’m still learning this stuff’. Whether you’re teaching, or speaking, or writing, please stop referring to languages, concepts, frameworks or tools as ‘easy’, it brings people down when they can’t instantly grasp that which you feel is easy and it belittles their accomplishments when they do.

At Codebar they advise coaches to assume that their students have zero knowledge and infinite intelligence. That way coaches are encouraged to ask their students about their familiarity with a subject rather than to assume it.

Patience is a virtue!

We are told that impatience is a good thing in a programmer, that the need for instant gratification makes us more efficient and lets us strive to build faster products and tools. It can also, often, make us unpleasant to be around. I know I’ve snapped a sharp retort far too many times during familial tech support calls, and I’m the kind of Londoner who tuts when someone takes too long getting through a barrier at a tube station.

Mentoring has introduced me to a well of patience that I didn’t know I had – I’ve learnt that I have infinite tolerance for someone who is trying to learn. That patience is necessary in order to ensure that your student doesn’t feel pressured to grasp an idea too quickly or too scared to ask you questions. What I couldn’t have predicted is that this newfound patience has had a humanising effect on the rest of my life. I am much slower to anger, and better at dealing with frustration in a positive way. Understanding that frustration is a means to an end has improved the way I approach my own learning, whether it is a new framework, tool or just fixing a bug.

Never stop asking questions

I’ve had some brilliant questions from my students, questions that I’d never thought to ask, and kicked myself after for just accepting. ‘What happens if you put the body before the head?’ was one ‘Why do I have to open html tags when I’ve just given a doctype of html?’, a good question and ‘What’s the difference between Javascript and Java?’ is always a fun one. I’ve noticed that I often fall into the trap of accepting the way I code without questioning why I’m doing it or whether or not there could be a better way. Teaching has helped me to keep my skills up to date, sometimes because my students point out to me that I’m behind the times – ‘It says here you don’t need to give a type when linking a CSS file in html5’, well I’ll be damned.

Get to know your audience

One question in particular that sticks in my mind was one that I posed to a student. They were making a website for a charity which helped isolated or lonely women find a friendly, local group of other women to spend time with. The student had created a giant purple button which hovered in the center of the page saying ‘Get me out of here’, and when clicked, landed the user on the YouTube homepage. I asked what on earth that was for, I couldn’t understand why she was so keen to direct her users away from the site. ‘It’s for women in abusive relationships who might want to keep their use of the site secret from their partners. If the partner approaches the screen they can quickly navigate away’. I was gobsmacked, I’d have never thought of this use case and now that I have I can’t stop thinking about how little we know about our users in general.

As developers, it is sometimes easy to think that nothing is more important than building the next feature, or using the most up to date technology. User testing and contextual research can feel like a painful pause in productivity. But finding out who wants your product and how they might use it is much more important than how you make it. By skipping out on getting to know your audience, you could end up building things that they don’t want, or can’t use. If you have access to your users for feedback, use it!

Give it a try

The final thing to say is, that mentoring has given me far more confidence to try new things. The students that I’ve worked with are an absolute inspiration, many of them are learning while holding down jobs, or are still in education. They bring a positivity to their studies that is infectious, they’re eager to learn and try new things. They view the world of development without the jaded cynicism that you often hear from developers who have seen too many new frameworks come and go. We could all do with a little more positivity and excitement, especially when encouraging junior developers! My students have taught me that there is so much to gain from trying new things and very little to lose. Their passion for constant improvement helps to drown out the voice of imposter syndrome. Since I started teaching I’ve given talks, run events and written blog posts – none of which I would have tried before for fear of failing.

There is a hebrew word ‘Firgun’ which describes genuine delight or pride in the accomplishments of another person, and that is the best description that I have been able to find for the joy that mentoring can bring. Whether it has been school kids, people at the beginning or middle of their careers or even my one 75 year old student, watching them have that ‘aha!’ moment, when something clicks is one of the most rewarding things I have ever done, and I can’t recommend it enough. As an antidote to 2016, if you’re looking for a New Year’s resolution, make it mentoring. You won’t regret it.

Elm is adventurous; it’s a strictly typed, functional language that takes inspiration and syntax from Haskell yet is aimed at JavaScript developers looking for a more productive environment. I’ve spent a lot of time on stage talking about Elm and a lot of people tell me that they love the idea but can’t quite progress to Elm in their work. This is totally understandable and although I hope more and more people will be able to use Elm at work, we’re not quite ready to leave JavaScript behind just yet.

That being said, I’ve felt my JavaScript (and other programming work) be influenced by what I’ve learned and enjoyed from Elm and in this post I want to talk about how you can still benefit from Elm even if you’re not working in it every day. It’s for this reason that I’d encourage everyone to play with Elm; you’ll benefit regardless of if you use it every day.

Immutability

In Elm every single value is immutable. That means that it can never change – whenever you want to modify a value you instead create a new value that is the old value, but transformed. This is built into Elm; it’s impossible to ever mutate a value. However, this isn’t the case in JavaScript:

var x = { a: 1 }
x.a = 2
console.log(x) // { a: 2 }

var y = [1, 2, 3]
y[0] = 0
console.log(y) // [0, 2, 3]

Even the new const feature of ES2015 doesn’t prevent us from this; it keeps the variable name bound to the same object, but doesn’t prevent that object being mutated:

const x = { a: 1 }

// not allowed!
// x = { b: 2 } errors

x.a = 2
x.b = 3
console.log(x) // { a: 2, b: 3 }

What we can instead do is use Object.assign, a new function introduced in ES2015, to create copies of objects with certain properties applied to them. Let’s say we have a point with an x and a y, and we want to update y to be a new value. We can use Object.assign to create a new object rather than mutate the original:

const point = { x: 0, y: 1 }
const newPoint = Object.assign({}, point, { y: 2 })
console.log(newPoint) // { x: 0, y : 2 }

Object.assign takes objects and copies the properties from right to left. In this case the object { y: 2 } is merged into the point object, and all of that is then copied onto the first argument, the empty object. It’s important that we pass an empty object as the first argument; if we instead just passed point, that would be mutated:

Object.assign(point, { y: 2 })

That code above will mutate point, which is what we’re trying to avoid.

This however is fairly verbose if you’re doing this a lot throughout your application. There is a proposal for ECMAScript called Object Rest/Spread which adds support for spreading an object using the ... operator. This functionality isn’t certain to make it into a future version of JavaScript, but it’s at Stage 3 of the process which means it’s pretty likely. It’s also a very popular proposal and I’m confident enough that it will make it into JavaScript to mention it in this blog post!

If you’d like to use this syntax now, you can use the Babel plugin to add this feature to your codebase. When we do, the code sample from above becomes:

const point = { x: 0, y: 1 }
const newPoint = { ...point, y: 2 }
console.log(newPoint) // { x: 0, y : 2 }

The advantages of this syntax are:

• You can never accidentally mutate point, the spread operator doesn’t allow us to do it.
• It’s much cleaner and more concise than Object.assign.

I use this pattern a lot in my code and I’ve found it a really nice way to avoid random mutations that I wasn’t expecting. If you wanted to go a step further you could introduce something like Immutable.js, a library that gives a whole new set of data types for keeping things immutable, but I personally find that using Object.assign or ... and being careful when working with objects is a nice middle ground. There’s also a benefit to using native data structures rather than ones provided by an external library.

Pure Functions

Another characteristic of Elm is that all its functions are pure. I’ve written extensively about pure functions before but in short a pure function is a function with the following characteristics:

• All data it works with is given to it as input.
• It does not mutate any data that it is given.
• Given the same input, it will always return the same output.

A function is pure if it doesn’t reach out to any global scope to access any data, and if it uses the data it’s given to return some other value without modifying anything along the way. A good way to test is a function is pure is to see if it always gives you the same result when you give it the same input. For example:

function pureFunc(x, y) {  
  return x * 2 + y * 3
}

pureFunc is pure because:

• All the data it works with it is given (x and y).
• It does not mutate x and y.
• It does not reach out into any global scope to access data.
• If I call it with x = 1 and y = 2 it will always give me back the same answer, 8.

On the other hand, the below function is not pure:

function notPureFunc(x, y) {  
  window.result = x * 2 + y + 3 + z * 4
  return window.result
}

It’s not pure because:

• It has a side effect, because it modifies window.result.
• It relies on an external variable, z.
• If I call it with the same x and y I don’t know that it will return the same value because the value of z could be anything.

There are two main benefits to pure functions in my experience. They are much easier to work with, because you don’t have to remember where z comes from, or deal with any other information outside of the body of the function, but this also makes them much easier to test. By having functions that rely on no external input other than their arguments, you can easily test them because there is no test set up required and no special framework specific configuration to set up before you can get on with testing. I’ve lost track of the amount of times I’ve wanted to test a simple function that’s nested within a framework controller or service, and I’ve had to jump through so many hoops that often I just ended up not testing it because I couldn’t deal with the frustration!

Separation of view and logic

Speaking of frameworks, that brings me nicely onto my next point. Elm does a great job of separating your core logic with your user interface. You should always strive to keep the two very separate as they are two completely different concerns. You should have code that can take your data and render it, and you should have code that can manipulate data based on input and user actions, and the two should very rarely cross.

In Elm we follow the Model-View-Update function, which breaks down into three parts:

• The model is the single object (or record in Elm parlance) that contains your entire state.
• The view function can take the current model and render the user interface based on the data it has. It can also bind event handlers to listen for user input, but it cannot modify data in anyway.
• The update function deals with user actions and uses them to update the model accordingly. When this is done the view function is then run again, so that the output on the screen is representative of the new state.

What this means is that there’s only one function above where data can change – in the update function. That means in order to test your application you only have one real function to test – the update function (as your app gets larger you’ll split it into many functions – but they all remain easy to test). What I enjoy most about this approach is how my tests on the update function never once reference the user interface, or the framework I’m doing. You can of course still test your user interface and that it’s rendered correctly given the data you give it, but the core logic of your application is nicely decoupled from it.

If you think this pattern sounds familiar then you’d be right – libraries such as Redux were influenced by Elm’s model, and it’s something that has now become a much more common approach. I’d highly encourage you to try this in your own applications. How much of the user interface you test is down to you, but I’ve found in Elm, as well as in React, that these days I don’t tend to test my UI much. I trust the framework to do the right thing, and focus on getting my core business logic correct.

Making an effort to avoid wrapping your code in framework boilerplate is also hugely beneficial. Most libraries have the concepts of services or factories that wrap logic up for you, but the cost there is that you now have your code that you want to test abstracted into a framework. Often this is a worthwhile cost and one you’re happy to pay, but often it’s beneficial to just create standalone modules of related logic in plain JavaScript, and import those into your framework specific components.

Functions, functions, functions.

When you follow the above rules and find yourself sticking to plain old JavaScript everywhere instead of wrapping code around a particular framework, you’ll notice that things become much easier to abstract, refactor and work with. You write plain old JavaScript objects (POJOs) that contain pure JavaScript functions, and suddenly everything is much easier to reason about, work with and test. You might even throw a bit of TypeScript or Flow to add some type checking to your code (it’s not quite as nice as Elm’s compile time type checks – but what is?!), and suddenly you’re oozing with confidence as you pull large functions apart, change arguments to other functions and pull logic out of components into modules of business logic detached from your user interface.

The beauty of this approach is that you strip away code and concepts that prevents you from easily reasoning about your system. Your UI components effectively become components that can take data and produce DOM; your application’s modules are just POJOs with functions within, and your functions rely on no outside state. Once everything is in this shape you can test it easily; once things are tested you can refactor with confidence, and once you can refactor with confidence you can maintain your application, and once you can maintain your application as requirements change and libraries mature over time, you’ll be chirpier than ever on your way into the office.

Conclusion

I hope this article has peaked your interest about Elm the programming language but also the ideas and concepts that are at the core of Elm. They can be applied to your Javascript just as readily as to your Elm, Ruby, or any other programming language of your choice. If you’ve got any questions I’d love to hear them, tweeting me is your best bet, and the Elm Guide is the best way to dive in and start exploring Elm.

Virtual Reality in the Web Platform now allows us to bring content into the user’s environment. This is supported on the Web today through the new WebVR APIs. Creating experiences for Virtual Reality has never been more accessible with tools like A-Frame and Play Canvas.

Right now there are only a few web browsers for browsing the traditional web in the headset such as Samsung Internet for Gear VR, Carmel (GearVR) and Chrome for Daydream.

More will come in time, especially with platforms like Hololens and GearVR and Cardboard which is bringing Augmented Reality and Virtual Reality into the realm of the everyday.

It is not too early to start working out how this platform shift will influence the web. I suspect the disruption will be on the same magnitude as the mobile web. What can we learn from the early days of mobile to ensure the web becomes a robust future proof platform for VR and maintains the accessibility of the web?

Ghost of Web Past

Some of you may own a smart phone.

The mobile web introduced a plethora of new devices which had a variety of screen sizes in which screen real-estate was at a premium.

This eventually lead to responsive design, progressive web apps and new levels of interoperability between browsers. But it’s easy to forget the lessons learned.

Don’t Fork the web

Before responsive design became the de facto way of designing sites, there were two common alternatives:

The practise of redirecting mobile users to m-dot websites (http://m.example.com) to provide different content. These websites were often incomplete and sometimes even lost any context during the redirect i.e. redirection to the homepage and not the article you were trying to read.

The other issue was that sites may use interstitials, see figure above, to try to get users to leave the web entirely!!

It took Google making it negatively effect SEO to finally rid the web of this practice.

Aside from being bad user experiences it broke one of the core principals of the web, that URLs should deliver the same core content to everyone regardless of who they are or what device they are using.

Eventually we learned to take advantage of the idiosyncrasies of mobile, such as small screens and touch interfaces, and build a web which takes advantage of the rich features of the mobile platform and the large displays of desktop.

Alas the damage had been done, the mobile web gained a bad reputation in preference of native apps which only today is starting to go away as web apps come to the fore.

Ghost of Web Present

I wish this was a spoken talk so I could do a three-way Christmas/VR pun!! Present (now), Present (Gift), Presence (VR)

WebVR right now is mostly focused on WebGL based VR experiences as that was the path of least resistance to getting VR to work in the web. It has shown that the web is an almost ideal platform for delivering VR media content. Which is hardly surprising considering the web has been the predominant platform for delivering 2D media content for a number of years now.

The era of streaming media is upon us and I think this is summed nicely in this quote:

“If visual fidelity was all that mattered we would be watching blu-rays not Netflix”
— Josh Carpenter

’cause what is the web for if not making rapid access to content with a single URL? This accessibility to content and content providers trumps any drawback you may have from working within the web platform.

WebVR and WebGL on the web has ushered in a new era of 3D modelling and WebGL tooling. A particular favourite of mine is A-Frame.

Mozilla’s A-Frame project brings the idea of authoring WebGL based VR content using custom HTML elements!

A-Frame allows web developers with only HTML experience to start working in 3D. Nothing says web to me as quickly getting new developers building in a new medium.

Although a WebGL based approach allows one to guarantee the same content at a low level across platforms, it has some downsides.

The biggest being that any content produced is not a native part of the web platform so it has not had the many experts of the web poring over it.

Every web API has had many experts arguing over it’s viability in terms of Accessibility, Performance, Ease of Use, Security and Privacy. Usually when developers take over parts of the web platform, Accessibility is the first thing to be lost and it is usually a sign that the platform needs extending.

Bringing VR into the realm of first class web APIs to enable normal websites to embrace VR would be a great way to extend the web platform to bring the web into the future.

Unfortunately right now the state of the traditional web in VR is not great. Although 360 and 3D videos are natively supported in Samsung Internet the traditional web is confined to a single 2D window, taking no advantage of the added depth VR can bring.

But it is still early days, it took a long time for responsive design to become accepted for the web on mobile. How does one even begin to think about doing responsive design in an entire extra dimension?!

Ghost of Web Future

I envisage a future where the traditional web is enhanced by Virtual Reality. Where standards bodies and browser manufacturers work together to enable a future in which:

• Just as content creators learned to take advantage of touch interfaces for mobile, we create new interface patterns for the controller/wands/hands or other future interfaces of VR.
• Just as we learnt to make the most of limited screen real estate, we gain the abilities to position and rotate HTML elements in 3D to take advantage of the virtual spaces VR gives us.
• Just as mobile pages are expected to be so performant that they stick to the finger and feel physical, the interactive elements of the VR web should feel physical by being able to be manipulated in 3D space.

The traditional web has been around 25 years and had a monumental shift when the mobile web came to be. Another great shift is coming! Lets avoid the mistakes we made on mobile to make a future where the web is the predominant platform for VR media.

How the traditional web will be enhanced by VR is not something I can predict at this point. But discussion of it is happening in the open. On Github and in a W3c community group.

We can all work together and try out the new WebVR APIs to feed back on them. Try prototyping the websites of the future. Tell us where you are struggling it is only via feedback we can work out what needs to be done.

Recommended Reading:

I recommend Jeremy Keith’s new book Resilient Web Design, for a detailed look back to where we have been. After all, unless we learn from our history we are doomed to repeat it.

Get Started with WebVR today with A-Frame!!

I’ve put together some A-Frame HTML you can edit live in your browser.

Share your creations with me I would love to see them @lady_ada_king on twitter.

You know that site that you have ambitions to fix up during the holidays? Let’s create something fun for it, while playing around with SVG. If your happy place is usually filled with code — and drawing sounds scary — this article is especially for you.

Scalable Vector Graphics is no new kid on the block anymore. Since you’re reading this, there’s a good chance you’ve used <img src="logo.svg"> or perhaps even have a nifty icon system with <symbol> and <use>. But SVG is more than icons and logos!

We poke fun at ourselves for the identical web designs across the internet; hero image and three column content. SVG could be your first step to breaking free, and a perfect one-day task to add some originality to your personal web site or side project.

Amazing stuff can happen in the intersection of drawing and code. Now that designers are coding, developers could be learning vector graphics, right?! I can’t wait to see what we create, because I think we’ve barely scratched the surface of potential for SVG.

So let’s get to know the SVG elements! A friendly first acquaintance is <line>. Basic lines are drawn with x and y coordinates for the start and end point, and need a stroke attribute with a colour. So crack open your devtools to inspect these examples.

We can write SVG. But we can also draw them in a vector graphic editor. To get the most of our playtime with SVG; let’s do both. \o/ Perhaps you already have Adobe Illustrator, or you can go download and install the free and open source Inkscape.

“But I can’t draw,” you say…? Sure you can! Because basic shapes and simple lines will do just fine. There is so much we can make without any classic drawing skills, and this is precisely what I want to show you. See, this is something anyone can draw:

Basic shapes make great building blocks in illustrations, and the code is both readable and writeable. A <circle> needs a radius and a center point in coordinates. While <rect> is drawn starting at coordinates for a top left corner, along with width and height.

Colour can be set with the fill and stroke attributes. Note that if the fill attribute is missing, it will always default to black if there is an area that can be filled. This means you want to something like stroke="YellowGreen" fill="none" for an outlined shape.

I like jumping back and forth between drawing and code. Vector graphics software has helped me learn the elements, and to draw more complex paths I’d never want to code. But after drawing, I will use a text editor to tweak and optimize the output.

After you first start playing around with SVG, there are many paths you can take. Check out Pocket Guide to Writing SVG by Joni Trythall, and dive into the many articles on SVG by Sara Soueidan. Start creating basic animations? Or enter the d3.js rabbit hole…

…but don’t forget to scatter some fun illustrations or abstract backgrounds around in that web site you had in mind. Happy holidays — and enjoy your SVG adventures!

If you’ve written CSS long enough, you’re probably aware of the waves of features that we get to use across many browsers. In the mid-2000s CSS modules for border radius, background gradients, text and box shadows, and media queries were making their way into browsers.

After a monolithic release of CSS3 (or CSS level 3) specifications being published and executed upon by browser vendors we were in a lull, it felt like the development of CSS specifications stagnated a little.

During that time there was also debate amongst browser vendors about vendor prefixes.

Some front-end developers seemed only to write CSS for webkit browsers (Chrome – at the time – and Safari) leading to browsers discussing adding aliases in their rendering engines so that their browser too could render the website as it ‘should’ be. Yet at the time there were various ways to create all of the prefixes required.

Waving the flag

To cut a long (or not so long) story short most browsers ended up hiding new, draft CSS features behind flags and, CSS felt like it stagnated a little.

Ultimately though, this was the better decision; allowing authors to create more robust specifications, letting developers test these new ‘works in progress’ and feedback any issues in the spec. or to the browser vendors.

Onwards, to the future

I think we are in the the initial splashes in another wave of exciting CSS for us to dig our teeth into.

We are seeing the pages of can i use go mainly green for CSS modules like variables, flexbox, filters, scroll snap points and we are very close to being able to use grid across popular, modern browsers.

CSS. It’s broken, in two

Looking at the current drafts for CSS module specifications I feel that we can see CSS is starting to provide us with two clear tranches. That which is inside the curly brackets and that that is outside of them.

/* CSS that could start here */


.elf__hat {  
  /* CSS that would go here */ 
}

On the inside we have rules available to use to style, we can add colour, shadow, rounded corners, filters. CSS ready for us to use that will affect the look and feel of what we are creating. CSS that determines the ‘cosmetics’.

On the outside we have CSS that helps with how we architect our CSS. CSS that can make our codebase more manageable, maintainable, and understandable. CSS that may well not do anything unless it’s added to or invoked by another CSS property.

I’m on the outside

Currently, available today is the custom properties for cascading variables module. Although not strictly ‘outside’ of the brackets, CSS variables allow us to architect our codebases more clearly and succinctly, making them more maintainable.

CSS variables are set by using a custom property (--brand-color--main) and are accessed (with the curly brackets) by using var(). To be sure that we have the values available to all elements in our HTML we place the variables in the :root.

:root {
  --brand-color--primary: #DA2A32;
  --brand-typeface--heading: "proxima-nova", sans-serif;
  --brand-typeface--body: "freight-sans-pro", sans-serif;
} 

We can then call them wherever needed in the rest of our stylesheet, using var().

#main-header {
    background-color: var(--brand-color--primary);
}

I’m looking in

The CSS available today for us to style our HTML is long and winding list. As mentioned further up this post we have flexbox, filters, grid (soon, soon), scroll snap points and more to create our websites with.

There is so much, that this article would turn out to become several books-worth of what is available for the ‘cosmetic’ side, so I won’t start listing all of them here.

It’s almost paradise

Looking at what Safari are doing and reading through the issues and updated specs on the CSS Working Group’s GitHub page there’s several exciting modules making there way to a browser near you soon.

Again we are getting CSS that will help us with the cosmetic (the inside of the curly brackets) and the architecture (the outside) of our stylesheets.

When they’re in, they’re out

CSS that is nearly within our reach to use on the cosmetics of what we are creating are both new and old, some of what we could be using someday (real) soon has been around in the specification drafts for few years already.

We have exciting things like backdrop filter, shapes, regions, and more. CSS that is almost all green in every popular browser.

When they’re out, they’re in

With what (to me) seems a re-ignition of creating and pushing forward new CSS modules, we also have exciting things in the CSS specification drafts for code that will allow us to architect our CSS better.

If you are familiar with preprocessors, as well as variables (CSS Variables) you will be familiar with features such as nesting, and mixins. These could be on their way to the browsers soon for us to take advantage of, allowing us to make better maintainable code. Mixins get a little naming refresh with @apply and nesting acts similar to what you would be used to if you’ve ever nested in Sass.

In the sky, with diamonds.

We can use the future CSS today. Kinda. PostCSS allows developers to create plugins to polyfill or prollyfill draft specification CSS so that we can use it today. We can now ‘fill the gaps’ with plugins for nesting, mixins (@apply), a better @import and much, much more.

That is fantastic, but we need to be mindful. CSS draft specifications are subject to change.

If you start to rely on a plugin to polyfill or prollyfill your current project with code that might be available natively in the future, you must be prepared to ‘watch for the changes’. Some specs change a few times before their candidate release (flexbox or grid for example) and at times, parts of or whole specifications get depreciated.

I can see clearly now

As I’ve mentioned, I think we are on the cusp of a new wave of exciting CSS feature we can use. CSS that not only makes our design patterns and layouts more robust and usable but CSS that makes creating and maintaining the code in our stylesheets more manageable and better.

With this new wave of CSS giving us the ability to write better code and create better products in doing so we should benefit the person taking a look at our websites, web apps and products.

Yet, we must still give due diligence, not everything that’s being created in the drafts, and that’s ok. What is really exciting about this is that, those drafts being in the open and on Github make it easier for us to contribute and voice our ideas, opinions and thoughts on what’s being worked on.

Merry Xmas and a Happy New CSS Year.

I posed five questions to five developer advocate’s from today’s top browsers:

• Ada Rose Edwards, developer advocate at Samsung Internet
• Jake Archibald, developer advocate for Google Chrome
• Martin Beeby, technical evangelist at Microsoft
• Soledad Penadés, Devevangineer at Mozilla, and
• Shwetank Dixit, who worked in the developer relations team at Opera for 9 years

I also spoke with an advocate to speak about Safari, however sadly they declined to participate. Hopefully next year.

Now, let’s dive into the questions!

To kick things off I wanted to ask what has been your the feature released this year that you feel is already making an impact on how we can build better experiences on the web?

For Jake he’s either been talking about Service Worker or streams lately, so I was not surprised by this answer:

I would say streams! – I don’t think they got as far as I thought they would in 2016, but they’ve showed that a progressive approach to content delivery is the fastest way.

Keeping along the lines of performance Soledad picks out two of her favourite features that will have a massive impact on performance:

Well, I’m torn between two things which are sort of complementary: Service Workers and Let’s Encrypt.

Pardon the terrible comparison, but Service Workers are like eating the mushroom in Super Mario Bros. Suddenly you get all these new cool things you can do, while still being a jumping plumber. But if you do not eat the mushroom you can still be a plumber. Service Workers are like that, if your browser supports them, your website gets lots of additional features that make it better for users, but if the browser doesn’t support them, users can still use the website.

Service Workers help developers take the network factor into account, and build websites that can work faster and more reliably by caching content for later access, amongst other great features. Users can trust the Web again, and developers do not need to write three or four different native wrappers around WebViews that access the same API end point. Happy users, happy developers!

It was really exciting to see websites take advantage of Service Workers soon after we shipped the feature in Firefox. One day we barely saw any registered worker in our developer tools, and the next week there were lots! (if you’re curious to see whether you’ve visited websites which use Service Workers, type about:debugging in Firefox’s URL bar, and go to the ‘Workers’ tab).

And Let’s Encrypt… granted, it was “launched” last year, but it was still in beta. This year has seen tremendous growth, and it is fantastic to see that. This service issues free SSL certificates, which makes delivering secure websites possible for everyone, and this is truly important because new features such as Service Workers only work when your code is delivered with https, for privacy reasons.

Developers had to spend money in a certificate in order to use https. And we want the Web to be secure, but we also do not want to limit access to the Web to just rich developers; that would be against the very principle of the Web! But Let’s Encrypt changes this. People can now get certificates for free, and they will work for everyone, without rightfully scary warnings from browsers.

I’m really pleased to see adoption going through the roof. It’s great!

The theme continues with Shwetank’s talking about what all these features allow us to do:

I think the whole progressive web apps movement got a serious boost this year. Granted that it’s not one single feature, but a set of features working together to create an enhanced experience. Some of these are web specs (like Service Workers, Push Notifications, Web Manifest) and some browser features (Like Add to Homescreen, for which web manifest is needed). Even though some of the work in this regard had been happening last year too, the majority of the improvement and polish in browsers like Chrome and Opera happened this year. This year we finally saw big businesses adopt PWAs as part of their corporate Internet strategy with sites like Flipkart, AliExpress, The Washington Post, Telegram, The Financial Times etc all coming on board. Many of those companies have blogged about how PWAs are already making a positive impact for them on key business metrics.

Me and a few friends from the former Opera Devrel team contribute and maintain a list of great PWAs – I’ll advise anyone getting in Progressive Web App development to go through those sites for inspiration and ideas.

I was starting to wonder if any of the interesting things would be CSS based, but fortunately Ada rescued me there:

CSS Grid – it’s coming out now, will go stable next year and will revolutionise the way we build websites. We can go back to building very semantic html, which renders in a beautiful Grid Layout, removing the need for DIVs for rows of content. It can be feature sniffed with @supports (diplay: grid) {}. This allows one to use it today where it is supported but fallback to something simpler in other cases. As grid support improves, users will get an enhanced experience without you needing to ship a single line of code.

And finally, Martin looks at one of the features that’s helping to improve developer productivity:

For me the biggest change in my own development has been the new features of JavaScript. I’ve adopted a number of the new features and am now using them day in and day out. In some instances I’m using TypeScript to convert the syntax into something that can be deployed to the web, but since most of my work is demoware and Proof of concept I’m often free to use it in it’s pure form.

Whilst you could argue that the syntax I use doesn’t have an impact on the end user experience of what we are creating I would argue that These new features in JavaScript are giving me better productivity and help me avoid simple bugs and so give me more time to add value into my apps rather than writing thousands of lines (or importing libraries) just to implement a specific design pattern.

My absolute favourite feature is Async/Await which reduces the headache of writing complex Promise or Asynchronous code. In this Gist I have added the same function call using plain promises and then in the 2nd example using Async/Await. It ultimately tells the JavaScript engine to do exactly the same thing but the 2nd version is so much cleaner to read particularly if you have lots of nested Async calls.

At 12 Devs we always like to hear about the things that people are interested and excited about, with that in mind, what new feature has you excited about the web and why?

Speaking from recent experience Martin looks at some of the things he’s been building with lately:

I’m building lots of bots recently for Facebook Messenger and Skype using the Microsoft Bot Framework. One of the more common requests we are getting is once the messenger bots are established they want to then have the bot be available through their website too.

This is perfectly possible using the framework and one of the things I have been doing frequently to not only have the bots respond using text but also, via the browsers baked in Speech Synthesis, have the bot speak to the user. You can find an example of the Speech Synthesis over here and a basic implementation example in this Gist. For browsers that Don’t have Speech Synthesis features I’m falling back to cloud based Text to Speech APIs.

Shwetank and Jake continue their theme’s from the previous question as well. First Shwetank:

Going with the progressive web app theme, it is possible that PWAs might be able to be installed as an actual APK soon, like like any other Android app. This has potential to be huge, as this means web apps could be side-loaded into phones and it can appear not just on the Homescreen, but also in the android apps list, along with all other native apps.

Henrik Joreteg has written a nice post about it which should check out.

And Jake:

I’m still excited about streams! Especially what we’ll be able to do with transform streams in 2017. Also, I really hope we can deliver a streaming html fragment.

I’ve seen Ada getting really excited about WebVR in a couple of talks lately, so it’s no surprise to see her answer:

WebVR: since I was child Cyberpunk novels promised this idea of a shared virtual reality that would grow out of the internet!! It’s happening!! It’s still very early days; currently it needs WebGL, but tools like A-Frame allow scenes to be written up in HTML!!

The abilities of the web for authoring content, delivering media and making complex APIs accessible to even the newest developer for free, cross platform, is incredible. This makes it the perfect platform for even novice developers to get stuck in and start building web sites. All you need to get started is a .html file and text editor.

If we can bring this level of accessibility to 3D and Virtual Reality then the cyberpunk utopian future of the web in which we share in experiences made by our own communities will really come true!!

And Soledad goes a bit meta, talking about a whole new browser engine:

Well, it is not strictly a new feature, but a new browser engine: Servo! It is written in Rust, a new programming language, which has modern computing platforms in mind, and takes advantage of all the hardware in nowadays devices in the most efficient way: using multicores, using GPUs, parallelising as much as possible. This is great for speed, and also for energy consumption: using more cores but at slower speeds results in less consumption than one core at top speed. Energy is a huge factor for success in mobile platforms, and the future is mobile.

Unlike older browser engines, Servo is modular by design, which means that parts can be plugged in and out, and even reused elsewhere. This benefits the ecosystem way more than if you have a huge “Browser Monolith repo” where all sources go to die: if you like one of these modules, you’re free to use it. And Servo might even consume modules from the ecosystem as well, even if they have not been specifically written with a browser in mind. It’s a more modern way to develop.

We don’t want to wait until Servo is a feature complete browser, so we are taking parts of Servo and bringing them into Firefox already. We call this Quantum: https://wiki.mozilla.org/Quantum – if you downloaded Firefox sometime after August this year, you have already been running bits of Servo/Rust code in your machine, and there will be more of this in 2017.

I’m very proud that we’ve invested time and resources in building this solid foundation for the future. Even if the results have not been immediately visible, it makes existing websites more performant, enables new use cases, and helps us ensure the Web continues to be a successful platform, ready for all upcoming challenges.

Is there any more obscure feature you’ve stumbled upon by accident that others might not be aware of?

I thought this question might turn up some interesting answers, and I wasn’t disappointed. First Soledad:

I’m always stumbling upon things and going all “WHOAAAA, I didn’t know this existed”!!!

One of the latest is the currentColor keyword – it is similar to a CSS variable in which you can use it wherever you would use a value. This is very helpful if you want to write modular CSS. I wrote a little post and demo about this feature.

I learnt about it from Glenn Maddern’s talk at Cold Front last year in Copenhagen

Not sure if this counts as ‘by accident’, though…

As expected Jake has found so many things! He’s given us a great list to check out:

Ohh a few!

Moving elements out of an iframe while the parser is still writing to it.
The difference between audio decoders across platforms and browsers.
The inconsistencies between canvas+svg+media queries.
How CSS custom properties can be used to manage states
And createContextualFragment, and how it differs from innerHTML in terms of script execution

Next we have some great little features along with some code examples to get to grips with. Starting with Ada’s look at state selectors:

One thing I particularly like is using the checked pseudo selector in CSS to hide/show a subsequent element. This allows you to have dynamic elements powered only through CSS, allowing you to control the behaviour and style of a drop down menu in CSS and it breaks down really nicely in the case that the CSS file fails to load.
e.g.

<label for="toggle" aria-haspopup="true"Click me</label> 
<input type="checkbox" id="toggle"checked /> 
<div aria-label="submenu">Hide me, show me</div> 

input:checked + div {
    display: none;
}

Next Shwetank explores a handy API for working with URLs:

It wasn’t really accident, but in my experience, not a lot of people I talk to are aware of URLSearchParams Try a demo. It can come in pretty handy in certain situations.

Basically, this nifty little API makes dealing with url parameters very easy. Till now, if you wanted to parse, read or manipulate URL parameters, you needed to use regex, which isn’t really that fun. With URLSearchParams, we now have simple getters and setters etc to manipulate them. For example if you have a URL like:

const myURL = new URL('https://example.org/?firstName=Bruce&LastName=Wayne');

then to get the first name, all you need to do is

let fName = myURL.searchParams.get('firstName'); 
// will assign fName as 'Bruce'

Append to the URL with

myURL.searchParams.append('secretIdentity', 'Batman'); 
// value of 'myURL' is now 'https://example.org/?firstName=Bruce&LastName=Wayne&secretIdentity=Batman'

and change it with something like

myURL.searchParams.set('secretIdentity', 'The Dark Knight'); 
// value of 'myURL' is now 'https://example.org/?firstName=Bruce&LastName=Wayne&secretIdentity=The+Dark+Knight'

Eric Bidelman wrote a nice article on it which is worth checking out. Andrea Giammarchi wrote a polyfill for it too.

Finally, Martin has a play with the audio API:

Web Audio isn’t exactly obscure, but I think this use of it is.

If you pop the following code into your console you should hear a continuous tone. (GIST Here).

var context=  new (window.AudioContext || window.webkitAudioContext)();
var oscillator = context.createOscillator();
oscillator.frequency.value = 5000;
oscillator.start();
oscillator.connect(context.destination);

This starts with a tone with a frequency of 5000 which most people with hearing should be able to notice it.

If you create a tone with a frequency greater than 15000 only those under 40 will be able to hear it and a frequency above 17500 can be heard by only by those 18 and younger.

oscillator.frequency.value = 15000;
oscillator.frequency.value = 17500;

This festive season why not turn your speakers up high and use this method (starting at 17500 and then reducing by 1000 at a time) to figure out who is the youngest in your office.

If you want the sound to stop simple run this:

oscillator.stop();

If there was one feature that you think developers should know about or be working with in 2017, what would it be?

Again, Ada’s answer hit’s close to my heart talking about CSS layouts methods we should be using more now:

Flexbox: it is incredibly powerful and I fear not enough developers use it. What you learn in flexbox is applicable with CSS Grids and they can be used to do some marvellous layouts very simply with HTML that looks incredibly neat. BE CAREFUL though because they can be used to change the order of elements which may have bad consequences for people using a screen reader.

Soledad echoes this brilliantly too, it’s time to jump in with Flexbox!

I think it’s time for people to shake off their fears, and embrace Flexbox to build layouts. Support is exceptionally good across browsers, and if you are building a new website you probably have no excuse to not use it.

If you are not building a new website, but working on a existing codebase, use every opportunity to see if you can replace old style potentially problematic code with Flexbox instead. You know, those definitions where sizes are essentially a collection of “magic numbers”, like for example:

.terror {
  height: calc(100% - 195px - 0.7rem);
}

You can often avoid writing this kind of rules by using flex and flex-grow. It will be simpler, easier to read and debug, and more maintainable on the long run.

I like this guide from CSS Tricks on Flexbox – I use it all the time!

Martin takes on a look at something that will change the way we buy things on the web, which is really exciting:

I think the Payment Request API is really interesting. It’s basically the ability to allow the browser to manage the Payments part of an Ecommerce experience. It has a number of potential benefits for the user, in particular it will allow them to use their digital wallets to easily buy stuff on the web and to never have to enter a billing or shipping address ever again. This has the potential to be hugely important, it could even disrupt the dominance of larger Ecommerce sites as transacting with smaller companies will now have less friction. Of course it also has the potential to be a huge flop. Either way, I’m intrigued by the possibilities of it.

Shwetank looks at a spec for improved performance:

The Preload spec. This was implemented in Chromium earlier this year, and I hope in 2017 more browser engines support it.

Basically, by using <link rel="preload"> you can tell the browser to preload some resources that you know will be needed later on for the current page. A common use case for it (though definitely not the only one) would be web fonts.

Right now, you often find web fonts taking time to load even though they are critical resources. This is because most browsers preloaders do a shallow parse of the JS and CSS, which means that Web Font declarations are often missed by them. So now using rel="preload" you can explicitly tell the browser to fetch the resource early because you know you’ll need it later in the page.

Yoav Weiss implemented the spec in chromium and wrote a great article on it over here.

Jake also backs up the focus on the performance aspect of the web too:

Ahh well I’m always going to say “service workers”. But really, anything that improves the performance of unpredictable network conditions.

Finally, looking ahead to 2017 there’s already a lot of exciting looking features that are starting to make their way into stable browsers, like CSS Grid and even WebVR for instance. What’s the next feature you’re excited about seeing begin development and testing in 2017?

In the final question I wanted to see what people thought about the future of the web and some future features we’ll be seeing talked about a lot next year.

Shwetank kicks off this final question with a look at something very interesting that could broaden the reach of the web in the new year:

I really find Web Bluetooth exciting. The ability of the web to talk to physical devices will be amazing. Instead of downloading and installing an app for each of your hardware devices, imagine just opening up your browser and going to a web page to control them. When you’re done, just close the tab. There are already demos involving controlling toys, drones, and other IoT devices. I wrote an article introducing the Web Bluetooth API over here.

Martin has another new one for me, which I’ll be interested in seeing develop next year as well:

I’m really excited by 360 Video. Not just the virtual reality experience of 360 video but even the regular 2D browser experience of it. Take for example this project built using Babylon.JS.

I love the way that they have 360 video and text working together and I suspect that lots of web designers and developers will be working on finding the patterns and practices that make experiences like this main stream.

Following Martin’s look at 360 video, Jake looks at another way we might be working with images on the web next year:

I guess I gave my streams answer earlier, but I’m also excited about createImageBitmap.

It has already landed in Chrome, but the missing bit is being able to rasterise SVG in a worker. Right now it’s difficult to hit 60fps when zooming SVG because it paints on every frame. createImageBitmap would let us do super-fast bitmap transforms while rasterizing shaper versions in a background thread.

Taking over Jake’s Service Worker baton for the final question, Ada looks at a new feature being implemented at the moment which might add another dimension to how we use Service Workers:

I’ve mentioned CSS Grid and WebVR already but another feature I think will be great is a new one for Service Workers: Cross Origin Service Workers and Foreign Fetch! It’s a bit of a mouthful but they will allow CDNs to setup their own service workers. When multiple sites are sharing the same Service Worker then it will greatly reduce the network load for commonly reused resources. Here are some example use cases:

• Large popular library, e.g. THREE.js
• CDN with browser specific libraries e.g. The Polyfill Service
• Large reusable 3D models, e.g. In WebVR it is common to include 3D models of the controller which is being used in Virtual Reality, these models could be downloaded once and used again and again across different domains.

The advantage of all of this is that if you use a popular library the user may already have it cached and ready to go!!

Finally, Soledad looks at one of the things I’m most excited about next year, CSS Grid:

Grid is certainly one of the next big things. Firefox and Chrome just turned it on in the nightly browsers, and we even have support for debugging Grid on developer tools – we’ve worked hard to make sure developers can debug and inspect Grid from the start! And the feature should become available to stable browsers some time next year. Here’s an article talking more about it

In the meantime, it’s a great opportunity to learn and embrace good mark-up practices and Web design, in the sense that designs that take into account the diversity of browser support for various features are great designs.

You can use feature queries and @supports to enable conflicting parts of your CSS stylesheet depending on browser support, so you serve the same mark up code (HTML) and a stylesheet with various @support sections and different browsers will render it differently depending on what they can do. Here’s an article explaining how to do this

And this is not a prediction, but a wish: I would really like to see Safari/iOS support Service Workers in 2017. This would be huge!

And finally we’ve reached the end of our mammoth tour around the top browsers, the new features they’re excited about, and some interesting things you might not have known.

A huge thank you to Ada, Jake, Shwetank, Soledad, and Martin for being involved.