Recently we had the opportunity to attend NationJS, a Mid-Atlantic JavaScript conference held in Silver Springs, Maryland which had 300 attendees and thirteen speakers. A wide variety of interesting JavaScript topics were discussed, ranging from testing, writing documentation, interfacing with hardware, and much more.
Click on a link below to be taken directly to that section of the article.
- Becoming A Happy Javascripter by Julia Allyce
- 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
- JavaScript Rehab for Grunters and Gulpers by Erik Isaksen
- React is “Functional” by John K Paul
Becoming A Happy Javascripter by Julia Allyce
Julia Allyce, a java developer and consultant for Open Source Software, started the conference off. She began her talk by expressing to everyone that “Happiness != Expertise”. She said this is something that you need to keep in mind when attempting to make that leap from just starting out to being a proficient front-end JavaScript master. She went on to say that happiness is not constant; It is something that, as a developer, you need to be aware of your level of happiness and find things that increase it greatly. According to Julia there are three steps to making this easier on you: Confidence, productivity and security. She called these the “tools to learning” and are what you need to succeed in your career.
Taking the initiative to leave when you don’t have the tool or knowledge to complete a task should be at the top of your go-to list. Julia said that feeling stupid is just part of the everyday life of a developer; it shouldn’t stop you from continuing on your path and succeeding in what you set your mind to. Pushing yourself to “shamelessly ask questions” will only get you that much further as a JavaScript developer.
One key take-away was the idea that learning the JavaScript, not the framework, is where your developer mind needs to go. Frameworks require a strong foundation. Learning a framework will get you a good way, but learning the basics of what the framework uses will get you ever further. The frameworks are not always going to exist; Even right now, they are changing, but the JavaScript behind it will be used all the same.
Julia mentioned some tools to learn and use in order to better foster the growth and development of new developers looking into JavaScript: Backbone.js (even though it may seem like an outdated library because of the little “magic” being used, it has excellent concepts behind the single-page application [spa]) and Express/Mongoose/MongoDB (specifically for the rest API’s).
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.
A good read to look into: Eloquent Javascripts by Majijn Haverbeke
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 MacWright presented a library called JSDoc, which is very similar to Javadocs and has similar notation which allows one to document their JavaScript. Often people argue that document generators are unnecessary because we strive to write self documenting code, or that it is overly verbose to describe all the required properties.
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.
JSDoc is a cool library for generating documentation for your JavaScript code in multiple forms (it can generate HTML, and Markdown for you), and worth checking out.
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.
After hearing of the oh-so-fun technology you can build with just a tiny device and some JavaScript Stacey went through some good libraries to look into: SpaceBrew (makes connecting interactive things to one another over a local network; built for prototyping development), cylon.js (allows interaction with sensors easily), johnny-five.js (robotics JavaScript framework), and device.js (operating system based, allows for easy manipulation based on the device being used).
Follow @bitchwhocodes if any of the above sounds intriguing.
Writing Command Line Applications in Node.js by Josh Finnie
Following a short break, Josh Finnie got on the stage to talk about Node.js. Josh is a full-stack engineer at TrackMaven and runs NodeDC’s Node Nights, checkout their meetup events here.
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.
ECMA Script 6 (ES6, the first update to the language since 2009) was then mentioned, primarily to reference some of the fantastic new features implemented in this release, such as: arrows and let + const. Using ES6’s newest features allows great things with many of the main JavaScript libraries used in web applications. Node.js, Babel.js and Gulp are all taking strides to stay as up-to-date as possible and allow for easy use of these features.
Watch for updates on ES6 implementation for Node.js and Babel.js.
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
Lizz Sommerfield works at the Washington Post as a technical architect. She spends most of her time investigating better ways to build dynamic interfaces using HTML, CSS and JavaScript.
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)
Nicolas Bevacqua is a JavaScript and web performance consultant and author of JavaScript Application Design from Buenos Aires, Argentina. Speed is very important in web development, Amazon recently found that a 100 ms increase in latency led to a 20% drop in traffic. In this talk Nicolas outlines many methods to increase performance, and also suggests tools to monitor performance.
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.
Other performance increasing methods exist besides the obvious minification of code. Gziping text, reducing the number of requests and turning on Keep-alive are some things to look into. Next we can look into optimizing HTML, CSS, Images, fonts, and JavaScript. Inline critical CSS where necessary, compressing image sizes, and using a font loaders are great to start this process.
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.
JavaScript Rehab for Grunters and Gulpers by Erik Isaksen (Talk Resources)
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.
