Drill Down, Then Zoom Out on America's Gun Violence Problem

Since the horrific events of 12/14/2012 in Newton, CT, the ever-controversial topic of gun control has flared up, as it always does after yet another mass murder in the US.

I wrote a series of tweets that I'll expound upon below.

First, acknowledge the problem. Easily obtainable global data says we do.

Drill down: Gun laws haven't helped in Chicago. Why not? What's gone wrong? The 1994 Assault weapon ban in US was a dud. Why? What can we do better next time?

Zoom out: Gun control laws in other developed countries have had dramatic mass-casualty, gun-murder, and gun-suicide rates. What worked? Why did it work? How can we make it work here?

Obviously there is a mental health care aspect to this, as well as a cultural one. Those are far more nebulous battles that will take far longer to fight, with far less clear results.

Simply saying "gun laws don't work, criminals still get guns.", without asking "Based on what?", is lazy and tells me you either don't want to do anything to curb gun death in the US, or that you refuse to believe the data right before your eyes. Be analytical, not lazy, or stay out of the discussion.

It's critical that we collect gun data that doesn't exist, as well as ask why we don't already have the data. Arguments on all sides must have data to back up their positions. David Frum, today, highlighted what pro-gun lobbies have done to prevent research and collection of data. 

The global data we already have clearly illustrates that the US is a radical outlier both in terms of guns-per-household, and rates of gun deaths. Other countries have had similar problems, have taken bold steps, and have reaped undeniable rewards for it.

We need to ask why organizations would suppress the collection of data which may directly result in decreased profits for their constituents at the expense of thousands of US lives every year.

Simply dismissing the problem, saying that nothing can be done, or making claims about outcomes of policy action with no data to back up your claims, is lazy and irresponsible, plain and simple.

Don't be intellectually lazy. Don't accept catch-phrases as gospel. Be a critically thinking person willing to analyze your own opinions and thoughts to find their roots. Likewise, do the same for those organizations who's talking points you ascribe to.

Base your opinions on data, not dogma. Drill down. Zoom out. Don't accept that there are no answers before you even lift your eyes to search for them.

Letter to Mom and Dad from an X-Skater

My mom visited recently and brought a folder full of old sports pictures, clippings, report cards, and more. One of the items was an original, cursive letter I wrote to my parents in 1986 (or so), when I was eleven.

The letter was a response to being told that I could neither skate on the front street, nor at the Cooper's house up the road. They had a full half-pipe in their back yard.

I decided to hand in my skateboard along with this letter. It is comedy GOLD.

My favorite parts are where I mention God. My second favorite is signing off the letter as "From the "X skater". The coup de gras is the picture of a board with a circle and line through it.

This is pure, 11 year old, cringe-worthy angst. Enjoy!

Beware of JavaScript Library Gluttony

While working on the CareTechSys portal today, I reached the point where I realized I was piling too many client-side APIs on top of each other.

My site uses the following client-side libraries:

• Knockout.js
• Knockout.js Mapping Plugin
• jQuery
• jQuery UI
• jQuery Json plugin
•  jQuery URL Parser plugin
• jQuery LoadMask plugin

I got to the point of adding client-side validation on some views, and quickly realized that this wasn't a trivial task, due mostly to the fact that I'm using the Knocking.js Mapping plugin. 

That plugin is a really great tool for taking json objects you shuttle over via ajax and updating the UI with them (and then to send back to the server for updating later).

The downside to using it is that it's a bit harder to do some custom things, including using the nice Knockout.js Validation plugin, or the jQuery validation plugin.

So I went down the road a bit towards using the latter, and at some point realized, "Man, I'm API pluggin-ing myself to death here." The web gets pretty tangled.

Oh, and I'd also implemented some of the nice new HTML validation features, too. Of course, given that some major browsers still don't fully support those (you'll never guess the main culprit...), I knew I couldn't rely on those too much.

So I went back and decided to, since I already had access to a very nice client-side view modelvia Knockout.js mapping plugin and my custom server side json classes, why not just do validations on those and have some error labels ready to be displayed in the html.

The result is probably less sexy than if I'd piled up yet another JS library plugin on top of the site and written some more crazy code to glue them all together, but at least the pattern is somewhat clear, and that's one less potential source "API-interaction" issues.

It seems like awesome, shiny, fancy libraries are being invented and embraced on a daily basis, and it's really tempting to use everything cool as often as possible and possibly all at once. I think I've reached a point where I've got a soft limit on the number of different third party APIs I'm going to use on a single project.

"All things in moderation". Words to live by, and that includes third party JavaScript Libraries.

Mercurial, Google Drive, and Missing revlogs

So I finally took the time to write something couldn't be done in 140 characters.

Today I was wanting to push a locally cloned Hg repo to my account on BitBucket. When I tried, I got hit with a message stating that revision logs are missing for a few files.

Googling it, I found that this means my repo was corrupt. Joy.

Doing a hg verify gave me:

data/CareWeb/jquery/demos/datepicker/animation.html.i@1: missing revlog!
 1: empty or missing CareWeb/jquery/demos/datepicker/animation.html

My first thought was: WTF did I ever check in jquery demo source? Oh well, anyway...

I started following the instructions here to fix my corruption. At some point I realized that Google Drive had renamed some of my hg revision date store files with a (1) in the file name.

I went into \.hg\store\data, found the files that had been renamed, fixed them, and that fixed me up.

In case anyone else is odd enough to use Mercurial and have their source also sitting in a Google Drive.