いわゆるIMEのON/OFFをタスクバーで確認するとかもう目の移動がめんどくさいから、編集しているカーソルの近くに表示してくれってことです、はい。
というわけで.gvimrcに以下を追加しました。
if has('multi_byte_ime') || has('xim')
highlight CursorIM guibg=Orange guifg=NONE
endif
以下を.gvimrcに追加してやればDONE
autocmd FocusGained * set transparency=235
autocmd FocusLost * set transparency=200
5/6にクリティカルチェーンという本を読み始めた事を記事とした。
クリティカルチェーンを読みはじめた - hiro(iskwa)'s blog
本日読み終わったので、掴めた(と思われる)ことを少し。
これまで、バッファの考えるとき、過去に経験したプロジェクトからの応用で考えていた。この考え方を改善する考え方を掴むことができた。
リソース競合の起こりやすい複数のプロジェクトを管理する手法については、今まで経験・知識共にほぼ皆無であったため、説明がなされた1つの方法を掴むことができた。
以上。
Vimを久々に使っているので新しいコマンドで使えそうなものを発掘している。日々邁進。
(ノーマルモード)e/ge
(ノーマルモード)f{指定文字}/F{指定文字}
クリティカルチェーン(エリヤフ・ゴールドラット著)を読み始めて、現在第2章まで読み終えた。
本作は有名(と思っている)ザ・ゴール同様、小説のスタイルでプロジェクト・マネジメントについて書いた本。以前のプロジェクトよりも現在は組込みの生産現場に近くなった事もあり、チョイス。何か掴めるかな。
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
最近のプロジェクト管理ツールを幾つか試そうと思って、まずは検索して試すツールを調べたのでその記録。連休中に試したいなぁ。
この1週間くらいプロダクトバックログの粒度について悶々と考えていた。
参考になったのは以下のページの"フィーチャーだと粒度が大きすぎて"のくだり。
http://www.ryuzee.com/contents/blog/2844
プロダクトバックログの主たる目的は、オーナーが投資に対する効果を確認できることだと認識している。
もう少し具体的に言えば、その要件が実現できた時の効果と費用(見積り、ポイント)を見て、優先度を決めたり、いつまでにどれだけ実現できるのか判断したりする材料にするため、と考えられる。
つまり、投資判断ができる程度の精度で見積りできなければ意味が無い。
従ってフィーチャではどうもいかん、という事はなんとなくわかっていた。粒度が大きすぎたり不確定要素がありすぎて、見積りができないのだ。だからといってタスクの粒度だと費用はわかっても効果がわからない。複数のタスクを束ねたストーリーレベルであればわかるという事なのだろう。
で、最後に課題、あるストーリー「ほげほげができる」の開発をポイントの基準として、これを1ポイントとした時に、「ふがふがができる」というストーリーがあまりに大きくなった時(例えば20倍以上)である。しかもこのストーリーは分割が難しい、とした時である。「ふがふがができる」に必要なタスクを並べれば、数倍以内におさまるけれど、タスクをバックログに登録することになってしまう、うーん、もう少し考えよう。