(this post is more a note to my future self than anything else)
The WP Super Cache plugin for WordPress is a pretty awesome plugin. The other day I was having problems with it not doing any caching and spitting out the following just before the head tag (where the wp_head() call is):
<!-- Page not cached by WP Super Cache. No closing HTML tag. Check your theme. -->
This was very odd. Everything I could find on the web regarding this problem was seeing this tag at the end of the html. Eventually I found a post that sounded similar to mine (and of course now I cannot find it again, unfortunately). It mentioned a plug-in using output buffering incorrectly. This makes sense, as looking in the source code of WP Super Cache, it outputs the message above in its output buffer handler if it cannot find a </html> closing tag. Needless to say, after a couple of hours fiddling, it turns out that it was a plug-in that I had written especially for the site, and it was doing exactly what the post mentioned (i.e. it was calling ob_end_flush() without calling ob_start()).
So it was all my fault, and I’ll probably do it in the future, hence this post!
So, note to self: If you see this in the future, check the plug-ins.
If you’re using SQL Server, and you’re inserting records into a table with an auto increment primary key, I suggest you don’t use @@IDENTITY to retrieve the previously inserted Id. Rather use SCOPE_IDENTITY().
The reason for this is that @@IDENTITY gives you the last generated Id in the current session vs. SCOPE_IDENTITY() gives you the last generated Id in the current scope.
The current session includes any triggers that run on the table after the insert. The current scope is just the current stored procedure that you’re in.
We were bitten by this recently. We were using @@IDENTITY when inserted into a table that is replicated. Upon insert the replication trigger was firing, inserting a record somewhere else. @@IDENTITY was giving us the identity of the record the trigger inserted.
Changing the @@IDENTITY to SCOPE_IDENTITY() fixed the problem.
This was even nastier in that by total fluke, the identity was matching a record that already existed, so when we used the retrieved identity to insert into another table, we didn’t violate the foreign key constraint.
I’ve recently finished a new site for a client, and in the process of developing, I uploaded a test site to a web server for the client to review. Since going live with the actual site, I left the test site up and running (in the assumption that its less effort to leave it up than to take it down).
Unfortunately, google managed to find the test site and ranked it higher than the proper site for a couple of the keywords. Not good! Its a simple fix to put in a mod_rewrite redirect rule, but its quite incredible how quickly google managed to find a site that has no incoming links.
I have a feeling that its related to the site map plugin that we’re using for wordpress, I think that it pinged google when we were developing the site, and google happily went along and indexed the site.
So, if you’re developing a site, and put up a test version, make sure that you either take it down when making the site live, or ensure that it redirects to the correct site.
We’re using SQL Compact 3.5 in a smart client desktop application, talking to it with NHibernate and are experiencing performance problems in a couple of places.
In general, we’re very happy with the database, it is most of the time pretty fast, and easy to work with. The fact that it runs within our process also helps, as its easy to install and use. This is especially useful, as we are going to be running on relatively low-spec machines (laptops with 500MB ram).
We are however seeing a performance problem in SELECT statements with multiple joins (> 5).
I was reviewing some code, and noticed a couple of unit tests that had “TODO” comments in them (and no code). The problem is that when running these tests, they were passing. Someone reading the list of tests would assume that the test was testing what it claimed to be testing, when in actual fact its doing nothing.
The first option to avoid this problem is to not actually create test methods until you’re ready to implement them.
I know I like to sometimes lay out a list of tests I want to implement before actually writing them. If you want to do this, then I suggest you create the methods, but ensure that the test is ignored (in nUnit, put an [Ignore] attribute onto the method), or that it fails (in nUnit, Assert.Fail). This is especially important if you’re going to commit to your source control system your partially complete tests.
Doing it this way will ensure that
You don’t forget that you need to implement the test.
That someone doesn’t think that something is being tested when in actual fact it isn’t.