I am the fool who tweaked Qt to work with long-distance X11. The main problem was slow startup; if the ping time to the display was 0.1s, then applications needed 0.5s or more to start. So I fixed that, tested it using Qt/X11 applications on a transatlantic link, then fixed whatever else that I noticed because of the slow link.
As far as I know, noone ever made use of this work.
That didn't prevent someone at Trolltech from trying some of the same again twelve years later, except this time with better buzzwords and more effort.
So why did I do it? I don't remember. Perhaps someone had told me that X11 was network-agnostic by design and Qt's implementation fell short of the design, and I let myself be persuaded. Perhaps I told myself. One thing is sure: Noone had told me that this was a problem for their actual, concrete, existing application.
Maybe my work helped sell a seat or two for Qt. Many people are willing to pay for features or performance they don't need, so it's entirely possible. But I think it was probably waste. I feel good about it, though, because quite recently I was able to avoid a mistake by having learned from those two.
I've been a professional programmer for twenty years now. That seems to be long enough that for whatever mistake anyone proposes to make, I have made or watched a similar mistake at least once before. I'm not sure whether that's good or bad. Seeing a mistake be repeated is such a sad feeling.
All the hate against openssl at the moment makes me sick. Yes, it was a bad bug, and yes, the API is frustrating. Still, it reminds me of an episode at, I think, Linux-Kongress in Cologne in 2002, and it is not a pleasant memory.
I wasn't wearing any badge, and hadn't been to many linux events in the eighteen months since I left Trolltech, so some people had forgotten how I look. Including one person, who talked at length about how evil Trolltech was. About 20% accurate facts, 30% lies and 50% opinion, and the opinion wasn't favourable. He also mentioned me specifically, with me standing slightly more than one meter to his side. He might not know how I looked, but he certainly could talk about my thoughts and intentions.
Haters gonna hate, I suppose, but it was deeply dispiriting all the same. I haven't been to Linux-Kongress since.
I have found fifty-three dollars on my desk. I remember why they're there: 15-20 years ago, someone whose name I have forgotten gave me a dollar to help pay for a haircut and three others then chipped in. Their four dollars
have littered my various offices since.
One of the three must've had too much to drink, because now that I look closely, I observe that one bill bears a portrait of Ulysses S. Grant and the number 50. Good. $49 is an appropriate fine for a joke as poor as that one. Justice has been served.
It's weasel wording and angers me. The real meaning of the statement is almost always that someone is me, and we both know I'm not particularly well qualified
.
Another ancient Trolltech principle was the person who did the work had final authority over how it was done. Not exactly a result of planning — I think that principle came to be when the passion for quality clashed with the workload. A serendipitous compromise.
This is mostly a footnote for my review of Knuth's Literate Programming book. Read that first.
Undocumented arguments often occur where an argument wasn't considered in the code, or where the design is wrong. 50-60% of undocumented arguments were also buggily handled at Trolltech.
That correlation depends on the documentation being written by hand and by programmers. Generating documentation like Ghostdoc does breaks the correlation completely, and starting with mostly-generated text like that from Eclipse also weakens it to uselessness. If you, as a programmer, forget something about the argument while implementing, but someone/something else writes the documentation, then there is little or no correlation between what you forget to implement and what Ghostdoc, Eclipse or a technical writer forgets to mention.
The same applies to undocumented public functions in a class: If there were any at Trolltech, those functions were usually not ready for production use. Scanning for undocumented functions was a quick way to find functions with other problems.
Undocumented nulls and other edge cases are frequently unhandled; at Trolltech I had something to scan for pointer arguments where the word null wasn't mentioned in the same sentence as the argument. It found treasure quite often, but the text analysis was too poor to use it all the time, for example because the null was mentioned in a following sentence. Warnings have to be good, and quite often
may or may not be enough.
I've never had a tool that parses both the implementation and the documentation. I wish I had one. It could look for differences and use them. Here are two examples:
When a caller and a callee disagree, the documentation status can be used to point at the most likely guilty function. Suppose x() calls y() and doesn't catch an exception y() may throw. Is that best reported as a problem in x() or y()? That depends on whether the documentation for y() mentions the exception.
If a function takes an enum argument, and the set of enum values mentioned in the code and in the documentation differ, then something is almost always wrong. It may be in the documentation, but in my experience it's more often in the code and sometimes in both.
The should rules went out of fashion at Trolltech after I left. I don't know when, but some people who started in 2006 didn't learn them.
Which is a pity, they were good rules and in my opinion they still are.
The rules were: In a meeting (which at early-Trolltech usually meant over lunch), the phrase we should …
meant I will …
, and someone should …
meant I immediately will …
.
The rationale for this is what we should
and someone should
was weasel wording for I think we should …, but I know I can't persuade anyone else to take on the work
. Often (but far from always) noone else thought the result was important enough to justify the working time. Sometimes there were many other reasons. But the reasons don't matter, the results matter, and the should rules made people speak more realistically.
For what it's worth, the rules were suggested by Paul Olav Tvete.
One evening in November 1998, drinking with some of the trolls at Suetelane Paludo's place, I ranted grievously about how installing linux still sucked. I'd spent the day installing a new server. In typical Trolltech fashion, the discussion quickly turned to what we could do about it. We decided that noone at Red Hat or Debian would talk to us because Trolltech was so very evil, Suse suffered from NIH syndrome, but we could talk to Caldera (ie. the German team Caldera formed by buying LST) and maybe get something done.
I put together a proposal (a single-page email, just text). Ralf Flaxa and Stefan Probst at Caldera immediately accepted it.
What followed was great. […More…]
My cron-driven alter ego ran several scripts on the Trolltech web server. This is about one I wrote in 1996 and ran every half-hour to make sure that qt-related subjects were well covered by the search engines. At the time, some search requests didn't give as good results as they could have, and I thought the likely reason was that the search engines hadn't crawled the right pages.
But the pages tended to be in the Trolltech referrer log, or if not, then some other page very close to them were.
So I wrote a crontab script to watch for new referrers in our apache logs, and whenever it saw one, it did the following.
First, get rid of spam (yes, even then there were spam pages). The test was simple: At most x% of the text could be links, the page should mention one of a set of keywords, the page could contain at most y links, and at least one link had to point to Trolltech.
If the page passed that test, the script tried to clean up the URL a bit (delete session cookies, delete index.html). Next it tried to locate a higher-level index page linking to the candidate page and other related pages (since submitting an index page gave the search engine more to work with).
Finally, the script would submit either the payload page or the index page to Altavista, Hotbot, Lycos and a fourth engine whose name I've forgotten. I don't think it was Google, Google came later.
It worked very well. Searches for Qt-related subjects gave better results than before, and yes, the search engines saw more links to troll.no. The script ran until shortly before I left Trolltech in 2001. By that time Google had learned to crawl well, and the script laid unused and forgotten until I found it today, while going through and wiping my old hard disks. (Update: The reason I don't know the name of the fourth search engine is that I had put the submission URLs in a configuration file.)
Update: The fourth was, of course, Excite, whose existence I had quite forgotten.
When I arrived at Trolltech, there wasn't much documentation for Qt. Some good intentions, some outdated Τεχ source, no plan for improvement. Having suffered from that (I was the world's first external Qt user and needed documentation) I set about writing a usable documentation tool and documentation. One of my jobs became Documentation Supremo. I wrote some/much documentation, wrote the tools, kept track of quality and gradually improved the way we produced our documentation.
I did not write all of the documentation, far from it. While I wrote much and looked at the rest, I could not have written all. It was essential that everyone who wrote code, also wrote documentation.
Our documentation process worked (we wrote documentation and it largely satisfied the readers), so in this post I attempt to document what we did and what made our process succeed. […More…]
Last night I read that use of the GPL is declining, ever faster. Makes sense. And makes me want to braindump another minor aspect of Trolltech's history, with a bit of a comment.
Trolltech started using 100% closed licensing, then, when I suggested it a few days after being hired, gradually released Qt under ever more permissive licenses. […More…]
Nokia's rampage makes me want to post the picture below.
It's from a very rainy Friday in September 2000. I had a meeting around noon that day. Directly afterwards, I went for a weekend in the mountains with two friends, and I felt just like that.
About an hour after the picture was taken, over dinner, I explained my mood. Unless things change, I expect I'll leave in a few months
. My forecast was good, I gave notice four months later, ten minutes after another depressing meeting.
Qdoc misses many features Javadoc has. This is intentional — javadoc has many naïve or harmful features. Here's a braindump of the features I dropped or decided against adding.
@author is one thing Qt had, but I dropped it due to two problems. First, it misled users who used it to answer the question who should I ask about this problem?
. The problem was typically about some recent change to the file, and the original author of the file was the wrong person to ask. Second, there was some reluctance within the team about editing someone else's code
, which delayed bugfixes. […More…]
The origin of udoc goes a long way back, to when I still was a student at the University of Trondheim, the world's first and only Quasar Toolkit user, and about to start working at Trolltech, which at the time was called Quasar Technologies (Hi Haavard) and occupied a room and a half overlooking a busy street in a rather unfashionable part of Oslo.
I wasn't very happy with the Qt documentation, which was then written using LaTeX macros and already obsolete. I was also an opinionated asshole and far too sure of myself, and I'd just learned about Donald Knuth's literate programming techniques, but I hadn't read his book. Naturally I looked at the existing litprog tools (there were quite a few) before discarding them all to write something good. […More…]
For a long time udoc was called qdoc. Because Trolltech might want to release its qdoc (abbreviated from qt doc tool
for no particularly good reason), it seemed sensible to rename this one before release. A simple matter — just step along to the next letter, I thought. But then there turned out to be something called rdoc already. And two programs called sdoc. tdoc was taken too. A few quick searches showed that there are more than 26 programs like udoc.
You can understand why I considered naming it fdoc.
In a not-so recent thread on the defunct linux-isp list I wrote slightly harshly about Emerging Technologies' driver for its ET/5025 synchronous serial card, which I was using at the time to talk HDLC to a Cisco router at my ISP via a 64k line.
I had been using the ET card for almost a year and was getting rather restless, suspecting the card or driver to be the reason for my much too frequent crashes. David Mandelstam of Sangoma, one of ET's competitors, wrote to me and offered me a substantial discount in return for the card, and for my writing to linux-isp about my experiences with both cards. […More…]