ANNOUNCEMENT: Upcoming Disaster Communications Meeting on Wednesday, February 10, 2010 6:30PM

The American Red Cross Bay Area (ARCBA) San Francisco Disaster Communications (DComms) Team is holding its first meeting on Wednesday, February 10th, 2010 from 6:30PM to 8:00PM at 85 Second Street, SF in the 1st Floor Boardroom. Topics to be discussed include:

  1. Introduction by Team Leadership
  2. ARCBA Mission
  3. DComms Team Mission
  4. San Francisco Communications Room Tour
  5. Upcoming Training Opportunities
  6. Radio Programming Assistance

THIS IS AN OPEN EVENT. All interested parties are invited to attend. Please bring your radio (if you own one).

Talk in frequency is 147.42MHz Simplex on the 2Meter Amateur Radio band.

For more information please contact the ARCBA SF Disaster Communications Team:

Sincerely,
Greg Albrecht & Lawrence Lin
SF Disaster Communications Leads
American Red Cross Bay Area
85 Second Street, 8th Floor
San Francisco, CA 94105

Many important relief efforts are taking place right now in Haiti and I want to make sure that the people of our local disaster communications teams are taking notes. We’ve been given the opportunity to witness a humanitarian crisis emerge real time via numerous traditional and new media outlets. This crisis is the kind of event that we hope against all odds will never happen, but plan against time to prepare for.

Please take your time in capturing this moment and try think about how you would prepare yourself, your friends, your community and your preferred social structures. Take notes, save reports, pictures, and anything that you find worthy. Below is a sample of the areas of detail that are worth reviewing:

  1. logistics in and out of the effected areas
  2. communications resilience and usage in the effected areas
  3. coordination of resources from unsolicited entities
  4. previously ignored assets now of use in the effected areas

My hope is that at some point in the next month our disaster communications teams can get together as groups and discuss what we saw (or perceived) and use it to train ourselves. Think of this as the worse case Use Case.

There are lots of Testlink API client examples in Python. None-of-them-work. I’d like to think mine does:

#!/usr/bin/env python
import xmlrpclib

class TestlinkAPIClient:
    SERVER_URL = "http://testlink.splunk.com/lib/api/xmlrpc.php"

    def __init__(self, devKey):
        self.server = xmlrpclib.Server(self.SERVER_URL)
        self.devKey = devKey

    def reportTCResult(self, testcaseexternalid, testplanid, status):
        # fyi: this is XML-RPC, the order of our parameters matters.
        data = {"devKey":self.devKey, "testcaseid":testcaseid, \
        "testplanid":testplanid, "status":status, "guess":True}
        return self.server.tl.reportTCResult(data)

    def getInfo(self):
        return self.server.tl.about()

# substitute your Dev Key Here
client = TestlinkAPIClient(devKey="xxx")

# get info about the server
print client.getInfo()

# Substitute for tcid and tpid that apply to your project
print client.reportTCResult(testcaseexternalid='splunk-655', \
testplanid=1328, status="p")

Python comes with the tarfile module who’s usage allows manipulation of tar archives, including those using bzip2 or gzip compression. Python 2.6’s tarfile includes the ability to exclude files when creating tar archives:

TarFile.add(name, arcname=None, recursive=True, exclude=None)
Add the file name to the archive. name may be any type of file (directory, fifo, symbolic link, etc.). If given, arcname specifies an alternative name for the file in the archive. Directories are added recursively by default. This can be avoided by setting recursive to False. If exclude is given it must be a function that takes one filename argument and returns a boolean value. Depending on this value the respective file is either excluded (True) or added (False).

Changed in version 2.6: Added the exclude parameter.

Searching around I was unable to find an example usage of this parameter, so I’ve created the example below:

#!/usr/bin/env python
import tarfile

# return True for files we want to exclude
def excluded_files(file):
    _return = False
    # here we're checking to see if the file is 'fwdApp' -
    # a file don't want included in our tar archive.
    if file.find('fwdApp') > -1:
        _return = True
    return _return
# create a tar archive of my home directory
tar_archive = tarfile.open('home.tar','w')
tar_archive.add('/home/gba',exclude=excluded_files)
tar_archive.close()

My associate Comm-Lead (aka http://curikim.com) and I performed a FRS radio check on our way home from downtown. We used store bought 12 (14?) channel Motorola talk-about FRS radios. We took two different routes from work to home, here’s a map:


View FRS Test Route in a larger map

The map is somewhat self explanatory, but here’s some notes. We had very good coverage until Curi hit Duboce and Market. At that point I could pick her up if I turned the squelch all the way down. For the remainder of the trip I could tell there was a background signal but I could not make her out out until she reached the hill on 17th  and Clayton at which point I was at Masonic and Fell and received an excellent signal.

It seems from our test that in a flat part of the city, the expected range of FRS is about 4-6 blocks.

I’ve created a tar.gz, yet Python’s mimetypes.guess_type() and my OS’ file command see it as two different mime.types:

$ file SPL-28435-etc_apps.tar.gz
SPL-28435-etc_apps.tar.gz: gzip compressed data, was "SPL-28435-etc_apps.tar",
last modified: Mon Dec 28 11:56:05 2009, max compression

$ python
Python 2.6.4 (r264:75706, Dec 16 2009, 06:15:35)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_type('SPL-28435-etc_apps.tar.gz')
('application/x-tar', 'gzip')

If I attach this file to a JIRA with this mime-type and then download the file:

$ file SPL-28435-etc_apps.tar.gz
SPL-28435-etc_apps.tar.gz: data

If I attach the file to JIRA using the mime-type ‘application/x-gzip’ and then download the file:

$ file SPL-28435-etc_apps.tar.gz
SPL-28435-etc_apps.tar.gz:    gzip compressed data, was "SPL-28435-etc_apps.tar",
last modified: Mon Dec 28 11:56:05 2009, max compression

I’ve also tried overriding Python’s mime.magic without luck:

>>> from mimetypes import MimeTypes
>>> m = MimeTypes()
>>> m.read('/usr/share/file/magic.mime')
>>> m.guess_type('SPL-28435-etc_apps.tar.gz')
('application/x-tar', 'gzip')

One of my more favorite HST quotes is from the book Hells Angels (1966):

The Edge… There is no honest way to explain it because the only people who really know where it is are the ones who have gone over.

Which is very reminiscent of Santayana’s Tipperary 101:

Only the dead are safe ; only the dead have seen the end of war.

Original sent to members of the Red Cross DAT Communications team and Duboce Park NERT:

At the past few events I’ve noticed volunteers arriving without the
appropriate safety gear. If the agency we’re working with has issued
us any type of gear, be that gloves, helmets, vests or radios, it is
our responsibility to bring these items to every event, be it
training, exercise, actual incident or drill. The idea behind these
events is to test our response, and part of that response is being
prepared – lack of these items constitutes a lack of preparedness and
an inability to respond. If you’re missing any of your safety gear
please report the missing items to you Team Lead or Coordinator.

Gear that’s appropriate for responders:
1. Your Agency ID
2. Helmet
3. Safety Vest or Agency Jacket/Vest
4. Gloves
5. Amateur Radio (if licensed)
6. Work Boots

Of course, when the big one hits we might not be able to get to this
equipment, until then don’t let the disaster in your closet keep you
from participating in drills.

http://www.inc.com/magazine/20091201/when-and-how-to-micromanage.html

Luckily I rarely have to deal with these people:

“At the top of every company, there’s at least one person who really
cares and really wants the product and the customer experience to be
great. That’s you, and me, and Ryan. Below that person, there are
layers of people, many of whom are equally dedicated and equally
talented.

But at some point as you work your way through an organization, you
find pockets of people who don’t care that much. For them, it’s a job.
They just want to get through the day.”

http://eng.kaching.com/2009/12/baking-availability-sla-into-code.html

I like the idea of offloading the responsibility for determining if a
service is ‘available’ off onto the caller and gaming yourself to
think about what should happen if your SLA is violated.