CodeMash 2024 was Jan 11th and 12th this year, and this marked the first time I've gone since 2015 when I did a talk called "The Cartography of Testing". That's 9 years! I couldn't believe it had been that long. It was great to be back and see old friends, meet some new people, and oh also there were sessions ;)

There were some good sessions, and here are my notes about those.

CodeMash Session Notes

Don't Build a Distributed Monolith - "J" Tower

Microservices continue to be all the rage. There were quite a number of microservice related talks at CodeMash this year. I think they're over hyped, over advertised, and over used. But truly, what do I know?

I liked Tower's talk, cause the first 10 minutes were basically about why you probably don't need microservices. He introduced some new-to-me terms of including "Modular Monolith", which is basically just a well organized code base as far as I gathered, and "Distributed Monolith", which is microservices done poorly so you get all the downsides of a monolith and the downsides of microservices.

The talk went into the "10 problems" of microservices. My biggest take away was the importance of microservices being built on an Event Bus/Service Bus via asynchronous event-based communication instead of them calling each other synchronously. I don't remember coming away from the Building Microservices book with that a strong take away, so I found that useful (I'm not saying it isn't in there, I just don't remember, it's been awhile).

A Contrarian View of Software Architecture - Jeremy Miller

This was a fun one. Talk was mostly about the pitfalls of Clean Architecture and other similar architectures like hexagonal, onion, etc. To be honest, I didn't find there to be a ton of substance here, but I definitely agreed with most of Jeremy's points, and I was happy to see that our architecture at work seemed to me to be a near neighbor to what Jeremy described.

The biggest take away here, and by the far the most important and probably impactful thing from the conference was a reference to James Shore's article Testing Without Mocks. I'm still working my way through this article, but so far, my jaw is on the floor at how complete it is. I'm not sure I like all of what it is proposing yet, but I KNOW I'll benefit from so many of the terms it defines. So many subtleties that I discuss with co-workers all the time, but I have certainly not been clever or thorough enough to give names to them or so clearly describe.

Dev Containers. What are they and why do you need them? - Joseph Guadagno

I really need to learn Docker. I readily admit, it's one of those things that I think I mostly understand, but at the same time I have no idea how to get started or what I should be doing with them. So, obviously, I really don't understand.

This talk was a quick demo of setting up and using Dev Containers in VS Code. It ended with a demo of editing a file on github in the browser inside VS Code, in the browser, and then github actions running the container and building and deploying a website. Very impressive.

I think Dev Containers are just Docker, but with editor integration? But maybe there is more to it than that too? See, I'm still confused. But I did go home after the conference and try to setup a dev container for this blog. Which worked, except that watch didn't work, and I couldn't figure out why, so I stopped using it. :\

Out of Control: How to Rescue a Struggling Software Project - Cory House

A talk about Cory's experience as a consultant being called into struggling projects and what he sees going wrong and what seems to help. Some of this was fairly standard DevOps type stuff, like Continuous Integration. And Cory referenced DORA: DevOps Research and Assessment as a treasure trove of DevOps practices that I still intend to check out.

One line that really stuck with me was about how to deal with "legacy" code, specifically around the problem of identifying it so people on your team recognize it is legacy code that they should not copy and paste. The line was "The stuff in here is necessary, but it's not our future." I like that. So often the internet settles for over simplifications like "rewrite it all".

The most contentious thing was Cory's suggestion to make one person on your team responsible for the quality of the code base. I get the argument, but I didn't resonate with me. I think it would work, but I think it works because it forces collaboration by making everything go through a single person. I'd rather find ways to enable and encourage collaboration without centralizing it.

Another thing was Cory talked about having such thorough Playwright or Cypress tests on the frontend, that must have been very fast running, that they had such confidence in the tests they didn't even bother running the app and manually testing it for some changes. To be honest, I can't even imagine that world.

Building Event Driven User Interfaces - Sam Ferree

This was a cool talk. It was basically like, what if we tried a different approach to our UI architecture, what would it be like? In this case, the approach was to apply the event bus driven microservices architecture we see on the backend to the front end. Sam demoed a Blazer UI using custom Javascript events and state machines and it was pretty neat. I saw a similar thing mentioned in another talk later in the day too.

I'm not sure if I was fully sold though. Sam started out by referencing the Elm Architecture, or any centralized state Model View Update (MVU) reducer based architecture, and basically just said, "I don't like it". I was willing to go along, but every step of the demo I just kept thinking how it was basically the same thing as the Elm Architecture.

One thing I liked, but that also illustrates this point, was a component that executed a fetch request. It did it by fetching, and when the results were returned, firing an event with the results instead of immediately handling them. That way, the same component could hook the "results have arrived event", but other components could too. Very neat. But isn't that exactly how Elm works too?

I really liked the state machine code though. I think I'm going to need to spend some time getting more familiar with that.

Beyond Request/Response: Why and how we should change the way we build web applications - Chris Nelson

I think this was my favorite talk. Very well delivered, set the idea in good context, and was something totally and compellingly new (to me).

Chris started with an overview of the history of web architectures. I loved that, I do a little spiel when we on board new devs on our team that I call my Brief History of the Web, so it was fun to see someone else cover it in a really similar way and for the same reasons. He ended by pointing out that when we build SPA-type web front ends, we are writing a distributed application. And Martin Fowler's first rule of distributed objects is "don't distribute your objects" (now, Fowler was really talking about CORBA, which is a pattern you really don't see anywhere any more). The point is that when you have to distribute your state between systems, like we have to do when we write a front end app that communicates with a backend app, we're increasing the complexity of the system alot.

Chris' solution? Open a web socket between the frontend and backend and basically do the Elm Architecture but with all of your state and reducer logic completely on the backend, and the frontend just dispatching "events" and receiving state updates. It was honestly jaw dropping.

Chris demoed a library he wrote called LiveState which is built on Elixer/Erlang. A lot of the demo seemed to heavily rely on capabilities of Elixer, so right now it's not all clear to me if this at all practical in .NET right now. And I don't know websockets well, so I don't think I understand what the risks and downsides would be of building fully on that (scale? performance? network reliability?).

But all that said, it was amazing tech. And the ability to get the kind of rich interactivity of "rich clients in the browser" with the simplicity of MVC style code structures would be a huge deal.

You Are the Pilot: Getting Better with Code Gen AI Tools - Sam Wedig

Last session was a demo of how to use ChatGPT and Co-Pilot in your development. Obviously this has been all over the news lately, but not something I'd seriously explored. I really enjoyed Sam's demo, he did a great job of highlighting what it is and is not good at right now, and also really showing how to use it while coding.

Honestly, I came out not being terribly overwhelmed or impressed. I was a bit more interested in the ChatGPT approach of "tell it how you want it update the code". I didn't think I'd like the magic auto complete approach of Co-Pilot where it's trying to guess what you're thinking of doing next and often not getting it right at all.

Conclusion

As usual, there were some really bad sessions too. Lots of time slots I tried popping into different talks. The "rule of two feet" as they used to say at CodeMash, meaning, feel free to leave if it's not for you. And a few where I ended up bailing completely. But, that comes with the territory of a community oriented conference. And to be honest, it comes with having done talks of my own, where I spent ridiculous hours writing and practicing over and over. It shouldn't matter, but I'd be lying if I said that didn't make it hard for me to sit patiently through some talks. But that's really more my issue.

And, I'm glad I took the time to write this up, cause I'm quite impressed with all the stuff above that felt worth writing up. And focusing on the great stuff like this does help balance the not as great stuff.

So CodeMash continues to be a good conference. Keep it in mind next year and maybe I'll see you there!