Get Stock Quotes from Yahoo

My previous two posts alluded to this project. This file contains a Visual Studio 2008 solution. It is a class library written in vb.NET. You can use it to get basic stock quote information from Yahoo finance. It is working as of March 31, 2009. When Yahoo changes their format, the code may have to be modified to adapt.

The goal of this project was not stock quotes. Instead, I was learning, and practicing in these topics:

A general provider pattern
A provider factory pattern
Using linq and reflection
Benefits of using interfaces
Microsoft.VisualBasic.FileIO.TextFieldParser
HttpWebRequest , HttpWebRequest

If you would like to add a new stock quote provider, add a class in the Providers folder and have it implement the IStockQuoteProvider interface. That is all you have to do; but you could also add unit tests for your new provider. Note that the existing providers are implemented as “Friend.” This enforces callers who reference the assembly to create instances of providers by using the StockQuoteProviderFactory.

Thanks to Ryan Cromwell for pairing with me and providing the starting template. I’m sure this code can be improved. If you see opportunities to make it better please let me know.

Ryan Cromwell's blog

A CLR Stored Procedure

A talk given at the Dayton .NET developers group meeting on March 25, 2009.

The talk is a quick introduction to writing a CLR stored procedure for SQL Server using Visual Studio. This file contains the slide deck, a Visual Studio 2008 demo solution, and a Word document describing some steps to take if you want to write a CLR stored procedure. The code is in vb.NET.

If you open the solution you will have to establish a connection to some database. I recommend an empty database created in your local SQL Server Express instance.

A Detour

Part of yesterday and all of today were spent working on a little software project that took entirely too long.

I created a class library which contains one primary function. It makes an HttpWebRequest, parses the Response, and returns some useful information to the caller. I deployed this into SQL Server as a CLR stored procedure.

This was optional work; not an absolute requirement for my primary project. It was related - as it would help in testing. But an astute outsider or casual agile head would recognize this for what it was – a detour along the path to shipping the product.

The work covered new ground for me. I had not written any CLR code for SQL Server and I had never deployed a DLL assembly into SQL Server. Now, after some information immersion and helpful guidance from a co-worker, I have done both.

Tonight, I’ve been replaying the struggles and asking myself why it took so long. All the information needed to solve this was available. Google searches, MSDN documentation, SQL Server documentation – it was all there. It just took several hours to piece together enough bits to finally make it all work.

Part of the problem is my tendency for trial and error progressions. Just try something, watch it fail in the debugger, read a little, then try something else and watch it fail again.

Here is something I’ll try next time. Before I start any work, I’ll take a deep breath, push back from the keyboard, and have a conversation with myself; something like this:

Ok, this is a new problem. It will require some learning. What is the best and fastest way to get the learning, before I burn too many work cycles? What do I want I the end? What is the shortest distance to “the answer?” Would a bunch or reading be best or should I seek an experienced co-worker? Well, not only that…should I even begin on this? Perhaps deferring this to another sprint would be best?

For me, software development is engaging. The feedback of seeing your work “perform” is compelling. Could it be that taming this feedback addiction might be a productivity boost?