OCRもそれはそれでよいが……

今日はPayPayフリマでたくさん売ってたくさん買った日だった。

PayPayボーナスもいい感じに消化できてよかったんじゃないですかね。

よく売る人はよく買うという話もありますが、新品・中古問わずいろいろ買ってますね。

もうちょっと売れてくれないと本の収納場所が……


今日はGoogle Playカードを購入した。

キャンペーン目当てでの購入ですね。

Google Playカードを購入して登録するのだが、これがだいぶ楽になっていた。

まずはスクラッチ部を削る……のではなくシール状になっているのをはがしてコードを出す。

削る方法でもよいのだが、はがす方法の方が圧倒的に楽である。

その状態でGoogle Playアプリを起動して、ギフトコードを登録するのだけど、

ここでカメラを使って自動的に読み取ることができる。

ついでにこの後にキャンペーン申込みをするのに、購入時のバーコードの一部が必要なので、

これもバーコードリーダーアプリでスキャンして切り出した。


以前はコインで削って、アルファベット・数字交じりの文字列を打ち込んで……

とけっこうめんどくさかったGoogle Playカードの登録だが、いろいろな工夫で楽になりましたね。

まぁクレジットカード決済の方が楽だろと言われればそれはそうなんですけど。


ところでカメラでコードを読み取るというのはOCRで文字認識をしてるということですね。

書体がOCR-Bであることを考えれば文字認識は比較的容易だとは思うが、

そうはいっても読み取り条件によっては誤読はあるものである。

認識の容易性だけ言えばバーコードなりQRコードの方が……

とは思うけど、スクラッチカードには向かないのかなとも。


そんな中、ちょっとニュースで話題になっていたのですが。

ワクチン接種券読み取りに不具合 政府配布タブレット (日本経済新聞)

現在、新型コロナウイルスのワクチン接種にはVRSという記録システムが使われている。

一般的な定期予防接種では市町村が予診票を発行して、それを医療機関に持参して接種を受け、

医療機関が予診票を回収して市町村に提出して……というようなフローを取るのだが、

今回、広域接種も想定されていたからか、突貫工事で作られたのがVRSというシステムだと聞いている。

全国共通フォーマットの接種券・予診票を市町村が配布して、これを接種会場でVRSに登録するということである。


で、このVRSでは接種者の情報を読み取るのにOCRを使っていて平均2~3秒で読み取れる!

ということだったのだが、実際にはそれ以上の時間を要したり、誤認識が起きることがあって問題になっているようである。

ところで、この記事で読み取り画面の写真が掲載されているが、バーコードがあるように見える。

バーコードじゃなくてOCRなの? と思ったかも知れないが、実はバーコードはOCRで読み取る文字情報の一部しか入ってないらしい。

現場の工夫により足りない文字列を付け足すバーコードと連続して読み取ることでこの問題を回避しているケースもあるようだが、

どうして現場でOCRを使うことにしたのか? というのはよくわからない話である。

OCRの性能が高いからそれで問題ないと思ったのかも知れないが……イマイチである。


OCRといえば、以前は本の流通で使うことが想定されていて、

そのためにISBNなどの情報を印字する書体(OCR-B)・文字サイズが厳密に規定されていたら。

しかし、ISBN13桁化のときに、それはバーコードでやるだろということで、この規定を大きく緩和し、

それ以後は従来よりも小さめの字で一般的なゴシック体で記載されることが多くなっている。

そういえばそうだなと思った人もいるかもしれない。


事情は色々なのでなんとも言えないのですが……

カメラで読み取るならQRコードはQuick Responseの言葉の通り素早いですよね。

PayPayが導入されたときにユーザースキャン方式とかどう考えても遅いだろと思ったけど、

意外に速いのは、QRコードの読み取りの早さのおかげというのはあるだろう。

QRコードはそれはそれでデザイン性の問題があるというような話もあるんですが。

確かにGoogle Playカードに登録用QRコードを印字するとなれば、なかなか置きにくいとは思う。

一方で、接種券にそういうスペースを作ることはそんなに難しくなかったのでは? という気はする。

やり方次第ではないか。

iOSではスクリーンショットできるんですか

Twitterで集英社の電子書籍アプリでアカウントが凍結されたと言っている人がいて、

話によればスクリーンショットの撮影を繰り返したためだという。

結局は手続きを踏んでアカウント凍結は解除されたようだけど、

そもそもなんでこういうことになってるんだろうと。


というのもちょっと前にこのBlogでとある電子書籍アプリでスクリーンショットが封じられてた話を紹介した。

スクリーンショット禁止っていうけど

これ詳しく書かなかったけど集英社直営ストアの話なんですよね。

同じアプリではなさそうだったが、集英社なら基本的な考えは同じだろうと。

確かにそうらしい。

ただ、1つ違いがあって、それはその人はiOSを使っているということ。


実はiOSでは直接的にスクリーンショットを禁止することはできないらしい。

ただ、スクリーンショットが行われたということを検出することはできる。

そこで、このアプリはスクリーンショットが行われたことを検出して、

まず警告を表示する。ここでアカウント凍結の可能性もあると警告されるわけである。

2回以上スクリーンショットを撮らなければ、おそらくはおとがめなしである。

しかし、それを無視して繰り返すと、今度はそれを元にアカウント自体を凍結させてしまうと。

このようにして間接的にスクリーンショットを抑止しようとしているようだ。


AndroidではHDCPを強制してまで、スクリーンショット制限を実効的にしようとしている。

実際にはAndroidエミュレータ、BlueStacksで外側からスクリーンショットが撮影できてしまうけど。

WindowsではHDCP強制していないから、外側からキャプチャすることはできるが、

HDCP強制でないといってもそうそう容易な話ではないだろう。

そんな中ではiOSは禁止できないという点では相当にゆるいが、

反復的にスクリーンショットを行うことを困難にしてなんとかということらしい。


まぁ仕方ないと言えばそうなんだろうけど、今どきそんなのなのかと。

もっともiOSもDRMで保護されている動画についてはスクリーンショットをすると真っ黒になったり、

あるいは動画でキャプチャする場合はそれを検出して画面を消すような処理は可能だという。

すなわちスクリーンショットだけが穴となっているわけで、静止画については軽視しているだけとも言える。

まぁそれは仕方ないのかなとも思うが、電子書籍だと静止画が全てなんだよなぁと。

もちろんその性質によって制限の必要性は判断されるべきですが、時間限定のコンテンツなどは制限する妥当性はあるんじゃないか。

集英社もそういう意図だと思うが。

何をマイニングしてるんだろう?

マイニング需要でグラフィックボードが品薄なんて話はよく聞くけど、

一体何の暗号資産(仮想通貨とも)をマイニングしてるんだろ?


結論から言えば、多くにおいてはEthereumとみられる。

暗号資産の先駆けともいえるBitcoinではSHA256のハッシュ計算を効率よく行うために専用のICを作ることが行われた。

これをASICマイニングと呼んでいるが、こうなってくると参入障壁が非常に高い。

ASICマイニングにはCPU・GPUを使っては太刀打ちできないのが一般的で、専用のICは一般には買えませんから。

というわけで、Bitcoinのマイニング目的でグラフィックボードが品薄になるのは現実的ではない。


一方で後発の暗号資産では、ASICマイニングを困難にするようなアルゴリズムが取り入れられることが多くなっている。

というのも、暗号資産は多くの参加者の合意を得ることで改ざんを困難にしているわけだが、

Proof of Workを使っている暗号資産では過半数の計算能力を悪意を持った人が占有すると、台帳の改ざんができてしまう。

これを「51%攻撃」などと呼んでいて、実際そういう被害が出た通貨もいくつかあるようだ。

この問題を回避するためには特定の人が計算能力を独占できないように、汎用的なコンピュータでマイニングに参入できるようにするべきだと。

これが後発の暗号資産では一般的な考えだという。


さて、人々が暗号資産のマイニングをするにあたって、マイニングプールに参加することが一般的である。

というのも、大抵においてマイニングというのは、特定の条件を満たすハッシュ値を算出した人が報酬を総取りする。

なのでPC数台とかいう単位でマイニングをやっても報酬が得られる可能性は低い。

そのため、よっぽど大規模でない限りは、みんなで計算能力を持ちよって、獲得した報酬を分け合う仕組みが一般的で、それをマイニングプールと呼んでいる。


そんなマイニングプールの中でも特に参加者が多いらしいのが「NiceHash」というサービスである。

これは数あるマイニングプールの中でもかなり独特なものである。

NiceHashでは多数のアルゴリズムが選択可能で、それぞれの環境でもっとも多くの報酬が得られるものが自動的に選ばれるのが通常。

しかし、どのアルゴリズムでマイニングしても報酬はBitcoinで与えられる。

なんで? と思うところだが、実はNiceHashは計算能力の売買の仲介をするサービスで、

Bitcoinを払って、NiceHashの計算能力を買って、それで暗号資産のマイニングをする人もいるわけだ。


Algorithms (NiceHash)

これがNiceHashで取引されているアルゴリズムなのだが、日当たりの取引高の大きいアルゴリズムはこんなところ。

  1. Ethash(DaggerHashimoto) : 81BTC/日 (53万台)
    →Ethereum, Ethereum Clasic, TRON など
  2. SHA256(SHA256AsicBoostと合算) : 9.6BTC/日 (8万台)
    →Bitcoin, Bitcoin Cash, Bitcoin SV
  3. Scrypt : 6.4BTC/日 (4万台)
    →Dogecoin, Litecoin
  4. KAWPOW : 2.0BTC/日 (5万台)
    → Ravencoin
  5. Equihash(パラメータ違いのZhashと合算) : 1.7BTC/日 (3万台)
    → Zcash, Bitcoin Gold(こちらで使うEquihashをZhashと通称しているらしい)
  6. RandomX : 0.84BTC/日 (15万台)
    → Monero

()内にminerの数を書いておいた。時間帯に変動はあるかもしれないのでなんとも言えませんが。

というわけで取引金額・miner数のどちらを見ても圧倒的にEthashで、Ethash=Ethereumと考えて差し支えない。

実際、マイニングしてるPCの画面のスクリーンショットでも「DaggerHashimoto」という表示を見ることは多い。

(NiceHashでなぜDaggerHashimotoと表記されているのかというと歴史的経緯があるらしい)


SHA256もなんやかんやいってけっこうあるが、これはASICなんですかね。

取引額の半分以上はSHA256AsicBoostという露骨にASICっぽいアルゴリズム名だし。(根本的には同じだと思うが)

ScryptはASICマイニングを回避するアルゴリズムにしたつもりが、結局はASICマイニングされてしまったというものらしい。

miner1台あたりの売却額とみると、Ethashが0.15mBTC/日、SHA256が0.12mBTC/日、Scryptが0.16mBTC/日と似たようなもんだが、

その次、KAWPOWは0.04mBTC/日、Equihashが0.06mBTC/日とやや少なく、RandomXは0.006mBTC/日とかなり少ない。

(参考までに現在の相場で1mBTC=約6000円であるから、Ethashだと1台平均900円/日、KAWPOWだと1台平均250円/日とかそれぐらい)

KAWPOWやEquihashは比較的非力なGPUでのマイニングで選択される傾向があるらしく、

実験的にAMD APU搭載のこのPCでGPUマイニングをしたら、唯一動いたのがZhash(Equihash)だった。


そしてRandomXについては、これは専らCPUマイニングに適用されるアルゴリズムである。

RandomXはMoneroという暗号資産のアルゴリズムなのだが、CPU以外でのマイニングを非常に困難にするという方針なんですね。

これは他のアルゴリズムと明確に異なるため、CPUマイニング=RandomXということらしい。

もっともMoneroという暗号資産は流通量の割に取引所での取扱が少なく(日本国内には取扱業者がいないとか)、

これはMoneroの方針で非常に匿名性が高く、犯罪に利用される恐れがあると、業者も手を出したくない存在らしい。

NiceHashならRandomXの計算能力にもBitcoinが支払われるから、漫然と動かすのは容易だけど、

大した金額にもならないので、非常に軽視されているというのが実情である。


時価総額ではBitcoinが筆頭で、次がEthereumで、この2つが飛び抜けてますから、

BitcoinはASICマイニングで支えられ、EthereumはGPUマイニングで支えられているということであろう。

(EthereumもASICマイニングはあるが、アルゴリズム設計上、効果が薄いらしい)

その上で昨今の経済情勢により行き場の失った金がBitcoinやEthereumに流入してるということで、

そんなところでこれらの暗号資産、あるいはそれ以外の暗号資産のマイニングで得られる報酬が増えていると。

そうするとマイニングのためのハードウェア投資をしても見合うということですね。


NiceHashを使ってると、マイニングしてる人も、自分で何の暗号資産をマイニングしてるのか知らないということはありそう。

特にDaggerHashimotoなんて、何を表してるのはさっぱり意味がわかりませんからね。

もちろんEthashを計算して、直接的にEthereumを受け取るマイニングプール(Nanopoolなど)とかもありますから、

こういう場合はEthereumを掘っているということは意識しているはずだけど。

自動更新されて困ったWordPress

週末にこのBlogシステム、WordPressからメールが届いた。

サイト (http://hdmr.org/d) を WordPress 5.7.1 へ自動更新しました。
何もする必要はありません。 バージョン 5.7.1 について詳しくは「WordPress について」画面をご覧ください。

なんだこれ? と思ったんだが、どうもWordPressには自動更新機能があるらしいですね。

基本的には互換性の問題はないということらしいのだが……

セキュリティ的に強固な状態を維持するのに役立つということのようである。


確かにこれは一理あるし、本来は大きな問題とならないはずなのだが、

実は更新前後でこのBlogの動きが変わっていたのである。

原因はwp-include/functions.phpに追加していたカスタムコードが消えていたから。

WordPressのカスタマイズをするためにfunctions.phpにコードを追加しろというのはよく見るので、

それに従ったのだが、このファイルが更新で変更されることはないのかな? というのは心配になっていた。

やっぱりあるんですね。


もともとこういうことはあるだろうと予期していて……といってもまさか自動更新されるとは思ってなかったんだが。

カスタマイズのコードの正味部分は別ファイルにしてincludeしていた。

なんでこれのincludeを再度書き加えれば戻るだろうとは思ったのだが、

自動更新のたびに手動対応が必要なのは困った話である。

そこで調べたところ「Code Snippets」というカスタムコードを追加するプラグインがあったので、

これをインストールして、下記のコードを自動追加させるようにした。

include('/var/www/wp/wp-includes/00_custom.php');

これによりfunctions.phpを直接いじってないので、自動更新の影響を受けることはなくなったはず。


自動更新が当然有効になっているのはWordPressの開発者があるべき姿を考えた結果なのだと思うが、

やはり本番のシステムをいきなり更新されてしまっては困るという声の方が多いようだ。

確かにプライベートの重要度の低いBlogだから自動更新されてもまだなんとかなったけど、

自動更新~修正までの間に投稿した記事はslugが漢字になってたり(後に記事のslugについては修正済)、

URLが書き換わってたり、いろいろ問題が起きてしまったわけである。

影響度が小さいはずと考えた更新プログラムも、環境によっては思わぬ影響を及ぼしてしまうことはあることだ。

そこで更新するにしてもテスト環境でテストしてから本番環境へというステップを踏みたいということで、

自動更新を切るための方法がいろいろ紹介されているが、設定画面で簡単に設定できる話ではないらしい。

この辺はWordPressの開発者と運用に関わる技術者の考え方の乖離がかなり大きいところである。


ちなみに00_custom.php(00で始まってるのは検索しやすくするためで深い意味は無い)の内容は下記の通り。

  • slugの付け直し(タイトルから漢字になってしまうところを wp-6085 などに強制付替)
  • パーマリンクのURL変更 (内部的なslugが blogn-4732 ならば /?e=4737 のように旧形式にURLに変換する)
  • RSS URLの自動変換(/rssを内部的にはindex.php?feed=rdfに変換している)
  • 上記自動変換によってURLの書換が起こらないようにする(なにもしないと /feed/rdf にURL変換されてしまう)
  • フィードリンクを強制的に/rssに変換
  • 検索結果の表示順序を日付順に固定(標準ではタイトルで検索結果ヒットの日付順→本文で検索結果ヒットの日付順)

といったところで、けっこういろいろあるんですね。

URL関係はApacheの設定でやってる部分もあるので、WordPressの更新だけで即ダメになるわけでもないのだが、

やはりいろいろおかしな挙動になっていたので、そこで気づいたというのが実情ですね。


やっぱり今まで化石みたいなBlogシステムを使ってたのがWordPressに変わるといろいろありますね。

よくメンテナンスされてるのは安全・安心とは言えるし、カスタマイズ性も高いけど、やっぱり難しいわ。

唯一の選択肢だろうと選んだWordPressですからうまく付き合っていくしかないね。

プロセスが多くてはメモリ浪費がひどい

朝にBlogにアクセスすると異常に重くて、状況を確認しようとするとSSHアクセスも重い。

MySQLなど一時停止して、再起動すると立て直せたが、いろいろ重くて、

始業前にいろいろ対策をしていた。


これまでBlogではデータベースシステムを使ってなかったんだな。

ところがWordPressを使うのは不可避だとMySQLを導入したら、これがリソースを食ってた。

ただ、MySQLについては負荷軽減のための対策はこれといってなく、

対策をしたのはそれ以外の部分である。


結論から言えば、メモリの消費がひどかったんだよね。

# free

RAMはほぼ全部を食い潰し(メモリの余裕はavailableの数字をみるとよい)、スワップすら半分以上使ってた。

このVPSの契約がメモリ1GBというケチな契約なのがそもそも悪いのだが、

簡単に増量できなさそうだし、少ないメモリ消費でもパフォーマンスを維持できる仕組みを考えることに。

まずは現状分析のためにプロセス毎のリソース消費量を調べた。

# ps aux --sort=-%mem

これでメモリ消費量順に並ぶのだけど、筆頭はmysqldでしたね。

でもmysqldは1つだけなんですよ。

複数のプロセスに分断されてるものを合計して考えると一番ひどかったのはphp-fpmだったんですよね。

あと使ってないのに消費してたという点ではsssdというのがあって、認証関係のデーモンらしいが使ってないのは確実なので無効化した。


php-fpmとはなにかという話だが、これはPHPを使ったことあるひとでもなじみがない人は多いかも。

このサーバーでは以前よりPHPをfastcgiを使って動かしてきた。

FastCGIは本当に速いけど…それだけ?

それがいつしかphp-fpmというもので管理されるのが標準になったらしい。

なんとなく旧来のApacheプラグインとして動くPHPと似てきた気もするけど、あくまでも違うものなのかな。

とはいえ、これが一番良さそうなのは確かなのでphp-fpmを採用している。

ユーザーディレクトリに限ってはこのとき書いたのと同じFCGIWrapperを使う方法にしてるけど。


で、php-fpmは標準設定だと最大50個までプロセスを動的に増やせるらしく、多すぎるプロセスにメモリが食い潰されていたらしい。

というわけで適度な個数に制限することで、メモリの浪費を防ぎパフォーマンスを保てるわけである。

/etc/php-fpm.d/www.conf にて、下記の通り設定した。

pm = static
pm.max_children = 4

これが一番効いたかな。


他にもこういうものはある。ApacheもDovecotもそうである。

Apacheだとこんな感じで

StartServers 2
MaxClients 2
MaxRequestsPerChild 128

プロセス数2は少なすぎるかなぁ。

Dovecotについては、imap-loginが標準設定ではログイン要求毎に作られるのが問題で、

これは多くのログイン要求(総当たり攻撃も含む)でプロセス数が際限なく増えてしまうということである。

ただし、imap-loginをログイン用要求毎にプロセスを作るのはセキュリティ強化のための方法らしく、

下記の設定はパフォーマンス重視の設定であることに注意が必要である。

/etc/dovecot/conf.d/10-master.confにて、

service imap-login {
  (略)
  service_count = 0

これでもimapプロセスは接続毎にできるけど、これは実際使われている分なので仕方ないということで。


こんな対策でとりあえずメモリの空きは確保できるようになった。

ただ、やっぱりきついですね。RAM 1GBのVPSは無謀だったかなぁ。

いろいろあるかもしれないけど、パフォーマンスは犠牲にしても、

なにかあっても身動きが取れなくなるほど悪化することは避けられるようにカスタマイズしていきたい。


あとSSHのログインが遅い件については、こういうカスタマイズもした。

ログイン時の処理で使っていないもの、あまり意味のないものを切ったという話。

UseDNS no
GSSAPIAuthentication no

もちろんGSSAPIを使っている人は有効にしないといけませんが。

プッシュ通知が使えてなかったのは設定ミス

今さらなんですけど、AndroidタブレットでIMAPのプッシュ通知が有効にできた。

Androidのメーラーとしては「K-9 Mail」を使っている。

おそらくAndroidでは唯一のSSL/TLS証明書認証を使えるメーラーで、

これがあるから証明書認証を使えているというところはある。

マイナーな認証方式ではある

まぁそれ抜きにしてもAndroidでIMAPのメーラーといえばこれだと思いますが。


で、今までもIMAPのプッシュ通知は有効にしていて、スマートフォンの方はそれで即時通知が来ていたのだが、

タブレットの方はプッシュ通知は飛ばないし、数分に1回の自動更新も期待通りに動かない。

どうなってんだと思ってたら、電池の設定のせいだったらしい。

電池→アプリ起動で、K-9 Mailの「自動的に管理」を無効にすれば、メールが届いた瞬間にプッシュ通知が届くようになった。

実はスマートフォンでは同じ設定をちゃんとやっていたというだけの話で、

とはいえ、なぜそのことをあまり意識してなかったのかというと、

こちらでは同設定はアプリの権限設定などと並んであるので、非常に気づきやすかったんですね。

MediaPad M5を使うようになって2年間、このことに気づいてなかったのがアホらしい。


もう今どき、メールサーバーを設定して……なんてE-mailの使い方をする人も減っただろうなぁ。

スマートフォン・タブレットならGmailアプリなど入れて、PCならWebメーラーを使ってと。

IMAPというプロトコルも、これを意識して使う人はそう多くないかも。

ただ、内部的にはIMAPを使っているようなメールアプリもありそうな気はしますが。(Yahoo!メールとかそんな感じがするけど)

IMAPの特色として、基本的にはメールサーバーにメールを置きっぱなしにして使う(POP3だと受信後に削除するのが通常だった)、

なんていうのはよく言われる話だけど、その次ぐらいの特色がプッシュ通知ではないかと思う。

IMAP IDLEという機能らしいのだけど、コネクションを維持しておくと、

メールボックスにメールが届いたらサーバーから教えてもらえるわけですね。

これにより、ポーリング間隔を数分と長めにとっても、メールが届いたら即時に通知が入るというわけである。

短い間隔でポーリングを繰り返されるよりもメールサーバーの負荷軽減にもつながるとされている。


今どき、そこを意識してE-mailを使う人は減ったと想うけど、うちは自分でメールサーバー動かしてるからね。

どうしてもここら辺の設定は意識して使うことになる。

ただ、IMAPとしてはこの機能があって、アプリが対応していても、

それがAndroidの電池マネージメントでつぶされるというのは難しいね。

K-9 Mailはこれ切っても大した電池消費はしないけど、アプリによってはこういう対策は必要なんですよね。

マジックコード、ただしバイト順が逆

今日は出勤して作業していた。

作業自体はわりと短時間で終わる話だが、実機を使うとなると出勤してやらないとね。

無事に完了して、作業完了後にハードウェアを他の担当者に引き渡して、

なんともなければこれでいけるはず。


今回はプログラムに簡単なチェック機能を組み込むものである。

コマンドを送ると、チェックして、判定結果を格納するというもの。

判定結果は0と1でもいいのかもしれないが、偶然OKに見えてしまうと嫌だなと思い、

OKの場合は0x900DDA7Aという値を格納することにした。

“gOOD DATA”ってことですね。Tはちょっと無理がある気がするけど。

NGの場合は明確に別の値を格納するし、チェック結果の格納前に読んでしまっても偶然OKになる確率は極めて低い。

(手順を守ってやればそんなこともないはずだけど、視覚的にわかりやすいのはよいことである)


それで実行したら、なんか変な値が格納されていて、初期化ミスでもしたか?

と思って、よく結果を見たら “7A DA 0D 90” というデータ列で、

これリトルエンディアンで見れば 0x900DDA7A ってちゃんと格納できてるなと。

そうだ、マイコンは4byteのところにリトルエンディアンで代入しているけど、

判定する側はビックエンディアンで見ている(他の部分も大半そうなっている)から、こうなるのか。


というわけで、これ自体はわりとあるあるなので、バイト順を入れ換える処理を追加しようかと思ったのだが、

よく考えたら代入する値は定数なんだから、

0x900DDA7Aのバイト順を入れ換えて代入する処理を書くのも、0x7ADA0D90という値を代入するのも意味は変わらない。

というわけで代入する定数の定義を 0x7ADA0D90 に書き換えて、

「ビックエンディアンでの0x900DDA7A」というような注釈を入れておいた。

こうして期待値通りの結果が得られるようになってめでたしめでたし。


しかし、本来は視覚的にわかりやすいという理由でこういうマジックコードを使っているのに、

そのマジックコードのバイト順を入れ換えた、一見よくわからない値を代入するのはちょっと納得感のないところはある。

そういうもんなんですかね?


というわけで実にしょうもない話でしたとさ。

チェック処理も過去に作った処理の転用で非常にシンプル。

ただ、これを作り込むことで製造上のメリットがあるということでやることにした。

姑息というのはこのことだが、製造時にしか使わない機能なので姑息でもいいかなと。

PCとスマートフォンの切り分け方

新しいBlogになって、あんまり見た目が変わらないと思った人もいると思うが、

一方でスマートフォン・タブレットで見ている人は、サイドバーがサイドになくなったことに気づいたかも。

画面幅の小さな端末ではサイドバーを下に持っていくようにしたんですね。

PCでも画面幅を狭めていくと、この表示を体験することができる。

あるところで、サイドバーが消えて、右上に▼が表示され、これをクリックするとサイドバー相当の内容に飛ぶ。


これは画面幅に応じてCSSの動作を切り分けているからである。

@media (min-width: 900px) {
  .absolute-sidebar {
      float:left;
      width:30%;
  }
  .site-content {
      float:left;
      width:70%;
  }
  .secondary-link{
      display: none;
  }
}

900pxよりも画面幅が大きい場合は、サイドバーを画面幅の30%、コンテンツ本体を70%として、左右に並べると。

その上でサイドバーへ飛ぶための▼も必要ないということで表示から消している。

900px未満の場合はこの部分が適用されないので、▼は表示されるし、

コンテンツ・サイドバー共々幅100%で、通常通り上から下にコンテンツが並ぶという形になる。


このような形になったのは参考にしたテーマがこういうものだったから。

  • サイドバー相当は通常は表示されていない
  • ボタンをクリックしたときだけ表示される
  • 画面幅が広い場合は画面の右一部を割いて、狭い場合は画面全体に覆い被さる

これは複雑すぎたが、画面幅が狭いスマートフォンなどで常にサイドバーを表示する不都合はあるわけで、

画面幅によって表示方法を切り分ける部分は採用したということである。

こういうサイドバーが常に表示されるデザインはスマートフォン時代にとっては古風だが、

PCではこのスタイルはやはり使いやすいわけで、使えるところは使ってスマートフォンでも見やすいようにしたと。

(もっとも、こんな文字だらけのBlogはそもそもスマートフォン向きではないのだが)


ただ、これをやるためにはもう1つ仕込みがいるんですよね。

<meta name="viewport" content="width=device-width, initial-scale=1">

これをHTMLの冒頭に書いておく必要がある。

これはスマートフォン・タブレットだけに適用されるものだと思うのだが、

この書き方をすると、デバイスごとに決められたピクセル数を画面幅とみなして表示することになる。

手持ちのスマートフォンだと425px、タブレットだと630px(いずれもAndroid)になってるみたい。

viewport について (Just another memorandum) : Viewport 確認用

width=360とか書くと、どんなサイズのスマートフォン・タブレットでも360px幅とみなして表示される。

デザインを固定できる一方で、画面の大きなタブレットでは不適かなということで、device-widthということで端末お任せにしている。

ちなみに端末を横向きにすると、タブレットでは900px超となりPCと同様の表示になる。

これもwidth=device-widthとするメリットである。


さっきの425pxとか630pxというのは実際の画面サイズとは違う値である。

昔はiPhoneが320px、Androidが360pxが典型的な値だったが、画面の大型化により少し拡大する傾向にある。

width=320とかwidth=360とか指定することが多いのは、この頃の数字を引きずってるということか。

結局、その頃との相対値でいろいろ言ってるので、現状とはいろいろ合わないんですよね。


これをAndroidのChromeで「PC版サイト」にすると、画面サイズによらず980pxを基準にして表示することになるようだ。

典型的PCが980pxなんですかね。

さっき900pxが閾値だと書いたので、PC版にすればスマートフォンでもサイドバーが右側に出る。

viewportが指定されていない場合(すなわちスマートフォン用ではないページ)も同様とみられる。

なので、こうやって見ると、旧Blogをスマートフォンで見た場合とそんなに変わらないと思う。


PCとスマートフォンで大きく見た目が違うページも、

意外にこういう画面幅の切り分けで実現されていることがあるんですね。

だからPCでもズリズリと幅を変えていくと、スマートフォン同様の表示になることがあると。

なかなかどのデバイスでも見やすいというのは難しいところはあるのだが、

自分自身が、PC・タブレット・スマートフォンをどれも使うので、

それぞれの性質によって見やすくなるように工夫しているつもりである。

PCはWindows、スマートフォン・タブレットはAndroidということで、他OSでは事情が違ったりするとは思うが、

それでも大崩れしないようにはしているつもり。(どうにもまずかったら教えてくれるとありがたい)

OSもPHPも新しくなりました

前々から話題にはしてましたが、OSのバージョンアップが完了しました。

OSバージョンアップの障壁はPHP

移行後のOSは「CentOS Stream 8」ですね。

CentOSに対する方針の変更はいろいろ言われたが、長く使うことを考えればこれがいいんじゃないかと。

VPSサーバーに備え付けのインストールメディアには当然無いので、

ネットワーク版のインストールイメージをダウンロードして、VPSにアップロードしてという手順を踏むことに。

でも、これで正真正銘、最新のOSになったのでしばらくは安心。


いろいろ戸惑いはあって、serviceもchkconfigもなくて、systemctlコマンドになってたり、

iptablesがなくなってて、firewalldになってたり、慣れるまではいろいろありましたが。

そういうのを乗り越えても最大の問題はPHPのバージョン移行であり、

特にBlogのシステムが全然使えないと、WordPressへの移行を決断し、

過去のBlog記事を全移行してはURLの一貫性を保つという、まぁいろいろめんどくさい話もありました。

WordPressに古いBlogを集約

それもなんとかメドが立ったので、よっこいしょと移行したわけですね。


WordPressになって、いろいろ検討した結果、トラックバックは廃止することにしました。

もともとスパム対策としてトラックバックURLの発行にワンクッション入れたりしてたが、

そもそも使う人なんていないだろと全廃を決断した。

WordPress独自のPingBack機能を含めて使わないということである。

あとは、旧システムのコメントも移行しなかったが、DISQUSの分は旧Blogで付いたものもちゃんと見られるようになってる。

URLの一貫性が保たれているので、こういうことも問題なかったんですね。


実はいろいろな工夫はあるのだけど、それは追って。

でもとりあえずこれでOSが古いという課題は解決できたので一安心。

WordPressに古いBlogを集約

先日、サーバーOS移行の最大の難関はPHPのバージョン移行であるという話を書いた。

OSバージョンアップの障壁はPHP

移行先はWordPress以外にないだろうということで、格闘していたが、

とりあえず今のBlogと似たような見た目を作ることができ、記事移行もなんとかいきそうなところまで来た。


方針はこうだろうというのはすでにあって、

あと、URLの一貫性もできれば保ちたいので、そういう観点でもどうするかなと考えている。

なにしろ、今のBlogのプログラムを移行するというのはもうできないわけですから、

静的なHTMLを現行システムで吐き出して、これを何らかの方法で表示するというのが有力なところ。

現在のBlognPlusと、その前の掲示板ベースのシステムと、そしてWordPressで新規に書く記事、

いずれもWordPressで管理するという形にせざるを得ないが、ここでの課題は3つあると考えた。

  1. 現システムでレンダリングしたデータを取り出す
  2. 取り出したデータをWordPressに取り込む
  3. URLの一貫性を維持する

ただ、調べたら1.は以前にそういうプログラムを(なぜかPerlで)作っていたので、これを流用すればよさそう。


2についてはWordPress同士のデータ移行をXMLで行う仕組みがあるので、

WordPressになりすまして同形式のXMLを作成することで移行することにした。

意外となんとかなったが、一部の記事の移行に失敗するので何故なのかと悩んでたら、どうもこういうことがあるらしい。

WordPressのインポート処理を改良 (AT-CENTRAL)

まさにこれが問題でしたとさ。なんで1行8192bytes制限なんだか。


そして、最後のURLの一貫性を維持する部分だが、まだ作り込み途中だがだいたい方針は決まった。

WordPressにはslugというのがあって、まぁページ名だね。

標準ではタイトルから生成される。例えば”Hello world”というタイトルなら”helllo-world”のように。

ただ、これは日本語だと不都合ですからね。タイトルの日本語がURLに入ったBlogがあって違和感があるけど。

で、このslugというのは一応は各投稿に好きなものを設定することができる。

そして、ページへのアクセス手段として /wordpress/slug のように使うことができる。


これを利用して作成時期の違う記事にそれぞれ下記のようなslugを付けることを考えた。

  • 旧システム(掲示板ベース): read-xxxxxxxx (read.php/xxxxxxxxに対応)
  • 現システム(BlognPlus): blogn-xxxx (index.php?e=xxxxに対応)
  • 新システム(WordPress)新規記事 : wp-xxxx (xxxxは記事のID)

新規記事はwp_unique_post_slugの処理に噛ませて、強制的に付け直す方法が紹介されている。

本来は同じslugが重複するのを回避するための処理だけど、

ここで日本語を含むslugが付いてしまう可能性を回避する処理を入れるのはわりと一般的らしい。

“read-xxxxxxxx”・”blogn-xxxx”・”wp-xxxx”のいずれの形式にも該当しない記事のslugは強制的にwp-xxxx形式に書き換えてしまうわけだ。


その上でApacheのmod_rewriteで、URLの形式を変換してやる。

/d/read.php/xxxxxxxx は /d/index.php?name=read-xxxxxxxx という具合に。(このURL書換はユーザーには見えない)

こういう形にすれば、従来からのURLの一貫性を維持することができる。

さらにページへのリンクもこの形で作り直す処理を入れれば、

slugがread-xxxxxxxxの記事へのリンクは/d/read.php/xxxxxxxx という形にすることすらできる。

というわけでURLは全く変わらないわけですね。


まだいくつかやるべきことはあるけど、PHPのバージョン移行のためにBlogのシステムを乗り換えるという、

最も大がかりなことはとりあえずなんとかなりそうな気がしてきた。

なんやかんや言っても多機能なシステムなので、いろいろ工夫はできるわけですね。

今月中か来月頭に移行すれば、現在のVPNの更新前には移行できるので目論見通りですね。