This kitchen needs a better synch

"It's always a distribution problem." And you can quote me on that ...

We are going more and more towards "Web 2.0" applications. This is compounding a problem. It was already hard enough to find applications that would permit data to be synched between multiple copies and locations. Road-warriors have had some success with synchronizing their desktops and their PDA. But our needs are becoming more complex. We need to be be as productive on the road as when we are sitting in our main office, and if T-Mobile would have you believe that Wifi is ubiquitous, the reality is not even close. I won't even discuss working on the plane or while waiting 4 hours at the Passport Office (guess where I am right now ...) Even if the planet was plastered with Wifi antennas, it would still be necessary to be off the 'net once in a while.

Road-warriors use their laptop a lot and being able to synch todo, calendars, contacts, and general notes, as been possible for Outlook users, and now OSX users via .Mac (which is total crap, IMHO). iSync is definitely a good idea, but falls a little short to synch things like RSS readers, outlines (think OmniOutliner), general folders, source code versions, iTunes libraries, blog drafts, multimedia libraries (think Delicious), IRC logs, keychains, and such.

Now compounding this is the fact that, more and more, applications must be accessed via the Internet; and that's the front-end itself... If Microsoft has its way, it will even be impossible to *use* your computer unless it reports back to Redmond's mothership to "validate" its license.

I cannot understand why no synchronization standards exist. I guess it is too complex of a problem.
Each app needs to document what it stores and how. It has to be in a structure that can take being modified by third party apps, say XML. The structure has to have time-stamps and IDs linked at the atomic level. Then we have to create a language in which we can express a structure to scan for and a sub-structure to modify in order to synch two repositories. Preferably, the app must support re-scanning of its databases or configuration/status files.

These are problems that have been solved for Calendar apps for the longest time. Now a calendaring app cannot survive unless it offers some form of iCal support and synchronization. Developers selling commercial-ware and share-ware need to realize that they can double their sales by integrating proper synchronization capabilities in their save formats. If your app can be used both on a laptop and a workstation, then this applies.

Using a corporate Wiki

One of things that has always nagged at me was that departments always had individuals that would horde information; the "kingdom builders". These would be particularly nasty in the Operations areas. Also, if you did hold of their official documents, and you found a problem with the doc, or the system had drifted away from the doc, it was close to impossible to change it yourself.

The epitome of this is the Portal. Portals were all the rage about 3 years ago. Corporate internal portals for the employees were seen as a way to get information to the employees of the company. In reality, it just gave a way for the executives and HR to slam corporate rules at the employees. At the very best, Portals were nice attempts at corporate memory but ended up being an ivory tower of management-approved sanitized libraries. They were a feel-good thing for management, but ended up being close to useless for workers to easily distribute information to other workers.

Enter the Wiki.

Wikis are great to partially address these situations. Documents written in the Wiki can be changed by anyone in the company, in real time, if any discrepancies are apparent. Anyone can create a new document/link. It is a great way to distribute knowledge inside the company, and a great way to maintain corporate memory. I believe that all Intranets should have a Wiki installed. If they don't get immediate traction, leave it there, it will grow into its own in time. At the very least, you will find that Operations will use it almost immediately to store Standard Operating Procedures docs (SOPs).

We use PMWiki. It is based on PHP, and uses rather simplistic Wiki formatting tags. It has some quirks that might force us to look at something else. We might code our own using TurboGears at some point.

How are we hiring ?

Having a minor in Human Resources, I have scathing opinions of typical hiring techniques in the high-tech sectors. I have spent most of my career in the Silicon Valleys (north and south) and most of that as a consultant. I have also been a founder of a start-up which went on to be listed on the stock exchange. The usual hiring scenario is this:

• An HR person asks the manager what he/she are looking for, including the skill sets and experience required. The manager usually has no specific clue and will list all the small stuff that might *perhaps* apply. Like "Must know Perl" if the department has a few .pl files in their day to day operations.


• The HR person takes a look at the title of the position (like "Senior Programmer") and the list of knowledge and skills that the manager listed and then proceeds to apply some weird algorithm that has been given to them by their grandmothers or something.... So now, the "Must know Perl" becomes "Must have 7 years of Perl programming experience", or god forbid "Must have 10 years experience in Web 2.0".... I was constantly floored when I was asked to have 7 years experience in C# when it had only been out for 5.


• An ad is put in a newspaper, and on websites like Monster.com


• A gazillion resumes are received. 500 more trees die. Spam is mistaken as legit applications.


• The HR person has to apply a "scoring system" to all of these to decide which ones make the first round. This is where the HR person feels they are the "value added" in the system. So, our "7 years of Perl" becomes 14 points, and our "15 years of Web 2.0" becomes 30 points; even when it should be obvious that the candidate lied through his teeth on that last one...


• The top scoring 10 or 20 candidates are kept and their resumes are forwarded to the manager.


• The manager reviews the resumes and apply their own scoring system and keep about 5 to 10 candidates. They report these to the HR person who schedule the interviews.


• The candidates come in and meet the HR person for a quick 10 mins interview and then meet the manager for an extended interview. Fun is had by all. The manager is looking for a "team player" or some other soft skill. The candidate is encouraged to spew buzzwords at the manager. If the candidate is really unlucky, they will get to be interviewed *very briefly* by one of the department's techies.


• The manager asks the candidate what salary they are expecting. They candidate replies that he/she is very flexible, and what did the manager have in mind ? This continues on back and forth until someone says a number. The first one to say a number loses.


• The candidates are all thanked and the nephew of a VP is hired.


• OR, if the VP has no relatives to hire: The candidate with the lowest salary requirement is hired.

I wish I was joking.

We are in 2006. This procedure is total crud. We are in the information age, and hiring is still in the dark-ages. Very few managers know how to really describe their departments needs, and only a handful of companies actually test the skill sets required. Those that *do* test, typically do so at the last round of qualifications. They might as well hire randomly...

We should be testing our requirements first. Have a questionnaire on the Web and demand that applicants answer before submitting their resumes. We must have a way for the candidate to demonstrate their skill upfront, with their application. I am not proposing a boilerplate solution here, just that receiving even one resume must be accompanied with some form of skill demonstration. It is up to a real HR department to show the proper initiative and craftiness necessary to cull the crud from the cream. Anyone can lie on a resume. I find they are totally useless as a hiring mechanism. Also, a lot of candidates do not have the writing skills necessary to show well on a piece of paper.

Let the techies of the department review the skills answers. If the candidates had to code a certain function as part of their application, let the techies review each of the code bits.

When the techs have a few answers that they like, HR should contact about 6 candidates at a time and bring them in for interviews *at the same time*. When they come in, they are given a piece of paper and asked what salary they are expecting. That information is to be kept hidden during the "group" interview.

The group interview can take a few forms, depending on what soft skill-set is necessary. You will be asking your candidates to participate in a game. The game will try to bring out a skill for the interviewers to assess. The department manager is usually the one to oversee the group interviews. Here are a few examples:

• Create two identical Lego sculpture. Same colors, same blocks, same positions. Make it *really* complex. Now break apart one of them and put the pieces in a box. Take the other sculpture and put it behind a blind. Designate one candidate as the "describer". He/she gets to describe the sculpture to the rest of the candidates. The rest of the candidates must work together to duplicate the sculpture that is being described to them. At any time, a candidate may ask to take the place of the describer. Watch the sparks fly.
  
• Have a list of technical questions, and ask the group for answers. The first one who raise their hands gets to answer. Don't keep score. Just watch if the candidates are confident enough in their knowledge to show little stress during the questions.
  
• Have the candidates split into 3 teams of 2. Explain a problem to which they must design a solution. Have them write on a piece of paper their name and their answer. Have them give in their individual answers. Then get them to discuss and debate the design with their partner. Have the team give you the team design. Compare that design with the individual answers. See which candidate was able to compromise best.
  
• Make up your own
  

The HR person gives the salary requirement answers to the manager after the manager has picked 2 or 3 candidates.

If you still must know how the candidates fit with the rest of the team, bring the team and the candidates out to lunch together. Then ask the team what they think.

Summary

1. Test the skills first.
2. Involve the co-workers of the position as soon as possible in the culling process.
3. Interview in groups, not as individuals. This way you see how the candidates react under real stress.
4. Salary is not part of the main interview items.
5. Team interaction should be tested on a social setting.

Even will all this, I must admit that the chances are that you will still be forced to hire the VP's nephew...

Trip to San Jose

So, off I got to XenSource certification. A trip to San Jose is not strategic for us at this time, but we really want to get in bed with XenSource. I *have* to meet with their executives and get their technical certification if we want to play ball together.

Here's a rundown of the trip:

Customs and security were routine.

The flight to Chicago was too heavy so the airline had to find 4 volunteers to get off the plane before takeoff. Only two people said "thank you" to the volunteers as they were walking down the plane's corridor. I guess graciousness isn't really a traveler's trait.

My laptop started giving me SMART failures during the flight, so I started a backup on the plane, which I had to interrupt because we were landing. I won't purchase from Tiger Direct anymore, I really promise this time.

Arriving at O'Hare, I started Kismet and noticed that the Wifi coverage was huge, but I had no time to connect if I wanted to eat and make my connecting flight. The "Bar&Grill" on concourse G has a good fruit and bagel breakfast. I heard a Homeland security anouncement as soon as I was off the plane : "Level is Orange!" Who cares, and who can really tell what the heck that means ? Should I really change my behavior or are they just announcing justification for draconian security measures that have *previously* happened that day ?

Finding a power outlet near the H8 gate at O'Hare is like finding a needle in a haystack. I finally located an outlet and sat on the floor in the corridor to recharge my laptop. Sure enough, 10 mins later, a golf cart came by and the driver ask me to go somewhere else. That's OK. I got 20% more juice for my battery. It's not like there were any signs on the floor or on the wall that this was a reserved space...

The flight from Chicago to San Jose was OK, but I swear that I have hearing damage from sitting right next to the engines on takeoff. I was wondering if I wasn't *in* the engine. I guess S80 airplane are not known for their "hush kits".

The hotel was OK, right next to the HP arena where the Sharks play. It certainly was not a 4-star, but had complimentary Internet, complimentary breakfast and complimentary dinner. For $79US per night, that's pretty hard to beat.

As I said in my previous blog entry, the whole discussion and certification with XenSource is under NDA, so I cannot write about it at this time. But the people I met were awesome. I mostly stuck around the Aussies and Kiwis since they seem to be the best people to drink with :-) Ask Stuart to tell you the one about him going from the east coast to the west coast of the US with a $300 car purchased in New York, and then sold for $100 in Los Angeles when the trip was done...

The XenSource executives were on the ball, and my certification went rather well. I stayed at the back of the class with some kindred souls, and soon the trainer was calling us "the dangerous guys at the back", or maybe it was more like "the <censored>ers at the back"... Rebooting the Aussies box from the other end of the classroom while they were trying to finish a module was fun, and they promised to get even later over beer.

Leaving San Jose was a bit tricky. The weather was pristine but the flight was delayed for 2 hours as our destination (Chicago) was dealing with -2C temperatures. Our pilot said "I don't really know why that really matters, but O'Hare flight control tells us what to do , and we do it". I don't think he was too impressed.

I landed at O'Hare already 10 minutes late for boarding for my next leg. I rushed and got there to see the other passengers filling the waiting area. The flight was actually delayed 1.5 hours. When the plane finally did show up we were once again told that they would need 3 volunteers because they had overloaded the plane *again*. I volunteered, but it came out that it wasn't necessary since 3 passengers didn't show up. We got good wind and I ended up landing in Ottawa with just one hour of lost time from my original schedule.

Using git as a management tool.

We use git a lot. I really love it. One thing that I have been able to do with it is to track each programmer's "drifting away" from the main branch.

We can use this to remind individuals to update the local branch to make sure that they don't drift too far out and that way their commits will have much less chance of conflict. It is also vital for doing structured releases. A release manager using this technique can easily tell if all programmers have commited all relevant code.

Start by cloning the main tree:

cg-clone /main/development/branch <product>
cd <product>
cg-branch-add <programmer name> /programmer/local/branch
cg-fetch <programmer name>
cg-branch-add <programmer2 name> /programmer2/local/branch
cg-fetch <programmer2 name>
and so on

Then use this script for getting and showing where everyone is:

cg-update
cg-fetch <programmer1 name>
cg-fetch <programmer2 name>
...
cg-fetch <programmerN name>
gitk --all

You will visually see where each programmer stands regarding the main branch, and if they need to push their local branches into the main branch for release.

Use the XenSource, Luke...

We are preparing to partner up with XenSource so here I am sitting at the product launch. Room is full, and a lot of different countries are represented. Met people from Australia, New Zealand, and Japan. We are the only partner from Canada.

Their VP of World Wide Sales and Channels, John Glendenning is about to give us a presentation on the merits of Xen as a product and XenSource as a company. So will the CEO, Peter Levine.

As today is a Non-Disclosure event, I will have to keep this post short...

... This paragraph would be huge if I wasn't under NDA ...

The big announcements will be December --th.

Now I get to fill in an evaluation sheet and get a free polo shirt. That makes the trip worthwhile :-)

Worse.... Update... Ever...

Well, I am usually keen on Apple's security updates. I have never been burned by them. Except for this latest one. To be fair, I think my laptop's hard disk started failing *immediately* after... SMART reports that I should move all my important data off the drive *right now*. That's lovely, as I am on a trip to California right now. So, it's 3am in a hotel room, and I'm copying what I can to my spare USB drive.

The security update prevents me from running Mail.app and Colloquy, so I have to revert to irssi and squirrelmail. It's the first time that a security upgrade reduces my efficiency. Thanks Apple. (Well, OK, the Mail.app crash *might* be due to GPG Mail and not Mail.app per-se...)

The thing that really aggravates me about the HD failing is that Disk Utility will not permit you to fix permissions if your SMART status is "failing". And no real flags to force the checking either.

So, here's what you have to do:

- Reboot and press Command-S to get into darwin's single-user mode.

- Run the following:

/sbin/fsck -fy
/sbin/mount -uw /
/sbin/autodiskmount -va 
/usr/sbin/diskutil repairPermissions /

- And then reboot

Laptop hand-me-down

Being a CEO has its perks, but getting the latest toys should not be one of them.

It strikes me as ridiculous to see the CEO of the company with gadgets that they own just for the "oneupmanship" of it. Of course, the same can be said about the sports cars, the huge mansion, the trophy wife...

I do most of my roadwarrior work using an old and battered Titanium G4. It was the ex-CEOs laptop, and has obviously seen one too many airport check-ins. The casing was damaged from being dropped on the ground, the CDROM was broken, and the battery was dead. I had a choice to make: purchase a new laptop, or fix this one. I didn't need a CDROM drive right away, and a battery cost $120CDN. If I can't show restraint at purchasing for myself, how can I show proper spending diligence to my investors ? I purchased the battery, fixed the casing with some vise-grips, and bought a CDROM drive when my travels brought me near the We Love Macs store.

That was last year. A month ago, I found myself being quite annoyed at the sound level of the 4800rpm drive in the Titanium. Also, the memory was getting a bit tight as I am now using a few more apps in the background than before. I priced and ordered a new 7200rpm drive (yes, I picked one that had less heat-load and used the same amount of battery life as my old one) and another stick of RAM. So, $300CDN later, I am once again happy. I had to use Carbon Copy Cloner to move the data to the other drive, but it was quite painless.

This laptop is over 4 years old, and I've had it for about 1.5 years now. I figure it should last me another 2 years, if the LCD holds on.

How I get this blog together

I might as well describe the steps I went through to get this blog into existence:

Choosing a blog host

I had the choice between hosting the blog itself or using a blog hosting service. If I hosted my own blog, then I could control the information that would be published. In other words, I would be able to censor this that I had already published. Well, the information I want to blog will be technical recipes, and won't be Xelerance intellectual property. Since I am making this information public anyways, there is no specific requirements for me to host my own blog. I settled on Blogger because I just wanted to get up and running fast.

Choosing a blog software

Bart proposed vimblog; that one is very tech-oriented, and the fun thing about it is that all blog entries are stored in "email format" on the server. Well, I decided on Blogger as a host, so since vimblog is mostly a server-side software, I decided to pass. I had to chose between software that would be able to speak MoveableType API to Blogger. I settled settled on Ecto because I have a Mac and Ecto offers a queuing system. With Ecto, I can create drafts of future blog entries I want to create for the future. Quite neat.

Publishing

Ecto sends automatically to Blogger when I connect to the Internet. I can also synch published stories between my workstation and my laptop. I cannot synch draft stories between my workstation and my laptop, but I will try to find or code a way. This might be hard, since Ecto seems to store drafts in a .plist file. Perhaps if I can find a way to synch parts of an XML tree, this might work.

Here we go

It's been 3 years since my last confession ....

Well, what are blogs supposed to be but a public confession of our actions ? Hopefully this won't be that kind of blog. I decided to get a blogger account and start typing for the general public because I've found myself asking Bart to blog a technical item or technique that I had created that day.

You see, that's where I think that blogging is becoming the norm. We are moving our great Internet archive method from Usenet to web logs. So, searching for techniques and information used to give us a link to a newsgroup, and now chances are you will be linked to an individual's blog instead. By creating this blog, I hope to archive some of the technical recipes that I've had to create as part of my job.

Of course, I might ramble somewhat about the "Chief Executive" part of the job as well.

As most bloggers seem to write to an audience, my blog may very well be lines of code and a few notes. If I bring in an audience, I will be the first surprised.