Scala Best Practiceの和訳を進めています

少し前からScala Best Practiceの和訳を進めていて、現在0章と1章が済んだところ。

github.com

ライセンスはCC BY 4.0だけど、一応著者本人に声かけとくかな―と思ってた矢先に、一緒に和訳してくれている知人が知らせてくれていた。

github.com

こんなことやってる、ということを同僚に伝えたらあれよあれよと各章の担当が決まり*1、大変感謝している状況なんですが、多くの人の目に触れた方がより良い翻訳になるので、ここの表現おかしくない?などの意見はドシドシご指摘ください。

*1:なお自分は全然英語が出来ず、「バンドやろうぜ!当方ボーカル」状態である

次世代 Web カンファレンス #nextwebconf に参加してきた

2015年10月18日に開催された「次世代 Web カンファレンス #nextwebconf」に参加してきました。

次世代 Web カンファレンス - connpass

server_perf

以下自分のつぶやきと参考になったツイート

server_arch

server_archでは開始早々、@yuguiさんが開発したJSON APIへの変換プロキシ生成機"grpc-gateway"の話となった。

そもそもgRPCとは、HTTP/2の利点である双方向ストリーミングや多重リクエストを扱えるRPCフレームワークであり、C、C++、Java、Go、Node.js、Python、Rubyなどの言語をサポートしている。

新しいオープン ソース HTTP/2 RPC フレームワーク、gRPC のご紹介 - Google Developer Japan Blog

ただ、gRPCはすべての言語をサポートしているわけではなく、かつHTTP/2が必須なため、これを今までのJSON API、HTTP 1.1でも動かせるようにするためのものが"grpc-gateway"とのこと。

gRPC-JSON proxy - 世界線航跡蔵

以下自分のつぶやきと参考になったツイート

standardization

(昼飯で抜けてたので途中からしか聞いていない)

以下自分のつぶやきと参考になったツイート

http2

以下自分のつぶやきと参考になったツイート

front_arch

以下自分のつぶやきと参考になったツイート

さいごに

主催してくださったJxckさんを始め、登壇された方々ありがとうございました。とても濃密でWebの未来について感じることができた1日となりました。

今回俺がいかにして転職したか晒す

9月から新しい会社で働き始めました。折角なので今回どのように転職したのかをまとめておきます。

何をつかったか

今回はWantedlyをメインに使って転職活動を進めてきました。前回の転職ではエージェントを使いましたが、今回は自分のペースで活動したかったのでエージェントは使いませんでした。

www.wantedly.com

期間・エントリー数

期間は3月~8月の間の5ヶ月間、活動しました。エントリー数は全部で6社となりました。

準備

プロフィールを書く

とりあえずWantedlyのプロフィールを埋めました。経歴、このさきやってみたいこと、作ったアプリなどは特に公開しておけばいいと思います。

履歴書・職務経歴書

企業によっては、エントリーしてすぐに履歴書・職務経歴書をメールで送ってほしいというところもありました。履歴書は、Wantedlyの「できる履歴書」で書くと写真込みでPDF出力できてすごく便利でした。

www.wantedly.com

職務経歴書版も是非欲しいですが、職務経歴書はフォーマットが様々なので厳しいのかもしれません。

企業にエントリーする

まずは1社エントリーすると良い

Wantedlyの場合、おそらく1社でもエントリーすれば最近活動のあるユーザとして企業側に伝わるようで、初エントリー後はスカウトがよく来るようになりました。*1

エントリー後の流れ

エントリー後はWantedlyのチャットでその企業の担当さんとやりとりします。 大体の流れとして、

  • 面接の日程調整
  • 履歴書・職務経歴書 → リモートで技術テスト
  • リモートで技術テスト → 面接

というケースがありました。この中ではいきなり面接というケースが一番多かったです。

福利厚生については別サイトで

Wantedlyでは、その企業がどのような活動をしているか、どのような技術を使っているかはわかりやすくなっていますが、福利厚生などがわかりにくいのでそこは別サイトに頼る必要があります。(実際に福利厚生について質問したら別サイトのリンクが渡された)

企業の規模でレスポンスに差がある

これは経験則ですが、社員数が十数名の企業はエントリーしてから数日で返信が帰ってくるのに対し、社員数3桁以上の企業は返信に2週間程度かかりました。これはその会社のエントリー数にもよると思いますが、転職活動のスケジュールを考える上で注意が必要です。

さいごに

最近自分の周りで転職を考えている人が増えてきているので自分のケースをまとめてみました。何かの参考になれば幸いです。

*1:数えてみたら16社あった

YAPC::ASIA Tokyo 2015に参加してきた #yapcasia

YAPC::ASIA Tokyo 2015

2015年8月22日に開催されたYAPC::ASIA Tokyo 2015に参加してきました。1日目は参加できず2日目のみの参加です。なお僕は初参加で、かつYAPCは今回で最後らしいです。

セッション

yapcasia.org

スピーカーのNathan LeClaireさんはDocker Machineの中の人。Polyglotとは複数言語、複数のツールを扱う人のことを指す。

今まで、エンジニアが新しい技術を学ぼうとするとき、毎回開発環境の方法を学ばなければならず、それが新しいユーザ参入の障壁となっていた。特に今のフロントエンド界隈は6ヶ月で新しい技術が生み出され(AngularJS,React.js,Grant,Gulp,etc..)、そのたびに環境構築に学習コストを払うのは辛い。

Dockerの魅力はそういった参入障壁をなくし、誰でも簡単に開発を始められるようにすること。ユーザの島と技術の島の橋渡しをする存在ということでした。

なお、質疑応答でDocker.incの中の人はほとんどがboot2dockerを使っているとのこと。

yapcasia.org

speakerdeck.com

Docker3兄弟とは、

  • Docker Machine
  • Docker Compse
  • Docker Swarm

のことを指す。(勝手に呼んでいる)

これにDocker Toolboxが加わり4兄弟になった。Docker Toolboxは3兄弟 + VirtualBox + GUIツールの全部入り。

Docker3兄弟のおかげでDockerがゆるふわに使えるようになった。開発環境では十分利用可能で、プロダクションに使うにはまだ課題があるがロードマップが提示されている。

yapcasia.org

togetter.com

歴代の実谷委員長が集まり、今までのYAPCの思い出話から、イベント運営に関するノウハウが語られました。以下内容を箇条書き。

  • 入場者数は300人から2000人
  • スポンサー数は6社から60社
  • ワイエーピーシー?ヤップク?ヤップシー。
  • ✕ 「ヤップシーアジア」◯ 「ヤップシーエイジア」
  • ライチタイムをリジェクトしたらTwitterが「お腹すいた」で溢れた
  • トーク観るのは素人
  • LTはYAPC発祥(Asiaではない)
  • 高橋メソッドもそこで生まれた
  • 大学を会場にしたいときはヒエラルキーを理解する

yapcasia.org

www.slideshare.net

mozaic.fmのJxckさんによるHTTP2のお話。

HTTP2はすでにRFCになっており、策定するフェーズから使うフェーズになっている。既にいくつかのHTTP2実装が世に出されている。

HTTP1.1はシンプルな分、これ以上速度をあげることに限界がきていた。Keep AliveやFile Concatなどの実装を駆使して対応してきたが、これらはバッドハックであり、ビルドシステムなどが複雑化していく。

HTTP2は1つのコネクション上でストリームを多重化することで、3 way handshakeが1回で済み、パフォーマンスの一番美味しいところを維持できる。

かつ、セマンティクス(各メソッドの意味とかHTTPステータスの意味とか)は維持され、下位互換も保証される。

我々はどうするべきか?

  • よく知らない/導入しない

HTTP1.1はこれからも生き続けるので問題ない

  • 理解した/導入しない

戦略としてはありだが、今後もパフォーマンスのためにバッドハックをし続けなければならない。どこかで見定める必要あり。

  • よく知らない/導入する

エコシステムの成熟しだいではあり。そもそもHTTPはよく知らなくても動くべきだし、既にクライアント(ブラウザ)は知らないうちに導入されている。(ただ、エンジニアとしてはどうなの...)

さいごに

特に何を聴くか考えずに来たけど割りとDocker寄りになったので自分でも興味があるのだろう。Dockerちゃんと勉強します。

とても素晴らしいイベントだっただけに1日しか行けなかった悔しさとこれで最後という悲しみがあります。実行員会の方々、スピーカーの方々、その他運営に関わった方々には大変感謝しております。ありがとうございました。

Photos

diffコマンドでファイルではなく標準出力を比較する(Process Substitution)

いざ使おうとして良く忘れるのでブログに書いておく。

bashやzshのProcess Substitutionを使えば、diffをファイルからではなく標準出力の結果から比較できる。(実際は/dev/fd/に一度ファイルとして吐かれるのだけど)

$ diff <(echo "hoge") <(echo "fuga")
1c1
< hoge
---
> fuga

参考:

http://tldp.org/LDP/abs/html/process-sub.html

『アジャイルサムライ横浜道場　特別編「RSGT再演 くじびきイテレーション改』 に参加してきました #agilesamurai #横浜道場

2015年5月12日に開催された『アジャイルサムライ横浜道場　特別編「RSGT再演 くじびきイテレーション改』 に参加してきました。

yokohama-dojo.doorkeeper.jp

www.slideshare.net

今回は特別回として今給黎さんを講師にお招きし、ゲームを通してスクラムを体験するというワークショップを行いました。細かいルールはスライドの方に書いてありますが、1ターンを1dayとし、1ゲームを1スプリント、場のカードをバックログに見立て、それを見ながら見積もりをします。そして手札のカードを使ってバックログを消化し、最後にふりかえりをするというスクラムの一連の流れがこのゲームに凝縮されています。

これを5セット行いますが、セットとともに追加ルールが加わります。加わるルールは以下になぞらえられたものでした。

  • 個々人が決められたタスクしかできない(単能工)
  • タスクを協業できる(協業)
  • 個々人の能力が違い、それぞれの能力をチームは把握している
  • 個々人の能力が違い、それぞれの能力をチームは把握していない

これらを通して学んだことは、

  • 決められた仕事しかできないと、スプリント内で消化できるタスクが制限される
  • 優先度が高くコストが重いタスクでも、協業できれば(タスクを分割すれば)確実に消化できるようになる
  • 個々人の能力をチームが把握していれば、見積りの精度が増す。
  • 逆に、個々人の能力をチームが把握していないと、アクシデントが起こる可能性が増す(見積もりを予測しにくくなる)

といったことでした。事実、僕らのチーム*1は能力を把握していないときの見積もりのブレが1、把握しているときが5と顕著に現れました。

さいごに

今回のワークショップはとても白熱し、たのしくスクラムが学べたかと思います。 講師をしていただいた今給黎さん、スタッフの方々、参加された方々ありがとうございました。

*1:チーム名は「Dieふごう」にしました

kawasaki.rb #23 に参加した & 寄稿した #kwskrb

2015/4/23に行われたkawasaki.rbに参加してきました。

今回はこちらのブログに内容をまとめるのではなく、kawasaki.rb公式ブログに寄稿という形をとりました。以下がその記事です。

kawasaki.rb #023を開催しました #kwskrb

大体の内容は上の記事に書かれているのでこちらには個人的な内容を書きます。 寄稿する流れとなったのは以下のツイートから

と、kawasaki.rb発起人のchezou氏がMacを会社に置いてきてしまったので、代わりにパーフェクトRubyの電子版が入っていた僕のMacで進行することにしました。初めて進行をしましたが、予想以上に大変でした。傍から見ててもてんやわんやしてたと思います。

というわけで今回試したコードの履歴は僕のpryのhistory上にあったので、ついでに寄稿することにしました。

終わってから

そういえば、今回のところは以前読書会した「なるほどUnixプロセス」で深く理解してたはずなのに、あまり気の利いた発言できなかったなぁとか終わってから思ってました。良い本ですので読んだほうが良いです。紹介は以下から。

norizabuton.hateblo.jp

最後に

kawasaki.rbの皆様ありがとうございました。次回もよろしくお願いします。