Happy New Year 2009

Today is January 1st, 2009. The sun raises as usual, but there's a leap second added after GMT 23:59:59 Dec. 31, 2008. At that time spot, you might notice something like XX:59:60. XX depends on your timezone. If you are using Beijing time, it should be 07:59:60, and if you locate in central America, it should be 17:59:60.

Talk to foreigners (even aliens) in your language seamlessly

Proposal

Build an automatic translation mechanism into instance message system (and other Internet communication system), as if a simultaneous interpreter were there.

It would be exciting if you master three languages. However, one could not master all languages. Even if such an interpreter exists, hiring him/her would be expensive. Internet helps people communicate easily from every corner around the world, and if it were an even probability to talk to anyone on earth, the chance a talker speaks foreign language is much higher. If we have such an automatic translation system, as if a simultaneous interpreter is ready, negotiation should be much simpler.

The problem currently is that a machine could not translate as good as an average interpreter. Languages are not one-to-one mapping, and machines are not good at analyzing and choosing which words to use and in what order. And this is why interpret is still a career.

Whenever a computer is not good at something, we could try to train it in hope that it will eventually learns and masters it. The source of training material would be from thousands of millions of people. As in image recognition, tags from Internet users helps classify and recognize pictures a lot. If, in one day, computers could seamlessly translate one language into another, we would be happy that we no longer need to learn a second language, and we would be equally sad that we will never drive to learn other than native language.

Currently, machine translation in instance message system should be more than experimental, but at least it could provide some information which might be helpful to international talkers. And, have fun to laugh at silly computers.

File names you can NOT create on Windows

Try to create a file named NUL.txt on Windows XP, and you probably get an error message.

Many characters are not allowed for file names on Windows. This includes
< > : " / \ | ? *

Besides, many reserved device names should be avoided. This includes
NUL, CON, PRN, AUX, COM1, COM2, ..., LPT1, LPT2, ...

Also, using the device names unintended might raise security vulnerability.

Dimensional Modeling vs Interval Tree

The concept Dimensional Modeling is like the Interval Tree (Segment Tree). Both speed up queries by storing information at different levels. The difference is that in Dimensional Modeling, levels are defined by users, while in Interval Tree, levels are usually defined by a complete binary tree. Interval Tree usually solves problems on one dimension, but it could also be applied to 2D problems. One dimension is not a limit.

Quotes

Quoted

Quotes are widely used in scripting languages, including (but not limited to) Bash, SQL, Python, Tcl, Perl, PHP, JavaScript. However, there is no universal rule for quotes. Most languages support single quote (') or double quote ("), while others have their own quotes like triple quote (''' or """), or braces ({, }). When one should code in a combination of different languages, the quotes would definitely confues programmers, not mentioning variable substitution, regular expression, etc.

Different outputs in Tcl - Stdout vs Return Value

When both set a {hi} and puts "hi" echo a "hi" in an interactive tcl shell, what is the difference between them?

Clarification on "output"
1. standard output
puts command will output to stdout by default.

% puts "hello"

hello

2. return values
set hi {hello} has a return value hello and will echo back to user

% set hi {hello}

hello

To make things clear, look at this example.

% set ret [puts "hello"]

hello

% puts $ret

(blank)

So that the return value from puts is blank.

Compound statements
Let move on to compound statements.

% set a "hello"; set b "hello2"

hello2

This gives a single line of output from `set b`, and a and b are both set.

% puts $a

hello

% puts $b

hello2

Here's two lines of output from stdout.

% puts "hello"; puts "hello2"

hello

hello2

Importance
Why is this important? What if we would like to store a calculated value into variable a.

% set a [expr 3+3]

6

% puts $a

6

This is what we expected. However, if we wrote another version of expr that output the result into stdout.

% set a [set b [expr 3+3]; puts $b]

6

% puts $a

(blank)
We get nothing.

Generally speaking, it is not a good idea to print to screen from many functions. Because this would make the testing difficult, if not impossible. Usually, assert will compare the return result to expected result, while the output to standard output are ignored. Despite all that, we can still try to test function which output to stdout. The idea is to trap the stdout. This assert for stdout would look like this pseudo code:

procedure assertStdout (expected, command) {

  create out for this instance

  execute command > out

  flush out

  return expected == out

}

One trick is that if multiple assertStdout procedures are running, 'out's must be distinct in order to keep thread-safe.

The echo back of tcl might be of use, but it could confuse people with the output from within procedures. However, it is mandatory to distinguish them for a programmer. Other scripting languages like shell does not have such echo back, but that doesn't mean it is OK to output from many functions for them. Especially, for compicated software that requires a thorough test, standard out or output to file everywhere would definitely bring down the testing.

Snapshot in UI Testing

If you have experience in JUnit or other testing tools, you probably know the importance of setup and teardown methods. These two methods help build a testing environment. However, when it comes to UI testing, it is not the case. UI testing means taking a long time, boring, and random exceptions. What's more, every time an error occurs, which might be caused either by a typo or by the tested codes, the only solution is to start over again from the very beginning. This is boring!

If we could take a snapshot at certain points (which are called save points), we could easily get started from those points. It should be time efficient. It certainly save a lot of time otherwise wasted in setting up the environment again. What's more, you can benefit from reproducing some random errors. If a snapshot were taken just before it occurs, the error would probably show up again, which also helps reduce the number of bugs.

It is not too hard to implement such a system. There are various ways though. It can be implemented as a functionality of the testing tools, or it could be bounded with the help of underlying systems. One good candidate is the virtual machine. Most VMMs, including open source ones, have a similar function. Taking snapshot takes seconds to minutes, depending on the implementations of VMM and the size of the virtual machine. We could take multiple snapshots, and rollback to a certain one, and even make branches. Although making use of VMM might seem easier, it is harder, but necessary, to integrate the snapshot into the testing tools. Taking snapshot should be as simple as setting breakpoints in debug.