技術書への不満という濡れ衣 - steps to phantasien
最近はプログラマ向けの技術書を読んでもムカついたりがっかりしたりばかりで、読みたい技術書を探すにも良い技術書評家はいないし、もうプログラマ向け技術書というジャンルは終わってしまったのだろうか。それはなぜか。 ・・・というような不満をもっていたが、考えているうちにこれは概ね濡れ衣に思えてきた。端的にいうと、一線を退いた元おたくが「最近のアニメ（などの得意だったおたく分野）はつまらん」というのと同じ現象が自分に起きているだけな気がする。 キャリアの停滞 まずマンネリ化。自分はキャリア初期のたくさん学ぶことのある時期は終わってしまった。これは雇用という点では良いことだが、学びのある本に出会う確率を下げてはいる。多くの人が「これは必要」と思う話題ほどたくさんの本が書かれる。中身はどれも似通ってくる。新しい読者が必要なものに出会う確率はあがるが、必要なものを読み終えた読者は同じものの繰り返し、すなわ
隣の JIRA 職人 - steps to phantasien
TPM / Technical Program Manager という職種がある。以前 Rebuild.fm では "JIRA 職人" として紹介されていた気がする。検索すると各社の求人が見つかるので、そこそこ広く知られた職種らしい。ただ Manager というくらいでそれほど数はいない、ちょっとめずらしめの仕事。最近、そんな TPM と仕事をする機会が続いた。 メタバグ管理 TPM の主要な仕事の一つは、組織のプロセスがきちんと機能する状態を保つこと。プロセスというと身構えがちだけれど、組織の規模がある程度より大きいと、良いプロセスは助けになる。だからプロセスがあるのはいい。一方で下手なプロセスが官僚化に繋がるのも事実だ。TPM にはうまいさじ加減で組織を回す期待がある。 あるとき自分のいるクライアントチームの週例ミーティングにあたらしい TPM がやってきた。サーバ、クライアントからア
2015/01/26: カルマをためすぎない - steps to phantasien
カルマはためすぎないほうが良いと思う。 仕事での貸し、面倒でイヤな仕事を片付けた実績。わかりやすい業績じゃなくて、プロジェクトや製品を支える雑用の見返りがカルマ。ビルド壊れ治し、バグのトリアージ、レビューの球拾い、ツールの改善、トロル対応。そういう仕事をすると貯まる目に見えないポイント。組織のインセンティブデザインなんて完璧でない。道徳心や責任感のある人がその不完全を埋める。そしてカルマを貯める。 カルマは貯めるだけでなく使うこともできる。日頃の行いがよければ、たまに無理したり変なことをしても大目に見てもらえる。そういう形でためたカルマを消化できる。自分は一時期クラッシュバグを直しまくってカルマをためていたため HTML Imports の出荷でやや無理にブランチに変更をねじこんでも見逃してもらえた（気がする）。 そんなカルマだけれど、あまりためすぎない方がいい。 まずカルマは曖昧なものな
Pandas と BigQuery - steps to phantasien
しばらく前から仕事のログ解析に Google Analytics をエクスポートした BigQuery を使っている。BigQuery を Jupyter 経由の Python から呼び出し Pandas で整形可視化する。久しぶりにするモダンぽい仕事で楽しい。 アプリのログ解析は大半が内製のシステムを使っているのだけれど、クライアント側の開発者が勝手に使う部分では歴史的経緯で GA が使われている。自分はもともと GA のダッシュボートなんてしょぼすぎて使い物にならないと思っていた。でも BigQuery にエクスポートできると知り試したら別物のツールになった。 SQL と Pandas を組み合わせて使うのはちょっと不思議なかんじだ。たとえば histogram を描きたいとする。Pandas だけなら hist() を呼ぶわけだけれど、SQL を使うと bucketing は Big
Matplotlib Object Model - steps to phantasien
Matplotlib を使ったコードを写経しようとしたが 10 行くらいで発狂しそうになる。この API, 眺めてるときからクソだと思ってたけれど自分で書くのは更に苦痛。耐えられませぬ... しかし今回は high level な API に逃げないと決めているので、なんとかこの人たちの気持ちを理解しようと公式のドキュメントを読んでみる。と、一定程度理解が深まり殺意も和らいだのでみんな読むと良いよ、という話。 まず Introduction から。「表面的には Matlab インスパイヤな API だけれど中は割と object oriented だよ」という。かすかな希望を抱いて次に Introductory Tutorial を一通り眺める。それから Artist Tutorial を読む。 わかること: Matplotlib の API 呼び出しは、内部の DOM みたいなのを構築し
書き直さない時代の気分 - steps to phantasien
なんとなく続き。(前回) Martin Fowler が蒸し返すまで、 自分は書き直しについてことさら何か書く気が起きなかった。 どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。 部分的に書き直す 最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。 小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れ
Ftrace と Systrace - steps to phantasien
Systrace を使いたいとおもい調べた記録。 Ftrace は Linux カーネルのプロファイル(トレーシング)機構。Ftrace にはざっと三つの構成要素がある: Linux の debugfs を介して操作するトレース情報のバッファリング機構、 カーネル標準で用意されているいくつかの標準probe(トレーシング情報)、 コンパイラのプロファイリングオプションを介して全てのカーネル内関数に注入されるフック。 Ftrace の機能はコンパイル時スイッチでオフにできる。特に 3 のコンパイラ経由のフックはオフにされていることがあるっぽい。若干のオーバーヘッドがあるため。 手元の Ubuntu では有効になっていた。 Android の Systrace は ftrace のインフラを使って作られている。 Android のトレーシング機構 Systrace は 3 に頼らず必要な情報を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
