This is what I would do if I ever quit IT

/
  1. Hire out accessible office building balconies in Sydney, or park space
  2. Get a bunch of beach chairs
  3. Put up lots of beach umbrellas (for the sun and rain?)
  4. Hire out the beach chairs for lunch and nap afterwards
  • Pump up lots of beach balls for decoration (and to keep the kids busy)
  • Complementary sun block if they don't want to stay under the umbrella - though sun burns during lunch probably is great advertising.
  • Soothing beach sounds and music

Premium service

  • Martini, Coke, Tea
  • Clean beach towels for hire.
  • Alarm clock fitted to the previously mentioned beach chairs
  • Wind breaker walls - I imagine on top of office buildings in Sydney the wind will be quite big

The company will be called "5 Minutes to Beach Paradise"

The workplace Wiki

/

I'm a pretty strong believer that anything related to the development should go on the project Wiki.

Most people will agree on a few obvious topics:

  • Rules & standards
  • Design decisions (which typically turns into documentation of some sort)
  • Setting up the environment
  • Development processes

I prefer if the Wiki was more a 'place for everybody'.  Because the goal is that you want to drive your team to firstly Read the Wiki and then secondly to Update the Wiki. 

This means it needs topics that are less hardcore and has a more personal touch:

  • Bus / Train timetables - tips for getting home on time
  • Good restaurants near work - with Google/MSN Maps integration
  • I love this one - a Quotes page of who said what
  • Office Foosball / Table Tennis championship scores (and champions)
  • Team money jar summary
    • Breaking the build fine
    • Late/absent for scrum fine
    • Swear jar
    • Playing foosball / table tennis out of legal hours
    • Wearing jeans to work (usually this goes to some sort of charity though)

When someone on the team has a problem, what do they do

  1. Yell out help - can anyone help me?!
  2. Or they search the wiki

On most projects, #1 happens all the time, and #2 pretty much never happens.  Which is a pity.

Enterprise security policy

/

I received an email reminder from the client recently.

"Please don't plug external/personal laptops into the corporate network, this is against the enterprise security policy".

This blog is not a criticism of this security policy.  In fact, I tend to agree with the gist of this security policy.  It is always better to tell your less-computer-savvy users to avoid plugging in potential trouble into the network.

However, this does reminds me of a few things I wanted to rant about:

1. What about things like: External Hard Drives, USB sticks (and by extension, iPods or digital cameras)? 

They can transfer viruses too.  There was a news just this January where the USB digital picture frames many people got for $50 from Best Buy for their grand dad for Chrismas, and it was infecting their PCs.

http://www.news.com/8301-10789_3-9843574-57.html

Personally I think the network must be smart enough to detect virus troubles and drops the device from the network automatically, in a corporate environment, this goes for both "internal" as well as "external" machines.

Enterprise Security Policy by limiting who can or can't plug into the network is extremely naive, and possibly only give a false sense of security.  I sincerely hope there's a second line of defense on the network beyond just this policy.

2. Licences on development machines

For many years, I do work on a laptop with all the tools already installed, licensed and configured correctly.  So when I showed up at a new client/project I'm ready to go on day one.  Trouble is, many clients have a similar requirement in not allowing external machines to be used on the network - usually that's a set back for development time with lots of "develop on laptop", "copy over on USB stick", "test on client network"...  rinse and repeat.  This is a workable solution, but it is time consuming and still requires a basic setup on the client's development computer (at least VS.NET)

I thought there are a lot of parallels between a consultant vs say a plumber.

Plumbers shows up at the project with their own hammer.  The client doesn't have to buy a hammer for the plumber.

If a consultant shows up at the project with their own laptops.  The client shouldn't have to buy a new laptop (or the tools on it) for the consultant. 

What happens though, when the client won't let the plumber use the plumber's own hammers on his sink?  How can the plumber do his work?

Oh by the way we're still waiting for a few more licences for Resharper.

Ad-hoc data structuring with anonymous types

/

I've been experimenting with the anonymous types we have in C# 3.0, here's my latest creation:

var actions = new[]
{
new { Name = ActionSave, Type = KnownActionType.Save },
new { Name = ActionCopy, Type = KnownActionType.Copy },
new { Name = ActionNew, Type = KnownActionType.New },
    // snipped another 10 actions...
};
foreach (var action in actions)
{
Actions.Add(new Action(action.Name, action.Type));
}

C# happily compiled this for me, to my surprise.  And it works just as I expected it to.


image


Even intellisense picked it up properly.  See, strongly typed goodness.


The most amazing part I wasn't expecting is the C# compiler knowing that all the array items are the same anonymous type.  So it must have worked that bit out somewhere.


---


Prior to the amazing var variable, you would to do this with nasty looking nested object[] setup.  Like so:


(warning, untested code)

object actions = new object[]
{
new object[] { ActionSave, KnownActionType.Save },
new object[] { ActionCopy, KnownActionType.Copy },
new object[] { ActionNew, KnownActionType.New },
// snipped another 10 actions...
};
foreach (object action in actions)
{
// reall awful looking line next
    Actions.Add(new Action((string)action[0], (KnownActionType)action[1]));
}



There are heaps of things wrong with this old way:



  • No type safety - do your own casting

  • No array-size safety - index 0 or 1 may not exist

  • Boxing with KnownActionType

 


Yes.  I think I'm going to do nested anonymous types next.


jliu