Posts Tagged ‘ruby’

Logging exceptions to a file using Padrino

October 11, 2013 Leave a comment

You wouldn’t think this would be a very complex topic.  Something every web server should be pretty good at is letting you see the activity on your server and most importantly the exceptions your app is sure to run into in production.  Without that, it’s rather difficult to hunt down your problems.  From what I’ve found the typical way this is done is by your frontend, be that Thin or whatever redirecting stdout and stderr to their log files.  I find myself in a rather odd situation though, as I am deploying on Windows using Helicon Zoo.  No, Linux deployment is probably not an option for this particular situation.  Ok, so now Helicon does its thing pretty well, makes your Rack app show up in IIS as an app, etc.  Padrino logs its files ok, but exceptions are mysteriously lost to the void.  So what I came up with was to redirect $stdout and $stderr to the Padrino logger (at info and warn levels).  The idea came from this thread.

In my boot.rb file I add the following


Padrino.after_load do
  info_wrapper =, :info)
  warn_wrapper =, :warn)

  $stdout = info_wrapper
  $stderr = warn_wrapper

This wraps up the Padrino standard logger into something that can be assigned to $stdout, namely a subclass of IO. Here’s the IOLogWrapper class

class IOLogWrapper < IO
  def initialize(logger, level)
    @logger = logger

    case level
      when :info
        @method_to_call = @logger.method(:info)
      when :warn
        @method_to_call = @logger.method(:warn)

  def write(str)
    return str.length

Voila! Your exceptions are now logged as info and warning messages in your Padrino log file.

Categories: Development Tags: , ,

The Merbification of Rails

January 12, 2009 5 comments

It’s been a few weeks since the announcement that Rails 3 would be Merb 2.  We had a discussion on our local Phoenix RUG list, my input to which is here.  Then I dug around some more and read the posting by DHH.

This is not a big bang rewrite

So, Rails 3 will be Rails 2 + some unspecified but core stuff from Merb moved over.  And Merb 2 will be … ?  If you’re a rails developer, this is probably not big news in any way, just wait for Rails 3 to be released (or RC status) and figure out what breaks, if you intended to upgrade at all.  However, if you are a Merb developer, or about ready to pick up Merb (like me) this puts you in a pretty bad spot.  Do I learn Merb for all its touted benefits of lean execution and component agnosticism?  Well I could, and then later this year re-learn all over when the API’s change in Rails 3.  The Merb community is saying “come to Merb, it’s like getting a preview of Rails 3”.

That makes this training basically the first training focusing on the future features of Rails 3, and a great way to get ahead of the game. – Yehuda Katz

Except that this is not true.  The Merb API will change when it is merged into Rails.  ActiveRecord is remaining as the default ORM layer and I am positive that other Rails elements will persist.  Merb will be Railsified I think as much as Rails will be Merbified.  How do you withstand hundreds (thousands?) of plugin authors shouting at you to not break things.  I don’t even want to imagine the compromises that will be made when all the users catch on to the idea that lots of API’s will be changing.

Unfortunately I think a clean break is the best possible solution.  Merb was started because Ezra claimed it was far easier to rewrite portions of Rails than try to fix the existing code.  Heck, Merb itself was rewritten from scratch recently with no apparent universe imploding effects so they’ve proven it can be done on a large code base.  Yet we have the situation where DHH will not let go of Rails (his code) to make way for what he to some degree is acknowledging as a better solution.  So my grand hopes of a stack that has all the marketing and acceptance of Rails but the clean implementation of Merb deflates daily.  Moreso, my desire to learn Merb drops to almost zero, I might as well stick with Rails since a) I know it and can move much quicker, b) The Merb API is going to change anyway, c) I suspect we’ll end up closer to Rails than to Merb in the end, at least on the surface.

Categories: Development Tags: , ,

JRuby, still the fastest Ruby implementation

December 9, 2008 Leave a comment

A fairly comprehensive benchmark test has been run across all available (and even some pending) Ruby implementations.

The Great Ruby Shootout

JRuby continues to be the fastest 1.8 compatible implementation by quite a long way.

Categories: Development Tags: , ,

What Ruby developers really want

September 9, 2008 Leave a comment
Survey results, 50% of readers to Ruby Inside want more performance

Survey results, 50% of readers to Ruby Inside want more performance

What’s your biggest beef with Ruby today?  A need for a better thought out sandbox model, people conflating Ruby and Rails (my personal vote), or some other issue?  For 50% of Ruby Inside readers it appears to be performance.  This is interesting because it’s one of the easiest things that can be remedied RIGHT NOW.  Yup, just switch to JRuby and (barring some native extension problems) you’re up and running and faster.  Sometimes this performance boost is quite significant as the JRuby team regularly demonstrates in their blog posts.  So what are you waiting for, go grab the fastest Ruby available and start enjoying that performance!

Categories: Development Tags: , ,

Java game library + JRuby + awesome DSL = Gemini

July 14, 2008 3 comments

I’ve been working with JRuby to build high level systems on top of powerful Java libraries for about 2 years now.  My most successful endeavor has been Monkeybars, a libarary for making Swing a lot easier to use.  My other project has been in the game development arena.  The project name is Gemini, and although it’s not nearly as advanced as Monkeybars, I was able to get to a significant point over the weekend.  Yes, here in all its glory, the simple “crapton of sprites bouncing back and forth demo”.

1000 dukes bouncing back and forth on screen

Now you’re probably saying, big deal, I can do that in like 40 lines of code in <insert favorite programming language/framework> and no doubt you would be correct.  What’s interesting about the way Gemini does things is in how it gives you an extremely flexible way of compositing together your game objects and your application as a whole.

The code to get this going using Gemini is pretty straightforward.  We have a game state that is loaded by Gemini when it starts up.  That game state then instantiates 1000 of our game objects and they proceed to load their images and care for their own logic of bouncing around on the screen.

Here’s the code in main.rb that kicks off the app:

require 'gemini'"Test game", 640, 480)

And here is the state that is loaded by default when Gemini runs: main_state.rb

class MainState < Gemini::BaseState def load @sprites = [] 1000.times {@sprites <<} end def update(delta) @sprites.each { |sprite| sprite.update(delta) } end def render(graphics) @sprites.each { |sprite| sprite.draw } end end [/sourcecode] Finally we have the Duke class that was instantiated in the MainGame class: [sourcecode lang='ruby'] class Duke < Gemini::GameObject has_behavior :Movable2D has_behavior :Sprite has_behavior :UpdatesAtConsistantRate def load self.image = "duke.png" self.updates_per_second = 30 @direction = :right self.x = rand(640 - image.width) self.y = rand(480 - image.height) end def tick if x > (640 – image.width) || x < 0 @direction = @direction == :right ? :left : :right end self.x = x + (@direction == :right ? 1 : -1) end end [/sourcecode] Apart from some hackish ternary ifs in the Duke class I think the whole thing is pretty darn readable, especially considering all that it is doing. As you can see, everything is extremely declarative including those has_behavior calls in the Duke class. Those nifty bits of metaprogramming bring in all the crunchy goodness of the class and make the x, y, image and updates_per_second methods appear. Movable2D gives us a move method and also pulls in the Positional2D behavior that provides the x and y methods. UpdatesAtConsistantRate gives us an update method that calls tick at the rate specified by updates_per_second. Finally the Sprite behavior gives us the image method and the draw method that gets called in the MainGame class. Most of this is bare bones at the moment. What if you don't have the UpdatesAtConsistantRate? When update is called you asplode. Same for Sprite / render. So clearly a more flexible game state is needed, probably involving the game object behaviors auto-registering themselves with the game state to be called during an update/render cycle. But as a whole I'm quite happy with the way Gemini is starting to shape up. Next on the agenda is getting keyboard mapping hooked into the RecievesKeyboardEvents behavior so you can control duke, then we'll have what could pass for a real game.

Categories: Development Tags: , , ,

When good metaprogramming goes bad

June 4, 2008 1 comment

So you’re cruising along, minding your own business, writing your Ruby based application when you hit a bug. A few seconds/minutes/hours later you’ve figured out what this bug is and you have an idea of what is causing it. Ok, this is easy, Ruby apps have all their code open, you can just go in, find the offending method and fix it up. This is so easy you’ll probably even submit a patch back to the project, dang you’re a nice developer

Several hours later you’re ready to toss the library, Ruby, your computer and that guy who drank the last Dr. Pepper. Yes, you have fallen victim to the scourge that is bad metaprogramming. Now I’m not talking about deliberately nasty, obfuscated Ruby type bad metaprogramming. It’s more like well meaning used-to-be-good metaprogramming that’s just gone over the edge and doesn’t realize it.

Sark from Tron

So what does bad metaprogramming look like? Well, I don’t have a great litany of the greatest offenders, but I do have a delicious little gem from our beloved (or not so beloved depending on your perspective), Active Record. You see, I was trying to figure out why my Derby queries were asploding when I used a range in my conditions. (Derby is a pure Java database that I’m hitting via JRuby and AR-JDBC). I found out that Derby requires the time portion of the date, even though their docs would indicate that just a date will work. Also, the SQL output of a DateTime object is very wrong for what Derby is expecting. So, of course the problem is in the Derby adapter, I’ll just check into that and fix up the few places where it’s not outputting the correct SQL.

Derby wants: ‘2008-06-04 00.00.00’ or ‘2008-06-04-00.00.00’

Derby is getting: ‘2008-06-04’ for Date objects and ‘2008-06-04T14:22:50-07:00’ for DateTime object

I dig around a bit and find out that my conditions (in this case a range object) quote_bound_value method which in turn calls the quote method of whatever connection is being used. I’m using JRuby so my connection is of type ActiveRecord::ConnectionAdapters::JdbcAdapter. Ok, great, I dive into that class and search for the quote method. Well, JdbcAdapter doesn’t have such a method, but it’s base class AbstractAdapter does mix in the Quoting mixin which… has a quote method! All is well in the world, except that the quote method of the Quoting mixin isn’t actually being called. I can remove the include statement from AbstractAdapter and I still get the same SQL output. Sigh. Ok, well one of the other mixins to JdbcAdapter must have a quote method that’s overriding the one on Quoting, surely. Well iterating through everything in JdbcAdapter’s ancestors and listing their instance methods yields exactly zero instances of a quote method. Now at this point we enter the realm of eval, instance_eval and singeleton methods, any of which might be used here and all of which are pretty darn difficult to track down. My regex-fu failed and I was unable to find the actual source of the quoting.

A coworker recommended that since I know that Date is getting to_string’d that I stub out that method and have it print out the stack. Great idea. So I reopen Date, do a little open heart surgery on to_s and get my stack trace. It’s a great stack trace, except that it leaves off at quote_bound_value. So evidently Ruby’s having an issue keeping track of where the next method lives also. Oh well, it was a nice try.

In the end, having seen how Active Record resolves its parameters I developed a workaround. I pass a range of string values, of which Active Record will call .first and .last to get the values to use for the between part of the query. So by pre-formatting my dates I get a valid query.

I had heard of the “black magic” properties of Active Record, people commenting on how it was doing too much metaprogramming. Up to this point I mostly figured those people were from the Java or PHP camps and simply didn’t like metaprogramming in general. I know feel their pain. So remember, when writing your libraries, considerhow hard it’s going to be for someone to come along and track down a bug in your system so that they can submit a patch.