Here are my notes on Day 2 of Scotland JS. If you are interested in reading my notes on Day 1, you can find them here.
JavaScript craftmanship
Speaker: Francisco Ferreira
Ferreira discussed how to write beautiful, maintainable JS code. The talk covered various best practices and “top tips”.
- Better code readability makes code easier to change and maintain.
- Tests should be small, readable, and independent from each other (Ferreira is using Mocha for testing).
- JS is not object-oriented and can only simulate it.
- We can create an object using an IIFE and then attaching functions to “this” to make them public.
- Capitalise names of objects which are meant to be instantiated using “new”.
- Abstract your functionality and name it. This will make your code more readable.
My thoughts: A lot of good, basic advice here on improving your JS code style.
Memory leak health check (slides)
Speaker: Andrew Duncan
After being tasked with writing a JS application which had to run months on end continuously without crashing, Duncan was forced to start doing serious memory checks on his code. In this talk he covered some basic techniques that you can use to check for memory leaks.
- A lot can be done using Chrome DevTools (task manager, timeline, profiles)
- OS performance monitoring tools can further support this: Perfmon, PsTools
- Using automated testing can help reduce the “observer effect”, whereby you affect your performance just by monitoring it (e.g. running the monitoring tools causes an additional performance hit)
My thoughts: Although we don’t need to write applications which need to run for months on end, we do write a lot of staff-facing applications. For these it is best if they can run for at least one working day without crashing! A lot of the techniques he discussed are quite basic, and I am planning on trying them out. This also highlights the importance of automated testing, which we are trying to do more of.
Improving pattern libraries with Polymer
Speaker: Sam Beckham
In this talk Beckham gave a quick introduction to Polymer, a new way of writing web components.
- A pattern library is a collection of code examples (e.g. Bootstrap). These are useful but require a lot of cutting and pasting, and can be difficult to maintain.
- Polymer is a web component framework.
- Using Polymer gives you drastically simplified markup and makes it easier to swap out components.
- Markup, styles, and scripts for each component are bundled together.
- Not supported by all browsers (but polyfills help)
My thoughts: I was quite impressed by this and think that Polymer looks great, but it’s limited by the fact that it isn’t supported in all browsers (especially older ones). At the university we have to give as wide a support for browsers as possible, so this means that we probably won’t be able to use Polymer at the moment.
Writing beautiful JavaScript tests (slides)
Speaker: Kim Joar Bekkelund
This talk looked specifically at writing readable, easy-to-maintain JS tests. The examples he showed were written using Jasmine, but can easily be applied to any testing framework.
- Focus on the reader – we usually spend more time reading code than we spend writing it.
- Minimise test setup. DRY isn’t always the answer if it makes tests harder to read and debug.
- Use creation helpers in each test – functions with semantic names which help you set up for a test – rather than putting everything in your test setup steps. This keeps everything for this test within the test itself.
- Reveal your intent. What are we testing?
- Make tests deterministic – eliminate conditionals (if, for, while, etc.)
- Functional code is easiest to test.
- Separate your DOM from the test logic.
- Tests need to fail when they are supposed to fail. A test that never fails is useless.
- Asynchronous tests need to tell you when they are done (or they won’t fail properly)
- Test structure: 1) arrange, 2) act, 3) assert
- Refactor your tests along with your code. Focus on craft, not tools.
My thoughts: I found this talk to be one of the most useful out of the entire conference (you can see I took a lot of notes!). I’m quite keen on testing but (like most people), I struggle with writing good tests. Bekkelund mentioned that when people first join his team he has them specifically write “Arrange”, “Act”, and “Assert” headers in their tests until they get used to writing in this style. Sounds like useful advice!
Accessibility and JS-based websites
Speaker: Mark Connell
Although the title of this talk just says “accessibility”, Connell mainly focused on making websites accessible for screen readers. He gave a quite introduction to screen readers, and then showed some examples of how you can design your website to make it easier to use for people who are using them.
- Accessibility is important because we should be making websites for everyone. This includes users with disabilities, low literacy/numeracy, or limited internet access.
- Don’t mess with browser behaviour.
- Try using your website with a screen reader (On Macs you can use VoiceOver).
- Be careful with event bindings. Dictation software won’t register as a key event in JS, so use “input” instead.
- Follow WAI-ARIA standards: use additional labels, hide unneeded content, and notify users of dynamic content.
- Compress your JS before deploying it.
My thoughts: Peter Pratt recently gave a presentation on the WAI-ARIA standards, and I have already started using some of the tags. This is an easy way to start adding a bit of accessibility into your website. Connell’s other suggestions here are quite sensible and equally easy to adopt. I think that a lot of the time we make a fuss about adding in accessibility features because it is “extra work”, but actually it’s not that time consuming to do most of these things.
A monad is a burrito and other functional myths
Speaker: Joe Nash
Nash tackled some of the various myths surrounding functional programming.
- What is functional programming?
- Higher order functions = functions that operate on each other
- Purity of our functions means that we limit side effects.
- Don’t feel like you need to be purely functional. Adopt the parts that you like and that work for you.
- For further exploration: Typescript, Elm
My thoughts: For me I didn’t find this talk quite as useful. Nash seemed to take the approach that many people find functional programming intimidating, so set about trying to convince the audience that it wasn’t. I don’t find it particularly intimidating (although now I feel like I should!), so I guess I wasn’t the target audience here. That said, both Typescript and Elm look quite neat and I’m interested in playing around with them a bit further.
Exploring multi-screen web technologies
Speaker: Hubert Sablonnière
This talk demonstrates various techniques for applications which operate across more than one screen. For example, applications that run across more than one device, or even just two windows on the same computer. For further reading Sablonnière suggested The Humane Interface by Jef Raskin.
- We can only focus on one thing at a time.
- A secondary screen acts as an extension of our short term memory.
- Don’t take all the attention (unless it’s really important).
- Two browser windows that talk to each other:
- Can be implemented using window.open() and then postMessage(). The second window listens for messages.
- Another idea is to store mutual information in the local storage
- Can also use a SharedWorker() to pass information
My thoughts: I didn’t expect to find this talk to be that useful, and was surprised to find out that it actually gave me a lot of ideas. We develop a lot of staff-facing applications, and many staff members have more than one monitor on their desk. I can think of a lot of examples where we may want to have more than one window for an application so that staff can take advantage of both monitors. We have already implemented a simple example in UG Paperless Admissions where staff can open a comments form in a separate window and take notes while reading an application.
Programming building blocks (literally)
Speakers: Amy Wibowo and Matt Baker
Wibowo and Baker demonstrated an application they wrote as part of the AirBnb developer happiness team to help them build a Lego mural. The application allows you to upload an image. It then converts it into a mural and gives you a shopping list and instructions for how to build it.
- To keep the code from running to slowly, reduce allocations and constrain input
- Finished implementation uses web workers to do the computations
- The final application: legoizer
Gleb Bahmutov also did an interesting optimisation of the legoizer which goes over the code structure in more detail.
My thoughts: I can’t think of a single application for this, but it is just fun. The optimisation is a really interesting read and I would suggest taking a look at that.
Use Docker to build, ship, and run any app, anywhere (slides)
Speaker: Phil Reither
This is another “demo” type talk which shows how you can use Docker for application deployment. He’s also prepared a useful Docker cheatsheet for getting started with it.
- Defines a standardised box for your app.
- Ships the entire environment.
- Similar in concept to a virtual machine, but with less overhead.
My thoughts: Since we work with SITS we have already have a fairly defined deployment process, so it’s unlikely that we will be able to use Docker. However, I still found the idea of Docker quite interesting. (My favourite part of this talk was slide 24.)
What are shaders and what can they do for me? (slides)
Speaker: Jaume Sanchez
This talk was a discussion of WebGL shaders. Sanchez gave several simple examples of graphics rendering using shaders, and then showed how they can also be used in other ways. Further information and demo code can be found on Sanchez’s blog.
- A shader is a program that tells the computer how to draw something.
- We can use shaders to make things look 3D.
- Geometry + material = a shaded object
- For further exploration with shaders, try three.js
- Shaders are optimised for processing large sets of data at high performance, so we can also use them to arbitrarily process any data set.
My thoughts: In our work we are unlikely to do any rendering, but I did find the idea of using shaders for other purposes to be pretty interesting. Sanchez showed how you can use a shader to perform expensive trig calculations across millions of numbers in only a few seconds – it was pretty impressive.
Intelligent responsive typography
Speaker: Phil Holden and Lelen Huang
In this talk, Holden and Huang described their experience designing and building a karaoke application. The goal was to create an application which could optimally display any song on any screen size.
- Challenges in displaying text on varying devices, resolutions, orientations
- View the code: song-fit
My thoughts: For us this is not as useful – I can’t think of any instances where we are going to be displaying text in this way. His final solution was to draw the text on a canvas and then do various calculations to determine the dimensions of the text and optimal layouts for displaying it. Probably not something that we will ever need to do, but also I don’t know if I would use a canvas for this purpose.
How I went to forklift driver to developer in 9 months (slides)
Speaker: Lewis Cowper
Cowper described his personal journey in becoming a developer.
- Learn by doing.
- Go slow and find your niche.
- Support (junior) developers who are trying to get into the business and learn.
My thoughts: This talk was a bit more personal so there was no immediate takeaway for me, but it did make me reflect a little on how important it is to support developers who are just trying to enter the field. Also it emphasized the fact that there is no shame in learning – we are all learning all the time.
A talk about nothing
Speaker: Lena Reinhard
This talk was the closing keynote for the Scotland JS conference. Reinhard explored the concept of “nothing” in technology culture. What does it mean to dismiss something as being “nothing”? The videos from Scotland JS aren’t up yet, but you can see a video from the concat() conference where Reinhard also delivered this talk.
- We need to understand our own privilege – the tech industry is full of it.
- We have privilege not to listen or care about things, to ignore them, to do nothing about it.
- Everyone has biases, and we need to recognise and combat these.
- Code can harm and exclude people.
- We should enable our users to be independent.
- Shipping culture leads to a stressed development team and poorer code.
- Who gets to shape the future?
My thoughts: I found this talk to be really insightful and thought-provoking. The video is definitely worth a look, it will give you a lot to think about.