I’ve noticed before that this build has some issues with scale, but now it’s really hitting home. Some of the details are ridiculously fiddly.
Starting with the faux vacuum tubes; Not too bad, just smaller than any real vacuum tubes would be, and even then they aren’t actually fully shown from behind the grill.
So that happened. And I spent much longer than should’ve been necessary to figure it out. What I was trying to do was this:
I’d already set the following permissions:
kms:GenerateDataKeyPairWithoutPlaintext
secretsmanager:DescribeSecret
secretsmanager:CreateSecret
What I had neglected was the fact that Secrets Manager needs permissions to use the CMK. Adding these two helped:
kms:GenerateDataKey
kms:Decrypt
This is documented in https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html , under “Authorizing Use of the CMK”.
I’ve added some more detail. Now I think this is getting to stage where there will be no more major changes, and where the next prints will the final pieces.
Here’s another one of my projects that has been on the back burner for quite a while: A replica Pip-Boy 2000, as originally seen in Fallout 1, Fallout 2 and Fallout Tactics (with minor differences). I’m designing the prop in Blender, and mostly 3d-printing the parts. The Pip-Boy will be powered by a Raspberry Pi with a 5″ LCD.
The finished product
TL;DR: It’s a dedicated desktop Pong console for two players. An Arduino Uno provides the brains, and an Adafruit 16×32 RGB LED matrix the display. The only inputs are two potentiometers connected to two of the analog inputs left free by the LED matrix. There are a couple of pins still available, and initially thought I’d use them to add a push button for each player, but decided to go with a minimal user interface instead. Continue reading
It looks like no-one has yet taken advantage of the CC-BY-NC-SA licence under which Adam Savage kindly licenced his plans for the EDC One and EDC Two bags. I’m not planning on making one of the bags anytime soon, but I did want to take a look at the plans. Since I couldn’t find a free download anywhere, I decided to buy the plans and share them here:
If you do download a free copy to take a look, and then decide to make a bag, please consider buying the plans as well. It’s only $5 US, after all. And if you make something, don’t forget to share what you’ve made with the world!
NOTE 2019-06-26: The original way this check worked with Terraform 11 no longer works with Terraform 12, as v12 checks that attribute names are valid. The code has been updated accordingly. Instead of a null resource, we now use a local_file data source with Terraform 12.
I’ve recently begun working with Terraform at work to move our infrastructure definitions to code. Like a lot of companies, we have some legacy applications that either have never been re-installed, or have been re-installed using a very long and usually outdated README or other document. Using a tool like Terraform and moving infrastructure into code makes re-installing a system much easier.
Terraform’s workspaces are designed to keep different environments (dev/production) separate. Mostly workspaces seem to work fine; For example, it’s quite easy to automatically select the correct variables based on the current workspace.
However, workspaces don’t keep the environments quite as separate as I’d like. Once you select a workspace, Terraform won’t go out of its way to remind you about which workspace you’re on. It’s only a matter of time before this happens: Continue reading
What could be better than being a giant monster and beating other giant monsters into submission? Well, clearly, being a giant monster that isn’t represented by a cheap piece of printed cardboard with a small plastic base, but instead a good sized solid three-dimensional plastic figurine! Unfortunately, the Internet has been lacking in the department of 3D-printable King of Tokyo monsters, so I set out to deal with the issue.
Continue reading
This blog post describes how to set up and deploy an AWS Elastic Beanstalk application written in Node.js that listens to both regular HTTP requests and Websocket connections.
TL;DR: Download the sample application, and deploy it into an EB environment created using eb create alb-test-app-dev1 --elb-type application.
By default, applications in Elastic Beanstalk only listen to one port, and that is reflected in settings of the Nginx proxy, the Elastic Load Balancer, and the ELB listeners. We must change Elastic Beanstalk’s default settings to make the dual port setup work, which is done with .ebextensions. Also, Websockets don’t seem to work too well with a “Classic” ELB. An “Application Load Balancer” must be used instead.
