株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。
業務多忙により更新が止まってしまっていましたが、再び復活して連載します。
前回まではAndroidStudioの検証を行っていましたが、業務都合により今回からテーマを変更。
テーマはWebフレームワークの「PlayFramwork」です。
昔を振り返る
PlayFramworkは、まあ単なるJavaのWebフレームワークですね。別にそれほど特別なものではなくて、あくまで標準的に使用されるべきフレームワークの一つと言えるでしょう。
- Struts1
- Spring
- Seasar2(SAStruts)
これら有名JavaWebフレームワークの同族です。
私は自分をJavaWebプログラマーとしては極めて平凡な道を歩んできたと思います。
Struts1で社会人入り、Springで炎上し、Seasar2で快適生活……。
上記に挙げたフレームワークはJavaWebフレームワークの首領達であり、これを知らずしてJavaWebの歴史は語れません。
しかし、あの頃から時代も流れ、現在はこんな状況……。
- Struts1 ⇒ サポート終了
- Spring ⇒ 炎上プロジェクトの代名詞
- Seasar2(SAStruts) ⇒ サポート終了
何と、必殺のキラーコンテンツだった「Struts1」「Seasar2」がサポート終了を迎えてしまいました。
Struts1は言わばJava全体のキラーコンテンツのようなものであり、何故今の時代にJavaがこれだけ普及しているかと言うと、それはStruts1があったから。
「スーパーマリオブラザーズが人気だったおかげでファミコンが普及した」と言っていいくらいの勢いでJavaの普及に貢献した伝説的フレームワークでした。
しかしサポートが終了してからセキュリティ脆弱性などが見つかってもう使えるシロモノではありません。（まあ、ごり押しで使ってるトンデモ現場もありま……ゲホゲホ）
Seasar2(SAStruts)は、日本製フレームワーク。
日本を代表するプログラマーひがやすを氏によるフレームワークで、これも日本人なら知らぬ者無し。
しかしSeasar2のWeb部分であるSAStrutsって内部ではStruts1を使っているそうじゃないですか。
Struts1サポート終了してからも随分と延命して下さいましたが、そろそろ限界の模様。
ひがやすを氏ご本人が卒業を勧告しておりますから、全人類はこれに従ってSeasar2の時代を終焉させるべきですね。
そしてSpringは……、申し訳ありませんね。
Spring自体は良く出来たものなはずなのですが、どういうワケか私の人生では１００％炎上しているのですよ。
Springは大規模プロジェクトに導入されることが多い為か、フル活用する為には熟練した知識が必要な為か……。
ともかく、何か呪われているような印象がありまして、実際やっぱり色々と難しい部分もあって、小規模プロジェクトに気軽に導入するようなものじゃないと思いますよ。
同じ意見の人も少なくないと思います。なので最近は採用率が下がり気味な印象……。
以上のように、かつて一斉を風靡していたJavaWebフレームワーク達はその役割を終えて新しい時代が到来してきているのが昨今のJavaWeb業界です。
では、これら伝説のフレームワークに続く新時代のフレームワークは……、ありません！！
そう、JavaWebフレームワークは群雄割拠の時代。
問答無用の最強フレームワークが無いご時世なのです。
何で無いんだろう……。
色々あるでしょうが、私としては以下のような持論を持っています。
JavaでWebシステムを作る必要性が無くなった。
そもそもコレ。PHPやRubyなど色々な言語が普及してノウハウも蓄積してきた昨今、Javaに拘る理由が無くなってきているんですね。
現在私が参画しているシステムは業務用でバッチ出力などもあるから全言語をJavaで統一して気合い入れて作る話になっているものの、そうでもないちょっとしたWebサイト開発だったらスクリプト言語ベースの方が小回りが効いて良いですもんね。
実装の必要が無くなった。
最近はパッケージやクラウドサービスも普及してきましたからね～。
「Salesforce」などが代表格ですが、自社用業務アプリを自社開発するより、既に存在するサービスに使用料を払って使った方が機能もコストパフォーマンスも優れていることも多いです。
必然的にJavaで必死に実装するシチュエーションも減ってきました。
悲しいですが、私みたいなプログラマーの出番があるということは、それはその業務が洗練されていないだけであり、本来はパッケージ製品で業務出来るように運用を見直すのが真の理想、というのが真実の姿かと……。
スマホ対応
最近はスマホが普及してきたのでWebシステムの需要もスマホに盗られ……、たわけではありません。
スマホが通信している先はサーバであり、そのサーバでは気合い入れてJavaが動いています。
問題はですね、スマホ、タブレット、ＰＣなど色々な端末に対応する為には「JSONでデータをやりとりするWebAPIである」のがベストってことなんです。
WebAPIとて所詮はHTTP通信するWebシステムってことに代わりはありませんからWebシステムと言えばWebシステムです。
しかし、かつてのようなＰＣ向け画面を作っていた頃のWebシステムと、JSON文字列をストリームで送り返すだけのWebAPIではやっぱり根底が違いますよ。
jspが無いことを始めとして、インターフェース部分が全然違いますからね。
Webフレームワークってのは「画面フォームから受けたパラメータをどうやって受け取るか」ってのがデザインの見せ所なんです。
でもWebAPIって基本、クエリがチョロって来るだけじゃないですか？
気合い入れてWebフレームワークを導入する話じゃないっていうか……。
私だったら自前でそのWebAPIに特化したフレームワークを作るでしょうね。
高機能なWebフレームワークの極一部だけ拝借するよりも、自前で作った方がずっと高速でスリムなシステムを作れるでしょうから。
なのでスマホ用サイト構築の場合は、Webサイトだったら別言語で作り、WebAPIだったらフレームワーク無しでＯＫ、とJavaWebフレームワークの出番が来ない。
まとめますと、最近は技術やノウハウが蓄積されて昔みたいなStruts単細胞野郎が淘汰され、ケースバイケースで色々な言語、製品、フレームワークを選択するようになった結果、「これさえあれば最強！！」みたいな単純な時代では無くなったというのが私の所感です。
何故PlayFramworkか？
このような選択肢の多い群雄割拠のこの時代、では何故、今回私がPlayFramworkを採用することを思い立ったのか……。
もちろんこれには理由がありますが、一番のポイントは、
- Ruby On Railsのフォロアーであること
これですね。
この辺り、フレームワーク採用の評価ポイントについては、次回に続きます。
終わりに
フレームワークはただ効率良く使えれば良いというものではなく、何故それが他と比べて優れているかを他者に説明出来る必要があるのだ。
PlayFramwork編は長期連載になると思いますが、末永く宜しくお願いします。
0 件のコメント:
コメントを投稿