Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Monkey Patch Du Jour

Alex Chaffee
Sunday, May 24, 2009

The following monkey patch gives a bit more information in the ActiveRecord SQL logs. Instead of just saying “User Load” it also says the file and line number in your code that asked AR to perform the operation. That way you can have a hope of tracking it down and optimizing it away if at all possible.

  User Load (0.2ms) views/main_page.rb:107:in `filters_box'   SELECT * FROM `users`

Code after the jump. I guess you put it in environment.rb with all the other monkeys.

    module ActiveRecord
      module ConnectionAdapters
        class AbstractAdapter
          def log_info(sql, name, ms)
            if @logger && @logger.debug?
              c = caller.detect{|line| line !~ /(activerecord|active_support|__DELEGATION__)/i}
              c.gsub!("#{File.expand_path(File.dirname(RAILS_ROOT))}/", '') if defined?(RAILS_ROOT)
              name = '%s (%.1fms) %s' % [name || 'SQL', ms, c]
              @logger.debug(format_log_entry(name, sql.squeeze(' ')))
            end
          end
        end
      end
    end
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Capturing Standard Out In Unit Tests

Alex Chaffee
Monday, May 11, 2009
    def capturing_output
      output = StringIO.new
      $stdout = output
      yield
      output.string
    ensure
      $stdout = STDOUT
    end

then…

    it "exits immediately from --version" do
      output = capturing_output do
        lambda {
          Erector.new(["--version"])
        }.should raise_error(SystemExit)
      end
      output.should == Erector::VERSION + "n"
    end
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Edward Hieatt

GoGaRuCo

Edward Hieatt
Thursday, April 16, 2009

The first Golden Gate Ruby Conference (GoGaRuCo) starts tomorrow in San Francisco. Pivotal Labs is happy to be a sponsor of the event. Pivot David Stevenson will be giving a talk titled “Playing With Fire: Running Uploaded Ruby Code in a Sandbox“. We have a booth where you can come by and chat with us; we’ll be showing off Pivotal Tracker.

Also, Pivotal Labs will be hosting the live Justin.tv feed of the entire conference at pivotallabs.com/gogaruco. Pivot Chad Woolley will be live-blogging every talk at pivotallabs.com/gogaruco/blog and, when the conference is over, we’ll make available videos of all the talks from the conference at pivotallabs.com/gogaruco/talks.

If you’re coming to the conference, we’re looking forward to seeing you there; otherwise, we hope you’ll follow along from home, starting at pivotallabs.com/gogaruco!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Abhijit Hiremagalur

Standup 01/16/2009: onReady() for AJAX, Web Sprites & Detecting UTF-8

Abhijit Hiremagalur
Monday, January 19, 2009

Interesting Things

  • Web based sprite generator – here

This also makes the generated sprite really small which is great if you care about page load times. A Ruby+ImageMagick sprite generator might also be a good thing to build.

  • Cool way of detecting if a file is UTF-8 enconded using Ruby+IConv – here

Ask for Help

“Is there an onReady() for AJAX events?”

  • onAJAXReady() ?
  • JQuery Live Events might do the trick
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Abhijit Hiremagalur

Standup 01/13/2009: daemons, encoding

Abhijit Hiremagalur
Tuesday, January 13, 2009

Ask for Help

“Daemon best practices in Ruby?”

  • We haven’t tried DaemonKit
  • SimpleDaemon is what we currently use, which we suspect of interfering with monit (had problems with multiple instances starting, and process not starting upon reboot).
  • A couple of people suggested looking at Daemonize
  • Always monitor daemons with sanity checks (e.g. memory usage); use Monit or God
  • Roll your own?

“cut doesn’t handle strange characters in large (5GB) text file, are there other unix commands for text file manipulation that are utf-8 compliant?”

  • Try awk/sed maybe
  • Try using od/hexdump to figure out what the weird characters are

UPDATE 01/14/2009: Chad’s corrections

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Adam Milligan

Aristotle, Aristotle was a bugger for the bottle…

Adam Milligan
Saturday, January 3, 2009

With the recent holidays, along with a hint of flu season, things have slowed down a bit, and I’ve finally had some free time to go back and watch a few of the talks I missed at RubyConf this year (recordings are available here). Notably, I also took the opportunity to re-watch Jonathan Dahl’s talk on Aristotle and the Art of Software Development. For anyone who missed it, I highly recommend you check it out. It was, in my opinion, one of the best talks of the conference.

You may be wondering what philosophy has to do with writing software. Watch the video. Listen to what Jonathan has to say. I believe fairly strongly that questions of how we think, how we communicate, how we interact with one another, etc. will become increasingly, and overshadowingly, important as the software industry continues to grope its way toward some sense of what it is we’re all doing, and what it means to do it well.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Adam Milligan

Keeping your errors in line

Adam Milligan
Saturday, December 27, 2008

How many times has this happened to you? You get a cool design for your website, and you spend a bunch of time lining up all of your images and roundy-corner widgets and input boxes just… so…, and everything looks great. But, then you submit a form without typing in your favorite ice cream (a required field, of course), and suddenly your layout is splattered about like an extra large scoop of rocky road in the hands of a two year old. It’s enough to make you want to stab your eyes out with a hedge trimmer.

The reason is, of course, that ActionView automagically wraps a div around any input element for an ActiveRecord attribute with validation errors. This div has the class ‘fieldWithErrors’, which makes it all red and nasty looking to tell your wayward user that they need to cough up some more information.

Now, input elements are inline elements, so they don’t break page flow. At the same time, div elements are block elements, so they break page flow and use up as much width as is available to them. When ActionView renders a form for your ActiveRecord object with errors, it alters the HTML structure that you’ve so painstakingly laid out, inserting these disruptive divs where previously there were only gentle, friendly input elements. Not to mention that it might be inserting these div elements inside other HTML elements that, according to the standard, mustn’t contain div elements. BOOM. Browser-specific nastiness all over the place.

So, a fellow by the name of Alex MacCaw opened a Rails ticket with a patch to change this fieldWithErrors div element to a span. Span elements are, of course, the inline version of div elements.

Based on some of the feedback, and the fact that ActionView modifying the HTML structure of my views annoys me, I created a somewhat more invasive patch for this ticket.

I changed ActionView to not add an any elements to the HTML structure, but to add the ‘fieldWithErrors’ class directly onto the input element for the attribute with errors.

I also added a #field_error_options class accessor on ActionView::Base, with which you can customize the HTML attributes that ActionView adds to these inputs. The value of #field_error_options defaults to

{ :class => 'fieldWithErrors' }

This will combine with any class option you’ve specified on your tag builder, so

<%= text_field @foo, :bar, :class => 'wibble' %>

will generate

<input type='text' name='foo[bar]' class='fieldWithErrors wibble' />

when the bar field fails validation on @foo.

ActionView::Base still has the #field_error_proc class accessor, so you can still add HTML structure to input elements for invalid attributes if you so choose. However, I changed this to default to nil.

Check it out, see what you think. And keep away from the hedge trimmer.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Adam Milligan

has_one-ish :through

Adam Milligan
Saturday, December 27, 2008

Rails has had the has_one :through association for a while now, and you probably use it on occasion. But, has it ever given you the heebie-jeebies a little bit? Maybe something happens now and then that doesn’t seem quite right? Well, the reason for this is that HasOneThroughAssociation, the class that ActiveRecord uses (shockingly) to implement has_one :through associations, is a subclass of HasManyThroughAssociation.

Whhaaaaaaaaaat?

Yes, oddly enough, a has_one :through association is a collection that is special-cased to always return just one element. Seems kind of dirty, doesn’t it?

I have two, related, problems with this inheritance relationship. First, it violates Liskov substitutability. One cannot in any way argue that a has_one :through association IS A has_many :through association; substituting one for the other would not be likely to maintain a program’s correctness. Second, the inheritance relationship exists to share implementation, not interface. Among others, the Gang of Four have described, persuasively, why this is a terrible idea.

More practically, I’ve now run into two serious bugs caused by this relationship. The first one caused newly created has_one :through associations to return an empty array rather than nil. I fixed that here, with the help of wunderkind David Stevenson. The second I ran into in the last few days while working on this patch, which I’ve written about here. It turns out that trying to get #method_missing to behave sensibly for all non-collection associations is difficult when one of those associations inherits a pile of collection-specific functionality.

So, in order to make my #method_missing patch work I had to rewrite HasOneThroughAssociation with a more appropriate superclass (I used HasOneAssociation). You can find that patch here. Hopefully this change will make its way into the Rails codebase and will make lives easier for generations to come.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Adam Milligan

#method_missing makes me eat my words

Adam Milligan
Saturday, December 27, 2008

A while back I wrote about private methods in ActiveRecord objects, and how Rails 2.2 makes them behave as they should. ActiveRecord associations will no longer respond to private methods defined on their targets; however, my colleague Joseph pointed out that they also no longer respond to methods defined via #method_missing on their targets. Which sucks horse poop through a straw, to some extent.

In my original post I wrote this, fully aware that I was writing lies, but mostly in a rush to get on to my point at the time:

Sometimes I’m forced to use #send:

method_name = extract_method_name_from_the_aether
some_object.send(method_name)

In order to make this code correct with regard to access control I have to add cruft:

method_name = extract_method_name_from_the_aether
some_object.send(method_name) if some_object.respond_to?(method_name)

The astute reader will note that the second code block doesn’t actually approximate the behavior of calling a private method via function call syntax. It should look more like this:

method_name = extract_method_name_from_the_aether
raise NoMethodError if some_object.private_methods.include?(method_name)
some_object.send(method_name)

Two things to notice here: first, the original code didn’t throw an exception if it failed to call the method; second, and much more importantly, the set of private methods is not the complement of the set of methods an object will respond to. So, using !#respond_to? as the condition for preventing the method call is too restrictive. The fact that this code will prevent calling a non-private method defined via #method_missing clearly shows this.

Now, I know the Rails core team chose to use #respond_to? in this particular case for a good reason (which my original patch did not take into consideration): performance. Some simple investigation quickly shows that #include? is an order of magnitude slower than #respond_to? Method calls happen quite a lot, so slow is bad.

I’ve submitted another patch that should correct the #method_missing behavior without dragging everything to a halt. Building on my previous examples, the code looks something like this:

method_name = extract_method_name_from_the_aether
raise NoMethodError if !some_object.respond_to?(method_name) && some_object.private_methods.include?(method_name)
some_object.send(method_name)

Note that the conditional expression is now redundant; the first condition cannot be false if the second condition is true. However, an object will likely respond to the majority of method calls sent to it. The first conditions will (quickly) evaluate to false in these cases, short-circuiting the conditional. In the minority of cases where the first condition evaluates to true, the second condition will (slowly, but correctly) determine if the method call violates access control.

Unfortunately, sensible as it may seem, this change actually breaks has_one :through associations, because of collection-specific functionality they inherit from has_many :through associations. (Oh yes, has_one :through associations are collections, based on their place in the ActiveRecord inheritance hierarchy. Or, they were; read more about that here).

And, finally, I think it’s important to note that none of these machinations in Rails would be necessary if #send (and #send!) actually worked as it should. Heads up, Matz.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Edward Hieatt

Back in the land of the living (or: How RubyMine makes me happy)

Edward Hieatt
Wednesday, December 17, 2008

How my outlook on coding in Rails has changed over the past few months!

When I made the switch from Java to Rails a few years back, I, like many of my fellow Pivots making that same well-chronicled transition, delighted in the ease with which we could suddenly knock out a web app. How we cheered when our object-relational mapping took zero lines of code! How we applauded when we declared our model object validations in near-English! How we roared with laughter when convention viciously slapped the face of configuration! And how we shook our heads in dismay when we realized that our new development environment appeared to be from the mid-, if not early, nineties.

For, while we had arrived in a brave new world of minimalist declarative meta-programming, rapid prototyping, and an new-found sense of productivity that made even the most nimble forms of Java development look like wading through a morass of slimy boilerplate code and endless XML, we soon realized that the IDE situation was less than awesome. Our productivity was overall much improved, but we had taken a huge step backwards when it came to the act of writing – and especially changing – code and tests. Overnight, we went from living it up in a paradise of automated refactorings, seamlessly inbuilt test runners and powerful debuggers to roughing it with a text editor that, to our spoilt eyes, appeared to offer barely more than code highlighting and support for homemade macros.

Not only didn’t our favorite Java IDE, IntelliJ, not function well with Ruby, but nor did Eclipse, and nor did NetBeans. Early on, each had some nominal support for Ruby, it’s true, but it was mostly just code highlighting and some basic navigation. If we wanted to run a test, we had to (horror of horrors) leave our IDE, go to a shell and run a command (mapping a key to an “external tool” was cold comfort, it seemed to me). If we wanted to rename a variable, we had to do it manually. And if we wanted to debug something, well, the only option was to use a tool that appeared so prehistoric that we simply didn’t do it.

In fact, things were so bad that if we were honest with ourselves, TextMate sometimes looked like a better option that the IDE we knew and loved. We pleaded with Pivots who didn’t come from the world of Java to use IntelliJ, if only (for them) for its awesome global search, and if only (for us) to make ourselves feel comfortable in the new world of Rails. But IntelliJ had been rendered so impotent by its Ruby Kryptonite that it felt at times as if we were simply dragging around a comfort pillow that had lost its stuffing. All the progress that had been made in the world of Java IDEs for so many years seemed to have been lost. Woe was certainly us.

But then came some signs of life. NetBeans and Eclipse (in its various forms) were making progress in Ruby-land: they had test runner integration and debuggers that worked. Big steps forward indeed. While I suspected that I would probably miss IntelliJ, I nevertheless gallantly tried to commit to one of them: if they were going to offer me something even close to the power I used to have in my Java IDE, I was willing to put up with a lot. But despite my best attempts to be patient, I was disappointed time and time again. Eclipse still felt clunky compared to IntelliJ. NetBeans still suffered from a problematic global search and less-than-perfect VCS integration. They are gallant attempts, and they deserve credit. They’re both great products and they both serve communities that no doubt find them invaluable. But in that very unquantifiable, personal, emotional way, they weren’t what I really wanted. I wanted that IntelliJ feel.

So where was JetBrains on this? There was the Ruby plugin for IntelliJ, which was making some great strides forward, but that always felt like a bolt-on solution at best. What was more, it often didn’t work with new IntelliJ updates.

Imagine my surprise and delight, then, when Christmas came several months early this year. Suddenly, in late 2008, we are quietly presented with RubyMine. IntelliJ for Ruby? Surely not! I dared not hope for too much when with some trepidation I downloaded an early pre-EAP candidate a few months ago. But, joy of joys, it turned out that it was, or rather, is gradually becoming, (almost) all I was hoping for. Built-in test runner, debugger, pretty good refactorings – all things that other IDEs provide, but in that special JetBrains way that is so much more intuitive. Great success!

Now, I realize that all this probably sounds like a gush of praise that is not yet due, and perhaps that’s true. It’s certainly true that there’s a long way to go: RubyMine is lacking in many ways. But the signs are there that things are moving hastily in the right direction. Recently, each build that has come out has been noticeably better to me than the last (additional useful features, stability, performance). But more importantly, I feel like JetBrains is on the right trajectory with RubyMine. We now have a path towards a great IDE for Rails. I think we’re back in the land of the living, and I’m hopeful that between Rails and RubyMine our productivity will soon jump higher than we could have imagined just a few years ago.

OK, start the “All you need is Emacs”, “VIM is the best thing ever”, and “TextMate rocks, what’s this IDE nonsense?” comments below :)

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (780)
  • rails (113)
  • testing (88)
  • ruby (83)
  • ruby on rails (70)
  • jobs (62)
  • javascript (55)
  • techtalk (44)
  • rspec (38)
  • ironblogger (32)
  • productivity (30)
  • activerecord (29)
  • gogaruco (29)
  • git (28)
  • nyc (27)
  • rubymine (26)
  • bloggerdome (23)
  • mobile (22)
  • process (21)
  • pivotal tracker (20)
  • cucumber (20)
  • jasmine (19)
  • design (18)
  • ios (18)
  • webos (17)
  • objective-c (17)
  • android (16)
  • palm (16)
  • "soft" ware (16)
  • fun (15)
  • tracker ecosystem (15)
  • ci (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • bdd (14)
  • gem (13)
  • css (13)
  • tdd (13)
  • selenium (12)
  • goruco (12)
  • bundler (12)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
  • mojo (10)
  • chef (10)
  • api (10)
Subscribe to ruby Feed
  1. ←
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. 9
  11. →
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >