Taste, See, Hear, Feel, and Smell - Just a Dream

I've been thinking about the history of the television lately. Way back then when, Philo Farnsworth invented the television. These early televisions and cameras were simple devices. None of them had any color and they showed us the basic things things of our world in a somewhat fuzzy view. Yes fuzzy, remember rabbit ears?

Fast forward to the 21st century and you have HDTVs which can show every freckle in a human face and computer monitors that display more colors then even nature can show us. Our visual technology has even caused the computer revolution to grow and give us all what we wanted to see.

In a similar fashion, audio technology has also grown to a sea of listening devices to satisfy our need. So, now we have two senses out of the five basic senses covered - Hearing and Seeing.

Yet, for some reason, I'm not satisfied. There's still three more that need to be worked on. One technology area I hope someone will develop is that of feeling. Every so often, you just want to touch something, to feel it's texture, to feel it's warmth, to feel it's coldness. Just to feel, what is it! Is it fuzzy? Is it slimy? Is it arid?

When will the age of touch computing come to us? No, not that iPod Touch, but touch that we can feel and respond back too! Imagine a technology that will let you feel your brand new baby while your hundreds of miles away? Imagine a technology that will let you feel what it's like to pet a tiger without actually being next to one!

Yet, as of now, touch is being ignored. Let's compare shall we? The monitors of today have billions of dollars of money poured into R&D. There is also decades of engineering and refining with millions of man hours spent into making it better, from the first TV all the way to today's Plasma TV's. Also, don't forget the hundreds of years of still photography and artistry before that. After the display technology comes the distribution technology. Billions spent on satellites, cables, fiber optics, etc. Then after that is billions spent on matrix math, 3D graphics, ratification, vector graphics, chip design, graphics cards, etc etc etc. Thousands of people employed with billions of dollars devoted just to the sense of sight. Our sense of hearing has also received a smaller, yet just as dedicated amounts of human resources and devotion.

Touch, well just read this blog: Researchers Want to Add Touch, Taste and Smell to Virtual Reality. In the end, it mentions this: "Now all they need is money." Kind of funny isn't it? Billions (I might even say trillions if you consider all the people buying) spent on visual and audio computing, yet almost nothing spent on feeling. For the resources that's being spent on it, all this is just creating equivalent of the "Black and White TV" except for touch. Come on everyone, just maybe invest just 0.01% of what we spend on visual technology, we can create an industry that's just a large as visual computing and actually have a technology that people who are blind can use! Maybe one day.....

ASP.NET & IIS7 : URL Routing + IHTTPHandler + Session State? Part 2! - runAllManagedModulesForAllRequests

In a previous post, I wrote about URL Routing and how it affects Session State. I also mentioned about removing the preCondition=”managedHandler” attribute. While upgrading some of my older website projects from 3rd Party URL Re-Writing mechanism to URL Routing, I noticed that Session State works without doing the managedHandler. I was curious why so I did some digging and noticed this in the system.webServer Modules section of my Web.config file:

<system.webserver>
<modules runallmanagedmodulesforallrequests="true">

Notice the attribute runAllManagedModulesForAllRequests="true". This is another solution to getting around the preCondition since as the attribute infers, it runs all managed modules for all requests! This was previously done with the URL-Rewriting information given in Scott Guthrie's blog.

Now does this really all requests? I wish I knew!

Beauty of Computing : Memory, Addresses, and Pointers

Computers are interesting tools which can do a lot of things. They can add, subtract, multiply, divide, and do basically any type of mathematical calculation. One of the central parts of a computer is memory. You can think of a computer's memory as a gigantic row of boxes. Let's say there are 65,000 rows. Each row contains something.

For example, let's say row 1-100 contains your program. It is etched and stored in row 1-100. Each row contains an instruction like, ADD apple AND oranges STORE in NumberOfFruits. The very first instruction of your program is in row 1. The next instruction is in row 2 and so on until you get to row 100.

Row 101 to row 200 is were you store you can store your variables. The number of apples you have is stored in row 150, the number of oranges you have is stored in row 151, and the NumberOfFruits you have is stored in row 152.

Now, let's say we run our program one step at a time starting from row 1. The program does what row 1 says and then goes to row 2. The program does what row 2 says and going to row 25. At row 25, the program says to do the "Add Apple and Fruit" parts. In order to do this, the computer goes to row 150 and get's the number of apples and row 151 and gets the number of oranges. The computer does its thing and then stores the NumberOfFruits in row 152. Lucky for us, once this is done, row 26 tells the program to start over and read row 1 again and this continues on and on. So this program doesn't do much.

However, doesn't all these numbers make you confused? Let's say we do this. We'll call the row apples are in (150) "AppleRow", the row oranges are in (151) "OrangeRow", and the row NumberOfFruits are in (152) "NumberofFruitsRows". These are just nicknames for us so instead of always typing #150 or #152, we just type the name above. When we type the name above, we have the row location. Just for fun, let's also call where our "Add Apple and Fruit" (row 25) "AddAppleAndFruitFunctionRow".

Now, we can do lots of things. Not only can we see the number of items "Apple" but we can find the exact row something is in "AppleRow". We can even know the exact row our "Add Apple and Fruit" function is!!!! Once we have this knowledge, we can now move stuff around.

So, this is all I'll talk about here, but it will give you a start on memory, address, and pointers.

Oh yes, to help you out, replace any mention of the word "ROW" with "Address". Oh, and the name's we called things (AppleRow, OrangeRow, NumberofFruitsRows) you can call those pointers. As for the pointer to the function "Add Apple and Fruit", we'll just call that a functional pointer.

So I'll leave you with that. That wasn't so hard wasn't it? So where does the hard part come in? Oh you mean the absolutely horrible syntax some languages use *coughs* C *coughs. Those '*' and '&' can really hurt you if you aren't careful. Don't forget the funny jargon like dereference, pass by reference, reference.

As for the data types....we'll save that for another time if anyone wants to know more.

(Aside: Please note this is a very very simplified view of what's happening inside a computer. If you want to know more, I recommend looking up "Von Neumann Machine")

Virtual vs Override vs Regular Methods in C#

In the world of C#, one of the biggest FAQ is what is the difference between a method marked as override and a method marked marked as virtual. The answer to this question is actually 10x easier when you think about how C# works. C# works by an automated compiler known as the CLR (in .NET implementation) where things are decided at compile time (when you build a program) or at run time (when your program is actually running).

When you mark a method as virtual, you are telling the CLR that when you use that method, whatever object you are using at run-time is the method you should use.

For example, lets say you have a ClassA with a Virtual method called VirtMethod(). ClassB inherits from ClassA and has an Override method of the VirtMethod(). Because you marked ClassA as a virtual method, whenever you call VirtMethod(), the CLR waits until the actual code is executed to see if the VirtMethod() has been overridden by ClassB's VirtMethod().

ClassA MyClassA = new MyClassA();
ClassA MyClassB = new MyClassB();

MyClassA.VirtMethod();  //CLR sees that ClassA 
virtual method is the only one there and thus 
uses it.
MyClassB.VirtMethod();  //CLR notices that ClassB 
has an override for ClassA.  So it uses that.

For a regular method without anything behind it, the method you have at compile time is used. It doesn't matter what happens at run time. In fact, if you try an override a normal non-virtual method, a compile error will occur.

This is seen in 10.6.4 of the C# v 3.0 Specifications: "A compile-time error occurs unless all of the following are true for an override declaration:........The overridden base method is a virtual, abstract, or override method. In other words, the overridden base method cannot be static or non-virtual."

More information about the differences of the Virtual Method and the Override Method and a Plain Method can be found in section 10.6.3 - 10.6.4 of the C# v3.0 specifications. I highly recommend you all read that guide since it's very useful in telling you how things are suppose to work.

The Simple Block Bracket { } : How Scope Can Be Created

Local variables is one of the most powerful things in programming today. Although the concept is old, it is still one thing all programmers must keep in mind on how to use. Today, I'll talk about the stuff between the bracket ({}) called a block (also commonly called curly braces) and how it can allow you access to local variables. In C# you normally would write a function like this:

public void MyFunction()
{
    Int64 MyVariable1 = 0;
    Int64 MyVariable2 = 1;
}

As most of us knows, everything inside that function is locally scoped. That means only things inside MyFunction can access MyVariable1 & MyVariable2. Let's expand this.

public void MyFunction()
{
    Int64 MyVariable1 = 0;
    Int64 MyVariable2 = 1;
    Int64 MyVariableChoice = 2;

    if(MyVariableChoice)
    {
       Int64 MyVariable3 = 0;
    }
    else if(MyVariableChoice)
    {
       Int64 MyVariable3 = 1;
    }
}

As most of us knows, MyVariable3 can only be accessed by statements inside the if(MyVariableChoice)block. Each instance of MyVariable3 is a local variable and memory is allocated for it's creation when the code reaches that block.


For most of us, all this is common sense. Let me rattle that common sense for a few programmers out there. Look at this switch statement:

public void MyFunction()
{

    Int64 MyVariable1 = 1;
    switch(MyVariable1)
    {
        case 1:
           Int64 MyVariableCase = 1;
           PrivateFunction(MyVariableCase);
           break;
        case 2:
           Int64 MyVariableCase = 2;
           PrivateFunction(MyVariableCase);
           break;
        default:
           break;
    }
}

If you try and compile this, you'll get an error. This is because a switch-case by itself doesn't allow for local variables. To make MyVariableCase a local variable, you need to surround it with a { } block so it looks like this.

Now let's change it a bit. Look at this switch statement:

public void MyFunction()
{

    Int64 MyVariable1 = 1;
    switch(MyVariable1)
    {
        case 1:
           {
               Int64 MyVariableCase = 1;
               PrivateFunction(MyVariableCase);
           }
           break;
        case 2:
           {
               Int64 MyVariableCase = 2;
               PrivateFunction(MyVariableCase);
           }
           break;
        default:
           break;
    }
}

This will compile and MyVariableCase will be defined as local variable. Noticed when I turned the free statements and put them inside a { } block, all the variables are now local. This is allowed by 5.1.7 of the C# Language Specifications v 3.0.

"A local variable is declared by a local-variable-declaration, which may occur in a block, a for-statement, a switch-statement or a using-statement; or by a foreach-statement or a specific-catch-clause for a try-statement." -5.1.7 Introduction

Now, before you go crazy with limiting local scope with blocks, remember, I only demonstrated this with C#. PLEASE read your language specification manual to make sure that your language supports scope by blocks. Highly popular languages such as Javascript DO NOT ALLOW LOCAL VARIABLES BY BLOCKS. Local variables in Javascript is allowed by functions but not blocks. Please don't try the case example above for Javascript. See Douglas Crockford's video on "The Javascript Programming Language" for more details.

ASP.NET & IIS7 : URL Routing + IHTTPHandler + Session State?

URL Routing is one of the newest addition Microsoft has added to ASP.NET. There’s quite a lot of information on the web that talks and explains it. Today though, I found a problem with it that I’ve been trying to figure out, but so far I only came up with a solution that doesn’t make any sense.

Let’s first talk about URL Routing & IIS7. To start a URL Route, we must first fill a RouteTable with Routes so that the URLRoutingModule can later use it. In my case, I usually do this in the Application_Start of the global.asax file. In the ASP.NET pipeline, a bit later, the URLRoutingModule is then called between the application.PostResolveRequestCache and the application.PostMapRequestHandler events. The URLRoutingModule then takes the routing table defined earlier in the Application_Start and searches to see if a route is found. If a route is found, the module then takes the IHTTPHandler associated with that route and add’s it to the MapRequestHandler. Later on in the pipeline, the Managed IHTTPHandler should fire when an event is called for them. You can find more information about the details here URL Routing, a good article written by Ruslan Yakushev with a good picture on this architecture (pipeline).

During this time, I was writing a JSON IHTTPHandler to send out information to the browser. As most of us knows, in order to use Session State with our IHTTPHandler (prefix = *.mini), we need to add either the IRequriesSessionState or IReadOnlySessionState marker interfaces to our handler class it. I then added the routes to my routing table. So I then tested it with Visual Studio’s 2008 debugger.

Results?

• localhost/site/junk.mini = Worked Perfectly as Expected!


• localhost/site/testroute = Worked Perfectly as Expected!

I felt really good about this so I then loaded up IIS7 and tried it there. Results?

• localhost/site/junk.mini = Worked Perfectly as Expected!


• localhost/site/testroute = SessionState Information Not Found???

So I did that and I got a error telling me that the Session doesn’t exist. After looking further, Odd, I say, because from the guide above, this handler should go through the System.Web.SessionState.SessionStateModule. Basically, what ends up happening next is searching the Internet until I found a partial solution. Loki in StackOverflow discovered that the AcquireRequestState wasn’t firing for some odd reason. The fix for this? Just re-add the System.Web.SessionState.SessionStateModule like this to the system.webServer section of your web.config:

<system.webServer>
<modules>
<remove name=”Session” />
<add name=”Session” type=”System.Web.SessionState.SessionStateModule” />
</modules>
</system.webServer>

I did the test again and it worked! So that fixed it, but why did it fix it? To find out that answer requires a little more digging. Since the .config files are inherited from the lower ones, there must be something that the lower ones are doing that the upper ones aren’t. A little searching and then you find Bilal Haidar’s blog on Session State and Native HTTP Requests in IIS7. This blog explains that the original SessionState is done via the applicationHost.config file. That session is defined as:

<add name=”Session” type=”System.Web.SessionState.SessionStateModule” preCondition=”managedHandler” />

So it added the preCondition=”managedHandler” so that the SessionStateModule would only work when it is a managed handler. Bilal then goes on talking about handling native events in managed mode. However, in my case, everything is managed. So what’s happening?

To test out this theory, I added the preCondition=”managedHandler” to my website’s web.config file, and guess what! Session State returned a null again!

So why in the world does this go through the URLRoutingModule get’s calculated and considered a “native” IHTTPHandler even though it is managed! I wish I knew why.

Update:
Part 2 Here