こうありたいものだと思う。本心から。 俺は手戻りを一切恐れてないので、細かく仕様詰める無駄な時間を過ごす間に3回作って捨てる scrapbox.io

立場上、って言い方からして不本意だけど、「え、それも俺が決めるの？」というようなことまで考えたり決めたりしなくてはいけないこともある。最終的に決めるのは自分ではないが「好きに決めてくれ」と丸投げするわけにもいかないこともある。 そういうときいつも、ばつの悪さを感じる。「なんでそんなことまでお前が、お前ごときが、どのツラ下げて良いとか悪いとか決めたり意見したりしてるわけ？何様のつもりだ？」と、そう囁くのだ俺のゴーストが。 それも仕事だ、と頭では理解しているし、納得した上でやってるのだから多少の居心地の悪さくらいで投げ出したりはしないけど、ずっと分不相応だという気がしている。そう思わなくなったら終わりだという気もしている。

仕事柄エンジニアの評価制度とかのことも考えないといけないのだが、以前から同僚が「二つのタイプの人がいる、 Rockstars と superstars だ」と言っていて、そのときはピンとこなかったのだが後日シェアされた記事を（重い腰をあげて）読んだら合点した。 Rockstars: 安定して着実な成長を求める。ワークライフバランスを重視するとも言える。決して仕事ができないというわけではなく、任された領域においては十分な仕事をして成果もあげているのがポイント。 Superstars: 急激な成長を求める。常にチャレンジングなことに取り組んでないと飽きるタイプともいえる。興味を持って没頭できる仕事を与えられると大きな成果をあげるので、このタイプのほうが「成長して成果を出した」とみなされやすい。 最初にこのアイデアについて聞いたとき、安定を求めるタイプをロックスターと呼ぶのに違和感があったが、ど

週に何回かこの台詞を思い出して自分を鼓舞している。 他人のスケジュールで暮らさなければいけないのは大変だが、だからこそ、俺は俺が選んだ俺の人生を生きるのだ、と強く思う。

webpack 全くわかってなかったので、有り難い記事だった。 CodeGrid 様々。 （「雰囲気で webpack をやっている」どころじゃなく、マジで config を一行も理解してなかったので、超苦手意識があった） webpack は、必要なコードだけロードされるようにバンドルするノードを分けたり、非同期ロードしたりする機能がある しかし実際いま触れてるプロジェクトでは単一のファイルにバンドルして同期的に読み込んでいそう（そういう使い方しかしてなさそう） 設定の最小構成要素は entry と output （こういうことが知りたかった！） entry で指定したファイルから import とか require されてる依存ファイルが自動的にバンドルされる entry と output を複数持てる コマンドラインオプションと設定ファイルのプロパティが対応する Loader というも

仕事で使う資料にトレードオフスライダーを使おうと思ったが、意外にもテンプレートの類が簡単に見つからなかったので自作した。 Google スライドで作って会社の G Suite アカウントのスライドテンプレートとして登録したが、個人用の Google アカウントではそういうことはできないようなので、 Microsoft PowerPoint (.pptx) 形式と OpenDocument Presentation (.odp) 形式でダウンロードしたものを GitHub にも置いておいた。 github.com

↓ここが一番良かった。著者はリープフロッグと呼んでいるが、茹でガエル現象ともいう。 これまでスマートフォンの仮想キーボードを頻繁に使っていた人たち（とくに、フリック入力方式に習熟していた人たち）は、音声入力の価値を過小評価し、それを利用できることを知っていても利用していない人が多いのではないかと思われます。つまり、スマートフォンの使い方が、携帯電話時代のものに固定化されているわけです。 音声入力はテキスト入力方式として、非連続的な革新の部類に入ると思う。キーボードもフリック入力も、手と指を使って一文字ずつ入力していくという点で連続的だが、音声入力は利用する器官が全く違うし、文字ではなく文章の単位で入力していく点も大きく違う。まるで、携帯電話のメールのかな漢字変換の革新を彷彿とさせる（初期の携帯電話は文節単位のかな漢字変換ができず、メールの文章を打つ時は「ぶんしょう」と打って「文章」に変換す

http://vesperapp.co/blog/the-end-of-vesper/ App Store をぼんやり眺めていたらメモアプリの Vesper がアプリの提供を終了することを知った。クラウドデータ同期サービスはすでに終了していた。 昔少し試した程度で、しばらく前に消してしまっていたけど、 look & feel は好きだったので、記念にダウンロードしておいた（購入後履歴からいつでもまたダウンロードできるだろうけど）特にタグを入力するところは出来が良かった。あと開発者が同期サービスのバックエンドの設計と実装について書いたブログ記事のシリーズが興味深かった（途中までしか読まなかったけど） Vesper has had more downloads since Sunday (when it went free, and was announced EOL) than it did

note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を

Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。 実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。 サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがとこ

会社の人事評価システムがいろいろ整備されたこともあり（この話は機会があればどこかで話したいと思っている。キーワード: グローバル企業、エンジニア評価制度、フェアな基準）評価面談的なのをやった。もちろん自分が評価される側。 現状そんなに悪くないからこの調子で、みたいな感じではあるものの、現状維持でokというわけにもいかないので今後なにをやっていくのか、というところで、前々から取り組みたいと思っていたことはあり、ニーズも大義もありそうで理解も得られそうではあるのだが、長い目で見ると自分のキャリア的にけっこう大きな進路変更になる可能性があるので（言うまでもなく、マネジメント路線ではない）、まだちょっと踏ん切りがつかないところもあり、悩み中、といったところで wrap up. あと自分にその適性がある仕事なのか？にいまいち自信というか確信がないのも及び腰になる一因ではある。 先日同僚と飲み会で話し

Kindleストアの日替わりセールで買った気がする。だいたいどこかで聞いたことあるような内容だった。「存在を認める」ってのはわかりやすかった。内省のために読むくらいがよさそう。 〈NJセレクト〉 コーチングのプロが教える 「ほめる」技術 作者: 鈴木義幸出版社/メーカー: 日本実業出版社発売日: 2009/10/08メディア: 新書 クリック: 8回この商品を含むブログ (4件) を見る

「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが

昨年末から SNS を見るのをやめた。目的は精神の平穏を保つため。誰が退職しただの、誰が本を書いただの、誰と誰が寿司を食っただの、そういう業界ゴシップで心惑わされるのに疲れ果てた。知る価値のある情報もたくさんあるが、 S/N 比が悪くなりすぎた。 また、 SNS に愚痴や攻撃的なことを書いたりしてしまうのもやめたかった。傍目に悪いし、書いてスカッとするわけでもない。いつか炎上するかもと内心びくびくしながらやめられない様はまさに中毒だった。 具体的にやったことは以下。 iPhone から Twitter と Facebook その他 SNS のアプリを削除した。隙間時間についつい見てしまう・書いてしまうのはこれで克服できた。 SNS からの通知メールをできるだけオフにした。特に効き目があったのははてなブックマークのマイホットエントリーお知らせメールで、自分にとって最大のゴシップ情報源になって