3G is Destinated to Failure

When 3G providers are launching the 3G services, I think that it will not success. The currently marketed feature of 3G is the video call. However, I would not use a 3G phone because of the video. First, the video resolution sucks. Second, I don't want the person (esp. girl) I am talking to know where I am.

Now the market shift the focus from the video call to video content. It won't work for me neither. First, why on earth I want to watch video on the street? Listening music or radio is OK but watching video? Nah...

Secondly, it is way too expensive. Well, bandwidth and information have their price but not for video entertainment. Moreover, as digital TV become more popular, there are a lot of free entertainment signals for the public already. If we could decode the signal with a TV box, why can't we decode it with a mobile phone?

Conclusion: 3G is destinated to failure

Dissection of Technologies in JavaScript RIA

In the last entry, I have summarized choices we have while writing a JavaScript RIA (or AJAX application). They are under these seven categories:

1. Communication Model
2. Communication Style
3. Push Communication Style
4. Transportation Protocols
5. Data Format
6. UI Rendering
7. UI Update Style

These categories are actually order in a particular user request:

1. Is it an asychronous or a synchronous?
2. Use iFrame or XHR?
3. Use iFrame or HTTP 1.1 chunked for push data?
4. Data is transmitted with HTTP, XML-RPC, or SOAP?
5. Data is returned in what format (plain text, HTML, JSON, Base64, XML)?
6. The data is the rendered UI or the data values for the client to render the UI?
   
7. Use innerHTML or use DOM to maniuplate the UI?

The combination of the technologies can be summarized in the following graph:

To make any design decision, we may highlight the nodes and paths in the graph in top-down manner. For example, in the case of original AJAX defintion, we may hightlight Asychronous, XHR, HTTP/REST, XML, and Client Side Rendering:

The UI update style is undetermined up to this moment. We can make a complete decision before sending the design to programmers. Designers and programmers may have different preference of AJAX approach. With this simple graph, designers can communicate and synchronize with programmers more effectively. The architect can also use the graph to generate the implementation blueprints for programmers to follow so that more maintainable code can be expected.

The way to JavaScript RIA is paved with good technologies

As we are working with the Shanghai team, we found that they have different concepts about JavaScript RIA (also known as AJAX). Hong Kong team tends to have a better structure and more graceful way to partition the layers. On the other hand, Shanghai team tends to have less structure but faster development speed.

This leads to the classical design question about the tradeoff between development time and maintenance time.

For this reason, I listed out all possible combinations of different technologies and styles so that we can make the design decision from the beginning of the design stage in the future. The explanations will be added soon. To summarized, they are:

1. Communication Model
• Synchronous
• Asynchronous (AJAX)
2. Communication Style
• iFrame
• XMLHTTPRequest (XHR)
3. Push Communication Style
• iFrame
• HTTP 1.1 chunked
4. Transportation Protocols
• HTTP / REST
• XML-RPC
• SOAP
5. Data Format
• Plain Text
• HTML
• XML
• JSON
• Base64
6. UI Rendering
• Server Side Rendering
• Client Side Rendering
7. UI Update Style
• innerHTML Substitution
• DOM Manipulation

Building a Source Code Generator II

Last article described the basic infrastructure of writing a source code generator. The design is now implemented in Codejen Framework and available in SourceForge.net.

Building a Source Code Generator I

Recall the following components to build a source code generator:

1. A model that describe your application - you don't need to define it yourself, you can use XMI or XML schema as the reference model. The only problem is how you parse them to the object model.
   
2. A template engine - Velocity or Freemaker are good template engines in Java.
   
3. Templates that corresponding to the model - Generate code Java, PHP, C#, etc.
   
4. A configuration of templates - There would be configurations for desktop app, web app, RIA, or web services, etc.
   
5. A parser that parse the configuration - If the configuration is an XML file, Apache's commons-digester library can help.
6. A driver to glue up everthing.
7. Optionally, a validator for the template is good - JavaCC or ANTRL for syntax validation. For the extreme, use a compiler to verify the correctness of the generated code.
   

The diagram on the left included the classes designed for #4 to #7.

• CodeGenerator - the parser of the configuration file and the driver gluing up everything.
  
• TemplateConfiguration - an list of template that can stores the properties specified in the XML file.
• Template - a class representing the state of a template.
• TemplateProcessor - processor that may perform validation or beautification of the generated code.

With this general source code generator, it can be adapted to use with other CASE tools (e.g. Visual-Paradigm).

Example configuration XML:

<profile>
<property key="asdf" value="1" />
<property key="templateDir" value="x ${asdf}" />
<template class="org.sf.codejen.test.TestTemplate" a="${templateDir}">
 <postProcessorFactory class="org.sf.codejen.test.TestProcessorFactory" b="jkl;" />
</template>
</profile>

The required attributes are

• profile/property - key and value
• profile/template - class
• profile/template/postProcessorFactory - class

All other attributes are optional depends on the class design.
Also, if you are familiar with ANT, you can use ${propKey} style to access the property value.

How to build a source code generator

1. A model that describe your application - you don't need to define it yourself, you can use XMI or XML schema as the reference model. The only problem is how you parse them to the object model.
   
2. A template engine - Velocity or Freemaker are good template engines in Java.
   
3. Templates that corresponding to the model - Generate code Java, PHP, C#, etc.
   
4. A configuration of templates - There would be configurations for desktop app, web app, RIA, or web services, etc.
   
5. A parser that parse the configuration - If the configuration is an XML file, Apache's commons-digester library can help.
   
6. A driver to glue up everthing.
7. Optionally, a validator for the template is good - JavaCC or ANTRL for syntax validation. For the extreme, use a compiler to verify the correctness of the generated code.
   

Web 2.0 is Just a Milestone

After reading some articles and blogs, I found that Web 2.0 is not really new thing. It's just a milestone that saying the internet has evolved into new phases. People are not working alone but collaborated. XML and HTTP make different platforms more integrated comparing to the DCOM and COBRA. Thanks to AJAX, web applications are almost as dynamic as desktop applications. Whenever you go, whereever your are. You can access the application with your electronic devices (mobile phone, PC, PDA, etc). No more deployment and update patches is need.

If Web 2.0 is a milestone, what else we can do with it? Just celerbrate and get back to work! Have we rearched the milestone yet? Not really! Let's work harder for it.

The Future of Programming

I share the same vision about programming with Microsoft. DSM will rule and MDA cannot dominate the market. So, does it imply programming will no longer exist if we define enough DSL? The answer is no.

There aren't "enough" DSL in the future. At least, there will be two camps of DSM tools, Microsoft (Software Factories) and Eclipse (EMF+VEF). For MS, sure it will be only .NET platform. For Eclipse, however, it will be for the whole all platforms. For different languages, UI, and DBMS. There are infinite combinations for us to define.

The future of programming is programming the DSL for user to define it's own application on the system specifications.

JavaScript Obfuscator

I have recently written an obfuscator for JavaScript in Java. It is available at:
http://www.shaneng.net/

It exploit some feature of JavaScript so that I don't need to understand the content of JavaScript. To start, the obfuscator just "blindly" replace the variables without leading dot (e.g. window.parent has the dot). Then, I managed to remove the comments. Later, it also encode character in the string literals into \uXXXX or \XXX format.

In the current version, I refactor it so that it is more managable. In the future, I would like to handle the source code with E4X syntax.

JavaScript: setInterval() problem

Have you been trying to write some class like this:

function y() {
  this.x = 0;
  this.start = function () {
      this.interval = setInterval(this.run, 1000);
  };

  this.run = function () {
      this.x++;
      debug(this.x); // or some other things you want to do
  };

  this.stop = function () {
      clearInterval(this.interval);
  };
}

You may attempt to refer the x in the run() function. However, in JavaScript, the scope of the function becomes the window after running setInterval() (or setTimeout()).

To solve the problem, the code be written like this:

function y() {
   this.x = 0;
   var self;

   this.start = function () {
       self = this;
       this.interval = setInterval(run, 1000);
   };

   function run() {
       self.x++;
       debug(self.x);
   }

   this.stop = function () {
       clearInterval(this.interval);
       self = undefined;
   };
}

Since using the self variable will create a cyclic reference, it should be cleaned up properly. Otherwise, the garbage collector of the script interpreter(s) which use(s) reference count will not be able to collect the instance.

Update (2009-03-29)
Thanks to the comment by dedogs, we could actually write the code like this without the cyclic reference:

function y() {
  this.x = 0;
  this.start = function () {
      var self = this;
      this.interval = setInterval(function(){ self.run(); }, 1000);
  };

  this.run = function () {
      this.x++;
      debug(this.x); // or some other things you want to do
  };

  this.stop = function () {
      clearInterval(this.interval);
  };
}

AJAX: XMLHTTPRequest Event Handling

Most of the XMLHTTPRequest uses the following implementation:

function run1() {
  xmlhttp = new XMLHTTPRequest();
  xmlhttp.onreadystatechange = processStateChange;
  ...
}

function processStateChange() {
  if (xmlhttp.readyState == 4) ...
}

The problem is, when you have many events to handle, the variable xmlhttp in run1 may have assigned to different instances by different functions (e.g. run2, run3, etc). If you rely on this code, no one can gaurentee that your code will run correctly.

The resolve this problem you can try to write the code in this way:

function run1() {
  var xmlhttp = new XMLHTTPRequest();
  xmlhttp.onreadystatechange = function() { ... }
}

If you insist to write the handle in a function, here is another style of writing it:

function run1() {
  var xmlhttp = new XMLHTTPRequest();
  xmlhttp.onreadystatechange = function() {
    processStateChange(xmlhttp);
  }
  ...
}

function processStateChange(xmlhttp) { ... }