Re: The end of America

Having listened to Naomi Wolf as she speaks about "10 steps to fascism" here:

http://www.youtube.com/watch?v=RjALf12PAWc

and here is a supporting story in Guardian:

http://www.guardian.co.uk/usa/story/0,,2064157,00.html

I was applying the principles she suggests to current situation in Russia one by one, and surprisingly, they hardly applied:

1. Invoke a terrifying internal and external enemy.

Pass. None of those exist in modern Russia. Chechnen terrorists looked like a mixed ex/internal threat once, but then quickly diminished. No external power is considered a threat. There are "me too" kind of reactions to the America-declared global war of terrorism, such as the absurd requirement to take off one's shoes in the airports, but that looks like a totally random acts of power rather than a iron fist lead.

2. Create a gulag.

Well, I wouldn't know. In a country whose leader has invented gulag, I'm sure as hell there are secret prisons, but then they don't have to be secret, any would do. So, I'd say no, there is no gulag in modern Russia in the meaning of the word Naomi Wolf puts in it.

3. Develop a thug caste.

No such thing. Or, multiple such things, depending on what you mean. There is no single dedicated paramilitary force and none are emerging. There is army, state police, corporate security guards, and all sorts of criminal organisations, I'd presume. They all may apply force pursuing their arbitrary goals, but I don't think they orchestrate. This is not to obscure the fact that the police or army could at any point be given any orders.

4. Set up an internal surveillance system.

There easily could be files on anyone, just as with the mentioned Stasi, but I don't think there is a global network of surveillance and the percentage of informants has hopefully decreased since KGB time.

5. Harass citizens' groups.

Citizen groups ? What citizen groups ? None of active opposition to the power, that's for sure. Groups of political hobbyists and minorities of all sorts may be present, but noone worth mentioning with real power or a threat to power. Therefore there is no reason to persuasively harrass anyone. At any rate, they don't make a show out of it.

6. Engage in arbitrary detention and release.

It's not comforting, but I'd guess, yes, it's just like that. The stories of people being detained, kept in prisons, beaten and tortured appear every now and then. And the purpose could very well be the same - to terrorize and intimidate the entire population, even if in subtle way.

7. Target key individuals.

Check. Except, there is no key individuals. There are occassional public executions of someone who is sort of in opposition, but the truth is - there is no opposition. Oh, and nevermind the reporters murders.

8. Control the press.

Check. I mean, absolutely.

9. Dissent equals treason.

I'd answer this question if anyone could tell me what the today's Russia consent is ? Anything sacred ? Take Americans, they worship their democracy and freedom (ahem, given the steps to fascism title, this sounds awkward), but in Russia - what is the true way ? The way I see it, right now Russia is happily doing nothing, basically selling oil for food.

Actually, it's funny how I can't come up with anything that would sound plausible and treasonous at the same time. Brainwashed with no access to the facts - the most likely cause.

10. Suspend the rule of law.

Well, there is no martial law in Russia right now and I hope not to ever see it. We have laws and justice, right ? Although Russians are traditionally very sceptical to the laws and justice, but you can't argue that codices exist and trials work.

So, it sounded not so bad, right ? But wait until it comes to about minute 41 of the speech, and the answer should have been obvious in the context - the closed society doesn't look like one.

To quote Naomi Wolf:

We have this, like, wrong notion of what a closed society looks like. ... A closed society, even a violent military dictatorship, [looks a lot like] civil society, there are still elections, they are just corrupted. ... There is still a judiciary in a closed society, they are just not free to adjudicate freely. ... There's still academics, they're just watching what they're saying. There is still newspapers, you just know how far to push the enquiry.

Duh ! What can I say, welcome to the closed society. We'll have to see how it works out in America. Anyway, the speech was very thought-provocative.

On software reliability

Despite the common prejudice and the name, for a system to be reliable is not the same as to have no errors or never crash (noone should ever be promising that). The way I see it, reliabilty is more of a predictability. A system is reliable if it behaves in a predictable fashion - so much that you can rely on that. Even if all it does reliably is crashing.

The systems we build, they don't exist in isolation. Again, despite a popular myth, programmers don't pull things out of a thin air. We base our work on the work of others - hardware, operating systems, servers, frameworks, libraries, compilers, you name it. Reuse is the boon and the bane of the industry. Client-server pairs, interfaces and contracts are not just about OOP, they are everywhere. Any interaction between software components is about grabbing something somebody else has.

I therefore take it for granted, that there are parts of the system not written by us or not belonging to us. This implies that they cannot be controlled in any way (actually, I mostly work on integration middleware, which makes my experience worse). Then this inability to control leads to inability to fix. More often than not, you cannot fix problems in systems you have to depend on.

What do you do when you encounter an unexpected behaviour from somebody else's system you have to depend on ? I do this: first - fetch a cookie for being lucky, second - understand the cause, third - find a workaround.

The point here is - a problem known is not a problem. Because if you know the exact circumstances under which it hits, you can work around. Figuratively, you have to walk the minefield, but every previously found mine can be sidestepped. Therefore,

For a component to be reliable, you must be able to work around any problem encountered, and for a system to be reliable, you need to know all the problems it can cause.

To conclude, here is a few examples of something which is broken and reliable at the same time, because there is a workaround:

• Reliable is a broken CPU which always fails upon certain floating point division. The numeric libraries fall back to software emulation when encountering this particular kind of chip.
• Reliable is the XML parsing library which crashes when you attempt to set attribute value to something with letter "Ё" in it. I replace "Ё" with "Е", which is a good enough if slightly ambiguous substitute.
• Reliable is the compiler which chokes and dies upon too complex a template. I rearrange the angle brackets and it goes on fine.
• Reliable is the provider's server which crashes every other Friday at 13:00. I schedule an offline gap at that time and noone complains.
• Moreover, reliable is the provider's server which crashes sporadically, but will gracefully handle repeated access attempts. As you might guess, this last example is the warmest to my heart and is one of the bases for Pythomnic - the platform for developing network services I'm developing and using.
  

Another ridiculous sentence

"Fighting stress"

The only way to get something done

... is to start and then don't stop.

Note to self: default parameter values are mutable in Python

Just hit a somewhat unexpected behaviour in Python code. What would the following code snippet print, what do you say ?

def foo(x = []):
    x.append("bar")
    print x

foo()
foo()

If you think about the def statement as a declaration, the answer is obvious - it should print

[ 'bar' ]
[ 'bar' ]

but in fact it prints

[ 'bar' ]
[ 'bar', 'bar' ]

Why ? Because in Python def is an executable statement, which means that the list of arguments for the method to be created (x) and most importantly their default values ([]) are themselves nothing but arguments to def. Something like this:

foo = def(x, default_x)

and when this gets executed, default_x is bound to something that at that point evaluates to an empty list, but remains mutable. Then, whenever the created foo is executed, the append method modifies the contents of default_x - effectively the "default value" of x.

This sounds strange, but is clearly documented in the language reference, quote from http://docs.python.org/ref/function.html

Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same "pre-computed" value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified.

The spec suggests using None for all the default parameters, but you should have no problem using any immutable objects as well. For example:

def foo(x = None):
    print (x or []) + [ "bar" ]

where x is None, or

def foo(x = ()):
    # oops, no append method
    print x + ( "bar", )

Phew, I've been lucky using None's so far...

Sympathy for Mr. Software

No software does what the user is supposed to be doing, because that is not known to the user in the first place. Should that have become known, the person could have been replaced with a machine. Instead, software helps people by making small and routine parts of their jobs easier to do. Even that it does imperfectly.

The users constantly struggle to make the software do what they want, the way they want. Sometimes they find the features useful the way they are. Sometimes they adapt to their quirks. Sometimes they find ways around. And sometimes they dump the whole thing.

As such, software is a dumb servant. A very dumb one. It needs assistance by itself.

To be useful, software needs assistance from the user. There must be a way for the user to explain what he wants even though the software may not have this capacity.

But then, returning to the dumb servant metaphor, the user must be willing to help. Therefore, here is my point - the software should be appealing to the user's sympathy or even pity. The user should be empathically connected to the software. To help and not to throw it away should be its first reaction.

I don't have any recipes on how to build such software. Arousing human's sympathy can be difficult even for another human, not for a piece of software. The only answer that I have is that the user should like the software for what seems to be nothing in particular.

The way I see it now, software should be written in such way that the user likes it for no apparent reason from the first sight. If it's pretty and it behaves consistently and it doesn't jump in your face and it knows when to speak and when to shut up and it looks familiar and it looks novel and it has square buttons and it has round buttons, then perhaps the user likes it. But you never know.

Note to self: exc_info is only available after except handler

It looks wrong to me, but in Python an exception is registered only when it hits the except handler, not immediately after it's thrown. In the following code snippet the first finally block is totally unaware of the exception.

import sys
try:
    try:
        try:
            raise SystemExit()
        finally:
            print "1:", sys.exc_info()
    except:
        print "2:", sys.exc_info()
        raise
finally:
    print "3:", sys.exc_info()

prints

1: (None, None, None)
2: (<class exceptions.SystemExit ... )
3: (<class exceptions.SystemExit ... )

This is not how I would expect it to work.

Upon closer inspection of the sys module's documentation:

exc_info()
This function returns a tuple of three values that give information about the exception that is currently being handled.
Here, 'handling an exception' is defined as 'executing or having executed an except clause.'

This contradicts to my common sense, but it is the way it is, so I'll have to find another solution for the problem at hand.

Re: Backpack

Having listened to Jason Fried as he speaks about the process they use at 37signals:

http://itc.conversationsnetwork.org/shows/detail471.html

I couldn't agree more to nearly all of his points. Also while listening to it, I had this associaction of the process with nothing but Brownian motion.

See, Jason essentially suggests that you have a small team of positive people in a small and lightweight cart and then allow every single individual product user push it in whichever direction he or she feels appropriate. A single user's push may not matter much, but if many of them push in the same direction, the cart moves. Then, this ease of feedback will also encourage the users to push more.

There are many other fine points in his speech and so I would definetely recommend to listen to it. Anyhow, here is a few other thoughts.

For one, the word "architecture" doesn't come up, but I do believe in architectures. Although architecture wouldn't emerge from the process outlined above, I thought that it would still present at the end, as one of the artifacts Jason calls "embraced constraints". These are restrictions that you enforce on your project in pursuit for optimal solutions. And architecture is just that.

For two, the described process is perfect for exactly this particular niche - web-based collaboration-like projects open for mass public access. It wouldn't work in many other cases, for example, if you build a project which you target towards big companies. Or, if the audience is too few, so that there is not enough user mass to push the cart.

For three, it seems logical to me that such brownian motion wouldn't last forever, the project trajectory would converge to some ideal point. And having such ideal point in mind from day one may be beneficial.

Otherwise, there was may be one thing that I don't agree with, and even that was minor and taken out of the context, it's when Jason says "get rid of boxes and arrows". While he probably meant functional diagrams in the context of the speech, getting rid of my favourite boxes and arrows feels scary. I would never give up such powerful mental instruments as boxes and arrows.

Overall, a great speech.

Re: To mistake is human

By programming we delegate the right to failure to the computer.

But the responsibility is still with us.

The most valuable pages of the World Wide Web

The World Wide Web contains a huge amount of files. Of those, HTML pages can point to each other (and other files too) with hyperlinks. Thus created hypertext structure can be presented with a directed graph.

Technically, the World Wide Web graph can contain cycles, but this is only possible if a page has been modified after it has been referenced. Specifically a page which has never been modified after it was created, cannot participate in a cycle. Therefore there could exist leaf pages, which are only linked to and not contain links themselves.

It is also seems reasonable that if page A links to page B, then the owner of page A somehow values page B, even if in some negative kind of way. Otherwise, he wouldn't even bother to put it there.

Now, the question is - aren't the most valuable pages of the World Wide Web the ones that are only referenced to but do not reference other pages themselves ? Taking it one step further, is a value of a page a function of N/M (where N is the number of the links to this page and M is the number of links from this page) ? Then a page with no links in it will indeed have infinite value.