stanislaw

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

stanislaw

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

stanislaw

```
width=`identify -format %w icon-167_360.png`; \
  convert -background white -fill black -gravity center -size ${width}x30 \
          caption:"Debug" \
          icon-167_360.png +swap -gravity south -composite  icon-167_360.png
```

stanislaw

#!/bin/bash

# This script is an optimization over Carthage's copy-frameworks script.
# This script copies frameworks provided as "Input Files" in
# Xcode Run Script phase. On the first run it copies the frameworks and
# codesigns them, on subsequent runs it does nothing.
#
# Warning! This optimization has a cost: to upgrade a particular framework
# one has to either delete the whole build cache or
# manually delete that framework from cache.

stanislaw

Count:       12
/Users/Stanislaw/Work/MusicContent/Music Content/3 Doors Down/Be Like That/3 Doors Down - Be Like That - Finale.xml
Document has errors: Errors: (
    "Error type: "More than one note on the same string in a chord!", description: "Voicing at measure 36 contains two notes on the same string: (
    "<MXMLNote: 0x7fd96174e7e0 (type = B; alteration = No; string = 5; fret = 2)>",
    "<MXMLNote: 0x7fd96174f540 (type = D; alteration = No; string = 5; fret = 5)>",
    "<MXMLNote: 0x7fd961750240 (type = D; alteration = No; string = 4; fret = 0)>",
    "<MXMLNote: 0x7fd961750f80 (type = A; alteration = No; string = 3; fret = 2)>",
    "<MXMLNote: 0x7fd962977690 (type = B; alteration = No; string = 2; fret = 0)>",
    "<MXMLNote: 0x7fd9629783f0 (type = F; alteration = #; string = 1; fret = 2)>"

stanislaw

// Implements the solution for solving "snapback" found in 
// Chapter 8 of "iOS Core Animation Advanced Techniques" by Nick Lockwood
// without the need to use setDisableActions: to override the implicit animation,
// instead passing in the implicit animation key in addAnimation:forKey:

// With setDisableActions
- (void)applyBasicAnimation:(CABasicAnimation *)animation toLayer:(CALayer *)layer
{
    //set the from value (using presentation layer if available)
    animation.fromValue = [layer.presentationLayer ?: layer valueForKeyPath:animation.keyPath];

stanislaw

; ModuleID = 'jitrust.0.rs'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-darwin"

%str_slice = type { i8*, i64 }
%"9.__test::test::TestDescAndFn" = type { %"9.__test::test::TestDesc", %"9.__test::test::TestFn" }
%"9.__test::test::TestDesc" = type { %"9.__test::test::TestName", i8, %"9.__test::test::ShouldPanic" }
%"9.__test::test::TestName" = type { i64, [0 x i64], [3 x i64] }
%"9.__test::test::ShouldPanic" = type { i64, [0 x i64], [2 x i64] }
%"9.__test::test::TestFn" = type { i64, [0 x i64], [2 x i64] }

stanislaw

#!/bin/sh

#
# Converts branch name 'MAPP-452_how-is-it-going' into a commit message 'MAPP-452 How is it going'
#

if ! [ -z $2 ] 
then
  if ! [ "message" == $2 ]
  then 

stanislaw

swiftc \
    -emit-ir \
    -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks \
    -Xlinker -rpath -Xlinker /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks \
    -lswiftCore jitswift.swift
; ModuleID = '-'
source_filename = "-"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.9"

stanislaw

So you want to build a mutation testing system

Introduction

There have been a lot mutation testing systems, but very few have them have seen succesfull use in industry.

This document is a set of notes that might be helpful for anyone thinking of implementing a mutation testing system for another language.

It represents some of the things we learnt while creating pitest. The choices made by pitest are not neccessarily the best choices for your system. Some of these choices are appropriate only because of the particular quirks of Java and the JVM, and some of them are simply the first idea that we had.