14k Gold Coin - 100th Anniversary of the Canadian Arctic Expedition (year 2013)

The Canadian Arctic  Expedition 1913-1916

On the antique celluloid, the light flickers. Sled dogs move silently across the Arctic tundra. A man perched on an ice floe surveys the horizon as teams of men and dogs prepare for ice-bound travel behind him. In the distance snow-capped mountains rise into the sky like jagged shards of ice.

In grainy photos, men stand alongside makeshift fences, before shelters made of skins and furs, in open ice fields, atop sleds packed with gear. Some smile; others stare silently into the lens, arms crossed, thoughts unfathomable.

These are only a few of the approximately 4,000 photographs and more than 2,700 metres of film capturing one of the twentieth century’s most exciting moments in exploration: the Canadian Arctic  Expedition.

In 1913, Canadian Prime Minister Sir Robert Borden commissioned an expedition, led by Manitoba-born ethnologist Vilhjalmur Stefansson, to explore and map the western Canadian Arctic. Stefansson and zoologist Rudolph Anderson had travelled through the Far North the previous decade. Knowing that there was a great deal of unexplored potential in the region, Stefansson planned to continue his earlier journey, but the Government of Canada, recognizing the importance of new sovereign territory, hosted the Expedition and broadened its mission significantly. A Northern Party led by Stefansson would undertake the mapping exercise while a Southern Party led by Anderson would explorer the geology, resources, and native inhabitants of the northern mainland.

Traveling by sea and despite significant hardships, the Northern Party covered thousands of kilometres, mapping land that even the local inhabitants had never seen. The Northern Party discovered four new islands and proved that some of the geography proposed by nineteenth century expeditions was erroneous.

The Southern Party completed the full mapping of the mainland and produced 14 volumes of scientific data as well as thousands of specimens and artefacts, opening up a new world of wonder for Canadians. Their findings included information about flora and fauna never before recorded, fossil samples, and more. Their cultural research familiarized the world for the first time with the culture and way of life of the Copper Inuit and the aboriginal peoples of the Northwest Territories, Yukon Territory, Alaska and Siberia. From these Aboriginal peoples – some of whom participated in the Expedition as guides and other assistants- they collected artistic artefacts, tools, knowledge, and thousands of photographs as well as extensive film footage.

The Expedition’s artefacts, photos, and recordings enabled researchers to introduce to the rest of the world cultures that had been virtually inaccessible until that time. The artefacts have also had a broad educational legacy, forming the basis of numerous educational programs and museum exhibits, and are an important pillar of the permanent National collections of the Canadian Museum of Nature and the Canadian Museum of Civilization.

14k Gold Coin - 100th Anniversary of the Canadian Arctic Expedition

This 100-dollar coin is certified to be 14-karat gold with a metal content of 12 grams and a diameter of 27 millimetres. In this design, Canadian artist Bonnie Ross depicts several key images representative of the Canadian Arctic Expedition, including a survey team atop an ice floe taking research measurements and, in the background a stylized map of the Canadian Arctic. The obverse features the effigy of Her Majesty Queen Elizabeth II by Susanna Blunt. 

14k Gold Coin - 100th Anniversary of the Canadian Arctic Expedition - Mintage 2500 (2013) [Front]

14k Gold Coin - 100th Anniversary of the Canadian Arctic Expedition - Mintage 2500 (2013) [Back]

Mintage/Tirage

0218/2500

Certificate of Authenticity

This proof quality 2013 $100 gold coin was authorized by the Government of Canada. It was expertly struck by the Royal Canadian Mint and has a limited mintage worldwide (a maximum number of 2500 coins were produced).

Proof Fine Silver Dollar - 100th Anniversary of the Canadian Arctic Expedition

This proof silver dollar is certified to be 99.99% pure silver with a diameter of 36.07 millimetres and a weight of 23.17 grams. Designed by Canadian artist Bonnie Ross, the reverse image draws on photography from the Canadian Arctic Expedition, depicting a group of three men aboard a dogsled, the waiting dog team before them listening for the command to move on across the Arctic tundra. The skyline and horizon behind this portrait are filled with stylized image of a compass. The obverse features the effigy of Her Majesty Queen Elizabeth II by Susanna Blunt.

Proof Fine Silver Dollar - 100th Anniversary of the Canadian Arctic Expedition - Mintage 40000 (2013) [Front]

Proof Fine Silver Dollar - 100th Anniversary of the Canadian Arctic Expedition - Mintage 40000 (2013) [Back]

Mintage/Tirage

12866/40000

Certificate of Authenticity

This 2013 silver dollar is proof quality and is authorized by the Goverment of Canada. The coin has been expertly struck by the Royal Canadian Mint and has a limited mintage worldwide (a maximum number of 40000 coins were produced).

How to open a checking account at ING DIRECT?

ING DIRECT (Canada) was re-branded (renamed) as Tangerine as of Tuesday April 8th, 2014.

For instructions about how to open a checking account at Tangerine go to the following up-to-date article: How to open a checking account at Tangerine?

Tangerine kept most of the things from ING DIRECT. In their own words: “We’re changing our name, but we’ll never change who we are”. From the customer’s perspective, it was mainly about changes in the names of the services (products) provided and the organization itself.

Here is a summary of the name changes (old account names to the left and the new names to the right of the -> symbol):

• THRiVE Checking Account -> Tangerine Checking Account.
• Investment Savings Account (ISA)  -> Tangerine Savings Account.
• unmortgage ->Tangerine Mortgage.
• ING DIRECT Streetwise Portfolio ->Tangerine Investment Funds.
• Streetwise Balanced Income Portfolio ->Tangerine Balanced Income Portfolio
• Streetwise Balanced Portfolio ->Tangerine Balanced Portfolio.
• Streetwise Balanced Growth Portfolio -> Tangerine Balanced Growth Portfolio.
• Streetwise Equity Growth Portfolio -> Tangerine Equity Growth Portfolio.

The only real change I see as a customer, is the about the access to ATM machines. In the times of  ING DIRECT, THE EXCHANGE  Network was used for free. This will continue to be free until September 30th, 2014. After this date, you won’t be able to access ATM machines THE EXCHANGE  Network for free. This will impact some people I guess.

Instead you could use the Scotiabank ABM Network (containing nearly 4000 machines) and the Tangerine ABMs (which allow you to withdraw US dollars) for free.

Tangerine (formerly ING DIRECT) is a great banking alternative to the traditional ones (RBC, TD, Scotiabank…).

With Tangerine (formerly ING DIRECT), you don’t pay monthly fees, you get interest even on your checking account…You won’t be disappointed. My advice: switch to Tangerine. For details click the following link: How to open a checking account at Tangerine?

Enabling TLang to handle more than 17 translations: a workaround for a regression bug in Delphi XE3

I recently had to localize a FireMonkey application and for that I aimed to use the TLang component. With TLang you can define a collection of native strings to be localized and the corresponding translations to a particular language. To my surprise the component was allowing to store a maximum of 17 translations for the whole application. So, what about the other strings that need localization?

It seems there’s a regression issue from Delphi XE2 to Delphi XE3 that is preventing TLang to store more than 17 translations. You can even find an entry for this in Embarcadero Quality Central, for which no workaround or fix has been provided up to this date.

I found a programmatic workaround for this issue. Basically, the native strings and the translations could be loaded from text files in which each line will have the form:

NativeString1=Translation1
NativeString2=Translation2
NativeString3=Translation3
…………
NativeStringN=TranslationN

You will need one file containing the native strings and the translations per language. These files can contain as many lines as you which (certainly more than 17). In order to load those files into an existing TLang component you can use the function below:

procedure LoadTranslationsFromFile(aLangCode: string; aFileName: string; aLang: TLang);
var
  Translations: TStrings;
begin
  if (aLangCode <> '') and
     (FileExists(aFileName)) and
     (Assigned(aLang)) then
  begin
    Translations:= TStringList.Create;
    Translations.LoadFromFile(aFileName);
    aLang.Resources.AddObject(aLangCode, Translations);
  end;
end;

For an example of how to use such function see below:

procedure TForm1.Button1Click(Sender: TObject);
begin
  LoadTranslationsFromFile('ES', 'C:\Temp\Lang_Test_ES.txt', Lang1);
  LoadTranslationsFromFile('EN', 'C:\Temp\Lang_Test_EN.txt', Lang1);
end;

Hopefully this bug will be fixed in the near future; but meanwhile you can use this workaround to handle more than 17 translations with the TLang component.CodeProject

Refactoring to patterns. Yet another TDD example coded in Delphi

Long overdue here is my second article about Test Driven Development (TDD) in Delphi. This is a continuation of TDD in Delphi: The Basics, another post that I wrote a few months earlier. 

I would like to focus in a particular step within the TDD cycle: refactoring the code. Refactoring means optimizing, cleaning, shortening, beautifying, styling (put your own word here) the code without breaking the functionality; that is, without breaking your unit tests.

 
By having unit tests in place before refactoring, you guarantee that the changes to the code are safe. Refactoring can introduce bugs. To avoid those bugs you need your unit tests in place.

Refactoring can introduce something else: refactoring can introduce design patterns into your code. That means you don’t have to introduce the design patterns up-front, since your code can evolve from a “very rustic implementation” to a “pattern oriented implementation”. This is referred as “refactoring to patterns”. If you are interested on the topic, I advise you to read Refactoring To Patterns by Joshua Kerievsky.

I’ll take the chess game as the base to my example. For simplicity, I’ll just refer to a couple of pieces: the knight and the bishop. In this example, I will just focus in refactoring some code with unit tests already in place. A detailed walk-through for the TDD cycle can be found in my previous article, which is also based on the chess game.  

  
The code is easy enough to be self-explanatory: basically, there is a class hierarchy in which TPiece is the base class from which TKnight and TBishop derive. Take a quick look:

unit ChessGame;

interface

type

 TPiece = class
 private
   FX,
   FY: Byte;
 public
   constructor Create(aX, aY: Integer);
   function IsWithinBoard(aX, aY: Integer): Boolean;
 end;

 TBishop = class (TPiece)
 public
   function CanMoveTo(aX, aY: Byte): Boolean;
   function isValidMove(aX, aY: Byte): Boolean;
 end;

 TKnight = class(TPiece)
  public
    function CanMoveTo(aX, aY: Byte): Boolean;
    function isValidMove(aX, aY: Byte): Boolean;
 end;


implementation

{ TPiece }

constructor TPiece.Create(aX, aY: Integer);
begin
  inherited Create;
  // TODO: check that this assignment is valid.
  // Not now, ok? :-)
  FX:= aX;
  FY:= aY;
end;

function TPiece.IsWithinBoard(aX, aY: Integer): Boolean;
begin
  Result:= (aX > 0) and
           (aX < 9) and
           (aY > 0) and
           (aY < 9);
end;

{ TKnight }

function TKnight.isValidMove(aX, aY: Byte): Boolean;
var
  x_diff,
  y_diff: Integer;
begin
  x_diff:= abs(aX - FX) ;
  y_diff:= abs(aY - FY) ;

  Result:= ((x_diff = 2) and (y_diff = 1))
                         or
           ((y_diff = 2) and (x_diff = 1));
end;

function TKnight.CanMoveTo(aX, aY: Byte): Boolean;
begin
  Result:= IsWithinBoard(aX, aY) and
           IsValidMove(aX, aY);
end;

{ TBishop }

function TBishop.isValidMove(aX, aY: Byte): Boolean;
begin
  Result:= abs(aX - FX) = abs(aY - FY);
end;

function TBishop.CanMoveTo(aX, aY: Byte): Boolean;
begin
  Result:= IsWithinBoard(aX, aY) and
           IsValidMove(aX, aY);
end;

end. 


/////////////////////////////////////////////

 
unit TestChessGame;

interface

uses
  TestFramework, ChessGame;

type
  // Test methods for class TPiece
  TestTPiece = class(TTestCase)
  strict private
    FPiece: TPiece;
  public
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure TestIsWithinBoard;
  end;

  // Test methods for class TBishop
  TestTBishop = class(TTestCase)
  strict private
    FBishop: TBishop;
  public
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure TestCanMoveTo;
    procedure TestisValidMove;
  end;

  // Test methods for class TKnight
  TestTKnight = class(TTestCase)
  strict private
    FKnight: TKnight;
  public
    procedure SetUp; override;
    procedure TearDown; override;
  published
    procedure TestCanMoveTo;
    procedure TestisValidMove;
  end;

implementation

procedure TestTPiece.SetUp;
begin
  FPiece := TPiece.Create(4, 4);
end;

procedure TestTPiece.TearDown;
begin
  FPiece.Free;
  FPiece := nil;
end;

procedure TestTPiece.TestIsWithinBoard;
begin
  //Test trivial (normal) workflow
  Check(FPiece.IsWithinBoard(4, 4));

  //Tests boundaries
  Check(FPiece.IsWithinBoard(1, 1));
  Check(FPiece.IsWithinBoard(1, 8));
  Check(FPiece.IsWithinBoard(8, 1));
  Check(FPiece.IsWithinBoard(8, 8));

  //Test beyond the boundaries
  CheckFalse(FPiece.IsWithinBoard(3, 15));
  CheckFalse(FPiece.IsWithinBoard(3, -15));
  CheckFalse(FPiece.IsWithinBoard(15, 3));
  CheckFalse(FPiece.IsWithinBoard(15, 15));
  CheckFalse(FPiece.IsWithinBoard(15, -15));
  CheckFalse(FPiece.IsWithinBoard(-15, 3));
  CheckFalse(FPiece.IsWithinBoard(-15, 15));
  CheckFalse(FPiece.IsWithinBoard(-15, -15));
end;

procedure TestTBishop.SetUp;
begin
  FBishop := TBishop.Create(4, 4);
end;

procedure TestTBishop.TearDown;
begin
  FBishop.Free;
  FBishop := nil;
end;

procedure TestTBishop.TestCanMoveTo;
begin
  // Hey developer, indulge me here: believe
  // that I fully wrote the code for this
  // test already before writing anything else.
end;

procedure TestTBishop.TestisValidMove;
begin
  // Hey developer, indulge me here: believe
  // that I fully wrote the code for this
  // test already before writing anything else.
end;

procedure TestTKnight.SetUp;
begin
  FKnight := TKnight.Create(4, 4);
end;

procedure TestTKnight.TearDown;
begin
  FKnight.Free;
  FKnight := nil;
end;

procedure TestTKnight.TestCanMoveTo;
begin
  // Hey developer, indulge me here: believe
  // that I fully wrote the code for this
  // test already before writing anything else.
end;

procedure TestTKnight.TestisValidMove;
begin
  // Hey developer, indulge me here: believe
  // that I fully wrote the code for this
  // test already before writing anything else.
end;

initialization
  // Register any test cases with the test runner
  RegisterTest(TestTPiece.Suite);
  RegisterTest(TestTBishop.Suite);
  RegisterTest(TestTKnight.Suite);
end.

Note that the method CanMoveTo is duplicated in both TKnight  and TBishop; that’s not nice isn’t it? In order to fix this, we can pull-up the CanMoveTo method to the TPiece base class. Note this now: the CanMoveTo has now become a “template method”; because is a general algorithm applicable to all kind of chess pieces (TKnight ,TBishop, etc) .

This general algorithm has deferred some steps to be implemented in the subclasses; I mean, the isValidMove method is still coded in the subclasses. Isn’t this a beauty?  You have now refactored your code and when doing so, you have introduced the Template Method Design Pattern.

What’s even best, (don’t forget this because it is a key part): is that we can guarantee that our fancy refactoring didn’t break our pre-existing functionality. Why? Because we had unit tests in place written a long time ago. Writing unit test from the beginning gives a huge peace of mind to the developer :-) See the new refactored code below:

unit ChessGameRefactored;

interface

type

 TPiece = class
 private
   FX,
   FY: Byte;
 public
   constructor Create(aX, aY: Integer);
   function IsWithinBoard(aX, aY: Integer): Boolean;

   function CanMoveTo(aX, aY: Byte): Boolean;
   function isValidMove(aX, aY: Byte): Boolean; virtual; abstract;
 end;

 TBishop = class (TPiece)
 public
   function isValidMove(aX, aY: Byte): Boolean; override;
 end;

 TKnight = class(TPiece)
  public
    function isValidMove(aX, aY: Byte): Boolean; override;
 end;


implementation

{ TPiece }

constructor TPiece.Create(aX, aY: Integer);
begin
  inherited Create;
  // TODO: check that this assignment is valid.
  // Not now, ok? :-)
  FX:= aX;
  FY:= aY;
end;

function TPiece.IsWithinBoard(aX, aY: Integer): Boolean;
begin
  Result:= (aX > 0) and
           (aX < 9) and
           (aY > 0) and
           (aY < 9);
end;

function TPiece.CanMoveTo(aX, aY: Byte): Boolean;
begin
  Result:= IsWithinBoard(aX, aY) and
           IsValidMove(aX, aY);
end;

{ TKnight }

function TKnight.isValidMove(aX, aY: Byte): Boolean;
var
  x_diff,
  y_diff: Integer;
begin
  x_diff:= abs(aX - FX) ;
  y_diff:= abs(aY - FY) ;

  Result:= ((x_diff = 2) and (y_diff = 1))
                         or
           ((y_diff = 2) and (x_diff = 1));
end;

{ TBishop }

function TBishop.isValidMove(aX, aY: Byte): Boolean;
begin
  Result:= abs(aX - FX) = abs(aY - FY);
end;

end.

Conclusion, in addition to all the cool things of TDD there’s the possibility of refining your design not up-front, but when refactoring your code. Design patterns can be introduced at any time and we know that such introduction, if late, is not going to break our logic, because we have unit tests in place to prevent that from happening.

Some related reading below:

CodeProject

Check your Brick Platinum Card balance online

Note from the blog owner: This article might be outdated. I no longer have a Brick Platinum Card and I don’t know if what’s written in this article is still applicable today.

If you want to check your Brick Platinum Card balance over the Internet, the first thing you need to do is to register with the HSBC Online Customer Care.  For that just click here: Enrollment form. 

You will be redirected to a registration form in which you will have to type in some information like: 

• Account Number: The Brick Card number preceded with a zero to the left. For instance, if your Brick Card number is 0000 1234 5678 999, then you should type 0000 0123 4567 8999.
• Date of Birth: The Brick Platinum cardholder’s date of birth.
• Postal Code: The Brick Platinum cardholder’s postal code
• Loing ID and Password: A login and password for accessing the Online Customer Care.
• Two security questions: Just in case you forget your credentials in the future (login ID and password)
• Email Address: The Brick Platinum cardholder’s email address.
• Statement Delivery Preference: Whether you prefer to receive paper statements over regular mail or electronic statements over email. I particularly prefer the electronic statements.
• Email Alerts: Check this out if you want to receive email alerts when a payment has been received, when your payment is past due and when a new statement becomes available.

Finally, just click the Submit button at the end of the form. With that you'll have completed the registration process. Shortly after, you will receive an email from HSBC Retail Services welcoming you to the Online Customer Care.

If you want to check your Brick Platinum Card balance just login with your Login ID and Password in the Online Customer Care web portal.

Important: you cannot make online payments from within the Online Customer Care portal. You can only review your statements and balance. If you want to make online contributions to your Brick Platinum Card refer to the following article:

• Make payments to your Brick Platinum Card from the RBC Online Banking.