# Thursday, August 26, 2004

This is more of a note to myself, nothing too interesting. Simply some links to interesting articles on patterns and such:
Enterprise Development Patterns
Patterns & Practices
Improving .NET Application Performance and Scalability

 

Kick It on DotNetKicks.com

posted on Thursday, August 26, 2004 6:20:15 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Sunday, August 22, 2004

For one of the innumerable personal apps I am writing, I decided to store some values in session variables. However, I loathe the syntax for both getting and setting such variables:

Session["UserID"] = userID;

GetSomeData(Convert.ToInt16(Session["UserID"]));

Yuck. Why? The literal strings. I want strongly-typed stuff. I don't want to have the opportunity to accidentally type Session["UsrID"] and deal with resulting issues (I know, it is not that big of a deal, but you know), I want design-time features like code completion/Intellisense. So, at first my idea was to create an enum containing all of the session variables I would use for the app, like so:

public enum SessionVariables
{
   UserID, ClientID, etc.
}

And then I would do this:

Session[SessionVariables.UserID.ToString()] = userID;

That gave me Intellisense and strong typing (more so than a string literal), reducing the chance that something would be typed incorrectly.

But I still don't like the whole "Session[...]" thing. In order to understand my solution, I first must say that I have created a base class for my site's pages. Every ASP.NET page must inherit from the System.Web.UI.Page class at some point, either directly or as a result of a deeper inheritance structure, and I have an intermediate class which inherits from that class, and then all of my pages inherit from that derived class. So, the solution I came up with (I doubt this is in any way original, nor do I feel it is necessarily the ideal) involves creating properties on that base class. For example:

      public short User_UserID
      {
         set
         {
            Session["UserID"] = value;
         }
         get
         {
            return short.Parse(Session["UserID"].ToString());
         }
      }

As long as the page inherits from this intermediate base class instead of inheriting directly from the Page class, I have an easy, strongly-typed means of obtaining session variables without using the nasty syntax (I only need to use it in the property). So, now I can do this in my code-behind files:

User_UserID = userID;

GetSomeData(User_UserID);

Much sexier, and as an added bonus it abstracts WHERE I store the variables. So, if I want to, I can change that property in the base class so that instead of storing this value in session, I can store and retrieve it from a cookie should I desire to do so. (By the way, the reason I preface the property with the "User_" is because it makes it gives the property name a context, in this case these are properties associated with the current User. Also, one of the variables I am storing is a ClientID and that is already the name of a property of the Page class, so I have a collision there.)

Now, the question I have is this: is this a good way to accomplish this? It works, and I personally like it, but I have only thought it through for about 25 minutes.

Kick It on DotNetKicks.com

posted on Sunday, August 22, 2004 5:48:02 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [2]
# Wednesday, August 18, 2004

[Note: This is by NO means an exhaustive discussion of code gen, and only illustrates the most miniscule example of what you can do and how it can be done.]

One of the topics I really have an interest in is code generation ('code gen' for short). Some call it useless, while others, such as myself, find it compelling. I don't know how I would live without it, since writing redundant code is one of those things I have much apathy for. Why write code that can be generated with the click of a button?

For those not familiar with this concept, I will give you a simplified example. Let's say you have a SQL Server database that has a table with the following schema:

Now, you usually have to perform the usual CRUD operations on such a table, with various variations, but for the most part, we can generally assume you want to INSERT new records into this table, SELECT all the data from the table, UPDATE records, and DELETE records. You get the idea.

We can *easily* generate a set of 4 stored procedures (sprocs) to do these things. It is ridiculously easy in fact. There are sprocs extant after you install SQL Server that will allow you to obtain metadata about tables and their fields, their relationships, etc. Once we have this data, we can generate our sprocs. Example code for generating the SELECT sproc:

    // let's assume the name of the table is in this string variable, "tableName"
    // and all of the fields of the table are in this array variable, "fieldNameArray"
    // (we obtained that info by querying the database for the metadata)

    string selectAllSproc = "CREATE PROCEDURE " + tableName + "_SelectAll AS SELECT ";

    for(int i = 0; i < fieldNameArray.Length; i++)
    {
       selectAllSproc += fieldNameArray[i];
       selectAllSproc += (i == (fieldNameArray.Length - 1)) ? " " : ", ";
    }

    selectAllSproc += "FROM " + tableName + " GO";

When this is done, our string selectAllSproc has the value:

CREATE PROCEDURE User_SelectAll AS SELECT UserID, Username, Password, FirstName, LastName, DateCreated, Status FROM User GO

So, if we were to print that to a text file (probably would be formatted better), we would have a script we could run, thus creating the sproc in our database (obviously there is a little more to it, but really that is the essence).

Pretty nice. Imagine your database has 45 tables. Do you really want to hand-craft all of that code? You should be shaking your head "NO" right now. So, not only does this save us time, but it improves consistency, because we know that if this runs right once, it will do the same for all tables (Again, I am generalizing, I don't want to write a book on the subject!).

So, in our schema, we have this field "Status" right? Maybe I only want that column to contain 2 different values, namely "Active" or "Inactive". Well first off we need a check constraint attached to that table indicating that those are the only valid values. Again, we can query the database and find this out so that programmatically, we can access that info. Well, this is perfect for generating an enumeration like this:

    public enum Status
    {
        Active, Inactive
    }

This can then be used in our code when we want to give someone the option of choosing a value for that field, thereby helping strongly-type the data being passed around (read: maintain the integrity of data, thereby reducing the possibility of errors).

Although simplified, I hope this example shows just what kind of possibilities there are for using code generation in your development process. It can truly be a boon to productivity and overall code quality if done well.

Kick It on DotNetKicks.com

posted on Wednesday, August 18, 2004 6:48:16 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Wednesday, August 11, 2004

Artificial black holes: on the threshold of new physics

Can that be a good thing? Help me live, we don't need to be creating black holes so close to home, don't these scientists realize that although they may think they know what they are doing, this could be disastrous?! Apparently splitting the atom and fusing hydrogen is not enough to keep these types happy. No, they want to go and create mini universe-eating objects. I think they need a new hobby or else we are all in trouble!

This is the part of the article I personally love:

"In reality, there is no risk posed by creating artificial black holes, at least not in the manner planned with the LHC."

"[A]t least not in [this] manner?!?!?!" Oh so you acknowledge that, although these guys at the LHC are not doing it, there is some other manner in which to create these things, and maybe that is not so safe! Great, go ahead and plant the idea in our heads (and the heads of those that might want to use it to their advantage!). Yeah, we thought nukes were bad? No, the next WMDs are going to be little black holes. Seriously, I wonder just what conditions happen to cause the manner in which these are made to become critical? One well-placed black hole would ruin our day for sure. It would just feed itself until it had eaten all of earth and then start feeding on our solar system in some sort of cosmic all-you-can-eat buffet.

"The black holes produced at CERN will be millions of times smaller than the nucleus of an atom; too small to swallow much of anything. And they'll only live for a tiny fraction of a second, too short a time to swallow anything around them even if they wanted to."

Oh really?!?! You sure about that? Scientists have had many theories in the past that have been proven incorrect, and I don't think this is one we want to be proven as such by virtue of our planet getting sucked into one. Seriously, can't we do this somewhere else, say maybe one quintillion light-years away from here?

"If it makes you feel any more comfortable, we're pretty sure that if the LHC can produce black holes, then so can cosmic rays, high-energy particles that smash into our atmosphere every day. There are probably a few tiny black holes forming and dying far above you right now. So I think we should all relax, fire up the Large Hadron Collider, and get ready for a view of the universe that we've never seen before."

Oh sure, I feel so much better. Whatever! Stop this madness now! I think Senator Kerry should address this situation and make it an important issue for the election, it may help him win . . .

See you in the singularity!

Kick It on DotNetKicks.com

posted on Wednesday, August 11, 2004 6:12:37 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [1]
# Tuesday, July 27, 2004

So, I am always interested to see how people land on my blog, so I go looking at my traffic logs. There have been 3 occasions in the last week or so where people have searched for "free porn" and "free smut" and such things and landed here. First, it is sad that people go looking for such deplorable material, and secondly that my blog shows up in the results! I wonder if the people that click to come to my site think they are going to see links to such stuff, I bet they are really disappointed when they see this place for what it is . . .

Kick It on DotNetKicks.com

posted on Tuesday, July 27, 2004 5:12:19 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [3]
# Friday, July 23, 2004

This morning I played Disc Golf at the Solitude ski resort here in the lovely state of Utah. Talk about not having fun. The view, the air, and the peace and quiet were remarkable and worthwhile, but spending most of the time hiking and looking for a disc that travelled hundreds of feet and landed in a mess of bushes was not my idea of fun.

When we (myself and my friend Aaron) started hiking to the 1st tee-off point, I found a disc that someone must have lost (we were the only ones up there this morning). I used that as my first throw to test things out. Well, it's lost again. It literally travelled over 1500 feet to what I assume is its current (and probably permanent) resting place. Wow. There was a light wind and the moutain fell away faster than gravity had its way with the disc. It just kept going. It was awesome.

No markers (indicating the hole number) could be found, and the map of the course must be incorrect. We were all over the place. And let me tell you, hiking in was not fun, partly because we didn't know where in the world we were going half the time. If I ever play this course again (don't know why I would at this point), I would take the lift ($5). This was not an option for us, as the lift does not run until 1:00 on Fridays.

Can't wait to go back to our weekly game at Creekside, where no intense hiking or hunting for your disc is involved! Unless, of course, you go too far to the right on holes 5 or 6!

Kick It on DotNetKicks.com

posted on Friday, July 23, 2004 7:47:52 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
Review of Domori
Kick It on DotNetKicks.com

posted on Friday, July 23, 2004 5:48:26 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [1]
# Wednesday, June 23, 2004
How evil-minded people (via software they write) can really mess your life up
Kick It on DotNetKicks.com

posted on Wednesday, June 23, 2004 4:48:36 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [4]
# Monday, June 14, 2004
The banning of lawn darts in 1988 proves the idiocy of one of our government bureaucracies
Kick It on DotNetKicks.com

posted on Monday, June 14, 2004 5:47:30 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [2]
# Tuesday, June 01, 2004
Letters and numbers have a specific sex . . .
Kick It on DotNetKicks.com

posted on Tuesday, June 01, 2004 4:44:05 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [5]