For those of you who are not familiar with Mozilla Prism, it's a tool that allows you to sandbox web applications away from the rest of your day-to-day browsing. For security freaks (which we should all be to at least some degree), this is an excellent tool, as it prevents data from being shared or potentially stolen between web pages. It also allows you to clear away the browser navigational elements, making the page more like a real application and giving you more screen real estate to work with.
The big problem with Prism right now is that it's in beta and isn't technically Firefox (even though it's the same exact browser engine). That means software that sniffs the user agent string specifically for certain browsers has no clue what Prism is, and therefore might not let you do everything you could were you in Firefox itself. Most people come across this issue with YAHOO Mail. YAHOO's newest mail client is super-sexy, but in order for it to do all the fancy interactivity that it does, it relies on having a very modern, snappy javascript implementation in the browser. To make sure the user's experience is top notch, it therefore only lets browsers it knows are good enough into the new client, and forces older or unidentifiable browsers into the old, flat client. Unfortunatley, it does not yet recognize Prism, and therefore your nice YAHOO Mail sandboxes in Prism won't have access to the newer mail client.
In theory, there's a plugin/template linked to at mozilla's prism wiki that is supposed to fix this problem, but it doesn't seem to work as of Prism 1.0 beta 1. A user named rotassator on the Mozilla Lab's forums outlined an excellent alternative solution that I'd like to repeat here for searchers' sake. Here's how to do it:
I hope this helps someone!
If anyone hasn't heard, there's a bit of a kerfuffle brewing about Microsoft's decision to continue to use Word as the default editor and html renderer for Outlook 2010. Web developers reading this will probably cringe, as Outlook is the primary thorn in any email designer's side. A case in point: I was hired not too long ago to assemble a tightly-designed email for a small publisher. The design was clean, simple, and attractive. I generated a clean, standards-compliant version fairly quickly, but when I moved to adding compatibility for Outlook, my time and their costs literally tripled.
This sounds all too much like the arguments made against changing standards support in IE6. The IE6 argument started when a Microsoft product was found to handle things in a nonstandard manner that the larger community of developers found troublesome. That argument resulted in the ascension of Firefox and Safari, as well as Microsoft's decision to support better standards in IE7 and 8 later one.
We're now on the second phase of deja vu now, where the Microsoft holds that their method and strategy is fine and proper, even if it breaks their fundamental compatibility with the rest of the community. Now we'll move on to the last phase, where enough of an outcry is generated that a secondary application like Thunderbird or GMail begins to get better PR and market share. Well after this happens, Microsoft will begin to implement better compatibility in order to appease the community and retain their user base.
It's sad that this has to play out again so soon after the IE6 debacle. One would hope that losing 20% of a monopolistic market would be enough of a jolt to change the corporate culture at Microsoft to recognize the importance of standards on the internet, but their recent declarations indicate otherwise.
Outlook is a digital communications tool, and digital communications rely on standards to operate properly. Despite Microsoft's claim to the contrary, there is a standard for email rendering: HTML 4 and CSS 2. YAHOO, GMail, OSX Mail, Thunderbird, and Hotmail all render consistently using this standard, leaving Outlook as the IE6-like outlier. If they wish to use Word to make the editing portion of their user experience better, that's fantastic, and I encourage them to do so. Simply make the results obey standard HTML/CSS rules, and use a real HTML/CSS renderer to display emails from others.
Step 1: Sign into your gandi.net account
Step 2: Select your domain (click on the Manage tab if you don't see a similar screen after logging in)
Step 3: At the bottom of the screen (under Technical Settings), click "Manage DNS zone file"
Step 4:

Remove the unneeded entries as indicated in the screenshot (i.e. everything except the "A" record and the www CNAME)
Step 5: Edit the A record and change the value to 65.39.205.54
Step 6: Edit the CNAME record and change the value to yourdomainname.com. i.e. domain dot top-level domain dot; the last dot is important!
Step 7: Click "Submit changes". Note that it may take some time (up to a day) for this change to take effect.
Step 8: Log into your squarespace.com account.
Step 9: Visit your Website Management console
Step 10: Click "Custom Domain"
Step 11:

Enter your domain name without a www (and without a trailing dot). It will ask if you also want to create the www - say yes.
That's it! If you don't see any results right away, wait a few hours. DNS changes have to get copied all around the internet once they're made, and can take up to a day to do so.
There are a bunch of code/syntax highlighter plugin options for MediaWiki. After playing around with the few I just linked to, I'd like to recommend the basic GeSHi highlighter...it's by far the simplest to install, and works well with both highlighting and spacing.
To steal the commands from the wiki, here's what you do:
1) Browse to your mediawiki extensions folder:
cd /var/www/%mysite%/wiki/extensions
2) Check out the extension with SVN (you do have SVN installed, right?)
svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi
3) Add a single line to LocalSettings.php in your mediawiki directory root:
require_once("extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php");
That's it! It's great if you do your documentation in MediaWiki...tags will only get you so far.