Scotland JS was held on the 2nd and 3rd of June at Dynamic Earth in Edinburgh. There were numerous talks, a few interesting and/or useful of which I have detailed here.
There were a few others, such as VR, JavaScript desktop applications and LiveJS (A demo of using MIDI input to create visuals) that I have not covered. If anyone wants to know more about these, I can also write up the notes I have about them. The rest I have written my notes on and what we can take away from them.
ESNext and the future of JS
Jem Young – @jemyoung – Senior UI engineer at Netflix
Services workers are the future. Much like a web service, they sit outside the browser performing tasks in a separate thread. However, unlike a web service, they remain even when the tab is closed and continue working when it is re-opened. They have a heavy utilisation of promises and cannot use local storage. These could be a very powerful tool that we could start using. Jem also provided an example.
https://young.github.io/service-worker/
There is no direct control from main thread, and it proxy fetches events and modify requests and responses. It is persistent and has cache storage and an API.
When the service is fired up, it starts working. When it is stopped, it will still work thanks to the caching. Even if the tab is closed and reopened. I think this will be a huge part of future applications we develop as they have the potential to replace so much functionality.
Open Open Source
@charlotteis
The basic structure of a readme file is very important for open source software. They spoke of the structure and what to include, listed below.
- Title of project
- Short description
- Link to Code of Conduct
- How to install and use it
- Link to tutorials
- Where to go for help
- How to file an issue
- Things you want help on
- How to get in touch
- Project issues (GitHub issues)
Each of those bullet points is an important part to be included for any potential user. This way, each aspect of the project is covered. With our handovers I think we already cover what is necessary but it is worth taking into consideration this list in case there is anything we might want to add.
It was also pointed out that it needs clear wording to avoid confusion and suggested to use language such as ‘they’ or ‘them’, as the user(s) may be anyone.
Let’s talk about MIDI
@rumyra
MIDI, yes that midi – Musical Instrument Digital Interface. The digital interface part is important, as this is what this talk covered. As it is basically an array input, e.g. [144, 60, 100], it can be useful. The numbers refer to Note on and Channel, Velocity, and Pressure. There are a lot of specifications that have not yet been implemented. These are currently sitting in W3C.
There is no timing in the web MIDI API, which is problematic. This was demoed by getting everyone to open a webpage and having that webpage play a sound. Each device played it at a different time. In JS, there is more control over the API input and animation linked to it.
Through using the MIDI specification it can be used to play a sound in the browser without having to load in files or other resources. For example, a beep to confirm an action.
Overcoming the challenges of mentoring
Kim Crayton @kimcrayton1
A very interesting talk on the challenges of mentoring and being a mentee. The proposition was made that senior programmers already have a job, and have it the way they want it. This means that it is far more likely to mentor junior programmers into a job than hiring new senior ones. The developer community needs to do a better job about mentoring people learning to code.
Mentoring adults is focussed on gaining careers success aka ‘How do I become the best at what I do’. Personal mentoring can take any form, it is unstructured and usually open ended, and professional mentoring should be seen in the same way as an apprenticeship programme.
Conversely, solutions such as Stack Overflow is a last resort ‘my house is on fire, put it out’ type scenario. It is not mentoring.
It is worth looking at how we mentor and how people learn, as everyone both teaches and learns differently.
I’m Offline. Cool, now what?
Ola Gasidlo
Ola spoke about how applications should care more about the screen before the network. The more that’s there before the network, the more ‘offline first’ it is. This method of development focusses on the application working before the network. The main example was the Chrome web dinosaur. When there is no network, the application still works and there is the game Google implemented with the T-Rex.
The talk continued about how you should think about the issue rather than the tools. For example, the gorilla and banana problem (you wanted a banana, bit got a gorilla holding the banana and the whole jungle). Solutions include checking your requests – would 1 do where 20 exist? What data do you want to send and receive? Or coding assets for in browser storage. Base64 over IMG improved performance, but it shouldn’t be done just because you can. Plus it is a heavy task to be done on the fly.
JSON web tokens are great.
Async JavaScript at Netflix, Microsoft and the World
@mattpodwysocki and @reactiveX – Microsoft open source projects
Netflix has a big asynchronous problem because everything they do is asynchronous. With events and states, which one do you handle first and which state do you keep around? Promises are part of a solution, but not the solution. For example, cancellation is not implemented yet.
Can we do better?
Reactive programming where we react to the load helps drastically. Netflix uses polling to get what you want in view. It polls for row updates and continuously gets row data until it starts hiding new data.
Another example is the spell check in Slack – When the user stops typing for a short while, it determines the language and if a word is misspelt.
This would be a useful technique for applications where the load will be high and variable.
Web Bluetooth in the browser
The talk was about interacting with things around us, aka The physical web. They spoke about Eddystone, which is used in conjunction with iBeecon to interact with physical objects.
For example, they mentioned a parking meter that instead of entering money into, you would pick up the ‘object’ on your phone as something to interact with. Then you could use its actions to pay online.
Of course, none of this works unless you have data. URLs may not be show up as you need Internet. A good idea in practise, not particularly something we could implement here right now, but may be worth bearing in mind for the future.
Designing for big screens
@potch – Developer advocate at Mozilla
They use large screens for:
- Dashboards – Jenkins builds, Github etc.
- Public access programming – Firefox bug count and what’s shipping right now
- On Demand programming – instant results for request (press button, get result e.g. puppy button. Press button, get puppy gif), Share URLs or images to TVs.
Following the rule of ‘The ten foot user interface’, what can be read from 10 feet away, is a good design practise for big screen design. It was pointed out that mobile design for phone screens will pay off as TVs can be considered the same, just further away. So all the work we have done with mobile design can carry over to large screens.
An interesting point about CSS was Viewport. It makes elements dimensions a percentage of the screen, causing everything including text to scale like an image. Very useful for scaling.
Not to mention navigation considerations, such as navigating around the page using arrow keys and the tabIndex.
As for how to display these on a large screen, we already implement the dashboard screens and have the Mac Mini. These are some of the more expensive options, and should really be more utilised.
HTTP/2 – The Weird parts
@smithclay
When building more and more complicated websites with HTTP and TCP requests, HTTP/2 can address problems that can arise. HTTP/2 has 10 frame types – frames get reassembled into standard requests/response messages over multiple streams.
The front end implications are that there is no need for concatenation, sharding/spriting, inlining etc that are used to reduce requests.
There are a few ‘weird’ frames, such as push_promise frame. (Like http request recognition) GOAWAY frame that terminates the TCP connection and PING frame which can safely tests the connection without a request. The last one would be quite useful when we need test connections without putting load on the server(s).
How Cognitive phychology can help you write better code
Silvia, Developer for Zalando
Biases in programming can cause a lot of problems. Cognitive biases can cause shortcuts to be taken, which end with worse code or more work down the line. Representative bias means salient features of the code base judged as more frequent and mental representations in programming cause an over-representation of features that are easy to remember and under-representation of those that are hard.
Along with numerous other kinds of bias, we spoke about how to overcome them and where. A first step is to adopt multiple perspectives when tackling a problem, question assumptions and consider the improbable and unpopular.
This means that when testing, negative test cases should also be tested to prove something fails as well as works. Only testing positive cases can means a lot of failing scenarios are overlooked.
We also spoke in discussions about someone’s solution to bias, which was to highlight code that was covered by tests. This means that all code was covered, regardless of what the programmer thought about whether it needed it or would work regardless. However, when it came to testing it introduced a new bias of ‘Oh that line is highlighted, so that means its already covered and we don’t need to test it’.
Monitoring on a budget
CJ Silverio @ceejbot
Monitoring is pulling data in. The best way is to ask questions you already know the answers to. Is this host up? Is the HTTPS certificate about to expire? Is the DB replication keeping up? If answers are wrong, something is wrong. So we now know, and it can be fixed.
An even better way is to automate the fix. If a server is down it should be restarted for example. Using monitoring to ensure everything continues working helps alleviate a lot of work.
Anomaly detection is another reason for monitoring and why we should probably focus more on it. As we had the performance issues in DEV client recently, this was spotted by human eyes and not flagged automatically. With monitoring data like this, we could be informed of changes in run times and other such metrics.
The end point of the talk was to automate as much as you can and not to require humans.
Creating Accessible components
Kat – BBC accessibility (Glasgow based) Web developer
People assume that people know how to do things. Providing accessible resources allows all sorts of people access. Having said that, the talk covered what most of us already know and cover with regards to usability and how to test it.
Though they did cover aria, which doesn’t ‘do’ anything, it just describes the element. It tells the accessibility API what the element does. ARIA attributes update when an element changes state.
The rest of the talk covered how to test accessibility on different devices, which I’m sure we all have material available on usability testing to reference when we need to do this. A couple of links provided for this:
http://webaim.org/articles/
http://tink.uk/
http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile
Surviving JavaScript
@rmehner
A very interesting talk on opinions and trends in the JS community. Frameworks change, the popular things everyone switches to, and everyone has opinions.
The best solution is not to have opinions. Use robots to have opinions for you, for example using standard.js (Like our JSCS implementation).
Bullet points they went through to iterate the idea of surviving JS:
- Move fast and break things
- Burnout is real
- Pick your battles
- Learn techniques, not APIs.
- It’s OK to not know everything
- Ask questions
- Find your own pace
- Learning takes time
- Don’t compare yourself to others, only to your own past self
- Be one of those loud voices
- ‘code doesn’t matter, humans do’
Which may end up being soundbites, but they each have a point.
Fear
Raquel Velez
The final talk was from Raquel Velez who spoke about fear. Basically, what could we achieve if we weren’t afraid? Everyone from junior to senior developers gets afraid at some point and how do we deal with stress?
Everyone has their own techniques and harnessing the knowledge of how your brain works can help you push out your code. Knowing everyone is human means you too know that everyone can make mistakes.
Other links
Richard Littauer has a good write up of the conference here with his perspective of the talks: https://medium.com/@YLDio/scotlandjs-2016-69ed8a588161#.ede2rz9f1
ScotlandJS twitter – https://twitter.com/scotlandjs