BarneyBlog

Question: When is 7 days ago not 168 hours ago?

Answer: When DST changes during the 7 days, in which case it's either 167 (in the spring) or 169 (in the fall) hours ago.

I've got some graphs that display the current day and a seven days in the past, but the x axis is actually built based on hours (e.g. today's midnight is hour zero, yesterday's noon is hour -12, etc).  I'd done the queries to just extract data from seven days before midnight on, and wondered why my graphs were all screwy this week.  After quite a search, I realized that I was getting seven days, but seven days didn't equal 168 hours, and that the DST change was the reason.

In this specific case, the assumption was actually that every day was exactly 24 hours long, and while that holds true the majority of the time, it's an incorrect statement two days per year.  So watch out.

I'm not really sure what the general solution is if you need to assume a day is of a certain length.  In my case, I just changed the queries to be hour based, so seven days before midnight today is actually being extracted as one AM on 10/24.  Not ideal, obviously, but in my case having exactly 168 hours was more important than 168 hours ago being a midnight.  I suppose the right solution would to have sunday's section of the graph be 1/24th larger than the other days to accoun for the extra hour, and actually display 169 hours.  But the charting engine won't handle that.

To my knowledge, there are two free Eclipse plugins to use Subversion as a team provider: Subclipse and Subversive. I started out with Subclipse, but after Eclipse started crashing a lot when I moved from coding to team tasks, I pulled down Subversive to give it a whirl, hoping it would address the crashes. Which one did I just finish uninstalling, you ask? Read on.

First off, using Subversive didn't resolve the crashing, so it's either the team framework code, or something else (I've a suspicion debug-mode Tomcat instance I've always got running).

By and large, the two plugins were very similar. Minor differences included slightly different ordering of options on the context menu and different icons/labels. A large percentage of the UI, however, is driven by the core team framework, not the individual plugins.

Some of the more significant differences included the ability to create working copy change sets with Subversive, but not Subclipse. That can be quite handy if you're stuck working on two (or more) different things in the same working copy at the same time. Subversive also had a bit more intelligent repository browsing, automatically detecting the "standard by convention" trunk/tags/branches top-level directories and letting you browse them for what they are, rather than just generic directories. For a lot of operations, Subversive seemed noticably faster, but on occasion it would take forever to do the simplest things (like commit a single small file). Finally, Subversive's various dialogs exposed a rather richer feature set, though the vast majority of it is useless to me.

Subclipse, on the other hand, had very consistent performance. It also was much faster to "spin up" when loading a project for the first time and building all it's internal metadata for label decorations and stuff. It also seemed slightly faster on synchronize operations. One rather significant advantage for Subclipse was the merge viewer. While it's not for the faint of heart, it's quite powerful, and on the couple merges I did with Subversive, I felt slighted. One little edge case that I did find, Subclipse will let you connect over SSL to a repository whose SSL cert requires manual confirmation to accept (expired, non-trusted issuer, etc.), while Subversive just said it couldn't connect to the repository without attempting to get that confirmation. Not a huge deal, but I run my repos on a self-signed SSL cert, so I couldn't connect to them with Subversive unless something else (like Subclipse) had already done the confirmation.

So which one did I keep? Subclipse. Subversive's definitely got the potential to scoot by Subclipse in terms of feature set and usability (and will get a big boost if it becomes and official Eclipse project), but at the moment, Subclipse isn't lacking a bit. To be fair, Subversive has targetted a larger feature set and is a younger product, but I'm not considering developer merit, only how well it fits my needs. I know I'll be revisiting this question again next year sometime, and I'm not confident predicting either way.

To this point, I've avoided much participation in the 'duck typing' discussions that seem to have pervaded the CF community for the past months.  But I saw this point on Dooce (which is a non-technical blog that just happened to be accidentally relevant) about it, and had to provide some commentary.

The narrative, while totally divorced from the world of software development, illustrates an interesting facet: what if it's "kind of" a duck?  Obviously Jon (the father) is not Heather (the mother – who is not my wife Heather either).  But does he pass the test in this one scenario?  Yes.  Is he duck enough?  No.

You might be tempted to say "yeah, he's duck enough", based on the narrow confines of this discussion, but I encourage you to not fall into the trap.  If he's duck enough in one scenario, but not duck enough in a different scenario, there's some major inconsistencies.

Back to programming, say you have an object parameter to some method that does a few different things (via delegation, of course) that don't involve a database (so they're not protected by a DB transaction).  The method uses it's argument to initiate the first process without issue.  Same for the second.  But the third errors, because the object isn't duck enough to help with the third process, even though it worked for the first two.

What can you do?  You can enforce formal typechecks where possible (on the CFARGUMENT tag in this case), but other than that, you just have to pray.  But we all know prayer isn't a good tactic for building robust enterprise applications, so we have to very carefully monitor all the places that call the method and ensure they don't pass something that's "kind of" a duck, but that's a PITA.  Or we have to build in a bunch of extra "duck enough" validation at the top of the method to ensure all three parts will succeed, but that leads to greatly increased coupling.  Or we could use some structured exception handling to catch any errors and manually undo the stuff that's already been done (a la a transaction), but hard to accomplish with sending emails or something.

I'm not against duck typing or dynamically typed languages, though I do prefer the statically typed ones in general.  Dynamic typing can grant you flexibility that can massively speed development, but it can also introduce weird loopholes in logic that are very difficult to deal with, because of this "duck enough / not duck enough" scenario.