Revive an Old Turbo Flame?

Just found this referenced on an FTPOnline story: http://www.turboexplorer.com/

For an old Delphi aficionado (version 5 was my last), I can't wait to download the Explorer versions to see what they've done with the place.

I've always felt that starting with a Borland tool was a better place for a beginner to start. And then you take a corporate job and everyone is drinking the blue coolaid. Don't get me wrong. I like the coolaid too. Visual Studio 2005 is hands down the best IDE I've worked with. And no, for you Eclipse fans, I've not tried that highly vaunted IDE. I do know people that have used both and they invariably have good things to say about both.

Borland is spinning off the tools, so they say. So where will they be spun and how do these new dolled up Turbo versions fit into the equation. And so I don't have to wait so long, is there anyone at Borland that can get me a sneak peek copy.

I promise to run it through it's paces and report back here. I'm especially eager to try the C++ flavor. Could the good old days of Turbo be back? Let's see....

SOAP vs REST -- Clean vs Comfortable

SOAP vs REST
In my work I've had occassion to use both SOAP and REST in the client and the server. SOAP is easy if you have good tools. Hard wiring a WSDL is not my thing. At the risk of committing a pun foul, I'd rather eat a bar of soap than hard code good WSDL. Fortunately, .NET makes WSDL for simple web services easy, both on the server and client end of things. And WSCF makes more complex web services easy in the .NET world.

At the same time, REST is more comfortable, especially for those without nice support tools for consuming SOAP on a plate of WSDL. A nice simple HTTP POST. A simple agreement between friends to pass X, Y, and Z data along in a simple name value pair model.

Trust or Verify
I guess in some ways it comes down to trust. Do you trust the client to submit clean data? Can you trust your server application to parse through and make safe any data that is not clean? Or would you rather automate some of that authentication via schema and the rigidity of SOAP? For me, it all depends on the circumstances.

The Illusion of SOAP and Schema
How tight are your contracts? A good lawyer will take a two page agreement and expand it to ninety pages. Not only because she wants to bill you more but because she needs to cover all the bases. Are your web service contract bases covered? Is the schema and secondary validation sufficient.

Can REST Be Secure?
This line of thought takes me to the question. Can we trust REST? Well, the short answer is no. But the longer answer is, yes, just as much as we trust SOAP. The brilliance of SOAP is the contract is carried with the data, or at least that data is transported in a container with which the contract may be validated. So is that really better? Well, the underlying truth is that someone else wrote a bunch of helper code to help us perform the first level of validation in the message--form. But what about content. Yes, schema validation can do some content validation as well, especially of the type type of validation. Beyond that, it's up to you pretty much.

Validation Bottom Line
Ultimately the value and robustness of a web service, whether you use REST for it's simplicity or SOAP for the niceties of automated tools, will be determined by the code you write to validate and execute and respond with an appropriately formed response.

Consider Your Audience
Back in my poor old days as a technical writer, I had to always keep in mind and understand my audience. It really does matter. For example, my mother would not understand a single word of this post. If you are publishing web services, you must consider who will consume them. Will they be a hodge podge of PHP, JSP, ASP, and many other forms of "server pages" technology? Or will they be hard driving Visual Studio SOAP users who would rather have the tool do the heavy lifting and eliminate the need to parse?

Give your users what they want. And to do that, you may have to give them both SOAP and REST. I guess that won't hurt us too much. After all, a hot shower is always a good combination with a good night's rest.

Frameworks in Their Place

A friend shared this Joel on Software post with me today. An absolute hilarious read.

Excerpt:

"So you don't have any hammers? None at all?"

"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."

"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"

"Yes."

Frameworks have their place but time seems to be unkind to them. I'm not a Java guy but even the Java zealots I knew "back in the day" are now less bullish on the frameworks mess that exists on the Java stack. And no, for you remaining zealots, I don't want to fight about the point.

The fact is, the .NET Framework is only a few years behind. Will it bloat too? Has it already started with 2.0 and all the changes in ASP.NET and so forth and so on? Will 3.0 see bloat or a cohesive, more conservative growth pattern.

If we're all doomed to framework elephantitus, what is the solution? My hope is that Microsoft will learn from the failures of its biggest competitor and work as hard to keep the framework tight as they work to sell their operating systems. The same aggressive and successful behavior will be the only thing, perhaps, that can save us all from the same doom suffered by our Java brethren who are now escaping in droves to PHP.

Okay, I made that last part up. But it could be true. ;-)

ASP.NET, Threading and Application Pools

Thread Abortion
Why is my app working in my Windows XP Pro machine and not on the Windows Server 2003 production machine? I have two ASP.NET apps that run on the same server and interact between one another. Why? Because eventually they will go their separate ways behind a load balancer onto many machines. And I was logging unexplained ThreadAbort exceptions.

Clue: IIS 6 and Application Pools
After working on fine tuning my code nearly all day and still getting the same result, it dawned on me that the two unique Application Pools that I had created on which the two ASP.NET apps would run had properties. Doh! Check out the properties.

Application Pool Properties
I made the following changes on the assumption that because each request to the application would launch work on a ManagedThreadPool and return something immediately. Because of that, the settings of the application pool would allow the process to be killed and/or cycled while executing on those working threads and generate the unexpected ThreadAbort exception.

  • Recycling tab - disable the check boxes
  • Performance tab - diable the check boxes
  • Health tab - uncheck "Enable rapid-fail protection"

Positive Result
Ran the test again and alakazam! No ThreadAbort exceptions.

Threading on ASP.NET
There have been several issues I've run into over the past few months in dealing with handling work after the request has long since been sent back to the client. Using the ThreadPool vs the ManagedThreadPool from Stephen Toub and this Application Pool thing have been among the trickiest.

What are the dangers?
I'm sure there are dangers in disabling the safety net around the Application Pool. So I'm making sure that these two apps run on their own. I may experiment with re-enabling them one at a time and observing the result. If you have any advice for me on the matter, I'd love to hear from you.

RssJam.com - My Foray Into Feeds

A month or two ago, I started looking for an RSS client again. I had tried some a year or two ago but never really liked them. I now have greater reason to keep track of a few blogs and other RSS sources. There seem to be quite few now.

All the Readers a Local Client
Okay. Not all, but nearly all of the RSS readers are local clients which means installing another piece of software on a machine already full of it. What I wanted was a daily or thrice daily email with updates on all my favorite feeds. Simple. But none of the online sites I browsed provided what I wanted.

Rolling My Own
So I had a free weekend on my hands. I could have spent it fishing but I don't fish. I could have spent it golfing but I don't golf anymore. So I registered RSSJAM.COM and wrote a little file based ASP.NET app that would do what I wanted.

Daily Emails
Now I get three emails a day with a nice HTML formatted message that shows me my feeds with the stories that have been posted in the last 24 hours listed at the top.

Explosive Growth
After a month or two of telling a few people about it, only 16 people have signed up to use RssJam for free, so I don't expect it to be a huge hit or make me a ton of money. But it's a fun and useful tool. And for those of you who spent the time to read this post, if you want, just shoot me an email and ask for the code. I'll be happy to zip it up and send it to you. Who knows, you might set up your own site inside your team to keep track of all your teams blogs. Or whatever.

The link to email me is at the bottom of the left column here.

.NET Regex Fixed on x64

The Bug - Submitted June 5, 2006
On June 5, 2006, I submitted a bug to Microsoft their Connect site and expected that it was an exercise in futility. Who would listen to me? Here's what I submitted to them.

Title: Long pattern string results in race condition on x64 system but not x86 system
A long pattern string in a Regex constructor works fine on my x86 Windows XP development machine but results in a race condition that eats RAM very fast until an "out of memory" condition occurs an the process is killed on the x64 Windows Server 2003 machine. In steps below, I will cut and paste the code which resulted in the condition--the input exceeds 2000 characters so I will remove some of the lines that concatenate the pattern string but one can easily add additional lines to achieve the result that I experienced. To resolve it or work around it, I simply split the Regex into 19 Regex objects and that resolved the problem.

This happened after developing a pattern to remove unwanted words from text before I run the keyword extraction algorithm I wrote based on this whitepaper by a brilliant young researcher named Yutaka Matsuo and the honorable professor Mitsuru Ishizuka at the University of Tokyo.

Fixed - July 7, 2006
I received an email from the Connect system to let me know the bug had been fixed. Of course, it was a nice, poorly formatted plain text email spit out by the system. Where's the love? Still, I was impressed that the system (hence somebody who programmed the system) bothered to send a note to let me know that the bug was confirmed and fixed.

I'm sure a million or more of my readers have already enjoyed this experience, but for those small few that have not, I thought I'd share. So don't hold back. When you find a bug in the framework or just want to complain, visit the Connect site and see what happens.

 

HttpWebRequest, ServicePoint and BindIPEndPointDelegate

I've spent months fighting with 3rd party components and my own hand rolled code that would allow me to achieve essentially the same thing you can with the HttpWebRequest class with one additional feature: binding a specific end point (IP address) to the object so that a remote server would recognize the call as coming from that specific IP address.

I looked through the description of each of the HttpWebRequest's members in the MSDN documentation. I searched the internet high and low. I banged my head against buggy third party components. And in desperation attempted to roll my own. All efforts resulted in a thorougly disappointing result.

Bring on the Delegates

Two days ago, I was chatting with a friend and I expressed my desperation. I told him I'd drive to his house and give him a fifty dollar bill if he could tell me how to use the HttpWebRequest object and assign or "bind" the local IP. He started digging. And I tried one last Google search using HttpWebRequest and IPEndPoint, I think it was, in the search. And I found this little gem about 5 seconds before my friend suggested taking a look at the HttpWebRequest's ServicePoint member and the ServicePoint's BindIPEndPointDelegate member.

Glory Hallelujah!

One of my new best friends is someone I don't know: Malar Chinnusamy. Thanks a million, Malar.

So to the point of the title of this little rant. It is the delegate stupid. The lesson learned is when you can't figure out how to do something with the .NET Framework, check out the delegates. And the delegates of the object's members. And so on...

public delegate IPEndPoint BindIPEndPoint(ServicePoint servicePoint,
  IPEndPoint remoteEndPoint, int retryCount);

That little gem is a beautiful thing. It lead to this:

private IPEndPoint BindIPEndPointCallback(ServicePoint servicePoint,
  IPEndPoint remoteEndPoint, int retryCount)
{
    if(retryCount < 3)
        return new IPEndPoint(IPAddress.Parse("192.168.10.60"), 0);
    else
        return new IPEndPoint(IPAddress.Any, 0);
}

and...

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
req.ServicePoint.BindIPEndPointDelegate =
  new BindIPEndPoint(BindIPEndPointCallback);

I told my friend that I wish I knew and understood everything in the framework. He said that he wished I knew it all too. So, when there's a shortage of helps and great blog posts out there, don't give up. Follow the delegates and you won't look as stupid as I felt once I found my new friend's post.

Code Fonts and ClearType

I ran across the Consolas font from Microsoft today. I love it. I'd been using Courier New in 9pt and have now switched to Consolas 10pt. Much easier on the eyes. But not at first. It displayed quite poorly until I enabled ClearType in my display settings.

I've been using LCD monitors for a long time and why I've not switched to ClearType, I'll never know. It's like my glasses suddenly became more effective.

How many other cool things have I missed? One can never really know.