DEV Community: Bukhori M. Aqid

Making any chrome os device your second screen

Bukhori M. Aqid — Sat, 06 Mar 2021 04:03:09 +0000

For a while now, I'm trying to make my Lenovo Duet as my portable second screen. I don't want to carry around monitors everywhere and my main devices for traveling are Macbook and Chromebook. That's why I thought it would be cool if I can use my Duet Chromebook as my second screen.

First, I tried several options:

Duet Display (https://www.duetdisplay.com/) - They have lots of good reviews but unfortunately the connection is not stable and I notice lots of lag. They have pretty good support though and I managed to get a refund. Thanks!
Synergy (https://github.com/symless/synergy-core) and Barrier (https://github.com/debauchee/barrier) also doesn't work. They crashed when I tried to move my mouse to the chromebook.

Finally I found Deskreen https://deskreen.com/

In order to use this app, I need to purchase some hardware (virtual plug) that enables me to extend the screen. However, the result is pretty satisfactory. The connection is stable and even though there are lags, it's still acceptable.

Cheers!

Migrating from JIRA to Redmine

Bukhori M. Aqid — Fri, 26 Jun 2020 17:09:53 +0000

both are great, really!

Since the very start, we loved to experiment with tools & new technologies for our project management. We’ve tried Asana, Trello, Basecamp, Smartsheet, Pivotal Tracker, JIRA Server, Jira Cloud and many other tools. Though we love all of them, we can only use them for short period of time before finding impediments or some features that we think we need but at the time non-existent in that particular platform.

Last year, we used JIRA for our project management platform. We loved it. JIRA has lots of good features that we want, and we need. Custom workflow, Sprint based planning, informative dashboard, Bitbucket integration and many more. Our only complaint is that it was quite hard to setup initially. Aside from that, we love the experience. But as our team grows, somehow we need to re-evaluate our usage on JIRA because of the cost vs benefit that it bring. This year, we grew from 15 to ~23 person team and forecasted to be around 30 at the end of the year. Taking a quick glance at JIRA pricing, we’re going to spend ~$1500 to~$3000 annually. Which is quite pricy for us. And so we began our search…

After several weeks of comparing JIRA with another tools, we find it hard to replace our daily use cases. But then I remembered Redmine, a project management tools that I’ve used before in college. The UI is really simple and honestly quite ugly back then, but I’m curious to give it a go since it’s an open source project that I hoped we can tinker with.

And turns out, we find it quite pleasurable to use because

There is an awesome theme : https://github.com/mrliptontea/PurpleMine2 that really boost the general look & feel ( though we can’t compare it with the final polished commercial product such as JIRA ). We did change the theme a little bit to suit our taste better.
A lot of plugins available ( free / commercial ). Those plugin options really helped us take what’s good from JIRA and incorporate them into our Redmine. Even though Redmine has a lot of useful features, but to increase our productivity we decided to install several plugins.

Some of the features that I personally found super useful :

The ability to right-click (multiple) task and display quick actions for those following task

The ability to create and categorize Roadmap. You can see spent time, overall progress and deadline for that specific Roadmap

Parent-Child project relationship. JIRA doesn’t have this and we have some difficulties managing our project relations. Redmine has this feature built in

Some important plugins that we use are :

https://bitbucket.org/tkusukawa/redmine_work_time We use this plugin to make worktime log and keeping track of your daily task easier. I personally loved this plugin and use it instead or the original redmine’s time logger.

https://github.com/JostBaron/redmine_workload We use this plugin to view resource workload estimation Installation notes : after installing, we found some styling conflict and we need to edit the plugins .rb files

http://www.redmine.org/plugins/custom-workflows This plugin is really powerful if you understand how to code ( using Ruby ). We used this plugin for task automaton such as automatic assignment, default task properties and other automaton task.

https://github.com/jgraichen/redmine_dashboard JIRA has a beautiful Kanban board and some of us really missed it because Redmine doesn’t provide this feature. We add this dashboard plugin to cater for those who prefers Kanban board style.

Other plugins that we use are :

https://github.com/akiko-pusu/redmine_issue_templates
https://github.com/a-ono/redmine_ckeditor
Installation notes : this plugin has conflict with redmine_mentions. if you enable it, mentions can’t be used on the same field.
https://github.com/a-ono/redmine_ckeditor/issues/113
https://github.com/a-ono/redmine_per_project_formatting
http://stgeneral.github.io/redmine-progressive-projects-list/
http://rmplus.pro/en/redmine/plugins/usability
Installation notes : never enable simplified view for participants — will result on 500 error! Also I think there are styling conflicts with PurpleTheme
https://github.com/arkhitech/redmine_mentions
https://www.redmine.org/plugins/redmine_editor_preview_tab
https://github.com/vichak/redmine-import-tasks
Installation notes : create your own public/uploads/exports plugin and make sure www-data has access to it. enable popup for auto download

Even with all of those plugins addition, Redmine still has a lot of things that we need to adjust. But for now, we’re quite satisfied with it.

Cheers

Extending Fabric 2 Test Network

Bukhori M. Aqid — Thu, 25 Jun 2020 19:55:22 +0000

What is Fabric 2
Hyperledger Fabric is a private blockchain platform that enables you to create permissioned blockchain network. The main elements in Hyperledger Fabric are:

Peer & Organization: Peer node hosts and execute ledger transactions and smart contracts. Peer belongs to Organization. Some peers can be endorsing peers.
Orderer: Orderer provides ordering service (packages transactions into blocks to be delivered to peers on a channel).
Channel: Channel are logical structure formed by collection of peers.
Chaincode / Smart Contract: Smart Contract is software that defines the business logic, contains assets and related transactions. Hyperledger Fabric smart contracts are called chaincode and may specify an endorsement policy which defines transaction validity.

The approach that is taken by Hyperledger Fabric (in my opinion) is beneficial for industrial use cases because it enables cooperation between organization (using channels) while to certain extent having a privacy inside the organization.

To explore the capabilities of Fabric, there are some examples provided that serves certain use cases. For a simple introduction, there are 2 examples that should be used: First Network and Test Network. Due to a major upgrade in Hyperledger Fabric, there are 2 major versions available 1.4.x and 2.x.x - First Network is suitable if you want to learn Fabric 1.4.x but Test Network would be preferable for Fabric 2.x.x. Also good to know that Test Network is a replacement for First Network so you should use that whenever possible.

The striking difference between First Network and Test Network is the number of nodes. First Networks comes with 2 peers for each organization, and 5 orderers while Test Network only comes with 1 peer per organization and 1 orderer. This might be limited for some scenario that you want to run. This article will help you extend the test network with some helpful bash scripts. The underlying assumption is that you already have a Test Network running with command ./network.sh up createChannel && ./network.sh deployCC

TL;DR

To extend Test Network, we need to extend fabric key with cryptogen, update system-channel definition, compose orderer nodes, compose peer nodes, join application channel and deploy the chaincode. For an easy setup, clone this repository and run ./extend-network.sh after setting up your local Test Network. Or to make things easier, just run ./setup-fabric-extended.sh that will setup local Test Network as well as extends it.

Extending Fabric Key
Before extending the network, we need to generate all the necessary key for each new orderer and peer that we want to create. The easiest way to do that is by using cryptogen command. cryptogen is an utility for generating Hyperledger Fabric key material. It is provided as a means of preconfiguring a network for testing purposes. It would normally not be used in the operation of a production network.

cryptogen extend --config=crypto-config.yaml --input="organizations"

The --config parameter should point to the new network configuration, not the existing test network configuration. In this case, we want a total of 3 orderers, with 3 peers for each organization.

OrdererOrgs:
- Name: Orderer
  Domain: example.com
  EnableNodeOUs: true

  Specs:
    - Hostname: orderer
    - Hostname: orderer1
    - Hostname: orderer2

PeerOrgs:
- Name: Org1
  Domain: org1.example.com
  EnableNodeOUs: true

  Template:
      Count: 3
      SANS:
        - localhost
  Users:
      Count: 1

- Name: Org2
  Domain: org2.example.com
  EnableNodeOUs: true

  Template:
      Count: 3
      SANS:
        - localhost
  Users:
      Count: 1

Extending Test Network Orderer
First, we need to update system-channel configuration so that we can run new orderer node. The steps needed to update system-channel are as follows:

Fetch (and decode) latest configuration
Add new orderer certificate generated by cryptogen to orderer consenters and modify the configuration
Apply the change to blockchain

To fetch and decode latest configuration, we need to execute:

peer channel fetch config ./out/config_block.pb -o $ORDERER_ADDRESS -c $2 --tls --cafile $TLS_ROOT_CA

configtxlator proto_decode --input ./out/config_block.pb --type common.Block --output ./out/config_block.json

jq .data.data[0].payload.data.config ./out/config_block.json > ./out/config.json

The commands above will get the latest config and store the result in out folder. The default orderer address is export ORDERER_ADDRESS=localhost:7050 and the TLS_ROOT_CAshould be test-network/organizations/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem

Next is adding new orderer certificate to the new configuration. We can achieve that by executing commands below:

# add new orderer certificate
echo "{\"client_tls_cert\":\"$(cat $ORDERER_TLS | base64 -w 0)\",\"host\":\"orderer$1.example.com\",\"port\":7$150,\"server_tls_cert\":\"$(cat $ORDERER_TLS | base64 -w 0)\"}" > $PWD/out/ord$1consenter.json

jq ".channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters += [$(cat ./out/ord$1consenter.json)]" ./out/config.json > ./out/modified_config.json

# calculate config differences
configtxlator proto_encode --input ./out/config.json --type common.Config --output ./out/config.pb

configtxlator proto_encode --input ./out/modified_config.json --type common.Config --output ./out/modified_config.pb

configtxlator compute_update --channel_id $2 --original ./out/config.pb --updated ./out/modified_config.pb --output ./out/config_update.pb

$1 refers to our orderer address, $2 refer to channel name (system-channel) and $ORDERER_TLS should refer to TLS certificate for the corresponding orderer.

The final step before starting the node is applying the changes via update transaction

# "applying changes"
configtxlator proto_decode --input ./out/config_update.pb --type common.ConfigUpdate --output ./out/config_update.json

echo '{"payload":{"header":{"channel_header":{"channel_id":"'$2'", "type":2}},"data":{"config_update":'$(cat ./out/config_update.json)'}}}' | jq . > ./out/config_update_in_envelope.json

configtxlator proto_encode --input ./out/config_update_in_envelope.json --type common.Envelope --output ./out/config_update_in_envelope.pb

# "submit update transaction"
peer channel update -f ./out/config_update_in_envelope.pb -c $2 -o $ORDERER_ADDRESS --tls --cafile $TLS_ROOT_CA

The final step is actually creating and running the orderer node. The easiest way is to use docker compose and add the service definition below

  orderer1.example.com:
    container_name: orderer1.example.com
    extends: 
      file: orderer-base.yaml
      service: orderer-base
    environment: 
      - ORDERER_GENERAL_LISTENPORT=7150
    volumes:
      - ${FABRIC_SAMPLES_DIR}/test-network/system-genesis-block/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
      - ${FABRIC_SAMPLES_DIR}/test-network/organizations/ordererOrganizations/example.com/orderers/orderer1.example.com/msp:/var/hyperledger/orderer/msp
      - ${FABRIC_SAMPLES_DIR}/test-network/organizations/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/:/var/hyperledger/orderer/tls
      - orderer1.example.com:/var/hyperledger/production/orderer
    ports:
      - 7150:7150

with orderer-base.yaml defined below

version: '2'

services:
  orderer-base:
      image: hyperledger/fabric-orderer:$IMAGE_TAG
      environment:
        - FABRIC_LOGGING_SPEC=INFO
        - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
        - ORDERER_GENERAL_GENESISMETHOD=file
        - ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
        - ORDERER_GENERAL_LOCALMSPID=OrdererMSP
        - ORDERER_GENERAL_LOCALMSPDIR=/var/hyperledger/orderer/msp
        # enabled TLS
        - ORDERER_GENERAL_TLS_ENABLED=true
        - ORDERER_GENERAL_TLS_PRIVATEKEY=/var/hyperledger/orderer/tls/server.key
        - ORDERER_GENERAL_TLS_CERTIFICATE=/var/hyperledger/orderer/tls/server.crt
        - ORDERER_GENERAL_TLS_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
        - ORDERER_KAFKA_TOPIC_REPLICATIONFACTOR=1
        - ORDERER_KAFKA_VERBOSE=true
        - ORDERER_GENERAL_CLUSTER_CLIENTCERTIFICATE=/var/hyperledger/orderer/tls/server.crt
        - ORDERER_GENERAL_CLUSTER_CLIENTPRIVATEKEY=/var/hyperledger/orderer/tls/server.key
        - ORDERER_GENERAL_CLUSTER_ROOTCAS=[/var/hyperledger/orderer/tls/ca.crt]
      working_dir: /opt/gopath/src/github.com/hyperledger/fabric
      command: orderer
      networks:
        - net_test # docker network for Test Network

Extending Test Network Peer
Extending peer node is easier. After you've generated all the required key, you can directly compose the node. One of the sample configuration for your node container is given below

  peer1.org1.example.com:
    container_name: peer1.org1.example.com
    extends:
      file: peer-base.yaml
      service: peer-base
    environment:
      # Peer specific variabes
      - CORE_PEER_ID=peer1.org1.example.com
      - CORE_PEER_ADDRESS=peer1.org1.example.com:7151
      - CORE_PEER_LISTENADDRESS=0.0.0.0:7151
      - CORE_PEER_CHAINCODEADDRESS=peer1.org1.example.com:7152
      - CORE_PEER_CHAINCODELISTENADDRESS=0.0.0.0:7152
      - CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.example.com:7151
      - CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer1.org1.example.com:7151
      - CORE_PEER_LOCALMSPID=Org1MSP
    volumes:
      - /var/run/:/host/var/run/
      - ${FABRIC_SAMPLES_DIR}/test-network/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp:/etc/hyperledger/fabric/msp
      - ${FABRIC_SAMPLES_DIR}/test-network/organizations/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls:/etc/hyperledger/fabric/tls
      - peer1.org1.example.com:/var/hyperledger/production
    ports:
      - 7151:7151

with peer-base.yaml defined below

version: '2'

services:
    peer-base:
        image: hyperledger/fabric-peer:$IMAGE_TAG
        environment:
            # Generic peer variables
            - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
            - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_test
            - FABRIC_LOGGING_SPEC=WARN:cauthdsl=info:policies=debug:msp=info
            - CORE_PEER_TLS_ENABLED=true
            - CORE_PEER_GOSSIP_USELEADERELECTION=true
            - CORE_PEER_GOSSIP_ORGLEADER=false
            - CORE_PEER_PROFILE_ENABLED=true
            - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
            - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
            - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
        working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
        command: peer node start
        networks:
            - net_test # docker network for Test Network

That's basically it. Make sure that all certificates and keys are pointing in the correct and existing folder and you're good to go.

Enjoy your new network!

Design Patterns in Healthcare domain

Bukhori M. Aqid — Sun, 07 Jun 2020 13:22:33 +0000

Same old design patterns, from healthcare use cases

For those of you who don’t know, design pattern is one of the fundamental concepts in software engineering that will help you manage pieces of your system by reducing complexity and isolating independent components so that frequent change can be performed smoothly.

A pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way, twice

— Christopher Alexander, A Pattern language

Design Patterns by GoF

One of the famous books regarding software design pattern is created by Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides).

A System of Patterns

There is also a good book by Gang of Five (5 completely different persons than Gang of Four) which gives a bigger scope perspective in software engineering patterns.

In this series of articles, I will try to dissect and discuss some of the patterns contained in those 2 books with sample cases/problems from the healthcare domain. I do realize that those books discussed more towards the context of Object-Oriented Principle and might not apply in some non Object-Oriented language. But the patterns alone are worth to discuss and might be beneficial in some general cases.

Before starting the pattern discussions, we have to know how to model real life concept/object type and phenomenon/object instance. We usually model those with UML (Unified Modelling Language) and that’s what we’ll use most of the time while discussing design patterns.

Since we’re going to work with lots of UML diagram in this article series, let’s recall some of the UML notation:

https://www.omg.org/spec/UML/2.5.1/PDF

There will be some UML doodle similar to the one above in this series so bear with my chicken scratch handwriting :)

Before crafting UML diagram, there are 4 important concepts that you need to remember for modeling:

Abstraction : Can the object instances be generalized into type or sub-type?
Inheritance : Which type is the ‘parent’ of the other type? (Car vs Sports Car)
Encapsulation : Which part of the data/behavior is exposed to the outer world?
Polymorphism

PSE 1920 TUM: Polymorphism hierarchy

Besides doing that, you also want to achieve low coupling and high cohesion. Having low coupling means that the dependencies between subsystems are low and high cohesion means that the dependencies among classes in one system are high. To achieve this property there are some things that you can do :

Principle of Least Knowledge/Law of Demeter The intuition for this is rather easy, if you call multiple objects e.g. objectA.getB.getC.doThings() then you might violate this principle.
Ask, don’t tell Instead of directly modifying object internals (tell), call a method/API that will modify such internal (ask).

In this article, I will take some of the patterns and try to give some context and examples related to healthcare domain.

I. Structural Patterns

This pattern group aims to reduce coupling between classes, enabling future extensions (by introducing abstract class) and encapsulate complex structures.

Delegation Pattern on Activity Delegation between Doctor and Nurses

In many states, physicians can delegate their activities to nurses, physician assistants or other medical professionals to deliver care more efficiently and effectively.

http://lawatlas.org/datasets/physician-scope-of-practice-1509022789

I can imagine that during the daily tasks of a doctor, there are some activities that can be delegated to another role that is better suited or even more skilled in that one specific action. That’s why sometimes you have doctor prescribe and/or apply the first medicine but then followed up by nurses.

We can model that kind of scenario using delegation pattern. Simply by having Doctor class to store reference to Nurse class and when needed, call the Nurse object for action delegation.

if (doctor.busy) nurse.apply()

Adapter Pattern on API Development in Legacy Hospital System

Consider this scenario:

A hospital has already been running for 100 years with stable in-place system.

You are a new and modern tech division in the hospital, wants to create mobile app, needing API that consumes the data from legacy system as well as collecting new data from other sources

some kind of UML Diagram

One way to connect those 2 systems is to create an adapter. In the UML diagram above, Legacy Adapter acts as a translator/connector between 2 systems. This can be done by implementing interfaces or extending parent class (and override some methods) from the new system and then make a delegation call (blue arrow) or calling the superclass method (inheritance green arrow) to get the value.

Please be aware that you might need to do some parsing/conversion process in the adapter to ensure that the request and response data is in a valid format.

Bridge Pattern on Medicine Procurement from Multiple Sources

Medicine procurement in hospital pharmacies of Nepal: A qualitative study based on the Basel Statements

It was found that the majority of hospital pharmacies in Nepal reported using an expensive direct-procurement model for purchasing medicines.

Since direct-procurement in Nepal is expensive, we want to provide cheaper option by having an auction based or competitive-procurement. But we don’t want to disrupt an already stable system. There is also a problem that some branches might already have their own customization. This calls for a Bridge Pattern.

In this scenario, our Bridge Pattern consists of

Application Domain: This is your hospital/hospital system
Solution Domain: This is where you get your medicines using some procurement model

Procurement can happen with direct or competitive procurement model, and in this case each hospital branch have the the liberty to choose any model they prefer.

By creating a bridge pattern between abstraction of hospital and procurement, we can strictly define each branch to have procurement model but since the subclass can override the superclass then each branch can choose their preferred model and new branch can also choose their preferred model. Changing model also easy, just add implementation of procurement and change branch that wants to use that new model.

But be careful with Degenerate Bridge : where the application or the solution domain doesn’t have a subclass/subtype (yet). This might increase complexity without any clear benefits.

In a sense, Adapter pattern might seem similar to Bridge pattern. But “Adapter makes things work after they’re designed; Bridge makes them work before they are. [GoF, p219]”

Proxy Pattern on Patient’s Guardian/Decision Proxy

Why all adults need a healthcare proxy

The article above argues that we should always have a healthcare proxy in for emergency cases. As a healthcare system developer, we want to cater to this scenario hence we’ll implement Proxy Pattern in our hospital system.

There are 3 types of Proxy Pattern:

Caching/Remote Proxy The proxy object is used for information caching (local representative for an object in a different location)
Substitute/Virtual Proxy This proxy is used for a stand-in object in case the real object takes quite a lot of time/memory to instantiate
Access Control/Protection Proxy This proxy provides access control to the real object

In this particular case, the guardian acts as access control proxy. If the real patient can actually do / willing to do said action that it will do it otherwise the proxy gets to decide.

scratch UML for proxy pattern

if (competent) inPatient.agreeToProcedure()

else patientP roxy.agreeToProcedure()

II. Behavioral Patterns

By applying patterns in this group you can answer “Who does what?” questions, e.g which algorithm is used for some problems, or which object instance to use. This will also simplify control flow and enable a better understanding of your program data flow.

Strategy Pattern on Patient-Centered Care approach

Eliciting patient treatment preferences: A strategy to integrate evidence-based and patient-centered care.

One of the strategy described in article above is to elicit patient preferences via written description. With some preferences given, there will be differences in patient care/treatment. During the hospital system development, this scenario can be handled by utilizing strategy pattern

The difference with Bridge Pattern is that if you use a bridge pattern, the patient (depending on the preference) will receive the type of treatment that he/she wants before system runtime while in strategy pattern, the treatment will be decided from patient preferences and can be changed at runtime if the preferences of the patient changed.

State Pattern on Medical State representation

Sometimes, hospital describe patient’s condition in a medical state jargon. Even though this is not commonly used clinical term, it will serve as a nice example for the needs of using State Pattern.

Medical state

State Pattern is used to help object control their behavior by changing its internal state.

Per Wikipedia’s description, there are several Medical States:

Undetermined

Patient awaiting physician and/or assessment.

Good

Vital signs are stable and within normal limits. Patient is conscious and comfortable. Indicators are excellent.

Fair

Vital signs are stable and within normal limits. Patient is conscious, but may be uncomfortable. Indicators are favorable.

Serious

Vital signs may be unstable and not within normal limits. Patient is seriously ill. Indicators are questionable.

Critical

Vital signs are unstable and not within normal limits. Patient may be unconscious. Indicators are unfavorable.

Dead

Vital signs have ceased. Patient has died.

scratch UML for Medical State

Every state can move to another state depending on the patient’s condition.

patientState.handle(…) can results in different actions depending on the current Medical State

There might be a question on where to handle state change, should it happen in the context class (TreatmentContext) or should it happen in concrete class (Medical States). I would say that this is up to personal preferences, but handling it in the concrete class will reduce the conditional block and making it simpler to add more state and/or see the limitation on each state.

Observer Pattern on Integrated Patient Information

Inadequate availability of patient information is a major cause for medical errors and aﬀects costs in healthcare. Traditional information integration in healthcare does not solve the problem.

An improvement for the information exchange is needed. The goal is to provide better information exchange between institutions (see Broker Pattern), or in smaller cases — between displays in a hospital counter. Let’s discuss the this smaller scope using observer pattern.

There are 2 key parts in observer pattern:

Observable object / Publisher
Observers / Subscribers

Imagine that in the same examination room, you have different screen / Graphical User Interface (GUI) used by the nurse to take your blood pressure, check for previous diseases, etc. There is also another GUI for the doctor to input more extensive treatment and diagnosis.

Wouldn’t it be nice if when the nurse enters your measured data, the GUI for the doctor is also updated? We can achieve this by applying an observer pattern with patient information as observable object

scratch UML for publish-subscribe scenario

Each GUI must have Observer implementation so that they can observe the patient information. And since they also modifying the Observable object, all changes will be observed and updated by other GUIs.

III. Creational Patterns

Sometimes to create something there are complex process involved and Creational Patterns are one collection of design pattern trying to improve the implementation of those complex processes. By applying patterns in this group you can create a simplified view to understand those processes in a glance. This will also make the creation process independent hence reducing dependency and coupling.

Abstract Factory Pattern on Doctor Skills Composition

Doctor can have multiple skill set. How do we properly model this scenario using Abstract Factory pattern?

Before starting with this pattern, we need to address the difference between Factory (Method) pattern vs Abstract Factory pattern.

Factory Method

As the name implies, Factory Method is a method / function that has an objective to instantiate one object.

Abstract Factory

Utilizing full class as Abstract Factory, we can create more complex object instantiation consisting of different classes composing that said object.

Now let’s consider the action of adding new doctor to the hospital. Every doctor has their degree and specialization and we might encounter one situation where we have a very competent doctor with multiple and maybe specialized skills. How can we create new doctor object with all the skills information and dependencies?

In this case, we can generalize few things, such as:

Hospital has doctors
Doctor has Degree(s)
Degree has a specific Degree Factory extending default (general physician) degree factory
Degree factory returns degree containing multiple skills given specific factory class
For a new degree, it’s as easy as add new degree factory with composeSkills() method containing all the required skills

scratch UML for Abstract Factory Pattern

IV. Architectural Patterns

An architectural pattern is a special set of pattern applied to software architecture problem within a given context. In this section we will discuss several samples of Architectural Pattern.

Blackboard System for Evidence-Based Diagnosis

Understanding evidence-based diagnosis : Diagnosis

“ How do we minimize the cognitive errors inherent to a task like diagnosis? The answer is even less clear, but computerized diagnostic support tools may have a role.”

One approach to model computerized diagnostic support is by using Blackboard (behavioral) pattern implemented in Blackboard system (architecture). Intuitively, you can imagine blackboard system as a room filled with experts discussing problems and putting solutions and opinions in the blackboard to achieve one final consensus/result.

In general, blackboard system consists of 3 big elements:

Blackboard is the repository of the problem, partial solutions and new information (hypotheses, etc)
Knowledge Source that reads anything placed in the blackboard (input) and place new information created by them on the blackboard.
Control that governs the flow of problem-solving activity in the system.

Also in order to create blackboard system, there are 6 steps that will be beneficial to follow:

Define the problem (and make sure there’s no algorithmic solution for it)
Define the solution space
Identify Knowledge Sources
Define the Blackboard
Define the Control
Implement Knowledge Sources

Let’s apply those 6 steps in our case

The problem : Evidence based diagnosis Domain: Healthcare Requirement: Given symptoms, patient health data & history, provide supporting diagnosis output Actors: Doctor, Patient, Nurses
Solution space : In the solution space, we need to identify the existence of top-level and intermediate solutions. A top level solution might indicate a flu diagnosis while intermediate solution might specify more details like possibility of dengue fever. For a complex diagnosis, partial solution might be needed as well. Such as giving cluster of diseases might occur given the observed symptoms and patient’s history.
Knowledge Sources: Different records of past diagnosis, organized (e.g. grouped by city) Inputs: Patient health data, Reported symptoms Outputs: Solution candidate as different diagnosis with confidence level
Defining Blackboard: We need to decide the data representation used in the blackboard, such as JSON with added metadata.
Defining Control: How are we going to process all the data provided from various Knowledge Sources? How and who are going to construct and verify the hypothesis? What constitutes an acceptable solution? In this stage, an expert help is necessary so collaboration is a must.
Knowledge Source implementation To implement Knowledge Sources, we need to define condition and action. We can utilize multiple arrays of techniques such as Bayes rules, classification algorithms, rule based system, or any of the computational intelligence methods.

scratch UML for Blackboard System

Client-Dispatcher-Server for System with High Availability

Once, I visited a clinic because I got a fever. Their system is under maintenance from 11:00–13:00 and I need to wait until it’s up before my medical data can be processed.

True story. And we can avoid that by implementing simple client-dispatcher-server

Healthcare is a critical field. A single mistake can cost human life. When I check myself in that said clinic during mid day, I observed that they have tablets and laptop but not using it. Curious, I asked: why do you have those devices but not using it? Surprisingly they said: Our system is usually under maintenance during this time so just to be safe we use paper and we will process the data later. Of course there might be multiple reasons why this happen but having only one server without backup might be the cause, so when there is a scheduled update then the client will be unable to connect to that server. We should provide several servers as backup so we can have zero down time deployment and update. But how are we going to manage those servers and the client connections?

Client-Dispatcher-Server architecture will help manage your system by introducing a dispatcher subsystem that manages connection between multiple clients and multiple servers so that updates can be done without making the server down.

To implement Client-Dispatcher-Server there are some steps that is useful to follow

Identify subsystem that act as clients, servers and dispatchers
Decide on the communication mechanism to be used for the protocols
Specify the protocols between components
Decide naming scheme for dispatcher
Implement the dispatcher
Implement client and server

Note: To be technically accurate, client-dispatcher-server architecture should enable direct client-server connection after name resolve so if you’re using load balancer to manage multiple servers you need to configure direct server return (https://www.haproxy.com/blog/layer-4-load-balancing-direct-server-return-mode/), sticky session or the combination. But in real life this usually doesn’t matter much.

Broker Pattern for Integrated Patient History

While in Observer Pattern we discuss how each hospital units keep it touch with the data, there is also the need to have integrated patient history between hospitals which means all data must be passed remotely. The question is, how to accommodate this use case in our system?

Broker Pattern, specifically message broker pattern can be used in this scenario.

Message broker

While implementing the pattern you need to provide client proxy and server proxy in order to make sure that there is no compatibility problem between different platforms and implementations as well as hiding inter-process communication details between said party to broker. The proxy will also takes care of marshaling (serialize) and unmarshaling (deserialize) messages.

There are lots of existing libraries / tools that can help you with the implementation of message broker pattern. Some of the most popular ones are RabbitMQ and Apache Kafka, among many others.

By understanding several different patterns and actively implement them, we should develop an intuition on how to solve some problems. There are a lot more patterns than described in this article and I personally recommend SourceMakingas your first stop on understanding further patterns. But we have to be careful to not fall into AntiPatterns trap, especially since sometimes, detecting Anti Pattern is hard.

Hope this helps!

Benefits of Pull Request Workflow

Bukhori M. Aqid — Sun, 28 Jan 2018 17:50:08 +0000

From no workflow to gitflow to pull requests. Here’s our story…

Initially, we don’t use Git for our projects. Around 2010, SVN is our main source control / versioning ( aside from Dropbox and USB Drive transfer 🤘 ). After we grow into several people working in the same project, several discomforts occurred and we decided to adopt Git around 2013.

finding commits for old feature got us like…

As usual, the first time is a mess. Several projects have messed up git history that made tracking and merging painful to do. We don’t have any consensus on how to divide branches, or any decent workflow to implement. People just do commit and push as they like. Finally in late 2014 we decided to adopt gitflow into our workflow. Things got better real quick. We know what to track, who’s doing what and the current branch status.

But there are still some pain points that we encounter, especially regarding our junior developers. To make a clear and readable branch history, sometimes squash / rebase / rewrite remote history is necessary. And since we don’t protect the develop / master branch sometimes the history got messed up real quick.

In 2016 we’re starting to actively release our own libraries and little by little using Pull Request as a way to manage our open source library updates. And surprisingly in 2017, several of our developers suggested that we use Pull Request workflow to replace gitflow.

To be honest, I was against Pull Request at first. The main reason is that it might introduce bottleneck especially when the reviewer is busy. Deciding the workflow is also requires some discussions ( should we use multiple repo? or one repository with protected branches? how to name branches? etc. ). But in the end after weighing the benefits vs drawbacks I decided to implement Pull Request workflow in some of our projects.

The result is incredible. The benefits totally outweigh the drawbacks. Let’s discuss them in details.

Benefits of Pull Request Workflow

Clean git history by using pull request, we can easily squash those redundant / unimportant / unclear commits before merging into main branch. This is enforced by our protected branch policy. Only the lead / captain can merge into main branch. Other developers are free to do whatever they want in their branches
Meaningful git history we used to neglect this one aspect but turns out this is more important than we think. By adhering with our branch naming convention, all pull requests and merge(s) becomes easier to read and provide features / fixes history. In the end, your git history can be a tools to track productivity and/or project velocity.
Remote code review process before pull request, we did code review face to face either by pair programming or code presentation session. Using pull request as our workflow, code review can be done before pull request is merged. This enable smooth code review process, even while doing remote work.
Better software quality making pull request means that the feature need to be approved by captain / lead and QA / QC. Before pull request, all features and fixes can be merged to main branch hence updating staging server without the knowledge of QA / QC. This makes testing harder because there is no way to ensure the staging server state. Doing pull requests means that staging server state will only be updated after all changes are approved by lead & QA. This ensures that all codes in our staging server is already inspected by several stakeholders hence better quality.

Drawbacks of Pull Request Workflow

Long review process especially when the captain / lead is busy. otherwise, all is well.
Time / process overhead there are some complaints that doing pull request resulting in more process to be done. You need to create a pull request in browser, adding comments & change logs, waiting & fixing for feedbacks etc. Sometimes an idle time happens because the developer is waiting for approval and cannot start working on new branch. We discourage working on parallel branches because we believe that focus is important.

Even though we successfully implement pull request workflow in some of our projects, a detailed guide is necessary to ensure that no redundancy / misconception happened. After several discussions we came up with this workflow conventions. Feel free to give your feedbacks and inputs on this matter!

After adopting pull request workflow with additional conventions above, I definitely can say that our projects have been better overall. There might be some problems here and there, but the benefit is really apparent. I suggest that you try to use this approach at least for comparison with your current workflow.

Cheers

disclaimer : This post is based on my personal experience while working with Flipbox. Our daily activities and projects is revolving around mobile apps & (sometimes) websites for clients. Those points and suggestions might not apply in a different circumstances.