永久Pending機関

NEC VersaPro J タイプVRのCPUを換装

2016-07-18T13:29:19+09:00

Celeron Mが遅い

NEC VersaPro J タイプVRのVJ16M/RF-X（2006年5月発売）という10年選手のノートPCをantiX 16 i386（Debian 8 Jessieベース）というOSで運用している。しかし、搭載しているCPUのIntel Celeron M 380がボトルネックと感じる今日このごろ。そこで、このCPUを同じDothanコアのIntel Pentium Mに換装することにした。このPCと同じラインアップのノートPCにはソケット479のマザーボードが採用され、BIOSも共通とのことで、実際このラインナップには以下のとおりDothanコアのPentium Mを搭載している製品もある。

VJ20F/RF-X: Pentium M 760
VJ17F/RF-X: Pentium M 740
VJ16M/RF-X: Celeron M 380 ← ラインナップ中で最弱の我がPC

だから換装できるっぽい。

ラインナップのその他スペック

NEC VersaPro J タイプVRのその他の主要スペックは以下のとおり。詳しくはWayback Machine参照。

チップセット: AMD Radeon Xpress 200M
FSB: 533/400MHz
GPU: AMD Radeon X300 IGP（IXP450）
オンボードメモリー: PC2-4200（DDR2-533）256MB
メモリースロット: PC2-4200（DDR2-533）SO-DIMMスロットx2（最大2GB）
ビデオRAM: 最大128MBをメインメモリーと共有
ハードディスク: チップセット内蔵コントローラー, シリアルATA
オーディオ: チップセット内蔵コントローラー, High Definition Audio準拠
イーサーネット: Broadcom NetLink BCM5789, 1000BASE-T有線LAN
USB: チップセット内蔵コントローラー, USB2.0 x5
PCカードスロット: Richo RL5C476 II, CardBus対応Type I/II x2又はType III x1
ディスプレイ: 15型TFTカラー液晶, XGA（1024x768）

ちなみに、我がPCはメモリーを最大容量まで積んでいる。

VJ16M/RF-Xを分解

ACアダプターを外し、バッテリーパックを外す
ハードディスクを格納している蓋を開け、そこにあるすべてのネジを外す
パームレストを外し、キーボードを固定しているすべてのネジを外す
ヒンジの爪を上げて液晶パネル部と本体部を分離させ、電源ボタンやワンタッチスタートボタンのあるパネルを外す（これをしなくてもキーボードを外せるかも）
キーボードを外すと金属製のカバーが見えてくるので、このカバーを固定しているすべてのネジを外す
カバーを外すとCPUを覆うヒートシンクとクーラーが見えてくるので、それらを固定しているすべてのネジを外す
上の画像の状態になる

ちなみに、各ネジの長さは微妙に異なることがあるので、どこから外したネジかわかるようにしておく。

Celeron Mよさようなら

上の画像にあるCPUソケットのマイナスネジを回し、CPUを取り出す
用意したPentium MをCPUソケットに嵌め、マイナスネジを元に戻す
ヒートシンクから古いCPUグリスを拭き取る
Pentium Mに新しいCPUグリスを塗る
エアーダスターでヒートシンク、クーラー、排気口などを掃除後、すべて組み立て直す

CPU換装後の稼働テスト

う～ん、ちょっとは速くなったのかも、くらいの体感。まあそんなもんでしょ、ベンチマークを取るまでもない。と言うか、もう一つのボトルネックのGPUがそのままだし。しかしNINTENDO 64、ニンテンドーゲームキューブ、WiiのGPUを開発したあのArtXの系譜のIGPとして愛着があるので、そこは目を瞑ることにした。ちなみに、換装後のCPUもC0ステッピングだったためPhysical address extensions（PAE）やNXビット（XDビット）に対応していたので、OS側で設定等を弄る必要はなかった。

SiSでもwattOS R9 Microwattがイケるっぽい

2016-07-17T14:45:51+09:00

未だにWindows XPはいかがなものか

2002年8月に発売開始のShuttle XPC SS51Gというキューブ型ベアボーンPCを未だにWindows XPで運用している変人は、自分くらいのはず。確かに、2014年4月に延長サポートが終了したXPで運用するのはいかがなものか。しかし次のような劣悪なスペックを鑑みるに、XPから後の、よりヘビーなWindowsでの運用は非現実的。

チップセット: SiS 651B, SiS 962L
CPUソケット: Socket 478
FSB: 533/400MHz
CPU: Intel Pentium 4 2.26 Northwood SL7V9 (M0)
GPU: SiS 315 IGP
メモリースロット: PC2700/2100/1600 (DDR333/266/200) DDR SDRAM x2
メモリー: PC2700 (DDR333) 1GB+512MB=1.5GB
オーディオチップ: Realtek ALC650 AC'97 2.2 5.1ch
イーサーネットチップ: Realtek RTL8100B 10/100M
空きスロット: AGP 2.0 x1, PCI 2.3 x1
主な外部接続: Firewire IEEE1394a (VIA VT6306) x2, USB 2.0 x2
電源ユニット: 200W

Prescottすら載らないし、デュアルチャンネルメモリーですらない。そこで、XPの延長サポート終了を機に、軽量Linuxディストリビューションへ乗り換える方向で検討してきた。

何故wattOS R9 Microwattなのか

次のような特徴から、1年ほど前に白羽の矢を立てたのが2015年5月リリースのwattOS R9 Microwattエディション。

USA産で、2014年4月リリースのUbuntu 14.04 LTS Trustyがベース
i386なハードウェアにも対応
Microwattエディションではi3 window managerという軽量なタイル型ウィンドウマネージャーを採用
ロングタームなライフサイクルで、かつ、ローリングリリースのためアップグレードに気を取られない
Ubuntuでは公式及びPPAに大量のパッケージが存在
でも日本語化は自分でしよう！
Ubuntuは経験済だがタイル型ウィンドウマネージャーは未経験で、学習コストが読めない

対して、次点としたMageia 5の特徴は次のとおり。当初はこれにしようかと思っていた。

フランス産の独立系Linuxから2014年6月リリース
i586なハードウェアにも対応
カスタムインストールが可能で、Xの最小構成を選択すれば、自動的にIceWMという軽量なスタック型ウィンドウマネージャーで環境構築
ライフサイクルは相対的に短めで、かつ、非ローリングリリース
パッケージ数は非公式も含めて相対的に少なめだが、何故か音楽制作系のパッケージはそこそこ充実
日本語化はちょこっとだけだから自分でしよう！
フォーク元の旧Mandriva LinuxでIceWMを経験済で、学習コストが低そう

一般的なLinuxは、決して軽量ではない。Linuxでは、概して機能やルック&フィールとのトレードオフで、デスクトップ環境や様々な基本的サービスの削除、あるいは軽量なものへの代替が可能に過ぎない。何だったらカーネルでさえ差し替えられる。これらはWindowsでは不可能なことだから、軽量Linuxが存在する。

しかし、X.OrgのSiSグラフィックスドライバーであるxf86-video-sis（Ubuntuパッケージはxserver-xorg-video-sis）にクリティカルなバグがあるらしく、乗換えを見送っていた。

X.OrgのSiSグラフィックスドライバーにバグ

2012年10月リリースのUbuntu 12.10 Quantalでバグが発覚。具体的には、X.Org Serverの新しいバージョンから、2DアクセラレーションのAPIの一つであるXAAが廃止された。SiSのGPUとしては、だったらEXAという別のAPIを利用したい。しかし、X.OrgのSiSグラフィックスドライバーが適切にEXAに対応していなかった模様（詳しくはBug #1066464参照）。

これはUbuntu 12.10以降のバージョン、つまり14.04にも当てはまった。ただ、xorg.confで次のように2Dアクセラレーションを切れば、バグを回避可能。しかしこの場合、ただでさえ非力な我がSiS 315の描画性能が目も当てられない。

Section "Device"
    Identifier "Configured Video Device"
    Option "NoAccel" "true"
EndSection

また、X.orgのxf86-video-vesa（Ubuntuパッケージはxserver-xorg-video-vesa）という汎用グラフィックスドライバーで代替する方法もある。しかしこの場合、10年物の我がVA液晶モニターのWXGA 15:9（1280x768）へドットバイドットで表示できず、ぼやけたりにじんだりする模様（上手くいったとの報告もあるが、VESAにそんなグラフィックスモードあった？）。それに、前段同様、2Dアクセラレーションも効かないはず。

これらの理由で乗換えを見送っていた。ユーザーの多いUbuntuでダメだったら、他のディストリビューションでも絶望的だし。

知らぬ間にバグがフィックス

ところが、X.Orgは2015年8月にこのバグをフィックス（解消）させていた。次のような簡素なコメントを添えて。

Remove upload / download EXA hooks

Support based on something other than libc memcpy was never added, so these functions did not improve upon software fallback at all.

先月このブログで記事を書きながら気付いた。見逃していたのではなく諦めていた。AGPの空きスロットへ挿すべく、nVIDIA GeForce FX 5500のファンレスな激安グラフィックボードをゲットしていたほどに。ただ、試しに挿すと電力不足のためか、冷却不足のためか（いずれも弱いことで知られているPC）、はたまた別の問題でか長時間運用時にまれにOSが落ちたため、できれば挿したくなかった。

でも、これで挿さずともwattOS R9 Microwattをインストールできるようになった模様。ところで何故にこのPCを廃棄しないかというと、そんなのSiSお嬢さんだからに決まっているじゃないか！

EPSON NJ2150のOSをアップグレード

2016-06-26T23:47:10+09:00

Windows Vistaから7へアップグレード

EPSON Endeavor NJ2150（詳細はPDF）という我がノートPCは、2008年11月に発売が開始され、7年以上が経過したPC。OSはWindows Vista Ulutimate 32ビット。しかし、Vistaのメインストリームサポートは確かに2012年4月10日に終了したが、延長サポートが終了する2017年4月11日まで日はあるのに、Google Chromeをはじめ今やデファクトスタンダードと化したChromium系ウェブブラウザーが利用できなくなった。他のソフトも追随気味。だからWindows 7 Professional 64ビットにアップグレードすることにした。Windows 10のご時世に、メインストリームサポートが2015年1月14日に終了したWindows 7を選択するのには理由がある。

メモリー不足で更にストレージをSSDへ換装

このノートPCが積めるメモリーの上限はDDR2-667（PC2-5300）の2GBx2スロットの計4GBで、既に上限まで積んでいる。しかし、Windows 8以降で4GBではやや苦しいからだ。詰んでいる。Windows 7ですらメモリーが4GBでは苦しいかも知れない。だから、メモリーがスワップした場合でも可能な限り速度を低下させないため、ストレージをHDDからSSDへ換装した。

また、Bluetooth接続のために、併せて内蔵Wi-FiをIntel Wireless WiFi Link 4965AGN（詳細はPDF）からBluetoothと一体型のものに換装しようとしたが、PCIe Mini Cardにソソる製品がなくて見送った。なお、その他のスペックは、CPUがIntel Core 2 Duo P8600で、 TFT液晶画面のサイズが15.4型WXGA（1280x800）。

Windows 7をクリーンインストール

苦労してプロダクトキー付きインストールメディアを入手し、換装したSSDへクリーンインストール。Windows 7が起動したら、念のためオンライン認証用に、インターネットオプションの詳細設定のタブでSSLのチェックボックスをすべて外し、TLSのチェックボックスをすべて入れた。次に、コマンドプロンプトを管理者として実行し、プロダクトキーを適用した（remから始まる行はコメントなので不要）。

rem プロダクトキーをクリーンアップ
slmgr /upk
rem 新しいプロダクトキーを適用
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
rem ここで初めてインターネットへ接続
slmgr /ato
rem プロダクトキーがオンラインで認証

しかしここでよく見たら、入手したメディアがService Pack 1（SP1）ではないことに気付いた。がっかり。しかも、デバイスドライバーのいくつかがまともに当たっていない。Microsoft Updateよりも何よりもまずこれらを当てて、SP1をインストールしなければ。

SIS Mirage 3+のグラフィックスドライバー

SiSお嬢さんには一番苦労した。NJ2510のチップセットはSiS M672FXという聞いたことのないもので、その統合グラフィックス（IGP）はMirage 3+という激レアなもの。IGPのベンダーIDは1039で、デバイスIDは6351。

まずはMozilla Firefoxをインストール。次にMozilla FirefoxからMicrosoft Updateカタログ（MUC）でSiS Mirage 3+ Driverを検索し、ヒットしたSilicon Integrated Systems Corp. - Display - SiS Mirage 3 GraphicsというAMD64用のグラフィックスドライバーをダウンロード。これを解凍し、ドライバーの更新で適用したところ、動作がやや不安定になり、ほどなく画面が固まった。失敗。この問題の解消方法には2種類ある模様。

SiSの公式サイトで配布しているSiS UniVGA3 Graphics Driver（R529_Logo.zip）をインストール
エプソンの公式サイトで配布しているNJ2150又はNP12用ビデオドライバーをインストール

MUCのドライバーを含め、3つとも中身をデバイスIDの6351でgrepすると、セットアップ情報ファイル（拡張子.INF）等がヒット。バージョンは7.14.10.5290で同じ。各DLL・INF・CATファイルのタイムスタンプは微妙に異なるが、ハッシュ値は同じ。違いはMUCのドライバーだけにインストーラがない、つまりSiS VGA Utilitiesがインストールされないこと。とりあえず1.の方法を選択したが、現時点で画面が固まる問題は生じていない。

なお、当初はOSをLinuxへ変更することも考えたが、LinuxではX.Org向けSiS用グラフィックスドライバーの出来がイマイチで、IGPがその性能を十分に発揮できない。ただでさえ華奢なSiSお嬢さんの性能にもかかわらず、だ。Linuxへの変更をシミュレートしたとき、2020年1月15日（Windows 7の延長サポート終了日）までこの激レアなIGPを引っ張っていく道程が見えなかったため諦めた。ただ、今確認したらX.Orgのxf86-video-sisのリポジトリーでは、ビルドしてみないと何とも言えないが、メンテナンスが継続している模様。

リコーのメモリーカードコントローラーのデバイスドライバー

不明なデバイスが2つあるが、一つはベンダーIDが1180でデバイスIDが0592で、もう一つはベンダーIDが1180でデバイスIDが0843。前者がRicoh Memory Stick Host Controllerで、後者がRicoh SD/MMC Host Controllerというメモリーカードコントローラーの模様。これらにデバイスドライバーを当てるのは簡単。

MUCでRicoh Memory Stick Host Controllerを検索し、ヒットしたRicoh Company - Storage - Ricoh Memory Stick Host ControllerというWindows 7以降用のCAB形式のファイルをダウンロード
続けてRicoh SD/MMC Host Controllerを検索し、ヒットしたRicoh Company - Storage - Ricoh SD/MMC Host ControllerというWindows 7以降用のCAB形式のファイルをダウンロード
任意の場所にRicohというフォルダーを作成し、更にその中に1及び2のフォルダーを作成
3.の1のフォルダーには1.のCAB形式のファイルを解凍
3.の2のフォルダーには2.のCAB形式のファイルを解凍
デバイスマネージャーで不明なデバイスをダブルクリック、表示されたプロパティ画面のドライバータブでドライバーの更新をクリックし、コンピューターを参照してドライバーを検索で3.のRicohフォルダーを指定すれば、自動的に最適なデバイスドライバーが適用
もう一つの不明なデバイスにも6.を実行

事前に3.のRicohフォルダーをデバイスIDの0592及び0843でgrepすると、セットアップ情報ファイル等がヒットすることを確認済。ただし、適用後にテストしていないからホントに当たっているかは不明。

Realtekのオーディオドライバー

セットアップでオーディオドライバー（サウンドドライバー）は当たっているのだが、デフォルトフォーマットのビット深度・サンプリングレートの上限が16ビット・44100Mhzのトンデモ仕様。ベンダーIDは10ECでデバイスIDは0660。Realtek ALC660というオーディオコントローラーの模様。蟹のオーディオドライバーを更新するのは簡単。

MUCでRealtek High Definition Audioを検索し、ヒットしたRealtek Semiconductor Corp. - Audio Device, Other hardware - Realtek High Definition AudioというWindows 7用でAMD64用のCAB形式のファイルをダウンロード
任意の場所にRealtekというフォルダーを作成
2.のフォルダーに1.のCAB形式のファイルを解凍
デバイスマネージャーでRealtek High Definition Audioをダブルクリック、表示されなプロパティ画面のドライバータブでドライバーの更新をクリックし、コンピューターを参照してドライバーを検索で3.のフォルダーを指定すれば、自動的に最適なデバイスドライバーが適用

事前に2.のRealtekフォルダーをデバイスIDの0660でgrepすると、セットアップ情報ファイル等がヒットすることを確認済。これでデフォルトフォーマットに24ビット・48000Mhzを選択できるようになった。後述のSP1適用後のMicrosoft Update終了時にASIO4ALLとTracktion 4 Free、PreSonus Studio One 3 Primeでテストしたが、DSP値が持続的に跳ね上がり、ノイズが乗った。現時点で再現性がないため原因不明。

Windows 7 Service Pack 1の適用

これでようやくSP1が適用できる。MUCでWindows 7 Service Pack 1を検索し、ヒットしたx64 ベースシステム用 Windows 7 Service Pack 1 (KB976932)をダウンロードしてインストールするだけ。実はもう一つ当たっていないデバイスドライバーがあり、解決できなかったのだが、SP1にしたらこの問題は解消されていた。グラフィックスドライバーを除く前述のデバイスドライバーのいくつかも、もしかしたらSP1の適用で問題が解消されるのかも知れない。

Windws Vistaを振り返る

描画処理の性能だけ見れば、SiS Mirage 3+は決して優れたIGPではない（だがそれがいい）。にもかかわらず、それなりに動作していたWindows Vistaはホント過小評価されていると思う。びすたんは確かに出だしでやや躓いたが、その後すくすくと成長した。だからまったく不満はなく、その前のWindows XPよりむしろ気に入っていた。でもVistaから変更せざるを得なくなり、ちょこっと寂しい。

なぜブログで情報発信するのか

2016-06-25T14:03:37+09:00

Twitterを退会した

Twitterでは情報が玉石混交過ぎてウザいと感じてしまう。例えば、玉ではなく石寄りの情報をまことしやかに拡散されると困ってしまう。しかも拡散する人はそれを正義だと思い込んでいるからウンザリする。かと言ってそれにツッコんだ場合、奇異な正義を振りかざして更に声高になる危険性すらある。しかも拡散していた石寄りの情報が悲劇を招いたとしても、自分の振舞いは棚に上げ、今度はその悲劇をダシに別のトコへ奇異な正義を振りかざし始める。石が石を呼び、石が石を生む。ホント度し難いスパイラル。だから知り合いとのDMのためだけに使っていた。しかしDMはTwitter固有の機能ではないので、6年くらい入会していたが、ついに退会した。

Instagramを退会させられた

写真・動画を共有するほど撮る習慣がないから、発信のしようがない。よしんば撮ったとしても、他人とか写り込んでいるときに肖像権のからみで編集するが、そのデメリットやリスクを考えると積極的になれない。だからInstagramではROM専状態だった。過去形なのは、アップロードはほとんどしていない、コメントはほとんど書き込んでいないのに垢BANされたから。いろいろやったが垢は復活しなかった。むしろそういう使い方だと垢BANされるのが情報発信・公開型SNSなのか。

Facebookは知り合いとのつながり用

Instagramは垢BANされたが、ほぼ同様の状態のFacebookは垢BANされていない。でも実名での発信で知り合いにすぐ見つかるのはちょっと、という情報もある。だから知り合いへの告知やメッセンジャーのためだけに使っている。

だからブログが一番いい

知り合いにすぐ見つからず、誰に読ませるでもなく、書きたいときに書いて、後で備忘録的に読み直せるブログが精神的に一番楽。それにウェブサービスとしてのブログを除き、原因不明の垢BANをされる心配もない。もちろん誰に読まれても問題にならないような配慮は必要。

情報発信で心掛けること

今はインターネットでググれば簡単に情報にたどり着く。しかしこの行為で得られるものは、単なる知識の場合が多い。社会で必要とされているのはその知識をどう活かすか、どう実践するか、つまりは知恵。ググって知識を得て、それを披露しても、デキるような雰囲気は出せるだろうが、実践が伴っていなければ、己でもって実現可能でなければ社会的にはあまり役に立たない。だから誰かが読む可能性がある限り、なるべく実践で得た知恵を発信するよう心掛けたい。

静的サイトジェネレーターを試してみた

2016-05-08T11:02:14+09:00

静的サイトジェネレーターの長所

前にサーバーを引っ越してから、CMSを静的サイトジェネレーター（SSG）に替えてれば引っ越すの簡単だったんじゃね？と思えてきた。ローカルにファイルが残るから引っ越すとなったらデプロイ先を変えるだけだし、仮にコメント機能を付けたくなったらDisqus等で遜色なくできるし。ローカルが吹っ飛んだらアウトだけど、WinSCPかLinuxのファイルマネージャーを使ってWebDAVでBoxというクラウドストレージへバックアップしておけばいいし。という長所を踏まえつつ、次のとおりSSGの要件定義から始めてみた。

SSGの要件を定義してみた

要件をいろいろ考えた結果、シンプルで簡単そうなSSGが合ってると思った。なお「シンプルで簡単」とは具体的には以下のイメージ。

Linux若しくはWindows上のMSYS2又はMinGW（とGit for Windows）でサクッとインストールできる。
クロスプラットフォームで、運用するPCなど環境をコロコロ変えても持続可能である。例えばPerl、PHP、Python、Ruby、Lua、Bashあたりに依存するアプリとか。
ミニマムなこと。パワフルな機能、豊富なプラグイン、行き届いた管理画面などは要らない。
スクリプトに手を加えたり、新たなスクリプトを書くことが前提でない。
フラットファイルからHTMLを生成し、そのファイルもマークダウンなどわかりやすい記法で書ける。
デフォルトのテンプレートがそこそこ整っている。一からテンプレートを書く気はない。かと言って重たいテンプレートは嫌だ。
ウェブページ間のリンクを自動生成してくれる。
フィードかサイトマップファイルを自動生成してくれる。

mysite.pyが凄くイイと思う

そうして、以下の順番で8種類のSSGをサクッと試してみた。時間が惜しかったので、しっかり確認しておらず、また、PerlやRubyまで至らなかった。

zodiac: AWK製で、git cloneからインストール。デフォルトのテンプレートがショボく、それをカスタマイズするのが楽じゃなさそうだから候補外。
Jenny: Bash（一部AWK）製で、git cloneからインストール。フィードかサイトマップを自動生成してくれなさそうだったから候補外。そのためのスクリプトくらい自分で書けってことなんだろうな。
Luapress: Lua製。MSYS2上でLuaRocksからインストールしようとしたところ、Discount（マークダウンのライブラリー）のdevelファイルを用意しなければならず、サクッとしてないから候補外。
Carew: PHP製で、Composerからインストール。デフォルトのテンプレートが一部粗雑で、それに手を加えるのが楽じゃなさそうだから候補外。
Sculpin: PHP製で、Composerからインストール。凄くイイ。でもPHPってバージョンアップで動かなくなったりすることがあるっぽいから、Python製でも試しとくか。
MkDocs: 冒頭の画像。Python製で、pipからインストール。ミニマムでなく本格的過ぎるので候補外。
PyBlosxom: Python製で、pipからインストール。元ファイルの更新日からウェブページの更新日を取得するので、誤字脱字を修正するたびにtouchコマンドで更新日を直さなければならないのが面倒そうなので候補外。
makesite.py: Python製で、git cloneからインストール。なんだこれじゃん！

クラウドストレージの弱点

あとはBoxにバックアップする環境を整えればOK。しかし過去、WebDAVで4sharedにいろんなファイルを放り込んでいてトラブル発生。ちょこっとログインしなかったらだと思うが、アカウントが消され、ファイルも消された。ローカル側で削除してしまって4sharedにしかなかった重要なファイルがあったことに後で気付き、呆然とした。クラウドストレージの選定は慎重に。

Windowsの游書体とウェブデザイン

2016-05-07T14:28:43+09:00

Windowsの游書体はタブレット向き？

OSはWindowsでのお話。デスクトップPCでWindowsの游書体を適用したとき、外付け液晶モニター上では「デザインは優れてるけどちょこっと細いなぁ」というのが第一印象だった。しかし、2in1タブレットPCで適用したとき、ディスプレイ上では「めちゃめちゃ見やすいなぁ」と印象が変わった。特にウェブブラウザーでのサンセリフ体のYu Gothic UI。Windowsの游書体は、タブレットのような画素ピッチの狭いディスプレイでの表示を考慮されて最適化されてるのか？とまで思った。イマドキだなぁ。

画素とは

ちなみに画素（ピクセル）とは、ディスプレイを構成する一つ一つの点を指し、画素ピッチとは、画素の間隔・距離を指す。画素ピッチが広いとフォントも大きく表示されるが、画素ピッチが狭いとフォントも小さく表示される。言い換えれば、画素ピッチが広いとフォントは粗く表示されるが、画素ピッチが狭いとフォントは細かく、つまりは高詳細に表示される。大雑把だが、横1920ピクセルのモニターに横一列に100文字表示させたとき、24.5インチ（横幅544mm≒1920ピクセル×画素ピッチ0.283mm）と11.6インチ（横幅256mm≒1920ピクセル×画素ピッチ0.134mm）の液晶モニターでは見え方にどのような差異が生じるかを想像すれば簡単だ。

高精細が見やすいとは限らない

イマドキのガジェットのディスプレイは画素ピッチが相対的に狭くて高精細な場合が多い。しかし、ウェブページで最も多く利用されているであろう（Google Chromeで初期設定の）16ピクセル程度の文字だと小さく表示されて困る。ただこのとき、画数の多い（概ね8画以上の）漢字はやや細いくらいのフォントのほうが潰れずに表示されるため見やすいのかも知れない。日本語ネイティブな人は斜め読みするときまず漢字を目で追っていく傾向にあるから、これ、重要。

CSSでのフォント指定でお願い

以上のとおり、タブレットPCのClearTypeに対応したウェブブラウザーで、フォントファミリーのサンセリフ体ではYu Gothic UIを表示するよう設定してみた。しかし、いざウェブページを表示すると、Yu Gothic UIで表示されないことがしばしば。理由は、そのウェブサイトが、CSSで例えばMeiryo UIで表示するようガチガチにフォントを指定しているから。ごく稀だがCJKのウェブフォントを表示させてくるウェブサイトすら存在する。ウェブブラウザーやディスプレイの表示能力、更には己の眼の能力等を考慮し、せっかくウェブブラウザーでフォントを設定していても、華麗にスルーしてくれる。これ、ちょこっと困る。画数の少ない欧文書体は構わないとして漢字、つまりは和文のフォントくらいは設定したものをストレートに使わせてもらえるほうが助かる。

当サイトのCSSの例

当サイトでは次のとおり欧文書体のみ指定。使用テーマのデフォのフォント指定に対し、林檎向けにHelvetica NeueとHelveticaという欧文書体を挿入しだだけ。ちなみにOpen SansとはDroid Sansから派生したオープンソースの欧文書体で、ウェブフォントで提供されている。なおOpen Sansもやや細めなので、ウェブブラウザーでサンセリフ体に太めの和文フォントが指定されている場合の親和性が気にはなっている。Helvetica Neueもやや細め。

html, body, h1, h2, h3, h4, h5, h6, div, p, address, blockquote, dt, dd, li, caption, th, td, input, select, option, label, textarea, object, embed, iframe {
  font-family: 'Open Sans', 'Helvetica Neue', 'Helvetica', 'Arial', sans-serif;
}
textarea, pre, code, kbd, samp, var, tt {
  font-family: monospace;
}

デスクトップPCのフォントは？

デスクトップPCにはMeiryo UIを適用していたが、実はRobotoJ（具体的にはRobotoJAA Regular OTF）に乗り換えようかと考えていた。メイリオはあんなにエレガントなデザインなのに、なぜMeiryo UIはデザイン的にやや落ちるんだろう。見やすいのは確かだけど。

国内無料サーバーへ引っ越した

2016-05-05T15:34:40+09:00

海外無料サーバーは重かった

海外無料サーバーで本サイトの運用を開始したが、接続が遅かったり、不安定だったりすることがままあった。そこでPHP、mod_rewrite等を提供している国内無料サーバーへ引っ越すことにした。NibbleblogはRDBMSを使用しない。だから、移転元の海外無料サーバーからFilezillaでファイル一式をFTPダウンロードし、それらを移転先の国内無料サーバーへFilezillaでFTPアップロードするだけの簡単なお仕事。

Nibbleblogは移転も簡単

念のため、Nibbleblogの/content/private/config.xmlという設定ファイルの「ブログのアドレス (URL)」は移転先のURLに編集してからアップロードした。注意点はたったこれだけ。

<!-- 編集前 -->
<url type="string">http://移転前のブログURL/</url>
<!-- 編集後 -->
<url type="string">http://移転後のブログURL/</url>

あと、.htaccessも一部編集したが、これはNibbleblogが必要とするのではなく、サーバー環境に合わせるために必要な作業。また、海外無料サーバーにはなかった広告表示が、国内無料サーバーでは表示されるようになったが、テーマのレイアウトには影響しなかったのも引越作業を簡単にさせてくれた。

結論

簡単に移転できるNibbleblogは良くできたフラットファイルCMSなのかも知れない。日本でのユーザー数はおそらく数十人くらいだろうけど。

レスポンシブデザインっぽくしてみた

2016-05-04T16:31:03+09:00

Bootstrapテーマなんて使わずに対応

レスポンシブデザインなんて知るかコノヤローと思っていたが、モバイルフレンドリーなウェブデザインがSEO的に良いらしく、最近レスポンシブデザインが増えてきている。一方、Nibbleblogの初期テーマの一つであるGoogleSimpleを現在利用しているが、このテーマはレスポンシブデザインに完全には対応していない。しかし、今更このテーマからBootstrapテーマ系のテーマへ変更するつもりはない。かと言って、このテーマをゴリゴリに弄るのは面倒。そこで、このテーマのCSSだけ弄って、なんちゃってレスポンシブデザインにしてみた。

コードの修正内容

元の/themes/google_simple/css/main.cssは以下のとおりで、CSSでサイドバーを右に回り込ませている。

/*
========================================================================
BLOG :: Main
========================================================================
*/

#main {
    margin: 0 auto;
    overflow: auto;
}

#left {
    font-size: 1.32em;
    margin-right: 260px;
}

#sidebar {
    float: right;
    margin-right: 10px;
    width: 220px;
    font-size: 1.2em;
}

これを、以下のとおり画面表示幅が800px以下になったとき、サイドバーが右に回り込まないようにするとともに、メインコンテンツの位置とサイドバーの位置関係をcolumn-reverseで上下反転させただけ。いわゆるブレークポイントを800pxにしたのは、所有しているドコモ dtab d-01Gの画面が800×1280ピクセルだったから。つまり、俺フレンドリーなウェブデザイン。

/*
========================================================================
BLOG :: Main
========================================================================
*/

#main {
    margin: 0 auto;
    overflow: auto;
}

#left {
    font-size: 1.32em;
}

#sidebar {
    font-size: 1.2em;
}

/* 画面表示幅が801px以上の場合の挙動 */
@media all and (min-width: 801px) {
#left {
    margin-right: 260px;
}
#sidebar {
    float: right;
    margin-right: 10px;
    width: 220px;
}
}

/* 画面表示幅が800px以下の場合の挙動 */
@media all and (max-width: 800px) {
#main {
    display: flex;
    flex-direction: column-reverse;
}
}

備考

「ヘッダーを画像に置換してみた」で加えたmin-widthプロパティは、あらかじめすべて削除したので念のため。

Debian norootをインストールしてみた

2016-04-30T16:42:02+09:00

AndroidにDebianをインスコ

YouTubeやGYAO!等の動画視聴くらいにしか利用しなくなったドコモ dtab d-01G（Android 4.4.4 KitKat）に、Debian norootというLinuxデスクトップ環境をインストールしてみた。インストール自体はGoogle Playストアから行うだけなので簡単。しかし、実際にDebianを起動すると初期設定をしようにも画面が小さくて操作しづらい。そこで、同じローカルLAN内にいるWindows PCから（Debian PCからでも良かったのだが）VNCでDebianに接続し、リモートデスクトップで運用することにした。

VNC環境の構築

d-01Gはroot化していない。Debian noroot（Debian 8 Jessie + Xfce）にインストールするVNCサーバーはTightVNCで、Windows Vista PCにインストールするVNCビューアーはUltraVNC（TightVNCやTigerVNCでも動作）。まず、d-01GのDebian norootでVNCの準備。がんばってタッチパネルでマウスカーソルを動かしてデスクトップのRoot Terminalからターミナルエミュレーターのxtermを起動したら、USB OTGのキーボードから以下のとおりコマンドし、文字化けしないようロケールを一時的に英語に指定後、リポジトリーを修正。

# export LANG=C LC_ALL=C LANGUAGE=en
# nano /etc/apt/sources.list

そして、このファイルの内容を以下のとおり修正。

deb http://http.debian.org/debian jessie contrib main non-free
#deb-src http://http.debian.org/debian jessie main contrib

deb http://security.debian.org/ jessie/updates contrib main non-free
#deb-src http://security.debian.org/ jessie/updates main contrib

deb http://http.debian.org/debian jessie-updates main contrib non-free
#deb-src http://http.debian.org/debian jessie-updates main contrib

deb http://http.debian.org/debian jessie-backports-sloppy contrib main non-free
#deb-src http://http.debian.org/debian jessie-backports-sloppy main contrib

deb http://http.debian.org/debian jessie-backports contrib main non-free
#deb-src http://http.debian.org/debian jessie-backports contrib main

deb http://www.deb-multimedia.org/ jessie main non-free
deb http://www.deb-multimedia.org/ jessie-backports main

次に、テキストエディターのnanoを上書き保存後に閉じたら、以下のとおりコマンド。

# apt update && apt upgrade && apt-get clean

必要に応じyで進む。次に、必要なパッケージをインストールし、ロケールを修正。

# apt install locales debian-keyring deb-multimedia-keyring xfonts-intl-japanese fonts-takao tightvncserver && apt-get clean
# nano /etc/locale.gen

インストールでは必要に応じyで進む。/etc/locale.genではen_US.UTF-8 UTF-8とja_JP.UTF-8 UTF-8のコメントアウト（先頭の#）を削除して外し、nanoを上書き保存後に閉じる。次に、以下のとおりコマンドし、ロケールを反映後、システム環境変数を設定。

# locale-gen
# nano /proot.sh

ここでは、export TZから始まる行を以下のとおりコメントアウト（行の先頭に#を追加）し、その直下に4行追加。LC_ALLが空白だと何故か英語表記になり、しかもPerlに怒られる。

#export TZ="`getprop persist.sys.timezone`"
export TZ="Asia/Tokyo"
export LANG="ja_JP.UTF-8"
export LC_ALL="ja_JP.UTF-8"
export LANGUAGE="ja"

nanoを上書き保存後に閉じたら、exitとコマンドしてRoot Terminalを終了。次に、デスクトップのTerminalからxtermを起動したら、以下のとおりコマンドし、文字化けしないようロケールを一時的に英語に指定後、ユーザーフォルダーに遷移し（u0_a192というユーザー名は一例）、~/.Xresourcesを新規作成。

$ export LANG=C LC_ALL=C LANGUAGE=en
$ cd /home/u0_a192
$ touch .Xresources
$ nano .Xresources

~/.Xresourcesの内容は以下のとおりで、これでxtermの日本語の文字化けが解消する（Xterm - ArchWikiより）。

xterm*faceName: Droid Sans Mono
xterm*faceNameDoublesize: TakaoGothic
xterm*faceSize: 10

nanoを上書き保存後に閉じたら、~/.Xresourcesをリロードし、xtermのロケールを日本語に戻した後、一度TightVNCサーバーを起動する。途中、パスワードの新規設定を尋ねられるので、設定後、すぐにTightVNCサーバーを閉じ、VNCサーバーが呼び出すXの起動スクリプト（~/.vnc/xstartup）を変更する。

$ xrdb .Xresources
$ export LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 LANGUAGE=ja
$ vncserver :1
$ vncserver -kill :1
$ cd .vnc
$ nano xstartup

xstartupは最後の行を以下のとおりコメントアウト（行の先頭に#を追加）し、その直下に4行追加（xfce - How to run xfce4 on debian on VNC startup? - Stack Overflowより）。DebianとXfceには慣れ親しんだつもりだったが、これは知らなんだ。

#/etc/X11/Xsession
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
startxfce4 &
xrdb $HOME/.Xresources

いざVNC接続

nanoを上書き保存後に閉じたら、以下のとおりコマンドしてローカルIPアドレスを確認後、再度TightVNCサーバーを起動（1280x800は画面サイズの一例）。

$ ip -4 addr
$ vncserver :1 -geometry 1280x800 -depth 24

wlan0のinetに続く数字がd-01GのローカルIPアドレス（仮に192.168.XXX.XXXとする）。今度はWindows側。UltraVNCをインストールしたら、UltraVNC Viewerを起動し、Auto serect best settingsにチェックを入れたら、Computer:の入力欄に192.168.XXX.XXX:1と入力し、Connectボタンを押下。途中、VNCサーバーのパスワードを求められるので、先ほど新規設定したパスワードを入力し、Log onボタンを押下。

冒頭の画面はVNC経由でsynapticを起動したところ。synapticはデスクトップ上のアイコンからインストールできるが、インストールでコケるようだったら、コマンド中の-yを--force-yesにしてやればいい。以上、初めてのVNCにしては上手くいったので、これからDebian norootの用途を考えていきたい。

XRDPは断念

最初はDebian norootでXRDPを起動し、Windows側からリモートデスクトップ接続で運用するつもりだった。しかし、XRDPの設定ファイルをどう弄ってもWindowsから接続できなかったので、諦めた。

そもそもVNCを利用しない方法

前述のとおり、VNCで運用することにしたのは、d-01Gの画面が小さかったから。だったら最初からAmazon Fire TVボックスに導入すればよかった。これには外付け液晶モニターをHDMI接続させているし、Bluetoothキーボード・マウスをペアリングさせているしで、仮にDebian norootをインストールしてもVNCを設定する手間は不要だった。ちなみにこの場合、導入はGoogle PlayストアからではなくSourceForgeから行う（まだ試してないけど）。

JSON-LDを追加してみた

2016-04-29T16:13:40+09:00

構造化データの文法の一つ、JSON-LD

フィードやトラックバックが流行ったころも似たようなことが言われていた気がするが、最近はセマンティック・ウェブな世の中らしい。そこで、Nibbleblogの初期テーマの一つであるGoogleSimpleの以下の2つのスクリプトを次のとおり弄って、SEO的に期待されているJSON-LDを追加した。

/themes/google_simple/views/blog/includes/post.bit（記事一覧表示用スクリプト）
/themes/google_simple/views/post/includes/post.bit（個別記事表示用スクリプト）

コードの修正内容

2つのスクリプトへ追加する内容は同じ。

<script type="application/ld+json" charset="UTF-8">
{
  "@context": "http://schema.org",
  "@type": "BlogPosting",
  "@id": "<?php echo htmlspecialchars(Post::permalink(true), ENT_COMPAT, 'UTF-8') ?>",
  "url": "<?php echo htmlspecialchars(Post::permalink(true), ENT_COMPAT, 'UTF-8') ?>",
  "headline": "<?php echo htmlspecialchars(Post::title(), ENT_COMPAT, 'UTF-8') ?>",
  "description": "<?php echo htmlspecialchars(Post::description(), ENT_COMPAT, 'UTF-8') ?>",
  "articleSection": "<?php echo htmlspecialchars(Post::category(), ENT_COMPAT, 'UTF-8') ?>",
  "datePublished": "<?php echo htmlspecialchars(Post::published(), ENT_COMPAT, 'UTF-8') ?>",
  "isPartOf": {
    "@type": "Blog",
    "@id": "<?php echo htmlspecialchars(Blog::url(false), ENT_COMPAT, 'UTF-8') ?>",
    "url": "<?php echo htmlspecialchars(Blog::url(false), ENT_COMPAT, 'UTF-8') ?>",
    "name": "<?php echo htmlspecialchars(Blog::name(), ENT_COMPAT, 'UTF-8') ?>",
    "description": "<?php echo htmlspecialchars(Blog::slogan(), ENT_COMPAT, 'UTF-8') ?>"
  }
}
</script>

設定->地域->タイムスタンプ書式->カスタムで%Y-%m-%dと設定したら、上のコードを</header>の直下に追加するだけの簡単なお仕事。

構造化データの文法の一つ、RDF

これってトラックバックが流行っていたころ、その自動検知用の構造化データ（メタデータ）をRDF形式で以下のようにHTMLへ埋め込んでいたのと情報的にあまり変わらない気がする。メタデータの埋め込みといった手法は手を変え品を変え出てくるけど、長続きしないのかも。

<!--
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
<rdf:Description
  rdf:about="記事のパーマリンク"
  dc:identifier="記事のパーマリンク"
  dc:title="記事の題名"
  dc:description="記事の要約"
  dc:creator="記事の著者"
  dc:date="記事の発行年月日・時間"
  trackback:ping="記事のトラックバックURL" />
</rdf:RDF>
-->

海外無料サーバーはフラットファイルCMSもキツい

2016-03-21T16:35:39+09:00

画像等のキャッシュで速度を稼ぐ

この投稿で十数ページ目になるのだが、このNibbleblogというPHPで動作するフラットファイルCMSであっても、ここ海外無料サーバーで応答速度のパフォーマンスが低下してきている。しかし、かつてここでフラットファイルDBで利用していたBlognPlus（PHP5で動作）というCMSのときもそうだったので、驚きはない。しかしページ遷移くらい何とかしようと、以下のとおり.htaccessを弄り、クライアントのウェブブラウザ―に画像、CSS、JavaScript等のファイルをキャッシュさせることにした。

コードの修正内容

Cache-ControlとExpiresでは僅かに意味が異なるので、ウェブブラウザー等の対応状況を考慮し、念のため両方設定しておいた。

<IfModule mod_headers.c>
# 画像、CSS、JavaScript等のキャッシュのみ最大寿命を秒で30日と設定
<filesMatch "\/(|[^/]*\?.*)$">
  Header set Cache-Control: "no-cache"
</filesMatch>
<filesMatch "\.(s?html?|php|xml|txt)$">
  Header set Cache-Control: "no-cache"
</filesMatch>
<filesMatch "\.(gif|jpe?g|png|ico|css|js|ttf|woff2?)$">
  Header set Cache-Control: "public, max-age=2592000"
</filesMatch>
# 画像、CSS、JavaScript等のキャッシュのみ有効期限を1か月と設定
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault                         "access plus 0 seconds"
  ExpiresByType image/gif                "access plus 1 month"
  ExpiresByType image/jpeg               "access plus 1 month"
  ExpiresByType image/png                "access plus 1 month"
  ExpiresByType image/x-icon             "access plus 1 month"
  ExpiresByType image/vnd.microsoft.icon "access plus 1 month"
  ExpiresByType text/css                 "access plus 1 month"
  ExpiresByType text/javascript          "access plus 1 month"
  ExpiresByType application/javascript   "access plus 1 month"
  ExpiresByType application/x-javascript "access plus 1 month"
  ExpiresByType font/ttf                 "access plus 1 month"
  ExpiresByType application/font-ttf     "access plus 1 month"
  ExpiresByType application/x-font-ttf   "access plus 1 month"
  ExpiresByType font/woff                "access plus 1 month"
  ExpiresByType application/font-woff    "access plus 1 month"
  ExpiresByType application/x-font-woff  "access plus 1 month"
</IfModule>
</IfModule>

ライブラリーのCDN化で速度を稼ぐ

次に、現在利用しているGoogleSimpleというテーマの/htdocs/themes/google_simple/templates/default.bitを弄り、normalize.css及びjQueryライブラリーをCDNから読み込むようにしてみた。我ながら涙ぐましい。

<?php
  // Charset, title, description, keywords, robots, etc
  echo Blog::meta_tags();

  // Include CSS from theme
  // echo Blog::css(array('normalize.css', 'main.css', 'post.css', 'page.css', 'plugins.css', 'rainbow.css'));
  echo '<link rel="stylesheet" type="text/css" href="https://unpkg.com/normalize.css@3.0.3/normalize.css">'.PHP_EOL;
  echo Blog::css(array('main.css', 'post.css', 'page.css', 'plugins.css', 'rainbow.css'));

  // Include Jquery
  // echo Blog::jquery();
  echo '<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.1/jquery.min.js"></script>'.PHP_EOL;

  // Include Javascript from theme
  echo Blog::javascript('rainbow-custom.min.js');

  // Include Favicon, default path: theme/css/img/favicon.ico
  echo Blog::favicon();

  // Plugins for <head></head>
  foreach($plugins as $plugin)
  {
    echo $plugin->blog_head();
  }
?>

Nibbleblogにはキャッシュ機能がないっぽい

せめてCMS側にキャッシュ機能があれば速度をカバーできるのだけど、Nibbleblogはキャッシュせず単純に動的生成しているのかな。でもPHP+MySQLで動作するWordPress及びNucleus CMSというCMSをかつてここで利用していたとき、更に遅かった（特にMySQLが遅かった）からそれに比べればマシか。

ソースコードエディターならGeany

2016-03-20T16:37:32+09:00

Geanyを選択した理由

最近はオープンソースなソースコードエディターと言えばAtom、Brackets、Visual Studio Codeあたりが話題になっている（うちAtom及びVisual Studio Codeはヘビー級なElectronというライブラリーがベース）。しかし、Windows又はLinuxでこのNibbleblog等のコードを弄るくらいなので、これらはいかにも大袈裟。したがって、Geanyというクロスプラットフォームで動作する軽量なソースコードエディターを常用している。

Notepad++とGeanyは似ている

かつてはWindowsではテキストエディターとしてオープンソースなNotepad++を常用していたが、最近はテキストエディターとしてもGeanyを利用している。GeanyとNotepad++は、ともにScintillaというエディター機能を提供するライブラリーがベースとなっている。つまり使い勝手等の一部が同じなので、戸惑うことが比較的少ない。日本語の取扱いが若干苦手なところまでNotepad++にそっくり。また、シンタックスハイライトやプラグインの種類が豊富な点もNotepad++に似ている。

備考

Geanyは厳密にはソースコードエディターではなく、IDE（統合開発環境）らしい。

海外無料サーバーならFilezillaで接続

2016-02-11T16:15:32+09:00

Filezillaの特徴

ここ海外無料サーバーで最も悩ませられるのが速度、そして次は安定性。FTP接続が遅かったり、不安定だったりすることがままある。だからしっかりとしたFTPクライアントを利用しなければならない。そんな中、最終的に選択したのがFilezillaで、その理由は以下のとおり。

Windows及びLinux、つまりクロスプラットフォームに対応
オープンソース
FTPS及びSFTPによるセキュアな転送に対応
GUI
貧弱な海外無料サーバーであっても、がんばって接続してくれる
ローカル及びリモートを表示する2ペイン構造で、かつ、ディレクトリツリーを表示
アップロード及びダウンロードがキュー形式
ユーザー数が多く、開発の継続の期待値が高い

Filezillaを選択した理由

Windows及びLinuxを常用しているため、どちらでも利用できるFTPクライアントでオープンソースとなると、ほぼFilezilla一択になる（他にFireFTPもあるにはあるが、Mozilla Firefoxやその派生ウェブブラウザーのアドオンなので、少し毛色が違う）。プラットフォームごとにFTPクライアントを変えてみたこともあったが、やはり面倒だった。

WinSCPやCyberduckもアリ

Windowsだけで考えれば、オープンソースではWinSCP及びCyberduckも及第点だった。だからWindowsだけで利用するならWinSCP、Windows及びMacで利用するならCyberduckを選択していたかも知れない。ちなみにFFFTPは一部の海外無料サーバーとあまり相性が良くなかった。

meta要素のviewportを追加してみた

2016-02-10T21:31:08+09:00

モバイルフレンドリーに必須なviewport

このNibbleblogはデフォでmeta要素のviewportを生成しない。一部の初期テーマは生成するようだが、現在利用しているGoogleSimpleという初期テーマは生成しない。しかしviewportはSEO的に重要らしい。そこでスクリプトを以下のとおり修正し、デフォで生成するようにしてみた。

コードの修正内容

/admin/kernel/helpers/blog.class.php

//$meta = '<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">'.PHP_EOL;
  $meta = '<meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="rating" content="general">
  <meta name="classification" content="Weblog">'.PHP_EOL;

width=device-width, initial-scale=1と指定するのが鉄板。その意味がわからないなら無暗にカスタマイズしないほうが良いらしい。なお、ついでにmeta要素をいくつか追加しておいたが、習作的なもので、特に意味はない。

OGPの2つのプラグインを修正してみた

2016-01-11T16:58:02+09:00

プラグインのダブルスラッシュ問題

このNibbleblogにはプラグイン機能があり、このうちFacebookのOpen Graphプラグインのog:imageと、Twitter Cardプラグインのtwitter:imageのURLがhttp://www.example.com//themes/テーマ名/css/img/image.pngとダブルスラッシュ（//）が入っておかしなことになっていた。そこで、以下の2つのスクリプトを次のとおり修正した。

/plugins/open_graph/plugin.bit（Open Graphプラグイン）
/plugins/twitter_cards/plugin.bit（Twitter Cardプラグイン）

コードの修正内容

//$og['image'] = $settings['url'].HTML_THEME_IMG.'image.png';
  $og['image'] = preg_replace('/([^:]\/)\//', '$1', $settings['url'].HTML_THEME_IMG.'image.png');

いずれもmeta要素のcontent属性の値となるURLを生成するコードで、修正部分は同じ。PHPのPCRE正規表現を用いて、ダブルスラッシュを普通のスラッシュにpreg_replaceで置換しただけ。しかし正規表現というのは、なぜかいつも顔文字に見えてくる。

動画は普通に投稿できる

2016-01-10T16:19:48+09:00

普通の記事にYouTube動画を貼付

このNibbleblogは、前回利用した固有の動画投稿機能を使わずとも、今回のようにTinyMCEというJavaScript製WYSIWYGエディターのMediaプラグインを利用してYouTubeの動画（今回も前回同様、岡村靖幸『ラブメッセージ』PV）を貼ることができる。パッと見での２つの大きな違いは、文章を添えることができるかどうか。でもそれだけではない。

プライバシー強化モードで貼付したい

今回はプライバシー強化モード（youtube-nocookie.com）のembed動画を貼ったが、前回はNibbleblogが動画IDから自動的にプライバシー強化モードでないembed動画のURLを生成している。ちなみにNibbleblogの動画投稿機能にプライバシー強化モードのembed動画のURLを生成させるようにするには、/admin/kernel/helpers/video.class.phpを以下のとおり変更する。

//$info['embed'] = '<iframe class="youtube_embed" width="'.$width.'" height="'.$height.'" src="https://www.youtube.com/embed/'.$video_id.'?rel=0" frameborder="0" allowfullscreen></iframe>';
  $info['embed'] = '<iframe class="youtube_embed" width="'.$width.'" height="'.$height.'" src="https://www.youtube-nocookie.com/embed/'.$video_id.'?rel=0" frameborder="0" allowfullscreen></iframe>';

あと、TinyMCEのMediaプラグインは多くの動画配信サービスに対応しているようだが、Nibbleblogの動画投稿機能はYouTubeとVimeoのみに対応している。つまりNibbleblogの動画投稿機能のメリットは、YouTubeとVimeoの動画が簡単に貼れるところらしい。なお、動画投稿機能を使わずにこのページに貼った動画コードは以下のとおり。

<div class="video-embed">
  <iframe src="https://www.youtube-nocookie.com/embed/g0Y3icv1QjY?rel=0" frameborder="0" allowfullscreen="allowfullscreen"></iframe>
</div>

動画投稿を『ラブメッセージ』でテストした

2015-12-23T16:11:34+09:00

Debian 8.2 Jessieのメモリ使用量

2015-12-22T23:59:10+09:00

軽量なデスクトップ環境を選びたい

個人的には何にしても軽量なものが好きだ。だからWindowsはあまり好きではない。さて、Debian 7 Wheezy i386で使用しているとても古い自作デスクトップPC（CPUはPentium M 750 Dothan）へDebian 8 Jessie i386をネットインストールしようとしているが、Jessieではインストーラでデスクトップ環境（DE）を多数から選択できる。そこで、このうち軽量そうに思われたDEについて、クリーンインストール・初回起動・ログインから各DEのデフォのターミナルエミュレータを開き、約3分放置後にfreeコマンドを叩いた際、実際にOS全体でどれくらいメモリを食っているのかを調べてみた。

メモリ使用量選手権 on Jessie
順位	デスクトップ環境	メモリ使用量
1	Cinnamon	700MB台
2	MATE	500MB台
3	Xfce	400MB台
4	LXDE	300MB台

その他の比較理由・条件

メモリ使用量だけを比較し、ディスク使用量を比較しなかったのには理由がある。それは当該PCのメモリはDDR2-533 2GBと速度・容量ともに（特にウェブブラウザー使用時に）問題ありまくりだが、それに比べてシリアルATA HDDはまだ幾分かマシだと思われたから。また、一緒に標準システムユーティリティとプリンタサーバはインストールした。一方でWebサーバとSSHサーバはインストールしなかった。いずれも一般的にはインストールされないと思われたため除外したが、個人的にはどうせ後からインストールするんだろうから、条件に含めるべきだったかな。

結局Xfceを選ぶことにした

とりあえずCinnamonは軽量では全然なかったからパス。そうなるとMATEかXfceかLXDEかだけど、これくらいの差だとあとはもう趣味の世界。そこで、これらのうち最も使い慣れているXfceを選択することにした。学習コストはバカにならないからね。しかし4回もクリーンインストールして調べておいて、結局いつものXfceを選択するとは。ただPC構成、ディストリビューション、バージョン、ビルドオプション等によって各DEにおけるメモリ使用量は異なってくるはずだから、今回はたまたまXfceになったとも言えなくもない。

ホントの狙いはTrinityとLXQt

最近はDAW（デジタル・オーディオ・ワークステーション）をはじめとするマルチメディア系アプリケーションを利用する機会がとみに増加した。それらのアプリケーションは決まってQtベースだったりする。しかし、今回調べたDEはすべてGTKベース。ホントはQtベースで軽量と話題のTrinity（TDE）とLXQtを調べたかったのだが、残念ながらいずれのDEもJessieのインストーラの選択肢にはなかった。