Turns out Fractint development kind of stopped at Fracting version 20.0, one that is said to "even work under Win95". Outch :-)

However the DOS version still rocks. It runs very nicely under XP in DOS mode without any tweaks and finds lots of interesting VESA modes to use, so I ended up using 1280x1024 mostly.

In a matter of minutes I got myself re-acquainted with the interface and generated these images:

Click on the images to view the full album and larger versions.

Fractint is unique in that it can compute in a variety of precisions, ranging from integer to floating point but also the one called "arbitrary precision". Think zooms in the range of 10^100 or, as you will see below, 10^240. 20 years ago the speed was simply ridiculous.

This is called "deepzooming", and you can view many deep zoom examples here.

Deepzooming at the top of the Mandelbrot set has already been done, for example in this page from Bengt MÃ¥nsson. To put things in perspective, the most inner zoom I computed took me 3h30 at 1280x1024 whereas the page above reports 800 hours at 640x480 on a 90 MHz Pentium.

All of this starts when zooming at the tip of Mandelbrot, near -2,0.

There are a bunch of converging "nodes". One would think the intersection of two nodes is empty. Nothing exciting to see here?

Yet by zooming at the intersection between 2 nodes, it eventually splits in 4, then 8, 16, etc...

And there's yet-another Mandelbrot in there:

The only non-trivial projects that got completed in that time frame are rig3 and asqare.

I've been really busy recently.

First, on the work side, I changed teams at the beginning of the quarter. That was really good and invigorating. Lots had to be done, and lots happened.

Update: I generally tend to avoid posting about work and I will make no exception here.

Second, I changed my "workflow" at home.

I got real tired of not writing [Rig2|Dev/RigII] and decided to fix this.

I never got to implement Rig2 since the design was mostly self-centric: most of the design was driven by the desire to create a nice design. But there were no compelling features and thus no much motivation to start implementing it. Besides I had tried last summer to start the design and it had got boring and after a couple weeks of fighting I still had nothing to show but a bunch of self-referencing classes.

So I started again from scratch with Rig3. As indicated in the design doc, my plan was to implement the bare minimum that I needed right away. Then enough motivation would flow into the project to allow it to sustain itself.

To make this work, I had to focus on this single project for my spare time, and put aside a number of other ideas I had been toying with in the past two months. Too many competing ideas lead to spare time fragmentation.

And it worked. I started the design doc by finding which features I really needed that I didn't have. I found out that instead of re-writing Rig1 (the photo album) from scratch, I could just use it, and focus on resolving the current pain point -- namely that it was taking too much time to enter nice formatted posts in the Wordpress blog and that an [Izumi|WhatIsIzumi]/wiki-like syntax stored in plain text files with a pre-determined filename convention could generate those posts automatically.

Then I cut the feature set in two parts: the core "engine" part, which makes it possible to generate the content, and the "application" part, which actually generates the content. To start, I needed a bit of the engine and pretty much nothing of the application.

Then I cut the feature set even more so that I'd have a "two week" iteration -- the saint Graal of the over-hyped modern "extreme" programming paradigm. It turned to be more like a month-or-so iteration but it worked: I literally spend half an hour there, 5 minutes there, any time I had some time free and I could focus on the task, with the idea that I'd try to address at least one point of my task list per day. Think ahead where you want to go, split into small tasks and try to address them one a day.

At first I had nothing to show. Rather than rush to write a monolithic piece of "something" with no idea if it would work in the end, I used unit tests. Rather than focus on the naive and baseless mantra of "one test per method", I focused on a more sound strategy of "one test per feature". That is the idea of the test is to show that given task points get solved.

Accordingly half of the task points are for "feature X" and the other half are "UT for X". This means sometimes there are one or more tests for a given class or method, and sometimes there's just a single test that will test a top-level method and inner methods are not tested (kind of a black-box test.) In some rare cases, the result of a method call is really not testable, in which case I still write a test and even though I don't quite check the result, it acts as a coverage test.

There's more than 50% of the code dedicated to tests. One of my non-written goals was to keep the implementation as simple as possible and I think I did quite well on this.

Oh and I even rewrote my own template engine. In just 600 lines of python, including comments. This removes the need for the Django or Kid template libraries, which do too much for my needs and yet are not powerful enough.

Overall I'm very satisfied with Rig3 so far. After the initial cut, I started actually using it to produce content and quickly found necessary to add some of the features that didn't make it in the very first release. Most of the engine part will stay like this, changes are more expected on the application and templates part.

When trying to understand what they mean, I generally find two causes:

For the latter part, there's not much I can do. The best way to deal with irritating and annoying people is to ignore them, in the hope they just go away. There are evangelists everywhere. GPL fanatics are mostly irrelevant and they don't bug me so I can ignore them, except maybe the ones working for FSF or the ones actually drafting the GPL but then it's their job to do so. Heck they don't complain about paid Microsoft evangelists. Amusingly (or sadly) most people whom I hear complaining about GPL fanatics are actually anti-GPL fanatics themselves.

Now for the viral part, well yes GPL is viral and I have no problem with that. The main complaint I hear is that by using GPL I prevent others from using my work and instead I should be using a more liberal license such as MIT or BSD.

This is false on two levels.

First by using GPL I don't prevent others from using my applications. At the contrary, they are free to use them as they wish and they have free access to it and any updates. I don't either prevent others from reusing the source -- as long as their application is also GPLed, meaning I will have access to it.

But then that's exactly what they mean -- they want to be able to access my source and embed it in whatever software they have. If the software is commercial and close sourced I'm sure to have a problem with that and that's exactly why I choose the GPL in the first place, i.e. that I don't want others to take whatever I wrote and monetize it without retribution. I would, however, be more than happy to dual-license it against a reasonable compensation.

In the case the target software uses a more liberal license, say, MIT-based one, using GPL still prevent it from being included. That may be but again dual-licensing is always an option, although I would not degrade the original license from GPL to MIT since it would undercut the protection granted by the original GPL version. In this case I would instead advocate including GPLed code with permission from the author. Amusingly most people will refuse that because they are anti-GPL fanatics.

Now note that I'm not myself a GPL fanatic. I use GPL when I think it suits me, mostly for home projects that I want to open but where I don't really expect others to embed them -- i.e. applications instead of libraries. My idea is that by publishing an application as GPL, nobody will be able to legally take it as-is and sell it, yet however if any feels like it they can use it and extend it and hopefully give me back patches (which has happened in the case of RIG.) They can make money by using the software if they wish, directly or indirectly, there's nothing wrong with that (it's their effort as a user, not mine, also true for RIG BTW.)

If I were to create a library and wanted others to use it, then yes I would consider a more liberal license such as MIT. Note that here there are two cases. If I just want to make it available to anyone for free, I'd just put as MIT and maybe ask for a credit line and/or keep an embedded comment line with credits -- in which case the compensation is hopefully fame and showcase. However if I wanted to make money from it I could dual source it as GPL and closed, the latter for a fee -- GPL apps could pick up the library (they wouldn't pay for it anyway) and make it popular and closed apps could always buy a license.

To finish I'd say that where ever I said GPL earlier I meant GPL v2. Version 2 seems just fine to me right now. GPL v2 is about giving rights back to authors & users whereas the new version 3 seems to follow some kind of political agenda designed to restrict the rights of a number of people.

Looking back on Ruby, the language is interesting. From an outside point of view it looks a bit clumsy sometimes -- for example @var constructs. There's also a lot of room for confusing syntax -- or better worded flexible syntax which can generate confusing code. One example is the fact that you can call a method without using parentheses. Pretty cool at first. If you come from any other language that means that at first your see a construct such as blah.foo and you don't know if foo is a member, a method, a variable, etc. Ruby's point is that the difference is moot. I don't quite buy it as we're dealing with procedural languages which work by generating side effects so you want to know when side effects occur -- and Ruby's answer to that is that foo! generates a side effect but foo should not. Well it may be.

In the end it's all a matter of conventions: learn the possible syntax and then decide what works for you and try to be consistent about it.

The libraries are also important and there are plenty around so they are not an issue.

Eventually maintenance in the long term is what matters. I'll see how it works. Python, with its ugly need to write self.foo all other the place, is at least very predictible and so far when coming back to an old Python scripts aeons later I had no trouble remembering how it worked and I could dive right in. I'm not quite sure about Ruby in this context, as even to remember some basics I had to look at other code I wrote 6 month ago and needed to open the book to remember the @var thing. However Python is too verbose to do shell scripting whereas Ruby can be as consise and cryptic, err I meant efficient, as one wants it too be.

Now don't get me wrong. I'm won't go as far as claim that Ruby is an acceptable LISP yet I'll claim that Ruby is good enough.

Odyssey	Atari 800XL	Apple IIe	Apple IIc	Atari 1040STF	BeBox

In the mid 90's I switched to a 386-based PC running Windows, then 486 and Pentium followed soon enough. Around 1992/93 I was starting to play with Linux Slackware 0.99 and in 1994 I started hacking using experimental BeOS on a prototype Hobbit-based BeBox. I only bought my own PowerPC-based BeBox in 1996/97 and then later started hacking using BeOS on the Mac-clone Umax which I had won at the BeOS Masters Awards Aug '97 for PowerPulsar.

... print -u5 exec 3<&p

read -ru3 line print -r "$line" read -ru3 line print -r "$line" float r a=1 b=1.5 c=-1... (( r*sqrt(b*b-4*a*c) )) print r1=$(( (-b+r)/2 )) r2=$(( (-b-r)/2 )) integer even=0 odd=0 ... for ((count=0; count < 100; count++)) do if ((RANDOM%2=0)) then even=even+1 else odd=odd+1 fi done print even=$even odd=$odd TIMEOUT=10 select i in list edit quit do case $i in list) cat "$foo";; edit) ${EDITOR-vi} "$foo";; quit) break;; "") print ... esac ...

Outch. That seems like an awful syntax, very bash-like and extremely low-level. You'd expect something higher level for a scientific genius to use. Especially since it never takes more than a handful of keystrokes to reprogram entire subsystems.

Oh well, it's not like SG/SGA plots try to be logical very often.

Almost totally unrelated it would be fun to have a language where the reserved keywords are ortva raq vs gura ryfr sbe rnpu va pnfr fryrpg juvyr hagvy qb qbar. Another option would be to force Latin declinations when using verbs for method names in call statements :-) Sorry about that. I had too much fun with Intercal when I was younger and it obviously had some consequences.

The development cycle was not too bad:

I'd estimate there was about a 1 to 5 ratio here: 1 hour to implement the real functionality (it's really low tech) and 5 hours to polish the chrome around it and deliver, the whole thing split over 3 days. And another day lost trying to make it available.

Speaking of bloat, the resulting executable is 168 KB, the MSI installer file is 337 KB and according to the task manager the application uses 12 MB when running yet its VM size is 7 MB. For comparison, an empty .Net WinForm application (the default WinApp created by the C# wizard in VS.Net 2k3) generates a 16 KB executable that uses 8 MB of memory and 6 MB of VM when running.

Obviously having a kitchen sink run under the hood has a price in terms of memory usage, not to mention the hefty 20 MB initial download (which I painfully forgot to load on my secondary vmware dev box :-( ).

That's more or less right on spot. I can (almost) relate.

From my experience, very few companies' managements would agree with this -- OK maybe on the paper, yet making it happen is another story. I can foresee the typical comment: "these new software engineers they expect a red carpet to be laid in front of them. In my time it was not like this."

Obviously it requires some forward thinking, a larger organization, a commitment and a lot of support/investment. I don't think than an organization can move from one scheme to the other either -- can't scale up, nor scale down.

And it's not something you can change in an existing environment. Not as long as the idea will survive that work should be hard, not fun.

Last week I was totally excited when I finally took a close look at Groovy so I decided to try to use Grails to develop some RAD database web-based front end. And boy was I disapointed.

Finally I ended up trying with Rails (aka Ruby on Rails) and that was it. In two days and a couple hundred of lines of code I had my functional SQL-based web site front end.

Now there's a story here and it's not about whether Groovy or Ruby and which one is good or bad. The fact is I wanted to use Groovy because of it being Java based, with the expectation that I was already familiar with the Java syntax so Groovy should be easy to pick up, right? On the other hand, I didn't care for learning Ruby's syntax.

In the end after spending several hours experimenting with both, Ruby was easier to use than Groovy despite it being a new syntax. The reason has unfortunately nothing to do with the technical merits of the languages (both are equivalent IMHO).

The real reason is the documentation and their respective web site.

Ruby's web site is developer-oriented, with direct links to various tutorials including the OnLAMP articles on Rails, direct link to javadoc-like Rails documentation for all classes and more important a wiki with tons of user feedback and tips.

The Groovy web site on the other hand lacks all of these. There are a couple of tutorials to get started with Groovy but these lack depth. Once I was past the initial step of installing Groovy and creating an empty Grails application, I was mostly left in the dark. Interestingly, the Grails tutorial starts talking right away about controllers and views without ever defining them. It's almost as if Grails was a pure Rails clone and the developers expected their users to be already familiar with Rails' terminology and the way of doing things (which I believe is exactly where the problem is.)

In the end one almost needs to learn Rails before starting to understand Grails. Which sounds to me like a lack of vision typical of open source projects. Anyone that checks out Grails might just end up frustrated like I did, go to Rails and once there just not come back to Grails.

As usual, I still think IDEs are the way to go and when it comes to Java-related stuff there's no way around Eclipse (well not unless you want to pay for IntelliJ, which seems like the next best thing, except I want free/open source stuff here for my tool chain.)

Consequently this morning I recompiled an updated version of the Groovy plugin for Eclipse and made an Eclipse Update Site for it. To use it, you need Eclipse 3.1 with a JRE 1.5.0 then go to Help > Software Updates > Find and Install, select Search for new features to install and create a New Remote Site with URL http://ralf.alfray.com/eclipse/. This is based on the Groovy Eclipse plugin from CVS for version JSR 03 yet I updated it with a Groovy JSR 04 jar. It's not an official distribution. The only minor issue was a compilation error because the getSuperClassNode() does not longer exists in ClassNode and needs to be renamed to getSuperClass().

If you want to rebuild your own plugin, follow the excellent directions on the Groovy plugin for Eclipse page as they are rather obvious. The instructions to create an Eclipse Update Site can be found in the PDE documentation that comes with Eclipse. The whole thing is extremely easy to do and straightforward.

It was actually pretty good. We finished cleaning the baby toys, I played a bit more with DV Video, started having a look at x264 (although I haven't managed to get FFmpeg compile with x264 yet -- not to mention it's not clear which decoder over than VLC can decode it.)

Most important I finally started having a look at Java 5.0 and the latest Eclipse 3.1.1 which totally rocks imho. It helps that installing Java 5.0 on Debian is quite a piece of cake.

Speaking of Java, I think it's time Sun stops the marketing insanity with version numbers. "Java 2 Platform, Standard Edition" with Java 1.4 or "Java 2 Platform, Standard Edition 5.0" with Java 1.5. This is so freaking annoying. Can't they do version 1 and then version 2 like everyone else? OK maybe with a version 1.1 thrown in the middle like our friends in Redmond. Would it hurt them to match the platform revision number with the language revision number since they are so much tied? Yeah, surely, people might start understanding what Java is all about. Hopefully developers will get brain damage first whilst trying to get a grasp of the acronyms in use: J2SE, J2EE, J2ME, SWT, JAXP, Struts, Swing, etc.

Anyway, it's unfair to make fun of Sun as it's too easy. Kinda like Apple and their horde of brain damaged fans that will now go berserk explaining to the rest of the world how hype it is to watch a webcam-quality movie on a screen smaller than my watch for $2 a piece. They probably need that now that they can't credibly explain any more why one-button mice are vastly superior.

Anyway Java 5.0 is pretty cool. Annotations and templatized types are always good to have. I still can't quite find the syntax for closures, although I'm being told there's an incoming Groovy patch for that.

Speaking of closures, I had the unfortunate "luck" to discover what probably everybody else found with closures in Javascript: closures created in a for-loop are not bound as one would think they should be.
This post explains it perfectly so I don't have to: A huge gotcha with Javascript closures and loops.
Really I think this sucks and smells as a "bug in the spec". A good semantic would be "var f = new function() { ... }". I'm not sure why one can't do that if functions are first-class citizen objects?

I had another cool thing to blog about yet I forgot it. Oh well. I feel like the Bear with Very Little Brain, namely Winnie the Pooh which original book I have been reading lately (along with Applied Cryptography.) Somehow the former is easier to read, although Schneier is quite interesting to read too.

Oh yeah so that cool thing to blog about. Well it's not much but it goes this way: I've been having a look at the various dev projects listed on [Izumi|WhatIsIzumi] and most especially the plans with dates which are all listed indirectly via the Project List. My point was that if you look at the project pages, my projects barely advance. They literally stagnate. And sure they actually do. Not that I'm quite lazy (well I am lazy but that's not my point), it's more like I have only a limited amount of free time and recently coding hasn't been the priority (getting a life was.) Plus it doesn't really matter. I keep my creativity and energy for work (I mean it like the real work place, where they pay me to do exactly that) and I home I can relax and spend time on whatever or with whom is fun (such as significant others.) Coding is still a lot of fun. One day it's PHP, the next day it's Java and some other day it would be planning and thinking about stuff rather than actually implement it.

Such it's life and I'm having quite a good time :-)

By the way, there's one more project plan page for [rig2j|RigTwoPlan].

Outch. I actually ate too much chocolate cake tonight.

Programming on the Apple II was easy: fire the integrate Basic runtime and start typing. And when thing went wrong, as well always do with computer programs, the easiest debugging utility was printing variables on the console.

That means somewhere the Basic runtime was interpreting a print instruction, getting a string and giving it to a system routine that would copy it at the adequate location in the video memory then a character line generator would translate that to a video signal for the monitor.

Years have passed, computing power has literally exploded and we have state of the art visual debugging tools.

Yet most of the time my main debugging tool hasn't changed: I print lines on a console output.

The workflow is a bit more involved though:

So in nearly two decades, the main way we program and debug hasn't advanced that much and most of the time the "best" solution to debug is just to clutter my code with ugly printfs.

I've started working on RIG 0.8.

Years ago, during my school years and my first employment years, I quickly realized an emerging pattern: when it comes to computing I'm generally able to leverage knowledge that I had previously gathered on my spare time. All this computer-related stuff I read on my spare time, all these languages I try for no apparent reason, that generally pays off sooner or later.
I was learning Pascal on my spare time when Basic was a requirement at school and I already knew quite well. Then at the university, I was learning C and Objective-Pascal when classes were done in Pascal. Then I started exploring C++ just to find out that's what needed for work, and so forth with PHP, .Net, C#, Perl and more recently Python.

Back in 2001 I attended the first Mozilla Developer Day at the Netscape's headquarters, followed by the first Mozilla party. At more or less the same time I was checking out Mozilla and fighting to have it build and eventually succeeded -- a useless exercise as I was not really planning to contribute to it. Merely out of curiosity and totally worth it, if not just to realize that there was a daunting amount of code involved and pretty much an equal lack of documentation.

Two years ago I received the book Rapid Application Development with Mozilla which triggered the same behavior -- checkout the code, compile it, browse it and move on to something else. At least I can understand a sentence that combines lots of acronyms like XUL, XBL, XPCOM and Gecko and feel like I know what the concepts are all about.

All these little efforts seemed basically like useless exercises at the time. Yet, in much accordance to the above mentioned pattern, this is going to prove useful sooner than later.

More recently I heard of Dive Into Greasemonkey and this may as well become a good read.

That first idea has to do with how to integrate an answering machine like capability in an audio/video stream that adapts to bandwidth. It's not exactly new, yet I realized I had never wrote it down before.

The second idea has to do with the purpose of [Izumi|WhatIsIzumi] -- that is I'm an engineer so I tend to explain projects from a technical point of view of how they work, yet somehow I understand that it is sometimes more relevant to ignore all technical details and simply solve one problem. Even if a system is made generic to solve more than the one problem at hand, people may not understand what the generic system will solve. Instead it is easier to just tell them exactly what they can do with it. Then once they get used to it, they may start asking for more functionality and with some luck the system can be expanded to include that.
If I apply this view to [Izumi|WhatIsIzumi], instead of describing it as a content management system I could describe it has a place to keep links, photo albums and other kind of material centralized on a server, with automated mechanisms to publish it on the net (thus potentially indexable by search engines) and of course the ability to decide what is public or private.