Technology Executive & Entrepreneur

Hello, In the previous article, we explored the theory of the builder pattern. Let’s see a more concrete example : Let’s assuming that we are building a Role Playing Game core model. Here are the basic rules: A player can be a Hero : a Warrior, a Wizard, or a Thief (we keep it simple) Every Hero has 4 main characteristics: Health, Strength, Spirit, and Speed, that are counted in points. Heroes have a Level, and starting characteristics are based on this level (Health starts at Level * 10, Strength and Spirit start at Level * 5, and Speed starts at Level * 3) Warrior has a (+2 Strength, -2 Spirit) Modificator, Wizard has (+2 Spirit, -2 Strength) Modificator Player can improve 2 Characteristics of 1 points each or 1 characteristic of 2 points, in order to cutomize his Hero. A naive implementation of the Hero class would be : ...

Hello, In this article, I’d like to present you the Builder pattern and how I use it in my C# code. The Builder Pattern is a Creational design pattern, like the Factory Method Pattern I already covered un this previous article. Its main focus is to provide a light DSL to build objects by settings startup properties, by seperating the process of constructing an object from the object itself. Basically, the idea is to create a class with mutable fields, that will be initialized with dedicated methods, and a final method that create the object itself from thoses values. Here is an abstract example : ...

Hello, I’d like to introduce you Canopy, a Selenium overlay written in F#. It brings you the concision and the clarity of F# to your selenium tests. First of all, we have to create a new F# console application, then we install canopy in our project: As you can see, the canopy nuget will bring back the selenium ecosystem. Lets create our first test. It will check that a search of “canopy F#” in google will feature the official Canopy website as the first result. Here is the little bootstrapping needed by Canopy : ...

In this article, I’ll demonstrate how to buid a simple and maintainable process manager for Node.js, leveraging its Event Loop. The main idea is have a core processor that will be able to run a serie of tasks, in a synchronous way. As you may know, Javascript is by essence an asynchronous language. Let take simple example : As the execution flow is asynchroneous, the result variable will not be valued before the crawling method ends, and the usage of the variable will occurs before its valuation The standard solution in javascript to handle this issue is to use a callback method : Callbacks are really handy, but what happen if if I have a process with several tasks in it? Yes, we just felt into the Callback Hell! The main issue with the nested callback is that your code has a lack of readability and flexibility. It’s quite difficult to understand what the code is meant to do. And if you have to modify the process, you’ll have to rethink the whole process. ...

Dead factory - Alexander Kaiser - This file is licensed under the Creative Commons Attribution 2.0 Generic license. The Factory Method pattern is, in my opinion, one of the most useful creational design patterns. It allows us to delegate the creation of an object to a dedicated class, and thus encapsulate all the logic of this creation that is often not directly related to the responsibility of the class. 1) Simple example : Given the following code : {{< gist oinant 4ca495386bec0fa96f22 >}} The first class is an actual business object : It’s built from some properties, has some business logic. Its single responsibility is to perform business logic. It shouldn’t embed any infrastructural concern ( like database connection for example) The second class is the factory itself, that handle the full creation process of our BusinessObject. Its responsibility includes to fetch data from a repository, and to call the business class constructor. The third class is a simple runner, that instanciate the factory, get the business object from it, and perform what the program is meant to do. Thanks to the Factory Method Pattern, the Runner is not polluted with any construction logic, everything is delegated to the factory object. 2) Increase the system testability: Obviously, by splitting the responsibilities of your code into different modules, you are, de facto, improving the testablity of your program. But in some cases, you can use the factory method pattern as a way to use a TestDouble where your usual mocking techniques cannot apply. For example, when your code is consuming an external object, and that object has no interface, like this NetworkMessage. {{< gist oinant f16849566b18a85dfef9 >}} As you can see, the main class relies on DateTime.Now, that make the code relying on it quite complicated to test. Here is our own NetworkClient, without factory for the NetworkMessage : {{< gist oinant 59148627589e87777614 >}} Here, in order to be able to test every execution path of our client, we have to know precisely how the external library behaves internally, and even use some Microsoft.Fakes to create shims of System.DateTime. That’s a lot of test code that is not really relevant, because it’s out of our scope. Futhermore, we just want to control the NetworkMessage output in order to ensure that our network client behaves correctly. To achieve this, we can add a factory to our client : {{< gist oinant f6c49cf22182f062b198 >}} And testing becomes really easy, by implementing another factory, that creates an object which inherits from our external object : {{< gist oinant 1a8426c1e1647efe7616 >}} In this article, we saw that the Factory Method pattern helps us respecting the SOLID’s Single Responsibility Principle, and can help us with external/legacy code integration, by providing us a way to enhance testability. Note : all the code of this article is accessible on this github repository

Thanks to my first post, i had the chance to have very interesting chat with some cowokers. One of the main concern was the mandatory apsect of the estimates in specific situations, mostly in order to arbitrate between two projects. First of all, let me clarify my thoughts about estimates. In order to provide reliable estimate, the following criteria have to be gathered : Team should know itself perfectly, knowing precisely what are the strenghts and weakness of each member. Team’s codebase should be either blank or without defects product should entierely identified and specified, and the Product Owner, as the domain experts, 100% sure of what the final product should be. I’ll post more on this later, but in my opinion, thoses conditions are at best anti-agile and at worst impossible to get. ...

This is a daily struggle of the developper nowadays : to give accurate estimates of the work we are doing, or we’ll have to do. When was the last time you succeeded to give an actually accurate estimate? You know, the one that perfectly fits the amount of work to do, in the exact time frame, with a clear vision of what you were meant to do? It’s been a while, isn’t it? ...