Monthly Archives: November 2012

WinRT and WINJS

 

Even though installed windows 8 on one of the laptops quite a while ago, never had a chance to look at all the internals of windows 8 OS and all the software development options. Finally made some time to understand some of these aspects. Here is what I learnt.

WinRT is an abstraction layer over the OS. But, I found the concept of projection layer to be slightly different from what I was used to.

WinRT

 

WHAT IS WinJS?

WinJS is nothing but WinRT projection into JavaScript. It comes with quite a few touch optimized controls used to built windows 8 applications. It also includes new DOM constructs.

You must be wondering why go to all this extent to create JavaScript projection?. Well, main reason is to let many developers who are already familiar with HTML,CSS3 and JavaScript start developing windows 8 applications quickly without any steep learning curve. However, this WinJS is not portable to run in web browsers. Unlike PhoneGap, you cannot leverage the same code to run on multiple devices.

If you already know XAML,C#/VB and/or C++, you can leverage that experience to build windows 8 applications. XAML and C# is going to be my choice.

QUEUE,CAPACITY UTILIZATION AND FLOW

 

Whether you are manufacturing something or developing software, making sure that flow is smooth by controlling the queue and capacity utilization is very important.

How do you accomplish this? You will be surprised to know this. In order to increase the overall efficiency, WIP (work in progress) should be kept small. It is very easy to think that multitasking and doing lot of things at once means being efficient.

Lead Time = Starts when a given request is made and ends when the delivery is made.

Cycle Time = Begins when you start the work on a given request and ends when the items is ready for delivery.

Your customers will measure you based on the lead time.

lead-cycle time

 

HOW DO WE IMPROVE THE RESPONSIVENESS?

Important goal is to reduce all the items which does not add any value. Let us take an example to illustrate this. Green color means value-adding activity and red color means no value add. This scenario happens in many organizations. Whenever a request is made, people wait at various stages to the items to next level in the queue.

value-novalue

 

In this particular case:

Value Adding Time = 7 Hrs. and 15 Minutes

Total Waste Time = 19.5 days

Lead Time = 19.8 Days (475.25 Hrs.)

PROCESS EFFICIENCY = 7.25/475.25 = 1.52%

 

Let us see how the WIP plays an important role:

In this example:

WIP = 475.25/7.25 = 65 Items

In order to increase the efficiency, either you can hire more people (which can be more expensive and not practical in many cases) or the reduce the WIP.

Statistically it is proven that, reducing the WIP not only increases the efficiency and throughput, overall quality is also better.

WINDOWS SERVICE BUS V/S MSMQ

Everything looked great with Windows Service Bus until I noticed the CPU usage.

If you have ever built a distributed fault tolerant software systems, you already know the role played my message brokers. On Microsoft platform, until now we had only MSMQ (I am not counting all third party and open source message brokering solutions). This is a fantastic implementation of transactional queue which is good enough to build many great practical solutions. Couple of weeks ago, Microsoft released windows service bus 1.0. I was really excited to see the features. This is very close to everything I had seen in IBM MQ.

I couldn’t wait to see if we can take advantage of this new release. Everything seemed great, until I started paying attention to the CPU usage. I have provided a screen shot of task manager below. I am seeing this CPU usage of message broker pegged around 27%. IMO, this is not acceptable. I am pretty sure Microsoft will address this issue soon. Too bad, I have to wait for some more time, before our applications start taking advantage of this nice technology.

 

service-bus-cpu usage

 

UPDATES TO THIS ARTICLE – DEC 7th 2012

I sent the source code which caused this particular scenario to Microsoft and they could not reproduce this scenario. I am also not able to reproduce the same error.

Besides, you should consider your message size (MSMQ supports larger sized messages), weather you have plans to port your solution to cloud in near future etc. before moving your solution from using MSMQ to Windows Service Bus.