This changes everything!
Thursday, December 10, 2009
Thursday, November 12, 2009
A Trillion Is A LOT!
Maya, a design consultancy company, has created a short film called Trillions which puts some perspective on the invisible but fast approaching challenges and opportunities in the pervasive computing age. As a software engineer, this affects me directly. I think it's good to start thinking about these issues today, before we are forced to think about it in the future. enjoy!
Tuesday, October 20, 2009
Take Control of Your Soundscape
This is a quick, informative talk on the influence the sounds around us have on our feelings and behaviors; check it out. It's a good thing I work in a "Library" like atmosphere...
Thursday, September 10, 2009
Web Service Not Reading the Lmhost File?
I recently spent 1/2 of my work days trying to figure out a problem reported to me by a client. I am working on a three tiered application that has a windows forms application that communicates to a web service. The web service performs all the communication with the database which is located on a different server from the web service.
I was told that they could not longer upload or download data to or from the windows forms application. They also mentioned that they installed a firewall. .Net remoting can use tcp or http as the protocol and either of those can use soap and/or binary encoding. I read that firewalls block binary transfers of data... uh... not really. So with a grain of salt I began going down that path. I determined that the web.config file for the web service is where the encoding type is set (in the remoting section). I happened to have http with soap and binary. I commented out the binary line, and ran the program. BOOM! I got an error regarding incorrect binary string. So without changing the program quite a bit I cannot have the soap protocol only.
Well, it turns out that it had nothing to do with the binary format of the stream. The client's web server was not translating the server name they entered to the correct IP address of the database... So they entered the IP address of the database server. fixed. firewall still enabled.
What did I learn? There's a lot of garbage assumptions out there in Google space... So apparently in their setup, the web server was not reading and translating the server name from the lmhosts file. I wonder if Microsoft has any detail on that?
Wednesday, April 22, 2009
Internet Explorer 7, Print Preview Page Generator
I found a bug (or at least what I think is a bug in Internet Explorer 7. Here’s the scoop: when you print preview a page in IE7, you get a nice little popup of the page(s) and how it will print. Great. Well depending on how the page is created, it might not work. Down at the bottom of the preview it gives you a “Page 1 of X” (where X is the total number of pages). As you can see from the image, the number of pages is 2076, but what you cannot see is that it is still increasing… doh!
Under certain circumstances you can make the function that calculates the total number of pages to print to “freak out” or rather infinitely loop, thus never displaying the actual preview of the page. This is only an issue in IE7. The same test works fine in Firefox 2.0.0.6. I have not yet tested it in any other browser or version of a browser.
I have not completely narrowed down the issue yet either. But I have found that if you use DIV tags and a CSS style sheets to layout your pages, you may come across this issue. Some facts: this page is built dynamically. My div tags are all fixed width. There are nested div elements up to 3 or 4 levels, and there are label elements with empty “for” attributes. All the layout is done using the style sheet and div attributes. The interesting thing is that this issue only happens on pages that are longer than about 2 print preview pages; which means that it seems to either be the data in the elements, or the number of elements on the page.
First, I made sure that all my tags had appropriate closing tags and formatting (text case and all that). I threw it into Visual Studio 8 and formatted and validated the text. Same issue. Next, I started from the bottom of the page and started commenting out the div blocks one by one and testing the print preview after each. After commenting out two of them, the issue went away and the print preview displayed fine. So I thought there must be something wrong with one of these divs. Turns out that there is nothing wrong with them. I found that I could uncomment those divs and comment out the first few divs and the problem would also be resolved. So then I uncommented all the divs again (essentially restoring the problem), and removed the CSS stylesheet reference. Again the problem went away.
Okay, now this is messin’ with my brain….
So ultimately, I submitted the issue to Microsoft. Right now, this currently looks like a bug. I found the following article on MSDN: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/5defae18-1e29-4f75-a47c-670c82ab15de and submitted my issue there. The original issue was reported in 2008, so I’m not sure if anyone is still tracking the problems. If you have any solutions to this issue please post your comments here. I still need to resolve this issue. Thanks!
The problem is resolved in the latest version of Internet Explorer 8.
Wednesday, April 1, 2009
How to Speed Up Finding an Element in a System.Collection.IList
I've been working on a program for some time now that I inherited. It's a great program, most of the code is designed well, but some of the implementations of the design have been less than desirable, especially when you are talking about speed. Let me explain:
I've recently found a bottleneck in some of the code I've been optimizing. For instance, I have a System.Collection.IList that is basically given to me to use (since it has been implemented using a third party tool, the trade-off for removing it was not an option). I don't recall what the IList was implemented as, but the IList does not allow me to call a List.Contains(object value), or List.IndexOf(object value). If it did, I would not be in the situation I am. The bottom line is that I needed to have an implementation of the .Contains() and .IndexOf() methods. So here's how it was implemented:
As you can see from the code above, the way you find a match is to loop through each object (I could have used a foreach statement, but I was trying to optimize and a for loop helped slightly) and match the value. If a match is found then "true" is returned and if not then "false" is returned for the Contains() method. For the IndexOf() method, you are looking for the index where the object resides in the IList, so you can reference it in some other place of the code.
So this is all fine and dandy if your collection is garanteed to stay small (which was the intention of the collection at design time). This method of search is a linear search, O(n). But you'll see that its actually O(n^3). Since then, the design has been extended to allow the collection to contain upwards of 5000 objects (which really is not that many, so I thought). It turns out, that these objects have multiple data elements, and everytime the object was referenced it would take a very long time to check (I found it by pausing the debugger when the program was halted for the time it was performing this routine). This looping and checking would not be performed once, but between 2000 to 4000 times, and that would be performed 400 to 800 times, so the number of times the list is accessed would be more like 800 * 4000 * 5000 = 16,000,000,000 billion times. OUCH!
So there are a few things that I did to fix the search time. First of all, where I could, I pulled all the direct calls to the object ("List[i]") into a local variable to reduce the overhead of those calls (though this did not do much). Second, I implemented a System.Collections.Hashtable that was pretty much a clone of the IList (a clone of the objects and the number of objects, not the order they are stored). Hashtables are typically O(1). Which means that you'll find you value a heck of a lot faster than a linear search. So each time I add an object to the IList, I add the same object to the Hashtable, and the same goes for removing objects. I then changed the Contains() method to the following:
The IndexOf() method then goes away, since you can then reference the object in the following manner:
BINGO! Problem solved.
I've recently found a bottleneck in some of the code I've been optimizing. For instance, I have a System.Collection.IList that is basically given to me to use (since it has been implemented using a third party tool, the trade-off for removing it was not an option). I don't recall what the IList was implemented as, but the IList does not allow me to call a List.Contains(object value), or List.IndexOf(object value). If it did, I would not be in the situation I am. The bottom line is that I needed to have an implementation of the .Contains() and .IndexOf() methods. So here's how it was implemented:
public bool Contains(Guid _reviewAnswerId)
{
int listCount = myList.Count;
for (int i = 0; i < listCount; i++)
{
if (myList[i].ReviewAnswerId.Equals(_reviewAnswerId))
return true
}
return false;
}public int IndexOf(Guid _reviewAnswerId)
{
int listCount = myList.Count;
for (int i = 0; i < listCount; i++)
{
if (myList[i].ReviewAnswerId.Equals(_reviewAnswerId))
return i;
}
return -1;
}As you can see from the code above, the way you find a match is to loop through each object (I could have used a foreach statement, but I was trying to optimize and a for loop helped slightly) and match the value. If a match is found then "true" is returned and if not then "false" is returned for the Contains() method. For the IndexOf() method, you are looking for the index where the object resides in the IList, so you can reference it in some other place of the code.
So this is all fine and dandy if your collection is garanteed to stay small (which was the intention of the collection at design time). This method of search is a linear search, O(n). But you'll see that its actually O(n^3). Since then, the design has been extended to allow the collection to contain upwards of 5000 objects (which really is not that many, so I thought). It turns out, that these objects have multiple data elements, and everytime the object was referenced it would take a very long time to check (I found it by pausing the debugger when the program was halted for the time it was performing this routine). This looping and checking would not be performed once, but between 2000 to 4000 times, and that would be performed 400 to 800 times, so the number of times the list is accessed would be more like 800 * 4000 * 5000 = 16,000,000,000 billion times. OUCH!
So there are a few things that I did to fix the search time. First of all, where I could, I pulled all the direct calls to the object ("List[i]") into a local variable to reduce the overhead of those calls (though this did not do much). Second, I implemented a System.Collections.Hashtable that was pretty much a clone of the IList (a clone of the objects and the number of objects, not the order they are stored). Hashtables are typically O(1). Which means that you'll find you value a heck of a lot faster than a linear search. So each time I add an object to the IList, I add the same object to the Hashtable, and the same goes for removing objects. I then changed the Contains() method to the following:
public bool Contains(Guid _reviewAnswerId)
{
return _hashTable.ContainsKey(_reviewAnswerId);
}The IndexOf() method then goes away, since you can then reference the object in the following manner:
return (CastToMyObject)(_hashTable[_reviewAnswerId]);BINGO! Problem solved.
Saturday, March 21, 2009
Don't DIY Starter Removal Instructions 97 MAZDA MPV 4WD
I'll make this short and sweet. Last Sunday, my wife got in our 1997 Mazda MPV after church and tried to start it. Nothing. Turns out that the starter was on a bad spot and would not crank. Ratz! Since I could not find out where the starter was at the time, I had it towed to my house. I validated that it was indeed the starter. I remove the front plastic dirt guard and found the starter. It's not in a very nice place. I took my long mag light and banged on it a few times, then it cranked over. Yep it was the starter.
Yesterday, I finally purchased a new starter (first mistake). I then went out to pull out the old starter. After removing the metal plate that protects the front differential, I could see the starter bolts. It looked a little tight.
After taking off the front differntial drive shaft, I attempted to remove the 3 bolts that hold the starter on. After some strenuous efort I got the lower bolt off.
However, the scond bolt proved to be so stubborn I decided to take another approach. There is a large cable assembly the runs right in front of the second bolt and so I used a angle bracket on my wratchet to get at it better (second mistake). Well, I did not have enough pressure on the wrench and so I stripped the bolt (slightly).
After fretting a bit and looking at it for a while, I realized that even if I got the bolts off, there was no way I could pull out the starter. There are two obstacles, the front differential and the engine heat shield that covers the starter. I have no way of removing the front differential (3 strikes and I'm out). So, I'll be taking it to a pro. This is the first time I've been beaten. Yes I'm very depressed. I wish I had a car lift... I could do it all then.
Lessons learned:
1) Buy a manual first. You'll learn what the real dissassembly instructions are and there by know what you'll get into before you actually get into it.
2) Don't buy the new starter, until you get the old one out. Now I have to take the new starter to the mechanic and then get the core from them to get my core rebate... more work.
Yesterday, I finally purchased a new starter (first mistake). I then went out to pull out the old starter. After removing the metal plate that protects the front differential, I could see the starter bolts. It looked a little tight.
After taking off the front differntial drive shaft, I attempted to remove the 3 bolts that hold the starter on. After some strenuous efort I got the lower bolt off.
However, the scond bolt proved to be so stubborn I decided to take another approach. There is a large cable assembly the runs right in front of the second bolt and so I used a angle bracket on my wratchet to get at it better (second mistake). Well, I did not have enough pressure on the wrench and so I stripped the bolt (slightly).
After fretting a bit and looking at it for a while, I realized that even if I got the bolts off, there was no way I could pull out the starter. There are two obstacles, the front differential and the engine heat shield that covers the starter. I have no way of removing the front differential (3 strikes and I'm out). So, I'll be taking it to a pro. This is the first time I've been beaten. Yes I'm very depressed. I wish I had a car lift... I could do it all then.
Lessons learned:
1) Buy a manual first. You'll learn what the real dissassembly instructions are and there by know what you'll get into before you actually get into it.
2) Don't buy the new starter, until you get the old one out. Now I have to take the new starter to the mechanic and then get the core from them to get my core rebate... more work.
Subscribe to:
Posts (Atom)