Forem: Ted M. Young

Remote Learning Ensembles (Mob Programming)

Ted M. Young — Sat, 15 Jan 2022 21:14:31 +0000

See updated version of this article here.

2022-03-22: Updates since I first wrote this can be found as bracketed & italic remarks inline.

How I Run Remote Learning Ensembles

The Ensemble (mob) Programming sessions that I've been running for the past few months are centered around improving developer skills in test-driven development (TDD), domain-driven design (DDD), and Hexagonal Architecture, with a focus on taking small, safe steps and frequent refactoring. Since the codebase is Java, it's turned out that all attendees are using IntelliJ IDEA, so an additional focus has been learning its shortcuts and the less common automated refactorings (such as Move Method).

Since the focus is on learning skills and not getting "work" done, I stay out of the rotation, observing and providing guidance and advice along the way. I also serve as the "customer" providing direction on the features being developed. [However, if there's only 2 attendees, I'll drop into the rotation.]

Below you'll find information on how I currently run the Learning Ensembles (much of this was gathered from various sources, some adapted, and some learned by trial and error).

I've found that using GitHub-based hand-offs, with the awesome command-line tool mob.sh, to work better than other mechanisms that I've tried. It allows people to use their own computer and IDE, which means they're not only comfortable using tools that they're used to, but building skills (such as shortcut keys) in their "natural" environment. The downside is that there's a bit of disruption during the hand-off, mainly around the new Driver taking over and possibly having to rearrange editor windows and open up files, though this tends to be less of a problem after a complete cycle of turns.

Roles

We call the person at the keyboard (and sharing their screen) the "Driver" and the person directing them the "Navigator". I've gone back and forth about the role names (e.g., typist, director), and have found that metaphor of getting to a destination with a "Driver" and "Navigator" to be well-suited.

Driver

When starting your turn, clearly state that you're ready for the Navigator with an "I'm Ready". This is needed so the Driver can do the mob start command (to get the latest code on their machine) and arrange the IDE windows as needed. [We've standardized on a split screen, with the test code on the left, feature code on the right.]
Driver carries out the Navigator's intent—there is only one Navigator, otherwise the Driver can get confused.
If the Driver is unsure what to do next, they ask the Navigator for clarification.
- It's often helpful for the Driver to offer choices "do you want me to extract the whole block, or just line 24?"
Avoid "Runaway Driver" where the Driver does more than (or different things from) what was asked.

Navigator

Declares intent at the highest level, only providing more detail if the Driver asks.
- Start with intent: "extract the loop to a new method named Process Transactions"
- Provide more detail: "select lines 24 thru 28, use Refactor then Extract Method.
- Even more detail: "click on the word 'for' on line 24, press the expand selection key a few times, now click on..."
Avoid micro-managing ("backseat driving") the fixing of syntax errors or typos.
It's important that the Navigator correct the Driver if the Driver didn't do what was desired, due to either confusion by the Driver, or a mistake by the Navigator.
- Communication is hard, and the only way a Navigator knows that they were understood is if the Driver did what was desired.
When the turn is over, inform the next Navigator of what you had in mind. However, it's up to that Navigator to either continue down that road, or try something else.

Onboarding New Participants

Get their GitHub username
- Add the username as collaborator to the repository that will be used for the Ensemble
- They'll need to accept the invite, so do this enough in advance
Participants will need to install and verify that these work:
- The mob.sh tool (which requires git)
- Zoom, especially share screen privileges
  - Do audio check, video check is optional
- Whatever IDE they're comfortable with
  - Increase font size of IDE to at least 16px for screen sharing readability (sometimes 18px is needed!)
- Correct version of Java (11 or later)
- Clone the repository via SSH if possible (this makes it easier to push)
- Build and run all of the tests
- Do a test mob start and mob next to ensure privileges are set up correctly

Facilitator Preparation

Fill out names in the Mob timer
- We use https://mobti.me
- Make sure to rotate so folks aren't always in the same order or are navigating the same driver
Verify participants have accepted GitHub repo invitations
Verify repository has the latest code (all changes since last session pushed)
Review retrospective and Mission notes from prior sessions
- I keep these notes in the same repository as the project code
Ensure goals (I called this the "Mission") for the upcoming session are clear
Send a link to the Zoom that we'll be using (even if it's the same one, people like/need the reminder)
- [I use my Ensembler tool to handle this: see https://github.com/jitterted/mobreg for more.]

The Session

This is based on my experience with 90-105 minute-long sessions [I've found 105-115 minutes—just under 2 hours—better for groups that only get together once a week, or less, in order to remember and/or understand the context]. We cap the size to 5 active participants, with turn times of 5 minutes each.

We have two main roles: Driver and Navigator (as described above). When the turn is over (after the 5-minute timer has expired), the Navigator becomes the new Driver and the Driver goes back into the general crowd. [We now go the other way: Driver becomes Navigator, and Navigator returns to the crowd, as the Driver has the code already in their head/fingers.]

The Huddle

[Added details on The Huddle]

The starting Huddle is a way for the group to sync up and understand where things are and what the next task is. This is important as people haven't seen the code for a week or more (or never!). Once the first Navigator agrees that they have a sense of what to do, the Huddle ends.

During the Ensemble, people can get lost, can disagree on which way to go, etc., and so anyone can call for a Huddle. The timer is stopped and discussion starts. It's important to get back to the code, so if the discussion becomes too detailed (or too abstract!), it's time to see if there's enough understanding to take the next step, without worrying about the steps after that. As the saying goes, "discuss in code" (i.e., writing actual code) is better at demonstrating what approach is better/worse than just talking about it.

Agenda

Introduce anyone who's new
Provide the mob timer link (if a separate one like mobti.me is used)
Remind folks of any Code of Conduct
- At a minimum, remind them that this is a learning experience and to be compassionate and curious
Create (or update) a participants.txt file with the date and start a list with the facilitator's name as the 0th entry. For example:
```
Session #10 - Friday, May 28, 2021
----------------------------------
0. Ted (@JitterTed)
```

[I stopped putting my name as facilitator, and now it starts with the first participant. Twitter name is optional.]

Do one rotation by having each participant do the steps below when it's their turn. The purpose of this exercise it to ensure everyone can share their screen, update their local copy of the repo, and push changes to the repo, as well as an check of their audio and font size. Doing it at the beginning means that it won't interrupt the Ensemble's flow:
1. Share their screen (I make sure that Zoom allows participants to "steal" the screen sharing from the current sharer)
2. Execute a mob start, once it completes...
3. Type their name in the participants.txt file (if it doesn't show up, or is missing other participants, you know something's not quite right), e.g.:
```
   Participants from Ensemble #50 on March 4, 2022
   -----------------------------------------------
   1. Hoffman
   2. Moxie
```
1. Execute a mob next and once it completes...
2. Announce "Ready for next DRIVER"
3. Next driver takes over and repeats from step 1 until everyone has had a turn
Explain/review the mission for the session
- I keep this in a text file in the same repository as the project code
The Team does a "huddle", where they discuss the mission, make sure they understand it, and define the next task or two.
The first Driver shares their screen, does a "mob start" and when complete declares "I'm ready"

[Usually they'll start by running all the tests]
The Navigator provides instructions to the Driver
When the turn is over (the timer has gone off), the Navigator relays their intent (what they were trying to achieve) to the next Navigator

[If the Navigator/Driver are almost done with a task, I'll usually let them finish it before moving to the next person.]
Things that need to be done (delete that test, rename that class, fix that flaky test) are dropped into chat
Side-comments about the work are also dropped into chat
After each full cycle (everyone has taken their turn once), the facilitator runs a "mini-retrospective", if the ensemble feels that things are in a good flow, the mini-retro can be skipped.
- Often the 2nd time around, folks feel the need to mini-retro to regroup and gain perspective.
[With a more experienced group, I've not found this necessary, as folks seem to learn to call for a Huddle as needed]
The final turn ends when there's 15-20 minutes left in the scheduled ensemble time.
Conclude with a retrospective, where each person in the rotation provides thoughts, observations, things they learn, etc., until everyone has run out of things to say. Then, things to do more or less of, what went well/not so well, etc., are noted in an outline or mind map.
Facilitator shares observations (the more specific and concrete, the better), such as "I noticed it took 3 turns to finally get from red to green" or questions, such as "how did it feel to leave have that test continue to be flaky", or "was anyone uncomfortable with the poor code formatting in that method?"
Session ends with cleaning up of the pending tasks, collecting undone ones from chat, checking off those that are done, etc.
Everyone waves goodbye!

Note that we have changed how we run the Ensembles over time, because of things brought up in our Retrospectives. I'll follow up with a post on what's changed since the above was written. One non-trivial change was the order of Driver-Navigator. When we swapped that order, we found less of a need to "hand off" intentions.

Stay tuned!

My Favorite IntelliJ IDEA Plugins

Ted M. Young — Wed, 21 Apr 2021 23:30:28 +0000

As an instructor and experienced IntelliJ IDEA user (some might say fanatic), I'm often asked about the plugins that I use. To be honest, I don't use a lot of plugins, I find myself mostly focused on improving the quality and testability of code by using IntelliJ IDEA's powerful automated refactorings, along with its Live Template and Postfix features. However, there are some very useful plugins that are "standard equipment" for me when I install it on a new machine. Note that I use many of the built-in plugins from JetBrains that I'm not including in this list.

Git

For better or worse (I think worse, but that's a separate rant), Git is the de facto standard for version control. IntelliJ IDEA's support for Git is great, but the plugin GitToolBox makes it even better. I rarely find myself using Git from the command line anymore, which I'm very happy about.

PlantUML

I love drawing diagrams, but I hate using visual drawing tools, because I spend so much time fiddling with the little things. I've been using PlantUML for years to draw sequence, class, and state machine diagrams by describing it in a text file. Having it as a plugin in IntelliJ IDEA makes it that much more valuable.

Presentation Assistant

Pretty much what it says in its description: "shows name and Win/Mac shortcuts of any action you invoke". As an instructor and live coder, I always have this installed and activated. I like how it shows both the Mac shortcuts (I use a Mac) as well as the Windows & Linux shortcuts so those who are watching can learn the shortcuts for their platform. It's also helpful when I'm writing how to use the shortcuts since I don't have to search for the shortcuts for the other platforms, I just hit the keys and Presentation Assistant shows me the keys for Windows/Linux.

Floobits

The holy grail of synchronous editing of a project by multiple people has not quite been solved, but of the tools I've tried out (Floobits, CodeTogether, Code With Me, and GitDuck), Floobits has come closest to what I want: the ability to use the full power of IntelliJ IDEA, and let the other people use whatever tool they want. It's not perfect and sometimes things get out of sync or just don't sync in the first place, but when it works, it's great. In the Mob Programming groups that I lead, though, I have shifted to using mob.sh as it's much more reliable.

SonarLint

Last and, yes, least, is SonarLint an open-source project. It's not that it's not a powerful tool (it is), it's just that I find myself constantly telling it to stop bugging me about things that I turn it off when teaching, and then forget to turn it back on when I'm just coding. Perhaps some more fine-tuning would get it to the right level of nudging, but I'm not there yet. However, it has saved me from some silly mistakes, so it's worth installing and trying out.

What About You?

What plugins do you find indispensable? Let me know as a comment below, or on Twitter, where I can be found as @JitterTed.

Top Five "Forever" Books for Coders

Ted M. Young — Tue, 16 Jun 2020 00:39:01 +0000

Introduction

On my live coding stream, the question often comes up: "what books would you recommend?" about various topics. Since it's such a common question, I decided to set aside time on my stream to pull together my recommendations and discuss them with my viewers. At first, I was going to write one of those standard "Top 10" lists, but I realized my recommendations are more nuanced than that (and that I have way more than 10 that I want to mention), so I'm dividing the "top" list into several, more focused lists. As we were discussing the book candidates on the stream, I realized there are "classics" that I think are required reading for any coder who wants to really step up their ability to write more maintainable and testable code, so those are the books in this first list: the "Forever" Books.

This list has books that have been around for 15-20 years and will likely apply for 15-20 more. They came out during the "golden" period of 1995-2005 when Design Patterns, Refactoring, and eXtreme Programming broke through and started becoming well-known. Future lists will cover more recent books on developer testing, object-oriented design, and tech-specific books (e.g., Java, Spring framework, etc.).

How to Read

Instead of just listing the books, I provide a recommendation on how I'd read the book, since some of them, like the 883-page xUnit Test Patterns book, are quite large (and heavy if you have the physical book), and you don't need to read every page. Even if they're not that long, not all of these books are meant to be read cover-to-cover and serve as cookbook-like references. These books also have quite a bit of code and I tend to skip over most of that on my first read-through. Unlike most people it seems, I actually enjoy reading the Preface and Introduction chapters of books and since they often provide their own "how to read this book" advice, it's worth taking the extra time to read.

If you can, read these books as part of a Study Group. I was lucky to be part of a group (the Silicon Valley Patterns Group) that met weekly to discuss these books (and many more), chapter by chapter, and followed the patterns described here. We were also lucky enough to get access to the in-progress books (such as WELC and DDD) and provide feedback to the authors.

Disclaimer

This list has affiliate links where I might make a few cents on your purchase, but in addition to the typical Amazon links, I've included links (IndieBound) that would help support local and independent bookstores, without which the world would be a poorer place. I look forward to the day when I can leisurely and casually browse my local bookstores again. If the indie bookstores in your area aren't yet open (e.g., for curb-side pickup or drop-off), you can buy from indie bookstores online by following the link to BookShop.

The Forever List

And now, on to the list! These are my Top 5 "forever" (aka "classic") books that I strongly recommend folks buy and have on their shelf. They are not in any particular order, so I'm not numbering them. Except for eXtreme Programming eXplained, they're not books that are meant to be read linearly all the way through, but contain a catalog of recipes to be slowly learned over time.

"Working Effectively with Legacy Code" by Michael Feathers

This is the book that most people reference when discussing dealing with legacy code, which, let's be honest, is probably all of us. Usually referred to by the initialism WELC.

Read Chapters 1-4
Skip Chapter 5 (Tools)
Read Chapter 6 (I Don't Have Much Time and I Have to Change It)
Skim the rest of the book, that way you're aware of techniques to use when you run into those situations. Or maybe you're already in those situations? If so, read on!

Buy WELC on IndieBound
Buy WELC on Amazon

"xUnit Test Patterns" by Gerard Meszaros

This book's subtitle is "Refactoring Test Code", but I think it's much more than that, as it got me to really think about how I write and structure automated tests.

Read Introduction through Chapter 6. No really, read the Introduction.
Skip Chapter 7 if you know JUnit/xUnit etc.
Skip Chapters 8, 9 on Fixture Management -- I don't think it's as important as other chapters.
Read Chapter 10 for how to verify (assert) -- you might be surprised what you learn from this chapter.
Read Chapter 11 at least twice(!) about "Test Doubles"
- Forget everything you knew about mocks and learn this terminology.
- Eventually this will become second-nature, but if you overuse mocks in your current codebases, learning the different kinds of Test Doubles will help you wean off of them.
Skip Chapters 12-14, unless you're really not sure how to organize your tests. Not that it's not important, it's more that this isn't the main problem that I see in teams that I coach and train.
Skim the rest of the Chapters for Test Code Smells (Chapter 15ff) and Test Strategy Patterns (Chapter 18ff).

Buy xUnit on IndieBound
Buy xUnit on Amazon

"Refactoring: Improving the Design of Existing Code" by Martin Fowler

There are two editions of this book: the First Edition, from 1999, uses Java, whereas the Second Edition came out in 2018 and switched to JavaScript for the code examples (as well as being tailored towards JavaScript idioms, such as using function instead of method). There are obviously more significant changes than just the code, as described by Martin here.

So which edition to buy? If you're not a Java developer, then the Second Edition is what you want. However, if you are a Java developer, then maybe both? The First Edition is available used for around US$15-20 used, and the Second Edition is about US$30, so I don't think that's too much to spend on one of the most valuable books you can get. The First Edition is nice to have available to see the refactorings in a more familiar language, and the Second Edition has improved and updated the "code smells" and principles text.

Read Chapters 1, 2
Skim Chapter 3 (identifies code smells)
Can skip Chapter 4 (Test)
Skim through list of Refactorings (Chapter 6 through to the end) -- this is the refactoring "catalog"

Buy Refactoring 1st Edition on Biblio
Buy Refactoring 1st Edition on Amazon

Buy Refactoring 2nd Edition on IndieBound
Buy Refactoring 2nd Edition on Amazon

"Domain-Driven Design" by Eric Evans

I use the patterns and the principles from this book all the time. If you've ever heard me speak in person or on stream, you'll hear me use terms such as "ubiquitous language" and "context boundary" and "repository pattern" quite a bit. This is not the easiest book to understand, not because it's poorly written, but because there's a lot packed into it, and it's written in a certain Pattern Language style that can take a bit of getting used to. The main point that you should take away is thinking about your applications Domain First (what should the system be doing) instead of Data[base] First (what data are we keeping track of). The more you try to use these concepts and patterns, the more you'll start to see ways of applying them -- it's a virtuous cycle.

Read all the way through
On your second read-through, start with Part IV "Strategic Design" and work your way, Part by Part towards the beginning of the book.

Buy Domain-Driven Design on IndieBound
Buy Domain-Driven Design on Amazon

5. "eXtreme Programming Explained" by Kent Beck

This book (also known as XP Explained) had such a huge impact on the way I, and soon enough the teams I worked with, developed software. The idea of pair programming was mind-blowing for me, and the emphasis on developer testing, something I was doing anyway, was reassuring. The flattening of the "Cost of Change" curve was also surprising as it went against what I had learned about project management of software development projects: earlier is better, later is badder. That assumption is wrong and is the cause of premature flexibility (You Ain't Gonna Need It, aka YAGNI) that makes software less flexible rather than more.

Note: The links are for the 2nd Edition, which is almost a full rewrite of the 1st, but retains the overall thrust of XP:

XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine.

Read the whole thing
Discuss with your colleagues
Read it again
Repeat on a regular basis

Buy eXtreme Programming Explained 2nd Ed. on IndieBound
Buy eXtreme Programming Explained 2nd Ed. on Amazon

Stop Trying to Outsmart the Java Compiler

Ted M. Young — Thu, 23 Jan 2020 17:11:55 +0000

When Java 9 was (finally) released, it was considered a disappointment, or a disaster, depending on who you talked to. Lost among the debates about Project Jigsaw (the Java Module System) was a big improvement to the way strings are concatenated.

When I talk to even seasoned Java coders, many aren't aware of the changes that JEP 280 (JEP is the "Java Enhancement Proposal", part of the process of bringing new features into Java) brought to the world. Unfortunately, the title of that proposal: "Indify String Concatenation" didn't exactly help. (For what it's worth, indify here means using invokedynamic, which doesn't help if you don't know what that means either.)

I'll summarize the changes and benefits, but leave the detailed explanations and performance benchmarks to the experts.

Before Java 9

When you concatenated strings, like this:

String fullName = first + " " + last;

the Java compiler would automatically change it to be:

String fullName = new StringBuilder().append(first).append(" ").append(last).toString();

The idea here is that StringBuilder is generally more performant. The nice thing is, you didn't have to write that StringBuilder code yourself! But what happens in the future when there are new and faster ways to concatenate strings? Do we have to then replace all of our StringBuilders? (For those who remember, we did that with the move from StringBuffer to StringBuilder when we realized that synchronizing everything wasn't a good idea.)

With Java 9 and JEP 280, the compiler doesn't try and pick the best thing (StringBuilder? StringBuffer? Plain concatenation?), it just calls out to a method that the runtime (the JVM) can replace with something optimized for the runtime behavior of the code. Essentially the code above would look like:

String fullName = makeConcatWithConstants(first, last, SPACE_CONSTANT);

(Though that's not exactly right, because there's more going on -- read JEP 280 for the details -- it's close enough for this discussion.)

As Claes Redestad says in the "String Concatenation, redux" post: "optimize the runtime, not the bytecode".

Not For Loops

While the compiler is smart enough to optimize the string concatenation above, if you're in a loop, especially a very large one, you'll need to manually pull the StringBuilder variable outside of the loop and use StringBuilder's .append() method for the concatenation. For example, if you write

    String line = "";
    for (int i = 0; i < 20; i++) {
      line = line + "line (" + i + ")\n";
    }
    System.out.println(line);

Then the compiler will only optimize the concatenation going on inside the loop, which is still not as efficient as the "manual" optimization of pulling the StringBuilder outside the loop, like this:

    StringBuilder lineBuilder = new StringBuilder();
    for (int i = 0; i < 20; i++) {
      lineBuilder.append("line ").append(i).append("\n");
    }
    String line = lineBuilder.toString();

On the other hand, if your loop is guaranteed to be pretty small (like this one, with the constant of 20 lines), then I'd lean towards the more readable + for concatenation than using StringBuilder.

Don't Trust Me and Maybe Not Benchmarks

You can try "micro" benchmarks on the above code (using the JMH tool), but these days there's so many interactions between the runtime JVM, including the garbage collector and optimizer, the operating system, and the chip you're running on that it's difficult to generalize from a micro-benchmark. I'd much rather rely on higher-level measurements, such as load testing, to find bottlenecks. I often tell my Java students that you're much more likely to have slow systems because you're slinging JSON around, because you have to parse and serialize them, than because your string concatenation isn't optimized.

Slower in Java 11?

While all of this (and other things) have resulted in better String concatenation performance (see Heinz Kabutz's presentations linked in the references section), not everything has been smooth. It turns out there is a performance regression (unresolved when I wrote this) in Java 11.0.2 where string concatenation might be a bit slower. See this bug for details.

References:

Live Coding Learnings - June 21, 2019

Ted M. Young — Sun, 23 Jun 2019 22:31:14 +0000

Quizdown: Episode 20

The 20th episode of working on Quizdown, a Java+Spring-based app that uses a Markdown-like syntax to create coding quizzes.

Stories Implemented

After a non-trivial refactoring (see No Naked Data Structures below),
I now have the ability to move back and forth between questions. The HTML generation now generates checked if that choice was previously selected. Next step is to load the user's responses from the database and send that to the UI controller.

HTML: Use disabled Attribute for Button or Link

When I was looking for the proper CSS class to use to display a button as disabled, I found that instead of using, say, an is-disabled CSS class, HTML supports disabled as an attribute on both button and link (<a>). For example, to show the link as disabled instead of:

<a class="is-disabled" href="/question/0">Previous Question</a>

you would use the disabled attribute like this:

<a href="/question/0" disabled>Previous Question</a>

No Naked Data Structures

One of my Java design heuristics is No Naked Data Structures, which means wrapping raw data structures (List, Map, etc.) in a type so you can pass it around and interact with it in a way that makes sense from a domain point of view.

This is similar to the No Stringly-Typed Code heuristic: don't use String everywhere, instead use class and interface types. For details see here and here.

When adding the feature to allow users to go back and forth through the questions, I needed to have the choices that the user made be available. Previously I was storing those choices as a Set<String>, as it was straightforward and it wasn't being used in many places. However, once I needed it in more places (pushing it back up to the front-end from the database), handing around a "naked" Set made the code a bit harder to read and work with. For example, with the Set, figuring out if it's correct depended on the type of question (FIB is a fill-in-the-blank and MC is multiple-choice):

  public boolean isCorrectFor(@NonNull Set<String> response) {
    return switch (questionType) {
      case FIB -> correctChoices.containsAll(response);
      case MC -> correctChoices.equals(response);
    };
  }

This is pretty typical code, but unless you're familiar with the specifics of Set, you may have to do a bit of JavaDoc reading to ensure you understand it correctly. By replacing it with a Response type that encapsulates the Set, the code above becomes:

  public boolean isCorrectFor(Response response) {
    return switch (questionType) {
      case FIB -> response.matchesAny(correctResponse);
      case MC -> response.allMatch(correctResponse);
    };
  }

Now, this may not be such an amazing improvement (I'm still toying with the naming), but it leads to the next step (which I haven't done yet) of pushing the behavior that's specific to the question type into a subclass of Response, e.g., a FibResponse and McResponse, which would look like:

  public boolean isCorrectFor(Response response) {
    return response.correctlyMatches(correctResponse);
  }

Completely delegating how responses are compared to the class that knows best how to do that comparison.

In my training and coaching of Java developers, the use of Stringly types and Naked Data Structures is the cause for much pain when things change, so always try and encapsulate Strings into Value Objects and wrap up your data structures into its own class.

Exposing `asSet()` on Response: breaks Encapsulation?

By encapsulating the Set<String> inside of Response means that when I need to display the response choices or persist them to a database (i.e., hand the response across the domain boundary) I need to get those choices as a set, so the Response class has a method

public Set<String> asSet() {
  return Set.copyOf(response); // return a copy of our internal field
}

That returns the choices as a Set<String>. I use this in the GradedAnswerView class to convert it to a comma-separated String:

  private static String responseAsString(Answer answer) {
    return answer.response().asSet()
                 .stream()
                 .sorted()
                 .collect(Collectors.joining(", "));
  }

You might think: oh no, this is breaking encapsulation by exposing the set, but I'm not really doing that, because I'm returning a copy of my internal storage of the response choices. I never expose the field itself, so the only way to modify the internal Response data is only through its methods. Modifying the copy would have no effect.

Empty varargs

I don't think I had realized this before, but calling a method defined with varargs (e.g., createFrom(String... strings)) means that you can call that method with no arguments: createFrom(), and inside this method, the strings argument would be an empty array.

This means I didn't have to special-case turning varargs into an empty Set, because calling Set.of() with no arguments will turn into an empty Set (technically an ImmutableCollections.emptySet() as of Java 9), which is what I'd want.

Collaboration Tests

Most of my tests are unit tests, in that they are testing code in a class by working with that class as closely as possible. For example, the Choice class can be directly tested without any other objects. However, the QuestionTransformer can't be tested on its own as its job is mostly to collaborate with more specific transformers to do its job, i.e., its job is to integrate or collaborate with the other objects. This means that I don't need to comprehensively test all of the behavior of all of the classes that are involved, just a test or two that would ensure that QuestionTransformer is correctly collaborating with (in this case, propagating the response to) other objects.

You can see a clip from my stream where I do this: https://www.twitch.tv/videos/443315061.

Be sure and tune in to my next live coding stream: https://twitch.tv/jitterted.

Want to support me? Become a Patron at https://patreon.com/jitterted

Live Coding Learnings - June 20, 2019

Ted M. Young — Fri, 21 Jun 2019 04:42:35 +0000

Pure Refactoring

I didn't stream today, but was reviewing some of my past streams (mining it for content for my Java coaching clients) and realized my coding rule that I mentioned earlier was incomplete. The rule I stated was:

Do not change code unless it is to make a failing test pass (or fail better).

However, I had forgotten that this rule doesn't apply when doing pure refactoring. In that case, the rule is:

Tests must pass before refactoring and remain passing -- with no changes -- after refactoring.

Some might say that this is too strict, and I'd agree, I'll bend these rules when using my judgment, but for teaching novices, it's a good way to differentiate when you're changing code to add capabilities vs. when you're changing internals to improve the code itself. The latter is refactoring and if tests are breaking, you're either changing too much, or your tests were too low-level (tied too tightly to the implementation details).

For example, if I have the code

public int price() {
  return cachedPrice;
}

Then it shouldn't matter to tests or other code if I changed it to:

public int price() {
  int sum = 0;
  for (Item item: items) {
    sum += item.price();
  }
  return sum;
}

In other words, whether I calculate the price when requested, or cache it (the first example), it's an implementation detail that the class should be free to change, i.e., refactor, without affecting other code.

If tests are relying on one or the other behavior, then that's likely (though not always) a problem where you might want to re-think your test code.

Be sure and tune in to my next live coding stream: https://twitch.tv/jitterted.

Live Coding Learnings - June 19, 2019

Ted M. Young — Thu, 20 Jun 2019 02:25:55 +0000

Quizdown: Episode 19

Stories Implemented

Today I completed the implementation of handling code-fenced blocks (surrounded by three backticks) and "regular" text blocks. The differences between the two is that the code block can have embedded blank lines, but regular text uses blank lines to separate the paragraph blocks. For example, given this Quizdown text:

Here, line 2 is blank, meaning that the first line is a regular text paragraph. However, while line 8 is blank, it's inside of a code block, so it remains all one block up through line 11, where the code-fence ends. Then line 12 is a blank outside of a code block, so the final two lines (not separated by a blank line) are considered the third block (a paragraph).

Getting the above correct, while also handling inline markup (e.g., asterisks and underscores to bold and italicize words) was a bit tricky, but good tests helped me get it all straight.

Content inside of a `<pre>` still requires entity escaping

Since one of the main goals of the Quizdown project is to easily include Java code into the questions and answer choices, I have to be able to show things inside angle brackets for generics, e.g., List<String>. Normally things inside angle brackets are treated as HTML tags, but I had thought that if they were inside of a <pre> tag, they'd be shown as-is. In fact, the Mozilla docs for pre say (emphasis mine):

The HTML <pre> element represents preformatted text which is to be presented exactly as written in the HTML file.

This isn't exactly true, as angle brackets still need to be escaped, i.e., the < is replaced with <, the > with >, etc.

So, this meant I had to do HTML entity escaping on all text -- but before I turned any Quizdown into HTML (the dreaded double-encoding).

Prism needs `<code>` inside of `<pre>` for highlighting

I use the Prism library and CSS to do the syntax highlighting for the Java code fragments in the quiz. When I finished processing the code-fenced blocks, which I surrounded with a <pre>, I wasn't seeing any syntax highlighting. It turns out, that Prism has the additional requirement that any code needs to be inside of a <code> element as well for it to highlight it. The docs need to be improved on this (and some other) areas, with better examples. I'll be looking into filing a pull-request for that.

No code changes without failing test

Even though I've been doing TDD for many years, I still fall into the habit of jumping in to fix the code first instead of a test. As a reminder (to myself, if nobody else) the rule is:

Do not change code unless it is to make a failing test pass (or fail better).

By fail better, sometimes a failing test is a success if it failed as predicted and desired.

Regex Backreferences

I forgot to mention in yesterday's "lessons learned" that wietlol (one of my Twitch VIP viewers) taught me how to use backreferences so that I always match underscores with underscores (e.g., _italic_) and stars with stars (e.g., **bold**) and not a mixture (e.g., _oops*). An example regex that uses backreferences is:

([*_])(?<italic>.*?)\1(?!\1)

which means: first, match on either a star or underscore, then some text (with a named capture group), and then match in the same way as was matched up-front. The ?! at the end is a negative lookahead so the when I'm doing the replacement, I match against the right-most character. To see how this works, looking at the Quizdown test might be useful.

A good reference on backreferences (ha ha) is here and lookahead is here.

In Closing

As always, the source code for this project can be found on GitHub, and you can watch my past streams on Twitch.

Tune in to my next live coding stream: https://Twitch.tv/jitterted.

Live Coding Learnings - June 18, 2019

Ted M. Young — Wed, 19 Jun 2019 00:49:29 +0000

Summary of what I learned in today's live coding stream at https://twitch.tv/jitterted.

Matching newlines in RegEx

For the text I'm working with, I want regex search and replace to work across newlines (by default matching stops at a new line). Today I learned that I need to pre-pend this: (?s) to the regex String, which turns on DOTALL mode and therefore the dot wildcard will match across new lines. For details, see the JavaDoc: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#DOTALL

Example of `matches()` using `DOTALL`

I want to search for text that's surrounded by 3 equal signs (===)
both at the beginning and at the end. The text can span multiple lines.

For example:

Before text.
===
Text inside the equals signs.
===
Outside text.

To search for the text, I would use the String.matches() method, like this:

boolean found = text.matches("(?s)===(.*?)===");

Which returns true if the pattern is found, as it would be in the
above example.

Example of `replaceAll` using `DOTALL`

If I want to replace the triple backtick code block with a <pre> tag (as I do in my live stream), then I'd do this:

Which would output this:

<pre>
public class Stock {

}
</pre>

Scanner for Parsing

I used Scanner in a few places and forgot about it until I was reminded by one of my regular stream viewers (thanks flamaddidle84!). Today, I wanted to parse some text and split the lines whenever there was an empty line between two non-empty lines.

For example, given this text:

Block one.
Still part of block one.
Yep, still part of block one.

Block two here.
Still part of block two.

Last block here.

I want to end up with three pieces of text. Using the Scanner class and the fact that the delimiter can be specified, this is all I needed:

Scanner scanner = new Scanner(text).useDelimiter("\n\n");

Then, all I had to do was use the scanner.tokens() method (only available starting in Java 9) to give me a stream of these blocks, e.g.:

scanner.tokens()
       .map(s -> "<p>" + s + "</p>\n")
       .collect(Collectors.toList());

Which uses replaceAll on each block to surround it with the HTML <p> (paragraph) tag. Here's a full code example:

When run, it results in this output:

<p>Block one.
Still part of block one.
Yep, still part of block one.</p>

<p>Block two here.
Still part of block two.</p>

<p>Last block here.
</p>

Watch Me Live Code on Twitch

If you want to see how I use TDD to code in Java and Spring, and learn with me, tune in to my daily stream at Twitch.TV/JitterTed. I'm usually streaming from 12pm PDT (1900 UTC) for around 3 hours. You can also chat with me on my Discord.

Forem: Ted M. Young

Remote Learning Ensembles (Mob Programming)

How I Run Remote Learning Ensembles

Roles

Driver

Navigator

Onboarding New Participants

Facilitator Preparation

The Session

The Huddle

Agenda

My Favorite IntelliJ IDEA Plugins

Git

PlantUML

Presentation Assistant

Floobits

SonarLint

What About You?

Top Five "Forever" Books for Coders

Introduction

How to Read

Disclaimer

The Forever List

"Working Effectively with Legacy Code" by Michael Feathers

"xUnit Test Patterns" by Gerard Meszaros

"Refactoring: Improving the Design of Existing Code" by Martin Fowler

"Domain-Driven Design" by Eric Evans

5. "eXtreme Programming Explained" by Kent Beck

Stop Trying to Outsmart the Java Compiler

Before Java 9

Not For Loops

Don't Trust Me and Maybe Not Benchmarks

Slower in Java 11?

References:

Live Coding Learnings - June 21, 2019

Quizdown: Episode 20

Stories Implemented

HTML: Use disabled Attribute for Button or Link

No Naked Data Structures

Exposing asSet() on Response: breaks Encapsulation?

Empty varargs

Collaboration Tests

Live Coding Learnings - June 20, 2019

Pure Refactoring

Live Coding Learnings - June 19, 2019

Quizdown: Episode 19

Stories Implemented

Content inside of a <pre> still requires entity escaping

Prism needs <code> inside of <pre> for highlighting

No code changes without failing test

Regex Backreferences

In Closing

Live Coding Learnings - June 18, 2019

Matching newlines in RegEx

Example of matches() using DOTALL

Example of replaceAll using DOTALL

Scanner for Parsing

Watch Me Live Code on Twitch

Exposing `asSet()` on Response: breaks Encapsulation?

Content inside of a `<pre>` still requires entity escaping

Prism needs `<code>` inside of `<pre>` for highlighting

Example of `matches()` using `DOTALL`

Example of `replaceAll` using `DOTALL`