Akka-Framework

Die Idee ein Framework zu entwickeln, dass ganz auf Messages zur Kommunikation zwischen den Komponenten basiert, ist interessant. Ich habe schon verschiedene Ansätze in der Java-Welt gesehen, z.B. Versuche, das in JavaEE mit JMS zu bauen. Letztlich ist das in der Java- und JVM-Welt ein eher selten verwendeter Ansatz, aber z.B. Erlang-Software basiert komplett auf diesem Prinzip, wobei natürlich effiziente Messaging-Mechanismen vorausgesetzt werden müssen.

Das Akka-Toolkit oder Akka Framework setzt diese Idee nun in konsequenter Weise für die Java- und JVM-Welt um, wobei es natürlich am besten in seiner nativen Sprache, also in Scala verwendet wird. Die Idee ist, eine effiziente massive Parallelisierung hinzubekommen und durch assynchrone Kommunikation die Komponenten weitestgehend zu entkoppeln. Typisch in der Scala-Welt ist es, dass man unveränderliche (deep immutable) Objekte in den Messages verschickt, um Änderungskonflikte und Fehler zu vermeiden, wenn dasselbe Objekt an mehreren Orten gleichzeitig verwendet wird. Veränderbare Objekte in den Messages sollte man vermeiden, außer man kennt das Framework und die Multithreading-Thematik sehr gut und weiss was man tut und es ist aus Performance-Gründen wirklich ein so großer Vorteil, dass der zusätzliche Entwicklungs- und Testaufwand gerechtfertigt ist. Dabei ist noch zu sagen, dass sich solches Verhalten kaum testen lässt, weil das Zeitverhalten in den Tests nie genau das im ungünstigsten Fall auf dem Produktivsystem sporadisch auftretende Zeitverhalten ist. So können in schlecht oder fahrlässig programmierten Applikationen noch Fehler lauern, die erst irgendwann auf dem Produktivsystem auftreten und die sich dann noch schlecht einordnen lassen. Genau deshalb sollte man hier auf Nummer sicher gehen und nur deep-immutable Objekte in Messages verschicken.

Für die Parallelisierung von Software gibt es grundsätzlich verschiedenen Ansätze. Mehrere getrennte Prozesse sind attraktiv, weil die Trennung sauber ist und man nur bei der Kommunikation überhaupt aufpassen muss. Dafür sind sie etwas schwergewichtiger als Threads und vor allem ist der Aufwand für de Kommunikation größer. Mehrere Threads zu verwenden hat den Vorteil, dass man dasselbe Memory benutzt und deshalb Daten einfacher getauscht werden können. Dafür steigen auch die Risiken, wenn mehrere Zugriffe auf dasselbe Objekt gleichzeitig stattfinden und mindestens einer davon schreibend ist.

Akka verwendet sogenannte Aktoren (engl. Actors), die einen Memory-Footprint von unter 1 k haben sollen, weshalb man etwa eine Million Actors durchaus gleichzeitig im Memory haben kann. Nun werden diesen Actors Messages geschickt, die etwa Methodenaufrufen in der (synchronen) objektorientierten Denkweise entsprechen, aber assynchron sind. Das heißt, dass der Sender die Message verschickt und dann fertig ist. Sie wird in einer Warteschlange für den passenden Actor eingereih und dann irgendwann abgearbietet. Nun hat so ein Actor nicht permanent einen Thread zugewiesen, sondern es gibt einen Threadpool. Actors mit einer nicht-leeren Warteschlange werden dann einem Thread im Threadpool zugewiesen und so abgearbeitet.

Share Button

Telearbeit

Durch die heutigen Möglichkeiten wie VPN, Mobiltelefonie, Videotelefonie, Chat, Telefon, EMail, Zugriff auf Fileserver u.s.w. kann man neuerdings von zuhause aus arbeiten. Wenn man die Sache genauer anschaut, ist natürlich das bezahlbare Festnetztelefon, das es schon eine Weile gibt, schon für viele Tätigkeiten schon völlig ausreichend und auch das Internet gab es schon vor 20 Jahren, als das alles noch einfacher ging, weil noch kaum jemand an Firewalls dachte, die einem das Leben für den Zugriff von außen erschweren könnten. Aber natürlich hat man heute noch mehr Möglichkeiten und hat auch 20 Jahre Zeit gehabt, darüber nachzudenken. Attraktiv ist es ja, weil man dadurch Wege spart und die Umwelt schont. Manche Firmen verzichten sogar auf einen festen individuellen Büroarbeitsplatz und lassen die Mitarbeiter 20% der Zeit von zuhause arbeiten, um Kosten zu sparen. Gerade Informatikberufe eignen sich dafür.

In der Praxis zeigt es sich, dass es oft sinnvoll ist, jeweils an dem Ort zu arbeiten, der für die aktuelle Tätigkeit am effizientesten ist. Das ist meistens der Ort, wo die Leute sind, mit denen man zusammenarbeitet, weil einfach die direkte Kommunikation immer noch viel besser funktioniert als über elektronische Medien. Es kann aber auch gerade ein Ort sein, der leiser ist als das Großraumbüro, in dem alle dauernd telefonieren oder Besprechungen am Arbeitsplatz durchführen. Es gibt auch recht viele Firmen, bei denen alle oder fast alle Mitarbeiter dauernd von zuhause aus arbeiten, wenn sie nicht gerade für die Firma unterwegs sind, z.B. für das alljährliche Mitarbeitertreffen. Solche Firmen sind dann über viele Länder verteilt und haben in jedem dieser Länder einen oder mehrere Mitarbeiter. Man sieht das häufig bei Open-Source-Firmen und mir sind viele Beispiele dafür bekannt.

Nun ist das verlockend, man kann sich die Wege sparen und sich sein Büro wirklich individuell einrichten. Aber es hat auch Nachteile. Solange die Arbeitswege nicht zu lang sind, ist es auch ein Luxus, nach Hause zu kommen und nicht mehr arbeiten zu müssen. Diese Grenze verschwimmt leicht einmal, wenn man oft zuhause arbeitet. Lohnt sich das? Die Frage kann man wohl nur individuell beantworten. Die zweite Frage, die ja niemand zu stellen wagt, ist ob denn da wirklich so intensiv gearbeitet wird. Es gibt Tätigkeiten, die von sich aus schon einen Rhythmus vorgeben oder bei denen das Ergebnis leicht messbar ist. Es gibt aber auch Tätigkeiten, die sich nicht so leicht fassen lassen. Da funktioniert diese Telearbeit gut, wenn sich die Mitarbeiter dem gemeinsamen Ziel verpflichtet fühlen und motiviert sind, ihren Teil dazu beizutragen. Man kann das durchaus lernen.

Wichtig ist an solchen Tagen, dass man auch innerhalb der eigenen Wohnung klare Abgrenzungen zwischen Arbeitszeit und Freizeit findet, auch um die Freizeit zu schützen. Ein fester Tagesablauf hilft dabei sicher und vielleicht ist es sogar gut, wenn man zwei verschiedene Rechner für die Arbeit und die Freizeit hat. Das haben in dem Fall die meisten, weil es einen Firmenlaptop und einen privaten Rechner gibt, die nur selten in einem Gerät vereinbar sind.

Hierzu ein paar andere Blogbeiträge und Artikel auf Englisch:

Share Button

iO hat zusätzliche Services

iO der Swisscom bietet jetzt die Möglichkeit, abhängig vom zugrundeliegenden Abo zusätzliche Möglichkeiten für jeweils einen Monat dazuzukaufen. Damit kann man aus der iO-App Nummern in der Schweiz oder mit dem passenden zugrundeliegenden Abo sogar Nummern aus bestimmten Ländenr in Europa und Nordamerika. Für diejenigen, die im Urlaub WLAN auf dem Zeltplatz oder Hotel zur Verfügung haben, kann das nützlich sein und Roaminggebühren sparen.

Share Button

Kovarianz und Kontravarianz

Bei Typsystemen objektorienter Programmiersprachen wird man gelegentlich mit Kovarianzu und Kontravarianz konfrontiert. Im Fall von Java stellt man sogar fest, dass bei Arrays hier ein konzepitioneller Fehler unterlaufen ist, den man heute nicht mehr wegbekommt.

Wenn man zum Beispiel die Vererbungshierarchie

Frucht -> Citrusfrucht -> Zitrone

hat, dann ist es intuitiv plausibel, anzunehmen, dass eine Liste von Citrusfrüchen sowieso immer auch eine Liste von Früchten ist. Das ist das Prinzip der Kovarianz. Wenn man mal in der Java-Welt das anschaut, dann kann eine Methode, die aus einer Liste Objekte entimmt und damit irgendwelche Berechnungen macht, durchaus gut damit leben, wenn statt der erwarteten List eine List kommt, denn was daraus gelesen wird, sind ja alles gleichzeitig auch Citrusfrüchte. Wenn diese Liste nun noch immutable ist, stimmt die Sache sogar. Dagegen würde eine List nicht funktionieren.

Nun wird es aber gefährlich, wenn die Methode dort Objekte hinzufügt. Das ist von den Sprachkonstrukten her durchaus möglich. Wenn aber nun Liste erwartet wird und stattdessen List übergeben wird und dort Orangen hinzugefügt werden, so ist das gegen die Idee einer Liste von Zitronen. Dagegen könnte man die Orangen sehr gut in eine List einfügen. Hier kommt das Prinzip der Kontravarianz zum Zuge.

Bei den Generics wurden Kovarianz und Kontravarianz einigermaßen richtig berücksichtigt, bei Arrays wurde aber nur die Kovarianz wahrgenommen, was wie erwähnt falsch ist.

In Scala sind diese Konzepte viel präziser und sauberer umgesetzt.

Siehe auch: Wikipedia

Share Button

Nokia steigt aus dem Mobiltelefongeschäft aus

Der Ausstieg fand eigentlich schon statt, als S. Elop dort die Leitung übernommen hat und den Marktanteil bei Smartphones innerhalb weniger Monate von etwa 50% auf knapp 3% reduziert hat.

Hier ein ein interessanter Artikel zu dem Thema:

Tech More: Microsoft Nokia Some People In The Finnish Tech Industry Are Pretty Upset About The Microsoft-Nokia Deal

Hier noch ein Beitrag, der am Erfolg des Deals für Microsoft zweifelt:

CIO.de

Wie es aussieht, werden sich einige neue Firmen in Finnland etablieren, die davon profitieren, dass viele hochqualifizierte Mitarbeiter bei Nokia entlassen wurden oder der Firma den Rücken gekehrt haben oder es jetzt tun werden. Mit Jolla gibt es sogar wieder einen kleinen, aber vielversprechenden Mobiltelefonhersteller.

Share Button