Some thoughts on Service Oriented Architectures and how for some people the silver bullet du jour is the only tool in their toolbox… Just a bit of a rant really…
Recently, both Rocky Lhotka and Ted Neward have said plenty of interesting things about Service Oriented Architecture (SOA). I’m in complete agreement, SOA is a “good thing” and yet since it’s such an expensive option, in terms of complexity, performance and (potentially) cash, you need to make sure that you know where not to use it.
Sorry about the comment spam whilst I was away. I’ve now installed MT-Blacklist, so hopefully the only offensive rubbish and stupid sales-pitches on this site will be my own…
MT-Blacklist seems pretty good; it cleaned up the mass of spam with one click but then unfortunately failed to block a new piece of crap that was posted this afternoon. Having added one of the offending urls to the blacklist I ran the cleanup again and it removed the offensive comment and automagically added the other urls that the comment contained to the list…
“I’ll bet you that from ten feet away I can tell if a program is bad. I might not guarantee that it is good, but if it looks bad from ten feet, I can guarantee you that it wasn’t written with care. And if it wasn’t written with care, it’s probably not beautiful in the logical sense.”
Charles Simonyi
The quote is from an interview with Charles Simonyi; via Joel’s discussion forum.
I’m reviewing a large body of code for a client at present. It’s a general review of the design, coding style, code correctness and testability of a project. I started off by making notes on some of the general design changes that I’d recommend and eventually got down to a detailed review of the code. There’s a lot to say about the code and, as with all code, sometimes it’s hard to figure out the reason behind the use of a particular construct.
Interesting thread over on Joel today about using const, or not.
The original poster asked how many people bothered to mark function parameters that they don’t modify as const and whether there was any performance or readability advantages in doing so.
Ignore any performance issues, making your code const correct has massive readability and comprehension advantages. I’d go so far as to say it’s one of the most important coding standard issues there is…
I’m currently working with a corporate client. The plan is that I’ll help them refactor a key component in their system and make it more robust and increase performance. Right now they’re in the middle of a release and are in ‘slip mode’. I find myself feeling some sympathy for Cypher from The Matrix; there I was, safe in my green-tinted world of TDD, then suddenly I find myself in “The real world” and it’s nasty and messy and there aren’t any tests.
I’m a great fan of wrapping stuff up with thin layers that make the wrapped code easier to use in a given circumstance, or to provide a more appropriate interface. Obviously there are other reasons to wrap APIs but I’m continually amazed at how often the wrapping fails to add much value.
Take the humble Win32 Event API. It’s a fairly standard C API that uses an opaque handle to allow you to manipulate an event object.
STL containers are great. Rather than have to worry about writing doubly linked lists, efficient maps, and other such data structures you just grab one from the STL and you’re away.
Unfortunately the STL containers have quite a large ‘surface area’. Their interfaces are rich because they are generic containers. Often the container you actually need is much more limited in scope and in such situations I always find it’s worth wrapping the STL container and providing a more appropriate interface to the user.
If you don’t write the code are you doomed to forever be thinking that the abstraction is all in the wrong place?
Another day, another dollar. Starting with a new client, well starting back with an old client, and doing that ‘get your head around the source’ thing…
Today turned into a day for pondering complexity, abstraction and memory management and watching Pirates of The Caribbean on DVD…
I experimented with a version of the buffer allocator that allowed a user defined memory allocation policy. It worked, but it was, I think, unnecessarily complex. If the buffer allocator itself lay behind an interface then that’s enough flexibility. Additional abstraction, with an abstract allocation policy in addition to an abstract allocator seemed a tad too abstract… At some point you have to actually make the decision and write the code that does the work.
