Don’t delay, start contributing today!

Mark humorously makes a very good point in this short talk at TED: don’t delay contributing!  Your contribution may not be large or dramatic but you cannot predict the scale of the impact in peoples lives you can make until you start contributing.

This video reminds me of the principle of inertia:

“The vis insita, or innate force of matter is a power of resisting, by which every body as much as in it lies, continues in its present state, whether it be of rest, or of moving uniformly nor a measure of mass.” – Sir Issac Newton (1687)

If your are currently not contributing then your are liking to continue doing nothing, however if you are already contributing then you are likely to continue contributing.  The hard part is making the transition between these two states.  By starting with small contributions as Mark suggests we can increase our chances of successfully making the transition from doing nothing to contributing t0 each other and society.

Processing Perforce command output with python.

The Perforce command line client supports returning Python marshalled dictionary objects as command output via the ‘-G’ option.  This functionality can be used to easily export data from Perforce to various formats to allow further analysis.   The following script exports the  submitted change lists returned by the p4 changes command to an CSV file which can easily be loaded into Microsoft Excel for analysis.  The script also converts the returned timestamp into human readable date and time columns.

"""Perforce changes dumped into CSV format."""
import marshal, subprocess

def Run( cmd ):
  """Run supplied perforce command and return output as a list of dictionaries."""
  results = []
  cmd = "p4 -G %s" % cmd
  # Run the Perforce command using -G option to get results as Python marshalled dictionary objects.
  process = subprocess.Popen( cmd, stdout=subprocess.PIPE, shell=True )
  # Harvest stdout output until end of file exception is thrown.
    while 1:
      output = marshal.load( process.stdout )
      results.append( output )
  except EOFError:
  return results

if __name__=="__main__":
  import csv, datetime

  # Perforce command to run, fetch the latest submitted changelists.
  cmd = "changes -L"

  # Get results.
  results = Run( cmd )
  print "'p4 -G %s' - %d" % (cmd,len(results))

  # Convert timestamp into human readable form.
  for result in results:
    result['timestamp'] = result['time']
    result['date'] = datetime.datetime.fromtimestamp(int(result['time'])).strftime("%d/%m/%Y")
    result['time'] = datetime.datetime.fromtimestamp(int(result['time'])).strftime("%H:%M:%S")

  # Write results to file.
  f = open( 'p4.csv', 'wb' )
  w = csv.DictWriter( f, results[0].keys() )
  for result in results:
    w.writerow( result )

This script could also be used to export the results of most Perforce commands to CSV simply by changing the cmd string (line 25).  It could also be adapted to export into a different format e.g. JSON, XML or even into a database like SQLite.

Friday Linkage

This week’s interesting links:

  • 20 percent time spent coding in the clouds.
    An interesting post by a Google engineering director about how he recently used his twenty percent time developing his first App Engine application on a long haul flight to Japan.
  • Do or do not.
    The author has an interesting take on not using asserts in favour of using unit tests instead.  Reflecting on this I find asserts and unit tests essential for C++ projects however for projects in Python I tend to just use unit testing.
  • How not to get things done.
    This ironic post makes a case against those engineers with a knack for ‘getting things done’ usually at any price (e.g. gratuitous hacking) can be dangerous to the project.  All engineers require leadership on code quality, testing and maintenance not just those who get things done.
  • A Hundred Machines for Only Ten Dollars an Hour.
    An interesting presentation on just how the Amazon cloud makes massive parallel data processing using Hadoop very cheap: $100 in this case.  There is also a warning as the author ends up spending $3000 in legal fees convincing FaceBook that he didn’t do anything wrong with his $100 of data processing!
  • How to polish a turd.
    A post about the process of developing and evolving a game concept from conception to shipping.  I have had the opposite experience from the author with publishers being the main source of change requests.
  • Are gas prices really that high?
    As a European living in Canada it is easy to appreciate just how much cheap fuel is here.  This graph maps out petrol prices for the whole world relative to the US prices which are even lower than Canada’s prices.
  • Time Management (Comic).
    An amusing take on time management blog posts.

Using Perforce Counters to control syncing

Perforce has a handy system of built in variables you can use which are visible to all users for a particular server, these variables are called Counters.  Counters are very handy way to distribute Perforce specific information e.g. the last change list that successfully passed automated testing.

Its relatively easy to write a batch file to sync to the change list specified in a counter. Although it isn’t pretty due to the limitations of batch scripting: first pipe the output from the p4 counter command into a temporary file, use the contents of the file to set a batch variable, then delete the temporary file (to keep things tidy) and finally call P4 sync with your Perforce path and the new batch variable.

echo off

REM Get change list specified in counter.
p4 counter <COUNTERNAME> > CL.txt
set /p CL= < CL.txt
del CL.txt

REM Sync Perforce to change list specified in counter.
p4 sync <P4PATH>@%CL%

I usually specify the port, user and client when I am using Perforce from a script to make sure the correct server/user/client is used as I login to many different Perforce servers so its not guaranteed that the correct server is setup in the command line environment. To specify the port, username and client spec to use insert the following after ‘p4′ and before the sync/counter command.


I use a script like this to avoid syncing to known broken change lists, which is a big time saver

Friday Linkage

This week interesting links:

It takes a team to ship an idea

Ideas aren’t enough, it isn’t enough to think of something first: you need to implement and ship it to claim it.

To implement and ship an idea requires more than one individual: it requires a team, co-operation and the refining of the idea.  This is often forgotten, instead the original individual’s epiphany is idolized.

The epiphany is not the hard bit.  The idea for a automobile autopilot has occurred to pretty much everyone who drives or uses a car.  Yet there is still no commercial car autopilot solution.  Why?  It requires expertise from multiple domains to solve such a whole series of non-trivial problems in multiple problem spaces to reach the goal: this means hard work, problem solving, intense discussion, passion and lots of resources.

Liza Wood has a good post about this over on her blog: Sockets & Lightbulbs. Go read & watch.