May 14, 2020
I’ve been writing more and more Haskell lately, as part of a side project involving GraphQL. As part of working with the language, I’ve had to work with its compile errors. The Haskell compiler gives you errors that are extremely informative—if you know the language. If you don’t know the language very well, the compiler errors can occasionally be opaque and unhelpful.
I’ve very much enjoyed using Haskell, and I figure the best way for me to give back to the community is to make this situation a little better. In order to do this, we’re going to take a fun dive into Haskell errors, why they’re confusing, and how they might be improved.
This is very much not a literate Haskell file, because none of the snippets within will actually compile! You can discuss this post here.
On the internet, it isn’t particularly hard to find technology postmortems. Some of them are from large, venture-funded companies which eventually keeled over and died after the investors ran out of confidence and the bank account ran out of money. Others are from open-source initiatives that failed to find a footing and drifted off into darkness until their creator decided to turn the lights off for good. And others are much more personal, the story of a small, not-well-funded team that couldn’t quite get up to snuff. The term originates in medicine, where it describes a detailed account of all the things that eventually lead to the death of a patient. Such reports aren’t written unless there’s a need to. There’s no knowledge to be gained from an obese man in his late seventies succumbing to heart disease, or a trauma patient simply dying after succumbing to injuries no human can survive. If the cause of death is obvious, a postmortem report is frivolous. All of my previous failures, I believe, fell under this particular category. I’ve never felt a need to write a postmortem for them because it was obvious, even to me, why they did not succeed.
I graduated college with a Bachelor’s in Computer Science in December of 2017, after studying for five semesters plus two summer classes. Instead of going the typical route and trying to find a job immediately, I decided that I would embark on a project of my own, take another stab at entrepreneurship, and try to pursue a dream I remember having as a child. I was going to make a video game, and a good one at that, and I was going to sell it on steam and turn its moderate success into a fledgling indie studio. Unfortunately, however, I find myself in the morgue, staring down at my game’s corpse and trying to decide if it’s worth the time and effort to investigate exactly how it died.
In this case I’m not quite sure if I’m even writing a postmortem, or if it’s a sort of obituary. I’ll admit openly that I am partially writing this for emotional closure and not purely as an objective report so that I may discover why and how this project died. Still, I do think there is some value to be gained in organizing my thoughts on the matter. So, without further ado, let us examine my failed attempt at game development, so we can try to pinpoint exactly where things went wrong.
Apr 26, 2018
Let’s say you’re building a modern web app. You’re using react, you’re set up with webpack code splitting, you render stuff on the server-side, everything is awesome. Even better, your dependencies are really lean-and-mean: you fetch stuff as you go, so the initial bundle is very small!
You might run into a problem, though, if you need to render user-generated Markdown. You’re already using the excellent react-markdown library, so that’s all working fine, but the recommended way to do syntax highlighting has the rather large problem that you need to manually require the languages you want to use. Worse, they’re all bundled together.
You don’t want this. You want to be able to deliver no highlighting code, then allow the user to dynamically fetch the required highlighting files, like how the rest of your app works. Ideally, you even want it to render a non-highlighted version first, then switch to the highlighted one when its ready. How might this get done?
Mar 21, 2018
Recently, I’ve been working on a 2D game. Full-time, in fact: I recently graduated early, and I figured I might as well take a year and a half to work on this project before getting a “real” job. I initially started creating a game in Unity, however, I quickly realized that I didn’t actually like the engine. I actually disliked it fairly heavily, and it was hurting my productivity. So, naturally, my next thought was to code the game from scratch.
The natural choice for this was C++. I messed around with making a 2D engine before and enjoyed it, even if I didn’t actually get very far. I took a bit of a different approach this time, intentionally trying to make a game instead of an engine. However, that doesn’t mean that I don’t occasionally encounter engine-dev-related problems. One interesting recent one: optimizing a component of my ECS system.
Nov 7, 2017
Over the last few years, I’ve become progressively more interested in tabletop games. As a result, I’ve been playing more of them—and thus rolling more dice. Now, as with any game of chance, occasionally luck isn’t in my favor and and I’ll consistently do much lower damage than I feel like I should. When you do 5 damage on an attack that averages 16, it feels pretty awful. I, however, wanted to know more. I wanted to know exaclty how unlucky I was getting. Being a programmer, my solution, naturally, was to write some code to do so.