OmniAICreator/Qiita-1.07M huggingface dataset:
Docker for Macのファイル共有が遅いので計測してみる

この記事は[WHITEPLUS Advent Calendar 2016](http://qiita.com/advent-calendar/2016/whiteplus) 20日目になります。

開発環境整備担当 kai-zoa です。

多くの現場でそうだったように、リネットの開発環境も今年からDocker ToolboxからDocker for Macに移行したのですが、macOSだととにかくマウントしたボリュームのファイルアクセスが遅くて毎日不満です。

このあたり、共有ファイルシステムのマウントじゃなくてファイルを即時同期したり、もういっそLinux使うなどして一部やり過ごしてるようですね。

[Qiita - docker-syncでホスト-コンテナ間を爆速で同期する](http://qiita.com/pocari/items/0340049742927f3a94b7)

いまはDockerのosxfsが改良されますようにと願うばかりですが、一応Docker for Macのアップデートの度に改善を見守りたいので、見守り用に簡単にGoでベンチマークするコードを書いてみました。

# ソース
簡単に165KBのgopher画像を読み取りだけします。

```go
package main

import (
	"os"
	"testing"
)

func _read(path string, bufSize int) error {
	f, err := os.Open(path)
	if err != nil {
		return err
	}
	defer f.Close()

	buf := make([]byte, bufSize)
	for {
		n, err := f.Read(buf)
		if n == 0 {
			break
		}
		if err != nil {
			return err
		}
	}
	return nil
}

func BenchmarkReadContainerFile_Buf128(b *testing.B) {
	for i := 0; i < b.N; i++ {
		err := _read("/tmp/gophercolor.png", 128)
		if err != nil {
			panic(err)
		}
	}
}

func BenchmarkReadContainerFile_Buf1024(b *testing.B) {
	for i := 0; i < b.N; i++ {
		err := _read("/tmp/gophercolor.png", 1024)
		if err != nil {
			panic(err)
		}
	}
}

func BenchmarkReadVolumeFile_Buf128(b *testing.B) {
	for i := 0; i < b.N; i++ {
		err := _read("./gophercolor.png", 128)
		if err != nil {
			panic(err)
		}
	}
}

func BenchmarkReadVolumeFile_Buf1024(b *testing.B) {
	for i := 0; i < b.N; i++ {
		err := _read("./gophercolor.png", 1024)
		if err != nil {
			panic(err)
		}
	}
}
```

https://github.com/WHITEPLUS/advent-calendar2016-docker-volume-bench

# 結果
```bash
./bench.sh
testing: warning: no tests to run
BenchmarkReadContainerFile_Buf128-4         2000            567241 ns/op
BenchmarkReadContainerFile_Buf1024-4       20000             76948 ns/op
BenchmarkReadVolumeFile_Buf128-4             500           2959713 ns/op
BenchmarkReadVolumeFile_Buf1024-4            500           2683988 ns/op
PASS
ok      bench-fio       6.927s
```

extremely slow!!

これからも見守っていきますが、そろそろ暫定的になにかしていかないとなぁ

#明日
knakamigawaのフロントエンドの話ですっ

#ホワイトプラスではエンジニアを募集しています
ホワイトプラスでは、[新しい技術にどんどん挑戦したい！という技術で事業に貢献したいエンジニアを募集](https://www.wantedly.com/projects/69257)しております。!
python,ruby,PHPで動的プロキシ

## はじめに

この記事は「WACUL Advent Calendar 2016」の20日目です。
最近、個人的にメタプログラミングrubyを読み返したのと仕事で一部使ったり~~語れる新鮮なネタが無い~~といった経緯があり、今回は動的プロキシについて書きます。

## 動的プロキシとは

実は、この言葉がどこまで一般的なのか自信がないのですが…　個人的には「定義してないメソッドの名前とパラメータを受け取って、目的の処理を別のオブジェクトに委譲するようなプログラミングパターン」と認識しています。

## どんな時に使うのか

外部システムのラッパーを書きたい時に便利です。

例えば、外部のREST apiを利用するクライアントライブラリを書きたいとします。話を単純にするために、GETに限定して考えます。

GET /api/hoge

を実行するには、例えばpythonでrequestsを使えば

```python
import requests

class Client:
    def hoge(self):
        return requests.get('/api/hoge')

client = Client()
client.hoge()
```

などすれば良いです。何も難しくありません。
しかし、この場合だとfuga,piyoなど増えてくると

```python
class Client:
    def hoge(self):
        return requests.get('/api/hoge')
    def fuga(self):
        return requests.get('/api/fuga')
    def piyo(self):
        return requests.get('/api/piyo')
```

などとコピペが増えてきて大変です。

そこで、「メソッドやプロパティが見つからない時に呼ばれる特殊メソッド」を使います。pythonの場合メソッドもプロパティも等しくオブジェクトの属性なので、```__getattr__ ``` が使えます。

```python
class Client:
    def __getattr__(self, name):
        def _func(*args, **kwargs):
            return requests.get('/api/' + name)
        return _func
```

これで、client.hoge()もclient.fuga()もclient.piyo()も対応できますし、何より良いのは今後さらにapiが追加されてもClientクラスをメンテする必要がありません。また、```_func```の実装次第ですが、client.method に渡すパラメータを自由にハンドリングできます。

## RubyとPHPで動的プロキシ

まず、Rubyでやります。今回は単純にコード量を減らすだけでなく、未知の仕様にまで動的に対応させたいのでmethod_missingを使います。

```ruby:a.rb
class A
  def method_missing(name, *args, &blk)
    p name.to_s
    p args
    return if not block_given?
    blk.call
  end
end

a = A.new
a.hoge
a.fuga(1, 2, 3)
a.piyo do |i, j|
  p "piyopiyo"
end
```

実行するとこうなります

```
"hoge"
[]
"fuga"
[1, 2, 3]
"piyo"
[]
"piyopiyo"
```

次にPHPです。```__call```を使います。昔、仕事で書いていた~~書かされていた~~時に覚えました。Reflectionと組み合わせると良い感じです。静的メソッドの場合は ```__callStatic```という別のメソッドが用意されています。

```PHP:a.php
<?php

class A
{
    public function __call($name, $args)
    {
        var_dump($name);
        var_dump($args);
    }
}

$a = new A();
$a->hoge();
$a->fuga("fugaarg");
```

cliで実行するとこうなります

```
string(4) "hoge"
array(0) {
}
string(4) "fuga"
array(1) {
  [0]=>
  string(7) "fugaarg"
}
```

## 注意すること

使いすぎると挙動を読みづらいコードになりがちです。ご利用は計画的に。
babel plugin 入門: ソースコードの行番号を出力させてみる

こんにちは！ @kumabook です。

僕は学生時代からJavaScriptを使い始めていて、
色々ダメなところもあるけどなんだかんだ言ってみんながいつも使っているブラウザというプラットフォームの上で動いているJavaScriptという言語が好きです。

最近はes6やtypescriptと言われていますが、便利になったなーと思う反面、
es3は覚えることは少なくてよかったなーと思うこともあります。その分、ワナも多かったわけですが。

で、es6 といえばbabel流行ってますよね。

ASTいじるツールがここ２年・３年乱立していた感ありましたが、babel 6でbabelに集約されていくのかなと思っています。

僕も前にesprimaとかを使ってASTをいじって遊んだことがありましたが、
これからはbabel-pluginだろうということで、簡単なpluginを作って入門してみたいと思います。

babel-plugin入門に当たってですが、[plugin-handbook](https://github.com/thejameskyle/babel-handbook/blob/master/translations/ja/plugin-handbook.md)　をめちゃくちゃ丁寧にまとまってました。

あと、シンプルで実際に動くpluginは [ここ](https://github.com/babel/babili/tree/a0922fc439003a6039a5e3a20cde982f21f7cf93/packages)

に結構あったので参考になりました。

で、今回は、行番号つきでデバック出力してくる`__DP__()` という関数(マクロみたいなもの？)を作ってみました。chrome developer toolとかはconsole.logに行番号出してくれますが、レガシーな環境ではそうも行かないことがあるので、前から欲しいと思っていたものです。

```js

"use strict";

module.exports = function({ types: t }) {
  return {
    name: "transform-debug-print-function",
    visitor: {
      CallExpression(path) {
        var line = path.parent.loc.start.line;
        if (isDebugPrintFunction(path.node)) {
          path.replaceWithSourceString(`console.log('[DP]: line ' + ${line})`);
        }
      },
    },
  };
  function isDebugPrintFunction(node) {
    return t.isCallExpression(node) &&
           t.isIdentifier(node.callee, { name: "__DP__" });
  }
};
```

`__DP__`を 行数付きの`console.log`にreplaceするという大変雑な作りですが、

```
var name = "babel plugin";

console.log("hello " + name);
__DP__();
```

これが


```
"use strict";

var name = "babel plugin";

console.log("hello " + name);
console.log('[DP]: line ' + 4);
```

こうなるようにできました。

https://github.com/kumabook/babel-plugin-sample

簡単なbabel-pluginですが、実際に手を動かして作ってみると
完全にブラックボックスだったbabelも少しだけ理解できた気がします。

明日は @aTomoyaKubo です！
Webpack2 と 最小限の babel transform で Chrome で動くJSを

先に言っておくと、IE11は死ぬ。

## 何がしたいか

前提として、現代では ES Modules を除けばほとんどのモダンブラウザ(IE11を除く)でES2015は実装が終わりつつあり、IE11のような特定の環境を除けばほんのすこしの変換でES201xのコードが動く。うまくやれば、コンパイル時間もbabelの起動時間も短縮できる。何度も言うがIE11は死ぬ。

それと、先週リリースされたChrome55でasync/awaitがデフォルトで有効になった。これで何ができるかというと、babel で　async/await をコンパイルすると、CPS変換で巨大なスイッチ文に変換してとにかくコードが読みづらいという問題があって、それをネイティブの機能を使うことで解決できる。(ソースマップもよくわからんところに吹っ飛んで使えなかった)

## このアプローチを試みた際の問題

browserify/webpack(1) は requireでcommonjsを解決するのにASTのパース、変形を行うのだが、その入力としてES5水準のコードまでコンパイルされていることを想定しているため、ES2015のコードを食わせるとどちらも死んでしまう。

なのでそのあたりが考慮されてて、かつasync/awaitも通せるwebpack2を使った。本当は browserifyの方が好きだがパーサに介入できる気配がないので、substack がその必要に気づくまで待つ。

## 設定

```json:.babelrc
{
  "plugins": [
    "syntax-async-functions",
    "transform-decorators-legacy",
    "transform-class-properties",
    "transform-object-rest-spread",
    "transform-react-jsx",
    "transform-flow-strip-types"
  ]
}
```

```json:package.json
{
  "dependencies": {
    "babel-core": "^6.21.0",
    "babel-loader": "^6.2.10",
    "babel-plugin-syntax-async-functions": "^6.13.0",
    "babel-plugin-transform-class-properties": "^6.19.0",
    "babel-plugin-transform-decorators-legacy": "^1.3.4",
    "babel-plugin-transform-flow-strip-types": "^6.21.0",
    "babel-plugin-transform-object-rest-spread": "^6.20.2",
    "babel-plugin-transform-react-jsx": "^6.8.0",
    "webpack": "2.1.0-beta.25",
    "webpack-async-await": "^1.1.0"
  }
}
```


```js:webpack.config.js
const webpack = require('webpack');
const AsyncAwaitPlugin = require('webpack-async-await') ;

module.exports = {
  entry: './src/main.js',
  output: {
    path: "public",
    filename: 'bundle.js'
  },
  plugins: [
    new AsyncAwaitPlugin({})
  ],
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader',
        exclude: /node_modules/
      }
    ]
  }
};
```

想定してるディレクトリは

```
- .babelrc
- webpack.config.js
- package.json
- public
    -  bundle.js
-  src
    -  main.js
```

で、`$ webpack` と叩くとビルドされる。自分の趣味で flowtype とか jsx とか入ってるけどこの辺はいらない人はいらないだろう。

webpack-async-await は 中で使ってる acorn に async-awaitのパーサを足して落ちないようにしてる感じのコードだった。ワークアラウンドなのでそのうちいらなくなるとは思う。

## 結果

![](https://i.gyazo.com/89583ff0decf1cab3c9f43d9782898c0.png)

debuggerが変なswitchに巻き込まれずにちゃんと動いて最高。


Chromeだけじゃプロダクションで使えない？ これは僕が趣味で遊ぶための環境であって仕事で使うには環境変数で多段でビルドオプションを切り替えるとか、そういう話になるんで各自勝手に頑張ってくれ。
Watson Conversationを触ろうか迷っている人たちのための一歩を踏み出してみた。

## 概要
IBM Bluemixには様々なサービスが用意されていますが、話題のwatsonに触れてみたかったのでwatsonのサービスを触りました。
<img width="1280" alt="Screenshot 2016-12-22 15.31.34.png" src="https://qiita-image-store.s3.amazonaws.com/0/84126/c8ff0a1c-9df6-eb56-786f-409f52872c27.png">

上図のようにたくさん種類がありますが、今回はconversationに触れてみます。

<img width="1277" alt="Screenshot 2016-12-22 15.42.07.png" src="https://qiita-image-store.s3.amazonaws.com/0/84126/7584ffd0-f592-372c-4063-4f9fff71985c.png">

### はじめに
[IBM Bluemix X teratermアドベントカレンダー(https://teratail.com/Bluemix)](https://teratail.com/Bluemix)に投稿した記事です。年納めとして初めてIBM Bluemixに触ってみました。

## Watson conversationとは

IBM Watson Conversationを使用することで、自然言語処理・機械学習を介して、人間との会話を実現することができます。

![conversation_arch_overview.png](https://qiita-image-store.s3.amazonaws.com/0/84126/fce813d3-2304-4f49-d16d-3a4ff0b51675.png)
※参考：「[Overview of the IBM Watson Conversation service](http://www.ibm.com/watson/developercloud/doc/conversation/index.html)」

現在（2016年12月22日）段階では、下記の言語に対応しているようです。
Brazilian Portuguese, English, French, Italian, Spanish, German, Traditional Chinese, Simplified Chinese, and Dutch

日本語はまだ対応していないようなので今回はEnglishで触ります。

## Bluemixに登録する

IBM Bluemixへの登録方法はこちらを参考にしてください。
[IBM Bluemixフリートライアルアカウント作成手順(http://qiita.com/KenichiSekine/items/6ad49b25167b3f4cdb63)](http://qiita.com/KenichiSekine/items/6ad49b25167b3f4cdb63)

## サンプルアプリケーションを触ってみる

シンプルなサンプルアプリケーションがBluemixに用意されており、そこで入出力を見ることができます。  
[watson conversation sample(http://conversation-simple.mybluemix.net/)](http://conversation-simple.mybluemix.net/)

<img width="1278" alt="Screenshot 2016-12-22 15.24.15.png" src="https://qiita-image-store.s3.amazonaws.com/0/84126/5f59d37c-e9c2-7aaf-7550-a158d470c61c.png">

"Hello Bluemix world"と入力してみます。すると下図のようなinputが表示されます。
<img width="1276" alt="Screenshot 2016-12-22 15.38.17.png" src="https://qiita-image-store.s3.amazonaws.com/0/84126/d1b22f36-8381-5250-4102-c6a6c398b838.png">

返ってきたOUTPUTを見てみましょう。

```
{
  "intents": [
    {
      "intent": "greetings",
      "confidence": 0.9930016439498001
    }
  ],
  "entities": [
    {
      "entity": "genre_bad",
      "location": [
        13,
        18
      ],
      "value": "World"
    }
  ],
  "input": {
    "text": "Hello Blumix world"
  },
  "output": {
    "log_messages": [],
    "text": [
      "Hello! I'm doing good. I'm here to help you. Just say the word."
    ],
    "nodes_visited": [
      "node_7_1468608329601"
    ]
  },
  "context": {
    "conversation_id": "d7ae4cf6-4c1e-4e0b-bbfe-d054cdde0f16",
    "system": {
      "dialog_stack": [
        {
          "dialog_node": "root"
        }
      ],
      "dialog_turn_counter": 2,
      "dialog_request_counter": 2
    },
    "default_counter": 0
  }
}
```

## 参考URL
[Watson Conversation Tutorial(https://www.ibm.com/watson/developercloud/doc/conversation/tutorial.html?cm_mmc=Bluemix-...)](https://www.ibm.com/watson/developercloud/doc/conversation/tutorial.html?cm_mmc=Bluemix-_-Leadership+Agenda_IBM+Watson+Core-_-WW_WW-_-Intercom+Conversation+Nurture&cm_mmca1=000000OF&cm_mmca2=10000409&)
Android アプリのセキュア設計 WebViewの実装 の要約

[Android アプリのセキュア設計・セキュアコーディングガイド](https://www.jssec.org/dl/android_securecoding.pdf)に記載されている内容の要約です。

## JavaScriptを有効にするのは自社管理のコンテンツなど安全性を保証できるのみにする

* JavaScriptを有効にすることで、端末の情報を取得される、あるは端末を操作されるという被害が発生する可能性がある。
* 安全性を保証できないコンテンツを表示する場合はJavaScriptの実行を無効にすべきである。

## ローカルコンテンツをWebViewで表示する場合は、assets/resディレクトリの限定する

* SDカードのような端末の外部記憶装置に配置されたコンテンツは他のアプリによる書き換えが可能なため、assets/resディレクトリの限定する。

## 通信にはHTTPSを使い、適切にエラーをハンドリングする

* 第三者によるサービスのなりすましによる被害を防ぐ。
* SSL通信エラーの場合は通信を終了する。

## 他アプリからIntentを受信するActivityのWebViewではJavaScriptを無効にする

* 予期せぬJavaScriptが実行されることを防ぐ。
* どうしてもJavaScriptを有効にする必要がある場合はIntentで渡されたURLが安全性を保証できるなのか、ホワイトリストで管理する必要がある。

## Android4.2未満の端末における addJavascriptInterface() に起因する脆弱性

* Android4.2(API Level 17)未満ではJavaScriptからJavaのReflectionを行うことにより任意のJavaメソッドを実行できてしまう問題がある。
* Android4.2以降では@JavascriptInterfaceアノテーションが指定されたメソッドしか実行できないように仕様変更され、対策されている。

## fileスキームに起因する脆弱性

* fileスキームを利用すると該当アプリがアクセス可能なすべてのファイルにアクセスすることが可能になる。
* 例えば、JavaScriptからfileスキームを使ったリクエストをすることで、アプリの専用フォルダに保存したファイル等を取得されてしまう。
* 意図しないfileスキームによるリクエストは処理しないような対策が必要である。
* またAndroid4.1(API Level 16)以降の場合は以下のコードでfileスキームによるアクセスを禁止することが出来る。

```kotlin
        webView.settings.allowUniversalAccessFromFileURLs = false
        webView.settings.allowFileAccessFromFileURLs = false
```

## Web Messagingに起因する脆弱性

* WebViewを用いてWeb Messaging を行う際は postWebMessaging()メソッドに特定のオリジンを指定すべきである。
* postWebMessaging()メソッドでオリジンにワイルドカードを指定すると、WebViewに悪意のあるコンテンツが読み込まれている状況で、オリジンの制限なしに重要なメッセージを送信してしまう可能性がある。
コンソールで動くエディタを作る(19日目) コードを読みやすく、安定動作に！？

本稿は[自作エディタをつくる Advent Calendar 2016](http://qiita.com/advent-calendar/2016/make_editor)の19日目です、レポジトリは[こちら](https://github.com/tinyco/tiny_code_editor)


自分の中で読みづらいと思っているのは、主にstring_type.cです。
今日はそこを綺麗にしつつ、バグを取っていきます。

# コードを読みやすくする

いままで、

- utf8の1文字をmbchar型
- 行先頭から末尾までをline型
- ファイル先頭からファイル末尾までをtext型と名付けていましたが

それぞれutf8char型、mutable_string型、lines型と呼ぶことにします。

名付けたときの思いに反して、line型が示す内容が直感的ではない気がしました。
text型がlineっぽい名前であるべきかなと。

あとは、より説明的な名前にしました。

mbcharはmulti-byte charのつもりだったのですが、
現時点ではutf8しか対応できてないのでutf8charにしました。

あわせて、メソッド名もわかりにくいものは順次なおしています。

引数がわかりにくい似たメソッド(X座標とY座標)を、メソッド名に引数はX座標だよ、
みたいな命名したところだけがキャメルケースになっていました。(他はスネークケース)
書いたとき、Objective-Cを連想したんでしょうか。
・・・Cって普通スネークケースなのかな。cursesはスネークケースだったけど。

# nullチェックと静的解析

16日目を参考に、地道にnullチェックを追加していきます。
地道すぎる、静的解析ツールほしい！と思って`cppcheck`を試して見ます。

`$brew install cppcheck`
`$cppcheck --enable=all . 2>err.txt`

すると

```
[file/reader.c:17]: (style) The scope of the variable 'c' can be reduced.
[file/reader.c:20]: (style) The scope of the variable 'mbsize' can be reduced.
[type/lines_type.c:97]: (style) Variable 'prev_width' is assigned a value that is never used.
(information) Cppcheck cannot find all the include files (use --check-config for details)
```

3行しか怒られなかった。nullチェック漏れは見つからず。

4行目の --check-config をつけると
`[main.gen.h:7]: (information) Include file: <stdio.h> not found. Please note: Cppcheck does not need standard library headers to get proper results.`
見つからなくても大丈夫らしいので、気にしないことにしました。
いちおう指摘をなおします。

[facebook-infer](http://fbinfer.com/)は使い方がわからず。

```
$ infer -- clang -c main.c
Capturing in make/cc mode...
In file included from main.c:1:
./main.gen.h:7:10: fatal error: 'stdio.h' file not found
$infer -- gcc -c main.cもだめでした。
```

こちらはstdio.hがあるフォルダにシンボリックリンク貼ったりしたけど、結局諦めました。

そして地道にnullチェックを続けます。

mutable_string(ポインタ)を別のラインにつけかえて、
それを所持していたlineをfreeするときに、
間違えて再利用したはずのmutable_stringまでfreeしていた箇所を直すと、
だいぶ動作が安定してきました。

・・・静的解析は教えてくれなかったけど。

# 余談: 可変長配列の実装

**全体的に、合ってるかの自信は全くないです**


### swift

世の中の可変長文字列はどうなってるんだろう、可変長配列になってるのかな、と思ってswiftを調べてみました。


https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L670

bufferなるものを足していくらしい、たぶんmallocみたいなやつなのかな

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayBuffer.swift#L127

capacityを指定してmallocするらしい、たぶん

つまり、必要に迫られたときに必要に応じて確保して後ろにつなぐ。
サイズがマチマチなメモリ領域をリストでつなぐ構造・・・なのかな？

https://github.com/apple/swift/blob/b4d30b7c1a0189290410aa2df983d618abaca3db/stdlib/public/core/ArrayBuffer.swift#L269

ここがリスト構造っぽいけど、_SliceBuffer内のイテレータの動きがわからず確信が持てない。

swiftってswift自体(とgyp)で書いてるんですね。参照カウンタっぽいコードが多い。

### PHP

PHPを調べると

https://github.com/php/php-src/blob/master/Zend/zend_hash.c#L174

hashになってるのかな。プリミティブ型としてarrayっぽいものがない雰囲気。

いや、配列型がないわけないような・・・。見つけられず。

### Ruby

Rubyは

https://github.com/ruby/ruby/blob/trunk/array.c#L210

配列を伸ばすときに、おっきい領域を確保しなおして、そこにコピーかな？たぶん。

Rubyって標準ライブラリいっぱいあるなって思いました。


# 今日のまとめ

- 徐々に読みやすいコードを目指しています
  - メソッド名・型名を他の人が見やすくした、つもり
  - フォルダわけも少し手直し
  - 1ファイル100行以内を努力目標にして、だいたい130行以内くらいに収まりつつあります
- バグ修正して、だいぶ落ちなくなってきました(当社比)
- 静的解析ツールを試してみました、微妙かも

明日は、後回しにしていた自動テストとincludeの見直しをしたい！
Yesodの設定ファイルconfig/settings.ymlに設定を追加する

stackのテンプレートから生成したYesodアプリは、設定ファイル群が ``` config ``` ディレクトリに格納されています。

その中に ``` settings.yml ``` というファイルがあり、これは環境変数から値を取ったり、直接値を書いたりできる設定ファイルです。

今回はこのファイルに設定を追加する方法を紹介します。

# config/settings.ymlの内容

デフォルトではsettings.ymlの内容は次のようになっています（DBにSqliteを使う場合。コメントは省いてあります）。

```yaml
static-dir:     "_env:STATIC_DIR:static"
host:           "_env:HOST:*4" # any IPv4 host
port:           "_env:PORT:3000" # NB: The port `yesod devel` uses is distinct from this value. Set the `yesod devel` port from the command line.
ip-from-header: "_env:IP_FROM_HEADER:false"

#approot:        "_env:APPROOT:http://localhost:3000"

database:
  database: "_env:SQLITE_DATABASE:model-example.sqlite3"
  poolsize: "_env:SQLITE_POOLSIZE:10"

copyright: Insert copyright statement here
#analytics: UA-YOURCODE
```

値の書き方に注目すると

```
"_env:SQLITE_POOLSIZE:10"
```
という書き方は、「まず環境変数 SQLITE_POOLSIZE から値を取得し、失敗した場合は 10 を採用」という意味です。

# AppSettings型で設定内容を受ける

settings.ymlの内容は、Settings.hsの中で定義されているAppSettings型で受け取ることができます。デフォルトでは次のような定義になっています（DBにSqliteを使う場合。コメントと空白行は省いてあります）。

```hs
data AppSettings = AppSettings
    { appStaticDir              :: String
    , appDatabaseConf           :: SqliteConf
    , appRoot                   :: Maybe Text
    , appHost                   :: HostPreference
    , appPort                   :: Int
    , appIpFromHeader           :: Bool
    , appDetailedRequestLogging :: Bool
    , appShouldLogAll           :: Bool
    , appReloadTemplates        :: Bool
    , appMutableStatic          :: Bool
    , appSkipCombining          :: Bool
    , appCopyright              :: Text
    , appAnalytics              :: Maybe Text
    , appAuthDummyLogin         :: Bool
    }
```

settings.ymlと同じ内容になっていることが分かると思います。
また、settigs.ymlに無いかもしれない設定は、型がMaybeになっています（``` appAnalytics ``` が該当）。
また、入れ子になった設定も可能です（``` appDatabaseConf ``` が該当）。

# 設定を追加する

設定を追加するには、ここまでで紹介した２つのファイルに追記すればOKです。
ここでは ``` apiKey ``` という設定を追加してみます。

## settings.ymlに追記

```yaml
apiKey: "_env:API_KEY:xxx-xxx-xxx-xxx"

```
## Setting.hsのAppSettings型に追記

```hs
    , appApiKey                 :: String
```

# AppSettingsを使う

AppSettingsは、Handler関数の中で簡単に使えます。

```hs
apiKey <- getYesod >>= return . appStaticDir . appApiKey
```
技術英語 > one of your routines will [be penalized] for the time spent executing another program.

@ Code Complete (No. 19602 / 36077)
> one of your routines will **<font color=red>be penalized</font>** for the time spent executing another program.

https://www.merriam-webster.com/dictionary/penalize
> :  to put at a serious disadvantage

上記の文章の前に、以下のような文章がある (意訳)。

> 時間計測するときに「経過時間」よりも「CPU clock ticks」を使いましょう。さもないと、システムはあなたのプログラムから他のプログラムにスイッチし、

続いて上記の文章 (意訳)

> あなたが書いたルーチンの１つ(の処理)には「他のプログラムを実行する時間」という余分な経過時間が加えられます。
PowerShellメモ　2つのファイルの差分を見る(diff)

# <i class="fa fa-cubes" style="font-size:1em;"></i> 概要
2つのオブジェクトを比較する`Compare-Object`コマンドレット(エイリアス:diff)の結果を少しだけ見やすくする関数。

# <i class="fa fa-cubes" style="font-size:1em;"></i> 使用例
例1）`a.txt`と`b.txt`を比較。変更のない行も出力。
![ps20.png](https://qiita-image-store.s3.amazonaws.com/0/142879/2a7e6751-a879-02d7-043c-faef71e2be89.png)


例2）`before.csv`と`after.csv`を比較。変更のない行は出力しない。

```PowerShell
diffc D:\Work\before.csv Z:\Tmp\after.csv
```

# <i class="fa fa-file-text-o" style="font-size:1em;"></i> コード

```PowerShell
<#
.SYNOPSIS
    2つのファイルを比較

.DESCRIPTION
    修正前と修正後のファイルを比較し、差分をコンソールに表示する。
    [+]が修正後に存在する行(追加/変更)、[-]が修正後に存在しない行(削除/変更)。

.PARAMETER FromFile
    修正前ファイル

.PARAMETER ToFile
    修正後ファイル

.PARAMETER Full
    変更なしの行も表示する場合に指定。
    変更なしの行は[=]で表示。

.NOTES
    行番号は出ません

.EXAMPLE
    diffc .\File_ver1.txt .\File_ver2.txt
    File_ver1.txt と File_ver2.txt の差分を表示

.EXAMPLE
    diffc C:\Work\before.csv D:\Tmp\after.csv -Full
    before.csv と after.csv の差分を変更がない行も含めて表示
#>
function diffc([Parameter(Mandatory)][string]$FromFile, [Parameter(Mandatory)][string]$ToFile, [switch]$Full)
{
    Compare-Object (Get-Content $FromFile) (Get-Content $ToFile) -IncludeEqual:$Full | 
        ForEach-Object {
            [string]$line = ""
            [string]$foreColor = ""
            if ($_.SideIndicator -eq "=>")
            {
                # 修正後に存在する行（追加または変更された行）
                $line = "[+] " + $_.InputObject
                $foreColor = "Green"
            }
            elseif ($_.SideIndicator -eq "<=")
            {
                # 修正後に存在しない行（削除または変更された行）
                $line = "[-] " + $_.InputObject
                $foreColor = "Magenta"
            }
            elseif ($Full)
            {
                # 変更がない行
                $line = "[=] " + $_.InputObject
                $foreColor = "Gray"
            }
            
            Write-Host $line -ForegroundColor $foreColor
        }
}
```

# <i class="fa fa-cubes" style="font-size:1em;"></i> 動作確認した環境
* PowerShell V4 (Windows 8.1)
* PowerShell V5 (Windows 10)

# <i class="fa fa-book" style="font-size:1em;"></i> 参考サイト
[Compare-Object - MSDN](https://msdn.microsoft.com/ja-jp/powershell/reference/5.1/microsoft.powershell.utility/compare-object)

# <i class="fa fa-cloud-download" style="font-size:1em;"></i> もっといいもの
* [DF.exe - Vector](http://www.vector.co.jp/soft/win95/util/se113286.html)
* [WinMerge 日本語版](https://winmergejp.bitbucket.io/)
SQLアンチパターン：マルチカラムアトリビュート

[SQLアンチパターン](https://www.amazon.co.jp/dp/4873115892/)を読み始めたので、1つ１つ書いてのメモです

# 目的

- 目的:複数の値を持つ属性を格納する
- ジェイウォーク（信号無視）と同じ。ジェイウォークでは、カンマ区切りで1つのカラムにデータを入れていた

# アンチパターン

## 複数の列を定義する

- tag1、tag2とか、image1、image2とか
 - やったことある

### 課題

- 値の検索が複雑になる
 - tag1、tag2 を検索しなくてはいけない
- 値の追加と削除が複雑になる
 - null のカラムを探してから update をすることになる
- 一意性の保証ができない
 - tag1、tag2 に同じ値を入れちゃう
- 増加する値に対応が大変
 - tag3 を増やすときには大きなテーブルになってて、ロックが必要になったり、取得用のSQLを書き換えたりする必要がある

## 用いてもいいパターン

- 属性の選択肢を限定できる場合
 - tag1 には、報告者、tag2には、担当者、tag3 には、品質管理者
 - 論理的に異なる場合

# 解決策

- 属性を格納する列を 1 つ持つ従属 テーブルを作成
- ジェイウォークのときと発想は同じ

# まとめ

同じ意味を持つ値は、1 つの列に格納するようにしましょう。

# 感想

- やってた！
- きちんとテーブルを分けます。

[![](https://images-na.ssl-images-amazon.com/images/I/41qHKrFZi0L._SX389_BO1,204,203,200_.jpg)](https://www.amazon.co.jp/dp/4873115892/)
ElectronからローカルファイルをSFTPでサーバーにアップロードする方法

ElectronでSFTPを通じてファイルをアップロードしたい場合の方法です。

npmモジュールを追加します。

<code>spawn</code>とかつかってShellコマンドを操作するでもいいですが、簡単な方法としては<code>ssh2</code>モジュールがおすすめです。ただし、素の<code>ssh2</code>だとリモート側でのmkdirが用意されていないようでしたので、今回は<code>ssh2</code>のラッパーである<code>ssh2-sftp-client</code>を使って、ディレクトリ作成を含んだSFTPアップロードの方法をご紹介します。

## インストール

```
npm i ssh2-sftp-client --save
```

## 使い方
```
function upload () {
    let Client = require('ssh2-sftp-client');
    let sftp = new Client();

    var localPath = home + '/Gene/gene/themes/index.html';
    var remotePath = 'Your remote dir // e.g./home/user/www/dir/sample/';
    var remoteFilePath = remotePath + 'File name // e.g. index.html';

    sftp.connect({
        host: 'Your ftp host',
        port: 22, // Port
        username: 'Your user name',
        password: 'Your password'
    }).then(() => {
        return sftp.mkdir(remotePath, false);
    }).then(() => {
        return sftp.put(localPath,remoteFilePath, true);
    }).then((data) => {
        console.log("Success!!");
    }).catch((err) => {
        console.log(err, 'Error!!');
    });
}
```
以上です。

## 参考
[npm - ssh2-sftp-client](https://www.npmjs.com/package/ssh2-sftp-client)
コミュニケーションコストを減らしてチーム活性化

[コミュニケーション Advent Calendar 2016](http://qiita.com/advent-calendar/2016/communication)の19日目です。

# コミュニケーションコストってなんだ？
この言葉に行き当たったのは[サイボウズの記事](https://cybozushiki.cybozu.co.jp/articles/m000334.html)で、ちょうどそのときに考えていたことが書かれていたので、もう参照してよ。以上！　とはいかないので、自分なりの何かを見いだしていこうと思います。

## 2つの側面
コミュニケーションコストには、大きく分けて2種類あります。
### タイムコスト
> コミュニケーションには時間がかかる＝人件費がかかる　⇒　短いほどいい！

という発想のビジネス**スキル**として言及されることが多いでしょう。

関係者のコンテキストが異なると、問題のピントを合わせるのにも一苦労します。
お互いに必要な情報を交換し、ゴールに向かっていくためにどういうことが必要なのかということは、ファシリテーションやホウレンソウと呼んだりしてビジネス**スキル**として多くの組織から求められているのが現状です。

[去年のpenginさんの記事](http://qiita.com/pengin/items/11689c521a179070651c)や[今回のrhoboroさんの記事](http://qiita.com/rhoboro/items/27fe3484f83a0f20e13c)はこちらに重点を置いたものだといえます。

### 心理的コスト
> 風通しの良い職場環境

その言葉を面接官に言われ、本当にその職場がそうであったかどうか、~~私~~あなたが実態に悩まされたかどうかは別の問題として、企業から求職者に対するアピールポイントとなる程度には求められている要素です。

相手に話しかけたり相談をするために決断や思い切りが必要な場合は、`コストが高い`状態にあります。

多くの場合、相手との**関係性**や彼・彼女・私の**人間性**として言及されることになります。

## この記事では心理的コストにフォーカスします
**関係性**とか**人間性**に帰結してしまうと逃げ道がなくなってしまうので、何とか体系化できないものかと悩んでいて、そのとっかかりとしてこの記事を書いています。

# 心理的コストの差で何が変わるのか
サイボウズの記事で言う「絡みやすい」人だと何がメリットなのか。まずはそこから確認しましょう。

- 信頼関係を作ることで、お願いを聞いてもらえる土壌ができる
- 情報が集まる

ビジネスマンとしては前者、技術者としては後者が重要かもしれません。
一般的な組織のマネージャにとっても、情報が集まることは重要ですので見逃せない要素だと思います。

# 「絡みやすい」人とは

## 人と事を分離する 
> 今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない
（ノームカースの最優先事項）

私がどこから拾ってきたのか忘れてしまいましたが、私のEvernoteに残っている言葉です。ググっても出典が見つかりませんでしたｗ
問題が発生したとしても、原因を人に求めるのではなく事に求めるようにすると、メンバーは所属するチームに安心感を覚えます。

## 説明を遮らない
本来、一人で考えているだけの方が楽なのに、人に説明することは、それだけで気合いが必要です。
勇気を出して説明していることを遮り、お前の話はよくわからないなどと突っ返されたら、次から説明するときのハードルが上がります。
一方で、説明の途中で「ああ、わかった」というのも実はあまりよくありません。
わかってくれたんだと思っても、後から話をすりあわせると、やっぱり話がすれ違っていたりする。ひどい場合には、自分が言ったことにされて、その人の意見を通しただけ、という事態にもなります。
そうなると、説明者はやはり曲解を生む相手と話すことに抵抗を覚えるようになります。

## 自分を飾らない
人は弱さを見せる人に対して親近感を覚えます。
何でもできると吹聴する人と対面するのはしんどいことが多いです。
得てして、承認欲求の現れであったり、自らの意見が絶対であると考えているケースが多数のため、相手の意図に沿わない応対をすると関係がこじれるためです。

# まとめ
コミュニケーションコストとして人との垣根をなくすためにできることを書き殴ってみました。
総じて言えば[Googleのプロジェクトアリストテレス](http://gigazine.net/news/20151126-five-keys-to-successful-team/)で言及されているように、心理的安全性や信頼感が人とのつながりの間の障壁を減らすことになるのでしょう。

# 不完全燃焼
最初の段階ではもうすこし掘り下げて書こうと考えていたのですが、なかなかうまくまとまらないままアドベントカレンダーの予定日を過ぎてしまったため、このまま投稿します。
具体的には、心構えに近くなっているこの内容から、実際の行動へとつなげるためのスキルとして敷衍できたらと考えていました。
なので、一旦ここで投稿し、追記を後日投稿しようと思います。

　→　やっと[追記を投稿できました](http://qiita.com/sho0211/items/5dce3599b4007c2b4db9)。 (2017/01/19)

# 転職します
個人的なことですが、2017年1月から別の会社で働きます。
新しい職場での自戒と抱負を込めて、この記事を書きました。
また、Qiita初投稿になる訳ですが、殻に閉じこもりがちな自分を鼓舞し、コミュニケーションの基本と言われる自己開示から始めようと思ってます。
時間がない時のテスト項目書の作り方

## 開発期間が短いプロジェクトでも、しっかり試験を行うには
プログラムの品質を高めるには、試験工程でどれだけ良いテストを行ったかも鍵になります。
試験工程で良いテストを行うには、良いテスト項目書が必要です。
開発期間の短いプロジェクトでは、試験工程になかなか時間を割けないものですが
それでも、短い時間で良いテスト項目書を作成する方法を……まずは自分のやってきたことを以下に纏めてみます。

## 時間がない時にまずやること
以下の作業を通し、テスト対象となるシステムを理解します。

1. 要件定義を機能ごとに理解する
2. 業務フローを、要件定義を意識しながら理解する
3. 設計書を、要件定義・業務フローを意識しながら理解する
4. 画面項目を、要件定義・業務フロー・設計書を意識しながら理解する
5. DB項目を、要件定義・業務フロー・設計書・画面定義を意識しながら理解する

2.の業務フローの理解の時点で要件定義と合わない箇所を見つけたとすると、
プログラムにはほぼおちていないこととなり、大変大きな問題となるのでここでは割愛します。

3.～5. の段階で、まず設計書や画面項目、DB項目記載事項に要件定義や業務フローと合わない矛盾を見つけることができます。
ここで想定しているプロジェクトの開発期間では、大抵これらはプログラムを作りながら変更されていくものなので、
この時点ではプログラムまたは設計書および画面やDB項目のどちらに不具合があるのか、テスターにはわからないことが多いのですが
仕様管理者や該当箇所の開発担当に状況を伝え、次に進みます。
 - Redmine等不具合を手軽に管理できるツールでチケット起票だけはしておくと便利です。
 - 指摘誤りは担当者がバサバサ切ってくれるので、気になることはすべて起票しておきます。

## テスト項目書の作り方
システムを理解したら、早速テスト項目書を作成します。
テスト項目書は、件数の増減に耐えられるよう「シナリオ」「データ」「試験項目書」の３つのシートに分けておきます。
「シナリオ」「データ」を作成したら、「試験項目書」からそれぞれを参照していく形式です。

- シナリオをつくる

業務フローを書き出し、まずは要件定義や設計書で定義されている仕様と画面の動きが合っているかどうかを確認するシートです。
仕様的な不具合を、これを作成している間に洗い出すことが目的です。

    1. テストの対象となる業務フローを、機能ごとにすべて書き出す
    2. 業務フローに対し、該当する要件定義・設計書の項目番号を記載する
    3. 要件定義または設計書側に、業務フローに対応していない箇所があるかどうかを確認する
    4. 業務フロー側に、要件定義または設計書側に対応していない箇所があるかどうかを確認する
    5. 3.または4.にて対応していない箇所を見つけた場合は、シナリオに適宜追加しどちらが対応していないかをメモしておく

試験対象となる業務フローが、要件定義や設計書に紐付きすべてが記載されたはずです。
5.で追加されたシナリオについては、場合によっては仕様管理者や開発担当に報告しRedmine等の管理ツールがある場合は、まずは不具合として起票しておきます。

- データをつくる

シナリオに記載された業務フローに対し、考えられるすべてのデータの入力パターンを別表として作成、各パターンにデータパターン番号を振っておきます。
データの作成は、以下の基本パターン別から作り出すとスムーズですが、まずはシナリオ作成時に一通りチェックしている要件定義・設計書側からみたデータを作成します。
シナリオでは、各ケースで必要なデータ番号を紐付けておきます。

    1. 初期表示・再表示
    2. 必須項目
    3. 条件付き必須
    4. 境界値
    5. データ数
    6. その他（テスト対象となる要件定義・仕様から適宜追加）

また、これらは画面側からみたデータパターンですが、次にDB項目定義側からみたデータパターンも作成しておきます。
DB定義側との齟齬を洗い出すことが目的です。

- 試験項目書をつくる

作成した「シナリオ」や「データパターン」を参照先として、以下の観点ごとに試験項目書のケースを作成していきます

    1. ログインユーザの権限別
    2. 機能別
    3. 正常系・異常系
    4. 起動時引数別
    5. その他（テスト対象となる要件定義・仕様から適宜追加）

期待結果や操作手順・テストデータ等、試験項目書には幾つか項目がありますが、基本的にはそこには「シナリオ」や「データ」の該当する項目番号を参照するよう記載するイメージです。

試験を進めながら、試験項目書不備（期待結果誤りや考慮漏れ）が発生した場合は、参照先である「シナリオ」や「データ」を修正します。

試験を行うために必要な仕様やデータに関する知識はそれらのシートに纏められているので、あとから再確認する際や他のテスターに引き継ぐ場合に便利です。

また「試験項目書」シートでは、試験件数（総件数・ステータス別件数・合格件数・不具合件数）や試験結果および試験日を、品質管理として集計しやすいよう配置する工夫が必要です。
このシートを、試験結果報告用に流用できるよう作成しておくのです。


以上が、時間がないときによく作っていたテスト項目書作成の流れですが、「シナリオ」さえできてしまえば、あとはExcelを駆使すればすぐ出来ます。
もっと時間があれば、あれもこれも……と悔しい思いをしたことは何度もありますが、
まずはざっと、試験対象の要件や仕様をおとすことなく試験するには上記の方法がとてもやりやすいものでした。

また機会があれば作ってみたいです。
素人プログラマ(私)からみたQiitaへの願望

#はじめに
私はまだまだ素人のプログラマです.
まだQiitaに投稿しはじめて20日位しかたっていませんが
素人だからこその意見も需要があるのではないかと思って書いてます
そんな本気で思っていることではないので,ただの独り言だと思って適当に読んでみてください

#こうなって欲しいと思った点など

##タグ付けのガイドライン
初めてこのサイトを訪れたときはマークダウンの書き方が
「長いチュートリアルなし」かつ「懇切丁寧でわかりやすい説明」で感動したのですが,
タグは何を付ければいいのかいつも悩みます(というよりいつも使用した言語くらいしか付けません)

おそらくQiitaを長らく使用している方にとっては,タグをどのようにつければいいかわかっていると思うので
**読者が自由にタグを付け消しできたり必要なタグは変えられないように設定できればいいかな**と思いました
あと,素人的には「環境構築」がわからずに詰んだりすることがよくあります.

私としては「やりたいこと」からではなく「環境構築」の記事からスタートしていくという方針もありだと思っています

そこで「環境構築」「アルゴリズム」など**重要なタグはタグ付けを義務化されるといいな**と思いました

あと言い回しの違う同じ意味のタグがいっぱい湧いているので**関連ワードの投稿数の大きなタグ**が調べられるといいなと思いました

##記事のレベル分け
素人プログラマの代表として代弁すると私たちは同じか少し上のレベルの記事が読みたいと思っています.
というのも,レベルの高すぎる記事は読むにはまだ早いといったこと頻繁にあります.

このような成長日記や入門記事は重要だと感じています(見たりアドバイスをもらったり)
(例えば,私としては[こんな記事](http://qiita.com/uporeke/items/8f0628209463549a85f2)なんかは楽しく見れます)

一方で,[こんな意見](http://qiita.com/tottokotkd/items/58d98e38c7b078dbe143#qiita)もあります
>最近は日記みたいな記事と金太郎飴みたいな入門記事が増えすぎだし、

人により好みが割れるので,こういったものは個人にあったフィルタにかけられるだと思います
つまり,**記事のレベルを設定して読者が読みたい対象を読めるようになるといいな**と思いました

それとも,Qiitaの「プログラムの情報共有」に,こういった玄人から見たら当たり前すぎる素人同士の共有情報は含まれないのでしょうか

##注目の当たらない記事
レベルの高い人は当然役に立つ記事をどんどん書いていき,みんなが注目ますが,
私みたいな素人はただの二番煎じに毛が生えた程度の自己満足記事しか書けず
誰も読んでくれません

また,有名な言語の記事だと通りすがりの上級者(通称:神様)からアドバイスを頂けますが
需要のないマイナーものは全然反応がありませんね

せめて「いいね」ボタンならぬ**「読んだよ」ボタンがあると,
投稿者も自信がでるし,読者も既読かわかるし**一石二鳥じゃないかと思いました

##装飾など
文字サイズや色(例えばテーブルのセルの背景色を淡い赤にして強調したり)が変更できるといいなと思いました

##お知らせ欄
通知から,いいねしてくださった方などのユーザのページに飛べないのは少し不便に思いました

#おわりに
いろいろ書きましたが,私がメインにイメージしたことは「同じレベルの人と情報共有してお互い切磋琢磨したい」ってことです
これは**個人の願望(「こうだったらいいのにな」という妄想)であり希望や依頼ではありません**
このように思っている人もいるんだなという感じで,参考にしてもらえると幸いです
見易い定数同値テストのためのRSpec matcher

## 概要
RSpecでモジュールで定義した定数との同値テストの結果を見易くする。
(これ、需要は少なくないと思うので、標準の方法でもあるのではないかと疑っています。知ってる方いたら教えて頂けると幸いです)

## 前振り
RSpecのテストを書いていて、ある対象がモジュールで定義した定数と一致すること、というテストケースを書くことがある。
例えば、こんなテストケース。

```ruby
# プロダクトコード抜粋
module Status
  SUCCESS = 0
  ERROR = -1
end

# テストコード抜粋
status = Status::SUCCESS
expect(status).to eq Status::Error
# => expected: -1
# =>      got: 0
```

この失敗するテストの結果は、人間にとって見易いものではない。
我々が知りたいのは0とか-1とかいう数値ではなく、SUCCESSとかERRORとかいう意味のある名前である。



## 解決方法
以下のようなmatcherを実装する。

```ruby
RSpec::Matchers.define :const_eq do |mozule, exp_symbol|
  match do |act_val|
    mozule.const_get(exp_symbol) == act_val
  end
  failure_message do |act_val|
    act_symbol = mozule.constants(true).find { |c| mozule.const_get(c) == act_val }
    act_msg = if act_symbol.nil? then "ACTUAL: unknown value(#{act_val})"
              else "ACTUAL: #{mozule.name}::#{act_symbol}(#{act_val})"
              end
    exp_val = mozule.const_get(exp_symbol)
    "EXPECT: #{mozule.name}::#{exp_symbol}(#{exp_val})\n" << act_msg
  end
end
```


## 使用例

```ruby
# プロダクトコード抜粋
module Status
  SUCCESS = 0
  ERROR = -1
end

# テストコード抜粋
status = Status::ERROR
expect(status).to const_eq Status, :SUCCESS
# => EXPECT: Status::SUCCESS
# => ACTUAL: Status::ERROR
expect(999).to const_eq Status, :SUCCESS
# => EXPECT: Status::ERROR
# => ACTUAL: unknown value(999)
```

## 改善予定
- `--format documentation`したときにも見易くするためにdescriptionを定義する。
- より細かな制御ができるmatcherを生成する方法は[その2](http://qiita.com/gimKondo/items/ebf6b38382f50a7fb1cf)で紹介する。
Python3で一定間隔で処理を行う


「一定間隔で」処理をしたいときにどうしたらいいのかちょっと迷ったのでメモ。

センサの読み出しとか、だいたい1秒間隔で呼び出せてればいい場合は、以下のような感じで書かれてることが多い気がする。

```python
import time

def task():
    print(time.time())

while True:
    task()
    time.sleep(1)
```

ただこれだと、

実行間隔 = `task()`の実行時間 + `time.sleep()`の呼び出しにかかる時間 + 1秒

になってしまう。
これだと精度云々の前に「一定間隔」ではない。

ロボットの制御とか音ゲー的なもので、正確に（と言ってもtimer.sleep()の精度と同じくOSのスケジューラの精度以上にはならないのだが）に100msec間隔で関数を呼び出したい。どうしたらいいのか。

システムコールとシグナルを使って、OSに一定間隔で呼び出してもらうことにした。

```python
import signal
import time

def task(arg1, arg2):
    print(time.time())

signal.signal(signal.SIGALRM, task)
signal.setitimer(signal.ITIMER_REAL, 0.1, 0.1)

while True:
    time.sleep(1)
```

引数の説明は以下のような感じ。
実行間隔にはfloatも設定できる。

```python
signal.signal(signal.SIGALRM, 呼び出したい関数)
signal.setitimer(signal.ITIMER_REAL, 1回目の実行までの時間, 2回目以降の実行間隔)
```

実行結果。

```bash
$ python3 signal_timer.py 
1482167643.537612
1482167643.633588
1482167643.733585
1482167643.833546
1482167643.933578
1482167644.033563
1482167644.133434
1482167644.233593
1482167644.333625
1482167644.433611
1482167644.532706
1482167644.633626
1482167644.732813
1482167644.833607
1482167644.933651
1482167645.033594
1482167645.133631
1482167645.233608
1482167645.333617
1482167645.43365
1482167645.533664
1482167645.633506
1482167645.733653
1482167645.83349
1482167645.933611
1482167646.033654
1482167646.133675
1482167646.233464
1482167646.333358
1482167646.433514
1482167646.533638
1482167646.63348
1482167646.733628
1482167646.833232
1482167646.933508
1482167647.033419
1482167647.133616
1482167647.233618
1482167647.333291
1482167647.433455
1482167647.533664
1482167647.633571
1482167647.733662
1482167647.833642
1482167647.93337
```
HoloLensアプリを実機にデプロイできないときの救世主 Maintainer #アセットアドカレ

この記事は Unity Assets Advent Calendar 2016 14日目の記事になります。

慣れないうちのHoloLensアプリ開発がツラいところとして、Visual StudioからDeployしたら追いようもない意味のないエラーメッセージが出るだけでデプロイできない状況に遭遇する。

そんな原因の8割がシーンのオブジェクトやコンポーネント、コンポーネント内のフィールドの参照切れ、missing。

で、厄介なmissingをバシッと一発で探し当ててくれるアセットがこちら。

## Maintainer
![image](https://qiita-image-store.s3.amazonaws.com/0/32347/fb63df7d-3241-18ce-d624-bd5ca7550cc7.png)

### 使い方

Tools > Code Stage > Maintainer > Find Issuesを選択するか、ショートカットキー(Ctrl+Shift+Alt+F)で実行。

[![image](https://qiita-image-store.s3.amazonaws.com/0/32347/971670c7-4710-346a-4fc1-427927de22ed.png)](https://www.assetstore.unity3d.com/jp/#!/content/32199)

プロジェクトに含まれるすべてのシーンから問題点を検索。結果を表示してくれる。

![image](https://qiita-image-store.s3.amazonaws.com/0/32347/91db02e0-9b7f-249b-0630-12b77e15cc86.png)

HoloLens実機でmissingがあるとDeployに失敗する件については、ほかのプラットフォームではそんなこともなく、意味のないエラーメッセージであることもあり、この挙動自体はまだ未成熟ゆえのバグっぽい。
そのうち解消されることで、近い将来記事の内容が役に立たなくなることを期待したい。

ただ、この話やHoloLensのプロジェクトに限らず、落としてきたプロジェクトとかでプレハブのパラメータ剥がれや、寝ぼけてぶっ壊すとかはよくある話なので、Maintainerで一発でUnityプロジェクトが健全であるかどうかを調査できるってことを知っておくともしもの時に助かる。お手元に置いておきたいアセットの一つ。
【非エンジニア・QA向け】なんちゃってQAのススメ

本記事は[Goodpatch Advent Calendar 2016](http://qiita.com/advent-calendar/2016/goodpatch) の20日目の記事です！


Goodpatchで唯一QAの肩書をいただいているenpipiと申します。
普段は社内SEとして活動しておりますが、Prottの大幅な改修時などスポットでQAとして参加しています。


専任のQAがいれば良いのですが、ディレクターや手が空いている人がQA的なことをしているチームも多いのではないでしょうか。

本記事では、非エンジニア・QAに向けた簡単なQAのコツについて紹介します。


# スタンスの話

QAは、平たく言えばサービスの品質に責任をもつ仕事です。
しかし、片手間でQAをやる場合や専任じゃない人に同じ責任を求めるのは酷です。
バグを絶対に出さないと意気込むよりも、**エンジニアがやらなくても良い仕事を引き受けて、開発に集中してもらう環境を作る**くらいで考えている方がモチベーションを保てると思います。



# テストケースを作る時の話
テスケースは簡単でも作ったほうが良いです。
記憶は全然頼りになりません。ログを残しておいたほうが後々同じテストを無駄に繰り返すことがなくなります。

以下のように、誰が実施しても同じ手順を踏めれるようになるべく丁寧に書けると使いまわすことができます。
もちろん、自分が理解できるだけで良ければ丁寧にやらなくても大丈夫です。
![image](https://qiita-image-store.s3.amazonaws.com/0/66020/20011266-08e2-f525-f4f3-9db199d33218.png)

重要なのはテストを実施した結果、問題ないと判断するのはどこが最適かを意識することです。
例えば、お問い合わせ画面から問い合わせができることを確認するなら、「送信完了画面が表示される」ではダメで、「問い合わせ内容がメールで届いているか」を確認する必要があります。


# バグを見つけた時の話

1. バグの再現ができないと、どこを修正して良いかわからない
2. バグが出た時のメンタルダメージでかい。不安。
3. 何から修正するか迷う


と言ったようにバグがエンジニアに与える負担は大きいです。


バグを報告してもらえるのは嬉しいのですが、情報が少ないと相手にヒアリングしなければならず開発に集中できません。

非QAの人は以下のような工夫をしてなるべくエンジニアにかかるコストを下げてあげましょう。

![image](https://qiita-image-store.s3.amazonaws.com/0/66020/3fc0fe61-9035-dee8-cc27-a01799bf64f6.png)


## 1. バグを再現させて共有する
再現手順がわからないと、手がかりほぼ無しでソースとにらめっこすることになります。
逆に再現方法がわかれば容易に原因を突き止めることができます。

偶然発生したものは普通にやっても再現しないことが多く、その前の手順やアカウントの状態が関連していることが殆どです。少しでも手がかりになりそうな情報を記憶があるうちに残しましょう。


### 画面キャプチャを必ず撮る

![image](https://qiita-image-store.s3.amazonaws.com/0/66020/918b18f9-bd13-e307-3037-3e0db19257c0.png)

---

どの画面で何が起きてるか、瞬時に把握できるように画面キャプチャを必ず用意しましょう。


### 再現手順を書く
```
**問題の詳細**
招待を連続で承認すると、2番目のプロジェクトを承認できずに落ちる

**再現手順**
1. ユーザーAをプロジェクトに3件招待する
2. ユーザーAでiOSアプリにログインする
3. 1件目を承認する
4. 2件目を承認する(なぜか3件目が一覧から消える)
5. 2件目を承認する
6. 落ちる

**備考**
リストの下からやると再現しない
```
---

再現方法を突き止めたら文章にして残しましょう。都度、エンジニアに報告すると集中力が切れてしまうので、スプレッドシートなどにまとめて好きなタイミングで確認できるようにしています。




## 2. 部分的にでも網羅的なテストを実施する

```
トレーニングジムのレジに下記のような自動割引機能をつける
* クーポン持参：10%OFF
* ジュニア割引（15歳以下）：20%OFF
* 平日割引：30%OFF
* シニア割引（65歳以上）：50%OFF
* 割引サービスが重なった場合は、割引率が高い方が優先される
```

以上のようなシステムがあった場合何パターン確認しなければいけないでしょうか。
こういった様々な条件が重なる場合はデシジョンテーブルを作りましょう。

![QA_WorkFlow.001.jpeg](https://qiita-image-store.s3.amazonaws.com/0/66020/244644b5-9348-8534-5df5-51a5a56cd5f5.jpeg)
![QA_WorkFlow.002.jpeg](https://qiita-image-store.s3.amazonaws.com/0/66020/3a38fedb-e5de-7c43-e6bf-727a2633dc07.jpeg)





## 3. バグに優先順位を付けて管理する
Githubでバグをissue化してProjectでカンバン管理するなど、優先順位付けと修正確認をしてあげるとかなりエンジニアが楽になります。


例えば、私の場合以下のような優先順位をラベルで作成しています。
どのバグから修正したら良いか、基準ができるので効率的にバグを潰せるようになります。

* A : 絶対リリースまでに修正する
* B : できればリリースまでに修正する
* C : 次回リリース以降に修正する

また、修正確認時では「他の場所でも発生しないか」を念頭に置くと修正漏れを防ぐことができます。

![Screen_Shot_2016-12-20_at_1_49_43.png](https://qiita-image-store.s3.amazonaws.com/0/66020/4cd3be67-d9ba-65ee-b4ce-8efce76991cc.png)



# むすび
QA作業は本当に地道な作業です。過去に[バグをドラゴンと呼ぶ運用](http://konifar.hatenablog.com/entry/2015/05/02/003449)が話題にあがったように、楽しくやったほうがお互いモチベーションを保てます。ちなみに私はドラゴンを見つけても退治できる術がないので、バグを財宝と呼んでテンションを高めています。

ぜひ、楽しくQA業務をやっていただき、エンジニアの力を最大限プロダクトを良くすることに使えるようにしましょう！
レイマーチングで潜れる雲を作る

この記事は，[WebGL Advent Calendar 2016 20日目](http://qiita.com/advent-calendar/2016/webgl)の記事です。

doxasさんやgam0022さんのレイマーチングの作品を見て面白そうだったので挑戦してみようと思います。

#目的
ところでこの記事を見ている方はエースコンバットというゲームをご存知でしょうか。
超遠距離のオブジェクトや、雲や煙のような形が定まっていない物ばかりが描画されるゲームです。
[![Youtubeリンク](http://img.youtube.com/vi/gS5FiOEeE3w/0.jpg)](http://www.youtube.com/watch?v=gS5FiOEeE3w)

プログラミングを学び始めた頃は、こういったものがどうやったら表示出来るのか全くわかりませんでしたが、今なら少し再現できそうです。
そこで、今回はその第一歩としてレイマーチングの力を借りて、リアルな雲を描画してみたいと思います。

#方法
「よし、レイマーチングでボリュームレンダリングをしよう！」と思っても、よく考えたらなにをしたら良いのかわかりません。
というかボリュームレンダリングって何？

[https://ja.wikipedia.org/wiki/ボリュームレンダリング](https://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%AA%E3%83%A5%E3%83%BC%E3%83%A0%E3%83%AC%E3%83%B3%E3%83%80%E3%83%AA%E3%83%B3%E3%82%B0)
>コンピュータグラフィックスにおいて、ボリュームレンダリングとは、3次元的な広がりのあるデータを直接2次元画面に表示することである。半透明な物体や発光体などを光学的に正しくレンダリングしたり（レイキャスティング）、CTなどで3次元的に撮影された画像を目的に沿って見やすく提示したりする（最大値投影処理など。)

説明が全然わからない。

![Wikipediaについてた画像](https://upload.wikimedia.org/wikipedia/commons/e/ec/Volume_ray_casting.png)
>レイキャスティングによるボリュームレンダリングをする方法の模式図。

なるほど。
とりあえず一定距離ずつレイを飛ばしてその地点の色の情報を取得して合成していく雰囲気だと思います。

#作成
考え方は想像出来たのでSharder Toy上で作ってみました。
[![Sharder Toyリンク](https://i.gyazo.com/f6ca720166c803eb0319df197925fdca.png)](
https://www.shadertoy.com/view/ll3SWl)
https://www.shadertoy.com/view/ll3SWl

```
    vec4 sum = vec4(0, 0, 0, 0);
    for (float depth = 0.0; depth < 100000.0; depth += 100.0)
    {
        vec3 ray = campos + fragAt * depth;
        if (cloudrange.x < ray.y && ray.y < cloudrange.y)
        {
            float alpha = smoothstep(0.5, 1.0, fbm(ray * 0.00025));
            vec3 cloudColor = mix(vec3(1.1, 1.05, 1.0), vec3(0.3, 0.3, 0.2), alpha);
            alpha = (1.0 - sum.a) * alpha;
            sum += vec4(cloudColor * alpha, alpha);
        }
    }
```
雲を描画している部分がここです。

簡単に解説すると
1. カメラの位置からfragAtの方向に100.0ずつベクトルを伸ばし、伸ばした座標に依存するfbmを取得
2. 取得した値を元に透明度と雲の色(濃さ)を計算
3. 雲の色を「余っている透明度」に対してその雲の透明度分、合成

「余っている透明度」の部分がすこしわかりづらいですが
例えば1ループ目で透明度50%の雲が発生したら
`alpha = (1.0 - 0.0) * 0.5`
なのでalphaは0.5になります。

2ループ目でもう一度透明度50%の雲が発生したら
`alpha = (1.0 - 0.5) * 0.5`
なので0.75になります。

このように画面奥の雲の色は、それより手前でついた雲の色より影響されにくくなります。

#参考
fbmというのはフラクタルブラウン運動というパーリンノイズの仲間みたいなものです。
http://qiita.com/y_li/items/290754b9c3ba18e9fb2b

潜れる雲を作るにあたって非常に参考になった作品です。
この作品自体はカメラを雲の中に移動させると破綻してしまうんですが、wikipediaの参考画像と合わせてボリュームレンダリングについて理解出来るようになりました。
https://www.shadertoy.com/view/4sXGRM

----------
ところでボリュームレンダリングでこれあってるんでしょうか。
「君のやってるそれ全然違うものだよ」とかありましたらご指摘ください。
【初心者向け】Rails5＋FullCalendarでイベントを登録する

# はじめに

今回は、FullCalendarでカレンダーにイベントを登録するところまでをやります。

# 前提

[前回の投稿](http://qiita.com/fukumura/items/fc46ae2558544306b858)で構築した環境を使っています。

# 登録

イベント登録用のエンドポイントをroute.rbに設定します。

 ```ruby:config/route.rb
Rails.application.routes.draw do
  root to: 'calendar#index'
  get 'calendar/index'
  get 'events', to: 'event#show'
  post 'events/create', to: 'event#create'
end
```

続いて、登録用の処理をcontrollerに書きます。

 ```ruby:app/controllers/event_controller.rb 
class EventController < ApplicationController
  def show
    @event = Event.all
    # render :json => @event
    respond_to do |format|
      format.json {
        render json:
        @event.to_json(
          only: [:title, :start, :end]
        )
      }
    end
  end

  def create
    event = Event.new
    event.attributes = {
      title: params[:title],
      start: params[:start],
      end: params[:end],
    }
    event.save
    respond_to do |format|
      format.json {
        render json:
        @event.to_json(
          only: [:title, :start, :end]
        )
      }
    end
  end
end
``` 

あとは、calendar.jsに処理を追加すればうまくいくはず。
ですが、Railsでは、CRUDを行う際にCSRF対策のtokenを発行するようで
普通にpost投げてもエラーを返されます。
metaタグにcsrf-tokenがセットされているのでそれを取得して
$.ajaxにセットしてリクエストを投げました。

 ```js:app/assets/javascripts/calendar.js
$(document).ready(function() {

    create_event = function(title, start, end){
      $.ajaxPrefilter(function(options, originalOptions, jqXHR) {
        var token;
        if (!options.crossDomain) {
          token = $('meta[name="csrf-token"]').attr('content');
          if (token) {
            return jqXHR.setRequestHeader('X-CSRF-Token', token);
          }
        }
      });
      $.ajax({
        type: "post",
        url: "/events/create",
        data: {
          title: title,
          start: start.toISOString(),
          end: end.toISOString()
        }
      }).done(function(data){
        alert("登録しました!");
      }).fail(function(data){
        alert("登録できませんでした。");
      });
    };

    $('#calendar').fullCalendar({
      header: {
        left: 'prev,next today',
        center: 'title',
        right: 'month,agendaWeek,agendaDay'
      },
      navLinks: true,
      selectable: true,
      selectHelper: true,
      select: function(start, end) {
        var title = prompt('イベントを追加');
        var eventData;
        if (title) {
          eventData = {
            title: title,
            start: start,
            end: end
          };
          $('#calendar').fullCalendar('renderEvent', eventData, true);
          $('#calendar').fullCalendar('unselect');
          create_event(title, start, end);
        }
      },
      timezone: 'UTC',
      events: '/events.json',
      editable: true
    });

});
```

# 最後に

一通り動くようになったら、calendar.jsは整理したいですけどとりあえず今日の目標はデータが格納されるまで。
上記プログラムで動きました。

![スクリーンショット 2016-12-20 1.33.40.png](https://qiita-image-store.s3.amazonaws.com/0/1153/bf2f84e0-27eb-d4f4-f9cf-54db3c150b76.png)

が、user_idがNULLだったり、まだいろいろ整形する必要がありそうですが、本日はここまで。

ソースはこちら。https://github.com/fukumura/dcalen

テストとか、ログインとか、validationとか、その他の細かい処理とか、は追々やっていけたらと思います。
HoloLensで壁を透視して見える綺麗な空に心を落ち着かせる AllSky #アセットアドカレ

この記事は Unity Assets Advent Calendar 2016 13日目の記事になります。

普通HoloLensのアプリはSkyboxはOffにして、背景を透過させて現実の風景を見えるようにしますが、[HoloTour](https://www.microsoft.com/microsoft-hololens/en-us/apps/HoloTour)のように360°コンテンツのようにSkyboxを生かして、現実の風景から目を逸らすことができるリラクゼーションアプリとして仕上げていこうと思います。

# AllSky 4 (Apr 11, 2016)
[![image](https://qiita-image-store.s3.amazonaws.com/0/32347/b8c33880-fdfe-6aac-710a-2788a110d3a9.png)](http://u3d.as/55P)

心落ち着くリラクゼーション効果の高い素晴らしい風景の詰め合わせ、AllSkyを使いましょう。

# HoloLensのカメラでSkyboxを有効にする

HoloToolkit-Unityに含まれるHoloLens向けのMain Cameraプレハブは次のような感じになっています。
![image](https://qiita-image-store.s3.amazonaws.com/0/32347/6fe329df-9e21-f14e-86d9-4252e3341c41.png)

Skyboxを有効にするにはClear FlagsをSolid ColorからSkyboxへ変更する。


# Skyboxを選ぶ
Window > Lightning で Lightningタブウインドウを開き、SceneタブのSkyboxでAllSkyのSkyboxマテリアルを選択する。
![image](https://qiita-image-store.s3.amazonaws.com/0/32347/d7d08d93-7a5e-e995-c84a-9d0556ea8e68.png)

![image](https://qiita-image-store.s3.amazonaws.com/0/32347/190469f3-8240-fa0b-d337-9f5bcdab70a7.png)

で、選んで表示してみると凄いボヤっとしている。


![image](https://qiita-image-store.s3.amazonaws.com/0/32347/62780f6c-1eb7-502b-91d1-ad74e2a5d0b0.png)

これはAllSkyのテクスチャサイズが32x32に設定されてしまっているので、本来のサイズである1024に設定してApplyを押すとキレイでくっきりな空を楽しめる。

![image](https://qiita-image-store.s3.amazonaws.com/0/32347/a34d8c36-2239-bcc5-dd00-0124a1236bf0.png)
uGUIのパフォーマンス・チューニングについて

## はじめに
はじめまして。
株式会社アカツキの新卒Unityクライアントエンジニア、@sevenstartearsです。
アドベントカレンダーのネタを選ぶのは本当に難しいですね、僕にとって、コードを書くよりも難しいかもしれません。
エディターの話をしようと思っていたが、泥沼に足を突っ込むことになりかねないのでやめました。
Unityでパフォーマンスの話をできる範囲内で少ししてみようと思います。

Unityでパフォーマンスと来たら、メモリの話がまずありますが、今回はあえてメモリにフォーカスを絞らず、uGUI回りのパフォーマンス・チューニングについて書いてみたいと思います。
初歩的なものが多いかもしれませんが、どうか暖かい目で読んで頂けると助かります。

## uGUI
パフォーマンスの話をする前に、少しuGUIの使い方の話をします。
多くの場合、チューニングというレベルより以前に、使い方一つで解決できる問題もあります。
今回はアトラスの使用と使わなくなったUIリソースの処理の2点について書きたいと思います。

#### アトラスの使用
uGUIを使う上でアトラスを使わないということは多分ないと思いますので、「アトラスを使いましょう」などの話はいったん飛ばします。
アトラスを使う場合、使い方についてのポイントをいくつか書きたいと思います。
1. 共通のUIパーツ（ダイアログの枠などをもとめて一枚から数枚のアトラス画像にすることで画面遷移するときのロード時間を減らすことができます。
2. 同じ機能のUIパーツ（キャラアイコン）を一枚から数枚のアトラス画像にすることで同じく画面遷移のロード時間を減らすことができます。
3. 同じUI画面のパーツのできるだけ一つのアトラスにすることでDrawCallを減らすことができます。
4. 形揃ってるものと不規則なもの、透明ありのものとなしのものを別々のアトラスにすることで画像の容量と使用するメモリを抑えることができます。 
5. インゲームで使うパーツはアウトゲーム用のアトラスに置かないことで、インゲームではアウトゲームのUIパーツ分のメモリが解放され、インゲームでのメモリ使用に余裕をもたらすことができます。

#### 使わなくなったUIリソース
開発していく過程で、必ず使わなくなるものが出てきます。こういった負の遺産がたまり続けるとやがて大きな負荷になってしまいます。
そういった使わなくなったリソースに対して、しっかり対策を立てていくことが重要です。
1. Resourcesの下にできるだけUIリソースを置かないことで、ビルド時Resourcesの下にないかつ引用されていないUIリソースはビルドの対象から外れます。
2. 使わなくなったUIやアニメーションオブジェクトをDisableなどではなく、しっかりシーンから削除するだけではなく、使わなくなったUI画像のちゃんと削除しましょう。引用を切らすことでビルドの対象から外れることになりますが、Editor上では残り続けるので、最適化判断の邪魔になりかねません。

## CPU
uGUIのパフォーマンスの話をするにはCPUの話は欠かせない、今回はプロファイラーをよく見かけるCanvas.SendWillRenderCanvasesさんやCanvas.BuildBatchさんについて、少し書いてみたいと思います。
基本、UIパーツに変化が発生した場合、CanvasUpdateRegistryがCanvas.SendWillRenderCanvasesイベントが発生することをトリガーとして、LayoutとGraphicのRebuild処理を着火します。
諸悪の根源というほどではないが、このRebuild処理を如何に軽く、回数を少なく抑えるかがCPUの負担を減らす重要な課題にまちがいありません。

#### ヒエラルキーの階層を少なくする
実際リビルド処理に入る前に、ヒエラルキーの階層の深さ順にソートする処理が入るので、階層を少なくすることでソートの時間を減らしRebuildの時間を短縮させることができます。


#### 静的UIパーツを切り分ける
transformやアルファーなど頻繁に変わるパーツを切り分けて特定なCanvasに突っ込むことで、Rebuildの頻度と範囲を減らすことができます。

#### 便利だけど、使わない方が実は軽くなるかもしれないもの
1. Best Fit : テキストのサイズを自動的に調整してくれる素晴らしいものですが、使われるであろうフォントサイズのグラフィックを全部入ってるatlasが生成されるので、生成の時間がかかる上に、サイズもデカくなります。
2. Enable/Disable：オブジェクトのオンオフを切り替えるとき、当たり前のことだがEnable/DisableするとLayoutとGraphicのRebuild処理が入ります。何かいい方法があるのでしょうか？CanvasRendererだけをオフにできれば...
3. Pixel Perfect:使うと、locationが変わる時LayouのRebuildが入ります。ScrollRectとかでこれやるとつらい思いをします。

#### Raycast Targetを外そう
デフォルトではすべてのUIオブジェクトに対してRaycastを取りますが、タッチ判定を必要としないもののRaycast Targetを外すことでCPUの負荷減に繋がります。

## +α的な何か
#### ヒエラルキーの階層をあえて増やす
ヒエラルキーの階層をあえて増やすことでDrawCallを減らすことができる。画像に載せたテキストAとただのテキストBだと2つのテキストに対して、DrawCallが2回だが、Bを透明の画像（Aを載せてる画像とバッチできるやつ）の子供にすることで、テキストの階層が一致し、DrawCallを1回で済みます。ただし、前述のUIのRebuildによるCPUの負荷の関係で、使い方は状況を慎重に見極める必要があります。

#### 空のImageを使った全画面タッチ判定を取るのをやめる
よくあるFullScrennButton的なものが空のImageのアルファーを0にして全画面サイズに設定し、ボタンを付けることで全画面のタッチ判定を取得します。
実はこのやり方は余分のOverDrawに繋がります。基本タッチ判定はGraphicであれば取れますので、画像である必要は全くありません。
Graphicを継承した簡単なクラスを作ることで、同じ処理を実現することができます。

## 最後に
だらだらといろいろ書きましたが
どれも「これやれば画期的にパフォーマンスが変わる！」のようなものではありません。
そもそも、そんなものがもしあれば、知りたいです。
パフォーマンスのための最適化は「塵も積もれば山となる」の言葉を信じて、コツコツやっていくしかないと思っています。
しかも、メモリ最適化しすぎると、CPUの負荷がかかり過ぎてプラマイゼロなんてことも十分ありえます。
プロファイラーと睨めっこしながら、もっとも解決すべき問題を少しつつ最適化していく苦行がやがて快適なユーザー体験につながるのであれば、それもまた楽しいことだと信じています。
Qiitaでコードを引用する方法

始めるぞー！と意気込んだ結果、かなり探したので恥ずかしいけどここから書いてみる。
バッククオート（`）３つで囲む。
バッククオートは「Shift + @」で出てきます。

「 ```言語:ファイル名」で始めると・・・以下のような形で幸せになれます。

```js:test.js
console.log("hello");
var hoge = 3
```

```c:test.c
int main(void){
 printf("hello world");
 return 0;
}
```
WAF ACLをCFに設定できず人生が辛くなるたった一つの方法

未だにサガスカーレットグレイスを買っていない俺ですこんばんは。

`aws:SourceIp` でIAM User Policyを縛ってるIAMを使い、WAF ACLをCFに紐付けたりすると以下の様なエラーがでます。

# error

```
Web ACL is not accessible by the requester. (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidWebACLId; Request ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
```

# 対策

`aws:SourceIp` を一時的に削除するなりしましょう。

完