OmniAICreator/Qiita-1.07M huggingface dataset:
ownCloudのアクティビティ機能とそれを使った請求書発行システム事例


ownCloud Japan Advent Calendar 2016 - Qiita
http://qiita.com/advent-calendar/2016/owncloudjp
14日目です。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/3c6d09a7-b0f0-2f6a-ecb3-6d6f5fd681c4.png)
# 1. ownCloudのアクティビティ機能とそれを使った請求書発行システム事例

ownCloudのアクティビティ機能を使った請求書発行システムの事例です。
アクティビティ機能はユーザーの操作に対してメールを送付する機能があり、それを応用した事例になります。

# 2. 既存請求書発行の仕組み
既存のシステムは、顧客事のPDFファイルを担当者が、個別に顧客に対してメールを送付していました。
その為、メールの添付間違いなどのミスが発生していました。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/6b2fdc5e-6634-c63a-5a23-5f1f32884e8d.png)

この課題を解消するために ownCloud のアクティビティ機能を使って自動的にメール送信するようにシステムを改修しました。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/04cf52ea-c4ec-2cb8-f753-5ffd660129a2.png)

# 3. ownCloudのアクティビティ機能とは？

ownCloudのアクティビティ機能とは、ownCloudでのファイル操作を表示、メール通知する機能です。
メールでの通知は設定が必要です。
アクティビティ機能を有効にした場合、自分の操作が他人に見られるようになります。
ご注意ください。
(※見られてはまずい場合は、「ストリーム上にあなたの活動を表示する」のチェックを外しましょう。)

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/01969efa-698a-ddb4-500b-2899b6ff878d.png)

# 4. 隠れた人気アプリ「アクティビティ機能」

アクティビティ機能で人気となっている機能が、「メールで通知する機能」です。
自分の操作や他人の操作履歴がメールされるため更新した情報を確認することができ、メールがあったときだけownCloudを確認すればよいことから、便利な機能として重宝されています。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/34523e7f-1a86-b7af-ecf1-688bfd245854.png)

# 5. アクティビティ機能を使った請求書発行システム

このアクティビティ機能を使った請求書発行システムについて、ステップを追ってownCloudがどのような動きをするかご紹介します。

## 5-1. 請求書PDF作成、ファイルサーバー保存

帳票システムから請求書PDFを作成し、ファイルサーバーに保存します。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/c09971c0-dc31-f6db-cb34-eb3e9d4c0fc2.png)

## 5-2. ファイルサーバーからownCloudサーバーに同期(アップロード)

ファイルサーバーにファイルが保存されたら、ファイルサーバーにインストールされているownCloud デスクトップクライアントアプリが追加されたファイルを認識して、ownCloudサーバーにアップロードします。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/0a783248-ed39-51c8-e5f3-378c80613698.png)

## 5-3. アクティビティ機能が通知メールを送信

ownCloudにファイルがアップロードされると、アクティビティ機能によって対応するユーザーに対してファイルが追加された旨のメールが送信されます。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/9e1e3e79-36d5-7c00-c03a-df61e43213f5.png)

## 5-4. 通知を受け取ったユーザーがユーザー毎のフォルダーに入った請求書PDFファイルをダウンロード

ユーザーは、事前に発行されたID/PWに従ってownCloudにログインし、ユーザー毎に分かれたフォルダーに入っているPDFファイルをダウンロードする。

![image](https://qiita-image-store.s3.amazonaws.com/0/15176/f1be2ccc-e9d4-0dab-7e2b-df9305780084.png)
Perl入学式 を卒業したら、仕事が楽になった話

- これは [Perl入学式 Advent Calendar 2016 - Qiita](http://qiita.com/advent-calendar/2016/perl-entrance) の14日目の記事です

# 自己紹介
- sironekotoro と申します
- かわいらしいハンドルネームですが中身はおっさんです
- 2013年、スカラー変数・配列・ハッシュは分かるものの、リファレンスは分からない、という状態で入学し、卒業しました
  - リファレンス分からなくてもプログラムは書けらぁ！ そんなふうに考えていた時期が俺にもありました
- お仕事は、業務委託先でセキュリティアプライアンスサーバ（中身はLinux）のリモート保守(10%)・社内ヘルプデスク(10%)・その他雑用(80%)をやってます
- 数年前はプロバイダで一般ユーザ相手にダイヤルアップ、ADSL、光接続、メール設定、ホームページへのFTPアップロードなどのコールセンター業務をしていました


# Perl入学式 を卒業したら、仕事が楽になった話
- 上にも書いたように仕事のほとんどが雑用で非定型なんですが、だからこそPerlは大いに役に立っています

## 1. よその部署からよく依頼される「ログファイルから一致する項目を日別で集計」

### Perl入学式「前」
1. ターミナルで該当ログ表示させ、テキストエディタにコピペ
2. テキストエディタの置換機能で整形し保存
3. ファイルをExcelで読み込み
4. Excelのフィルタを駆使して集計

### Perl入学式「後」
```perl
use strict;
use warnings;

my $hoge;
foreach my $row (<DATA>) {
    chomp $row;
    my ( $date, $country ) = split / /, $row;
    $hoge->{$date}->{$country}++;
}

foreach my $date ( sort keys %{$hoge} ) {
    print $date , "\n";
    foreach my $country ( sort keys %{$hoge->{$date}} ) {
        print "\t", $country, "\t", $hoge->{$date}->{$country}, "\n";
    }
}

# DATAは例ですが、大体こんな感じです
__DATA__
0102 Japan
0102 Japan
0103 England
0103 China
0103 America
0104 Japan
0104 America
```

- 結果

```
0102
	Japan	2
0103
	America	1
	China	1
	England	1
0104
	America	1
	Japan	1
```

- リファレンス大活躍です
- これはPerl入学式でリファレンスに触れ、かなりの数の練習問題をこなしたからこそ、と思っています
- 今ではリファレンスの無いPerlスクリプトは考えられないほどです
  - 通販番組みたいな口上だけど本当に
- また`Data::Dumper`を利用して変数の中身を立体的に「見る」方法を教えてもらい、これが理解する上で大きな助けになりました


## 2. 業務で使ってるサイトをもっと便利に改造（with Javascript）
- サーバーのグローバルIPアドレスが一覧表示されている業務用ページを参照し、各々の逆引きドメイン名を確認する

### Perl入学式「前」
1. ページを表示する
2. IPアドレスを選択して Ctrl + c （コピー）する
3. 心を込めて「[IPひろば](http://www.iphiroba.jp/) 」の入力欄に Ctrl + v して調べる
4. 2-3を繰り返す 
5. 使いすぎて利用制限に引っかかる
6. どっか別のドメイン検索できるサイトを探す

###  Perl入学式「後」
1. Javascript(Gresemonkey)とローカルで立てたmojoliciousのサイトを利用する
2. Gresemonkeyでページ読み込み完了後、ページ内のIPアドレス部を取得し、XMLHttpRequestでmojoliciousにIPアドレスをgetで投げるスクリプトを書く
  - 後日、GM_xmlhttprequest というGresemonkeyのローカル関数使えばもっと楽と判明
3. mojoliciousはgetで渡ってきたIPアドレスを名前解決モジュールに渡す
4. 名前解決モジュールはIPアドレスを逆引きし、ドメイン情報を返す
5. mojoliciousから返されたドメイン情報をJavascriptのappendChildでページに追記

```perl
# 抜粋 名前解決モジュール
use Net::Nslookup;
my $ip_address = shift;
my $host = nslookup( host => $ip_address , type => 'PTR' , server => ['8.8.8.8' , '8.8.4.4']);
return $host;
```
- これにより、ページを表示するだけでドメイン情報も一緒に表示され、とてもとても仕事が楽に

## 3.その他
- とりあえず、スクリプト言語的なものなら書いて実行してみることが怖くなくなりました
- おかげで、シェルスクリプトはもちろん、Teratermのマクロなんかも自分で好きに組めるようになりました

# まだ勉強してます
- 以上、Perl入学式で学んだことを活用し、仕事がとても楽になったという報告でした
  - ほぼ定時に帰ることができるようになってます
- 現在はPerlでオブジェクト指向を学び、それを自作のプログラムで生かそうとしています
  - もちろん仕事と生活が楽になる事を目指して！
  - Perlのオブジェクト指向ですが、個人的には「[すぐわかるオブジェクト指向Perl](https://www.amazon.co.jp/dp/4774135046)」がオススメです
- 来年は「ラクダ本」こと「プログラミングPerl」に取り掛かる予定です。すごい楽しみです。
Milkcocoaとの出会いで電子工作がIoTと呼ばれるようになった話

こんにちは、蔵下です。コミュニティーにはたま〜に現れるキャラなのでご存じない方が大多数でしょう:sweat_smile:

今年の夏前にこういう本を出しました（早速宣伝ですみません）。ArduinoとESP8266というWi-FiモジュールでIoTをはじめようという内容です。後半ではMilkcocoaを紹介させていただきました。

![book.jpg](https://qiita-image-store.s3.amazonaws.com/0/55103/8dd73440-c47d-d1a9-e848-0574e0063848.jpeg)

一応リンクものっけておきますね（調子乗ってすみません）。

[センサーでなんでもできる おもしろまじめ電子工作 Amazon](https://www.amazon.co.jp/dp/4798046604)

この記事では、電子工作が「ハンダで部品くっつけておもちゃ作るんでしょ？」と思われていた時代から、IoT（Internet of Things：モノのインターネット）がバズワードとして認識されるようになった現在までを、今までの経験でまとめたいと思います（おじさんの思い出話にならないように気をつけます。。）。

結論から言うと、**Milkcocoaとの出会いで電子工作がネットとつながるようになり、IoTと呼ばれるようになった**ということです。

技術的な内容はゼロなので悪しからず:bow_tone1:

# Arduinoの登場でクリエイターと電子工作が近づいた

※Arduino以外にもあるだろーというツッコミは一旦置いといて。。

僕が電子工作を本格的に始めたのはこの頃でした。もともと工業高校でハンダのたしなみはあったので、「こんな簡単にできるのか！」と衝撃でした。パソコンにUSBで接続してサンプルコードを書き込むだけでLチカする。ファンタスティック:clap_tone1:

その頃からいろいろ作っていたのですが、残っているのはこれくらいですかね:sweat_smile:音を周波数？ごとに分割して16セグのLEDでゴニョゴニョしているものです。映像のクオリティで8割増しですが（映像を作ってくださった先輩に感謝）。

![hikari.jpg](https://qiita-image-store.s3.amazonaws.com/0/55103/4ceb93c3-0a38-93e8-5a23-48ca8d5bb632.jpeg)

[16x16 HIKARI](https://vimeo.com/36118090)

# Arduinoからサーバーへアクセス（できたけど...）

同じ時期に、当時在籍していた会社のスペシャルコンテンツとして、ネット経由でロボットを操作して戦うコンテンツを制作しました。私は主にロボの制御（Arduinoから赤外線を飛ばして技を出す）ところから、制御用のアプリ（Flash）の開発を行いました。今思えばIoTの走りだったのかもしれません。

![taiman.jpg](https://qiita-image-store.s3.amazonaws.com/0/55103/c7e5e711-08f4-3203-f04c-61938401d668.jpeg)

[TAIMAN ROBO](https://vimeo.com/27574649)

当時はBaasもなく、サーバーサイドのエンジニアさんにゴリッと環境をつくっていただきました。フロントエンドが専門な私にとってはハードルが高すぎなコンテンツで、その後Arduinoとネットを連携するコンテンツは作れずにいました。

# インスタレーション作品が増えてきた

私はなかなかインスタレーションのお仕事に関わることはできなかったのですが、Arduinoを使った体験型インスタレーションでがこの頃から増えてきました。独自のコントローラーを作って、画面内のコンテンテンツを制御することは初めての体験だらけで面白かったですね:smile:

その後はKinectの登場で体のジェスチャーで操作する手段が生まれ、コントローラーを作るということが一瞬減った気がします。

この頃のコンテンツは、会場に来ているお客さんしか体験できずすばらしいコンテンツでも埋もれてしまうものもありましたね。

# ときは流れ、Milkcocoaとの出会い

Milkcocoa Advent Calendarに関係する内容にやっとたどり着きました。前フリが長くなってしまってすみません:bow_tone1:

あれから数年経ち、電子工作はなかなかやれない日々が続いていました。そんなとき、Milkcocoaと出会いました。どいういうタイミングだったかは正直覚えていません。とにかく突然でした。

サーバーの構築がいらないぞ。フロントエンドならJavaScriptで実装できるぞ。**ん？ ArduinoのSDKがあるぞ！**

「見つけた！神サービスを」と思いました。

見つけた当時のSDKは、ESP8266に直書きする（Arduinoの用に使える）方式だったので、Milkcocoaの中の方にはガチでサポートしていただきました。スマホからLチカできた感動は今でも忘れません:sob:

# それまでの電子工作がIoTと呼ばれるようになった

今まで電子工作をしていると、「ハンダで部品くっつけておもちゃ作るんでしょ？」と思われがちでした。知らない人になかなか伝えられない。LEDがチカチカして何が楽しいの？状態。ちょっと辛かった:persevere:

それがネットとつながることでIoTと呼ばれるようになった。人に見せるときも、スマホ経由でLEDをチカチカさせるだけで驚いてもらえるようになった。伝わるようになった。

# 感謝

そして、いろいろな方のご尽力もあり、書籍を執筆するまでに至りました。本当にありがとうございます。Milkcocoaの登場で通信やフロントエンド、ハードウェアまでまるっと一人でできるようになったかもしれませんが、これもコミュニティーや開発してくださった方々の汗と涙と血の結晶かなと思います。

長くなりましたが、2017年もますますの発展を期待してます。私にできることがあればお手伝いできればと思います:v_tone1:
nghttpx Ingress controller

# はじめに

最初にIngressについて説明する必要があるだろう。誤解を恐れずにいろいろと端折って文章にするならば、[Kubernetes](http://kubernetes.io/)というコンテナーオーケストレーションシステムが用意している[Ingress](http://kubernetes.io/docs/user-guide/ingress/)は、Kubernetesクラスタ内で稼働しているHTTPベースのサービスに対して、クラスタ外部からアクセスする手段を提供するものである。Kubernetesが定義するIngressは、ただのリソースであり、HTTPにおけるホストとパスでどのサービスへリクエストをフォワードすればよいかのルールを記述する。実際にリクエストをIngressリソースの通りにフォワードする機能は、Kubernetes本体では提供されていない。この隙間機能、すなわち、Ingressリソースを読んでいい感じにL7ロードバランサーを設定してリクエストが期待通りにフォワードされるようにする機能を提供するものこそが、[Ingress controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers)なのである。[nghttpx Ingress controller](https://github.com/zlabjp/nghttpx-ingress-lb)とは、L7ロードバランサーにnghttpxを採用した、Ingress controllerである。

Kubernetesについて知りたい方は、 http://qiita.com/advent-calendar/2016/kubernetes をどうぞ。

nghttpxについて知りたい方は、少し古いですが http://qiita.com/tatsuhiro-t/items/99a2fd61d0fb16d7241b をどうぞ。合わせて読みたい[公式マニュアル](https://nghttp2.org/documentation/nghttpx.1.html)、[nghttpx - HTTP/2 proxy - HOW-TO](https://nghttp2.org/documentation/nghttpx-howto.html)もどうぞ。

https://github.com/kubernetes/contrib/tree/master/ingress/controllers にはnginxを使ったIngress controller実装が公開されている。nghttpx Ingress controllerは、nginx Ingress controllerをベースに開発した。

# どこがHTTP/2と関係あるのか?

もちろん関係がありますとも。nghttpxはHTTP/2をサポートしたL7ロードバランサーである。nghttpxはフロント、およびバックエンドの接続の両方でHTTP/2をサポートしているため、[gRPC](http://www.grpc.io/)のロードバランスにも使うことができる。ただしnghttpxはバックエンドの接続では、HTTP/1もしくはHTTP/2のどちらを使うのかを事前に指定しておく必要がある。ところが、Ingressにはその指定するようなフィールドは存在しない。nghttpx Ingress controllerでは、Ingressリソースのannotationsにバックエンド接続に関する追加設定を書くことにして問題を回避した。以下の例では、greeterというサービスのport 50051に対する接続については、h2、すなわちHTTP/2プロトコルを使うように設定している:

```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: greeter
  annotations:
    ingress.zlab.co.jp/backend-config: '{"greeter": {"50051": {"proto": "h2"}}}'
spec:
  rules:
  - http:
      paths:
      - path: /helloworld.Greeter/
        backend:
          serviceName: greeter
          servicePort: 50051
```

詳しくは、https://github.com/zlabjp/nghttpx-ingress-lb#additional-backend-connection-configuration を読んでほしい。
Socket.ioとMessagePack

Socket.ioが落ちる事態に見舞われていましたが、追いかけていくと妙なところに原因が眠っていました。

## Socket.ioと他システムとの連携
他のWebシステムの中にSocket.ioを取り入れる場合、（他のシステムがNode.js製でシームレスに組めるのでもなければ）連携の方策を考える必要があります。

そこでよく使われるのが、Redisのpub/subシステムを使った[Socket.io-redis](https://github.com/socketio/socket.io-redis)です。「Redisに投げる」のは他言語でも容易にできるので、Nodeを離れての開発にも有効です。

## 突然のエラーに襲われて
そんな中で連携してシステムを作っていたところ、Socket.ioサーバが落ちる、ということになってしまいました。ログを見て原因を探っていくと、msgpackの処理で失敗している、ということでした。

## msgpackとは
聞きなれないmsgpackですが、検索していくと[公式サイト](http://msgpack.org/)が見つかりました。JSONのように、数値・文字列・配列・連想配列をエンコードするシステムで、バイナリ表現を使うことでJSONより容量を削減している、ということでした。

### 問題の詳細
そして、詳細を追いかけてみると、socket.io-redisで使っているmsgpackのライブラリ自体にバグがあって、Int64/Uint64型のデータをデコードできない、という事態が発生していました。

この記事を書くために確認してみたところ、[msgpackライブラリの差し替え](https://github.com/socketio/socket.io-redis/pull/156)がマージされているので、次のリリースには問題が解決しそうです。

### 残された課題
とはいえ、言語仕様上JavaScriptには[64ビット整数がなく](http://qiita.com/jkr_2255/items/0495585a315512a9f00b)、doubleの精度は53ビットしかないので、それを超える数が来た場合、

* 数値として扱って、桁落ちを起こす
* 文字列として処理する

の2択が必要となるのでしょうが…あまりすっきりしない気がしました。
リカバリとチェックポイント

# リカバリ

DB上のページは「Atomicな複数更新」かつ「コミット時に全ページをForce」かつ「No-Steal」という、設計上の非常に遅い選択肢を選ばない限り、プロセス・OS・電源の障害からの復旧は基本的に一貫性が無い状態がスタート時点になる前提が必要である。

一貫性のないDBのページを復旧するためにログを残しており、一貫性のないページとログからDBの一貫性を取り戻す作業を**リカバリ**と呼ぶ。
どのような**リカバリ**が必要とされるかはDB側のページ一貫性設計に大きく依存する。

基本的な戦略としては、DBのACID特性を維持するために「すべてのトランザクションをALL or Nothingに倒す」「ユーザに完了を報告した可能性のあるトランザクションはすべてALL側へ倒す」というのが前提となる。(CやIに関してはログを生成した時点で解決していると言える）

前述したように**Steal**のあるDBでは未コミットなページ更新がディスクに反映されてしまっている可能性もある(Atomicity違反)。また**Force**のないDBではコミット済みのデータがディスクに反映されていない可能性もある(Durability違反)。**Steal**かつ**No-Force**なDBでは１つのページの中にRedoすべき更新とUndoすべき更新が両方載っている可能性すらあるので、ログに書かれている順番通りにRedoとUndoを適切に行う必要がある。
その適切なプロトコルはそれぞれの場合でもあまり自明ではなく、様々な要素と複雑に絡み合っている。このアドベントカレンダーでは一番有名なARIESでのリカバリの実装について後日説明する。

# チェックポイント

さて、**No-Force**戦略で動くデータベースは基本的にLRUなどでのページ置換アルゴリズムに従ってメモリに置くページを決める。
それを愚直に実装してしまった場合、大きな問題に悩まされる事になる。
例えば、1年走り続けているDBシステムがあって、特定の1ページが一度もLRU的に不要と見做されなかった場合、つまりhotなページとしてメモリの中に生き続けてしまう。
するとディスクに正しくRedo用のログが書き込まれていたとしても、そのDBの電源断からの再起動時にはそのページに関しては1年分の更新をすべて再度行わないと最新のコミットされたデータまで追いつかない。1年分の処理のリプレイは並々ならぬ時間が掛かる事だろう。

そこで考案されたのが**チェックポイント**である。この技法は定期的にメモリ内のページをディスクへと強制的に書き戻す事によって、再起動時のコストを小出しに支払う。
注意して欲しいのが、**チェックポイント**とは飽くまで再起動時のリカバリ時間を短縮するための高速化であって、原理上それは存在しなくてもDBの中身はログから復旧可能である。たまに「**チェックポイント**をとっているからDBはリカバリができる」と話す人もいるが、時間が掛かるだけでログさえあれば復旧は原理的に可能である。

チェックポイントの取り方も数多くの研究がなされているが、古典的なタイプのものは前回の記事でも引用した [Principles of Transaction-Oriented Database Recovery](http://dl.acm.org/citation.cfm?id=291)の中でまとまっている。

- Transaction Oriented Checkpoints(TOC): 純粋に毎回**Force**する戦略。言うまでもなくパフォーマンスに悪影響が大きい。
- Transaction Consistent Checkpoints(TCC): 定期的に出されるチェックポイントシグナルを受け取ったらメモリ内のページを全てディスクに書き出すまで新規トランザクションの開始を抑制する戦略。一貫性のあるディスク内ページが定期的に得られるものの、チェックポイント中は新しいトランザクションを受け付けられない。
- Action Consistent Checkpoints(ACC): チェックポイントシグナルを受け取ったらその瞬間のメモリ内のページを全てディスクに書き出す戦略。当然ダーティなページも全て書き込まれるのでリカバリ時のコストは高いが上の2つと比べればチェックポイント時のコストは遥かに少ない。
    - fuzzy: その他いろいろな亜種が提案されており、ダーティなページの一覧（Dirty Page Table）と走っているトランザクションの一覧(Transaction Table)のみをディスクに書き、メモリ内のページをディスクに書き出す操作を伴わない物。冒頭で書いた超長いRedoなどの問題は解決しないが、Redo時にどのページを洗えば良いか明白になるのでリカバリ動作が高速になるというメリットがある。最近のfuzzy checkpointと見比べて両方に含まれるhotなページがあったらそれを選択的にディスクに書き出すなど、適応的な方法もある。

上記の事を踏まえて改めて[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)

- ¬FORCEなシステムでしかTOC以外のチェックポイント選択肢はない。むしろFORCEしないとTOCは選べない
- ¬ATOMICなシステムでしかfuzzyなチェックポイントは使われない、なぜなら複数ページの書き込みが常に一貫性を守るのならdirtyなページを管理するメリットが少ないから。

実施例は複雑にからみ合っており、それぞれの中で無数に細かい実装上の選択がある。
それら全てについて語る時間も知識も無いので、この日記では。一番有名な金字塔ARIESに絞って説明を行う。
Schooアプリを支えるGolangサーバーの構成について

# はじめに
本投稿は、Schooの年末特別企画「[Schoo advent calendar 2016](http://qiita.com/advent-calendar/2016/schoo)」への投稿記事になります。

14日目の今回は、先日公開したSchooアプリver2系のバックエンド構成について、個人的なピックアップポイントと共にお届けします。

それでは、どぞー


# サーバー構成と概要
まずは、簡単な構成図です。クライアントに近い方から紹介していきます。
![golang-servers.png](https://qiita-image-store.s3.amazonaws.com/0/4503/34247e41-03dd-20d6-4e6c-2f3d94525e14.png)

## ELB/TCP
最前面にELBを配置しています。
こちらはロードバランサーとして利用しているのではなく、2個あるサーバーグループへのアクセスをリリース毎に切り替える目的で利用しています。
(TCPモードにしているのは、HTTP/2を扱うため)

### <i class="fa fa-hand-o-right"></i> Pickup！
ELBに登録するEC2インスタンスを動的に入れ替えてトラフィックの切り替えを実現しているんですが、それを自動でやってくれるのはSchoo開発チームのお友達「すくすけ」ですよ！
![scsk-switch.png](https://qiita-image-store.s3.amazonaws.com/0/4503/8d0095e4-2470-91eb-4a71-f533db09f513.png)


## [nghttpx](https://github.com/nghttp2/nghttp2)
HTTP/2対応のリバースプロキシー/L7ロードバランサーです。
パスベースの振り分けで利用していて、前面/背面共にHTTP/2での通信になっています。(TLSは前面のみ)
当初はALBでやろうとしたんですが、背面側がまだHTTP/2に対応していなかったため、今回の構成になりました。
ALBが対応したら置き換えを検討しようかと思います。

### <i class="fa fa-hand-o-right"></i> Pickup！
`ALB`はもちろん`nginx`なども検討したんですが、背面側でのHTTP/2対応がなかなかのハードルで、現状`nghttpx`一択ではないかと思います。
ちなみに、`nghttpx`のコンテナについては[こちら](http://dev.classmethod.jp/tool/nghttpx-on-docker-tips/)を参考にさせていただきました。


## Golangアプリケーションサーバー
[gRPC](http://www.grpc.io/)実装のGolangサーバー複数台で構成されています。
サーバーが機能ごとに別れているのとgRPCがHTTP/2を利用するため、`nghttpx`を利用したパスベースの振り分けが必要だったということになります。
将来的に、機能単位でのスケールアウトを想定しての構成となっています。

### <i class="fa fa-hand-o-right"></i> Pickup！
GolangサーバーのDockerコンテナは[`Alpine Linuxイメージ`](https://hub.docker.com/_/alpine/)をベースにしています。そのためイメージサイズが非常に小さいです。

```sh:Dockerfile
FROM alpine

RUN apk --update add ca-certificates
RUN apk --update add tzdata && \
    cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && \
    apk del tzdata && \
    rm -rf /var/cache/apk/*
```
上記のような`Dockerfile`でビルドしたものを利用していますが、イメージサイズは驚きの`6MB`です！

また、`Alpine Linux`で動かすGolangバイナリは、ビルド時に[`static link化`](http://okzk.hatenablog.com/entry/2016/08/03/234738)する必要があるようでした。利用される方は、ご注意ください。

## Blue/Greenデプロイ構成
Dockerホストを利用した再利用型のBlue/Greenデプロイ構成になっています。
なので同じサーバーグループが2個ありますが、`docker swarm`などを利用したクラスタ構成ではなくて、動的に入れ替われる`Production`と`Staging`のような独立した関係になります。

### <i class="fa fa-hand-o-right"></i> Pickup！
本番公開されていない方を`Staging`として利用し十分な確認の後、`Staging`を`Production`に昇格、`Production`を`Staging`に降格という切り替えを行っています。

`Production`と`Staging`が固定されている環境よりも、確認タスクや公開タスクを少なくできて便利です。
デメリットとしては構成スケールが常に同じである必要がある点でしょうか。(大規模サービスには向かないですね)

ちなみに、各環境へのデプロイも「すくすけ」がやってくれます！


# まとめ
いかがでしたでしょうか。
どこかに関心のある部分はあったでしょうか。
構成要素は他にもたくさんありますが、ボリューム的に省略させて頂いた部分も多いです。

まだまだ手探り感がありますが、ゼロからサービスを構築する醍醐味は十分にあると思います。
少しでも興味を持たれた方は、Schooの[Wantedlyページ](https://www.wantedly.com/companies/schooWEBcampus/projects)を是非チェックしてみて下さい！

何卒、なにとぞー
Vim 8.0 Advent Calendar 14 日目 新しいオプション その 1

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

新オプション紹介その 1 です。追加されたものの中でも便利なオプションについて解説します。

## `'breakindent'` (真偽値) `'breakindentopt'` (カンマ区切り文字列)

オンにすると、折り返して表示される行がインデントされて表示されます。
つまり以下のようになります。左が `'breakindent'` がオフ、右がオンです。また、`'showbreak'` オプションの値に `>` が設定されています。4 行目の折り返しに注目してください。
![`'breakindent'` オプションのオフとオンの比較](https://qiita-image-store.s3.amazonaws.com/0/551/3109f668-8938-f861-86ae-f05716f6a103.png "'breakindent' オプションのオフとオンの比較")


また、`'breakindentopt'` オプションで細かい挙動を制御できます。このオプションはカンマ区切りの文字列で、以下の要素を指定できます。

- `min:{n}`
    - 深いインデントが短すぎる幅で折り返されないように、1 行の最小の幅を指定します。未指定の場合は 20 になります。
- `shift:{n}`
    - 折り返された位置をずらします。正数で右に、負数で左にずらします。未指定の場合は 0 で、ずらしません。
- sbr
    - インデントの左側に `'showbreak'` を表示します。

例えば、`shift:4,sbr` を指定すると、以下のようになります。

![:setlocal breakindentopt=shift:4,sbr](https://qiita-image-store.s3.amazonaws.com/0/551/cbe5eac7-9157-f340-cc24-318dfa3892a4.png ":setlocal breakindentopt=shift:4,sbr")

`'showbreak'` である `>` 記号が行頭に移動し、折り返しのインデントが `if` のインデントに比べて右に 4 つずれています。

## `'fixendofline'` (真偽値)

通常、Vim は保存時にファイルの末尾に必ず改行を入れます。これは POSIX にて、テキストは行の集合であり、行は必ず改行で終わるとされているからだと思われます。
このファイル末尾の改行の付与は、ファイル末尾に改行のないファイルを開いて編集し、保存した場合にも行われます。
これは特にチームで作業している場合に困る場合があります。また、一部の CSV の処理系など、ファイル末尾の改行の有無で意味が合わるファイルを扱う場合も困ります。

そこで `'fixendofline'` オプションが追加されました。このオプションはデフォルトではオンで、保存時にファイル末尾に改行を追加します。
オフの場合、`'endofline'` オプションに従って改行を付与します。オンなら改行が付与され、オフなら改行は付与されません。
この `'endofline'` オプションは、既存のファイルを開いた際にはファイルの末尾の改行を見て自動でオンオフされます。

つまりまとめると以下のようになります。

- ファイル末尾の改行をいじって欲しくない場合は、`set nofixendofline` を vimrc ファイルに書きます。
- ファイル末尾の改行の有無を操作したい場合は、上記に加えて、都度 `'endofline'` オプションの値を変更します。

## `'belloff'` (カンマ区切り文字列)

Vim はエラーが発生した際にベルを鳴らします。これを無効化したい場合、以前は以下のような設定を書いていました。

```vim
set visualbell t_vb=
```

新しく追加された `'belloff'` オプションを使うと、代わりに以下のように書けます。

```vim
set belloff=all
```

`'belloff'` オプションは、どんな時にベルを鳴らさないようにしたいのかが細かく指定できます。特定の場合のベルのみ無効にしたい！といったことも可能です。
どのような値が指定可能かは help を参照してください。
Fess ウェブ認証

Fess 10.3
管理>クローラ>ウェブ認証を利用してBASIC認証とDigest認証のサイトをクロールします。

#### BASIC認証
- BASIC認証のサイト
`ユーザ名: basicuser`
`パスワード： password`

- 管理>クローラ>ウェブクロールの設定
`クロール名: basic_site_crawler`
- 管理>クローラ>ウェブ認証

| 項目         |       設定値 |
|:-------------|:------------------|
| ホスト名     | basicserver.com |
| ポート      | ポート番号(80は省略可) |
| レルム      | レルム名を記述(省略可) |
| スキーム      | BASIC認証 |
| ユーザー名      | basicuser |
| パスワード | password |
| パラメータ  | パラメータが必要な場合は記述 |
| ウェブ設定  | basic_site_crawler |


#### Digest認証
- Digest認証のサイト
`ユーザ名: digestuser`
`パスワード： password`

- 管理>クローラ>ウェブクロールの設定
`クロール名: digest_site_crawler`
- 管理>クローラ>ウェブ認証

| 項目         |       設定値 |
|:-------------|:------------------|
| ホスト名     | digestserver.com |
| ポート      | ポート番号(80は省略可) |
| レルム      | レルム名を記述(省略可) |
| スキーム      | Digest認証 |
| ユーザー名      | digestuser |
| パスワード | password |
| パラメータ  | パラメータが必要な場合は記述 |
| ウェブ設定  | digest_site_crawler |
enchant.jsをcoffeescriptで書く

## はじめに
enchant.jsはjavascriptを使ったゲーム用のライブラリです。
ゲームを作りながら工夫したところなんかを、かいつまんで解説していきたいと思います。

まずは前作の宣伝から。
以前こういうのを作ってました。
http://www.nicovideo.jp/watch/sm23105589

今新作を作ってます。2年くらい前からダラダラ作ってます。
2017年9月12日公開を目標にやってます。

## きっかけ
前作ったやつが、１つのJSファイルで作っていたのですが
コードが6800行くらいまで膨らみ、何がどこに書いてあるかわけがわからなくなってきたので、
ファイルをキレイに分割したい、見た目もスッキリさせたい、と思い
やることにしました。2年前の話です。

## インストール
おぼろげな記憶を頼りに辿っていきます。

まずはcoffeescriptをインストールします。
たぶんこの辺を参考に適当にインストールしたと思います。
http://techblog.kayac.com/coffeescript-tutorial.html
Node.jsとnpmをインストールして、coffeescriptをインストール。

コンパイラにはgruntを選びました。
当時参考にした記事とは違いますが、このあたりを参考にすればインストールできると思います。
http://webdrawer.net/javascript/firstgrunt.html
インストールして出来上がったgruntfile（コンパイルの設定みたいなの）をいじります。
gruntfileはこんな感じです。

```javascript:
// 'use strict';
module.exports = function(grunt) {
  grunt.initConfig({
  watch: {
      coffee:{
        tasks: 'coffee',
        files:['../project/coffee/**/*.coffee']
      }
  },
  coffee:{
    compile:{
      files: {
        '../project/public/js/main.js': ['../project/coffee/**/*.coffee']
      },
      options: {
        bare: true,
        sourceMap: true
      }
    }
  }
  });
  grunt.loadNpmTasks('grunt-contrib-coffee');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.registerTask('default', 'coffee');
};
```
ここでファイルがうまく結合できなくて、ハマってしまった記憶があります。
確か解決策はoptoinsのbare: trueでした。

ディレクトリ構成はこんな感じです（いろいろ省略）

>
coffee/
　　├ !app/
　　│　　├ !enchant.coffee
　　│　　├ app_game.coffee
　　│　　├ app_sprite.coffee
　　│　　├ ・・・
　　├ game/
　　├ scene/
　　├ sprite/
　　│　　├ object/
　　│　　├ effect/
　　│　　　　　├ _effect.coffee
　　│　　　　　├ cut\_in.coffee
　　├ ・・


文字列順でファイルが結合されていくので、
親クラスなど先に読み込みたいファイルには!とか\_とか付けて調整してます。
フォルダ名には、game, scene, spriteなど、
親になるenchant.jsが持っているクラス名などを付けて、用途によって分類しています。

その他、当時参考にした記事です。興味のある方は見てみてください。
http://tmlife.net/programming/javascript/coffeescript-gl-enchant-js-15-minutes-3d-game.html
http://d.hatena.ne.jp/h6n/20111125/1322169941

## 変わったこと
フォルダやファイルで細かく分けたのでソースの場所がわかりやすくなりました。
あと、クラスの書き方がスッキリしました

```javascript:before
var Yukipo = enchant.Class.create(Enemy, {
        initialize: function (scaleX, scaleY) {
             Enemy.call(this, scaleX, scaleY);
```
↑これはenchant.jsに標準で用意されてるクラスの作り方みたいです。

```coffeescript:after
class Yukipo extends Enemy
    constructor:(scaleX, scaleY)->
        super scaleX, scaleY
```

coffeescriptなので全体的にスッキリしてます。
快適です。

## さいごに
開発環境が快適になると、コーディング作業も楽しくなります。
次回はゲーム開発をより快適にするための、デバッグと単体テストのやり方を解説したいと思います。
New Relic APM: 異常値のトランザクションを簡単に特定して、正確なパフォーマンス情報を把握しよう

アドベントカレンダー14日目も New Relic APM から。New Relic APM の Overview ページをみると、まっさきに目につくのが、レスポンスタイムの時系列チャートです。このチャートをみると、現在や特定の時間帯のレスポンスのパフォーマンスが一目で把握できます。

ただし、このチャートは、平均のレスポンスタイムのチャートなので、レスポンスタイムが急激に遅くなっていた場合に、それが、全体的におそくなっているのか？ それともある以上に遅い特定のトランザクションによって、平均が底上げされているのかまではわかりません。

そこで、そういった異常値を簡単に把握する方法が、**ヒストグラムチャート**と**パーセンタイルチャート**です。

その名の通り、ヒストグラムチャートは、ヒストグラム(度数分布) で指定されている時間帯のトランザクションを表現します。パーセンタイルチャートも同じく、パーセンタイル形式で指定されている時間帯のトランザクションを表現します。

ここでは、それぞれのチャートについて説明していきます。その前に、これらのチャートを表示する方法から始めていきます。

## 表示方法

パーセンタイルとヒストグラムチャートは、メインチャートだけでなく、平均を表しているような APM の大体のグラフで利用できます。表示方法は、チャートタイトルの横のドロップダウンをクリックすると、下にチャート形式選択欄が表示されます。左が、時系列チャートで、真中が、ヒストグラム、右がパーセンタイルとなりますので、好きな形式をクリックすると、切り替わります。

![nr_apm_histgram_percentile_01.png](https://qiita-image-store.s3.amazonaws.com/0/46003/bd011a3e-5eb1-2e52-dc61-b814edcf2f8d.png)

## ヒストグラムチャート

![2016-10-13_apm_histgram.png](https://qiita-image-store.s3.amazonaws.com/0/46003/697b3333-b1df-1e1b-8766-f849f0311da6.png)

ヒストグラムは、レスポンスタイムを横軸に、トランザクション数の割合を縦軸に、指定している時間帯の全トランザクションを対象にグラフ化します。このグラフをみることで、異常値ががあった場合は、簡単に知ることができます。

分布に何か気になるトランザクションを見つけたら、チャートのバーをクリックすると、そのバーの範囲で発生したトランザクションのトップ5を見ることができます。

また、さらに細かい時間別でヒストグラムをみることもできます。チャート下部の「Explore timeline」 をクリックすると、チャート下に時系列チャートが表示されます。チャート下のツマミを移動することで、１分単位のヒストグラムを確認できます。

![2016-10-13_apm_histgram_with_timeline.png](https://qiita-image-store.s3.amazonaws.com/0/46003/8bb5451a-fd0e-2524-c1d5-3f549d84eb54.png)



## パーセンタイルチャート

![HistPercImage2-1024x429.jpe](https://qiita-image-store.s3.amazonaws.com/0/46003/29ae1398-f133-3b92-4d36-d96afb86a3f4.jpeg)

パーセンタイル形式のチャートでは、指定時間における全トランザクションを平均値(Average)、中央値(Medium)、95パーセンタイル(95%番目)、99パーセンタイル(99%番目)をトランザクションを一つのグラフで見ることができます。

注: デフォルトでは、99% は表示されていないので、99% のラベルをクリックして、表示する必要があります。バグってのか、デフォルトでラベルが ON になっているけど、表示されていないので、２回クリックしないと表示されない。

上記のチャートのように、平均レスポンスタイムは一定の一方、95パーセンタイルは変動が激しいという状況に出くわすことがままあります。このチャートではこれが、何を意味しているかというと、少数のユーザーにキャッシュ問題が発生していたということです。この問題を修正すると(上記のチャートの17:40から45の間)、95パーセンタイルもフラットな表示になったのがわかります。

## まとめ

ここで説明したように、平均のレスポンスタイムからは見えてこない、パフォーマンス問題を正確に把握するために、是非、ヒストグラムやパーセンタイルも活用してみてください。
TPI NEXT®導入による品質管理のプロセス改善について

## はじめに
12/14の投稿を担当させていただきます株式会社 ノハナで品質管理を担当している田井です。　
ノハナでは毎月１冊無料（送料別）で作成できるフォトブックアプリや、スマホから簡単に作成できる年賀状アプリを提供しています。
テスト専門会社に7年ほどいましたが、今年の4月からノハナの品質管理グループで働いています。
今回はプロセス改善モデル「TPI NEXT®」の弊社への導入事例についてお話ししたいと思います。

## TPI NEXT®とは？
TPI NEXT®とはオランダのSogeti社が提案したもので、日本語訳の本も発売されており、日本でも認知度が徐々に高まっているプロセス改善モデルです。
簡単に概要を説明しますと、大きなグループが３つあり、それぞれにキーエリアがあります。その中にチェックポイントがいくつかあり、チェックポイントに答えることにより、自社の到達レベルを確認することができます。
レベルは初期レベル、コントロールレベル、効率化レベル、最適化レベルと4つあります。チェックポイントにもAからMまで優先度がついていて、Aの方が優先度が高くなります。内容によっては当てはまらないチェックポイントもあるので、弊社では「N/A」としています。

以下は弊社で管理しているスプレッドシートとなります。チェックポイントを達成すると色が変わり、到達率などがわかるようにしています。

![名称未設定.png](https://qiita-image-store.s3.amazonaws.com/0/151058/f4323ce8-c97a-8aa8-6e3b-33e8d8dc756b.png)

## TPI NEXT®との出会い
弊社の品質管理グループがTPI NEXT®を知ったきっかけは、私が入社する前の2016年3月に開催された「JaSST'16 Tokyo」でした。品質管理グループのメンバーが参加し、TPI NEXT®を使えば品質管理業務が改善できるのではと検討を始めました。また、上層部へ品質管理グループとしての任務を明確に示せるのではないかということも導入の理由です。
それからTPI NEXT®の日本語訳本を購入し、関連セミナーやイベントに参加し、徐々に準備を進めていきました。

## 最初にしたこと
TPI NEXT®導入にあたり、弊社でまず何をしたかというと、現状把握を行いました。　
そもそもTPI NEXT®の指標だと自分たちはどのぐらいの位置にいるのだろうかと。

結果として、以下のようになりました。
![レーダーN.png](https://qiita-image-store.s3.amazonaws.com/0/151058/346fa72a-271f-b6d7-9329-7d09d62c0fba.png)

レーダーチャートを見ていただくとわかると思いますが、コントロールレベルに達しているのは「テストケースデザイン」と「手法の実践」の2つで、偏りもとても大きいことがわかりました。メトリクスについては全く対応しておらず初期レベルであることも判明しました。
スマホ向けアプリというリリースサイクルが短い特性上、ガチガチにテスト計画から行って行くことも工数的に厳しいので、自分たちの現場にあった改善策を優先的に検討することとしました。

## メルカリ社のテストチームとの連携
改善していくにあたり、メルカリ社のテストチームと連携も行っています。定期的にミーティングを行い、お互いの現状報告を共有したりしています。
そこで見えてきたことは、先ほどあったレーダーチャートの形が全く違うことでした。自社でまだコントロールレベルのところが、最適化レベルだったり、会社ごとの文化などが大きく影響しているようでした。
従って、メルカリ社側でまだ改善が必要な点があれば、弊社で実施していることを提案してみたり、逆に自分たちに改善が必要な点はメルカリ社からのアドバイスをもらったりしています。
お互いに切磋琢磨して品質向上に努めています。

## 改善策
自分たちがやらなくてはいけないことがわかったら、次は改善策を検討しなくてはいけません。
今回はテスト業務に密接である「テスト管理」と「テスト業務の専門性」内のDレベルまでを、半期で全てコントロールレベルにすることを目標としました（スプレッドシート参照）。Eについては半期での目標とするには工数が不足するため、余力があれば行うということにしました。
チェックポイントに優先度はAからついていますが、必ずしもAから実施するのではなく、自社でどの部分を強化したいかを検討して実施していくのが良いのかなと感じました。
各チェックポイントに対して達成するにはどのような施策を行えばよいかをグループ内で検討し、実際に施策を1つずつ実施しています。

## 最後に
TPI NEXT®は継続していくものなので、すぐに結果が出るものではないと思います。　
ただ、自分たちがどこに向かっているのか、目標はどこなのかが明確になりましたし、目標達成には何に取り組めばよいかということもわかりました。
そういった点で、TPI NEXT®に取り組んで良かったと感じています。

また、TPI NEXT®だけで判断するのではなく、その他の判断基準も併用することにより、より一層業務改善ができるのではと感じています。

TPI NEXT®に興味のある方、ぜひ協力していきましょう！
あの日増えた容量の大きさを僕はまだ知らない

最近ネイティブアプリでは**ヨウリョウガ！ヨウリョウジャ！**といった某FFの強力魔法みたいな言葉が飛び交っておりますが（飛び交っていない）、
基本的に新キャラ追加とか新シナリオ追加を行うとヨウリョウガ！ヨウリョウジャ！が発動するのは当たり前です。詠唱条件満たしてしまっています。MP？知りません。

開発段階で運用を想定した設計や仕組みを考えておかなければいけないですが、
実際に運用が始まらないと分からないことがほとんどなので、
正直開発段階で完全な設計や仕組みづくりは出来ないと思っています。
（もしくは運用2年後ぐらいからタイムリープしてくればあるいはいや待てもしかしたら）
ちょっと論点がズレてますね。修正。

今回は容量削減の中でも画像周り（他にも応用は効くと思います）でとりあえずやってみたことを書いておこうと思います。


##1.テクスチャ設定を見直す##
一番手っ取り早く、取りかかりやすいです。
ここは各自使うものによって変わると思います。
特にFilterの設定はしっかりした方が良いです。
（うちのプロジェクトは初期バッラバラでした）


##2.アトラスを利用する##
容量削減というよりは、リソースの管理と無駄を省くという意味の方が強いかもしれません。
・テクスチャの読み込み枚数を減らせる
・正方形化されてない画像を正方形の画像にまとめておくことで無駄な処理を省ける（iPhoneとかでの描画のお話）
・リソースの視認性を高める（管理が杜撰だったら視認性も糞もないです）
特定のシーンUIのリソースがアトラス化されておらず、
1シーンで大量のテクスチャを読み込んでいる･･････なんてこともありました。
低スペック端末だと表示できないとかもあります。
リソースの管理は計画的にしましょう。


##3.アセットバンドルをまとめる##
運用をしていくと色んな施策としてイベント用ガチャだったり、
イベント用シナリオとかを行うというのは往々にしてあると思います。

その度にDLCが発生し、ユーザーの端末にリソースがダウンロードされてきます。
しかし、イベント期間が過ぎた後も端末内にイベントのリソースが残っているのはよろしく無いはずです。

DLC時に不要なデータが残っている場合削除する等、何かしらの機能を実装しておけば問題はありませんが、
それ以外の方法として必要なリソースだけを常にアセットバンドルにまとめるようにしておくという方法でも改善できると思います。
（ガチャやイベントなどの頻繁に更新され、プレイヤーのデータに対して影響の与えないレベルの物）


##外伝:9スライスを活用する##
今関わっているプロジェクトで一番無駄が多いなと思ったところの一つがコレでした。
ポップアップやボタンを使用するサイズで出力されていることが多かったので、一人で首を傾げていました。
ウィンドウやボタンのUIを組むときには、9スライスを利用して作ることをお勧めします。
9スライスについては調べてみてください。（無慈悲）

簡単に説明すると、
![ss_9s_01.png](https://qiita-image-store.s3.amazonaws.com/0/34019/7fec87e7-6f96-2a79-d0a9-817fee6ad501.png)
普通に画像サイズが128x26のものでボタンを配置するとき、widthに128、Heightに26と指定すると思います。

このままサイズを変更しようとすると以下のようになります。
![ss_9s_00.png](https://qiita-image-store.s3.amazonaws.com/0/34019/c1ce77b4-92d3-04b6-1acd-dc32038dc625.png)
これだと100x100の画像も用意しないといけなくなります。


そこで9スライスです。画像に対してBorderを設定することで
中央のブロック部分だけを引き延ばす対象にして、
それ以外のブロックは固定して使用することができます。
![ss_9s_04.png](https://qiita-image-store.s3.amazonaws.com/0/34019/a68ec012-a689-f48f-a47c-7c05faa3b2ef.png)
※画像ではLeftとRightのBorderだけを設定している

するとwidthをいくら設定しても両端部分は画像が崩れずに
引き延ばすことができます。
![ss_9s_05.png](https://qiita-image-store.s3.amazonaws.com/0/34019/a38d79e4-412c-e1ad-cabb-569b69e00490.png)
※オレンジ色の方は同じ画像の色違いでBorderの設定無

![ss_9s_06.png](https://qiita-image-store.s3.amazonaws.com/0/34019/bcaa70ec-5a93-8a5a-a3ff-95b605093f72.png)
違いが分かりやすいです。
borderを設定している方は丸い部分の形が崩れていません。


もっと言うとこういう風なこともできます。
![ss_9s_07.png](https://qiita-image-store.s3.amazonaws.com/0/34019/70e7c732-a2eb-65bb-1803-2f91d31a9053.png)
（横幅に画像サイズ以下の数値を指定）

![ss_9s_08.png](https://qiita-image-store.s3.amazonaws.com/0/34019/97927707-2493-6fbf-8093-2e8defb2f9ef.png)

これを利用すればウィンドウやボタンの画像の縦横幅を最低限まで小さくできます。
そうすれば
・画像自体も小さくなる
・アトラス化の際に領域を無駄に使ったりしないので他の画像を入れるスペースだって出来る
・そもそものアトラス自体のサイズも小さくできる！
やったね！

ただし、装飾があるような場合は9スライスが利用しづらいので、
そのまま使うかデザイナーとの相談が必要です。
（装飾の一部分だけが引き延ばされると見栄えが悪い）


##まとめ##
最終的に9スライス使いましょうって話になってしまった感が否めない……
ですが、**ヨウリョウガ！**や**ヨウショウジャ！**は運用が続く限り、避けては通れないので
しっかり対策は考えていかなければいけません。
みなさんも何か良い方法とかご存知であれば、教えてください。


*あれ･････････？*
*これってエンジニアの記事なのだろうか･･･*
Swiftについての覚書３

#Core Dataプロジェクトを作る
まずはCore Dataを使うためにプロジェクトの作り方からです。
![coredata1.png](https://qiita-image-store.s3.amazonaws.com/0/150621/e3d3b0e7-4455-4ad4-a72e-a15fd165446e.png)
「Use Core Data」にチェックをつけて、プロジェクトを作成。

#Entityの設定
チェックをつけてプロジェクトを作成すると、〜.xdatamodeldというファイルが作成されます。
![coredata2.png](https://qiita-image-store.s3.amazonaws.com/0/150621/e9b0d76f-181a-4bb5-d1b4-7c784e184cac.png)

そのファイルを選択します。
「Add Entity」をクリックするとEntity名が編集可能になります。
![coredata3.png](https://qiita-image-store.s3.amazonaws.com/0/150621/45619e24-a833-8100-f99e-ca1b344ea6e4.png)
「＋」を選択してカラム名と型を設定します。
![coredata4.png](https://qiita-image-store.s3.amazonaws.com/0/150621/5ca9820a-a1f8-d7db-cf7b-959935e634ae.png)

#モデルクラスを生成
![coredata5.png](https://qiita-image-store.s3.amazonaws.com/0/150621/435b6bc6-f045-2557-06c1-3e3d3baedea2.png)
「Editor」メニューから「Create NSManagedObject Subclass...」を選択します。

![coredata7.png](https://qiita-image-store.s3.amazonaws.com/0/150621/58eef35a-463b-219b-3d4d-36980b4a9868.png)
チェックを入れて「Next」

![coredata6.png](https://qiita-image-store.s3.amazonaws.com/0/150621/bf01e1d4-e666-9206-da39-d29f3ad46e2f.png)
もう一回チェックを入れて「Next」

![coredata8.png](https://qiita-image-store.s3.amazonaws.com/0/150621/21db9225-aaae-affe-4368-71eed7325c5f.png)
するとこんな感じでファイルが作成されます。

次回は検索、更新などについて書きたいと思います。
二児のパパエンジニアの日常

これは[子育てエンジニア AdventCalendar 2016](http://qiita.com/advent-calendar/2016/kosodate-engineer)の12/14の記事です。

2人の子供をもつ30台前半エンジニアのbwtakacyです。
10代、20台の頃は「絶対結婚しないよね」と周りから言われていた自分ですが、30歳の時に結婚してあれよあれという間に2人の子供のパパになりました。妻とともに子育てに奮闘している毎日です。

最初は、育児のために転職した話をかこうかなーと思っていたのですが、書き始めて見ると他人に共有できない闇ができてしまったため止めて、自分の生活の様子を伝える方針にしました。

子育ては、子供や父親の育児参加スタンスによって本当に異なると思うので、あくまで一例でしかありませんが、こんな感じですよーという事例共有になれば幸いです。

# 家族構成

* 私
  * 都内勤務のエンジニア
  * 長女が産まれた直後に転職
* 妻
  * 都内勤務（エンジニアではない）
  * 育児休職中
* 長男：2歳　
  * 公立の保育園に入れるも、市の方針により長女が生まれた直後に一時退園させられてしまう
  * 現在は、私立の認可外保育園に通わせています
* 長女：0歳
  * 今年の5月に生誕


# 子供が生まれる前後で変わったこと

とにかく、子供中心に生活が回るようになります。

乳幼児の頃は、ミルクやお風呂、寝かしつけ。
保育園に行きだしてからは保育園の送り迎えやイベント対応、熱を出した時の対応。

妻が育休を取っているとはいえ、ワンオペでは倒れてしまう（実績あり）ため、できる限り育児に参加するようにしています。

とにかく無意味に会社に残ったり、飲みに行ったりすることは無くなりました。


## 困っていること

妻の実家にヘルプを頼みやすくするため、引越しをしました。
そのため、通勤時間が大幅に伸びて1時間半近くかかるようになってしまいました。

それまでは、職場まで30分から40分程度だったので、身体的にも精神的にも結構な負担増です。

また、通勤に時間がかかるため、飲み会や勉強会などはほとんど参加できなくなりました。
このあたりは自分にとっても辛いところです。。。


# 育児と自分の勉強を両立する方法

子供が寝るまでは何もできません。
一旦寝ても、ミルクで起きたり、機嫌が悪くて起きてしまったりするので、運が悪いと睡眠時間はガリガリ削られます。

とはいえ、子供が寝てからは貴重な時間なので、ある程度の睡眠時間が削られるのは覚悟で夜の時間を勉強に当てています。

## 平日の平均的なスケジュール

7:00　　　起床、朝ごはんを食べさせる、保育園の用意など
8:00　　　上の子を連れて出発。最寄駅の途中にある保育園に子供を送り届ける
8:40　　　最寄駅に到着
10時過ぎ　職場到着

勤務

18:30　　　会社を出る
20:15頃　　帰宅　=> 上の子をお風呂に入れる
21:00　　　寝かしつけ、その後、夕食
~
22:00 　　勉強
~
26:00 　　就寝

休日も日中は子供を遊びに連れて行ったり、買い物にいったりするので、ほぼ同じです。

あとは、転職してリモートワークができるようになったので、週に一度はリモートワークをしているので、保育園の迎えもその日は行なっています。


以上。
簡単な何かを消す方法

この記事はAfterEffects Advent Calendar 2016の14日目の記事です。

http://baaaf.com/neta_16.html
昨日はBaKaAfterさんで、開くとAEが死ぬデスファイル(aep)　でした。
この記事が無事に公開されたので先程開きました。落ちました。

こんばんわ。メツヤです。

ビデオで撮影した動画を編集する時に、後ろで人が歩いていたり、
いらない物が映っていて「消したいなぁ～」って思う事が稀によくあります。

今回は「簡単な何かを消す方法」というタイトルですが、つまりバレ消しについて説明します。

バレ消しとは…
画面内に映ってしまった不要なものや、見せたくない物などを消す作業のことです。
「後ろにいるめっちゃ動くカメラマンを消す」とか、
「鏡に映っている自分を消す」という講座でもやろうと思ったのですが、

あまりにも説明が長くなる&結局は1フレーム1フレーム愛をこめてキーフレームを増やすだけなので、
今回は簡単なバレ消しにしました。
CCからの機能で、「トラックマスク」という機能がありますが、
CS世代の生き残りの為にも、今回はトラックマスクを使用しないバレ消し方法です。

やり方を載せたスクリーンショット祭りにしても、
やった事ない人からすれば、ふーーんそっかーーー（高速流し見）ってなると思うんですよね。
なので、映像をキャプチャーして、その映像内に説明を入れて投稿すれば良いのでは？と思ったので、
今回は動画を用意しました。
本当は動画のリンクだけ貼って終わろうと思っていたのですが、
レンダリング中暇だったのでちょっと記事を書きました。プレーンテキストかよって感じですが。

バレ消しといっても、３行で説明すると、

1.消したい箇所に対してトラッカーを使用して
2.バレ消し用のマスクを追従させ
3.マスクを適度にキーフレームを打つ！

という内容になっています。

細かいことをいうと、
本当なら調整レイヤーにするとか、トランスフォームエフェクトでズラして他の箇所から持ってくるとか、
色々あるんですが、簡単なバレ消しなので、簡単なエフェクトのみです。

こちらが動画になります！どうぞ！
[![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/SPuuihAewpg/0.jpg)](http://www.youtube.com/watch?v=SPuuihAewpg)


明日はTo7さんによる
「ディスプレイスメントマップの活用法」です！
ペアワークのすゝめ

この記事は[株式会社ネクスト(Lifull) Advent Calendar 2016](http://qiita.com/advent-calendar/2016/lifull)の14日目です。
こんにちは。株式会社ネクスト QAGの福沢です。

仕事の効率向上のため "ペアワーク" というものを10月から取り入れ実践してきました。
弊社の中でもペアワークを取り入れているのは、(恐らく？)自部署だけだろうということで、
この活動内容と結果を共有していきたいと思います。


# ペアワークって何?:dolls:

今年のSQIP(Software Quality Profession) というソフトウェア品質のシンポジウムで、
[アジャイルプロジェクトにおけるペアワーク適用の改善事例](https://www.juse.jp/sqip/symposium/timetable/files/happyou_B4-2.pdf) という発表がありました。 (※2018.02.02現在リンクが切れています)
こちらから引用しますとペアワークとは、
> ・ アジャイル開発のプラクティスの1つ
> ・ 2人の開発者が1つのコンピューターを共有して作業

というものになります。これだけ覚えていればとりあえず大丈夫です。
社内で具体的にどのように進めていったかというのは次に書きます。

# ペアとタスクの割り当て:sunny:
ペアワークを始めるにあたり、まずはタスクとそのタスクを担当するペアを決めないといけません。
ペアの割り当ては朝会で決めていきます:sunny:

朝会でそれぞれのタスクに対して担当する2人ないしは3人のペアを決めます。
ペアを決める時は、
そのタスクについて詳しい人 or 過去に同じような内容のタスクを担当したことがある人
を優先的にそのタスクを担当してもらいます。
![無題のプレゼンテーション (4).png](https://qiita-image-store.s3.amazonaws.com/0/88603/1e6542c1-91d4-9edf-7714-3bbc141a4650.png)


これは、タスクに詳しい人とそうでない人をペアにすることで、
そうでない人にも情報や知識を共有していくためでもありますし、
タスクを消化するスピードを上げるためでもあります。

特に誰もそのタスクを担当したことがない場合は、適宜割り当てを行います。

作業の進め方については次に書きます。

# ペアワークでの作業の進め方:point_up:
上記の資料のペアワークでは、
> 2人の開発者が1つのコンピューターを共有して作業

という定義でしたが、私たちの部署では以下の2パターンにのどちらかを
選んでタスクを進めていきます。

#### A. 1人が作業もう1人がサポートに徹する アクティブ ✖️ サポートパターン
#### B. 2人とも並列に作業を進める アクティブ ✖️ アクティブパターン
![無題のプレゼンテーション (5).png](https://qiita-image-store.s3.amazonaws.com/0/88603/ff028832-a776-6a8b-6238-87e4a2a100d0.png)

パターンAの場合は、1人は有識者でもう1人は初心者の場合に行い知識を
共有しながらタスクを進めていきます。ペアプログラミングのような感じですね。

もう一方のパターンBは、2人ともある程度タスクに対する知識があるという状況で、
タスクを分担することでタスクの消化率を上げていきます。 

# ペアワークをしてきて良かったこと :sparkles:
ペアワークを実践してきたことで、良いなと思うことを挙げていくと

* タスクの消化スピードが上がった。
* 以前より、タスクの属人化が減ってきた。
* タスクを共有する労力が減った。
* コミュニケーションの量が増えた。
* 何か手詰まった時もすぐに相談できるようになった。

良いことづくしですね。

# 改善できそうなことは、KPTで改善:sunglasses:
ペアワークを進めていくにあたり、やりにくい所は定期的に見直して、
やりやすいように適宜ルールを変えていくのが良いと思います。
私たちの部署では、1週間に一度 KPT (振り返り会)を開催し、
一週間の良かったこと(Keep)、悪かったこと(Problem)、改善点(Try)を出し合います。
この時にペアワークの進め方についても話し合い改善に繋げています。

例えば、
ペアワークでやっていると、休憩なしで進んでしまい後半の生産性が落ちてしまうという課題が出たのですが、
そこは遠慮なく休憩取っても良いよというように変えました。
また、ペア同士でタスクを進めるにあたって席を隣同士で仕事できるように
チーム内の席をフリーアドレスに変えました。
このようにチーム内でやり易いようにルールを決めていけるので、
最初にペアワークを始めた時より、改善されていると思います。

# まとめ　
ペアワークいかがでしたでしょうか？
ペアワークを取り入れることで、困っていることもすぐに相談でき、
タスクの属人化防止にも繋がります。
皆様のチームでもペアワークの採用どうでしょうか？ おすゝめ致します。:blush:

以上です。
単純な衝突判定

# はじめに
　
今回は最近３Dを触り初めたので３Dの衝突判定について書こうと思います。
### 自己紹介
 HAL大阪ゲーム学科2年のゲームプログラマ目指してる人です。
[@konojunya](https://twitter.com/konojunya) にアドベントカレンダーに誘われ書くことになりました。
アドベントカレンダーは今回が初めてです。
# 境界ボリューム（ Bounding Volume,BV)

### 境界ボリューム（ Bounding Volume,BV)とは
　単体の単純なボリュームで複雑なオブジェクトを包んで判定を簡単するというものです。
単純なボリュームを使うことで複雑なオブジェクトと比べて重なりの判定にかかる時間が短いです。



### いい境界ボリューム 

-  交差判定のコストがかからない
 
-  オブジェクトの形に密着している
 
- 計算に時間がかからない
 
- 回転と移動が簡単である

-  わずかなメモリのみ使用

# 軸平行境界ボックス(AABB:Axis-Aligned Bounding Box）
### 軸平行境界ボックス(AABB:Axis-Aligned Bounding Box）とは
　軸平行境界ボックス(AABB:Axis-Aligned Bounding Box）は最も一般的な境界ボリュームの１つです。
直方体３Dの場合は６つ、２Dでは４つの面を持つボックス型で、各面の方向はその面の法線が常に座標系の軸に対して平行になっています。AABBの最大の特徴は重なりの判定が高速に行えることです。  

![アセット 1.png](https://qiita-image-store.s3.amazonaws.com/0/62873/5a9d6b91-1007-85ab-7a8e-3ca277a71144.png)

``` cpp:AABB(1)
struct AABB {
  D3DXVECTOR3 max;
  D3DXVECTOR3 min;
};
```

``` cpp:AABB(2)
struct AABB {
  D3DXVECTOR3 min;
  float d[3];
};
```

``` cpp:AABB(3)
struct AABB {
  D3DXVECTOR3 center;
  D3DXVECTOR3 r[3];
};
```
コードにしたらこんな感じです。

##  実装
（１）の最小-最大の判定を簡単に書いてみた。
このコードの使い勝手はおいといて、、、、
取り敢えず、最大値と最小値と当たり判定を取りたいオブジェクトの座標を渡します。
オブジェクトが移動するとupdateでオブジェクトの座標を渡しバウンディングボリュームを更新します。
intersectAABBで判定したいAABBを渡してあげておわりです。


``` cpp:AABB.h
struct AABB {
	D3DXVECTOR3	min;            //      最大値
	D3DXVECTOR3	max;            //      最小値
	D3DXVECTOR3 actorOldPos;         //      前の座標値
	AABB() = default;
    ~AABB() = default;
	AABB(D3DXVECTOR3 minValue, D3DXVECTOR3 maxValue, D3DXVECTOR3 actorPos) {
		min = minValue;
		max = maxValue;
		actorOldPos = actorPos;
	}
// 更新
	void update(const D3DXVECTOR3& actorPosition) {
		D3DXVECTOR3 diff =  actorPosition - actorOldPos;
		min += diff;
		max += diff;
		actorOldPos= actorPosition;
	}
};
// AABBとAABBの衝突判定
inline bool intersectAABB(const AABB& box1,const AABB& box2) {
	if (box1.min.x > box2.max.x) return false;
	if (box1.max.x < box2.min.x) return false;
	if (box1.min.y > box2.max.y) return false;
	if (box1.max.y < box2.min.y) return false;
	if (box1.min.z > box2.max.z) return false;
	if (box1.max.z < box2.min.z) return false;
  return true;   // 衝突！！
}
```

# 終わり
もっと書くはずだったのに（）
# 参考文献  

~~もっと参考にするはずだった~~最高の技術書
[ゲームプログラミングのためのリアルタイム衝突判定](https://www.borndigital.co.jp/book/164.html)
[ゲーム３D数学](https://www.oreilly.co.jp/books/9784873113777/)
[ゲームアプリの数学Unityで学ぶ基礎からシェーダーまで](http://www.sbcr.jp/products/4797384260.html)
[ゲームプログラミングのための３Dグラフィックス数学](https://www.borndigital.co.jp/book/849.html)
iOSで動くRubyについて

普段はCRubyやJRubyを使っている人が多いと思いますが、今日は私が開発しているiOSで動くRubyを紹介します。

## RubyPico
http://rubypico.ongaeshi.me/

ファイルビューワ、エディタ、実行環境を含みます。(無料です)

[App Store](http://rubypico.ongaeshi.me/ja/download.html)からダウンロードできます。

## irb
スマホからirbが使えます。Rubyの文法をちょっと確認したりするときに便利です。

![rubypico-advent-01.png](https://qiita-image-store.s3.amazonaws.com/0/3885/1f36ff22-24f0-6f26-6ccd-a0e0683eb050.png "rubypico-advent-01.png")

irb自体もRubyPicoを使って書かれています。見慣れたRubyのコードに近くないですか？

```ruby
# # irb
#
# ## Description
# Interactive Ruby Shell (REPL).

puts "irb - Interactive Ruby Shell"
no = 0

loop do
  print "irb:%03d> " % no
  cmd = gets
  
  puts cmd
  
  break if cmd == "exit"
  
  begin
    puts "=> #{eval(cmd).inspect}"
  rescue Exception => e
    puts e.message
  end
  
  no += 1
end
```

## LINE Notify
[POSTメソッド](http://ongaeshi.hatenablog.com/entry/2016/11/14/235638)が使えるのでLINE Notifyが送れます。GETメソッドを使いたいときはBrowser.getです。

```ruby
TOKEN = "XXXXXX"

def post(message)
  Browser.post(
    "https://notify-api.line.me/api/notify",
    header: { "Authorization" => "Bearer #{TOKEN}" },
    body: { message: message }
  )
end

if $0 == __FILE__
  loop do
    post prompt
  end
end
```

## Gistに投稿
[Browser.post](http://ongaeshi.hatenablog.com/entry/2016/11/13/005602)を使ってGistに投稿もできます。

```ruby
# https://developer.github.com/v3/gists/#create-a-gist
json = {
  description: "Created by RubyPico at #{Time.now}",
  public: true,
  files: {
    "file1.txt" => {
      content: "updated file contents"
    },
    "old_name.txt" => {
      filename: "new_name.txt",
      content: "modified contents"
    },
    "new_file.txt" => {
      content: "a new file\nあいうえお"
    },
  }
}

puts Browser.post(
  "https://api.github.com/gists",
  header: { "Authorization" => "token XXXXXXXX" },
  json: json
)
```

## まとめ
普段Rubyを使っている人ならすぐに使いこなせると思います。マニュアルの整備はまだまだなので分からないことは気軽に[@ongaeshi](https://twitter.com/ongaeshi)までどうぞ。

Appタブという自作スクリプトを[簡単に呼び出すための仕組み](http://ongaeshi.hatenablog.com/entry/rubypico-0.9.2)も用意されているので、簡易ランチャーやWeb APIを叩くための便利ツールとしてお使いください。

それではスマホでも楽しいプログラミングを！
PostgreSQL付属のリグレッションテストでトランザクションを学んでみる

これは[PostgreSQL Advent Calendar 2016](http://qiita.com/advent-calendar/2016/postgresql)の14日目の記事です。　　

# これは何?
トランザクションを勉強し始めたけれど、本や記事を読んでいるだけでは分からない。自分の手でSQLを書きながら勉強したいからとりあえずPostgreSQLをインストールしたけれど、何かお手本がないとつらい。。
そんな時はPostgreSQLのソースコードに付属しているテストをお手本になるかもしれないという記事です。今回はデッドロックを起こすテストケースを例に説明します。

# PostgreSQLのRegression Test
## ソースコードの入手
PostgreSQLの[ソースコード](https://www.postgresql.org/ftp/source/)を落とします

```shell-session
$ wget https://ftp.postgresql.org/pub/source/v9.6.1/postgresql-9.6.1.tar.gz
$ tar xf postgresql-9.6.1.tar.gz
$ cd postgresql-9.6.1/src/test/isolation
``` 
`src/test/`配下には多くのテストが含まれています。今回は`isolation/`配下のテストに注目します。

## isolation testを見てみる
`README`を見ると一つのデータベースに対して複数のトランザクションが同時に実行された時の動きをテストするものだと分かります。実際、ディレクトリのタイトルも`isolation`(分離性：複数のトランザクションが互いに影響を与えないこと)となっています。
>This directory contains a set of tests for concurrent behaviors in
PostgreSQL.  These tests require running multiple interacting transactions, which requires management of multiple concurrent connections, and therefore can't be tested using the normal pg_regress program.  ....

テスト自体は`specs/`配下[^1]にあります。
今回は、デッドロックの勉強をしたいとします。`deadlock-hogehoge.spec`ファイルはいくつかありますが、分かりやすそうな`deadlock-simple.spec`をお手本にします。
このファイルはあるテーブル`a1`にs1さんとs2さんの二人が共有ロックを掛けた状態で、交互に専有ロックを掛けようとしデッドロックが起きるいうシナリオです。

ファイルの中身を見ます。

```css:deadlock-simple.spec
setup
{
  CREATE TABLE a1 ();
}

teardown
{
  DROP TABLE a1;
}

session "s1"
setup           { BEGIN; }
step "s1as"     { LOCK TABLE a1 IN ACCESS SHARE MODE; }
step "s1ae"     { LOCK TABLE a1 IN ACCESS EXCLUSIVE MODE; }
step "s1c"      { COMMIT; }

session "s2"
setup           { BEGIN; }
step "s2as"     { LOCK TABLE a1 IN ACCESS SHARE MODE; }
step "s2ae"     { LOCK TABLE a1 IN ACCESS EXCLUSIVE MODE; }
step "s2c"      { COMMIT; }

permutation "s1as" "s2as" "s1ae" "s2ae" "s1c" "s2c"
```
上記ファイルの`setup`などのキーワードはテストの自動実行をする際に利用されるものです。`{}`の中にはSQL文が入ります。

| 構文       |       役割 |
|:-----------------|:------------------|
| setup {}            | テスト開始時に実行            | 
|teardown {}|テスト終了時に実行|
|session "hoge"|"hoge"という名前でデータベースに接続|
|step "stepName" {}|各SQLに"stepName"という名前を付与|
|permutation "stepName1" "stepName2"|SQLを実行する順番をstep名で指定|

## isolation testを参考に自分でデッドロックを起こしてみる
上記のファイルに基づいて自分でデッドロックを起こしてみます。

1. ターミナルを二つ立ち上げ`psql`コマンドを打ちます
2. `create table a1 ();`
3. 後は、二つのターミナルで交互に`permutation`に書かれた順番でSQLを書いていきます。
4. デッドロックが起きるのを確認する  
実際の実行結果は下記のようになりデッドロックが起きたことが確認できます。
 
```shell-session
test=# lock table a1 in exclusive mode;
ERROR:  デッドロックを検出しました
DETAIL:  プロセス 13154 は ExclusiveLock を データベース16385のリレーション26561 で待機していましたが、プロセス 13077 でブロックされました
プロセス 13077 は ExclusiveLock を データベース16385のリレーション26561 で待機していましたが、プロセス 13154 でブロックされました
HINT:  クエリーの詳細はサーバログを参照してください
```
# まとめ
この様にisolation testをお手本にすることでデッドロックを学ぶことができました。
他にも複数のテストがあるので、それを自分の手で実行することでデータベースの理解が深まるのではと思います。

[^1]: 通常この`spec/`配下のテスト`hoge.spec`を`make install-check`や`./pg_isolation_regress hoge`をターミナルに打ち込み自動実行します。実行結果は、`results/`に保存され`expected/`にある正解ファイルと比べられ正誤の判定が行われます。
スタートアップに放り込まれた学生、JavaScriptを学ぶ その2 箱庭編

こんにちは、CureAppの新卒1年目、@imoansです。


プログラミングを学び始めた学生時代の私は[前回の記事](http://qiita.com/imoans/items/23ca8a4b59cef3be8cf8)のように成長し、ついにCureAppでバイトできることになりました。
そこからさらに深いJavaScriptの世界にはまっていくことになります。


# 放り込まれたのは、箱庭だった
githubのレポジトリをcloneし、最初の仕事が始まりました。
とりあえずREADMEを読みつつ聞きつつで環境構築。そして、「ここをいじると作業できるはずだから」と教えられ、簡易なタスクをこなしていきました。

もとからあるコードを見よう見まねで継ぎ足せば、とりあえず実装ができていきます。
テストも、とりあえず`describe`と`it`を書けば、何やら意図通りに動きます。コードを書き換えるとその都度watchが走って、すぐさま何やらが書き換わります。

当時は、環境のありがたさよりも、業務をこなせる自分の成長に喜びを噛みしめていました。


# 箱入り娘の弊害
## 環境が作れない
業務に慣れ、gitやshellと格闘すればなんとか仕事はこなせるとわかった私。趣味でも同じような技術で遊ぼうと試みます。

とりあえず色々と設定ファイルを用意しなければ。
`package.json`とか、`Gruntfile.coffee`とか、`.gitignore`とか...。
ディレクトリ構成もなんとなく似せたほうがいいよな、`src`とか`spec`とか?

しかし、当時の私はそれぞれの設定がどういう意図で書かれているのかを理解できていませんでした。
どこが自分にとって必要なのか分からず、構築段階で挫折。

とりあえず環境はいいから、普段通り書いてみるも、Google Chromeのブラウザは、


```
Uncaught ReferenceError: require is not defined(...)
```


とか言ってきました。
今考えたら当たり前なんですが、怒られて初めて、[browerifyは魔法の杖なんだなぁ](http://qiita.com/cognitom/items/4c63969b5085c90639d4)と気づくことになりました。


```
「browserifyがなかった時代、ファイル間での変数共有ってどう実現していたの？」
「え、globalに変数ぶらさげてたんだよ。」
「えええええええええ」
```


旧石器時代を偲びました。
 このように、**JSを書くなら環境構築の庭を作ることが大事である**ことを実感し、
そのためには結構な知識がいることがわかりました。


## 戦いの歴史を知らない
他にも、JavaScriptがいかに混沌から整備されてきたのか、ということに無頓着だったエピソードがあります。それはPromiseです。


プログラミングを始めてから、非同期処理にはPromiseを使うように、と叩き込まれていましたが、なぜPromiseが嬉しいのかはあまり分かっていませんでした。
説明記事で比較される「コールバック地獄」って、まあちょっと汚くなるよね、ぐらいの認識でした。


ある日、自分の使っているライブラリのバグっぽい挙動に悩まされ、ソースコードを見ることになりました。


密林のようなソースコードのなかで現れたのは、200行の1関数の中に何重にもネストされたコールバック関数でした。
コールバック全体をtry / catch で包み込むといったことができないので、エラー制御フローは追えたものではありませんでした。

この一件を経て、ネストも深くならず、どこでエラーが起きようとcatchできるPromiseは偉大なんだなあと気づくことになりました。
戦いの歴史を知らないままベストプラクティスだけを使っていると、技術のありがたみに気づくことができません。


# 次世代の足音
しかし、その「ベストプラクティス」というのも、永遠ではないのでした。
やっとgulp/browserify/CoffeeScriptの環境を覚えてホッとした私。
そのうち新しいプロジェクトが始まることに。


**新プロジェクトは babel/React/webpack でいく**ぞ！


なん....だと......


thisやnullのつらみを隠蔽してくれたらしいCoffeeScriptも、もうベストプラクティスではないのか...。ReactってJSのなかにタグあるのになんで許されているの？Reactが解決したかった問題って、まだ実感できてないんですけど。
あとbrowserifyはどうしてダメなの? 
Promiseがさらに隠蔽されるasync / await ってなんやねん!!!!


次世代の足音は、またもや新たな環境構築を強いるものでした。
このサイクルの速さに振り回されるばかりの私でした。


続く...




# この時期を振り返って
## 環境がある理由が、後から分かる
振り返ると、**初級者のうちから整った環境で作業したほうが、即戦力になった**といえるでしょう。
フルスクラッチで色々調べて構築するよりも、学習効率はよいはずです。
ただし、どうしてこの環境が生まれたのか、どうしてこの環境がよいのか、を知るためには
自分で環境との接点に触れて、発見していくことが必要です。

「browserify、ありがたかったんだ」というのは、JavaScriptを昔からやっていた方々からすれば当然のことのようですが、私にとっては新鮮でした。
昔の辛さを記事やレガシーコードで知りながら、今の技術の良さを心から理解していくのが、今JSを始め(て仕事にす)る初級者に求められるのかなと思いました。


## 環境を自分でつくれるまでは長い道のり
Reactを触ってみよう、となったとき、レシピ通りに環境構築を進めれば初級者でもHello Worldまでは実現できる時代です。
けれど「このレシピ、バージョン古いから動かない」とか「このスタックがベストなんだっけ」という問題は、初級者にはハードルが高いです。
業務で技術選定をしている経験豊富なエンジニアに相談したりして、徐々に自分でも技術選定できるようになりたいです。

--------


次回は、実際にbabel/React/webpack/flow/eslintを触って荒波に揉まれるJS初級者の様子を書いていきたいと思います。お楽しみに！

明日の[CureApp Advent Calendar](http://qiita.com/advent-calendar/2016/cureapp)は@janus_welさんです！
Yet Another XSS on Amazon

本記事は[脆弱性"&'<<>\ Advent Calendar 2016](http://www.adventar.org/calendars/1404)の14日目の記事です。

昨年の[脆弱性"&'<<>\ Advent Calendar 2015](http://www.adventar.org/calendars/811/)では[AmazonにXSSを2つ報告した記事](http://qiita.com/shinkbr/items/4867beb2858fa6e854b7)を書きましたが、これの2つ目のXSSに類似したXSSを最近またAmazonに発見・報告したお話です。

# 概要

<img width="696" alt="screenshot_alert_1.png" src="https://qiita-image-store.s3.amazonaws.com/0/53690/7e2a8d07-e013-fdaf-c3e0-69cc4cf11000.png">

<img width="828" alt="screenshot_html_with_box.png" src="https://qiita-image-store.s3.amazonaws.com/0/53690/e6aa190a-6c9d-a491-fd7e-fe655b45651f.png">

スクリーンショットの通り、www.amazon.co.jpの検索バーから`'><script>alert(1)</script>` と検索するだけで起きる反射型XSSです。

```html
<div data-ad-details='{"adPlacementMetaData": {"searchTerms": "<the_search_query>", ...}}'>
```

という風にシングルクオートで囲ったattributeに検索クエリを含むJSONを書き込んでいる箇所で、シングルクオートがエスケープされていないことが問題でした。

```html
<div data-ad-details='{"adPlacementMetaData": {"searchTerms": "'><script>alert(1)</script>", ...}}'>
```

このようにJSONやJavaScriptの中に含まれる文字列では、問題を引き起こしている`'`を含め検索クエリ全体をUnicode Escape Sequenceに変換して`\x27\x3e\x3cscript\x3ealert\x281\x29\x3c\x2fscript\x3e`とするのが安全なエスケープ方法です。

```html
<div data-ad-details='{"adPlacementMetaData": {"searchTerms": "\x27\x3e\x3cscript\x3ealert\x281\x29\x3c\x2fscript\x3e", ...}}'>
```

# jjencode yet again

冒頭で以前発見したXSSに類似していると書いたのは、これも検索の結果Amazonの商品が1つ以上ヒットしないと問題の箇所が出力されず、XSSが起きないという性質のためです。今回も"High **Alert** Status"というレーベルの"Degree of the Streets Volume **1**"というアルバムに収録されている["**Script** Ta Unscripted"](https://www.amazon.co.jp/dp/B0044Q3IL4)という楽曲が仕事をしてくれたおかげで`'><script>alert(1)</script>`によりXSSが確認できました。(画像1枚目)

なので、今回もjjencodeなどで検索を邪魔しないようにして`<script>`タグを注入することで任意のJavaScriptを仕込むことができました。

<img width="696" alt="screenshot_alert_document.domain.png" src="https://qiita-image-store.s3.amazonaws.com/0/53690/a0ae25a4-2dfa-cd35-7333-de3b86d3498f.png">

2016/12/9に報告し、1日で修正されました。ちなみに、その修正方法が少し変わっていて、検索クエリをbase64で出力するというものでした。

<img width="831" alt="screenshot_html_base64_with_box.png" src="https://qiita-image-store.s3.amazonaws.com/0/53690/9ba5a0e2-a3c6-751d-32be-bd398d74add9.png">

```bash
% echo -n 'Jz48c2NyaXB0PmFsZXJ0KDEpPC9zY3JpcHQ+' | base64 -D
'><script>alert(1)</script>
```

# 結論・所感
Amazonにバグバウンティ来ないのか (575)