確かにこのやり方やってるわ。さすがにデカいディスプレイの前でしか読めないと制約が大きすぎるけどな。基本はノートPCでKindleとブラウザにTrello開いて並べてメモ＆キャプチャ・OCR＆検索しながら読んでる。
atsuizo
91.7K posts
atsuizo
@atsuizo
流浪の人。SE、コンサル、事業企画、経営企画、管理会計、情シス、総務などなど。最近はインフラ、DBいろいろ屋。AWS関連ツイート多めですが、中の人ではありません。
Joined September 2008
- この人がどうなのかは知らないけど、この手のことを声高に言う人って「オレの仕事が止まるから即レスしろ、オマエの仕事の中断ことなんか知らねえ」ってヤツが多い印象があるので、即レス至上主義はあまり好きではない。「非同期でも効率的」な仕事のやり方を考えようぜ。
- Oracleの「適当なテーブル設計＆適当なSQLぶん投げても、イイカンジに速く処理してくれる」にさんざん甘えておきながら、「カネかかる」とゴネて、OSSなDBに乗り換えをもくろんで、単純移行で済ませようとして見事に爆死、ってケースはまれによくある。
- 自分がDB屋なのもあって全く同意できないんだけど、こういう価値観の世界もあるんだってことはキモに銘じておかなきゃいけないと思った。
- 読書再開。「みんなのフィードバック大全 amzn.to/43Lx1oh 」 読んでる。これ、マネジメント側も、被マネジメント側も、両方読んでほしい本だな。少なくともマネジメントサイドの共通認識にしたい要素が盛りだくさん。
- 一応DB屋だけど、ブログやツイートでは、「トランザクション」ネタの言及は避けてる。生半可な知識で飛び込むと火傷するからな。「このプロダクトではこういう挙動をする」というファクト以上の話に触れると危険。人類には早すぎる、くらいのつもりで臨む謙虚さが必要。
- Qiitaに投稿するのに「こんなレベルで大丈夫か？」なんて心配しているヤツを見たけど、技術ブログなら、とりあえず、意見じゃなくて事実（やったこと）を書けばいいんだよ。そこで飛んでくるのは「もっといいやりかた」であることが多いから、多少のショックはあれどプラスになる。
- 「データベースの性能問題の大半はストレージI/Oネックで発生」とはよく言われるが、経験上、相談に持ち込まれる問題の大半はストレージI/Oじゃないところなんだよな。少なくとも必要なデータはメモリに乗ってる状態で「応答速度要件を満たせないんだけど、どうにかできないか？」って持ち込まれる。
- DB遅くて相談してくる人、アプリのソースいじりたくなくて、DB側のパラメータ調整でなんとかして欲しいってことが多いけど、いわゆるクソクエリから目を背けたまま対応できることなんて限られてるよね。
- かつてストアドプロシージャ（Oracle PL/SQL）大好物マンだったけど、今は「できるだけストアド使うな」教を布教してる。理由は「ロジックはアプリ側に集約させたほうが見通しがいいし管理がラク」「ストアドはスケールさせにくい」「移行がツライ」あたり。ストアドプロシージャっておいしいの？
- 超大手通信会社の社長が澱みなく技術的な説明してるのに、お客さん向けの報告資料を作成からプレゼンまで孫請けの担当者にやらせてるヤツ、恥ずかしくないの？（闇
- 先日の「RDSの方がAuroraより速いケース」の件、とりあえず調べたい範囲のベンチマーク取れた。元記事って2000万件*5=1億件を1クライアントで処理してるのな。で、普通に？HammerDB TPC-Cで多重度上げてもRDSが速いケースがないか調べた。
- オンラインになってから図をその場で書くというのが激減したな。自分メインの会議のときは事前にパワポで書くようにしてるけど、やはり対面でホワイトボード使えるときとは差が出る。「過渡期」だよねえ。
- 本番環境をいじる作業を「手順書なし」「チェッカー不在」「GUIツール」でやる時点でスリーアウトだな。。。
