We’re off at the crack of dawn tomorrow morning, [[Catherine]], [[Oliver]] and I, to fly to Munich by way of Halifax and Philadelphia. It’s a late fall vacation; maybe too late for crisp fall weather, but a vacation nonetheless.

Munich is the destination simply because that’s where U.S. Airways would fly us most cheaply in continental Europe closest to my current obsessions.

From Munich we immediately hop on a train for Basel (obsession) where we spend three days, then fly to Venice (another economic decision: 75 EUR for the three of us, taxes included) for three days (obsession, with likely some art on the side for others’ obsessions), then take the bus to Ljubljana (it’s surprisingly hard to cross from Italy to Slovenia and this was the handiest way) where we’ll overnight and then rent a car and head down into Croatia to look up some long-lost relatives (somehow navigating through the fact that we speak no Croatian and they no English) before coming back to Ljubljana, and taking the train back to Munich. The end of the trip is 2 days in Munich before we fly home on December 9.

It’s certainly not “slow travel,” and it’s the first time in a while that all three of us have traveled together.

I may pop in here on occasion; my new-fangled SIM card from Telestial claims to be able to automatically update this Travel Journal with our current location once a day and I’ll likely be unable to keep myself from tweeting from time to time.

Of all the projects I’ve had a hand in over the years, my absolute favourite is My Local Almanac, a “make your own Old Farmer’s Almanac” application that’s available for sale on Almanac.com.

My Local Almanac had its roots in conversations many years ago with my friend and colleague the late John Pierce, Group Publisher of the Almanac – John was the project’s cheerleader, and it was his enthusiasm for it, along with the patience of Almanac staff who walked me through the data itself, that got me through the many and varied complicated bits from concept to product.

The printed Old Farmer’s Almanac is a wonderful analog tool, but its one limitation is that, because its tabular material is produced for a single geographic location per edition (Boston, Atlanta, San Francisco and Halifax for the U.S. National, Southern, Western and Canadian editions respectively), to be able to find the sunrise, or the next high tide or other information for other locations requires using the look-up tables at the back of the book.

While this need to do a conversion isn’t necessarily a bad thing – some would say it’s part of the fun of using the Almanac, and it’s certainly educational – it doesn’t make the publication as useful as it might otherwise be.

Enter My Local Almanac: we take a location you enter – either a ZIP or postal code or a city and state or province – and create a 13 month customized set of tables fit specifically for that location that we deliver to you as a PDF file. Take a look at this sample, for Dublin, NH for this month (click the image for a larger version):

Comparing this to the information you’ll find for November 2010 for Boston – the location you’d have data for if you bought the national edition of the Almanac – you’ll find that while the sun rises at 7:17 a.m. on November 1 in Boston, it rises at 7:22 a.m. in Dublin.

To find that out in the printed Old Farmer’s Almanac you’d first look at what we call the “left-hand calendar pages” for November 2010 and find the day in question:

Then, noting the “Rise Key” value of D beside the time of 7:17, you’d turn to page 236 where you’d find the nearest town to Dublin, in this case Keene, NH, and find the conversion under column D, in this case +5 minutes:

You’d then take 7:17 and add that 5 minutes to get 7:22.

It works. But having a My Local Almanac means you can skip that calculation and have information for your location right in front of you.

Behind the scenes of this product there’s a whole lot going on.

First, we’re using Drupal and Ubercart to power the Almanac.com General Store; when you enter your location when purchasing the product we take that information and save it and then, when you complete the purchase, we have some hooks that trigger the generation of your customized PDF file.

The PDF-generating magic is done on a dedicated server that takes the location you entered, converts it into a latitude and longitude, and then produces the data for each column for each data of the current and following 12 months. As you might imagine, making this all work required learning a lot about astronomy and astrology, and that afforded me the opportunity to work with both the Almanac’s own astronomer and its astrologer, fascinating people in completely different but obviously overlapping disciplines. Some of the calculations are done in PHP, some in Perl.

Once all the data calculations have been made, we use the (excellent) PDF-creating PHP class from New Zealand to burn the PDF files; once we have all 13 PDF files created we merge in a custom title page, a guide to the data, and end up with a final PDF.

Miraculously, all of this only takes about 20 seconds, meaning that by the time a customer’s placed their order and received an acknowledgment email pointing them to their file for pick-up, it’s likely already there.

My Local Almanac is on sale now at Almanac.com for $2.95 (US). If you purchase a copy, you’ll not only make me happy, be supporting an Island company in the process, but you’ll know when the sun and Moon are going to rise and set, when the next high tide will be, and a variety of other data points, every day for the next 13 months.

The issue of shopping on Sundays has reared its head here on Prince Edward Island again, with the introduction of a private member’s bill by Hon. Olive Crane, An Act to Amend the Retail Business Holidays Act.

And again the same forces are speaking out: it’s a freedom thing, they say; we should be able to shop whenever we want. And the news is full of person-on-the-street interviews and suggestions that there’s overwhelming support for abolishing the law that prevents unfettered year-round 7-days-a-week shopping.

But there’s a reason we don’t choose to govern ourselves by instant online poll: government is where we look to nourish our better selves; the filter of representative government allows other factors than “everyone wants it” to be considered. It allows for the broad view, the long view, the systematic view that places instant desires for fulfillment secondary to the greater good of the community.

This is why we have mandatory free public schooling (“forcing kids to go to school”), mandatory speed limits (“forcing everyone to drive slowly”), liquor laws (“forcing everyone not to be drunk all the time”) and universal health care (“forcing me to to pay for my neighbour when he gets sick”).

I don’t think shopping is bad. But I think that it’s healthier for the community to have a single day every week when, as much as we’re able, we move away from shopping and concern ourselves with other pursuits. This isn’t about God or Jesus, it isn’t about “family,” or a “day of rest.” It’s simply about a mutually agreed upon day when commerce is removed from the equation.

This indeed does involve a limiting of our “freedoms” and prevents everyone from a full exercise of their “right” to shop all the time if they so choose. But that’s an inevitable by-product of a system that is based on living in community; our individual rights are placed secondary to the collective long-term good.

A 2008 Guardian op-ed piece on this topic, Sunday shopping: how we got where we are, by Dr. Pamela Courtenay-Hall, remains the most cogent argument I’ve read to date, and its stand out paragraph remains:

Further, to construe ‘individual liberty’ as being primarily about ‘consumer choice’ is to misconceive the fundamental role of individuals in a society. It is not to consume or to own stores. It is to build a good life in community with others.

And she concludes:

Make no mistake about it. There is a battle of giants going on in our time, becoming only more intense as Wal-Mart enters the field of grocery superstores in Canada. All of them are competing to become The One – our one and only source for food, clothing, toilet paper, drugs, small appliances, and on and on. Unless we engage in civic action to preserve local economies, we will become their helpless dependants, relying on their suppliers and their underpaid workers in countries overseas to feed us. To say no to Sunday shopping isn’t going to save our communities from the fallout of globalized capitalism. But it is to exercise the kind of community intelligence and local control that can.

That is the broad view, and I hope our Members of the Legislative Assembly have the courage to consider it and to vote against this bill.

All of the components needed to set my Prince Street School raffle tickets were in place today, so I was able to set all the type and lock everything in place. Here’s a comparison of my original sketch (at the top), a digital mock-up (in the middle; created in OmniGraffle on my Mac and printed on an HP ink jet printer) and the first draft of a ticket printed on my Adana Eight Five letterpress (at the bottom):

I gotta say that the internal Gill Sansness of the analog Gill Sans certainly shines through in the letterpress; it just seems right. And the numbering machine (it came set to 31 – I didn’t actually print 36 copies to get to this one) is everything I hoped it would be.

My favourite part of setting the type was the opportunity to use the ligature for ffl, which I was happy to see came as part of my M&H type.

Here’s what the type to produce the ticket looks like:

The only problem is that I mistakenly ordered two 12 inch lengths of perf bar forgetting that perf rule has to be hard steel so as to be able to make perforations. I need a smaller piece to fit into the mix, so [[Catherine]]’s going to have a go at it tomorrow morning with her special jewelry tools with hopes that I can pick things up Tuesday night. Stay tuned.

I’ve printed the tickets for the annual Prince Street Home and School Association’s Christmas raffle for the past 2 years using a simple “design in OmniGraffle, print at Staples” technique. This year I decided to try out my newly-delivered Gill Sans (from M&H Type) and do the 2010 tickets as a letterpress job.

I’ve got a numbering machine and some perf rule (to let me number and perforate the tickets) on the way from Don Black Linecasting; in the interim, I roughed things out on paper for a 5 inch by 2 inch ticket, and set the left-hand-side type in 18pt. and 12pt. Gill Sans:

The green Christmas trees are a rubber stamp I bought at Michaels yesterday for $1.50; as I’m only printing 300 tickets, it seemed reasonable to add a bit of colour to each by stamping them individually after printing (it may seem less reasonable once I’ve stamped all 300).

Tickets will be available in December at the Charlottetown Farmers’ Market and the draw date is December 18, 2010. I hope to have all the tickets printed and ready by the time I take off for a two-week vacation at the end of this week.

I’ve really enjoyed the six-part television series Circus that’s been airing this fall on PBS (it came to an end this week, but you can watch the entire series online). It’s beautifully photographed, and contains a nice mix of circus action and personal stories. Worth a watch.

This is a picture of a situation that, in the world of pedestrian traffic signals, should never happen: the “walk” signal is still counting down while the light for cars is red, and the light for cars crossing is green. It’s at the north-east corner of Prince and Grafton Streets in Charlottetown, and it’s a signal that’s been problematic for at least a month.

When the signal first started to fail, it would count down from 50 seconds while the light on the other side of the street would count down from 30. And then, suddenly, when it had counted down from 50 seconds to 30 seconds, blamo, it would turn red, despite the fact that pedestrians might very well be mid-intersection.

I’m the kind of person who sees things like this and immediately runs a thousand mental scenarios, most of them involving frazzled parents with multiple children, that all end up with someone getting run over by a transport truck; many Charlottetown drivers don’t pay attention to the signals when they’re working – who knows what happens when they’re broken.

And so I immediately called the City of Charlottetown Public Works Emergency After-Hours line, thinking, naively it appears, that they’d send someone right out: even settings aside the possible real dangers, traffic lights only work because we believe in them, and as soon as there are cracks in that, everything starts to fall apart.

And, besides, if the pedestrian signals were malfunctioning, who’s to say that the signals for cars, presumably controlled by the same box, wouldn’t start misbehaving too, and then you’d be talking about doubly real problems.

I waited a few days for the problem to be fixed. It seemed to correct itself, at least partially: the countdown timer stopped working completely. Then it started up again. I waited another week, and then sent a follow-up email to Public Works. I got a quick reply – “We have asked our electrical contractor to review and seek repair.” – and then nothing.

That was 10 days ago.

This morning I emailed the chairs of the Police and the Public Works committees, as well as our new councillor for ward one, and I just heard back from the chair of Public Works, Terry Bernard:

I have received word that the pedestrian signals are malfunctioning and can not be repaired. We ordered new ones today due to arrive Tues next week and will be installed then.

While it’s nice to hear that the problem has been identified and will be solved, surely a problem as serious as this shouldn’t take this sort of effort to get solved, should it?

Newly arrived from M&H Type Foundry in San Francisco, Gill Sans in 18pt. and 12pt., caps and smalls. Never have I been so excited by the delivery of lead by post.

For almost three years we’ve been using Trac as a project and issue management application in our work with [[Yankee]]. This after many years of experimenting with other systems, some homebrew and some open source, none of them satisfying.

Trac hits the sweet spot for our team between comprehensiveness and brevity (nobody wants to fill in a 3-page form just to submit a bug report, but we do need a basic template of information to be efficient).

What this means, day-to-day, is that any work that any member of the web team, inside Yankee or outside, is going to take on gets an “issue” (aka “ticket”) created for it, using a web form that looks like this:

With any tool like this, one of the key pieces of information is how work gets prioritized (it’s the “Priority” field in the form above). And how this is handled generally depends on whether you’re on the “client” or the “server” side of the issue – the person who needs the work done or the person who’s going to do the work.

The simplest way to handle this is by simply assigning a ranked priority: priority 1 jobs get done before priority 2 jobs, and so on.

The problem with this is that while it allows for relatively fine-grained control on the client side, it tends to make programmers and designers feel “boxed in” by a strict order of operations. (Programmers and designers, as a rule, don’t like to be told “okay, work on this now.”)

To deal with this, we’ve come up with a system that gives the “clients” enough information about when their issues will be addressed (right now, soon, someday, never) and gives the “servers” (programmers, designers, QA people) enough flexibility to have a self-directed workday with some variety.

We’ve evolved a set of priorities with Yankee that work for our team; to keep things as simple as possible we add new priority settings with some reluctance, and only if everyone’s in agreement. Here’s what we use, and what each priority means in practice for us:

Discuss at Scrum: We have a weekly conference call with all members of the team present, to go over the issue queue, and assigning this priority means “we need to be sure to have a discussion about this,” generally because there’s some question about the issue or its priority. This is the priority we added most recently, and it’s saved us a lot of time at our weekly call because we don’t need to review the status of every ticket, only the ones here.

Critical: Drop everything else and work on this right now: there’s a problem with code, design or infrastructure that’s breaking something; we work on critical tickets to the exclusion of everything else.

Need Feedback: Generally a place for issues to go after work is essentially complete but before closing them. We put issues here when the person doing the work is finished, but before the issue is closed, if there’s some question as to whether the issue was really addressed, or if further information is needed. It’s a sort of short-form way of handling “Dave, please take a look at this and if everything is okay you can go ahead and close the issue out.”

Specific Date: If something absolutely has to happen on a specific date – a campaign released or a contest turned off, for example – the issue goes here. We have a “due date” field for issues that need to be completed by a certain date, this is for situations that are time-sensitive and need to happen on a specific date. It’s the least concrete of priorities, but it’s served a useful purpose for us.

Blocked: Issues go here if work can’t move ahead, either because some amount of time has to pass – we implement a change and need to wait a few days to see whether it worked – or because some third-party needs to take action before we can proceed.

In Progress: I’m working on this right now.

Two Weeks: We have a two week development cycle, and so work to break down all projects into bite-sized chunks of 2 weeks or less. Giving an issue this priority means “we’ll work on this issue during the current two week cycle” and it’s really the heart of the prioritizing system from the “doing the work” side of the equation because it allows us to treat all items with this priority equally, creating a sort of “smorgasbord” from which we can chart our daily work routine.

Coming Soon: An issue that’s “on deck” for a “two weeks” priority, but that we’re not ready to start work on yet. There’s an ever-present danger of issues languishing here forever, and if there’s a weak point in our system it’s that we need to be more disciplined about revisiting issues here regularly to prevent that from happening.

Accepted: An issue that we’ve agreed will be worked on someday, but that’s not being worked on right now, and it’s “on deck” for work soon. At worst this is where issues go to die, but we’ve been pretty good at either marking an issue as “won’t fix” and removing it entirely if we know we’re never going to work on it, or putting it here if we know we really are going to work on it, just not right now.

Proposed: All newly created tickets that aren’t “critical” start here, get discussed by the whole group at our weekly meeting, from which they either get rejected (marked as “won’t fix” or “duplicate”) or assigned another priority. Having this be the single point of entry for tickets is both a good filter and means that everyone’s eyes are, at least at the very beginning, on every ticket that gets created.

This list of priorities has evolved over time – the last item on the agenda of our weekly call is a “process review” where we talk about things like this. The most important aspect of the system is that there’s a shared understanding of what each priority means (so that, say, “this is really important to me” issues don’t get mis-prioritized as “critical”); the most challenging aspect is convincing everyone on the “client” side that when we say “two weeks,” it really means “two weeks” to the point where they can be comfortable enough to trust the system and not develop a out-of-Trac side-system for maintaining the “real” priorities.

When I compare “life with Trac” to life before, I can’t say enough about how it’s improved our long-distance working relationship with Yankee, and, I think, the efficiency of the web team inside and outside Yankee as a whole.

I see having some issue management that’s not “categories in my private email inbox” is a vital part of every project I take on now (to the point where I’ve sometime wished for “Trac@Home”, a system where I could maintain issues like “get glass for front door fixed” and “pick up milk”).

I took my new Reinvented logo engraving out for a ride this afternoon, printing it on 200 lb. Crane Lettra card stock. There was a small issue with the “bottom swoop” that I think I can solve by adjusting the pressure and the press packing, but otherwise it turned out very well: