Schedule – 2017


DAY 1 / DAY 2

Registration 08:30 am
08:30 - 09:20 Breakfast and Registration
09:20 - 09:30 Opening Remarks
Ernie Turner
09:30 - 10:10 Ernie Turner Dodging Web Crypto API Landmines

"This talk will teach attendees how to use the Web Crypto API within a production application. The talk will focus on the practical implementation of cryptography and not on cryptography generalities. I won't be covering the breadth of the Web Crypto API, as it contains much more functionality than most developers need.

I'll start out with a very brief intro to some basic cryptography concepts (random number generators, symmetric keys, IVs/nonces), but only enough to be able to use the terminology throughout the talk. I don't expect any of the attendees to have much/any prior knowledge of cryptography, but they also won't come out of the talk as cryptography experts either.

In my example, I'll show how to take a single piece of data and encrypt it using AES with a key derived from a user provided password. As all of the Web Crypto API operations use Promises, I'll show how to chain them together to make a nice encryption and decryption workflow. In addition, because of the slower performance of these operations, I'll show how to use WebWorkers to do the cryptography processing in a separate thread and how to pass data between these threads quickly and securely.

During each of these sections, I'll also cover browser support for each operation and what is/isn't available in major browsers. In situations where support is not fully available, I'll show which 3rd party libraries can be used as polyfills.

In the end, I hope to show attendees that cryptography isn't as scary a concept as they might think. As long as they follow a few rules when encrypting data, it can be a very useful tool to understand."

Brian Gantick and Austin Starin
10:25 - 12:00 Brian Gantick + Austin Starin A Vue (app) from the top - Introduction to Vue.js Workshop

"Since its initial release in February of 2014, Vue.js has rapidly become one of the top open-source progressive JavaScript frameworks. Approaching 63k stars on GitHub, Vue is one of the most popular open source projects ever and the second most popular JavaScript library after React, surpassing popular libraries and frameworks such as Angular, Backbone, Polymer, Ember, and even jQuery.

Vue's popularity is due in large part to the ability to incrementally adopt the framework into existing projects and approachability for developers new to working with front-end frameworks. Since it is mostly an interface layer, Vue tends to be less opinionated than other frameworks, which makes it easier to learn and suitable as a drop-in library that can be used in existing projects to add interactivity or provide a declarative, HTML based template syntax. Beyond the drop-in use case, Vue can also be scaled up to be used as a full-blown application framework.

In this workshop, we'll go over the basics of getting started with Vue, from getting your development environment setup using Vue CLI to deploying a completed application and debugging it using Vue dev tools. We'll run through how Vue can quickly and simply solve common front-end problem sets including how to create reactive and easily maintained UI through reusable components, as well as how to use more advanced features like mixins, filters, and custom directives. You'll also learn the basics of setting up Vue Router and how Vuex can help you manage state in larger applications, all while building a custom image gallery application."

Sam Jones
10:25 - 11:05 Sam Jones JavaScript Is Too Convenient

Conveniences we love in JavaScript are discouraging us from writing concise, descriptive code. In-line objects and anonymous functions deprive us of descriptive domain names for the actions we are performing and the objects we use to perform them. They add noise that distracts from the purpose of a function.

This is especially true in tests, which should help us feel the code we write. These conveniences encourage us to create functions that do too much and require complex test setup.

"JavaScript is Too Convenient" will encourage you to write more focused code with good names. We can make our code nicer for new team members, and our future selves by examining the purpose of our code, amplifying the signal, and reducing the noise."

Connor Skiro
11:20 - 12:00 Connor Skiro Lean Coffee Session


Matt Morgis
01:30 - 03:05 Matt Morgis + Tamera Lanham Pair Programming with TDD and Jest Workshop

Customers value two things about software: how well it works, and the ease with which it can be changed. If you compromise either of those two values, the software will diminish in real value to the customer.

If you have been a programmer for more than two or three years, you have probably been significantly slowed down by -someone else's- messy code. Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules?

We've all been there.

The degree of slowdown from messy code can be significant. Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail's pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. **Every addition or modification to the system requires that the tangles, twists, and knots be understood so that more tangles, twists, and knots can be understood.

So why does this happen to code? Why does good code rot so quickly into bad code? We always have lots of explanations for it, but perhaps the best: **The software should be easy to change,** but it often isn't.

We complain the requirements changed in ways that thwart the original design. The truth is the business should not find it expensive add a new or change requirements. The business shouldn't be slowed down by wanting to change or adapt the system.

What has worked at our small agency and at large international enterprise companies is practicing pair programming and TDD. Implementing these have lead to flexible software, shared team values and attitude towards the codebase, and most importantly happy customers. TDD is often thought of as an _individual_ practice. Yet, more software is built by teams. Teams that don't enjoy a shared set of values become unstable over time. Pair programming is a dialog between two people that can help break down these barriers and help teams conform on a shared set of values.

When you first learn TDD, it sounds simple and easy. However, if you're like us, you may have had a typical TDD novice experience which lead to giving it up within the first couple weeks. We will demonstrate symptoms of test-design problems, and how to identify and overcome them.

We will address some of the challenges we faced when implementing these practices. For example, that pairing doesn't mean you that can't think alone. If you need to work on an idea alone, go do it. When you're done exploring, bring the resulting _idea_, not the code, back to the team. With a partner, you'll reimplement it quickly. The results will be more widely understood, benefitting the project as a whole.

Another challenge we will address out of the gate is how to start using TDD on a legacy code base that was not originally written with tests a frequent question that arises after basic intro TDD exercises. Using the workshop format, we will demonstrate adding a feature to an existing web app not currently under test. The two of us will pair program on the full-stack feature and use TDD as we go. We'll also be using the latest and greatest Javascript frameworks and tools: including React and Redux on the front end, Node.js and Express to build an API end point, and Jest as our test runner.

After the brief demonstration, the audience will be given a TDD exercise to complete on their own or with a pair (encouraged) where tests are provided and one-by-one the pairs will work to make them all pass. Attendees will know TDD by the end of the session.

William Lyon
01:30 - 02:10 William Lyon Full Stack Graph Application Development Using the GRAND Stack: GraphQL, React, Apollo, and Neo4j Database

"Full-stack developers need to choose the right tools for building complex web applications. The stack of tools they choose needs to ensure developer productivity for building highly scalable applications using production ready tools that have integrations to ensure they work together nicely. In this presentation, we explore application development using the GRAND stack (GraphQL, React, Apollo, Neo4j) for building web applications backed by a graph database.

We will explore building a movie recommendations web application using:

* GraphQL - a query language for APIs that has been called ‰ÛÏREST 2.0‰Û as it offers many advantages over REST, also developed at Facebook

* React - a leading frontend JavaScript framework developed for use at Facebook

* Apollo - the most popular GraphQL client that glues together React components and GraphQL

* Neo4j - the open source graph database that allows for modeling, storing, and querying data in real time, using the property graph data model and the Cypher query language

We will learn just enough of each component to build a simple web application, including how to build a React component, an introduction to JSX, an overview of GraphQL and why it is a game-changer for front-end development, and we'll learn how to model, store, and query data in the Neo4j graph database using GraphQL to power our web application.

After this talk you‰Ûªll have an understanding of the role each component plays in the stack, but especially why GraphQL is even more powerful when combined with a graph database such as Neo4j. Using graphs on the backend as well as the frontend allows for removing the mapping and translation layer, simplifying development and allows the developer to leverage the power of graphs for expressing complex data models as well as the power of graph database queries that can be used for (in this example) generating real-time personalized recommendations.

No experience with GraphQL or graph databases is necessary to benefit from this talk, but some familiarity with JavaScript will be helpful."

Matt Hayes
02:25 - 03:05 Matt Hayes Particle Systems for Fun and Profit

Particle Systems for Fun and Profit

Particle systems are most commonly used in games and physical simulations, but needn't be complex in order to reap many of their benefits. Using just a handful of patterns borrowed mostly from game programming, we can build a particle system that is easy to reason about and that has excellent performance characteristics. This combination of reason-about-ability and performance will enable rapid iteration over a number of possible uses and implementations of such a system.

This talk will be broken up into 4 sections:

1. Overview of the patterns we'll be using: command, game loop, component, and object pool. (10 minutes)

2. Simple app scaffolding using Webpack 3 and Babel 6 (maybe 7). (5 minutes)

3. The patterns applied/building up the particle system. (10 minutes)

4. Implementations, ""live"" coding, demos and Q&A. (15 minutes)

Some possible demos may include (but are not limited to):

- Explosions/fireworks (using canvas)

- ""Metaballs"" (using SVG, maybe React)

- Infinite scroll (using DOM, maybe React)

Come for the explosions, stay for the infinite scroll!

Martin Snyder
03:20 - 4:55 Martin Snyder Functional Programming in JavaScript Workshop

Applied functional programming can be a challenge for many developers. Sure, you might have learned some of that in school, but little of that translates into building real-world applications. Doing exercises and numeric computations is nice and all, but at some point the rubber has to meet the world, and you have to deal with the complexity of managing state mutations in an otherwise immutable world.

This workshop explores just that boundary, and discusses how to decide what changes where and how to represent things.

There are up to 5 hours of material that can be explored in this workshop, but we only have two. We'll meander through this world and switch back and forth between composing answers ourselves (bring your laptop) and looking at parts of the already-written answer so that we can skip ahead as the groupthink decides.

John + Chris
03:20 - 04:00 John Riviello + Chris Lorenzo Web Components: The Future of Web Development is Here

With the updates to iOS and Android phones released earlier this year, Web Components are now supported natively. With libraries such as Polymer that are built on top of Web Components, it is now possible to easily create fast Progressive Web Apps (PWAs) without the overhead of a framework. In this workshop, we'll begin with a brief introduction to Web Components and Polymer, and then dive into hands-on experiences with the core aspects of Web Components: the "template" tag, Custom Elements, and the Shadow DOM.

This talk assumes an understanding of HTML, CSS & JavaScript. No prior experience with Web Components, Polymer, or any library or framework (Web Components or otherwise) is required.

Emily Freeman
04:15 - 4:55 Emily Freeman The Dr. Seuss Guide to Code Craftsmanship

The Dr. Seuss Guide to Code Craftsmanship

I have a two-year-old daughter who adores Dr. Seuss. And as I was reading Cat in the Hat for the 214th time, I realized Dr. Seuss had it all figured out.

His words are odd. The cadence confusing. But there's a gem hidden in all his children's rhymes.

You see, Dr. Seuss would have made an excellent engineer.

Because great code isn't about choosing the perfect method name or building out 95% test coverage. All that is great, but it doesn't make great code.


It likely never feels that way. There's a rhythm to software development that goes something like this:

1. "Easy. I've got this."

2. "Uhhh, maybe not."

3. "HALP! I have no idea what I'm doing."

4. "How did I not think of that before?!"

5. "I AM A GOD."

This process is okay if you're comfortable having a mild psychotic break every sprint. I'm not.

We're going about it all wrong. Putting ourselves ‰ÛÓ our egos ‰ÛÓ above our code. No judgement. I do it too. We're human. It's okay.

But I think we can bypass our egos and the emotional ups and downs it produces. This talk will focus on common pitfalls along the development lifecycle and distill Dr. Seuss's excellent advice into concise steps developers can take before they write a single line of code.

In the words of Dr. Seuss: You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. You're on your own. And you know what you know. And YOU are the guy who'll decide where to go."


DAY 1 / DAY 2

Len Smith
09:30 - 10:10 Len Smith An Introduction to Functional Programming in JavaScript

Functional programming confers many benefits that can help us write clean code. And much of the power of functional programming is available to us in vanilla JavaScript.

In this session, we'll explore what functional programming concepts are and how they help us clean up our JavaScript code, as well as looking at FP libraries like Ramda.js.

Eric Lewis
10:25 - 12:00 Eric Lewis Intro to React Workshop

We'll work through exercises to learn about:

- The JSX syntax for building React component trees

- Building React components

- Using component props and state to hold data

- DOM event handling in React

- Using Create React App as a good base configuration

Kathryn Stracquatanio + Sarah Polansky
10:25 - 11:05 Kathryn Stracquatanio + Sarah Polansky Please Touch: Creating Applications for Museums

Touchscreen interactives are not usually in the vocabulary of a web developer. These applications are typically saved for those with software or computer engineering degrees. But recently, javascript has been helping to produce fast and slick interfaces that can be used anywhere

At Bluecadet, we have explored the opportunities of using javascript from traditional websites to multi-screen and multi-touch applications found in museums around the country. This talk will cover our journey with javascript and delve into the tools that helped along the way.

Michael Schoonmaker
11:20 - 12:00 Michael Schoonmaker JavaScriptural Exegesis

If we insist on being religious with our JavaScript, perhaps it's time to use religious tools to improve it enter _exegesis_.

Do you know where "arrow functions" came from, before they were introduced in ES2015? How about let/const? Or async/await? Better still, what was the "cultural context" of these language features originally, and of their specifications now? Why did the authors of these languages introduce the feature in the first place, and to what audience? These questions and more are wrapped up in this process of textual criticism (or ""hermeneutics"", for my philosophy nerds out there), and they provide a framework for understanding The New JavaScript䋢 better, making us better as programmers along the way.

This talk is about the process of exegesis, applied to some exciting new and forthcoming features of JavaScript, and the nuance we can glean from those storied origins.

Brian Douglas
01:30 - 03:05 Brian Douglas Zero to Webpack Workshop

Before module bundlers, JavaScript and CSS were inserted onto the page via the index.html. Now bundlers like webpack can modularize your assets into these chunks to improves speed and decrease the size of your application.

I will first talk through the history of how we got from adding script tags to now using bundle tools, like webpack to dynamically replace those script tags. I then talk through the basic concepts of webpack and how the use of loaders and plugins get bundles into your output and place into the index.html. This will be summarized showing the steps to get Webpack up and running from the ground up for a React application.

Finally, I will walk through examples of using different plugins to manage your build size. I will weigh the benefits as well as the limitations for each plugin. This will all be analyzed showing comparisons from the webpack-bundle-size-analyzer tool.

At the end of this talk, the listener will have a better understanding of why they are using webpack and how to be confident enough to update their configuration to better suit the needs of their app.

Hao Lou
01:30 - 02:10 Hao Luo Understanding Async Await in Javascript

Javascript traditionally relied on callback functions to handle asynchronous operations. As your Javascript application grows, you would encounter "Callback Hell", which makes your code unreadable and application error-prone. There are now several ways to combat callback hell, and make your application development experience more enjoyable.

The presentation will quickly go over the shortcomings of callback functions. It will also provide a thorough walk-through of Promises, and Generators, and combine the two paradigms to explain the new ES2016 feature async/await.

Nate Abele
02:25 - 03:05 Nate Abele Un-dux Your Front-end

Redux is the community standard for state- and transaction-management in React applications, but it leaves a lot to be desired when it comes to implementation guidance. As a result, you're left to cobble together a set of redux-* packages for each new app you write. What's more, there's little consensus on how to manage complicated, multi-step async transactions — redux-saga is the closest thing to a standard, but it is needlessly abstract and boilerplate-heavy.

Taking inspiration from the Elm language & architecture, I've created an Open Source framework that provides a succinct, elegant API for managing state and side-effects. Its integrated tooling allows developers to iterate with unprecedented speed, and combines hot reloading with time-travel debugging to maintain state across the save/reload cycle, replay requests, snapshot for future replays, and even live-mirror across machines for collaborative development & debugging.

I've been writing JavaScript for over 20 years, and I consider this the pinnacle of my work. I fully anticipate that this will replace Redux as the standard for building React (or equivalent virtual DOM library)-based applications.

Tierney Cyren
03:20 - 04:00 Tierney Cyren Building the Foundations of the Node.js Community

"Node.js is an amazing project in terms of code - it's evolved rapidly to cover an immense landscape, from web apps, desktop apps, APIs, IoT, robotics, and beyond. There's something else that Node has also been absolutely killer with, though: the community.

When the _community_ split off of the core Node project into io.js, things changed **dramatically**. Suddenly, the community was in charge - of everything. The project wasn't under the control of a small few, but rather it adapted to enable the project to be entirely controlled by the community.

Great - Node.js is governed by its community. But how does the Node community grow? How should it communicate? How can it encourage people to stop by and give Node.js a try - and hopefully not get thrown into a catch()?

One really awesome thing is that the Node.js community has an established community for building the Node community. How meta is that? The Node.js project is sectioned off into different Working Groups (WGs) with that are tasked with different objectives - the one that was tasked with building the community was the Evangelism WG.

Now, we're seeing step two in process of building the Community for the Community: The Node.js Community Committee.

There have been several new developments, such as...

* Scaffolding out processes for the community to become technical editors to The Node.js Collection (

* Moving community education efforts like nodejs/education and NodeTogether into a central place

* Developing the documentation around the Community Committee to enable the Community to develop and grow naturally

These are the buds of momentum that is building for new community-based content that we're seeing a need for as Node.js is growing, spreading, and diversifying.

All that said, there's a transition happening. The Evangelism WG planted the seed of the grassroots Node.js Community efforts. Now, the Community Committee has taken this a step further and is mobilizing to start exploding the awareness and understanding of Node and its diverse ecosystem.

To succeed with this effort around enabling the Node.js community, we're going to need help.

We're going to need help.

We're going to need ideas.

We're going to need feedback.

We're going to need people.

We're going to _need_ the community.

We need **you**."

Pam Selle
04:15 - 4:55 (KEYNOTE SPEAKER) Pam Selle The Serverless Revolution

The Serverless Revolution

05:00 - 07:00 Afterparty at JJ Bootleggers