Silverlight Coding Contest

A few days ago, ComponentArt started a Silverlight coding contest. If you submit your Silverlight applications for evaluation by the "Esteemed Panel of Judges" you can win a prize of $10,000 or get free licenses to ComponentArt products if you happen to be one of the two runner-up. Much more details available at the following sites:

 

- http://www.componentart.com/ - http://www.componentart.com/community/competition2009/ - http://www.componentart.com/BLOGS/miljan/archive/2009/06/22/10-000-for-the-best-silverlight-app.aspx

BTW--I'll be one of the esteemed judges :)

Posted 02 July 2009 05:30 PM by despos | no comments
Filed under:
DataForm Control in Silverlight 3

Silverlight 3 comes with a new control—the DataForm control—through which you can design a view model around a data type in what actually results to be a specialization of the MVVM pattern. The DataForm control is also smart enough to analyze the public properties of its data source and generate some UI accordingly. The DataForm will use text boxes for string properties, check boxes for Booleans, and a date picker control for dates. If bound to a collection of objects, it will also display a navigation bar.

Read the full (part I of the) story on DotNetSlackers.com.

Posted 02 July 2009 05:25 PM by despos | no comments
Filed under:
ASP.NET 4.0: more control on viewstate management

ASP.NET is a stable and mature platform for building Web applications. Personally, I can hardly imagine a revolutionary set of new and  compelling features to be added to it. So what's new in ASP.NET 4.0? Beyond AJAX stuff, there are some interesting enhancements in the Web Forms area. As I see things, all changes in ASP.NET 4.0 can be catalogued under the label of "more control". You get more control over viewstate, script references, ID generation, output caching and even, but in very limited form, over HTML generated by some controls.

Let's briefly focus on the viewstate extended control. In ASP.NET, the viewstate is optional but it is enabled by default. In addition, the viewstate is not simply a way of reducing your bandwidth. It is rather functional to the implementation of the Web Forms model. So just dropping the viewstate in a new version of ASP.NET is simply out of question: either you get a new ASP.NET platform such as ASP.NET MVC or you stick to Web Forms with the viewstate on board.

However, there's a subtle aspect of the viewstate management that has been fixed in ASP.NET 4.0. I said fixed because, well, from my perspective it had to be considered a bug-by-design in previous versions.

All server controls (the Page class derives from Control) have the EnableViewState property through which you can disable the viewstate for that control. What is little known ais that the EnableViewState property is ignored for child controls. In other words, if you take the default value (true) for the page, then whatever value you assign for it to any controls in the page... it is ignored. You can have have TextBox1.EnableViewState = false but still have the text box to read/write state from the viewstate if the viewstate is enabled at the page (or container) level.

This will change in ASP.NET 4.0 thanks to the new ViewStateMode property.

This property indicates whether the viewstate for the control is enabled|disabled|inherit. You can use the ViewStateMode property to enable view state for an individual control even if view state is disabled for the page. This is the great news. Finally, you can now disable the viewstate on the page and decide which controls will have it enabled (opt-in). In earlier versions you could only do the reverse (opt-out): enable the viewstate and then decide which controls will not support it.

 

 

 

Posted 13 June 2009 10:04 PM by despos | 7 comment(s)
Filed under:
Give a chance to prediction

It is mostly about AJAX applications, but it applies well to any scenario where a smart/rich client is present. I'm talking about the "Predictive Fetch" pattern. Quite simply, it refers to the idea of preloading data that the current user can request in a few moments. It relates to caching--more, it is often implemented through caching--but it is a different kind of thing. It is actually a strategy for certain pieces of the user interface, where you need/want to exceed expectations and provide an output close to (if not under) the threshold of human consciousness (about 10 ms). Immediate response.

Like many other AJAX-related things, it is mostly a matter of tradeoff. You are guessing, that's what you're doing. And the guess can be right or wrong. If wrong, you have just wasted some resources and CPU cycles on both client and server. If right, you astonish users. BUT... because you can hardly afford pre-fetching from every possible use-case, then the open point is: what the user reaction/feelings when one feature is sooo fast and another similar one is slower?

The full story on DotNetSlackers.

Posted 21 May 2009 10:04 AM by despos | 1 comment(s)
Filed under:
Testability vs. Testing

The first time I heard the expression "unit testing" at a .NET conference was--if memory serves well--back in 2004. Since then, it took probably a couple of more years for the theme of "unit testing" to gain due visibility in the .NET space. I can't mention a date when I heard the word "testability" instead. And still in articles, blogs, and conference talks the prevailing term is "testing". Not that no conferences in the world had the word testability pronounced lately, but it never happened to me to attend a talk or something where I could hear it--maybe I just go to the wrong sessions and miss a lot of great events :)

Seriously, I feel that the word "testing" is used much more frequently than the word "testability". And I do believe that for developers and, especially, architects testability is a far more important aspect. In first place, testability is one of the required attributes of any software system according to the ISO standard for software architecture. Second, testability has a deeper impact than testing on the quality of the code you write. What's testability?

In our book "Architecting Applications for the Enterprise" Andrea and I write it as follows:

A broadly accepted definition for testability in the context of software architecture describes it as the ease of performing testing. And testing is the process of checking software to ensure that it behaves as expected, contains no errors, and satisfies its requirements.

In a nutshell, testing returns you a working application; testability returns you a better designed code. Honestly, can you spot any difference between a unit-tested piece of code that works and a piece code that just works (maybe tested by simply poking around)?

With the excuse of letting you do that cool thing called unit-testing more quickly and effectively, testability silently drives you towards a much better design of the code with plenty of SoC, dependency injection, low coupling, high class cohesion, and minimal responsibilities for classes.

Ultimately,design for testability means applying a software contract (code-contract in .NET 4.0) to classes and methods and keep classes cohesive, loosely coupled, and with dependencies clearly listed. Once classes are testable, unit-testing them is really a little detail.

 

 

 

Posted 13 May 2009 11:26 AM by despos | 3 comment(s)
Filed under:
Things to say

Two interviews out at about the same time. One is on mythical DotNetRocks; one is on SodThis--brain burps for the tech savvy. Love the payoff :)

 Enjoy!

Posted 03 May 2009 09:33 AM by despos | no comments
Filed under:
AJAX Architectures Condensed

One thing is using AJAX to dynamically refresh a small piece of a single page; all another thing is designing a whole presentation layer to be partially refreshed in every possible operation against the server. An individual feature can be happily and nicely coded using a smart piece of JavaScript; a whole Web presentation layer will cost you a lot more if done entirely in JavaScript. And from scratch.

Sure, new productivity tools are created every day (from the popular jQuery library to the upcoming ASP.NET AJAX 4.0 framework), but the most effective way of adding AJAX to applications continues to be the subject of research and begins to look like the Holy Grail of Web software.

I just published an article on DotNetSlackers, that summarizes the options you have when it comes to AJAX architectures. It is an excerpt from Chapter 3 of my latest Web architecture book mentioned in this recent post of mine.

Posted 17 April 2009 04:40 PM by despos | 7 comment(s)
Filed under: ,
A lovely couple (of architecture books)

It was brought to my attention that there's no way to have a (free) look at the TOC of Microsoft .NET: Architecting Applications for the Enterprise other than holding the book in hands and flip through pages. Sorry about that, this post is to make up for the omission. There's no reason and no intention to keep it secret :) Here it is: 

  1. Architect and Architecture Today
  2. UML Essentials
  3. Design Principles and Patterns
  4. The Business Layer
  5. The Service Layer
  6. The Data Access Layer 
  7. The Presentation Layer

The book develops its content more in terms of general patterns than concrete technologies. It is, however, concretely bound to the MS platform and it is not hard to recognize products and technologies behind the scenes. At the same time, it discusses other mostly open-source alternatives that fit nicely in the .NET stack.

Mid April 2009 is also the release date of the Web counterpart of the architecture book. I'm talking about Microsoft ASP.NET and AJAX: Architecting Web Applications, always from MS Press. Below, you find the TOC. I particularly recommend chapter 3 where I generalize most common approaches to AJAX today coining two (new?) terms: AJAX Server Pages and AJAX Service Layer.

  1. Under the Umbrella of AJAX
  2. The Easy Way to AJAX
  3. AJAX Architectures
  4. A Better and Richer JavaScript
  5. JavaScript Libraries
  6. AJAX patterns
  7. Client-side Data Binding
  8. Rich Internet Applications 

Chapter 6 and chapter 7 contain concrete stuff about AJAX patterns with a lot of references to existing frameworks. Chapter 5 doesn't miss some jQuery coverage.  Finally, Chapter 8 is about programming the Silverlight 2 model. Nothing on animation and graphics but everything a .NET developer/architect needs to know.

Posted 16 April 2009 08:15 PM by despos | 9 comment(s)
Filed under:
Web Forms vs. ASP.NET MVC

Probably I'm a bit late to the party, but as I gain confidence with ASP.NET MVC I feel I have my cents to share :-) 

ASP.NET MVC is not the anti-Web Forms and Web Forms is not the anti-pattern of ASP.NET development. ASP.NET was created 10+ years ago and in the late 1990s the MS platform was VB-oriented. So it was a natural choice to design ASP.NET as a stateful framework over a stateless medium--the Web. Many of the hot features in ASP.NET (postback, viewstate, forms authentication/authorization, server controls and abstraction over HTML) were eagerly welcomed by the community because they were time-saving facilities just implementing common features that everybody would have aboard.

Over years, MS probably failed drawing Web people attention on architecture and software design. There was an interesting attempt made with the Web Client Software Factory to implement MVP and workflow-based page navigation in Web Forms pages, but that turned out to be too far complex. At least, in my opinion. So in some way instead of driving Web Forms towards a better design it seemed preferable to introduce a new framework on the wave of the success gained by RoR and MonoRail. To many people, ASP.NET MVC looks like the new way to go and the only way to achieve SoC, testability, better design.

For sure, ASP.NET MVC is a "new" ASP.NET designed ten years later looking at the current state of the industry and evolution. Comments on Web Forms vs. ASP.NET MVC are often biased and stuffed with pieces of personal experience that is elevated to the rank of absolute, objectives facts.

The table below lists my top-ten undisputable facts about ASP.NET MVC and Web Forms. These are facts--everything else, I believe, are opinions. And like all opinions they are fully respectable. At the end of the day, Web Forms and ASP.NET MVC is like car or motorcycle and ... it's up to you, your skills, your education, your attitude, and your project requirements.

  1. Web Forms is hard to test
  2. ASP.NET MVC requires you to specify every little bit of HTML
  3. ASP.NET MVC is not the only way to get SoC in ASP.NET
  4. Web Forms allows you to learn as you go
  5. Viewstate is not the evil and can be controlled/disabled
  6. Web Forms was designed to abstract the Web machinery
  7. ASP.NET MVC was designed with testability and DI in mind
  8. ASP.NET MVC takes you towards a better design of the code
  9. ASP.NET MVC is young and lacks today a component model
  10. ASP.NET MVC is not the anti-Web Forms

On this topic, an article on MSDN Magazine is coming out in the July 2009 issue. A Web architecture book is being published these days and I'll start soon on the MS Press big book guide on ASP.NET MVC to be available towards end of the year.

 

Posted 11 April 2009 01:03 PM by despos | 17 comment(s)
Filed under: ,
iBrii is gaining ground

IBrii is a Web application that I've been working on in the past weeks. It's not my baby, and I'm not one of parents, but I can definitely be called as an hooked-on uncle of the baby :-)

So I'm even more proud of the work we did when I read what's on in the Wired How-to Wiki. IBrii is recommended as the best tool to replace and extend the just retired Google Notebook. IBrii is even more, tough. 

It is a virtual notepad through which you to write your personal notes, organize and share them with your friends. Your personal notes can contain just everything you can find in the Web. And you can clip-and-share as you browse the net. IBrii is still a beta but is going to support documents (PDF, Office documents) and RSS feeds meaning that you can publish your notes of choice to your blog.

First read this, then rush to get your account today! You'll love it.

 

PS: Technically speaking, IBrii is a relatively simple ASP.NET application with a lot of jQuery to shape up the UI and calling into an AJAX Service Layer for server-side logic.

Posted 04 April 2009 10:19 PM by despos | 10 comment(s)
Filed under:
More Posts Next page »