Author: axel

Aikido-Techniken

Wie man rechten Rand dieser Seite sieht, habe ich meine Notizen zu den Aikido-Techniken, die ich gerade lerne, öffentlich auf die Website gepackt. (bis ich herausgefunden habe, wie man Wordpads Kommentar-Funktion auch für “Seiten” bekommt, hoffe ich auf Kommentare an diesem Eintrag hier – ich will ja wissen, was Du (ja genau Du) darüber denkst!).

Was mich umgehauen hat: Wenn man bei google die Namen der Techniken eingibt (z.B. “irimi nage” oder “shiho nage”), erscheinen meine Seiten weit vorn! Und das, obwohl (soweit ich weiß) niemand auf diese Seiten verlinkt. Gibt es wirklich so wenig Aikido im Netz? Oder ist die Idee, die Techniken beschreiben zu wollen, derart abwegig?

“Das kosmische Schwert hat viele Möglichkeiten der Anwendung, die nur mündlich weitergegeben und im wirklichen Training gezeigt werden können” (Ueshiba in “Budo”). Ich hoffe, auch wenn man Bewegungen nicht aus Text lernen kann, hilft Text, sich an das Gelernte zu erinnen. Genau wie Bilder, Rückfragen, Videos, und all die anderen schönen Dinge, die das Netz heutzutage bietet.

Graduierung

Letztens unterhielt ich mich mit Ronald über die verschiedenen Aikido-Schulen, die es in Deutschland gibt. In unserem Dojo hängen auch Lehrgangsausschreibungen anderer Schulen aus. Ich hatte mich gewundert, woher einige der Lehrer einen sechsten oder siebten Dan hätten, und fragte mich, ob das denn ein “echter” Dan sei oder ein quasi selbst verliehener. Ronald kommte mich beruhigen, dass auch diese Dan-Grade letztlich auf das honbu dojo zurückgehen, aber, und da kommen wir endlich zum interessanten Teil,

“Du könntest hier im Garten ein Dojo aufmachen und anfangen, Dan-Grade zu verleihen, und niemand könnte Dich davon abhalten. Du könntest es sogar Aikido nennen.”

Man muss halt nur genug Mitspieler finden, um einen glaubwürdigen Rahmen für die Gemeinschaft zu schaffen. Credibility wird oft über Lehrer-Schüler-Ketten vom O’Sensei weitergereicht, Genealogie ist auch wichtig. Bei anderer Gelegenheit ist auch der Staat ein wichtiger Mitspieler. Der vielleicht offiziellste technische Maßstab ist der aktuelle Doshu im honbu dojo, aber der ist weit weg. Das in vielen Kampfkünsten (wie auch in der Wirtschaft) gern bemühte Kriterium der Effektivität, praxistauglichkeit etc. ist gerade im Aikido kaum messbar.

Was Original ist, was zeitgemäße Weiterentwicklung, was persönlicher Stil, körperliche Eigenart, Eklektizismus, unheiliger Mischmasch, Ego-Trip, Esoterik,… das scheint im Deutschen Aikido tatsächlich Geschmacks- und Verhandlungssache zu sein. Das Entscheidende für eine reichhaltige und langfristige Entwicklung ist wohl einfach, gut eingebunden zu sein.

Hear hear!

“Maybe you don’t work for or with a Global 2000 company, so I’ll let you in on a little secret: They Can’t Hear You! That’s right, the CIOs, and Enterprise Architechts, and, yes, even the journeyman programmer employed by these firms have no idea that there’s even a discussion going on. […] They don’t read technology blogs, they don’t know who DHH is, and they’re excited to get their new Vista gear.”

I was quite relieved when I read Pete Lacey’s post, as it means the world of cubicles hasn’t swallowed IT entirely. There are some companies where the CEO is blogging. Some might understand this as a marketing instrument and broadcast medium at first, but the medium will get them – there is no blogging without discussion. And if the CEO sets the example, employees are likely to follow.

There’s another, rather unpleasant aspect to this, however: If some (the?) blogging community unanimously votes for or against something, then this says nothing about the validity of this result for another, decoupled community like the Global 2000 flock. Just as an example, a discussion among technicians is likely to exclude commercial and organizational aspects, either willfully or because of lack of expertise (ignorance is such a hard word). A CEO would be maladvised to just copy their results.

Motivation

Darth Vader: You may dispense with the pleasantries, Commander. I’m here to put you back on schedule.
Moff Jerjerrod: I assure you, Lord Vader. My men are working as fast as they can.
Darth Vader: Perhaps I can find new ways to motivate them.

What is managing software development?

Raganwald: What is managing software development?
“The fundamental definition: “Management” is accountability for results, authority over resources, and making decisions based on judgement. […] and courage.”

Thinking about it, I wonder if I have ever seen anyone “managing” software to such an extent. In my reality, there are too many constraints, most of the time, and too much fog around the results. It might be nice for a manager to prove himself like that (“The project’s mine! All mine! And I did it!”), but then again his project might not be too much fun to work in.

Subtext Refactoring

A few months ago I tried to implement some refactorings for the Subtext “programming language”. I think I now understand some reasons why that did not work out.

A refactoring changes the shape of your program, while maintaining the program’s behaviour. You do it so the code gets into a shape that makes the changes you are aiming for easier to apply, and makes it easier to reason about their correctness. The correctness of the initial refactoring is guaranteed by your IDE.
Note that even a refactoring is a change; it is only guaranteed to be “correct” as long as you live in a closed world, where all the code you might interact with is contained in your IDE project. As soon as you leave that safe haven, using type casts, reflection, dynamic linking, or when you guarantee backwards compatibility for published interfaces, that’s over.

So, what about Subtext?
Firstly, Subtext does not have an external “behaviour” that might be observed. It just has a system state, and it’s up to the user to observe any interesting bits of that system state at any time, and even in retrospect. The system state encompasses both code, data, past states and an operation history. It’s all the same, actually, just nested nodes.
This makes it somewhat difficult to separate a program’s behaviour from the program itself. The solution I tried for transferring the refactoring idea is to guarantee some property of some usage of a node before and after a refactoring: “When invoked as a function with the same arguments as before the refactoring, the result subtree will look the same” – seems quite straightforward. I made a whole catalog of these.

However, here comes “Secondly”: Secondy, Subtext is completely untyped – at a sufficient level of abstraction, function invocation is the same as copying with changes, and is also the same as assignment, method overriding, and object creation, and it is exactly at this level that Subtext operates. Also, all the innards of a function are accessible (and overridable), not just its result. So essentially the only way to know what a “function” does to its arguments is to run the function. Especially, due to untyped higher-order data flow, an automated analysis can’t really tell where a node modified by the refactoring may eventually be copied to. But without this information, the refactoring cannot guarantee much about the system state. (I tried some heuristics, which turned out either too coarse or felt incomprehensible to a user).

Static types and other distinctions made by the programming language form the contract between you and your tools. As long as you stick to the types, your tools can and will help you. If you don’t have a type system, or the type system is too clever, you do not notice when you cross the line, and your tools become unreliable.

If a project is small enough and short-lived enough, and the language concise enough, you may not need tools as desperately. Some people also find tools like Eclipse or IntelliJ Idea too complex or heavy-weight and prefer to stick to their ASCII editor, and therefore focus on the “conciseness” aspect, or restrict the scope of their project, or rely on tests. That’s OK as long as you realize that by liberating yourself from types, you are also limiting yourself in various ways.

The hard way

“Academic discussions won’t get you a million new users. You need faith-based arguments. People have to watch you having fun, and envy you.”

Steve Yegge points out that culture matters, and may make Ruby the Next Big Thing.

When asked why we are using Java at work, I said “because we have to do things the hard way” – it’s the way that’s guaranteed to work, rock-solid, interoperable, stable, enough skilled engineers out there in the market place, enough googleable solutions for our everyday problems, will be actively maintained for years to come, Not My Fault if it does not run, etc.

If Ruby ever gets to that point, great. But until that day, everyone in middle management does their best to ignore the fun factor, and engineers will keep dreaming (of using Ruby, of owning an Apple Mac, of a world without deadlines, legacy and momentum).

The hard way means: having to wait until the Next Big Thing is the Current Big Thing.

Surprise

“Before that, like every beginner, I thought you could beat, pummel, and thrash an idea into existence. Under such treatment, of course, any decent idea folds up its paws, turns on its back, fixes its eyes on eternity, and dies.”

Ray Bradbury, Just This Side of Byzantium