Monday, October 15, 2007

Moving to .Net 3.0/3.5

WF, WCF, WPF, and LINQ are going to be pushed by Microsoft. To be honest, the framework is just unbeatable by other current programming frameworks. Adobe has the equivalent technologies but they are more on documents only and have not fully integrated together yet. Open source camp is too scattered. It is hard to imagine it can response quickly to the .Net 3.5 wave.

Tuesday, June 19, 2007

Sunday, June 17, 2007

Thoughts on Silverlight

Microsoft is pushing Silverlight so hard these days. As the official release is approaching, the adoption rate will be low if it use the same installation method of beta. A better off will be Flash like installation. Everything can be installed automatically and no restart of browser. The real frictionless environment.

I could provision it could be a big success when Microsoft solves this particular problem.

Thursday, May 03, 2007

Software Design Corrosion

No matter how good is the design of a piece of software, the design corrodes proportional to the the time gathered the user requirements. As time goes by, the user requirements change. The design of the software become less oriented to the new user requirements. The programmers may feel the limitation of the original design. However, they have the stick with the design and trying to change the fewest thing to accomplish the goal - the user requirement.

Hence, cheap hacks and workarounds are introduced. These hacks and workarounds may not hurt the maintainability in short term. However, since the design may not consider the effect of these hacks and workarounds, some other factor may get affected. For example, security may get compromised.

Take XmlHttpRequest as and example, it is designed for retrieving XML or simple text data. However, people use it to retrieve JSON that allows executable JavaScript.

Even large enterprise applications are vulnerable to the corrosion. The architecture design of enterprise application is usually coarse grained due to the time and resource limitation in the business world. Hence, hacks and workarounds are very easy to introduced among a team of programmers. Since enterprise applications are large, it is not quite possible for the architects or the analysts to review the code. Thus, the design corrosions are easily occurred.

There is no easy solution to the phenomena. Adding extra resources may slow down the effect. However, it cannot be completely removed.

Tuesday, April 10, 2007

Some Thoughts on Ruby

Ruby on Rails (RoR) seems very promising. However, not every web applications are CRUD applications. It is very easy to have the similar frameworks to implement it in Java or PHP. Even Ruby got the attention now, it will like all buzz diminishing at the end.

Let's see how I reach the conclusion from the successful platform.

Java
  1. Cross-platform
  2. Language of C family
  3. Huge number of libraries
  4. Backed by big corp
  5. Excellent Javadocs API
  6. Nice IDEs
.Net
  1. Support multiple languages
  2. Medium size .Net libraries but able to talk with legacy DLLs
  3. Backed by big corp
  4. Very nice MSDN
  5. Very nice IDE
PHP
  1. Cross-platform
  2. Morph from C family
  3. Large size of libraries
  4. Interactive PHP Manual (i.e. users can add the comments providing examples, tricks, etc)
To make a language/platform success, the language family, the size of libraries, and the documentation are very critical. Perl, for example, does have the whole CPAN libraries and quite well documented. However, the cryptic syntax scares off so many people. That's how PHP became more popular than Perl.

Java and .Net have the advantages because they are backed by big corporations and they have the resource to get the documentation written nicely. PHP does not have the financial advantage but it starts off very simple at the beginning. Documentation can be written and updated bit by bit.

Now, Ruby is not a language belongs to C family. I believe that the size of the libraries cannot be larger than CPAN. The library should be well written. However, it does not have a nice IDE. It does not have big corporation support. It only has a framework letting programmer to get the easy job done. As I mentioned in the first paragraph, the framework can be written in Java/PHP easily. It is not a good advantage. Is it going to success?

Alternatively, I think Java and server-side JavaScript (Rhino engine) can have the synergy. Simply speaking, RoR reads database and generates the data model, the controllers, and the views. Java can read the database (from MySQL to Oracle) to generate the data model and the controllers in JavaScript (for the sake of flexibility) and use a template engine (JSP, Velocity, Freemarker) to generate the view. Since ALL web programmers know JavaScript already, they can REUSE what they have already known. With some simple documentation to let the programmers know how to get the job done, it is very easy to get adopted.

P.S. JavaScript success factors:
  1. Cross-platform
  2. Language of C family
  3. Large size of libraries (esp. after the AJAX boom)
  4. No official documentation but references are just a click away from the search engine

Thursday, March 22, 2007

Screwing up HTTP Session for Servlet/JSP

Prerequisites:
1. Browsers under Mozilla project (e.g. Firefox, SeaMonkey)
2. Enable cookies
3. Tomcat (probably all Java web containers)

Procedure:
1. Write a page that use back-slashes as the directory seperator (e.g. http://www.abc.com\app\page.jsp)
2. Include this page with absolute path in all pages

Why:
1. The browser encode back-slashes as %5C. So, http://www.abc.com\app\page.jsp will be encoded as http://www.abc.com%5Capp%5Cpage.jsp
2. The browser tries to look up the cookies for the domain. However, the browser think that the domain name is www.abc.com%5Capp%5Cpage.jsp instead of www.abc.com
3. The browser cannot find the cookies for the domain. So, it does not send the cookies to the browser.
4. When cookies is enabled, Java Servlet and JSP uses it to store the session ID
5. Since the cookies was not found in the request header, the web container creates a new session and send to session ID with Set-Cookie header.
6. The browser uses the new session ID for the next request.
7. As a result, the web container creates new session for each browser request and the sessions are screwed up.

What about other browsers? I think IE is smart enough to replace all back-slashes to slashes before it does further processing. I don't know about others though...

You may want to ask why you would use back-slash. My answer is "No, you may not but your staff or your outsource partner may." In a workflow engine we are studying, we found the following JavaScript:
document.write("<iframe src='<%=request.getContextPath()%>\\app\\page.jsp'>")

My colleague asked for help about why the session does not work in Firefox. Since the code was written by different parties, we know nothing about the workflow engine. I alone used 6 man-hours to fix the BUG. I think I know fairly well on HTTP and Java Servlet. I tried many possible solutions like finding the HttpSession.invalidate(), session.removeAttribute(), appending the jsessionid, etc. Finally, I used a packet sniffer to dig out the pattern that changes the jsessionid cookie and recognize the weired %5C URL in a GET command.

Monday, March 05, 2007

Adobe Flex Push

There are ready to go assemblers in FDS samples application provided for you to develop your own Flex application with FDS. It is quite impressive that when a client update a piece of data, the FDS can synchronize the data to other Flex client without extra coding. However, what if you only want to push some changes to the client?

Calling update in assembler may be a good option. Using the DataServiceTransaction could be better:
DataServiceTransaction tx = DataServiceTransaction.begin(false);
Rate rate = ... // get the rate from some streaming data source

// do any necessary calculation
tx.updateItem("fds.rate", rate, null, null);
tx.commit();
This snippet should get the job done on the server side. On the client side, you need to handle the FDS message:

<mx:script>
public function handleMessage(event):void {
if (rate.id == event.message.body[2].id) {
rate = event.message.body[2];
}
}
</mx:script>
<mx:label text="{rate.value}"/>
<mx:dataservice id="dsRate" destination="fds.rate" message="handleMessage(event)" />