そうだねぇ… - がるの健忘録

早速。

外部のプログラマーのMLへのメールやテックでない人へのメールを用心深く書く

ある。「用心深く」ってのが大切だし、その手のは大抵「一度書いて」「少しだけ、30分とか時間を空けて」「推敲する」ので、手間と時間がめっさかかる orz

ミーティングに参加、モックアップやDBスキーマの作成、要求された機能へのパフォーマンスの心配

踏む。邪魔者を排除するのは、成果を挙げるための基本事項です B-p

バグレポートを書く、過去のバグを検索

メモを走り書くから、そんなにいっぱいの時間は食われないかなぁ。

複雑なシステムの障害の原因を何ギガもあるログを探索して調べる

切り分けはおいちゃん得意なほうらしいからねぇって書いたらIDEが特異って変換しやがった orz

ダウンタイムについてユーザーや上司への説明

顧客には説明をする。「丁寧な説明が必要な上司」は、その前に締め上げておく B-p

他人の問題の解決へ協力

あぁこれは普通に。えと…「トレーニング用のおもり」くらいの感覚？
これをやった上で「通常の20倍の速度を出す」くらいが、今の「フロー状態における最大速度」かなぁ。

ドキュメント、本、ブログ、リリースノート、脆弱性アナウンスを読む

息抜き。でなきゃ逃避 orz

必要な既存の名前の分からないようなコードを探す

そんな散らかったプロジェクト、キライ〜

見つかったコードが自分の環境に互換性がありライセンスに問題がなくコミュニティが生き残っているかを検証する

ざっくり斜め読みで先にあたりをつけてかｒ。

ソフトウェアをインストール、設定、テストまでしてみたがけっきょく自分の環境では動かない

だからツールってキライ

エラーメッセージをググる

稀に

公開されているコードを調べて「あるOSSがどう動いてるかを調べる」

これもまずは「ざっくりとソースを斜めに読んで」から

ソース管理ツールやbash、GNUツール、Linuxのファイル権限について学習

息抜き？

IDEやVM、サーバー、データベースの設定

発生頻度は「稀」だけど、発生すると結構食われる orz

共存できないように設計されたコードをなんとかひとつにまとめる方法を考える

まず「そーゆー設計をした環境」を締め上げるか、でなきゃ逃げ出す。
さもなくば、無間地獄の始まりだぉ orz

おわりなくやってくるタスクに優先度をつける

そのタスクの発生源を締め上げる B-p

…えと…締め上げる系が多いなぁ(苦笑