1. David Krentzlin
  2. lisp-unleashed blog

Commits

certainty  committed 3cc8b29

fixed jekyll installation and finished missbehave post

  • Participants
  • Parent commits 4d58744
  • Branches default

Comments (0)

Files changed (14)

File Gemfile

View file
 source 'http://rubygems.org'
 
-
-gem 'jekyll'
+gem 'coderay'
+gem 'kramdown'
+gem 'jekyll', github: 'mojombo/jekyll'
 gem 'jekyll-sass'
 gem 'haml'
 gem 'rake'

File Gemfile.lock

View file
+GIT
+  remote: git://github.com/mojombo/jekyll.git
+  revision: 1374a6354290a08167f040d33a0d0b8be0b1a699
+  specs:
+    jekyll (1.0.3)
+      classifier (~> 1.3)
+      colorator (~> 0.1)
+      commander (~> 4.1.3)
+      directory_watcher (~> 1.4.1)
+      kramdown (~> 1.0.2)
+      liquid (~> 2.3)
+      maruku (~> 0.5)
+      pygments.rb (~> 0.5.0)
+      safe_yaml (~> 0.7.0)
+
 GEM
   remote: http://rubygems.org/
   specs:
-    albino (1.3.3)
-      posix-spawn (>= 0.3.6)
     classifier (1.3.3)
       fast-stemmer (>= 1.0.0)
+    coderay (1.0.9)
+    colorator (0.1)
+    commander (4.1.3)
+      highline (~> 1.6.11)
     directory_watcher (1.4.1)
-    fast-stemmer (1.0.1)
-    haml (3.1.7)
-    jekyll (0.11.2)
-      albino (~> 1.3)
-      classifier (~> 1.3)
-      directory_watcher (~> 1.1)
-      kramdown (~> 0.13)
-      liquid (~> 2.3)
-      maruku (~> 0.5)
-    jekyll-sass (1.0.0)
+    fast-stemmer (1.0.2)
+    haml (4.0.3)
+      tilt
+    highline (1.6.19)
+    jekyll-sass (1.1.0)
       jekyll (>= 0.10.0)
       sass (>= 3.0.0)
-    kramdown (0.14.0)
-    liquid (2.4.1)
+    kramdown (1.0.2)
+    liquid (2.5.0)
     maruku (0.6.1)
       syntax (>= 1.0.0)
     posix-spawn (0.3.6)
-    rake (0.9.2.2)
-    sass (3.2.1)
+    pygments.rb (0.5.0)
+      posix-spawn (~> 0.3.6)
+      yajl-ruby (~> 1.1.0)
+    rake (10.0.4)
+    safe_yaml (0.7.1)
+    sass (3.2.9)
     syntax (1.0.0)
+    tilt (1.4.1)
+    yajl-ruby (1.1.0)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
+  coderay
   haml
-  jekyll
+  jekyll!
   jekyll-sass
+  kramdown
   rake

File Rakefile

View file
 
   desc "Build site"
   task :build do |task,args|
-    system "jekyll --pygments"
+    system "jekyll build"
   end
 
   desc "Run server"
   task :server do
-    system "jekyll --server --auto --pygments"
+    system "jekyll serve --watch "
   end
 end
 

File _config.yml

View file
 permalink: /:categories/:year/:month/:day/:title 
 
 exclude: [".rvmrc", ".rbenv-version", "README.md", "Rakefile", "changelog.md","Gemfile","Gemfile.lock","drafts"]
-pygments: true
+pygments: false
+
+markdown: kramdown
+
+kramdown:
+  use_coderay: true
 
 title : lisp-unleashed 
 tagline: Lisp is the red pill 

File _layouts/.page.html.swx

Binary file removed.

File _layouts/default.html

View file
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
 
      <link href="{{ ASSET_PATH }}/vendor/bootstrap/css/bootstrap.min.css" rel="stylesheet">
-     <link href="{{ ASSET_PATH }}/vendor/pygments/default.css" rel="stylesheet">
+     <link href="{{ ASSET_PATH }}/vendor/bootstrap/css/bootstrap_responsive.min.css" rel="stylesheet">
      <link href="{{ ASSET_PATH }}/css/style.css?body=1" rel="stylesheet" type="text/css" media="all">
-     <link href="{{ ASSET_PATH }}/vendor/bootstrap/css/bootstrap_responsive.min.css" rel="stylesheet">
 
      <!--[if lt IE 9]>
       <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

File _layouts/post.html

View file
     </div>
     <aside class="span3">
       <h4>Published</h4>
-      <time datetime="{{ page.date | date_to_xmlschema }}" class="date"><span>{{ page.date | date_to_long_string }}</span></time>
+     
+      <time datetime="{{ page.datestring chema }}" class="date"><span>{{ page.datestring }}</span></time>
 
       {% if page.code %}
         <h4>Code</h4>

File _posts/2010-08-14-back_to_chicken.md

View file
 title: Back to CHICKEN
 tagline: Let's see what has changed 
 tags : [scheme, chicken]
+datestring: 2010-08-14
 ---
 {% include setup %}
 

File _posts/2010-12-26-nomads.md

View file
   url: http://bitbucket.org/certainty/nomads
   caption: nomads
 tags : [scheme, chicken, nomads]
+datestring: 2010-12-26
 ---
 {% include setup %}
 
 
 Ok, so SQL is not a bad thing, why should we pretend that we aren't using it? While I do see the general benefit of layering abstractions over SQL to achieve a certain degree of "database independence", I do also think that it must not be overused. And migrations are a place where I don't see a good reason for abstracting away the SQL. So my migrations hold SQL-Fragments. A typical migration file would look like this:
 
-{% highlight scheme %}
+~~~
 ((UP "CREATE TABLE IF NOT EXISTS edge (in_vertex INTEGER,out_vertex INTEGER)")
  (DOWN "DROP TABLE IF EXISTS edge"))
-{% endhighlight %}
+~~~
 
 It's as simple as this. As you see there are two sections inside a migration file. One section for the rollout and one section for the rollback. The SQL-Fragments of the appropriate section get executed during up and down migration.
 
 In either case I wanted the developer to have as much liberty as she can get.
 So lambda the ultimate to the rescue. In fact the migration files are read and evaluated inside a quasiquote. If the library recognizes that the body of a migration holds a procedure, it invokes it and passes the database-adapter as its sole argument.
 
-{% highlight scheme %}
+~~~
 ((UP ,(lambda (db) (do-something-nifty-with db)))
  (DOWN ,(lambda (db) (undo-something-nifty-with db))))
-{% endhighlight %}
+~~~
 
 ## Which route do we go?
 
 
 Another common feature are migrations, that aren't reversible. Of course the library allows to express this situation. The migration file may simply hold #f to be considered irreversible. The developer can also add an optional message for irreversible migrations.
 
-{% highlight scheme %}
+~~~
 ((UP "CREATE TABLE vertices (id INTEGER, name STRING)")
  (DOWN (#f . "You must not remove vertices") ))
-{% endhighlight %}
+~~~
 
 ### The migration tool
 
 Now we can put it all together and create a simple program that can be used to manage the migrations. Here is a simple version that works like RoRs db:migrate rake task. It uses a custom callback that is invoked on each check point, which enables us to customize the way we report migrations. We're using Alex Shin's very cool [fmt egg](http://wiki.call-cc.org/eggref/4/fmt) to do so.
 
-{% highlight scheme %}
+~~~
 (use nomads nomads-sql-de-lite fmt fmt-color filepath)
 
 (migration-directory "./migrations")
 
 
 (migrate version: (get-version) callback: pretty-print-migration)
-{% endhighlight %}
+~~~
 
 
 All you need to do is adjust the path to your database and compile the program like this:

File _posts/2012-10-25-dynamic_attributes.md

View file
 title: Dynamic Attributes
 tagline: syntactic affairs
 tags: [ruby,dynamic_attr,syntactic_affairs]
+datestring: 2012-10-25
 ---
 
 {% include setup %}
 
 ### fluid-let
 
-{% highlight scheme %}
+~~~
 
 (define counter 0)
 (define (bump-counter!) (set! counter (+ 1 counter)) counter)
 (display counter)
 (newline)
 
-{% endhighlight %}
+~~~
 
 <pre>
 11
 See how the counter is temporarily set to 10 and restored to 0 after the fluid-let body.
 
 ### Parameters (SRFI-39)
-{% highlight scheme %}
+~~~
 (define context (make-parameter ""))
 
 (define (log message)
   (parameterize ((context "Network"))
    (log "starting up"))
   (log "finished"))
-{% endhighlight %}
+~~~
 
 This results in:
 <code>
 
 But let's get back to ruby now. The following piece of code illustrates what a ruby-version of this could look like:
 
-{% highlight ruby %}
+~~~
 class MyLogger
   dynamic_attr :context
 
 
   logger.log("finishd")
 end
-{% endhighlight %}
+~~~
 
 
 I guess there is not much that I need to say about it. It's just a piece of boilerplate that should

File _posts/2012-10-25-pipes_and_filters_in_ruby.md

View file
 title: Pipes and Filters in Ruby
 tagline: syntactic affairs
 tags: [ruby,syntactic_affairs]
+datestring: 2012-10-25
 ---
 
 
 programming.
 
 I usually find myself facing the following situation. I have an object, like a collection,
-and want to apply a couple of transformations to it. This leans itself very much to a <strong>fold</strong> or 
+and want to apply a couple of transformations to it. This leans itself very much to a <strong>fold</strong> or
 <strong>inject</strong> in ruby parlance. However doing all the transformations in a block-argument for inject, just appears a bit cumbersome.
 
 So ruby allows the following:
 
-{% highlight ruby %}
-puts %w(Alicia David Lucie Jenny).map(&:downcase).map(&:reverse).map(&:capitalize)
-{% endhighlight %}
+~~~ ruby
+  puts %w(Alicia David Lucie Jenny).map(&:downcase).map(&:reverse).map(&:capitalize)
+~~~
 
 When I looked at this I thought, wow that looks like a lot like a pipe on the UNIX command line.
 
 The way I picture this, is that all we do here is applying a bunch of <strong>pipes and filters</strong>.
 
 
-{% highlight ruby %}
+~~~ ruby
 
-%w(Alicia David Lucie Jenny).map(&:downcase | :reverse | :capitalize)
+  %w(Alicia David Lucie Jenny).map(&:downcase | :reverse | :capitalize)
 
-{% endhighlight %}
+~~~
 
 See how the pipes actually resemble what we know from the UNIX command line?
 And it we don't have to traverse the entire collection multiple times to do this. Instead
 
 Ok so here's how we might achieve this:
 
-{% highlight ruby %}
+~~~ ruby
 
-class FilterChain
-  def initialize
-    @filters = []
-  end
+ class FilterChain
+   def initialize
+	 @filters = []
+   end
 
-  def |(filter_or_symbol)
-    @filters << (filter_or_symbol.is_a?(Symbol) ? Filter.new(filter_or_symbol) : filter_or_symbol)
-    self
-  end
+   def |(filter_or_symbol)
+	 @filters << (filter_or_symbol.is_a?(Symbol) ? Filter.new(filter_or_symbol) : filter_or_symbol)
+	 self
+   end
 
-  def to_proc
-    ->(r){ @filters.inject(r){ |o,f| f.apply(o) } }
-  end
-end
+   def to_proc
+	 ->(r){ @filters.inject(r){ |o,f| f.apply(o) } }
+   end
+ end
 
-class Filter
-  attr_reader :the_method
+ class Filter
+   attr_reader :the_method
 
-  def initialize(the_method)
-    @the_method = the_method
-  end
+   def initialize(the_method)
+	 @the_method = the_method
+   end
 
-  def apply(r)
-    r.send(the_method)
-  end
-end
+   def apply(r)
+	 r.send(the_method)
+   end
+ end
 
-class Symbol
-  def |(other)
-    FilterChain.new | Filter.new(self) | Filter.new(other)
-  end
-end
+ class Symbol
+   def |(other)
+	 FilterChain.new | Filter.new(self) | Filter.new(other)
+   end
+ end
 
 
-{% endhighlight %}
+~~~
 
 With this in place we can run the expression from the beginning and get the the following result:
 
-    ["Aicila", "Divad", "Eicul", "Ynnej"]
+~~~ ruby
+   ["Aicila", "Divad", "Eicul", "Ynnej"]
+~~~
 
 Not so bad for a couple of lines of code. With this in place we can do some nice experiments.
 Note that in other languages you get these kinds of things with function composition. So the
 above example would look something like this in <strong>scheme</strong>:
 
-{% highlight scheme %}
-(map (compose string-reverse string-downcase) (list "David" "Alicia" "Lucie"))
-{% endhighlight %}
+~~~ clojure
+ (map (compose string-reverse string-downcase) (list "David" "Alicia" "Lucie"))
+~~~
 
 Well, since this scheme example doesn't require a receiver it's actually a bit of cheating. <strong>But then again,
 using a language like scheme does always feel a bit like cheating ;)</strong>
 In Scheme for example you can use the <strong>(cut)</strong> form to do just this.
 Observe the following:
 
-{% highlight scheme %}
+~~~ clojure
  (map (cut + 3 <>) (list 1 2 3 4))
-{% endhighlight %}
+~~~
 
 This is quite elegant and we don't need to go through all these hoops as we do in ruby.
 
 In Haskell this is equally well solved.
 
-{% highlight haskell %}
-map (+1) [1,2,3,4]
-map (1-) [1,2,3,4]
-{% endhighlight %}
+~~~ haskell
+ map (+1) [1,2,3,4]
+ map (1-) [1,2,3,4]
+~~~
 
 Also note how in Haskell you can create a section that specifies how to apply operators that are not commutative. The second map will for each value in the list compute the result of 1 - value.
 
-In Ruby we have the ability to use the Proc#curry to implement the same behavior. This however doesn't work well with our Symbol-Syntax. 
+In Ruby we have the ability to use the Proc#curry to implement the same behavior. This however doesn't work well with our Symbol-Syntax.
 
 To address this problem we can extend our code and give it the ability to partially apply the "Symbols".
 
 What I wanted it to look like is this:
 
-{% highlight ruby %}
+~~~ ruby
   [1,2,3,4].map(&:+[3])
-{% endhighlight %}
+~~~
 
 This would hopefully result in <strong>+</strong> being partially applied to 3 and mapped over the list of values. To achieve that we need to adjust our code from above:
 
 
-{% highlight ruby %}
-class Filter
- attr_reader :the_method,:arguments
+~~~ ruby
+ class Filter
+  attr_reader :the_method,:arguments
 
-  def initialize(the_method,*arguments)
-    @the_method = the_method
-    @arguments = arguments
-  end
+   def initialize(the_method,*arguments)
+	 @the_method = the_method
+	 @arguments = arguments
+   end
 
-  def to_proc
-    ->(r){ apply(r) }
-  end
+   def to_proc
+	 ->(r){ apply(r) }
+   end
 
-  def apply(r)
-    r.send(the_method,*arguments)
-  end
-end
+   def apply(r)
+	 r.send(the_method,*arguments)
+   end
+ end
 
 
-class Symbol
-  def |(other)
-    FilterChain.new | Filter.new(self) | Filter.new(other)
-  end
+ class Symbol
+   def |(other)
+	 FilterChain.new | Filter.new(self) | Filter.new(other)
+   end
 
-  def [](*args)
-    Filter.new(self,*args)
-  end
-end
-{% endhighlight %}
+   def [](*args)
+	 Filter.new(self,*args)
+   end
+ end
+~~~
 
 The definition of the FilterChain-Class didn't change, but we had to prepare Symbol and Filter to make this work. Pretty easy, wasn't it?
 
 Now open up your irb and try it out!
 
-## But does it still compose? 
+## But does it still compose?
 
 Let's see if the following works:
 
-{% highlight ruby %}
+~~~ ruby
 
 puts [1,2,4,4].map(&:*[3] | :+[10])
 
 #=> undefined method `|' for #<Filter:0x00000001a80a88 @the_method=:*, @arguments=[3]> (NoMethodError)
 
-{% endhighlight %}
+~~~
 
-Not Quite! There is one piece missing. Filters need to be able to be actually glued together. 
+Not Quite! There is one piece missing. Filters need to be able to be actually glued together.
 
 Easy enough to add. Here's the final version with a bit of polishing.
 
 ## Final Version
 
-{% highlight ruby %}
-module Pipeable
-  def |(other)
-    FilterChain.new | self | other
-  end
-end
+~~~ ruby
+ module Pipeable
+   def |(other)
+	 FilterChain.new | self | other
+   end
+ end
 
-class FilterChain
-  def initialize
-    @filters = []
-  end
+ class FilterChain
+   def initialize
+	 @filters = []
+   end
 
-  def |(filter_or_symbol)
-    @filters << (filter_or_symbol.is_a?(Symbol) ? Filter.new(filter_or_symbol) : filter_or_symbol)
-    self
-  end
+   def |(filter_or_symbol)
+	 @filters << (filter_or_symbol.is_a?(Symbol) ? Filter.new(filter_or_symbol) : filter_or_symbol)
+	 self
+   end
 
-  def to_proc
-    ->(r){ @filters.inject(r){ |o,f| f.apply(o) } }
-  end
-end
+   def to_proc
+	 ->(r){ @filters.inject(r){ |o,f| f.apply(o) } }
+   end
+ end
 
-class Filter
-  include Pipeable
+ class Filter
+   include Pipeable
 
-  attr_reader :the_method,:arguments
+   attr_reader :the_method,:arguments
 
-  def initialize(the_method,*arguments)
-    @the_method = the_method
-    @arguments = arguments
-  end
+   def initialize(the_method,*arguments)
+	 @the_method = the_method
+	 @arguments = arguments
+   end
 
-  def to_proc
-    ->(r){ apply(r) }
-  end
-  
-  def apply(r)
-    r.send(the_method,*arguments)
-  end
+   def to_proc
+	 ->(r){ apply(r) }
+   end
 
-  alias_method :call,:apply
-  alias_method :[],:apply
-end
+   def apply(r)
+	 r.send(the_method,*arguments)
+   end
 
-class Symbol
-  include Pipeable
+   alias_method :call,:apply
+   alias_method :[],:apply
+ end
 
-  def [](*args)
-    Filter.new(self,*args)
-  end
-end
-{% endhighlight %}
+ class Symbol
+   include Pipeable
 
-{% highlight ruby %}
-puts [1,2,4,4].map(&:*[3] | :+[10])
-{% endhighlight %}
+   def [](*args)
+	 Filter.new(self,*args)
+   end
+ end
+~~~
+
+~~~
+ puts [1,2,4,4].map(&:*[3] | :+[10])
+~~~
 
 <pre>
     13
 
 
 
-That's a lot of code to get these kinds of things working. 
+That's a lot of code to get these kinds of things working.
 
-## Is it worth it? 
+## Is it worth it?
 I don't know. I actually doubt it a bit, but it was fun to experiment with it!

File _posts/2013-01-19-the_pragmatism_dogma.md

View file
 title: The pragmatic tar pit
 tagline: about undeliverable products
 tags: [rants,pragmatic]
+datestring: 2013-01-19
 ---
 
 

File _posts/2013-03-27-i_did_missbehave.md

View file
 layout: post
 title: I did mis(s)behave
 tagline: Lessons learned from a failed project
+datestring: 2013-03-27
 code:
   url: http://bitbucket.org/certainty/missbehave
   caption: missbehave
 tags: [scheme,missbehave,chicken,tdd,bdd,testing]
 ---
 
-<h3 class="statement">It is in our failures, that we learn the most important lessons</h3>
+<blockquote class="statement">&laquo; It is in our failures, that we learn the most important lessons &raquo;</blockquote>
 
-I guess it is really hard to admit that a project has failed. That's probably why many projects are taken
+It is really hard to admit that a project has failed. That's probably why many projects are taken
 further and further even though they have failed a long time ago.
 
 One of my failed projects is a little scheme library called [missbehave](http://wiki.call-cc.org/eggref/4/missbehave).
-I intended to provide a testing framework that could be used in [TDD](http://en.wikipedia.org/wiki/Test-driven_development) and especially in [BDD](http://en.wikipedia.org/wiki/Behavior-driven_development). It was inspired and mostly architectured after the really neat [rspec-library](http://rspec.info). If you're a ruby programmer
+
+I intended to provide a testing framework that could be used in [TDD](http://en.wikipedia.org/wiki/Test-driven_development) and especially in [BDD](http://en.wikipedia.org/wiki/Behavior-driven_development). It was inspired and mostly designed after the really neat [rspec-library](http://rspec.info). If you're a ruby programmer
 and you don't know it yet, go ahead and give it a try.
 
 
 ### How did it fail?
 
 Well the most obvious thing I realized was that even I as the developer of the library didn't use it much.
-I used it to some extend, but whenver I wanted to make sure things work and I had to get things done, I switched to the [defacto
+I used it to some extend, but whenever I wanted to make sure things work and I had to get things done, I switched to the [defacto
 testing library for chicken scheme](http://wiki.call-cc.org/eggref/4/test).
 And so did others.
 
-There weren't many who tried the library, and when they did they immediatly recognized problems.
+There weren't many who tried the library, and when they did they immediately recognized problems.
 Fixing those problems became harder and harder, which is another indicator for a failed project.
 
 While it did provide some new and useful features, it was just another testing library, and there
 Let me walk you through the parts of the library that are the reason for its failure. There are things that I really like about
 the library which I will outline in [the good parts](#missbehave_the_good_parts).
 
-#### Behavior verification
+
+#### 1) Behavior verification
 
 That's one of the things the library aimed at. I intended to enable BDD in scheme.
 The problem with that is that most of the testing techniques that currently exist
-to support BDD are alien or at least unnatural for scheme. Let me decsribe shortly what that
+to support BDD are alien or at least unnatural for scheme. Let me describe shortly what that
 normally looks like and you'll realize that this is not what scheme is about most of the time.
 
-BDD by definition is an outside-in approach, or top-down, or interface-first.
-This means that the programmer starts with the definition
-of the interface and works his way from the outermost layer inwarts.
-
-Interface in that context can indeed be the GUI or more commonly protocols
-describing the services a particular '''object''' provides. It is common to test behavior with objects that have not been implemented at that
-point. This is done by using test doubles or mocks which are used as replacement for the actual thing that will be implemented later.
-Often these mocks represent [depended-on components (DOCs)](http://xunitpatterns.com/DOC.html) that the  [system under test (SUT)](http://xunitpatterns.com/SUT.html) interacts with. So if we want not make sure that the SUT behaves as expected, we can not do that by just looking
-at its direct output; instead we have to verify it through indirect output performed on the DOC. A method call does not just return
+BDD is an outside-in or top-down or interface-first approach to testing.
+This means that the programmer starts with the definition of the interface and works his/her way from the outermost layer inwards.
+Interface in that context can indeed be the GUI, external APIs or just protocols describing the services a particular '''object''' provides.
+It is common to test behavior with objects that have not been implemented at that point.
+This is done by using test doubles which are used as replacement for the actual thing that will be implemented later.
+Often these doubles represent [depended-on components (DOCs)](http://xunitpatterns.com/DOC.html) that the [system under test (SUT)](http://xunitpatterns.com/SUT.html) interacts with. So if we want not make sure that the SUT behaves as expected, we can not do that by just looking
+at its direct outputs; instead we have to verify it through indirect output performed on the DOC. This is often done by placing
+expectations on the DOC about which method will be invoked with what arguments. A method call does not just return
 a value (if it does), but also invokes methods on DOCs, that have often been injected. See also [dependency injection DI](http://xunitpatterns.com/Dependency%20Injection.html).
-
 This type of testing is called [behavior verification](http://xunitpatterns.com/Behavior%20Verification.html).
 
 In functional programs or mostly functional programs, we don't have these
-kinds of functions. We are in the fortunate position to be able to determine the correctness of a function just by looking
-at the return value of the function. Indirect outputs would normally be side-effects in this context.
+kinds of functions. We are in the fortunate position to be able to determine the correctness of a referentially transparent function just by looking
+at the arguments and the return value of the function. Indirect outputs would normally be side-effects, which don't exist in pure functions.
 
-That doesn't mean that scheme programs don't have side-effects, but they are rare and generall discouraged.
+That doesn't mean that scheme programs don't have side-effects, but they are rare and general discouraged.
 That again means, that I have provided a library that eases the testing/development of a small fraction of the code that you typically produce in scheme.
 That's not very useful, is it? So the bad idea here was:
 
-<h3 class="statement">I worked against the language and its characteristics.</h3>
+<blockquote class="statement">&laquo; I worked against the language, its characteristics and idioms &raquo;</blockquote>
 
-Functional programs aren't about behavior, but rather about values and computation. That doesn't mean that functional systems don't have behavior, but they don't interest us much when we apply tests to the system.
+Functional programs aren't about behavior, but rather about values and computation. That doesn't mean that functional systems don't have behavior, but they don't interest us as much when we apply tests to the system.
 
-#### Trust
 
-Even I didn't have much trust in it. This may be partly
-due to the messi implementation and partly because there really were things that just didn't work.
-This lowered the overall trust in the library, and trust is an essential property of a tool that you use to make sure
-that your code works. That means that the testing tool needs to work correct and work well.
+#### 2) Procedure expectations
 
+Since scheme programs are usually not build in a OO fashion with compound objects and complicated hierarchies based on types, I provided a way
+to verify that a certain function has been called. Additionally you could verify that it has been called given times and with given arguments. This is an essential feature if you apply OOish behavior verification to scheme.
 
-#### Procedure expectations
+~~~ clojure
+ (use missbehave missbehave-matchers srfi-1)
 
-Since scheme programs are usually not build in a OO fashion with compound objects and all that stuff, I provided a way
-to verify that a certain function has been called. Additionally you could verify that it has been called a certain amount
-of time and and with given arguments. The following is an example of that.
+ (define (shuffle ls)
+   (sort ls (lambda _ (zero? (random 2)))))
 
-{% highlight scheme %}
-(use missbehave missbehave-matchers srfi-1)
+ (define (yodize str)
+   (string-intersperse
+	 (shuffle
+	   (string-split str " "))))
 
-(define (shuffle ls)
-  (let ((len (length ls)))
-    (if (< len 2)
-        ls
-        (let ((item (list-ref ls (random len))))
-          (cons item (shuffle (remove (lambda (i) (equal? i item)) ls)))))))
-
-(define (yodize str)
-   (string-intersperse
-    (shuffle
-      (string-split str " "))))
-
-(context "procedure expectations"
-  (it "calls shuffle once"
-     (expect (yodize "may the force be with you") (to (call shuffle once)))))
-
-{% endhighlight %}
+ (context "procedure expectations"
+   (it "calls shuffle once"
+	 (expect (yodize "may the force be with you") (to (call shuffle once)))))
+~~~
 
 As I pointed out earlier, this can be useful in some situations, but those are rare.
-A point that is irrelevant to the user of the library is that the implementation of procedure expectations is somewhat hacky and brittle.
-It is implemented using a lot of mutation.
+There is an additional problem, which is not so important for the client programmer, but still a reason I don't like that feature, is the implementation of
+that mechanism.
 
+<strong>Admission:</strong> It is implemented using a lot of mutation.
 
-#### Stubs and mocks
 
-As I explained in behavior verification it is common to introduce test doubles so the library added a possibility to mock procedures.
-Though the general idea might be pleasing the particular implementation didn't feel right.
-I essentially redefined the procedures to have the desired behavior. Also I made again heavy use of the [advice egg](http://wiki.call-cc.org/eggref/4/advice) to do this. See the following example that stubs the result of (car).
+#### 3) Stubs and mocks
 
-{% highlight scheme %}
-(use missbehave missbehave-matchers missbehave-stubs srfi-1)
-(stub! car (returns '()))
-(car (list 1 2 3))
-(car '())
-{% endhighlight %}
+As I explained it is common, in behavior verification, to introduce test doubles, so missbehave added a possibility to mock procedures.
+Though the general idea might be pleasing, the particular implementation didn't feel right.
+I essentially <strong>redefined</strong> the procedures to have the desired behavior. Also I made again heavy use of the [advice egg](http://wiki.call-cc.org/eggref/4/advice) to do this. The following example shows how to stub the result of (car).
 
-Procedure stubs aren't that useful since in functional languages we are more concerned about the outcome, rather than if a procedure
-was invoked. Most likely we will have an interface that accepts a procedure or uses a paramater. For both cases we can
+~~~ clojure
+ (use missbehave missbehave-matchers missbehave-stubs srfi-1)
+
+ (stub! car (returns '()))
+ (car (list 1 2 3))
+ (car '())
+~~~
+
+Procedure stubs aren't that useful in scheme, since in functional languages we are more concerned about the result of a procedure, rather than if it has been
+invoked. Most likely we will have an interface that accepts a procedure or uses a parameter. For both cases we can
 provide implementations that fit in our tests, without resorting to replacing a function's implementation. That's a natural
-property of higher order functions. Actually it's the defining property of them.
+property of higher order functions. In essence I tried to solve a problem, that isn't there.
 
-#### Hooks
+#### 4) Hooks
 
 A key part of the library are contexts. Contexts are a snapshot of the world in a given state. They supported hooks that could
-be used to setup a certain state of the world at a given point in time or rather at a given time inside the test cycle.
-In traditional test frameworks this is were your setup and teardown code resides. The following example illustrates this:
+be used to setup a certain state of the world at a given point in time.
+In traditional test frameworks this is where your setup and tear-down code resides. The following example illustrates this:
 
-{% highlight scheme %}
-(use missbehave missbehave-matchers missbehave-stubs srfi-1)
+~~~ clojure
+ (use missbehave missbehave-matchers missbehave-stubs srfi-1)
 
-(context "context with hooks"
-  (before :each (set! ($ 'answer) 42))
-  (it "should have the answer"
-    (expect ($ 'answer) (to (be 42)))))
+ (context "context with hooks"
+   (before :each (set! ($ 'answer) 42))
+   (it "should have the answer"
+	 (expect ($ 'answer) (to (be 42)))))
+~~~
 
-{% endhighlight %}
+As it turns out, this feature is really bad since it embraces mutable state and even worse, it hides when the mutation happens.
+It's way clearer to just use let-bindings to share values across examples and use an explicit set! if you must.
 
-As it turns out, this feature is really bad since it embraces mutable state and what it's even worse, it hides when the mutation happens.
-It's way clearer to just use let-bindings to share values accross examples and use an explicit set! if you must.
+#### 5) The runner
 
-#### The runner
+This is something that turned out to complicate things. The library comes with an executable that is used to run missbehave tests. This means that
+you can not just run the test file itself using csi. That also means that you can't compile your test file which also means you can not use of FFI calls.
+Also the chicken CI expects the tests to work in a certain way and without going through some hoops it was not possible to run missbehave in the
+context of [salmonella](http://tests.call-cc.org/). I added a way to do that later, as the following example shows:
 
-This is something that turned out to complicate things. The library comes with a binary that is used to run missbehave tests. This means that
-you can not just run the test file itself using csi or something. That also means that you can't compile your test file. This is really unfortunate
-as the chicken CI expects the tests to work in a certain way and without going through some hoops it was not possible to run missbehave in the
-context of [salmonella](http://tests.call-cc.org/). I added a way to dot that later, as the following example shows:
-
-
-{% highlight scheme %}
+~~~
 (use missbehave missbehave-matchers missbehave-stubs srfi-1)
 
 (run-specification
     (make-empty-specification
       (lambda ()
         (it "should work")))))
+~~~
 
-{% endhighlight %}
-
-Not exactly short, but it did work to some degree. The more problematic part was, again, an implementation defail. I had to go through some hoops
-to make the runner work. It used some hacks in conjunction with eval that I'm not very proud of. You can check the [sourcecode](https://bitbucket.org/certainty/missbehave/src/578b051764092dab0c5bd9c7d66640f44d281c25/behave.scm?at=default#cl-231) if you want to see it.
+Not exactly short, but it did work to some degree. The more problematic part was, again, an implementation detail.
+I had to use some hacks in conjunction with eval that I'm not very proud of. You can check the [sourcecode](https://bitbucket.org/certainty/missbehave/src/578b051764092dab0c5bd9c7d66640f44d281c25/behave.scm?at=default#cl-231) if you want to see it.
 
 The last problem is that the way it was designed, it didn't work well (read: "didn't work at all") in the REPL and thus you could
-not use it to throw in some quick verifications to prove that you're on the right track.
+not use it to throw in some quick verification right into the REPL to prove that you're on the right track.
 That is really something that is bad for a lisp.
 
 
+<blockquote class="statement">&laquo; I provided tools that didn't support the programming workflow &raquo;</blockquote>
+
+#### 6) Trust
+
+This is a somewhat non-technical problem, but still I think it was a reason why the library failed.
+Even I didn't have much trust in it. This may be partly
+due to the messy implementation and partly because there really were things that just didn't work.
+This lowered the overall trust in the library, and trust is an essential property of a tool that you use to make sure
+that your code works. That means that the testing tool needs to work correct and work well.
+
+
 
 ### Missbehave: the good parts
 
-Now that I've showed you the bad parts, it's time to look at the things that I didn't mess up totally. There are some things that are valuable and
-nice to have. Indeed some of these things will make it into a new library that intents to honor the language more. It's a work in progress, but
+Now that I've showed you some of the bad parts, it's time to look at the things that I didn't mess up totally. There are some things that are valuable.
+Indeed some of these things will make it into a new library that intents to honor the language more. It's a work in progress, but
 if you're curious you can take a peek at [veritas](https://bitbucket.org/certainty/veritas).
 
-
 #### The matcher abstraction
 
-missbehave introduced i thing called a matcher that was used to verify expectations. A matcher is
+Missbehave introduced an abstraction called a matcher, that was used to verify expectations. A matcher, in missbehave, is
 a higher order function that knows how to verify the behavior of the subject that is passed to it.
 Also it knows how to generate messages for the failure and success case.
 Matchers serve two goals.
 
-1. they are a means to extend the test library. That's a very lispy approach as lisp itself is intended to be extended
+1. They are a means to extend the test library. That's a very lispy approach as lisp itself is intended to be extended
   by custom functions that look as if they belong to the lisp/scheme core itself.
 
-2. the shall improve the expressiveness of the test. By creating clever matchers the source code
+2. They shall improve the expressiveness of the test. By creating clever matchers the source code
   is able to express what happens more clearly, possibly using vocabulary from the problem domain.
 
-The following code snippet shows these matchers and compares it to the equivalent tests using the [test egg](http://wiki.call-cc.org/eggref/4/test).
+The following code snippet shows the matcher abstraction to provide new matchers.
+
+~~~ clojure
+ (use missbehave missbehave-matchers srfi-1)
+
+ (define (contain what)
+   (matcher
+	(check (subject)
+	  (member what (force subject)))
+	(message (form subject negate)
+	  (if negate
+		(sprintf "Expected ~a not to contain ~a" (force subject) what)
+		(sprintf "Expected ~a to contain ~a" (force subject) what)))))
+
+ (expect (iota 10) (to (contain 3)))
+~~~
+
+There are quite many matchers that are built into the library, but
+you can also provide your own with ease. It provides nice messages and enables more expressive tests.
+Note that you can achieve something like that using the [test egg](http://wiki.call-cc.org/eggref/4/advice) as well.
+
+~~~ clojure
+ (use test)
+
+ (define contains (flip member)))
+
+ (test (contains (iota 10) 5))
+~~~
+
+This exploits the fact that the test-library uses a pretty printed form of the expression as the title for the test if no title has
+been given. For more complicated things, this doesn't work so well though. Also note that missbehave does a similar thing if
+you use the simplest form:
+
+~~~ clojure
+ (use missbehave missbehave-matchers srfi-1)
+
+ (expect (> 2 1))
+~~~
+
+This will automatically generate a message that uses the expression itself.
+
 
 #### Meta information and filters
 
 The library provided a way to attach meta data to examples and contexts. The user could then use filters to run only examples that
-have corresponding meta data. This is a valuable feature as it gives you fine grained control on which tests are run.
+have corresponding meta-data. This is a valuable feature as it gives you fine grained control over which tests are run.
 For example you might have platform dependent tests, that you only want to run on the matching platform. You could tag your tests
 with the OS they support and run them filtered. Another example would be fast and slow tests, where you generally want to run the slow tests
-during CI but not so much during development. I think this is really useful, but it should be opt-in. And it should be orthogonal to the
-other features. In missbehave the syntax for examples and contexts supported a variation that was used to declare metadata.
-In that regard this feature was bound to the syntax of these things. What I want instead is to let this be composable and usable "a la carte".
-That means you want to be able to mix and match contexts and meta-data and examples and meta-data without requiring them to know from each other.
+during CI but not during development. I think this is really useful, but it should be opt-in. And it should be orthogonal to the
+other features. In missbehave the syntax for examples and contexts supported a variation that was used to declare meta-data.
+In that regard this feature was bound to their syntax. What I want instead is to let this be composable and usable "a la carte".
+That means I want you to be able to mix and match contexts and meta-data  without requiring them to know from each other.
 
 In missbehave it looks something like this:
 
+~~~ clojure
+ (use missbehave)
 
-What I currently have in mind for veritas is:
+ (context "Test"
+   (it "has some meta-data" (meta ((issue-id . 1234)))
+     (expect #t)))
+~~~
 
-{% highlight scheme %}
-(use veritas)
+As a sneak preview, this is what I currently have in mind for veritas:
 
-(meta (os: 'linux pace: 'slow)
-  (verify #t))
+~~~ clojure
+ (use veritas)
 
-(meta (os: 'linux)
-  (context "this is some context"
-    (verify #t)))
+ (meta (os: 'linux pace: 'slow)
+   (verify #t))
 
-{% endhighlight %}
+ (meta (os: 'linux)
+   (context "this is some context"
+	 (verify #t)))
+~~~
 
-So that's completely orthogonal to the notion and syntax of contexts and examples. Also I want meta data to compose in the way that
-nested meta data "adds up", so that the inner most expression holds the union of all meta data surrounding it.
+So that's completely orthogonal to the notion and syntax of contexts and examples. Also I want meta-data to compose in the way that
+nested meta data "adds up", so that the inner most expression holds the union of all meta-data surrounding it.
 
 #### Pending tests
 
 Pending tests are extremely valuable and I don't quite understand why they are not supported by the test egg, or at least not directly.
 As the name suggests you can temporarily disable the execution of tests by marking them pending. The point is that these tests aren't run,
-but they are reported as being pending, so that you know that they are actually there. This means, that you can't accidently forget them.
+but they are reported as being pending, so that you know that they are actually there. This means, that you can't accidentally forget them.
 In missbehave you can define a pending tests in two ways. The first way is to mark it explicitly as pending as the following example shows:
 
-{% highlight scheme %}
-(use missbehave missbehave-matchers missbehave-stubs )
+~~~ clojure
+ (use missbehave missbehave-matchers missbehave-stubs )
 
-(describe "Pending"
- (it "is explicitly pending"
-   (pending)
-   (expect '() (be a number))))
-{% endhighlight %}
+ (describe "Pending"
+  (it "is explicitly pending"
+	(pending)
+	(expect '() (be a number))))
+~~~
+
 
 As you see you could add a call to pending at any point in the expectation which would make the expectation exit early and skip the
 verification machinery. The second way is to make an example implicitly pending by omitting the body.
 
-{% highlight scheme %}
-(use missbehave missbehave-matchers missbehave-stubs )
+~~~ clojure
+ (use missbehave missbehave-matchers missbehave-stubs )
 
-  (describe "Pending"
-     (it "is implicitly pending"))
-
-{% endhighlight %}
+ (describe "Pending"
+   (it "is implicitly pending"))
+~~~
 
 This is especially nice, if you start by outlining the things you intend to test and then you fill in the actual code.
 This way it's hard to forget some of the tests.
 So this is really something that is valuable and will be added to veritas as well, but in a slightly different way.
 Again I want it to be usable a-la-carte and compose well. This is what it will probably look like in veritas:
 
+~~~ clojure
+ (use veritas)
 
-{% highlight scheme %}
-(use veritas)
-
-(pending
-  (context "this is some context"
-    (verify #t)))
-
-(pending "some reason"
- (verify #f))
-
-{% endhighlight %}
+ (pending "some reason"
+  (verify #f))
+~~~
 
 ### What now?
 
 As I wrote before, I have learned from my failures and work on a testing library that incorporates the good parts and throws away the bad parts.
 This library will be called veritas and is a work in progress. It will further more encourage the use of quick-check like
-automated value generators as well as using the REPL as a host to run tests interactively. I'll post about it once it's ready.
+automated value generators as well as using the REPL as a host to run tests interactively. To support this style of testing
+I currently work on a library that provides combinators to generate data. You can have a look here both projects here:
 
+* [veritas](https://bitbucket.org/certainty/veritas)
+* [data-generators](https://bitbucket.org/certainty/data-generators)
 
-### Wrapup
+### Wrap up
 
 I hope you enjoyed this little journey through all my failures. It has certainly been a pleasure for me and a healthy way to look at the "monster" I've made.
-I'm sure there is still alot to learn for me and I'm open to it. I want to thank all the helpful people that provided valuable feedback for this post
+I'm sure there is still much to learn for me and I'm open to it. I want to thank all the helpful people that provided valuable feedback for this post
 and for missbehave. I for one will continue to improve, which means I will continue to fail. Promised! ;)

File assets/css/style.scss

View file
 
 /* posts */
 
-h1 {
+h1,h3,h2{
   color: #D52932;
 }
 
+h4 {
+  color: #333;
+}
+
+h3 {
+  border-bottom: 1px solid #D52932;
+}
+
+h3.preview {
+  border-bottom: none;
+}
+
 a, a:active, a:link, a:visited {
  color: #0a6c0a;
 }
 
 content a, a:link, a:visited, a:focus, a:hover, a:active {
- color: #D52932;
+ color: $link_red;
 }
 
+
 .tag_box {
 	list-style:none;
 	margin:0;
     text-align: center;
     margin: 40px;
     font-style: italic;
+    color: #333;
+    border-bottom: none;
 }
+