読者です 読者をやめる 読者になる 読者になる

i remember nothing

文章の練習も兼ねています

昨年度から現在に至るまで、その振り返り、リクルートであったことの話

一年前の今頃、私は新卒エンジニアとしてリクルートに採用され、出向先のリクルートマーケティングパートナーズで実務をやっていた。 就活は自分にとってロシアンルーレットみたいなものだった。どんな会社でも入ってみないと善し悪しがわからない。だからここは運試しだろうと、内定した企業のうち一番提示年収が高くサービス内容が興味のあるジャンルである(いわゆる英語教育系のサービスであった)リクルートに入社した。 でも、2ヶ月後に休職し、気づけば入社半年後には退職していた。

リクルートでは、内定が出る時点でミッショングレードというものが提示される。平たく言うと、そのランクに応じて与えられる業務目標が設定され、年俸が変わるというものだ。 だいたいの新卒は同じミッショングレードを与えられる。私も標準的なグレードを与えられ、承諾した。ただし様々な理由で少し高いミッショングレードを与えられるやつもいた。

そして4月に入社、同期たちは各々の出向先で勤務を開始した。 そして上述したミッショングレードの高い新卒、そのうちの1人が同じ出向先で同じチームで開発することになった。 ここで、高いミッショングレードの彼に与えられたミッションが何だったかというと、「他の新卒同期たちのマネジメント」であった。 これは当の本人にしか知らされず、標準グレードの我々は知る由もなかった。 そして、この彼と私は完全に合わなかった。私は彼に関して何も認めることができなかった。 より正確に言うと、私が迎合しきれなかった。

おそらく彼は焦っていたのだろう、まず、遅刻する人間に注意する。それはいい。リモートワークを許可されるよう上司たちにアピールするように言う。ここで私は少し反論というか、提案をした。リモートワークはもともと契約上提示されていたものであり、それをする権利は本来そうやって手に入れるものではないではないかと。というか、同じ同期同士なのになんでそんな上から目線でものを言われなければならないのかと。上述のとおり、彼が新卒のマネジメントを任されていたことは、標準グレードの我々は知る由もなかった。

これがまずかったのだろう。自尊心の高く精神的に強いわけでない人間は自分の思い通りに動かない人間が許せなかったようだ。私はまくしたてるような口調で反論され、萎縮してその場をなあなあに済ませてしまった。 そこから、私を含めた彼に「許容されない」同期たちへの威圧的な態度が目立つようになった。 相互フォローしているTwitterで彼に嫌味を言われる。休日に突然グループチャットを立てる。そこで彼は他の同期に対して「人間性がクズでも技術力があればいいと思ってるんですか?」「心身の不調を言い訳にするな」などのことをまくしたてた。これは私に対してではなく、他の同期にたいする言葉であった。そうであっても私にはしんどかった。(ここは細部までは覚えていないのでちょっと言葉が違うかもしれない)

他にもいろいろあった(現場におけるサービスに対する教育事業としての意識の希薄さなど)が、もともと従順ではない上に気が弱く、威圧的な態度や嫌味などが得意でなかった私は、そこから2ヶ月もたたずにここで働くのは無理だ、このままでは自尊心をボロボロにされてしまう。

私は会社に行くのをやめた。

それから、彼は一ヶ月後に別会社に行くということ、なので彼にはもう接する必要がないということを上司から伝えられ、復帰した。 彼が怒りや不機嫌で同じチームの新卒に怒りをぶつける時点で彼に与えられたマネジメントのミッションは失敗したとは思うが、その後彼がどういう扱いになっていったのかは聞いていない。怒りや不機嫌で他人をコントロールしようとするのはマネジメント能力が足りないからだと私は思う。

しかしこれで復職、安心かと思っていたが、そうではなかった。 彼に対して従順でいられた人たちに、私が嫌われないはずがなかった。 嫌われるだけならまだいい。仕事にそれを持ち込まれ、あからさまに態度に出されるようになってきた。

有給を取った次の日にリリース日が変更されたことを私は知らされず、なんとなく気づいて聞いたときにはもう時間が遅すぎた。

そして、とにかく決まりが多い。マージまでのフローがとにかく多すぎる。 レビューが遅い上に自分の作業がある間はレビューをしない同期もいて、それを待たないとこっちのコードもレビューが通らず、スプリント内にチケットが1つも終わらないことは多々あった。もちろん自分の作業能力にも問題はあった。自分の能力のなさ、発揮できなさ、そしてこの何も進んでいるように感じられない状況に私は焦りがつのっていった。

また、相互フォローしているTwitterで同期に嫌味を言われる。前回の私の件で、チーム内にはその辺の注意が行ったらしいのだが。 別会社に行った彼はその嫌味に対して「ツイッターでそういうこと言っちゃいけないんだよ?w」(意訳)などとリプライを送っていた、会社の上司がそのリプライに混ざったり、ツイートをお気に入りに入れたりしていた。

辞める間際では、自分のレビューが無視されたり、自分のレビューだけレビューをされず何日も放置されたりもしていた。

そして、 疲れたので会社をやめた。こいつらの言いなりにはなるくらいなら辞める。 やめる際に人事の方に今後の体制について考えておきますとは言われたが、実際にどうなったかは、私の知る由もない。

会社をやめ、退職エントリ

ussopyon.hateblo.jp

を書き、ほしいものリストからプログラミングElixirを頂いた。ここで私は Elixir, Erlang に興味を持つことになる。趣味で小さいアプリケーションなんかを書いて遊んだりしていた。 そうしてすぐ、Elixir でゲーム開発の仕事をしませんかというお誘いが来た。これは好機だった。 好きな言語で、新しい環境で働ける。こんな状況にもかかわらず、尊敬している人に一緒に働いてほしいと言ってもらえることも嬉しかった。

そうして1月からその会社で(パートナー契約で)働き始めた。 設計を考えたり、通信プロトコルに関して勉強したり、動くものを作ったり、そういったことをとても速いサイクルで進めていけた。そして作ったものに対して、(ネガティブなものも含め)いろんな反応を貰えるのも楽しかった。好きなものを考える、作る、褒められる、楽しい。 チームの方々も私のような人間にでも寛容ないい人が多く、そこも楽で助かった。過去にUnityをちょっとやっていたことも思わぬ役に立った。

自分の中では、「何をやるか」も大事だが、「誰とやるか」が優先される事項であることもわかった。

そして、時々体調を崩したりはしつつも、今もその仕事を続けている。今の仕事がうまくいくと良い。そして、いい人でありたい。でも私はあまり(今は強いられてないが)従順ではない。苦手なことも多い。失敗することもあるだろう。 でも私は、次はよりよい失敗をするつもりだ。

もちろん私の怒り補正と、主観に偏った見方によって、上述したことに時系列のズレや事実でないことも混じっているかもしれない。 ただ私は今でも怒っているのは事実だ。 見返してやることを原動力にして何かを頑張ることも未だにある。

体が弱いことによる不安

今日は体調が悪く会社を休んで家でずっと寝ていた。

もともと体は強い方でないので月に一度くらい仕事を休んで平日に1日くらい寝込んでしまう

そうなると1日何もできなかった気持ちで落ち込む。

体が丈夫でさえあればもっと出来ることも増えるのにとか考えると悔しくもある。生まれつきのものなので仕方がないが。

こう書くと体を鍛えろとか食事に気をつけろとか言われるかもしれないが週に三回はジムなどで水泳やランニングをしているし三食自炊しているし夜は7時間は睡眠時間を確保するようにしている。

それでも体調維持が難しいのはもうどうしようもないので、他の健康な人より生産的な活動や読書や勉強に割ける可処分時間が少なくなる。

 

それを踏まえていかに短時間で効率よく物事をこなせるか、を健康な人より重要視して生活する必要があるのかもしれない。

体力づくり

最近ジムに通ったり自宅で筋トレできる道具を導入したりなどして体力づくりに力を入れている。 もともと週一くらいのペースで水泳はやっていたし、私の容姿を知っている人ならわかると思うが、体格はいいほうである。 身長166cm, 体重58kgで超健康体型。 なので、目的は見た目を変えることではなく、体の不具合を減らしたりとか、生活する上での基礎体力をつけたいとかその辺。 10月から年末にかけておそらく忙しくなるので、その期間をぶっ倒れることなく駆け抜けられるよう下準備したいという側面もある。

あとはなりがちな貧血に気をつけること。 鉄分が多そうな食物を優先的に取る。 遅くても日付が変わる頃には寝る。

今はそこまで忙しい時期でないので、忙しくないときにしかできなさそうなことを優先してやっている。

行間がスカスカ

私のブログを読んでもらっている人から、「文章に行間が空きすぎているからもっと埋めた方がわかりやすいと思う」

というコメントをもらえた。

自分では全くそんなつもりはなくて、というか行間というものの存在を全く考えないまま、技術的な文章はともかく、普段の日記だとか雑記みたいなものは思うままに書いていた。

 

行間を埋めるという言葉を聞くと数学書を割と熱心に読んでいた時期を思い出す。数学書を読む人たちはみんな、本のあるセクションの記述を理解することを「行間を埋める」と言っていた。

これはまさに文字通り行間を埋める行為で、たとえば一行目になんらかの公理や式が書かれている。

二行目にそこから推論されるであろうことが書いてある。

 

この一行目と二行目の間の、本には書かれていない推論を自分で考えて式と文章にまとめる、そういう作業を「行間を埋める」と言っていた。

 

確かに何かを説明するとき、言葉と言葉の繋がりが出てくる。自分の中では当然であるが、そこを第三者から見て一見繋がりがないように見える。

そこで、その言葉と言葉のつなぎとしての言葉を考える。それが行間を埋めるという行為なのであろう。

いざ行間を埋めようとするとき、つまり言葉と言葉を繋げる言葉を考えるとき、自分の中では繋がっていたはずのものがパッと出てこない時もある。自分で書いたはずの言葉の行間が埋められない。

 

なんとなくわかっていた事、この「なんとなく」を明らかにするのは難しい。よくよく考えてみると自分でもよく理解してないのに言ってたことに気づいたり、また考えた末ひねり出した言葉からまた行間の隔たりを発見することもある。

 

言葉と言葉の間はなんとなく繋がっているようでつながっていない。そこには無数の隔たりがある。

 

Elixir Conf Japan 2017に参加しました

www.elixirconf.jp

4/1にあったElixir Conf Japanに行ってきた。

Elixir自体は去年の年末に触り始めた。そして1月ごろからゴールドスポンサーであるアカツキさんのところでお手伝いしていて、そこで Elixir を書いている。

そんなときちょうど今年 Elixir Conf Japan第一回やるぞということで、タイミングに感謝して参加を申し込んだ。

普段この手のカンファレンスに行ったことがあまりなかったので、少し身構えて行ったが全然そんな必要はなかった。

始めにElixir の作者 José Valim さんの発表。Elixirのこれまでの経緯や型や今後の展望など熱く語ってくれた。

やさしい英語で話してくださり聞き取りやすかった。

午後からの発表は大規模運用やErlangVM, OTP, FPなどと多岐にわたり、やっぱ落ちにくいのがいいよねとか、一方でプロセスデザイン難しいよねとか、VMチューニングなどその辺のマニアックな話も聞けた。

今後のErlang/OTPの話なども。とはいえここで詳細を説明するつもりはなくて、発表資料はほとんど公開されているのでそちらを見ると温度感がわかりやすいと思う。

どの発表も楽しかったし、あらためて Erlang/OTP の基礎概念に興味を持った。 Erlang/OTPとElixirやるぞ!という気持ちになった。

あまりメジャーでない言語で400人近くの参加者が来るのはすごいし、以前からコミュニティにいた人にとってはやったぜという感じなのだと思う。(私は増えた側の人間なのだけれども)

懇親会は体調の問題で行けなかったが来年は行きたい。

発表された方、参加した方、企画、準備に携わった方々、ありがとうございました。

プロフェッショナルSSLTLS 2.1章, 2.2章

TLS はいくつかのメッセージで構成される二者間のやりとりを安全にするために設計された暗号化プロトコルである。

2.1 Record プロトコル

TLS は Record Protorol によって実現されている。 このRecord Protocol がコネクション状の低レベルのメッセージの転送を全て担う。

ヘッダにContent type, バージョン、レコード長などの情報が格納されている。 そのヘッダの後にメッセージのデータがくっついている。

Record Protcol は通信の重要かつ高レベルな側面の抽象化の基盤となるプロトコルとなる。

  • メッセージの転送

レコードの長さには制限がある(26384byte)。それより長いバッファはRecordプロトコル によってチャンクに分割される。その逆もある。

  • 暗号化及び完全性の検証

TLS の最初の接続におけるメッセージは保護されない。 一旦ハンドシェイクが完了したらネゴシエーションしたパラメータに基づきレコード層による暗号化と完全性の検証が行われる。

  • 圧縮

TLSの圧縮機能は現在は使われていない。2012年にCRIME攻撃に利用された。

  • 拡張性

Record Protorolが担うのはデータ転送と暗号処理であり、他の部分はサブプロトコルで行う。 サブプロトコツの追加は簡単なのでTLSの拡張ができる。

TLSでは4つのサブプロトコルが規定されている。

2.2 Handshake プロトコル

2点間通信の両サイドはTLS接続で使うパラメータのネゴシエーションと認証をHandshakeプロトコルで行う。

以下の三つの一般的な流れがある。

  • サーバ認証を伴うフルハンドシェイク
  • 前回のセッションを再開する場合の一部のメッセージを省略したハンドシェイク
  • クライアントとサーバの認証を伴うハンドシェイク

Handshake protocol のメッセージのヘッダには メッセージの種類、 メッセージの長さという情報が含まれている。

2.2.1 フルハンドシェイク

TLS の接続はハンドシェイクから始まる。 クライアントがサーバとセッションを行ったことがない場合、TLSセッションを確立するためにフルハンドシェイクを実装することになる。

  • 一連の図

[Client]<–>[Server]

ClientHello ——-> | クライアントが新規のハンドシェイクを開始し、希望する暗号スイート、鍵交換の方法等のパラメータをサーバに送る

<——- ServerHello | サーバがパラメータを決定する

<——- Certificate | 証明書チェーンを送信する

<- ServerKeyExchange | マスターシークレット生成に必要な情報を送信する

<— ServerHelloDone | 終わったよ

ClientKeyExChange -> | マスターシークレット生成に必要な情報を送信

ChangeCipherSpec –> | 暗号通信に切り替えたよ

Finished ———-> | ハンドシェイクメッセージのMACを送る

<– ChangeCipherSpec | 暗号通信に切り替えたよ

<———- Finished | MACを送る

ClientHello

新規のハンドシェイクで常に送信される。

送信される。

主な情報は、

  • Version
  • Random

32byteのデータが含まれている。そのうち28byteは無作為に生成される。残りの4バイトはクライアント側の時刻情報が入る。

  • Session ID

既存のセッションがある場合に一意の識別子が入る。現在のセッションの状態をサーバが自身のキャッシュを持っておけるようになっている。

  • Cipher Suites

クライアントが対応可能な暗号スイートが格納されている。

  • Compression methods

クライアントが対応している圧縮方法を指定する。

  • Extentions

付加的なデータを運ぶ拡張が任意の数だけ含まれる。

などである。

ServerHello

構造はClientHelloと同じ

クライアントの要求プロトコルに答えられない場合プロトコルの別バージョンを返したりする

Certificate

X.509 証明書チェーンを運ぶ。(それ以外の形式のもの、たとえばPGP鍵を利用することもできる)

証明書チェーンはASN.1 の DER を使用してエンコードされた証明書を順番に並べる。

ServerKeyExchange

鍵交換に必要な付加的なデータを運ぶことができる。

ServerHelloDone

予定していたハンドシェイクを全て送信した時にサーバから送る合図。これを送ったらサーバはクライアントからメセージが来るのを待機する。

ClientKeyExchange

鍵交換に必要な情報をクライアントから送信するためのメッセージ。

ChangeCipherSpec

接続に使うパラメータに十分な方法を全て手に入れ、暗号処理に移行することを相手に通知する。 クライアントサーバの両方がこれを送信する。

Finished

ハンドシェイクが完了した合図。

このメッセージは暗号化されているので通信の両端で安全に交換できる。

verify_data というフィールドを持っていて そこに両端で受け取ったハンドシェイクメッセージをすべてハッシュ化した値とマスターシークレットを組み合わせて計算したものが入っている。

このメッセージは完全性が保証されているので第三者による捏造や改ざんはできない。

  • TLS 1.2 では Finished メッセージはデフォルトで 96 bit。SSL3.0では36 byteであった。

2.2.2 クライアント認証

クライアント認証を要求できるのは認証済みのサーバだけ。

CertificateRequest

サーバはクライアントに対する認証の要求を許容できる証明書の公開鍵と署名アルゴリズムの伝達に用いる。 許容できる認証局の一覧を送ることもある。

CertificateVerify

このメッセージにはその時点までにやりとりした全ハンドシェイクメッセージの署名が含まれる。

2.2.3 セッションリザンプション

フルハンドシェイクはクライアントがアプリケーションデータを送信できるようになるまでに2往復のやり取りを要する。

ハンドシェイク中はCPU負荷の高い処理がなんども必要になる。 省略版のハンドシェイクを使うことでオーバーヘッドの大半を回避できる。

セッションリザンプションは Sesson ID という識別子を用いてセッションの再開を可能にする仕組み。

サーバがセッションに対してSession IDを割り当てる。 クライアントとサーバはこのSession IDを一定期間保持しておく。 これで以前のセッションを再開しようとした場合、Session IDをデータに含めることで以前共有したマスターシークレットをつかって新しい暗号鍵を生成し、暗号通信に以降することができる。 これによりハンドシェイクが短くなりネットワーク上のやり取りが1往復で済む。

session ticket という似た別の方法もある。これはRFC 5077として導入されている。 こちらの方法ではクライアントが情報を全て保持する。

プログラムを書くという行為は残らない

私たちはプログラマなので、日々プログラムを書いて製品にしてリリースする。リリースされると一区切りつく。 ユーザーは動くソフトウェア、または納品されたコードを見る。

プログラムは確かにファイルとして残る。ただしそこにプログラムを書くという行為が残るわけではない。 プロダクトとしてのコードは残る。ただしそれは日常として、コードを書いている時間の一点を取り出したものであり、プログラムを書いているという連続した行為そのものが残るわけではない。 コミットログの一つ一つを切り出してみても、コードそのもの、またはそれに付随した思考の残滓が離散的に切り出されたものでしかなく、コードを書いている主体、思考の断続的な流れは残らない。 ピアニストにとってのコンサート、小説家にとっての小説がそうであるようにだ。

狂気の巡礼

狂気の巡礼