products

Conference talk proposals

My presentation ideas, abstracts and cfps.

I constantly apply to speak at Boston meetups and conferences world wide. Sometimes I get accepted. Here is my current list of proposals for reference. If you would like me to speak about these topics, get in touch. You can find my slides at slides.com/bahmutov and videos from previous speaking engagements in this YT Playlist. Some presentations have links to slides and videos from conferences.

JavaScript presentations

Modern JavaScript

abstract

Let us look at JavaScript - the language that runs the Internet. We will learn how new features are added to the language, how the modern syntax looks, and the main tools for testing, transpiling and bundling JavaScript applications. Anyone looking to start with JS or upgrade development skills will benefit from this presentation.

details

I am going to cover the following topics:

  • where JavaScript is used today: browser, mobile, server, desktop, build scripts, service workers.
  • how new features are added to the language
  • main tools for testing, linting and bundling code

presentations

Previously shown to great acclaim at the following conferences

Cycle.js: get in the loop

abstract

An introduction to the Cycle.js: a modern functional reactive framework. Cycle.js breaks with the existing Model-View-Controller approach, instead focusing on making the data flow inside your application as clear as possible. All external interactions: the browser, the server API calls, the real time feeds are modeled as input and output reactive streams, making your own application code pure from side effects. Programming with Cycle is very different from using any other library for web development; attend this presentation to find out what makes Cycle.js so special.

presentations

  • FrontEnd Camp NYC 2016 slides

It's not your parents' HTTP

abstract

The Internet of simple textual requests and responses is done. Finished. Obsolete. The modern web is a web of binary, persistent connections like WebSockets, WebRTC, HTTP/2 and QUIC. Today's Internet is a strange place where things are received before they are requested (Server Push) and a web application work without Web (offline support with Service Worker)

details

I will start with the history of HTTP, and how it changes from 0.9 to 1.0 and to 1.1. I will explain the performance benefit of HTTP/2, the state of support and a very interesting performance feature (Server Push). Then I will talk about real time systems that use Web Sockets for persistent data connection. Then I will talk about data synchronization solutions via in-browser database that can sync automatically. I will talk about offline support and instant web applications using ServiceWorker, and finally I will describe why HTTP/2 is going to be replaced by a protocol named QUIC based on UDP.

presentations

I have done this presentation several times, with different emphasis, and every time the audience loved the contrast between the original goals of HTTP 0.9 and how it is used now.

Hyped about Hyperapp

abstract

What is the smallest and purest front end framework out there? Did someone say Elm? I said smallest! The answer is Hyperapp - a really tiny, Elm-inspired pure functional web framework that combines the best features of today's hottest frameworks. It has built-in state management, pure functions, virtual DOM and still is easy to learn in 30 minutes.

presentations

Which web framework should I learn next?

abstract

Should I learn and use Angular 1, React, Angular 2, Ember or something else? What are the common features they all share? How are they different? Are there "better" frameworks that will be popular next year? I will show a couple of new approaches that should be part of any future-proof framework: reactive streams for managing the data flow, virtual DOM abstractions for speed, testability and performance tools built right into the framework. The presentation might be controversial, but the struggle to pick "the next best thing" is very real.

details

First, I will talk how unproductive are arguments "framework X vs Y". Then I will talk about features that are only now appearing in the web frameworks:

  • DOM abstractions for performance reasons (moving virtual DOM computation into separate thread using WebWorkers)
  • Modular design for smaller size (we can start small, or we can cut a large bundle)
  • Hydration using ServiceWorker to speed up the startup times
  • Offline support
  • Universal rendering
  • Reactive streams as first class objects
  • Functional purity
  • Real time support instead of "turn-based" abstraction

From another angle this presentation can be titled "My journey from MVC to FRP". Based on the personal experience, we have discovered many common problems the modern frameworks do not solve yet. Solving offline for example, requires dramatically rethinking the web application's architecture. I hope the redesign can happen soon, because the real world's needs demand the features from the above list!

presentations

Semantic release

abstract

Manually releasing new software versions is dangerous. You might forget to test it before releasing, or you might release a platform-specific version, instead of a general one. Moving the release to the CI and automating it is the key to repeatable and robust release process. In this talk I will show how to setup completely automated yet robust release system with semantic versioning for JavaScript using NodeJS.

Self-improving software

You software does not have to be hopelessly behind in its dependencies.

abstract

Every JavaScript project requires 3rd party modules. As soon as you depend on specific versions, your module falls behind. I will show how to keep your software up to date without any effort (as long as there are some tests). I will also show how your NPM package can guarantee NOT breaking its downstream dependencies; and even the major changes can be upgraded automatically by using codemods.

You can automatically upgrade dependencies for an individual project, or a collection of projects. You can even estimate if a particular update is likely to succeed based on global stats. If upgrading your dependencies can be automated, why not streamline publishing new versions of our module? It is very easy using the existing semantic release tools.

details

Everyone argues about semantic versioning, modular architecture and large repos vs large number of dependencies. The tools I will show make the highly modular development possible. I have described a lot of ideas in a series of blog posts

I wrote the Node tools that allow splitting the project into lots of focused small modules, without increasing the effort that goes into keeping all the pieces working together. The tools are all open source:

  • changed-log for seeing commit messages between any two releases
  • next-update for upgrading an individual project
  • next-updater for upgrading and publishing multiple projects
  • next-update-stats keeps anonymous stats across multiple projects, see http://next-update.herokuapp.com
  • dont-break tests projects depending on your module to ensure a safe release
  • dont-crack is a plugin for semantic-release pipeline to use dont-break module before automatic publishing to NPM registry.
  • next-ver is local semantic version update tool.
  • version-remix is a work in progress that allows combinatorial explosion of published versions by releasing every permutation of features.

presentations

What did we just test?

Use advanced code coverage techniques to better target the testing effort.

abstract

Code coverage tools are extremely useful, yet they do not show what the final coverage looks like. In the most development setups, the individual commits are cherry picked from the development to the staging to the production branch. The final coverage might be very different after some updates are transferred, merged. Add to this the fact that the manual feature testing is not included in the coverage information, and the metrics become useless.

I will show several tools that enhance the code coverage computed from unit tests. First, there is a code coverage proxy was-tested that I wrote. It collects code coverage information during end 2 end feature testing, usually performed by the QA people. This is extremely valuable, because most of the front-end code is extremely time consuming to test using automated tests.

Second, I wrote tested-commits tool that takes any code coverage information and splits it back to coverage by an individual commit. Thus we can track how much we have tested each feature / bug fix that merged and moved around the branches.

Third, one can make any Node server a live source of real-time coverage events! Then just sit back and receive a stream of "line K covered" events.

Taken together, we can reliably speak about each feature tested at 90% before being deployed to production, even if the testing is manual.

details

Testing is hard. Unit testing with code coverage has recently become wide spread, while achieving code coverage for live website testing with actual users has not been practiced. I wrote tools to collect the code coverage on the fly (see blog post https://glebbahmutov.com/blog/code-coverage-proxy/) and to split any code coverage information into individual commits (read the blog post https://glebbahmutov.com/blog/code-coverage-by-commit/). These two pieces play nicely with existing unit test coverage tools (like istanbul), and solve huge quality problem in the modern web applications.

Web application profiling using code snippets

Find bottlenecks in live production code instead of running microbenchmarks.

abstract

Chrome DevTools code snippets became my favorite tool when investigating performance bottlenecks in web applications. A JavaScript fragment can be stored as a named snippet in the "Sources" DevTools panel and executed in the current page's context, just as if it were a code executed in the browser's console.

Using code snippets we can start CPU, timeline and memory profilers, get very accurate information about any performance measurement, and quickly find the application's bottlenecks. We can even auto update locally stored code snippets using a code snippet!

In this presentation I will go through a typical web application, using different code snippets to measure and locate bottlenecks. Any developer trying to make a page faster would benefit from knowing about code snippets.

details

See blog post https://glebbahmutov.com/blog/performance-profiling-using-devtools-code-snippets/ where I walk through a typical web application step through step, finding bottlenecks using code snippets and then fixing them one by one.

The web performance is certainly an important topic these days. The code snippets allow accurate and quick profiling. My github repo with code snippets https://github.com/bahmutov/code-snippets has become my most starred project overnight.

presentations

  • /dev/summer Cambridge, UK 2015 slides
  • BostonJS meetup 2015 slides

Workers of the world, unite!

abstract

WebWorkers have been very useful for performing computation-intensive tasks in parallel, preventing browser lockup. Recently a new beast has appeared: the ServiceWorker. I will show how to use both WebWorkers and a ServiceWorker to add new features to the web development: rendering HTML from data without blocking the main thread, supporting offline mode, computation-intensive tasks.

details

I used a WebWorker to run Angular app in a WebWorker for speed, while using a ServiceWorker to have a flexible HTTP interception to provide exploratory testing at run time, see service-turtle. I also used ServiceWorker to make web application instant - appear inside the browser with no flashing or delay, see the blog post Instant Web Application. Finally, we can marry the two technologies: server-side rendering and the browser. I have been able to port the entire ExpressJS server to run inside the ServiceWorker, producing fast, "static" web applications, described in Run Express server in your browser.

presentations

Alternative - only the ServiceWorker focused

WebWorkers have been very useful for performing computationally intensive tasks in parallel, preventing browser lockup. Recently a new beast has appeared: the ServiceWorker. Most examples show this technology used to provide powerful offline support and smart caching, but we can do much more; achieving things that were considered impossible, like zero flicker instant web application startup.

I will show how to use ServiceWorker to implement what used to be considered impossible features

  • Make any web application appear instantly in the browser (zero flicker)
  • Run the most popular NodeJs server ExpressJS completely inside your browser
  • Transpile the code on the fly precisely targeting the client environment
  • Run a web application in the browser with disabled JavaScript

Browser is the new server

abstract

We see the great technology unification, with the boundary between the server and the client (browser) becoming blurrier every day. Who has time and budget to write separate code bases? In this presentation I will show the ultimate combination of NPM's two most popular packages: Browserify and Express; and their product that allows to move the complete server to run inside the browser's ServiceWorker. It is like server-side rendering but inside your browser, and even runs when JavaScript is disabled!

details

I have implemented several unusual hybrids of server and browser in these projects

presentations

Journey from procedural to reactive JavaScript with stops

abstract

JavaScript is an interesting language. It can mimic almost any style you want: procedural, object-oriented, functional, etc. In this presentation, I will take a simple problem and will solve it using different approaches. With each step, we will see the power of each approach to take the complexity away, while still being the JavaScript we all love to hate. The following topics will be shown:

  • procedural (imperative) style
  • object-oriented
  • functional
  • point-free
  • lazy evaluation
  • immutable data
  • async processing using promises
  • async processing using event emitters
  • advanced topics: transducers and streams
  • reactive programming using event streams

Any team looking to improve its code should attend this presentation. Making a single leap from an object-oriented approach to reactive programming is too difficult, but you can make it step by step.

details

This has been a very productive shift for me personally and for my team at Kensho. We are slowly moving away from procedural style and are currently at functional / promises steps. Our code became smaller, easier to test and understand.

These blog posts show the content I would like to present:

I have spoken about this topic at several conferences, always provokes a lot of discussion and many interesting responses. A few videos of me speaking are available https://glebbahmutov.com/videos.html and the slides are available at https://slides.com/bahmutov

presentations

How do you deal with runtime errors?

abstract

What happens when there is an exception in your JavaScript code? Does the application crash? Does it show an error message to the user? Does it send the information to the developer? In this presentation I will show how to improve the quality of your JavaScript apps without spending a lot of time testing.

My main tools to guarantee good quality are:

  • real-time error monitoring and crash reporting
  • defensive and even paranoid programming style
  • using lazy assertions
  • exploratory testing to trigger bad server responses and see how the program deals with them
  • best programming practices for ensuring errors do not silently disappear (cough Promises)
  • snapshot and schema testing

Anyone tired of deploying websites only to see them break apart, or exhausted from banging on the app before deployment should attend this presentation.

details

We spend very little time on unit testing, yet our code works. We know it works, because we have real time error and crash reporting - see my blog posts https://glebbahmutov.com/blog/know-unknown-unknowns-with-sentry/ and https://glebbahmutov.com/blog/catch-all-errors-in-angular-app/ We benefit from crashing early and thus use a lot of assertions in our code to overcome JavaScript's dynamic nature. Yet we do not suffer a performance penalty because our assertion library is lazy - https://glebbahmutov.com/blog/lazy-and-async-assertions/

Finally, the top jewel of our web applications is how robustly we handle errors (like bad server data). We can actually confirm that our error handling logic works using 3 different types of live server request intercept and mocking - read https://glebbahmutov.com/blog/robustness-testing-using-proxies/ how we do this.

Promises, promises, promises

Promises cut through the callback hell. Yet, they have their own quirks. In this talk I will show how to properly terminate promise chain in order to avoid silent errors; how to chain multiple steps together; how to tap into the chain for debugging; how to generate success vs error paths; how to add timeouts; how to generate and cache resources using promises.

Finally, I will show how JavaScript despite a single thread still might have a concurrency problem due to the unexpected execution ordering.

details

I have looked at promises in detailed from different perspectives. In my mind it is required technology for anyone using JavaScript in asynchronous fashion. Even for people who use event emitters or reactive programming approach to async, the promises is a required step to master. I covered promises in a lot of blog posts, see the list at https://glebbahmutov.com/blog/tags/promises/

JavaScript lexical scope magic

abstract

JavaScript is a dynamic language, and sometimes we can bend its rules a little. One of the rules we rely upon is that one cannot override variables inside a closure from outside. We call these variables part of the closure, and turns out they can be mocked! I will show how to fake variables defined outside the function's own scope and several practical use cases:

  • mocking server responses in live AngularJs application without any external tools
  • patching Node system require function to make it more powerful
  • testing functions for side-effects (purity test)

Think your function is safe inside a closure because no one can call it with unexpected arguments? Think again! I will show is how to compromise functions private to closures via references to the returned partially applied functions.

Anyone trying to really master the JavaScript should be aware of these techniques.

details

Understanding closures (https://glebbahmutov.com/blog/javascript-closures/) is fundamental to programming JavaScript. One of the rules is that the function returned still has access to the variables outside its own immediate scope where it was defined. Turns out we can easily reevaluate the function and substitute our own variables into the lexical scope. See how I have done this in https://glebbahmutov.com/blog/faking-lexical-scope/ and the linked blog posts on real world uses.

I described the "unapply attack" in this detailed blog post: https://glebbahmutov.com/blog/unapply-attack/ This is the current ES5 running in the strict mode. Without strict mode, all sorts of crazy things are possible, like changing the passed arguments inside the function, see https://glebbahmutov.com/blog/changing-the-function-arguments-trick/

presentations

  • ManhattanJS meetup 2015 slides

Remove the boilerplate

abstract

In this talk I will show how to remove lots and lots of unnecessary code from your application. Counter variables, wrapper functions, callbacks - they can all be removed using utility libraries or even built-in JavaScript ES5 language features. In particular I will show how to remove

  • callbacks and pyramids of doom
  • extra functions just to massage the arguments
  • wrapper functions
  • manual iterations
  • special emphasis on removing boilerplate code from the unit tests

In each instance there will be a lot less code, but it will be more robust, manageable and simpler to reason about and test.

details

JavaScript code should be simple and expressive, but often we write extra code just to get the write arguments to a function, or bind the context, etc. A few samples how I minimize amount of code in my applications

You can find all my blog posts that deal with removing boilerplate under the tag

presentations

Replacing built-in Node require

abstract

The Node require method that loads source files, compiles and caches them is ok, but could be made a lot more powerful. Luckily one can replace the built-in require in user space without much effort. In this presentation I will show how to

  • use your own require version with extra features, like cache busting and passing extra variables or loaded code transformation.
  • speed up application startup by 25% with a single require include to avoid path hunting.
  • quickly unit test most private functions and variables.
  • related: secure the Node server by making the require cache add-only.
  • related: make loaded code a source of real-time code coverage events.

details

I will base the presentation explaining the module loading logic and the javascript tricks (like faking lexical scope) that allowed me to implement the following interesting projects:

  • really-need is a powerful require replacement module.
  • cache-require-paths speeds up application startup times by 25% by caching filename resolutions to avoid path hunting.
  • describe-it gives you access to any private function, functional expression and most variables without modifying the source code.

Porting a cross-platform application to Windows

abstract

Running an Electron application on Windows should be easy, right? Well, yes and no. In this talk I will describe the reality of building and releasing an end to end testing tool Cypress (OSS, MIT licensed, based on Electron application) on Windows platform. In the end, we were successful, but there were surprises along the road.

TypeScript Benefits Without TypeScript

Abstract

In this presentation, I will show how to get type checks without going all the way to TypeScript. We will look at how you can write JSDoc comments to describe types. I will also show how we provide external TypeScript definitions in Cypress end-to-end tests where the tests themselves are written in JavaScript.

presentations

Previously shown to great acclaim at the following events

  • Boston TypeScript meetup, Feb 2019 slides

GitHub Actions in action

In this presentation I will show how simple the continuos integration can be with GitHub Actions. They are powerful, have generous limits for public repositories and can be easily reused. In particular, I will show a few use cases that can be of interest to any JavaScript or TypeScript developer:

  • how to run Prettier inside a GH Action and push any updated code back to the repository
  • how to correctly install Node dependencies with a single YAML line
  • how to run end-to-end Cypress tests without pulling your hair out

presentations

  • NomadJS online, end of 2019 slides

Rethinking Continuous Integration Configuration: CircleCI Orbs and GitHub Actions

Abstract

Nobody likes writing continuous integration config scripts. In this talk, I will show two new ways to configure CIs via reusable 3rd party orbs (CircleCI) and actions (GitHub). Both technologies make CI config quick and easy, but use very different approaches that I will explain.

Description

Writing continuous integration scripts is a frustrating loop of copying, pasting, tweaking and pushing code to CI to see if it works. As an author of tools that other people use in their CI pipelines, I feel the frustration: because every tool has its own caching requirements, executor parameters, and run-time arguments. Yet what can I - the author of the tool X - do to help my users configure and run the tool correctly? Nothing really.

That was the situation until about a year ago when CircleCI has released the "Orbs" way of configuring individual tools to run on CI. Similarly, at the end of the last year, GitHub Actions CI released workflows that can reuse 3rd party CI config scripts (called GH actions). Both technologies allow the tool's authors to write the CI snippets that the users can "drop" into their pipelines without any additional low-level configuration.

Notes

I have been using CircleCI Orbs for a while, the Cypress orb I have written is probably the most popular orb outside of the orbs written by CircleCI team itself. We have even done a combined webinar with CircleCI team explaining the orbs with Cypress orb as an example, find the slides and video here.

Similarly, I have written NPM install and Cypress GH Action that are very popular and significantly simplify running our testing tool on CI. Previously I have done NomadJS presentation on GH Actions slides because I am really excited how simple and powerful they are. I would love to tell more people about these two approaches to hiding the CI config complexity, and how they shift the CI config responsibility from the user's space to the tool's authors.

AngularJS presentations

Secure your Angular applications

abstract

What do Chrome extensions written in Angular and secure websites have in common? They take Content Security Policy seriously! In this presentation I will show

  • how bad things happen to good people
  • how to switch from chasing the bad guys to protecting yourself
  • how to secure your web application against cross-site scripting attacks

presentations

  • AngularConnect, UK 2016 slides

Improving Angular application performance

abstract

Once your Angular application has the features you need, the next step is usually focused on improving its performance. The initial load time, responsiveness to user's commands - the application has to execute quickly in order to be useful. Is Angular framework fast or slow? I argue that is very fast, but requires knowing how to measure and optimize the right bottlenecks. In this example I will show multiple possible performance traps

  • JavaScript engine bottlenecks and things to avoid
  • Measuring idle digest cycle time
  • Simplifying and caching expression and filter results
  • Removing double data binding
  • In-code markup generation
  • Quick above the fold markup generation
  • Splitting large model / DOM update job into batches
  • Offloading computation to a web worker
  • Measuring and optimizing memory allocation
  • On-demand computation
  • Minimizing data attached to the scopes
  • Limiting digest cycle to part of the application
  • Keeping only visible parts of the application in the DOM

Anyone who needs to speed up Angular application should attend this presentation.

details

I have been working on Angular application performance problems recently, making our code faster. In the process I kept updating the blog post https://glebbahmutov.com/blog/improving-angular-web-app-performance-example/ with new findings. This blog post became very popular, if you google "angular performance" it usually comes up in the first 3 results. Today many people argue for / against Angular compared to other frameworks, it is important to know the Angular-specific common performance bottlenecks and how to avoid them.

Unit testing AngularJS

abstract

Writing unit tests is a time-consuming chore; but it is necessary before we can fix bugs or develop new features. Testing AngularJS code in particular requires a lot of boilerplate. In this presentation I will show a simple helper library can remove all the extra code and allow to unit test code in seconds.

details

Take a look at ng-describe - it provides a single helper function ngDescribe that is a BDD wrapper specific to the Angular framework. The ngDescribe makes injecting specific services to be tested very quick and intuitive. It also provides advanced features, like mocking services and HTTP responses. As I describe testing different Angular aspects; from simple values to custom directives; I will point out how ngDescribe has a user-friendly API. With ng-describe in your tool belt, there is no more excuse no to test your code.

presentations

A simple checklist to follow

Alternative title: A checklist for your Node project.

abstract

Checklists have been known to reduce errors during air flights and surgeries. Why don't we use one for our JavaScript projects?

I want my NPM module to be useful, robust, and well-documented. I want it to stand out from the 100s of the modules that do a similar thing. Here is my recipe for a module that everyone can rely on: a simple checklist. Rather than forcing everyone to do the same, the checklist only reminds me to do unit testing, publish smaller module, have good API examples, and lots of other useful things.

details

I have published hundreds of modules on NPM. While not as prolific as some NodeJS superstars, I know that others can reuse my work, and it is simple for me to implement a new feature when needed. My development and roadmap for each module is open - it is in a simple checklist I share freely at bahmutov/npm-module-checklist.

I will go through main items in my list; why a particular TODO item is important and the main tools that help me to mark it done.

Securing the front end, from a Node server

abstract

A simple technique to disable the script injection attacks on your web pages is to disable the inline JavaScript. This means that most popular ways to inject variables and code fragments into your pages will have to change. I will show the JavaScript to JavaScript rendering engine for Express that allows you to set very strict and safe Content-Security-Policy on your website. Not only my approach is much safer, but it will be very testable as well.

As a bonus I will show another project that can prevent sensitive information leaking to GitHub and NPM.

Details

presentations

  • Boston CodeCamp 2016 slides
  • Boston Node meetup 2016 slides

Software Engineering presentations

Find me if you can

abstract

Having a good text search is the key to successful documentation, especially as the number of pages, examples, code recipes, answers, and other user-facing text snippets grow. In this presentation, I will show how to set up the Algolia search index and use it from a static site to make sure your users find everything they are looking for.

You can find more details in the blog post Scrape Static Site with Algolia.

presentations

  • LondonJS Online Meetup slides

JSON schemas are your true testing friend

abstract

In our company we have a lot of data flowing from the user’s applications (and we are backwards compatible) to the API, then this data is displayed in the web dashboard. How do we avoid accidentally breaking API contracts, while adding new features? We have started using json-schema convention and wrote a few tools around it to lock down our API protocols. Now we have full confidence in our tests, and major refactorings and releases happen without hiccups. Bonus: our tests are realistic, elegant and easy to understand.

details

At Cypress we have 3 large pieces of software:

The Cypress Test Runner, an Electron desktop application. The API which receives test results from the Test Runner when running cypress run --record The Cypress Dashboard Service, a web application that shows test results to users. When we were planning version 3 of the Cypress Test Runner, we needed to make sure big changes to the way the Test Runner processes test runs did not break anything these changes were especially important as we were preparing to introduce automatic test load balancing. Not only the Test Runner had to change, but the API had to introduce new features while supporting both existing versions of the Test Runner and the new v3. The changes also would affect the Cypress Dashboard.

In short - we had a huge amount of work on our hands; and this work had to be backwards compatible.

The solution we came up with to avoid accidentally breaking our clients (both the Test Runner and the Dashboard could be called our API’s clients) was easy to understand and use. It solved the version problem, made testing super simple and made self-documenting code a reality. This presentations shows our solution by going through an API and showing what we did at each step.

schema-tools, blog post

presentations

  • Boston JS meetup August 2018 slides

Explain with examples, without writing any

abstract

Humans learn best by example; good technical docs use lots of them. Yet all modern documentation tools (think jsdoc) making writing correct examples and maintaining them a chore. There is no tool support for syntax highlighting, or even guarantee that an example is correct or up to date.

On the other hand, solid software projects have lots of well tested, up to date examples. We call them unit tests!

In this presentation I will show how to take the unit tests and transform into syntax-agnostic human-friendly examples to be plugged into your docs. Documenting your API will never be the same - it will be a simple and pleasant experience. One can even target other types of documentation: my blog posts have examples that are generated from unit tests, thus sparing me the embarrassment of having a broken source fragment.

details

xplain - the tool for generating API documentation or updating Markdown documents from units tests. Example API, or example README.md with lots of usage examples - all coming from unit tests.

presentations

  • CodeMotion Berlin 2016 slides

Building an orchestra of rock stars

abstract

Our startup Kensho has achieved a lot in less than 2 years: signing up huge corporate clients, being used by CNBC on the air every day and even changing how the financial research is done. All these things were done with a small number of exceptionally productive engineers. In this presentation I will go over our two strengths: a development approach we call Agile+ and unorthodox approach to hiring new engineers.

Agile+ means we prototype quickly a feature but always invest time to refactor if it is to stay; no technical debt accumulation long term. Our hiring focuses on people with experience and students still in college; then we train the rock stars out of them.

Finally I will talk about the dark area in software industry: handling employees who quit, and how we are trying to change this experience at Kensho.

details

I have delivered this presentation at the Great League of Engineers event in Boston where we talked about what makes some teams very productive. You can find my slides at http://slides.com/bahmutov/rockstars and notes from the event at https://glebbahmutov.com/blog/great-league-of-engineers/

presentations

  • Great League of Engineers, Boston slides

My ultimate "code quality as a service" proposal

abstract

Continuous build services (like TravisCI) became a must-have tool for any serious project. The setup is super quick and checking every pushed commit, or Github pull request is very valuable for keeping the project build green. Recently, several other "code metric as a service" resources became popular: test code coverage and static code analysis. What if I could design my own "code quality as a service"? What could it do? How would it present its results? Can it help us solve the technical debt accumulation problem?

details

More details available in Code quality as a service blog post.

Think inside the box

There are four operations "Ops" things that I am excited about today: Docker, Kubernetes, Dokku and Zeit. All make my life as a developer a lot simpler, they change the way I test software and they blur the line between the local and the production environments. Enterprises already use the first two, while every developer should use all four tools.

abstract

It used to be hard to actually run code in production. I needed to rent a rack server from a company, login into the machine, set it up, then periodically deploy new application version. Deploying often meant overriding the existing running application, taking a server offline. Long, cumbersome, and error prone. No wonder we did deploys once a month! Luckily there are 4 things that recently revolutionized the way I deploy and run code: Docker, Dokku, Kubernetes and Zeit Now.

Details

Here are the 4 things that completely changed the way I, a developer, view code deployment and running the production servers.

  1. Docker allows me to run my code in the same environment as the server.
  2. Kubernetes is managing multiple docker boxes as one.
  3. Dokku is open source platform to run docker containers that is perfect for personal projects.
  4. Zeit.co makes code deploys almost instant, and more importantly the deploys are immutable.

Read the blog posts Think inside the box and Cypress and immutable deploys

I see your point but ...

abstract

This will not be your typical presentation following "here is a problem, and here is how I solved it" scenario. Brian Mann and I work together on many testing tools for JavaScript, yet our opinions on what a good test is or how to write quality software are often at odds. In this presentation we will respectfully disagree with each other about the following topics:

  • test-driven development vs end to end tests
  • stubs and mocks
  • cross-browser testing
  • code and data coverage
  • picking the right test framework and snapshot testing
  • legacy browser environment support
  • crash reporting and performance monitoring
  • earning leaving by writing OSS testing tools

We will have a dialog and an argument about the means, but our goal is a common one: making the software running the world more reliable.

Everything I know about writing quality software

abstract

In this presentation I will show all the tools I use to write software that does not break but keeps the users happy. Static types, exception monitoring, unit tests with snapshots, randomized testing, code and data coverage, code complexity metrics and awesome end to end testing tools - the list is long and keeps on growing! The techniques I plan to show are applicable to every framework and environment.

details

A preview talk has been given and warmly received by the MIT web development class 6.148 of 2017, see the slides here. But the universe of tools keeps growing and we can adapt tools that came since (like snapshot / schema testing). For more details, see my blog posts on testing.

presentations

Shapes of development

abstract

A geometric shape is simple to remember and visualize concept, familiar to any child. In software development we have a few concepts with associated shapes: agile is shown as a spiral curve, waterfall as, well, a waterfall, etc. In this presentation I will show the shapes that describe other modern development approaches and architectural styles.

Details

In this presentation I will go through a list of concepts, each concept closely matching a geometric shape. While the list is long, here are the main shapes:

  • Artifact repositories decouple software development steps, and can be visualized like large warehouses storing versioned code, ready to be "shipped" to be assembled into a new application.
  • Software isolation using Docker can be drawn as a box. Multiple boxes can be stacked and deployed together in a cluster. Closely related to are immutable deploys that always build a new set of boxes, rather than modifying the existing one.
  • A reactive system useful for modeling modern user interfaces can be described as a directed acyclical graph (the user is the missing link that would close the cycle)
  • Functional programming concepts usually deal with functions, but also with "boxed" types like Monads. Visualizing these helps to understand the modern JavaScript, Elm and Haskell languages.
  • A typical developer's expertise is a T-shaped figure, and often a little investment in related vertical "bars" can be extremely beneficial. In particular, the knowledge to install a library or an application can be modeled as a pyramid. By making the pyramid's layers thinner we can achieve reusable software.

A right abstraction goes a long way in making a concept simple to understand. This presentation shows the shapes that helped me be more productive and explain my work to others.

key takeaways

  • reusable software with semantic versioning
  • immutable deployment pipelines
  • functional reactive programming
  • developer's skills and learning

presentations

Why I record hundreds of videos and so should you

abstract

As a regular engineer and OSS maintainer I recorded close to a thousand short videos in the last five years. Why? To better communicate my ideas, explain how something works, and answer questions really clearly. While I love blogging and have been doing it regularly for ten years, a short video is often worth a thousand words. Videos can be very complementary to the blog posts and other documentation types. In this video, I can show that creating solid and useful videos does not take much time, if you get your process right.

Description

I will cover what topics are better covered by recording a video (screen recording plus the talking head) compared to Markdown / Blog post / documentation site. I will show how to create a video really quickly that looks good, how to make sure the users find it, and how it can further one's professional career.

The future belongs to you (and your JavaScript)

abstract

There are a few web frameworks that are all the rage right now: React, VueJs, but which frameworks are going to be HOT tomorrow and why? I will talk about functional reactive web applications you can write today, and why they are going to rock tomorrow. We are going to touch upon offline applications (using ServiceWorkers) and why some databases are better than others. Plus I will show how a testing trapezoid is going to save your career. Finally, we need to sit down to have a real talk about Dev Ops; if immutable data structures help you code better apps, then immutable artifacts and deploys are going to change your entire pipeline.

Testing presentations

TDD Calculator Using Cypress E2E Tests

abstract

Let's code a simple calculator web app using a test-driven development approach. For each feature, we will write an end-to-end Cypress test first. In this talk, I will show how to:

  • test and code the main UI features
  • test color and a11y
  • collect and report code coverage to guide tests
  • set up continuous integration using GitHub Actions

This presentation is based on my online course "TDD Calculator" https://cypress.tips/courses/tdd-calculator and blog posts like https://glebbahmutov.com/blog/code-coverage-on-the-fly/ Every developer and tester would benefit from seeing how end-to-end tests can provide rapid feedback and accelerate developing web applications

Running A Thousand End-to-End Cypress Tests Every Day

abstract

In this talk, I show how we run a lot of full end-to-end Cypress web application tests every day. In addition to running the full data set, we do separate feature test runs based on test tags. We also allow everyone from all teams to trigger the tests right from GitHub Actions UI. This lets every group quickly test their feature before merging into the main branch. For pull requests, we employ source code analysis based on data test IDs to run the affected tests first for quicker feedback. The software automation team uses the flake test information to chase the sources of the underlying errors to minimize noise and make every passing test run give us confidence in the released code, and every failing test run useful to quickly diagnose the real underlying issue. The presentation covers test writing, test organization, selecting tests to run based on the source code changes, running tests in different resolutions. I also look into making the tests faster by employing data creation and caching, as well as using API calls to bypass the user interface in some places. Finally, making the tests robust and flake-free and triaging the failed runs is an ongoing activity for the automation team.

Writing Cypress Tests Using GitHub Copilot

abstract

I want to show you the secret weapon I have been using for the past year. The GitHub Copilot lets me write full tests quickly, fills the gaps in my knowledge of 3rd party tools, and even writes clear descriptive commit messages. But it is not a "press the button to do it all". You need to guide the AI to do the right thing, which takes experience, but most importantly, you need to decide what you want the AI to do, step by step.

GitHub Copilot is really two main tools: there is an inline editor helper that suggests a piece of code based on the current code, the present code comments, and context. I will show you how to get better code suggestions for your end-to-end tests. Copilot also has a Chat companion mode that is like your personal very knowledgeable coding partner. Chat can answer your questions and show relevant code snippets right in your VSCode editor. The chat is ideal for looking up the right terminal commands, or writing short algorithms, or even looking up web platform docs.

Remember: AI is not going to replace you any time soon. But someone being a lot more productive with AI's help might get ahead. Let's learn Copilot for real-world test writing. It might change how you work. If you master it, Copilot becomes your super weapon. It is like playing Super Mario - in some games, you can dash quickly by pressing the "Y" button, but you need to be pointing in the right direction first.

details

I have shown this presentation to very high audience feedback, find slides at https://slides.com/bahmutov/writing-tests-using-github-copilot

Cypress vs Playwright With Examples

abstract

Cypress and Playwright are two of the most popular tools for writing end-to-end and component web application tests. In this presentation you will see how both tools control the browser and simulate human user actions. I will show where each tool shines and provides the best solution to real-world situations.

description

We are truly living in the golden age of web testing automation. There are lots of good tools, and this presentation tries to show two of the most powerful tools available today that are both open source, run fast, allow quickly debugging problems, and can do a lot. I am talking about Cypress and Playwright of course. Both tools are capable of great things, but their architectures are very different, and thus they can shine when solving different problems. By showing test code examples you can get a sense of what it takes to write full end-to-end, component, and even API tests. Everyone looking to test their modern web app would benefit from this presentation.

Visual Testing For React Components

abstract

Many modern web frameworks use components as their building blocks. In this talk, I will show component testing using Cypress – and I mean “show” literally. You will see the component running inside a real browser, you will interact with the component like a real user, and you can debug the component using the real browser’s DevTools. Finally, I will go through the current open source and commercial options for visually testing the component’s styles and rendering.

Details in the blog post Visual testing for React components using open source tools

presentations

Snapshot testing

abstract

Snapshot Testing is a recent technique in unit testing and automated testing in general that's been gaining some traction, thanks to a new excellent test runner called Jest. I will show what snapshot testing is, how you could implement this tool yourself, and how to extend this approach to dynamic data with schema testing, and how to remove almost all boilerplate using data-driven testing.

presentations

Good News About End-to-end Testing

abstract

Unit testing is simple, yet it only checks small pieces of code. End-to-end testing of real web applications can potentially find a lot more problems across the entire stack. Yet E2E tests are delegated to the very tip of the testing pyramid - because the tools for controlling a large application inside a real browser are brittle, and the development experience is a mixed bag. In this presentation I will bear some good news about end-to-end testing; in particular, I will demo Cypress.io - an open source, free MIT-licensed test runner that is trying to solve the end-to-end testing problem from a new angle. I will also show how to set up continuous integration pipeline in a few simple steps without pulling your hair.

Effective End to End Testing

abstract

Unit testing is hard and time consuming; and worse - the users and the customers do not care! They only want the features working in the production system, everything else is development overhead. If this is the case, how do we improve the web application quality? How do we catch the bugs early? How can we test the deployed system effectively? And finally, how do we get rid of Selenium? This presentation tries to answer many of these questions in a web framework agnostic way.

Details

As a VP of Engineering at Cypress.io I have front seat to end to end testing for web applications. Currently we are open sourcing our complete testing tool; it is a fast and powerful replacement for Selenium and every other similar tool. In this talk I will show how one can quickly test all features of a modern web app. Cypress design and features were strongly influenced by the unit testing and modern snapshot testing technique and provide fast feedback, full access to the application and great developer experience. The goal of the project is to flip the testing pyramid and allow anyone to write A LOT of useful end-to-end tests really quickly.

More info about Cypress and the decisions behind it available at https://www.cypress.io/ and https://www.cypress.io/blog/.

presentations

Testing across boundaries

abstract

Developers like to test on their local machine. Then the code gets built by CI and things break - missing dependencies, mismatched configuration, different environment. I will show how we effectively test our code when it crosses such boundaries: local to CI, CI to staging, staging to production.

Description

The ultimate "it works on my machine" only happens when the code runs on a different machine. I call these code transitions from local to CI, from CI to staging and from staging to production "crossing the boundary", and believe we must test our code every time a boundary is crossed. Yet we do not work very hard on making the code testable! Worse, we often allow using very different tools to monitor and test production versus CI. In this talk I will walk through a typical web application and all the places we can test it using the same tools, ensuring the bugs are caught early and the production works as expected.

Say "Noroc" to Cypress.io

abstract

In this talk, I will show how to quickly and efficiently test modern web applications using Cypress.io test runner. We will write functional tests, add visual regression testing, stub network calls, control application methods, and even measure code coverage - all without any frustration or anger. Make the world a better place - learn how to write end-to-end tests!

Будущие технологии тестирования: обзор

В этом докладе будут показаны самые последнии идеи для достижения надежного программного обеспечения для веб. От data-coverage (а не code-coverage) в тестах, до тестирования недоступого кода (например внутри private JavaScript closures), от минимизатции boilerplate и до тестирования веб-приложений без помощи браузеров; эти решения помогут быстро и дешево достичь высокий уровень качества.

presentations

  • QAFest, Kiev, Ukraine 2016 slides

Career Advice For The Automation Testers

abstract

Are you looking for a job? Going through a career switch? Thinking about your professional future? In this talk, I will show how you can avoid common mistakes that make the hiring manager say No to your application. And I will show how you can help the hiring manager say Yes. Even if you have little experience, you can still build up your demonstrable skills that make the job search faster and less nerve-racking.

This talk is based on the advice I gave to people looking to improve their testing careers: