Wednesday 21 January 2009

You can't make everyone happy, so don't try too hard


My personality type according to Myers Briggs, sees life as a series of constant battles. In the past that was the case. With age and a pinch of wisdom, that is no longer the trend.

Since this is my professional blog, I'd like to discuss the idea in the context of the workplace and your place in your organisation.

First thing, no one respects a yes man. That is a rule. Remember it.

Having an opinion is always good. You don't always have to voice it all the time but having one is essential. Shutting up is a skill. Learn it.

So how do you balance the need to speak out and at the right time close the gate between the your brain and your mouth?

I'm an extrovert and this is something I've constantly struggled with. Even after ten years of practice, there is no easy answer. I do however have a good handle on being myself and not spending too much time pleasing everyone. There is the saying that "you can not please all of the people, all of the time" and this is true but that doesn't mean you should quit and sit passively by, pretending this is not happening.

Here is how I think you can do this...

Count to Ten

Take your time to form your own opinions. Listen to others who you respect. Think about what you respect and like about their ethos and adopt those things as your own with your flavour. Through discussion, reading and contemplation, form your opinion about things conceptually before being in that actual situation. If a whole complex situation is too much then work with parts of situations.

Don't jump up and voice an opinion on something to the room if you have not thought through what is about to come out of your mouth.


Admit you are wrong, if you are

Often people voice an opinion and stick to it purely out of pride. If you do get it wrong then learn to admit you are wrong. There is nothing wrong with changing your opinion and telling people, if what you think now is different and improved. People will respect you if you are humble enough to admit you a wrong. Don't be too humble though.


Shut Up Already


When you have said your piece and articulated what you think then stop.

Do not make the mistake of saying something over and over again with the assumption that they aren't agreeing because they simply don't understand. Sometimes, people just don't agree with you, for whatever reason. Say what you have to say and then stop saying it.

Give the person you are talking to, time to digest what you have expressed.


Don't try to please only your Managers

One thing I have seen of late is people who state an opinion just to show their bosses that they agree. Managers are not idiots. Ok, some are but if they aren't then they see right through you. If your opinion is an exact parrot of your superiors then all that you will gain is a Mr Burns and not the respect you may crave.

Pleasing only those above you also wins you no friends. I've worked in environments where the rule was to "kiss up and kick down". There is only so far you can go with that war cry. Remember to consider how what you say will filter the views of those around you. All people matter. Not just the ones who decide your pay rise.


If you follow those four rules, you will find that you will be fine. Interpret them how you will but find your voice. Your own voice. Learn when to use and when not to.

Sunday 18 January 2009

Disabling Enter Causing Submit with jQuery


Recently I was asked to disable the submit event being triggered when the enter key is hit in a textbox input. This is for an ASP.NET MVC application. That means that including this in the site.master will allow identical behaviour across the entire web application.

When you hit enter, the focus will move to the next textbox.

There is also browser sensing code since Firefox needs a different event bound.


jQuery(document).ready(function($) {
   textboxes = $("input:text");

   if ($.browser.mozilla) {
      $(textboxes).keypress(checkForEnter);
   } else {
      $(textboxes).keydown(checkForEnter);
   }

   function checkForEnter(event) {
      if (event.keyCode == 13) {
         currentTextboxNumber = textboxes.index(this);

         if (textboxes[currentTextboxNumber + 1] != null) {
           nextTextbox = textboxes[currentTextboxNumber + 1];
           nextTextbox.select();
      }

         event.preventDefault();
         return false;
      }
   }
});

Friday 16 January 2009

Rabbit Hole Day


On Lewis Carrol's birthday, change your blogging style for a day.

"January 27th is the birthday of Lewis Carrol, author of ALICE'S ADVENTURES IN WONDERLAND. Alice fell down a rabbit hole into a place where everything had changed and none of the rules could be counted on to apply anymore. I say, let's do the same: January 27th, 2005 should be the First Annual LiveJournal Rabbit Hole Day. When you post on that Thursday, instead of the normal daily life and work and news and politics, write about the strange new world you have found yourself in for the day, with its strange new life and work and news and politics. Are your pets talking back at you now? Has your child suddenly grown to full adulthood? Does everyone at work think you're someone else now? Did Bush step down from the White House to become a pro-circuit tap-dancer? Did Zoroastrian missionaries show up on your doorstep with literature in 3-D? Have you been placed under house arrest by bizarre insectoid women wielding clubs made of lunchmeat?"

Sunday 11 January 2009

TDD Objective-C : Testing a Cocoa Framework Project

My intention is to write an iPhone application that does something simple, just so I can learn how they are designed, built, tested and deployed. The first step is to design the core functionality that the application will use. For that, I am creating a Cocoa Framework, which is a class library. This project will be test driven.

This describes how I created a Cocoa Framework project and the accompanying unit tests.

Operating System: Mac OSX 10.5.6
IDE: Xcode 3.1.2
Language: Objective-C


Creating a Cocoa Framework Project and Test Target

1. Start Xcode;
2. Go to File -> New Project... and create a new Cocoa Framework project named MyApp;
3. In this MyApp project under Targets, Add -> New Target... of the type Cocoa Unit Test Bundle called MyAppTests.

Making Your Target Dependent on the Main Executable

"When you configure your test target, you need to decide how you want that target to behave. The unit test bundles that come with Xcode can be integrated with your executable in one of two ways. One technique is to configure your test target as a separate entity that you build and run independent of your main executable. The other is to add dependencies to your target that automatically build your executable and run the tests each time you build." -- Xcode Help

I've chosen to run the tests every time I build the framework project, so I followed the steps on this Xcode Help page: To make your test target dependent on your framework project.

Here is a summary of how to make a Cocoa Unit Test Target dependent on your Cocoa Framework by establishing the dependency in your Xcode project:

1. Select your MyAppTests target;

2. Open an inspector for the target;

3. Select the General tab;

4. Add a dependency to the test target by clicking the + button and selecting the framework target MyApp from the list;

5. Select your Unit Test Bundle target;

6. Open an inspector for the target. To get an inspector on a project, just control-click on the test target and choose Get Info. The resulting window is referred to as an inspector. Typing Command-I does the same thing;

7. Set Build -> Linking ->Bundle Loader to $(BUILT_PRODUCTS_DIR)/MyApp.framework/MyApp;


Create a Test Class and a Failing Test

1. Control-click on the MyAppTests target and choose Add -> New File...;

2. Create a new Objective-C Test Case Class and name it MyAppFunctionalityTests. Two files will be created - MyAppFunctionalityTests.h (the declaration) and MyAppFunctionalityTests.m (the definition);

3. In MyAppFunctionalityTests.m, add a test method like this:


//
// MyAppFunctionalityTests .m
// MyApp
//
// Created by Damana Madden on 10/01/09.
// Copyright 2009 __MyCompanyName__. All rights reserved.
//

#import "
MyAppFunctionalityTests.h"


@implementation
MyAppFunctionalityTests

- (void) testThatThisIsTrueForThisCase
{
STAssertTrue(false, @"oops it didn't work.");
}
@end

4. To run the test, build the MyAppTests target. You will see this test fail.

Important: All tests must be prefixed with the word 'test' or they will not be picked up and run.

Thursday 8 January 2009

You should blog on Ada Lovelace Day


Join a bunch of us in pledging to write a blog post on Ada Lovelace Day about a woman in technology who you admire. It's happening on the 24th of March, 2009. You can even follow the goings-on through Twitter by following @FindingAda.

Acknowledge Me

Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...