Sql Tools - Profiler and SqlCommand

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/sql_tools__profiler_and_sqlcommand.htm]

Everyone knows how to use SQL Management Studio, but there are two other useful tools that SQL Server 2005 has.

• SQL Profiler - This lets you profile the SQL Server calls. It's very effective to determine what page is making which calls (and how long those calls take). It's much easier to just run profiler, as opposed to stepping through all the code to find what SP gets triggered when you click Button X.
• SqlCmd - This is the command line for SQL Server (replaces osql for SQL 2000). It's useful when you need to Automate, or don't want the full SQL GUI installed (such as when you have limited space on a build server).

Converting to a string

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/converting_to_a_string.htm]

In web development, we constantly need to get string values (from objects of different data types) that we can display to the user. For example, ints, dates, bool, and even custom objects eventually need to be rendered as some string. There are different ways to handle this conversion, but I think one of them is best.

      //Fail if type is wrong, such as an integer
      //Compile error: Cannot convert type 'int' to 'string'
      string s1 = (string)i;

      //Fails if object is null
      string s2 = i.ToString();

      string s3 = Convert.ToString(i);

As the code snippet shows, there are at least three standard ways: (1) casting, (2) calling the ToString method - which every object has, and (3) using the System.Convert class. I think the third way is often the best because the first will throw a compile error if the the object is an incompatible type (like converting a value type int), and the second will fail at run time if the object is null (not possible with value types like integers, but very likely with other reference types). However, using System.Convert handles both of these cases - you can convert value types and handle null instances of reference types. This lets you use a consistent approach for your conversions.

'__pendingCallbacks[...].async' is null or not an object

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/__pendingcallbacksasync_is_null_or_not_an_object.htm]

I was doing so ASP.Net 2.0 callbacks (see an overview here: http://dotnet.sys-con.com/read/192509.htm), and kept getting this error when I did a document.location redirect on the ReceiveCallback JavaScript function.

Microsoft JScript runtime error: '__pendingCallbacks[...].async' is null or not an object

Looks like a flagrant Microsoft bug: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101974

People have different suggestions

• http://developers.de/blogs/damir_dobric/archive/2006/03/02/4.aspx?Ajax_CallBack=true
• http://blogs.sqlxml.org/bryantlikes/archive/2005/12/20/4593.aspx

What worked for me is the setTimeout. However, I needed to pass a parameter to the variable, so I used a technique like so:

var _gRValue;
function ReceiveCallback(rValue)
{
  _gRValue = rValue;
  window.setTimeout('__ReceiveCallback(_gRValue)',0);
}

function __ReceiveCallback(rValue)
{
  //Do stuff here
} //end of method
 

To handle the nature of setTimeout, I stored the returned data in a member variable.

Backwards: "I wanted to do Unit Tests, but my manager wouldn't let me"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/backwards_i_wanted_to_do_unit_tests_but_my_manager_wouldnt_l.htm]

I've heard this before when I give interviews or meet new developers at tradeshows.  The thinking seems to go that "While I'd personally love to do this best practice of 'Unit Tests', adding them takes a lot longer (like adding a new development phase), which costs extra money, therefore I need managerial approval." This is fundamentally backwards.

The whole point of Unit Tests is that:

1. They save you time: Obviously with regression testing, but also by stubbing out the context so you can very quickly test things in isolation (without wasting tons of time constantly re-setting up that context). They also help you to see all the boundary test cases, and hence prevent future bugs.
2. They are free to use - open source tools like NUnit can be downloaded for free and instantly used for your own personal development. It's not like you need to purchase a separate expensive tool, or hire out some auditor to review your code.
3. You write tests as you develop, not afterwards.

Here's an analogy: Think of your schedule like a bucket, and your tasks are like rocks that fill up the bucket. You can't increase the size of your bucket, or decrease the number of rocks, therefore the bucket (i.e. your schedule) seems full. However, there are gaps between the rocks (just like there are gaps between tasks - like setting up the context and regression testing). You could pour sand into a full bucket, in the cracks in between the rocks. That's what unit tests are like. If you do them as you develop, you can squeeze them into your schedule without overflowing it.

What makes programming fun?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_makes_programming_fun.htm]

A brainstorm of some ideas. (Feel free to add your own in the comment section).

• Writing new, interesting code
• Not hunting down regression bugs
• Not repeating yourself
• Sharing work with others
• Learning new things
• Seeing your code just work

Certain methodologies, like Agile and TestDriven.Net are designed to fulfill many of these things. For example, by having sufficient unit test coverage, you minimize your regression bugs and get to focus more on new things.

The myth of the "perfect past project"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_myth_of_the_perfect_past_project.htm]

In today's world, developers switch projects a lot. Whether it's a consultant at the same company who keeps jumping between 3 month projects, or a developer who switches jobs every two years, most people can refer to some "previous" job. I notice an interesting trend, that some people insist that they've had that perfect project in the past - the one (unlike their current job) where everything was done properly. It almost comes across as their development life was great before (i.e. their last job did it "right"), but their current employer is a bozo. Many people can refer to a good previous project because some other star (not them) made it good. For example, a past project may have had awesome process or tools - but someone else set it up. It seems like a bluff (or the grass is always greener on the other side thinking), but because you don't know about their previous project, and have to just take their word for it. But, you can always ask what they did to make that last project so great, and what they can do on the current team (besides just reminiscing about the "Good old days") to make the current project better.

How to make maintenance easier

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_to_make_maintenance_easier.htm]

Almost everyone would rather create something new than fix something broken (especially someone else's broken code). However, it's inevitable that some maintenance will always be required. Here are some ideas to make maintenance easier:

• Reduce the amount of work that must be maintained by refactoring your code.
• Add Unit Tests for easier regression testing, and to make sure that your maintenance doesn't break something else.
• Document your work so that it's easier to understand, perhaps with inline comments (maybe using NDoc), wikis, or more traditional word documents for feature designs.
• Design you code to be maintainable - perhaps use simpler algorithms (if all else is equal), loosely couple components so that it's easier to understand, make flexible code, etc...