ECom plug-in – in the lights of Strategy Pattern

When I started understanding ECom architecture of Symbian, I tried to map it with some design pattern from the GoF book. This way I found out that the Strategy Pattern described as one of the Behavioral Patterns is the closest match. Let me share my understanding with you.

First of all, let me tell you about the Strategy Pattern as it has been described in the GoF book. It says that we should use Strategy Pattern when we have a family of related classes differing only in their behaviors. The class diagram of a simple strategy pattern would be like the following:



What this diagram essentially depicts is that Context and Strategy work hand in hand to determine which ConcreteStrategy to pick up in the runtime. We may pass a ConcreteStratgy object to the Context constructor to achieve this.

This can also be achieved by creating a template class of Context and passing Strategy as a template parameter. This will, however, be at compile time. Hence it would increase the efficiency with the cost of larger code footprint.

Now let me dissect the ECom framework to describe how it can be mapped with the strategy pattern. We know ECom framework is built as a client-server architecture. We don't have to bother about the background processing that the server does. What all we need to understand is the client interface of the ECom. There is a singleton class called REcomSession which is the client side interface of the ECom framework. It has got several exported functions out of which ListImplementationsL (there are three overloaded version of it) and CreateImplementationL (there are twelve overloaded versions of it) are the most important one.

So, to map the ECom architecture with the Strategy pattern, we need to understand when a client application (read context in the Strategy pattern) tries to load a specific implementation (read ConcreteStrategy in the Strategy pattern), how the ECom framework resolves it.

To do that, let me delve into one of the CreteImplementationL function of the client interface of the ECom architecture. I have taken the following function:

EXPORT_C TAny* REComSession :: CreateImplementationL(TUid aInterfaceUid, Tuid& aDtorIDKey, const TecomResolverParams& aResolutionParameters)

To implement an application which takes the help of the ECom architecture, we need to call the above function (say for example, from a menu command). Now, the most important things we need to know to load the correct implementation, are the Interface ID and the Resolution Parametrs. These are there in the registration file of the ECom plug-in.

So, here are the analogies between the ECom architecture and the Strategy Pattern.

1.In strategy pattern, we have a strategy interface from where different strategies are realized. In ECom, we create an interface which are realized in different implementations.

2.In Strategy, we pass the Strategy interface as a parameter to the context to load the correct implementation at runtime. The context object is created with the correct implementation of the Strategy interface. In ECom, we create the correct implementation by passing the Interface ID and the Resolution parameter from Client (read context) to the ECom framework.

3.In strategy pattern, the client of the context must know what are the concrete strategies available for the current strategy interface. In ECom, the application must know what are the implementation we have for a specific interface. Of course we can query about it using ListImplementationsL, however, the knowledge must be available to the application.

So, in essence ECom plug-in architecture is some kind of application of the strategy pattern.

Depression in the IT Industry

I was terribly disturbed by the news of the Pune-based techie who committed suicide due to work pressure. It is no less important news than the suicides of farmers in India. 

Software is all about passion - tickling our brains with new innovative ideas. It's really surprising to know how a worker in this field can ever feel depressed. 

I think we need to seek the answers to this dilemma from within the organization. 

We can easily assume that usually, people with an analytical bent of mind come to this IT industry. However, the path to becoming a good IT professional is full of bumpy rides.

I think the first and foremost thing for a software engineer is to seek the answer not only from the "How's" point of view but also from the "Why's" point of view. 

We must encourage the inquisition that a newbie in the industry comes with. We must encourage software engineers to go beyond the routine work and seek something extra. That extra thing varies from person to person. Moreover, we must create an environment where a software engineer should feel proud of the organization he works for. Without that emotional bondage, it's difficult to get the motivation to work on any sort of innovative work with all our body, mind, soul, and even senses directed to it. And it's difficult to create such environments without Gurus. It's all about mind games. I think we should stop thinking that salary and perks are the only factors to be doled out to motivate people. This way we can create some managers and workers, but not leaders and innovators.

I will tell you the reason for such a mindset to decipher Why...

When I joined NOKIA, India - I got a chance to see a different C++ dev framework - the S60 platform for Symbian.

There I found about the new concept called two-phase construction of a UDT

Everybody said - this is the norm - but nobody tried to decipher why this is the norm

So, my Why was nurtured to figure out this

And, I got it

When Symbian became a popular mobile OS, the mobile device had limited memory. And there was no template at that time to maintain smart pointer or auto pointer to tackle exceptions while constructing a large object

So, there was the answer

The two-phase construction was carefully introduced in the Symbian framework just to avoid the exception during the construction of large objects in the Symbian OS

I worked with NOKIA in 2007 and in 2008 I got the answer in Japan. I started studying Boost's library to answer such Whys' of C++ right inside Japan and then voila, the Boost library was introduced in the C++ standard library in the release of a brand new C++ in the year 2009.

Here goes a write-up by another sage that mentioned Swamiji's clarion call for the "Why's"

In search of Why...

Failure - a boon in disguise

Yesterday I was reading an article about the importance of failure in life. If properly utilized, the knowledge that we gain from failure can propel us to a new life. I have come to know about it from my own software career.

I first tasted failure in the beginning of my software career. Let me share it with you.

I came into the software profession from a telecommunication background without proper knowledge of programming and other software related technologies. However, I was confident that I could make it. With my little knowledge in programming, I was sent to Singapore for an assignment. I was given a task which needed good knowledge of C programming. Hence I was not able to solve the problem as I used to during my student life.

This inability came as a huge shock. My confidence became abysmally low. I was really confused about the relevance of the engineering degree that I had. It, however, acted as a stimuli that I have to learn the necessary software skills.

It was not easy.......especially in those days without the help of internet, google and all other relevant technologies that we take for granted these days.

From that failure, however, I had learned a lesson. The lesson of perseverance. I knew that someday I will be able to achieve the necessary skills required for a software developer.

From that failure onwards I started reading whatever books related to software that I could lay my hands on. I knew my target but the path was still unknown. However, with sheer perseverance, patience and hard work, I was able to achieve my goal.

These days when I decipher different software codes, I say, THANK YOU to that FAILURE.

Globalization of Indian Economy - through the eyes of a small town boy

The ambition of becoming an engineer was born in me when I was in class eleventh standard studying at a very backward district of eastern India in the year 1987. It was the ceremony of one of my elder sister's marriage and I was awed by one of the guests of my sister's would-be brother-in-law. He was in complete formal and I came to know that he worked for IBM, USA. I had no idea about IBM, and had a very vague idea about USA. Yes I am talking about those days when there was a single TV channel in India, when roads used to become deserted at around 9 o'clock in the morning because of the TV serial Ramayana, and when radio has just given ways to TV in Indian cities and when telephone used to be the symbol of status. I was barely aware of what was happening outside my hometown. After seeing that gentleman, however, one ray of ambition entered my calm soul - I started looking myself as a future engineer.

I was fortunate enough to crack the entrance exam and took admission in the civil engineering department of Bengal Engineering College, one of the premier institutions of India.

At that time another technological revolution was taking shape in India. That was the telecommunication revolution, and I used to read news about the brain behind that. Yes I am talking about Sam Pitroda. At that time all my fellow hostel room-mates were from the Telecomm department. I could not resist my ambition and took admission in the TeleComm department of my college in the year 1989.

Days passed by. When I was in the third year, I was introduced to PC and DOS and BASIC. I was, however, not satisfied by the syllabus of this subject. So I started looking outside for some help. I started learning Lotus 123 and WordPerfect from outside. At that time it was really difficult to gather information. There was no Google.

However, it gave me the interest to learn computer science. This way I was exposed to the globalisation of India. I took admission in the Masters of Engineering program in the Computer Science Department of our college in 1994. But it became difficult for me to pick up subjects like data structure, Operating system without any background. It was not that I was unable to understand the theoretical side of data structure, but with my existing concepts of programming knowledge I just could not implement those in C. My frustration was building up. The willingness to learn could not be satisfied by the means of learning. Finally I gave up and went for a job.

Thus I started my career. But it was only in 1996-1997 that I got a chance to come into the real software industry. I started picking up skills like C++, VC++ and Windows Programming.

Many days have passed by. But still I can't forget about those days when to remove a compilation error I used to sweat. Life was really difficult those days without the support of Google.

However, it gave me the right direction. I moved into the right path.

Many days have passed by. At present when I am trying to establish myself in the mobile technology domain, I wonder how I didn't have the knowledge of the difference between a cordless phone and a mobile phone, how I used to struggle to know about a telecom switch and its structure. These days when I read about fixed mobile convergence, I wonder how I had to struggle to gather the knowledge about CDMA and DECT. And I can't forget my struggle to make one senior executive understand the difference between DataCommunication and TeleCommunication.

My career is as old as the age of the economically liberalised India. As I didn't have the key to control my year of birth, I am definitely thankful to God for bringing me to this earth at the right time. I am at least the part of the technological revolution that has made the world "flat".....

Theory X and Theory Y

Ultimately- it's deep education that matters

Learn from the Israel PM, my favorite BB sir

It's very important for one to gather the right view about the big picture of the technology he works on but at the same time, he cannot neglect the nitty-gritty of the work. It's like a building architect should have sound knowledge about the basic masonry job or as a matter of fact, some knowledge about the painting or the interior decoration.

However, a mason may not always have to have the knowledge of an architect, but vice versa is not good for a true professional.

Please enjoy my early days' expression about the tech sector,

 

As I was going through Douglas McGregor's Theory X and Theory Y, I was astonished to map them to my own life. 

Let me start with my childhood days. Those days I was really afraid of Mathematics. I could not do well in the maths exam. Then my Mom came to my rescue and she did a little bit of hand-holding. She encouraged me and asked me not to be afraid of it and told me that practice makes a man perfect. From that day maths became one of my favorite subjects. 

This happened in my professional career as well. After a few years of work, I was almost on the verge of breaking down. I loved software, but somehow I was not getting the urge from my inner self. Then my wife did that magic. She gave me all the encouragement I needed. From that point in time, I came back into the industry again. 

I cited these two examples to tell you how a positive attitude and a little pat on the back work wonders. Probably theory Y was long back described in Indian Philosophy. 

According to the Hindu sage Swami Vivekananda

"

Each soul is potentially divine. The goal is to manifest this divinity within by controlling nature, external and internal. Do this either by work, worship, or psychic control, or philosophy – by one or more or all of these and be free.

"

Being in the software industry for quite some time, I can understand how it feels when someone new in this world faces the wrath of a foul-mouthed manager for not being able to fix the bugs or not being able to understand the compilation and linking error messages. For a newcomer, these may not be easy, but when someone, instead of empathizing with that poor guy, starts castigating him, it becomes more difficult. 

According to the Gita, one of the holiest books of the Hindu religion, a person has four stages in life. First, he will suffer, then he will be thirsty for knowledge, then he will go in pursuit of truth and then he will attain wisdom. 

I think in the software industry as well, a software engineer's first few years are years of suffering. But this period of suffering can be lessened and the thirst for knowledge can be injected by wise organizations. However, for that to happen we need mentors who themselves had gone through these phases.

I would like to add the concepts of intrinsic motivation vs extrinsic motivation here.

Intrinsic motivation is the act of doing something without any obvious external rewards. You do it because it's enjoyable and interesting, rather than because of an outside incentive or pressure to do it, such as a reward or deadline.

An example of intrinsic motivation for a software engineer would be deciphering a piece of a framework code because you enjoy doing it and have an interest in the matter or subject, rather than doing it because you have to prove a point to others or pass an exam.

Intrinsic motivation comes from within, while extrinsic motivation arises from outside. When you’re intrinsically motivated, you engage in an activity solely because you enjoy it and get personal satisfaction from it.

When you’re extrinsically motivated, you do something in order to gain an external reward. This can mean getting something in return, such as money, or avoiding getting into trouble, such as losing your job.

Now, the responsibility lies on the organizations to create a supercharged environment so that the engineers feel that intrinsic motivation - because the environment signals the gene of a human being to go the extra mile.

So here is the conclusion for the middle managers

"Praise more and criticize less" and get the best out of your juniors...

And for all those new comers in the software industry.... remember...

To Win is no more than this... To rise each time you fall...

My presentation on WiFi Security

The Evolution of a matured C++ software engineer

One day one junior friend of mine came to me and asked what he should do to become a proficient C++ developer. And I was stumped. I didn't have any direct answer to his queries. Then I started pondering on this matter and was amazed to know that although there are so many books and articles on C++, but there is hardly anything which will tell a novice what to do or rather what to read to become a matured C++ engineer. Hence I am writing this article to demystify some of the basic things one must be aware of to become proficient in this subject matter. Some of the ideas presented here are common to any software domain, but I have given stress on C++ specifically.

UML Use Case

Before delving into the nitty gritty of the language one should be comfortable with UML use case analysis. Because this is one of the major ways for requirement gathering process. And for a GUI oriented project this gives the developer the pictorial view of the different flow of the application. Or in other words the developer can visualize about the work he is going to produce. Because I believe that a piece of work is done first in the mind and then it is depicted in the actual coding.
But how to develop the skill set for the UML Use cases. The best way to go about this is to think in terms of use cases. One should try to divide any software work into small use cases. The use cases developed this way may not be very complex but it gives the developer the idea of the subject. One should pick up any standard books on UML and formulate the idea. There are free tools available on the internet. One tool that comes to my mind is Visual Paradigm for UML. It has a community edition which is free of cost.

C++ Basics

With the increase in knowledge of UML use cases, the developer should start learning about the different aspects of C++ side by side. He should clarify the ideas about inheritance, polymorphism, virtual functions, abstract classes and so many other things. This may take several months to complete for a person having computer science background, and for one without any computer science background, this may take more time.
Once he is familiar with the basic C++ ideas, now he is ready for an entrance in the industry.

Coding Standard

Before writing a single line of code in a commercial project, the developer should be aware of the coding standards. Besides telling about the indentation and commenting about the comments, the coding standard is helpful in understanding the basic C++ concepts. It gives the developer an idea about how to write a maintainable C++ code. It tells the developer about the naming convention and helps him to understand why long and self-explanatory naming of variables and functions are preferred. Not only that, it also tells one about some of the basic things one should follow when developing C++ code. As an example the following item in the coding standard tells the developer how to delete a heap based pointer.

SomeClass* ptr;
......
.....
....
delete ptr;
ptr = NULL;

So if one always keeps these things in mind, it will become his habit.

UML Class Diagrams, Sequence Diagrams, etc

After learning about the C++ basics, the developer should focus into learning the rest of the UML concepts. This includes mainly Class Diagram and Sequence Diagram. My suggestion for the developer would be to translate any kind of C++ code into Class Diagrams and Sequence Diagrams. Again Visual Paradigm for UML would be a perfect free tool to learn about these things.

C++ Design

Now as the developer has started some coding and as he is familiar with UML, he becomes more or less comfortable with the C++ programming style. But what about the design. This is a very important aspect in any object oriented programming. So my suggestion to the developer would be to pick up some good books and learn about the designing aspect of C++. He may go through books like Effective C++, More Effective C++ and books like these in that series. After going through all these books, one should get familiar with the concepts of Design Pattern. The developer should pick up the Design Pattern book of GoF and become familiar with several aspects of an object oriented project. I also suggest the developer to pick up design pattern books like POSA.

Open Source Library

Now the developer has become a proficient C++ programmer. So my suggestion would be to delve into the source code of some C++ libraries like Boost and Loki. Some of the concepts from these libraries like Generalized function pointer, etc are very interesting.

Documentation

This is also very important aspect of good software. Any software should be accompanied with useful documentation. So my suggestion to the developer is make it an habit to extensively document and comment in the source code. All the public interfaces of a class should be well documented. Along with that a document which will give the bigger picture of how different modules are interacting with each other would be useful. UML diagrams will be a perfect requirement in documentation.
Conclusion

Are these all to become a good C++ engineer? Obviously not. The main challenge lies in how one can traverse from the problem domain to the solution domain; how one can break down the actual problem in hand into classes and modules. In other words how one can visualize the problem and its solution. The UML tools are there to help one out, but ultimately its the responsibility of the person to use that tool.

Hopefully the above discussion will guide the novice to become a proficient C++ engineer.