子供に最初にプログラムさせるという話になると、 まずテーマに選ばれるのは、キャラクタを動かす、図形を描く、そして、ゲームくらいだろう。 しかし、それは適切ではないかも、という話。
Hackety Hackでは、ゲーム以外の手段でプログラムを学ぶ。 それはゲームのプログラミングは難し過ぎるから(_whyによれば)。
確かにそうかもしれない。私でもゲーム(でも難しいからBASICの頃の古典的キャラクタゲーム)を 題材に選びそうだものな。
弾さんによる 「Matzさんでさえ言及した様子がない」新言語Xtalの紹介。
うーむ、実はこっそりブログでの開発状況を観察し 密かに愛でていたのに。
個人的な経験から言えば、言語仕様がある程度安定するまでは 人の意見を聞かず、自分が「これ」と思うところを追求した方が 最終的に良い物ができる可能性が高まると思っているので(独り善がりになる危険性も高まるんだけど)、あまり人に知られない方が良いんじゃないかなあ、と思っていたのだ。
が、弾さんのところみたいな大手からリンクされたんじゃ もう隠しておく意味はなくなったな。
個人的にはXtalは
など面白いところがたくさんあると思う。
でも、メジャーになるには冒険しすぎかもしれないと思ってしまうのは 私が年を取って安定指向になってきたせいかしら？
いや、別にメジャーにならなくても全然問題ないんだろうけどね。
最悪のケースを想定することでより良い見積もりが出せる、という話。
まあ、単純に「見積もって」と言われたら、 こんな作業が必要そうだから、と思いついたものを積み上げて見積もるわけだが、 ソフトウェアの場合、「必要そうな作業」は恐らく本当に必要な作業のごく一部に過ぎない。 「最悪のケースを想定して」と言われると 最悪のケースを想定するためにいろいろな状況を考慮する必要があるわけで、 より多くの状況を考慮することでより正確な見積もりが出せるということなのだろう。
考えてみれば当然のことだが、見積もりは悲観的に。
個人的には、(〆切のある)仕事でソフトウェア開発の見積もりを行う時には、 普通に(特に悲観的でなく)見積もった時間に1.5から2.5までの係数を掛けることにしている。 最初はかなり罪悪感があったが、最終的にはいつもちょうどいいか、ほんのちょっと余るくらいで 収まるので、こんなものかな、と思っている。
この方法を実践するまでは、いつも見積もりばかり甘くていつも火の車だった。 健康を壊しかねない。
Railsに関するGeek Sessions。 今回のテーマはスケーラビリティ。
レポートを読むだけでも面白そうなネタが満載であることがわかる。 こういう交流も重要なんだろうなあ。
もうちょっと詳しいレポートは「geekSessions I: Ruby on Rails: To Scale or Not to Scale」に。