Kosei Kitahara's Blog

やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...

ちょうど 1 年前にリリースされてた機能だけど、恥ずかしながら知らなかった。 @t2y 先生が 紹介 していらっしゃって、後で試してみようと思ってたのですが...。 virtualenvwrapper ってインストール時にグローバルな site-packages に放り込んで、後は。。。って感じ。あんま見直したことなかったのですが、プロジェクト管理以外にも結構色んな機能が追加されてるんですね。 mkvirtualenv , workon だけじゃない！ ドキュメントを 和訳 してくださっている @t2y さんに多謝。基本的な機能やコマンド (と思いこんでいた mkvirtualenv , workon , etc...) については virtualenv, virtualenvwrapper, pip を使う方法 by @IanMLewis さん, Pythonを取り巻く開発環境 (PyCon JP 2012資料 #pyconjp) by @ymotongpoo さんの記事が参考になります。 >>> mkvirtualenv v3.3 から新しい オプション が増えてたんですね。これも知りませんでした。 -a <path/to/project> : プロジェクトに新しい env を関連付ける (後述) -i <library_to_install> : env 作成と同時に、インストールしたいライブラリを指定する mkvirtualenv -i django -i django-celery-with-redis <env_name> のように複数指定できる -r <path to requirements file> : env を作り requirements.txt 等指定したファイルに記載したライブラリを一括でインストールできる。個人的にこれは一番うれしいかも mkvirtualenv -r ./requirements.txt <env_name> ラクダーーー >>> mktmpenv これも v3.3 から。ユニークな名前で env 作成してくれる。 >>> cdvirtualenv , cdsi...

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。

Hython 部の方から来ました。こんにちは。今回は Python ボルダリング部 (通称 #kabepy ) のアドベントカレンダーにお邪魔させて頂きます。もともと Hython 部は Pythonista が廃村に行くとかいうノリで始まったんですが、廃村が山奥にあることが多く、いつの間にかワンダーフォーゲル部になってしまいました。昔の日本は林業大国だったんですね。 今年 (2012年) の登山成果は、 谷川岳 - 一ノ倉 - 茂倉岳縦走 富士登山 槍ヶ岳縦走 浅間山縦走 丹沢縦走 です。#kabepy のアドベントカレンダーなので "ロッククライミングのメッカ" と言われている谷川岳について書かせて頂きます。 谷川岳について 谷川岳 - Wikipedia に詳しく書かれていますが、 剣岳、穂高岳と共に日本三大岩場のひとつ 日本三大急登 (高低差) がある 遭難による死者数が世界一 (ギネス認定 なんとも物騒な感じですが、コースによります。私が登ったコースは、とても登りがいがあり、稜線が素敵なコースでした。まだ登山歴 2 年目ですが、また登りたいと思った山は谷川岳だけ。 @rokujyouhitoma 先生の故御父様も谷川岳をこよなく愛されていたそうです。 コース 直線距離: 約15km / 高低差: 1.5km / 全 7.5 時間 ぐらいですかね。小雨。 07:30 - 土合駅 08:00 - 天神平 晴れてる時は富士さんが見えるらしい。残念ながら ガスで10m 先も見えない。 10:00 - 谷川岳トマの耳 (1,963m) 鎖場あり。岩場あり。登りごたえのある登山コースです。が！写真撮れません。ガスがひどくてシャッター下りません。立派なプレートだけ。 11:00 - 谷川岳オキの耳 (1977m) 景色？なにそれ。立派なプレート。 稜線の所だけガスが晴れた瞬間。ここから人とすれ違わなくなります。高山植物がいたるところに生えていて、ハエが大量にいます。が！写真撮れませんでした。 12:00 - 一ノ倉岳 (1974.2m) 立派な・・・ 手前に万年雪があります。ガスもあってただ一面白いだけ。ここもオートフォーカスが効かないという。 13:...

Django-ja の方からきました。こんにちわ。さて、昨日の Ian 先生のブログ にも書いてある通り、ついに Django にも本格的に Python 3 の足音が近づいてきました。ただし現在 alpha 版が公開されている 1.5 では "実験的" なサポートで、1.6 以降で正式にサポートする予定となっています。あくまでも "実験的" であり、プロダクションでの利用は "非推奨" となっています。Django コミュニティでは、この 1.5 でサポートをテストしてもらい、そのフィードバックを呼びかけています。なのでプロダクションでの利用は 1.6 まで待ちでしょうね。また Python 3 サポートと同時に、Django 1.4 では Python 2.4 がサポートから外れ、1.5 では Python 2.5 がサポートから外れます。これで 1.7 以降から django.utils 配下が軽くなっていくんでしょうかね (現在は 3 サポートのためにさらに増えてる)。 バージョン 下位互換 Python サポート 2.5 2.6 2.7 3.2 3.3 Django 1.4 > 1.2 ○ ○ ○ - - Django 1.5 > 1.3 - >= 2.6.5 ○ >= 2.7.3 △ 実験的 △ 実験的 Django 1.6 > 1.4 - >= 2.6.5 ○ >= 2.7.3 ○ ○ Python 2.5 系を利用している場合は、1.6 のリリースまで (2013 後半ぐらい?) に Python 2.6.5 以上 (2.7.3 以上を強く推奨) への移行が必要です。1.5 は今月 (2012/12) 中にリリース予定とのことなので、今のうちに Python 3 へ移行方法を抑えときたいなと。以下 Django ドキュメントの翻訳作業がてら " Porting to Python 3 " を元にご紹介。さすが...

遅くなったけど続編。前回 TODO にしてたスケールアウトのオートメーションあたり。AWS のオートスケールについては、 本家ドキュメント に一通り書いてあります。その機能を大まかにまとめると、 スケールアウト、バランシングが自動化できる 複数のゾーン (Availability Zone) にまたがっていても一元管理できる (AZRebalance ELB を指定してインスタンスを追加できる 不健全なインスタンスを自動的に入れ替えれる >>> オートスケールの設定 大きく分けると 3 つのステップ CPU やメモリ等のリソースを識別する CloudWatch に各リソースをモニタリングするためのメトリクスを作成する デフォルトでモニタリング可能なリソースが用意されている ( デフォルトで用意されているリソース EC2 の CPU 負荷、ディスク I/O、ネットワーク I/O ELB のホスト数 (健全/不健全)、 リクエスト数 、レイテンシ Netflix 推奨は ELB の rps (req/sec クラスメソッドさんが カスタムメトリクスの追加 について超わかりやすく解説されています。 リソースの変化に基づくアラームやオートスケール等のポリシーを定義する ポリシーベース: 負荷が高くなったら EC2 インスタンスを増やし、負荷が減ったら EC2 インスタンスを減らす スケジュールベース: 負荷の予測が可能な場合は、インスタンスの増減をスケジュールする (バッチ処理にも素敵 >>> Netflix がオートスケールから学んだこと Netflix さんが実際にオートスケールを運用して、その結果を フィードバック されています。以下抄訳とかメモとか 早めにスケールアップ 例えば負荷テストで 25rps (rec/sec) を超えると待ちが発生するとする。その場合は待ちが発生しないように、20rps を超えた際にキャパシティーを増やすよう設定する。この rps の上限設定は以下の目的がある。 オートスケールイベントのトリガーでは間に合わない程の、予想をはるかに超える rps もありうる このバッファーが "キャパシティスパイラル" を回避するセーフ...

現在日本でサービスを提供していないため目にすることは少ないですが、AWS のベストプラクティスと呼び名が高い Netflix のスケールをメモ。ベストプラクティスと言われるだけあって、記事も解説も豊富です。まー規模が桁違い過ぎるので読み飛ばしていたってのが正直なところですが、V 先生ドリブンで資料を読み直しました。AWS の How-to 記事は日本語でも山ほどあったので、自社データセンターから AWS へ移行した過程を中心に書きたいと思います。Netflix のテクノロジーについては以下を参考にしました。 The Netflix Tech Blog @ slideshare @ github >>> サービスの規模 Netflix は主に北米で VOD と DVD 郵送レンタルサービスを提供している会社です。ほとんど VOD で、今後 DVD 郵送レンタルは縮小するらしい。AWS の資料も VOD がメインです。サービス規模を抜粋 ( スライド ) すると、 会員数は 2500 万人弱 ピーク時は 北米インターネットトラフィックの 30% 超を占有 800 種類以上のデバイスからアクセス = 各デバイス用にエンコーディング 月間 (2012/6時点) 総視聴時間は 10 億時間超 = ユーザ 1 人当たり、1 日約 1 時間視聴 API リクエスト数 は 420 億 RPM = 約 15,000 RPS 今現在も急成長中とのことです。桁違いですね。はい。 >>> AWS 移行前の課題 AWS に移行する前の Netflix は、 単一の Web アプリケーション: Java/Tomcat = war ファイル 単一のデータストア: Oracle rac 単一のデータセンター バックアップなし (Wow という構成だったようです。The エンタープライズ！って感じですね。2008 年に DB の障害で DVD レンタルサービスが 3 日間停止するなど、この運用は以下のような問題があったようです。 データセンタが SPOF データベースが SPOF 。単一データベースの限界。スキーマ変更等サービスのリプレイス時にサービスが停止する Web アプリケーションの一部のバグが全体に...

Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 ( comment ) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、 2006 年当時はオンラインストレージサービスがいっぱいあった ようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プライベートベータのビデオが 12000 digg (<- 懐かしい) され、ベータリストの登録が 1 日で 5 千人から 7 万人に増えたことも。 現在 、 5000 万人のユーザ が、 2 億 5 千万デバイス から、 48 時間で 10 億ファイル 保存してるとのこと。 ファイルの POST/PUT で 5787 rps となると GET を合わせると。。。すごいですね！ スケールの記事を書かれているのは、2011 年まで Dropbox でスケールを担当されていた Rajiv Eranki (← URL w) 氏です。Dropbox のバックエンドはほとんど 1 ~ 3 人で面倒を見ていたとのこと。順不同で以下抜粋。なお、Dropbox さんは有効であるのは間違いないですが、ストイックと思われる箇所もあるので、18 最未満の方は保護者の同意の下ｗ >>> 利用しているテクノロジー 言語: ほとんど Python, ちょっとだけ C データベース: MySQL WSGI: Paster / WAF: Pylons / テンプレートエンジン: Cheetah ファイルブロックの保存と提供: S3/EC2 キャッシュと...

前回書いた記事のアップデート。jetty をよく理解してなかった orz。シンプルに dotCloud に jenkins.war をデプロイするだけでいけますね。 プロジェクト作成 プロジェクト名を jenkins として作っています。 $ dotcloud create jenkins $ mkdir jenkins ディレクトリ階層は以下のように。jenkins.war は jenkins-co.org からダウンロード。 $ tree jenkins/ jenkins/ ├── dotcloud.yml └── webapps └── jenkins.war dotcloud.yml の内容 $ cat jenkins/dotcloud.yml www: type: java approot: webapps まんまデプロイ。 $ dotcloud push jenkins jenkins/ jetty@dotCloud の設定 こっからは dotCloud のインスタンスに ssh アクセスして設定 (更新: user.home ごと書き換える) $ dotcloud ssh jenkins.www # ssh でアクセス ワークスペースを作成する。 $ mkdir jenkins $ chmod g+w jenkins 後は、 jetty の設定 。 ~/contexts/ ディレクトリ以下に、以下のような xml を追加。名前は何でもいいけど、とりあえず contexts/jenkins.xml など。書いたのは、パスの設定と JENKINS_HOME の設定だけ。ここで設定するので、 ROOT.war とかに変更する必要もなし。 <?xml version="1.0"?> <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> <Configure class="org.mort...

これはすごい！Windows でも使える素敵なタブ機能付き Shell クライアントががが！Chrome extention です。10h/24h 以上は secure shell の中で生活しているので、これで捗ります。 Chrome Web Store - Secure Shell FAQ Google Group chromiumos 用に開発されてるようですね。動作もサクサクですし、今のところなんの問題もなく動作してます。現在 beta 版で公開鍵認証等はサポートされていませんが、恐らくすぐに サポート されると思います。 # スクリーンショット 接続画面 マルチバイトも問題なく表示 Vim もサクサク # ブックマーク 以下の URL でブックマークができます chrome-extension://pnhechapfaindjhompbnflcldabbghjo/html/nassh.html# user @ host : port

@ats 先生のご紹介で Windows Developer Days に参加させて頂きました。ありがとうございます！Microsoft のイベントは 10 年振りぐらいですかね。前回行ったパシフィコ横浜の時に比べると、こじんまりした会場で、人口密度がかなり高く、装飾が派手でした。Windows 8 は他の OS に負けない UI ! という意気込みを感じます。 セッションもメトロスタイルなアプリのデザイニングに関するものが厚めでした。MS 社のイベントでこれだけデザインの話がでるというのも新鮮です。今んとこ開発予定はないですが、メモ Windows 8 RC 版を 6 月 1 週にリリース スタートボタンから Metro UI へ (デスクトップモードもちゃんとある) USB で持ち歩ける -> Windows To Go (抜いたら停止、挿したら再開、抜いて 60s 経ったらシャットダウンし、データも消える) 新しく Metro スタイルアプリが追加 Metro style Apps MVC は HTML/CSS/JavaScript or silverlight で ネイティブリソースにアクセスする場合は WinRT or WinJS MS の方曰く、IE で動くものは基本的に移植可能 白石先生 (html5j.org) 曰く、html5 アプリがそのまま動けばいいけど、制限があるため Metro アプリケーション用に改修が必要とのこと ※ iframe なら可 配布は基本的に Windows Store のみ デザインガイド その他 Hadoop の Windows ディストリを公開予定 Hive や Pig 等の主要プラグインもパッケージング Server 版と Azure 版を提供予定 (Azure 先行) すべて javascript で制御可能 rails アプリケーションを Azure で動かす Intel Ivy bridge は省電力とのこと Intel の  Tick-Tock  戦略の Tock Intel Parallel Studio は面白かった！ パフォーマンス分析、チューニングが出来る プロフ...

O'Reilly 様から " 実践 Qt4 プログラミング " をご献本頂きました。 有難うございます ！！初めての献本ということで小躍りしました。この本は入門書ではないので、今から Qt4 を触りたいという方は " 入門 Qt4プログラミング - O'Reilly" もあります。 中身をどこまで書いていいのかわかりませんが (w、各章で Web アプリケーションクライアント、メディアプレイヤー、データ・モデルビュアー、エディタ等々 幅広い デスクトップアプリについて解説されています。データ・モデルビュアーが厚めです。その各章にアプリケーションの作例 (25 ちょい) があり、 丁寧にコードリーディングしていくことができます 。サンプルコード量約 2 万行w 読み応え十二分です。Qt は (この本がカバーしてる Ver.4.6 ) 800 近いクラス からなっているので、そんなもんなんでしょうね。 クラスの API リファレンスは公式ドキュメントを読むとして、この本の素敵なところはコードリーディングをしていくうちに Qt4 の重要な機能を理解できる ことと、 デスクトップアプリケーションを作る際に気を付けるべきことが勉強できる ことだと思いました。まさに実践向きですね。あと、プラットフォームごとの差異、非推奨の機能、デスクトップアプリを作成する際に注意すべきことが各所で紹介されています。これも嬉しいですね。クロスプラットフォームなデスクトップアプリにご興味がある方は必読だと思います。 >>> PySide/PyQt の参考書としては? 十分使えます 。量バインディング共によく出来ていて、クラス名やプロパティはそのまま、c++ で書かれているロジックを Python に置き換えれば動きます。ただし、マクロは Python に書き換える必要があるのと、シグナル・スロットの書き方、各クラスが属しているモジュール (QtCore, QtCore.Qt, QtGui...) は調べる必要があります。 アプリケーションを起動する main 関数 int main(int argc, char *argv[]) { QApplication app(argc, argv); ...

V 先生から 教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。 Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います 。 本題に入る前に、Python には The Zen of Python ( 日本語 ) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。" Simple is better than complex " です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。 Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android アプリ公開等のサービス拡大時にも少ないエンジニアリングで柔軟に対応できたのかと。これはあくまでもイメージでしかありませんが、AWS 上でスケールアップできるところまでスケールアップし、限界が見えたところでスケールアウトで最小限のエンジニアリングコストをかける。インフラで解決できるところはインフラで解決しているというイメージです。Pinterest のスライドでは、インフラをシンプルに更改した過程が紹介されています。 >>> インフラの遷移 2010/05: 創設 RackSpace 小規模な Web Engine × 1 小規模な MySQL DB × 1 2011/01: AWS へ フロントに nginx を立て垂直分割、MySQL をマスタースレーブ構成に垂直分割、ヘビーな処理をタスクキューに分割、MongoDB を導入。 Amazon EC2 + S3 + CloudFront nginx × 1 Web Engine × 4 MySQL: Master × 1 / Slave × 1 Task Queue × 1 / Task Processors × 2 MongoDB × 1 2011 年後半: ターニングポイント LB, Web サーバを増加、MySQL をシャー...

Instagram がどこに買収されたとかは他のニュースサイトにお任せして、 Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載 された スライド から個人的なメモとしてまとめてみました。 Instagram の哲学は シンプル であること オペレーション負荷を最小化 すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、" まだ進化途中だから " だそうです。 ハードウェアの選定、導入、セットアップの手間も省けますし、パッケージ管理等の運用も軽そうですね。 >>> ロードバランサ Amazon ELB を利用。もともとは DNS ラウンドロビン + nginx のロードバランサでバランシングしてたらしいですが、DNS の更新が遅いので止めたとのこと。nginx の負荷を軽減するために SSL も ELB までで、あとは HTTP。ELB はほんと素敵なサービスだと思います。DNS も Amazon Route 53 を利用。GUI での管理が素敵とのことです。 >>> アプリケーションサーバ Django アプリケーションを EC2 の High-CPU Extra-Large インスタンスで実行。2012 年開始ぐらいでは約 25 インスタンスと書かれています。Android アプリを公開して 10 日で 1000 万ユーザ (20 時間で 100 万ユーザ) を獲得したようなので、今はもっと多いでしょうね。こういうサービスの拡大に柔軟に対応できるのも EC2 を含むクラウドの魅力だと思います。High-CPU にしている理由はおそらく PIL を多用するからでしょう...

メリークリスマス！でしたね。今年のクリスマスは ruby を書いて過ごしました。えぇ。ついに ruby デビューです。 作ってたのは Redmine のリポジトリ全文検索プラグインです。会社のプロジェクト管理サイトを Trac から乗り換えるにあたり、これ！ってのが見つけられなかった情弱です。 Trac では、full-text サーチエンジンに Hyper Estraier を使う  TracRepoSearch  という素晴らしいプラグインを使ってました。ということで、便乗して redmine_reposearch というプラグインを作って見ました。バックエンドも同じく Hyper Estraier です。  個人的に欲しかった機能は、 インストールステップが簡単 プロジェクト、サブプロジェクト、全プロジェクト間で検索できる Redmine のアクセス権管理に対応する MIME タイプを限定して検索する (今後実装予定) です。ある程度は満足がいく出来に作ることが出来ました。インストール方法等は wiki にまとめました。わかりにくかったらお気軽に Issue か Twitter でお申し付けください。 # インストールステップは 2 ステップ これは結構苦労しました。いろんな OSS 検索エンジンの仕様を調べ、一番インストールが簡単で、動作が軽快で、気の利いた ruby バインディングがあるやつを選びました。 ライブラリのインストールとプラグインのインストールのみで動作します。 Estraier の DB は RAILS_VAR/reposearch 以下にプロジェクト毎に作成されます。Ubuntu の場合は、 /var/lib/redmine/reposearch になります。クラスタ組みたい場合は、 RAILS_VAR はアップロードファイル保存ディレクトリでもあるので、ネットワークファイルシステムをマウントするなどすればいいと思います。 あと SCM との連携は fetch_changesets と同じ仕組を流用しています。まだ ruby script/runner "Repository.fetch_changesets" -e production のようなコマンドでは動きませ...

これは Python3 Advent Calendar の記事です。夢はテストエンジニアです！ということでユニットテストについて書きます。 Python3 縛りとのことですが、この新ユニットテストフレームワークは Python 3.2 以降と 2.7 以降が対象です。これ以前のバージョンでこの新ユニットテストフレームワークを利用したい場合は、それぞれ unittest2py3k (3 系)、 unittest2 (2 系) というバックポートが用意されています。新ユニットテストは mock や IronPython 等の開発者としても知られている Michael Foord 氏を中心に開発されました。 >>> Python とユニットテストの歴史 Python のユニットテストは、1999 年 xUnit ファミリーの PyUnit として開発され、2001 年に公開された Python 2.1 から unittest として標準ライブラリとなりました。それ以降、アップグレードといえば assert* メソッドの追加や削除といった感じ。PyCon 2010 での Michael Foord 氏の プレゼンテーション によると " Python には革新的なテストインフラが数多くありますが、unittest は標準ライブラリという理由により最も利用されているテストフレームワークです。しかし、他のテストフレームワークが革新的な進歩を遂げている中、unittest は遅れを取っています "。 しかしついに、ユニットテストは Python 3.2, 2.7 で革新されることになりました。それも Python らしく "後方互換" がかなり意識されています。これも Michael Forrd 氏の言葉を借りると " これは革命ではなく、 進化 です "。 >>> どこが "進化" したのか 新ユニットテストフレームワークには以下の機能の追加や更新が行われています。 便利な assert* メソッドの追加 名称の統一、重複の排除 コマンドラインからの制御をより便利に / 或いはディスカバリ テストのスキップ モジュールレ...