Articles and sources to pick from

Lean scotland videos
https://vimeo.com/leanagilescotland/videos/page:1/sort:dat/

Sandro mancuso blog
http://codurance.com/blog/

Jabe Bloom - Decisions and Futures: On Designing Boundaries, Systems, and Distributed Cognition 

I have already watched this video. Its a bit phylosophical, but the guy has a phd in design and it can be quite interesting, maybe follow a bit more of his work.

Recommended chat from Dan north

https://vimeo.com/36579366
Bret Victor shows how to get instantaneous feedback. Very cool!

Scotland videos conference
https://vimeo.com/52085327

Back to the builder

Still fighting with the building. I've read another article where highlights having immutable objects and having objects in full state (rather that half populated) as arguments to use this pattern.

But one interesting thing in this article are links to eclipse plugins to generate the builder code.

http://jlordiales.me/2012/12/13/the-builder-pattern-in-practice/

scotland videos conferences

https://vimeo.com/52085327

Tell dont wait to be asked

Today I have a conversation with one of my collegues, we discuss about the interface between two systems: java and ciboodle.

In the this case the direction is JAVA verso ciboodle, but I can see two approaches:
We could see ciboodle as a listener of java, so the method exposes will be "onJavaAction" (onATRFailure), and them implement whatever is relevant to ciboodle
The other will be having ciboodle to expose a "createCase" service.

Notice that the method name its very important here because it drives the approach versus a listener or in the second case versus a service method.

So lets have a look at the arguments behind each solution. In the first case, the implementation seems more flexible. The method  will not have to change if ciboodle needs to do an extra step like creating another task. ciboodle get the information from the JAVA notification and he can do whatever is required.

For the second case the argument is that exposing a web service should be expose in terms of the system, and therefore it will not make sense to expose a method in system as listener of other system. One of the things that doesn't seem to fit is when JAVA communicates the type of ATR that it was processing. It uses an enum. Defining a web  service interface that uses an enum of another system it seems weir. In the best scenario you can imported to your system, other ways you have to duplicate. But even if it make sense to import it doesn't seem right to use these concepts as API of call center system.

The argument is between call the method: createWorkItem(priority, target,...)
or onFailedATRRecover(failedATR)
in the second scenario failedATR, contains a type which a distinction java does to implement their logic.

It reminded me of this video from Kevin Rutherford

Kevin, uses a listener approach. Where the system notifies to a bus the event that has ocurred, "FailedATR".  The event at this point is the message that systems are using to communicate and both system should know about it (how to create, how to parse it).

Where these events belong to? Java project? Ciboodle project? Or a whole new project that I am missing?

Kana enterprise open points

Desktop framework
Use of tabs
Used of relevant items: which cases are displayed when a customer is selected(entitled cases, associated cases, subcases)

Build processes
Why java build takes 10minutes ours takes 1h.
Exporting zip?
Implementing code quality check's

Testing ui ciboodle

Create tool which allows to set componentes state. This allows to either check the state of the components in a TDD classic style test or to check the behaviour by testing that the tool was called with the right parameters.

Premisas ciboodle dev

Logic place within a  form process cant be reused. Not good to put logic in a place that you can't reuse it.
You test mainly logic.
when you test the through the ui you are testing the most end to end test, the most black possible black box.. However you'll need to stub or mock some object in order to get the behaviour you want. Which means not testing directly the object that implements it youll have to configure quite a lot in your test, which at this point you don't have a black box test anymore because you are configuring the inside of the ui. Although you could use factories to encapsulate that knowledge
Form  processes can be tested as any other object. However if make sense
--> which means we test them as a black box, without looking at who he delegates to.
Testing at the form process level is more end to end test. It covers more code

London School Vs Classical TDD

This is still a question for me. I have recently read again Martins Fowler article "Mocks aren't stubs" and then read Emily baches articles "tell dont ask".

One of things Emily mentions which I have experimented is the fact of not writen gold-plating code. It happens recently while developing the comparator. I have started developing the core classs "Comparator". I had to constantly remember myself that this class will not be called in certain way  because the button in the UI will be disabled if, for example, both policies are not entered. 
So I definetely see an advantage of working outside in from the requirements and write  just the code that does the job.

Action entitlement manager

In a call center application one of the key/core aspects is the user entitlements which determine given a user what can and cannot this user do.
Another reason for an action to be available can depend on the entity which that action belongs to. For example you might not to edit a policy if the policy is already closed.
So that's two different reasons to determine if action is available: the entitlement and the action entity or context in which the action is carried over. Its quite possible that these reason are handled in different ways. Entitlement failure, can be handled simply by hiding the functionality. While context failure can be handled with an informative error message.
Again is important to determine same simple error code object which allow to handle the failure in different ways.
Again this can fit within the generic validator, handler approach. Where a composed validator can be created, and them invoked by passing the handler which can be  composed one too;one generic handler which handles the failure hiding a parametrized form component. And one popup error message handler  which displays the failure message for the context failure.

Registering listeners into services

I have just finished what it could be one of my last developments in my current client, the false new business comparator. One screen which based on a renewal proposal and fnb proposal compares them and return a lost of the fields which are different. The design is an FnbComparator class which acts as the core  of this screen. This class has a fnbcomparator service which does job of getting the info from the db an compare it returning a list of differences.  The fnbComparator has a Compariaosn translator which transforms the service reaponses into calls to a listener, which is implementes by the displayer. The main class remains like this:
Displayer = new FnbComparatorDisplayer()

New FnbComparator(displayer,new FnbComparatorService(), new FnbComparatorTranslator(displayer)
Displayer and comparator have each other references to allow call backs.

Responsibilities remain like this:
FnbComparator displayer: allows the user to enter info and it triggers the behavior on the comparator main class.
FnbComparator: its the class which supports the screen behavior. Expose methods accordingly to the fields shown in the displayer. It does the validation and send messages back to a listener (the displayer in this case) with whether or not that operation succeed. 
There might be another way to look at his responsibilities; This class expose and interface which allows to set the correct information to compare two prp, and them expose the method compare. Each of this methods produces output messages to a class listener.  However notice how the interface its dictated by the neccesity of the screen:
Setfnb(fnb fnb)
Setrenewal(renewal renewal)
Setfnbbyprposalno(string prpno)
Compare()
Notice those methods support the selection of a renewal, selection of a fnb and the manual entering of the fnb number from the ui. So he is really acting as screen listener.
Comparator service
  In order to provide the screen support, the FnbComparator needs something that does the comparison, is clear this responsibility.
Notice an interesting thing this service returns a response to itscaller (FnbComparator) who is in charge of handling the response. He does it by using a response translator which allows yo hide the internals from the respond and it sends accordingly output messages (compared, unknownerror, different vehicles...) That means the respond error code system can change and we only have to change this class. It exchanges the error codes for output messages. That job is done  in the book 'growing objects orientated systems" by registering the translator within the chat (my comparator service).  This allows the FnbComparator remain ignorant from the fact that he needs a "servicerespondtranslator" combined with the service. Its not obvious that you need this translator to do that. It would be if the service ask for it.
This design of registering listeners seems emerging when we do outside in development. If youll start thinking from the inside out...
It seems useful when calling a service which can have multiple outputs. This way you can have one class which manages this outputs and converts them into messages creating a nice interface.
Other approach will the caller getting the response. This might bbe more the casa when the call returns more of a concrete answer, like a calculation, which then its used by the caller to calculate something else that you can assert on the final calculation.
However im this scenario the next step will be to enable or disable the buttons.  Which is not the responsabilty of the caller. So you'll have to create too many classes for this test.
One approach will be pass the displayer as a listener and asserts that the displayer calls some util action. Class. With an interface very specific like 'disable button compare'.  In this case given a service call you could test almost till the last step of the ui logic. As much fine grained are method in the ui as more logic you can test leaving only without testing the line of code which sets CSS class or calls the disabled. Method on the button
Bottom line is that testing state in ui is difficult and that's why we look for this mesage approach.

TDD - motivations

Ive been watching a few videos on this topic by Robert c Martin. His three laws are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

He mentions the following "minor" reasons:
 - Halve your debugging time
 - Serve as documentation
 - Improve you designs
 - Its fun


Halve your Debugging time
 
Following the three rules you'll never be more than a minute away from knowing that  you code works. You can easily undo the last line you when something doesn't work

Serve As Documentation
Third party come with a pdf guide. What is the part that we really look at? The sample codes. Unit test are simple to understand, they show every possible way to invoke an API, and they are executable, so they are always in sync, they are the perfect documentation!!

Improve your design
Writting test after your works it's quite hard because the code is not testable, its too coupling to something, and its hard to break that coupling.
Following the laws you can't write production code that is hard to test, because you wrote the test first. "Your code is testable or decouple, simply by writing the test first you end up you wind up your production code in ways that you never thought before. You end up with a better design".

Its fun
Becuase the test fail and  you want to make it pass. You get to write a test and make it pass, write another test and make it pass...


Main reason
Bad code,
why do you write it? we have to go fast.

Why don't you clean it? How many times you look at a code and think I need to clean it, next thought is I don't want to break it?

You are scared from breaking it. If you break you own it. So you don't touch it. So system continues to get worse and worse, slowing you down, slowing your team down till eventually the project gets through away and fresh new project starts.

How do we get reed of that fear?
Imagine we have a button, and when you push it within a few seconds a green light will tell you everything works.

"If you have the button, you'll not be afraid of touch, if you touch it will get clean, if it gets clean the team will go faster and thats why we do it."

How is stupid is to be scared from the code write, how bad is to not make a change that improve you code,  how unprofesional?

The only way is to have a suite of test that you can trust. You can trust your unit test if test everything.

Code coverage tool?
The goal is a 100%. You can't reach it but we try to get as close as possible.







 

Practical object oriented -Sandi metz

I've finished today the book. Just to write a list of the top things within the book:
Asking for what instead of telling how
Seeking context independence
She uses the example of mechanics and Trip. Where a trip is prepare if its bikes are prepare. There are two knowledge levels here. One is  how to prepare a bike (pump the tires, check chain...). The other is how to prepare a trip. Which is by preparing each of his bikes. Both responsibilities correspond to the Mechanic. In order todo that a mechanic knows that a trip has bikes. But we could abstract this concept into a preparable , where something can be preparable is it has bikes. This avoids the preparing knowledge from leaking into the trip class.
Notice that in order to achieve this we have to different kinds of interfaces. On one side we have a mechanic (preparator), exposes command methods, which allow to tell the what not the how. But on the other we have something preparable, which responds to query methods.
I though that this kind of query concept was wrong, and was looking always for the command like concept.  However it does make sense in situation like this where preparing is domain heavy concept which needs to be extracted from bike AMD put into a service. Then the dilemma is whether trip passes bikes and makes the service more context independent (he doesn't works with something that has  bikes, he works with bikes directly). In this case the trip knows that are his bikes the thing that need Ti be prepare.
The other. Trip seems that. Still know that the bikes. Are prepare since  still needs to respond tio bikes as a preparable.
But un tje example mechanic ask for the bikes,vehicles and something else from the trip so it totally make sense to pass the wrapping object trip.

Remove argument order dependency with a has table

Inheritance
Decoupling subclasses using hook messages (post_initialise)
It removes. The super from subclasses and therefore the knowledge within the subclass of the superclass

Query versus command important for testing

Test Equality

Entities can not be compared as value objects
IEqualityComparer use it to compare entities in tests:

Helper method that sets a value and return the entity itself with the same values. It helps to create expectations when only one property changes

Resemblance
Create subclass which implements equals

Likeness
 

TDD a practical book: communication from View layer to Logical Layer

Just getting to the end of this book, I wanted to write about the interfaces which defined the communication between the view and the logical object, specially the information that the view passes to the logical layer and whether we should use finer interfaces with individual getters for each field (used by David in his book), to a coarse interface with one getter returning a data structure.

 Passing Simple fields accross
By simple fields, I mean fields that do not need validation,  an string, an integer an enumeration are considered a simple fields. However a decimal is not, since and decimal is built from a string but it needs validation to be built.

This approach has the advantage of leaving the view completely ignorant from any sort of logic. The logical object asks for each single simple fields to the view and them he builds an object or an entity, e.g. a movie, while he carries out the validation.

In this case the View is acting as both, a service (Movie displayer) and a view Model (the Movie). Mixing these two responsabilities can be a problem when we has multiple views of a movie. As well it can obscure the test verification phases, where seeing the the view as a service can make hard to implement the equality.

Passing a view Model (Interface segregation)
In this case the View acts as a display service (Movie displayer) of a View Model (the movie). Even thought the concrete view class can still acts as both we could separate the movie into its own interface.

In this case,  we can end up with a Movie view Model, and Movie logical object, very similar between them, but the first being a data structure while the second is an object with behaviour.  For example in the case of the movieView, the ratings, are a vector, while in the movie are an array. Another example will be an amount field, while in the view will be an string the object would have it as a decimal so easily implement operations on it.

This allows to narrow the movie view, in pretty much two methods: "displayMovie" and "getMovie", passing an Movie view Model, which can easily implement equality to help in test verification.

If the view model is shared by different view this approach make sense. The downside is that increments complexity by segregating a new interface which will have to be converted from and to the object.

Passing the object

Having the editor talking to the view using the objects can reduce complexity by using one only object (Movie).
The issue here, it is easy that logic leaks into the view, since building the logical object can easily require validation.


Conclusion


I believe the key here is avoid having logic within the view, specially validation.
Fields entered in the view will have to be validated before they form
The key here is when do we do the data validation captured on the view.
The other key will be how fine/coarse grain we will like our view interface.
The third one will be avoid complexity when not needed.

At the moment I would avoid the "Passing the object"  approach which is likely to break the first key.  I would start with "Passing simple Fields",  and I would refactor if needed into "Passing a view Model".

Approach to TDD: London School Vs Classical TDD

One of the articles that most has struck me is one from Martin Fowler, Mocks aren't stubs. He explains  the two main different approaches to TDD; classicist and mockist.


One of the main points for me is that using Mocks seems sometimes to be testing implementation details rather than the return result is correct. However using mock allows us to avoid testing the same thing in multiple tests and I find myself writing similar tests for different classes, it feels like I am duplicating code and it just feels wrong.

An example of this can be a converter of composite structure. Imagine we have a Room which is divided in sections which are divided in rows. So to convert a Room to some string format we could have a "RoomToStringConverter" object, which uses a "SectionConverter" which at the same time has a "RowConverter" object.

I would like to test each converter independently and I want to set up what is relevant for each test, without setting up the full data structure.
This means testing  a  "RoomConverter", would test that the "SectionConverter" is called once per each section. And the result will be the appended result of all this calls. This test should be them implemented using mocks, where an expected number of calls with results are set up.


Testing the "SectionConverter" would be similar to the "RoomConverter". This allows to write my test in the form of:
"Giving that rowConverter returns X and Y, converting a Section would be the result of X + Y".  

In the case of classic testing (no mocks) one test would be created per each class. In this example we would have three tests: "testRowConverter", "testSectionConverter", "testRoomConverter". All of them are testing the row conversion. And if the test "testRowConverter" fails the other too will fail as well. This is not necessarily bad since it could be seen as giving us more information. What I don't really like the set up method of a room, which needs to set up a list of sections and then a list of rows for each section, and it feels to be setting too much data for one unit test.

Both[David Astels 2003] and [Lasse Koskela 2007] use a classicist approach. David uses it all through his practical example, instead Lasse uses it at least to explain the first few chapters which make sense since they are introductions to TDD. But I am not sure how he progressed since I am still at the beginning of his book.


On the other side I understand that using mocks relates the test a bit more to the implementation details. In the previous example a possible change on the implementation  could be to do all conversion within the "RoomConverter" class. This would break the tests even if the result would be same. It won't occur with a classicist approach.

GOOS (2009) by Steve Freeman and Nat Price, use a mockist approach. In the page 135, they refactor the "AuctionMessageTranslator" class. They create a class called "AuctionEvent", where they move the parsing message responsibility.
However they don't test this class because they argue that the class its protected by unit tests.
Lasse,  in his "Template engine" example explained through chapter 2 and 3, creates first the unit test for the most outer class "Template":

• test one variable
• test multiple variables
• unknown variables are ignored
• test missing value raises an exception
• variables get processed just once

But them he creates new tests when moving parsing functionality out of this class to the "TemplateParse".  The test for this class are:

• empty template renders as empty String
• template with only plain text returns a list with an element containing the plain text
• parsing multiple variables return a list of parsed variables
• parsing template into segment objects

The class  TestPlainTextSegment

• plain text evaluate as it is

And the class TestVariableSegment:

• variable evaluates to its value
• missing variable raises an exception

Creating these tests allows him to progress in smaller steps. We can see that the  scenario "test missing value raises an exception", is tested in both test classes, "TestTemplate" (p.70) and "TestVariableSegment"(p.97).
If a new feature arises now like "evaluating a variable with "*2" on the name will return its value concatenated twice". At this point we need to create a test within TestVariableSegment:
variable with name containing "*2"  evaluate to its value concatenated twice

Then should we create another test within Template test class to verify this behaviour. I would say no, we shouldn't. The template class it should test the variable evaluation with the same detail as the TestVariableSegment.  That's one positive thing of having those micro tests in place, that allow us to test the class directly without testing through its parents.

It'd be interesting to do a kata one with classicist approach and one with mockist approach and see the test that we end up with and how we get there.
 
Conclusion

There is no one way approach. Using mocks allows you to test each class isolated from the others, but the test is more linked to the implementation details. Therefore in an scenario where setting up the feature is complex  using mocks could help a lot. However in an scenario where the test can be written without too much complexity it can be worth to test without mocks asserting on the final result.

On the other side having, finer grainer tests help us to progress in smaller steps, but they can get in the way if we are trying to refactor a class, because each class component is tested.

Creational Design Patterns

Why Design Patterns?
There are several reasons why is interesting to learn about Design patterns:


It gives us vocabulary that we can use to talk about design. For example: "I am thinking about using an strategy for this scenario".

It is important to understand when each pattern could be used.


Creational Patterns

Robert Martin talks in his book about how each application should have a part where the objects are created and link together, and then they are passed to the application which exercises them to fulfill the requirements through the object interfaces. In this way we could change the application behaviour by changing the object building process, and returning different object which respect the same interfaces.

So it is important to be able to identify where objects are created and how we can plugged in the new objects which will change the functionality. 


Rather than spread the word "new" all around our code, we should be locating the object creation under a well set of defined classes which responsibility is building the net of objects that the application will use.



Abstract Factory
It make sense when we need to create a well defined number of objects, and all of them can be defined within an abstract interface..
Classic example is UI application, where a widget factory is used to create all the different types of widgets for an application. This allows to change the look of application by defining a new set of widgets and then creating them with a factory which will passed to the application.


Builder
Builder defines an algorithm for the process of building a final product, separating the algorithm from the how the product is created and represented. It allows to reuse the algorithm and to create different products by implementing the algorithm steps.
One the main advantages is that allows to hide the internal representation of the product being build.

RTF converter
The builder acts as listener of the director, who carries an operation and it calls method on the builder, where the implementation varies. Builder objects is called multiple times and we can finally call a method on it to retrieve the wished information. The director is the part that can be reused.
To enhance this view of the pattern we could rename the methods  "convertChar", "convertFont", "convertParragraph" to "onCharRead", "onFontConvert", "onParragraphConvert". Those method would be implemented by the builder.


Maze Builder
The maze builder encapsulates how mazes are created, without exposing the internal structure the maze.  We could subclass the Maze builder to create different type of Mazes.
Director
Create an additional driver list

Based on [GOF], there isn't much benefit in wrapping the products under a common abstract concept. The builder client configures the director with a builder, therefore he should expect the relative product. This is not the scope of this pattern. It is more focus in capturing the knowledge on which operations need to be implemented for creating a certain type of object.
In the example of the RTF document reader, a builder can be passed in, so everything about the reader can be reused.

Builder is related to template method in that the template method defines the skeleton for the algorithm, which is what the builder does. So we could say the builder  does.

The main difference between a builder and an abstract factory is that the builder define steps on the building process while the abstract factory defines an interface to create a family of products, and all the products can be wrapped under an abstract interface.

In DDD mentions that factories, which are used by erepositories to make agreggates, used frequently builder objects to build aggregates which are then passed to the repositories to retrieve.

Builder is a more finer grain version than factory Method. Factory method return the product directly while in the builder identifies a common pattern (template method) on the creation of the product.