キャップの探したんだけど、いいのがなくてサーフィンしてたところでスパイディを見つけた。
めっちゃかっこいい
System.IO.Directory does not contain a definition for Delete.
Unityの経路探索使ってみた
ちょっと、ストラテジー寄りのゲームつくろうと思ったのでUnityのNavMeshを調べてみた
そんなに量が多くないのでとりあえず、公式マニュアルを読む http://docs.unity3d.com/ja/current/Manual/nav-Overview.html
どうやら、StaticMeshに対してNavMeshをBakeすると移動可能な経路として認識される。
エージェントの配置は適当なGameObjectにNav Mesh AgentをアタッチすればOK。
動的に障害物を配置したい場合はNav Mesh Obstacle を使用する。
離れたメッシュ同士の経路を接続したい場合（ワープポイントの設定など）はオフメッシュリンクを使用する。
ざっとこれくらい調べただけで経路探索が実装できた。
拍子抜けするくらい簡単なので経路探索を聞いて、怖がる必要が全くない。
ゲームエンジンすげー
Scala 関数型デザイン & プログラミング 進捗
3章を解き始めた
https://github.com/ozw-sei/scalaz_book/blob/master/ex3.sc
とりあえず、3.13まで解いて力尽きた。
所感をメモしていく 難易度 ☆1~5
3.1 ☆1 読めばわかる
3.2 ☆1 Cons(x, xs)をじっくりみてればわかる
3.3 ☆1 何をすれば解けるかを考えればすぐわかる
3.4 ☆1 アキュムレータとか再帰を覚えてればらくちん
3.5 ☆1 3.4よりも簡単かも
3.6 ☆3 15分くらい頭かかえた。答えには到達できてたけど末尾再帰できない か考えて無駄に時間を使ってしまった。
3.7 ☆3 0.0をマッチすれば検知はできるけど、そうすると末尾再帰にならないので無理☆
3.8 ☆1 foldRightのソース読めば一撃
3.9 ☆2 foldRightあんま使ったことなかったので時間かかった。
3.10 ☆3 紙に書いたらすぐとけた。
3.11 ☆2 ほぼfoldRightの書き換え
3.12 ☆2 ちょっと考えたけど、落ち着いたらすぐできた
3.13 ☆5 自力で解けなかった
以上
解答を読んでみるとこっちのほうがスマートに書いてあるな…
小さな買い物でもカードを使うようになった
ちょっと前まではコンビニでも小さな買い物でいちいちカード使うの面倒に思ってたのだけど、最近はすべての買い物でカードを使うようにしてる。
大した理由はないのだけど、シンプルに手間が減るのがよい
額が小さいほうがよりカード向き
コンビニで適当な買い物をすると大体1000円以下でおつりが数百円出てくると思う。 そうなると必然的に財布の残金を確認して、おつりの端数をまとめられないか計算するフローが発生する
カードで払えば提示してたまに署名を書くだけ。
そうすれば小銭を受け取らずに済んで財布が太るストレスや財布の中身を確認するストレスから開放されるので結構有意義だと思ってる。 （同じことは電子マネーにも言える）
デメリットが”ほぼ”ない
現金お金を払うタイミングが異なるだけでデメリットらしいものはあまり多くない。 手数料は考えられるが多くのチェーン店では手数料が取られない。反対に個人経営のお店では手数料取られる事がまだあるかもしれないのでそういう時はおとなしく現金を払おう…
また、大手家電量販店などポイント還元率が減るケースもあるのでそういう時もおとなしく現金がよさそう…（家電量販店と提携したカード作れば倍率が変わないこともあるけど）
まとめ
現金払う事って習慣になってるので大したコストと認識してないかもしれないけど、実は結構手間がかかる行為だと思っててそこを補完してくれる便利な道具があるなら積極的に使っていこう。
※自動チャージされる電子マネーに対しても同じことが言えるかも
