タグ

ブックマーク / kwatch.hatenadiary.org (6)

  • 次の絶対可憐チルドレン(アニメ)はデスノートのパロディ回 - kなんとかの日記

    さて、次週はいよいよ「ですノート」編、予告でもう爆笑でした。平野さんのミ●ちゃんネタも出るか!? あと、OPが特別版です。お見逃しなく! アニメ第45話: 完成原稿速報・ブログ版 デスノート編キター! 絶チル史上最高に面白い話だけに期待++! あ、そうだ、明後日のアニメ、絶対見てね。原作ファンにもアニメファンにも大笑いしてもらえると思います。 燃えたよ・・燃え尽きた :週刊少年サンデー09/13号: 完成原稿速報・ブログ版 見ますよ、見ますとも! 椎名高志のパロディセンスが神懸かってたネタですから! 明後日の朝10時はテレ東にかじりつけ! #これでつまんない内容だったらアニメスタッフは切腹もんだよな。

    次の絶対可憐チルドレン(アニメ)はデスノートのパロディ回 - kなんとかの日記
    tokada
    tokada 2009/02/21
  • 従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

    従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている。 ソフトウェア開発では、個人の生産性は上と下とで 30 倍違うと言われる。これが当だと仮定したら、これだけ差がでるものを均一化なんてできるわけない (したところで間違った結論しかでない) んだから、属人性を排除することは大きな誤りである。 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 よく、ソフトウェア開発を工場での作業に例える人がいるけど、これも「属人性を排除できる」という勘違いからもた

    従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記
  • Merb 1.0 リリース記念に、Merb がどんだけすごいのかを紹介した海外の記事を翻訳してみた - kwatchの日記

    まつもとさんもお気に入りという Merb フレームワークの 1.0.0 がリリースされた。これは Rails 一辺倒だった時代から、複数のフレームワークが入り乱れる時代への切り替わりを告げる、大変重要なリリースだと思っている。 しかし日のニュースサイトでは何の記事にもなってないようで、大変残念だ (InfoQ は翻訳記事を載せてくれるだろうけど)。 仕方ないので、多少なりとも日で Merb が盛り上がるように、海外の優れたブログの投稿を翻訳してみた。これを読めば、Merb がいかに期待されているか、わかると思う。 翻訳して初めて知ったけど、Django の slice という機能が Merb にも搭載されているそうだ。しかし「Django スライス」でぐぐっても、Python のスライス (list や tuple の要素を取り出すための言語機能) しかヒットしなくて、よくわかんなかっ

    Merb 1.0 リリース記念に、Merb がどんだけすごいのかを紹介した海外の記事を翻訳してみた - kwatchの日記
    tokada
    tokada 2008/11/12
  • デザイナに eRuby を書かせるべきか否か - kなんとかの日記

    masayang氏に、わざわざ回答をいただいた。ありがとうございます。 eRubyでXHTMLの大枠を記述するのはRubyエンジニア そのeRubyの編集をデザイナにも解放せよ デザイナがeRuby構造を壊したとしても、テストで検知できるし、最悪リポジトリから戻せるではないか 技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記 これは同意できる。 リポジトリの概念はCSSの階層構造を理解できるデザイナなら、すぐに習得できる 技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記 これはよくわからない。リポジトリと、CSSの階層構造は、似ているとは思えない。 デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、A

    デザイナに eRuby を書かせるべきか否か - kなんとかの日記
  • t_yanoさんのコメントへのコメント - kなんとかの日記

    t_yanoさんの日記でのコメントへのコメントです。こちらの質問に対して正面から答えてくださっているのと、長くなったこともあって、自分の日記で書かせていただきました。 えーと、例に挙がってるような改変が、大規模開発に役立つかどうか、という意味と理解しました。 そうですね、役にも立たない、まではいうつもりはなくて、少なくともプラス方向に影響を与えるだろうなと思いますよ。 一行で書くとしたら、「不利にもならないし、実際役に立つ。でもそんなに大きく役立つわけでもない」というところです。 悪影響もないし、簡単になるんだったらやったらいいんじゃない?というのが私の意見ですね。私のような趣味でもJava触る人間にとってはプロパティ構文とかはものすごく欲しいですけどね... 上記で明記は終わり。 http://d.hatena.ne.jp/t_yano/20080503/1209847383#c1210

    t_yanoさんのコメントへのコメント - kなんとかの日記
    tokada
    tokada 2008/05/06
  • Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記

    まじめな話に切り替えて、Java屋さんJava信者さんに質問したいと思います。 質問: Java における、質的でない冗長な記述は、どのように大規模開発に役立つのでしょうか。 質問の背景を説明すると、以前の晒されエントリで、Java における質的でない記述の数々について話題にしました。それに対する反応で、『Java は大規模開発向けだから記述が長くてもいいんだ (または長くなくてはいけない)』という意見が多くあります。 たとえば、ブックマークコメントより: エンタプライズ分野であの大伽藍が求められたのだから仕方ないですよ。 エンタープライズ分野のような大規模開発こそ、必要な情報を簡潔にわかりやすく記述する必要があると思ってたんですが、世の中は違うようです。 同じくブックマークコメントより: Java屋の怠慢は高層ビル建築をどうサボるかであって、犬小屋を作る時にどうサボるかという視点とは

    Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記
    tokada
    tokada 2008/05/04
  • 1