Here are some resources that have helped formulate a basic understanding for me: 

• Khan Academy:  American Call Options
  • A great little video to introduce the concept.  Sal's graphical, example oriented approach was an extremely instructive nugget to get me started
• Khan Academy:  Call Options as Leverage
  • Reinforced the concept that a call option is a "force multiplier" and can yield magnitudes higher percent returns, while simultaneously reducing the required upfront capital.
• Yale Econ 252:  Financial Markets - Lecture 23
  • With Khan Academy piqueing my interest in the topic, I found a more rigorous lecture on the topic.  While Shiller is not exactly the most dynamic instructor (at least this was my impression from this single lecture), the video provides an excellent historical and theoritical foundation on options markets.
• TD Ameritrade's Investor Education
  • I have been a TDAmeritrade customer for years, and have found that their online portfolio management tools are simple and intuitive, yet quite powerful in terms of access to instruments.
  • They are definitely not the cheapest alternative in terms of trade commissions, but this has not yet been a concern for me given my preference for particular ETFs which TD offers commission free.
  • Their Investor Education center is geared primarily toward the use of TD trading platform, but the tutorials were very instructive in learning hw to read options chains and understand how to evaluate key attributes such as the option Strike Price, Expiration date, bid/ask spread etc.

The basics on Options Trading are easy to grasp, but (as with all other aspects of investing) are only just the beginning.  I have decided that I am most interested in taking advantage of the leverage advantage that call options offer.  In order to apply this concept, I first need to find an equity to formulate a position around.

In the meanwhile, I have been thinking that it would be very useful to have a simple calculator that accepts parameters like the option strike price, expiration date, commission rate etc. and returns back a single value for potential profit or loss.  The ones I've found are quite complex and attempt to estimate profits along a continuum with assumptions for volatility, and other "greeks".  More on that later perhaps?

What are the management implications for the US healthcare delivery and financing systems?

• One of Reid's central tenants is that the financing of healthcare cannot be a for-profit enterprise.  Needless to say, moving toward a non-profit model for this entire industry will be nothing short of a sea-change.  While it is difficult to fathom the full extent of the changes that would result from such a transformation, some simple items to prepare for may be the shift away from the focus on medical billing, more centralized negotiation on prices for supplies and services, and greater focus on mission and vision values than profitability.
• Healthcare providers will need to accept a reduction in compensation, a greater degree of scrutiny on their costs, and a greater accountability for the quality of the care they provide.  I imagine that this will drive (or attract) practitioners into more and higher administrative roles as management objectives will necessarily be more directly connected to the quality of outcomes in care settings. 
• While much has been made of the profit-oriented motivation of insurance companies, I believe medical providers will also face similar pressures to behave in an even more socially responsible manner.  Reid focuses his attention to the payor role, but I believe hospitals will face a more stringent requirement on providing charity care and proving their benefit to the communities they serve.

Is there anything I disagree with?

• Are Insurance Companies truly evil?
  • More clearly than any other point in the book, Reid paints a bright target on the for-profit insurance industry as the cause of human suffering in our country.  I can certainly appreciate that some practices that are commonplace in the individual health insurance companies can appear obtuse and in some cases even cruel.  But I think its important to recognize that these practices are in fact legal and quite well known, if a little technically difficult to understand.  
  • Rescission, for example, is not revoking someone's insurance coverage at will or because they don't feel like paying a claim.  Rescission is a measure to identify and penalize fraud.  If an applicant omits or misrepresents information that would have materially changed an underwriter’s decision to issue a policy, then that individual should not have an expectation to benefit from that type of fraud.  Afterall, if I misrepresent my income to qualify for a loan and purchase a large home, I cannot reasonably expect much sympathy when the bank repossess it after a few missed payments.
• Are the systems in other countries really "better", and can we really transplant what works abroad into our system? 
  • In a late 2009 New Yorker article on health reform, Atul Gawande talks about the concept of "path dependence" as a major reason for the state of any country's health care system.  Essentially he argues that the systems one observes today are not the product of discreet events or sheer will of any particular political party.  Rather, these highly complex systems are the result of the momentum that builds over many years and many small decisions; each reflecting the unique set of circumstances of any particular time.  
    In a late 2009 New Yorker article on health reform, Atul Gawande talks about the concept of "path dependence" as a major reason for the state of any country's health care system.  Essentially he argues that the systems one observes today are not the product of discreet events or sheer will of any particular political party.  Rather, these highly complex systems are the result of the momentum that builds over many years and many small decisions; each reflecting the unique set of circumstances of any particular time.  
  • Following that argument, I am skeptical that we have a reasonable chance of deploying the Carte Vitale next year, or that we can impose a Japanese style "source of truth" index of fees the year after that.  Rather, I think we need to drive reform by evolving our current system; jettisoning the baggage and nurturing the good points.

Can we Americans think about and answer the "First Question" as it was intended - an ethical barometer for our outlook on the question of health?

• Moral questions appear to have common understanding in these other countries.  Part of what defines our culture (and I believe is a strong reason for our success as a society) is that we are rigorously individualistic.  Inherently, we resist morality (at least I do), especially if it comes attached with a sense of a "right answer".  We are loathed to hear what we are "supposed to do".  That said, we have no choice but to drive reform in our healthcare system.  So I am holding out hope that we can achieve this reform without necessarily arriving at a univeral agreement on this moral/ethical question of right to healthcare.

Let me first introduce you to Get Set...GO!  

Think of middle school recess or those hot summer afternoons when you and your friends from the block would race to the end of the street.  Think of that free, simple feeling of just tearing down the alley to see who could get to that mailbox first (you know, that yellow one next to the big tree?).  There were no rules, and what you won was bragging rights.  

Get Set Go! revives that same simple sense of competition as a location-aware mobile game.  You pick a destination (maybe that Alterra coffeeshop two blocks over), send a challenge via sms or email to a few friends, and its game on!  Get Set Go! tracks your location, as well as your friends, and the first one to get there is checked in as the winner.  

You pick up points for races you start and join (with bonus badges for wins).  Businesses that sponsor destinations can offer prizes to winners and other checkin rewards to other racers.

Minimum Viable Prototype...

Planning is key (I'm told).  I forced myself to spend a few hours paper-napkin-ing the idea.  I developed a flow for the app (try LucidChart for dirt simple flowcharting), thought about some basic game mechanics and worked out a value-proposition for the race sponsors (ie my revenue model).  The exercise helped me land on a basic spec for the game that would allow me to get my phone out and tap on some screens as I pitched the concept to friends anyone who'd listen.

I decided to try wireframes using Balsamiq and some others, but found that for my own use, the mockups made the app much harder to visualize.  I decided to try platforms like ApplicationCraft and Rhomobile to simplify the visual aspects of designing a mobile application flow.  Now these tools are incredibly powerful, and while they do simplify certain advanced aspects of multiple platform targeting, they do come with a non-trivial learning curve.

My needs were centered around developing a usable protoype of the concept, quickly and cheaply.  I've written some code now and again, and decided that it would be faster for me to whip something together myself, and then transition to ApplicationCraft when I'm ready to refine the prototype into a more beta product.

jQueryMobile to the rescue...

Any developer familiar with the incredibly powerful and popular jQuery framework can be extremely productive extremely quickly using the jQueryMobile platform.  However!  Beware.  I was surprised to find so much of what I needed to accomplish required various degrees of hackery.  

• Cross-domain requests or Same Origin Policy woes
  • http://www.giantflyingsaucer.com/blog/?p=2682
  • Not quite a hack per se, but the whole concept of how JSONP is implemented is oddly complex, but a necessary reality in mobile web development
• Variety of mobile specific implementations of the Google Map API
  • Google's eerily awesome javascript mapping API (v3)
  • Best API to the API I've found (GMap).  Certainly consuming the Google API directly is likely the best way to go for reliability and performance, but in reality fairly routine operations like searching for markers on a map is often easier through wrappers than dealing with the core API.
• Implementing fixed headers and footers
  • Various approaches ranging from the standard to some more exotic approaches.

Now, I'm not complaining mind you!  Just cautioning that although access to the raw tools can empower you to produce workable prototypes with minimal friction, you have to evaluate whether its sustainable for you to deal with build challenges *and* business development priorities.

So what can I say about my experience so far with mobile development:

1. Plan.  Committing to a hardline spec for your prototype will bound the scope of your effort, and also go a long way in refining your best available options to deliver that desired state.
2. Build it yourself.  At least in the beginning.  You will very quickly learn the key challenges you will need to invest the greatest amount of resources into as you move further toward delivery.
3. Share it.  Its a difficult proposition, but share what you have early and often.  Its painful to hear comments like "is it supposed to look like that??", or "huh, that didn't quite work!", but you will end up directing your effort more accurately toward the right challenges in your project.  That is, the ones your users and customers care about;  and these may not be the ones you thought of first!

Kat (very diplomatically!) confirmed my comment that shape matching would not work, and then very kindly shared some specific technical information on why.   

"Your approach is a good first start, but unfortunately the Hu moment is not going to work in this situation. The Hu moment is a measure of the image moment, which is kinda like a moment in physics. Basically a moment describes how much work you have to do to get something to spin. Round things have less of a moment and spin easily, long things are a lot more difficult to spin. Moments are actually a good way to match things that are similar shapes, but not to align edges that are a like puzzel pieces."

Kat also forwarded a video of a simplified visual explanation of the math behind the Hu moments that illustrates how robust the calculations are in identifying a particular image, regardless of transformations applied to it:  http://www.youtube.com/watch?v=O-hCEXi3ymU 

Personally, I found that while the video definitely drove the point home, Kat's simple, straightforward explanation was key for me in understanding the nature of this feature.

I hope this little bit sets off a light bulb or two for others, as it did for me.  At the moment, my thinking on the first puzzle has turned to collision detection; the type you might be familiar with if you've played any old-school platform scroller arcade game.  These games determined when two polygons intersected each other, and I think the principle should apply to determine whether two puzzle pieces in the shredder challenge are a good fit.

My latest homework is to understand the Separating Axis Theorem and see if I can develop an approach based on this concept.

Forgive me if the code formatting creates issues for you.  The script is dirt simple, and should be easy to follow.  It is only a proof of concept that (usefully) gets as far as identifying the distinct blobs.  From there, I've asked it to perform a simple match and identify the pairs by coloring each of the matches the same.  Running the script produces something similar to this:

Doesn't that look a lot easier now?

This last bit is not at all useful in solving the puzzle because we are not attempting to identify duplicates in the image.  Rather we need to match each shred to a "fit match".  I have not yet figured out the math to express the "fit match", but at least I'm a step closer in this marathon.

• Intutive syntax and application
  • mysshclient = paramiko.SSHClient() mysshclient.connect('hostadd',username='user',password='pass')
  • Addressed the missing host key issue we are all familiar with directly on the shell
    mysshclient = paramiko.SSHClient() mysshclient.set_missing_host_key_policy(paramiko.AutoAddPolicy())
• Key based authentication
  • Terrific example here
  • mysshclient = paramiko.SSHClient() mysshclient.set_missing_host_key_policy(paramiko.AutoAddPolicy()) privateKeyPath = '/path/to/your/key' privateKey = paramiko.RSAKey.from_private_key_file(privateKeyPath) mysshclient.connect('hostaddr',username='user',pkey=privateKey)
• Send commands and interact with output on the remote machine
  • mysshclient = paramiko.SSHClient() mysshclient.set_missing_host_key_policy(paramiko.AutoAddPolicy()) mysshclient.connect('hostaddr',username='user',password='pass') stderr, stdout, stdin = myssh.exec_command('ls -latrh') stdout.readlines()

Brilliant.  Will be applying Paramiko to a teeny automation script that will start an Amazon EC2 instance, run a series of commands on the server (neat scraping and analysis stuff I hope to write more about), and then process some post shutdown ops.

 A little background:  At around 6:45am CST today (10/13/2010), I received an email with no message body or subject line from "Mint.com <stage-mini@mint.com>".  The message contained an single 1x1 pixel image that "phoned home" to mkt41.net - an email marketing firm that presumably tracks visits and message load statistics.  After a little Googling, I learned that Mint.com apparently sent a "flood of emails" the previous morning due to a "simple" misconfiguration of a test server "with no customer data".  Stephen Mann (Mint.com's Director - Customer Advocacy) assures us (other loyal users like me no doubt) that measures were being put in place to ensure this never happens again.

So when I received a second blank email - identical to the first - about 6 hours later, I was upset.  I then learned that many others had received a half dozen or more emails well after Stephen Mann's rather inadequate message.  As I re-read that message that Mann posted early on 10/13, I grew more upset as I saw clearly both the incompetence and the utter lack of professionalism represented in the content.  

Here are my two main issues with Mint.com/Stephen Mann's message:

• Stephen Mann's choice of language in posting "sorry for being annoying" and "We also apologize if we woke you up from your sleep! " indicates that he thinks he's managing the social presence for a brand new shiny web2.0 side project.  Mint.com manages the personal financial information for hundreds of thousands (millions?) of users.  Stephen Mann should take this more seriously.  Moreover, a $30million sale to Intuit should firmly signal (at least to Mint.com) that Mint.com has a greater responsibility to its userbase.  We should not be subject to amateurish mistakes like allowing a test server to communicate with the outside world.
• I believe Stephen Mann is either too incompetent to have correctly determined the technical details of the problem, or outright lied in this message.  If the mistake occurred on a test-system with "no customer data", how was the email delivered to my email address?  If the test system has access to my email address, what other detail exists in this environment?

My final concern is that not many people appear to be aware of this problem!  To my own tiny part, I have hooked the RSS feed for this utterly shameful feedback thread into twitterfeed.  Any updates to the forum will be pumped into my embarrassingly lonely twitter stream.

For shame Mint.com.  Cereal.

Track the Forum Here:  http://gsfn.us/t/1n67r

Gawande's closing centers around a lecture he once gave to medical students that he hoped would help guide them in their own efforts to distinguish themselves in their careers (and likely their lives in general). He offers his students 5 ideas that he feels would condition them into a pattern of behavior that would set them in the right direction:

• Ask an unscripted question: he encourages stepping outside the routine to establish a more human connection; not just with patients, but also with collegues or friends.
• Count something: in one of my favorite lines in the book, Gawande suggests that everyone should be a scientist in their world.   Counting something - as he did the number of instances sponges or tools were left behind in the body after surgeries - conditions the mind to ask the types of probing questions that invariably lead to innovation and change.
• Embrace change: he is careful to caution against blind adoption. Rather he encourages the willingness to learn, critically evaluate, and adopt new ideas if they bear merit.
• Don't complain: Gawande suggests (from his own experience) that nothing is as demoralizing in healthcare than hearing doctors complain.   I'm inclined to think that a variation of that sentiment applies equivalently to virtually any situation.
• Write something: perhaps this last suggestion was the most compelling as it motivated me to write this short blurb. I find that writing (particularly about things that are meaningful to me personally) naturally forces me to think more critically and creatively.   At the very least it has forced me to put the iPad keyboard through it's paces! (this post was authored on my spanking new iPad using SquareSpace's iPhone app.  Thanks Mona!)

I highly recommend Better, as well as Gawande's other texts (including The Checklist Manifesto, and his very insightful contributions in the New Yorker).