Innocence is Forever

On this Thanksgiving Day, I acknowledge it's special because of the memories of family and people I've known and loved.  Oh man, the memories of hanging out with my cousins in Hillsdale, smelling the cooking of food that teased us for hours, watching the adults become child-like and feeling the camaraderie of watching football on tv, no matter how silly it sounds now, are undeniable. There doesn't need to be anything more special than that.

I also enjoy Thanksgiving because, for whatever reasons, it's one of the few days I experience peace and quiet on a personal level.  I wrote a love letter to somebody this morning.  And while I wrote it, I was enjoying a source of innocence that doesn't show up very often, especially as I grow older.

I think that's why I enjoy finding my spirituality in the universe, which to me is simply "Life."  Whether you believe in a god, one Universe, multiverses or that it's all an illusion, it's all Life. 

The immensity of it all means good news to me.  The news? No matter what, we are all innocent.  No matter how thick your skin has become and the piles of regrets equally so, you can access your innocence to be bold, to be romantic or to start over.  It's still there, I assure you.  How can anyone not feel innocent when visualizing your place in the Universe.

So that's my Thanksgiving and perhaps a gift to those who've forgotten, or never had the feeling that it's a special day.

David

Particles versus Waves -- Beautifully explained in a 7 short minutes...

... not by me, though I try below.

So the "discrete" in "discretepassions" comes from the Neils Bohr's observation that electrons can only occupy specific orbits above a nucleus.  As the video points out, that was quite a shock to Newtonian folks who believed an orbit is an orbit and orbits had no rules associated with predefined heights.

http://www.youtube.com/watch?v=a6o9XjQOvHc
"Quantum Physics and the Nature of Reality: Neils Bohr, Charles Rutherford, Werner Heisenberg

This video caught my imagination and my desire to understand concepts at a deep level.  Something that makes sense.  Something that's beyond rote memorization.

We all know about the counter-intuitive explanation of electrons and the observation that they behave both like particles and waves.

As this short video explains, the rationalization of the dual nature of neutron behavior around a nucleous is achieved by the Heisenberg Principle.  Take some light or x-ray or some form of energy to observe an electron.  Problem: the energy you use to observe with influences the electron.  It moves it, diverts it, etc.  The end result is that you can never know the exact position or the momentum of that neutron.  At least you can't know both attributes at the same time.

The result: the wave-like display of electrons around a nucleus results from the fact that we, as observers, never know the position of an electron.  Why? Because our act of observing instrantly alters the positional attribute of that neutron. What Heisenberg concluded as that the wave explanation is really one based on possible locations of individual neutrons at any one moment in time.  Consequently the wave form that represents the presence of neutrons is really the manifestation of a spread of possible locations of those electrons.

Thus the dual nature of electron behavior, as observed by us humans. 

That was fun (and hopefully accurately summed up...)!

• 
  

Chipping away at manipulating and querying mongoDB sub-documents (with Groovy/Java)

I'm building a little library of commonly needed MongoDB Groovy scripts using the MongoDB Java driver. Sub-documents are my favorite aspect of mongodb scheming. They're how I like to illustrate a core difference between document DBs and the "joining tables" world of SQL. So I figured I'd tackle storing and fetching sub-documents.

There are more programmer/java-friendly strategies such as Morphia. My preference is to start with a reasonably low level API to understand some foundation perspective before jumping up a level or two of very helpful abstraction. It's a control thing, I'm sure... ;}

It's easy to use native MongoDB javascript to create some test data, so I started with that. Below I'm using a collection called "diary". This document identifies the activities and activity dates performed by John.

mongo
> use blog
> db.diary.insert ({name: 'john'}, {'activities':[]}); // setup activities array for subsequent content updates

> db.diary.update({name:'john'},{"$push" : {"activities" : { "date" : "20130812", "name" :"Go to school"}}});

> db.diary.update({name:'john'},{"$push" : {"activities" : { "date" : "20130817", "name" :"Bird watching on Rio Grande"}}});

> db.diary.findOne({}, {_id:0}); // select all docs; don't display the _id
{"activities" : [
       {
               "date" : "20130812",
               "name" : "Go to school"
       },
       {
               "date" : "20130817",
               "name" : "Bird watching on Rio Grande"
       }
       ],
       "name" : "john"
}

I now have a key called "activities" that collects sub-documents in array form. Each item in the array is a sub-document representing a date-stamped activity, such as "Go to school", which I do every day in one form or other.

In the code below loops through any top-level documents, looking for the presence of the "activities" key. Since we're talking MongoDB, there's no requirement that such a key exists in every document. The responsibility of whatever you decide that policy should be is implemented in your code!

Here's some tested code the performs the query I've been looking for.

// main...
    myApp.dumpActivities(fetchActivities('john'))
// ...end of main

def fetchActivities(name) {
  def activities = [:]
  def q = new BasicDBObject().append("name",name)
  def cursor = diary.find(q)
  while (cursor.hasNext()) {

    def activityDocs = (BasicDBList) cursor.next().get("activities")

    # DANGER -- This loop assumes one event per day...
    for (BasicDBObject activity: activityDocs) {
      activities.put(activity.date, activity.name)
    }
  }
  return activities
}

def dumpActivities(activities) {
  activities.each { dateStamp, activity ->
    println "Activity: "+ activity + " on " + dateStamp
  }
}

So we're looping through each document looking for a match on the key "activities". When found, we use the key casting of the value associated with the activities key to create a BasicDBList object. Basically, we're treating the activity key's sub-document as the array that it is.

The innermost loop processes each sub-document as the hash (represented by the BasicDBObject object) that it is, collecting each key-value pair ("date","activity") as encountered.

So! Now I have the basis of my standard query pattern. Next post should be about inserting new activity sub-documents with Groovy.

Magic numbers at it again: approaching critical mass of knowledge as video

When I was running Lutris Technologies in the mid-90's, everybody knew I had a fascination in two things: serendipity (as it influences business) and what I called "magic numbers."  I'll write about the serendipity stuff another time... but I used the concept of magic numbers as associated with the hiring of any new employee and the eventual impact on our Lutris culture.

• The 7th employee and, all of a sudden, the need to call meetings.
• The 10th employee and, all of a sudden, the need to hire an office manager.
• The 12th employee and, all of a sudden, the puzzling interruption in the perfect flow and distribution of knowledge (amongst all of us).

It was somewhere around 20 when I realized, "geez, we need a real CEO." That's another story in itself.

But, to get back to the real reason for this posting... and that's about what I've observed recently and that observation is that video has become a true knowledge base.

My favorite example is Charlie Rose at http://www.charlierose.com When I just feel like learning something knew or wonder if he ever interviewed somebody I'm curious about, I'll go to his website and search.

It used to be that you searched for text, such as wikipedia.  I still do that.  But if I'm in a real learning mode, I go video first.

The impact?  I used to think of Youtube as a resource for music and kitten videos.  Instead, I watch videos on Quantum Mechanics or a new salesforce.com feature.  Or, as I just did, I search Youtube for videos on "defining mongodb schemas."

It's a wonderful phenomenon.  The charlierose.com is particularly interesting to me because I have always suspected his politics and social views were similar to mine.  So I know I'm going to like his questions of those he interviews.  So it's more than a site of pure knowledge.  It's one that supports an angle that I relate to.

So, somewhere along the line, in the past 3 or so years, and maybe I'm just late to the knowledge party, but one of those magic #'s was reached.  I guess it's the # that represents a sufficient # of topics (relative to my direction of personal growth and interest) supported by a critical mass of videos.  It's a curious kind of transformation because you don't realize it until it's been there for awhile.  Fun stuff.

So back to my mongo video...

David

Tackling programming in chunks

Sometimes, out of nowhere, you discover you've acquired some wisdom over the years. Wisdom, in this case, was probably inherited from my Unix/Linux background... namely, break a problem into chunks, and attack it left to right.

For example, take a list of names, sort them and get rid of the redundant ones.

cat myNameListFile.txt | sort | uniq > myUniqListOfNames.txt

Unix has a nice way of pipe'ing the output from one app or tool to the next.  As you become familiar with the available tools, you start thinking in terms of how you can sub-divide tasks.

For example, you need to generate some customer numbers from your database.  This is a one off task, though it has the possibility of being useful further down the road.

You're not sure about the SQL.  You can do it, but it's going to take awhile to figure out that lengthy thing. And feeling comfortable with Unions and Joins can be quite a challenge. So, why not do it in chunks?  Why not do it in a series of SQL calls, feeding the results of the first query into the second.

But what if that isn't quite working for you in terms of doing so confidently.

This is where a bit of bash scripting or Groovy comes in.  There are more tricks to bash shell managing SQL queries and results than you may know.  I will address that in a future post.  It's how I survived before I discovered Groovy.

Here's the strategy:
1. Create a SQL query that gets all your customers' ID.
2. Execute the query from Groovy so that you can capture the results in a list. 

Maybe there were lots of conditions applied to that customer list.  Perhaps they're the customers who are not suspended and they reside in Ohio and they're new accounts as of 3 years ago.  Simple considerations, but nonetheless, considerations that lengthen your thought process and your SQL query.

Now you can move to the next phase or chunk.  All of a sudden that grand design of a SQL query has gotten a little bit simpler.