Announcement of Windows Store App and Windows Phone App Development Blog

Hi, All,

I took the effort to reorganize my blogs. with that effort I created 2 new blogs, one for Microsoft Mobile App development ( windows Store App and Windows Phone App); One for Apple iOS app (iPad and iPhone) development. I have migrated most of relevant posts to these 2 new blogs and I will continue the migration process.

  http://peterlumsmobile.blogspot.com/

http://peterluios.blogspot.com/

http://peterludotnet.blogspot.com/

http://peterlusql.blogspot.com/

http://spellingchampionapp.blogspot.com/




these are the links to the newly created blogs and 2 other blogs, Enjoy and your comments are most welcome.


Thanks.

Inversion of Control (IOC) and Dependency Injection (DI)

For some time, I wanted to write something about this topic. it was largely due to my laziness, until now.  well. I guess I overcame my laziness today, and took the effort to get to this topic…

in most of program we write, there are always 2 parties involved, namely provider and consumer. when you write a method which instantiate another class and invoke a method of the instantiated class,  the code you are writing is the consumer, and the class you are instantiated is the provider. the same class in different context could switch its role between consumer and provider.  however, there is one common characteristic between the consumer and the provider, that is the consumer have the control and calls the provider.

Inversion of Control ( IOC) is a mechanism by which the control been transfer to the provider, in another word : let the provider take the control.  the over all goal of IOC is to break the dependency between the consumer and the supplier and yet let them communicate freely. if you take a closer look at the IOC implementations, you will find there are a few different implementation of it. I am going to list them below and give some of them some more detail elaboration on some of them:

Delegates

most of modern programming language supports Delegates, with the exception of Java.  if you look back at any declaration statement 

People myManager 

People is a class defined somewhere else, myManager is a variable can take any instant of People class. 

in 

DayEndOperation myDayEndOperation 

DayEndOperation is a Delegates defined else where, and myDayEndOperation can take in any instance of DayEndOperation

like in the class case, you can invoke the method or property of the class by myManager.Name or myManager.Approve ( yourRequest). in the case of delegate, you can invoke the delegate. you can pass around the delegate as parameter. This is very important as you create a delegate from consumer class and pass it to a method of the suppler class. and let supper class decided when and where to invoke it. 

Event 

Event is a special application of Delegate.  the suppler class defined certain events, when the consumer class instantiates the supplier class, the consumer class get to defined event handlers to react to these events. in the course of execution of the suppler code, the supplier class fire up certain events and in react to the firing of the event, the consumer’s event handling logic get executed.  the key is the supplier took over the control and calling the supplier code. underneath any event handling mechanism, you will see a delegate as part of implementation.

Dependency Injection

Dependency Injection is a mechanism to break the dependency from the consumer to the supplier by introducing Interface.  in this case, 2 more players got into the picture other than consumer and supplier,   ISuppiler and  container. in compiling time, consumer only depends on ISuppiler instead of the solid implementation of ISuppiler. in runtime, container injects the solid implementation into the interface. the injection could be done in code, or by configuration. when it is done in configuration, that means, in run time I can switch the solid implementation of the interface without recompiling the consumer code. This characteristic make it very good for doing coded unit test, because I can inject some stub implementation into my test method to test my consumer code without calling the real supplier components. there are constructor Injection, Property Injection and Method Injection. most of DI container support all of them.  I personally worked on Unity and NDepend.

Service Locator

Suppose your consumer classes have dependencies on an external service , whose concert types are specified sty compile time. The following limitations are posed to the system:
 1. to replace or update  the external service, you need to update your project reference and recompile the solution
2. the external service must be available at compile time
3. your class is difficult to test in isolation because it need the external service to run


Service Locator pattern introduce another element, call <Service Locator>  and let Service Locator handle the dependency of the external service.  in detail implementation, you could inject different locator to your consumer project, or you inject external service into your Service Locator  or you use Factory Pattern to handle the instantiation of the external service.  if the service provider provides respective interface of the service, DI is preferable, otherwise use factory pattern. this preference is due to the fact, only doing DI you will remove the dependency of concert type of the service and only when the interface is provided, you can do DI.

Anti-pattern for August: Walking in a Minefield

The title of the anti-pattern is: Walking in a minefield. The sub title is “the application’s ready for production… you go first."

The elaboration is read as:  When a product (known to be incomplete) is released prematurely, this forces users to stumble through the system finding bugs while the development team scrambles to resolve them.

http://deviq.com/walking-through-a-minefield

This link provide some further reading on the anti-pattern (including interesting photo). For your convenience, I copied some here:

When software is released before it is ready, and users of the software are made to find all of its bugs and shortcomings, they're made to feel as though they're walking in a minefield. It's important to release software as quickly as possible, in order to minimize feedback loops, but what is released should work so that users do not lose confidence. Each new release should be more stable than the last, and should incrementally add new functionality. If the system is constantly shifting such that things that work one day fail the next, eventually users will demand a different system altogether, and the project will fail.

 Quotes

"Software undergoes beta testing shortly before it's released. Beta is Latin for 'still doesn't work.'" - Anonymous

There is a related anti-pattern, it says “let’s test it in production.”

 

The commonality of them is releasing a untested product to the end user, with the hope that the product is not buggy or if it is buggy, the users will help to identify the bugs for the development team to fix so that the software product can be useable.

From principle point of view, this is not a good practices, when the product is released for production, it need to have some kind of quality standard. Release an untested product to production is not fair for the users or client. It may very well negatively impact client’s business operation and could damage their reputation or expose client to other tangibles damage.

From technical point of view, some bugs could cause loss of data, and the lost data may not recoverable even if the bugs are fixed afterwards.

The biggest risk is that when an untested product exposed to its user, the users might very well discouraged by the buggy product and hence reject the product totally. 

However, in my decade’s application development experience, I have seen many incidences of the anti-pattern. I remember a few years ago, I attended a high level project strategy meeting. The meeting is to establish a strategy to address the issues of lacking of resource and time for developing and conducting test cases during the stabilization phase of the project. To my surprise, the decision was cutting down the number of test cases  significantly. The justification was: there is no enough time.  When I heard that, I could not believe my ear, this is exactly, “let’s test in production”

My take on it is simple, “Never”, never do that! An experienced project manager should be able to project such project risk and mitigate such risk so that it will never become an issue to be addresses in the project.  From technical resource point of view, when you are brought into a project to handle the crisis, you should take positive attitude do your best to recover from the crisis. I personally have been in such situation many times. The advice I could offer are the following:

 

1.    Backup database often, make sure the raw data entered by user is stored in database correctly. In production system, nothing is more important than data.

2.    When patching data error generated buggy logic, make sure the patching logic does not get extended beyond its intended scope.

3.    Fixing bug and patching data need to be in sync.

4.    Apply pair programming to reduce human error.

5.    When fixing bug, do your best to respect the original design and minimize the changes to be made. It is always risky to change design when product is in production.

 

Finally, remember there is no bug is small in production.  You could never be more careful. As the title said, it is a minefield, you do not want to walk in the minefield. When you are forced to walk in the minefield, be absolute careful.