- トイレットペーパーホルダーが二つあるトイレでは、紙が少ないほうを先に使いましょう
負荷低すぎはもはや障害じゃないのかという記事の話。
そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか?
とのこと。
package mse | |
import java.io._ | |
import org.bytedeco.javacpp.helper.opencv_core.AbstractCvMat | |
import org.bytedeco.javacpp.opencv_core._ | |
import org.bytedeco.javacpp.opencv_highgui._ | |
object MSE { | |
def main(args: Array[String]) { | |
val ms = |
こんにちは。 @katzchangです。
VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。
評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。
``` | |
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' |
<?PHP | |
class F { | |
public static function curry($f) { | |
return new F($f); | |
} | |
private function __construct($f, $args = []) { | |
$this->f = $f; | |
$this->args = $args; |
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html より。Auto Scalingがインスタンスを破棄(terminate)するとき、どのインスタンスを選ぶかのポリシーがある。無指定であればdefaultポリシーが適用されているが、選ぶこともできる。
- Availability Zone毎にインスタンス数を取り、多いAZを特定する。
- 同数ならランダムに選ぶ。
2年経ったらなんとなくまとめる流れがあったので、それに習い、2年間を振り返ってみます。
入社当時の配属先。当時は@ajiyoshiがリード、1ヶ月前に入社していた@brtriverがグリーンバンドをしていたのが印象的だった。
管理系はPHPで書かれており、まともに触るのは初。最初はWindows上でなんとかしようとしたが、すぐに諦めてUbuntu on VMWareにした。本番サーバはCentだったけど。「共通の開発環境」みたいなのを用意してくれていて、アプリケーションはそれぞれ独立していたがDBは共用していて(これもそのうち解消したはず)、隣の人のデータを壊したりしていた。まーそれでも、聞けば答えてくれる人たちが周りにいたので、とりあえず仕事をすることが出来た気がする。立ち上がりはかなりゆっくりで、初回のコミットは4週間後だった記憶がある。
ワイワイ!これはFluentd Advent Calendar 12日目の記事です。
私は現在、VOYAGE GROUPの子会社であるZucksというところで、Zucks Adnetworkという広告配信サービスを作っています。で、その中でFluentdが活躍しているよーという話をしてみます。事例紹介ってやつです。
Zucks Adnetworkは、いわゆる広告配信サービスです。
広告配信サービスは配信した結果を何らかの形で集約して、よーするにお金がどうチャリンチャリンしてるかを確かめる必要があるわけです。その一つのやり方として、「配信結果を1件ずつ行分割したテキストファイルの出力しておいて、そいつをいい感じにまとめて、数え上げる」みたいな方式があって、つまるところ、私たちはそうやってます。
ユニットテストが継続的に回るようなベースの上で、アプリケーションを書き始める。
「ユニットテストが継続的に回るようなベース」って仰々しいけど、ようするにmavenとかsbt, composer, rubistじゃないからわからんけどbundlerみたいな、実に一般的なアレです。当然、それら単体ではテスティングフレームワークも依存ライブラリの一つでしかなく、ようするにそのへんの依存性が定義されていればそれでよい。それに加え、テストコードのサンプルがあるとすぐに始めることができる。その辺のベースは、 TDDBC コミュニティによっていくつか紹介されているので、使ってみてもいいかもしれない。
あとはテストファーストでもよいし、アプリケーションコードから書いてもいいし、好きにやればよい。意外と良いのは、アプリケーションコードとなる関数やクラスをテストコード側のディレクトリに書き始め、ある程度書いたら、プロダクションコード側のディレクトリに移動するやり方。やったことない人はお試しください。場合によっては print デバッグも使うし、デバッガも使う。print はプロダクションコードを汚すやり方ではあるけど、どうせ後で消すし、消したあとの動作がいい感じであることを確認できれば(当然自動テストによって!)、特に問題にはならない。消し忘れが怖いやつは何やってもダメ。
一般的なベースを使っていればテスト実行もIDE等に依存することなく、CIサーバに組み込むこともそれほど難しくないはず。なので、「CIを先に構築すべき」という制約がなくなるし、外部のCIサービスを使うこともすぐに使えるようになるはず。