OmniAICreator/Qiita-1.07M huggingface dataset:
アジャイル開発(初めてのSCRUM)

#アジャイル開発

##scrumとは
　アジャイル開発の手法のひとつ。
　プロダクトを作るために、全員が一丸となって行うべき**作業**・**会議**・**成果物**

##■成果物の用語説明
  成果物１　プロダクトバックログ
　　・実現したい要求を「リスト」にして並び変える。
　　・常にメンテナンスして最新に保つ。

  成果物２　スプリントバックログ
　　・プロダクトバックログを具体的なタスクに分割する。
　　・タスクは後から増えることもある

　成果物３　リリース判断可能なプロダクト
　　・開発チームは「リリース判断可能」なプロダクトをつくる

##■ロールの用語説明
　ロール１　プロダクトオーナー
　　・プロダクトの責任をとる
　　・プロダクトバックログの管理
　　・開発チームに相談できるが干渉はできない

　ロール２　開発チーム
　　・リリース判断可能なプロダクトを作る
　　・3人～9人で構成する
　　・全員そろえばプロダクトをつくれる
　　・上下関係はない

　ロール３　スクラムマスター
　　・このプロセスがうまくまわるようにする。
　　・妨害を排除する。
　　・支援と奉仕をする。
　　・教育、ファシリテート、コーチ、推進役。

##■会議体の用語説明
　会議体１　スプリント計画ミーティング
　　・スプリントで開発をするためには計画が必要
　　・第１部　プロダクトオーナーは何を欲しいか？
　　・第１部　開発チームはどれくらいできそうか。　　　
　　・第２部　開発チームはどうやってそれを実現するか。

　会議体２　デイリースクラム
　　・開発チームの状態を毎日確認する。

　会議体３　スプリントレビュー
　　・開発チームの成果物をプロダクトオーナーが確認する。

　会議体４　スプリントレトロスペクティブ（振り返り）
　　・プロセスやツールなどの観点で今回のスプリントを検査する。
　　・うまくいったこと、今後改善すべき点を整理する。
　　・今後のアクションプランをつくる。

#SCRUM導入手順
- ユーザストーリーの決定
- プロダクトオーナーの決定
- スクラムマスターの決定
- 開発チームの決定
- プロダクトバックログの作成
- スプリント期間の決定
- スプリント計画の準備
- プロダクトバックログの優先順位決定
- プロダクトバックログのアイテム見積もり
- スプリント計画
- スプリント実施
- スプリントレビュー
- 振り返り


＝＝＝＝＝

スプリントの期間は固定する。（短ければ1週間～長くて4週間）
完了の定義
　完了の定義によって、何をもってリリース判断可能か定める。
　ex)コードレビュー、チェックイン、ユニットテスト、カバレッジ、ドキュメント、セキュリティ、性能、デプロイ

＝＝＝＝＝
CodeIgniter 3 でmysql 4.0 に接続

mysql 4.0 に CodeIgniter 3で接続が出来ないと思って
[(入門) CodeIgniter 2 でdatabase接続 - Qiita](http://qiita.com/tukiyo3/items/db106e2e2df524d1eefa)を書いていたが、
CodeIgniter 3でも接続する方法がわかった。
[サーバ要件 — CodeIgniter 3.2.0-dev ドキュメント](http://codeigniter.jp/user_guide/3/general/requirements.html) (MySQL（5.1+）、mysql*（廃止予定）)

## 設定

* php 5.6にて確認。

```diff:config/database.php
- 'dbdriver' => 'mysqli',
+ 'dbdriver' => 'mysql',
```

あとの方法は CodeIgniter 2 と同じ。

## E_DEPRECATED のエラーを抑止

![aa.png](https://qiita-image-store.s3.amazonaws.com/0/25728/cef170fb-3931-2e35-ca34-e5c9c232603c.png)

```diff:system/database/drivers/mysql/mysql_driver.php
 // Error suppression is necessary mostly due to PHP 5.5+ issuing E_DEPRECATED messages
 $this->conn_id = ($persistent === TRUE)
         ? mysql_pconnect($this->hostname, $this->username, $this->password, $client_flags)
-        : mysql_connect($this->hostname, $this->username, $this->password, TRUE, $client_flags);
+        : @mysql_connect($this->hostname, $this->username, $this->password, TRUE, $client_flags);
```
ライブラリのコンテクストを越えた例外の送出はやめよう

この記事は [Sansan アドベントカレンダー](http://qiita.com/advent-calendar/2016/sansan) ネタ枠のHaiToが去年から引き続きお送りしています。

# Introduction
去年の http://qiita.com/HaiTo/items/af0836723ba1ec45de3e の `Introduction` で 
> fogが唐突にExcon::Errorを返してくるファッキンな部分とかと書いても

こんなことを書いていて、まぁつまりこの記事はこの話です。

# Fog?
https://github.com/fog/fog
`fog is the Ruby cloud services library, top to bottom:`
`Fog` はクラウドサービスをがばっとラップしていい感じに共通化されている状態で扱える便利ライブラリ[^1]です。
AWSやAzureはもちろん、Sakura cloud やIBMのBluemixとかいろいろななクラウドサービスに対して殆ど共通のインターフェースを提供してくれ、いい感じに扱えます。
> 大切なことなので二度

例えば使い方として、

```rb
# 出典: http://fog.io/
storage = Fog::Storage.new({
  :provider => 'AWS',
  :aws_access_key_id => ACCESS_KEY_ID,
  :aws_secret_access_key => SECRET_ACCESS_KEY
})

storage.get(file_name)
# これでS3からObjectが取れる
```

ね。簡単でしょ？ AWS-SDKが2012年頃はこなれていなかったのかは歴史的経緯の海の飲まれ不明ですが、Sansanの名刺データ化システムの中の画像をとったりする部分はこのFogをさらに僕達がラップして使っています。

# 何が良くないの？
冒頭でも書きましたが、予期せぬエラーが発生します。

```rb
storage.get(file_name)
# raise Excon::Error::InternalServerError 
#       message: Expected(200) <=> Actual(500 InternalServerError)
```

`Excon` のエラーがraiseされてきます。
Excon とは https://github.com/excon/excon こちらで、まぁつまりRubyのHTTPクライアントの一つです。
つまり、クラウドサービスをいい感じにラップしてくれるライブラリですが、エラーはそのコンテクストでラップしてくれるわけではなく、HTTPクライアントのエラーをそのまま `raise` する仕組みになっています。

## で、それで何が困るの？
たとえば以下のようなコードになるわけです。

```rb
def storage
  @storage ||= Fog::Storage.new({
    :provider => 'AWS',
    :aws_access_key_id => ACCESS_KEY_ID,
    :aws_secret_access_key => SECRET_ACCESS_KEY
  })
end

def image_temporary_url(id, expire: 30.seconds.since.to_i)
  storage.get_object_https_url('awesome-bucket-name', id, expire)
rescue Excon::Error::InternalServerError => e
  retry # 実際には無限Retryになるので良くないのでretriable等を使う。
end
```

突如として出現する **`Excon`** の文字列！ 特に `Excon` を直接使っていないと、この`Excon`が一体何者なのかを考える所から始まります。[^2]
そして、バックトレースを漁っていくとFogの先にその実体が居ることが分かるわけです。
後からコードをさわった人も、「このExconってなんだろう？ Gemfileにも書かれてないしなぁ……」となるわけです。
Gemfile.lockを見たり、`@storage` を見てFogの中を見て……と考古学的な時間が掛かります。

# じゃあどうしたいの？
**素直に`Fog::Error`みたいな例外をraiseしてください** お願いします何でもはしません。
つまり、以下のようなコードになります。

```rb
def storage
  @storage ||= Fog::Storage.new({
    :provider => 'AWS',
    :aws_access_key_id => ACCESS_KEY_ID,
    :aws_secret_access_key => SECRET_ACCESS_KEY
  })
end

def image_temporary_url(id, expire: 30.seconds.since.to_i)
  storage.get_object_https_url('awesome-bucket-name', id, expire)
rescue Fog::Error::InternalServerError
  retry
end
```

こうするだけで、「あぁFogのエラーなんだな」という事が一瞬で理解出来るようになりますね。
深追いする必要もなく、Fogを使うのを辞めたら素直にこのロジックも消す(あるいは`AWS::Error`みたいなのに置き換わる)ことが出来ます。

良い世界ですね。

## じゃあコントリビューションしろよ
Fogの場合はライブラリがでかく、また、ライブラリの特性上影響範囲が広く読みきれない（読めば良いんですが）事が目に見えてます。
> でも実は取り掛かったら簡単なのかも。

あと英語が苦手なので、ちょっとこれだけのやりとりを頑張るモチベーションも無いです。
> Fog捨てたいし

# 結論
何かライブラリを作ったりした時に、別のGemを使って例外を発生する箇所もあると思いますが、
**そのライブラリのコンテクストに応じた例外に置き換えて、改めてraiseするようにする** と、皆ハッピーになるかなぁと思います。


-------

今年はモンハンではなくGジェネを楽しんでます


[^1]: 便利とは言っていない
[^2]: `rescue`はわかりやすさのために入れています
PostCSSの仕組み

この記事における「PostCSS」という単語のスコープは、GitHubリポジトリにあるPostCSS本体のコードが行う範囲を指します。

https://github.com/postcss/postcss

## PostCSSのAST

PostCSSは自体はただのCSSのパーサーで、それほど大きいコードベースではありません。PostCSSは入力としてCSSのソースコードを受け取り、パースし、独自のAST（Abstruact Syntax Tree, 抽象構文木）を生成します。

実際のASTはどういうものかを見てみましょう。

まず、以下の内容で `input.css` というファイル名を作ります。

```css
.qiita {
  color: #fff;
  background-color: #4ea30a;
}
```

そして、`input.css` のコードをパースし、ASTを標準出力します。

```js
// parse.js
const fs = require('fs')
const util = require('util')
const postcss = require('postcss')

const css = fs.readFileSync('./input.css')

const ast = postcss.parse(css)
console.log(util.inspect(ast, false, null))
```

実行:

```bash
$ node parse.js
Root {
  raws: { semicolon: false, after: '\n' },
  type: 'root',
  nodes: 
   [ Rule {
       raws: { before: '', between: ' ', semicolon: true, after: '\n' },
       type: 'rule',
       nodes: 
        [ Declaration {
            raws: { before: '\n  ', between: ': ' },
            type: 'decl',
            parent: [Circular],
            source: 
             { start: { line: 2, column: 3 },
               input: 
                Input {
                  css: '.qiita {\n  color: #fff;\n  background-color: #4ea30a;\n}\n',
                  id: '<input css 1>' },
               end: { line: 2, column: 14 } },
            prop: 'color',
            value: '#fff' },
          Declaration {
            raws: { before: '\n  ', between: ': ' },
            type: 'decl',
            parent: [Circular],
            source: 
             { start: { line: 3, column: 3 },
               input: 
                Input {
                  css: '.qiita {\n  color: #fff;\n  background-color: #4ea30a;\n}\n',
                  id: '<input css 1>' },
               end: { line: 3, column: 28 } },
            prop: 'background-color',
            value: '#4ea30a' } ],
       parent: [Circular],
       source: 
        { start: { line: 1, column: 1 },
          input: 
           Input {
             css: '.qiita {\n  color: #fff;\n  background-color: #4ea30a;\n}\n',
             id: '<input css 1>' },
          end: { line: 4, column: 1 } },
       selector: '.qiita' } ],
  source: 
   { input: 
      Input {
        css: '.qiita {\n  color: #fff;\n  background-color: #4ea30a;\n}\n',
        id: '<input css 1>' },
     start: { line: 1, column: 1 } } }
```

ASTと聞くと難しく感じるかもしれませんが、ただのJavaScriptのオブジェクトです。今回は、`Root` ノードがまずあって、その下に `Rule` ノードが1つ、その下に `Declaration` ノード（プロパティ宣言）が2つ、という構造になっています。 また、各ノードにある `source` プロパティはソースマップです。

## PostCSSの処理の流れ

PostCSSは上述した通り、CSSコードを受け取り、ASTを生成します。そして、そのASTをCSSの文字列に変換するだけです。PostCSS自体はASTの変換は行ないません。つまり、 **PostCSS単体ではCSSは一切変換されない** ということです。

![postcss-process2.png](https://qiita-image-store.s3.amazonaws.com/0/6598/ecb8a9db-bd0f-5451-2592-d21f617815d2.png)

実際にCSSを変換する処理は、PostCSSのプラグインが担当します。PostCSSでは複数のプラグインを組み合わせて使うことができ、読み込んだ順に実行されます。プラグインとは、ASTを受け取り、任意の変換を行ったASTを返すプログラムのことです。

---

また、PostCSSはこのASTを簡単に操作するための便利なAPIも提供しています。

明日はこのAPIをいくつか使って、ASTの変換の方法を説明します。
sshを使用し、別サーバーからの特定のコマンドの実行だけを許可する

#sshを使用し、別サーバーからの特定のコマンドの実行だけを許可する
sshを使用すると別サーバよりコマンドを実行する事が可能になるが、特にrootを用いてのコマンド実行など認証を鍵形式にしていても不安が残る。そこで特定のコマンドやシェルの実行しか許さないようにする。
自分で作成したシェルも実行できます。
sudoして特定のコマンドしか許さないようにしたらどうかといった話もあるが、ここはsudoできないような環境を想定する。
またrootユーザ以外でも同じテクニックは使えるので覚えておこう。

##コマンドを実行されるサーバー（受け側）のsshd設定変更
rootでのログインを禁止にしていると「PermitRootLogin no」になっていたり
初期だと「PermitRootLogin yes」になっていたりすると思う。
これを「PermitRootLogin forced-commands-only」に変更する。
※最近のデフォルトだと「PermitRootLogin forced-commands-only」に既になっていたりする。

```lang:/etc/ssh/sshd_config
#PermitRootLogin no
PermitRootLogin forced-commands-only
```

```lang:設定反映
service sshd reload
```

##キーの発行
コマンドを実行されるサーバー（受け側）にてキーを発行する

```lang:キーの発行
ssh-keygen -t rsa -N "" -b 2048 -f /root/.ssh/hogehoge

-t rsa :keyのタイプ
-N "" :パスワードなし
-b :bit数
-f :ファイルの作成場所
```

作成されたキーは
hogehoge
hogehoge.pub
となる。
このうちhogehoge.pubの中身を
/root/.ssh/authorized_keysに追加する。
既に行がある場合は最下行に追加してください。
追加する際は、行の先頭に

```lang:
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="コマンドの絶対パス"
```
を追加します。
ここでは他にポートフォワードなども禁止しています。

```lang:具体例
hogehoge.pubの中身が
ssh-rsa aaaaaaaaaaaaaaaaa1111111111111111
だとしたら、
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="コマンドの絶対パス" ssh-rsa aaaaaaaaaaaaaaaaa1111111111111111
となる。

すでにauthorized_keysに何かある場合は
ssh-rsa bbbbbbbbbbbbbbbbbbbbb2222222222222222222
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="コマンドの絶対パス" ssh-rsa aaaaaaaaaaaaaaaaa1111111111111111
のように既存行を改行して次の行に追記する。
```

追記後は「hogehoge.pub」ファイルは消しておいていいかも。

##コマンド発行側
コマンド発行側では先程作成した秘密鍵「hogehoge」を使用して接続する。

```lang:
ssh -i /etc/ssh/hogehoge -p 22222 -l root  ターゲットのipもしくは名前 ターゲットの実行したいコマンドをターゲット側のフルパスで

-i : pubキーのパス
-p : port
```

この秘密鍵は他のユーザには見れないように厳重にパーミッションなど注意してください。

以上
SQL整形ツール

ログみるときやデバッグ時に長い長い一行のSQL文を確認しなきゃいけないときってありますよね。

手で整形するのも面倒なので、自動で整形してくれるツールがあると最高です。
仕事で使うSQLだとオンラインで気軽に変換、というのも怖いので、オフラインで使えるツールに絞って探してみました。

[Poor Man's T-SQL Formatter ]
このツールが良さそうでした。いくつかバージョンがあるようです。
http://www.architectshack.com/PoorMansTSqlFormatter.ashx

■ SSMS and Visual Studio Add-In
SQLServerユーザーには嬉しい、マネジメントスタジオ上で実行できるアドインです。

■ WinForms App
こっちのバージョンが、今回探していたものにぴったりでした。
![図1.png](https://qiita-image-store.s3.amazonaws.com/0/148310/367b1ae4-382b-d506-cb4e-52cfe3094a53.png)

SQL文を貼り付けると、自動で瞬時に整形してくれます。便利！！
整形オプションもあるので、ある程度自分の好きなフォーマットに近づけることができます。
PackstackでNewtonをインストールする

# OpenStackをインストールした環境
## ハードウェア
- HP DL360p Gen8 4台

## OS
- CentOS7.2

## ネットワークの構成
```
host1  10.30.0.100　　　コントロールノード
host2  10.30.0.101　　　Compute(Nova)ノード1
host3  10.30.0.102     Compute(Nova)ノード2
host4  10.30.0.103     ネットワークノード
```

# OpenStackインストール
## OSのインストール
PackStackを実行するhost1ではOSに日本語環境が入っていると、インストールに失敗する様子。CentOS7のインストーラを英語モードで実行して、インストール後は/etc/environmentに次の値を設定します。

```
LANG=en_US.utf-8
LC_ALL=en_US.utf-8
```

## SELinuxの設定
host1〜4のすべてのノードで設定はdisabledに変えておきます。

## ネットワークの設定
NetworkManagerとFirewalldを停止します。

```
systemctl stop firewalld
systemctl disable firewalld
systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl start network
systemctl enable network
```

## パッケージのインストール
host1にOpenstackのパッケージをインストールします。

```
yum install -y centos-release-openstack-newton
yum update -y
yum install -y openstack-packstack
```

## answerファイルの作成
```
packstack --gen-answer-file=answer.txt
```

## answerファイルの修正
host1のanswer.txtファイルの以下の部分を修正します。

- CONFIG_KEYSTONE_ADMIN_PW=<パスワード>
- CONFIG_NETWORK_HOSTS=10.30.0.103
- CONFIG_COMPUTE_HOSTS=10.30.0.101,10.30.0.102

## インストールの実行
```
packstack --answer-file=answer.txt
```
## ブリッジネットワークの設定変更
host4でネットワークポートbr-exを設定します。（hosts1〜3では不要のようです。）

- /etc/sysconfig/network-scripts/ifcfg-br-ex 

```
BOOTPROTO="static"
DNS1="10.30.0.3"
GATEWAY="10.30.0.1"
IPADDR="10.30.0.103"
PREFIX=16
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
NAME="br-ex"
DEVICE="br-ex"
ONBOOT="yes"
```

- /etc/sysconfig/network-scripts/ifcfg-ens2f0

```
TYPE="OVSPort"
NAME="ens2f0"
DEVICE="ens2f0"
ONBOOT="yes"
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
```

## GUIへのアクセス
Dashboardからネットワーク、ルータの設定します。インスタンスを実行してComputeノードでKVMが起動すれば、とりあえずOKです。
CentOS6.8にtpcc-mysqlを入れようとして失敗した話

はじめまして！ kakuka4430と申します（由来は某軍師です）。
こちらは、[MySQL Casual Advent Calendar 2016](http://qiita.com/advent-calendar/2016/mysql-casual) の2日目の記事 兼 私の初投稿です。

先日、CentOS6.8にtpcc-mysqlをセットアップしようとしたらエラーに遭遇してしまったので、
その話を書いてみようと思います。

※ 下記の問題は、CentOS 6.7 / CentOS 6.8 で確認
※ どうやら CentOS 7 系では解決されているようです

*【経緯】*
https://yoku0825.blogspot.jp/2012/07/tpcc-mysql.html

皆さんお世話になっているであろうyoku0825さんの上記ブログ記事を参考にして、
tpcc-mysqlをセットアップします（参照する情報が古すぎるのはご愛敬…）。


```
# yum install -y mysql-server mysql-libs mysql-devel
# yum install -y bzr make gcc
```
→ 必要なパッケージを入れて…

```
# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
```
→ bzrを使ってtpcc-mysqlをダウンロードしようとすると…

```
TypeError: readline() takes exactly 1 argument (2 given)

bzr 2.1.1 on python 2.6.6 (Linux-2.6.32-573.7.1.el6.x86_64-x86_64-with-centos-6.7-Final)
--- 省略 ---
*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.
```
→ bzrでエラーが発生してしまいました

*【原因】*
どうやらbzrのバージョンが古いのが原因のようです。
問題を解決するため、bzrの新しいバージョンを入れます。

```
# yum remove -y bzr
# yum install -y wget
# wget https://launchpad.net/bzr/2.6/2.6.0/+download/bzr-2.6.0.tar.gz
# tar zxf bzr-2.6.0.tar.gz
# cd bzr-2.6.0
# python setup.py install

※Pythonのエラーが発生した場合は、下記コマンドで必要なパッケージを入れましょう
# yum -y install python-devel kernel-devel
```

あとは問題なくtpcc-mysqlをダウンロードできるはずです。

```
# cd ~/
# bzr init
# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
```

*【参考URL】*
http://laporz.blogspot.jp/2015/08/aurora-vs-mysql.html

*【余談】*
現在は「tpcc-mysql」もGitHubで公開されているので、実はbzrを使わなくてもいいんですけどね。。
https://github.com/Percona-Lab/tpcc-mysql


普段はROM専ですが、こうして記事を書いてみるのも良いものですね。
明日・明後日の枠が空いているようなので、お気軽にご参加くださいー！
http://qiita.com/advent-calendar/2016/mysql-casual

次回は、12/3 [@yoku0825](https://yoku0825.blogspot.jp/2016/12/mysql.html)さんです！
Firefox開発ツールのショートカット

この記事は[Firefox 開発ツール Advent Calendar](http://qiita.com/advent-calendar/2016/fx_devtools)の 1日目の記事です。
昨日はUemmra3の[Firefox Developer Editionの存在](http://qiita.com/Uemmra3/items/807837c888f3e1c482d9)でした。
明日はxxxxさんの[未定](URL)です。

さて、Developer Editionをインストールしたら、色んな機能を使ってみたくなると思います。

TODO

では。
pyenv環境でAnacondaを使う

最近 [ゼロから作るDeep Learning](https://www.oreilly.co.jp/books/9784873117584/) でDeep Learningの勉強をはじめました。

その過程で NumPy や Matplotlib などのデータ分析系のライブラリが使えるディストーションである Anaconda の環境を用意する必要があり、本では [Anaconda公式ページ](https://www.continuum.io/downloads) からインストールシェルを使ってインストールするように書いてありますが、私は pyenv を使いたかったので、そのとき行った手順を書きます。

といってもめっちゃ簡単で、以下を実行するだけです。
※pyenvはインストール済みの前提

```
$ pyenv install anaconda3-4.0.0
```

`anaconda3-4.0.0`環境をactivateする

```
$ pyenv activate anaconda3-4.0.0

(anaconda3-4.0.0) $ pip list
alabaster (0.7.7)
anaconda-client (1.4.0)
anaconda-navigator (1.1.0)
...
numpy (1.10.4)
...
matplotlib (1.5.1)
...
```

~~本当はvirtualenv環境を作りたかったのですが、以下のようにしても `numpy` などのライブラリがコピーされなかったので仕方なく上記のやり方にしています。~~

```
$ pyenv virtualenv anaconda3-4.0.0 deeplearning

$ pyenv activate deeplearning

(deeplearning) $ pip list
pip (9.0.1)
setuptools (27.2.0)
wheel (0.29.0)
```

~~やり方ご存知の方いたら教えてください。~~

### 2017/04/04 追記
anacondaではcondaコマンドを使ってvirtualenv環境を作るようですね。

```
$ conda create -n deeplearning anaconda

$ source activate deeplearning
もしくは
$ pyenv activate anaconda3-4.0.0/envs/deeplearning
```
開会の辞：技術書献本感謝Advent Calerndar開催にあたって

## 開催の趣旨

みなさま技術書献本感謝Advent Calerndar 2016にようこそ。
このAdvent Calendarは普段心の中にあっても、記事という形にはしていなかった献本に対する「感謝」を年末にまとめていこうという趣旨で始まりました。
正直なところ、私自身、優秀な知遇を得たおかげで、本をいただく機会も増えたのですが、日々の忙しさにかまけて記事にするのを怠っておりました。

まあ、いろんな感謝の形があっていいと思うんですよね。
twitterで書籍の画像と一緒に「ありがとうございました！」。
Facebookで感謝の舞の動画と一緒に「ありがとうございました！」。
結婚式でフラッシュモブと一緒に「ありがとうございました！」。
とはいえ、まとまった記事の形でレビューを書いていただき、それが多くの注目を集めていると、著者冥利につきるでしょう。

一方、どんな形でレビューして良いかわからないという方も多いと思います。
このAdvent Calendarの中では参加者皆様の様々な形のレビューを通して、献本していただいた際のレビューの雛形を探っていければとも思っています。

## 献本する時に人は何を思うか

私自身、執筆して何度か献本する機会に恵まれたのですが、この際思ったのが「献本する相手、そんなにいない」ということです。
もちろん原稿のチェックなどでお世話になった方には送るのですがそれ以外の相手が思いつかない。
よくレビューを書いている人はいるけど、決まった人に送るのもなんだかなという気分もあります。
そんな時に今回のCalendarを通して、「この人は丁寧な/面白いレビューを書いてくれるから、自分が執筆したらこの人に送ってみよう」とかいった判断の一助になればいいなと思っています。

## 終わりに
能書きが長くなりましたが、このカレンダーの趣旨はあくまで各自で溜まったレビューを大放出し、こんな本があったんだと読者に認識してもらうことでロングテールな売上に多少なりとも貢献できればというものです。
ですので、記事の中にはアフィリエイトの有無にかかわらず、書籍へのリンクを貼っていただければ幸いです。

それでは皆様のレビューをお待ちしております。

※自動投稿に失敗しておりました。
PHPエンジニアが絶対に読みたい本

## インフラ

|書籍名|読了|
|:--|:-:|
|サーバー技術者養成講座||
|Amazon Web Services実践入門
|Amazon Web Services パターン別構築・運用ガイド||
|Amazon Web Services 業務システム設計・移行ガイド||
|AWSによるサーバーレスアーキテクチャ||
|Amazon Web Services負荷試験入門||
|プログラマのためのDocker教科書||
|コンテナ・ベース・オーケストレーション||
|Ansible実践ガイド||
|nginx実践ガイド||
|Mackerel サーバ監視[実践]入門||
|Webエンジニアが知っておきたいインフラの基本||
|パケットキャプチャの教科書||

## データベース

|書籍名|読了|
|:--|:-:|
|達人に学ぶDB設計||
|達人に学ぶ SQL徹底指南書 ||
|SQLアンチパターン||
|SQL実践入門||
|データベース技術[実践]入門||
|やさしく学べるMySQL運用・管理入門||
|ビッグデータを支える技術||
|ビッグデータ分析・活用のためのSQLレシピ||

## フロントエンド

|書籍名|読了|
|:--|:-:|
|HTML5&CSS3デザイン||
|HTML5&CSS3ステップアップブック||
|JavaScriptの教科書||
|Atomic Design||
|React開発 現場の教科書||
|Node.js超入門||
|Webサイトパフォーマンス実践入門||
|UX+理論で作るWebデザイン||

## サーバーサイド

|書籍名|読了|
|:--|:-:|
|パーフェクトPHP||
|Laravelリファレンス||
|Laravel入門||
|PHPプログラミング開発テクニック||
|体系的に学ぶ 安全なWebアプリケーションの作り方||

## ソフトウェア開発

|書籍名|読了|
|:--|:-:|
|CODE COMPLETE||
|コーディングを支える技術||
|達人プログラマー||
|リファクタリング||
|レガシーコード改善ガイド||
|テスト駆動開発||
|初めての自動テスト||

## ソフトウェア設計

|書籍名|読了|
|:--|:-:|
|現場で役立つシステム設計の原則||
|エリック・エヴァンスのドメイン駆動設計||
|マイクロサービスアーキテクチャ||
|Web API: The Good Parts||
|アジャイルソフトウェア開発の奥義||
|オブジェクト指向のこころ||
|システム設計のセオリー||

## プロジェクト管理

|書籍名|読了|
|:--|:-:|
|SCRUM BOOT CAMP||
|アジャイルサムライ||
|スクラム現場ガイド||
|スクラム実践入門||
|カンバン仕事術||
|チーム開発実践入門||
|DevOps導入指南||
|エンジニアのためのGitの教科書||
(入門) CodeIgniter 2 でdatabase接続

## 参考

* [目次 : CodeIgniter ユーザガイド 日本語版](http://codeigniter.jp/user_guide/2/toc.html)
* [モデル | 基礎編 CodeIgniter Guide 徹底ガイド！](http://www.ci-guide.info/basic/model/)
* [kenjis/php-framework-benchmark: PHP Framework Benchmark](https://github.com/kenjis/php-framework-benchmark)

## インストール

```rb:
git clone https://github.com/tukiyo/docker-php5.6-apache
cd docker-php5.6-apache

sh files/get_codeigniter2.sh
chmod -R 777 app/tmp
docker-compose up
```


## model

* application/config/database.php の修正は終わっていること。
* `select id,name FROM shop`を行いたい。

```
touch application/models/shop.php
```

```php:application/controllers/Welcome.php
<?php

if (!defined('BASEPATH')) exit('No direct script access allowed');

class Welcome extends CI_Controller {

    public function index() {

        $this->load->model('Shop');
        $res = $this->Shop->get_info();
        echo "<pre>";
        var_dump($res);
        //$this->load->view('welcome_message');
    }
}
```

```php:application/models/Shop.php
<?php

class Shop extends CI_Model {

    public function __construct() {
        $this->load->database();
    }

    public function get_info() {

        $this->db->select('id,name');
        $this->db->from('shop');
        $query = $this->db->get();
        //echo $this->db->last_query();

        $res = null;
        if ($query->num_rows() > 0) {
            $res = $query->result();
        }
        return $res;
    }

}
```
Amazon Aurora for PostgreSQL compatibilityの話を聞いてきたよ

日時・場所
----------

12/1(Day1) 12:30- Venetian Theater/Venetian
Mark Porter / General Manager
Kevin Jernigan / Senior Product Manager

概要
----

Day 1で発表になった、Amazon Aurora w/ PostgreSQL compatabilityのブレイクアウトセッションがありましたので、そちらのレポート

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLQ2p1TUVXY3B6b1E)

[【速報】Amazon Aurora with PostgreSQL compatibility が発表されました！ #reinvent ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/reinvent2016-postgre-aurora/)

総括
----

* 12/1現在、Limited Previewですので[申し込みが必要](https://pages.awscloud.com/amazon-aurora-with-postgresql-compatibility-preview-form.html)です
* ローンチは2017年の早い段階を予定。ただしベータかGAかは全然未定
* Amazon Aurora (MySQL)の時のように、超早い

セッション内容
--------------

※Ventian Theaterのスクリーンがあまり良くなくて、見づらくてスミマセン。。。
※冒頭はAmazon Auroraの話だったので省略します

### Amazon Aurora(PostgreSQL)移行シーン ###

* Amazon EC2上に手で構築したDB移行
* Amazon RDS for PostgreSQLからの移行
* Oracle や SQL Serverからの移行

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLOF83Y25iTzZSSTg)

### "Compatibility" とはどういう意味か？ ###

プロトコルレベルでのPostgreSQLと同じ振る舞い

* psqlはもちろんpg_dumpなども使える
* 内部構造は全く別物。ただし利用者・開発者が意識する必要は全く無い

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLVjRZVVNWUFdhdWs)

### Amazon RDS for PostgreSQLとの違い ###

高速な動作
※Amazon RDS for PostgreSQL / m4 16xlarge, c4 8xlarge との比較

* トランザクション 3倍
* データのローディング 3倍
* レスポンスタイム 2倍以上
* スループットのブレ※ 3倍以上安定
* スケール時のスループット 3倍
* リカバリーに必要な時間 85倍も短い

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLUEtEbE1Jc0w0ZWs)
![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLc2ZJb2xKNkZVdU0)
![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLN0llaEY1Q0dhRHM)
![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLakU5UTdsc2NubEk)
![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLblVsSlEybUdTcGM)
![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLLXZDUWlpZ0VNNGM)

Amazon Aurora特有の "そもそもチェックポイントを持たない" 事による復旧の速さ

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLeXdCcV9Ua2xkNWs)

### ローンチまでのロードマップ ###

特に下記はローンチ時点でサポートをする予定

* PostgreSQLの全機能
* Amazon RDS for PostgreSQLエクステンションのサポート
* AWS DMSのサポート
* AWS KMSを使ったデータ暗号化
* SSLサポート
* Amazon VPCサポート

![](http://drive.google.com/uc?export=view&id=0B8oVjSSLpXBLN2h2QlJOTkpjNlE)

### QA ###

Q: Amazon Aurora for PostgreSQLがリリースされたらRDSの方はどうなるの？
A: HaHaHa!! RDS for MySQLが残っているように、RDS for PostgreSQLも残るよ

Q: 価格は？
A: 未定だけど、たぶんAurora(MySQL)が出てきた時並のインパクトがある価格にするつもりだよ

所感
----

早く使いたい

あとがき
--------

申し訳ない、このセッション受講は完全に個人的な趣味です
ねむい
複数の作業ディレクトリを作成する git worktree

git では通常、リポジトリと作業ディレクトリとが一組になっています。`git clone` をすると、作業ディレクトリの中に `.git` ディレクトリ（＝リポジトリ）が作成されます。

![git-worktree_main.png](https://qiita-image-store.s3.amazonaws.com/0/6204/8bdc3822-094d-3e50-1c28-af25c6584cac.png)

そして、この作業ディレクトリの中でブランチを切り替えて作業するのが一般的かと思います。

さて、作業ディレクトリの中で何かの作業中に、別の割り込み作業が発生して、一時的にブランチを切り替えたくなったとしましょう。そんなときは、いったん現在のブランチに作業中の変更をコミットしておいてからブランチを切り替えたり、作業中の変更を `git stash` を使って保存してからブランチを切り替えたり、という操作をすることになります。

そういった操作が簡単に素早くできるのが git の特徴ではあります。しかしそれでも、そういった切り替えが多くなってくると、作業中の変更を失ってしまったり、現在のブランチを勘違いして作業してしまったり、といったミスを招く心配があります。

そんなとき、[git worktree](https://git-scm.com/docs/git-worktree) が便利かもしれません。

# git worktree とは

`git worktree` は、ひとつのリポジトリに対して、複数の作業ディレクトリを作成して管理することができます。

![git-worktree.png](https://qiita-image-store.s3.amazonaws.com/0/6204/aba21bf8-6994-0641-b690-291ed601b5ae.png)

`git worktree add <path> <branch>` で、指定パスに作業ディレクトリが作成できます。作業ディレクトリの内容は指定したブランチのものになります。

新しい作業ディレクトリにはリポジトリは複製されておらず、元のリポジトリを参照するようになっています。作業ディレクトリを見てみると、通常の `.git` ディレクトリの代わりに、`.git` という名前のファイルができていることが分かります。元の作業ディレクトリを "main working tree"、`git worktree add` で作成した新しい作業ディレクトリを "linked working tree" と呼びます。

リポジトリを共有しているため、ひとつの working tree で特定のブランチにコミットを行うと、別の working tree でもそのブランチが更新されます。

# linked working tree の管理

linked working tree の情報は、リポジトリで管理されています。`git worktree list` で linked working tree の一覧が表示できます。

linked working tree を削除したい場合には、単にそのディレクトリを丸ごと削除します。そのあとで、main working tree で `git worktree prune` を実行すると、linked working tree の情報が削除されます。

ちなみに、間違って main working tree を削除しないように気をつけてください（linked working tree はリポジトリ本体を持っていないので削除しても平気ですが、main working tree にはリポジトリ本体が含まれています）。

なお、main working tree は linked working tree のパスを持っており、linked working tree は main working tree のパスを持っています。このため、main working tree や linked working tree を後で別のパスに移動するとおかしくなってしまいます。この点は、`git worktree` を活用する際には注意が必要です。

# 活用のパターン

## パターン 1 : 割り込み作業のために linked working tree を作成する

作業ディレクトリ（main working tree）の中で何かの作業中に、別の割り込み作業が発生したとします。

そんなときに、作業中の main working tree をそのままにしておいて、`git worktree add` で linked working tree を作成することができます。割り込み作業は linked working tree で行い、終わったら linked working tree を削除します。

main working tree はそのまま残っているので、すぐに元の作業に戻ることができます。

## パターン 2 : 自分の作業のために linked working tree を作成する

上記のパターン 1 とは逆に、main working tree は普段は触らず、linked working tree で普段の作業をする、という方法もあります。割り込み作業は main working tree で行います。

普段の作業で常にトピックブランチを作成する習慣がある場合は、このパターンでも良さそうです。linked working tree 上でトピックブランチの作業をして、トピックブランチを master ブランチにマージしたら linked working tree を削除します。

# まとめ

ひとつのリポジトリに対して、複数の作業ディレクトリを作成する `git worktree` を紹介しました。便利かどうかは各自の使い方次第になると思いますが、選択肢のひとつとして知っておくと良いのではないかと思います。
技術英語 > Their argument is that debugging tools are [a crutch] and ... / car:clutch

@ Code Complete (No. 18032 / 36077) 

> Their argument is that debugging tools are a crutch and ...

http://ejje.weblio.jp/content/crutch
> 2 支え.

"[通例複数形で] 松葉づえ."という意味もあるとのこと。

<hr>

前後の文は以下となっている。

> They recommend using your brain and avoiding debugging tools altogether. Their argument is that debugging tools are a crutch and that you find problems faster and more accurately by thinking about them than by relying on tools.

意訳「ツールに頼らず頭を使うといいよ」

ツールはあくまでツールで、それを主体とするものではない、というのは分かっていても時々失敗する。

<hr>
crutchは車のクラッチを思い出す。

https://www.howacarworks.com/basics/how-a-car-clutch-works

> The first stage in the transmission of a car with a manual gearbox is the clutch.

スペルは「clutch」のようだ。

<hr>
以下は、思いつきの記憶方法。

松葉杖のcrutchは、真っすぐな棒ではないから「r」。

車のclutchは、、、特に思いつかなかった。「松葉杖でない方のクラッチ」でお茶を濁す。
re:inventで発表されたX-Rayのサンプルアプリを試してみた


![スクリーンショット 2016-12-01 10.01.28.png](https://qiita-image-store.s3.amazonaws.com/0/23936/9df3b2f2-e74d-0fbb-1ccb-7fd87603ab5a.png "スクリーンショット 2016-12-01 10.01.28.png")

##Get Started の Launch a sample application(Node.js)を起動する
「Launch a sample application(Node.js)」を選択してサンプルアプリを立ち上げます。
![スクリーンショット 2016-12-01 10.01.38.png](https://qiita-image-store.s3.amazonaws.com/0/23936/9935165a-f8aa-6dd0-8d61-a7c5d19ee573.png "スクリーンショット 2016-12-01 10.01.38.png")

「Launch Sample Application」をクリックすると、別窓でCloudFormationの管理画面が起動します。
この画面は消さずにそのままにしておきます。
![スクリーンショット 2016-12-01 10.05.58.png](https://qiita-image-store.s3.amazonaws.com/0/23936/4b6a46e1-e002-531c-4468-11b3b82604bc.png "スクリーンショット 2016-12-01 10.05.58.png")

ここから先は従来通りのCloudFormationでのスタック起動作業です。
![スクリーンショット 2016-12-01 10.06.10.png](https://qiita-image-store.s3.amazonaws.com/0/23936/dd85103b-ded7-dd53-d89d-0f2259a2932b.png "スクリーンショット 2016-12-01 10.06.10.png")

CloudFormationの起動が完了して、OutPutsの「ElasticBeanstalkEnvironmentURL」に表示されているIPからサンプルアプリにアクセスできるか確認します。緑色の「Start」をクリックするとサンプルデータがX-Rayに投入され始めます。
![スクリーンショット 2016-12-01 11.22.37.png](https://qiita-image-store.s3.amazonaws.com/0/23936/da9818af-98b6-f11d-c5bc-4451866245fe.png "スクリーンショット 2016-12-01 11.22.37.png")


OKならば、先程のX-Rayのウィザード画面に戻ります。
「Launch Sample Application」だった青ボタンが「Done」に変わっているので、クリックします。これを抜かすとマッピングができずにX-Rayで確認できないっぽいので注意してください。

![スクリーンショット 2016-12-01 13.46.05.png](https://qiita-image-store.s3.amazonaws.com/0/23936/5e92793b-f571-e3cc-f1bc-5ba52e6854cb.png "スクリーンショット 2016-12-01 13.46.05.png")


##X-Rayを使ってみる
こんな感じでビジュアライズされます。
![スクリーンショット 2016-12-01 13.49.36.png](https://qiita-image-store.s3.amazonaws.com/0/23936/704ec174-d5ff-c7b7-8275-2fcc183cbe88.png "スクリーンショット 2016-12-01 13.49.36.png")

円をクリックすると、サービス別のステータスが見れます。
![スクリーンショット 2016-12-01 13.52.30.png](https://qiita-image-store.s3.amazonaws.com/0/23936/940e0bed-bf47-b10b-5396-4d2039799353.png "スクリーンショット 2016-12-01 13.52.30.png")
IDを選択すると、そのIDの処理で使われたリソース(?)別にどれだけ時間がかかったかが見れます。
![スクリーンショット 2016-12-01 13.52.56.png](https://qiita-image-store.s3.amazonaws.com/0/23936/62064729-08aa-e3a2-6964-f3623182a2fa.png "スクリーンショット 2016-12-01 13.52.56.png")

##触ってみて
まだサンプルアプリとサンプルデータで見ただけですが、複数のサービスを組み合わせていくマイクロサービスやサーバーレスアーキテクチャで作られたアプリケーションのボトルネックを探す時などに重宝しそうです。
Lean Theorem Prover で 継続モナド

[2016/12/11 追記]
以下の記述は lean2 のものです。lean3 では動きません。
[/追記]

今回は継続モナドの証明に挑戦してみる。

```monad2.lean
structure Monad [class] (M : Type → Type) :=
  (return : Π {A : Type}, A → M A)
  (bind : Π {A B : Type}, M A → (A → M B) → M B)
  (left_identity : Π {A B : Type} (a : A) (f : A → M B),
    (bind (return a) f) = (f a))
  (right_identity : Π {A : Type} (m : M A), bind m return = m)
  (associativity : Π {A B C : Type} (m : M A) (f : A → M B) (g : B → M C),
    bind (bind m f) g = bind m (λx, bind (f x) g))
```

モナドクラスはこの前と同じ。
継続モナドの場合の `M : Type → Type` は次のやつ。

```monad2.lean
definition contM (R A : Type) := (A → R) → R
```

return と bind は次の通り定義。

```monad2.lean
namespace cont

  definition return {R A : Type} (x : A) := λ(k : A → R), k x

  definition bind {R A B : Type} (c : contM R A) (f : A → contM R B) : contM R B :=
    λ(k : B → R), c (λ(a : A), f a k)

end cont
```

left_identity, right_identity, associativity を証明する。（bind の定義の下に追加）

```monad2.lean

  theorem left_identity {R A B : Type} (a : A) (f : A → contM R B) :
    bind (return a) f = f a :=
  begin
    apply rfl
  end

  theorem right_identity {R A : Type} (m : contM R A) :
    bind m return = m :=
  begin
    apply rfl
  end

  theorem associativity {R A B C : Type} (m : contM R A)
    (f : A → contM R B) (g : B → contM R C) :
    bind (bind m f) g = bind m (λx, bind (f x) g) :=
  begin
    apply rfl
  end

```

すべて `apply rfl` で終わってしまった…。

これらを使って継続モナドを構成できる。

```monad2.lean
definition Cont [instance] {R A : Type} : Monad (contM R):=
Monad.mk (@cont.return R) (@cont.bind R)
  (@cont.left_identity R) (@cont.right_identity R)
  (@cont.associativity R)
```

すべてをまとめると次の通り。

```monad2.lwan
structure Monad [class] (M : Type → Type) :=
  (return : Π {A : Type}, A → M A)
  (bind : Π {A B : Type}, M A → (A → M B) → M B)
  (left_identity : Π {A B : Type} (a : A) (f : A → M B),
    (bind (return a) f) = (f a))
  (right_identity : Π {A : Type} (m : M A), bind m return = m)
  (associativity : Π {A B C : Type} (m : M A) (f : A → M B) (g : B → M C),
    bind (bind m f) g = bind m (λx, bind (f x) g))

definition contM (R A : Type) := (A → R) → R

namespace cont

  definition return {R A : Type} (x : A) := λ(k : A → R), k x

  definition bind {R A B : Type} (c : contM R A) (f : A → contM R B) : contM R B :=
    λ(k : B → R), c (λ(a : A), f a k)

  theorem left_identity {R A B : Type} (a : A) (f : A → contM R B) :
    bind (return a) f = f a :=
  begin
    apply rfl
  end

  theorem right_identity {R A : Type} (m : contM R A) :
    bind m return = m :=
  begin
    apply rfl
  end

  theorem associativity {R A B C : Type} (m : contM R A)
    (f : A → contM R B) (g : B → contM R C) :
    bind (bind m f) g = bind m (λx, bind (f x) g) :=
  begin
    apply rfl
  end

end cont

definition Cont [instance] {R A : Type} : Monad (contM R):=
Monad.mk (@cont.return R) (@cont.bind R)
  (@cont.left_identity R) (@cont.right_identity R)
  (@cont.associativity R)
```
乳児が泣く不快要因の分解

1日目に続き2日目も具体的に Raspberry Pi の話ではなくて恐縮だが、センサーによる適切なモニタリングを行うためにまず乳児が泣く不快要因について分解してみたい。

## 不快要因の分類

### ダンスタン乳児言語 (Dunstan Baby Language)
オーストラリアのメゾソプラノ歌手 Priscilla Dunstan は乳児の泣き声と不快の原因を以下のように分類している。[^dunstan]
音声の解析はかなりハードルが高い気がするが、iOS アプリで [Baby Ears by DBL](https://itunes.apple.com/jp/app/baby-ears-by-dbl/id556482217?mt=8&at=1000ldGD) が480円で販売されている。

* Neh ネェ (空腹)
* Owh オォ・アォ (眠気)
* Heh ヘェ (暑さや排泄物の不快感)
* Eairh エァ (胃腸内のガスによる不快感)
* Eh エッヘ (ゲップ不良の不快感)

[^dunstan]: https://en.wikipedia.org/wiki/Dunstan_Baby_Language

### 肉体的泣き
小児科専門医の小山博史医師は、乳児が泣く原因を精神的なものと肉体的なものに大別し、[輸送反応](http://www.riken.jp/pr/press/2013/20130419_2/)で鎮静しないものを肉体的泣きとして以下のように分類している。[^ikomaiin]

[^ikomaiin]: [赤ちゃんが泣く時、不快を感じている - 和歌山市の小児科 生馬医院](http://www.ikomaiin.com/?%E8%B5%A4%E3%81%A1%E3%82%83%E3%82%93%E3%81%8C%E6%B3%A3%E3%81%8F%E6%99%82%E3%80%81%E4%B8%8D%E5%BF%AB%E3%82%92%E6%84%9F%E3%81%98%E3%81%A6%E3%81%84%E3%82%8B#content_1_2)

* 空腹
* 温度
* 排泄
* 痛み
* 痒み
* 風邪など、病気の前駆症状

## 不快要因の整理
前述の言説を参考に、乳児が泣く不快要因を以下のように整理した。
1. 空腹
2. 暑さ
3. 排泄
4. 痛み
5. 痒み
6. 眠気
7. 姿勢

## 各不快要因の分析
### 空腹
新生児期は昼夜問わず2~3時間おきに母乳または人工乳の授乳が必要である。
泣き声を**音センサー**により常時モニタリングすることで、授乳の規則性を発見できるかもしれない。

空腹時に手足を動かす特徴があるなど、動きにより検知が可能と思われる場合、**映像**または**加速度センサー**によって判別可能である。

### 暑さ
新生児や乳児は体温が高く、体躯も小さいため体温調整が難しい。
寝具のかけ過ぎで寝具内の温度が不快なレベルまで上昇したり、室温自体が高くなりすぎたりなどが考えられる。

これらは**温度センサー**で寝具内の温度および室温を常時モニタリングすることにより閾値が見えてくると推測される。
また同時に**湿度センサー**で湿度もモニタリングすることで、不快感の閾値の精度を向上できると考えられる。
その他、**気圧センサー**により気圧をモニタリングすることで温湿度の変化を事前に予測することも考えられる。

不快要因を暑さとしたが、寒さも同様と思われる。

### 排泄
大便や尿など排泄物の気持ち悪さで泣く場合がある。
**においセンサー** によって排泄の有無を確認することが出来ると考えられる。

昨今の紙おむつの品質向上により泣かない乳児も多いと推測されるが、排泄物を放置すると皮膚のかぶれが生じるなど衛生面で問題があり、早期の処理が望まれるため、泣かない場合でも早期検出は重要である。

### 痛み
発熱などの病気の前駆症状として苦痛を感じて泣く場合や、湿疹等の炎症による痛みにより泣く場合が考えられる。
センサーによる痛みの検知は、**音センサー**で泣き声を分析する以外には難しいかもしれない。

### 痒み
「新生児落屑」と呼ばれる現象があるなど新生児期は皮膚が乾燥、剥落しやすい。
**湿度センサー**で湿度をモニタリングすることで、冬季の空気乾燥による皮膚の乾燥の事前防止と不快要因からの可能性除外が可能となる。
加湿器があれば通常は湿度計が付いているが、常時モニタリングをすることで給水時期を推測したりなど管理効率向上も可能かもしれない。

### 眠気
眠いのに眠れないために不快を感じて泣くケースがあるようだが、これもやはり**音センサー**で泣き声を分析する以外には難しいかもしれない。

### 姿勢
乳児は自身で体勢を変えることが出来なかったり、逆に快適でない姿勢になってしまうことがあり、これを快適な状態に変更できないため泣いてしまうケースが考えられる。
**映像**や**加速度センサー**、**感圧センサー**によって判別可能かもしれない。

## センサー
前述の不快要因の整理から、活用可能と考えられる各種センサーは以下の通り。後日入手可能な商品を具体的に確認したい。

* 音センサー
* カメラ
* 加速度センサー
* 温度センサー
* 湿度センサー
* 気圧センサー
* においセンサー
* 感圧センサー

3日目は既存のモニタリングシステムについて確認してみたい。

## 参考文献
シンプルでキレイなところで生きたい。その１

### 前段
修論やる気起きないなー
って思ったとき、なんでやる気起きないんだろ・・ダメだなって思うけど
どうしても世の中と折り合いつけなきゃいけない時があって、
こんな世の中とか自分がだめだとか言う前に、
ぶらぶらぶら下げてる余計なものを切り落とさないといけないなって思った。


断捨離。

# Case:01
__「ゴミ屋敷ならぬゴミポスト。」- ひきこもりの対処に困っている大家の女性__

1. メールがすごく来る
2. そこにたまに英語のメールが混じる（しかも案外重要だったりする）
3. たまればたまるほど、見るのが嫌になる

無駄に来るFAXのようにメールの重要度は下がっていき、
読み損ねたり、読んでも対応する気がなくなってきたり（他の放置メールが頭をよぎって嫌になる）、そうして対応が遅れると怒られて、文面を考えるのも億劫になり、だんだんとメールボックスを開くのすら嫌になってしまった。
簡単なことなのにどうしてできないんだろうって、凹んでまたループしてしまう。

# Hack:01

## 方針

僕らは霧の中の砂漠のように、不透明で複雑な地形を歩いている。

1. 情報を見える化し、不透明さを減らす
2. 見える情報を減らし、複雑さを減らす

を繰り返して、着実に前へ進む必要がある。

1. は取り組むべき課題と課題を構成する要素といった複雑さを明らかにする
2. では基準を設け、複雑さをフィルタリングしていく

## 分析
__メーラー__
まず、メーラーが複数の端末で統一されてなかった。
端末によっては見えてるメールが違ったり、フォルダ分けされたメールが見にくかったり、ストレスだった。
そしてフォルダは昔Gmailで設定したものと、Macのメーラーで個別に設定したものが混ざっていた。
統一しないと、メールの分類すらままならない。
メーラーは1つにすべきだ。しかもどの端末でも利用できるように。

__メールの中身__
ちょこっと自分のメールを見てみた。

1. 宣伝とか、SNSの通知が大半
2. サービスの通知が少し
3. 先生からのメールなど、自分の行動にかかわるものがそこそこ

といった感じだった。
対処したメールを捨ててしまうと後から確認できないから、対処済みはラベル付けしたりして別枠にしたい。

## 切り落とし
状況がわかったので、対処をはじめる。
__メーラー__
メーラーはinboxにした。自動分類があるのがいいし、完了と削除を使い分けて、対処済みメールとほんとに要らないメールを区別できる。

__メールの整理__
すぐ消せるものは今すぐ消そうと思い、
判断基準として
- 対応が、いるもの/いらないもの
- 前者のうち、10分以内に対応できるもの/できないもの
を設けた。

メール整理以外はやらないことにして（←大事
まずは1. 2. のメールを一括削除。
3．は片っ端からピン止め、10分以内に対処できそうなものはその場で対処した。

これをやると、メールが２、３通に減った。ヤバい。
スクロールできないのが不思議な気分だった。

基準を加えよう。スクロールバーなしに一覧が見れる。ちょっとカンバンシステムでのWIP制限に似てるな。
来たメールはすべて見て、要らないものはすぐ消してスクロールバーの排除につとめることにしよう。


## その後
不思議と宣伝やSNSの通知も一読する余裕が生まれた。Qiitaの今週の～とかFacebookの誕生日通知にも結構反応できるようになった。

ただ、作業中に来たメールを後回しにしてPIN止めしているうちに、スクロールバーが現れてしまった。

inboxには、スヌーズ機能がついている。

期日が大事なものだったり、10分以内にできそうなものは、翌朝再通知などにして手を付けやすくするとよさげだ。


## まとめ

メールがあふれかえり、また対処の仕方に統一性がなく、混乱を招いていた。
問題の複雑さをなくし、タスクの透明性を確保するため、以下を徹底する。

1. inboxだけを使い、自動分類を活用
2. 読んだものは、すぐアクション。（Pinどめ、完了、削除、スヌーズなど）

たったこれだけで、必要なメールには必ず目が通せるようになったし、連絡し損ねることもなくなった。スケジュール張へ写し忘れたりってこともない。最高です。

# え、それだけ？？
僕は、ここが最初のボトルネックだった。

やってないことすべてが頭の片隅にちらついて、何もかも嫌な感じで、メールボックスの問題はその一つにすぎなかったけれど、「連絡しなきゃ」は1日で最初に躓くところだった。
実のところ初めに検討したのは、この「最初に躓くところはどこか」だった。

嫌なことってひとくくりにしない（見える化し）で、一つ一つ向き合えば（見える情報を減らせば）、必ず対処できると思う。


何かをやめる理由はいくらでも見つけられる。

だから、少しでも躓きそうなところは少しでも良くしていって、気持ちよく物事に取り組めるようにしたいのだった。

次はどうしてもTwitterとかみちゃったりする話。
GitHubからAzureにウェブサイトをデプロイ

#ローカルからGitHubにデプロイ
[ここ](https://techacademy.jp/magazine/6235)を参考にしてGitHubに**Hello World!**を表示するプログラム(hello.html)をPushする
このあと、GitHubとAzureを連携してHTMLファイルをAzure上にデプロイして表示してみます

#Azureにデプロイ
GitHubに上げたものは[こちら](https://github.com/saiyuki1919/testfordjango)になります。ここには、Hello Worldを表示するだけのHTMLがPushされています。
##Web APPの作成
まずはAzureポータルに行き、下記の順番にアクセスして行き、WebAppを作成します
**【App Service】➡️【追加】➡️【Web App】➡️【作成】**

・設定はアプリ名は任意に設定し、リソースグループは作成してない場合は作成してください
・App Service　プラン/場所は新しく作成しちゃったほうがいいかも
![1.png](https://qiita-image-store.s3.amazonaws.com/0/130097/4b9ea733-ac72-9e24-99ee-0c037f17947e.png)

##GitHubと連携
作成した**App Service**から下記のようにGitHubを選択
**【デプロイ　オプション】➡️【ソースの選択】➡️【GitHub】**

![2.png](https://qiita-image-store.s3.amazonaws.com/0/130097/50ebcc77-b071-673c-04f9-8c3ba4d1b3c7.png)

・承認でGitHubにログイン
・プロジェクトの選択でデプロイしたいリポジトリを選択

![3.png](https://qiita-image-store.s3.amazonaws.com/0/130097/95de4415-8c9c-a9b1-6a45-abadaa99d8a9.png)

下のように完了したら、**【同期】**を行い反映させる

![4.png](https://qiita-image-store.s3.amazonaws.com/0/130097/47aa3945-68bf-6623-8cad-6b447d49ab24.png)

##デプロイ
最後に【App Service】にある**【URL】**からページを開き、デプロイしたhtmlを確認すると**Hello World**と表示される
![5.png](https://qiita-image-store.s3.amazonaws.com/0/130097/ddd10c0a-1cc6-2f97-6761-68dc26465697.png)

#おまけ
実際にデプロイ行うとApp Service内にある**コンソール**からAzureサーバをいじることができる
実際に **D:\home\site\wwwroot**の下にhello.htmlが入っている
「全検索アルゴリズム入門」の隠された情報を書き出してみる

[「全検索アルゴリズム入門」](http://qiita.com/MasayaMizuhara/items/86099ad721a329e1d6cd)は、すごく良い記事で勉強になりました。
その中で・・・
>例題1:最短歩数の測定

という例題が提示されていますが、なぜ最短歩数が求められるか？
について説明が不足している気がしたので勝手に捕捉。

* 元記事の移動状況を示す図。

```text:引用(探索状況)
(0)          (1)          (2)          (3)
s 0 0 0 0    s B 0 0 0    s B 0 0 0    s 0 E 0 0
0 0 1 0 0    A 0 1 0 0    0 D 1 0 0    A D 1 0 0
0 1 0 0 0    0 1 0 0 0    C 1 0 0 0    0 1 0 0 0
0 0 g 1 0    0 0 g 1 0    0 0 g 1 0    0 0 g 1 0
0 0 0 0 0    0 0 0 0 0    0 0 0 0 0    0 0 0 0 0
0 0 1 0 0    0 0 1 0 0    0 0 1 0 0    0 0 1 0 0
```
↑の図に対応する訪問履歴(memo)は、次のように変化していきます。

```text:スタートからの距離
(0)          (1)          (2)          (3)
s 0 0 0 0    s 1 0 0 0    s 1 0 0 0    s 1 2 0 0
0 0 0 0 0    1 0 0 0 0    1 2 0 0 0    1 2 0 0 0
0 0 0 0 0    0 0 0 0 0    2 0 0 0 0    2 0 0 0 0
0 0 g 0 0    0 0 g 0 0    0 0 g 0 0    0 0 g 0 0
0 0 0 0 0    0 0 0 0 0    0 0 0 0 0    0 0 0 0 0
0 0 0 0 0    0 0 0 0 0    0 0 0 0 0    0 0 0 0 0
```

つまり、

* sからの移動量が訪問履歴に保持されているのがポイント！
* gに到達した時点で探索は終了するから無駄がないよ！

ってことなんですね。

全検索アルゴリズムを勉強し始めだったので、gに到達した時点で終了するのと、
探索歩数にどういう関係があるんだろう？（ポカーン）
としてたのですが、コレに気が付いてやっと理解できました。
※デバッガで動かしながら変数をwatchしてれば分かるんだろうけど。

例題の解法は幅優先探索でしたが、深さ優先探索も同様にsから一歩ずつ進んで探索するので
同様の考え方で歩数が得られるんですね。

**但し、**
深さ優先の場合は、sからgまでの経路と移動量を全パターン求め終わって初めて最短経路が判明する。
*アルゴリズムを理解してる人にとっては、当然の話なのかもしれませんけど・・・*
Perl for構文 grep, map の不思議

先日触った [Net::WebSocket::Server](http://qiita.com/Urushibara01/items/55fb464a582ce6f782e2)のソースコードを見ていて気づいたのですが、for構文の使い方が意味不明だったので自分用メモ。

まずサンプルコードからして不思議である。

```Perl:
$_->send_utf8($msg) for $conn->server->connections;
```

この for 一体なんだろう・・・？
そう思ってServer.pm の中も覗いてみると・・・

```Perl:Server.pm
sub connections { grep {$_->is_ready} map {$_->{conn}} values %{$_[0]{conns}} }
```

ふぁっ？？？

return すら存在しないしなんなのよこれ？！

いろいろ試してみて、return if (ごにょごにょ); みたいなPerl独特の文法を利用したものだと気付いた。

```Perl:
my @a = (1,2,3);
print $_ for @a;

# 123
```

```Perl:
my @a = (1,2,3);
sub b {$_==@_[0]||&c} # セミコロンも省略可らしい・・・
sub c {print "$_\n"} # return はいらない
b(1) for map {$_} grep {$_} @a;

# 2
# 3
```

<span class='label label-default'>解説</span>
``&b()`` は引数の他に、``$_`` がそのまま参照可能。
``A || B`` は 式Aが<真>ならそのまま``return``として抜けるので 式Bである``&c()`` へはNOTの役割になる
関数 ``c()`` の中では ``$_`` はまだ読めるので``print``すればこの通り。

Perlさん、フリーダムすぎぃ！！！

``map`` ``grep`` に似ている。でもどっちかというと ``foreach``

**まとめると、**

- ``for`` は配列が引数の時、左辺にステートメントがあると、左辺に配列の中身を一つずつ参照して ``$_`` として返してくれる。(``shift``はしないので配列は破壊されない)
- 無名変数 ``$_`` を使用するので、他に無名変数を書き換えるような関数などをかますとヤバイ(evalとかも？)
- 
perl は変態言語である


こんな混乱を生みそうな文法はあまり良くないと思うけど、一応こんな書き方があるということは、知っておくべきだと思いました。

え？知ってた？常識？　失礼いたしました・・・。
AWS X-Ray発表

「Transformation」をキーとして発表がされた（これ書いているときまだやってますｗ）、AWS上で動作するアプリケーションの見える化サービスとして「AWS X-Ray」が公開されました。

[AWS X-Ray](https://aws.amazon.com/jp/xray/)

Preview版のためまだ使うことはできませんが、発表されたドリルダウン機能などは早く使ってみたいと思わせるものでした。

＃画質悪いですが。。。
![Cym1LyuVIAAH8OT.jpg](https://qiita-image-store.s3.amazonaws.com/0/102769/4d27f393-817c-01d7-74bb-0764071893ce.jpeg)

# 特徴
３層階層の単純なWebアプリケーションから数千のサービスから成る複雑なマイクロサービスまで分析、可視化を行い、根本問題の解決の手助けをするものです。

1. アプリケーションアクセス時のリクエストをトレースする。
2. 現在動作可能なサービスは Amazon EC2、 Amazon EC2 Container Service (Amazon ECS)、 AWS Elastic Beanstalk。Lambdaの対応は少し先。
3. Java、.NET、Node.jsで書かれたアプリケーションを対象に分析ができる。
4. 開発中であろうと運用中であろうと適用が可能。

どこまでの分析、可視化が可能なのか。どのような適用（手軽さ）なのかなど、どうしても他のサービスと比較したいポイントがまだ書かれてはいませんが、実際に試せるようになる日を楽しみにしましょう。
React Nativeとは何なのか

改めて、React Nativeについて書いていきたいと思います。

## React Nativeとは何か？

ReactはFacebookが開発したJavaScriptのフレームワークであり、React Nativeはそれをモバイルで使えるようにしたものである。

React Nativeを使用することでネイティブに描画されるiOSとAndroidのアプリを作ることができる。１つのコードで、両方のプラットフォームで動くものが作れる。さらに、JavaやObjective-Cのライブラリを自分で書いてReact Native自体を拡張することもできる。WebでReactを使っているなら、ターゲットがモバイルに代わるだけなので簡単に使い始めることができる。

React同様、React NativeもJavaScriptと、JSXと呼ばれるXMLライクなマークアップを使って記述される。内部では、ネイティブのレンダリングAPIが呼び出されるので、WebViewではなく、ちゃんとしたモバイルUIコンポーネントが描画される。もちろん、プラットフォームの機能であるカメラや位置情報といったものも利用できる。

ネイティブのレンダリングAPIが呼び出されるクロスプラットフォームでのアプリ開発というと、以前だとTitanium Mobile、今だとXamarinなども思い浮かべられるかもしれない。ここでは特に比較などはしないが、１つReact Nativeが安心できるポイントとして、Facebook, Instagram, Airbnb, Baiduといった名だたるアプリがこぞって採用しているということが挙げられる。どういったアプリで利用されているかは[こちら](https://facebook.github.io/react-native/showcase.html)のページで見ることができる。

### React Nativeの利点

他の多くのクロスプラットフォームを謳う開発方法（CordovaやIonic）と違い、WebViewではなくネイティブで描画されるのが大きな利点となる。
これらの開発方法ではネイティブでの表現（UI/UX）を再現するために多大な努力をしているが、完全な再現とまでは行っていないし、最先端からは一歩遅れた表現（UI/UX）になってしまう。また、パフォーマンスもあまり良くない。

一方でReact NativeではネイティブなUIが使われるし、また、メインのUIスレッドとは別に動くからパフォーマンスも高く維持される。
React NativeのアップデートサイクルはReactと同じで、``props``や``state``が変化したときにビューが再描画される。

開発の方法はほとんどReactと変わらないので、Reactを使ったことのある人にとって学習コストが低いのも大きい。同様に、開発メンバーも集めやすい。また、以下で述べるように普通のモバイル開発に比べて開発がしやすいのも大きなポイントである。

### 開発体験

React Nativeは開発ツールが充実している。例えば、React NativeはJavaScriptなのでアプリを再起動することなく、変更を反映することができる。画面上でただ``Command + R``を押すだけで良い。

デバッグツールとエラー報告も優秀で、ブラウザのデベロッパーツールと同じように使える。テキストエディタはXcodeやAndroid Studioに縛られる必要がなく、好きなものが使える。

開発体験だけでなく、プロダクトのリリースサイクルにも良い影響がある。例えば、AppleはJavaScriptベースの変更を認めているので、レビューを通さずにアップデートをすることができる。

### コードの再利用と知見の共有

React Nativeを使うことで、モバイルアプリ開発に必要なリソースは大きく短縮される。Reactの書き方を知っている開発者なら誰でもWeb、iOS、Androidのアプリを作れることになる。プラットフォームごとの専門職は要らなく、チーム全体で素早く知見を共有することができる。

知見だけではなく、コードも共有可能だ。全てのコードがクロスプラットフォームになるわけではなく、個別のプラットフォームに合わせたObjective-CやJavaのライブラリを作らなければいけないこともあるが、例えばFacebookの広告管理アプリのAndroid版の87%のコードはiOSと全く同じだという。

### リスクと欠点

React Nativeにおける最も大きな危険性はおそらく、React Nativeがまだ発展段階にあるということだ。2015年の3月にiOS用としてリリースされ、同年9月にAndroid対応が発表されたばかりである。
まだネット上にも情報が多いとはいえないし、ドキュメントも整備されていない部分がある。ただし、足りないAPIは自分で作ることができるので、完全な「詰み」になることはないだろう。
Reactとプラットフォームでデバッグするべき層が二層になるのも欠点の１つだ。

## React Nativeはどのように動くのか

ReactにおけるDOMへの描画の代わりに、React NativeはObjective-CやJAVAのAPIを呼び出してコンポーネントを描画する。例えばReact Nativeでの``View``はiOSでは``UIView``となる。

## React Nativeをどのように学習していくか

まず、React周辺の知識は前提として必要になる。また、[公式ドキュメント](https://facebook.github.io/react-native/docs/getting-started.html#content)が最初の導入にはやはり良いかと思う。Reactを知っている上で公式ドキュメントに目を通せば、少なくともある程度のアプリは作れるようになると感じた。

また、英語にはなるが[Learning React Native](http://amzn.asia/jaF18Sy)のような書籍もある。ただし、書籍だと情報はやはり少し古い部分もあるので、新しい情報が欲しい場合はWebで情報を入手するか、あるいは内容が更新される電子書籍などが良いと思う。

## あとがき

実は自分はReactより先にReact Nativeについて勉強してしまった（そして、意外と簡単なアプリならそれでも問題なく作ることができた）のですが、結局Reactについて知らないと良いアプリは作れそうにないな、と感じてReactやReduxの勉強をすることになりました。これを一歩目として、React Nativeについての知見がもっと貯まった際にはまた記事を書こうと思います。
開発のしやすさを重視した仕様を作成しよう

[開発のしやすさを無視した仕様は成功しにくい](http://qiita.com/nonbiri15/items/bfcbf6406825630fac2f)
に関連した記事です。


###**「最終実装のCPUボードはこれだから、全ての開発はそのボードでいいよね」**

**間違っている理由：**
　・最終実装の外部仕様・内部仕様、設計の詳細が全て自明になっていることはまずない。
　　開発しながら明らかにしていかなければならない要素がある。
　・開発に必要なコンパイラ・エディタなどのツールの使い勝手が
　　開発の速度を上げるの必須。
　　（場合によってはクロスコンパイラが必要）

　
###**「製品には画像の表示はないから、開発中でも画像の表示ができないCPUボードでいいよね」**
**間違っている理由：**
　・画像の扱いが適切であることを確認するための枠組みが必要。
　そのボードでXの表示ができて確認ができれば
　プログラムの実行中に不具合を目視で見つけることが可能だが、
　Xの表示がない場合、
　結果の画像を保存して、ftpで画像を転送して
　別のマシンで表示するという方法しかできなくなる。
　
　　問題の発見や対策がとても限られた状況になる。

###**「実装はC言語と決まっているから、プロトタイピングでもC言語でお願いするよ」、「僕は○○言語なんてわからないから、C言語でお願いするよ」**
**間違っている理由：**
　プロトタイピングは、楽をしてアルゴリズムの妥当性を検証することです。楽ができる理由は、目的のライブラリが充実している言語を使うことにあります。ここでC言語を使ってしまうと、本来の実装と同じ開発量を必要としてしまって、少ない工数で設計の妥当性を検証しようすることを達成できなくなります。
　設計が正しいのか、要求仕様が適切なのかが、プロトタイピングをしてみないと気づかないことがあります。プロトタイピングをせずに実装して、そのプログラム中の関数の要求仕様が期待したものではないことが判明したりすることもある、
　早い段階で設計の妥当性を検証しておくことが、製品のプログラムの開発を成功させるポイントです。


###**「どうせ、それは開発時点でしか使わないんだから、そんなものにお金をかけられないよ。最終製品に使うもの以外に金をかけるのは言語道断だ。」**
**間違っている理由：**
 大きな建物を建てるときには、建物の中にクレーンが設置されることがあります。
家を建てたり、外装を補修する際にも足場を組みます。どちらも、建物を建てるという「開発段階」でしか使わないもので、最終成果物に残るものではありません。でも必要のあるものにはお金をかけています。
　ソフトウェアといういわば”建築物”を作りあげるには、クレーンや足場が必要であることを理解してください。


###**「昔はそんなのがなくたってちゃんと開発していたんだ。それがないと開発できないなんて言うな。」**
**間違っている理由：**　
　SVNやgitなどのバージョン管理ツール、Redmineのようなオープンソースのプロジェクト管理ソフトウェアなど、今の時代の開発には必須のツールです。動いている例を見せてもらうことです。また経験者の声を聞くことです。バージョン管理ツールが(ファイル単位の管理だった)貧弱だった時代と、今ではソフトウェアの生産性が10倍近く変わっているように思います。
　開発者がいうことには、それだけの根拠があります。

###**「製品として残るコード以外書くな。デバッグをしやすくするためなどいうコードを書いている暇があったら、さっさと製品のコードを書け。」**
**間違っている理由：**　
　製品として残るコードは正しいコードであることが必須です。間違った製品コードのリリースは、多額の損失を発生させます。間違ったコードを製品として書くよりは、コードをリリースしていない方が格段ましだと私は思います。
　ソフトウェアの開発を進めていく中で品質をどう確保するのか、そのことを考えてください。


###**「どうせ自分たちで書かなければならないコードなんだから、市販のライブラリを買ってみるなんて言うな。」**
**間違っている理由：**
　ソフトウェアを開発する時点では、対象のライブラリについて、必ずしも正確な理解をしきっているわけではありません。もし、そのライブラリが有用であって、無理のない価格であったら購入する価値はあります。ある関数の動作についての解釈が正しいのかを検証するための比較のライブラリになります。
　FTPのソフトウェアを開発していると仮定しましょう。既存のFTPのソフトウェアと動作を比較することは、開発しているソフトウェアの健全性を検証するのに役立ちます。
　製品の中で、他社のライブラリを購入して利用することは、価格の上昇につながるので、自社でライブラリを開発したいとします。そのような場合でも、当初の開発は、他社のライブラリを購入して開発し、それ以外の部分の開発を進めて、製品のソフトウェアの見通しを早めにつけることを推奨します。その後、必要な関数だけを自社開発すれば、他社ライブラリを使わなくて済むようにできます。
　ですから、自分たちで書かなければならないコードでも、市販ライブラリを買うことは、開発速度を上げるのにとても有効なのです。



###**「成果物としてのライブラリのインタフェースには、そんなのないんだから、『単体テストをするためのインターフェース』だって、いい加減にしろ。」**
**間違っている理由：**
ソフトウェアの品質管理の近年の動向をつかんでいますか。マネージャーとして組織の方向性を導いていくとき、必要な動向をおさえてみてください。単体テストでのカバレージが一定水準を超えていないと、製品として受け入れないという組織もあります。
　単体テストを可能にしないライブラリは、後々トラブルを引き起こす可能性が高くなります。



###**「とにかく、うまく動きゃいいんだ。『設計がおかしい』だなんて抜かすな。」**
**間違っている理由：**
どうやってソフトウェアの品質を確保しますか。
品質が不十分だったことが判明したときに、どれだけ損失を発生するのか考えたことがありますか。


##関連する追記：##

[開発速度が上がる順序を考慮して実装を行っていこう](http://qiita.com/nonbiri15/items/9846085dfa61bab105a3)として別記事にしました。
LaravelのDBトランザクション落とし穴

Laravelを使った開発でハマった事を何か紹介出来ればと思い書いてみました。

## DBトランザクションはコネクション毎に効くようになっています
当たり前の事なんですけど、Laravelのような便利なフレームワークを利用していると
こういった常識を忘れて何時間もハマってしまったりします。

設定方法によっては同じDBにも関わらず、複数コネクション使用してしまっていて
期待通りにロールバックされないなんて事が起きるわけです。

もしかしたら一生役に立たない例かもしれませんが、
私が遭遇した落とし穴がどんなケースだったのかを紹介したいと思います。

## DBのマスター・スレーブ構成を採用したアプリケーション
例えばマスター・スレーブ構成をとっている場合も、Laravelを使っていれば
設定ファイルに書き込み時のhostと読み込み時のhostを指定するだけで勝手に使い分けてくれます。とてもお手軽ですね。
https://readouble.com/laravel/5.3/ja/database.html#read-and-write-connections

config/database.phpで以下のように「read」と「write」を指定するだけでOKです。

```php
'mysql' => [
    'read' => [
        'host' => '192.168.1.2', // スレーブのホストを指定
    ],
    'write' => [
        'host' => '196.168.1.1' // マスターのホストを指定
    ],
    'driver'    => 'mysql',
    'database'  => 'database',
    'username'  => 'root',
    'password'  => 'hogehoge',
    'charset'   => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix'    => '',
],
```

言わずもがな裏ではマスターへのコネクションと、スレーブへのコネクションが作られるわけです。

## 読み込みだけどマスターを参照したい時
DBマスターへの書き込みがDBスレーブに同期されるまでにはタイムラグがあります。
通常気になる事はないでしょうけど、同期が失敗し続ける可能性もあります。

確実に最新情報を参照するためDBスレーブではなくマスターを参照したくなるわけです。

Laravelのモデルクラスではconnectionプロパティにて、利用する接続情報を指定する事ができます。
https://readouble.com/laravel/5.3/ja/eloquent.html#defining-models

この指定をすると デフォルトの接続情報よりも優先されるのです。
かゆいところに手が届く感じで良いですね！

```php:config/database.php
// この設定を追記
'master' => [
    'host' => '192.168.1.1', // マスターと同じホストを指定
    'driver' => 'mysql',
    // 省略
],
```

```php:店舗Model
<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

/**
 * 店舗テーブル
 */
class Shop extends Model
{
    protected $table = 'shops';
}
```

```php:商品Model
<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

/**
 * 商品テーブル
 */
class Item extends Model
{
  protected $connection = 'master';
  // このようにモデルクラスでconnectionプロパティを指定する事で、
  // 商品テーブルへのアクセスは読み込みであってもマスターを向くようになります。

  protected $table = 'items';
}
```

これで意図したDBを参照するようになってくれます。
**DBトランザクションの落とし穴も出来ました。**

## DBトランザクションを使用してみる
上記設定でDBトランザクションを使用してみましょう。

ShopとItemそれぞれへの更新がどちらもロールバックされるのが期待される動作です。

```php
\DB::transaction(function() {

    $shop = new Shop;
    $shop->save();

    $item = new Item;
    $item->save();

    throw new \Exception('ここで処理を終わらせる');

});
```

しかし実際に動かしてみるとItemだけロールバックされません。
これは手動トランザクション（DB::beginTransaction()使うやつ）でも同じです。

なぜItemだけロールバックがされないのか？

実はItemモデルはconnectionにmasterを指定しているので
Shopと同じDBマスターを向いているにも関わらず、**デフォルトとは別のコネクションを利用しちゃっている**からなんです。

以下のように書くと理解しやすいかもしれません。
今度は逆で、Shopだけロールバックされなくなります。

```php
\DB::connection('master')->transaction(function() {

    $shop = new Shop;
    $shop->save();

    $item = new Item;
    $item->save();

    throw new \Exception('ここで処理を終わらせる');

});
```

先ほどはトランザクションを開始する時にコネクションを明示していなかったので、
デフォルトのwriteコネクションにトランザクションが張られていたというわけです。

## まとめ
原因がわかってしまえば何だそんな事かという感じですが、
ハマった当時はLaravelのバグだと決めつけて調べていました。猛省。。

参照するDBが同じだから同じコネクションを使用しているとは限りません。
そしてロールバックのような例外テストはしっかりやりましょうね。