【読書感想】オライリー本 オブジェクト指向分析設計 １章
・例題として出されたコードを見て頭を抱えたのは初めてだ。なんだこのクソコード！（驚愕）
・読んどいて損はないってことで読んでたけれども、意外と自分が直感的にオブジェクト指向的な考え方ができてたのを確認できた。
・↑そのせいかちょっと初歩的すぎるなあという感想を抱いた。まだ一章の段階だからかもしれないけれど。
・GuitarSpecをカプセル化して検索パラメータに使うことについてはちょっと疑問。たしかに柔軟性は上がるし素晴らしい設計だとは思うけれど、検索パラメータとGuitarSpecは別のオブジェクトとして扱う方が直感的な理解がしやすいじゃないんだろうか。
・↑リーダブルコード的な考え方が自分の中で重要視されてるのかもしれない。
・↑と言っても、より優れたアーキテクトだと柔軟性と可読性の両立も可能な気がするので、結局は自分の知識もまだまだなのだろうなあと感じた。
・本章を読んだ上での感想とはちょっとズレるのかもしれないけれど、可読性と柔軟性の両立について考えるいい切っ掛けになったのだと思う。
・スーパーハカーの皆さんに「情弱乙」って言われそうな感想だなコレ。
転職活動してて気づいたこと
主に転職サイトについて色々と感じたこと。参考にはならないと思う。
○リクナビNEXTについて
・やっぱ掲載費かかるだけあってある程度儲かってる企業が出してる感じ。
・転職アドバイザーがハイエナかお前らって勢いでオファーかけてくる。
・リクナビ側としてはやっぱバシバシエントリーかけて欲しいのか無駄にアホみたいな量のエントリー催促してくる。うるさい。
・おそらくは裁量労働制である企業のいくつかにその旨が提示されていなかったりする。大体のIT企業は暗にそうなんだろうけどそれでもこの辺は面談とかで聞いとかないといけない気がした。
・技術要件の提示がすっごく微妙なところが多い。人事と開発の必要とする人材の齟齬が発生してんのかな？
・でもなんだかんだでやっぱ一番使いやすいサイト。
○Greenについて
・ちくしょう転職だのアレ
・Green側で用意してる質問事項の中に「最近注目している技術は？」みたいな項目があるのか、ここでエントリーした企業には全て聞かれた。
・「数日後に連絡します」と連絡がきた企業の一部から連絡がまだ来てない。いやこれは転職サイトのせいではないんだけど、そういう体制を取る企業が何社かあるかもしんない。せめてお祈りしてよ。
・Java経験なしなのにJavaが必須項目の企業から何社か「気になる」通知がきた。おいおい。Javascriptと見間違えたんちゃうか？
・パッと見企業文化がゆるいところが多い。僕みたいにゆるゆる文化好みの人間としてはオイシイかもしんない。
○Geeklyについて
・アドバイザー様。
・おすすめ求人のおすすめ基準がマジで不明。だからJava未経験つってんだろ。
・深夜問わずガンガン連絡かけてきてくれるので、担当の人大丈夫かよって思った。求人系の仕事は間違いなく激務だなあ。
○結局は
・一緒に働ける人が楽しいかどうか、尊敬できる人材がいるかで八割がた決まるので、求人サイトの情報とか面談とかじゃあ全然わからんよね。一種の運試し。
・人生なんざ麻雀みたいなもんで、結局はその運を掴む確率をあげる努力しかできんのだ。受かるも運、落ちるも運。
懐古ゲーマーと名作ゲーム
センジュくんとUstでゲームについて色々と話して思ったことをまとめてみる。
Ustのアーカイブ配信はようわからんのでURLは生貼り。
僕もセンジュくんもいわゆる懐古ゲーマーと呼ばれる類の人種で、かつてやったゲームに大してアレは良かったこのシステムは素晴らしかったと語り合うことが多いのだが、しかしこれは真にゲームを楽しむ人＝ゲーマーとしては正しい楽しみ方なのであろうかという疑問が喋っている間に生まれた。
僕たち二人のあいだの共通認識として、ゲームとは「適切な課題設置」を行う製作者と、「課題解決」を行うプレイヤーの意思疎通を行うツールであり、ゲームを楽しむという行為は、いかに課題を解決するか？課題を解決するためのリスクとリターンをどう釣り合わせるか？を思考することが本質であるという結論が出ている。
しかし一度プレイした名作ゲームをもう一度プレイすることは、この定義には当てはまらない。何故なら、一度プレイしたゲームは、既に解き終えた問題集を再度行うがごとき行為であり、ゲームの本質である課題解決が行われない、もしくは、過去の経験から課題の解法をカンニングし、それをなぞるように手順をクリアしていく行為であるからだ。
しかし僕たちはその行為に一種の快感を覚えている。
記憶というものは完全ではない。故に、完全に課題の解法をなぞっているわけではない。しかし、例えば「この敵には炎属性の攻撃が効く」などの断片的な情報はいつまでも残っているもので、現に僕自身過去やったゲームをプレイしていて、断片的な攻略情報から解放を容易に導き出すような経験を何度もしてきた。
見えないパズルピースを記憶から可視化し、それをつなぎ合わせていくことにゲーム的快感を覚えるのだろうか。否、それは違うと思う。課題解決はパズルピースを集めていくことから始まる。故に、既に揃ったパズルピースをつなぎ合わせる行為は、課題解決とはならないのである。（ここは諸氏意見あると思うけど、少なくとも僕はそう思っている）
ここから推論するに、おそらく、僕たちが得ている快感というものは、ゲーム的な快感ではない。課題解決に対する快楽ではなく、自らの記憶をたどっていく、まるでアルバムを見ながら自分の中の思い出を掘り返していくような、いわば一種の自己肯定の儀式、そして、それに伴う一種の安心を快感と勘違いしているだけなのではないだろうか。
もちろんそれを否定するつもりはない。ただ、それをゲーム的な快感と誤解したままゲームをやり続けていくと、自分がゲームに求めるものが何なのかを確定せぬままに新たにゲームを選び、そしてやるんじゃなかったこんなクソゲー、と、的はずれな感想を抱いたままにそのゲームを「完結」させるのである。
それは不幸でしかない。プレイヤーにとっても、製作者にとっても。
故に、僕たちがゲーマーとして有り続けるためには、自分がゲームの何に快感を感じているのかを常に頭の片隅に置きながらゲームをプレイし続ける必要があるのだろう。
何ゲームにマジになっちゃってんのという指摘が聞こえてくるようだが気にしない。
暴論なので異論は認めます。っていうか認めまくります。
個人でシステムを作ってみて思ったこと
技術の勉強って結局は学ぶという姿勢が整ってないと何も身につかなくて、なおかつ学ぶという姿勢はどのように育まれるかというと、結局「いざ使用するとき」「壁にぶちあたったとき」にならん限りは八割がた生まれんという持論を振りかざして生きてきました。
故にってわけではないですけれど、いろいろと技術を勉強するにあたって、技術系のサイトやら勉強系のサイトやら見るよりもまず自分でその瞬間を作ってみようということで、自分でシステムをちまちま組んでました。
ウィザードリィとかキャラメイク系のゲームあるじゃないですか。アレに似た関係で、アトラスの「世界樹の迷宮」シリーズのキャラメイク管理用のシステムを作ってみました。
認証は独自実装のためMembershipProvider使わず。荒らそうと思えばいくらでも荒らせる作りになっててアレなんですけどまあ使う人なんて身内くらいしかいないかなということで気にせず実装。
そんでもってようやくタイトルに沿った内容に入ります。以下箇条書き
・設計大事。超大事。
当たり前すぎるけれども実際に自分で1から全部組んでみて実感した。
いやもうほんと設計九割なんじゃないかってレベルで大事。仕様とも言うべきものは自分の頭の中にあって全部書き出したつもりだったんだけれども、いざ実装段階になると、一つ一つの機能としては問題なくとも連携すると大変なことになるとか多かった。特にViewModelの設計。
想像力が欠如していると言えばそれまでなんだけれども、でも実際にやってみないとどうにもわからないことが多すぎた。結局はSession変数に頼りまくるRestとは程遠い形となってしまいました。
この辺は経験で補うしかないのか。と、思ってますが、勉強することで少しはマシになるものがあればそれを学んでみたいとも考えてます。何について学べばいいだろ。ドメイン駆動？
・MVCのあり方について
MVCフレームワークに始めて触れたのが前職だったのですが、MVCのなんたるやの概要をほぼ学ばず実装から始めたので、イマイチな独自MVCフレームワークを自分で作って実装しました。
色々と意識できてないところはあるんだけども、一番意識できてなかったのは下位層は上位層を知っていてはならないというところ。（レイヤーアーキテクチャだっけ？）
ControllerはControllerという層、ViewはViewという層といった形にしか捉えきれていなかったので、あっちこっち参照しまくりのお前本当にMVCか？という形になりかけました。一応、なんとかそれっぽい形に落ち着けはしましたが。
アーキテクト的な考えになるのかもしれないのですが、やっぱりそのへん知ってないと修正時にゴチャついてなんとも言えないゴミクズが出来上がるというのは実感しました。
実際に組んでみるのも大事ですが、やっぱり概念的なものを捉えてないとうまいこと動くものは作れないと感じました。
この辺はしばしば議論されててスライドもよく挙げられてるので、そのへんからちょいちょい吸収していきたいところ。
ぜい肉のないコントローラーをめざそう ASP.NET MVC
この辺はmiso先生のブログとかスライドとかに書かれてる内容を特に意識して勉強中です。心の師匠。
・テストコードは思った以上に時間がかかる
さっきから当たり前のことしか書いてないけれど実際自分で体験してみないと実感として身体に埋め込まれないんですよね。
テストコード、というより、テストコードを実装できるようなモデル設計、というべきか。テスト自体書いててクソ楽しいのでいくらでも書いてやるよみたいな気持ちで取り組んだのですが、いざやってみると面倒だし何より前述した通り設計グデグデなのでまずリファクタリングしてからテストしなければならなくてやる気が失せたり、ほかにも実装すべきところがあるのにテストから取り組むのどうよって気持ちになったり、どうせ趣味プログラミングだからいいじゃんって気持ちになったり。
やらない理由しか上げられないのですが、時間がかかるとわかってることには人間なんとも手が出しにくいもんだ。こんなことなら最初っからTDDで取り組んで見積もり日数もっと取っとけばよかったなあと後悔です。最初はテスト時間込の見積もりだったんだ……。
この辺は見積もりの話も込みだし、人月の神話とか読んどくべきかなあと思ってます。
・Session変数の扱いについて
というかSession.Timeoutの話が殆ど。
アレConfigファイルにTimeoutの時間書いてたらその通りの時間でTimeoutすると思ってたんですけど、試してみたらデフォルトの20分で切られました。
レンタルサーバーなのでIISの設定は見られないので、サーバーの問題だったらお手上げです。でもアプリケーションの設定が優先されるはずなので関係ないと思うんだけれどなあ……。
この問題については依然悩み中。
こんなもんかなあ。
結局のところ、いかんせん経験と基礎知識が足りてないので、個人システムでもいいから量産してみてうまいとこ落としどころ見つけたいもんです。
特に今の状態だとIoCコンテナがただいるだけみたいな状態になってるので、テストコードだけでも使えるような設計を考えられるようにしたいところ。
やっぱりまだまだ勉強足りてないねえ。
だいぶ前に書いた覚え書きその2 IEでのJQuery.Ajaxの挙動について
非同期での通信が容易にできるようになり、非常に便利なJQuery.Ajaxですが、
Internet Explorerで特定の条件の場合、うまく機能しないことがあります。
問題
利用ブラウザがInternet Explorerのとき、
JQuery.Ajax、もしくはJQuery.getJSONを使い、
送信するパラメータを変えずにGET属性の通信を行うと、
二回目以降の戻り値が、一回目のものと同一になる。
原因
IEはXmlHttpRequestでのやりとりを行った際、その値をキャッシュします。
JQuery.AjaxはXmlHttpRequestオブジェクトを返しているので、
その影響を受けているようです。
次回以降、パラメータが同じかつGet属性の通信が行われた場合、
キャッシュに保存してある値を返すようになります。
対策
対策はいくつかあります。
1．POST属性にして通信を行う。
あくまでキャッシュに残るのはGETの通信を行った時だけです。
Ajaxのオプションで属性をPOSTにしてしまうか、
JQuery.postを利用すれば、キャッシュの値が返されることはありません。
が、例えば問合せ先のActionResultにHttpGet属性を付けたりしたら、
この対策は即座に破綻してしまいます。
2.パラメータに常に変動するデータを入れる
パラメータ内にTimeStampのようなデータを用意し、
中身にはDatetime.NowやGUIDのようなユニークな値を入れて通信を行うようにします。
毎回送るパラメータが異なるので、キャッシュを利用することがありません。
3.OptionのCatchをfalseにする
Catchはキャッシュを制御するためのオプションで、
デフォルトではTrueとなっています。
これをfalseに指定してやることで、キャッシュを行わないように指定できます。
同様に、ifModifiedのオプションをTrueにしてやることで、
サーバ側のコンテンツの変更があったかどうかを確認し、
変更がなかった時だけキャッシュを表示する、という挙動にしてやることも可能です。
が、これらはJQuery.Ajaxのみ可能な方法で、
getJSONには利用できません。
まとめ
個人的には3推奨。
なんで、Ajaxでオプションを書くのがめんどくさくても、
あとあとのことを考えて、
できるだけgetJSONで書かないようにしましょう。
だいぶ前に書いた覚え書きその1 JSONについて
JSONとは？
>>JSON（ジェイソン、JavaScript Object Notation）は軽量なデータ記述言語の1つである。
>>構文はJavaScriptにおけるオブジェクトの表記法をベースとしているが、 >>JSONはJavaScript専用のデータ形式では決してなく、
>>様々なソフトウェアやプログラミング言語間におけるデータの受け渡しに使えるよう設計されている。
Wikipedia先生より抜粋。
使用できるデータ型は、数値、文字列、True or False、配列、オブジェクト、nullの6つ。大抵のモノはカバー可能です。
日付情報がちょっと頭捻る必要がありそうなくらいじゃないかと思います。
配列は
["a","b","c"]
のように、
オブジェクトは
{“name” : “A“,”age” : 21}
という風に、
”keyname”:値 のように表記します。
これを利用して、 [ {"Name": "A","Age":24}, {"Name": "B","Age":26} ] のようなオブジェクトの配列のやりとりも可能です。
マークアップ言語と通常の言語の中間みたいな感じでしょうか。 最初見た時、C#の匿名クラスっぽいなあと思ってました。今でも思ってます。
どういう時に使えるの？
・Ajax通信の際、サーバサイドとフロントサイドで情報を非同期に受け渡す時に使用する。
・WebAPIのデータ受け渡しに使用する
上記2つが主な使用目的ではないかと思います。いかんせん知識薄いのでまだあるような気もしますが。
特にAjax通信の際、 クエリ文字列やXMLよりも冗長にならずオブジェクトのやりとりが出来るのが、 JSONの一番の強みではないかと思います。
参考URL
http://thinkit.co.jp/article/70/1/
