OmniAICreator/Qiita-1.07M huggingface dataset:
Segwitを簡単に説明してみる

今回は最近よく話題に上がるSegwitを簡単に説明してみようと思います。

# 注目されるSegwit

ビットコインのブロックチェーン。その最大の課題は何かという質問に対し、「スケーリングです」という答えがよく帰ってきます。ビットコインの取引が増えてきたときに、取引が捌ききれなくなることが危惧されています。そうなった時、より多くの取引が扱えるよう、ビットコインのブロックチェーンに何かしらの変更を加えないといけません。その1つの方法がSegwitなのです。

# Segwitの仕組み

Segwitは、ブロックチェーンのブロックに入るデータ量を増やす事ができます。でも、ブロックの大きさは据え置きです。では、どうやって入るデータ量を増やしているかを簡単に解説します。

![segwit.png](https://qiita-image-store.s3.amazonaws.com/0/28426/4818d87a-bdde-14cb-d8fe-28029984e05b.png)

これまでの取引情報には、すべての取引にそれぞれ電子署名の情報が入っていました。そこで、Segwitを適用した場合、取引データと署名データを別々に扱い、署名データは重複排除が行われます。重複があった分、ブロック内に空きが生まれます。そこの空いた部分にさらに別の取引データを入れることにより、1つのブロックあたりに多くのデータを入れられるようにしています。Segwitを適用することで、60～70%の増量が見込まれているとのことです。

# Segwitの適用状況

2016年11月15日から投票が始まった、Segwit。1ヶ月近く経ちましたが、12月に入ってから25%前後で頭打ちとなっていました。

![segwit.png](https://qiita-image-store.s3.amazonaws.com/0/28426/ca333e8f-e8aa-5392-1ab4-80f34e2fc612.png)

Segwinの適用には、Segwitが動くコードへの差し替えが必要ですが、置き換えが進んでいないようです。多くのノードを抱えるマイニングファームの中には、Segwitに対応しないことを宣言しているところもあり、なかなか適応へは時間がかかっていきそうです。

ビットコインは、約8年間無停止なのは、仕様変更にとても慎重であることも一役買っています。このSegwitへの以降も慎重であるがゆえに、差し替えに時間がかかってしまっています。この慎重さネックになっているのは言うまでもありません。今後、Segwitがどう適用されていくのか、とても気になります。
OpalでJavaScriptのAPIラッパーを作る

この記事は[Opal Advent Calendar 2016](http://qiita.com/advent-calendar/2016/opal)の12日目の投稿として書いています。

今日は、[10日目](http://qiita.com/youchan@github/items/b043d85e5eebd7e7f3e7)の続きでWeb Audio APIのラッパーを作ろうと思います。

Web Audio APIのすべてを実装すると良いとは思うのですが、記事にするにはボリュームが大きすぎると思います。
ある程度のものを作って大体のつくりかたが分るところまでできれば本記事としてはよいでしょう。[9日目](http://qiita.com/youchan@github/items/d3636d619bbf535cd69a)に作ったサンプルが動く程度のものを作ってみましょう。

まずはAudioContextをつくりましょう。

```ruby
module Audio
  class Context
    include Native

    def initialize
      super `new AudioContext()`
    end
  end
end
```

`Native`を`include`することでJavaScriptのネイティブオブジェクトをラップしたクラスを作ることができます。
イニシャライザはネイティブオブジェクトを引数に取るので、ここではラップしたコンテキストクラスで`AudioContext`オブジェクトを生成して`super`に渡すことにします。

exampleのほうも更新しましょう。

*examples/app/application.rb*

```ruby
require 'opal'
require 'opal/audio'

context = Audio::Context.new
source = context.createBufferSource

request = Native(`new XMLHttpRequest()`)
request.open('GET', 'sound.mp3', true)
request.responseType = 'arraybuffer'
request.send

request.onload = Proc.new do
  res = request.response
  context.decodeAudioData(res) do |buf|
    source.buffer = buf
  end
end
source.connect(context.destination)
source.start(0)
```

`sound.mp3`を読めるようにするためにSinatraを使うようにしましょう。
*examples/config.ru*等を[8日目」(http://qiita.com/youchan@github/items/735ffad1a5c406ebb30c)の記事を参考にSinatra版に変更しましょう。

このまま実行すると、`createBufferSource`というメソッドがないと怒られます。
`createBufferSource`メソッドを追加しましょう。
そのまえに、メソッド名はそのままでよいでしょうか?ここはRubyなのでスネークケースのメソッド名にしたいところです。
`create_buffer_source`という名前でネイティブの`createBufferSource`を呼ぶようにしましょう。
`Native`にはこういうときに便利な`alias_native`メソッドがあります。

```ruby
    alias_native :create_buffer_source, :createBufferSource
```

ほかにも、`decode_audio_data`と`destination`も定義しましょう。`destination`のほうは、JavaScript側ではプロパティとしてもっているので`native_reader`を使います。

```ruby
    alias_native :decode_audio_data, :decodeAudioData
    native_reader :destination
```

*examples/app/application.rb*のほうも直して実行しましょう。
音が鳴りましたか?

`AudioContext`だけをラップしましたが、他のオブジェクトのラッパーは書いていません。たとえば`create_buffer_source`の戻り値はいったい何なのでしょう?
`p`で表示してみると、どうやら`Native`クラスのオブジェクトのようです。
このようにOpalは特にラッパークラスを書かなくてもいい感じにラップしたオブジェクトを返してくれます。
今回のケースのようにスネークケースにしたいとかよりRubyishなラッパーにしたい場合にはラッパークラスを書けばよいでしょう。
OpalはRubyとJavaScriptのコードの間の橋渡しがとても良くできていると思います。JavaScriptのプロジェクトに一部Rubyを使うということも可能でしょう。これはOpalのひとつの魅力だと思います。
ゲーム会社で色々勉強した話

15日を担当する事になりました。アダチです。


何を書こうかと思い、考えたところ、Unityは、あまり語れるほどではないので、ゲーム繋がりで、ゲーム会社に入って、学んだ話でも書いて行こうと思います。


### 就職活動
まずは、就職活動の時の話です。専門学校に行ってから、就職活動を行いましたが、就職活動のやり方を知らなかったので、就職活動の勉強にもなりました。

1. 何をやりたいか考える。
 - 働ければ何でもはいいと考えるよりも、ゴールを明確に持つ。プログラマー、デザイナー、プランナーで、必要になる知識は違うので、本当に必要な事に時間をかけられる。
2. 作品に気を配る
 - プログラマー・・・プログラム作品。動かない場合もあるので、説明書にスクリーンショットも撮っておくと良い。
 - デザイナー・・・ポートフォリオ。一番上手く描けた作品、普段描いてる作品、最近書いた作品等があればOK
 - プランナー・・・企画書。誤字・脱字・推敲。
 - 書類選考は、紙面でしかアピールができない為、作品がとても重要なアピールポイントになる
3. 企業調査
 - やらないという話も聞くが、受ける会社の事を調べるのは当たり前
 - 少なくとも、その会社が出しているゲームやアプリは、2、3点はプレイしておく
4. 実践に勝るものは無し
 - 何ヶ月もかけて、独学で身につける知識よりも、仕事で一ヶ月働いた方が得られる技術や情報の方が遥かに多い
 - ゲーム会社で働けるならチャンスがあるなら、アルバイトででも入ってしまって、早めに経験を積んでおく方が役にたつ
5. こんな人をよく見かける
 - やりたい事がある人。熱意があり将来的な目標を持っていて、その為に行動している
6. 運も実力の内！
 - どんなに優秀な人でも、人が十分足りていれば、採用されなかったりする
 - 逆に言えば、本当に人手が足りない時は、スキルセットが合っていなくても採用される事もある

### 就職後
ゲーム会社に入った当初は、覚える事が多くありました。

1. アンテナを張る
 - ニュースサイトや技術サイトやSNSを定期的に、チェックする。ちゃんと業界ニュースを知っていないと雑談もできない
2. 体力勝負
 - プロジェクトや施策にもよるが、開発時間が足りなくなり、物理的に時間を捻出しなければならない場合もある。その場合は、残業や休日出社で時間を作る事がよくある
3. 未経験は、賞味期限あり！？
 - 年齢が高くなればなるほど、新しい事を覚えるのには時間がかかる為、採用のハードルが上がっていく
4. どういう人が業界に残るのか
 - プロジェクトにもよるが、開発の仕事は、プライベートの時間がとり難い事もよくあり、業界を去る人もしばしば居る
 - 2年、3年働いている人は、技術を学ぶ事を本当に楽しんでいたり、作りたいゲームがあったりして明確な目標を持って働いていたりしている


### 中堅になってから
仕事も覚えてきて、扱える技術も多くなって来たのがこの頃です。
また、仕事にできる事とできない事の判別もつくようになって来た為、場合によっては転職をして、自分の目標を考える事もありました。

1. 知識よりも技術/経験（実績）
 - ただ知っているだけよりも、やった事がある方が信用される
 - できれば、その技術を使って、収益を得た事があると良い
2. スキルアップを考える
 - ゲーム会社で働く人は、技術セミナー(UNITEやSEDEC等) に行って、スキルアップしたいと考えている人が多い
 - 技術を学ぶ事が楽しい！これが苦痛に感じてしまうと、業界を続けていくのが厳しいかもしれない
3. キャリアプランを考える。管理職を目指すのでなければ、目指すべきは大きく二つ
 - 技術力に特化したスペシャリスト
 - 幅広い知識と融通が効くゼネラリスト


ゲーム業界に就きたいと考えている人の参考になればと思い、書いてみました。
個人的に必要だったと感じた事を書いているだけなので、必ずしもここに書かれいる事が正しい訳ではありません。
最後まで、読んでいただきありがとうございました！
Go言語でコレクション処理のメソッドを作ってみた　#golang

# はじめに

Qiita初投稿です。

自分がGo言語で配列操作をするとき、rangeを使ってぐるぐるループを回して処理することが多いのですが、
ふと、rubyで言う `map`, `filter`, `each` などを作って使いたくなっては、
「わざわざ作るのもめんどうだしなぁ」と、すぐ諦めてしまいます。

そこで今回は、Advent Calendarの季節でもあり、よい機会なので、
試しにPlaygroundで作ってみることにしました。

# 作ったメソッドたち

## 1. filter


```go
package main

import (
	"fmt"
)

func filter(nums []int, funcs ...func(n int) bool) []int {
	if len(funcs) == 0 {
		return nums
	}
	ret := make([]int, 0, len(nums))
	f := funcs[0]
	for i, n := range nums {
		if f(n) {
			ret = append(ret, nums[i])
		}
	}
	return filter(ret, funcs[1:]...)
}

func main() {
	nums := []int{1, 2, 3}
	nums = filter(
		nums,
		func(n int) bool {
			if n > 1 {
				return true
			}
			return false
		}, 
		func(n int) bool {
			if n > 2 {
				return true
			}
			return false
		}, 

		)
	fmt.Println(nums)
}

```
https://play.golang.org/p/8bqykZCbSU

- 可変長引数にして、フィルタ条件を複数受け付けられるようにした
- 久々に再帰をみた


## 2. map

```go

package main

import (
	"fmt"
)

func mapToI(nums []int, f func(n int) int) []int {
	ret := make([]int, len(nums))
	for i, n:= range nums {
		ret[i] = f(n)
	}
	return ret
}

func main() {
	nums := []int{1, 2, 3}
	nums = mapToI(nums, func(n int) int {
		return n*n
	})
	fmt.Println(nums)
}
```
https://play.golang.org/p/R5CQCRWh7L

- よく使うint, stringあたりだけ作ると便利なこともあるかも

## 3. each

```go
package main

import (
	"fmt"
)

func each(nums []int, f func(n int)) {
	for _, n:= range nums {
		f(n)
	}
}

func main() {
	nums := []int{1, 2, 3}
	each(nums, func(n int) {
		fmt.Println(n)
	})
	fmt.Println(nums)
}
```
https://play.golang.org/p/d2lgAgPQuG

- うーん、これくらいだと作ってあってもなくても変わらない感

## 4. uniq

```go
package main

import (
	"fmt"
)

func uniq(nums []int) []int {
	ret := make([]int, 0, len(nums))
	numsMap := make(map[int]struct{}, len(nums))
	for _, n := range nums {
		if _, ok := numsMap[n]; !ok {
			numsMap[n] = struct{}{}
			ret = append(ret, n)
		}
	}
	return ret
}

func main() {
	nums := []int{1, 1, 3}
	nums = uniq(nums)
	fmt.Println(nums)
}
```
https://play.golang.org/p/HB0gk4zVF_

- これは作っておくと地味に便利かも
    - uniqueとったIDの配列でデータベースにアクセスするのとか簡単になりそ

# おわりに

ほかにも、「こういうメソッド生やしておくと便利だよ」というものがあれば教えてください。
マネージャーが最低限意識するべき事〜コミュニケーション編〜

# WHY
会社で初めて複数人をマネジメントし、多くの事を得ました。
コミュニケーションには自信があった自分も、もう一歩踏み込んだコミュニケーションを学ぶことができました。
その中で得られた、**最低限意識する事**を記事にしました。

元々社内の自分の後を継ぐマネージャー向けのナレッジに手を加えたものです。

# 目次
・WHYを伝える
・原則メンバーには即レス
・徹底的なフォロー

# WHYを伝える
どんな仕事もWHYが伝わっていないと、大抵メンバーのモチベーションが下がって収集がつかなくなります。
地味な仕事も全力で楽しくやってもらえるよう、ビジョンを示す事がマネージャーの仕事です。
まずは絶対にWHYを伝えましょう。

**どんな仕事も受けてもらえないのは全てマネージャーの責任です。**

# 原則メンバーには即レス
即レスは仕事の基本です。
レスが遅い人はマネージャーとして信頼ができません。
メンバーは**「自分の事は後回し」**と感じてしまいます。
オンライン中は必ず即レスをしましょう。

**▲即レスのコツ**
即レスできない時の理由として「すぐに答えられない」という場合があります。
そういう時は**「◯時までに返信します！」「確認するので少々お待ち下さい！」**等、とりあえず1レスを入れておきましょう。
# 徹底的なフォロー
前提として、**「2割共有」**をしてもらいましょう。
自分の意図をメンバーに伝える事は誰がやっても大変です。
なので、こまめに進捗と内容を確認して**「一緒に作り上げる」**という事を意識しましょう。
特に、最初のうちはできるだけ自分で道筋を示してあげると良いです。

# 仕事には全て期限を設定する
よくありがちな**「あとで見ます！」**は絶対にNGです。
期限を設定しないとお互い仕事を円滑に進めらず、誰も得をしません。

## 仕事を依頼する時
**「◯日の◯時までにお願いします。」**とお願いをして、`1日以上空く場合は1~2日に1回リマインドをする。`
**仕事が間に合わなかったら、メンバーの責任ではなくてマネージャーの責任です。**

## 仕事を受ける時
メンバーから仕事をお願いされたら**「◯日の◯時までにやります。」**と返信をする。
遅れる場合はこちらから事前に連絡をする。
報告なしに期限を過ぎると、**「自分の事を軽く見ている」**と信頼を損なう結果になります。

# 否定から入らない
## メンバーの提案に対して

メンバーの提案に対しては、**「いやそれは無理でしょ」**というように否定から入る事は絶対にやめましょう。
まずは一度受け入れ、例えその案を採用しなくとも、**「その案をよりよくする為にはどうしたら良いか」**を一緒に考えましょう。
結果的に良い案になり採用する事になった場合は、**「メンバーの成果」**としましょう。
メンバーの成果はマネージャーの成果でもあるので、そこでいちいち**「自分がアドバイスしたから良くなった」**等という態度はとらないようにしましょう。
**9割が自分の仕事でも、1割関わったメンバーの成果にしましょう。**

## メンバーのミスに対して
明らかなミスでも、実はメンバーに考えがあって意図的にそうしている場合もあります。
なので、どのようなミスでも否定から入らず**「ここって意図があってこうしてる？だとしたらその意図を教えてほしいです！」**と、まずは話を聞きましょう。
仮に単純なミスでもその後のコミュニケーションの取り方は圧倒的に良くなります。

`※同じミスを何度も繰り返す場合はやや強めに言って調整をしましょう。`
`そうでないと、いつまでたっても同じミスを繰り返してしまう可能性があります。`
# 詰め口調で仕事をしない

特にチャットだと感情が伝わりづらいので気をけましょう。
例えば**「メンバーのミスに対して」**の章の場合で見てみましょう。

```
✕「ここって意図があってこうしてるの？であればその理由を教えてください。」
◯「ここって意図があってこうしている？もしそうならその理由を教えてほしいです！
特に理由がなければこっちの方が良いかなーと思ったので！」
```

最初の方だと、完全に怒っているように感じます。実際に怒っていなくても相手がそう感じてしまえば意味がありません。
「一方的なコミュニケーション」は最悪なコミュニケーションの形です。(コミュニケーションですらない)

後者のように「！」を使用したり、自分の提案も合わせて伝えましょう。
そうする事で、**「一緒に良くしようとしてくれている」**と感じ、モチベーションも上がります。

# 感謝を忘れない
ずっと一緒に仕事をしていると慣れも出てきます。
どんな小さな仕事をしてもらった時でも**「ありがとう」**の言葉は絶対に忘れないようにしましょう。
心を込めて、ありがとうを伝え続けましょう。


# 最後に
本来であれば以下の4つのパターンに分けて考える事ができます。
・ビジョンマネジメント
・戦略マネジメント
・PDCAマネジメント
・メンバーマネジメント
今回は「メンバーマネジメント」にフォーカスした内容を記事にしました。
時間があったら他のパターンも深掘って書いてみようと思います。
NSX for vShield Endpoint と Deep Securityの関係

この記事は [vExperts Advent Calendar 2016](http://www.adventar.org/calendars/1709) に参加中です！

昨日の[三好さん](http://blogs.networld.co.jp/main/2016/12/vmware-esxi-8c58.html)からのバトンを受け継ぎ、本日はトレンドマイクロ 姜(かん)が担当させていただきます。
これまでの内容が皆さんテッキーでしたので、箸休めとして、コタツでミカン食べながら見れるぐらいの緩さで紹介させて頂きます。

#皆さん、NSX for vShield Endpoint（以下、NSX for vSE）ってご存知でしょうか？
|      ![image.png](https://qiita-image-store.s3.amazonaws.com/0/103170/6a7dd348-6c38-b05d-27d0-0624017b88e9.png)   |    なんじゃそれ？    |
|:-----------------|------------------:|:------------------:|
名前だけ見ると、NSX for vSphereっぽいのですが・・・。

NSX for vSEは、VMware社のエコパートナーがリリースしているエージェントレス型のセキュリティを実装するためのコンポーネントで、VMware社が提供しております。
ここで言うエージェントレス型セキュリティとは、各セキュリティベンダーが提供している下記製品となります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/103170/0d9f45b9-ae9b-ed7f-8d06-4d034e73df59.png)
これらの製品は、NSX for vSE（NSX for vSphere）やvCenterと連携する事によりエージェントレス型のサービスやその機能を提供する事が可能となります。

#NSX for vSphere（以下、NSX）とは違うものなの？
じゃあ、NSX for vSEとNSXは何が違うのか？ というと、バイナリ自体は同じもの（NSX）なのですが、提供出来る機能が異なります。
NSXをインストールした後に、ライセンスを何も入れなければ、NSX for vSEとして稼働します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/103170/b5ad530f-d814-6ba0-b3a9-19de67e95443.png)
もう少し具体的な違いとなると、、、

|   | 提供形態 | 機能 | 費用 |
|:-:|:-:|:-:|:-:|
| NSX for vSE  |  vSphereの一部として提供 | 主に、エージェントレス型のサービスと連携（vShield ManagerやvCNSの後継という位置づけ） | 無償(vSphereに包含) |
|   |   |   |   |
| NSX for vSphere  | NSX for vSphereという単体製品として提供  | NW仮想化を実現するためのコンポーネントを提供 （[詳細はこちら](http://blogs.vmware.com/jp-cim/2015/03/nwv01.html)）| 有償（Standard、Advanced、Enterprise） |

このように、NSX for vSEはvCNS(vCloud Networking and Security)の後継として位置づけられ、且つvSphereの一部として提供されるので利用出来る機能もかなり限られています。

また、エージェントレス型製品の機能においてもNSX for vSEとNSXでは提供出来るサービスが変わってきます。
トレンドマイクロのDeep Securityを例にすると、NSXと連携した自動隔離機能（不正プログラムを検知した際に自動的に隔離する機能）はAdvancedとEnterpriseのみ提供可能となります。([参考Blog：拡散防止が最強なのです。](https://vm-fun.blogspot.jp/2016/12/blog-post.html))
![image.png](https://qiita-image-store.s3.amazonaws.com/0/103170/69ebfa6f-915f-6f62-2bda-da1e0f6213f4.png)

#何故NSXではなくて、NSX for vSEを記事にしたのか？
そもそも、NSXがリリースされた当初はNSX for vSEなんて存在してなかったんですよね。
なので、vCNS(旧vShiled Manager)でエージェントレスを利用しているユーザは強制的にNSXに移行するしか選択肢がなかったのですが、その救済処置としてNSX for vSEが提供されました。（おそらく）

それは良い事なのですが、

| ![image.png](https://qiita-image-store.s3.amazonaws.com/0/103170/0469d4f5-49af-fb56-173d-97143eb9fa56.png) | vCNS自体が既にサポート終了(2016年9月19日)しており、テクニカルガイダンスは2017年3月までとなっております。　　　　　　　　　　　　　|
|:-----------------|------------------:|:------------------:|

これがあまり認知されていないという事実があります・・・。

という事は、これから新規にエージェントレス型を利用されるユーザは必然的にNSX for vSE又はNSXで構築する必要があります。
また、既存ユーザに至っては

- あと数か月ちょっとでバージョンアップするのか？
- サポート無しでそのまま使い続けるのか？
- いっその事、使わない（ その選択肢は無しで <(_ _)> ）

といった選択に迫られます。
少しでも皆様の手数を減らすためにも、VMwareさん、SoftBank C&Sさん、トレンドマイクロの3社でここらへんの情報を整理し、下記のような視点でBlogや手順書も公開しておりますので、お時間あればご確認頂ければと思います。

- [サポート終了の背景や関連情報の取り纏め](http://blogs.vmware.com/jp-cim/2016/11/vmware-nsx-for-vsphere-migration-1.html)
- [実装するために必要な構成やライセンス情報](http://blogs.vmware.com/jp-cim/2016/11/vmware-nsx-for-vsphere-migration-2.html)
- [バージョンアップや新規構築に伴う検証や詳細手順](http://blogs.vmware.com/jp-cim/2016/12/vmware-nsx-for-vsphere-migration-3.html)
ループ中にdefaultdictの未定義領域にアクセスすると例外

突然ですが次のコードは例外をスローします。なぜでしょうか?

```py
import collections

ht = collections.defaultdict(int)
ht[0] = ht[1] = 1
x = 2
for ky in ht:
    if ht[ky + 1] == 0: do_something()
    
#=> RuntimeError: dictionary changed size during iteration
```

Python3ではループ中に対象の辞書のサイズが変化すると`RuntimeError`を投げます。`collections.defaultdict`も同じで、上記の例では`ky = 1`のとき`ht[2]`という未定義領域にアクセスした結果、`ht[2] = 0`と定義されてしまいます。そのためループ中に辞書のサイズが変化したとして例外になるのです。

`collections.defaultdict`は未定義領域に問答無用でアクセスできるという点でとても便利ですが、だからといって__「とあるkeyのvalueがすでに定義されているかどうか」のチェックに際して、「とりあえずそのkeyでアクセスしてみて、帰ってきた値がデフォルト値だったら結果的に未定義だったとわかる」という方法は推奨できません___。上記の例がその典型といえるでしょう。ややまどろっこしくとも`if ky in ht`のように、きちんと存在チェックを行いましょう。

ちなみにRubyの`Hash`の場合はどうでしょう? 実は次の例ではエラーにはなりません。

```rb
hash = Hash.new(0)
hash[0] = hash[1] = 1
hash.each{|ky, val| p hash[ky + 100] if hash[ky + 100] == 0}

#=> 0 0
```

Rubyの場合`Hash`の未定義領域にアクセスすると、規定されたデフォルト値を返しますが、___明示的な代入行為が行われない限りは定義されたとみなされず、したがって`Hash`のサイズは変動しません。___未定義領域にアクセスした瞬間にkeyに対するvalueをデフォルト値で定義してしまうPython3の`collections.defaultdict`とは性質がかなり異なります。

なおループ中に`Hash`のサイズが変動するとエラーになるのはRubyも同じです。残念(´・ω・`)

```rb
hash = Hash.new(0)
hash[0] = hash[1] = 1
hash.each{|ky, val| hash[ky + 100] += 1 if hash[ky + 100] == 0}

#=> can't add a new key into hash during iteration (RuntimeError)
```
erdでテキストベースにER図を描く

# 背景
[PlantUML](http://plantuml.com/)はコードで設計図を描くことができて非常に便利なんですが、ER図はサポートしていません。
ということで、コードからER図を生成する方法を探してみました。

# 今回使うもの
[BurntSushi/erd](https://github.com/BurntSushi/erd)
Haskellで作られたER図生成ツールです。PlantUMLのようにGraphvizで図を生成してくれるそうです。

# インストール
[こちら](https://tfrkd.org/log/2016-03-20-plain-text-erd)と[こちら](http://qiita.com/nori3tsu/items/c36591b8091e9ff89ce5)の記事を参考にさせていただきました。
Haskellには`cabal`と`stack`というビルドツールがあるそうです。
stackの方が新しいということなのでそちらを使いました。(正確には、stackはcabalのラッパーツールだそうです)

    $ brew reinstall graphviz --with-pango
    $ brew install haskell-stack
    $ git clone git://github.com/BurntSushi/erd
    $ cd erd
    $ stack init
    $ stack build

気軽に使おうとしましたが、GHCのインストールがはじまって160MBくらいのファイルダウンロードが始まったので、ちょっと導入に抵抗を感じました。
あと、公式のREADMEにかかれている

    cabal install erd
のようなインストールは、依存性の問題が解決できないため使えませんでした。

# 使ってみる

まずはサンプルを生成してみます。`.er`がER図の生成元です。

    $ stack exec erd -- -i examples/simple.er -o simple.png
![simple.png](https://qiita-image-store.s3.amazonaws.com/0/130933/120cadc5-f5d3-d947-d343-442e0f95e329.png)

主キーを表す下線の描画等がうまくいかない問題があったようですが、現在は解決しているようです。
マルチバイトを使った状態でも問題なく描画できました。
![comp.png](https://qiita-image-store.s3.amazonaws.com/0/130933/94f77cb7-4713-8b38-fbec-690d7f5733f5.png)

# `.er`ファイルの書き方
## エンティティ
    [Person]
[ ]で囲うことでエンティティを表現します。

### 属性
    [Person]
    *id
    +name
    age
![test.png](https://qiita-image-store.s3.amazonaws.com/0/130933/97079b72-3f7e-b699-f713-4dfcd6a34f7e.png)

エンティティの下に、そのエンティティの属性を書くことができます。
`*`で主キー、`+`で外部キーを表現できます。
    
## リレーション
    Person *--1 Location
![test.png](https://qiita-image-store.s3.amazonaws.com/0/130933/a7637d4b-0970-f2bd-9b1d-3599187e053d.png)

エンティティ間を、カーディナリティと `--`でつなぐことでリレーションを表現します。
使えるカーディナリティは以下の様になっています。

    Cardinality    Syntax
    0 or 1         ?
    exactly 1      1
    0 or more      *
    1 or more      +

1以外の数字をカーディナリティとして使うことはできないようです。（使う機会はないと思いますが…）
カーディナリティ同士をつなぐ`--`も固定で、`---`だったりすると変換で弾かれてしまいます。

# gulpで変更監視させてみる
[erdwatch](https://github.com/ganoganano/erdwatch)

Atomの[plantuml-viewer](https://atom.io/packages/plantuml-viewer)みたいに、変更監視してコマンド叩いてくれるものが欲しいなと思ったので、gulpを使って手軽に済ませてみました。
`childprocess`使って無理やりコマンドを叩く泥臭い出来上がりなのでいつかちゃんとしたAtomプラグインを作りたいです。

# まとめ
参考にさせていただいた記事のほうでも書かれていましたが、導入が少し面倒という感じがしました。
dockerizeしてしまったほうがよかったかなーと今更思っています。

ER図を書くという観点では、
エンティティとリレーションを分けて書くので、頭の中も整理しやすく結構書きやすいのではないでしょうか。
AWS Lambda (Python) でHipChatに通知をする


## やりたい事

* [HipChat] に通知を投げたい
* [AWS Lambda] \(Python\) でしたい
* [AWS Lambda] で [requests] \(外部モジュール\) を使いたい

## HipChat API Token と ROOM ID

他にも方法がありますが、ここではユーザーの API Token と ROOM ID で通知をします。

![apiaccess.png](https://qiita-image-store.s3.amazonaws.com/0/60131/9669ea7e-3717-46cb-8a7d-f8e2cba8c0b6.png "apiaccess.png")


ROOM ID は 画面右上のMenuから↓で確認できます。 API ID (多分7桁の数字) がそれです。

* Account Settings --> Rooms --> {Room名}

API Token は↓で発行します。

* Account Settings --> API Access

Labelは何でもいいです。 Scopesは ``Send Notification`` を選びました。 Createを押すと41字くらいの英数字のTokenが発行されます。

![token.png](https://qiita-image-store.s3.amazonaws.com/0/60131/63a201e2-1aa6-8026-8a44-983cd5071050.png "token.png")


## スクリプトを書いてアップロードする

普通は書いたスクリプトをAWS Consoleに貼って終わりですが、今回は [requests] (外部モジュール) を使うので、外部モジュールを同梱した ``.zip`` にしてアップロードします。

```shell-session
$ mkdir {your-project-dir}
```

[requests] を ``pip`` でインストールします。 ``-t`` Optionでインストール先を指定します。

```shell-session
$ pip install requests -t {your-project-dir}
```

スクリプト本文をファイル名 ``{your-project-dir}/lambda_function.py`` で保存します。

```py
#!/usr/bin/env python
# encoding: utf-8

import json
import requests

def lambda_handler(event, context):
    # HipChat IDs.
    hipchat_token = u'{ここに41桁の英数字のToken}'
    hipchat_roomid = u'{ここに7桁のROOM ID}'
    
    # :see: https://developer.atlassian.com/hipchat/guide/sending-messages
    def _payload(message):
        return json.dumps({
            u'from': u'FROM',
            u'message_format': u'text',
            u'color': u'random',
            u'message': message
        })
    
    # :see: https://developer.atlassian.com/hipchat/guide/hipchat-rest-api?_ga=1.190068904.2037217368.1478496904
    headers = { u'Content-Type': u'application/json', u'Authorization': u'Bearer %s' % (hipchat_token) }
    
    # send a message to HipChat.
    res = requests.post(u'https://api.hipchat.com/v2/room/%s/notification' % (hipchat_roomid), data=_payload('hello world !'), headers=headers)
    
    return res.status_code
```

スクリプトと外部モジュールを ``.zip`` 化します。

```shell-session
$ zip -r lambda.zip {your-project-dir}/*
```

あとは、この ``lambda.zip`` をAWS Consoleからアップロードしたらいいです。


[HipChat]:https://ja.atlassian.com/software/hipchat
[AWS Lambda]:http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html
[requests]:http://docs.python-requests.org
Gebでtextやtitleでのエレメント取得は遅くなる！？

# はじめに

これは[Geb Advent Calendar 2016](http://qiita.com/advent-calendar/2016/geb)の13日目の記事です。
前日は[@setoazusa](https://twitter.com/setoazusa)さんの[Gebでインフラをテストする。](http://blog.fieldnotes.jp/entry/infrastructure-test-by-geb)でした。いやはや昨日はいぶし銀なエントリーでしたね。
今日はGebのパフォーマンスがらみのお話です。

# tl;dr
textやtitleでエレメント取得すると、古いバージョンでは書き方次第で速度劣化を引き起こす可能性があったが、バージョン1.0以降を使っていれば基本的には問題ない。

# Gebでtext, titleでエレメント取得すると遅い？
[メーリングリスト](https://groups.google.com/d/msg/geb-user/lX169KiTLeo/EuUOqu9_dmoJ)などで時々話題に出る内容です。バージョンによって答えが変わってくるので注意が必要です。


## text, titleでの取得は遅いの？
バージョン1.0までは遅かったです。この件については中の人が[メーリス](https://groups.google.com/d/msg/geb-user/lX169KiTLeo/EuUOqu9_dmoJ)でコメントしています。意訳しますと

```
textで取得するときは、可能な限りCSSセレクタでエレメントを限定的に指定してください。
なぜかというと、textでの取得はCSSでサポートされてないからです。
Gebでそれをするときに何が起きるかというと、そのセレクタにマッチするエレメントを全て取得してきて、
それらをイテレートしてテキストをチェックします。
テキストでのエレメント取得はワイヤプロトコルの呼び出しです。
それはつまり、イテレートする要素が増えれば増えるほど、ワイヤの呼び出しも増えるということです。
一般に、テキストでの取得は便利ですが遅くなります。
そのため、可能であれば避けてください。
```

というわけで、バージョン1.0が出る前は実際に遅くなる状態でした。というわけで、[『Selenium実践入門』](http://gihyo.jp/book/2016/978-4-7741-7894-3)にはその旨が注釈で記載されていたりします。

## 遅かった時代の解決策
というわけで、textやtitleでエレメントを取得する際は、<b>可能な限りCSSセレクタに寄せて書け</b>と案内されていました。例えばこんな感じ

```groovy
$("div", title: "foo") // NG:遅くなる書き方

$("div[title='foo']") // OK:なるべくCSSセレクタに寄せる
```

## バージョン0.11.0での改善
バージョン1.0で、上記のNGの書き方をしても、可能な限りCSSセレクタに寄せるようにコンパイルする、という修正が入りました（[参考](https://github.com/geb/issues/issues/280)）。そのため、上記で実質的なパフォーマンスの違いは出なくなりました。

## バージョン1.0で安定
バージョン0.11.0では、上記の修正に伴う[バグが出ていた](https://github.com/geb/issues/issues/390)のですが、それもバージョン0.12.1で[修正](https://github.com/geb/geb/commit/45df5cfbd2087e686ab8452f453d67ea7702acb9)されています。それらはバージョンの1.0に引き継がれているので、バージョン1.0を利用していけば問題なく利用できると思います。

# まとめ
Gebのバージョン1.0使いましょう。
ジェネレータを実装する

# ジェネレータを実装する

[Julia advent calendar 2016](http://qiita.com/advent-calendar/2016/julialang) 13日めの記事です。 簡単なジェネレータを書いてみました。初心者なので、間違い・もっと良い書き方があれば教えてください。※頂いたコメントを元に修正しました。

## ジェネレータ

リストのように最初からすべての要素を用意するのではなく、必要な時に生成していくもの。

## listの中身を`+2`した文字列を生成するジェネレータ

~~~julia
function main()
    list = [1,2,3,4,5]
    generator = (syori(i) for i in list)
    for i in generator
        println(i)
    end
end

function syori(i)
    v = string(i + 2)
    return v
end
main()
~~~

### `syori()`
listの各要素にかけたい処理。複雑な処理でも関数を作ってGenerator式に渡せば綺麗に書ける。

### `generator = (syori(i) for i in list)`

Generator式でジェネレータを作成。for文などで要素を取り出せる。

## listの中身を`+2`した文字列を生成する~~ジェネレータ~~ Task
以下の実装はPythonのyieldを使用したジェネレータと似た動きをする。(再利用できない)
基本的には上記のGenerator式を使ったほうが便利そう。

~~~julia
function main()
    list = [1,2,3,4,5]
    for i in @task generator(list)
        println(i)
    end
end

function generator(list)
    for i in list
        v = "$(i + 2)"
        produce(v)
    end
end
main()
~~~

###`produce()`

ループを一時停止して生成されたvの中身を返し、ループを再開する。

### `@task`
これを付けてfor文などで回すと要素を取り出せる。
Node-REDでノードを整列する

#ノードを整頓したい

Node-REDでノードをズラズラならべると、こんな感じで少々かっこ悪く並んでしまいます。

<img width="841" alt="不揃いなノードの配置" src="https://qiita-image-store.s3.amazonaws.com/0/130638/5f20c7e6-0f0c-c501-0e70-095fd20ff5e3.png">

しかし、Node-REDにはノードを整列する機能がちゃんと用意されています。Node-REDのメニューから、[View]の中の[Show Grid]と[Snap to Grid]をONにします。

<img width="524" alt="グリッドにスナップさせる設定" src="https://qiita-image-store.s3.amazonaws.com/0/130638/a4b35027-43c4-4546-b247-f0e04eb91dc0.png">

そうすると背景にグリッド線が表示されます。

<img width="815" alt="グリッド線が表示された" src="https://qiita-image-store.s3.amazonaws.com/0/130638/f7b43610-2bd3-3582-1c50-d1b21e290a7e.png">

あとはノードの配置をずらして整頓すれば、綺麗に並びます。

<img width="830" alt="整列後のノード" src="https://qiita-image-store.s3.amazonaws.com/0/130638/719d8467-cc01-3062-51b9-0c826bbbd2e1.png">

整頓するだけなら[Show Grid]は不要ですけど、グリッド線があったほうがわかりやすいですよね。このように多数のノードが並ぶ時でも美しく整列できますよ。

<img width="987" alt="多数のノードが綺麗に並んでいる例" src="https://qiita-image-store.s3.amazonaws.com/0/130638/278066c5-0e3c-2685-ba10-1549bd7c4e19.png">

P.S.
なおegplntさんが[Node-RED小ワザ集](http://qiita.com/egplnt/items/aca359fc69deb2fb6dff)で簡単に説明を記述されていますが、egplntさんに伝えたのは自分ということもあり[Node-REDアドベントカレンダー](http://qiita.com/advent-calendar/2016/nodered)向けに図入りで記述しました。
ごめんよ、まだ僕にはHLSを作れるツールがあるんだ。こんな嬉しいことはない。ShakaPackagerでmp4からHLSを作る。

## ようやく
ネクストスケープ 配信事業本部 Advent Calendar 2016 もコンプリートの目が出てきたのですが
まだ空いている日が有るので、例のごとく小ネタで埋めます。
相変わらずの、誰得な内容です。

## HLSって・・・
みんな何のツールで作ってるんですかね？Macの環境が有るならそれ用のツールが有りますけど、
WindowsやLinuxの人はやっぱりffmpegで作ってるんでしょうか。それともbento4でしょうか。

実はGooleがMPEG-DASHのパッケージャとして開発をしている ShakaPackager にもいつの間にやらHLSの作成機能が実装されていたりします。
しかも、Widevineでの暗号化まで出来てしまうので結構お得です。再生できるプレーヤーを用意するのが大変ですが。
先日Windows用ShakaPackagerをビルドする記事も書いたので、今回はShakaPackagerを使ってHLSを作ってみようと思います。

## 早速作ってみる（Windows向け）

単純にHLSをmp4から作るだけなら

```
packager input=some.mp4,stream=video,segment_template=video_$Number$.ts,playlist_name=video_playlist.m3u8 ^
input=some.mp4,stream=audio,segment_template=audio_$Number$.ts,playlist_name=audio_playlist.m3u8,hls_group_id=audio ^
--single_segment=false ^
--hls_master_playlist_output="master_playlist.m3u8"
```
こんな感じでしょうか。

これに、Widevineの暗号化オプションを付けると

```
packager input=some.mp4,stream=video,segment_template=video_$Number$.ts,playlist_name=video_playlist.m3u8 ^
input=some.mp4,stream=audio,segment_template=audio_$Number$.ts,playlist_name=audio_playlist.m3u8,hls_group_id=audio ^
--single_segment=false ^
--hls_master_playlist_output="master_playlist.m3u8" ^
--enable_widevine_encryption ^
--key_server_url "https://license.uat.widevine.com/cenc/getcontentkey/widevine_test" ^
--content_id "3031323334353637" ^
--signer "widevine_test" ^
--aes_signing_key "1ae8ccd0e7985cc0b6203a55855a1034afc252980e970ca90e5202689f947ab9" ^
--aes_signing_iv "d58ce954203b7c9a9a9d467f59839249"
```
こんな感じですかね。
Widevine用のオプションの値はテスト用のデフォルト値です。Widevineのバートナーの方なら、この辺の値は
持っていると思いますので書き換えて下さい。
※ネクストスケープはWidevineの認定パートナー企業です。この記事を書いている人は認定パートナーの一人です。

この暗号化は**AES-CTR方式**でのWidevine暗号化なので、これを**AES-CBC方式**でのWidevine暗号化に変えると

```
packager input=some.mp4,stream=video,segment_template=video_$Number$.ts,playlist_name=video_playlist.m3u8 ^
input=some.mp4,stream=audio,segment_template=audio_$Number$.ts,playlist_name=audio_playlist.m3u8,hls_group_id=audio ^
--single_segment=false ^
--hls_master_playlist_output="master_playlist.m3u8" ^
--enable_widevine_encryption ^
--key_server_url "https://license.uat.widevine.com/cenc/getcontentkey/widevine_test" ^
--content_id "3031323334353637" ^
--signer "widevine_test" ^
--aes_signing_key "1ae8ccd0e7985cc0b6203a55855a1034afc252980e970ca90e5202689f947ab9" ^
--aes_signing_iv "d58ce954203b7c9a9a9d467f59839249" ^
--protection_scheme cbcs
```
という感じです。これで、**今の所ほぼ誰も再生できない**コンテンツが出来上がりました。

ほんと誰得なんだよ・・・
phina.jsでGamePadを使う

この記事は[phina.js Advent Calendar 2016](http://qiita.com/advent-calendar/2016/phinajs)１３日目の記事です。
前日→[Flowを使った非同期処理の基本 by alkn203さん](https://alkn203.github.io/blog/2016/12/12/phina-advent-12th/)

#ついに念願のXBOX360コントローラをPCにつなぐレシーバーを手に入れたぞ！
むしろなんで今やっと買ったのよ、という感じですが、これでＰＣで[ダラバー](http://darius.jp/dbcs/)や[デススマ](http://store.steampowered.com/app/314180/?l=japanese)や[大復活](http://store.steampowered.com/app/464450/?l=japanese)をキーボードでやる苦痛から解放されるぜイエーイ。いやエスプレイドをキーボードでやってガラ婦人まで行けるのでそんな苦痛でもないのですが。
しかし[まほシュー](https://freegame-mugen.jp/shooting/game_5344.html)はキーボードでやってて、オールクリアどうしても出来なかったのが、パッドを導入してあっという間にオールクリア出来ました。
やっぱりパッドだと操作が楽ですね。

という事で、あまりにも嬉しかったのでphina.jsでgamepadを使ってみました。

#phina.GamapadManager
phina.jsではゲームパッドをphina.GamapadManagerで簡単に扱う事が出来ます。

```JavaScript:GamepadManagerの定義
var gamepadManager = phina.input.GamepadManager();

//Update内等で毎フレーム呼ぶ必要があります
gamepadManager.update();
```

```JavaScript:GamePadの取得
//GamePad１つ目
var gamepad_1 = gamepadManager.get(0);

//GamePad２つ目
var gamepad_2 = gamepadManager.get(1);
```

```JavaScript:キーの状態取得
//十字キーの上が押されているか
var up = gamepad_1.getKey("up");
//Ａボタンが押されているか
var A = gamepad_1.getKey("A");
//L1ボタンが押されているか
var L1 = gamepad_1.getKey("L1");
```

```JavaScript:アナログスティックの状態取得
//二次元ベクトルで格納されてます。
//左側のアナログスティック
var left = that.gamepad_1.getStickDirection(0);
//右側のアナログスティック
var right = that.gamepad_1.getStickDirection(1);
```

#テストコード
http://runstant.com/minimo/projects/GamepadTestSample
左右でトマピコを移動、上キーまたはAボタンでジャンプします。
左側のアナログスティックでも同様の操作が可能です。
取得キーコードの違いから、Chrome以外は正しく動きません。
っていうか、ブラウザ毎でGamepad APIの挙動が違うのなんとかしてください。

#おしまい
実際のゲームにも導入したいですが、ブラウザ間の互換性とか、キーコンフィグ画面作るとか考えるとちょっと億劫かなーって感じがしますね。汎用で使えるコンフィグ画面を作りたい所です。
自分の環境だとこんなだったぜー、見たいな事があったらコメント頂けると嬉しいです。
perlのコードになっているgifファイル

# perlのコードになっているgifファイル

去年は[D言語のコードになっているepsファイル](http://qiita.com/amama/items/a8788287c6c57872169b)を書いたのでよろしくな.

環境

- This is perl 5, version 24, subversion 0 (v5.24.0) built for x86_64-linux-thread-multi
- Version: ImageMagick 6.9.6-6 Q16 x86_64 2016-12-02 http://www.imagemagick.org
- DMD64 D Compiler v2.072.1

## gifファイル
![dman_3.gif](https://qiita-image-store.s3.amazonaws.com/0/105410/e437aaee-7a02-88e4-e38f-36f2b344c373.gif)
qiitaの環境がよくわかりませんが,アップロード時にファイルに変更があるかもしれないので,gifファイルを生成するD言語のソースも書きました.

```d:dman.d
import std.stdio,std.base64;void main(){writeln("GIF89a#\x00X\x00\xf1\x01\x00\x00\x00\x00\xff\xff\xff\xff$$\x00\x00\x00!\xfe%\n;use MIME::Base64;BEGIN{$s=<<'END';");write(cast(string)Base64.decode("ACwAAAAAIwBYAAAC/oyPqcvdAJ1UEARr8JQ65j1pFyKCSSmW5oGS69J+L8xe1UzLmTpXqoezOYAvIsO4QR55D+YSpOQ4WdPhNAplAn3c0A8DEYjH41uTBBYAyOxy1LNVt+dipSVed6/p6pM5U1bHwtdHZbSnhkIWVrbjOFinKHixKPRIGbnDmLKIkpbJ9YfZ6DcaigjGSOqHmljR6NPG8yrnYxPBxaYVticaKrd6Ehh8y6sLMzxp2HtMkVzonEcMKK0sXA0NCTwNiZhNvW197f3z/E2CXY593l15HX6VHg0/JI++7sTsru3NTt0vid4RfPPIPSB4TyCycOJaccPUr2GyWfqaJUTlxxwxlofffs1Rt80joUQFR/IRxc+krF4lVbrhxnEkLXHt6Ih8CPGUKpsHGbrEQimiSaBBP8rK5MXmyioUdOoMQqEpVDQwmHqpOtUSVqhYiFqREoSo161gi1gdWyqJ1RNZejBFG7Ws269c6YbdxcpKhyc1dLB1hIRIjL81vlzq60Iq2zdxGyM+4jix5ByEK/s19CDy47Gh9FYpAAAh/v8K"));write(q"[END
$_=q[print q[import std.stdio,std.base64;void main(){writeln("GIF89a#\x00X\x00\xf1\x01\x00\x00\x00\x00\xff\xff\xff\xff$$\x00\x00\x00!\xfe%\n;use MIME::Base64;BEGIN{$s=<<'END';");write(cast(string)Base64.decode("].encode_base64($s,'').'"));write(q"[END
$_=q['.$_.'];eval};]"~"#\x00;");}';exit];eval};]"~"#\x00;");}
```

これをdmdでコンパイルして実行すると,標準出力にバイナリが出力されるので,それをファイルに保存すれば,perlのコードになっているgifができます.

```sh
dmd dman.d
./dman > dman.gif
file dman.gif
perl dman.gif
```

`perl dman.gif`で標準出力に何が出力されましたか?
上記のD言語のソースと全く同じものが出力されたと思います.
もしもエラーが出たり一致しなかった場合は,ごめんなさい,僕がコード生成をミスったか,windowsのCR問題か,落としたgifが間違ってるか,その他環境の差異かのどれかだと思います.

なので,このgifファイルは,**「『このgifファイルを出力するD言語のソース』を出力するperlスクリプト」になっているgifファイル**になります.

詳しい説明は面倒なので後で追記します.
興味のある人は適当なテキストエディタでdman.gifを覗いてみてください.
Scrapy de Redis

[Scrapy](https://scrapy.org/)でRedisを使う場合に
[Scrapy-Redis](https://github.com/rolando/scrapy-redis)が有名です。

どうRedisが使われているかを少し書きます。

リクエストのキューと重複チェックのリストがRedisに格納されます。

## リクエストのキュー
「[spider name]:requests」という名前のzset型
http://scrapy-redis.readthedocs.io/en/stable/_modules/scrapy_redis/scheduler.html

Parameters込みのURLが並んでいます。
[Request objects](https://doc.scrapy.org/en/latest/topics/request-response.html?highlight=request#request-objects)

## 重複チェックのリスト
「[spider name]:dupefilter」という名前のset型

重複するrequestsを排除するためにfingerprint(Hash値?)を持っています。

## ScrapyのArchitecture overviewとRedis
![image](https://qiita-image-store.s3.amazonaws.com/0/73615/1252dc5b-10fd-61e4-b96e-6b49f603b1f9.png)

```python
SCHEDULER = "scrapy_redis.scheduler.Scheduler"
```

という設定でSchedulerがRedisを使います。


## 最後に
なんらかの原因でScrapyが止まってしまっても、
リクエストのキューが残っていれば、そこから再開され、
重複チェックのリストもあれば、
既にクロールしたURLにはアクセスせずに続けることができます。
VR童貞からVR素人童貞へのススメ_Untiy編

この記事は[さいたまげーむすAdvent Calendar 2016](http://qiita.com/advent-calendar/2016/saitamagames)の13日目です。

唐突ですが、今年は、VR元年ですね！

僕も、今年は、VRの私用で開発をする機会が割とあったので、ほんとにVRやったことない初心者向けの方への記事を書きます。

ちなみにUnity5.4系からの話を書きます。

# 目次
* Oculus Rift CV1
* HTC Vive
* Google CardBoardなど、スマホデバイス

# Oculus Rift
UnityでVRをやるのに一番楽なのは、Oculus Rift CV1 でございます。
DK2の動作方法は、面倒なのと、需要がこれからなくなると思うので書きません。

## Unity以外の設定
Oculus Rift CV1を買うPCにケーブルをぶっさす。
対象PC:GeForce GTX 1000番台を搭載したPC、[参考](https://www3.oculus.com/en-us/oculus-ready-pcs/)

## Unityの設定
メニュービューから、「File→BuildSettings→PC,Mac&Linux Standalone→Player Settings」

![gazou1.PNG](https://qiita-image-store.s3.amazonaws.com/0/102634/a05a3b3e-0db1-ecf7-dbbe-08cecd5fd66e.png)

![2016-12-10 (4).png](https://qiita-image-store.s3.amazonaws.com/0/102634/1713d998-0307-5307-e351-63d0205003ab.png)

Vitual Realty Supportのチェックのボタンを入れる

![gazou4.png](https://qiita-image-store.s3.amazonaws.com/0/102634/e2920b44-016a-0e82-e9d9-fbcdda36d3c2.png)

再生するだけ

# HTC Vive
## Unity以外の設定
[スチームのアプリをDL](http://store.steampowered.com/about/)
SteamVRを起動

## Unityの設定
Oculus CV1 と Vitual Realty Supportのチェックのボタンを入れるまでは同じ、「Vitual Realty SDKs」に「OpenVR」を追加

![gazou6.PNG](https://qiita-image-store.s3.amazonaws.com/0/102634/fdd979c6-8f00-359d-2dc7-5cdbf5aabdfc.png)

OpenVRを一番上にあげる

![gazou7.PNG](https://qiita-image-store.s3.amazonaws.com/0/102634/bee16b64-8182-dd2e-8515-059a85c1db75.png)

# Google CardBoardなど、スマホデバイス
## Unity以外の設定
DayDreamは、わからないので、書きません。
### デバイス
対象スマホ：ジャイロセンサーが入っているスマホ、[参考](http://taovisor.com/hard/hawei-p8lite/)
### 環境
[Unityで作成したゲームをAndroidアプリ向けにビルドする方法【初心者向け】](https://techacademy.jp/magazine/2229)
Androidのビルド環境を整える。
* JDKのインストール
* Android SDK（面倒なので、AndroidStudio入れる方がいい。）

## Unityの設定
### Androidのビルド環境
#### Unityでのビルドツールを入れておく
Unityで「File→Build Setting→Android」を選択して、Androidのbuild環境を入れておく。
#### JDKとSDKのパスを通す
Unityのメニュービュー「Edit→Prefrenceｓ→ExternalTools→Android」でSDKとJDKのパスを通す。（パスの例、SDK:「C:/Users/【ユーザー名】/AppData/Local/Android/sdk」、「C:\Program Files (x86)\Java\jdk1.8.0_66\」）
#### ビルドの詳細設定
メニュービューから、「File→BuildSettings→Android」を表示
`Identification` の `Build Identifier` で「com.Company.ProductName」のデフォルトの設定を書き換える（「com.」から先を書き換えたら大丈夫）
`Minimum API Level` の設定を最低に落としておくと通りやすい（Android2.3.1 API Level 9）

で準備完了です。

あとは、ビルドするのみ～


ということで、手軽でリーズナブルなVRライフを～
Visual Studio Codeを用いたC++ STLデバッグの方法（※2016/12/23追記）

Visual Studio Code(VSCode)を用いてC++のStandard Template Library(STL)をデバッグする方法について。

実はすでにWeb上には情報がありますが、なぜかGoogle検索で見つけられなかったので自分で書いてみます。
元ネタはこちらの、GithubのIssue Listにあります。
https://github.com/Microsoft/vscode-cpptools/issues/69
Visual Studio CodeはオープンソースでGithub上で管理されているため、バグリストもGithubに載っているようです。
[^1]

# はじめに
本稿は、STLを用いたC++をg++でコンパイルし、gdbでデバッグするVSCode環境を想定しています。
そのためには、まずVSCodeやプラグインのC/C++ for Visual Studio Codeをインストールしなければならないのですが、それはこのあたりを参考にして下さい。
http://gabekore.org/vscode-c-windows

なお、筆者の環境は以下のとおりです。
- Ubuntu 16.04.1 LTS
- g++ 5.4.0
- gdb 7.11.1
- Visual Studio Code 1.7.2
- C/C++ for Visual Studio Code 0.9.2
※2016/12/23追記
C/C++ for Visual Studio Codeは、0.9.3からデフォルトの設定でSTLのデバッグができるようになりました。下に記した「launch.jsonに記述する方法」の追加記述は、0.9.3でlaunch.jsonを新規作成する場合は不要となります。しかし、0.9.2以前のバージョンで既にlaunch.jsonを作成してしまっている場合は追加記述が必要です。

# 問題
さて、VSCodeを使ってC++をデバッグできる環境が整ったとします。
STLを使ったコードを書いていざ動かそうとすると、変数の中身が読めないことに気づきます。
（添付の画像だと、aというvector配列の中身が表示されていません。）
![vsc.PNG](https://qiita-image-store.s3.amazonaws.com/0/100/c73b8905-9715-2f41-2022-bf07771aaa0c.png)

# 解決策
前述のissue listによれば、gdbのpretty printingを有効にすれば中身が見えるらしいのですが、動作が遅くなるためかデフォルトではオフになっているようです。VSCodeが自動的に判別してくれるといいのですが現状ではそうなっていません。
そこで解決策としては次の２通りがあります。

## debug consoleを用いる方法
その場ですぐに見たい場合には、debug consoleに"-exec -enable-pretty-printing"と入力してreturn押下します。
![VSC2.png](https://qiita-image-store.s3.amazonaws.com/0/100/e24b01e6-e7bf-7fcc-b6b7-ce70f4c7cd2f.png)
すると、変数の中身が読めるようになっているはずです。

## launch.jsonに記述する方法
上の方法だと、VSCodeを起動するたびにpretty-printingの有効化が必要になります。
最初から有効にしておきたければ、launch.jsonに記述しておきます。
![VSC3.PNG](https://qiita-image-store.s3.amazonaws.com/0/100/43183568-98bd-01c4-501b-a511f1b5bbf3.png)
（launch.jsonを作成するには、F5 を押して、環境の選択 > C++(GDB/LLDB)。)

[^1]: マイクロソフトのテクニカルエバンジェリストである戸倉彩さんにtwitterで質問した際、このissue番号を教えていただきました。
StealとForce

# 直交するStealとForceの軸

ディスクの一部を適宜メモリに写し取って編集するページモデルのデータベースの設計上の選択肢として、**Steal**と**Force**の2軸がある。

## Steal

トランザクション側の都合で任意のページをメモリから追い出せるシステムの場合、それを「**Steal**」と呼ぶ。（任意といっても流石に**WAL**のルールに違反はできないが）
それはつまり、トランザクションが認知しないタイミングでも任意のページが他のトランザクションの手によってメモリから追い出される事を意味するので、書き換わった(ダーティな)ページが未コミットのまま永続化される可能性がある。なのでリカバリ時にそのための配慮（Undo操作）が必要となり複雑度が増す。トランザクションからすると自分が触っているページが「盗まれる」ので**Steal**と呼ぶのだろうと思う。

**Steal**を許さないシステムの場合（**No-Steal**と呼ぶ）トランザクションは未コミットのデータを永続化できない。
そのシステムでは**メモリに入りきらないテーブルに対してWHERE句無しのUPDATE文は永久に成功しない。**
また、他のトランザクションが触っているからという理由でメモリからページを追い出せないので、ロングトランザクションが走るとそれだけ他のトランザクションが好きなように使えるページが減る。性能・機能の両面から**Steal**が望まれる事が多く、実際のところMySQLやPostgreSQLなど有名ドコロのDBはみんな**Steal**に分類される。

## Force

トランザクションが完了時にそのトランザクションが更新した内容をディスクに反映させるシステムの場合、それを「**Force**」と呼ぶ。
それはつまり、トランザクションが完了する度に大量のランダムIOが走る事を意味するのでパフォーマンスに多大な影響を与える。
**Force**する場合、完了したトランザクションは必ずディスクに全て反映されているのでリカバリ時のRedoが不要になる（リカバリ時の挙動に付いては後日詳しく）。
コミット時に複数のページを更新する途中で電源が落ちた場合、ディスク上のDBから一貫性が失われてしまうのでUndoするか、もしくは複数のページを一括で更新するシャドーページング等のテクニックを使う事になる。
性能の観点から**Force**を選択しないシステムの方が近代ではよく見かける（昔のDBでは割と**Force**していたようだが）。有名ドコロのDBはみんな**No-Force**に分類される。

これら2つの軸は直交しており、DBを設計する際には**StealかNo-Stealか**という観点と**ForceかNo-Forceか**という点はそれぞれ独立している。つまり四象限どこかを選ぶ事になる。

# 2軸とログに望まれる情報

前述したように、**Steal**と**Force**をどう選ぶかによってログに求められる情報も変化する。

トランザクションシステムを設計する際に、**Steal**を選んだ場合、未コミットのデータが書き込まれる可能性があるのでUndo情報が必要となる。
**No-Force**を選んだ場合、コミット済み（つまりクライアントに完了を報告した）トランザクションがディスク上のB+ツリー等に反映されていない可能性があるので、Redo情報が必要となる。
**Force**を選んだ場合であってもディスク上の複数ページ更新がAtomicに行われていない場合はディスク上のデータの一貫性が取れないのでUndo情報が必要となる。

そのあたりの情報をまとめたのがTheo HaerderとAndreas Reuterらの[Principles of Transaction-Oriented Database Recovery](http://dl.acm.org/citation.cfm?id=291)である。
以下の図はこの論文から引用する。

![Classification scheme for recovery concepts](https://qiita-image-store.s3.amazonaws.com/0/1716/086ff7e1-04f2-cc16-9d02-b9ea72184744.png)

Propagation Strategyは複数のページ更新をアトミックに行えるか否か。
Page ReplacementがStealするか否か。
EOT(End of Transaction) ProcessingがForceするか否か。
Checkpoint Schemeは後日解説する。

そして一番下にその当時でのDBシステムの実施例が書かれている。
IMS/FPは歴史の古いインメモリDBで、グループコミットを実装したDBとして先日のアドベントカレンダーにも書いた。
当時はこのように多様性に富んだ選択が行われていたが、結局現代のWebの世界で広く使われているDBの多くは`¬Atomic ∧ Steal ∧ ¬Force ∧ fuzzy`の組み合わせであり、その組み合わせのDBを作る際のベストプラクティスをまとめた金字塔がこの論文の9年後に公開された[ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging](http://dl.acm.org/citation.cfm?id=128770)である。
この論文はディスクベースなDBの設計を語る上で欠かせない重要な知見が詰まっているのでおいおいこのアドベントカレンダーで話していく。
サーバ侵入について(超初級)

#  はじめに
現在、サーバ侵入について勉強し始めたので、
今回はサーバ侵入について軽く話したいと思います。

# 注意
この記事以外でも同じですが、
サーバ侵入の学習は自分のPCやサーバのセキュリティ意識、
技術を高めるものであるため、他のPCやサーバのデータを取得し悪用、
または第三者に提供することは憲法に違反するのでご注意してください。
この記事の内容では具体的な内容はないので大丈夫ですが。

# なぜサーバ侵入を勉強しているのか
サーバ侵入について勉強しているのは、サーバのセキュリティを学習する上で
攻撃者の手口を知っておきたかった理由と、
単にどうやってサーバに侵入するのか興味があったからです。

# サーバ侵入手順
じゃあ、実際にどうやってサーバ侵入しているのか簡単に説明したいと思います。

**1. ターゲティング(事前調査)**
攻撃者が対象とするサーバを選ぶにあたって、
最初にサーバに脆弱性があるかどうかサーバ自身の情報を事前に調査する必要があります。
手法としてはポートスキャンやバナーチェックを行ったりします。
これによりOSの特定(推測)やバージョン情報などを知ることができます。

**2. 脆弱性の特定**
サーバに関する情報を入手したら、どのような脆弱性があるのか特定します。
脆弱性は最新のセキュリティ情報を元に特定できます。
正直、今の私にはこの脆弱性の発見はまだまだできませんが。

**3. 対象サーバへの侵入**
サーバの脆弱性を特定したら、その脆弱性をついた攻撃プログラムを探します。
この攻撃コードの入手はWebサイトなどで入手することができます。
既存の攻撃コードをそのまま使うのもいいですが、
自分の目的に合わせて手直しをするのもいいです。
攻撃コードの準備ができたら、コンパイルして実行します。
すごいバッサリとした説明になりましたが、
自分もまだ勉強中のため今回は詳細な説明は省かせていただきます。

**4. サーバ侵入後**
サーバに侵入後は管理者権限を奪います。
これにより自分のアカウントIDを作成できたり、サーバ上に保管されている
情報を自由に閲覧、編集(改竄)することなど様々なことができます。
また、侵入したサーバを踏み台にして異なるサーバやシステムなどに
侵入するなど再度サーバに侵入したい場合は、バックドアを仕掛けます。
バックドアを仕掛けることで再度サーバに侵入するのが楽になります。

# 終わりに
本当に軽くサーバ侵入の手順を説明しましたが、この内容はあくまでも参考程度のものでありますのでサーバ侵入に興味を持ってくれたらとても嬉しいです。
私もこの記事を書くうちに早く勉強を再開したいと思いましたw
また機会がありましたら次はもう少しまともな記事を書けたらと思います。
{listviewer}パッケージでリスト型データを可視化してみよう

この記事は[RStudio Advent Calendar 2016](http://qiita.com/advent-calendar/2016/rstudio-ide)の13日目の記事です。

## list型データの内容を確認するには

Rを使っていると，list型データによく出会います。中々に柔軟なデータ構造を持つことができるので，色々なところで出力として用いられています。ただし，APIなどで取得した大きなデータ等だと「一体どんな内容なのか」とか「あのデータってどこにあるんだ」という感じで，苦労することが多いかと思います。

今回は，{listviewer}というパッケージを利用して，リスト型データを可視化してみます。

### 今回使用するサンプル

今回使用するlist型データとして，{DiagrammeR}パッケージで生成したものを使用してみます。このコードは[本家のこちらのページ](http://rich-iannone.github.io/DiagrammeR/graphviz_and_mermaid.html#mermaid-sequence-diagrams)を利用して持ってきました。

```r
library(DiagrammeR)

m <- mermaid("
sequenceDiagram
  customer->>ticket seller: ask ticket
  ticket seller->>database: seats
  alt tickets available
    database->>ticket seller: ok
    ticket seller->>customer: confirm
    customer->>ticket seller: ok
    ticket seller->>database: book a seat
    ticket seller->>printer: print ticket
  else sold out
    database->>ticket seller: none left
    ticket seller->>customer: sorry
  end
")
```

### オーソドックスな確認方法

Rには`str()`というコマンドがあり，これを使えばそのRオブジェクトの構造を確認できます:

```r
str(m)
```

出力は，以下のようになります:

```
List of 8
 $ x            :List of 1
  ..$ diagram: chr "\nsequenceDiagram\n  customer->>ticket seller: ask ticket\n  ticket seller->>database: seats\n  alt tickets available\n    data"| __truncated__
 $ width        : NULL
 $ height       : NULL
 $ sizingPolicy :List of 6
  ..$ defaultWidth : NULL
  ..$ defaultHeight: NULL
  ..$ padding      : NULL
  ..$ viewer       :List of 6
  .. ..$ defaultWidth : NULL
  .. ..$ defaultHeight: NULL
  .. ..$ padding      : NULL
  .. ..$ fill         : logi TRUE
  .. ..$ suppress     : logi FALSE
  .. ..$ paneHeight   : NULL
  ..$ browser      :List of 4
  .. ..$ defaultWidth : NULL
  .. ..$ defaultHeight: NULL
  .. ..$ padding      : NULL
  .. ..$ fill         : logi FALSE
  ..$ knitr        :List of 3
  .. ..$ defaultWidth : NULL
  .. ..$ defaultHeight: NULL
  .. ..$ figure       : logi TRUE
 $ dependencies : NULL
 $ elementId    : NULL
 $ preRenderHook: NULL
 $ jsHooks      : list()
 - attr(*, "class")= chr [1:2] "DiagrammeR" "htmlwidget"
 - attr(*, "package")= chr "DiagrammeR"
```

まあかなりややこしい構造です。もちろんRStudioの**Environment**で表示させても，同じもの出てきます。正直見づらいです。

## {listviewer}パッケージ

[{listviewer}パッケージ](https://github.com/timelyportfolio/listviewer)は，Rによる可視化で有名なtimelyportfolio氏が開発したパッケージで，[jsoneditor](https://github.com/josdejong/jsoneditor)というjsライブラリを，Rの{htmlwidgets}パッケージを利用して導入したものです。

CRANにあるので，インストールはいつも通りでOKです:

```r
isntall.packages("listviewer")
```

### 実行は`jsonedit()`関数

では実際に使ってみます。先ほどのを`jsonedit()`関数に投げると，以下のような感じになります:

```r
jsonedit(m)
```

![listviewer01.png](https://qiita-image-store.s3.amazonaws.com/0/35118/865a2c5e-3a1e-7e0f-6334-2250ea6b179c.png)

RStudioのViewerに，まさにそれっぽいのが表示されるかと思います。

### 使い方

もうほぼ見たまんまです。**三角形をクリックしていけば深い階層のものが表示**されていきます。あと，**検索窓にキーワードを入力すると探してきてハイライト表示&ジャンプ**できるようになります。**フィールド名でも値名でも検索**してくれるはずです。

![listviewer02.png](https://qiita-image-store.s3.amazonaws.com/0/35118/013c873d-c0c9-5b7c-917c-c2dfe25b4afe.png)

あと，データの編集も可能みたいですが，個人的にデータをいじる場合GUIではしたくないので検証しません。

ちょいネタですが，list型でいつも面倒な思いをしていた方は，チェックしてみてはいかがでしょうか。

**Enjoy!**
超強力な FileMaker API for PHP のラッパー、RESTfm について

# FileMaker API を利用するために逐一コードを書く
これまでに書いてきたように FileMaker API を利用するためには PHP や Ruby を用いて一つ一つの手続きをガリガリとコードで書いていかねばなりませんでした。このように順を追って内部的に何が行われているのを理解しながら動くものを作り上げることというのは、動作の本質を理解するために大切なことです。

また、コードの保守や改良を加える際に、その内容を理解しているために作業がスムーズに進むことでしょう。

# ライブラリ（フレームワーク）の利用
しかしながらある程度の理解が進みいくつかのアプリケーションを書いているうちに、決まりきった同じコード（それもいわゆる「おまじない」）を書いたり、ただ引数が違うだけのメソッドの羅列を書いたりすることが面倒になってくることがあると思います[^1]。

その際にはライブラリやフレームワークを使用すると便利です。そして FileMaker にはそのようなライブラリが存在します。

# RESTfm
その中の一つが [RESTfm](http://www.restfm.com/) です。名前からも分かるように、RESTful な API を提供してくれる FileMaker API for PHP のラッパー[^2]です。

このラッパーを Webサーバ に配置すれば、HTTP 経由で FileMaker API for PHP をとても簡単に扱うことができます。

HTTP の GET / POST / PUT / DELETE で CRUD ができ、URI も直感的なものであるのでコードの見通しもよくなります。Webアプリケーション や Webサービス への展開や組み込みも、いわゆる Web API ですのでやりやすくなるでしょう。

コマンドラインからも HTTP メソッド を発行すればいいだけですので、curl でサクッとコードを書けます。

PHP や Ruby を知らない人でも、GET に関しては指定された URI を構成して叩くだけですので利用が容易になります。

# RESTfm のソースコード
RESTfm のコードは [GitHub にて公開されています](https://github.com/GoyaPtyLtd/RESTfm)。興味がある方は覗いてみてください。

# インストール～使用方法
インストール方法や使用方法については明日からの記事で触れたいと思います。

[^1]: いわゆる DRY じゃない
[^2]: 「ライブラリ」でも「フレームワーク」でも「アプリケーション」でもピンと来ないので「ラッパー」としました
Vim 8.0 Advent Calendar 13 日目 undo を分割せずにカーソルを移動

この記事は [Vim 8.0 Advent Calendar](http://qiita.com/advent-calendar/2016/vim8) の 13 日目の記事です。

普段はあまり気にしないかもしれませんが、undo の単位は重要です。この undo について、新しい機能が追加されました。

## 挿入モードでの操作の分割

挿入モードでの操作中に、`<Left>` などでカーソル位置を動かすと、undo 情報や `.` でのリピートが壊れてしまいます。
例えば以下のキーマッピングがあった場合、

```vim
inoremap ( ()<Left>
```

挿入モードで `foo(bar` と入力することで `foo(bar)` が入力できます。

```
入力: afoo(bar<Esc>
↓
foo(bar)
```

しかし、ここで `u` コマンドで undo を行うと`foo()` となってしまいます。また、`.` コマンドでリピートを実行すると、`bar` が挿入されます。

```
foo(bar)
↓
入力: u
↓
foo()
```

```
foo(bar)
↓
入力: j.
↓
foo(bar)
bar
```

これは `<Left>` により入力情報が途切れてしまうためです。つまり、`<Left>` を行った時点で、挿入モードを一旦抜けて入り直したのと同じことになります。

## 挿入モードでの `<C-g>U` コマンド

この問題を避けるために、`<C-g>U` コマンドが追加されました。これはカーソルを動かすコマンドの直前で使用します。
このコマンドを使うために、キーマッピングを以下のように書き換えます。

```vim
inoremap ( ()<C-g>U<Left>
```

最初の例と同様に `foo(bar` を入力し、その後それぞれ `u` コマンドや `.` コマンドを実行すると、入力された `foo(bar)` 全体が 1 つの入力として動作します。

```
foo(bar)
↓
入力: u
↓

```

```
foo(bar)
↓
入力: j.
↓
foo(bar)
foo(bar)
```

この `<C-g>U` コマンドは、カーソルが行を跨がない移動をする場合のみ有効です。

`<C-g>U` コマンドは便利ですが、手で入力するにはちょっと複雑です。今回の例のように、キーマッピングで使うとよいでしょう。
iOS/Androidアプリへドメイン駆動設計（DDD）を導入してCleanArchitectureを目指す [どうなったか編]

この記事は[導入編](http://qiita.com/KazaKago/items/7c58d05ec388821d7b52)の続きになります。
こっちは文字ばっかです。

# 実施してみて
まず、そもそも私のDDDに対する理解がまだまだなので、本来の効果が発揮できているか怪しいですがNon知識から導入してみたらどうなったかということを書いてみます。

## :smiley:メリット1：保守性が上がった
レイヤーがきれいに分かれておりレイヤー間の結合度が低いので、互いの干渉が少なく仕様変更には強くなりました。
画面単位でのロジックが一切ないので、この画面のこの処理を変更してさらにこの画面の同じ処理を…というリファクタリングはかなり減ったと感じました。

## :smiley:メリット2：ファットコントローラーの解消
MVCの一番の悩ましい点だったファットコントローラーが解消されたと感じます。
アニメーションがもりもりの画面などは相変わらずViewControllerの記述量は多いところもありますが、少なくともUIの描画(ViewController)とイベントのハンドリング(Presenter)やロジック周り(UseCase)のコードが混在してカオス化することは防げているので、その点では大いに効果がありました。

## :smiley:メリット3：テストしやすい
一番恩恵をうけるのはテストだと思います。
ロジックのテスト、UIのテスト、DBアクセスのテスト等、分離してテストが出来るのでテストコードが書きやすく、バグの原因追求も容易です。
例えばドメイン層のロジックのみをテストしたい場合は、スタブとドライバを用意すればおｋです

## :frowning2:デメリット1：工数増えるしぶっちゃけめんどくさい
ViewControllerから保存されている値を取り出そうと思った場合、最短だと
> ViewController→UserDefaults

のようにアクセスすると思いますが、DDDに則って取り出しを行うと
> ViewController→Presenter→UseCase（インターフェース）→UseCase（実装クラス）→Repository（インターフェース）→Repository（実装クラス）→UserDefaults管理クラス→UserDefaults

とかなり長いクラスを経て取得しに行くことになります。~~メンドクサイです。~~
この場合途中のUseCaseクラスは次のクラス処理を依頼しているだけなので書いてる途中に「このクラス挟んでる意味あるのか…？」という気分に陥ります。

## :frowning2:デメリット2：Realm等の一部のライブラリとの相性が悪い
DDDを導入する上で一番困ったことの一つが[Realm](https://realm.io/jp/)データベースをどう扱うかという問題で、Realmはプロパティアクセス時に初めて値がDBから呼び出されるライブオブジェクトと呼ばれる仕組みを用いて高速化を行なっています。
Realmの概念は本来Data層のみに留めるのが理想ですが、RealmオブジェクトはそのままUIに適用するのを想定されているため、ほかの層でもRealmの存在を強く意識する必要があります。
Data層でRealmオブジェクトを取り出してDomainオブジェクトへの変換してしまうとせっかくのライブオブジェクトの利点がなくなってしまうのが悩ましいところです。

今回は悩んだ末、DomainオブジェクトをそのままRealmオブジェクトとして扱うことにしました。
つまりDomain層やPresentation層の中にもがっつりRealmの概念が入り込んでおり、Domain層にあるRealmオブジェクトをData層やPresentation層でもそのまま使っています。

## :frowning2:デメリット3：途中参入メンバーの学習コスト高い（かも？）
私のプロジェクトでは途中参入はありませんでしたが、途中からプロジェクトへ参入された方は苦労するかもしれません。
ちゃんと設計を理解した上で同じように実装して貰う必要があるので、プロジェクトが炎上しているからと行って説明を省いて作業に取り掛かるとお互い不幸になりそうです。

# :point_up:自分なりの結論：効果は大いにあるが銀の弾丸ではないのでTPOに応じて使おう
元々があまり良い設計で開発していなかったので、それに比べればクラス設計に一定のルールが設けられ、クラス間の疎結合も保たれるのでMVCより設計が改善されたと感じることが出来ました。

その反面、かけるコストは大きいためスピーディな開発には向いていません。
特にiOS・Androidアプリだと一人のエンジニアがスピード重視で作ることも多いため、そのような場合にかけたコストに見合った効果が得られるかは微妙なところです。

ただ開発の途中からDDDのような概念を導入することは大変なので、プロジェクトが肥大化することを見越して最初から考慮しておくのはありだと思います。

## ポイントは適度にユルめにやること
DDDのような設計手法をガチガチにやってしまうとコストが掛かりすぎてしまう事もあるので、概念を一部適用するのもありだと思います。
たとえばData層のRepositoryパターンだけを採用してデータ入出力処理を一箇所にまとめるだけでも効果があるでしょう（既にやってる人多いと思いますが。。。）
UIに近い部分は特にOSフレームワークの影響を受けやすく設計概念をそのまま適用するのが難しいことがあるので、そこは厳密にはやらないという選択肢もあります。
また定数ファイルの置き場所一つでData層に置くかPresentation層に置くか悩んだりもしてくるのであまり厳しくやりすぎないのがコツです。
私自身も一部端折ったり妥協したりしながら試行錯誤して作業したので、自身のプロジェクトにあったやり方を見つけるのが一番ですね。

# 参考
[SwiftでDDD(ドメイン駆動設計)](http://qiita.com/kayo_h/items/0f91fe8d1b66c8680ae6)
[まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて](http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc)
[[ Android ] - これからの「設計」の話をしよう](https://tech.recruit-mp.co.jp/mobile/android-architecture/)
[Clean Architecture + DDD + Redux + RxJavaをAndroidでやるときにどこまで分割するか問題](http://izumin.hateblo.jp/entry/2016/01/24/221943)
[AndroidではMVCよりMVPの方がいいかもしれない](http://konifar.hatenablog.com/entry/2015/04/17/010606)
CData API Server で5分でMySQL からREST API を生成

CData API Server がどれだけ超高速でRDB からREST API を作れるか？

ケースとして、すでに公開したいデータがMySQL に一つのテーブルとして格納されているとします。

##CData API Server をダウンロード:所要時間2分## 
[CData のAPI Server ページ](https://www.cdata.com/jp/apiserver/)から製品のインストールを行います。

##MySQL とAPI Server を接続：所要時間1分##
「設定」タブの「接続」からデータベースへの接続を行います。
![apiserver3.png](https://qiita-image-store.s3.amazonaws.com/0/116843/0f3662d6-7231-e683-50f6-7c1ccfc250a2.png)

##API として公開するテーブルおよびカラムを選択：所要時間1分##
「設定」タブの「リソース」からクリックして公開するテーブルおよびカラムを選択して、保存します。
![apiserver5.png](https://qiita-image-store.s3.amazonaws.com/0/116843/3f317eae-b3be-ad81-ce48-e740bc9c4f22.png)

##API にアクセスできるユーザーを設定しAuthトークンを発行：所要時間1分##
「設定」タブの「ユーザー」からどのユーザーにデータへのアクセスを与えるかや、権限、リクエスト制限などを設定します。保存するとAuth トークンが発行されます。

以上で設定は完了で、選択したDB テーブルのデータがREST API として公開され、ドキュメントも自動生成されています。管理コンソールでは、公開されたAPI のモニタリングが可能です。
![apiserver6.png](https://qiita-image-store.s3.amazonaws.com/0/116843/c26f467b-a61b-ff5e-7806-ba483d34569d.png)
Fess 管理>全般のクローラ設定

Fess 10.3
Fessの管理>システム>全般の設定>クローラの設定を確認します。

### 全般の設定 > クローラ

- [x] 最終更新日時の確認

前回クロールしたドキュメントは更新されていればインデックスします。
チェックを外すと更新の有無に関わらず全てのドキュメントを再インデックスします。

- 同時クローラ設定

　　ウェブ・ファイルシステム・データストアに設定されたクローラを同時に実行する数を設定します。

- 以前のドキュメントを削除

　　過去何日分のドキュメントを保持するかを設定します。

- 除外するエラーの種類

　　障害URLがしきい値を超えるとクロール対象から除外されますが、
　　障害URLがしきい値を超えてもクロールさせたい場合はエラーの種類を設定します。

- 障害数のしきい値

　　しきい値を超えた障害URLをクロール対象から除外します。


#### 障害数のしきい値と除外するエラーの種類の設定例

- 障害数のしきい値を`2`に設定
　　障害数3回目以降の障害URLはクロールから除外されます。

- 除外するエラーの種類
`org.codelibs.fess.crawler.exception.MaxLengthExceededException`
 ファイルサイズが大きいと発生するExceptionを除外するエラーの種類に設定すると
上記Exceptionはしきい値を超えてもクロールされます。