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?

Project Momentum – Recovering from a Body Blow

The momentum of a software project varies. There are times when momentum is good; progress is being made, the team is optimistic, all features seem possible. At other times momentum is bad; a team member or two is pessimistic, every obstacle seems like a mountain, people begin to wonder why the project was ever started. In my experience a trigger can usually be identified; a trigger which shifted the tide one way or the other.

Sometimes momentum is real. Sometimes it is imagined. This is true for both good and bad momentum. A good project lead is a realist. They know when perception of momentum is temporarily distorted. Asking the right people, the right questions, even when the answers are known, can often improve the situation.

Occasionally project momentum takes a body blow. It might be a little thing like leaving work two days in a row with no solution to a seemingly trivial problem. It might be a big thing, like realizing that key assumptions affecting large swaths of architecture – were wrong. Whatever the cause; project momentum comes to a standstill.

What to do? No single answer will work in all cases but here are some things to try:

Talk about it; get the team together and bring the perceptions to the surface. Let everyone express some frustration and vent before taking on the difficult problem.

Get some help; bring people who are not working in the project into a meeting. Tell them about the problem. They may or may not be able to help – but talking through the problem with an outsider may force minds into different grooves; grooves where there is a solution.

Redirect to other work temporarily; you almost always have some other work that can be done. Redirect the team to this other work for a day or two, let them rack up some successes, then go back to the hard problems. Some problems that cannot be solved by a developer with low self confidence are a breeze following success in another arena.

Have a Google search fest where the team spends 15 minutes searching the web for help; ask each person to bring their top 3 links to a meeting. This is a variant on ‘get some help.’

It would be nice if some meter visible to the entire team could show a real indicator of project momentum. Dream on. Just be aware that there is such a thing as momentum, that triggers can cause it to reverse tide, and that action can sometimes fix it when it goes astray.

So you want to be a software developer?

You will write (or generate) large amounts of code that will have to be re-worked or completely re-written because design decisions and goals will change.

You will struggle with technically difficult challenges; sometimes for days.

You will face the question "when will it be done?" many times - and you won't know the answer.

There will be deadline pressures all year long, year after year.

There will be competition for your attention - pulling you from one project to another.

You will want to work on new things...but have to work on old things first.

You will have to find and fix errors months or even years after you or others originally create them.

New technology will come at you at a rapid pace - and you will have to struggle and learn about it on your own - for no extra pay. This will never stop while you are a developer.

You will search the internet relentlessly looking for solutions.

There will be days when you code non-stop all day long and still have lots left to do.

You will have to look at, understand, and fix other people's code.

You must be able to communicate with others about your code and their code.

You will have to make progress when given the most vague and ambiguous directions or specs.

You will read large volumes of coding related material to keep up with technology.

You will find yourself working with design or architecture decisions that you don't like or agree with.

You will not be able to give up when solving a difficult problem.

You will have to communicate with and support end users throughout your career.

Some work will be tedious, repetitive, boring, and make your wrists sore - but you'll have to do it.

You will have to communicate effectively through writing.

You should desire to always improve the quality of the code you write and the efficiency with which you go about the work.

But... it is a darn engaging way to make a living!

Different - and fun.

During the last few days, I did a small ASP.net project. Most of my experience is working on WinForms apps. This proved to be a fun project because it was outside my normal groove.

It is a simple one page internal report. No interaction. It just displays data in two grids. I started out creating a class library - not really knowing how I might deploy a front end. I got the queries and the data massaging done in a few classes. Not really thinking about how this would be used - I did my standard WinForms thing: created a form, dropped two grids on it, wired it up and it worked. I was not impressed. Battleship grey, standard grids, nothing to write home about.

A random thought came to me to try this as a web application. I would not have to write a setup application or worry about deploying and maintiaining it on various user workstations.

I added a web application to the class library solution and started to ponder Default.aspx. Writing an ASP.net application really is a different beast when your brain is configured for WinForms. After a few google searches, some help file reading, and some bookshelf skimming - I had something starting to work. With a little more effort it started to look much better than the WinForms version.

Not knowing much about IIS, I had my co-worker Bob help me get this deployed. Finally, I sent a hyperlink around to the users. They all tried it and sent email within a few minutes!

No technology breakthrough here. This is a very simple non-interactive page. The breakthrough is more in my developer mindset. In the past, I've kept ASP.net applications at arms length...I have a ton to learn but this project got me past that initial hesitation...I should force myself outside the groove more often!

Development Balance

There is a balance to strike. Too few active development projects and I'm not pushing on any boundaries of learning; just what I need for the work layed out before me. Too many projects and each suffers from fleeting focus. Do a little on this project, do a little on that project; none of them are progressing enough to develop that feedback loop. You know the one - where you code some stuff, it works, it feels good, so you code some more - it also works, it also feels good, etc. Just the right number of projects...that is the place to be. Maybe you have one project that really pushes your limits - forcing you into new territory. You have a few others that are in the pure production stage...many of the decisions and thinking are done...you just have to crank the rest of the code. Maybe one or two projects almost finished.

I've been developing software for many years. This balance is elusive. I used to think it was out of my hands; the result of external forces. The longer I develop the more I realize it comes from decisions accumulating as I work. Which projects I push for, which ones I shy away from, which design approach was used , how much unit testing was done, how many simplifying assumtptions were made which ignored broad swaths of possibilities? Like an incrementing counter in a recursive loop...eventually it can overflow.