パターン

パターンを嫌う人って、思考とか経験を飛ばしてパターンから先に入っちゃって、かつ、パターンを過大評価しちゃってる人が多いイメージ(・ω・)
過大評価っていうか、拡大解釈かな(・ω・)？

パターンが駄目系の文脈で良く出てくる、論理的に美しいかもしれないけど実用的じゃないみたいな発言って、別に美しいものが駄目なわけではなく、単にお前のソレが底の浅い美しさだから駄目なだけって話と違うん？、っていう(´・ω・`)

あと、パターンに対する議論って、盛り上がるのは良いんだけど、拡大解釈して我田引水になっちゃうケースが多いのが玉に瑕ですわん(・ω・)

オッサンだし、パターンっていうのは今までやっていたことに名前を付けた事が重要だと思っているので、パターンをはじから学んでいく的な物言いにはどうも違和感を感じるのよね(・ω・)
コンテキストが最初に来なくて、良く学べるもんだというか(´д｀;)

Omotenashi

SIビジネスに必要なのはOmotenashiとか言ったりするけど、有り余る技術力がなければおもてなしとか出来んよね(・ω・)

技術力とか、創造的な事をやるには目の前の課題をオーバーキルできるくらいでないと駄目だと思うので。
作業的に、とりあえず課題を解決できれば良いだけでないなら、レベルアップにも励まんとな(｀・ω・´)

よって、あるテクノロジーがいまどの位置にあるのかを把握する程度のアンテナ能力と、溝を超えた途端にしれっと採用して「前から良い技術だと思っていたんですよね〜」っとその界隈での古参をﾋﾟｸﾋﾟｸさせるような発言をするだけの厚顔さ、もとい即採用できるだけの技術力は必要なのよね(・∀・)
テクノロジーに関するSIの保守的な観点というのは、キャズムを超えるまでは無視する、程度の意味であって、いつまでも新しいものを採用しない、っという意味ではないと思うのよ、もともとは(・ω・)

SI屋だから○○(新しい技術、ツール、ライブラリ、プロダクト、手法)の導入は難しいとか、眠たいこと言ってる時代じゃないと思うけどね〜(・∀・)ﾆﾋｰ

アメニモマケズ

雨にも負けず 風にも負けず デスマにも ふわふわした顧客の要求にも負けず
金に困らない案件を持ち 毒を吐き 決して残業せず いつも静かに定時帰宅している

東におかしなコードを書く子供あれば 行ってレビューしてやり
西に疲れたPMあれば 行ってタスクを整理してやり(ただしその苦労は負わず)
南にメモリリークがあれば 行ってこわがらなくてもいいといいSOS.DLL
北に新規事業と言いだす企画が居れば つまらないからやめろといい

一人の時は20%ルール
褒められもせず 首にもされず

そういうものに わたしはなりたい(´・ω・`)

テクノロジーの選択

駄目な技術オタは、新しいものの優れたある一面だけを見てそれを礼賛し、古いものを使っているだけで糞だと罵ったりもしますが(・∀・;)

新しい方は、まだエコシステムが不十分だとか、総合的に考えて敢えて古いものを選択しているケースもあるわけで(・ω・)
マジョリティを釣るためには、単体としての良さだけではなく、エコシステムの確立が必要不可欠よね(・ω・)

採用したい、自分の使いたいものがある人は、上っ面の良さを語るだけでなく、単純ではないケースも考慮して実際に結果を積み重ねていけば、周りの人も貴方の意見を採用するようになるんじゃないかと(・ω・)

まあ、世間的には、何を言ったかより誰が言ったかが重視される傾向もあったりもするわけで(・∀・;)

(　´･д･)　(その技術/方法論が信用されていないのではなく、貴方が信用されていないんですよ)

Service層

Service層っていう言葉が、割と都合よくつかわれているというか、Facade兼コンテキストに応じたインタラクションの実装とか、別にService層=スクリプト的な記述にするわけじゃねーしとか(・ω・)

HogeServiceという名称の「ファサードと思いきやデータアクセスコンポーネントも兼ねるモノシリックなクラス」だけでレイヤを構成しているケースも多いんだろうけど。
単純なアプリだと、それでも困らないから(・∀・;) *1

サービスとはレイヤ(ビジネスレイヤ)であって、クラスではなく。
クラスで言うなら、アプリケーションファサード、コアドメインロジックを実装する(PIな)エンティティ、ビジネスコンポーネントなんかからなるものよね(・ω・)

自分の周りでは、ファットななんちゃらとかの話は、昔からプレゼンテーションのパターンの話と同時にレイヤの話をしているので、そう言うほどには見ないけど。
けど、アプリケーション層とドメイン層の分離が屑いというケースは見るかぽね(・ω・)

あと、もう2013年なんだし、ドメインモデルvsトランザクションスクリプト的な話はもういいでしょう、的な。
それって単にパターンの拡大解釈や、レイヤやファサードの話との混同だったりもするし(・∀・;)

っていうか、(国内では)なんでその部分の議論だけが流行っちゃったんですかね(・ω・)？
PoEAAだけで(アプリケーションアーキテクチャの話ではなく)ドメイン回りのアーキテクチャ設計まで語ろうとしたからかしら(・ω・)？

っで、この辺の議論が落ち着くのはドメイン駆動設計の翻訳まで待つことになったのだ…(・ω・) *2

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

あと、プレゼンテーションモデルの話もあるけど、それはまた別途。

*1:1段レイヤができるというだけで十分だから

*2:っていうのが個人的な見解ですが。

Cloudera Certified Developer for Apache Hadoopに合格してきました( ・ω・）ブヒ

っというわけで、Cloudera Certified Developer for Apache Hadoopに合格してきました。
これで、自分もHadoopを知っているとか言っても大丈夫ですよね(・∀・;)？

内容的には、象本の中身が一通りわかっていれば合格はできるレベルじゃないかと(・ω・)
自分が持っているのは第2版までですが、最近第3版が出ましたね。

Hadoop 第3版

一応Windows系の人(?)ですが、遊ぶ時はCDHを使ってHDInsightとかはあまり見ていませんが(・ω・;)
でも、最近はLinq To Hiveをのぞいてみたりとか、Dryadを覗いてYARN上で動くのかよ(；・`д・´)と思っていたりなんかもしますが。

ちなみに、Linq To HiveはHDFSへのアクセスはWebHDFSを使用、クエリはTempleton/HCatalogを使用で、式木(HiveTable : IQueryable)からクエリへの変換はIQToolkitを利用しているみたいですね(・ω・)
IQueryableに対してCreateTable、InsertIntoTableとか、Map、MapMany、ClusterBy、Reduce、ReduceMany等の拡張メソッドが用意されていたりだとか、HiveやIQueryableが好きな人は(・∀・)ﾆﾔﾆﾔできるかもしれません。

ところで自分は蜂の巣より豚の方が好きだったりというか、Pig Latinが手続きというよりもLINQ的なイテレータのチェインにしか見えないので(・∀・;)

　 ε　⌒ﾍ⌒ヽﾌ
　（ 　　( 　・ω・）　ブヒ
　　しー し─Ｊ

ちなみに、実はベンダー系の試験ってこれがはじめてだったりして( ゜Д゜)
これまで、情処くらいしかとったこと無かったので。

フレームワーク

フレームワークとかさー、それを礼賛する人は、その適用に適したケース前提で優れた(生産性の高い部分)だけを持って最高、使わないやつは糞ってdisるし、それを叩く人はその適用が適さないケースを例としてあり得ない、もてはやす奴はアホっと失笑する、っという程度の話なので、まあ、そんなにむきになるなよ(・ω・)

∩(´･ω･`)つ―*'``*:.｡. .｡.:*･゜ﾟ･*　必要な要件、ニーズの前提とかなしに、流行りだとか新しさだとか限定された状況での生産性だとか主観的な良いもの定義とかで特定フレームワークをゴリ押しするだけでなく他をdisるような議論はなくな〜れ♪

ポジショントークは、ネタだと思ってみればまだ許せるけど(・ω・)