Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
運動が苦手な君へ - higepon blog
ぼくは運動が苦手です。走るのがとてもおそいです。リレーをやるとぼくのいるチームはかならず負けます。サッカーをやるとキーパーをやらされるか、一度もボールをさわらないまま体育の時間が終わってしまいます。野球をやるとポジションはかならず外野です。高いフライがとんでくると後ろにそらしてしまいます。ヒットを打ったこと一度もないです。バドミントンやたっきゅうをやっても、サーブが上手にできないので相手がイライラしてしまいます。バレーボールをやるとあそこがあなだと言われ、ねらいうちされて同じチームのみんなにめいわくをかけてしまいます。みんなでダンスをおどる場合も1人だけずれてしまいます。ぼくのせいでみんなが何度も練習しないといけません。先生のやるとおりやってみろといわれても上手にできません。何がわるいのかもわからないです。てつぼうをやってもクラスで1人だけ、さかあがりができません。ぼくはいっしょうけんめい
サイボウズ・ラボ株式会社を退職しました - Higepon’s blog - Mona OS and Mosh
2012/1/15 をもちましてサイボウズ・ラボ株式会社を退職することになりました。 お世話になったみなさん本当にありがとうございました。 各分野でのトップレベルのエンジニアに囲まれた 4 年間は本当に刺激的でした。ラボでは良い上司（畑さん）に恵まれラボのミッションに沿う形で、比較的自由に研究・開発に取り組むことができました。外に出ているだけでも Mosh / Mio / outputz など。どのプロジェクトでも自分が実現したいこと、自分の能力と真摯に向き合う必要のあったかけがえのないプロジェクトでした。この 4 年間に学んださまざまなことは、今の自分を形成する「成分」の中でも大きな割合を占めていることを感じています。サイボウズ・ラボおよびサイボウズのみなさま本当にありがとうございました。 1 月末から新しい職場でソフトウェアエンジニアとして新たな一歩を踏み出します。みなさま今後ともよろ
thunkって？ - higepon blog
引数なしの手続きを引数にするときに thunk っていうじゃないですか。 この thunk ってどういう意味なのかと思って調べたのですがぴったりくるのがないなあ。 “thunk”の検索結果（2 件）：英辞郎 on the Web：スペースアルク 追記 真相はコメントに。
Gauche(Scheme) でデバッグをする4つの方法 - higepon blog
Gauche でコードを書いているときにコードが意図どおりに動かないことがあります。そのような場合にデバッグする方法を4つ紹介します。 前提 まず Gauche はリリースされている最新版を使った方が良いでしょう。Linuxのディストリビューションによってはパッケージが古い場合あります。 またScheme は関数型言語なので、デバッグの単位は関数（手続き）ごとに行うことが多いです。一つ一つの手続きが意図どおり動いているのか？を調べながら進めるのが基本になります。 方法1 print デバッグ Gauche には今のところデバッガがありませんから基本的には print デバッグがメインとなります。単純な print デバッグから見ていきましょう。 以下のような sum という手続きで print デバッグしてみましょう。 (define (sum n) (if (= n 1) 1 (+ n
Three Implementation Models for Scheme by R. Kent Dybvig - higepon blog
ドラゴンブックを読み終わったあと、実は「Three Implementation Models for Scheme by R. Kent Dybvig」という論文を読んでた。 これは id:yhara さんにすすめられたもので、「Scheme の処理系を3つのモデルで実装する方法」を長所/短所をまじえて説明している論文。 英語で180ページ程あるので苦戦していたのだけど、実家で紙に印刷して冊子上にしたらあれよあれよという間に読み終わった。 PDFより、やっぱり紙だよなと思った。 論文の内容は heap base の Scheme処理系 stack base の Scheme処理系 string base(FFP)の Scheme処理系 を Scheme で作る話。 上記の順序で処理系を作っていく。 単純なものから、よリ効率の良いものへ改善していく内容で超ためになった。 まず VM の作り
Emacs Lisp auto-compile.elを公開しました - higepon blog
自作の Emacs Lisp auto-compile.el を公開しました。 これは何か? C, C++などのコードをEmacs上で編集しているときに、ファイルを保存したタイミングで、バックグラウンドで make コマンドが自動で実行されます。 以下のようなメリットがあると思われます。 いちいち terminal で makeしなくて良いので、開発効率があがる 保存時に行われるのでコンパイルエラーが早い段階で発見でき、開発効率があがる このような感じ C-x C-s で保存すると make が自動で実行されます コンパイルが終われば OK がでます（エラーが発生すれば表示されます） インストール方法 sf.netから auto-compile.el をダウンロードしロードパスが通っている場所に置く。 .emacsに (require 'auto-compile) ;; auto-comp
Erlang の logger の謎が見えてきた - higepon blog
Erlang で書かれたアプリケーションの logger 。使っていると色々と疑問がわいてくる。 今思いつくだけでも error_logger という名前なのに設定で sasl とか log_mf_h など違う名前が出てくるの？ error_logger の吐くログはなぜ rb で見るの？面倒だよね。 数々のプロジェクトが独自 logger を実装しているのはなぜ？ など。 背景 error_logger は event manager として実装されている。ロギングは error_logger に登録された event handler が行う。 これが分かればあとは簡単。 デフォルトの event handler はログを tty に出力するだけ 起動中に Kernel Application が上記 handler を standard event handler に置き換える。同様に
Erlang でエラー行表示 smart_exceptions - higepon blog
Erlangで行番号付きでエラーを出力する方法: みかログ を参考にしつつ最新の Erlang で動くように。 devel at 3a91498669996e05a2199bb42df938343b2abec0 from thomasl's smart_exceptions - GitHubから、最新版 Erlang 対応の smart_exceptions を持ってくる。（オリジナルのものはメンテナンスされていないので注意） % cd devel % mkdir ebin % cd src % make % sudo cp ../ebin/*.beam /usr/local/lib/erlang/lib/smart_exceptions/ebin あとは erlc に +'{parse_transform, smart_exceptions}' をつけるだけ。
Erlang 付属プロファイラ fprof の出力結果の見方 - higepon blog
参照 Erlang の公式マニュアル。fprof 手短なコツ プロファイラ結果を上から見ていき、ACC が大きいものをたどっていく。 % がついたマーク付きの関数に注目して、calling, called 関数の ACC を見比べていき、時間を消費している関数を特定する。 Emacs なら M-C s で 関数名.*% あたりで追っていくと良い。 詳細 マニュアルの超訳（ねつ造、改悪、省略）。 以下のコードのプロファイリングを見ている場合。 -module(foo). -export([create_file_slow/2]). create_file_slow(Name, N) when integer(N), N >= 0 -> {ok, FD} = file:open(Name, [raw, write, delayed_write, binary]), if N > 256 ->
memcached の空間効率 - higepon blog
memcached クライアントを実装してみて気づいたというか意識したこと。 オブジェクトのシリアライズはクライアントライブラリやユーザー任せなのだ。例えば Perl では Storable 。言うなれば汎用シリアライザ。 普段は全く意識せずに与えられた汎用シリアライザで扱えば良いと思う。 ただし格納するオブジェクトに特性があるときはカスタムシリアライザを作って空間効率を追求してみるのも面白いかも。 特性とは例えば格納するオブジェクトが 特定の種類のみ 特定の値域のみ などの場合。 より具体的には ascii 文字列だけ 数値だけを格納してその範囲は 8, 16, 32, 64bit に収まる 取り得る値が enum のように限られる など。 うまくカスタムシリアライザを作れば格納時のオブジェクトサイズをぐっと小さくできる可能性がある。 この方法に対する考えられる反論は メンテナンス性の問
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eshell(Emacs Shell) で alias を定義する - higepon blog