Warnung vor dem goldenen Auge

Leider ist James Bond gerade nicht verfügbar. Dass er diesmal nicht hinter dem Superschurken her ist, wird die Ergreifung desselben sicher ein wenig verzögern. Vermutlich hat er anderweitig zu tun.

Aber Spaß beiseite. Der Heise-Verlag warnt vor der Ransomeware „Goldeneye“. Diese verbreitet sich im Moment rasant durch einen Makrovirus, der in einem Excel-Dokument daher kommt. Zielgruppe sind offenbar Personalverantwortliche in Betrieben, aber es ist nicht ausgeschlossen, dass auch andere Personen auf der Empfängerliste stehen. Die Mails kommen momentan von einem Absender wie „Rolf Drescher“, aber auch darauf würde ich mich langfristig nicht verlassen. Erfahrungsgemäß werden solche leicht erkennbaren Merkmale schnell geändert, ohne dass dadurch die Gefahr geringer wird.

Besonders auffällig ist, dass die Mails laut Heise Informationen in ein Anschreiben einbauen, die gezielt auf das Empfänger-Unternehmen bezogen sind.

Als Schutzmaßnahme wird für Administratoren empfohlen, mittels der Windows-Policy-Einstellungen alle Makros pauschal zu deaktivieren. Das verhindert erfolgreich die Ausführung der Makros und damit die Infektion des Systems.

Generell ist es natürlich immer eine gute Idee, unerwartet zugesandte Mails mit besonderer Vorsicht zu betrachten. Und wenn Sie General Orumov oder Xenia Onatopp begegnen sollten, machen Sie am besten einen großen Bogen um sie. Auch wenn Xenia eine gewisse Anziehungskraft nicht abzusprechen ist 🙂

Ähnliche Artikel:

Flattr this!

Danke für den Bugreport

Kürzlich fiel mir mal wieder auf, dass ich mich für einen Bugreport bei einem User bedankt habe. Ich habe eigentlich nie darüber nachgedacht. Ich tue das einfach, es ist meine Art, denn ich bin wirklich dankbar für gute Bugreports. Er antwortete mit einem betonten „Ich habe zu danken!“, was vielleicht sogar stimmt, und auch wieder nicht. Im Grunde haben wir beide etwas von guten Bugreports.

Ein Bugreport ist nützlich

Erstens ist ein Bugreport nützlich (er sollte es zumindest sein): Ich muss nicht dreimal nachfragen, wie dieses „die Software läuft nicht“ gemeint ist, sondern bekomme deutliche Hinweise auf einen konkreten Fehler. Wenn noch ein Beispiel hinzugefügt wurde und vielleicht der Wunsch, wie es statt dessen sein sollte, dann bin ich glücklich. Und wenn dann noch die genaue Versionsnummer der Software enthalten ist und vielleicht sogar Daten zum Nachvollziehen anhängen, dann ist mein Glück kaum noch mit Worten zu beschreiben.

Ein Bugreport ist hilfreich

Zweitens helfen Bugreports mir, meine Software zu verbessern. Ich gebe zu, manchmal sitzt das Problem vor dem Monitor. Aber selbst dann bemühe ich mich, meine Software so zu gestalten, dass ein mangelndes Verständnis für mein Problem von diesem selbst erkannt und mit entsprechenden Hinweisen beantwortet wird. Ein Anwender, der mich auf so ein Problem hinweist, hat mir einen großen Gefallen getan, denn ich selbst bin offensichtlich nicht auf diese Idee gekommen.

Es ist eigentlich gar nicht so schwer, das zu verstehen. Versetzen wir uns in die Lage des Users. Wir Entwickler sind ja oft genug selbst Anwender. Jetzt gerade zum Beispiel bin ich Anwender von Firefox, von WordPress und letztlich von Ubuntu. Wenn WordPress nun diesen Artikel nicht speichern würde und ich ihn ein zweites mal schreiben müsste, wäre das ausgesprochen ärgerlich. Würde ich dann aber dem Entwicklerteam ein lapidares „Euer Scheiß läuft nicht!“ entgegen schleudern, was würde dann passieren?

Auch die Leute, die nach dem Motto „nicht gemeckert ist genug gelobt“ vorgehen, vergessen dabei, dass wir alle Menschen sind. Wo Menschen arbeiten, werden Fehler gemacht. Fehler sollten vermieden werden, aber mit Meckern allein geschieht dies nicht. In manchen Branchen ist permanente Aufmerksamkeit gefragt, da sollte man im Stellwerk nicht einfach mal Pokemons jagen, sollen die Züge doch fahren, wohin sie wollen!

Aber wenn gute Arbeit einfach ignoriert wird, wozu sollte ich mich dann noch anstrengen?

Auch ich freue mich über ein Lob. Denn „I’m only human after all“.

Ähnliche Artikel:

Flattr this!

Die Party geht ab!

Zeitraum ab Start bis zum 27.11.2016
Bitcoin-Kursentwicklung ab Start bis zum 27.11.2016

Vor etwa zweieinhalb Jahren begann ich mich für das virtuelle Geld „Bitcoin“ zu interessieren. Diese Währung ist nicht nur aus der Sicht des Softwareentwicklers interessant, da sie vollständig digital existiert. Auch die Frage, ob ich Kursentwicklungen vorauszusagen vermag, stellte sich in der Vergangenheit immer wieder. Um es kurz zu machen: Ich kann es (leider) nicht. Aber manchmal hoffte ich schon, ich hätte 2012 meine gesamten Ersparnisse in Bitcoins angelegt. Unterstelle ich ferner, dass ich tatsächlich bis heute alles behalten hätte, dann wären aus damaligen 10.000 Euro (Tagesmittel am 26.11.2012: 9,68 €/BTC) in nur vier Jahren (aktuell ca. 700 €/BTC) fast eine dreiviertel Million Euro geworden! Fantastisch, oder?

Leider habe ich vor vier Jahren noch nichts vom Bitcoin gewusst, und selbst wenn, hätte ich sicher nicht so eine Summe auf Risiko angelegt. Am Anfang sah es nämlich eigentlich gar nicht danach aus. Mit einem Eröffnungskurs am 5. Dezember 2011 von 2,24 €/BTC gestartet, ergab sich erst im März 2013 eine deutliche Steigerung. Nur ein halbes Jahr darauf ging der Kurs dann durch die Decke und erreichte weniger als ein Jahr nach dem Start sein bisheriges Allzeit-Hoch von 716,47 €/BTC (Tagesmittel). Und wenn die aktuelle Entwicklung so weiter geht, haben wir diese Marke bald geknackt.

Doch bei aller Faszination für das Medium (und den erhofften Gewinnen) muss immer auch das Verlustrisiko betrachtet werden. Im konkreten Fall, wo der Bitcoin bei „Erfindung“ im Grunde erstmal nur ein „proof of concept“ war, hätte man durchaus auch mit einem Totalverlust rechnen müssen.

Dennoch: Egal wie hoch oder niedrig die Einlage gewesen wäre, eine Kursentwicklung innerhalb von vier Jahren auf das 70-fache (das 312-fache ab dem Start vor knapp 5 Jahren) ist schon bemerkenswert.

Wir leben in spannenden Zeiten.

Alle Zahlen sowie die Grafik von https://www.bitcoin.de.

Ähnliche Artikel:

Flattr this!

Auf der Suche nach Dingen, die sich geändert haben

Auf der Suche sind viele, nicht nur Aldous Gajic. Ob den meisten wirklich klar ist, wonach sie suchen, darf bezweifelt werden. Oft weiß man es erst, wenn man es gefunden hat, obwohl man etwas ganz anderes gesucht hat.

Bei Git ist es eigentlich recht einfach. Wollen wir zum Beispiel wissen, wann diese Variable mit dem dämlichen Namen „dummy“ in das Projekt hereingekommen ist, gibt es den einfachen Befehl:

git log -Sdummy

Alternativ geht auch:

git log -G"REGEX"

wobei REGEX natürlich nur ein Platzhalter für eine regular expression ist.

Das Ergebnis ist in beiden Fällen eine Liste der Commits, die den gesuchten Text enthalten. Das wars also. „Suchet, so werdet Ihr finden!

Aber wir müssen schon wissen, wonach wir suchen wollen 🙂

Ähnliche Artikel:

Flattr this!

Coach Reflection Day

Was schreibt man über eine Veranstaltung, über die man nicht reden darf? „Was im Fight Club passiert, bleibt im Fight Club!“ So ähnlich lautet auch die wichtigste Regel am inzwischen dritten Coach Reflection Day.

Ganz so schlimm ist es natürlich nicht, denn es sind ja keine großen Geheimnisse, die dort gelehrt werden. Nur die Erfahrungen, die die Teilnehmer sich gegenseitig in den Gesprächen anvertrauen, sollen die Gruppe nicht verlassen. Das ist im Grunde nicht viel anders als ein ganz normales „non-disclosure-agreement“, eine Verschwiegenheitsvereinbarung, die ein Berater oft mit Unternehmen abschließt.

Die Idee, die Patrick Koglin nach Nordhessen importiert hat, fand am vergangenen Freitag nun zum dritten mal statt. Der Coach Reflection Day ist eine Veranstaltung, die ursprünglich im Januar 2014 von Martin Heider, Fabian Schiller und Gerald Fiesser in Fürth ins Leben gerufen wurde. Sie ist von, für und mit Menschen, die in irgendeiner Form als Coach tätig sind, sein wollen, oder einfach nur Interesse an dem Thema haben. Doch was ist es eigentlich, das einen zum Coach macht? Ist das so etwas wie ein Psychotherapeut?

Coach Reflection Day weiterlesen

Ähnliche Artikel:

Flattr this!

Argumente gegen Quellcodeverwaltung

Weil heute ja Karneval ist, mal zu was ganz anderem. Und natürlich zünftig um 11:11 h, hoffentlich geht die Server-Uhr richtig 🙂

Nachdem ich so viel über Quellcodeverwaltung geschrieben habe, wird es euch sicher wundern, wenn ich nun Gegenargumente anführe. Ich tue das nicht, um euch vom Gegenteil dessen, was ich bisher gepredigt habe, zu überzeugen, sondern um aufzuzeigen, dass diese Gegenargumente eigentlich nichts mit Quellcodeverwaltung zu tun haben, sondern meines Erachtens eher der menschlichen Natur entspringen.

Um es ganz klar zu sagen: Ich verwende SCC (Source Code Control, das englische Wort dafür) nun schon seit so vielen Jahren, dass ich mich kaum noch daran erinnern kann, wann es eigentlich begonnen hat. Ich weiß nur, dass es zunächst Visual Source Safe war, dann Subversion, dann Mercurial und nun Git.

Mein Versuch mit CVS ganz zu Beginn scheiterte glorreich, weil ich absolut nicht verstanden habe, wozu das eigentlich da ist, was da in den zahlreichen Texten so wortreich erklärt wurde. Denn es wurde nur erklärt, wie man das macht, aber nicht wozu. Das kann durchaus ein Grund sein, weshalb auch heute noch einige Kollegen der Ansicht sind, Verzeichnisse mit Versionsnummern würden vollkommen ausreichen. Damals habe ich das auch so gemacht (und fand es toll und übersichtlich). Heute bin ich froh, dass ich „dran geblieben“ bin. Ich möchte ohne ein SCC kein Projekt mehr durchführen. Oder noch deutlicher: Ich werde ohne ein SCC kein Projekt mehr durchführen! Dank verteilter Systeme wie Hg und Git würde das sogar dann funktionieren, wenn ein Kunde sich nicht zu einer Installation auf einem Server durchringen kann. Aber eigentlich gehört ein SCC inzwischen zum Standard-Arbeitsmittel einer Softwareentwicklers.

Argumente gegen Quellcodeverwaltung weiterlesen

Ähnliche Artikel:

Flattr this!

WordPress für ein Team

WordPress ist nicht umsonst ein sehr beliebtes Werkzeug, um ein Blog oder ein kleines Redaktionssystem aufzusetzen. Auch wenn es mit professionellen Systemen sicher nicht vergleichbar ist, hat es unter der Haube manche versteckte Funktion, die im Einzelfall sehr hilfreich sein kann. In diesem Artikel will ich auf zwei Aspekte eingehen, die einem kleinen Team die Arbeit sehr erleichtern können: Das Rechtesystem und die Möglichkeit, Artikel vor der Veröffentlichung zum „Review“ vorzulegen.

WordPress für ein Team weiterlesen

Ähnliche Artikel:

Flattr this!

Vater, vergib ihnen!

„Wider besseren Wissens“ zu handeln gilt gemeinhin nicht unbedingt als eine Tugend. Doch im Projektmanagement scheint es an der Tagesordnung zu sein. Und nicht nur dort.

Es ist doch so: Wenn jemand ein Projekt plant, dann weiß er oder sie zu Beginn in der Regel sofort, wann es fertig ist. Der Termin steht als erstes fest, dann kommt ein ausführlicher Projektplan, danach werden die Leute bestimmt und dann der Weg skizziert, den man gehen will. Und erst ganz am Schluss unterhält man sich darüber, was eigentlich geschehen soll und warum. Und das funktioniert ja auch alles, da muss man sich keine Sorgen machen. Klar soweit?

Der Spruch „Vater, vergib ihnen, denn sie wissen nicht, was sie tun“ wird Jesus als eine Art „famous last words“ zugeschrieben (auch wenn es dazu kontroverse Ansichten gibt, siehe Wikipedia). Dieser Spruch wird oft verwendet, um das seltsame Verhalten einer Gruppe zu erklären oder zu entschuldigen. Ich möchte diesen Spruch hiermit umdrehen und es so formulieren: „Denn sie tun nicht, was sie wissen!“ Denn im Grunde scheint doch jeder Projektmanager zu wissen, dass Zeitabschätzungen im Vorhinein nicht funktionieren, dass der festgelegte Zeitpunkt nur selten wirklich eingehalten wird.

Gut, man mag erwidern, „aber eine Urlaubsplanung wird ja auch vorher gemacht, und dann kommt es genau so wie es geplant ist“. Das stimmt in gewisser Weise. Doch betrachten wir mal die Details: Welchen Teil des Urlaubs plant man vorher, und was genau ist das, was „genau so gekommen ist“? Aha, wir verstehen! Es ist ausschließlich der zeitliche Rahmen, der bei einer Urlaubsplanung vorab geplant ist. Die Planung lautet gewissermaßen „der Mitarbeiter wird vom Tag X bis zum Tag Y nicht im Büro sein“. Das ist einfach, das kann man weitgehend sicherstellen. Zumindest wird der Mitarbeiter nicht freiwillig vor Ablauf der geplanten Zeit zurückkommen. Aber wie steht es mit Krankheiten? Das könnte den geplanten Zeitrahmen ungeplant erweitern. Na, das nimmt man dann einfach hin, „da kann man halt nix machen“.

Wenn ich also in meinen Projektplan schreibe, „der Mitarbeiter wird von Tag X bis Tag Y an diesem Projekt arbeiten“, dann wäre das sicher ein Plan, der recht einfach einzuhalten wäre. Aber da steht ja meistens noch mehr drin.

Begriffsklärung: Plan vs. Plan

Der Begriff „Plan“ ist im Deutschen leider in verschiedenen Kontexten mit unterschiedlichen Bedeutungen belegt. Ein Fahrplan zum Beispiel ist der Plan, wie gefahren werden soll. Ein Stadtplan hingegen ist eine Zeichnung, die zeigt, wie die Stadt aufgebaut ist.

Planbar vs. unplanbar

Auch die, die das Projekt durchführen sollen, wissen es. Das führt dazu, dass die Mitarbeiter bewusst zu viel schätzen, was die Manager wiederum wissen und diese dazu bringt, die abgegebenen Schätzungen nach unten zu korrigieren. Das wissen selbstverständlich auch die Mitarbeiter, so dass ihre Schätzungen noch großzügiger ausfallen, woraufhin die Manager dann noch stärker kürzen. Eine Eskalation der anderen Art, wo sich beide Positionen immer weiter auseinander bewegen, was den Mittelwert leider auch nicht verlässlicher macht.

Was also tun? Habt ihr eine Idee?

Beitragsbild: Symbolfoto (Veranstaltungsplan der AEK19)

Ähnliche Artikel:

Flattr this!

Thomas Möller: Fehler für Fortgeschrittene

Thomas Möller hält seinen Vortrag im Schlaf
Thomas Möller hält seinen Vortrag im Schlaf

Nach einer superkurzen Einführung in das Errorhandling zu den Möglichkeiten, wie in VBA Fehler abgefangen werden können, kommt von Thomas Möller sofort die erste überaus hilfreiche Empfehlung. Die Einstellung „Unterbrechen bei Fehlern“ gilt VBA-weit! Das bedeutet, wenn der User es umgestellt hat, kracht unser Code. Abhilfe schafft ein einfacher Befehl, den unsere Applikation beim Starten ausführen sollte:

Application.SetOption("Error Trapping") = 2

Da hat sich der Vortrag doch schon gelohnt!

Thomas Möller: Fehler für Fortgeschrittene weiterlesen

Ähnliche Artikel:

Flattr this!

Und weiter geht’s …

„Die EU will den geplanten Datenaustausch von Facebook und WhatsApp verhindern“ schreibt CHIP. Die EU will sich die übermittelten Daten offenbar erst mal genauer anschauen. Solange soll nichts übermittelt werden. Es ist wohl doch nicht alles so schlecht, was da aus Brüssel kommt.

Das erinnert mich an das Video „Was hat die EU jemals für uns getan“, das laut dem Europäischen Informations-Zentrum Niedersachsen den Clipwettbewerb „Europa: Erste Wahl“ gewonnen hat. Auch Patrick Stewart, bekannt als Captain Picard von der Enterprise hat einen Beitrag in ähnlicher Form veröffentlicht.

Beitragsfoto: Quelle, Urheberschaft: Accountalive aus der deutschsprachigen Wikipedia CC BY-SA 3.0, CC BY-SA 3.0 de oder GFDL, via Wikimedia Commons

Ähnliche Artikel:

Flattr this!