口蓋扁桃の摘出手術を受けて7日入院したときの記録。 手術を受けた理由 直接の引き金は先月初旬に扁桃腺炎で40度以上の熱を出し入院したこと。以前から1年に何度も扁桃腺炎になっていた。喉の痛みからはじまり高熱というパターン。最悪の場合は悪化して抗生剤点滴のため入院となる。年に1-2回入院していると思う。過去にも医師に摘出をすすめられたが出血などのリスクが怖くて断っていた。その代わり以下の予防に命をかけていた。 頻繁なうがい。出社、帰宅時はもちろん。トイレで手を洗うときはうがいもする。 通勤時のマスク。これは他者のくしゃみや咳からの予防目的ではない。マスクを付けていることで、自分の手が鼻や口などの粘膜に物理的に触れなくなる。つまり自分の汚い手からの感染を防ぐのが目的。 睡眠 加湿。家には加湿器が2台あり冬場はフル稼働である。 喉の腫れや痛みを感じたらすぐに病院に行き、必要があれば抗生物質を処方し

以前作った Seq2Seq を利用した chatbot はゆるやかに改良中なのだが、進捗はあまり良くない。学習の待ち時間は長く暇だし、コード自体も拡張性が低い。そういうわけで最新の Tensorflow のバージョンで書き直そうと思って作業を始めた。しかし深掘りしていくと Seq2Seq の詳細を分かっていなかったことが発覚したのでここにまとめる。間違いを見つけたらコメントか @higepon まで。 Seq2Seq のすべてを解説するのではなく、Tensoflow/nmt/README.md のチュートリアルをベースにする。読んだだけでは、理解できなかった部分を補っていく形で進める。 必要とされる前提知識 DNN の基礎。構造、training、 loss とかそういう話。back prop は別に理解できなくても可。 RNN の基礎。RNN が時系列の扱いに向いているとか。RNN の構

思いついたら追記していく or コメント下さい。 Amazon が似たようなことをやる。 中高生が結果を見せあって盛り上げる。「おまえ足短っ！」とか。 筋トレクラスタが盛り上がる。 ダイエットクラスタが盛り上がる。 夫婦間でも結果を見せ合うのに躊躇する。 ハロウィンで ZOZO SUIT 勢が現れる。 芸能人の採寸が高値で取引される。 by 匿名さん ZOZO suitを切ってであるくやつが発生。採寸スーツなのに。by id:asbjom スマホカメラで測定できるようになって、スーツがゴミになる。 by id:isawo81 Amazonが電撃買収。 by id:mongrelP ボディサイズという新手の個人情報漏洩が見られるのもそう遠い未来じゃないかもしれない。 by id:nakakzs 気になる人のデータから人形を作って抱き枕にする(´･_･`)がっきーのデータとか高く売れそう by

omo さんがおすすめしていた Deep Work を熟読した。Deep Work とは「長期間中断しない難しい知的作業」のこと。その Deep Work がいかに大事か。そしてもっと時間を費やすべきかという内容。Deep Work と対極にあるのが Shallow Work。Twitter/Facebook/Instagram で過ごす時間、メールをチェックする時間など。Deep Work を邪魔するもの。 内容は耳が痛いものばかり。自分がどれだけ「Twitter に時間を費やすこと」を正当化していたかよくわかった。自分でも気づいているものばかりで、当たり前に思える内容だが、他人に指摘されると自分の甘さがよく分かる内容だった。少しずつ Shallow Work を減らしていきたいと思う。 描いたマインドマップ

@garyu さんによる「エンジニアとして世界の最前線で働く選択肢」を読んだ。自分はサンフランシスコでアメリカの会社で働いた1つの経験しかないけど、「あるある」とうなずくところばかりでした。この本がとても良いと思うのはできるだけ公平な視点を持とうとしている点だと思う。米国で働くことのメリット・デメリットがよく分かる良い本。個人的にも子供の教育の部分は深く考えさせられた。 ぼくもそうだったけど米国で働くことへのあこがれを持っている人は少なくない。この本ではそれを実現する方法、その後に待っているであろうことが詳しく書かれているので興味のある人は手にとって見ると良いかも。

今回のブログは短く。同僚・上司たちは「日本人的な空気を読む」ことはしません。というか無理。 例1 ある日の 1 on 1にて 上司「というわけでこんなプロジェクトがあるんだけどどうかな？」 僕「・・・（うわあ。これは炎上しそうなプロジェクトだな避けよう）」 僕「（困惑顔かつ拒否オーラを出しつつ）考えさせて下さい」 上司「オーケー分かった！」 翌週の 1 on 1 上司「例の件考えた？（結構乗り気だったよね？）」 僕「（いや。空気読んでくれよ・・・いやだよ）」 この場合の1つの正解は最初の 1 on 1 で率直に「ごめん。炎上しそうなのであまりやりたくないな」とか「やってもいいけど。xxx な条件なら」などとはっきり答える。 例2 上司「おい。ひげぽん。Android の仕事が入ったぞ。やってくれ。」 僕「（え。僕 iOS が好きって言ったのに・・・断りづらい）」 この場合の1つの正解は「i

今の会社で 7 人のマネージャと仕事させてもらい、自分もマネージャになったこともある。その経験をふまえてマネージャとのつきあいかたを書いてみる。マネージャは日本的な「上司」と若干ニュアンスが違うので注意。上司というよりは役割の異なる同僚。 目的 マネージャとうまくつきあうことで以下を得るのが目的。 困ったときに助けてもらえる。マネージャ自身のマネージャのちから、マネージャの人脈を借りる プロジェクトの進め方、デザイン等。基本的に好きにやりたい。細かく口を出されない。 キャリアプランゴールを共有し助けてもらう 大きな 2 つの方針 初期の段階で信頼関係を築き、以降のつきあいを楽にする バランスのよい情報共有を目指すが over-communication よりにたおす マネージャの視点 マネージャの視点を意識すると何を伝えるべきかが見えてくる。マネージャがあなたについて知りたいのは プロジェ

Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責

エンジニアからみた良いプロダクトマネージャとは？ 1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から Tech Lead（TL/テックリード）の役割 マネージャとのつきあいかた 言ったもの勝ち/言わないと伝わらない

エンジニアからみた良いプロダクトマネージャ（以下PM）とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト（製品）マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか？と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分

1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ

スーパーエンジニアの道というと大げさだが原題は「Becoming a Technical Leader」。年齢的にもそして現ポジションもリーダーシップが必要なので読んでみた。著者はエンジニア出身でかつ、リーダーシップのセミナーを主催しているので、リーダーシップにまつわる現実的な話がたくさん。すこし冗長で読みづらかったので各章毎にマインドマップもどきを描きながら読んだ（例 これ）。 先日 id:secondlife さんにインタビューしていただいた記事 でも少し触れているのだがここ数年 Tech Lead という役割で仕事をしている。その体験と本の内容を重ねながら読み進めた。この手の本にありがちな「リーダーになるのは素晴らしい！」とか「強いリーダーになる方法！」などは一切ない。むしろ「リーダーって大変だけど。そこまでしてなりたいの？よく考えて。」とか失敗例がたくさん載っていて面白かった。某外

この記事は Evernote すばらしい！というものではない。面倒くさがりやが最終的にたどりついたのは2周半くらいして Evernote だったという話。 何か欲しい情報があったらどうするだろうか？多分 Google で検索する。何かメモをしたい場合は？ChangeLog メモ？howm? Simplenote?。もう Evernote でいいよ。消極的な意味で。設定とかほとんどいらない。マルチデバイス対応も簡単。(Dropbox とか組み合わせなくて良いんだぜ！） メモと一緒に図をくっつけて保存したい。plain text 以上に構造化してメモを取りたい。もう Evernote でいいよ。消極的な意味で。 何か保存したいときは Evernote でやれば、探すときも Evernote の中だけを探せば良い 例 旅行する。飛行機チケットの情報は Gmail に届いた予約確認メールを Web

毎朝5時に起きて出勤前にコードを書くという習慣を始めた。2週間経ったのでまとめてみようと思う。この記録が小さい子持ちの30代パパ・ママエンジニアに役立つとうれしい。多分独身で若い人には役に立たない。 始める前に抱えていた問題 好きなコードを書きたい。勉強したい。そう思っても以下の理由により以前とは比べられないほどに時間がとれなくなってしまった。 子供に可能な限り時間を使いたい。結果的に自分の時間は減る コードを書く自由時間が極端に少ない 1人になれる時間がほとんど無い 家で10分以上集中できない。こどもが遊ぼう！って誘ってくるとか 子供に話かかられたり質問されたら出来る限り応えたい とにかく疲れやすい 以下のような典型的な1日。 朝は 6:30 頃に早起きの息子に起こされる。1人で起きて絵本などを読める歳だが、静かに起きることは稀だ。トイレに行きたいとか。何かが見つからない。何だかんだで同

ちょうど1ヶ月前。フレンズのディクテーションとフレーズの暗記を毎日やることを決心した。その成果を1か月後にブログに書くというイベントをカレンダーに登録した。なのでこのブログを書いている。 なぜやるのか？ 1:1 ではなく大人数での会話の聞き取りについていけないことがよくあるから。特に仕事とは関係のない話題の場合に顕著。これはリスニング能力の問題。 日常のふとした言い回しのストックが足りないと感じていたから。例えば「病院どうだった？」「あ。僕がそっちに行くよ」「もったいないねー」など。 これらのフレーズは聞き取ることは簡単。そして意味も簡単に類推できる。しかし自分の口からは出てこない。なぜなら知らないから。 なぜフレンズか？ 英語の先生、英語がネイティブではない外国人の同僚、多くの人がすすめてくれたから。そしてDVD 全巻持っているくらいフレンズが好きだから。 工夫した点 続けられる仕組みづ

2012/1/15 をもちましてサイボウズ・ラボ株式会社を退職することになりました。 お世話になったみなさん本当にありがとうございました。 各分野でのトップレベルのエンジニアに囲まれた 4 年間は本当に刺激的でした。ラボでは良い上司（畑さん）に恵まれラボのミッションに沿う形で、比較的自由に研究・開発に取り組むことができました。外に出ているだけでも Mosh / Mio / outputz など。どのプロジェクトでも自分が実現したいこと、自分の能力と真摯に向き合う必要のあったかけがえのないプロジェクトでした。この 4 年間に学んださまざまなことは、今の自分を形成する「成分」の中でも大きな割合を占めていることを感じています。サイボウズ・ラボおよびサイボウズのみなさま本当にありがとうございました。 1 月末から新しい職場でソフトウェアエンジニアとして新たな一歩を踏み出します。みなさま今後ともよろ

タイトルの通り Key で sort 済みの Key-Value Storage を作りはじめました。 良くある DHT だと Key の Hash を取る事で分散させるので順序情報を失ってしまうのですが、それを Skip Graph という仕組みで順序情報を保持したまま分散させることが可能になります。 sort 済みだとうれしいのは KVS に対して Range Query が可能になること。 例えば、empno-999 以上の value リストを 最新10件、KVS に要求するみたいなことが出来るようになります。 従来の KVS では上記のような Range Query は不可能だったので、そこは RDBMS に任せていたと思うんですが。（RDBMS で Range Query 後、Key のリストを KVS に投げるなど） この辺りの RDBMS の負荷と分散しづらさを KVS 側

手続き 届け出場所 期限 必要なもの 備考 出生届 市町村役場 14日以内 母子手帳、印鑑、出生証明書 なし 出生の連絡 はがき投函か、市町村役場 なるべく早く 母子手帳に付いているはがき なし 出産一時金 勤め先 なるべく早く 母子手帳、印鑑 なし 児童手当 市町村役場 出生届けと同時 印鑑、通帳 1人につき5000〜10000円/月。所得制限あり、東京都渋谷区の例。国の制度らしい。 健康保険加入被扶養者へ 勤め先など なるべく早く 印鑑、申請書類 児童医療費助成 市町村役場 なるべく早く 所得制限あり。東京では乳幼児医療費助成？ 入院助産費用 市町村役場 出産費用にお困りのかた。所得制限あり 育児休業給付金 勤務先またはハローワーク 関連：育児休業中の保険料免除、育児休業中の厚生年金保険料の免除、育児休業者職場復帰給付金 確定申告（医療費控除） 税務署 確定申告時期 医療費・交通費のレ

Java並行処理プログラミングを読み終えた。ここ 1 年に読んだ技術書の中でダントツのベスト。（2位はWorking Effectively With Legacy Code） 「Java の本だから関係ない」と思った人にこそ読んで欲しい。僕もここ数年 Java のコードなど一切書いていないが、この本を読んで得たものは非常に大きかった。 この本では マルチスレッドプログラミングにおける問題と背景、その対処方法 Java が提供している API の設計と実装 を解説している。分かりやすさとレベルの高さを兼ね備えたとても良い本。翻訳も最高。 僕はこの本を読んで、Java の並行処理プログラミングは、想像を遙かに超えて進化している事に驚きを隠せなかった。何回も twitter で Java すげーと叫んだ。 これを読んでしまうと、最近僕が熱心な Scheme も含めて、自分の身の回りにあるプログ

勉強方法を勉強して分かった僕に足りなかった３つのこと。 それは 時間割 マインドマップ 復習 の3つ。 1.時間割 勉強をコンスタントに長期的に続けるならば時間割は大変有用。 時間割を作り実践してみて分かったが「次に何をやるべきか」に迷う時間は振り返ればとてももったいなかった。 時間割を作ればほぼ迷わない。迷うとすれば超イレギュラーな事が起きたときだけ。 時間も節約できるしペースもつかめる。 また時間割を家族と共有していれば「20:00になったから勉強してくる」と言うだけで理解してもらえるようになる。 ただし時間割は時が経ち「見慣れて目に入らなくなる」「実態に合わなくなる」事があるので注意が必要。 僕は毎週手書きで描き直している。 時間割の有用性についてはレバレッジ勉強法が詳しい。 2.マインドマップ 正直 マインドマップ を馬鹿にしていた。何で皆あのようなものに踊らされているのかと。それ