Tag: Programming

There’s no end to the number of bad programming examples we’ve seen in the past or will see in the future. Recently, I saw this one. (This was actual code seen in an actual project.)

try { createDate = Request.Params["createDate"]; }
catch (Exception) { createDate = "-1"; }

Nice and ugly. Aside from a horrible way to implement a try/catch block, it screams of performance issues and unreadable code.

A more proper alternative follows.

createDate = Request.Params["createDate"] ?? "-1";

The same project also had this use of integer parsing.

try { myInt = Int32.Parse(textBox.Text); }
catch (Exception) { myInt = -1; }

In this case, you would use the TryParse method instead:

if (Int32.TryParse(textBox.Text, out myInt))
    myInt = -1;

Exception handling is for exceptions, not for null checking or validations.

Having spent six of the past ten years as a consultant, I’m all to familiar with the practice of estimating. Every client wants an estimate, and every client wants your estimate to be accurate. Of course, clients also don’t want to give you concrete requirements that are needed to give an accurate estimate, either, which compounds the problem.

Scott Hanselman has a nice post about estimating, where he mentions two lessons I learned over the years:

• Make your estimate, then double it. I actually took this a step further. If an estimate had to be given based on very sketchy requirements, I’d double it twice (effectively quadrupling it). This practice leads to…
• Under-promise and over-perform. Always make sure your estimate gives you sufficient cushion to come in ahead.

A third lesson he doesn’t mention is to be willing to walk away from a client if your estimate is too high. If a client balks at your estimate (even if you double, or quadruple, it), you can either reduce the scope of your proposed work (and thus reduce the estimate) or walk away. I’ve taken projects that I’ve regretted taking after all was said and done, and most of them can be attributed to me skimping on my estimate because the client was scared off by my original (and, usually, more accurate) estimate.

These lessons go not just for programming projects, but for nearly everything in life. Over-estimate, under-promise, over-perform, and don’t shortchange yourself. Words to live by.

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

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 the HTTP header content-type “text/html”.
• Block all files that are actually text files.

In this case the first three bullet items are effective, but the last three would limit your ability to use the Internet as a whole. Usually binary files (ZIP files, EXE files, etc) are restricted by the latter three types of blocks, and entire sites by the first three types of blocks.

So how does ProxyBuster do its magic?

First, if your firewall/proxy blocks the IP address, that’s not a problem to ProxyBuster, because you do not connect to the site directly. ProxyBuster connects to the site and reads your data, then provides it to you. Of course, if your firewall/proxy blocked www.proxybuster.net or our IP address, you’d be out of luck using our service because you wouldn’t be able to connect to it!

Next, ProxyBuster returns the file to you in one of a few formats. First, the file is sent to you as “download.aspx” — which is a very generic file name and file extension that would be too restrictive to block. (For example, blocking “.aspx” files would make it impossible to browse Microsoft’s Web site.) Next, we give you the option to receive the file with an HTTP content-Type header “text/plain” even if the file is not a plain text file. Last, if your firewall/proxy blocks binary files, we can send you the file in a text-encoded format (so it’s transmitted as a text file); all you need to do is decode it after you receive it (which does require a separate utility).

I hope this sheds some light to the inner workings of ProxyBuster!