Older blog entries for henrique (starting at number 14)

Definitely. I'm the right guy, at the wrong place, in the wrong time.

10 Jan 2009 (updated 10 Jan 2009 at 22:23 UTC) »

I'm moving to São Paulo this monday. The good thing is that I found a house near the office that I started working and it will take only 30 minutes to arrive there, walking.

The work is going fine, there were some initial problems, but finally there are nice people to work with and I got the tasks very easily.

Happy new year.

Not a good beginning I'd say, but at least I leave SigX. I'm going to work at Sao Paulo, I can't wait to start working there.

Lazy resource loading on pyglet (was: cocos2d importing too slow?)

As promissed in my last post, I opened the issue #367 at google code to fix the problem reported.

My first patch wasn't accepted, but I though that it would take this way, since the patch was very punk (it would introduce undesired backward incompability). The second patch was better, but I was not happy with it... it just relied on environment variables, what is a crappy thing.

The final fix by Mr. Holkner implemented lazy loading support... IMHO his implementation was not good, but the idea is very cool. The guys there seemed not so friendly, so I leave this detail apart.

By the way, I'm happy to have helped with something in this project.

20 Nov 2008 (updated 20 Nov 2008 at 01:40 UTC) »
cocos2d importing too slow?

So, you find cocos2d and think "man, I need to try it out!". Cool, so you went to your editor, open an usual "foo.py" and start typing some example...

import cocos
class HelloWorld(cocos.layer.Layer):
    def __init__(self):

followed by python foo.py; after some 2 minutes you got the result on the screen, but why is it too slow to start? The culprit is pyglet.

When cocos is imported, pyglet is imported as well. cocos will then try to append some resource directories to it and then the problem begins... pyglet will start indexing every file in the tree starting at ".", so if you are running this script at your home directory or inside a directory with a lot of files and directory (like a ~/dev directory as it is my case), it will add each file found in a dictionary.

The solution: Create a directory to put your code and run it there or wait for my bug report at code.google (out of time right now, but I will do it soon and let you know).

By the way, the homework is: what will happen if your game is at /usr/bin/my-ubergame and you start it in your home directory with, lets say, 15gb of mp3 and movies?

SuspiciousOperation on Django with FileField?

Just a quick tip. I was wondering why this error happens, but until I got the time to investigate it I just commented out the column on the model and moved on, but now (after a 5 minutes search at the django's code) I found the reason and I want to share it. The complete error message is:

Exception Type:	SuspiciousOperation
Exception Value:	
Attempted access to '/Users/henrique/tmp/uploads/half_logo.png' denied.

Suppose the project directory (where manage.py and its friends are) is: /Users/henrique/dev/someproject/. The problem is quite simple: since the directory specified for the parameter upload_to is /Users/henrique/tmp/uploads and it has a "base path" different of the place where the project is (/Users/henrique/dev/someproject/), django forbides access to it. It has a bit of reason to be, since django is avoiding you from future headaches (pollutioning directories outside your sandbox, for instance).

Of course, to fix it you just need to change the upload_to parameter to something like /Users/henrique/dev/someproject/uploads, that is inside the project's sandbox.

12 Oct 2008 (updated 12 Oct 2008 at 01:48 UTC) »
Testing your django app

Today, I found this nice blog post about testing on django:

http://ericholscher.com/blog/2008/jul/26/testmaker-002-even- easier-automated-testing-django/

It is interesting to see the way the test process is realized, it makes me remember a similar problem we had on the stoqdrivers (part of the Stoq project).

In that project we needed to (automatically) test our code against a couple of fiscal printers... teorically we would need to have connected all the printers at the same computer to run the test suite, and even this being possible, the tests would run very slowly and a lot of paper would be needed (apart the risk of putting the printer in a inconsistent state, what would make the printer unusable for a day at least :)

The solution was to log all the commands sent to the printer and the output returned. Once this log was saved, we could use it to feed the code, through a virtual printer (or actually through several virtual printers, created on demand based on the list of printers supported).

I think this way of testing has a defined name, but it still unknown for me... However, it is nice to see this "pattern" being validated in other areas like web and desktop applications development.

By the way, you can check the stoqdrivers test implementation at the: project's source web browser.

Pycon Brasil 2008

Last week I went to this amazing event in Rio de Janeiro. Well, I had the opportunity to know many guys that I never met before and to know other interesting guys as well (most of them users of django, community #django- br on freenode and the mailing list at google groups).

In this event I'd participated of a coding dojo season, since I never had participated of a season before and I would like to know what is that about. That was cool... nothing like a programming contest or a project sprint, like I was thinking of it. The dojo itself is more like a trainning, where a problem is presented to a group of people and then solved using a baby steps approach together with pair programming (from extreme programming) and TDD (test driven development).

Once a pair start presenting a solution and then coding it, they have 7 minutes to move it on. A refactory can be done (since all the tests still passing after that) or then continue implementing the last solution proposed (test first, as TDD dictates). After 7 minutes, the pair is changed.

The main feature of this dojo I liked most is the fact that nobody (except the pair writing the code) can to communicate, they have to wait for the test implementation finishes and executes (passing or failing) to speak something. This leads the public to think carefully about the code/solution that is being write, what is hard if everybody could speak at same time, proposing new solutions or starting complaining about the current solution (your solution could be accepted, but you need to present the advantages or then go ahead and implement it there).

For more information: http://www.codingdojo.org/

13 Aug 2008 (updated 27 Sep 2008 at 21:35 UTC) »

(nothing here)

7 Jun 2008 (updated 13 Sep 2008 at 16:05 UTC) »

Lets say you work on a company which has an employee working at home 'cause currently he is not at company's city (and will note be for the next 2 months). That's all fine, but it got complicated to ask the "sysadmin" to give him access to our server, his response takes so long and even this way the response propably will be a "no-no, sorry".

Well, at least some things got available to our employee and he can do its work.

It is raining and it is cold in the city and another employee would like to work at home; asking the sysadmin for access is not an option, so this employee explains the other employee that there is an option if he agrees to give access to your machine through SSH, so he could try some port forwarding through SSH and access the servers freely.

The slack employee then runs the following command on your machine:

ssh -L 8888:XXX.XXX.XXX.XXX:YYY slackuser@ofirst_employee_host -N

Where XXX.XXX.XXX.XXX is the IP address of the company's server you want to access, the "8888" is the port number at your machine which you access the company's services (you access the services through localhost:8888 and it will be forwarded to "XXX.XXX.XXX.XXX:YYY") and YYY, obviously, is the port. With that, you can access the services at company normally (actually, it should be a pretty slow, but it is better than rain and cold).

(For reference and pictures, please visit this site)

All the story was just to put that tip in a context, the slack employee will be at the office in the next monday :)

So long!

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!