Stir Trek 2022

I had a ton of fun and learned a lot at Stir Trek this year! And experiencing the in-person conference was really cool after last year's virtual conference.

I went to a lot of interesting sessions this year, and my notes on the sessions are below. They're mostly for my own reference later, but others might find them useful, so I've shared them here. However, my notes do not do these amazing speakers justice!

The Spy of Testadel: A Medieval Unit Testing Tale - Phillipe Vaillancourt

This talk was an introduction to principles of unit testing and different ways to make code more testable, and testing difficult-to-test code. The unique framing of this topic in a medieval story of knights and kings and spies was extremely effective, and I learned a lot:

• In computer science, a "side effect" is "a change made by a function to the state of things outside that function's scope"

  • usually has a bad connotation outside of computer science
  • however, side effects are necessary in computer science for things like input/output, so they are not inherently bad, but they are difficult to test

• pure functions are deterministic functions with no side effects

  • deterministic = function gives identical return values for identical arguments
  • pure functions are generally simple, short, and easy to test, so it is usually a good idea to encapsulate logic in pure functions where possible

• dependency injection is like sending in a spy

  • we can instantiate our own version of a class and send it in to investigate what's happening in another class in unit tests

Clean Architecture with ASP.NET Core 6 - Steve Smith

In this talk, Steve Smith gave an in-depth overview of clean architecture, starting with an explanation of the principles behind it, then going into the specifics of its implementation:

• Follow good coding principles

  • Separation of Concerns
  • Single Responsibility Principle
  • DRY
  • Dependency Inversion Principle
  • dependency inversion allows flexibility and easier/better testing, and it avoids tight coupling
  • Explicit Dependencies
  • ask for all dependencies in constructor
  • i.e. list all ingredients up front, like a recipe does
• Architecture should facilitate a "pit of success"

• The Core Project is the domain model

  • contains: interfaces, entities, value objects, aggregates, domain services, custom exceptions, domain events, event handlers, specifications
  • avoids dependencies, and does not have dependencies on Infrastructure

• Infrastructure project

  • contains: repositories, EF Core, DB Context, web app clients, file system accessors, logging adapters, email/SMS adapters, system clock wrapping, other services
  • implements caching, etc.

• Web project

  • contains: controllers/views or Razor Pages, DTOs/ViewModels/API Models, Filters, Binders, Tag/HTML Helpers

• Shared Kernel

  • collection of code used between projects in a solution
  • contains: base abstractions/types, common interfaces, dependency injection helpers
  • Should not depend on

Don't Build a Districuted Monolith - How to Avoid Doing Microservices Completely Wrong - Jonathan "J." Tower

• monolith = having all the code in one place, with every piece interconnected with the other pieces

  • not necessarily a bad thing
• microservices = independently deployable, decoupled services
• in a distributed monolith, you have microservices, but they are interconnected or all use the same database
• you should only use microservices if you have a good reason, because they are very hard to get right
• microservices are good if you need to update often with minimal downtime and/or if you need separate/autonomous teams
• separate your microservices based on sub-domains
• minimize both service size and required communication between services

• can use "strangler fig" pattern to migrate from monolith to microservices

  • put facade in front to direct traffic either to legacy monolith or modern microservices application, depending on which components have been migrated, then gradually migrate functionality from monolith to microservices
• remember that microservices can be too small, since smaller microservices may end up needing lots of communication, which ends up resulting in a distributed monolith

Where Has Jane Gone? - Karen Linden

This was the first of two talks I attended this year discussing the experience of women in the tech industry. This was a very engrossing presentation, so I didn't take many notes, but here are some of my key takeaways:

• didn't agree with all of it, but I thought she made a lot of really interesting points
• I liked that the conversation was being held and that Stir Trek was making a space for that conversation
• she cited a lot of very intersting studies and statistics about how the underrepresentation of women is a cultural/systemic problem not limited to the tech industry

Explore the Why Behind Insufficient Representation from Women in Technology - Taranjeet Kaur

While Linden's talk focused more on her personal experiences, Kaur focused more on the statistics and how we can go about making things better.

• culture associates "feminine" qualities like being introverted/quiet with not being successful in technology
• there are no gender differences in math skills from grades 2-11 - so where is the gap?

• 3 steps to fix the problem:

  • define problem statement clearly
  • define inputs that can produce differences in output
  • remove the factors causing the issues
• pattern recognition is reall yimportant, but as a culture we put different patterns in front of girls than in front of boys

• the only profession coming close to the gender gap in engineering is stand-up comedian

  • both careers are about recognizing patterns/incongruities in the system

• the behavior that gets rewarded will get repeated, so you have to reward the right behavior

  • currently, the system works better for women who act more "feminine"

• steps that work for women in stem - how do we fix the problem?

  • lots of influences - parents/siblings, teachers/coaches, colleagues/bosses
  • spark interests for girls at a young age
  • get educational institutions on board
  • hiring is the beginning - you have to support women beyond that
  • as a woman in tech, share your story, be visible, and support the women in tech around you
  • stand up for women in tech

Project Zero or Removing Barriers for Creating OSS Libraries - Jimmy Byrd

This talk discussed creating open source libraries and the many, many small but important components of such libraries, such as useful README files/documentation, licenses, robust .gitignore files, and of course the actual functionality of the library

Conclusion

I really enjoyed Stir Trek and learned a ton! It was also a really good experience for me to see just how much there is about software engineering that I had never thought about or never really understood. You don't know what you don't know.

After Stir Trek last year, I wrote:

Previously, I'd only associated Stir Trek with my dad getting to see all the Marvel movies before I did; I'm glad now to have had my own experience with it, though I was somewhat disappointed in the lack of Marvel movies. But that is, of course, more Covid's fault than Stir Trek's! Hopefully in the not-too-distant future, I'll get to attend a Stir Trek in person, Marvel movie and all.

This year, I was really excited to see Doctor Strange in the Multiverse of Madness on opening day, which was really cool, and it meant that I was able to watch the movie at the same time as my dad, rather than having to wait until after he saw it.

I hope I'll be able to attend Stir Trek next year, as it was a phenomenal experience, and I'd love to go again!

Thanks for reading! I hope you find this and other articles here at ilyanaDev helpful! Be sure to follow me on Twitter @ilyanaDev.

Tags

• software development
• stir trek
• conferences