This post might be interesting for all people who are faced with strange problems like this: “Yesterday it worked. Now it’s broken” or “It works on my machine (and it does not in production)”.

I’m sure that all Programmers and sysadmins have had an incident like this in their lives. I’ve had a lot of these problems and found out that in the end there’s always an explaination for the problem. Very rarley it’s some quantum mechaincs effect that caused the problem. In most cases there is a really simple explaination for the problem even if it was hard to find. These things include “the cause of a crashing perl script is the java version of the app starting the script”, “failing tests that where caused by a minor version difference of a testing library where the error message lead to something completely different”

The process described below was used in all cases to find the root cause of the problem which then was solved very easily. We weren’t aware that we used this process but rather did it intuitively. After talking about the process and writing it down, we were able to find more and more problems by following these steps and also to transfer the knowledge to other people so that they will build up the intuition to find root causes of problems as well.

General idea

Systems that work and system that don’t work differ.

If you make the not working system equal to the working system, it will work.

That’s all there is to Troubleshooting (basically).

Process to find out the difference

The hard part is to find out where the working and not working systems differ.

The general process is really simple though:

1. List all items that can differ
2. Check if they differ
3. Make them equal (one at a time!)
4. Repeat 3 until finished. If still broken, think harder about 1 and start again

The optimized version of this is, to start with the things that are most likely to cause the problem.

The term “most likely” is based on

• your own experience
• information found in the web: blog posts, google searches, etc.
• experiences of your co-workers

It is fundamental that you make each step conciously (writing the step/change down helps to do that). If one step doesn’t yield the desired outcome: revert it immediately. Again: having written it done helps not to forget anything. Forgetting steps may make the situation even worse.

How can systems differ?

The main questions are:

• What changed since it worked (if it is the same system)?
• What is different or changed on the not working system compared to the working system (if it is a different system)?

The latter is a lot easier because you something to compare to. In the former case you have to create the “working system” again. Which in itself may be the solution to the problem.

If the answer is “nothing”. Think again…! Because time has progressed. So at least the time changed.

Possible effects of changed time

• File system full
• weird time dependend behavior of applications
• system/application restart occured
• data changes happend

Other things that may have changed:

• software versions through package updates – Minor Changes are important!
  • OS Kernel
  • OS packages
  • application libraries (ruby gems, jars))
• Database schemas
• Database content
• Filesystem content of any kind (That includes timestamps of a file that is only read!)
  • Location of files
  • symlink vs. real files
  • timestamps
• Hardware
• Increased load
  • Network I/O
  • Disk I/O
  • CPU
  • Exceeded RAM -> Swapping

Some things will be straightforward and it is obvious why something brakes something else. Some things are not as obvious (at least not at the time when you try to find it – it’s always obvious afterwards!). Don’t jump to conclusions about cause and effect while you debug. If you think “I’ll don’t try X because X has nothing to do with Y” try X! Maybe it has something to do with Y. You don’t know before you try. Revert (or create the equal state to the working system for) the “most obvious” things that “can’t possibly interfere with the problem”. That includes

• Comments in Source or Configuration files
• Whitespaces
• Trivial Code/Configuration changes
• minor version changes in Packages

The “most likley” rule does apply here, too. Don’t start with whitespace if there are other not so subtle changes still different. Don’t look for access time timestamps if the files on one system are are in completely different locations compared to on the other system. This requires some experience but with time you’ll find which things to look for first.

Tools

• Filesystem-Analysis: df, ls, find,
• Application-Behavior: strace (dtruss on Solaris and Mac OS), lsof, netstat
• Databases: For mysql: mysql, innotop
• Packages: Debian: apt-get, dpkg
• Finding differences/problem causes in running vs. not running code: Binary Search (e.g. via git bisect, debugger or just plain “print”-Debugging).

We hope these thoughts help you to debug and troubleshoot strange problems. Feel free to post additions, comments, tool or experiences with troubleshooting.

Popularity: 1% [?]

Wir wollen, dass die Ladezeit von imedo.de so gering wie möglich ist, damit unsere Besucher nicht ewig auf den Aufbau der Seite warten müssen und gefrustet auf den “Zurück”-Button einhämmern.

Welche Bildformate gibt es für Webseiten?

GIF:
verlustfreies Format, bis zu 256 Farben, eine transparente Farbe möglich, unterstützt Animation

Wann verwenden?
Eigentlich nur bei sehr kleinen Grafiken mit wenig Farben oder wenn eine Animation sein muss. Ansonsten sollte man PNG-8 verwenden.

Daumenregel:
Wenn eine Grafik (keine Fotos) kleiner als 20×20 Pixel ist, keine Verläufe hat und mit weniger als 16 Farben auskommt, ist Gif eine gute Wahl. Kleinere Animationen sind ausser mit Flash nur mit Gif möglich. Je weniger Farben, desto kleiner wird die Datei.

PNG-8:
verlustfreies Format, bis zu 256 Farben, unterstützt echte Alphatransparenz, also Übergänge von transparent nach nicht transparent sind in unterschiedlichen Stufen möglich, keine Animationen

Wann verwenden?
Eigentlich genau wie Gif, aber PNG-8 ist zu bevorzugen wenn man gröere Grafiken mit mehr als 16 Farben hat und echte Alphatransparenz verwenden will. Vorsicht ist geboten bei Internet Explorerer und einigen anderen Browsern, weil die Transparenz manchmal falsch interpretiert werden und das Resultat nicht besonders schön aussieht. Ist dies der Fall, sollte man auf Gif ausweichen.

Daumenregel:
Bevorzugtes Format für Grafiken mit bis zu 256 Farben, wenn Transparenz benötigt wird. Fallback auf Gif falls es Probleme gibt. Je weniger Farben, desto kleiner wird die Datei.

JPG/JPEG
verlustreiches Format für Fotos mit sehr starker Kompression, mehr als 256 Farben, keine Transparenz, keine Animationen

Wann verwenden?
Bei Fotos.

Daumenregel:
Alles was keine Grafik ist (z.B. ein Chart mit wenigen Farben) ist ein Kandidat für JPG. Alle Fotos die ihr mit einer Digicam aufnehmt haben normalerweise dieses Format.
Beim abspeichern kann man normalerweise die Qualitätsstufe von 0 – 100 einstellen. Normalerweise sollten 75 reichen, aber wenn es ein Portrait einer Person ist kann man auch mal bis 90 hochgehen.
Umso geringer die Qualität ist, desto kleiner wird die Datei.

Und jetzt? Was nehm ich nun?
Grafiken: PNG-8 oder GIF
Fotos: JPG

Dateigrößen:
PNG-8 und Gif: je weniger Farben, desto kleiner die Dateigröße
JPG: je geringer die Qualität, desto kleiner die Dateigröße

Gibts noch was zu beachten?
Ja! Die Ausmaße der Bilder (Höhe, Breite) die ihr verwendet haben eine enorme Auswirkung auf die Dateigröße. Deswegen Überlegt Euch wie groß das Bild sein soll, bevor ihr es hochladet. Skalierung von Bildern in Browsern verschwendet Bandbreite und sieht unter Umständen (IE *hust*) schrecklich aus.

Und noch was
Die Auflösung im Internet beträgt 72dpi (Dots per Inch, also wieviel Pixel pro Fläche). Alles was darüber hinaus geht ist Verschwendung. Wenn ihr also irgendwo Bilder findet die eine höhere Auflöung haben als 72dpi dann rechnet diese um auf 72dpi.

Popularity: 1% [?]

We’re proud to announce that our talk proposal The big bang – what to do if your Rails codebase grows to big? was accepted by the Scotland on Rails organizers.

From what we’ve heard Scotland on Rails is a nice conference with and by interesting people. Maybe we see you there! Register now!

Popularity: 1% [?]

If you try to deploy your Rails app which is using Rails Engines with JRuby in an Java application server, you end up with errors on the first request. Basically JRuby is complaining that it cannot create directories. This is due to the fact that engines tries to copy over assets from the plugins into the public dir of the rails app.

In an application server the rails directory structure is “turned inside out” as Nick Sieger calls it. So the public directory is actually inside the base dir of the deployed app and the class files are in the WEB-INF dir.

You can easily fix that if you put the following code right after your engines require in your environment.rb (or inside an initializer file):

if Object.const_defined?("PUBLIC_ROOT")
  Engines.public_directory = PUBLIC_ROOT
end

PUBLIC_ROOT is defined inside JRuby (or warble) and set to the correct path by warble.

I found out about this behavouir in the Rails Tutorial Session Take the Jruby Challenge: Deploy Your Rails Application With JRuby and Taste the Difference with the helping hand of Nick Sieger

Popularity: 1% [?]

RailsConf Europe 2008

Session – Design for Usability

presented by Christian Lupp

In his talk at RubyConf Europe 2008 Christian Lupp showed a designers approach to solving problems. It my seem strange to have a designer give a talk in front of a developer crowd, but I think you will find, that we can learn a few things by observing other professions’ methodologies.

He told the audience that many great ideas have evolved on paper. You start out with rough sketches and prototypes. In this stage you basically create a landscape of your application and it should help you to understand what the problems are you want to solve. Once you’ve dont that, you redefine these prototypes iteratetively. Be confident to throw stuff away that isn’t working out and explore alternative solutions. Fail fast and early.

Hmm, this all sounds an aweful lot much like agile software development, doesn’t it?

He also mentioned that you should always take the context into account when constructing your application. Without thinking about the user’s perspective and his needs, may it be a human or a machine, it’s likely that you develop in the wrong direction.

If you have two equal solutions to a problem, take the simple solution. This is called the Occham’s razor Behold! Knowledge from the 14th century folks, but still true. In order to find the simplest solution, you reduce functionality until your application is missing something important, then you go one step back.

Then the talk got technical after all.

Christian asked why we as web developers should use techniques like unobstrusive javascript at all and listed some valid points. First, people using screenreaders will love you. Second, the marketing and SEO guys will love you. You improve the overall performance of your website and thus speed up the overall user experience on your website. Users don’t like to wait. If a page is snappy and responsive, they are more likely to come back.

Christian also shared some basic design tipps with us.

Repeat with DRY. Don’t show different elements on every page. Instead develop an overall graphical and UX concept. It doesn’t only make you site look more professional but will also help users to find their way around on your site. Usability equals recognizable patterns, so repeat yourself and use layout grids etc. that will help your users to understand the content of your site faster.

Another good tipp is to always validate user input immediately by javascript for example. Give your user feedback all the time and instantly, eventough the action he started may take longer. Be creative and entertain you user while he is waiting for search results. Instead of letting the user wait for the search to finish, you can show him an immediary screen which informs him that his search is beeing performed and could take a few moments to finish. You informed your user and in the backgorund your server is already working on finding relevant results for him. This pattern is already used by most forum software.

That was “Design for Usability”, a very interesting talk.

Popularity: 1% [?]

RailsConf Europe 2008

Tutorial – Accessible Ajax on Rails

presented by Jarkko Laine and Geoffrey Grosenbach

In this tutorial on tuesday Jarkko showed how to use unobstrusive Javascript techniques, in particular LowPro, to seperate javascript logic from content. His example of choice was a simple ToDo list with checkboxes. He started out by using the standard Rails helpers and the refactored the application to use unobstrusive javascript.

If you’ve never heard of unobstrusive Javascript before the first part was very interesting, because here he pointed out that inline scripts not only block the browser, but also clutter your html code with unneccessary output. It bloats your file and is not very DRY. Imagine you use standard Rails helpers in a list of checkboxes to do Ajax calls. The same code over and over again.

The next step was a introduction to LowPro by Dan Webb (Prototype Core Team member), which makes it easy to attach javascript logic to elements on a page by the Event.addBehavior method:

Event.addBehaviour({
  '#add_form' : RemoteForm({
    onComplete: doSomething here ...
  })
});

Here are some tips from Jarkko:

Be careful when using Event.addBehaviour.reassignAfterAjax = true;, because all your behavior code will run again after every Ajax request and potentially mess up your page. Instead apply behaviors inside the onComplete callback of the Ajax call like this: onComplete: function(){ Event.addBehaviour.reload(); }

He also suggested that instead of using too many classes to identify your behavior targets, you could use CSS3 selectors like "input[type=checkbox]" instead. The question here is if this performs better than classes on slow browsers like IE6.

All this ujs sounds pretty interesting, but you should use it wisely. For example if you need to apply a behavior to every cell in a large table. If you attach a behavior object to every single cell, it will not only eat a lot of memory, but will slow down the initialization of the page overall. If you add observers to each of these objects, the site will be sluggish. This is where Event.delegate comes in! Instead of applying the behavior to every single cell, you attach it on the table and let Event-propagation do the work for you.

LowPro comes in handy here, because it has this functionality built in through the Event.delegate method, which you can use like this:

Event.addBehaviour({
  'table:click':Event.delegate({
    'td':function(e){
      var targetElement = e.element();
    },
    'a':function(e){
      e.stop(); // stops the event from bubbling
    }
  })
});

Make sure you explicitly stop events from bubbling, because otherwise if a link inside a table cell is clicked, both actions will be executed. But there is a caveat to this method: unfortunately not all events bubble up. In particular ‘focus’ and ‘blur’, so be aware of this.

If you need to store state inside your behavior you can also attach custom objects to these elements, like you’ve seen it with RemoteForm in the first example. First you need the class:

var Hover = Behaviour.create(
 initialize: function(className){
   this.lassName = className || 'over';
 },
 onmouseover:function(){
   // this will be a event handler
 }
);

which will contain all your logic and observers.

Then you attach the Hover class to the DOM element like you’ve seen before:

Event.addBehaviour({
'.hover_thing':Hover
});


More on UJS will follow.

Popularity: 1% [?]

Neulich beim Coden:

Hendrik: Ich hab da ein Problem mit XYZ… Hast ‘ne Idee, woran es liegen könnte?

Thomas: Lies den Sourcecode! Ich mache es auch. Ich lese gerade ActiveRecord::Base

Hendrik: Und? Ist es spannend?

Thomas: Ja. Ich glaube es war der Gärtner.

Popularity: 1% [?]

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% [?]