a timocracy of one

A list of some sites I follow to keep up in my field (ruby and web development)

Sat, 04 Sep 2010 14:33:21 -0700

http://www.google.com/reader/bundle/user%2F12740622692005399469%2Fbundle%2FRuby%20JS%20and%20other%20dev

Git sub-tree merging back to the subtree for pushing to an upstream

Mon, 21 Jun 2010 17:35:00 -0700

While git sub-tree merge strategy works great for merging a library into vendor (when you want to pull HEAD on that library instead of waiting for releases), I had trouble finding documentation on pushing back to upstream. This is annoying because one of the most obvious times you may want to use subtree is when you manage the library yourself, so can just pull straight from the repo, and want to push your maintenance changes back.

Surprisingly, and not what I have come to expect from git, it just works. From the example in the docs I linked, when you are checked out on master

git merge --squash -s subtree --no-commit rack_branch

will merge the rack_branch into where you have specified. But it just works the other way to. If checked out on rack_branch

git merge --squash -s subtree --no-commit master

will do what you expect, so you can now just push your library branch back to it's upstream.

Awesome!

Permalink | Leave a comment »

Our vows and pre-vow speeches

Wed, 19 May 2010 23:32:00 -0700

Roula

I am honored that you have chosen me to be your wife. You: the best person I know, my dearest friend, the highlight of my day.

I may have doubts and questions about life, but of you and this marriage I have none - it is the most fulfilling work of my life.

The sounds of your voice and the touch of your hand assures me that I am, at last, home, and I cannot wait to spend the rest of my life with you.

I love you now and always.

Tim

Some of you know that we aren't very traditional and aren't sold on the cultural expectations of marriage. We decided we'd try and have a kid before we decided to get married and we live as if we are married: we live together, share our expenses, daily life, hopes, dreams, and plans. Yet, I very much wanted to have a wedding and get married.

I want to commit so absolutely that Roula can feel it incarnated on her finger. I want her to have a constant reminder that I am here for her, at all times, and I want the same for me. I want to gather our loved ones and have them share a moment where we formalize our commitment. I want to crystalize and distill this moment down for all eternity, for us to share and remember when we are 102 and and hobbling down to the park for a Sunday picnic. I want to make the implicit, explicit, and for us to say out loud, in front of witnesses, the things we already both know and feel.

Vows

I promise to love and treasure you always, in sickness and in health, in poverty and in wealth;
to be considerate of your feelings, kind in all things, and ask forgiveness when I fail at that;
to talk through the tough times and always remember to the good ones;
to hold you above all others in my heart.

This I vow: to commit to this marriage with all my being and no reservations.

Permalink | Leave a comment »

The Tea Party is Racist

Tue, 27 Apr 2010 18:09:45 -0700

http://politicalirony.com/2010/04/27/the-tea-party-is-racist/

Permalink | Leave a comment »

Unobtrusive JavaScript vs. Kool-Aid

Tue, 27 Apr 2010 18:06:44 -0700

Great response to @jamis' UJS == Kool-aid posts. Welcome to the post-2005 era of web dev. ;)

Unobtrusive JavaScript vs. Kool-Aid

via DailyJS on 4/26/10

This article is a guide to writing unobtrusive JavaScript. It’s not always easy for people to transition to writing JavaScript this way, so I’ve tried to address common concerns.

The techniques presented here should enable you to think differently about client-side code and work more productively.

Background

It’s important to realise that unobtrusive JavaScript is an evolving concept, perhaps even a movement. The broad goal is to separate JavaScript into a behaviour layer, but related goals include: enhancing browser behaviour, capability detection, and transparently supporting modern platforms like touchscreen phones.

This article was inspired by my surprise at the following tweets:

almost two months later, I’m still have trouble swallowing the UJS kool-aid. @jamis

Funny how the JS people get all shocked and dismayed when jamis complains about UJS. Evidence of kool-aid. @rjs

Unobtrusive JavaScript isn’t a fad, it’s how you should write JavaScript. If you read this blog, you’re probably doing it already. If you have server-side developer friends who don’t write much client-side code, please send them this article!

I don’t advocate blindly applying the techniques championed by the proponents of unobtrusive JavaScript. However, I have learned lessons from several hard-won battles which have enabled me to write JavaScript more productively — my own practices have evolved towards unobtrusive JavaScript over the last 4-5 years.

Inline JavaScript

Where does inline JavaScript come from? One common place is server-side frameworks. It’s easier for frameworks to inject JavaScript through helpers — popular frameworks like Rails do this. This is because the HTML and JavaScript these frameworks generate is naturally tightly coupled. It’s also because the framework builders often try to appeal to the host language rather than seasoned JavaScript developers.

Inline JavaScript crops up in several places:

Events like onclick are added to page elements through attributes
Inline script tags
Conditionally generated combinations of the above
Custom solutions like Rails’ RJS templates (often used to communicate between the server and client)

These techniques work well for frameworks and make life easy for the host language developer. In fact, Rails is one of the projects that helped JavaScript frameworks bring Ajax to the world, and also the now ubiquitous use of visual effects through projects like Scriptaculous.

The Alternative

The alternative isn’t just about moving your JavaScript into its own files. It’s to change the way you think about JavaScript, the DOM, and HTML templates.

If you’ve worked with CSS, you’ll be familiar with the separation of style from structure through the use of stylesheets. The popular argument for writing unobtrusive JavaScript is that scripts define a behaviour layer, and therefore should be separated, just like stylesheets.

This is true up to a point, but it takes a leap of faith to get there. The key is to stop thinking about templates like static blocks of HTML, and see documents for what they are: living, breathing tree structures of DOM objects, events, and styles.

Concerns

The main concern of those who are uncomfortable with writing unobtrusive JavaScript is maintainability. This is deeper than just finding code, or the link between a template and a script — it also affects project management.

When planning new features, it can be difficult to determine what page elements will be affected by a change if all of the JavaScript is outside the templates.

Or is it?

Mental Models

People resist writing JavaScript this way is because their mental model of a HTML document is based on HTML templates. A more useful mental model is one which encapsulates the true nature of the DOM — a document is a collection of interrelated objects, affected by scripts, stylesheets and their very structure.

When I start work on a new project or feature, I think in terms of these objects and how they’re related. I try to group like items and behaviours — just as styles can be efficiently shared, events can also.

Strategies and Patterns

DOM Ready

This is what makes healthy client-side code possible. DOM ready lets you run a function when the document is in a usable state. This allows you to safely bind event handlers. In jQuery it looks like this:

$(document).ready(function() { // Your code here });

Prototype:

document.observe("dom:loaded", function() { // Your code here });

This isn’t actually an easy thing to write from scratch — let the framework do the work. I’ve written my own DOM ready handler before and it wasn’t much fun (mainly due to IE).

Event Delegation: DRY

If you’ve come to JavaScript through jQuery, you might be wondering what I’ve been talking about. People raised on jQuery think in terms of event delegation, and this is one of the key strategies to writing unobtrusive JavaScript.

Event delegation is where an event is bound to a containing element, then conditionally executed based on the event’s element.

Imagine if you wanted to open popup windows when the user clicks a link. You could attach an onclick attribute and set up a window. Every link would then have to repeat this code.

An alternative approach is to use event delegation to bind an event to a high level element, the use a class to trigger a special popup event handler:

$(document).click(function(event) { if ($(event.target).is('.popup') { // Open a new window with specified parameters } event.preventDefault(); });

The benefit is similar to the benefits brought in by stylesheets — you can now change the behaviour of all popup windows across your entire project. You could even have multiple class names for different window properties — sizes, toolbar hiding, whatever! It also makes the page size smaller, all for the price of one event handler with an if statement.

Internal Relationships

On larger projects I use a technique that maps controllers to JavaScript objects. I do this by using body ID tags and classes. A function runs when the DOM is ready and calls the appropriate object.

For example, let’s say you’re making a blog application in Rails (or similar) and you have an ArticlesController. I’d use a helper in my Rails layout to create an appropriate body tag:

<%= body :id => controller.name %>

Which is defined like this:

def body(options = {}) tag 'body', options, true end

Then my JavaScript delegation function would look at the body tag and call a method on an associated object:

ArticlesController = { run: function() { // Do stuff that the articles templates need } }; $(document).ready(function() { var controllerName = ''; if ($('body').id) { controllerName = $('body').id + 'Controller'; if (typeof controllerName !== 'undefined') { controllerName['run'](); } } });

This body ID delegation pattern has allowed me to build very large Rails projects without feeling lost when moving between JavaScript and Rails templates. I also use body class names for shared functionality. The JavaScript “controllers” are generally stubs that invoke other objects.

Any framework could use this technique — it’s really just an agreement between your server-side code and JavaScript.

Test First

When I start writing JavaScript for a project, I try to think in terms of the core functionality, independent of the browser. I’ll write console-based code and run unit tests in the console. Once I’m happy with my “models” I’ll start to hook up event handlers.

Get used to thinking about events through CSS classes — try to group like events and rely on high-level delegated event handlers. Not only does this result in fast UI code, it also makes testing easier.

Light Event Handlers

Good code us usually easy to test. I’ve found that writing light event handlers then calling higher-level objects helps keep testing simple and increases reusability.

Basics

It’s useful to be fully-versed in JavaScript’s object model and prototypal inheritance. Even though you can use certain libraries to ape classical OO, good code comes from a deep understanding of the tools at hand.

Maintainable and clear code comes from knowing when to exploit JavaScript’s flexible object system, rather than trying to write in a style that doesn’t suit it.

Byte-sized Takeaway

Keeping JavaScript out of templates can help:

Reduce page size
Improve performance
Allow broad brush-stroke changes across a site

To ensure projects are maintainable:

Create a clear link between templates and the location of associated scripts
Use the body ID/class technique
Think in terms of DOM objects — the DOM is a living, breathing system, not just a static page
Exploit JavaScript’s inherent advantages rather than trying to force it to be something it isn’t

Permalink | Leave a comment »

Following up on how to test a config.ru, an actual patch

Thu, 22 Apr 2010 00:37:19 -0700

http://github.com/timocratic/rack-test/commit/dd5324627890b4632c07deed1fc2528...

Permalink | Leave a comment »

Testing a rackup (config.ru) file with Rack::Test

Wed, 21 Apr 2010 10:20:00 -0700

The ever useful rack-test gem let's you easily integration test any rack project. All you have to do is include the Rack::Test::Methods and define an app method that returns your rack app. So people usually have a config.ru that just references their my_application.rb that they reference in their config.ru and then in their test file they can also reference that app and return it. Something to to this effect:

class MySweetRackApp
  def initialize
    Proc.new { |env| [200, {'Content-Type' => 'text/html'}, ['success']] }
  end
end

I had a project where I was actually trying to better breakdown a more complex app, and I wanted to just be able to use Rack's built-in map method at the top level of my config.ru to route to different apps. And in at least some of the cases I wanted to be able to test the whole thing. Also, I figured sometimes it's useful to actually be able to test your rackup file itself, all routing/mapping included. So I dug around in the rack code and found how the rackup command handles the .ru file, and came up with this:

use Rack::Bug
map '/my_sweet_rack_app'
  run MySweetRackApp.new
end
map '/'
  DenyAccessAndRecordRetinaApp.new
end

Update

If you are running off of a new enough version of rack, you could also just use Rack::Builder.parse_file

Permalink | Leave a comment »

Just making sure it fits before...

Thu, 15 Apr 2010 12:13:49 -0700

Permalink | Leave a comment »

Beware respond_to format with redirects in shared systems before_filter - DoubleRenderError

Tue, 13 Apr 2010 12:28:00 -0700

If you have global before_filters for things like requiring login to access pages (such as in authenticated_system.rb), be careful of missing formats in the respond_to. I just tracked down a bug on an app where we were getting DoubleRenderErrors because of unauthenticated requests directly against a dynamic csv file.

We had a before_filter that was denying request and redirecting them to login, in different ways, depending on the format, but hadn't thought to include csv. In this case, it is wise to include a catch-all at the end using .any

def anon_access_denied
  respond_to do |accepts|
    accepts.html do
      store_location
      redirect_to login_path
    end
    accepts.xml do
      headers["Status"]           = "Unauthorized"
      headers["WWW-Authenticate"] = %(Basic realm="Web Password")
      render :text => "Could't authenticate you", :status => '401 Unauthorized'
    end
    accepts.js do 
      render(:update) { |page| page.redirect_to login_path }
    end
  end
end

Permalink | Leave a comment »

Simplicity does mean simple, readable methods

Sun, 28 Mar 2010 11:51:25 -0700

Following a link from @raganwald I came across an article where Mike Taylor was debating wether the concept of simplicity, as it pertains to the length and complexity of methods isn't subjective. He read a decent chunk of Fowler's Refactoring, found himself disagreeing with the tendency to composable, well named methods, in favor larger methods with the low-level implementation in the method itself, and hoped maybe he was wrong, because the lure of The One True Way is strong. While I am often a subjectivist, as I told my fiance, "Honey, somebody on the internet is wrong - I must inform them immediately."

Basically Mike breaks it down into two approaches: top-down, where the methods are named what they do and abstracted away so you don't see each step of implementation at the top, and bottom-up, where the main method is a little larger and is built up of the implementation itself. He favors bottom-up, and I am a partisan of the other camp, as rubyists often seem to be.

I think there is one most important reason to favor the big-picture top-down in this dichotomy. From top-down you can dive down into the implementation and see the details if you chose, but in bottom-up there is no way to get the equivalent top-down view without just reading and understanding the whole program. Basically, advocating the bottom up approach is like making world-maps illegal, because you can get a better feel for navigating your hometown with a city-map.

From this flows the second most important reason, the inability to mentally page out to disk, so to speak, means you have to hold more of the program in your head to understand what is going on. That means as the program grows in size, it gets harder and harder to keep track of it all. And the reason this is really a problem, is when it comes time to introduce new people to the code. By not abstracting things away into bite-sized chunks you've just forced them to learn every piece of everything involved to have a hope of understand things enough to actually get any work done.

A third point: various software engineering theories like: cyclomatic complexity and single-responsibility principle.

I will admit that getting carried away with classitis and class hierarchies, Java style, has some cost, when it comes to following what a program does. There is a little balancing act required there. But, I do think, that decomposing methods is an unequivocal win. I think Rein's tongue-in-cheek talk on Unfactoring is a better visual, code-based proof of the importance of this for maintainability than anything I could whip up here (about 5 minutes in he gets into the examples).

Lastly, who hasn't gone back and looked at their old code and wondered what they were doing? If you want to go back and tweak something, it's painful if you have to refigure out every piece of implementation. This is a case where scanability and readability is a huge win.

Permalink | Leave a comment »

The trouble with bash colored prompts munging your control-r bash history searches

Sat, 06 Mar 2010 14:44:00 -0800

Basically, you just want to be very careful properly escaping and ending color sequences in your bash prompt. If you mess them up, when you try to use spiffy bash tricks that alter the text on your current input line, such as control-r to search through your bash history and then left of right arrow to edit that line, you'll get a partially overwritten line that is impossible to read or edit properly.

#Just be careful.  Safest to properly end color sequence, so instead of this
#export PS1="\[\033[01;32m\]\u\[\033[00m\]\[\033[01;31m\]\$(git_br)\[\033[01;32m\]\[\033[00m\]:\[\033[01;36m\]\$(git_pwd)\[\033[00m\]\$ "
 
#do this
USER_GREEN='\[\e[01;32m\]'
#NO_COLOR='\[\e[00m\]'
REPO_RED='\[\e[01;31m\]'
PATH_BLUE='\[\e[01;36m\]'
END_COLOR='\e[m'
 
PS1="${USER_GREEN}\u${END_COLOR}${REPO_RED}\$(git_br)${END_COLOR}:${PATH_BLUE}\$(git_pwd)${END_COLOR}$ "

Permalink | Leave a comment »

Using open3 in ruby to call an interactive shell command with all three pipes while avoiding block

Thu, 25 Feb 2010 06:40:00 -0800

Apparently when using the three standard pipes (stdin, stdout, stderr)
in your own programming, it is REALLY easy to block or deadlock on
them. At first I figured there were problems in the ruby *open3
library, but this is not ruby specific, I found message board
discussions about similar problems using perl open3 libraries.

Trying to figure out these quirks is made harder by the fact that all
of the common ruby examples are non-interactive, and just close the
stdin before trying to read any output. Even worse, many, many shell
programs don't use stderr and stdout in what I understood as the
proper way. For instance I first as trying to use ftp as the command,
but this proved beyond my abilities. I then came up with a simple
working example that calls dc (the simple reverse polish calculator
available on most unixes), and discovered that on errors it outputs to
both stderr and stdout (different text). I was not able to in any way
to get the output from stderr until I closed stdin (short of
redirecting stderr to a temp file).

This drives home the point that you shouldn't be doing this too much,
in ruby. Generally, use a better, task-specific ruby library, for
these sort of tasks. If you want to use ftp, use net-ftp, for
instance. If you want to use more extensive interactive shell
sessions, check out Ara Howard's session
gem

#http://github.com/ahoward/open4 is an alternative that handles pid and exit status
#http://github.com/ahoward/session a more fleshed our shell utility
require 'open3'
 
Open3.popen3("dc") do |stdin, stdout, stderr|
  t = Thread.new(stderr) do |terr|
    while (line = terr.gets)
      puts "stderr: #{line}"
    end
  end
  
  puts "pushing 5 to stack"
  stdin.puts(5)
  puts "pushing 10 to stack"
  stdin.puts(10)
  puts "pushing + to stack"
  stdin.puts("+")
  puts "sending print command"
  stdin.puts("p")
  result = stdout.gets
  puts "stdout: #{ result }"
  
  puts "\ntrying an unsupported command"
  stdin.puts("b")
 
 
  extra_info_not_in_stderror = stdout.gets
  puts "stdout: #{extra_info_not_in_stderror}"
 
 
  puts "\nclosing stdin to avoid deadlock with stderr"
  stdin.close
 
  # puts "let's give stderr a chance to run"
  # t.run or sleep 1
  
  puts "joining"
  t.join
end

*Open3 as a naming convention tends to be a library to call shell
commands with the three aforementioned pipes.

Permalink | Leave a comment »

Call a custom jar from ruby in jruby

Mon, 15 Feb 2010 23:40:00 -0800

#javac HelloWorld.java && jar cvf HelloWorld.jar HelloWorld.class
require 'java' 
require 'HelloWorld.jar' 
import 'HelloWorld'
 
puts HelloWorld.new.hello 
#=> "Hello cruel world"
 
#jruby hello_world.rb

Permalink | Leave a comment »

Making config.gem in Rails 2.3.x allow you to install from a direct url or the local filesystem

Sat, 13 Feb 2010 17:57:26 -0800

If you are on Rails 2.3.x (pre-Bundler) and want to organize some of your shared functionality into gems, but they are for internal use only, you could set-up a private gem server and point the :source at this server. And then you could deal with authentication, and then...

Or as a quick hack you could just allow for config.gem to reference the gemfile directly, which would then mean 'rake gems:install' would work, even if the gem were stored locally, or on a file-server, etc. Also useful as you could then just point at a .gem file on github.

## require in config/environment.rb before init starts
#require 'config/add_explicit_path_to_config_gem'
#Rails::Initializer.run do |config|
#config.gem 'my_gem', :version => '0.0.1', :explicit_path => "#{RAILS_ROOT}/vendor/local_gemfiles/my_gem-0.0.1.gem" #or
#config.gem 'my_gem', :version => '0.0.1', :explicit_path => "http://github.com/myname/myrepo/raw/master/mygem.gem" #or
 
module Rails
  class GemDependency
    def initialize_with_explicit_path(name, options = {})
      @explicit_path = options[:explicit_path]
      initialize_without_explicit_path(name, options = {})
    end
    alias_method_chain :initialize, :explicit_path
    
  private
  
    def install_command
      cmd = %w(install) << (@explicit_path || name)
      cmd << "--version" << %("#{requirement.to_s}") if requirement
      cmd << "--source"  << @source  if @source
      cmd
    end
  end
end

Permalink | Leave a comment »

"Object is not missing constant XXX" and "A copy of YYY has been removed from the module tree but is still active" when using Rails metal

Wed, 10 Feb 2010 16:12:00 -0800

If you have a Rails metals that has enough code to have its own subdirectories that live in your Rails load_paths you can get stuck in dependency hell. The combinations of autoloading, rails reloading on development, and running through the metal can intersect in nasty ways: on the first request you get "Object is not missing constant XXX" and subsequent requests kick off "A copy of YYY has been removed from the module tree but is still active."

The easiest solution is to kill magic reloading for this metal's code by adding the metal's directories of code to the Rails load_once_paths and then using explicit require_dependency calls for any files that give you trouble. For example, I have a MadMetal that referenced a Mad which has a whole sub-directory structure of code that, for now, lives under lib/mad:

#config/environment.rb
config.load_once_paths += Dir["#{RAILS_ROOT}/lib/mad/**/"]

#app/metal/mad_metal.rb
require_dependency 'mad'
class MadMetal
  def self.call(env)
    if (env["PATH_INFO"] == '/the_path_to_my_metal')
      Mad.call(env)
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

And wallah, no more conflicts between development auto-reloading and metal.

Of course, now you need to restart the server if you change code in lib/mad. In this case it's not a problem for me because the app is also a stand-alone rack app that I run with shotgun when I want development environment reloading.

Permalink | Leave a comment »

Tagging a git release with current branch name and date

Tue, 02 Feb 2010 13:57:00 -0800

Either add this to your .git/config

[alias]
datetag = !git tag `git name-rev --name-only HEAD`-`date \"+%Y%m%d%H%M\"`

or run it in your project folder to add it to the config for that project:

git config alias.datetag '!git tag `git name-rev --name-only HEAD`-`date "+%Y%m%d%H%M"`'

Then you can just run 'git datetag' to create a new tag to use as a release

Permalink | Leave a comment »

Setting RAILS_ENV on Dreamhost when running Passenger

Tue, 02 Feb 2010 01:47:41 -0800

It may depend on which server you are on, but mine has mod_env
enabled, so it's a simple matter of setting the ENV['RAILS_ROOT'] in
an .htacess file

 
SetEnv RAILS_ENV staging

Permalink | Leave a comment »

http://g.raphaeljs.com/

Wed, 09 Dec 2009 13:26:45 -0800

A sweet javascript charting/graphing library. Soon there may be no
need for flash/flex every again?

Permalink | Leave a comment »

Avoiding some of the negative trade-offs in the template pattern with ruby's dynamicism?

Mon, 23 Nov 2009 11:12:00 -0800

So my buddy Tammer's recent post about the Gang of Four's Template Pattern reminded me of some code I saw recently. A start-up's greenfield project had it's authorization done in a pretty clean way using the template pattern. Basically every object determined what could be done to it, something like this:

After continuing this approach to fully cover CRUD you make a straight-forward set of accessors that can be used to easily enforce permissions in the controller in a programmatic way (this project was using on of the inherited resourceful-controller plugins, so that was a big plus). The developer who implemented this commented that the trade-off for this simplicity was having to look in each individual model file to figure out what a user can do overall.

I figured I liked everything about this scheme except that trade-off, and since ruby is so dynamic, why settle for almost. Why not just reopen each class in the authorization file and add the methods. You still get the simplicity and encapsulation of having the model able to determine it's own permissions, based on it's state and methods, and there is still one place to look to review/change the permissions for the whole project:

a timocracy of one

A list of some sites I follow to keep up in my field (ruby and web development)

Git sub-tree merging back to the subtree for pushing to an upstream

Our vows and pre-vow speeches

Roula

Tim

Vows

The Tea Party is Racist

Unobtrusive JavaScript vs. Kool-Aid

Unobtrusive JavaScript vs. Kool-Aid

Background

Inline JavaScript

The Alternative

Concerns

Mental Models

Strategies and Patterns

DOM Ready

Event Delegation: DRY

Internal Relationships

Test First

Light Event Handlers

Basics

Byte-sized Takeaway

Following up on how to test a config.ru, an actual patch

Testing a rackup (config.ru) file with Rack::Test

Just making sure it fits before...

Beware respond_to format with redirects in shared systems before_filter - DoubleRenderError

Simplicity *does* mean simple, readable methods

The trouble with bash colored prompts munging your control-r bash history searches

Using open3 in ruby to call an interactive shell command with all three pipes while avoiding block

Call a custom jar from ruby in jruby

Making config.gem in Rails 2.3.x allow you to install from a direct url or the local filesystem

"Object is not missing constant XXX" and "A copy of YYY has been removed from the module tree but is still active" when using Rails metal

Tagging a git release with current branch name and date

Setting RAILS_ENV on Dreamhost when running Passenger

http://g.raphaeljs.com/

Avoiding some of the negative trade-offs in the template pattern with ruby's dynamicism?

Maus hanging out in bed

Simplicity does mean simple, readable methods