Why I stopped coding - and why I would like to do it again

Sometimes I wonder why I stopped coding. No,the above mentioned link isn't about me, but I couldn't state it better than this. I feel that I miss today the drive to just "fuss around" with stuff. Now I want to get things done, and little things that get in the way really break the flow.

Besides the database issues that the article describes so well right on the first page, there is another one that takes away all my pleasure from programming. It's an old problem that got worse recently: the lack of standardization regarding Unicode encoding. It's something that for us (weird users of diacritical marks and accented characters) just stays in the way. Another one is testing of visual applications, web apps included. In the end, all this stuff takes away a lot of pleasure.

But there is hope... even with my recent focus on managing people and projects, coding is still something that I miss. From time to time I give it a try. There are improvements. And who knows, perhaps I can do something myself to help solve these problems. I want to do it again, but this time, I want to do it as it should be done - with productivity and with pleasure.

PyKaraoke - Karaoke for Linux

This is a new project that goes along with my latest sound explorations... I just saw the announcement of PyKaraoke 0.4. PyKaraoke is a karaoke player, written in Python, of course. I'll check you and write about it over the course of this weekend.

The Linux Sound Font Manager Project

After a long time without writing any code... and thus without writing anything in this very blog... I'm finding some time to write code again, now for my personal use. The Linux Sound Font Manager is a new project, aimed a making it easier for a user to add, test, or remap sound fonts. It's part of my ongoing battle with multimedia in Linux.

Why does Linux need a Sound Font Manager? There are several reasons:

• I'm using Ubuntu. The current Sound Font support (via the freepats package) is good, but is incomplete. For example, some patches from the GM standard are missing. I suspect the same problem happens with other distros (news & opinions are welcome!).


• Even if it did support the full GM spec... having the option of changing the Sound Fonts is nice. If you don't like the sound of some instrument, you can change it, remap it, as you wish. Some sound fonts work better for some kinds of music -- for instance, the piano from a classic Sound Font may be different from the piano in a rock & roll oriented one.


• For professional musicians, it's a must. They need to be able to add their own Sound Fonts, or samples, in order to get the exact sound they want. The ability to remap patches on the fly is also important, as it allows easier experimentation with ready-made music fragments in MIDI format.


• Last but not least... it's one of the few things that I can do that does not involve low level hacking on the audio subsystem, something that I don't feel inclined to do. It's a self contained project, and I feel confident that I can do it in a reasonable amount of time. It's my own itch to scratch :-)

The scope for the project is simple. It's a visual editor, that will allow to import & install sound fonts, and also to maintain the Timidity++ configuration file. It will allow to test each & every sound in the system (using pre-made reference MIDI sequences). If possible, it will include sfArk support (so you don't need to download & install a separate sfArk package). In the future, it may include some basic Sound Font editing capabilities, mostly to allow the user to adjust the volume of individual patches. Time: two weeks from now (target: Nov 21) to have a working tool.

Living with Javascript

It's nice to be back after a couple months of unrelated work... let's start catching up, a lot of interesting things are going on the Python world.

First of all, there is a interesting discussion going on the Python Web SIG regardingJavaScript libraries. After a long thread discussing why everyone else loves Rails (which is something that really makes many Python programmers envy!), we're starting to talk about doing something real. And a good base of Javascript code would be handy, don't you think?

Well, it's not that simple. Javascript seems to be everyone's little dirty secret. Everyone uses, but most people don't really like it. Some (like me) dislike it for no other reason than being another language that they have to use. Some others dislike it for being named Javasomething (which is indeed something very strange). Yet others dislike it because it's a hell of a language to work with, mainly because it breaks the usual development cycle... it's hard to debug, trace, or otherwise analyze because it runs inside the browser. Most of the times, Javascript can't stand on its own legs; it requires other 'real' languages, such as Python or Java (or even PHP!) for something to be done. To top it all, there's the DOM, incompatibilities, you name it.

Once you understand that - Javascript may be tolerated, but (almost) never loved - it's easy to understand why there is so little movement in the OS camp involving Javascript libraries. I mean, the amount of quality & well documented JS libraries is ridiculous if compared to the relative importance of the language for the industry. The lack of real communities of developers is also telling. Please note that in no way I mean to disrespect the few brilliant people that is working with Javascript. Projects like Kupu are really brilliant, but overall, things do not look good.

For all the reasons above, I can't see it changing anytime soon. Perhaps if we had better support in some browser -- and Firefox is the perfect candidate here -- to improve the development experience; a more convenient enviroment, just to start with. So far, programming in Javascript it's been a long trip into a U2-class sub with the lights turned off, and no sonar to point the direction.

RAD style programming for web apps

It's nearly one month since I posted my last rant here. I was very busy, and working on a lot of different stuff, so I did not really had time to get my hands on code. But the forced rest was good, because it allowed me to take some time to investigate some of the underlying ideas that were bothering for long.

I was a relative early adopter of the then-called event driven programming, when the term was new, and Windows was barely a blip on the radar. My first experiences were with Borland Pascal, and later, with Visual Basic and Delphi. Of the tools of that age, I recall Delphi as being the best. It's design is still underrated; one of the best things about it was the quality of the VCL, a library 'done right' since the first incarnation. Of course, there were rough edges, but considering the maturity of the industry at that stage, it's a great library.

The main innovation brought to the mainstream by both Visual Basic and Delphi was the concept of visual components. I am not going to argue either about quality, or about who did it first. What set them apart was the easy with which a novice programmer could select a ready-made piece of code - a component - and attach code to handle events. That's incredible easy even by todays standards.

Fast forward ten years or so to the web applications age. It's amazing that even today, there's still nothing as easy to use as a Visual Basic component for the Web. (Of course, I am limiting my search to fully compliant web-based tools!). The best explanation that I can come up with is that web development is inherently different from standard GUI development, and so, porting the paradigm is impossible. The main problem sems to be the dogma of separation of presentation & logic. Also, given the fact that a simple component would have to rely on a fragile glue of Javascript, server script code, HTTP intrinsics and DHTML & CSS, it's fairly understandable why it's so hard to do it.

After some thought, I realized that I don't fully buy this explanation. I am beginning to realize how to glue all these pieces together in single framework, in a standard and reusable fashion. I already have some code working, as a proof of concept. The snippet below is a web form which declares a validator, in Python, which is automatically called (via a custom callback mechanism) when the EditBox component loses focus:

def isNotEmpty(result, formName, fieldName, formData, msg=msg):
 if formData[fieldName] == '':
     result.setWarning(formName, fieldName, msg)
 else:
     result.clearWarning(formName, fieldName)

class PersonForm(Form):
 nome = EditBox(
     source='name', caption = u'Name', size = 15,
     onblur=BrowserCallback(notEmpty,
         msg=u'The name can't be empty!'))
 address = EditBox(
     source='address', caption = u'Address', size = 60,
     onblur=BrowserCallback(notEmpty,
         msg=u'The address can't be empty!'))

The PersonForm class generates Web form, and attaches the onblur event to a standard Javascript method that initiates the callback, using an IFrame. The server receives the callback request and dispatches it to the isNotEmpty function, which was registered by BrowserCallback. The callback handler receives a result object, which exposes a simplified server-side API that represents the objects in the client side. The result is renderend as a snippet of Javascript code and sent back to the browser, which executes it to update the form display accordingly. Note that the programmer does not need to know Javascript, or how to write a callback; all the necessary glue is written automatically by the framework.

This is a promising experiment. My intention now is to generalize the callback mechanism, and define a clean API for the components. Separation of presentation and logic is not only possible, but easy to achieve; the code relies on CSS for all visual effects, making it easy to fine tune the details, including the positioning of the elements. I hope that this tool improves my own productivity with web development.

A curious remark about code structure in Python

Python never ceases to surprise me. Today I noticed something really simple; it's one of those things that can go on unnoticed for ages, but make the code read better.

When coding in several other languages -- C, C or Delphi -- there's the need to declare things before using them. As a consequence, class declarations tend to be organized to satisfy this restriction (of course, there are forward declarations, but that's the practice anyway). When debugging, or mentally tracing a sequence of calls, or simple doing a review of the code, more often than not, we end up reading the code 'backwards' - the most common entry points are usually located at the end of the source file, and more specifi methods are located before them. After some time, we get used to it, and we don't notice it anymore.

Then today, I noticed today, by accident, that the ordering of the methods in my Python classes is much more intuitive. Starting with the __init__, the methods are organized in a clear 'top-down' approach. The effect is that the source code can be comfortably read from top to bottom, as if it was an article.

I don't know about other programmers 'mental model' in this regard, but it seems to me that we are able to mentally 'push' the yet undefined symbols to check them down the code. Whatever it is, I found it very interesting, and yet another strong point for Python.

Trac is great!

Well. I may be exaggerating a little bit, but for people like me that easily get lost in the transition from the big picture into the details of the software, Trac is a great tool. My initial experience with Trac was due to the CherryPy project, that adopted it a while ago. Later, I participated in a private project that also relied on Trac for documentation and ticket management. It's a great tool. It lives up to the promise in its web page: to be an inobstrusive tool for software development management. It's still a 0.8 release, but if it keeps going this way, it's going to be a great success.

That said, I had some troubles setting up Trac in my main development machine. I had a Linux box, running Ubuntu Warty. I tried to download Trac in several formats: the official 0.8 release from SourceForge, the subversion-hosted version, and the Debian package. I installed all dependencies (for example, ClearSilver, a high-performance template package written in C and with bindings for Python). But I couldn't make it work. It always complained about something wrong with the database. I gave up, waiting for a new release to try again.

This week, I had a big problem with my PC, due to some mixups between packages from Debian unstable and Warty (I know, I was not supposed to be doing that, but I needed to use some stuff from unstable, and I had to try). It seemed to me to be a good opportunity to move to Hoary, the upcoming version from Ubuntu. It involves some risk, because I was going to rely on inherently unstable stuff. And the ride was rough, it must be said, but in the end -- and after a good day of downloading fixes and tracking dependencies -- I had everything working in a better shape than before. Now I have the newest version of Eric working (one of the limitations of Warty was its support for new Qt versions; the situation improved in Hoary). And at last, I decided to try Trac again.

I resumed working from the 0.8 tar file that I had downloaded a few weeks ago. I installed it running the standard 'setup.py install' invocation, which worked flawlessly. My customizations for Apache were kept in the upgrade, so I didn't had to redo it. But when I tried to run, it complaining about a missing neo_cgi module. It turned out that I only had ClearSilver for Python 2.3, and the new Hoary is running Python 2.4 by default. At this point I had to make my mind on whether to hunt new packages on the repository, or to solve it in a practical but less apt-friendly way, by installing such extra packages from the source distribution. I ended up choosing the later route. So I'm not relying on the official repository for such stuff, which is a shame, but made things more practical for me at this point.

I installed ClearSilver from the source (which complained quite a lot about some settings, again, because the standard installation script was broken for both Python 2.3 and Python 2.4 -- which is kind of weird). The fix is simple, and involves a few patches to the configure script:

   # include 2.4 in the python_versions string
   python_versions="2.4 2.3 2.2 2.1 2.0 1.5 22 21 20 15"
   ...
   # remove or comment the below & substitute for the other
   # PYTHON_SITE=`$python_bin -c "import site; print site.sitedirs[0]"`
   PYTHON_SITE=`$python_bin -c "import os,sys; print os.path.join(sys.prefix,
      'lib','python'+sys.version[:3],'site-packages')"`

The only other package missing was SilverCity, which is used for 'pretty printing' of source code in several languages. I did the same: downloaded from the source and installed it. It went smoothly. From this point, Trac was running. But running it under CGI is slow. As I am now running it for private use, I decided to try the standalone tracd daemon. It's much faster. There were a few issues with authentication that I was able to solve (using Apache style htdigest files), and now, it seems to be running pretty reliably.