点と閉じた図形がある。

点が閉じた図形の内部にあるかどうかを判定する関数、
閉じた関数を長方形とすると、
RectContainsPoint(Rect rect, Point point);
となるが、これの判定は

point.x >= rect.x1 && point.x < rect.x2 &&
point.y >= rect.y1 && point.y < rect.y2;

となる。


不等号にイコールの付く・付かないは、上記のように
>= x1(y1)
< x2(y2)
とする。

大きさのない図形(長方形ならx1=y1=x2=y2=0など)を渡したとき、内部にはいかなる点も含まないとするため。
例えば未初期化図形rectZero(x1=y1=x2=y2=0)と未初期化点pointZero(x=y=0)があるとき、これらをRectContainsPoint()に渡して真が返ってきてしまうと、期待と反するからだ。

ボタンが決まっているハードデバイスの場合、1ボタンを1ビットに対応させ、isOn(BIT_BUTTON1 | BIT_BUTTON2)
getOn() & (BIT_BUTTON1 | BIT_BUTTON2)

のようなコーディングをすることがある。

が、iPhoneのような全面タッチパネルでバーチャルボタンを作るようなデバイスの場合、こういうやり方ができない。

まずボタンの数が決まっていない。ビットに置き換えるためには上限数が見えていないとできない。
状況によって、自由にボタンを増やしたり減らしたりできるのがバーチャルボタンを使う利点になるので、そこを生かすことができるコーディングができるようにしたいところ。

そもそも、ハードデバイスで or 演算をしたい理由は、同じ機能を持つボタンが複数あるからである。
なぜ同じ機能をするボタンが複数あるのかというと、不必要なボタンが存在しているからです。ハードデバイスだから、いらないボタンも常に存在し続けるのです。
だから、同じ機能をするボタンが必要になるということが起こる。AボタンかSTARTボタンでゲームを始める、とか。

バーチャルボタンなら、そういうことは起きないはずで、いらないボタンは消してしまえばいいわけです。
だから、まったく同じ機能をするボタンが複数同時に存在することはあまり考えられない。
一時的に一部の処理が同じになるようなボタンが存在することはあるにしても。

だから、まとめると
・ボタンのビット演算はできなくてよい
・ボタンを自由に追加・削除できる
というところがポイント。

また、複数のボタンが重ねて存在することも可能です。
重なっている部分をタッチすれば、両方のボタンが押されたことになります。
扱いには気をつけるべきですが、常に画面全体を一つのボタンと見なすようにしておくと便利なことがあるかもしれません。

ファイルへの読み書きの方法はいくつかあります。
ここには、一番簡単な方法を書きます。

//書き込み
bool saveData(void *pData, uint32_t lenData, const char *fileName)
{
  //正確なファイルパスを作成
  NSString* filePath = [NSHomeDirectory() stringByAppendingPathComponent:[NSString stringWithFormat:@"Documents/%s", fileName]];

  //書き込むバイト列をNSData型(またはNSMutableData)に変換
  NSData *data = [NSData dataWithBytes:pData length:lenData];

  //NSDataをファイル書き込み
  BOOL ret = [data writeToFile:filePath atomically:YES]; //引数については後述

  return ret;
}

//読み込み
const void *loadData(const char *fileName)
{
  //正確なファイルパスを作成
  NSString* filePath = [NSHomeDirectory() stringByAppendingPathComponent:[NSString stringWithFormat:@"Documents/%s", fileName]];

  //ファイルマネージャの取得
  NSFileManager *fileManager = [NSFileManager defaultManager];

  //ファイルが存在するか確認
  if ([fileManager fileExistsAtPath:filePath]) {

    //ファイルが存在するなら、その中身をNSData型で取得
    NSData *loadedData  = [NSData dataWithContentsOfFile:filePath];

    //NSDataから生のバイト列に戻す。ここが忘れがちなので注意
    const void *bytes = [loadedData bytes];

    return bytes;
  }
  return NULL;
}

OpenGLESプロジェクト

XCode で、新規プロジェクト→iOS→OpenGLESを選択
すると、もうOpenGLESで描画のされたサンプルが生成される。
これを自分のいいように書き換えていく。

その際の注意点。


シェーダの変数名は合っているか
　position と a_positionとか
　Shader.vsh/fsh と、 loadShaders() のglBindAttribLocation()の引数など


CoreGraphics.frameworkを追加したか
　CG***()関数を使う場合
　_CG***()が定義されていない、というようなエラーが出る


programオブジェクトをちゃんと渡しているか
　loadShaders() の program = glCreateProgram();

UIApplicationDelegateプロトコルの主要なメソッドの解説


普通、***AppDelegate.mとして自動的に作られている


前説
background, foregroundはiOS4以降に出てきた概念。
アプリを実行中にホームボタンを押すと、background状態に移行する
active, inactiveはiOS4以前からある。
電話がかかってきてアプリを一時中断したときなどにinactiveになる。

backgroundは、inactiveである。（逆は成り立たない）
backgroundの間は、ユーザからは見えない。inactiveの間は、操作はできないが見えている可能性があり、描画はしている必要がある。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
アプリの起動時に呼ばれる
似た関数にapplicationDidFinishLaunching:もあるが、推奨されていないとのこと

- (void)applicationWillResignActive:(UIApplication *)application
アプリがアクティブ状態から非アクティブ状態になるとき呼ばれる
電話が来て中断したり、ホームボタンを押してアプリが裏にいったとき
ゲームを一旦停止する処理を書く
非アクティブ状態のアプリは、実行はされているが、どのResponderもイベントを受け取らない。

- (void)applicationDidBecomeActive:(UIApplication *)application
アプリがアクティブ状態になるとき
ゲームを再開する処理を書く

- (void)applicationWillTerminate:(UIApplication *)application
アプリが終了するとき。メモリ上から完全に消し去る
ゲームの終了処理を書く
5秒以内に済ませられないと、システムに強制的にキルされる。
iOS4より前なら、ホームボタンを押したときに呼ばれる。
iOS4以降なら、基本的に呼ばれることはない。backgroundで実行し続けるから。ただしシステム(iPhone)が終了したときには呼ばれる。

- (void)applicationDidEnterBackground:(UIApplication *)application
iOS4以降。
アプリがバックグラウンドに入ったとき。（ホームボタンを押したとき）
描画に関係のない処理
これが呼ばれる前には、applicationWillResignActiveが呼ばれている

- (void)applicationWillEnterForeground:(UIApplication *)application
iOS4以降。アプリを選択したとき
このあとには必ず applicationDidBecomeActive が呼ばれる



流れ

起動
application:didFinishLaunchingWithOptions:
applicationDidBecomeActive
ホームボタン押す（バックグラウンドへ）
applicationWillResignActive
applicationDidEnterBackground
アプリアイコン押す（フォアグラウンドへ）
applicationWillEnterForeground
applicationDidBecomeActive
電話受信、実行中アプリ表示、アラート表示など（非アクティブへ）
applicationWillResignActive
電話終了、実行中アプリ表示の終了、アラート消去など（アクティブへ）
applicationDidBecomeActive
実行中アプリから消去

--落ちた。なぜ ← 落ちた理由はこれ

「KAGEROU」。
著者は齋藤智裕。水嶋ヒロです。





本の内容そっちのけでなにかと話題になったこの作品。

実際に読んでみると、そのできばえの良さに驚きます。


主人公はビルの屋上で自殺を図る四十男。

そこに現れた謎の人物。
自殺を止めるでもなく、生きろと諭すでもない。
男は自分を、全日本ドナー・レシピエント協会の人間だと名乗る。
ドナーとは臓器提供をする人、レシピエントは提供を受ける人のことであり、両者の橋渡しをする団体だという。
つまり、自殺しようとする人間に声を掛け、自殺の手助けをするとともに、その体を数千万円で買う、その代金は自然な形で遺族に遺すというのである。
ここに２人の奇妙な契約が成立する。


設定の妙からつい先が読みたくなります。

ストーリーは決して目新しいものではありませんが、必要な伏線の張りと回収、無理のない自然なストーリー展開、納得感のある結末と、新人としては非常によくできていると思います。



ストーリーとか全然違うんだけど、「天国の本屋」を思い出します。
本を読んで心温まりたい人には強くおすすめ。

毎月給与から天引きされる厚生年金。

会社員の入る第2種国民年金。


給与と賞与の両方から源泉徴収されます。
給与のほうは毎月定額。

○給与の徴収額
保険料率は、平成22年9月から平成23年8月までは16.058％。
誰でも同じ率です。
ただし、厚生年金基金に加入している会社の場合、これよりいくらか(2.4%~5.0%)低くなります。
これを個人と会社で折半するので、8.029％。
なお、9月分の徴収は10月にされるので、給与明細では10月から保険料が変化します。

保険料率は毎年あがっています。
平成22年9月からは16.058%で、毎年0.354%ずつあがっています。
平成29年9月以降は18.3％になります。


毎月の給与そのものに上記の保険料率を掛ける訳ではなく、標準報酬月額というものが決まっています。
月額の境目は以下の表に書いてあります。
http://www.sia.go.jp/seido/iryo/ryogaku2109/ryogaku01.pdf


例えば、1ヶ月の給与が29万円以上31万円未満の人は、18等級となり、標準報酬月額30万円となります。
これに8.029％を掛けて24,087円が毎月天引きされるという訳です。

こういう仕組みなので、標準報酬等級が1ランク変わっただけで、大きく保険料が変わります。
例えば、309,999円の人は標準報酬月額30万円なので、保険料は上記の通り24.087円。
しかし、310,000円の人は標準報酬月額が32万円となり、保険料は25,692円となります。
その差は1,605円、年間では19,260円の差になります。大きいですね。


○賞与の徴収額
標準報酬月額は決められておらず、賞与額の1000円未満を切り捨てた額に保険料率を掛けた額が保険料率になります。

「ドラッカーと会計の話をしよう」




最近何かと流行りのドラッカー本。

この本は、会社の会計と利益に焦点を当てて、ストーリー仕立てで噛み砕いて説明しています。

小さなイタリアンレストランを経営している純一。
年商1兆円の小売りチェーンの創業者、西園寺。
成田発ロサンゼルス行きの飛行機で偶然隣に座った２人が、フライトの間に交わす会話。
会社の目的とは何か、利益とは何なのか。
レストランの経営に苦しんでいる純一（と読者）に、西園寺がドラッカーのエッセンスを教える形で話は進みます。




純一の経営するレストランは、黒字であるにもかかわらず、資金繰りに苦しんでいます。
利益とは何なのか。
ドラッカーは、「利益というものは存在しない」と言い切ります。
存在するものは、「儲け」である。
利益と儲けはどう違うのか。

利益とは、その会計年度でむりやり区切って算出した、いわば「作られた数字」です。
会計を学ぶ2年生であれば、誰でも数字をいじることができてしまう。
儲けとは、稼いだ現金、つまり「キャッシュフロー」です。
銀行口座にどれだけの現金が入っているか、ということです。



また、どこの会社でも心当たりのあるようなことが書いてあります。
--
売り上げが下がったからといって、トイレの石けんを買うのをやめたりしてはいけない。
好況だから予算を増額、不況だから減額というような場当たり的なことをするのではなく、
しっかりとしたマネジメントの判断で決定すべきである。
--


ほかにも興味深い事実がたくさん語られています。

もっともよい10％の商品が、全体の90％の売り上げを占めている。
逆に、90％のコストは、価値をうまない90％の活動に使われている。
管理可能な支出を増やすこと。
費用と資産は同じものであること。
キャッシュフローは未来を見ている。
利益は、過去を表しているにすぎない。


しかし、もっとも大事なのは以下ではないでしょうか。
--
利益は、顧客が製品を受け入れた時点で発生する。
消費者へのアフターサービスまで含めて、製品のコストとして捉えるべきである。
消費者が、その製品のコストをすべて負担している。
製品の値段は、コストでなく顧客が払えると考える値段に依って決まる。
--

大事なのは、会計には現れない、顧客の視点だというのです。

iPhoneの加速度センサの使い方です。


○使い方

1.
delegateとするクラスに
<UIAccelerometerDelegate>プロトコルを使います。

2.
加速度センサを有効にしたいタイミングで
[[UIAccelerometer sharedAccelerometer] setUpdateInterval:1.0 / 60.0];
[[UIAccelerometer sharedAccelerometer] setDelegate:self];
と記述。
この場合、60分の1秒ごとに加速度を検出し、selfにメッセージが送信されることになります。

3.
以下の関数を実装。
-(void) accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration*)acceleration
60分の1秒ごとに呼ばれます。
UIAccelerationクラスのaccelerationのメンバx,y,zに加速度の方向が入っています（後述）。

4.
終了時には、delegate指定を削除すればOKです。
[[UIAccelerometer sharedAccelerometer] setDelegate:nil];



○加速度の向きについて
加速度の方向とは、通常は重力の方向が検知されます。iPhoneを思いっきり振るなどした場合は、振った方向の逆向きに加速度が働いたように検知されます。

iPhoneの座標系は、画面左から右を+x方向、ホームボタンから電源ボタンの方向を+y、画面の表方向を+zとした向きに軸が指定されています。

　　『チア男子!!』

作者は現役早稲田大学生、朝井リョウ。



性格も目的も違う男子大学生たちが、チアリーディング部を作って全国大会を目指します。

話はメンバーを集めるところから始まります。
ずいぶん簡単に集まるなあと思いますが、そこはご愛嬌。
チアのメンバーは最終的に16人になるのですが、全員のキャラがしっかり立っているのがすごい。読んでいてメンバーの練習風景の情景が眼の前に浮かぶようです。

それぞれのキャラクターやストーリーは決して目新しいものではありませんが、
全体としてきれいにまとまっており、読後感も非常にさわやか。
特に最後の章、全国大会の演技と、試合前最後のミーティングと2つの場面を交互に描いていく場面は、そのまま映画にできるような巧さです。

男子チアリーディングというのは実際にあり、早稲田大学にもチームがあります。
作者はそのチームをモデルにして作品を書いた訳ですが、逆にこの作品を読んだチームメンバーが作品の登場人物に励まされたといいます。