ゆとりさんが鮨を奢ってくれるそうなので、感謝の気持を込めて、たくさんのプロセスに「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パサーしない(無駄だから、無駄な奴は苦しめ)
• もう敵を倒しかけたなと思ったら、次の敵に向かって移動を開始する
• ヴァイパーファングで猛毒で毒で倒す
• チャットでありがとうを「あｒ」、おめでとうを「おｍ」で済ませる(キーボードうつの面倒い)

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