Google wird Grün

Google kündigte am 27. November 2007 eine Initiative für erneuerbare Energien an. Wörtlich: Google "creates renewable energy R&D group and supports breakthrough technologies". Da wird viel geredet über Solar- und Windkraftwerke. Aber sind das wirklich "breakthrough technologies"? Mir fällt da eine potentielle "breakthrough technology" ein. Was, wenn Larry Page Dr. Bussard seinen Vortrag bei Google abgenommen hat?

"In 2008, Google expects to spend tens of millions". Was sagte noch Bussard, wieviel der nächste Schritt kostet? wenige Millionen US $ zur Verifikation, dann ca. 200 Mio US $ für den Demoreaktor. Das passt ganz gut zu "the company also anticipates investing hundreds of millions of dollars in breakthrough renewable energy projects". Natürlich kann man für so viel Geld auch viele "breakthrough"-Windräder kaufen. Aber vielleicht ist der Solar/Wind-Teil auch nur ein kleines Ablenkungsmanöver und eine Beruhigungspille für Aktionäre.

IEC - Hoax oder Rettung der Welt

Am 9. November 2006 präsentierte ein alter Mann im Google-Firmenseminar (Google Tech Talk) eine erstaunliche Theorie. Der Mann war Dr. Bussard. Bussard ist bekannt für den sogenannten Bussard Ramjet, einen hypothetischen Raketenantrieb, der interstellaren Wasserstoff durch Magnetfelder einsammelt, komprimiert und zur Kernfusion bringt. Das war aber nicht die Theorie, über die er bei Google berichtet hat. Der Ramjet stammt schon aus den 60-er Jahren. Bussard befasst sich also schon seit 50 Jahren mit Magnetfeldern und Kernfusion. Er ist ein ernstzunehmender Physiker und Ingenieur. Er war in den 70-er Jahren Assistant Director der Atomic Energy Commission und bis in die 80-er Jahre an einigen Projekten zur Tokamak-Kernfusion auch für das DOE beteiligt. Bussard hat mehrere Unternehmen gegründet, darunter 1984 die EMC Corporation, eine Anspielung auf Einsteins E=mc^2 Formel.

EMC hatte über viele Jahre bis 2006 Forschungsaufträge der US-Regierung. Die Firma beschäftigte sich mit der Herstellung von Prototypen für einen neuen Typ von Kernfusionsreaktor. Und das ist der Punkt an dem die Geschichte erstaunlich und für Laien undurchschaubar wird. Das heißt aber nicht, dass sie nicht wahr sein kann.

Bussard berichtet, dass seine Firma an IEC-Fusion arbeitete. IEC ist die Abkürzung für Inertial Electrostatic Confinement, also elektrostatischer Trägheitseinschluss. Kernfusion ist in der Theorie einfach. in der Praxis aber sehr schwierig. Man bringt leichte Atome (z.B. Wasserstoff, Lithium, Bor) sehr eng zusammen. Sie verschmelzen zu schwereren Atomkernen und setzen dabei Energie frei. Die Energie kann man dann verwenden, um Strom zu erzeugen. Leider stoßen sich Atomkerne ziemlich stark ab, da alle positiv elektrisch geladen sind. Man muss sie deshalb unter hohem Druck einsperren und zusammenhalten. Das nennt man Einschluss (=Confinement).

Es gibt verschiedene Methoden Atome zusammenzupressen. Zum Beispiel so wie es in Sternen (unsere Sonne) geschieht, durch Gravitation. Dafür braucht man sehr viel Masse, ca. 100.000 mal so viel wie das Gewicht der Erde. Das ist also technisch nicht praktikabel. Eine vielversprechende Methode ist der Einschluss durch Magnetfelder. In sich geschlossene (Tokamak) Magnetfelder, die 100.000 mal stärker sind als das Erdmagnetfeld können Atomkerne genügend zusammenpressen. Darüber hinaus kann man auch Wasserstoffkügelchen mit gigantischen Lasern beschießen, so dass sie explodieren wobei für kurze Zeit ein großer Druck entsteht, der die Atome genügend zusammenpresst. Das nennt man Trägheitseinschluss. Sowohl am magnetischen Einschluss, als auch am Trägheitseinschluss wird noch geforscht. Es ist aber jetzt schon klar, dass wenn sie eines Tages wirklich funktionieren dafür ziemlich große und teure Anlagen gebaut werden müssen.

Genauso wie sich die elektrischen Ladungen der Atomkerne abstoßen, ziehen sich gegenseitige Ladungen an. Man könnte deshalb die Abstoßungskräfte überwinden, indem man einen negativ geladenen Pol (Kathode) aufstellt zu dem alle Atomkerne hingezogen werden. Sie werden dort so stark hingezogen, wie sie sich untereinander abstoßen. Die negative Ladung müsste nur etwas größer sein, als die positive, dann kommen sich die Atome ziemlich nahe. Das nennt man elektrostatischer Einschluss (= electrostatic confinement). Das einzige Problem dabei ist, dass mit dem Druck der eingeschlossenen Atomkerne auch die Temperatur steigt. Und zwar auf viele Millionen Grad. Das heißt, dass die Kathode ziemlich schnell schmilzt und kaputt ist. Die einzige Lösung ist eine sog. immaterielle Kathode, die nur aus Elektronen besteht. Man müsste die Elektronen zusammenhalten ohne ein Material, dass schmelzen kann. Man kann tatsächlich Elektronen durch ein Magnetfeld zusammenhalten. Mit der richtigen Magnetfeldstruktur kann man einen Klumpen Elektronen an einer Stelle in der Mitte der Magnetfelder fixieren. Schießt man jetzt leichte Atomkerne darauf, dann kreisen die Kern um den Elektronenklumpen in der Mitte und treffen sich immer wieder. Jedes mal, wenn sie sich treffen, können sie verschmelzen und Energie erzeugen. Die Kunst bei diesem Verfahren besteht in der Anordnung der Magnetfelder. Die müssen so dicht sein, dass die Elektronen nicht entkommen können und zusammenbleiben, um die immaterielle Kathode zu bilden. Das nennt sich dann IEC: inertial electrostatic confinement.

Dr. Bussard behauptet nun, dass seine Firma einen Prototypen diese Maschine für ein paar Millionen Dollar an Forschungsmitteln gebaut hat. Das Gerät, genannt Fusor, sieht etwa so aus wie 3 ineinander geschachtelte Helmholtz-Spulen. Das Prinzip ist nicht neu. Schon vor 80 Jahren gab es Vorschläge für sphärische Kathoden, um Ionen einzuschließen. Auch in Los Alamos in den 50-er Jahren wurde daran geforscht. Bussards Beitrag besteht darin, die Kathode immateriell zu machen. Sie besteht nur aus freien Elektronen, die nicht schmelzen können. So einen Fusor kann man mit relativ wenig Aufwand herstellen. Nur die Hochspannungen und Stromspulen mit hohen Leistungen sind eine Herausforderung. Es gibt sogar Studenten, die das in ihrer Freizeit gemacht haben. Aber ein Fusor, der für kommerzielle Kernfusion eingesetzt werden kann, hat dann doch höhere Anforderungen. Anscheinend ist auch die Größe des Geräts ein wichtiger Faktor. Nach den Berechnungen der EMC Corporation müsste ein 3 m großer Fusor dicht genug sein, um die Elektronenwolke im Inneren festzuhalten. Der Prototyp bei EMC war nur 30 cm groß.

Dieses 3 m große Gerät würde 200 Millionen US Dollar kosten und dauerhaft Strom produzieren. Bussard behauptet in seinem Vortrag, dass ein 3 m großer Fusor 100 Megawatt Leistung erzeugen könnte, genug für einen Stadtteil. Der notwendige Treibstoff ist unendlich verfügbar auf der Erde. Das IEC Verfahren ist sogar geeignet für Proton-Bor Fusion bei der nur geladene Teilchen (Alphateilchen) entstehen, die direkt in Strom umgewandelt werden können ohne den Umweg über Hitze zu gehen, wie bei heutigen Atomkraftwerken und bei den anderen geplanten Fusionskraftwerken. Zu allem Überfluss geht das alles ohne nennenswerte Radioaktivität. Es werden zwar Atomkerne verschmolzen, aber der Proton-Bor Prozess erzeugt nur Alphateilchen, keine Neutronen, wie die Kernspaltung oder die Deuterium-Tritium Fusion der Tokamaks. Da die Kernreaktoren vor allem duch Neutronenbestrahlung radioaktiv werden, entfällt sogar dieser Nachteil. Das ist keine kalte Kernfusion im Wasserglas. Das ist echte Technik mit bekannten physikalischen Effekten. Man könnte innerhalb von 10-20 Jahren von Kohle und Erdöl wegkommen und saubere Energie erzeugen. Fusor-Kraftwerke sind kleiner und billiger, als Kohle- und Kernkraftwerke und würden eine dezentrale Energieversorgung erlauben in der jeder Stadtteil sein eigenes Kraftwerk hat.

Bleibt die Frage: wo ist der Haken? warum gibt es das noch nicht?

Dr. Bussard sagt, dass es keinen Haken gibt. Ich kann nicht beurteilen, ob die Technik funktioniert. Es hört sich physikalisch vernünftig an und es gibt auch viele unabhängige Fusor-Entwicklungen. Es müsste nur jemand ein paar hundert Millionen Dollar investieren, um das erste Kraftwerk zu bauen.

Und da liegt laut Bussard das Problem. Jeder, der hundert Millionen Dollar/Euro investiert fragt erst mal ein paar Experten, ob das Projekt machbar ist. Und alle, die gefragt werden sind irgendwie verbunden mit der klassischen Tokamak Fusionsforschung. Der nächste Tokamak Forschungsreaktor (JET), der in Frankreich gebaut werden soll hat ein so großes Budget, dass eine ganze Generation von Fusionsforschern davon leben, arbeiten, promovieren, habilitieren, profilieren und emeritieren wird. Niemand hat ein Interesse durch ein positives Gutachten die Forschungsgelder der nächsten 20 Jahre zu gefährden. Deshalb sind alle Gutachten zumindest zurückhaltend, aber nie uneingeschränkt positiv. Bussard jedenfalls hat die Finanzierung der nächsten Stufe in den vergangenen Jahren gesucht und nicht gefunden. Er sag, dass er mit 79 Jahren inzwischen zu alt ist, um sich gegen die Widerstände durchzusetzen. Seine Firma hat ein paar Millionen vom DoD bekommen, v.a. von der Navy, weil die Navy immer an kompakten Stromquellen (für Flugzeugträger und U-Boote) interessiert ist. Aber alles was darüber hinausgeht wäre eine politische Entscheidung und da gibt es Widerstände im Establishment, angefangen von den Fusionsexperten, bis zu den Ölfirmen und Energiekonzernen.

Das alles klingt nach Verschwörungstheorie. Vielleicht ist es ja auch wahr. Vielleicht ist der Vorschlag technischer Unsinn. Vielleicht ist es die Lösung der Energie- und Umweltprobleme. Die US Navy hat EMC finanziert. Vielleicht erfahren wir in 20 Jahren, dass US Atom-U-Boote ab 2015 mit IEC-Fusion fuhren, statt mit Kernspaltung.

Der finanzielle Aufwand um Gewissheit zu bekommen ist viel geringer, als das was sonst in Fusionsforschung gesteckt wird, sogar geringer, als die jährliche Förderung alternativer Energiequellen in Deutschland. Ein Technologieland, wie Deutschland könnte zumindest die wenigen Millionen Euro investieren, um einen 1 Meter Prototyp zu bauen. Auch wenn man damit die Arbeit von Bussard noch mal wiederholt. Und Deutschland hat eine Physikerin als Bundeskanzlerin. Da könnte man auf höchster Ebene die Chancen erkennen.

Deshalb meine Bitte von Physiker zu Physikerin: liebe Frau Merkel, sehen Sie sich in einer freien Minute mal IEC-Fusion an. Vielleicht ist es ein Hoax eines alten Mannes, vielleicht aber die Lösung der Energieprobleme und der Weg zur Einhaltung ihrer Klimaziele.

Links:
- "The Advent of Clean Nuclear Fusion: Super-performance Space Power and Propulsion", Robert W. Bussard, Ph.D., 57th International Astronautical Congress, October 2-6, 2006
- "Should Google Go Nuclear?", November 9, 2006, 1.5 MB (revised August 30, 2007)
- askmar.com: IEC Fusion
- Tom Ligon’s Link and Resource List for the Bussard Fusion Reactor

Soweit der Stand der Dinge im Sommer 2007.

Letzten Monat, am 6.10.2007 ist Dr. Bussard an Krebs gestorben.

Zwei Monate zuvor ist der Forschungsvertrag für Dr. Bussards Firma EMC verlängert worden.

Es sieht so aus, also ob die US Regierung da an der falschen Stelle gespart hat. Die US Navy hat über 11 Jahre 20 Mio Dollar spendiert und keine Veröffentlichungen zugelassen. Ende 2005 ist der Forschungsauftrag ausgelaufen. Seit 2006 veröffentlich und spricht Dr. Bussard über die Technologie. Hätten sie ihn weiter finanziert, hätte die amerikanische Industrie vielleicht 10 Jahre Vorsprung gehabt. Aber Vorträge, wie der bei Google haben das Interesse von Physikern in aller Welt auf dieses Thema gelenkt. Innerhalb von wenigen Jahren werden andere Nationen, vielleicht auch die Industrie in diese Technologie investieren. Und vielleicht tritt ja der unerwartete und unwahrschinliche Fall doch ein, dass eine neue Technologie weltweit die Energieprobleme löst. Dann könnte man fossile Rostoffe besser verwenden, als sie zu verbrennen und Kernkaftwerke mit radioaktiver Strahlung blieben eine Randnotiz im Geschichtsbuch.

Weblin has what IBM needs

IBM searches the path to the 3D Web of the future. The current initiative tries to make the borders between virtual worlds more transparent and allow avatars to move between worlds. But what IBM really searches are the standards, which unify the Web of the future like HTTP and HTML did for the current Web. To let avatars hop between worlds is nice. You can keep users occupied a very long time by selling them clothes and items, with chat and you can earn much money with gimmicks and vitual gadgets. This is great for MTV, for entertainment and game companies, but not the way of IBM.

What IBM really wants is the business foundation of the future. Today IBM earns money with consulting and services based on Open and Web technologies: HTTP, XML, Java, Linux. Wanted is the architecture of the next net. Not at the level of bits, fiberptics and routers, but at the level that users see, where they click and navigate, where they spend their time, how they work, communicate, design, and create value.

What used to be AOL, Compuserve, Minitel, and BTX are todays virtual worlds. They where closed and separated worlds of content. Then came the Internet to end users in the form of the Web. The Web was simpler, distributed, without a central control like a grass roots movement. But more important: you can create and claim private spaces, which you can control entirely for the benefit of your business. There is no need to put services or content on other people's servers. You can set up your own services and they become part of the Web. The base technologies are simple and extensible. It was easy to learn, to accumulate know how, to create services, and sell them to business customers, who in turn produce the products we all consume.

IBM is looking for the base technologies for the next level. A 3D Web in which we can live and work. A 3D Web which is based on simple, extensible technologies. A distributed 3D Web without limits for businesses.

At the risk of repeating myself: this foundation is a combination of
- virtual presence with a
- unique location mapping,
- distributed storage for user identities
- including avatars from different words and
- multiprotokol clients, which
- allow users to move between
- distributed rooms of a 2D/3D Web from
- simple chat rooms on Web pages to
- regions of virtual worlds.

The effort to connect the Linden grid with an IBM grid is mainly driven by the need to protect assets and secure communication. Not a simple process in the Linden-derived technology base and definitely worth a press release when achieved. But the same would be much easier based on a established distributed messaging standard (e.g. XMPP, but not necessarily) combined with location mapping and distributed identity storage. Simple, not as sophisticated 3D-wise. But sophistication will come. Simple, distributed, extensible, partially ownable is the key now.

Links:
IBM Takes Second Life Behind Firewalls
Virtual Presence
Virtual Presence Primer
Virtual Presence Location Mapping
Webmobs Manifesto

_happy_coding()

Weblin hat was IBM sucht

IBM sucht einen neuen Weg ins 3D Web der Zukunft. Bei der aktuellen Initiative geht es darum die Grenzen zwischen Virtuellen Welten durchlässiger zu machen und Avatare das Wechseln zu ermöglichen. Aber was IBM wirklich sucht sind die Standards, die das Web der Zukunft so vereinheitlichen, wie HTTP und HTML das Web geeint haben. Avatare zwischen Welten hüpfen lassen ist nett. Damit kann man viele User lange Zeit beschäftigen, Avatare einkleiden, Items verkaufen, Chatten, viel Geld mit Gimmiks verdienen. Das ist toll für MTV, für Entertainment- und Gamecompanies.

Aber was IBM wirklich sucht ist die Businessgrundlage der Zukunft. Gesucht ist die Architektur des nächsten Netzes. Und zwar nicht auf der Ebene von Bits, Fiberoptics und Routern, sondern das was User sehen, worauf sie klicken, womit sie navigieren, wo sie sich aufhalten, wie sie arbeiten, kommunizieren, designen, Werte schaffen.

Was früher AOL, Compuserve, Minitel und BTX waren, das sind jetzt die virtuellen Welten. Geschlossene, voneinander getrennte Welten. Dann kam das Internet zu den Endusern in Form des WWW. WWW war einfach, verteilt, ohne zentrale Steuerung, basisdemokratisch. Aber was noch viel wichtiger ist: man konnte eigene Bereiche abstecken, die man komplett kontrollieren konnte ohne Inhalte und Dienste bei anderen aufzuspielen. Die Basistechnologien des WWW sind einfach und erweiterbar. Man konnte lernen, Wissen aufbauen, später Dienste schaffen und an Firmenkunden verkaufen, die damit die Produkte herstellen, die wir alle konsumieren.

IBM sucht die Basistechnologien für die nächste Stufe. Ein 3D Web in dem man leben und arbeiten kann. Ein 3D Web dass auf einfachen Technologien basiert. Ein verteiltes 3D Web ohne Grenzen.

Auf die Gefahr mich zu wiederholen: diese Grundlage ist
- virtuelle Präsenz mit einem
- einheitlichen Location Mapping,
- verteiltem Storage für User-Identitäten (einschliesslich Avataren) und
- Multiprotokoll-Clients, die sich in einem
- verteilten 2d/3d Web aus unterschiedlichen Räumen von
- einfachen Chaträumen auf Webseiten bis zu
- virtuellen Welten
bewegen können.

Links:
Bewegungsfreiheit zwischen virtuellen Welten.
Webmobs Manifest
Virtuelle Präsenz
Virtual Presence Primer
Virtual Presence Location Mapping

_happy_coding()

Chinas Technologie

Nachtrag zu China im Artikel Die Singularität fällt aus.

Barcamp Berlin 2007

Schon wieder Barcamp, schon wieder interessant. Viele gute Leute, viel gelernt und Session über Virtuelle Präsenz gehalten, Titel:

Virtuelle Welten - Virtuelle Präsenz
Walled Gardens - Open Skies

Stichworte: Gemeinsame Aufstellung relevanter virtueller Welten (VW), Trend zu verbundenen VW, Second Life Grid Initiative, Analogie zwischen Instant Message (IM) Chats und virtuellen Welten.

These: In der Absicht abgeschottete virtuelle Welten ("Walled Gardens) zu öffnen, schlagen mehrere Hersteller vor, nur einen Klienten und ein Protokoll für verschiedene VW zu verwenden. Jeder Hersteller favorisiert dabei sein eigenes System. Das 3D-Web der Zukunft droht zu fragmentieren durch administrative und technische Grenzen, wie schon der IM Markt und im Gegensatz zum Web, dass auf einer gemeinsamen Technik basiert. Es wird viele VW mit konkurrierenden Protokollen und Features geben. Eine Möglichkeit dieses 3D-Web doch zu vereinigen könnte darin bestehen, alle Welten durch Multiprotokoll-Klienten (ähnlich multiprotoll-IMs) unter dem Dach eines User Interfaces zu verbinden. Bei fortschreitender technischer Entwicklung wird es bald möglich sein, z.B. einen Second Life Klienten als Protokollmodul in einem Multiprotokoll-VW-Klienten zu integrieren, wie das heute schon bei IMs Standard ist. Das verbindende Element des 3d-Webs könnte das URL-Mapping sein, dass einer Web-URL einen World-Server zuordnet. Das URL-Mapping sollte deshalb so flexibel sein, dass neben XMPP-Chaträumen zum Chatten auf Webseiten später auch SL-Regionen oder Metaplace-Welten als Kommunikationsräume verwendet werden können. Dabei ist zu erwarten, dass sich heutige Chaträume von "unten" der Vielfalt und den technischen Möglichkeiten der VW annähern. Chaträume boten vor kurzem nur Nicknames. Virtual Presence (weblin) heute aber auch schon animierte Avatare in Chaträumen. Bald sind zusätzliche Objekte zu erwarten. Daraus könnten sich eine 3D-Szenen und 3D-Inhalte ergeben, die sich dann ähnlich wie heutige virtuelle Welten darstellen.

Tafelbild:
(wird nachgeliefert)

http://barcampberlin.pbwiki.com/
http://www.virtual-presence.org/

More virtual spaces for Web pages

I just read about Ogoglio in Virtual Worlds Weekly. Ogoglio is a relatively new project, which creates virtual spaces in web pages with web technologies. There are already Media Machines, Metaverse, Areae with Metaplace, and others in the same "area", some with millions of venture capital. This seems to be the time of of virtual worlds in web pages. It remembers me of the VRML/Blaxxun times and I expect a Blaxxun descendant to come forward soon with a similar concept.

So, here comes a new category of systems, which are very close to virtual presence (VP). The category of
- web-based-interconnected-virtual-spaces (WIVS). It joins the categories of
- chat-on-web-pages-browser-plugins (CWP) and
- chat-on-web-pages-iframe-embedded (CWI) systems. All very close to the
- web-based-virtual-presence (WVP), weblin style.

I am very curious which concept prevails in the long run:
1. I do not expect a big future for iframes, only as a demonstrator and for special purposes.
2. Chat plugins are a bit nineties. Most are missing avatar and 3D perspectives, which are a must currently.
3. Spaces in the web page, especially, if interconnected are technically cool, they are the next step after walled gardens like WoW and SL. They get much attention recently also from VC. But they live with the drawback that the content must be created from scratch. There VRML ancestors failed because of the content problem despite big money even in 2000. Still, there are chances, because the time of avatars and 3D has come.
4. They are all strong competition to weblin's concept of "the web already is the virtual world" (WVP).

The verdict: I bet on a combination of 2.-4. Something like weblin as a browser plugin or completely integrated with 3D and interconnections. But in contrast to WIVS I do not expect the good old web content to go away soon. It will stay and only WVP provides a way to be present and interactive with an avatar on HTML content. Many web sites will start to offer 3D content. Some will be completely 3D. But this will take a long time, because users without the 3D browser will not be able to see it unless it's Flash of Java. There can be a seemless integration of WIVS and WVP, which enables a gradual transition from WVP to WIVS or vice versa.

WIVS gets more money currently and more attention. It is the logical extension of walled garden systems. But WVP is more general and will incorporate WIVS. A WIVS protocol will serve as a virtual presence transport protocols, just like XMPP does now. That's the technical point of view, lets see what the market decides.

_happy_coding()

VPTN 2 und 3

Endlich am Wochenende auf dem Barcamp Köln die Spezifikation für "Virtual Presence User Data" fertiggestellt. Zusammen mit "Vitual Presence Location Mapping" die Grundlage für ein globales, verteiltes und chatsystemübergreifendes VP-System. 

OpenID und FOAF sind sehr eng verwandt mit VP-Identity und können vermutlich sinnvoll integriert werden. OpenID hat ein Konzept für selektive Veröffentlichung. Das fehlt bisher bei VP-Identity und FOAF. FOAF gibt es schon lange. Es ist ziemlich weit entwickelt, hat aber nie den Mainstream erreicht. OpenID ist sehr jung, aber auf dem Weg zum Mainstream. OpenID Services könnten als VP-Identity Item integriert werden, FOAF ebenfalls. Vor allem FOAF hätte auch das Potential als VP-Identity Format. Dafür müsste man FOAF erweitern um Features, wie VP-Identity Digest. VP-Identity ist eine gute Grundlage. Mal sehen was noch kommt. 

_happy_coding()

Lessons for Big Systems

Lessons

Take load from the DB

• Finally the DB is the bottleneck.
• There is only one DB (cluster), but there can be hundreds of CPUs (web server) and caches (memcache server).
• Let the CPUs work. 10 web server CPU cycles are better, than 1 DB CPU cycle.
• Aim at 0,1 DB operations per web page by average.
• Make it F5-safe. No DB operations for page reloads. No DB for views.

Avoid SQL

• Keep all live data in memory.
• Store only for persistency, not for report generation.
• Use a quick storage, storing 50.000 items per sec is possible
• DB != SQL, there are quicker interfaces
• The index is always in memory. That's what SQL DBs are good for.
• But there are other indexes as well.

External IDs

• Do not use DB IDs externally. Map all IDs.
• Use memcache to map external IDs to internal (often DB) IDs.
• Use memcache as a huge hashtable.
• External IDs may be strings. After the mapping continue with numbers internally.

DB search loves numbers

• Everything you search for must be indexed.
• Avoid indexes on TEXT, VARCHAR. INSERT with index takes significantly longer for text.
• You may store text in the DB, but do not search for it.
• You may spend some CPU to map text IDs to numbers for the DB.

100,000 concurrent

• Imagine 1% of your users are doing the same thing in an instant.
• If it affects online users, then each task is x 100,000.
• If it affects all users then everything is x 1-10 Mio.
• Anything must be at at least 1000/per sec.
• Do maintenance all the time. There will never be a time of the day where load is so small, that you can cleanup something. Cleanup permanently.

Memcache every business object

• No object is constructed from the DB.
• Everything is buffered by the cache.
• Code with real interfaces, which can be cache-enabled later.

Code for the speed

• Code for the cache. It is there. It is essential. No way to pretend it is not just for the "beauty" of the code.
• Write beautiful cache-aware code.

Memcache frontend data

• Parsing template costs much CPU.
• Cache generated HTML fragments.

Do not overload the cache

• Not more than 10 memcache requests per script.
• If you expect many items, say a mailbos with many messages, then put a summary into a list (mailbox) object even though the same information is in the individual messages.

No statistics on the live system

• Occasionally they want statistics. Don't do it live.
• Take snapshots, take the backup. Process it somewhere else.
• Make statistics offline.

Simple SELECTs

• Use only simple SELECTs on indexed columns
• Forbidden keywords: JOIN, ORDER BY
• Structure and code must guarantee small DB results.
• Sort in the code not in the DB.
• If you really need aggregated data, then aggregate permanently. Do not aggregate on demand.

Basics and Trivialities:

Distribute everything

• Do not rely on a single server for a task.

Check all input

• Check ALL input.
• Not only query params are input.
• Cookies, HTTP header fields are also input.

SQL injection

• SQL-escape all data in SQL strings.
• Use prepared statements and variables.

Framework

• Use a real programming language.
• Use a compiled language, because the compiler eliminates errors.
• You will have errors which will wake you at night. So, reduce errors by any means, even if you like script languages.
• Simple deployment of script languages won't work anyway in the long run, because you will switch on caching and you will have to invalidate the script cache for deployment.

Yet Another Tag Cloud für Blogger

Ich habe keine Tag-Cloud in der Widget Liste von Blogger gefunden. Nur ein Label-Widget, dass alle Tags als Liste darstellt. Deshalb hier eine kurze Beschriebung, wie man die Label-Liste zur Tag-Cloud umbaut.

1. Label-Widget (Seitenelement) einfügen.

2. HTML/Javascript-Widget einfügen.

3. Im HTML/Javascript-Seitenelement:

<script src="http://www.wolfspelz.de/blogger.js"></script>
<script>BloggerTagCloud('Label1', 1.0);</script>

<style>
div.Label div.widget-content ul li { display:inline; word-spacing:-0.3em; padding:0 8px 0 0; line-height:90%; text-indent:0px; }
</style>

Das 'Label1' in BloggerTagCloud('Label1') ist die DOM-ID des Label-Widgets, normalerweise Label1 für das erste Label-Widget.

Die 1.0 ist eine Skalierungsfaktor, der die Dynamik der Label-Größen bestimmt.

_happy_coding()

Simple Remote Procedure Call

In my projects we often use remote procedure calls. We use various kinds, SOAP, XMLRPC, REST, JSON, conveyed by different protocols (HTTP, XMPP, even SMTP). We use whatever is appropriate in the situation, be it client-server, server-service, client-p2p, and depending on the code environment C++, C#, JScript, PHP.
With SOAP and XMLRPC you don't want to generate or parse SOAP-XML by hand. That's an avoidable error source. Rather you use a library, which does the RPC-encoding/decoding job. To do that you have to get used to the lib's API, modes of operations, and its quirks.
This is significant work until you are really in "complete advanced control" of the functionality. Especially, if there is only a method name with paramaters to exchange. Even more bothersome is the fact, that most such libraries need megabytes, have their own XML parser, their own network components. Stuff, we already have in our software for other purposes.
What we really need is a simple way to execute remote procedure calls

• with an encoding so easy and fail safe, that it needs no library to en/decode,
• that is so obvious, that we do not need an industry standard like SOAP, just to tell other
  developers what the RPC means.

The solution is a list of key-value pairs. This is Simple RPC (SRPC):

• request and response are lists of key-value pairs,
• each parameter is key=value
• parameters separated by line feed
• request as HTTP-POST body or HTTP-GET with query
• response as HTTP response body
• Content-type text/plain
• all UTF-8
• values must be single line (must not contain line feeds)
• request method as Method=

Example (I love stock quote examples):
HTTP-POST request body:

1. C: POST /srpc.php HTTP/1.1
2. C: Content-type: text/plain; charset=UTF-8
3. C: Content-length: 43
4. C:
5. C: Method=GetQuote
6. C: Symbol=GOOG
7. C: Date=1969-07-21

HTTP response body:

1. S: HTTP/1.1 200 OK
2. S: Content-type: text/plain; charset=UTF-8
3. S:
4. S: Status=1
5. S: Average=123
6. S: Low=121
7. S: High=125

Additional options:
1. Multiline Values:
Of course, there are sometimes line feeds in RPC arguments and results. Line feeds must be encoded using HTTP-URL encoding (%0A) or a better readable "cstring" encoding (\n). The encoding is specified as meta parameter:

1. News=Google%20Introduces%20New...%0AAnalyst%20says...
2. News/Encoding=URL

or:

1. News=Google Introduces New...\nAnalyst says...
2. News/Encoding=cstring

The "cstring" encoding replaces carriage-return (\n), line-feed (\r), and back-slash (\\). The "cstring" encoding indication, e.g. "News/Encoding=cstring" may be omitted.
2. Binary Values:
Binary values in requests and responses are base64 encoded. An optional "Type" uses MIME types to indicate the data type in case of e.g. image data.

1. Chart=R0lGODlhkAH6AIAAAOfo7by/wCH5BA... (base64 encoded GIF)
2. Chart/Encoding=base64
3. Chart/Type=image/gif

3. The Query Variant:
Even complex result values, such as XML data, must be single line. Following the scheme above, this can be done by using "base64" or "cstring" encoding. Both are not easily readable in case of XML. SRPC offers a simpler way to return a single result value: if the request is HTTP-GET with query then the result value comes as response body with Content-type. It's a normal HTTP request, but SRPC conform.
HTTP query:

1. C: GET /srpc.php?Method=GetPrices&Symbol=GOOG&Date=1969-07-21 HTTP/1.1

HTTP response (with a sample xml as a single result value):

1. S: HTTP/1.1 200 OK
2. S: Content-type: text/xml
3. S:
4. S: <?xml version="1.0"?>
5. S: <prices>
6. S: <price time="09:00">121.10</price>
7. S: <price time="09:05">121.20</price>
8. S: </prices>

4. Special Keys
There are 3 special keys defined:

• request "Method=FunctionName" (RPC method)
• response "Status=1" (1=OK, 0=error)
• response "Message=An explanation" (an accompanying explanation for Status=0 or 1)

This Simple RPC specifies exactly how RPC requests are encoded. It's just lists of key=value pairs. But still powerful enough for all RPCs we need.
happy_coding()

Wilde Zeiten

In Erinnerung an wilde Zeiten
... als Systeme in wenigen Tagen hochgezogen wurden ...
... heute dauert das nur noch halb so lang ...

- Die berüchtigte SQL-Gang

Tech Idole

Es gibt ein paar Leute, die ich wirklich bewundere:

• Robert X. Cringely wegen seinen unermüdlichen und mutigen Near-Term Vorhersagen und weil er das Gras wachsen hört. Seine Kolumne (jetzt: Blog) (jetzt: nicht mehr online) ist ein Geheimtipp für Leute, die Geld auf Technologie wetten.
• David Pulver für seine Weitsicht und die umfassenden Prognosen im Transhuman Space Setting. Es zeigt sich, dass er in vielen Dingen ziemlich richtig liegt. Das einzige was man ihm vorwerfen könnte ist, dass er 9/11 nicht vorhergesagt hat. Hätte er Jahr später geschrieben, dann hätte Negative Growth den Mars-Elevator doch zerstört.
• Douglas C. Schmidt weil dieser Mensch erstens C++ programmiert wie ein Gott und im gleichen Leben auch noch hunderte von Veröffentlichungen schreibt und viele Millionen an Drittmitteln einwirbt. Mehrere Fulltimejobs und trotzdem ein Privatleben. Das längste Resume, dass ich je gesehen habe. So unmöglich für Normalbürger, wie Half-Life 2 in 90 min.

wird fortgesetzt.

Blog Migration

Endlich hat der Blog eine neue Heimat gefunden. Das Warten hat ein Ende.