TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Added some social media integration

Got slightly annoyed when I shared a link to an old post and twitter didn't do anything nice with it. So, now it should.

This is the biggest blog update I've done in a while... despite only being like 30 lines of diff, most of which echoing the meta tags themselves (thanks to this getting started reference), my PHP has gotten rusty, and it took longer than it should have. Also discovered my error setup that emails me when an error occurred isn't working anymore, so I needed to fix that. And a few other maintenance things -- my cookie/session handling logic needs an overhaul later, it's not using secure defaults.

Maybe it's just time for that rewrite after all. =P

See Full Post and Comments

Two problems addressed by an issue tracker, testing, and code review

I haven't been coding much since "retirement". A bit here and there, and I enjoy it every time, but sometimes I'll go weeks without doing any. Still, what little I've done, I've recognized some insights about myself and the way I write software that I might not necessarily have fully gained if I still had employment. It's nothing mind-blowing, I'm sure many programmers either realize something similar already, or just don't have the same problems. (Parts of the methodologies of professional development try to prevent the problems from arising, and you can make use of those as an amateur/hobbyist/out-of-worker just fine, as we'll see.)

The way to approach this is by noticing two "problems". They both stem from the fact that left to my own devices, my development flow naturally drifts towards a lazy style reminiscent of when I first started programming and didn't know any discipline to make things better. Sometimes that's fine, you can just brute-force it, and indeed that's how many of the things I did got done. An example of this style is not using version control much -- just develop the whole thing until it's ready, then commit it and ship it! Once I have a "base thing" though, I can then more easily apply some discipline, so the two problems I'm now going to highlight come most strongly in the earlier phase.

The first problem I found nicely described by this old blog: Imagination Overrun. The second problem is also described there, Knowing When You're Done.

See Full Post and Comments

Six-month early "retirement" report

Today I read The 2021 Early-Retirement Update since it showed up on HN. This prompted me to write a bit about my current situation -- admittedly not a report (I lied), mostly just a few quick and useless thoughts.

It always bemuses me when I see people figure out something like "There’s so much left of life, so much that will change, so much that will deviate from peoples’ original plans." The only constant is change! Yet here we are, someone careful enough in their thinking to pull off FIRE, who has probably read a lot, and yet this insight is new to them at the age of 41. (They're 43 now.)

So I'll write down some of my own thoughts I had well-before I hit the trigger to quit. (Last September was my final month, just in time for my 30th birthday on October 2nd.) These thoughts are what I think gave me the basis to be as "eyes open" about things as I could have. Maybe they'll be amusing for others to read too.

See Full Post and Comments

Hello World to get with the times using SDL2 and Common Lisp

Long ago I learned how to program simple 2D games using PyGame. PyGame was built around a C library, SDL 1.2, and both presented a very attractive model for programming 2D games that followed from some old-school techniques. Specifically, the structure of your game was built on the assumption of a single CPU talking to a video memory buffer used by the display to show pixels. If you wanted to make a 3D game, you could do it classically with a pure software renderer, controlling every pixel. Of course to be more useful SDL allowed you to setup an OpenGL context, so you could make a 3D game taking advantage of graphics cards, but you'd do it with OpenGL; SDL wouldn't help you with the actual video part of that, though it remained very useful for input polling, sound, and other game programming aspects.

Times have changed, and almost everyone has some sort of 3D acceleration hardware even if it's bundled with their CPU. CPUs have more cores. Resolutions are higher. More people have multiple monitors. The optimal graphics pipeline is very different than it once was. CPUs are also faster, so it's not like you can't do software rendering, but you're leaving a lot of performance on the table that could be used to do more stuff per frame in your game. So SDL2 was made to address modern realities while keeping a nice high level API to create 2D games. Things aren't that different, but now you can get a huge performance boost, because SDL2 will do hardware stuff behind the scenes on your behalf.

I've played with SDL2 a few times since it's been out, and each time left not too satisfied. For some reason I never bothered to read the Migration Guide. Reading it this time I've convinced myself SDL2 is the right approach and worth relearning a few things and changing approaches to take advantage of it. In other words it's time to get with the times. The guide also explains the main approaches people have used to make 2D games and how each approach can be, with few drastic changes, done just fine with SDL2, but now can be much faster.

See Full Post and Comments

Draft - vim Introduction and My Setup

Note: This blog entry is in a draft state and given my laziness likely to stay that way indefinitely.. In particular the "trying to program" bits at the end are just notes of how I want to flesh them out. Maybe I'll write them up at some point -- if I do they'll probably be separate posts and I'll edit this one to link to them.




It seems everyone who uses vim eventually winds up writing something like this... Out of the box, vim (and its long-ago predecessor vi) are very capable for their primary purpose: editing text. But vim has a powerful extension system, making it capable of so much more. In addition, the out of the box stuff is very configurable, so even if you install no new plugins, you can spend a lot of time tweaking the settings to get what you like. As such, this is my vim setup. Your preferences may very well be, and may very well should be, different.

See Full Post and Comments

Some thoughts on test automation

I found an old piece of paper from ~2014 that had some bullet points on testing philosophy I had back then, mostly to help myself articulate things in interviews. Reading through the list I still believe a lot of them, but others not so much or I have more qualifications. Let's look at them, elaborate, and add some thoughts not present then.

* Code should be designed for testing -- create hooks/test points (if hardware) if necessary. Want to facilitate "white-box" testing.

Mostly makes sense to me. This has larger implications though depending on language and test type and how exactly you're designing for tests. The very worst design idea is to have code like "isRunningTests()", and to make worst worse have code inside such blocks doing things like "getTestContext().getProperty("blah")" to use for the code instead of whatever the real thing was.

See Full Post and Comments

IT'S OVER 9000!!!!!

What?! 9000?!

(I only get to do this once.)

See Full Post and Comments