Archive for November, 2008

GMail Themes (and its launch faux pas)

Thursday, November 20th, 2008

Oh my!! Did you see the new GMail themes feature?? It’s freakin’ awesome! No seriously. Within minutes, I’ve found my favorite among those themes: the pebbles theme! The color scheme is absolutely pleasent, complete with transparent bars.

This, together with the label colors lab feature has turned my boring gmail account into a very pleasant color explosion. Soothing and relaxing. :) Try it out if you have an account (or create an account). You know, sometime I think that everyone has a gmail account. When I see an e-mail that is not gmail based, I can’t help feeling delighted (at seeing something not ‘et’ gmail ‘dot’ com).

GMail made a faux pas during the launch of themes. Usually new features will only appears when GMail is refreshed. It seems that this one wasn’t launch that way. The new theme appears halfway on my GMail. It was shocking. I thought something was really wrong with my GMail since the color looks really horrible. Fortunately, the first thing I did was refreshing the page. After refreshing it turns to be quite pleasant (the “default” theme). I thought it might just be my browser. An hour later, a friend was pointing to me that the web snippets (those text at the top of the inbox with text coming from other sites) were virtually unreadable due to the color scheme. My conversation with him was quite funny. We thought that somebody in GMail is so gonna get his arse burned. ;) We were kidding, of course (in case some Googlers read this). I told him to refresh, and he loves it.

(You might also want to try the time-based themes; those are pretty cool as they change with time. I tried the Beach themes, but after awhile, it still doesn’t look as appealing as pebbles.)

John Resig’s degrading script tags

Thursday, November 13th, 2008

I just re-discovered this interesting Javascript trick from John Resig’s blog (link here). Under usual circumstances, I would frown when I see eval in Javascript code, the one construct I tried to avoid like a plague. But I don’t resist interesting usage of eval. This is one of them. Basically, the trick allows you to have a script tag with an embedded Javascript, like this:

<script src="some_js_file.js">
  // Do something with the loaded file.
  callSomething(); ...

Interesting huh? To make this work, the loaded script file itself will end with the a two-liner that basically find the script element and evaluates the innerHTML of the element:

var scripts =
eval(scripts[scripts.length - 1].innerHTML);

Ingenious. As an added bonus, the content of the script element will not be executed if the Javascript fails to download (since, obviously, the last two lines that we just added won’t be executed).

Also interesting is how this hack utilizes the synchronous property of Javascript loading. In most browsers except the most recent ones (most of them still in beta/nightly), whenever a script tag is encountered, the rendering stops until the script is downloaded and executed. That means by the time the script is loaded, it knows for sure that the script tag it is in is the last one on the DOM since nothing else has been rendered. Thus, you can access the element by using the above method (see scripts[scripts.length - 1] part of the code).

I’m a little bit behind with how newer browsers download its Javascript. I suspect that the method above may not work. I guess it’ll depend on the heuristics the browsers use to make Javascript download not blocking. I heard that Firefox will actually assume that the script does not do anything to the DOM and continues rendering, in which case the above technique may not work. (I’m sure I’m missing something, probably there are some heuristics that FF used that I’m not aware of.)

Well, still, it is an ingenuous way of utilizing eval.

Parallel programming is a double-edged sword

Tuesday, November 11th, 2008

Today I read an interesting article at DDJ on understanding parallel performance. It outlines several truths about multithreaded code. One is that it is not always faster than non-threaded code.

Yes. It’s surprising. Several years back, when I was young(er) and single-core was the only choice of affordable PC (there were those servers with multiprocessors, but those aren’t affordable at all), I was naive to think that if I make my code multithreaded, I will gain some speed. In general that’s probably true, up to a point. Too many threads imply expensive context-switching, especially in a single core (heck, it is still a problem with multi-cores, as long as there are more threads than cores, as the article clearly pointed out). Over the years, I realized several considerations to ponder about when coding multithreaded code.

The first is how CPU-bound are your threads. If your process is highly CPU-bound, it is not worth to have more threads than cores. Remember, there are always other processes running as well, so the optimum number would be the same as the number of cores, or less as number of cores explodes. For CPU-bound processing, it is better to minimize context-switching.

Blocking process is another consideration. Any process that may block for I/O or to obtain a lock should be run on a thread pool. In this case, I would say that having 2-3 times threads compared to the number of cores are optimal for most cases. Note that for highly I/O-bound processes, more threads may be needed to fully squeeze every ounce of performance out of those cores.

Locks. When your threads require access to common resources, reduce the number of threads. Too many threads will cause lock contention everywhere and slows down processing as CPU cycles are used to acquire locks. Either minimize contention, which may not be possible on most cases, or segregate resources appropriately. For example, you may want just 1 thread to write to a common file, with any threads wanting to write to that file queue its task to that 1 thread. It’s not too easy in other cases. Although there are usually way out that minimize the number of lock contention. For example, when writing to an object, try to have different threads writing to different parts of the object, hopefully unrelated part.

In some cases, you can make a single thread perform much better than multiple threads (well, I said single thread, but I’m lying). The idea is to saturate the thread as much as you can with CPU-bound tasks. You may have some other threads (see I lied) that collect resources and writing out data as the single thread completed its tasks. In a web server example, you can have one master thread. When an incoming HTTP connection arrives, another thread will process the request into a task (perhaps a Request object?) and queue it at the master thread as it comes. The master thread may process one request and realized that it needs to read a file and queue that task to another file reader task, while at the same time returning the partially processed request back to the queue and start processing other request. Most bottleneck here will come from the queue implementation, but this is a baby example so I’m going to stop at that. Another bottleneck will be if the number of incoming requests arrive faster than the speed in which the master thread can process the requests, in which case, we arrive at classic example of dropping of requests (a la network routers and switches). In that case, it may be time to consider having 2 master threads.

From the above examples, you can probably tell that this method of self-managing your “threads” (in this case, instead of threads, we have requests) allow for much faster processing as it reduces context-switching.

What about LWPs (light-weight processes)? Indeed… what about LWPs? :) LWPs are fast, I love it.

P.S. Do read the DDJ’s article above. It’s very thoughtful.

Rant #1

Sunday, November 9th, 2008

Sometime I just need to rant to cool myself down a little. Rather than bringing it out on unsuspecting strangers (well, it usually got out to that stranger in my imagination), I thought it might be better for my blood pressure to actually write them down. I mean, I am getting older, high blood pressure isn’t something I want to be playing around with anymore.

On clueless educator:
If you did not know about x, do not blabber as if you know what x is. It is okay if you say, “I’m not familiar with x, would you mind explaining it?” It is not okay to say, “I think x is not good because of a” where clearly x and a has no relation.

On Javascript and Java:
Javascript is not Java. The only similarities between them are the four consecutive letters they share and the fact that both of them use C-style syntax and has garbage collector. In all other aspects, they are not the same. Read my previous post1 and tell me which part is the same? Even with regards to OOP, they differ.

On writing a short treatise:
My fault. But I realize that writing a 20-30 pages manuscript on something that’s close to your heart is still hard as hell. It takes a lot of thoughts to make it interesting and to not write too long. I mean, people wrote books about those 20-30 pages I’m supposed to write.

For reading through my rant… A present: js2-mode for emacs. A friend asked me what I used for Javascript syntax highlighting in emacs. js2-mode is the answer.

  1. []

Javascript: several paradigms in one

Saturday, November 8th, 2008

Now, coders familiar with C++’s infamous text The C++ Programming Language The C++ Programming Language by Bjarne Stroustrup1 would be familiar with his adage of C++ being a language made up of 4 different paradigms: C imperative, modular data abstraction, object-oriented C++, and template metaprogramming/generic programming. While some would say that you should stick with one of these paradigms when programming in C++, the truth is more of a mixed. I focused on object-oriented C++ with sprinkles of templates (I stay away from advanced, Boost-y templates, they are harder to get right and harder to maintain—and time is more important to me than reducing code duplication to 0.00%).

Javascript. Well, early Javascript programs I saw years back were purely procedural with sprinkles of functional paradigms. And they look ugly. For awhile, I decided to stay away from Javascript, only picking up this really cool language slightly over 2 years back. Man, this language is one heck of a language. Like C++, it’s a mixed bag of paradigms, some of which are:

  1. Procedural programming
  2. Functional programming
  3. Object-oriented programming
  4. Semi-generic programming
  5. “Hacks”-oriented programming

Procedural programming

This is probably the very basic of Javascript that most programmers use in the early days. They consist of simply procedure-based programming techniques. Programmers wrote libraries of functions and procedures that does certain manipulation and use them without much data abstraction. It is common to see code like this:

function highlightElement(element) {

// ... and later ...
function onLoad() {

Functional paradigm

Most veteran Javascript programmers would be very familiar with the concept of closure in Javascript. Many programmers also use closure without realizing that they are using one. Closure is very useful and it is one of the best thing offered by Javascript. The essence of closure is that you can create a function/procedure anonymously in a given scope; this anonymous function (while function and procedure differs slightly, let’s just use the term function here) keeps a closure, that is the environment where it is being declared. Therefore, this function can access all variables accessible in the scope where the function is declared. Well, an example will speak more than my rumbling:

var x = 1;
function createHandler(int index) {
  var element = getTableRow(index);
  return function() {
    // This function can access
    // 'element', 'index', and 'x'.
    return x;

var handler = createHandler(5);

// This function call can still access 'element'
// and 'index' although we can't directly
// access them from this scope.
handler(); // This returns 1

// This is the fun part...
x = 2;
handler(); // This returns 2!!

Object-oriented Javascript

This is my favorite by far. Javascript offers a really cool “primitive” object-oriented programming. By “primitive” I meant not having visibility that marks most other OOP languages. However, it’s still cool. To create a class, we just need to write class prototypes.

Highlighter = function(highlightColor) {
  this.highlightColor_ = highlightColor;
Highlighter.prototype.highlightElement = function(
    el) { = this.highlightColor_;
Highlighter.prototype.setColor = function(color) {
  this.highlightColor_ = color;

// To create an object:
var highlighter = new Highlighter('#dedede');

You can perform inheritance and mixins by inheriting the prototype attribute of a class. Awesomeness. Furthermore, you can inject methods into an object without actually having a prototype for the method.

// Let's add method to highlighter object.
highlighter.getColor = function() {
  return this.highlightColor_;

// Now you can use getColor on highlighter object
// but not other Highlighter object.
highlighter.getColor(); // This works.
new Highlighter().getColor(); // Failed!

Semi-generic programming

Well, Javascript is dynamically-typed, so it is very generic. What I want to highlight here is that you can write your code on-the-fly and executes it right away. You can, for example, easily ask your user to type in some Javascript in a textarea and grab that as a string and run it.

Is this a good thing? Usually no! Stay away from this as much as you can. So, stay away from any form of eval! (I guess an exception would be when unsafely parsing JSON; though most modern browsers now have good JSON parser that is probably faster than using eval directly.)

“Hacks”-oriented programming

Ok, this is pushing it a little bit. But hey! You almost never be able to escape from this when you’re doing the more advanced DOM manipulation. I’m almost tempted to say that you’ve never experienced the real Javascript if you haven’t needed to perform weird and crazy hacks on it (well, unless you’re working on server-side Rhino).

Well… When it’s about programming for several web browsers, some of which as old as 6 years and quirky beyond belief2, you have to perform some hacks to make sure things work correctly across all browsers. Recently, I illustrated this by writing about min-/max-width hacks for IE.

This is one fun part of the language. While it’s frustrating sometime, you have to admit it’s fun.

So, this is Javascript. Some consider DOM manipulation as another aspect of Javascript programming. Yes, it is. But DOM manipulation generally falls in the Object-oriented programming side of Javascript (oh, and “hacks”-oriented). Isn’t Javascript cool? I’ve used it frequently in the past 2 years and I must say it’s one heck of a language.

And Javascript 1.7 is coming with many interesting new features.

  1. While I wouldn’t suggest this book for first-time C++ programmer with little background in OOP or C; this book is of tremendous use if you plan to master C++ standards, short of reading the standards itself—which in itself is actually a pretty interesting reading, though I’ve never managed to read more than 5-6 pages without falling asleep []
  2. []

emacs 81×70

Saturday, November 8th, 2008

Recently, I started to rethink my workflow. I used to work with emacs occupying 80 columns and 2/3 of the screen vertical space, with another 1/3 below it used for a command line terminal to execute builds and tests. After the rethinking, I’ve settled with 81×70 in-terminal emacs (emacs -nw). By 81×70, I mean the dimension setting in my Mac that makes a terminal with tabs stretch all the way from the top of the screen to the bottom (I forgot the exact terminal size in Ubuntu). It’s amazing how much I missed in the past by not extending the emacs terminal as long as it gets. With such a big space, I can visualize code much better (well, it has never been a problem before, but being able to see more code does apparently boost my confidence in my internal brain’s RAM).

Why 81 columns? Because I like to keep my code at 80 columns width. Yes, so why 81? Well, in emacs, if you type exactly 80 characters in an 80 by x terminal, the last character will fall off to the next line as the last column is used for the ‘\’ character indicating the line continuing in the next line. Having 81 by x gives me just enough space to type 80 characters. Any more and I’ll notice it falling off.

This setting works well for me in Ubuntu and Mac. I’ve tweaked my Mac fonts too. I’ve changed the default terminal font with Monaco 12pt., anti-aliased. It’s just wonderful (it’s the same font used in TextMate btw). Here is a sampler (the code in the emacs window is not mine; it’s someone’s extremely messy code I’m in the middle of cleaning up—stylistically—and soon rewrite, hopefully; there is a limit to messy code… Sigh).

emacs in 81x70 terminal window

emacs in 81x70 terminal window

Bonus tip: If you decided to code with good width limit (80 or 100 chars), you can tile several Terminal windows side-by-side. I’ve seen people with 4 terminal windows side by side in their kickass 30″. I have 2 emacs terminal side-by-side and another smaller sized terminal to run miscellaneous shell commands and scripts.