.Net, diversify!

One of the tenants of .Net is language neutrality. It means you can pick the language you know and like the best and you will be able to write more or less the same program as you would in any other .Net language. This has pretty much worked as promised and today with Visual Studio .Net 2008 you get C#, C++ and VB.Net support out of the box. Some languages like J# have been made obsolete but many new, and most interestingly those based on Dynamic Language Runtime are in the works, or have been recently released.

However, once you get over your syntax preferences (as in VB vs. C style) and those die-hard habits, there isn’t that much difference in what you can do with each of these languages. For sure, VB .Net has some dynamic capabilities, and this can lead to some interesting features, like I have demonstrated in VB’s Statically Typed Wrapper for Dynamic Code article, but frankly these are not revolutionary. There must be a better reason for being able to use the same language on one platform than syntactic sugar-coating.

In VB 2008, however, you get a native XML support in VB in style of E4X programming extension for ECMAScript (or to put is simply JavaScript). Processing XML in VB using LINQ, XML literals, with ASP style templates and accessing it through XML Axis properties makes VB the best choice for working with XML on .Net platform. If you tried XSLT and didn’t like it (don’t worry, you are not the only one: MovingAwayFromXslt), then you will be thrilled with VB’s new capabilities, that can easily turn VB into real XML pipeline. There are drawbacks of course, using XML literals can often mean embedding your schema and transformations inside the VB code, but how serious these really are? How often can you change the schema or transform and not recompile anyway and is that really important? And yes, this increases VB syntactic load, but hey when was VB conservative in this aspect?

This means that choosing between VB and C# finally might matter in some cases! And that is actually a good thing. It means that “right tool for the right job” might finally mean something in VB vs. C# debate. (Yes, I know these differences are in the end only syntactic, but this times it does matter.) While both C# and VB are general-purpose programming languages, there is no reason why they shouldn’t be more specialized in some aspects. When you put it that way, this seems to be in the accord with Domain-specific languages ideas, that are getting into the spotlight recently. So, if you need to process some XML, no reason not to do it in VB (even if you prefer C# in general). Multi-language paradigm is a great asset of .Net, only if put into the practice correctly!

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

It’s official! Professional Refactoring in C# and ASP .Net is in the works!

Writing a book is a LOT of work. When I finished writing Refactoring in VB, I didn’t think I will embark on similar adventure any time soon. Well, what to you know…

I already started working on my next book. Should be in the bookstores sometime in the spring of the next year. I plan to follow the same approach as in Refactoring in VB, meaning it will mix typical narrative section with reference style definitions. Content wise, this time I will also cover refactoring in ASP and maybe a few things more. I will keep you posted about the progress 😉

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

Debunking refactoring misconceptions at InfoQ

InfoQ has published an article adapted from Chapter 1 of my book Professional Refactoring in Visual Basic. Check out the article for a interesting discussion.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

LINQ to SQL or LINQ to MS SQL?



LINQ to SQL is simple ORM framework from Microsoft that ships with .Net framework 3.5. Today, it seems that Microsoft is trying to divert all attention to alternative Entity Framework, but this one is not without controversy. This maybe the reason why Microsoft didn’t address one very serious limitation of LINQ to SQL in SP1 of .Net framework 3.5: LINQ to SQL works only with Microsoft SQL Server (2000 onwards I think). Or could it be something else?
Whatever the reason, this limitation is serious and will put many towards choosing free alternatives like NHibernate. Another limitation of LINQ to SQL is that it is no 100% POCO. It almost is, but the framework forces you to use System.Data.Linq.EntitySet programming one-to-many relationship (and EntityRef on the other side of relationship). This can have some awkward consequences, most obvious being existing code; should you decide to use LINQ to SQL to persist some existing classes, you will have to change original source code to accommodate this. Other ORMs do not pose this limitation, so neither LINQ to SQL should.
I am hoping that these obvious limitations are only consequence of products immaturity and that Microsoft will fix it’s first-born ORM in the future.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

Another tool in Visual Basic refactoring arsenal

It’s great to see that support for refactoring in VB is constantly growing. Here is another tool on the list. JetBrains have announced 4.0 Beta of ReSharper Visual Studio Add-in. This time, ReSharper comes with support for Visual Basic. While it is still lagging a bit behind C#, since it supports refactoring of Visual Basic 8.0 code (comes with Visual Studio 2005), while C# 3.0 is fully supported including LINQ, it still supports some very useful refactorings in VB likeExtract Superclass, Pull Members Up and Push Members Down. According to my records, these are supported for the first time in VB.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

What difference does the “CALL” make? (or Another Treatise on Premature Optimization)

These things tend to happen during those lovely quiet afternoons. I was enjoying reading about Mars colonization and genetically engineered bacteria terraforming when I got the call from our CEO. You probably already know the story, our VIC (Very Important Client, sometimes confused with GOD) has a problem. Even worst, the problem is identified in their production environment. I am to put on my superhero uniform and to go to client’s installation and face the “eye of the storm”. My mission is two-fold. My appearance is supposed to pacify the client and I might even do something about the problem, I have some whole 2 or 3 hours to come up with the solution.

Fortunately, once I meet with our guy working in-situ and our liaison (a junior manager has been assigned on client side to help us deal with the problem) the hysteria has subsided, and a few interesting details come into the light. The problem is by no means new, it has been reported more than a year ago, but for some reason nothing was done about it. It is a performance problem, so that is why it might not have been considered critical in the begging. What actually happened recently is that their CEO was annoyed by the problem and that made it hit the fan.

So, we start reviewing the app. My team-mate tells me that problem is produced only during login flow. We investigate bit further and by looking performance of components in Component Manager we are able to identify single offending component. In development environment, this component is taking some 40 seconds to respond, each time with exactly the same delay.

I ask them to monitor the component in production environment and to let me know. I will not receive the result until tomorrow, so I go back to the office. I am just too curious to wait, and I decide to take a look at component’s code. It is a COM+ component programmed in VB6 quite a few years ago. Component serves as a sort of Http proxy for stored procedures on MS SQL 2000, something of an in-house SOAP implementation that exposes stored procedures over http. Stored procedure name and parameters are received through Http request and reply rendered in form of Xml and sent back as a response.

A few lines almost immediately catch my eye:

strExecID = Request.Form("exec")
strParams = Request.Form("params")
‘ ...
Set Conn1 = CreateObject("ADODB.Connection")
Conn1.CursorLocation = adUseClient
Conn1.open strConnString
Set Rs1 = Conn1.Execute("EXEC " & strExec & " " & strParams)
‘ ... process Rs1 and generate Xml

Following problems are immediately evident:

1. Cursor Location

By setting cursor location to adUseClient, application will first pull down all the data over the wire before processing any of it. This should be changed to adUseServer.

2. Parameters

Parameters are passed as comma delimited string that is concatenated to “EXEC ” command + Stored Procedure name string that is used to execute query using the Connection object. This syntax is inferior to using ADODB Command and Parameters object. The problem in this case is that it would be probably too complicated to ask client component to supply all parameter metadata like type, size etc necessary when adding parameters to command. They decided to use position based parameter string executed on connection object instead. There are different solutions for this problem:

* Component could use some configuration data for this purpose

* ADODB Command is capable of obtaining parameter information from database. While this is not very efficient if it is done before each execution, some cache mechanism could be implemented in order to cut number of round-trips.

3. EXEC syntax

When executing stored procedures, standard ODBC syntax with CALL statement is the preferred way. This should reduce the number of compilations on the server. In order to check this, I decide to perform a small experiment.

The experiment

I place two controls on the form in VB and write the following code:

Private Sub UseCall_Click()
    Dim Count As Integer
    Dim Cn As ADODB.Connection
    Set Cn = CreateObject("ADODB.Connection")
    
    Cn.Open ("Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;" & _
    "Initial Catalog=Northwind;Data Source=TESLATEAM")
    Dim Rs As ADODB.Recordset
    Do Until Count > 100
        Set Rs = Cn.Execute("{Call [Ten Most Expensive Products]}")
        Do Until Rs.EOF
            Debug.Print Rs.Fields(1)
            Rs.MoveNext
        Loop
        Count = Count + 1
    Loop
End Sub

Private Sub UseExec_Click()
    Dim Count As Integer
    Dim Cn As ADODB.Connection
    Set Cn = CreateObject("ADODB.Connection")
    Cn.Open ("Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;" & _
    "Initial Catalog=Northwind;Data Source=TESLATEAM")
    Dim Rs As ADODB.Recordset
    Do Until Count > 10
        Set Rs = Cn.Execute("EXEC [Ten Most Expensive Products]")
        Do Until Rs.EOF
            Debug.Print Rs.Fields(1)
            Rs.MoveNext
        Loop
        Count = Count + 1
    Loop
End Sub

As you can see, the only difference between two event handlers is that in first case, {CALL } and in second EXEC syntax is used.

I open Performance Monitor and add SQL Compilations/sec counter. It is found under SQL Server:SQL Statistics performance object.

First, I press UseCall button. The counter is showing barely single SQL Compilation.

call.GIF
Using “CALL” syntax to execute Stored Procedure

However, when I use Exec syntax, there are repeatedly more than 10 Sql compilations per second. In production environment, this might incur significant load on the server.

exec.GIF
Using “EXEC” syntax to execute Stored Procedure

This is enough to convince me that I am at the right track, and I proceed fixing the 3 problems I outlined above. Soon I have new version and I am ready to take the component to testing site we maintain at client’s premises.

Sobering up

I receive the monitoring results from production environment waiting in my inbox the next day. Things can really move fast when you have the right lever. The results are similar to one in testing environment, the component is taking a very long time to respond, with times raging from 700ms to over 50s. No doubt we have found our performance bottleneck.

I am off to the client with fixed code. I want to debug the component and to observe how the new code is being executed. I start executing the login test case and soon the IDE stops in debug mode reporting an error. The default Error Trapping options are not changed and IDE will break on errors in class module.

Damn, I have made the error somewhere and this might not be such an easy ride as I expected. I was already preparing for hero’s welcome back in the office. I guess that medal ceremony will have to wait for now.

Code is relatively simple and I should be able to find the bug without too much effort. I run the test case a few times but no error is produced until the command is executed. Finally, I have identified the error and it is not inside the component. The component is receiving non-existing stored procedure name for execution!

I decide to see how original version will do. The result is the same, the IDE breaks on the same error produced by non-existing stored procedure. This leaves me quite puzzled. Finally, I decide to change Error Trapping option to “Break on Unhandled Errors”. Voila! Application executes just fine, showing normal behavior, including the 40 second delay.

Following some dark alleys of error handling code, I finally fins out that client component handles the error produced in the component I just “fixed” and returns empty reply back the execution stack. As it happens, the component is not used at all and calling it is complete waist of time. And not just any waist of time, but very critical delay producing serious performance problem.

I soon implement the final solution eliminating the call to the component altogether. Application continues to work as it was supposed to be so I let the bygones by bygones. I explain the problem and the solution to the junior manager that is working with us and he is nice or content enough not to ask “But how this happened…”.

Finally, I am convinced once more that there is quite a lot of truth in Hoare’s proverbial sentence “Premature optimization is root of all evil”, cited by Diego in foreword to my book on refactoring in VB.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

Get a first peek into upocoming Professional Refactoring in Visual Basic

While Professional Refactoring in Visual Basic still has “upcoming” badge on Wrox site, I recently saw that you can already download and take a look at few excerpts. Excerpt 1 is actually the whole first chapter and gives a good intro in what the book is all about.

Enjoy 😉

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

Refactoring community at RefactorMyCode

At RefactorMyCode you can post the code you are not so sure how to refactor and ask someone else to have a go at it. There is already a great number of posts and programming languages at the site. A great way to make refactoring community work together.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

VB6 crossing the Rubicon

This post is for all you VB6 diehards. I just stumbled upon a VB6 add-in that supports a few refactorings in VB6. CodeShine add-in supports Extract Method, so it means it’s on the other side of refactoring Rubicon. It also supports a limited Rename functionality, so here you have probably two most common refactorings automated in VB6. You can download a free trial version from www.wsdesigns.com.
I have noted that when performing Extract Method, it hill always create the Sub with output parameter and never the Function. I prefer methods that clearly state the value they return. In case extracted block returns single value, I’d prefer it to create a Function instead of Sub.
Has anyone tested the tool thoroughly? Let me know what you think.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG