guntamania

Disqusを導入

[2018-06-02 Sat]

Disqusを導入した。 これでブログっぽくなるぜ。 とりあえず、Articleのほうにだけ追加しておく。 こっちはメモだし、いらないよねえ。。

Android Test

[2018-06-17 Sun]

わけあって、Androidのテストについて調べていた。 自動テストってやつだ。もうこの「自動テスト」とか、 「自動化」って古い響きがするんだけども。

Androidでのテストは以下に大別できる。

Local Unit Test

いわゆる単体テストってやつなのかな。 昔ながらのテストでイメージするのはこっちかな。 メソッドごとに単体テストを行い、 期待どおりの出力が得られるかどうかテストをする。

例えば足し算をテストするようなやつだ。

ただ、Androidだと、フレームワーク依存部分が多少なりとも出てくるから、 Robolectric なんかを使う必要があるかもしれない。

あとはモックを使う箇所が出てくる。 クラスのインスタンス化を行わずに振る舞いだけを 定義してやることを「モック」というらしいんだけど、 これを使うことによって、他のクラスに依存することがない テストを書くことができるっぽい。

例えば、 RestService なんていう自作クラスがあったときに

mRestService = new RestService(context);

ってやっちゃうと、 RestService のテストまですることになってしまう。 これをモックを用いることで、回避しようってわけ。

単体テストは、開発以外の人から見るとあまり意味のないものと 捉えられるかもしれない。 ただ、大人数や不特定多数で開発する場合、 I/Fまわり(publicメソッドふくむ) の試験くらいは用意していたほうがいいのかな、と思うことがある。

まあでもこれもステークホルダを説得できるかどうかにかかっている。 僕はまだ職場では導入できていない‥

instrumented test

実機を使ったテスト。 単体テストではできなかった結合試験を行うことができる。

用いるフレームワークは以下の2つに大別できる。

両方ともuiテストができる。

uiテストってのは、ユーザ入力を何らかの方法で擬似して、 アプリを実際に動かすテストだ。

それだけに非常に説得力のあるテストなんだけど、 コードを直接試験するような特性はないので、 まあ、ざっくりとした試験になりがちってこと。 カバレッジ上げるのも大変だしね。

espressoは細かい入力を擬似することができるし、 使いやすいんだけど、弱点として、他のアプリの操作が できないことが挙げられる。 なので、インテントを投げて他のアプリでシェア、 なんて試験はできないので、そういった場合は uiautomatorの出番になる。

ただ、espressoの弱点ってほぼそれだけのようなので、 あまりuiautomatorの出番はないかもしれない。

最近

で、気になったのは、記事が出ないことでないこと..

googleで引っ掛けてみても全然最近の記事がヒットしない。 google i/oでの講演が2017なんで、 それ以降の記事が出てきてもいいと思うんだけど‥

アーキテクチャの話はたくさんでてくるし、 mvpやmvvmって、テストしやすいアーキテクチャだって 話だったとも思うんだけど。

なぜそれとセットでテストの話が出てこないんだ‥?

参考

メモ

[2018-06-18 mon]

cssのフレームワークはめんどくさいので、 フレームワーク使ってない参考サイト

http://zeroequalsfalse.press

それだけ。。

mgo

[2018-06-20 wed]

metal gear online 2 のサーバが有志によって復活しているようだ。

プレイするにはPS3のリストア機能を使うため、 内蔵ハードディスクをすべてリセットする必要があるんだけど、 もうあまりプレイしなくなったゲームのセーブデータしか入ってなかったんで、 思い切ってやってみた。

プレイしてみると、本番サーバがよく再現されていて、 プレイヤビリティは全く遜色がない。

ただ、ここまでしてプレイするプレイヤーってのは、 相当やりこんだプレイヤーであることが予想される。

自分の腕が相当鈍っているというのもあるだろうけど、 なかなか太刀打ちできなかったのだった。

Macbooc以外のラップトップ

[2018-06-21 Thu]

DELLという選択肢ね。

脱MacBookしようとしてnew XPS 13 2018年モデルにLinuxをいれてみたけどちょっと後悔してるよ

(ややバズったせいか、もとの文が消えている気がする。)

元記事では、DellのXPSをMacbookProの後釜として選んでいるようだ。

前はおなじようなことかんがえていた。 別にMacを特別好んでいるわけではないので、 Linux機としてThinkpadを手に入れようと思ったのだ。

自分としては

というのがPCの条件だった。

最後の条件が結構厳しくて、Thinkpad ぐらいしか選択肢に入らなかったんだけど、 DellもUS配列に載せ替えができるのね。

結局、いろいろ検討したんだけど、いろいろ盛ったりすると結局Macbook Pro 買うのとあまり変わらんな、と思ってMacbook Proにしたのでした。

元記事見ると、やはり、ノートPCにLinux入れて運用するのは、 結構気合のいる作業だってことがわかる。

Java Script について試行錯誤

[2018-06-29 Fri]

JavaScriptを書くことがあるんだけど、クラスの実装やら、 インスタンスまわりの設計についていろいろ悩んでいる。 一応決着付きそうな感じなので、メモ。

素朴な実装

何も考えずにjsを書いていくとこうなっていく..

var value;
function method1() {
  value++;
  console.log("value is " + value);
}

function method2() {
}

 :

これでも悪くはない。でも、割とすぐに破綻してしまう。 やはり変数のスコープや値やメソッドの保持の仕方を考えないと、 設計にすぐ行き詰まってしまうのだ。

名前空間

JSはHTML側で勝手に読んでくるので、自分が定義する変数やメソッドが グローバルにあるかどうかが重要になってくる。例えば

function add(a, b){
  return(a + b);
}

なんてしたときに既存の add を書き換えてしまっているかもしれない。 これをグローバル汚染という。

グローバル汚染を防ぐのであれば、単純に名前空間を導入すればいい。

var NameSpace = NameSpace || {};

NameSpace = {
  method1: function(a, b) {
    return (a+b);
  },
  method2: function() {
    console.log("result is" + NameSpace.method1(1, 2));
  }
};
// 呼ぶとき
NameSpace.method2();

上記では method1method2 も毎回名前空間である NameSpace をつけなければ呼ぶことができない。

これでどれだけベタな命名をしても他のメソッド名とかぶる心配がなくなり、 名前空間の管理だけしておけば良いことになる。

ただし、このパターンはオブジェクト指向ではない。 インスタンスを持っていないためだ。

クラス

そこで、クラスを導入する。最新の仕様だと class が導入されているが、IEでは動かないため、今回は考えない。

ここではクラス MyClass を導入することを考える。

var MyClass = function(name) {
 this.name = name;
};

MyClass.prototype.method1 = function() {
  return this.name;
};

MyClass.prototype.method2 = function() {
  console.log("hello," + this.method1);
};

new MyClass("john").method2();

この実装で、クラスの振る舞いをもたせることができる。 インスタンスメソッドや、フィールドを持つことができるため、 オブジェクト指向プログラミングが可能になる。

また、メソッドの実装部は下記のようにしてもよい。

MyClass.prototype = {
  method1: function() {
    return this.name;
  },
  method2: function() {
    console.log("hello," + this.method1);
  }
}

ただし、このパターンだと、すべてのメソッドがパブリックになってしまう。 このパターンの場合のように、プライベートメソッドや変数が 宣言できない場合、冒頭にアンダースコアをつけ、

MyClass.prototype._privateMethod = function() {..};

のようにすることもあるが、外部から呼び出すことは可能なので、 あまり効果があるとはいえない。

モジュールパターン導入

最近はモジュールパターンを導入しつつ、 インスタンス生成を簡素化するため、 以下のようなパターンを用いている。

MyClass = (function() {
  // 1
  var name;
  var self;
  // 2
  function Klass() {
        // 3
        self = this;
  };
  Klass.prototype = {
        // 4
        publicMethod1: function() {
        },
        publicMethod2: function() {
        }
  };
  // 5
  function privateMethod() {
        self.publicMethod2();
  };
  // 6
  return Klass;
})();

インスタンスを作るときは以下のようにすれば良い

var instance = new MyClass();

一つの名前空間に対して唯一のクラスを実装するときに有効なパターンだ。

まず、1では、プライベートな変数を宣言している。 この名前空間の中では value の形で利用可能だ。 名前空間や this をいちいちつける必要もない。

2 でコンストラクタを実装している。

3 で self を宣言している。これは、 this が指す内容が 各スコープごとで変わってしまうためだ。 例えば、 5 でのプライベートメソッドや、 コールバック登録時の匿名メソッド内などで this の内容が変わってしまう。 これをコンストラクタ内で self に固定してしまうことにより、 いつでもこのインスタンスを指すハンドラを呼び出すことができる。

4 では、パブリックメソッドを宣言している。外部からは instance.publicMethod1(); のように利用可能だ。 ただし、内部からは this を使って呼び出す必要がある。

5 はプライベートメソッドだ。 内部からは利用可能であり、内部変数も呼び出し可能である。

6 でこのクラスを返している。 このように返すと、 名前空間を意識せずにインスタンスを生成することができる。

おわりに

JavaScriptは生粋なオブジェクト指向言語ではない。 オブジェクト指向プログラミングをする場合、 上記のように自分で、構造から定義してやる必要がある。

最初はとっつきにくかったが、やってみると、 最近は楽しみすら感じるようになってきた。

規模や目的によって、どこまでオブジェクト指向するのか あるいは異なるパラダイムを導入するのか、 決めていく言語なんだと感じている。