Posted on February 12th, 2007%
Microsoft, the company who provided the products and tools for millions of people to build careers off (myself included), has often forgotten that the simple solutions are often the best. In a recent blog post, hammett wrote about Microsoft’s missteps in this area and their focus on YAGNI (You Ain’t Gonna Need It) — at least, where “You” refers to most people.
[Digression: Someone at some point commented on Microsoft Word that "90% of the features are used by 10% of the people". If I was designing a product and 10% of my features were used by 90% of the people, and the other 90% of the features were used by 10%, I'd either write two products, or I'd write one product that was incredibly extensible using a plug-in architecture.]
This feature-bloat approach to technology reminds me of Microsoft’s Enterprise Library and the Data Access Application Block (DAAB). In the first release of the DAAB, you can . . .
→ Read More: KISM: Keep it simple, Microsoft
Posted on July 5th, 2005%
The ADO RecordSet object’s Clone method does a great job of making a duplicate copy of the RecordSet, with one major caveat: any changes to the clone are duplicated on the original. It’s more like a shallow copy than a deep copy.
To make an actual copy of a disconnected ADO RecordSet in Visual Basic, use a method like the one shown below, which was largely taken from Francesco Balena’s article on devx.com:
Private Function CopyRecordset(rsSource As ADODB.Recordset) As ADODB.Recordset
Dim rs As ADODB.Recordset
Dim pb As New PropertyBag
‘ create a copy of the recordset
pb.WriteProperty “rs”, rsSource
Set rs = pb.ReadProperty(“rs”)
‘ release the memory
Set pb = Nothing
Set CopyRecordset = rs
End Function
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: . . .
→ Read More: Copying an ADO RecordSet in Visual Basic
Posted on March 30th, 2004%
I received an email today from Johnny B. (Good?), in which I was asked a question about a Web service I provide, ProxyBuster.net. The email was:
Hello. I had a little question and I’ll be so glad if you can answer me. I wanted to ask: What system or platform does ProxyBuster use in its process, is it CGI, PHP, ASP, JavaScript, or something else? I mean which one of these can manage to trick the firewall and access a forbidden file?
My response is: None of those, actually. The “trick” is understanding how firewalls work. Most firewalls/proxies do one of a few things:
Block by IP address.
Block by domain name.
Block by URL text.
Block by file extension.
Block by HTTP content type.
Block by actual content type.
Let’s say you want to access Google’s home page (http://www.google.com/index.html). A firewall can:
Block the IP address 216.239.39.99.
Block the domain name, www.google.com.
Block a URL that has “www.google.com” in it (as in http://www.google.com).
Block all files ending in “.html”.
Block all files that have . . .
→ Read More: How does ProxyBuster.net work?
Uncategorized 
Recent Comments