This post is just going to be a cool story. I was on my laptop in a local coffee shop, and I had a lot of terminal windows open, so I guess whatever I was doing looked high tech. And this young man who was working there said “Hey, is that code? Are you programming?” We talked for a while, and traded email addresses. I’ll call him Steve. Continue reading “Helping Folks”
I just finished The Hard Thing about Hard Things by Ben Horowitz. This post will be about that book (which I read as an audio book), and have two parts: A general recommendation, and a key lesson. Continue reading “Book Review: The Hard Thing about Hard Things”
I love this book, but its title might be a slight exaggeration. I would have called it Some analogies of varying strength between computer science questions and life questions, with some special focus on optimal stopping, sorting, scheduling, and game theory. I guess that doesn’t have quite the same ring to it. Continue reading “Book Review: Algorithms to Live By”
In the time I’ve spent learning to code, I often see a little uptick in difficulty around packages (or dll’s, or gems, or imports, or whatever). Getting to “hello world” is pretty easy, but then getting to a program that prints hello world but also imports some system library for regexes or whatever is slightly harder, and often not covered well in tutorials. So I think that part of basic competency in a language is being able to publish and consume bundled code. I’ve been learning Ruby recently, so I’m going to do three things in this post and the following post:
- Go through making a gem for myself to use in a silly web app.
- Import said gem and use it.
- Import some published gem and use that.
Last week, I looked at the getting a rails server pushed up to AWS using a Vagrant. After that was working, I decided I wanted to be able to test changes on a local VM, then push that VM to the cloud when I liked it, rather than test all my changes in the cloud.
In the directory where I had the Vagrantfile and the shared folder for the rails server, I did
vagrant up --provider=virtualbox, and I got this:
An active machine was found with a different provider. Vagrant currently allows each machine to be brought up with only a single provider at a time. A future version will remove this limitation. Until then, please destroy the existing machine to up with a new provider. Machine name: default Active provider: aws Requested provider: virtualbox
Last time, we learned why
vagrant up with the AWS provider sometimes hangs on “waiting for SSH to become ready” (because I accidentally set it to use a private IP, but didn’t map routes or anything), and why it sometimes says “invalid group ID” (because if the group id provided doesn’t match your security role and region, AWS reports the same error as if you’d passed in a null group id).
Now, I’m going to resume doing the rails tutrial book’s “mostly static pages” and try to deploy it in AWS. I’m not going to worry about DNS entries for this post – I’ll declare victory when I can paste the public DNS entry that AWS generates for my instance in the browser and see some Rails content come back. Continue reading “Simple Rails Server on AWS with Vagrant”
My goal for this post is to take the sample app steps from the rails tutorial book, work on them locally, and deploy them in AWS from a script. Then I will share the script. To start with, I have a Vagrantfile that works fine for doing rails development locally, and I have an AWS account. One of the first things I did was set environment variables on my host machine to store my AWS credentials in. Then I can refer to those environment variables in my Vagranfiles, and I don’t need to risk checking an API key into github or something. In the vagrant file, it looks like this:
aws.secret_access_key = ENV['AWS_SECRET_KEY']
And then in my ~/.profile:
export AWS_SECRET_KEY="Wouldn't you like to know"