Standing Desk Update, 2ish Weeks In

I've been using my ghetto fabulous standing desk now for about 3 weeks or so, but one of those weeks doesn't count since I was out on vacation for Thanksgiving.  So here is a breakdown of how often I've used it:

Week 1, Used it the last 2 days of the week.
Week 2, Out on PTO.
Week 3, 4 day week, used it for most of 3 of the 4 days (had all day meetings on Wednesday).
Week 4, Just started, on day 2.

So far so good.  My back doesn't hurt necessarily, but I do have to be very conscious of my posture and I do get stiff if I stand in one place for too long.  Also I find myself wanting to slouch over.  I find myself stretching more to get my muscles active in different directions instead of just one.  The only thing that hurts is my feet.  I suspect that my one year old daily wear Lands End shoes need to be replaced.  Thinking about getting some light hike/run type shoes to replace them.  I'm also seriously considering an anti-fatigue mat to help with the pressure on my feet.

Mornings are the best.  I feel good and I enjoy standing and feel like I get a lot done at work.  By the time lunch rolls around, I'm definitely ready for a break.  That seems to be one of the "benefits" of doing this.  I don't eat at my desk anymore.  It is really hard to eat and stand.

Afternoons are tough.  I find myself having more trouble focusing on work as I'm more focused on how fatigued I am, or on my aching feet.  I also end up taking more walking or sitting breaks.

It is hard to tell how it affects my energy levels.  I've also been hitting the gym a lot more lately, not to mention the sharp increase in hiking and walking.  I do feel like it has been helping greatly with my posture.  I feel my back "settle" in new ways.  My lumbars pop more when I twist, and it feels like overall my spine is aligning differently.  My awesome chiropractor told me that this would happen, and that my spine would realign with increased standing.

Otherwise, I've had no more stiffness in my lower back which could just be time healing my wounds or it could be from standing more.

I'm definitely a fan.  I do feel like I'm making a positive impact on my health and on my posture and alignment.  It is definitely worth the laughs (although, most people also say that they think it is really cool that I'm doing this while laughing at my ghetto fabulous setup).  I definitely want to continue standing.

Standing Desk Trials

Mostly for Kristopher Kinlen, but for anyone else who's thinking about doing a standup desk. Here is a bit about why I decided to try it, and what it has been like since I've switched.

First, why. I recently had a bout with severe muscle spasms in my lower back. I *think* it was my Longisimus or Iliocostalis muscle (one of the ones that goes all the way up to my neck). It was so severe that I

 could not get off of the floor for about 30 minutes, writhing in agony as my muscle seized into a painful knot about every few seconds. I've had other back problems as well, this is just the latest in a long line of issues. I also have problems with my shoulders. They get "out of joint" from time to time and I have to work them back in to get them off of my nerve. I'm fairly certain the shoulder issues come from a long career sitting (well, slouching) in front of a computer writing the codes for the computers all day. Lastly, I've put on a lot of weight since I went from working in restaurants to a sedentary job. I weighed around 165lbs when I got my first desk job. I quickly went up to (and recently past) 200.

After my last bout of muscle spams, I found it very uncomfortable to sit all day. It actually felt better to stand. I've been considering using a standing desk, but this was the last bit of impetus I needed.

I started in the middle of a week and haven't done a full week yet, but so far so good. It is tiring standing all day. One nice side benefit is I find myself taking walks around the campus about 3-4 times per day to move a little. My feet end up hurting, but I suspect better shoes will help with that. The best thing though is that I'm really and truly fatigued at night when it is time for bed. I feel like I did get some physical activity in. I also sleep better since I'm tired. I have problems on occasion with insomnia, so for me this is a GREAT side effect.

Also keep in mind that I'm not standing 100% of the day. I have plenty of meetings to go to, where I do get a chance to sit for a while.

So far so good. It is tough some times during the day, especially near the end of the day to stick with it, but I also suspect that my stamina will get better the longer I do it. It's also way to early to know if there are any noticeable health benefits.

CouchDB, Part 2 - Data Structure and JSON

Couchdb stores the documents in a native erlang format.  When it runs a view function, it runs a json encode (out of the mochiweb framework) to convert the native erlang object into JSON that the JavaScript interpreter can parse.  It runs the function on that document, and takes the output of the emit and turns it back into a native erlang object.

In this post, I will do my best to explain how the native erlang object translates to JSON, and JSON to native erlang.  The reason this is important is to know how to get values out of non-trivial JSON objects.  Most examples show how to get one level deep (proplists:get_value).

First is a short explanation of erlang objects.  There are three things you need to know about how erlang structures data.  The tuple, the list, and the bit string.  See this reference manual for Erlang data types.

The Tuple
Tuples are defined as "Compound data type with a fixed number of terms."  You'll see later that they are very similar to Lists, except the number of terms is fixed.  As far as I can tell, when storing JSON objects in Erlang, Tuples are mostly used to represent a name/value pair.  The other use is to contain lists.

The List
Lists are defined as "Compound data type with a variable number of terms."  Lists are obviously very handy for representing arrays.  They are also used to hold all of the name/value pairs stored in Tuples.

Bit String
"A bit string is used to store an area of untyped memory."  In this specific example, all strings are stored as bit strings in couchdb.  Bit strings look like this:  <<"foobar">>.  Empty strings either look like this:  <<>>, or this:  <<"">>.  Bit strings actually have quite a few more uses, but for this post we'll just stick to using them for strings.

Putting it together
So how does a JSON object look in Erlang?  Let's start with a simple example.

In Javascript:


{
_id: "article_A9CC7889-B880-1CEE-2493-1B7605619241",
_rev: "21-500f57210e2856f2bc24368555f67209",
type: "article",
title: "Phelps Wins!",
uri: "/news/phelps-wins"
}

This would look like this in Erlang:


{
[
{<<"_id">>, <<"article_A9CC7889-B880-1CEE-2493-1B7605619241">>},
{<<"_rev">>, <<"21-500f57210e2856f2bc24368555f67209">>},
{<<"type">>, <<"article">>},
{<<"title">>, <<"Phelps Wins!">>},
{<<"uri">>, <<"/news/phelps-wins">>}
]
}

Pretty simple so far.  What about something a bit more complicated, like an article with a list of tags:

Javascript:


{
_id: "article_A9CC7889-B880-1CEE-2493-1B7605619241",
_rev: "21-500f57210e2856f2bc24368555f67209",
type: "article",
title: "Phelps Wins!",
uri: "/news/phelps-wins",
tags: [ "news", "olympics", "swim" ]
}

Erlang:
{[
{<<"_id">>, <<"article_A9CC7889-B880-1CEE-2493-1B7605619241">>},
{<<"_rev">>, <<"21-500f57210e2856f2bc24368555f67209">>},
{<<"type">>, <<"article">>},
{<<"title">>, <<"Phelps Wins!">>},
{<<"uri">>, <<"/news/phelps-wins">>},
{<<"tags">>, [<<"news">>, <<"olympics">>, <<"swim">>]}
]}

And with a property that has another object as a value:

Javascript:

{
_id: "article_A9CC7889-B880-1CEE-2493-1B7605619241",
_rev: "21-500f57210e2856f2bc24368555f67209",
type: "article",
title: "Phelps Wins!",
uri: "/news/phelps-wins",
tags: [ "news", "olympics", "swim" ],
metas: {
pubDate: "2012-10-02T15:11:34Z",
author: "asmith",
description: "Phelps wins again in the Olympics"
}
}

Erlang:
{
[
{<<"_id">>, <<"article_A9CC7889-B880-1CEE-2493-1B7605619241">>},
{<<"_rev">>, <<"21-500f57210e2856f2bc24368555f67209">>},
{<<"type">>, <<"article">>},
{<<"title">>, <<"Phelps Wins!">>},
{<<"uri">>, <<"/news/phelps-wins">>},
{<<"tags">>, [<<"news">>, <<"olympics">>, <<"swim">>]},
{<<"metas">>, {[
{<<"pubDate">>, <<"2012-10-02T15:11:34Z">> },
{<<"author">>, <<"asmith">> },
{<<"description">>, <<"Phelps wins again in the Olympics">> }
]}
]
}

There are a few simple rules when going from JSON to an Erlang object.  First, the entire structure should be a tuple, containing a list.  Each item in the list should be a tuple with 2 items.  The first should always be a bit string (property name), and the second (value) can be a bit string, list, or tuple.  If it is a list, it should be a list of bit strings (an array).  If it is a tuple, the tuple should contain a list, and each item in the list should be a tuple with 2 items.  Wash, rinse, repeat.


Read your couchdb log.  It is EXTREMELY verbose and will dump the object that the view failed on.  This helps greatly when trying to figure out how the object is structured.

In my next post, I'll show you some patterns I've used in Erlang to get data out of non-trivial objects, as well as some ways to protect your view against bad data.

You've got to tell them resources is people

Bob Schatz, a.k.a. "Scrum Bob" told me once that "People are not resources."  He was very emphatic and brought up some very good points.  Namely, you don't want management to think of your top talent (and even your middle and low talent) as being something they can mine like a mineral or a tree.  They should be thought of as people with the same needs and motivators as any other person.

Fighting the urge to call people "resources" is hard.  The further you go up the chain, the harder it is to change this behavior.  The further disconnected you are from the people who would be considered resources you get, the harder it gets to see them as people.  Upper level management, executives, VP's, even directors must focus on the bigger picture.  This is especially true in a larger company.

So why fight it?  Why not work with it?

What prompted this line of thought?  I saw The Lorax with my kids.  If you've not seen it, lets just say that it is very transparent about its underlying message:  unregulated corporate greed is killing the environment.  The main message is that if you over utilize your resources (in this case, the Truffula tree) your business will fail once the resource is depleted.  No more resources means no more product.

So as long as managers are aware of this and understand the concept of sustainability the company not fail (well, at least not due to depleted resources).  I'm quite alright with being called a resource as long as I'm not mined/logged/fracked into extinction (or near extinction).

This draws a lot of analogies.

Some resources are like a forest.  During critical times, they can be heavily deforested providing wood for fire, shelter, furniture, musical instruments, etc...  The problem is, if you take trees out of the forest as fast as you can, the forest doesn't have time to regrow.  Eventually you run out of trees.  If you don't take the time to plant new trees you will wipe out an entire ecosystem.

The analogy here is that new, talented employees might start with a whole forest full of ideas.  If we constantly harvest those ideas without taking the time to plant new ones or allow old ones to germinate and grow new ideas, our new talent will start showing diminishing returns.  100% utilization is not sustainable.  Creativity and  new ideas need time to grow.

So go ahead and call people resources, as long as you understand that people and resources both need to be treated responsibly and used in a sustainable manner.

CouchDB, Writing views in Erlang, Part 1

How it started, benchmarking erlang against javascript

It all started when we needed to write some views against couchdb, and were told that we've had problems with the reindex jobs taking down our production sites.  I've always heard that writing those views in erlang would result in faster re-index time, but had not heard any numbers around just how much faster they would be.  So I decided to test this theory.  I wrote the same view in two different design documents, one in javascript and one in erlang.  The view was simple, it would just output all documents of type "article" as key="publishDate", value=null.

The results were impressive.  Calling the view after an update (forcing a re-index) against around 12,000 documents and returning about 6,000, I recorded the entire time taken from the time the call was made to the time the results had been returned.  The javascript versions took approximately 45 seconds each time I ran it with a re-index.  The erlang version only took 10 seconds.  This is mighty compelling.

For the next few posts in this series, I will walk through a few examples of how to write couchdb views in erlang.  It is not easy to find information on how to do this past the easy use cases (by easy, I mean cases where the json document is relatively flat, no recursion or iteration, etc...).  In future posts I will explore more complicated examples.

The how:

First step is to enable Erlang in your couchdb settings.  Here is how to Enable Erlang Views in CouchDB.  You'll need to add this to your local.ini and restart couchdb:

[native_query_servers]
erlang = {couch_native_process, start_link, []}

After that is added, you'll now see a the drop down in your temporary view creator include erlang as an option.

Writing a View

First let me thank some other blog posts on getting me started.  I found great information in Echo Libre Blog on writing a view in erlang.  I like the compacted version better, and after time something like that will be easier to read and understand.  For an idea on how json documents are stored in couchdb, check out this Stack Overflow question on tuples in couchdb, especially the answer from Jan Lehnardt.  Starting couchdb in interactive mode is gold.  Pure gold.  Here's another great one Stack Overflow translating views from javascript to erlang.  The answer by Dustin is a great example of how to write a view in erlang.

Also, don't forget to use your couchdb log.  I usually have a tail on that log while I'm developing these views.  The log is located under

var/log/couchdb

I'm running the couchbase server on a Mac, and it is buried under

/Applications/Couchbase Single Server.app/Contents/Resources/couchdbx-core/var/log/couchdb

Let's write that view I mentioned before, where we want to just output publishDate as the key.  Here's the json:

{
  "_id" : "d7accdc6-cefb-420b-aa30-96d3597d3b91",
  "publishDate" : "2011-06-28T17:04:16Z",
  "status" : "Published"
}

and here's the code:

fun({Doc}) ->
  case proplists:get_value(<<"publishDate">>, Doc, <<>>) of
    <<>> -> ok;
    Pubdate ->
      Emit(Pubdate,null);    
    _ -> ok
  end
end.

Walking through this easy example, we are passing the publishDate value out of the incoming document into a case statement.  The last argument "<<>>" is just an empty string, and is the default that gets returned if there is not a key named "publishDate".  I like to do this so that I can test for both an empty value, and a non-existent key the same way.  Otherwise I need to handle both cases in my matches (both cases being undefined and empty string).

The case matches are evaluated in order, and the first one to match is the one that gets used.  In this example I match on an empty string first and do nothing if matched.  In the second case, I capture the value in an atom because I want to use the value later.  In this match, I do the Emit on the value returning a row.

Last match is just a catch all.  Erlang tends to get persnickety about pattern matches, and I don't want to blow up the whole view on something unexpected.

Let's get a little more complicated.  Say we want to check the "status" key in our json for a value of "Published" before we output the row.

fun({Doc}) ->
  case {
    proplists:get_value(<<"status">>, Doc, <<>>),
    proplists:get_value(<<"publishDate">>, Doc, <<>>)
  } of
    {_,<<>>} -> ok;
    {<<"Published">>, Pubdate} ->
      Emit(Pubdate,null);    
    _ -> ok
  end
end.

A couple of changes here.  The first is to change our case from a simple value to a tuple.  Keep in mind, a tuple is an object made up of several values.  Erlang uses them a lot to represent key/value pairs (more on that in a later post).  Also keep in mind when doing pattern matching in Erlang that you can match against complex types like this.  So each of our case matches will check the values inside of this tuple.

The first match is going to check for a status of anything and an empty pub date.  Remember, we still want to throw those away.  The second match is going to match any document that as a status == "Published" and capture the publishDate.  The last case again just throws out anything that doesn't match the first two; including rows that have a status of something other than "Published".

That's it for part 1 of writing views in Erlang.  Check back for Part 2 where I'll explore more complicated cases such as getting values deeper than one level in the json document, using regular expressions to extract values from a string, and emitting more than one row for each record.  The last one comes in handy when trying to extract multiple tags in a document into distinct rows.