should-you-always-pass-the-bare-minimum-data-needed-into-a-function‏

I have found the following architecture dilemma in the following post In my opinion the method: void Authenticate (User pUser )  cause decoupling between the User class and the authenticator class.
In case we will want to authenticate a Roll the Roll should implement inherits from 
User. 
What about IAuthenticatee interface?
This raise the problem of authenticate not using name password group , so I change the name of the interface to INPGAuthenticatee  
Note : 
I think that creating an interface INPGAuthenticatee   that inherits from IAuthenticatee  make thinks too complicated at the first stages of the development and design process in order to KISS at the first stage we will use just the INPGAuthenticatee    interface and if there will be a need to authenticate using other information the authentication  in advanced stages  of the project the authentication mechanism will be refactor. 

I don’t like the option to give the User option to call authenticate directly because it will prevent the option to apply policy for example after 3 authentication failure to lock the account. 
(The policy component should be separate from the authenticate component)

Resources:

http://programmers.stackexchange.com/questions/216371/should-you-always-pass-the-bare-minimum-data-needed-into-a-function‏

 

Inspecting executing commands for cancelation

Sometimes a New Command Execution should cancel current commands execution or remove older commands from a commands Queue .
For an example:
When a Command is issue to Self driving car to follow a route while other route command is currently executing , the new Route command should cancel the execution of the old one.
There should be a mechanism in the software that its duty is to decide is there a need for canceling a commands before executing the new command ?
The  mechanism should determent:
1.Which commands to cancel ?
2.Can the cancelation process may be invoked in parallel to the execution of the new  command or the new command execution should be blocked until the cancelation process finished .
3.Maybe instead of cancelation of a command execution an execution blocking is needed (in case of resource sharing between the commands and there is a need to boost the current command execution ).
The algorithm for selecting the command should be based on the following parameter's:
1.Commands that are currently executing or in queue .
2.Priority of the current executing commands .
3.Internal concrete state of the current executing commands.
4.Shared resources that are consumed by the current executing commands
5.The period of time left for the old commands to finish it’s duties.
6.System overall state.

One of the architecture dilemmas is where to implement the mechanism  for choosing the commands to be canceled.
Should it be part of the Command ?


List <ICommand> GetListOfCommandsToCancel (List <ICommand> pCurrentExecutingCommands).

There is a Single responsibility principle violation in this case I think .And this attitude may lead to DRY violation were each command may implement a similar mechanism .

May be the following implementation :

Here there is a decoupling between the command and the commands that should ne canceled.

I think that the return value of the GetListOfCommandsToCancel should be extend to use custom return type

The IComamndCancelationInspector may have properties used to query the current domain overall state in order to determent its result.
The recommendation may although contain if the cancel of just postponed the command .

The execution sequence of the process :

 

Note:
The cancelation process is out of this post scope.

benchmark VM host scheduling

Our benchmark system is based on a private cloud that is managed by OpenStack framework.
For each benchmark execution session a new VM is created form an Image that include the benchmark tools .
The VM should be schedule to be host on a machine that the maximum remaining work of other running instances of vm that are executing on this machine is the less from all other machines.
Apsedo code for host selection scoring:

Int MaxWork
Foreach ( Vm nextVM in Host.GetVms())
       If ( MaxWork < nextVM.RemaingingWork )               
                   MaxWork = nextVM.RemaingingWork
Return MaxWork

The goal :
Setting the custom weights in our private cloud.
In the Nova  configuration file.
scheduler_weight_classes=nova.scheduler.weights.all_weighers

Note:The filter can be one of the build in filters

The following tasks should be consider during the solution architecture:
1.How can I get all host vm references ?
2.How can I send a vm remaining time to the nova weight component  ?
3.how can I write a custom weight component  ?
4.how can I consider other instances that executes other jobs then benchmarks in the weight calculation?

References:
http://docs.openstack.org/grizzly/openstack-compute/admin/content/weights.html
https://github.com/openstack/nova/blob/master/nova/scheduler/weights/ram.py
http://docs.openstack.org/trunk/openstack-ops/content/customize.html
http://docs.openstack.org/grizzly/openstack-compute/admin/content/scheduler-filters.html#imagepropertiesfilter
http://www.slideshare.net/guptapeeyush1/presentation1-23249150

Map interface design review

Last week I had design review session about Map wrapper interfaces.
The interface is part of a module that allows a programmer to switch map infrastructure implementations within its product transparently  to the logic of the UI layer 

Part of the proposed interface looks something like this :

The goal of the MapSurface interface is to allow adding drawing annotations on the map like routes , spots areas etc.

Prons

1.KISS:
Very simple interface allow the programmer quickly learned how to use it even without documentation and code samples . 

Cons

1.Open close principle violation:
In order to add handling for new widget type for an example a closed curved etc the IMapInterface  should be changed .

2.The interface does not allow me to use the created route in a surface of a map in other window .

 

 

 

UI reenter event deadlock

Dead locks in application are very often  related to the intersection between UI thread and BL layer threads.
Most of the UI technologies require single thread affinity to the UI  calls.so in order to update the UI  the BL threads must invoke a method through mechanism (like the control.invoke in wpf ) in order to change context to the UI context .

The following diagrams demonstrate a locking  problem that may be caused due to this :
 

1.A BLL activity wants to send update to the UI.
2.The message is send to a common point that invoke events in the UI .The common point is implemented the Front controller pattern . Often this point is protected by locking mechanism in order to void the situation were several updated are entered to the mechanism of the front controller.
3.The UI process the message and call the BL layer to help
4.The helping activity try to access the UI with result  or notification and bang a dead lock .

A lot of poor design is involved here but Its happens to me to meet several systems that implements the front controller badly and the troubles come along.