D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

grpcをさらっと触ってみた。僕の個人的な結論から言うと、小規模なシステムにはいれるメリットあんまりないけど、複数チームでわりとバラバラに開発をしてるけど同じRPCを叩く必要があり、なおかつそれなりのトラフィックがあるなら有効そう。

他の言語の事は知らん。とりあえずGoでさわる。github.com/grpc/grpc-commonをチェックアウトして、サーバーとクライアントを起動する。ドキュメント読んでるとProtocol Buffersの話とかでてくるけど、動かしたいだけなら全部忘れてよし。

$ cd go/greeter_server
$ go run main.go
$ cd go/greeter_client
$ go run main.go

これだけだと一回RPCが走るだけでつまらないので、client側を変えて100 goroutineでぼちぼちたっぷりのコールをするようにする変更した部分はこんな感じ。ローカルホストにサーバーもクライアントもある状態なので正直正しい計測ではない事はまず言っておく。その前提で ざっくり10000 jobs/sec。HTTP2のオーバーヘッドを含めてだいたいそんなものなのでまぁ悪くないな、って感じ。

と、ツイートしたら"net/rpcと比べてどう?"って聞かれたのでほぼ同じプログラムをnet/rpcで作ったところ、約25K jobs/secいけた。 というわけで生スピードでは負けてしまったが、プロトコルの複雑さの差分と、goのhttp2がついこの間作られたばかりであまり最適化されていない、というのがほとんどの原因だと正直思ってる。

この辺りの厳密な値はちゃんとサーバー立てて検証すべきだし、他の言語でも試すべきなので本当に雑談程度の認識にしておいてください。

それより、やはり方法論としてProtocol Buffersでプロトコルを定義してそれを複数言語用に自動生成できるのが強みかなーと思ってる。JSON Schema的な。あっちの大陸とこっちの大陸で作業してるチームがサーバー・クライアントのコードのひな形を簡単に生成して作業を始められるのは強いのではないだろうか。このコード生成をgoから試すにはgithub.com/google/protobufを入れた上でgithub.com/golang/protobuf/protoc-gen-go を入れる必要があるので注意。

以上、さわってみたエントリでした。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

Software Design 2015年3月号

ソフトウェア デザイン 2015年 03 月号 の表紙はYAPC::Asia Tokyo 2013, YAPC::Asia Tokyo 2014でもお世話になり、今年もお世話になる予定CONBUの面々による「カンファレンスネットワークの作り方」です。普段正直ほとんど技術系の雑誌ってわざわざ買わないんだけどこの号は購入した。

DSC_0812


本文の記事ももちろんおもしろいんだけど、個人的にはやはり「YAPC」という文字列が専門誌とは言え一般的にあちこちで流通している雑誌の表紙に載っているのが胸熱…! 今までも雑誌にYAPC::Asia Tokyo関連の記事を載せてもらったり書いたりしたことはあったんだけど、もうYAPC本体とはなんにも関係ないところで自然?な形でこういう形でYAPCの名前が載るのがとにかく感動であった。

Web+DB Press vol 85

最近あんまり文章を書く仕事をしていないのだけど、WEB+DB PRESS Vol.85には自分が企画・進行諸々をやった「カンファレンス運営の本当の舞台裏」という座談会の記事を無理に言ってねじ込んでもらった(企画は賛同してもらって実際おもしろいと思うのだけど、多分俺の知らないこのページ数を都合する戦いがあったのだろう、と思ってこういう言い方をしてます)。

以前にもカンファレンスカンファレンスというイベントがあったりしたけど、運営側もすごくいろんな事を考慮しながら運営してるのでどうしても観客がいるとぽろっと話しちゃまずい話とかもあって好きに喋ることができないので正直言いたいことの10分の1も言えなくてストレスがたまる。それを解消したい! ぶっちゃけ話も聞きたい!ぽろりがあった場合はあとで修正して、おもしろい部分だけ世の中に伝えたい!という自分の欲求を正直に編集の稲尾さんに相談したら乗り気になってもらったのでガツガツと進行させて実現させてしまったのがこの会です。


_MG_6807_edit


というわけでRubyKaigiPyConYAPC::Asia Tokyo、そしてJANOGの皆さんに集まってもらって(もっと時間とお金と色々あれば他のカンファレンスの人達も呼びたかったのだけど、会場と司会進行の都合でこのメンツになりました)、まぁとりあえず酒でも飲んで、辛い事楽しいこと野望やらなにやら話そうぜ!という形で進めたらやっぱり楽しかったのであった。

本当におもしろいのでカンファレンスに登壇、出席している人には読んで欲しいなー。

ちなみにこの座談会のエッセンスはこの記事に出せているので是非読んで欲しいが、将来どこかのタイミングで完全版?を出版したと思っています。もしこの記事を読んでおもしろいと思ってくれたら、ブクマとかでコメントをくれると僕と文章の編集を担当してもらっている工藤さんがとても喜ぶしやる気がでるので、是非ぽちっとして教えてください!
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

更新: h2oを0.9.1から1.0.0にしたらこのハック無しでもいけたくさいです!





HTTP2使いになりたい!と思いはじめて数ヶ月。でもなかなかうまいことここぞという使い道がなかったので、2週間ほど前にとりあえず仕事でkuradoを立てた時に前段にh2oを入れて様子を見ていた。kuradoならたくさんグラフ表示されるし、HTTP2の恩恵を受けられるはず…!と思って。HTTP1モードでは当然特になんにも問題はなかったのだが、いざChromeでenable-spdy4を有効にした時になーんか… 崩れる…

具体的にはCSS、画像の類いがこない事が多いが、たまにメインのHTML部分が返ってこない。Chromeの開発者ツールやnet-internalsを見ててもただERR::connectionResetみたいなエラーが返ってくるだけで全然意味がわからなかったので、しばらくそれはそれで忘れてた。

だが、ふとローカル環境で同じセットアップを試そうと思って色々とログを出したりして見ていたら、h2o側にアクセスが行っているタイミングと裏のkuradoのアクセスログが出てくるタイミングが全然合わない状況が認識できた。

はっ… persistent connectionとかkeepalive timeoutとかだ…!

と 細かい理屈が脳内でさっと組み立てられなくても経験値からひねり出せる天啓を得たのでごにょごにょデバッグ開始…

色々な組み合わせを調べてみた結果、とりあえずh2o側の設定で以下のようにすると、動く。YATTA! 

    paths:
      /:
        proxy.reverse.url: http://172.17.42.1:5434/
        proxy.timeout.keepalive: 0

そしたら、SUGEEEEEEEEE! kuradoやcloudforecastはご存じの通り1ページに大量のグラフが出てくるんだけど、それらの描画が爆速になった!これぞまさにライフチェンジング!まぁなんかどこかに問題があるとは思うんだけど、とりあえず期待通りの結果を得られた。

もし「本当はこうするべきだよ!」という方法をご存じの方がいたら是非教えてください!

おまけ:

その後ツイッターでこんなやりとりが。この続きはあるのか…?










追記




    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。



昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。

が、21世紀に入って10年以上過ぎている今日、GitHub等のソーシャルコーディングを可能とするプラットフォームを使っている現場においては非技術者も積極的にコードやドキュメントの状態の閲覧、そして時には自ら介入して意見を言う必要があると思っている。そしてプライベートなプロジェクト等ではそのためにGitHubにアカウントを持つべきだと思う。特に小さいチームにおいては全員がプロジェクトに参加できるようにするべきではないだろうか。自分は100人も200人もいるチームなら別だが、10人、20人のチームであるなら自分達が関わっているプロダクトの開発がどのように行われているのかせめて見える・見るようにするためにGitHub等に積極的に参加するべきだと思っている。





自分がこれを必要と思う理由はいくつかある。

まずは分業文化を避けるためである。ある程度それぞれの部署で自力でどうにでもできる大きさの企業なら分業制は効果があるだろうが、小さいチームでは一蓮托生。全員での密なコミュニケーションを取り、なにが今必要なのかをちゃんと共有する必要がある。非技術者がコードやドキュメントの状況を見られない、というのは「自分はコードには責任を持たない」という気持ちを肯定する意味があると思う。それでは駄目だ。当然実装には関わらないが彼らにも当事者でいてもらわないといけない。営業や顧客対応をしている人達こそがプロダクトの本当の姿を知っているのではないだろうか。彼らこそがエンジニアのケツをひっぱたくべきなのではないだろうか。もちろん、全体の状況を鑑みて取捨選択をしたり、エンジニアを余計な労働から守る人も同時に必要にはなるが、それもまた密なコミュニケーションにより状況を相互理解しあう事が必要だと思ってる。

次にエンジニアの怠慢を避けるためである。これは前の点と根っこは一緒なのだが、自分も含めエンジニアというのはやりたくない機能の実装や修正はとにかく先延ばしにしたい、というのが本音だと思う。たまに意識の高い人もいるが、それは稀であると思う。基本人間怠けたいものだ。プログラムを書いている側というのは自分が書かなければ何も始まらないという圧倒的アドバンテージを持っているため、立ち回り方を間違えなければエンジニア以外の人から見たら信じられないほど怠けることができる。秘密にしてたんだけど、ここではしょうがないのでバラす。僕の元クライアント・元同僚の皆様、僕はあなたたちに気づかれないようにかなり怠けてきました、すみません。ところがソーシャルコーディングプラットフォームを使って可視化することによって、多少鼻の効く非技術者が混ざればこの辺りが圧倒的にやりにくくなる。非技術者が実装して欲しい機能を技術者側から「えー、それはやりたくない…」と言われても、開発の状況をなんとなく見つつもう一歩突っ込めそうなタイミングで突っ込んでみる、ということができるようになるわけだ。

そして最後に自分達の命運がかかっているプロダクトの本当の姿を知ってもらうためだ。営業、運用、みんな自分達のプロダクトがどういう状態なのか知っておくべきだ。問題がある部分やすごくうまくできてる部分。どれも知ってるべきだし、その状況に合わせておのおのの仕事の戦略を変えるべきだ。何もエンジニアはプロダクトをSGUPP(スーパー・グレート・ウルトラ・パーフェクト・プロダクト)レベルに常にしておく必要があるというわけではない。現実とのバランスを取りつつ「ここは手を抜く」「これは駄目駄目だけど、とりあえずの形で実装しておく」などの取捨選択をせざるを得ないだろうし、それが普通だ。でもその状況をチームは共有すべきだ。

PRs


もちろんこのような事を実現するためにわざわざGitHubのアカウントを取るのではなく、ミーティング等で共有する、というのはありだろう。だけど俺が共有のための報告を行う場合、相手が開発の状況を何も知らないのなら俺は絶対に話の内容を盛ります。面倒くさい追求を受けたくないから、実害のでない範囲で嘘もつきます。そしてなによりミーティングはみんなの時間と生産性を奪う。昔ならばこの辺りの情報共有をしたかったらレポートに色々まとめないといけなかったのだろうが、2015年である。GitHub等のツールが使える。パーフェクトなツールではなくとも、issueの報告もできればwikiも書ける。コードの統計情報も見えるし、テストが通っているかという状況も見えるし、実装についてのエンジニア同士の喧々囂々も読める。

要はこの手の情報共有をするためのコストが10年くらい前と比べると圧倒的に低くなっている。もはや少なくともGitHub等に参加することによってコードの状況を見る事がコスト増(=損)にはならない。見ない事はマイナスになりえる。

エンジニア達は非技術者達にもっと自分達のやってることを見せるべきだし、非技術者達は恐れずにもっとプロダクトの中身の光と闇に向かい合うべきだと思う。




おまけ。若干違う論点だけど、似たようなトピック:
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

タイトルの通りなんですが、某急成長中/快進撃中のあの企業を11月末ですごくサクッとやめて、イベント運営サポート・チケット販売システムをやっているスタートアップであるPeatixにジョインしました。とりあえずインフラ周りをがっつり整備する方向。

この話をするとわりと真顔で「え、なんで?あの会社を辞めるなんてなんか事件でもあったの?!」って感じの反応をされるんだけど、そういうことではないのでそこだけ説明のため好きでもない退職・転職エントリを書いている次第です。

まず、なにか事件があったわけではない。べつになーんもなかった。子供のお迎えとかをしてても基本文句も言われなかったとか、色々融通を効かせてくれてたのは明らかだし、そのまま居れば皆も知ってる勢いのある企業でボチボチ高給取りでいられたかなーとは思う。

だから退職せずにもっと良い方法を模索すればよかったのかなぁとは思わないではないけど、やっぱり自分は自分が役に立っていると感じられる所で働きたかった。自分の見える範囲では自分がこれ以上いても会社も自分もお互いなーんのメリットもなかった(特にこのままの状態であと数年同じ事をしてたら絶対に自分が使えない人間になってしまうという恐怖を感じた)ので、このたび分業制の大きな会社には見切りをつけて自分が全部やらないといけない、もう少し汗をかける煮え煮えな現場に身を投じる事にしました。あと折角誰にでもわかりやすい形でTOEIC受けて950990点取れたから英語で仕事もしたかったし、もっと海外も含めたカンファレンス等でも発表したかったし、もしそうしたかったら世界のどこに住みながら仕事しててもいいよって言われたし。

ちなみにPeatixではAndroid/iPhoneエンジニアとか募集してるみたいですよ

というわけで2015年はもう少し表立って色々やるような気がします。YAPC::Asia Tokyo 2015もあるし、本年もよろしくお願いいたします。


思い起こせば出戻りでlivedoorに行ってからその後5年弱在籍した。今回わかったのは「あー、俺livedoorすごく好きだったんだなぁ」ってことだな。もうlivedoorはないからさすがに戻る事はなさそうだな。さよならlivedoor
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

2013年年末に次男が産まれて晴れて年子の男の子二人の子供の親になってしまったので2014年は忙しすぎて全体的に記憶にもやがかかっていてる。基本いくら思い出そうとしても「保育園への登園」「保育園のからのお迎え」「子供の風呂」「子供の飯」「子供の寝かしつけ」しか思い出せない



と、思っていたら「peco作ったやないですか><」言われて「あー、そういえば!」となった。あれ、Rebuild.fmに出たの今年だっけ?あ、あとそういえば某急成長中企業を退職したんだった。 色々あってYAPC::Asia Tokyo 2015をやることになって、慌てて会場を探してなんとか借りれる事になってアナウンスしたりもしたなー。年末はDocker漬けでDockerのツールとか書いてたな。あとは思い出せないかブログにはかけない事ばかりや…

まぁわりと開発的にはスローな1年だった(それもあって転職という道を選んだ)が、個人の活動としてはとにかく目の回る忙しさだった。来年はもう少し外に出て行く機会を増やして行く予定なのでもう少しアウトプットが増えるかもしれません。そうなるといいな。

それでは皆様よいおとしを。


    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

最近自分のSNSのフィードを読んでいる方には色々と新しめのツールを使ったりして今までやれなかったことをやろうと色々とつまづきながら学習しているのがわかると思うのですが、その一環としてConsulやらなにやらをがっつり使おうと思ってさー、やるぞ!と思ったら二つほど問題があってはまった:
  1. Consulもぼちぼち設定が面倒くさいからDockerで投入したいのに、DockerにARPまわりにバグがあるらしく、UDP経由のraft通信が時々おかしなことになる(多分コレ
  2. 何百台もマシンを使いたいわけじゃないから、Consulの認証・セキュリティ周りを設定するのがだるい
ConsulはDNSのインターフェースが非常にすてきで使いたかったんだが、うーーーーむ。registratorも見てみたんだけど、なんかAddress欄がうまくコンテナが動作してるサーバーのIPアドレスになってないような感じもして微妙〜〜〜〜な感じを受けた。削除もうまくいかなかったし… そしてドキュメントが… う〜む。

というわけで一歩戻って「俺は何をしたいのか?」と考えたところ、したいことは「コンテナをデプロイした時に何かトリガーを走らせたい」というだけだということがわかった。これなら小さそうだし、ちょうどregistratorのコードを読んでdocker remote APIも把握したところだったので、じゃあ、ということで二つほどツールを書いた。

tp (lightwegith template processor)

tp=template processorのイメージ。もうアホみたいに簡単なツール。ただただシェルスクリプトとかでJSONをSTDINに受け取って、テンプレート(goのtext/template形式)に渡して処理してSTDOUTに吐く。それだけ。だけで手元にあると超便利じゃね?

こんな感じで、curlでJSONのAPI叩いて、直接流し込む感じで使うイメージ

001


dockeractd (docker event receiver)

dockerの走ってるサーバー上でコンテナの開始とかのイベントを受け取った時に任意のコマンドを動かすためだけのツール。 コンテナが作成された、稼働した、止まった、等々のイベントが受け取れるので、それをJSON形式でSTDIN経由で任意のコマンドに流す。それをどうするかはあなたの自由。分散システム的な要素はないけど、serf agentの動きに似てます。

自分の意図としてはとりあえずdockerでアプリのコンテナを起動した時に前段にあるnginxのupstream設定を書き換えてHUPしたい。それだけ!

001


あ、コマンドラインの引数とか途中までしか書いてないし超絶いけてないので、PRとかissuesとかまってます。


 
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

「なんか外部CIサービスだるいなー」「リリースとかもうローカルの環境でやりたいなー」「マシン取っ替えてもすぐ環境作れるようにしたいなー」などなどの欲求があったのと、go1.4がリリースされたのもあってDockerで全部自動化してみた。

戦略としては
  1. Travis CIとかの連携は残すけど、手元でいつでも同様のテストを走らせられるようにしておく
  2. リリースは手元でバージョン指定すれば基本的に一発で通るようにしておく
実装は単純で、ubuntuベースのイメージに必要なgoのバージョンとツール類(goxcghr)を展開しておいて、pecoのディレクトリは後からdocker run -vでマウントできるようにしておく

使う時は先にイメージを作成しておく(キャッシュ使ってるから当然素早く走りますね!)

001

あとはpeco-dockerレポジトリについてくるスクリプトでCI的なテストとリリースができる。(リリースは本当にリリースはしっちゃって面倒くさいのでここではテスト画面だけ)

001

test.shの中身は基本的に"docker run peco-docker:go1.4 /test-docker.sh"というコマンドを実行しているだけです。

で、先ほどpeco v0.2.11 をリリースしましたバグフィックスと機能追加両方ありますので、是非お試しください。

というわけでdockerを使ってpecoさんを手元で色々できるようにしてみた、というお話でした。オーケストレーションは色々と微妙なところはあるけど、こういう単純な自動化にはdockerすごいフィットしてる感あるという感じがしましたね。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

YAPC::Asia Tokyo 2015 は ななななんと!8/20-8/22にビッグサイトで開催されます! まだまだ本番までは時間はありますが、本エントリではどどーーーーーんとその辺りを先取りして 皆様に紹介したいと思います! 

もしこれを見て「スポンサーに興味あるんだけど、この会場だったら○○とかできる?」というような興味が湧いた方は是非こちらのフォームからお問い合わせください続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

このページのトップヘ