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

I've got an awesome battery in my laptop

I wish I could find more like this

-ec

6/5/2008 7:06:10 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback

Annoying VS.NET "Feature"

 

I have a fairly large ASP.NET application that has a large number ASP.NET WebParts built as Custom Controls (150+) in a compiled assembly .  I've been getting a little annoyed with VS.NET (I'm using 2008 right now, but saw the same behavior in 2005) where after I get done compiling I have to wait 20-30 seconds while VS.NET does ?something? and freezes the UI (can't ?someting? this be done in a worker thread).  Anyway I think I've finally figured out what's up, it would appear anytime I open anything that requires a designer (including an ASMX page) the tool box get's populated with all the custom controls as part of my project.  It would seem as soon as the tool box is populated it needs to be refreshed and that's what's taking the 20-30 seconds.  So therefore if I don't open anything requiring a designer, I'm OK.  I think I've gotten used to this for ASPX and ASCX pages since they normally open up in the HTML view, but I'm still clicking on ASMX and Services design surfaces and end up shutting down VS.NET and restarting without a design surface open.

 

Maybe my project isn't typical, but it sure would be nice if I could use design surfaces at some point.

 

-ec

 

6/5/2008 7:08:30 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5 | ASP.NET  |  Trackback
 Saturday, May 24, 2008

LINQ 2 SQL - SQL Server Compact Edition 3.5 - Provider Not Found

If you are working on a 64 bit machine and get the error message

Provider 'System.Data.SqlServerCe.3.5' not installed.

when you attempt to connect to your database, open your project properties and on the build tab, change your target platform to x86 and you should be back in business.

-ec

5/24/2008 5:48:29 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5  |  Trackback
 Sunday, May 11, 2008

More Help Available

I got this one while trying to spin up a 3.5 WCF Service and it made me chuckle...no comment necessary...

-ec

5/11/2008 2:33:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5  |  Trackback
 Saturday, May 03, 2008

Development or Discovery

The biggest cost in any software development effort is always a factor of time.  It became pretty obvious to me while working on a new reporting project.  I've worked on a "ton" of systems over the past few years and with very few exceptions I can sit down and start making tangible progress very quickly (this may not be evident to my clients while I'm working on the plumbing, but that's a topic for another post) but with this project I've got about 4-6 hours into it and although I'm making headway on a couple of fronts I'm starting to sense the "churn" where it's more of a discovery process than a development effort.  How much of your time is spent in discovery and how much in pure development?  I think the ratio of discovery to development is major factor in developer efficiency and thus the time/cost in a software development effort.  Although some external factors such as training, pair programming, documentation and mature processes may help with this ratio, the biggest impact on the ratio will be the person doing the development.

Discovery does not provide any real business value.  Discovery is a critical investment that needs to be made.  Just as you invest in your financial future, you should invest in your professional one as well.  Once you’ve made this investment you start building capital, the capital can then be used to increase your Development time, this is where your investments should pay off.  As Frederick Brooks states in his timeless classic “The difference between an exceptional developer and a Mediocre one is generally an order of magnitude”.  Why is this the case?  One reason is Developer Efficiency  but the other is the capital the developer brings to the effort.  Effective program manager realize this.  When we talk about capital/experience/knowledge this can really be in three categories, general technology, domain specific, implementation specific.

Technology Capital

You, my dear reader are 100% responsible for this.  If you work for a corporation that’s nice in that they may pay you to learn this knowledge, but in the end, this is how to program an Http Handler in ASP.NET or write a SQL Query, create a clustered index and so on.  These skills are not implementation specific.  The wider background of skill sets you have the more capital you will have and the more value you bring.  As a consultant, if I am stuck doing “discovery” on a new technology I very rarely bill the client for this time.  My clients pay me to “develop” they assume I know they technology.

Domain Specific

This is where you can start developing additional capital.  Unless you pick on specific vertical, there will always be a portion of the time working on development efforts where you will be doing discovery within that domain.  An example of this is my experience working in a Sales Force Automation company for 3 years on a number of different efforts.  Although there was an initial learning curve in this vertical, over time the value I brought to the table during the system design meetings increased, the more knowledge I brought to the table, the quicker we could talk about what made their problems unique and in most cases these so-called “unique” problems were actually solved in other efforts and that experience could be capitalized on.  My goal going forward is to pick a new domain every other year and start gaining that knowledge.  Have you worked in one industry all your life?  How many jobs are there in that industry?  How well are you compensated in your industry with respect to others?

Client/Implementation Specific

Now is where it get’s interesting, each client does indeed have certain technologies, systems, database schemas that are unique to their organization.  I would suspect that a considerable number of developers are “experts” in this area.  As a consultant I worked at one client for about 3 or 4 years.  They made a considerable investment in me in their specific data, not only just the structure, tables but also the subject matter.  I made a significant investment in time in their data.  At the point I started scaling back my work on their efforts, I had a much better understanding of the data within their systems then anyone did internally.  This was a great engagement for both parties (Client & Software Logistics) however when I look back over those 3 or 4 years, what can I take away from that client specific data knowledge?  Not very much as it turns out.  From a billing perspective, I don’t have any problem doing “discovery” of a clients systems on their “nickel” especially if in the long run that knowledge won’t be useful anywhere but their systems.

The bottom line is in software development, the more capital you bring to the table, the less time you are doing discovery and the more time you do performing development.  You are paid by your organization as an employee or a consultant to do development and not discovery.

-ec

5/3/2008 12:43:26 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering | Software Metrics  |  Trackback
 Tuesday, April 29, 2008

While attempting to get ruby to connect to a SQL server using DBI.connect I ran into a bit of a challenge...getting the error message

'load_driver' is not a class/module

To resolve this :

  1. Download ruby_dbi the files from http://rubyforge.org/frs/?group_id=234&release_id=20222
  2. Create the directories under \ruby\lib\ruby\1.8\ called \DBD\ADO
  3. From your extract copy the file ADO.rb into that directory

This works with V1.8.5-24

Here's hoping this might save some one some time.

-ec


 

4/29/2008 5:41:22 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 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
Copyright © 2009 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: