MongoDBでのシェルとは、PostgreSQLで言うところのpsqlコマンド 、MySQLのmysqlコマンド、 OracleのSQL Plusみたいなもの。MongoDBに入っているデータを直接見たり、更新したりする場合に使う。ただし、SQLは使わずに、Javascriptを使う。
なんとなくMongoDBの雰囲気が感じられると思う。
MongoDBの翻訳については、 こちら参照。
いまいちそのWikiが使いにくいのだが、右の方のNavigate Spaceというところからツリー構造になってる。とりあえず終わってるのは、以下のドキュメントだけ。
- Developer Zone (の一番上のところ)
- チュートリアル (Tutorial)
- 開発者FAQ (Developer FAQ)
- コレクション (Collections)
- 制限付きコレクション (Capped Collections)
翻訳することになった経緯としては、このブログでドキュメントを(翻訳ではなく)部分的に紹介しようとしたら、劣化コピー(&部分的に翻訳)になってしまいそうだったので、「どうしよーかなー」という感じで、MongoDBの中の人とメールしてたら、編集用のアカウントができていた、という感じ。
基本的に、翻訳はめんどくさいし、これは需要もたいしてなさそうだし、その上あまり自分の得にならないので(得意でもないし)、面白そうだなというところだけ適当にやるつもり。MongoDB自体、今ちょっと興味あるだけなので、そのうち興味なくなる可能性もかなりある。そしたらその時点で翻訳も止まる。
チームでの翻訳もめんどくさいので誰かに協力を頼むつもりはないけど、もしページ単位で翻訳した人がいれば送ってもらえればそのまま反映はする(またはMongoDBに、アカウントくれ、と言ってアカウント作ってもらってもok)。ちゃんとWiki形式で書いてね。英語のページから原文をWiki形式で取ることができる。後ライセンスとか権利とかだるいことはMongoDBの人に聞いて(これみたい)。
もし万が一、引き継ぎたいという人や、「俺が仕切る」的な人がいたら連絡してください。私が訳した分は捨ててもいいですし、そのまま使っても、修正しても、何でもいいです。
なんか、やる気ないオーラを全面に出してるけど、それなりにはやる。とりあえずDeveloper Zone下ぐらいはやるつもり。
追記: 宣言通り Developer Zoneは完了した。よかった。
typoとか誤訳の指摘はここのコメントかtwitterか直接か、私の耳(目)に入ればなんでもいいです。
随時、ここかtwitterで更新情報を流します。
昨日に続いて普段心がけていることや、周りの人に期待してることを垂れ流してみる。誰かが言ってたり書いてたりしたものパクってるのもある。当然なことばかりだけど意外とできなかったりすることだと思ってる。
ツールはツールでしかない
新しい管理ツールやコーディングのためのツールを導入したらバラ色だと思う勘違い。ツールはツールでしかないんで、なぜそのツールを使うのかという本質を理解しないで導入しても、導入コストだけかかって意味がない。
開発手法は開発手法でしかない
上と同じ。新しい開発手法を取り入れたら生産性が必ず上がると思う勘違い。
フレームワークはフレームワークでしかない
上と同じ。
コーディングの早さはハマってる時間の短さ
ハマることは必ずしも悪いことではないし、早ければいいわけではないが、ハマってることを意識することは大事。また、同じようなことでハマることが続くならなら、基礎的なことを先にまとめて勉強し直すという思い切りも大事。
休憩重要
定期的に休憩しよう。自分の場合は最大1時間30分で一回休憩するようにしている。
開発環境の構築をできるようになろう
自分の開発環境用のOSのインストールや各種サーバの構築ぐらいはできるようになろう。
とりあえず書こう
行き詰まったらとりあえずコードを書いてみることも大事。少しでも書くと見えてくるものもある。
妄想禁止
妄想で動くのはやめよう。
例:
- 何の根拠もなく「この処理でこのデータをmemcachedに入れたら処理が早くなるんじゃね？とりあえずやってみよう。」
- 何の根拠もなく「このバグはユーザのブラウザが古いのが原因だ。バージョンアップしてもらおう。」
ソフトウェアは思ったように動くのでなくて書いたように動く (追加: 2010-02-04)
バグを指摘され「そんなはずはない」と考えるのは時間の無駄です
命を大事に
ちょー大事。
他にもあるけどとりあえずこんな感じ。
バグが起きたときの対応によって、その製品のクオリティが大きく変わる。自分または自分が属するチームがバグを直すときに注意していることをメモ。
- 正しい手順で直したか。
- commitするbranchは間違いないか。
- バグ管理システムはルール通り使われているか。
- すぐにデプロイする必要があるときはその手順は問題ないか。
- そのバグによって壊されたデータがある場合、それも直したか。
- そのバグが再現しないか。
- 発生したバグのためのテストコードを追加し、再現しないことを保証する。
- ただし、そのバグが再現性の低いようなバグで、直せたかどうか不確かな場合、
- 次回それが起きたときにより精度の高いログを出せるようなコードになっているか。
- また、それが起きたときに開発側が気付けるような仕組になっているか。
- その修正が、他に悪影響を与えることはないか。
- コード的な悪影響はテストで確認する。
- 仕様的な不整合やバグが出てないかも確認する。
- 似たような潜在的なバグが他にもないか。
- 直すか直さないかは別にして(動いているものは直さない方がいいこともある)、同じようなバグが他にあるか確認する。
こういうのは、余裕があるときは簡単なことなんだけど、忙しいとついさぼってしまうので、Redmineなどのバグ管理ツールか何かと連携して(チェックリストとか)できた方がいいんだろうなー、と思いつつ今はしてない。
Webシステムではあちらこちらでキャッシュが使われている。クライアントサイドでのファイルのキャッシュ(ブラウザやproxy)や、サーバ側でのキャッシュ(memcacheとか)など、そこかしこでキャッシュが使われている。キャッシュする対象も、ファイルであったり、データベースの検索結果であったり、動的に生成したhtmlページであったり様々だ。
その中でも、今回はweb開発で基本となるユーザ側(ブラウザやproxyサーバ)での静的ファイル(Javascriptや画像など)のキャッシュについて書いてみる。ちなみに、以前nginxを使ったサーバサイドでの動的なhtmlコンテンツのキャッシュについても書いたのでそちらもどうぞ: nginxを使った簡単快速reverse proxy+cacheサーバ構築法
まず、説明するまでもなく、キャッシュとは、コストの高い処理の結果を保存しておき、再度同じリクエストがあった場合に同じ結果を返す仕組みのことだ。キャッシュというのものはWebシステムに限らずやっかいなもので、キャッシュが有効か無効かの判断(validation)が難しい。判断に失敗するとユーザは古いデータを使い続けてしまい、システム提供側の意図しないような動作になってしまう。システムのややこしい部分の大部分はキャッシュにあるんじゃないかというぐらいややこしいことが多い。
しかし、Webシステムにおけるブラウザ(or proxy)側でのキャッシュ戦略についてはいくつかの定番がある。
- ファイルが変更されたかどうかを最終ファイル更新日(Last-Modified)を元に毎回サーバに問い合せる (Apache等のWebサーバのデフォルトの機能はこれになっていることが多い)。そして変更があったときにのみ新しいファイルを返す。
- ファイルの有効期限(Expires)をある程度先(2週間後とか)に設定し、それまでの間は古いファイルが使われてしまっても仕方ないと諦める。
- ファイルの有効期限(Expires)を遠い未来(2037年とか)に設定する。そして、サーバ側でファイルの変更するときには、ファイル名も変更する。
1.は毎回サーバにアクセスしにいくので(ブラウザによっては必ず毎回ではないが)、そのための余分な時間がかかる。もちろん1個や2個ならたいしたことないが、1画面内に数十ファイルある場合それなりに違ってくる。また3と比較すると、壊れたブラウザやプロキシに対して弱い(後述する)。
2.はある程度古いコンテンツをユーザに流しても問題ないと言った緩い要求の場合には有効。ただ、1.と同じく、壊れたブラウザやプロキシには弱い。
3.は1, 2.と比べ、下記の理由で優れている。
- 1.と違いファイルが変更したかどうかをサーバに問い合せる必要がないので、その通信の時間や帯域、サーバの負荷を低減できる。
- 2.と違いファイルが更新された場合には、すぐにキャッシュが無効になる。
- さらに、「ファイル名を変える」ということはブラウザやProxyから見ると「新規のファイル」になるのでvalidationの処理自体必要がなくなり、どんなことがあっても必ずサーバに問い合わすようになる。これは、キャッシュシステムが壊れていたり、バグがあったりしたときにもとても強い。ブラウザやproxyにキャッシュ関連のバグや、仕様という名のルール無視な製品によって、1や2がうまくいかずに、新しいファイルが配信されない、ということがそれなりにある。そういうブラウザやproxyを使っている人を無視できればいいのだけど難しいことも多い。また、ユーザ側で起こっていることをサーバ側から完全に知ることは基本的にはできないので、できるだけそういう問題がクリティカルにならないようにしておくことが大切。
ただし、3.はアプリケーション側でしなければいけないことが増えるという欠点がある(ファイル名が変わるということは、それを呼び出しているhtml等も変える必要がある等)。ちなみに、たいていの大手サイトでは静的ファイルは3.になっているし、YSlowやPage Speedと言ったWebサイトの性能を計るようなソフトウェアでは、Expiresが設定されていないと評価が落ちる(警告が出る)ようにできている。YSlowやPage Speedと言ったツールも非常に面白いのでそのうち紹介したいと思っている。
実際の設定については、Webサーバソフトウェアやアプリケーションサーバによって変わってくるが、
- Last-modifiedヘッダーをつける(何もしなくてもこれがつくWebサーバやアプリケーションサーバがほとんど)。
- Expiresヘッダーのタイムスタンプをちょっと先にする。
- Expiresヘッダーを遠い未来(2037年)とかにする。また、ファイルを更新するときには名前を変える。ファイル名を変えるのが大変な場合には、query stringをつける、という手もある。例えば、http://www.example.com/picture.png?123456 みたいな感じにして123456のところをファイルの中身と連動して変える。ただし、query stringがついているキャッシュされなくなってしまうブラウザやproxyサーバがあるのは注意が必要。ただ「キャッシュされなくなる方」に誤動作する方が「古いファイルがキャッシュされ続けてしまうよりは」はマシなのでシステム的にこれが楽な場合はこれもありだろう。
おまけ:
この辺の設定もnginxだと非常に楽に書けて気に入っている。たとえば、これは実際のこのブログの設定だが、ブログ内に貼ってあるスクリーンショットなどの画像ファイルは中身によってファイル名を変えているので、3.のパターンが使え、Expiresを遠い未来にしている。
例:
location http://blog.madoro.org/mn/images/ {
root /usr/local/projects/everblog/public/;
if ($request_uri ~* "\/images\/[0-9a-f]+.(png|jpg$)") {
expires max;
break;
}
}nginxはこんな感じで、プログラム風に設定を書けるのがとても楽。一度使ってしまうとApacheのような設定が複雑なのには戻れない。
上記のように設定しFirebugのようなツールでヘッダーを確認するとExpiresが設定されているのを確認できる。
追記: twitterで聞かれたんで。これはキャッシュさせることができる(技術的なことよりも、仕様/要求的に)コンテンツが前提の話なので、キャッシュさせたくない、有効期限をちゃんと持たせたいファイルに対しては別の話になる。
RSSリーダで読む