ゆとりさんが鮨を奢ってくれるそうなので、感謝の気持を込めて、たくさんのプロセスに「sushi」と言わせてみた

・これはなんですか？

ゆとりAdvent Calendarの11日目です。


・なんで書いているんですか？

ゆとりさんが鮨を奢ってくれるというので、感謝の気持を込めて書いています。


・実行方法は？

• Eshellを開きます。
• yutori.erlをコンパイルもしくはロードします。
• yutori:call()を実行します。
• yutori:sushi(プロセス数, 回数)を入力します。

・実行結果は？

こんなかんじ。

	$ erl
	Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
	Eshell V5.10.1 (abort with ^G)
	1> c(yutori).
	{ok,yutori}
	2> yutori:call().
	true
	3> yutori:sushi(6,10).
	sushi
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.
	<0.42.0> sushi.
	<0.43.0> sushi.
	<0.44.0> sushi.
	<0.45.0> sushi.
	<0.46.0> sushi.
	<0.40.0> sushi.

view raw console.txt hosted with ❤ by GitHub

・結論

僕にはゆとりがないので、ゆとりさんを待たずにyutori:sushi(プロセス数, 回数)を実行してしまいました。

	$ erl
	Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
	Eshell V5.10.1 (abort with ^G)
	1> l(yutori).
	{module,yutori}
	2> yutori:sushi(6,10).
	** exception throw: {error,yutori_nante_nakatta}
	in function yutori:send/3 (yutori.erl, line 19)

view raw error.txt hosted with ❤ by GitHub

ゆとりなんてなかったんや！

コードはこちらからどうぞ。

すこしブログを解体しようと思います。

みけです。

相変わらず集中力がなかったり、

昼間に２時間は昼寝しないと駄目だったり、

イライラしていたり、

「死にたい」とか「死ね死ね」「(　ﾟ∀ﾟ)o彡°おっぱい！おっぱい！ 」と心のなかで思ってたり

で、まともな状態ではいないです。

本題

ここのブログ、当初はScalaを覚えるときの覚書きのような感じで始めたわけですが、

AndroidやGroovyが入ってきたり、最近ではErlangが入ってきたり、

まあ、プログラミング言語が入ってくるのはいいんですが、

ドラクエ入ってきたり、

「死にたい」とか「死ね死ね」「(　ﾟ∀ﾟ)o彡°おっぱい！おっぱい！ 」といった

人様にお見せするような内容でないものがあったりで、

カオスと化しててちょっとアレなので、ブログを解体しようと思います。

さらには、アクセスで最も多いものがドラクエに関するものだったりで

すっごく残念です。

内容

とりあえず、こんな感じで解体します。

• プログラミングに関するやつ→ここに書いていくgithubに移動する(2013/05/08 17:17 変更)
• 仕事のあれとかプロジェクト進行とかソフトウェア開発手法(あ、そんなの書いてない…(´・ω・｀))→別のブログに移動する
• ドラクエに関するやつ→別のブログに移動する
• 「死にたい」とか「死ね死ね」「(　ﾟ∀ﾟ)o彡°おっぱい！おっぱい！ 」といったやつ→別のブログに移動する

結論

今後ともよろしくお願いします。

(2013/05/08 17:17 追記)

すえさんの希望により、ブログの変更先などを変更しました。

プログラムに関する奴はgithubに移動します。



…これでこのブログの更新、終わりじゃん…(´・ω・｀)

SIerが業務知識が目的でありIT技術が道具であるというならば…

古いエントリーだし、まあどうでも良いといえばどうでもいいんですけど…

スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記

のリンクがツイートされてきてちょっと思ったことを少しだけ…


なんか名工とかが道具のメンテナンスをしっかりやるのは、

名工がそのパフォーマンスを常に最大限出せるようにしているからで、

SIerがIT技術を道具として顧客業務の付加価値を高めるのが生業なら、

IT技術は常にメンテナンスしてないといかんよね。


というわけで、業務知識もさることながら、

IT技術は常に磨いていかないといけないなーと思った次第であります。

ドラクエやるやつ、もう少し属性とか勉強しろよ

さっき、迷宮でジャミラス相手に苦戦したみけです。


で、苦戦の原因ですが、

弓魔法戦士がさみだれうち連発してMP切れて天使の矢をしてを繰り返してて、

効率が悪かったからです。

ちなみに僕はスーパースターで僧侶のサポートしてました。

僧侶さんは回復でいっぱいいっぱいでした。

もう一人はサポートの盗賊で、

タイガークローしすぎてMPが枯渇して、

使い物になっていませんでした。


あまりに効率が悪かったので

チームチャットで

バイキルト→アイスフォース→バードシュートが一番効率がいい

とアドバイスしました。

その後はあっけなく倒せました。


で、いっつも思うんですけど、

爆裂拳、タイガークロー、氷結らんげき、さみだれうち、

こういった技はコスパが悪いので、

ドラクエやる人はちゃんと属性の勉強して下さい。


ブリザード相手に氷結らんげきとか、

フレイムドッグ相手に火炎斬りとか、

魅了された敵がいるのにさみだれうちとか、

ガニラスへの爆裂拳・タイガークローとかは

無駄なのではっきり言って迷惑です。



また、魔法戦士をやる人は、

フォース全種類の習得および敵の弱点をすべて暗記するのは必須です。

以上。



なお、僕が魔法戦士をしているときは、

爆裂拳・タイガークロー・氷結らんげきしかやらない人には

MPパサーは渋りますので…

システム開発会社として善良なる管理者の義務に基づき瑕疵のないシステム構成を設計すべき義務がある

雨で人格が完全に縮退しているみけです。

世間を騒がせたJINS PCのクレカ情報流出事故の報告が発表されたようです。


不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）




これをうけて、エンジニアの方々のエントリーがいくつかあるようです。

• 水まんじゅう - JINSオンラインショップ最終報告について
• ikeike443のブログ - 脆弱性パッチあてろよとかフレームワークのバージョンアップしろよとか

また、発表されたStruts2の不具合については下記の通り報告があるようです。

• Apache Strutsソフトウェアの脆弱性を利用した攻撃の危険性 - NRIセキュアテクノロジーズ
• Apache Struts のException Delegatorにおける入力値処理の不備により任意のJavaコードが実行される脆弱性 (CVE-2012-0391)に関する検証レポート - NTTデータ先端技術株式会社

まあ、技術的な側面での考えはだいたいこんなもんかなとおもいます。

で？

技術的な側面に向けての記事書いたって、

もう二番煎じだし、

技術が優れている人がJava6以前使うなとかRuby1.9以前使うなとか

いろいろ発言されているので、

技術がない僕としては自分の興味にそってなんか書こうと思います。


で、僕はまあ、精神的にアレな人なので、

人間のもっと暗黒面というか、

どろくさい部分に目を向けたいと思います。

再発防止策から読み解いてみよう

JINSでは再発防止策を下記の通り発表しています。

• PCI DSS(Payment Card Industry Data Security Standard)への準拠
• 外部の決済代行サイトの利用

というわけで、JINSでは内部でカード決済の機能を使わないように、

システムの仕様を変更するということですね。


じゃ、なんで最初から決済代行サイトを採用していなかったのかな…(´・ω・｀)


理由はいろいろと考えられます。

• 決済代行サービスの利用料が高かったのでカード決済の機能を作成したかった
• カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された

いいにおいがプンプンする所で、

事故の根本原因(と考えられるもの)が

前者だとユーザー側にあって、後者だとユーザー側にないということになりますね。


実際にどういう経緯があったかはわかりませんが、

まあ、事故のあとの報告としては後者の方に倒したいところですね。

言葉遊び・数字あそび

ところでITシステムにおいて、tabula rasaなるユーザーにおいては、

システム開発のプロフェッショナルたるシステム開発会社にアドバイスをもとめるわけで、

先の理由の部分、いくらでも書き換えられます。

• 決済代行サービスの利用料が高かいとベンダーから報告を受けたので、自前で開発することを決定した
• カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された

こうなってくると、もうベンダーの方は完全に負け戦になります。

特にこういう提案資料とかの金額の部分って、いくらでもごまかせます。


こういった類の本が売られているほど、

数字というのはうそをつけるし、

数字によって騙されやすいもののようです。


まあ、企画提案書とかどうなっていたのかわからないから、

推測の域を出ませんけど、

もしかしたら、

スクラッチで開発する方が、外部の決済代行サービスを利用するよりも安くなるような

資料があるかもしれません。

だって

システムを開発する会社からすれば、

開発機能を増やして、

売上を高くしたいですからね…


(利益を高くするでないところに注意)

人間的、あまりに人間的

人間、一度成功を体験すると、

• もっと挑戦をして、成功を体験したい
• 同じ手法にて成功を増やしたい

こんな欲望が発生するかもしれません。

まあ、純粋に技術者だったら前者ですが、

企業としては確実に成功を狙いたいですから、

後者のほうを選ぶことが多いかもしれません。


ということで、Struts2のバージョンが云々とありますが、

その古いStruts2のバージョンでの成功の経験がある

リーダーないし、プロジェクトマネージャーないし、アーキテクトがいたので、

その古いStruts2を採用した可能性は否めません。


で、後者の方を選択する人の常として、

最新情報に疎いことが往々にしてあります。


といったわけでセキュリティイシューを見逃していたことは否定出来ないと思います。

で、笑えない話

ところで、JINSの発表を受けて僕がした適当なツイート、

結構リツイート頂いたようです。

ベンダー「Struts2のバージョンを上げたい」JINS「それ、何が変わるの？いくらかかるの？」ベンダー「機能は変わりません。セキュリティが向上します。～百万円です。」JINS「機能増えないんだ。じゃ、やらなくていい」#システム開発会社として善良なる管理者

— hotchemiさん (@mike_neck) 2013年5月1日

JINSさん美味しいネタ提供ありがとうございました。

じゃなかった、

以前、僕が務めていた会社で、

システムを更改する案件があった時に、

お客さんに更改する旨伝えて、お金をいただくわけですが、

なんで機能が増えないのに、お金を支払わないとイケないわけ？

と文句を言われたことがありました。


システムの更改は、ハードウェアの故障率の増加とか、

ミドルウェア、ハードウェアの保守期限が切れるために

行わざるを得ないのですが、

ユーザーからすればベンダーの都合によりお金をとられるのは割にあわないと

感じているようです。


ハードウェア、ミドルウェアの保守期限が切れているため、

壊れてしまえば、もうどうすることもできなくなるのですが、

人間、壊れていないときに、壊れた時の話をしても

ピンときません。


だから更改の提案をするときは本当に嫌がられます。

で、僕のあの適当なツイートはあながち笑い事ではないです。

とりとめのない文章になって来ましたがマトメ

システムの開発・運用って、やっぱり人間的な

ドロドロしたものがあるので、

なんか、もう、アレですね。

(アレ＝適当に察して下さい)


というか、タイトルほとんど関係あらへんがな(´・ω・｀)

「「Java 8を関数型っぽく使うためのおまじない」をGroovyでやってみた」をGroovyにした

バイク川崎バイク：「ブンブン」

きしださんのエントリー「Java 8を関数型っぽく使うためのおまじない」のいろんなバージョンが出ていますね。

Java 8を関数型っぽく使うためのおまじないをF#でやってみた

Java 8を関数型っぽく使うためのおまじないをGroovyでやってみた


というわけで、僕もとおもったんだけど、

関数型いまいちわからんので、


『「「Java 8を関数型っぽく使うためのおまじない」をGroovyでやってみた」をGroovyにした』と題してやってみた。

	String.metaClass.define {
	enclose = {
	"[${delegate}]" as String
	}
	}
	assert '[foo]' == 'foo'.enclose()
	assert 'Foo' == 'foo'.capitalize()
	assert '[Foo]' == 'foo'.capitalize().enclose()
	String.metaClass.define {
	middle = {
	delegate.substring(delegate.size() / 3 as int, delegate.size() * 2 / 3 as int)
	}
	}
	assert 'foo' == 'fizfoobar'.middle()
	assert '[Foo]' == 'fizfoobar'.middle().capitalize().enclose()
	String.metaClass.define {
	sandwich = {enc ->
	"${enc}${delegate}${enc}" as String
	}
	}
	assert 'バイク川崎バイク' == '川崎'.sandwich('バイク')
	/*
	* カリー化 != 部分適用
	*/
	String.metaClass.define {
	haskell = {pre ->
	def item = delegate
	return {post -> "$pre$item$post" as String}
	}
	haskell = {pre, post ->
	"$pre$delegate$post" as String
	}
	}
	assert 'ばいく川崎バイク' == '川崎'.haskell('ばいく')('バイク')
	assert 'ばいく川崎バイク' == '川崎'.haskell('ばいく', 'バイク')

view raw バイク川崎バイク.groovy hosted with ❤ by GitHub

とちゅうで終わってるのは、眠いから。

…ひどいなコレ(´・ω・｀)

ドラクエ10の迷宮にて思う

ドラクエ10はこれまでのドラクエと比べて、

他の人がどういうプレイをするかがわかるので、

まあ、いろいろと面白いわけですが、

自分とは美意識が違う人が多いなと思います。


それが顕著に現れるのが迷宮です。


で、特にこれはないわーと思う人を書いてみようと思います。

爆裂拳僧侶

回復系の職業が一つでも入っていると結構安心するのですが、

爆裂拳僧侶だけは安心できないです。


というのも、爆裂拳をする人は共通して、

バカの一つ覚えのように爆裂拳を繰り出します。


爆裂拳は消費MPが4で、一回の戦闘で少なくとも４〜５回は使います。

一つのフロアにモンスターシンボルが4つあり、

ひらめきの指輪でのMP回復が3とすると、

一つのフロアでのMP消費量は60です。


で、迷宮の３階が終わる辺りから、

魔法の小瓶をがぶ飲みするか、

素手・格闘をやめてスティックに持ち替えて、

MPの吸収に切り替えます。


まあ、これレベル40くらいの武闘家とか盗賊なら

仕方がないにゃ～と思うに留めるのですけど、

僧侶がこれをやると回復大丈夫ですか？と不安になります。


自分のMP管理で精一杯なのに、

人のHPを管理できるのか心配で仕方ないです。


というか、がぶ飲みしている点で、

自分のMPも管理できてないですね…


というわけで、爆裂拳僧侶は僕の美意識上ありえないです。

(元々自分も素手・格闘僧侶でしたが…)

タイガークロー

タイガークローは強いので良いです。

でも、タイガークローの人も爆裂拳の人と同じで、

バカの一つ覚えで、タイガークローしかしません。


まあ、強いからいいんですけど、

強いという安心感からか、

状況を判断せずにタイガークローを選択している人が多いように

見受けられます。


よく見られる例では、

• キングレオが力溜め20の状態で、怒り状態なのにロストアタックせずにタイガークローして激しく切り裂くで死ぬ
• 灼熱・輝く息する相手に構わず前から攻めていって、息攻撃食らって死ぬ
• 敵数が多いので眠らせた敵を気にせずタイガークローはなって、起こして、敵に囲まれて死ぬ

といったあたりでしょうか。

まあ、強いからといって過信しすぎるのもアレですね。


あー、後、MP管理ができていないという点で爆裂拳の人と同じなところもあります。

なんでも氷結らんげきする人

棍という武器は日輪の棍という、反則的な武器があるのでスキルを棍にした人が多い人気のある武器です。

ですが、氷結らんげきは本来の日輪の棍の光属性を捨てて、氷属性で攻撃します。

で、爆裂拳・タイガークローと同じで、

なんでも氷結らんげきするバカの一つ覚えがいます。


ゾンビ系の敵は光属性が弱点ですが、

氷属性に対しては耐性を持っている敵がいたりします。


氷結らんげきは消費MP5で、通常の0.5倍の攻撃を4回繰り返します。

で、ゾンビ系の氷耐性はダメージを0.75倍に減らします。

したがって大体通常攻撃の1.5倍くらいのダメージを与えます。

一方、棍の技として消費MP1の黄泉送りというのがあります。

これはゾンビ系の敵に通常攻撃の1.5倍のダメージを与えます。

ゾンビの弱点は光ですので、日輪の棍なら1.3倍くらいダメージが乗るので、

日輪の棍で黄泉送りすると、通常攻撃の約2倍程度のダメージを消費MP1で与えられます。


比較して、消費MP5で1.5倍と消費MP1で2倍ならどっちを取るかと云えば、

まともな考えを持っている人なら後者を取ります。


でも氷結らんげきバカは前者を取ります。

理由はわかりません。

まあ、アレでしょうね。

MP消費して派手な技やって、

充実感を楽しんでいるのでしょうね。

ははは、意識高くていいですねー


で、これが武闘家か旅芸人ならまだ許します。

僧侶ならもうアウトですね。

自分のMP管理できないようでは人のHPは管理できないので、

レベル上げやめて下さい。

あなたは僧侶向いていません。

息攻撃する敵の最初のターンに心頭滅却しない

息攻撃食らってたのしいですかね…

魔法する敵の最初のターンに魔結界しない

魔法食らって楽しいですかね…

敵の耐性のある属性などで攻撃する

無駄な攻撃して楽しいですかね…

まとめ

まあ、僕の美意識上ありえない人をあげたわけですが、

僕のプレイの仕方も他の人の美意識上ありえないことをやっていたりします。

例えば、

• 盗賊・旅芸の時に、スリープダガー・ヴァイパーファング→ヒュプノスハント・タナトスハントを多用する
• 魔法戦士の時に、素手・格闘の人にはバイキルト・バイシオン、MPパサーしない(無駄だから、無駄な奴は苦しめ)
• もう敵を倒しかけたなと思ったら、次の敵に向かって移動を開始する
• ヴァイパーファングで猛毒で毒で倒す
• チャットでありがとうを「あｒ」、おめでとうを「おｍ」で済ませる(キーボードうつの面倒い)

まあ、人それぞれということですね。

リング上のプロセスでメッセージを伝達する

Erlang見習中のみけです。

オライリーの『Erlangプログラミング』は各章の最後にエクササイズがあって、

そのエクササイズの4-2を解いてみました。

内容

課題はN個のプロセスがリング上に形成されていて、

メッセージをM個伝達し、

M個伝達し終わったらプロセスを終了するというものです。

	-module(ring).
	-import(io, [format/2]).
	-import(timer, [sleep/1]).
	-export([start/3, new_process/3]).
	start(M, N, Msg) when M > 0, N > 1 ->
	Processes = N - 1,
	Size = M - 1,
	Count = N * M,
	Top = self(),
	Pid = spawn(ring, new_process, [Size, Processes - 1, Top]),
	format("~p next -> ~p~n", [self(), Pid]),
	listen(Size, Processes, Msg, Pid, Count);
	start(M, _, _) when M =< 0 ->
	{error, "Message size should be larger than 1."};
	start(_, N, _) when N =< 1 ->
	{error, "The number of processes should be larger than 1."}.
	new_process(M, N, Top) ->
	Pid = prepare(M, N, Top),
	format("~p next -> ~p~n", [self(), Pid]),
	listen(M, N, Pid).
	prepare(_, 0, Top) -> Top;
	prepare(M, N, Top) ->
	spawn(ring, new_process, [M, N - 1, Top]).
	listen(M, N, Next) ->
	receive
	{message, Msg, Pid, Count} ->
	sleep(10),
	print_message(self(), Msg, Pid, M, Count),
	Next ! {message, Msg, self(), Count - 1},
	case M =:= 0 of
	false -> listen(M - 1, N, Next);
	true -> ok
	end
	end.
	listen(M, N, Message, Next, Count) ->
	Next ! {message, Message, self(), Count},
	listen(M, N, Next).
	print_message(Pid, Msg, From, M, Count) ->
	format("~p => [~p:~p] => ~p", [From, Count, Msg, Pid]),
	case M =:= 0 of
	true -> format("(final)~n", []);
	false -> format("(last : ~p)~n", [M])
	end.

view raw ring.erl hosted with ❤ by GitHub

実行結果は下の通り。

	1> l(ring).
	{module,ring}
	2> spawn(ring, start, [3, 7, hello]).
	<0.35.0> next -> <0.36.0>
	<0.36.0> next -> <0.37.0>
	<0.37.0> next -> <0.38.0>
	<0.38.0> next -> <0.39.0>
	<0.39.0> next -> <0.40.0>
	<0.40.0> next -> <0.41.0>
	<0.41.0> next -> <0.35.0>
	<0.35.0>
	<0.35.0> => [21:hello] => <0.36.0>(last : 2)
	<0.36.0> => [20:hello] => <0.37.0>(last : 2)
	<0.37.0> => [19:hello] => <0.38.0>(last : 2)
	<0.38.0> => [18:hello] => <0.39.0>(last : 2)
	<0.39.0> => [17:hello] => <0.40.0>(last : 2)
	<0.40.0> => [16:hello] => <0.41.0>(last : 2)
	<0.41.0> => [15:hello] => <0.35.0>(last : 2)
	<0.35.0> => [14:hello] => <0.36.0>(last : 1)
	<0.36.0> => [13:hello] => <0.37.0>(last : 1)
	<0.37.0> => [12:hello] => <0.38.0>(last : 1)
	<0.38.0> => [11:hello] => <0.39.0>(last : 1)
	<0.39.0> => [10:hello] => <0.40.0>(last : 1)
	<0.40.0> => [9:hello] => <0.41.0>(last : 1)
	<0.41.0> => [8:hello] => <0.35.0>(last : 1)
	<0.35.0> => [7:hello] => <0.36.0>(final)
	<0.36.0> => [6:hello] => <0.37.0>(final)
	<0.37.0> => [5:hello] => <0.38.0>(final)
	<0.38.0> => [4:hello] => <0.39.0>(final)
	<0.39.0> => [3:hello] => <0.40.0>(final)
	<0.40.0> => [2:hello] => <0.41.0>(final)
	<0.41.0> => [1:hello] => <0.35.0>(final)

view raw ring_execution.txt hosted with ❤ by GitHub

なんか、もう少しプログラムの行数を減らせそうな気がする。

やってて覚えたこと

• atomにプロセスをregister/2関数にて割り当てるとき、既に他のatomにプロセスが割り当てられている場合、エラーが発生する。
  
  • つまりひとつのプロセスはひとつのatomにしかregister/2関数で割り当てられない
• whereis/1関数の戻り値はプロセスID
• プロセスを強制終了する場合は、exit/2関数を用いる。引数はPid、終了する原因(atomなど)

うん

Erlangって型ないですねー

企業が求めるストレスに強い人材像に関する矛盾

ストレス耐性のないみけです。

デスマとかになると、

メンバーが苛ついて、

攻撃的になりますね。


さて、企業が求めるストレスに強い人材とかいう

馬鹿げた人物像がありますが、



あれ、


苛ついたメンバーが攻撃的になるのは

おｋで、

その苛ついたメンバーの攻撃対象になった人が、

鬱とか精神失調になった時の、

攻撃対象になった人がストレスに弱い人材と

なっているみたいですね。


おかしくないですか？


ストレスを抱えているのは、

攻撃的な人材も、攻撃を受ける人材も同じなのに、

それが攻撃的に出る人材が

ストレス耐性があるとでも言うんでしょうか？


馬鹿げてますね。


攻撃的になる人材のほうが

ストレス耐性が弱いですよ。


そういう人間は攻撃することで、

ストレスから逃れているので、

まあ生き残れます。

でも、

攻撃対象になった人間が

ストレス耐性がないと断定するのは

おかしいですよね。


攻撃的になっている人間が

ストレス耐性がないというのを

見逃していると思います。


だから、企業はストレス耐性がある人間といった時に、

ストレスが掛かった状態で

攻撃的になる人間を採用してはいけないわけです。


人間、ストレス抱えた状態で、

味方であるはずのメンバーから攻撃されれば、

逃げ場はなくなります。


そんなの、ストレス耐性があろうが

なかろうが、追い詰められるのは当たり前です。


だから、ストレスで攻撃的になる人間、

そういう人間を早期発見して、

解雇するなり、

プロジェクトから外すなりしたほうが

企業として優秀な人材を失わなくて済むし、

社会にとっても有益なはずです。

結論

ストレスで攻撃的になる人間は

死すべき、そして社会から抹殺されるべき


以上。

Erlangばっかりやっていますが

Erlang見習いミケです。

Erlangばっかりやっていますが、

本当はJavaのASTライブラリーを書きたいです。

書きたいですが、頭が混乱して、

自信喪失しているので、

Erlangで初歩的なことをして自信を回復しています。

以上、それだけです。

まあ、ErlangでWebアプリくらい作れるようになるといいなとおもいます。

Erlangでマージソート書いたら、なんか汚かったで御座る

Erlang見習中のみけです。

Erlangでマージソート書いたら、クイックソートの100倍は汚いコードになりました。

誰かツッコミください。

	-module(msort).
	-import(lists, [sublist/2, sublist/3]).
	-export([sort/2, asc/1, desc/1]).
	asc(List) ->
	sort(fun(X, Y) -> X < Y end, List).
	desc(List) ->
	sort(fun(X, Y) -> X > Y end, List).
	sort(_, []) -> [];
	sort(_, List) when length(List) =:= 1 -> List;
	sort(Compare, List) ->
	merge(Compare,
	sort(Compare, left(List)),
	sort(Compare, right(List)),
	[]).
	left(List) ->
	sublist(List, half(List)).
	right(List) ->
	sublist(List, half(List) + 1, length(List) - half(List)).
	reverse(List) ->
	reverse(List, []).
	half(List) ->
	length(List) div 2.
	reverse([], List) -> List;
	reverse([X|T], List) ->
	reverse(T, [X|List]).
	merge(_, [], [], List) -> reverse(List);
	merge(Compare, [L|Left], [], List) ->
	merge(Compare, Left, [], [L|List]);
	merge(Compare, [], [R|Right], List) ->
	merge(Compare, [], Right, [R|List]);
	merge(Compare, [L|Left], [R|Right], List) ->
	case Compare(L, R) of
	true -> merge(Compare, Left, [R|Right], [L|List]);
	false -> merge(Compare, [L|Left], Right, [R|List])
	end.

view raw msort.erl hosted with ❤ by GitHub

Erlangでプロセスたくさん使ってフィボナッチ数列を計算したら、too many processesとなっておこられたで御座る。

調子が悪いので

Erlangで初心者的なことをやって

自信を回復しようとしているみけです。

Erlangでのプロセス間通信

spawnという関数を用いて関数を実行すると、

その関数のプロセス識別子が取得出来ます。

そしてプロセス識別子に対して!演算子を用いることで、

プロセスに対してメッセージを送信することができます。

フィボナッチ数列の計算

ところで、Erlangでフィボナッチ数列を計算する関数は簡単に書けます。

-module(fib).
-export([fib/1]).

fib(N) when N < 2 -> 1;
fib(N) ->
    fib(N - 1) + fib(N - 2).

ところが、この関数はひとつのプロセスで実行するために、

値が大きくなると途端にパフォーマンスが低下します。

3> timer:tc(fib, fib, [10]).
{11,89}
4> timer:tc(fib, fib, [12]).
{24,233}
5> timer:tc(fib, fib, [14]).
{61,610}
6> timer:tc(fib, fib, [20]).
{1546,10946}

timer:tc関数の戻り値の一つ目の要素が実行時間(ms)です。

ガクガクって増えていっている様子がわかります。

そこで複数プロセスでフィボナッチ数列を計算する

そこで、fib:fib関数を少し修正して、

プロセス間通信する形で計算してみます。

	-module(fib).
	-import(lists, [sum/1]).
	-export([fib/1, fib/2]).
	fib(0) -> 1;
	fib(1) -> 1;
	fib(N) ->
	Self = self(),
	spawn(fib, fib, [N - 1, Self]),
	spawn(fib, fib, [N - 2, Self]),
	summary([], 0).
	fib(0, Pid) -> Pid ! 1;
	fib(1, Pid) -> Pid ! 1;
	fib(N, Pid) ->
	Self = self(),
	spawn(fib, fib, [N - 1, Self]),
	spawn(fib, fib, [N - 2, Self]),
	summary([], 0).
	summary(List, 2) -> sum(List);
	summary(List, N) ->
	receive
	Result -> Temporary = List ++ [Result],
	summary(Temporary, N + 1)
	end.

view raw fib.erl hosted with ❤ by GitHub

では、試してみます。

3> timer:tc(fib, fib, [10]).
{2889,89}
4> timer:tc(fib, fib, [12]).
{5109,233}
5> timer:tc(fib, fib, [14]).
{5684,610}
6> timer:tc(fib, fib, [20]).
{132777,10946}

う〜んと、値が大きい割には、値の増え方が緩いですね。

では、40くらいだとどうなるでしょうか？

7> timer:tc(fib, fib, [10]).

結果が返ってきませんねー

	=ERROR REPORT==== 25-Apr-2013::20:30:38 ===
	Too many processes
	=ERROR REPORT==== 25-Apr-2013::20:30:38 ===
	Error in process <0.22339.4> with exit value: {system_limit,[{erlang,spawn,[fib,fib,[3,<0.22339.4>]],[]},{fib,fib,2,[{file,"fib.erl"},{line,43}]}]}
	=ERROR REPORT==== 25-Apr-2013::20:30:38 ===
	Too many processes
	=ERROR REPORT==== 25-Apr-2013::20:30:38 ===
	Error in process <0.22342.4> with exit value: {system_limit,[{erlang,spawn,[fib,fib,[2,<0.22342.4>]],[]},{fib,fib,2,[{file,"fib.erl"},{line,44}]}]}

view raw result.txt hosted with ❤ by GitHub

あ、え、エラー…

too many processesだってｗ

というわけで

まあ、何が問題だったかというと、

所詮4コアしか積んでいないマシンで無数のプロセスを起動すると、

死ぬ

というわけですね。


まあ、当たり前と言っちゃ当たり前ですね。


さて、では、プロセス数を4より増やさないようにして

書いてみたのが次のやつになります。

	-module(fib).
	-export([fib/1, fib/2]).
	-export([cfib/1, cfib/2]).
	-export([ccfib/1, ccfib/2]).
	fib(N) when N < 2 -> 1;
	fib(N) ->
	fib(N - 1) + fib (N - 2).
	fib(N, Pid) when N < 2 -> Pid ! 1;
	fib(N, Pid) -> Pid ! fib(N - 1) + fib(N - 2).
	cfib(N) when N < 2 -> 1;
	cfib(N) ->
	Self = self(),
	spawn(fib, fib, [N - 1, Self]),
	spawn(fib, fib, [N - 2, Self]),
	summary([], 0).
	cfib(N, Pid) when N < 2 -> Pid ! 1;
	cfib(N, Pid) -> Pid ! cfib(N).
	summary(List, 2) -> lists:sum(List);
	summary(List, N) ->
	receive
	Result -> Temporary = List ++ [Result],
	summary(Temporary, N + 1)
	end.
	ccfib(N) when N < 2 -> 1;
	ccfib(N) ->
	Self = self(),
	spawn(fib, ccfib, [N - 1, Self]),
	spawn(fib, ccfib, [N - 2, Self]),
	summary([], 0).
	ccfib(N, Pid) when N < 2 -> Pid ! 1;
	ccfib(N, Pid) ->
	Self = self(),
	spawn(fib, cfib, [N - 1, Self]),
	spawn(fib, cfib, [N - 2, Self]),
	Pid ! summary([], 0).

view raw fib.erl hosted with ❤ by GitHub

関数fibはひとつのプロセスでやる奴。

関数cfibは二つのプロセスでやる奴。

関数ccfibは四つのプロセスでやる奴。


で、実際に時間を計測してみました。

	1> c(fib, array).
	{ok,fib}
	2> FibTimer = fun(Func, Arg) -> timer:tc(fib, Func, Arg) end.
	#Fun<erl_eval.12.17052888>
	3> Matrix = fun(N) -> {
	3> N,
	3> FibTimer(fib, [N]),
	3> FibTimer(cfib, [N]),
	3> FibTimer(ccfib, [N])}
	3> end.
	#Fun<erl_eval.6.17052888>
	4> Bench = fun(List) -> lists:map(Matrix, List) end.
	#Fun<erl_eval.6.17052888>
	5> [0,2,4,6,8] =:= array:range(0,8,2).
	true
	6> Bench(array:range(10,30,2)).
	[{10,{11,89},{28,89},{84,89}},
	{12,{24,233},{34,233},{75,233}},
	{14,{61,610},{84,610},{109,610}},
	{16,{234,1597},{253,1597},{329,1597}},
	{18,{420,4181},{419,4181},{439,4181}},
	{20,{1546,10946},{1103,10946},{612,10946}},
	{22,{2695,28657},{2086,28657},{1551,28657}},
	{24,{7324,75025},{4871,75025},{3096,75025}},
	{26,{16549,196418},{11037,196418},{7516,196418}},
	{28,{42813,514229},{29904,514229},{21128,514229}},
	{30,{111535,1346269},{79943,1346269},{50972,1346269}}]

view raw terminal.txt hosted with ❤ by GitHub

だいたい、16〜20くらいで、複数プロセスの効果が現れていますね。

Erlangのリスト内包表記がすごい便利

Erlangのリスト内包表記がすごい便利です。

クイックソートも簡単に書けます。

	-module(quick_sort).
	-export([q_sort/2, q_asc/1, q_desc/1]).
	q_sort([P|T], Compare) ->
	q_sort([X || X <- T, Compare(X, P)], Compare) ++
	[P] ++
	q_sort([X || X <- T, not(Compare(X, P))], Compare);
	q_sort([], _) -> [].
	q_asc(List) -> q_sort(List, fun(X, Y) -> X < Y end).
	q_desc(List) -> q_sort(List, fun(X, Y) -> Y < X end).

view raw quick_sort.erl hosted with ❤ by GitHub

これ、数学的には

(∀x; x ∈ P, Q(x, p))

って書いている感じなので、

読みやすいですし。

Erlangを少し勉強してみてる

少しだけErlangを勉強してます。

まだファイルIOとかできないし、

プロセス間の通信とかできないし、

並行処理とかできないし、

並列処理とかできないです。

重複する要素を含むリストの個数を数える関数を作ってみました。

	-module(erl_list_count).
	-export([group_by/1]).
	group_by(List) ->
	lists:map(
	fun(Item) -> {Item, length([X || X <- List, X =:= Item])} end,
	lists:usort(List)).

view raw erl_list_count.erl hosted with ❤ by GitHub

実際に試してみました。

	1> c(erl_list_count).
	{ok,erl_list_count}
	2> List=[2, 8, 7, 10, 3, 6, 8, 1, 5, 7, 1, 10, 9, 9, 8, 1, 1, 2, 1, 9, 4, 4, 7, 7, 8, 10, 1, 3, 6, 8, 5, 5, 10, 1, 1, 3, 6, 5, 4, 8].
	[2,8,7,10,3,6,8,1,5,7,1,10,9,9,8,1,1,2,1,9,4,4,7,7,8,10,1,3,
	6|...]
	3> [{1, 8}, {2, 2}, {3, 3}, {4, 3}, {5, 4}, {6, 3}, {7, 4}, {8, 6}, {9, 3}, {10, 4}]
	3> =:=
	3> erl_list_count:group_by(List)
	true

view raw erl_console.txt hosted with ❤ by GitHub

まだ、こんなレベル…

#DQ10 ちょっとした小銭稼ぎと水の樹木を量産する

最近やっとレンジャーがレベル５８になって、

手なづけるを覚えさせたみけです。


そんな僕はランプ錬金やっていて、

家の棚の中には錬金用の素材がびっしり埋まっています。

水の樹木

で、そんな中で在庫が少ないものの一つが


水の樹木

です。

キラキラポイント

これらをキラキラポイントで拾おうとすると、

• スイゼン湿原
• ジュレー島上層

をまわる必要があります。


だけど、ぶっちゃけ、

スイゼン湿原は(強ボスやらないので)ほとんど行かないし、
ジュレー島上層は南東部にあるっぽいけど、その辺の敵強すぎるし
(倒せないことはないけど、正直結構苦戦する。レベル65でもスタンプが押せる)

ということであまり行くことが殆どありません。

買う

実は水の樹木は店で売っています。

• アズランの素材屋
• カミハルムイのギルド

まあ、アズランとかはほとんど行かないし、

ランプ錬金のギルドはラッカランにあるので、

カミハルムイにもほとんど行くことないし、

というわけで、実は水の樹木をあまり持っていません。


ついでに言うと、水の樹木が必要になった時は、

たいていバザーで特に調べもせずに買うので、

450G(通常は370G)で買うこともあったりします。

何に使うの？

ランプ錬金で水の樹木は何に使いますのん？

ということで使う錬金を挙げると以下のとおりです。

• 最大MP+10
  
  • 魔力の土 x 3
  • 水の樹木 x 2
  • 妖精の粉 x 5
• 最大MP+15
  
  • 魔力の土 x 8
  • 水の樹木 x 5
  • 汗と涙の結晶 x 10
  • 妖精の粉 x 15

通常ドロップ

どうにかならないものかと公式ガイドを眺めていたら、

通常ドロップするモンスターがいました。

伐採マシン改

です。

ん、あれ、こいつボスモンスターやん(´・ω・｀)

量産方法

クエストのボスモンスターなので、手順が必要です。

• 木陰の集落-アズラン地方側からモリナラ大森林に入る
• モリナラ大森林A-8にてクエスト109「森の断罪者」を再受注
• レンジャーから盗賊に転職する
• 木陰の集落-アズラン地方側からモリナラ大森林に入る
• モリナラ大森林A-5 森はずれのほら穴にてイベント
• モリナラ大森林A-6 モリナラ広場にて伐採マシン改と戦闘-水の樹木を入手
• 盗賊からレンジャーに転職
• 木陰の集落-アズラン地方側からモリナラ大森林に入る
• モリナラ大森林A-8にてクエスト109「森の断罪者」をクリア、グリーンアイ２個をもらう
• 2に戻る

なんだか、クエストなので非常にまどろっこしいですね。

一人でやっているとそれなりに時間を浪費します。

PT組んでやる

レンジャー⇔盗賊の転職が必要以上に無駄な時間であるため、

PTを組んでやるのがよいかと思います。

一回の戦闘時間は

• サポートの盗賊(レベル55くらい、攻撃力200程度)
• 僧侶(レベル55くらい)
• 自分(盗賊63、攻撃力200キラピ)

で、3分でした。

アズラン-モリナラ大森林への移動が約3分 x 2

イベントで4分

モリナラ大森林での移動が約4分x2

転職などでトータル4分くらい

なので、一人でやると水の樹木を一つ得るのに25分くらいかかりますが、

• 盗賊
• 盗賊
• 盗賊
• レンジャー

のPTでやれば、6分くらいは節約出来て、19分くらいでできます。

結論

あんま効率良くないな(´・ω・｀)

厨二病のみけ様、大変恐縮ですが、勤務時間は全社員共通の8時間が定時となり個別の調整は難しい状況です。

ソフトウェアの品質に関するサービスを提供している会社から

オファーが来たので、応募してみました。

やっぱり、うつ病であることを隠すのはよくありません。

だから事前にちゃんと伝えておきました。

その返信は以下のとおりです。

厨二病のみけ様

お世話になります。
株式会社hoge採用担当です。

この度はオファーへのご返信、誠にありがとうございます。
大変恐縮ですが、勤務時間は全社員共通の8時間が定時となり
個別の調整は難しい状況です。

大変残念ですが、ご了承いただきたく存じます。
また何か機会がございましたら、その際は何卒よろしくお願いいたします。


株式会社hoge
採用担当




> ソフトウェアの継続的インテグレーションに興味があるので応募しました。
>
> 【アピール】
> JUnit/Groovy/Gradle/Maven/Spock/Selenium/HP Quick Test Professionalのスキルがあります。
> また、JavascriptのテストをJavaで実行できるようなライブラリーの作成もしております。
>
> 【考慮頂きたい事項】
> うつ病のため長時間の勤務ができません。
> 勤務時間について調整願えますでしょうか？

やっぱり社会というのはうつ病を生産するくせに、

うつ病を排除するんですね。

結論

「ドイツ民族、即ちアーリア系を世界で最優秀な民族にするため」に

遺伝病や精神病者などの「民族の血を劣化させる」「劣等分子」を排除するT4作戦を実施した

ナチスドイツというのはその点では非常に優しい思想を持った国だったと思います。

厨二病のみけ様、ご希望にそえず申し訳ありませんでした

人身売買系のSI会社からオファーが来てたので、

面接の応募をしてみました。

ただ、うつ病だとか、腰痛持ちだとかの僕にも相手にも

不利な条件を隠して面接をするのは気が引けます。

そこで、先に希望条件を提示して、

叶えられそうなら面接するというスタイルで応募してみました。

返ってきた文面は次のとおりです。

厨二病のみけ様

下記の件で、Ａ．Ｃ．に関しては客先常駐になるためお約束できません。
申し訳ございませんが、面接はなしとさせていただきます。

オファーに対し返信していただきましたが、
ご希望にそえず申し訳ありませんでした。


> 第1希望：４月２３日　１３時スタート～１７時スタートまで
> 第2希望：４月２４日　１３時スタート～１７時スタートまで
>
> ★面接前に質問・相談したい
> A. 現在うつ病を患っているため
> (自立支援医療制度(精神)適用済み、障害者手帳申請済み、障害者年金申請中)
> (1)勤務時間を１１：００～１７：００（途中１時間休憩含む）とすることはできないでしょうか？
> (2)勤務地について、都内限定にしてもらうことは可能でしょうか？
>
> B. 僕はJavaの専門プログラマーです。
> (1)PHP、C#、F#の案件はやりません。
> (2)Windowsは開発生産性がわるいため、Macintoshでの開発を希望します。
> (3)eclipseは開発生産性に乏しいため、JetBrains IntelliJ IDEAでの開発を希望します。
>
> C. 腰痛持ちです。(過去にぎっくり腰を数回していて、くせになっています。)
> (1)アーロンチェアと言わないまでも、腰痛にならない椅子での勤務を希望します。
>
> D. キャリアパスについて
> (1)プログラマーの価値を向上させたいという思想で生きていますので、
> プロジェクトマネージャーや何もできないエス・イーというポジションにはつきません。
>
> E. プロジェクト管理について
> (1) Atlassian JIRAでのプロジェクト管理を希望します。
> (2) Atlassian Confluenceでのドキュメント管理を希望します。
> (3) Gitでのバージョン管理を希望します。(svn、cvs、vssは使えますが、希望しません)
> (4) JenkinsあるいはTeam Cityでのビルドを希望します。
>

なんだ、結局うつ病の人間なんて社会からいなくなればいいのにと

社会が言っているんですね。

結論 日本に在住する日本国籍を有するもので精神を患っているものは粛清されるべき

オフショアがダメだと思う７つの理由

厨二病を発揮中のみけことみけです。

昨日のエントリーいろいろな方にファボもらいました。

ついでだから、アマゾンアフィリのリンクからポチをしてください。

本題

オフショアが日本-東アジア圏ではダメだと思う理由をあげます。

日本語が特殊すぎる

日本語は特殊な言語で多分機械翻訳はほぼ無理です。

無理と言われていた将棋がプロ棋士よりも強くなるというのは、

現実化しつつありますが、

日本語を他の言語に置き換えるのはまだまだ先の話だと思います。

したがって、日本語で書かれた仕様書をオフショア先に届けても、

まあ、良い感じに解釈してくれないでしょうね。


解決策 仕様書をもっと数学的に記述すること

プログラミングの技術レベルが低い

まあ、インターネッツ様のお陰で、

プログラミングに関するhow-to的なものを検索することは可能になっています。


だけど、もっとメンテナンスしやすいプログラム、

読みやすいプログラム、安全なプログラム、

こういったプログラムを書くためにはインターネッツ様だけでは足りません。

『達人プログラマー』とか、『Thought works アンソロジー』とか、『ドメイン駆動設計』とか

こういった書籍で勉強する必要があります。

でも、インドネシアやベトナムといったオフショア先にある国で

書店を回ってみましたが、

こういった書籍が置いてあるところは皆無でした。


これが意味するのは、オフショア先で技術が向上しているといっても、

それはコピペをする能力が向上しているだけで、

プログラムを書く能力が向上しているわけではありません。

機械化に関する考え方

オフショア先というのは人件費はマジ安いです。

ベトナムだとおそらく日本人一人雇う金額で、

ベトナム人５人くらいを雇えます。


でも、ここに落とし穴があります。


マシンの値段はあまり変わらないということです。

日本でビルド専用の結構いいマシンを買うと、

人件費の５分の２くらいで購入出来ます。


でも、オフショア先では人件費の２倍かかります。


したがってなんでもかんでも機械化するということに関する情熱は、

金額的に考えて５倍の差があります。


言い換えると面倒くさくて時間のかかる作業も、

彼らは人力でやろうとするし、

機械化したら仕事取られちゃうしで、

機械化するのを嫌います。


でも、日本では機械化してないとやってられませんね。


というわけで、テストを書くとかそういう考え方がオフショアでは希薄です。

Jenkins？そんなのオレがやるから導入するなよっていう感じだと思います。

結論 オレ(オフショアのオレくん)がリアルJenkinsだ！

責任というかなんというか

これな。

僕はこれインドネシアと中国で痛い目にあっているんだけど、

なにかしらのうまくいかないことがあると、

日本人の責任にされます。


オフショア先では教えたことはやるけど、

教えたことの応用はできなく、

それをやらないことの責めは

日本人にあることになります。

結論 オフショアがうまくいかないのは日本人が悪いニダ

コスト的なこと

まあ、テストを書かないというのは前の前に書いたことですし、

コピペが多いというのは最初のあたりに書いたことですが、

ここからの結果として、こんなことになります。

不具合が発生した場合、

• 不具合箇所のきりわけ
• 不具合箇所の修正
• 不具合箇所の修正の確認

に膨大なコストがかかる。

で、コピペ技術のすぐれたオフショアプログラマー、

これらの技術はありません。

そこで！日本人登場ですよ！

日本人のエンジニアがこれらプログラムの森を進み抜き、

不具合箇所を修正します。


結論 日本人がプログラム書かないためのオフショアなのになんで日本人がプログラム書いてんすか？

トータルコスト

というわけで、コストをだいたいみてみると、

こんな感じになると思います。

ちなみにウォーターフォールを前提としてます。


モデル

計画

• 工数 : 30人月
• 開発期間 : 3ヶ月
• 開発体制 :
  
  • 日本人SE : 1人x3ヶ月(ブリッジSE兼PM) + 0.5人x1ヶ月(アーキテクトとか考える人)
  • オフショア : 10人x3ヶ月

結果

• 工数 : 30人月 + 30人月(日本人による修正)
• 開発期間 : 6ヶ月(バグ取りの期間を含む)

収支(便宜上、日本人1人月100万、オフショア20万)

• 予算 : 950万円
• 費用 : 3350万円

その他

• ブリッジSEの過労による精神障害の発生
• 納期遅延による顧客との信頼関係の喪失

というわけで

オフショアするなら、オフショア人員一人あたり日本人一人つけといたほうが安全です。

あれ、それってオフショアの意味なくない？


あと、7個も理由書いてないや…(´・ω・｀)

日本からプログラマ技術者がいなくなるそうです。

マイナビにプログラマーとして登録しているので、

いろいろとスカウトメールが届きます。

その中からお馬鹿なものがあったので、紹介します。

日本からプログラマ技術者が・・・・！?

突然のメールにて失礼致します。 株式会社■■　代表取締役の◯◯と申します。

私は大袈裟ではなく近いうちに日本からプログラミングの仕事がなくなる日がくるのではな
いかと考えています。理由は二つあります。

ひとつは、オフショア開発の増加です。インド、中国で注目され始めたオフショア開発ですが、
リーマンショック以降情報システム業界の仕事量が激減した年でも、その発注量は増え続け
ています。しかも、発注先もベトナム、フィリピン、ミャンマーと次々に広がっています。
もうひとつの理由は、セールスフォースに代表されるsaas環境の発達です。触った事のある人
であればわかると思いますが、ノンプログラミングで大概の事が実現できるのです。

このような環境下、あなたは本当に今のままのキャリアプランで大丈夫でしょうか？
■■では、会社として環境の変化に対応し、技術者がキャリアアップを重ねながら存在
意義を保つ環境を整えました。

いいですね、なにもできないプログラマーを駆逐するという考え。

僕もうつ病でダメ人間なので駆逐されたいです。

ですが、プログラミングする人は、
これからはますますちゃんと情報工学などの教育を受けた
人であるべきだと思っているので、
この人のようなプログラミングなんてしなくていいやという考えの人とは
僕の考えは合わなそうだったので、
丁重にお断り申し上げました。

以下、その文面。

馬鹿ですか？
無知・無学・無能で人を使い捨ての駒としてしか考えていない筋脳鬼畜馬鹿とは一緒に仕事できないので辞退します。

(1)オフショアについて

オフショア開発のブリッジSEの経験をしていますが、
オフショアで開発したプログラムのほとんどは日本で書きなおされます。
その理由は日本語という言語が、言語学的に特殊すぎて
機械翻訳が難しいためです。
そのためオフショア先では誤解を元に作成されたプログラムが量産され、
結果、日本人がプログラムを修正するという事例が多数発生しています。
したがって、どんなにオフショアにプログラム開発を依頼しても、
日本人がプログラムを修正するという作業がある限り、
プログラマーが不要になるということはありえないと考えております。
また、当初の見積もりコストの１０倍に膨れ上がったプロジェクトを
僕はいくつか知っています。

これらの原因となっているオフショア先のプログラム開発の能力については、
オフショア先となるアジア各国では、
プログラムをちゃんと書くための書籍類が不足していて、
(それは各国の通貨がドルに対して弱いため)
・リファクタリングが可能なコード
・変更に強いコード
・ちゃんとテストコードのあるコード
を書く能力が乏しいという事実があります。

実際に僕はインドネシアやベトナムの書籍店を回ってみましたが、
プログラミングに関する書籍は非常に少ないばかりか、
プロフェッショナルの使用に耐えうるような書籍はほぼ皆無でした。

オフショア開発で成功するための必要最低な条件は、僕の経験上以下の３つになります。
・時差が少ない
・言語間の壁が小さい(英語-スペイン語など)
・オフショア先でもプログラミングに関するちゃんとした書籍が入手できる
　- 10日でできるAndroidのような書籍は論外です。
　- マーティン・ファウラーなどの書籍のことを指しています。

上記の事実を勘案すると、東アジア圏ではオフショア開発が
成功するというのはほとんど不可能に近いです。

上記の条件を満たせるオフショア環境は今のところ、
US-ブラジルの間だけではないかと存じています。
実際、ブラジルでオフショア開発が成功したという事例はよく聞きます。

貴殿のプログラマー不要説がこれらの必要条件を精査した結果でのものと
思えるほどには説得力のない説明であったので、
貴殿が業界の勉強や実体の調査をおこなっていないと判断するに至りました。

(2)Google Apps、GeNexus、Salesforce等のプログラミングレスアプリケーションについて

これらの既存アプリケーションの組み合わせによる業務アプリ作成は、
フルスクラッチからの開発よりもかなり高速な開発を実現できるのは事実です。

しかし、Salesforceを僕よりもご存知であろうとおもいますが、
業務的に性格を期すアプリケーションを構築するためには、
(例えば受注が成立した場合に関係者にメールを送付して、
現在ある在庫を確保するという業務)
Google AppsではJavascript、
GeNexusでは独自のプログラミング言語、
SalesforceではJavaに似た独自のプログラミング言語
でのカスタマイズが必要になります。

これらはC、Java、C#等の低水準の言語で恩恵があったIDEのサポートを得られず、
入力補完が効かない、型安全でないという生産性低下の要因を抱えています。
入力補完がない型安全でないということは、
コンパイル時にプログラムが正しいことを証明できず、
実行時にエラーとして判明するため、
不具合箇所の検出、修正に多大なるコストがかかります。

C、Java、C#といった言語の場合、
見かけ上は開発コストがかかるように見えますが、
プログラミングレス言語に比べて、
バグ検出・修正コストを調整できるメリットがあり、
コストは大して変わらないと存じます。

以上二点から貴殿のプログラマー不要という考えには同意できかねるため、
本オファーを辞退させていただきたいと思います。

…どこが丁重やねん…(´・ω・｀)

社会に反抗する厨二病

個人と社会という二元論の立場を取ります。

社会に反抗する人を厨二病と呼んでいますね。

では、社会の側に立って社会に順応させる人のことをなんて言うんでしょうか？

社畜ですかね…

ドラクエ10 短剣使い旅芸人・盗賊のスカラベキング-タナトスハント狩り

こんにちわ

みけです。

おそらく神経性のアトピーが酷くて、

シャワー恐怖症になっています。

相変わらずお金が貯まらない

ドラクエ１０本当にお金が貯まらないですね。

まあ、過去の作品の場合は、

メンバー全員分の装備を整えないといけなかったので、

ゴールドは多めに設定されていましたが、

今作では自分の装備だけ整えればいいいので、

とにかくモンスターからもらえるゴールドが

少なめに設定されています。


あと、微妙に経験値が少なくて、

レベル５０になっても、

経験値３００程度のモンスターを

延々と狩り続けないといけません。


正直つらいです。

比較的お金を貯めやすい職業

ということで、旅芸人と盗賊はお金が貯めやすいように

なっています。

とはいえ、大して稼げませんが…

リューイーソー

まあ、おすすめはリューイーソーなんですが、

最近は混んできました。

代替モンスター

というわけで、やつの代わりになる新しいモンスターということで、

探してみると、

スカラベキング



（画像の著作権は、株式会社スクウェア・エニックスに帰属します）

が出てきます。

課題

こいつ、お金を持っているのはいいのですが、

いかんせん、硬い、痛い、生命力高い、の三拍子が整っています。

攻撃力２００程度では、一回の攻撃で与えられるダメージが

１６程度と残念なことになります。


というわけで、魔法使い様の登場になります。

不気味な光＋覚醒の後のメラミで、

大体３００～３５０程度くらい与えられるので、

９ターン(魔法使い二人なら４ターン)程度で

倒せます。


ただ、この方法の問題点は、

とにかくMPの消費が激しいこと。

スカラベキング一匹に対して、

覚醒(10)+メラミ(6)x9 = ６４ＭＰ

(魔法使い二人の場合は、一人あたり覚醒(10)+メラミ(6)x4 = ３４ＭＰ)

を消費します。


最近はＭＰ消費しないを20%くらいつけている人が多いので、

一回あたり結局５１(二人なら２７)くらい消費します。


最近の魔法使いはＭＰが３５０程度はありますから、

だいたい、７匹(二人なら１３匹)狩ったら、

宿屋に戻るという計算になります。


スカラベキングがいる場所は結構アクセスの悪い場所がおおいので、

まあ、時間がかかる割に、あまり稼げません。

そこでオススメなのが

短剣スキル100を持っている盗賊と旅芸人です。


スカラベキングは毒耐性を持っていないので、

ヴァイパーファングがよく通ります。


ヴァイパーファングで猛毒を与えた後は、

タナトスを叩いていくだけで結構倒せます。


ちなみに、攻撃力２４０程度でバイキルトがかかった状態での、

タナトスハントはスカラベキングに２００程度与えます。


なお、タナトスハントの消費ＭＰは３で、

ダメージを与えた場合、ときおりＭＰが回復します。


というわけで、あまりＭＰを消費せず、

(経験的には10も消費しない)

スカラベキングを狩り続けることができます。

参考

メンバー

• 旅芸人Lv55（自分：短剣100：王家のナイフまたはサラマンダー：攻撃力240）
• 旅芸人Lv55（サポート：短剣100：王家のナイフまたはサラマンダー：攻撃力240：バッチリ）
• 魔法戦士Lv50（サポート：杖：バッチリ）
• 僧侶Lv55（サポート：スティック：バッチリ）

自分の行動

• スリープダガー(バイシオン中の攻撃を避けるため/効かなかった場合は３回をめどにやる)
• バイシオン(to 僧侶(僧侶にも攻撃させて、僧侶のMPを回復させる))
• バイシオン(to 魔法戦士(魔法戦士にはロストアタックさせるため))
• キラーブーンx3～4(キラーブーンの与ダメは100程度)
• ヴァイパーファング(ヴァイパーファングの与ダメは80程度)
• タナトスハントx4(与ダメ200程度)

最初からヴァイパーファングでもいいですが、

途中で毒が切れてしまいます。

お怒りモードを少なくするために、

最初の方はキラーブーンを使っておくのがよいでしょう。

獲得

経験値 800 + 200
ゴールド 52 + 26(旅芸人の証装備)
時間 1分30秒くらい


トータル12ターンくらいかかりますが、

ＭＰをほとんど消費しないので、

何時間でも狩り続けられます。

(小ビンすら使わない)


また、魔法戦士が時折ルーレットでＭＰ回復するので、

自宅・宿屋に戻ることもほとんど必要ありません。

欲を言うと

小ビンを使っていいので、

効率を追求したいという場合は、

魔法戦士を盗賊にするというのも一つの方法かもしれません。

(盗賊の方はピオラ/ピオリム+盗むをやってください)

あと、肉入りであれば、

僧侶をユグドラシルスーパースターにして、ベストスマイルもありです。

豆

岩石落としが怖い攻撃ですが、

スカラベキングが自分の方に向かってきて、かつ距離をとっている場合が、

岩石落としの合図なので、

その場合はメンバーから離れましょう。


HPの残りが半分と1/4の時にお怒りモードになるので、

ロストアタックしてください。

お怒りモードの時の吸血でＨＰが回復してしまいます。

(守備力280程度で、120くらい吸われます。)

#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.～」などがあります。

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

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

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

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


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

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

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


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

入力画面だけでなくて、

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

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

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


赤字ですな。


まあ、今考えると、

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

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

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

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





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

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

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

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

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

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







最後に、

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

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

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

みけです。

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

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

ギリギリセーフ。

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

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


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

https://github.com/nobusue/GradleHandson


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

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

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

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

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

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

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

毛虫本

Gradle Effective Implementation Guide

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

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



おわり

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

みけです。

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

梅本洋一さん死去　「カイエ・デュ・シネマ・ジャポン」（朝日新聞デジタル） - Y!ニュース headlines.yahoo.co.jp/hl?a=20130312-… この先生にはお世話になったな…ご冥福をお祈りします

— (ΦωΦ)さん (@mike_neck) 2013年3月12日

梅本先生には大学の３年から４年の、

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

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


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

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

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


性格も気さくな方で、

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

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

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

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


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

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


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

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


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

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

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

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


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

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

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

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

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


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

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


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

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

みけですう。

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

僕の発表内容

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

gistのリビジョンでGroovyASTTransformationのAnnotation 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の構成要素は次の３つです(かなり端折ってます)。

• 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出てきてないしｗ

nobeansさんのGrailsの話

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

杉浦さんのGConstractsの話

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

懇親会

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

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


おわり。

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得られます。

IntelliJ IDEAでmethodを変更する

みけです。

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

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

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

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


変更前のコードです。







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

⌘ + F6を押します。





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








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






おしまい

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を選んで、まとめる。





できあがり。

IntelliJ IDEAでinterfaceの実装クラスに移動する

今日(2013/02/26)の18時までに13時間眠っていたミケです。

IntelliJ IDEAの記事を書きます。

eclipseガチ勢な人は読まないで下さい。

それとeclipseガチ勢なのに、むかついて僕に批判を投げてくる人も読まないで下さい。

しかもeclipseは無料で同じことできるんだよとか、

さも自分は社会一般に貢献してるアピールとか絡めて

批判するような輩ははやくこのタブ閉じて下さい。


今、僕に必要なのは、ガチ勢が求めるような

何が速いとか、何が正しいとか、何が真実かとかいう

ガチ勢のための心の安定剤ではなく、

僕のための自信です。

デバッグでインターフェースにたどり着いてしまったんだけど…

デバッグなどをしていて、

メソッドコールを辿って行ったらインターフェースにたどり着いて＼(^o^)／ｵﾜﾀとなる人は多いのではないでしょうか？

eclipseではそのような人のために、

コマンドがあるようです。

Eclipseで例えば↓のようなInterfaceをimplement

一方、その頃IntelliJ IDEAでは…

とりあえず、インターフェースにたどり着いてしまいました。




(実はabstract classでしたが…)


クラスの宣言の横に緑色の下向きの矢印のついたアイコンがあります。

それをクリックすると…





実装クラスの一覧が表示されます。

そのうちの一つを選択します。





実装クラスに移動出来ます。





かなり楽です。

今更Java7のmulti-catchとか… #Java6ネガティブキャンペーン

退院間近のみけです。

気分は落ち込みつつあります。(2週間ごとに波があって、今は下り坂)

Java7のmulti catchとか

まあ、Java7が発表されてから1年以上も経っているので、

今更Java7のmulti catchをIDEでどうすんのか悩んでいる人など

いるわけもないと思いますが…

(普通のIDEはもうJava8まで対応しているので、
今苦労するのはJava8の方だと思っています。)


IntelliJ IDEAはJava6のシンタックスで書いていたコードを

すぐ簡単にJava7っぽく出来ます。


とりあえず、Exceptionとか無視して書いたコード…





とりあえず、try()の部分をどうにかしましょう。

try()のところの赤線の範囲にカーソルを当てて、

⌥ + Enterを押します。





おもむろにAdd Catch Clause(S)を選択します。





なんんか、まだ赤いエラーが残っていますね。

最初の部分をどうにかしちゃいましょう。

factory.createXML…の部分にカーソルをあてて、

また⌥ + Enterを押します。





やっぱり、Add Catch Clause(S)を選択します。





なんか、catchのあたりがドドメ色(どんな色？？？)になっています。

僕は、IntelliJ IDEAの設定でエラーっぽい箇所をこういう色になるように設定しているから、

こんな色になっていますが、多分何も設定をいじっていない人は、

黄色の波線かなんかが表示されると思います。

(デフォルトはとっくに忘れた)


気持ち悪いのでなんとかしましょう。

catchのあたりにカーソルを合わせて、

またまた⌥ + Enterを押します。





ひとつしか選択肢がないので、あとはわかるな（ｒｙ。

Collapse 'catch' blocksを選択します。





あとは良い感じに握りつぶしましょう(ダメ)。





そうそう、メソッドにthrowsをつけるのも、

だいたいおんなじです。

⌥ + Enter → やりたいことの順番です。




簡単ですね。


まあ、簡単ですが、eclipseに慣れている人はeclipseの、

netbeansに慣れている人はnetbeansの固有の方法でやればいいと思います。

IntelliJ IDEAでassertThatをimport staticする一番ひどい手段

意識の高いエントリーがありました。みけです。

• [Java][JUnit][IntelliJ IDEA]IntelliJ IDEAでJavaのstatic import文に関する効率化設定をLive Templateで実現する
• Re: IntelliJ IDEAでJavaのstatic import文に関する効率化設定をLive Templateで実現する

僕は意識が高くないので…(´・ω・｀)

いつもassertThat(hoge, is(foo));ってのを書くときはこんな感じで書いています。

(1) asまで入力




(2) assertで一旦入力補完を完了する。




(3) Thatをassertの直後に付け加える。




(4) ⌥ + Enterして、「static import method」を選ぶ。




(5) org.junitのAssert.assertThatを選ぶ。




(6) static import された状態。




(7) actual value を入力した後に、 is と入力する。




(8) 変な補完がうざいので、esc を押す。




(9) is に括弧を付けて、括弧の中にカーソルを合わせる。




(10) ⌥ + Enterかまして、 static import method を選ぶ。




(11) Matchers.is を選ぶ(他にもいろいろ使えるMatcher が使えるため)。




(12) static import ができた状態。




(13) expected value を入力する。




(14) おもむろに、⌥ + ⇧ + F10 を押して、テストを実行する。




(15) はい完了。

結論

僕は実はあまりIntelliJ IDEAの設定をしていません。

カレットを行の終わり以降にも置けないようにするとか、
使っていない変数とかクラスとかに対してオレンジ色の背景にするとか、
怪しい式(SuppressUnwarnings)が必要な奴やシンプルにできるやつの背景を紫色にするとか

といった設定しかしていません。

でも、eclなんたらより快適にコーディングできるので、やっぱりIntelliJ IDEA様は素晴らしい。

ついでに言うと、テストでhamcrestとか使うんなら、

groovyのPower Assertを使（ｒｙ。