Living in Apple Land

As a long-time Windows developer and user (started writing Windows programs with Windows 3.0 and Turbo C++), I thought I'd share a little bit of my experience since April switching to a MacBook Pro. The contributing factors were an aging Dell E6400 with maxed out 8GB of RAM and the need to run at least two virtual machines at the same time as our core development environment.

The MacBook Pro is a circa Spring 2012, 15" display with 250GB drive purchased through Amazon. I bought it with 4GB and then upgraded it to 16GB for $250 from Newegg. I have not yet replaced the HDD with a 7200rpm 750GB, but its only a matter of time.

Ostensibly the reason for this shift from Windows to OSX was that the 16GB would allow me to run two VMs and still use the host, all with acceptable performance. In a nutshell: this works. Certainly there is a performance hit for doing this, but the VMs are acceptable for development and database work, and the host runs quite smoothly.

Some details on the environment:
OSX Lion 10.7
16GB RAM
VMware Fusion 4.1.2
VM#1 is 64 bit Windows 7 with Visual Studio 2010 and 8GB RAM
VM#2 is WIndows Server 2008 R2 (64 bit) running Oracle 11G enterprise with 2GB RAM
(leaving 6GB for OSX)

The Pros:

• Runs two or three Windows VMs quite easily at acceptable speed without tearing down the host.
• VMware Fusion integrates the use of Windows apps into OSX so that you can get by without Office for Mac. VMs created from Workstation came into Fusion without a hitch.
• Cisco VPN support works fine within the VM
• OSX is unquestionably more pleasant, fluid, and faster than Windows 7 (even for me)
• Desktop switching is really easy and efficient

The Cons:

• Cisco VPN support on Mac seems like false advertising to me: I can't ever get it to work.
• For daily use Mac Office 2011 is much better than using a VM, but it's a culture change like anything else in Apple Land. Hated the ribbon bar? Well they redesigned it yet again for Mac...
• VMware Fusion is not as robust as Workstation (Windows version). Its buggier, and forget about port mapping, there is no tool: you have to hack the file system.
• The Mac refuses to disassociate resolution of my dual monitor from the Mac laptop display (keeping the monitor at low res).
• Skype is different on the Mac (can't separate conversation windows). Somebody thought it was better this way, but that isn't me.
• Chrome has some flakey issues with web service stalls, but I use it almost 100%  of the time and for me it has been quite stable.

The Summary

This turned out to be a good move for me. I had been "counseled" by friends to go this route, and the bonus is that as we move into native iOS development I have been able to use xCode on the host. There is event a native Tortoise client (we use Mercurial for version control) for the Mac. In fact, I have found many native clients for the Mac like Filezilla, Office 2011, Skype, Microsoft RDP. Still, as a Windows developer the general reliability of VMware Fusion has been the saving grace of this switch.

Anything I can't do in OSX, I can do in the Windows VM...

Life is good.

Artful Making

My professor and friend, Lee Devin, has started a blog on innovation and collaboration here.  It's good reading, and very applicable to the software industry and other product development fields.

Lee is a Theatre guy, but don't let that frighten you; as Lee would tell you, the Theatre has attributes that are enviable from any product development field:

1. The product is routinely delivered on time and within budget.
2. The end date is known from the very beginning (the curtain will rise, and there better be a show!)
3. The product isn't fully understood until the day it is finished, and can continue to change thereafter.
4. Collaboration from every participant is necessary to make the product.

He'll be updating his blog every Monday.  Add him to your list.

And add us to your list while you're at it.

Music, Running, and Creating

Earlier this week, Christopher sent me a link to a video presentation by inventor Bret Victor. I found this particular talk to be brilliant and entertaining. Most important, it inspired me into doing something different. How this happened I can not say. One minute I was walking the dog and thinking about the video, and the next minute I was wondering about... running.

Huh? If you are looking for the thread of this post, hang in there.

About a year ago I started running. At the time I was terribly out of shape and coming out of a crazy stressful set of commitments which consumed way too much time. I took the end of that as the start of getting myself back together: eating better, losing some weight, getting a lot more exercise. It's turned into something bordering on obsession as I am now training for my first marathon and don't hesitate to run at 6am in the dark and 10 degrees.

But I digress...

Along with running I have developed an interest in minimalist or "barefoot" running. One of the tenets of this mode is that you need a high "turnover" rate, as measured in steps-per-minute. The idea is to reduce time in the air and impact by using shorter strides at a higher frequency. The problem is that this is actually pretty hard to do, because runners have a basic form, and adjusting it can be a bit uncomfortable. The ideal rotations translate into 180 steps-per-minute (SPM) for accomplished endurance runners.

For reasons I can't explain, something in the video caused me to start thinking about timing and feedback and rhythm and...running. The next thing I know I am off on a hunt for music that has the "ideal" beats per minute (BPM) of 90 (two steps per beat) or 180 (one step per beat). This is actually a pain. The music is random lists by others who found it, how exactly???

From there I am discovering that DJ's actually use BPM data for tracks to blend them without interrupting the flow of the dance (duh, I don't go to many dance parties obviously).

Where do they get this data? Software! Inexplicably, lame music tools like iTunes don't provide BPM data analysis (booh!), but there are other tools that do, like MixMeister.

And magically, now I have a list of songs from my digital library that match the correct tempo to train for barefoot running. Create a playlist, and away you go!

At this point, somebody is expecting me to start writing about Fourier Analysis and codecs, and how I hated the fact that these tools don't actually do a great job of interpolating the BPM data, nor do the free ones inject it into the metadata of the audio file so that iTunes can display it. Well I'm not going to, hah!

The key to this experience was the speed at which the idea occurred and that I could get feedback on whether it worked (it does for me). If I had to build my own waveform analysis code, then study audio decoding libraries, and finally how to write audio metadata, and then choose what tools to build it with, and write, compile, and test it. Oh dear, I don't have time for that next run, do I???

The lesson for me here was that the speed with which I could think of something and then try it out mattered a lot. As Bret said: ideas are precious. Too many barriers kill them.

As software developers, we should try to remember that what we design for users will control how they use it, probably more than we would like. As users, we should rebel against those constraints. As both developers and users, we should strive to bring software to the point where our end users feel like the tool is enabling them to create their ideas, not defining the boundaries around them.

Javascript Object and Variable Scope

We've been trying to come up with a template for building Javascript objects successfully as we transition from using .NET WebControls to a UI entirely written in Javascript.  We came across the following interesting example of how Javascript variable scope can sometimes be frustrating and confusing.

Consider the following Javascript object definition:



myObjCreator keeps a single variable in scope, and then provides a single selector and mutator for accessing that variable.  It also exposes the variable directly, and this is where the fun begins.

If you believe that variables get passed by reference when assigned to Javascript objects, you would expect to see the following output:
  1
  1
  2
  2
  3
  3

However, if you click the handy dandy "Result" button above, you'll see the output is instead:
  1
  1
  2
  1
  2
  3

What's going on, here?!?

This appears to be proof that assignment to a Javascript object is done by value, not by reference.  Meaning that myObjCreator's internal variable x and the variable o.x are not references to the same internal memory location.  They are different variables.

Here's another example that proves this beyond a doubt:





After assigning x to ret, we modify x to 5.  Yet, when we look at ret.x, it still has the value 1.  So when we did the assignment of x to ret, what was stored was a copy of the value of x, not a reference to the variable x.

Our solution to this problem is to structure our objects to address internal and external references to public variables the same way.  To correct our example, we would write:




Now we get the output we originally expected.

And there was much rejoicing.

The Importance of Being Quipped

Not too long ago, we switched from Bugzilla to Fogbugz as our issue tracking system. I say "not too long ago" because I'm trying hard not to remember the whole incident too clearly. I'm sure I agreed to it, that's the way we do things: as a team. Nonetheless, as with most technology stack shifts, there are both unintended consequences, and unexplained ones (ahem, you know who you are). Now don't get me wrong, Bugzilla and Fogbugz are both fine defect tracking solutions, and we have benefited significantly in our SDLC from Kiln's Code Review features (which are actually the primary reason we switched).

Nonetheless, I have my regrets. There is something comforting about old tools, and I don't think software developers are immune to the easy comfort of the well-loved chef's knife or hand-saw. Oh sure we "thrive" on change and PROGRESS, but underneath, we suffer the obscenities of EMACS and Microsoft Office Ribbon Bars, every bit as much as the normal application user.

All of this has nothing to do with this post however.

Well except for the intro line.

You see Bugzilla had a feature which turned out to be (for our team) even more important than case tracking. This feature turned out to be the very foundation of our team knowledge, wisdom, and humor. And the moment it was taken away (because it didn't exist in Fogbugz) we began the slow inexorable slide towards... well, being boring. If you are a software developer, date one, have a sibling who is afflicted, or (god help you) are married to one: then you will know this: we don't tolerate boredom well.

So I made a "request" (which probably sounded like a demand, but was in fact For The Betterment of The Team, honest) that we bring this feature into Fogbugz; thereby improving the product, recapturing our institutional wisdom, and most importantly, adding a respectable veneer of sophisticated humor back to our daily plod through defects which others have thrust upon us. Like a superhero without a cape, Christopher swept down upon Fogbugz and created a JS plugin which has become the analogue to Bugzilla's Quip feature.

If you have never seen this feature, a picture is worth a {for(int i=0;i<1000;i++)} words:

These little snippets of philosophy, wisdom, existentialism, or ridiculousness are defining characteristics of what I think of as our team. They leap out at us every time we look at an issue. In their absence, the world is somehow less friendly, bright, and human. Almost every day, quips are added based on Skype messages, emails, phone conversations, meetings, whatever. Sometimes they make me laugh, sometimes they make me regret being too fast on the send button, but always they remind me of what a wonderful experience it is to work with people whom I respect, who aren't afraid to speak their minds and share their day.

I have often succumbed to (and regretted) the temptation of using the term "personalization" to mean "application configuration specific to a known user account". YUCK. That is just customization of a more or less friendly UI, but there's nothing remotely personal about it. Quips on the other hand, are true personalization. Tied to personalities, expanding your knowledge of others and encouraging self-evaluation.

As a developer, team member, and manager, some of my favorites show that our team's intent to collaborate is alive and well:

Phil to David: This is the only corporation in America where the vice president cleans out the fridge


David to Steve: you were right. I was wrong. Don't tell anybody. Steve: K.


Christoper to Steve: David was going to show me... then he saw a squirrel


David to Others: Do I need to join this meeting to suck the fun out of it?


These make me smile, they also make we wince. What makes them funny is they are also true, and the good-natured acknowledgement of both fault and opportunity to get better is what makes us more than just a team, it makes us an improving, enthusiastic team. We tease, we lend criticism, we self-deprecate, we connect.

By the way, we also have a wonderful bunch of Quality Assurance folks who keep us honest, and are also a part of our team and our success:

Dev1: there are a heck of a lot of re-opens... QA1: Duh Sherlock!! You didn't fix them right.

The QA mantra - Please don't say "It works for me", Please don't say "It works for me", Please don't say "It works for me"

I guess in the final analysis, Quips may not be the most critical feature in our issue tracking system, and they certainly aren't the most effective way to archive and convey SDLC knowledge. Quips are, however, profoundly important because they tie us together on a truly personal level, and in the end any good team is more than the sum of its skill sets.

I am more productive, more tolerant, more motivated, just more because of knowing the others I work with.

And so I leave you with one more tidbit from our central repository of all known knowledge and wisdom:


I'd rather write with pen and paper, scan the document using OCR, and then edit the resulting image using Windows Paint than use emacs


Well, they can't all be beauties.

Post-Peak Society: Dystopia, or Opportunity?

The other night, my wife and I took our girls to our local bookstore. While I was browsing the photography books with my older daughter, I heard my wife call out, "Oh, Phil, here's something that's right up your alley."

Sure enough, James Howard Kunstler's novel The Witch Of Hebron articulates almost word-for-word the dystopic vision of the world after petroleum that I have been agitating about with my friends and colleagues for several years now. Here's the description from the inside cover:

Kunstler expands on his vision of a post-oil society with a new novel about an America in which the electricity has flickered off, the Internet is a distant memory, and the government is little more than a rumor. In the tiny hamlet of Union Grove, New York, travel is horse-drawn and farming is back at the center of life. But it’s no pastoral haven. Wars are fought over dwindling resources and illness is a constant presence. Bandits roam the countryside, preying on the weak. And a sinister cult threatens to shatter Union Grove’s fragile stability.

True as Kunstler's novel is to my worst boom, gloom, and doom diatribes, I recoil from reading it. And only in part because I know better than to read such things before bedtime.

First of all, brooding about such a dark future doesn't lend itself to the healthiest mental and emotional state. Imagining the worst contriubtes to fear, anxiety, and just plain moodiness: at some level of our being, we believe in what we imagine.

More importantly, what you imagine sets your overall direction in life. In place of the fear and cynicism of Kunstler's vision, why not embrace the idea of shifting, as activist Joanna Macey describes it, "from the industrial growth society to a life-sustaining civilization."

As the high cost of petroleum makes shipping food from places as far away as China impractical, for example, local agriculture could return to being a more significant portion of our food supply. Reliance on local food sources, in turn, would lend itself to a higher quality of connection with the people in our immediate surroundings. It would also make us more conscious of the quality of our immediate environment. Who would tolerate fracking knowing just how precious those local water and agricultural resources are?

You don't have to get discouraged by the level of effort necessary to steer an entire civilization in the right direction. You only have to see the change in your mind's eye and take small steps towards living that change. Macey describes the challenge as "The essential adventure of our time." Indeed.

Don't get me wrong. I still believe that we're in for some rough spots in this adventure. Go ahead and stockpile your flashlights, batteries, food, and wind-up radios to prepare not only for a Katrina-scale weather event, but also for the rolling blackouts and unpredictable region-wide power outages that peak-oil will bring. (I recommend The Ultimate Suburban Suvivalist Guide for a full picture of how to prepare in a reasonable way). But, the difficulties can give way to a better future -- if we dare to imagine.