The headline article in last month’s Communications of the ACM (“Attack of the Killer Microseconds”1) got me thinking. The article was drawing attention to the fact that computations are now happening so fast that we now must now even consider the time it takes data to move from one side of a server warehouse to the other at the speed of light. Multi-threading (a)synchronous programming methodologies need to be re-thought given that the overheads of supporting these methodologies are becoming more of a burden compared to the actual computation work being undertaken.
That is not what got me thinking.
What got me thinking was a point being made that despite our generally held belief that asynchronous models are better performers [click title to read more…]
Adding PKCS10 support for one of my Perl installations turned out to be a bit of a hunt. It seems that that the makefile config is referencing the “crypto” library instead of the Windows equivalent, “eay32”. The clue was early in the installation trace where it said:
Warning (mostly harmless): No library found for -lcrypto
Mostly harmless. Not so. It affects more than just the PKCS10 that I was trying to install. Anything needing the cryptographic API from OpenSSL will be affected. All the suggested fixes for this problem that I could find (in a 10 minute trawl) involve editing the makefile (e.g. this) but there’s a much easier fix. Simply locate the “c/lib” folder in your Strawberry [click title to read more…]
There is a common coding mechanism called a “wrapper”, which attempts to make an existing solution take on some extra characteristics. Just like your overcoat is a wrapper that converts an ordinary human into a human with pockets. And maybe a hood.
Today I battled with a database connection wrapper and eventually observed it being secretly and unexpectedly de-cloaked. To be precise, I was dealing with a javax.sql.Connection wrapper known as a ProxyConnection. In an earlier version of my solution I had a raw (uncloaked) Connection and I used this to create some additional items (ResultSet and Statement) that I needed when interacting with my database. Then I processed the data, and finally I destroyed the Connection. (One should never [click title to read more…]
It was while studying electro-mechanics in Manchester that my late father came across an unusual (though not very flattering) term to describe a “tool at hand”: a Liverpool screwdriver (also known as “a hammer”). It was obviously the opinion of the average Mancunian at that time that their counterpart Liverpudlians would happily use said hammer in lieu of a more specialised tool, which was either praise of their resourcefulness or a veiled reference to ineptitude. Regardless, we’re all aware of the usefulness of a simple tool from time to time.
So it is with routine software development tasks. I’m speaking not of the grand act of implementation in the langue-du-jour, but rather of the supporting cast: compile/build/make, difference checking, version [click title to read more…]
Like many software developers, system designers and other computing specialists, I often find myself facing a new project with far too many implementation options. A quarter of a century ago my options were far more limited, and perhaps as a consequence it was easy to get started. If I needed to directly manipulate the underlying hardware, I’d roll up my sleeves and churn out hundreds of lines of assembly. (OK, so each processor has a different instruction set, memory model, etc., but once you’ve mastered a few, the rest are a piece of cake.) For something high level, C is the best workhorse. Quick and dirty? BASIC. Don’t laugh. Many serious solutions were coded in BASIC, or at least in [click title to read more…]