結局、MSゴシック＋9ポイントを使い続けるハメになるのです。MSゴシックが、スラッシュドゼロとか、lとIと1の見分け付けたりしてくれればそれで万事解決なのですがね。

メイリオ-等幅、なんて公式で出ないかなあ。

OOPに対する拒絶反応

これまで、Web上でいろいろなOOPに関する書き物を目にしました。そして、その書き物に対する、様々な意見にも、極力目を通すよう心がけてきました。
その中によくある「OOPって難しい」「必要性が分からない」といったような、OOPに対する拒絶反応を見てきて、少々残念に思うことがあります。

「難しく考えさせすぎ」

OOPを勉強しようと思い立った時、Webにせよ専門書にせよ、OOPについて書かれたものを開くことになるでしょう。しかし、それらを開いてぱっと目につくのは「多態性が云々」「カプセル化が云々」と、「OOPを実現するための要件」ばかりに思えます。

－そりゃあ無理ですよ。いきなりわかりもしない言葉を並び立てて、難しく考えさせすぎというものです。

私がOOPに至るまで

私自身は幸いにして、高専という恵まれた環境下で、授業やその他様々なシーンにおいて、プログラミング（や、その周辺知識）を勉強してきました。
その中で、自分なりにどういう風にプログラミングすれば「デバッグしやすく」「人にも読みやすく」「次回の授業につなげられる」プログラムが書けるのか、という工夫をしてきました。

紆余曲折はあったものの結果として、当時の私はC言語しか使えなかったものの、「なんとなくオブジェクト指向的」なプログラムを無意識に書いていた覚えがあります。
そういう背景や基盤があったからこそ、先に挙げた様な書き物を読んで、荒唐無稽なオブジェクト指向の方法論を突きつけられても、ある程度の苦労はあっても理解できた、と思います。

OOPの現状と未来

今改めて、世にある「OOP入門」といえるものを読み返してみると、理解したつもりになっていても難しく感じます。これでは尚のこと、「オブジェクト指向なんてどうでもいいや」と思っていたり、あるいは「知りたいけど何もわからない」と思っていたりする人たちにとっては、それこそ苦痛以外の何ものでもない代物となってしまっても不思議はありません。「分かっている奴だけ使えばいいじゃない」となっても仕方のないことだと思います。
理解して推してくる人間－こと、信者と言えるような熱心な人たち－が疎ましく思えてしまうのも無理はありません。

私はこの状況が好ましいものだとは思えません。なぜならば、OOPは何ら難しいものでも、不愉快なものでもなく、ずっと素直で簡潔なものだと考えているからです。
そして、それはもっと多くの人に理解され、そして肯定も（拒絶ではなく）否定も含めた議論がもっと成されるべきだと考えているのです。

この記事の動機

そのためには、もう少し「なぜ、OOPなのか」あるいは「OOPが目標とするところは何なのか」を、抽象的に論じた話が、さわりとしてあった方がいいように思います。「OOP概論」のような。

OOPってなんぞや

OOPって何ですか、って話は、某高専の情報系学科、入学直後の「情報工学概論」という授業で最初に教授が切り出した話題に答えがあるように思います。

「“情報”とはなんですか」

曰く、「情報＝データ＋意味」なんだそうです。
これは決してその教授が考えた、という話ではなく、工学的に見た「情報」とはなんぞや、という一般論です。当時は、こいつは一体何を言い出すのだ、と思っていましたが（ごめんなさい、S先生）、今思えば確かになあ、と納得できる話です。
あくまでも工学的な理屈の上での、「情報とは」なんですけれど。

情報とオブジェクト

情報とは、データ＋意味である。
では、データとは何か。
究極的にいえば（コンピュータ上では）0と1のあつまりだ。
では、意味とは何か。
それが「画像」であるのか、「文章」であるのか、「音声」であるのか・・・つまるところ、「データをどう処理するか」というデータに対するメタだ。

では、情報とはどうあるべきか。
データ＋意味であるべきだ。

データが意味を喪失したとき、それは情報ではない。単なる値の集合体だ。
そして悲しき哉、データそのものに何ら「意味」はない。

逆に、「意味」だけがあってもしかたない。
意味があっても、データが無ければ、情報の体は成さず、データが間違っていれば、情報自体が誤りとなり、これもまた「意味」がない。

データと意味・・・つまり、そのデータをどう「処理するか」ということは、常にセットであってほしいものなのです。

プログラミングと「情報」

さて。
プログラミングとは、「情報処理」の塊です。
実際に処理をするのは、コンピュータ側ですが、それを命じるのは人間です。情報処理を命じるのは一般的にはプログラミングのソースコードです。そしてそのソースコード上にもまた、数多くの情報があふれています。これを人間が読み解くとき、「データ」と「意味（処理）」が離れていては、それを情報としてみなすことが難しくなってしまいます。

可能な限り、データと意味、両者は近くにあってほしいのです。ならばどうするか。

・・・

抽象的な話

「データ」と紐づく｢意味（処理）」は、共通の箱にしまいましょう。
そして、必ず箱単位で扱うようにしましょう。
めったなことで、外から箱の中身をのぞいてはいけません。ましてや、中のデータを勝手に書き換えたりしてしまっては、箱の「意味」はなくなってしまいます。

箱の種類が増えてきて、またいくつかの箱で「意味」が形成されたなら、その箱たちをより大きな箱にしまいましょう。やっぱりその箱も、外から覗いたり、データだけ書き換えたりしてはいけません。中身の箱だけ勝手に入れ替えるのもいけません。「意味」を成さなくなってしまいます。

・・・

OOPとそのメリット

ソースコード上といえども、情報はあくまで一つの「情報」として扱い、どこからどこまでが「一つの情報」なのかを明確にするべきです。
そうすることで、人がソースコードを見た時に、「ここでこういうデータにこういう処理をしている、はたしてそれは情報として正しいか？」ということを判断するだけで済むようになります。
そして、「情報」という単位が明確に定められていれば、その情報に対して人間が行う作業も、明確な範囲をもって行うことが可能になるでしょう。
たとえばそこに新しい意味（価値）を付加することも、あるいは後から「意味」を変えることも、対象となる「情報」の枠の外にでることなく実行することが可能です。

おわりに

これまでぐだぐだと書いてきましたが、これらはあくまで理想論の上でのOOPについて論じたものです。実際には、開発する言語や環境、要件や既存資源などによって数多くの制約を受けることになります。
結果として、中途半端なOOPは皆の頭を悩ませる代物を生み出すおそれもあります。

それでも、一人でも多くの人がOOPを深く理解し、結果、世に溢れた中途半端なOOPが少しでも完成度の高いものに近づけるなら、と思い、この様な記事を書いた次第です。
この記事を読んで、そうか、OOPも意外とシンプルな話なのかもしれんと、おもってくれる一人でもいたなら、それはとてもうれしいことです。

・twitterにあるものは、如何なる場合も究極的に140文字の文字列である。
　⇒あくまでもシリアル化されたデータの中に、さまざまな構造を持つ。
・構造は時とともに変貌し、そしてそれをサポートすることは一定のニーズを見込む。

・言語構造とは・・・？

・構造が持つ機能と、その構造のシリアル化された姿の対応
　⇒まさしくクラス。以下構造をクラスと呼ぶ。

・シリアル化されたデータに対して、各クラスが出来ることは、
　「クラス自身にとって関心のある部分と、そうでない部分（文字列）との分割」

・ならばTweet全体は常に、単なる文字列と各種クラスがシリアルに並ぶ構造＝クラスである。

・構造の例
　以下で大文字はクラスの識別子、小文字は変数的なもの。
　「******」で記述される部分は、クラスが関心を持たない部分。
　「～～～」で記述される部分は、クラスが関心を持つ部分。

・・前置（例: ReTweet）
　　******@RT～～～～～～

・・後置（例: RESponce）
　　～～～～～～@id******

・・包括（現状存在しないので、飽くまで例: PaンチのあるTsuぶやき。PunchTweet）
　　******@PT{～～～@PT}******
　　（もう一例: URLリンクTweet。Uniqlo T-shirts）
　　******@UT{～～～ | http://？？？@UT}******

各クラス内部についてはシリアル化の限りではなく、包括関係や上下関係を伴う可能性もある。

　　******@RT～～～@PT{？？？@PT}～～～
　構造例：（ただし、以下の例においてSTRとは単なる文字列を示すための便宜上の識別子である）
　　******　＝　～～～　＝　？？？　＝　～～～

　⇒ROOT {{
　　　STR {{ ****** }}
　　　RT {{
　　　　STR {{ ～～～ }}
　　　　PT　{{ ？？？ }}
　　　　STR {{ ～～～ }}
　　　}}
　　}}

・単一のクラスが、単一の構造を持つとは限らない。
　例：
　　@PT～～～～～～、または～～～～～～@PTとした場合、
　　Tweet全体がPunchなのだ。

・PT、RTその他は拡張により、その定義を外部から与えることができる　⇒参照: MEF

・構造化する構文は、複雑すぎれば意図的な使用者に混乱を招く。
　単純すぎれば意図しない使用による混乱を招く。

・クラスのインターフェース (仮り名: [TW]

　・readonly char 識別子;　 #「P」⇒「@PT」みたいな。どんと来い混乱。
　・TW[] 解析( 文字列 );　　# 上位のクラスから呼ばれる。

・ルートクラス

　・プラグインの読み込み、
　・文字列を各プラグインに噛ませて読ませる。

Internet Explorerで、シングルラインテキストボックス（input type=”text”）にmaxlengthを設定しない場合、
入力文字数が4,000を超えた時点で挙動が不正な状態になります。

再現手順

• <input type=”text”>のように、最大長(maxlength)を指定しないシングルラインテキストボックスを作成する
• ascii文字またはそれ以外の文字で、4,000文字入力する。ただし、両者を混成しない。
  　（あああああ、のように日本語文字で入力するなら、「a」などのアスキー文字を途中にまぜない。
  　　逆に、aaaaa、のようにascii文字で入力するなら、「あ」などのその他のの文字を途中にまぜない。）

現象

4,000文字を超えた時点で、入力された文字の表示がおかしくなります。
入力できることはできますが、入力直後は表示されず（空白が入力されているように見える）、選択などによってあらためて再表示をかけると、その時点で表示される、という挙動をとります。
実際にこの状態で送信した場合、どのような挙動になるかは未確認です。

環境

現象は、IE8、IE8互換表示モードで確認されています。その他のIEについては未検証です。

対策

maxlengthをかならず4,000文字以下で設定します。4,000文字以上の入力が必要となるケースは、textboxやファイルのアップロードで対応します。

まず重い。低スペックパソコンでは、ストレスない開発など不可能。
Celeron 2.0GHz + 1.97GB RAM、グラボなし環境下では、XAMLデザイナがちょくちょくフリーズする。あるいは画面が乱れて、現状が見えなくなる。
Core i7 + 6.0GB RAM、Radeon環境下でも、時々表示が狂う。バグか？

Intellisenseに至っては、エディタのリアルタイム描画を邪魔する始末。
記述中にIntelilsenseが開いていると、記述中の文字列が見えない。

.NET Framework 4.0 / C#

なんでPathってクラスを増やした・・・！
なんだかんだファイルシステムを扱う機会は多いので、そのたびにSystem.IO.PathとSystem.Windows.Shapes.Path が衝突を起こして、System.IO.Pathと書く必要が生じる。

名づけ参照（だっけ？　「using IOPath = System.IO.Path」みたいな）をすればいいんでしょうけど、そんな馬鹿なことって。
System.IO.Path自体は、Path.Combine(params string[] ～なんてのが増えてたりして、ありがたい。
というか、全体的にLinq重視のメソッド増強・メンバ増強が成されてて嬉しいところが多い。String.Joinなんかも、
String.Join メソッド (String, IEnumerable(String)) (System) – MSDN ライブラリ
こんな風に増強されてて、今までIEnumerable<T>.Cast()だのIEnumerable<T>.ToArray()だのを頻発していた部分が、よりスマートに書けるようになっている。
String.IsNullOrWhiteSpace() など、基本的なクラスにさりげない増強が施されているので、調査続行の予定。

進化した結果、使い勝手は落ちている部分がいくらかある。
いつだって進化に犠牲はつきもの・・・が、System.IO.Path <-> System.Windows.Shapes.Path だけはどうにかならなかったものか。

その他の新機能覚書

• .NET Framework 4 の新機能
• StringBuilder.Clear メソッド
• Stopwatch.Restart メソッド
• Enum.TryParse メソッド
• Environment.SpecialFolder 列挙体
• Path.Combine メソッド
• SortedSet<T> クラス
• String.IsNullOrWhiteSpace メソッド
• String.Concat メソッド

「効率」

効率はいつだって（結論に差はあれ）考えなくてはならないことで、それを無視してコーディングするようでは、どんなに便利な道具でも時に凶器と化すように、Linq もまた単なる「お荷物」になりかねません。せっかくの便利な道具を、お荷物にしてしまわないためには、その内部をある程度知っておく必要があるでしょう。逆に、Linqを便利で、かつ効率の良いツールとして活用するためにも、それは必須のことと思います。

かといって、私はLinqの中身をILで・・・とか、そんなことは考えるのも億劫なので、「実際に動かして結果を見てみればいいじゃない！」という手抜き工程を踏みます。ゆえに、「一歩」の踏み込みには及ばずながらも、「半歩」程度は踏み込めてるかなあ、と。

さて、サンプルコードです。

using System;
using System.Collections.Generic;
using System.Linq;

namespace Kyoh.Tips.LinqExtensions
{
	static class Program
	{
		static void Main(string[] args)
		{
			var enum1 = enumTest("enum1", 1, 5);
			var enum2 = enumTest("enum2", 3, 7);
			var enum3 = enumTest("enum3", 2, 3);

			Console.WriteLine("Aggregate:");
			enum1.Aggregate((x, y) => x);
			Console.WriteLine();

			Console.WriteLine("All:");
			enum1.All(x => x != 3);
			Console.WriteLine();

			Console.WriteLine("Any:");
			enum1.Any(x => x == 3);
			Console.WriteLine();

			Console.WriteLine("AsEnumerable.run:");
			enum1.AsEnumerable().Run();
			Console.WriteLine();

			Console.WriteLine("AsQueryable.run:");
			enum1.AsQueryable().Run();
			Console.WriteLine();

			Console.WriteLine("Average:");
			enum1.Average();
			Console.WriteLine();

			Console.WriteLine("Concat.run:");
			enum1.Concat(enum2).Run();
			Console.WriteLine();

			Console.WriteLine("Contains(3):");
			enum1.Contains(3);
			Console.WriteLine();

			Console.WriteLine("Count:");
			enum1.Count();
			Console.WriteLine();

			Console.WriteLine("Distinct.run:");
			enum1.Distinct().Run();
			Console.WriteLine();

			Console.WriteLine("ElementAt(3):");
			enum1.ElementAt(3);
			Console.WriteLine();

			Console.WriteLine("ElementAtOrDefault(-1):");
			enum1.ElementAtOrDefault(-1);
			Console.WriteLine();

			Console.WriteLine("Except.run:");
			enum1.Except(enum3).Run();
			Console.WriteLine();

			Console.WriteLine("First:");
			enum1.First(i => i == 3);
			Console.WriteLine();

			Console.WriteLine("Intersect.run:");
			enum1.Intersect(enum2).Run();
			Console.WriteLine();

			Console.WriteLine("Last:");
			enum1.Last(i => i == 3);
			Console.WriteLine();

			Console.WriteLine("LastOrDefault:");
			enum1.LastOrDefault(i => i == 3);
			Console.WriteLine();

			Console.WriteLine("Max:");
			enum1.Max();
			Console.WriteLine();

			Console.WriteLine("OrderBy:");
			enum1.OrderBy(i => i);
			Console.WriteLine();

			Console.WriteLine("Reverse.run:");
			enum1.Reverse().Run();
			Console.WriteLine();

			Console.WriteLine("SequenceEqual:");
			enum1.SequenceEqual(enum3);
			Console.WriteLine();

			Console.WriteLine("Single:");
			enum1.Single(i => i == 3);
			Console.WriteLine();

			Console.WriteLine("SingleOrDefault:");
			enum1.SingleOrDefault(i => i == 3);
			Console.WriteLine();

			Console.WriteLine("Skip(3).run:");
			enum1.Skip(3).Run();
			Console.WriteLine();

			Console.WriteLine("Sum:");
			enum1.Sum();
			Console.WriteLine();

			Console.WriteLine("Take(3).run:");
			enum1.Take(3).Run();
			Console.WriteLine();

			Console.WriteLine("ToArray:");
			enum1.ToArray();
			Console.WriteLine();

			Console.WriteLine("ToDictionary:");
			enum1.ToDictionary(i => i);
			Console.WriteLine();

			Console.WriteLine("ToList:");
			enum1.ToList();
			Console.WriteLine();

			Console.WriteLine("ToLookup:");
			enum1.ToLookup(i => i % 2);
			Console.WriteLine();

			Console.WriteLine("Union.run:");
			enum1.Union(enum2).Run();
			Console.WriteLine();

			Console.WriteLine("Where.run:");
			enum1.Where(i => i != 3).Run();
		}

		public static void Run<T>(this IEnumerable<T> enumerable)
		{
			foreach (var item in enumerable)
				Console.WriteLine("      (running)");
		}
		static void empty() { }

		static IEnumerable<int> enumTest(string key, int min, int max)
		{
			try
			{
				Console.WriteLine("  start(" + key + ")");
				for (int i = min; i <= max; i++)
				{
					Console.WriteLine("    " + i.ToString());
					yield return i;
				}
			}
			finally { Console.WriteLine("  final(" + key + ")"); }
		}
	}
}

結論はここには書きませんが、実際にこれを動かしてみると、「思っていたのと違う！」というのもあるのではないでしょうか。
今後Linqを使う場合に、これがひとつ「効率」の問題に何か投じることができれば、それはとても嬉しいことです。

どうでもいいっちゃいいんですが、MSDN はもっとPerm linkについて真剣に考えるべき。
最近大幅な改修があったみたいで、どこのサイトもリンクが切れてて非常に不愉快。

NetUseSetup_x86
NetUseSetup_x64

二重起動を禁止する、っていうエントリーは、いろんなところで見かけるんだけど、
二重起動を禁止して、尚かつ既に起動しているプロセスに対して何かする、っていうエントリーは、いまいち回答が見つかりにくい。
ならいっそ、共通処理化出来たら意外とニーズはあるんじゃないのか？という企み。

キーワードは、「Ipc」である。ここに書いてあることで理解できないことや、もっと発展的にやってみたい、という方は、「Ipc C#（またはVB）」で検索すれば、結構それなりに引っかかる。

まあ、ともあれ、まずはクラスのソースコードから。
まず肝となる「ExtendetMutex」クラスから。本来の「Mutex」が意味するところとは若干違う役割を持っているけど、適切なクラス名が思いつかなかったので、最初につけた名前でずるずるときてしまっている。ご容赦。

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Ipc;
using System.Runtime.Serialization.Formatters;
using System.Threading;

namespace ExMutex
{
	using BinaryClient = BinaryClientFormatterSinkProvider;
	using BinaryServer = BinaryServerFormatterSinkProvider;

	/// <summary>同プロセスが呼び出されたことを通知するデリゲート</summary>
	/// <typeparam name="TMessage">通知するメッセージの型</typeparam>
	/// <param name="holder">通知するメッセージ</param>
	public delegate void CadetStartedHandler<TMessage>(IMessageHolder<TMessage> holder);

	/// <summary>プロセス間通信により、起動オプションなどのメッセージのやりとりをサポートするMutex</summary>
	/// <typeparam name="TMessage">プロセス間でやりとりするメッセージの型</typeparam>
	public sealed class ExtendedMutex<TMessage> : IMessageHolder<TMessage>, IDisposable
	{
		/// <summary>IPCで利用する共通メッセージクラス</summary>
		private sealed class MutexMessage : MarshalByRefObject, IMessageHolder<TMessage>
		{
			#region ISyncHolder<T> メンバ

			private bool mIsCadet = false;

			public bool IsCadet
			{
				get
				{
					try { return mIsCadet; }
					finally { mIsCadet = true; }
				}
			}

			public TMessage Message { get; set; }

			public event CadetStartedHandler<TMessage> CadetStarted;

			#endregion

			public void RaiseCadetStarted(TMessage e)
			{
				Message = e;
				if (CadetStarted != null)
					CadetStarted(this);
			}
		}

		private IChannel mChannel;
		private MutexMessage mMessage;
		private ExtendedMutex(IChannel channel, MutexMessage message)
		{
			this.mChannel = channel;
			this.mMessage = message;
			this.IsCadet = message.IsCadet;
		}

		#region ISyncHolder<T> メンバ

		/// <summary>起動したプロセスが、すでに他に存在するかどうかを取得します。</summary>
		public bool IsCadet { get; private set; }

		/// <summary>プロセス間通信オブジェクト。</summary>
		public TMessage Message { get { return mMessage.Message; } }

		/// <summary>他のプロセスが後から起動した場合に発生するイベント。</summary>
		public event CadetStartedHandler<TMessage> CadetStarted
		{
			add
			{
				if (mMessage != null)
					mMessage.CadetStarted += value;
			}
			remove
			{
				if (mMessage != null)
					mMessage.CadetStarted -= value;
			}
		}

		#endregion

		/// <summary>プロセス開始通知</summary>
		/// <param name="name">開始プロセスのユニークな名称文字列</param>
		/// <param name="eventArg">先に開始していた同名のプロセスがあった場合、当該プロセスに送信するメッセージ</param>
		public static ExtendedMutex<TMessage> Start(string name, TMessage eventArg)
		{
			// 開始プロセス自体をMutexでプロセス間同期
			using (var mutex = new Mutex(true, typeof(MutexMessage).FullName + "[" + name + "]"))
			{
				bool isServer = false;
				mutex.WaitOne();
				try
				{
					#region サーバ

					// IPCチャネルの作成と登録
					var channel = new IpcServerChannel(name, "remote", new BinaryServer() { TypeFilterLevel = TypeFilterLevel.Full, });
					ChannelServices.RegisterChannel(channel, true);

					// サーバとして起動できる
					isServer = true;

					RemotingConfiguration.RegisterWellKnownServiceType(typeof(MutexMessage), name, WellKnownObjectMode.Singleton);

					// メッセージキャプチャを開始
					var message = new MutexMessage() { Message = eventArg, };
					RemotingServices.Marshal(message, name, typeof(MutexMessage));
					return new ExtendedMutex<TMessage>(channel, message);

					#endregion
				}
				catch (RemotingException)
				{
					// サーバの起動に失敗
					if (isServer)
						throw;

					#region クライアント

					var channel = new IpcClientChannel(name, new BinaryClient());
					ChannelServices.RegisterChannel(channel, true);

					RemotingConfiguration.RegisterActivatedClientType(typeof(MutexMessage), "ipc://remote/" + name);

					// メッセージを発行する
					MutexMessage message = (MutexMessage)Activator.GetObject(typeof(MutexMessage), "ipc://remote/" + name);
					message.RaiseCadetStarted(eventArg);
					return new ExtendedMutex<TMessage>(channel, message);

					#endregion
				}
			}
		}

		#region IDisposable メンバ

		public void Dispose()
		{
			try { ChannelServices.UnregisterChannel(mChannel); }
			catch { }
		}

		#endregion
	}
}

中で利用している「IMessageHolder」クラス

namespace ExMutex
{
	/// <summary><seealso cref="Kyoh.ExtendedMutex"/>で用いる、プロセス間メッセージのラッパー。</summary>
	/// <typeparam name="T">メッセージに用いるオブジェクトの型</typeparam>
	public interface IMessageHolder<T>
	{
		bool IsCadet { get; }
		T Message { get; }
		event CadetStartedHandler<T> CadetStarted;
	}
}

と、まあ。
「T」やら「TMessage」っていう型アーギュメントがあるけれど、これはプロセス間でやりとりしたいオブジェクトの型を指定する。
型は特に制約を持たない。基本的にはclassであることが望ましい（相互にやりとりできるし）けれど、一方通行のナニであればstructでも問題は無いと思う。
また、単に通知したいだけなら、メッセージを飛ばす必要もないので、T（TMessage）にobjectを指定して、渡すメッセージはnull、でも何ら問題ない。

次に、どういう風に使うか、の例。
GUIの場合とCUIの場合両方で書いてみた。

GUIの方は単に、先に走っていたプロセスがあった場合にはそのプロセスの画面（MainForm）をアクティブにする（実際にはタスクバーで点滅が起きる）という処理。ただし、CUIとして動かすために全面的にコメントアウトされているので注意。実際にはちゃんとMainFormとして画面を作らなくては動かない。

CUIの方では、メッセージとして

Environment.CommandLine

を渡している。つまり、呼び出しコマンドをそのまま文字列として渡している。

using System;

namespace ExMutex
{
	public class Program
	{
		/*
		static MainForm mainForm;

		[STAThread]
		static void Main()
		{
			using(var mutex = ExtendedMutex<object>.Start("testProcessName", null))
			{
				if (!mutex.IsCadet)
				{
					Application.EnableVisualStyles();
					Application.SetCompatibleTextRenderingDefault(false);
					Program.mainForm = new MainForm();
						mutex.CadetStarted += new CadetStartedHandler<object>(CadetStarted);
					Application.Run(Program.mainForm);
				}
			}
		}

		static void CadetStarted(IMessageHolder<object> holder)
		{
			try { Program.mainForm.Activate(); }
			catch { }
		}
		/*/
		static void Main(string[] args)
		{
			// メッセージを文字列型で受け取るMutexに
			// コマンドラインをそのまま渡す
			using (var mutex = ExtendedMutex<string>.Start("testProcessName", Environment.CommandLine))
			{
				if (mutex.IsCadet)
					return;

				// 後から起動されたプロセスを処理
				mutex.CadetStarted += new CadetStartedHandler<string>(CadetStarted);

				// ポーリング
				string input;
				do { input = Console.ReadLine().Trim(); } while (string.IsNullOrEmpty(input));
			}
		}

		/// <summary>後から起動されたプロセスのメッセージを表示する</summary>
		/// <param name="holder">表示するメッセージ</param>
		static void CadetStarted(IMessageHolder<string> holder)
		{
			Console.WriteLine(holder.Message);
		}
		//*/
	}
}

詳しい話はそのうち気が向いたら（＝十中八九気は向かない）書くけど、
要するに「先に起動した方がサーバー」「あとに起動した方はクライアント」として動作する、クライアント・サーバーモデルなあん畜生で通信してるんですよ。

もしかしたら、うまくいかないケースもあるかもしれない。

といってもたいしたことはしてないので、まぁまず安全だとは思います。
利用環境はFirefox 3で動作確認をしています。

→Download

→SourceCode:

// ==UserScript==
// @name           mixi ssler
// @namespace      net.kyoh.greaseMonkeys
// @description    All links to mixi(http://mixi.jp/*)in the document will be replaced to ssl format(https://mixi.jp/*).
// @author         kyoh
// @include        *
// @exclude        http://mixi.jp/*
// ==/UserScript==
for(var i = 0; i < document.links.length; i++) {
if (document.links[i].host == "mixi.jp:80" ||
document.links[i].host == "mixi.jp")
document.links[i].protocol = "https:";
}

[2009/3/13]
つつみんぐにご指摘いただいたとおり、SSHではなくSSLでした。
未だに間違える…。バカだな。
文中ならびにスクリプト中の「SSH」を全て「SSL」に訂正しました。