Rube Boy

Getting the current_user or current_admin_user into your production logs.

Fri, 26 Feb 2016 08:01:00 +0000

Conspicuously Absent

I was trying to debug a problem that was impacting a specific user this morning and realized there was no good way to tell from the production logs which user had issued any particular request. I’m using ActiveAdmin for this project, which is using Devise for authentication, which uses Warden. Warden’s features don’t appear to be available at ‘log-time’. But, with a bit of digging in the cookie jar we can pull the current admin_user.id out without too much hassle. Some posited solutions were a little bit over-designed for my liking. I hate running around in half a dozen files to find things, so I feel like this is the easiest to understand solution. Stick this in config/initializers/logging.rb

Rails.configuration.log_tags = [
    lambda { |req|
      session_key = Rails.application.config.session_options[:key]
      session_data = req.cookie_jar.encrypted[session_key]
      warden_data = (session_data["warden.user.admin_user.key"] || [[]])
      admin_user = warden_data[0][0]
      "u: #{admin_user || 0}"
    }
]

Thanks to…

http://stackoverflow.com/questions/10811393/how-to-log-user-name-in-rails

RecordNotUnique - Expect the unexpected.

Fri, 03 Apr 2015 21:19:00 +0000

TL;DR

Not all validations are created equal. Some hit the database and others don’t. You need to know which is which. Add this to the idea that “exceptions should not be expected” and you are talking about some serious cognitive dissonance. Consider using a distributed Mutex managed by your database server to really do a good job. Otherwise a simple retry will suffice. UPDATE Due to rails weirdness, retry can actually cause an infinite loop scenario. Be careful.

Beer

I have heard and even said to other developers that ‘exceptions should not be expected’. Some languages rely on exceptions for message passing. I can just see the little buggers bubbling up like the bubbles in a pint of Guinness. Mmmm…

Where were we ? Right. Exceptions (in Ruby) should not be expected. What does that mean exactly ? Let me give you an example. I have been trying to DRY up my basic controller world. I keep using the usual new, create, edit etc. actions and I wanted to make those as tight and readable as possible. And then there was this one:

 

class Item < ActiveRecord::Base 
    validates_uniqueness_of :name 
end

 

def create @item = Item.new(item_params)

    if @item.save
        redirect_to @item, notice: 'Item was successfully created/updated.'
    else
        render :new
    end

end

This looks all fine and dandy on the face of it. Look! I even put a uniqueness validation on Item.name. What could possibly go wrong ? This is textbook. I bet even the scaffold generator would make something that looked a lot like that (it does). Well, there’s a reasonable chance that mysql will throw ActiveRecord::RecordNotUnique (or many others - how woudja like an InvalidForeignKey ?) in your face. The problem arises because time elapses between the validation and the save. Someone could squeak a record in there that has the same ‘name’ as your record and then you try to save and BOOM. Now, old-school developers like me hate the idea of CHECKING and then SAVING. We just used to setup the database with constraints to handle these sort of validations and wait for it to throw an exception. It was atomic and efficient. But I guess that just ain’t cool anymore.

So, there’s a non-zero chance of your exception getting thrown and the user is then plunged in to an error page. No nice form with error messages on the input fields so you can work out what happened. Well, Mr Smarty Pants, where did your zen-like lack of exception handling get you ?? Let’s tweak up our action a bit:

 

def create @item = Item.new(item_params)

    if @item.save
        redirect_to @item, notice: 'Item was successfully created/updated.'
    else
        render :new
    end

    rescue ActiveRecord::RecordNotUnique 
        flash[:notice] = 'Unable to create Item' 
        render :new 

end

Well, this is a bit better. At least they get a flash message, but it’s not neatly sitting on the form field. I suppose I could hack around with the object’s error collection and try to stick something in the right spot. I want the best user experience possible. I could even parse the error message and try to work out which field was affected by the error. That would be a pain in the arse, because all database servers will throw a different message. Not very portable. Either way this definitely violates ‘exceptions should not be expected’.

Transactions, dude.

Let’s try whacking a transaction on this sucker. Then the whole darned table/database will be locked while you CHECK and SAVE. Feels like it might work. I don’t need to catch the exception anymore because it can’t happen…right?

 

def create @item = Item.new(item_params)

    Item.transaction do
        if @item.save
            redirect_to @item, notice: 'Item was successfully created/updated.'
        else
            render :new
        end
    end

end

Wait - what? The ActiveRecord docs point out that this won’t work. A transaction is not your tool here. Since the validation doesn’t fail in any sense at a database level, the transaction proceeds unimpeded. You can also try with_lock but that won’t cut it either as it only seems to lock the local copy of the model.

Setting Expectations

So who said “exceptions should not be expected” ? Who is responsible for this heart-rending rubric ? Great Answer Here from Mike Partridge

We believe that exceptions should rarely be used as part of a program’s normal flow; exceptions should be reserved for unexpected events. Assume that an uncaught exception will terminate your program and ask yourself, “Will this code still run if I remove all the exception handlers?” If the answer is “no,” then maybe exceptions are being used in nonexceptional circumstances.

The Pragmatic Programmer

And here comes the science…

[A]n exception represents an immediate, nonlocal transfer of control - it’s a kind of cascading goto. Programs that use exceptions as part of their normal processing suffer from all the readability and maintainability problems of classic spaghetti code. These programs break encapsulation: routines and their callers are more tightly coupled via exception handling.

The Pragmatic Programmer

Sigh. How am I going to get rid of this dirty feeling? I have been scrubbing for hours BUT IT WON’T COME OFF ! I think the answer must come from within.

Slow, slow, quick, quick, slow

Exceptions are slow, too. Although this isn’t really a problem in our case. We are doing something at human-scale speeds. This exception-raising probably won’t ever become a serious performance issue in our example. When it takes our user whole seconds to complete their form, who is going to miss a few microseconds ?

No hope of rescue

There’s always rescue_from, I suppose. But that seems even worse. Flow would jump out of your function and off into some global error handler. I mean, seriously ? Are you nuts ? Besides this smacks of defeatism. “This won’t happen very often. The customer’s convenience is less important than mine.”

 

class ApplicationController < ActionController::Base 

    rescue_from ActiveRecord::RecordNotUnique, with: :spaghetti_code

If at first you don’t succeed…

Some have suggested using ‘retry’ to solve the issue. The validation will pass the first time, raise the error, retry, then fail the second time resulting in the requisite error messages that are useful to the user. That’s 2n SQL queries, on the rare occasion that someone beats us to it and n queries (where n depends on the number of validations you do against the database) normally but it does result in a much improved user experience. And that’s a trade-off I can live with. I don’t mind doing more work if it benefits the user.

 

def create 

    retries ||= 2 
    @item = Item.new(item_params)

    if @item.save
        redirect_to @item, notice: 'Item was successfully created/updated.'
    else
        render :new
    end

rescue ActiveRecord::RecordNotUnique 
    retry unless (retries-=1).zero? 
    raise 
end

Be careful ! Make sure you have unique constraint defined ! At least it will only try once and then stop if it isn’t. In the interest of DRYness we should probably take the re-try wrapper and make it a helper or something. That create action is looking pretty skinny. And retry_once_on can be used in all my other create and update actions.

 

def retry_once_on(exception) 
    retries ||= 2 
    yield 
rescue exception 
    retry unless (retries-=1).zero? 
end

def create 
    retry_once_on(ActiveRecord::RecordNotUnique) do 
        @item = Item.new(item_params)

        if @item.save
                redirect_to @item, notice: 'Item was successfully created/updated.'
            else
                render :new
            end
        end

    end
end

Insane in the membrane

I’m still not loving this. Another developer might well look at this and wonder why the hell I would bother retrying a failed save. The code doesn’t change anything, it just retries.

The definition of insanity is doing the same thing over and over and expecting different results

Not Albert Einstein

In fact, when you think about it, Einstein is the least likely person to say that given his preoccupation with space and time. Let me change that quote:

The definition of polling is doing the same thing over and over and expecting different results

Rube Boy

The old saw discounts the possibility of external change. Not all change comes from within. I guess my coworker might think I was insane because the change that might happen is not apparent. The retry code is not as self-documenting as the simple rescue version.

Mutual Exclusion

What’s really needed here is a Mutex or Mutual Exclusion. This can be achieved in a couple of ways. There’s a neat gem called with advisory lock that lets you create a named lock either in mySQL or Postgres (and even sqlite with the aid of file-based locks). And I’m sure a solution for MongoDB is an option. Alternatively you can manage Mutex using a table that records who has a lock on what as suggested here. There’s no point using a Ruby Mutex because there may be multiple servers running your code and Ruby Mutexes aren’t distributed.

def create @item = Item.new(item_params)

    Item.with_advisory_lock(:creating) do
        if @item.save
            redirect_to @item, notice: 'Item was successfully created/updated.'
        else
            render :new
        end
    end

    rescue

end

So, in the end, our retry solution is simple and effective and maybe uses more SQL queries than you might want. On the other hand with_advisory_lock would do it with slightly less SQL queries, more expressive syntax and might even satisfy the Exception-phobic. It’s surprising what a can of worms database-querying validations makes and I’m even more surprised that we are all casually ignoring this issue. Dealing with this problem should be a core feature of Rails. The advisory lock solution should probably wrap all ActiveRecord transactions that perform datebase validations before a database operation.

Footnote: A further wrinkle occurs when the validation passes and the insert fails permanently. Rails’ validates_uniqueness_of constraint uses BINARY comparison which is different to the comparison mode the index uses. Sometimes (especially with trailing spaces) the BINARY comparison passes and the insert fails. Retry. Same thing happens = infinite loop. Why is nothing ever simple ? I had some ideas about this in another post.

Rendering Partials With Layouts Recursively in Rails 4

Wed, 01 Apr 2015 18:37:00 +0000

So, gather around and I will tell you a story of a terrible curse. Or not:

###TL;DR

Add this to your application helper and use it instead of render whenever there’s a chance you will call a partial and try to wrap it in a layout.

  def inside(options)
    parent_view_flow = view_flow
    self.view_flow = ActionView::OutputFlow.new
    yield
    output = render options
    self.view_flow = parent_view_flow
    output
  end

Takes the current view_flow, stores it, starts a new one, renders your partial, then puts everything back the way it was

###Layouts and Partials

Normally, it’s not so hard to apply a layout to a partial. Why would I apply a layout to a partial ? Am I nuts ? Possibly. Let me explain. Let’s say I have a bunch of things I would like to have similarly formatted = Use case for a layout. Say, you were trying to display something that was self-referencing. Like an Item that has_many items. Yes, that sounds reasonable. The Item object has a ‘name’ property.

rails g scaffold Item name item:references

Now, I warn you, I like haml with a bit o Bootstrap. So that’s how this is going to go down. Let’s say I have a template thus, for rendering one of these thingies and it’s children.

shared/_data_card.html.haml

.well
  .h1
    = content_for :name
  .h2
    Items:
    = content_for :contents

And a partial for rendering an Item

item/_item.html.haml

-content_for :name do
  = item.name
-content_for :contents do
  = render item.items # this is where it's all going to go horribly wrong
=render partial: 'shared/data_card'

A model.

models/item.rb

class Item < ActiveRecord::Base
  belongs_to :item
  has_many :items
end

A bit of a tweak to

views/items/show.rb

=render @item

A little prep in rails console or migrations, whatevs.

Item.create(name: 'bottom_item', item: Item.create(name: 'middle_item', item: Item.create(name: 'top_item')))

Probably need to work on making these names a bit less ‘itemy’

Rails is smart enough to work out what to do at render folder.contents. It’s going to render a collection, calling the folders/_folder partial for each Folder in contents. There is another way to do this. I could call

render partial: 'folder/_folder', layout: 'shared/filesystem_object'

instead. The results would be the same - bitterly disappointing.

Let’s take a look at some screenshots.

Well, that’s what we were HOPING for. But actually this is what you end up with:

WTF ?

Let me tell you WTF. It’s pretty simple. Rails has a thing called view_flow which is an instance of ActionView::OutputFlow. When you do content_for it puts the result of that block into the view_flow.content hash. If content_for gets called multiple times it concatenates the results. Are you feeling me ? So what happens in our example. Well, the following happens:

content_for first item’s :name is called.
content_for first item’s content is called BUT it has to do this first:
- content_for second item’s :name is called (uh oh. what’s in the view_flow now ?)
- content_for second_item’s :content is called BUT it has to do this first: (oh dear lord)
- etc…
- render all the crap above that’s been mashed together
render all the crap AGAIN

You get the picture…

So get on with it already.

  def inside(options)
    parent_view_flow = view_flow
    self.view_flow = ActionView::OutputFlow.new
    yield
    output = render options
    self.view_flow = parent_view_flow
    output
  end

This little fella takes a copy of the view_flow and makes a fresh one for your recursive call, and puts it back once the result is computed and output. That stops stuff falling all over itself. How do we use it ? Easy. Let’s refer back to this partial:

item/_item.html.haml

= inside(partial: 'layouts/data_card') do
  -content_for :name do
    = item.name
  -content_for :contents do
    = render item.items # this is where it's all going to go swimmingly.

view_flow feels horribly like a global variable, doesn’t it ? Perhaps there’s a way to make it local-er.

Thanks to André Arko for the inspiration for this solution. His solution doesn’t work for multiple content_for sections, but rather has a single yield. This didn’t work for my needs. His explanation helped me work out a refinement of his solution. Also, the format of his article inspired the structure of this one. So, many thanks.

Hello, Pixyll

Wed, 11 Jun 2014 15:31:19 +0000

Hello.

Pixyll is a simple, beautiful theme for Jekyll that emphasizes content rather than aesthetic fluff. It’s mobile first, fluidly responsive, and delightfully lightweight.

It’s pretty minimal, but leverages large type and drastic contrast to make a statement, on all devices.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupéry

Where is it?

Checkout the Github repository to download it, request a feature, or report a bug.

It’s free, and open source (MIT).

Pixyll in Action

Tue, 10 Jun 2014 12:31:19 +0000

There is a significant amount of subtle, yet precisely calibrated, styling to ensure that your content is emphasized while still looking aesthetically pleasing.

All links are easy to locate and discern, yet don’t detract from the harmony of a paragraph. The same goes for italics and bold elements. Even the the strikeout works if ~~for some reason you need to update your post~~. For consistency’s sake, The same goes for insertions, of course.

Code, with syntax highlighting

Here’s an example of some ruby code with line anchors.

# The most awesome of classes
class Awesome < ActiveRecord::Base
  include EvenMoreAwesome

  validates_presence_of :something
  validates :email, email_format: true

  def initialize(email, name = nil)
    self.email = email
    self.name = name
    self.favorite_number = 12
    puts 'created awesomeness'
  end

  def email_format
    email =~ /\S+@\S+\.\S+/
  end
end

Here’s some CSS:

.foobar {
  /* Named colors rule */
  color: tomato;
}

Here’s some JavaScript:

var isPresent = require('is-present')

module.exports = function doStuff(things) {
  if (isPresent(things)) {
    doOtherStuff(things)
  }
}

Here’s some HTML:

<div class="m0 p0 bg-blue white">
  <h3 class="h1">Hello, world!</h3>
</div>

Headings!

They’re responsive, and well-proportioned (in padding, line-height, margin, and font-size). They also heavily rely on the awesome utility, BASSCSS.

They draw the perfect amount of attention

This allows your content to have the proper informational and contextual hierarchy. Yay.

There are lists, too

Apples
Oranges
Potatoes
Milk

Mow the lawn
Feed the dog
Dance

Images look great, too

There are also pretty colors

Also the result of BASSCSS, you can highlight certain components of a post with CSS classes.

I don’t recommend using blue, though. It looks like a link.

Footnotes!

Markdown footnotes are supported, and they look great! Simply put e.g. [^1] where you want the footnote to appear,¹ and then add the reference at the end of your markdown.

Stylish blockquotes included

You can use the markdown quote syntax, > for simple quotes.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis porta mauris.

However, you need to inject html if you’d like a citation footer. I will be working on a way to hopefully sidestep this inconvenience.