1) The entropy of a function is determined by how predictable the output of the function is, based on its inputs.  In other words, I think we can we can take the basic concepts of statistical thermodynamics and apply it to software.

 

2) Every function can be assigned an entropy value between zero and one.  The following is a zero-entropy function (as it doesn't change the input parameters at all):

int func0(int x)
{
     return x;
}

Conversely, the following function has an entropy of one (output is completely independent of the input):

int func1(int x)
{
     return rand();
}

(Actually, this function would have an entropy slightly less than 1.0, since any software random number generator isn't completely random, but... you get the basic gist.  In any case, the point is I'm assigning arbitrary values to define a range of possible entropy values)

3) Any two functions which have identical return values for identical inputs, have the same entropy.

4) The entropy of a function is not equal to the sum of the entropy of each line that comprises the function.

 

Proof:

 

By #2, the following function has zero entropy:

int func0(int x)
{
     return x;
}

Conversely, these functions have positive, non-zero (albeit small), entropy:

int func1(int x)
{
    return x + 1;
}

int func2(int x)
{
     return x - 1;
}

Now, consider the following function:

int func3(int x)
{
     int y = func1(x);
     return func2(y);
}

By #3 the func3() has the same entropy as func0(), since the output of both functions is identical (they both return the original value passed to the function).  Thus the entropy of func3() is zero, even though the lines the comprise the function have positive entropy.

Given all of these, I propose the following statement:

5) The efficiency of a function is the entropy of the function, divided by the sum of entropy of each statement that make up the function.

1. The Jetta made it a year without a check engine light.  I'm stunned.
2. Champ Car observation #1:  Saying there was a merger with the IRL is ridiculous.  Champ Car was killed and Tony George plucked a few items off the course.
3. Champ Car observation #2:  If you're a Champ Car fan who wasn't interested in the IRL, what are you to do?  Watch a series you never liked in the first place?
4. Champ Car observation #3:  Last year we went to three open-wheel events in the US:  Champ Car at Road America and Cleveland, and the F1 race at Indy.  This year, none of those events even exist.  If that doesn't show the state of open wheel in the US, what else can I say?
5. I have a box running Windows Server 2008, and I have to say my first impressions have been very good.  It's definitely taking a bit for me to warm up to IIS7, mainly because the interface to it has changed dramatically, but I think it will prove to be a excellent upgrade from IIS6--I just need to get used to it.

Ok, gotta run.  Toodles!

Ben

• the driver-side door lock module broke
• the front swaybar had to be disassembled and lubricated
• the passenger seat heater broke (which is one of the reasons I bought the Jetta in the first place, my wife likes seat heaters!!!)

But considering the car has never gone more than 5-6 months before that stupid light came on in the last 5 years, I think I have officially made a breakthrough!!!

Of course, it still has to go another month ;-)

Ben

• Kimi continues his momentum from last year, builds a comfortable lead in the Championship and maintains it through the year, never really being challenged.
• Massa gets a couple wins but as the season progresses, he starts falling further and further back as he comes to the realization that Kimi's faster than he is, and his chances for a World Championship are only a dream
• Hamilton has a bit of a "sophmore slump" and only gets 2-3 wins and scores less podiums than his frankly incredible 2007 season.  Nonetheless in the grand scheme of things, it's still a unbelieveable result for a driver in his 2nd year, and he continues to have as much desire as ever.
• Heikki scores no wins, but has several solid podium performances, with at least one 2nd place.  Even though he doesn't do fare as well as Hamilton, the dream of a World Championship is untarnished.
• Renault struggles a bit early in the season, but makes steady progress throughout the year to the point that Alonso is regularly on the podium in the 2nd half of the season, and he wins 2 of the last 3 races.
• Piquet... no clue, but I liked his dad!
• With Hamilton and Alonso not scoring quite as many wins and podiums as last year, BMW steps up and scores several podiums through the year, including a somewhat unlikely win in a race with some unusual twists.
• Williams does better than last year, with Rosberg scoring a couple of podiums.  But he starts getting restless watching his contemporaries (Hamlilton, Heikki) pulling away from him.
• Honda improves a fair amount, but remains far behind BMW and Renault.  Barrichello becomes even more Zen-like,  uttering phrases like, "the race, it was."  Button soldiers on but begins to realize that he will inevitably end up with Panis and Alesi--outstanding drivers with, sadly, only one win to their credit.
• Toyota holds station, but Glock is a bit of a relevation in that he consistently beats Trulli.
• Red Bull also holds station, with a season earily simiar to 2007--surprising speed with bad reliability.  Webber starts getting flaky at the end of the season, as he comes to the realization that bad luck and bad timing is going to trump his talent, and prevent him from ever seeing a win.
• Torro Roso:  Oh boy...  I think Bourdais is a remarkable talent, but the car holds him back.  But Vettal's excellent, too.  One of them gets a surprise podium during the year.
• Force India:  I'll be honest, I *love* teams with national pride, like Ligier and Prost.  But Mallya's no dummy, and by mid-season he'll realize that he's dumping tens of millions of dollars into a project with no chance of being anything but a backmarker.  By the time the season is 3/4 complete, rumors will run rampant that he's trying to sell the team, and at the end of the season they will announce the team will be sold...  back to Eddie Jordan!!!

Seriously, though, I think this will be the best season since the early 90's, and I chalk it all up to Michael Schumacher:  I think we're currently seeing the strength of the drivers who grew up during his dominence:  Hamilton, Kovalainen, Rosberg and most of all Alonso, who went head to head with Michael--and beat him.  They saw his speed, his commitment to win--always.  And it raised their game far beyond where they would be, had he not been on the scene.

Cheers!

Ben

This is accomplished by letting an application on the internal network send requests to any machine on the outside network either via UDP or TCP and any replies from that specific IP/Port will be allowed to come back into the local network and routed to specific machine that sent the initial request.

If you are using an SPI based router then you should not be having any problems what so ever unless you have turned on some kind of option that tells your router to block all inbound traffic except for certain ports like HTTP, POP3, SMTP, FTP, etc.

The Ventrilo software was developed behind an SPI router and tested by many people using different types of SPI based routers.

QA: Hey...
Developer:  What's up?
QA: That new feature you built is crashing the program.
Developer:  Hmm.  It works fine on my machine.

I can't count the number of times I've seen developers dismiss bugs and errors as some bizarre, "one-in-a-million" aberration that in an miraculous Act of God, somehow occurred on the computer down the hall.  The truth is that if you're seeing a problem on one or two QA boxes, you're going to see it on many more machines once the code goes into production.

What the developer should do is beef up the error handling code in order to pinpoint what's occuring, and then fix the code.  For what it's worth, typically when I see this interaction between development and QA, it's a sign of non-robust code.

Since I'm a believer in not bringing up a problem unless you have a potential solution, here's what I'd suggest to the Ventrilo development crew:

1. Establish the initial connection to the server via TCP, not UDP.  Since TCP is so well defined, you're much more likely to be able to establish a TCP connection than getting two-way UDP to work.  Also, since the Ventrilo devs seem a bit paranoid about network admins blocking ports, establish the first connection on port 80.
2. Once that connection is established, send a UDP packet to the server and see if you can get a reply.
3. If you receive a UDP packet, start using UDP communications and all the features/advantages that come with it
4. Conversely, if you didn't receive a UDP response after sending out the UDP packet, stick with the TCP connection like the v2.3 client did

Looks like a win-win to me, people who can support UDP communications get the advantages that UDP can bring, but if someone's network doesn't support UDP as Ventrilo needs it to, they still get the functionality of the old Ventrilo client.

Ben

1. First off, the client sends a UDP packet from an ephemeral port to the address and port specified in the Ventrilo server configuration.  The Ventrilo server then sends a UDP packet back to the client, with the source port being the specified server port, and the destination port being the ephemeral port.  If the Ventrilo client is stuck at a "connecting to server" message, then you have a problem with these UDP packets either not making it out of the network, or the return packet being thrown out.
2. Next, the client sends a UDP packet from an ephemeral port to port 5000 on a server in the ventrilo.com domain.  The ventrilo.com server will then send a UDP packet back to the client similar to step #1, but originating from port 5000.  I'm not positive why this exchange occurs, possibly client tracking or statistics?  In any case, it seems no harm comes if the firewall blocks the packet coming back from the server--even when I have ISA 2006 blocking the return packet, the Ventrilo client seems to work fine.
3. When you click the "Connect" button, a TCP connection is established using the same address and port as in step #1,  the client sends credentials (server password and user name at a minimum, I'm guessing).  For what it's worth, all non-public data appears to be encrypted--the only plaintext I saw was when the server returned it's version number and name.
4. Finally, the client sends out several UDP packets from ephemeral ports to port 6100 on several different servers, and these servers respond with UDP packets similar to steps #1 and #2, but originating from port 6100.  I'm not sure where the client is getting the addresses to send these packets to; probably step #1 or step #3, but it really doesn't matter.  If these outbound or incoming packets are blocked, the Ventrilo client will get stuck at a "syncronizing" prompt.

Armed with this data, you'll need to create a new protocol in ISA 2006 with the following settings:

Obviously, if you're connecting to a Ventrilo server on a port other than 4000, you'll have to use the port you're using instead of 4000.  The UDP connection on port 5000 and 6100, though, won't change regardless what server port you're connecting to.  Also, the UDP connection must be specified as "Send Receive", otherwise ISA 2006 will just discard the UDP packets inbound from the server.  Port 5000 could feasibly left as just "Send" since the return packet doesn't appear crucial to the client, but I don't really see the advantage of that.

However, you might not be out of the woods quite yet:  if ISA 2006 already has a protocol set up for UDP packets going to the port you're connecting to on the server, then ISA will use that protocol instead of the one you've just defined.  In my case, a legacy ICQ protocol is already defined in ISA 2006 for UDP packets going to port 4000.  And, since this protocol defined the port 4000 UDP connection as "Send" and not "Send Recieve", returning UDP packets were being tossed out.

The solution for this is to either create a deny rule for the offending protocol, or un-include the protocol from a blanket rule that would normally allow any traffic originating from the Internal network going to the External network.  I used the latter.

I'm not sure how many folks are using Vent on a network with ISA 2006, but I hope this helps someone!  ;)

Ben

SELECT OrderNumber FROM Order WHERE blah = blah AND ...

int orderNumOrdinal = reader.GetOrdinal("OrderNumber");
int orderNumber = reader.GetInt32(orderNumbOrdinal);

• You need to make a change to a database schema, but you can't because you'd have to change a bunch of other applications to work with the new schema
• You're afraid to make a code change because you're not sure how it will affect other applications in the system

And that's where the "evil" part comes in--because monolihic systems are overly coupled, you can't efficiently change them to deal with changing requirements.  Not only that, they tend to be fragile because it's easy for a legit bug fix in one applications to create a subtle, hard-to-find bug in another application within the system.

The bottom line is that monolithic systems are bad, and something you want to avoid.

Next up:  the main causes of monolithic systems.

Ben

• 6-speed manual transmission
• engine with variable valve timing (later ammended to "interesting technology")
• seat heaters (for the wife!)
• 4-wheel disc brakes
• under $20k
• 4-wheel independent suspension

When I was buying my last car in 2003, the car that came closest to my list was probably the Nissan SE-R Spec V, which missed out on the independent suspension and seat heaters.  The other two cars I seriously considered were the Jetta (missing out on the 6-speed and independent suspension, but pretty close to the $20k price limit) and the Subaru WRX (missing the 6-speed and seat heaters, and really too far from $20k for serious consideration).

In the end I picked the Jetta over the Nissan because the Jetta came across more as "premium" small car while the Nissan seemed more like a cheap car with an uprated suspension and engine.  Four and a half years later, I still feel the same--I think I would have been disappointed with the low-cost feel of the Nissan, although I'm certain it would have been much more reliable with the Jetta.

These days, I think the car that most closely matches my criteria is the Mazdaspeed 3.  It's not under $20k, but it's reasonable close (and I realize that $20k is pretty unrealistic for a car these days) and it's as quick as our Corvette.

So how does this all relate to American car companies?  Simple:  As you've probably noticed, I haven't mentioned a single American car that's come close to my new car criteria. 

And that bugs me, because I really want to buy an American car.  I'd much rather buy an American car than a foreign one, but nothing they offer was close enough to my requirements to merit consideration.  The biggest problem for me is that the American car companies offer very few cars with manual transmissions.  I'd often say, "Cavaliers and Corvettes"--those were the only two Chevrolet cars offered with manual transmissions; everything else was strictly automatic.

In 2003, probably the closest American car to my criteria was the Dodge Stratus R/T, but the MSRP on that was like $27k.  I think the final price on that Stratus would have been close to the $21.5k I spent on the Jetta, but even thinking about trying to get a car salesman down from $27k makes me feel ill--the endless "let me run this past my manager" smoke breaks, the "I'm losing money on this deal" BS, the constant pushing of unwanted paint treatments.

I think that at the time, American car companies were trying to make customers feel like they got an expensive car for an incredible discount.  But it backfired for customers like me, because I never stepped into a Dodge dealership since I didn't want to deal with hours of salesman BS while they whittled down the price $200 at a time.

Dodge, are you listening?  Do you care?

I'm not sure why the American car companies don't want to build a car that I'd consider buying.  Certainly I'm in a vast minority since I prefer a manual transmission.  But the German and Japanese manufacturers have no problems offering a variety of cars to me with manual transmissions.  Why don't the American manufacturers?  I guess it's because the sales volume of manual tranmission cars would be low enough that they can justify losing that business.

Oh, well.  Perhaps someday they'll building something that comes close enough to my list that I'd consider buying. 

I'm not holding my breath, though.

Ben

    class OrderAttribute
    {
        public int OrderID;
        public int AttributeID;
    }

    class OrderAttributeDataLayer
    {
        public static OrderAttribute[] GetOrderAttributesForOrderID(int orderID)
        {
            SqlConnection connection = new SqlConnection();
            connection.Open();

            string sql = "SELECT OrderID, AttributeID FROM OrderAttribute WHERE OrderID = " + orderID.ToString();

            SqlCommand cmd = new SqlCommand(sql, connection);
            SqlDataReader reader = cmd.ExecuteReader();

            List<OrderAttribute> tempList = new List<OrderAttribute>();

            while (reader.Read())
            {
                OrderAttribute orderAttribute = new OrderAttribute();

                orderAttribute.OrderID = Convert.ToInt32(reader["OrderID"]);
                orderAttribute.AttributeID = Convert.ToInt32(reader["AttributeID"]);

                tempList.Add(orderAttribute);
            }

            reader.Close();
            connection.Close();

            return tempList.ToArray();
        }
    }

And finally, the code to display the total of all rush orders:

public static void DisplayRushOrderTotal()
{
     Order[] rushOrders = OrderDataLayer.GetRushOrders();

     double totalValue = 0.0;

     foreach (Order order in rushOrders)
          foreach (OrderLine orderLine in order.OrderLines)
               totalValue += orderLine.Quantity * orderLine.UnitPrice;

     Console.WriteLine("Total rush order value = $" + totalValue.ToString());
}

public static void DisplayRushOrderTotal()
{
     SqlConnection connection = new SqlConnection();
     connection.Open();

     string sql = "SELECT SUM(ol.Quantity * ol.UnitValue) FROM OrderLine ol JOIN OrderAttribute oa ON ol.OrderID = oa.OrderID JOIN Attribute a ON a.AttributeID = oa.AttributeID WHERE a.AttributeName = 'rush'";

     SqlCommand cmd = new SqlCommand(sql, connection);
     double totalValue = Convert.ToDouble(cmd.ExecuteScaler());

     connection.Close();

     Console.WriteLine("Total rush order value = $" + totalValue.ToString());
}

• Which do approach is more clear and concise?
• Which could be developed faster?
• Which would perform better?
• Which would be easier to debug and fix?

Finally, ask yourself this:  Which is the better approach?

Ben

public class Attribute
{
     public int ID;  
     public string Name;
}

public class Order
{
     public int ID;
     public Attribute[] Attributes;
}

CREATE TABLE Order
(
OrderID INT
)

CREATE TABLE Attribute
(
AttributeID INT,
AttributeName VARCHAR(30)

)

CREATE TABLE OrderAttribute
(
OrderID INT,
AttributeID INT

)

public class ObjectAttribute
{
public int OrderID;
public int AttributeID;
}

public class Order
{
     public int ID;
     public OrderAttribute[] OrderAttributes;
}

foreach (OrderAttribute oa in order.OrderAttributes)
{
     Attribute = OrderAttributes.GetAttributeByID(oa.AttributeID);
     // do something with the attribute here
}

foreach (Attribute attribute in order.Attributes)
{
     // do something witht he attribute here
}