| #!/usr/bin/env gosh | |
| (use gauche.parseopt) | |
| (use file.util) | |
| (define (main args) | |
| (let-args (cdr args) | |
| ((help "h|help" => usage) | |
| (quiet "q|quiet" #f) | |
| (lag "l|lag=n" 600) |
http://tddbc.doorkeeper.jp TDD Boot Camp 2013-07 -- TDDBC で、偶然にもロンドンから来日していたSteve Freeman氏を招くことができた。ちなみに本当に偶然の来日で、その日の夕方にご家族と隅田川の花火を見る予定だったらしい。貴重な時間である。
20分ほど講演していただき、さらに参加者と一緒にペアプロ課題に挑戦してもらった。しかもペアプロでっていう貴重な体験をさせてもらったので、そのことについてまとめたい。
Steve Freeman氏は書籍 "Growing Object-Oriented Software, Guided by Tests" （邦訳「実戦テスト駆動開発」）の共著者の一人で、Javaのモックフレームワーク "JMock"の開発者の一人。当然、自動販売機の課題にもJMockを駆使してモデリングしていただくことになった。
| ; 3.3.5 | |
| (define false #f) | |
| (define true #t) | |
| (define (celsius-fahrenheit-converter c f) | |
| (let ((u (make-connector)) | |
| (v (make-connector)) | |
| (w (make-connector)) | |
| (x (make-connector)) |
ユニットテストが継続的に回るようなベースの上で、アプリケーションを書き始める。
「ユニットテストが継続的に回るようなベース」って仰々しいけど、ようするにmavenとかsbt, composer, rubistじゃないからわからんけどbundlerみたいな、実に一般的なアレです。当然、それら単体ではテスティングフレームワークも依存ライブラリの一つでしかなく、ようするにそのへんの依存性が定義されていればそれでよい。それに加え、テストコードのサンプルがあるとすぐに始めることができる。その辺のベースは、 TDDBC コミュニティによっていくつか紹介されているので、使ってみてもいいかもしれない。
あとはテストファーストでもよいし、アプリケーションコードから書いてもいいし、好きにやればよい。意外と良いのは、アプリケーションコードとなる関数やクラスをテストコード側のディレクトリに書き始め、ある程度書いたら、プロダクションコード側のディレクトリに移動するやり方。やったことない人はお試しください。場合によっては print デバッグも使うし、デバッガも使う。print はプロダクションコードを汚すやり方ではあるけど、どうせ後で消すし、消したあとの動作がいい感じであることを確認できれば（当然自動テストによって！）、特に問題にはならない。消し忘れが怖いやつは何やってもダメ。
一般的なベースを使っていればテスト実行もIDE等に依存することなく、CIサーバに組み込むこともそれほど難しくないはず。なので、「CIを先に構築すべき」という制約がなくなるし、外部のCIサービスを使うこともすぐに使えるようになるはず。
ワイワイ！これはFluentd Advent Calendar 12日目の記事です。
私は現在、VOYAGE GROUPの子会社であるZucksというところで、Zucks Adnetworkという広告配信サービスを作っています。で、その中でFluentdが活躍しているよーという話をしてみます。事例紹介ってやつです。
Zucks Adnetworkは、いわゆる広告配信サービスです。
広告配信サービスは配信した結果を何らかの形で集約して、よーするにお金がどうチャリンチャリンしてるかを確かめる必要があるわけです。その一つのやり方として、「配信結果を1件ずつ行分割したテキストファイルの出力しておいて、そいつをいい感じにまとめて、数え上げる」みたいな方式があって、つまるところ、私たちはそうやってます。
2年経ったらなんとなくまとめる流れがあったので、それに習い、2年間を振り返ってみます。
入社当時の配属先。当時は@ajiyoshiがリード、1ヶ月前に入社していた@brtriverがグリーンバンドをしていたのが印象的だった。
管理系はPHPで書かれており、まともに触るのは初。最初はWindows上でなんとかしようとしたが、すぐに諦めてUbuntu on VMWareにした。本番サーバはCentだったけど。「共通の開発環境」みたいなのを用意してくれていて、アプリケーションはそれぞれ独立していたがDBは共用していて（これもそのうち解消したはず）、隣の人のデータを壊したりしていた。まーそれでも、聞けば答えてくれる人たちが周りにいたので、とりあえず仕事をすることが出来た気がする。立ち上がりはかなりゆっくりで、初回のコミットは4週間後だった記憶がある。
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html より。Auto Scalingがインスタンスを破棄（terminate）するとき、どのインスタンスを選ぶかのポリシーがある。無指定であればdefaultポリシーが適用されているが、選ぶこともできる。
| <?PHP | |
| class F { | |
| public static function curry($f) { | |
| return new F($f); | |
| } | |
| private function __construct($f, $args = []) { | |
| $this->f = $f; | |
| $this->args = $args; |
| ``` | |
| Sigdump at 2014-08-10 18:45:49 +0900 process 1977 (/usr/sbin/td-agent) | |
| Thread #<Thread:0x007f191859bf68> status=run priority=0 | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:38:in `dump_backtrace' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:24:in `block in dump_all_thread_backtrace' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:23:in `each' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:23:in `dump_all_thread_backtrace' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:16:in `block in dump' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:107:in `open' | |
| /usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/sigdump-0.2.2/lib/sigdump.rb:107:in `_open_dump_path' |
こんにちは。 @katzchangです。
VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。
評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。
