パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

三菱東京UFJ銀行でオープンソースのフレームワークSeasar2が採用される」記事へのコメント

  • Seasar2って (スコア:5, 参考になる)

    by Anonymous Coward
    Seasar2ってどこのblogとか掲示板にのりこんで暴れまわるのやめれば使うという人は多いですね。

    また、日本のプロジェクトなのに日本語ドキュメントが少ないとか、サイトをどう歩けばいいのかわからないとか(これは最近だいぶ改善されました)、まったくコメントのないソースファイルを追うのは面倒だとかまぁ問題は山積みです。

    せっかく日本のプロダクトなのにまったく同じ技術のSpringのほうが採用されることが多いです。実績とかの違いも多いですがドキュメントの差が大きいですね。

    結局ひが氏のサポートがないと使えないようにわざとしてるように取れます。何のためのオープンソースなのかなぁと。

    せめてメソッドの頭に1行コメントくらいつけてよ。
    • Re:Seasar2って (スコア:1, 興味深い)

      by Anonymous Coward
      > Seasar2ってどこのblogとか掲示板にのりこんで暴れ
      > まわるのやめれば使うという人は多いですね。

       同感です。まぁ、議論しようとしているのかもしれま
       せんが。
       
       端から第三者として見ているとプロジェクトメンバー
       で気に入らない人を袋だたき(表現は悪いですが)にし
       ているようにも見えてしまいます。

       公開されているところでの売り言葉に買い言葉的な応
       酬はマイナスにしかならないと思うのですが。

       まぁ、プロジェクトの中心メンバーが率先している現
       状では改まらないかもしれませんね。
      • by Anonymous Coward
        >> Seasar2ってどこのblogとか掲示板にのりこんで暴れ
        >> まわるのやめれば使うという人は多いですね。
        >同感です。まぁ、議論しようとしているのかもしれませんが。

        Seaser2に批判的な意見に対し、
        「それはSeaser2に対する冒涜だ。」
        「公式に謝罪を要求する。」
        「謝罪のために、こちらにまで出てこい。」
        「適切な対応を取っていただけない場合は、名誉毀損で訴える。」
        という風に脅迫まがいの行為を行ってるとなると、何か知られ
        ては困る事実をひた隠しにしているんじゃないかと邪推したく
        なります。

        批判的な意見ならば反論すれば済むし、単なる誹謗中傷ならば、
        普通は無視するだけ。発言そのものを無かったことにするために
        手段を選ばずにたたきつぶすのは、やはりそれなりに理由が
        あるのでは?
        #「JavaはC++のサブセットじゃないか」と言われて、
        #「それはJavaに対する冒涜だ!名誉毀損で訴えるぞ。」
        #なんていう人いないよな。
        • Re:Seasar2って (スコア:1, 興味深い)

          by Anonymous Coward
          今いろいろと検索してみたけど殺し合いとかすごいテンションだな。

          引用
          ># habuakihiro 『ないですよ>愛(w ぶっちゃけ殺し合いだから。先に手袋を投げつけたのは相手だしね。
          というか、そもそも相手を低く見てませんか? 裏にどんな味方がついてるかわからないじゃないですか。有能な弁護士を雇ってくるかも知れないわけですよ。煽って馬脚を現してくれるほうがいいです。
          tpircsさんが読んでて不快になるのは当然です。やってる当人が不快なんだから(^^; だから当事者以外は見ないほうがいいんですよ。
          まともな議論になることを期待するほうが間違ってるんです。みんなそういう幻想を持ってるからデスマがなくならないんです。』
          • by Anonymous Coward
            どこからの引用ですか?URL教えてください。こんな自然言語文章はGoogleでもうまく拾えないし。

            >裏にどんな味方がついてるかわからない

            お互い様だな(わら

            つーか、ま た ハ ブ か 。
            (文字通り「また大阪か」だな)

            口調はともかくとしても、内容についても、奴の言うことは一面的なことが多い。
            技術サイドで特に気になるのはSQL信者っぷりかな。
            そんなにSQLが好きなら、全業務アプリをSQLとPL/SQLで書きゃいいだろうに。
            こないだの雑誌記事でも色んな言語を批判するくせに、SQLには批判を全然向けない。
            他の言語で構造化(というか関数分割)をしろとしきりに言う(それ自体は間違ってない)くせに、SQLは平気で数百行のサンプルを書いて「SQLのテクだ」とか称している。
            SQLが有利なんじゃなく、単に君の頭がSQL脳なだけだろ。
            • by Anonymous Coward
              こないだの雑誌記事でも色んな言語を批判するくせに、SQLには批判を全然向けない。

              まだ読んでますか?

              興味があるので、その雑誌名と掲載号を教えていただけると嬉しいです。

              • by Anonymous Coward
                たとえば最近の例。

                WEB+DB PRESS Vol.33
                特集1
                オブジェクト指向エンジニア必読 構造化プログラミング入門
                第1章 「きちんとコードを書く」ための大原則
                http://www.gihyo.co.jp/magazines/wdpress/contents

                COBOL、VB、Web開発、OOP、LL、などによる開発が混迷する(こともある)と言っている(それ自体は正しいが)一方で、SQL(で「処理」を記述する必要が無いこと)のメリットばかり説いてSQLのデメリットは触れてない。扱いが不公平。まるでSQLが銀の弾丸であるかのような書きっぷり。

                =======================

                SQLだって幾らでも長く難解なス
              • by Anonymous Coward

                #984264 の AC です。

                つまり最下層以外を担当する意思なんか無い言語だ。要するにアプリ全体は書けない。

                …何なんだこのSQLという言語の半端な姿勢は?

                SQL の短所については同意です。ただ、姿勢に関しては、最下層のみ担当するということで、半端ではないんじゃないでしょうか。

                つまりSQLは化石だ。生きている(とはいえ)化石だ。

                LINQ は、進化形としてはちょっと違うかな。

              • by Anonymous Coward on 2006年08月04日 0時22分 (#990555)
                >姿勢に関しては、最下層のみ担当するということで

                でも窓関数とかは最下層言語としてはオーバースペックというか。

                他にも色々、使用用途の名前がついた機能(わら)がSQLには有りますよね。もうアホかと馬鹿かと。

                根本的には整列(SortつまりOrder-by)機能は最下層言語には蛇足だと思います。

                集計(Group-by)は必要だと思ってもいいとは思いますが、それは現状のSQLのように返しLISTの部分列をSORTすることで実現するのではなく、LISTの更にLIST(か配列:平たくいえば二次元配列)という返しデータ型の構造化によって実現すべきだったと思います。

                だってそうしないと、呼び出し側のアプリ言語や、パイプラインの後段(後述)で、「Group化されたサブLISTのLIST」という本来の構造をParseして再現しないとならないんですもの。もともとあった二次元構造をわざわざ捨ててしまったせいです。馬鹿みたい。

                昔のようにBASICみたいな困った言語やCみたいな中級言語しかない時代なら、本来最下層であるSQLに高級言語としての仕事(であるSORT)をやらせるってのも「仕方ない」選択肢だったかとは思いますが、Javaや(出来のよい)LLが色々選べる現代においては、整列を最下層でやるのはシステム構造的にお世辞にも綺麗とは呼べない役割分担だと思います。低コストかつ安全にSORTを行う手段が、BASICやCにはロクに無く、JavaやRubyには有る。

                >LINQ は、進化形

                LINQやPowerShell…どっちもMS製品なのは偶然なのか、それとも意図したMS大攻勢なのか…には期待しています。従来の枠から大きく逸脱しないが今風に洗練しなおした文法。きちんとした関数型言語のエッセンスの再導入。DBもそれ以外も統一的に扱えるっていう辺りは(DBの話題をするときには)どうでもいいことですが、それにしてもこれは色々なものがかなり綺麗になるんじゃないかと期待できそうです。

                基本的には、パイプラインと(FCOな)関数としてのQUERYっていう考え方があれば、いいんだと思います。

                あと関数を代入すべきローカル変数(純粋関数型言語として捉えれば定数)を使うか否かは、変な構文縛りじゃなく常にプログラマに選択肢があること。つまり有名も無名もまったく自在に使い分けれること。変数のSCOPEという概念も必要ですね。

                #with select hogehoge select fugafugaというwithによるサブクエリの名前付けが、Select文では使えるがUpdate文で使えないってのは、何考えてんの?

                それらが使えれば、素直なQUERYをいつでも記述できるようになると思います。

                個人的には、いまいち不純ですが、RubyでQUERYしてもいいと思っています。要するにClosureが使える言語ですね。
                こんな感じ。
                table1.select{|row|
                row.abc > 1 # SQLでいうWhere
                }.map{|row|
                [row.x, row.y] # SQLでいうselect カラム名
                }

                Rubyなgroup_byの実装は
                http://pub.cozmixng.org/~the-rwiki/index.rb?cmd=view;name=Enumerable%A4%F2%B3%C8%C4%A5%A4%B9%A4%EB
                に紹介されてますね。そうそう。そういう風にGroupはサブLISTで表現するのが絶対正解だよなあ。

                Rubyの場合、メソッド呼び出しの「.」が、ちょうどパイプラインの「|」みたいな立場になるんで、素直に左から右に処理を読み下せて、すごく快適です。
                親コメント

身近な人の偉大さは半減する -- あるアレゲ人

処理中...