The brave new world revisited: How to take care of the multiple aspects of your life

With the recent changes on my life, I’ve been asking myself this question: How can I balance the multiple objectives of my life? How to divide my time appropriately between professional, parental, affective, spiritual matters and subjects? How to handle my finances and health with high standards?

The interesting thing is that I remember this being a concern in my life since childhood days. On the very beginning, the tendency was to freak out. Obviously, with time you clearly realize that this won’t help much. Since then, things has gotten a lot better. I’m more productive nowadays, but, of course, I still feel that I could do a lot better. By learning to relax and stop seeing the little problems as unsolvable things, and by realizing that most people have the same problems, you can freak out less and do more.

That’s pretty much what methodologies such as Getting Things Done try to address: By taking out stuff from your mind and putting it on a consistent and constantly revised system, you take out the anxiety, allowing you to focus better your energies. I want to learn more about all this stuff, but the concepts are pretty simple. The biggest thing is, of course, the commitment you make to apply those simple concepts on your life. Just reading and talking about that stuff will definitely get you to nowhere.

As they say on the free software world, ‘Talk is cheap, show me the code’. Enough with the talking. Let’s go to the code.



This Sunday myself and my good friend Glauber watched the 80’s masterpiece known as Rambo: First Blood Part II. Explosions, kills, blood, to summarize, everything that makes up for a great movie 😀

If you don't find them, I'll find <b>you</b>

From all the lines, the best one isn’t even spoken by master Stallone:

Co Bao: (touches her necklace) This brings me luck. What brings you luck?
Rambo: (raises his small and delicate militar knife)

I agree with Glauber :), nothing can beat 80’s movies 🙂

Integrating autotest with trac testcase management plugin

During the holiday we had here in Brazil I’ve spent some time working on integrating my autotest control files with our trac testcase management plugin. For those that don’t know, we hacked the Trac testcase management plugin [1] to suit our needs, and developed some macros that generate proper test bucket [2] state reports. The plugin can generate the test buckets and neat tables, summary tables and plugins. Every test is mapped to a trac ticket.

Now, if we could integrate our autotest control files to automagically update the test tickets on the event of a pass of failure, that’d be great, isn’t it? Yep. And that’s possible since trac has an xmlrpc server. Python, with its ‘batteries included’ philosophy includes the xmlrpclib module, that allows us to interact with an xmlrpc server. First, you need to install the Trac XMLRPC plugin, and the plugin page is an excellent source on how to install it [3].

After the trac instance is restarted, test if everything is working by doing some tests using the interactive python prompt (I definitely recommend using the ipython python shell). Let’s suppose that the trac instance is running on The xmlrpc server URL that you’ll have to build looks like:

So you could build that URL and connect to the server as follows:

import xmlrpclib
trac_user = "trac_user"
trac_password = "trac_password"
trac_rpc_root = ""
trac_url = 'http://%s:%s@%s' % (trac_user, trac_password, trac_rpc_root)
trac = xmlrpclib.ServerProxy(trac_url)

At this point we already have a server connection object stablished on trac, so we just need to call remote methods as methods of this connection object. You can get a complete list of methods accessible from this server connection looking at the XMLRPC plugin page. To make sure this connection is working you can call the method, that requires the ticket number. So, assuming that you’ve provided a valid ticket number to it, you’ll get the fields of your ticket on a list that contains a dictionary with the ticket values, like:

In [12]: trac.ticket.get(100)
 {'cc': '',
  'component': 'Distro',
  'description': "''''''Test Details:''''''\n\nA highly configurable stress test utility that calls most of the main file system syscalls. Originally developed by SGI for XFS testing.\n\n''''''Expected result:'''''' \n\n0 as return code",
  'keywords': '',
  'machine_name': 'lpar_name',
  'machine_type': 'HV8',
  'milestone': 'DummyDistro',
  'owner': '',
  'priority': 'major',
  'reporter': '',
  'resolution': 'fixed',
  'status': 'closed',
  'summary': 'TestID: fsstress -- HV8',
  'testcase_bugzilla': '',
  'testcase_result': 'Pass',
  'type': 'testcase'}]

If calling this method works as described, we should be good to go. As one may guess, the method that updates the tickets is ticket.update, as follows:

array ticket.update(int id, string comment, struct attributes={}, boolean notify=False)
  Update a ticket, returning the new ticket in the same form as getTicket().

So you have to pass the ticket id, a string comment (that might for example contain an URL to the test logs), a dictionary with the new ticket fields (for the fields that will be updated). Now, to the autotest control file.

An autotest control file contains fragments of python code, but it can grow to something quite elaborate. The main interface from running tests on a control file is the method job.run_test, a simple autotest control file would be something like:


The job.run_test() method takes a ‘test name’ as its argument, and returns True if the test passes, False when it fails, so the logic to implement trac reporting is very straightforward:

ticket = 150
message = "[ Sleeptest log]"
if job.run_test('sleeptest'):
	trac.ticket.update(ticket, message, \
		{'status': 'closed', 'resolution': 'fixed', \
		'testcase_result': 'Pass'})
	trac.ticket.update(ticket, message, \
		{'status': '', 'resolution': '', \
		'testcase_result': 'Fail'})

This way, when the test passes, it will close it and mark it as pass with no intervention, when it fails it only marks it as failed, leaving it open so the test engineer can analyze the failure and came up with a conclusion/bug report.

It was a fun holiday indeed 🙂

[1] We plan on integrating those modifications to the plugin, of course.
[2] By test bucket we mean the sequence of testcases that have to be performed for a single project, let’s say, distro testing.
[3] It’s packaged as a python egg, that could be installed using easy_install or unpacking it and dropping it to your python site_packages directory


On Thursday (05/01) we had a holiday, labor day here in Brazil. Even though that might be a controversial position, I think we have way too much holidays over here. Our country’s economy would do better if we had less holidays. I mean, there’s no need for that much additional opportunities to rest 🙂

Since there was not much to do about it, I worked a little, then a good old friend of mine came here to visit me. We had a good lunch, then we went to a large mall here in Campinas, spent some time talking about life, the universe and everything, all this with a little girl (my daughter Victoria) jumping and laughing all over the place 🙂

I guess I spend way too much time thinking about life, the universe and everything… It came to my mind that our life nowadays is complex, and we have to deal with several tasks and handle several sources of information at once… it’s pretty stressing. But, in the end, we just want to do something useful with our lives, and in the (large) amount of time we’re not carrying out our life duties, we just want to… enjoy ourselves, having friends to share all the choices and small moments of life.

And the most interesting thing is that the answer for all this is 42 🙂