Flexblog aka Flex Block

Bits and pieces about free software and various other things.

Thursday, September 22, 2011

Introducing Gigger, a Realtime Javascript Monitoring Framework

(originally posted here)


Monitoring your web application is essential for professional maintenance and development. Especially if you have a high load on your website and you want to keep the current users on your site, you definitely should stay alert for problems and be able to react fast in case of problems. Monitoring is also crucial for A/B tests, since you have to evaluate somehow which version of your website performs better. Many big players also measure constantly how much revenue the website produces. For them it is important to monitor if a new feature increases or decreases the revenue and take decisions based on that information.


Mayflower is currently developing a javascript framework which provides a smart tool for realtime monitoring and measuring. Read the full article for more information.

Monitoring your web application is essential for professional maintenance and development. Especially if you have a high load on your website and you want to keep the current users on your site, you definitely should stay alert for problems and be able to react fast in case of problems. Monitoring is also crucial for A/B tests, since you have to evaluate somehow which version of your website performs better. Many big players also measure constantly how much revenue the website produces. For them it is important to monitor if a new feature increases or decreases the revenue and take decisions based on that information.


The time it takes to get your monitoring results is crucial for many web applications. If reports reach you after one hour or even a day, its almost impossible to react on potential problems in time. Gigger allows you to monitor your web application in realtime. Everything you want to track in the web application is transmitted to the monitor in realtime where it can be processed and visualized.


Most of current monitoring solutions focus on page loads and backend monitoring, but times change: Nowadays more and more web applications are single page websites. This makes the old approach difficult, since the only page load happens in the beginning, afterwards everything is loaded dynamically. Gigger solves this and brings the monitoring task to the javascript and thus to the browser. It allows you to monitor what is going on in the browser that runs the web application. Using gigger you can monitor the web application closely and find out about potential problems users run into.


From a technical point of view, gigger uses Faye to establish a publish/subscribe connection between the browsers where the web application runs and the monitor (which also runs in the browser). With gigger you can specify in the monitor, what should be monitored. The monitor transmits the requests to the web application and the web application hooks into the desired events and notifies the monitor when something happened. Since this approach is not perfect and only allows you to monitor simple things (DOM events), gigger also has an API on the web application side to manually emit signals. This requires some synchronization between the monitor and the web application, it only makes sense if the monitor is listening on the right channels where the web application emits its custom signal. Through this API you have the full flexibility to measure and monitor whatever you want. You could for example measure how long it takes for your ajax requests to return and calculate a mean ajax request time from a browser point of view.


We currently have a monitor running, which monitors simple events on blog.mayflower.de, you can find the monitor on gigger.mayflower.de/monitor.html. We are currently measuring how many hits the blog gets every minute and which topics are hot. There is also a log view which shows a new entry when someone hits the page and also when someone clicks on a link.



DISCLAIMER: It's pre alpha! Don't expect it to be perfect. The project is in a very early stage, this is the first live test and it could happen that there are some problems with the service. It was tested with Firefox and Chrome.

Thursday, September 1, 2011

Google+ Advice

Small advice for all the google+ users out there:

DONT MESS WITH YOUR CONTACTS IN GMAIL-->OTHER CONTACTS

I did and afterwards all my google+ circles were empty!

Wednesday, August 31, 2011

Feature Branch vs Mainline Development

Today our CTO at Mayflower pointed me towards Martin Fowlers great article on feature branch development. Since my work with GNOME I was convinced that feature branch development is the way to go, much better than mainline development where every developer is working on the same code.

Some historic background (from my point of view):
Back in the days of svn, mainline development was the most feasible way of writing code in a (distributed) team. Branching (and merging) was not so easy and often made things worse. Working on the mainline was a real pain in the ass: you don't want to commit stuff that could break the build, so your commit grows and grows until all the bits and pieces are there to fully increment the code and reach a buildable state including your feature.

With git many teams switched to a feature branch development, where every feature got its own branch, where you can commit often and early (since it only breaks your local build and does not affect others) and where you merge the branch once the feature is ready to release.

Martin Fowlers article made me realize that feature branch development has its downsides as well. If you work with a bunch of colleagues on one product and you work on that product 8h a day, merge conflicts will be quite common. When you have a branch and work on it for a couple of days, the merge becomes a bigger risk with every minute. But since I cannot tell the story as good as Martin Fowler, read his article.

Monday, August 8, 2011

Desktop Summit 2011 Berlin, Aftermath

I am sad to leave already, but tomorrow I'll start my internship at the Mayflower office in Munich. I had a really good time in Berlin and enjoyed the talks at the Desktop Summit.

(more pictures will follow soon on googles picasa)

I would like to thank the organizers for doing such a great job. Thanks also to the GNOME Foundation for the sponsorship that allowed me to attend the summit.


If anyone that has not attended the summit wants to look through some of the video recordings, but does not know which ones to choose, I've prepared a list of talks that I liked the most. Videos should be online soon.

Saturday, July 23, 2011

Desktop Summit Berlin



Yes, I am going to Berlin! I would like to thank the Gnome Foundation for supporting me financially.



I will be in Berlin from 08/01/11 until 08/08/11. See you there!

Thursday, March 31, 2011

Telepathy Support for Gedit-Collaboration

During the last months I was working on telepathy support for gedit-collaboration, a gedit plugin. The plugin allows you to work collaboratively on files via an infinote server. The idea of giving it support for telepathy was to get rid of the extra infrastructure needed (infinote server) and collaborate directly with your buddies over XMPP.

The branch is not finished yet but its functional. Thus I am looking for volunteers to test it and to give me feedback. Since I'm not a UI expert (more a UI non-expert), I really need some good ideas for the UI part, which right now follows the way gedit-collaboration handles infinote servers. That approach is not really intuitive for direct collaboration. So if you have an idea, please don't hesitate.



You can find the branch with my work here: http://git.collabora.co.uk/?p=user/kaserf/gedit-collaboration.git;a=shortlog;h=refs/heads/add-telepathy-support

I also opened a bug to collect all the feedback and ideas: https://bugzilla.gnome.org/show_bug.cgi?id=646312




A big thanks to Collabora Ltd. for sponsoring this work, to Jesse van den Kieboom (gedit-collaboration maintainer) and Armin Burgmeier (Infinote maintainer)

Tuesday, December 21, 2010

Folks and its backends

Listen up people, Raul Gutierrez Segales (rgs) wrote a new backend for libfolks. His backend handles read access to the Evolution Data Server (EDS) which means folks knows about the contacts you have in your evolution address books.

In Rauls blog post you can read that there is also a libsocialweb backend for folks, written by Marco Barisione. The libsocialweb backend allows you to get your contacts from facebook and twitter (and potentially many other social websites and services).

This is awesome work which brings us one step closer to a cleaner contacts future. Rock on folks....

Blog Archive


View My Stats