Continually learning better coding methods

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

Coding requires constant learning. Here are some ideas to help with that:

1 - Be prepared to spend not just time, but mental energy.

2 - Find ways to get input:

• Other Opinions:
  • Code Reviews - both having people look at your code, and looking at other's code.
  • Read blogs
  • Read articles
  • Read the documentation. If you're using a collection, read the documentation to see how it suggests enumerating through or referencing it's items.
• Experiment on your own code
• Reflect back on your code
• Ask yourself, "does this make sense?". If your own code doesn't make sense to you, it probably won't make sense to others.
• Make sure that you're not re-inventing the wheel. Look for resuable components.

3 - Make the intent of your code clear so that others can help. If Bob doesn't know what you're trying to do, Bob can't easily help you.

• Use smaller methods
• Add helpful comments that explain intent, not just repeat the steps that the code is doing
• Abstract out context and dependencies such that it's easier for people to understand what you really want.

There's obviously a lot more to say on this, I'll make some follow-up posts.

How to send the Console output to a string

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

Sometimes when writing a tool or automated process, you want to read in the console output and send it to a string. From there, you can do whatever you want to it, such as parse for info. For example, a third-party tool (not necessarily even built with .Net) may display result information to the console, and you may want that info as part of some bigger process. The classes to do this reside in System.Diagnostics.

    public static string GetConsoleOutput(string strFileName, string strArguments)
    {

      ProcessStartInfo psi = new ProcessStartInfo();
      StringBuilder sb = new StringBuilder();
      try
      {
        psi.WindowStyle = ProcessWindowStyle.Hidden;
        //Need to include this for Executable version (appears not to be needed if UseShellExecute=true)
        psi.CreateNoWindow = true;   
        psi.FileName = strFileName;
        psi.Arguments = strArguments;
        psi.UseShellExecute = false;
        psi.RedirectStandardOutput = true;
        psi.RedirectStandardError = true;

        Process p = Process.Start(psi);

        sb.Append(p.StandardOutput.ReadToEnd());
        sb.Append(p.StandardError.ReadToEnd());

        p.WaitForExit();

      }
      catch (Exception ex)
      {
        sb.Append("\r\nPROCESS_ERROR:" + ex.ToString()); ;
      }
      return sb.ToString();

    }

USNAF - Microsoft's National Architect Forum

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

I just got back from Microsoft's National Architect Forum in Vail, Colorado - and wow! To be at a conference with 200 top architects was humbling. There are several big things I saw:

1. Microsoft is really maturing on Enterprise Architecture and agile processes.
2. Paul Glen spoke (author of the great book Leading Geeks). A lot of good insight about how to manage geeks.
3. There's a lot of good architects out there.

Perhaps the easiest thing to describe was Paul's closing speech. He had several good points from his book:

• Geeks are different than other people because their productivity is based on thinking not behavior.
• Power is useless with geeks because power only controls behavior, but Geeks deliver productivity via thought.
• "Geekwork" is different than normal work. For example, in geekwork because technology moves so fast, the moment you step away from implementing code to become a manager, technology moves on. Therefore managers often know less about direct coding than the geeks they manage. In most other fields, managers know more than the people they manage.

Viewing the source of an Html File, even with the ContextMenu disabled

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

In IE, you can view the source of any file through either the context menu or tool bar. However, sometimes there are design reasons to disable or hide these. For example, you can prevent the content menu by putting this in the a script in the HTML body:

document.oncontextmenu=new Function("return false");

And you can hide toolbars by opening up a new window and passing in the appropriate options:

window.open(...);

However, even if a site does this, you can still view the source through the VS.Net debugger. Simply start debugging one of your own apps, then navigate to the target site in the address bar, and you'll see full source in the Script Explorer window.

ASP.Net 2.0 Callbacks: Using callbacks to create a rich Web UI

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

I just had an article on ASP.Net 2.0 Callbacks published in .Net DJ. It provides a basic intro, and some more advanced uses like handling multiple callbacks and passing multiple data values.

Hashtables in JavaScript

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

As a bit of trivia for the day, JavaScript can handle pseudo-hashtables, via the Array object. You can reference the item with its key, and enumerate through all the objects.

function DoHashTest()
{
  var h = new Array();
  h["aaa"] = "Aardvark";
  h["bbb"] = "Babboon";
 
  var s = "";
  //This won't work, length will be 0.
  for (var i = 0; i < h.length; i++)
  {
     s += h[i];
  }

  //Cycle through like a hash:
  for (var i in h)
  {
    s += i;
  }
}

MSBuild error MSB3073 "The batch file cannot be found"

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

We've migrated to MSTest, and are running tests through MSBuild. I came across an interesting issue (that seems like a bug).

Normally I would expect that if the test passes in Test Viewer (the UI), then it would also pass when I run it in MSTest from the command line, and it would still pass when I call it from MSBuild. However, I found this not always so.

One of my tests wrote out files to the temp directory, as generated by "System.IO.Path.GetTempPath()". I then cleaned up the test output by deleting the directory, and recreating it. This worked fine in both UI, and MSTest, but failed in MSBuild with the following error:

Run Configuration: Default Run Configuration
The batch file cannot be found.
C:\myProject\myBuild.msbuild(21,5): error MSB3073:

The command ""C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MsTest"
/testcontainer:C:\myTests.dll /resultsfile:myOutput\UnitTests.trx" exited with code 1.
Done building target "UnitTest" in project "myBuild.msbuild" -- FAILED.

By appending a sub directory to the temp directory, like "System.IO.Path.GetTempPath()" + "temp\", the tests all passed again. My guess is that MSBuild sent something to this output directory that my cleanup method was inadvertently deleting.