Forem: Tom Cools

Playwright: Wordle, with no hands!

Tom Cools — Sun, 16 Jan 2022 00:00:00 +0000

Using Playwright to automatically play Wordle. I recently decided to give UI Automation another try live on Twitch. I’ve used Selenium in the past but that always felt like a hassle. So this time, I wanted to try out a new competitor on the scene of UI Automation Libraries: Playwright. And what better way to get a feel for a library then by using it in a fun project. As this is the point in time where the online game Wordle is immensely popuplar… why not try and automate that?

See full article at: https://www.tomcools.be/post/jan-2022-playwright-wordle/

The Coffee 'Break' Conundrum

Tom Cools — Sun, 16 Jan 2022 00:00:00 +0000

I've been hearing a lot of similar stories lately. They usually go like this:

"Should I clock out of work if I take a small break? Technically I'm not being productive... so..."
"You are getting a lot of coffee... and then you just stand there looking out the window. We don't pay you for this."

In this blog, I won't talk about the regular Coffee Break Conundrums (Black or with milk? What cookie should I eat with this? Should fake drinking out of an empty coffee cup be allowed on camera? @BillyKorando 🤔 ).
I want to spend some time reflecting and thinking out loud about the "break" part.
Is a "coffee break" a break at all... and what arguments could be put forward to support the claim that "coffee breaks = work time"?

Let's see where we end up with this!

This blog is reflection on something I've seen happen around me as a software consultant and through stories from fellow consultants.
This is very much me thinking out loud and crystallizing my thoughts on this topic, usually a dangerous thing to do publicly on the internet.
Not everything comes from my personal experience but I've written this post from my perspective.
If you think differently about this topic or if you feel I've missed something, please be so kind to point out my fallacies or biases in the comments. I'm here to learn.

How we learn and solve problems

Let's start with the idea that you are paid to solve problems.
This seems like the most general description I could use to include as many of you, the readers of this post, as possible.
You are all problem solvers... be it writing code to automate solutions, writing code to test that code or determining what should be built in the first place.

As humans, we unfortunately have to rely on that thing inside our bodies called "our brain" to solve problems.
The problem is, the brain is full of biases and tries to take shortcuts where it can... some shortcuts useful, some counterproductive.
Our brain is sometimes erratic, weird and uncooperative. These rebellious acts of the brain happen more often for some of us (ex. ADD/ADHD) than others (ex. neurotypical), but they do impact us all.

Great books to read on this topic are "Thinking Fast and Slow" and "The Idiot Brain"

So lets first take a step back and look into how solving problems (and learning) actually manifests itself.
As presented in one of the first chapters of the magnificent ("can't believe this stuff is FREE"-level) course Learning to Learn our brain operates in 2 modes: Focused and Diffuse.

I'll be listing only an extremely simplified explanation of the two modes here... for more detail, look at this blog post..

Focused mode is single track. You experience this mode of thinking when you are working on a task and everything around you seems to fade away into the background;
Diffuse mode is all over the place and allows you to look at the broader picture. You are not focussed on 1 thing but let your mind wander;

Ever had a really though problem you spent hours on, only to solve it in a couple of minutes the next day or after a visit to the bathroom?
That phenomenon, which is almost a meme / cliché in our industry, can be attributed to the diffuse mode of thinking.
By letting your mind wander, you give it the necessary room to form important connections, see the bigger picture again.

There is enough research out there from people much smarter than me to confirm that focused and diffuse modes are a real thing, so let's continue our story with the reasonable assumption the theory is valid.

Efficieny: Focussed vs Diffuse thinking

When looking at the work place, usually a place where we need to find solutions for problems, you really need both diffuse and focused modes of thinking.
Sometimes you want to be in "in the zone", focused on implementing that feature which is described in your user story.

If you run into a problem however, chances are your brain is now fixated on the solution you had in your head... and it's really hard to pull yourself away from it.
That's the moment where you can benefit if you succeed in switching your brain into the diffuse mode, taking a step back, see the bigger picture and try to figure out some alternative solution.

Unfortunately, there is no easy switch hidden somewhere on your head to flip between these two modes.
What is know however, is that diffuse thinking usually occurs when you do other things. Take a shower, go for a walk or go grab some coffee.
Looking at it this way, taking a break is a way to get your brain to switch to diffuse mode... which would make taking breaks an integral and important part of solving problems.

Given all this information, isn't it weird then that so many managers only consider you "at work" when you are in focused mode behind your desk?
Isn't it strange that coffee breaks or just walking around the office to give your brain a rest is considered lazy & unproductive?
What is happening here?

One explanation could be it's an availability/measurement bias: It's easy to measure the amount of time you sit behind your desk.
Measuring the value of your diffuse thinking is much harder, but it might be much higher than you anticipate!
I've personally saved companies hours (if not weeks or months) of work by stepping back and shutting down the focused mode for a short while.
Some things that happened when I was activating my diffuse mode, aka taking a breather:

I realized some features on our backlog are unnecessary or could be built in an easier way;
Realized what a potential solution could be for a problem I'd been struggling with;
Remembered a collegue who had a similar project, contacted them, found better solution than the one I had in mind;

Measuring work efficiency is a hard task. If you read my experiences above, you know those actions saved a ton of time and money.
However, that saved time will never make it on a sprint report, burndown chart or work log... and unless I specifically mention it to my manager, chances are they'll never know.

Should I be paid if I figure out a problem in my sleep?

The content of this post so far could be used as an argument that companies should pay you for your diffuse thinking time as well as your focused time.
I believe this to be true on a certain level but let's refine that idea (being paid for diffuse thinking time) for a second and look at what that might mean.
If we ask to be paid for our diffuse thinking as well... what would that say about overtime?

The trope mentioned earlier ("I went home, slept on it, and now I have a solution") implies you did some diffuse thinking at home which benefited your company.
Should you get paid for that as well? Where does the working day stop in this case? For hourly workers: How long did your diffuse thinking take to come up with that solution?
As you might imagine, trying to quantify diffuse thinking time would lead to an organisational nightmare. So what can we do?

If we believe the research on this topic, both focused and diffuse thinking are needed to solve problems.
This certainly makes a case that it might be beneficial to allow room for diffuse thinking during the regular workday.
Consider the following two scenarios:

Person X can solve a problem in 3 hours but they took a 30 minute walk to let their brain wander;
Person X can solve the problem, struggling 5 hours, focussed on their screen, then goes home to "sleep on it" to only solve it the next day;

Which situation was more productive? What instance is going to be more taxing on the employee?
When was the most value provided to the company?
The answer seems clear.

What are you being paid for?

It's important to note that I'm not advocating employees should be allowed to just walk about the whole day, every day.
The economic reality is that in order to get paid, you need to provided value, either to your company or directly to your customers.

You are being paid to be as productive as you are able to be.
As a professional you should do whatever you think is necessary... even if what you think is needed is to take a break.
As I've talked about in this post, taking breaks is important to let your brain switch gears.

So if you need one, take one and remember, you can't spell "breakthrough" without "break".

Footnotes

I am fully aware I leave a lot of open discussion space with this blog and if I triggered a response within you, please leave a comment! There are a lot of things I don't have an answer for.

If you need a lot more breaks to get the job done than your colleague, that might be a bad look but should it be?
There is a lot to be said about the value of neurodiverse teams, something I will be exploring next as I don't know enough about neurodiversity to see how this discussion is appropriate for the many ways in which people can be different.

I also realize I'm in a situation and profession where taking a break is not really frowned upon that much but it's still interesting to think about this topic.
If your company has a policy for this, please drop a comment! I want to learn how to think about this absorbing as many perspectives as possible.

Getting through the Q&A section of your presentation

Tom Cools — Sun, 24 May 2020 00:00:00 +0000

This post was written from a white-cis-male perspective. If anything in this post doesn't match your previous experiences with Q&A, please leave a comment! I would like to know what kind of hardships my priviledge has spared me from. <3 to all of you!

Imagine being at a conference or meetup giving a talk. You completely ace it (I believe you will, even if you don't, you badass!) but then you feel anxiety setting in. You can feel it coming for you, slowly, surely: the end of your talk. Which means... it's time for Q&A: Questions and (hopefully) your Answers.

Q&A is the most dreaded part of a presentation for some while being indispensable for others.

Let's talk about that.

It's not 1 vs N

Let's discuss the "fear" part of the Q&A first because let's not deny it, it can be quite daunting.

Sometimes it makes you feel like you are in the middle of a technical interview. Instead of one interviewer, you have ... an audience. Maybe 10 people, maybe 50, maybe way more than that. The chances are, there is someone in the audience who knows way more about the topic than you do. Maybe the person who wrote THE book on Java is in your audience while you are giving a Java talk. Now that is scary.

And yet, all of that does not matter. Because it is not a technical interview. Your Q&A is not a place where people will ask you questions to bring you down a notch.

Here is the truth about Q&A (and your entire talk in general):

Your audience wants you to succeed.

Q&A is not a "1 vs All" proposition, it's a collaborative moment. That person who knows more about the topic than you do... no matter how scary their presence may seem to you at first,
they might be the ones to jump in and help you answer those questions. Just be sure to thank them for their help afterwards.

The biggest mistake in Q&A

It is normal to not know the answer to every question. Don't let that distract you. Don't let it get to you! You are still the presenter! You know enough about that topic to be there!

There is only one thing you should never do:

Never pretend to know the answer when you don't.

I see people struggling with this. Some get so caught up in the idea that they are supposed to be "ultimate master experts" they have trouble handling the perceived emberrasment of not knowing the answer to a question. So they start inventing answers, to keep up appearances. Problem is: People know. Your audience can sense that you are making stuff up from a mile away. Especially people who have more knowledge on the topic than you do.

There is only one thing you can answer in this situation:

"I'm sorry, I don't know the answer to that question..."

Yes, people expect you to be able to answer basic questions but if you have prepared a talk on something, you will be able to answer those questions.
So it's actually pretty straightforward: either you know, or you admit you don't know. There is no shame in any of those two outcomes.

Q&A beyond your talk

Having been to quite some conferences now, I have noticed that the Q&A is often my favorite part. It gives me the opportunity to ask questions to people who know a lot more about the topic than I do. Even if I have no questions myself, I will often just sit there and listen to the questions other people come up with.

Don't forget: You have a room filled with people, each with a slightly different background and perspective. You'll notice that often one of them ask a question that will make you think: "Oh... never even considered that."

Despite the Q&A being a great moment of opportunity and collaboration, most speakers only share 2 things: Code and Slides. While you should be grateful they are willing to share their hard work, the Q&A part of the talk often gets lost to history. This can be extra frustrating for members of the audience who asked a question that was left unanswered.

When I started doing talks, I decided I wanted to do it differently. That is why, for every talk I give, I create a page containing, Slides, Code and the Q&A. See this example.

This allows me to take whatever great interactions I had during the talk and bring it, at least partially, online for everyone to see.
I can't recommend this enough! It has so many great side effects.

First of all, it enables you to say:

"I'm sorry, I don't know the answer to that question but I will figure it out for you!".

By posting the Q&A online, you're effectively extending it beyond your timeslot. This gives you the time to figure out answers to the questions you couldn't answer during the talk. That way, you are still helping your audience, which is what this is all about!

Secondly it also greatly benefits yourself! By keeping track of all the questions people have asked and answering them, you are effectively creating an amazing resource of information. Questions that are asked frequently are a nice indicator that your presentation is missing some content. Knowing what is missing, you can add that information to your slides to make your talk even more awesome!

After giving a talk a couple of times, I notice I often open my own website and go to a Q&A page of a previous talk and I use that content to answer questions. That's not bad presenting, that's giving your audience the content they are looking for.

Conclusion

This entire post originated because of a tweet by Angie Jones (a fellow badass!). In the tweet, she talks about being unable to answer some questions and how she handled it by researching the questions and writing a blog post about the answers.

Angie Jones

@techgirl1908

Many speakers are hesitant to do Q&A bc it takes you out of your comfort zone

During Q&A for my last talk, I gave educated guesses for many Qs bc I just didn't know

After, I took those questions, researched (while live) & made it a blog post

So, new content! #LemonsToLemonade twitter.com/techgirl1908/s…

21:40 PM - 21 May 2020

Angie Jones @techgirl1908
Angie Jones - live via https://t.co/kmDTWCFaxf https://t.co/Xh1zQWUZ49

20 121

It made me realize that I had been doing exactly the same thing for a while but never talked about it, assuming more people were already doing it anyway.
Turns out I was wrong. I should have been advocating for sharing Q&A's online and following up on unanswered questions a bit more.

With that at least partially corrected now by posting this, I hope to see more content out there. Not because a presenter succeeded in answering questions but because they failed and handled it with grace.

Great stuff is Loom-ing on the Horizon for Java

Tom Cools — Thu, 21 May 2020 00:00:00 +0000

Almost two years ago now, I was at Oracle Code One in San Francisco. It was there that I first heard about Project Loom, a project that would introduce some kind of new way to do concurreny in Java. At that point, Loom was just a concept, a promise to make concurrency in Java easier.

Fast forward to today and Loom has changed quite a bit since that initial presentation. The time to catch up with Project Loom.

Old choices sometimes hurt in Java

Ever since Java 1.0 we've had the Thread class. This class is a representation of an OS resource, namely an OS thread.
OS threads are limited to a couple thousand at a time. This wasn't much of a problem 25 years ago. It is however a huge problem now, where some applications need to handle tens of thousands of requests (or more) at the same time.

By linking what can be done concurrently in Java to OS Threads, Java has extremely limited it's own scalability.
To add to the problem: Threads are costly to make. Just creating them for a single run and disposing them again isn't viable.
This is why we have started using Thread Pools, groups of re-usable threads we keep alive in our applications.

The real problems begin when we have to block a thread. This happens whenever we do an API call, connect to a database or read from a file.
At those moments, our thread isn't doing anything. It is just "waiting" for something. As threads are costly AND limited, this becomes a serious bottleneck if we want to get the most out of our hardware.

Loom to the rescue

So what is Project Loom going to bring us?

Backwards compatibility

When Loom was first introduced, we were also introduced to the concept of Fibers, a new concept that was dubbed "Threads revisited". This sparked a bit of controversy in the Java Community, as worries grew about replacing Thread.class everywhere by Fiber.class, which would require a lot of code to be changed. As the project went on the Java team realized that if it looked like a thread, and worked like a thread, then maybe it should just be Thread!

That's what they did. Instead of creating a totally new concept, Loom introduces us to Virtual Threads.
Unlike the current Thread implementation, virtual threads are no longer a one-on-one mapping to OS threads. Instead, virtual threads are a concept managed by the JVM. This means we no longer have to worry about them as much as we had to in the past.

Here is a basic example on how to run something on a virtual thread:

    Thread.startVirtualThread(() -> {
        // Do something in a Virtual Thread
    });

    Thread.builder().virtual().task(() -> {
        // Do something in a Virtual Thread
    }).start();

If you think that code looks awfully familiar you are absolutly correct.
By keeping the current name and class, we can effectively keep all our code and our tools the same!
While some libraries will need to change to make use of virtual threads, the impact of that change is extremely limited.
When using the ExecutorServices, which you should be doing anyway, chances are all that needs to be changed is the implementation of the Executor!

    // Classic fixed thread pool
    ExecutorService executor = Executors.newFixedThreadPool(10);

    // Threadpool with unlimited virtual threads
    ExecutorService executor = Executors.newUnboundedVirtualThreadExecutor();

So hardly any change in code required to switch to Virtual Threads! That's the kind of backwards compatibility we've grown to love (and expect) from our favorite programming language!

Unlimited (virtual) threads :o

In case you are wondering, you did read that previous code example correctly: "newUNBOUNDEDVirtualThreadExecutor". Unbounded means "a lot!", but how does that translate to OS Threads? Well, to reiterate: Unlike the current Thread implementation, virtual threads are no longer a one-on-one mapping to OS threads. The JVM does the heavy lifting of making sure our virtual threads eventually run on actual OS threads.

So, if virtual threads are a concept in the JVM... how many can we run at the same time?
According to the "State of Loom" post by Ron Pressler (May 2020): Millions!

Because these virtual threads are cheap to create, there is no real need for pooling anymore. With Loom, we are entering a world where we will be creating a (virtual) thread for a single action and then just disposing it again. In fact, the UnboundedVirtualThreadExecutor above does exactly that! Whenever you use it, you get a shiny new virtual thread which will be destroyed once it's done with its task.

Blocking code is no longer an issue

In recent years we saw the rise of frameworks who claim to have bypassed the restrictions of the Java Concurrency model. These "non blocking" frameworks have seen quite some success, Vert.x being the one I personally fell in love with. The main idea behind them was often to write code in such a way that only a limited amount of Threads would be blocked at the same time. This left other threads to be continuously busy. Those threads are never blocked leading to greater overall performance.

Those benefits, like everything in life, came at a cost. Quite often those frameworks required a different programming style, something a lot of programmers (including myself) struggled with. Whenever I do reactive programming, I feel like I'm no longer programming Java. It has always felt alienating to me.

With Project Loom we might no longer need reactive, non-blocking programming as it is known today.

In plain terms reactive programming is about non-blocking applications that are asynchronous and event-driven and require a small number of threads to scale. - docs.spring.io

Because we can create MILLIONS of virtual threads, each of which can be used for a single action, the cost of blocking a virtual thread is close to zero!
With that cost gone... imagine the possibilities! We can write synchronous/blocking code, without having the decrease in performance or scalability. That seemed impossible just a few years ago, yet now with Project Loom it's becoming reality.

Conclusion

When Project Loom is completed and finds it's permanent spot in the JDK, it'll change how we look at building high-performant Java applications forever.
Removing the cost of blocking threads while still being backwards compatible is a masterpiece of engineering by the project team.

I have been trying out the Early Access build and was just baffled by how intuitive the API feels. This is my new #1 of amazing things to come for Java!

In short: "Project Loom allows Java to once again become the Java we fell in love with: boring but highly performant <3."

Addendum:

Try yourself! Download the Early Access Build

Building a Twitch Chat Integrated Game

Tom Cools — Mon, 27 Apr 2020 00:00:00 +0000

Being in Corona isolation, I have been watching some Twitch streams and was wondering if it would be something I'd like to do as well.
I love teaching and since we're all pretty much stuck in our homes, maybe I should give it a shot.
It could be kind of like giving a talk at a conference only more limited in interaction... but that's what I love most about teaching...interaction.

So, maybe Twitch just isn't for me... unless...
What if I could do something to make Twitch a more interactive place?
What if I could somehow create something streamers could use to entertain their viewers in a more interactive way?

Time to build something Twitchy!

The Requirements

To keep myself focused, here are the guidelines I set for myself:

The bar of entry should be low;
The owner of the stream needs to have control;
Whatever I make should not draw attention away from the stream, it should be the stream;

These requirements pushed me towards the following preliminary design:

IMG

To keep the bar of entry low, I'm going to create some kind of web-based game.
Making it in Javascript/HTML makes it more accessible, since all users would need is a browser.
I've had some previous experience with p5.js, so I'm going to use that again for this project.

All I needed to do then was find a way to integrate with Twitch... somehow.

Read the chat!

Scouting around on some Twitch streams, I quickly noticed that the way most Twich users interact with the streamer is through the chat.
If that is the common way of doing things, I'm not going to fight that. I'm going to embrace it.

So now I just need to integrate with the Twitch Chat and use that as input for whatever I'm making.
I was a bit worried this might be a difficult task. I really didn't want to use some screen-scraping tooling or whatnot to get the chat messages.
Those feelings quickly went away when I learned the good news:

Twitch uses IRC!

For those of you who might not know this...IRC, or Internet Relay Chat, is an Application Layer Protocol built on TCP.
It's a fairly simple text based protocol which has been around for 30 years now and is still used today.

Nice! Since IRC is so common, I only had to find a way to connect my front-end to the IRC chat and we are good to go.
And that is kind of where my original plan fell apart.

You see, IRC uses TCP. Javascript, at least the sort of Javascript running in the browser, can't make regular TCP socket connections.
This may sound surprising with the popularity of WebSockets.
WebSockets however always start out as a HTTP request and get "upgraded" to TCP.
WebSockets are a separate application layer protocol, just like IRC is an application layer protocol.
Unfortunately, they do not magically play well together.

So...back to the drawing board!

The Java IRC Client

It seems like I had no other choice than to put a custom Backend between my Frontend and the Twitch Chat.
I chose for a Spring Boot application, always good to keep some familiar technologies close when you are building something unfamiliar.

IMG

To connect to the Twitch IRC, I decided to use the PircBotX library.
I'm not going to duplicate their documentation... but I will show you what settings I used to connect to Twitch.

First off, you'll need a Twitch account and get an Access Token for your application.
This website will give you one if you log in.

Next, you need to setup PircBotX to use the correct configuration.

    String authToken = "oauth:YOUR_TOKEN"; // Your oauth password from http://twitchapps.com/tmi
    String channel = "#tomcools"; // The IRC channel name = Twitch Channel name
    Listener listener = <PIRCBOT Listener> // Extend the ListenerAdapter Class

    Configuration configuration = new Configuration.Builder()
            .setAutoNickChange(false) //Twitch doesn't support multiple users
            .setOnJoinWhoEnabled(false) //Twitch doesn't support WHO command
            .setCapEnabled(true)
            .addCapHandler(new EnableCapHandler("twitch.tv/tags"))
            // Twitch by default doesn't send JOIN, PART, and NAMES unless you request it, 
            // see https://dev.twitch.tv/docs/irc/guide/#twitch-irc-capabilities
            .addCapHandler(new EnableCapHandler("twitch.tv/membership"))
            .addServer("irc.twitch.tv")
            .setServerPassword(authToken) 
            .addAutoJoinChannel(channel) //Some twitch channel ex. #tomcools
            .addListener(listener).buildConfiguration();

    bot = new PircBotX(configuration);
    bot.startBot();

Next we need to add a Listener which will be called whenever a new message arrives on the IRC channel.
There is a convenient abstract class you can inherit. You only need to override the methods you actually want to use.
In our case, we're interested receiving messages and some feedback on connect/disconnect events.

    public class TwitchIrcChatListener extends ListenerAdapter {
        private final ChatMessageListener listener;

        public TwitchIrcChatListener(final ChatMessageListener listener) {
            this.listener = listener;
        }

        @Override
        public void onGenericMessage(GenericMessageEvent event) {
            listener.onChatMessageReceived(new ChatMessage(event.getUser().getNick(),event.getMessage()));
        }

        @Override
        public void onConnect(ConnectEvent event) throws Exception {
            super.onConnect(event);
            listener.onConnect();
        }

        @Override
        public void onDisconnect(DisconnectEvent event) throws Exception {
            super.onDisconnect(event);
            listener.onDisconnect();
        }
    }

As you can see, I provided a ChatMessageListener in the constructor and all I do is pass the message on to this listener.
The definition of that interface is pretty simple.

    public interface ChatMessageListener {
        void onChatMessageReceived(ChatMessage chatMessage);
        void onConnect();
        void onDisconnect();
    }

While this may seem like an unneeded layer of indirection,
it allows us to decouple the rest of the application from the PircBotX framework.
This way, we're free to change it out with anyother framework without the need to refactor too much.

STOMP for the Win

Now that we're getting the chat messages in the Bootiful backend, we still needed a way to get them to my Javascript Frontend.
The game we're building needs to be usable by multiple different users, each with their own session, their own part of the system.
I almost instinctively reached for Websockets to complete that task... but something stopped me.

When doing these projects, I always try to limit the amount of new things I'm learning.
Trying to mash too much new shinies in a project always slows me down to a pace which I no longer enjoy. I need a sense of progress.
Having the IRC integration behind me, I did feel it was time for something new, specially since I had the feeling Websockets weren't a good fit.

This is when I discovered Simple Text Orientated Messaging Protocol, or STOMP for short.

STOMP provides an interoperable wire format so that STOMP clients can
communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.

From: https://stomp.github.io/

STOMP resembles IRC in one very convenient way for our application.
They use different terminology for this, but they both allow messages to be sent to a named location.

In IRC, messages can be sent to CHANNELS users can *JOIN*.
In STOMP, messages can be sent to DESTINATIONS users can SUBSCRIBE on.

While there are some difference between the two, it's this similarity that caught my attention.
Remember, what I wanted to do originally is to connect my frontend game directly to IRC.
What can be done instead is to connect the frontend through STOMP to the Spring Boot backend and use that backend as a Bridge to IRC.

IMG

Lucky for us, Spring has built in support for running a STOMP broker.

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-websocket</artifactId>
    </dependency>

    @Configuration
    @EnableWebSocketMessageBroker
    public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

        @Override
        public void configureMessageBroker(MessageBrokerRegistry config) {
            config.enableSimpleBroker("/topic");
        }

        @Override
        public void registerStompEndpoints(StompEndpointRegistry registry) {
            registry.addEndpoint("/stomp-websocket")
                    .setAllowedOrigins("*").withSockJS();
        }
    }

This configures a simple message broker and a STOMP endpoint with SockJS support.

SockJS is a library which provides WebSocket-like features, it even uses WebSockets by default.
It will however fallback to different protocols and strategies if WebSockets are not available for whatever reason.

Because the backend will function as a bridge between STOMP and IRC,
it is only natural we want to start/stop the IRC connection at the same time the connection with STOMP starts/stops.
To achieve this, we can listen to Spring Events which will be fired when a session is started/stopped.

    @Autowired (through constructor in project code)
    private final SimpMessagingTemplate template;

    @EventListener
    public void handleSessionConnected(SessionConnectEvent event) {
        // Get channel out of event
        String channel = SessionEventHelper.extractChannel(event);

        // Start a new Chatbridge (see code for details)
        chatBridge.start(channel, chatMessage -> {
            // Whenever a message arrives, send it to /topic/CHANNEL_NAME through STOMP
            template.convertAndSend("/topic/" + channel, chatMessage);
        });
    }

    @EventListener
    public void handleSessionDisconnect(SessionDisconnectEvent event) {
        // Stop Chatbridge
    }

Whenever an IRC message is received on a certain channel (#channel-name), our bridge will place the message on a STOMP destination
with the same name (/topic/channel-name). Keeping the name mapping between IRC and STOMP 1 to 1 makes it just a tad easier to manage.

Connecting the frontend

Now that's all settled... let's have a quick look at the front-end.

The way the frontend connects to Spring is by using the endpoint we configured earlier.
We use the SockJS library and wrap it with a Stomp Client.

    const socket = new SockJS('/stomp-websocket');
    let stompClient = Stomp.over(socket);
    let twitchHandle = // Read from field;
    stompClient.connect({channel: twitchHandle}, function (frame) {
        console.log('Connected: ' + frame);
        stompClient.subscribe('/topic/'+twitchHandle, function (msg) {
            let message = JSON.parse(msg.body);
            textReceived(message); // Function our game uses to handle received messages
        });
    });

The Roundup

The rest of the frontend doesn't matter that much to be honest.
It's just a simple frontend game in Javascript written with p5.js.
What does matter is that we have some way to get the Twitch Chat messages all the way to Javascript.

The project is available on my website. Check it out if you're a streamer.
While it is just a simple game, it was fun to see people participate on my own stream.

If you build some cool Twitch Chat integrated game or application after reading this post, I'd love to try it!

Full Code is available on Github. <3

Some usefull resources:

Static access to your Spring Beans

Tom Cools — Sun, 19 Apr 2020 00:00:00 +0000

There are some edge cases where you want to access Spring Beans in a static method.
While you should always try to refactor your code so you do not have to do this... this post will still show you how it can be done.
Continue reading at your own risk! You have been warned!

Autowiring Beans

Getting instances of beans in Spring is pretty simple.
You add @Autowired on your constructor and assuming your class is a bean as well, an instance will be injected in your constructor.

@Component
public class UserServiceImpl implements UserService {

    UserRepository repo;

    @Autowired
    public UserServiceImpl(UserRepository repo) {
        this.repo = repo; //JEEJ! an instance!
    }

Some notes about the above code example before we continue:

@Autowired can also be placed on a field or a setX(x) method. Constructor injection is generally accepted as the best way to inject dependencies;
When a class only has a single constructor you can omit the @Autowired annotation (since Spring 4.3), I kept it here for clarity;

Time to spill some beans! Statically!

The problem

In our use-case, we don't want to create a class. We want to be able to have static access to the beans!
This means the standard @Autowire is not an option. There is however another way to get beans, namely directly from the Application Context.

The Application Context is at the heart of the Spring Framework. It provides a couple of different features:

Load file resources in a generic fashion;
Publish events to registered listeners;
Resolve messages, supporting internationalization;
It has bean factory methods for accessing application components;

That last one is what we are interested in. We want to use the Application Context to get another bean.
The ApplicationContext interface provides a nice convenient method to access beans it knows about: getBean(Class<>)?

// Our static method
public static <T> T getBean(Class<T> clazz) {
    ApplicationContext context = //excluded
    return context.getBean(clazz);
}

So all we need now is to get an ApplicationContext and we are done! How do we get one?
Well, you could @Autowire one... but we want to use it in a static context. Here is how we can do it!

@Component
public class StaticContextAccessor {

    private static ApplicationContext context;

    @Autowired
    public StaticContextAccessor(ApplicationContext applicationContext) {
        context = applicationContext;
    }

    public static <T> T getBean(Class<T> clazz) {
        return context.getBean(clazz);
    }
}

Create a class marked with @Component. This way, Spring will initialize it on startup by default.
@Autowire the ApplicationContext.
Set the ApplicationContext to a static field.
static method can now use the ApplicationContext.

Doing this, we can now use the getBean() method on the StaticContextAccessor to get any bean in a static context.

UserRepository userRepo = StaticContextAccessor.getBean(UserRespository.class)

Timing and the looming Nullpointer

While the solution above works, there is a major problem with it.
It is possible to use the StaticContextAccessor.getBean(class) method before the ApplicationContext is autowired.
This would crash the system because you can't invoke a method on a reference pointing to null.

We have a timing issue here.
We know the ApplicationContext will be autowired eventually, usually within seconds if not milliseconds after the application is started.
But we also can't really stop anyone from invoking the static method to get the bean before that happens.

Returning a Proxy

To avoid the timing issue, we need to bridge the time between those two events.
What we could do is provide a temporary object, so our static getBean() returns at least something.
This can be achieved by using a Proxy object, which is a part of the Java specification.

A proxy class is a class created at runtime that implements a specified list of interfaces, known as proxy interfaces.
A proxy instance is an instance of a proxy class.
Each proxy instance has an associated invocation handler object, which implements the interface InvocationHandler.

A method invocation on a proxy instance through one of its proxy interfaces will be dispatched to the invoke method of the instance's invocation handler, passing the proxy instance, a java.lang.reflect.Method object identifying the method that was invoked, and an array of type Object containing the arguments.

Source: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/reflect/Proxy.html

So we need a couple of things now. Let's start by seeing how we create the proxy object.

public static <T> T getBean(Class<T> clazz) {
    if (context == null) {
        return getProxy(clazz);
    }
    return context.getBean(clazz);
}

private static <T> T getProxy(Class<T> clazz) {
    // Our custom invocation handler, will be explained below!
    DynamicInvocationhandler<T> invocationhandler = new DynamicInvocationhandler<>();
    return (T) Proxy.newProxyInstance(
            clazz.getClassLoader(),
            new Class[]{clazz},
            invocationhandler
    );
}

The Proxy.newProxyInstance() method will return a dynamic object of the given interface.
It creates a new Object, at runtime, which extends Proxy and implements the given interface.
Since this object implements the given interface, we can return it in our getBean() method. Thanks Polymorphism!

Note: This method will only work when requesting a interface. If you want to be able to create a proxy-object for non-interfaces, you could use ByteBuddy. ByteBuddy is out of the scope of this post.

Next up is the InvocationHandler.
Whenever a method is invoked on our proxy object, the invoke method of this handler will be called.
If your handler has the actual bean set, it will invoke the correct method on our bean instance.
If the actual bean isn't set yet, it will throw a RuntimeException().

class DynamicInvocationhandler<T> implements InvocationHandler {

    private T actualBean;

    public void setActualBean(T actual) {
        this.actualBean = actual;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (actualBean == null) {
            throw new RuntimeException("Not initialized yet! :(");
        }
        return method.invoke(actualBean, args);
    }
}

Now all that is left is to set the actual bean on the handler as soon as it becomes available and we are done!

Full Code Solution

@Component
public class StaticContextAccessor {

    private static final Map<Class, DynamicInvocationhandler> classHandlers = new HashMap<>();
    private static ApplicationContext context;

    @Autowired
    public StaticContextAccessor(ApplicationContext applicationContext) {
        context = applicationContext;
    }

    public static <T> T getBean(Class<T> clazz) {
        if (context == null) {
            return getProxy(clazz);
        }
        return context.getBean(clazz);
    }

    private static <T> T getProxy(Class<T> clazz) {
        DynamicInvocationhandler<T> invocationhandler = new DynamicInvocationhandler<>();
        classHandlers.put(clazz, invocationhandler);
        return (T) Proxy.newProxyInstance(
                clazz.getClassLoader(),
                new Class[]{clazz},
                invocationhandler
        );
    }

    //Use the context to get the actual beans and feed them to the invocationhandlers
    @PostConstruct
    private void init() {
        classHandlers.forEach((class, invocationHandler) -> {
            Object bean = context.getBean(class);
            invocationHandler.setActualBean(bean);
        });
    }

    static class DynamicInvocationhandler<T> implements InvocationHandler {

        private T actualBean;

        public void setActualBean(T actualBean) {
            this.actualBean = actualBean;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if (actualBean == null) {
                throw new RuntimeException("Not initialized yet! :(");
            }
            return method.invoke(actual, args);
        }
    }
}

There we go! We can now get Spring components from a static context!
All we need to do is call the static getBean method.

UserRepository userRepo = StaticContextAccessor.getBean(UserRespository.class)

About that RuntimeException

Even with this proxying setup, there is still a case which will not work.
As you can see in the handler code above, if the actualBean isn't set yet, we throw a RuntimeException.

UserRepository userRepo = StaticContextAccessor.getBean(UserRespository.class)
userRepo.getAll() //this will break if called before ApplicationContext is ready.

There is no way around this. If the bean isn't created and known in the ApplicationContext, we can't call a method on it.
The proxy solves the issue with the time between requesting the Bean and the ApplicationContext being created.
However, if the real bean isn't loaded into the proxy and a method is invoked, the only option is to throw an exception.

A plushy controlled game (Part 1)

Tom Cools — Sat, 29 Feb 2020 00:00:00 +0000

I have been fascinated by video games ever since I saw the first level of Mario. They dominated a big part of my youth and are what got me into programming in the first place. Building a website for our Call of Duty clan was probably one of the first times I came into contact with HTML and CSS.

Recently however, my fascination has shifted from playing games, to discovering how they are built. Physics are a big part of what makes a game feel natural, making things fall with gravity, being blown away by wind, etc.
I had no idea how to even start coding physics, until colleague of mine told me about this great book he had read: The Nature of Code.
The book describes in incredible detail how you could program physics in a pretty clear and straightforward way.
Best of all, you can find it online, for free! :o

Next to the physics part, how your audience interacts with your game determines a lot of the experience.
I have always loved the idea of using a camera to control your game so I decided I wanted to use my laptop camera as the main way to interact with the game.

What are we building?

So what do you get when you mix physics and computer vision? A demo concept "game" controlled by a plush animal! So fluffy! <3

In this first post we will focus on the basic elements of a game.
We'll cover how to draw items on a canvas and program in some realistic looking physics. As this blog post contains a lot of examples with Javascript which could not be posted on dev.to, please read the blog on my own personal website.

Event Stores: Saving the right kind of byte[]

Tom Cools — Fri, 14 Feb 2020 15:32:12 +0000

A colleague of mine recently started exploring Event Sourcing.
While his focus is on .NET and mine is on Java, I was more than glad to help him out.
I pointed him to Event Store as a great place to start.
A couple of hours later he shared a link to his github, proclaiming he "had done it".

The warm feeling you get when helping a colleague discover something new was rising up inside me... until it was taken away again when he dropped the following line on me.

It's a shame I have to manually serialize my objects to byte[]...

I immediately opened the Event Store website only to discover that serializing your Objects into byte[] seems to be the default way of saving events when you use the C# library. While there are other ways to create a byte[], there seems to be no guidance what so ever on what you should be putting in your event store.

So... what bytes are a right fit for an event store? To make a decision, lets take a step back to one of the fundamental truths in our sector.

Change as a constant vs Event Sourcing

Perhaps one of the most powerful lessons I learned in school was this: "Change is the only constant".
Writing code is an iterative process where we learn and discover better ways of expressing ourselves. We refactor, we get new insights and sometimes so does the business we are working for.

Event Sourcing on the other hand is about writing and never changing events.
Most of the time, the way we save our events is referred to as an "immutable sequence of events". This means that if we save something, we have to keep dragging it along until the end of time. It can not change.

Immutable Event Store VS The fundamental truth of change

The Event Store and the concept of Change may seem like complete opposites.
What we can do is try to bring the two closer together by choosing an event structure which is flexible enough to allow for some change, without truly breaking the immutability of the Event Store.

Lets look at some of the options for creating our byte[] events while keeping change in mind.

Serializing JAVA/C# Objects

My colleague chose for serializing his C# objects. There are some obvious pitfalls to this choice.

Serialization is a very fragile thing. Simple changes like adding or renaming fields will already break the system.
Your events will be locked forever to a single version, requiring you to keep them forever and use upcasters to update them to the latest version.

Depending on how much you change your events, this may lead to an explosion of versions and an overall increase in complexity.

That being said, there is a bigger issue here. By serializing Objects, you are binding your events to a certain programming language.
This might be a conscious choice but it is not one that should be taken lightly as it will haunt you forever.

JSON

To remove the dependency on a specific programming language we could use JSON. JSON has been a big success as a communication format in polyglot environments. We are at a point where a public API is expected to return data in a JSON format!
But how does it fare as a format for events in our store?

While we can now be polyglot when reading our events, it is far from perfect.
For example, if we discover a more meaningful name for a field, we still can not change it.
Have a look at the following JSON structure:

{
  "event": "UserAddedEvent",
  "data": {
    "userid": "123456789",
    "name": "Tom",
    "lastname": "Cools"
  }
}

Through evolving our code, we notice that we have different kinds of users in our system, which each mean something different.
You want to be able to make the distinction between "Customers", "Employees" and maybe an "Administrator" type of user.
As adding employees is new for the system, the currently saved users are all "Customers".
What you actually want to do, is change the event to the following:

{
  "event": "CustomerAddedEvent",   <- Change event name
  "data": {
    "customerid": "123456789",  <- change field name
    "name": "Tom",
    "lastname": "Cools"
  }
}

Using JSON however, this will not work.

You can't change the events in the event store, so now you have two kinds of events.
Without making two readers for the different types, the reading of the event will fail, either hard with an exception, or soft because the resulting field is empty or null.

You will be forced to add a new "type" field to the data and your reader must be smart enough to set the type = Customer as a default.
This might not be a big deal for now, but remember, every version of an event must be handled. This means, adding more processors or adding more upcasters to handle the differences.

Another downside is that JSON is, at its core, a String. This means you will need to escape special characters.
Those of you who have lost some hours with escape sequences should have felt a shiver down your spines reading the last paragraphs...

Data Serialization Libraries

Data Serialization Libraries are often mentioned in the context of Inter Process Communication. Think about the things you put on Kafka, RabbitMQ or some other message broker. It is commonplace to use a library to transform messages into byte[] to put them on the wire. So why not use those libraries to serialize and save our events?

There are some out there, like Avro and Thrift, but my personal favorite is the Google Protocol Buffers Library.
Using Protocol Buffers you declare a schema which is used to generate (de)serialization code for a specific programming language.

The serialized result is the same each time, so you could serialize data using the Java library and deserialize that data again with the .NET Library.

message CustomerAddedEvent {
  required string customerId = 1;
  required string name = 2;
  optional string lastname = 3;
}

Important to note is that a Protocol Buffer schema is index based. Because this is the case, there is no impact when changing a field name.
As long as the field index and type never change, you can change the field name as much as you want.

Adding and removing of fields can be done without problem as well. The serialization will keep working.
When you add a new field that didn't exist before, you do need to program a sensible default yourself.

I have created an example project on github where I use the Maven plugin to generate the Java classes out of the Protobuf Schemas.

TomCools / protocol-buffers-example

Example repo for protocol buffers

Be sure to have a look. For other programming languages, check out the official documentation.

So what do you choose?

Choosing in which structure you save your events is probably the most significant decision you have to make while starting Event Sourcing.
If you worry about an ever changing world, you may want a mix between the principles of an Immutable store, while still having a little bit of flexibility.

Here is a table listing the options I described above and which changes are possible when using each one without adding an extra mapping layer.

Example	Serialized Object	JSON	Protocol Buffers
Polyglot	✘	✔	✔
Remove field from event	✘	✔	✔
Add field to event	✘	✔	✔
Change field name	✘	✘	✔
Human Readable	✘	✔	✘

I have a tendency to forgo the human readability in favor of the flexibility and speed of Protocol Buffers.
If you are interested in performance metrics, the guys at auth0 have written a great blog post on this.

For now, I will be sticking with Protocol Buffers as the format for my events. Whatever you choose to use, be sure you know the consequences.
Choosing an event format is a day 1 decision, so whatever you do, keep in mind:

A bad choice now will haunt you for a long, long time.

Don't agree or have another idea, please leave your remarks in the comments!

'Just Google It' is not enough - The negative impact of 3 simple words

Tom Cools — Wed, 12 Feb 2020 15:05:07 +0000

When I had just transitioned into a senior role a couple of years ago, a junior developer in my team asked me a technical question.
I was busy tackling a pretty important issue which required my full attention so I didn't give him the time he deserved.
Basically what I answered him was:

"Just Google It..."

Fast forward a couple of months.
I am scrolling through Twitter and see an interesting discussion.
The subject is not relevant here but the discussion was between 2 people who seemed to be experts on the topic.
Me being me, I asked for more resources, eager to learn more.
I got a simple and straight answer:

Just Google It, we do not have to do the work for you."

... thanks?

Giving vs Receiving

Looking back at those two moments, it started to realize two things.

Telling my junior colleague to Just Google It was easy, too easy.
Being new to the senior role, I hadn't yet realized the full scope of my new assignment.
And with 3 words, I was able to go back to my tasks like I never became a senior.

Being on the receiving side however, being the one with the questions, this doesn't feel good at all.
The motivation and eagerness to learn were somewhat replaced by other emotions, like anger, sadness... feelings which lead to the Dark Side.
I decided not to look into the subject at all and moved on to other things.

Considering this, I reflected on my own behaviour. How did those 3 simple words impact my colleague?
Did he feel the same way I felt after being "Just Google It"'d? Perhaps he did.

Impact of "Just Google It"

So... what happens when you tell someone to "Just Google It"?

We live in an age where software engineers know where to get information.
People know how to Google and most of the time they already tried Googling for an answer before they asked you a question.
At that point, telling them to just look it up online is almost an insult.
In a way, you are telling them they are incompetent, unable to do the simple thing of looking up some information online.

We all struggle to get something working on almost a daily basis.
Either it's because CSS is being annoying or because you are trying to run 3 different Java versions at the same time.
Not getting any help when struggling might leave you desperate and ready to quit. Is it an good working environment when your motivation is perpetually drained by your senior developer not taking the time to help you? Not very likely.

There is one thing I see a lot of junior developers struggle with: Being able to speak up when they get stuck.
A few years ago there was one junior colleague who was visibly struggling with this. He would just sit at his desk, head in in his hands, trying to figure out a problem. During a 1-on-1 talk I had with him, he explained the reason for his behaviour.

Bothering you with questions just makes me feel like a junior developer
- a junior developer

If someone asks you a question, in a very real sense, they are looking up to you.
They turn to you for expertise. They want to learn from you.
If all you do is say they should look it up online, this will impact how they view you. No matter how great your skills are, they will turn to someone else who actually helps them.

A Positive Change

While sending your colleague a "let me google that for you" link can be funny when done in good sport, it can be taken badly as well.
So just how do we turn this situation into a Win/Win situation:

Instead of saying "Just Google It", ask them "What are the things you have tried already?" or "What is holding you back? There is a big chance they'll show you an entire search history filled with information related to the problem.
If you already have an idea on how to solve the issue, try out your solution together by pair programming. Not only are you solving the problem, you are sharing what you know at the same time. Great return-on-investment if you ask me.
If the issue is vague or you don't know the answer, try Googling together. You might be using different terminology leading to better search results. This also helps your colleague to get better results in the future. It also shows you don't know everything either (despite them thinking you do...), helping to create an environment where it is OK to not know something.

As senior developers it isn't our job to solve the next issue. It is our job to enable our team to build amazing software.
We can do this by helping them out, guiding them through the ocean of information available on the internet, share what we know.
Foster a safe environment where it is normal to express doubts and fears, where asking questions is seen as an opportunity to learn for all parties involved.
Don't just disregard questions and uncertainties of your teammates.

In short, it is pretty clear: "Just Google It" is Just Not Enough.

Burnout: Looking the monster in the eye

Tom Cools — Wed, 05 Feb 2020 13:27:46 +0000

Early september 2019, it finally happened.
I had been ignoring the warning signs for years.
Instead of pacing myself for the marathon which is a career, I sprinted, running ever faster, harder, better... only to fall on my face.
I had burned out.

That was 4 months ago and I have started working a couple of days a week now.
As we reach this phase of my recovery, I want to take the time to list some of the things which helped me get back on top.

Some ground rules

There are a lot of blogs who talk about burnout without further context. To avoid the same trap, here are some baselines for this post.

Blog posts (including this one) are not replacements for professional help. Most of the activities in this post were suggested or inspired by my psychologist.
The books, videos and activities listed in this post helped me. We are all unique individuals and discovering what works for you is your own personal journey... but maybe some of my stuff will inspire you.
This post is not about work re-integration, both because I'm just starting that phase and your work situation might be very different from mine.

Looking the monster in the eye

During one of our first sessions, my psychologist and I went over a questionnaire.
I got top marks! Unfortunately, the questions were derived from the Maslach Burnout Inventory, the most recognized test for Burnout.

You can do a semi-official test here.
If you take this test and are troubled by the result, consult a professional.

After a week or 2 of growing some acceptance for my situation, my psychologist and I found that the best next step would be to learn more about burnout.
She gave me the notes she had from a recent seminar, which were a good starting point but a bit too academical for my liking (and current state of mind). After some searching I did find some other sources to learn from which I will share with you here.

Video: Understanding Burnout - Prof. Christina Maslach (U.C. Berkeley)

Who better to tell you a bit more about burnout than one of the co-authors of the Maslach Burnout Inventory?
Prof. Christina Maslach is well known as one of the pioneers in work-related burnout.
In this video she focuses a lot on a mismatch between person and job, which I didn't really relate to. It does give a nice introduction to the problem.

Book: Overcoming burnout in 30 days - Carien Karsten

The title of this book should have been "Overcoming burnout in 30 steps", as even the author herself admits in the opening chapter that for most people it will take longer. (Hurray for marketing...)
Despite this, the book offers a great balance between practical advice and (simplified) scientific information.

This is not a book you read in a single day. Every chapter is chore, in a good way.
Getting out of a burnout requires serious effort and thought. In that sense, this book could be considered to be more of a workout plan than a magazine to leisurely browse through.

Video: The Burnout Gamble - Hamza Khan

There are a lot of talks about Burnout on Youtube.
I watched nearly all of them, at least the ones the algorithms allowed me to find.
A lot of them are quick fix-style talks, talking about this one thing you can change to make it all better.
Others were incredibly personal experiences where it seems to be more important for the speaker to have an audience, someone to listen to what happend to them than it is to say something of value.

Amids all of this, there is one talk that stood out. While it did seem to start off as just another personal story, Hamza's story is meant to reinforce his message, it is not the core of the talk.
He explains the different phases of burnout and gives some practical advice on how to move forward.
All while pulling in references to greek mythology, basketball legends and casino-style gambling.

Hamza's talk resonated with me a lot because I consider myself to be a recovering overachiever.
I too kept going while everyone around me told me I was doing more than enough already.
Wether you fall into this same group or not, I believe this is a must-see.

It's not the fire that's the problem,
it is the absence of the fire that's the issue. - Hamza Khan

I have not yet read Hamza's book (The Burnout Gamble) but if it is as entertaining and revealing as his talks, it should be a great read.

The Round-Up

These are the top 3 resources which gave me more insight into burnout.
If you want to learn more, I think some of Prof. Christina Maslach's books or even some of her papers are a safe bet.

In the next post, I will write about some activities which helped me recharge my batteries again.
If you have anything else burnout-related you would like me to talk about, leave a note in the comments.

Take care out there and love yourself! <3