Using node.js without the tyranny of express and jade.

function start(response) {
   console.log("Request handler 'start' was called.");
   var filename = 'view/start.html';
   fs.readFile(filename, "binary", function(err, file) {
      if(err) {
         response.writeHead(500, {"Content-Type": "text/plain"});
         response.write(err + "\n");
         response.close();
         return;
      }

      response.writeHead(200, {"Content-Type": "text/html"});
      response.write(file, "binary");
      response.end();
      });
}

Well, one of the cool things about node.js is that it is the smallest looking server I’ve basically ever worked with. Smaller then Apache. In a few lines of code you have your entire webserver there ready to accept requests. That part is nice and powerful. If you want a longer explanation  of node.js itself there are some here, and here. Seriously, read those explanations. 

Granted, I may not have really given it a good honest try, but i  can already tell I don't really like it. I expected at first i would just be able to write an HTML and javascript/Ajax page and then just ask node to host it, adding in server side code to go with the Ajax. But noooo, apparently you need to design the pages in something called Jade, and then have something called Express translate the pages. Now it reminds me of Ruby or Grails. I'm sure there are other interpreters then Jade/Express, but I have a feeling it's going to be another thing i have to learn anyway. I guess that's my biggest gripe so far.

Troubleshooting is the other issue I have with node.js. As i was going through the examples from the node on azure walkthrough, and on the node.js website, I would occasionally make some silly mistake. Maybe i didn't close a paren, or mixed some capitalization, but in either case the only error I would get is a page telling me there was a 500 error. I had no idea where the problem was. The js? My jade/express? Was a file in the wrong folder? No idea, i just had to comment things out until things worked again and then slowly get the new changes working. Hugely annoying. Some sort of message would be nice. I realize the language isn't compiled, but still.

With those things, I have a hard time finding a good reason to use node.js. Especially with the learning curve. I'll find a reason though! Sometimes when you have a hammer like this, you need to find a nail. :)

Part of the reason I wanted to learn some node.js was because Microsoft made it easy to put onto Azure, which is handy and a load of fun! All of the tooling to get settings, create the necessary files, and publish your project is all done through Powershell. Notepad and the command line is all you need. Like I mentioned already though, I have mixed emotions doing it this way.

The benefit to having node.js on Azure, is its lightweight, and you'll probably be able to do more with a smaller VM size - saving you some money. Also it was actually pretty simple to get a full node.js solution up and running on Azure. I don't know if it's going to be much easier to get it going on a stand alone server. Plus once your traffic grows, and you need more power, all you'll need to do is either increase the size of your instance, or increase the amount of instances. No additional configuration will be needed. That's going to be a whole lot nicer then your typical on premise server and you have to migrate it onto a bigger server later.

Don't let my lackluster review of node.js prevent you from trying it out yourself. Its a popular framework right now and it may solve a problem you have. In fact if it IS solving a problem you have, let me know in the comments, I'd be excited to hear about it.

Since I was already an AT&T customer, I figured I’d just continue with them. I thought about going to Sprint’s 4G, but I heard they were dropping their WiMax for LTE. (http://www.wired.com/gadgetlab/2011/10/sprint-lte-rollout-2013/) Since LTE must obviously be the technology to use. Since AT&T does 4G LTE, my decision was made. I went into the store, and their newest 4G MiFi was the Elevate. The coolest thing about the Elevate is you don’t need to connect it to your computer to use it. You basically turn it on, and it exposes a SSID you can connect to. In fact, you can connect 5 devices to it, so I can configure my phone to connect to it also. It needs to be charged so you *eventually* need to plug it in.

So now that I got it, how did it compare to real life usage? Pretty darn good. The first thing I did when I got it, was to do a speed test. The results were surprising. 24.03 Mb/s down, 9.79 Mb/s up, and a 49ms ping time. Amazing! I did all the stuff I normally do, lots of remote desktop, msdn, checking some news sites, all that junk. Also Outlook, Lync, and Live Mesh were running in the background syncing like they do. It’s also interesting to note that I only have 1 bar of signal with the 4G LTE.

To really get a good idea of what it can do, I watched a streaming video demonstrating how to write and use Reactive Extensions. (http://msdn.microsoft.com/en-us/data/gg577609). I didn’t experience a single hiccup. At this point I’m sold.

The only problem I experienced is one morning I turned it on, and it wasn’t using 4G LTE. Only the 4G. I thought this would be fine, but it was not. No No No NO. When it was on normal 4G, I was getting speeds of 1.48 Mb/s down, and .71 Mb/s up with a 105ms ping time. Unacceptable. This was with 4 bars of connectivity in 4G. I was a little concerned at this point that there might not be the LTE available where I’m at (inside an office building) all the time, and I’d have to constantly fall back to the crappier 4G. What I did, was turn the device off and then back on again, which gave me the LTE back. If I’m able to do that every time it drops to regular 4G, then that’s not a problem - just an inconvenience. Hopefully I don’t have to do that all that often.

As far as battery life goes, I give it a 3/5 in my mythical system where this is the only device that’s been judged. What I was hoping for would be I could connect it, throw it into my bag, and I’d have 4G LTE internet wherever I go until I go to bed. Then I’d plug it in. Sadly, that’s not the case. On a full charge, it got me though about 6 hours of my work day before the 15% alarm went off. Still that’s not bad.

All in all, I’d definitely recommend it for anyone who wants super-fast wireless 4G LTE internet wherever they go.

What Unity basically does, is provide an easy solution for dependency injection. With dependency injection, you can specify in a config file, which type of a class you want to instantiate without having to maintain different versions of solution, or rebuild. I’m going to start with a simple business scenario.

You are in charge of an inventory system for your company, and they have two locations. One is a simple where house where they maintain a small set of inventory items in SQL Server Express. The other is a larger one where the data is stored in Azure Tables. Other than that, the application is exactly the same. Just work with me on that one.

So, now as a developer, you need to program in two different ways of getting a hold of inventory data. To do this, we’re going to create an interface to represent the *very* crude operations our application will use to get data. Let’s start by creating a new C# console app. Call it “UnityHelloWorld”, and then create an Interface called IInventoryDataSource.

namespace UnityHelloWorld
{
    public interface IInventoryDataSource
    {
       InventoryItem LookupInventoryItem(int id);
       List<InventoryItem> GetAllItems();
       string GetSourceName();
       void AddInventoryItem(InventoryItem item);
    }
}

Great! Now, let’s go ahead and create two classes - One that will get the data from the SQL Server Express, and the other that will connect to Azure. We will put them in a folder called “Sources”. We won't actually connect them to the database or Azure, maybe we will address that in another blog post but for this example, we just want to get everything wired up.

namespace UnityHelloWorld.Sources
{
    class SQLExpressSource : IInventoryDataSource
    {
       public InventoryItem LookupInventoryItem(int id)
       {
          throw new NotImplementedException();
       }

       public List<InventoryItem> GetAllItems()
       {
          throw new NotImplementedException();
       }

       public string GetSourceName()
       {
          return "SQL Express";
       }

       public void AddInventoryItem(InventoryItem item)
       {
          throw new NotImplementedException();
       }
   }
}

The Azure class is basically the same thing except for the GetSourceName() method returns "Azure Source".

public string GetSourceName()
{
    return "Azure Source";
}

Now we have two different classes and they do the same things but in very different ways. As a developer, if we wanted to create this application for the different locations, we need to figure out how to use the class we want. Our options are:

1) Create an application for the Azure Data location, and another for the small SQL Express location.
2) Make it configurable so they can pick a location.

Now the first option might be great, except then we would have to maintain different versions. This is a horrible idea, but in the past I've done it. I remembering having two separate solutions, and the application did basically the same thing. I'd throw one onto a flash drive, and give it to the small shop up the road, and then install the other one on the web server at the big site. The biggest problem was always if there is a change, you need to fix it in both versions. Let’s never do it like this again.

Option #2 is a much better option than number one. You would create a field in app.config and set the environment you're in, and then write code to read that and instantiate the right class. It ends up looking something like this:

if (configSetting == "Azure")
{
Sources.AzureSource az = new Sources.AzureSource();
// do stuff......
}
if(configSetting == "SqlExpress")
{
Sources.SQLExpressSource ex = new Sources.SQLExpressSource();
//do stuff...
}

You can see how that gets hairy. What if we add a third data source? Or remove one? Besides, you need to either do this in every class that accesses data, or you need to create some Factory that creates it. In fact the basic factory pattern could help in that case. http://www.dofactory.com/Patterns/PatternAbstract.aspx.

Let’s do this in Unity instead. What Unity will let us do is use the interface to help us construct the class we need without having to hard code the class that gets used. I'll show you what I mean.

If you haven't already, go to the codeplex site and download the Unity. http://unity.codeplex.com/. Once you've got that, lets create an xml file to configure how Unity will work.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
   </configSections>
   <unity>
    <typeAliases>
      <!-- First comes the typeAlias, that lets us refer to UnityHelloWorld.IInventoryDataSource as just IInventoryDataSource -->
      <typeAlias alias="IInventoryDataSource" type="UnityHelloWorld.IInventoryDataSource, UnityHelloWorld" />
      <!-- Followed by Aliases for the sources-->
      <typeAlias alias="AzureSource" type="UnityHelloWorld.Sources.AzureSource, UnityHelloWorld" />
      <typeAlias alias="SQLExpressSource" type="UnityHelloWorld.Sources.SQLExpressSource, UnityHelloWorld" />
    </typeAliases>
    <containers>
      <container name="containerOne"> <!-- You can call the container anything you like. -->
        <types>
          <!-- Type mapping using aliases defined above -->
          <type type="IInventoryDataSource" mapTo="SQLExpressSource" /> <!-- The mapTo here lets us select which will get Resolved at runtime. -->
        </types>
      </container>
    </containers>
   </unity>
</configuration>

Now let’s go back to our Program.cs, and add some using files for unity, and to get a hold of our xml file:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;

...and now let’s add some code to wire up the config file with unity...

IUnityContainer container = new UnityContainer();

ExeConfigurationFileMap map = new ExeConfigurationFileMap();
map.ExeConfigFilename = "unity.config";
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
UnityConfigurationSection section = (UnityConfigurationSection)config.GetSection("unity");
section.Containers["containerOne"].Configure(container);

These 6 lines of code basically say "go get the unity.xml files, and set up unity to use it." And now that we have Unity all configured, let’s use it!

To mimic "using" unity at this point, we are going tell it we want a new IInventoryDataSource, and it will be of whatever type that we configured in the unity.xml file. If you notice in the xml files, we've told it to map to the "SQLExpressSource". Here's the one line of code that does that:

IInventoryDataSource ds = container.Resolve<IInventoryDataSource>();

Now, in that one line, we never actually tell it what Class we are going to instantiate. We did that in the config file. As you would imagine, if we call the GetSourceName() method on ds, it will return "SQL Express" - which is what we coded in the class. Though Unity, we basically did this:

IInventoryDataSource ds = new Sources.SQLExpressSource();

That's freaking cool.

If we wanted to switch it to the Azure source, all we need to do is change the xml file. If we built a new source, like FlatFileDataSource or OracleDataSource, as long as it implemented IInventoryDataSource, we can add it to the xml file, and choose to have that instantiated instead. The great benefit to this is we don't have to dig through code and find the old instances and replace it with new ones.

There we go! Hopefully you can see the power and simplicity of using Unity in your application. More and more developers are starting to use this as a way of storing connection strings, as well and configuring development, test, and production server environments.

Can you see a use for it with the project you're working on? Would you like to see it actually connected to Azure? Let me know! I've attached the project for you to download and see.

SSN/SocialSecirityNumber/Social
Username/username/UserName
Birthdate/DOB/dateOfBirth (all in different date formats)

Ugh.

The application itself was used to this ‘User’ object, and was basically programmed to use those fields. When it wanted to get the SSN, it would use objectname.SSN, and when it wanted to calculate the age of the user it used objectname.Birthdate in the equation. Now there are a variety of ways we can integrate the new data sources into the application.

One of the ways is to go into each class, and to add another field where the getter/setter pulls the other field. For example if I go into the class that pulls the Oracle data…

public string Social { get; set; }

public string SSN
{
   get { return this.Social;  }
   set { this.Social = value; }
}

 And then do this for all the different Classes. This is not the way you should do it. The class that gets the values from the database/active directory/wherever is doing its job of getting those values. They’re probably named like that in the database. Adding more fields or (the other thing that you thought of doing) adding a conversion method would break the Principal of Single Responsibility. This class is getting data from the source.

So we likely need a separate class that represents the data, and moves it around two whichever object needs it. A Data Transfer Object if you will. Since the application is designed to accept fields from the original Active Directory store, we can match those fields.

public class UserDTO
{
    public string Name { get; set; }
    public string SSN { get; set; }
    public DateTime DOB { get; set; }
    /* more fields... */
}

 Now, we can change the application to use this object instead of the old User class it was used to. That modification isn’t that time consuming. So now we have a new UserDTO object, and we feel better because it doesn’t rely on the old User object that was based on Active Directory. Now we need to get the data from the data sources into the DTO. One of the things we could do is create conversion methods in the DTO. While this would work, it again violates the principal that a class should be only doing one thing. Plus, if we did that, this is how we would use it.

public void DoStuff()
{
    DatabaseUser dbUser = new DatabaseUser();
    UserDTO user = UserDTO.ConvertFromDatabase(dbUser);
}

Not bad… notice how we have a DatabaseUser object (assume it came with data), then we created a UserDTO object and ran the conversion method to give us a NEW UserDTO object with values.

There’re really not anything wrong with this method, except it will require us to write conversion methods for the other types. What if we wanted to convert from a UserDTO to its old type? What if we needed this DTO in another part of the solution that doesn’t use/need/care about the old types? This DTO sure will carry a lot of baggage…

ENTER THE EXTENSION METHOD

So Extension Methods are basically static methods that attach themselves onto a parent class, without actually being in the parent class. Or as MSDN explains it: “Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.” That’s our winner right there. Let’s create an extension method to handle the conversion…

namespace Extensions
{
    public static class UserExtensions

    {
        public static SomeSolution.UserDTO ToUserDTO(this SomeSolution.DatabaseUser dbUser)
        {
            return new SomeSolution.UserDTO { Name = dbUser.Name, SSN = dbUser.SocialSecurityNumber, DOB = DateTime.Parse(dbUser.DateOfBirth) };
        }
    }
}

We plopped this in a new namespace, but you don’t necessarily need to do that. Also, the method is a public static method. Okay. So it looks like the conversion method that we had before. So… here’s the cool part.

Ah-ha! There is our extension method there! The conversion is done in a whole ‘nother class where we can manage it outside of the original class. Perfect.

Also, cool? Extension methods can extend the functionality of the String class. Remember, the String class is ‘sealed’ meaning it can’t be derived from (subclassed) but with Extension methods, we can add some extra functionality to strings! So look what I can do with our SSN.. 

public static System.String ToSNFormat(this string ssn)
{
    return String.Format("{0}-{1}-{2}", ssn.Substring(0, 3), ssn.Substring(3, 2), ssn.Substring(5, 4));
}

Now, when we go and look at the options for our SSN field…

Boo-ya!

public static void LogError(string message)
{
    Console.WriteLine("ERROR: " + message);
    Debug.Write(message, "DeathRayControllerERROR");
    if (!EventLog.SourceExists("DeathRayController"))
    {
        EventLog.CreateEventSource("DeathRayController", "Application");
    }
    EventLog.WriteEntry("DeathRayController", "ERROR: " + message, EventLogEntryType.Error);
    WriteToLogFile("ERROR: " + message);
}

This is great for logging and capturing Errors - things that may have crippled or stopped our application. Let’s add some additional methods to our class to long things that are not errors:

public static void logDebug(string message)
public static void logInfo(string message)
public static void logWarning(string message)

So many options! But why? Well, to give you the level of logging you want. We have Info, Debug, Warning, and Error now. Each of these can be used to log your application depending on what you need to see. Debug will generally be used for logging everything you could possibly want to know including queries, users accessing the application, and lengths of time things take to execute.  Info can be used when you want a good idea of what’s going on, but don’t want the entire granularity from Debug. Warning is generally used for things that you might be concerned about, but doesn’t generally effect the application running at this moment.
I’ve re-written the IsDeathRayTempOkay() method to use some more logging…

private bool IsDeathRayTempOkay()
{
    //Since we don't have an ACTUAL death ray (yet), lets simulate some conditions...
    try
    {
        Random rnd = new Random(DateTime.Now.Millisecond);
        int action = rnd.Next(0, 25);
        Logger.LogDebug("Death Ray Temp is: " + action);
        if (action <= 5)
        {
            Logger.LogError("Death Ray is too hot, please wait for cooling.");
            return false;//Death Ray is too hot! Can't use!
        }
        if (action == 13)
        {
            throw new DeathRayOutOfMemoryException(); //Weird exception we dont handle...
        }
    }
    catch (DeathRayOutOfMemoryException)
    {
        Logger.LogError("Exception Thrown! Death Ray is out of memory!");
        return false;
    }
    Logger.LogInfo("Temp is okay to fire Death Ray...");
    return true;
}

Notice now we have a few LogInfo, and LogDebug statements in there. Remember, you’re deciding what is getting logged and at what level. When you start the application, you select which levels you’re going to see.  If you’re going to set it to “Info”, for instance, you’ll see all the logging that’s occurred at Info, Warning, and Error. Setting it to Warning will give you all the logging at Warning and Error.
I’ve written statements to set my level of logging, and I configure them in the constructor of the DeathRayController class. You can set them up in a helper class, a config file, or whatever you want to use to support it. Here’s how I set mine up:

Logger.IsEnabled = true;
Logger.WriteToDbgViewEnabled = true;
Logger.WriteToEventLogEnabled = true;
Logger.WriteToFileEnabled = false;
Logger.SetDetailToDebug();
Logger.ApplicationName = "DeathRayController";

class Logger
{
    private static int logLevel; //a numerical representation of the log level.
    public static bool IsEnabled { get; set; } //when using this class, this will turn on and off the logging.
    
    public static bool WriteToFileEnabled { get; set; } //Turn on/off writing to the file
    private static string filePath; //if you're turning on writing to a file, you'd better set this path also!
    
    public static bool WriteToDbgViewEnabled { get; set; } //Turn on/off DbgView...
    public static bool WriteToEventLogEnabled { get; set; } //Tuen on/off Event Logging....

    public static string ApplicationName { get; set; }

    //Default Constructor. Since this Class will not be instansinated, no reason to make it a public constructor.
    private Logger() { }

    /**
	 This function writes to the console whatever is passed into it.
	 In this function, it checks to see if enabled is false, or if the log level is outside of range.
	 If either of those condtiions are true, the function will not print the message.
	 logLevel can be only be 0 for this to print.
	 */
     public static void LogDebug(string message)
     {
         if (IsEnabled == false || logLevel > 0)
         {
             return;
         }
         Console.WriteLine("DEBUG: " + message);
         WriteToLogFile("DEBUG: " + message);
         WriteToDbgView("DEBUG: " + message);
         WriteToEventLog("DEBUG: " + message, EventLogEntryType.Information);
     }

     /**
     This function writes to the console whatever is passed into it.
     In this function, it checks to see if enabled is false, or if the log level is outside of range.
     If either of those condtiions are true, the function will not print the message.
     logLevel can be either 0 or 1.
     */
     public static void LogInfo(string message)
     {
         if (IsEnabled == false || logLevel > 1)
         {
             return;
         }
         Console.WriteLine("INFO: " + message);
         WriteToLogFile("INFO: " + message);
         WriteToDbgView("INFO: " + message);
         WriteToEventLog("INFO: " + message, EventLogEntryType.Information);
     }

     /**
     This function writes to the console whatever is passed into it.
     In this function, it checks to see if enabled is false, or if the log level is outside of range.
     If either of those condtiions are true, the function will not print the message.
     logLevel can be either 0, 1, or 2.
     */
     public static void LogWarning(string message)
     {
         if (IsEnabled == false || logLevel > 2)
         {
             return;
         }
         Console.WriteLine("WARNING: " + message);
         WriteToLogFile("WARNING: " + message);
         WriteToDbgView("WARNING: " + message);
         WriteToEventLog("WARNING: " + message, EventLogEntryType.Warning);
     }

     /**
     This function writes to the console whatever is passed into it.
     In this function, it checks to see if enabled is false, or if the log level is outside of range.
     If either of those condtiions are true, the function will not print the message.
     Note: When logging is enabled, this will ALWAYS print.
     */
     public static void LogError(string message)
     {
         if (IsEnabled == false || logLevel > 3)
         {
             return;
         }
         Console.WriteLine("ERROR: " + message);
         WriteToLogFile("ERROR: " + message);
         WriteToDbgView("ERROR: " + message);
         WriteToEventLog("ERROR: " + message, EventLogEntryType.Error);
     }

     public static void SetPath(string path)
     {
         filePath = path;
     }

     /**
     This function will allow you to maunally set the logging level.
     The value can be set to 0, 1, 2, or 3. If you go outside the acceptable levels, 
     this function will set it to the closest acceptable level. 
     0: Debug
     1: Info
     2: Warning
     3: Error
     Alternatively, the built-in methods for setting the logLevels can be used.
     */
     public static void SetLogLevel(int level)
     {
         //Logging can come in 4 different levels:
         //	0: Debug
         //	1: Info
         //	2: Warning
         //	3: Error
         logLevel = level;
         if (level < 0) { logLevel = 0; }
         if (level > 3) { logLevel = 3; }
     }

     public static int SetLogLevel() { return logLevel; }

     /**
     Built-in method for setting the logLevel to 0 (Debug).
     */
     public static void SetDetailToDebug() { SetLogLevel(0); }

     /**
     Built-in method for setting the logLevel to 1 (Info).
     */
     public static void SetDetailToInfo() { SetLogLevel(1); }

     /**
     Built-in method for setting the logLevel to 2 (Warning).
     */
     public static void SetDetailToWarning() { SetLogLevel(2); }

     /**
     Built-in method for setting the logLevel to 3 (Error).
     */
     public static void SetDetailToError() { SetLogLevel(3); }

     private static void WriteToLogFile(string message)
     {
         if (WriteToFileEnabled == false) { return; }
         System.IO.StreamWriter file =  null;
         if (filePath == null)
         {
             Console.WriteLine("FilePath must be set in order to write to logs.");
             return;
         }
         try
         {
             file = new System.IO.StreamWriter(filePath, true);
             file.WriteLine(message + "\n");
         }
         catch (System.IO.PathTooLongException)
         {
             Console.WriteLine("A PathTooLongException occured. Maybe try shortening the path, buddy.");
         }
         catch (System.IO.IOException iox)
         {
             Console.WriteLine("An IOException occured. Something is wrong with my ability to write the file.\n" + iox.ToString());
         }
         catch (Exception ex)
         {
             Console.WriteLine("Writing to the file failed. Here's what happened:");
             Console.WriteLine();
             Console.WriteLine(ex.ToString());
         }
         finally
         {
             if (file != null)
             {
                 file.Close();
             }
         }
     }

     private static void WriteToDbgView(string message)
     {
         if (WriteToDbgViewEnabled == false) { return; }
         try
         {
             Debug.Write(message, ApplicationName == null ? ApplicationName : "");
         }
         catch (Exception ex) { } //Failed...
     }

     private static void WriteToEventLog(string message, EventLogEntryType eventType)
     {
         if (WriteToEventLogEnabled == false) { return; }
         try
         {
             EventLog.WriteEntry(ApplicationName == null ? ApplicationName : "", message, eventType);
         }
         catch (Exception ex) { } //Failed...
     }
  }

Writing to the Event Log

Instructions on how to write to the event log are here: http://support.microsoft.com/kb/307024, so lets use that to add a line to our method and write to the event log also:

class Logger
{
    public static void LogError(string message)
    {
        Console.WriteLine("ERROR: " + message);
        Debug.Write(message, "DeathRayControllerERROR");
        if (!EventLog.SourceExists("DeathRayController"))
        {
            EventLog.CreateEventSource("DeathRayController", "Application");
        }
        
        EventLog.WriteEntry("DeathRayController", "ERROR: " + message, EventLogEntryType.Error);
    }
}

Here we are checking to see if the DeathRayController exists as a source, and if not, we create it (the source is really just the name of the application.) Then... We write to it, and specify that it should go into the event log as an error. Easy-peasy (yeah I went there). If we run this, and pull open the event log, we can see the entries in there.

There we see an error, when it occured, the source is our DeathRayController. There is an event ID also, and it's optional when writing to the event log. We could use that if we like to give a numerical error to our error, this way we don't have to read the contents. 1 could mean a SQL problem, 2 could mean a memory error, 739 could mean someone had installed the death ray backwards. It's really up to you. I didn't specify an event id.

If we look at one of the errors int he event log, we can see the details of the error we logged...

There is pleanty of room for LOTS of text here, so when writing to the event log, feel free to really add the information you need in there.

Like I said, the event log really isn't for debugging as much as it is for logging, and it's more of an admin thing then a developer tool. It's so easy though to write to it, you might as well just do it. It's great for administrators who are used to being in there, and there are 3rd party tools that monitor the event log, like EventSentry, or LogRhythm, that can help parse those things out.

Now, event logging is good for things that have HAPPENED, and writing to the event log is good for administrators, but annoying for developers. You know what works fairly decently for developers? Writing to a text file.

A Simple Text File

The best things about text files, is their really, really simple, and if you have access to the application folder, you can look at the text file (probably). The problem with text files, is you might not have the ability write to the folder, system IO problems, and the size of the text file. Generally, if you DO write to a text file, you'll want to create a new file based on the date, and you'll want to throw it all in a try/catch in case you're getting more errors then you can successfully write. Here is a method that writes errors to the file...

private static void WriteToLogFile(string message)
{
     //set the path to something you can write to...
     string filePath = string.Format(@"C:\DeathRayControllerLog_{0}-{1}-{2}.txt", DateTime.Now.Year, DateTime.Now.Month, DateTime.Now.Day);
     System.IO.StreamWriter file = null;
     if (filePath == null)
     {
         Console.WriteLine("FilePath must be set in order to write to logs.");
         return;
     }
     try
     {
         file = new System.IO.StreamWriter(filePath, true);
         file.WriteLine(message + "\n");
     }
     catch (System.IO.PathTooLongException)
     {
         Console.WriteLine("A PathTooLongException occured. Maybe try shortening the path, buddy.");
     }
     catch (System.IO.IOException iox)
     {
         Console.WriteLine("An IOException occured. Something is wrong with my ability to write the file.\n" + iox.ToString());
     }
     catch (Exception ex)
     {
         Console.WriteLine("Writing to the file failed. Here's what happened:");
         Console.WriteLine();
         Console.WriteLine(ex.ToString());
     }
     finally
     {
         if (file != null)
         {
             file.Close();
         }
     }
}

Then we simply add another item to our method...

public static void LogError(string message)
{
     Console.WriteLine("ERROR: " + message);
     Debug.Write(message, "DeathRayControllerERROR");
     if (!EventLog.SourceExists("DeathRayController"))
     {
         EventLog.CreateEventSource("DeathRayController", "Application");
     }
     EventLog.WriteEntry("DeathRayController", "ERROR: " + message, EventLogEntryType.Error);
     WriteToLogFile("ERROR: " + message);
 }

Notice in the WriteToLogFile class, I catch a bunch of different exceptions, this is important! You don't want your logging to cause even MORE errors then the application already has. Writing to a text file can cause all sorts of problems with security, naming, the file already being opened, the file being gone, etc. It's best to just catch and ignore then introduce more problems. However if everything is working well, having a generic text file to see errors can be immensely helpful, especially if your logging more then just errors. Thats right MORE THEN JUST ERRORS! I'll talk about other types of logging in Part 3.

In the past, I've had several instances when I was sitting at my desk and someone would come over and say "Casey! Your death ray controller application is down!" in which I would proceed to spend time debugging the application to find out why it all of a sudden wasn't working when it used to. Maybe the database is down... maybe the host machine ran out of resources... maybe there was a change to a server that caused one of my components to break. It was usually something odd. But the problem wasn't that it broke, the problem was the length of time it took to find what the problem was. "What do you mean you have no idea?!" They would say. "You WROTE the program!"

Soon I learned that adding some logging to the application can QUICKLY shorten the time it takes to determine what the problem is. It also helps to give you some piece of mind that the application is running, so you can feel comfortable handing the application off to someone else.

There are a couple of different ways of logging your application, and a couple of different situations in which you should do the logging. For logging you have: Event Logs, DebugView, text file, web page, and console. Event Logs are the least helpful to other programmers, but most helpful to admins. The opposite is true for DebugView. Text files, web pages, and the console works good also for some cases and can be a helpful way to check the status of your application.

So let's make a class called "DeathRayController", and do some logging against it...

class DeathRayController
{
    public DeathRayController() { }
    public void Zap()
    {
        if (IsDeathRayConnected() == true & IsDeathRayTempOkay() == true)
        {
            Console.WriteLine("ZZZZZAAAAAPPPPPP!!!!");
        }
    }
    
    private bool IsDeathRayTempOkay()
    {
        //Since we don't have an ACTUAL death ray (yet), lets simulate some conditions...
        Random rnd = new Random(DateTime.Now.Millisecond);
        int action = rnd.Next(0, 20);
        if (action <= 5) { return false; } //Death Ray is too hot! Can't use!
        if (action == 13) { throw new DeathRayOutOfMemoryException(); } //Weird exception we dont handle...
        return true;
    }

    private bool IsDeathRayConnected()
    {
        //again, no death ray, so lets simulate some conditions.
        Random rnd = new Random(DateTime.Now.Millisecond);
        int action = rnd.Next(0, 20);
        if (action == 5 | action == 7 | action == 14) { throw new UnableToConnectToDeathRayException(); } //unable to connect!
        return true;
    }
}

public class UnableToConnectToDeathRayException : Exception { }
public class DeathRayOutOfMemoryException : Exception { }

...and then we run through it 10 times...

static void Main(string[] args)
{
   DeathRayController dr = new DeathRayController();

   for (int i = 0; i < 10; i++) //Lets use the Death Ray 10 times!
   {
      dr.Zap();
      Console.WriteLine();
      System.Threading.Thread.Sleep(1000); //Just wait a bit...
   }
}

Now when we run this, a few things can happen. We could see a console output ZZZZZAAAAAPPPPPP!!!!, or we can see nothing, or we throw an exception.

If this is a console application, we can just display the problem on the console, and hope then when it's run, someone will see this. If it's a service though (death ray service?), nobody will get to see a console, or maybe it's run on a remote machine somewhere that's not always monitored (on the moon!)

This is when logging comes in handy.

Let us create a logging class, something that we can use for... logging.

class Logger
{
   public static void LogError(string message)
   {
       Console.WriteLine("ERROR: " + message)
   }
}

Then, we can alter our DeathRayController class to take advantage of the logging, here I've altered the IsDeathRayTempOkay class...

private bool IsDeathRayTempOkay()
{
     //Since we don't have an ACTUAL death ray (yet), lets simulate some conditions...
     try
     {
         Random rnd = new Random(DateTime.Now.Millisecond);
         int action = rnd.Next(0, 20);
         if (action <= 5)
         {
             Logger.LogError("Death Ray is too hot, please wait for cooling.");
             return false;//Death Ray is too hot! Can't use!
         }
         if (action == 13)
         {
             throw new DeathRayOutOfMemoryException(); //Weird exception we dont handle...
         }
     }

     catch (DeathRayOutOfMemoryException)
     {
         Logger.LogError("Exception Thrown! Death Ray is out of memory!");
     }

     return true;
}

I've highlighted the area of my code when we access our logger. Again, it's only going to log to the console. But that's okay for now... lets see this thing in action...

Okay! now we see how our our logger is logging to the console... Lets expand it a little bit, and write to the DebugView.

What the heck is the DebugView?

Debug view is part of the SysInternals that you can download from technet here. The benefit to DebugView, is you can write to the debugger and it will display live on the DebugView application. No need for the console, and you can access it from a different machine! Let's alter our class so we can take advantage of the DebugView application.

First, we need to add a reference to

System.Diagnostics;

...and then all we have to do is add a new line to our class...

public static void LogError(string message)
{
    Console.WriteLine("ERROR: " + message);
    Debug.Write(message, "DeathRayControllerERROR");
}

now, if we open up DbgView, and run our application a few times, we can see the log that's produced:

As you can see, we get all the benefits of console-like logging without even having a console window. Again, this works great when you have an application that doesn't open in a console window, or isn't installed on a machine that you have access to. Just like a console window, you can see this live as the application is running. The problem is, of course, it wont tell you what WAS happening, only what IS happening. Though the DbgView still has it benefits to being used. For knowing what HAS happened, you need to either write to a text file, or write to the event log.

In Part 2, I will discuss connecting to the Event Log...

So right now I'm sitting on united flight 445 from BWI to Denver, and so far its been a typical flight. We've just been told by Potomac departure that were cleared to 17000 ft. How could I possibly know this? Well, when you fly on united and turn your headset to channel 9, you can hear live air traffic control. Everything the pilots hear, you can hear. I love it! Being a pilot was one of the things i would (and still) have wanted to do. Since i don't know how to fly an airplane - yet - listening to air traffic control is the next best thing.

"Climbing to 270 (27000ft), with continuous light chop."

Flying on united isn't the only way to get my air traffic control fix, if you visit liveatc.net, you can listen to live air traffic control from many airports and centers all over the world. If your feeling super piloty you can even fire up flightaware.com, and see the live locations of planes that are in the air. Combine that with the air traffic control your listening to, and you can be your own air traffic controller, just without the crippling stress, and risk of accidently killing hundreds of people.

Sometimes when I'm sitting and programming, I like to pick an airport and listen. Usually nothing super interesting is going on, but I find its still worth listening to. It keeps me focused on programming, and provides me with a bit of entertainment.

Climbing to 360. Woot! We will probably stay here for a while, as this is probably our cruising altitude. The pilot also asked how the ride up ahead was, and ATC said they had no reports of problems. Boring. But I'm on the boring flight, and boring is good.

Also, if your not familiar with listening to ATC, once you're outside of the airport, your flight is asked to change frequencies to a regional center. These centers basically monitor the traffic in their area, once you leave the area, your flight is passed to another center. Once you get close to landing, you're passed to that airport.

Now that were cruising, the drinks are coming out. I'll take them up that.

Next time your flying united, I definitely suggest listening. If you've listened before, have you heard anything interesting? Why do you listen?