Archive for the ‘Rant’ Category

August 9th, 2010

With Each Step Forward, Microsoft Takes Two Back

Today I was browsing a Microsoft published document on creating ASP.NET Web Pages using the Razor Syntax and to my surprise I found this gem on page 65. 

 @{
    var db = Database.OpenFile("SmallBakery.sdf");
    var selectQueryString = "SELECT * FROM Products ORDER BY Name";
 }
<!DOCTYPE html>
<html>
  <head>
    <title>Small Bakery Products</title>
    <style>
        h1 {font-size: 14px;}
        table, th, td {
          border: solid 1px #bbbbbb;
          border-collapse:collapse;
          padding:2px;
        }
     </style>
  </head>
  <body>
    <h1>Small Bakery Products</h1>
    <table>
        <thead>
            <tr>
                <th>Id</th>
                <th>Product</th>
                <th>Description</th>
        <th>Price</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var row in db.Query(selectQueryString)){
             <tr>
                <td>@row.Id</td>
                    <td>@row.Name</td>
                    <td>@row.Description</td>
                    <td>@row.Price</td>
             </tr>
            }
        </tbody>
    </table>
  </body>
</html>

In case you missed it here is the meat of the problem I have with this example:

@{
    var db = Database.OpenFile("SmallBakery.sdf");
    var selectQueryString = "SELECT * FROM Products ORDER BY Name";
 } 

This is in direct relation with Microsoft’s latest attempt to make programming easier for bad software developers.  Ayende probably put it best in his article entitled “Microsoft.Data and Positioning” when he said:

If Microsoft thinks that they can get the market for bad developers, good for them. But that needs to be highly segmented. It should be clear that going with that route is leading you to a walled garden and that writing real apps this way is not good. The best comparison I can think of is Access apps in the 90s. There was a clear separation between “just wanna write some forms over data app over the weekend” and “I want to build a real application”. When you built an app in Access, you had very clear idea about the limitations of the application, and you knew that if you wanted something more, it would be a complete re-write.

That was a good thing, because it meant that you could do the quick & dirty things, but when things got messy, you knew that you had to make the jump.

The problem with things like Microsoft.Data is that there is no such line in the sand. And when you call it “Microsoft.*” you give it a seal of approval for everything. And when you have a piece of code that is explicitly designed to support bad coding practices, it is like peeing in the pool. If there is only one pool, it is going to affect everyone. There wouldn’t be nearly as much objection if it was called WebMatrix.Data, because that would clearly put it in someone else’s pool, and it that turn into a putrid swamp, I don’t really care.

I know proponents of this approach are going to say, it’s only an example to give a quick demonstration of how the Razor syntax works, and no good developer would take this seriously.  But I don’t know what land Microsoft lives in, because in my land examples like this are seen by both good developers and bad developers a like and examples like this quickly turn in to production apps.  Bad developers have the same deadlines as good programmers do, and bad developers don’t have the same forethought about the pains that come from bad coding practices, so they are more apt to take the example at face value and look at it as a good example of how they should be programming coming from Microsoft itself.

And don’t even get me started about handling your post back logic in the same page, and then doing an insert into the database that is found on page 68.

@{
    var db = Database.OpenFile("SmallBakery.sdf");
    var Name = Request["Name"];
    var Description = Request["Description"];
    var Price = Request["Price"]; 

    if (IsPost) { 

        // Read product name.
        Name = Request["Name"];
        if (Name.IsEmpty()) {
            Validation.AddFieldError("Name", "Product name is required.");
        } 

        // Read product description.
        Description = Request["Description"];
        if (Description.IsEmpty()) {
            Validation.AddFieldError("Description",  "Product description is required.");
        } 

        // Read product price
        Price = Request["Price"];
        if (Price.IsEmpty()) {
            Validation.AddFieldError("Price", "Product price is required.");
        } 

        // Define the insert query. The values to assign to the
        // columns in the Products table are defined as parameters
        // with the VALUES keyword.
        if(Validation.Success) {
            var insertQuery = "INSERT INTO Products (Name, Description, Price) VALUES (@0, @1, @2)";
            db.Execute(insertQuery, Name, Description, Price);
            // Display the page that lists products.
            Response.Redirect(@Href("~/ListProducts"));
        }
    }
}

I shouldn’t have to explain what is wrong with this.  This is the way that PHP 3 and classic ASP developers use to construct pages over 10 years ago, which by the way is no longer recommended practice for either language.  PHP 5 now has classes and a couple very well accepted MVC frameworks, classic ASP is all but gone, and Ruby, with Ruby on Rails which is an MVC framework, has most of the mind share of dynamic languages at the time of writing this. 

So why is Microsoft continuing to target PHP 3 users, when they should be targeting PHP 5 and Ruby on Rails users for the mind share of rapid application development?  I am calling on Microsoft to take this abomination of a document down, and just put up a simple Razor syntax language reference at the very least, and at the very most gut this document and create a document that doesn’t perpetuate bad software development practices and becoming a shining star to software developers and not a rusty anchor.

Tags: , , ,

Posted in Programming, Rant | kick it on DotNetKicks.com | Bookmark | View blog reactions | 8 Comments »

March 20th, 2010

The difference between Routing and Rewriting

As most of you are probably aware, if you read my blog enough, I am the sole developer of a URL Rewriter that I have tried to keep extensible and relevant to the problems that modern web developers face when exposing their applications to the web, by allowing them to have more control over the only interface that matters on the web … THE URL.  The benefits of a URL Rewriter have been explained many times, by many people, so I am not going to add just another rant to the web about keeping your URL’s clean for the search engines.  I will just leave you with Jeff’s explanation of why you shouldn’t ignore the URL.

Having multiple URLs reference the same content is undesirable not only from a sanity check DRY perspective, but also because it lowers your PageRank. PageRank is calculated per-URL. If 50% of your incoming backlinks use one URL, and 50% use a different URL, you aren’t getting the full PageRank benefit of those backlinks. The link juice is watered down and divvied up between the two different URLs instead of being concentrated into one of them.

While Jeff only focuses on the reasons related to SEO, there are many other reasons to make your URL’s “look-and-feel” a hire priority.  One that is often touted as a wonderful reason to use a URL Rewriter is to produce pretty looking URL’s, and even though this one of many reasons to use a rewriter, it is really a small part of why you want to have a URL Rewriter in your arsenal as a web developer.  Other reasons include forcing your domain to a constant www vs non-www address, having helper URL’s such as http://www.microsoft.com/sql that redirect to their actual location, and many others.

routing_engine

However, since Microsoft released the System.Web.Routing framework the benefits for using a URL Rewriter have been blurred, because the routing framework gives developers more of an ability to control the URL and thus create prettier URL’s than have traditionally been possible.  Because of this overlap of efforts, in the router and rewriter, in making a more readable URL a misunderstand has been created about the functions and benefits that each provide to the modern web developer.

The first thing to understanding the difference between routes and a rewriter. Phil Haack explains on his blog the reasons routes were not designed to be changeable without a recompile:

This is partly by design as routes are generally considered application code, and should have associated unit tests to verify that the routes are correct. A misconfigured route could seriously tank your application.

In other words the route which is compiled “application code” is like a road, and like the properties of a road it provides a way to get between the starting point and the destination, or in the case of the web the client browser requesting a URL as the start point and your action method as the destination.  If this road could be changed with out much thought, it would be possible to create a circumstance where your destination is no longer accessible by the road. The rewriter on the other hand can be looked at as the rules of the road used to detour traffic, govern the speed, give direction, and really just provide flexibility on top of the rigid start and end points of the road.

When I try to explain this to fellow developers I often have a conversation that goes something like this:


[ME] Why are you not using a rewriter in your ASP.NET MVC application to give you better control over your URL routes.  So that you provide a consistent domain, helper URL’s, and more flexibility to the running of your web application?
[THEM] I don’t need a rewriter, I use ASP.NET MVC for creating pretty URL’s and Routing rocks.
[ME] Sigh, I never said anything about pretty URL’s. The benefits of a URL Rewriter go way beyond making your URL pretty.
[THEM] I don’t see how. The interweb always talks about pretty URL’s and rewriters.
[ME] Well, Routing is like namespaces for your actions they just provide a web accessible name to get directly to your action method, they don’t act as a rule engine on what types of requests to let through, what type to redirect, and where the request should go.  That is why you need a URL Rewriter in addition to Routing.  Thing of a route as a road, and the rewriter the rules you use to drive on that road.
[THEM] I like driving fast in my Prius.
[ME] Double Sign. Lets focus here for a minute.  Lets get back on topic.
[THEM] Yeah but so what I don’t need any of that mumbo jumbo, I just want pretty URL’s because that is all that people talk about on the interweb, and that is how you get to #1 on Google.
[ME] Fine Good Luck with your PageRank, come back to me in a year when you are still at the exact same rank in Google and ready to listen.


It has gotten really to the point where I start picking the people I want to have this conversation with based on if they are actually willing to listen and understand enough of the basics of SEO and HTTP so that my conversation is not lost on them.

If you have gotten this far in to my rant on the differences of routing and rewriters, you are probably somebody who generally cares and already understands the difference or wants to know more.  If you are that person, I would love to talk to you about what kind of enhancements to my companies URL Rewriter that would make your life easier as a web developer.  As I start to line up the features for the 4.0 release.

Tags: , , ,

Posted in Programming, Rant | kick it on DotNetKicks.com | Bookmark | View blog reactions | Comments Off

July 6th, 2009

Form over function often fails

Have you ever been asked to program something as simple as this chain lock for a door:

Door Chain Lock

And after it has gone through the design process, usability groups, your corporate intigration team, and any Tom, Dick, or Harry that wants to put their finger print on the project to get credit.  You end up with something like this:

At least it looks pretty, and functions once as intended. However every time the door opens after that it fails to work as the user would assume, and gives a false sense of security.

This is a major security flaw and these are the exact situations, as programmers, we are hired to prevent. I am not talking about chain locks on a door, but programs that were suppose to serve simple processes, but after going through the design and review machines it came out looking like some Frankin-program.

This is why as developers, we must create unit tests based off requirements and not based off of the program we have created. It is usually easier to get a unit test to pass after we have programmed something, but often times that leads to a false sense of security for both us as developers and the users who rely on the program. If the second, pretty-looking-lock, was properly unit tested based off the requirements of the first lock, it would have never made it’s way in to the high priced Le Meridian hotel in Paris.

Be sure to unit test to provide both a sense of security for you as the developer and an expected experience for your users.

Tags: , , , ,

Posted in Programming, Rant | kick it on DotNetKicks.com | Bookmark | View blog reactions | 1 Comment »