According to the Tiny Tower Wiki the equation for calculating how much it costs to build a given floor is:
cost = 150 × floor_number 2
A simple way to evaluate this equation in Ruby would be:
According to the Tiny Tower Wiki the equation for calculating how much it costs to build a given floor is:
cost = 150 × floor_number 2
A simple way to evaluate this equation in Ruby would be:
At Crush + Lovely, we use Railsmachine's Moonshine to automate the configuration of our servers. When writing our deployment recipes, VMWare Fusion's ability to take snapshots and rollback to these snapshots is a huge timesaver because it takes just seconds to roll a server image to it's original state.
When you're just configuring a single server, having a static IP address for your server image isn't too important, but when you're configuring multi-server setups, it can be useful to duplicate a number of server images and give each a static IP address so you can consistently deploy to them. While not documented well at all, it turns out that this is relatively easy to accomplish in four simple steps.
Let's say you have a guest machine with the name ubuntu-lucid-lynx-base
a
When upgrading PostgreSQL on your machine, previously installed versions of the pg
Rubygem will complain because their native extensions were compiled against an older version of Postgres. The error will look like this:
[daley (qa)]$ be rake db:create
rake aborted!
LoadError: dlopen(/opt/rubies/2.3.1/lib/ruby/gems/2.3.0/gems/pg-0.18.4/lib/pg_ext.bundle, 9): Library not loaded: /opt/boxen/homebrew/lib/libpq.5.5.dylib
Referenced from: /opt/rubies/2.3.1/lib/ruby/gems/2.3.0/gems/pg-0.18.4/lib/pg_ext.bundle
Reason: image not found - /opt/rubies/2.3.1/lib/ruby/gems/2.3.0/gems/pg-0.18.4/lib/pg_ext.bundle
/Users/pjkelly/src/daley/config/application.rb:7:in `<top (required)>'
Over the past few years, we've seen the projects we work on go from occasionally to almost always requiring a REST API. There are several reasons for this, all of them necessitating our ability to construct clean, performant APIs that are easy to work with:
As a Ruby shop, we've always had a wide array of tools and libraries to choose from when building our applications. While this is most definitely a good problem to have, it's still a problem, and finding a combination of tools that made API development feel right to us took a few tries.
service: project-vpc | |
variablesResolutionMode: 20210326 | |
# Concepts From: | |
# https://raw.githubusercontent.com/awsdocs/aws-lambda-developer-guide/main/templates/vpc-privatepublic.yaml | |
# https://datachef.co/blog/aws-vpc-with-public-and-private-subnets/ | |
# https://ordina-jworks.github.io/cloud/2020/02/19/Combining-MongoDB-and-AWS-Lambda.html#vpc-peering-connect-your-lambda-functions-with-your-mongodb-atlas-cluster | |
custom: | |
stage: ${opt:stage} |
PhantomJS is an awesome tool for doing automated, full-stack acceptance tests in a headless browser. It's a great alternative to capybara-webkit because it doesn't depend on QT or xvfb, and it's way better than Selenium in most cases because it's faster (you don't need to open Firefox to run your tests).
Unfortunately, installing PhantomJS via Homebrew can wreak havoc on your Rubies if you're using rbenv. These are the steps that worked for me in fixing my Ruby installations.
# Update Homebrew
brew update
# Install PhantomJS
service: my-service | |
frameworkVersion: ">=1.45.0 <2.0.0" | |
plugins: | |
- serverless-localstack | |
- serverless-deployment-bucket | |
custom: | |
stage: ${opt:stage} |
The basic flow is this:
Given the name of your feature branch is registration-page:
I hereby claim:
To claim this, I am signing this object: