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() );

CentOS 5.10 を VMware Player 6.0.1 で使う

毎回設定するのでメモ。

1. /boot/grub/grub.conf にカーネルパラメータ追加
nmi_watchdog=0 pci=nommconf

2. インストール直後に追加するパッケージ
kernel-devel kernel-headers system-config-kdump

3. kdump のワーニング対策のため、system-config-kdump で kdump を有効にする

4. VMware tools インストール

Ubuntu 10.04 で Chrome を使い続けるには

Ubuntu 10.04 で Chrome を開くと「Google Chromeはアップデートの提供を中止しています。お使いのバージョンのオペレーティングシステムには対応していません。」と表示されて邪魔くさい。しかし、やはり表示が早くて便利なので使いたい。

なんと、しばらく放置していた 10.04 の Chrome で上記の表示が無いことを発見。理由を調べるとバージョンによるものだと判明。
27 以降だと上記メッセージが表示され、26 以前だと表示されないらしい。

古いバージョンの deb を検索したところ、以下を発見。
http://95.31.35.30/chrome/pool/main/g/google-chrome-stable/

10.04、まだまだ現役で使います。12.04 のデスクトップは微妙なので。

今更ですが Ubuntu 12.04 で FreeNX する。

サーバ側の手順。

$ sudo add-apt-repository ppa:freenx-team/ppa
$ sudo apt-get update
$ sudo apt-get install freenx
$ sudo vi /usr/bin/gnome-session-nx
#!/bin/bash

export LC_CTYPE=ja_JP.utf8
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
export GTK_IM_MODULE=ibus
export USE_XOPENIM=t
/usr/bin/xmodmap -e 'keycode 123 = backslash underscore'
/usr/bin/ibus-daemon -d -x &
/usr/bin/gnome-session --session=$1
$ sudo chmod +x /usr/bin/gnome-session-nx

クライアントの設定。
Desktop > 「Unix」  「Custom」 > 「Settings…」
NX Client 1

「Run the following command」で作成したコマンド”gnone-session-nx”を使う。
「gnome-session-nx ubuntu-2d」
「gnome-session-nx gnome-fallback」
NX Client 2

Unity-2D で画面は表示されたのですが、解像度が一致していなかったため、以下のように設定。
右クリック > 壁紙の変更 > すべての設定 > ディスプレイ > 解像度

phpPgAdmin で TSV をインポート

たまたまお客さんが準備されたデータが UTF-8 の TSV だったので、phpPgAdmin で直接インポートしようとしたら色々と対策が必要でした。

1. BOM があるとうまく処理できないので、エディタなどで保存し直すなどして取り除きます。
2. 一行目にはテーブルのカラム名を指定する必要があります。
3. 内部的に fgetcsv 関数を使うので、config.inc.php の末尾から2行目に以下を追加します。

setlocale( LC_ALL, 'ja_JP.UTF-8' );

Windows 8 のファイル破損

Windows 8 を使い始めて 1年近く経過しました。大体は安定しているんですが、今までインストールした全てにおいて、普通に使っているはずなのにシステムファイルの破損が発生しています。ほとんどは「サービスが正常に起動しない」「デスクトップ画面が表示されない」など、起動時の問題でした。

個人的には .Net 関係のアップデートやインストールが関係しているように思います。大抵、 .Net 関係の Microsoft Update の後に動作がおかしくなります。原因を解明しても事実上、対策は不可であると思われます。

Surface Pro でもシステムファイルの破損が発生しているので、何か Microsoft の不手際だろうとは思います。

今までのところ、sfc コマンドを使ってリカバリすることで回復しているようです。管理者権限でコマンドプロンプトを開いて、以下のコマンドを実行します。

sfc /SCANNOW

あとは自動的にファイルの修復が行われます。

こんなヲタクじゃないと知らないような手間がかからないよう、なんとかして欲しいですね。

PHPの正規表現で大きな文字列を処理しようとすると極端に遅い

独自開発の CMS で、編集完了したページを公開しようとするとエラーが発生しているようだった。
どうも AJAX で呼び出している PHP スクリプトがタイムアウトしているらしい。
ローカル環境で再現しようとすると、時間はかかるが公開処理は正常にできた。
該当記事をエディタで短くしていくと処理時間が短くなるので、何かしら記事を処理する部分が時間を食っているのはほぼ確実だった。
この CMS ではページを公開する際に、検索用のデータを生成しており、この時、自前の処理で html をパースしていた。

問題はこのパース処理だった。

応急処置として、自前処理ではなく DOMDocument の loadHTML メソッドを使用するようにして、業務に支障がない状態に出来たが、根本対策には html のパースを高速化する必要があった。

mb_ereg 系の関数を使用していたため、preg 系に修正してみたが、今度は Segmentation fault が発生した。どうもデータベースのトランザクション内で正規表現ライブラリをガッツリ使うとメモリが足りないらしい。mb_ereg 系に戻して、再度検討を行う。
よく調べてみると、正規表現を使っている部分は、タグ部分の切り出し時と、切り出したタグ部分の分解だった。タグ部分の切り出し時には mb_ereg に記事全体を渡しており、どうもここが怪しい。
タグ部分の切り出し処理を、正規表現から strpos/substr などの文字列処理関数に修正すると、すばらしい処理速度となり、対策を完了することが出来た。

PHP の正規表現処理は非常に便利なのだが、現時点では大きな文字列の処理には向いていないようだ。
今回のように、処理速度に問題があるようなケースでは、以外な方法のほうが結局速かったりするので、いろんな方法を思いつけるように準備して置かなければならない。