  |
はてなキーワード: JavaEEとは
単体テストというのは、画面を手動で操作してスクリーンショットを撮る仕事だった。エクセルで仕様書を書き、レビューをしていたが、レビューアーはテストケースよりも、枠線の整え方に気を配っていた。
誰かが自動テストを導入しようと言い出した。「再現性がある」「保守性が高まる」「もっと良くなる」と口々に言われていた。
でも、テストコードを開発する工数はどうするのか、開発コードが増えればさらに大変になるのではないかと不安があった。
それでも、これが実現すれば、何かが大きく変わる予感がした。
アプリケーションフレームワークはStrutsだった。フォームをポストする瞬間にカオスが生じ、50行の無駄なコードを書き、100行の読みにくいコードを理解することが技術者の条件だった。
ある人が「レイヤリング」という概念を持ち出し、別の誰かが「DI」と言い出した。アプリケーションアーキテクチャという言葉も登場し、ファウラーという人物の名前も聞こえるようになった。
新しい構造が提案され、それに影響を受けながら、「いつかは美しいアプリケーション構造が生まれるのかもしれない」と夢を抱いていた。
当時、PerlでCGIを作っていたが、PHPやRubyが登場した時は、正直Web"サイト"を作るためのものだと侮っていた。
しかし、次々と洗練されたWebアプリケーションフレームワークが生まれ、StrutsやJavaEEよりもはるかに使いやすくなっていった。
数多くのWebフレームワークの中で、どれを選ぶべきか悩みながら、「いつか完璧なWebフレームワークが現れるかもしれない」と期待していた。
サーバーは冗長化され、ReversProxyを使い、セキュリティのために構成を変更してきた。そしてクラウドが登場し、Dockerなんて本番で使えないと言っていた時代から、
気がつけばどこに存在するのかもわからないクラスターの中で、コンテナアプリが動いている時代になった痛快だ。
かつてLinuxマシン一台を「鯖」と呼んでいた時代から、世界は目まぐるしく変化し続けるとかと思っていた。
誰かがAjaxと言い出し、別の誰かがReactと言い出した。「こんな方法でHTMLを作って良いのだろうか？」と疑問に思いつつも、「Webはアプリケーションだ」という感覚が強まっていた。Webアプリケーションがどう進化していくのか、未来を感じることができた
私たちは、ソフトウェアを開発すること自体に大変さを感じていた。新しい技術やフレームワークが次々と登場し、その都度課題が解決される一方で、新たな課題が生まれる。これほど面白いことはなかった。そしてエンジニアたちには一体感があり、誰もが自分なりの方法で課題を解決し、そのフィードバックループが世界を動かしていた。だからこそ、今は少しつまらない。変化は穏やかになり、「お金を稼ぐ」という目標だけが共通となり、課題は個々の事象に閉じ込められている。しかし、それが悪いことではない。ただ、私たちの時代が変わったのだ。
かつては、私たちの目の前には普遍的な課題があり、それぞれがそれぞれの場所で課題を解決し、そのフィードバックループが世界を動かしていた。
生成AIで例えると、それをどう使うかではなく、エンジニアが一丸となって生成AIをチューニングしていた。世界情勢で例えると、世の中の飢餓を全世界の人がアイディア出して、解決しようとしてたいた。
今でも、普遍的な課題は世界中に転がっているが、それらは高度で、私たちには手が届かないものが増えてしまった。
ITは面白かった。プログラミングが分かるだけで、世界の課題を一緒に解決できる時代だった。それぞれが自分の場所で働くだけで、世界を動かしていた。そんな時代が終わってしまったと感じる。
老害といえば昔話だろ！
・機械工学は大学で学んだ。機械系４力学のさわりだけなら大体やったがもう忘れている。
・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ３Dプリンタでなんでも作れるらしいが、３Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定１級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった＆謎のSegmentation Faultで苦手意識を残したまま。Go？Rust？なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。１から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript？なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
AzureIOTについて自社で関わることになって、自分はJavaEEと化石時代のAndroid(Linux Kernel 側w)しか経験ないし、
とりあえず下記のような青写真を作ってGW遊ぶかーと色々調べてた。
Android Architecture Componentsを使用したkotlin仕様のAndroidクソUIアプリ --MQTT(HTTPよりかっこよさそうなプロトコルと名前だけ覚えていた)--AzureIOT。
とりあえず肝はMQTTっしょということで、これも名前だけ覚えていた時雨堂さんの名前を元に[色々親切だったと思うsangoサイト](https://sango.shiguredo.jp/mqtt)にアクセスしても繋がらない。
え、なんでやと思ったら[去年サービス終了してた...](https://medium.com/shiguredo/mqtt-%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%E6%8F%90%E4%BE%9B%E7%B5%82%E4%BA%86%E3%81%AE%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B-c615ab484110)
役目を十分終えた、か。サービスインからアウトまでたったの3年...自分が名前を知ったのもこのサイトだったはずだけど、早すぎたんやな。はやー。
[こっちはまだ残ってるけど](http://akane.shiguredo.jp/mqtt.html)
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support
「ローカルに仮想環境たてて開発するとマシンスペック足りない人いるから
みんなで一緒の開発環境上で開発しようね。
→ アホですか？
「Gitは使い方難しくて工数増えちゃうからSVNでソース管理しようね。
ソース触るときは他に開発中の人いないかチャットで確認してね。」
→ アホですか？
あとで検証環境と本番環境でも同じ手順で構築するからコマンドまで細かく書いてね？
chef?ansible? itamae? 自動化するとミスがあったときにハマっちゃうからね。
手動が確実だよ。」
→ アホですか?
「Java8?使ったことないから不安だね。今回はJava7で行こうか。実績あるから安心だね」
→ アホですか?
「JavaEE?使ったことないから不安だね。今回は大規模案件だから使いなれたJavaSEにしよう。
→ アホですか?
「設計書書くときは知識がない人がみてもわかるように書こうね。
もちろんExcelで書いてね。更新するときは更新履歴シートに更新内容書いてね。
ファイル名は日付をちゃんと書くこと。更新したらチャットで報告してね。」
→ アホですか?
こんな会社は僕のとこだけだよね？
あの発表の場にいたわけだけど、感想はよくわからないポエムな理由だ、でした。
今日の彼のSeasar2打ち切り宣言ブログ記事も読んだがやっぱりポエムだった。
あの発想は正直私にはよくわからないです。飽きたなら飽きたと言えばいいのに。
つうか、開発を打ち切ったあの時に言えばよかったんじゃないですかね。
かっこいいのかもしれませんが半分言い訳が入っているようにも思えます。
あのフレームワークには大変お世話になっているので、
とりあえずは本当にありがとうございます。
ま、でもすぐは消えないでしょ。この国ガラパゴスだし。
そもそも日本はまだStruts1.2.9ガチで新規開発に使ってるSIerがいたりするくらいだし。
来年で打ち切られたとして、確かに今後新規開発に使う人はほぼいなくなるだろうけど、
それでも5年いや10年以上既存アプリのメンテとかで普通に使ってるでしょ。どうせ。
フレームワークのフの字もない時代に作られたサーブレットだけで書かれた昔のゴミアプリを書き換えたいと
5年以上主張してても顧客から改修費用もらえない（後そこにリソース取れない）
という理由で書き換えられない人も世の中にはいるわけですよ（私だけど）。
もちろん最終的にはSeasarが緩やかに消えていくのは確かだろうけど皆さんが思ってるほど早くはないんじゃないですかね。
で、とりあえず今うちの会社は現在（かなり）Seasarの資産を使って作ったアプリが稼働中なので
いきなり移行する気もないわけです（つかそんなリソースない）
そもそも確かにメーリングリスト見て参考にしたところは多少あるけど、
サポート打ち切られたからってああそうですかでしかないとも言う。
どうせ何かあったら最初からこっちでメンテするしかないんですよ。
ぶっちゃけ今もそうですし結局当面はなんも変わらないわけです。
（あ、でもメーリングリストのバックアップは消えないうちに全部取っておこうかな）
フリーの環境を使わせていただくというのは究極的にはそういうことなんだと思っています。
それは多分Springに移行してもそう変わらない（最新の機能は随時提供されるだろうけど）
とは言え、新規に今後Seasar2を使うのがためらわれる状態なのは確かなので、
今後の新規開発案件では多分Springに移行することになるでしょう。
当日SpringBootのセッションも聞いたので日曜さらっと動かしてみてます。（ほんとにさらっとですが）
ひと月も触ってみればある程度Seasar2と変わらない程度で代替としては使えそうだとは感じてます。
バージョン2.4くらいの時に少しSpring触っていまいちとっつけずに捨てていたけど、
当時から見て大分とっつきやすくなってるんだなとは思いましたね。
（未だにSeasar使ってる化石人間の私としては今のSpringならPlayよりとっつきやすそう。JavaEEは論外）
でも正直あれがSeasar2より優れているのかと言うとぶっちゃけよくわからないけれども。
せめてDB周りがS2JDBCくらい使いやすければなー。来週HibernateやDBFluteの連携を試しますかね。
せっかく（外的要因とはいえ）変えるのだからよりやりやすい方法を探したいですね。
ま、もう少し研究して1か月くらいしたら新規案件はこっちでやるめどがつくかもですね。
（既存を移行するかはわからない（受託開発は移行を提案しても金がもらえないと…））
とりあえず、
１、5～10年計画で徐々にSeasar2フェードアウトするとは思うけど、完全卒業は多分しない（苦笑）
２、とりあえず、新規の開発はSpringで今後やるけど既存のアプリをどうするかは目途つけてない。変更のないアプリとかそのままずっと動き続ける可能性大（大苦笑）
３、ほどほど主義なもんであの人たちほどの成長意欲はない。流れのままのんびり生きていきたいっす。（SEに向いてない）
Re: http://anond.hatelabo.jp/20070304154248
