My parents gave me the Swiss Army Active Original with Red Bezel (#24221) as a gift for high school graduation, which had a retail price of 155USD at the time of purchase and is now sold by authorized dealers for 195USD. The Original features a Swiss analog quartz movement and scratch-resistant mineral crystal. Its strap consists of leather and nylon mesh with stainless steel buckle. The dial of the Original is white with bold black numerals and small red military time numerals. The Swiss Army Active Original is battery operated and water resistant, and its hand and hour markers are luminous. The day of month feature is the Swiss Army Active Original’s sole complication.
After 12 years, I upgraded to the Victorinox Swiss Army Classic Infantry Mechanical Self-winding (#24695). I purchased the timepiece, which has a retail price of 525USD, by special order through Classic Design Fine Jewelers at the Glendale Galleria. The Classic Infantry Mechanical Self-winding features a 25 jewel Swiss automatic mechanical movement, scratch-resistant sapphire crystal, stainless steel case, and a see-through caseback. Its strap is leather with a stainless steel buckle, and its dial is black with white hands and markers. Aside from the dial, the crown and buckle are embellished with the Victorinox Swiss Army logo. The Infantry Mechanical Self-winding includes two complications: day of week and day of month.
The transition from a quartz movement timepiece to one with an automatic mechanical movement has surely renewed my enthusiasm for owning and wearing a watch. The Victorinox Swiss Army Classic Infantry Mechanical Self-winding allows me to appreciate the awesome engineering feat that is accomplished in a quality timepiece.
A Microsoft Windows Media Video that presents the Victorinox Swiss Army Classic Infantry Mechanical Self-winding timepiece with an ETA 2836-2 movement operating at 8 beats per second is found here.
A real-world discussion about trunk and branch management that I found through reddit.com is reprinted here:
From: Rasmus Lerdorf
Subject: PHP 6
Groups: php.internals
Date: Thu Mar 11 12:22:48 2010
Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways.
So I think Lukas and others are right, let’s move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let’s see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again.
The main focus here needs to be to get everyone working in the same branch.
-Rasmus
From this post, it seems that the required “Unicode effort” was underestimated, and continuing that effort on the trunk is causing issues with development of PHP. The proposed change will move the Unicode effort to a branch, allowing development for other components of PHP to continue on the trunk. Changes to the rest of PHP on the trunk can be pulled into the Unicode branch as the Unicode branch continues to be developed. The Unicode branch can be merged back into the trunk once it is matured sufficiently.
The words, “trunk” and “branch,” are used to label lines of development work. In general, a trunk can be considered simply another branch. Identifying a specific branch as the trunk helps developers visualize its relationship with other branches. For the PHP development project, the trunk appears to be the main code base that is being developed. A branch isolates development of a feature, so that any impact it has on the main development effort is minimized. The Usenet newsgroup post above is an interesting example of the importance placed by developers in distinguishing between development trunk and branches.
I recently finished reading Applied Software Project Management by Andrew Stellman and Jennifer Greene. Stellman and Greene’s book has motivated me to read CMMI for Development, Version 1.2. Since CMMI is a model for process improvement, Stellman and Greene’s book has also encouraged me to get books on processes such as Rational Unified Process and Personal Software Process.
Stellman and Greene’s book makes the case for software engineering practices in a general way, leaving a reader wanting knowledge of specific practices that are used. Their book starts strong with their introduction of the Wideband Delphi estimation technique, which is one of a few specific practices that are discussed in the book. Their script for inspections is also strong, clearly stating the objective of inspections and how to run inspections efficiently. The strength of the book tapers off when discussing requirements acquisition, planning, design, and testing. Overall, Applied Software Project Management is a good introduction to the components of software project management. Other introductory books on software engineering practices claim that writing documentation before performing implementation is good, but Stellman and Greene’s book explicitly states why and how this is the case, and their book surely makes me more appreciate software engineering practices.
A local copy of CMMI for Development, Version 1.2 is found here.
The responsibility of a project’s outcome is shared between developers and managers. Developers depend on managers to effectively manage projects, and managers depend on developers to provide reports that serve as the basis of project management decisions.
Possibly due to insufficient transparency, a problem may be detected after attempting to use a fully implemented and unit-tested software component. The integration phase of a software life cycle is a common, but undesirable, phase to detect interface issues. The problem, found during the integration phase, potentially reopens tasks that were considered complete. Design documentation might need to be updated, software might need to be re-implemented, and software might need to be retested. This increases the difficulty of meeting a project schedule, which may already be tested during integration.
The person that detects the problem has the responsibility to make the problem known. Resolving the issue among developers of the affected modules may be possible, but in general, resolution will involve too many people and too many tasks. Utilizing the managerial structure is pragmatic and effective in coordinating a resolution. A line manager or immediate supervisor is an entry point of using the managerial structure, so reporting the problem to that manager is reasonable.
Without a problem report, management is unaware of the problem and unable to manage the project with respect to the problem. Reporting the problem to management is a practice that increases project visibility. Management may decide that the problem shall not be resolved, because of schedule pressure or the severity of the problem. Management may decide that it shall be resolved within the constraints of the project schedule. Management may also decide to resolve the issue and revise the project schedule. Management must make the decision for the project, but the need for a decision must be made visible by developers through problem reports.
I have just completed transitioning to a new server, which serves this blog. I am now using GoDaddy.com’s Virtual Dedicated Server product. I have been administering my own dedicated server, GoDaddy.com’s Dedicated Server product, for more than two years. I changed from a Dedicated Server to a Virtual Dedicated Server to reduce costs and better fit my utilization.
Though, I am not sure when the last time I rebooted my old dedicated server, the result of running ‘uptime’ on my old server is:
XX:XX:XX up 790 days, 15:23, X users, load average: X.XX, X.XX, X.XX
As I publish this post, the ‘uptime’ on my new server is:
XX:XX:XX up 2 days, 19:52, X users, load average: X.XX, X.XX, X.XX