明日は社長とかとYAPCに行く予定だったんだけど、数年に一度くらいしか会えない友人に会う予定ができてしまったので中止。
あさっては行きます。
それと、RubyKaigi2008 なんだけど、チケットを予約したはいいけどいろいろ立て込んでて結局取れなかった。
懇親会のチケットはとれたけどね。
懇親会だけ参加ってなんだよそれって感じだよね。
ていうか何あのローソンチケットのシステム。
ほんと使えねー。
ネットで予約してから三日以内にローソンにチケット取りに行かないといけないって何それ。
あと、ロッピー使いにくい。
ダメあんなの。
まあ僕の考えが甘かったのがいけないんだよなあ。
あー、もう、自分にがっかり。
忘れないうちに書いておこう。
 |
その子育ては科学的に間違っています 国米欣明 サワダサワコ 三一書房 2007-11-05 |
僕は子育てに関する話が結構好きなんです。
なのでこの本もなかなか面白く読める。
まだ半分しか読んでないけど。
「科学的に間違っています」と言っているわりには科学的な根拠をきちんと示せていない、もしくは説明不足な感じがする部分が多いというか、根拠のあやふやな主張ばっかり。
ていうかそもそも「子育て」について考えるのって非常に難しい。
「科学で説明できるのか？」という気がする。
「科学的に正しい子育て」という考え方がそもそもおかしい。
何をもって「正しい子育て」とするか、というのも人によって全然違ってくるだろうし。
まあ、僕が見てて「子育て失敗してるなぁ」とか思ってしまうのは、親が子供に主導権を握られてしまっていたりするケース。
あと、自分の思うように子供が育たなかったのを、自分のせいではなく子供のせいにしようと必死になっていたりするケース。
著者曰く、今主流の「子供中心の子育て」が諸悪の根源である、とのこと。
著者の言いたいことはよくわかる。
子育てが上手くいっていないケースってのはだいたい、子供と親の関係がどことなく「ぎくしゃく」しているというか、信頼関係が希薄な感じなんですよね（かなり想像だけど）。
親が子供にどう接していいかわからなかったりするんでしょうね（僕もわからないときはあるけど）。
ていうか、この本の文章が気にくわない。
変に感情的でまるで科学的な説明になってないように思える箇所が多い。
アマゾンのレビューを見てみると、ずいぶんたくさんの人が高評価を下してるけど、どうかと思う。
こういう本の内容を簡単に信じてしまうのは良くない。
どんなものでもまずは疑ってかかるべき。
思ったのが、どんな主張であれ必ずミスリーディングしてしまう人が（自分も含め）一定数いるってこと。
例えば「子供中心の子育て」に関しても、その考え方が必ずしも間違っているわけでは無いと思うんだけども、本質を読み違える一定数の人たちがそれを悪い方向に持って行ってしまう（気がする）。
僕が思うのは、これ子育てに限らずなんだけど、周りに流されずに自分の頭でちゃんと考えないとダメ、ということ。
たとえ始めは間違ったやり方をしてしまっていたとしても、子供や自分自身をよく観察することでその間違いに気付くことができるはず。
自分の頭で考えようとせず、誰かが言っている適当な言説を簡単に信じちゃうからいけない。
あと、時代によって「正しい子育て」というのは変わってくるのだと思う。
人間はそれに適応していく必要がある。
適応していく必要があるというか、適応できなければ淘汰されるだけなんだけど。
だからこそ自分の頭で考えることが非常に重要。
ここで「自分の頭で考える」とか簡単に言ってるけど、これはそんな簡単に言えるような事じゃない。
けどその話はまた別の機会に。
RubyKaigi2008 のチケット予約した。
懇親会のほうも一応とったけど、知人とかいなそうだからなんか不安。
ちなみに、チケットの予約は以下から。
Lコードっていうので検索する。
Lコードは以下。
| RubyKaigi2008 | 35770 |
|---|---|
| RubyKaigi2008 懇親会 | 35610 |
追記
やばい。
ローソンにチケット取りに行けなかった。
 |
ひとりでも部下のいる人のための世界一シンプルなマネジメント術 3分間コーチ 伊藤 守 ディスカヴァー・トゥエンティワン 2008-03-13 |
思った以上におもしろかった。
部下いないけど。
会社というものを考えていく上で非常に参考になる内容だった。
…
運輸業のマネジャーは、自分の上司に良く言われたことを思い出すそうです。
「もし、お前に言われたとおり部下が動くのなら、お前はいらない」
確かに。
コーチングでは、基本的に「アドバイス」はしない、問題解決もしない、ただ、問題とのつき合い方をコーチします。これにより、部下のそれぞれが、現場で起こることに、毎度上司の指示を仰がなくても自分で対処できるようになるのです。
それがなかなか簡単にはいかないんだなぁ。
ダグは言います。
「みんな、会社や組織の求める目標を、まるで自分の意志であるかのように口にするけれど、たいてい、その目標は完璧には達成されない。必要なのは、一人ひとりに自分個人の目標を見つけさせることなんだ」「ほんとうのゴールは、一見、目標と思えるようなものの先にある。それを見誤ってはならない。上司は、そのことを頭において、部下の目標設定をコーチする」
「それだけではなく、スタッフ一人ひとりの目標が、会社の目標とつながっているかどうかを確認しなければならない。そのために、一人ひとりに、自分の目標は何であるかを考えさせるんだ」
ほんと、おっしゃる通り。
だいたい、うまくいっていない会社やプロジェクトってこういうことが全然考えられていないんですよね。
会社だけがうまくいくということはありません。同じように、そこで働く個人だけがうまくいくということもありません。
これ重要だなぁ。
Web アプリケーションフレームワークを使うべきか否か。
当然使うべきでしょ。
開発効率が全然違ってくる。
ものすごく特殊なアプリケーションとかだったら適用するのは難しいかもしれないけど、ほとんどの Web アプリケーションが何かしらのフレームワークを使って構築できるはず。
フレームワークの選択を誤ると無駄にコストがかかるかもしれないけど、ま、そうそう間違えないでしょ。
メジャーなフレームワークには、たいていわかりやすいドキュメントがある。
ドキュメントがあるとシステムの見通しが良くなるので、メンテナンスがやりやすくなる。
例えば、独自のフレームワークを作ったとしてもドキュメントが無いと他の人がシステムを理解するのに余計な手間がかかる。
ドキュメント書くのって結構面倒くさい。
要は、どこにコストをかけるか、という話ですね。
自社の製品にめちゃくちゃ特化したフレームワークをはじめにコストをかけてドーンと作って、それを活用することで後々の開発のコストを下げるのか、メジャーなフレームワークを活用して開発コストを下げるのか、という。
図にすると以下のような感じ（状況によって違ってくることも多々あると思いますが）。
フレームワーク無しでいく場合
フレームワーク無しでいく場合、各開発において効率が相当悪くなることが予想されます。
似たような機能をそれぞれで実装したりするはめになるので。
独自フレームワークでいく場合
フレームワークを作るのにかなりのコストがかかります。
それに、そこそこ使い物になる良いフレームワークを作るにはかなりの技術力が要求されるので、優秀な技術者がいないと厳しいです。
メジャーなフレームワークを活用する場合
メジャーなフレームワークを使うと全てが上手くいきます！
（嘘）
複数の情報筋からの情報：２年近くの間、高い頻度で発生していたスケーリング関連のトラブルで、TwitterはRuby on Railsのフレームワークを捨て、PHPないしJava（Rubyは使い続け、Railsのフレームワークのみを放棄する案もあるようだ）を使ってゼロから作り直すことにしたようだ。
実際のところどういう問題があったのか知りたいな。
おそらく、Twitter のような膨大なトラフィックを集めるサイト特有の問題だと思われる。
以下のような話も関連してるんだろうな。
TwitterのスケーリングについてはCookがその任に当たっていたが、彼はこの作業をうまくこなすことに失敗した。
[略]
Twitterは今年になって、少なくとも３つ、キーとなる技術面での雇用を行っている。Lee MighdollはVPエンジニアおよび運用担当として１月から参加している。そして今週になってJohn Kaluckiと（「BloggerおよびBlogspotのスケーリング分野での働きでその名を知られる」）Steve Jensenという、２名のスケーリング分野のエキスパートを採用した。
というか、アレですよ。
Web アプリケーションをいかにスケールさせるか、という話になってくると、どのフレームワークが良いとかそういう話の重要度はきわめて低くなってくるんだろうな。
例えば、Java もしくは PHP に置き換えることによってシステムの負荷がほんのちょっと下がるだけでハードウェアにかかるコストがものすごく減る、なんてこともあるだろうし。
ごくごく一般の Web アプリケーションにおいてはこういう問題はそうそう起こらないと思う。
つまりは、「開発コスト」と「運用コスト」の二種類のコストがあって、サイトの規模や種類によってどちらの負担が大きくなるかが変わってくる、ということですね。
そういったことを考慮した上でシステムに採用する技術（言語やフレームワーク等）を決める必要があると。
なので、 Rails がダメだったから、とか早急に結論づけるのは問題の本質をとらえ損ねてるわけですよ。
いや、でも、Rails もしくは Ruby に致命的な問題があったとかだったらまた話は変わってくるけど。
うーん、アレですね。
Web アプリケーションをちゃんと作るのってくそ面倒くさい大変ですね。
というか、Web という基本ステートレスな環境でいろいろなことを表現しなくちゃいけないというのが、本当に、、、特殊。
慣れるまでは大変。
僕は今までは主に Windows 上で動く GUI アプリとか、RPC によるサーバークライアント型システムのサーバー側の処理とかを Java とか C# なんかで作ってたりしたんだけど、まあこういうシステムってそこそこ直感的ではあるんですね。
プログラミングとしては、特にマルチスレッドで動く部分とかがあるといろいろ大変になってくるけど、そういう部分さえ意識していればその他の部分はわりと作りたいように作れる。
そこそこ思い通りに表現できたり、無理のない実装、綺麗な実装にできたりとか、オブジェクト指向的に作れたりとか。
なんていうか、クラスを中心に物事を考えられるんですね。
こういう感覚に慣れているから、いや、こういう感覚にしか慣れていないから、Web アプリケーションの開発って非常に、とまどいます。
僕としては、アプリケーションの土台となるような部分に一本ビシーッと筋が通ってて欲しいんですね。
この処理はこれが面倒見て、ここに関してはこれが責任を持つ、とかそんなような。
Web アプリケーションにおいてはそういうのを一から作らないといけない。
ま、フレームワークってのがそういう役割を担うものなわけなんだけど。
で、巷には Rails とかいろいろあるわけですが、導入するにしても学習コストが馬鹿にならない。
ていうか、Web アプリケーションフレームワークって種類多すぎじゃね？
例えば、僕は Swing のような GUI ライブラリが何十種類も存在するなんてのを想像できない。
それだけ Web アプリケーションって特殊なんだな。
とか、簡単に結論づけちゃってるけど、これは結構切実な問題なんですよね。
今まさにそういうところで悩んでいるわけなので。
（GUI ライブラリと簡単に比較するのもどうかと思うけどね）
というわけで、いろんな Web アプリケーションフレームワークをザーッと眺めていこうと思ってます。
上手くまとめて社内勉強会なんかで発表できるといいなぁ。
