DAY 1 / DAY 2
"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."
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."
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.
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.
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.
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.
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)
- Explosions/fireworks (using canvas)
- ""Metaballs"" (using SVG, maybe React)
- Infinite scroll (using DOM, maybe React)
Come for the explosions, stay for the infinite scroll!
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.
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.
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
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
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.
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.
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.
"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 (https://medium.com/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**."
The Serverless Revolution