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.
TL;DR: How do I make it work?
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
Posted in IT
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.
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:
Posted in IT
Tagged raspberry pi
Here’s a quick build I just finished: A Raspberry Pi running RetroPi, installed in a Makita powerdrill briefcase with a 7″ TV and four USB controllers. Also included are all the components necessary to power the whole setup: A 12V PSU that powers the TV, and a 12V to 5V voltage regulator that powers the Raspberry Pi and the USB hub.
Scenario: A new Linux box has been installed with Vagrant, and now I must git clone a non-open repository to the server, so I need to forward my SSH keys to the root user on the virtual server.
1) Add the following line to your Vagrantfile:
config.ssh.forward_agent = true
2) Once you’ve “vagrant ssh”‘d to the server:
$ sudo -E -s su
..to become root with your forwarded key.
I found the answers at Stackoverflow and Serverfault, and decided to copy them here so I don’t need to Google them the next time I’m looking for the answers.
Looking at the way some freshly licenced (and some older) jumpers struggle with making neat line stows, I figured I’d document the method I’ve been using to stow my lines. Here goes:
A method for neatly stowing lines
These instructions are for stowing a bight of lines on the right-hand side of the bag; for the left-hand side, the hands used are reversed.
1. Start by slipping your right middle finger through the rubber band you’re going to use.