Peterbe.com

Starting today, I'm a Hubber. Meaning, I work for GitHub. I'll be joining the GitHub Docs team to help technical writers document all the various products that GitHub have. Since I haven't actually started coding anything yet, I don't want to claim I know how it works or exactly what I'll be working but on, but I do know that the site at hand is docs.github.com and I've previously taken a lot of inspiration from this site when building the MDN rewrite.

If you are a Hubber, too, and reading this; Hi! Let's be friends! I'm a friendly guy. Please ping me and say hi.
I'll be working from home here in Mount Pleasant, South Carolina. I have 2 young kids; Tucker and Charlotte, who mean the world to me. And my backbone-of-life wife Ashley. My hobbies are coding, swimming, golf, and cooking.

Being a recruiter is hard work. A lot of pressure and having to deal with people's egos. Although I have no plans to leave Mozilla any time soon, it's still some sort of value in seeing that my skills are sought after in the industry. That's why I haven't yet completely cancelled my LinkedIn membership.

When I get automated emails from bots that just scrape LinkedIn I don't bother. Sometimes I get emails from recruiters who have actually studied my profile (my blog, my projects, my github, etc) and then I do take the time to reply and say "Hi Name! Thank you for reaching out. It looks really exciting but it's not for me at the moment. Keep up the good work!"

Then there's this new trend where people appear to try to automate what the bots do by doing it manually but without actually reading anything. I understand that recruiters are under a lot of pressure to deliver and try to reach out to as many potential candidates as possible but my advice is: if you're going to do, do it properly. You'll reach fewer candidates but it'll mean so much more.

I got this email the other day about a job offer at LinkedIn:

• I have a Swedish background. Not "Sweetish". And what difference does that make?
• I haven't worked on "FriedZopeBase" (which is on my github) for several years
• I haven't worked on "IssueTrackerProduct" for several years
• Let's not "review [my] current employment". That's for me to think about.

So what can we learn from this? Well, for starters if you're going pretend to have taken time, do it properly! If you don't have time to do in-depth research on a candidate, then don't pretend that you have.

I got another recruiter emailing me personally yesterday and it was short and sweet. No mention of free lunch or other superficial trappings. The only personal thing about it was that it had my first name. I actually bothered to reply to them and thank them for reaching out.

Today we launched The London Frock Exchange which is a joint project between Fry-IT, Charlotte Davies and Sarah Caverhill

Elevator sales pitch: Unlike other clothes swapping sites, with Charlotte, Sarah and Rani as an expert hub in the middle you don't swap straight across; no you swap one frock in and can choose a frock (of equal value) from the pool of frocks.

Fry-IT is co-founding this venture and hope it'll make us billionaires by the end of the year (They take a small admin fee of £25 for sending you a frock back but sending it in is free with freepost). It's been great fun to work on it over the last couple of months as it means we (Fry-IT is a all-male highly technical company) have had to learn about sizes, body shapes and trying to learn how a female web audience thinks. The ladies have done a great job of seeding it with lots and lots of frocks all of which you can wear in a matter of days if you just swap one of equal value in first. Enjoy!

This is the second part of the summary of the Google London Automation Test conference that I blogged about.

The conference lasted two days. Here's a brief summary of what happened on the second day which was on the same theme as the first: automated testing of software. The highlight of the day was Goranka's talk about performance testing.

I'm writing this from Googles office in London, UK where Google is hosting a conference on Automated Testing. Testing of software that is. There's been very little talking about usability testing or hardware testing. There's been a lot of talks about taking unittesting taken to the next level.

I'm going to blog again about the stuff I learn today. Below is a summary of the stuff I learnt yesterday. Just coming to see the Google office was a very interesting experience. It's very impressive. The office building is beautiful and has a nice feel to it. One of the most impressive things about this office is the free-food canteen which I've used almost excessively but nobody except my girlfriend and my kung fu teacher will minds. I'm only here for two days and they can afford it :)

A database table that I've had to work with has a something called identifiers which are humanreable names of questions. There's a HTML template where the question designer can place the various questions in a human-sorted order. All questions get identifiers in the form of <something><number> like this: Head1 or Soma3 or Reg10 where Head, Soma and Reg are sections. Changing the nameing convention from Head1 to Head01 is too late because all the templates already expect Head1 not Head01. Initially I sorted the identifiers like this:

SELECT id, identifier 
FROM questions
WHERE section=123
ORDER BY identifier 

The result you would get is:

Head1
Head10
Head2
Head3
...

The human readable sort order should have been this:

Head1
Head2
Head3
...
Head10

There are several ways to do case insensitive string matching in SQL. Here are two ways that I've tried and analyzed on a table that doesn't have any indices.

Option 1:

(
 LOWER(u.first_name) = LOWER('Lazy') OR 
 LOWER(u.last_name) = LOWER('Lazy') OR
 LOWER(u.first_name || u.last_name) = LOWER('Lazy')
)

Option 2:

(
 u.first_name ILIKE 'Lazy' OR 
 u.last_name ILIKE 'Lazy' OR
 u.first_name || u.last_name ILIKE 'Lazy'
)

A potentially third option is to make sure that the parameters sent to the SQL code is cooked, in this case we make the parameter into lower case before sent to the SQL code

Option 1b:

(
 LOWER(u.first_name) = 'lazy' OR 
 LOWER(u.last_name) = 'lazy' OR
 LOWER(u.first_name || u.last_name) = 'lazy'
)

Which one do you think is fastest?

Here at Fry-IT we use timesheets, like so many other companies, to track the time we spend on each client project. Despite being a very "web modern" company we still don't use a web application to do this. What we use is a python script that I wrote that uses raw_input() to get the details in on the command line. The script then saves all data in a big semicolon separated CSV file and is stored in cvs. This works quite well for us. It's in fact all we need in terms of actually entering our times which is usually very easy to forget.

But, here's an idea for a timesheet tracker that will not guarantee but will really help in not forgetting to fill in your timesheets. The idea is that you have a web application of some sort that is able to send out emails to registered individuals. These emails will be sent at (a configurable time) the end of the work day when you're about to leave for the day. You might have seen this before on other timesheet tracker applications; it's not new. What is new is that the email would contain lots of intelligent URLs that when clicked fills in your timesheets for that day.

Since I always forget how to do this and have to reside to testing back and forth or to open a book I will now post an example patch that alters a table; correctly. Perhaps this is done differently in Oracle, MySQL, etc. but in PostgreSQL 7.4 you can't add a new column and set its default and constraints in the same command. You have to do that separately for it to work and most likely you'll have to run a normal update once the column has been added.

Just doing:

ALTER TABLE users ADD mobile VARCHAR(20) NOT NULL DEFAULT '';

...won't work and you'll get an error.

There's lots of small pieces of knowledge in our company. Not the kind of knowledge that requires thinking but stuff like,

• where's the black stapler
• how to add a domain to the xyz-server apache config
• who to call to sort out the airconditioner

Most of this core "knowledge" we have tried to store in a relatively structured Wiki (we use zwiki) which has been a really good start. It's good because whenever I need to refresh my memory on some IP address or how to install a printer I can go to our company wiki and search for it there.

The problem is that it's such a choir to maintain the wiki. It takes several seconds to go there, log in and (biggest bore) to find the most appropriate places to write anything new or where to update something old. I know I sound disgustingly lazy, but when you have to do it many times per day you want the software to help you rather than being an obstacle. I'm now instead looking for a different solution: a blog!