X11RDP-o-Matic のご紹介

明けまして、おめでとうございます。

お年玉と言うわけではないんですが、X11RDP-o-Matic をご紹介いたします。

詳しくは上記のページをご覧になっていただくとして、アキラは Xubuntu 14.04 で正常に動作することを確認しています。
標準パッケージの XRDP の場合には、セッション終了時に RDP クライアントの画面が閉じなかったりするため、安心して使用できませんでした。
X11RDP-o-Matic を使ってインストールすると、上記の不具合もなく、レスポンスも良いと思います。

開発は GitHub を使って行われているため、変更リクエスト(Pull Request: PR)も比較的簡単にできます。
また、Google グループ で相談することもできます。

あきらは今回 GitHub を初めて知りました。
勉強がてら XRDP の日本語キーボード対応の PR を送ってみたところ、採用していただきました。
開発版(develブランチ)で、”\ _”キーと変換キーが正しく入力できるように対策しています。

上記を含めた XRDP & X11RDP のインストール手順は以下となります。

$ sudo apt-get install git
$ git clone --depth 1 -b v3.03 https://github.com/scarygliders/X11RDP-o-Matic.git
$ cd X11RDP-o-Matic
$ sudo ./X11rdp-o-matic.sh --branch devel --justdoit

“–branch devel” の部分を追加するだけです。develブランチとなりますが、十分安定しているように思います。

追記 (2015/02/24)

現時点で上記の変更は master ブランチにマージされています。
“–branch devel” は必要無くなりました。

VAIO Pro 11 を自分なりに活用するまで

以前、持ち運び用に使っていたノートパソコンのバッテリーがへばってきてしまったのですが、Ultrabook 仕様のため、簡単にバッテリーを交換する事ができませんでした。
また、ちょっといいノートパソコンを買ってもいいよと嫁さんが言ってくれたので、ヤマダ電機の店頭で触った VAIO Pro 11 を、ほぼ衝動買いしてしまいました。
実はたまたま CPU ファンが低温時に回って高温時に止まるという初期不良に当たってしまい、購入して1週間で交換してもらったのですが、その後はハードウェアの不具合は発生せず、便利に使っています。

最近、Linux Mint 17 の使い勝手が良かったので、VAIO Pro 11 に入れてデュアルブートにしたくなりました。その際に経験した問題の解決方法をメモしておきます。

■ リカバリーディスクの作成

購入時に初期設定を済ませたら、リカバリーディスクを作成しておきましょう。あきらは外付け DVD ドライブで 4 枚の DVD を作成しました。どうも長期保存に USB メモリや SD カードを使いたくないんですよね。消えてしまいそうで。

Windows 8 モデルでしたので 8.1 にアップデートしましたが、その時点で以下のようなパーティションとなっていました。

・#1 SONYSYS
・#2 回復パーティション
・#3 EFI 用パーティション
・#4 Windows 予約領域
・#5 C ドライブ
・#7 回復パーティション
・#6 リカバリー領域 14.14GB

■ ディスク容量を確保するまで

以下の手順で LinuxMint 用の領域を確保します。

・リカバリー領域の削除
・不要な回復パーティションの削除
・C ドライブのリサイズ

■ リカバリー領域の削除

まず、Windows 8.1 にアップデートするとリカバリー領域でのリカバリーはできなくなります。つまり、無駄な領域となりますので削除します。
参考URL : http://www.call-t.co.jp/blog/mt/archives/entry/015676.html

■ 不要な回復パーティションの削除

Windows 8.1 へのアップデート時に、C ドライブの後ろに勝手に作成されました。C ドライブを縮小して後ろに空き領域を作る際に邪魔となるのですが、下手にいじるとブートできなくなります。また、以前の回復パーティションは十分な容量なので、作成されるのは明らかにインストーラーのバグです。なんとかこのパーティションが削除できないかと調べました。

LinuxMint 17 の DVD で起動して、以下を行います。

・古い回復パーティション(#2)の Recovery/WindowsRE フォルダを削除
・新しい回復パーティション(#7)の Recovery/WindowsRE フォルダを、古い回復パーティション(#2)の Recovery/WindowsRE フォルダとしてコピー

Windows 8.1 で再起動して、コマンド プロンプト(管理者) で以下を実行します。

reagentc /disable
reagentc /setreimage /path \\?\GLOBALROOT\device\harddisk0\partition2\Recovery\WindowsRE\winre.wim
reagentc /enable

正しく再起動できることを確認します。

参考URL : http://answers.microsoft.com/ja-jp/windows/forum/windows8_1-windows_install/win881%E3%81%A7%E5%9B%9E%E5%BE%A9%E3%83%91/c8970d3a-2c52-41c8-9c91-b76e4516b254?page=2

■ C ドライブのリサイズ

再び LinuxMint 17 の DVD で起動して、GParted で以下を行います。

・新しい回復パーティション(#7)の削除
・C ドライブ(#5)を可能な限り拡張(後ろに 36GB を確保するための仮作業)
・C ドライブ(#5)のリサイズ(後ろに 36GB を確保しました)
・C ドライブ(#5)のリサイズに時間がかかるため、操作を適用しておく

・LinuxMint 用 / パーティション作成(32GBとしました)
・LinuxMint 用 swap パーティション作成(4GBとしました)

■ LinuxMint のインストールと rEFInd のインストール

以下のサイトで詳しく解説されています。大変参考になりました。ありがとうございます。

参考URL : http://qiita.com/rit-rit/items/5adefbd7d4876f0917c3

「Ubuntuのインストール」以降の作業で継続します。

Linux のリモートデスクトップを検討

相変わらず Web システムの開発を行っているわけですが、最近ではリモートデスクトップで VPS の開発用サーバにログインして、作業を行っています。
ファイルの転送は、開発がひと通り終わった後に実サーバへアップロードする1回のみです。
以前はローカルで修正して開発用サーバにアップロードして動作確認後、ローカルから実サーバへアップロードしていたのですが、誤って開発用サーバにアップロードしてしまって実サーバが更新されなかったり、開発用サーバを直接修正したのにローカルのファイルを実サーバへアップロードしてしまって元の状態に戻ってしまったりといった単純ミスが発生していました。

ともあれ、現状の手順だと開発用サーバで IDE(Eclipse) と FTP ソフト (Filezilla) が使いたいため、リモートデスクトップは必須です。

で、色々試した結果、XRDP を選択しました。XRDP にしたのは以下の理由です。

・NX Client がアップデートされて、FreeNX のクライアントとして使えなかったり使いづらくなったりしてしまった。旧バージョンは購入済みの顧客対象に公開されるようになってしまった。
・X2Go のクライアントが安定しない。複数のセッションを立ちあげれない。
・RDP であれば現状でクライアントは困らない。Windows では標準で準備されており、Mac だと Microsoft が無償で提供している。

設定などで注意する点です。

・ポートは標準の 3389 から変更
・レスポンスを考慮して色は 16 ビットにしておく

Skype for Windows が改良されていた

パソコンをシャットダウンする際に、「このアプリケーションがシャットダウンを妨げています」と表示されていたのですが、すんなりシャットダウン出来るようになっていました。
もしやと思って確認すると、Skype for Windows がアップデートされていました。やはりコイツが犯人だったようです。

ありがとうと思う反面、もっと早く対応してくれれば良かったのにと思ってしまうのはしょうがないですよね。

PHP5 の basename 関数のバグ対応

PHP5 の basename 関数にはバグがあり、ファイル名が日本語を含むとうまく処理できません。
ググってみると代替え関数を用意する方法が多く提案されていましたが、あきらは以下の置き換えで対処しました。

basebane( $path )

preg_replace( '/^.*\//u', '', $path )

最長一致がデフォルトなので上手く動きます。

On-Lap 1302 でお手軽マルチディスプレイ

パソコン工房松江店に、ぽつんと置いてあった On-Lap 1302 を買ってみました。

高解像度のノートパソコンを手に入れたのですが、老眼となりつつある自分には小さすぎるか大きすぎるかの解像度しか選択できませんでした。
このため、一時期はやった USB サブディスプレイで解像度が 1366×768 以上で手ごろなものが無いか探していたのです。
しかし USB サブディスプレイは 1280×720 以下のものしか見当たりません。

この On-Lap 1302 は HDMI 入力も必要ですが、1366×768 の解像度があり、スタンドもタブレット用のもので大丈夫そうでした。
結局、一日検討して翌日に購入。売れてなくてよかった。

しばらく使っての感想ですが、解像度がどうとか言う前に、マルチモニタ環境は本当に便利です。
サブモニタで参考資料を開きながらプログラミングするのがこんなに楽だとは思いませんでした。
サブモニタに表示するのは、仕様書、php.net、Yahoo! 翻訳、その他参考になるブログ記事など。
プリントするほどではないけど見ながらタイプしたい場合に本当に便利です。

効率としては 1.2倍ぐらいではないでしょうか?さらに、ストレスは半分以下です。
肝心な部分にどうしてもウィンドウが重なったり、見ながらタイプしたいがためにウィンドウのサイズ変更や移動をする必要がありません。

肝心のOn-Lap 1302 については、以下の感想です。

[良い点]

軽いので移動が楽
USB 電源さえあれば他の機器のモニターとしても使える

[残念な点]

PCへの貼り付け用金具が不用な場合が考慮されていない
HDMLケーブルがちょうど邪魔な位置
付属のスタンドが使いづらいというか使えない
視野角が狭い
LEDが上部ほど暗いみたい
スピーカーも欲しかった

えーっと、はっきり言って他にないから使う程度ですね。
同程度の値段で良いものがあったらさっさと買い替える程度です。
10.1 インチで 1366×768 なら本当に便利なんですけどね。

長い目で見るとサブモニタにパソコンの半額ぐらいは投資しても十分元が取れると感じます。
次は On-Lap 1502I を手に入れるために、お仕事頑張ります。
デスクトップのモニタを On-Lap 1502I にしてしまってもイイかと思っているので。

Windows 8.1 の再起動が遅かった原因が判明

「このアプリがシャットダウンを妨げています。」と、表示されるのですが、どのアプリやらはっきり表示されておらず、イライラしていました。
自分は Skype for desktop を使っているのですが、たまたま Skype を終了させたりしてテストしている時に、終了確認のダイアログを表示しないようにチェックできることを知りました。
これにチェックしたところ、素早く再起動や終了が行われるようになりました。
ちなみに、上記ダイアログを再表示させる方法は不明です。

Skype って Microsoft が買い取ったんですよね?
何というか、ちゃんとテストして考えて欲しいものですね。

※追記
その後、またシャットダウンを妨げているとの表示があり、色々やってみました。
まず Skype を手動で終了させてからシャットダウンすると表示されないので、Skype が原因であることは間違いないことを確信しました。
終了時のサウンドを切ったりしましたが、あくまで表示されない確立を上げる程度でした。

VirtualBox 4.3.4

ノートパソコンに VMware Player 6.0.1 をインストールして使ってみた。
ホストは Windows 8.1 64ビット、ゲストは Ubuntu 12.04 64ビット。
残念なことに、ゲストでタッチパッドでのスクロールが出来なかった。タッチパッドは Synaptics。

試しに VirtualBox をインストールして使ってみたら、問題なかった。
長い間放置されていた漢字キーがリピートする問題も解決されていた。
ちょっと重い表示を行うときにスクリーンが

当面は VirtualBox を使って行こうと思う。

しかし、残念なことに VMware Player も VirtualBox も、高 DPI に未対応なのは残念だった。
今どきの 11.6 インチのノートパソコンだと、文字が小さくて結構つらい。
何とか対応してもらいたいものだ。

mb_ereg_replace で “mbregex compile err: too short multibyte code string in ~”

他のシステムで使っているライブラリで、”mbregex compile err: too short multibyte code string in ~”となってしまいました。
PHP のバージョンによるものかと考えて、鬼車で変更された内容とか色々調べましたが、元のシステムではエラーとなっていない事に注目して、PHP の multibyte 関連の設定を同様にしたら解決しました。

mb_internal_encoding( 'UTF-8' );
mb_language( 'Japanese' );
mb_regex_encoding( mb_internal_encoding() );