Skip to main content

Posts

Showing posts from November, 2016

Review - The Object-Oriented Thought Process, by Matt Weisfeld

In this post, I would like to point out what I understood after closing my eyes and thinking about what  exactly I have learned from this book. That means the layout of content does not follow the book.
From Procedural to Object Oriented Once upon a time, there is an issue that it is very hard to test and debug in Procedural programming because the data is sometimes global and can be modified by multiple functions.

Object-Oriented (OO) programming addresses these problems by combining both data and functions into an object. That means only functions belong to the object can access its own data.

Let us check the below two different approaches for a case that we want to transfer information between clients and servers across a network.

-    Procedural programming: a client (browser) transfers a JSON data to a server which needs to know how to process with this data. In order words, a handshaking agreement must be defined for the client and server in order to work together.
-    OO prog…

Building a Wizard with Chain of Responsibility Pattern

What is the Idea? We want to create a page that there are some steps and each step has its own business. Users are able to click on a step and its status could be changed. Primefaces owns a component "Wizard" but it it quite hard for us in order to apply our very specific and complicated business domain logic on each step; even we cannot click on a step of this component.

We somehow are able to use the component "TabView" works with a strong back-end mechanism. A backend mechanism! what do I mean? Yes, we need it because we want to abstract the behaviors of each step otherwise we will get trouble with many events handling. Obviously, each step has some behaviors  such as "next", "back" and "switch' are the same and they are related to each other; but the business of these behaviors can be different totally. That is where the pattern "Chain of Responsibility" can be applied.
Step by Step Building It! In this simple project, I …

Avoiding Time-Wasting Pitfalls in Agile Estimation

If you do Scrum at work, you might be very familiar to the estimation in Planning 1. My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated.


I give you some advice from my experience:
Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement.

The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you don't ha…