Posted on 2013年2月1日(金) 01:47
この前、家に着ていた男の子（小学校低学年）が、ずっとDSやりたい、DSやりたいって言ってました。
ずっとゲームばっかで親も困ってるらしい。
なんかなー。
やっぱDSやってる子供みると良くないよなぁって見えてしまう。
そこで僕の持っているNintendoDSと3DSとPSP2台,PS Vitaをおもむろに取り出し、
ゲームは子供がするもんじゃないよ、大人になったらやり放題だよ って見せてやりました。
ゲームは大人の嗜みですよね。
Posted on 2013年1月30日(水) 21:41
Windowsファイアウォールの設定ミスなどでネットワーク機能が機能しない場合に、ユーザー様に簡単に確認してもらう手段が少ないので、アプリを探してみました。
例えば以下のアプリでiPhoneから、PC(Windows等）へのTCP接続が可能かどうか確認できます。
この記事を書いた時点では無料でしたが、変わる可能性もありますのでよくご確認ください。（同機能のアプリは他にもありますが、分かりやすそうだったものを紹介します）
＜使い方＞
右上の＋ボタンをタップしてグループを追加します。名前はなんでもいいです。
グループを作成したら、その中のビューでもう一度＋ボタンをタップします。
以下のような画面になりますので、必要な情報を入力してください。
Name・・・任意の名前
Host・・・接続先のパソコンのIPアドレス（調べ方は下に書きます）
Port・・・確認したいポート番号。(ComicGlass Sync&BackupServerであれば49728）
保存したら右下の更新ボタンをタップして、アイコンが緑色のチェックになれば接続出来ています。接続できない場合は赤い×マークになります。ネットワークの設定を確認してください。
ほとんどの方はパソコンのIPアドレスをDHCPで自動設定していると思いますので、アドレスの調べ方を以下に書いておきます。
＜パソコンのIPアドレスの調べ方(Windows)＞
（方法１）コントロールパネル→ネットワークと共有センター→（左の一覧から）アダプター設定の変更→利用しているアダプタをダブルクリック→詳細(E)…→IPv4アドレス
（方法２）コマンドプロンプトでipconfigと打つ
＜パソコンのIPアドレスの調べ方(Mac)＞
システム環境設定→ネットワーク→使用しているネットワークを選択し、状況の部分を見てください
Posted on 2013年1月24日(木) 23:32
たとえ話です。
とある部族は、旱魃（かんばつ）が起きると雨乞いのための儀式を行います。
この儀式は部族に古くから伝わるもので、これまで数々の旱害から人々を救ってきました。
さて、現代人には当たり前ですが、ふつう、人間の儀式くらいで雨は降りません。
つまり、儀式は天候に何の影響も与えないはずです。
しかしながら、この部族の儀式の成功率は１００％であると言います。
何故でしょうか？
答えは簡単です。
雨が降るまで儀式を続けるのです。
途中で誰かが死のうが、絶対に続けるのです。
そうすると、いつか雨が降ります。
儀式は成功します。
努力をします。
努力とは全く無関係な幸運によって、成功したとします。
努力は報われました。
努力をします。
しかし努力の量とは無関係な不運によって、成功しませんでした。
努力が足りませんでした。
もっと努力を続けて成功させるべきですね。
そうすれば、いつかきっと報われるはずです。
というわけで、「努力は報われる」というアドバイスは論理的に破綻しており、意味がありません。
「どのくらい」努力をすると、「どのように」報われるのか定量的に示さない人の言うことは聞く必要ありません。
Posted on 2013年1月24日(木) 00:23
学校の成績などで相対評価（つまり偏差値）が使われることがよくありますが、あれは成績の出現が正規分布になることを期待しているわけです。
しかしながら人の意思が働くような事柄では正規分布にならない事の方が多いということが知られており、実際に試験の成績分布は正規分布にならないそうです。
（なので相対評価は問題であると唱える人もいます）
それでは先天的な才能（もしくは物心つくまでに身につけた能力）の出現は正規分布に近似できるのでしょうか。
先天的な才能には人の意思が入る要素が（ほとんど）ありません。才能の違いはまさに多数の因子の和であり、遺伝子の誤差とも言えます。そのような仮定をすると才能は正規分布で出現することになります。
（独立な要素の和は正規分布になります。＝中心極限定理）
仮に才能が正規分布に従うとしましょう。
世の中には天才的な才能を持つ人がいます。
分散±３σに収まる割合は99.73%です。
500人に一人は平均値＋3σを超える才能を持つわけです。
（そして同時に平均値－3σ以下の才能を持つ人間もいるということになります）
「努力したら報われる」は結果論でしかありません。
せっかく努力をしても才能に恵まれず報われないことはよくあります。それが徒労としか言えない結果になることもあります。
人はその徒労への恐怖があるからこそ努力できないのです。
仮に自分が＋２σの才能を持っているとすると、それは全体の５％未満のすぐれた才能です。きっと自分は優れていて、努力すれば報われると思えることでしょう。
しかしながら更に平均から倍も離れた＋４σの分布に入る人も約0.006%存在します。
１億人の人がいたらその中に6340人もいることになります。
才能がなくても人並み以上の努力でカバーできるという主張は、努力で埋められる値の方が才能の分散σよりも十分に大きいと言っていることになります。
もちろん分野によりますが、経験的にそれは正しくありません。
「自分には才能がないから努力しない」というのは殆どの人にとって正しい選択です。
徒労への恐怖は当然の感覚であり、合理的な判断に基づくものです。
努力が徒労にならない場合、それは努力自体が楽しい場合です。結局好きであることが最大の才能なんですね。（というよりは、才能があってうまくいくことは楽しくできるんですね）
我慢してまで何かをやる必要はないと思ってます。
それは徒労になる可能性が高く、声高に努力を薦める人は無責任な人で、徒労の損害を補償してくれません。
どうせなら好きなことを努力しましょう。徒労になる心配がないので。
Posted on 2012年12月20日(木) 15:47
結論からいうと例によって公式な方法は無いようです。
BluetoothキーボードからUITextFieldに文字を入力できますが、直接キー入力を取得するには以下の非公式な方法で可能なようです。
非公開メソッドを使ってしまうので何かとやっかいです。。
まず、UIApplicationに来るイベントを監視します。
UIApplicationのsendEventをオーバーライドするとアプリケーションに色々なイベントが飛んでくるのが見られます。
UIEventの非公開メソッドである_gsEvent:で得られるポインタが指す、正体不明なデータを監視してみると、なんか入ってます。仮に32bit単位読んで先頭を0番目とすると、2番目にキーを押したかどうか、12番目に修飾キーの情報、15番目にキーコードっぽいものが入っているのがわかります。このコードは何なのかは不明な値ですが、とりあえずキーに対応した固有の値が入ります。他にも[17]番目はアスキーコードっぽいのが入るみたいです。
アローキーやファンクションキーなどの特殊キーも取得できます。
シフトキーやコントロールキーが押されたかどうかは12番目の値を見るとビット和で入っています。
詳しくはサンプルプログラムを作りましたので見てみてください。
https://github.com/rhotta/iOS_bluetoothKeyboardInputSample
普段は編集することのないmain関数を編集します。
UIApplicationMainの第３引数に独自クラス名を指定するとUIApplicationをオーバーライドできます。
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, @"MyUIApplication", NSStringFromClass([AppDelegate class]));
}
}
Posted on 2012年11月6日(火) 23:48
URLをパーセントエンコーディングするとき、stringByAddingPercentEscapesUsingEncodingを使ってはいけないという記述をよく見ますが、用途次第です。
このメソッドは「$&+,/:;=?@」をエンコードしてくれません。
しかしこれが逆に必要な時もあって、具体的には非アスキーなURLをエンコードする場合です。
例えば以下のようなURLですね。
http://exmple.com/日本語/index.html
このURLはこのままだとNSURLなどに渡せません。
日本語部分をエスケープする必要があります。
しかしながら「/」や「:」までエスケープしてしまってはURLでなくなってしまいます。
stringByAddingPercentEscapesUsingEncodingはこのような時に使います。
「$&+,/:;=?@」は日本語まじりの場合でも必ずエスケープしないとURLの構成要素と区別がつきませんのでエスケープされているが、その他の非ASCII文字はエスケープされていないというような場合に利用できるわけですね。
どこで出現するかと言えば、NSURLConnectionなど使って通信しているとホスト側からリダクレイとされたりしたときに返ってくることがあります。
Posted on 2012年10月16日(火) 23:06
iPhone5とiOS6の地雷原から未だに完全に抜け出せていません、こんにちは。
しかしながら、ようやく解決の目処がついてきております。
iOS5.0のときほどではないにしても、今回もギャンブル性が高いアップデートでした。
なにせ解像度が変わることが正式に発表されてから2,3日以内にsubmitしないとiPhone5の発売に間に合わないというスケジュールでしたからネ。
次はiPad miniの噂も出てきていますがどうでしょうか。
電子書籍ビューアにとっては少し小さいタブレットは理想的だと思いますので、もし本当に発売されるのであれば、また地雷原が広がっているとしても果敢に早期対応する意気込みではあります・・。
iPad Retinaの時も実機が手元に来る前にアップデートしましたからね！
（この時は奇跡的？にうまくいきました）
Posted on 2012年5月14日(月) 00:49
今やiPhone＋色々なカメラアプリで味のある写真が気軽にtwitterなどに投稿できる時代ですが、敢えて変な事をしてみる人がいるのも世の常。
という訳で、なんとなくフィルムで写真を撮影してみるってことをやってみる事にしました。
父が持っていたRollei35というカメラがあったのでそれで撮影してみました。
このカメラ、近年のデジタルカメラに比べると非常に面倒です。
まずフォーカスがマニュアルです。
それは当然なのですが、レンジファインダーでも一眼レフでもなく、人が距離を判断しないといけません。
被写体まで３メートルくらいかな？ と目測した上で「３ｍ」と書かれたところに目盛をあわせるというピント調整方式です。
でもそんなのよく分からないので被写体までの距離はレーザー距離計で測距しました。
無駄にセンチ単位で測れます。
いったい何やってんだろうって思いますが気にしないようにします。
こちらがモノクロネガフィルムで撮影したもの（をスキャンしたもの）です。
まぁ、とりあえず写ってはいるようです。
Rollei35は小さくて良い感じなのですが、レンズが暗く、何よりもピントが合ってるのかどうかよくわからないってことで、もう一台、どうせならって事で、機械式カメラ（シャッター時間などが機械式に制御される）を入手してみました。
Nikon F2というカメラです。
当時の高級機種ですが、ヒット作なので大量に市場に流通している（と思う）
このカメラ、一眼レフなのでフォーカスはバッチリ合います（たぶん）。
しかし、露出がやっぱりマニュアルです。
さらに露出計もありません。
「今日は晴れてるし、正午だし、こんなもんの明るさかな？ じゃあ絞りとシャッターをこんなものにしよう。」
・・・ってやるわけですが、そんなの僕に判るわけありません。
しかも結果は現像してみるまでわからない。
こりゃなんとかせねばって事で登場するのがiPhoneですよ。
iPhoneのカメラの露出制御値から被写体の明るさを逆算して露出計の代わりにしてみました。
左は検証用の露出計です。最初からそれ使えというツッコミはなしで。
（このアプリはちゃんと完成させて公開予定！）
上記iPhoneアプリによる露出計算とリバーサルフィルムで撮影した結果がこちらです。
（スキャナが不調なため、フィルムをデジカメで撮影）
リバーサルフィルムはラチチュードが狭い（ダイナミックレンジが狭い）ため、露出がぴったり合っていないとイケナイと聞いているので、この結果はちゃんと露出が取れてると考えていいでしょう。いいですよね。
被写体をみつけたら、iPhoneのカメラを向け、露出を計算し、フィルムで撮影、現像を行い、出来上がったフィルムをデジタルカメラで撮影する・・・・。一体自分が何やってんのかよくわからなくなってきましたが、まぁ楽しいです。
Posted on 2012年4月30日(月) 22:22
前々からちょっと書いていましたが、新しいアプリをリリースしました。
そもそも、ComicGlassの開発するために子どもを寝かしつけてから時間を取っていたのですが、子どもと一緒に寝てしまうんですよね。
この「子どもと一緒に寝てしまう」問題は多くの親が「そうそう！」って頷く問題なわけですが、それをなんとかしようというアプリです。アプリ名は「添い寝アラーム」です。
スクリーンショットはこんな感じ。
まず、最初にやったのは「暗闇でも止められるアラーム」です。
普通のアラームアプリは画面を見て止めますよね？
あれだと、もしまだ子どもが寝ていなかったりするときに画面を点灯させなければならないのが困るのです。
そういうわけで、加速度センサを利用し、iPhoneを軽く叩くとアラームがスヌーズになるアラームアプリを作りました。
しかし、これでやってみるとアラーム時間を何分後くらいに設定すればいいのかが難しい。
絵本を読み聞かせている途中になってしまったり、まだ子どもが起きていてしゃべっている最中や、ゴロゴロ転がっている（子どもはよく動きます）途中にアラームがなってしまったりします。
そこでアラーム時間の自動設定方法の開発に取り組みました。
使えるのはマイクと加速度センサ。
連日データを収集し、毎秒どのくらいのデータを取得し、どのように信号処理したらいいのかを試験しました。
少しでも楽に使えたらいいなーと思いながら毎回すこしづづ改善をした結果、それなりに良い感じになってきたので、本格的にアプリにしてみました。
（最初に時点では完全自分用で公開するつもりはなかったのですが）
最終的に、iPhoneの接近センサー、バイブレーター、マイク、スピーカー、加速度センサ、と、かなり内蔵デバイスを多く使うアプリになりました。
技術的な話をすれば、普通じゃありえないような頻度でAudioSessionを切り替えていたりと色々勉強になりました。
簡単に書きますと、
まずAudioSessionを切り替え、マイク入力を有効にします。
AudioSessionInitialize(NULL, NULL, NULL, NULL);
UInt32 category = kAudioSessionCategory_PlayAndRecord;
AudioSessionSetProperty(kAudioSessionProperty_AudioCategory,
sizeof(UInt32),
&category);
AudioSessionSetActive(YES);
それで音声をモニタリング。
加速度センサは60Hzで取得して微分して使っています。
音声と加速度の認識処理の部分は説明できないので省きますが、完璧な検出はやはり無理なので、アラームタイミングを長くしたり短くしたりすることでだいたい目的の動作が得られるようになっています。
アラームタイミングになると、オーディオセッションをマナーモードでも音が出るようにPlaybackに切り替えてバイブレーターを鳴らします。
（録音モードのままだとスピーカーの音量が自動的に抑えられてしまうというのもあります）
もう一つ苦労したのが、スヌーズのやり方です。
iPhoneを軽く叩いた事を検出すればいいだけなので一見簡単そうなのですが、同時にバイブレーターが動作しているというのが問題でした。
iPhoneを置いている場所（の硬さ）によってバイブレーター→謎の伝達関数→加速度センサの値が全然違うんですよね。
そこで、最初の一定時間は「謎の伝達関数」を推定する処理を行い、その後軽く叩いた動作を検出するようにしています。
最初の着想は簡単だったのですが、調整がとにかく大変でした・・・。
子育て中で、「寝てしまう！」問題にお困りの方がいらっしゃいましたら是非お試しくださいませ。
↓こちら
Posted on 2012年4月26日(木) 12:31
iOSでは通常の画像(image.png)と、解像度が倍のRetina用画像(image@2x.png)を両方用意しないといけませんが、すごく面倒です。
そこでimage@2x.pngを入れるとimage.pngを自動生成するアプリケーションを作ってみました。
奇数の大きさを持つファイルや@2xが名前についていないファイルは何もしません。
また、既にファイルが存在している場合は上書きします。
縮小は４画素を平均して１画素を作る方法で計算しています（画素平均法）。
輝度の端数は切り捨てです。
png画像のみ対応。需要があればjpegも対応しますが、ひとまずこれで。
何かありましたらコメントかtwitter(@rhotta)までお願いします。