Prezi日本語マニュアル

Preziは、無料で使える新しいタイプのプレゼン作成ツールです。PowerPointとは発想が異なり、プレゼン全体を一枚の大きな模造紙のように見立てて、その中を移動して行くようなイメージです。

最初にこのツールを見たのが2009年の1月でした。自分と仕事をしたことのある人は分かると思うのですが、ホワイトボードの前に陣取って全体像を描きながら説明するのがスタイルの自分には、非常にシックリくるツールです。当時は日本語が使えずに利用機会は無かったのですが、その後、限定的ではありますが日本語も使えるようになったので、徐々に利用が増えていきました。

単に「ちょっとカッコイイ感じのプレゼンが作れるツール」ではなく、ツールが思考の方を引っ張る好例ではないかと思っています。今自分はフリーで仕事をしていますが、以前のようにメンバーが居る立場であれば、ロジカルに物事を考える練習としてでも使わせてみたいななどと考えながらドキュメントを作りました。

興味を持ったら是非、ちょっと触ってあきらめずに、一本プレゼンを作ってみて下さい。
きっと、プレゼンの組み立てそのものが変わると思います。

No related posts.

Tuitter_Account

名前や所在地などの設定、アイコン、プロフィール画面のデザイン変更などをプログラムから行うことが出来ます。

Twitter APIでは、特にアイコンや背景画像などのイメージを変更するのにマルチパート・フォーマットのPOSTを必要とするので、PHPから行うのは少し手間です。TuitterではHTTP通信に自前のモジュールを使っているのですが、そこに multipart の機能を追加して実装しました。OAuthの方にも対応させています。

プロフィール情報を変えられるのは、Tuitterオブジェクト作成時に認証しているユーザのものだけです。
まず、以下の例ではベーシック認証を用いて、ユーザの所在地を変更させています。

$t = new Tuitter($user, $pass);
$a = $t->getAccount();
$a->updateProf(array('location'=>'沖縄'));

次の例は、アイコンを更新しています。アイコンは、PNGフォーマットであると仮定。認証はOAuth。画像を更新する場合、URLやパスなどの所在を渡すのではなく、あくまで画像データそのものを渡すことに注意して下さい。

$t = new TuitterOAuth(
     $consKey, $consSec, $acKey, $acSec);
$a = $t->getAccount();
$img = file_get_contents('/path/to/img');
$a->updateProfImage(
    $img, 'icon.png', 'image/png');

Related posts:

1. [Tuitter] OAuth認証機能を追加

TuitterをOAuthで使う
TuiBotter環境設定

あまり難しく考えないで、サクッと。おかげで外部ライブラリが結構な環境依存になってしまいましたが。

まずOAuthクライアントですが、自作するのも手間だったのでPECLのOAuthを使うようにしています。
最初はtwitteroauthなど配置するだけのライブラリを使おうかとも思ったのですが、いずれにしろ libcurl が必要ですし、ライブラリの場所を指定する手間も発生します。おまけに PECL/oauth を入れると OAuthException の定義が干渉しあって twitteroauth は動かなくなってしまうことが判明したので、思い切ってPECLのみの対応で割り切りました。

実装は単純で、従来の Tuitter クラスを継承して、新たに TuitterOAuth というクラスを作ります。コンストラクタの引数だけが異なりますが、インスタンス化してしまえば以前と全く同様に使えるという寸法です。
つまり、以下のようなコードがあったとすると

$tuitter = new Tuitter($user, $pass);
$tuitter->sendMessage("Hellow");
$user = $tuitter->getUser('nao58');
    :

最初のインスタンス作成部分を修正するだけでOAuth対応になります。

$tuitter = new TuitterOAuth(
     $consKey, $consSec, $acKey, $acSec);
$tuitter->sendMessage("Hellow");
$user = $tuitter->getUser('nao58');
    :

TuiBotter側に至っては、INIファイルの記述を書き換えるだけで対応完了です。

ただ、ベーシック認証に比べると複雑なことをやっているため、動作がちょっと重くなったような…ま、ここはトレードオフとしてください。

Related posts:

1. [Tuitter] Twitterのプロフィール設定変更機能を追加
2. [TuiBotter] Twitterボット専用PHPフレームワーク
3. [Tuitter] オブジェクト指向型Twitterクライアント

Mandlin – QuickSilver風 ウェブナビゲーションツール

詳しい使い方はリンク先を見ていただくとして、YubNub+QuickSilverといった風の、様々な検索エンジンをキーボードベースで操ることのできるツールです。

自分が欲しくて作ったものなので使い勝手にはそれなりに満足していますが、なにしろ呼び出しにマウスを持ってクリックしなければいけないのが、なんとも残念な点で。せめてポップアップを開くAPIがあればショートカットキーもどきも出来なくは無いのですが… ポップアップではなく、コンテント・スクリプトでウインドウから描画してタブのコンテンツ内で表示させることも考えましたが、他人の家にあがりこむような感じにちょっと抵抗があったので、とりあえず由としておきます。

作成にあたって気づいた点など、徐々に リファレンス の方で更新していければと思っています。

Related posts:

1. [Chrome Extension] APIリファレンスの日本語訳

今回、勉強がてら公式のAPIドキュメントを日本語訳してみたので、公開しておきます。

Google Chrome Extension API 日本語リファレンス

馴染みのあるWeb技術ばかりで出来ているので、チュートリアルに沿ってひとつ作ってみれば、簡単に理解できました。あとはガイドを斜め読みしながら出来ることをおさえておき、作りながら必要にあわせてAPIリファレンスをひいてみる感じで。

まだ出来ることも限られていますが、プロセスが分かれていることもあり軽量で快適です。なかなかFFから移行できずにいたのが、おかげで最近はすっかりChromeメインで使っています。

というわけで幾つか作ってみたのですが、どうやら ギャラリーページのバグ でアップロードできず… いずれ問題が解決したら公開しようと思います。

作成途中で気づいたTipsなどもあるので、オリジナルのコンテンツも追加していく予定です。

Related posts:

1. [Chrome Extension] QuickSilver風の拡張機能

TuiBotter – Object-oriented PHP framework for Twitter-Bot

最大の特徴は、イベントドリブンでボットが書けること。例えば「フォローされたら、フォローバックする」というコードを書くには、「フォローされた」というイベントに渡ってくる「フォロワー」オブジェクトに対して、「フォローする」というメソッドを投げるだけで実装できます。
実際にコード例を見ながら、簡単に説明します。

class GreetingBot implements TuiBotter_Event_BeFollowed
{
  public function eventBeFollowed(Tuitter_User $user, Tuitter $tuitter)
  {
    if(!$user->isFollowing()){
      $user->follow();
      $user->sendDM('フォローありがとう!');
    }
  }
}

基本的には、このBehaviourという「振る舞い」をあらわすクラスを作ることが、そのままボットの人格を作ることになります。

1行目: ボットの名前(GreetingBot)と、必要なイベント(TuiBotter_Event_BeFollowed)
3行目: 「フォローされた」イベント
5行目: フォローしてきたユーザを、こちらから既にフォローしていなかったら…
6行目: フォローする
7行目: DMを送る

これだけで完了です。

イベントは他にも「TLが更新された」「自分が言及された」「自分の発言がRTされた」など種々あり、これらを自由に組み合わせることでボットの人格を比較的容易に形成できます。

動作するのは、PHP5以上。パースにはXMLを用いましたので、json_decodeが含まれていなくても動作します。
ただし、将来的に検索モジュールを追加した場合、必要になるかもしれません。

Related posts:

1. [Tuitter] OAuth認証機能を追加
2. [Tuitter] Twitterのプロフィール設定変更機能を追加

で、ボット用フレームワークを作るにあたって結局はクライントライブラリが必要なのですが、どうもAPIコールを媒してくれるだけの手続き型ライブラリが多くてシックリ来ない。というわけで、クライアントライブラリの作成まで遡ってしまったのが、この「Tuitter」です。

既にボット用フレームワークも完成しているのですが、テストとドキュメンテーションがまだで、とりあえずライブラリ単体でのリリース。
詳細は、次のドキュメントページを見てください。

Tuitter – Object oriented Twitter client for PHP5

ちなみに、いかにもタイポのようでダサいライブラリ名ですが、ニュージーランドに住んでいた頃によく近所で見かけた「Tui」という鳥の名前からつけました。
黒くてギャーギャーとやかましく啼く鳥で、胸のあたりだけ白いのが特徴。ちょうどオールブラックスのユニフォームのようでもあって、ちょうどいいかなと。(何が?)
オークランドには同名のビールもあり、国鳥ともいえるほどポピュラーな鳥です。

フレームワークの方も、近日中に公開予定。
気づいた点などあれば、指摘いただけると幸いです。

Related posts:

1. [Tuitter] Twitterのプロフィール設定変更機能を追加
2. [Tuitter] OAuth認証機能を追加

商業的利用やプロモーションのためにツイッターを利用する行為は許可されています。興味のあるユーザーとの間に、互いに価値のある関係を作るためにツイッターを利用する場合などです。ところが、自分のアカウントやサイトなどに注意を引くためだけに、ユーザーをフォローする行為はスパムとして扱われる可能性があります。まったく同じものを宣伝、または販売促進するためにたくさんのアカウントを登録することもスパムとして扱われる可能性があります。また本物ではない＠付きのつぶやきを投稿することや、検索結果に表示するためだけに投稿することもスパムとして扱われる可能性があります。さらに、つぶやきに関係のないリンクを貼ったり大勢のユーザーがあなたをブロックした場合などもスパムとして扱われる可能性があります。

ここにはハッシュタグに関する記述はありません。

もう一息、英語の方のヘルプフォーラムを調べてみたところ、それらしいものを見つけました。これによると、次のような行為がイエローカードに当たるようです。

• 同じ、或いは似たような呟きを繰り返す。
• 同じ、或いは似たようなリンクを繰り返し貼る。
• 同じ話題の単語、或いはハッシュタグを乱用する。
• 自動化された呟きや返信を送る。
• キーワードを基にした似たようなメッセージを送るボットやアプリケーションを使う。
• 複数のアカウントから似たようなメッセージを投稿する。
• 頻繁にフォロー/フォロー解除を繰り返す。

自分はハッキリは言われませんでしたが、ラグビー関連の話題を持ち出す際に慣例として使っていた #rugby が「同じハッシュタグの乱用」に当たったのではないかと思います。興味の無い人が読まなくて良いように呟きの先頭につけていたのですが、今後は止めにします。(アカウント分けた方が良いのかな…)
なお、「状況を改善して欲しい」とお願いしたところ、今朝から検索にヒットするようになりました。

どうやらTwitter検索八分は、完全にスパムアカウントとして凍結する前の「執行猶予」のようなもののようです。
「別に検索されなくてもいいや」としていると、場合によってはアカウント自体を停止されてしまうかもしれません。
気になる人は、エゴサーチで自分の発言がヒットするか試してみることをお勧めします。

No related posts.

「F5」でXHR通信結果が更新されない

通常、キャッシュが設定された外部ファイル取り込みは、その期限が来るまでは再通信されません。しかしブラウザをF5やCtrl+rなどで明示的にリロードした場合はその限りではなく、ファイルの再取得が行われるのが一般的です。
しかし、キャッシュ指定の条件によっては、XMLHttpRequestを用いた、いわゆるAjax通信時が発生しなくなってしまうとHttpWatchの記事で伝えられました。
これを検証するために、簡単なプログラムを作ってみます。

検証プログラムの説明

まずは、取り込まれるjsファイルを用意します。
サーバサイドで毎回ジェネレートされる、現在時刻を指定された要素に出力するだけのスクリプトです。

検証用スクリプト

呼び出す度に日時が更新されることが分かると思います。

そして必要なのはキャッシュコントロール。
パケット監視などが出来る人は見ていただけばわかるのですが、パラメータに応じて次のようなヘッダを付与します。

cache=1

キャッシュ有効。Expiresを30日後にし、Cache-Controlのmax-ageも30日間に設定します。

cache=-1

キャッシュ無効。Expiresを30日前にし、Cache-Controlのmax-ageは0とします。

cache=0

キャッシュ指定無し。ExpireもCache-Controlも指定しません。

ついでに、画像も用意してみました。同様にサーバサイドで現在時刻の画像を作成して返します。キャッシュ制御も同じです。

検証用画像

これを、テスト用のHTMLで取り込みます。
スクリプトは、scriptタグによる単純な取り込みと、XMLHttpRequestによるAjax通信の2種類。画像はimgタグで指定しています。
前述の3種類のキャッシュ制御を行うページは、次の通りです。

• キャッシュ無効
• キャッシュ有効
• キャッシュ指定無し

これで、ページを開いた時の時刻(正確には、サーバがリクエストを受け付けた時刻)が表示されるはずです。リロードや再訪問時に、キャッシュが効いていれば日時はキャッシュされた時のままになります。

順に見ていきましょう。

キャッシュ無効の場合

いずれの場合も期待通り、キャッシュは全くききませんでした。
ページ遷移を行った場合も、F5でリロードした場合も、全て最新に更新されます。

キャッシュ有効の場合

動作が分かれました。
通常にページ遷移を行った場合は、Opera10を除き一律にキャッシュが使われる期待通りの動作です。(Opera10はまだbetaのため、最終的にどういった仕様になるかは不明です)
F5などでリロードを行うと、画像やscript要素で取り込んだものは、いずれも再読み込みされます。
しかしXMLHttpRequestでの通信は、ChromeやFFでは再通信が行われるのに対し、IEとOpera9ではそのままキャッシュが有効になってしまいました。これはCtrl+F5のようなスーパーリロードを用いても、変わりません。

キャッシュ指定無しの場合

かなり無軌道になっています。Operaに至っては、通常のページ遷移でも動作に違いが出てしまいました。

ETagについて

StevesSuders氏の検証ではETagについても含まれています。
今回は検証結果を見やすくするために、レスポンス304については確認していません。
氏のページによれば、Safari4はIf-Modified-Sinceを送らずに常に再送信されてしまうようです。

まとめ

1. Expiresを指定しないことは、動作を全く制御しないのと同じこと。可能な限りきちんと、用途にあわせてキャッシュの制御を行うべきです。
2. Ajax通信でキャッシュをされたくない場合(多くの場合、この用途でしょう)、Expiresを過去に指定してキャッシュを無効にしましょう。
3. 或いは、通信にエポックタイムのようなユニークなIDをパラメータに付与し、キャッシュできないようにするのも良い方法です。
4. Ajax通信をキャッシュしたい場合、Expiresをキャッシュしたい期間、きちんと指定しましょう。ただし、その際にはF5でリロードしても更新されないブラウザがいることを知っておきましょう。
5. Operaを対応ブラウザにするならば、バージョン10がどのような仕様になるか注意しておきましょう。

No related posts.

Bytecode cache

バイトコードキャッシュを用いずしてパフォーマンスを語る無かれ(超意訳)

If you care about performance and don’t use bytecode cache then you don’t really care about performance.

というほど、まず重要としているのがこの部分。
まずは(Zend社員としては当然) Zend Serverの導入検討を奨めていますが、自分でPHPをコンパイルできる環境であるならばAPCなどを使えば良いでしょう。ちなみに、このblogを動かしているPHPもAPCを使っています。GUIの管理画面もあってステータス管理も簡単。キャッシュヒット率99.9%。プログラム中からmemcache的に変数を格納したりも出来るし、非常にありがたいモジュールです。

Profiling

最適化する前にプロファイルを!(意訳)

Profile you code before you start optimizing it!

どの関数がボトルネックになっているのか、ちゃんと把握してからチューニングしましょうということで。そのためのツールとしてZend Studio/DebuggerやXdebugが挙げられています。

Caching

殆どのPHPは”shared nothing”でインストールされているわけで、リクエスト処理の終了と同時に作業内容は全部飛んでしまいます。これは処理の複雑さを回避するなどのメリットは大きいのですが、パフォーマンス的にはデメリットですよね。繰り返し処理はキャッシュに入れて、いいとこどりにしちゃいましょう。(意訳)

Most PHP installations run in “shared nothing” mode where as soon as the request processing ends, all the data associated with the request is gone. It has some advantages, but also one big disadvantage – you can not preserve results of repeated operations. That is, unless you use caching.

実際、DBへのアクセスや複雑な計算のような大きな処理はもちろん、XMLによる設定ファイルをパースしておくような簡易な処理でも、アクセス毎に発生するようであればDisk I/Oとあわせてトータルでかなりの軽量化になります。
キャッシュ先としては memcached や前述の APC などが挙げられます。用途によってはHDDでも良いでしょうが、基本的には高速なメモリでのキャッシュを考えるべきです。ポスト元では他にも、Zend Serverに含まれたZend Frameworkによるキャッシュ機能を奨めています。

Optimize your data

通常、PHPアプリケーションで最もコストのかかる処理は、データベースやファイルシステムのような外部データや、ネットワークにアクセスすることです。クエリーを減らすこと、データベース構造の改良、ファイルシステムへのアクセス減、データ取得のためのサービス呼び出しを複数回行わずに1度でまとめるなど、これらの最適化に注力しましょう。更に言えば、システムコールトレーサ(Unixであれば strace、Windowsであれば Process Explorer など)などを使い、スクリプトが呼び出しているシステムコールを減らせないかどうか検討しましょう。それらの全てを除くことは不可能だと思いますが、いくつかは検討の余地があるでしょう。(意訳)

Usually the most expensive places of the PHP application are where it accesses external data – namely, database or filesystem or network. Look hard into optimizing that – reduce number of queries, improve database structure, reduce filesystem accesses, try to bundle data to make one service call instead of several, etc. For more advanced in-depth look, use tools like strace (Unix) and Process Explorer (Windows) to look into system calls your script produces and think about ways to eliminate some of them. You would not be able to eliminate all of them but each of them is a worthy target.

ほぼ、そのまま。
下手にPHPでの処理をいじるより、RDBのチューニングを行った方が遥かに効果的なことは、非常によくあります。また、先述のキャッシュを使うような工夫は、ここにも繋がります。

Don’t try to outsmart the engine

世の中には”Tips”と呼ばれる「ああしたほうが速い」「こうすると遅い」というような話題があります。しかし特にビギナーのうちは、そういったものに惑わされない方がいいでしょう。十中八九は何も変わらず、残った1つも手持ちのコードに容易にあてることは出来ないか、費やした時間ほどの価値は無いというのがオチでしょう。確かにopcodesを軽くしたり、lookupsを減らしたりするような手法はありますが、他の全ての条件が整っていなければ無意味です。加えて、こういったアドバイスのいくつかは、寧ろコードを遅くしたり、堅牢性やセキュリティを失わせてしまったりします。特に初心者は、こういったトリッキーな手法に手を出さない方が良いでしょう。(意訳)

There are a lot of “tips” floating around about which constructs in PHP are faster or slower than others. I think you can safely ignore all of these tips, especially if you’re a beginner. Odd are, 9 cases out of 10 they won’t give you any improvement at all, and in the remaining one case it will be either not applicable in your code or not worth the time spent on it. Yes, there are ways to save couple of opcodes and remove couple of lookups here and there – but unless you’ve already done with all of the previous steps it is not worth it. And some of the advice out there will actually make you code slower, less robust and less secure without you even noticing. So I think for the beginners is better to stay away from trying to outsmart the engine altogether.

この辺が恐らく、Googleの(そして、その他「高速化Tips」と銘打つほぼ全ての)アドバイスに対する反発心に繋がっているのでは。
王道をきちんとおさえるのが近道というのは、何にでも言えることですよね。

Benchmark in real life

ここまでに話題に挙げたアドバイスの多くは、証拠としてベンチマークを使っています。問題は、これらのベンチマークはいつも、ほんの数行の部分的なコードで書かれていることです。しかしながら、実際に実行されなければいけないコードは大きなアプリケーションで、そのような一行コードではありません。(意訳)

Many of the advices I mentioned above have benchmarks as a proof. The problem is these benchmarks always test only a short piece of code. However, you would not be running that one-liner – you would be running the whole big application.

これに続けて筆者は、「勝ち馬を予想するために真空状態でのモデルを使う科学者のジョーク」を引き合いにだしています。
確かに条件が複合的に絡む場合は多く、数行のベンチマーク結果を妄信することを危惧する必要はあります。しかし、現実に「A/Bどちらの方法が速いのか?」と確かめるには、むしろ他の要因を取り払って調べる必要がある場合もあるように思います。ここに関しては、「最終的なパフォーマンスチューニングは、実際のアプリケーションを用いるべき」というアドバイスと捉えれば良いのではないでしょうか。

Leverage the extensions

あまりにも自明のことを言うようですが、それでもPHP extensionで可能となる機能を重複して作っているようなコードを数多く見かけます。PHPには多くの関数があるので、誰か他の人がやっていそうなものを作る前に、マニュアルをチェックしてみて下さい。DOM/SimpleXML拡張も、JSONパーサも、SOAP送受信のための拡張なども、利用することができます。serialize/deserialize関数が使えないのでなければ、独自のものを作ったりするのは止めましょう。
もしパフォーマンスが非常に重要で、あなたがCプログラムを書けるなら(PHP初心者が、全てにおいて初心者だということを意味しませんよね)、独自のPHPエクステンションを作ることを検討してみてください。それは、それほど難しくはありません。(意訳)

That seems too obvious, but I have seen a lot of code that duplicates functions available in some PHP extension. There are a lot of functions in PHP and if you do something that others may have done before, check in the manual. You have DOM/SimpleXML extensions for XML, JSON extension for JSON, SOAP extension for doing SOAP, etc., etc. Do not create custom serialization/deserialization if serialize()/deserialize() would work for you.
If you have some very performance-sensitive bit of script and you can do C programming (beginner in PHP doesn’t mean beginner in everything , consider even making your own extension, it’s not that hard.

Avoid extra notices/errors/etc.

PHPでエラーを抑止することが大変だったとしても、noticeやstrict notice、warningなどが出ないコードを書くよう挑戦してみて下さい。その際、全てのエラーが出力されるように設定したいと思いますが、実運用環境ではエラー表示を決してしないようにしましょう。恥を大っぴらにするだけですから。(意訳)

Even suppressed errors have cost in PHP, so try and write your code so it would not produce notices, strict notices, warnings, etc. You may want to enable logging of all errors to examine that. Never enable displaying errors in production though – it will only lead to a major public embarrassment.

変数の未定義や配列に添え字が無い場合など、noticeエラーを出しておくことは、タイポなどの単純で気付きにくいバグを回避するのに有効です。ちゃんと無くしましょう…と心から思うのですが、一方で「それってスクリプト言語の手軽さ」を失うことでもあるのかなと考えてしまいます。
いっそ変数型宣言必須の”strict mode”みたいなのが欲しいような。

Use php.ini-production as a start

もしphp.iniの設定をするのに、PHPのソースコードに含まれる php.ini-production を参考にしましょう。include pathなど幾つかの項目は変更が必要でしょうが、土台にするには最適です。(意訳)
If you need a set of php.ini settings which would not hurt your performance and not break anything, look into php.ini-production in PHP source. You may need to change a couple of details (e.g. include path) but it’s a good starting point.
マニュアルによると、PHP5.3.0からはphp.ini-development(開発環境用)、php.ini-production(運用環境用)の2つが同梱されているようです。自分はまだPHP5.3を落としていませんが、以前のrecommendedなどとどの辺が違うのか、確認してみようと思います。

Use big realpath cache

リアルパス・キャッシュは、ファイル名や相対パスからユニークなフルパスを取得する際に非常に有用です。初期設定ではこのキャッシュサイズは16kですが、多くの長いパス名のファイルを扱うのであれば、この値を増やすのが良いでしょう。これはディスクアクセスという重い処理を軽減します。(意訳)

Realpath cache is very useful for the engine when it tries to find the unique full name of the file from just filename or relative path. By default, it’s 16K but if you have a lot of files with long pathes, it’s better to increase the size – it would save the expensive disk accesses.

この機能はPHP5.1から実装されたものですが、ちょっと大きい規模のアプリケーションになると、16kという値はすぐに超えてしまうかもという話は、よく聞きます。よほどメモリに困窮していなければ(そんな場合は既にパフォーマンスを云々言っていられないと思いますが)、64kくらい確保してしまうのが良いようです。

最後に、次のように締められています。

ここに挙げた以外にも、もっと多くのことが挙げられると思いますが、既にちょっと長くなりすぎました。一旦ここで終わりますが、あなたの考えをコメント欄で追加してくれると嬉しいです。

There are probably more things that could be said, but this post is pretty long already, so I will end it here and you are welcome to add your opinion in comments.

同じ言葉で、終わりたいと思います。

No related posts.