I have a personal connection to this natural disaster. My wife has a cousin who lives in Tonga (if you’re wondering about how her cousin ended up there, she was there on [I think it was] a Peace Corps mission and met a guy there with whom she fell in love and eventually married). The last I heard, my wife’s cousin and her family are okay, but they are cut off from the rest of the world.
It’s been a while since I posted a speaking schedule update, and I figured I was overdue.
Right now, I have only one confirmed speaking engagement: the WE Local Conference in Buffalo, NY on April 8-9. Last I checked, the conference schedule still hasn’t been released, so I don’t know if I’m speaking on April 8 or April 9 (all I know is that I’m speaking!). I’m still waiting for the schedule to come out before I make my travel plans!
This will be my first in-person speaking engagement since Rochester SQL Saturday back in February, 2020, just before the start of the COVID pandemic; every presentation I’ve given since then has been virtual. It’ll feel good to get back on the road again!
This week, I was introduced to a new (to me) methodology called the C4 model. Now, in this context, C4 does not refer to the high explosive. In this case, C4 refers to a development methodology. Mostly, it refers to software development, but it has other applications as well, and that includes document development.
As part of my indoctrination into this methodology, I was provided this link. So far, it looks like an interesting read. I’m still reading about it, but here’s my understanding of the methodology thus far.
First of all, C4 stands for context, containers, components, and code. Think of it as looking at something at four different levels, from the top level (context) that shows the big picture, all the way down to the most minute detail (code).
The top level (context) refers to the big picture. Using maps as an example, here is a map of the United States — for purposes of this example, the big picture. You’ll notice that I drew a black box around New York State, which indicates the next level to which I will zoom.
If we want to drill down to the next level (container), a state would be the next logical level. So for the next map, I’m drilling down to my home state of New York. Again, I’m drawing a black box around the area to where I will drill down next.
A city or region is the next logical step (component). Let’s drill down even further, this time to my home city of Troy. Again, I’m drawing a black box around the next level to which I will zoom.
The bottom level of this methodology (code) shows the minute detail. For personal privacy reasons, I’m not using my home location, so instead, I’ll use one of my favorite establishments: Brown’s.
You’ll notice that I did not draw a black box in the last illustration; this is because we are at the lowest level in this model. I suppose if I really wanted to get granular, I could drill down into building floor plans, but for the purposes of this example, I think the point is made.
From how I understand it, the C4 methodology appears to be used for diagramming and documentation. It addresses a shortcoming in many technical diagrams in which they can be confusing and difficult to follow. C4 addresses this by showing how components relate to the big picture.
While I haven’t (yet) come across this in my reading, I want to note something that I think is important. When I captured the maps you see above, I thought it was important to highlight the context to which each level was related. If you look only at the bottom code level, you only see a building and a street (although I did make it a point to also capture the street name and route number). If you don’t know what city or state this place is located, then this macro level is likely useless information. The same is true for technical documents. Each small piece fits into a larger puzzle. If you don’t understand how the puzzle piece fits, you don’t get a sense of how the piece relates to the rest of the puzzle, and it becomes confusing and hard to follow.
As I said, I’m still reading about this, so I’m not yet sure what additional intricacies about the methodology I need to learn. Nevertheless, the concept does sound interesting, and I’m looking forward to learning more about it as I improve my skills as a technical communicator.
Topic: SQL Server Query Performance: Common Problems, Possible Solutions
Identifying which queries are running the slowest, or using the most resources is relatively well documented. However, once you identify the query you need to fix, what are you supposed to do next? This session will walk through a bunch of the most common performance problems and how you go about identifying those problems. From there, we’ll discuss some possible solutions for those problems as a way to move you more quickly to a more highly performing database.
About Grant: Grant Fritchey is a Data Platform MVP with over 20 years’ experience in IT, including time spent in support and development. He has worked with SQL Server since 6.0 back in 1995. He has also developed in VB, VB.NET, C#, and Java. Grant has written books for Apress and Simple-Talk. Grant presents at conferences and user groups, large and small, all over the world. He joined Redgate Software as a product advocate in January 2011.
Our online meeting schedule is as follows:
6:00: General chat, discussion, and announcements
We usually wrap up between 7:30 PM and 8:00 PM.
Please RSVP to this Meetup, then use the online event URL to join (note: you MUST RSVP for the URL to be visible). We will send out a meeting password as we get closer to the event.
Thanks to our sponsor, Datto, for making this event possible!