Last weekend happened the second “Machine Learning Prague” conference and I was lucky enough to was one of the attendees.
I’d like to recap what I learned and my experiences in this blog post. I hope this is helpful to anyone who couldn’t attend and it helps me to remember.
It’s 2017 and you might think continuous integration/delivery is everywhere. Sadly it’s not but with tools like Gitlab, Gitlab-CI and Kubernetes there is pretty much no excuse not to do it anymore. Think about it. The pain point to do proper continuous delivery is often to setup all the staging systems, connect them with your ticket system, connect it with your code repository and automate not even tests but basically your entire workflow – end to end. And this took you usually month – best case weeks. This’s terrifying! But Kubernetes and Gitlab are here for the rescue. It simplifies the setup so much that you can focus on your business.
{f5 lh-copy measure mt0-ns}
Lately I stumbled over Google’s Eddystone protocol and how it brings the word wide web to the physical world or the other way around: how it enhances physical things with the internet. This idea is nothing new: there was/is RFID/NFC or even barcodes.
What I can see as real advantage of the physical web compared to these other technologies is that you get contextual information without opening any app or touching a specific physical thing.
In my previous post about How to setup rsyslog, elasticsearch and kibana on CoreOS and AWS I used some custom scripts in order each service discovers all the required ones. E.g. I wrote my own announcement mechanism which polluted all the systemd unit files of the services. The disadvantage of my first approach is clear: it’s mixing responsibilities.
After one year working with AWS Cloudformation templates I’ve changed the way how the templates are structured. When I started I thought it might be a good idea to have everything that belongs to each other in one file. This means that this file includes Route53 entries, AutoScaling, Alarms, etc. Then I extracted Alarms and DNS entries but still Elastic Load Balancer, Security Groups and Auto Scaling Groups were defined in the same file.
While I’m working with docker I use a handful of commands: build this project, run it with certain environment variables, remove the image/container. First I tried writing shell scripts to prevent me for typing this commands over and over. But the disadvantages are clear: I had quickly a bunch of scripts and I could not commit this scripts to our VCS because all this scripts were to much coupled to my setup.
After a while thinking I came up with this solution: I have a base Makefile that includes a configuration file which is ignored by the VCS. This way everyone profit from the handy make commands like make build, make run etc. but all my colleagues can configure their own setting.
In classical companies deployments are very strong coupled with Development Cycles and they again with the availability of new features. But this coupling is only feasible when the company is small or best case one person is responsible for all of this three things. But in companies where the responsibilities are scattered across departments (Product Management, IT-Operations and IT-Development) you should de-couple the outcomes of this departments to be more flexible.
I was recently thinking about what “doing something in a simple way” actually means. “Simple” what a complex word.
When you working in the IT you hear everywhere “keep it simple”, “just do it simple”, “remove the complexity” etc. But everyone I asked explaines the meaning of this six letters differently. So what is it?
Wahrscheinlich setzen die meisten Effektivität und Effizienz gleich. Laut duden.de ist das wohl im deutschen auch nicht ganz falsch, doch bin ich der Meinung, dass sich der englische Gebrauch in Büchern wie “The Goal” auch auf die deutsche Sprache übertragen lässt und sinnvoller wäre.
Twitter Bootstrap wurde über die letzten Jahre zum beinahe Standard wenn es um CSS-Frameworks geht. Natürlich will man aber dieses anpassen, damit seine eigene Seite nicht wie das original aussieht. Hier bietet getbootstrap.com die Sparte Customize an, jedoch kann man diesen Vorgang leider nicht versionieren. Die Alternative ist das Repository zu forken, jedoch kann es sein, dass man dann nicht mehr upgradefähig bleibt.
Hier halte ich es radikal: Ein Backlog-Item ist Done, wenn es automatisiert und manuell getestet wurde, die Akzeptanzkriterien erfüllt UND vor allem live ist.
I thought about how can we make continuous deployment more valuable for other departments besides research/development. Often the effect to get features faster doesn’t appear when you develop things from scratch because you have to build also some basics. The development cycle get longer without big notice. But big cycles come always with big batches of work when the deployment comes along and this tends to big trouble.
Während der FrontTrends 2013 in Warschau lernte ich Gregor Martynus kennen und erfuhr etwas über zwei Ideen: noBackend und Dream Code Development. Die Kurze Diskussion und der Vortrag machten mich Neugierig mehr darüber zu erfahren, zumal ich die Vision bei dem kurzen Gespräch auch nicht ganz erfassen konnte. Deshalb hatte ich mir im Nachgang auch den Talk von Jan Lehnardt (http://nerds.fm/p/nfm-006-jan-lehnardt/) angehört in dem ebenfalls auf beide Themen eingegangen wird und ich kann jedem ebenfalls diesen Talk empfehlen.
In letzter Zeit sind mir einige Gedanken zum Thema Requirements durch den Kopf gegangen. Was sind Requirements und gibt es für Anforderungen eigentlich nur die eine Richtung immer mehr von einem System zu verlangen? Wenn man die Literatur befragt [3] findet man folgende Definition zu Requirements:
To develop large scalable JavaScript projects you need the right setup. You can use a tool like yeomen to avoid boring setup effort. But in many projects you can’t use such tools (maybe you have to work with windows) and therefore you need to set up everything by yourself. In this blog post I will summarize what tools and frameworks I use to develop JavaScript efficient.
Vor einiger Zeit hatte ich das erstmal von einer neuen Idee, dem so genannten Commit Driven Development gelesen und mir in letzter Zeit einige Gedanken dazu gemacht.
Idee
Wie bei TDD/BDD überlegt man sich die nächste Tätigkeit im Vorfeld und formuliert daher seine nächste Commit-Message bevor man mit der Entwicklung beginnt.
Der Nutzen ist der selbe, wie auch bereits bei TDD. Man muss sich vorab in weiterhin sehr kleinen Schritten klar darüber sein, was man als nächstes umsetzen will. Selbstverständlich werden dadurch auch die Commit-Messages sehr wahrscheinlich deutlich qualitativ Aussagekräftiger. Die Konzentration auf den Arbeitsfortschritt ist ebenfalls klarer und der Entwickler wird stärker dazu angehalten öfter einzuchecken, was zu einer früheren Integration führen kann (bei SVN) auf jeden Fall jedoch zu einer besseren Nachvollziebarkeit.
Tooling
Leider existiert aktuell kein Versionskontrollsystem ein solches Vorgehen. Deshalb muss man sich vorher seine Message in einem Editor seiner Wahl vorschreiben und sie anschließend beim Commit kopieren. Ich hoffe aber, dass es bald möglich wird in Git ein Pre-Commit zu machen in dem man die Message vorformulieren kann.
Auswirkungen von Altlasten auf die Neuentwicklung von Features.
Altlasten in Softwaresystemen sind beinahe immer alte Anforderungen, die von anderen Personen vor längerer Zeit umgesetzt wurden. Trotz Dokumentationen in Form von JIRA-Tickets, WIKI-Einträgen und Testdokumentation ist es sowohl für Softwareentwickler als auch für das Anforderungsmanagement kaum möglich all diese Informationen in adäquater Zeit auszuwerten, um ein neues Feature kostengünstig liefern zu können.</p>
Die in der Praxis gängige Herangehensweise, um dieses Problem zu lösen ist daher einfach nachzuvollziehen: Man versucht möglichst nichts an der bestehenden Funktionalität zu ändern (d.h. der Softwareentwickler versucht bestehenden Code nicht zu verändern) und fügt seine neuen Änderungen einfach hinzu. Dieses Vorgehen funktioniert bei den ersten Änderungsanfragen auch wie gewünscht. Nach einiger Zeit stellt sich jedoch eine Situation ein, die es unabdingbar macht bestehenden Code anzufassen. Spätestens, wenn neue Anforderungen im Widerspruch zu alten stehen. Dies ist der Knackpunkt an dem nun auch alle alten Überlegungen mit bedacht werden müssten, um den Überblick über das System beibehalten zu können. Das Produktrisiko steigt enorm an und die QA-Phase verlängert sich deutlich stärker als nur linear (alte Anforderungen müssen "erforscht" und intensiv nachgetestet werden).
Folge: Die Kosten für Neuentwicklungen steigen rasant an, jedoch sind die eben genannten Punkte den Auftraggebern oft nicht transparent.
Warum man ein System nicht vorab so planen kann, dass es auf alle Eventualitäten erweiterbar ist.
In klassischer Softwareentwicklung ist eine Strategie gegen das Altlastenproblem die Software so zu planen, dass das Altlastenproblem nie entstehen wird. Das heißt, dass die Software ohne Änderung bestehender Softwareteile ewig erweiterbar bleibt. Dass dies ein reiner Wunschgedanke bleibt, ist spätestens mit einer fachlichen Anforderung belegt, die im Widerspruch zu bestehenden, und bereits umgesetzten Anforderungen steht. Aus Geschäftsstrategischer Sicht ist es einleuchtend, dass eine solche Situation in einer schnelllebigen Welt sehr oft eintreten kann. Einen statischen Plan zu entwickeln steht auch im gravierenden Widerspruch zur dynamischen Komplexität, die die geschäftliche Situation hier deutlich besser abbildet (siehe auch “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum: Successful Large, Multisite and Offshore Products with Large-scale Scrum”, Craig Larmen und Bas Vodde).</p>
Wie man sich von Altlasten befreit und Agilität erreicht.
Wie aus dem ersten Punkt hervorgeht ist es sehr einfach neue Altlasten aufzubauen. Welche Lösungen schlägt nun die Wissenschaft und Praxis vor, um das Altlastenproblem zu lösen?</p>
Die einstimmige Meinung unter agilen Softwareentwicklern ist, sich der Tatsache bewusst zu werden. Wenn man sich im klaren darüber ist, dass Softwaresysteme über die Zeit fehlerhaft und schwergewichtig werden, kann man Maßnahmen umsetzen, die das kontinuierlich abmildern.
Dazu gehören folgende Punkte:
1) Testgetriebene Softwareentwicklung (Test-Driven Development, Jeff Langr, http://pragprog.com/magazines/2011-11/testdriven-development, Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larmen und Bas Vodde)
2) Spezifikationen anhand von Beispielen (Specification by Example, Gojko Adzic)
3) Kontinuierliche Upgrades von eingebundener Fremdsoftware
4) Die einfachste Lösung umzusetzen, die die Anforderung erfüllt (“You Ain’t Gonna Need It”, http://de.wikipedia.org/wiki/YAGNI)
Wie äußern sich diese Maßnahmen mittel- bzw. langfristig aus monetärer Sicht?
Ad 1) Testgetriebene Softwareentwicklung ist trotz seines Namens nicht gleichzusetzen mit Software zu testen ("Test-first coding is not a testing technique", Ward Cunningham). Vielmehr führt es implizit zu einer jederzeit änderbaren Software, durch das kontinuierliche schreiben von automatischen Tests und dem noch wichtigerem kontinuierlichem Refactoring des neu geschriebenen Codes. Zusammengefasst: Die Kosten für Neuentwicklungen bleiben über die Zeit relativ konstant.
Ad 2) Wenn Anforderungen mit klaren Beispielen dokumentiert sind, werden diese schneller verstanden. Missverständnisse werden reduziert und die rückblickende Information was umgesetzt wurde ist klarer. Ebenso lassen sich Beispiele einfach automatisiert testen, wodurch Anforderungen kontinuierlich qualitativ gesichert werden können, ohne zusätzlichen Kostenaufwand über die Zeit.
Ad 3) Veraltete Fremdsoftware führt langfristig dazu, dass keine Softwareentwickler mehr gefunden werden, die mit diesen Versionen arbeiten können. Das Umsetzen neuer Features wird bei alter Fremdsoftware also verlängert, wodurch die Kosten steigen.
Ad 4) Das Feature wird so umgesetzt wie gefordert, aber auch nicht mehr. Der Aufwand wird auf das nötigste reduziert und Kosten für Planungs-Overhead werden obsolet. Der Return of Investment steigt.
Warum das eine kontinuierliche Tätigkeit bleiben muss
Refactoring ist keine Tätigkeit, die in einem Entwicklungszyklus erledigt werden kann, sondern es ist eine kontinuierliche Tätigkeit. Man kann diese Aufgabe am besten mit der Büroreinigung vergleichen: Würde man das Büro nur einmal im Jahr reinigen, hätte man auch hier einen deutlich höheren Aufwand und das Unbehagen in der übrigen Zeit wäre bei allen Beteiligten nach kurzer Zeit sehr groß.</p>
Durch den agilen Hype werden immer mehr Tools (hauptsächlich Softwareprogramme) in Frage gestellt, die bisher zum erledigen vieler Aufgaben eingesetzt wurden. Die Frage ist, wieso passiert dieser gedankliche Wandel und was ist die Ursache, die dazu führte?
These: Tools (z.B. Softwareprogramme) haben die Absicht die Arbeit zu beschleunigen.
Meiner Meinung nach ist die grundlegende Idee Tools einzusetzen, wiederkehrende Arbeiten zu beschleunigen. Selbst die Erfindung des Computers war eben dieser Intention entsprungen. Denn Konrad Zuse wollte bestimmte Rechnungen beschleunigen, da diese sehr monoton und mühselig waren.
Dieses initiale Ziel bei der Einführung von beliebigen Tools vergessen wir allzu oft. Häufig werden Tools nicht anhand eines Beschleunigungsvorteils ausgewählt, sondern anhand der Funktionen, die uns das jeweilige Tool bietet; egal ob wir diese Funktion benötigen oder nicht. Daraus ergibt sich meine zweite These:
Ein qualitativ hochwertiges Tool muss den Prozess unterstützen und nicht der Prozess das Tool.
Das heißt im ersten Schritt gilt es die Arbeitsweise und den Prozess zu verbessern. Erst im zweiten Schritt wird diese Arbeitsweise durch ein Tool nochmals beschleunigt. Was allzu oft passiert ist jedoch, dass ein Tool eingesetzt wird in der Hoffnung es würde den Prozess per se beschleunigen. Das Gegenteil ist dann der Fall, d.h. die Arbeit wird dadurch behindert, dass die Arbeitsweise mit dem Tool erst erlernt werden muss. Das jeweilig eingesetzte Tool, ob es nun in Form einer Software oder eines Blatt Papiers und Stift in Erscheinung tritt, darf somit per se kein Selbstzweck sein. Woran sich sofort meine dritte und letzte These anschließt:
Ein Tool muss den gesamten Arbeitsfluss beschleunigen und nicht nur die Arbeit einzelner.
Dieser Punkt ist am schwersten zu evaluieren und auch nur noch anhand eines Beispiels zu erklären.
Angenommen zwei Personen Anton und Berta arbeiten zusammen. Anton wohnt in Europa und Berta in Australien. Falls Anton für sich feststellt, dass er am schnellsten Texte handschriftlich verfasst, die aber von Berta gegen gelesen werden müssen, behindert das Tool "Papier+Stift" möglicherweise den Gesamtfluss. Hier ist nun zu prüfen, ob eine E-Mail den Prozess beschleunigt oder nicht. Für jeden ist einsichtig, dass es sehr wahrscheinlich ist, dass Anton für eine E-Mail kaum um einen derartig großen Faktor länger benötigen wird, dass sich der Einsatz eines PCs als Tool anstelle von Papier und Stift nicht lohnen würde.
Für ein beliebiges Tool eines komplexeren Ablaufs (Prozess) ist eine solche Fragestellung nicht so einfach bzw. so pauschal zu beantworten. Genau in solchen Fällen machen wir gerne den Fehler und suchen ein Tool anhand der Features und nicht anhand unserer Ziele aus. Doch auch hier sollte der Grundsatz "You ain't gonna need it" (YAGNI) beherzigt werden.
Wenn man den deutschen IT-Arbeitsmarkt eine Weile beobachtet fällt auf, dass "hippe" Technologien und Start-Ups vermehrt im Norden Deutschlands zu finden sind. Im Süden jedoch ist die Enterprise-Welt zu Hause.
Doch was führt zu dieser örtlichen Trennung und wozu könnte sie langfristig führen?
Gründe
</p>
Meine These: der Norden Deutschlands (die Region um Berlin) ist finanziell ein günstigerer Standort verglichen mit dem Süden Deutschlands um München oder Stuttgart.
Dieser einfache Grund führt unweigerlich dazu, dass viele Start-Ups sich im Norden um Berlin niedergelassen haben. Diese These trifft jedoch nicht auf alle nördlichen Regionen zu. Beispielsweise Hamburg. Doch Hamburg verbindet den aufstrebenden Flair Berlins mit dem Klischee der Münchner-High-Society. Diese ausgesprochene Mischung zieht ebenso viele Jungunternehmer in die nördliche Stadt.
Junge IT-Unternehmen können nur bestehen, wenn sie einen sehr hohen Return-of-Investment (ROI) erwirtschaften. Genau auf dieses Prinzip sind alle modernen agilen Projektmanagement-Methoden ausgelegt. Ob die eingesetzte Methodik Scrum oder Kanban genannt wird ist am Ende egal. Doch neben der Methodik haben auch die eingesetzten Technologien einen großen Einfluss auf den Erfolg oder Misserfolg eines IT-Start-Ups. Technologien, mit denen sich per se nicht schnell entwickeln lässt, da sie lange Compilezeiten erfordern oder ein umständlichen Deploymentprozess benötigen, stehen im Widerspruch zu einem hohen ROI. Um auf dem Markt bestehen zu können muss der Nutzen für den Anwender sehr hoch sein und mit geringem Aufwand erreicht werden.
Spezielle (Neue) Technologien und moderne Methoden reduzieren sowohl die Compilezeiten als auch die Aufwände eines Deploymentprozesses. Ruby, Python, JavaScript, PHP etc. sind Beispiele für diese Technologien. Doch auch Objective-C mit der guten Unterstützung von Apple durch XCode zähle ich zu diesen Technologien. Zudem werden moderne Tools benutzt, um die Arbeit zu erleichtern. SVN gehört in Start-Up Kreisen zum alten Eisen. GIT, Mercurial, Jenkins, Bash-Skripts (nicht zuletzt durch den Erfolg von Apple und Linux) sind die Wahl (UPDATE: Warum, Gründe für einen Tooleinsatz). Wer kennt in diesem Zusammenhang nicht die Streitigkeiten zwischen GIT und SVN-Nutzern? Die Antworten auf solche "hippen" technologien aus dem Entersprise-Umfeld hören sich oft so an: "not enterprise ready".
Folgen
Meine These zu den Auswirkungen ist klar: “Motivierte, meist junge, sehr gute Arbeitskräfte wandern in den Norden ab”.</p>
Wenn es Bayern und Baden-Württemberg nicht schaffen hippe Start-Ups anzuziehen, werden auch immer mehr sehr gute junge Fachkräfte abwandern. Diese fehlen selbstverständlich auch den sogenannten "Enterprise-Unternehmen". Hier sehe ich definitiv Handlungsbedarf sowohl bei den Unternehmen als auch bei den Landesregierungen, um eine ausgeglichene Gründerszene in Deutschland zu etablieren.
Acceptance tests: Selenium, Watir. I use Selenium but i read that watir should be a bit better... If you know more about please share your experience in the comments below.
Debugging: Firebug-Plug-in and the build-in capabilities in google chrome.
Performance: YSlow. Every web developer should know it.
Webanwendungen werden immer häufiger auch genutzt, um near-real-time Daten zu visualisieren. In HTML 5 ist dafür der Websocket definiert. Bis wir diesen nutzen können, müssen wir auf andere Techniken zurückgreifen. Long-Polling oder Bayeux Protocol sind hier die häufigsten. Jedoch ist es nicht immer möglich diese einzusetzten. Eine Alternative wäre eine "Infection" der Webseite mit einer weiteren Technologie, um kein traditionelles Polling nutzen zu müssen.
Das Problem.
Übertragen wir das technische monitoring Problem in ein Beispiel unseres Lebens: Ein Kollege arbeitet gerade an einem Plakat. Sobald es fertig gedruckt ist, sollen wir es abholen. Woher wissen wir, wann wir es holen sollen?</p>
Old school.
Um daten per Ajax auf herkömmlichen Weg zu überwachen erstellt man eine Funktion, die in periodischen Zeitabständen die Daten vom Server holt. Damit bekommt man häufig überhaupt keine Veränderung, muss den Server aber dennoch “stubsen” und verbraucht Bandbreite.
In unserem obigen Beispiel müssten wir in einem bestimmten Zeitintervall, sagen wir alle fünf Minuten, zu unserem Kollgen laufen und ihn fragen, ob wir das Plakat schon mitnehmen können. Wenn nicht, gehen wir unverrichtete Dinge wieder zurück auf unseren Platz.</p>
Long-Polling.
Mit Long-Polling frägt man genauso immer und immer wieder den Server an, jedoch wartet man auf dem Server auf die Antwort.</p>
In unserem obigen Beispiel würden wir also einmal zu unserem Kollegen laufen und dort solange warten, bis er mit dem Plakat fertig ist und wir es mitnehmen können. Anschließend gehen wir erfolgreich zurück zu unserem Platz, legen das Plakat ab und gehen wieder zu unserem Kollegen um wieder auf das nächste Plakat zu warten.
Infect your website.
Mit einer Ifection nutzt man den Umstand, dass auf nahezu allen Clients Plugins installiert sind. Man kann also wählen ob man eine Seite mit Adobe Flash oder einem Websocket oder Silverlight infizieren will. Ich gehe hier von Adobe Flash aus.
Wir starten also eine unsichtbare Flashanwendung, die nur eine Aufgabe hat: Sich mit einem Socket auf dem Server zu verbinden. Sobald Daten auf dem Server vorhanden sind, wird eine kleine Message “data available” an den Clienten verschickt. Dieser startet dann die Ajax-Anfragen. Der Vorteil die Daten nicht über den Socket zu senden, ist keinen Code zu duplizieren und den Dienst bei Bedarf jederzeit weglassen zu können. Sollte kein Flashplugin installiert sein, kann so einfach auf periodisches Polling zurückgegriffen werden. Der Vorteil gegenüber Long-Polling ist, dass kein Prozess blockiert wird und keine Aufwändigen Serveranwendungen wie beim Bayeux Protokoll nötig sind. Nur eine simple Socketanwendung, die die entgegengenommenen Daten verwirft und durch z.B. einem Hook-Up eine “data available” Message verschickt.</p>
In unserem obigen Beispiel würden wir zu unserem Kollegen nicht hingehen, sondern ihn vorher anrufen und diesen Anruf einfach neben uns liegen lassen. Sobald unser Kollege uns übers Telefon Bescheid gibt, dass das Plakat fertig ist, machen wir uns auf den Weg. Wäre unser Telefon einmal kaputt, könnten wir auf jeden Fall ohne Probleme wieder periodisch zu ihm laufen.
Fazit.
Websocket sind die definitiv beste Antwort auf near-real-time monitoring. Doch bis es soweit ist, dass diese Technologie in allen gängigen Browsern verfügbar ist, wird noch etwas Zeit verstreichen. Bis dahin ist eine Alternative zu nutzen. Ist man an bestimmte Servertechnologien gebunden und will trotzdem skalierbar bleiben ist long-polling oft nicht möglich. Eine Alternative bietet hier die “Infection”.</p>
Schon in der frühsten Kindheit steht jeder irgendwann vor der Frage: Bin ich ein Anhänger der Legosteine oder liebe ich doch das Spiel mit den Playmobil-Figuren mehr? Die Zeit verrinnt. Wir werden älter. Unser Spielzeug änderte sich. Es wird elektronisch und wir fragen uns mit welcher Programmiersprache wir am liebsten spielen. Objektorientiert, funktional, deklarativ oder doch eher Logikbasiert? Und wieder diese Frage an jeden einzelnen: Will ich kleine, einfache generische Grundelemente oder lieber die großen fertigen Figuren und Objekte, die aus den Fabriken kommen? Ich versuche in der Analogie der Spielzeuge zu bleiben und überlasse es euch die Parallelen zu den Sprachen zu ziehen.
Ich mag Playmobil, aber...
… wenn mir das Seeräuberschiff nicht mehr gefällt, weil sich die Welt und ich verändert haben, ist es schwer daraus ein Haus zu bauen. Natürlich kann ich mich daran machen das ein oder andere Fenster hinein zu bohren. Auch kann ich es im Spielfeld neu arrangieren und mein Bot auf Grund laufen lassen. Doch im Prinzip ist die Spiellogik mit dem Spielzeug viel zu dicht vermascht. Also versuche ich die Logik meines Spiels so weit wie möglich aus meinen Spielsachen zu halten und kaufe nur noch Figuren, die neutral aussehen und mit denen sich letztlich in allen Umgebungen gut spielen lässt. Ändert sich das Spiel, so muss ich mir jetzt keine neuen Spielsachen mehr kaufen. Klasse, oder etwa nicht? Nun, meine Spielsachen haben mittlerweile jegliche Individualität verloren und so versuche ich sie wieder anzupassen. Aus den allzu gleichen Figuren werden Individuen. Die Häuser übernehmen Aufgaben und bekommen einen Anstrich. Doch manches mal ziehen solche Anpassungen weitere Veränderungen nach sich, die ich anfangs gar nicht ins Spiel eingeplant hatte. Irgendwie fängt mir das ganze über den Kopf zu wachsen und ich frage mich: Bin ich noch Herr über mein Spielzeug oder haben sich die vielen Änderungen in meinem Spiel selbstständig gemacht? Wie bekomme ich wieder die schöne heile Welt zurück in der das eine zum anderen passt und alles da ist, wo es hingehört? Und wieso habe ich zuerst alles brav getrennt, wenn ich es nun doch wieder allzu sehr anpasse?</p>
Nun, ich versuche über den Tellerrand zu schauen und versuche das Gute anderer Spiele zu kopieren. Ich finde Legobausteine, die ganz und gar unabhängig sind. Ich kann aus ihnen Spielfiguren erschaffen und Roboter bauen, die mir mein Spielzeug individualisieren. Unglaublich, sie sind total generisch. Es gibt nur wenige verschiedene Fertigteile, die ich aber mit vielen anderen kombinieren kann, wobei das Ergebnis nur von den verschiedenen angedockten Bausteinen abhängt.
...Legosteine sind einfach zu allem zu gebrauchen.
Meine Spiellandschaft wird irgendwie wieder etwas klarer. Da sind einige Figuren und Werkzeuge mit denen ich meine Steine zu neuen Unendlich großen Gebilden zusammen setzten kann. Durch meine neuen kleinen Helfer kann ich keine Änderungen mehr übersehen, denn all die Änderungen, die zusätzliche Auswirkungen haben an die ich bisher nicht gedacht hatte, erlauben mir meine neuen Werkzeuge nicht mehr. Ich behalte also den Überblick. Ich bin wieder Herr meines Spiels.</p>
Und die äußeren Werte zählen doch!
Doch besonders hübsch sieht mein neues Spiel leider noch nicht aus. Aber dafür, ließ ich mir sagen, gibt’s Dekoratöre und Designer. Mit denen muss man nur noch abstimmen was sie an wem machen sollen. Total einfach. Fast schon zu banal.</p>
Und wenn ich ständig unterwegs bin und unterschiedliches Spielzeug zu Verfügung habe?
Dann muss ich wohl den Spieler unabhängig von meinem Spiel machen und in den Spielregeln nur noch von den Diensten des Spielers sprechen. Falls ich dann Spielfiguren zur Hand habe, die für ein Spiel passen, kann ich sofort loslegen, ganz egal wo ich bin.</p>
Und die Frage vom Anfang ist jetzt doch ganz einfach zu beantworten, oder? Meine Spielkiste ist jedenfalls mit vielen unterschiedlichen Spielsachen gefüllt, so macht's mir am meisten Spaß!
Am Ende dieses etwas anderen Informatik-Blogs wünsche ich euch allen "a lot of fun" beim spielen!
Man ist mit seinem Windows-PC in einem Netzwerk angemeldet, in dem man nur über einen Proxy in das WWW kommt. Für die Webbrowser sind freilich entsprechende Einstellungen leicht durchzuführen, jedoch gelten diese meist nur in dem entsprechendem Programm. Ein Aufruf von ping auf der Console bekommt weiterhin keinen Zugriff auf das Internet.</p>
Lösung
Mit dem in Windows XP vorhandenen Programm proxycfg lassen sich die Einstellungen entweder manuell setzen, oder vom Internet Explorer übernhemen. Beispielsweise werden die IE-Einstellungen durch proxycfg -u übernommen. Anschließend lässt sich auch ein ping auf einen Internet-Computer absetzen.</p>
Auf meinem zweiten Blog findet sich ab heute wieder eine aktualisierte Version des beliebten OpenThesaurus für das Apple Mac OS X Lexikon. Viel Freude damit wünsche ich allen Mac-Anwendern!
XSLT ist eine auf XML basierte funktionale Sprache, die zur Umwandlung von XML-Dokumenten in eine andere XML bzw. Plaintextdarstellung dient. XSLT der Version 1.1 hat sich bereits auf breiter Front durchgesetzt und wird vom .Net-Framework 3.5 und Firefox unterstüzt. Die Nachfolgerversion 2.0, die einige nützliche Funktionalitäten bietet, ist bisher noch nicht so verbreitet. Das Framework SAXON B bietet ein, unter der MPL 1.0 stehendes, Framework an, mit dem man die W3C-XSLT 2-Version verwenden kann.
Um nun XML-Dokumente ganz einfach umwandeln zu können biete ich ein einfaches ausführbares JAR-File an, das SAXON B der Version 9.1 verwendet und auf ein XML-Dokument ein XSLT-Dokument anwendet.
In Windows kann man zwar Verknüpfungen auf Verzeichnisse erstellen, jedoch sind diese eigentlich Dateien, die als Information das Zielverzeichnis enthalten. Greifen eigene Programme auf diese Links zu, erreichen sie meist nicht das Zielverzeichnis. Abhilfe schafft das Tool Junction. Denn seit Windows 2000 mit NTFS werden echte Symbolische-Links, wie man sie aus *nix kennt, unterstützt.
Testen von Software und das sicherstellen von korrekter Software in Bezug auf den Anforderungen und Anwendungsfällen. Um dieses Ziel zu erreichen, möchte man nicht zu wenig, aber auch nicht zu viel Testen. Zu viel Tests würden das Testbudged strapazieren, zu wenige könnten die Qualität der Software reduzieren.
Deshalb werden beim Testen von Methoden generell zwei Verfahren angewendet, um die Testdatenmenge zu reduzieren.
Äquivalenzklassen auf den Inputdefinitionsbereichen werden gebildet.
Bsp.: Eingabefeld Hausnummer wird aufgeteilt in gültige Eingaben den Integerwerten größer 0, den ungültigen kleiner gleich 0 und den restlichen ungültigen Eingabemöglichkeiten.
Um nicht alle Äquivalenzklassen-Kombinationen bei mehreren Inputparametern testen zu müssen wird auf die Pairwise-Methode zurückgegriffen. Es werden dabei nur alle Eingabeparameter paarweise kombiniert anstelle des Kreuzproduktes.
Am kommenden Montag startet unter www.itnotes.de ein neuer Weblog! Informatik-Themen werden hier kurz notiert oder ausführlich in einem Artikel festgehalten! In erster Linie wird es mein persönlicher Notizblog, doch fordere ich alle Leser auf Anregungen und Verbesserungen als Kommentare zu hinterlassen! Danke euch!
