(Incidentally, if you’re checking the Wiki link above before August 30th or so, you’re not seeing the latest version of the Wiki, which includes around 9 months of improvements.)

Who am I to talk about this?

For the last 18 months I’ve been working at Embarcadero Technologies converting the whole of the RADStudio/Delphi/C++Builder documentation over to a MediaWiki based system. As of right now, I have a 7-server continuous-build system designed to build and support both product and language documentation in four languages. I’ve got 18 wikis running off a single codebase with custom skins, custom extensions, and scripts writing and retrieving around half a million pages on a pretty regular basis. It’s fair to say at this point I’m familiar with deploying, maintaining, and working with Mediawiki, both the good and the bad.

Why Mediawiki?

While it brings its share of problems, Mediawiki does a phenomenal amount of what we needed right out of the box. Given that we’ve got an extremely limited budget and an even more limited development team to support a professional commercial product, Mediawiki’s capabilities have been invaluable to us.

Here’s what we’re getting right away:

Easy Syntax

This was the #1 reason we went with Mediawiki – We wanted something where anyone could write new documentation easily, and eventually we wanted to open up the documentation to contributions from customers. Mediawiki has an easy-to-use syntax, and it’s a syntax that many people are already familiar with. Anyone trying to get user interaction on a site knows that even if you write the content for the user you’re still asking too much of them – we wanted as low a barrier to entry as possible, and it’s a fair guess everyone who hits our site has at least Seen Wiki syntax at some point. So far it’s working: one of my best moments at work was when our localization manager complained in jest that our writers were too productive for his budget. We’ve seen a 40% increase in output over the old XML-based system, which is great, and it’s even easier to bring new people up to speed, which is crucial.

Localization

I’m not sure how strong a consideration this was at the beginning, but boy has it saved us time and stress. Our documentation goes into four different languages, so having a system that handled Japanese out of the box has been crucial for us. Mediawiki has a robust localization framework built in, which is another part of the system we didn’t have to write.

Accessibility

I’m honestly not sure where we sit on the regulations on this one – I’m not sure if our company is required to have a 509 solution. Fortunately, I don’t have to worry about it, because it’s baked in right out of the box.

Scale

Our documentation is around 70,000 pages per language, times four languages, times two product versions. Half of the pages are duplicated because of how our scripts work, so we’re at ballpark 750,000 pages on the DocWiki system. We needed a system we knew could handle anything we threw at it, and Mediawiki’s one of the few that have been field tested to be able to stand up to just about anything. Other CMS’s may be able to handle this sort of load, but we absolutely knew Mediawiki could – we don’t have the resources to plow a few months of dev into a system and have it collapse once we put all our documentation in.

Revision Management

Built in, out of the box, including diffs and comments. We transitioned away from SVN to Mediawiki, so the revision tracking made it very easy for us to track our changes. It’s got easy-to-use diffs and an RSS feed, so we can keep tabs both on the Wiki and on the writers. It’s also got a detailed log, so we can tell who was responsible for anything that happens on the system.

Robust User Management

Including Roles. There’s some quirks here, but overall, it’s another thing we didn’t have to worry about. I’ve been able to expand on this quite a bit to allow mass user imports from our other systems, user searches, and a few other neat tricks that have made our lives easier.

API

We auto-generate a lot of our content, so we needed a clean way to edit certain pages without affecting others. Mediawiki has an API baked in, and the mwclient python scripts work wonders. Another part of the system we didn’t have to build.

Extensibility & Community

Because we’re using a packaged solution for a fairly specialized use case, extensibility was part of the spec. Mediawiki has a shockingly large number of hooks for extensions, and really allows us to do just about anything we want with the right combination of calls. It’s also got an enormous developer community, including the WikiMedia foundation, which contributes its code back to the MW community. As a bonus, you can see anything that’s in use on the WikiMedia servers, which guarantees the code has been put through its paces.

Skinability

In our case, we were able to change the look of the default Mediawiki skin enough to get a distinct look, but at the same time, it’s still clearly Mediawiki. This is a bonus for us, since it tells users what system they’re using and saves us a whole lot of user training.

LAMP & Caching

Say what you will about the LAMP stack, but we’re on an extremely restricted development budget – we needed something that worked. LAMP gets us up and running in 20 minutes on a stack that’s in use practically everywhere – there’s not a problem we’re going to hit that someone else hasn’t seen already. Mediawiki also supports APC, Squid & Memcached right out of the box – with everything set up, we’re catching almost everything somewhere in the caches.

What’s Bad?

It’s Unstructured

Mediawiki is not meant for structured content – it’s basically built for a flat hierarchy. This is a bit of a problem when you’re dealing with any serious product documentation, and was especially a problem for us, as we had highly structured content. We had to invent our way around the table of contents, the index, and the tagging we needed to make our shippable help files.

Search is a Joke

The built-in Mediawiki search is just absolutely atrocious – even Wikimedia’s using Lucene instead. If you have any reasonable expectation of users finding content on your site, you need a different solution.

Architectural Limits

Because of how Mediawiki stores inter-page links and category information, pages that are extremely link-heavy tank the wiki when you try to save them. Looks like a database lock, but I’m not totally sure. It took me a long time to track this issue down, but that’s my leading contender for the mysterious “The wiki’s dead!” bug.

Spaghetti Code

Especially in the themes. Or at least, a codebase that’s so large and daunting it might as well be spaghetti code. Either way, it really looks like code which has been developed by a large number of different people, none of whom knew each other. Which it basically is, and it’s a triumph for that, but it’s not terribly readable.

PHP

Yeah, we all knew it was coming – PHP seriously sucks as a language. It’s the most universally-deployable web dev language around, but then again, McDonalds is the most universally-deployed hamburger-ingestion venue around – doesn’t make it good.

In a future post, I’ll talk a bit more about the specific challenges we faced and how we dealt with them. I think we’ve got some pretty cool stuff going into our wiki setup, and maybe someone will even find it useful.

If you have any questions, by all means, leave them in the comments below, and I’ll address them as best I can.

Thanks!

The Hardware

Ok, I know I’m not going to be impartial here – I just wrote a post a couple days ago about how damn impressed I was with the hardware, and that was before I even saw it. Still, though, this is definitely a refined piece of hardware. It feels Machined, finished. It feels like a high-end watch – extremely tight, solid construction, great feel to the materials. This isn’t a standard phone body. This is the first phone I’ve felt that feels like a luxury device – there’s nothing cheap about it. I’m seriously impressed.

The Screen

I actually expected to be more impressed by the screen. Don’t get me wrong – it’s a Really nice screen, but it didn’t totally blow me away. I think that’s because I’m already used to the droid screen, which is already in the range of ~265 ppi, so I’m not coming from a normal iPhone. If you’re used to an iPhone, the screen is a Huge improvement, but if you’re already used to a Droid or a Nexus, I think your socks will stay securely on.

The Rest

It’s an iPhone – there’s not much else to say. I didn’t get to really take it for a spin, but it seems fairly snappy, and the multitasking menu is pretty slick. I’m pretty used to android right now, so it’s hard for me to give a good evaluation. There’s too many UX differences for me to figure the phone out well enough in the time I normally have, so I don’t think it’s fair for me to talk about the interface without being sure it’s not just my Droid-addled brain, but iOS4 didn’t strike me as anything overly different than iPhone 3.

One thing did get me though – I’ve been using Swype for a couple months on the Droid now, and I’ll never go back. It’s not on the iPhone, and unless Apple buys the company, it’s not going to be, so that’s definitely a point against the iPhone for me.

Conclusion

I’m not going to get into iPhone vs Droid, because there’s really no point – the new iPhone is still an iPhone, so whatever I’ve said before applies here.

Hardware-wise, though, this is one slick phone, and I really hope the rest of the industry is watching – that, to me, is the iPhone 4′s big contribution: It’s a grown-up phone built to the same standards we expect out of other $500 accessories. If Apple can put the era of shitty plastic phones to rest, I frankly don’t care what they do with the software.

Augmented Reality is, at its essence, just a new interface. In some cases, it’s a better interface, in some cases it’s not, but that’s basically what AR brings to the table: a new means of displaying information, albiet now in a way more integrated with the user’s physical surroundings. The promise is in that integration: visions of sci-fi heads-up displays, the sort of stuff the anime artists have been playing with for years, the ability to leverage our ridiculously well-developed online abilities in the real world.

The problem, though, is that we’ve got almost zero spare cognitive bandwidth to play with. The unfortunate fact is parsing what an alert from a mobile system is takes effort, and effort takes focus, and focus is a finite quantity limited to One: What am I focusing on Right Now? This is easily made apparent just by observing people trying to walk while using smart phones, and it’s also why the headset requirement in California is basically window-dressing: the problem isn’t where our hands are, it’s where our heads are.*

So AR poses an interesting conundrum: On the one hand, with some work on machine vision and context filters (and goggles – god knows we don’t need “smartphone elbow” to become the carpal tunnel of the 21st century), it could be a radically new and useful way to get highly readable information about the world around you. On the other hand, current systems display entirely, totally, utterly too much information, even assuming someone’s actually focused on the information being displayed. It’s rare I need to know where Every coffee shop in the city is – normally I’m just looking for the best one. A smart, useful AR system needs to be able to filter the infinite feed of information down to the absolute most useful things you could need to know right now and display only those things.

The question of usefulness of the information itself is only half the battle, though. There’s also an issue of context – What am I doing Right Now? What sort of mood am I in? Am I looking for a coffee shop to meet a friend for a chat or a coffee shop to work for the day? Did I already have lunch, or should the place have good food, too? Am I a creature of habit, or do I crave novelty? What’s the weather like? Information Utility varies by person, by day, by time, and by circumstance.

This applies to notifications, too. If I’m engaged in a (physical) conversation, I probably don’t need to get that email about a coupon for a bookstore. The email about the fire in the server room, though, might warrant an interruption. Likewise, if I’m wandering around looking for something to do, the fact that a friend of mine just checked in to the bar a block away is relevant, whereas if I’m in the office, it’s probably not. What’s even trickier is that mood plays a big role, too. Maybe I’m just not feeling like going out today, or maybe I’m on a super-productive streak, in which case anything shy of the second coming of jesus should probably wait until I run out of steam.

What this boils down to is a system that knows you, knows where you are, knows what you’re doing, and knows how to filter all of that down to just what you need. It remembers what you’ve done before, recognizes by the amount of time you’ve spent somewhere and your overall mood there what you thought of the place, can recognize by your behavior what your likely mood is, can tell by your surroundings what you’re up to, and from all that can tailor its recommendations to what’s best for you right now. Basically, it’s a personal assistant in software form – an AI.

We’ve reached a point in the evolution of computers, the internet, and mobility where we no longer have to try to find information or to connect with people. We’ve wired everyone and everything to everywhere (or at least to Google) such that it’s not a question anymore about whether the information exists, it’s whether it floats to the surface of whatever interface we’ve slapped on top of the fire hose of data aimed at our eyeballs and our brains. We don’t have an Access problem anymore, we have an Excess problem, and there’s just no way that dumb filters (or even just slightly smart filters) are going to be able to carry us forward. We need learning filters. We need systems to sit between us and the fire hose, to act as the gatekeeper to the ludicrously limited cognitive time we’ve got. We need something to take the terabytes terabytes of information we’re constantly exposed to and strip it down to the most relevant 40 bits and deliver it to us so that we Know it, we don’t just see it or read it.

I’ve become increasingly aware of the value of cognitive downtime lately. Our brains need time to parse the materials they’re exposed to, and without taking time to pull out of the feed and parse the information we’ve obtained, we lack context and the ability to assimilate the knowledge we’ve gained. Minimizing non-essential or extraneous pulls on our attention allows us to focus more fully on the world around us and even allows us to relax and reflect. With mobility as it exists today, we’re fast-tracking ourselves towards a sort of mass social ADD, and AR without context is only going to worsen the matter.

* Credit to S.Applin, M.Ito, & others working on this problem. Apologies to any other unattributed shoulders on which I’m standing.

The first problem we have with privacy is that we simply don’t have a good definition for what we want kept private. We’re not used to having to define exactly what we consider our identity, nor what we consider a breach of privacy. These are conventions that we all see differently, and we do so on an ad-hoc basis. In each interpersonal relationship, we’re defining on the fly roughly what we consider our identity and roughly what we consider private information, and these definitions are mostly relative to the current circumstances. It’s not just that we’re not defining privacy, it’s that we just don’t have a concrete definition at all.

The second problem is the definition of Identity. We present different personas to different people – this is human nature. We behave differently around our friends than our co-workers, we act differently in different groups, and typically people who don’t do this come off as abrasive. Certain parts of our personalities are relevant to certain situations, and these are typically the parts we present in different scenarios.

The third problem that arises is that frequently what gets presented as our ‘identity’ online is, to say the least, an incomplete picture. A huge, huge part of human communication is non-verbal, and this is something that’s simply lacking online. Our words taken by themselves are far more susceptible to misinterpretation than the whole of our communication, and pictures and videos do not fully fill in the blanks. The problem, then, comes because our online persona is an amalgamation of small parts of our personality, and not a true representation of the whole.*

I submit that there are three main situations in which we will feel our privacy or identity violated:

1. When the commitment level in an impersonal relationship is escalated without our consent: When a store starts addressing us by name or we become aware they’ve kept more data on us than we were aware, we feel like we’ve been stalked – and rightfully so. The nature of stalking is a non-consensual escalation of familiarity borne without trust. The behavior of businesses trying to establish “customer relationships” is extremely similar, and off-putting for the same reason.
2. When parts of our different identities become intermixed: We assume different identities in different groups largely as a means of convenience – certain information is not relevant to a relationship, nor something we want to have influence a relationship. When this information gets added (say, your coworkers find out the size of your genitals), this can be profoundly upsetting.
3. When we feel we’re being misrepresented: We cultivate our identities carefully, especially in our dealings with others, and we’ve a certain idea of what that identity is. When partial information is revealed or when we feel like we’re being unfairly or inaccurately represented, we feel a powerful need to correct this, and we get very upset. This includes attaching our name as an endorsement of a product or service – we consider this tantamount to misrepresenting us wholesale.

When we engage in a relationship (very broadly) with a person or an entity, we reveal parts of our identity to that entity. The degree to which we do so is commensurate with the trust we have in that person. Each of the three breaches above cause us to lose trust in that entity, as it’s a breach of an unspoken agreement easily as strong as whatever other agreement we’ve formed with that entity. In effect, any given transaction has two components: the transaction itself and the trust transaction.

Facebook has performed all three of these breaches, repeatedly and remorselessly. For those of us who started in college, we gave Facebook a certain part of our identity – typically one with more red cups and horticultural appreciation than what we’d present to those not privy to that persona. Facebook proceeded to open this network up to the rest of the world, instantly revealing a swath of information (and frequently, indiscretions) that we’d not have shared otherwise. Facebook has repeatedly revealed, without our consent (‘opt-out’ might as well say ‘f*ck you’), large amounts of personal information to people we haven’t decided to engage in relationships with, and revealed relationships in ways that were tantamount to slapping our endorsement – putting our identity up as collateral – on a given third party. Most recently, Facebook has, again without soliciting our consent, revealed our information by connection with our friends.

In every instance, Facebook has taken what was a trust relationship and treated it as a purely commercial transaction. We feel betrayed, because we were betrayed, even if Facebook wasn’t aware they were betraying anything.

Thanks to Sally, Doug, and the other people whose names elude me but whose ideas informed me. (Contact information withheld because my sense of irony is still intact.)

—————————

Note 1: It’s worth noting here that the ability to hide one’s true personality has helped many a wallflower build a more confident representation online. This ‘pseudonymity’ (gratz, privacycamp), therefore, is not universally negative, but it does obfuscate our true identity.

(I’m aware this is an “obvious-man” sort of post, but I think it’s interesting to consider the limits of the info-god as we rely increasingly on smartphones and ubiquitous data.)

I’ve been living in San Francisco for almost 8 months now. I’m starting to get a pretty good feel for the city, though I’ve spent most of my time on the east side. Google maps have been invaluable to me in this process, allowing me to wander without concern for getting back home, directing me to the nearest stores, in general giving me at least the base knowledge to explore the city. I can’t overstate the incredible feeling of just walking out the door in a totally foreign city with no real concern for when or how you’ll get back home.

Bobbi, the woman from whom I rent a room, has lived in the city for the better part of a couple decades now, and I’m beginning to suspect I should be asking her a lot more than I’m asking Google.

What drove this home most recently was a trip over to the Fillmore area. I was meeting a friend of mine in a coffee shop at Fillmore and Sacramento. Google recommended the 10 bus, but I missed that, so the next option was the 45, which stops at Union and Fillmore. Google suggested I walk from Union to Sacramento on Fillmore.

For those of you who don’t live in the city, this is only about a half-mile walk along Fillmore. For those of you who do live in the city, you might know why these are terrible, terrible, terrible directions.

See, Google Maps doesn’t take terrain into account with its walking directions. And San Francisco is a city for which Terrain is quite an important factor. Between Union and Broadway, a scant 3 blocks along Fillmore, there’s about a 100ft change in elevation. To put that in perspective – in the space of three blocks, you climb the equivalent of 10 stories. There are STAIRS CUT INTO THE HILL. Don’t get me wrong, there’s a beautiful view from the top – or so I hear. I was hallucinating by then. I mentioned this to Bobbi later and she just laughed, because this is just a blindly obviously a bad idea to anyone who’s lived in the area – You take the 10 or the 22. This is how you get to Fillmore, Period, because otherwise you have to hire a Sherpa or a cab.

To give a couple more examples:

Google’s sent me past Taylor and Ellis and sent me up 6th st., both at night. For non-SFers, this is the Tenderloin, also known as “Man, I am gonna get Stabbed if I don’t get out of here.” It’s told me to drive along the Embarcadero during the weekend (it’s quite insistent on this route. I’m beginning to suspect Google of having a stake in the Farmer’s market). It might as well tell me to drive into a parking lot. It’s recommended stores that have been closed so long there’s no sign there was ever anything other than a vacant building there. In general, it’s given me generally accurate, utterly context-free information.

Google’s been a great reference and safety net as I learn the city, but it’s a pale comparison for acquired knowledge, and incidents like this have made me increasingly cautious of my over-reliance on third-party or aggregated knowledge in lieu of personal experience.

The incident started with a massive attack against 26 different American companies which Google claims it traced back to the Chinese government. However, as Foreign Policy recently highlighted, China’s hackers are neither a monolithic group nor strictly under the control of the Government. I’ve no doubt the Chinese government can influence the group, and they can exert their will against certain hackers or certain groups, but I’d question their ability to really reign in the hacker army, and I suspect the Chinese government’s got their own reservation on that count. At the least, this would be a challenging task that would almost certainly require draconian degrees of control over China’s networks with enormous collateral damage to legitimate companies in China. This puts the Chinese government in an interesting position. They’re viewed as holding near supreme sway over their country, and that image has served them extremely well, but this may be the one nut they can’t crack. If they promise to stop the attacks, they run the risk of not being able to deliver.

Google’s complaint involved Chinese hackers, with the approval of the Chinese Government, illegally infiltrating several American corporations to steal private data. It’s not quite Mossad in Dubai bad, but it’s bad. This hardly seems the sort of thing a government’s going to lose face for  - unless the alternative is even worse, like, say, showing they don’t really have the level of control everyone assumes they do.

I am not an expert on China, and there’s certainly a whole lot of other plausible explanations for China’s actions, but given the size and skill of the hacker army in China, I don’t see “stopping the attacks” as any kind of an option. It really doesn’t matter what other motives they may have beyond that – they Can Not make that promise, whatever the consequences of not doing so may be, and that’s an awkward position for a party that thrives on visible shows of influence.

Note: This theory was exhaustively researched over a couple beers and is put out as a thought experiment only.

What’s Good:

1. Google Voice – I had to go back and edit this article because I almost forgot about this one – that’s how well it’s integrated into the system. My GV number is effectively my Only number right now. I’m saving $20/mo because I don’t need text messaging from VZW anymore. Like everything else, it occasionally glitches, but otherwise, it’s integrated almost flawlessly into the system. I am seriously impressed by this.
2. The Keyboard – thank god for the keyboard. I’m still not comfortable with the on-screen keyboard, though that’s primarily because no matter how good the on-screen is, the physical is still better. It’s not a great keyboard, but it’s a keyboard.
3. Multitasking – The #1 reason I went with the Droid over the iPhone, and one month on, I’m convinced I made the right choice. I listen to Pandora Constantly, and I can do anything else I want while doing so. Eat it, iPhone.
4. Widgets – I wouldn’t have thought so, but the widgets are really nice. I’ve got twitter, weather, mail, to-do’s, and my calendar all visible on my home screen at a glance, and I can toggle Wi-Fi, GPS, screen brightness, and airplane mode all from one of my home screens.
5. Customizability – Speaking of home screens, I swapped out the default Home app for Home++, which does just a bit more than Home. I also removed the standard camera noise, so now it doesn’t sound like I’m shooting someone when I take a picture
6. Easy Root – I rooted my phone in 5 minutes, and 4 of those were spent downloading the patch.

What’s Bad:

1. The Camera – like, biblically bad. I didn’t expect much, but unless you’re in broad daylight, don’t expect to take a picture. I’ve yet to figure out why this thing insists on closing the iris when the frame’s already black. It’s awful.
2. App Selection – Don’t let anyone tell you different. It’s not an iPhone, so it’s not what Every App You’ll Ever Want is developed for (There’s a few reasons to expect that not to change anytime soon either). There’s a lot of good apps – Pandora, Yelp, Facebook, Twitter clients, all the critical stuff – and there’s some really cool Droid Only stuff – Google Goggles is awesome – but it’s Not an iPhone, and that’s annoyed me more than once.
3. Touch Screen – The screen is gorgeous, but I’d back up what that test showed – the Droid’s screen has some serious precision problems. This is part of the reason why the On-Screen keyboard is so bad.
4. It’s Buggy – I knew this going in, but it’s not a totally polished system, and it shows. I’ve also gotta believe the iPhone apps crash a bit less than the Droid variants, if for no other reason than that they’ve sold as many as they have. I’m pretty accustomed to beta software, but somehow I get the feeling I wouldn’t have a Droid if the iPhone was as buggy – the market wouldn’t have taken off.
5. Apps can only be stored in internal storage – I’ve got a 16gb sd card, but all my apps have to be crammed into the internal memory. Not a huge problem so far, but apparently it’s holding back a few big name developers.

Overall:

Would I buy it again? Yeah, definitely. I’ve got my nags with it, but overall it’s a really impressive piece of hardware (and accompanying software). It’s instantly become an extension of my daily life and it hasn’t really pissed me off, and that’s saying a lot – I’m not normally charitable towards gadgets.

Do I regret not getting an iPhone? Sometimes. The app problem can’t be overstated – it’s the number one reason I wish this phone had a piece of fruit on the back. Until the multitasking issue gets fixed, though, there’s absolutely no way I would switch, especially now that I’ve used a phone that has it.

Final Thoughts:

Ultimately, while I’m a big fan of my Droid, if the iPhone gets multitasking, I’m going to have a hard time not switching. The arguments about open development aren’t enticing to me – the apps I’m missing on the Droid aren’t coming out of big shops, they’re mostly made by startups and small firms, so whatever you want to say about ‘iron fists’ and ‘walled gardens’, I’ll tell ya – from outside the garden, it looks pretty welcoming in there.

Just let me run two apps at a time, dammit.

Turns out, there’s a nice, easy way to get a solid color background of your choice that doesn’t involve making a new image for each color you want. OS X supports transparency in PNGs used as wallpaper, showing the desktop color through the transparent parts. If you use a small transparent PNG and set it to “Center”, you’ll get a solid color desktop, and you can change the color using the color picker next to the “Center” pull-down.

I’ve conveniently attached a 128×128 totally transparent png file below:

Right-click above me!

Save this file to your “Pictures” folder, open up System Preferences, pick Desktop & Screensaver, select the blank picture, and choose “Center” from the orientation pulldown menu. A color selection will appear to the left – click it, and select the color you want your desktop to be.

Simple, but this has been periodically bugging the hell out of me for about a decade now.

Note: This is based on a tip on MacOSXHints, found here:
http://www.macosxhints.com/article.php?story=20021002055217828

Why Digest?

Standard HTTP auth sends the password in plaintext, which is generally bad. On sites with an SSL cert, this is less of a problem, since the traffic is encrypted to begin with, but on smaller sites, it’s a lot of overhead to set up SSL.
Digest authentication hashes the password before sending it – it’s an MD5, which isn’t great, but it’s also not your password flapping in the breeze, so to speak. It’s a good intermediate step to make sure you’re not transmitting plaintext passwords anywhere.

What’s the drawback?

There’s a very small performance hit, and it’s not as easy to set up, but the biggest drawback is that you have to rebuild your apache users file.

So how do I do it?

Digest is very similar to standard Apache access configuration, with just a couple changes.

1. Make sure you have digest enabled – if you have shell access, type:
   a2enmod auth_digest
   otherwise, in your httpd.conf or apache2.conf file, include the line:
   LoadModule auth_digest_module modules/mod_auth_digest.so
2. Create your new Digest authentication file. At the shell, type:
   
cd /var/www/
htdigest -c .digest Internal Admin

   Note: This code creates a user named Admin in the realm “Internal” – we’ll get to realms later.
   You’ll be asked for a password, and then asked to confirm the password.
3. Create your .htaccess file in the directory you want to protect – in this case, we’ll assume it’s http://(yourdomain)/Private:
   
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
AuthType Digest
AuthName "Internal"
AuthDigestDomain /Private
AuthUserFile /var/www/.digest
Require user valid-user

   The first line is necessary to make Digest work for IE6. IE7 seems fine.
   AuthName is the realm you chose earlier – Digest allows you to make multiple “realms” to protect different directories.
   Also, note the AuthUserFile line – Apache docs swear that line should read AuthDigestFile. It shouldn’t.

That’s it – you’re using Digest!
The code is interchangeable anywhere you’d normally use standard Apache password auth, and you can use all the other normal .htaccess commands as well. It’s just a mildly more secure, and horrendously documented, alternative to standard HTTP authentication.

Apache.org: Authentication, Authorization and Access Control
Apache.org: Apache Module mod_auth_digest