Chief Technical Officer

本広告は、一定期間更新の無いブログにのみ表示されます。
ブログ更新が行われると本広告は非表示となります。

アンロックするまでに使用するテーブルを一通りロックしなければいけないらしい。

とりあえず一個だけロックみたいな使い方はできない模様。

マニュアルにもちゃんと「LOCK TABLES の使用時には、使用するテーブルをすべてロックし、・・・」って書いてありました。

おそらくこれは書き込みをバッファしているからでしょう。マニュアルにもUNLOCKのときにフラッシュと書いてあるので、バッファしているテーブルとそうでないテーブルの間で不整合が起きないための仕組みかもしれません。

久しぶりの更新です。

早速本題ですが、

知り合いが流しそうめんを企画していて、その際に竹が必要なようです。どなたか譲っていただける方いらっしゃいましたら、コメント欄にてご連絡お待ちしています。

ねむいねー。今日はあついねー。

右手の小指にマウスダコができそうです。


毎回悩むのだけれど、ホームページのコンテンツ流し込みはどんな方法が効率的だろうか。
・手打ち
・正規表現
・プログラム組む

本当は汎用的なプログラムができればいいのだけれど、世の中そんなに甘くないわけで、プログラム使うとしても毎回改造は必要だろう。

正規表現は便利なんだけれど、条件分岐とかまで正規表現で組むのは面倒。

手打ちはちょっとアナログすぎだよね。


結局今回は、エクセルでフォーマット整えた後、CSVで出力して正規表現でぐわぁーっと置換してみた。結論としてEmEditorは素晴らしいアプリケーションだと思う。

ちなみに、EmEditorを開発されている会社はつくばにあるのです。

僕はだいたいメールを処理すると捨てるのですが、一日にどれくらいメールを捨てているのか見てみました。

まぁ中にはメルマガとかプレスメールもあるのですが、それでも200通以上捨てていることにびっくり。迷惑メールはフィルタに引っかかってそもそもローカルまで配送されることはないから、実際にはもっとメールは届いていることになりますね。

正式にリリースされたので使ってみた。

なんか少し遅くなったような気がするなぁ。タブの切り替えにすこーしもたつく感じ。

インターフェースは、新しいデフォルトスキンは見づらい。なれもあるかもしれないけれど、9デフォルトのときの方が好きかな。ということで、9っぽいスキンをダウンロードして変えてみた。

M2のスペルチェック機能は不要かな。名前のローマ字表記とかにも赤線が引かれてしまうので。それにスペルチェック切っておいた方が速そうじゃん？スペルチェックは、設定ウィンドウ>詳細設定タブ>閲覧カテゴリ>スペルチェック、で無効にできる模様。ってかなぜ「閲覧」のカテゴリなのか。

Yahoo!はブラウザによってコンテンツ内容が違うのか。

Opera10だと広告も表示されないシンプルな検索結果に。Opera10のBetaが出ていたにも関わらず修正していないYahoo!もどうかと思うが、個人的には邪魔な広告もないししばらくこのままでいいかなぁって感じ。

前回の記事から今頃になってですが、そういえば、クックパッドのレスポンスがめっちゃ早いのを思い出しました。

クックパッドのシステムはレスポンスに0.2秒を目標としているようです。実際にアクセスしてみれば分かりますが、レスポンスめっちゃいいです。特に個別のレシピのページはサクサクしています。

せっかくなので、技術的部分に触れてみます。

○ 残念ながらHTMLやJavaScriptなどのフォアグラウンドの部分はまだ最適化の余地がありそうです

○ 画像の読み込み先のドメインが複数に分散されているので、並列ダウンロードができます。これはブラウザが通常1ドメインから2個まで(たしか、記憶では)しか並列ダウンロードしないのですが、ドメインを分散させるともっと多く並列ダウンロードさせることができます。

○ 個々のレシピページの読み込みが速いのは、おそらくページをキャッシュしているからでしょう。レシピなんてものは一度投稿すれば内容はほぼ変わらないですからね。つくばちゃんねるショップも同じような高速化手法を使っています。


ユーザーもあつめ、システムもしっかりしている。素晴らしいですね。

つくばちゃんねるブログ内でパフォーマンスに触れている記事があったので、ちょっと僕もパフォーマンスについて触れてみようと思います。

まず、元ネタ
サイトパフォーマンス - viviのホームページ作成奮闘記



viviさんも言うように、サイトのパフォーマンスはユーザーの使い勝手に大きく影響します。特に読み込み速度はだれもが感じるストレスの指標でしょう。

ちなみに、僕視点ですが、Googleの検索結果からアクセスするページが、おおむね3秒以内で読み込みが始まらない場合は、読み込みを中止して別のサイトを訪問します。具体例をあげると、最近某Q&Aサイトが検索結果に良く引っかかりますが、このサイトは肝心のQ&A部分が表示されるのに、10秒くらい(遅いときはもっと！)かかります。なので、検索結果でこのサイトが検索で引っかかってもアクセスしないことが多いですね。

ちなみに、某Q&Aサイトが重い原因は、システム自体の重さと、広告配信JavaScriptですね。

JavaScriptについては、読み込み場所を検討しなければなりませんね。JavaScriptはHTMLの記述された位置で必ず読み込まれ、それ以降のコンテンツはスクリプトが読み込み完了するまでロードされません。なぜならスクリプトの中にHTMLを吐きだすコードが含まれているかもしれないからですね。JavaScriptの読み込み位置で最適なのは

タグの直前。そうです、すべてのHTMLが読み終わったあとなんですねー。この変更だけで体感的にかなり読み込みスピードが速く感じられます。

システムについては、プログラマーが何とかしなければなりませんね。プログラムの中身は見れないので、何が原因で、どう対策すればいいのか分かりませんが、DBあたりがボトルネックになっていそうなので、このあたりを分散化するなり、SQLを最適化する必要がありそうです。



ちなみに、つくばちゃんねる求人・つくばちゃんねるショップは、HTMLのレスポンスが開始されるまで(プログラムがページを出力し始めるまで)に0.5秒(CPU: 1GHz、MEM: 512MBの貧弱サーバーで)、ページの描画が完了するまで5秒程度(十分に回線が早い環境で)を目安としています。一応スケーリングも考えてシステムを作っているので、アクセスが集中するようになったらサーバーの分散化が行えるようになっています。

残念ながら、つくばちゃんねるブログはウチが開発したシステムではないので、パフォーマンスが悪くても内部はいじれないですし、実際ちょっとレスポンスが悪かったり(特に広告部分！)もします。



ウェブサイトって見た目やコンテンツは重要ですが、それを支えるシステムやHTMLコードにもちゃんと気を配ってあげないといけないと思います。とりあえず、やっつけで作ったウェブサイトは、もしヒットするサイトになったらあとあと恐ろしいことが待っています。この記事を読んでいるHTMLコーダー・プログラマーがいたら、そのあたりも考慮してほしいですね。

今J-WAVE Brandnew-Jを聴いています。

スポンサーがCHINTAIで、番組の間にラジオCMが流れているのですが、これがちょっと面白い。CHINTAIのCMは、以前から、うまいなぁと思っているんですよね。

内容を書くのは面倒なので、どうしても聞きたい人は各局ラジオで聞いてもらうとして。ものとしてはラジオらしくイマジネーションを掻き立てる造りになっています。聞いていると情景が良く想像できるような感じ。

ラジオは想像力が豊かになりますね！

Perl高速化のためにmod_fcgiを入れたのですが、普通のPerlプログラムが動かーん。

で、CGI::Fastを使うようにしたら解決した。単純にFastCGI入れたからってPerlそのまま使えるわけではないのですねー。勉強になった。

原理的には、FastCGIはCGIプロセスを再利用することで高速化をするため、プログラム側も再利用に対応できるよう、無限ループでリクエストが来るのを待っていなければいけないということなんですね。

ついでに、同様の理由のため、プログラムの開発・デバッグをするとき、新しいプログラムを走らせる前に古いプロセスを殺さないと、残っている古いプロセスが動いちゃいます。CGI::Fast使っていても、通常CGIで動くので、まずはそこでデバッグしないとですね。

MTEntriesに抽出条件を追加するプラグイン。

24時間くらい費やしましたとさ。

MT4からウェブページの機能が付いていますが、これはもともとあるエントリーをウェブページ向けにオーバーライドしている感じの機能です。

内部コード的に、MTPagesはフォルダ->カテゴリの変換を行ったあと、さっきの記事で触れたMTEntriesへ飛ばされています。

つまり、MTPagesの抽出条件用のモディファイアはMTEntriesのモディファイアで実装すればいいわけですね！

うがー、なんでMTの内部コードまで読むことになるのだ。

ということで、MTEntriesの内部コードを読んでみました。大体の処理の流れがつかめたぞ！

ちなみに、MT標準のタグは「lib/MT/Template/ContextHandlers.pm」でほぼ実装されています。500kb以上のコードです。この中を読めばMTのタグを制覇できるわけですね!!(読みたくないけど)

で、結局何をしたいかというと、MTEntriesのモディファイアに独自のフィルタリング条件を設定できるようにしたかったのです。そして、さすがMT、ちゃんと独自のフィルタを設定できるようなコードになっていました。

これから、どうやってプラグインでフィルタを追加するかを追うところです・・・。

最後に気が付いたのですが、こちらの記事で大まかな流れが説明されているではないですかorz。WWWの世界は広いですね。

MTでパブリッシュされるURLまたはパスをテンプレート内で取得することはできないのだろうか。

一応、MTFileTemplateを使うと、アーカイーブマッピング中における%cなどのマッピング文字列に設定される値を取得できたりするのだけれど、結局最終的にはどんなパスに出力されるのかを取得できない??

アーカイーブマッピングでファイル名を直接指定している場合に、そのファイル名を取得したいのですよ。というか、複数のアーカイーブマッピングを指定している場合に、アーカイーブマッピングごとにテンプレートをカスタマイズしたいわけです。

まぁアーカイーブを複数作成して、それぞれにマッピングを記述すればいいのだけれど、分け合って現在の仕様だと、アーカイーブテンプレートが多くなりすぎてしまう。

さて、どうしたものか。眠すぎる。

おぉ～、筑波大学のスパコンもやりますなぁ。

＜円周率＞２兆５７６９億けたまで計算　筑波大、ギネス申請

コンピュータの性能もさることながら、3日程度で2兆ケタ計算できるプログラムもすごいわ。

ちなみに、世界記録を樹立した高橋先生はSuperPiの開発者でもあります。解析学I(1の方は一発で単位取れましたよ、1はね)は高橋先生にお世話になったものです。

さっきのような、じわ～っとくる地震、いやですねぇ。どこまで大きくなるんだろう…、ていうドキドキが続きますからね。

でっかい地震が来るなら、いっそのこと、どーんって来たほうがドキドキしている暇がなくていいかも(笑)

Value Domainでドメインを移管するとき、急いでいる場合は「割引価格で移管」のリンクから手続きしない方が良いです。

というのも、割引価格の方は上位レジストラがKeySystemsという会社のようで、KeySystemsは何かと手続きがゆっくり内容です。今回もあるドメインの移管でトータル10日間を費やしました。承認メールでActivateしてからは6日ほどかかっています。

ちなみに、通常価格の方は上位レジストラがeNomです。eNomはコントロールパネルが用意されているようで、仮にValue Domainが吹っ飛んじゃっても何とかなりそうな感じです。どうせ割引価格で取得したってほんのちょっとの金額の差しかないのだから、やはりeNomの方で取得しておいた方がいいですね。

MT::PluginDataを利用してCMS外からプラグインの設定データを読み込む方法。

・MTオブジェクトをnew (ぶっちゃけ、これが重いのでnewしたくないのだが・・・)
・MT::PluginDataをload(PLUGIN, KEY)してオブジェクトを取得。
・オブジェクトのdataからハッシュリファレンスを取得。
・$data->{"setting_name"}で設定値を取り出し

引数は以下の値を設定すれば良い
PLUGIN：設定を読み込みたいpluginオブジェクトのkey値
KEY：configuration。ブログごとに設定できるプラグインの場合、configuration:blog:N(NはブログID)

MovableTypeのプラグイン作成ちゅう～

サムネイルの生成にMT::Imageを使用しようと思ったのだけれど、newしてもエラーで止まっちゃいます。なんでだろな～とMT/Image.pmを覗いてみると、ImageDriverの設定を読み取っている。確認のためにMT->config->ImageDriverを確認してみたら空文字ではないですか！リファレンスにはデフォルトはImageMagickって書いてあるのになぁ。

で、mt-config.cgiにImageDriverディレクティブを設定してみたら動いた！

簡単に書いているけれど、これに2時間ハマってしまったんです。MTは優秀すぎてわかんねよ！

何か投稿してみるテスト

とりあえずネットワークがつながることだけを考えてLANを構築するとこうなります。



パソコンからファイルサーバーへ大量のファイルを転送するときのグラフ。パソコンとサーバーの間にはスイッチングハブが3段挟まっています。すべてのハブは100Mbpsのタイプで、ふつーに電気屋さんで売っているやつです。

ボトルネックとして考えられるのはやっぱりハブではないかと。パソコンとサーバーは1GbpsのNICが付いているので。特に原因でありそうなのがルーターについているハブ。

これ見て思うのですが、ネットがいくら早く接続できるようになったとしても、ネットに接続する前のLAN内でスループットの低下があるようだと、高速ネット回線の恩恵が受けられないよねってこと。ひかりoneみたいにギガ接続できるなら、LAN内のハードウェアもしっかり検討しないとだめですね。