OmniAICreator/Qiita-1.07M huggingface dataset:
React Native - Debugの方法

ネイティブアプリの開発はXcode等の開発統合環境で普段行われていると思います。これらの環境では、デバッガーが標準で付属しており、ブレークポイントなどを設定して、変数の確認等が用意にできます。React Nativeでの開発では、Chromeのデベロッパーツールを使用してデバックします。

## iOSの場合

デバイスのエミュレーター上でCommand+dを押すと、下のようなアクションシートが出てきます。ここで"Debug in Chrome"を押します。

![](https://qiita-image-store.s3.amazonaws.com/0/13663/49dddbe5-79e3-1c1d-6680-ff5c9b29b26a.png)

すると、Chromeが立ち上がるので、`Command+Option+j`を押し、デベロッパーツールを起動します。
![](https://qiita-image-store.s3.amazonaws.com/0/13663/469f7576-0fe7-f38a-9243-a9a3a3bfb7e5.png)

そして、Sourceのタブを開きます。
![](https://qiita-image-store.s3.amazonaws.com/0/13663/758a7072-cedb-500a-7ccf-5ed0cd196cad.png)

左のペインの"Sources"でブレークポイントをマークしたいファイルをハイライトします。
![スクリーンショット 2015-12-03 14.55.43.png](https://qiita-image-store.s3.amazonaws.com/0/13663/9c06c221-61b8-3add-884c-ec0e92d7e245.png)

ブレークポイントを設定し、デバイス上でCommand+rを押して、Reloadするとそこで止まります。変数を参照したい場合は、右ペインのWatchで指定できます。
![](https://qiita-image-store.s3.amazonaws.com/0/13663/48b9573c-9aed-7eb6-c3ba-6b8426187323.png)

もちろん、`console.log()`でChromeのコンソールの窓に表示されます。![](https://qiita-image-store.s3.amazonaws.com/0/13663/7c98fb74-a572-01a7-2954-feb171a49059.png)

同様にXcodeのデバックエリアにも表示されます。注意点として、このデバックエリアはオブジェクトのタイプなどがうまく表示されない場合があります。例えば、Parseオブジェクトを取り扱ってるのにJSONフォーマットのように表示されて区別ができません。私はここでハマった記憶があります。できるだけ、Chromeのデベロッパーツールを使いましょう。

![スクリーンショット 2015-12-03 15.05.58.png](https://qiita-image-store.s3.amazonaws.com/0/13663/e936d08b-6c5b-4ed8-de44-546baa0abe79.png)

## Androidの場合

Menuを開いた後, "Debug in Chrome"を押します。そうすると、デベロッパーツールが起動します。あとはAndroidも同様です。
![](https://qiita-image-store.s3.amazonaws.com/0/13663/bd3c07ac-0136-1724-2064-564f2cfe2d63.png)

![](https://qiita-image-store.s3.amazonaws.com/0/13663/e4c1e106-9323-7e20-a6a5-24b7747734b9.png)

コンソールで確認するには、abdコマンドでTailします。

```
$ adb logcat *:S ReactNative:V ReactNativeJS:V'
```

## Summary

デバッガーがあるのでReact Nativeも安心して開発することができます。JSファイルのReloadの威力は絶大で、Xcodeのbuild＋Runに比べて一瞬でスタートできるのも良いです。

これで開発環境が整いました。明日は`StyleSheet`についてまとめたいと思います。
[OSX][iOS]Objective-C

<p>Objective-C 2.0と呼ばれるものから、大幅に機能が増えたが、当初のObjective-Cは簡素で、C言語をマスターしたプログラマーなら30分程度でマスターできる言語だった。ただし、言語の仕様を簡素というだけで、Cocoaフレームワークを使いこなせるようになるには、当初から難しかったが。</p>
<p>今回の投稿では、初期のCocoaでのObjective-Cについて説明する。これによって、基本的にとても簡素な仕様の言語だとうことが分かると思うので。</p>

<p>クラス定義は、以下の通り。通常、ヘッダーファイルに記述される。</p>

<pre><code>#import &lt;Cococa/Cocoa.h&gt;
 
@interface Song : NSObject {
    NSString *title;
}
 
+ (id)sharedInstance;
- (id)init;
- (void)dealloc;
- (NSString *)title;
- (void)setTitle:(NSString *)aTitle;
@end
</code></pre>

<p>クラスは必ずNSObjectまたは、その子クラスを継承する必要がある。</p>

<p>クラスの実装は、以下の通り。通常、サフィックスが.mのファイルに記述される。</p>

<pre><code>#import "Song.h"
 
@implementation Song
 
+ (id)sharedInstance
{
    static Song* song = nil;
    if (! song) {
        song = [[Song alloc] init];
    }
    return song;
}
 
- (id)init
{
    if (self = [super init]) {
        title = nil;
    }
    return self;
}
 
- (void)dealloc
{
    if (title) {
        [title release];
        title = nil;
    }
    [super dealloc];
}
 
- (NSString *)title
{
    return title;
}
 
- (void)setTitle:(NSString *)aTitle
{
    [title autorelease];
    title = [aTitle retain];
}
 
@end
</code></pre>

<p>+で始まるのはクラスメソッド。-で始まるのはインスタンスメソッド。親クラスのインスタンスはselfとなる。</p>

<p>既存のクラスはカテゴリーを使って拡張できる。</p>

<pre><code>#import "Song.h"
 
@interface Song (Album)
 
- (NSString *)albumTitle;
 
@end
</code></pre>

<pre><code>#import "Album.h"
 
@implementation Song (Album)
 
- (NSString *)albumTitle
{
    return @"Trout Mask Replica";
}
 
@end
</code></pre>

<p>多重継承に対応しない代わりに、プロトコルという機能を用意している。</p>

<pre><code>@protocol Playable
- (void)play;
- (void)stop;
@end
</code></pre>

<p>Songクラスがこれに対応してみる。</p>

<pre><code>#import &lt;Cococa/Cocoa.h&gt;
#import "Playable.h"
 
@interface Song : NSObject &lt;Playable&gt; {
    NSString *title;
}
 
- (void)play;
- (void)stop;

</code></pre>

<p>呼び出し側はプロトコルに対応しているか判定することができる。</p>

<pre><code>if ([song conformsTo:@protocol(Playable)]) {
    [song play];
}
else {
}
</code></pre>

関連情報
<a href="http://qiita.com/advent-calendar/2015/cocoa/">Cocoa Advent Calendar 2015</a><br />
<a href="http://amazon.jp/dp/0596004621/">Cocoa in a Nutshell: A Desktop Quick Reference</a><br />

【Cocoa練習帳】
<a href="http://www.bitz.co.jp/weblog/">http://www.bitz.co.jp/weblog/</a><br />
<a href="http://ameblo.jp/bitz/">http://ameblo.jp/bitz/</a>（ミラー・サイト）<br />
<a href="https://t.co/6P3h2jtbRk</a>note<br />
frame.size.width + 10をframe.size.width + marginにした途端に動かなくなる理由

表題の現象ですが、Swiftを始めたばかりの頃は結構遭遇するのではないかと思います。
私は以前は良くハマっていました。

今回はなぜ数字を変数にしただけでエラーになるかを書いていきます。

## エラーになる状況
下のコードは普通に動きます。
10はマジックナンバーなのでmarginと言った変数にしたいとします。

```swift
let x = view.frame.size.width + 10
```

しかし変数にした途端にエラーになってしまいます。

```swift
let margin = 10
// 変数化しただけでエラー、辛い(˘ω˘)
let x = view.frame.size.width + margin // `Binary operator '+' cannot be applied to operands of type 'CGFloat' and 'Int'` エラー
```

## なぜ変数にするとエラーになるのか
これはview.frame.size.widthとmarginの型が違うからです。
view.frame.size.widthはCGFloat型でmarginはInt型です。
SwiftではCGFloatとIntの演算はサポートされていないのでエラーとなります。

```swift
CGFloat(10) + Int(10) // エラーになる
```

## view.frame.size.width + 10はなぜエラーにならないか
CGFloatとIntの演算はエラーになるという事なので、view.frame.size.width + 10も型が違ってエラーになりそうです。
しかし実際はエラーは発生しません。

これは`10`は演算時にCGFloatに変換されるからです。

## `10`がCGFloatに変換される仕組み
`10`がCGFloatに変換される仕組みですが、CGFloatが実装しているIntegerLiteralConvertibleというプロトコルが関係しています。

IntegerLiteralConvertibleを実装していると`10`などのIntリテラルが自動でそのクラスに変換されるようになります。
CGFloatはIntegerLiteralConvertibleを実装しているので、10はCGFloatの10.0に変換されます。

## Intリテラルがそのクラスに変換されるとは?
Intリテラルがそのクラスに変換されると言う所についてもう少し深掘りします。

下の実装は型が違うためにエラーが起きます。

```swift
class MyClass {}

let myClass: MyClass = 1 // MyClass型に1を入れようとするとエラー
```

しかしMyClassにIntegerLiteralConvertibleを付けるとエラーが起きなくなります。

```swift
class MyClass: IntegerLiteralConvertible {
    typealias IntegerLiteralType = Int
    required init(integerLiteral value: Int) {}
}

let myClass: MyClass = 1
```

これはIntegerLiteralConvertibleを実装した為、1(Intリテラル)が自動でMyClass(integerLiteral: 1)に変換された為です。

```swift
let myClass: MyClass = 1
// ↑ は ↓ のように変換される
// let myClass: MyClass = MyClass(integerLiteral: 1)
```

CGFloatも下のように変換されています。

```swift
let value: CGFloat = 1
// ↑ は ↓ のように変換される
// let value: CGFloat = CGFloat(integerLiteral: 1)
```

## まとめ(frame.size.width + 10がエラーにならない理由)
つまりview.frame.size.width + 10という計算の時、10はCGFloat(integerLiteral: 10)になるので問題なく動いているという事です。

```swift
let x = view.frame.size.width + 10
// ↓ のように変換されているのでエラーにならない
// let x = view.frame.size.width + CGFloat(integerLiteral: 10)
```

逆に変数にしてしまうと、IntリテラルではなくInt型になるのでCGFloatへの自動変換は行われなくなります。

```swift
let margin = 10 // → marginはInt型
```

その為変数にする際はキャスト or 型宣言を付ける必要があります。

```swift
let margin: CGFloat = 10
```

## 参考URL
http://qiita.com/koher/items/cbe232782b9943715c9b
Falconで光速のWeb APIサーバーを構築する

Falconは、Web APIサーバーの構築に特化したWebアプリケーションフレームワークです。
他のフレームワークがテンプレートエンジンやO/Rマッパなどのリッチな機能を詰め込んだ大衆車だとすれば、FalconはWeb APIサーバーに必要な機能だけにフォーカスし研ぎ澄まされた、F1マシンのようなフレームワークになっています。

[Falcon Official Page](http://falconframework.org/)

特筆すべきは、そのシンプルな設計と圧倒的な速度です。
以下は公式ページに掲載のベンチマークです(2015/11/26時点、PyPy2.5.1での比較結果)。

![benchmark.PNG](https://qiita-image-store.s3.amazonaws.com/0/25990/975cc857-a823-1c18-f53a-3a0a2ca22a16.png)

シンプルなフレームワークと言われる**Flaskの27倍、Bottleの1.5～2倍**の速度で動作します。

実装も非常に簡単です。以下は、シンプルなJSONレスポンスを返すサーバーの実装例です。
`python`で実行すると`8000`番ポートでサーバーが立ち上がり、アクセスするとJSONレスポンスが返ってきます。

```example.py
import json
import falcon


class HelloResource(object):

    def on_get(self, req, resp):
        msg = {
            "message": "Welcome to the Falcon"
        }
        resp.body = json.dumps(msg)

app = falcon.API()
app.add_route("/", HelloResource())


if __name__ == "__main__":
    from wsgiref import simple_server
    httpd = simple_server.make_server("127.0.0.1", 8000, app)
    httpd.serve_forever()

```

* リクエストに対しては、Resourceで処理を行う。Resourceは単なるPythonクラスで、継承などの必要はなし
* Resourceクラスでは、`on_get`、`on_post`など、HTTP METHODに対応したメソッドで処理を行う
* `add_route`で、どのURLパスをどのResourceクラスが担当するか設定

他に[Hook](http://falcon.readthedocs.org/en/latest/user/tutorial.html#introducing-hooks)といういわゆるFilterを実装できる機能がありますが、基本はこれだけです。
FalconアプリケーションはWSGIアプリケーションなので、WSGIサーバーで動かすことができます。上記ではPython組み込みの`simple_server`を使っていますが、gunicornやwaitressでも動かすことができます(公式は`gunicorn`を推奨していますが、Windowsの人は動かせないと思うので、waitress等を使うとよいと思います)。

* [gunicorn](http://gunicorn.org/) ※Windows対応のIssueは上がっているが、2015/11/26現在ではまだ
* [waitress](http://docs.pylonsproject.org/projects/waitress/en/latest/) pure-PythonのWSGIサーバー。速い。

用途としては、以下のようなシチュエーションに向いていると思います。

* クライアント側はJSフレームワークで構築するからテンプレートエンジンはいらない。JSONデータのやり取りをとにかく早くしたい。
* メールやセンサーデータなど、トラフィックの多いデータを高速にさばきたい(画面はそもそもない)
* シンプルなAPIサーバーを作りたいので、学習コストが高いフレームワークは勘弁

ぜひ、使ってみてその速度と手軽さを体感してもらえればと思います。
DockerでMinecraft forgeのマルチサーバを立てる

# はじめに

![Minecraft Title](https://qiita-image-store.s3.amazonaws.com/0/6583/769024a4-dd69-2ca3-8792-be425c135b63.png)

現在、弊社では「サンドボックスゲーム同好会」というのを立ち上げようとしています。

なにをする同好会かというと、今はMOD入りMinecraftをマルチプレイで遊ぶ会になっています。
月に1回MODを入れ替える作業をするのですが、これがいろいろバージョンの問題とかデーモン化の問題とかでめんどくさいので、サーバを移し替えるのとセットで、Dockerに移すことにしました。

# 動作環境

* ConoHa 4GBサーバ（2GBじゃ足りなかったので）
* CentOS 7（標準サーバです。CentOSのバージョンはメンバーにアンケートを取りました。）
* DockerはDocker公式リポジトリからインストール
* docker-compose もインストール

# 構成ファイル

https://github.com/deflis/minecraft-docker

# 所感

## 良かった点

### Docker Compose が便利だった。

最初はコンテナにそのままで動かしていたのですが、ボリュームコンテナを作る際にComposeを使うように変更してみました。
一度の操作でワールド用コンテナも作成することができ、MODを弄ってビルドしなおしになった際も同じコンテナを参照してくれるので、とても作業が捗るようになりました。結果としてサーバのダウンタイム低下につながっています。

この環境を構築したおかげで、11月から12月への構成の移行はそれほど苦労せずに移行できました。

### 事前にコンテナを準備してあれば、すぐに切り替えが可能

コンテナを準備するだけですぐに切り替えが可能なので、メンテナンスが超楽です。
MODの構成を変更したらローカルでビルドして確認することも容易で、最近ではDocker for Windowsで確認後にデプロイしています。

## 改善したい点

### バックアップ体制

まだ構築したばかりで、何もバックアップを取っていません。
さすがに複数台構成とかにするつもりはありませんが、1箇所にデータが固まっているのはリスクだなと感じています。

一応バックアップを取るコマンドは作っています。以下の様な形式です。

```bash
docker run --volumes-from minecraft201512_world_1 -v $(pwd):/backup busybox tar cvf /backup/minecraft201512_world.tar /data/world
```

参考 → http://qiita.com/manabuishiirb/items/6da3cd926fe674307615

### メモリ使用率の問題

MOD構成によってメモリ使用率が大きく変わるので、MODによってサーバを変える必要があります。

今回ConoHaを利用したのはまさにそこで、すぐにメモリの多いプランに乗り換えることができます。メモリを食う構成が終わったら同じ環境のままメモリ量を減らせます。
今のところ正式な同好会ではなくカンパで動いているサーバなので、時間課金があることも合わせてとても便利です。

ただ、ConoHaさん、メモリ量変更してからかなり待たされるのなんとかしてください！

### インフラエンジニアの不足

インフラエンジニアの社員が同好会にいません。
Docker触ってみたい弊社のインフラエンジニアがいればぜひ手伝ってください！！！

# 参考情報

[DockerでMinecraftServerを建てる](http://qiita.com/koki_cheese/items/873431fac1520e2a912f)
[docker-backupをdata volumeのデータをバックアップする](http://qiita.com/manabuishiirb/items/6da3cd926fe674307615)
[docker-composeを使うと複数コンテナの管理が便利に
](http://qiita.com/y_hokkey/items/d51e69c6ff4015e85fce)

# さいごに

![始まったばかりの今月のマルチサーバの様子](https://qiita-image-store.s3.amazonaws.com/0/6583/0c8ae193-dcf8-10fe-5255-d0a6b5d2ee4a.png)


「サンドボックスゲーム同好会」は毎晩楽しくマインクラフトをプレイしています！
spark frameworkのちょっとした応用


spark frameworkはJava8のラムダ式を使用したシンプルなWebアプリケーションフレームワークです。
[Spark Framework - A tiny Java web framework](http://sparkjava.com/)

基本的な機能については上記の公式サイトや[こちら](http://qiita.com/opengl-8080/items/801b32a8d44089fa1c04)が参考になります。

今回はマニュアルには書いてないけど、こうするとよさそうと思ったことを書いていきます。

# route
railsのroutes.rbやplayのrouteに相当するルーティングをmainメソッドに記載することがspark frameworkの特徴になっています。

```java:HelloWorld.java
import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
}
```

ただ、このままダラダラと書いていくと
* ルーティングが1ファイルに固まっていてみにくい。
* チームで開発するときに編集が競合しやすい。
* 加えてフィルタに相当する機能や組み込みjettyの設定もここに書く。
といったことになり、よろしくありません。

じつは別クラスにできます。こんな感じで

```java:Main.java
public class Main {
    public static void main(String[] args) {

        // common configuration
        CommonRoute.route();

        // Filter configuration
        FilterRoute.route();

        // business configuration
        BusinessRoute.route();

        // default route
        DefaultRoute.route();

        // initialization
        InitRoute.route();

    }
}
```

# 初期化
組み込みjettyから起動する際はmainメソッドがエントリーポイントになります。
上にも記載していますが、route定義と関係ない処理でも実行されるため、初期化に利用できます。
シングルトンオブジェクトの作成なり、データベースマイグレーションなりお好きな通り。

# ビューへの引き継ぎ
sparkでビュー(というかモデルからレスポンスへの変換)はいくつか方法があり、

* `(req, res) -> "Hello World"`という形のStringを返すラムダを書く。
* ResponseTransformerを実装する。
* テンプレートエンジンを呼び出すプラグインを利用する。(ResponseTransformerの特殊形)
といった方法があります。

ただマニュアルにも記載がある通り、ResponseTransformerは関数型インターフェースなので、

```java:ResponseTransformerの関数型の書き換えその1
get("/api/hoge/:id", (req, res) -> {
    return Hoge.get(req.params(":id"));
}, JsonUtil::dataToJson);
```

という感じでメソッド参照が使えます。

また、テンプレートエンジンも標準で提供されているものもありますが、あまり使い勝手がよくない場合もあるので、

```java:ResponseTransformerの関数型の書き換えその2
get("hoge/:id", (req, res) -> {
    Map<String, Object> variablesMap = new HashMap<String, Object>();
    variablesMap.put("hoge", Hoge.get(req.params(":id")));
    return ThymeleafTemplateEngine.render(variableMap, "hoge_show");
};
```

のような感じで必ずしもResponseTransformerを使わなくても大丈夫です。
最終的にはStringが返せればHttpServeletResponseのoutputstreamに流れていく(のかな？すいません、未確認です)

以上です。初投稿でした。
Aurelia hack 04 ～APIを呼んでみる～

今回は Node.js で実装した API を呼んでみるところまでやってみましょう。

# サーバサイド(API)の実装

Node.js で Web サーバを立てる際におなじみの [express](http://expressjs.com/en/index.html) を使います。
まずは依存モジュールを追加インストールします。

## サーバサイド用のモジュールを追加インストール

```json:package.json(追記)
{
  ～省略～
  "dependencies": {
    "babel": "5.8.23",
    "body-parser": "^1.14.1",
    "express": "^4.13.3",
    "serve-static": "^1.10.0"
  }
}
```

> babel の最新版は2015年12月現在 babel6 ですが、モジュールの構成が大きく変わっていて準備しずらいので今回は babel5 を使っています。

```shell-session:追加したモジュールをインストール
[you@server aurelia-skeleton-navigation]$ npm i
```

## サーバサイドスクリプトを書く

何のおもしろみもないサンプルではありますが、GET パラメタ `name` を受け取って `hello <name>` を返すだけの API を一つ実装しました。

```js:server.js(新規作成)
import express from "express"
import bodyParser from "body-parser"
import serveStatic from "serve-static"

let app = express();
let port = 3000;    // 待ち受けポート番号を変える場合はここを修正

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true}));
app.use(serveStatic('.'));

// API本体
app.get('/api/hello', (req, res) => {
    res.json({
        reply: `hello ${req.query.name}!`
    });
});

app.listen(port, () => {
    console.log("listening http on port " + port)
});
```

ES2015 の書式で書いたので、そのまま `node server.js` とコマンドをたたいても動きません。
`babel-node` コマンドを使ってもよいのですが、今回は require hook を使います。

```js:server.babel.js(新規作成)
require('babel/register');
require('./server.js');
```

```text:追加したやつ
aurelia-skeleton-navigation/
 ├─ ～省略～
 ├─ package.json (追記)
 ├─ server.js
 └─ server.babel.js
```

これを node で実行すれば起動します。

```shell-session
[you@server aurelia-skeleton-navigation]$ node server.babel.js
```

http://localhost:3000 にアクセスして確認してみましょう。

# クライアントサイドでAPIを呼び出す

Aurelia の HTTP クライアントとして [fetch-client](http://aurelia.io/docs.html#/aurelia/fetch-client/1.0.0-beta.1/doc/api/class/HttpClient) というものが開発されています。ひな形では users.js で使われているのでなんとなく使い方はわかるのですが、まだ詳しい説明を見つけることができません。

とはいえ別に fetch-client を使わなければいけないということもありません。Aurelia の素晴らしいところは何も強制しないということです。jQuery の Ajax 機能を使っても怒られません。

## SuperAgent

今回は jQuery ではなく、より軽量な Ajax クライアントである [SuperAgent](https://visionmedia.github.io/superagent/) を使ってみましょう。
まずは jspm を使って SuperAgent をインストールします。

```shell-session
[you@server aurelia-skeleton-navigation]$ jspm install npm:superagent
```

`src/welcome.js` の submit メソッドを以下のように修正してみてください。

```js:src/welcome.js
import superagent from 'superagent'

export class Welcome {
  heading = 'Welcome to the Aurelia Navigation App!';
  firstName = 'John';
  lastName = 'Doe';

  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  submit() {
    this.previousValue = this.fullName;
    alert(`Welcome, ${this.fullName}!`);
    superagent.get('/api/hello')
        .query({ name: this.fullName })
        .end((err, res) {
            console.log(res.body.reply);
        });
  }

  ～省略～

}
```

`gulp watch` を実行していない場合は実行してから http://localhost:3000 にアクセスして確認してみましょう。
今回は自分でサーバを立ち上げているので `gulp build` でも大丈夫です。

次回は superagent をラップしつつキャッシュ機能を追加した ApiClient クラスを実装してみます。
同時に DI にサービスとして追加する方法も紹介します。
Office UI Fabricのボタン

今日はOffice UI Fabric(以下"")のボタンの作り方を紹介します。

## ボタンのサンプル

サンプルソースコードは以下になります。OfficeUIのボタンは「ms-Button--XX」というクラスで指定します。

```html
<!DOCTYPE html>
<html ng-app="App">
  <head>
    <meta charset="utf-8" />
    <title>fontSize Sample</title>
    <link rel="stylesheet" href="//appsforoffice.microsoft.com/fabric/1.0/fabric.min.css">
    <link rel="stylesheet" href="//appsforoffice.microsoft.com/fabric/1.0/fabric.components.min.css">
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
  </head>
  <body ng-controller="AppController">
    <!-- ボタンを表示する -->
    <div class="ms-Grid-col ms-u-sm6 ms-u-md8 ms-u-lg12" ng-repeat="button in buttons">
      <button class="ms-Button {{button}}" onclick="alert('hello')">
        <span class="ms-Button-label">{{button}}<span>
      </button>
    </div>
    <script>
      var app = angular.module('App', []);
      app.controller('AppController', ['$scope',
        function($scope) {
          $scope.buttons = [
            "ms-Button", "ms-Button--primary", "ms-Button--hero",
            "ms-Button--compound", "ms-Button--command"
          ];
        }
      ]);
    </script>
  </body>
</html>
```

実行結果は以下のようになります。

![img.png](https://qiita-image-store.s3.amazonaws.com/0/61137/62addf0d-f61e-cd03-4840-f8a061a8e2bb.png)

## まとめ

OfficeUIでのボタンについて紹介しました。単にボタンを作るだけなので、サクッと記事が終わってしまいました……。
明日以降もOfficeUIの基本コンポーネントまわりの解説を行う予定です。
ぼくが変数の命名やコミットメッセージにこだわる理由

エンジニアの方であれば、よく変数や関数の命名で悩むことや指摘を受けることがあると思います。 
私はコードを書くときやレビューをする時にこの部分を非常に気にするのですが、今回はなぜかということについて書いておこうと思います。

## 今回の対象
* 変数名
* 関数名
* クラス名
* コメント
* コミットメッセージ

## 悪い命名（変数、関数、クラス）
### デメリット
* 名前を見ただけで値が予想できないのでコードを読むスピードが下がる
* 名前から処理の内容や返り値などが予想できないのでコードを読むスピードが下がる
* 読む人のストレスが溜まる

### 具体例
* dataなどの汎用的な単語を使う
* 変数に動詞を使ったり、英語として間違っている

## 適当なコミットメッセージ
### デメリット
* レビューしている場合修正されたかどうかがわからない。。
* ソースコードを見ないと、作業内容がわからない
* バグなどが発見された時の調査などがしにくい

### 具体例
```
コードを修正
```
→どこのコードだよ！

```
レビューの指摘修正
```
→どのレビューのどの指摘？

```
ボタンで一発ポチッとする処理を実装
```
→はっ！？


## 良い命名をするために
* 適切な英単語を使う
* 適切な品詞を使う
* 多少長くても複数の単語で表現する（data → userProfileDataなど）

## 良いコミットメッセージやコメントを書くために
* 仕様を知らない人の立場に立った時に理解できるかどうか考える
* コミットメッセージの一覧が日報などにそのまま使えるようにする

## まとめ 
一人で開発するのであれば、それぞれ適当でも問題が無かったり、いざ困るのは自分だけのはず。 
しかし、チームで開発するとなれば、レビューをしてもらったり自分以外の人がソースコードを変更することもあります。 
そういう時に、今回書いたようなことが最低限できていないと、他の人の時間を無駄に消費することになります。  
限られた時間の中で最大限の価値を生み出すためには、それぞれの人が一緒に働く人のことを思いやって、 
「他の人が読んだら迷わないだろうか」「この処理の理由はわかるだろうか」などということを常に意識するだけで、チーム全体のパフォーマンスは大きく向上すると思います。
RDSのデータをBigQueryに同期する

アクセスログはfluentdでBigQueryに流しているが、その情報とマスタデータを付きあわせてデータを出したい。Embulkでどうにか、とも考えたけどプロダクトの性質的にマスタデータがそれほど重くないので、何も考えずに毎回全部流してみることにした。キツくなってきたら考える。

ということでRDSの全データをBigQueryに転送するnpmを書いた。RDSだけではなくMySQLなら何でも可。差分の転送じゃなくて毎回全レコード転送するのでご注意を。
[mysql-to-bigquery](https://www.npmjs.com/package/mysql-to-bigquery
)

# 使い方
以下はElasticBeanstalkのWorkerとして構築した時の例。Lambda(Scheduled Event) -> SQS -> ElasticBeanstalkという構成でバッチ処理を実現している。[AWS LambdaのScheduled EventでSQSを叩く](http://qiita.com/KeitaMoromizato/items/2685048cd1cb2718854f)に書いたように構築するのは簡単。

Lambdaからは基本的にRDSに接続できない(SecurityGroupが面倒)ので、この構成にした。RDSを使う/使わないに限らず、重めのバッチはEB Workerに処理を寄せて、LambdaはScheduled EventでSQSを叩くだけに専念させてよいかと。EBもt2.microなら大した金額にもならないし。

```js
var http = require('http');
var MySqlToBigQuery = require('mysql-to-bigquery');

var sqlToBq = new MySqlToBigQuery({
  mySqlConfig: {
    host: 'localhost',
    user: 'root',
    password: 'password',
    database: 'database'
  },
  bigQueryConfig: {
    projectId: 'bigquery_project',
    keyFilename: "./path/to/file.json",
    dataset: 'production'
  }
});

// ここに転送したいテーブルを配列で
var tables = [
  'users', 'articles
];

http.createServer(function(request, response) {

  sqlToBq.exec(tables, function(error) {

    response.writeHead(200, {"Content-Type": "text/plain"});
    response.write("Hello World");
    response.end();
  });

}).listen(process.env.PORT || 8888);
```

Configはパラメータで渡さずに環境変数に設定してもOKです(詳細はREADMEを参照)。

# 参考
[iQONを支えるデータ分析基盤/iqon-bigquery](https://speakerdeck.com/kyuns/iqon-bigquery)
自信が無いエンジニアこそコードレビューをするべき

# 概要
コードレビューを受けるのは勿論成長につながりますが、コードレビューをする側になるのも
成長出来るチャンスがたくさんあるなとここ1年で実感しました。

「レビュー」と付いているとすごいこう上からな感じがして
新卒のうちやあまり自信が無い時だと中々やらなかったり、
読んでもわからないからある程度みてあとは適当に流しちゃうとか
そういう人も多いんじゃ無いかなと思います(自分もそうでした)

どんなに短いプルリクでも、1つ1つのコードをしっかり見ることはメリットが物凄くあると思います。

そこで、実体験を元にコードレビューをする側に立った時のメリットを書いていきたいと思います。

# 自分では書けないコードがたくさん見れる
最大のメリットはここにあるなと思います。
自分じゃ思いつかないようなスマートな書き方や、知らなかったメソッド、
クラス構成などがどんどん目に入ってきて、
「なんでこう書いてるんだろう？」と疑問がたくさん生まれます。

これってめっちゃ成長のチャンスですよね。
自分で調べれば糧になるし、どうしてもわからなければGitのコメントでなぜこうしているんですか？と聞けば
理由も知れるし、得することしかないなと思います。

実際、自分がSwiftを学習始めた時にすぐにコードレビューをした時に、以下のようなコードを見ました。

```lang:Swift
guard let identifier = segue.identifier else {
    return
}
```

初めて見た時、guardってなんやねん！とそこで初めてguardを知りました。
もし一人でやっていたら、これを知らないままif letを使いまくっていたことでしょう。。

# 自分でコードを調べる機会が増える
上記と少し被りますが、みたことない構文などが出てくるとその度に調べないと読めません。
なので、圧倒的に調べる機会が増えます。

```lang:Swift
var number = [1,2,3]
number.map{$0 + 1}
```

最初見た時もうなんじゃこれって感じでした。
ここからmapのことを調べて、省略の仕方を調べ、いつ使うのかを調べて…。
この途中でもしかしたらもっといい書き方をコメント出来るかもしれないし、
実はmapじゃなくてhogehogeを使ったほうがいいとか出るかもしれません。

自分で調べることで自信がつくし、その結果コメントをつけれれば、レビューされる側もメリットがあります。
自分の出来る範囲、考えれる範囲で質問や疑問を投げかけるだけでも、
チームにとってもメリットだと思います

# 真似できる
同じ人のコードレビューをしているとだいたい癖や好きな書き方がわかってきます。
その人が出来るエンジニアであればあるほど、その癖を掴んで真似していくことで
スキルアップにつながります。

```lang:Swift
func viewDidLoad() {
   self.setupTableView()
   self.setupLog()
   self.setupImage()
}
```

私が超尊敬する大先輩は、こんな風にライフサイクルの中身をなるべく簡潔に
かくのが癖(といっていいのか)の方でした。
実際、ライフサイクルの中身は簡潔にする方がもちろん可読性があがると思っているので
私は常にこういう風に書くことを意識しています。

1つ1つ真似していくと、その人がどんなことを考えて書いているかもなんとなくわかってきます。
そうなると、自分の武器がどんどんできていって、結果成長が出来ると思っています。

# 自信がないうちは「レビュー」しようと気張らなくていい
コードレビューと言う言葉は、「コードの質をあげるために指摘をする」というイメージ
が強いですが、**「コードの疑問点を聞く」**側面もあると思います。

特に若いうちは先輩に胸を借りる気持ちで質問をしたり、自分で調べて意見をぶつけてみたり、
そういった繰り返しが実体験としてとても大事だと思っています。

臆さずに自分から積極的にコードレビューさせてください！と言うと、より自信の成長が進むのではないかと思います。

ただ社内の文化や、忙しさなどで「コメントするな！」と言われてしまう場面もあるかもしれません。
文化を変えるように動けるのが得策ですが、なかなか難しいと思うので、
そういう時は友人のを見せてもらうとか、OSSを眺めたりするのが良さそうかなと思います。

# 終わりに
インプットとアウトプット、どちらもバランスよくしていくことが成長していく中で大事だと教わりました。
コードレビューする側になればインプットができ、コードレビューをされる側の時は自分のアウトプットを評価されます。

そう思うと、コードレビューって本当にエンジニアとしての成長を促進するものだなと思います。
私もまだまだの身ですが、積極的にコードレビューや人にコードをみてもらう機会を増やすよう
これからも活動していきたいと思っていますので
コードレビューをあまりしたことがない方は是非してみるとよいことがあるかもしれません！
[AngularJS] Promiseの状態をビューに表示する便利モジュール作りました


# Promiseの進捗によって表示を切り替える

```js:app.js
.controller('FooController', function ($scope, $http) {
  $scope.save = function () {
    $scope.pending = true;
    $scope.message = '';
    $http.post('http://...').then(function () {
      $scope.pending = false;
      $scope.message = '保存しました';
    }, function () {
      $scope.pending = false;
      $scope.message = '保存に失敗しました';
    });
  }
})
```

```html
<button ng-click="save()" class="btn btn-primary" ng-hide="pending">
  保存する
</button>
<button class="btn btn-primary disabled" ng-show="pending">
  保存中...
</button>
<p ng-show="message">{{message}}</p>
```

いきなりですがangularで開発していると、こんなコード書く機会一度はあったかと思います・・・

難しくはないですが、面倒くさいですよね？

ましてや「同じようなボタンが同じスコープにもう１個必要」となった暁にはフラグ名が重複しないようにしないといけません
ひたすらに面倒くさい・・・

# そこでモジュール作りました

https://github.com/hshn/angular-promise-messages

これを使って先ほどのコードを書き換えると面倒くささから解放されます

```js:app.js
.controller('FooController', function ($scope, $http) {
  $scope.save = function () {
    return $http.post('http://...');
  }
})
```

```html
<promise-messages for-action="save()" state="state" class="btn"
                  ng-class="{'btn-primary': state.none || state.pending}" ng-disabled="state.pending">
  <promise-message when="none">保存する</promise-message>
  <promise-message when="pending">保存中...</promise-message>
  <promise-message when="fulfilled">保存しました</promise-message>
  <promise-message when="rejected">保存に失敗しました</promise-message>
</promise-messages>
```

ほぼプログラムする必要がなくなり、定義だけで実現できるようになりました。
めでたしめでたし

サンプル => http://plnkr.co/edit/EVtjEEaRrgCJffxTBmtg?p=preview
Adobe Premiere: MV作成のための自動マーカー打ち込みスクリプト

この記事は [慶應義塾大学SFC村井&徳田研 Advent Calendar 2015](http://www.adventar.org/calendars/1053) の3日目の記事です。

---

ミュージックビデオを作るとき、大事なのは映像と音楽の同期です。動きとテンポがシンクロしていると、それだけでかっちょいいムービーになります。

しかし、意外にも動画編集ソフトのAdobe Premiereは、自動BPM検出どころか一定間隔でマーカーを打つ機能すらありません。仮にBPM160で5分の動画だと、手動で800個のマーカーを打つ地獄になります。それは嫌です。


## Adobe ExtendScript

Adobe製品のGUIをJavaScript(ES5?)から操作できる「ExtendScript」というものがあります。公式のドキュメントがほぼ皆無なので知名度も低いですが、今回のような単純作業には非常に有用です。

![スクリーンショット 2015-12-03 23.47.23.png](https://qiita-image-store.s3.amazonaws.com/0/60718/573b05cc-1638-b81a-84e9-4eb51cfe1cb5.png)


### マーカーを扱うためのAPI

#### MarkerCollectionオブジェクト
Markerオブジェクトの作成や削除、取得を行えます。

```ts
// MarkerCollection
var numMarkers:number;
function createMarker(t:number):Marker;
function deleteMarker(m:Marker):void;
function getFirstMarker():Marker;
function getLastMarker():Marker;
function getNextMarker():Marker;
function getPrevMarker():Marker;
```

#### Markerオブジェクト
マーカーそのものです。色などのスタイルは操作できません。Premiereには4種類のマーカーがありますが、初期値ではコメントマーカーになります。

```ts
// Marker
var comments:string;
var name:string;
var start:Time;
var end:Time;
function setTypeAsChapter():void;
function setTypeAsComment():void;
function setTypeAsSegmentation():void;
function setTypeAsWeblink():void;
/* 以下略 */
```

#### Timeオブジェクト
タイムコード（時間軸）を扱うために使います。

```js
// Time
var seconds:number;
var ticks:number;
```

## 音源にシンクロしたマーカーの打ち方

例えば0.1秒ちょうどにマーカーを打つコードは以下になります。

```js
var Markers = app.project.activeSequence.markers;
Markers.createMarker(0.1);
```

"ちょうど"と書きましたが、残念ながらこれは嘘で、実際にはGUI上で取得した時間とExtendScriptで指定した時間とでは0.03秒程度ずれます。（なぜ？）
そこで、バッドノウハウ気味ですが最初の拍の位置に手動でマーカーを打って、その秒数をExtendScriptで取得し、BPMに応じて一定間隔でマーカーを追加していくスクリプトにしました。

```js
var MUSIC_LENGTH = 290; // 楽曲の長さ(秒)
var MUSIC_BPM = 130; //　楽曲のBPM

var Markers = app.project.activeSequence.markers;
var firstMarker = Markers.getFirstMarker();
var startTime = firstMarker.start.seconds;
var endTime = startTime + MUSIC_LENGTH;
var interval = 60 / MUSIC_BPM;

for (var i = startTime; i < endTime; i += interval) {
    Markers.createMarker(i);
}
```
![after.png](https://qiita-image-store.s3.amazonaws.com/0/60718/88904915-c09a-9a6b-4335-388ee3b393a6.png)
![final.png](https://qiita-image-store.s3.amazonaws.com/0/60718/6bbafe12-1692-c067-6984-f30a83067221.png)


## おわりに

GUIは直感性などで優れている反面、繰り返しや単純作業が多いとかえって負担になることもあります。
ExtendScriptによって、GUIとCUIの良いとこどりをした制作ができますので、ぜひ活用してみてください。
RailsAdmin が、サーバ起動後にダッシュボードにアクセスしたタイミングでのみ、エラーを吐く件について

# 現象

Rails のプロジェクトに、RailsAdmin を設定して、```[Rails.root]/config/initializers/rails_admin.rb``` にいろいろと設定を加えて、```rails s``` を起動して、routes で設定した rails_admin のダッシュボードを見に行くと、

![スクリーンショット 2015-12-03 23.21.49.png](https://qiita-image-store.s3.amazonaws.com/0/31980/97a3a0a5-4a06-963a-a2ab-bea2c8bcfc44.png)
 
な画面が出て、リロードすると、

![スクリーンショット 2015-12-03 23.22.28.png](https://qiita-image-store.s3.amazonaws.com/0/31980/53bd70d4-2351-31c3-786d-6bcb21d717fe.png)

な画面が出て、さらにリロードすると、ちゃんと正常にrails_adminのダッシュボードが表示される、という、謎な現象が起きて戸惑っておりました。


# 結論を先に言うと

```[Rails.root]/config/initializers/rails_admin.rb``` にタイプミスがあるとこういう現象が起きますよ、と。


# 詳しく話すと

## 前者のエラー

devise を用いて、AdminUser モデルを使ってユーザ認証を行おうとしていたのですが、rails_admin上から変更できるものを絞ろうと include_fields で指定したところ

 * 誤：password_confrmation
 * 正：password_confirmation

という typo をしており、上記をきちんと直せば、最初のエラー画面が出なくなりました。

## 後者のエラー

同様ですね。

 * 誤：iclude_all_fields
 * 正：include_all_fields

こちらを直すと、```rails s``` でサーバを起動した直後から、ダッシュボードの画面が表示されるようになりました。

# typoがあるときとないときの rails_admin の挙動

本来（typo修正後）は、AdminUserの編集画面が下記のようになりました。

![スクリーンショット 2015-12-03 23.23.22.png](https://qiita-image-store.s3.amazonaws.com/0/31980/3b66fd24-6574-b402-5481-8715f06a5eab.png)

これでは想定通りに email, password, password_confirmation, status だけを編集できるようになっています。

typo 修正前、複数回のエラー画面を経た上でアクセスする編集画面は、下記のような画面になっていました。

![スクリーンショット 2015-12-03 23.23.40.png](https://qiita-image-store.s3.amazonaws.com/0/31980/d6259c17-f959-224b-35c5-528c1b4c2a2c.png)

include_fields を設定しない、取り急ぎ、テーブルにあるカラムを全て編集対象にする、という、rails_admin デフォルトの挙動となっています。


# 要は何がいいたいのかと言いますと

typo をするなとは一切述べるつもりはありません。
ただ、include_fields のような箇所を間違えるとただでさえ間違いに気づきにくく、かつ、エラーメッセージも初見ではかなり不親切です。
そして rails_admin は実装が結構複雑というか、コードが 9998行あるファイルとかあって、リファクタリングも厳しいので、ここらへん分かりやすく例外出してよ、というのも、厳しいでしょう（自分はちょっとそこの修正　pull request を送る元気はないです）。

とりあえず、このような地雷を踏んだ人間がいる、ということだけ、ここに記しておきます。
データベース初期構築用のSQLをリポジトリ上のどこのディレクトリに置くか

この記事は [animateLAB Advent Calendar 2015](http://qiita.com/advent-calendar/2015/animatelab) 3日目の記事です。

今日はポエムを書こうと思ってたんですが、考えてた内容が明らかに今日中に書き終わらないので、別のポエムに変えます。あとポエムはさすがに開発者ブログに書くのがはばかられたので、Qiitaのポエムタグにそっと置いておきます。

というわけで、タイトルの通りデータベース初期構築用のSQLをリポジトリ上のどこのディレクトリに置くかという話。MySQLでたとえるとこういうのです。

- CREATE DATABASE
- CREATE USER
- GRANT

RDBMSに依存したサーバーサイドのアプリケーションを初期構築する場合に絶対1度は必要になるはずなのに、GitHub上に.sqlなファイルとして置いてあることが少ない気がします。仮に置いてあったとしても置いてある場所がバラバラで気持ち悪い。代表的な.sql置き場のディレクトリ名として以下のような名称があるのではないかと思います。

- sql
- db
- docs
- misc

`db`や`sql`はDB接続関係のソースコードが置いてあることもあるし、`docs`はちょっと違うんじゃない？（.sqlはドキュメントじゃないよね？）と思うし、`misc`ってディレクトリを切ると何でもかんでもそこに置かれそうだし、なんだかモヤっとするんです。

もしかしたら私が知らないだけでフレームワークによってはきちっと決まっているのかもしれません。 [^1] もしくは、ちゃんとREADMEとかWikiとかに構築方法が書いてあればそれで構わないけど（ドキュメントの中にSQL文がまんま貼られてる例もあった気がする）、なんかちょっと気持ち悪いなと思うのでありました。

まあ、実態としてはDBM（≒データベースおじさん）がいい感じに初期構築してくれちゃうのでリポジトリで管理されず秘伝のタレ化している、というのが真相なのではないかなと推察してます。そもそもCREATE USERなんぞを実行できるのは強力な権限（≒rootやsys）を持っているアカウントに限られるし、結局人間がやるからあんまりリポジトリで管理するメリットがないのかもしれません。でも「結局人間がやるから」って思った瞬間負けだと思うんだよね。うーむ。

[^1]: 例えば、Railsでは [マイグレーション](http://railsdoc.com/migration) という仕組みがあって、「空のスキーマが存在する」ことを前提にCREATE TABLEとかしてくれる。ただ「空のスキーマ」を誰かが作成する必要がある。
Playerに追従するカメラ

Playerタグが付いているオブジェクトを追従するカメラ

最初にカメラとプレイヤーの位置の差分を計算しておき，プレイヤーとの位置を保ち続ける。

```csharp

using UnityEngine;
using System.Collections;

public class CameraControl : MonoBehaviour {

	private GameObject player = null;
	private Vector3 offset = Vector3.zero;

	void Start () {
		player = GameObject.FindGameObjectWithTag("Player");
		offset = transform.position - player.transform.position;
	}

	void LateUpdate () {
		Vector3 newPosition = transform.position;
		newPosition.x = player.transform.position.x + offset.x;
		newPosition.y = player.transform.position.y + offset.y;
		newPosition.z = player.transform.position.z + offset.z;
		transform.position = newPosition;
	}
}
```

カメラの移動をスムーズにしたいときは，LateUpdate内の

```
transform.position = newPosition;
```

この部分をこのようにする。

```
transform.position = Vector3.Lerp(transform.position,newPosition,5.0f * Time.deltaTime);
```
AWS LambdaのScheduled EventでSQSを叩く

これだけ。aws-sdkはLamda環境で自由につかえるからnpmは必要なし。数行のコードなのでAWS Console上で書ける。

**SQLのアクセス許可を追加しないとAPI叩け無いので注意**

```js
var AWS = require('aws-sdk');
var sqs = new AWS.SQS();
var params = {
    QueueUrl: 'https://sqs.ap-northeast-1.amazonaws.com/xxxxxxxxxxx',
    MessageBody: 'hoge'
};

exports.handler = function(event, context) {
    sqs.sendMessage(params, function (err, data) {
      if (err) return context.fail(err);
      
      console.log(data);
      context.done(err, 'Complete');
    });
};
```

LambdaのScheduled Eventのみでバッチ処理を書いてもいいけど、npmをまともに使いたいならElasticBeanstalkでWorker立てて、LambdaはScheduled EventでSQSを叩くだけで処理はEBに任せる方が良さそう。
Milkcocoa・パターン

ネタがなさすぎてヤバい。コードを書かないネタでお茶を濁します。

# パターンご紹介
Milkcocoaをバックエンドとして使うときのパターンがいくつかあるなと思い、それを書くことにしました。自分がMilkcocoaを使ってきたなかで出会った大まかな構成パターンのご紹介です。
名前は適当につけてるので、雰囲気で読み取っていただけたら幸いです。

## Webアプリ⇔Milkcocoaパターン
sendとonSend、pushとonPushなどの送受信をアプリで全部やるパターン。
チャットだったり簡単なアプリケーションを作るときに一番よく使うパターンかと思いますが、実装力があれば本格的なWebアプリだっていけちゃいます。

## Webアプリ(送信専用)⇒Milkcocoa⇒Webアプリ(受信専用)パターン
sendやpushでデータを送る部分と、データを受け取って可視化等をする部分をわけるパターン。
例えばスマホをセンサーとして使うときに便利なパターンで、スマホからはデータを送るページを開くだけでIoTっぽいことが簡単にできちゃいます。

## Webアプリ⇔Node⇔Milkcocoaパターン
アプリ⇔Nodeをsend/onSendでやり取りして、Node⇔Milkcocoaをpush/onPushでやり取りするパターン。
Nodeを途中でかませることで柔軟なデータのチェック等ができますね。MilkcocoaをDBとしてガッツリ使うときはこのパターンがいいのかもしれません。
ちなみにsend/onSendの部分はぶっちゃけそんな手間じゃないのでXMLHttpRequestでやってもいいと思う。

## Webアプリ⇔Node⇔Webサービスパターン
外部のWebサービスのAPIを使ってデータを自前のアプリで使うパターン。アプリ⇔Nodeをsend/onSendでつなぎ、Node⇔WebサービスはNodeでやります。
TwitterのストリームAPIを使ってクライアント作るのに使いました。
これもMilkcocoa使わずXMLHttpRequestでやってもいい感じですね。

## IoTデバイス⇒Milkcocoa⇒Webアプリパターン
送受信分離パターンの送信部分がIoTデバイスになったやつで、現実世界からWebにデータが流れていきます。
Milkcocoaにデータを蓄積させたり、リアルタイムに可視化等、いろいろできます。

## Webアプリ⇒Milkcocoa⇒IoTデバイスパターン
逆に、Webから現実世界にデータを流すことができるパターンです。
個人的にWeb To Thingsと呼んでます。Webから現実世界に影響を与えるってすごい！

## IoTデバイス⇔Milkcocoa⇔IoTデバイスパターン
デバイスとデバイスをMilkcocoaでつなぐパターンです。センサーデータから他のデバイスに何かさせることができます。たとえば人感センサーを備えたデバイスからMilkcocoaを介してLEDをビカビカ光らせるなど。
IoTやるならこのパターンがやりやすいのかもしれませんね。

## データ送信ボタン⇒Milkcocoaパターン
データをMilkcocoaに送るだけ、というパターンです。
これはブログパーツやブックマークレットなんかに使えます。簡易的なアクセスカウンターで使ってます。

# まとめ
なんとかお茶を濁せませたかね…
まとめてみて思ったんですが、意外といろんなパターンがありました。Milkcocoaはそれだけ柔軟な使い方ができるということですね。今後ともいろんな使い方見つけていきたいなと思います。以上Milkcocoa Advent Calendar4日目でした。
画像処理・画像認識を並列計算で高速化させるための資料

読んで理解して、活用しなくては

[「マルチコアを用いた画像処理」SSII 2014 チュートリアル]
(http://www.slideshare.net/FukushimaNorishige/ssii-33751285?related=2)


[「構造化並列プログラミング
－効率良い計算を行うためのパターン－」マイケル・マックール (著), 菅原 清文 (翻訳)]
(http://www.amazon.co.jp/%E6%A7%8B%E9%80%A0%E5%8C%96%E4%B8%A6%E5%88%97%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E2%80%95%E5%8A%B9%E7%8E%87%E8%89%AF%E3%81%84%E8%A8%88%E7%AE%97%E3%82%92%E8%A1%8C%E3%81%86%E3%81%9F%E3%82%81%E3%81%AE%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-%E3%83%9E%E3%82%A4%E3%82%B1%E3%83%AB%E3%83%BB%E3%83%9E%E3%83%83%E3%82%AF%E3%83%BC%E3%83%AB/dp/4877833056)



データ並列
map
 「すべての要素を並列化し、要素ごとに計算する。各要素に依存性無し」
 pixelごとの処理、色空間の変換、ガンマ特性の変換、閾値処理などが該当する。
 大きさが同じ行列の加算
\#pragma omp parallel for
 上記スライドp.51

　SIMDが実行できる場合だとSIMDを実行すること。
　「画像を色変換して、画像間の差分をとって、閾値処理をする」という例はmapというカテゴリに属すようだ。
　このような処理の段数が深い場合には、メモリ転送を生じてもGPUによる並列化の効果は、SIMDを上回ることもありそう。
　


stencil
 上記スライドp.40、p.55～p.59 4重ループの平滑化フィルタ
 OpenMP による並列化
私見：FPGAを利用すると内側の2つのループが、回路として展開されてscanという動作になりそうだ。

 

reduction
p.53 ～　p.54
OpenMP による並列化
\# pragma omp parallel for reduction(+:rec)
 
私見：機械学習の分野でMapReduceという枠組みがあるが、map処理とreduce処理とがある。これと対応してそうだ。

>MapReduce の特徴は、MapとReduceの各ステップで並列処理が可能なことである。それぞれのMap処理は、他のMap処理と完全独立であり、理論的に全て並列実行することができる（実際には、データソースやCPUの数により制限がかかる）。続くReduceステップでは、Mapステップでの処理結果がキー毎にまとめられてReduce処理に送られることになるが、これも同様に並列処理が可能である。(ウィキペディアからの引用)
[MapReduce](https://ja.wikipedia.org/wiki/MapReduce)

scan

プロセス並列
Fork-join
　マルチコアの階層での並列化であって、GPUのような並列化ではない。
　C++もC++11になってスレッドが強化されている。
pipe-line
という典型例に着目すべきであるようだ。




[「アセンブラ画像処理プログラミング　-SIMDによる処理の高速化」](
http://www.amazon.co.jp/%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9%E7%94%BB%E5%83%8F%E5%87%A6%E7%90%86%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E2%80%95SIMD%E3%81%AB%E3%82%88%E3%82%8B%E5%87%A6%E7%90%86%E3%81%AE%E9%AB%98%E9%80%9F%E5%8C%96-%E5%8C%97%E5%B1%B1-%E6%B4%8B%E5%B9%B8/dp/4877831398)

追記：
　dandelion1124さんによる記事 [cv::Mat::forEachを使った高速なピクセル操作](http://qiita.com/dandelion1124/items/94542d8cd7b3455e82a0)

[パフォーマンスのグラフ](https://qiita-image-store.s3.amazonaws.com/0/31158/ac9236a5-f561-7d32-45ae-efa952848497.png)
 上記のmapに相当する処理で高速化が期待できそうだ。マルチコアでのmap演算が速くなるようだ。

この内容がcv2.pydに反映できるのかどうかが気になります。
INSTALL_PARSE_FAILED_MANIFEST_MALFORMED

# INSTALL_PARSE_FAILED_MANIFEST_MALFORMED

Android開発でapkをインストールする時にこんなエラーが出ることがありました。

検索すると最近の記事で出てくるのは、

* [apk転送時に「INSTALL_PARSE_FAILED_MANIFEST_MALFORMED」というエラーが出た場合の対処方法](http://mrkagerou.blogspot.com/2015/05/apkinstallparsefailedmanifestmalformed.html)
* [Android アプリビルド時に packageNameSuffix を使った時にはまったこと](http://vividcode.hatenablog.com/entry/android-app/build-types-packagenamesuffix)
* [Android - INSTALL_PARSE_FAILED_MANIFEST_MALFORMED ](http://kabagaeru.blogspot.com/2015/10/android-installparsefailedmanifestmalfo.html)
* [[Android]INSTALL_PARSE_FAILED_MANIFEST_MALFORMED
](http://blog.rabisoft.com/?p=219)

といろいろありました。
要はAndroidManifest.xmlの中で引いているActivityやApplicationクラスの名前が、補完されるような指定だと、package名が動的に変わる場合などはビルドはできてもパースに失敗してインストールできないよ、ということでした。

AndroidStudioになって、ビルド時に動的にManifestの書き換えが簡単になりましたが、パッケージ名（`applicationId`）がbuildTypeやflavorによって変わる場合は完全修飾名でクラスを指定しないといけません。
また、パーミッションやプロバイダー定義項目などのリソース参照も怪しいみたいです。

## 自分の場合

ちなみに僕の場合は全然これらと違って、

```xml:AndroidManifest.xml
        <activity-alias
                android:name=".LaunchActivity"
                android:targetActivity=".MainActivity"
                >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity-alias>

        <activity
                android:name=".MainActivity"/>
```

のように書いてしまっていたからでした。
この場合は.MainActivityを`activity-alias`で参照していますが、`activity`の定義部よりも前で参照してしまっていたため見つからなかったようです。

`activity`と`activity-alias`の順番を入れ替えて`activity`を先に宣言すればいいだけでした。
deploygateのコマンドラインツールでiOSアプリを簡単デプロイ

この記事はモバイルDevOpsカレンダーの3日目です。

お仕事ではiOSアプリを書いています。
今日は巷で噂のdeploygateのコマンドラインツールについて紹介します。

# GitHubリポジトリ
[DeployGate/deploygate-cli](https://github.com/DeployGate/deploygate-cli)


# どこが便利なのか
xcodeからarchiveしてOrganizerからipaファイルをexportし、
deploygateを開きアプリを選択し、ipaファイルをアップロードする。
この一連の動作がコマンドラインから
```
$ dg deploy [ios project path]
```
でbuildとuploadをよしなにやってくれる！簡単！最高！

# インストール
gemで簡単インストール
```
$ gem install deploygate
```

# 使う
dgコマンドは次のコマンドがある。　
* login
* deploy
* logout
* config
* help

## dg login
おもむろに `dg login` と叩いてみると、Emailとpasswordを聞かれます。
普段使っているdeploygateのアカウントのものを入力しましょう。

```
$ dg login                                                                                                
Welcome to DeployGate!
         _            _                       _
        | |          | |                     | |
      __| | ___  ___ | | ___ _   ,____   ___ | |_ ___
     / _` |/ _ \' _ \| |/ _ \ \ / / _ \ / _ `| __/ _ \
    | (_| |  __/ |_) | | (_) \ v / (_| | (_| | |_' __/
     \___, \___| .__/|_|\___/ ` / \__, |\__,_|\__\___`
               |_|           /_/  |___/

Email: kiy0p0n@sample.co.jp

Checking for your account...

Password: ********************

Hello kiy0p0n!
```

イケてる

## dg deploy
アプリをdeploygateに新規作成、または新しいverのアップロードができます。
```
$ dg deploy [ios project path]
```

### オプション
* `--message STRING`  
アップロード時にメッセージを追加する
* `--user STRING`  
owner name, group nameを指定できる
* `--open`  
upload完了後にdeploygateのappページをブラウザで開く(OSXのみ)
* `--disable_notify`  
メールの通知をしない(iOS appのみ)

### コマンド例
* oyabunがownerのappをメッセージをつけてアップロード  
`$ dg deploy --message "task complete" --user oyabun [ios project path]`
* アップロードが終わったらブラウザでappのページを開く、メールでも通知はしない  
`$ dg deploy --open --disable_notify [ios project path]`

## dg logout
アカウントの切り替えをしたい時に、ログアウトができます。
`dg login` で再度ログインできる。

## dg config
ログイン中のユーザのコンフィグが見れる

### オプション
* `--json`  
json形式でログイン中のユーザの情報を出力
* `--name STRING`  
DeployGateのユーザ名を出力
* `--token STRING`  
ユーザのapi tokenを出力

## dg help
ヘルプが見れる。困ったら積極的に見よう。

# その他
* ios projectがworkspaceを使っている場合は、 `dg deploy` 時にbuild対象とBundle Identifierを聞かれる
* `dg deploy` に失敗した時に `Do you want to report this issue on GitHub? (y/n) |n| y` と聞かれて、Backtraceが入った状態でIssue立ち上がる

# まとめ
deplogateのコマンドラインツールで簡単にbuildとuploadができるようになった。
いつもdeployしていた時間におやつが買いに行けるようになった。
ebiでビューの作成

シンプルなビューを表示します。
ビューは resources/templates ディレクトリに設置します。
ここでは２つの新しいビュー 「layout.html」「users.html」をこのディレクトリに作成します。

```resources/templates/layout.html
<html>
	<body>
		<h1>ebiクイックスタート</h1>

		<rt:block name="content"></rt:block>
	</body>
</html>

```

```resources/templates/users.html
<rt:extends href="layout.html" />

<rt:block name="content">
	Users!
</rt:block>
```

ebiはテンプレートエンジンも内蔵しています。
テンプレートの継承などパワフルな機能性と同時にifやloopなどの典型的な制御構文の使いやすい代用構文を提供しています。詳細は[Templateのドキュメント](https://github.com/tokushima/ebi/wiki/テンプレートエンジン(ebi.Template))をご覧ください。


routes.php を開き（または作成し）ルートを定義します。

```routes.php
<?php
include('ebi.phar');

\ebi\Flow::app([
	'users'=>['template'=>'users.html']
]);
```

Webブラウザーで routes.php/users へアクセスすればレスポンスとしてHTMLが表示されます。
これはtemplateが定義されているためです。



> ![スクリーンショット 2015-12-03 23.19.52.png](https://qiita-image-store.s3.amazonaws.com/0/32758/248a2a2c-32aa-4943-b591-ea2c49cfab27.png)



参考:
https://github.com/tokushima/ebi
http://readouble.com/laravel/4/2/0/ja/quick.html
[python] リストの要素の確認　all, any

#リストの各要素がある確認したい時
リストのすべての要素にちゃんと値が入っているか確認したい時とかに使います。
例えば、リストを最初に[[], [], []]と初期化し、ある処理を加えた後、すべての要素に値がちゃんと入ってるか確認する時とか。

#all(iterable) 
組み込み関数のall
この関数は、iterableの要素が全て真であればTrueを返す
真は、数字であれば0以外、文字であれば''以外、リストであれば[]以外のとき etc...
なので中でやってる事は,こんな感じ多分
#
```all.py
def all(iterable):
    for x in iterable:
       if not x: return False
    else: return True
```

#any(iterable)
組み込み関数のany
この関数は、iterableの要素一つでも真であればTrueを返す
中でやってる事は、
#
```any.py
def any(iterable):
    for x in iterable:
       if x: return True
    else: return False
```


#簡単な例
```easy_example.
>>> a = [1,2,3,4,5]
>>> all(a)
True
>>> any(a)
True
>>> a = [0,1,0,0,0]
>>> all(a)
False
>>> any(a)
True
>>> a = [0,0,0,0,0]
>>> all(a)
False
>>> any(a)
False
```

# まとめ
all(): iterableの各要素が真ならTrueを返す。
any(): iterableの要素が一つでも真ならTrueを返す。
slack分報を導入してみた


社内でも分報がバズって取り入れる人増えてきましたが
中にはtwitterのようなただの「つぶやき」や「感情の垂れ流し」になってしまったり
逆に一日中何を書けばいいのか解らなくて書けない人が居たりと気になったので
自分なりの考えを書いてみたいと思います。


Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
http://c16e.com/1511101558/


# 分報ルール
①タスクの開始時に見積もり時間を宣言
②１５分起きくらいに進捗と経過時間を記載
③終了時に余日書いて結論を簡単に書いて終了
④一日の終りに振り返ってPDCA回す。

②は集中を阻害しない程度に気がついたら書くくらいで。
ただタスクが割り込んだ場合は開始終了を明確にするためにちゃんと書くって感じでしょうか。

④の振り返りは大体このパターンが多い気が・・
C->見積もりずれてた A->タスクを細分化する  P->見積もりがずれないタスクを増やす



# 目的を明確にする
こういうのは目的を整理するのがセオリーですが
自分としてはこんな感じに優先度つけて意識してます

1.タスクの開始時に見積もりを宣言することで１５分単位くらいで予実を合わせに行く
2.予想よりもずれそうな場合は最速で１５分後にアラートをキャッチできる
3.詰まっていること、わからないことを書けば他の人が助けてくれるかもしれない
4.他の人の分報を見ることでぼんやり他の人が何を考え何が出来るヒトか見えてくる
 -> 組織に「弱いつながり」や「トランザクティブメモリー」を醸成する
 -> 4は日報の機能と一緒ですが。日報よりレスしやすいので効果が高くなりそう

世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア
http://www.amazon.co.jp/%E4%B8%96%E7%95%8C%E3%81%AE%E7%B5%8C%E5%96%B6%E5%AD%A6%E8%80%85%E3%81%AF%E3%81%84%E3%81%BE%E4%BD%95%E3%82%92%E8%80%83%E3%81%88%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B%E2%80%95%E2%80%95%E7%9F%A5%E3%82%89%E3%82%8C%E3%81%96%E3%82%8B%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%81%AE%E7%9F%A5%E3%81%AE%E3%83%95%E3%83%AD%E3%83%B3%E3%83%86%E3%82%A3%E3%82%A2-%E5%85%A5%E5%B1%B1-%E7%AB%A0%E6%A0%84/dp/4862761097


#分報に対して
個人的にはエンジニアにかぎらず
コンサルタントみたいなノウハウ集約型の業務でやればかなりハマるんじゃないかと思います。



#分報って
名前がハイパーダサいんで
誰かかっちょいい名前つけて欲しいｗ
Apple Watchアプリの作り初め

# watchOS2なアプリを始めるための用語理解
watchOS 2になって時計再度ででいろいろ処理できるようになったからいろいろアプリ作れるやないか！
と思ってたけど、いろいろバタバタしてもう3ヶ月くらい。困ってたこと思い出しながら、ドキュメントも充実してきてるのでメモメモ。
始めるにあたって、ささっとやるだけであっても、用語理解とライフサイクルの理解等は、真剣にやっとかなあかんなぁと思いました。

内容はこれの要約の要約みたいなもんです。
https://developer.apple.com/library/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/index.html#//apple_ref/doc/uid/TP40014969-CH8-SW1

## 環境
|OS|Version|
|:-----:|:----:|
|Mac OS|Mac OS X Yosemite|
|iOS|9.1|
|watchOS|2.0|
|Xcode|7.1.1|

## 基礎用語

|用語|説明|
|:-----------:|:------------:|
|Watchアプリケーション |実際のAppleWatchのアプリケーション |
|WatchKitExtention|WatchアプリケーションでUIやらリソースを保持しているもの|
|グランス|下から画面をスワイプしたときに出てくるやつ。1画面で完結する必要有り。|
|コンプリケーション|時計の画面に出てくる小さい要素|


## 基本的なフレームワークの立ち位置。

下図で言うところのwatch OSとiOSの会話をConnectivityFrameworkでやっている。

![20151129123803.png](https://qiita-image-store.s3.amazonaws.com/0/103725/374785e8-6345-98f5-11f6-3ff61993ad66.png "20151129123803.png")

## 簡単な実装を行うための用語準備
まず必要なクラスとしてInterface ControllerというWKInterfaceControllerを継承したクラス。
iOSで言うところのViewControllerに似ているが、描画を直に担当してるわけじゃなさそう。

## 画面遷移(インターフェースナビゲーション)
基本的にはページベースと階層型ってのに分かれるらしい。
モーダルって便利アイテムもアリ。
(個人的には「ページベースの中で階層型を使うためのもの」に誓い解釈をしている。)

### ページベース　並列に並んでる感じ(下にチョボがあって横スライドする感じのやつ)
storyboardでControlドラッグして別のInterfaceControllerに繋げば実装可(iOSでmodalとかする感じ)このつながりをセグエって言うらしい。
didAppearやらwillDisappearメソッドでビューがアクティブかどうかを判別
### 階層型　読んで字のごとく(左上に戻る<的なのがあるやつ)
pushControllerWithName:context:メソッドで遷移
### モーダル　上記２個とは別枠で、iOSと同じく親子な感じで遷移するやつ
presentControllerWithName:context:メソッドで単一InterfaceControllerをモーダル
presentControllerWithNames:contexts:メソッドで複数をページベースでモーダル

### グランス
常に最新情報が必要なのでwillActivateに更新処理を含めると吉
StoryBoardにて、右下からGlance Interface Controllerを引っ張ってきて乗せれば基本的にOK
「１画面でわかりやすく表示するぜ！」というポリシーで作成しろとのこと。

## 通知
### 通知の種類(ローカルorリモート)

|通知|仕組み|
|:-----------:|:------------:|
|ローカル通知|iOS側で完結|
|リモート通知|外部からのプッシュ通知|

### 通知の種類(通知画面の種類)

|通知画面|仕組み|
|:-----------:|:------------:|
|ショートルック|通知来た時に出るやつ。あんまりカスタマイズできない。|
|ロングルック|ショートルックの中でも詳細見たいときのやつ。レスポンスの変更も可(スタンプ送る、的な)|

### 通知の画面での表示領域
通知の画面で出てくる表示を３つに領域分けしている

|領域|内容|
|:----:|:---:|
|sash領域|アイコンとラベル|
|content領域|内容。カスタムロングルックインターフェースで設定可|
|bottom領域|ボタンが配置される場所なイメージ|

### content領域の表示方式
・スタティックインターフェース　必須　下記ケースで表示される
　ダイナミックインターフェイスがない
　電力が不足している
　開発者が明示的に表示しないよう指示
・ダイナミックインターフェース　categoryが一致しているものを表示する。ちょっとおしゃれな感じに加工できる。
　1.WKUserNotificationInterfaceControllerのサブクラス作成
　2.Has Dynamic Interfaceをon
　3.インターフェースにクラスを関連付け
![20151129135626.png](https://qiita-image-store.s3.amazonaws.com/0/103725/d548d6db-4080-51eb-12a2-0fb7f9c93b95.png "20151129135626.png")


### まとめ
基本的にこれだけのイメージが最初にあれば、設計もある程度できる気がするしとっつきやすい気がする。
ドキュメントがいかに整備されてても、「どうスタートしたものか....」ってなるのがAppleやなぁ(玄人志向やなぁ)と俺は思う。
まぁ日本語ドキュメントがあんま無いからってだけやから、英語勉強せぇ言う話やねんけどね。

気が向いたらぼちぼち実装してgithubにでも
Google Play Developer Console をマスターするための10の方法

Youtubeで公開されている下記ビデオの内容をまとめてみました。

> Youtube: Android Developers
> [10 tips to master the Google Play Developer Console](https://www.youtube.com/watch?v=8RwOVvlBTT8)

[![10 tips to master the Google Play Developer Console](http://img.youtube.com/vi/8RwOVvlBTT8/0.jpg)](https://www.youtube.com/watch?v=8RwOVvlBTT8)

## 1. ベータテストの実施

- 一部のユーザからフィードバックを集め、品質を向上してから公開
- `[APK]` タブからユーザをベータテストに招待、フィードバックをもらう

## 2. 段階公開

- 人数を限定して段階的に公開
- 世界中で大問題になる前に修正が可能

## 3. アプリ紹介ページ（掲載情報）のテスト機能

- 最大3種類のアイコン、テキスト、画像を設定可能
- 効果テストによりデータに基づいた掲載情報の改善

## 4. レビューに返信

- 評価やレビューを見ると、アプリのどこが好きでどこが不満か分かる
- レビューに返信することで対話と信頼関係が生まれる

## 5. Optimization tips を活用

- ディベロッパーコンソールではアプリのパフォーマンスを計測している
- 合わせてアプリ改良のヒント（Optimization tips）を提供しているので、こちら参考にアプリを改良

## 6. App Indexing を有効活用

- 有効にすることでGoogle検索結果に「アプリ内コンテンツへのリンク」が表示
- アプリをインストール済みのユーザーが便利な機能を再発見してくれる可能性も
- App Indexing を追加したらDeveloper Console から確認出来る

## 7. Google Analyticsと連携

- 連携することで新規・アクティブユーザーに関するレポートや指標を追加出来る
- 例えば、新しい指標である「参照フロー（Referral Flow）」は「ユーザーがどのようにアプリを見つけた」かが分かる

## 8. 警告メールを設定

- 警告メールにより評価の急激な下落や、突然のクラッシュ数増加に迅速な対応が可能

## 9. 統計情報の抽出・分析

- 重要な統計情報をエクスポートして、アプリやユーザーの行動を分析
- 例えばインストール、アップグレード、レビュー、評価、クラッシュなど
- 詳しく分析することでユーザーにとって重要な改善点に集中出来る

## 10. アプリの公開・管理作業を自動化

- 自動化することで時間の節約になり、また簡単に最新状態を保つことが出来る
- 例えば、アルファ版テスターへの配信時に発生するローカライズ用のテキスト・画像更新、アプリ内アイテムの管理などを自動化すればアプリは常に最新

## さいごに

さらに詳細・有益な情報を入手したい場合は、関連動画の参照、また The Secrets to App Success を Google Play 上からダウンロードしましょう

https://play.google.com/store/books/details?id=O2a5CgAAQBAJ
ChainerをMac OSXでビルドする


Macでビルドできないよ、という報告を受けたのでMacでビルドできないか探っていたのですが、実はマシンにnVidia GPUがなくてもビルドはできることがわかったので、そのときやったことを報告をします。この記事は必ずしも、Macで **動作することを保証しません**　。残念ながら、nVidia GPUの乗ったMacを持っていません・・・。

# CUDAのインストール

公式サイトに行って、Mac用のCUDA 7.5をダウンロードします。インストーラーを起動すると、nVidiaのドライバとCUDAのインストールが促されますが、両方共インストールできます。とりあえず入れてみます。実はこれで入ります。
注目すべきは、ディレクトリ構成です。別件で書きましたが、以下のようになっています。注目すべきは、`libcuda.dylib`が`/usr/local/cuda/lib`にしか入っていないことです。他のファイルは、`/Developer`ディレクトリ以下へのシンボリックリンクになっているようです。そのため、Chainerでは、このディレクトリを強制的にライブラリのパスに追加するようにしました。EI Capitanだとどうなるんでしょうね・・・。怖くて試していません。

```
+ usr
| + local
|   + cuda
|     + bin --> /Developer/NVIDIA/CUDA-7.5/bin
|     + include --> /Developer/NVIDIA/CUDA-7.5/include
|     + lib
|       + libcuda.dylib
|       + libcublas.dylib --> /Developer/NVIDIA/CUDA-7.5/lib/libcublas.dylib
+ Developer
  + NVIDIA
    + CUDA-7.5
      + bin
      | + nvcc
      + include
      | + cublas.h
      + lib
        + libcublas.dylib
```

# インストール

あとは普通にインストールします。ふつうにCythonが走ってインストールできます。pyenv推奨。

```
$ pip install chainer
```

# 動作確認

動作しないのをわかっていながら動かしてみたら、実行時エラーになりました。Macbook Airだしね。動いた方はご報告を（？）・・・。

```
% python
Python 3.4.1 (default, Sep 15 2014, 13:51:31)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cupy
>>> cupy.array([1])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/unno/.pyenv/versions/3.4.1/lib/python3.4/site-packages/cupy/creation/from_data.py", line 27, in array
    return core.array(obj, dtype, copy, ndmin)
  File "cupy/core/core.pyx", line 1524, in cupy.core.core.array (cupy/core/core.cpp:51766)
  File "cupy/core/core.pyx", line 1543, in cupy.core.core.array (cupy/core/core.cpp:51519)
  File "cupy/core/core.pyx", line 107, in cupy.core.core.ndarray.__init__ (cupy/core/core.cpp:5117)
  File "cupy/cuda/memory.pyx", line 250, in cupy.cuda.memory.alloc (cupy/cuda/memory.cpp:5101)
  File "cupy/cuda/memory.pyx", line 230, in cupy.cuda.memory._malloc (cupy/cuda/memory.cpp:5040)
  File "cupy/cuda/memory.pyx", line 231, in cupy.cuda.memory._malloc (cupy/cuda/memory.cpp:4955)
  File "cupy/cuda/memory.pyx", line 28, in cupy.cuda.memory.Memory.__init__ (cupy/cuda/memory.cpp:1358)
  File "cupy/cuda/device.pyx", line 51, in cupy.cuda.device.Device.__init__ (cupy/cuda/device.cpp:1299)
  File "cupy/cuda/runtime.pyx", line 127, in cupy.cuda.runtime.getDevice (cupy/cuda/runtime.cpp:2048)
  File "cupy/cuda/runtime.pyx", line 106, in cupy.cuda.runtime.check_status (cupy/cuda/runtime.cpp:1815)
cupy.cuda.runtime.CUDARuntimeError: cudaErrorInsufficientDriver: CUDA driver version is insufficient for CUDA runtime version
>>>
```