Oh, all right, so maybe it’s not really a poem you’re reading now… Deal with it.

And speaking of coping: dealing with the repercussions of the Mega-Snowstorm of (February) 2010 seems to be quite a struggle for the majority of the Washington, DC region.

Although the snowstorm ended earlier than predicted, the combination of alternating sunlight and freezing temperatures have conspired to create excessively thick (and for some, virtually invisible) ice layers on the roads and sidewalks. This has led to treacherous driving and even pedestrian activities outdoors.

Fortunately, a lot of people have wisely chosen to remain ensconced at home, snug in the comfort of their respective dwellings. Some of this is due to the announced closures of schools and businesses, many which were publicized over the weekend and the latter part of last week,. Some was unfortunately due to failed attempts by many to leave their homes, only to find themselves obstructed by ice and snow.

There is yet another category of people who are currently suffering, however: these people lost electricity during the snowstorm. While the actual totals are constantly fluctuating, and the various repair crews are probably working hard to restore service, many people are even today struggling with the consequences of no electricity in their homes. Hopefully, this situation will be corrected in the minutes and hours to come.

As I’m tracking a variety of media channels at the same time as the Apple [AAPL] iPad announcement, I find it curious as to how the human condition, and certainly all of these so-called tech pundits, keeps wanting to compare new tech with old tech.

When I’ve been using the iPod touch in the practice, I kept thinking, “Yeah, the iPod touch is nice, but I really could use a larger touchscreen, and some more compute power”. But all of these “pundits” keep talking about netbooks and cheap 13″ notebooks and iPhones and BlackBerry devices… But given that my needs are more specialized (and some of you will call them “advanced”), the iPad may be the missing link in my product usage roster.

Something that fits the 8.5″x11″ form factor with a much thinner profile. Something that allows me to use my hands, enclosed in disposable nitrile and latex gloves, along the touchscreen. Something that does not require me to have an attached, or even wireless, keyboard and mouse to manipulate the viewpane and enter data. Something that allows me to quickly retrieve data from the Internet as well as my LANs, wirelessly. Something that lets me manage scheduling and patient data quickly and conveniently.

I’m not looking for a Kindle or mere e-reader. I’m not looking for a BlackBerry. I don’t need an iPhone in my office, or my lab, or my practice rooms. I don’t need yet another notebook with the keyboard and mouse/touchpad.

Certainly, I need to get a hold of an iPad to see if it really lives up to my requirements. But next to the Axiotron Modbook, this may be the frontrunner.

Smack! Smack! Smack!

Ouch! That smarts!

Verizon [VZ] has now gotten two of  Palm’s [PALM] flagship devices that Sprint [S] has been touting, although some may say unsuccessfully due to the odd way that software developers and consumers have been treated– or at least very mixed– there’s that new question as to how Verizon will position these smartphones.

The TV commercials for the devices are already rolling out… and this is certainly a new entryway for Verizon to cater to Palm enthusiasts who have given up on the Garnet/Palm OS.

WordPress 2.9.1 was released yesterday, after a relatively short beta and RC1 pair of cycles.

Some of you may recall the controversy surrounding WordPress 2.9, surrounding some defects that were discovered shortly after its release– although some people have mentioned that the problems, they felt, were present even in the previous versions of the software. As mentioned by Ryan at the WordPress development blog, those noticed defects were addressed by this release, as well as a few other minor issues selected to be included.

Operations Recommendations and Notes

Apparently, since the recent series of posts about WordPress 2.9 and the 2.9.1 beta came out, many of you have been sending E-mails and messages about providing more guidance to prod-ops teams and developers. The following recommendations should not be taken as gospel, since I strongly advocate sound development practices and practical management processes and more than a little common sense: rather, they should be considered in context with your current situation and deployment strategy.

Recommendation for Standard Operations Teams

At this time, the recommendation is that it is a worthwhile upgrade for most technically savvy production operations teams, as well as developers accustomed to using and manipulating WordPress. However, the customary testing procedure is strongly advised: download it, set it up in your testing environment and vet it through your test suite(s), prepare your CM machinery to handle the new version if it passes your tests, and deploy it to your production environment.

Recommendation for Agile Operations Teams

For the heavier types of agile development, if you have already cleared WordPress 2.9, you should be able to layer 2.9.1 on top of your previous iteration and restart your testing segment and merge back to your expected path. Once you have cleared it, you should be ready to deploy it to your staging/production environments.

For the aggro types, you probably have been tracking beta and RC1 versions of WordPress 2.9.1, but the latest changes for it should be considered as overriding the previous two changesets. If you are sweeper types, overlay 2.9.1 onto your outbound segment and restart testing. If you are satisfied with the results, you should be ready to deploy it to your staging/production environments.

Recommendation for Continuum Operations Teams

Yes, I know: this is somewhat redundant. But a couple of you have asked about continuum development recommendations, so here ’tis:

You most likely already know the outcome of your tests, but the question is in which order should your production environments be refreshed. The easy answer would be to use the exact order you have been using all along; however, some teams do have highly variable distribution orders, so the prevailing advice here would be to deploy into production prioritizing first in order of increasing code complexity and then in order of increasing network or traffic load. So your simpler outbound segments with lower traffic and integrations with other packages would be rolled out first, then you proceed upward in complexity and then frequency/traffic/load. For this version, avoid simultaneous or near-simultaneous rollouts unless your tests have already proven 0.00% disruption.

Hint: our tests showed ~4.33% disruption across all outbound segments, > 120.

N.B.

Other related Javamancy posts (in reverse chronological order):

• Stop the Insanity! Or, WordPress Development for 2010, a New Year’s Resolution
• Complaining About WordPress: Does That Make You a Bad Person?
• Uh-Oh: WordPress 2.9.1 Coming Soon?
• WordPress 2.9 Released

Other related Javamancy mini posts (in reverse chronological order):

• WordPress 2.9.1 Now Available
• WordPress 2.9 Now Available

Maybe this ought to be called “the FUD Edition”, Part II… After one year, remember the first FUD Edition?

As we count down the minutes to the start of 2010, let’s review some of the things that have captivated us (for lack of a better term) over the course of 2009:

• The world economy, and certainly the US economy, with odd “jobless recovery” seen in some of sectors in the stock market;
• Moderate improvement in gas prices and a lot of backpedaling from doom-and-gloom environmental prognosticators;
• Slow real estate recovery in a few select regions in the US market, leading pundits to wonder whether 2011, not 2010, is the year that consumers
• More revelations of of financial misdeeds at a variety of ostensibly “reputable” financial firms, all while their executives are cashing in BIG-TIME with huge bonuses and salary raises;
• Continued car industry collapses in the US due to [insert-your-reason-here], and attempts by a few of the big-name companies to return to relevancy in the minds of consumers, despite lackluster achievements in energy saving technologies;
• Further disastrous job loss woes in the US, depending on whom you ask… some people see the continued worsening as the unemployment rate surpasses 10% and even more people completely drop out of attempting to find jobs;
• Crazy reality show stunts, and stunts for publicity by certain individuals that revealed serious national security deficits, including at the White House itself;
• Active and even more planned tax hikes in various US jurisdictions;
• Return of the blockbuster gaming phenomenon, such as Modern Warfare 2 and Borderlands;
• …

And you can certainly add more items to the list.

So: the wrap-up message for 2009 has just got to be…

Better luck next year, and thanks for all the fish!

I’ve always wondered how some popular open source and GPL projects keep going. Many times, they seem to implode upon themselves, whether due to internal or external forces imposing their undue influences upon the work at hand. The good ones realize that they are imploding and take measures to stop it from happening… and sometimes, they manage to successfully execute an appropriate plan of action in time.

Here’s an interesting live example: WordPress.

Scenario: WordPress

Jane Wells posted yesterday about an anticipated change to how WordPress development will change to fit a model that should address their scope creep problems that have been hampering their releases, of late. She refers to project management as providing the answer for their woes with scope creep; yes, there’s additional verbiage in the post, but essentially, that is what she is primarily referring to. There is that additional component to the problem, in the form of release scheduling, which plays a part in the problem set.

At this point, some of you will be nodding sagely toward your display screens (LCD’s, iPhones, BlackBerry devices, et al.) and thinking, “Well, project management techniques would help manage what is going on, but… there’s something else in play that needs to be controlled, right?”

Management Perspective

Yes, sage thought (or thinking sagely, perhaps?), indeed.

While project management in general is a useful discipline or tool to have, even for small teams, especially those that conform to a matrixed (or “mixmaster”) configuration, it is not the magic bullet that many people think it is.

In essence, it is a way to react to chaos in the workplace by arbitrarily grouping workstreams into some semblance of order, based on a variety of criteria, like limited resource availability, priorities, scheduling conflicts, release dates, et al.

However:

What if trying to rope in the insanity of scope creep and meandering requirements are symptoms of a greater problem? Using reactive techniques to mitigate further damage to a production schedule is only an immediate-term fix.

Instead, determining a new way to manage requirements intake and development, and a new workflow cycle for controlling change and releases, would be much closer to a longer-term solution. Figuring out the most appropriate mechanism by which to introduce and control change (whether fixes, new features, extensions, etc.) and to align them with ongoing development and documentation is the basis for the transition toward a fully-realized workflow that integrates configuration management with project management. Of course, not an easy task (certainly, easier to simply state what seems to be needed for this scenario, as opposed to actually implementing it)… But a lot of the basic tools to build upon are already in-place or being used or available.

So, this will be an interesting live scenario to follow.

Apparently, several people have had issues with WordPress 2.9 since its FCS release just a few days ago.

In fact, this has caught on such attention that there has been mention by Jeff (at Weblog Tools Collection), Keith (also at Weblog Tools Collection), and at the WordPress development blog about a beta version of WordPress 2.9.1 making its way out for people to try.

If you read the comments on Jeff’s post, you’ll notice that there is a sort of near-religious (for lack of a better term) indignation over the 2.9 version and presence of bugs in the product despite its beta and release candidate cycles. While certainly not to the same extent as the “religious wars” over GPL and other open source efforts, it does touch upon the conversations and arguments over whether GPL’ed products are worth the trouble for many businesses and individuals.

While it would be difficult to argue that hobbyist bloggers have the same issues about code ownership and production-worthiness that major corporations do, it is easier to understand the concern that individual bloggers (and even SMB’s that use blogs to help drive or support their work) have over some (or, in some cases, much or even all) of the open source software that they rely upon.

And it does not make it any better when the fervent GPL’ers and open source fanatics turn the frustration around upon the users and accuse them of not “helping out”. As if every user of open source software is somehow financially and technically equipped to deal with the intricacies of agile and automated testing…?

Perhaps the lesson here is: You get what you get, and that’s all.

“Well, what does that mean?!?”

Another way of stating it (and a bit less obtusely) is that when you get software like WordPress, despite being GPL’ed, it is still nothing more than software. And like most software released into the wild today, its code complexity makes it prone to having bugs introduced with every successive increment, and coupled with its existing bugs, some of the combinations and permutations of the population of defects would be truly wicked and pervasive. So if you choose to use it, or any other software, you have to be cognizant of this reality and decide how you are going to deal with it.

In the realm of COTS, it was fairly simple: you abide by the terms of the EULA or basic software licensing contract. If there was a support clause, you could exercise it. If you decide the headaches of using the software are not worth it, you have the option to just stop using it. A common example that is being played out in the marketing arena, and in mass media, is of course, the Exodus Away From Windows of the 2000’s: whether it’s OS X, Linux, Solaris, or something else, the choice to stop using Windows has become not just viable but extremely attractive. And while some have chosen to stop using Windows, others have decided to stay with the versions that they are already using, and still others have taken the plunge to Windows 7.

The FOSS arena has generally been fairly simple as well: if you choose to use the software, you need to understand the terms of acceptance and make arrangements for support. Since several of the open source licenses do not place restrictions on customizations or modifications, it is a laissez-faire market for hiring developers to manage the code. This frees the users who are less technically adept to focus on their business needs and be what the software expects them to be: users.

The WordPress-GPL realm has been a bit murkier when it comes to the separation between user and developer in some respects; some of the comments being bandied around about how WordPress users should somehow transform themselves into volunteer developers or QA testers for unstable versions of the blog package indicate how misinformed those writer are. Other comments about how the WordPress users with problems should consider hiring some developers to correct the bugs for them are a bit more reasonable since, after all, it’s just software. But judging from the types of comments being written by the user types, a lot of them are looking for constructive advice on how to get back on track and just being productive users of the software, but not heckling or the typical “you-should-have-backed-everything-up-every-second-of-every-day” lecture.

Recommendations

Well, by now, you probably figured that this section would be here, right?

Here are some recommendations for WordPress users, especially the ones who are discouraged and frustrated by all of the people who are giving you grief for being, frankly, users of WordPress:

• Use the software for all it’s worth, but don’t expect more from it than it really is… skip the hype about how it’s the end-all-be-all of software… It’s Only Software.
• Whether you’re a casual user or a power user, use the features you like or need to use. Blog as much as you want and how you’d like to, based upon what the software provides for you.
• Sometimes you’ll have to check the WordPress.org support forum for information or help. Don’t be afraid; just ignore the hecklers– the rest of us do.
• If you are motivated and spot a bug, there is documentation on WordPress.org, including in the Codex, about how to report a bug. It’s a lot of didactic to wade through, but it discusses the formalities behind researching the bug to see if it already exists, and then posting it (if it’s not anywhere) into the Trac issue tracker.
• If you want to focus on being a user, use the support forum to discuss the bug… take your best guess at the most appropriate topic for now (you’ll see what I mean when you get there).

And not to leave Matt and the other WordPress folks out of the recommendations, here’s a feature request of sorts:

• If I couldn’t persuade a few hundred project managers at a large Fortune 500 company to submit and track bugs in something like JIRA or Trac, I seriously doubt I would be able to offer Trac as the easy-to-use, convenient bug reporting tool for end users.
• Instead, a lot of customer-facing software tend to use quick pop-up style or pre-shutdown hooked dialogs to capture the user’s note about the problem and some internal stack trace or other technical info before the software bombs.
• A good approach would be a “Report a Bug” feature in WordPress that would be accessible at multiple locations through the admin console. What information you’d like to capture would be up to you, of course, but knowing where the bug occurs and what happens when it occurs… well, y’know.
• You’d probably want to pump all of the bug report data through to a secure Web service and store the raw incoming data separate from Trac initially; then you could filter against it, or scrub the data down to unique sets for import into Trac. Or you could have the Web service import the data into Trac after a bit of transform or scrub, so you would have everything captured… just keep in mind that the data could get large and you will see a lot of duplicated reports.
• For more advanced fun, you could also provide the users with a ticket ID associated with their report, for both the raw incoming data and the eventual associated Trac ticket.

Parting Words

Users are users. Many developers are also users. But not many users are also developers. Good users are great sources for feature requests, but they should not be expected to be well-versed or experienced in reporting and investigating defects.

So, happy holidays, folks! Be kind and considerate to your friends, neighbors, and even strangers. Be of good cheer and well-wishing. And be good users of software.

Jeff Chandler, at the Weblog Tools Collection blog, posts that WordPress 2.9.1 beta version will be available shortly to address a WordPress core bug in the 2.9 version.

While undoubtedly version 2.9.1 will include additional bug fixes, there is a bug fix reported in WordPress’ Trac issue tracker:
http://core.trac.wordpress.org/attachment/ticket/11505/ticket-11505-full.patch

So those of you who wish to assemble your own bug fix instead of rolling back to your pre-installation backup can give it a try.

Note: Since this is PHP code, it would be helpful to be familiar with PHP.

WordPress 2.9 was released yesterday, and with it comes several new features.

As announced by Matt at the WordPress development blog, WordPress 2.9 has come out of its release candidate status into FCS.

Unlike the previous several “minor” point releases of WordPress, which have been devoted toward security and stability fixes, WordPress 2.9 is intended to bring online new features… in addition to the expected security and stability fixes.

Recommendation for Production/Operations Teams

Of course, a new release like this will probably have a few bugs that may make you think twice before deciding whether to deploy it for production use.

Our recommendation is that you should withhold using this version until your QA or GPL-OSS test group has cleared the software.

Recommendation for Developers

On the other hand, for developers and readers who are savvy in their appreciation (and usage) of WordPress, our recommendation is a bit different. If you have a version of your site where you typically try cutting-edge software, or if you are already using one of the beta or release candidates of WordPress 2.9, congratulations: you will probably already be aware of the stability conditions of the software.

More importantly, you are probably already prepared to deal with any unusual behavior of the version, or you have already made your determination of it. Thus, our recommendation is to continue with your current course of action.

Javamancy Operations

Javamancy will not be upgrading to this latest version at this time; instead, it will be deployed to a few internal cycle beds for closer examination while we interpret some recent integration changes that are specific to our configurations.

Thanks for being patient, folks! Until then, version 2.8.6 will be in circulation for a while longer.

It’s been several years since a massive, crushing snowstorm hit the Washington, DC area, so I suppose you could say that it was long overdue.

Given the craziness of the Congressional struggle over healthcare benefits this week (which appears to be the political version of last-minute cramming for an exam, rather than steady, deliberative, organized studying) and the continued poor economic performance across multiple sectors and lackluster retail sales, having a respite in the form of severe bad weather may be a blessing in disguise.