「Error while running zipalign: Unable to open as zip archive」とか出た・・・
ADTさんとは今まで上手く付き合ってきたのに、アプリを更新しようと思い立ってコードを修正してさぁ後はAndroid toolsから認証付きでエクスポートすればオシマイというところまでこぎつけた時に、突然下のようなエラーの宣告が・・・
よく解らなかったのでeclipseを取り敢えず再起動してみたが効果なし・・・
仕方がないので前例が無いか調査（という名のネットサーフィン）
オオッ結構引っかかるなandroid - Error while running zipalign - Stack OverflowとかAndroid app won't launch unless project dir name equals app name » Community Questions & Answers » Appcelerator Developer Centerとか結構ひっかるじゃん余裕じゃんとか思ってた時期が私にも有りました。
が・・・駄目っ・・・困った・・・
なんでこうアプリをアップデートしなきゃいけない時に限ってこういう目に合うのか・・・
ハイハイ解ってますよSDKのアップデートもですよね！
と思ってアップデートしようとしたらこのザマですよ・・・
えっ？いやいやいやいやｗ API17そもそも入れてませんから！
なんで有る判定になってるの？意味がわからないよ！
SDKのアップデートは前にも失敗していたのでもうトラウマ級ですな
どうでも良くなってDownload Android Studio and SDK Tools | Android Developersをダウンロードしてきてもう一度環境作った！
もうね、eclipseとかAndroidでエラーが出た時って捨てて環境作りなおしたほうが速いね・・・
あともう一言言いたいことがある。
なんでリンク先のSDKは古いのが入ってないのか・・・
Raspberry piさんがフリーズするので対応
外からssh経由でアクセスをかけようとした時に、なぜだか反応しない瞬間が結構あった。
家に帰って確認してみるとLANポートが光ってない！(@ _ @)
LANケーブルを抜き差ししても駄目でこれは壊れたのかと一瞬目の前が真っ暗になりかけたのですが、
電源を抜き差ししたら復活したのでこれで一安心ε-(´∀｀*)ﾎｯとか思ってたら、しばらくするとアクセスが出来ない！
という事態の繰り返しになってました。
で、気がついたのは重い処理を投げている時によく落ちてしまうということでした。
例えば、rubyで1000000000回putsするだけのプログラムを走らせてみたり、apt-get でinstallをしたりすると落ちる。
これはひょっとして熱暴走かな？と思いアイネックス チップ用マルチヒートシンク HM-17
を購入して貼り付けた。
因みに貼りつけた状態でも純正のケースに入れるとフリーズします・・・
むき出しだとフリーズしません。
ケース買うんじゃなかったなーとかこっそり思ってしまってます・・・
そのうち時間ができたら錐とかで穴あけてファンを導入しようと画策中。
そうしたらもっと安定するに違いないし、せっかくファンレスなのに申し訳ないけど安定の方が大事だったりする。
追記
やっぱりヒートシンクだけじゃ駄目だったみたい・・・早いうちにファンを付けるかもっと大きなヒートシンクに変えないとだめみたい・・・
herokuでbranchをアップロードした時に"Pushed to non-master branch, skipping build."が表示される・・・
herokuにbranchをアップロードした時に
Pushed to non-master branch, skipping build.
みたいなメッセージが表示されて、buildされない場合の対応策は、【Heroku】master以外のブランチで動かす - ふわふわRuby on Railsに書かれている通り
$ git push heroku yourbranch:master
でOK。エラーメッセージでググった時に出て来なかったので書いた。
JINS PC買ってみた。
いまさらになるのですがJINS PCを買ってみました。
ブルーライトを防ぐということでブルーライトヨコハマを再生してみましたが、普通に見れました。
どこらへんがブルーライトなのかわからなかったのが原因かもしれません。
因みにフレームですが、同期とかぶってしまったためもっぱら家で利用することにしています。
ブルーライトを遮るメガネなのでせっかくなので青にしたのにまさかかぶっているとは予想外でした。
しかし、家ではいつもつけているのでメガネがない状態でPCのディスプレイを眺めていると非常に眩しいです。
なので早急に外出先で使う用のスペアが必要になってます。
効果は、付けてると感じない外すとすごく眩しいです。
因みにメガネかけるよりディスプレイにシートはったほうが圧倒的に満足度が高いと思ったのはないしょ。
モンティ・ホール問題は実装してみれば感覚的に解る！
モンティ・ホール問題ってみなさん知ってますか？
簡単にまとめると、
三個の箱があって1つだけあたりがあります。残りの２つは外れです。
あなたがその内の一つを選択した時に残りの2つのうちハズレを一箇所教えてもらえます。
そして司会者が最初に選んだものを本当に選択しますか？それとも、変更しますか？
という質問をされた時にあなたは、選択したものを変えたほうがいいのか？買えない方が良いのか？という問題です。
さて、ではコレを実装して検証して見ることにしましょう。
こちらがそのRubyのコードです。
# -*- coding: utf-8 -*- #アドバイス付きの選択 def select_use_advise(array, index) !check(array,index) end #当たり判定 def check(array , index) array[index]==1 end hit_not_change = 0.0 hit_change = 0.0 iter=1000 array =[1,0,0].shuffle iter.times{ array.shuffle index = rand(3) if(check(array,index)) hit_not_change = hit_not_change + 1 end if(select_use_advise(array,index)) hit_change = hit_change + 1 end } puts "変えなかった場合 : "+hit_not_change.to_s+" 確率 :"+(hit_not_change/iter*100).to_s+" %" puts "変えた場合 : " + hit_change.to_s+" 確率 :"+(hit_change/iter*100).to_s+" %"
紆余曲折を経てコレぐらい簡単になりました。
因みに実行結果は以下のとおりに。
変えなかった場合 : 318.0 確率 :31.8 % 変えた場合 : 682.0 確率 :68.2 %
皆さんが気になるのはコード内でアドバイス付きの解答の部分ではじめにハズレを選択していた時に、かならず当たるという形式をとっているところだと思いますが、これは至極当然ではじめに選んだものが外れていればハズレが開いているので絶対に当たり、はじめに選択していたものが当たりだったら選択肢を変えたら外れてしまうという可能性しか無いのです。
そしてはじめに選んだものは1/3で当たりなので、選択肢を変えた場合1-1/3=2/3となり選び変えたほうが絶対にいいと思う。
(間違ってたりした場合は連絡をいただけると助かります。)
Raspberry piさんにRailsインストールしてびっくりした話
aptitudeでrubyをインストールしてrailsをインストールしようとしてあまりに遅かったのでtimeコマンドで計測してみた。
結果はreal97m49.652sで大体1時間半。
皆さん予測ついてると思いますが、--no-ri --no-rdocを付け忘れました・・・
気がついた時にはどうすることも出来ずぼーっと眺めていました。
にしても遅い！SDをもっとはやいのにしたらいいのかもしれないけどお金ないっす・・・
でも、これでも家につなぐためのsshサーバぐらいなら何とかなりそうだしなぁ・・・
アプリケーションサーバにするのはかなり頑張らないと難しいかもね〜
アリアンロッド2Eのクリティカルの確率を（力技で）試してみた。
最近TRPGを始めました。
その中でもアリアンロッド2EというTRPGをやっているのですが、TPRGに必須なダイスを振った時にダイスがどれだけあったらどのくらいの確率でクリティカルになるかを（力技で）考えてみました
そもそもクリティカルの仕様は
振ったダイスの中に6の目がふたつ以上あった場合は、その判定は自動的に成功となる。これを[クリティカル]と呼ぶ。(アリアンロッドRPG 2E ルールブック①P191より)
というわけでサイコロが2個以上の時に6の目がどれだけあるかを調べれば良いと・・・
というわけでrandを使って試して見ることにした。
def check(time,dice_num) count=0 time.times{ dices = Array.new dice_num.times{ dices.push(rand 6) } dices.delete(5) if(dices.length < dice_num-1) count = count + 1 end } return count end #試行回数 time = 100000 10.times{|dice_num| dice_num = dice_num + 2 count = check(time,dice_num) puts "dice = "+dice_num.to_s+" probability:"+(count.to_f/time.to_f*100).to_s+"%" }
いま見てみるとちょっと（というかかなり）微妙なコードだけど・・・まぁいいや。
checkの中でやってることはサイコロを生成して6の目(プログラムでは0~5が生成されるのでプログラムでは5)を削除して長さが2以上減ってたらクリティカルと考えて実装した。
実行結果は
dice = 2 probability:2.777% dice = 3 probability:7.175% dice = 4 probability:13.186% dice = 5 probability:19.732% dice = 6 probability:26.445% dice = 7 probability:33.046% dice = 8 probability:39.604% dice = 9 probability:45.762% dice = 10 probability:51.397999999999996% dice = 11 probability:57.028%
という形になった。アリアンロッドではフェイトというシステムがあってサイコロを増やすか、もう一度振り直すか選択が出来るんだけど、この結果から4個以上ある場合は普通に振りなおしたほうが効率がいいんだろうな。
とここまでやって数学的にやってらっしゃる方のページを見つけたので哀心よりお悔やみ申し上げます 真・アリアンロッドのクリティカル率比較してみるとやっぱり乱数のせいで正確な値ではないものの、ちゃんと近似値は出ていた。
こんなかんじで日常で書いてるコードを晒していこうかな。
