http://rebuild.fm/126/
日本語版がでました。すぐ買うべし。 SOFT SKILLS ソフトウェア開発者の人生マニュアルposted with amazlet at 16.05.18ジョン・ソンメズ 日経BP社 売り上げランキング: 1,272 Amazon.co.jpで詳細を見る Soft Skills: The Software Developer's Life Manualは残念ながら日本語訳が出ていない。でも英語でも読む価値はある。とても平易な英語で書かれてる。どこかの出版社さん翻訳だして欲しい。空前のブームになるに違いない。 Soft Skills 。alc.co.jp によればソフトスキルは「対人的な交渉・指導・意思疎通などをうまく行える能力(または知恵)」のことらしい。そのタイトルからも分かる通り、プログラマ向けに書かれた本だがほとんど技術の話は書かれていない。プログラマとして生きていくための技術以外
今回のブログは短く。同僚・上司たちは「日本人的な空気を読む」ことはしません。というか無理。 例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 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある?」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
エンジニアからみた良いプロダクトマネージャ(以下PM)とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト(製品)マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか?と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
スーパーエンジニアの道というと大げさだが原題は「Becoming a Technical Leader」。年齢的にもそして現ポジションもリーダーシップが必要なので読んでみた。著者はエンジニア出身でかつ、リーダーシップのセミナーを主催しているので、リーダーシップにまつわる現実的な話がたくさん。すこし冗長で読みづらかったので各章毎にマインドマップもどきを描きながら読んだ(例 これ)。 先日 id:secondlife さんにインタビューしていただいた記事 でも少し触れているのだがここ数年 Tech Lead という役割で仕事をしている。その体験と本の内容を重ねながら読み進めた。この手の本にありがちな「リーダーになるのは素晴らしい!」とか「強いリーダーになる方法!」などは一切ない。むしろ「リーダーって大変だけど。そこまでしてなりたいの?よく考えて。」とか失敗例がたくさん載っていて面白かった。某外
毎朝5時に起きて出勤前にコードを書くという習慣を始めた。2週間経ったのでまとめてみようと思う。この記録が小さい子持ちの30代パパ・ママエンジニアに役立つとうれしい。多分独身で若い人には役に立たない。 始める前に抱えていた問題 好きなコードを書きたい。勉強したい。そう思っても以下の理由により以前とは比べられないほどに時間がとれなくなってしまった。 子供に可能な限り時間を使いたい。結果的に自分の時間は減る コードを書く自由時間が極端に少ない 1人になれる時間がほとんど無い 家で10分以上集中できない。こどもが遊ぼう!って誘ってくるとか 子供に話かかられたり質問されたら出来る限り応えたい とにかく疲れやすい 以下のような典型的な1日。 朝は 6:30 頃に早起きの息子に起こされる。1人で起きて絵本などを読める歳だが、静かに起きることは稀だ。トイレに行きたいとか。何かが見つからない。何だかんだで同
ちょうど1ヶ月前。フレンズのディクテーションとフレーズの暗記を毎日やることを決心した。その成果を1か月後にブログに書くというイベントをカレンダーに登録した。なのでこのブログを書いている。 なぜやるのか? 1:1 ではなく大人数での会話の聞き取りについていけないことがよくあるから。特に仕事とは関係のない話題の場合に顕著。これはリスニング能力の問題。 日常のふとした言い回しのストックが足りないと感じていたから。例えば「病院どうだった?」「あ。僕がそっちに行くよ」「もったいないねー」など。 これらのフレーズは聞き取ることは簡単。そして意味も簡単に類推できる。しかし自分の口からは出てこない。なぜなら知らないから。 なぜフレンズか? 英語の先生、英語がネイティブではない外国人の同僚、多くの人がすすめてくれたから。そしてDVD 全巻持っているくらいフレンズが好きだから。 工夫した点 続けられる仕組みづ
重い腰を上げて screen をやめて tmux にしてみる。 install % brew install tmux % brew install reattach-to-user-namespace .tmux.conf # Prefix set-option -g prefix C-t # reload bind C-r source-file ~/.tmux.conf # Histories set-option -g history-limit 10000 set-option -g status-utf8 on set-option -g status-interval 5 set-option -g status-bg black set-option -g status-bg white set-window-option -g window-status-current-
実際に英語を使う機会がほとんどないときに、将来の備えとして英語を勉強していた(シャドーウィング、ディクテーション、単語)。その時には必要そうだと思ったこと、人に勧められたモノに必死に取り組んでた。それらは全て役だっているし力のかけ具合も適切だったと思う。 ただし他にもやっておいたほうが良かったことと思っていることが1つあるので紹介。 それはコミュニケーションの中で発生する短いやりとり(同意、意見を聞く、質問)などに使われる表現の勉強。 例)Sure. Go ahead. Looks good to me. I don't think so. I guess ... I would say that ... Let me confirm ... などなど。 これらがとっさに出てくるようになるとうれしい(まだ出てこない)。 ので以下2冊で勉強中。まだ道のりは長い。経験者の方はいい勉強方法・本が
背景と動機 WebKit をいじっているとファイルの階層が深い。find-file でファイルを探すのが面倒。一度でも開いたことのあるファイルなら find-file のヒストリから簡単に開けるがそれでも大変だ。理想としては「えーと。ファイル名に Event と Mouse と Platform が入っていて拡張子が cpp のファイルがあるはずなので探してちょうだい」と言いたい。 環境 Emacs 23.3.1 OSX Lion 後述の anything.el は version 1.3.8 セットアップ anything.el の導入 auto-install.el をダウンロードし loadpath の通ったところに置く。 % wget http://www.emacswiki.org/emacs/download/auto-install.el (require 'auto-ins
大げさなタイトルになってしまった。大した方法ではない。暗記が苦手な僕は新TOEIC(R)テスト900点 新TOEFL(R)テスト100点への王道を参考に以下のような暗記システムを組み上げた。(ITのシステムてはないので注意) ポイント 昔ながらの英単語暗記カードを使う 「完全に覚えた」単語とそうでないものを分ける 「完全に覚えた」単語を復習するタイミングを表紙に書く 詳細 入力。究極の英単語 Standard Vocabulary List [上級の3000語] Vol.3を開き4ページの中から知らない単語を抜き出す。 入力。暗記カードに意味とスペルを書く。 すべて書き終わったところでカードをめくりながら「完全に覚えた」「覚えていない or 覚えたが自信がない」に分類し。すべて覚えるまでめくり続ける。 上の作業の間は語呂合わせや頭にイメージを浮かべるなどの方法で愚直に覚える。 上で書いた暗
分散 Key-Value ストア mio-0.0.1alpha をリリースしました。(mio-0.0.1-alpha.tar.gz) Mio とは何か? 範囲検索(range query) が出来る KVS です。例えば「key が "1000"〜"2000" にあるものを昇順に10件取り出す」という検索が可能です。 Mio は memcached 互換プロトコルを実装しているので、多くのプログラミング言語から簡単にアクセスする事が可能です。(後述のコード例参照) Mio のアーキテクチャ Mio は Skip Graphs(スキップグラフ)というアルゴリズムに基づいて実装されています。詳細はErlang 分散システム勉強会での発表資料 Mio - a distributed Skip Graph based orderd KVSをご参照ください。 インストール 最新の Erlang をイ
GDB において特定の回数関数が呼ばれたら break する方法。 # break point を表示。番号を知る (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000413fab in scheme::VM::runLoop(scheme::Object*, __jmp_buf_tag*, bool) at src/VM-Run.cpp:982 2 breakpoint keep y 0x000000000040e240 in scheme::VM::tryJitCompile(scheme::Object) at src/VM.cpp:957 breakpoint already hit 3 times # 2番の breakpoint において 121 回は通過し 122 回目で br
Memcached のベンチマークツールを公開しました。自作の KVS のパフォーマンス測定に使っていたものです。 以下のように簡単にベンチマークがとれます。 $ mcbench -b 10000 -t 10 -n 1000 -s 127.0.0.1 -p 11211 -c get ==== mcbench started ======================= Server: 127.0.0.1:11211 10 threads x 1000 = 10000 commands. Inserting base data 10000 ... done Sending get Commands ... done ==== mcbench result ======================== Interval: 138 msec Performance: 72661 comma
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く