Once—in 1988 to be exact—I, proudly, showed my dad the source code of a program—PAP, Pension Analysys Program, to be exact—that I co-wrote with an actuary. Not being a computer literate at all, my father looked at it with little interest, read part of it nonetheless and than said the most amazing thing to me: “Why are there so many errors?” I was baffled, many errors in my code? Looking at this one line—the one showed above to be exact—it hit me. The code was larded with if … then Error(). I explained to my father that I tried to catch everything that could go wrong at the earliest possible moment and, with appropriate modesty, that it was a sign of quality code. I tried to explain, ignoring my fathers tell tale signs of boredom, that the Error() function would hardly ever be executed in the end product. I told him all about error distributions not being normal and their heavy tails not being exponentially bounded. I thought I lost him there because my father was not a math buff, but a financial-adviser. When I had finally shut up, he proclaimed: “So all you are saying is that you do not ignore unlikely potential problems. Good for you.”
If I hat to pick the one term that causes confusion in code companies, it would be “technology debt.” This metaphor, was coined at least three years ago: “Technology debt is basically when you ‘borrow’ time to avoid having to pay it now – but likely having to pay it later, generally with interest.” (Dharmesh Shah) [Development Short-Cuts Are Not Free] Compared to financial debt, technology debt is less tangible. Some don’t even think the metaphor to be very strong: “unlike real debt there is no external requirement to pay this back.” (Kendall Miller) [Technology Debt?] However I think that Kendall, as many others, is confused. This confusion might be due to the ingrained misconceptions that code mainly has functional-properties, and that each functional-property is implemented as a monolithic block of code. First and foremost, technology debt is mainly about the nonfunctional-properties, like re-usability, maintainability, robustness, security, user-friendliness, (source) controllability, compatibility, extendability, copy-n-past-level, correctness, and so on and on and on. If—as Kendall Miller seems to—one assumes code has mainly functional properties, technological debt translates into limited functionality. Functionality is like taste, “you don’t have to lay an egg to know if it tastes good.” (Pauline Kael) But if you don’t care what the kitchen looks like after making omelets, I want to be your maid nor cook. 
So two functionally-similar blocks of code have a similar technology deficit, so clearly one should pick the cheapest. This assumption gets you a techy techie, because, most every time a techie brings up non-functional technology debt, in what ever form, they are perceived as non-supportive, inflexible, uncommitted or worse. Understanding technology debt is difficult, but important. Misunderstanding it, can be catastrophic.
If you write any, non trivial PHP script, that reads and writes tekst, you will need to get a feel for the magic in PHP. Because at some point, you start to wonder, where all those backslashes come from. Because quotes in text will grow backslashes with every read-write cycle, like this: \\\\\\\\\"Sure!\\\\\\\\\". So you set out to find out what is going on:
int fwrite ( resource $handle , string $string [, int $length ] )
fwrite() writes the contents of string to the file stream pointed to by handle.
handle:
A file system pointer resource that is typically created using fopen().
string:
The string that is to be written.
length:
If the length argument is given, writing will stop after length bytes have been
written or the end of string is reached, whichever comes first.
Looks normal so far, but directly below than it reads:
Note that if the length argument is given, then the magic_quotes_runtime configuration option will be ignored and no slashes will be stripped from string.
But of cause, how stupid of me, clearly if I supply a length argument, I would not want to ignore the slashes (that were added apparently by some other “magic” functionality) and be happy to have them in my file, after all they are magic quotes from the great wizard that was born in Qeqertarsuaq, how could I not want that? Or maybe I am one of those exoteric inclined people that prefer solid design over “magic” kludges? But don’t tell anyone, or the last words I will ever hear are: “Stone him! He is the endoheresiarch!”
Read the rest of this entry
Source: BusinessBalls.com
Read the rest of this entry
source: Wikipedia
stack_t with push(), pop(); Horizontal e.g., queue_t with enqueue(), dequeue(); and Gyved e.g., list_t with putHead(), putTail(), getHead(), getTail(). You should not push down on a queue or dequeue from a stack, that is confusing. This was, however, exactly what happend in the book. It used a standard C++ library template called queue that has push() and pop() methods. To add insult to injury, the authors used the the name stack for their queue object. This made things far worse, because now there was one line of code that turned the whole interpretation 90°. I glossed over the code and started to wonder (wrongfully) why they were using a LIFO stack, turning the example in a depth first traversal. Only after re-reading some text and re-examining the code, did I spot the definition of stack as a queue: “queue<node> stack;.” Note that the C++ queue template uses push() and pop() but any underlying containers have to implement the oxymora push_back() and pop_front(). This was a very clear and short example. Imagine doing something like that in a real-life application.So the lessons learned, again, were to never mix metaphors and to always refactor mixtures in given-code.
Most pro-programmers will know that programs that function well, also need the proper form. That is, if you want users to, well actually use your program. Getting the form right, means tweaking the graphics, the layouts, the speed, the input flow, progress bars, and much, much more. Actually it is almost an art to dress up your code such that it will diffuse. Even if you do everything right, and create a Bauhausian beauty where form and function walk hand in hand with your user, straight into paradise, chances are they still will not adopt it.
Look at Google Chrome. They did a lot right, even the marketing, so after a year, how are they doing?
(graph afterdawn.com)
Most languages have a mechanism to handle failure. For example, ADA has raise…with, C has setjmp(), longjmp(), Python has try:, except:, else:, finally:, and Perl has eval{…die…}. Despite this, a (library) function will often handle failure in an other way: by return-value. This is because failure comes in many guises.
Read the rest of this entry
“The new Quicksort algorithm uses partitioning a source array T[ ] a, where T is primitive type […], to three parts defined by two pivot elements P1 and P2 (and therefore, there are three pointers L, K, G, and left and right […]) shown [below]:
It is proved that for the Dual-Pivot Quicksort the average number of comparisons is 2*n*ln(n), the average number of swaps is 0.8*n*ln(n), whereas classical Quicksort algorithm has 2*n*ln(n) and 1*n*ln(n) respectively.“ (Vladimir Yaroslavskiy) [paper, link, Thanks John.]
“Turing was a quite brilliant mathematician, most famous for his work on breaking the German Enigma codes. It is no exaggeration to say that, without his outstanding contribution, the history of World War Two could well have been very different. He truly was one of those individuals we can point to whose unique contribution helped to turn the tide of war. The debt of gratitude he is owed makes it all the more horrifying, therefore, that he was treated so inhumanely. In 1952, he was convicted of ‘gross indecency’ – in effect, tried for being gay. His sentence – and he was faced with the miserable choice of this or prison – was chemical castration by a series of injections of female hormones. He took his own life just two years later. […] So on behalf of the British government, and all those who live freely thanks to Alan’s work I am very proud to say: we’re sorry, you deserved so much better.“ (Gordon Brown) [link, via DI]
