21. September 2015

Feature Flags

(Image: bytearrays.com)
In one of my projects I just stumbled across the topic "Feature Flags".

Feature flags (aka Feature Toggle, aka Feature Switch) let you enable program/web site features selectively. This is especially important in continuous delivery environments where code is always committed and deployed even if a feature is not ready for prime time. It can be useful if you have a large user base and want to introduce the feature incrementally by enabling the feature for sub-sets of users. Feature flags are useful in anything beyond toy apps.

Feature flags are not new. They are widely known since Martin Fowler blogged about the pattern. He did not invent them. Many good developers have been using feature flags or alike for a long time. But Martin Fowler recognized feature flags as a remarkable pattern. Writing about feature flags was a good idea, because other developers who are not aware of the pattern can learn from it. That was 2010.

Guess what, in 2006 a lonely Weblin programmer added feature flags to the Weblin portal. Weblin has been using feature flags from the start.

_happy_flagging()

15. September 2015

ZEIT online Relaunch - Undo

ZEIT online hat gerelauncht. Jetzt irgendwie dunkel und schmaler als vorher. Gefällt nicht. Kann man aber fixen. 

Links: ZEIT nach Relaunch, 
Rechts: gefixt: wieder weiß, ohne Rand 


Wie?

Mit Tampermonkey, eine Chrome Erweiterung. Tampermonkey führt auf jeder Webseite Javascript aus.

Bei ZEIT online muss man nur ein paar CSS Anweisungen verändern: den Hintergrund vom <body>-Tag wieder in weiß und der Rahmen vom Content-<div> weg:

body { background-color: #ffffff !important; } 
.page__content { box-shadow: none; }

Man braucht noch etwas Javascript, um das CSS einzufügen. Hier das ganze Tampermonkey-Script für ZEIT online:

// ==UserScript==
// @name        ZEIT
// @namespace   http://wolfspelz.de/
// @version     0.1
// @description Restore white background
// @match       http://www.zeit.de/*
// @copyright   2015+, wolfspelz
// ==/UserScript==

function addGlobalStyle(css) {
    var head, style;
    head = document.getElementsByTagName('head')[0];
    if (!head) { return; }
    style = document.createElement('style');
    style.type = 'text/css';
    style.innerHTML = css;
    head.appendChild(style);
}

addGlobalStyle('body { background-color: #ffffff !important; } .page__content { box-shadow: none; }');

_happy_tampering()

Für Firefox: Greasemonkey

12. August 2015

Nie wieder Smooth Gestures für Chrome

(Blogpost, damit ich es mir selbst merken kann)

Ich war immer sehr zufrieden mit der Chrome Extension "Gestures for Google Chrome". In letzter Zeit ist Gestures for Google Chrome anscheinend manchmal abgestürzt. Jedenfalls war sie immer wieder nicht aktiv, musste von Hand aktiviert werden.

Ich hatte noch von früher "Smooth Gestures" installiert, aber nicht aktiv. Probeweise mal wieder aktiviert. Macht in allen Tabs haufenweise Requests an yieldsquare.com (gefühlt 10 pro Sekunde).

Also: nie mehr aus Versehen zu Smooth Gestures greifen.

_happy_gesticulating()

6. August 2015

Minimalinvasiver Bootstrap Bestätigungsdialog (Confirm Modal Dialog)

Ab und zu braucht man bei Webanwendungen einen Bestätigungsdialog, bevor die Benutzerin eine Aktion auslöst, zum Beispiel "Do you really want to delete …"


Das geht mit Bootstrap sehr schlank und fast ohne Änderungen am Code. Kein Umstellen eines Links auf Button mit click-Aktion, kein Aufruf einer Javascript Dialog-Klasse, keine extra Funktionen als Callbacks, die auf Dialog-Button-OK oder –Abbrechen reagieren, sondern…

…etwas HTML (für den Dialog) und 2 Zeilen JavaScript zum Verdrahten.

Der Trick: Angenommen es gibt einen Link, dem der Confirm-Dialog vorgeschaltet werden soll. Das href-Attribut des Links wird zum "OK"-Button des Dialogs weitergereicht und der Link stattdessen zum Öffnen des Dialogs benutzt.

Ein Klick auf:

Delete

<a href="/Offer/Delete">Delete</a>

würde das Angebot (Offer) sofort löschen. Das soll durch einen Bestätigungsdialog abgesichert werden:

Dafür muss man 3 Dinge tun:

1. Dem Link sagen, dass er den Dialog aufrufen soll

<!—data-target und data-toggle aktivieren den Dialog beim Klick-->
<a href="/User/Delete" data-target="#ConfirmDialog" data-toggle="modal" id="DeleteButton">Delete</a>

2. Den Dialog definieren (irgendwo im Body)

<!-- Modal dialog -->
<div class="modal fade" id="DeleteDialog" tabindex="-1" role="dialog" aria-labelledby="myModalLabel">
    <div class="modal-dialog" role="document">
        <div class="modal-content">
            <div class="modal-header">
                <button type="button" class="close" data-dismiss="modal" aria-label="Close"><span aria-hidden="true">&times;</span></button>
                <h4 class="modal-title">Echt jetzt?</h4>
            </div>
            <div class="modal-body">Willst du das Angebot wirklich löschen?</div>
            <div class="modal-footer">
                <button type="button" class="btn btn-primary btn-ok">OK</button>
                <button type="button" class="btn btn-default" data-dismiss="modal">Abbrechen</button>
            </div>
        </div>
    </div>
</div>

3. Alles verdrahten:

// Beim ursprünglichen Link:
$('#DeleteButton').each(function () { $(this)
  // Link als data-href sichern
  .data('href', $(this).attr('href'))
  // Link durch # entschärfen
  .attr('href', '#');
});
// Beim Öffnen des Dialogs:
$('#DeleteDialog').on('show.bs.modal', function (e) { $(this).find('.btn-ok')
    // …das gesicherte href-Attribut zum OK-Button weiterreichen 
  .attr('href', $(e.relatedTarget).data('href'))
    // Beim OK-Klick zum href navigieren
  .click(function () { location.href = $(this).attr('href'); });
});

Das sieht viel aus, aber in der Praxis schreibt sich das so:

$('#DeleteButton').each(function () { $(this) .data('href', $(this).attr('href')) .attr('href', '#'); });
$('#DeleteDialog').on('show.bs.modal', function (e) { $(this).find('.btn-ok') .attr('href', $(e.relatedTarget).data('href')) .click(function () { location.href = $(this).attr('href'); }); });

_happy_confirming()

PS: Nur eins der vielen kleinen Themen, die so ein Web-Projekt aufwirft: www.essenbeifreunden.com

23. Juni 2015

Was geht ... Galactic Developments

Wenn ihr Euch fragt, warum hier keine Posts mehr kommen...

Momentan konzentriere ich meine Freizeitaktivitäten auf Galactic Developments. Als Kreativ-Übung schreibe ich jeden Tag eine neue Idee auf.

Ich schreibe pro "Story" maximal eine Seite. Dafür aber jeden Tag eine. Ich versuche mir jeden Tag etwas Neues einfallen zu lassen, eine neue Erfindung, eine Entdeckung, ein neues Ereignis. Und das dann in maximal 1000 Wörtern zu formulieren.

Die Action ist hier:
Das ist zur Zeit mein Haupt-Hobby: Story ausdenken, schreiben, rechtefreie Bilder suchen, Bild machen, Blog posten, Timeline-Eintrag comitten (Subversion), Facebook und Twitter post-Bilder machen, Facebook/Twitter posten, Facebook Gruppen und Follower betreuen. Daneben bleibt nicht viel Freizeit.

_happy_writing()



22. April 2015

Interview auf dem Deutschen Science Fiction Portal

Auf deutsche-science-fiction.de ist mein Interview zum Thema Galactic Developments erschienen. Sven Kloepping vom  Deutschen Science Fiction Portal hat mir einige Fragen zugeschickt, die ich dann nach bestem Wissen und Gewissen beantwortet habe.

Eine Frage hat mir besonders zu Denken gegeben: Inwieweit fließen reale Forschungsergebnisse und Entdeckungen in Ihr Projekt ein?

Anfangs dachte ich, dass ich als naturwissenschaftlich interessierter Physiker mein Wissen oft verwende. Immerhin lese ich die Zeitschrift der Deutschen Physikalischen Gesellschaft, Spektrum der Wissenschaft und Science Blogs. Ich verfolge die neueste Hochenergiephysik, war sogar live (im Stream) bei der Veröffentlichung des Higgs und bei der Landung von Philae dabei.

Bei genauerem Nachdenken ist mir dann aber aufgefallen, dass ich neuesten Erkenntnissen eher skeptisch gegenüberstehe. Damit meine ich nicht, dass ich sie anzweifle. Neueste wissenschaftliche Erkenntnisse sind (fast) immer korrekt. Aber es kommt immer wieder vor, dass sie später anders interpretiert werden können. Und da ich bei Galactic Developments aus der Sicht der Zukunft schreibe, bin ich vorsichtig mit brandneuen Erkenntnissen, die später relativiert werden könnten. Wenn ich Galactic Developments schreibe, dann aus der Sicht des Artikels ja schon ein paar hundert Jahre vergangen und es sind neue neueste Erkenntnisse dazugekommen, die die alten neuesten Erkenntnisse vielleicht in einem anderen Licht erscheinen lassen.

Vorsicht vor Extrapolation:

Die erste Eisenbahn war mit 28 Stundenkilometer wahnsinnig schnell. Der Begriff "schnell" hat sich sicher gewandelt. Heute ist ein Zug mit 100 km/h nicht besonders schnell. Schreibt man also, dass ein Regionalzug im 25. Jahrhundert 500 Stundenkilometer "schnell" ist, dann mag das heute toll klingen. Ist auch vermutlich nicht mal falsch. Aber Thema verfehlt, weil alles ganz anders ist und Räder nicht mehr auf Metall rollen. Vielleicht nicht einmal auf Magneten schweben. Merke: einfaches Extrapolieren geht nicht. Ich versuche deshalb disruptive Änderungen zu erfinden, statt die neuesten Erkenntnisse zu extrapolieren.

Vorsicht vor impliziten Annahmen:

Die Legende sagt, dass Galileo Galilei auf den Schiefen Turm von Pisa gestiegen ist, zwei Metallkugeln fallen gelassen hat und so die Fallgesetze erfunden hat: alles fällt gleich schnell und zwar immer schneller mit einer Beschleunigung von 9,81 m/s2.

Das war damals die neueste Erkenntnis. Das ist auch immer noch richtig. Aber heute würden wir das nicht so formulieren, denn das stimmt nur auf der Erde und auch da nur auf Meereshöhe. Auf dem Mond sieht das anders aus (nur ein Sechstel davon), in tiefen Bergwerken auf der Erde ist es auch weniger (im Promille Bereich). In einer Erdumlaufbahn fällt man gar nicht auf die Erde.

Newton und Kepler haben die Gesetze der Gravitation und Bewegung verallgemeinert, so dass sie auch auf dem Mond und in tiefen Bergwerken gelten. Das macht die neuesten Erkenntnisse von Galileo nicht falsch, aber rückblickend hat Galileo "nur" einen Spezialfall beschrieben, keinesfalls allgemein gültige physikalische Gesetze.

Und dann kam Einstein und erklärte, dass auch die neuesten Erkenntnisse von Newton und Kepler nur eingeschränkt gelten. Sie stimmen, aber nur solange sich alles langsam bewegt, wenn die Schwerkraft nicht sehr stark ist und man kann sie überhaupt nur auf normale Materie anwenden, aber z.B. nicht auf Licht.

Einstein schrieb neue Formeln auf, die auch dann noch gelten, wenn sich sehr schwere Massen sehr schnell bewegen oder bei Lichtteilchen, die gar nichts wiegen und sogar mit Lichtgeschwindigkeit fliegen. Es stellte sich heraus, dass auch die Formeln von Newton und Kepler Spezialfälle einer allgemeineren Theorie waren. Und die neuesten Erkenntnisse waren plötzlich alt. Nicht falsch, aber nicht allgemein anwendbar.

Also Vorsicht vor den neuesten Erkenntnissen der Wissenschaft. Die sind richtig, können sich aber als Spezialfälle herausstellen und später etwas altbacken wirken. Man bekommt sogar den Eindruck, dass die Aussage von Galileo "alles fällt gleich schnell" ein bisschen falsch ist. Das liegt aber nur daran, dass er es so allgemein formuliert hat und dabei ein paar Annahmen weggelassen hat, nämlich: "1. auf der Erde und 2. auf Meereshöhe, 3. solange sich alles langsam bewegt und 4. es sich um normale Materie handelt". Tatsächlich waren Galileo diese Annahmen nicht bewusst. Sie waren implizit. Sonst hätte er vermutlich gleich eine allgemeinere Theorie formuliert und Newton, Kepler und Einstein arbeitslos gemacht.

Für mich ist deshalb die wichtigste Erkenntnis, dass alles was heute brandneu ist, später überholt sein kann, auch wenn es vorher nicht falsch war. Vorsicht vor impliziten Annahmen.

_happy_assuming()

7. Februar 2015

How to Make Your Site Responsive and Mobile Friendly in Minutes

Assumed you have a web site for years. It has a traditional layout with a header, a menu sidebar, and a content area. The menu sidebar and also the header do not fit very well on a smartphone screen.

We need a scrolling friendly vertical design. It should appear automatically whenever the screen width is the size of a smartphone. We need an overlay menu instead of the menu sidebar.

And we need it quickly without a complete redesign. 

This is what I just did for my old web site http://www.galactic-developments.de

(Because it went so smooth and easy, I'll report what I did. Maybe it helps someone. Paying back to the Web.)


Starting with a typical nice static, not responsive, not smartphone compatible design:




We will turn it into a responsive design with popup menu:




...in 10 minutes.

The Basic Principle:

HTML5/CSS3 offers a simple mechanism to switch designs based on device properties: media queries. A media query applies the enclosed CSS only if the query condition is met. 

I insert this into the HTML of the page template of my CMS (I could also add it to my CSS file):

@media screen and (max-width:700px) {
  // here will be CSS
}

Media Queries override general CSS-styles. Inside the curly braces I will now redefine some of the styles. By redefining I can make elements disappear, change sizes, and change the layout.

The above CSS means, that the styles will be applied to screens (not when printed) and which are smaller than 700 pixels.

Things to do:

1. Remove Header, Footer, and Frame

The frame in the background must disappear. The background consists of three <div>s with a background image each. Top and bottom <div>s also contain other graphics and buttons. They will all disappear. The center <div> also has my text and the menu. The center <div> will stay. But it will loose it's background. Luckily these three <div>s already have IDs. So I can add these lines inside the media query:

  #bgtop { display: none; }
  #bgcenter { background: none; }
  #bgbottom { display: none; }

... which makes my new media query CSS look like:

@media screen and (max-width:700px) {
  #bgtop { display: none; }
  #bgcenter { background: none; }
  #bgbottom { display: none; }
}

See, how the header and the vertical frame disappeared:


2. Menu

The menu should not be statically on the left side. It should be invisible at start and accessible from a menu button. If I press the menu button, then the menu should appear.

I decided, that the menu button should be in the top right corner of the screen and the menu will appear on the right side. Reason: the button in the top right corner will cover less of the text. There is free space at the top right while the top left always has text. I move the menu from the left side, which is also left of the text, to right side and above the text. My menu <div> has the ID "menu":

#menu {
  position:fixed; right:0px; top:0px; 
  background-color:#ffffff; padding:4px; 
}

The position will to be fixed even if the page is scrolled. There is a 4 pixel padding which is filled by a white background color for a small distance between the content below and the menu:


If you make the window wide, then it has still the original design.

3. Menu Button

This will be my menu button:


I insert the button <div> into the HTML (I put it just before the header <div>):

<div id="menubutton"></div>

Add CSS for the menu button:

#menubutton {
  display: block; position:fixed;
  right:4px; top:4px; width:24px; height: 24px;
  background:url(img/menubutton.png);
}

Shift the the menu down to make room for the menu button:

  #menu { margin-top:28px; }

Add a small JavaScript section to the HTML to toggle the visibility of the menu, when the menu button is pressed (jquery would be overkill, could use jquery for fade/slide animations, though):

<script>
 
document.getElementById('menubutton').onclick = function()
  {     
    var m = document.getElementById('menu'); 
    m.style.display = (m.style.display == 'block' ? 'none' : 'block');
  };
</script>

    When the page loads, then the menu should not be visible (it will be shown by the menu button):

      #menu { display: none; }


    4. Device Scaling:

    Pixel densities on mobile devices are usually higher than on desktop/laptop screens. And they differ. But all devices should show about the same amount of text. This means, that a scaling factor must be applied, which scales the page depending on the DPI of the device. The command for that comes as a meta tag. Add it to the HTML <head> section (of the web site template):

    <meta name="viewport" 
      content="width=device-width,initial-scale=1,user-scalable=no"
    />

    That's basically it:

    5. Additional Tweaks:

    Pixel densities on mobile devices are usually higher than on desktop/laptop screens. So I changed the baseline font size from 12px to 14px (this might be more effort depending on your existing CSS). In my case:

    * { font-size:14px; }

    On small smartphone screens, like old iPhones, the menu is too long. I remove some menu entries, which are not really important. I do this by assigning IDs to menu entries like. I changed:

    <li><a href="stuff.html">Wallpapers</a></a>

    to:

    <li id="menuWallpapers"><a href="stuff.html">Wallpapers</a></a>

    ...and add this to the CSS:

      #menuWallpapers { display: none; }

    As you see in the screen shot, my text is too wide. The reason is, that in my original design I assigned a fixed width to the content area, so that the text does not flow outside the border. Now, the text width should adjust to the device width. In my case, there are two <div>s to be fixed:

      #bgcenter, #main { width: auto; }

    I want to remove the page URL from the top. I don't think it's very useful, especially on a mobile screen. The page URL is only on the start page. It is a page content, not in the template of all pages. Still, I can hide it with a CSS in the same place as the other CSS tweaks.

    In other words: a style which is only used by a single page is configured globally by the media query CSS section. No problem. Since the link is inside a <div class="link">:

      .link { display: none; }


    A small shadow for the menu is no mistake:

      #menu {
        -webkit-box-shadow: 0px 0px 8px 0px rgba(0, 0, 0, 1);
        -moz-box-shadow:    0px 0px 8px 0px rgba(0, 0, 0, 1);
        box-shadow:         0px 0px 8px 0px rgba(0, 0, 0, 1);

      }

    Result:




    Summary:

    The complete CSS:

    @media screen and (max-width:700px) {
      #bgtop { display: none; }
      #bgcenter { background:none; }
      #bgbottom { display: none; }
      #menu { margin-left: 0px; }
      #menu { 
        position:fixed; right:0px; top:0px; 
        background-color:#ffffff; padding:4px; 
      }
      #menubutton {
        display: block; position:fixed;
        right:4px; top:4px; width:24px; height: 24px;
        background:url(img/menubutton.png);
      }
      #menu { margin-top:28px; }
      #menu { display: none; }
      * { font-size:14px; }
      #menuWallpapers { display: none; }
      #bgcenter, #main { width: auto; }
      .link { display: none; }
      #menu {
        -webkit-box-shadow: 0px 0px 8px 0px rgba(0, 0, 0, 1);
        -moz-box-shadow:    0px 0px 8px 0px rgba(0, 0, 0, 1);
        box-shadow:         0px 0px 8px 0px rgba(0, 0, 0, 1);

      }
    }

    A bit HTML and JavaScript for the menu button:

    <div id="menubutton"></div><script>
      document.getElementById('menubutton').onclick = function()
      {     
        var m = document.getElementById('menu'); 
        m.style.display = (m.style.display == 'block' ? 'none' : 'block');
      };
    </script>
    A meta tag in the HTML <head>:

    <meta name="viewport" 
      content="width=device-width,initial-scale=1,user-scalable=no"
    />

    _happy_scaling();

    Of course, there are other ways to make a responsive web site. You could use a mobile friendly CSS package, like bootstrap. But that probably means, that you will redesign your site, which won't be done in an hour.

    Of course, there are more modern ways to program the menu button. You could use jquery and this JavaScript:

      $('#menubutton').click(function() { $('#menu').fadeToggle(); });

    But you have to include 100 kB jquery library:

    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>