One of my current projects involves relocating my client to a new hosting environment. This is proving to be a challenge as I don't really know the application that well, yet. The code is hybrid asp/.net, and one of the bugs that is totally driving me crazy is actually date formatting. The old server environment was configured with English US as the default locale, whereas the new environment is English Canada. As a result, I have a few database inserts that are using VBScript's Now() function to write the current time-stamp. (Not exactly why the database isn't providing this functionality -- but that's another problem). What's odd is that I changed the default locale, but wasn't seeing any changes in the old asp code -- the date format was still wrong.... I had changed the regional settings (or at least I thought I had) and couldn't figure out why I was seeing the proper date format from the command-line but not in asp. The glaring mistake I made was that I had missed the "Set Default" button at the bottom of the control panel. If you forget to click that -- then you're only applying changes to the current user profile. The link for this article points to a ms kb article on some new options for the regional settings for w2k sp2+. I'll come back to that if it proves to be a problem with my .net code.
Wednesday, January 19, 2005
Lori and I have been counting down the days to our house closing on a chalkboard in the kitchen. Our real estate agent just called us and asked how we felt about moving the closing date up by a month! I'm all for moving in early, but we've already paid for our March rent. We're trying to figure out a way to maximize our move-in time while minimizing the money going out.
by bryan at 10:55 AM
If code is half-science and half-art, then this is either code reflecting life, or geeks seeing code when ordering coffee.
by bryan at 10:51 AM
Tuesday, January 11, 2005
Over the last year, our organization has been migrating our version control systems to subversion. Man, what a ride. Previously, I've grown accustomed to Visual Source Safe, which when looking back seems like -- well, for lack of a better term, like sticking your code into a shredder and setting it on fire. While it does have it's advantages (it doesn't require any brain-power to use) -- it doesn't do complex things well, if at all. If you go down the path of pushing the envelope and try to make it behave like an enterprise version control system, ... it'll bite back. hard. Am I surly? Sure, why not. Unfair? Well, you try repairing a 3 Gig corrupted vss database and call me unfair. Subversion is a far cry from the simplicity of VSS. It's command-line utilities only (there are open-source GUI's, but I haven't heard any good things), the concepts are radically different, and it doesn't plug into the IDE. I'm not complaining -- these are advantages. Subversion requires you to think differently about what you consider source-control. Gone are the days of my team complaining that they "...can't work on that file because it's currently checked out." At any rate, I won't be going back to VSS any time soon. I'm sold on subversion. Coupled with Cruise-Control.net, we've got a pretty sweet development-integration cycle happening. As of late, I've switched projects recently, a form of promotion if you want to call it that, and I'm now responsible for a large account that pushed out about 62 projects last year. This means we are branching and merging in subversion all the time. At the rate we're going, I'll be a subversion guru in a week....
by bryan at 6:49 PM
Thursday, January 06, 2005
Lately, these articles have sparked a lot of interest within our app dev group. Provider Model Design Pattern, Part 1 Provider Design Pattern, Part 2 I had a client that was experiencing problems with their monolithic application, in that they were adding microsites to their site on a weekly basis, and found that they had to recreate the wheel for their application framework for each microsite. At one point, they had up to 20 different assemblies referenced for each microsite. In addition, they wanted to keep the Personal Information in their production database private, thus they didn't want to hand out their schema or access to their database. On top of that, they had a multitude of 3rd party vendors who supplied code to them. Each had their own set of coding standards and beliefs about the application's responsibilities. Including us ;-) We looked at building an abstract framework that all the code would reference. The trick was to make everything extremely generic so that it could be 100% transparent to the developers. This meant pushing code out of base classes and into an abstract version in the framework, or out of the project entirely and into HttpModules. The abstract framework tied to concrete providers, as in the msdn articles above, and allow third party vendors to write and use their own providers for their own environments, and allowed the client to use the same application-framework for multiple small-to-large size applications with different configured providers. I've found these links useful, so I'm posting them here so that I can find them when I need them, but if you stumble upon them, maybe you'll find them useful.
by bryan at 4:02 PM