imedo Development Blog

As requested here is the presentation for our awesome email plugin:

Slides

Popularity: 1% [?]

I want to say a few things about a I read lately, called Design Patterns in Ruby.

In this book, Russ Olsen discusses 14 out of the original 23 design patterns described by the GoF. In addition he also talks about 3 not unique but very common patterns in Ruby. Alongside he gives a very nice overview of Ruby for the Ruby beginner and shows some sweet little tricks.

I find the book very comprehensive with the special paragraphs of when to not use a certain pattern, which is really helpful to not get overly enthusiastic with a pattern and try to use it everywhere. Design Patterns are after all solutions that you should use when you found a fitting problem and not when you made a problem fit.

Eventually I created a presentation with a short (not so short, actually) overview of the patterns for my colleagues which I want to share with all of you here.

The presentation on video:

Online Videos by Veoh.com

The slides:

Special Thanks

to Jonathan Weiss, who’s introduction and review pointed me to this book.

Popularity: 1% [?]

Recently, I held a presentation about the background plugin, at the Ruby User Group Berlin. The presentation was very well received, and the effect was that our watchlist on github got a boost.

Anyways, here is the presentation. Enjoy.

Popularity: 1% [?]

Welcome to the first part of our blog series about optimizing rails views. This part is about remove white space.

Introduction

In order to save bandwidth, imedo.de packages it’s rails views on deploy. This is accomplished with a simple rake task, that parses every erb file and removes unneccessary white space. But what is unneccessary white space? First of all, unless we’re in a pre tag, subsequent white space characters are displayed as one character in HTML (for the sake of simplicity, we will ignore pre tags for now). As it turns out, unneccessary single white space characters are hard to distinguish from neccessary single white space characters. Consider the following example (for clarity, the white space character is displayed as an under score, and the new line character is displayed as a question mark):

<a_href="/some/url">Some_url</a>_|?
<a_href="/another/url">Another_url</a>

Rendered in HTML, this code looks like the folloing

Some url |
Another url

Packaging this code simply by removing newlines, for instance, breaks the layout:

<a_href="/some/url">Some_url</a>_|<a_href="/another/url">Another_url</a>

Some url |Another url

Note that the pipe symbol is now attached to the second link, which is not the intended result.

An obvious solution to this problem is to convert every white space character to a regular space character, and then remove duplicates. But this does not yield optimal results, as can be seen in this example:

<ul>?
__<li>?
____<a_href="/some/url">Some_url</a>?
__</li>?
__<li>?
____<a_href="/another/url">Another_url</a>?
__</li>?
</ul>?

Which, compressed by the above algorithm, leads to the following markup:

<ul>_<li>_<a_href="/some/url">Some_url</a>_</li>_<li>_<a_href="/another/url">Another_url</a>_</li>_</ul>_

whereas the optimal solution in this particular example would be to remove any white space characters between tags:

<ul><li><a_href="/some/url">Some_url</a></li><li><a_href="/another/url">Another_url</a></li></ul>

Note that it is not sufficient to remove all white-space-only text nodes in the DOM tree.

Aggressive Packaging

As we said above, it’s hard to detect neccessary white space. neccessary white space depends on so many factors, that not even all browsers get it right. That’s why we don’t even bother trying. So the simple rule is:

Don’t depend on new lines and indentation showing up as space.

(See the section Conservative Packaging of this article, if you can’t follow this rule). This is a bad practice, anyway. A visible space between words should be treated as a first-class HTML citizen, and should not be the result of some random code beautification things, like line breaks or indentation. Actually, as I packaged all of our view files (about 2000 or so) for the first time, there were only a handful of places where we depended on indentation or new lines showing up as spaces. To get rid of these implicit whitespace dependencies is easy, particularly if you use Globalize (an internationalization plugin, that forces you to write any text as an erb tag) for every user-visible hardcoded string. Just make sure, that you don’t have a word as the last token in a line, with the next word as the first token in the following line. So, this is bad practice:

<p>This is
bad practice.</p>
<p>There is the
<em>next</em> paragraph.</p>

while this is good practice:

<p>This is good practice</p>
<p>There is the <em>next</em> paragraph.</p>

With this complication eliminated, it turned out to be very simple to compress the partials. ERB comes packaged with a lexer class called ERB::Compiler::TrimScanner that splits an erb view into small pieces, in a way that is perfect for this task. One small thing to note is that we don’t want to remove any white space characters inside erb tags (<%= ... %>), since white space, especially the newline character, sometimes matters in Ruby.

So, the code to compress a view file is as short as this:

# Weird TrimScanner bug: Lines consisting only of %> (without whitespace) are lexed as >
content = File.read(file).split("\n").collect { |line| line == '%>' ? ' %>' : line }.join("\n")
scanner = ERB::Compiler::TrimScanner.new(content, '>', true)
array = []
scanner.scan { |x| array << x }

inside = false # true, if we are inside an erb tag
# remove whitespace
content = array.collect do |e|
  if e =~ /<%/
    inside = true
  elsif e =~ /%>/
    inside = false
  end
  if e.is_a?(Symbol) || e.is_a?(ERB::Compiler::PercentLine)
    nil
  elsif inside
    e
  else
    e.strip.gsub(/\s+/, ' ')
  end
end.join

File.open(file, 'w') {|file| file.print content}

This very aggressive white space removal works for us, because we have

• no inline Javascript, that might depend on consecutive spaces.
• no actual text written in the views, but strings that are translated with Globalize on the fly (so there is no new line in the middle of a text that might glue words together).
• every user-visible text embedded in a paragraph or span tag.
• the closing tag of a DOM element containing text (i.e. where whitespace matters) on the same line as the opening text.

That being said, we still have to disable white space removal in certain instances, like text/plain emails.

Conservative Packaging

For those of you who do depend on newlines as white space, just remove the strip call in line ? of the code snippet above. The compression will not be optimal, but better than no compression at all.

Disclaimer

Important: If you try any of the view optimizing techniques, please make sure that you have a quick and painless way to revert the changes, because files are rewritten with optimized content. We are not responsible for any damage that any of the code may have caused.

Download and installation

• Download the view transformer plugin here.
• Install it by copying the plugin in your vendor/plugins folder.

Configuration

To configure the view translator, modify the file view_transformer.yml.

Popularity: 1% [?]