Posts

I have been experimenting with various productivity hacks lately. I
feel like I’m already fairly productive, based on tracking the amount of
work I accomplish week-to-week. So instead of trying to do more, I’m
trying to maintain the same level of output with less effort (and
hopefully time).

One of the top tips I have seen repeatedly is to reduce the amount of
time spent checking email, and only check it a couple of times per day.
I’m not sure I’m ready go go that hard-core, yet. Our team is spread out
and relies heavily on email for communication. Most of the messages are
important, and there aren’t too many that I feel like I have trouble
keeping up. The biggest issue is that they can be very time-sensitive.
Our code-review process is triggered via email messages generated when a
ticket is given a specific status in trac. If one of us does not notice
the change, the author of the change might be blocked for some period of
time from doing dependent work, until the code review can be completed.
Since we want to encourage code reviews, we don’t want those blockages
to last too long. So, I can’t turn email off entirely. But I can dial it
down fairly far.

Besides cutting down on email during the week, I also want to break
myself of the habit of checking work email over the weekend. Working for
a startup, it is too easy (for me) to get sucked into giving up weekend
after weekend. This is draining, so I’m not as fresh during the week as
I would be if I avoided the work mail. But, I don’t want to give up my
personal email at the same time.

So, the question is, how do I strike that balance?

The first step was to decide what my new mail schedule would be. I
tend to get up fairly early in the mornings, and enjoy breakfast on the
patio when the weather is nice enough (it rained last night, finally).
This is relaxing time, but not especially conducive to the long
stretches of deep thought needed for development or debugging. So,
mornings are a good time to do a lot of email, instant messaging with
the rest of the team, review code or documentation, and the other sorts
of tasks that don’t take hours at a stretch to complete. Afternoons are
too warm to sit outside and think anyway, so I move inside to work on
coding projects then. That gives me a schedule: I am willing to have
more interactions (and interruptions) in the morning than the afternoon
and I want to “reclaim” weekends. The next step is to tell Mail the
news.

I use the same email client (OS X’s Mail.app) to access all
of my mail accounts. Even though I use IMAP, this lets me read and
search old messages when I don’t have access to the network. The
brute-force way would be to manually change the preference “Check for
new mail” to the appropriate schedule. I hate doing things like this
manually, though.

I’ve done some work with AppleScript and Mail in the past. This
week (I’m not sure why it took me so long to figure out this approach) I
realized I could use AppleScript to control how often Mail checks for
new messages, and which accounts are checked.

Now that I have a general schedule identified, I can configure some
events in iCal using AppleScripts to control Mail. I began by composing
a few AppleScripts in Script Editor.

To check mail frequently in the morning:

To check mail infrequently, for the afternoons:

To turn of automatic checking entirely in the evening:

To disable my work account for the weekend:

To enable my work account on Monday mornings:

With the scripts in place, I configured events in iCal to run the
scripts to adjust my settings at appropriate times.

Every week day morning, I turn up the frequency to every 5
minutes. This ensures that by the time I am up and ready to look at
email, the mailbox is up to date.

Around lunch time, I turn the frequency back down to once
per hour. I find I don’t even notice the change, and when I come back
from lunch I am ready to settle in and concentrate. I don’t make it
through the afternoon without checking email, but stretching out the
time between checks does help.

And in the evenings, I turn email off entirely. Note that
this script only runs Monday-Thursday. On Friday, I leave Mail set to
check messages once per hour, since I do receive personal messages over
the weekend and I want to see those.

To avoid being sucked back into work, I disable that
account entirely. Of course, on Monday morning, I have a similar job
scheduled to run the MailCheckWorkEnable script to re-enable the account
for the week.

Disabling the account entirely seemed like a drastic step, but is very
effective. When Monday comes around, I am refreshed and ready to work
again. I do not miss any personal mail, and have not been tempted to
“just look at this one thing” from my work messages.

The os module provides a wrapper for platform specific modules such asposix, nt, and mac. The API for functions available on all
platform should be the same, so using the os module offers some
measure of portability. Not all functions are available on all
platforms, however. Many of the process management functions
described in this summary are not available for Windows.

The locale module is part of Python’s internationalization and
localization support library. It provides a standard way to handle
operations that may depend on the language or location of your users.
For example, formatting numbers as currency, comparing strings for
sorting, and working with dates. It does not cover translation (see the
gettext module) or Unicode encoding.

I recently came across a few articles by Esther Schindler on
telecommuting which struck a chord with me.

The first, “Getting Clueful: Seven Things the CIO Should Know About
Telecommuting”, is directed at managers of telecommuters. It covers
the benefits to the company of having telecommuters (cost savings,
productivity, etc.), potential pitfalls (not everyone can manage
themselves well enough to work remotely, ), and how to cope with them.
She places a heavy emphasis on building trust in the manager/employee
relationship, especially through communication.

The second article is directed at the telecommuting employee. In
“Telecommuters Need to Develop Special Skills”, Schindler goes a
bit beyond the basic advice normally found in articles like this.
Unsurprisingly, most of that advice centers around communication issues
such as status reporting and “visibility”. One key item regards
conference calls and telling people sitting around a speaker phone tospeak up – we have that problem frequently at my company.

Both articles include specific advice from experienced managers and
telecommuters. I’m happy to say that my company gets most of this right.
We are based in Atlanta, and unless you live in the same building as
your company there is no easy commute in Atlanta. From the very
beginning, my manager told all of us he would rather have us working
than sitting in traffic and we have been expected to figure out how to
do as much of our work from home as possible. This went beyond the
grudging acceptance of telecommuting at my previous employer to active
encouragement. He saw the immediate cost benefit in office space and
productivity benefit in gaining as much as 2 hours per day of extra
work.

As far as remote communication goes, we follow the technology chart
laid out by Schindler pretty closely. We don’t have formalized rules; it
just seemed to work out that way naturally. One category of tools she
does not mention for status/discussion are online collaboration tools
such as wikis and issue tracking systems. We rely on both, with the
ticket tracking system used for asynchronous design discussions and the
wiki for historical documentation, how-tos, etc.

After an initial settling in period (2-3 months) where I got to know
my new co-workers and learned about the development environment, I have
been working at home as much as possible. These days that usually means
4 of 5 days in a week, sometimes 9 of 10 over 2 weeks. There have been
stretches where I didn’t go to the office for a few months at a time,
but those are rare. One day in the office per week works out well, since
most of the developers seem to talk better with a whiteboard in front of
us. I’ve looked into online whiteboard tools in the past, but haven’t
found anything to replace the nuance of the in-person meeting. Perhaps
if we installed some web cams…

We’re a small group, so we try to keep everyone informed of all design
issues. The code is usually implemented by just one or two developers,
but everyone has an opportunity to be involved in signing off on design
and implementation before anything goes into the svn trunk. We’ve been
doing this for 5-6 years now, so we’ve settled into a pattern. For small
designs, an individual developer may do the work and write up the
“approach”, explaining the design and tricky implementation details. The
approach (a wiki page in trac) is then submitted for review along with
the completed changeset. This works well for small changes or bug fixes,
but for larger projects we usually have some sort of conversation before
development begins. It might be a simple sanity check by one other
developer via IM, phone, or email. If a more formal review is needed, we
typically write a preliminary approach, without any code, and submit it
for comments. If we can’t agree on the approach it is time to schedule a
meeting, either as a conference call or in person.

Of course, we also make heavy use of instant messaging on our own
Jabber server. Most of our quick communication has moved off of email to
IM, and we use IM for “presence” notification. If I step away from my
desk to take care of something around the house, run an errand, or get
lunch, I use the IM status message to tell people when I expect to come
back. Email tends to be reserved for progress updates, issues that don’t
need immediate resolution, and sometimes scheduling times for more
direct means of communication.

A drawback to working remotely so often is that I frequently end up
the last to know about things like schedule or priority changes. If an
informal discussion in the hall results in a major decision, an email
still might not go out right away or the eventual message might assume
more knowledge of details than I have. This is a group communication
problem, and we’re working on it, but it can be frustrating at times.

Schindler does not offer tips for handling physical space for
telecommuters in the office. She mentions the opportunity to save office
space, but doesn’t get into what to do when all of those remote workersdo show up at the office. For a couple of years I had my own cube,
even though I was hardly ever there. We’ve recently grown big enough
that my desk was needed by someone who is in the office more frequently
than I am, so I gave it up. When I cleaned out the drawers, the only
things I kept were a handful of business cards and a couple of pocket
reference books. There wasn’t anything else in the drawers that belonged
to me!

Now I sit in the “hotel” room when I’m in the office for meetings;
that’s typically the only reason I go in, any more. Even if I don’t plan
specific meetings, I usually end up spending the day in informal
discussions rather than writing code. We converted a small conference
room by replacing the central table with folding tables along the walls
to serve as desks and by adding a few chairs. There are internet
connections (or wireless), a phone, and the old whiteboard from when the
room was actually a conference room. I used to spend most of my time at
the office in a conference room anyway, so this works out fine. :-)

And of course when I’m at home, I work at my desk here most of the
time. I do try to mix it up a bit, though. On nice days, I start on the
patio after breakfast. I catch up on email, read news, listen to
podcasts, etc. If it is cold or wet, I usually start out at the dining
room table, or on the sofa with a cat in my lap. When I am ready to do
some coding, I move to my home office, where I have a door to close and
space on the desk to spread out notes or reference manuals. I also have
a second monitor for my laptop there, which turns out to be a lot more
useful than I ever expected. Occasionally I take some reading or
documentation work to a local coffee shop, but their chairs tend to be
less comfortable and the people traffic can be distracting, so I don’t
usually do any coding while I’m there.

Our application runs on Linux, and my desktop is a PowerBook, so I
rely heavily on remote access tools such as ssh and VNC. I have a
development box at home, because the lag time to the office is
intolerable sometimes. Most of the collaboration tools we, such as trac
and Jabber, use can be tunneled, so my ssh configuration includes a lot
of port-forwarding. The end result is that I can access any of my work
systems or tools remotely, even from the coffee shop if need be.

I’ve been working remotely for several years now, and I have a hard
time imagining going back to the office every day. I do like being in
the office, but the commute is killer. If the job were closer, or we
lived somewhere else, it might not be as big of a concern. But this is a
good situation for me now, and I’ve had no trouble getting used to it.

The logging module defines a standard API for reporting errors and
status information from all of your modules. The key benefit of having
the logging API provided by a standard library module is that all python
modules can participate in logging, so your application log can include
messages from third-party modules.

Ms. PyMOTW sent me a link to the survey UNC-Chapel Hill School of
Information & Library Science is conducting called “Blogger Perceptions
on Digital Preservation”. If you blog, you might want to go
participate. They ask thoughtful questions, and it only takes 5-10
minutes.

A little over a week ago I received a review copy of Sylvain
Hellegouarch’s new book, CherryPy Essentials, published throughPackt Publishing. The timing couldn’t have been better, since we
have begun investigating Python web application frameworks at work for
a new project. From previous work I have done with TurboGears, I knew
that CherryPy was a contender, so I was definitely interested to see
what version 3 had to offer. Sylvain’s book is is a good starting
point for the information I wanted.

Review

CherryPy Essentials is a fairly short book (251 pages), especially
given the breadth of topics it covers. It could easily have been 2-3
times as long, if the author was wordy or repetitive, but the concise
writing style means that there is a lot of good information packed
into this short volume.

The outline is fairly typical for tech books:

What is this thing and why do I care? – chapter 1

How do I get it? – chapter 2

What can it do? – chapters 3-4

Build an example app – chapters 5-7

Advanced topics – chapters 8-10

The real substance of the book begins with chapter 3, which gives an
overview of CherryPy. It includes a moderately sized introductory
application which lets different authors post notes on a page. The
sample code includes embedded comments and is used as a basis for a
brief description of how CherryPy decides what to do when an HTTP
request is received.

CherryPy comes with a host of modules to make building your
application easier. The coverage given these modules in the “Library”
section of chapter 3 probably does not do them justice. The author
clearly states that his intent is not to create a reference guide, but
I would have liked to see this section pulled out into its own chapter
and expanded, possibly combined with the Tools list in chapter 4.

The more in-depth discussion of CherryPy in chapter 4 includes
instructions for running multiple HTTP servers; various mechanisms for
dispatching URLs to Python functions; serving static content; hooking
into the core to add your own middleware (or “Tools” in
CherryPy-parlance); and WSGI support. The same chapter also includes a
description and concise example of how to use each Tool provided in
the CherryPy core distribution, following a format not unlike the one
I use for my Python Module of the Week series.

Chapters 5-7 discuss the design and development of a photo blog
application, which is small enough for the reader to follow but large
enough to delve into the details of how to build a real application
with CherryPy. The presentation begins with the data model, then
covers web services and user interface topics.

Some of chapter 5, which discusses working with databases, is
unfocused and includes sections on topics such as backgrounds on
database types and object-relational mapping libraries not actually
used in the example applications. This material could have been
eliminated without serious loss. It is interesting, but it detracts a
bit from the overall coherence of this book. Once he selects the
Dejavu ORM, the discussion refocuses and covers the mechanics of using
that library to store and retrieve data.

Chapter 6 provides an excellent discussion of web services, REST, URL
design, and the Atom publishing protocol. These were perhaps the most
interesting sections in the book. The author clearly has a great deal
of experience to share on these topics. I hope there is another book
coming soon with a greater examination of these topics.

The coverage of presentation layer topics in chapter 7 begins with a
brief history of HTML, up to the development of DHTML. Then the Kid
templating language is introduced (thankfully without a comprehensive
survey of all available Python templating languages :-). The UI for
the example application is fairly simple, so only basic Kid features
are really covered, but that is enough. The more complex DHTML work is
handled by Mochikit, introduced here and used more extensively in
chapter 8, which is devoted to Ajax.

The last 2 chapters of the book cover topics too frequently left out
of other books: Testing and Deployment. The chapter on testing
presents several tools which integrate well with CherryPy for
automated testing of different aspects of your application, including
webtest for unit testing, FunkLoad for load testing, and Selenium for
UI testing. I had never seen these tools before, and the descriptions
and examples were enough to make me add them to my “to be researched”
list.

The final chapter covers deployment options for moving a CherryPy app
into production. Options for using Apache, lighthttpd, WSGI, and SSL
are covered, but no definitive “best practice” is suggested. I suppose
the final choice should be made on more variables than could really be
covered, but I would have liked to see clear guidelines for making a
decision about which configuration to use in different situations.

Third-party Tools

Any good, modern, open source project does not stand alone, and
CherryPy is no exception. “CherryPy Essentials” makes it clear that
integrating with third-party tools is an important part of the design
for CherryPy. Tools covered include:

Conclusion

CherryPy Essentials packs a surprising amount of information into a
small space. The coverage is not exceptionally deep in any one area,
but is fairly complete. The sample code is consistent and easy to
read. The book is full of useful and interesting information and,
while it occasionally suffers from disjoint flow, I can definitely
recommend it to any Python programmer interested in the future of
CherryPy development, and web technologies in general.