Welcome to CampJS opening remarks

What do the designers of sofas and clock radios have to teach us about API design? This talk explores the work of influential industrial designer Dieter Rams, and what it can teach us about the tools we build for each other.

In the late 1970s, industrial designer Dieter Rams wrote his "ten principles of good design", a set of aphorisms outlining how he saw his work. Rams and his ten principles have been hugely influential on design to this day, and that influence extends far beyond Rams' realm of shelving systems, wristwatches and FM radios—Apple chief designer Jony Ive cites him as an influence, and articles applying the principles to web or UI design are a dime a dozen.

But we as developers are designers too, whether we like it or not, and not just on those occasions where we build something that faces an "end user". Our fellow developers are also our users, and the APIs and the developer tools that we build are products that are designed, intentionally or otherwise.

In this talk, we'll use Rams' ten principles to explore good design of APIs and developer tools, and the things we should keep in our minds to build APIs and developer tools that are designed for our peers to use.

The MIDI protocol is a beautifully endearing thing. It's been around, virtually unchanged since 1982! But it's awfully compact and does some tricky and creative stuff when it comes to exchanging larger formats of data.

Join Julian as he reverse engineers a 'system exchange message' from a Korg monologue synthesizer. We will be looking at the raw signal on a spectrogram, observing the bit packing structure and discussing the absurdity of 7 bit bytes!

There will be an interactive component where you are encouraged to use the synthesizers provided and try your hand at decoding some MIDI signals too!

We've found that defining message schema validators - using libraries like Zod - has become foundational to how we write software. This talk goes through how we do it, why it's useful, and how it changes the tradeoffs involved in other techniques and technologies used in web software. We also talk about how this technique fits into some software design philosophies such as Domain Driven Design and Data Oriented Design.

ValueScript is an MIT licensed dialect of TypeScript that I've created. It's written in rust and runs independently of any JS runtime. https://ValueScript.org.

Bevry has been maintaining its hundreds of npm packages that get 500 million installs a month for years using mostly automation, which tests our packages on multiple Node.js versions, attempts Deno packages, compiles our javascript/typescript/vercel projecs, uses the appropriate linting, and documents everything accordingly. It uses an intelligent Editions system to load the appropriate edition for the environment to ensure that the best edition is always loaded for the user.

If you are a maintainer/publisher of npm packages, this is a workshop you don't want to miss.

GIS (Geographic information system) skills are really important these days, it should be in every developers toolbox - as every app usually has a mapping component and the planet (and even other planets!) needs more people to know GIS!

In this talk I'll give an entry level guide to the technology - centered around what I believe are nice core open source tools that we use every day in our business and will set you up to start your GIS journey.

These are mainly

PostGIS (GIS on Postgresql)
QGIS (probably one of the best organised and funded Open Source projects out there)
LeafletJS

ESLint, Prettier and Typescript are great tools for keeping codebases clean but what happens if you have a large legacy codebase and you want to add a new rule or tighten some things up? Do you rebuild it or improve what's there? This talk explores the idea of ratcheting rules in large legacy codebases using betterer and some of the experiences we've had tackling a large legacy codebase.

Testing is hard.

When we do it well everything just works and it kinda feels like testing was a waste of time.

When we do it badly, things are often broken and we wished we did more testing.

What if told you there was a better middle ground. A place somewhere in the middle where testing doesn't cost as much and can deliver a lot more bang for you buck.

In this talk we'll cover various testing techniques that will make you more effective with much less effort. Including my fav: how to cheat at testing so it looks like you did TDD even when you didn't.

Join software craftsman and author Ashley Davis and learn how to be more effective at testing in JavaScript.

Space for anyone to bring a lightning talk, demo, etc to show off to the group

Karaoke - Sing!

Why it is, What it is and why you should be interested

Bun is a new JavaScript runtime (the thing you run to make your source code actually do things) as a rival to the mainstream NodeJS ecosystem.

It features an all-in-one binary, package manager, standard library, complication and compatibility with regular NodeJS projects (... at least in theory).

This talk will cover some of the shiny new features this runtime brings to the table, investigates the speed and efficiency claims and looks at some of the compatibility and change-over issues you might see if you choose to use it.

Modern Javascript requires an eye-watering number of dependencies in order for us to do pretty much anything useful. This talk will explore what actually lurks beneath the "node_modules" folder, the kinds of things you might find in there (and why you might find them), the history of how we came to depend on so many things, and just some of the dangers it exposes us to.

We can't "solve Javascript dependencies" in a short talk, but hopefully it can provide some insights into how we can start to address some of the the issues around what we depend on and why, while still getting our jobs done.

We build applications so that someone will use them. When your new application takes off you will find that operating an application is a skill too. You will need a solid observability foundation to be able to quickly and confidently investigate and diagnose problems. Fortunately, the JavaScript ecosystem has mature telemetry and analysis technology for production diagnostics.

This presentation is a practical demonstration of how to instrument a typical, modern, distributed application and how to make sense of all that data.

Wanted to learn how to make a web game but don't like the steep learning curve of game engines? Learn the basics by learning how to draw on the canvas element & get started on a basic game.

Dorothy — https://github.com/bevry/dorothy — is a dotfile ecosystem comprised of three parts:
1. Commands that streamline everyday interactions with your machine, such keeping your system and its packages updated, securely managing environment secrets, correctly configuring secure DNS, as well as for managing ecosystems like homebrew, snap, flatpak, node, python, ruby, go, rust, etc.
2. Commands that streamline the authorship of your own dotfile commands, such as processing inputs and outputs, handling colours and quite mode, managing configurations.
3. An initialisation script that will ensure your environment is correctly configured and adapted to your machine and its installed utilities, supporting Bash, Zsh, Fish, and Nushell.

All this with cross-shell, cross-os, and cross-architecture portability, enabling interchangeability between such.

Have you ever wondered what those pesky folks at large tech companies are doing changing the UI of their apps and websites one hundred times a day? They’re probably running an experiment on you; yes you! Experiments are one of the most common tools used by—usually larger, but more than ever, smaller—tech companies to understand user behaviour, increase revenue and drive better experiences for customers. Most commonly in the form of A/B tests, they usually involve making a small modification to the experience of a web application and seeing whether that results in the increase of some “metric”, whether that be users, purchases or something else.

However, besides just pushing whack new experiences to production, there is a lot of planning, consideration and statistics that goes into a successful experiment. The aim of this talk is to explain how we do experiments in the growth team of a reasonably large-sized company, Atlassian, and the importance of seemingly small decisions in experimentation. We'll go over all three main phases of an experiment; thinking, implementing and measuring, all with the help of a worked example.

Space for anyone to bring a lightning talk, demo, etc to show off to the group

Closing remarks & demo time. If you built something during CampJS, come on up and show it off. Seeing what attendees built is one of the highlights of the weekend. There'll be some prises to give out too.