I've been contemplating doing a Firefox Extension as a personal enrichment technology project (obviously extensions aren't a potential revenue market), and have played around with the rudiments: Tremendously powerful, and very easy to take each step, and while there are specifics that I haven't nailed down, most of the enabling functionality for the following requirements seems to be there.

Before I waste the time I thought I'd put a general query to see if anyone has seen anything like this (searches yield nothing that looks similar).

• Record and report the time spent on all sites, or selected sites (e.g. defined by regex patterns, or groups of regex patterns), allowing for various reporting levels. e.g. domain, subdomain, folder, document, etc. Reporting could be facilitated via the new SVG or canvas functionality.
• Based upon the recorded time, allow the user to "ration" their own access. e.g. "Limit me to 20 minutes of Slashdot per day" or "Limit me to 60 minutes of Reddit, Digg, Slashdot, and JoelOnSoftware per week".

Like most software developers, I peruse the various technology sites during the day, and in the interest of good time management, not to mention that such a tool could be useful for billing purposes, I want to have an accurate grasp of exactly how much time I spend at specific sites, or a group of sites for that matter. Apart from status bar indicators of the time spent, and perhaps time "remaining", the product could be more interesting if it actively blocked further access to that site until you indicated moral weakness and selected the override feature.

Come across anything like this?

As a software developer, I'm generally drawn to complexity, and I generally view "hard" problems as much more worthwhile, from a business perspective, than easy problems.

For instance I never considered many of the "successful" .COM-type ideas as worthwhile, and I naturally feel the same about many of those percolating up via Bubble 2.0, because they either seemed too obvious, or too easily duplicated (aside from the fact that most of them haven't a hope in heck of ever having a sustainable revenue model...but that's beside the point -- If you can get Yahoo or Google to buy you out with big dollars, it doesn't matter if your flighty userbase would never pay a penny, and that they would never tolerate a single ad impression).

As such I discarded a lot of "neat ideas", only to see them bring success to someone else. I was keeping my eye out for something both unique and difficult.

Yet often it's the simplest of things that hold the most value to people.

Just over a year ago, late December 2004, I was working on some custom C++ JPEG parsing logic (scary pointers and all), and noticed that some of my test files were bloated up with a lot of extraneous data. We're talking 4KB JPEGs that had an extra 60KB+ of data appended to them. Apart from EXIF data -- useful at times, but completely irrelevant at other times -- Adobe Photoshop was particularly notorious for stuffing files full of worthless application blocks.

Many of the images you find on the web have all of this extraneous info, slowing transfer times, increasing server loads, hiking bandwidth bills, causing pestilence and suffering (okay I'm going a little overboard).

As such, I gathered up a ridiculously small amount of the parsing code, compiled it, and "released" it as the rashly named PureJPEG. I expected it would see maybe a dozen downloads from nitpicking webmaster looking to ultra-optimize their user's experience.

Over the past year, over 40,000 people have downloaded this utility directly from yafla. It's been mirrored on quite a few sites (particularly in Russia, for some reason), so I have no idea how many worldwide have downloaded it, but presumably a greater number still.

I would have never imagined that something so simple would have filled such a niche, and I'm a little embarrassed about how trivial of a micro-project it really was, but there it is. As far as little utilities go, it's been a stunning success.

I've received some great feedback regarding the entry on setting up a MediaWiki install on Windows. Many of the comments were kind words of thanks (which I really appreciate. Knowing that it helps people is my greatest motivation), and others helpfully suggested improvements to the instructions.

As an example of comment-driven improvements, my instructions have you installing the GNU diff utilities, in particular for the diff3.exe utility, however the MediaWiki setup scripts don't properly find it (e.g. as the instructions are currently written the GNU diff utilities are completely unused, although they can still be useful in your day-to-day travails). This is because a prior revision included fairly involved changes to the MediaWiki config/index.php script so it would properly locate diff3 on the Windows platform, as it is currently Unix-centric and doesn't look for the proper executable, not to mention that it parses the PATH environment variable incorrectly . After receiving two comments that those steps were a little too complex, however, I removed that section.

My goal was to get people experimenting with MediaWiki, or even just wikis in general, so diff3 functionality really wasn't critical. I pared the instructions accordingly. Similarly one early draft included the building and installation of a PHP memory cache to improve performance, but that too is unnecessary to simply try out the product.

Another line of comments involved asking:

• Why would I give instructions for Windows. People should just set it up on Linux and go with its native home.
• -or- Why would I recommend a wiki product that largely caters to the open source crowd. Instead I should be pushing Sharepoint, or something properly anointed by the Microsoft camp, enabled with all of the latest Microsoft buzzwords.

To answer this I really need to describe the philosophy of this blog, along with my resistance to "technology alliances".

In the byline of this blog I describe my philosophy as "pragmatic software development", and this really drives my recommendations. In this case there are a lot of development shops that are Windows-centric, with little or no UNIX/Linux experience, yet MediaWiki is one of the best, most featurer rich, "standard" wiki products out there. Choosing a solution that leveraged what shops already know with the best solution is a pragmatic approach.

Which brings me to my general philosophy towards Microsoft, as comments indicating that I'm either a Microsoft hater, or a Microsoft drone parroting the corporate line, have hit my inbox over the short history of this blog.

I am not subservient to Microsoft.

Unlike many Microsoft technology advocates (I truly love both SQL Server, and .NET, and I think they're remarkable solutions), I have no desire to ever work for Microsoft (Microsoft has some top notch, world-class talent, and I've met and worked with a lot of great talent from there, but they also have their share of both jerks and duds). I'm not going to praise their every move in hopes that I'll get noticed. yafla, my consulting/ISV company, has chosen to avoid any partnerships or tying to the Microsoft brand because we don't want to become another drone "consulting" company single-mindedly acting as a third-party sales force for Microsoft, desperately racking up Microsoft partner points by pushing less-than-optimal solutions on customers. We didn't choose to use .NET for our software because we're hoping to nestle into the Microsoft family -- we chose it on technical merit, and a pragmatic analysis of our current and prospective clients.

We work for our clients and ourselves, not Microsoft. This is a very important mantra for our services, and for the technology of our software, and if Microsoft wants their products to get recommended to our clients, and their technology to the foundation of our software, they need to make great products at competitive prices. No sales gladhanding, or sad career dreaming, is going to change that.

Am I saying that Microsoft solutions are second rate? Of course there are examples of Microsoft products that are terrible, and customers are being misled into buying buzzword-laden atrocities because a Microsoft partner is hoping to get invited to the next Microsoft dinner party. Yet there are also Microsoft solutions that are extraordinary. Windows 2003R2 is a superlative operating system, and where you need the breadth of its functionality, it can be well worth the money. Microsoft Small Business Server can be an amazing package of value for some small organizations, within the constraints of the product. Other times, however, if you have the appropriate skills, a Linux machine is the best choice, along with a stack of the many available free or close to free server products on that platform. Sometimes IIS 6 is the superior solution for a problem, while other times Apache would be your best bet. Sometimes PHP and MySQL is a great solution, and other times C#/ASP.NET with SQL Server is the perfect combo.

I don't blindly assume the Microsoft product to be the best, but neither do I automatically presume it to be second rate. Instead I evaluate on merit, and propose solutions based upon the customer and their needs.

To do otherwise would be just biased noise, and wouldn't be to the service of clients and peers.

Tagged: [Software Development], [Programming], [Software-Development]

Introduction

This article describes the wonder and curiosity that many developers start out with, whether it's when they entered their first Compute! type-in program on their Atari 400, picked up their first JavaScript in 1 Hour book, when they started toying with the gcc compiler for the first time, or when they began towards their first Computer Science degree in university.

It also describes how that natural enthusiasm can be crushed, and how it can hopefully be regained or maintained.

This is written for the developer, whether a new recruit or a veteran, motivated or unmotivated, spirited or crushed, yet it's also written for software development managers (who might identify how to make the workplace more enjoyable and more rewarding).

Like most entries of this genre (see also Optimal Software Development Processes and Practices) I selected a small list of widely applicable, but often overlooked, factors. This most certainly isn't exhaustive, but hopefully it leads to a bit of reflection.

The Enjoyable Profession of Software Development

Software development can be a tremendously rewarding, enjoyable career.

Few careers offer comparable opportunities to weave intricate, complex structures that, while virtual, have such a positive impact on the world around them. Few offer the freedom and creativity that software development does, or the very real potential for entrepreneurial riches.

Whether it's building a new peer-to-peer application, control software for a massive power generator, or improving the workflow of the corporate scorecard system, done right this can be a very fulfilling, enjoyable, challenging pursuit.

A Passion for Software Development

Does your mind race at all hours, abuzz with potential solutions for vexing software development challenges? Do you lie awake at night -- anxious like a preschooler on Christmas Eve -- eager for morning to arrive so you can implement the crafty coding structures you just thought up? Do you frequently find yourself powering up your system in the twilight hours to implement the fruits of an epiphany?

Or do you put in just enough face time and superficial effort that sacrifice makes up for undelivered results? Do you purge your mind of software development the moment the virtual end-of-day whistle goes off, sliding off your Aeron dinosaur satisfied that it's one day closer to the weekend? Do you dread Mondays, motivating yourself to keep going with the dream of a far off vacation?

Do you eagerly embrace new technologies, seeing it as a challenging opportunity to learn something new when a solution calls for a new skill? Would you voluntarily dive into the innards of the Firefox web browser if a solution demanded it and you'd never touched it before? Do you swim through documentation, thirstily absorbing new APIs, tools, and languages to expand your skill-set, eagerly embracing industry advances?

Or do you dread anything different, praying that you're tasked with challenges that require only the skills you've long held, allowing you to apply them in a mechanical, repetitious fashion? Do you hope every project is an echo of a prior project? Do you put off any task requiring research, and show disdain towards new languages, techniques and practices, hoping that they don't gain traction?

Are you really passionate about software development? Be honest with yourself.

A desire to outshine a teammate isn't passion. Nor is a motivation to impress the boss. Neither is a combination of the two worn as a magic defensive cloak against downsizing spells. These are second-rate, artificial passion substitutes: Mixed into the recipe, they yield sub par results, often leaving a nasty aftertaste of burnout and dissatisfaction.

Instead I'm talking about a bona fide interest and enjoyment of the craft and challenge of software development, even outside of career or job security issues (though it benefits the same). This isn't a job ad demanding that you're "passionate about business reports!", but rather is just a moment for sober reflection on whether you're over-clocking life, or running idle instructions in a tight loop.

If you're like many software developers in the industry today, a feeling of enthusiasm and enjoyment for the pursuit is just a distant memory (often during the happy days of university and your first job). Instead it has become a career, and is just something you do from 9-5 (or more when passion is replaced by sacrifice). Skills have likely stagnated, moving just enough to compete with coworkers, or to avoid obsolescence.

Of course there are those who've never enjoyed this career, and they probably will never enjoy it -- it just isn't their thing. The only advice I can offer to those people is a suggestion that life is too fleeting to spend so much time doing something you don't enjoy.

Many others, however, remember the passion, and sporadically get a fleeting taste of it again. For those people I propose some personal habits that, coupled with workplace practices (for managers, as well as people who rightfully manage up), will help recapture and maintain that passion.

Software developers who truly love what they are doing are the ones creating the most innovative code. They're the ones with productivity rates multiples of their peers. They're the ones that feel a little guilty getting paid to do something they enjoy so much.

The Top 5 Habits of Productive, Happy Software Developers

1. Be Marketable - Keep Up To Date Skills and Network Contacts

Most of us will work for over a dozen different firms over our careers.

We'll leave for better salaries and working conditions. We'll relocate to accommodate a spouse's career. We'll be laid off during corporate mergers and spin-offs, or even when the company goes bankrupt. We'll get turfed out because we're over-skilled, and thus overpaid, relative to the needs of the position. We'll be downsized because we aren't compatible with the new boss' empire building schemes. Maybe we'll get bored of a position and seek out something new.

This is the employment reality of most careers in the 21st century.

To some professionals this represents an exciting journey, and each transition is met with anticipation and enthusiasm. These people feel confident in their abilities, have a network of peers in the industry communicating interesting opportunities, and their skillset is up-to-date and marketable (they have the appropriate laundry list of abilities, credentials and certifications, and upgrade as needed), and while the possibility of their current employer closing shop tomorrow is something they'd prefer not happen, and they probably love the great group of people that they work with, it isn't something that they fear.

To less prepared professionals, however, the idea of losing their cushy job hangs over them like a black cloud. Their lack of apparent opportunities, and the feeling that they couldn't find an equivalent job, is enormously destructive of both motivation and job satisfaction. Paradoxically, job protectionism (such as making one "indispensable" through obscurity, by denigrating coworkers, and so on) often becomes a more likely activity of people in such positions than legitimate contributions.

This is incredibly destructive to morale, not just for the individual in question, but for everyone on their team: Often the malcontent, contagiously demotivated member of the team is the least employable, and it can be debated which condition led to the other.

SUMMARY:  No matter how much you love your current job, you should keep your CV current, and you should always keep up-to-date on industry opportunities. Know what skills are in demand, and try to gain experience in them (even if it means pursuing formal or self-training during your own time), and attain a level of comfort that you could transition to a different opportunity with minimal discomfort.

MANAGER SUMMARY: You should do everything in your power to make your group feel confident in their abilities -- ensure that everyone gets a chance with marketable technologies; encourage the pursuit of desirable certifications; and build skills through internal resources, workshops, and seminars. Unless you're running a sweatshop, this is unlikely to lead to a feared exodus of employees, but instead will empower and motivate your group to more openly contribute, and to demand more of each other.

2. Be The Master of Your Domain

The control we have over our environment can have a tremendous impact on our happiness. 

Something as simple as a sporadically malfunctioning key on our keyboard can ruin an entire day, for instance. Similarly, when you're nearing a deadline and your network connection starts flaking out, it can make an enjoyable jog to the finish line a frustrating exercise of physical restraint (in this case restraining yourself from tearing the wiring out of the wall). At least we have optical mice now, eliminating one of the primary causes of environmental control frustration.

Many times our work habits inevitably bring a feeling of "lack of control" into our work lives: By failing to fully read the documentation for our tools, investigating their behaviour, APIs, and nuances, we often create a situation where much of our development is basically crap-shoot trial and error, reacting as things don't work as planned.

I've witnessed development groups, not to mention that I've demonstrated this unsavoury trait myself, unhappily fighting with perceived technology deficiencies (usually as a deadline rapidly approaches), moaning and complaining about what seems to be faults in the language, technology, or platform, forever building workarounds under a fog of uncertainty, when in reality it was actually a fault in the understanding of the same. 

More often than not it's simply that they haven't spent the upfront time to understand the language (I remain amazed at the number of C# developers who have no idea what the using keyword is for, or why seemingly out-of-scope file objects are still locking files until some magical, indeterminate time in the future. Or the Delphi developers who needlessly nulled variables at the end of scope in a futile misguided attempt to fight mystery bugs), the technology, or the platform. Their frustration is created out of ignorance, and a small up-front investment would have sped up development, increasing the sense of control that the developers have over their domain.

SUMMARY: The next time something seems mysterious or unknown, take the time to properly investigate it. Classic lack-of-control approaches such as hacked workarounds or "reset the server daily" lead to a feeling of losing control, reducing job satisfaction and adding to the natural daily frustrations. And get your keyboard replaced if it starts malfunctioning.

MANAGER SUMMARY: Identify and investigate "easy-outs" proposed by your development team. While most software has faults, and products and technologies often work differently than we might imagine, many times such excuses are due to a lack of investigation and analysis. Even when things don't work as advertised, which is frequently the case, formally investigating and empirically determining behaviours is vastly superior to each developer endlessly fighting with and then hashing out strategies on a need basis. And make sure your developers have functioning keyboards.

3. Accommodate Your Financial Needs

I've worked in some great positions at the wrong times in my life, sapping my motivation until eventually I moved on. These positions were for great firms, with great working conditions and great coworkers and management, but it couldn't realistically adapt to accommodate my evolving financial needs. I invented dissatisfactions with the situation, turning an ideal situation into a daily torture.

After getting married and planning for our first child, for instance, the financial risk/reward that worked when I was living alone in a $600 apartment eating Ramen noodles was no longer satisfactory. Demands of owning a home, a car with infant carseats, education funds, daycare (for two children costing more than it would cost to lease two (2) BMW 750i's), and boxes and boxes of diapers, required more financial returns than I needed years before.

I moved on.

While the resulting role superficially wasn't as satisfactory, from a life perspective my mood brightened dramatically, and my day was much more enjoyable.

Of course this seems like cheap advice: Make more money! And Fast! Yet the reality is that developers often do make choices to the detriment of their financial condition, and if they go too far they will hate their job no matter how perfect it otherwise is. Working for equity of a start-up is great when you're just out of university, but it is destined for failure when you're more established.

SUMMARY: If your financials are out of balance, it will unavoidably sour your mood during the workday, making you resent your employer and your workplace. When life goals exceed the income of your position, immediately begin investigating alternatives (be it asking for a raise, looking for a more senior role in your organization, or seeking employment elsewhere). No motivational boost or cool company games room will overcome this basic life need.

MANAGEMENT SUMMARY: Be aware of the goals and needs of your group. Sometimes someone's needs grow beyond the possible return of a position, and it is important to appropriately communicate this (rather than giving vague hints of unseen raises and super-bonuses at some future point).

4. Have A Life Outside of Work

This is a rule that works for all professions -- having accomplishments providing satisfaction outside of work will smooth the inevitable downs of our professional lives, often providing one with a much better perspective. Without this, often minor workplace failures can explode into seemingly momentous events.

These accomplishments can even be in the same domain: A professional coder by day, and an open-source coder by night, for instance.

SUMMARY: There will be periods when everything seems to go wrong in the workplace. Having the cushion of achievements outside of work can avoid it spiraling into a workplace disaster, keeping spirits up through the tough times. Often non-work experiences benefit the workplace as well, whether it's techniques learned from nighttime projects, or delicious coffee courtesy of the nighttime barista classes.

MANAGER SUMMARY: There is a world outside of work.

5. Properly Manage Expectations

Developers, as a general rule, are terrible at managing expectations: Many of us are prone to overpromising deliverables, assuring stakeholders that we'll deliver these amazing results sooner than is reasonable. I've fallen victim to this syndrome myself, and I've seen it occur rampantly across the industry.

When D-day comes we convince ourselves into believing that the users built their own unrealistic expectations, and managers forced us into untenable timelines. While often that is the case, just as frequently the developers were the origin of misinformation. 

While there is a temporary sense of satisfaction wowing users and management with an exaggerated declaration of our abilities (we've likely even convinced ourselves), as time wears on this misinformation can be enormously destructive and debilitating. With every day closer to the deadline we get a little more desperate for a silver bullet, hoping that some magic technology or component will deliver us from damnation.

It seldom works out that way.

Users are unhappy. Management is dissatisfied. Employees are demoralized and devastated.

The best option is always to manage expectations, to ensure that we can reasonably deliver promised results without heroic effort.

SUMMARY: Plan for the long term, realizing that promises that aren't delivered on will cause you great workplace unhappiness later. Manage expectations to ensure that you can satisfy your "customers" with reasonable effort, and with a reasonably high probability of success.

MANAGER SUMMARY: Never demand unrealistic deadlines, and question employees when provided with the same. Encourage your troops to be more reasonable with their promises, especially to stakeholders outside of the group, and they'll have a much greater probability of meeting external expectations, leading to increased motivation for everyone.

Conclusion

This is an amazing, expansive career full of incredible innovation and endless opportunity. Ensure that you don't diminish your enjoyment through simple mistakes, such as pigeon-holing into a position, or endlessly setting up yourself for failure.

Control your destiny.

Tagged: [Software Development], [Programming], [Software-Development]

I've been doing this as a somewhat regularly updated blog for just over half a year now, and the results have been extremely satisfying: I get about ~2500 direct unique visitors on an average day (increasing 2-6x when something ends up being a meme-of-the-day on sites like Reddit or Digg, and of course many read via aggregators), search engine referrals are up to 200 or so a day, and viewing the "who's on" list is a laundry list of influential corporations and locations across the globe.

It does feed my ego a little bit seeing visitors from various governments, the CIA, nuclear research labs, just about every large financial company, and visitors from every end of the globe. My numbers aren't huge, but it's a perfect composite of influential and knowledgeable readers.

The most popular entries thus far are as follows (I'm providing the static version links where possible):

Effectively Integrating Into Software Development Teams
Optimal Software Development Processes and Practices
Spelling Matters
Everyone Is Above Average - The Overpopulated Top 2%

I've tried to minimize the number of entries (outside of the personal category, though this anniversary one being an exception) to keep the noise as low as possible -- if you're using a reader it won't constantly pretend there's new content when I'm just adding a peanut gallery comment about someone else's blog -- though on the flip side that means that I've delayed various .NET and SQL entries until they're "perfect". 

Perhaps I might have to find a compromise somewhere in between.

The Odd OS Out

In the world of the wiki, being in the Windows camp sometimes makes you feel like a second-class citizen.

Much of the information for wikis on the Windows platform is either out of date, or just plain wrong. Many of the tools encourage users to simply accept Linux into their lives, giving vague warnings about the dire consequences that await if they dare to host the product on Windows.

While Linux is undoubtedly the optimal solution in some cases -- such as when you can requisition or reconfigure existing hardware to act as a new Linux server, or when you're using some of the superlative virtual machine solutions -- many shops lack UNIX/Linux skills, or they simply want a homogenous platform, and thus would prefer to stick to the Windows platform even if it wasn't the native-environment originally envisioned.

Sometimes the team is skillful and adept with Linux, but the corporate IT department brutally seeks out and destroys rogue PCs running the unauthorized OS, storming the department in a flurry of flying pocket protectors.

All is not lost, however.

Wikis To The Rescue

Not only are there numerous wiki or wiki-like products (yafla provides Sharepoint consulting in addition to wiki solutions, however Sharepoint fulfills a subtly different niche than wikis) available for the Windows platform, you can even host the trendsetter in the wiki world - MediaWiki - on Windows.

MediaWiki, as you likely know, is the rapidly evolving software platform on which Wikipedia is based. It's free to download and use, even for big, soul-less corporations.

So without further ado, the following is a no-nonsense guide to getting MediaWiki installed on Windows XP, Windows 2000, or Windows 2003. This is intended to get you up and running, and if you find that you like the platform and the package then you can start looking into advanced customization and locking down (for instance you can configure a Wiki to only allow authorized users to make changes, with authorized users only being created by users with appropriate privileges. This eliminates the primary fear of most wiki-holdouts -- a fear that a wiki is a crazy free for all).

My primary goal is simply to get people looking at wikis, seeing how simple it is to configure them. In Optimal Software Development Processes and Practices, I wrote about the need for formulating written standards. The reason many teams shirk from such a task is because it's one that appears to have a lot of upfront, contentious work involved, generating the first version of the definitive Corporate Standards guide. Using a wiki, though, and you can organically grow team information like standards, adding small additional pieces of information as they come up, with extraordinarily easy editing, organized centralization (which I covered in Organize Your Information), and full history and revision control.

A wiki can be a tremendous information tool for modern teams. It works in the way that information is often accumulated, and not in the spastic, all-or-nothing manner usually pursued.

Common Steps

1. Download and install the feature-rich 7-zip. This will facilitate unzipping/untarring files further in the process. Log out and back in to enable the GUI extensions. 
2. Download and install the GNU diff utilities. You can get by with the "complete package, except sources". Note where you installed it, as you'll require the location in a later step (this will likely be C:\\Program Files\\GnuWin32).

Option 1 - The WAMP Platform

You've probably heard the acronym LAMP (Linux + Apache + MySQL + PHP/Perl/Python). It's the description of an important and somewhat standard technology stack on which a tremendous number of very successful solutions are built. It's extraordinarily feature rich and capable, not to mention that it comes at a very good price.

AMP is all of the stack on a platform other than Linux, WAMP being Windows + Apache + MySQL + PHP/Perl/Python.

One of the easiest and most-up-to-date options to configure WAMP on Windows is the DeveloperSide.NET Web-Server Suite. Offering a free, pre-packaged configuration of the fundamentals, this option can get you up and running in little time, even on the "non-server" Windows XP.

1. Download and install the self-installing DeveloperSide.NET Web-Server Suite at http://www.devside.net/web/server/free/download. Note the install location (by default C:\\www). Restart when prompted.
2. If you already have the IIS World Wide Web Publishing running, there will be a conflict over port 80. You can move your wiki to a different port by modifying C:\\www\\Apache2\\conf\\httpd.conf. You can then run C:\\www\\Apache2\\bin\\ApacheMonitor.exe to stop and restart the service. If you opt to do this you'll have to append the port when you access your wiki (e.g. http://localhost:85 if you chose port 85) in later steps, and this could cause problems for machines with software or hardware firewalls between them and the wiki, which usually only expect HTTP traffic on port 80.
3. Delete index.html from C:\\www\\webroot (altering the path if you have a different install location from step 1).
4. Download MediaWiki. For this setup I grabbed 1.5.6, which is a stable release from January 19th, 2006. When you read this something newer may be available.
5. Right click on the downloaded file (mediawiki-x.x.x.tar.gz, where the x's represent the version number - e.g. mediawiki-1.5.6.tar.gz) and pick "7-Zip -> Extract Here".
6. Right click on the newly ungzipped file, mediawiki-x.x.x.tar (where of course the x's refer to the version number. e.g. mediawiki-1.5.6.tar), and choose "7-Zip -> Extract Here".
7. Copy the contents of the newly extracted folder - e.g. mediawiki-1.5.6, to C:\\www\\webroot, altering if you have a different base directory in step 1. For instance navigate into the folder, choose Edit/Select All, Edit/Cut, navigate to C:\\www\\webroot and choose Edit/Paste).  You should now have files such as wiki.phtml in the folder C:\\www\\webroot.
8. Open a web browser pointing to http://localhost/ (or the IP or DNS name of whatever server you've installed this on), and you should be presented with a page telling you to setup the wiki first.
9. Everything should be fairly self-evident. After setting passwords for the sysop (which is the account used to administer through the wiki web app), as well as for the new MySQL account, be sure to clear the password at the very bottom, as by default MySQL was installed with no password on the root account, albeit limited to local access.
10. Copy LocalSettings.php from C:\\www\\webroot\\config\\ to C:\\www\\webroot\\.
11. Configure the email server appropriately - if you're running the IIS SMTP server locally you're good, otherwise you need to make a configuration change so the wiki is capable of sending email.
12. Access your wiki! Start editing and creating pages (search for a new topic, and then click on this exact title in the resulting search failure page -- you're now editing the new page!), organically growing your information base! Select Edit on complex Wikipedia entries to see how features like categorization, sections, sidebars, and images are achieved.
13. Read the User's Guide to see how to customize things like images, templates, allowing uploads and images, and so on, and how to edit pages. Login as WikiSysop (or whatever else you named it) and play around with preferences, special pages, skins, and so on. Create accounts for members on your team.
14. If you find that you like the platform, remember to make a backup strategy for your MySQL wiki database.

Option 2- The WIMP Platform

IIS 5.1, and moreso IIS 6.0, really is a superlative web server, and in security metrics it's actually been beating out Apache. It's fast, capable, and you probably have other applications running on it (e.g. .NET apps), and perhaps you don't want the heft of a second set of webserver services running on your machine simply to host a new web app.

Well you don't need to run Apache for MediaWiki if you don't want to.

This configuration is a little bit more involved as I've chosen to recommend the individual constituents, but in the end you'll have what could be considered a more granular, controlled configuration than using one of the all-in-one stack solutions.

This presumes that you've already installed IIS. If you haven't, used Add or Remove Programs and add IIS in Add/Remove Windows Components.

1. Download and install MySQL (in this case I downloaded and installed the 34.9MB v5.0.18 "Windows (x86)" variant), using the "Typical" install options. In the detailed configuration choose appropriate settings (for instance Developer Machine if you're just doing a trial run), noting the new root password for the database server (you'll need this later, as by default this stand-alone install is more secure than the packaged bundles).
2. Download the "PHP 5.x.x zip package" (not the installer), for instance PHP 5.1.2 zip package.
3. Right click on the downloaded file and pick 7-Zip->Extract Files. Enter C:\\PHP as the path.
4. Copy libmySQL.dll from C:\\program files\\mysql\\MySQL Server 5.0\\bin to C:\\PHP.
5. In C:\\PHP, rename php.ini-recommended to php.ini.
6. Open php.ini in notepad.
7. Find the line (Edit/Find) extension_dir = "./" and change it to extension_dir = "C:\PHP\ext"
8. Find the line ;extension=php_gd2.dll and remove the leading semicolon, leaving extension=php_gd2.dll
9. Find the line ;extension=php_mysql.dll and remove the leading semicolon, leaving extension=php_mysql.dll
10. Save the file and exit notepad.
11. Add C:\\PHP to the path (Start/Control Panel/System/Advanced/Environment Variables. Under System Variables, double click Path and append ;C:\\PHP on the end (note the semicolon).
12. Add a new system environment variable (Start/Control Panel/System/Advanced/Environment Variables) called PHPRC, with the value C:\\php
13. If you're running Windows 2003, run Start/Administrative Tools/Internet Information Services (IIS) Manager. Expand the local computer, and choose "Web Service Extensions". Select "Add a new Web service extension". Give it the name PHP, and then Add  the required file C:\\PHP\\php5isapi.dll. Set the checkbox "Set Extension status to allowed". This will allow the extension to run.
14. In IIS Manager, expand websites and right click on Default Web Site. Choose the Home Directory tab, and select the Configuration button in the Application settings section. Click on the Add button in the Mappings page. For the executable, enter C:\\PHP\\php5isapi.dll, and for the extension enter .php. Ok all of the dialogs.
15. In IIS Manager, expand websites and right click on Default Web Site. In the Documents tab select Add and configure the new default content page to index.php. Ok out, and choose Move Up until index.php is at the top of the list.
16. Complete steps 4 to 12 from the WAMP configuration, replacing all references to C:\\www\\webroot with C:\\Inetpub\\wwwroot. Also be sure to enter the root MySQL password that you set in step 1 into the Wiki setup page. As one last hiccup, you will likely have to provide the account IUSR_LOCALMACHINE, where local machine is the hostname of the machine in question (e.g. IUSR_MyServerA1) with full control of the C:\\inetpub\\wwwroot\\config directory during Wiki setup, allowing it to emit the generated setup file. You can remove it right after generating and copying the LocalSettings.php file. Alternately you can customize the account under which the web site is running.
17. If you wish to enable uploads, you will also have to configure directory access on C:\\inetpub\\wwwroot\\images, allowing the account under which the web application is running to have access to modify files in that directory. For instance add IUSR_LOCALMACHINE (again where localmachine is the hostname of the machine in question, such as IUSR_MyServerA1), or whatever other account you have the application pool running under, to have full control of the directory, or simply give it Add File permission and add full control to the CREATOR OWNER virtual account.

Voila, a high performance wiki hosted with IIS on Windows. Now if only there were a ASP.NET 2.0 fork with all of superlative MediaWiki functionality and usability, coupled with a SQL Server back-end...

Once you have the platform configured to demonstrate the concept to yourself and your team, you can begin altering the look and feel, and enabling huge performance speed-ups such as the PHP compiled caching extensions and memory caches. This is just a powerful starting point.

After fielding several wiki-related queries by clients and associates, along with numerous questions and comments online, it is evident that it's the Year of the Wiki. Wikipedia has proven the concept, and users have a growing awareness of the benefits that organic information growth could bring to their teams.

As such, I'm putting together a feature covering wiki options and alternatives, including specific instructions for configuring and using Wikis on Windows (as this is a particularly neglected area, and much of the information that exists is terribly out of date or quite simply non-functional). Of course yafla provides turnkey Wiki solutions and training as a service as well.

One more point: The consulting work has always overflowed purely from word-of-mouth and associate networking, so the business website has always been terrible (sort of the whole "the cobbler has the worst shoes" thing). As yafla is now entering a growth stage, wailing past the temporary manpower limit, I'm finally going to change the corporate website to properly reflect the services and capabilities of the organization, and actually allow options for prospective clients to engage our services. That should be up shortly, growing and improving rapidly over the coming weeks.

Three yafla resource "shout-outs":

yaflaColor - A dynamic web tool to select colors, including proper saturation and lightness varations of colors
pureJpeg - Remove extraneous JPEG blocks
High Performance SQL Server - Information to ensure your database designs and usage are optimal

Have a fantastic weekend!