ピープルウエアを読んだ感想と書評を書くことについて
トム・デマルコの「ピープルウエア」を読んだので、書評を書いて残しておくことと
今までは読んだ本全部で書評を書いてなくて、今回書くかどうか迷った時に考えたことを残す。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (10件) を見る
読んだ感想
組織の問題の解説とどうすれば良いかについての本で、以前からお勧めされていたのをようやく読んだ。
結論としては読んでよかった。エンジニアが働きやすい組織は昔から変わってないんだなと思った。
特によかった点を詳しく書く。
生産性の高いチームを育てる話
チームを殺す方法
チームを結束させる方法をあげることができないから、逆にアンチパターンをあげて
それだけはやらないようにすることが書かれている。
具体的にはメンバーに対してマイクロマネジメントをすることや、マニュアル通りに動かすこと、チーム内で競争させること、複数のチームに所属させることで、この中では競争させることがアンチパターンというところは驚いた。
共同作業でチームを結束させる
本の中ではチームメンバーでスパゲティディナーを行い、その中でマネージャーは何も手伝わないという例で書かれていた。
マネージャーが指示しなくても、メンバー同士で考えて動くことでチームワークは出来上がるという話で、
チームでやることは別に開発に限ったことでなくても、一緒にやることでチームを良くすることができるので、
一度こういうこともやってみたいと思った。
目標を提示してメンバーに任せる
マネージャーはメンバーを画一的にするのではなく、メンバーの個性に寛容になりながら
目標意識を植えつけて、任せてやることで特別意識を持たせて活動的にさせるものということが書かれていたが
特に印象に残ったのは、「いずれにしても部下はコントロールできるものではない」というところで、これは強く認識していきたい。
文化を醸成する話
メソドロジー(方法論)は悪
メンバーのやり方を決めて動かすことは、メンバーに責任を持たせないこととなり
責任を持たないメンバーは自分の意識で動かなくなる。
これはマネージャーが崩壊する未来しかないので絶対にやってはいけないと思った。
変化を嫌う人は成長できない
変われない人は進歩できないと書かれていて、自分も他人から与えられる変化には敏感になることがあったと思って
自分の進歩を止めるような行動ややらないようにしたい。
仕事を楽しくする
コミュニティ
自分の場所を楽しい場所にするためには居心地の良いコミュニティが必要で、コミュニティは仕事だけで生まれないので、自分で作り上げなければならない。
今まで意識して作っていたことはなかったけど、確かに自分から動いて出来たコミュニティは楽しいと感じることが多いので、仕事をする中でコミュニティについても意識するのは良いのかもと思った。
問題はみんなで共有すればみんなの問題
一人で行動しても変化はほとんど起こらない。でも問題をみんなに共有して共感してもらえばそれはみんなの問題になるということは、チームで働く上で本質だなと思った。
問題と感じているところはオープンに共有して、一人で解決するのではなくチームで解決していきたい。
書評を書くことについて
今回も書評を書こうかどうか迷ったときに、「明日の自分に書く」ということを考えた。
コードを書くときは必ず「明日の自分は他人で、他人はそのコードの意図がわからないかもしれないから明日の自分のためにコード(コミットコメント)を書く」と言っているのに、書評は書かないは矛盾しているんじゃないかと思った。これは未来の自分が読んだことを忘れた時のための書評だ。
なので今後も読んだ本で覚えておきたいものは書評を書くようにしたい。
まとめ
いきなり全部やることはできないしこの本にもおそらく一つだけしかできないだろうと書かれていたので、まずは一つやっていくことから意識していきたい。
WordPressの管理画面にログインできない問題の原因がDBだった
WordPressの管理画面にログインできない問題が発生し、解決まで完了したのでブログに書く。正確に事象を説明するとログイン画面は表示されて、正しいログイン情報を入力してログインボタンを押した場合にリダイレクトが発生しログイン画面が表示されるという無限ループが起きた。
調べても出てこないケースの問題だったのと、なかなかに怒りが発生したのでそれをモチベーションに今書いている。
動作環境
WordPress4.7(バージョン関係なし)
AWS EC2
MariaDB
TL;DR
ディスク使用量が100%になるとDBに書き込みできないので、ディスクに空きを作る。
どう調査したか
まずは画面で調査を行い、何が起きているかを確認したところ、ログインボタンを押した時に
POST wp-login.php 302
->GET wp-admin/admin.php 302
->GET wp-login.php 200
とリダイレクトしていることを確認した。
wp-admin/admin.php
のどこでリダイレクトしているか調査したところ、auth_redirect()
のwp_validate_auth_cookie()
でfalse判定になっていることでログイン状態の判定がされないことがわかったので、なぜfalse判定となるのかを調査。
https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L1044
ここからが長かった。
$manager->verify( $token )
がfalseになっていることはわかったが、これがなぜfalseになるのかがわからない。
https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L675
このセッションがどこに保存されているか、このセッションがどういう情報が入っているのかも知らない状態から調べ始めたのでこれが何もわからない。
ようやくwp_usermeta
テーブルにセッション情報が入っていることまで確認したが、もともと入っているデータがどうなっているのかもわからない。
そもそもいつ更新されるかもわからなかった。
これを一つずつ調べるのにすごい時間がかかった。
wp_usermetaテーブルが更新されない
$manager->verify( $token )
はwp_usermetaに入っているsession_token
から、Cookieに格納されているトークンを使って一致するキーから情報を取得するのだが、ここにトークンと一致する情報が存在しないからログイン判定がなされない。
ここに一致する情報がないと絶対に解決しないことがわかったので、どうやって格納しているかを調査する方向に転換した。
調査をしたところ、ログイン成功時にトークンを発行し、それをセッション(DB)とCookieに格納していた。
https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L877
Cookieが格納されていることは開発者ツールで確認している。なのでセッションに格納されないことが原因だと判明。
https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-session-tokens.php#L151
トークンは生成時にセッションに格納している。
この処理でセッション(DB)に格納している。
update_user_meta
を調査。
DBにQueryを実行し結果を返している。まさか。
update_user_meta
の実行結果を出力してみる。
falseが返ってきた。
DBの更新処理が失敗している!!!
原因が判明。あとはなぜDBの更新が失敗しているかを調査し、実際にDBに入って更新処理を実行してみたところ同じように失敗
Disk Full 〜
と出力されたので、DBを抜けてdf -h
を実行、100%となっていることを確認。。。
解決方法
容量を圧迫しているファイルを探し、今回はログファイルを圧縮することでログインできるようになった。
怒りポイント
ソースコードを読むのが辛い
とにかくソースコードを読むのが辛い。ログイン処理とかどこで書き込みしているのかわからない。
https://github.com/WordPress/WordPress/blob/master/wp-login.php
そして、一つの関数の内容が多すぎる。どうみても一つの責務だけを担当していない。
関数のコードが大きいということは、関数内の何で問題になっているかから調査しないといけないので、その労力がすごく大きい。
DB処理失敗時に何もしない
今回の原因となったDBの更新処理について、失敗した場合にfalseを返すだけなので、ログも残らないし処理も終了しない。
DBの更新に失敗ってWordPressだと致命的だと思うので、せめて例外を投げて処理を終了してほしい。
解決したあと、そりゃわからないわと思ってしまった。
まとめ
多分ここで愚痴るよりPR投げた方が早いが、多分WordPressは大きくなりすぎてしまったんだと思う。
自分もこのブログにWordPressの記事を書くことになるとは思わなかった。
もう少し平和に過ごしたい。
RedashのDatasourcesにMySQLがなかった場合の対処法
はじめに
RedashのDatasourcesにMySQLが出てこなかったので、その調査と解決策です。
TL;DR
PythonのMySQL用ライブラリ(MySQL-Python)をAPサーバにインストールする
何が起きているか
Redashでは、Datasourceごとにクライアントライブラリが存在するかをチェックし、存在しないDatasourceは新規作成時に表示されません。
Redashの環境構築を行う際、docker-compose.yml
を使用してDocker上で全て完結する場合は全てのクライアントライブラリをインストールするpipコマンドが実行されるようDockerfileに記載されています。(requirements_all_ds.txt
)
ただ、こちらの記事にある開発者向けの環境構築手順では、Datasourceをインストールする手順が省略されているため、いくつかのDatasourceは表示されません。
何もしなくてもいくつかのDatasourcesが使用できる理由
環境構築で必要なライブラリだからだと思われる。
例えば、Postgresqlはライブラリがimportできるかのチェックすら行なっていない。これはおそらくPostgresqlをRedash自身が使用するため、ライブラリは確実にインストールするためだと思われる。
他にも、MongoDBやAmazon Athenaは、Redashのユニットテストで使用しているため初期から表示されている。
MacにMySQL-Pythonをインストールする
pipでインストールするだけでは動きませんでした。
pip install MySQL-python
また、全てのDatasourceをインストールしようとしても失敗しました。
pip install -r requirements_all_ds.txt
インストール失敗時に表示されたエラーメッセージを読み、こちらの記事を参考にしました。 stackoverflow.com
まとめ
Docker Composeで構築した場合と自分で構築した場合で表示されるDatasourcesが違ったり、いくつかのDatasourcesは最初から利用できることから
最初はとても戸惑ったけど、中を読めばわかる内容だった。
ドキュメントではLinuxでの環境構築が書かれており、Macで環境構築しようとすると少し手間が必要になる。
他に同じような内容で困っている人がいればこの記事が参考になると幸いです。
わからなくても読む。いずれ理解することを目指す
導入
最近、設計について解説されている本や設計パターンの本をいくつか読んでいる。
そんな中、このツイートとこの話題を取り上げているブログをいくつか読んで、自分は今読んでいる設計の話が本当に理解できているんだろうかと不安になった。
UseCase がわからない...
— Yuki Anzai (@yanzm) 2019年2月15日
FizzBuzz で
「3の倍数のときは fizz が返る」
「5の倍数のときは buzz が返る」
「3の倍数かつ5の倍数のときは fizzbuzz が返る」
「3の倍数でも5の倍数でもないときはそのままの数字が返る」
これは
私自身、本を読んだだけで理解できたとはまったくもって言えないし、理解するのにまだ時間がかかると思っているけど
そんな状態でも読むことに意味があるんだと信じたいのでブログでまとめる。
読む対象は本だけではないです。ブログとかのインプットするもの全般です。
まずは用語だけでも目に入れておく
今回のケースは、本を読むことである程度理解できる人ではなく、
なんとなく、主張はわかるけど実際にどうやれば良いのかわからないという人がテーマになる。
私もそういうタイプの人間で、すぐ理解できなかったり、その場では理解できるまで読み込むようなことをしないタイプだけど、それはそれで良いと思っていて
まずは用語を目に入れて、どこかのシーンで「見たことある」というようにしておくことを心がけている。
そうすることで、他の記事を見かけた時に少しずつ前提知識がついていって理解が進むようになると思う。
自分が携わるシステムに触れる時に読む
業務でもプライベートでも、どこかでシステムに関わる機会はあるはずで
そのシステムが自分一人だけで作っているものでない場合、最初に作った人や大きな部分を構築した人の思想というのは絶対に入っているので
それを読んで、システムの理解だけでなく背景や思想まで読み取るような習慣をつけると、思いがけず過去にみた事ある設計パターンの理解に繋がることがあると思っている。
実体験してわかることもある
プログラミングを始めた頃、「オブジェクト指向」や「MVC」について、何を言っているか全くわからなかった。
設計図を作るから何?再利用できるなら関数で良いんじゃないの?って考えてたけど、ちょっと経験を積んで、有名なフレームワークのソースコードを読んでみると
ああこれがMVCか、なるほどこうすることで綺麗なコードになるんだと理解できるようになっていた。
なので、いきなり全てを理解できることはなくて、実際に使用されているシステムのコードを読むだとかその中で開発するという経験はあると理解が進みやすいと思います。
そういう意味では、一つのサービスだけではどうしても触れる領域というのは限られてくるので、小さいアプリを作ってみるとかOSSに参画してみるとかで機会を増やす方が良いと思います。
まとめ
ある意味、一つの勉強法の話かもしれないなと思いつつ、思ったことを書いた。
今回は設計の話で思ったことだけど、これって設計に関わらず全ての事象で言えることだよなーと思ったので、タイトルに設計というワードは入れなかった。
事前にちょっとずつ入れようという話ではあるんですが、別の考え方も持っていて、これってYAGNIの原則とは離れた考え方だよなと思った。
なのでそこは、完全に理解するのは必要になるまで不要ということで結論としたい。
YAGNIの原則で機能は必要になるまで実装しないのに、知識は今必要としなくても得る必要があるって考えてしまって人間設計的には良くないんじゃないかって最近考えるようになってる。でも必要になってから勉強し始めても遅いしなー。必要になるって予測して事前に知識を得るのが一番なのかな。
— taminif (@sbntaminif) 2019年2月14日
「ファクトフルネス」読んで最後まで感動した
FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣
読んだ。最初のきっかけはTwitterだったかブログだったか忘れてしまったけど、最初は「ビル・ゲイツがアメリカの大学を卒業した学生のうち、希望者全員にこの本をプレゼントしたほど」という触れ込みに興味を持った程度だった。ただ、読み終わった今は読んで良かったと思っている。とても良い本だった。
最初から書いてしまうんだけど、「終わりに」の文章まで最高だった。この本を書いたハンス・ロスリングという方が、本を書き始めて約半年で余命宣告をされて、それからこの本を書くことだけために余生を費やしたこと、それでも最後は完成させる前にこの世を去ったこと、救急車で運ばれた時も原稿を手にしていたこと、この本を妻と子供が最後まで完成させたことが2ページ程度に書かれていたのだが、偉大な人がまさに人生をかけて書いた本ということがすごく伝わった。素晴らしい内容だった本が、より感銘を受け感動した。もしあなたがこの本に興味があるのなら、必ずこの本は読んだ方が良いとお勧めできる本である。
「ドラマチックすぎる世界の見方」は正しくない
あなたは、世界は悪くなっていると考えているだろうか?戦争・暴力・災害は減ることはなく、貧富の差は広がっていると考えていないだろうか?
少なくとも紛争は減っているし、災害発生時の支援や救助は年々整備されている。だからその見方は正しくない。だけど、人間はそういう見方をする生き物だ。
「ドラマチックすぎる世界の見方」を変えるのは難しいが、ドラマチックな本能は抑えるべきだ。
ファクトフルネスと事実の見方
どうやって「ドラマチックすぎる世界の見方」を抑えるか、それは、世界を事実で見るようにすることだ。
先ほどの紛争や災害発生時の被害者は、年毎のデータを見ればわかることだ。データを見れば、「ドラマチックすぎる世界の見方」をすることはなくなる。
この本は、ファクトフルネスの方法を習慣化するための手助けをしてくれる。
10の本能と、それを抑える方法
この本では、「ドラマチックすぎる世界の見方」をしてしまう10の本能について紹介されている。
- 分断本能
- ネガティヴ本能
- 直線本能
- 恐怖本能
- 過大視本能
- パターン化本能
- 宿命本能
- 単純化本能
- 犯人捜し本能
- 焦り本能
どれも世界の見方を曇らせるもので、どういうものかとなぜそうなってしまうのか、その回避方法が説明されている。それをここで全部書いてしまうとただの本を写すだけになってしまうし、ちゃんと文章で理解してもらえる内容を私に書く力はない。
この本を読んでその通りだなと思ったことはいっぱいあって、一例を出すと、どんなに勉強をしている人でも一度手に入れた知識をアップデートすることは少ないと思う。この本はそれについても言及されていて、過去の知識を元に考えてしまうことがあると思う。それが不変なものなら問題ないが、世界情勢が不変なことはありえない。
世界は常に変わっている。だから、今の知識をデータで見て、アップデートすることが必要だ(宿命本能)
まとめ
10の本能はひとつひとつ読み応えがある内容なので、ぜひ買って読んでいただきたい。
この本を読んだ後、世界に希望が持てるようになるとのことだったが、確かに読む前と読んだ後で世界の見方が変わった気がする。
自分もクイズの正答率はチンパンジーより悪かったし、事実を見れていなかったので反省している。
ファクトフルネスの10のルールは写真に撮っておいたので、なんども見返しながら実践していきたい。
SkyWayのiOSライブラリ知見二つ/peer.destroyとSKWMediaStream
はじめに
本日ハマったので備忘録を二点残しておきたいと思います。
iOSアプリでSkyWayを使ったアプリを実装する場合に、peerオブジェクトを必ず明示的に破棄するようにしましょう
そして、SKWMediaStream
の操作をするときはメインスレッドで実行しましょう
TL;DR
画面遷移などで一度接続したpeerを破棄する場合は、peer.destroy()
しないと次回接続時のSKWNavigator.initialize(peer)
を実行した時にエラーが発生しないまま動作がストップする。
SKWMediaStream.addVideoRenderer
するときはもちろん、SKWMediaStream.close
するときもメインスレッドで実行しないと接続が切れるまでUIがストップする。しかも、止まるのを待たないまま動かし続けるとフリーズする
(completionhandler
のような接続断後に実行できる関数はない)
経緯
どちらも、以前動いていたものが動かなくなって報告をもらってから調査を行なったもの。
ソースコードは一切変更していなったので、なぜ突然動かなくなったのかはわからない。
おそらく以前から動かなくなっていたと思われるが、リリース当初は問題なく動いていたため、いつからかは不明。
peer.destroy()
ビデオ画面に入室 <-> 退室を繰り返した時に2回目のSKWNavigator.initialize(peer)
を実行したタイミングでエラーも出ず、次の処理にも進まない事象が発生した。
SkyWayのSwiftライブラリは中のソースコードを読むことが出来ず、ステップ実行でどこで止まっているかもわからないためいくつかのサンプルコードを読んで実行して問題ないことを確認した上で、ビデオ終了時にpeer.destroy()
せずにpeerにnilを格納して破棄しているだけであることを発見、解決した。
SKWMediaStream
こちらもビデオ画面に入室 <-> 退室を繰り返した時に、2回目の退室後に入室前画面に戻りはするも、画面がフリーズする事象が発生した。
こっちはどこで処理がストップしているか不明だが、前画面には戻っていて処理は全て完了していたので、こちらもサンプルコードを探して
公式のサンプルではDispatchQueue.main.async
でremoveVideoRenderer
を実行していたため、こちらを参考に修正することができた。
まとめ
SkyWayのiOSライブラリは情報が少なく、原因を調査するのが難しいので
こういうブログでWebに知見を残していきたい。
精神が疲弊しているので本を読んで勉強する
年末から年明けにかけてここ二ヶ月くらい、公私ともに忙しい日々を過ごしていている。それ自体はありがたいことなのだが、仕事が終わって帰ってくるなりほとんど何もできていない。休日もいろんなところに出かけていて、まともに時間が取れないこともあって、最近はほぼアウトプットできないでいる。
ハードワークというわけじゃなくて、精神的に負荷がかかっているのも影響があると思っているのだが、パソコンを開いてもあまりモチベーションが上がらないまま時間が過ぎてしまう。
何もできないとやっぱり焦りはあって、今はできるだけ頑張れることを頑張るようにしていて、その一環で本を多く読むようにしている。でもインプットするからにはアウトプットもした方が効率が良いし、この二ヶ月で読んだ本について良かった本をアウトプットする。
禅マインド ビギナーズ・マインド (サンガ新書)
Team Geek ―Googleのギークたちはいかにしてチームを作るのか という本で、リーダーシップパターンの中に「禅マスターになる」という章がある。リーダーはどのような状況でも禅の心を持って平静を保ち、知識に沿った判断をするというものである。これとは別に、仕事の上でついつい感情的になってしまう傾向があり、自分を俯瞰する技術を身に付けたいと思ってどうすれば良いか考えたときに、禅を学ぶことを決めてこの本を読んでみた。
禅の本を一冊読み終えた。今あなたはここにいる。あなたがここにいる時あなたはここにいないのです。ニルヴァーナ。座禅を組む。立っている。あなたは立っている時座禅をしている。空になる。全てを受け入れる。それが禅です。
— taminif (@sbntaminif) 2018年12月19日
全然わからん。わからないことも禅らしい。
このツイートはわりと本音を書いていて、読んだ結果は全然わからなかったというのが正直な感想である。
ただ、禅とはそういうものらしい。本を一冊を読むだけではわからないとは思っていたけれど、禅は学び続けるのでちょっとずつ学びたい。
おとなの教養 私たちはどこから来て、どこへ行くのか? (NHK出版新書)
面談で教養つけた方が良いんじゃない?と指摘をもらって、Amazonで「リーダー 教養」で検索して良さそうなのをいくつか見繕って買った本のひとつ。前にも池上さんの本は読んだことがあったんだけど、この人の本は読みやすくてすぐ読めるのが良い。
歴史や宗教が人を形成していったことがわかりやすく説明されていて、教養がなかった私にも、すでにある人も再認識するという意味で良い本だと思う。
自分は教養をちゃんと理解できているか怪しいけど、これから多くの人と関わる上である程度多くの人が持っている普遍的な情報を持たないといけないと思っていて、こちらも時間をかけて学んでいきたいと考えている。
異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養
世界中の人と仕事をする際に、その国のコミュニケーションの方法、仕事の付き合い、評価の伝え方などそれぞれで違った文化を持っていることを知り、その国に合わせることで仕事をスムーズに進めるという本で、とても参考になった。
日本で働くだけであれば国に合わせるようなことはそうそうないことだが、自分の職場にも海外で育った人が働いて、その前提を持って話をすることはひとつのテクニックだと思うので、実践できればと考えている。
プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
コードもあまり書けていないのだが、この機会に基礎的な本を読もうと思ってこの本を読んだ。
「3年目までに身に付けたい100の原則」とあるように、プログラミングする上で知っておくと綺麗なコードになると思う参考になる本だった。
自分はもう9年目なのですでに遅いかもしれないが、どれだけ時間がたっていてもちゃんと学ぶべき内容だったし、読んで良かったと思う。
「コンウェイの法則」など、この業界で何年か働かないとスッと入ってこないような内容もあって、読み直すのもオススメしたい。
リーダーが育つ55の智慧
「リーダーが育つ55の智慧」読了。ニトリの創業者による社員育成のための手法が書かれた本。一度この人が書いた本を読んでみたいと思って、今勉強しているリーダー論と関連がある本で良いタイミングだったので読んだ。考え方が面白く読んで良かった本だった。常に行動し続けて数字を意識したいと思った
— taminif (@sbntaminif) 2019年1月16日
ニトリに行った時にこの本が積んであるのを見たのと、記事などでこの人の特集を読んだことがあって
気になっていたので、この機会に読んでみた。
上のツイートの通り面白かったし、人には向き不向きがあっていろんな舞台でチャレンジさせてあげるとか、
常に改善を行うなど、実践してみたいと思う内容だった。
今読んでいる本
FACTFULNESS(ファクトフルネス)10の思い込みを乗り越え、データを基に世界を正しく見る習慣
まだ第1章を読んだだけだが、面白そうで楽しみにしている。
私も事実を見ずに印象だけで思い込んでいたので、この本を読んでちゃんと物を見れるようになろうと思う。
まとめ
なんとなくだけど、海外の本で翻訳されたものと日本の本ではボリュームが違うのはなんでだろうと思った。
ちなみに弊社は本を全て会社で購入してもらえるので自分で買った本はない。
いずれまとまったアウトプットはしたいが、そのためにもちょっとずつ勉強できたらと思う。