{"action":"created","issue":{"url":"https://api.github.com/repos/kcis/kcis/issues/3","labels_url":"https://api.github.com/repos/kcis/kcis/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/kcis/kcis/issues/3/comments","events_url":"https://api.github.com/repos/kcis/kcis/issues/3/events","html_url":"https://github.com/kcis/kcis/issues/3","id":57928551,"number":3,"title":"フレームワークの再選定の是非について","user":{"login":"func-hs","id":1285850,"avatar_url":"https://avatars.githubusercontent.com/u/1285850?v=3","gravatar_id":"","url":"https://api.github.com/users/func-hs","html_url":"https://github.com/func-hs","followers_url":"https://api.github.com/users/func-hs/followers","following_url":"https://api.github.com/users/func-hs/following{/other_user}","gists_url":"https://api.github.com/users/func-hs/gists{/gist_id}","starred_url":"https://api.github.com/users/func-hs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/func-hs/subscriptions","organizations_url":"https://api.github.com/users/func-hs/orgs","repos_url":"https://api.github.com/users/func-hs/repos","events_url":"https://api.github.com/users/func-hs/events{/privacy}","received_events_url":"https://api.github.com/users/func-hs/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/kcis/kcis/labels/%E8%AD%B0%E8%AB%96%E3%83%BB%E5%86%8D%E8%80%83","name":"議論・再考","color":"f7c6c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-02-17T14:13:35Z","updated_at":"2015-02-17T16:21:54Z","closed_at":null,"body":"# はじめに\r\n\r\nフレームワークを見つめなおす必要があると聞いて。確かにMVCやそれらに関するドキュメントが1箇所に固まってるのはいいことだし、可能な限りそうなるように努力する必要があります。\r\n\r\n# 前提条件\r\n\r\nまず、どのフレームワークを選ぶにしても、以下の事はまず前提として記憶しておく必要があると思います。\r\n\r\n## 必要な機能\r\n\r\nデータベースとページ部品間とでデータのIOのみを行う(そこから先の複雑な計算をコンピュータが必要としない)ようなシステムの場合、モデルやコントローラを多機能なものにしなくても\r\n\r\n* ルータ\r\n* コントローラ(あくまでURLアクセスに対して遷移先を決定する程度のごく単純なものでOK)\r\n* ビュー\r\n* データベースへ直接アクセスを行うAPI、及び、構造体やクラスもしくはそれに近いデータ構造(データベースとやり取りするデータを一時的に保存するのに使う)\r\n\r\nがあれば実装しきれる場合が多いです。現KCISの機能は、グラフチャートやカレンダーの出力こそ必要となるものの、前者はウェブフレームワークとは別なツールが必要になるだろうし、後者はほとんどCSSやJavaScriptの領域なため、MVC間がやるのはあくまで単純なデータの送受信に留まると思います。\r\n\r\n## 単純なデータ入出力より複雑な処理は存在しないか\r\n\r\nフレームワークや開発に利用する言語を丸ごと入れなおすという場合、データを単純に入出力するということよりも複雑な処理を、そのフレームワークや言語がどこまでカバーできるかをよく考える必要があります。\r\n\r\n## 気持ちや感覚的な事(哲学的ともいう)は後で\r\n\r\n意義があるかどうかは、一通り作ってしまった後で考えればよいと思います。\r\n今からそれを考えだしてしまうと、そこで行き詰まってしまうことが多いからです。\r\n(自分の人生の意味や意義を今考えても仕方ないのと同じ)\r\n\r\n# 雑感\r\n\r\n私としては、今の仕様の範囲では、あまり多機能なフレームワークは必要ないかなぁというのが正直なところです。**スキャフォールド**や**高機能なリクエスト・レスポンスハンドリング**が必要になるかは疑問。\r\nPHPやRubyは、フレームワークの機能範囲よりも言語仕様との闘いになるような…？\r\n\r\nまた、本格的な再選定への議論や検討は、 @master-q さんが中国へ渡ったあと、出張先の職場でも同様に行われるような気がします。\r\n\r\nこれらを踏まえた上で、今週中(できれば2/19まで)に話しあいましょう :)\r\n\r\nP.S.: 私としては Play+Scala でも全然平気ですよ！"},"comment":{"url":"https://api.github.com/repos/kcis/kcis/issues/comments/74696198","html_url":"https://github.com/kcis/kcis/issues/3#issuecomment-74696198","issue_url":"https://api.github.com/repos/kcis/kcis/issues/3","id":74696198,"user":{"login":"func-hs","id":1285850,"avatar_url":"https://avatars.githubusercontent.com/u/1285850?v=3","gravatar_id":"","url":"https://api.github.com/users/func-hs","html_url":"https://github.com/func-hs","followers_url":"https://api.github.com/users/func-hs/followers","following_url":"https://api.github.com/users/func-hs/following{/other_user}","gists_url":"https://api.github.com/users/func-hs/gists{/gist_id}","starred_url":"https://api.github.com/users/func-hs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/func-hs/subscriptions","organizations_url":"https://api.github.com/users/func-hs/orgs","repos_url":"https://api.github.com/users/func-hs/repos","events_url":"https://api.github.com/users/func-hs/events{/privacy}","received_events_url":"https://api.github.com/users/func-hs/received_events","type":"User","site_admin":false},"created_at":"2015-02-17T16:21:54Z","updated_at":"2015-02-17T16:21:54Z","body":"> カレンダーは実は MVC が密接に関連するアプリケーションの例ではないでしょうか？\r\n\r\nMVC を要することは確かです。しかし、カレンダーに関しては MVC そのものよりも、 CSS や  JavaScript といった、 **MVC に付随する**モジュールによって、カレンダー表全体を(あくまでユーザにとって)どこまでストレスを感じにくいデザイン&実装にできるのかの方が大事な気がしています。現行のものを見てみても、完成度は置いておいても Google カレンダーの使い心地を参考にしているように見えます。\r\n\r\n私は契約上、3月上旬で居なくなる予定ですが、 @master-q さんはこの後中国への出張が待っています。その出張先で現状の構成に対する評価や、そもそもこのまま使い続けるのかどうかすらわからない、もしかするとScalaもPlayも使わなくなるかもしれない、というのを考えると、今の内から環境構成を深く考え込んでいてもどうしようもない気がします。\r\n\r\n> あとはどのフレームワークを選定するにしても、カレンダーのような機能を作り込むにはその言語を使用可能でなければならない、という視点もあると思います。このような作り込みは今回の案件では少ないだろう、とみつもっていたのですが、いまの認証に関してさえScala+Playでは作り込みが必要になりました。\r\n\r\nおそらく、ログインの認証に関する API が標準でライブラリに組み込まれていて、そこそこストレスない感じに使えるようなものは PHP しかないでしょう。その PHP も、ライブラリこそ豊富なものの、型システムは脆弱で、当案件のように、数値をプロットするとか、そういう中のデータの形を統一したい部分では、ゴミが混ざってもそれを感知する手段に乏しいのが現状です。\r\nなので、ライブラリが豊富であり、かつ、型システムも必要十分程度にしっかりしているものとなると、次点では **Java** ということになります。今では Scala という静的型かつ Java よりも強力な言語機能を備えた onJVM な言語があり、おそらくこの先の事を考えると、これによらざるを得ない気がします。\r\nHaskell/yesod にするにしても、 Ruby/Rails にするにしても、コアが小さい言語での開発は追加で必要になるパッケージとの依存関係とも戦う必要が出てきますし、Haskell に至っては言語仕様を正確に把握・利用できる技術者がどれだけ要るのかも問題になってきます。\r\n\r\n> この学習曲線があと2.5週間後に追い付くのか、それとも追い付かないのか、は早めに知りたいのです。\r\n\r\n同意します。1ヶ月というごく短期間では私も必要十分に理解できるかどうかは怪しいです。しかし、途中から言語やフレームワークを変えると、その短期間でどうにか貯めこんできた知識を一度放して、新しい言語やフレームワークに対応するために、再度**早くても**1〜5日程度学習する時間を要してしまい、その分納期までの猶予が喪失してしまいます。もっと言うと、選びなおすことにも時間を取られるでしょう。当案件が今後まだまだ(少なくとも3ヶ月は)続くなら、選びなおしても間に合うと思いますが、現状では、この案件が未来でどう扱われていくのかが見えておらず、また納期にもほとんど余裕がないのでその都度納期の猶予がなくなっていきます…(´･_･`)\r\n\r\n*本音を言うと、私がこの1ヶ月より後に御社にどう扱われるのかが全く見えてこないので、私としては納期までに間に合うように動きたいのです XD*\r\n\r\nただし、もし @master-q さんが言語やフレームワークを総入れ替えして、この1ヶ月間ないし中国に渡ってからの1ヶ月間(もしかして、もっと長い？)の間に対応しきれるのであれば、私は追従します :)"}}