Phil Haack has suggested a great alternative to the captcha. Personally I hate captchas because they are annoying and hard to read a lot of the time. Phil’s idea would block spam just effectively and doesn’t involve an action by the user in fact the user doesn’t even know it is there (the way it should be).

The Invisible Captcha control plays upon the fact that most comment spam bots don’t evaluate javascript. However there’s another particular behavioral trait that bots have that can be exploited due to the bots inability to support another browser facility.

You see, comment spam bots love form fields. When they encounter a form field, they go into a berserker frenzy (+2 to strength, +2 hp per level, etc…) trying to fill out each and every field. It’s like watching someone toss meat to piranhas.

At the same time, spam bots tend to ignore CSS. For example, if you use CSS to hide a form field (especially via CSS in a separate file), they have a really hard time knowing that the field is not supposed to be visible.

I came an article by someone who has created a LINQ provider for Flickr. This will allow you to easily leverage Flickr in your applications using the power of LINQ.

LINQ provider for Flickr gives an easy way to query , add and delete Flickr photos. Here, I will give some sneak preview about how to use the provider to do different operations on Flickr, as if doing queries with SQL objects.

A little bit of Friday humor.

After a long loyalty to Mootools I could no longer ignore the huge potential Ext holds for my projects. I think I held out for so long because I was comfortable with the Mootools style and didn’t really have “extra” time to learn a new library.

Much to my surprise, Ext wasn’t too hard to learn and they have a great cummunity that are eager to help newbies like me out.

So I set to work playing with the controls and documentation and came up with an Accordion plugin that you can implement in 1 line of code.

You can download the package (which contains the full, uncompressed source code) or view the live demo.

Ext.onReady is the starting point of every Ext project. All you have to do is drop the below line in onReady and you are set to go (well, you have to reference the library and create your markup too).

var nav = new Ext.plugins.Accordion({
	container: "navigation",
	panels: "panels",
	width: 200,
	height: 200
});

The following example is a hack to combine CSS and JavaScript into a single file thus reducing page load speeds. This technique is based on the way current browsers react in certain situations and should be used cautiously.

Now, if you have by any chance worked on page load optimizations, you would know how costly each resource download is. The more the number of external resources that you refer to, the more the time it takes for the page load to complete.

Typically, web pages refer to many external CSS and JS files and hence incur many resource downloads. The advice from the PLT (page load time) gurus is to combine all the CSS files into one and all the JS files into one so as to reduce the number of resource downloads to just two. This, without any doubt, would help boost your PLT.

If you feel that two downloads still isn’t the best, I concur. In this post, we’ll look at a technique to combine CSS with JS and get the resource download count to one! I discovered this technique while desperately trying to improve the page load time for the pages in Microsoft Office Live. Read on…

The technique relies on how CSS and JS parser behaves in IE and Firefox.

* When the CSS parser encounters a HTML comment token (<!–) in CSS content, the token gets ignored.
* When the JS parser encounters a HTML comment token (<!–) in JS content, the token is treated similar to the line comment (//) and hence the rest of the line following the HTML comment token gets ignored

Look at the below JS+CSS code snippet…

<!– /*
function t(){}
<!– */
<!– body { background-color: Aqua; }

When the CSS parser parses the above content, the HTML comment tokens would be dropped and the snippet would become equivalent to the one below…

/*
function t(){}
*/
body { background-color: Aqua; }

As you can see above, the CSS parser will get to see only the CSS code and the script code would appear to be within the comments (/* … */).

In similar lines, when the JS parser parses the content, the HTML comment tokens would be treated as line comments (//) and hence the code snippet would become equivalent to the one below…

// /*
function t(){}
// */
// body { background-color: Aqua; }

As you can see above, the JS parser will get to see only the script code and the rest of the contents would look like comments.

You can refer to the above content in both the SCRIPT and LINK tags in your HTML page. For e.g.,

<link type=”text/css” rel=”stylesheet” href=”test.jscss” />
<script type=”text/javascript” language=”javascript” src=”test.jscss”></script>

Note above that both the tags refer to the same source and hence it would be downloaded once and used as appropriate (as CSS and SCRIPT).

To round it off, there is just one more thing that you need to take care of - the response content type - it needs to be set to */* in order to affirm to Firefox that the contents can be treated as anything as appropriate.

I found a nice article explaining how to ensure that the newest version of your javascript or css is always loaded and not using old cached versions. The example shows how to accomplish this in ASP.Net but this technique can easily be applied to any server side code.

<script type=”text/JavaScript ” src=”FileName.js?v=<%=AssemblyVersionNumber()%>”>

The attribute does nothing other than trick the browser into thinking that the .js file must be retrieved from server for new version instead of cached .

A very amusing example of why you need to sanitize user input.

Click to enlarge

ScottGu has announced Microsoft’s upcoming MVC framework. This is great news for ASP.Net. This will give developers a choice besides WebForms. I can wait for MVC. Handling my own postbacks is a fair tradeoff to get rid of __VIEWSTATE. This will also help developers who work with Ruby on Rails as well (RoR also uses a MVC style architecture).

What is a Model View Controller (MVC) Framework?

MVC is a framework methodology that divides an application’s implementation into three component roles: models, views, and controllers.

* “Models” in a MVC based application are the components of the application that are responsible for maintaining state. Often this state is persisted inside a database (for example: we might have a Product class that is used to represent order data from the Products table inside SQL).

* “Views” in a MVC based application are the components responsible for displaying the application’s user interface. Typically this UI is created off of the model data (for example: we might create an Product “Edit” view that surfaces textboxes, dropdowns and checkboxes based on the current state of a Product object).

* “Controllers” in a MVC based application are the components responsible for handling end user interaction, manipulating the model, and ultimately choosing a view to render to display UI. In a MVC application the view is only about displaying information - it is the controller that handles and responds to user input and interaction.

One of the benefits of using a MVC methodology is that it helps enforce a clean separation of concerns between the models, views and controllers within an application. Maintaining a clean separation of concerns makes the testing of applications much easier, since the contract between different application components are more clearly defined and articulated.

The MVC pattern can also help enable red/green test driven development (TDD) - where you implement automated unit tests, which define and verify the requirements of new code, first before you actually write the code itself.
A few quick details about the ASP.NET MVC Framework

I’ll be doing some in-depth tutorial posts about the new ASP.NET MVC framework in a few weeks once the bits are available for download (in the meantime the best way to learn more is to watch the video of my Alt.net presentation).

A few quick details to share in the meantime about the ASP.NET MVC framework:

* It enables clean separation of concerns, testability, and TDD by default. All core contracts within the MVC framework are interface based and easily mockable (it includes interface based IHttpRequest/IHttpResponse intrinsics). You can unit test the application without having to run the Controllers within an ASP.NET process (making unit testing fast). You can use any unit testing framework you want to-do this testing (including NUnit, MBUnit, MS Test, etc).

* It is highly extensible and pluggable. Everything in the MVC framework is designed so that it can be easily replaced/customized (for example: you can optionally plug-in your own view engine, routing policy, parameter serialization, etc). It also supports using existing dependency injection and IOC container models (Windsor, Spring.Net, NHibernate, etc).

* It includes a very powerful URL mapping component that enables you to build applications with clean URLs. URLs do not need to have extensions within them, and are designed to easily support SEO and REST-friendly naming patterns. For example, I could easily map the /products/edit/4 URL to the “Edit” action of the ProductsController class in my project above, or map the /Blogs/scottgu/10-10-2007/SomeTopic/ URL to a “DisplayPost” action of a BlogEngineController class.

* The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and .Master markup files as “view templates” (meaning you can easily use existing ASP.NET features like nested master pages, <%= %> snippets, declarative server controls, templates, data-binding, localization, etc). It does not, however, use the existing post-back model for interactions back to the server. Instead, you’ll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).

* The ASP.NET MVC framework fully supports existing ASP.NET features like forms/windows authentication, URL authorization, membership/roles, output and data caching, session/profile state management, health monitoring, configuration system, the provider architecture, etc.

Eric Woods has put together a great article (part 1 of a series) on some of the most common design mistakes developers make. Hopefully this will help you avoid making some of these mistakes.

(1) Scoping Woes
Many projects end up being doomed to failure before they’ve really started, simply because their scope was wrong. The most common problem is the infamous “scope creep” where the scope of the system steadily increases as more and more people get their say. This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality. The converse problem is where scope is artificially limited (perhaps to meet timescales) and so the effectiveness of the system is compromised. Architects need to maintain a particular focus on scope problems that relate to system qualities. Does the system really need to be available 24×7x365? Or would working hours plus Saturday mornings be sufficient? It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation? Catching these mistakes early in the project will help to greatly increase the probability of success.

(2) Not Casting Your Net Widely
A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention. However there are often quite a few other interested parties who need to be involved. Consider people like auditors, systems administrators and DBAs, testers, helpdesk staff, the development team and so on. You’ll probably need the cooperation of a fair number of these people in order to successfully deploy your system and number of them may not share your enthusiasm for it! Think about searching for stakeholders in groups like acquirers, assessors, communicators (like writers and trainers), developers, maintainers, suppliers, support staff, system administrators, testers and end users. The sooner you can make contact with these groups and understand their interests and concerns, the better.

(3) Just Focusing on Functions
It goes without saying that a key quality of a system is what it does. People buy or build systems in order to perform useful work and so it’s crucial that the system does what people need it to do. However, a trap that many new software architects fall into is focusing entirely on a system’s functions without considering any of its other properties.

Unfortunately, while we do need to get the system’s functional processing right, this is rarely enough; unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful.

In my experience, an architect needs to focus on the type of functions that a system has to provide and must design a suitable framework that each of the individual features of the system can be slotted into during detailed design. The design of the overall framework has to take into account the kind of functions it will host (be they computationally intensive, data oriented, batch operations, interactive operations and so on) but crucially, it must also be capable of providing the right level of performance, allow the application to be secured, allow for high availability and disaster recovery, support operation and administration and so on.

In reality, if the system isn’t fast enough or is insecure, if it can’t be supported or changed to allow for new requirements, it probably won’t be used and may not even make it into production in the first place. Identifying and delivering on these non-functional requirements is a crucial part of the architect’s role.

(4) Box and Line Descriptions
At some point in the development of the system you will need to write something down to explain your ideas for the architecture of the system – in other words, you’ll need an architectural description.

The question is, how do you go about describing something as complex as a modern software intensive system? The approach that we’ve all tried at some point is the single, all inclusive, “boxes and lines” Visio diagram that tries to show everything. The diagram probably includes software modules and some interconnections, machines, network links, databases and data flow, some user interaction, perhaps some system monitoring and so on. If you’ve tried this yourself then you already know that it’s not a terribly effective approach.

There are two reasons why the huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean.

The first problem means that the diagram doesn’t work well for anyone, as everyone has to hunt through it for the information they are interested in. Infra-structure experts have to discern the machines, network links and infra-structure software from the whole, software developers have to try to work out what the software layering is, testers need to try to untangle dependencies from data flows. Each person is mentally creating their own subset of the diagram in order to understand it. The solution to this problem is to decompose your large diagram into a number of well-defined, non-overlapping views of the system such that each view addresses one aspect of the system structure (such as runtime functional structure, software module structure, data structures or deployment environment). This is a well proven technique and there are a number of standard approaches you can use to guide you in achieving this (see the Further Reading section).

The solution to the problem of ambiguity is to make sure that you use a well defined notation for your diagrams and to provide enough supporting text somewhere to make your intentions clear. UML is an obvious starting point, given its tool support and wide use, although quite honestly it’s not a very good architectural notation (although again see the Further Reading section for some guidance on how to use it effectively). For those situations where UML isn’t effective, you will probably design your own notation to represent your ideas. However, remember to clearly define what your notation means so that people aren’t guessing – different people rarely guess the same way!

(5) Forgetting That It Needs to be Built
It’s always very satisfying to create and prototype an elegant, sophisticated design for a new system and it’s always more interesting if we manage to use some novel new technologies and techniques along the way. However, when we do this, it’s often worth asking ourselves which stakeholders our new design is really serving – the answer may well be ourselves, first and foremost (and possibly the development team).

I’m not suggesting that we shouldn’t innovate or that all systems should use COBOL and VSAM but always bear in mind that your design needs to be built, tested and deployed in order for it to be successful. If the design or the technologies you use are too sophisticated or immature, then you may be jeopardising this.

Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working. The presence of any of these factors suggests that you need to tread carefully and make sure that you work with the development and test teams to minimise the risks.

Also bear in mind that your system needs to be installed, monitored and controlled in production. Sophisticated architectures can make all of this significantly harder and immature technologies often have weak monitoring and management facilities, even after their development support has been improved. Again, it’s a case of working with the relevant parties (such as system administrators and perhaps the vendors) to make sure that no one has any nasty surprises late in the day.

I read the first part of a great article on why inheritance is not the best way to implement things. I like the Jedi references in the explaination. Everyone needs a DarkHippo!

The difference between is-a and has-a relationships is well known and a fundamental part of OOAD, but what is less well known is that almost every is-a relationship would be better off re-articulated as a has-a relationship.

Bad

// bad
class Jedi {
    function drawSabre():Sabre { … }
}
class DarkJedi extends Jedi {

    function crushTownspeople():void { … }
}
dj:DarkJedi = new DarkJedi();
dj.crushTownspeople();

Good

// good
class Jedi {
    function drawSabre():Sabre { ... }
}
class DarkPowers {
    function crushTownspeople():void { ... }
}
class DarkJedi extends Jedi {
    // DarkJedi has-a DarkPowers
    public var darkPowers:DarkPowers = new DarkPowers();
}
dj:DarkJedi = new DarkJedi();
dj.darkPowers.crushTownspeople();