In certain scenarios, I've found it useful to use our production app's Read Replica as a source for manual testing. It's not something I'm reaching for often but there are definitely cases where our seed data just doesn't cut it.

Since it's a read replica, no writes can be made to it and I don't have to worry (too much) about harming production. You'll want to make sure any external user operations aren't configured to happen automatically (e.g. sending email, cropping avatars, etc).

Destroy​

In order to assign a different DATABASE_URL to a review app, you'll need to destroy the postgres attachment on your review app. I knock this out by chaining some commands together:

After running brakeman you'll get a report and, if there are new warnings, it will exit with a status code of "3". Typically, I only see two types of output from Brakeman. Either a large report where there are new warnings or a short report which is saying Brakeman is out of date.

I'll briefly explain resolving both.

Resolving New Warning(s) Detected​

The long report.

Run brakeman -I to get an interactive console for ignoring warnings. It will analyze your code base and then prompt you for where to find the ignore file. I've always used the default location of config/brakeman.ignore, so I simply press Enter to accept the default.

If you would like to have great, clean sounding audio in your meetings, podcasts, or videos. Purchase the microphone and audio interface that I recommend and use below.

Microphone​

I use the Audio-Technica AT875R shotgun microphone.

I place it 3-5 inches from my mouth using a boom arm attached to my desk. Since I type on that desk, I use a shock mount.

Since this is a shotgun mic, it works great from a distance. I can position the mic about 6-8 inches from my mouth to get it out of a video head shot which I use for meetings (I have enough room for a lower third with this shot; about a 35mm focal length). But, for best sound, place it only a fist-full away.

Audio Interface​

Since most microphones in this category do not have USB, you will need an interface to connect it to your computer.

In a Rails app at work, we are using a PostGIS data type of geometry and we were getting this warning in our logs:

unknown OID 16391: failed to recognize type of 'geo'. It will be treated as String.

This is because by default, Active Record doesn't support the OID 16391 for this data type. We can add our own in Rails 4.1 as recommended by Rob Di Marco.

I used pow in the past and didn't like it. I've given it a second chance and it seems to be working out. I'd like to give Invoker a try though but I'll save that for another day.

Pow is a daemon that runs your rack (Rails) apps in the background when you request them at a special example_app.dev domain. You don't have to start your app manually anymore (e.g. rails s). If you don't use your app for 15 minutes it kills your app's process to free up memory (restarting it on the next request). It doesn't run workers (I recommend inline que workers via ActiveJob) or other daemons such as those in your Procfile. It just looks for a config.ru and (presumably) does a rackup on it. It's very simple to set up and it's Mac OS X only.

I've recently been messing with a lot of hex thanks to my current client. I ran across a key/value hex string where each key/value pair was NULL terminated (pairs separated from other pairs with a NULL character) and each key was seperated from its value by a colon. Here's the hex string:

>> hexstr = "56494e3a3147314a433534343452373235323336370050524f544f3a3500504152414d533a302c312c322c342c372c392c31312c31342c323000494e44435452533a302830303030303030303030303131292c3128303131303031303131313129"

First I wanted to convert this to ASCII, Ruby makes this fairly simple:

I've been writing a Rails template for our future projects at Brightbit and I've been testing everything, including our application's environment. I've wrote a special rake task to test our different environments (development, test, staging, production, etc). This helps us ensure each environment is configured correctly. Ideally it would let the person running the tests know what is wrong with their environment and how to resolve it.

One of the environment details I wanted to test was that memcache was setup and running correctly. I could of course test for the memcached binary or check if it was running, but since we are running these tests in the context of a Rails app, why not just ask Rails if it can connect to the memcache server?

Currently at Brightbit there's 4-5 team members to add to each Heroku app. And with some projects having two, three or more apps (staging, production, splash, etc) it gets a bit cumbersome adding all of us and it will only get worse with more team mates.