Friday, 21 December 2018

End of 2018

The end of 2018 is on the horizon now. Joining with many other in the world, this is the best time of the year to reflect and make a resolution for the year to come.

Reflecting my life in 2018

At the beginning of the year, I was promoted to a Senior Developer role within my company after a successful internal interview process. The process pretty much the same as if you are going to be interviewed by an external company, which comprised of corporate value interview, behavior interview, and technical skills interview.

The first two interviews were using STAR model (Situation, Task, Activity, Result) approach, while technical skills interview include take-home application development, presentation, and interview. The take-home application was weather API application development. I only have less than one week to prepare, so I focus on the backend side of the application and only a slight touch on the front end. The complete code can be seen in the my gitHub repo here . The overall process going pretty smooth for me.

This year I also learned how to look after what I eat daily. Diet is important, and become very important after 40-an. Initially, I opt-in for low carbohydrate diet, my gradually add some carbohydrate back to my diet. I end up with DASH diet, which comprises half vegetables and fruit, a quarter of protein and quarter of carbohydrate. I also exercise regularly by running to/from work which takes about 30 minutes one leg of the journey.  Having done it for two months, my blood pressure gradually dropped to the borderline of normal range 120/80.

During this time, I also realized that a healthy lifestyle is VERY important, I do a lot of research about healthy lifestyle and become more aware of it, and became my first priority during this time. I put a list about healthy food I can consume daily, and I also start to avoid certain food. There are still many things to do on my list to acquire a healthy lifestyle, which  I am going to make a resolution for next year.

The other thing that happened to me this year was I got my residence permit in the UK in November. So no more visa application to stay and live in the UK, and free to work anywhere if I so wish. I applied at the same time as my wife at the PEO (Premium Service Center) in Liverpool and got approval on the same day. We overjoyed and spent the rest of the day sightseeing in the city.

At the end of the year, we are getting a family visit from my wife side and we will travel around the UK.

Friday, 15 December 2017

Clean Factory Design Pattern with IoC container

Audience


This article expects audience have familiarity with Dependency Inversion Principle (DIP) and Factory Design Pattern. For simplicity, the code is not defensive and there is no guarded statements. The code is using Simple Injector, but the described principles applies to other IoC container frameworks as well. The source code of the examples can be found in github by following this link


Problem


When implementing a factory class in a project which uses a Inversion of Control (IoC) container, and you arrive to the solution described below, then this article is for you:
using System;
using DirtyFactory.Dependencies;

namespace DirtyFactory.Processors
{
 internal class ProcessorFactory : IProcessorFactory
 {
  private readonly IDependencyOne _depOne;
  private readonly IDependencyTwo _depTwo;
  private readonly IDependencyThree _depThree;

  public ProcessorFactory(IDependencyOne depOne, IDependencyTwo depTwo, IDependencyThree depThree)
  {
   _depOne = depOne;
   _depTwo = depTwo;
   _depThree = depThree;
  }

  public IProcessor Create(RequestType requestType)
  {
   switch(requestType)
   {
    case RequestType.Internal:
     return new InternalProcessor(_depOne, _depTwo);
    case RequestType.External:
     return new ExternalProcessor(_depOne, _depThree);
    default:
     throw new NotImplementedException();
   }
  }
 }
}

Monday, 21 August 2017

Deep Dive into OWIN Katana and Web API


I was asked to give a presentation about OWIN and Web API to a different development team, as they wanted an introduction to the technology and no one in the team had exposure to that technology before. Prior to that, I have developed a number of internal API for our company. With the presentation slides and materials, I decide to write them down as a blog post as well, so it will be documented properly. I put a lot of extra information compared to the original presentation to cover a broader audience in the internet.

Saturday, 25 March 2017

Generic Pattern: How to do Fluent-API on both Derived and Base classes

I would like to share a lesson learned from work. I am working on a FHIR (Fast Healthcare Interoperability Resources) project. The task at hand was to create builder classes, which basically populate properties of different kinds of resource objects (e.g Patient, Order, Schedule , etc). All these resources are derived from the same object called Resource, which comprises properties such as Id, Meta (contains VersionId and Profile). The derived classes may have their own specialization properties/fields.

Saturday, 28 January 2017

SNOMED CT (Systemized Nomenclature of Medicine Clinical Term)

With recent NHS initiative to replace their clinical terminology, READ Version 3(or CTV3), with SNOMED CT (Systemized Nomenclature of Medicine Clinical Term), there may be a lot of questions raised about this terminology. I first knew about this terminology, in 2008,

Saturday, 21 May 2016

Dependency Inversion Principle: Part 5 - Using DIP/IoC container

(Note: you should read Part4 - Refactoring Using DIP before in order to understand this section)

I can just stop after refactoring code in previous section. I don't really need to use a DIP/IoC container. However most containers will have some additional features which enable us to tidy up the class composition code. You can even write your own IoC container with the features you really need.

Dependency Inversion Principle: Part 4 - Refactoring Using DIP

You have known the basic concepts of DIP, now it is time to apply it to the code. If the code is written without DIP principles, this means the code needs a refactoring by abstracting and inverting the dependencies. The code will normally have many interactions between classes. This mean that a class may have dependencies, but in turn the class will be the dependency of other class.

Refactoring the code using DIP will eventually create a tree structure which represents the class composition. Normally there will be one composition root, which is the class at the top of the tree.