Head First HTML5 - Geolocation notes

• The Geolocation is a pretty much in the HTML5 standard. The goal of Geolocation API is to find out the longitude and latitude of the accessing device (whatever it may be). There are multiple ways of finding the location of the user. These methods are through IP address, GSM triangulation,  GPS and WiFi. 
• The older browsers may not support Geolocation, therefore we need to ensure that this feature is available before using it.
• The Geolocation API is part of the navigator object. See the following code.

• What is most interesting is the object returned by calling the "getCurrentPosition" position. BTW the "displayPosition" and "displayError" are functions. Basically "getCurrentPosition" takes in 3 arguments. These are success, failure and options. (just search for details.)
• The object returned by "getCurrentPosition" looks like below.

The composition of "Position" object

• The 3ed argument to the "getCurrentPosition" is the options. The properties that comprise this object are "enableHighAccuracy" (false), "timeout" (Infinity), "maximumAge" (0 - in milliseconds). The browser returns the result that is determined less than the "maximumAge". 
• Setting "maximumAge" to 0 may force the browser to get a new position.
• Setting "timeout" to 0 and "maximumAge" to 0 will cause the error handler to be called if there is not a new position immediately. (may call the error handler immediately.)
• Setting "timeout" to 0 and "maximumAge" to 1000 (1 second) may cause the browser to return a position that is less than 1 second old. If not error handler is called.
• The other methods in the Geolocation API are "watchPosition" and "clearWatch". The callback registered in "watchPosition" is invoked whenever the position changes (e.g. moving around). As the "watching" function is expensive we can "cancel" watching by calling "clearWatch". The handler returned from calling "watchPosition" is used to cancel a watch.

Head First HTML5 - JavaScript notes (2)

"namespace"

• There is no strict "namespace" construct in JavaScript similar to C#. The notion of "namespace" is used to reduce the scope of the variables and prevent polluting the global namespace. 

The output looks like the following:

Simple "Namespace" 

• The next step is to add functions to this namespace. We can use a self-executing function for this purpose. See the following. The idea is to add our custom functions to the namespace.

Head First HTML5 - JavaScript notes (1)

Basic

• JavaScript is not a statically typed language. The core types are Object, String, Number, Boolean.
• The properties of an object can be accessed through "." or ["property name"] syntax (e.g. obj["name"], obj.name)
• Arrays are pretty standard. Two ways of declaring. See below:

• JavaScript objects are not "typed", instead think in terms of the "shape" of the object. See below.

Functions

• Functions does not require a name. This is like anonymous functions in C#.
• Functions can be considered "value" and it can be passed around as variable. Think about "Action" or "Func" (delegates) in C#.
• Variables declared as "var" in functions scoped to the function itself. It is a good practice to scope variables to functions. 
• Normally when passing arguments to functions, be aware that the primitive types are passed by "value" and objects are passed by "reference". The "reference" allows to get to the original object, similar to C#. See the following code.

• Objects can contain behaviour which is achieved through functions (method). See below: 

  

• The notion of constructor can be used to create an "object". The constructor in this case is a function.  See the following:

Most importantly the "new" keyword is used to create a new instance of "Dog". Its a convention to capitalise the constructor function.

• The methods attached to an object can use "this" in the body. The "this" keyword refers to the object that the method is contained in. Normal functions may not use "this" in the similar fashion to a method in an object. 

Curse of the Base class

Please do not get me wrong, Inheritance has its place.

In this post, I will share a very badly designed base class implementation. The goal is not to criticise someones work, but to learn from it.

Some code

The Platform (developed by a 3ed party) we use had a base-class implementation that was similar to the following.

The class itself looks innocent but it has massive problems. The following is the example provided in the documentation.

So how can we actually unit test this code. Nightmare!

Refactor (ugly)

We need to organise the class so that is it suitable for unit testing.

The following is my first attempt. (Remarks: I am using bastard injection in this example.)

We have removed the call to the base class "Add" method in the derived class "Add". The most odd looking code is in the public constructor. It is calling the internal constructor with "IDatabase" and null. If you remember the constructor resolution order, you might remember that the public constructor is resolved last (in the above example). This means that the "_addAction" delegate is initialised twice. Once with null then by the actual value from the public constructor.

Unit test

Sorry, ideally you should be writing a test first. (TDD!).

The unit test should focus on the code we wrote, not what is provided by the Platform.

Its all here.

Udacity Web Development course

I finally got around to completing the "Web Development" course on Udacity. I have to say the instructor Steve Hoffman has very good technical knowledge. The examples he presented are very good and "real".

It is really great to see instructors outside the academia conducting these courses. Sometime what we need is practical and realistic examples rather than hypothesising a use case.

My next target is Software Testing course.

Big thank you to Udacity for presenting these courses.

My cert :-)

The God object (patterns) [2]

In the previous post I was at a point where the baby was feeding, sleeping and most importantly making sure we spend money on nappies. In this post I attempt to extend my initial design.

So far my TheSpecialOne class looked like below:

A week went pass and after many hours of sleepless nights we realised that the baby was constantly hungry. Being responsible parents we kept on breast feeding, but it was time for the magic formula milk.

Our requirements were very simple. We wanted to be able to breast feed and swap to formula milk to top up. We wanted make this change without having to disturb the baby too much (or without him knowing).

If you take a step back, we see that feeding is an activity and only the method used for feeding is what is changing. So in reality we should be able to swap between different implementations (of feeding methods) without changing the abstraction. We would need the flexibility to alter the feeding process independent of the method used. Sounds familiar? What I am describing here is the Bridge pattern.

I have done some fundamental changes to my initial design. I introduced a new interface called IFeedStyle. This is the abstraction I will use to introduce different methods of feeding (e.g. bottle, spoon feed etc).
However I know that as he grows, we will need to be flexible. Consider the following code.

The key aspect here is that the "Start()" method is abstract. This way I can create as many derived classed as I want. As the baby grows his eating habits will change. While he is a baby, he may only take milk, but when he becomes a toddler some solid food. But while having solid food he may like to play with some toys but drink milk using a bottle. The idea is simple, based on different strategies, we can decide how to feed. For the moment we will only have a baby specific implementation of this abstract class.

The above abstract class must be integrated to the Person class. The following is the modified Person class.

I think you should see the advantage of using the Bridge pattern. The actual task of feeding does not change, only the implementation that meets the FeedableBase class. We can provide different implementation without modifying the Person class. Now the IFeedingStyle and FeedableBase can change independently.

All set, the calling code looks like this:

More to the point, the output looks like this.

Enough fun and back to real work!! (code is here)

The God object (discovery) [1]

In Software Engineering the God object this refers to an object that every other object depends on. I am sure simple search on the internet will yield dozens of articles describing the pros-n-cons of using a God object.

Me and my wife welcomed our son few weeks ago and I was immensely busy. It is only today that I managed to find few hours to myself to write this note. When it comes to baby stuff, I think whatever the literature that is available in the market is only half the story (or may be less). Having a child changes everything. This ever-hungry machine will forever change your life and mostly in a good way. Yes, you will loose few hours of sleep here and there but I think its absolutely worth it. The joy and happiness that this new member brings to your small family is priceless. Enough talk.... :-)

The God object is like a baby. We know its there, but for an application point of view its a big black box. The God object can do everything, (e,g write to database, file system, resolve dependencies etc). For a development team that is mature, understanding what the God object is not that difficult. However for a new member its similar to becoming a father/mother for the first time. You just know its there, but just do not know how to use it!

So what do I know about the Baby (God) object. The only thing that I knew at the beginning was it derived from a very generic class Person. Thanks to to modern wonders of science and technology we found out the gender of the baby. Therefore we knew its a Person and had a property called Gender which was set to to Male. So my abstract world looked like this.

After the baby was born I soon realise that this God object has a very simple and effective behavior. Crying. I have to say is very effective and the best way to model this behavior was to implement ICanCry interface. Crying can sometimes be a Big thing! especially for a new born. My object model was evolving.  

My son is very special to me, therefore I did not hesitate to make a brand new instance of this Person. We cannot create an instance of a Abstract class, however we can derive from it. I called this specialisation TheSpecialOne.

You might wonder why I decided Abstract the "Cry()" method as above. The reason is quite simple. Each baby cries differently. Some can be very loud but others are not. Therefore I decided my son can decide how best to cry :-). 

This does not look right, don't you agree? Well, every person should have a gender. We need to ensure that this is a required property. The best way to make sure that the Gender is populated is to have the Person class to contain a constructor that takes in the gender as a parameter.

We were starting to forget the most important piece of the puzzle. The Name. There is no doubt that a person should have a name, therefore I introduced the new Name property to the Person class.

Few hours after the baby was born he was ready to feed. As this is a fundamental behavior of a person, I thought of introducing this behavior to the Person class for the moment.

It did not take even few more hours to realise another fundamental behaviors. These were "poo" and "sleep". So I modeled this in to my glorified Person class. 

One thing I did do was to implement "Poo" in the base class itself. Whatever we take has to come out at some point. Therefore I did not really see the point of having a specialisation of "Poo" in my TheSpecialOne class.

So far my son is feeding, sleeping, crying and can poo. (Code is here.)