Click on a link below to be taken directly to that section of the article.
- How to Stop Hating your Test Suite by Justin Searls
- documentation.js by Tom MacWright
- Hardware for the Softworld by Stacey Mulcahy
- Writing Command Line Applications in Node.js by Josh Finnie
- Building a musical instrument with the Web Audio API by Steve Kinney
- Analytics and Tracking Tools on Single Page Apps with AngularJS by Lizz Somerfield
- High Performance in the Critical Rendering Path by Nicolas Bevacqua
Next Julia went over some skills to keep in mind when interviewing as well as when giving the interviews. She said that even though you may want to put anything and everything you have ever come across on your resume, honesty on your real skill set is better. Putting down what you really know and can express well in an interview is best for getting the job. Julia said that considering the culture and people in the company before deciding on a place to work should be just as important as the interview itself.
As for giving interviews, as a company, Julia mentioned that the strategy of “whiteboarding” questions has changed. Many companies are now asking developers to complete a project instead of writing functions out on a whiteboard. Take a look at the concept here. Following this type of interview process will better allow you to see whether the candidate can follow requirements and whether they are able to actually ask questions when they run into problems on a project. Another strong point Julia made was to always explain the correct answer at the end of an interview. Even if they do not get the job at your company it is best that you teach them and that they learn.
The last thing Julia touched on was what to do when you actually get the job: help out the new guy, make sure they are learning to the best of their ability. Become a mentor by going to Meetups and schools; try to pass on your knowledge to those that are wanting to learn.
How to Stop Hating your Test Suite by Justin Searls
Following Julia Allyce was Justin Searls. He actually sat at our table prior to the conference’s start and made a comment about taking notes during the talks today. His comment was more directed at his talk and the fact that he had 365 slides to get through in the 45 minutes he had. He warned us that we would not be able to take notes, but that he would enjoy seeing us try. This warning did not quite prepare me for the extremely speedy, but greatly educational talk Justin gave.
Justin co-founded Test Double, a software company that helps build better software for businesses, developers and customers. Justin is a speaker at conferences all over the world, and he was definitely great to hear from.
Justin’s focus was on consistency. He spoke about the lengthy tests developers use on their applications and the wasteful time they take. He said that deciding on testing conventions saves time and headaches and should absolutely be conceived of early on. His talk introduced a testing guide for how to setup your rules and templates and prepare better test cases for the ease of your application development.
One of the first slides Justin showed expressed that most developers are stuck in a bad way, with the thought that when tests are not working, that we need to test harder. This does NOT work. He said that when the tests are not working as they should be there is a problem elsewhere and focusing on testing harder is a bad solution. One thought would be to stay away from creating large objects. These objects will require many, more difficult test cases.
Justin mentioned the rule of product here to put things in perspective on the writing test cases: The number of products (in this case objects) times each other equals the total amount (in this case, test cases). Limiting new, large objects and instead making lots of little objects would be better. He said to minimize each phase to just one line.
Next he dove into his version of the testing pattern Arrange-Act-Assert which he called Given-When-Then; these patterns help format code for unit testing. He started by saying that when you come across the problem of having too many steps or just too much happening to do the obvious, and slim it down. Justin continued to give tips on how to keep consistency by saying to give the subject the name of what is being tested. Make the test cases readable to those that are NOT YOU. This will keep the meaning and usefulness of the test from being buried.
“Keep test data minimal and meaningful”. I enjoyed this slide. Justin wrote it out perfectly. Keeping your test data clean, meaningful and as minimal as possible makes for better testing. Everything is much quicker and understandable, and if – heaven forbid – you run into issues, your test cases will be easy to follow to find the problem. Working on message failure workflow will keep any issues from arising here, because even if your test are extremely fast – if you have terrible failure messages you will spend all of your time trying to figure out what is failing and why, and intelligible failure messages resolve that.
One issue we all run into is scope. No matter what a developer does, the customer will always want to push it a little further. They want just a tiny bit more, no big deal. In testing this causes an issue. Before testing/development starts define your boundaries. Know what browsers you will be using, know how much money you have to work with the develop everything, know the load time of the application. Talking about these issues in advance will solve the boundaries issue down the road. Everyone needs to be on the same page!
One of the last topics Justin covered, still not out of breath mind you, was the difference between a true negative and a false negative and the need to know the difference and keep track of when they happen. A true negative is when the test fails because you have broken code somewhere, and causes a developer to come and fix the code. A false negative is when the test fails because the test was written poorly or just plain wrong, and does not tell you if the code is broken or not which results in someone having to rewrite the test case and test again. Obviously it is best if the test case fails for code-breaking reasons. Keeping track of when a true negative happens versus a false negative will allow you to know if test cases are frequently being created incorrectly. This will help to sort through good and bad testers/developers.
documentation.js by Tom MacWright
Tom introduces us to the idea of an Abstract Syntax Tree (AST) to reduce the verbosity of the documentation tags. With an AST we can infer a lot about what we are trying to document, such as recognizing a function and the name of the function.
The purpose of JSDoc is to bring back the use of documentation generators as opposed to handling this manually in a markdown file. This library becomes more useful thanks to the ES6 module system, while our code is modular, the documentation should not be. With JSDoc all the documentation will be in one place, even if the code is not.
Hardware for the Softworld by Stacey Mulcahy
Next was Stacey Mulcahy. She was very bright and easily held everyone’s attention with her great videos and big personality. Stacey is a web developer at Microsoft. She has spoken internationally and is a technical editor.
Stacey started her talk by mentioning all the devices that as developers, we should all want to use. She said that she prefers working with her hands over coding, but loves mixing the two together to make fun, not always practical, things. Her list of Open Source, microcontroller devices included: Arduino, Raspberry Pi, Tessel, Intel Edison, Particle Photon (only $20, wifi-enabled, leverages Node, has an SDK), Teensy (very small), and NetDuino (used .Net).
Next Stacey shared with the conference some very neat inventions using some of the devices she mentioned previously. My favorite was the “Booty Bump”. Her description of the dilemma she faced really hit home. Have you ever written some amazing code, and it really works and everything is awesome, and absolutely no one around you cares. So you go from feeling like you want to fly to wanting to punch someone in the face? Yeah, it happens. Stacey came up with a very interesting solution. She created Booty Bump. The idea was that you could go up and booty bump this Booty Bump (booty shape on the wall of the office) and a light show would happen for several seconds. You can dance around and celebrate your success, then go back to work. This project used Raspberry Pi, two sensors, and some lights. It was perfection (and super annoying, so it did not last long in the office). Another she mentioned was SkrillTrex.
Follow @bitchwhocodes if any of the above sounds intriguing.
Writing Command Line Applications in Node.js by Josh Finnie
Josh walked us through the steps in writing a Node.js application in command line. He went through everything from how to get yourself setup and being, some fallbacks he has seen in the time he has spent creating these Node.js applications through command line, as well as some tips to create the best practices and make for a better application in the end.
Node package manager (NPM) is used in a lot of application. Npm has over 200,00 packages included and is very form-fitting to most applications out there. Josh started with the tip to try for a better argument handler that .argv (the default). Come of his suggestions were: commander.js, yarge.js, minimist.sj, or nopt.js. This tip comes from keeping developers from needing to hunt through the array of process for what the user input using .argv. There are better ways to handle arguments.
Building a musical instrument with the Web Audio API by Steve Kinney (Talk Resources)
Following Josh Finnie, we have Steve Kinney who will be talking about the Web Audio API (a synthesizer that was added to most browsers). Steve Kinney is the Co-Director of Academics at Turing School. This talk speaks of how to interact with the web audio api at multiple levels and in multiple applications (which use different techniques).
First the basic api is discussed to make sample sounds at varying frequencies, then we begin adding on complexity. In the simpler stages, we simply use web audio context to create a source oscillator, which allows us to start creating sounds when hooked up to a destination (like your speakers). To add more complexity, we can add nodes between the oscillator and the destination, and in doing so make more complicated sounds. The example given uses a gain node to adjust the volume of the oscillator at a specific frequency and wave type.
Afterward, we built something a bit more complex using an interesting helper library, Octavian. With this library we can forget about what frequency a given musical note is, and instead reference it by name; now we can simulate more interesting instruments (or even create our own instruments). To do this, we simply bind some event to create and start an oscillator at a given note (which is easy thanks to Octavian).
The piano example used simple key press events, but this is not required, as the next example shows. Using a face tracking library we can emit sounds based on facial position as recognized by the camera.
Analytics and Tracking Tools on Single Page Apps with AngularJS by Lizz Somerfield
Single-page development has become more and more popular over that last few years, which has caused problems in the analytics world where everything is based on a page load of the URL changing. Now that we have all moved on, so has web analytics! Lizz’s talk goes through these advances. She covers what you should look into now as well as what you should look out for in the future for web analytics.
She mentions a few options when it comes to getting analytics back, such as: Tealium, Adobe Tag Manager and Google Tag Manager (GTM). Since GTM is the most popular right now, this is the one she ran through an example of. She explained the different steps to create an account in GTM as well as how to create tags and triggers for your site.
If you go to https://github.com/angulartics you will see a fantastic overview of step-by-step how to setup an angularJS application and create the GTM tags to go with it. This is a great way to start things out and see all of the options you have before applying anything to your actual site.
Here is another great tutorial with much more in-depth steps on GTM.
High Performance in the Critical Rendering Path by Nicolas Bevacqua (Talk Resources)
The chrome dev tools are the first spot to find what is affecting performance in your app. Using the audit tab we can receive hints as to where we are performing poorly. More useful tools are found at PageSpeed Insights and WebPagetest. The former will provide you with a score from one to one hundred and give you advice on how to improve performance, and the latter will give a grade for varying topics.
These tools are great for testing speed and finding problems, but an automated approach would be more useful. This way we can measure the performance from the beginning and see what performance impact a change has. To do this we use a node module called PageSpeed Index and create a gulp or grunt task to do this for us. Many other node modules exist, and some can be found in the slides, but the message should be clear — test for performance and strive for fast load times. Grunt Performance Budget can even be used to ensure that every commit stays within some required, pre determined performance constraints.
Performance is important and should be monitored consistently from the beginning. Set a budget and enforce it to keep the app from growing, and becoming bloated, and make sure you optimize your content. These will lead to a better experience for your users, and should be a major priority.
Erik Isaksen is a web developer with Deloitte Digital and speaks about the growing complexity of web development. Lots of new tools are appearing, and managing everything can become overwhelming in a world where the UI/UX expectations continually grow.
Grunt and Gulp are two tools used to automate tasks that are no longer possible to do manually, but abusing these with overly complex tasks can lead to more time automating the task than it would have taken to do it manually. The takeaway of this is that a task should be small and meaningful.
Sticking with the concept of increasing productivity, web developers should look into using yeoman app generators, such as an angular app generator, a default one exists (but I encourage readers to look into JHipster if they haven’t already).
React is “Functional” by John K Paul (Talk Resources)
“In 2016, freaking out about virtual DOM in react will be like freaking out about gzip in HTML” – John K Paul
Our final speaker of the day provided the above quote as well as plenty of excellent hand drawn diagrams. He is a VP of Engineering who can be found on twitter as @Johnkpaul, and also has his own node package which can be installed with the following command ‘npm install johnkpaul’
In this talk we discuss aspects of React and what it means to be functional. The Virtual DOM is something of a buzzword when speaking of React, but it is simply a tree. This allows us to quickly tell the difference between two Virtual DOM elements.
To understand how React is functional, it is important to understand what it means to be functional. Refreshing basic math skills, we in turn must learn what a function is. The basic idea is that an input to a function should produce one and only one output. It follows that a functional language is one where this holds.
In the past, many strategies were used to handle communications between the server and the web page view when the user interacted with it. As it turns out, the server side is predictable, and only takes a single step, but this was not always true with the front end. Many times we have a multistep front end process where we make our original HTML, then update data as the user interacts with the page, and finally we try to keep the view and the data in sync. In this way, we are trying to keep the front end predictable (but trying isn’t good for a function). With react, we simply make the view and we know exactly what will happen — we have a predictable front end.
When the virtual DOM changes, we can very quickly compare it to the previous virtual DOM, and we see a performance increase due to this speed.