From Examples to Exhaustive: Intro to Property-Based Testing

Tired of writing countless test cases, thinking up random examples? Discover how property-based testing can revolutionize your testing process, making it exhaustive with minimal effort. Property-Based Testing generates vast numbers of robust yet simple test cases, automatically -- and if it finds a problem, most tools will narrow it down to the exact edge cases. You will come away equipped with a powerful technique to uncover edge cases and exceptions you never knew existed, while actually writing fewer tests.

Depending on conference preference, this might be done in Elixir, Python, Ruby, JavaScript, or maybe other languages if I have lead time to delve into their tooling.

Agenda:
- Status quo: testing by looking at chosen examples
- The problem with the status quo
- Basic explanation of Property Testing
- Examples

Hire Mutants to Build your Test Suite!

Do you find it daunting to write a test suite for existing code, from scratch?

Even those of us practicing Test-Driven Development sometimes need to do so. Maybe the boss wants to put our little throwaway experiment into production, rather than letting us rewrite it with good practices. Maybe we inherited code without tests. Maybe we even wrote code without tests?!

Fear no more -- a horde of mutants is at our beck and call, to help us!

Come learn how Mutation Testing can help us eat the elephant of test-writing, one bite at a time, making it a far less daunting and stressful experience. (If you aren't already familiar with Mutation Testing, don't worry, I will recap the basic concept.)

The code under test will not be livecoded, but the tests will be.

Agenda:
- Recap of Mutation Testing (MT)
- Explanation of how MT can help build a test suite
- Intro to the fairly simple code to be tested
- Demo:
1: run the MT tool
2: for each function with surviving mutants:
2a: have the audience pick one mutant to kill
2b: have the audience propose a test to kill it
3: repeat from step 1 until no mutants survive
- FAQs

Depending on conference preference, this might be done in Elixir, Python, Ruby, JavaScript, or maybe other languages if I have lead time to delve into their tooling.

Whose Line of Code Is It Anyway?

You might know the game of ping-pong, aka table tennis. You might know pair programming. But have you ever thought of putting them together? No, we don't pass the keyboard by smacking it with a paddle. It's much less violent and more useful than that, as a technique to combine pairing and test-driven development (not really ping-pong) in a fun way.

This talk will demonstrate Ping-Pong Pair Programming, on a problem chosen by the audience, in a language chosen by the audience. If time allows, we will also demonstrate "Smart@$$" Ping-Pong Pair Programming, in which each dev tries to force the other into doing the actual hard work.

I can do this as a normal breakout session, or if you want, I could possibly turn it into a workshop.

Prior knowledge needed: only basic concepts of unit testing, as I will explain TDD and pairing (and ping-pong). Though there are a variety of languages the demo could be done in, all are fairly English-like and should be reasonably understandable to all devs.

Ideally this has two speakers (other one TBD), but I can alternately take a volunteer from the audience, or a series of them.

The concept is language/technology-agnostic, so it could go at an agnostic conf or one centered around any language. If your conference is about a language I don't know, I can probably learn it (and its typical testing tools) at least enough to pair up with someone who does, so I can still do the talk at your conference.

This has been submitted to some conferences, but not yet accepted (nor rejected), let alone performed. I have several potential co-speakers, and even if none of them are available, I could use a volunteer from the audience, or maybe multiple of them.

The rough outline so far:

- Very briefly recap what are ping-pong, pair programming (mentioning test-driven development), and TDD.

- Ask the audience what language they want us to work in, from among those (up to four or so) that my co-speaker and I have in common. (Or if I couldn't recruit a co-speaker, just those I'm ready to do.)

- Ask the audience which of a few different fairly simple functions to code up using this technique, or maybe additional suggestions. Candidates so far include "FizzBuzz response for one number" and "next state of a cell in Conway's Game of Life, given its current state and number of neighbors". We may do multiple if time allows.

- DO IT!

- Recap good/bad parts of that experience.

- If time allows, demonstrate "Smart@$$" Ping-Pong Pair Programming, in which each dev tries to make the other do the "real work", by writing a test that can only be made to pass that way, while also trying to *avoid* doing the "real work" by writing code that passes all tests so far BUT is even simpler.

Tight Genes: Intro to Genetic Algorithms

Yes, that's right, geneTic, not geneRic. Genetic algorithms are shortcuts to "evolve" solutions to hard problems, by mimicking real-world biological evolution. They find a "good enough" solution more quickly than precise calculation or brute-forcing your way through the entire solution space. Their randomness often reveals great solutions that humans probably would never have thought of, such as NASA's twisty ST5 spacecraft antenna, developed by a genetic algorithm in 2006!

This talk will explain the general concept, and then walk through some examples, explaining terms and pointing out tradeoffs and nuances along the way.

You will come away equipped with a powerful technique for solving problems that might otherwise be computationally intractable!

This talk is simple enough that novices can grok it, but it can be useful for devs of all levels.

I have done this talk for several conferences so far, and am scheduled to do more soon. You can see the videos in my playlist at https://www.youtube.com/playlist?list=PLMrm16n64Buag1--3P3xf9KnrH330nrPc .

Agenda:
- What are genetic algorithms?
- Why are they useful?
- Brief history
- Examples of pre-existing usage
- Walkthrough of using it to solve different classic kinds of problems (e.g., knapsack, traveling salesman, and/or others), pointing out terms, tradeoffs, nuances, etc. along the way
- FAQs
- Conclusion/recap
- Q&A

TDD like a Viking: Brewing Mead with JavaScript!

You've probably heard of TDD (Test Driven Development) by now, but do you actually do it? Do you know how? This talk will explain the benefits of TDD, and show you how simple it is to do TDD in JavaScript. (Plus, what mead is and how it's made!)

Join me on the adventure of making some simple calculators, in JavaScript, to plan and blend batches of mead. You will come away much better equipped to write high-quality code, in JavaScript or any other language. (And to brew your own mead! Sorry, I’m not giving out samples.)

This won't be live-coded, but I will show the progress at various stages, including the code, the tests, and the web pages that the JS works on.

Bug Magnets: Booby-Traps in your Code

Have you ever inherited code, made a simple change, had it completely fail to work how you thought it would, and spent hours hunting down a subtle bug in your change? It might not be entirely your own fault! The previous developer may have laid one or more booby-traps for you to step into. (Then again, that may have been "past you"!) This talk will help you spot many kinds of such traps before you trigger them, and avoid laying them yourself.

There is code, so of course each example is in some specific language, but most of the concepts are language-independent. (Though some are more likely in certain languages than others.)

Agenda:
- What's a bug-magnet?
- Famous real-life examples, like Apple's goto-fail
- Other bug-attractive common situations, like complex code, long functions, lack of tests, etc.
- Less well known examples
- Theoretical examples I haven't actually seen
- General advice
- Tools to detect them and maybe suggest alternatives
- Wrapup

Multi-Talking (no, that's not a typo) with Genaver!

Adapting a presentation for different audiences can be a daunting task. You may need to make it longer or shorter, change the language (human and/or programming), include or omit different details, and more. This gets very cumbersome with binary files like from PowerPoint or Keynote. But with any Markdown or HTML based presentation tool, Genaver makes it much easier!

*Genaver* (Gen-A-Ver) is a small piece of JavaScript I wrote, to generate versions of a talk, with pieces chosen on the basis of parameters, and even content constructed from variables. For example, assuming you have actually created and properly tagged the necessary content, it can create a version with the introduction in Japanese, the code in Ruby, and fitting in 45 minutes, or with the introduction in Portuguese, the code in Elixir, and fitting in 30 minutes, just by changing parameters.

It can also be used for other purposes, such as including or excluding JavaScript libraries that soak up resources, substituting a child's name in a letter from Santa Claus / Father Christmas, and much more.

This talk is the story of how that came to be, including finding the need, other options I explored, how I settled on this way, how it works under the hood, where to find it, and how you can use it too.

This is suitable mainly for conferences about kluges, hacks, jury-rigging, workarounds, silliness, and so forth, such as GambiConf.dev, !!Con, or SIGBOVIK. But, it could be useful for other conferences, mainly JS-focused ones and others on creativity in general, just to show some of the fun things you can do with JavaScript. (For geeky values of "fun".) :-)

Agenda:
- Why I needed something like this
- How I came to this implementation
- Walkthrough of the code
- Demos:
* string equality filtering to choose language
* numerical order filtering to choose different explanations
* constructing content from variables to make a URL
- Where to find it, how to use it, other such practical matters
- Conclusion

I have done this at one conference so far, GambiConf 2023 in São Paulo. The video is at https://www.youtube.com/watch?v=CJtFPdvBcj8 -- but it's in Portuguese. :-) (I could certainly translate it to English, or even French, with a bit more lead time.)

At suitable conferences, this would also go well with my "From Audience to Authority: Breaking Into Conference Speaking" talk.

OOP: You Keep Using That Word . . .

Many developers keep using the term "Object Oriented Programmer", but the guy who actually coined it doesn't think it means what they think it means. This talk recaps both sides, compares and contrasts them, and makes recommendations for each based on circumstances.

Agenda:

- Quick recap of what we now call OOP
- Where did that come from?
- Alan Kay coining the term OOP
- What he meant
- Actor Model and other implementations
- What most of us mean by it now
- Advantages and drawbacks of each, re dev, testing, ops, etc.
- Recommendations when to use each
- Summary/Conclusion

ACRUMEN: What IS Software Quality Anyway?!

Without a good definition of software quality, you'll have a tough time achieving it, and if you don't _share_ your definition with someone, you'll have a hard time _convincing_ them that you _have_ achieved it!

This talk introduces ACRUMEN, my simple yet fairly comprehensive definition, that devs of any level can use, with any tech stack, for free. It stands for the idea that software should be Appropriate, Correct, Robust, Usable, Maintainable, and Efficient. (Come to the talk to see what the N stands for!) I will explain why we need a new definition, and how to apply this one, then explore each aspect in turn, including further nuances and immediately useful tips on how to _achieve_ each one.

You will come away better equipped to analyze the quality of anybody's software, give precise feedback on its shortcomings, teach the next generation of developers how to produce high-quality software, and most importantly, improve the quality of your own software.

This is aimed mainly at intermediates because they've realized how important, _yet fuzzy_, software quality is, while juniors usually haven't yet, and seniors have usually already developed their own approach to quality. However, juniors can generally understand the ideas _when pointed out_, and seniors can still benefit from a different point of view. Also, seniors may still be struggling to put their approach into words so as to teach it to any juniors and intermediates they oversee or mentor. Even non-techies will benefit from having a more precise vocabulary to tell us exactly _how_ our software falls short (to put it politely).

I've given this talk before at several conferences and Meetups, and am scheduled to do more soon, including keynoting Voxxed Days CERN. The latest video is at https://www.youtube.com/watch?v=5iJGC01ApSc (from Frontrunners DC 2023).

There is deliberately zero code in this, to emphasize that "code quality" is just a part of the overall picture of "software quality" that I am addressing -- and that the concepts are completely technology-agnostic (unlike some other definitions).

Agenda:
- Why do we need a new definition?
- What’s in this one?
- Basic FAQs: How do we use it, how can we quantify it, and is ACRUMEN always the right order?
- Explore nuances and tips for each aspect in turn
- Further FAQs if time allows, such as other good definitions I've found
- Conclusion
- Q&A

I would like to do this as an inspirational/motivational plenary keynote (and will do so at Voxxed Days CERN), but could also do it as a regular conference session.

Kill All Mutants! (Intro to Mutation Testing)

Would your test suite still pass if the tested code was changed? If so, you probably have gaps in your test suite, unreachable, redundant, or otherwise ineffective code, or both!

Mutation Testing reveals these cases, and provides some guidance about how to fix them. This talk will tell you what mutation testing is, how it works inside, how to use it, where in your process to use it, and its benefits, drawbacks, and history. There will be multiple examples, and a list of tools for many popular languages (and some others).

You will come away equipped with a powerful technique for making sure your test suite is strict and your code is meaningful!

On the submission forms, I usually pick "advanced" level because it's an introduction to an advanced topic. If forms mean the level *within the topic*, it's more introductory.

I have given this talk many times before (including being voted third best talk out of over 70 at Software Quality Days 2024), and am slated to do more soon. You can see videos in my playlist at https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS

I have the code already in Elixir, Python, Ruby, and JavaScript, and with decent lead time I could translate it into other languages. If you don't have a preference, I'll pick whichever is convenient for me at the time.

Agenda:
- What is mutation testing?
- Why isn't test coverage enough?
- What are its pros and cons?
- How does it work (overview *and* details)?
- Simple example (finding and fixing bad test)
- Complex example (finding and fixing bad/missing test)
- Complex example (finding and fixing redundant code)
- FAQs as time allows, such as: history, why is it so CPU/RAM intensive, where to fit it into dev process, why change code in only one way per mutant, can it help assess the quality of single tests, can it help if we don't have tests yet
- Wrapup
- Q&A

Lastly, if your conference has workshops *afterward*, consider having me do this talk *plus* having Markus Schirp do a workshop, at which I can help convey the concepts to the students.

Ruby Gotchas

Rubyists love its Principle of Least Surprise, but Ruby can still be surprising -- not always in a good way.

This talk is about Ruby’s lurking “gotchas”, so that you can avoid being “gotten”. They range from basic differences from most other languages or common sense, to ones that often catch even expert Rubyists. You will come away with an awareness of specific things to watch out for, and a "Spidey-Sense" of some general kinds of things also likely to be dangerous.

This has been done before at some Washington DC area Meetups, but long ago (over a decade), and not yet at conferences.

You can see the old slides at https://bit.ly/RubyGotchas -- but my slide style has changed a lot, and I intend to reformat it into the illustrated story of a new Rubyist encountering many of these gotchas (there won't be time for all of them, and many have been fixed) one by one.

When I did it I only had a couple years of Ruby under my belt, but several longtime Rubyists told me there were things in it that they didn't know about!

Drink like a Chinese Ethiopian Filipino Indian Mayan Xhosa Viking: The History & Making of MEAD!

This talk goes over the origins of mead (as far as anyone really knows, in several places, some not usually associated with it), some of the many varieties (including some bizarre modern ones), and the basic process of modern mead-making on a home scale. You will come away with the knowledge you need to get started making mead to impress your friends at your next Twitch-streamed D&D game, or your next Skyrim game!

This is currently about 40 minutes, and can be trimmed down to about half an hour, or lengthened to about an hour. There are slides, and for performances near me I can bring other visual aids. However, I will probably not be able to give out samples.

The current full title is "Drink Like a Chinese Egyptian Eritrian/Ethiopian Filipino Finnish Greek Indian Lithuanian Mayan Nepalese Polish Welsh Xhosa Viking: the History and Making of MEAD!" :-)

From Audience to Authority: Breaking Into Conference Speaking

Would you like to go up on a stage in front of dozens, maybe hundreds, of people at a conference? (And probably get your ticket paid for, and maybe your travel expenses too?) Does the thought excite you, scare you, or maybe both? Come find out how to figure out a good topic, organize your thoughts into a speech outline, create slides, find images for them, find conferences accepting submissions, craft your submissions, submit them, track them, actually deliver your presentation, and what to do afterward. Before you know it, you’ll be gallivanting all over the world as a speaker… or doing it remotely if that’s your preference.

This is applicable to non-technical conferences, but the vast majority of my conference-speaking experience (but not all!) is at tech ones.

Agenda:
- Why you might want to present at a conference
- Why you might NOT want to
- Very basics of Public Speaking, and some resources
- What's different about *conference* speaking
- Finding a Topic
- Finding Conferences
- Choosing Conferences
- Tracking Your Submissions
- At the Conference
- After the Conference
- FAQs
- Wrapup

At tech conferences, especially JS ones, this would go well with my "Multi-Talking with Genaver" talk.

Why We Prepend

Did you switch from an object-oriented or imperative language, to a functional one, and find it hard to adjust to prepending to lists instead of appending? And wonder why? It all makes sense when you know what's under the hood. This five-minute lightning talk will show you what that is, and why it's done that way.

Tame Two Tedious Tasks Together, with Doctests

Do the examples in your documentation get out of date? Are the examples in your tests hard to understand? Do you wish you could combine them? In some languages, you can! This talk is about doctests, as used in languages such as Python and Elixir, using documents with real tests embedded.

This is intended to be a lightning talk of about ten minutes, for either language. I might be able to chop it down to five if needed, or stretch it out to fifteen or so by including both languages. Maybe even twenty with examples from additional languages, but I think that would get boring.

TWO Weird Tricks: Mutation Testing and Property-Based Testing

Most devs unit-test, if at all, by using a few examples. There are often bugs that these examples won't catch! Mutation testing reveals them by changing the code and checking whether the test suite notices. Property-Based Testing reveals them by automatically generating a thorough set of examples. You will come away equipped with these powerful techniques to easily generate a thorough test, and check whether your test suite is strict.

Available in Elixir, Ruby, Python, and JavaScript.

Drink Like a Geeky Viking: the Nitty-Gritty of Brewing MEAD!

So you know the very _basics_ of making mead. Maybe you can follow a _recipe_. But do you know how to _predict_ how strong and sweet a recipe will yield? (Or reverse it, and _construct_ a recipe for desired strength and sweetness?) The math is surprisingly simple. Do you know what equipment, supplements, and chemicals to use, and why? What to do with the leftover _sludge?_ How to _fix_ a batch with problems -- and when to just toss it instead? How to _carbonate_ your mead? Come find out all this -- and _much_ more! We won't be getting into how _commercial_ meaderies operate, but this will level you up from unsure scrounging newbie to confident well-equipped homebrewer.

This talk is about the geeky details that the shorter version of my main mead talk omits. Basically, Mead 201.

COARSNO: The First Rule of Composition

There is a hierarchy of components, from complete systems down to single characters. This talk is about how each (except of course the bottom layer) should be COARSNO (Composed Of A Reasonably Small Number Of) things from the next layer down. The talk includes examples and reasoning.