Translating an Ancestral Tablet

Some time ago in Toronto I purchased what I thought was an antique Chinese sign from an antique dealership. Once I had brought it home I did a bit more research on it and found that it is an old ancestral tablet.

This page covers provides some photos to provide an online reference to it and potentially bring some more information as it becomes available.  I’ve also created a Quora question to see if the smarts of the Internet can help translate or otherwise provide deeper insight into the tablet.

The tablet itself is about 45″ (115 cm) tall – not including the base that would inserted into a stand or similar.  The width is about 13.5″ (34 cm).

If anyone who comes across this page can help translate or provide more information, I’ll update the page.

Continue reading “Translating an Ancestral Tablet”

Advertisements

Using Google’s “+” Email For Opting Out and Catching SPAM

Fortunately, with strong spam catching features in most of the mail systems, the bother of spam is considerably less than it was 10 years ago.  It is clear that the perennial concern about opting out being a magnet for new sources of spam is well and truly founded.  Fortunately, you can use the “+” option for email to opt-out safely as well as getting a solid read on the how the opt-out either cuts down on or increases spam. Continue reading “Using Google’s “+” Email For Opting Out and Catching SPAM”

Converting a ChromeBook to a Dev Environment

Chromebooks are inexpensive, generally single purpose devices that are 90% of what most people need for day to day use.  Developers however need just that little bit more.  My preferred development environment includes using the atom.io text editor among other tools.

When my normal OSX development environment was not available, I re-purposed an Intel based ChromeBook to being a dev environment.  This article describes the process and some of the final thoughts.

The steps needed are

  1. Backup local storage
  2. Enable Developer Mode
  3. Install Crouton
  4. Install the Crouton Extension
  5. Install Atom

Note this gets a developers editor, but does not set up other development tools (compilers, etc).  I’ll leave this as an exercise for the reader.

Continue reading “Converting a ChromeBook to a Dev Environment”

Code and the Written Word

Code history is like a narrated history of code.  The ability for git rebase to reorder, rework and polish commits allow a developer (and code reviewers) to curate the code history so that it tells a well structured story.  This post will wander through how strongly the analogy can work.

TL;DR version in the slides.  Read on for the long form.

Continue reading “Code and the Written Word”

New #bymoonlight images

A quick photo #bymoonlight photo for tonight.

las-palmas-bymoonlight

Ambiguous Requirements in the Simplest Places (and how to fix it)

Below is a photo from New Mongolian BBQ, a favorite dinner place for the family.  This is a really interesting example of an ambiguous requirement as demonstrated by an ambiguous API.  As part of the instructions at the start of the line, a patron is suggested to use two bowls – one for meat, and one for vegetables.

IMG_20150201_184436When the patron gets to the end of the line for the their Mongolian to be cooked and they are presented with this spot for two sets of waiting customers.  The first question that comes to mind is I have two bowls.

The two immediate options that I see for what this means is

  • Customers front and back, bowl 1 and bowl 2.
  • Customer 1 and customer 2

Judging from the customers choosing randomly from the two options above.  I generally opt for bowl 1/bowl 2 if there aren’t any bowls already up when I arrive.

So how do we take the ambiguous requirement and make it mostly obvious to most patrons?  My suggestion would be to place a thick line to separate the two customer spots.  This would rely on human nature to want to have their bundled things bundled together.  If you look carefully at the picture, this might be the intent since there is already a slightly larger gap between the front and back.

Any other suggestions on how to resolve this ambiguous requirement?  Any similar simple but confounding ambiguous requirements issues that you have found?  Post a comment below.

If you aren’t yellow, you aren’t pushing hard enough.

Came across great execution: balancing order and chaos blog post by Mike Abbott on uncapitilized.com.  In particular the following quote

If the environment at a startup isn’t crazy, then something’s wrong.

This reminds me of an adage that I use fairly often.

If you aren’t yellow, you aren’t pushing hard enough.

For those unfamiliar with the Red/Yellow/Green (RYG)status colors, otherwise known as the Traffic Light Rating System (apologies for the British-isms in the wikipedia article), which is commonly used in project management to rate the status of a project.  Very quickly, here are some broad guidelines on what RYG means..

GreenProject in great shape, no issues, no concerning risks

Red Project in troubled state, needs help, impactful risks realized, late, overbudget
Yellow Project in okay to not-so-bad state, some issues, some risks, needs care and feeding, might become late, might go over budget
Green Project in great shape, no issues, no meaningful risks, no concerns… All good!

Quite often, project go through their lifecycle going something like the following…

Green, Green, Green, Green, …, Green, Yellow, Red

The optimistic behavior isn’t usually intended, it is human nature to assume that issues are under control, unknowns can be ignored, risks are mitigated and under control.   It’s only at crunch time close to the end when integration is occurring, latent issues or risks are discovered that a project moves to yellow.  Since they collapse on top of each other, the project quickly goes from yellow to red.  Project resets occur, scope is thrown out the window, crap products ship…

Realistically, a good project will ferret out risks, issues, assumptions and dependencies early on in the project.  If after a thorough analysis, the project would generally be yellow.

If the project is still green, the project is a slam dunk.  If you think it’s a slam dunk, then the team can push harder.  Pushing harder brings in some yellow through any of the RAID items above, but they also bring in an element of chaos that Mike talks about in his blog.

Thoughts, comments, counterviews?