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.  

Career bootstrapping for young people: an alternative strategy

At a Satellite coffee shop here in ABQ yesterday, I heard a guy I knew to be a successful local businessman giving a 24 year old fella advice on breaking into business after college.  He focused on how he should look, dress and act.  I kept waiting for him to get past the surficial stuff but, alas, he kept going on about how to shape shift into something acceptable to the corporate stereotype.

So, in a fit of my occassional righteousness, I stood up, looked at the the advice-giving guy and said, "Don't forget to tell him about deed" and walked to the other end of the coffee shop to continue my work.  To his credit, the business guy understood my point and immediately translated my point to the young man.

So, the point of all this is, yes, it's a good idea to start combing your hair, but it's also important to think beyond just "getting" that first job out of college.

1. Think in terms of "infiltrating" a business.  By that I mean, be determined to learn how the company works, from its ultimate business plan to how it implements that plan in manufacturing, sales and elsewhere.  Position yourself physically -- where you start in the organization.  Believe it or not, the mail room is a great way to achieve that, assuming there are still mail rooms in businesses.  As far as your "insertion point" goes, your ideal vision of that first job may not serve you best.  Ivory tower positions have their consequences.  "Big picture" ignorance is one of them.
2. Start on the manufacturing side of your ultimate goal.  From that perspective, you'll see the reality of things.  As a wanna-be software developer, I saw how the company hired hordes of young developers from colleges around the Bay Area and those kids never had any idea what happened to their software after it was handed off.
3. Then, the hard part, which goes hand-in-hand with big pay-offs, is to figure out the weaknesses in the system and find something you think you could improve.  Find a "coach" within the programming group, or general management, and tell them what you're seeing.  See if they'll advise you on a strategy.  For me, it was a fella named Mark Wong who said, "We're drowning in our current workload.  Here's a programming book.  Teach yourself how to program in our language and build a program for that missing process."

So, that's what worked for my career.  By shaving a couple of days off of how things went from design to manufacturing, I got noticed, promoted and even sent to school by the company to become a full engineer.  In today's world, if you're doing the software thing, I highly recommend you pick a company that has truly adopted the Agile methodology.  It's fundamental basis in transparency amongst contributing teams undermines the ivory tower thing.  Just make sure it's a true Agile culture.

So there it is.  I know times have changed.  But my gut tells me that this kind of career strategy is still a valid option.  Just be sure to comb your hair, for goodness sake!