2013年3月29日金曜日

#java_ja java-ja.ddd いってきた

去る2013/3/22(金)にjava-ja.DDDに行って来ました。

プレゼン資料は

http://www.slideshare.net/digitalsoul0124/ddd-17678116

http://www.slideshare.net/masuda220/ddd-forname

だそうです。

おわり。








































これで、終わってたら、ブログの意味ないですね。

僕はドメインエキスパートと聞いて違和感があったので、

単純に「そんな人いるんですか?」と質問したら、

まあそれなりの質疑応答が始まってしまいました。


結論としては増田さんの「そんな人いない」の一言に尽きると思います。


僕も過去に大手企業の受託開発でいろいろと

Excel方眼紙による設計書を書いていたことがあるわけで、

かつて「顧客」に「敬称」をつけられるようにするという

案件がありました。

通常、僕らが「敬称」といった場合には

「~さん」「~様」「~殿」くらいしか使いませんが、

英語圏であれば

「Mr.~」「Mrs.~」「Dr.~」などがあります。

その案件が発生する元になったインドネシアかタイかでは、

前、後につける敬称があったりするんだとか、しないんだとかで、

いろいろぐぐってはみたものの何がなんだかよくわからんから、

「前敬称」「後敬称」とかいう謎のデータ項目が出来上がりました。


で、僕がこの案件の見積りとかしたとき、

入力画面だけにしか注目していなくて、

2画面を変更する程度の見積りでやりました。


だけど実際は「顧客」の「名前」を表示するというのは

入力画面だけでなくて、

帳票だとか顧客検索結果だとか所謂CRMだとか、

いろんな分野に登場するわけで、

実際にかかった工数は2画面以上の工数がかかったんだとか…


赤字ですな。


まあ、今考えると、

「顧客」の「姓名」「名前」、それと最終的な「顧客表示名」という

オブジェクトに分かれていれば、

この案件、比較的影響範囲が小さかったかななどと思っていたりします。

(実際はそうなっていないということをご想像ください…)





ただ、まあ、一点だけ気になるというか、

後になって考えると質問しておけばよかったなーと思ったのは、

オブジェクトを小さく作っていくことで楽になるとはいえ、

システム全体でクラスがどれくらいになるのか気になりました。

規模にもよると思いますが、

1,000~2,000くらいはあるんじゃなかろうかと推定される気がします…







最後に、

会場を提供してくださったGREEさんありがとうございます。

ピザのサイドメニューでついてきたオリーブ美味しかったです。

2013年3月16日土曜日

G*ワークショップZ Mar 2013 に参加してきた #jggug

みけです。

昨日確定申告の書類を中野税務署に提出したら、

ちょうど中野税務署の門が閉じたところでした。

ギリギリセーフ。


そのあと行って来ました。


G*ワークショップZ Mar 2013 Gradleハンズオン


内容はgithubにあるので、そちらを参考にどうぞ。

https://github.com/nobusue/GradleHandson


あとツイッターの実況中継はまとめられています。

2013/03/15(#jggug)G*ワークショップZ Mar 2013

最近はまとめ職人が洗練されてきていますねw


で、おまいは何をやってたんだ?


何も特にしていないです。

とりあえず、gradleにhelloWorkタスク作って

「hello work」というビルドスクリプト作りました。


毛虫本




Gradle Effective Implementation Guide

この本、翻訳やりたいです。

一ヶ月でやるので、どなたか出版社の人を紹介してくだされ~。



おわり

2013年3月14日木曜日

梅本洋一先生…ご冥福をお祈りします

みけです。

昨日ちょっと悲しいニュースがありました。






梅本先生には大学の3年から4年の、

超域文化学科表象文化論での

映像文化論系で合計6単位くらいをもらいました。


ゼミといういわゆる普通の大学にあるような

制度のない教養学部超域文化学科において、

非常に親しく付きあわせていただいた先生でした。


性格も気さくな方で、

授業の打ち上げでイタリア料理屋で御飯食べて、

映画について語るとか(授業外でもかよ!)、

卒業するのが日本一難しい超域文化学科表象文化論のなかで、

唯一、心のオアシスを提供してくださる先生でもありました。


ヌーヴェルヴァーグから現代の映画まで幅広く抑えている方で、

多分、今僕の映画を見るときの視点を鍛えてくださった方だと思います。


例えば、僕の下記の記事を参考

任侠、車、光と影-ビートたけし『アウトレイジ・ビヨンド』について


僕がまだ2年生の時に映画の授業を受けたのですが、

ストーリー偏重主義・ストーリー解釈主義的な見方を、

一刀両断して、「映像の中で何が映っていたかを見なさい」と

教えてくれたことは今でも忘れません。


さすがにロバート・ロッセンの『リリス』のレポートだけはまじでキツかった。

「少女が妖艶であるとか、そんなのはどうでもいい、あの最後の水のシーン、

あれがこの映画の最大の実験であり、見どころである」

とバッサリ斬られました。

(この辺りは青山真治、阿部和重、中原昌也の対談していた本(タイトル忘れた)でも取り上げられています。)


日本はとてもいい人材を失ったなーと残念な気がします。

(おまいらがいい人材になれということでしょう。)


というわけで、ご冥福をお祈りします。

2013年3月10日日曜日

#GroovyBase Groovy基礎勉強会で発表してきたらしい

みけですう。

昨日(2013/03/09)にGroovy基礎勉強会で発表してきました。



僕の発表内容


例の如く(?)発表資料はありません。

gistのリビジョンでGroovyASTTransformationAnnotation Based ASTTransformation

例をいくつか掲載していますので、御覧ください。

https://gist.github.com/mike-neck/5114818/revisions


まあ、GroovyASTTransformationという題で発表したけど

Annotation Based ASTTransformationを中心に発表しました。

なぜかってそれしか知らなかったGroovyASTTransformationを初めて書く場合には非常に導入しやすいからです。

基本的な(基礎的ではない)ASTTransformationの実装
(@ToString@EqualsAndHashCode@Canonical
@Log@Log4j@Slf4j@Singleton@Delegate)

を知っておくことは、それよりもさらに進んだASTTransformation
(Spockとか、Spockとか、GContractsとか)

を読んで、活用して、新たなASTTransformationに移行することの足がかりになるからです。

実際に僕の発表の後のいくつかの黒魔術(Spock、GContracts)では、

ほとんどがASTTransformationを活用していました。


さて翻って、もう一度ASTTransformationの基礎…


GroovyにおけるASTTransformationの構成要素は次の3つです(かなり端折ってます)。

  • Expression
    • 変数の宣言 (String namedef ageのようなもの)
    • 定数の表現(0"groovy"true)
    • メソッドの呼び出し(list.size()builder.append('c'))
  • Statement
    • 変数の初期化(String name = "hoge";)
    • 変数への代入(String name = builder.toString();)
    • 制御文(if (condition) {//do something} else {//do another thing} )
    • return文(return builder.toString();)
  • Node
    • フィールド
    • メソッド
    • クラス
    • インポート

これら以外にもまだまだたくさん要素があるのですが、

おおよそこれらを把握しておくと、

ASTTransformationを書きやすいです。


所感


上原さんのGroovy Compilerの話

面白かったし、わかりやすい資料でした。

ASTTransformationをやるならこの辺りの知識も持っていないと

厳しい感じがします。

特にコンパイルフェースに対する理解は重要かと思われます。


自分の話

ヒィヒィしてました。

gdgdもいいところです。


須江さんのGradleの話

Gradleを理解したければ、プラグインを書けというのは

納得する。


きよたかさんのSpockの話

なるほど、アレはよくわからん


ポケットバーサーカーさんのGParsの話

GPars出てきてないしw


nobeansさんのGrailsの話

nobeansさん何気にIntelliJ IDEAガチ勢ということが判明


杉浦さんのGConstractsの話

杉浦さん「今季のおすすめアニメは『レイルガン』と『ニャル子さん』」きょん「( ´Д`)=3」


懇親会


ピザと肉食ったら、トイレ行きたくなったので、

トイレで20分くらい過ごしていました。


おわり。


2013年3月7日木曜日

DQX 魔法使い レベル60からのレベル上げ + 金策

みけです。

レベル60の上限開放クエ大変でしたね。

で、魔法使いはレベル64でメラゾーマが使えるようになるみたいです。

非常に楽しみですね。


で、残念なのが経験値。

1レベル上げるのに10万ほど必要になってきます。

こいつはかなり辛い。


というわけで、僕のドラクエ10の魔法使いレベル60からのレベル上げ方法を

書いていきます。


バザックス


最近はバザックスが流行りのようですね。

確かに人が多い気がします。

これは多分ほかのサイトのほうが詳しいので、

ここでは記述しません。


スカラベキング


ここで、僕が提案したいのはスカラベキングです。





こいつ52ゴールドも持っていて金策としても美味しいやつです。

出現地域はバドリー岩石地帯、ヴェリナード西あたりです。


メンバー

魔法使いレベル60に求められる最低限の条件は次のとおりです。

  • 攻撃魔力300以上
  • 覚醒ができること

まあ、最近の魔法使いの皆さんはこれくらいの条件は満たしているでしょう。


メンバーは次のような感じがいいでしょう。

  • 僧侶レベル50以上
    • ユグドラシルを装備していること
  • 魔法戦士レベル50程度
    • 祝福の杖ができる
    • MPパサーがある
    • 肉入りのほうがいいかもしれません
  • 盗賊レベル50以上
    • 王家のナイフまたはサラマンダーを装備
    • 短剣スキル100程度(攻撃力+5/+10/+15があること)

こんな感じです。

戦い方

  • 魔法使い
    • 最初はヘナトスしてスカラベキングの攻撃力を下げる
    • 不気味な光で魔法耐性を弱める(盗賊/魔法戦士がやってもOK)
    • 覚醒してメラミを打ち続ける(1発300程度与えられますので、大体5〜6発で倒せます。)
    • 時折マホトラでMP回復
  • 僧侶
    • スクルト
    • 回復
    • 時折攻撃する(MP回復のため/ユグドラシルなら時折魅了できます。)
  • 魔法戦士
    • 開幕したらピオリム
    • 盗賊にバイキルト
    • 攻撃してMP吸収
    • 僧侶のMPの減り具合に応じてMPパサー
    • なお、かぜきりの弓装備でバイキルトした後、天使の弓でMP回復する方法もありです。(スカラベキングは風が弱点属性)
    • あるいは、ケイロンの弓で回復するという方法もありです。
  • 盗賊
    • とりあえず、盗む
    • 後はひたすら叩く
    • 開幕時ピオリムもあり
    • HPがちょっとやばそうな人(HP170程度)にホイミする

この戦い方で長時間戻ることなく戦えるでしょう。

一匹で得られる経験値が800程度、盗むがお金(いわゆる失敗)だった場合に1回の戦闘で104G得られます。










2013年3月4日月曜日

IntelliJ IDEAでmethodを変更する

みけです。

今朝起きたときは心臓がバクバクなってて、

「やばい、オレ、うつだしのう」と思いました。(結果、生きている)



メソッドを変更したいんですけど…





というわけで、大人しくRefactorを使いましょう。


変更前のコードです。







メニューからRefactor → Change Signature... を選ぶか、

⌘ + F6を押します。





ダイアログが出るので、追加したい引数だとか、修正したい引数を編集します。








Refactorボタンを押せば、自動的にメソッドとそのメソッドを使用している部分が変更されます。






おしまい

2013年3月2日土曜日

try-with-resourcesのアレをIntelliJ IDEAで…

みけです。

先週は鯛委員一週間ということで、

体調は絶悪でした。



IntelliJ IDEAユーザーでいまさらtry-with-resourcesを組めない人なんていないと思うけど…


一応やり方書いておくお。

赤いエラーが出ています。





AutoClosableインターフェースの実装クラスのコンストラクタを呼び出しているところで⌥ + Enterする。





surrond with try-with-resources blockを選ぶ。





try(...)で囲まれたけど、まだ赤いエラーが出たままなので、

もう一度⌥ + Enterする。





Add catch close(s)を選ぶ。





エラー全部消す。





catchが多いとアレなんで、

また⌥ + Enterして、





Collapse catch closesを選んで、まとめる。





できあがり。