Simo Råman
True team has no foreman
I read a blog post titled “Where is the Foreman?” by Robert C. “Uncle Bob” Martin. In his post Uncle Bob suggests that software projects, like construction sites, need a role of Foreman. He describes Foreman as someone who is responsible for making sure projects is done as it should, essentially signing off everybody’s work.
I assume . . .
Test Driving F#: String Calculator Kata
I finally took the time to code some F# again. This time I tried out Roy Osherove's String Calculator kata.
This was the first time I did development on a Mac using Mono. The experience was surprisingly pain-free. The biggest problem I had was MonoDevelop hanging when debugging. I was afraid that I would have to setup external . . .
Posted in: f#
Testing CoffeeScript with Mocha and Phantom.js
Introduction
One of my pet peeves with writing test-driven javascript is the difficulty initial setup. It feels that there is bunch of libraries I need to install to even get going with basics. I set up a simple template that has the very basics for doing test-driven development with javascript. Here is an explanation of what it . . .
Removing search from Zelect
I have recently worked on a project that uses the excellent zelect-libraryfor dropdowns.
There was a requirement to take out the search box on the list. There might be several ways to tackle this, but here is what I came up with.
My first thought was to simply hide it by setting search box element to display:none; . . .
Test driving F#: Bowling game
(published originally February 1, 2013 at simoraman.wordpress.com)
Some time ago I blogged about my first experience with F#. I took a course Functional Programming Principles in Scalarecently and it somewhat opened my eyes on problem solving in functional style. After that I felt confident enough to do something more complex than fizzbuzz with F# so the logical next step was Bowling game kata.
. . .
Posted in: f#
Code coverage with OpenCover
(published originally January 1, 2013 at simoraman.wordpress.com)
One of the most useful things you can measure in your code base is code coverage. Basically it means how many lines of your production code gets executed by your test suite. In theory developing with TDD should bring 100% coverage, because no code is ever written before there is a test for it. In practice code bases end up with parts that . . .
Test driving F#: FizzBuzz
(published originally September 19, 2012 at simoraman.wordpress.com)
I have been interested in F# for a long time, but haven't taken the time to actually do anything with it. Finally I decided to try and use it to implement the good old FizzBuzz. I used fsUnit as a unit test framework.
Here are the tests I ended up with:
[<TestFixture>]
type ``When to Fizz`` ()=
[< . . .
Posted in: f#