最近の知見 20150630
週末にデザパタ残りは、まとめてまた書こうかな。最後まで書きたい。
エクストリームプログラミング買った。言い訳はするだろうけど、色々考えるのも面倒だし、思ったより自分の考えている事と離れていなかったので、少しずつ寄せていきたい...。
(開くまでは、開発のためのお勉強の事でいっぱいで、開発をしない人が読むような本だと思ってた...)
プロジェクトをチーム全体の仕事にする
チーム全体で仕事をする、というのが足りてない感が半端なかった。
いや、チームの仕事ではあるんだけど、実行は、アサインされたエンジニアの領分みたいな感じがある。
だけど、なんていうか、うーん。。
とりあえず、他人は変えられないので自分の仕事についてはなるべく共有して、チームのプロジェクトにしようと思いました。
相手が縄張りバリアーみたいなの張ってるのに踏み込んでいくのは、よっぽど余裕があるときだけでいいですよ...。
PRのレビューに対して思ったこと
レビューに対して、受ける側としてもう少し感謝の意を示すように、というのと、 行う側として、ここ、こうした方がいいんじゃない、の前に、おつかれさまです、って一言つけよう、 って思いました。
なんていうか、そのタスクで実現させたいロジック自体が重い場合、 本筋のロジックとは関係のない細かいところを 前置き無しに、「こうじゃない?」ってやられると、結構辛いし、悲しくなるのですよね。
重たい設計や調査をすることと、お行儀やパフォーマンスに基づいてチューニングする事はまた別のタスクなのに(私のタスクの分割が細かいのかもしれない)、 後者が足りなかった故に、前者に対しておつかれさまもLGTMも無しに後者が足りないって言われるの、 気持ち的にすごい損に感じて半べそかきそうになりました。
1人では両方こなすのが難しい場合が多いからレビューをしてもらってるのに、身勝手なんですが。
あと、なんか設計の筋にたいして、コメントもらうと個人的に安心するので、 重いロジックの時は、積極的にこういう風に確認しました。LGTMとつけたい。
つけたいけど、誰がレビューするか、で、 この人の普段の仕事ぶり見てると、この人に何言われても説得力無いんだけど... と思ってどうしても内心しらける事があるので、 まずは自分自身で良いコード、良い仕事出してこう...。
3時間くらいは長いにしても、1時間くらい置いてから自分で細かいとこ確認するといいのかもしれない。
いつか確認する
- テーブルのストレージエンジンを知りたいとき、どうしたらいいのか?
- とりあえず、 http://d.hatena.ne.jp/momiage3dau/20100409/1270786599
- ユーザ権限によっては、information_schemaの一部テーブルに閲覧権減すら無かったりする
- http://open-groove.net/mysql/check-table-type/ あたりだっけ?
- とりあえず、 http://d.hatena.ne.jp/momiage3dau/20100409/1270786599
- 逆順でソートをしたいとき、indexは効くのか?
- ワーキングメモリ使って逆順でsortするのかなー。
- GROUP BYでCASE使うときって、SELECTした後の各行で演算してるのかな?
- 確認するすべがあるのか...