Thinking about - week 38

All videos can be found on

Doc Norton - The Technical Debt Trap

The danger occurs when the dept is not paid back. Every minute spent on not so good code counts as interest in that dept. Technical dept is good.

People are confused the dept metaphor with the idea that you could write code poorly.

Code must be clean enough to be able to refactor! (always) - Otto: so Tests are there…., well tested :)

Ask yourself:

I any of these are missing it is not technical dept. It is a mess!!!

Remember quality is your responsibility.

NEVER ask permission to do job correctly.

When monitoring complexity track trends not points. (exact values are meaningless but tends are meaningful).

Brendan Forster - 10 Things Ive Learned From Doing OSS

Enrico Campidoglio - Why no code reviews

Problem 1 is about Ego. EGO=1/Knowledge. The less the knowledge the greater the EGO.

Problem 2: you == your code

Problem 3: Fear of making mistakes. Fear of let colleges see my mistakes

Problem 4: Culture o(lack of it) “you are wrong”…. See Ego!

Do not review the person. REview the code. Do not speak in absolute. Fools are speaking absolute.

Time: it need time.

NB: Good diagram about productivity of a geek

What do you get from code review?

When you know that someone is watching you will take care of you code more. “The Big Brother EEffect”

It can eager ambition because yo want to impress your programmer fellow.

Give constructive feedback.

In a project everyone is in the same boat. (Sometimes I do not have the feeling - Otto - But we have to trust people that they are doing their bests)

Kind of review

  1. Formal code review. Most bugs found
  2. Over the shoulder code review. Less former. Less bug to be found
  3. Async code review. Happen async to the code written. “distributed”. IT happens offline. Good compromise in nr of bugs found and time.

Tools: - Gerrit, Diffy


  1. review small portions of code at a time. One commit one logical change.
  2. keep and follow a checklist
  3. keep under 1 hour

Aral Balkan - Free is a Lie

Interesting and shocking conspiracy theory how Google/Facebook is ruling our life and data…

Sep 19, 2014

Thinking about - week 37

All videos can be found on

Venkat Subramaniam - Core Software Design Principles

Basic Design and OO principles. Simple and good. DRY, SOLID, tell don’t ask, etc.

Anders Abel - Using the Scrum Rules Against your Boss

Basic Scrum but important for those who are using Scrum as a hipe then realize that it is not working for him:

Only accept those produce backlogs which are clear.

Venkat Subramaniam - Towards an Evolutionary Architecture

Interesting stories but there are not so many specifics. It emphasizes that we have to think about flexible architecture consciously.

Robert C. Martin - Clean Architecture and Design

As in last year. Maybe in an other conference.

Mike Cohn - Advanced Topics in Agile Planning

I have seen that last year too.

Steve Sanderson - Architecting large Single Page Applications with Knockout.js

I have to watch again…. Looks good but it was very fast.

Robert C. Martin - Advanced TDD The Transformation Priority Premise

Good but I have learned the same concept through

Robert C. Martin - Functional Programming What Why When

Thinking about Functional programming. Why it is so important to be ware of functional paradigm for our programming future.. On the other hand the presentation is made already in an other conference and available online too.

Mike Cohn - Getting Agile with Scrum

Scrum 101 :(

Sep 11, 2014

Thinking about - week 36

What Makes a Good Programmer?

1 - Problem Decomposition

But before you write any code, you need to be clear on how to solve the problem. One skill good programmers have is the ability to break the problem down in smaller and smaller parts, until each part can be easily solved. … A good programmer finds a way to model the problem in such a way that the resulting program is easy to reason about, easy to implement and easy to test.

2 - Scenario Analysis

the ability to consider many different scenarios for the program. This applies both to the logic in the program, and to the internal and external events that can occur. …

The good programmers ask themselves: How can this break? In other words, they have the ability to think like testers. In contrast, inexperienced programmers mostly only consider the “happy path”

3 - Naming

Programming consists to a large degree of naming things: classes, methods and variables. When done well, the program becomes largely self-documenting,

(from Phil Karlton): “There are only two hard things in Computer Science: cache invalidation and naming things.”

naming is hard because it needs to be clear in your mind what each name represents.

4 - Consistency

the biggest challenge in programming is managing complexity. Consistency is one way to combat complexity.

5 - Learning

As a software developer, you are constantly learning. Before adding a new feature, you have to understand what it is supposed to do. Before adding code to an existing program, you usually have to learn what the existing code does, in order fit the new functionality in properly

Spring pitfalls: transactional tests considered harmful

It is highlighting some important aspect. Examples are mostly about Hibernate and other JPA implementations. Some of the examples are not relevant it you are not using JPA.

I am using transactional test for SQL syntax check only. As you might know SQL cannot be unit tested (semantic of SQL) You could not test declarative tool with declarative toolset.

The proposed solution is to load a fresh database which might be working for h2 database but for a big monster like Oracle is a questionable solution.

Stand-ups are Broken, but Should They be Fixed?

on every team I’ve ever been on, if there’s a customer (or scrum-master or project manager) present, the meeting always turns into a status report.

If you have a good visible taskboard you do not need to report anything because it is visible on the wall.

The stand-up meeting was created to solve a particular problem—developers don’t always talk to each other. … if your team is working in the same war-room or communicates frequently through other means, it’s probably not necessary to have everybody discuss explicitly what they are doing.

Despite the desire for an On-Site Customer, most teams do not have their customer available all the time,

Oh, yes. At the end of the iteration/sprint is just fine for most of the customers.

Scrum, velocity, and driving down the motorway the wrong way

Velocity is in essence a negative metric – it can tell you that something is wrong, but not that something is good.

Velocity is a nice metric for internal process monitoring, so you can spot problems early. But beware of using a negative metric such as velocity as your primary measure of success, it leads down the path of false hyperproductivity and a warm feeling that you’re doing something good when in fact you might be driving the wrong way down a motorway, with a truck heading straight at you.

Nightmare on Agile Street

A very humorous story about an Agile project which is not so agile. Or more precisely about a project in which stakeholders are remembering those aspects of agile what they prefer and ignoring the rest. And the result is a total disaster.

A few weeks ago I had a similar (not so extreme) feeling and I wanted to cancel the project too. But… :)

Does Speaking Another Language Change How You Think?

Language is a tool that fills the needs of its speakers.

Languages also have expressions and words for concepts that don’t match one-to-one But, again, it’s a nuance in expression, the same fundamental thoughts can be conveyed fairly equally in most languages, plus or minus a bit of brevity.

The big way that learning a new language changes your thinking is that language is a gateway to culture

language is a preferential route for cultural understanding (albeit a difficult one)

The Language Learning Experience Changes How You Think

Sep 04, 2014

JUnit IgnoreRest - turn 2

In the previous IgnoreRest article I was complaining about that it is not notifying IDE properly without a custom test runner.

So I have implemented the runner I need.

  public class IgnoreRestSupportRunner extends BlockJUnit4ClassRunner {
    public IgnoreRestSupportRunner(Class<?> klass) throws InitializationError {

    protected void runChild(final FrameworkMethod method, RunNotifier notifier) {
      IgnoreRest ignoreRestAnnotation = method.getAnnotation(IgnoreRest.class);
      Description description = describeChild(method);
      if (IgnoreRestHelper.hasIgnoreRestAnnotation(description) && null == ignoreRestAnnotation) {
      else {
        super.runChild(method, notifier);

And that is all. Nothing else. All the remining code needed is extracted from the previous implementation. For supporting Spring I have to make use exactly the same code but the base class has to be SpringJUnit4ClassRunner.

So the only runner I have to deal with is the junit-hierarchicalcontextrunner .

Source is available on GitHub

Aug 31, 2014

Do we really need JQuery validator plugin?

The more I need to do some HTML client side validation the more I am asking myself whether we need a validation framework or not.

Until now I have not used any specific validation framework. But now I have to because I do not want to take care of simple syntax level (number field could accept numbers only, etc.) field validation.

First of all I have used developers best friend: Google . I have found numerous validation framework for JQuery (just have a look at the Google search result in the previous links).

I have check many of them and found that most of them are too complicated to my need (remember, I need simple syntax check because complex validation is made on server side).

The client side I wanted to make something simple and declarative:

  <form:input path="duration.hour" cssClass="form-control" maxlength="2" data-validation-pattern="^([01]?[0-9]|2[0-3])?$"/>

This is a simple Spring MVC input field. I have just introduced a custom data attribute called data-validation-pattern and the value is the regex pattern I want the check actual value test against. This specific example is checking an optional field which is accepting hours (0-23) of a day.

The expected behavior is that when any error happens I do not want to submit the form.

  $('#mrs_form').submit(function(event) {
    var validator = new MeetingValidator('#mrs_form');

    if (!validator.checkValidity()) {

So far, so good.

Let’s implement the validator:

  function MeetingValidator(form_selector, options) {
    "use strict";
      on_finished : function() {}
    options = $.extend({}, DEFAULT_OPTIONS, options);
    var issues = [];

     * @return false if there are validation errors
    function checkValidity() {
      return _.isEmpty(issues);

    function checkRegexPattern() {
      $('[data-validation-pattern]', form_selector).each(function() {
        var name = $(this).attr('name');
        var patt = new RegExp($(this).data('validation-pattern'));
        var value = $(this).val();
        if (!patt.test(value)) {
            kind : 'pattern',
            name : name,
            value : value
    MeetingValidator.prototype.checkValidity = checkValidity;

Cool, isn’t it? In function checkRegexPattern there are 4 effective lines of code which is dealing with all what I need.

You could say: “But it is not enough I need to report errors to the user”. And I will say: “Yes, you are right!”

And here is the weakness of many validator plugins. They are not so flexible how to report the error. If you have a look at the code it has an optional input parameter called options with one relevant attribute called on_finished which is intended to be a function and called at the end of the validation process.

Let’s see in practice:

  $('#mrs_form').submit(function(event) {
    var validator = new MeetingValidator('#mrs_form', {
      on_finished : on_validation_finished

    if (!validator.checkValidity()) {

  function on_validation_finished(issues) {
    _.each(issues, function(issue) {
      $('input[name="' + + '"]').parents('.form-group').addClass('has-error');

Function on_validation_finished is simply mark the field (using bootstrap styles).

Enjoy it!

Aug 04, 2014

Thinking about - week 31

Stop Unit Testing Database Code

Writing tests that use an actual database is hard.

  • that results from tests against your test system have (almost) no meaning
  • that your tests will not cover some of the most complex aspects of your productive system
  • that you will start spending way too much time on tweaking tests rather than implementing useful business logic

Databases couldn’t be any less stateless. The whole idea of a database is to manage state. And that’s very complicated and completely opposite to what any unit test can ever model

My database unit testing is about testing SQL syntax only.

Flyway and jOOQ for Unbeatable SQL Development Productivity

  1. Database increment
  2. Database migration
  3. Code re-generation
  4. Development

Good combination of tools. I would like to use. But those Oracle DBA guys do not like using tools which are not used to (even if it is more advanced)

TDD != Unit Tests (and vise versa)

The post itself is not about this topic but the reaction on depate made around Test-induced design damage started by DHH.

The “Just In Time” Theory of User Behavior

I’ve long believed that the design of your software has a profound impact on how users behave within your software. But there are two sides to this story:

  • Encouraging the “right” things by making those things intentionally easy to do.
  • Discouraging the “wrong” things by making those things intentionally difficult, complex, and awkward to do.

The purpose of locks, the locksmith said, is to protect you from the 98% of mostly honest people who might be tempted to try your door if it had no lock.

10% of people will never steal, 10% of people will always steal, and for everyone else … it depends.

most people will consistently and reliably cheat “just a little”, to the extent that they can still consider themselves honest people.

Once upon a time I have made a test whether I am a good man. For example a good man does not steal. And first question: Have you ever taken a pen from your workplace for private use? Of course I did….

a simple reminder at the time of the temptation is usually all it takes for people to suddenly “remember” their honesty.

You do it by showing them …

  • the minimum helpful reminder
  • at exactly the right time
Jul 28, 2014

Computer has no brain

Computer has no brain

Jul 21, 2014

foldLeft implementation

foldeLeft (folding in general) is one of the most powerful functional construct. Clean, elegant and generic.

Almost all functional operations can be built on top of the fold functions. So you need to have one. Once you have foldLeft you got a bunch of “operation” in addition (see later).

A few example how foldLeft can be used:

I had a continuous need of implementing some min and max on collection and I wanted to add my functional FIterable . So I did.

  public interface F2<X, Y, Z> {
    public Z f(X p1, Y p2);

    public static interface Simple<T> extends F2<T, T, T> {

    public static interface Collector<V, S> extends F2<V, S, V> {


  public <C> C foldLeft(C init, F2<C, T, C> reducer) {
    for (T i : this.iterable) {
      init = reducer.f(init, i);
    return init;


  public void foldLeft() throws Exception {
    Integer res = FIterable(IList(1, 2, 3, 4)).foldLeft(0, new F2.Collector<Integer, Integer>() {
      public Integer f(Integer p1, Integer p2) {
        return p1 + p2;
    assertEquals(10, res.intValue());

    String longestString = FIterable(IList("aaaaa", "a", "qqqqqqqqqqq", "bb")).foldLeft("", new F2.Simple<String>() {
      public String f(String p1, String p2) {
        return p1.length() > p2.length() ? p1 : p2;
    assertEquals("qqqqqqqqqqq", longestString);
Jul 14, 2014

Inner class for stepdown rule

Inner and nested classes (static or not) are not only for passing as anonymous classes for other component or not to expose special derivatives to the public. It is also useful to organize your code layout to improve readability.

I present two usage of class to improve readability:

Group methods together

One the Clean Coders videos and also in the Clean Code book there is a specific section about functions and the way to organize the layout of them (look for The Stepdown Rule in section Functions).

The summary of this concept is to organize code the following way:

Applying all other rules in Clean Code it is a meaningful advice. For example when considering the rule of a function is doing one thing and a function has one abstraction level only we must have sever (private) method in the class. It is clear that the file can be difficult to review. Such a layout makes easy to identify which lower level function is belonging to which higher level function. So you could skip them if you are not interested in the lower level stuffs.

But modern IDE-s are not supporting this kind of formatting. When let IDE formatting the code all unction will be indented to the same level. Except….

Except we are introducing some kind of extra block which will be indented. And here we can use a nested class.

Before code

  void main(){
  void f1(){...}
  void f11(){...}
  void f12(){...}
  void f2(){...}

After (introducing only one layer of grouping):

  void main(){
    new F1().f1();
    new F2().f2();

  private class F1{
    void f1(){...}
    void f11(){...}
    void f12(){...}
  private class F2{
    void f2(){...}

Simplifying parameter passing

In service centric code base (like the one easy to make when using Spring , or simply a legacy code to take care ) you might start calling a service method with a small number input parameter which is increasing as we are going deeper and deeper in the call stack.


  void main(String in){
    f1(in, new List());

  void f1(String in, List collector){
    f2(some_other, collector, Option.WHATEVER);

And here it is an other case of using inner classes. Their only purpose is to make parameters class variable and simplify method calls.

  void main(String in){
    new F1(in, new List()).f1();

  private class F1{
    String in;
    List collector;
    Object some_other;
    Option whatever = Option.WHATEVER
    // constructor are not included in the sample. 
    void f1(){

Jul 07, 2014

JUnit IgnoreRest

Given a scenario that you do not want to run all you test in a test case. For whatever reason you want to run only some of them.

For example: when developing and you find a failing test and when investigation you want to avoid the noise what other test runs are generating (e.g. logging output).

Simple, built in solution is to @Ignore all other but the relevant test case

  public void test1(){...  }
  public void test2(){...  }
  public void test3(){...  }

Of course it is extremely uncomfortable to do especially when having sever dozens of test methods.

A few days ago I have run into a special annotation called @IgnoreRest in Spock . It simply takes the marked test and executes only that one. All other is ignored.

Of course there is no similar in “standard” JUnit .

How it should look like (identical to the previous sample):

  public void test1(){...  }
  public void test2(){...  }
  public void test3(){...  }

Without implementation I had to develop myself. There were many options to implement:

There is one single issue which makes this implementation incomplete: ignored test are not marked as ignored.

At the moment in JUnit version 4.11 there is not way to use RunNotifier (that is the way IDEA is able to display ignored test properly). At the moment the official answer is to use Assume. Once an assume exception is raised JUnit is ignoring the result but not calling RunNotifier as in case of @Ignore. So even if the solution is working properly IDEs are not displaying it properly so it is much difficult to notice if you forget to clean up @IgnoreRest.

NB: All source is available on Github in package eu.qualityontime.test

A specific test case

  public IgnoreRestRule rule = new IgnoreRestRule();

  public void test1() throws Exception {

  public void test2() throws Exception {

  public void test3() throws Exception {

  public void test4() throws Exception {

The marker IgnoreRest

  @Target({ ElementType.METHOD })
  public @interface IgnoreRest {}


  import java.lang.reflect.Method;
  import org.junit.Assume;
  import org.junit.rules.TestWatcher;
  import org.junit.runner.Description;
  import org.junit.runners.model.Statement;

  public class IgnoreRestRule extends TestWatcher {

    public Statement apply(Statement base, Description description) {
      if (isIgnorable(description)) {
        return new Statement() {
          public void evaluate() throws Throwable {
            Assume.assumeFalse("IgnoreRest", true);
      return super.apply(base, description);

    private boolean isIgnorable(Description description) {
      return hasIgnoreRestAnnotation(description) && null == description.getAnnotation(IgnoreRest.class);

    private boolean hasIgnoreRestAnnotation(Description description) {
      Class<?> c = description.getTestClass();
      for (Method m : c.getDeclaredMethods()) {
        if (null != m.getAnnotation(IgnoreRest.class)) {
          return true;
      return false;

Jul 03, 2014

Measure it

We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense — Sir Hermann Bondi

Jun 30, 2014