Hey Judy, don’t make it bad

Last week we explained how we greatly reduced the rendering time of our web views by switching our escaping routines from Ruby to C. This speed-up was two-fold: the C code for escaping HTML was significantly faster than its Ruby equivalent, and on top of that, the C code was generating a lot fewer objects on the Ruby heap, which meant that subsequent garbage collection runs would run faster.

When working with a mark and sweep garbage collector (like the one in MRI), the amount of objects in the Heap at any given moment of time matters a lot. The more objects, the longer each GC pause will take (all the objects must be traversed during the Mark phase!), and since MRI’s garbage collector is also “stop the world”, while GC is running Ruby code cannot be executing, and hence web requests cannot be served.

In Ruby 1.9 and 2.0, the ObjectSpace module contains useful metadata regarding the current state of the Garbage collector and the Ruby Heap. Probably the most useful method provided by this module is count_objects, which returns the amount of objects allocated in the Ruby heap, separated by type: this offers a very insightful birds-eye view of the current state of the heap. – Hey Judy, don’t make it bad by Vicent Martí

CGI.escape and “Undefined method ‘bytesize’ for nil:NilClass”

Recently I’ve begun to encounter the above error more often. The issue is that Rails uses SafeBuffer instead of String in lots of places which then occasionally get passed to CGI.escape which internally calls #gsub and mucks with the magic variables $1, etc.

Annoyingly, CGI.escape only does this depending on the input.

SafeBuffer does not like this at all. Behold…

1.9.3p327 > s = ActiveSupport::SafeBuffer.new("foo")
 => "foo"
1.9.3p327 > CGI.escape(s)
 => "foo"
1.9.3p327 > s = ActiveSupport::SafeBuffer.new("foo>bar")
 => "foo>bar"
1.9.3p327 > CGI.escape(s)
NoMethodError: undefined method `bytesize' for nil:NilClass
  from .../lib/ruby/1.9.1/cgi/util.rb:8:in `block in escape'
  from .../active_support/core_ext/string/output_safety.rb:169:in `gsub'
  from .../active_support/core_ext/string/output_safety.rb:169:in `gsub'
  from .../lib/ruby/1.9.1/cgi/util.rb:7:in `escape'
  ...
1.9.3p327 > CGI.escape(s.to_s)
NoMethodError: undefined method `bytesize' for nil:NilClass
  from .../lib/ruby/1.9.1/cgi/util.rb:8:in `block in escape'
  from .../active_support/core_ext/string/output_safety.rb:169:in `gsub'
  from .../active_support/core_ext/string/output_safety.rb:169:in `gsub'
  from .../lib/ruby/1.9.1/cgi/util.rb:7:in `escape'
  ...
1.9.3p327 > CGI.escape(s.to_str)
 => "foo%3Ebar"

Rails by itself is pretty decent at dealing with this, but I’ve noticed that several of the gems I use call CGI.escape without checking their arguments. One could argue of course that CGI.escape should do it’s best to convert the arguments it gets into a pure string, but I won’t get into that. – CGI.escape and “Undefined method ‘bytesize’ for nil:NilClass”  by Philip Hallstrom

Introducing a New Look for Traces

Our fundamental unit of performance data is the trace, an incredibly rich view into the performance of an individual request moving through your web application. Given all this data and the diversity of the contents of any individual trace, it’s important to have an interface for understanding what exactly was going on when a request was served. How did it get handled? What parts were slow, and what parts were anomalous?

Over the past year, the TraceView team has been listening to your thoughts on this topic as well as hatching some of our own. Today we get to share the fruit of our labors: Trace Details, redesigned! – Introducing a New Look for Traces by dkuebric

Make Your Continuous Integration Server STRIKE FIRST and STRIKE HARD.

If automated testing is a part of your process, you know how much it hurts when tests fail on your master branch. Every red test on master makes it more likely that further breakages will sneak in, for several reasons:

  1. If master has failures, when you’re starting to review a feature branch, rather then relying on color recognition (red versus green), you need to use brainpower to separate “new failures” from “old failures”. Whenever you need to use your brain, there’s the chance that you might not end up with the right idea.
  2. Even if you never make mistakes, if the first in a series of assertions fails, this can prevent the rest from even running! In other words, because tests are failing, you’re now testing less than you were.
  3. Most importantly, good people have a powerful psychological need to preserve beautiful things. A pristine test suite is beautiful, and tends to motivate developers to keep it that way.

How best to keep the master branch green? You could attempt to foster an organizational appreciation that breaking master is a Very Bad Thing, in the hopes that this will make it happen less often. Some folks take this to interesting extremes, including ritual humiliation (however tongue in cheek). – Make Your Continuous Integration Server STRIKE FIRST and STRIKE HARD. – by Matthew Forsyth

5 useful tips for a better commit message

You’re already writing decent commit messages. Let’s see if we can level you up to awesome. Other developers, especially you-in-two-weeks and you-from-next-year, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.

  1. The first line should always be 50 characters or less and that it should be followed by a blank line. Vim ships with syntax, indent, and filetype plugins for Git commits which can help here.
  2. Add this line to your .vimrc to add spell checking and automatic wrapping at the recommended 72 columns to you commit messages.
    autocmd Filetype gitcommit setlocal spell textwidth=72
  3. Never use the -m <msg> / --message=<msg> flag to git commit. – 5 useful tips for a better commit message by Caleb Thompson

Combine Coveralls and Codeship to track your code coverage

When starting with continuous integration and deployment, code coverage is one of the tools that improve your workflow significantly.

Being able to quickly grasp which parts of your application aren’t well tested is incredibly important. Especially tracking your code coverage over time is a powerful feature.

With this in mind we were always searching for some way to help our users get started with integrating code coverage into their workflows. Today we are happy to announce that we worked together with Coveralls.io to integrate their code coverage service.

Coveralls.io

After a test run Coveralls automatically collects your code coverage data, uploads it to their servers and gives you a nice interface to dig into it. They even show you trends and changes on coverage for all of your files. Really awesome. – Combine Coveralls and Codeship to track your code coverage by Florian Motlik

From test-driven development to Behavior-driven development

This is the second blog post of our new Testing Tuesday series. Every Tuesday we will share our insights and opinions on the software testing space. Drop by every Tuesday to learn more!


Last Testing Tuesday we talked about test-driven development. We considered it the basis for Behavior-driven development. But what’s the difference between them?

Test-driven development focuses on the developer’s opinion on how parts of the software should work. Behavior-driven development focuses on the users’ opinion on how they want your application to behave.

Behavior-driven development

Test-driven development is rather a paradigm than a process. It describes the cycle of writing a test first, and application code afterwards – followed by an optional refactoring. But it doesn’t make any statements about

  • Where do I begin to develop?
  • What exactly should I test?
  • How should tests be structured and named?

The name test-driven development also caused confusion. How can you test something that’s not there yet? – From test-driven development to Behavior-driven development by Clemens Helm

9 Fallacies of Java Performance

Java performance has the reputation of being something of a Dark Art. Partly this is due to the sophistication of the platform, which makes it hard to reason about in many cases. However, there has historically also been a trend for Java performance techniques to consist of a body of folk wisdom rather than applied statistics and empirical reasoning. In this article, I hope to address some of the most egregious of these technical fairytales.

1. Java is slow

Of all the most outdated Java Performance fallacies, this is probably the most glaringly obvious.

Sure, back in the 90s and very early 2000s, Java could be slow at times.

However we have had over 10 years of improvements in virtual machine and JIT technology since thenand Java’s overall performance is now screamingly fast.

In six separate web performance benchmarks, Java frameworks took 22 out of the 24 top-four positions.

The JVM’s use of profiling to only optimize the commonly-used codepaths, but to optimize those heavily has paid off. JIT-compiled Java code is now as fast as C++ in a large (and growing) number of cases.

Despite this, the perception of Java as a slow platform persists, perhaps due to a negative historical bias from people who had experiences with early versions of the Java platform.

We suggest remaining objective and assessing up-to-date performance results before jumping to conclusions. – 9 Fallacies of Java Performance by Ben Evans

Expanded HTTP Method Support

HTTP and its secure variant, HTTPS, are the protocols used by every web client to talk to web applications. A key part of the protocol is the HTTP method. Traditionally, web applications used a very limited set of HTTP methods. It is common for application servers, proxies and routers (such as the Heroku HTTP router) to prevent unknown methods from being used. This unnecessary constraint of the Heroku HTTP router has increasingly become a limitation to developers building modern web applications.

In the past, if you tried to use an unsupported HTTP method in your Heroku application, clients would receive a 405 METHOD_NOT_ALLOWED error.

As of today, that’s no longer the case. The Heroku routers now accept any HTTP method, allowing you to use newer methods that have recently gained adoption, such as PATCH.

Why is this important?

Many new web frameworks use recently introduced HTTP methods such as PATCH or even custom methods that are not yet standardized. Ruby on Rails is one such framework. Rails has constantly evolved since its birth to always incorporate the latest development techniques. One such evolution is happening in Rails 4 where the framework uses the PATCH HTTP method to perform partial updates of resources.

Before Heroku removed restrictions on HTTP method, it was not possible to leverage this new functionality in Rails 4. Now that any method is supported, you can take full advantage of PATCH support in Rails 4. – Expanded HTTP Method Support by Blake Gentry

How to Validate for Matching Parentheses

In an interview the other day, the follow problem was posed to me: Write a method which validates a string if all the opening parentheses match the closing ones. For an invalid string, the method will return false. For a valid string, it will return true.

The method should behave as follows:

1
2
3
4
validate("(((hello))")  # => false
validate("((")          # => false
validate(")(")          # => false
validate("(())")        # => true

After attempting a solution using a boolean value, I settled on a simple tally variable. Whenever an opening paren appears, the method increments the tally. When a closing paren appears, the method decrements the tally. Finally, it is just a matter of returning true or false depending on the final value of the tally. – How to Validate for Matching Parentheses by Eno Compton