Skip to content

Array mit einer Schleife füllen…

Vor einiger Zeit hatte bin ich neben dem klassischen Füllen eines 2D-Arrays mit

for(y = 0; y < lengthY; y++)
{
  for(x = 0; x < lengthX; x++)
  {
     array[y,x] = [...];
  }
}

einmal über folgende Lösung gestolpert

for(index = 0; index < numberOfElements; index++)
{
   array[index / numberOfColumns, index % numberOfColumns] = [...];
}

Irgendwie ging mir das Ding nicht aus dem Kopf… und hab‘ mir überlegt, ob das Konstrukt auch n-dimensionale Arrays mit einer Schleife füllen kann.

Nach etwas Grübelei und Gecode in C# kam bei 4 Dimensionen folgendes heraus…

var numberOfColumns = 2;
var numberofRows = 2;
var numberOfPlanes = 2;
var numberOfCuboids = 2;
 
var sizeOfRow = numberOfColumns;
var sizeOfPlane = numberofRows * numberOfColumns;
var sizeOfCuboid = sizeOfPlane * numberOfPlanes;
var totalIndexes = sizeOfCuboid * numberOfCuboids;
 
var array = new int[
  numberOfCuboids,
  numberOfPlanes,
  numberofRows,
  numberOfColumns
];
 
for (var index = 0; index < totalIndexes; index++) {
  var a = index % sizeOfRow / 1;
  var b = index % sizeOfPlane / sizeOfRow;
  var c = index % sizeOfCuboid / sizeOfPlane;
  var d = index % totalIndexes / sizeOfCuboid;
  
  array[d, c, b, a] = index;
}

Das Muster ist einigermassen erkennbar:

Der Index einer Dimension errechnet sich aus dem fortlaufenden Index Modulo der Anzahl der Elemente einer Dimension durch die Ganzzahldivision der Anzahl der Elemente der „vorhergehenden“ Dimension.

Wenn jemandem eine besser Definition einfällt, her damit 🙂

Problem ist aber, dass die Anzahl der Dimensionen hartcodiert vorliegt…

Nach einigem Refactoring kam diese Lösung heraus, die ein Array beliebiger Größe füllen kann. Was rein kommt, kann durch eine Funktion geregelt werden.

Das ganze Ding ist zwar noch nicht optimal, aber es erfüllt seinen Zweck… es hat mich mal wieder zum „sinnlosen“ Coden gebracht.

The Tactical Advantage…

Bei einem Bekannten ist mir das Buch The Tactical Advantage: A Definitive Study of Personal Small-Arms Tactics aufgefallen und hatte ein bisschen rumgelesen.

Grundsätzlich geht es in dem Buch um Vorgehensweisen von Polizisten im Einsatz… aber mir ist das Kapitel Basic Tactical Principles aufgefallen, wo fünf „Tactical Guidelines“ beschrieben werden

  1. Use your senses for target indicators
    Auf Hinweise einer Präsenz eines Gegners achten. Diese können Visuell, Akustisch oder auch Gerüche sein (Zigarettenrauch in einer Wohnung eines Nichtrauchers).
  2. Avoid producing target indicators
    Im Gegensatz zu 1., wo es um den Gegner geht, sollte vermieden werden, selbst solche Hinweise zu liefern. Der Autor schreibt hier noch

    Be quiet, be careful, move slowly, and handle each tactical problem individually.

  3. Do not assume something is secure until you’ve checked it out yourself
    Sicher ist sicher, wenn es sicher ist.
  4. Maximize your distance from potential threats and minimize your exposure to them
    Nur so weit vorwagen, wie es die Sicht erlaubt. Gleichzeitg auch darauf achten, sich nicht zum Ziel zu machen.
  5. Move tactically
    Bei der Bewegung auf einen sicheren Stand achten. Die Waffe zeigt immer in Blickrichtung.
  6. When it is time to shoot, pay attention to the basics
    Zielsicherheit und Disziplin bei der Schussabgabe.

Irgendwie kam es mir das Gelesene bekannt vor. Wie würde man diese Punkte auf Software-Entwicklung transferieren ohne die Idee dahinter zu verlieren

  1. Auf mögliche Probleme achten
    Allen Beteiligten zuhören und versuchen zu verstehen, wie ihre Gedankenwelt aussieht. Auf Hinweise achten, was die Intention ist.
  2. Keine vorschnellen Entscheidungen
    Keine Commitments geben, wenn noch das Problem nicht wirklich verstanden wurde.
  3. Nicht auf Annahmen verlassen
    Sicher gehen, dass Annahmen richtig sind. Wenn testbar, dann machbar.
  4. Nicht mehrere Probleme auf einmal
    Sachen einfach halten und Schritt für Schritt
  5. Auf Gelerntes zurückgreifen
    Man muss nicht dümmer in ein Projekt gehen, als es sein muss. Vorgehensweisen/Praktiken anwenden.

Diese Liste ist mit Sicherheit nicht vollständig, aber was mir gefällt, ist die Kürze. Genau wie die 4 Grundwerte des Agile Manifesto lassen sich wenige, aber prägnante Sätze besser merken als irgendwas Ausschweifendes.

Dokumentation und Schnittstellen…

Wenn die Schnittstelle schwer zu verstehen ist und eine Dokumentation braucht, dann ist die Schnittstelle unter Umständen nicht wirklich gut.

Eine schlechte Schnittstelle wird durch eine Dokumentation nicht besser.

2 Minuten Sprints…

Beim 13. Regionaltreffen der Softwerkskammer Nürnberg war das Thema Game Of Life resp. dessen Regeln, die es zu implementieren galt. Die Sprache war egal. Unsere Wahl viel auf Java 🙂

Constraints

  • Ein „Sprint“ dauert exakt 2 Minuten
  • Pairing
  • Sprint Type 1
    • Test
    • Implementierung
    • Grün
    • Commit
  • Sprint Type 2
    • Refactoring
    • Grün
    • Commit
  • Sprint Type 3
    • Thinking

Wenn der Test nicht grün wurde, gab’s einen Revert; also es wurde nichts ins Repo geschoben, was nicht korrekt ist.

Nach wenigen Iterationen haben wir uns darauf geeinigt, erst zu programmieren und dann
über den nächsten Sprint nachzudenken.

D.h. für’s „Coding“ haben wir uns grob eine Minute Zeit genommen. Ggf. konnten wir dies dann
in unsere „Thinking“-Phase verlängern…

|<      Sprint       >|    
-----------------------
|  coding  | thinking |
-----------------------
|<  1 min >|<  1 min >|

Erkenntnisse

  • Die zeitliche Beschränkung hat ein bisschen dafür gesorgt, kein BDUF zu machen.
  • Das zu Implementierende auf das zu beschränken, was in der Zelle passiert (KISS), nämlich die Regeln und nicht z.B. wie die Anzahl der Nachbarn bestimmt werden soll.
  • Das Coding wurde zügig durchgeführt, eben mit den Überlegungen vorher.
  • Wir mussten uns nicht am Anfang des Sprint erst überlegen, was wir machen und dann keine Zeit mehr für das Coding zu haben.

In summe eine sehr interessante Erfahrung, da durch die zeitliche Reduktion sehr schnell klar wurde, wo es hakt.

Python hat was für sich…

… ist zwar ein eher simples (vielleicht auch doofes) Beispiel, aber irgendwie hat’s was

def getResultBy(Number_):
    return min([result for rule, result in rules if rule(Number_)])

rules = []

rules.append((lambda number : number < 11, "<= 10"))
rules.append((lambda number : number < 21, "<= 20"))
rules.append((lambda number : number < 31, "<= 30"))
rules.append((lambda number : number < 41, "<= 40"))
rules.append((lambda number : number < 51, "<= 50"))
rules.append((lambda number : True, "> 50"))

print (getResultBy(15))

Dank‘ für’s anfixen an @pro_cessor 🙂

Wir bilden einen Kreis…

… aus Elementen in JavaScript mit jQuery.

Es kommt mir blöd vor, Elemente per Hand in einem Kreis anzuordnen… das muss doch irgendwie anders gehen. Da war doch mal was aus dem Mathe-Unterricht mit Trigonometrie.

Der Code ist zwar noch nicht wirklich schön, aber es ging mir erstmal nur um die Funktionalität.

<!DOCTYPE html>
<html>
<head>
    <title></title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <script type="text/javascript" src="js/jquery-1.9.1.js"></script>
    <script type="text/javascript" src="js/jquery-ui-1.10.3.custom.js"></script>
    <style type="text/css">
        #position {
            position: fixed;
            top: 200px;
            left: 200px;
        }
        div.point {
            position: absolute;
        }
    </style>
    <script type="text/javascript">

        $(document).ready(function() {

            var radius = 100;
        
            var points = $('div.point');

            var ratio     = 360 / points.length;
            var toRadiant = Math.PI / 180;
            var factor    = toRadiant * ratio;

            var step = 0;

            points.each(function() {
                
                var asRadiant = step * factor;
                
                var y = Math.round(radius * Math.sin(asRadiant));
                var x = Math.round(radius * Math.cos(asRadiant));
                
                $(this).css('left', x + 'px');
                $(this).css('top',  y + 'px');
                
                step++;
                
            });

        });
        
    </script>    
</head>
<body>
    <div id="position">
        <div class="point">Eins</div>
        <div class="point">Zwei</div>
        <div class="point">Drei</div>
        <div class="point">Vier</div>
        <div class="point">Fünf</div>
        <div class="point">Sechs</div>
        <div class="point">Sieben</div>
    </div>
</body>
</html>

Minimalist Software Engineer’s manifesto…

oder in kurz Minifesto… nette Zusammenstellung von Prinzipien; erinnert mich an Lean.

Kurz, knapp und irgendwo schon mal gesehen… aber warum nicht. Stetes und „richtiges“ (die Wertung überlass‘ ich mal anderen) Training führt ab und zu auch zum Erfolg.