Mein Vorschlag für diese Diskussion

... ist schwer.

Glücklicherweise wurde der Prozess endlich offen gelegt!

Wunderschönes Comic - gezeichnet und gesprochen von Meistern.

Eine schräge Mischung aus japanischem Samurai-Gemetzel mit western Einflüssen plus Handies und Roboter...

Muss man sehen.

(Mehr Info)

... auf die Shell zu ziehen und ins Highlighting zu ziehen. :) (Sorry, ich muss dringend mal wieder Herr der Ringe anschauen)

Mir geht es um grep, der Urgroßvater aller Projektweiten Suchmöglichkeiten. Das kann viel - aber nicht alles.

Zum Beispiel ist es nicht besonders einfach in einem Projekt zu suchen dass SVN für die Versionskontrolle einsetzt. Grep besteht nämlich darauf dass es unbedingt bei -r auch in .svn Verzeichnissen suchen will. Und das beste: es gibt zwar eine Option --exclude - die funktioniert aber nur auf File-Basis. Das heißt man kann damit keine Verzeichnisse (wie z.B. .svn) ausschließen.

Doh.

Die Entwickler sagen dazu dass man doch lieber find . mumbojumbomagic | grep muster benutzen soll. Tja.

Enter Ack. Die Lösung aller Probleme. :)

• Das Tool sucht standardmäßig rekursiv - d.h. man muss nicht ständig -r angeben.
• Es ignoriert standardmäßig .svn .hg .git etc. Verzeichnisse - daher muss man nicht ständig irrelevante Resultate ignorieren.
• Man kann mit switches wie --python oder --objc nur in Dateien dieses Typs suchen.
• Man hat vollständige Unterstützung für Perls Regular Expressions auf der Kommandozeile (das Tool ist in Perl geschrieben)
• Man kann das Tool supereinfach in ~/.ackrc konfigurieren.

Hier meine .ackrc:

$ cat ~./ackrc
--type-set=nib=.nib
--type-add=objc=.mm
--ignore-dir=build

Schick ne?

Hier zu finden.

Flüssigkeit != Flüssig

Was ich als Spaß alles verpasst habe, weil ich sowas noch nicht gesehen habe.

Damit ist sogar endlich geklärt wie es Jesus geschafft hat über das Wasser zu gehen.

:-)

Ach ja, die Erklärung (Wikipedia) und mehr details (Wikipedia) und eine Anleitung zum Selber herstellen.

Have phun!

Heute hatte ich das witzige Erlebnis dass wir in ein Parkhaus gefahren sind - und einfach keinen Parkplatz gefunden haben.

Ok, soweit wars noch nicht spannend - aber was ich hoch-interessant fand, ist dass wir dann beim Rausfahren nicht zur Kasse gebeten wurden. Das macht Sinn, denn wer keinen Parkplatz findet, ist natürlich Dreifach angepisst wenn er dann dafür auch noch Zahlen muss. (Und vielleicht während dessen auch noch den Ausgang versperrt.. :)

Ich halte es für sehr wahrscheinlich, dass jedes Parkhaus so funktioniert. Cool. Denn das bedeutet, dass man prinzipiell jedes Parkhaus umsonst benutzen kann - man muss sich nur unmittelbar vor dem herausfahren eine neue Marke besorgen.

:)

(Ok, das mag nicht soo leicht sein, aber im Prinzip...)

Python != Funktionales Programmieren

--- zumindest scheint es so.

Das hier zum Beispiel:

#!/usr/bin/env python
# encoding: utf-8

def counter_generator():
    current_value = 0
    def counter():
        current_value += 1
        return current_value
    return counter

import unittest
class ClosureTest(unittest.TestCase):
    def test_counter(self):
        self.assertEquals(1, counter_generator()())

if __name__ == '__main__':
    unittest.main()

Wenn man das ausführt dann kriegt man den wenig aussagekräftigen Fehler UnboundLocalError: local variable 'current_value' referenced before assignment. Oder mit anderen Worten: "Wiebidde?"

Kommentiert man current_value += 1 aus, funktioniert das ganze (ok, bis auf den dann fehlschlagenden Testcase).

Immerhin kommt man dem Problem dann auf die Spur (ich und Felix haben das leider erst herausgefunden nachdem wir auf #python nachgefragt haben...) Python kann nämlich seine Scopes nicht vernünftig. Das heißt, man kriegt keinen schreibenden Zugriff auf die Variablen eine Funktion weiter draußen - nur lesend. Nur dass die Fehlermeldung natürlich total mist ist.

Grah.

Interessanterweise geht diese Lösung auch nicht

#!/usr/bin/env python
# encoding: utf-8

def counter_generator():
    workaround = object()
    workaround.current_value = 0
    def counter():
        workaround.current_value += 1
        return workaround.current_value
    return counter

import unittest
class ClosureTest(unittest.TestCase):
    def test_counter(self):
        self.assertEquals(1, counter_generator()())

if __name__ == '__main__':
    unittest.main()

Für hinweise wieso bin ich dankbar.

Vielleicht kriegt Python dass ja irgendwann mal hin. In der Zwischenzeit hilft dieser Workaround:

#!/usr/bin/env python
# encoding: utf-8

class AttributableDict(dict):
    def __getattr__(self, attribute_name):
        return self[attribute_name]
    def __setattr__(self, attribute_name, value):
        self[attribute_name] = value

def counter_generator():
    workaround = AttributableDict()
    workaround.current_value = 0
    def counter():
        workaround.current_value += 1
        return workaround.current_value
    return counter

import unittest
class ClosureTest(unittest.TestCase):
    def test_counter(self):
        self.assertEquals(1, counter_generator()())

if __name__ == '__main__':
    unittest.main()

iCal - ein Programm das man lieben und hassen kann.

Einerseits, es funktioniert gut, ist ordentlich ins System integriert - aber andererseits sowas:

Wenn man einen Termin bearbeitet, dann doppelklickt man ihn. Danach öffnet sich dieser in einem neuen Fenster, in dem man dann noch einmal auf Bearbeiten klicken muss damit man ihn tatsächlich verändern kann.

Das tolle daran: Wenn man dann irgendwann mit seinen Änderungen zufrieden ist und ihn bestätigen möchte, dann stellt man fest das der "Bestätigen" Knopf auf keinen sinnvollen Keyboard Shortcut reagiert. Enter, Return, Controll-Return, Command-Return, Alt-Return - alles voll daneben.

Bisher dachte ich nur: "Naja, voll nervig" aber heute ist mir aufgefallen dass sie es sogar geschafft haben dem noch die Spitze aufzusetzen: Es gibt nämlich doch eine Tastenkombination um die gemachten Änderungen zu akzeptieren:

ESCAPE

!!!!1111!!!!(elf)!!!

Ich bin Sprachlos.

(With many thanks to Dan Levin for his help)

This is what I arrived at [blog:2008/08/19/19.49 last week] as an authentication GUI:

This GUI Design has several good and bad points - first the good ones:

• It tells the user exactly what he should do
• It gives help in how to achieve that
• It provides additional help on how to achieve this

The bad ones though weigh very heavy:

• Its a dialog.
• Its super text heavy
• it looks ugly (well not because of the design, but because it has so much text in it.)

The most pressing problem however is in the library support from OTR. It simply does not know what a question is.

This is a problem, because it makes it almost impossible to have the Question as a special entitiy in the GUI - and also that none of the synchronisation problems that this brings are adressed in the GUI. So what to do if both users start typing their own question? The other User wouldn't know - then how does the programm tell the user that his question was just overruled be the other persons and that he should provide the answer to that as the secret word?

There is more of course - but this is what I consider the most important.

Well, this is our current approach at solving these problems:

This is what I like about this:

• No more dialog, it's all happening inline
• It clearly states what goes where in clear statements
• It tells the user in clear terms what he needs to do and how to do it
• Only as much text as is absolutely needed
• Provides more help should the user request it.

Especially this is the most simple GUI of all the approaches that I tried.

I don't have finished mockups of the other aproaches (most is pen'n'paper work) but I did try having the question and answer thing inline like so:

I especially like the fact that this gives lots of practical information to the user - even if it is still very wordy and does not solve the race condition of who will actually ask the question.

Therefore we decided to go with the first aproach pictured above.

There is of course more to this GUI than just the pretty pictures shown above. A few more things come to mind, that we think are very important:

• The normal chat window can and should be used as a feedback and instruction window. (With help messages clearly marked as such of course.) We want to use this to show some initial help when the "Verify" button is clicked and the authentication process is started and also at least when the authentication process fails multiple times, to provide additional help and tips as to how to overcome this situation.
• Whenever the user types the secret word in the normal chat we want to either clearly notify the user that he has just compromised his password exchange and needs to choose a new question and answer (also if it is in the recent history) or we'd like to prevent the sending of the message (perhaps with a dialog box that also allows to proceed if that is really wanted).

One unsolved problem is, that when the authentication fails multiple times, we need to find a good compromise between teaching the user about ways to prevent errors and making him aware of the possibility that there may be a man in the middle attack taking place.

Of course, just as the last time: Feedback welcome.

Here's the rest of the work

... die schönste freude.

Stimmt einfach. :)