All of my blog posts shall live on my homepage. Although this decision might make the blog unreadable, I like the idea of treating this page like it is a huge structured log of data that you parse through like anything else. Here is a command to find all of my available articles:

curl https://bipol.me/ | \
grep -o '"#.*"' | \
cut -d '"' -f2 | \
sed 's/^/https:\/\/bipol.me\//'

This command is less than ideal since grep is going match the text in my command above as well. That is kinda neat. Going to have to noodle on this a bit more I think! EDIT: 04/28/2020 I was thinking about this a bit more, and decided that it might be worth adding some metadata elements to my posts, instead of just parsing the ids directly. HTML 5 allows you to specify data attributes which can mean, well, anything you want. In this case, I'm adding the attirbute data-blog-slug to all of my titles, which will match the anchor of the blog post. Thus, you get this, which is probably worse than before.

curl https://bipol.me/ | \
grep -Eo "data-blog-slug=\"[^\"]+\"" | \
grep -o '"#.*"' | \
cut -d '"' -f2 | \
sed 's/^/https:\/\/bipol.me\//'

I’ve been working on a project with a few friends of mine called SMARTA. We’re investigating the ways that we can improve the ridership of MARTA (Atlanta’s transit authority) through technology. We are all avid users of public transit (well, we were until all of this happened) and are pretty passionate about our quest to make using MARTA easier for everyone. MARTA released a few endpoints that are accessible to a developer, all of which can be found here. This includes some real-time bus data leveraging GTFS (Google's Transit Specification) and a "restful" API providing information for train and bus arrival times. This API can be a bit confusing since it is completely undocumented (save for a few brief snippets of prose on the API website). Furthermore, the data itself seems pretty old (it refers to OMNI STATION which is very deprecated), and the service is not very resilient. You'll often find periods of empty responses due to an outage with no clear indicator for the developer to react to. Given all this, we've set out to build a new set of API endpoints we call third rail. Third Rail will be a pass-through to existing MARTA data, but with a layer of caching and predictability that MARTA currently lacks. Additionally, we'll provide full documentation for every endpoint with predictable and modern translations of the existing response. In addition to that, we're looking into building out predictive systems that will ingest MARTA's historical data (which is backed up by a service called scrapedumper) and deliver insights to a rider about delays. All of this will be baked into an iOS application that we're developing so that riders will have this data at their fingertips. I'm using this project to let me play with software architecture and product design. Hopefully, this will fuel more blog posts to give me something to talk about, too.

I've been trying to be more intentional with self-development, but I'm still figuring out exactly what I want to learn. To help focus these thoughts, I'm going to spend some time enumerating what I'd like to learn and how I'm going to achieve it. I think the intended audience for this post (and maybe everything I write) is just me. Programming Fundamentals I have always been a big fan of Gary Bernhardt's destroyallsoftware.com screencasts. He sort of helped architect the way I began programming, specifically in my early vim + screen workflow for web development. His screencasts are succinct and packed with useful information, and as a new bright-eyed engineer, they gave me a lot of hope that one day I'd be able to look as productive as he did on video. Anyway, I've resubscribed to his content, specifically so I can rewatch all of his screencasts and use his new tool, executeprogram.com. Databases I never dive too deeply into databases even though I work with them every day. executeprogram.com has a fun little SQL course that I've been going through - mainly to help reinforce my muscle memory around common SQL commands. Additionally, a coworker recommended use-the-index-luke.com/ as another resource to learn about database internals. Communication This skill is invaluable in almost everything I do. I hope that blogging will help me flex these muscles a bit more, specifically with communicating technical subjects. Watching Gary's screencasts also helps with this due to his strong communication skills. Ensuring that I'm always prepared with notes for meetings and am well engaged in them will help me practice this as well.

oh boy, have things been a bummer. What have I been doing? Working on smarta still, specifically the healthcheck service which should grant us a teensy bit of observability and alerting. The gist is that our services can expose a /healthcheck endpoint that the healthcheck service will check on - if a 200 is received, everythings peachy. Anything else and we'll alert. You can also return a specific bit of JSON to add more nuance to the state of the service by specifying a set of subservices and their health. Design doc sort of thingy can be found here. I've been extremely slow with shipping code here, and have been having a lot of difficulty finding motivation. Burnout sucks. How did my whole what i should learn stuff go? Well, not as well. I definitely spent some time watching the screencasts and working on the executeprogram courses (both of which I highly recommend). Never really got into database stuff, which I'm still interested in.