Musings about Entrepreneurship, Technology and Software Development

Accidental Technologist

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:

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.

Minitest Not Running My Unit Tests

I have started using minitest for Rails 3.x unit testing and since it comes with Ruby 1.9.x by default, it seems like a good direction to take my testing.

I am using the great gem by Mike Moore called minitest-rails which has a minitest dependency so I can easily have the latest version of minitest.  This gem helps to more cleanly integrate and use minitest in our Rails 3.x projects.

As part of my setup I use Autotest so my tests run automatically when files change.  I noticed none of my unit tests were running and upon further inspection, minitest was looking in test/unit and test/unit test directories but not in the test/models folder, which seems to be the minitest default.  

Opening up my .autotest configuration file and adding the following:

Autotest.add_hook :initialize do |at|
  at.add_mapping(/test\/models\/.*\.rb/) do |_, m|
   at.files_matching %r%^test/(models)/.*\.rb$%
  end
end

After restarting autotest, my unit tests are now being tested.  I hope this saves someone some 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.

 

Rails Views and Backbone.js with David Heinemeier Hansson

This is a great discussion with DHH about the Basecamp rewrite, not going crazy using Backbone.js, like so many developers are doing these days, for everything.  One technology used is PJAX, for updating small bits of a view to give small, fast updates.  PJAX combines HTML5 pushState and AJAX to make the fast magic happen.

PJAX is a great example how to use the views we know and the fast updates we need instead of completely changing the way Rails developers approach views using tools like Backbone.js, Knockout and others.

The discussion is about 1 hr 40 min long but well worth it.  You get some good views of new Basecamp Rails code and the usual colorful dialog.  

David had a great post on the 37Signals blog that serves as some background to the above talk titled How Basecamp Next got to be so damn fast without using much client-side UI.

RailsConf 2012 Wrap Up

IMG 0370

I was fortunate enough to be able to work out attending RailsConf 2012 in Austin, TX.   This was the first time on many years that the conference was not organized by O’Reilly but rather Ruby Central, Inc.

I have to go on record and say I usually avoid cities but the city of Austin is a great place and would not hesitate to return.  The people are friendly and there is so much diversity in the city that there is something new on each corner.  I noticed an abundance of restaurants with so many different types of food.  I can’t say I had a single bad meal during my journey.  Everyone I spoke with about the trip said I had to try the BBQ, and they were right…it was fantastic.

IMG 0379

Many of the sessions overfilled the room.  This on in particular exemplifies what I’m talking about.  I bet the fire marshal wasn’t aware of these.  Overall the floors were pretty comfortable.

It was often difficult to decide which sessions to attend, with 3 full-tracks there always seemed to be two talks during the same time slot I wanted to take.  I usually decide which sessions to attend by how applicable they are to current work.

One of my favorite sessions was by Obie Fernandez about using Redis with Rails.  Although the examples of the talk were from his recent startup, they were excellent and showed integrating Redis into a Rails application not to remove ActiveRecord but to compliment it.  Obie discussed a gem he released to help the integration called redis_props along with sample code used in the talk.  The code is clean and concise…great stuff.

Another talk I found personal value in was the Semi Automatic Code Review by Richard Huang.  Richard is the creator and maintainer of the Rails Best Practices gem.  In the talk he discusses another related open source project called Railsbp.com which allows for your code to be reviewed when committing to Github.  The results will be displayed on the Railsbp.com site where you can change the code right there and commit back to your repo.  Very informative details produced from the site, GitHub allows hooks into the service and thoughtfully open sourced.  I wasn’t aware of the site before but now I am using it regularly.

The other talk which I took a lot away from was Digging Deep with ActiveSupport::Notifications by Matt Sanders.  This talk when into great detail with many examples of using notifications in your applications.  It is similar to the event publishing and subscriber model from other platforms such as .NET.  Having spent many years writing .NET applications this talk brought back many memories of this pattern.  The techniques exemplified here I had never used in Rails but do need this functionality on a new project.  

UPDATE (05/03/2012): One talk that was intended to be included here, is from Lori Olson.  Her talk titled, Mobile Rage – What causes it & how to fix it (Confreaks), takes the view of web application use on a mobile device from the user’s perspective and how developers can implement very simple techniques to ease the pain.  I recommend this one highly, good stuff and some tips I was not aware of.  I admit I have some sites that can take advantage of this.  

IMG 0387

The final keynote of day one was from a non-Ruby developer, Rich Hickey, which seemed to be out of the ordinary.  Maybe he was there to pull some Ruby developer to the Clojure world.  It appears Rich is trying to convince these two Rubyist that LivingSocial would be better with Clojure.  I wish I could have overheard the conversation.

There were three very large, two-sided, white boards used for companies to post jobs, and they were pretty full of opportunities.  I noticed there were far too many companies attempting to make the next Facebook or Twitter and not enough companies creating really useful applications.  There were exceptions from what I could see, but too few.  I remember the same thing happening around 2000 and then the bubble burst.  Apparently we are not better from this event in history because we have not learned from it.

I finally met face-to-face many friends I only knew from various social networks with lively hallway track discussions.  I think this is the #1 reason to attend conferences.  The materials from the talks are available everywhere and with Confreaks recording all the sessions, you can watch the show later.  You can’t however, experience meeting new friends and seeing old ones without attending.

I recommend every Rails developer attend just one of these events, well worth the time and effort.  The next on is in Portland, OR from April 29 to May 2, 2013.

Palliative Symptoms Survey Hits the Apple App Store

I have been working diligently on a project for some time now and it’s finally available.  My company, Still River Software, received approval from Apple last week for Palliateive Symptoms Survey to help doctors and caregivers provide better and faster care to their patients.

Palliative Symptoms Survey is an application based on the Edmonton Symptom Assessment Survey (ESAS-r) which was developed to assist in the assessment of nine symptoms that are common in palliative care patients: pain, tiredness, drowsiness, nausea, lack of appetite, depression, anxiety, shortness of breath, and wellbeing There is also a blank scale for patient-specific symptoms.

The application is a native iPad application written in Objective-C with a back-end using Ruby on Rails.   Please read a little bit about the project on my company web site.

When Pow Eats Up the Clock Cycles

I have been a huge fan of Pow to serve my Rails applications for development on my Mac.  I wrote my love for Pow a while back and have been using it ever since, but all has not been a perfect experience along the way.  After upgrading to the 0.3.2 version I started to have my applications appear to lock up in the browser and finally timing out.

The only solution I could reliably make work was to open up Activity Monitor and kill the pow process manually.  It worked..until the next time and I would have to do it again and again.  It seemed like I was doing this many times a day.

It turned out this was a bug reported to the development team and is a confirmed issue.  The cause of the problem is determined to be the dns resolver, ndns.    A pre-release version, 0.4.0-pre is reported to resolve the issue.  Install it with the command:

curl get.pow.cx | VERSION=0.4.0-pre sh

I did this and have not had to manually restart pow once.  I’m not sure why the official release has not been updated to include the fix to this issue which seems to effect many users.