It’s hard to estimate how many lives she touched during her own 8 year battle with cancer. Few who came to any of the ACOR lists she was on seeking help didn’t find a ready response from Dr Dee.

As we have seen so clearly since the announcement of her passing,
Doreen was truly unique. She exemplified how an educated and engaged
patient can transform the odds of thousands of other patients by
showing them how to use information and peer support to best navigate
the healthcare system. She started as an Leiomyosarcoma patient but
very quickly she became MUCH MORE. Her information-rich website was
and remains amazing and is always the first entry to show up when you
google “leiomyosarcoma”. Right from the beginning Doreen changed the
outlook of this list and directed this community to a more
scientifically oriented group, to the benefit of countless people who
often do not understand how powerful her influence has been.

If you think this is a fitting way to remember Doreen, please help us by making a donation either online at  http://www.acor.org/donate/now/drdee.html or by sending a check to ACOR, marked “Dr. Dee Memorial Site”. If you make your donation online, Alison Woodman & Doreen’s daughter will be
instantly notified.

Gilles Frydman, founder ACOR

I’m not sure how many ACOR lists Dr Dee was on but she was on every one I ever joined, dishing out advice in her special way. Sometimes so ill she was completely bed ridden. Seemingly tireless as she led countless folks down the right treatment and care path.

I found the ACOR sarcoma list shortly after being diagnosed with cancer. Dr Dee was one of several folks who immediately reached out to me and started feeding me detailed instructions on how to proceed. They guided me through the next week and a half when my diagnosis changed 4 times. First dx, DFSP (dermatofibrosarcoma protuberans) with a Fibrosarcoma component. Then, Leiomyosarcoma (LMS). The third type actually escapes me at the moment! Then, with the aid of Dr. Dee and others the best sarcoma pathologist in the country figured it out, malignant glomus (glomangiosarcoma). I also was pretty much ordered (under threat of death) to get to a sarcoma center. I went to MD Anderson Cancer Center in Houston and Moffitt Cancer Center in Tampa. Second opinions are also vital as Dr. Dee was quick to point out. That will be five years ago in a little over a month. Had I stuck with the original course recommended by my local oncologist I’m not entirely sure I’d still be alive.

CNN coverage of her death: The life and death of an Empowered Patient - CNN.com

She always ended her notes with: “Together we are more, and more effective.” Madame Brimstone is gone and we all are a little less.  The world is missing a hero.

So I wrote a simple ruby script that tracks changes in aws assets. Stuck it in a cron job and it notifies me by e-mail whenever there’s a change on our account.

To get started grab the ruby gem

gem install right_aws

I decided to use SimpleDB to store state and history. Turned out to work really well. I’m digging the schemaless DB approach for this type of thing. It’s something I’m going to explore for other uses.

The script is simple

1. Iterate over the assets tracked
2. Load the info from EC2
3. Load the stored info in SDB and compare
4. Report any changes
5. Update SDB
6. Rinse, repeat

Lots more to build but this was a nice start and showed the right_aws gem is a capable library for building a complete set of tools to manage your Amazon Web Services account. The best bet is to go with RightScale and then just add functionality you need that RightScale doesn’t provide (shouldn’t be much).

require 'rubygems'
require 'right_aws'
 
LOG_FILE = '/tmp/ec2.log'
 
class AWS
    def initialize (argv, id, key)
 
        if argv.size > 1
            print_help
            exit 1
        end
 
        # List of resources to track
        #  0 - resource name
        #  1 - resources AWS id
        #  2 - [optional] name of the describe function in right_aws describ_[name]
        #      Only needed if it's not describe_[resource name]
        #  3 - [optional] name of parameter to the describe function
        @items = [
                ['images', 'aws_id', "images_by_owner", "self"],
                ['instances', 'aws_instance_id'],
                ['volumes', 'aws_id'],
                ['security_groups', 'aws_group_name'],
                ['snapshots', 'aws_id'],
                ['key_pairs', 'aws_key_name']
        ]
 
        if argv.size == 1
            if argv[0] == '-h'
                print_help
                exit 0
            elsif argv[0] == '-d'
                create_sdb_domains id, key
                exit 0
            else
                print "Unknown option: ", argv[0], "\n"
                print_help
                exit 0
            end
        end
 
        @sdb = RightAws::SdbInterface.new(id, key, {:multi_thread => true, :logger => Logger.new(LOG_FILE)})
        @ec2 = RightAws::Ec2.new id, key, {:logger => Logger.new(LOG_FILE)}
 
        check_for_updates
    end
 
    def print_help
        print "usage: #{$0} [options] \n"
        print "\n"
        print "\t -h this message\n"
        print "\t -d create sdb domains\n\n"
    end
 
    def check_for_updates
        @ec2_data = {}
        @sdb_data = {}
 
        @items.each do |i|
            key = i[0]
 
            meth_name = 'describe_' + i[2]||=key
            ec2m = @ec2.method(meth_name)
 
            @ec2_data[key] = convert_to_hash(ec2m.call(i[3]), i[1])
            @sdb_data[key] = sdb_get(key.to_s.upcase)
            compare(@ec2_data[key], @sdb_data[key], key.to_s.upcase)
        end
    end
 
    def create_sdb_domains(id, key)
        @sdb = RightAws::SdbInterface.new(id, key, {:multi_thread => true, :logger => Logger.new(LOG_FILE)})
        @items.each do |i|
            domain = i[0].to_s.upcase
            print 'Creating domain: ', domain, "\n"
            @sdb.create_domain domain
            print 'Creating domain: ', domain, "_ARCHIVE\n"
            @sdb.create_domain domain + '_ARCHIVE'
        end
        print 'Domains created.\n'
    end
 
    #--------------- SDB Routines ------------------#
 
    def sdb_save(domain, id, attributes)
      @sdb.put_attributes domain, id, attributes
    end
 
    def sdb_delete(domain, id, v)
        # Archive it first
        sdb_save(domain+'_ARCHIVE', id, v)
        @sdb.delete_attributes(domain, id)
    end
 
    def sdb_get(domain)
        v = {}
        results = @sdb.query(domain)[:items]
        results.each do |id|
            v[id] = @sdb.get_attributes(domain, id)[:attributes]
        end
        v
    end
 
    #--------------- EC2 Routines ------------------#
 
    # ec2 describe calls just returns an array of attributes for each entry
    # pull out the key and use that in a hash key, attributes
    def convert_to_hash(list, id_var)
        h = {}
        list.each do |v|
            if v[:aws_created_at] != nil
                v[:aws_created_at] = v[:aws_created_at].to_s
            end
            h[v[id_var.intern]] = v
        end
        h
    end
 
    def report_change (id, name, action, note)
        print "Asset #{id} : #{name} : #{action} : #{note}\n"
    end
 
    def compare(ec2_list, sdb_list, domain)
        # see if everything ec2 reports is in our db
        ec2_list.each do |k, v|
            if sdb_list[k] == nil
                v['added_date'] = Time.new.gmtime.to_s
                sdb_list[k] = v
                sdb_save(domain, k, sdb_list[k])
                report_change domain.capitalize.chop, k, "added", v['added_date']
            end
        end
 
        # see if everything the db reports is in ec2
        sdb_list.each do |k, v|
            if ec2_list[k] == nil
                v['removed_date'] = Time.new.gmtime.to_s
                report_change domain.capitalize.chop, k, "removed",
                        "Created: #{v['added_date']} Removed: #{v['removed_date']}"
                sdb_delete(domain, k, v)
            end
        end
    end
end
 
aws = AWS.new ARGV, 'your access key', 'your secret key'

All the hype reminds me of the hype Aspect oriented programming (AOP) went through climaxing around 2004.  AOP hype reached it peak when Daniel Sabbah, CTO of IBM Software said when speaking about AOP, “It is vital for our survival”. Blink. Cool stuff? Yeah. Really useful in some cases? Yeah? Vital to the survival of a multibillion dollar corporation? Blink. Oh, maybe he just meant programming in general!? Blink. In the end AOP is a useful tool in some specific places, the hype is gone and IBM has moved on to other things being vital for their survival (Blue Cloud?).

The dewpoint has hit and there’s one massive fog bank rolling in. Proceed with caution.

UITableView is probably the most used view on the iPhone. It’s flexible and the UI is ideally suited to use on the iPhone. There are lots of examples on how to add multiple items to a UITableViewCell. However, I needed to present some data in a more traditional spreadsheet style grid. The results worked well and enabled me to pack a lot of information on the screen that was very hard to follow without the vertical grid. I’ll show a very simplified version here you can use to add vertical lines to your UITableView.

First we need to create a subclass of UITableViewCell. This is so we can override drawrect and draw our lines and to add an array to hold a list of positions where we’ll draw the lines.

@interface MyTableCell : UITableViewCell {
	NSMutableArray *columns;
}
- (void)addColumn:(CGFloat)position;
@end

In this simplified example we’ll leave the positioning of the actual text in the cells in the UITableViewController and place it manually (full source code is attached at the end). We’re just providing a mechanism for drawing vertical lines to make a grid. Column locations are added by calling addColumn:

- (void)addColumn:(CGFloat)position {
	[columns addObject:[NSNumber numberWithFloat:position]];
}

Now lets override drawRect. In it we grab the current graphics context and set the line color and width. Then we iterate over our columns array drawing a line from the top of the cell row to the bottom at each position stored in the array.

- (void)drawRect:(CGRect)rect {
	CGContextRef ctx = UIGraphicsGetCurrentContext();
	// Use the same color and width as the default cell separator for now
	CGContextSetRGBStrokeColor(ctx, 0.5, 0.5, 0.5, 1.0);
	CGContextSetLineWidth(ctx, 0.25);
 
	for (int i = 0; i < [columns count]; i++) {
		CGFloat f = [((NSNumber*) [columns objectAtIndex:i]) floatValue];
		CGContextMoveToPoint(ctx, f, 0);
		CGContextAddLineToPoint(ctx, f, self.bounds.size.height);
	}
 
	CGContextStrokePath(ctx);
 
	[super drawRect:rect];
}

To add columns to the view just call

[cell addColumn:50];

when you’re building each cell.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
	NSString *MyIdentifier = [NSString stringWithFormat:@"MyIdentifier %i", indexPath.row];
 
	MyTableCell *cell = (MyTableCell *)[tableView dequeueReusableCellWithIdentifier:MyIdentifier];
 
	if (cell == nil) {
		cell = [[[MyTableCell alloc] initWithFrame:CGRectZero reuseIdentifier:MyIdentifier] autorelease];
 
		UILabel *label = [[[UILabel	alloc] initWithFrame:CGRectMake(0.0, 0, 30.0,
														   tableView.rowHeight)] autorelease];
		[cell addColumn:50];
		label.tag = LABEL_TAG;
		label.font = [UIFont systemFontOfSize:12.0];
		label.text = [NSString stringWithFormat:@"%d", indexPath.row];
		label.textAlignment = UITextAlignmentRight;
		label.textColor = [UIColor blueColor];
		label.autoresizingMask = UIViewAutoresizingFlexibleRightMargin |
		UIViewAutoresizingFlexibleHeight;
		[cell.contentView addSubview:label]; 
 
		label =  [[[UILabel	alloc] initWithFrame:CGRectMake(60.0, 0, 30.0,
															tableView.rowHeight)] autorelease];
		[cell addColumn:120];
		label.tag = VALUE_TAG;
		label.font = [UIFont systemFontOfSize:12.0];
		// add some silly value
		label.text = [NSString stringWithFormat:@"%d", indexPath.row * 4];
		label.textAlignment = UITextAlignmentRight;
		label.textColor = [UIColor blueColor];
		label.autoresizingMask = UIViewAutoresizingFlexibleRightMargin |
		UIViewAutoresizingFlexibleHeight;
		[cell.contentView addSubview:label];
	}
 
	return cell;
}

That’s it. Being a bit dense I beat my head on my desk a few days before it become obvious how blindingly simple it really was. A lot was just learning ObjectiveC and how UIKit works in general. I’m now working on a GridTableView library that will add a good bit of functionality and ease of use. I’ll post it here.

Here’s the source code.

Lisa I’m going to become a vegetarian
Homer Does that mean you’re not going to eat any pork?
Lisa Yes
Homer Bacon?
Lisa Yes Dad
Homer Ham?
Lisa Dad all those meats come from the same animal
Homer Right Lisa, some wonderful, magical animal!

One of my latest cooking fads is making my own bacon. It’s very easy (especially with a good smoker) and the results are outstanding. Pork belly is pretty easy to come by, ask your local butcher and he should have some. However for some truly awesome bacon get fresh belly from Niman Ranch. Their farm raised pork is just outstanding.

First step is to apply some cure. I use a dry cure (I’ve tried wet cures and haven’t liked the resulted nearly as much). In this picture I’m using a purchased cure Buckboard bacon cure which is actually a cure for making bacon from pork butts and shoulders but works fine for belly. Since I did this batch I’ve started using the cure recipe from Michael Rulman’s Charcuterie.

8 ounces sugar
1 pound kosher salt
2 ounces pink salt (aka Curing Salt or sodium nitrite)

If I’m making breakfast bacon I’ll add maple syrup or dark brown sugar. For non breakfast bacon you can get creative with any number of savory spices.

After applying the cure the belly is put in 2 gallon zip lock bags and put in the refrigerator for 5-7 days turning the belly over every other day to keep the juices that form in contact with the meat. First time I made bacon the juices worried me (I was doing a dry cure after all!) so I drained it. Wrong move, that juice is good, keep it in contact with the meat.

Once it’s cured I take the belly out of the bags, rinse than dry on racks in the refrigerator for a day. Here they are all set and ready to go into the smoker.

Into the Bradley. 210 degrees F. Apple wood pucks.

Two hours in.

6 hours later I pulled them when the internal temp hit 160 degrees. Let them cool for a bit then remove the rind.

The finished product. Slice, cook, eat!

As Mr T would say.Head over to Bacon Nation for more bacon fun.

As part of a new offering we decided to add in our new messaging direction. We’re processing realtime voice conversations. Some of our major considerations are:

1. Latency and Performance - Latency matters to us. A LOT. I’m including not only network transport but also memory and CPU. The total time it takes for a message to get from it’s native format in the sender to it’s native format in the receiver. We’re dealing with real time voice communications, too much latency and best case is the callers experience suffers. Our labor model is also sensitive to even small changes in latency. The smaller the latency the more efficient we are, the happier our client’s customers are and the more money we make. As greedy capitalist we see that as a good thing.
2. Versioning - Our current system has no versioning. Yeah, short sighted on my part. We have to fix it so it’s required for any new message protocol. Protobuf fits our needs on this nicely. Different versions have to coexist and interoperate. We could do this on a different layer than the messaging but it makes sense to me to keep it at this level.
3. Java and C++ - Language independence is cool and all but in practice if the protocol support Java and C++ we’re good to go. Maybe I’m being a bit myopic but my feeling is the likely hood that whatever we choose will expand to support more languages in the future is very high if it supports several today.
4. Internal - We control the end points. I don’t care if the schema is external to the data package. In fact, for our use case that’s a plus. For any external services we’ll still expose those using the usual standards. Internally our applications will be using PB for their messaging format.

Google Protocol Buffers

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the “old” format.

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

• are simpler
• are 3 to 10 times smaller
• are 20 to 100 times faster
• are less ambiguous
• generate data access classes that are easier to use programmatically

Alternatives

JSON

To me protobuf feels like compiled JSON. They are very similar.  The main difference being JSON sends data over the wire in text format verses protobuf’s binary format. The latter has the advantage of a smaller size and being faster for a computer to parse.

ASN.1

Why not ASN.1? Seems like one of the best choices. Well understood and widely used. Sure the full ASN.1 specification is complex but we’d only need a small subset. I’m still struggling with this one a bit. Tool support seems a bit better in protobuf and it’s definitely simpler.

Thrift

Facebook’s Thrift is very similar to protobuf. Not surprising since the main author interned at Google. It’s a strong offering and recently became an Apache project. Nice stuff. Stuart Sierra has a nice comparison on his blog, Thrift vs. Protocol Buffers. Another worthy contender but not a big enough advantage to stop the internal momentum protobuf already has.

HDF5

The HDF wiki has an entry Google Protocol Buffers and HDF5 that concludes:

In summary, Protocol Buffers and HDF5 were designed to serve different kinds of data intensive applications: a network based transient message system, and a high performance data storage system for very large datasets such as multi-dimensional images, respectively. That said, both 1) offer open source technologies that can reduce data management headaches for individual developers and projects, 2) increase the ability to share data through the use of well-defined binary formats and supporting libraries that run on a variety of platforms, and 3) provide the ability to access data stored with “older” versions of the data structures.

Different design goals. HDF5 doesn’t fit our needs as well. 

Hessian

The Hessian protocol has the following design goals:

• It must not require external IDL or schema definitions, i.e. the protocol should be invisible to application code.
• It must be language-independent.
• It must be simple so it can be effectively tested and implemented.
• It must be as fast as possible.
• It must be as compact as possible.
• It must support Unicode strings.
• It must support 8-bit binary data (i.e. without encoding or using attachments.)
• It must support encryption, compression, signature, and transaction context envelopes.

I still haven’t figured out how/if you can version your messages. Can you add and remove fields and still have compatibility (backwards and forwards)?  Cool effort, still feels very rough in places. Another worthy effort to consider.

ZeroC ICE

At it’s core it’s

The Ice core library. Among many other features, the Ice core library manages all the communication tasks using a highly efficient protocol (including protocol compression and support for both TCP and UDP), provides a flexible thread pool for multi-threaded servers, and offers additional functionality that supports extreme scalability with potentially millions of Ice objects.

ICE is a comprehensive middleware system. It can even use PB as it’s messaging layer. It’s messaging layer doesn’t handle adding or removing fields as well as PB. We don’t need the RPC side of ICE. Just not a good fit for us.

SDO

Service Data Objects provides a rather ambitious messaging architecture. It’s concerns aren’t speed and efficiency. The SDO V2.1 White Paper states

SDO is intended to create a uniform data access layer that provides a data access solution for heterogeneous data sources in an easy-to-use manner that is amenable to tooling and frameworks.

Interesting, not a fit.

Cisco Etch

Primary focus is an RPC implementation, not a messaging protocol. Steve Vinoski summarized it nicely in Just What We Need: Another RPC Package. In fairness Steve had some negative thoughts on PB also in Protocol Buffers: Leaky RPC. However, his concerns are around the undefined RPC features Google put in PB, not the IDL type aspects of PB.

Some other XML based protocol

I quickly learned that even though I had a kind, well regarded doctor, he didn’t have the expertise to handle my case. What I needed was a team of physicians that see hundreds of cases a year of my type of cancer. A team, not a doctor. Treatment frequently covers a lot of disciplines, surgery, chemo and radiation. I eventually landed at Moffitt Cancer Center and met with a surgeon. He told me what he thought my treatment plan would be but quickly qualified “I can’t do anything until the full cancer board approves your plan.” I didn’t have to go to each type of doctor, records in hand, and hear what they thought their part of the treatment should be. I had a team, all meeting together and determining the best course of action. 

Don’t be passive! Richard Bloch summed it up nicely:

Hamilton Jordan, White House Chief of Staff under President Jimmy Carter, upon being diagnosed with cancer at the age of 41, stated, “One of my closest friends is a doctor, and he came to see me one day and said, ‘You’re going to have to manage your own damn medical care.’ That shocked me. It put a sense of burden and responsibility on me that I wasn’t sure I could exercise properly. But as I saw things unfold, I saw he was right. Although it was tempting to stay at (the hospital) and be among all my friends, and the (hospital) doctors thought they could do as good a job as anybody, I realized there were many choices to be made, and I had to make them for myself.”   Fighting Cancer by R. A. Bloch

You’re going to have to manage your own care but you do not need to do it alone. Use the resources Christine listed. Become a Google fiend. Find out what’s valid science and what’s quackery. Act.