Musings about Entrepreneurship, Technology and Software Development

Accidental Technologist

Ruby on Rails – Supporting SSL for PostgreSQL on Heroku

For anyone who received this notice from Heroku:

Since 2016, all newly-provisioned Heroku Postgres databases have enforced the use of SSL to keep your data safe. However, one or more of your Postgres databases are running on legacy infrastructure, which does not enforce the use of SSL. In order to update your database to our security standards, and in response to potential impacts caused by Spectre and Meltdown, all databases – including those on legacy infrastructure – will be moved to our new Heroku PGX plans in a set of maintenances starting in March 2018 and concluding by April 2018. 

What Do I Need to Do
In preparation for these maintenances, please check that your applications are using SSL to connect to your Postgres database and enable SSL connections if needed. Instructions on how to perform these steps are available in Dev Center.

If you’re using Rails 4.1+ there is a support article on the Heroku Dev Center, that helps clarify making updates to our database.yml file. This allows customizing some connection behavior to PostgreSQL.

Some parts of the database.yml file that cannot be changed include:

You cannot use the config/database.yml to set any values found in ENV[‘DATABASE_URL’]. This is a list of attributes you cannot change:

  • adapter
  • database
  • username
  • password
  • host
  • port

But, what can be changed include sslmode. 

production:
  sslmode: require (disable|allow|prefer|require)
  pool: 15

I decided it would be helpful to reach out to Heroku to understand their guidance with regard to their notice. Their response:

If you’re using the pg gem, the default sslmode setting (and for libpq, the library that underpins it), is prefer – this means that should the server have SSL support, it will be used when the connection is established. This means there should be no action required, though if you wish, it’s worth a test with spinning up a staging environment with a non-legacy Postgres instance.

It seems if you’re using Ruby on Rails with the pg gem, you should be OK doing nothing but with brownout period scheduled, it’s probably a good idea to test during one of those times.

Heroku Support also indicated setting the environment variable PGSSLMODE would also override the default behavior for sslmode used by libpq.

It seems this is a notice which doesn’t effect a majority of Heroku customers and is a necessary and worthwhile upgrade. Hopefully this helps others as the public information available for this from Heroku is minimal.

Fixing Your Puma-dev SSL Problems on Google Chrome

Ruby on Rails developers have it made in many ways. We rely on and take advantage of great software created by the community.  Puma-dev is just one of those great pieces of software.

Puma-dev has some nice improvements over Pow, which Basecamp had promoted for years but has seemed to stop development.

Puma-dev allows developers to better mirror their local development environment to that of production. Prior to Puma-dev or Pow, developer would have to access their Ruby on Rails applications with something like localhost:3000 in their browsers. It works but having a “real” URL to visit, like mygreatapp.dev is better.

This worked well until a recent update to Google’s Chrome browser:

A lot of (web) developers use a local .dev TLD for their own development. Either by adding records to their /etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to 127.0.0.1.

In those cases, if you browse to http://site.dev, you’ll be redirect to https://site.dev, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can’t dismiss self-signed certificates with HSTS, they need to be ‘trusted’ by your computer)

I’ve faced this myself and Chrome refuses to serve the site, only showing security errors.

When trying to fix this problem I search a lot around the web and came up with very little. There were plenty of acknowledgements that since .dev is now a top-level domain (TLD) and Chrome 63 treats it as such and forces SSL, it looked like moving away from .dev would be needed. 

This was my assumption until I discovered a recent post from Barry Woolgar of Storm demonstrating setting up Puma-dev. He addresses troubleshooting .dev TLD issues specifically:

If your browser complains about an untrusted root certificate, please do the following:

  1. Open Keychain Access
  2. Click the ‘login’ keychain in the left pane, then find the ‘Puma-dev CA’ certificate in the right pane
  3. Double-click it and expand the ‘Trust’ section, and make sure it says ‘Always Trust’
  4. Drag it into the ‘System’ keychain in the left pane
  5. Restart your computer
  6. Try https://my-project.dev again!

Although I didn’t need to restart my Mac, this worked perfectly! I can now serve .dev domains in Chrome and latest Firefox.

Tip: Save Typing ‘bundle exec’

If you’re a Ruby on Rails developer, you probably type the words ‘bundle exec’ numerous times a day. I finally got tired of it and decided to do something about it.

In the context of keeping it simple, I use the ‘alias’ command and add to my .profile. I know there are more Rails recommended ways of solving this problem via binstubs but I rather not use that approach.

My solution is simple, add an alias to my .profile like this:

alias be='bundle exec '

Keen observers will notice the trailing space after the command. This space allows for alias chaining and can be helpful.

The resulting shortcut allows this:

bundle exec rspec

To this:

be rspec

The ‘alias’ command is super useful and has many applications to help remove repetitive typing tasks.

#

Life Beyond Rails: A Brief Look at Alternate Web Frameworks for Ruby →

I wrote up a list of alternative Ruby web frameworks some time ago and now Engine Yard has published a new list. Some of my original picks are in there, so it’s great to see they’ve continued.

A couple notables include Volt, for running Ruby on the server as-well-as the client, and Cramp that helps with needing a lot of open connections and bi-directional communication.

A great list to check out.

Introducing Rails Rescues

RR01

Today I’m happy to introduce Rails Rescues.

Rails Rescues is a service representing years of Ruby on Rails experience organized to help companies who have a Rails application but may be having some problems.

Rails Rescues aren’t limited to a fixed set of services but can include:

  • Scaling your website
  • Resolving site stability problems
  • Upgrading from an old version of Rails to current versions
  • Fixing Broken Code
  • Simplifying an out-of-control code base.
  • Finishing up after your contractor or employee left the project.
  • ….we’ll fix anything holding you back from a successful Rails web site.

I’m happy to offer a $500 finders fee for any referral sent that results in a sign Rails Rescues contract.  Please spread the word and visit the site. I will make myself available via live chat to answer any questions.

 

 

Speeding up Heroku Deploys

Anyone who deploys their Rails 3.x or 4.x utilizing the asset pipeline and doesn’t precompile those assets yet deploys to Heroku, knows it can take a really long time for your deployment.

I searched around a bit and found a great article on how to shave some time off my Heroku deployments.  Alex MacCaw has a nice write up about the process:

If you’re using Heroku, the first step is enabling a Memcache addon. I’ve gone with the memcachier service, as they’ve got a generous free plan (which is all we need at this stage).

heroku addons:add memcachier:dev

Then we need to make sure the environmental variables are available to your app during the pre-compilation stage. Usually this isn’t the case on Heroku, but they’ve got a new labs feature called user-env-compile which will do the trick.

heroku labs:enable user-env-compile

Next you’ll need to add the dalli and memcachier gems to your Gemfile. Finally, the last step is to configure Sprockets.

Since I am using Rails:

With Rails

With Rails, just configure the assets cache store inconfig/environments/production.rb.

config.assets.cache_store =:dalli_store

And the time savings would be….

 An example of time saving with a relatively small project:

Not using the speed-up method, deploy time: 2 minutes 40 seconds

Using the above method: 47 seconds

It is definitely worth the little effort.

Errors Installing the pg Gem When Using Heroku Postgres.app

I’ve been using the PostgreSQL Mac OS X app from Mattt Thompson and Heroku for quite some time now.  If you don’t know what it is, it’s a drop in app bundle for the PostgreSQL database.  There are many ways that work, this just happens to be really simple.

I use PostgreSQL with my Ruby on Rails projects and combine that with the pg ruby gem.  

I ran into a situation where the pg gem would not install because it could not find pg_config in a known location on my Mac.  The error occurred on Rails 3.2 but 4.0 may show the same behavior.  

The Error

The error can come up when running a bundle install or just a straight gem install pg from the command line. The resulting error may look something like this:

Installing pg (0.17.0) with native extensions 
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension
.
.
.
.
An error occurred while installing pg (0.17.0), and Bundler cannot continue.
Make sure that `gem install pg -v ‘0.17.0'` succeeds before bundling.

The Solution

I already mentioned the problem is the gem install not finding pg_config during installation.  So let’s find it.

1. First, find where pg_config is located.  Run this command from a terminal window:
which pg_config

Should display something like this:

/Applications/Postgres.app/Contents/MacOS/bin/pg_config

2. You can tell RubyGems where your pg_config file is located:

gem install pg -- --with-pg-config='PATH_TO_YOUR_PG_CONFIG'

For example, pg_config is here on my system:

/Applications/Postgres.app/Contents/MacOS/bin/pg_config

So I would install the gem this way:

gem install pg -- --with-pg-config='/Applications/Postgres.app/Contents/MacOS/bin/pg_config'

The pg gem should now install. I hope this helps.

UPDATE: Scott Watermasysk points out another good solution:

Talking about Building iOS Application on The Tablet Show Episode 85

I was a guest recently on The Tablet Show with Richard Campbell and Carl Franklin, to talk about iOS development, client projects, API’s with Ruby on Rails and creating applications with interactive back ends.

I think it turned out pretty well but I really can’t stand listening to my own voice, so please give it a listen and decide for your self.

Thanks to Richard and Carl for having me on the show.

Dead Simple Model Diagrams for Your Rails Project

While working on Rails project I often find myself wanting a visual representation of my model classes.  I usually grab a notebook and manually write them out. Depending on the project, it can take time.

I started searching for a diagramming tool that might be easier and faster than writing out by hand, there are a bunch of them out there.  Most have a steep learning curve and are expensive.

A bit of searching around the web for a Ruby-specific tool lead me to a gem named rails-erd.  Maybe you have heard of it, maybe I’m the last to know, but regardless it is a nice find.

Installing

The gem relies on GraphViz to do it’s drawing magic.  There are a multitude of ways to install it, I used Homebrew:

brew install graphviz

Add the gem to your development group in your Gemfile:

group :development do
  gem 'rails-erd'
end

Don’t forget to run the bundle command.

When everything is install, from the root of your Rails project simple run:

rake erd

When the rake task runs, watch the output from the tool. It tells you items you won’t find on the diagram either because it’s not used or a relationship isn’t right.

The Output

The result will be a PDF file in the root of your project that looks something like this: 

Erd

As you can see, it gives a very nice model diagram with all the relations and properties. Just what I was looking for.

The tool is very customizable and the web site outlines everything that can be changed.  I haven’t looked very much at this aspect since it produced everything I needed the first time.

Damn You Rails Multiparameter Attributes

Boy with a headache MG 0599

I came across an interesting problem that was driving me crazy when using Ruby on Rails 3.2 Date types in an application I am working on for client.

Problem

I have a date property that is virtual and not backed by a column in a database. When trying to create a new object from a date select on a form, I was being greeted by the following error:

ActiveRecord::MultiparameterAssignmentErrors in Users::MembershipsController#create

1 error(s) on assignment of multiparameter attributes

After some searching around the web for a solution, as any self-respecting developer does, and came up with many others facing the same problem.  It was suggested this was a problem with Rails, a quick check on the Github Rails project revealed something similar reported, but no solid fix I could find.  It may be out there and if someone is aware, please let me know.  I am using Rails 3.2.8 so any fixes that exist, should be in there. 

This works great when using the date select and storing to a database, Rails takes care of processing multiparameter attributes and pushing into the date field.   We are talking about virtual attributes here, no database field to store the data.

Solution

Please don’t comment how bad this solution is..it’s a hack, I know, but it works. I’m never too proud to share a hack. 

The goal here is to end up with and expiration date in a virtual attribute on my model.  To accomplish this I construct a plain Ruby Date class from the components of the date from the date select form helper.  Ruby Date expects parameters; Date.new(Year, Month, Day)

NOTE: if you try this look at the parameter values for each component of your date to make sure choose the right values.  I have changed the default order of the date select on the form.

params[:user][:membership_attributes][:expiration_date]=Date.new(
params[:user][:membership_attributes][:"expiration_date(1i)"].to_i,
params[:user][:membership_attributes][:"expiration_date(2i)"].to_i,
params[:user][:membership_attributes][:"expiration_date(3i)"].to_i)

Now remove the individual date components from the parameter hash:

params[:user][:membership_attributes].delete(:"expiration_date(1i)")
params[:user][:membership_attributes].delete(:"expiration_date(2i)")
params[:user][:membership_attributes].delete(:"expiration_date(3i)")

In my case this is strictly for a Ruby Date type in Rails but the problem and solution is the same with a Ruby DateTime type.  The date and time are broken down more, having 4i and 5i representing the time.

Finally

This little hack works great and hopefully helps those using a version of Rails 3 that is not patched..or heck, maybe it will never be.

I’d be happy to learn this was fixed or how I could have handled this better.  Please add some details in the comments.