Refactoring the Monolith (A CJUG Lightning Talk)

A few weeks ago I did a talk on refactoring monoliths for the Chicago Java Users Group. It was a short lightning talk about some of the alternatives that developers have when refactoring large monoliths. In the talk I went over how the problem came to be, and what some of the alternatives were and their pluses/minuses.

The slides to the talk can be found here:

Why did I do this talk?

This talk was mostly done due to my observation of the cargo-cult reaction to monoliths and reactoring. Yes, the monolith is pretty big and bulky, however it does get the job done. However, the popular opinion about what to do with them is to make a ton of microservices. In the long run, it just turns one monolith into a lot of noisy monoliths.

What did I learn?

The video of the talk hasn’t come out yet, however I feel like I had 2 things that could have been:

  1. Time the talk better. I felt influenced by the prior presenters to rush to finish in an unstated time limit.
  2. More practice could have made this talk smoother.

No Fluff Just Stuff October 2016/Chicago

My workplace sent me to No Fluff Just Stuff to attend the conference. Some of the interesting bits about the conference were:

  • Garbage Collection in the VM
    • Lead to the following questions
      • If there a way to do leak testing in unit tests? (VC++ provides heapdump checking and you can do it there)
      • Where is the memory indexed at?
      • Is it possible to modify the code cache?
    • Ken Sipe is a great speaker and I managed to have lunch with him.
  • Tracer Bullet architecture
    • Advocates slow development (make sure things work on a smaller scale before escalating higher)
    • Some redefining the existing development change process, and some parts naming work patterns.
    • Advocated for many of the circuit breaker/fault resistance that was already baked into Akka
  • LAMBDA Architecture
    • Mostly advocated in a more efficient datacenter using Mesos/DCOS.
  • Metaprogramming and AOP programming with Groovy
    • This was a great talk on how closures can take in state
    • Went over some basic built up on extending the language through Abstract Syntax Transforms
  • Encryption/Security
    • Mostly reviewed encryption algorithms and briefly talked about exploits
    • The talks on the exploits were interesting
    • Oddly enough, the conference talked a lot about the Heartbleed bug.
      • Sidenote: The events and context surrounding this bug are very strange.

Other notes

The conference loaned out conference ipads to keep notes on and rebroadcast the sessions. I found this to be similar to having a laptop in the classroom. Mostly it just led to distraction.

Things I would have liked to see more in the conference

  • Talk some about Scala
    • There were many mentions of Groovy, but other than the Metaprogramming/AOP they were just mentions
  • Discuss things like Akka or new methodologies
  • Try to avoid boilerplate talks on Spring
  • Label the sessions as Intro/Intermediate/Advanced

I gave a technical talk and so should you

Public speaking is a lot trickier than you’d think. It’s not hard, its mentally challenging, however it can be very rewarding. The majority of the population can talk about their interests to their coworkers, friends and family for a long period of time. However, they will struggle to talk to a large amount of people about what they know. It’s a shame, and it’s an odd problem to have and it’s a phobia that some have. It’s a little odd because the perceived threat isn’t a physical attack or something that threatens one’s life.

The common negative perception based on poor performance, making mistakes that are “attributed” to one’s self, and perception from others. The reality of the situation is that even if you do very poorly: It’s incredibly rewarding. In the upside, you may be invited to talk at other places, talk on other subjects, you may be considered a subject matter expert, get paid to give talks, etc. On the worse case of this: You may get stage fright and most people can understand that. Even in the worse case: You gained a huge amount of respect from the audience, and you learned that you have something you can work on and improve.

Recently I gave a quick talk in front of my local technical community. I was encouraged by the local Chicago Java Users group to give a lightning talk. Lightning talks are brief five minute talks on a particular subject. I’ve seen others do lightning talks before and they seem to breeze by fairly quickly. Additionally the format of this isn’t necessarily to show strong talks, but it’s desgined to get people up in front of an audience, and give them a taste at presenting. A friend of mine, Mark Thompson, encouraged me to go through with my talk. My talk was on the Spock Testing Framework and why people should use it. Prior to the talk I was a bit nervous; there were 60-80 people there. During the talk I felt that it didn’t go as smoothly as I thought it would in my head. However, the audience reaction was good, and my feedback was great. I watched the video later: Despite having a few quirks that should get ironed out, I think I did well for my first public technical talk.

Things I learned:

  1. Practice the talk before hand. I believe that I had a few issues during the talk because I hadn’t vocalized what I had planned to speak about
  2. Practice with the equipment that you’re given
  3. Make sure to have it recorded. This will give you valuable feedback later. Luckly for me, this was done by the CJUG crew.
  4. Always have others review your slides (Did that)
  5. Keep your slides as short as possible (I did ok on that)
  6. Dress for the part (Dress up): I could have done much better on this.

Curious about the talk or Spock? If so take a look at the video and feel free to respond with constructive criticism. I’m always willing to listen.

A side note about the talk: I did have something to do with coercing a few colleagues of mine to do a talk. They were: Todd Ginsberg (A short introduction to Akka)  and Mary Grygleski (An introduction into Mule ESB). They did a fantastic job as well!