Jacksonville Developers User Group

My presentation slides from yesterday's Silverlight presentation are attached to this post.  Since this was a code walk-through session, I used the slides just to set the stage for key Silverlight concepts I was going to illustrate.  Therefore, pardon the (short) length of the presentation.

I hope that those who attended felt that their time was well-spent and they have learnt a couple of things.  Silverlight 2.0 Beta 1 is literally just 1 week old, so welcome to the bleeding edge of technology (LOL, attendees will know what I mean).

As was mentioned by the audience members, investing in learning WPF today is a good strategy to jump-start both Silverlight and future smart client software development efforts.  Personally, I am excited about Silverlight, and, if there's desire, I'll do many more presentations about it, significantly improving on the test release of my demo app.

Thanks to everyone who attended--quite a few new faces, I am looking forward to seeing you in future meetings.

I promise not to write a novel this time around, just a brief post with links to information that I found valuable during this past week...

Larry O'Brien, whose 'Microsoft Watch' column in SD Times magazine I follow closely, points out the fallacy of several fundamental assumptions of software development--the assumptions that, to use his words, "were gospel" just a few years ago.  The first victim is the superprogrammer productivity myth--you know, the one where a superprogrammer can code 20 times faster than a regular one.  According to Larry, there really is no data (i.e., no scientific studies with a fixed control group) supporting this assertion.  The superprogrammer axiom was popularized by Tom Demarco in his famous Peopleware book, and the chart below (respectfully borrowed from Larry's blog) laid the foundation for the belief that superprogrammers exist.  While the chart itself does point out that productivity levels vary between different programmers, it's hardly enough on its own to generate a religious acceptance around the concept...

The second axiom revisited by Larry was the exponential increase of costs in software development over time, as shown in this graph (again, Larry's property):

William Taylor and Polly Labarre point out in "Mavericks at Work" that a true maverick would take a commonly accepted state of affairs, disagree with it, challenge it, and create something remarkable.  Such was the case with Kent Beck, where he challenged the assumptions documented by the graph above with his Extreme Programming approach to software development.  Now, we have something more closely resembling this:

Speaking of Agile Software Development, Steve McConnell is convinced that soon we will no longer refer to that approach as "Agile"--it will be simply referred to as Software Development.  With South Florida's Architecture Group changing their name to "Agile," I have to concur.

Occasionally, I like to disturb the state of software engineering nirvana to force myself and those poor few who are listening to take a second look at the commonly accepted axiom or state of affairs.  Today, I'd like to go out on a limb and suggest a multibillion dollar strategy shift for Microsoft, and I only want 0.1% of all the moneys saved as a result of adopting my strategic suggestion.  So, here's my ambitious contribution to the world of software development this week:

Drop the VB.Net as a language and either build something that truly allows RAD of web and Windows-based apps, or put the savings into building a better Object-Relational Mapper, bringing functional languages to the masses, or donate them to a worthwhile cause.  A worthwhile cause is, of course, in the eye of the beholder.  Expanding Victoria's Secret fashion show is a very worthwhile cause, in my humble opinion.

There are three main reasons why I think that VB.Net should be going the way of the VHS tape: the language is too similar to C#, it is not even remotely "basic" anymore, and it has already served its purpose of giving VB6 developers perception that they weren't left behind during the migration to the .Net platform.

First, the abundant existence of web-based VB.Net to C# translators is a clear indication of extreme similarities between the languages.  I've used those translators on multiple occasions, and I understand that they may not be perfect, but they are not bad.  Because the languages have an almost identical set of features and are syntactically similar, I see no advantage in developing in one over the other.  But I see a great pain and the expense of managing the two separate development environments, having all the samples written in both languages, etc.

Second, VB.Net did not do to web/smart client development landscape what Visual Basic 1.0 did to Windows development.  If you had the painful pleasure of reading Charles Petzold's "Programming Windows, Fifth Edition" and if your mind works anything like mine, I bet on more than one occasion you thought "all these pages of C code just to display a window and process a few messages?"  VB 1.0 abstracted much of the code needed for drawing windows and processing messages, and the market for business software exploded as a result.  Unfortunately, VB.Net does not do the same for web development--you are still responsible for knowing quite a bit of (D)HTML, CSS syntax, and, of course SQL if you are working with the database.

Third, I believe that the reason VB.Net came into being was to offer what VB6 developers would have thought was a natural path towards building the next generation of applications.  On the .Net platform, of course.  With C# syntax being so Java-like, all the VB6 developers would have been hard-pressed to start using C# when you could potentially "write once, run everywhere."  That reason for VB.Net existence is no longer valid--most developers have bitten the bullet and upgraded their applications by now (or in the process of doing so), and they have come to appreciate the power of the .Net framework itself with all the tools it provides rather than just the VB.Net language.

So, if in the near future you see Victoria's Secret fashion show tripling in size and all the models having the "Your Potential. Our Passion." tattooed on their back, please feel free to send me a "thank you" card.  You will most likely find me in the islands, Lamborghini parked close by.

On the other hand, if you think that I have totally lost it after a recent head-bumping accident and I am totally missing the point with VB.Net, I welcome hate/constructive criticism mail as well.  Direct it to "echuvyrov at msn dot com".

"Learning WCF" uses an unexciting approach to explain technology for technology sake

In an effort to stimulate discussion and perhaps occasionally give people a golden nugget of information at the user group meetings, we are continuing with the book reviews.  This month I reviewed "Learning WCF" by Michele Bustamante.  The motivation behind reading this book was to familiarize myself with the WCF technology and determine its applicability to the projects that I am working on currently and my future endeavors.

WCF is an amalgamation of previous technologies--ASMX, .Net Remoting, Enterprise Services--all encapsulated in a set of grandeur specifications with catchy names like "contracts, bindings, endpoints" that will certainly bring billions of dollars in consulting fees.  Unfortunately, I was searching for ideas on how WCF can help me architect/develop distributed solutions that are better and more reliable than has been possible in the past.  Sadly, Ms. Bustmante's book was not the place for answers to my questions.

Based on 6 reviews, Amazon.com had this book at a 5-star rating, which gave me a reasonable expectation that it must be a good place to start my WCF journey.  My brain works best in a top-down decomposition manner, where I take the big picture, understand its place in the universe, and then break it down into smaller component parts.  The author takes a different, more of a bottom-up, approach by throwing a lab at the reader, then explaining what happened during the lab and what technologies the reader has learned.  I found this not to be very intuitive.

Main themes of the book are (please bear with me as I mainly recite the table of contents):

 -Chapter 1: Definitions: Services, hosting, endpoints, bindings, metadata and behaviors
 -Chapter 2: Contracts: Service Contracts, Data Contracts, Message Contracts
 -Chapter 3: Bindings and types of bindings: BasicHttpBinding, WSHttpBinding, NetTcpBnging, etc.
 -Chapter 4: Hosting Services: type of hosting (self, IIS, and WAS)
 -Chapter 5: Instancing and Concurrency
 -Chapter 6: Reliability and message queueing
 -Chapter 7: Security
 -Chapter 8: Handling exceptions and faults

On the positive side, the coverage of various topics is pretty in depth.  The author clearly has put in a considerable amount of time writing the material and code for the labs included.  Unfortunately, it is not written in a very exciting manner--no jokes about Microsoft, and, the biggest disappointment of all (!), Victoria's Secret fashion show is not mentioned even in passing. 

Generally, I felt that my time was not very well spent reading this material page-by-page.  Perhaps a better approach would have been to treat this book as a reference manual, working through the labs to solidify individual concepts on as needed basis.

Bottom line: "Learning WCF" is not bad as a "how to" reference on WCF, but definitely not a good source on "why WCF, when WCF, and what is most appropriate WCF configuration for a given business scenario."  This is "technology for technology sake" type of material, so if you don't like this approach, you are probably better off looking somewhere else.  2.5 stars out of 4.

Next month, I will briefly review "My Job Went to India: 52 ways to save your job" since outsourcing and relevance of software development in the future is something that's among my primary concerns.  I am extremely interested in the opinions of the audience regarding the book and the offshore trends in general.  I hope to see you there.

Quick:  if a square object inherits a rectangle object, what OO principle does this violate?

If your answer is Liskov Subsitution Principle (or Design by Contract principle), you can probably stop reading this now, since there is little new information for you below.  If, however, you are having trouble thinking about OO principles beyond encapsulation, inheritance, and polymorphism (which, arguably, can be classified as both features and concepts of object orientation) and would like to learn a bit more, read on.

To paraphraze Dr. Dobb's Architecture Portal, "poor architectural design is everywhere; the brilliant designs are very rare."  Obviously, lack of sufficient understanding of business processes is one major cause of poor systems design; but the other major cause is the lack of knowledge of OO principles.  I am guilty of producing a few designs that I would rather not take a second look at, but there's hope for me yet, as I try to be a bit better each time I do it.  Without further ado, let's get back to the square inhereting from rectangle.

For the mathematically inclined (or those who need a sleep aid), here's the formal definition of Liskov Substitution Principle (LSP for short):

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

In simpler terms, this means that it should be possible to use any subclass in place of its parent class.  To observe the violation of this principle when using a square class that inherits from a rectangle, think about a method testing the calculation of the area of rectangle.  Let's say it's defined like this:

public int testCalculateArea(Rectangle r)
{
 r.Width = 10;
 r.Height = 20;
 return r.Width * r.Height;
}

If an object passed in to testCalculateArea() method is a rectangle (not a square), the result of the execution of the method above is clearcut: 200.  However, if the object passed in to that method is a square, the result is not so obvious--should it be 100, 400, or 200?  There's a violation of LSP here, and the real answer is that the square object cannot be polymorphic with the rectangle object without violating LSP.

Open Closed Principle
Let's say we modify the testCalculateArea() method above like this:

public int testCalculateArea(Rectangle r)
{
 if r.isSquare()
 {
  return r.Width * r.Width;
 }

 else
 {
  r.Width = 10;
  r.Height = 20;
  return r.Width * r.Height;
 }  
}

Before the code could run, we would have to modify the original Rectangle class to include the method called isSquare().  Doing so would violate the Open Closed Principle (OPC), part of which states that classes should be sealed to avoid cascading changes to the existing clients of the code.  Another part of the OPC states that classes should still be open for extension and adaptation.  The easiest way to think about OPC is that public interfaces of the base classes should not be altered; but via sub-classing, addition of private fields/methods, and applying the Inversion of Control principle (discussed below), the classes can be extended.

Inversion of Control Principle
Also known as the "Hollywood Principle," the premise of the Inversion of Control (IoC) technique is simple: "Don't call us, we will call you."  The IoC is a well-established technique:  think about the callback functions that you may have registered with the remote, long-running web service to update the GUI upon the return of the data.  This change of control flow, where the web service calls into the GUI (like Hollywood calling me) instead of the standard GUI calling into web service and waiting for data (me calling

Hollywood for years and still not being able to convince them of my unrivaled artistic ability) pretty much sums up the IoC principle. This tried-and-true OO principle could enhance user experiences with an application, reduce the load on the servers, and it is used extensively in various frameworks.

Dependency Inversion Principle
Dependency Inversion Principle is really a fancy name for the simple statement borrowed from the GoF's "Design Patterns":  Program to the interfaces, not the implementations.  A more formal definition (borrowed from DDJ) could go something like this:

 -Higher level modules should not depend on lower level modules. Both should depend on abstractions (interfaces or abstract classes).
 -Abstractions should not depend on implementations.

There is really not much else to say about the Dependency Inversion, it's a simple, yet fundamental principle of OO design.

Single Responsibility Principle
Another one of the fundamental principles, Single Responsibility Principle (SRP) is best summarized by Martin Fowler who said that "there should not be more than one reason for a class to change," or the class should have a single responsibility.  If a class has more than one responsibility, it becomes more difficult to understand and reuse, because the responsibilities get coupled.  And just as described in Steve McConnell's Code Complete, this cohesion (AKA single responsibility) principle should apply at the method level as well.

According to DDJ, the challenge with SRP is getting the granularity of responsibility right.  For instance, should a business entity class persist itself into the database?  There are several opinions and patterns on that, including Martin Fowler's "ActiveRecord" patter where each business class wraps a database row.  But, there are several other authoritative statements that talk about separating the two concerns (business logic and persistence to the database).

The challenge with adhering to good OO principles is that the payback is not immediately apparent.  There's a certain element of faith that requires a bit of extra diligence on the part of designer/architect for a promise of easier maitenance, better reuse and better stability of the system.  But just like an artist trying to better him or herself with each stroke of the brush, applying these principles will, in time, give us the opportunity to paint a masterpiece that, in Geekland, will rival Dali's "The Persistence of Memory."

In my first ever blog post, I want to go ahead and get the mandatory milestone of any introductory programming course out of the way.  So, here it goes:

Hello, Blog World!

With that monumental accomplishment out of the way, I can focus on the subject of my recent mini-presentation to the Jax Architects users group, namely DLINQ and its potential impact on .Net application architectures.  The basic idea of my presentation, perhaps a bit stretched, was that with DLINQ and anonymous types in C# 3.5 it is easier and more appropriate to work with denormalized database tables in scenarios where high performance and availability are of topmost priority.  But let's start at the beginning and see how we can arrive at this conclusion...

LINQ (Language INtegrated Query) is the newest feature of .Net 3.5 Framework.  .Net Framework 3.5 is available as a separate download or as a part of Visual Studio 2008 (in Beta 2 as of this writing).  Without rehashing Microsoft's documentation, LINQ simplifies working with data, making querying and filtering lists of data a snap.  LINQ to SQL (also known as DLINQ) is a subset of LINQ and it allows easy access and manipulation of data inside SQL Server databases (only SQL Server databases, however, as of VS 2008 Beta 2).  Although many people refer to DLINQ as an implementation of Object-Relational Mapping (ORM) for .Net, I would say that a true Object-Relational Mapping mplementation would make the software developer completely oblivious to the existence of the database.  A true ORM allows a developer to create and use objects in code that automatically end up in the database without extra effort or knowledge of the database layer.  Since DLINQ does not do that (rather, it creates attribute-based mappings of SQL Server tables to objects in the special 'DataContext' conduit class), I would refer to DLINQ as the 'enabler of strongly-typed access to database data'.

To take full advantage of LINQ (and DLINQ), some prerequisite knowledge of new features in .Net 3.5 is required.  Those features are (see the attached presentation for my attempt to graphically explain them):

1.  Anonymous Types
2.  Object/Collection Initializers
3.  Extension Methods
4.  Query Syntax
5.  Lambda Expressions

Let's take a look at each one of these features in some detail.

1.  Anonymous types, in my opinion, is the most radical, powerful, and unusual feature in .Net 3.5.  In essence, an anonymous type allows us to define/shape strongly typed objects "on the fly."  For example, given the following declaration

 var strIAmAString = "I really am a string"

the variable strIAmAString becomes of type string, with all of the string methods invokable on this variable and available in VS 2008 via IntelliSense after its declaration.  'Anonymous Types' is Microsoft's reference to what has been known for a while as "duck typing" in other languages, such as Ruby.  Duck typing is best explained by paraphrazing the old saying, "if it looks like a string, acts like a string, then it must be the string."  The 'var' declaration above indicates that the type of the variable that follows will be derived based on its initialization, which must be present during the declaration of that variable.  Anonymous types cannot be used as method parameters, however, since the compiler needs to know the types of method parameters during the compilation time.

The real power of anonymous types lies in the fact that we can declare custom objects "as needed," use them and throw them away.  This feature comes particularly handy when coupled with strongly-typed access to database (DLINQ), where, at any moment during the program flow, we can go directly to the data tables and construct custom objects containing the necessary data. The example below creates a new set of objects, AmericanAuthors, each containg properties for the first and last name:

 var AmericanAuthors = from a in dt.Authors
        where a.CountryOfBirth == "USA"
        select new
        {
            AuthorFirstName  = a.FirstName,
            AuthorLastName = a.LastName
        }

2.  Object/Collection Initializers is a fancy name for the short way to set values on an object.  For example, both of the code segments below initialize an Author object:

 C# 3.0:
 Author author = new Author { LastName = “Chuvyrov”,  FirstName = “Eugene” }

 C# prior to 3.0:
 Author author = new Author();
 author.LastName = "Chuvyrov";
 author.FirstName = "Eugene";

Nothing earth-shaking for sure, but a handy feature nevertheless.

3.  Extension methods is the reference to the ability to add new methods to existing CLR types in .Net 3.5.  In the example below, the new method IsValidEmailAddress is added to the string type (borrowed from Scott Guthrie's blog, where you could also find more details about the extension methods).  Note the usage of keyword 'this' in the parameter declaration, which glues everything together:

public static bool IsValidEmailAddress(this string s)
{
 Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");
        return regex.IsMatch(s);
}

After this declaration (and making sure that the method is in the namespace accessible to our program), we could use (with IntelliSense support even!) the new method in the following manner:

string emailAddress = "bill@microsoft.com"
if (emailAddress.isValidEmailAddress()) …

4.  Query Syntax is a reference to a more readable way to query data inside .Net 3.5.  In other words, it's a feature that enables writing LINQ queryies without requiring a PhD in Computer Science.  You don't have to use query syntax when writing LINQ queries, but stick with Lambda expressions and Extension Methods (described below).  Consider the following two examples, which produce equivalent results:

Without Query Syntax:
IEnumerable<AuthorArticles> results =  dt.AuthorArticles.Where(aa=>aa.LastName.StartsWith(“Chuvyrov”))

With Query Syntax:
IEnumerable<AuthorArticles> results =
  from aa in dt.AuthorArticles
  where aa.LastName.StartsWith(“Chuvyrov”)
  select aa;

Query syntax makes querying for data a lot more SQL-like and a somewhat more readable.  Without Query Syntax, an understanding of Lambda expressions is a must, and I will briefly cover Lambda expressions in the section below.

A few more words on the structure of Query Syntax: every query expression begins with a "from" clause and ends with either a "select" or "group" clause.  The "from" clause indicates what data you want to query.  The "select" clause indicates what data we want returned, and what shape it should be in.

5.  The easiest way to conceptualize Lambda expressions is to think of them as ways to write concise inline methods.  Or, you can think of them as shorthand for anonymous methods introduced in C# 2.0, but I prefer "inline methods" myself.  The attached presentation contains an example of writing out Lambda expressions as anonymous methods. Here, I would only like to emphasize that Lambda expressions would always have three parts:

 -the left part indicating the object accepted as parameter (note that this could be derived, or "guessed", by Visual Studio 2008, so you don't have to supply the type of this object)
 -the '=>' separator just to confuse us normal folk; its sole purpose in life is to separate the left part from the right part of the Lambda expression
 -the right part that actually evaluates some programmer-defined expression and returns a value

If you need step-by-step instructions on modeling databases using LINQ to SQL, please refer to Part 1 of Scott Gu's blog:

For the fear of this first blog post running way too lengthy (too late, I realize!), let me get to the point already:

With the availability of anonymous types and other tools in C# 3.5, should database always matter to .Net Developers?  Should developers always blindly follow Codd's normalization principles ("The key, the only key, and nothing but the key, so help us Codd")?  Should architecture of any data-dependent processes always have a separate "database design" phase?

Let's say we have a standard e-commerce application, where customers shop for different kinds of products.  We may store different types of products in different tables in relational DBMS, and each product may have specific shipping instructions, customization properties, etc.  Imagine all of this data being stored in relational database while thousands of customers are hitting our application.  Wouldn't it make a lot of sense not to have to perform a dozen joins simply to get to the data for a single customer?  And while we are at it, wouldn't it be cool not to ask five different programmers to go to their cubes and build a zillion stored procedures gathering all these data pieces while you sit and think about the best possible abstraction layer for all of the SQL code they will write?

What I am getting at is that, perhaps, in certain situations where performance is paramount and the number of joins required by the RDBMS is excessive, the use of relational database may no longer be appropriate.  The DLINQ technology could become the enabler of the easy querying of in-memory persistent objects, or some sort of denormalized database structures.  Some authors on the Internet already argue that RDBMS is dead, or at least dying.  For example, Todd Hoff of http://highscalability.com/ states:

“The problem is joins are relatively slow, especially over very large data sets, and if they are slow your website is slow. It takes a long time to get all those separate bits of information off disk and put them all together again. Flickr decided to denormalize because it took 13 Selects to each Insert, Delete or Update. “

There are several ways we could about denormalizing the data storage:  some advocate putting all of the data into a single BLOB field in the database, and have separate database columns for fields that are searchable.  Others (like myself) think that a more appropriate solution would be a single database table resembling a giant spreadsheet with customer names, product names, etc. duplicated many times over.

Of course, there's an issue of maintaing consistency of denormalized data, which may seem as somewhat unchartered and perhaps dangerous waters at the moment.  Fear not, however, since the giants came before you, as evident by eBay following the BASE (Basically Available, Scalable/Soft state & Eventually Consistent) approach to data storage.  Still, for small shops with more limited resources and expertise, performance vs. consistency is an important architectural decision that DLINQ perhaps just made it a bit simpler.

Do you denormalize data in .Net applications on a regular basis?  Do you think DLINQ will make the dealing with denormalized data easier, more abstract?  Will DLINQ be a factor when considering the potential denormalization of the database?

Let me know at echuvyrov at msn dot com.

Resources:

ScottGu’s Blog: LINQ to SQL, 9-part series
http://weblogs.asp.net/scottgu/archive/2007/09/07/linq-to-sql-part-9-using-a-custom-linq-expression-with-the-lt-asp-linqdatasource-gt-control.aspx

Bill Wagner’s Blog on LINQ:
http://srtsolutions.com/blogs/billwagner/archive/tags/LINQ/default.aspx