Ach ja, Erfolg macht sexy. Kein Wunder, daß alle erfolgreich sein wollen. Beispielsweise will Microsoft mit seinem Windows Vista ganz dringend Erfolg haben, koste es, was es wolle. Na schön, "koste es, was es wolle" hat MS ja schon ein paar Mal erfolgreich durchgezogen, zuletzt meines Wissens nach mit dem Internet Explorer, der mit brachialer Gewalt an die Spitze der verwendeten Browser im Internet geprügelt wurde.
Schon damals war eine spannende Frage, wie der Erfolg gemessen wird. Die verschiedenen Statistiken, die zum Thema Markaufteilung bei Browsern im Umlauf sind, haben ja eine lange Geschichte. Und wenn alle Stricke reißen, muß eben kreativ mit Zahlen umgegangen werden. MS konnte so in knapp zwei Monaten sein Ergebnis verkaufter Vista-Lizenzen um knapp 22% verbessern (von 140 Millionen auf 180 Millionen), indem einfach alle Windows-Lizenzen, die Hersteller wie HP in letzter Zeit verkauft haben, als Vista-Lizenz abgerechnet werden.
Wie schon beim Internet Explorer stellt sich auch hier die Frage nach dem Warum: Weshalb ist Microsoft so erpicht darauf, erfolgreicher dazustehen als sie ohnehin schon sind? (Denn daß sie erfolgreich sind steht völlig außer Frage.) Warum muß Vista möglichst noch erfolgreicher sein, sogar auf Kosten des hauseigenen XP? Ist es nicht offensichtlich, daß Vista eben nicht so erfolgreich ist?
Es kann natürlich sein, daß die neue Spitze bei MS demonstrieren will, daß sie auch ohne Bill ganz gut zurecht kommt. Oder daß man sich keine Schlappe leisten will: Wenn Vista noch teurer war als XP, und noch massiver beworben wurde als XP, muß Vista auch noch besser verkauft werden als XP. (Erinnert mich irgendwie an Civilization: Wenn ich den Wissenschaftsetat erhöhe, bekomme ich automatisch schneller Forschungsergebnisse.)
Aber im Grunde weiß das nur Microsoft.
Dienstag, 29. Juli 2008
Sonntag, 20. Juli 2008
Mass Effect Is Evil!
Ein neues Schreckliches Spiel sucht uns heim und verschlingt Zeit wie es auch ein schwarzes Loch nicht kann: Biowares Mass Effect haut in die gleiche Kerbe wie vormals Knights of the Old Republic. Nur hat Bioware an der Präsentation massiv gefeilt: Während KotOR noch steril und stellenweise hölzern wirkte, macht Mass Effect den Eindruck eines interaktiven Films. Zwar müssen wir bei Mass Effect auf Lichtschwerter verzichten, dafür sind die Kampfsequenzen irgendwie taktischer geraten -- oder wirken zumindest so. Die Dialoge sind insgesamt sehenswerter, die Atmosphäre stimmt, kurz, allein der äußere Eindruck legt den Erwerb nahe.
Was die Story angeht: Wieder einmal muß das ganze Universum gerettet werden. Dabei ist der Spieler selbst kein Superheld nach Lucas oder Marvel, sondern nur ein ganz normaler Superspion, der seine Handfeuerwaffen an Bord seines eigenen Schiffes beim Waffenmeister kaufen muß. (Abgesehen davon ist er natürlich Kapitän des Schiffes. Das muß schon sein.) Wie bei bisherigen Bioware-Titeln kann man sich in zahllosen Nebenquests verwickeln; ob die Story reich an Verwicklungen ist, wird sich erst noch zeigen.
Ansonsten gilt: Wenn gerade genug Kleingeld zur Hand ist, und ein paar Tage Zeit sind, sollte man unbedingt mal draufsehen. (Vermutlich wird es dann sowieso gleich gekauft.)
Was die Story angeht: Wieder einmal muß das ganze Universum gerettet werden. Dabei ist der Spieler selbst kein Superheld nach Lucas oder Marvel, sondern nur ein ganz normaler Superspion, der seine Handfeuerwaffen an Bord seines eigenen Schiffes beim Waffenmeister kaufen muß. (Abgesehen davon ist er natürlich Kapitän des Schiffes. Das muß schon sein.) Wie bei bisherigen Bioware-Titeln kann man sich in zahllosen Nebenquests verwickeln; ob die Story reich an Verwicklungen ist, wird sich erst noch zeigen.
Ansonsten gilt: Wenn gerade genug Kleingeld zur Hand ist, und ein paar Tage Zeit sind, sollte man unbedingt mal draufsehen. (Vermutlich wird es dann sowieso gleich gekauft.)
Mal was Anderes: Git
Das alte RCS hatte gegenüber allen hypermodernen Client-Server-SCMs einen großen Vorteil: Wenn man mal eben eine Datei versionieren will, sagt man einfach co dateiname. Besser noch, man versioniert die Datei im Emacs, und hat keine Sorgen mehr. Das ist zwar nicht praktikabel für Multimillionendateienprojekte, wie sie heute die Regel sind, aber perfekt für Konfigurationsdateien oder "Microprojekte", also Tools, die man nebenbei mal so schreibt.
Allerdings gibt es gute Gründe, RCS nicht zu verwenden. Zusammengefaßt: Aus heutiger Sicht kann RCS nicht mehr als SourceSafe. Na schön, laut der aktuellen Dokumentation von VSS kann VSS mittlerweile mehr als RCS (nämlich Verzweigen und Zusammenführen, bekannt als Branchen und Mergen). Wie dem auch sei, RCS lebt, solange es keine Alternative für solche Microprojekte gibt.
Und hier ist sie: Git, das Fast Version Control System. Git ist anders als Subversion, anders als RCS; es ist zusammen mit Mercurial eine neue Kategorie von SCM: verteiltes SCM. Im Gegensatz zu einem Client-Server-SCM, bei dem das Repository mit allen versionierten Dateien auf einem zentralen Server liegt, hat bei einem verteilten SCM jeder Client ein vollwertiges Repository lokal vorliegen. Damit hat man jederzeit offline Zugriff auf die komplette verzweigte History des Projektes, was ein großer Vorteil ist, wenn man aus irgendwelchen Gründen tatsächlich offline arbeiten muß.
Ein Git-Repository ist schnell aufgesetzt: alles, was man braucht, ist ein Wurzelverzeichnis. Dann reicht ein git-init, und schon kann man Dateien versionieren. In der Vergangenheit waren verschiedene Aufsätze zu Git populär (z.B. Cogito), um die Arbeit mit Git zu vereinfachen. Aktuell wird Git aber als nutzerfreundlich genug angesehen, sodaß diese Aufsätze als "deprecated" gelten.
Gilt es nun, eine lokale Arbeitskopie zu erstellen, wird bei einem verteilten SCM ein beliebiges vorhandenes Repository geklont. Bei Git klont man in der Regel das Repository, in das man seine Änderungen wieder einspielen möchte. Auch das ist sehr einfach: Ein git-clone
Der Rest ist schnell erzählt: Neue Dateien werden per git-add hinzugefügt, alte werden mit git-rm gelöscht oder per git-mv umbenannt/verschoben, ein Changeset wird per git-commit ins (lokale) Repository geschrieben. Updates vom Upstream-Repository besorgt man sich per git-pull, seine eigenen Änderungen schiebt man per git-push wieder zurück (hierfür wird i.d.R. ein SSH-Zugang benötigt). Branches werden per git-branch angelegt (oder einfacher per git-checkout -b
Damit ist die Grundfunktionalität eines SCM abgedeckt. Git kann noch eine ganze Menge mehr, aber das kann man sich ansehen, wenn man wirklich mal ein größeres Projekt unter Git verwaltet. Was noch fehlt ist eine vernünftige Integration in Eclipse (das Java GIT/Eclipse GIT Plugin habe ich nicht zur Zusammenarbeit bewegen können).
Das ist alles viel zu umständlich und generell nicht praktikabel? Nun, obwohl ich als bekennender Apple-User natürlich (!) BSD vorziehe, wird der Linux-Kernel unter Verwendung von Git weiterentwickelt. Das scheint ja erstmal zu funktionieren.
Allerdings gibt es gute Gründe, RCS nicht zu verwenden. Zusammengefaßt: Aus heutiger Sicht kann RCS nicht mehr als SourceSafe. Na schön, laut der aktuellen Dokumentation von VSS kann VSS mittlerweile mehr als RCS (nämlich Verzweigen und Zusammenführen, bekannt als Branchen und Mergen). Wie dem auch sei, RCS lebt, solange es keine Alternative für solche Microprojekte gibt.
Und hier ist sie: Git, das Fast Version Control System. Git ist anders als Subversion, anders als RCS; es ist zusammen mit Mercurial eine neue Kategorie von SCM: verteiltes SCM. Im Gegensatz zu einem Client-Server-SCM, bei dem das Repository mit allen versionierten Dateien auf einem zentralen Server liegt, hat bei einem verteilten SCM jeder Client ein vollwertiges Repository lokal vorliegen. Damit hat man jederzeit offline Zugriff auf die komplette verzweigte History des Projektes, was ein großer Vorteil ist, wenn man aus irgendwelchen Gründen tatsächlich offline arbeiten muß.
Ein Git-Repository ist schnell aufgesetzt: alles, was man braucht, ist ein Wurzelverzeichnis. Dann reicht ein git-init, und schon kann man Dateien versionieren. In der Vergangenheit waren verschiedene Aufsätze zu Git populär (z.B. Cogito), um die Arbeit mit Git zu vereinfachen. Aktuell wird Git aber als nutzerfreundlich genug angesehen, sodaß diese Aufsätze als "deprecated" gelten.
Gilt es nun, eine lokale Arbeitskopie zu erstellen, wird bei einem verteilten SCM ein beliebiges vorhandenes Repository geklont. Bei Git klont man in der Regel das Repository, in das man seine Änderungen wieder einspielen möchte. Auch das ist sehr einfach: Ein git-clone
Der Rest ist schnell erzählt: Neue Dateien werden per git-add hinzugefügt, alte werden mit git-rm gelöscht oder per git-mv umbenannt/verschoben, ein Changeset wird per git-commit ins (lokale) Repository geschrieben. Updates vom Upstream-Repository besorgt man sich per git-pull, seine eigenen Änderungen schiebt man per git-push wieder zurück (hierfür wird i.d.R. ein SSH-Zugang benötigt). Branches werden per git-branch angelegt (oder einfacher per git-checkout -b
Damit ist die Grundfunktionalität eines SCM abgedeckt. Git kann noch eine ganze Menge mehr, aber das kann man sich ansehen, wenn man wirklich mal ein größeres Projekt unter Git verwaltet. Was noch fehlt ist eine vernünftige Integration in Eclipse (das Java GIT/Eclipse GIT Plugin habe ich nicht zur Zusammenarbeit bewegen können).
Das ist alles viel zu umständlich und generell nicht praktikabel? Nun, obwohl ich als bekennender Apple-User natürlich (!) BSD vorziehe, wird der Linux-Kernel unter Verwendung von Git weiterentwickelt. Das scheint ja erstmal zu funktionieren.
[Update 2009-01-14]
Die offizielle Homepage von git ist umgezogen. Git firmiert nun unter http://git-scm.com.
[/Update 2009-01-14]
Samstag, 19. Juli 2008
Ein wenig über Synergy
Mit Synergy (vormals Continuus) besitzt IBM ein weiteres gefühltes Fossil unter den Versionskontrollsystemen. Zur Erinnerung: Vor ein paar Jahren kaufte IBM mit der Firma Rational auch gleich deren ClearCase SCM mit ein. Beide Systeme können ihre Wurzeln zumindest bis in die 1990er Jahre zurückverfolgen (was ich hier nicht tue, da beide Systeme eine bewegte Vergangenheit haben). Im Moment bin ich gezwungen, mit Synergy zu arbeiten, was mein Leben nicht eben leichter macht; ich vergleiche es hier mit ClearCase, obwohl ich mit letzterem wesentlich mehr Erfahrungen habe.
Wie bei allen anderen serverbasierten SCMs, zu denen ich auch das vielgelobte Subversion zähle, ist auch by Synergy eine wesentliche Schwäche des Systems der Aufwand, der im Vorfeld betrieben werden muß: Bevor ein Projekt aufgesetzt werden kann, muß die Projektstruktur geplant werden. Wer schon einmal die Freude hatte, ein neues Projekt in Subversion oder ClearCase aufzusetzen, weiß, daß hier viele Befindlichkeiten berücksichtigt werden wollen, inklusive der Planung der späteren Nutzung.
Synergy verwirrt hier zusätzlich, da es ein eingebautes Modell für den Lebenszyklus von Software hat. Es gibt hier Projekte und Unterprojekte (die brav mit den IDE-Projekten der Entwickler abgeglichen, aber nicht verwechselt werden wollen), Versionen, Folder, Tasks und Releases. Ein buntes Sammelsorium an Abhängigkeiten erleichtern die Arbeit, sofern man sich an die Vorstellungen eines Lebenszyklus von Synergy hält. Gewarnt seien alle, die sich damit nicht im Vorfeld beschäftigen wollen: Es kann sehr eklig werden, wenn man an diesen Vorstellungen vorbei operieren will oder muß.
Bis zu diesem Punkt ist Synergy ein gewöhnliches SCM mit einem eigenwilligen, man könnte sagen ungewöhnlich unintuitiven Interface. An dieser Stelle empfehle ich allen, die es benutzen wollen, sich mit der abweichenden Semantik von "Update" vertraut zu machen, bevor sie die Arbeit von Tagen verlieren.
Warum also sollte jemand Synergy einsetzen wollen?
Die Antwort liegt im (neuen) Namen "Synergy": Das SCM ist eng mit dem zusätzlichen Produkt "Change" (und anderen Produkten aus dem Haus Telelogic) verwoben. Change requests in diesem Tool sind bis ins SCM transparent, Tasks werden direkt CRs zugeordnet, und jede noch so kleine Quelltextänderung direkt an einen Task. Damit haben die Entscheider theoretisch jederzeit Überblick über den Stand der Arbeiten, ohne den Entwickler fragen zu müssen.
Generell spielt Synergy seine Stärken erst richtig aus, wenn die Software "fertig" ist: CRs können z.B. vom Test entdeckte Fehler sein, aber auch Anforderungen des Kunden. Im Gegensatz zu anderen Systemen lassen sich die dadurch nötigen Aufwände einfacher erfassen, und die Arbeiten bis hinunter zu den einzelnen Entwicklern zuweisen. Die Gefahr, daß hier noch etwas bei der Transition zwischen verschiedenen Systemen verloren geht, ist hier durch die Integration des SCM mit dem Change Management Tool deutlich geringer.
Ein wirklich sehr schönes Feature ist das Zusammenstellen eines Releases auf der Basis von Tasks: Man entscheidet, welche Tasks mitgenommen werden sollen, und kann so einfach problematische Änderungen ausschließen.
Warum würde ich es trotzdem lieber meiden?
Die Illusion totaler Kontrolle ist möglicherweise irreführend. Wie ein Kollege vor kurzem zitierte: Die Wahrheit liegt im Sourcecode. Und die zu extrahieren bedarf es mehr als einer Aufstellung von geänderten Dateien.
Zudem ist das unintuitive Interface (beide Interfaces sind unintuitiv: sowohl das "klassische" Interface, als auch der "Developer Client"; zudem weichen Bezeichnungen für Arbeitsschritte voneinander ab, und einige Arbeiten lassen sich im Developer Client nicht durchführen) Ursache für Frustration und verlorene Arbeit. Eine Einweisung in Synergy ist also unbedingt nötig, besonders wenn Entwickler vorher mit anderen SCMs gearbeitet haben.
Und letztlich kann auch Synergy keine Wunder vollbringen: Abhängigkeiten zwischen Quelltextänderungen in verschiedenen Tasks schlagen sich nicht automatisch in Abhängigkeiten zwischen das Tasks nieder. Damit kann das Zusammenstellen von Tasks für eine Build- oder Lieferversion keine integere Lieferung garantieren, was dieses ansonsten schöne Feature wieder etwas in Frage stellt.
Im Vergleich zwischen ClearCase und Synergy würde ich mich ob der klareren und intuitiveren Versionsverwaltung für ClearCase entscheiden. Die Lizenzkosten für beide Systeme sind mir nicht bekannt; möglicherweise entscheidet in der Praxis dieses Argument. Sobald es aber um Support per Internet-Forum und Bekanntheit bei den Entwicklern geht, verlieren sowohl ClearCase als auch Synergy klar gegen Subversion; kleine Projekte mit einem kurzen Entwicklungszyklus sollten sich eher in diese Richtung orientieren, zumal sowohl bei ClearCase als auch bei Synergy dedizierte Administratoren für die Pflege des SCM notwendig (und dann auch beschäftigt) sind.
Wie bei allen anderen serverbasierten SCMs, zu denen ich auch das vielgelobte Subversion zähle, ist auch by Synergy eine wesentliche Schwäche des Systems der Aufwand, der im Vorfeld betrieben werden muß: Bevor ein Projekt aufgesetzt werden kann, muß die Projektstruktur geplant werden. Wer schon einmal die Freude hatte, ein neues Projekt in Subversion oder ClearCase aufzusetzen, weiß, daß hier viele Befindlichkeiten berücksichtigt werden wollen, inklusive der Planung der späteren Nutzung.
Synergy verwirrt hier zusätzlich, da es ein eingebautes Modell für den Lebenszyklus von Software hat. Es gibt hier Projekte und Unterprojekte (die brav mit den IDE-Projekten der Entwickler abgeglichen, aber nicht verwechselt werden wollen), Versionen, Folder, Tasks und Releases. Ein buntes Sammelsorium an Abhängigkeiten erleichtern die Arbeit, sofern man sich an die Vorstellungen eines Lebenszyklus von Synergy hält. Gewarnt seien alle, die sich damit nicht im Vorfeld beschäftigen wollen: Es kann sehr eklig werden, wenn man an diesen Vorstellungen vorbei operieren will oder muß.
Bis zu diesem Punkt ist Synergy ein gewöhnliches SCM mit einem eigenwilligen, man könnte sagen ungewöhnlich unintuitiven Interface. An dieser Stelle empfehle ich allen, die es benutzen wollen, sich mit der abweichenden Semantik von "Update" vertraut zu machen, bevor sie die Arbeit von Tagen verlieren.
Warum also sollte jemand Synergy einsetzen wollen?
Die Antwort liegt im (neuen) Namen "Synergy": Das SCM ist eng mit dem zusätzlichen Produkt "Change" (und anderen Produkten aus dem Haus Telelogic) verwoben. Change requests in diesem Tool sind bis ins SCM transparent, Tasks werden direkt CRs zugeordnet, und jede noch so kleine Quelltextänderung direkt an einen Task. Damit haben die Entscheider theoretisch jederzeit Überblick über den Stand der Arbeiten, ohne den Entwickler fragen zu müssen.
Generell spielt Synergy seine Stärken erst richtig aus, wenn die Software "fertig" ist: CRs können z.B. vom Test entdeckte Fehler sein, aber auch Anforderungen des Kunden. Im Gegensatz zu anderen Systemen lassen sich die dadurch nötigen Aufwände einfacher erfassen, und die Arbeiten bis hinunter zu den einzelnen Entwicklern zuweisen. Die Gefahr, daß hier noch etwas bei der Transition zwischen verschiedenen Systemen verloren geht, ist hier durch die Integration des SCM mit dem Change Management Tool deutlich geringer.
Ein wirklich sehr schönes Feature ist das Zusammenstellen eines Releases auf der Basis von Tasks: Man entscheidet, welche Tasks mitgenommen werden sollen, und kann so einfach problematische Änderungen ausschließen.
Warum würde ich es trotzdem lieber meiden?
Die Illusion totaler Kontrolle ist möglicherweise irreführend. Wie ein Kollege vor kurzem zitierte: Die Wahrheit liegt im Sourcecode. Und die zu extrahieren bedarf es mehr als einer Aufstellung von geänderten Dateien.
Zudem ist das unintuitive Interface (beide Interfaces sind unintuitiv: sowohl das "klassische" Interface, als auch der "Developer Client"; zudem weichen Bezeichnungen für Arbeitsschritte voneinander ab, und einige Arbeiten lassen sich im Developer Client nicht durchführen) Ursache für Frustration und verlorene Arbeit. Eine Einweisung in Synergy ist also unbedingt nötig, besonders wenn Entwickler vorher mit anderen SCMs gearbeitet haben.
Und letztlich kann auch Synergy keine Wunder vollbringen: Abhängigkeiten zwischen Quelltextänderungen in verschiedenen Tasks schlagen sich nicht automatisch in Abhängigkeiten zwischen das Tasks nieder. Damit kann das Zusammenstellen von Tasks für eine Build- oder Lieferversion keine integere Lieferung garantieren, was dieses ansonsten schöne Feature wieder etwas in Frage stellt.
Im Vergleich zwischen ClearCase und Synergy würde ich mich ob der klareren und intuitiveren Versionsverwaltung für ClearCase entscheiden. Die Lizenzkosten für beide Systeme sind mir nicht bekannt; möglicherweise entscheidet in der Praxis dieses Argument. Sobald es aber um Support per Internet-Forum und Bekanntheit bei den Entwicklern geht, verlieren sowohl ClearCase als auch Synergy klar gegen Subversion; kleine Projekte mit einem kurzen Entwicklungszyklus sollten sich eher in diese Richtung orientieren, zumal sowohl bei ClearCase als auch bei Synergy dedizierte Administratoren für die Pflege des SCM notwendig (und dann auch beschäftigt) sind.
Donnerstag, 17. Juli 2008
Nachtrag Push-Funktionalität bei mobileMe
Nachdem ich mich gestern so über Apples mobileMe geärgert habe, will ich doch noch kurz nachschieben, daß Apple heute morgen per Rund-eMail Stellung genommen hat. (Nein, natürlich nicht wegen meinem Blog, sondern vermutlich weil das Problem größere Kreise zieht.) Offiziell wird jetzt darauf hingewiesen, daß die Push-Funktionalität momentan eingeschränkt ist.
Also, alles wird gut.
Übrigens sollte ich dazu sagen, daß mein nächster Rechner trotzdem ein Mac wird.
Also, alles wird gut.
Übrigens sollte ich dazu sagen, daß mein nächster Rechner trotzdem ein Mac wird.
Mittwoch, 16. Juli 2008
Kein Push mehr
Ich hab's ja immer gesagt: Man kann Apple einfach nicht trauen. Jüngstes Beispiel: Das rätselhafte Verschwinden der Push-Funktion aus dem niegelnagelneuen mobileMe (siehe auch die Golem-Meldung dazu). Aber ist das wirklich so schlimm? Vermutlich rüsten sie die Funktion ja noch nach (in den ersten Tagen zumindest hatte ich ohnehin Probleme mit dem verbauten JavaScript, welches sich mal eben einen meiner zwei Porzessoren gönnte).
Ja, ich denke, es ist symptomatisch. Apple (oder Herr Jobs, wer weiß das schon) ist ausgesprochen geschickt, wenn es darum geht, den Leuten zu verkaufen, was sie wollen. Du willst einen total einfachen und zugleich schicken Rechner? Klar, kein Problem, aber ein paar Prozent mehr als die in China montierten Dinger kostet der dann schon. Ist ja schließlich "Designed by Apple in California". Du willst auf Dein Adreßbuch auch in der Firma zugreifen? Kein Problem, schlappe achtig Dollar oder Euro (wo ist der Unterschied?), und los kann's gehen.
Dabei ist die Sache mit dem iPhone, was in seiner dritten (!) Generation endlich auch mal UMTS benutzen kann, dafür aber schon immer primär von Anwendungen im Netz gelebt hat (!!), noch überhaupt nicht mitgerechnet.
Und dann wäre da noch mein alter Groll ob des eingestampften Newton. Den ich so geliebt habe, und den Apple einfach aus Prinzip gekillt hat. Na ja, alte Wunden. Mein Newton funktioniert immer noch: Habe ihn vor einem halben Jahr nochmal ausgegraben, neue Batterien rein, und er lief sofort. Mehr als ich von meinem ersten Palm sagen kann.
Das Lustige an der Sache ist, daß man selten jemanden trifft, der ein Apple-Produkt gekauft hat und davon nicht überzeugt ist. Mal ehrlich, mein MacBook ist einfach mal cooler als jeder Laptop-PC. Ich liebe meinen Mac!
Nur Apple traue ich nicht über'n Weg. Wenn das ein Ansporn sein kann: Seid doch einfach mal eine Nummer ... solider.
Ja, ich denke, es ist symptomatisch. Apple (oder Herr Jobs, wer weiß das schon) ist ausgesprochen geschickt, wenn es darum geht, den Leuten zu verkaufen, was sie wollen. Du willst einen total einfachen und zugleich schicken Rechner? Klar, kein Problem, aber ein paar Prozent mehr als die in China montierten Dinger kostet der dann schon. Ist ja schließlich "Designed by Apple in California". Du willst auf Dein Adreßbuch auch in der Firma zugreifen? Kein Problem, schlappe achtig Dollar oder Euro (wo ist der Unterschied?), und los kann's gehen.
Dabei ist die Sache mit dem iPhone, was in seiner dritten (!) Generation endlich auch mal UMTS benutzen kann, dafür aber schon immer primär von Anwendungen im Netz gelebt hat (!!), noch überhaupt nicht mitgerechnet.
Und dann wäre da noch mein alter Groll ob des eingestampften Newton. Den ich so geliebt habe, und den Apple einfach aus Prinzip gekillt hat. Na ja, alte Wunden. Mein Newton funktioniert immer noch: Habe ihn vor einem halben Jahr nochmal ausgegraben, neue Batterien rein, und er lief sofort. Mehr als ich von meinem ersten Palm sagen kann.
Das Lustige an der Sache ist, daß man selten jemanden trifft, der ein Apple-Produkt gekauft hat und davon nicht überzeugt ist. Mal ehrlich, mein MacBook ist einfach mal cooler als jeder Laptop-PC. Ich liebe meinen Mac!
Nur Apple traue ich nicht über'n Weg. Wenn das ein Ansporn sein kann: Seid doch einfach mal eine Nummer ... solider.
Montag, 14. Juli 2008
Warum kann Maven Dateien filtern?
Weil es mir gerade auffällt? Kennt irgendjemand einen legitimen Grund, warum Maven Resourcen für seine zu erstellenden Artefakte filtern kann? Ich betrachte mal zielspezifische Builds nicht als legitimen Grund...
Was dabei nämlich rauskommt, sind Artefakte, die für eine Zielumgebung konfiguriert sind. Und das ist ja ganz klar ein großes NoNo. Na, ganz so klar ist das wohl nicht jedem, sonst wäre es nicht getan worden, daher ein Hinweis: Der gleiche Build sollte auf den Umgebungen von Entwicklern, Testern und auf der Produktionsumgebung laufen...
Nur so als Gedanke.
Was dabei nämlich rauskommt, sind Artefakte, die für eine Zielumgebung konfiguriert sind. Und das ist ja ganz klar ein großes NoNo. Na, ganz so klar ist das wohl nicht jedem, sonst wäre es nicht getan worden, daher ein Hinweis: Der gleiche Build sollte auf den Umgebungen von Entwicklern, Testern und auf der Produktionsumgebung laufen...
Nur so als Gedanke.
Donnerstag, 3. Juli 2008
Anfangen.
Eigentlich brauche ich ja kein Blog, weil ich erstens sowieso nicht regelmäßig reinschreibe, und ich zweitens nicht so viele spannende Dinge zu schreiben habe. Aber zum Glück gibt es ja unendlich viele Blogs, von denen wieder unendlich viele praktisch nur von ihren Authoren gelesen werden (wenn überhaupt), und und außerdem gibt es noch ganz, ganz viele Blogs, in denen nicht viel steht. Sagt man.
Also kann ich diesen Blog hier genausogut nehmen, um alles, was mir so in die Hände fällt, reinzuwerfen. Was ich hiermit tue.
Soviel zum Anfang.
Also kann ich diesen Blog hier genausogut nehmen, um alles, was mir so in die Hände fällt, reinzuwerfen. Was ich hiermit tue.
Soviel zum Anfang.
Abonnieren
Kommentare (Atom)