July 2007 Blog Posts
SQL Enterprise Manager TaskPad Script Errors 'Fix'

Switch the view to something other than TaskPad, then back again.

posted @ Tuesday, July 31, 2007 2:21 PM | Feedback (0)
The cat that can predict death


posted @ Saturday, July 28, 2007 5:24 AM | Feedback (0)
T-SQL: Using Microsoft Office Applications to Edit/Run/Debug DTS Packages

From Doug Waldron.

For instance, using Microsoft Word:

Save the DTS package to the file system.


Tools->Macro->Visual Basic Editor

Pops a Visual Basic 6 Window.


Cut and past your code into the new window



check Microsoft DTSPackage Object Libray


check Microsoft DTS Custome Tasks Object Library


check Microsoft DTSDataPump Scripting Object Library




F8 to step through


F9 to set break point


F5 to run

posted @ Friday, July 27, 2007 1:59 PM | Feedback (0)
T-SQL: Using Top 100% in Views

In SQL Server 2000, you can do something like:

Create view myView as select top 100 percent column1, column2 from mytable order by column1

to allow for ordered views.  It isn't 'supposed' to work, but it does.

It doesn't in SQL Server 2005.  However, this does:

Create view myView as select top 99.9999999999999 percent column1, column2 from mytable order by column1

If you count, there are 13 decimal places.  If you add a 14th decimal place it doesn't work.

Go figure.


posted @ Friday, July 27, 2007 1:31 PM | Feedback (0)
Dislike of hand-writing HTML != Like Drag and Drop Designing

Hammett has a post up about a point I made on Ayende's blog concerning the need to have to hand-write HTML to have a control on a page in Monorail (how many link references can you have in one sentence?).  The 'money' quote:

"And, I’m not missing the point, I DO NOT WANT TO HAVE TO HAND-WRITE HTML everytime I want to have a control on a page. That seems to me to be what Monorail requires and which you seem to be acknowledging."

Now, I'm shallow enough that I still get a little visceral thrill whenever I see my name in print, even when someone is calling me a douchebag (I heard that), so I appreciate his response.  And I'm not just saying that because he believes I have a point (I did say 'just', LOL).

Besides not liking to hand-write HTML, I am admittedly biased against Monorail for at least the following reasons:

  • I thought a comment on their site was too snarky for my taste.
  • I had to write some PHP code for a site once.  I don't like PHP syntax.
  • I have a visceral suspicion of Rails.  I don't like being forced to follow someone else's convention, which it seems to force upon you (now, my massively limited understanding is that one of the reasons why people like Rails so much is because they come from a Java background and they tire of the framework-heavy nature of Java web development, so Rails is like a breath of fresh air...I can understand that).

I'm also very aware that none of these additional 'reasons' are really good reasons whatsoever for disliking Monorail.  At all.  It has the tacit or explicit endorsement of people who a) I respect somewhat or b) are quite clearly better developers than I am (though that's a low bar to clear, really) or c) both.  So, it deserves a better look from me.  Not because people think it is 'cool' (some people though CORBA was cool, so there's never accounting for taste), but because it could very well make it easier for me to deliver highly scalable, testable, productive applications to clients.  And that's really all I care about right now (well, I'm thinking of taking the dive into the Entity Framework for my own stuff in part because I think it is cool, but that's another topic). 

I am looking forward to being able to take a deeper dive into Monorail at some point, when I have something I can pilot (slow, obstinate people like me need a QuickStart sometimes to really understand a technology, so there's that factor also).

But, that's not the point of this post.  It has to do with this comment from Hammett:

"Today MonoRail/RoR approach is to give you a canvas so you can start painting on it. That means you have to hand write html, after all what kind of web developer are you if you can’t stand html? A drag-and-drop developer, I’d say."

And the few comments to the post so far (I'll add one after I post this) pile on about drag-and-drop, blah, blah, blah.

Well, folks, I can't speak for anyone else, but:

  • I don't use drag-and-drop for web development.  Can't stand it.  I want CSS for styling *and* layout.  The last time I used drag-and-drop doing ASP.NET development was something like 2002, and I was ashamed of it then.
  • When I'm working on a master page or web page or user control, 90% of the time I'm in source view, not design view.  For instance, if I want to set the datasource for some element in an ItemTemplate, I'm 'hand-writing' that in source view, not using the graphical designer.
  • Actually, I'm not sure what I use design view for.  I'll have to usability test myself and remember why I use it...let me check a current UserControl I've been working on....I don't think I've ever looked at it in design view.  I look at it visually when debugging.  So, maybe more than 90% in source view.
  • My own stuff uses a modified version of MVP based off of Haacked's post, so I'm really against spaghetti code designers can produce (though I'm fine with Typed DataSets when they are appropriate).

So, let's get rid of this knee-jerk reaction, shall we?  There's probably something to be said about why people assume that only drag-and-drop designers could not like hand-writing HTML (and there's the unspoken assumption that drag-and-drop designing is always bad), but that's another topic.

So, why did I make the comment on Ayende's blog that I did?

A couple of reasons:

  • Response.write anyone?  Seriously, this is nearly identical.  It's like going back to ASP development.
  • Strings anyone?  Compile time checking?  Seriously, I can't stand having to write out HTML in string format, because I know, personally, that I will f$%^ that up.
  • Intellisense anyone?  Resharper actually will give some intellisense support in source view.  I was stunned (in a good way) the first time I saw a UserControl was Red because I set some OnSelectedIndexChanged value to a non-existent method.
  • Re-use anyone?  If I want a drop-down and want to handle events like its SelectedIndex changing, are you telling me I have to do it myself from scratch?  Why would I want to do that?  Isn't this re-inventing the wheel?
  • And if in a moment of 'insanity' I decided to be a ControlFreak (pun intended), I can use a Literal or Repeater or something and do all that.

So, I'm not against having total control, and Monorail seems to give you that, and that's something that people like Ayende seem to love.  And that's fine.  Just don't force me to hand-write HTML to implement a fricking button.

posted @ Thursday, July 26, 2007 6:58 PM | Feedback (4)
Reasons why Ayende hates SSIS

This is an excellent list.  My number one complaint (hard to narrow it down to just one #1) is the terrible way it 'handles' (and I mean that entirely sarcastically) errors.

I really want to love SSIS.  Hell, I'd settle with just liking it.

posted @ Tuesday, July 24, 2007 6:11 PM | Feedback (0)
T-SQL: READ COMMITTED and multi-counted rows

Snapshot isolation is the only way to get around the problem.

posted @ Tuesday, July 24, 2007 2:06 PM | Feedback (0)
T-SQL: NOLOCK and Page Splits

The upshot is that if a page split happens when doing a NOLOCK select, you can see the same row twice, or miss rows altogether.

The fix is to always have an ORDER BY in the SELECT.

posted @ Tuesday, July 24, 2007 2:01 PM | Feedback (0)
SQL Server and Raid 5

Always make sure you are comparing apples to apples.

posted @ Tuesday, July 24, 2007 1:36 PM | Feedback (0)
One way to use prison for rehabilitation

posted @ Saturday, July 21, 2007 10:30 AM | Feedback (0)
Contract Retrospective

So, my 3 month contract turned into two and a half years.  What to make of all of it?  I'm sure that this will not be a 'proper' retrospective in the Scrum sense, whatever that is.  But it will serve.  I'll focus on the things that worked and the things that didn't work quite as well.  Without getting into confidentiality details, it was essentially an ETL project.


The things that didn't work as well:

  1. Lack of properly scoped requirements
    1. Seemed simple enough.  Vendor had product A which was used to bring data into internal systems (in a very brittle, painful, time consuming way).  Vendor had a better product B.  So, just make sure you get the same data from product B that you did from product A. 
    2. No one checked to see how easy/difficult it would be to get the 'same' data.  It was never clear to me if this was the vendor's fault, the client's fault, both, or neither, but whatever the case, by the time I came in, the conversion project was ready to roll.  As it turned out, it was not easy at all to get the 'same' data.
    3. In certain cases, it was clearly the vendor's fault.  You'd ask them for a rule to convert data value X to data value Y.  They'd give you a formula.  You'd implement it and discover it only covered 85% of the cases and you'd bring it to their attention.  They'd respond "Ok, how about this one?"  Iterate dozens of times.  There was a lot of humor in the process.
  2. Not adequately unit testing
    1. I didn't get onto the testing bandwagon till recently.  You live, you learn.
    2. Because of the nature of the project, vast portions of it were untestable.  I had arguments with people about this, but it is true.  A large number of 'bugs' and problems were only visible by looking at a large dataset and comparing it over time (sometimes a week or a month were needed before you would see data that was problematic).   There is no way that I know of to unit test actual data in situations like this.
    3. Having said that, it would have been greatly productive to create a C# test suite that could test basic outputs of UDF calls and other things such as that.  And some of them wouldn't be 'pure' in some sense of the word, but setting up integration-type tests of problematic data situations could have been done.
  3. Corporate Politics
    1. This is one of those 'it was not my fault' sort of things, but there was quite a bit of politics involved in getting the work we did promoted.  It was, in retrospect, a *huge* change for the end users what we were doing (no ETL conversion project can achieve 100% data symmetry so the changes were noticeable), but the fact remains that the actual coding work done took 30-50% of the time to complete, the rest of the time was involved in convincing the important players that the changes were correct.  People *really* don't like finding out that a certain portion of their data has been incorrect for many years, and so no matter how well you describe that fact, prove it beyond reasonable doubt, there is an inherent resistance to accepting it.
  4. Talking more, listening less
    1. This is actually more important for other contracts down the road because the people I worked with liked to be challenged, liked strong opinions, etc.  But, this is something to keep in mind.  As my last project manager (more on him below) described it, "Working with jdn is pretty easy.  Ask him his opinion about whether something will work or not.  After he says 'No', ask him again and maybe he'll listen to what you said in the first place."  Now, he was exaggerating.  How much is open to debate.  But it is important to do everything you can to listen to the client, what it is they are trying to achieve, how they want to get there, etc.  Give them the opportunity to explain themselves as fully as possible, remembering at all times that it is their business, and you are there to help them.
    2. And then after all that, tell them 'No' if that is the correct answer.
  5. Remembering I'm a contractor, not an employee
    1. A friend of mind reminded me a long time ago about a very valuable lesson to remember as a contractor.  I was all ticked off about something, because what was being implemented the way I wanted it, was going to cause further work down the road, something along those lines.  And he said "Are they going to pay you any more to do it better?" 
    2. This isn't to say that you don't provide the best services you possibly can at all times.  But, it is important to remember that, as a contractor, you basically are providing the client what they want.  If the client wants something unethical, you walk away, but otherwise, if they want to implement something you don't agree with completely, that is your job.  To give them what they want, even if you don't think they should want it.
    3. More times than necessary, I would find myself forgetting this.  This wasn't a career path in the same way as being an employee is.  The last project manager I worked with was notorious for being difficult to get along with.  He was a control freak, he didn't want developers meeting with end users (even though they liked me better), he wanted to be involved in every phase of the project (architecture, development, you name it).  Most every employee on the team who worked with him asked to not have to do it again. As an employee, I wouldn't have worked with him as easily.  Once I remembered to 'know my role', he was actually quite fun to work with.  He was very intelligent and had a good sense of humor, and so we accepted our roles.  As a contractor, I didn't really have much say about many things (though since he was intelligent, if I felt strongly about something and argued it, he would accept my judgment, begrudgingly...which make it that much more fun when he had to admit I was right).  On the other hand, as a contractor, I had a certain amount of freedom to say things you couldn't really say to someone if you were an employee.  Especially since our boss was an interesting sort who believed that good-natured insulting built camaraderie, it was open season, and he'd toss it right back at me, and we'd both enjoy the exchange.
    4. To bring it back to a slightly more serious and less cynical level, it is important to remember that as a contractor, you are providing services for a fee, and while your expertise is being requested, your work will carry on long after you are gone.  Sometimes, you implement something less than 'ideal' in your mind because it is politically expedient.  Idealists of the world will get upset about this, but really, in the end, it's their business, and corporate politics often times makes the world go round.  And sometimes, you are simply flat out wrong about the best way to implement something.


The things that did work well:

  1. Knowing the right technology to use in the right situation
    1. The client had committees, lots of them.  Which produced standards, lots of them.  Where appropriate, we ignored all of them.
    2. Most everything was supposed to use C# as much as possible.  We used pure T-SQL.  They loved web services.  We used none of them.  On the SQL side, you had to use surrogate primary keys.  We didn't (and it was right not to use them, in just this case).  You needed to enforce referential integrity.  We didn't (and it was right not to enforce them, in just this case).
    3. We needed our own hardware, isolated from the rest of the production environment.  We forced this.
  2. Having the ability to work freely
    1. Except for a few hiccups, I was able to code what was needed to fulfill the requirements, as I saw them.  There were code reviews, but mainly, I could write the code I felt was needed.  Not having to look over your shoulder constantly as you work is tremendously valuable.
  3. Working with like-minded co-workers
    1. My main boss was one of the best I've ever worked with.  He was/is one of the more interesting people I've gotten to know, but he let you do what you needed to do without needing to change everything.  If it worked, he liked it.  How you did it was left up to you as a worker.  He felt that people should be motivated by their paychecks, and not need to be baby-sat all the time.  He also cursed like a trucker, which I can relate to.
    2. For the most part, the group that I worked in had very intelligent and humorous members.  Fun to work with, highly skilled.
    3. Though I only worked tangentially with a number of them, I got to meet a number of highly skilled people.  The DBA team was awesome.  One other developer in particular was one of the best I've ever had the opportunity to work with, even though we only officially worked together a day or two, as he was on another team.  I learned a tremendous amount from him, annoying him about development practices and much inane bullshit.  Even if he didn't grasp the worth and integrity of Canadian bacon.


Things to focus on for the new contract:

  1. Listen
    1. Figure out who the important players are.  Figure out exactly what you are expected to do.  If the gig is a bad one, there's not much you can do, but if it is a good one, as I expect, you will find a sweet spot where you can provide high quality services.
  2. Learn
    1. Never under estimate the ability to learn from others.  I'm smart, arrogant, opinionated, and all that, but begin receptive to highly skilled co-workers and how they do things is one of the best ways to grow as a developer/architect/person.  I think I'm good at a number of things, but except for a few things, I *know* I'm not as good as others.
  3. Remember, it's a contract
    1. Provide the client what they want, guiding them where you think they should go, but remember, it is their business.
posted @ Tuesday, July 17, 2007 7:17 PM | Feedback (2)
Driving Pet Peeves

So, for my vacation, I drove from Chicago to Miami.  Then from Miami to New Orleans.  Then Miami to Atlanta.  Then back to Chicago.

I like long drives, sue me.

Most of these are related to the fact that I have a car that, being built in the last 10 years, has cruise control.  Apparently, I'm one of the few.  There are other complaints one could make, involving the use of cell phones, but I'll leave those out.

  • The 'Semi driver that has to pass other semis, at 1 mph faster than the other semis' semi driver
    • I know someone who was a semi driver as a professional, and I respect them.  I really do.  But there is this class of semi drivers that decide that they absolutely have to be in front of 2-5 other semis in front of them.  Fine.  I also respect that semis do not have the responsiveness of a car.  Fine.  But, if you are going to pass someone, do it at more than 1 mph faster than the people you are passing.  Seriously.  If it takes you 3 minutes to move up a couple of hundred yards, blocking traffic the entire time, reconsider.  Please.
  • The 'I need to get past you right now, but I don't know why' driver
    • As someone that uses cruise control, I keep a constant speed.  If things go well, you can set a speed and keep it for long stretches of time.  You recognize those drivers that are slower than you or faster than you.  It's all good.  Then you get these drivers that seem to need to get past you as if they were going to a local hospital.  Fine.  Then they get past you and immediately slow down to slower than what you are driving at.  Figure it out.
    • These drivers don't seem to understand this.  They drive up to your bumper at significant speeds, then once they get past you (which you let them do), they drop down to a speed slower than what you are driving at, inevitably causing you to pass them, which seems to annoy them, causing them to speed up again to get past you. 
  • The 'I love your rear bumper' driver
    • These are the drivers I really don't like.  They can get up to you on the left side, or the right side.  In any event, they insist on preventing you from moving through traffic because they insist on sitting right on your rear bumper, so that you can't change lanes, can't pass other cars, can't do anything really.  Again, pass me, let me pass you, but make a move one way or the other that doesn't threaten a crash.
  • The 'traffic blocking duo' drivers
    • This happens in one of two situations, and it only works on two-lane highways. 
    • The first involves a police car driving right at the speed limit.  No one wants to zoom past a sheriff's vehicle on a highway, but normally they drive a little faster than the posted limit, so that there is some flow of traffic.  Not in this case.  Traffic backs up like the starting grid for a NASCAR race as everyone waits for the police car to take an exit.
    • In this case, two drivers, for reasons unknown to anyone, decide that they want to drive at the exact same speed, right next to each other, no matter how many cars are backed up behind them.  The worst case I was ever in lasted at least 10 minutes like this, to the point that people starting driving on the shoulder around the duo, and they still wouldn't stop blocking traffic.  Once one of them finally relented so that traffic could move, I pulled up next to one of the guys driving a moving van.  He looked like he hadn't slept in 24 hours (or was otherwise out of it), so that probably explained some of it.
posted @ Sunday, July 15, 2007 7:00 PM | Feedback (0)
My Favorite Songs of over 10 minutes in length

This is an odd list.  Fine.  My list of my favorite songs of over 10 minutes in length, ranked in rough order of preference, with comments if I care to include them, listed as Artist - Song Title - Album - Length:

  • King Crimson - Starless - Red - 12:16
    • My favorite song of all time, it is simultaneously harsh and beautiful.  Plus, I have this mental image of Robert Fripp, the guitarist, going to the rest of the band and saying "Okay, I'm going to play this staccato monotonous pattern for the next 6 minutes, play something over it."
  • Porcupine Tree - Anesthetize - Fear of A Blank Planet - 17:43
    • A brilliant song, with multiple 'movements' including an end that echoes Echoes.
  • Porcupine Tree - Arriving Somewhere But Not Here - Deadwing - 12:02
    • The lyrics don't quite make sense (the album is based on some screenplay treatment, I gather), but the energy of the song is tremendous.
  • Jimi Hendrix - Voodoo Chile - Electric Ladyland - 15:00
    • Truly an all-time classic, with Steve Winwood on organ.  Sure, the lyrics make little to no sense, and you can argue that he doesn't play note for note as fast as Eddie Van Halen or whatnot, but the song is brilliant.
  • Marillion - The Invisible Man - Marbles - 13:37
    • Apparently, there is some connection with this song to Iraq or whatever (I try not to let politics ruin good music), this works really well as a love song, especially as Hogarth's voice breaks in the final verses.
  • Pink Floyd - Echoes - Echoes - 23:27
    • At various points, the song mimics whale song.  You would think this was bad, it isn't. 
  • Arlo Guthrie - Alice's Restaurant Massacre - Alice's Restaurant - 18:01
    • One of the all-time classics.  "Kill...kill...", enough said.
  • Marillion - Ocean Cloud - Marbles - 17:58
    • Based on the life of a man who crossed the Atlantic multiple times by himself in a row boat (or something like that).  You would think this is bad, it isn't.
  • Peter Frampton - Do you feel like we do? - Peter Frampton Comes Alive - 13:47
    • The ultimate use of the talk box, and a great live release.
  • Frankie Goes To Hollywood - Welcome to the Pleasure Dome - Welcome to the Pleasure Dome - 13:39
    • One of the oddest bands of all time.  But this really works well.
  • Pink Floyd - Shine On You Crazy Diamond - Wish You Were Here - 13:30
    • Their ode to Syd Barrett, after his descent into madness.
  • Marillion - Neverland - Marbles - 12:10
    • In retrospect (given Hogarth's recent divorce), a bit depressing, but the lyric "I want to be someone who someone would want to be" and how he gets that from his wife is poignant.
  • Yes - Heart of the Sunrise - Fragile - 11:32
    • I have this perverse like of songs that take a few minutes to get to the opening lyrics.  This one kicks in somewhere past the 3 minute mark.
  • Genesis - Home By The Sea (Part 1 and 2) - Genesis - 11:12
    • A bit of a cheat, I guess, since it is really two songs, but I consider them one unit.
  • King Crimson - Islands - Islands - 11:54
    • Very un-King Crimson like.  Quiet, reserved, 'majestic' (for lack of a better word).
  • 3 - Amaze Disgrace - Wake Pig - 16:24
    • They were the opening band on the recent Porcupine Tree tour, and this was the song they closed with.  An interesting song, with a one minute break in the middle, drum/percussion solo towards the end.
posted @ Sunday, July 15, 2007 5:47 PM | Feedback (0)
Back On

One thing to keep in mind when you are self-hosting a site, if you go on vacation, and the power goes out in your building, the server isn't going to come back up.

Anyone have a good .NET hosting provider?  Should move this sucker.

As I prepare to start a new contract, I want to get a retrospective up on the last one this weekend.

Plus, pet peeves about driving long distances.

And, my favorite songs of over 10 minutes in length, as they are a good friend on a long drive.

posted @ Thursday, July 12, 2007 11:42 PM | Feedback (0)
Crushes I'm Personally Embarrassed About, #2

Allie Lewis, of Everyday Food.

Yeah, go ahead and brown that chicken cutlet, you little vix.....what?  Oh, sorry.

posted @ Tuesday, July 03, 2007 7:10 PM | Feedback (0)
Gosh, it's warm down here

Think the high is supposed to be 96 here in South Beach.  Only sporadic postings (if any, really) for the next two weeks as I take a well deserved vacation.  Bahamas in a couple of days.

Of course, it hasn't rained here in quite some time so it will rain every day.  But that means heavy showers for an hour and then gone.

Interesting to see what's changed in the 10 years since I've been here.

One thing remains is still the land of the beautiful people.  Yowza.

posted @ Tuesday, July 03, 2007 9:01 AM | Feedback (0)