Recently I attended the Scotland JS conference, which I have to say was really inspirational. A big thank you to the organisers for making this happen! The conference was an amazing mixture of the practical and thought-provoking. I came away with a lot of ideas on improving my own work.
For those who weren’t able to attend I’ll be posting my notes from the talks. You can also find out more about these from the conference website (linked above) and the Scotland JS Twitter feed.
Learning & vulnerability; teaching & empathy (slides)
Speaker: Philip Roberts
Roberts talked about how he was inspired to think about learning after watching this video about Jackie Chan. In the video, Jackie Chan talked about how anyone can be as good as he is if they practice enough. “Except, do you have the patience, or not?”
- It takes a long time to master something, and “I ain’t got time for that”
- But…is it really important to master things? You can not master a skill and still get value from it.
- Telling someone something isn’t the same thing as teaching them.
- As developers, we are constantly learning new things and teaching others. It’s important to spend time reflecting on both of these processes and thinking about how we can improve them.
My thoughts: At the university we probably spend more time learning (training) than at many other workplaces. We should also spend equal amounts of time reflecting on the learning process and how we can improve it.
TDD in the real world
Speaker: Dave Kennedy
Everyone agrees that testing is a good idea. But a lot of people struggle trying to figure out how to apply the principles of good TDD (Test Driven Development) in the workplace.
- Focus your tests on maintainability and quality, over correctness. Focussing solely on correctness makes tests that are too fragile.
- Think of is as Test Driven Design rather than Test Driven Development
- Create acceptance criteria for each change (for us these would be user stories), and base tests around these.
- Often times you are told not to test the DOM. But if your code is very DOM-driven, then that’s what you should be testing.
My thoughts: I think that many of us struggle with the problem of trying to apply TDD to our own workflow. The take-home message here was that it isn’t important to worry about making your tests “textbook perfect”. Rather, you should be fitting your tests to whatever it is you’re actually doing.
Chrome DevTools, back to front (slides)
Speaker: Katie Fenn
This talk was a quick and useful intro to some of the more useful features in Chrome DevTools. The slides have already been posted (link above), and I highly recommend browsing through them to get a more in-depth look and the below points and many others.
- Sources tab:
- Using the line “debugger;” in your code will create a breakpoint here
- From here you can see and set scope variables
- You can also set conditions for your breakpoints
- Code can be isolated for debugging using Blackboxing and Workspaces
- Easily record performance over time on the Timeline
- The CPU profile shows you what time is being spent where
For those interested in getting more into the world of debugging, Fenn recommended the podcast The Breakpoint. She also suggests this post for some helpful thoughts on testing with mobiles. (Other useful links from her can be found on the Scotland JS Twitter feed, linked above.)
My thoughts: If you are still doing old-style debugging using alert messages and posting to the console (I’m guilty as well!), it’s worth having a look at the new tools to see what they can do. I haven’t explored Chrome much since I’m used to using Firebug, but this got me interested. I’ll definitely be trying these out!
Look Ma no framework
Speaker: Colin Gemmell
The speaker shared some thoughts on his experience using frameworks, and also his experience trying not to.
- When we use frameworks, we’re developing in a certain way – the way the framework wants us to. Developers can end up with “Stockholm Syndrome” from the framework that they are accustomed to working with.
- Rather than using a framework, focus on using the right tool for the job.
- jQuery came out when browsers were non-standard, but this is no longer the case.
My thoughts: Often we can find ourselves spending time implementing silly workarounds simply because we’ve committed to using a particular framework, language, or tool. Gemmell’s talk encouraged me to think more about choosing the right tool for the job, rather than using something simply because we already have it or someone is already using it.
Adaptive and evolvable applications
Speaker: Ben Longden
Building RESTful applications is now taken as an industry standard. This talk explores the best way to build clients which interact with servers in a RESTful way.
- There are two types of APIs:
- Machine driven (the logic is built in)
- Human driven (controlled by a person)
- Affordances can be thought of as interaction “hooks”.
- Hypermedia includes the data and information on how that data should be used. This brings us to HAL (Hypermedia Affordance Language).
- This means less logic in the client, which allows the server and client to evolve independently from each other.
- JSON Schema can be used to validate this information (e.g. JSON Form)
- Link templates provide information on how a link is constructed.
My thoughts: Moving logic away from the client can lead to a faster and better-structured experience for the user. We have recently started to use JSON more for passing information around, and I am definitely interested in looking at how JSON Schema can potentially support this. A lot of what he was describing reminded me of the work demonstrated recently to us by Richard Good on MyEd.
Journey from procedural to reactive JS with stops
Speaker: Gleb Bahmutov
This talk is based on a post which you can read here. It looks at a simple problem: take an array of numbers, multiply each by a constant, and print the results. He then breaks this problem down using a number of common approaches (procedural, object-oriented, functional, etc.).
- JavaScript has a potentially larger impact than other programming languages because it’s used everywhere.
- We can compose complex applications from simple steps by splitting our code into procedures.
- Boring code does not surprise you. Make your code boring. (“Just as boring parents make boring children, boring functions make new boring functions.”)
- “Pure” functions are ones where the output only depends on the input. This is ideal.
- We can add new functionality using “bind”.
- Everything emits events, and our code should react to handle it.
If this interests you, then the following libraries are suggested:
My thoughts: I found this interesting since I come from more of an object-oriented background, and I find it hard to switch my mindset into doing functional or reactive programming. It has given me a lot of ideas in how I might approach developing something in a more reactive manner.
UX of stairs: when simple tasks aren’t simple (slides)
Speaker: Greg Tarnoff
Two years ago, Greg Tarnoff developed a vestibular disorder which has affected almost every aspect of his life. Even performing basic tasks such as walking or bending over can trigger extreme nausea and anxiety attacks. He opened the talk by describing his experience with his condition and sharing a little bit about what it’s like to be him. He then went on to look at how we approach accessible design, and what we can do to improve.
- We all have biases. We can’t understand what users experience without talking to them.
- The physical world is not accommodating for people with disabilities. In technology we can do better.
- Some rules to remember:
- Always support keyboard navigation.
- Limit the use of modals. When using them, lock the user into the modal and then return them to where they were before.
- When using form validation, show a list of errors. Allow the user to jump to errors and correct them. Never take them all the way back to the beginning of a long form.
- Always have a :focus state.
- Never use icons alone without text. This is not only for screen readers – some users may not have the cultural context to understand what the icon is showing.
- Include enough contrast for users with colour blindness (Daltonize bookmarklets).
- Use dyslexic-friendly fonts.
My thoughts: This was a really thought-provoking talk, and the rules provided were simple and straightforward. I think that we can be a bit lazy about supporting accessibility (especially in applications where the user population is “controlled”, e.g. staff-facing). I plan on being more rigorous in the future and using these rules to guide my development. I was lucky enough to chat with Greg Tarnoff after his talk – really an amazing guy!
Driving the style guide driven development
Speaker: Varya Stepanova
This talk showcased the SC5 Style Guide Generator, a tool that you can use to create a living style guide.
- The old way of development: mockup > markup > product. This leads to inconsistency, is time-consuming, and ultimately unmaintainable.
- Websites are systems. They are modular, so each component should have its own process.
- The style guide should be the focal point of design for new components.
- The SC5 tool is a true living style guide:
- Auto-refresh on change
- View variables and see affected components
- Make changes in the browser which are written back to your files
My thoughts: We have already tried using StyleDocco for some of our style documentation, but this tool looks more powerful to me. I like that it supports the mindset of a developer (view variables and Angular directives), and also of the user (just let me pick a nice colour). It seems like it would be really useful for working directly with stakeholders or as part of a mixed team to make style decisions.
The one trick to scaling your frontend codebase…
Speaker: Daniel Perez Alvarez
In this short talk, the speaker covered some of the lessons learned in dealing with scaling a large, legacy codebase across a distributed team.
- A big rewrite is often not possible, so we need incremental improvement.
- Team communication and knowledge sharing prevents developers from stepping on each other’s toes. (We use HipChat for this already, but he also suggested a few other tools for this purpose.)
- Use CSS naming conventions.
- Group code for a specific component (markup, JS, CSS, etc.) together in one folder. This makes it easy to find and remove if it is no longer being used.
- Codify your knowledge and make it executable.
My thoughts: This talk was of immediate interest to me since we certainly have the legacy codebase dilemma! We are already doing some of these things, but the other points are quite helpful. I like the idea of grouping together all the code relating to a specific thing. We currently split our files up by type (JS together, CSS together, etc.) and it makes it harder to find them when we want to phase something out.
Creating D3 components
Speaker: Chris Price
D3 is a popular way of creating charts, and yet it can be incredibly hard to use. This talk goes over one team’s journey in working with D3, and what they learned about it.
- D3 can be used for creating charts and visualisations.
- Create an abstraction of the data in JS, and then use a data join to connect the abstraction to your markup.
My thoughts: I didn’t take a large number of notes on this talk, since we do not normally need to create charts for our applications. This talk gave a lot of code examples which would be useful to anyone working with D3 (unfortunately not as applicable for me). If we start using D3 in the future I will have to revisit this!
Cascade, specificity, and a single name space
Speaker: Orde Saunders
Although the conference is primarily focused on JS, many JS developers also have to spend time working on CSS. This talk aimed to give some top tips on working with CSS and keeping your CSS clean and tidy. For further reading, see this post that the talk is based on.
- The word “cascade” in CSS means that the last declared rule wins. Keep your declarations as small as possible so they don’t conflict with each other.
- The hierarchy of specificity: inline > id > class > element
- Several approaches which can make your life easier (and your code more maintainable):
- Separate CSS classes from JS binding classes. It’s tempting to reuse them, but makes it harder if you need to change them.
My thoughts: We did a major cleanup of our CSS over a year ago, and recently I was thinking that it is time to revisit it. At the time just pulling it all together was sufficient, but as our codebase grows larger it is becoming harder to maintain. This talk gave me some ideas on how we can improve. At the moment we are not using naming conventions and I think that definitely needs to change!
A brief history of synthesis with the Web Audio API (slides)
Speaker: Chris Lowis
Chris Lowis has been working with the W3C to develop the Web Audio API, and this talk shows some of the tools that you can use to synthesize sound in the browser. Lowis gave a short history of sound synthesis, using the API to demonstrate each of the techniques.
- When we synthesize sound, we build it up from building blocks.
- Computers are the universal instrument.
Some fun things built using the API:
- Code demos – some demos used in this talk
- Virtual guitar amp – built at the Scotland JS Web Audio Hack Day
- RGB theremin – based on the in-browser theremin shown in this talk, someone else made one that plays RGB colours
My thoughts: Again, this was a talk that was not as applicable for me. I can’t think of any applications for the Web Audio API in what our team develops! On the other hand, I found it quite inspirational to see what could be done with it and how far sound synthesis has come over time. Something which used to take enormous, expensive, specialised machines can now be done in your browser! Also, frankly, it’s fun.