Google offers a browser plugin to opt out of Analytics tracking. Grab it from http://tools.google.com/dlpage/gaoptout

Perl: time PHP: time() Ruby: Time.now.to_i Python: import time int(time.time()) Java: long epoch = System.currentTimeMillis() / 1000; C#: epoch = (DateTime.Now.ToUniversalTime().Ticks - 621355968000000000) / 10000000; VBScript: DateDiff("s", "01/01/1970 00:00:00", Now()) Erlang: calendar:datetime_to_gregorian_seconds(calendar:now_to_universal_time(now())) - 719528*24*3600. MySQL: SELECT unix_timestamp(now()) PostgreSQL: SELECT extract(epoch FROM now()); Oracle: SELECT (SYSDATE - TO_DATE('01-01-1970', 'DD-MM-YYYY')) * 24 * 60 * 60 FROM DUAL SQL Server: SELECT DATEDIFF(s, '1970-01-01 00:00:00', GETUTCDATE()) JavaScript: Math.round(new Date().getTime() / 1000) Bash: date +%s PowerShell: Get-Date -UFormat "%s"

Have a single authoritative source for your schema. Everyone should know where the official schema lives. You should be able to walk up to a fresh machine, pull from source control, build, and run a simple tool to set up the database. Ideally the build process handles it automatically. Version your database. The goal is to propagate changes from development to test to production in a controlled way. You should also be able to recreate the database at any point in time. If someone reports a bug in build 20100612.1, you need to reproduce the exact database state from that build.

A shared database server is a convenience that turns into a trap. Developers overwrite each other’s changes. My changes on the server break your code on your machine. Remote development is slow. Avoid shared databases. The time you save setting up individual databases is nothing compared to the time you’ll waste debugging conflicts.

We talk endlessly about improved software quality and reduced risks. But for clients and users, the only tangible asset is deployable software. Everything else – process documents, test reports, velocity charts – is noise without working code to back it up.

You can manage scope, time, cost, and quality much more effectively by basing decisions on working software with actual feedback and metrics, not just task items on a project schedule.

Use qx() to capture the output of uptime and parse the load averages: # 1-minute load average my $load1 = qx(uptime | awk -F "load average: " '{ print $2 }' | cut -d, -f1); # 5-minute load average my $load5 = qx(uptime | awk -F "load average: " '{ print $2 }' | cut -d, -f2); # 15-minute load average my $load15 = qx(uptime | awk -F "load average: " '{ print $2 }' | cut -d, -f3); Note: use qx() not exec() – exec replaces the current process and doesn’t return.

If you get this error when running Gearman client code: Can't call method "syswrite" on an undefined value at /usr/local/share/perl/5.10.1/Gearman/Taskset.pm line 202. The fix is to specify the port explicitly. Change: $client->job_servers('127.0.0.1'); To: $client->job_servers('127.0.0.1:4730');

I’ve been playing with Gearman over the past few weeks and I’m impressed by how little friction there is between the idea of distributing work across machines and actually making it happen. The Perl module, Gearman::Client and Gearman::Worker, is straightforward enough that you can have a client and a worker talking to each other through a job server in under an hour. The basic model is simple. You have a client that submits jobs, a worker that performs them, and a job server sitting in the middle dispatching work to whichever worker is free. The client and worker can be written in different languages, run on different machines, and you don’t need to worry about the networking yourself — Gearman handles all of that through TCP sockets to the job server. ...

A set of requirements is complete when it describes all significant concerns of the user – functionality, performance, design constraints, attributes, and external interfaces. If any of these are missing, the requirements are incomplete.