OmniAICreator/Qiita-1.07M huggingface dataset:
展示组件和容器组件的那些事儿


[from Dan Abramov](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.gcjw814bw)

我发现有一些比较重要的模式,他们虽然简单, 但是对于写React 程序是非常有用的. 如果你已经写了一阵的React 应用  你可以已经发现并注意到了, 这篇文章有介绍到它, 但是这里我还是想说几句.

当你把组件划分为2类时,你会发现他们很容易重用. 我将它成为容器和展示组件. 但是我也听到有人这么叫他们, 什么肥瘦啊, 聪明傻蛋啊, 有状态的和无状态的, 还有屏幕和组件等等. 这些通常还都有些区别, 但是其想法精髓是类似的.



通常展示组件他们是这样的:

- 只关心我们看上去像什么
- 可能会包含一些容器组件的东西,但是通常还是有一些DOM 标记和样式
- 通常还允许通过this.props.children来控制
- 和 app 里的其他组件内容完全没有依赖关系, 如 Flux 里的动作和 store
- 不会参与数据流向和修改
- 通过props 来接收数据并且回调
- 通常没有状态(如果有,也是 UI 的状态而非他们的数据)
- 通常都是被写成函数组件, 除非他们需要状态,或者生命周期 hook 或则性能上的优化.
- 例如 Page, sidebar, Story, UserInfo, List 等
  

通常容器组件是这样子的:

- 只关心他们是怎么工作的.
- 可能包含一些视图组件的东西, 但是通常并没有 DOM 标记,来用表示他们组件, 有也只是用来封装一些div 等.从来都不会有样式内容.
- 给其他的展示或者容器组件提供数据
- 通过调用 Flux 的动作,来给展示容器提交回调
- 通常是有状态的,他们可称之为数据源
- 通常都是通过上级的组件来生成, 如React Redux 的connect()方法, 或者** Relay的createContainer() 方法, 或者 Flux** 的帮助方法Container.create()还有其他自己手写的.
- 如UserPage, FollowerSideBar, StoryContainer 等

通常会把他们方法哦不同的文件夹里以清楚的区分.



这样做有什么好处?

- 代码更加清晰,让你懂得app 和ui 间的区间和关系
- 更好地重用性, 你完全可以重用一个组件,尽管他们从属于完全不同的 state 源, 大大的增加了组件的重用性.
- 展示组件作为 app 的脸面,你完全可以让设计人员放开手脚尽情展示才华而不会去 care app 的逻辑.你可以跑可以通过集成测试截图每一个页面.
- 这个迫使你抽取那些版面布局的组件, 如 sidebar, Page, 上下文等通过使用this.props.children代替那些多余重复的标记和布局

记住, 组件不会去触碰 DOM, 他们只是用来帮助提供 UI 相关的所需

切用且珍惜



什么时候把玩容器?



通常我会建议你从设计展示组件开始, 事实上这样你意识到你在组件里追加过多的属性. 当你注意到很多时候你给那些组件的属性他们并不用,而只是简单的传递给下游, 你就需要过多的数据来每次重新渲染这些中间状态组件. 这个时候就推荐使用容器组件了. 这样你就可以不需要这些冗余的组件来获取数据和属性了.



而事实上, 这个过程是在不断的重构当中发生. 不要试图去一下子搞定它. 当你使用这个模式开发的时候,就会逐渐养成一种习惯或者直觉, 懂得何时需要重构. 就好像编码的时候感觉这个地方应该抽出去做一个 function 了. 瞧瞧我的例子.



其他的方法

事实上关于展示组件和容器组件的划分完全是出于目的而非技术. 相比还有很多其他的方法来解决这样的问题:

- 有状态和无状态, 一些组件通过 react 的 setState() 方法,一些组件不使用. 也就是容器组件不让他有状态, 而展示组件让它有状态. 这个不是一个硬性的规定. 展示组件可以有状态, 当然容器组件也可以无状态.
- 类和函数, 从 React0.4 开始, 组件就可以声明为类或者函数了. 函数式组件相比较就是容易定义,但是没有类式组件的一些特性. 如果在使用的时候如果不需要它又很多的相关方法调用状态设置就使用函数式的组件定义好了.
- 纯于不纯, 人们经常说如果一个组件给它不变的参数始终保证返回同样的值和状态它就是pure 的, 纯组件可以被定义成类或者函数. 同时可以是有状态的或者无状态的. 另外一个主要的纯组件就是, 他们不依赖于修改props 或者state, 这样就可以通过影子比较 shouldComponentUpdate()hook 来优化渲染性能. 当前只有类组件可以使用它.

关于展示组件和容器组件, 他们可以互换. 我的经验告诉我, 展示组件更加趋向于无状态纯函数, 容器组件更加趋向于有状态的纯类. 但是这样也是一个约束而非规则. 我也见过反其道的有道理的用法.

同时,不要老是嘴上挂着展示组件和容器组件,很多时候你分不清彼此. 别纠结, 先放着.



这个哥们写的gist 不赖可以看看.



Further Reading

- Getting Started with Redux
- Mixins are Dead, Long Live Composition
- Container Components
- Atomic Web Design
- Building the Facebook News Feed with Relay

-THE END-
【C#】最新FirefoxでSelenium Webdriver が動かくなった時に行ったこと

2016.9.12 時点、C#、VisualStudioでの開発中に起きた問題です
2016.9.13 過去のテストコードを一旦無視した形で、Selenium 3.0.0-beta3を使い、geckodriverを使うようにしたらFirefox48でもすんなり動きました。

## 環境など

・ Windows 10
・ VisualStudio Professional 2015
・ C#

## 症状

テスト用のURLに遷移させる際（要するにFirefox起動時）に「アドレスの書式がただしくありません」と表示され、例外で落ちる

## 解決方法

これらは全部ダメでした

・ Firefox最新へのアップデート (47→48.0.2)
・ Firefoxの全てのアドオンを無効化

で、結局 Firefox 46 を落としてきて FirefoxBinary を古いのに向けたら動きました。[ここから](https://ftp.mozilla.org/pub/firefox/releases/)探してインストールしてね

他にも解決方法はあるのかもしれないけど、あまり時間をかけてられなかったのでダウングレードするという結論にいたりました。


## 追記(2016.9.12)

近々 Geckodriver で解決できるかどうかも試してみます


## 追記(2016.9.13)

以前に書いたテストコードでは試していませんが、環境を以下のようにすると最新Firefoxでもすんなり動きました。

・Selenium 3.0.0-beta3
・geckodriver v0.10.0

ではサンプルコードです

```csharp

using OpenQA.Selenium;
using OpenQA.Selenium.Firefox;

namespace Selenium3
{
  class Program
  {
    static void Main(string[] args)
    {
      using (IWebDriver driver = new FirefoxDriver())
      {
        driver.Navigate().GoToUrl("http://webya.in");
      }
    }
  }
}
```

### 注意点

geckodriver は [github](https://github.com/mozilla/geckodriver/releases)から落としてきてください。更に解凍した**ディレクトリにPATHを通してください**。

selenium 3.0.0-beta3 は [公式](http://www.seleniumhq.org/download/) から落としてプロジェクトにて参照設定に追加しておきましょう。
iOS10端末でdidReceiveRemoteNotificationが呼び出されない

- Xcode7でビルドしたアプリを
- iOS10端末で実行した場合に
- ユーザが Remote notification のシステム通知をタップした時に

という条件で、

- `application:didReceiveRemoteNotification:fetchCompletionHandler:` が呼び出されず `application:didReceiveRemoteNotification:` の方だけが呼び出される
- なので、前者のみを実装しているアプリで、通知のuserInfoに応じた動作が出来ない
 - 手元のアプリでは、userInfoで指示された画面を開く動作ができず、単にアプリ起動される

という現象にハマりました。
同じ話が、 [Apple Developer Forums](https://forums.developer.apple.com/thread/54332) にも上がってました。

現状としては、

- iOS 10.0.1 GM seed (14A403) でも発生
 - OSのバグかな？とも思うが、GM seed でもおきるから、このままかな..
- 後者のメソッドから前者のメソッドを呼び出すように実装(※)されていれば問題ない

という状況なので、対処としては、

- Xcode7ビルドのまま、※の実装をする
- Xcode8 UNUserNotificationCenter に対応する

のどちらか、かな。
成長する人の技術ストックのため方

取り立てて目新しいことではないのですが、個人の力を形成する上で地味に効いてくるポイントをシェアします。

**基本的なスタンス = ナレッジを消費しない**

------
**成長が遅い人**
　納期明日かぁ・・・、このバグ原因わかんねぇや。
　あ、記事発見、直った。よし、コミットコミット。
　完了。終了。

------
**成長が早い人**
　なんとか終わった・・・。さっき原因がはっきりつかめなかったところ、
　ダミープロジェクト作って再現して、解決策を明文化しておこう。
　プロジェクト作成して、みんなと共有しよー。

------

こんな単純なことです。

僕らは日々仕事に追われています。復習の時間がなかったり、自分のテンションがあがる別のプロジェクトに一刻も早く取り掛かりたかったりします。
でも、原因を正しく理解し、解決方法を明確にすることは、次に同じ問題に遭遇した時の対処時間の削減や、チームの中で他の誰かが同じ問題に遭遇して生産性が低下しているところを解決できることにもつながります。

特に新しい言語を始めたばかりの時は多くの「なんだったんだろう？」に遭遇すると思いますが、その原因をきちんと再現性がある状態で解決する事が、その後に非常に活きてきます。

これまでおろそかしにしてきたので今更そういうことをやっているわけですが・・・大事です。
なめらかアコーディオンパネル


　どうでもいいけどサンプルのラテン語なんだろうあれ

## なめらかではないアコーディオンパネル

``` HTML:index.html

<dl>
	<dt ng-click="showPanel=1">Step.1</dt>
	<dd ng-hide="showPanel!=1"><p>...</p></dd>
	<dt ng-click="showPanel=2">Step.2</dt>
	<dd ng-hide="showPanel!=2"><p>.../p></dd>
	<dt ng-click="showPanel=3">Step.3</dt>
	<dd ng-hide="showPanel!=3"><p>...</p></dd>
</dl>

```

　dt要素のクリックでshowPanelの値を更新、値によってdd要素の表示を切り替えています。
　アコーディオン感はありませんが取り敢えずぱたぱた開閉はします。

## なめら化

　前回と同じくngAnimateを追加します。


``` HTML:index.html

<script type="application/javascript" src="../angular/angular-animate.js"></script>

```

``` JavaScript:main.js

angular.module('sample', ['ngAnimate']).controller('IndexController',
		[ '$scope', function($scope) {} ]);

```

　ngAnimateを追加すると表示/非表示(ngHide)の切替時にngHideAddやngHideRemoveが追加されるようになります。一秒くらいですぐ外されるクラスです。
　この追加されるクラスに対応するCSSを書いてやります。

``` CSS:base.css

dd {
	margin: 0;
	background: #d4d0c8;
	overflow: hidden;
	transition: 1s linear;
	-webkit-transition: linear 1s;
	-moz-transition: linear 1s;
	-o-transition: linear 1s;
}

dd:not(.ng-hide){
	max-height: 50em;
}

dd.ng-hide{
	max-height: 0em;
}
 
.ng-hide-remove {
	max-height: 0em;
}

.ng-hide-add{
	max-height:50em;
}


```

　で、開閉が同時に行われないのはなぜだろうなこれ

## ngClickを用いた開閉

　開いているパネルを閉じることができないのでngClickに動作を突っ込んでやります。
　現在は簡単に`ng-click="showPanel=1"`としていますのでここを`ng-click="onClickHeader(1)`とかに変更。

``` JavaScript:main.js

$scope.onClickHeader=function(num){
	if($scope.showPanel==num){
		$scope.showPanel=0;
	}else{
		$scope.showPanel=num;
	}
}

```

　これで開いているパネルも閉じることができるようになりました。
　開閉が同時に行われない問題の対策をご存じの方はご教示ください……_(:3」∠)_
「進捗・どう・です・か」をbashで

http://qiita.com/B73W56H84/items/a6c4b770c6efc8d1af35

超今さらだけど乗っかってみる

```bash:進捗どうですか.sh
#!/bin/bash

a=(進捗 どう です か)
b=(_ _ _ _)

n=0
while :; do
    i=$((RANDOM % ${#a[*]}))
    echo -n ${a[$i]}

    # array rotate
    b[ ${#b[@]} ]=${a[$i]}
    b=("${b[@]:1:4}")

    n=$((n+${#a[$i]}))

    if [ "${a[*]}" == "${b[*]}" ]; then
        break
    fi
done

(IFS=; echo "${a[*]}???")
echo "${n}文字で煽られました"
```

# ついでにruby版

`tap` 使うのはなんかフェアじゃない気もするなぁ。

```rb:進捗どうですか.rb
#!/usr/bin/env ruby

n=0
puts "\n%s???" % Array.new(4).tap { |b|
  %w(進捗 どう です か).tap { |a|
    (print b.rotate!(1)[b.size-1] = a.sample) or n += b[b.size-1].size while b.join != a.join
  }
}.join
puts "%d文字で煽られました" % n
```

# ついでにpython2系

やり方は全部同じだけど。

```py:進捗どうですか.py
#!/usr/bin/env python
# coding: utf-8

import sys
import random
import itertools
from collections import deque

a = [u"進捗", u"どう", u"です", u"か"]
b = deque(u"____")

n=0
for i in (random.choice(a) for x in itertools.count()):
    b.popleft()
    b.append(i)
    sys.stdout.write(i)
    n += len(i)
    if u"".join(b) == u"".join(a):
        break

print u"\n%s???" % u"".join(a)
print u"%d文字で煽られました" % n
```

なお、進捗は芳しくない。
SQL Server で最初に設定すべき３つのこと

#はじめに
SQL Serverでは、最初に必ずやらねばならない３つのことがあり、これを行わず、結果としてSQL Serverのパフォーマンスを活かせていないケースが多々ある


#その１：MAX DOPの設定

- サーバプロパティの詳細設定にある「並列処理の最大限度」を設定する
    - NUMA構成の場合は、NUMA内の物理コア数を設定
    - 一般構成の場合は、1/4 or 1/2×物理CPU数（物理コア数）を設定
    - SAPで使うときは1を設定する
    - SQL Server を実行するノードすべてで行う
- 注意点
    - HTを入れた論理数ではない
    - NUMA構成かどうかは、詳細設定にある「プロセッサ」を見るとわかる
- よくわからないとき
    - 1を設定する
    - 0は無制限なので絶対にダメ

#その２：tempdbデータファイルの分割

- tempdb のデータファイルの数を物理CPU数（物理コア数）と同じにする
- SQL Server を実行するノードすべてで行う


#その３：メモリ内のページロックの権限付与

- ローカルセキュリティポリシーで、SQL Server 実行アカウントにメモリ内のページロックの権限を付与する
- ローカルポリシー → ユーザー権利の割り当て → メモリ内のページのロック 
- SQL Server を実行するノードすべてで行う
- 今更SQL Server 2008 でもないのだが、SQL Server 2008 R2 Stdの場合はトレースフラグ845の付与もする
配列の複数要素の削除はdelete_ifかreject、-なんかを使おう

本記事は個人ブログからの焼き直しです。[^1]

# tl;dr
配列の複数要素の削除はdelete_ifかreject、-なんかを使いましょう

# each内でdeleteした場合に問題が起きる

Rubyで配列があったとします。
この中で、特定の文字列を含む要素を1つだけ削除したいです。
それであればArray.delete('特定の文字列')で済みます。

もし、その特定の文字列というのが複数ある場合はどうしましょう？
複数あるなら、それを配列にでも突っ込んで、イテレートしてdeleteしていけばいいんじゃない？
と考えたのが以下の実装です。
 
```rb:array_delete.rb
target = ['hoge', 'fuga'] # 元となるデータ
list = ['hoge', 'fuga'] # 削除対象の文字列のリスト
target.each do |str|
  target.delete(str) if list.include?(str)
end
p target # ["fuga"]
```

なんとfugaが残ってしまいました！

よく考えれば、分かることかもしれませんが、イテレートしている最中に要素を削除することで内部ポインタがずれてしまうのです。
ここの例だと配列の0番目はhogeです。
最初のループでstrにはhogeが入り、
```if list_include?```にかけられてtrue、target.deleteが実行されます。
その直後にtarget[0]をprintしてみると、fugaが入っています。

 
```rb:because.rb
target = ['hoge', 'fuga'] # 元となるデータ
list = ['hoge', 'fuga'] # 削除対象の文字列のリスト
target.each_with_index do |str|
  p target[0] # 'hoge'
  target.delete(str) if list.include?(str)
  p target[0] # 'fuga'
end
# 要素数(hoge削除後のfuga1個)とループの数(hogeを削除したときの1回)が一致したので1周しかしない
p target # ['fuga']
```

ということで、配列の場合はポインタが狂ってしまうので、削除にeach＆deleteを使うのはオススメしない、という話です。
こういうこともあるので用意されているのが、delete_if、rejectメソッドということなんですね。

# delete_if, rejectなら問題なし
delete_ifやrejectメソッドはこういうことがおきません。

```rb:delete_if.rb
target = ['hoge', 'fuga'] # 元となるデータ
list = ['hoge', 'fuga'] # 削除対象の文字列のリスト
target.delete_if do |str|
  list.include?(str)
end
p target
```

用意されているにはそれなりにワケがありますね。

# #-メソッドもあるよ
元記事のほうのコメントでshinoさんという方からご指摘を頂きましたが#-メソッドを使えば差を求めることができ、同様の結果になります。
（推測混じりですが）delete_ifなどと違いEnumeratorを使うわけではなさそうなので要素数が非常に多い環境では顕著に高速に動作するものと思われます。

```rb:minus_method.rb
require 'benchmark'

srand(62438757249)
target = (1..1000000).map{ rand(10000) } # １００万要素の配列を作成
list = (1..10000). map{ rand(100000) } # 削除対処のデータを作成
delete_if_target = target.dup # delete_ifだと元データから削除されてしまうのでdelete_if用にデータをコピー
res = nil # -メソッドの結果用の変数初期化

Benchmark.bm(10) do |r|
  r.report('delete_if') do
    delete_if_target.delete_if {|v| list.include?(v) }
  end

  r.report('- method') do
    res = target - list
  end
end

#                  user     system      total        real
# delete_if  365.790000   2.400000 368.190000 (379.281810)
# - method     0.110000   0.010000   0.120000 (  0.118205)

p delete_if_target == res # true 結果が同値であることを確認
```

-の方が速攻で終わってますね。

# まとめ
データ量ややりたいことに応じてメソッドを使い分けましょう。

[^1]: http://no-zom.jp/blog/?p=577
Trelloを便利に使うためのオススメChrome拡張機能

# カード管理
## Card Colors for Trello
- 概要
    - ラベル別にカードの色を分けてくれます。視認性に大きく効くのでおすすめです。
- Download
  - https://chrome.google.com/webstore/detail/card-colors-for-trello/nodlpencjjlohojddhflnahnfpfanbjm

## Card Color Titles for Trello
- 概要
    - ラベルに色をつけてくれます。Card Colors for Trelloと合わせて使うとよいです。
- Download
  - https://chrome.google.com/webstore/detail/card-color-titles-for-tre/hpmobkglehhleflhaefmfajhbdnjmgim

## CardCounter for Trello
- 概要
    - カードが増えすぎると下まで見渡せないことが多いと思います。
    - 一番上にカードの総数が表示されますので見通しやすくなります。
- Download
    - https://chrome.google.com/webstore/detail/cardcounter-for-trello/miejdnaildjcmahbhmfngfdoficmkdhi/related

# プロジェクト管理
## Projects for Trello
- 概要
    - {}で囲むことで通常のラベルとは別にラベル設定できます。多次元管理に便利。
- Download
    - https://chrome.google.com/webstore/detail/projects-for-trello/mholjhodapabhdbchonjjoecmfhobfoa

## Plus for Trello (time track, reports, scrum)
- 概要
    - タイムトラッキングやグラフなので後から振り返りがやりやすくなります。
- Download
  - 
https://chrome.google.com/webstore/detail/plus-for-trello-time-trac/gjjpophepkbhejnglcmkdnncmaanojkf

# 参考リンク
- http://tech.oga-ria.com/start-trello-and-scrum-for-trello/
- http://designer.hatenablog.jp/entry/trello-usage
- http://qiita.com/umeyee/items/7d09b011ee611cbecce3
Visual Studio Code で Electron をデバッグ実行(Windows)

WindowsでElectronをデバッグ実行する方法。
(MacやLinuxではちょっといろいろと試してみたけど不慣れなものでうまくいかなった。)
launch.jsonを以下のように設定することで、VSCodeからデバッグ実行することができました。
(Electronを-gでインストールした場合)
ただし、デバッグできるのはメインプロセスのみ。
VSCodeで開いているフォルダが、appフォルダの親のフォルダの場合の設定です。
stopOnEntryをfalseにすれば--debug、trueにすれば--debug-brkオプションで起動されます。

```launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Electron Debug",
            "type": "node",
            "stopOnEntry": false,
            "program": "${workspaceRoot}/app/main.js",
            "args": [],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": null,
            "runtimeExecutable": "C:\\Users\\gtk2k\\AppData\\Roaming\\npm\\node_modules\\electron\\dist\\electron.exe",
            "runtimeArgs": [],
            "env": {
                "NODE_ENV": "development"
            },
            "console": "internalConsole",
            "sourceMaps": false,
            "outDir": null
        }
    ]
}
```
エンジニアが安心してビジネスメールを送れる環境をつくる


# はじめに

以前記事にした[プラットフォームの仕事](http://qiita.com/tomoyamachi/items/0f049c87bfdef4aa6ad9)が少なくなってきたこともあり、広告やマーケティングまわりの仕事をはじめた。
アドテクはこれまでやりたいと思っていた分野だったので、他社の人をふくめ色々話を聞いて刺激を受けている。

さて、そのチームにエンジニアがいないこともあり、技術的なサポートも対応を行ったりもする。
そういう仕事がはじまって1週間が過ぎたのだが、メールを送るという作業がリスクが高いわりに、リスクヘッジができていないと感じたので 安心してメールを送るまでにしたことをメモする。

# エンジニアにとってビジネスメールのリスクが高い点

- 他社とのコミュニケーションを取らなければならない
- 一度相手のメールサーバに届くと編集できない
- ステージング環境がない
- テストコードがない
- よくわからないビジネスマナーがある 
	- ファイルをパスワード付きzipファイルにする
	- パスワードは別のメールで送る
	- 宛名は`{会社名}{名前}様<to@mail.com>`のフォーマット


日々何通も送信するメールを、人間の注意深さだけに頼っていたら絶対ミスをする。
すくなくとも自分はミスをする可能性が高い。
こんな無防備なシステムを使い続けて、送付ミスとかして信頼なくしたくないものね。


# つくったシステム

流れとしては以下のとおりで、できるかぎり本番環境(対象へのメール送信)までのチェック数を増やしている。
![mail_check.png](https://qiita-image-store.s3.amazonaws.com/0/14275/380a1a2f-1000-3c3f-edd6-0dbae00d538f.png "mail_check.png")



> 利用している外部サービス
> Yahoo!校正支援API
> [テキスト解析:校正支援 - Yahoo!デベロッパーネットワーク](http://developer.yahoo.co.jp/webapi/jlp/kousei/v1/kousei.html)

正直これでも不安は拭えないが、だいぶマシにはなった。
まだ5つしかテンプレはないが、ほとんどそのメールでやりとりが完了するので、リスクはだいぶ減らせた。

# 今後の課題
以下のように個別処理も多いので、なかなか作りを固定できない。

- 指定されたテキストをtxtファイルとして保存
- パスワード付きzipファイルにする
- 添付したzipファイルとは別のメールで、解答パスワードを送信する

パスワードを別送するという文化は嫌いだが、それを求める人がいる以上はやらなければならないのである。


# 最後に
まだ固有の処理が多い。
汎用化できるようになったらコードを公開する予定。

検索したかぎり、今回メモしたようなサービスは見当たらなかったのだが、
すでにそのようなサービスがあればぜひ知りたい。

## ちなみに本システムの環境
- SMTPサーバ : smtp.gmail.com
- 通信プロトコル : TLS
- メールクライアント : [PHPMailer](https://github.com/PHPMailer/PHPMailer)
- 文章校正 : [Yahoo!校正支援API](http://developer.yahoo.co.jp/webapi/jlp/kousei/v1/kousei.html)
Android SQLiteのファイルをadbコマンドで取得

AndroidでSQLiteのデータベースを作成すると
```/data/data/[パッケージ名]/databases```ディレクトリの中に、プログラムで指定したデータベース名のファイルが作成されます。

そのファイルの内容を確認したい場合、下記のコマンドをコマンドプロンプト(ターミナル)で実行することでデータベース・ファイルの内容をコマンドプロンプト(ターミナル)内で確認できます。

```adb shell run-as [パッケージ名] cat databases/[データベース・ファイル名]```

Rubyをインストールしてある環境で下記のコマンド実行することで、スマホ内にあるデータベース・ファイルをパソコンにコピーできます。

```adb exec-out run-as [パッケージ名] cat databases/[データベース・ファイル名] | ruby -pne '' > /[保存したいパソコンのディレクトリ]/[保存したいファイル名]```

例えば、パッケージ名が```jp.co.xxx.yyy``` データベースのファイル名が```database.db``` 保存したいパソコンのディレクトリが```/Users/taro/Desktop``` 保存したいファイル名が```dump.db```の場合、
```adb exec-out run-as jp.co.xxx.yyy cat databases/database.db | ruby -pne '' > /Users/taro/Desktop/dump.db```
を実行するとスマホ内のdatabase.dbのコピーであるdump.dbファイルが/Users/taro/Desktopに生成されます。

同様にしてアプリ内に保存したpreferencesのファイルもパソコンにコピーできます。

アプリで作成したpreferencesの値はxmlファイルとして```/data/data/[パッケージ名]/shared_prefs```に保存されます。
上記のデータベースのファイルをコピーしたのと同様に
```adb exec-out run-as [パッケージ名] cat shared_prefs/[preferencesのxmlファイル名] | ruby -pne '' > /[保存したいパソコンのディレクトリ]/[保存したいファイル名]```
を実行するとpreferencesのkeyとvalueが記録されたxmlファイルをスマホからパソコンにコピーできます。

毎回コマンドを入力するのは面倒なのでバッチファイル(.bat)やシェルスクリプト(.sh)を作成しておくとマウスのクリックひとつでスマホからパソコンにファイルをコピーできるので便利でしょう。

※コマンドプロンプト(ターミナル)でどこのディレクトリからでもadbやrubyコマンドを実行できるようにPathを通しておきましょう。
umbrella header 'Realm.h' not found エラーの対処

CocoaPods を 0.39.0 から 1.0.1 にあげて、次のエラーが出ました。

```shell-session
umbrella header 'Realm.h' not found
```

ドキュメントに書いてあるとおりに Realm を再インストールしたらうまくいきました
https://realm.io/jp/docs/swift/latest/#cocoapods

```sh
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate || rm -rf Pods
pod install --verbose
rm -rf ~/Library/Developer/Xcode/DerivedData
```

なお、以前は Realm は CocoaPods 1.0 以降をサポートしておらず 0.39.0 を使いましょうという古い記事も見かけますが、いまは既にサポートしています。
https://github.com/realm/realm-cocoa/issues/3052
[ JavaScript ] リンクを開く

``` open_url.html
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Javascript でリンクを開く</title>
    <script>
        // 同一画面でリンクを開く
        function openURL(url) { location.href = url; }
        
        // 別画面でリンクを開く
        function openWIN(url) { window.open(url); }
    </script>
</head>

<body>
    <a href="javascript:void('0');" onclick="openURL('https://www.google.co.jp/')">同一画面でリンクを開く</a><br>
    <a href="javascript:void('0');" onclick="openWIN('https://www.google.co.jp/')">別画面でリンクを開く</a>
</body>
</html>
```
Rails新規開発時のディレクトリ構成

# Rails新規開発時のディレクトリ構成
## app下の構成を先に決定
Rails5でアプリ新規開発時にディレクトリの構成を先に決定しました。
その経緯と実際の構成です。

### メリット
* 先にある程度ディレクトリ構成の方向性を決めておく事により実装フェーズでエンジニアが配置場所に悩む時間を減らす。
* PRが送られた時に新たな構成を作ってくる場合、コードレビューにより手戻りが発生する事を減らせる。
* 構成が決まっていないゆえに、チームにジョインしたてのエンジニアなどが振る舞いと一致しない場所にコードを増えていくことを防ぐことができる。

## app構成(Rails既存のディレクトリは除く)
cells
decorators
forms
observers
services
validators

### Directories
#### cells
viewの部分テンプレートとコンポーネントを独立させるcells用のクラス群を配置します

#### decorators
モデルに対応するデータの整形処理はhelperを廃止しdecoratorに移動させます

#### forms
独自formオブジェクト用のクラスを配置します

#### observers
Rails4から廃止されたrails-observerですが、モデルのcallbackやステータスチェンジ時の見通しを良くするためrails-observerを導入しディレクトリを配置します

#### services
モデルに紐付かない処理や振る舞いに対する処理用のクラスを配置します

#### validators
独自validationを作ることも多くなって来ると思いますがValidationクラスの共通化をし配置します


## その他
プロジェクト全体で共通のライブラリはlib/直下に配置

## 参考
[cells](https://github.com/apotonick/cells)
[rails-observer](https://github.com/rails/rails-observers)
[ jQuery ] onClickでページ内スクロール

```page_scroll.js
$(function () {
        // hrefがハッシュ（#）から始まる<a>要素をクリックした時
	$('a[href^="#"]').on('click', function () {
		var _href = $(this).attr('href');
		if (_href.replace('#', '') === '') {
			// hrefが # のみの時は、何も返さない
			return false;
		} else {
			// # の後に文字列がある時、ページスクロールを起こす
			var $target = $(_href).offset().top, // スクロール目標
				_easing = 'linear',              // スクロール効果
				_speed = 'slow';                 // スクロール速度（'fast', 'nomal', 'slow', ミリ秒）
			
			$('html, body').animate({ scrollTop: $target }, _speed, _easing);
			
			return false;
		}
	});
});
```
[ jQuery ] ユーザーエージェント判定

# jQueryでユーザーエージェント判定を行うコード

```ua.js
$(function () {
	var ua = navigator.userAgent;
	if (ua.indexOf('iPhone') > 0 || ua.indexOf('Android') > 0 && ua.indexOf('Mobile') > 0) {
		// スマートフォン用コード
	} else if (ua.indexOf('iPad') > 0 || ua.indexOf('Android') > 0) {
		// タブレット用コード
	} else {
		// PC用コード
	}
})
```
UITableViewを滑らかにスクロールさせるための確認すべきポイントまとめ

UITableViewを滑らかにスクロールさせるための方法が色々なところで公開されていますので、確認するべきポイントをまとめて列挙します。
基本的には、`tableView: cellForRowAtIndexPath` 内での重い処理を避けるというのが大前提になります。
セルを生成するために毎回呼ばれるメソッドの中での処理を軽くしてやることで、滑らかなスクロールを実現します。
この手のポイントは数多く存在するので、主立った一部を紹介します。

## 透過ビューを使わない
透過画像を生成するのは重い処理なので避ける。
半透明にすると、オフスクリーンレンダリングという重たい処理が発生してしまう。
これはUILabelの文字列に対しても発生する。
### 対策
- 必要のない部分では、`alpha`を1.0または0にする
- 背景色をベースカラーと合わせて投下させないようにする
- UILabelの範囲を必要最小限に留める

現在どれくらい使われているかは、Simulator -> Debug -> Color Blended Layers
にチェックを入れることで、シュミレータから視覚的に確認することができる。
使われている部分は赤く表示されるので、その部分を減らすようにする。

## layerの効果を使わない
UILabelやUIImageでlayerを利用することで角を丸めたりなどの効果を付けることが出来るが、
これもオフスクリーンレンダリングが発生する重い処理なので避ける。
あらかじめ丸く加工した画像を用意しておくなどして、対処する。

## 表示する画像のサイズと実際の画像のサイズを統一する
実際に必要な画像のサイズよりも大きなものをセットしようとすると、メモリを多く消費してしまう可能性がある。
予めリサイズしてからセットする、そもそもサイズが統一されたものを用意しておくなどする。

## 通信は非同期で行う
tableViewの中で、同期的に画像を読み込むと重くなる。
SDWebImageなどを利用して、非同期読み込みを行う。

## ファイル読み出しを使用しない
NSUserDefaultなどのファイル読み出しは遅くなるので避ける。
中身をあらかじめ取り出しておいて値を利用する。


## セルを再利用する
セルを生成する処理は時間がかかってしまうので、一度生成したセルを再利用するようにする。
`dequeueReusableCellWithIdentifier`を利用して、再利用可能なセルを取り出す。

## セルの高さをキャッシュする
セルの高さが変わらない場合は、高さを決定する`heightForRowAtIndexPath`での計算を毎回やらずに、計算結果をキャッシュするようにする。


## 参考
http://qiita.com/yimajo/items/a796739be4496f7aa3dd
http://qiita.com/noppefoxwolf/items/3109857f60e25816e55d
http://labs.gree.jp/blog/2013/12/9669/
http://tech.pero.li/entry/2016/07/01/193000
http://mokyu.game-ss.com/it%E9%96%A2%E9%80%A3/uitableview%E3%81%AE%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E6%BB%91%E3%82%89%E3%81%8B%E3%81%AB%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
http://blog.yoneapp.com/entry/2016/01/12/174947

### まとめ
tableViewの滑らかさはアプリケーションの使い心地に直結するので頑張ってチューニングしましょう。
また見つけ次第追記します。
[メモ] ConEmuからMSYS2のmintty経由でbashを起動する

以下のタスクを指定する。

```
set CHERE_INVOKING=1 & %ConEmuDrive%\msys64\usr\bin\mintty.exe  -i /msys2.ico /usr/bin/bash --login -new_console:d:%ConEmuDrive%\msys64\home\%username%
```
PHPのLaravelフレームワークのVagrant box(homestead)入れてみた

せっかく導入したので、躓いたところなどメモします。

# 本家マニュアル
[本家マニュアル](https://laravel.com/docs/5.3/homestead)

これだと分かりづらかったので、参考にしたのは下記

# 分かりやすかった日本語記事

[[PHP]WindowsでHomesteadを使ってLaravel5開発環境を作る(1/2)](http://php-archive.net/php/windows-homestead-laravel5-1/)
[[PHP]WindowsでHomesteadを使ってLaravel5開発環境を作る(2/2)](http://php-archive.net/php/windows-homestead-laravel5-2/)

# 日本語記事のほうでも気になる所があったので補足

* ubunt16.04、php-fpmとnginxで動いています。apacheは使ってないです。
* Windowsでやる場合、隠しフォルダが見える設定にする必要がある。

## homestead.gitをcloneしている理由

```bash
git clone https://github.com/laravel/homestead.git Homestead
```

vagrantや仮想環境中のミドルウェアの設定をするために使用。これを使用して簡単に設定変更が出来るように作ってあります。このgitプロジェクト自体にvagrantの設定ファイルがあるので、vagrant initとかすると、ファイルが存在すると怒られます。

また、clone場所は、ユーザのホームフォルダでやる前提になっています。仮想サーバとクライアントとの共有フォルダの設定もやるので、ディレクトリ構成が、ズレると起動しません。
（そこも理解して変更すればおｋですが、何も考えずに構築する場合は、合わせたほうがよいと思います）

## 新サイト追加
* serve hoge.homestead.app /home/vagrant/Code/hoge-sample-web/public
* hostsに、下記を追加する。
 * 192.168.10.10 hoge.homestead.app

このコマンド、一見魔法っぽく見えますが、homestead用のスクリプトが動いています。nginxなどのコンフィグの設定追加等もやってくれるので楽です。スクリプトの中身を[こちら](https://github.com/laravel/homestead/blob/master/scripts/serve-laravel.sh)です。

# まとめ

localと仮想環境のフォルダ共有など最初から組み込まれており、新サイトの追加が簡単に出来るサポートスクリプト（nginxをいじらなくておｋ）も用意されており、至れり尽くせりな感があります。

これを使って開発すると大分楽が出来そうで、Laravel/homesteadすげぇなと思いました。

ただし、本番を見据えて開発する場合、ローカルも開発環境もステージング環境も本番環境も出来る限り同じ構成にしたほうが良いという話があり、本番がhomesteadと全く同じ構成で無い場合、使いづらいとおもいます。（本番のOSがCentOSを使用など）

作りっぱなしにせずに開発が続くWebアプリケーションなら、これを機にUbuntu-Serverに合わせるのも手ですかね？作りっぱなしのアプリケーションの場合、CentOSのほうがパッチも作成してくれてサポートも長いので、合っているとは思いますが。。。
Postfixの設定メモ


以下のファイル編集
/etc/postfix/main.cf

postfix リスタート
systemctl restart postfix

わかりやすい
http://www.tmtm.org/postfix/tutorial/config.html


細かい説明
http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html

以下の設定で自分ところからしか発信しない

```main.fc:main.fc
inet_interfaces = loopback-only
```

Linuxユーザにいないユーザーでメールを送りたい
http://tech.ckme.co.jp/mailv.shtml


次のエラーが起きたら

```maillog:maillog
open database /etc/postfix/virtual.db: No such file or directory
```

ユーザを変換してないので以下のコマンド

```shell-session
postmap hash:/etc/postfix/virtual
postfix reload
```
ng-mtg#8 Angular勉強会参加レポ


9/9 参加したので勝手にまとめます。


# 時間のない人向け
+ SIは闇
+ 英語は大切

# 概要

URL：http://ngjapan.connpass.com/event/39173/
twitterまとめ：http://togetter.com/li/1022442

## はじめてのAngular2 @can_i_do_web
  - __触る分には問題ない、プロダクトに使うのはまだ待ったほうがいい__
     + Angular Connectが今月末にあるのでそこで発表したいんじゃないかな？という予想
  - [(ngModel)]=  とかは、公式ではbanana in Buttonと呼ばれてる
  - (VSCode使ってた)
  - 可能であればone wayで作ったほうがパフォーマンスが良い
  - Buitlin-Directive, angular1と比較して少ない
     + Ngif, NgFor, NgStyle, NgSwitch, NgPlural(1.4からある)
  - Angular2のキモは、Component間の親子関係を作るところ
     + 子供の変更は親に伝わらない
  - Typescript以外で書くのは大変, webpack, Rx.js
  - html5 confの@lacoのスライドを参考にしよう
     + http://slides.com/laco/first-step-to-angular-land#/
  - __angular/angular-ja 日本語化してみよう！__
     + https://github.com/angular/angular-ja
     + slackとかで喋ってもいいのよ

## SIだけどAngularやってます @くっすう
  - ほぼAngular関係のない話ですが普通におもしろいのでまとめ読むことをおすすめします
  - Angular1のきっかけとその苦悩
     + 自分の武器になる
  - この分野で戦うためには
     + 信頼できるメンバー
     + 上司が技術に明るい、技術に関して一任できる人
     + 学び続ける心

## 超絶初心者の自分が１ヶ月Angular2をやってみて新境地に達した話 @o0122_masahiro
  - phpができるんならAngular2もできるよ！と上司から
  - 初心者がangularを見てすごいと思ったこと
     + ルーティング
     + バインディング
     + security

## エンジニアよ、大志を抱け！マイクロソフトの夢とビジネスを育てる施策 DreamSpark と BizSpark
  - 会場がMSなのでCM枠
  - Bizspark
     + 起業5年以内, オリジナルドメインのURL
     + かなりの無料枠がある
  - 学生向けにも同様の物がある

## 僕はどうしてAngular2をテーマに登壇することになってしまったのか @ovrmrw
  - 英語読もう
    + Angular2の情報はほぼ英語
  - 翻訳記事を待っているのでは遅い
     + __英語ができると世界が広がる。__
     + 情報の広がりは英語が圧倒的に早い
         - 日本語で：1h
         - 英語で調べる：1min
     + Toeic 860くらいあると潰しが効くそうです
  - google検索の期間指定
  - なぜ登壇しているのか＝英語がそこそこ読めたから
     + 恐れずに糞コードでも何でもGithubへpush
     + __人の縁、人に恵まれた__
         - きっかけは英語力
  - Angular2をやるなら避けて通れない
     + TypeScript
     + __Rx.js__
         - angular2の基本になっている
         - 使いこなせると病み付きになる
     + zone.js
         - 気にしなくても良さそうだけと、Angular2の根本にあるのでヤバイ
         - setTimeoutとか、時間系のはパッチがあたっているのでテストとかangular2専用のじゃないとバグる



今回はAngularについての話は少ない感じ。次回はAngular Connectの内容を受けてになるので内容が濃くなる予定とのこと。

内容的にはどちらかと言うと初心者向けになっていたが、最後の@ovrmrwさんの発表の「英語の大切さ」は一読の価値があると思います。
slim触った

slimでbinding.pryを使うときは先頭に入れる
まとめ

```erb
<% if @blog.present? %>
  <h1>やったー</h1>
<% end %>
```

これを書くのは非常にめんどい  
slimなら

```slim
- if @blog.present?
  h1 やった-  
```  

これだけでできた。
binding.pry使うときは先頭にいれないと動かないっぽい。
uwsgiでのgraceful reloadについて

uwsgiのgraceful reload(hot reload)について日本語で解りやすくまとまっている記事が無かったのでまとめてみようと思いました。

# graceful reloadについて
既に稼働しているアプリケーションサーバを更新する際に、既に接続しているクライアントが切断されないようにreloadを行うための技術です。v1からv2の状態へと移行するためにreloadした場合v1のworkerを保持しつつv２のworkerを立ち上げてv1の接続がなくなったら順次そのworkerを切って行き、接続を切断せずに移行して行くような方法があります。

# 参考ドキュメントと動画
#### ○ The Art of Graceful Reloading
http://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html

#### ○ [動画] pycon jp 2015 uWSGI/Dockerを利用したWebサービス運用事例
https://www.youtube.com/watch?v=zsoqAf-c3_s

# graceful reloadの種類
今回はuwsgiのtouche-reload系のoptionを追加して実行するだけで対応出来る3種類の方法を紹介したいと思います。
他にも上記の記事や動画では紹介していますが、uwsgiのoption以外にも構成を変えたりしないといけなかったりしたので、とりあえず簡単なものだけ説明させて頂きたいと思います。

* Standard graceful reload
* Workers reloading
* Chain reloading

# Standard graceful reload
[^※]workers/processesへの接続が全てがなくなったのを確認してuwsgiを再起動する手法です。
reloadに時間がかかるのとその待機中にタイムアウトしてしまうユーザが発生する可能性があります。

`--touch-reload`オプションを利用するとStandard graceful reloadでリロードされます。

``` 起動例.
$ uwsgi --touch-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger
```

# Workers reloading
[^※]worker/processeのみ再起動します。
全体の再起動を行わないため、速度があがりますがコードの更新しか反映されません。
また、preforkには使えません。

`--touch-workers-reload`オプションを利用するとWorkers reloadingでリロードされます。

``` example.
$ uwsgi --touch-workers-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger
```


# Chain reloading
[^※]worker/processeを1つずつ再起動します。「Workers reloading」の改良版です。
順次更新して行く形なのでクライアント側の待ち時間が少ないです。
また、処理が分散されるのでリロード時の負荷が少ないです。

`--touch-chain-reload`オプションを利用するとChain reloadingでリロードされます。

``` example.
$ uwsgi --touch-chain-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger
```


# まとめ
uwsgiのgraceful reloadには複数の技術があることが解りました。
各手法には長所短所があるため、自分たちのサービスにあった方法を使う事が大切かと思います。




[^※]: この記事の中でworker/processeという表記をしておりますが、uwsgiの中でworkerもprocesseもどちらも同義なため、このような表記をしています。http://uwsgi-docs.readthedocs.io/en/latest/Options.html 内の各workersとprocessesのhelp文言が同じです。
新卒2年目SEの備忘録[SQLServer 関数フォーマット +α まとめてみた]

#いちいち調べるのが面倒くさい・・
最近、SQLServerでのクエリ開発を行っていますが
毎回ちょっとした関数のフォーマットを調べるのが面倒でなりません！
そこで、自分がよく使う関数フォーマットを備忘録的にまとめた記事を作成しました。

#SQLServerの関数フォーマット
####1.文字列切り取り
　・LEFT(切り取りたい文字列, "左"から何文字分切り取るか)
　　例：LEFT('12345', 2)⇒'12'
　・RIGHT(切り取りたい文字列, "右"から何文字分切り取るか)
　　例：RIGHT('12345', 2)⇒'45'
　・SUBSTRING(切り取りたい文字列, 切り取り開始位置, "開始位置"から何文字分切り取るか)
　　例：SUBSTRING('SUBSTRING', 4, 6)⇒'STRING'

####2.日時取得
　・GETDATE()
　　例：GETDATE()⇒2016-01-30 10:30:30.300
　・YEAR(取得対象)
　　例：YEAR(GETDATE())⇒2016
　・MONTH()
　　例：MONTH(GETDATE())⇒1
　　　　※01ではない事に注意。
　・DAY()
　　例：DAY(GETDATE())⇒30
　・DATEDIFF(日時差の計算基準, 日時1, 日時2)
　　例：DATEDIFF(d, '2016/01/01', '2016/01/05')⇒4
　　　　※dは午前0時を迎える度に、カウントが増加する。
　　　　⇒[d以外の基準](http://www.office-kitami.com/lesson/afunction/datediff.html)
　・DATEADD(増減箇所, 増減値, 増減対象)
　　例：DATEADD(mm, 1, CONVERT(date, '2016/01/05'))⇒2016/02/05
　　　　※DATEADDは、増減対象が日付型の場合のみ使用可能な事に注意。

####3.型変換※[]は、指定なし可能
　・CONVERT(変換後の型, 変換対象, [フォーマット])
　　例：CONVERT(date, '2016/01/01(※varchar型)')⇒2016/01/30(※date型)
　<補足①>
　 変換後の型の種類(代表的な一部)
　 　数値：int, decimal, float
　　 日時：date, time, datetime
　　 文字列：varchar
　<補足②>
　 日時⇒文字列変換時のフォーマット
　 ★CONVERT(VARCHAR, GetDate())　　　⇒　01 30 2016 10:30PM
　 ★CONVERT(VARCHAR, GetDate(), 101)　⇒　02/11/2007
　 ★CONVERT(VARCHAR, GetDate(), 102)　⇒　2007.02.11
　 ★CONVERT(VARCHAR, GetDate(), 103)　⇒　11/02/2007
　 ★CONVERT(VARCHAR, GetDate(), 111)　⇒　2007/02/11
　 ★CONVERT(VARCHAR, GetDate(), 120)　⇒　2007-02-11 12:34:56
　 ※[その他のフォーマット](http://orangebox.lbn.bz/index.php?SQL%20Server%A4%C7%C6%FC%C9%D5%A4%CE%A5%D5%A5%A9%A1%BC%A5%DE%A5%C3%A5%C8)

以下、追記。（2016/12/13）
#関数を使ってクエリを書いていく中で・・(+α：チューニング)
これまでは、想定通りのデータを抽出することに注力してきましたが
処理の遅さが気になってきたこの頃です。
そこで初めて、"チューニング=処理を早くするクエリの記述方法"を先輩から教わりました。
こちらも、備忘録がてらにまとめておこうと思います。

チューニングを行う中で、[インデックス](http://www.techscore.com/tech/sql/15_01.html/)(見出し)という考え方が重要になってきます。
ここでは、インデックスについての説明は割愛します。※詳しくは上記リンクにて。

・SELECT句では、必要以外に*を使わない
　⇒単純にカラム数が増えるため、検索速度が低下
・WHERE句の左辺側では、カラムに対して処理を行わない
　⇒インデックスが無効となり、検索速度が低下
・<>条件を複数指定したい場合は、NOT INで代用する
　⇒複数指定すると、走査も複数回になるため、検索速度が低下
・テーブル名に別名をつける
　⇒「短い」別名をつけることにより、単純にソース文字数が減り処理速度が向上
・UNIONとUNION ALLの使い分け
　⇒UNIONを多用しすぎると、重複行の削除に時間がかかってしまい、処理速度が低下
「オフラインリアルタイムどう書く第7回(のんびり座りたい)」の問題を解いてみた


[横浜へなちょこプログラミング勉強会](https://yhpg.doorkeeper.jp/)にて過去に出題された[のんびり座りたい](http://nabetani.sakura.ne.jp/hena/ord7selectchair/)を解いてみた。
回答にかかった時間は2,30分程度。

`Bench#sit_down`の判定部分は初め`if`文で書いていたが、無駄に`case`に書き換えてしまったので時間がかかった。

```ruby
class BenchRule
  def initialize input
    n, @rule = input.split(":")
    @bench = Bench.new n.to_i
  end

  def start
    @rule.each_char{|r|
      case r
      when r.upcase   then @bench.sit_down r
      when r.downcase then @bench.stand_up r.upcase
      end
    }
    @bench.to_s
  end
end

class Bench
  def initialize n
    @bench = Array.new(n){nil}
  end

  def sit_down name
    i = case @bench.map{|b| b.nil? ? 0 : 1}.join
        # 両方空いている場合
        when /(^00|000|00$)/     then $~.begin(0) + ($~.begin(0).zero? ? 0 : 1)
        # 片方空いている場合
        when /(^01|10$|100|001)/ then $~.begin(0) + (($~.begin(0).zero? and $1[0] == "0") ? 0 : 1)
        # 両側に座っている場合
        when /(0)/               then $~.begin(0)
        # 全て埋まっている場合
        # XXX: 「空席がない状態で人が来ることを考慮する必要はない」とあるが念のため
        else                          nil
        end
    @bench[i] = name unless i.nil?
  end

  def stand_up name
    if index = @bench.index(name)
      @bench[index] = nil
    end
  end

  def to_s
    @bench.map{|b| b.nil? ? "-" : b}.join
  end
end

test = <<_TEST
/*1*/ test( "6:NABEbBZn", "-ZAB-E" );
/*2*/ test( "1:A", "A" );
/*3*/ test( "1:Aa", "-" );
/*4*/ test( "2:AB", "AB" );
/*5*/ test( "2:AaB", "B-" );
/*6*/ test( "2:AZa", "-Z" );
/*7*/ test( "2:AZz", "A-" );
/*8*/ test( "3:ABC", "ACB" );
/*9*/ test( "3:ABCa", "-CB" );
/*10*/ test( "4:ABCD", "ADBC" );
/*11*/ test( "4:ABCbBD", "ABDC" );
/*12*/ test( "4:ABCDabcA", "-D-A" );
/*13*/ test( "5:NEXUS", "NUESX" );
/*14*/ test( "5:ZYQMyqY", "ZM-Y-" );
/*15*/ test( "5:ABCDbdXYc", "AYX--" );
/*16*/ test( "6:FUTSAL", "FAULTS" );
/*17*/ test( "6:ABCDEbcBC", "AECB-D" );
/*18*/ test( "7:FMTOWNS", "FWMNTSO" );
/*19*/ test( "7:ABCDEFGabcdfXYZ", "YE-X-GZ" );
/*20*/ test( "10:ABCDEFGHIJ", "AGBHCIDJEF" );
_TEST

require 'minitest/autorun'

describe 'Bench' do
  test.split("\n").each do |line|
    t, n, input, expect = line.match(/^\/\*(\d+)\*\/\s*test\(\s*"([^"]+)",\s*"([^"]+)"\s*\);$/).to_a
    rule = BenchRule.new input
    it input do
      assert_equal expect, rule.start
    end
  end
end
```
ホームボタン押下時に処理を止める


##はじめに
ホームボタンを押した時に処理を止めたいとか、ポーズメニューを表示したい場合があります。
音楽を使ったゲームや連続性のあるゲームでよくあるのではないでしょうか。

##ホームボタン押下時に呼ばれるメソッド
まずホームボタンを押した時(厳密にはアプリを閉じそうな時)に呼ばれるメソッドはAppDelegate.swift内の 
applicationWillResignActiveメソッドです。
ちなみに、ホームボタンを2回連続で押した時(メモリ解放の画面になるやつです)や、電話が掛かってきた時もこちらのメソッドが呼ばれます。

```swift:AppDelegate.swift
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    //アプリを閉じそうな時に呼ばれる
    func applicationWillResignActive(application: UIApplication) {
        //ポーズの処理を行う
    }
}
```

その中にコードを書けば良いのですが、すでに別のクラスでポーズメニューの処理を書いていたりしたので、NSNotificationCenterクラスを使ってみました。これが結構便利です

NSNotificationCenterクラスは通知という仕組みを使って、あるイベントが発生した時に別クラスでそのイベントを拾うことができます。

##通知の追加
例えばPauseGameSceneという名前の通知をapplicationWillResignActiveメソッド内に作ります。
`NSNotificationCenter.defaultCenter().postNotificationName("PauseGameScene", object: self)`


```swift:AppDelegate.swift
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func applicationWillResignActive(application: UIApplication) {
       NSNotificationCenter.defaultCenter().postNotificationName("PauseGameScene", object: self)
    }
}
```





##オブザーバーの追加
次は別のクラスで通知を受け取る役割を担うオブザーバーというものを追加します。例ではGameViewControllerクラスを使っています。

```swift:GameViewController.swift

import SpriteKit

class GameViewController: UIViewController{
    
    var gameScene: GameScene!

    override func viewDidLoad() {
        //...省略
        NSNotificationCenter.defaultCenter().addObserver(self, selector: #selector(pause), name: "PauseGameScene", object: nil)
    }

    func pause() {
        //ここでポーズの処理やポーズメニューを表示
        //例えばこんな感じの処理
        self.gameScene.view!.paused = true
    }

    deinit{
        //削除
        NSNotificationCenter.defaultCenter().removeObserver(self)
    }
}
```
addObserverのselectorには実行したいメソッド名(ここでは`pause`)、nameには作っておいた通知の名前(ここでは`PauseGameScene`)を入れます。


後は指定したメソッド内で、ポーズの処理を書くだけです。

最後にdeinit内でオブザーバーを削除した方がいいのかな?
RESTful APIのレスポンスデータ設計

APIを利用する側にレスポンスとしてどのようなデータを返却するかを検討する。

# レスポンスデータを設計する上での考え方
APIのレスポンスデータはほとんどの場合プログラムで処理される。また、HTTP経由でAPIが呼ばれるため、HTTPのオーバーヘッドも発生する。そのため、

* できる限りプログラムで処理しやすいレスポンスデータ
* APIへのアクセス回数は極力最小限に

を念頭に検討する必要がある。

# レスポンスデータのフォーマットを検討する
JSON、XML等のフォーマットを検討する。昔はXML形式が多かったが最近はJSON形式が主流。以下はGoogleトレンドの検索結果(赤は「xml api」、青は「json api」)。
![1.png](https://qiita-image-store.s3.amazonaws.com/0/23101/289d1505-6e33-7c64-0281-4c0eb6942701.png)
また、主要なWebサービスはJSONを基本としていて、サービスによってはXMLもサポートしている。つまり世のWeb APIはJSONがデファクトスタンダードとなっている模様。なので、深く検討せずJSONで決めてしまい、需要があればXMLもサポートするという形が好ましいと思う。なお、なぜXMLではなくJSONなのかというのは、[JSONに押されるXMLの存在](http://www.publickey1.jp/blog/10/jsonxml.html)にも記載があるが、簡潔にまとめると以下の通り(「XMLが悪い」と否定しているわけではなく、JSONのほうがマッチしているということ)。

* JSONのほうがシンプル
* JSONのほうがJavaScriptとの相性が良い

# レスポンスデータを検討する

実際にどんなデータを返すかを検討する。その際の考え方として、冒頭でも記載した通り「APIへのアクセス回数は極力最小限に」ということを念頭に検討する。そのためにも[RESTful APIのリソース設計#何をリソースとするか](http://qiita.com/NagaokaKenichi/items/ef23ca15ba0e9e5ee022#1-%E4%BD%95%E3%82%92%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%A8%E3%81%99%E3%82%8B%E3%81%8B)でも記載した通り、APIのユースケースを明確化しておく必要がある。例えば、本の情報を返すAPIがあった場合、以下のようなレスポンスデータ(idのみ)を返すとする。

```
{
    "books": [
        00001,
        00002,
        00003,
        00004,
        00005
     ]
}
```

本のidだけ返却しても、APIを利用する側からするとほとんどの場合あまり意味はない。APIを利用する側のユースケースとしては、「本の情報を一覧表示する」というケースが考えられるので、最低限idの他にも本の名前、本の詳細を記載したページのURL(もちろん詳細のURLではなく出版社、出版日等の詳細情報を直接返却してもよい)も必要としていることが考えられる。そのため、以下のようにすることで一度のAPI呼び出しで必要な情報が全て取得できるので、APIのアクセス回数を少なくさせることができる。

```
{
    "books": [
        {
            "id": 00001,
            "name": "本の名前1",
            "url": "http://example.com/books/00001"
        },
        {
            "id": 00002,
            "name": "本の名前2",
            "url": "http://example.com/books/00002"
        },
        {
            "id": 00003,
            "name": "本の名前3",
            "url": "http://example.com/books/00003"
        }
     ]
}
```

# 各項目の項目名のデータ型の定義
[RESTful APIのリソース設計#リソースの各項目のデータ型の定義](http://qiita.com/NagaokaKenichi/items/ef23ca15ba0e9e5ee022#4-%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E5%90%84%E9%A0%85%E7%9B%AE%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E5%9E%8B%E3%81%AE%E5%AE%9A%E7%BE%A9)にも記載した通り、レスポンスデータの各項目のデータ型や項目名を検討する。データモデル設計でやっても問題ないと思うが、どちらかというとリソース設計の段階で検討するべき内容だと思う。なお、項目名を命名する際の注意点としては以下のようなものがある。

* 多くのAPIで同じ意味に利用されている一般的な単語を用いる
* なるべく少ない単語数で表現する
* 変な省略形は極力利用しない
* 複数の単語を連結する場合、その連結方法はAPI全体を通して統一する
* 単数形／複数形に気をつける

# エラー発生時のレスポンスデータの検討
[RESTful APIのエラー設計](http://qiita.com/NagaokaKenichi/items/20825ae9256d9f4c6f35)で別途まとめた通り。

# 参考
[RESTful Webサービス](https://www.oreilly.co.jp/books/9784873113531/)
[Web API: The Good Parts](https://www.oreilly.co.jp/books/9784873116860/)
Quantum Chemistry - Postulates of Quantum Mechanics 4: Expectation Values

関連 http://qiita.com/7of9/items/d3a1799928734375f34f

CG分野で使われるSpherical Harmonics。自分の数値シミュレーション計算に用いたいと思い調べると、量子化学の講義にたどり着く。

短く分かりやすそうな159本のビデオを少しずつ消化中。

Quantum Chemistry - Postulates of Quantum Mechanics 4: Expectation Values
https://www.youtube.com/watch?v=0H7xbGGBMGc&list=PLm8ZSArAXicL3jKr_0nHHs5TwfhdkMFhh&index=27

- 量子力学での4つ目のPostulates 
- Postulates とは何か?
  - [このビデオから](https://www.youtube.com/watch?v=ppvk2hSYcG4&index=24&list=PLm8ZSArAXicL3jKr_0nHHs5TwfhdkMFhh)
     - trueとして証明されていない
     - trueとして考えられている(given)
     - predictionの妥当性を見てチェックされる
- 白文字
  - 系がwave functionプサイで記述されるとき、Aのaverage valueは緑の式で表される
- 緑の式
  - 分母: 複素共役プサイ*と、プサイの積の積分
     - 複素共役: v = a + bi の複素共役は v* = a - bi
  - 分子: 複素共役プサイ*と、プサイにオペレータAが作用したものの積の積分
- 紫の式
  - プサイ*とプサイの積は「粒子がその位置に存在する確率」
  - あらゆる空間で積分した時、存在する確率は100%
  - normalizedの場合、係数を消すようにして1となる
- ピンクの式
  - 紫の式から、緑の式において分母が1となるので
  - Aのaverage valueの式はこのようになる
- 黄色の式
  - プサイnにオペレータAハットが作用したものが、プサイnに係数a_nがかかったものとなるとき
  - プサイnは固有関数である
  - この式は水色の式の解釈に使う
- 水色の式
  - もしプサイがプサイiの時
  - average value Aの式はピンクの式の定義からこのようになる
  - 式においてプサイiにAハットが作用している部分は、黄色の式を用いて変形すると
  - a_i * プサイn となる
  - a_iは係数なので積分の外に出て、積分の中はプサイ*とプサイの積となる
  - 紫の式から、プサイ*とプサイの積の積分は1となる (オレンジの取り消し線)
  - 結果として、average value of Aは係数 a_i となる
- 右上の緑
  - プサイ=プサイiの時、average value of Aはa_i
  - 同じように左下の水色の式で2回Aハットを作用させた時は
  - average value of (A squared)はa_iの二乗となる
- 右側の紫の式
  - (補足) シグマaと書いているが(シグマa)二乗の間違い
  - その式は[こちらのビデオ](https://www.youtube.com/watch?v=sCeUFzxowuQ&list=PLm8ZSArAXicL3jKr_0nHHs5TwfhdkMFhh&index=20)の右側中段の紫の式で(シグマa)二乗 = x二乗の平均 * xの平均の二乗 と記載
  - (シグマa)二乗=0なので、(シグマa)=0となり答えは同じではあるが
[JAWS-UG CLI] SES:#7 Incoming用ルールセットの削除




前提条件
========


SESへの権限
-----------

SESに対してフル権限があること。


AWS CLI
-------

以下のバージョンで動作確認済

* AWS CLI 1.10.63

```bash:コマンド:
aws --version
```

```text:結果(例):
      aws-cli/1.10.63 Python/2.7.11 Darwin/15.6.0 botocore/1.4.53
```

バージョンが古い場合は最新版に更新しましょう。

```bash:コマンド:
sudo -H pip install -U awscli
```


0. 準備
=======


0.1. リージョンの決定
---------------------

```bash:変数の設定
export AWS_DEFAULT_REGION='us-west-2'
```


0.2. 変数の確認
---------------

プロファイルが想定のものになっていることを確認します。

```bash:変数の確認:
aws configure list
```

```text:結果(例):
            Name                    Value             Type    Location
            ----                    -----             ----    --------
         profile       sesFull-prjz-mbp13        env    AWS_DEFAULT_PROFILE
      access_key     ****************XXXX shared-credentials-file
      secret_key     ****************XXXX shared-credentials-file
          region        us-west-2        env    AWS_DEFAULT_REGION
```


0.3. ルールセット名の指定
-------------------------

```bash:変数の設定:
SES_RULE_SET_NAME='default-rule-set'
```


1. 事前作業
===========

削除する前にかならず、削除対象の確認をしてください。

```bash:コマンド:
aws ses describe-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```json:結果(例):
      {
        "Rules": [],
        "Metadata": {
          "CreatedTimestamp": "2016-09-10T01:23:45.678Z",
          "Name": "default-rule-set"
        }
      }
```


2. ルールセットの削除
=====================

```bash:変数の確認:
cat << ETX

        SES_RULE_SET_NAME: ${SES_RULE_SET_NAME}

ETX
```

```bash:コマンド:
aws ses delete-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```text:結果(例):
      (戻り値なし)
```


3. 事後確認
===========

```bash:コマンド:
aws ses describe-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```text:結果(例):
      An error occurred (RuleSetDoesNotExist) when calling the DescribeReceiptRuleSet operation: Rule set does not exist: default-rule-set
```


完了
====
[JAWS-UG CLI] SES:#6 Incoming用ルールの削除



前提条件
========


SESへの権限
-----------

SESに対してフル権限があること。


AWS CLI
-------

以下のバージョンで動作確認済

* AWS CLI 1.10.63

```bash:コマンド:
aws --version
```

```text:結果(例):
      aws-cli/1.10.63 Python/2.7.11 Darwin/15.6.0 botocore/1.4.53
```

バージョンが古い場合は最新版に更新しましょう。

```bash:コマンド:
sudo -H pip install -U awscli
```


0. 準備
=======


0.1. リージョンの決定
---------------------

```bash:変数の設定
export AWS_DEFAULT_REGION='us-west-2'
```


0.2. 変数の確認
---------------

プロファイルが想定のものになっていることを確認します。

```bash:変数の確認:
aws configure list
```

```text:結果(例):
            Name                    Value             Type    Location
            ----                    -----             ----    --------
         profile       sesFull-prjz-mbp13        env    AWS_DEFAULT_PROFILE
      access_key     ****************XXXX shared-credentials-file
      secret_key     ****************XXXX shared-credentials-file
          region        us-west-2        env    AWS_DEFAULT_REGION
```


0.3. ルールセット名の指定
-------------------------

```bash:変数の設定:
SES_RULE_SET_NAME=' SES_RULE_SET_NAME|'
```


0.4. ルール名の指定
-------------------

```bash:変数の設定:
SES_RULE_NAME='rule-inbound-spam-filter-20160912'
```


1. 事前作業
===========

削除する前にかならず、削除対象の確認をしてください。

```bash:コマンド:
aws ses describe-receipt-rule \
        --rule-set-name ${SES_RULE_SET_NAME} \
        --rule-name ${SES_RULE_NAME}
```

```json:結果(例):
      {
        "Rule": {
          "Name": "rule-inbound-spam-filter-20160912",
          "Recipients": [
              "spa@example.jp"
          ],
          "Enabled": true,
          "ScanEnabled": true,
          "Actions": [
              {
                  "LambdaAction": {
                      "InvocationType": "RequestResponse",
                      "FunctionArn": "arn:aws:lambda:us-west-2:XXXXXXXXXXXX:function:inbound-ses-spam-filter-python-20160912"
                  }
              }
          ],
          "TlsPolicy": "Optional"
        }
      }
```


2. ルールの削除
===============

```bash:変数の確認:
cat << ETX

        SES_RULE_SET_NAME: ${SES_RULE_SET_NAME}
        SES_RULE_NAME:     ${SES_RULE_NAME}

ETX
```

```bash:コマンド:
aws ses delete-receipt-rule \
        --rule-set-name ${SES_RULE_SET_NAME} \
        --rule-name ${SES_RULE_NAME}
```

```text:結果(例):
      (戻り値なし)
```


3. 事後作業
===========

```bash:コマンド:
aws ses describe-receipt-rule \
        --rule-set-name ${SES_RULE_SET_NAME} \
        --rule-name ${SES_RULE_NAME}
```

```text:結果(例):
      An error occurred (RuleDoesNotExist) when calling the DescribeReceiptRule operation: Rule does not exist: rule-inbound-spam-filter-20160912
```


完了
====
[JAWS-UG CLI] SES:#5 Incoming用ルールセットの無効化



前提条件
========


SESへの権限
-----------

SESに対してフル権限があること。


AWS CLI
-------

以下のバージョンで動作確認済

* AWS CLI 1.10.63

```bash:コマンド:
aws --version
```

```text:結果(例):
      aws-cli/1.10.63 Python/2.7.11 Darwin/15.6.0 botocore/1.4.53
```

バージョンが古い場合は最新版に更新しましょう。

```bash:コマンド:
sudo -H pip install -U awscli
```


0. 準備
=======


0.1. リージョンの決定
---------------------

```bash:変数の設定
export AWS_DEFAULT_REGION='us-west-2'
```


0.2. 変数の確認
---------------

プロファイルが想定のものになっていることを確認します。

```bash:変数の確認:
aws configure list
```

```text:結果(例):
            Name                    Value             Type    Location
            ----                    -----             ----    --------
         profile       sesFull-prjz-mbp13        env    AWS_DEFAULT_PROFILE
      access_key     ****************XXXX shared-credentials-file
      secret_key     ****************XXXX shared-credentials-file
          region        us-west-2        env    AWS_DEFAULT_REGION
```


0.3. ルールセット名の指定
-------------------------

```bash:変数の設定:
SES_RULE_SET_NAME='default-rule-set'
```


1. 事前作業
===========

```bash:コマンド:
aws ses describe-active-receipt-rule-set 
```

```json:結果(例):
      {
        "Rules": [
          {
              "Name": "rule-inbound-spam-filter-20160912",
              "Recipients": [
                  "spa@example.jp"
              ],
              "Enabled": true,
              "ScanEnabled": true,
              "Actions": [
                  {
                      "LambdaAction": {
                          "InvocationType": "RequestResponse",
                          "FunctionArn": "arn:aws:lambda:us-west-2:XXXXXXXXXXXX:function:inbound-ses-spam-filter-python-20160912"
                      }
                  }
              ],
              "TlsPolicy": "Optional"
          }
        ],
        "Metadata": {
          "CreatedTimestamp": "2016-09-10T01:23:45.678",
          "Name": "default-rule-set"
        }
      }
```


2. ルールセットの停止
=====================

```bash:コマンド:
aws ses set-active-receipt-rule-set 
```

```text:結果(例):
      (戻り値なし)
```


3. 事後確認
===========

```bash:コマンド:
aws ses describe-active-receipt-rule-set 
```

```text:結果(例):
      (戻り値なし)
```


完了
====
[JAWS-UG CLI] SES:#2 Incoming用ルールセットの追加



前提条件
========


SESへの権限
-----------

SESに対してフル権限があること。


AWS CLI
-------

以下のバージョンで動作確認済

* AWS CLI 1.10.63

```bash:コマンド:
aws --version
```

```text:結果(例):
      aws-cli/1.10.63 Python/2.7.11 Darwin/15.6.0 botocore/1.4.53
```

バージョンが古い場合は最新版に更新しましょう。

```bash:コマンド:
sudo -H pip install -U awscli
```


0. 準備
=======


0.1. リージョンの決定
---------------------

```bash:変数の設定:
export AWS_DEFAULT_REGION='us-west-2'
```


0.2. 変数の確認
---------------

プロファイルが想定のものになっていることを確認します。

```bash:変数の確認:
aws configure list
```

```text:結果(例):
            Name                    Value             Type    Location
            ----                    -----             ----    --------
         profile       lambdaFull-prjz-mbp13        env    AWS_DEFAULT_PROFILE
      access_key     ****************XXXX shared-credentials-file
      secret_key     ****************XXXX shared-credentials-file
          region        us-west-2        env    AWS_DEFAULT_REGION
```


1. 事前作業
===========


ルールセット名の決定
--------------------

```bash:変数の設定:
SES_RULE_SET_NAME='default-rule-set'
```

同名のルールセットが存在しないことを確認します。

```bash:コマンド:
aws ses describe-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```text:結果(例):
      An error occurred (RuleSetDoesNotExist) when calling the DescribeReceiptRuleSet operation: Rule set does not exist: default-rule-set
```


2. ルールセットの作成
=====================

```bash:コマンド:
aws ses create-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```text:結果(例):
      (戻り値なし)
```


3. 事後作業
===========

```bash:コマンド:
aws ses describe-receipt-rule-set \
        --rule-set-name ${SES_RULE_SET_NAME}
```

```json:結果(例):
      {
        "Rules": [],
        "Metadata": {
          "CreatedTimestamp": "2016-09-10T01:23:45.678Z",
          "Name": "default-rule-set"
        }
      }
```


完了
====
Quantum Chemistry - Postulates of Quantum Mechanics 3: Measurement

関連 http://qiita.com/7of9/items/d3a1799928734375f34f

CG分野で使われるSpherical Harmonics。自分の数値シミュレーション計算に用いたいと思い調べると、量子化学の講義にたどり着く。

短く分かりやすそうな159本のビデオを少しずつ消化中。

Quantum Chemistry - Postulates of Quantum Mechanics 3: Measurement
https://www.youtube.com/watch?v=hLgEO4WlfzU&list=PLm8ZSArAXicL3jKr_0nHHs5TwfhdkMFhh&index=26

- 量子力学での3つ目のPostulates 
- Postulates とは何か?
  - [このビデオから](https://www.youtube.com/watch?v=ppvk2hSYcG4&index=24&list=PLm8ZSArAXicL3jKr_0nHHs5TwfhdkMFhh)
     - trueとして証明されていない
     - trueとして考えられている(given)
     - predictionの妥当性を見てチェックされる
- 白文字
  - 観測可能なAのあらゆる観測は、オペレータAの固有値しか生じない
- 緑
  - 固有関数と固有値の式
      - 関数プサイnに対するオペレータA(Aハット)の作用は
      - プサイnに係数a_nがかかった値を生む
         - a_nは実数 (Rの太字 @ 工学における特殊関数 p10)
- 紫
  - 固有関数
- ピンク
  - 固有値
- 黄色
  - 白色の状況での観測では測定できるaはすべてa_nに属する
- 水色
  - プサイがプサイ_iの時、a_iのみ測定できる
- オレンジ
  - プサイがプサイ_iに係数c_iがかかった値の総和である時、
     - a_iを測定でき、
     - 条件としては、「c_iは0とならない」
  - この式は後のビデオでsuperposition principleにて出てくる
     - superposition principle: 重ね合わせの原理