2016年12月アーカイブ

この記事は Movable Type Advent Calendar 2016 の最終日の記事です。

再構築ウィンドウ

Movable Type Advent Calendar は2012年から参加していて毎年最終日を担当させていただいています。過去の記事はこちら。

2016年のネタ。2017年、MTはもっと高速になる!

今年は何を取り上げようかと思っていましたが、丁寧に記事を書くモチベーションと時間が足りず、とはいえ負けるのも(誰に?)悔しいので、以前から気になっているMTの箇所にパッチを当てて再構築のスピードを速める実験をしてみました。

静的ファイルジェネレーターとしての Movable Type

少しだけもったいつけて前振りを。静的サイトジェネレーター Advent Calendarで Movable Typeの中の人である長内さんが記事を書かれていますね。そう、MTは静的ファイルを吐き出すことのできるCMSです(ダイナミックパブリッシングも可能、部分的ファイナミックパブリッシングも可能、もちろんダイナミック処理ではキャッシュの仕組みを備えています)。

今年は第2回CMSプロレス 多言語サイトタイトルマッチ - CMS SUNDAYにお呼ばれして、チームMT(一人だけど)として参加、見事に勝利してきました。Movable Type以外の参加CMSはDrupal、concrete5、TYPO3、WordPress。Movable Typeだけが異質だと思いませんか?

  • MT以外のCMSはすべてダイナミック前提
  • MT以外のCMSはすべてPHP(MTは基本Perl、ダイナミックはPHP)

PHP、Perlの違いはまぁ置いておいて、ダイナミックとスタティック(静的サイト)だと、文化が違うというか話がかみ合わないんです。同じく中の人の澤さんに「勘所がわからん!」とか言ってますね。

Facebookにて、ピンチを迎える私!

そう、動的、ダイナミックなCMSが「高速ですよ」っていったらみんなキャッシュの話静的ファイルジェネレーターでキャッシュって、あるとしたらCDNやwebサーバーチューニングとかの話です。もちろんダイナミックも持ってるからキャッシュの話ついていけるけど、URLリライト系の話も盛り上がるみたいなんですよねあっちの文化では。てことで勘所あんまりわかりませんでした前半は。

静的ファイルジェネレーターで「高速」ってのは一般にはいわゆるパブリッシュ(再構築)の話ですよね。Movable Typeの再構築はしばしば待ち時間が嫌だとかそういう話になります。ただ、エンタープライズCMSの世界では、そこあんまり話題にならないんですよね。CMS操作の重さより、公開サイトの遅さや負荷とかそっちを気にされます。ま、そういうのも含め(使われているサイトの規模や用途も含め)て文化の違いとしか表現しようがありません。ま、なんとか勝ててよかったです。

MTの再構築はまだ速くなる余地がある

今年、ある案件で公開側のサイトのダイナミック処理の速度が思ったように出ずに調査していた時に、テンプレートのコンパイルキャッシュが非効率な処理になっているケースを発見しました。以下の記事にその顛末をまとめています。

その時に「あれ? 静的ファイルの再構築処理の際の MTタグ(MTML)のコンパイルってどうなってんだっけ? って見たんです。どうもキャッシュされている気配がない。

で、少し手を入れてみたんですがうまく行かず、途中のファイルをFogBugzに投げてそこで止まってました。

MT::Builder の compile に手を入れる

MT::Builder の compile てのは、乱暴にひと言で言えば、テンプレートのMTタグをパースしてコンパイルして{tokens}を組み立てているところです。そのあと、テンプレートはコンテキストに沿ってビルドされます。MTはSQLの実行結果やビルドしたブロックやモジュールなどはマメにキャッシュしていますが、このコンパイル結果をキャッシュしていません。以下、見てもらえますか!? そう、MTタグを正規表現でパースしているんですよ、ここ。

    while ( $text
        =~ m!(<\$?(MT:?)((?:<[^>]+?>|"(?:<[^>]+?>|.)*?"|'(?:<[^>]+?>|.)*?'|.)+?)([-]?)[\$/]?>)!gis
        )
    {

ご存知の通り(知らない人も多いでしょうけど)、Movable Typeでは、再構築処理を行う際に1つのCGIへのリクエストあたり40記事ファイルずつ再構築を行い、リダイレクトを繰り返してすべてのファイルを再構築します。この40という数字は環境変数で変えることができます。

つまり、1リクエストでの再構築処理で同じテンプレートが少なくとも40回パースされるわけです。こいつを一回で済ませてしまえば。

mt/lib/MT/Builder.pm

12a13
> use Data::Dumper;
32a34
>     my $is_tmpl;
34a37,39
>         if ( $ctx->id ) {
>             $is_tmpl = $ctx->id;
>         }
73a79,88
>     
>     my $cache_key;
>     my $chached_state;
>     if ( $is_tmpl && $text ) {
>         $cache_key = 'compiled-cache-' . MT::Util::perl_sha1_digest_hex( $text );
>         if ( $opt ) {
>             $cache_key .= '.' . MT::Util::perl_sha1_digest_hex( Dumper $opt );
>         }
>         $chached_state = MT->request( $cache_key );
>     }
82a98,101
>     
>     if (! $chached_state )
>     {
>     
291a311,316
> 
>     } else {
>         $state = $chached_state->{ state };
>         $depth = $chached_state->{ depth };
>         $errors = $chached_state->{ errors };
>     }
306c331,338
< 
---
>     if ( $cache_key ) {
>         if (! $chached_state ) {
>             $chached_state = { depth => $depth,
>                                state => $state,
>                                errors => $errors };
>             MT->request( $cache_key, $chached_state );
>         }
>     }

ソースファイル(Builder.pm)

マシンスペックの高い環境では、EntriesPerRebuildの値を大きくするほどその効果が顕著になり処理も速くなります。

計測結果

このブログをエクスポートして、最新版のMT6.32にテーマ Rainier 1.22 を入れた環境を用意して計測しました。「デフォルト、すべてのファイルの再構築計測結果(ケース1)」と、「記事アーカイブのみ、EntriesPerRebuildに1000を指定した場合(ケース2)」各5回の計測結果はこちら。

計測ケースケース1ケース2
Builder.pmオリジナルBuilder.pm改良Builder.pmオリジナルBuilder.pm改良Builder.pm
1回目331243216155
2回目302254270170
3回目285234211180
4回目301255189155
5回目281245170155
合計(秒)150012311056815
結果約18%高速約22%高速

2017年、もっとMTが速くなるための宿題

あまり時間もなかったので、今日のところはこれまでです。引き続き以下のような部分を検討して実装できれば2017年、MTの再構築はもっと速くなることでしょう!

  • まずは、このコードの影響度など、問題ないかの確認・検証
  • 現状template_id 指定がある場合のみキャッシュしているが、これ以外にキャッシュできるケースがないかの検討
  • リクエストをまたがって memcachedやMTのキャッシュ(MT::Session)などへのキャッシュ

それでは、メリークリスマス、そして、良いお年をお迎えください!

米大統領選挙の速報。色分けで両陣営の優勢状況を表現している。

米大統領選挙、僅差で最後まで読めませんでしたね。普段政治のこと書いたりしないですけど(政治と野球の話はオンラインでしない主義)、今日は Web Accessibility Advent Calendar 2016 の23日目の記事です。

Accessibility Advent Calendar といえば、sukoyakarizumuさんによるこんな記事がありました。

私は ColorTester の作成者なので、本題の前に少しだけ ColoerTester について触れさせていただきます。特にこのページで結果のバラツキについてネガティブな書き方をされているわけではないのですが、ColorTesterの色の比較メソッドは W3Cのページにある計算式のそのまま、ほぼコピペです。

Xojoという開発ツールで作成しています

Function GetL (C As Color) As Double
  Dim R,G,B As Double
  R = C.Red / 255
  G = C.Green / 255
  B = C.Blue / 255
  If R <= 0.03928 Then
    R = R / 12.92
  Else
    R = ( ( R + 0.055 ) / 1.055 ) ^ 2.4
  End If
  If G <= 0.03928 Then
    G = G / 12.92
  Else
    G = ( ( G + 0.055 ) / 1.055 ) ^ 2.4
  End If
  If B <= 0.03928 Then
    B = B / 12.92
  Else
    B = ( ( B + 0.055 ) / 1.055 ) ^ 2.4
  End If
  Dim L As Double
  L = 0.2126 * R + 0.7152 * G + 0.0722 * B
  Return L
End Function

なので、テキストフィールドに値を入れて計算している以上は正しい結果を返していると思っているのですが、ピッカーから色を拾う場合に正確な値が拾えす、誤差がでることがあります(これはmacとWindowsでも少々異なるかもしれません)。(久しぶりにコードを見て確認したのですが)、ColorTesterのピッカーは、マウスポインタ周辺の小さなキャプチャを生成して、そこから色を拾っています。実はあまり知られていない(ように思う)のですが、ColorTesterでは「OS標準のカラーピッカーを使う」という設定が選択できます。スポイトアイコンをクリックする「ひと手間」が余分にかかるのですが、より正確に色を拾いたい場合、こちらの設定も試してみてください。

ColorTesteの設定で「OS標準のカラーピッカーを使う」を選択した場合

また、画像をドラッグ&ドロップで放り込む簡易チェック機能もあります。このロジックについてご興味のある方は下記の記事で紹介しています。

米大統領選挙の速報サイトに見る「色で表現したらわかりやすくね? 」問題。

さて、ようやく本題に戻ります。米大統領選挙、まだ記憶に新しく、次期大統領の発言もニュースを賑わしていますね。

この記事では、米大統領選挙の速報サイトのデザインにおける色問題について取り上げます。 米大統領選挙の速報サイトについては、以下のページに様々なデザインが紹介されていますが、冒頭で紹介した画像もその一つです。

上記のページでも触れられている通り、色分け、色の濃淡もしくは大きさなどでどちらが優勢かが視覚的直感的に理解しやすいと紹介されています。

色分けされた地図は視覚的でわかりやすいので、ついやってしまいがちなパターンですが、次に示すようにグレースケール状態にすると民主、共和党優勢、同数あたりの区別が困難になってしまいます。

考えておかなければならないのは、色弱(色覚異常とも表現されます)の人や弱視の人のことだけではありません。いまどきモノクロ?、みたいな意見は kindle が一蹴してくれましたし、例えばこの速報を見ながら会議を行っている時、モノクロ印刷した紙資料で配布されても何がなんだかわからないですよね?

同じ米大統領選挙の速報をグレースケール表示にしてみた。

このような画像は、JIS X8341-3の7.1.4.1(WCAG 2.0 の1.4.1) に適合していないことになります(適合レベルは「A」)。上部の更新時間や「当選 優勢」などの画像内の文字のコントラスト比が不足しているという別の問題もあります。

これを適合させるためには、以下のような方法があります。文字を併用する、パターンを変えるなど。

このような配慮がなされない理由として、全体的に「デザインが"うるさく"」なってしまう点が挙げられます。以下の例は、色に加えてアルファベット1文字を追加し、若干全体のコントラストを上げています(文字の大きさも当選か優勢で分けています)。

色に加えて文字を追加した大統領選挙速報地図

モノクロになっても理解できますね?

色に加えて文字を追加した大統領選挙速報地図(モノクロ版)

この「デザインが"うるさく"」なってしまう問題を回避するには、例えば文字併記版と文字のない版を切り替えられるようにする、表組みでマークアップしたテーブルを地図の下に表記する、などの方法があると思います。いずれにしても画像の alt属性に各州の結果をずらずらベタ書きで格納するのは現実的ではありませんから、マークアップしたテーブルを併記するのが良いと思います。国内で次の選挙の際にでも、このあたりに配慮された表現が見られると嬉しいですね。

この手の問題につながりがちなものを覚えておこう

このような表現になりがちなもののパターンを覚えてしまいましょう。何事も「ツボ」が大事です。非アクセシブルなものになりがちなものには以下のようなものがあります。

  • 施設・図書館などの開館カレンダー
  • グラフ
  • 地図・路線図

こいつらが出てきたら、「来やがったな!」 と思って確認する習慣を持ちましょう。

関連するかもしれない記事

MacBookProで屋外で仕事をする人

※この記事は嘘八百、根拠のない、フィクションです。実在のいかなる会社、団体、個人とも関係はありません。

via APIやサイトから情報を収集してブログアップするプログラム - みんなのお仕事相談所 [ID:497]

検索エンジンのエンジニアをしている知人(Aという)の話です。キュレーションサイト、まとめ系サイトで質の低い(web上の情報の寄せ集め、正しくない情報や著作権に配慮されていないサイトの)ページが上位表示されているという噂がネット上に散見されるようになり、社内でもさすがにこれは問題ではないかという話しがずいぶん前から上がっていたとのこと。

どうやらクラウドソーシングで安価なコストでコピペまがいの記事を大量に生産するような方法でSEOを行っているらしいというところまでは認識しており、そのエンジニアは偽名を使ってクラウドソーシングから応募してみたのだそう。マニュアルに沿って原稿を書き、チャットツールでやりとりをし、採用されるといくばくかのお金を得られるのだという。

試しにやってみようかと思ったのだが、かかる労力とお金の見合わなさに萎えたのだそうだが、マニュアルを読んでいて、これ、自動化できんじゃね と思い、試しに書いてみたのだそうな。こういうの書くのはPHPに限るんだと。

  • 検索結果からある条件でフィルタして、一次情報を集める
  • そのページへリンクしているページから補足情報を補完する
  • 「です」「ます」などのトーン&マナーをマニュアルのレギュレーションにあわせる
  • 適当に文章を倒置する、シャッフルする
  • 文章校正APIでおかしな部分を修正する

これで、記事が大量生産できるようになった。一人の生産量があまりに多いのは怪しいので、アカウントをたくさん作ることにした。今度はアカウントの管理、受発注の管理が面倒になってきた。

※この記事は嘘八百、根拠のない、フィクションです。実在のいかなる会社、団体、個人とも関係はありません。(2回目)

で、これもbotを作ればええんやとすぐに気づいた。今時のクラウドソーシングはご丁寧にAPIが用意されている。チャットツールにしても然り。

こうして、たくさんのアカウントで仕事を分散して受注し、記事を自動生成してお金を稼ぐ仕組みができあがったらしい。ただ、それをやっているうちに何だか馬鹿馬鹿しくなったのだそう。だって、自分でキュレーションメディアを立ち上げたらもっと儲かるんだから。でも、Aは自分で責任を負うのは苦手だと普段から言っているタイプで、自分ではそういうのは気乗りしないのだと言っていた。

一方その頃、キュレーションメディアを運営するベンチャーに勤める別のエンジニア(Bという)に聞いた話し。Bの会社は大量の記事を作成するためにクラウドソーシングを利用しているのだそうだが、これがまた面倒臭いことをやってるなと。なので、クラウドソーシングのAPIを利用して募集から採用、やりとりまでを自動化するプログラムを作ることを提案したのだそう。なんて事はない、あの(どのだよw)大量の発注はbotがおこなっていたのである。

※この記事は嘘八百、根拠のない、フィクションです。実在のいかなる会社、団体、個人とも関係はありません。(3回目)

あるとき、AとBが偶然IT系の勉強会の後の懇親会という名の飲み会で意気投合したのだそう。技術力はあるが責任を負いたくないAと、キュレーションサイトの裏側を知るB。二人が出した結論はこうである。

  • botにキュレーションサイトを運営させる。
  • ただし、責任は外部ライターにあるという体裁をとるために、クラウドソーシングは引き続き利用する。
  • ある程度SEO効果を得たら、会社ごと、メディアごと大手に売却する。

やれやれ、こうやって世の中は回っていたのか。AもBも現在では相当の資産家であるらしい。

※この記事は嘘八百、根拠のない、フィクションです。実在のいかなる会社、団体、個人とも関係はありません。(4回目) ←もうええわ!!

ま、仮にこんなことがあっても別に驚かんよな、とか思った次第です。さ、仕事しようぜ。

記念に貼っておく。ただそれだけ。中盤から後半は結構無理やりだけどね。この歳になって初めて bashスクリプトを書いた(sedとか書いたのも初めてだ!)。

#!/bin/bash
lftp -u usrname,password -p 21 example.ftp.azurewebsites.windows.net << EOF
cd /site/archives
mirror
bye
EOF
find . -f>../files.txt
sed -i -e 's/^[^\/]*$//g' ../files.txt
sed -i -e '/^$/d' ../files.txt 
sed -i -e 's/^/rm /g' ../files.txt
commands=`cat ../files.txt`
lftp -u usrname,password -p 21 example.ftp.azurewebsites.windows.net << EOF
cd /site/archives
${commands}
bye
EOF
rm ../files.txt

参考

Facebook

Twitter

このアーカイブについて

このページには、2016年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2016年11月です。

次のアーカイブは2017年1月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6