Blockchain explained by simple Java code

April 11, 2018 by Hien Nguyen·Comments Off

Following my problem with KFC system, let’s see another real world problem: The food shop chain with a central hotline/database couldn’t work sometimes because of single point that needs to be always up. If the order database could be distributed, the high availability of the system could be increase. It’s when blockchain shows its value by all distributed shops store the copy of single order database.

Blockchain is combination of block and chain. Block is unique and stores the data/information, chain stores a sequence of blocks that each block points to the previous one.

This article describes the simple blockchain that’s used to store the orders of all food shops in the system.

Let’s start with Block with a simple version of Order.

public class Block {
    public String hash;
    public String previousHash;
    public Order order;
    public long timeStamp;
    
    public Block(Order order, String previousHash) {
        this.order = order;
        this.previousHash = previousHash;
        this.timeStamp = new Date().getTime();
        
        this.hash = Generator.generateHash(
                this.previousHash 
                + this.timeStamp 
                + this.order.toString());
    }
    
    public static Block getGenesisBlock() {
        Order order = new Order("Its me", "Nothing", 0);
        Block block = new Block(order, "");
        block.timeStamp = 0;
        block.hash = Generator.generateHash(
                block.previousHash 
                + block.timeStamp 
                + block.order.toString());
        return block;
    }
}

public class Block {

public String hash;

public String previousHash;

public Order order;

public long timeStamp;

public Block(Order order, String previousHash) {

this.order = order;

this.previousHash = previousHash;

this.timeStamp = new Date().getTime();

this.hash = Generator.generateHash(

this.previousHash

+ this.timeStamp

+ this.order.toString());

}

public static Block getGenesisBlock() {

Order order = new Order("Its me", "Nothing", 0);

Block block = new Block(order, "");

block.timeStamp = 0;

block.hash = Generator.generateHash(

block.previousHash

+ block.timeStamp

+ block.order.toString());

return block;

}

One Block has the unique ID, called hash, with time the block is generated, called timeStamp, and hash of the previous block, called previousHash. Block has order that store the food order data.

The first block that doesn’t have previous one, called genesis block, should be hard-coded.

A BlockChain has a list of block with some add-in methods like validateBlock() or validate() the block chain.

public class BlockChain implements Cloneable {
    private final ArrayList<Block> chain;
    
    public BlockChain() {
        this.chain = new ArrayList<>();
        this.chain.add(Block.getGenesisBlock());
    }
    
    public ArrayList<Block> getBlocks() {
        return (ArrayList<Block>) chain.clone();
    }
    
    public long size() {
        return chain.size();
    }
    
    public void add(Block block) {
        if (validateBlock(chain.get(chain.size() - 1), block)) {
            chain.add(block);
        } else {
            throw new IllegalArgumentException("Invalid block");
        }
    }
    
    public String getLastHash() {
        return this.chain.get(this.chain.size() - 1).hash;
    }
        
    public boolean validateBlock(Block previousBlock, Block block) {
        return block.previousHash.equals(previousBlock.hash);
    }
    
    public boolean validate() {        
        ArrayList<Block> subChain = (ArrayList<Block>) chain.subList(1, chain.size() - 1);
        Block previousBlock = chain.get(0);

        for (Block currentBlock : subChain) {
            if (!validateBlock(previousBlock, currentBlock)) {
                return false;
            }
            previousBlock = currentBlock;
        }
        
        return true;
    }
    
    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

public class BlockChain implements Cloneable {

private final ArrayList<Block> chain;

public BlockChain() {

this.chain = new ArrayList<>();

this.chain.add(Block.getGenesisBlock());

}

public ArrayList<Block> getBlocks() {

return (ArrayList<Block>) chain.clone();

}

public long size() {

return chain.size();

}

public void add(Block block) {

if (validateBlock(chain.get(chain.size() - 1), block)) {

chain.add(block);

} else {

throw new IllegalArgumentException("Invalid block");

}

public String getLastHash() {

return this.chain.get(this.chain.size() - 1).hash;

}

public boolean validateBlock(Block previousBlock, Block block) {

return block.previousHash.equals(previousBlock.hash);

}

public boolean validate() {

ArrayList<Block> subChain = (ArrayList<Block>) chain.subList(1, chain.size() - 1);

Block previousBlock = chain.get(0);

for (Block currentBlock : subChain) {

if (!validateBlock(previousBlock, currentBlock)) {

return false;

}

previousBlock = currentBlock;

}

return true;

}

@Override

public Object clone() throws CloneNotSupportedException {

return super.clone();

}

The reason of class BlockChain implementing interface Cloneable should be describe later.

Now each food shop, called Node, has a single blockchain. To make sure all nodes store the same blockchain, we must firstly make sure all nodes can ‘known’ others. Following:

If the node is started without connectedNode, it’s the first node
If the node is started with connectedNode, it asks the connectedNode for the list of nodes in the network, calling to getNodes(). Then the node tells those existing nodes that it wants to connect to the network, calling to registerToNetwork()

public class Node {
    public String address;
    
    protected BlockChain blockChain;
    private ArrayList<Node> nodes;
    
    public Node(String address, Node connectedNode) {
        this.address = address;
        blockChain = new BlockChain();
        
        if (connectedNode != null) {
            registerToNetwork(connectedNode);
            try {
                getBlockChain(connectedNode);
            } catch (CloneNotSupportedException ex) {
                Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);
            }
        } else {
            nodes = new ArrayList<>();
        }
    }
    
    public void add(Block block) {
        try {
            this.blockChain.add(block);
        } catch (IllegalArgumentException e) {
            if (this.nodes.size() > 0) {
                try {
                    getBlockChain(this.nodes.get(0));
                } catch (CloneNotSupportedException ex) {
                    Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);
                }
            }
        }
    }
    
    public void mine(Block block) {
        this.blockChain.add(block);
        this.nodes.forEach((node) -> {
            node.add(block);
        });
    }
    
    private void registerToNetwork(Node connectedNode) {
        this.nodes = connectedNode.getNodes();
            this.nodes.add(connectedNode);
            this.nodes.forEach((node) -> {
                node.register(this);
            });
    }
    
    private void getBlockChain(Node connectedNode) throws CloneNotSupportedException {
        this.blockChain = (BlockChain) connectedNode.blockChain.clone();
    }
    
    public ArrayList<Node> getNodes() {
        return (ArrayList<Node>) this.nodes.clone();
    }
    
    public void register(Node node) {
        this.nodes.add(node);
    }
}

public class Node {

public String address;

protected BlockChain blockChain;

private ArrayList<Node> nodes;

public Node(String address, Node connectedNode) {

this.address = address;

blockChain = new BlockChain();

if (connectedNode != null) {

registerToNetwork(connectedNode);

try {

getBlockChain(connectedNode);

} catch (CloneNotSupportedException ex) {

Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);

}

} else {

nodes = new ArrayList<>();

}

public void add(Block block) {

try {

this.blockChain.add(block);

} catch (IllegalArgumentException e) {

if (this.nodes.size() > 0) {

try {

getBlockChain(this.nodes.get(0));

} catch (CloneNotSupportedException ex) {

Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);

}

public void mine(Block block) {

this.blockChain.add(block);

this.nodes.forEach((node) -> {

node.add(block);

});

}

private void registerToNetwork(Node connectedNode) {

this.nodes = connectedNode.getNodes();

this.nodes.add(connectedNode);

this.nodes.forEach((node) -> {

node.register(this);

});

}

private void getBlockChain(Node connectedNode) throws CloneNotSupportedException {

this.blockChain = (BlockChain) connectedNode.blockChain.clone();

}

public ArrayList<Node> getNodes() {

return (ArrayList<Node>) this.nodes.clone();

}

public void register(Node node) {

this.nodes.add(node);

}

To make sure blockchain consistent, when a node mine a block, it needs to notify to all nodes in the network, method mine(). In this problem, it means a food shop creates order for a customer.

It is. A blockchain is ready. Class Store and FoodBlockChainTest is for testing: it creates 3 stores (kfc, burger, pho) and registers them to the network, each store simulates creating the orders and add to blockchain. You should see the result in your console. This example is just simulated by distributing the system in threads, that’s why I used Cloneable to get it looked like ‘distributed’ without references. In the real blockchain, methods like getNodes(), getBlockChain(), register()… should be called by REST or RPC.. and each node has it owned isolated data. But networking isn’t our focus here, you can easily write some extra code.

public class Store extends Node implements Runnable {
    
    public Store(String address, Node connectedNode) {
        super(address, connectedNode);
    }
    
    public void testOrders() throws InterruptedException {
        String[] customerName = {"Messi", "Ronaldo", "Pogba"};
        String[] orderDetails = {"KFC", "Burger", "Wine" };
        Random random = new Random();
        
        for (int i = 0; i < 3; i++) {
            Block block = new Block(
                    new Order(customerName[random.nextInt(3)], orderDetails[random.nextInt(3)], random.nextInt(50)),
                    this.blockChain.getLastHash()
            );
            try {
                this.mine(block);
                System.out.println(String.format("%s mined: %s", address, block.hash));
            } catch (IllegalArgumentException ex) {
                System.out.println(String.format("%s mined invalid block: %s", address, block.hash));
            }
            Thread.sleep(random.nextInt(3) * 1000 + 100);
        }
    }
    
    public void printBlockChain() {
        System.out.println("------ Block chain of [" + address + "] ------");
        
        this.blockChain.getBlocks().forEach(block -> {
            System.out.println(block.hash);
        });
        
        System.out.println("------ END ------");
    }

    @Override
    public void run() {
        try {
            testOrders();
        } catch (InterruptedException ex) {
            Logger.getLogger(Store.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

public class Store extends Node implements Runnable {

public Store(String address, Node connectedNode) {

super(address, connectedNode);

}

public void testOrders() throws InterruptedException {

String[] customerName = {"Messi", "Ronaldo", "Pogba"};

String[] orderDetails = {"KFC", "Burger", "Wine" };

Random random = new Random();

for (int i = 0; i < 3; i++) {

Block block = new Block(

new Order(customerName[random.nextInt(3)], orderDetails[random.nextInt(3)], random.nextInt(50)),

this.blockChain.getLastHash()

);

try {

this.mine(block);

System.out.println(String.format("%s mined: %s", address, block.hash));

} catch (IllegalArgumentException ex) {

System.out.println(String.format("%s mined invalid block: %s", address, block.hash));

}

Thread.sleep(random.nextInt(3) * 1000 + 100);

}

public void printBlockChain() {

System.out.println("------ Block chain of [" + address + "] ------");

this.blockChain.getBlocks().forEach(block -> {

System.out.println(block.hash);

});

System.out.println("------ END ------");

}

@Override

public void run() {

try {

testOrders();

} catch (InterruptedException ex) {

Logger.getLogger(Store.class.getName()).log(Level.SEVERE, null, ex);

}

public class FoodBlockChainTest {
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Store kfc = new Store("KFC Vietnam", null);
        Store burger = new Store("Burger King", kfc);
        Store pho = new Store("Pho", kfc);
        
        Store[] stores = {kfc, burger, pho};
        
        for (Store store : stores) {
            Thread thread = new Thread(store);
            thread.start();
        }
        
        try {
            Thread.sleep(10000);
        } catch (InterruptedException ex) {
            Logger.getLogger(FoodBlockChainTest.class.getName()).log(Level.SEVERE, null, ex);
        }
        
        for (Store store : stores) {
            System.out.println("");
            store.printBlockChain();
        }
    }
}

public class FoodBlockChainTest {

/**

* @param args the command line arguments

public static void main(String[] args) {

Store kfc = new Store("KFC Vietnam", null);

Store burger = new Store("Burger King", kfc);

Store pho = new Store("Pho", kfc);

Store[] stores = {kfc, burger, pho};

for (Store store : stores) {

Thread thread = new Thread(store);

thread.start();

}

try {

Thread.sleep(10000);

} catch (InterruptedException ex) {

Logger.getLogger(FoodBlockChainTest.class.getName()).log(Level.SEVERE, null, ex);

}

for (Store store : stores) {

System.out.println("");

store.printBlockChain();

}

It’s of course not a real blockchain that you can use now. There are many things that this article didn’t mention: chain conflict, Proof of Work, sub chain, confirmation… But I hope you can get the idea of blockchain and its value through a simple code. It just a start, I will get back with another topic later.

Full code should be found here: https://github.com/hiennvn/simple-blockchain-java

222 total views, 4 views today

What team needs in its stages

March 20, 2018 by Hien Nguyen·Comments Off

There are some researches about team stages, the famous ones are Tuckman’s model and ShuHaRi. To be honest, both Tuckman’s and ShuHaRi models are generic and support for group development instead of cross-functional and self-organized team in Agile. But both of them are very well known and well explained to be borrowed to Agile. I usually use those models in common Agile article/training/coaching, and in this post as well.Tuckman defined team stages with Forming, Storming, Norming and Performing in his first publish. It’s a sequence, meaning each stage has it own obstacle that needs to be overcome for moving team to next stage (see Agile Y, chpt. 6).

While Tuckman is team model of performance, ShuHaRi is not. ShuHaRi is team model of learning and practicing Agile with Shu, Ha and Ri (following, branching, owning). But Agile is iterative and empirical approach for building team and process, learning and practicing seem to be ‘everything’ that directly affect to team performance.

Working in Agile team as an Agile coach, I like the idea of combining Tuckman and ShuHaRi model: bringing the team through Tuckman’s model stages by supporting them to overcome their obstacles following ShuHaRi. That bases on understanding team’s stage and its needs in each stage as ShuHaRi.

Stage 1: The child (Forming, Storming) & Shu: Need a ‘manager’

Team should be in the chaotic stage, a group of people with an initial agreement (on vision, working method…) but lot of disagreement (on process). What team needs is the very clear direction, and who team needs is a leader with strong management skill to quickly bring team out of chaotic state. Like a child, team doesn’t need to understand why red light is for stop, just stop. Command and control is acceptable here by well explained reasons and high level of ‘command’: following code review, applying TDD…

Many people believe that Agile team shouldn’t have a leader – that I cannot agree. Any team has a leader itself in may way, with or without title or responsibilities in the job description. In Scrum, ScrumMaster is a leader of process. My experience, there are 2 reasons for Agile team never steps out of those stages: team has a manager who lacks of leadership spirit, and team has a leader who lacks of management skills. Team needs both, a ‘leader’ to set the direction, and a ‘manager’ who make sure team is doing right (Shu) on the way. If these are in one person (TeamLead or ScrumMaster…), team should expect the clear communication that they are SHUring, be patient to Ha and Ri in the next steps.

Stage 2: The teenager (Norming) & Ha: Need a ‘leader’

Team should be in organized stage, a half-team with their agreements that were built up from their experiences. What team needs is the clear objectives and a methodologies to reflect their learning. Like a teenager, team understands why red light is for stop, green to go and sometimes try the new things with yellow ones. Team needs a ‘leader’ who supports their decisions to try various things in their own way, thing by thing and step by step. Team has few knowledge and skills of managing, then still needs but weak ‘manager’ could be good here. Together, managing skills can be built up by leadership spirit.

Stage 3: The mature (Performing) & Ri: Need a ‘coach’

Team should be in out standing stage, a true team with self-organized and enough of skillset to perform well. What team needs is a methodology for keeping the continuous improvement, and who team needs is a coach. Like a mature, team understands why lights exist in places, when it should be red, when it should be green. The method and coach should be for both: team and team member. How team works well together is still an important knowledge and skills to be built up but team shouldn’t expect the big step as child and teenager stages. Keeping or stepping out of this stage needs team deep understanding about the methodology behind rather than just practices. Team and each member needs a coach who tell them the missing knowledge and skills, manage the improvement process and give feedbacks.

FSNP-SHR

You could see it as the model or pattern to be applied in team. But the hard and trick part is the leader/manager needs to recognize the correct stage of the team to shift his role or responsibilities in the right time. The metrics are useful out there.

164 total views, 1 views today

Very first introduction to DevOps

February 27, 2018 by Hien Nguyen·Comments Off

Here is my talk in Hanoi University of Science and Technology. The students came from many majors with different backgrounds challenged me, required another approach. Good-enough with less effort is the best way today. My thanks are sent to the authors of 2 slides below, the great ideas and contents helped me save times.

https://www.slideshare.net/hawkmanacademy/introduction-to-devops-69870752

https://www.slideshare.net/sgganesh/devops-a-gentle-introduction

144 total views, no views today

How a team setup a software project

February 17, 2018 by Hien Nguyen·Comments Off

How could we have the high performance team for a software development project at getting started? It may take long time to get a team having the same mindset and working together with high performance but with the good setup at the beginning, time would be shorter. Five things below, in my opinion, are simple but very important that every software development team should do.

0. Working method

Very important. Remember that in the first step, we don’t have a team that targets the same goal, we have a group of people that works in the same project even though in a sustainable organization where the working method or process is defined. So what we need to form a team?

Mission & vision: No one works without the vision and objective. A group needs it at least to become a team. It’s a direction for team and also a glue to get people worked together.

Working agreement: What team commit to do? I try my best to complete the day job or I just want to work at most 6 hours daily no matter the result is? It must be agreed in team.

Write down mission & vision and working agreement in a eye-catching place to remind everyone in team. Before all, let’s discussed and agreed in team, and get everyone signed off.

Choose a working method: Everyone in team has to understand how they work together. It’s good to pick a “standard” method or framework to start with such as Scrum, Kanban… in order to help people more easily to understand and follow. In case of people don’t understand it right, make sure they get trained to reach the level of start.

Working method (or process) must be visualized

1. Team collaboration tools

When working method is set, team needs a tool for collaboration. If team chooses Scrum or Kanban, team board is more than important. It can be the physical board or online board such as Jira, Trello, Pivotal Tracker…

Choose a single official toolset. A lot of good communication tools today makes team difficult to decide. Slack or Skype? Google Docs or Zoho?… Then team never feels happy enough with one tool, Slack is good but Skype has better video call quality. Choose both? No. Let choose a single official tool where every main information, decision, solution… are placed there. Extra discussion can be worked over others that the contributors feel comfortable with. It helps people simply find the decision.

Choose a single official tool where every main information, decision, solution… are placed there

2. Source code version control

I don’t need to explain more about the needs of source code version control. Choose one that all team members are familiar with, otherwise it will become the headache by overhead. Git is the best one today. But Git is so uncomfortable without diff tools. Meld, Kdiff3, WinMerge… are the good tools that work for most of Git clients.

Choose which?

3. IDE & team environment settings

IDE / text editor is a sword to kill dragons. Find the best one. It’s so easy to have an agreement in team if the project is working on .NET, iOS… with the vendor tool. There’s a bit harder with the language or technology that can be done by many choices. TextMate or Atom, Sublime or InteliJ for PHP? Which is the best for Android, Eclipse or Android Studio?

Once team chooses a single IDE, set the team environment settings and make sure to manage it in the right place, good one usually is source code repository. Keeping team environment settings reduce the conflict issues that usually be the overhead. It also helps for continuous integration and continuous delivery.

Environment shouldn’t be a place for personal creativity at beginning. Do it later.

4. Continuous delivery pipeline

Agile is becoming standard working method today, then continuous delivery and continuous deployment is crucial. The age of continuous integration was passed by, team needs more powerful toolset that’s near production or staging. That’s why DevOps is becoming important in developing software service.

That’s a pattern for setting up a software project that should be longer than 2 months within more-than-3-persons team. It’s very important with the initial setup with a specific method or toolset the team uses – it becomes material for improvement after each iteration. Lacking of agreement on a single method or toolset get the road harder to success.

457 total views, no views today

“Tinh thần MVP” là gì vậy trời?

December 8, 2017 by Hien Nguyen·Comments Off

Sau giai đoạn nhà nhà nói về “tinh thần Agile” như một thuật ngữ cửa miệng, giờ người ta bắt đầu nói về “tinh thần MVP”.

Nhưng giống như bao nhiêu thứ “tinh thần” khác được hô hào, cổ vũ mà thiếu nền tảng và thực hành rõ ràng – rất nguy hiểm. Chạy theo “tinh thần Agile” mà thiếu thực hành tạo ra một nhóm hỗn độn. Chạy theo “tinh thần MVP” mà thiếu thực hành tạo ra một sản phẩm tạp nham.

Tôi bắt đầu gặp nhiều nhóm làm sản phẩm với một công cụ MVP duy nhất là “tinh thần”:

MVP không đồng nghĩa với kém chất lượng. “Có bug chút cũng được, chắc gì đã có ai dùng”. Nếu bạn đã không tin sẽ có người dùng (chức năng đó), tại sao lại làm? Rồi bạn sẽ biết người dùng không sử dụng do chức năng đó thực sự không nằm trong nhu cầu của họ hay nó tệ đến mức không thể sử dụng? Chúng ta có thể đặt nhỏ scope nhưng không được thoả hiệp với chất lượng.
MVP không đồng nghĩa với “cứ làm đi”. MVP phải dựa trên giả định, phải tìm kiếm, nghiên cứu trước để củng cố phần nào cho giả định… MVP là công cụ để kiểm chứng lại giả định trong thực tế. MVP không phải là cứ có ý tưởng là lao vào làm, rồi để thực tế trả lời mà không định nghĩa rõ những giả định nào cần kiểm chứng.
MVP rồi cũng phải dừng hoặc đi tiếp. Cần phân biệt rõ ràng, test là test. Khi đã đủ dữ liệu để kiểm chứng giả định, học từ đó và quyết định: đi tiếp hay dừng lại. Đã quyết định dừng lại thì phải thẳng tay loại bỏ chức năng không hữu ích. Đừng biến sản phẩm thành bãi rác.

Một sản phẩm làm sao phát triển bền vững nếu nó cứ loanh quanh trong việc “test” để tìm ra phần hồn của mình? “Tinh thần MVP” không có thực hành sẽ tạo ra một mớ hổ lốn không còn đúng với nguyên lý 80/20 mà chính MVP theo đuổi nữa.

284 total views, no views today

Anti-IF pattern

November 15, 2017 by Hien Nguyen·Comments Off

Lập trình không dùng if-else, có được không?

If-else thật xấu xí

Đối diện với một bài toán, lập trình viên (LTV) thường phải trả lời câu hỏi: Đây là bài toán đặc thù hay phổ quát? Bài toán “số ít” hay “số nhiều”? Và thông thường, câu trả lời sẽ quyết định thành quả tiếp theo. Ví dụ, con chó kêu gâu gâu?” là bài toán số ít. Ta có thể viết thế này:

if (dog.startTalking())
    return "gâu gâu";

1 2	if (dog.startTalking()) return "gâu gâu";

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG)
        return "gâu gâu";
    else
        return "meo meo"; 
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else

return "meo meo";

}

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo, con vịt kêu quạc quạc” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG) 
        return "gâu gâu"; 
    else if (animal == CAT)
        return "meo meo"; 
    else if (animal == DUCK) 
        return "quạc quạc";  
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else if (animal == CAT)

return "meo meo";

else if (animal == DUCK)

return "quạc quạc";

}

Thật đơn giản. À từ từ, chuyển sang switch cho đẹp mắt.

switch (animal) {
    case DOG:
        return "gâu gâu";
    case CAT:
        return "meo meo"; 
    case DUCK: 
        return"quạc quạc";
}

switch (animal) {

case DOG:

return "gâu gâu";

case CAT:

return "meo meo";

case DUCK:

return"quạc quạc";

}

Đẹp đẽ quá rồi. Tuyệt vời.

Bạn có thấy câu chuyện trên quen thuộc trong cuộc sống hàng ngày của LTV? Khi if-else bắt đầu phát huy sức mạnh, làm ơn đừng chuyển sang switch – chẳng hay ho gì đâu. Khi if-else bắt đầu phát huy sức mạnh, chính là khi nó bắt đầu trở nên xấu xí, chính là khi chúng ta cần phải xem lại cách đánh giá bài toán của mình. Đây không phải là bài toán số ít ngay từ đoạn code #2. Các LTV cần hiểu đúng đắn rằng đây là bài toán số nhiều ngay từ khi nó có dấu hiệu là bài toán số nhiều, thay vì cứ else-if và hy vọng giữ nó là bài toán số ít.

LTV có thể sống mà không cần if-else?

Có, dùng switch thôi. Không không, tiêu đề trên để cho vui thôi. Câu hỏi thực sự là “chúng ta có thể lập trình mà không sử dụng câu lệnh rẽ nhánh (conditional statement)?”. Vâng, không dùng if-else, switch,…?

Từ thưở đầu học lập trình, ai trong chúng ta cũng biết những thứ căn bản nhất của một ngôn ngữ lập trình (NNLT): variable, array, conditional, loop statement. Lâu dần chúng ta coi đó là điều nghiễm nhiên của một NNLT. Nhưng bạn cần biết rằng, âu lệnh if-else còn nhiều điểm xấu xí khác, từ logic cho tới runtime speed, memory… nên một số NNLT hoàn toàn không có if-else.

Vậy thì sống làm sao? Làm sao để giải bài toán trên mà không dùng if-else? OOP – polymorphism là một giải pháp. Thử xem:

class Animal { 
    talk(); 
} 

class Dog : Animal { 
    talk() {
        return "gâu gâu"; 
    } 
} 

class Cat : Animal { 
    talk() {
        return "meo meo"; 
    } 
} 

class Duck : Animal { 
    talk() {
        return "quạc quạc"; 
    } 
} 

// something here
animal.talk();

class Animal {

talk();

}

class Dog : Animal {

talk() {

return "gâu gâu";

}

class Cat : Animal {

talk() {

return "meo meo";

}

class Duck : Animal {

talk() {

return "quạc quạc";

}

// something here

animal.talk();

Không có gì huyền bí cả, bạn có thể tham khảo tại blog của Martin Fowler về pattern này.

Nếu bạn muốn thực hành nhiều hơn, có thể tìm đến Anti-IF pattern tại đây.

No if-else

Về lý thuyết, chúng ta hoàn toàn có thể lập trình mà không sử dụng if-else. Tại các buổi Code Retreat thường có 1 session mà LTV nhất định không sử dụng if-else khi lập trình ngay cả khi NNLT đó hỗ trợ. Mục tiêu là luyện tập khả năng ít phụ thuộc vào conditional statement để hình thành tư duy abstract. Như ví dụ trên, câu lệnh if-else thực sự quá mạnh mẽ, đến nỗi các LTV không thể tránh được cám dỗ, giải bài toán theo “số ít” và tạo ra những thiết kế sai lầm, vi phạm nguyên tắc open-closed cơ bản.

Nếu bạn chưa biết thực hành thế nào, hãy tới một buổi Code Retreat cho biết.

589 total views, 1 views today

Hội chứng nghiện thảo luận

August 2, 2017 by Hien Nguyen·Comments Off

Trong quá trình đào tạo, tư vấn về Agile, tôi nhận được nhiều câu hỏi về “nhóm không chủ động đưa ra suy nghĩ, ý tưởng, thảo luận”, đây là vấn đề lo ngại rất cơ bản. Nhưng rất ít người nhận ra một vấn đề trái ngược hoàn toàn – nhóm có quá nhiều ý tưởng và thảo luận – điều mà tôi thấy xuất hiện nhiều hơn trong thực tế, ở một số nơi tôi huấn luyện.

Khi triển khai Agile, tư tưởng đề cao nhóm (phát triển) được cổ vũ, nhóm hiểu rằng mình là nòng cốt, trung tâm, quyết định thành bại của việc phát triển (được ScrumMaster và Product Owner hỗ trợ hết mức trong Scrum). Những thành viên trong nhóm (phát triển) yêu cầu thảo luận và tham gia thảo luận vào mọi vấn đề, và dường như không có một điểm dừng cụ thể. Tôi gọi đó là hội chứng nghiện thảo luận. Bài viết đề cập tới hội chứng này trong nhóm phát triển Agile/Scrum.

Dấu hiệu

Hội chứng nghiện thảo luận có thể được nhận biết qua những dấu hiệu:

Quá nhiều ý tưởng không được quản lý. Các thành viên nảy ra ý tưởng và thảo luận mọi lúc mọi nơi: trong các cuộc họp, trong ngày làm việc… , được đưa ra song không được ghi chép, lưu trữ lại.

Liên tục thảo luận không theo kế hoạch. Mỗi khi một ý tưởng được đưa ra là bắt đầu ngay một cuộc thảo luận không có dự định trước. Hai thành viên thảo luận bên ly cafe. Nhóm thảo luận trong buổi họp hàng ngày…

Liên tục đặt câu hỏi hoặc thảo luận trên những miền kiến thức khác với chủ đích không rõ ràng. Khi công việc đã được gán cho một thành viên cụ thể, các thành viên khác vẫn luôn mốn thảo luận thêm về cách làm. Lập trình viên quan tâm quá mức tới từng bước nhân viên marketing giới thiệu về sản phẩm và đóng góp ý kiến.

Liên tục mở rộng ý tưởng. Khi một ý tưởng được đưa ra, cuộc thảo luận bắt đầu, ý tưởng khác lại phát sinh, lại tiếp tục thảo luận không có hồi kết.

Tất cả chỉ là ý tưởng, không có nhiều hành động cụ thể. Hiệu suất sản sinh ý tưởng của nhóm vượt xa hiệu suất thực thi, nhóm dành 1/2 thời gian để sinh ra 8 ý tưởng khác nhau mỗi tuần và dành 1/2 thời gian còn lại để thực hiện 1 ý tưởng không rõ ràng.

Thực thi trên những thứ không rõ ràng. Khi thực thi một ý tưởng, những yêu cầu dừng ở mức chung chung, không rõ ràng, khiến việc thảo luận tiếp tục không dừng.

Hệ quả

Tốn thời gian. Tốn tiền.

Nguyên nhân

Hội chứng nghiện thảo luận tới từ việc thiếu cách làm việc khoa học, trong khi nhóm được cổ vũ quá mức. Sức mạnh của nhóm là không thể nghi ngờ, trí tuệ đám đông thì tốt. Nhưng khi tổ chức cổ vũ nhóm thì cũng cần song song với đó trang bị cho nhóm cách làm việc khoa học, nhận biết những vấn đề nào nhóm cần thảo luận và vấn đề nào thì không. Những thành viên trong nhóm phát triển có tần suất ra ý tưởng nhiều hơn cả Product Owner (nhóm Scrum) thường là không tốt.

Loại bỏ

Đừng nhầm lẫn giữa loại bỏ hội chứng nghiện thảo luận và loại bỏ thảo luận, giữa loại bỏ hội chứng nghiện ý tưởng và ý tưởng. Ý tưởng và thảo luận luôn luôn là điều tuyệt vời, song nhóm cần thực hiện khoa học hơn

Hãy đảm bảo có các buổi họp / workshop để brain storming. Hãy tạo không gian để những ý tưởng được “xả” ra, tập trung và đều đặn.

Hãy đảm bảo mọi sự kiện kết thúc trong khung thời gian cho phép. Buổi họp hàng ngày cần kết thúc đúng trong 15 phút, không nêu ý tưởng và thảo luận vượt quá thời gian.

Hãy đảm bảo mọi cuộc họp đều đi đúng mục tiêu ban đầu. Các buổi họp Planning là để lập kế hoạch, buổi họp Retrospective là để đánh giá lại quy trình… không thảo luận những ý tưởng bất chợt, không liên quan.

Hãy đảm bảo mọi thảo luận đều phải có kết luận cụ thể. Làm, không làm, để sau tính. Không kết thúc cuộc thảo luận, họp mà không có kết luận cụ thể. Không chuyển sang thảo luận trên chủ đề khác khi chủ đề trước đó bị bỏ lửng.

Hãy luôn nhớ tới Product Backlog. Bất cứ khi nào thành viên có ý tưởng, viết ra, đặt vào một nơi tập trung, Ideas Bag, Brown Bag… PO sẽ cùng nhóm xem xét để đưa vào Product Backlog và làm rõ sau.

Hãy thực thi. Thảo luận không có giá trị cho tới khi việc thực thi mang lại kết quả. Hãy đảm bảo những thảo luận phải được chuyển hoá thành hành động với sản phẩm cụ thể.

Cụ thể hoá và đo lường. Nhóm phải cụ thể hoá ý tưởng trước khi thực thi. Và hãy nhớ đo lường. Nếu không, ý tưởng nào cũng tốt hoặc tệ như nhau.

Kết

Trong đào tạo Agile/Scrum, những trainer luôn đề cao vai trò của nhóm, cho rằng tri thức của nhóm là tốt – điều này không sai. Song nếu nhóm không tỉnh táo nhận biết những gì nên thảo luận trong toàn nhóm, những gì nên giải quyết bởi cá nhân, việc hình thành tri thức nhóm sẽ dẫn đến chi phí khủng khiếp. Những thành viên với kỹ năng chính là testing tham gia thảo luận về kiến trúc với lý do “đóng góp một góc nhìn khác”, nhóm phát triển tham gia bàn quá sâu về kế hoạch marketing sản phẩm (không liên quan tới công nghệ)… không hề hợp lý. “Góc nhìn khác” đôi khi mang lại giá trị, song hãy nhớ, “đôi khi” – đánh đổi quá nhiều công sức chỉ để chờ đợi một “đôi khi” là lãng phí.

697 total views, 1 views today

Choose a baseline for Story Point

July 16, 2017 by Hien Nguyen·Comments Off

Estimating by Story Point (SP) is important for a project that is following Scrum. It helps Product Owner (PO) and Development Team (DT) quickly imagine the workload of the upcoming Sprints and vision the release roadmap. Good estimation helps so much; the better accuracy is, the better Sprint goes. Then choosing the “unit” User Story (US) or the baseline of SP is important step.

Some of the Scrum guideline chose the baseline of SP by following:

Choose the “smallest” US and set it is 1 SP, call it a baseline.
Estimate other USs by comparing them with the baseline.

But this method isn’t good enough by 2 reasons at least:

What does it come between 1 or 2 if DT think a US is larger than 1 but less than 2 SP? We don’t have 1 and 1/2 in single card.
How does DT maintain the consistent compare of each US estimation? How they can make sure all 5-SP US are the same?

As my observer, following guideline above leads the new DT to less accurate estimation. One signal of not-good estimation is that SPs are distributed around a number like 1, 2, 1, 2, 1, 1… as it shows that the DT doesn’t know how to compare the difference between USs so that they choose the same number just because of the feeling.

Another way to choose the baseline is:

Choose the “smallest” US and set it 2 SP.
Find a US that is good to set 5 SP.
Call 2 and 5 baseline, estimate others.

The idea of the above method is:

DT can reserve 1 SP for the future US that maybe less than today smallest – 2.
DT understand how to compare US because they did it when finding 5-SP US.
When estimating a US, DT can choose to compare it with 2 or 5 instead of single unit for better accuracy.

The idea of choosing 2 SP as baseline is getting DT understood about US comparison and setup more anchor for the next estimation. Then choosing 2 & 5, 3 & 8, 1 & 2… doesn’t matter but my recommend is 2 & 5 because they are small enough in both absolute value and their difference.

343 total views, no views today

GURUnH

Guru's notes

Blockchain explained by simple Java code

What team needs in its stages

Stage 1: The child (Forming, Storming) & Shu: Need a ‘manager’

Stage 2: The teenager (Norming) & Ha: Need a ‘leader’

Stage 3: The mature (Performing) & Ri: Need a ‘coach’

FSNP-SHR

Very first introduction to DevOps

How a team setup a software project

0. Working method

1. Team collaboration tools

2. Source code version control

3. IDE & team environment settings

4. Continuous delivery pipeline

“Tinh thần MVP” là gì vậy trời?

Anti-IF pattern

If-else thật xấu xí

LTV có thể sống mà không cần if-else?

No if-else

Hội chứng nghiện thảo luận

Dấu hiệu

Hệ quả

Nguyên nhân

Loại bỏ

Kết

Choose a baseline for Story Point

Stage 1: The child (Forming, Storming) & Shu: Need a ‘manager’

Stage 2: The teenager (Norming) & Ha: Need a ‘leader’

Stage 3: The mature (Performing) & Ri: Need a ‘coach’

FSNP-SHR

0. Working method

1. Team collaboration tools

2. Source code version control

3. IDE & team environment settings

4. Continuous delivery pipeline

If-else thật xấu xí

LTV có thể sống mà không cần if-else?

No if-else

Dấu hiệu

Hệ quả

Nguyên nhân

Loại bỏ

Kết

If-else thật xấu xí