地デジ化でチューナー選び DTV-H400S

地デジ化、つまり地上(波)放送のデジタル化というやつだが、七月に入って画面左下に「アナログ放送終了までーー」と巨大なカウントダウンテロップが嫌がらせのように挿入された。(テロップ攻撃、以後「テロ攻撃」)
地デジ化へカウントダウン 残り日数字幕に苦情も http://t.asahi.com/31qe
それに驚き、そしてその見苦しさに耐え切れなくなった者たちが、安価なチューナーに飛びつき、まずはネット販売の在庫が一気に干上がった。 
このテロ攻撃はタイミングとして金曜日だったので、金曜日~土曜日には家電店に並ぶ地デジチューナーも売れ切れが続出していた。

日曜日にPCショップへ行ったとき、B社の地デジチューナーを山のように積み上げ買い占めていく、おそらくは転売屋と思われる薄汚いゴミ人間を目撃してしまった。
店頭販売価格は五~六千円だった。
その後ネットオークションでは、一万数千円くらいまで高騰するのを確信した。
一般市場からは完全に在庫が消えてしまったのに、オークション市場ではあり余る出品が並び続けるという異常事態が続いた。
それは、テロ攻撃から六週間後・アナログ停波から三週間後の今も、混乱の絶頂期から比べれば若干の落ち着きをみせてはいるが、未だ続く在庫不足との駆け引きによるオークション相場が継続中だ。

 

うちのリビングルームでは既にかなり前に大型の液晶テレビへと買い換え、地デジ化も完了していたので、残る各部屋の28型ワイドブラウン管テレビが二台あるのをどうするか検討中だった。
両親の寝室にある一台は、地上放送と衛星放送が観られる環境であればよいということで三波対応デジタルチューナーが第一候補になった。
どうせなら簡易録画機能付きのチューナーにしてみてはどうか?と提案してみたが、必要ないだろうということで却下された。

もう一台は自室にある。
これまで使っていた録画機は D-VHS でアナログチューナーしか内蔵しておらず、今回の購入選択肢としては録画環境も含めた機器選びとなった。
理想としては、ダブルチューナー内蔵のレコーダーを購入することだったが、D-VHS の資産を活かすには iLink 付きの機種が欲しいなと贅沢な考えが浮かんでしまう。
iLink 付きというのは、たいてい各社の上位機種に限られてしまったりする。
ちょっと予算的にそれは難しかった。
いずれそういった理想の環境を構築すればいいとして、今はまず観られることが優先されるので、それまでの継投用としてシンプルなチューナーか簡易録画機能付きのチューナーか、その辺りを検討していた。

と、そんな最中にアマゾンでチェック中だった DTV-400S という三波チューナーの在庫が奇跡的に復活していた。
両親用にはこれを第一候補にしていたので、すぐさま購入をポチった。
自室用にもアレコレ考えるのが面倒になりかけていたところだったので、とりあえずこれ買っとくか!と勢いで追加ポチった。
運良く入荷のタイミングに遭遇できたので、「観る」についてはあっけなく解決してしまった。
追加で分波器も二つポチる。
こうして同一機器で揃えておくと、もしなにか片方に初期不良があった場合でも無駄にハマらずに済む。

今になってみると、視聴予約ができる機種であったり、出力を二系統持つ機種であったりと、D-VHS を続投させるに必要な機能がある機種にしておけばな……と思うこともあるのだが、まあそれはそれだ。
今現在は、iLink のある中古チューナーをオークションでチェック中なのだが、なかなか安く手に入る気配がない。
金額的に一万円前後になってしまうなら、いっそのこと PT2 あたりで……なんて思いもよぎってしまう。

MP860 に microSD 8GB を追加する

Transcend の携帯音楽プレイヤー(DAP) MP860(8GB)も容量限界に達しつつあったので、だいぶ安くなってきた microSD 8GB 1380円を購入した。
これで一気に容量倍増ということで、およそ1000曲・アルバム換算100枚くらいは追加していける。
にしても、こんな小指の爪ほどの小さなカードに 8GB だの 16GB だのと、恐るべき集積度になったものだ。
特に意識したわけではないが、microSD も Transcend のものを購入した。
2000円以上購入で送料無料になるネットショップを利用したので、ちょうどUSBハブが欲しかったのと、SDカードリーダーも新しいものが欲しかったのとで、まさに一石二鳥のSDカードリーダー付きUSBハブなるものを980円でセット購入。

しかし、このUSBハブ、LEDが常灯していてほんのり熱を持っているのが少し気になる。
プラ筐体で安っぽい感じもあって、だからこそ超軽量なのだが、これはデスクトップに常設用ではなくノート用で一時的に使うものなのか、ケーブル長も7cmほどだし。
まあでも、カードリーダーとしてはアクセスランプが必須だし、USBハブ3ポートあればデスクトップ用にも使えなくはないし、常設使用で壊れるようなことはさすがにないだろうと信じたい。

MP860 に microSD を挿した状態での転送速度と、同じく、今回購入した USB-HCS307 での転送速度とを比較してみる。
ついでに、ケータイに挿しっぱなしで使っている 2GB の microSD も比較してみたいと思う。
厳密には 8GB の microSD は、microSDHC の Class6 という規格拡張型になる。
……つづく。

そしてそして、Ruby 奮闘記が開幕する

今回は、1000 件ほどの蔵書データベース入力(移植)だ。
手作業で 1件 30秒の流れ作業ができたとしても、8時間以上かかる計算になる。
不可能な作業量ではなさそうなところがまた迷いを誘うのだが……もし同じ時間や労力が必要になるとすれば、単純作業の繰り返しより、Ruby の勉強ができたほうが得るものは圧倒的に大きい
やるべきことは、決まった。

まず Amazon のサイトから「持っています」リストを引っ張り込むのは自動処理を諦めて手作業にする。無謀な挑戦は絶対しない、欲張らない、やれることをきっちり確実にこなす、このディレクションが超重要
Amazon のリスト表示は、1ページに 15件ずつしか表示されないので、60ページ以上の手作業による保存が必要になる。まあ許容範囲だろう。
その HTML ファイルを読み込んで ASIN 部分を検索し抽出するプログラムを考える。
実際には、書きながら、考えながら、調べながら、トライ&エラーを繰り返しながら一つずつクリアしていった。

データ(ファイル)の読み込みはマニュアル通りに書けば楽勝なので、次に ASIN の検索を考える。
手作業で保存した「持っています」 1.htm 内には URI が沢山あって、そこから ASIN を検索していくわけだが、そこで正規表現がほんの少しだけでも分かるのは好都合だった。迷うことなくそこに到達しトライする。
試行錯誤の結果、~/dp/◯◯◯◯◯◯◯◯◯◯(←必要なのはこの10桁)の部分を切り取って、そこから余計な /dp/ を除去するという処理にした。というか、一発で切り取れる方法が思いつかなかった……。一発で処理できればいいのかもしれないが、そのために延々とハマり続けて時間を無駄にするより、二発で簡単そうならそれで妥協するのも必要だ。宇宙へ飛ばすロケットだって二段~三段式が当たり前のように……。

これを出力すれば OK かと思いきや、「持っています」 1.htm 内にある、1品目あたり画像と文字の二つにリンク(URI)があるので、それが重複してしまうのと、1行区切りの入出力で空行(nil)ができてしまう問題があった。メディアマーカー側のインポート機能は、1行 1項目というルールだったので、それに合わせた出力結果にしたかった。(重複していてもメディアマーカー側が弾いてくれるけど)

正規表現の処理だけではまず無理なので、配列に入れるという基本中の基本を試す。
配列に入力する段階で、空(nil)をスルーしながら、という形で上手くいって、重複の除去は最終出力の「puts 配列」で「uniq」を付けることで上手くいった。
このへんはマニュアル類を見ながらやれば猿でもできる系なのが嬉しい。
C言語なんかでやろうとすると多分大変なことになるんだろうなぁ、なんて漠然とアホ面で天上界を見上げた。

そして、なにげに一番苦労したのが、複数ファイルの読み込みで、60ファイル以上あるものを手作業で保存したんだから、読み込みも手作業に(毎回スクリプト内(もしくはファイル名の方)をちょっと書き換える)しようかな……と妥協しかけたが、ここまで来ると少し欲が出てしまうし、やれそうな気がしてくるもので……。
まず最初に思いついたのは、ファイル名を 1.htm 2.htm…… と連番で保存しておいたので、スクリプトの方でも連番でループ処理していくようにと、最も簡単な方法を考えていたが……欲張った。
指定ディレクトリ内にあるファイルパスを拾ってきて、それを順次処理させることにした。(逆にこれのほうが問題が起こる可能性は広がると思うのだが……まあ自分専用だからいいんだけど)
これが大苦戦し……、つまりは find 一発目の処理で、空(nil)が与えられると open できずにそこで終了しているようなのだ(たぶん)。というか、それに気づくまでが素人には大変なのだが……。
なんとなく原因がわかれば対処はそんなに難しくないので、とはいえ、そもそも10行スクリプト程度だし、なにか難しい処理をさせているわけでもないし、1行追加する程度で事は片付く。

どんなにちっぽけな作品でも、こうして作り終えた後の余韻は格別なものだ。
プログラムを走らせると、ダァーっと ASIN が滝のように流れる。
それを Ctrl + C で拾う。(ファイル出力なんてもんは書いていない)
そしてメディアマーカーの一括登録枠に Ctrl + V で流しこむ。
「一括登録」をポチる。
無事 934件登録完了!!
購入金額 1,508,282円の表示に、ほっほぅ、と感心する。

でもなんで俺は Ruby を弄ろうとするのだろう。
やっぱり「国産」って響きが好きなんだろうな……。

そして、Amazon の「持っています」から、メディアマーカーへ

他のオンライン蔵書管理系(本棚)サービスで「ブクログ」だかはアカウントを持っていたのだが、いまいちだったのでそれ以来放置。
mixi内にあるやつも少し使っていたんだけれど、同じく馴染まず放置したまま。
今回あらためていくつかのサービスを見て回って、とりあえず「メディアマーカー」が良いかなという直感があったので、過去にアカウント取得した記憶を呼び覚ましつつ ID:PASS メモを探したけれども見つからず、新規で登録してみた。
ほんとうなら自分で CMS を少しそれっぽくしてオリジナルでいきたかったけれど、まあメディアマーカーより良くなることはまずないので考えないことにする。

早速、登録作業を試そうとポチってみると、いろいろ便利な登録方法が用意されていて、そこに一括登録を発見!
これはもしや Amazon から移植できてしまったりするのでは……と期待感が高まるも、残念ながら純正機能としてのインポートは無理なようで、ISBN と ASIN のリストに対応いうものだった。
約 1000 件をいちいち手動入力する気力なんてあるわけがないので、気長にローカルでチクチクとエクセルにでも入力していこうかなと、そのデータベースが完成したらリストで吐き出して一括登録すればいいかなと、そう思ったのだが、Amazon 内に幽閉されし「持っています」リストをやっぱり使いたい……救いたい……。

ということで、Ruby の勉強も兼ねてデータ移植スクリプト書きでもやってみるべかなと。
たのしいRuby」と「Rubyレシピブック」の真っ赤な二冊を本棚の奥から出してくる。

理想は、Amazon の「持っています」リストページから ASIN を引っ張ってくるようにしたかったのだが、HTTP クライアントなんてまず書けるわけがないし、その前にまず足し算を puts するところから復習が始まった……。

とりあえずインストールだけはしてあった RDE を起動して、「あぁ、これこれ、こんなんだったなあ」なんて懐かしみながら、数年前に習作で書いていたランダムサイコロプログラムを走らせてみる。(Amazon探索から~ここまでの道のりで半日経過)

全くの素人が一からスクリプトを書いて目的を達成するというのは、その処理がどれだけ簡単なものであろうと大きな挑戦になることは間違いないし、もしかしたら道半ばで挫折するかもしれない。
やりきったとしても、手作業のほうが早く処理できた、なんてこともありうる。
習作のサイコロなんかも、そのへんにある鉛筆を転がすなり、アミダくじでも書いてみるなり、手作業のほうが圧倒的に楽だし簡単に終わる。
しかし、それを数百回、数千回、数万回……と繰り返したり、その結果をなんらかの別用途に使いまわしたり、というような場合には、手作業だとまず不可能なレベルになってくる。

Amazon の「持っています」や「★評価」が消えてしまった

Amazon の「持っています」チェックがいつのまにか消えていた。
この商品を評価する」の★付けも。

もうこれ↓が商品ページに表示されることはないのだろうか。

Amazon で「カスタマーレビュー」を読んだり、「リストマニア」や「この商品を買った人はこんな商品も買っています」や「おすすめ商品」などから関連商品に出会う楽しみも、そして手に入ると「持っています」にチェックを入れて、読み終われば★を付け、そんな Amazon ライフが……終わった。

この機能が消えてからしばらくは様子見していたのだけれど、待てど暮らせど復活することはなく、どうやら一時的な消失やメンテナンスの類ではなくて、完全な仕様変更によるものだろうと諦めるに至った。
こんなことなら専用の管理ソフトを使うなりエクセルなんかで入力しておくなり(200冊くらいまではやっていた)、自己管理環境下で入力しておくべきだった。

こうした Amazon の便利さに依存しきってしまい、本来の使い道ではない機能だということも忘れていたし、バックアップがとれない場所への入力という重大なリスクを負い、これは本当に大きな過ちだった。

入力済み項目数は 1000 近く。
これを改めて別環境へ手作業で入力していくには結構な時間がかかるものだし今すぐは難しい。
後々ちゃんとしたデータベースをローカル環境に作るのは必要だとしても、とりあえずオンラインで管理できる環境も一つ欲しいところ。

Amazon 内をいろいろ探ってみると、「持っています」リストは Amazon サイト内の深いところで利用することは可能
それを使い続けることも考えてみたというか、実際に少し使ってみた結果、これは実用外だと判断。

「おすすめ商品」から、「商品を評価する」で、検索入力すれば「持っています」や「★評価」は可能。

同様に、「おすすめ商品」から、「おすすめ商品を正確にする」か「既にお持ちの商品」で、一回認証が入って、「「持っています」にチェックを入れた商品」や「評価した商品」に飛べる。

正直言って、このプロセスは深すぎるし、実用性ゼロだ。
終わった……。

解像度統計調査~ウェブサイト制作における想定解像度設定基準

ブルーレイや地デジなど高解像度環境が一般的になった今、PC環境においてはどういった傾向にあるのかを少し調査しておく。
これまでウェブサイト制作では、1024 を目安にしてきた。
そろそろこの基準を見直す時期にきているはずだろう。

2009.12
1280×1024 23.9%
1024×768 21.5%
1280×800 14.9%
1440×900 7.3%
1680×1050 5.4%
1024×600 5.0%

約一年前の段階でも解像度 1024 以上は 100% に近いカバー率となっていた。
解像度 1280 以上でみても既に 50% を超えている。
しかし、ワイド環境は 30% 前後で、まだこれからといった感じ。

2010.9
1280×1024 16.2% -7.7
1920×1080 13.8%
1440×900 10.9% +3.6
1280×800 10.3% -4.6
1024×768 8.6% -12.9
1680×1050 8.2% +2.8
1366×768 6.3%
1920×1200 5.8%

夏のボーナス商戦から夏休みを経て9月。
これまで主流だった 12801024 の 4:3 モニターから買い替えで、ハイビジョン対応の高解像度へ一気にシフトしているのが分かる。
ノートPCでもこの高解像度に対応するモデルが増えたのも一因だろう。
ワイド環境は逆転して70%を超えるシェアになった。

2011.1
1920×1080 19.7% +5.9
1024×768 12.5%
1280×1024 12.5%
1920×1200 11.1% +5.3
1280×800 7.9%
1366×768 6.9%
1680×1050 6.5%

年末・初売り商戦を経て直ぐの1月。
まだ1月2週なのでサンプル数不足ではあるものの、解像度 1920 のハイビジョン対応モニターがシェア 30% を超えている
店頭で2万円を切る価格の商品もあり、買い替え需要ではほぼ確実にそれらハイビジョン対応モニターが選ばれているだろう。

ここで、ウェブサイト制作における想定解像度の基準を考えてみると、将来的には 1920 が目安になっていくはずだ。
しかし、まだ半数はそれ以下の解像度が残っているわけで、ボーダーラインを設定するとなれば 1280 になる。
ワイドモニター環境では、左右にガジェットを配置したり、複数ウィンドウの配置や、ブラウザ内でも左右にリスト表示などが普通になってきているから、それらを踏まえても 1280 という基準がしばらくの間は妥当なラインといえる。

AMD Athlon II X4 620 を K10STAT で調教してみる

レシピ 2010.07.28

まずは、クロックをいじらず電圧だけを下げていき底を探る。
Prime95 の4発回しなので、かなり CPU温度が上昇するのを確認。
CPU温度表示で 60℃ を超えてしまい、ちょっと焦る。
定格の 2.6GHz 1.4v をフル稼働させる場合、リテールクーラーでは危険だと判明。

オーバークロック (OC) を考えるなら、まずやるべきことは冷却強化だろう。
しかし、このクラス(1万円前後以下)の CPU に高性能クーラーを取り付けるというのはコスト配分としてアンバランスだ。
その費用があれば数クラス上の CPU が購入可能だろうし、無茶な OC をせずともポン付けで安定した環境が構築できる。
――だからといって、何もしないというのも味気ない。
そこで、P0 を擬似ターボブーストとして設定する。
一時的な高負荷状態に限定して OC を開放する。
それでも、何かのひょうしに CPUリソースを食い潰し続けるようなフリーズ状態に陥ったときのことも考えて、リテールクーラーの排熱飽和ギリギリの 3GHz 1.3v 以下に調整しておく。
こういった遊びや自分流の設定が可能なのも K10STAT のおかげ様様の様の様だ。

ベースクロック 240 ではどうにも安定しないようで、Prime95 を長時間回すとエラーを吐いてしまう。
これまでの試行錯誤と経験からメモリーがこけていると判断し、ベースクロック 238 に設定。
これでメモリークロックが 3MHz ほど下がり、Prime95 を長時間回してもにはならず安定したようだ。
ただし、これらは全てイレギュラーな状況が重なった個人的環境の話なので、絶対的な検証にはならない。

それと、やはり CPUクーラーの非力さは深刻で、3GHz 1.3v 辺りで Prime95 を回し続けると排熱が間に合わずリセットがかかってしまうようだ。(アイドル時の 30~31℃(室温26℃) から、+30℃ くらいのところで)
Q-FAN を ON にしているせいでもあるのだが、リテールクーラーは定格動作での排熱ギリギリのものでしかなく、つまりはこれがある意味でリミッターとして機能してしまう……。


HT (HyperTransport) についても少し研究してみたので追記。
M2A-VM (690G) では、HT1000MHz が設定可能上限となっているが、規格上では 1.4GHz くらいまでいけたような記憶だったのと、CPU のほうは 2GHz くらいまでの対応だった気がするので、ここに探りをいれてみる。

これまで、CPU を OC するためにベースクロックを20%(200 から 240 (238) へ)ほど上げていて、HT の設定は一段下げの、HT1000 から HT800 にしていた。
これでちょうど上げと下げが釣り合って、実稼働 HT1000 前後となる。
それを HT1000 にすれば、実稼働 HT1200 前後の OC設定になる。

で、実際にやってみたところ、特に問題なく OS は起動した。
短時間 Prime95 も回った。
上限の目安は 1.4GHz としているが、M2A-VM 自体の対応上限は 1000MHz なので過信は禁物だ。

肝心の性能はというと、ほとんど変化なし……。
当然といえば当然だが、HT というのはデータの通り道でしかないわけで、そこがボトルネックになっている場合に限り、その道路整備の効果はあらわれてくる。
なので、無理やりにでも渋滞するような使い道をしてみればいいのだ。

というわけで、オンボードVGA をブッ叩く
使っている人を全くみかけない、フロントミッション オンライン ベンチマークで 3Dゲーム処理をさせる。
ポイントは、このベンチマークを回しても CPUリソースが余りまくりだったということ。
つまり、VGA性能が全く足りていない=ボトルネックありの状況が明白だったという。
オンボードVGA性能は、GPUとしての処理能力と、メインメモリーへのアクセス速度で決まる。
で、予想通り10%前後のベンチマークスコア上昇が確認できた。

結論として、自分は HT がボトルネックになるような使い道をほとんどしないので、安定志向の実稼働 HT1000 に戻したが、3DゲームなどでオンボードVGA性能やメモリー速度が少しでも欲しい場合は HT を OC させてみるのも一つありかなと。
でも、M2A-VM のチップに付いているヒートシンクは極めて貧弱なので危険がいっぱいなのと、オンボードVGA の極めて貧弱な処理能力を1割前後アップさせたところで……という現実がある。
それと、K10STAT の俺レシピで、各 CPUコアのクロックをバラバラに可変させていると省エネには良いのだが、ベンチマークスコアは7%ほど低下していた。
ピーク性能を維持したい場合には、可変同期させるか、固定させるべきだというのを再確認できた。

追記 2010.07.28

M2A-VM HDMI BIOS 5001 に AMD Athlon II X4 620 を載せてみる

M2A-VM HDMI の BIOS が1年ぶりくらい?にアップデートされた。
いやはや、なんとも ASUS さん、スゲーよ!!
3年も前の M/B で、最新とまでは言えないものの、まさかの現行世代 CPU に正式対応(β版扱いではあるが)とはね。

BIOS バージョンとしては、昨年の 2302 で打ち止めだったわけだが、今回突如として 5001 が登場し、そのナンバリングからもこれが本当に最後の最後、ASUS からのプレゼントだというのがよみとれる。
次も ASUS 製品をよろしくね、ということだろう。
ここまでされては、次も絶対 ASUS を買ってやるぜ!!となる。

――で、じつは、この BIOS が登場するまえに衝動買い……していた AMD Athlon II X4 620 が数ヶ月の熟成を経て遂に御開帳、と。
(ASUS の CPU サポートリストには 635 と 640 が書かれているのだが、620 や 630 は無い…… まあ細かいことは気にしないで……)
 ADX620WFK42GI
 CADAC AD 0945CPBW
 (Propus と思われ)

エアーダスターを噴きつつ、掃除機で吸いつつ、ケース内を掃除をしながら、旧CPU となった Athlon 64 X2 3600+ を取り外す。
そして、新CPU を取り付ける。
付属品の CPUクーラーのヒートシンク形状が変わって、フィンパターンが横方向のみだったものから縦横十字になったので、これまで最も排熱が心配されていたチップセットの貧弱なヒートシンクにも空気の流れができる!という嬉しい副次効果まである。

BIOS の設定を初期値にし、いざ!!ブート!!
……なんの問題もなく、ピポッ♪と、起動成功。
(事前に OSレベルで CPUドライバーの見直しや CrystalCPUID のスタートアップ解除などをしておくのは言うまでもなく)


次に、個人的な趣味として最も楽しみにしている Down Clock & Over Clock を。

K10STAT で、極限まで自分好みに CPU を調教する!! ……つづく。

ニューマシン構築メモ ……誕生……あの日。

SOY CMS のデータバックアップついでに SQLite.db を最適化する

SOY CMS ネタをこのブログで書くのは一年以上ぶり……。
その間、SOY を全く触っていなかったわけではなくて、主にメンテをするだけな感じで、これといって先っちょを追っかけることはしていなかったというだけ。

と、そんな前振りは三行で切りあげて本題へ。
保守・メンテにおいて最も重要だと思われるのは、データ類のバックアップだ。
SQLite版なら基本的には sqlite.db のコピーを大切に保管しておけばいい。
詳しくは、SOY CMS オフィシャルサイトの、
http://www.soycms.net/product/download
バージョンアップ方法」に書いてある、
common/db以下」と「サイトディレクトリの.db以下」をバックアップせよ、と。

まあそれは当たり前に保守作業として常日頃からやっていることなのだが、ちょっと気になったのが、我がウェブサイトデータが詰め込まれた sqlite.db のファイルサイズが 6.7MB と、メタボ感。
記事数は 54件で、ページは 10 前後。
コメントや TB は皆無なのを総合的にみても、6.7MB はちょっとデカイ。
一番の心当たりは、過去に TBスパムを~万単位でくらっていたので、その頃に DB がエージングされまくったのは間違いない。

というわけで、SQLite の最適化・ダイエットを決行する。
SQLite の最適化には、TkSQLite を使用。
http://reddog.s35.xrea.com/wiki/TkSQLite.html
ダウンロードをポチって、下のほうにあった Win32 のをゲット。
http://reddog.s35.xrea.com/software/tksqlite-0.5.8-win32-bin.zip

解凍して出てきた tksqlite.exe をポチチって起動。
sqlite.db を開いて中のデータを覗き見しつつ、ちょっと動作が鈍いな……なんて思ったり、Tk だからかな……なんて知ったかぶり感。
メニューから VACUUM をポチる。
処理は一瞬。

sqlite.db のファイルサイズを確認すると、6.7MB から 2.33MB にまで最適化されていた。
生まれ変わったこいつをアップロードして、ブラウザから我がウェブサイトをポチポチ巡回してみる。
念のためキャッシュも削除して、またポチポチ巡回してみる。
OK牧場。

最後に、この投稿にて、最終動作確認とする。

Google Chrome のスクロールを滑らかに

Google Chrome のスクロールを滑らかにする拡張機能 SmoothScroll を試す。

Chrome のスクロールは流れるような動作ではなく、一定の高さ(行数)が瞬時に飛ぶだけのシンプルな動作なので、長文を読んでいる途中にスクロールさせてしまうと視点を見失ってしまう。
これがかなりのストレスで、無駄に時間もかかってしまい最悪だった。

長年愛用しているマウスはクリック感のあるスクロールホイールで、一滑り三行~五行くらいスクロールしてくれると感覚的に都合が良い。
クリック感の無い無段滑りタイプのマウスはまた違った感覚になるのだろうとは思うが。

SmoothScroll をインストールし、自分好みに少し調整してみる。

Stride size per scroll in pixel [200] Default value: 95
一度にスクロールする量(高さ)をデフォルトの 95 から 200 に増やす。
これでざっくりと好みの移動量に設定する。
基本的には、この数値を調整するだけでいい。

Animation time in milliseconds [400] Default value: 400
これはスクロールにかける時間、だと思う。
スクロール量をだいぶ増やしたので、時間もデフォルトから 50% ほど増やしてみた……けど、やっぱりトロくさいだけなので 400 にした。
サクサクっとスクロールさせたい場合は下げて、ニュルニュルっとさせたい場合は上げるといい。
同じく、Pulse Scale でも調整できるみたいだけど。

Frames per second [60] Default value: 50
これがフレームレートで、スクロールの描画の滑らかさに影響する。
モロに CPU性能を食うので上げ過ぎないように、と 60 に設定した。
ヘボPC やノートPC で無駄な処理をさせたくない場合は下げるといい。

これにて Chrome でも長文読みが可能となった。