Skip to content

Instantly share code, notes, and snippets.

View katzchang's full-sized avatar
🤯

Kazunori Otani katzchang

🤯
View GitHub Profile
@katzchang
katzchang / rule.md
Last active September 15, 2016 07:36
新社会人が守るべきだがほとんど誰も教えてくれない社会のルール

新社会人が守るべきだがほとんど誰も教えてくれない社会のルール

  • トイレットペーパーホルダーが二つあるトイレでは、紙が少ないほうを先に使いましょう
@katzchang
katzchang / readme.md
Last active August 29, 2015 14:14
負荷低すぎ問題は障害ではなくパフォーマンスチューニング - @katzchang.gist

負荷低すぎ問題は障害ではなくパフォーマンスチューニング

負荷低すぎはもはや障害じゃないのかという記事の話。

そうすると、 『イベントで一時的に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
katzchang / techass.md
Last active May 21, 2021 05:06
エンジニアの評価観点について - @katzchang.gist

エンジニアの評価観点について

こんにちは。 @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;
@katzchang
katzchang / about-auto-scaling-termination-poricy.md
Last active January 13, 2019 23:54
EC2 Auto Scalingを使ったときのインスタンス破棄のポリシーについての覚書 @katzchang.gist

EC2 Auto Scalingを使ったときのインスタンス破棄のポリシーについての覚書

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/us-termination-policy.html より。Auto Scalingがインスタンスを破棄(terminate)するとき、どのインスタンスを選ぶかのポリシーがある。無指定であればdefaultポリシーが適用されているが、選ぶこともできる。

どんなポリシーが用意されているか?

Default

  • Availability Zone毎にインスタンス数を取り、多いAZを特定する。
  • 同数ならランダムに選ぶ。
@katzchang
katzchang / readme.md
Last active January 1, 2016 03:19
VOYAGE GROUPに転職して2年とちょっとが経ちました #vgadvent2013 @katzchang.gist

VOYAGE GROUPに転職して2年とちょっとが経ちました

2年経ったらなんとなくまとめる流れがあったので、それに習い、2年間を振り返ってみます。

adingo Fluct開発チーム

入社当時の配属先。当時は@ajiyoshiがリード、1ヶ月前に入社していた@brtriverがグリーンバンドをしていたのが印象的だった。

管理系はPHPで書かれており、まともに触るのは初。最初はWindows上でなんとかしようとしたが、すぐに諦めてUbuntu on VMWareにした。本番サーバはCentだったけど。「共通の開発環境」みたいなのを用意してくれていて、アプリケーションはそれぞれ独立していたがDBは共用していて(これもそのうち解消したはず)、隣の人のデータを壊したりしていた。まーそれでも、聞けば答えてくれる人たちが周りにいたので、とりあえず仕事をすることが出来た気がする。立ち上がりはかなりゆっくりで、初回のコミットは4週間後だった記憶がある。

@katzchang
katzchang / readme.md
Last active December 31, 2015 03:09
[Fluentd Advent Calendar]広告配信にFluentdを使っていますという話 @katzchang.gist

ワイワイ!これはFluentd Advent Calendar 12日目の記事です。

私は現在、VOYAGE GROUPの子会社であるZucksというところで、Zucks Adnetworkという広告配信サービスを作っています。で、その中でFluentdが活躍しているよーという話をしてみます。事例紹介ってやつです。

置かれた状況

Zucks Adnetworkは、いわゆる広告配信サービスです。

広告配信サービスは配信した結果を何らかの形で集約して、よーするにお金がどうチャリンチャリンしてるかを確かめる必要があるわけです。その一つのやり方として、「配信結果を1件ずつ行分割したテキストファイルの出力しておいて、そいつをいい感じにまとめて、数え上げる」みたいな方式があって、つまるところ、私たちはそうやってます。

@katzchang
katzchang / README.md
Created October 15, 2013 01:37
ユニットテスト、果たして有用なのだろうか?

ユニットテスト以降

ユニットテストが継続的に回るようなベースの上で、アプリケーションを書き始める。

「ユニットテストが継続的に回るようなベース」って仰々しいけど、ようするにmavenとかsbt, composer, rubistじゃないからわからんけどbundlerみたいな、実に一般的なアレです。当然、それら単体ではテスティングフレームワークも依存ライブラリの一つでしかなく、ようするにそのへんの依存性が定義されていればそれでよい。それに加え、テストコードのサンプルがあるとすぐに始めることができる。その辺のベースは、 TDDBC コミュニティによっていくつか紹介されているので、使ってみてもいいかもしれない。

あとはテストファーストでもよいし、アプリケーションコードから書いてもいいし、好きにやればよい。意外と良いのは、アプリケーションコードとなる関数やクラスをテストコード側のディレクトリに書き始め、ある程度書いたら、プロダクションコード側のディレクトリに移動するやり方。やったことない人はお試しください。場合によっては print デバッグも使うし、デバッガも使う。print はプロダクションコードを汚すやり方ではあるけど、どうせ後で消すし、消したあとの動作がいい感じであることを確認できれば(当然自動テストによって!)、特に問題にはならない。消し忘れが怖いやつは何やってもダメ。

一般的なベースを使っていればテスト実行もIDE等に依存することなく、CIサーバに組み込むこともそれほど難しくないはず。なので、「CIを先に構築すべき」という制約がなくなるし、外部のCIサービスを使うこともすぐに使えるようになるはず。