ClearContext (http://clearcontext.com) is a great Outlook plug-in for managing your email. There are others for managing your workday (such as the GTD - Getting Things Done - plug-in). However, I feel this one has the most active development and a great featureset.

The reason I need a plugin like this is because a) I want to be as responsive as possible to people and b) I want to keep a clean inbox everyday. Keeping an clean inbox ensure I haven’t missed an important conversation.

The #1 feature I use is the auto-categorize feature. The way this feature works is: first create have a destination folder for email threads on a certain topic, then drag an email in a thread to that topic folder. ClearContext will then assign the remainder of the emails in that thread to the topic. Then, you can move these emails to this folder by pushing the assign button (either the current selected email or the whole thread).

The #2 feature I use is the feature that schedules an appointment from an email. It automatically copies the selected email as an attachment and inserts the first part of the email as the body of the appointment. A future release will automatically add the recipients of the email to the appointment.

The #3 feature I use is the ability to “defer” an email. This feature pops up a dialog asking you how long to defer the email (# of hours, # of days, # of weeks, a specific date, etc.). Then the email is removed from your inbox until the appointed time when it is reinserted into your inbox as an unread email.

The #4 feature I use is the prioritization of email. ClearContext assigns a priority of email based on the “importance” of the email using a custom algorithm. I’ve found this categorization to be fairly representative of reality.

There are other features including a dashboard overview of your inbox, tasks, and appointment, the ability to find related emails, the ability to convert an email into a task and others. However, this is a good start. =)

Leaving because you’re unhappy implies that you haven’t identified the specific reasons that you’re unhappy. You owe it to yourself to understand why the current job isn’t meeting your expectations. Changing employers is often risky and stressful - for you and those who depend on you.

Once you’ve identified the specific reasons you’re unhappy, you owe it to yourself and your company to attempt to resolve the issues. You’ve invested in relationships (often spending more time with coworkers than family), knowledge (including proprietary knowledge), and skills which may not be wholly transferable to a new job. Sometimes friendships endure between jobs - but even if some do, not all will.

Finally, leaving because you’re unhappy implies that you aren’t leaving for a better opportunity (otherwise you would have said so). I suspect that most people who leave because they are unhappy end up getting a job that is similar to their current job and work environment. After the initial euphoria of a new job wears off, the reality that the new job is suspiciously similar to the old job begins to set in.

In short, “I’m leaving because I’m unhappy” is ambiguous language that implies that you don’t know why you’re unhappy, haven’t attempted to resolve the issues resulting in your unhappiness, and aren’t leaving for a better opportunity.

(Caveat: This is a generalization which are never universally true, but are probably generally true.)

While the first chapter suggested the size was more about lack of editing than content, the second chapter was actually very useful. Excellent overview on symmetric/asymmetric keys, ssl, and key concepts in security.  And if the readable chapter wasn’t enough - you can check out Hamlet D’arcy’s excellent material prepared for the topic.

Seriously - Mary Queen of Scots as a real example to help me discuss security? Trust me it works AND is interesting. And if that (or the second Mary piece) isn’t good enough - see the online-merchant of venice example. I guess you don’t get the name Hamlet without being able to quickly rattle off great Bard references.

Using real-world examples to discuss security principles reminded me of Dick Hardt’s great Lessig-style short presentation explaining authentication/identity 2.0. Relates a form of third-party trust management in the physical world (photo IDs), to how one might think about identity trust in the electronic world.

Fits well with the Queen of Scots example-style, and while I think it will help you understand identity in a new way, if nothing else it’s completely well-done and uses a keen style of presenting.

(For those concerned, I’m not planning on changing jobs anytime time soon.)

On the Release Train at Ignite Realtime

I’m impressed they’re willing to share this with us (the global audience). Even more, I’m impressed that they’ve chosen strict, predictable release cycles (see next).

The key points to this model:

• We put out a new release every three weeks (although each release will have gone through a nine week process total).
• Three weeks before each development cycle is reserved for product management; three weeks after each development cycle is reserved for QA. But notice that all three processes are all happening at the same time.

We made a similar choice several years ago. A minor difference is that we chose four week cycles. The key is to chose a cycle that is relatively short (you’ll see it’s likely dramatically short compared to your prior release cycles), but long enough that you’re not burning time money in regression. This latter cost can be mitigated if you have automated regression tests (which we are building).

A major difference we have is overlapping cycles. We also do weekly builds to QA within this four week development cycle. QA tests our code each week (in theory) as the code is delivered. The reason we have overlapping cycles is because we add two weeks regression and a third week of “quiet” before a release. The regression we do is exhaustive and time-consuming. The quiet week is simply to add schedule buffer to that release. A consequence of overlapping cycles is the need for two testing systems.

A few of points of clarification: 1) our release cycle is more complex because of the regression testing window, 2) we do monthly Production deployments, and 3) the development and QA cycles are each only four weeks long. The two weeks of regression do add additional burden to the QA team. This regression “double-duty” on the QA team is non-ideal and we are agressively pursuing automated testing.

In summary, I believe having short, predictable release cycles is a major contributor to the quality code and products we produce. This release cycle won’t work for everyone, but I do believe it should be strongly considered as a viable option when selecting a release management strategy.

Footnote: I’m curious as to why they don’t do their continuous integration off of the trunk. See this comment:

Switch the builds in our continuous integration environment, TeamCity. The new branch becomes the “stable” release of the product and trunk becomes “development”.