I live in a small town that occasionally broadcasts announcements over the radio. For the past few years, I’ve been building a small Raspberry Pi appliance to transcribe these broadcasts to text. However, there are many broadcasts that don’t contain spoken content, so I wanted a way to recognize the kind of broadcast and make a decision whether to send it to the speech-to-text service or not.
Happy New Year! For the past few years, I’ve been using the year-end break to reflect on the past year and set a theme for the next. Last year, I was mainly focused on doing work at Geolonia and increasing the amount of output in terms of blog posts.
My theme for this year is experimentation. While I’m going to continue working on output – this time, with more focus on my personal blog – I want to work on running focused, meaningful experiements. I generally enjoy trying new things and playing with new toys, but this year, the focus will be less on the playing and more on actually learning from these experiments. I’ve found that I can learn from playing around, but I struggle with deciding when to move on, or whether I should stick around and keep on iterating.
However, updates on this personal blog has been not so great – the previous post is the “2023 review” post, after all.
I’ve been updating this blog from 2012, when we officially incorporated Flagship. I have since left Flagship, but it has a special place in my heart as it was where I learned how to bridge between programming and delivering results.
This year was an eventful year. The biggest event was by far moving from Tokyo to Yakushima, but there were a lot of other events that happened this year.
We made the move at the end of February, and my wife and I started out by working in a spare room in her father’s workshop. We then moved our workspace to the house when it was finished around July. During that time, I’ve worked on a few things at Geolonia, including growing the engineering team by a couple people and creating a few new products with the team.
I often get asked why I prefer Terraform over CloudFormation. I just ran into a nitpick of CloudFormation and decided to write this post before I forget about it.
So, I’m currently working on a relatively simple CloudFormation document that includes a CloudFront CDN that is in front of a S3 bucket. It also includes dependencies: the S3 bucket policy and the CloudFront Origin Access Identity. On my first try, I got something wrong in the CloudFront settings. OK, fine, I’ll fix it. It was a silly one-line mistake. Wait for cleanup to finish, removing the S3 bucket. Next, a mistake in the bucket policy. Another simple fix. This time the CloudFront distribution was already created, so I was already waiting for 3-5 minutes (I am so glad that it wasn’t 30 minutes like just a few years ago!). Wait for another 5-10 minutes for the distribution to be deleted and created again.
With the release of the Mac Studio recently – something that, for quite a long time, I thought I had been waiting for – I started thinking about what the ideal desktop environment for me is. This is what I use currently:
A PC (i9-10900k with 32GB of RAM) running Ubuntu, hooked up to a 28-inch 4K monitor.
A MacBook Air (M1, 2020 model)
I used to run macOS on the PC, but that experiment finished after a year or so. It was pretty stable and I had almost no problems, but hardware compatibility and performance was lacking. (Having a very Docker and Linux heavy workload meant that most of the time I was running Linux, virtualized in macOS, anyways, so I thought – hey, it would be better to just run Linux anyways, right?)
I wanted to make some advanced logic available, easily configurable via a database, in a couple apps that I’ve been working on recently.
Honestly, I could have just stored the code in the database and eval’d it – but no, I don’t want to take the risk of arbitrarily executing code. I could have done some gymnastics like running it in a network-less container with defined inputs and outputs. I could have made the configuration more capable. What I decided to do in the end, though, was to write an extremely compact domain-specific language (DSL).
There have been multipleanalyses about the recent (2020/11/25) outage of AWS Kinesis and its cascading failure mode, taking a chunk of AWS services with it – including seemingly unrelated Cognito – due to dependencies hidden to the user. If you haven’t read the official postmortem statement by AWS yet, go read it now.
There are an infinite amount of arguments that can made about cascading failure; I’m not here to talk about that today. I’m here to talk about a time a few years ago I was evaluating a few systems to do event logging. Naturally, Kinesis was in consideration, and our team interviewed an AWS Solution Architect about potential design patterns we could implement, what problems they would solve, what hiccups we may encounter on the way, et cetera.
During the COVID-19 pandemic, schools and daycares have been closed, so my family decided to use this as an opportunity to make some habits to make sure we can get through this period with minimal interruptions to life and work. Here are some habits that have worked so well for us that we’re planning on keeping them, even after the kids go back to school / daycare.
Keeping a schedule
We use a schedule to make sure the time we eat, sleep, and do activities are at regular times every day. At first, I thought this would be a good tool to let the kids know when we were working and when we could play together, but it’s proven to be a useful tool to both adults and children. I’ve written a blog post in Japanese about this as well.
While working on a Ruby project, I often find myself referring to the code of various libraries when it’s easier than looking up the documentation. For this, I used to use code (bundle show GEM_NAME), but recently I’ve been getting this warning:
[DEPRECATED] use `bundle info $GEM_NAME` instead of `bundle show $GEM_NAME`
Okay, that’s fine, but bundle info returns a bunch of stuff that would confuse VS Code:
> bundle info devise
* devise (4.7.1)
Summary: Flexible authentication solution for Rails with Warden
Homepage: https://github.com/plataformatec/devise
Path: /Users/keita/.asdf/installs/ruby/2.7.0/lib/ruby/gems/2.7.0/gems/devise-4.7.1
Luckily there’s bundle info $GEM_NAME --path. code (bundle info devise --path) is kind of long to type out every time, though, so I decided to make an alias.
I’ve written about how to host a single page application (SPA) on AWS using CloudFront and S3 before, using the CloudFront “rewrite not found errors as a 200 response with index.html” trick.
Recently, working on a few serverless apps, I’ve realized that this trick, while quick, isn’t perfect. The specific case where it broke down was when the API is configured as a behavior on CloudFront (I usually scope the API to /api on the same domain as the frontend, so CORS and OPTIONS requests aren’t necessary). If the API returned a 404 Not Found response, CloudFront would rewrite it to 200 OK index.html, and the front-end application would get confused. Unfortunately, CloudFront doesn’t support customized error responses per behavior, so the only way to fix this was to use Lambda@Edge instead.
