Here’s what I originally attempted:


function do_something() {
  $.ajax({
    url: 'http://example.com/AjaxRocks',
    type: 'POST',
    dataype: 'json',
    success: success_response
  });
}
function success_response(json) {
  var cookie_data = load_data_from_cookie(); // the implementation of this is not important
  // unfortunately, cookie_data is null so this doesn't really give us the important cookie_data
}


For some reason, the full contents of document.cookie are not available from inside the success_response function call. The solution? Load the cookie’d data before making the AJAX call:


function do_something() {
  var cookie_data = load_data_from_cookie();
  $.ajax({
    url: 'http://example.com/AjaxRocks',
    type: 'POST',
    dataype: 'json',
    success: function(json) {
      success_response(json, cookie_data);
    }
  });
}
function success_response(json, cookie_data) {
  // do something successful
}


Back story: we are using jQuery’s superfish drop down menus (a jQuery based implement of suckerfish/son of suckerfish) for site navigation. Everything works great in Firefox 2/3 and Safari. I’m going to assume that IE6 looks great as well since suckerfish is known to work well in IE6.

IE7 is a different story.

There is a large image directly beneath the navigation menu. Unfortunately for me, in IE7 the menu was being rendered beneath the image, despite having a z-index of 1001.

After some careful (and careless) digging and googling, I came across a solution.

To summarize, IE7 will not render the menu with the appropriate z-index unless that z-index is present on the top level :hover style. To clarify:


/*** ESSENTIAL STYLES ***/
.sf-menu, .sf-menu * {
margin: 0;
padding: 0;
list-style: none;
}
.sf-menu {
line-height: 1.0;
}
.sf-menu ul {
position: absolute;
top: -999em;
}
.sf-menu li:hover {
z-index: 100; /* This is the important style directive, without it IE7 chokes */
}
.sf-menu * li:hover {
visibility: inherit; /* fixes IE7 'sticky bug' */
font-weight: bold;
}


IE7 Suckerfish Hover CSS

Let’s say that some careless developer (me) forgot to close an XML tag. The aforementioned developer then checked in his build file and attempted to build it.

At this point, I got a bit worried because TFS came back with the following error:

TF42046: The build service used in the build process is not reachable. This error occurs when either the build machine is off-line,the required service is not running, Team Build is not installed on the build machine, Team Build is configured for a different Team Foundation Server or the network is not available.

So, at this point I spent a few minutes attempting to debug this problem. It turns out that this problem can also be caused by silly developers leaving off closing XML tags in their hurry to finish the weekly build script.

Why would Visual Studio throw back this seemingly unhelpful message? Probably because my XML was garbage and TFS simply refused to talk to me on the grounds that I am uncouth and trying to shout the XML equivalent of dirty words at it.

Moral of the story: close your XML tags and don’t hurry.

[edit]
Rick has informed me that I am a horrible developer and forgot to mention his involvement in this whole issue. So, Rick, thanks for helping me troubleshoot this problem. Read his blog, it’s at RickDoes.net. Did you notice that URL? He’s witty, much wittier than I.

Rather than summarize, I’ve just provided a link. It’s short, sweet, to the point, and full of screen shots.

How old were you when you started programming?
I originally started learning BASIC when I was very young, probably 11 or so. I gave up on programming for more worldly pursuits, only to come back to it 10 years later.

How did you get started in programming?
The second time around I wanted to create a ‘blog’, although at the time I don’t think we called them blogs. I think we called them e/n sites (everything/nothing). So I taught myself HTML.

What was your first language?
HTML, CSS, and Perl. It was a triple whammy.

What was the first real program you wrote?
The first real business program I wrote was a socket server written in PERL that accepted a rudimentary home grown protocol. It was used to remotely monitor the health of 8 different servers. What can I say, I started out as an HP-UX sysadmin.

What languages have you used since you started programming?
HTML, CSS, JavaScript, C#, VB.NET, ASP.NET, PERL, Python, Ruby, SQL (T-SQL, PL/SQL, PL/PGSQL), PowerShell, BASH scripts, SVG, XPath, XQuery, XSLT, ActionScript. Jack of all trades, master of none.

What was your first professional programming gig?
I worked at Qwest Communications writing unimpressive PERL scripts to automate keeping an Actuate Reporting Server running without too many memory leaks. I graduated to doing the same thing for Local Number Portability software. If you don’t know what LNP is, just think of it this way: it’s the reason your calls go through and the reason you can change carriers and keep the same number.

If you knew then what you know now, would you have started programming?
I might have kept with it when I was younger. Although, frankly, I think a good part of my approach and expertise come from my lack of formal training and my background in the Humanities. Getting a four year degree in CS would have probably proved impossible for me. However, that BA in English has taught me a great deal about the importance of communication, documentation, and solid presentational skills.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Communication is key. This stretches across every aspect of what we do on a daily basis. If you can’t communicate your ideas clearly and succinctly, the boss is never going to push for your pet project. If you can’t describe a problem well to non-technical people, they will never understand the importance of the issue. If you can’t share your failures and successes with fellow developers, someone will end up repeating your mistakes. Communicating is how we all learn. If people didn’t feel the urge to share their knowledge and write books, we would still be building Altair clones in our basements from Radio Shack kits.

What’s the most fun you’ve ever had … programming?
Frankly, every day is fun. I get to share knowledge with some exceptionally talented developers and I’m always learning from them. The best times are when I get to work with a dynamic team of people and build on each others ideas to make the best software we can.

I’ve often heard many DBAs make the claim that doing a date comparison is faster than checking if the value in a date column IS NULL, so I decided to run some primitive benchmarks to see what I would discover. Admittedly, I’ve also held this belief myself, but I’ve never witnessed any numbers to either prove or disprove the theory.

First, I created two tables with two columns each - CreatedAt and DeletedAt. One table allows NULLs in the DeletedAt column, the other does not.

Next I filled each table with 1,000,000 random DATETIME values. Each table recieved the exact same DATETIME values in each row and a random number seed was used to determine whether or not the NULL table would have a NULL value or a random DeletedAt value. In my test case, 500843 records had a NULL value. I then ran three separate queries to compare the performance of IS NULL against . Before and after each query, the current time was stored in a variable which was manipulated using a millisecond DATEDIFF to determine the total execution time.

1. -- turn off printing row counts to speed up processing
2. SET NOCOUNT ON;
3.  
4. -- Create test tables
5. IF OBJECT_ID('Benchmarking.dbo.TestNullDatetime', 'U') IS NULL
6. BEGIN
7. CREATE TABLE TestNullDatetime
8. (
9. CreatedAt DATETIME NOT NULL,
10. DeletedAt DATETIME
11. );
12. END;
13.  
14. IF OBJECT_ID('Benchmarking.dbo.TestNotNulLDatetime', 'U') IS NULL
15. BEGIN
16. CREATE TABLE TestNotNullDateTime
17. (
18. CreatedAt DATETIME NOT NULL,
19. DeletedAt DATETIME NOT NULL
20. );
21. END;
22.  
23. DECLARE @counter INT;
24. DECLARE @random FLOAT;
25. DECLARE @threshold FLOAT;
26. DECLARE @current DATETIME;
27. DECLARE @deleted DATETIME;
28.  
29. SET @threshold = 0.5;
30. SET @counter = 0;
31.  
32. WHILE @counter < 1000000
33. BEGIN
34. SET @random = RAND();
35. SET @current = GETDATE();
36. SET @deleted = @current + (@random * 9.5);
37.  
38.  
39. IF @random > @threshold
40. BEGIN
41. INSERT INTO TestNullDatetime VALUES (@current, NULL);
42. INSERT INTO TestNotNullDatetime VALUES (@current, @current);
43. END
44. ELSE
45. BEGIN
46. INSERT INTO TestNullDatetime VALUES (@current, @deleted);
47. INSERT INTO TestNotNullDatetime VALUES (@current, @deleted);
48. END
49.  
50. SET @counter = @counter + 1;
51. END
52.  
53.  
54.  
55. DECLARE @start DATETIME;
56. DECLARE @end DATETIME
57.  
58. DECLARE @null_isnullcompare INTEGER;
59. DECLARE @null_notequalcompare INTEGER;
60. DECLARE @notnull_notequalcompare INTEGER;
61.  
62. SET @start = GETDATE();
63. SELECT * FROM TestNullDatetime WHERE DeletedAt IS NOT NULL;
64. SET @end = GETDATE();
65.  
66. SET @null_isnullcompare = DATEDIFF(ms, @start, @end);
67.  
68. SET @start = GETDATE();
69. SELECT * FROM TestNullDatetime WHERE DeletedAt <> CreatedAt;
70. SET @end = GETDATE();
71.  
72. SET @null_notequalcompare = DATEDIFF(ms, @start, @end);
73.  
74. SET @start = GETDATE();
75. SELECT * FROM TestNotNullDatetime WHERE DeletedAt <> CreatedAt;
76. SET @end = GETDATE();
77.  
78. SET @notnull_notequalcompare = DATEDIFF(ms, @start, @end);
79.  
80. SELECT @null_isnullcompare AS [NULL - IS NULL comparison],
81. @null_notequalcompare AS [NULL - NOT EQUAL comparison],
82. @notnull_notequalcompare AS [NOT NULL - NOT EQUAL comparison];
83.  
84.  
85. -- restore original state
86. SET NOCOUNT OFF;
87. Download this code: benchmarking.sql

The results are as follows:

Overall, the <> comparison is faster than an IS NULL comparison, and it is approximately 100 milliseconds faster to perform on a table with no NULLs than on a table with roughly 50% NULL values.

Of course, it’s important to take note these are all hot cache hits. I didn’t take the time to reboot my machine and determine the difference running this against a cold cache, however I suspect that the results would still be the same.

Testing was performed on a 2.0 GHz Core 2 Duo laptop running Windows XP SP2, SQL Server 2005 Developer Edition (patch level 9.0.3054), with 2 GB of RAM and 7200 RPM drives. It’s an HP Pavilion dv9000t, for those who are interested.

You’d be hard pressed to get me to concede that a data access scheme based on stored procedures is a bad idea. In the absence of that, buy a good ORM tool.

I’m going to take a stab and responding to each of your points because I think it’s good to get a dialog going on these kinds of things.

Pain Point the First: Version Management
I’m not sure what you mean by this. It’s fairly trivial to version control SQL files, however I’m guessing that you aren’t having any difficulty with adding plain text files to version control. So, I’m going to make a guess and say that this has something to do with quickly determining which version of development code is in the database. This can be somewhat tricky. It becomes necessary to use some kind of build/migration system similar to the one used in Ruby on Rails where you have a schema_info table with a version column that is incremented or decremented by an automated tool. At this point, a high level of DBA discipline is required to prevent changes from being made in production that are not present in source control and vice versa.

Pain Point the Second: Two Code Bases
Again, I’m not sure what is meant by this. You’re absolutely right, maintaining stored procedures does require two skill sets. In an ideal world there would be a distinct separation of skills between database and application developers. While basic to intermediate SQL can be handled by most developers, venturing into high performance/advanced SQL requires a distinct skill set that requires years of experience and conscious practice.

Pain Point the Third: Business Logic
I’ve said this a large number of times over my career as both an application developer and database developer: business logic does not belong in the database. By default T-SQL will compile and store the first execution path it encounters in a stored proc. Let’s say you have a procedure with two branches, one performs a simple insert and the other performs a complex operation that can benefit from a compiled execution plan. If the simple insert statement branch is the first branch to be executed, it will be compiled and the other, complex, path with be performed as an ad hoc query unless the stored proc is ALTERed and the second execution path is executed. If you need complex logic and you have SQL 2005, you can use CLR stored procedures.

Pain Point the Fourth: Testing Stored Procedures
While I’m definitely not an expert on the subject of testing stored procedures, I have read numerous resources on the subject of testing stored procedures. Adam Machanic devotes some time to it in Expert SQL Server Programming. I’ll leave this topic to the experts.

Pain Point the Fifth: Writing Trivial SQL
When you’re operating, or attempting to operate, a high performance, high access database, there are no trivial data access calls. Granted, for the majority of data access scenarios (SELECT a, b, c FROM xyz WHERE param = @param), a stored procedure could be described as development overhead. This is a point that we agree on. However, I see the point that many DBAs have - if they want to change the underlying schema for performance/storage considerations, they should be able to do so as long as they provide developers with the same set of outputs as before, given the same inputs of course.

Pain Point the Sixth: Stored Procedures aren’t Dynamic
Nor should they ever be. The point of a stored procedure is to access data as efficiently as possible. In the event that you have multiple potential join combinations, you will need multiple stored procedures. Not to sound insulting, but the demand for multiple potential join combinations sounds like, to me, a poorly planned data access scenario. There are ways to dynamically generate WHERE and ORDER BY clauses using T-SQL and parameterized procedures/queries.

Ultimately, of course, the purpose of a stored procedure is to increase performance, granularity of data access, and provide an additional layer of security on top of the data. A data access solution based around stored procedures isn’t for every one, but it’s always good to know the reasons why you should be using it.

John Lam on Vibrant Ink
and
Dark Visual Studio
almost forgot
Scott Hanselman’s slightly more manual instructions

Now, either one of these will attempt to set your layout to the author’s favorite settings which, frankly, are not my favorite settings. Make sure to uncheck at least the following items, if you want your Visual Studio layout to stay the same:

• Work Item Tracking - View Settings
• Visual Studio Team Foundation Server
• General Settings -> Window Layouts
• General Settings -> Toolbox
• General Settings -> Menu and Command Bar Customizations

Any other suggestions for keeping as much of your preferred layout around are greatly appreciated.

me

But, seriously, PostgreSQL has the best documentation of any FOSS database I’ve used (I’m looking at you MySQL). Combined with its ability to handle just about anything I throw at it in a timely manner, PostgreSQL is impressing me more and more. I just need to figure out how to get plpgsql working in my normal queries instead of in functions… or else I need to give up and start writing all of my ETL scripts as functions (which seems somewhat expensive).

Anyways, The Rise and Fall of the Amateur New York Subway Riding Committee.

I found this think through anarchaia, so I can’t take any credit for finding it. But I can take credit for pronouncing it to be awesome