Why the hype?

We, at Webreakstuff, just gave birth to our youngest baby: TotSpot (yeah, pun intended).

TotSpot is a publishing platform designed to make it easier to parents to organize and share their tot’s life. Dads and moms of the world can write up journal entries about the toddler’s day-to-day life, upload pictures, link to videos on YouTube and Vimeo and document “firsts” as well as “favorites”. You know, kids’ stuff.

It was built on Ruby on Rails and uses MySQL. On the presentation layer, we use Yahoo!’s User Interface Library on a couple of things including the grids CSS and the little calendar widget for date picking.

Don’t take this for granted, but I think sometime soon we may end up writing a couple of technical posts either on TotSpot’s blog or wherever else about decisions we took or problems/solutions we found while working on TotSpot. Stay tuned.

Oh, and if you happen to have a baby, give it a spin.

this is a portuguese post about a portuguese event, the usual english babbling will be back in a bit

Há quase duas semanas, lançámos uma formação em Rails para o público em geral.
Para quem queira aprender a trabalhar com esta framework é uma óptima oportunidade. Para quem já sabe Ruby/Rails, o 3º dia pode ser interessante ao nível do deployment, scaling e outros tópicos avançados.

A formação será nos dias 19, 20 e 21 de Maio em Coimbra, no Hotel Tryp.

Há descontos para estudantes ou para quem queira comparecer nos 3 dias. Mais informações no site do evento: http://training.webreakstuff.com/

Bruno wrote an interesting post about integrating an application’s error logging with ticketing system you can turn bugs (that raise Exceptions) on your application into tickets ready to be taken care of by your developers.

About two years ago, I built an error logging system for a Ruby on Rails application we were developing back then. As pretty much everything in Ruby/Rails, it was really easy to do. I just needed to overwrite the log_error method in the ApplicationController catching every Exception and logging them to the database.

Once you have this setup, you can do whatever you want/need with your errors. You can send an email, write to a file…
Or… Post them as tickets to your favorite ticketing system using its API and thus keeping track of problems on your applications.

Although, there are a couple of small caveats that you should be aware of. One problem might arise if you’re getting very common yet harmless errors. An example: in a Rails app, you’ll get lots of RoutingErrors (everyone mistypes URLs every once in a while) but it doesn’t mean that something is wrong. In order to take care of this you can ignore them by creating a filter that either catches or ignores some Exceptions based on the type. Another problem could be duplication: the system should be able to filter out reports about the same error verifying that before submitting a new ticket.

Looking further at this approach, this can get to deeper levels of customization like mapping Errors of specific types into tickets with different levels of severity or automatically assigning a ticket originated on a given part of the application to the developer in charge, etc.

If you have any ideas about this subject, do leave a comment. I’ll get back to this issue soon exploring the Rails side and suggesting a solution.