Facebookのデフォルト設定では、誰でもWebから検索できるようになっているが、これをWebからの検索を拒否する設定に変えてみる。

先ずは、ログイン後にホーム→プライバシー設定で「つながり設定」をクリック。

ここで、「名前または連絡先情報を使ってあなたを検索できる人」の設定を編集。友達のみに変更してクリック。

次に、「アプリとウェブサイト」の「設定を編集」リンクをクリック後、一般検索の「設定を編集」ボタンをクリックする。「一般検索を有効にする」の前のチェックボックスのチェックを外せば設定が完了する。

これで、Webサイトからの検索を拒否する設定になったので、ブラウザからhttp://twitter.com/ユーザー名で検索すると、次のように表示される筈だ。。

ビジネスでFacebookを活用する場合は、できるだけ多くの人から検索される方がよいが、家族やリアルな友人だけでのプライベートな使い方をする場合は、この設定を試してみるとよいかもしれない。

前回WordPress3.2.1をインストールした時点では、まだベータ版だったが、11月4日をもって正式版となっている。この間、WordPress3.2.1は問題もなく動作し続けていて、レスポンスもまずまず。これがおまけのサーバーとはとても思えない。

ちなみ、このお試しサイトにインストールして動作を確認したプラグインは次のとおり。

• Contact Form 7
• Ktai Style
• Lightbox 2
• WordPress Importer
• WPtouch

なお、スターサーバープラスには、一部のPHP関数への利用制限やフォルダ、ファイルグループへの書き込み権限の制限(707や777とできない)などがあるので、すべてのプラグインが使えるという保証はないので注意が必要。

実をいうと、10月の時点では、WordPressだけでなく、CodeIgniterベースのSeezooCMSのインストールにも成功していたが、正式サービスのスタート直前に、PHP関数に対する新たな利用制限などが加えられ、そこで動かなくなった。

まあ、年間ドメイン管理料だけで、WordPressがサクサク動くサーバーが利用できるのだから、これ以上の贅沢はいえないかもしれないが、今後の規制緩和に期待したい。

WordPress3.3RC1もサクサク動く

正式リリースが間近に迫ったWordPress3.3のRC1もスターサーバープラスで動作確認を行ってみた。

インストール手順はいつもの通りで、WordPressのサイトから日本語版(もちろん英語版でもよい)をダウンロードして、適当な場所で解凍。これをFTPクライアント(前もってFTPの設定は行っておく)などで、サーバーにアップロードして、ブラウザでアクセスすると、インストールが始まる。

次へボタンを押して画面を移動しながら、wp-config.phpの作成、データベースの設定と進み、最後にユーザー名や電子メールなどを登録すれば完了。

前バージョンまでは、wp-config.phpを手動で行わなければならなかったが、3.3RC1ではこれを自動で作成してくれるので、これだけでも、入門者には随分敷居が低くなっていると思う。また、最初のログイン時に出てくるメッセージ(2回目から非表示にできる)もユーザーフレンドリで好感度が高い。また、ヘルプ機能が大幅に向上していて、こちらも入門者にやさしい設計となっている。

全体的に、今回のアップグレードは、操作性の向上に重きが置かれているようで、今後ますますWordPressユーザーが増えていく予感がする。

冒頭で紹介したスターサーバープラスでは、最低でもWordPressが動くことを目標にチューニングれているようで、特殊名プラグインを使わない限りバージョン3.3も問題なく動作しそうだ。

事の発端は、今年10月20日にニューヨークで行われたExpressionEngineとCodeIgniterのプレゼンテーションの席で、EllisLabのCEOが、CodeIgniterのライセンスをOpen Software License 3.0に変更すると発表したことから始まる。

その後の詳しい経緯については、次のサイトなどを参照していただきたい。

• CodeIgniter のライセンス変更問題のタイムライン

そもそもCodeIgniterは、オープンソースソフトウエアではあったものの、CodeIgniterライセンスという独自ライセンスを採用していた。このライセンスについて、EllisLab側は、BSD/Apacheライクなライセンスだと説明していたが、CodeIgniterの商標保護や宣伝条項があるために、正式のBSDライセンスやApacheライセンスではなかった。

今回のOSL3.0へのライセンスへの変更を決定する前にも、BSDやMITライセンスの採用が検討されたようだが、結局、この商標保護と宣伝条項があるため、最後はOSL3.0に落ち着いたということらしい。

この辺りの事情は、下記のEllisLabのブログでも詳しく説明されている。

• Software License Wrap-Up and OSL 3.0

OSL3.0とはどんなライセンスなのか

EllisLab側の主張では、独自ライセンスからOSL3.0に変更になることにより、CodeIgniterのオープンソースとしてのスタンスが明確になり、コミュニティにとっても有益だということになっている。

OSL3.0は、Lawrence Rosenによって提唱されたオープンソースライセンスで、
Open Source Initiativeによる認証も取得しているのだが、今、コミュニティで懸念されている最大の問題は、GPLライセンスとの互換性だ。

次の表は、CodeIgniter License and Terms of Use FAQのなかで使われているもので、OSL3.0と他のオープンソースライセンスとの互換性を示している。

これを見ると一目瞭然だが、GPLとの互換性だけがNoとなっている。これは、GPLライセンスに基づいて作成されたソフトウエアのソースコードを含む製品には、GPLライセンスが適用が及ぶという条項と、OSL3.0のソフトウエア派生物についての考え方とぶつかりあってしまうためだ。

例えば、EllisLab側は、OSL3.0が採用されているMagentoコミュニティの例をあげて、CodeIgniterのライセンスがOSL3.0に変更されたとしても、CodeIgniterのapplicationフォルダ内に作成したソフトウエアにはOSL3.0の条項は及ばないとしている。これは、OSL3.0が、ソフトウエア本体を改変しない限り派生物とはみなさないという考え方に基づいており、ライブラリの単純なリンクも対象外となる。

これにより、ユーザーが作成したソフトウエアの著作権が守られ、CodeIgniterを使った商用アプリの開発が容易になるが、その反面、applicationフォルダ内に作成するソフトウエアではGPLのソースコードを利用できなくなる恐れが生じる。先ほどのGPLライセンスの条項とぶつかり合ってしまうのだ。

ポストCodeIgniterの動きはあるか

ここから先は、法律解釈の問題も出てくるので、専門家の意見などを参考にしなければならないかもしれない。

EllisLab側も、最初は懇切丁寧に説明していたが、最近は徐々に、乱暴(訴訟大国のアメリカと日本では温度差の違いはあると思うが…)な説明の仕方になり始めていて、現行のCodeIgniterライセンスも元々GPLライセンスとは互換性がなかったとまで主張し始めている。

これに対して、日本CodeIgniterユーザ会ではCodeIgniterのライセンスがOSLに変更されることに関する投票などが呼びかけられており、こうした動きが世界的に広がるかもしれない。ただ、EllisLab側は、法的に問題はないとして、顧問弁護士と二人三脚で強引に事を進めてしまう可能性は高い。

個人的には、CodeIgniterベースのIonizeという多言語対応CMSが、MITライセンスで配布されていることを確認して今はひと安心だが、まだ予断をゆさない。

できることなら、コミュニティとの良好な関係を維持した上で、ライセンス変更を行ってもらいたいと願っているが、現実的にライセンスの変更が行われれば、CodeInginterの使用を止めるかGPLライセンスで提供されるソフトウエアの使用を止めるかという二者択一を迫られる人が出て来る。

そんななか、ポストCodeIgniterの候補として、次のふたつのフレームワークが少し話題になり始めている。

• Kohana
• FuelPHP

上記のいずれもがCodeIgniterから派生したプロジェクトで、KohanaがBSDライセンス、FuelPHPがMITライセンスで配布されている。ただし、どちらも現時点では、発展途上という印象が強く、GPLライセンスとの問題でCodeIgniterを利用できなくなるユーザーがこちらに移行するかどうかは未知数。

【注　記】
この記事は、あくまでも個人の見解であって、明確な法的な根拠があるわけではありません。OSL3.0については、提唱者のLawrence Rosen自らが解説するサイトもありますので、各自で内容をじっくり検証してください。

Linux Mintの最後の数字は、これまでUbuntuのバージョンを表していた。ところが、今回は、Ubuntu11.10ベースでありながら、12となっている。

これは、Gnome3とMGSE(Mint Gnome Shell Extensions)の採用によって、見た目と操作性が大きく進化したということのようだ。

これまで通りのインストール手順

外見は大きく変わったものの、インストール手順はこれまで通り。

先ずは、Linux Mintのサイトで自分の環ら境にあったDVD又はCDイメージをダウンロードして、これをBraseroなどでDVD又はCDに焼き付ける。

次に、PCを再起動して、DVD又はCDから立ち上げたら、デスクトップにInstall Linux Mintというアイコンが現れるので、これをダブルクリック。

日本語を選択して「続ける」ボタンをクリック。

インストールの準備が整ったら「続ける」ボタンをクリック。

自分の環境に合わせて選択。「それ以外」を選択すると詳細なパーティションができる。GRUBのインストール先も選択できる。

ロケーションの選択。日本人はみんな東京に住んでいることになっている。

キーボードレイアウトの選択。Macintoshもある。

アカウントの基本情報の登録。

インストール開始。レガシーPCならゆっくりコーヒーが飲める。

日本語環境は自分で整えよう

インストールが終わって、再起動すると、日本語入力ができないことに気づくだろう。Linux Mint 11までは、日本語を選択してインストールすれば、何もしなくて日本語入学ができていた。

どうもこれはインストーラーのバグの可能性が高いのだが、現在のLinuxの日本語環境構築は、昔と違って誰にでもできるレベルになっているので、取り合えす自分好みの日本語環境を整えてみよう。

日本語入力システムにAnthyを使うとした場合、インプットメソッド構築の組み合わせは次のとおり。それぞれのパッケージをapt-getコマンド又はSynapticパッケージマネジャーなどで、インストールするだけ。

iBusとAnthyの組み合わせは、Ubuntuでもお馴染みだが、Linux Mint 12の場合、日本語入力を選択したときに、Anthyのマークが表示されないという小さなバグがあるようだ。ただし、機能そのものには問題はない。

• ibus
• anthy
• ibus-anthy

uimとAnthyの組み合わせは、Linux Mint Debianの記事でも紹介している。ただし、Linux Mint 12ではデフォルトテーマのツールバー背景色とマッチしないかもしれない。後は好みの問題。

• uim
• anthy
• uim-anthy

SCIMとAnthyの組み合わせが、今のところ、最も無難かも。

• scim
• anthy
• scim-anthy

思っていたほどメモリを消費しないLinux Mint 12

最後に、システムモニターによるメモリ消費量を確認したところ次のとおり。

以前、同じPCで計測したLinux Mint 11のメモリ消費量は、2GBメモリ中217.3MB（10.8%）だったが、今回のLinux Mint 12は2GBメモリ中165.0MB（8.2%）使用ということで、これはかなり優秀な成績。

Gnome3によるところの改善なのか、MGSEのチューニングの良さなのか、その当たりははっきりしないが、何れにしてもメモリ消費量が減少したことは朗報だ。UbuntuのUnityシェルとは対照的だ。

また、以前のMintの外観を愛するという人には、MATEというクラシックなデスクトップ環境も用意されている。

DVDでインストールした場合は、デフォルトでインストールされており、ログインの際に選択できるようになっている。CDでインストールした場合は、後からapt-getコマンドやSynapticパッケージマネジャなどで、mint-meta-mateパッケージをインストールすれば利用できる。

では、Ubuntu11.10にアップグレード後はどうなっているのかということで、改めて計測してみたら、2GBメモリ中426.0MB（21.2%）という数字になった。UbuntuのUnityシェルがどんどんユーザーフレンドリーになって行く半面、メモリー消費量もどんどん増えていくという、ある意味当然の結果となった。

Update Pack 3を施したLinux Mint Debianの場合

前述の記事中にはLinux Mint Debianについての数字も残っていた。同量のメモリーを搭載した別PCでの計測ではあったが、2GB中156.7MB使用という数字が残っている。

そこで、Update Pack 3を施した後の最新のLinux Mint Debianについて、システムモニターで調べてみたら、次のような結果が出た。

前回の計測が違うPCで行われたことや、Pack3へのアップデートの際、日本語入力メソッドをiBusからuimに変更したことなどが多少影響しているかもしれないが、それでも2GB中133.2MB（6.6%）というのは驚くべき数字に違いない。

今回、同じ条件下で計測したUbuntuと比較して、メモリー消費量が3分の1以下に抑えられているということになるのだ。

Xfce4とLXDEのメモリー消費量比較

さらに、参考までに、Update11.10で、軽量デスクトップのXfceやLXDEを使用したときのメモリ消費量についても、調べてみた。

UbuntuソフトウエアセンターでXfce4、LXDEと検索して、インストールを完了させたら、ログアウトして、Xfceセッション又はLXDEを選択してログインしなおせばデスクトップ環境が切り替わる。

両者のメモリ消費量は以下のとおり。

• Xfce4 on Ubuntu11.10：
  2GBメモリ中348.2MB（17.4%）使用

• LXDE on Ubuntu11.10：
  2GBメモリ中269.0MB（13.4%）使用

両者ともUbuntu標準のGNOME＋Unityシェルの組み合わせよりもメモリ消費量は減ってはいるが、Xfce4で3%、LXDEで7%の減少だから、想像していたほどではない。

しかし一方で、GNOME版のLinux Mint Debianと比較した場合、Xfce4が2.5倍強、LXDEで約2倍のメモリを消費していることになり、ここでもLinux Mint Debianの軽やかさが際立っていることがわかる。

エレガントな操作性とPCリソースの消費量抑制

もちろん、体感速度がメモリ消費量だけで決まるというわけではないし、大量のRAMを搭載したPCの場合は、これらの数字はほとんど誤差の範囲になる。

個人的にも、仕事やプライベートで使うPCのほとんどにUbuntuとLinux Mint Debianの両方をインストールして、使い分けているが、両者に極端な体感速度の差を感じることは少ない。

ただし、今回テストしたような引退寸前のレガシーPCとなると話は別で、Linux Mint Debianの動作の軽やかさは特筆ものだ。その差は誰にでも体感できるだろう。

Ubuntuの場合、PCのリソースの消費量を増大させてでも、ユーザビリティを向上させたいという傾向があるように思える。これは、デスクトップOSとしての地位を固めるための戦略だろう。その意味からいうと、Ubuntuの場合、最新OS(今ならWindows7)が走るPCで、ストレスなく動作することを念頭に置いていると考えてよいかもしれない。

これに対して、Linux Mint Debianのベースは、レガシーPCを含め、できるだけ多くのハードウエアをサポートしようとするDebianのテスト版である。このため、リソースの消費量を極力抑えてレスポンスの向上を優先させているようだ。

もちろん、これはあくまでもポリシーの問題であって、どちらが正しいとはいえないが、少なくともLinux Mint Debianは、リソース消費量の抑制とエレガントな操作性というユーザビリティの両立に成功しているといえるだろう。

なお、さらなるメモリ消費量の抑制を望む方には、Xfce版のLinux Mint Debianも用意されている。

OpenIndianaとは、OracleのSun Microsystems買収に伴って終了した、OpenSolarisプロジェクトの後を引き継いだOSだ。Solarisとの互換性を保ちつつ、これまでバイナリでしか提供されていなかったカーネルやライブラリ類などを順次オープンソースされていくことを目標にしている。今回お試ししたバージョン151aでは、カーネルがオープンソースのIllumosに置き換えられ、仮想化ソリューションとしてKVMが統合された。OpenIndianaプロジェクトの詳細については、日本語のプレスリリースを参照していただきたい。

超簡単なGUIインストール

先ずは、OpenIndianaのサイトで、isoイメージファイルをダウンロードする。サーバー用とデスクトップ用があるが、今回はデスクトップ用のisoイメージファイルにした。これをBresaroなどでDVDに焼き付ける。

LiveDVDが出来上がったら、PCを再起動して、このインストール用のLiveDVDから立ち上げる。途中でキーボード配列と言語を問われるので、どちらもJapaneseと(当然環境によって違ってくる)答えておく。番号でいうと23番と15番だ。

上記はLiveDVDで立ち上がった直後のOpenIndianaの様子。デスクトップ環境がGNOMEということもあって、バージョン一桁代の頃のUbuntuという感じの雰囲気だろうか。

デスクトップにある「OpenIndianaをインストールする」というショートカットをダブルクリックするとインストールが始まる。Gpartedのショートカットもデスクトップに用意されているが、私の環境では、うまくHDDを認識しない。OpenIndiana用のHDD領域は前もって作っておいた方がよいかもしれない。

OpenIndianaをインストールするディスク領域の選択からはじまり、タイムゾーンとロケールの設定をして、最後にユーザー設定となる。rootパスワードとログイン名、ユーザーパスワードなどを登録すればインストールが始まる。当然のことだが、rootやユーザーパスワードはしっかり覚えておく。

インストールが完了すると、再起動を促される。初期設定のために少々待たされた後、コンソール画面からログイン名とパスワードをされるので、先ほど登録したログイン名とユーザーパスワードでログインする。以上でインストールは完了。作業自体は、Ubuntuより簡単だった。

デスクトップOSとして最低限のものは揃っている

ログインした直後の印象としては、どことなく動作がまったりとしているという感じ。同じPCにUbuntu11.10も入っているが、こちらと比べてもレスポンスが悪い。まあ、これはグラフィックドライバーのチューニングの問題もあるかもしれないし、そもそもSolarisを祖先に持つクラウドプラットフォームOSを、引退寸前の非力な32bitノートPCでテストすること自体に無理があったのかもしれない。

それでも無線LANの設定も簡単だし、ブラウザのFirefoxやメールクライアントのThunderbirdも予めインストールされていて、デスクトップOSとして最低限のものは揃っている。パッケージマネジャーもカテゴリ別になっていて分かりやすい。足りないものがあれば、カテゴリを選んでインストールすればよい。

アプリケーション→オフィスを覗いてみたのだが、このカテゴリには、ワープロや表計算ソフトがまだ登録されていない。OpenOfficeにするか、LibreOfficeにするか迷っているのかもしれないなどと勘ぐってしまいそうだ。ちなみに、アプリケーション→グラフィック画像処理のカテゴリにはGIMPが登録されていた。

なお、デフォルトでは日本語入力ができないので、パッケージマネジャーでIMEをインストールする必要がある。アプリケーション→システム→国際化のカテゴリを見ると、iBusやSCIM、Anthyなどが登録されている。

一応、iBusとAnthyの組み合わせで、インストールしてPCを再起動したところ、日本語入力とは関係のない別の問題が発生した。

OpenIndianaのGRUBはLinuxに未対応だった

OpenIndianaのブートローダは、GRUBに独自の改良を加えて、zfsファイルシステムにも対応しているとのことだったが、Windowsは認識できているものの、２つのLinuxが認識されていない。

ちなみに、同じHDDにインストールしていたLinuxは、Linux Mint DebianとUbuntu11.10で、ファイルシステムはext4、kernelバージョンはどちらも3.0.0だった。

馴れないOpenIndiana側でGRUGの設定をいろいろと弄ってみたが、解決できない。そこで、Linux側のGRUGからOpenIndianaを認識させてやろうとしたのだが、これもうまく行かない。

Gpartedで確認してみると、Linux側からは、OpenIndianaの領域がext4ファイルシステムと認識されている。どうやら、パッチを当ててコンパイルしてやらないとGRUBでzfs領域を認識することはできないようだ。

Ubuntu側からGRUBを再インストール

というわけで話がどんどんややこしくなって収拾がつかなくなったので、OpenIndianaのお試しはここまで。zfs対応のGRUB作ってもいいが、失敗したら、HDDのデータがすべて消失する危険がある。やはり、もう少しパワーのあるPCにOpenIndianaをインストールしてテストするというのが正解なのかもしれない。

なお、Ubuntu側からGRUBを再インストールする手順は次のとおり。

1. PCをUbuntuのLiveCDで立ち上げる
2. 初期画面が表示されたらF6を押す
3. 設定画面でさらにもう一度F6を押す
4. 起動オプションの後の文字列からboot=casperという箇所を探す
5. 見つかったら、boot=casperを例えばroot=/dev/sda6などに書き換える
   なお、/dev/sda6はUbuntuをインストールしているパーティション

以上の設定が終わり、エンターキーを押せば、HDDにインストールしたUbuntuが立ち上がる筈なので、端末から次のコマンドを打ち込めば、GRUBの再インストールは完了する。

SolarisのDNAが持つ実力

わずか数時間のお試しでは、何も結論めいたことは言えないが、発足から1年あまりでここまで来るとは思っていなかったので、開発チームの実力とモチベーションはかなり高いといえるだろう。

デスクトップOSとしては、少々荒削りな印象を受けたが、やはりクラウドプラットフォームOSとしてのポテンシャルを評価するのが正解かもしれない。

LinuxやFreeBSDに代表されるオープンソースOSが切り開いた市場にどこまで食い込めるかという問題はあるだろうが、AT&TとSunが共同開発したSVR4から生まれたSolarisのDNAを持つOSが、完全オープンソース化に向かっているということの意義はそれなりに大きい。

また、今後のOracle Solarisとの関係も気になるところで、Red HatとFeroraプロジェクトのような関係になるのか、CentOSやScience Linuxのような立ち位置になるのか、今後の動向には注目しておきたい。

Mozillaの開発を打ちきったMozilla Foundationは、Mozilla FirefoxとMozilla Thunderbirdの開発に注力して成功を収める。このとき、Googleの社員が業務の一貫としてFirefoxのソースコードを書いていたという話は有名だが、後に、GoogleはFirefoxのソースコードを基にして、Chromeという独自のブラウザを開発する。

今になって考えてみると、GmailやGoogle Docsを有するGoogleにとっては、Chromeは単なるブラウザではなく、インターネット統合アプリケーションだったということになる。

つまり、ひとつのアプリケーションですべてのインターネットのサービスを網羅すると便利ではないかという考え方は古くて新しい考え方かもしれない。ご存知のように、Thunderbirdにブラウザ機能を追加するThunderBrowseというプラグインもあるくらいだ。

SeaMonkeyはマルチプラットフォーム対応

SeaMonkeyの安定版はバージョン2.4.1で、開発版は2.5ベータ3となっている。それぞれのバージョンには、Windows版、Mac版、Linux版が用意されていて、ネスケ時代からの伝統を引き継ぎ(今や常識の範疇だが)、マルチプラットフォーム対応となっている。http://www.seamonkey-project.org/releases/#2.4.1

現時点では、Ubuntuや(バージョン11.10からパッケージ化された)Linux Mintではパッケージのメンテナンスは行われていないようなので、Linux Mint Debianユーザーの場合は、SeaMonkeyのサイトからバイナリファイルをダウンロードして手動でインストールしなければならない。

といっても、GNOME版ユーザーなら(たぶんXfceでも同じだと思う)、ダウンロードしたファイルを解凍して、seamonkeyフォルダ内のseamonkeyファイルをダブルクリックするだけで、SeaMonkeyを簡単に起動できる。

あとは、Mintメニューの設定→メイン・メニューでアプリケーションとしてSeaMonkeyを登録すれば、Mintメニューから起動できる。

レトロな感じのFirefoxとThunderbirdだが

SeaMonkeyを開発しているSeaMonkey Councilは、元々がMozilla Foundationからスピンオフしたボランティアグループで、お互いの成果をフィードバックしている。ということで、現時点ではFirefoxプラスThunderbird(HTMLエディタやChatZillaもおまけでついてくる)という感じで、SeaMonkeyならではの驚くべき機能というものはない。

MozillaサイトのAdd-ons for SeaMonkeyに登録されているテーマや拡張機能も数は少ない。ただ、LightningやGmail Manager、FlashGotなど、FirefoxやThunderbirdでメジャーな拡張機能は登録されている。個人的は、WebMail Notifierが登録されているのがうれしい。あと、ブックマーク管理のXmarksが対応してくれないかと密かに望んでいたりする。

Macユーザー時代からのネスケユーザーの立場からすれば、SeaMonkeyのレトロな雰囲気は、ある意味魅力的なのだが、FirefoxやThunderbirdのユーザーに積極的に乗り換えをお薦めする理由は、今ところ見当たらない。

ただ、日本語にも対応しており、開発スピードも飛躍的に向上しているという点では、今後に期待できるアプリケーションのひとつであることは間違いないだろう。

LMDE 201012に比べるインストーラーが改善されていて、起動時間等が格段に短くなっているような気がするが、日本語インプットメソッドについては、ibus + Anthyの組み合わせだと端末(gonme-terminal)で不具合が起こる。日本語も半角ローマ字も入力がおかしくなるのだ。

組み合わせをSCIM + Anthyに変更しても、状況は変わらない。端末を起動した直後にSCIMをオフにすれば、何とか半角ローマ字だけは入力できるようになるが、これではあまりにも不便。そこで最後に、UIM + Anthyの組み合わせを試してみたら、これはうまく行った。

synapticパッケージマネージャーやapt-getコマンドで、次の3つのパッケージを順番にインストールすれば。UIM + Anthyの組み合わせで日本語インプットメソッドの構築ができる。

• uim
• anthy
• uim-anthy

なお、少し欲が出て、変換エンジンにMozcを追加してみたが、端末では何も起こらないものの、パッケージマネージャーの起動が異常に遅くなるという現象が起きた。どうやらMozc変換サーバーとの相性問題があるようだ。apt-getなどでuim-mozcを削除すれば、この問題は解決する。

Pack 3でkernel-3.0へアップグレード

インストールが完了したら、アップデートマネージャーによるパッケージの更新を行う。最初にmintupdate-debianのアップデートを行ういかどうか問われるので、アップデートを受け入れると、アップデートマネージャーが自動的に再起動する。

再起動後は約400個近いパッケージのアップデートが提示される。これには、LMDE Pack 3へのアップデートも含まれている。Pack 3には、セキュリティやマルチメディア関連のパッケージのアップデートとともに、Linuxの最新カーネルkernel 3.0へアップグレードが含まれる。

これらのアップデートを受け入れれば、後はしばらく待つだけだが、アップデート作業の途中で、次のようなエラーメッセージが出て、作業が中断される。

ここで一旦アップデートマネージャーを終了して、Synapticパッケージマネージャー又はapt-getコマンドなどで、gstreamer0.10-plugins-badとgstreamer0.10-plugins-really-badの2つを削除した後、アップデートマネージャーに戻れば問題は解決する。

スタードメインでは、ドメインを新規取得又は移管すると、ドメイン毎にメール転送やサイト転送、GoogleApps簡単設定、10GBのウェブスペースといった無料の付加サービスが提供される。これらの付加サービスの総称がStar Serverだが、今回のStar Server Plus(ベータ版)では、ウェブスペースこそ3GBに減るものの、その他のサービスはそのままで、新たにPHP5.3.3(一部制限あり)とMySQLアカウント1個が利用できるようになる。

Star Server Plus(ベータ版)を利用するためには、切り替え手続きが必要で、すでにスタードメインでドメインを管理している人は、自分のアカウントにログインした後、次のような手順で切り替えができる。

• スターサーバープラス(ベータ版)について

切り替えが終わるとサーバー管理ツール内にデータベース設定とphp.ini設定が加わる。なお、一度切り替えを行うと、30日間は設定の切り替えが行えないので注意が必要。また、切り替え時にDNS設定以外のサーバー上のデータは初期化されるので、切り替え前にバックアップを取っておくこと。

WordPressのお試しインストール

そこで、実際にWordPress3.2.1をインストールしてテストしてみた。

先ずは、サーバー管理ツールのFTPアカウント設定で、パスワード設定(初回利用時のみ)を行う。ドメイン名の横の[編集]リンクをクリックするとパスワードが設定できる。

次にファイルマネージャー又はFTPクライアントを通じて、最新版のWordPressをアップロードする。この間に、データベース設定で、MySQLのアカウントを発行して、ユーザーを追加やパスワード設定などを行っておく。

WordPressのアップロードが完了したら、DNS設定でStar Server PlusのIPアドレスをドメイン名(又はサブドメイン名)に仕向け、ブラウザからWordPressのファイルにアクセスすれば、いつものようにWordPressのインストール作業が始まる。前もって発行しておいたデータベース名やユーザー名などを入力すれば、インストールは問題なく完了する。

あくまでもベータ版上に構築したお試しサイトということで、絶対に問題がないとは言いきれないが、今のところ、特に気になる問題は発生していない。

ちなみに、今回のお試しインストールでテストしたWordPressのプラグインは下記のとおり。

• Contact Form 7
• Ktai Style
• Lightbox 2
• WordPress Importer
• WPtouch

スターサーバープラスでは、PHPに一部制限があるので、将来的には使えないプラグインが出てくる可能性は否定できないが、WordPressの場合、代替プラグインが見つかる可能性も高いので、WordPress本体さえ問題なく動作していれば、何とかなるような気がする。

今のところレスポンスもまずまずで、これが、PHPに一部制限によるものだとすれば、この程度の制限はむしろ歓迎すべきものかもしれない。

なお、PHPの一部制限は次のとおり。

• PHPの仕様について(※スターサーバープラスのみ)

ベータ版から正式版になったらたぶん激安No.1

今回はあくまでもベータ版上に構築したWordPressのお試しサイトということで、本格的な運用に耐え得るかどうかは未知数だ。

ただ、この仕様に近いものが正式版として出るなら、個人のブログや小規模のコーポレートサイトなら十分に耐えられるような気がする。そうなると、Star Server Plusは、WordPressをインストールできる最安値サーバーということになるだろう。

現在、WordPressをインストールできる最安値サーバーはServerQueenだが、こちらは年額費用が1440円、MySQLが使えない(つまりWordPressが使えない)ロリポップのコロリポプランでも年額費用は1260円で、独自ドメインを利用する場合は、別途管理料が必要になる。これに対してStar Server Plusの場合、年間850円～920円程度の.comドメインや.netドメインの管理料を支払えば、WordPressを無料で運用できるというわけだから、正式版が登場すれば、激安No.1と言い切っていいかもしれない。

また、スタードメインを運営するネットオウルでは、ミニバードやファイアーバードといった本格的なレンタルサーバーも提供されているので、取り敢えずStar Server Plusで始めておけば、本格的なレンタルサーバーへの移行もスムーズに行えそうだ。

さっそく試してみたのだが、このプラグインはまだテスト段階ということもあって、私のUbuntuローカル環境では動作しなかった。そこで、他にもWordPressとCodeIgniterを連携させる方法はないかと調べてみると、あちこちでいろいろな試みがなされているようだが、大きく分けると次の3つに分類できる。

1. プラグインを通じた統合（WP Code Igniterの場合がこれ）
2. テーマとfunctions.phpを利用した統合
3. CodeIgniterのルートディレクトリ内にWordPressのフォルダを作って統合

上記の方法のうち、2番目の方法でチャレンジしている人が多かったようだが、その方法は千差万別で、使用しているCodeIgniterのバージョンも比較的古いものが多い。

CodeIgniterのViewをテーマ内から利用しようという発想は、シンプルで解り易いのだが、WordPressとCodeIgniterの両方に精通していないと実現は難しく、構築後のメンテナンスも大変そうだ。

WordPressとCodeIgniterの最も簡単な連携方法

ということで、最後に残った3番目の方法だが、これが一番原始的な方法で、ほとんど説明の必要がないほど単純明解だ。

例えば、CodeIgniterのルートディレクトリにblogという名前のフォルダを作り、そこにWordPressをインストールすれば作業はこれで終わってしまう。

唯一懸念される問題は、CodeIgniter側でWordPressをインストールしたフォルダと同名のコントローラーを作った場合だが、デフォルトの状態で使う場合は問題はない。通常、CodeIgniterでblogコントローラーを作った場合は、サイトアドレス/index.php/blogでアクセスすることになる。これに対してWordPressのフォルダへのアクセスは、サイトアドレス/blogとなるので、両者が衝突することはない。

CodeIgniterのindex.phpを消去したい場合

ただし、デフォルトの状態が気に入らないという人も当然いるわけで、SEO対策上もよろしくない。この問題については、CodeIgniterのユーザーガイドでも、「index.phpを消す方法」として紹介されいる。ルートディレクトリに次の内容の.htaccessを置けば解決する。

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

なお、この設定をした場合、WordPressをインストールしたフォルダと同名のコントローラーがCodeIgniter側にあるときは、CodeIgniterのコントローラーが優先されることになってしまうが、WordPressをインストールしたフォルダのblogをコントローラーに支配させないために、上記の.htaccessの2行めを次のように変更すれば問題は解決する。

RewriteCond $1 !^(index\.php|images|robots\.txt|blog)

本当はSeezooCMSやPyroCMSでもいいのだが

以上で、index.phpも消えてすっきりする。この方法だと、固定ページをCodeIgniterで作り、ブログはWordPressを利用するという使い方ができるだろう。番外編として、WordPressのルートディレクトリにCodeIgniterのsystemフォルダやapplicationフォルダを置くという方法もあると思うが、この場合は、WordPressの管理画面とデータベースのみを利用してサイト構築はCodeIgniterで行うことになるだろう。

もちろん、最初からWordPressとCodeIgniterを連携させようなんて考えないで、「素直にCodeIgniterで構築されたSeezooCMSやPyroCMSなどを使えばいいんじゃない」という考え方もあるだろう。まあ、案外それが正解なのかもしれないが、いくらCodeIgniterが気に入ったからといって、使い慣れたプラットフォームというのは、そう簡単には捨てられるものではない。

また、3番目の方法なら、たぶんWordPress以外のCMSでもうまく行くと思うので、いろいろと試してみると、思いもかけない組み合わせが見つかるかもしれない。

ただし、現段階ではあくまでもお試しレベルなので、予期せぬ問題を孕んでいる可能性はある。実際のサイト構築などに応用するときは、自己責任でお願いしたい。