Hey there

Today I learned about Mermaid, which lets you make diagrams in Markdown! You just make a code block with the type mermaid and then there are several different types of charts you can make. Super useful for throwing a quick chart together. However, in order for this to work on my site (which doesn’t natively support it unlike the VS Code Markdown preview), I need to create a Markdown Render Hook. That means creating layouts/_default/_markup/render-codeblock-mermaid.html (create that dir since it doesn’t exist yet, and the file name is very specific). This loads Mermaid.js from the jsdelivr CDN and makes sure it only loads once. I also need to check the blog theme to match light/dark mode. ...

Private GitLab instance, what can I say?

I don’t have some revolutionary new take on daily standups or anything like that. This isn’t some grand reworking of any part of the agile manifesto. It’s another rant. Eventually, if you’re a developer, you will have to take part of a daily standup call, where everyone has to give an update on the previous day and state what they plan to do during the day. I understand why this is a valuable meeting in the ideal case: everyone on the team gets updated on what everyone else did and is doing without having to repeat themselves. However, very rarely is the ideal case what actually happens. Usually, way too many people end up on the standup call, and then you end up tuning out people you don’t want to listen to, and then you end up tuning out everyone. Which defeats the purpose of the standup. Also, maybe I am not working on a small enough team, or maybe my work is spread out or siloed enough, but very rarely do people give updates on the level that I need. For instance, if I am working on something with one other person, we probably have a pretty similar understanding of approximately what the state of the project is, but I would want to know more details about the last issue that he ran into and how he overcame it. However, since we both feel like we have to give an update that is distilled down for the other 18 people on the call, neither of our updates really end up being that useful to each other, and they are probably being tuned out by the people we are distilling it down for. As soon as the standup is done, I am sending him a message or getting on another call with him anyways, so there was not really a point to the standup. ...

A couple of years ago, I was helping with an acquisition at my company. The company we were acquiring had one product, a B2B web app. One of the things that came up during the first couple of days of reviewing their system setup was their monitoring. They had some very nice looking Grafana dashboards set up. I want to discuss one of them in particular, because I don’t really remember what the others said. It almost doesn’t matter at this point. The title was something like “Number of Errors”, and the developers told us, pretty much verbatim, “As long as the number of errors stays around two hundred thousand, everything is fine”. I didn’t say this at the time, but what I was thinking was “I’m sorry, 200,000?? That’s just a constant amount of errors that are happening at all times??” I should have said it out loud. Then we might have had a more productive discussion about what the variance of that number is. Is 300k “around”? Is 100k “around”? But I was not experienced enough at the time to know that that was a bad way of doing things, even if I may have felt it in my gut, so I just made a note. ...

One thing that I love to do is visit National Parks. Visiting them all is on my bucketlist. Some people really like to collect the cancellation stamps; I am more concerned with witnessing and experienceing all these amazing natural areas. At the time of writing this, there are 63 parks, and I have been to about 18 of them. I say “about” because I am not 100% sure that I went to certain ones since I went when I was a kid (Grand Teton, Haleakala). So I will be going back to make sure that I hit those. But I digress. There are a couple different ways I could track which parks I have gone to. But, perhaps inevitably due to my occupation as a software developer, I have considered storing that information in a database. I thought about putting that info in a SQLite database so I could easily drop it in to various projects if I’m trying a new technology and need some quick data. Sure, I could use a mock data generator like Mockaroo, but it’s fun to have real data sometimes, and also to be reminded of my goal. ...

This is not going to be anything revolutionary, but I have observed this about myself and what works for me. If I have 30 minutes or so between meetings, very little programming work is going to get done in that amount of time. By programming work, I mean the kind of deep work that you get done when you’re in flow state and you aren’t staring at the blank cursor. It ususally seems like it takes 10-15 minutes to get into that state. But I am definitely not going to get into that state if I know that I will only have 15 minutes in that state before my next meeting. So obviously, the best thing to do is to bunch all your meetings together. That’s ideal, but not always possible. Most of my meetings are with people who are in way more meetings than me, and they are always changing the schedule, or running late, or double booked. So what to do when you are essentially subject to someone else’s meeting schedule? ...

I was doing a bit of job searching recently, and I applied to a company throgh a referral from a friend who worked there, so it was a little more high stakes than just a run-of-the-mill interview, as I wanted to leave a good impression at the very minimum. This was a full stack position, and I made it to the technical assessment. There was a database component, a backend component (python), and a front end component (Vue.js). It was a take home assessment and I had 72 hours from the time I started it to finish. I started with the database component, then did the python portion, then finished up with the Vue.js stuff. I spread the work out over the first two days, then took the third day to optimize anything, double check my work, and make sure I didn’t do anything wrong. All my tests passed. I was feeling good about every part of it. I submitted it, and began waiting to hear back. ...

Several years ago, I took over partial data ownership a web application at work. The front end was a mishmash of Javascript and PHP, and the backend was C#. There were some areas for improvement there, but it was workable. However, the most glaring problem was the database. The entire application was backed by as single node Amazon Redshift database. I am here to spread the word: DON’T USE AMAZON REDSHIFT… …as the only database for your entire modern web application. Just because your application is going to be so big that “big data!!1!” (spoiler…the data was not big) does not mean that a columnar database is going to serve the needs of a web application. Let me give a few reasons why. ...

If you’re reading this, that means I was able to get this website up and running. This site is running on the Hugo framework, which is a static site generator written in Go with the PaperMod theme. I have written a static site before with Pelican, which is based on Python. There are static site generators written in all sorts of languages – I tend to gravitate towards the ones that I like for programming, but in reality, the language doesn’t matter as much because most of the writing that I do is some form of markdown. If I wanted to start modifying the workings of the site, or modifying the template itself, then maybe I would dig into the code, but I digress. Here’s a general overview of what I did to get this site off the ground, and how I overcame some snags along the way. ...