Writing for Untestability. · 29 July, 08:36 AM
via Steve Loughran, How to Write 3v1L Untestable Code on the Google Testing blog. The “Use Global Flags” rule cracked me up, except that my variation on the rule for .NET would be “Use appSettings liberallly”. It’s another reason to dislike appSettings, except that it’s more evil, because a simple “find references” won’t reveal it the way it’ll reveal global flags. So to generalize, the rule is “Depend on configuration for everything”, because the alternative, to use configuration objects and pass those in as initial state, requires a little more work but yields more testable code – particularly in .NET where the app.config is tied to the AppDomain. The “Depend on Large Context Objects” is along the same lines rings totally true for anybody who’s had to deal with anything around System.Web.
But Steve’s absolutely correct about the “Use Utils Classes” and “Use statics” rules – the reasons those smells show up in every project is because of sealed, final and their ilk. Except that I’m sure there’s a Ruby / Python version of this floating around that has a rule like “Override low-level methods of object whenever the opportunity arises”.
— Gordon Weakliem
That Sound You Heard... · 25 July, 02:07 PM
Brad Feld pointed at the article Oily Speculations as a way of bashing the current fad of blaming speculators for oil prices. It’s an interesting article with the key point that while certain commodity markets have seen manipulation in the past, oil currently isn’t showing any evidence of manipulation. Anti-speculation legislation is right up there in the legion of Bad Ideas, along with “Gas Tax Holidays”, which isn’t a position that sells especially well, but unfortunately in these cases, allowing the market to do its thing beats ill-considered manipulations.
One of my co-workers forwarded around the Open Letter to All Airline Customers which I found highly ironic, considering that it was signed by a number of airlines which have famously profited by hedging fuel prices; notably Delta in the late 90’s and in the last year, Southwest, which supposedly locked in large fuel purchases at $50/barrel. That’s right: these airlines were speculating in the futures markets, and somebody took the bad side of that trade. That’s right, some poor slob (or very likely, a large number of poor slobs) are paying for that $100/barrel difference in oil prices that Southwest and its customers have been enjoying.
That sound you heard is the world’s smallest violin playing for the airline CEO’s who now want to put the genie back in the bottle, at least until the public isn’t paying attention and they can go back to speculating in private, like true gentlemen.
— Gordon Weakliem
A Tale of Two Regexps · 25 July, 02:06 PM
It seems that in .NET 3.5, the static methods on the Regex class will use cached versions of compiled regular expressions. According to the .NET 3.5 Documentation for the System.Text.Regex class:
The Regex class contains several static (or Shared in Visual Basic) methods that allow you to use a regular expression without explicitly creating a Regex object. In the .NET Framework version 2.0, regular expressions compiled from static method calls are cached, whereas regular expressions compiled from instance method calls are not cached. By default, the regular expression engine caches the 15 most recently used static regular expressions. As a result, in applications that rely extensively on a fixed set of regular expressions to extract, modify, or validate text, you may prefer to call these static methods rather than their corresponding instance methods.
I immediately flagged this tidbit, not because it had anything to do with the problem I was trying to solve, but because, in fine Regex tradition, it seems that using a Regex might create two problems: now I have to worry about caching. It seems like one of those solutions to a problem that I may not even have; and on top of that, now I have to worry about usage of the static methods on Regex by callers other than my code: code written by other team members, code in other libraries, code in the .NET Framework itself. The thing is, this caching policy is on such a small scale that it works for only the smallest applications and in order to tune it, you need to do the same thing that you’d have to do to fix performance issues in the first place: profile and audit the code to find the problem. My inclination is to avoid the static methods altogether, which is probably not the intended effect.
This kind of thing crops up in the .NET Framework a few other places; most notably the ServicePointManager – you simply can’t create IP connections without going through ServicePointManager, but that introduces its own complications and behaviors that in some instances, you need to go to extreme lengths to code around, since all these classes invariably involve some combination of private, internal, or sealed classes. I was reading the documentation on Edi Weitz’ Regex Coach which states “It might be worthwhile to note that due to the dynamic nature of Lisp The Regex Coach could be written without changing a single line of code in the CL-PPCRE engine itself although the application has to track information and query the engine while the regular expressions is parsed and the scanners are built. All this could be done ‘after the fact’ by using facilities like defadvice and :around methods.” Edi’s comparing with Perl, but the situation’s the same in .NET – if you don’t like the way the default libraries work, well, that’s tough.
— Gordon Weakliem
Is EC2 a Spam Platform? · 15 July, 03:20 PM
I ran into a few comments on my weblog that caught my eye – mainly because 2 of the comments came from the same IP, but were apparently left by different people. Normally, I don’t spend much time thinking about comment spam, but this has some interesting features: the source of the comments resolves to ec2-67-202-49-217.compute-1.amazonaws.com. So it appears that an EC2 server was the source of the comments, which is odd because EC2 isn’t an interactive system – why am I getting comments from there. So, theories:
- Some legitimate comment service is using EC2 to post to weblogs. I don’t think that’s likely because I haven’t gotten other referrers for those posts.
- A comment spammer has decided EC2 is a good platform for spam.
The comments aren’t egregious spam, but they didn’t really add anything to the post – they’re relevant to the content but ultimately just “thanks for posting this”. The comments are signed with a real name, with an email address in the form fistnamelastname@yahoo.com or gmail.com along with a URL in the form http://firstnamelastname.com
13 Jul 2008 20:28:46 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 20:28:22 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 20:28:05 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 20:28:02 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 20:26:59 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 20:26:58 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58 13 Jul 2008 20:26:47 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58 13 Jul 2008 20:25:31 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58
13 Jul 2008 16:30:52 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58 13 Jul 2008 16:30:52 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58/?commented=1 13 Jul 2008 16:27:21 67.202.49.217 ec2-67-202-49-217.compute-1.amazonaws.com weblog/article/58
13 Jul 2008 13:44:16 75.101.208.78 ec2-75-101-208-78.compute-1.amazonaws.com weblog/article/54 13 Jul 2008 13:44:16 75.101.208.78 ec2-75-101-208-78.compute-1.amazonaws.com weblog/article/54/?commented=1 13 Jul 2008 13:44:01 75.101.208.78 ec2-75-101-208-78.compute-1.amazonaws.com weblog/article/54
— Gordon Weakliem
Comment [2]
Money for Nothing and Interop for Free · 14 July, 12:16 PM
Giving Shit Away is not a Business Strategy – Ref Smart companies try to commoditize their products’ complements.. On the flip side, dumb companies give stuff away and make it up in volume.
Ted Neward on Protocol Buffers – ref Mark Pilgrim’s post on PB. It’s a case of someone who’s looking at a spec versus someone who’s used the implementation. I’d tend to defer to Mark. In a case of cognitive disconnect where you run into something that you wouldn’t think would work, versus seeing evidence that maybe it does, my instinct lately is to wonder why my instincts are apparently wrong. Let’s think about a few of Ted’s points:
- “Protocol Buffers’ claim to be language and/or platform-neutral is hardly justifiable, given that they have zero support for the .NET platform out of the box”. So Google does little or no work in .NET, is this their problem? I think Ted misunderstands what open source/open spec actually means.
- “until we see implementations of Protocol Buffers for Perl/Parrot, C, D, .NET, Ruby, JavaScript, mainframes and others, PBs will have to take second-place status behind XML in terms of “reach”“. But there are some well documented examples where the parsing situation is poor for a given language: REXml in Ruby, for instance.
- “In XML we can follow Noah Mendelsohn’s advice of years ago (“Schema are relative”) and parse XML in whatever manner suits the consumer, with or without schema” – which works in situations where partial understanding is acceptable. It’s one of those great straw man questions: would you want your bank to make assumptions about your input? I think it’s irritating that my bank requires me to specify cents in my payment amount in the online bill pay service, but on the other hand, it’s better force me to be explicit than assume I really meant to append a decimal point and two zeroes to my payment amount.
I think that what’s probably the case here is that protocol buffers reflect the culture they grew up in, which is to say they reflect Google’s culture, whereas XML grew up from the markup world that inherently has different concerns. Ted’s point about the “One True Schema” misses the larger point that interop doesn’t come for free. It’s nice to have the freedom to not have to have to negotiate with the other side of the wire, but that comes with its own tradeoffs.
Dare covers a lot of the same ground in Scalability: I Don’t Think That Word Means What You Think It Does, saying “If a service doesn’t scale it is more likely due to bad design than to technology choice.” I’d counterpoint that with the note that technologies often have defaults that lend to failure: for example, DOM in XML or ASP.NET’s postbacks and ViewState, or the simple-minded nature of PHP leading to sites tightly coupled with a relational DB.
— Gordon Weakliem
Comment [2]