Your AI Needs an Assistant

Today’s era of “AI”, better referred to as internet-enhanced autocomplete, is wonderful at producing lots of code - but terrible at producing correct code. And while AI is getting better over time, we still need tooling to analyze generated code for defects. Do you know what parts of your of your toolchain run quickly, in editors, to provide configurable reports on likely bugs and best practice violations? Linting, unit tests, and type checking!

This balanced, nuanced talk will walk through the best and worst cases for AI-generated code. That includes how dynamic analysis (tests!) and static analysis (linting! type checking!) can help resolve many of those issues:

- Knowing when to prefer first-party docs over risky AI regurgitation
- Pitfalls for common code prompts - and the common issues linting and type checking can automatically spot in AI responses
- Systems such as TypeChat for re-prompting for better results by reporting detected defects back to AIs

To conclude, we'll pull that all together with a walkthrough of a new system for AIs that strings together tailored prompts and traditional analysis for a much better code prompt experience. You don't need to run a full v0 to get great code completions locally!

By analyzing both the inputs and the outputs of AI prompting, we can use this amazing new technology in the ways it’s made for - and avoid its all-to-common pitfalls.

I'd like to start by contrasting the benefits to developer education and productivity with drawbacks of lower quality code, misconceptions, and outright “hallucinations” (also known as lies). I'd especially like to show off real-world cases where exuberant AI use led developers down bad paths and had a net negative impact on their ability to function.

The points I'd like to go through specifically are:

- Automatically re-prompting for better results by reporting detected defects back to AIs
- Configuring your linter to find issues tailored to your project’s needs - in and out of AI code
- Forcing prompts to act in “untrusted” modes for AIs, so user-provided misconceptions don’t taint results
- Increasing type safety for AI communications with projects like TypeChat

I want to make this a balanced talk. AI has a lot of hype and a lot of detractors. I think it's useful to put forward a fair, nuanced opinion that respects where we are in the Gartner Hype Cycle for AI.

Type-Safe Style Systems: The Future of CSS

Most CSS developers today write visual styles in terms of what you literally see: exact color values, size numbers, and so on. But what if you could write styles as a function of how they fit into your design system? And what if you could get type safety in specifying and using those values, including in responsive props?

This talk will dive into some of the key features and flaws in many design system builders today such as Chakra UI and Tailwind. We'll establish what the best next steps for design systems should be with type-safe TypeScript APIs and performance both for prebuilt pages and at runtime.

1. How'd We Get Here?
* An overview of that 'W' shape of effort in the modern landscape
* Brief history of how these systems all evolved
* Current trends of how each of those areas are evolving. In particular:
- Clean CSS: CSS variables, new CSS features, and Tailwind systems & abstractions
- Dynamic Systems: design systems and scalability patterns

2. Respective Strengths
* Clean CSS: Smaller repositories, static & performant content, building design systems
* Dynamic Systems: Multi-team organizations; complex sites; building design systems too

3. The Future
* Where both systems fail: type safety with responsive layouts; difficulty in creating variants
* A "perfect"(-ish) system proposal: the cleanliness of Tailwind and the scalability of Chakra UI
* Why continuing to iterate on these scalable systems is important for the industry

Attendees will leave the talk both with an appreciation for the systems of today and hope for the type-safe systems of the future.

Types Beyond TypeScript

Everybody seems to be talking about "types" these days. From the TypeScript language to type description utilities such as Zod, developers expect clear descriptions of the shapes of their data. Let's talk about the mindset shift that's happened over the last decade, and where types are taking us over the next one.

1. Thinking in Type(s|Script): How modeling value shapes helps raise predictability and understandability, especially in the wildest and wackiest of project architectures.
2. TypeScript's Limitations: By design, TypeScript can only act as a development-time type system and enforce what that system can represent. We'll want to go over what can't and/or shouldn't be represented in that type system.
3. Raising the Runtime: Moving those type thoughts into your runtime with programmatic frameworks or libraries such as tRPC and Zod.
4. Node.js Specifics: How this "types-first" theory works helps improve common parts of projects in the Node.js ecosystem: REST or RPC endpoints, testing, and documentation.
5. Ecosystem future: where the TC39 types-as-comments proposal will -and won't- take types at a language-level for JavaScript.

By allowing our types to be a reflection of the runtime reality, we embrace types-first thinking in designing code - making our Node.js code more clear to read and update. Hooray, types!

Building a Design System In-Flight

Design systems -collections of common components, colors, and other constants- are a key way to scale teams and web applications on the modern web. They're particularly handy for deduplicating frontend development costs for microfrontends and remote teams. But how do you create one from scratch -- or, much more commonly, in-flight from an existing service?
This hands-on talk will take you through three stages of crafting your design system:

Stage 1: Extracting colors, spacing, and typography from your existing brand. We’ll cover how slight variances in behavior are generally not intentional, and you want to deduplicate as much as possible.

Stage 2: Creating components following using the first stage’s designs. We’ll start with low-level atom components such as buttons and text, then work up towards forms and other larger conglomerations.

Stage 3: Documentation is critical! TypeScript provides in-IDE developer hints and can enforce proper usage, while Storybook scaffolds gloriously interactive docs pages.

By creating and using a design system, you'll both help and enforce your designers and developers are creating their most consistent work at shockingly reduced costs.

Floating and Sinking Promises: Let's Fix Your Broken Async Code

Promises and async/await are the right way to work with asynchronous code in Node.js. They're also both the easiest code constructs to introduce bugs with -- and can be some of the hardest code to debug. We'll walk through:

* Refactoring pre-Promise callback hell to Promises
* Refactoring pre-async/await Promises to async/await
* Debugging with console logs and node --inspect
* "Floating" Promises (those created and not handled): detection with TypeScript ESLint, and error handling
* "Sinking" Promises (those created and handled improperly): detection with TypeScript ESLint, and error handling

Each of those classifications off issues will be resolved in three steps:
1. We'll look at how their need can develop in even the most type-safe, well-architected, well-intended projects
2. We'll see how to detect those issues - as bugs and/or development-time smells
3. We'll see how tools in TypeScript and/or typescript-eslint can detect them for us, and sometimes even automate the fixes.

By the end of this workshop, you'll be fully prepared to debug even the gnarliest asynchronous shenanigans and write production quality asynchronous code.

Floating and Sinking Promises: Understanding Broken Async Code

Promises and async/await are the right way to work with asynchronous code in Node.js. They're also both the easiest code constructs to introduce bugs with -- and can be some of the hardest code to debug. We'll walk through:

* Refactoring pre-Promise callback hell to Promises
* Refactoring pre-async/await Promises to async/await
* Debugging with console logs and node --inspect
* "Floating" Promises (those created and not handled): detection with TypeScript ESLint, and error handling
* "Sinking" Promises (those created and handled improperly): detection with TypeScript ESLint, and error handling

Each of those classifications of issues will be understood in three steps:
1. We'll look at how their need can develop in even the most type-safe, well-architected, well-intended projects
2. We'll see how to detect those issues - as bugs and/or development-time smells
3. We'll see how tools in TypeScript and/or typescript-eslint can detect them for us, and sometimes even automate the fixes.

By the end of this session, you'll be fully prepared to debug even the gnarliest asynchronous shenanigans and write production quality asynchronous code.

Killing Mutants with Mutation Testing

Who tests your unit tests? Even if a line of code is covered by a test, you're not guaranteed the test verifies anything. Enter mutation testing: the practice of inserting "mutant" bugs into your code and checking whether any tests catch them.

This hands-on talk will walk you through real-world code issues detectable with mutation testing, how mutation testing catches them, and how to get started with it locally.

In particular, we'll cover:
* Where unit testing coverage does or does not act as an effective measure of behavioral coverage
* Common types of bugs and developer mishaps
* How mutation testing works at a theoretical level (AST analysis, mutators, and strategies for efficient re-testing)
* Running mutation testing on an example TypeScript repository
* Integrating mutation testing both into technical needs (i.e. CI/builds) and interpersonal (e.g. team culture)
* Creating our own custom mutators for business-specific use cases
* Where mutation testing does not catch code slipups and/or can be augmented with other forms of static or dynamic analysis

We'll view demos of TypeScript code with StrykerJS but the lessons learned will be applicable across any stack.

Static Analysis: Shockingly Awesome! ⚡️

Wouldn’t you love to automatically zap code bugs before releasing to production? How about before your code even gets run? Static analysis tools scrutinize your code as you write it - giving you blazing fast feedback at development time. We’re going to go into how that works, why it’s useful, and -best of all- how to enable the best configurations for ESLint, TypeScript, and their associated tooling in your app.
In particular, we'll cover:

* The tooling differences between formatters, linters, and type checkers
* How to appropriately set up each of those tools for local development and CI/builds
* A brief overview of using recommended rulesets from ESLint and TypeScript-ESLint -- and why you'd want to
* The kinds of development-time issues each of those tools catch
* Using ESLint and TypeScript as documentation sources and to educate developers on general and team-specific best practices
* Longer-form demo showing lint rules catching three classifications of async/Promise bugs in a React app

A primary goal of the talk is to get the audience excited about the tooling they can run on their code. A lot of developers don't see static analysis as something they need to care about -or are even scared of the term- despite how useful it is day-to-day. This talk will have you detecting bugs, bad practices, and code smells in your web apps at lightning speed! ⚡️

TypeScript for JavaScripties: Full Day Edition

You've heard about TypeScript and maybe poked at a docs page or two. But it's still a mystery for you. Not to worry! Josh Goldberg -author of the O'Reilly Learning TypeScript book- will walk you through the foundations of "types" and a "type system" up through the important language features you'll need to get started understanding TypeScript.

This workshop will go through through topics equivalent to the Learning TypeScript book table of contents - a battle-tested, intentional set of topics that build on each other to teach TypeScript. We'll cover each of the chapters:

1. From JavaScript to TypeScript: Why JavaScript is the way it is with respect to types (or lack thereof), and where TypeScript does or does not fit in
2. The Type System: Foundations of how TypeScript's type system fits in to JavaScript code and understands your values
3. Unions and Literals: How TypeScript understands values that can be one or multiple possible primitives, along with strict null checking (the "billion dollar mistake") and the powerful concept of "type narrowing"
4. Objects: How TypeScript's "structural typing" allows it to understand objects by their shape and intent, not just by their declaration forms
5. Functions: How TypeScript understands function inputs, outputs, and quirks around "void" and "never" types
6. Arrays: TypeScript's understanding of fixed type, evolving any, and fixed size ("tuple") arrays
7. Interfaces: Akin to types, but with advantages on readability and performance, and an excuse to look at various property modifiers allowed on both
8. Classes: Broadly how TypeScript models class inheritance, properties, and static fields -- even if your framework of choice doesn't go deeply into them
9. Type modifiers: Various keywords such as 'keyof' and 'typeof' that bend the type system to your will
10. Generics: Adding in type parameters that allow constructs such as functions and interfaces to be flexible on what types and values they're used for
11. Declaration files: How external JavaScript -and your own built outputs- can still be described in the type system
12. Using IDE features: Code navigation, name completions, and error debugging that level up any JavaScript and/or TypeScript developer
13. Type Operations: Introducing logic in the type system with mapped and conditional types

Each session consists of a 25-30 minute interactive lecture+workshop, with 5-10 minutes in-between for bio breaks and miscellaneous questions, and a lunch break in the middle.

TypeScript for JavaScripties: Half Day Edition

You've heard about TypeScript and maybe poked at a docs page or two. But it's still a mystery for you. Not to worry! Josh Goldberg -author of the O'Reilly Learning TypeScript book- will walk you through the foundations of "types" and a "type system" up through the important language features you'll need to get started understanding TypeScript.

This workshop will go through topics equivalent to the first half of the Learning TypeScript book table of contents - a battle-tested, intentional set of topics that build on each other to teach TypeScript. We'll cover each of the chapters:

1. From JavaScript to TypeScript: Why JavaScript is the way it is with respect to types (or lack thereof), and where TypeScript does or does not fit in
2. The Type System: Foundations of how TypeScript's type system fits in to JavaScript code and understands your values
3. Unions and Literals: How TypeScript understands values that can be one or multiple possible primitives, along with strict null checking (the "billion dollar mistake") and the powerful concept of "type narrowing"
4. Objects: How TypeScript's "structural typing" allows it to understand objects by their shape and intent, not just by their declaration forms
5. Functions: How TypeScript understands function inputs, outputs, and quirks around "void" and "never" types
6. Arrays: TypeScript's understanding of fixed type, evolving any, and fixed size ("tuple") arrays

Each session consists of a 30-35 minute interactive lecture + workshop, with 5-10 minutes in-between for bio breaks and miscellaneous questions.