Blog Home  Home RSS 2.0 Atom 1.0 CDF  
The Efficient Coder - Monday, March 10, 2008
There has got to be a better way of communicating with our computers!
 
 Monday, March 10, 2008

Putting your Trust in Metrics

I'm a big fan of automating as much as you can, but blindly automating processes controlled by metrics may cause more problems than they solve.  The idea behind capturing metrics or in the case I'm currently working on, writing a suite of unit tests is to automate the testing so I can make changes at-will, run my unit test and know everything is still working good.  If I come to rely on these unit tests (or really any sort of metrics) to help me make business decisions as to when I am code complete and ready to ship;unless I'm 100% sure that the unit tests take into account 99.99% of all the edge cases; I'm doing the recipients of the software a disservice.  As an efficient coder, I want to take what the customer tells me they need and turn it into the compiled bits that successfully solve their problem in a straight of a line as possible.  Unit testing and other software related automated processes go a long ways to helping ensure an efficient path, but as these automated processes are developed we need to pay special attention to make sure these are complete.  In a large sense, if you are capturing KPI or Key Performance Indicators about your organizations performance, are you sure that the core measures you capture are indeed complete and accurate?  Remember the purpose of capturing these metrics is to influence business decisions.  If your metrics are not accurate or your measures just can't be trusted, there are three core problems that this causes.  First it clouds the judgment of the people directing the efforts, they may think they need to do A, but the metrics tell them B really needs to happen, A is clearly the right thing to do, but since B is out there as a potential solution it may dilute the affect of implementing A.  Second it puts in place a false sense that you are indeed doing something to solve your problems and all you are really doing is delaying the true solution costing the most valuable asset in software development, time.  Finally it takes time to capture metrics and if done properly it is a great tool.  If your metrics are worthless you waste the peoples time building the infrastructure to capture the metrics, you waste the peoples time to capture the metrics and you may even unintentionally sabotage future metrics capturing initiatives.

In a previous post I discussed the race car analogy, where the drivers have a significant amount of safety gear in their cars.  They need to be 99.99% sure that if they get in an accident the gear will do it's job and protect them.  If they can rely on their gear, they can take more risks to give themselves a competitive edge.  Are your sure the test cases, scenarios and metrics your are employing would help you prevent or survive a crash and give you a competitive edge?

-ec

3/10/2008 9:17:28 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering | Software Metrics  |  Trackback
 Friday, February 29, 2008
Dynamic SQL/ADO Command Execution Comparison

In a project I'm working, I need to build up filtering conditions within C# code based upon user settings.  There are about 50 settings so I chose to do this in C# code and pass it to SQL server to get the results set.  This is something I would really like to have in a stored procedure, but was hesitant to building up the dynamic SQL, both from a complexity and performance stand point.  Recently while troubleshooting a problem I was working with the SQL Profiler and a SqlClientCommand object executed a statement against SQL Server.  Since this was a parameterized query the following statement was passed to the engine.

exec sp_executesql N'select * from usv_action_item_detail where action_item_type_id = @actionItemTypeId',
     N'@actionItemTypeId uniqueidentifier', @actionItemTypeId = N'25B3384F-04C8-4B6D-BC11-B7EC92A07E45'

This gave me the thought that this is really just a parameterized dynamic sql statement.  This could be built and executed through a stored procedure.  As a trusted colleague suggested, I went on to run some performance tests.

I built a simple C# test harness with the following code

     SqlCommand cmd = new SqlCommand("select * from usv_action_item_detail where action_item_type_id = @actionItemTypeId", new  SqlConnection("server=sldsql1;database=ChaosFilter2007;Integrated Security=true"));
     SqlParameter parm = new SqlParameter("@actionItemTypeId",SqlDbType.UniqueIdentifier);
     parm.Value = new Guid("25B3384F-04C8-4B6D-BC11-B7EC92A07E45");
     cmd.Parameters.Add(parm);
     cmd.Connection.Open();
     cmd.ExecuteReader();
     cmd.Connection.Close();

I also built the statement to run in SQL Server Management Studio.
exec sp_executesql N'select * from usv_action_item_detail where action_item_type_id = @actionItemTypeId',
     N'@actionItemTypeId uniqueidentifier', @actionItemTypeId = N'25B3384F-04C8-4B6D-BC11-B7EC92A07E45'


And started my testing.

As I expected when the C# code was executed the following results where presented in SQL Profiler



Next I executed the dynamic SQL command through SQL Server Management Studio and capture the following result


You will notice the only real difference is that "EventClass" column which for the ADO.NET method it returned "RPC:Completed" and with SSMS it returned SQL:BatchStarting and SQL:BatchCompleted.  I guess this makes sense if you think about it.

I've executed this test about a dozen times and with all things being equal the, CPU, Reads and Duration where roughly the same in all cases.

My conclusion is that the same stored procedure gets executed either through the Parameterized Query through C# or through the Parameterized Dynamic SQL through SSMS.  What this tells me that if done properly there is no performance penalty for using a parametrized dynamic SQL statement in a procedure.  I can push the logic for building up my filtering statement from C# into a stored procedure.

-ec
2/29/2008 8:40:37 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Friday, December 28, 2007

Upgrading .NET FX 2.0 to .NET FX 3.5 and LINQ

After recently upgrading a web project from the 2.0 framework to 3.5 I attempted to use the new language feature LINQ (actually found a really good use for I'll blog about later) however I ran into a problem where it wasn't recognizing the LINQ syntax...after a bit of research I discovered the following, for the ASP.NET compiler to recognize the syntax I need to add the following chunk of xml to my web.config file.  Not sure how this works with the compiled ASP.NET apps and my CI environment, if I need to do anything else I'll post it...

</system.web>
...
<
system.codedom>
   <
compilers>
      <
compiler language="c#;cs;csharp" extension=".cs" warningLevel="4"
         
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <
providerOption name="CompilerVersion" value="v3.5"/>
      <
providerOption name="WarnAsError" value="false"/>
   </
compiler>
   <
compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" warningLevel="4"
         
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <
providerOption name="CompilerVersion" value="v3.5"/>
      <
providerOption name="OptionInfer" value="true"/>
      <
providerOption name="WarnAsError" value="false"/>
   </
compiler>
</
compilers>
</
system.codedom>
...
<system.webServer>

Make sense if you think about it...

-ec

12/28/2007 11:54:40 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   ASP.NET  |  Trackback
 Wednesday, November 28, 2007

Table vs DIV Tag Layouts

Am I a bad person because I fall back on using Tables to some of my layouts?  Ok, maybe "bad-person" isn't the right term, but over the past year or so I've started to pay extra-special attention to the HTML.  I'm trying to carve out for my apps to build the HTML with DIV tags and not tables, for the most part this works good, but in some cases after about 15 minutes of screwing around I fall back to my crutch of just doing the old table with colspan and rowspan.  In most cases where I get in trouble is with more complicated layouts that include nested divs/spans with images using the float:left style.  It seems like these get real tricky to keep lined up right when you want to keep the "flow" concept of HTML intact instead of doing absolute or relative position.  It also gets a bit interesting when you try to make it work on different browsers, layouts in one browser look good but because of different rendering techniques paragraphs with images that "floated" nicely all of a sudden look like a mess.

So I guess I can understand some possible performance improvements with a div strategy (are these really negligible) and unless you are doing absolute positioning, (which I feel sort-of dirty after doing so) are there any downfalls to just falling back to tables?

Comments?  Thoughts?  Two-Cents?

-ec

11/28/2007 4:20:10 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Monday, November 26, 2007

Upgrade to .NET FX 3.5 - Assembly Binding

I've officially converted my main ASP.NET application from 2.0 to 3.5 this morning overall it was very painless, for the most part, just adjust the class libraries to use the .Net Frameworks 3.5, and modify web.config entries from System.Web.UI.Extensions, Version 1.0.61025.0 to System.Web.Extensions, Version=3.5.0.0.  The problem I ran into was that some of the control libraries I was using were compiled against the 2.0 framework.  Adding the following keys to the bottom of my web.config files clean that up.<configuration>
  ....
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

-ec

11/26/2007 11:41:35 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5 | ASP.NET  |  Trackback
 Monday, November 19, 2007

The next leg of our journey officially begins today...VS.NET 2008 RTM!

http://weblogs.asp.net/scottgu/archive/2007/11/19/visual-studio-2008-and-net-3-5-released.aspx

11/19/2007 3:38:08 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Wednesday, November 14, 2007

VS.NET 2008 & VS.NET 2005 Solution Files

I recently made the move to Beta 2 for my main project and so-far-so-good, I haven't made the move to the 3.5 framework yet, I probably will as soon as I get the RTM later this month.  I'm being a bit cautious and not installing and beta components on my build server so I did a little research and found this article on information for working with your projects in both VS.NET 2008 and VS.NET 2005 concurrently.

http://west-wind.com/weblog/posts/122975.aspx

Basically just make a copy of your solution file, then change the "Format Version" and "# Visual Studio"

ProjectName_2005.sln

 

ProjectName_2008.sln

From what I can tell so far, the actual project files just aren't a problem.

-ec

11/14/2007 10:58:26 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   ASP.NET | Continuous Integration  |  Trackback
 Tuesday, November 13, 2007

AJAX File Upload

As we all know that if you put any sort of file upload control on a form where you use AJAX (ex. the ASP.NET ScriptManager and UpdatePanel) it won't upload the file via an XMLHttpRequest.  So that means you have two options; first not use the update panel; second, put a button on the form that does a full post back to upload the file, and another one to just do the save.  Actually the second one could be fairly attractive for providing some sort of feedback on large file uploads, but that isn't the point of this post.

Here's a hack that at least allows me to do this until I can figure out a more elegant approach, but first a quick background.  Within my architecture I have web parts which are essentially a tool bar with Save, Cancel & Delete and a form of fields that get updated.  I have this wrapped into a nice server side custom control and all my panels use the same architecture so this was a change only in one spot.

Basically what I do is capture the "onchange" event on the <input type="file" id="foo" onchange="swapSaveButtons();" /> control.  I then invoke some java script that swaps out the save button on the form that is registered for an async post back (it does this by default on an update panel) for one that does a full post back:

<asp:UpdatePanel ID="oUpdatePanel" runat='server'>
   
<Triggers>
      
<asp:PostBackTrigger ControlID="btnFoo" />
   
</Triggers>
</asp:UpdatePanel>

A more elegant approach would be to interact with the ScriptManager with client javascript, but I couldn't find any APIs.  So basically in most cases, the normal save button that does the async post back triggers the trip to the server and the AJAX panel is happy.  In the case where the user selects a file, we swap out the normal save button with one that does a full post back and the file gets uploaded.  Of course this solution isn't perfect, but the worst case scenario is one where there is no file to upload and we still do a round trip.  That probably isn't the end of the world.

I would be very happy to hear of other approaches that would be transparent to the user and workflow.

-ec

 

11/13/2007 2:16:24 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
Copyright © 2010 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: