Die 3 wichtigsten Facebook Einstellungen

Generell lohnt sich immer der Blick in die Privatsphäre-Einstellungen von Facebook. Die 3 Punkte, die aber jeder Nutzer richtig konfiguriert haben sollte, erläutere ich hier:

Ruft diese Seite auf

Abschnitt 1:

Wählt rechts ‘Bearbeiten’ aus

Wählt ‘Niemand’ aus

 

Abschnitt 2:

Wählt rechts ‘Bearbeiten’ aus

Wählt ‘Niemand’ aus

 

Abschnitt 3:

Wählt ‘Deaktiviere’ aus

Auf der nächsten Seite wählt ihr ‘Abbestellen’ aus

 

Eine interessante Nachricht zum Thema Facebook Werbung könnt ihr auf Chip.de nachlesen. Wie sich das verhindern lässt, zeige ich in meinem nächsten Beitrag.

Werbung

Regelwerk und Beispiele für die eigene Retrospektive

Bei uns führt jeder IT-ler täglich seine eigene Retrospektive durch. Für neue Mitarbeiter will ich in diesem Blogbeitrag festhalten, was wir darunter verstehen. Statt die Information in unserem internen Wiki zu persistieren, wollte ich sie öffentlich machen, damit gegebenenfalls Andere davon profitieren können. Eine letzte Anmerkung für Außenstehende: Natürlich führen wir zusätzlich noch Team bzw. Sprint Retrospektiven durch, die sich zum Teil erheblich unterscheiden.

 

Regelwerk

• Die Retrospektive ist ein Werkzeug aus unserem Werkzeugkasten zur kontinuierlichen Verbesserung
• Eine Retrospektive ist eine Reflexion, bei der der Tag nochmal in Gedanken durchgegangen wird. Eine feste Dauer gibt es nicht, da jeder Tag anders ist. Aber um eine Orientierungshilfe zu nennen: 10-30 Minuten.
• Idealerweise wird die Retrospektive immer am Ende eines Tages gemacht, weil die Erinnerungen noch frisch sind. Eine feste Vorgabe gibt es jedoch nicht. Es ist genauso möglich täglich mehrmals Notizen festzuhalten oder frisch ausgeruht am Morgen des Folgetages zu reflektieren.

Was ist festzuhalten?

• Sowohl das Gute, als auch den Verbesserungsbedarf. Jedoch nicht nur das Problem an sich, sondern möglichst gleich eine entsprechende Lösung.
• Wenn ich selbst etwas Neues probiert habe und es gut funktioniert hat, dann könnte eine Schlussfolgerung lauten, die Vorgehensweise meinen Kollegen zu empfehlen. Eine weitere könnte lauten, dass es sich lohnt noch mehr Zeit in die Optimierung bzw. das Testen zu stecken, um noch mehr herauskitzeln zu können
• Bei negativen Punkten ist zu unterscheiden, ob es sich um regelmäßig benutze Ansätze respektive auftretende Verhaltensweise handelt oder ob es ein einmaliges Problem war
• Wenn es regelmäßig auftritt, sollte es in jedem Fall festgehalten und über eine Lösung nachgedacht werden. Im Zweifel kann es in die Team Retrospektive eingebracht werden, um Hilfestellung zu bekommen. Oder es könnte sich um das Verhalten des Kollegen handeln, welches negative Konsequenzen für die eigene Arbeit mitbringt. Dann könnte eine Schlussfolgerung sein dies zunächst unter 4 Augen zu klären.
• Bei einmalig aufgetretenen Problemen sollte jeder selbst entscheiden, ob es sich ein Eintrag lohnt. Bei einem menschlichen Fehler, der einmalig und unter einer einmaligen Konstellation auftrat, ist das vermutlich wenig zielführend. Allerdings hängt es auch ein wenig von den Konsequenzen ab. Vergesse ich beispielsweise beim Gehen das Abschließen und Sichern des Firmengebäudes, so kann ich – oder eben nicht – selbiges notieren und z.B. darüber nachdenken eine kleine Checkliste am Monitor zu befestigen. Auf der könnte übrigens dann auch stehen, dass die abendliche Retrospektive durchzuführen ist.

Beispiele

• Vergesse ich als Schüler, der ich ca. 1x in der Woche bei einem Betrieb jobbe, mehrfach meine meine Retrospektive durchzuführen oder mir meine Arbeitszeit per Unterschrift bestätigen zu lassen, dann kann ich mir die oben erwähnte Checkliste an meinem Arbeitsplatz (am besten auf Augenhöhe) befestigen.
• Verstoße ich als Entwickler gegen das Don’t Repeat Yourself-Prinzip, dann notiere ich das. Stelle ich nach einem Monat fest, dass das häufig vorkommt, überlege ich mir, woran es liegt. Arbeite ich z.B. viel mit Copy & Paste, so könnte ich z.B. für 1-2 Wochen in meiner IDE die Tastenkombination STRG+C umstellen.
• Vergesse ich als Administrator regelmäßig E-Mails an Externe, weil der Empfänger sich nicht von alleine meldet, so kann ich mir in Outlook auf die gesendete E-Mail einen Reminder setzen.
• Verbringe ich als Vorgesetzter den Großteil meiner Zeit in Meetings, so sollte ich selbige vielleicht analysieren. Unproduktive Meetings lassen sich mit einfachen Mitteln deutlich verbessern (vgl. meinen Artikel Wir arbeiten timeboxed). Eine weitere Möglichkeit ist es alle Meetings auf einen Tag zu legen oder an bestimmten Tagen / zu bestimmten Uhrzeiten gar keine Meetings anzusetzen.

Aus unserer täglichen Retrospektive berichte ich hier. Natürlich ist die Retrospektive ein sehr weites Feld und das oben genannte Regelwerk nur ein Tropfen auf den heißen Stein. Aber für den Einstieg reicht uns das. Der Rest kommt über Gespräche darüber und beim täglichen Reflektieren.

Wie hält es der Leser? Sind Retrospektiven bei euch in der Firma fest im Prozess etabliert? Nur bei Scrum oder auch in Eigenregie? Wollen die Kollegen sich überhaupt weiterentwickeln?

Aus der täglichen Retrospektive #3

Unsere Retrospektiven gehen weiter und die Teammitglieder entwickeln meiner Einschätzung nach ein immer besseres Gespür für Impediments. Das ist für mich als Scrum Master besonders erfreulich. Ich habe mir wieder einmal etwas herausgegriffen, von dem ich denke, dass es dem Leser helfen kann.

Es hat sich herausgestellt, dass ein wichtiger Prozess bisher nicht explizit gemacht wurde: Der Go Live.

Das führte unter anderem dazu, dass das Update erst mit mehreren Tagen Verzögerung und teilweise sogar mit Änderungen aus dem neuen Sprint durchgeführt wurde. Darüber hinaus war nicht gewährleistet, dass mit der Codebasis auch die Datenbasis aktualisiert wurde. Deshalb haben wir uns zusammengesetzt, den Prozess besprochen und diesen im Wiki festgehalten.

Darin wird klar zw. Daten- und Code- Go Live unterschieden. Damit einhergehen auch unterschiedliche Termine und Verantwortliche. Interessanterweise wurde in der Diskussion deutlich, dass der Prozess noch detailliert visualisiert und kommuniziert werden muss. In Kanban ist das fest als Regel aufgelistet:

                  Visualize Your Workflow

Einen Einblick in unser Wiki und den Prozess werde ich demnächst in Form eines Screencasts auf YouTube und auf meinen Blog stellen. Als Abonnent kriegt ihr das automatisch mit.

Mit welchem Tool verfasst bzw. persistiert ihr eure Regeln? Wer macht das? Wird das kontinuierlich erweitert oder war das nicht mehr notwendig? Ist es euch auch schon öfters passiert, dass ihr feststellen musstet, dass Regeln nicht explizit gemacht und dadurch Probleme verursacht wurden? Gerne könnt ihr mir einen Kommentar schreiben.

Testen von Datenbankabfragen – Es geht auch einfach

In diesem Screencast zeige ich wie selbst Abfragen mit mehreren Bedingungen und Sortierungen einfach getestet werden können. Unter der Haube kommt das Entity Framework zum Einsatz. Davon kriegt man dank Dependency Injection aber nichts mit.

Die erwähnte Webcast Serie, sowie weiteren Beispielcode und das Projekt auf Github gibt es hier. Feedback oder Fragen nehme ich gerne entgegen. Wenn ihr wollt, dass ich die Serie fortsetze, sprecht mich über einen Kanal eurer Wahl an.

Bessere Enumerations in NET

Ist euch der Smell von typischen Enumerations auch schon in die Nase gestiegen? In diesem Webcast zeige ich eine Alternative zu den typischen Enums in NET. Damit können das Open Closed Principle und Separation of Concerns besser umgesetzt werden, was meiner Meinung nach zu einer höheren Kohäsion führt.

 

Weiterführende Links:

• Blogbeitrag von Jimmy Bogard (Hier gibt es den Code der EnumerationBase)
• Video von Jimmy Bogard (Das Enum Beispiel kommt bei 44.45min)
• Strategy Pattern mit IoC

 

Wie haltet ihr es mit Enums? Arbeitet ihr schon auf diese Weise? Wollt ihr mehr Webcasts zu Clean Code?

Flexibles Bootstrapping durch Composition

In diesem Webcast zeige ich unseren Kompositions-Ansatz für das Bootstrapping. Die Interfaces sind schmal, die Implementierungen überschaubar, das Ganze ist flexibel und lässt sich gut testen.

Hier der gezeigte Code:

   1: public class BootstrapperContext

   2: {

   3:     public BootstrapperContext()

   4:     {

   5:         AppConfig = new ApplicationConfig();

   6:         Container = new WindsorContainer();

   7:     }

   8:  

   9:     public IWindsorContainer Container { get; private set; }

  10:     public ApplicationConfig AppConfig { get; private set; }

  11: }

   1: public interface IAmABootstrapperAction

   2: {

   3:     void Execute(BootstrapperContext context);

   4: }

 

   1: public interface IAmABootstrapperComposition

   2: {

   3:     IEnumerable<IAmABootstrapperAction> Actions { get; }

   4: }

 

   1: public class BootstrapperExecutor

   2: {

   3:     public static void StartupApplication(IAmABootstrapperComposition bootstrapperComposition)

   4:     {

   5:         var exceptionMessage = "Beim Starten der Anwendung ist ein Fehler aufgetreten. Bitte den Support kontaktieren.\n\n";

   6:  

   7:         if (bootstrapperComposition.Actions == null || !bootstrapperComposition.Actions.Any())

   8:         {

   9:             throw new BootstrapperException(exceptionMessage, new ArgumentOutOfRangeException("Auf dem Bootstrapper waren keine Actions definiert"));

  10:         }

  11:  

  12:         var context = new BootstrapperContext();

  13:  

  14:         var time = TimedAction.Run(() =>

  15:                                    {

  16:                                        foreach (var action in bootstrapperComposition.Actions)

  17:                                        {

  18:                                            var actionName = action.GetType().Name;

  19:                                            SiAuto.Main.LogMessage(string.Format("{0} gestartet", actionName));

  20:  

  21:                                            var timeTaken = TimedAction.Run(() => { ExecuteAction(action, context, exceptionMessage); });

  22:  

  23:                                            SiAuto.Main.LogMessage(string.Format("{0} in {1} erfolgreich durchgeführt",

  24:                                                                                 actionName,

  25:                                                                                 timeTaken.Format())

  26:                                                );

  27:                                        }

  28:                                    });

  29:     }

  30:  

  31:     private static void ExecuteAction(IAmABootstrapperAction action, BootstrapperContext context, string exceptionMessage)

  32:     {

  33:         try

  34:         {

  35:             action.Execute(context);

  36:         }

  37:         catch (Exception ex)

  38:         {

  39:             SiAuto.Main.LogException(string.Format("Fehler beim Bootstrapping: {0}", ex.GetFullExceptionMessage()), ex);

  40:             throw new BootstrapperException(string.Format("{0}{1}", exceptionMessage, ex.GetFullExceptionMessage()), ex);

  41:         }

  42:     }

  43: }

 

Welchen Ansatz verfolgt ihr?

Fragen oder Feedback könnt ihr mir gerne als Kommentar hinterlassen.