When Java first hit the development ecosystem, to many it wasn't just a method of doing efficient, high-level development, but rather it became a new religion: You couldn't only use Java as the glue between existing code, or even as the overwhelming bulk of your solution. A partial-Java solution simply wasn't good enough.
Instead your product had to be 100% Pure Java. The still sought-after eventual goal was a complete Java solution, from applications right down to the operating system, with only the smallest possible binary kernel, if even that. All of this would be running on a Java-aware processor, engineered specifically for Java.
Sun created a "100% Pure Java" campaign to push this philosophy, including banners and designations for appropriately certified software, and advocated it as a very desired moniker. Users were led to feel that mixed solutions were impure and somehow dirty: Are you some sort of nut running an impure solution, dirtied with some pointer munging, buffer overflow vulnerable C code? While there were (and remain) methods to call native code, they were discouraged.
Of course there is a lot of validity to this agenda. Primary being the fact that pure Java solutions are theoretically cross-platform, with no ties to external technologies. Compare this to a solution leveraging C libraries, which would require a rebuild or binary available for every distinct target platform. Additionally Java could only impose its sandbox and extensive security constraints if you stayed in the world of Java, and thus callouts to native code represented a risk.
In the real world, though, it often meant that developers were constantly solving long-conquered problems, redundantly reinventing solutions in Java that long existed elsewhere, or waiting until adequate libraries eventually appeared: Developers were pressured to use Java alone even when it was a hammer and the solution really needed a chisel.
Thankfully .NET hasn't been pushed in such a single-minded way (even if some of its champions have foolishly taken up such a misled cause, including some at Microsoft. Instead of a justified part of the solution, it becomes a religion. .NET! .NET! .NET! .NET!), and indeed Microsoft themselves has always facilitated, and even advocated, "impure" solutions. The majority of the .NET Framework, for example, is actually a very thin veneer over the existing Win32 facilities and libraries -- it was either that, or version 1.0 would have come with a much smaller, much less efficient library.
The "orchestration layer over native code" implementation is the reason .NET hasn't suffered the performance difficulties that Java has.
Microsoft chose to leverage what
they'd already done, to maximize both performance, and to maximize
the breadth of the library.
This advantage isn't limited to Microsoft, though, and the developer can utilitize this functionality as well. .NET offers very simple COM and P/Invoke functionality to leverage "legacy" code (or even new code developed in a best-solution, non-.NET technology), allowing you to easily use your existing DLLs and/or COM libraries as first class partners in your .NET solutions. Even if they're created in "dirty" languages.
I take advantage of this functionality regularly, utilizing existing best-solution libraries and functions, regardless of whether they're pure .NET or not. For instance in creating the static version of the "best of" blog entries, I quickly -- maybe 2 hours -- wrote a quick transformation tool that basically imported the "best of" RSS feed (it isn't included in the normal category lists), then doing some XSL transformations (using extension objects in the XSL given that XSLT alone wasn't adequate for some special purposes -- for instance HTMLDecoding the description block of the RSS) to the resulting XHTML, as well as creating an index page.
One goal when creating this solution is that the resulting pages are all fully XHTML compliant, and they pass the W3C validity checks. While I could easily see how the pages rendered in Mozilla/Firefox/IE/Opera, and of course they all rendered fine, technically there were a couple of deviations from the spec. Some of these errors and warnings were caused by unavoidable transformation issues, while others were caused by minor mark-up errors in the original blog entries (both because of my own errors when doing it by hand, but also because of Radio Userland's "helpful" auto-"cleanup" of HTML. It is remarkable how often auto-formatting is detrimental).
HTML Tidy to the rescue.
I had several options with HTML Tidy, the easiest of which would be to ShellExecute out to the EXE, telling it to process an existing file. I could have taken more time and tried to make a managed C++ version of Tidy, but I really didn't want to spend that much time.
I decided to have a bit more fun, not to mention building a more integrated, higher performance solution, and use the Tidy dll from the micro-.NET utility. I grabbed the Tidy source code (Tortoise CVS is a great solution for this, in this case using :pserver:anonymous@cvs.sourceforge.net:/cvsroot/tidy), updated the included MSVC projects to Visual Studio 2005, and added them to the transformation utility solution. I set the Tidy dll project output to the build directory of my .NET utility (in this case $(SolutionDir)\blogStatic\bin\$(ConfigurationName)). The MSVC build worked perfectly right away, which is amazing given that Win32 isn't an officially supported build.
To reference the Tidy dll methods, of course I had to add the DLL import signatures, in this case adding only the ones I had a need for.
[StructLayout(LayoutKind.Sequential)]
struct TidyBuffer
{
public IntPtr
bp;
/**< Pointer to bytes */
public uint
size; /**< #
bytes currently in use */
public uint allocated; /**<
# bytes allocated */
public uint
next; /**<
Offset of current input position */
};
class FileClean
{
[DllImport("libtidy.dll")]
public static extern IntPtr
tidyCreate();
[DllImport("libtidy.dll")]
public static extern int tidyParseFile(IntPtr
tidyPointer, [MarshalAs(UnmanagedType.LPStr)]string
fileName);
[DllImport("libtidy.dll")]
public static extern int tidyParseBuffer(IntPtr
tidyPointer, ref TidyBuffer tidyBuffer);
[DllImport("libtidy.dll")]
public static extern int
tidyCleanAndRepair(IntPtr tidyPointer);
[DllImport("libtidy.dll")]
public static extern int tidySaveFile(IntPtr
tidyPointer, [MarshalAs(UnmanagedType.LPStr)]string
outFileName);
[DllImport("libtidy.dll")]
public static extern int tidyRelease(IntPtr
tidyPointer);
[DllImport("libtidy.dll")]
public static extern int
tidySetCharEncoding(IntPtr tidyPointer,
[MarshalAs(UnmanagedType.LPStr)]string encoding);
[DllImport("libtidy.dll")]
public static extern int tidyOptSetBool(IntPtr
tidyPointer, int value, int Bool);
public static
bool CleanFile(System.String outputfileName, System.IO.MemoryStream
docDataStream)
{
int result = -1;
IntPtr tidyPointer = tidyCreate();
try
{
// We want the resulting
file to be UTF8 encoded
tidySetCharEncoding(tidyPointer, "utf8");
byte[] docDataArray = docDataStream.ToArray();
TidyBuffer tidyBuffer;
tidyBuffer.size =
(uint)docDataArray.Length;
tidyBuffer.allocated =
(uint)docDataArray.Length;
tidyBuffer.next =
0;
GCHandle pinHandle = GCHandle.Alloc(docDataArray,
GCHandleType.Pinned);
try
{
tidyBuffer.bp =
Marshal.UnsafeAddrOfPinnedArrayElement(docDataArray, 0);
if (tidyParseBuffer(tidyPointer, ref tidyBuffer) >= 0)
{
tidyOptSetBool(tidyPointer, 29, 1);
tidyOptSetBool(tidyPointer, 23, 1);
if (tidyCleanAndRepair(tidyPointer) >= 0)
{
result = tidySaveFile(tidyPointer, outputfileName);
}
}
}
finally
{
pinHandle.Free();
}
}
finally
{
tidyRelease(tidyPointer);
}
return (result == 0);
}
}
Most of this should be self-evident, however the two tidyOptSetBool calls may be a little cryptic. For the sake of brevity I haven't used the constants, but 29 is the TidyMakeClean value of TidyOptionId enum (see tidyenum.h), and 23 is the TidyXhtmlOut value. Together these indicate that I want to clean the documenting, converting it to XHTML. Note that I've also set the encoding to UTF8.
Voila, after transforming the RSS to the memory stream as quasi-conformant HTML, I passed the stream to this function, along with the desired output filename, and out went a cleaned-up, valid XHTML document. Pedants everywhere were thwarted from pointing out minor deviances from the standard. I could have processed to another buffer, and then done follow-up processing in .NET as well, but this was sufficient.
This is a trivial example, but it really exemplifies the great value of the easy interoperation of .NET. With it I could instantly leverage existing code, without having to search out bastardized ported versions, and instead could go right to the source.
This is a preview of an article scheduled for completion before the week is out (and while it shares superficial similarities to a recent Paul Graham article, it was started before Paul "published", and has been a topic that I've long wanted to cover).
I've dedicated a little more time to writing now, and should finally complete another commissioned magazine article over the next month (this one on distributed/symmetrical computing with .NET), which will be satisfying to finally .
Software development can be a tremendously rewarding and 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.
This article describes the wonder and curiosity that many developers start out with, whether it's when they pick up their first JavaScript in 1 Hour book, when they start toying with the gcc compiler for the first time, or when they started their first Computer Science course in university. It 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).
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. All of those are second-rate, artificial passion substitutes: Mixed into the recipe, they yield subpar results, often leaving a nasty aftertaste called 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 most 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 (and will never) enjoyed this career. 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 sporatically get a 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), that 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 in the industry. They're the ones getting paid to do what they love doing.
...
I have been considering the possibility of yafla providing training services, developing and delivering programs here in the Greater Toronto Area (and globally where the monetary return makes it worthwhile), adding this service to the existing software development, outsource management, and consulting options. Not only is it an additional revenue stream, much more importantly it's another potential avenue for making contacts and getting involved as a vendor with new clients, creating opportunities to more easily offer our other services.
I've done a lot of group training in the corporate space, have been involved in quite a few tutorials and online training guides, and find it to be a very rewarding pursuit. Several of my associates have been heavily involved in the training industry during periods of their career. The possibility of hosting an "Advanced SQL Server" seminar or workshop, for example, seems very exciting.
We're very equipped to perform this task, and we certainly can do a better job than all of the trainers I've been exposed to. Our approach would never be to dedicate anyone to training alone (or even as a substantial period of their time), as continuing and up-to-date real-world experience would be absolutely critical to the program.
As such, I'd greatly appreciate any input anyone might have regarding the technical training industry, and how external training programs work at their organization. I know many mid- to large-sized firms have an "authorized training vendor", basically ensuring a universally weak level of training throughout their organization, and that could present a significant barrier to entry.
Earlier this month -- January 4th to be precise -- I posted an entry regarding optimal software development practices (here in archived form), one of the most important points being that teams should "Focus On Results Instead of Effort and Sacrifice".
Focusing on results instead of effort and sacrifice can be realized in many ways; For instance by using the easiest possible tools and technologies that acceptably achieve your results. By cancelling long, drawn out meetings that everyone hates if the meetings don't achieve results. By ditching any process that is nothing more than cargo-cult remnants.
It's a simple perception change that forces one to evaluate the actual benefit yielded by extended efforts, rather than blindly applying brute force with hopes that it magically yields returns.
This rule isn't just for workplace practices, though, but applies to our day-to-day living as well. For instance making a delicious cup of coffee.
I recently came across a widely referenced piece, "A Coder's Guide To Coffee", which details the various steps that one should take to achieve a drinkable cup of coffee. It's an interesting read, and serves as an entertaining bit of additional knowledge about the craft of brewing. Nonetheless, as I read it I imagined countless people creating subpar, or even just par, cups of coffee, confident that the additional care, concern, and manual effort they put into the effort guarantees them a better cup of coffee.
It doesn't.
In fact it could lead to much worse results, not to mention that it took a lot more effort to yield those worse results in the first place.
Most of the time I drink packaged coffee, brewed in an often-dirty automatic drip coffee maker (it isn't the height of science getting water just below the boiling point, and in fact many automatic drips work by boiling water up from the reservoir, letting it cools the perfect amount while dispensing. In essence the water temperature is guaranteed perfect by the thermodynamics of the design). It requires close to no effort on my part, yet most of the time my coffee is (in my humble opinion) extremely good. For any normal coffee drinker it would be close to the "perfect cup", and unless you had dedicated your life to the classification of coffee, or you're on to drinking only coffee defecated from civets, you probably won't notice the difference from the most effort-encrusted specialty coffee. The only thing my coffee lacks is the placebo effect of imagined advantages.
Getting the "perfect cup" was incredibly easy: I found the perfect water/coffee ratio for my particular tastes, my cheap drip coffee maker does a very credible job (and provides water at the perfect temperature), and I brew small enough pots that coffee isn't sitting for very long before being consumed.
I tried a wide variety of grind brands and roasts, and eventually found a couple that are predictably good, so they're my staple. Occasionally I buy some of the "bulk" gourmet coffees (although the results there have been negative as often as they've been positive. The large coffee manufacturers seem to have the process down to much more of a science than the local coffee house).
Even the most common, most pedestrian, package ground coffee is made with 100% Arabica beans, so that isn't too much of a concern, and the whole Robusta red herring is a bit of cheap, disposable advice.
So without further ado. Here's the amazing magic of making the pragmatic perfect cup of coffee!
That's it.
Focusing on hand roasting your beans, or manually brewing, is absurd when the overwhelming majority of the population can't even accomplish the basics consistently. Following those simple rules gets you to the point of extraordinarily diminished returns, and it is the Pragmatic Perfect Cup.
Of course you could hand craft your own gathering containers, walk 500 miles barefoot to hand pick only the cutest beans from the largest jar, brew with the most remarkably pure spring water after having it blessed by the saint of coffee in a pot made of the purest of silver, using beans ground with ancient Egyptian artifacts, but that doesn't mean that you'll yield a better cup of coffee, unless you're susceptible to the placebo false return effect.
Oh, and occasionally clean the pot. I think I'll go do that right now.
#define KNOW_IT_ALL_DEVELOPER 64
#define TEAM_VIEW_OF_THE_NEW_GUY 8
#define UNWANTED_INPUT 1
int team_integration[TEAM_VIEW_OF_THE_NEW_GUY];
team_integration[KNOW_IT_ALL_DEVELOPER] = UNWANTED_INPUT;
The following is an email I could have gotten recently.
Hi there. First time caller, long time listener. You're the greatest, and your words are like gold!
I recently took a new software development job, and I've been experiencing a lot of ill will from coworkers and peers. It's really been killing my job satisfaction.
To explain, I was recently brought in to help a software team get a product out the door, with a mandate of helping with some web app code. I've been trying my best to integrate with the team, trying to earn some credibility and respect by making myself useful.
I've been forwarding various Joel On Software essays to All, recommending that the office stock up on Code Complete, Peopleware, and the Mythical Man Month, and I make an effort to point out everything I believe could be done better. I regularly browse through the source repository to find ways that other members could be working better.
When other developers ask for my help, I try to maximize my input by broadening my assistance to cover the way they're developing, how they could improve their typing form, what naming standard they use, to advocate a better code editing tool, and to give my educated final word regarding the whole stored procedure/dynamic SQL debate.
Despite all of this, I keep facing resistance, and I don't think the team likes me very much. Many of my suggestions aren't adopted, and several people have replied with what I suspect is thinly veiled sarcasm.
What's going wrong?
Are these developers just afraid of change? Are they so stuck in their ways? Do they simply LIKE doing things the wrong way?
Yours truly,
The New Guy
Thanks for writing New Guy. It's a thrill when I can manufacture a cheap strawman to make a point, so I welcome the opportunity to address this scenario.
Let's get to why you're experiencing what you're experiencing.
Many development shops operate as a zero sum game: there are a fixed number of promotions, raises, and apple-of-the-boss'-eye positions that everyone is competing for, and thus one developer's gain is at the cost of the rest of the group.
Given this sad reality, when a new recruit joins the team, there may be resistance, particularly among less confident groups and team members, and attempts could be made to limit the recruit's influence by deriding their ideas, limiting their input, and marginalizing their contributions.
The longer the existing team has been in place, and the less confident they are about their positions and their skill, the worse this problem usually is.
Of course, their fears may be well-founded. Many new hires are motivated to push silver-bullet methodologies, to lazily advocate quick-fix online essays, and to make superficial commentary about how to improve the code and the products, is the desire to earn themselves enhanced credibility with the overseers, and thus the opportunity to fast-track past the existing team members.
About a decade back, I was tasked with building an aggregation system to pull together data from facilities across the continent, and to perform some rudimentary filtering upon it. The eventual result of this effort was a rather ugly creation that I was both proud of and ashamed of at the same time.
This system originally grew out of some Excel macros, growing into an Access solution with some simple automation, and then to a SQL Server database with on-demand manual data extractions, and finally to a DHTML web application reporting framework against a data warehouse. Through that evolution it incorporated a mish-mash of technology advances, methodology changes, and of course changes based upon my own knowledge increasing.
Many of the project steps weren't actually authorized -- I built the original application because I was lazy, and wanted to automate some manual tasks I had been assigned -- and the project was always viewed by management as a short-term hack until another of the organization's products could render it irrelevant, so rewrites and major refactoring were out of the question. Requirements and user input was incredibly sparse, and most of the project was developer initiated, with the users choosing what color to paint the shed after the fact.
Remarkably that ugly hack job continues to process data today.
Yet having that product history under my belt made the position close to untenable: With each new developer I got to hear how the data should have been structured, whether more normalized or less normalized; how it should have incorporated as yet uninvented technologies like XML; how it doesn't conform with coding standards imposed years later; how it was theoretically rendered redundant by hypothetical solutions released far later; and how the hack-job code, one of my first projects created in Delphi and Object Pascal, was less than ideal; and so on. Many of these criticisms were made as widely and as loudly as possible, in standard To: All fashion.
Yet, despite all of its real-world warts and appendages, it was a critical part of the enterprise. Despite all of the bold talk about its shortcomings, no one could more than superficially improve it or deliver any real alternative.
And that's the reality that new recruits walk into -- products created in less than ideal conditions, with limited requirements and limited sponsor backing, under absurd time constraints, by developers not entirely adept at the technologies, and with limited or non-existing supporting technologies (ADO, for instance, didn't even exist yet). Developers who live through such a history are often resistant to brash or unrealistic commentary.
Of course, this doesn't mean that the project deserves no constructive criticisms. Indeed, I would be the first to say that lessons should have been learned from its implementation and failings, and a much better replacement built using all current generation technologies. I was always open to discussion regarding some of the choices made, and to explain its less than ideal architecture.
Yet I grew an instant dislike to anyone who haughtily pronounced its shortcomings.
This is the sort of reality that many new developers walk into, with ugly-offspring projects that are nonetheless loved. The legacy developers know its faults, and while they work to improve those that they can, they accept others as necessary compromises (often compromises of time -- it may be ugly, but it's worked for years so it's not the best place to spend critical time changing). They are naturally defensive of their legacy, while more pragmatic than a fresh "everything should leverage all of the advantages of .NET 2.0" recruit.
In the real world you probably don't need GUIDs for your employees table primary key. In the real world you can use basic authentication and extremely heavyweight reporting solutions (such as Excel automation) on a high value, single customer web server. In the real world client-server architectures can often suffice, and less-efficient code is often satisfactory. In the real world you can often get away with unilingual applications.
Of course in the artificial one-sized-fits-all ecommerce world, all of these are sins. In the artificial world every solution has to be database vendor netural, platform neutral, infinitely vertically and horizontally scalable, immediately multilingual, using n-tier connection pooling via a hierarchy of web services.
The conflict between the real world and the artificial one-sized-fits-all world is a frequent point of contention between new hires and existing teams. One organization's Enterprise solution is another organization's short sighted mistake.
To draw from personal experience again, I farmed some code off to a new recruit once, asking them to build some extensions. Some time later they returned to tell me that the code I sent was clearly flawed, and that it couldn't possibly work due to some perceived flaws. I assured them that the code worked, and they were off again. Once again they returned to tell me that I was wrong. I imagined myself a bumblebee with a distraught aerodynamics scientist informing me that it was impossible that I could fly.
The code I sent them was straight from the production branch, and had been operating robustly for over a year. I quickly demonstrated that they were wrong.
This is a fairly typical scenario, where new recruits place too much confidence in their own knowledge and skills, despite what is often a domain knowledge deficiency, while simultaneously placing too little confidence in the team they are joining.
More often than not that quirky piece of code has a reason, and that seemingly less-than-optimal solution probably has a very good explanation.
Despite all of the selfish and illogical traits described above, many teams are staffed with confident developers who are ready and willing to accept new hires into the fold, and who welcome and respond to criticism and doubt fairly and respectfully. Similarly, many new hires are selflessly trying to contribute their knowledge, and their contributions often are founded on nothing but good intentions. When they are jockeying for position, it's often to earn the respect and trust of their peers rather than to impress the boss.
Having said that, the development community is (at least thus far...unless the robots take over) full of humans, and humans are imperfect. Often we try to boost our own relative position by pushing down others, and we stake out domains that we defend against all logic. By nature most humans are prone to resisting change. New hires need to keep these realities in mind, not only to identify and minimize their own weaknesses, but also to identify the same in others and to adapt to the greatest extent possible, working to integrate without become life-long foes of their coworkers.
Tagged: [Software Development], [Programming], [Software-Development]
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!
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.
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.
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.
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.
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.
