List of videos

Side projects can be daunting if you're new to them. It takes discipline to get started, and even more so to finish. And what's even more daunting is that finishing is only the beginning of maintenance. In this talk, I'll relate my adventures coming up with dance-mat.js, the project for making a Dance Dance Revolution controller with Raspberry Pi, the Bare Conductive PiCap, and Node.js.

Let's have some fun with TensorFlow and React. Not familiar with TensorFlow? No problem, you will get a fast crash course and learn how to track faces and add silly adornments (I bet you would look good with a new set of reading frames) entirely in the browser with TensorFlow and React. With a good background in the tech let's expand to tracking multiple limbs and evaluating and scoring some yoga positions. We will look at a couple different scoring algorithms, and finally challenge the audience to beat our high score for ultimate bragging rights.

As technologists, one of the hardest things to remember is that we’re not our users and our assumptions can easily extend into our work. If we aren’t careful, we can easily end up designing products based on our assumptions and biases rather than insights from the actual audience. If we want to build better products, we need to include our target audience in the creation process and listen to their feedback every step of the way. In this talk, I’ll share what my team and I learned from two different projects where we worked directly with our audiences - busy moms who were raising a child with autism and Gen-Zs experiencing various forms of bullying. You’ll learn what types of biases to watch out for, how to challenge your own assumptions, how to engage hard-to-reach audiences, and how the user-driven insights we gained uncovered the struggles unique to their community and informed our design decisions and product iterations. Whether or not you work in UX design, this talk will help you create tech solutions that are physically, cognitively and emotionally accessible and ultimately valuable for all humans.

What would it mean if there were an AI musician? An artist that wrote its own drums, keyboards, and complete songs. An artist that generated album art and live visuals. People writing JavaScript are some of the most interesting artists today, and using the latest TensorFlow APIs (and projects like Magenta), we're able to generate sounds and instruments using only JavaScript. It's a bit ridiculous for a "musician" to be generated using purely JavaScript... but that's exactly why we should do it. In this talk, we'll look at the innards of a couple of digital instruments that use Neural Nets and Machine Learning models to generate music. We'll also compile a complete song, rock out together, and have some fun. This talk is lighthearted, but will also pose some big questions: What would it mean if you knew the music you listened to was made by a computer? Would you like it more? Or less? By the end of it, you'll be able to take these instruments and build your own songs—or your own musicians.

Building Open Source Communities is hard. There’s a lot of people that do it, but we repeat the hard lessons again and again. In this talk, we'll go over overlapping lessons from four distinct OSS communities to help the next generation of builders… build.

Creating a JavaScript application (built with React) for orphans in Ghana offered some unique challenges. Progressive Web Apps (PWAs) are more than just "cool" or "hip" — they can be really important for applications where the internet is spotty, if available at all. Learn why I chose React + AWS Lambda for a country with poor internet connectivity, and general lessons on the often messy and exciting world of creating offline applications.

Introduction to graph federation with Apollo Federation. With a simple example, we will show you how to split your GraphQL Schema into smaller "micro-services" and how to link them back together again.

Wait... CSS algorithms? Can one really write algorithms in CSS? According to Lara, absolutely! This talk is all about CSS algorithms: what they are, how to write them, and the potential impacts of a word like "algorithm" when it comes to positioning CSS expertise in the larger context of web development.

Discussions about "when to use decoupled architecture are plentiful and important, but it often assumes or ignores another tricky decision: "Where" to decouple. This talk will discuss the "Decouple Line" and how moving it around provides some amazing features to your API. When designing a content API, the assumption is often that decoupling must take the form of an API that matches your data model, where tables in your data store are mapped to resources in your API (think, /author and /posts). This is often helpful and necessary for exposing the raw data that our UIs need, however, in a cross platform scenario where teams are all building similar features, this can lead to a lot of duplicated efforts and discrepancies between the apps. All of these platforms will be writing similar queries, denormalization logic, business logic, and A/B tests, and then finally render the UI with their respective component libraries. This can lead to platform specific bugs, inefficient queries, and design inconsistency across platforms. Components as Data moves the "decouple line" further toward the frontend to absorb queries, denormalization, business logic, and A/B testing into the backend. In practice, the API serves JSON structured in terms of the tree of UI components that will be used to render the respective data. In doing so, it becomes a quasi frontend in its own right, but it renders JSON instead of HTML or native views. This enables some amazing features: 1. Simpler, presentational frontends 2. Centralized business logic 3. Centralized A/B Testing and Feature Flagging 4. Design consistency via a "Design Schema" 5. Query optimization Finally, this pattern opens the door for writing a cross platform UI library that implements the "design schema" and can be used as the rendering engine for each platform.