Tuesday, July 21, 2009

jQuery and Scriptmanager in asp.net Custom Controls

I dove into jQuery today with the intention of using the datepicker control in an asp.net custom control that I had built. I ended up having to jump through a few hoops to get it to work properly so I thought I would share what I discovered.

First, lets start with a simple user control like the one below:

What I wanted to do was make the date text box control work as a jQuery date picker and have the custom user control work properly with UpdatePanels. In order to have a text box work as a jQuery date picker you simply have to call the code below (described in detail here):

The problem when using user controls is that it's impossible to know the exact control name of the other controls contained in the user control because asp.net renames those controls at will in order to avoid conflicts. To solve this problem we need to use the c# code below in order to get the mangled name that asp.net creates:

At that point all that is left to do is call register the datepicker() function with the ScriptManager. Since my control was created to only work with an internal website, I could guarantee that the page containing the control would always have ScriptManger tag initialized. If you are working with a generic control that may or may not be in an update panel check out a useful proxy class here.

Here is the code that should work to register the jQuery script required to put initialize the date picker control with the txtDate text box.

I said should work above because this code leads to the error described in this knowledge base article.

Error KB927917 in IE8: Unable to modify the parent container element before the child element is closed.

What is happening is that the ScriptManager is registering the startup script in a block right before the closing form tag. The problem stems from the fact that jQuery is trying to modify the body tag when it builds the date picker pop up. The body tag is a parent of form tag and the form tag is not yet closed. Bummer.

After more searching I came across this jQuery tutorial that introduces the (document).ready() function. This turned out to be the key. By including this function in the registered code the datepicker() waits until the page or update panel finishes loading before creating the date picker popup. The final code listing:

One final note. Most sites I found said to use the control and the control type as the parameters to the RegisterStartupScript function. Using the control parameters works until you add more complexity to the user control. For example, after adding a databound grid, changes to the underlying data would update the grid and thus the update panel the control resided on, but not re-register the date picker script. The fix for this was to pass the page itself to the register script function.

Sunday, May 10, 2009

News Overload!

I'm an information junkie. IT, economics, politics, general 'news', etc... I'm drawn to it like a drug. Daily I used to visit various web sites like /., The Wallstreet Journal, and Google News in order to get my fix. Then, in order to become more efficient, I started using Google Reader to manage RSS feeds. I thought I had found new nirvana. I could quickly scan, tag, share, and manage hundreds of news stories easily through a single interface. Everything seemed great but...

It is just too much information. Google reader makes it easy to add new RSS feeds from any source. Before long I was seeing hundreds of new stories through the day. The primary problem is not the raw amount of stories though, but the content. So much of it is duplicated from each source.

At this point I have gone full circle. I no longer use Google reader, and now just check a handful of sites daily.

Friday, March 13, 2009

32-Bit To 64-Bit Upgrade

I've been busy upgrading and moving a MSSQL server and all of the associated applications from a 32-bit Windows 2000 server to a 64-bit Windows 2003 server. The process has been a lot of trial and error. Below are some tips to use when moving from 32-bit to 64-bit.

Try to find a 64-bit equivalent of your application. If you wrote the application, recompile it. If you bought the application try to find an upgrade. If you have to use the 32-bit application keep reading.

If you have to run 32-bit applications using WOW (Windows On Windows) remember that nearly all of the system configurations and libraries are separate between 32/64-bit. The problem is it is not always obvious how to handle each case. The registry for example uses the same regedit.exe for both editing both the 32-bit and 64-bit keys. The difference is that all of the 32-bit keys can be found in the [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node]. There are some exceptions for COM, but if you have a 32-bit application that just isn't working check its registry keys to make sure they are in the right place.

External drivers are another issue. From my experience many 32-bit ODBC drivers install just fine under WOW. If you come across one that doesn't, I couldn't find much else to do other than find a more recent version. While we're on ODBC it (unlike regedit grr) has two completely separate apps for managing 32-bit and 64-bit ODBC entries. 32-bit applications will only see the entries in the 32-bit ODBC manager and vice versa for 64-bit. This is another gotcha to check if a legacy application isn't working and it is database driven.

Since it is a MSSQL server that is being moved there is one final piece to remember. DTS packages only run in the 32-bit container (even when running MSSQL-64). This means that any external ODBC drivers that they may need also have to be installed in the 32-bit ODBC manager. Another small annoyance is that the DTS package editor no longer works under 64-bit windows. This means that all DTS package editing has to happen on a 32-bit machine. All the more reason to finally upgrade those last remaining DTS packages to SSIS.

Good luck!

Thursday, March 12, 2009

Agile and Cowboy Coding

All too often I meet people who claim they are agile developers. After a short discussion I realize they are not using any software development methodologies and are instead cowboy coding. Agile development is not a plan free environment. In fact, being an agile developer requires more developer discipline than even the dreaded waterfall.

Agile development requires the proper tools. Without tools to help with automated testing, refactoring, source control, etc... agile development would be dead in the water. I believe it also requires programming language support. You could try to be an agile developer writing assembly code, but I don't think you would get very far. Java really set the ball rolling for languages that supported the agile way of developing. The trend has continued with scripting languages like Python and Ruby (and it's associated frameworks like Rails).

The developer must also understand how to properly use all of these tools. Back when K&R released their book on the C programming language you had all you needed to know to write software in a nice consise book. Nowadays you need to know a multitude of languages frameworks, environments, patterns, and so on in order to create useful software.

Agile development, like other iterative development methodologies, requires proper planning. This is where many developers get tripped up. Agile does not mean jump in and code. Developers must plan short complete blocks (incidentally very similar to short runs of the waterfall) of gathering requirements, designing, developing, testing, and releasing that at some point deliver a complete product with all of the requested features. Determining the features that make the cut each iteration and maintaining the overall project vision can be challenging.

If you think you are currently an agile developer (and no, just using SCRUM does not make one agile), take a hard look at your process, or lack thereof, and verify that you are not just some cowboy in disguise.

Monday, March 9, 2009

1 TB Loaded in 30 Minutes!

This is a great new white paper out of Microsoft. In it they explain how to move a lot of data from flat files into MSSQL using SSIS. Some key take aways from the paper and my personal experiences loading data into MSSQL.
  • If at all possible get your source systems to provide flat files to the ETL processes. The popular ways like web services and ODBC are nice, but they tend not to perform as well when you start moving a lot of data.
  • Run SSIS on a separate server from the final destination database server. This is key for balancing the load and being able to easily up later.
  • Test, analyze, change, repeat. While the authors did use the standard off the shelf versions of the MSSQL and SSIS, they did have to tweak them to get the results they were looking for. It is critical to analyze your solution and make adjustments.
Provide other ETL best practices below.

Sunday, February 22, 2009

Excel Evils

I'm a big fan of using the best tool for the job. The old adage that says when you only have a hammer everything looks like a nail explains why so many people use Excel for tasks beyond its capabilities. This article provides some facts for what I've been seeing anecdotally for years.
  • "Spreadsheet errors are probably more prevalent than most users realise. A 2005 paper by Jonathan P. Caulkins, Carnegie Mellon University, refers to earlier studies which suggest that the (simple) average proportion of spreadsheets with errors was 46%. A further analysis of this literature by Panko suggested that even those numbers might understate the problem, since not all audits find all errors. Out of 8 studies auditing a total of 421 spreadsheets using better methodologies, only one study had an error rate below 21%. According to Panko, a weighted average of published spreadsheet audits since 1995 suggests that 94% of spreadsheets had errors. Even if these stunning rates overstate the problem in practice, it is hard to avoid the conclusion that errors in spreadsheets are common. "
The question is, what can replace Excel? I've been writing one-off pieces of software to replace Excel for years. The problem is that Excel has become so ingrained in many users workflow that even if I provide all of the options they used in Excel they still want the ability to export the data back to Excel.

It is time to move past Excel (and thus spreadsheets) and into tools that treat data as data and calculations as calculations and not confusingly mix the two as is often the case with Excel. Enterprise mashups are going in the right direction, but still don't give users the same flexibility as Excel. So what do you think will eventually replace Excel as the defacto analyst tool in the enterprise?

The Lazy Programmer: Introduction

la⋅zy

adjective
1. averse or disinclined to work, activity, or exertion; indolent.
2. causing idleness or indolence: a hot, lazy afternoon.
3. slow-moving; sluggish: a lazy stream.
4. (of a livestock brand) placed on its side instead of upright.

Nowhere in the definition above does it mention anything about a disinclination to think. In my mind "The Lazy Programmer" is not a derogatory term. In fact the best programmers are lazy. They would rather think before acting in order to prevent more work later.

Those programmers who are not lazy often code themselves into corners. They are too busy writing code to stop and think about what they are doing. They are the same programmers who get married to one programming language, one tool, or one methodology. They are the same ones who will copy and paste the same piece of code all over a program when a class or library should have been refactored out.

The Lazy Programmer will be an ongoing section where I will pick one software development topic and explain what it means to be lazy.

Hello World

The typical starter blog post. I went through many names before finding "The Pensive Programmer." It's quite annoying the number of abandoned blogs out there that are occupying many good names.

So what is this blog about?

First, I plan to write about my ideas on anything and everything that has to do with the creation of software. I hope that my ideas can spur on further discussions. I have only been writing software professionally for a little over 10 years and know enough to know that there is a lot I do not know.

Second, this blog will be a place where I write about interesting problems that come up at work and how I solved them. Hopefully these answers can be helpful to others and through discussion I can find even better solutions to the problems I come across. I come across various blogs all of the time that provide me with solutions to problems and it is time I give back. Knowledge wants to be shared.