Coursera: Programming Mobile Applications for Android Handheld Systems: Part 1 - My take

There is no argument that Coursera is one of the largest online education providers in the world. I recently completed the part 1 of the Android course and thought I would share some of my experience.

Not for the faint hearted

Yes, if you are looking for a basic overview of the Android system, then this may not be the best place to start. I would recommend looking at the official documentation on the subject from Google itself. In fact I spend more time reading the official documentation during the course than the course material.

Format

I would say the format of the delivery is pretty good. I really felt like being at University when listening to Dr. Porter (the instructor). His use of language is fantastic and very easy to follow.

The lectures are added to the course home page every week followed by assignments which are graded through an automatic grader. The assignments comes with very clear instructions. Generally the assignments are submitted in a form a zip file with requisite files in certain folders. Be very very careful with names as the automatic grader will reject if there are any special characters in the folder names.

The final project is peer reviewed.  As a part of the review process you are asked to review others work as well. (Here is my screencast that was part of the submission.)

Quality 

I think the material is pretty good. You are expected invest about 4/5 hours a week on the material. However I think you would need to invest more time if you are really interested in learning the platform. I started the course not simply to "pass" a course, but to learn. Therefore spend more time reading questions in StackOverflow and official Google documentation than the lecture material.

Final words

There are alternative courses offered by Udacity too. Once you start on the Android journey, I would recommend looking at other courses simply to enhance and solidify your knowledge.

Score

My score is 4/5.

Working with CallContext in WCF (with a twist)

In my previous post I discussed a bit about CallContext and how it can be used with WCF. In this post I will attempt to describe an issue I encountered and a possible workaround.

Issue

The CallContext looks pretty convincing when it comes to storing "state" of a WCF service on a per-request basis. This "state" flows through the local call context and very beneficial for async-await methods.

What I did notice is that under load (I mean with 10 requests per seconds), the content in the CallContext is shared. Which is pretty Bad.

Tool

In order to reproduce this issue, we need to use JMeter (or any load testing framework). JMeter is a tool that is used for load testing a web application.The documentation of JMeter may be bit scratchy, but is it worth the effort.


Reproducing the issue

We will need to add the following code to a WCF service. (Code is checked in here, and I will extract parts to explain the issue.)


Ideally we should never see "(GetPaymentDetails) CallContext already has..." message as this will shown only when there is something already in the CallContext.

Reflecting on the results

Normally Threads in the .NET framework is polled. This would mean same Thread will be used to execute multiple requests. After a request is complete, the Thread returns to the Thread pool.

So what seem to be happening is that the CallContext state is returned with the Thread to the Thread pool. When the same Thread is reused to process another request, it is quite possible that the state is still preserved in the Thread itself.

This could be a bug or expected behaviour of the CallContext.

What if we reset the CallContext at the end of the request? The CallContext reset is through a call to CallContext.Clear method. This may work. However in the scenario where multiple async-await method are used, we cannot be 100% sure that context is cleared across all the the Threads used to process the request.

Normally in .NET 4.5 CallContext uses "copy-on-write" behaviour. (more on this is here.) So although we reset in one Thread it is not propagated across all the Thread that we used to process a particular request. Therefore resetting it "at the end" of a request is not quite correct.

Workaround

The workaround is to introduce a "MessageInspector". At the beginning of the request we can reset the CallContext with a call to CallContext.Clear. This way we make sure the CallContext is cleared for the request.


Given the shortcomings of CallContext, I am not sure whether there is any other solution that may  work consistently .

Working with CallContext in WCF

The CallContext class is provided by the .NET Framework to "track" the logical execution of a request. It is sort of a property bag that is carried through the execution path.

Why CallContext is quite useful in WCF?

Prior to .NET 4 (most specifically async-await) paradigm, WCF methods were sort of synchronous. I use "synchronous" is a very loose terms to suggest that no explicit Threads were created by the developer to process a request.

However with the introduction of async-await pattern and Task Parallel Library (TPL), developing asynchonous code has become quite easy.

The issue really is that WCF was never designed (or at least visioned) to handle async-await in a graceful manner. Normally WCF use OperationContext to store extensions that can be used later in the application. The OperationContext hold state in thread local store which will never play happy with async-await. There are dozens of questions in StackOverflow around this matter.

There are few ways to design a WCF service that leverage the power of async-await.

• We can discount OperationContext completely and pass the any data items around.
• We can store the data points in a backing store and read when required. We may need to pass around a references, this may be acceptable. 
• We could consider CallContext to store request specific information and read it whenever required. 

The data stored in CallContext is maintained across threads (as by definition CallContext is per logical execution context). In theory CallContext could be considered as a replacement to OperationContext. We can continue using async-await without having to worry about the limitations in the framework (in this case WCF). 

Example

The following code is a simple wrapper over the CallContext.

A word of caution about what you should store.

• Generally it is advised that you should only consider storing immutable objects in CallContext. There is an excellent post here that explains the pros and cons.

An operation can use the CallContext wrapper in this fashion.

Summary

There is no double that CallContext is a very strong candidate for maintaining per-request data in WCF. Here is another post around CallContext from Winterllect. However there is a twist of CallContext that we need to be very careful about. I will write up my findings in the next post.  

(xp) Pair programming

Last week I spend good few hours with a colleague from a different team pair programming. I think I learned so much during these hours compared to whole of last year. This is not to say we do not pair in my current team. We do pair, but hardly any cross team paring. 

Some of the topics we paired on were:

• Tips and tricks of Castle Windsor.
• Integrating GitBook with TeamCity CI.
• Await-Async pattern and issues we encounter when used with WCF.
• Usage of Interlocked to prevent re-entrancy.  
• Implementing DDD (why rich models are encouraged).
• Event based service programming with NServiceBus.

Hopefully I will be able to write few posts covering the above points in the next few weeks and months.

If you do not pair or not encouraged to pair, then try it few times. The benefits are immeasurable!  

"Private" member access within same class

Sometime we are so busy "doing stufff" and miss the most basic concepts.

See the following code (LinqPad):


The key factor to consider here whether the code is going to compile. Actually it compiles and executes without any exceptions.

If you look closely you will see "friend.i.Dump()" and "friend.j.Dump()". This might be a cause for concern. This is because "i" and "j" are private members and how come we can call "f.i" in the "Add" method.

The "private" modifier indicates that the members can only be accessed within the same class. So in this particular case we are "inside" the "Friend" class and members are visible. Reference is here.

In order to prevent this confusion, simply use a property. That is simple and universally understood.

Castle Windsor IoC experiment

I use Castle Windsor for dependency injection at work. The application I work on is a large e-commerce application with many moving parts. I find a DI container such as Castle Windsor (Castle) essential considering the number of dependencies that needs to be resolved.

We use "feature" toggles to control what feature are turned on in Production. I think this is pretty common for any agile organisation. There are times, certain features are not ready and we "turn off" the feature so that the customer do not see it. Again, this is standard practice.

We register the dependencies in Castle using the fluent interface. As new features are developed, the number of dependency installation files increases. Taking a step back from this, I thought if we do not need a feature why its dependencies are registered in Castle in first place. I bet this is not an issue for Castle as there is no request to resolve a dependency. However I believe that if a features is "turned off" then it should not be present in Castle.

So I embarked on an experiment to see how this might work.

Problem description

We have the interface "IAnimal" that has multiple implementation "Bat", "Dog", "Cat" (different features). The idea is to register the correct type based on the feature that is currently enabled.

Potential solution

I used the following to register the dependencies in Castle.


There are no surprises here, I simply register types that implement "IAnimal" in the currently assembly. However what I have introduced here is an extension method. The idea is to provide the configuration that determines what dependencies needs to be installed in the container.
I also indicate that the "IAnimal"s that I find should be registered against "IAnimal" in Castle. (If you have used Castle, you know that there is "WithService.AllInterfaces()" that allows you to register types against all the interfaces that a dependency implements.

The extension method is below.

I use the "If" method to register each dependency if it is defined in the "config.Registrations". The key piece of information here is the "registration.UseWith". This defines in what context that the dependency should be used.

An example of an ordinary registration is as follows.

The data structure is pretty standard. It defines the feature key and what is and what is not to be used when a feature is turned on/off respectively.

The full code is in GitHub.

Issues and problems

Generally dependencies are registered at "startup". For an web application this means App_Start. This event is triggered at the start of the application and NOT on each request. What I am assuming in the above code is that the application will restart once a feature is turned on or off. I do not think this is the desired behavior. For a large scale application with thousands of users browsing at the same time, service downtime is completely taboo.

So to sum up, I am not convinced that the above solution is going to work for me. It has been a good learning experience going though documentation/Git repo to find out how "stuff" work.

In the next post, I am going to look at the next logical solution "TypedFactories".

Sorry to disappoint.  :-(

Encapsulation and SOLID (Pluralsight course by Mark Seeman) - My take

The title says it all.

Seriously how difficult it can be to understand Encapsulation. In my mind Encapsulation was simply "information/implementation hiding". If you are one of developers who believe Encapsulation is what I believed, then I strongly suggest following to the this Pluralsight course.

One of the key learning outcomes was understanding Command Query Separation (CQS). We all use this principle in our day to day development. I did not realise the power of this principle until when Mark dissect some confusing code. I learnt why should you make a clear separation between a Command (mutate state) and Query (idempotent). This was really refreshing. Seriously, is it so hard to follow this principle? When you work in a code base that is constantly been modified by half a zone teams cross multiple continent, my answer is Yes. 

I have not heard about The Postel's Law (Robustness principle), before this screen cast. If you have, then Good for you!, if not, then you should read NOW!. 

We have seen the use (or misuse) of Null for reference types. Have you heard about the Maybe<T> pattern?. This is purely a wrap around the Enumerable<T>. Simply put, if something is being returned then there will be 1 (one) element in the output, and 0 (zero) if none. This is quite useful to avoid returning Null from a reference type contract. I found this slightly confusing first. But once I understood the intent, then I do see the advantages.

So, if you would like to refresh your core OOP skills, then this is the course you should seriously consider.