  |
はてなキーワード: サーブレットとは
職業訓練でプログラミングを習ってて今Java言語やってるけど授業についていくの大変。
目的があやふやなまま、就職の選択肢が増えればいいくらいの気持ちで始めたのが悪いんだけど。
ほんとは昔前少し習ったPHPをじっくり習いたかったけど、それを教える学校が通える範囲には無かった。
（昨今の職業訓練はオンライン開催してるとこもあるけど全体の１割くらいで内容がワード・エクセルコースとかPythonコースとかで希望とマッチせず、通学制度の学校を選択した）
面接でJavaやればPHPも理解しやすくなる、みたいに言われて入所決めたけどここをもう少し詰めれば良かったなと後悔してる。
Javaってちょっと前のAndroidアプリとかお硬い会社への就職のイメージだから、希望業種と合わない。
これからmysqlとサーブレットまで４ヶ月くらいで習うけど、どうなるか。
Javascriptもカリキュラムには含まれてるけど、Java習ってから習うと混乱しそうにならないかな。
前エンジニアらしき人のブコメでJavascriptの記述法がなんか気持ち悪いし慣れない、みたいなのを見た事ある。
JavascriptもPHP同様に前に少し習って面白い、これもっとやりたい！って思ったから
Java習ってる今気持ちが落ち込んでてこのままあの時の面白いもっと学びたいって気持ちが萎えてしまうんじゃないか、とか心配してる。
でも今頑張ってカリキュラム終わった後に、オンライン学習サービスでPHPやったら
厳しい意見いっぱいきそうで怖いな。
初めてプログラミングを学ぶことになったんだけど、正直全然理解が進まなくてしんどい。
・コーディングするのは初めて
・Javaではない言語だがバグ特定のためにデバッグすることはある
12月半ばから始めたオンラインの動画講座で、初歩的なところから初めてMySQLとかJSP/サーブレットを使って簡単なWEBアプリを作るところをやっている。
解答というか、書かれたコードをみるとなるほどそうやってやればいいのねと思うものの、いざ自分で書こうとすると手が動かない。複合的になるにつれ、こことここで学んだ書き方で書けばいいというのがわからなくなっていくというか…
書き方については見返したりしながら進めているので知識は頭に入っているはずなのに、部分的に？理解していて頭の中で繋がっていないのか。
始めて1ヶ月もたってないので、そんなすぐは書けるようにはならんだろと思うものの、自分で書けなくて結局分からなくて解答見てしまうのが悔しい。でも解答見なかったら先に進めないんだよな。
プログラミング学んでる人、こういう書き方をすればいいんだなってどうやったら思いつくの？経験？
※向いてないというコメントはなしで。趣味ではなく必要なのでやっていて、嫌いになるとモチベが上がらないのでできるだけ前向きにいきたい。
昔数学を始めた時にxとyが出てきて、二次関数くらいから全然解けなくて泣いた時の気持ちに近い。今となってはなんでそこにつまづいてたのかもわからないけど。
最近はGoが流行っているが、それならJavaだって同様に良さそうな気がする。
- nullがたまにうざい
- なんか重厚な感じがする
- ORMとかが重厚なのが多かった
- 故に環境構築が大変だった
- strutsがしんどかった
- xml地獄からアノテーション化したりいろいろと模索していた
- ちょっと昔には「俺たちイケてるプログラマ」はみんなRailsに移っていった流れがあった？
- Effective Javaよいが、そもそもそういうtips意識せずにそう書けるような言語仕様になってほしかった気もする
- 非同期処理やスレッド処理がやや難しかったか、あるいは言語側でのサポートが薄かったか(?)
言語仕様的な批判と、エコシステム的な批判に分けられそうなきがするな。
関数型言語の関心はScalaやClojureに全フリしてもらって、Javaはシンプルな機能を持つGoの方向性なModan Javaになっていってくれれば良さそうな気も。
httpサーブレットとかそのへんが微妙だったかもしかして。Goみたいにnet/httpライブラリが標準であればそれをベースにすることでオレオレフレームワークの乱立を避けることができるか、と思ったけどJAX-RSとかがあるな。
Goだって冗長な記述が必要な言語だが、好かれているし、Javaも悪くない言語な気がするんだよな。
まあ何でもいいが。
ロジカルに考えているようで結局なところ雰囲気的なところに左右されているエンジニア多い気がする。
まあわいも、人気な言語に乗っておいて高単価を得られたほうがいいのでそうするが。今の所Goが肌にあっているんだよな・・。3年ぐらい使って熟練度上がってきたし、さほど悩まずにコーディングすることができる。
PHPの人が好きな、あるいはRubyのmethod_missingなど活かしたテクいコードは、書いているやつは気持ちいいかもしれないがわいは明示的にinterfaceがわかるコードが書かれていたほうが好きだ。型で振る舞いがわかったり制御されていないと分かりづらくない？複数のプロジェクトを掛け持ちするから、読むときに前提知識が少なく読めるコードがいい。
まあJavaもリフレクションでテクいことができる気がするな。
Goがいい。誰が書いてもだいたい同じコードになるから、誰かに作業を振ったとしてもレビューしやすい。
まあこれからJavaを書く気はしないが、GoでAPI書いているマンから見ると、JAX-RSとかでゴリゴリAPI書いていくの全然悪くないんじゃないかと思うのであった。
最悪別にGeneric入らなくてもいいかもな。別にそんなに困ってない。はいってくれるなら、はいってくれたほうがいいが。sliceに対してmap, each, filter, existsなどのメソッドが生えることになるイメージかな。まあそれは欲しくなるけどな・・・。
Scalaもいいんだが、たまにイキったコードを書くと分かりづらくなる時がある。イケてるコードを書こうと思ったとき、結構パワーを使う言語だ。なんかモナドってジェネリックを更に強くしたやつだとも捉えられるような気がするな。ゴリゴリ関数型で書こうと思った場合、プロジェクト全体に影響がある話なのでアーキテクチャ設計に力がいる気がする。
年をとると大事にするポイントが変わってくるな。昔はスーパープログラマになりたくて関数型言語とかやっていたが、今はいかに効率よく仕事をする＝金を稼ぎ自由を得るかを重視している。職業プログラマとなったわけだ。仕様固めたりリリースしたり不具合対応したり運用したり、フリーランスなら税金計算したり、金儲けの方法考えたり忙しいんじゃ。今は結局スーパープログラマとは何か悩ましいよ。「プログラマとして」キチガイレベルにすごい人間というのはまだ見たことがないかもしれない。コーディングが早い？バグ修正が早い？パフォーマンスのやばいコードを書ける？設計が優れている？
あの発表の場にいたわけだけど、感想はよくわからないポエムな理由だ、でした。
今日の彼の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に向いてない）
普段Androidがクソ端末でiPhoneは良端末みたいな風潮が我慢ならないのでiPhoneも同じクソ端末である理由書いとく。
これは、Appleはシンプルさを保つため云々みたいなこと抜かすが、そんなことはない。
むしろアプリ側にそのメニューや戻るをどう実装するかを任せており、各アプリが思い思いな方法で実現しているので、UXとしては最悪だ。
例えば、→にフリックで前に戻るとか、↑にフリックでメニューが出てくるとか、そういうの。
デフォルトのブラウザ、Safariでさえブラウザバックしたいんだけど戻るボタン出すのに苦労する。死ねばいいのに。
よくある手法として、アプリ上部にバーを設けて、左側に戻る、右側にメニューボタンをつけるヤツ。
もう、ほんと死ねばいいのに。届かねーんだよ。指が。
おかげでツルッと滑って落して割れた。マジクソ。
片手操作する人も多いと思うんだけど、こういう実装するヤツ、そういう人のこと考えてないよね。
戻るボタンがあるということは、ベースの戻る機能を利用する方法が保証されているということ。
さらにそのボタンをホームボタンと同じようなとこにつけておけば、操作もしやすい。
まずその機能が保証された上で、さらに上記のようなアーティスティックな方法でも操作できますよ、が優れた手法だと思う。
これは例外はあって、Apple が認めたアプリであれば、GameCenterとかと連携はできる。
ただ、それ以外のもの、例えばはてブと連携したいとか、Evernote と連携したいとか、そういうのができない。
Safari でネットサーフィンしてて、「あ、これはてブに追加しときたい」っての、できない。
サーブレット使えば行けるけど、そんなニッチなことせずに連携させろよ、と思う。
逆に、はてブアプリからSafariで開きたいとか、Twitterで開きたいとか、そんなこともできない。
個々のアプリとしてはiPhoneアプリは素晴らしいが、どうしてもそれだけじゃ足りないものを補わせる機能はない。
独自プロトコルとかに関してはそのアプリしか使えないから却下。ユーザーが使いたいアプリで開かせろ。
確かに最大64GBあれば一般的には問題ないだろう。
重要なデータは個人で保有し、必要な場合に付け替えできるようにするべきだ。
15分おきにフェッチとかありえないだろ。
社内向けのポータルサイトが数年前から稼働しているのだけれども、これが酷いできでソースを見るだけで頭が痛くなる。（サーブレットだよ）
staticおじさんプログラミングのすべてがそこに詰まっているデザイン、かつクラスをコピペして機能拡張をするというまあ良く有りがちな糞コードアプリだ。
まあ、そりゃいいけれど
なんかバージョンアップしようとすると、変なオッサンが自分がデザインして稼働させたシステムを変更させたくない圧力をかけてくる。
なんか、これが自慢のシステムらしい。
HTMLは古い書き方なのは仕方ないにしても、内部のJavaソースがより酷くて
アクセスカウンターのような仕組みがあるんだけれども、アクセス数はアクセスがあったときにたされるのだけれども
その数字をJSPに渡す時に、なぜかint[6] の配列で返してくる。
お尻が切れて表示されるというアクセス数が全くわからないシステムになっている。
ついでに不必要なスレッド処理があるのだけれども、同期処理が不十分で、何回かに一回例外が発生する…
じゃあ、最後までお前が面倒見ろと…
まあやってくれないだろうから、外見からは分からないようにこっそりバグは治しているけれど
なんか馬鹿らしい。
まあ、社内向けだし…
今日プロジェクトの打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQLの魔女と呼ばれていた。
今から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSEの仕事内容、特にWebのアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。
初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。
与えられた課題を終えるごとに、コードを提出するのだが、見たよ〜出来てると思う、頑張ったね〜と言われた後で、そのプロジェクトを下敷きに発展課題に足を進めたら、でっかいバグがあったり。
万事その調子で、今やってる課題放り出して、プロジェクトオイラーの問題でも解いてた方がよっぽど楽しいなぁと若干サボりたいと思い始めた頃、炎上プロジェクトへ先輩と二人テスターとして出向するよう、上司から命じられた。炎上プロジェクトのリーダーから手待ち要員いない？と声がお上に届き、降りて来た結果先輩と自分がいたわけだ。
前の事業部ではずっと同じ客先にいたわけで、頭では分かっていても鼻先三寸で飛ばされることには不安がつきまとった。
「これから行く先はどうなんでしょうね？」
先輩へ問うと、
「基盤にいたんでしょ。メインフレームが扱えるなら大丈夫だよ〜」
豆腐すらぷるぷる震えそうな声が返ってきた。
この時の私は、まだ事業部を転属して間もなかったし、プライドばかり高くて奢ってたように思う。事業部を変える→入社して以来の経験値がまた0に、と失うことに対する不満ばかりで、それが拗れて数少ない基盤系経験アプリ開発者、そんな肩書きばかりを強調する変人に成り果てていた。自己紹介で、どうも、基盤から参りましたと、そこだけは大きい声が、今思い出したけどマジで恥ずかしい。
だから、だろう。このゆるふわな先輩とドナドナされることに密かに感じていた屈辱には、出向いた先で押された駄目テスターという烙印によって罰があたることになった。
その理由は、私がSQLを全く使えなかったことにある。テスターとして行うことになったのは表示画面の統合テストで、UIの検索結果とデータベースに直接SQLを打ち込んで得たレスポンスを目で確認していく作業だった。UIは、境界値さえ気をつけて、仕様通りに実施すれば何とかなる。しかし、SQLで再現が出来ない。この仕様はどうやったらコマンドに落とし込めるんだよ。頭を抱える中で思い出したことがあった。
教育過程でJavaサーブレットを学んだが、その一つにJDBCも勿論習った。そこで私は何をしたか？mysqlに繋げればそれでいいやと、エグゼキュートで実行する際に渡す魔法の文字列……つまりSQLの中身は、すべてコピペで済ませていたのだ。社内教育資料を内部作成するにあたり参考にしたと思われるネットから……構文チェック効かないし、ここは手を抜いてもいいだろう、これが要領の良さというものさ……アホーアホー私のアホー。
三日目の午後二時、進捗を確認しに来たPMにすべてを告白すると、ちょっと来てとPMが連れ出したのがあの先輩の席だった。
「申し訳ないけど今やってるテストは止めて、これから定時いっぱい最低限テストが出来るように彼にSQLを教えてやってくれ。」
良いのですか？と顔をあげるとPMは何を勘違いしたのか、やにわに私の肩を叩くと、
「彼女はSQLの魔女と呼ばれている。半日でお前も即戦力だよ。」
と去っていった。顔を先輩へ戻すと、あのPMさんは嘘つきだから信じないほうがいいよといつものふわふわした声でにっこり。
宜しくお願いします。ノートパソコンを横に私は型通りの挨拶。四時間後、私は傲慢さを、尻の毛まで抜かれることになる。
私はSQLの深さを知った。SQLのQとは何だ？Queryであります、サー!!今も時々夢問答を繰り返す。そう、全ては問い合わせ次第なのだ。今思えば、あの時やったことはT2テストを使ったSQL文の作成と添削、しかもSELECTによる条件抽出のみだったが、そこに全てが詰まっていた。
DISTINCTとORDER BYの共存で詰まってわけがわからなくなったコードは、もっとシンプルにいけるよと副問い合わせに書き換えられて。ネストとワイルドカードを多用してスパゲティになったコードを、先輩はLEFT JOINとWHEREとORで全てをすませた。
なんということでしょう。マニキュアが塗ってある長い爪からは想像もつかない早さで直されていく構文に脳内で途中から匠の曲が流れ始めたのを覚えている。本当に、なんということでしょう。先輩はSQLの魔女だった。
翌日、先輩の教えはしっかり自分に身に付いていた。すらすら書けるSQL、サクサク進むT2テスト。条件設定に悩んで、エクセルに吐き出してからリストとコピペで逐一加工してた時間が馬鹿みたいだった。先輩のところへ、帰りしなに昨日のお礼と作業進捗に激震が走ったことを伝えると別にお礼なんていいよーといつものふわふわした顔で微笑んでくれた。
それから先、配属先が決まるまでの条件付きでテスターとして入っていたはずだったが、T2試験が終わり、T3試験が始まってもなぜか私はそのプロジェクトにいたままだった。DB担当者として。もともと基盤だったわけだし、バッチファイル処理でスクリプトがそこそこ書けたというのもあるけど、SQLが書けたというのはすごく大きい。昼休み、いつのまにか私はプロジェクトオイラーの問題に代わって、名著「SQLパズル」を解くのを日課としていた。
先輩は仲良くなる暇もなく、その後すぐにプロジェクトを移り、メーリングリストで寿退社を知った。炎上したプロジェクトは、なぜか横展開を経て今に至り、私は相変わらずここにいる。だが、あの時SQLの魔女がかけた呪いは今もしっかり私に根付いている。
