2014-04-26

クリフトの効かないザラキ連発に隠された秘密と真実


何してくれとんじゃい！！



この記事の対象読者


クリフトがボス相手に効くはずのないザラキを連発することを知っている
これを実際に体験している、または何のことか理解できる



ドラクエ４名物といえばコレ

病を得ず 柔のザラキなら効いてたかもしれない

なぜ、クリフトはボス相手に効くはずのないザラキを連発するのだろうか？
よく理由として挙げられるのは、次の２つである。



誤解１：ファミコンゆえAIが貧弱だった

正しくない。敵モンスターがボスかどうかを管理するフラグを見て、
ザラキが効かない相手だと判断することは簡単にできた。
あえてそうしなかったところに秘密がある。



誤解２：AIの学習過程をプレイヤーに体験させるため

一般的に知られる理由。ある程度正しい。
ドラクエ４のAIは、最初はメタルスライムに呪文で攻撃するも、効果がないことを学習し、
しだいに打撃中心の攻撃をするように行動が変化していく。

ク... クリフトさんは
AIの学習をプレイヤーに体験させるために
効かないザラキをとなえたッ！
そ れ も あ る ッ！
だが！ 彼が考えていること！
も う ひ と つ あ る ッ ！　まさか！　まさかそんな！
だめだ　そんなこと！



真実にたどり着くためのシンプルな質問

もしクリフトがザキを連発していなかったら、どうなっていたか？
クリフトがザキを連発することで、得をするのは誰なのか？



真実


クリフトは自らの意志で道化を演じている。



どういうことか？



ドラクエ４、もうひとつの名物


ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!


ギャアアアアアアアアアアア



レベルアップと無縁のドランにさえキレられるアリーナさん

このチンピラが　俺をナメてんのかッ！
何回教えりゃ理解できんだコラァ！
会心の一撃かましておきながら　
なんでスライムに当ててんだ　この…
ド低脳がァーーーーッ


アリーナはサントハイム王国の王女であり、
作中では他の王子などの跡継ぎは登場しない。
一粒種の王女が脳ミソまでも筋肉で出来ていると知られた日には、国はいったいどうなるだろうか？



どうすればいいのか？

アリーナを上回る圧倒的アホさを見せつけ、彼女の隠れミノの役目を果たすほかにない。
そのために、クリフトはどのような手段をとったか？
それこそが、全ドラクエ４プレイヤーの記憶に強烈に刻み込まれている、
あの効かないザラキ連発である。　
　
見事な政治手腕と言うほかない。



もっとも効果的な瞬間は？

たとえそれが世界の命運を賭けたラスボス戦であったとしても例外ではなく、
むしろラスボス戦だからこそ、効かないザラキを連発しなければならなかった。
しかし仲間のピンチは見逃さず回復呪文を唱えるという、ぎりぎりのバランス感覚は忘れずに、である。
　
見事な戦況判断能力と言うほかない。



それだけじゃない

クリフトは、サントハイムという国のために道化を演じざるを得なかった。　
しかし、理由はそれだけではない。ゲーム内に、クリフトがアリーナに思いを寄せる描写が登場する。
(リメイク版ではより顕著らしい)　

アリーナたんハァハァ

いち神官が王女と身分の差を超えて愛を伝えるなど許されることではない。
アリーナへの愛ゆえに、しかしかなわぬ愛ゆえに、
自ら進んで道化となることを望んだ結果があのザキ連発なのである。



当時のプログラマの話

「クリフトは作中において性能的に大変有用なキャラです。大抵のプレイヤーは彼のお世話になったでしょう。
その彼が世界よりもアリーナのためにザラキを唱える姿に、愚かであろうとも彼の魅力の一端を表現したかったのです。
キャラに人間味をもたせる、キャラが生きているというのはこういうことだと思います。」

ドラクエのキャラはかつてはほとんど喋らなかった。
その中でキャラの魅力を表現するために考えられたのが、あのザラキ連発なのだという。



一方で、回復系キャラとしてクリフトの影になりがちなミネアについてはこう語った。

「旅立ち直後の未熟者である勇者の盾となり、護り育てるのが彼女の役割です。
なので、中盤から終盤にかけて育っていく勇者との性能差を明確にする必要がありました。
それに、もしミネアが呪文やステータスで優遇されていたら、クリフトもあのような活躍はできなかったでしょう。」


このように、不要とも言えるほどの設定の細かさが、ドラクエ４のキャラにリアリティと魅力を与えているのである。




以上、この記事は嘘だ。



[ikemenium]イケメンを眺める ＞

2014-04-14

プログラマの生活を劇的に改善する、たったひとつのこと



本記事の対象読者

  • お酒が好きで、月に数回は飲みに行く。
  • 家でもプシュッと缶ビールなどを開けたりする。
  • 毎日眠い　疲れが取れない


え？ いやな予感がする？　だいたい話が読めた？
OK、OK、大丈夫。禁酒だなんて、そんなヤボなことは言わない。



改善したい問題点

  • 帰宅後にコードを書こうとPCにむかうも、ダラダラ脱線したり、
    寝落ちしてしまったりで一向に捗らない
  • アルコールの利尿効果で、就寝中にトイレのために起きることがある
  • 起床時刻のころは尿意を我慢して寝ているような状態
    (眠気が勝ってトイレに行くより寝ていたい)
  • 上質な睡眠とはとても言えない。遅刻ギリギリまで布団の中。朝食などとれるはずもない。



たったひとつの対策、それは……………

日々の習慣を変えようと思ったら、対策の実行しやすさ、継続しやすさが大切。
実行するのが大変だったり、面倒くさくて毎日継続することができないようでは、
よい対策とは言えない。
また、充分に低コストでなくてはならない。

それら全てを兼ね備えた、たったひとつのシンプルな答え、それは…………

ひとり酒をやめる。

これだけだ。

拍子抜けだって？　そんなの意味が無い？　無茶を言うな？　
たしかにそうかもしれない。

とはいえ、以下のメリットランキングを見て、自分ならどうするか？って考えてみるのは
それ自体にけっこう価値はあるんじゃないかと思う。




発表！メリットランキング

どれも魅力的なメリットぞろいだ。



10位：自由になるお金が増える。


帰り道にコンビニでお酒とツマミ、余計なものを買うだけで
あっという間に1000円前後の出費だ。
これを月間で足し算してみると１万円を軽く超える。

この習慣がなくなるだけで、自然と、不思議と、手元にお金が残るようになる。

「貯蓄のコツは、増やすことではなく、減らさないこと」が
実感としてわかるようになり、必然的に、ムダ使いをしなくなる。

そしてこれにより、１年で少なくとも１２万円以上のお金が貯まる。
(飲み会の頻度は減らしていないのに！)

その結果、 まとまった買い物ができるようになる。
個人的には、ひとり酒をやめたことで、今年の夏頃にはコレ↓に手が届く。
もちろん、技術書代にあてるというのも◎。


９位：人間関係に対して積極的になれる。


お酒を飲むのは誰かと一緒でなければならないので、誰かを誘って飲みに行くようになる。
情報交換や人間関係構築に役立つのはもちろんのこと。

それに何より、
あの子をデートに誘うための、もっともらしい理由のひとつになる。



８位：飲み会の後のムダ飲みをせずに済む。


「飲み会の後のムダ飲み」とは？………　
飲み会の帰り道、ちょっと飲み足りないな、もう一杯飲みたいなと思って
コンビニでビールを買って帰るも、
いざ飲んでみると体に染みこんでいかず、結局残してしまうこと。

あるいは、もったいないから無理して飲み干した結果、次の日調子悪い………
というパターンもある。



７位：コーディングへの集中力が明らかに増す。


缶ビールを傍らに置いてキーボードを叩いていた（またはニコニコ動画を眺めていた）
あの日々は脱線と寝落ちが日常茶飯事だった。（人間の屑。はっきり分かんだね）

この対策をとってからというもの、
脳ミソから湧いてくるコードの量と質とスピードが明らかに違う。

湧き出してくるものをエディタに書き留めないともったいないので、
いつの間にかコーディングに没頭している。




６位：時間を有意義なことに使うようになる。


ひとり酒は何も考えもなくとも、なんとなくできてしまう。

なんとなくの行動ゆえ、時間をムダにしているという実感を得にくい。
そこが怖いところ。

それに対し、ひとり酒をやめることで得た時間は、自らの意思で作り出した時間なので、
ムダにしてはもったいないという気持ちが働く。



５位：寝覚めが明らかにスッキリする。30分～１時間ほど早起きしても苦にならない。


時間を大切にする気持ちの芽ばえは、「目覚めのよさ」「朝の強さ」を強烈に後押しする。
もう少し早起きして、朝活してもいいかなと思えるレベル。

子供に朝食をとる姿を見せることができていない親御さんプログラマは、食育の面でもメリットがある。



４位：自分をコントロールする力がつく。


今日はちょっと飲みたいな、いやでもひとり酒はやめとこう、ということを繰り返すうちに、
自分をコントロールできていること、自制できていることの喜びがわかるようになり、
自信がつく。

意志の弱い自分に負け続けていた(無意識的に！)過去との爽やかな決別があり、
前を向いて毎日を過ごせるようになる。



３位：新しいことへのチャレンジ意欲が湧く。



習慣を変えるということを達成し、このメリット群を受けるという成功体験により、
次のチャレンジに意欲的になれる。

自分の意思で自分を変えられる人間になれる。　

変化に強いコンピュータの世界において、変化に強いプログラマは、
この先も仕事に困ることはない。



２位：使える時間が増える。 ちょっと信じられないくらい。



寝起きが改善されることと、就寝前の時間が有効に使われるようになることで、
１日あたり１時間の時間を作ることができたとする。(個人的にはもっとだけど)

これが　た っ た １ 年 間　積み重なっただけで、
365時間もの時間が生まれることになる。

365時間。

45人日。

２人月強。

２人月。自分のプロダクトを前進させるにはとても力強い数字だ。(*)
この習慣が２年、３年、５年、10年と続いていったらどうなる？　
ちょっと考えてみてほしい。

* あなたの仕事上の担当プロジェクト（遅れている）に、
　人員追加によってスケジュールを取り戻そうとする事態さえなければ。



１位：お酒が美味しくなる！！


これに尽きる。

ひとり酒をしないことによって、胃腸が万全の状態でお酒と料理にのぞむことができる。

お酒を美味しくいただければ、料理だってもっと美味しくいただける。

２杯め、３杯めのビールだって、新鮮なのどごしで飲み干せる幸せがそこにある。
そんなコンディションで参加する飲み会は、確実にこれまで以上に楽しいものとなる。



ちょっと待った

いいことばかり書いてあるが、本当にそうだろうか？

デメリットはないのだろうか？

以下に、ひとり酒をやめることのデメリットを挙げる。



デメリット





な に ひ と つ な い ！





勇気か、気まぐれか

あとは、自分の中に次のものがあるかどうかだ。
両方もっている必要はない。どちらか一つでいい。

  • 自分を変えようとする、ほんの少しの勇気　
  • ま、たまにはチョットくらいやってみてもいいか、という気まぐれ


どちらか一つさえもっていれば、最も困難な「最初の一歩を踏み出すこと」ができる。

最初の一歩さえ踏み出せれば、
なかば成功したといってもいい。

あとは変わっていく自分、自制心のあるオトナな自分、
継続する喜びを楽しめばいいだけだ。


じゃあ、いつやるか？　


いまでしょ。



継続するコツ

人間、ただ「悪い習慣をやめる」ことはけっこう難しい。だけど、
やめたい習慣を「他の良い習慣で置き換える」のは、
良い方法であり、効果が高い方法と言われている。

自分の場合は、ビールを炭酸水に置き換えることでひとり酒を卒業できた。

どうしてもビールを飲みたいときは、
まずワンクッションおく感じで、かならず炭酸水を飲んでから、というルールにした。

ほとんどの場合、これでお酒への気持ちは泡のように消えてしまう。フシギ。
(味のない炭酸水だとガブ飲みできてオススメ)



おわりに

いろいろ紹介してきたが、
もちろん、この記事には何の強制力もない。　

これを読んで、ひとり酒を卒業してもいいし、別に卒業しなくてもいい。

人間、そうそう気まぐれなんかも、おきるもんじゃない。


最後に２つだけ。
  • 10のランキングの内容は、すべて事実だ。
  • もしあなたがひとり酒をやめようと思ったなら、それはこの記事の影響などではなく、
    あなた自身の意志の力ということだ。



ましてや習慣化に成功したなら、
それはまぎれもなく、あなた自身の強さを証明している。


[ikemenium]イケメンを眺める ＞

2014-04-09

Googleの検索結果を目に優しくして、PC用メガネいらず！ [グリモンあり]


真っ白な背景はまぶしい

プログラマであれば、いつも使うエディタやIDEの背景色を暗めに設定している人は多い。
真っ白な背景色の画面を眺めているのはまぶしいし、
長時間の作業ともなれば目の疲れ、肩こりなどにつながってくる。

それゆえ最近だとPC用メガネなどを掛ける人も多い。
（ディスプレイの輝度MAXでPC用メガネを掛けている人と見るとツッコミを入れたくなる）

毎日Googleで検索するけど

しかし、毎日数十回と繰り返すGoogle検索、
あの検索結果ページは背景が真っ白だけど、そのまま閲覧している人って結構多いんじゃないか説。


目が、目がぁーーーーーーーーーーーーーーーーーー

やさし化


これならずっと見てても平気

GreaseMonkey

背景を緑色にする
// ==UserScript==
// @name        googleBackgroundGreener
// @namespace   google
// @description google検索の背景色を緑にする
// @include     https://www.google.co.jp/search*
// @version     1
// @grant       GM_getValue
// @grant       GM_setValue
// ==/UserScript==
document.body.style.background='#1D3018';
document.body.style.color='#eeeeee';
document.getElementById('taw').style.display = 'none';
document.getElementById('resultStats').style.color = '#eeeeee';
document.getElementById('hdtbSum').style.background = '#1D3018';
document.getElementById('topabar').style.background = '#1D3018';
var elem = document.getElementsByClassName('sfbgg');
for (var i = 0; i < elem.length; i++) {
  elem[i].style.background = '#1D3018';
};
var elem = document.getElementsByClassName('st');
for (var i = 0; i < elem.length; i++) {
  elem[i].style.color = '#eeeeee';
};
var elem = document.getElementsByTagName('a');
for (var i = 0; i < elem.length; i++) {
  elem[i].style.color = '#89C5EF';
};
var elem = document.getElementsByClassName('f');
for (var i = 0; i < elem.length; i++) {
  elem[i].style.color = '#eeeeee';
};
var elem = document.querySelectorAll('.r a:visited');
for (var i = 0; i < elem.length; i++) {
console.log("here");
  elem[i].style.color = '#eeeeee';
};

弱点

JavaScriptのセレクタでは、 :visited 擬似クラスでエレメントを取得できない。
(ユーザのプライバシー保護のため)
そのため、GreaseMonkeyにおいても、訪問済みリンクの色を変えることができない。
これは残念なところだが、目の疲れとどっちを取るかっていうところ。
個人的にはさほど不便はないので良しとする。

快適な検索ライフを！

[ikemenium]イケメンを眺める ＞

2014-04-07

書評：TeamGeek Googleによる、プログラマ版の「人を動かす」


どんな本？

プログラマ界隈では話題の本。
Googleのプログラマ達（すんげートンガってそう）を、どのようにしてチームにまとめ上げるのかを、
Googleの中の人が体験記として軽快に語ってくれる。
「人を動かす」のプログラマ版みたいな本、とも。納得。



家に着くまでが遠足 アウトプットするまでが読書

本を読む際は、ラインを引いたり書き込んだりとチェックしながら読み進めるようにしている。
本に対して能動的に向き合うことで、得た知見が脳ミソから抜けにくくなる。
さらに、こうしてアウトプットすれば、たとえ小学生並みの感想であっても自分の血肉になるだろうというところ。

そうして読み終えたときには20を超えるチェックがあったが、
その中でも、特に印象深い３点を紹介しようと思う。


１．途中の作業を見られるのは怖い。

人間は誰にも批判されたくないし、それが未完成のものならなおさらだ。

天才の神話は不安の裏返しなんだと思う。多くのプログラマは、
開始したばかりの作業を共有したいとは思わない。
誰かが間違いをみつけて、このコードを書いた奴は天才じゃないなと思うかもしれないからだ。
Benのブログを引用しよう。
「完成していないものを見られたら、なにか言われるんじゃないかと本当に不安だ。
細かいところまで見られて、バカだと思われないだろうか。」
でも、隠したらダメになる。

コードのこともそうだし、アプリ(web/ネイティブ)もそうだけど、
未完成の状態でチームメンバや、さらには世界中に見られるのは恥ずかしいものがある。
そんなことに囚われない勇気が必要。
とくに、プライベートで書いているコードだと、
完成したら公開するつもりで、未完成のまま飽きて放置なんてのは良くあるケース。



２．僕たちの経験では、メンドクサイ人は道端のウンコと同じ扱いをされる。

影響を受けやすくなれば、それだけ影響を与えやすくなる。
弱いところを見せれば、それだけ強い人だと思われる。
矛盾していると思うかもしれない。
でも、過去に一緒に働いた頑固な他人を思い浮かべてみればいい。
どれだけ説得しようとしても、自分の意見に固執するような人だ。
その結果どうなるだろうか？
僕たちの経験では、チームメンバーはその人を障害物のように「回り道」するようになる。

著者の優しさゆえか障害物、と抽象的に書いてくれているが、
要するにメンドクサイ人は道端のunkoと同じ扱いをされるよと言っている。
個人的には、自分と違った意見は考えの幅を広げさせてくれるので大変ありがたい。みんな頭いいなーって思う。
自分の意見が採用されればよし、採用されなかった不満は(っていう強烈なアレでもないけど)、そのままプライベートな開発のモチベーションになる。


３．彼が相談を持ちかけるのは、"君に" 問題解決をして欲しいからではない。 

"彼が" 問題解決するのを手伝って欲しいからだ。

チームメンバーがアドバイスを求めてきたら、問題解決のチャンスだ！
問題解決ならリーダーになる前に何年もやってきたので、
すぐに問題解決モードに突入してしまいそうだが、それはダメだ。
エンジニアが相談を持ちかけるのは、君に問題解決をして欲しいからではない。
彼が問題解決するのを手伝って欲しいからだ。

サクッと華麗に問題を片付ける様を披露し、ﾄﾞﾔｯ（｀・ω・´）
とやりたい衝動をおさえて、相手の問題解決を手助けする姿勢が大事だよってお話。
自分で問題解決の原因と方法を知っていればまどろっこしく思えるだろうけど、
答えを与えるのではなく、答えの導き方を教えることがチームを育てる。
これ、育児にも活かせるね。


また、本の中で、
悪い習慣を「やめる」ことはできない、良い習慣と「置き換える」ことならできる、
みたいな話が出てくるが、これについては↓の記事がわかりやすい。
何かをやめさせる時の考え方


費やした時間で、それ以上の時間を買えるナイスな本だと思う。
他サイトでの書評・感想は以下。

【書評】Team Geek ―Googleのギークたちはいかにしてチームを作るのか

「Team Geek」Google流 チームのつくりかた

HRTの原則 ～ソフトウェア開発はバーでしっとり語り合うように ～

Time to play the Role Playing Game – 書評「Team Geek」



amazonのリンクは↓。
アフィリエイトリンクではないので、マウスのボタンが凹んで戻らなくなるパワーでクリックしてOK。



[ikemenium]イケメンを眺める ＞

2014-04-04

[ハマりどころ] AndroidStudio+Gradle+Android Annotations

Android Annotationsとは

Javaによる記述を、アノテーションによる宣言に置き換えることで、
Androidのコードを短く簡潔にするライブラリ。
実装スピード、可読性、保守性の面でも嬉しい。ヽ(•̀ω•́ )ゝ✧
http://androidannotations.org/


インストールはこんな感じ

build.gradleにAndroidAnnotationsの依存関係を記述。
↓ページに全て書いてある。
http://www.jayway.com/2014/02/21/androidannotations-setup-in-android-studio/

  • buildscript.dependenciesにandroid-aptのクラスパスを追加
  • apply plugin: 'android-apt'の追加
  • apt.arguments.androidManifestFileの追加
  • dependenciesに apt "org.androidannotations:androidannotations:3.0+" を追加
  • dependenciesに compile "org.androidannotations:androidannotations-api:3.0+" を追加


build.gradleの全体像は以下のようになる。
JSONICとかAQueryのdependenciesはココでは無視してOK。

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.9.+'
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.2+'
    }
}

apply plugin: 'android'
apply plugin: 'android-apt'

apt {
    arguments {
        androidManifestFile variant.processResources.manifestFile
    }
}

repositories {
    mavenCentral()
}

dependencies {
    // Android Annotations
    apt "org.androidannotations:androidannotations:3.0+"
    compile "org.androidannotations:androidannotations-api:3.0+"
    // JSON manager
    compile 'net.arnx:jsonic:1.2.9'
    // AQuery
    compile 'com.googlecode.android-query:android-query:0.25.9'

    compile fileTree(dir: 'libs', include: '*.jar')
}

android {
    compileSdkVersion 17
    buildToolsVersion "19.0.0"

    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']
            aidl.srcDirs = ['src']
            renderscript.srcDirs = ['src']
            res.srcDirs = ['res']
            assets.srcDirs = ['assets']
        }
        instrumentTest.setRoot('tests')
        debug.setRoot('build-types/debug')
        release.setRoot('build-types/release')
    }
}


Gradle Syncを実行する。


External Libraries に androidannotatinos-apiができていればOK。


使用例

本家。ひと目で効果のほどがわかるナイスなトップページ

サンプルが簡潔でわかりやすい



ハマりどころ

AndroidManifest.xmlで宣言しているActivity名の末尾に _ をつける必要あり。
(MainActivity -> MainActivity_)
実際の動作の際は、アノテーションを解釈して自動生成した子クラス(_つきクラス)を実行することになる。

が、Activity末尾に _ をつけても、ビルドの際にそんなActivityクラスないよと怒られる。
Build -> rebuild project
File -> Invalidate Caches / Restart...
で解消。
また、子クラスを自動生成して実行することから、
privateなフィールドやメソッドはprotectedに置き換える必要がある。


onCreate()の代わりに@AfterViewsのアノテーションをつけたメソッドを初期化メソッドとして使用する。

onCreate()内で@ViewByIdのフィールドにアクセスするとNullPointerExceptionで落ちる。
@ViewByIdが効いていないのだろうか、設定ミスったかと思ったが、
以下のページに答えがあった。
http://code.google.com/p/androidannotations/wiki/LayoutAndViews




When onCreate() is called, @ViewById fields are not set yet. 
Therefore, you can use @AfterViews on methods to write code that depends on views. 







@ViewByIdのフィールドがセットされた後の初期化処理、

Viewに対しての処理を行ないたい場合は、@AfterViewsを使ってねということ。



つまり、@ViewByIdのフィールドに対しての処理を行なわないならば、

onCreate()内に書いてOK。



処理の流れとしては以下のようになる。

onCreate() -> @ViewByIdフィールドへのセット -> @AfterViewsのメソッド







滑り出しで躓いたが、コードが短くなっていく過程は楽しい。

Javaは記述が冗長でストレスフルな言語だと思うこともあったが、

逆にそれだけ短くする楽しさもある





[ikemenium]イケメンを眺める ＞














































          

        

          

        

2014-04-03


          

        










Gradle project refresh failed: A fatal exception has occurred. Program will exit.
























環境： windows7, Android Studio 0.5.3







Gradleプロジェクトをgit cloneしてAndroidStudioにインポートしたところ、表題のエラーに遭遇。







stackoverflowでも同様のエラーに困っている人がちらほら。







android studio 0.4.2: Gradle project sync failed error







An error when creating new project in android studio







ホームディレクトリ以下の.gradleディレクトリを削除するというのがいい手らしい。




    

  1. File -> Invalidate caches / Restart
    2. 

  2. Shutdown Android Studio
    3. 

  3. Rename/remove .gradle folder in the user home directory
    4. 

  4. Restart Android Studio let it download all the Gradle stuff it needs
    5. 

  5. Gradle build success !
    6. 

  6. Rebuild project.... success !
    7. 






試してみたものの依然として同様のエラーが出続ける。











結局、今回は以下を参考に解決することができた。



Gradle project sync failed - unable to launch JVM for daemon






File -> Settings -> Compiler -> Java Compiler -> Additional command line parameters


-Xms256m -Xmx512m
















File -> Settings -> Compiler -> Gradle -> VM Options 


-XX:MaxHeapSize=256m -Xmx256m

















無事、Gradleタスクが完了した。











[ikemenium]イケメンを眺める ＞


















































        

      









登録:
投稿 (Atom)