XTargets

Ensuring the selected item in a sencha touch list is always visible.

2012-04-30

Sencha Touch “Ext.List” lists are nice and flexible but they have one fiddly problem. If you manually set the selected item in a list from a callback like so

card.on
  activeitemchange: (card, item, oldIndex)=>
    index = card.items.indexOf(item)

    # Change the list selection to reflect
    # the current card
    list.select(index)

where list is a currently defined Ext.List object then all works fine until you select an item that is not currently in the visible window. Grrrrrr it is not visible and there is no public API to help you keep it so.

For example my setup is a card layout on the right and a list on the left reflecting the current card.

Uploaded with Skitch!

To select a card you can either directly select an item from the list or proceed sequentially back and forth using the left and right arrow on top of the card.

What we would like is an unobtrusive solution that doesn’t jump the scroll of the list around too much but keeps the selected item always in view and makes it always possible to directly select a next item on the list without finger scrolling.

I have added the following code to my activeitemchange callback. It can be added anywhere it is appropriate or made a method on a subclass of Ext.List if you prefer.

card.on
  activeitemchange: (card, item, oldIndex)=>
    index = card.items.indexOf(item)
    list.select(index)

    # Get the selected item. Seems
    # a bit ugly but it works
    cls = list.getSelectedCls()
    selectedElement = list.element.down("." + cls)
    selectedHeight = selectedElement.getHeight()

    if selectedElement
      # Height of the full list
      fullListHeight = list.element.down(".x-list-container").getHeight()

      # Height of the scroll window
      scrollWindowHeight = list.element.getHeight()

      yTop = selectedElement.dom.offsetTop
      yBottom = yTop + selectedHeight

      scroller = list.getScrollable().getScroller()

      # Outside this zone a scrollTo will be triggered
      triggerZone =
        min: scroller.position.y + selectedHeight
        max: scroller.position.y + scrollWindowHeight - selectedHeight

      # Conditions for items above the current scroll
      # position
      if yTop < triggerZone.min
        pos = yTop - selectedHeight

      # Conditions for items below the current scroll
      # position
      if yBottom > triggerZone.max
        pos = yTop + 2*selectedHeight - scrollWindowHeight

      # Adjust for the edge cases where the item
      # to scroll is at the top or bottom of the
      # list so we don't get nasty jumping effects
      if pos?
        pos = Math.max(0, pos)
        pos = Math.min(pos, fullListHeight - scrollWindowHeight)
        scroller.scrollTo(0,pos,true)

You can see a screen cast of the effect in action below

Pain free sencha touch 2.0 setup with sinatra and guard

2012-04-29

Setting up a dencent workflow with sencha touch is not too complex especially if you pull out the ruby toolbelt. I’ll show you how to do it and add in coffeescript for a bonus.

First download the sencha touch packages and install as per instructions. If you are using ZSH then it probably won’t work for you. Add this or similar to your zshrc

export PATH=/Applications/SenchaSDKTools-2.0.0-Beta:$PATH
export PATH=/Applications/SenchaSDKTools-2.0.0-Beta/bin:$PATH
export PATH=/Applications/SenchaSDKTools-2.0.0-Beta/jsbuilder:$PATH

Create a new sencha project and add it to your favorite version control system. I use git. I would skip the sdk directory that is auto generated as it is full of win32 binaries that you may not want clogging your version control server.

Now create a Gemfile for use with bundler

source 'http://rubygems.org'
gem "sinatra"
group :development do
  gem "compass"
  gem "guard"
  gem "guard-coffeescript"
  gem "guard-compass", :git => 'git@github.com:bradphelan/guard-compass.git'
  gem "growl"
end

bundle install

and all your gems will be installed.

Sinatra will help us to create a simple web server. No need for apache! Create the following ruby file call app.rb in the project root directory.

require 'sinatra'
require "sinatra/reloader" if development?

# Make sure our assets reload on every request.
set :static_cache_control, [:public, :max_age => 0]

# Pick which set of files get served depending
# on our environment
case ENV["RACK_ENV"] || "development"
when "production"
  puts "Production"
  set :public_folder, "./build/production"
when "testing"
  puts "Production"
  set :public_folder, "./build/testing"
else "development"
  puts "Debug"
  set :public_folder, "./"
end

get "/" do
  redirect "/index.html"
end

You will need a rake file for common command like starting the server and building releases. This is a simple starter to put in file Rakefile in the project root directory.

namespace :build do
  desc "Build the production code"
  task :production do
    sh 'sencha app build -e production'
  end

  desc "Build the testing code"
  task :testing do
    sh 'sencha app build -e testing'
  end

end

namespace :serve do

  desc "Run the production code"
  task :production do
    ENV['RACK_ENV']='production'
    sh 'ruby app.rb'
  end

  desc "Run the testing code"
  task :testing do
    ENV['RACK_ENV']='testing'
    sh 'ruby app.rb'
  end

  desc "Run the development code"
  task :development do
    ENV['RACK_ENV']='development'
    sh 'ruby app.rb'
  end
end

Now you will want to fiddle with the standard CSS of sencha or add your own custom styles. Sencha uses SASS so that is why we have the compass gem installed. We will use that next. Create a file called Guardfile in the project root directory and put this in it

require 'guard/guard'

guard 'coffeescript' do
  watch %r{^app/.+\.coffee$}
  watch %r{^app.coffee$}
end

config = File.expand_path "../resources/sass/config.rb", __FILE__
path = File.expand_path "../..", config

guard 'compass', :project_path => path,  :configuration_file => config do
  watch %r{resources/.+\.scss}
end

You can then from the command line run

bundle exec guard

and your app.css will always be up to date. There is also a section in my guard file for compiling my coffeescript to javascript. Coffeescript is a great alternative to javascript and works perfectly with Sencha.

Now to start your server you just do

rake server:development

and you will see something like

rake serve:production (in /Users/bradphelan/workspace/xxxxx)
ruby app.rb
Production
[2012-04-29 21:44:04] INFO  WEBrick 1.3.1
[2012-04-29 21:44:04] INFO  ruby 1.9.2 (2011-02-18) [x86_64-darwin10.8.0]
== Sinatra/1.3.2 has taken the stage on 4567 for production with backup from WEBrick
[2012-04-29 21:44:04] INFO  WEBrick::HTTPServer#start: pid=84278 port=4567

and you can point your browser / iDevice / fondlePad / android thingie at

http://localhost:4567/index.html

and your app is served. And now you have a sinatra backend you can add custom routes to do backend processing of the sencha data stores. If you are interested in me writing a post on how to do that then tweet me and I’ll write that up next.

And to to build your production release which packages all your js code into a single minified file do

rake build:production

That package in app/build/production is what is served when you start the server in production mode and is the default when served from somewhere like heroku.

Solving polymorphic has_one through building and nested forms

2012-04-04

I recently hit on the brilliant idea of using STI (single table inheritence), polymorphic classes, nested forms and has_one through models all at once just to prove how silly I am.

My use case is an asset manager backed by paperclip. I wanted all assets to go into a single S3 folder and be mananged by a single :assets table. Then I wanted any other model to be able to associate uploaded assets at any arity. Gumpf!

My base class for an STI compliant asset table is

# == Schema Information
#
# Table name: assets
#
#  id                      :integer         not null, primary key
#  attachment_file_name    :string(255)
#  attachment_content_type :string(255)
#  attachment_file_size    :integer
#  attachment_updated_at   :datetime
#  created_at              :datetime        not null
#  updated_at              :datetime        not null
#  type                    :string(255)
#  attachment_processing   :boolean
#  terminated              :boolean         default(FALSE)
#

    class Asset < ActiveRecord::Base
        belongs_to :assetable, :polymorphic => true
        delegate :url, :to => :attachment
        delegate :expiring_url, :to => :attachment
        delegate :present?, :to => :attachment

        validates_attachment_presence :attachment

        has_many :assetable_assets, :dependent => :destroy
        has_many :assetables, :through => :assetable_assets, :as => :assetable

        AssetPath = ":rails_env/assets/:id/:style.:extension"

        def self.configure_attachment options = {}
            options.merge! :path => AssetPath
            has_attached_file :attachment, options
        end

    end

Then I need a class to associate other objects, assetables, with uploaded assets. Note that assetables are polymorphic

    # == Schema Information
    #
    # Table name: assetable_assets
    #
    #  id             :integer         not null, primary key
    #  assetable_id   :integer
    #  assetable_type :string(255)
    #  asset_id       :integer
    #  created_at     :datetime        not null
    #  updated_at     :datetime        not null
    #

    class AssetableAsset < ActiveRecord::Base
        belongs_to :assetable, :polymorphic => true
        belongs_to :asset

        # Clean up orphans
        before_destroy do
            if not asset.nil?
                if asset.assetable_assets.count == 1
                    asset.background_destroy
                end
            end
        end
    end

And an example of a concrete assetable class.

# == Schema Information
#
# Table name: users
#
#  id                     :integer         not null, primary key
#  email                  :string(255)     default(""), not null
#

class User < ActiveRecord::Base

    has_one :assetable_asset, :as => :assetable, :dependent => :destroy
    has_one :avatar, :source => :asset, :through => :assetable_asset, :class_name => "ImageAsset"
    attr_accessible :avatar_attributes
    accepts_nested_attributes_for :avatar

    def build_avatar attributes={}, opts={}
        asset = ::ImageAsset.new attributes, opts
        build_assetable_asset :asset => asset
        self.avatar = asset
    end

    def avatar_with_build
        a = avatar_without_build
        unless a
            return build_avatar
        end
        a
    end
    alias_method_chain :avatar, :build
end

Now I can upload an avatar via a formtastic form as so

= semantic_form_for @user, :url => user_profile_path(@user), :html => { :multipart => true } do |f|
        = f.inputs do 
            .span5
                = f.input :email
                = f.input :name

                - if user.avater.present?
                    = image_tag user.avatar.url(:thumb)

                = f.inputs :attachment, :for => :avatar do |a|
                    = a.input :attachment, :as => :file
        = f.buttons

For some reason that I can’t get my head around Rails doesn’t ship with a handler for polymorphic has_one builders. I expected to be able to do

    user.build_avatar

out of the box but I got an error that the method does not exist and it took some fiddling to figure out how to emulate it.

For reference, The image asset class is defined below which fleshes out the STI part of the problem. Maybe it would not be necessary to have STI support on the assets table but it might happen that I have assets with different styles and need to classify them as such.

class ImageAsset < Asset

    configure_attachment styles: ImageSizes.standard_sizes_hash

    validates_attachment_content_type :attachment, 
        :content_type => %r{image/.*}, 
        :less_than => 5.megabyte

end

Simple javascript powered inline confirm

2012-03-29

Browser confirmation dialogs are ugly. They can’t really be styled and anyway who wants a big fat popup making the user drive thier mouse and focus away from where the action is at. Here is an easy solution using unobtrusive javascript techniques

Say we have an image viewer and we want a link to delete the image. My haml might look like

.item{'data-image_id'=>image.id}
  = image_tag image.attachment.expiring_url(s3_expiry, :large)
    .carousel-caption

      = link_to url_for_event(:delete_image, :asset_id => image.id),
        :method => :delete, 
        :remote => true,
        :class => "delete inline-confirm" do
        delete

Forget the fluff. I’m using twitter bootstrap carousel here but that is irrelevant. The key is adding the class inline-confirm. That is all.

The user interface interaction will go like this

IMG

delete

Imagine IMG is replaced with a picture of your sweetheart. You then click on delete and the screen changes to

IMG

yes no

You click on yes and the original link is followed. You click on no and the action canceled. The coffeescript to achieve this is

$(document).ready =>

  $("body").on "click", ".inline-confirm", (e)=>
    t = $(e.target)
    t.hide()

    yn = """
      <div>
        <a class="no" href='#' >no</a>
        &nbsp;
        <a class="yes" href='#'>yes</a>
      </div>
    """
    yn = $(yn)

    yn = yn.insertAfter t
    yn.fadeIn()

    yn.find(".yes").one "click", =>
      t.removeClass("inline-confirm")
      t.click()
      t.addClass("inline-confirm")
      yn.remove()
      false

    yn.find(".no").one "click", =>
      yn.remove()
      t.show()
      false

    false

The user experience improvement was immediate. To delete a sequence of images could be done an order of magnitude faster because I didn’t have to move the mouse around.

The code could be enhanced with more features and maybe some styling. If you have ideas for enhancements tweet me…

Understanding and solving race conditions with ruby rails and background workers

2012-03-08

Once upon a time you wrote a web application where a request would come in, you would process the request and send the result to the client. Job done. These days it is a little more complex. The jobs that a request may invoke may take longer than the client is willing to wait for a browser response so we add jobs to a job queue.

Sending an email is the cannonical example. A client performs some action in the browser which invokes a response from the server. Part of that response may be to send an email. However if we wait till the email is sent before we respond to the browser it may take a long time and result in a grumpy client.

Background workers to the rescue! Almost.

Now if your background workers feed from a job queue in the same database as your models, Delayed Job being an example of this, then you have not much to worry about and you can stop reading.

However if you are using Girl Friday which is memory/actor based or or Resque which is Redis based or any other queuing mechanism which is not based on ActiveRecord and resident in the same db as your models you are in for a scary ride of race conditions unless you are very very careful.

Picture the following controller

class FooController < ActionController::Base

  respond_to :html

  def create

    @foo = Foo.new params[:foo]
    @foo.save

    mail_subscribers_with @foo.id

    respond_with @foo

  end

end

Our imaginary mail_subscribers_with method might use Girl Friday as it’s job mechanism so we define it like

def mail_subscribers_with id

   MAIL_SUBSCRIBERS_QUEUE.push :id => id

end

and the queue is defined in config/initializers/girl_friday.rb

MAIL_SUBSCRIBERS_QUEUE = GirlFriday::WorkQueue.new :mail_subscribers_queue, :size => 3 do |info|

  foo = Foo.find info[:id]

  # A custom ActionMailer class to send the email
  SubscriberMailer.mail(foo).deliver

end

The problem with this is that the queue can be too quick. Each controller action is wrapped in a transaction in rails. Even though it seems that we have saved the object to the db before we add the job to the queue this is misleading. Transactions are local to the current thread in Rails. On another thread in another transaction the new object will not appear until the first transaction is commited.

The end effect is that

Foo.find info[:id]

may turn up no record or it may turn up a record. Not a good thing. Race conditions suck.

After Transaction Gem to the rescue.

This gem allows you to delay a block of code until after the current transaction is complete and thus everything that will be is commited to the database. To use it we modify our mail_subscribers_queue method to be

def mail_subscribers_with id
   ActiveRecord::Base.after_transaction do
     MAIL_SUBSCRIBERS_QUEUE.push :id => id
   end
end

Now by the time the

Foo.find info[:id]

call is made in the work the object is garunteed to exist. The astute reader will note the Rails 3 after_commit performs a similar function but after_transaction is more flexible and can be used inline with other source code making the intention of the code more obvious.

Caching signed uris with Paperclip and Amazon S3

2012-03-08

With paperclip we can specify that a generated URL will expire in a certain period of time. The simple way to do this is just

user.avatar.expiring_url(24.hours, :thumb)

The bad thing about the above is that it generates a new url on every call and every time the user refreshes the page they get new image urls. The browser doesn’t get the chance to cache the page and your S3 bandwidth bill goes up.

The better way is to use an explicit date for the expiry.

If you would like your images to expire after a maximum of 25 hours then create a method like below in your application helpers file

def s3_expiry
      Time.zone.now.beginning_of_day.since 25.hours
end

Then you can do

user.avatar.expiring_url(s3_expiry, :thumb)

The image url will expire at 1am in the morning tomorrow nomatter how many time time you regenerate the url. This means the url stays stable and is suitable for browser caching for 25 hours. However at a maximum of 24 hours new URL’s are generated leaving a minimum cache window of 1 hour and and average of 12.5 hours of caching.

Testing OAuth 2.0 apps locally

2012-03-05

In your facebook app setup do

App Domain => mydomain.com

in your /etc/hosts

127.0.0.1 localhost.mydomain.com
::= localhost.mydomain.com

in a shell script

#!/bin/sh
sudo ssh -L 80:localhost:3000 -l `whoami` -N localhost

When this script is run then it will block. Press ^C to stop the port forwarding. This could be made into a rake task if you like

What the above does is tell facebook to authorize an application operating at the *.mydomain.com uri pattern. In our /etc/hosts we map localhost.mydomain.com to the loopback device and in the shell script we forward port 80 to the real port our rails app runs on. Last of all we need to configure OAuth in our OmniAuth in our rails app to use the correct end points depending on our environment.

if Rails.env.production?
  OmniAuth.config.full_host = "http://mydomain.com"
elsif Rails.env.test?
  OmniAuth.config.full_host = "http://staging.mydomain.com"
elsif Rails.env.development?
  OmniAuth.config.full_host = "http://localhost.mydomain.com"
end

If you are using http rather than https then change the http to http above.

Using with_scope and ActiveRecord extension to set join model attributes

2012-02-29

I have the following

class User < ActiveRecord::Base
  has_many :user_venue_managements, :dependent => :destroy

  has_many :venues, :through => :user_venue_managements do
    def create *params, &block
      UserVenueManagement.with_scope :create => { :role => :owner } do
        super *params, &block
      end
    end
    def create! *params, &block
      UserVenueManagement.with_scope :create => { :role => :owner } do
        super *params, &block
      end
    end
  end
end

I can now do

u = User.first
u.venues.create! :address => "New York"

will create me a venue with the correct role set on the join model. Executed SQL is

INSERT INTO "venues" ("address") VALUES (?)  [["address", "New York]]
INSERT INTO "user_venue_managements" ("role", "user_id", "venue_id") VALUES (?, ?, ?)  
   [["role", :owner], ["user_id", 1], ["venue_id", 148]]

I’m a little unhappy with the duplicate create and create! repititon but it works.

RSpec steps for cleaner specs

2012-02-25

The following RSpec idiom drives me nuts in my unit tests.

describe Invitation do
  before do 
    @owner = Factory :registered_user
    @guest = Factory :user
    @event = Factory :event, :owner => @owner
    GirlFriday::WorkQueue.immediate!
  end
  describe "Comment subscriptions" do
    describe "A new invitation" do
      before do
        @invitation = @event.invite @guest
      end

      it "should not be subscribed to comments" do
        @invitation.should_not be_subscribed_for_comments
      end

      describe "After a comment has been made" do
        before do
          @comment = Comment.build_from(@event, @guest.id, "foo")
          @comment.save!
        end

        it "should be subscribed to comments" do 
          @invitation.reload
          @invitation.should be_subscribed_for_comments
        end
      end
    end
  end
end

Yeah I know. No stubbing, mocks or other fancy cool stuff. However there is so much boiler plate to describe what is really just a sequence of steps to verify. The rspec output is ( and the wording could be better but this is not the point )

Comment subscriptions
  A new invitation
    should not be subscribed to comments
    After a comment has been made
      should be subscribed to comments

Why all the indentation. It’s a sequence of steps we are verifying the behaviour of, not generating a YAML file!.

I’ve been using RSpec Example Steps in my acceptence tests recently and I thought why not give it a try for normal RSpec tests and see what happens.

describe Invitation do
  Steps do
    Given "A user a guest and an event" do
      @owner = Factory :registered_user
      @guest = Factory :user
      @event = Factory :event, :owner => @owner
      GirlFriday::WorkQueue.immediate!
    end

    When "the guest is invited to the event" do
      @invitation = @event.invite @guest
    end

    Then "the guest should not yet be subscribed to comments" do
      @invitation.should_not be_subscribed_for_comments
    end

    When "the guest makes a comment" do
      @comment = Comment.build_from(@event, @guest.id, "foo")
      @comment.save!
    end

    Then "the guest should be subscribed to comments" do
      @invitation.reload
      @invitation.should be_subscribed_for_comments
    end
  end

end

with the RSpec output being

Given A user a guest and an event
When the guest is invited to the event
Then the guest should not yet be subscribed to comments
When the guest makes a comment
Then the guest should be subscribed to comments

Why would you want to write your specs as if you are some asynchronous coding god. If you want to test a sequence of steps and have a nice RSpec report that describes the behaviour of the code then try out RSpec Example Steps

CANCAN Devise and Apotomo living together in harmony

2012-02-14

The Apotomo Framework cleans up Ruby On Rails view code. It encapsulates widgets into easy to reuse object oriented modules packages. However none of the examples I could find used real world examples with authorization and authentication bundled in.

The packages I use are Devise and CANCAN which seem to be pretty much standard with most new rails projects

The easy way to get it working is to create a base class which adds in all the functionality for auth that you will need.

class AuthorizableWidget < Apotomo::Widget

  include Devise::Controllers::Helpers 
  helper_method :current_user

  def can?(action, object)
    current_ability.can? action, object
  end
  helper_method :can?

  def cannot?(action, object)
    current_ability.cannot? action, object
  end
  helper_method :cannot?

  def authorize! *args
    parent_controller.authorize! *args
  end

  def current_ability
    ::Ability.new current_user
  end

end

Note that above I am calling the authorize! method on the parent_controller which is the real controller that the browser calls. The controller.authorize! method sets a variable on the controller which sets a flag telling the controller that an authorize! method has been called. If you use the method check_authorization as a sanity check this flag is what stops the error being thrown.

This becomes the base class for all new widgets that need authorization capabilities. You use it so

class CommentsWidget < OpenKitchen::AuthorizableWidget

  responds_to_event :comment
  responds_to_event :destroy

  #
  # Events
  #

  # Destroy a comment
  def destroy(evt)
    @comment = Comment.find params[:comment_id]
    @event = @comment.commentable

    # Call the CANCAN authorize! method here!
    authorize! :destroy, @comment

    @comment.destroy
    update({:state => :display}, @event)
  end

  # Add a comment
  def comment(evt)
    commentable_type = case params[:comment][:commentable_type]
                        when 'Event'
                          ::Event
                        else
                          raise "nice try!"
                        end

    @event = commentable_type.find(params[:comment][:commentable_id])

    @comment = Comment.build_from @event, 
      current_user.id, 
      params[:comment][:body]

    # Call the CANCAN authorize! method here!
    authorize! :create, @comment

    @comment.save


    update({:state => :display}, @event)
  end

  #
  # Views
  #
  def display(event = options[:event])
    @event = event
    @comments = @event.root_comments
    render
  end

  def list(comments)
    render locals: { comments: comments}
  end

  def item(comment)
    render locals: { comment: comment }
  end

end

Note that the helpers are also now available to the Apotomo views

app/widgets/comments/item.html.haml

%li.comment{id: "comment_#{comment.id}"}
  %span.author=comment.user.name
  %span.body=simple_format h(comment.body)
  %small
    %span.date
      =distance_of_time_in_words_to_now comment.created_at, true
      ago
  - if can? :destroy, comment
    = link_to url_for_event(:destroy, :comment_id => comment.id),
      remote: true, 
      class: "destroy", 
      title: t('comment.remove'), 
      :confirm => t('confirm') do
      %small
        %i.icon-fire
        =t :delete

It would be nice if this was distributed with Apotomo by default as it was a bit of trouble to figure out, especially the special flag set by authorize! as I was initially just calling current_ability.authorize! which didn’t set the flag.