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.
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.
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.
Sometimes it can be painful to try and get an Elastic Beanstalk application to deploy cleanly. In order to effectively debug the issues, it’s necessary to SSH into the instance. This requires that you’ve added a Key Pair in the EB environment configuration before launching the instance(s). The address to SSH to can be found in your EC2 management console.
Once on the server, these paths are useful in debugging:
/var/app/current/ – This is where your application source code is.
/opt/elasticbeanstalk/hooks/appdeploy/post – If you’ve used post deployment scripts, this is where they are. Note that any post deployment scripts from any previous deployments to the same instance will be left here even if your latest configuration does not have those scripts!
/var/log/eb-activity.log – “tail -f /var/log/eb-activity.log” in order to get a live feed about how your deployment is going.
Getting started with a Raspberry Pi is basically really easy: All you need to do is get a disk image and burn it to an SD card. But of course, that’s just the very basic starting point. Theres’s plenty of setup work left to do after that, so I decided to gather it all in a blog post so I don’t need to re-invent everything every time I start a new project. Here goes: