CodeBlab

“Mobius is an invite-only event, hosted by Microsoft, where the invited guests are shown what Microsoft is doing in the mobile space.“ [Mobius 2009] Guess what most of these creme-de-la-creme Microsoft mobile developers (and journalists) use as their weapon of choice? [via: DI]

Banks play a pivotal role in the finance system, they perform a kind of miracle, they make short money long. Come to think of it, most companies, not just banks, perform such miracles. Companies, make long visions short. Management takes the long term goals of a company and by ways of a miracle translates them into short term goals for the people that actually do the work. So, wonder no more, that is what management is good for … in theory. In practice management often emits quick and dirty shorts that do not sum into coherent longs. With most tech-companies, this is even more difficult to spot because a manager, feeling the lack of effort behind their decision, will effort-up the decision by trying to express it in quasi tech-terms.

So next time, you go WTF? Just ask them two things. First, why are you telling me how-to-do instead of what-to-do? And second, what long term goal does this serve?

With countless new languages hitting the scene, it is refreshing to find one that clearly states its domain (systems programming) and a realistic set of goals. Leave it to Google to roundup some smart and experienced people, to create this new language, they dubbed Go (mainly because “Ogle” would be a good name for a Go debugger).

“Go was born out of frustration with existing languages […] One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language. Programmers who could were choosing ease over safety and efficiency by moving to dynamically typed languages such as Python […] Go is an attempt to combine the ease of programming […] and safety […] with support for networked and multicore computing […] it is intended to be fast” [Language Design FAQ]

Obligatory “Hello World” example:

“The following gdb script will handle this:

#
# Trace objective-c messages. - nemo 2009
#
b dyld_stub_objc_msgSend
commands 
        set $id  = *(long *)($esp+4)
        set $sel = *(long *)($esp+8)
        if(*(long *)($id+8) != 0)
                printf "[%s %s]\n", *(long *)($id+8),$sel
                continue
        end
        set $isx = *(long *)($id)
        printf "[%s %s]\n", *(long *)($isx+8),$sel
        continue
end

We could also implement this with dtrace on Mac OS X quite easily.

#!/usr/sbin/dtrace -qs
/* usage: objcdump.d  */
pid$1::objc_msgSend:entry
{
    self->isa = *(long *)copyin(arg0,4);
    printf("-[%s %s]\n", 
        copyinstr(*(long *)copyin(self->isa + 8, 4)),
        copyinstr(arg1));
}

Let me correct myself on that, we /should/ be able to implement this with
dtrace on Mac OS X quite easily. However, dtrace is kind of like looking at
a beautiful painting through a kids kaleidescope toy.” (nemo) [The Objective-C Runtime: Understanding and Abusing]

If you are only interested in the above text you are a halfling, if you just hit the link to RTFA, you are a nerd, if you think you could write the article, you are a script-kiddy, and if you go WFT, you are a n00b. But if you do read it, you might learn some new debugging techniques.

“File-level deduplication has the lowest processing overhead but is the least efficient method. Block-level dedupe requires more processing power, and is said to be good for virtual machine images. Byte-range dedupe uses the most processing power and is ideal for small pieces of data that may be replicated and are not block-aligned, such as e-mail attachments. […] ZFS provides block-level deduplication, using SHA256 hashing, and it maps naturally to ZFS’s 256-bit block checksums. The deduplication is done inline […]” (Chris Mellor) [ZFS gets inline dedupe]

“Good for virtual machine images.” I’d like to nominate this remark for the understatement of the year contest. Note it would also be great for vectorized OLAP. Also note that compression engines like LZW use “byte-range dedupe” on a data stream. … Implementing byte-range dedupe on a random access system won’t be easy. … Besides performance might suffer, if the contents of every block is expressed in terms of other blocks. … Probably a dynamic dictionary is worth a try. … Somebody stop me!

with x( s, ind ) as
( select sud, instr( sud, ' ' )
  from ( select 
  '53  7    6  195    98    6 8   6   34  8 3  17   2   6 6    28    419  5    8  79'
  sud from dual )
  union all
  select substr( s, 1, ind - 1 ) || z || substr( s, ind + 1 )
       , instr( s, ' ', ind + 1 )
  from x
     , ( select to_char( rownum ) z
         from dual
         connect by rownum <= 9
       ) z
  where ind > 0
  and not exists ( select null
                   from ( select rownum lp
                          from dual
                          connect by rownum <= 9
                        )
                   where z = substr( s, trunc( ( ind - 1 ) / 9 ) * 9 + lp, 1 )
                   or    z = substr( s, mod( ind - 1, 9 ) - 8 + lp * 9, 1 )
                   or    z = substr( s, mod( trunc( ( ind - 1 ) / 3 ), 3 ) * 3
                                      + trunc( ( ind - 1 ) / 27 ) * 27 + lp
                                      + trunc( ( lp - 1 ) / 3 ) * 6
                                   , 1 )
                 )
)
select s
from x
where ind = 0
/

(Anton Scheffer) [Solving a Sudoku using Recursive Subquery Factoring]

Impressive code from our amici over at Amis. But also an impressive example of how far one can go outside the original domain of a language. I mean recursive queries? On the other hand this algorithm does not look too good in Scala or in Perl either. The mathematics of Sudoku are studied in depth. Sudoku has been shown to be NP-complete and of the many ways of solving Sudoku, dancing links and constraint programming seem to be very popular. (Typically, it takes milli seconds for a computer to solve a Sudoku.)

“Software types are more analytical, (either as a result or as an cause of them being in their field). As such they see things that Joe Random doesn’t even notice. When the waitress says “If you need anything else, my name is Betty” Joe Random grunts and takes a bite of his meal. Programmer dude wonders what her name is if he doesn’t need any thing else. […] Computer types are so used to thinking about eventualities, undesirable consequences, dangling IF conditions, and protecting against them that they fall into doing so in personal life as well. A simple, carelessly worded question in normal conversation can render them speechless while the gears grind.” (icebike) [icebike, article]

“When I was a young boy” (Muddy Waters) [Manish Boy] my mother done told me, I was one scary boy. Mind we are talking pre PC era. Actually the IBM PC was still ten years a-coming. Yes, we are talking August 1971. I was at the age of five—just. Somehow I had gotten hold of my sisters “vorm en kleur” (shape and color) booklet. (I summoned all my google fue, but to no avail, so I can not show it to you here.) It was some typical ’70s teaching tool. There were colored shapes, like red-squares, or blue-triangles. There, also, were “boxes” that would interact with the colored shapes, either changing a shape or a color. E.g., from square to triangle, or from red to green. I instantly absorbed the booklet and soon I was filling paper after paper with my own variations. I had generators, that produced a specific shape and color, no matter what the input was. I noticed that boxes could not handle all input (i.e., the domain was limited), so I made up rules, like door-als-past-niet (pass-if-unfit) and designed draai-vorm (shape-rotator) boxes that would work for any shape and draai-kleur (color-rotate) that would work for any color. I would string boxes into more complex boxes. I would draw boxes with multiple outputs, multiple inputs, an arbitrary input symbol (actually a question mark), kies-maar (choose-arbitrary, i.e., a non-deterministic box), kies-pas (choose-fitting, i.e., box overloading), duplicator boxes, switcher boxes, decider boxes (i.e., flow control), state-holder boxes and many others. The shear volume of papers littering my room, with all these boxes, really scared my mother—or it might have been my unwillingness to interrupt my journey for trivial mundane thins like eating, sleeping, social interaction and personal hygiene. Basically, that was when I learned all there was to know about input, process, output. Everything I learned about writing code later in life seemed a trivial continuation of “vorm en kleur.” And why am I laying this funky bit on you? Well, the original “vorm en kleur” system—not including my extensions—probably is the most complex thing a non techie, will be able and willing to understand. So it might be the perfect tool to explain the biggest known secret of systems design: The inside matters. Ok, a raise of hands, who amongst you pro-programmers has had trouble in the past explaining this to some manager? Ok, ok, just what I thought. Next time explain “vorm en kleur” and draw them this:
Tell them: “This is what we have. This is what we need.” and draw them:
If they don’t understand, just quit, seriously, run while you still can. You know why? Because that would-be-colleague that writes those “what we have,” by virtue of delivering some results that the customer came to accept, will be put in charge of designing the grand new integrated product that will be the apotheosis of all your company’s products (all in Python, mind) and “they” are going to bet the whole company on you saving the day while crediting your ex-colleague-now-boss. You will die a slow and painful death. You will die from battle fatigue—or maybe it will be the lack of time for those trivial mundane thins like eating, sleeping, social interaction and personal hygiene. And you want to know the worst part of it? You are sure, you want to know the most gruesome part? You know, you know what the worst part is, already. Right? Worse than dying, your legacy will be a big pile of shitty code. So… run… run… run… like a man.

“A sociopath-entrepreneur with an idea recruits just enough losers to kick off the cycle. As it grows it requires a clueless layer to turn it into a controlled reaction rather than a runaway explosion.”
“Sociopaths, in their own best interests, knowingly promote over-performing losers into [clueless] middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves.”
“Eventually, as value hits diminishing returns, both the sociopaths and losers make their exits, and the clueless start to dominate. Eventually, the hollow brittle shell collapses on itself…” (Venkatesh Rao) [The Gervais Principle]
If you are a good programmer, than you will be—by definition of the word: good programmer—perceived as “bare-minimum-effort” loser. It is the effort that counts. That is why you are left to fend for your self. So there, now you know.