More fun with Jasmine, Sinon and JavaScript

By Kenneth 'RabidDog' Clark at January 26, 2012 22:48
Filed Under: Code, JavaScript, Test Driven Development

Once again delving into front end JavaScript development (which I might add is not all that fun Sad smile) I have started to gather a few tid bits on good sites to have a look at. Before I post that I want to make a few points on the whole JavaScript world and why I find it to be so annoying to work with.

 

A few general trends I have noticed in the web development world is that the idea of using solid architectural practises is often undermined by the need for fancy front end user experiences. This leads to a very dangerous situation were we sacrifice the integrity of backend services to facilitate fancy front end experiences. This being said, I must admit, that I do like the trend developing in the JavaScript development community to implement test cases. Lets hope this trend continues!

 

The one thing that really, and I mean REALLY, frustrates me around the JavaScript language is the lack of structure. While this might be a plus for some people, it is highly frustrating me. Why has the ECMA specification not allowed for a simple import function? All other major platforms and languages allow you to import reference files. Yes, I know you can merge them, minify them and then wrap them in cheese but why should you have to? I know that this decreases HTTP traffic in certain instances but it is a pain in the rectum to develop for. Some sort of import directive is long over due in JavaScript. Why should my HTML pages contain script reference tags? This doesn’t fit in with the view knowing nothing about the application layer. With unobtrusive JavaScript becoming big this is a serious flaw in the design. I know there are ways to get round all this but all mechanism involving referencing files is contrived.

 

That single word sums up my feelings on JavaScript development, it is contrived. That an the lack of support by any major IDEs is also painful. Yes, you should know how to do this without the help of an IDE but that is like telling a dentist to use a handle drill because an electric drill is too helpful.

 

The lack of standards regarding engineering practises in JavaScript, the custom JavaScript engines found in all major browsers and a few other things still make JavaScript development a “dark art”. I take my hat off to good, productive JavaScript developers, you guys truly have a gift. I am also left wondering who long it will be before JavaScript grows up.

 

Anyways if you looking to get into the whole JavaScript TDD and MVC boat I would highly recommend that you check out a fantastic set of write ups by Jim Newbery over at tinnedfruit.com.

 

http://tinnedfruit.com/2011/03/03/testing-backbone-apps-with-jasmine-sinon.html

 

Well here is to JavaScript growing up!

Time management and the call of procrastination

By Kenneth 'RabidDog' Clark at December 29, 2011 13:23
Filed Under: Work, Personal

Today I was feeling all flustered and had no idea why. It felt like I had stacks of work to do and didn’t know where to begin. Then half way trying to do something I felt like I had been working for hours on the same thing.

 

I took a step back and remembered a technique our scrum master has taught us called the Pomodoro technique. Yes I know it is old but I thought I would try it again. Now like any true geek I had to find an application that could do the timing (I know you can use any clock but I wanted a history of tasks done).

 

So I found a really cool Adobe Air application which has been developed free. http://code.google.com/p/pomodairo/. If you are one of the unfortunate Apple Mac users Winking smile a friend of mine uses http://pomodoro.ugolandini.com/

 

 

If you interested in reading more about the technic have a glance at http://www.pomodorotechnique.com/

 

Happy days!

Windows 7 Desktop helpers

By Kenneth 'RabidDog' Clark at December 15, 2011 11:48
Filed Under: Open Source, Personal

This morning I went on a mission to organise my desktop icons. I usually try and sort them logically but it appears that in my old age and perhaps an element of laziness is causing my desktop to become, shall we say, uncontrollable?

 

Fiddling with Ubuntu last night I noticed how the unity interface groups icons for you. So I wondered if anything like that existed for windows and guess what, something very similar does indeed exist. Check out http://www.stardock.com/products/fences/ and smile. My desktop went from a cluttered in cohesive, speed valuable time isolating shortcuts and links to this:

 

mydesktop

 

 

Nice and neat, structured, just the way I like it. This is a custom layout and you too can now have this power!

 

Then comes the inevitable question of multiple desktops. Well again, the only decent on I have found is a product called Dexpot which can be found here http://dexpot.de/index.php?lang=en. Still absurd how Microsoft hasn’t built this into their OS.

TOGAF Level 1 Examination

By Kenneth 'RabidDog' Clark at December 14, 2011 22:31
Filed Under: Architecture, Work

 

It has been a long time coming. I put it off for way to long and then the expiration of the exam voucher started creeping up so a few weeks ago I decided to book the exam date and get on with it.

 

I will not lie, the stress levels were high. I found a few resources regarding revision and the best ways to prepare for the exam. I also found a significant number of practices test kindly provided by people also studying for the exam.

 

So I decided to adopt my own study still of notes and testing myself. The day before the exam my office was kind enough to give me the day off and I spent it behind the books. After a full 9 hours of studying (yes with breaks between) I went to Systema to blow off a bit of steam. I then arrived home, did some more revision, hit the XBox 360 for an hour and finished the revision.

 

This morning I headed out early and arrived at the exam center 40 minutes early. This allowed me another look at my revision cheat sheet before doing the exam.

 

Going upstairs I was greeted with some nervous faces also writing their exams. After waiting for everyone to arrive we sat down and began the process of registering and opening the test which comprised of 40 multiple choice questions.

 

I started the test and 15 minutes later was finished. Not to brag but I figured that if I didn’t know it, reading the questions over and over wasn’t going to help. So I answered the questions and waited for the results. by God’s grace alone I passed!

 

So now on to level 2!

Ubuntu 11.10 updgrade black screen

By Kenneth 'RabidDog' Clark at November 29, 2011 19:53
Filed Under: Linux

If you decided you wanted to upgrade your Ubuntu you might end up in a situation where you get a black screen and nothing after.

 

After search the net I found this article

 

http://uksysadmin.wordpress.com/2011/10/14/upgrade-to-ubuntu-11-10-problem-waiting-for-network-configuration-then-black-screen-solution/

 

Which basically stipulates you do this

1.Hit Ctrl+Alt+F1 at the blank screen to get you to a non-X terminal (tty1)
2.Login in with your username and password
3.Change to root with: sudo -i and enter your password
4.mkdir -p /run /run/lock
5.rm -rf /var/run /var/lock
6.ln -s /run /var
7.ln -s /run/lock /var
8.reboot

 

Problem with this is that you can’t get the tty1 so boot into single user mode and follow the instructions from point 2 and it will be up and running again. Thanks to the initial author.

Google+ C# client

By Kenneth 'RabidDog' Clark at November 10, 2011 23:57
Filed Under: C#, Code, Web

After the hackathon, I noticed that the .NET realm is not covered by the current Google+ clients. This prompted me to write a client to facilitate the current APIs. It is strongly typed, easy to use and pretty handy. I have included basic tests to describe it’s usage. Currently it only supports the API Key. Next is the paging and OAuth 2. Check it out if you get a chance https://github.com/RabidDog/GooglePlusNet

 

Ciao

C# HttpWebRequest and HttpWebResponse

By Kenneth 'RabidDog' Clark at November 09, 2011 13:34
Filed Under: C#, Code, Web

 

Another quick post on doing a simple http request and processing the response. Working on the Google+ client for C# and due to the fact the API is REST based, I need to be able to make an HTTP request and process the HTTP response. When looking at the client I am implementing I decided to wrap the whole round trip into a single operation. Here is the results of my labor.

 

First let me give you the class definition:

 

using System;
using System.Diagnostics;
using System.IO;
using System.Net;
using System.Text;

namespace CodeShark.Communication
{
    class HttpProcessing
    {
        public static String ProcessRequest(string requestUrl)
        {
            // This will be the raw string response
            String output;

            var httpWebRequest = (HttpWebRequest)WebRequest.Create(requestUrl);
            httpWebRequest.MaximumAutomaticRedirections = 4;
            httpWebRequest.MaximumResponseHeadersLength = 4;

            httpWebRequest.Credentials = CredentialCache.DefaultCredentials;

            using (var httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse())
            {

                Debug.WriteLine("Content length is {0}", httpWebResponse.ContentLength);
                Debug.WriteLine("Content type is {0}", httpWebResponse.ContentType);

                using (var responseStream = httpWebResponse.GetResponseStream())
                {
                    if(responseStream == null)
                        throw new InvalidDataException("Could not retrieve any data from the URL " + requestUrl);


                    var readStream = new StreamReader(responseStream, Encoding.UTF8);

                    output = readStream.ReadToEnd();

                    Debug.WriteLine("Response stream received.");
                    Debug.WriteLine(output);
                }
            }

            return output;
        }
    }
}
Now for a quick explanation. We create the HTTP request using the URL supplied. Then we set some limits on the bouncing the HTTP request can do and set the credentials. The request is fired off when we call the httpWebRequest.GetResponse(). Once we have the HttpWebResponse we need to read the response stream. We get the response stream by calling httpWebResponse.GetResponseStream(). Using this stream you can read the response (presumably text). Pretty simple, nothing to fancy but something we do quiet often without even knowing it.

Build now, make money later

By Kenneth 'RabidDog' Clark at November 09, 2011 10:31
Filed Under: Code, Work

After reading an interesting piece of market research around the general idea and reasons for building mobile applications, everyone always pointed out the fact that they wanted to make money off their applications, so I thought I would make an observation about it.

 

Firstly, money is needed. We need it to pay the bills, we need it survive, to remain clothed and to have a roof over our heads. There is definitely a very real need for money, I am not denying this. However if we look at successful online software products, very few of them first set out to make money. Their first goal was to attract a user base.

 

At the recent G|South Africa (Google South Africa) days, the key note speaker went a little into the methods that Google uses when building applications. He pointed out that the when presenting an idea, the last thing Google wants to hear is how you going to make money off it. The first thing they tell you to do is to get the users!

 

Why is this important? Well it is pretty simple really. If you don’t have people using your application, you won’t ever make money off it. If people cannot use the application without risk they won’t try it. Especially at the rate that applications are being released and the substandard quality of the product. I am incline to believe that the Apple App store is doing better just by virtue of the fact that people know they have quiet a rigorous quality assurance procedure.

 

So my advice to you is pretty much the same as Google’s. Build the application first. Release it for free, get the user base, then and only then try to figure out how to make money off it.

 

Just another point on the inability to monetize applications in South Africa through the Android Market. South Africa has some of the nastiest monetary policies in the world. Look how long it took us to get PayPal. So it is not because Google is not interested in South Africa, it is just incredible difficult to establish the mechanisms in South Africa.

A fool doesn’t learn from his mistakes, a smart man learns from his mistakes and …

By Kenneth 'RabidDog' Clark at November 08, 2011 21:08
Filed Under: Work

a wise man learns from the mistakes of others!

 

This is a list of things that I have learnt in my stint in the IT industry. I thought that everyone knew these things but as is often the case we take for granted the knowledge we have gained via experience.

 

Everyone knows better than you.

This might sound sarcastic but it is not. When you come fresh out of your studies you figure that University or College has prepared you for everything. Every eventuality, every possible problem until you walk into your first job. What you fail to realise is that while studying you have been given the perfect environment to build programs. You are the only person responsible for your projects. Things can be configured and set up as you please (unless the  assignment stipulates otherwise). Finally you never have to worry about the bottom line. By the bottom line I mean money. Sure you have to worry about marks but see how confident you are to make tough decisions that affect a companies bottom line. Listen to your peers, interact with them, make suggestions but be prepared to be corrected. You might very well have a good idea but it doesn’t fit the business problem. On the other hand you might have an idea that solves the problem. Business software development is a team effort. Be part of the team.

 

Learn when to keep quiet.

  1. Your opinion counts. Really it does. When you express it is a different story. There are times to speak and times to keep quiet. If you are not sure whether it is time to speak or time to be quiet then it is probably best to be quiet. Don’t be afraid to speak though but before you speak, formulate your questions. Think about what you want to say and what you are trying to get answered. When you do speak make it concise and to the point. Leave no room for ambiguity. Don’t ramble or speak for the sake of speaking. Nothing turns people of your statement, no matter how smart it is, quick than rambling or disjointed statements. I often remind myself “Light travels quicker than sound. That is why people appear intelligent until they open their mouths”.

 

Don’t get precious about your project.

This does not mean that you are to take no pride in your work! What this does mean however, is don’t get so attached to what you have done that you refuse to improve it because it wasn’t your idea. Perfection is obtained through iteration. Nothing screams insecurity more than an individual who gets defensive about their code. Never forget that a software project is a strange beast, it can turn at the drop of a hat, hence all the agile methodologies now prevailing. These are not fancy management techniques but techniques put in place to help negate the dynamic nature of business and the rigged nature of software development. If you believe you are right, converse with the individual claiming there is a better way to do it. Perhaps they might educate or their reasoning might illuminate and angle you never thought of. Then again, you might very well educate the individual point what they believe to be a problem out.

 

Be professional.

Ok seriously. We have been potty trained. All of us. We have all figure we were old enough to rule the world and we most definitely thought we knew everything at some stage or another. That being said, why is it that when we first walk into the work place we become a bunch of snivelling cry babies? If faced with a difficult situation, evaluate it. Don’t throw a temper tantrum when you don’t get your way. Always remember that your employer is your client. You are a service provider, nothing more, nothing less. Do you job and do it well. If faced with a difficult situation tackle it. This is not only in the code base but also interpersonal relationships. If you have a problem with a fellow employee resolve it amicably. You guys, after all, are going to be spending a significant amount of time together. Deliver what you commit to delivering.

 

Be disciplined with your work. Check it before you submit it. Proof read the document before you submit it. Take pride in your project. The reason I said project as opposed to work is because their is nothing stopping you from continually checking the quality of the project. If you are a more experienced developer and you identify issues don’t just bounce it back to the developer. Take them time to help them fix. I have noticed that a significant amount of errors are due to a lack of understanding as opposed to laziness or stupidity. In this dog eat do world we have created we forget that we should carry the weak. Enable someone not to make the same mistake again, actively promote developer growth and maturing as opposed to bullying. The sooner they can do your job, the sooner your work load can be lightened.

 

You going to have to wipe your own bum. 

I cannot tell you how often I have seen (and yes been one of them) guys sitting in their office fuming at the fact that they can’t do things better because their managers won’t let them. Remember that your working environment and your perception of it, rests completely in your court. If there is something you want changed and it doesn’t go against company regulations then change it. If you think there is something that will fix your development cycles and the risk is minimal to the project, change it. If there is a piece of code that you know can be better, or a piece of refactoring that would remove duplication without bubbling significant issues up the code chain then do it. Don’t expect your managers to hold your hands with everything. Be proactive. Identify issues and figure out how to solve them. There is nothing worse than someone that continually points out problems without a way to fix them. If you put yourself out there and make yourself noticed people will take notice. Don’t sit back and wait for things to happen. If you can improve things then do it. Just don’t step on toes or hurt people doing it. Hurting someone does not imply that you should not be honest with them. It implies that you should not be dishonest with them.

 

Fill the gaps you identify.

If you notice a gap, fill it. If you can assume a little more responsibility for the benefit of the team then do it. If the leadership needs help then provide it. Don’t just do what you told, do what you see is not getting done. Before you get all mad just take a minute and think about it. This statements does not mean working yourself to the bone. It means that if you can take up a little slack then do it.

 

It is a team effort.

As software development has matured so have it’s processes and methodologies. That being said, a significant number of old stable teams have been using a form of Agile before it became a catch phrase. Old stable teams have worked past all their teething issues. They have identified the optimal communication mechanism that they should use when addressing their team mates. They understand (you need to understand this so read it again if you have to) that the delivery of a section of the project is not the goal. It doesn’t matter how fantastic their piece of code is. If the project fails then the team has failed. Period. If your team does not produce the end result you have failed. Yes, don’t argue, no excuse, I don’t want to hear you did everything you were supposed to, you failed. End of story.

 

Be low maintenance.

By this I mean that you should be fluid. Adapt to your environments and situations. Look for ways to best fit in. Be a problem solver. Even if your solution is the best one, try and help. Refer to the first point though. There are ways to communicate your ideas without screaming and making a fuss. Don’t whine about things that annoy you, fix them or suggest ways to fix them.

 

Business is right.

Yes it is. Sure they know nothing technically but I got bad news for you. If business doesn’t make money, neither do you. As opposed to fighting business become an ally. Facilitate their requirements, even if they seem absurd. This doesn’t mean that they should dictate implementations or technology spaces. This just means that if they request a change then best we perform it. If they request a feature then best we create it. Business is an extremely competitive industry. Being first to market means a competitive edge. The more money business makes, the longer we get to keep our jobs. Lets work with them. The more flexible we are, I have seen this, the more flexible and understanding business becomes.

 

Get to know the network engineers.

This is something I learned very quickly because I used to be one of those guys. People, for some reason, see network and infrastructure engineers as the plumbers of the IT world. This could not be further from the truth. Remember that the machine you are working on, the telephone you use, the server you hosting on, the network transmitting all your data is because of these guys. If anything ever goes wrong you going to need them to help you fix it. If you are certain there is an issue with the network then take as much data as you can to the network guys so they can diagnose the problem quicker. It is absolutely incredible how busy they can become when you need them if you have been off towards them. I also find that network engineers are generally the funniest and comedic of any division in the IT industry. If you ever need a laugh, go chat to your network engineers.

 

I am sure there are more but this is all I can think of at this time. The reason I raised this is due to a discussion we had in the office today. If you want top excel then don’t be afraid to stand up and be counted. Fail fast, that way you can move onto the next thing. I have noticed that companies promote initiative even if the answer is not 100% correct. Believe in what you are saying, if you don’t then don’t put it out there. If you put your ideas out there expect them to get cut off. Be prepared to defend them but never defend them subjectively or emotional. Always back your statements up with facts or experience. If your idea doesn’t get accepted then don’t get down or think no one loves you. One day, grasshopper, you will have an idea that everyone loves.

 

If you don’t agree with the points above you will one day Winking smile As I always say, I am always right, most of the time.

C# XML and Binary Serialization

By Kenneth 'RabidDog' Clark at November 08, 2011 17:55
Filed Under: C#, Code, Architecture

Recently was working on a small project that required me to store a collection of objects. So I figured I would refresh my knowledge of the serialization available in C#.

 

First I had a look at the XmlSerializer. First you need to define an object to serialize.

 

[Serializable, XmlRoot(Namespace = "http://rabiddog.co.za")]
public class Dog
{
    public Dog(String name, int age)
    {
        this.Name = name;
        this.Age = age;
    }

    public string Name { get; set; }
    public int Age { get; set; }

    //The XmlSerializer requires a default Constructor
    public Dog() { }
}

 

Now that we have the class defined, lets create a collection and serialize that collection to an XML file. Create a console application and then add the following method

 

private static void XmlSerialize()
{
    Dog dog1 = new Dog("Charlie", 42);
    Dog dog2 = new Dog("Jim", 32);


    List<Dog> myDogs = new List<Dog>{dog1, dog2};

    using (Stream stream = new FileStream("MyDogs.xml", FileMode.Create, FileAccess.Write, FileShare.None))
    {
        XmlSerializer xmlSerializer = new XmlSerializer(typeof(List<Dog>), new Type[]{typeof(Dog)});
        xmlSerializer.Serialize(stream, myDogs);
    }
}

 

Then call the method from the Main() function, let it run and you should end up with a file called MyDogs.xml in the debug/bin directory. The file should look something like this

<?xml version="1.0"?>
<ArrayOfDog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Dog>
    <Name xmlns="http://rabiddog.co.za">Charlie</Name>
    <Age xmlns="http://rabiddog.co.za">42</Age>
  </Dog>
  <Dog>
    <Name xmlns="http://rabiddog.co.za">Jim</Name>
    <Age xmlns="http://rabiddog.co.za">32</Age>
  </Dog>
</ArrayOfDog>
 

Well that was pretty simple. All we had to do was add the [Serializable] annotation to the class and then create an instance of XmlSerializer to write it to. You could also set the properties to be attributes by decorating them with the [XmlAttribute] annotation.

 

Cool, lets move onto the binary serialization shall we? Using the same Dog class we are going to serialize this down to a binary file.

 

We do that by changing the serializer we are using to the BinaryFormatter:

private static void BinarySerialize()
{
    Dog dog1 = new Dog("Charlie", 42);
    Dog dog2 = new Dog("Jim", 32);


    List<Dog> myDogs = new List<Dog> { dog1, dog2 };

    BinaryFormatter formatter = new BinaryFormatter();

    using (Stream stream = new FileStream("MyDogs.dat", FileMode.Create, FileAccess.Write, FileShare.None))
    {
        
        formatter.Serialize(stream, myDogs);
    }
}

 

Don’t forget to call this method from the Main method. This should produce a MyDogs.dat file in the debug/bin directory. Happy days but there is just one problem. What good is it serializing it if we can deserialize it?

 

First lets deserialize our XML like so

private static void XmlDeserialize()
{

    using (Stream stream = new FileStream("MyDogs.xml", FileMode.Open, FileAccess.Read))
    {
        XmlSerializer xmlSerializer = new XmlSerializer(typeof(List<Dog>), new Type[] { typeof(Dog) });
        List<Dog> myDogs = (List<Dog>)xmlSerializer.Deserialize(stream);

        foreach(Dog dog in myDogs)
        {
            Console.WriteLine("My Dog {0} is {1} years old", dog.Name, dog.Age);
        }
    }
}

 

And the method to deserialize our binary file would be something along the lines of

private static void BinaryDeserialize()
{
    BinaryFormatter formatter = new BinaryFormatter();
    using (Stream stream = new FileStream("MyDogs.dat", FileMode.Open, FileAccess.Read))
    {
        List<Dog> myDogs = (List<Dog>)formatter.Deserialize(stream);

        foreach (Dog dog in myDogs)
        {
            Console.WriteLine("My Dog {0} is {1} years old", dog.Name, dog.Age);
        }
    }
}

 

It thought this was a particularly neat way of storing data on application close. Serialize your object graphs and exit. When you start the application deserialize back to the original state and off you go. No over head of setting up database connections or any other mechanisms of persistence.

 

Yes I know it is old school but is facilitates the requirements for the application I am using. The reason I raise it is because we far to often get caught up in distributed application mentality when something simple like this would do just fine! Below is the enter class file. I hope some one found this useful Smile

 

using System;
using System.Collections.Generic;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Xml.Serialization;

namespace RabidDog
{
    class Program
    {

        private static void XmlSerialize()
        {
            Dog dog1 = new Dog("Charlie", 42);
            Dog dog2 = new Dog("Jim", 32);


            List<Dog> myDogs = new List<Dog>{dog1, dog2};

            using (Stream stream = new FileStream("MyDogs.xml", FileMode.Create, FileAccess.Write, FileShare.None))
            {
                XmlSerializer xmlSerializer = new XmlSerializer(typeof(List<Dog>), new Type[]{typeof(Dog)});
                xmlSerializer.Serialize(stream, myDogs);
            }
        }

        private static void XmlDeserialize()
        {

            using (Stream stream = new FileStream("MyDogs.xml", FileMode.Open, FileAccess.Read))
            {
                XmlSerializer xmlSerializer = new XmlSerializer(typeof(List<Dog>), new Type[] { typeof(Dog) });
                List<Dog> myDogs = (List<Dog>)xmlSerializer.Deserialize(stream);

                foreach(Dog dog in myDogs)
                {
                    Console.WriteLine("My Dog {0} is {1} years old", dog.Name, dog.Age);
                }
            }
        }


        private static void BinarySerialize()
        {
            Dog dog1 = new Dog("Charlie", 42);
            Dog dog2 = new Dog("Jim", 32);


            List<Dog> myDogs = new List<Dog> { dog1, dog2 };

            BinaryFormatter formatter = new BinaryFormatter();

            using (Stream stream = new FileStream("MyDogs.dat", FileMode.Create, FileAccess.Write, FileShare.None))
            {
                
                formatter.Serialize(stream, myDogs);
            }
        }

        private static void BinaryDeserialize()
        {
            BinaryFormatter formatter = new BinaryFormatter();
            using (Stream stream = new FileStream("MyDogs.dat", FileMode.Open, FileAccess.Read))
            {
                List<Dog> myDogs = (List<Dog>)formatter.Deserialize(stream);

                foreach (Dog dog in myDogs)
                {
                    Console.WriteLine("My Dog {0} is {1} years old", dog.Name, dog.Age);
                }
            }
        }

        static void Main(string[] args)
        {
            XmlSerialize();
            BinarySerialize();
            XmlDeserialize();
            BinaryDeserialize();
        }
    }

    [Serializable, XmlRoot(Namespace = "http://rabiddog.co.za")]
    public class Dog
    {
        public Dog(String name, int age)
        {
            this.Name = name;
            this.Age = age;
        }

        public string Name { get; set; }
        public int Age { get; set; }

        //The XmlSerializer requires a default Constructor
        public Dog() { }
    }
}



I am South African. Always have been always will be. I love my country. I love my wife and two children.


I also really enjoy solving problems. I currently work as a Software Architect exploring new solutions for business problems. Having been round the block a few times I enjoy showing new developers how best to solve problems, how to find answers and how to approach solution development.


In my spare time I enjoy riding my super bike, training in Systema and horsing around with my family.


Month List

Visitors

Twitter Feed

12. January 23:34
@Annaling horrific. People like that should face sever punishment. Unless of course they tried to find the cat :(

12. January 08:28
@Annaling to fix cat problems u need a dog :)

9. January 15:34
@UnexpectedPippa my boy is 2. They rock! My daughter, son and myself have endless fun with them!

9. January 15:23
@UnexpectedPippa my son has a bucket of them :)