Sami Wagiaalla's Blog

This is the first episode of the “Usability Rant” series, in which I complain about certain usability (or rather lack there of) features in software.

In todays episode I would like to talk about the next page button you find in websites with any sort of list. Can anyone tell me why the next button is needed ? Why cant all the items be listed on one page ? Then I dont have to torture my self trying to aim for the ‘next’ link and I can just can the entire content in one scroll. More importantly I can search using the find widget in my firefox browser (by the way; great feature!).

I understand that there might be a reason, that I am not aware of, which prevents people form listing 5000 items on one page. In that case instead of showing them in 100 item groups over 500 pages just have a link that shows the first hundred then explain to the user that there is more and that he/she can click on the show all button.

And that was our show for tonight… till next time!

In a previous post I talked about Observers, and pretended everyone knew what I was talking about . This post will go into a little more detail about Observers.

The Frysk Monitor, as I mentioned in the previous post, is indented to provide a live modeling of processes on the system. The time lines in the monitor display events, these events are fed into the Monitor by Observers.

Observers are triggered by the Frysk core at interesting points during the execution of a process. The Signal Observer for example, is triggered when the traced process receives a signal. When the Frysk core realizes the process received a signal it stops the process notifies observers, the monitor plots a nice blue tick, then if there are no other requests the signal is delivered and the process is resumed. This way your program continues to run and you can monitor its execution.

When you download Frysk there is a small set of observers provided. These include Syscall Observer, Signal Observer, Clone Observer, and Fork Observer. As the Frysk core gets more robust and complete there is virtually no limit to what observers the Frysk developers and users can create: FunctionFooCalledObserver, LibraryXLoadedObserver, NullPointerExceptionObserver? You get the idea.

The Current UI provides a way to do simple customizations of these Observers, by adding filters, and actions to them. For more complex events it is possible to write these observers in Java, and theoretically any other language that can be interfaced with Java.

Developers already do something similar with print statement debugging. The Frysk Monitor builds on that inspiration: it stream lines the process, eliminates the recursive debugging process (insert printf, compile, rerun), and provides visualization that takes into consideration threads, and multiple processes.

I envision people releasing Observers that are useful to their software. an example for Frysk would be a set of observers which monitor the different state transitions within the process/task state machines in the Frysk core.

For a future post I will create a relevant observer, and blog about the process and the results, and fix the bugs I find in the way .

One of the early strategies we took in Frysk is converting all our work items to bugs, and its turning out to be a very nice system.

Here is an overview:

In the frysk bugzilla there are Tracker Bugs these bugs are generic things that represent the larger components of Frysk. Examples are Build System, Event Viewer, etc. These bugs are listed as blockers for bugs that relate to these components. This is very useful for managerial purposes, but it also allows you to answer questions like why cant I currently use component X ? Or I am interested in contributing to the Frysk Source Window where do I start ? .

When a task comes up a bug is filed. I file bugs against my self instead of writing down notes. And I have in my browser two buttons set up that are short cuts to Bugzilla queries. One is called “My Bug List”, and the other “My Assigned Bugs”. When I am currently working on something I assign the bug to myself and it ends up in “My Assigned Bugs” list, otherwise if I plan to work on it some day i cc myself so that it ends up in “My Bug List”.

I am subscribed to the frysk-bugzilla mailing list (subscribe here) so I see all the bugs that are filed and I can tag them if I am interested in them, and keep track of the project as a whole.

I find bugs a much better place to discuss things, they keep the discussion archived and in context. I like to keep the mailing list for bigger issues. One problem with using Bugzilla to keep track of Frysk is that it is too zoomed in a view; and while that is good for me it might not be so good for someone new to the project or who doesn’t have time to read the high traffic bugzilla list. One way to solve that is to be more proactive about sending bigger items to the Frysk mailing list, or maybe adding comments to the tracker bugs.

Any thoughts ?

Hi, my name is Sami and I am a Red Hatter.

I first joined Red Hat as an intern in May 2005. Back then the Frysk project was just starting up. It wasn’t even called Frysk in fact. I worked on various parts of Frysk until the end of my internship in August 2006. I then returned to one semester of school, and joined Red Hat to work full time on Frysk in January 2007.

Ever since my return from the dead I have been meaning to start a blog to talk shop about Frysk and other Open Source matters. Phil Muldoon hocked me up with a blog, and I am finally making a blog post.

Since January I have worked on the Frysk Monitor. The mission statement of the monitor -at least as I see it – is to provide a high level modeling (or abstraction) of running programs. This bird’s eye view is meant to enable the user to monitor, and catch problems in large scale multi-threaded programs. The Frysk Monitor is also to enable the user to dig in deeper and zoom in on the source of the problem where possible.

Here is a screen shot of Frysk monitoring nautilus on my system:

When I first run Frysk on nautilus, it is one process with one thread. I then go to my desktop and double click on a folder, the folder opens up and the monitor screen in Frysk is updated.

As you can see from the above screen shot the main thread spawned a second thread which probably handled the opening of the folder then died as you can see by the terminating event. Ticks which have the gray lines next to them represent events during which a stack trace was captured. You can click on that event to see view the stack trace.

The above process has four observers watching it. Two terminating observers, and two clone observers. One terminating observer captures a stack trace and one doesn’t. Same for the clone observer. I realize this is confusing for the user, so I have to come up with a way of consolidating this info .

This was just a brief preview. More detailed blogs are to come . Meanwhile, if you are interested in learning more about the project, providing input and suggestions, and contributing , we hang out in #frysk on irc.gimp.net.