Unityコインプッシャーにて勉強

Unityコインプッシャー
Unityのラーニングに指定されたのでさくせいしました。

iPhoneゲームを20分間で作る【メダルプッシャー編】

Unity Web Player | WebPlayer

« created with Unity »

.*演算子 メンバポインタ？

http://d.hatena.ne.jp/redboltz/20120111/1326292284
をあきらさんがつぶやいているのを見て、だいぶわからなかったので調べてみました。
http://www.geocities.jp/ky_webid/cpp/language/034.html
にメンバ関数ポインタ.*演算子について書いてありました。

とにかく

struct A{ int value_; }

に対して

A a;
a.*&A::value_ = 20;

とアクセスできることがわかりました。
まあ、なんでも
a.* がメンバにアクセスする方法で
&A::value_ がクラスの先頭からのオフセット値なんだそうでした。
まだ、途中ですが、ものすごく気持ち悪かったのが

template <class MemPtr, MemPtr p>
MemPtr Access() { return p; }
a.*Access<int A::*, &A::value_>() = 40;

で、aのメンバではないものを呼び出しているようにしか見えませんでしたが
@hudepen先生に聞いたりいろいろしていたらなんとなくわかったのですが、

a.*(Access<int A::*, &A::value_>()) = 40;

っつーことらしく、
先に計算されてAccess<int A::*, &A::value_>()が&A::value_を返すので

a.*(&A::value_ ) = 40;

となるわけで問題ないですね。
よって

void A::set(int _value){ value_ = _value;}

を呼び出す際は

(a.*Access<int A::*, &A::value_>())(50);

です。
また、A内から呼ぶ際は

void A::call(){ (this->*&A::set)(50);}

とか

void A::call(){ (this->*Access<int A::*, &A::value_>())(50) ;}

となりますでしょうか。
ほんで、当のprivateに外部からアクセスする部分はまだ見てません。

遅延評価の把握

http://d.hatena.ne.jp/amachang/20061204/1165180769
こちらを参考にjavascriptで実験してみました。

Function.prototype.funcObj = function() { return { valueOf : this } };
var random = function()
{
  var res = Math.random();
  alert('randomL:'+res);
  return res;
}
function add(i, j) {
  alert('add');
  if(j>0){
    return i+j;
  }
  return j;
}

alert(add(random(), 1));
alert(add(random(), 0));
alert(add(random.funcObj(), 1));
alert(add(random.funcObj(), 0));

普通にrandom()を引数に渡すとadd()の第二引数に関係なく必ずrandom()が実行されますが、
random().funcObj()を引数に渡すと先にadd()が呼ばれて第二引数によってはrandom()が実行されないのを確認。

こんな感じでしょうか。
しかし、
Function.prototype.funcObj = function() { return { valueOf : this } };
これがいまいち理解出来ていなくて、連想配列としてvalueOfを誰かが自動的に呼んで、その際に関数を実行させないで、自分のオブジェクトを返すって事でいいのでしょうか。

普通のHaskellプログラミング入門 ghc Glasgow Haskell Compiler, Version 7.2.2, stage 2 booted by GHC version 6.12.2

なにも知らなすぎるので、コンパイルできないと悩みまくる
ひとまず
 import Listは
 import Data.List
にする見たい。

パターンマッチの
 prefixp line = pattern `isPrefixOf` line
の`isPrefixOf`はshift+7の'では、もちろん無く
`(shift+@)のほうでした。。。

import Systemでコンパイルエラーが出る

ふつうのHaskellプログラミングのecho.hsのところで
import System
がコンパイル通らないのでググルと
http://tnomura9.exblog.jp/14966671/
import System.Environment (getArgs)
このように記述する旨書いてありました。
ghcのバージョンのせいなのか
The Glorious Glasgow Haskell Compilation System, version 7.2.2

なにがなんだか理解していませんが、ひとまず先に進めそうです。

よくみると

import System.Environment (getArgs)
じゃなくて

import System
の代わりに
import System.Environment
でいいっぽい

本の時代から
Systemが細分化されたのかな？

ふつうのHaskellプログラミングのUS-states.txt

US-states.txtに近いものを用意してみましたｗ

AK Alaska - Juneau
AL Alabama - Montgomery
AR Arkansas - Little Rock
AS American Samoa
AZ Arizona - Phoenix
CA California - Sacramento
CO Colorado - Denver
CT Connecticut - Hartford
DC District of Columbia, which is the seat of the Federal government
DE Delaware - Dover
FL Florida - Tallahassee
GA Georgia - Atlanta
GU Guam
HI Hawaii - Honolulu
IA Iowa - Des Moines
ID Idaho - Boise
IL Illinois - Springfield
IN Indiana - Indianapolis
KS Kansas - Topeka
KY Kentucky - Frankfort
LA Louisiana - Baton Rouge
MA Massachusetts - Boston
MD Maryland - Annapolis
ME Maine - Augusta
MI Michigan - Lansing
MN Minnesota - Saint Paul
MO Missouri - Jefferson City
MP Northern Mariana Islands, Commonwealth
MS Mississippi - Jackson
MT Montana - Helena
NC North Carolina - Raleigh
ND North Dakota - Bismarck
NE Nebraska - Lincoln
NH New Hampshire - Concord
NJ New Jersey - Trenton
NM New Mexico - Santa Fe
NV Nevada - Carson City
NY New York - Albany
OH Ohio - Columbus
OK Oklahoma - Oklahoma City
OR Oregon - Salem
PA Pennsylvania - Harrisburg
PR Puerto Rico, Commonwealth
RI Rhode Island - Providence
SC South Carolina - Columbia
SD South Dakota - Pierre
TN Tennessee - Nashville
TX Texas - Austin
UT Utah - Salt Lake City
VA Virginia - Richmond
VI the United States Virgin Islands
VT Vermont - Montpelier
WA Washington - Olympia
WI Wisconsin - Madison
WV West Virginia - Charleston
WY Wyoming - Cheyenne

マネージメント＆ディレクション

直近のプロジェクトでプロジェクトの運用の方面に近い箇所を担当する事になって、今までプロジェクトを回してもらってきて不満に思っていた箇所がどういう事で発生するのかわかってきた気がします。 一番思ったことは、プロジェクトの方針がだんだんぼやけてくる事。 あれ？聞いていた事と違う事が発生している？と疑問に思うことが増えてくると、だんだん不信感が高まってきます。 運営側がすべてを隠蔽するくらいのものならばそれでいいのかもしれませんが、現場に叱咤激励を飛ばしてくる場合にだんだん失敗の尻拭いをさせられている気になってきます。 個人的に簡単で効果があることは、プロジェクトの現在の方針を細かいPDCのイテレーションのなかのPで更新共有することではないかと思います。 マネージメントなどを一人で行なっている場合にどうしてもPDDDDCになってしまいがちかと思います。 それを全員でPDCを共有することで抜けやミスをする機会を減らせるのでは無いかと思います。 そうすれば、結果的にPを忘れてんぞ！とかCして無いけどおかしいなとなってくるのではないかな。 結構現場ではCしてないってことには気がついているものです。 ほったらかされているのが、まさにCしていないってことです。 この際に、まあいいか。知らねー。なんでやらないのか！と心で思っているだけではなく、気づいた人からアクションを行えるようになったらいいな。と思います。 とにかく、何かの役割を人に背負わせるのは、その人が失敗したときに責めて終わりというわけには行きません。 意識していきたいなー。