DEV Community: Paul Roub

How to Over-Complicate Your First Conference Talk

Paul Roub — Tue, 03 Mar 2020 14:48:04 +0000

In January 2020, I was lucky enough to be selected as a speaker at CodeMash, an annual software development conference in Sandusky, OH. It is a fantastic event which I would highly recommend to anyone.

This was my first time speaking at a conference, so I made things up as I went along. Some things were easier than I expected, some were harder, and some were simply unexpected.

The First Easy Part: Deciding to Speak

Why did I want to do this now? Honestly, I’d always had it in the back of my mind as something that might be fun — and, just maybe, something I’d be good at. I’m passionate about code, tools, strategies – systems, really. How we do what we do, why we do it, how we can do better. I’m comfortable enough in front of an audience, and (to my co-workers’ occasional dismay) perfectly capable of going on (and on) about a topic. And I love teaching; wrapping something interesting and useful up in a story, helping someone get it the way that I get it, hopefully passing along my excitement.

There were two catalysts for the talk I gave.

During our hiring round last year, I had some great conversations with people who were less-familiar with Test-Driven Development (TDD). I found that I loved walking through the core concepts, and that I had an easy time explaining why I loved to work this way.
While listening to two developers I admire on one of my favorite podcasts, talking about all the reasons they were certain TDD just wasn’t for them, I had quite a “someone is wrong on the internet” moment.

So I thought a “TDD for Skeptics”-type talk might be useful. And very likely fun.

The Second Easy Part: Submitting

I’d been aware of CodeMash for a while, but hadn’t yet attended. It seemed like this talk might fit CodeMash’s relaxed-yet-incredibly-professional vibe.

I submitted my abstract:

For the skeptical: Both new and more-seasoned devs -- especially solo practitioners -- can have a lot of misconceptions about TDD. Mostly of the "it's extra work, it's extra code, I can't ship tests, why would I test something simple and obvious" variety. But magic happens when the light bulb switches to "on".

Walk through the design of a simple-enough class, showing along the way how initial assumptions are often wrong; how to avoid making those assumptions too early; throw away less code; and feel comfortable and safe when you do throw away code.

I was a bit surprised that those two paragraphs were all that was required. I’ve since learned that this is typical of most conference submissions, which makes sense in retrospect: the organizers have to wade through a lot of submissions, and they need to see an idea that comes across as interesting enough to attract an audience. The submission abstract becomes the conference session abstract.

I waited a couple of months (as expected), trying not to worry about the outcome too much. The email came...

They said “yes”!

The Appropriately-Difficult Part: Writing the Talk

I had a few rules in mind before I started, gained from watching many other technical presentations (live and in YouTube form):

A complete program, even a toy one, is going to make more sense to an audience than snippets of some larger, unseen “real” application
Don’t. Read. The. Slides.
I wanted to show the progress of the test/code/refactor cycle in something like real time, but didn’t want to actually code live in the room. Typos are not interesting.
I wanted to address real concerns/objections to TDD, not straw men. This talk would be aimed at intelligent people who didn’t necessarily see things the way I did. My job was to demonstrate my point of view.

I had a list of objections I’d heard and felt I could counter. I needed to be sure I hit all of those points.

I wanted the talk to have a natural flow -- natural to me, that is, so I could speak comfortably. On a long drive, I “wrote” a first draft by dictating to my phone, explaining to an imaginary friend why they should reconsider their objections to TDD. I used almost none of this in the actual materials, but it helped me get the “shape” or flow of the talk straight. Another benefit of an on-the-fly draft like that is that I had no attachment to it; I knew it would mostly be thrown away, so I could just talk without worrying if it was good enough.

I also did a “draft” of the demo project itself. My plan was to capture the final project step-by-step in Git commits; but I didn’t want it to be too aimless. So I worked through the same problem in another language (Python) ahead of time, to convince myself it was the right size for the talk, while keeping the final demo project “real” -- mistakes and all.

Then, I really did sit down and solve the problem in JavaScript, refactoring and changing course along the way. I made sure to use meaningful, narrative comments as I went.

I then used those comments, and the code changes they accompanied, to build the flow of the demo slides. I literally went through the changes, adding slides when something interesting or novel had been done. “Here’s where I refactored for the first time”, “here’s where I knock off a bunch of corner cases in a row”, and so on. I left notes that just mentioned the key points, the reason, for each slide.

And now I had a first draft.

Self-Imposed Roadblock #1: Writing My Own Presentation Software

Writing your own slide-presentation app is a bad idea, even if you really want that one extra feature. Anyway, here’s the thing I cobbled together to deliver my #CodeMash presentation. Do as I say, not as I do (or at least do it better). https://t.co/mXAptK7uqL
— Paul Roub (@paulroub ) February 6, 2020

To be clear, this wasn’t just for fun. As part of my presentation I wanted to show test failures — and subsequent successes — live, as I went through the slides. So of course, I wrote a whole web app that served up the presentation; showed my notes in another window; and performed Git checkouts behind-the-scenes.

As detailed above, I recorded each step of the process in Git. This allowed me to replay those steps in as fine detail as I liked. I expected that I would be flipping from the slides to a terminal window running tests constantly.

In actuality, I think I ran the live tests three times during the actual presentation. Static content would probably have sufficed.

In hindsight, there was probably an element of procrasti-working at play. Writing a talk: unfamiliar and uncertain. Writing code: comfortable and immediately rewarding. And still, technically, making progress towards the task at hand! One could argue that time might have been spent more effectively working on the slides themselves.

It was still fun to write, though. And I’ll use it again the next time I give this talk.

Self-Imposed Roadblock #2: Failing to Ask for Help

You know that terrible interview cliché, “What are your greatest weaknesses”? In my case, the one that leaps to mind is my tendency to want to handle things myself and not bother anyone. I don’t think this is unusual in our profession.

CodeMash has a wonderful speaker-mentorship program, wherein experienced speakers offer advice/feedback/etc. to first-time speakers. I’m no fool, I signed right up for that! And then… never used it. Bob and Russell, thank you for your kind offer to help. I really wish I’d taken advantage of it.

I also work with a great team who were more than happy to look things over ahead of time. Again, I didn’t give them the chance. They’ve given great feedback after seeing the video of my talk, and that will be great in March when I give an updated version of the talk at Orlando Code Camp; I regret not having those improvements baked in the first time.

Complications I’ll Try to Avoid Repeating

Re-(re-)writing

I rewrote too many slides, too many times. That time would certainly have been better spent practicing the actual delivery a few more times, or attending another session, or maybe playing in the water park. (CodeMash is at the Kalahari Resort, which has a water park. Like I said, I recommend the daylights out of this conference)

I also tried to write in the hotel room for the first day, which I’ve found just doesn’t work well for me. There was a perfectly nice speaker’s lounge, and once I migrated there, everything was much more focused and easy. Your mileage may vary.

My rewrite-obsession also led me to miss a speaker get-together early in the week. I really regret this; there’s a lot to learn from talking to fellow presenters (seasoned and new).

Cutting Travel Time Too Close

I’d booked a return flight for Friday night, the last day of the conference. The flight was at 8pm, the conference ended at 5, it seemed like just enough time. I’d miss the closing ceremonies, but that seemed like a small price to get home sooner.

Then, a month before the conference, the flight schedule was changed. 7:15pm. No later options that didn’t involve overnight stays in some far-flung airport. “Well,” I thought, “as long as my talk isn’t scheduled for the last slot on Friday, I can leave early and make the flight.”

A week later, the conference schedule was published. Guess what?

I was able to add a night and re-book for the following morning’s flight, but all-in-all really wish I’d just done it that way in the first place. Cutting travel close, in the winter, in northeast Ohio, is a crap shoot anyway. I should know - I learned to drive in the northeast Ohio winter.

Complications Which I Do Not Regret At All

MacGyver-ing a Test Setup

To get a feel for the slides on a big-ish screen, separate from the laptop, I HDMI-ed my way into the hotel TV and rigged a podium.

As one does.

Venturing Out and Making Music

I grew up in the Cleveland area, about an hour from the conference. I couldn’t resist finding a way to meet up with some old friends; and whenever possible, I’m inclined to find a way to be on stage with a guitar.

So I got in touch with the gentleman who runs a songwriters’ night at a Cleveland lounge, and booked myself a slot well in advance. This did mean I missed the CodeMash Lightning Talks, which was regrettable. But in the midst of four solid days of sessions and rewrites, getting out was worth it (even if it meant getting to sleep well after 1am).

Temporary Guitar Ownership

Oh, about that guitar. While I borrowed the host’s for the actual performance, I wanted to have one in the hotel room. 5 days is a long stretch to be without, after a lifetime of habitual noodling. Traveling with a guitar is expensive and risky, so I rolled the dice and visited a pawn shop halfway between the airport and the hotel.

The little old Epi stayed in tune, played easily, and sounded fine. Basically an $8-a-day rental.

At breakfast on the last day, I mentioned the guitar (and my desire to give it away) to a couple in attendance, who mentioned that their son was learning to play. We decided to meet up after the closing ceremonies.

When the evening came, it turned out that one of these nice folks was having dinner with friends in the hotel restaurant, and I was welcome to join. The entire crew turned out to be speakers and/or conference organizers; I had a great dinner, and made up for the missed connections earlier in the week.

The Best Part

The talk itself was a blur and a blast.

I hoped there would be, I don’t know, 20 attendees? There were over 100. Almost all of them stayed, and I got heartwarming feedback immediately after, and later on Twitter and via the conference ratings.

I hoped I wouldn’t be stressed and miserable. Turns out? I loved it.

Going in, I was worried that I’d run short; run long; read the slides; stumble over topics; be bored; or be nervous. I didn’t know what to expect from myself in this situation, no matter what I’d watched anyone else do.

These concerns ended up fading away due, I think, to a number of factors:

I was genuinely excited to talk about the material. This is a huge advantage you have when you’re giving a talk of your own choosing.
I purposely kept the slides, and even my notes, terse. “Reading the slides” just wouldn’t work even if I’d been so inclined.
I’m naturally self-deprecating and dad-joke-y, and included that in the presentation. “Let’s all laugh with me” has anti-nervous effects.
CodeMash had a helper/prompter in the front row, who’d let me know when I was close to running out of time.
I hadn’t practiced as much as I’d like, but I had practiced. And all that rewriting had me very familiar with the flow of the slides.

I’m already keeping a list of possible topics to submit next year, and I’m watching for other Calls For Proposals along the way.

The Takeaways

I went about this somewhat instinctively. Some of those instincts served me well. Others, hopefully, will be tempered next time. If I had to do this again, I would apply:

More people. Feedback from friends, advice from mentors, discussion with fellow presenters -- the talk and the week would have benefited.
More rehearsal. Once I really, actually, no kidding, presented the talk out loud to an empty room, two things happened: I made a number of helpful changes to the talk, and I realized I didn’t feel nearly as silly as I’d feared.
More downtime during the conference. Which would have been possible with…
Less last-minute re-writing, which would have been helped by…
Earlier rehearsal. Don’t wait until conference week, kids.
The Same level of excitement. Bored speakers == bored audiences. Talk about something you have a hard time not talking about.
The Same first-draft process. A throwaway draft is the enemy of writer’s block (at least in my case).

Think you have a talk to give? Write it up. Submit it. Rejection is survivable, and you’ll have learned something for the next time. And if it went this well despite all of my twists and turns, imagine the relative ease and satisfaction a sensible approach might bring.

Oh, and if you want to watch the actual talk, Pluralsight and CodeMash have made all this year’s talks available for free, here, including this one:

Matching form posts in the Pretenders mock HTTP server

Paul Roub — Tue, 28 Jan 2020 20:47:29 +0000

I've used the Pretenders "Fake servers for testing" on a number of work and personal projects, with generally good results. But I've wished that it was easier to write tests against different HTML form post contents.

Pretenders can return results based on specific URLs (of course), HTTP headers, query string parameters, body contents, and so on. But if that body is the result of a form? You'd better know:

If it was sent url-encoded or multipart
In what order the fields will be arriving

And be willing to deal with those specifically via RegEx matches.

But I don't want to care about those things. I want to say "here are the form fields and values I'm expecting, respond if you see them."

I'd submit a feature request if the project wasn't borderline abandonware¹. But hey, that's why we use open source tools, no?

In my fork at github.com/paulroub/pretenders/tree/match-form-data, I've added an optional data parameter to the when() method. It takes a dictionary, e.g.

http_mock.when('POST /hello', data={'one': 'first', 'two': 'second'}).reply(b'First and Second passed', times=FOREVER)

This will match when a form is posted to /hello, and fields "one" and "two" have the expected values. It does not care in what order those fields were passed, nor which encoding method was used to submit the form.

I've submitted a pull request, but since the project was last touched in 2017 I'm not overly optimistic. In the meantime, you can use the forked version directly, either by saying:

pip install 'git+https://github.com/paulroub/pretenders.git@match-form-data#egg=pretenders'

or by including

git+https://github.com/paulroub/pretenders.git@match-form-data#egg=pretenders

in your requirements.txt file.

The fork currently has a userbase of "me", so comments, suggestions, and bug fixes are even more welcome than usual.

If you're starting a new project, I'd look at alternatives; mockttp is nice, for example. ↩

Responsive calendar layout with flexbox

Paul Roub — Tue, 28 Jan 2020 20:45:27 +0000

For the better part of two decades, I've been running openmikes.org, a directory of open mikes¹, jam nights, etc. across the US and Canada. As with many hobby sites, especially of this vintage, it's showing its age.

I was particularly annoyed with the calendar page. Although it's probably the worst way to display this data in terms of scannability and useful-information density, it's also the most popular. I've tried killing it, I've tried hiding it... either way, I get complaints.

But there's no longer any excuse to display a squished desktop calendar on mobile devices. I wanted to restructure the layout so that it would collapse to a list on narrower screens. But the old code was a mess - all sorts of "off day" padding logic to place the first day of the month on the right day of the week (in the table I was using for layout), empty days that really shouldn't show up in a list view, etc.

I took a first cut at a new layout using CSS Grid, but a small percentage of my users are still on IE 10 or 11. No real grid support, and this layout includes corner cases that the polyfills can't handle. So, Flexbox it is.

My goals:

I wanted to keep the HTML simple, and let CSS do the heavy lifting (with some math help from SASS)
JavaScript shouldn't be necessary
I wanted to start the calendar HTML off on the 1st of the month, with no "padding" cells
No fill-out-the-week padding at the end of the month, either.

What I was willing to include in the HTML:

Each day's "cell" has a "calday" class.
Each cell is also tagged with its day of the week, so we have class="calday sunday", class="calday monday", etc.
Days with no events also get an "emptyday" class.
Days that have already passed get a "calpast" class

The first few days of February 2019, therefore, might look like this:

<div class="calheader">
  <div class="calday">Sunday</div>
  <div class="calday">Monday</div>
  <div class="calday">Tuesday</div>
  <div class="calday">Wednesday</div>
  <div class="calday">Thursday</div>
  <div class="calday">Friday</div>
  <div class="calday">Saturday</div>
</div>
<div class="calendar" id="calendar">
  <div class="calday friday"><span class="caldate">1</span>
    <ul>
      <li>words</li>
      <li>words</li>
      <li>words</li>
    </ul>
  </div>
  <div class="calday saturday"><span class="caldate">2</span>
    <ul>
      <li>words</li>
      <li>words</li>
      <li>words</li>
      <li>words</li>
    </ul>
  </div>
  <div class="calday sunday emptyday"><span class="caldate">3</span>
    <ul></ul>
  </div>
  <div class="calday monday"><span class="caldate">4</span>
    <ul>
      <li>words</li>
      <li>words</li>
      <li>words</li>
    </ul>
  </div>
  <!-- and so on -->
</div>

Going mobile-first, we:

Let each day take 100% width
Hide "emptyday" and "calpast" cells
Hide the "calheader" section which labels the day-of-week columns in full-sized views.

.calheader,
.calpast,
.emptyday {
  display: none;
}

.calday {
  width: 100%;
}

That's the default view in this CodePen:

On wider screens (at least 55em, adjustable via the $calbreak SASS variable), we:

Bring the "calheader" section back
Restore empty days and past days
Set each calendar day to 1/7th of the available width
Use Flexbox layout in the calendar and its header

$cellwidth: (100% / 7);
$calbreak: 55em;

$cellwidth:
@media screen and (min-width: $calbreak) {
  .calendar,
  .calheader {
    display: flex;
    flex-flow: row wrap;
    justify-content: space-around;
  }

  .calpast,
  .emptyday {
    display: block;
  }

  .calday {
    width: $cellwidth;
  }
}

(SASS is not strictly necessary here, but I'd rather let the tool do the calculations for me, for correctness and readability's sake)

If that's all we did, every month would start in the first column -- i.e. every month would start on Sunday. Historically, I'd either add empty cells before the first of the month (1 for Monday, 2 for Tuesday, etc.), and perhaps something similar at the end to maintain the last week's cell spacing. That's annoying, and adds more junk that we need to hide in mobile views.

So each cell also gets a "sunday", "monday", etc. class. And we let CSS (again, via SASS) do something special with that information:

@mixin day($dayOfWeek) {
  @media screen and (min-width: $calbreak) {
    &:first-child {
      margin-left: ($cellwidth * ($dayOfWeek - 1));
    }

    &:last-child {
      margin-right: ($cellwidth * (7 - $dayOfWeek));
    }
  }
}

.sunday {
  @include day(1);
}
.monday {
  @include day(2);
}
.tuesday {
  @include day(3);
}
.wednesday {
  @include day(4);
}
.thursday {
  @include day(5);
}
.friday {
  @include day(6);
}
.saturday {
  @include day(7);
}

Assume the first day of the month is on a Tuesday. That "tuesday" class compiles to:

@media screen and (min-width: 55em) {
  .tuesday:first-child {
    margin-left: 28.5714285714%;
  }
  .tuesday:last-child {
    margin-right: 57.1428571429%;
  }
}

Meaning: on wide-enough displays, if this Tuesday is the first day in the list (i.e. the first day of the month), add a left margin of 2/7th of the screen — the same as two calendar cells.

Similarly, if the last day of the month is a Tuesday, right-pad it with 4-cells' width of space.

Now:

Each week will span exactly one row (because each cell is 1/7th of the width)
Flexbox will keep the heights of the cells in a row the same, without any extra CSS needed
Our list will start in the correct column.

You can reduce the size of the preview in the above CodePen, or view it full size to see this more clearly. Resize the window to watch the break happen.

The JavaScript in the CodePen is there to fill out the calendar for a given month, with semi-random content, and add the appropriate classes so you can see — for example — the lack of empty days in mobile view.

Feedback, suggestions, improvements are very much welcome.

"Um, actually, it's 'mic'". Oh, thanks. You may be surprised to find this has come up before. ↩