I have planned originally to publish links to interesting articles and websites on daily basis. I have a title for such posts with an unoriginal name: "Daily Links". With the blog more than 2 months old I have gained some experience and insights, one of which is that I just can’t publish new links every day. I simply don’t go through enough links to have a daily list. “Daily Links” name needs to change.

I see two possibilities – aim to publish links on (by) weekly basis, or publish one link at a time but go deeper into what an article or website is about. I'm leaning towards the first solution and that's what I was doing anyway. I'm going to rename the posts. I guess "Weekly Links" would be closer to the truth:) , but I want it to be original. I've came up with "Turns of liquid maze". I will let you all decide what that means for you :) Maybe sometime in the future when I won't have anything to write about I will go into what it means for me.

If you have critique of the name, or have any ideas why “Turns of liquid maze” is inappropriate, please feel free to share them and I will take your advice under consideration.

Without further ado.

Web development

• On having layout - An article that goes deep into how IE rendering engine works, why IE often incorrectly handles CSS and possible ways to work around the problem. It provides a very good foundation for developing IE-compliant web pages that don't behave unexpectedly. (via http://dean.edwards.name/weblog/2005/06/layout/)
• JavaScript Benchmarking (XSLT) - XSLT performance is analyzed in IE and Mozilla Firefox. IE wins easily even using an older version of MSXML. On the side note using pure JavaScript to generate HTML and manually inserting it into web page is much faster than XSLT in Mozilla, but slightly slower in IE.
• Benchmark – style vs. classname - Another article on web browser performance. Changing element's className is faster than actually going in and changing element's style.someThing. The only exception is Safari, which likes style change better than className change.
• JSAN - JavaScript Archive Network. Repository for OpenSource JavaScript code. It contains a lot of JavaScript code so it's a good place to start looking for something you might need.
• Best Practices: Implementing JavaScript for rich internet applications - A list of JavaScript development practices. All of them are common sense, but having them in front of your eyes will probably lower chance of not following them (you always follow common sense anyway, right?:) ) (via http://domscripting.webstandards.org/?p=19)
• Migrate apps from IE to Mozilla - A list and description of differences between IE and Mozilla DOM API. There are a lot of them and this article touches on most of them (I'm not sure if anybody can describe them all. There are just too many.) The article should be of interest to any web developer, not only those migrating from IE to Mozilla.

.NET

• Castle release (Download) - Old news by now, but still important and worth mentioning. A lot of bugs were fixed and some interesting features introduced.

Last weekend I went to Chicago and on my trip I got a chance to read some of Code Complete (2nd edition). This is a wonderful book that digs deep into what software development is and how it can be improved. Most of the book is concerned with the actual coding. First few chapters, though, cover software process from a higher level of abstraction and talk about other development activities (requirements analysis and design).

The book also shows how metaphor use can improve understanding of the problem at hand. The mind usually does a better job at handling something familiar than at handling something completely new. Chapter 2 goes into what software development is and what it is like. Is it like writing a letter? Or is it more like building a house? Well, as I was on my way through Chicago, I got stuck in traffic and while I was waiting for the cars to move I had an idea that city planning and development is similar to software development in many ways.

Initially bad city design can cripple the city and make parts of it as hard to maintain as poorly designed code. A city is usually separated into various areas (zones): commercial, industrial, housing. Software is often split into several areas (modules) as well: user interface, data access, business logic, etc. There’s even correlation between city services, police for example, and aspect oriented development (logging and errors handling aspect come to mind), but I feel I’m pushing the metaphor too far:)

Roads is the way for the city resources to flow from one area to another (people going from home to work and back, material going into factories and products coming out). Another way to look at it: roads (as well as electrical lines, etc.) are the pipelines for the different areas exchange various types of information. Their design must be flexible and must take into account future changes when various areas grow. In software interfaces must be just as carefully planned to ensure that any future class modifications will not affect the whole system.

I’m not sure if this analogy has real life use. I will keep it mind and try to get a feel for using  it to come up with better software design or maybe even improve my software development process (which, probably, can use some improvement:) ).

The RemoteContent helper I released on Monday had a flaw. It pulls and displays the feed correctly, but the feed by default has escape characters (HTML-encoded). This resulted in any HTML in the feed to be shown as HTML source code and not as an actual web page.

I fixed the problem by utilizing System.Web.HttpUtility.HtmlDecode method. After the transformation takes place it's is decoded.

By default the feed will get decoded, but you can always disable decoding by calling $RemoteContentHelper.TransformFeed( "feedUrl", "transformation.xslt", false )

Get the new version of RemoteContentHelper here.

I’m finishing up the website for my JavaScript UI project and the only thing left is to add some content and fix the style a little bit. I’m also enjoying flexibility that Monorail provides. For example, I decided to publish announcements on the front page and to pull them from CS forums. CommunityServer is a separate application so it’s hard to access it directly to retrieve the posts, but forums expose an RSS feed with all the latest messages. With some inspiration from the CS community and Cuyahoga (which provides remote content module) I decided to pull announcements via RSS and transform them into HTML using XSLT.

Surprisingly it was easy to write the helper since .NET XML classes already support working with URLs and loading XML documents from remote locations. All I had to do was to write code to load XSLT from the local directory and spit out the transformation results. For those interested to see implementation I’ve uploaded the files together with an XSLT file to transform CS forum feed into HTML - RemoteContentHelper.zip

If you’re developing with Monorail and nVelocity adding the feed is really simple. Just add the following line to your template where you want the feed to appear:

$RemoteContentHelper.TransformFeed( "feedUrl", "transformation.xslt" )

Please feel free to leave a comment if you have any questions or remarks.

I was reading Castle IoC reference manual and realized something that I have not thought of before. By using IoC facilities it’s really easy to implement certain patterns, especially since Castle is really designed to be extensible. In reality, some of the patterns are already implemented and supported. For example by default all components in the IoC container are of the singleton lifestyle. The beauty of the framework is that it’s really easy to change the lifestyle of the object to, for example, transient (new component per request), without having to change the class code. Since components are singletons by default, reusability of the objects is encouraged. This should save some memory and execution time.

Another cool feature of the Castle is that it’s really simple to configure components. In the past, I might have had to either write my own class to extract configuration from the .config file or use some configuration framework, like Nini. Now my components will automatically initialize with the supplied configuration. I might still have to use Nini when a complex configuration will be required and application will need to save it (save user options for example). But the whole config deal is going to be really simplified.

The elation of starting a new blog has passed as it seems I’m not posting as often… something to fix in the near future.

I'm going write about Monorail a little bit more (see my previous post).Web development with Monorail is easy, although it takes some time (not much) to wrap one's head around the way the code is written. Adding new feature to the website is just as simple as having those features in the original design. I enjoy working with it and I can focus on adding content instead of thinking about how to follow DRY (Don’t repeat yourself) principle as I had to sometimes in ASP.NET (as I’ve mentioned before I’m lazy).

In my opinion benefits outweigh the disadvantages and so I’m sticking with it.
Benefits:

• Faster development
• Enforces good design practices resulting in easy to understand and maintain code
• Responsive community (ASP.NET has a bigger and just as responsive community, so getting help there can be easier if you know the right people)
• Support for simple template engine (in addition to “.aspx”)

Disadvantages:

• Lack of documentation (there are tutorials, but not everything is covered)
• Learning curve
• Template engine (a separate dependency project on which Monorail relies) is out of date and is not being worked on (there are problems in it that weren’t fixed since 2003, although people are starting to talk about working on it to fix the bugs at least)
• Small community
• No third party support (no controls or anything similar to the ASP.NET world, but usually it’s not important)

I’m sure I’ve missed something so feel free to leave a comment and I’ll update the post. The point though is that Monorail benefits are big while disadvantages are small.

The only concern I have is that community is still very small. If for some reason developers would have to quit (like people quit working on nVelocity) the project could die easily. I would be left with code for the framework that is not maintained, but I doubt this will happen. All developers appear to be from different parts of the world so it’s highly unlikely for all of them to leave simultaneously. Community is also growing and more and more people are starting to contribute. In the end, I really think that the project can succeed if the authors would pull it together, update documentation and create a professional website in addition to wiki.