Moving on

Posted by Tim Connor Sun, 25 Oct 2009 21:15:00 GMT

I rarely update this blog, possibly because dealing with Typo is more than I can bothered to do anymore. So I am caching it to HTML, and moving on to newer lighter-weight approaches that require no maintenance from me. This blog will be moving to and a redirect put in place for all the old content. will continue to be my home on the web; I may just set-up a redirect (or maybe proxy everything) in Apache to my tumblog.

Compiling Flex apps with external swc libs and RSLs using ruby and rake

Posted by Tim Connor Sat, 08 Aug 2009 21:40:00 GMT

At work I maintain a number of flex projects, some of which are dynamically modified based on the results of slicing up SVG maps. As such, it is far easier to have a rake task do the compiling, rather than recompiling each one by hand, in Flex Builder.

Since there are a range of different projects that share some library code, I had to figure out how to compile them against an external swc, ideally loaded as an RSL for space savings and a couple other benefits. I hadn’t seen many full fleshed out examples of this, so I thought I should share.

Below is a stripped down version of the code that is called from rake; I cut out stuff specific to the work projects. I also made a flex ruby compiler gist so that it can be found on github and modified there.

module FlexCompiler
  COMPILER = "/Applications/Adobe\\ Flex\\ Builder\\ 3/sdks/3.2.0/bin/mxmlc"
  FRAMEWORK_PARAM = "-runtime-shared-library-path=/Applications/Adobe\\ Flex\\ Builder\\ 3/sdks/3.2.0/frameworks/libs/framework.swc,framework_3.2.0.3958.swz,,framework_3.2.0.3958.swf"
  COMPONENTS_PARAM = "-runtime-shared-library-path=vendor/flex/components/bin/components.swc,components.swf"
  DEFAULT_FLAGS = "--warnings=true --strict=true --debug=false" 
  def self.compile_swf(project)
    puts "compiling #{project}"
    project_path = "vendor/flex/#{project}/src/#{project}"
    compile_cmd = "#{COMPILER} #{DEFAULT_FLAGS} #{FRAMEWORK_PARAM} #{COMPONENTS_PARAM} -file-specs #{project_path}.mxml"
    #puts compile_cmd

   `mv #{project_path}.swf public/flash/#{project}.swf`
  def self.optimize_swc(library="components")
    `unzip vendor/flex/#{library}/bin/#{library}.swc -d vendor/flex/#{library}/bin/unzip`
    `optimizer -keep-as3-metadata="Bindable,Managed,ChangeEvent,NonCommittingChangeEvent,Transient" -input=vendor/flex/#{library}/bin/unzip/library.swf -output=public/flash/#{library}.swf`
    `rm -rf vendor/flex/#{library}/bin/unzip`

One thing to beware of: make sure your various libraries (.swcs) externally link the framework rsl’s, otherwise they will be a couple 100k bigger with the duplication. By default in flex, libraries merge the framework in, which is counter-productive if you’ve taken steps to dynamically link it in your app.

Workaround for has_many :through overriding the :select clause

Posted by Tim Connor Mon, 15 Jun 2009 22:30:00 GMT

As I mentioned earlier a named_scope select clause will get overridden in a has_many :through.

class Grandparent
  has_many :grandchildren, :through => :children

class Grandchild
  named_scope :summed_ages_by_gender, :select => "SUM(age) as age", :group => :gender

#does not do what you want, because the through overrides the select

If you have a case where this isn’t acceptable, such when you have a complicated aggregate select that you would like to call on a has_many through, there is an ugly work-around. You can recreate the has_many :through, with joins in a scope on the child model, then return that in a method of the grandparent.

class Grandparent
  def grandchildren
     Grandchild.grandchildren.scoped({:conditions => [' = ?'], id})

class Grandchildren
  named_scope :summed_ages_by_gender, :select => "SUM(age) as age", :group => :gender
  named_scope :grandchildren, :joins => ['JOIN parents ON grandchildren.parent_id =>', 'JOIN grandparents ON parents.grandparents_id =']

#should work

Obviously I would not advise using this as a relationship model – it was one I just threw together for elucidation. And I haven’t run this exact code, but I have run the code it is a dummied up copy of, with great success.

Maybe I’ll try and come up with a patch to fix the original problem, but the through select logic is probably some of the most edge-case ridden in AR associations, so I am not sure how easy it would be.

Update: I made a ticket with a patch for the failing test, at least.

Another ticket on Rails Metal loading/requiring issues

Posted by Tim Connor Tue, 28 Apr 2009 21:43:00 GMT

Our (YieldBuild, Inc) use of metal for one of our two highest throughput actions seems to manage to ferret out edge-cases, as I know have another ticket on Rails Metal requiring issues

This one, thankfully doesn’t have any serious performance hits on production (fixing the other one by manually forcing thin to use the right rails handler via a basic dropped our load by roughly 30%).

There is just a problem with having a dependency on a project constant from within metal, and you have the choice of having development mode choke on the second metal request (due to Rails having unloaded the constant, but not knowing metal needed it reloaded), or forcing a manual require, which will cause a double require. Hopefully none of your models, etc, are non-idempotent on file load (aside from warnings about redefining constants), right?

Problems with mongrel_cluster and Rails 2.3 dispatcher reloading your metal every request 2

Posted by Tim Connor Wed, 15 Apr 2009 23:33:00 GMT

So, once I added a couple Rails metal to our high volume site, my boss complained that our performance took a serious hit. In tracking it down (with strace) we realized that every request was re-requiring each metal, which involves a full load path search. This was not happening on our local script/server started mongrels, but was happening on production for both thin and mongrel_cluster, even after we had gone through every setting and made them match exactly.

We traced it down to the difference of mongrel_cluster versus the script/server. Script/server is going to use the built in, updated for Rails 2.3, mongrel handler. The old stuff called by thin or mongrels started by mongrel_cluster, is going to use the old (“deprecated”) dispatch path, which in a cgi-ish fashion rebuilds the dispatcher and all rack middleware and metal each time, which means re-requiring them all.

So now I am not sure what to do. Do we have to start all of our mongrels with rackup? Do we take the rack mongrel handlers from rails and patch them into wherever? Do I file a bug for Rails that there at least needs to be some documentation, other than just deprecating the method that a stock mongrel will call?

Update I made a ticket for it Also having mongrel start up using the handler in the rails vendorized rack as a config will fix the problem for mongrel. I’m not sure about thin, as that handler seems to be rackup specific?

Update2 Ezra said he’d go with rackup and gave me a monit script for it

Update3 We made a barebone rails and made thin use that, forcing it down the path of using the built-in rails handler. That dropped our load by 30% roughly, so yeah, this behavior had a significant impact on us.

Follow-up on the iPhone theft +1 for Amex and SFPD

Posted by Tim Connor Fri, 27 Feb 2009 23:51:00 GMT

Getting insurance money from American Express for the theft of my iPhone was straight-forward. It is only the purchases price ($299 + tax), not the replacement value, but that is better than nothing.

Also an Inspector from the San Francisco Police Department just called me to record an electronic statement. Apparently they got good enough video from the muni cameras to make a bulletin from, so they want my statement on hand for a follow-up if someone identifies suspects. I have to say, throughout this SFPD has been friendly, responsive, and more pro-active than I expected. I wonder if that is at all affected by me being a well-off, educated, white, male? All I know is they seemed far more interested in this than SLC PD where for a car theft, and a couple break-ins, I had. Maybe the involvement of a gun make a difference.

Difference between rspec style spec names and test unit? Three lines.

Posted by Tim Connor Tue, 24 Feb 2009 23:19:00 GMT

A discussion I overheard in irc made me wonder what possibilities would be opened up if instead of naming tests by convention (test_)all publicly accessible methods were run as tests. This lead down a path to this thought:

class RspecInTU
  class << self
    alias it define_method
  it "should say hello" do
    puts "hello"
end "should say hello"

Forkable here

Technomancy told me that it’s easy to actually get miniunit to use all public methods as test methods and came up with a minimum working base

Of course, I wondered if Shoulda already did something like that, and some people confirmed that it does. It’s still neat.

named_scope :select clause gets overridden by a :source specified in a has_many association

Posted by Tim Connor Fri, 06 Feb 2009 21:27:00 GMT

FYI. If that wasn’t Greek to you, then that’s about all there is to it.

Correction any :through overrides the :select, not just one specifically :source’d

On iPhone theft and chasing down an armed robber 8

Posted by Tim Connor Sat, 17 Jan 2009 22:33:00 GMT

Sorry for the stream of consciousness, lack of paragraphs, but I am still wired on adrenaline.

Those of you with my phone number, it won’t be good for a little bit. My phone just got snagged out of my hand on the bus. The guy doing the snatch and grab, ran out of the bus as he grabbed it, while his fat compatriot tailed behind him running interference. I kicked off my shoes as I chased after the guy with the phone and weaved around the fat guy out into the street and around the corner after my phone. I pushed the robber up against the chain link fence as I caught up to him, and his gun fell out of his pants. His fat buddy, behind me a little said something to the effect of “what the fuck are you doing” while he said “I didn’t grab it, it fell.” Thinking he meant he missed the grab I let him go as he fumbled for the gun (stupid, I know, but I didn’t know what else to do with him, what try and beat the snot out of the two of them, that’d be assault. And the gun hadn’t registered yet, or had just barely started falling) and went back to look for my phone. Of course, it wasn’t there because the robber had it.

The bus driver called it in to the cops, who took all my info and witness account and gave me a drive home. They are hoping to get something good off the cameras on the bus, and I have a case number. I am canceling all the passwords of things that might be saved on my phone, and already canceled service to it.


I just realized when he said “I didn’t grab it, it just fell” he was referring to his gun, to let me know he was not pulling it on me. That makes it somehow more real and scary to accept that he could have been.

Problems with arity when converting a method to a block/proc that accepts an array param

Posted by Tim Connor Sat, 17 Jan 2009 04:55:00 GMT

Some consider this hacky, but while working on cleaning up test_benchmark I wanted to pass a named method as a block to a map. In the simplest case you just grab a method reference via object.method(:method_name) and to_proc it with an ampersand. In this case the method definition is basically just a way to store a proc, and this could be replaced by just storing a proc in an instance variable. But it works, both with the method called directly, and passed as a proc/block:

benchmarks = [["a slow test",2.0],["a fast test",0.001]]
def by_time(a,b)
  b[1] <=> a[1]
benchmarks.sort { |a,b| by_time(a,b) } #works
benchmarks.sort(&method(:by_time)) #works

I discovered you can have problems with arity, though, if the block method is passed an array, which is then expanded out to array.length params, giving you an ArgumentError. For instance, if I am again working with doubles for my benchmark rows:

benchmarks = [["a slow test",2.0],["a fast test",0.001]]
def format_row(tuple)
  ("%0.3f" % tuple[1]) + " #{tuple[0]}"
end { |tuple| format_row(tuple } #works
# ArgumentError: wrong number of arguments (2 for 1)

Thanks to Evan Phoenix for pointing out I just need to use a glob param in my method. This won’t work with the direct call anymore, as the tuple gets wrapped in another array by the globbing:

benchmarks = [["a slow test",2.0],["a fast test",0.001]]
def format_row(*tuple)
  ("%0.3f" % tuple[1]) + " #{tuple[0]}"
end #works { |tuple| format_row(tuple }
#Blows up on an invalid index access, because tuple inside format_row is now [["a slow test",2.0]] for the first call

To work around this, in this case, it works to just flatten the array.

def format_row(*tuple)
  ("%0.3f" % tuple[1]) + " #{tuple[0]}"
end #works { |tuple| format_row(tuple } #works

I guess the general conclusion to go with, is be careful doing tricky things like using method references as procs. Especially keep a careful eye on the method signature and how arrays can mess with your arity.