a timocracy of one

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

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

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

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

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.

"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

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.

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

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:

Thoughts?

interesting new ruby, redis-based background job/queueing choice from the github guys

Yet another queuing system, but I do like the look of the included
Sinatra mini-app for managing it. And isn't redis all the hot thing
now? Or is that a negative?

Maybe hiding initialize in your abstract parent class is too much abstraction?

Or the wrong one. It just seems like over-inheriting is definitely one of the bigger maintainability nightmares I have had; and pulling the constructor entirely into the parent.... Well it better be exactly the parent, and cleanly done.

It's like those overly abstracted resource_controllers. They seem like a great idea, but once you start deviating at all, you spend more code and more time thinking about how to write that code to get out of the straight-jacket over over-inheritance than you would have had in the first place.

I'm starting to feel that while abstract constructors *can* be done right they are often are a smell. Compare these three approaches and let me know what you think:

No JS or in a feedreader? Read the code in the gist

A pretty good overview of ruby's Structs

http://blog.rubybestpractices.com/posts/rklemme/017-Struct.html#

including the oft under-documented passing of a block to new

Creating Your Content - Nesta – a CMS for Ruby Developers

32 Rack Resources to Get You Started | Jason Seifer