After some shallow exploration, I have found a template/example for poster preparation in L^AT_EX. It is only one among many, but I pressed on with that particular one almost blindly. I am currently in the process of preparing one poster for a conference I will attend in Arlington, Virginia within a couple of weeks (there will be no blogging in that period).

Ironically perhaps, the author of this ‘T_EX forgery’ is currently working at Microsoft. He has been quite a successful researcher and I even exchanged a few E-mails with him. Nonetheless, the scenario is rather odd. Employment in Microsoft lies in complete disagreement to intentions of such contribution to to our L^AT_EX community. T_EX often obviates the need for commercial, proprietary software such as Adobe Illustrator.

Upon closer inspection, I discovered that another poster template produces visually-richer results. Yet, I have no experience with this L^AT_EX kit. If you have experience with other such packages and can also comment on them, please post them below for others to benefit from.

Previously, in my younger days of naive existence, I actually created a poster by handling a 6,000×4,000-pixel image in the GIMP. It was rather convenient, to be honest, but making subsequent changes was a tough task. You can find the amateur outcome on this site as a shrunk-down and down-sampled JPEG, as well as a lossy full-sized version. On my hard-drive I retain a ZIP archive which contains the 70-megabyte original bitmap. What a pixelated beast!

O anyone who is interested: I have put together a page that enables content spam to be reported to several search engines in tandem. The purpose of this little ‘utility’ is to centralise various pages of interest, which motivates spam reports that reach more than just a single company. The ‘meat’ of the report can be conveniently copied and pasted from one frame to another. Report spammy sites that violate ethics.

Wallpaper from Houghi (click image above
to enlarge; non-lossy PNG version)

With Novell’s release of XGL and Red Hat’s answer to all that eye candy, one begins to wonder if flame wars could awake over X — an Open Source graphics and interaction component.

An advantage to free software is that it is an environment where competition can thrive, choice is always available and different solutions exist for the same problem. However, it’s also fair to say that free software is disadvantaged where competition breeds, choices are forced on unsuspecting users and diverse technologies fight each other.

Related item: Next Generation of X

HIS item serves as a brief introduction and a pointer to a mailing list analysis tool. The tool in question is capable of producing statistics for mail that is stored in a standardised form, namely the MBOX format. The tool is called MailListStat, MLS being the memorable abbreviation.

I am currently generating statistics for mailing lists where I am most active, but there is a pitfall. Messages are not always RFC-compliant and, as a result, a certain number of messages gets discarded by MLS. Consequently, statistics do not reflect on the true figures and facts. I have changes the code and re-compiled it, but it was a “mend-and-break” situation. I could never get the desired results and only borked the package progressively. So, eventually I chickened out and aborted my initiative. The author of the tools admits there are some issues related to message headers interpretation. In the mean time, it seems as though I definitely gave up on this.

UPDATE: As of this morning, I am able to use the tool perfectly well. By saving mailing list archives in Horde/IMP, I am able to make the header both uniform and acceptable as input to MLS.

Related item: Newsgroups Statistics

N programming, efficiency always entails a cost. Contrariwise, simplified and inefficient code is often easier to understand. Where can balance be found? Can it ever be found? Efficiency is often preferred by so-called ‘power users’, whereas others opt for simplicity. Consequently, when negotiating projects, either at code-level or when deciding on UI design, flame wars may arise among developers or avid users.

Let us consider code optimisation. If the programmer wants to go all the way, (s)he could optimise by shortening variables, removing excessive spaces, and stripping out newlines. In such circumstances, interpreted code will be quicker, albeit less meaningful when an error arises and goes verbose. This is nothing like bytecodes and JIT, but similar rules should apply.

Good code should be well-structured, easily-readable, elegant, and well-documented. If the code is compiled, all comments should definitely stay in tact rather than ever be stripped. Automatic documentation can fit nicely in the source rather than be generated and made peripherally available, e.g. via Web pages. The only exception is debugging ‘bits’, which could definitely slow down program execution. As long as the developer keeps the original and saturated version of the code public, however, nobody need get entangled in closed-source traps.

On to an exciting prediction, with lowered file sizes and optimised code, programs could scale better on Wi-Fi-driven Web servers which run on a PDA in one’s pocket. Such server must be properly taken good care of, as well as the Internet connection, which is as vital as that of a synapse. With the growth of smaller devices, the need for efficiency is better realised.

EARCHING of the Web is no exact science. If it was, its exhaustive exploration would be infeasible. The more formidable search engines amass information from million of Web sites, each containing huge lumps of information — both textual and media. That information, in turn, could be interpreted and/or indexed in a variety of different forms. Rarely is the content truly understood, which is my personal motivating for knowledge engines.

Mathematics and physics could be argued to be inexact sciences as well, at least when a variety of man-made, non-fundamental fields are introduced. Think of computer science, for example. Its fundamentals assimilate to this complex problem, which is searching the World Wide Web. It is associated with ad-hoc solutions. Computational theories which relate to Turing machines are not tractable enough to make a most correct and efficient algorithm ever crop up and stand out.

Don Knuth has written his popular series of books on the issues of correctness and efficiency in common algorithms. It proves an elegant reference to many computer science practitioners. Problems which are simple, such as element or number sorting, are still handled differently by different algorithms and their efficiency is dependent upon the architecture involved, the scale of the problem, and its nature. Search algorithms likewise, which is why they should be engineered differently depending on a number of key factors. Hence, judgement of the quality of search engines cannot be done objectively, but only ever be estimated using test cases and artificial scoring schemes.

Still, everyone wants to discover the perfect recipe to outperforming Google. Others try to reverse-engineer their algorithms and cheat (fame and riches owing to ‘Google juice‘ that is channelled to one’s site/s). Many of us continue favour and recommend Google, which brings the largest number of referrals to most sites in existence. There is a danger here though. Large search engines are the main target for deceit and they are easily confused by spam inasmuch as they are inclined to pick up rare and valuable content.

Quality of search is probably in the mind of the searcher and the result of hearsay — somewhat of a ‘cattle effect’. Even engines that spit out cruft might be defended unconditionally by their innocent users. This may lead the competition to forfeiting the battle and invest fewer resources (e.g. datacentres) in the attempt to catch up. Phrases like “Google it” do not help either as they promote a search monoculture at best.

Related item: Search Engines and Biased Results

NE of the deterrents to a publishing developer are support queries, which follow a premature or ‘half-baked’ releases. Maintenance of code and replies to support queries become a necessary evil. Then come the bug reports, the question, the requests and the complaints, which can truly be a handful.

Here is my humble perspective on ways to prevent a chaotic support-bound life:

• The amount of queries depends on the extent to which you encourage or enable people to contact you
• If everything is properly documented and explained, expect a quieter time
• Programmers are notorious for writing code quickly, but neglecting to do the rest, which is ‘housekeeping’. Document your code properly as if you address support queries before they have been summoned by angry users.

Many of us vehemently loathe support-related E-mails. My public E-mail address was excruciating yet self-maintaining feedback system. That is also where bugs get reported and projected back to the public.