OmniAICreator/Qiita-1.07M huggingface dataset:
iOSエンジニアがAndroidプロジェクトのレビュー効率的にする方法(Swift → Kotlin)

# はじめに

**この記事ではiOSエンジニアがAndroidプロジェクトのレビューをしてみて思ったこと(こうしたらいいんじゃね？)をだらだらと書いております。**

# 背景

**iOSとAndroidのエンジニアが1人ずつしかいないプロジェクト**において、**レビュー誰もしてくれない問題**を回避したいと思いお互いにレビューすればいんじゃね？となったので、**実際にやってみた感想とかポイント**とかまとめておきます。 

もともと**他のプロジェクト人にレビュー**してもらっていたのですが、**仕様がわからないのでそもそもレビューできない**等の意見がでたので試してみました。

# レビューしてみての全体的な感想

**やっぱり言語がわからないのは結構辛い。**ただ、**if文だけ**を見れば大体のロジックはわかるのでそこだけ重点的に見るならありかなと。結局の所**レビューで何を担保したいのかによるなー**と思いました。
**仕様的な確認**を行いたいのであれば**同プロジェクトの人がチェック**するといいと思いますし、**コードの読みやすさ**とかをチェックしたいなら**同言語を使用している人**に見てもらうといいと思います。

# 以下効率的にレビューするポイント

## ディレクトリ構成とアーキテクチャーの説明だけは最初に教えてもらっておく

ディレクトリ構成とアーキテクチャーの説明を受けないでレビューしようと思うと、全体がつかめないしどこに何が書いてあるかもわからないのでレビューする気が起きません。
まぁ、同言語のレビューする場合でも大事なことなんですけど、忘れがちなので。

## xmlファイルは見ない

iOSでいうところのxibとかstoryboardに当たるファイルです。xibとかstoryboardに比べれば読みやすいですが、そんなに見なくてもいいかなと。**チェックする時間の割にチェックしてもあまりいいことがない気がします。**
ただ注意しないといけないのは**xmlにもロジックがかける**らしいのでコードだけ見ていると罠にはめられる可能性があります。

## Resource系も見ない

ImageとかStringとか(Stringもxmlだけどね)AnimationとかDrawableとかColorとかとか...
**見ない！**
ココらへんは実際にアプリをポチポチテストしているときに確認してもらったらいいかなーと

## gradleも見ない

iOSのprojectファイルみたいなもの(だと思ってる)ので、見ない

## import文も見ない

確か勝手にAndroidStudioが管理してくれるので読み飛ばします

## View周りは見ない

LayoutファイルとかViewとかActivityとかAndroidの癖が強めなところは見ない
MVPとかだったらVに当たる部分ですね
View周りはデザイナーさんが実機で確認してくれると思うので**きっと大丈夫！**

## 基本if文が書いてある部分だけ見る

仕様どおりにコードが動くかってことを考えるとif文のところが一番怪しいのでそこを重点的に確認します。
**if文だったら言語関係なくほぼ同じ書き方になると思うので言語＆OSが異なってもすらすら読めます。**

## 困ったらAndroidエンジニアと一緒にレビューする

調べながらレビューしてもいいのですが、基礎がなさすぎると１日中勉強しないといけないことになってしまいます。
そんなときは**できるAndroidエンジニア**を捕まえて**一緒にレビュー**するとめちゃめちゃ捗ります。
**Android側の知識だけでなくiOSの知識を再度見直すいい機会になったりします。**

![nininsankyaku_men.png](https://qiita-image-store.s3.amazonaws.com/0/70276/27d3b158-fe27-2d33-7de2-13af42425feb.png)
Catapultで変わる現行NEMの機能

# はじめに

次期NEM(Catapult)では、アグリゲートトランザクションやクロスチェーン・トランザクションといった新機能が追加されてパワーアップしますが、既に現行のNEMにある機能もCatapultになるに伴い仕様や挙動が変わります。

今までのNEMだとこう動いていたけど、あれ挙動が違うなということにならないように、あるいは次期NEMだとこういうこともできるようになるんだというのを知って、Catapultに向けてアイデアを温めてみましょう。

# ネームスペース

- 親ネームスペースのレンタル期間は現行NEMの場合、約1年間の固定となっていましたが、Catapultではレンタル期間を**任意のブロック数の期間**で指定できるようになります。
- `cow`よりモザイクやアカウントの紐付けを任意に行う事ができます。

# モザイク

- ネームスペース同様、モザイクの存続期間も任意に設定できるようになります。また、`cow`より存続期間を**永続**にすることもできます。
- 今まではネームスペースを作成してから、モザイクを作成する必要がありましたが、`cow`からは単独でモザイクを作成できるようになりました。
  - モザイクにはIDが割り振られ、そのIDとネームスペースを後から紐付ける形となります。 
 
# マルチシグトランザクション

- マルチシグによる転送トランザクションについては注意が必要です。次期NEM(Catapult)ではマルチシグによる転送トランザクションは**アグリゲートトランザクション**で扱います。
- アグリゲートトランザクションは`AggregateCompleteTransaction`と`AggregateBondTransaction`の2種類があり署名条件によって使い分ける必要があります。

## パターン1 必要署名数が1人だけの場合

<img width="651" alt="スクリーンショット 2018-12-05 9.51.16.png" src="https://qiita-image-store.s3.amazonaws.com/0/9315/e6bfc7ce-2e6e-1304-e795-b2be88851cb1.png">

- 必要な署名数が1人だけで、トランザクションの作成者だけでトランザクション成立する場合は`Aggregate Complete Transaction`を適用します。


## パターン2 必要署名数が複数の場合

<img width="629" alt="スクリーンショット 2018-12-05 9.50.42.png" src="https://qiita-image-store.s3.amazonaws.com/0/9315/b87eb12a-c591-94c6-4cbd-8a475f0a4b04.png">

- 複数の署名がないとトランザクションが成立しない場合、`AggregateBondTransaction`を適用する必要があります。
- `AggregateBondTransaction`を使用する場合、`HashLockTransaction`を使用してネットワーク上に**担保用の通貨を収める**必要があります。
- `HashLockTransaction`で差し出した通貨は必要な署名が揃ってトランザクションが成立した場合は返却されますが、期限内にトランザクションが成立しなかった場合没収されます。

# 現行NEMにあるけどCatapultのドキュメントでまだ公開されてない機能

現行NEMにある機能で、Catapultのドキュメントで公開されていない機能も実はあります。

- 転送(送金)トランザクションのメッセージの暗号化メッセージ・HEXメッセージ
- モザイクの徴収機能
  - ref: https://github.com/nemtech/catapult-server/issues/24 


# まとめ

現行NEMにも備わっている、ネームスペース、モザイク、マルチシグトランザクションについてもCatapultになると挙動が変わる部分がありました。
特に**モザイクとネームスペースの部分は大きな仕様変更**となっているので注意が必要です。
この変更はNEMを使ってアプリを開発するエンジニアだけでなく、一般のユーザやサービスを考える人にも影響がある箇所なので、NEMを使って何かやっている人やろうとしている人はこの変更点を是非抑えてもらえればと思います。

## 参考リンク

- https://nemtech.github.io/index.html

# 更新履歴

- 3/19 最新版(cow)に合わせて内容を修正しました。
YAML de Markdown

宮崎在住エンジニアのジョウ(@JotarO_Oyanagi) です。

API ドキュメントを作成していて「swagger とか ReDoc でテーブル使いたいけど、どうすればいいんだろ」となってあれこれ探した結果、以下の方法で YAML で Markdown 記法が使えるのがわかったのでメモします。

# `description: |` を使う

こういうことです。

```yaml

...
description: |
  見出し：
  # テキスト

  イタリック：
  *テキスト*
  
  ボールド：
  **テキスト**
  
  モノスペース：
  `テキスト`

  罫線：
  ---

  箇条書き：
  * その１
  * その２
  * その３

  番号付きリスト：
  1. その１
  2. その２
  3. その３

  リンク：
  [テキスト](https://example.co.jp) 

  画像：
  ![ロゴ画像](https://img.co.jp/logo.png)


  コード：（`` を ``` に置き換えてください）
  ``
  function() {
  	return true;
  }
  ``

  テーブル：
  | 見出し１ | 見出し２ |
  | ---- | ---- |
  | データ１ | データ２ |
```

これで API ドキュメントづくりが捗りますね！
tmuxやvimで分割された画面の背景色をフォーカスの有無で変更する。

# はじめに
自分が今どこにいるのか、わからなくなることが多いので。

# tmux
![2018-12-04_11:40:30.png](https://qiita-image-store.s3.amazonaws.com/0/163210/2b2b9967-653a-98f7-b369-8084fcd2d509.png)

```config:tmux.conf
setw -g window-active-style fg='#c0c5ce',bg='#2b303b'
setw -g window-style fg='#c0c5ce',bg='#27292d'
```

```config:tmux.conf
setw -g window-active-style fg='#c0c5ce',bg='#2b303b'
setw -g window-style fg='#c0c5ce',bg='#ef5a4a'
```
,
# vim
![2018-12-04_11:38:15.png](https://qiita-image-store.s3.amazonaws.com/0/163210/205e57e6-43f9-800f-c1f6-679431977ad7.png)

```vimscript:init.vim
augroup ChangeBackground
  autocmd!
  autocmd WinEnter * highlight Normal guibg=default
  autocmd WinEnter * highlight NormalNC guibg='#27292d'
augroup END
```

```vimscript:init.vim
augroup ChangeBackground
  autocmd!
  autocmd WinEnter * highlight Normal guibg=default
  autocmd WinEnter * highlight NormalNC guibg='#ef5a4a'
augroup END
```

# tmux と vim
![2018-12-04_11:38:57.png](https://qiita-image-store.s3.amazonaws.com/0/163210/5a98fe42-7819-ef25-b397-c7237f06e8c7.png)
![2018-12-04_11:39:00.png](https://qiita-image-store.s3.amazonaws.com/0/163210/f134be2a-1c68-4f0b-08ca-2369451cbad2.png)

```vimscript:init.vim
augroup ChangeBackground
  autocmd!
  autocmd WinEnter * highlight Normal guibg=default
  autocmd WinEnter * highlight NormalNC guibg='#27292d'
  autocmd FocusGained * highlight Normal guibg=default " 追加
  autocmd FocusLost * highlight Normal guibg='#27292d' " 追加
augroup END
```

# denite.nvimでauto_previewする場合
行移動する度にウィンドウが切り替わるので画面がチカチカします。なので、buffersに[denite]があるならハイライトを切り替えないようにします。

```vimscript:init.vim
function! s:changeBackground()
  for buf in getbufinfo()
    if buf.name =~ '\[denite\]$'
      return
    endif
  endfor
  highlight Normal guibg=default
  highlight NormalNC guibg='#27292d'
endfunction

augroup ChangeBackground
  autocmd!
  autocmd WinEnter * call s:changeBackground()
  autocmd FocusGained * highlight Normal guibg=default
  autocmd FocusLost * highlight Normal guibg='#27292d'
augroup END
```
Sourcetreeの内部gitの更新方法

# 背景

- SourcetreeのpullでAggregateExceptionがでてpullできなかったところ以下の記事がHIT
    - [git on Windowsで aggregateexceptionが発生する](https://qiita.com/horsewin/items/fdf2fb9092b4092fcc34)
- 内部Gitのバージョンが古そうだったので更新方法をメモっておく

# 環境

- Windows 10 64bit版 v3.0.8

# 方法

- ツール　＞　オプション　＞ Git
- オプションウィンドウ下部にある「Gitバージョン」の「Update Embedded」をクリックする

更新することでpullできるようになったが、この更新が理由で解決したのかは判断ができなかった・・・（障害も起きていたし）
eZ Platform を Docker で簡単セットアップ

## eZ Launchpad
[eZ Platform](https://ezplatform.com/) のセットアップは[システム要件](https://doc.ezplatform.com/en/2.3/getting_started/requirements/)を満たす必要がありますが、[eZ Launchpad](https://ezsystems.github.io/launchpad/) を利用することで簡単なコマンドで Docker 上に eZ Platform をセットアップすることが可能です。

### システム要件
eZ Launchpad のシステム要件は以下の通りです。

* PHP 5.6 以上、または 7 以上
* Docker 1.17 以上
* Docker Compose 1.16 以上

#### 検証環境
* macOS Mojave 10.14.1
* PHP 7.1.19
* Docker Engine 18.09.0 (API 1.39)
* Docker Compose 1.23.2

### インストール
```bash
curl -LSs https://ezsystems.github.io/launchpad/install_curl.bash | bash
```
上記のコマンドを実行すると `~/ez` コマンドが使用可能になります。

```bash
alias ez='~/ez'
echo "alias ez='~/ez'" >> ~/.bashrc
```
追加で上記コマンドを実行すると `~/ez` ではなく `ez` で実行可能になります。

なお、[install_curl.bash](https://github.com/ezsystems/launchpad/blob/master/docs/install_curl.bash) の中身は以下の通りです。

```bash:install_curl.bash
#!/usr/bin/env bash

EZ_HOME="$HOME/.ezlaunchpad"
URL="https://ezsystems.github.io/launchpad/ez.phar"
mkdir -p $EZ_HOME
cd $EZ_HOME

curl -sS -o ez.phar "$URL"
curl -sS -o ez.phar.pubkey "$URL.pubkey"

ln -sf $EZ_HOME/ez.phar $HOME/ez
chmod +x $HOME/ez

echo "You can now use eZ Launchpad by running: ~/ez"
echo ""
echo "- You may want to put ~/ez in you PATH"
echo "- You may want to creat an alias (in your .zshrc or .bashrc) alias ez='~/ez'"

~/ez
```

```bash
sudo nfsd restart
```
ホスト OS が macOS の場合、 `nfsd` を再起動する必要があるようです。

### 作業ディレクトリーの作成
```bash
mkdir ~/Workspace/ezptest && cd $_
```
作業ディレクトリーを作成して移動します。

### 初期化
```
ez init
```

### Docker の確認
```bash
ez ps
```

### 情報の確認
```bash
ez info
```
Mapbox GL JS 仕様のベクトルタイルが想定どおりに表示されているかどうかを CircleCI でテストする

みなさんはじめまして。TileCloud というサービスの開発チームの宮内です。

https://tilecloud.io/

TileCloud とは、OSM ベースの地図をベクトルタイルで配信するための地図専用ホスティングのサービスで、ただいまパブリックベータを少しでも早く公開できるように、せっせと頑張っております。

このサービスでは、OSM のデータをベースに Mapbox GL JS と互換性のあるベクトルタイルをご提供しようと思っていまして、Mapbox GL JS のプラグインや周辺ツールなどをオープンソースで開発中です。

https://github.com/orgs/tilecloud/dashboard

今回の記事では、これらのツール類を開発する際の基盤技術ともいえる地図の動作確認の CI 方法についてざざっとかいつまんで説明していきます。

## CI でやりたいこと

僕たちが今作っているものは、主にサービスのダッシュボードで使用することを想定しているもので、例えば以下のようなものがあります。

https://github.com/tilecloud/mbgl-export-control

これは、Mapbox GL JS のプラグインで、これを有効化すると、以下のように表示中の地図をダウンロードするためのボタンが表示されるというものです。

![](https://www.evernote.com/l/ABWn28S6xdNOR6J8Es5ZxYfuxFQ1jkBc6TcB/image.png)

ダウンロードされる地図は PNG フォーマットで、ブラウザの解像度よりも高い 300dpi という解像度でもダウンロードできるので印刷にフレンドリーなのと、`© OpenStreetMap Contributors` というアトリビューションが自動的に入ります。

他にも

* https://github.com/tilecloud/mbgl-japanese-prefs
* https://github.com/tilecloud/mbgl-fork-me-control
* https://github.com/tilecloud/mbgl-circle-marker

などのモジュールがあり、まだまだ増える予定です。 

これらひとつひとつは小ネタなのですが、これらをオープンソース化しつつ複数組み合わせてリッチなダッシュボードにしていくというアーキテクチャにしようとしているため、単品で動作することももちろん重要ですが、モジュール同士のコンフリクトなどもありえるため、最低でも地図が表示されていることだけは自動的にチェックしたいと考えました。

もしモジュール間のコンフリクトがあればそのときにそれも自動化テストの中に追加する感じですね。

## Puppeteer を使用した自動化テスト

実際に地図が表示されていることを確認するには、サービス全体のさまざまな要素すべてが健全に動作している必要があります。

たとえば、僕たちのサービスでは地図の表示の際にAPIキーが必要なんですが、そのための認証用のAPIが動作しているとかですね。

逆に言えば地図の表示確認を自動化できれば、それらのAPIの動作確認も完璧ではないにしろある程度できることになります。

```javascript
const chai = require('chai')
const assert = chai.assert
const puppeteer = require('puppeteer');

describe('Tests for Maps.', () => {
  it(`The map should be displayed as expected`, done => {
    (async () => {
      const browser = await puppeteer.launch()
      const page = await browser.newPage()
      await page.goto('https://xxxx.tilecloud.io/')
      await setTimeout(async () => {
        await page.screenshot({path: 'screenshots/osm-bright.png'})
        const map = await page.$('#map div:first-child')
        const className = await (await map.getProperty('className')).jsonValue();
        assert.deepEqual('mapboxgl-canary', className)
        await browser.close()
        done()
      }, 5000)
    })();
  });
})
```

上のソースは、実際に地図が表示されているかどうかを Puppeteer というヘッドレスブラウザを使って確認するための例です。

この例では `https://xxxx.tilecloud.io/` という URL に対してヘッドレスブラウザでアクセスし、JS が無事に動作したときに生成されるであろう要素の存在有無（今回は `.mapboxgl-canary` というクラス属性をもった DIV 要素の有無）を確認して、さらにスクリーンショットを保存しています。

まだそこまで頑張っていませんが、スクリーンショットについては、いろんなパターンの地図のギャラリー的なサイトをつくってそこでざざっと俯瞰して確認できるようにしようかなと思っています。

## CI サービスで自動化

現時点で僕たちは52通りの地図の動作確認をしているのですが、これらは今後バグや不具合等の経験を通してどんどん増えていくと思います。

そのため CI サービスを利用して Git のコミットなどをトリガーにしてテストの実行そのものも自動化するわけですが、Mapblox GL JS ならではのハマりポイントがありました。

なんと Trais CI で起動するコンテナで Puppeteer を起動しても、Mapbox GL JS ベースの地図がうまく表示されません。

Mapbox GL JS は、地図を表示するために WebGL を使用しているのですが、どうやらそのあたりに制限があるようですね。（GPU が利用できないとかそういうこと？どなかた詳しい人解説を希望します。）

一瞬うぎゃーとなりましたが救いの神がいました。 Circle CI さんですね。

というわけで Mapbox GL JS のレンダリングをヘッドレスブラウザで行う際は、Circle CI でどうぞ。

ちなみに Lambda でも挑戦したのですが、Puppeteer のバイナリが Lambda のファイルサイズの制限にひっかかってしまって、やはりうまくいきませんでした。
開発環境がWindowsからMacになったときにしたこと

# はじめに
オークファンの佐藤です。Judas PriestとBABYMETALがシンガポールで共演する話題に心振り回されながら、記事を書いています。
会社がアドベントカレンダーを始めたので便乗してみました。

本当はテック的な小ネタを考えていたのですが、オークファンに入社して、Macの開発環境に初挑戦したときの思い出を書こうと思います。

# 仕事でMac
オークファンに入社するににあたり、特にPC環境について何も聞かれず、入社してみたら、MacBook Proが用意されていました。
実は今まで、業務でMacを使ったことはなく、開発マシンはずっとWindows環境でした。

いちおう家にMacはあったものの、持ち運び用のノートとして使っていたので、ガチの開発用に使ったことはありませんでした。
それがいきなり、成果とパフォーマンスを求められる開発用環境として、Macです。

確かにWeb開発といえばMacだよね、と思いつつ、 （´-`）.｡oO（あ、どうしよう）　と思ったのでした。

# 入力インターフェイスに慣れる
MacはWindowsとキー配列が違います。開発時には地味に大きなポイントです。
ただ、Macは日本語キーボードですが、外付けキーボードは英語でも問題ありません。これはWindowsより優れている点ですね。

## カスタマイズ
「システム環境設定」-「キーボード」-「修飾キー」から、`Capslock` -> `Control`　`Control -> Command` に変更。
これだけで、Mac流のCommandキーのショートカットを、HHKBと同じ感覚で使い続けることができます。
Macの`Ctrl`キーを使った各種ショートカットは、Windowsの通常キーボードで馴染みのある左下キーで使えるので、違和感激減。

外付けキーボードは別のカスタマイズが可能なので、キーボードの配列に応じてカスタマイズができます。
ちなみにキーカスタマイズ定番ソフトの `karabiner`は使っていません。

## スクロール方向を変える
自宅と同じLogicoolのトラックボール`M570`を使っていて、操作感はいつもと同じ……なのですが、どうしてもスクロール方向が自宅のWindowsと反対になるのが気持ち悪く、あえてWindowsに合わせました。　
「システム環境設定」-「トラックパッド」-「スクロールとズーム」から、「スクロールの方向：ナチュラル」のチェックボックスを外します。

# 開発環境を作る
そしてドキュメントに従い開発環境を作ります。ひたすらインストールするだけです。

オークファンは `PHPStorm`のライセンスを持っていました。設定すればなかなか便利なので、使っています。
DBはMySQLメインで、クライアントに`Sequel Pro`を使います。
VMで開発するので、`VirtualBox`と`Vagrant`も。これはWindows時代と同じ。
メーラーは`Gmail`なので不要。一応`Microsoft Office`もインストールします。
Macはデフォルトで`git`が入っているので、`Github`のアカウントを作って、念のため`SourceTree`も入れておく。
そして初体験の`Slack`……

ここまでの環境比較をまとめます。

環境|〜前職|現職
---|---|---
PC|Windows|Mac
IDE|Eclipse|PHPStorm
DBアクセス|MySQL Workbench|Sequel Pro
端末|Git Bash|ターミナル
VM|VirtualBox + Vagrant|同じ
バージョン管理|BitBucket|Github
バージョン管理GUI|Egit & SourceTree|同じ
メール|Gmail|同じ
オフィス|MS Office|同じ
チャット|なし|Slack

（´-`）.｡oO（問題はエディタとDiffツールでした）

（´-`）.｡oO（率直に言ってコマンドラインとVimが苦手でした）

## サクラエディタへの愛情
過去の私はサクラエディタ使いだったのです。
テキスト系の処理は`Ctrl + F`の検索、`Ctrl + R`の置換、`Ctrl + G`のGREP機能で、だいたいこなせました。
特にEclipseのフォルダ検索があまり頼れなかったため、GREPは頻繁に使っていました。

しかし、Macにはサクラエディタがない。
正規表現のスキルはサクラエディタでだいぶ身についたが、コマンドで検索・置換・grepする経験があまりなく、IDEに頼ってばかり……

## WinMerge
そしてもう一つ、Diffツールとして、どうしてもWinMergeは手放せませんでした。
コピペコードの比較、CSVファイルの内容比較など、テキストファイルを比較する場面はとても多いのに、MacのDiffツールは、どれもどこか弱い。
CompareMergeは起動しなかったし、Vimdiffも慣れなかった。


# 救世主VSCode
（´-`）.｡oO（WindowsとGUIに慣らされた私を救ってくれたのは、やはりMicrosoftでした）

## カジュアルに使えるエディタ
Visual Studio Codeは、vim的なルールを覚える必要はありません。
誰でもカジュアルに使えます。

## デフォルトで使えるエディタ
カスタマイズ性も十分ですが、インストールしてすぐ使えることもとても重要です。
Visual Studio Codeは、その点で必要十分な機能を持っています。

### 正規表現の使えるエディタ
`Command + F` でファイルを検索できます。
`Command + Option + F`で置換できます。

検索・置換ウィンドウを開いた状態で`Command + Option + R`を押すと、正規表現オプションがつきます。
使い方はほぼサクラエディタと同じ。ただし置換時のプレースホルダに`\n`は使えず、`$1`...です。

### ファイル比較のできるエディタ
比較したいファイルをドラッグ&ドロップして、`Command + Shift + P`から `Compare`と入力して出てくるオプションから、ファイル間の比較ができます。

### sortもできる
行を`Command + A`で選択した上、`Command + Shift + P`から `Sort`と入力して出てくるオプションから、選択行を昇順・降順でソートできます。

## 拡張できるエディタ
（´-`）.｡oO（この点はあまり詳しくないので割愛します）

# 結論
WindowsからMacに環境が変わっても、変わるのはソフトと使い方だけです。
開発環境は変わってもサーバーは同じLinuxですし、ブラウザベースで動くソフトウェアを作る点では同じ。
最終的には、Macでの開発に馴染むことができました。


ruby-fikemakerでNameError

filemakerをrequireすると、NameErrorが発生。

```
irb(main):001:0> require 'filemaker'
Traceback (most recent call last):
       11: from /Users/foo/.rbenv/versions/2.5.3/bin/irb:11:in `<main>'
       10: from (irb):1
        9: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in `require'
        8: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
        7: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `require'
        6: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/filemaker-1.0.0/lib/filemaker.rb:3:in `<top (required)>'
        5: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:70:in `require'
        4: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:70:in `require'
        3: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/filemaker-1.0.0/lib/filemaker/server.rb:4:in `<top (required)>'
        2: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/filemaker-1.0.0/lib/filemaker/server.rb:5:in `<module:Filemaker>'
        1: from /Users/foo/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/filemaker-1.0.0/lib/filemaker/server.rb:6:in `<class:Server>'
NameError (uninitialized constant Filemaker::Server::Forwardable)
```

先にforwardableをrequireしておけばOK

```irb
irb(main):002:0> require 'forwardable'
=> true
irb(main):003:0> require 'filemaker'
=> true
irb(main):004:0> 
```

https://github.com/mech/filemaker-ruby
AG-03とスマホの放送してみた

# 2018/12/4 レクチャー会

オーディオインターフェースを使ったSHOWROOMアプリでの配信は可能ですが、SHOWROOM Vを使った放送は申し訳ございませんがアップデートがあるまでお待ちください。

## 機材使い方シート
![1.JPG](https://qiita-image-store.s3.amazonaws.com/0/318045/c4e4608f-cee4-3c15-2aed-07b5fb40eeef.jpeg)
![2.JPG](https://qiita-image-store.s3.amazonaws.com/0/318045/6b274d8c-f3bf-941f-f85d-8f68e0a6d42f.jpeg)
![3.JPG](https://qiita-image-store.s3.amazonaws.com/0/318045/fdda6a1f-2361-3939-df7a-d0eaf7d9c9de.jpeg)
![4.JPG](https://qiita-image-store.s3.amazonaws.com/0/318045/00ca687b-a0b7-f0a8-b2d5-e14e97acd90e.jpeg)


### 〇BGMの流し方
【プラン１】　AG-03のAUXに接続してBGMを流す
特徴　音量は音源側で調整しなくてはならない。BGMをミキサー側でミュートできない。
使用ケーブル　ステレオミニプラグケーブル

【プラン２】　AG-03の2/3に接続してBGMを流す
 ![DFD151D3D66E48E6ABF05DECCFBDF38D_12075_735x735_af574fc19cba81411655873489fc439b (2).jpg](https://qiita-image-store.s3.amazonaws.com/0/318045/2c3f69d1-2325-3e9f-5805-e0896a516998.jpeg)　　　　

特徴　ミキサー側で音源を調整できるフェードイン・フェードアウトが可能
使用ケーブル　変換ステレオミニプラグ 2分配 trs ケーブル オス-オス
サーバルームから這い上がった元インフラSEが見たゲームQAの属人化

本記事はゲームのソフトウェア品質向上アドベントカレンダーの6日目の記事として執筆しています。
##属人化したテストケースって？
ゲームのQAを担当していると、こんな感じのテストケースを見ることがないでしょうか。
![20181204_132646.png](https://qiita-image-store.s3.amazonaws.com/0/320947/73cc1cea-e3b0-a97a-426c-b73ac9268df4.png)
このようなテスト実施手順では、確認者に次のような条件がつきます。

- 管理ツールからイベントのランキング報酬を確認する方法がわかること
- 報酬の数を見て問題の有無にあたりがつくこと

熟練のテスターぞろいのチームであれば全員が上記の条件を理解しているかもしれませんが、そこに新規の人員が加わった場合、
テストケースを見ただけではテストをできない状態が生じてしまいます。
このような、確認者がある程度前提を理解している前提で作られたテストケースは、属人化した状態にあると言えます。


##属人化したテストケースの問題点
では、テストケースが属人化すると何が良くないのでしょうか？
パッと思いつく限りでも、以下のようなデメリットが考えられます。

1. **担当者不在時の支障**
2. **不慣れな巻取り者のミス**
3. **問題が発覚しにくい環境**

###1.担当者不在時の支障
ここは単純で、いつも担当している（＝属人化している内容を理解している）人が不在の時は、その人の業務はストップしてしまいます。
計画的な休暇など、予め担当者が居ないことが分かっているならばまだしも、急病による当日欠勤や、最悪の場合だと担当者が急に退職してしまった場合など、業務への大きな影響が考えられます。
###2.不慣れな巻取り者のミス
これは1.担当者不在時の支障に関連するデメリットですが、いつもの担当者が不在の時、急遽対応の必要が生じてしまった場合は、作業に慣れていない誰かが巻き取って対応する必要が出るケースもあるでしょう。
属人化したテストケースだと、実施手順はあらかじめわかっている前提で作られているので、このような場合細部の見落としや認識の相違などで、障害が発生するリスクが高くなります。

ここで注意すべきなのは、担当者が不在の時だけでなく、キャパオーバーを起こしているときにも他者の巻取りは発生する場合があるということです。
その際、**担当者はたとえ近くにいても、巻取り者の疑問や不手際に確実な対処をとれるわけではないので、不在時とリスクの大きさにそう大差はありません。**

###3.問題が発覚しにくい環境
テストケースが属人化していると、客観的なテストの実施状況がわかりにくくなります。
たとえ百戦錬磨の担当者でも時にミスを起こすことはあるはずですが、テストの詳細な内容や要点は他の人からはわかりにくいので、**ミスを指摘することも同様に難しく**なります。
また、あってはいけないことですが、**担当者が意図的にミスを隠すことも容易**になってしまいます。

このように、テストケースの属人化は、組織にとって望ましくないと言えます。

##元インフラSEから見た属人化の排除
私は前職でインフラSEをしていましたが、例えば毎日深夜2時にサーバの保守作業をしなければいけない時、
SEがその時間に出社するのは非現実的なので、交代制で24時間365日サーバを監視してくれているオペレーターの方に作業を依頼するのが普通でした。
その際のフローを基に、テストケース属人化排除のアプローチを考えてみようと思います。

###作業者が未経験者と想定する
オペレーターはチームとしていくつものお客さまの環境を監視しなければならないので、基本的には専任の担当は置けず、あらゆる作業を誰もが行う可能性があります。
また人の入れ替わりも激しいので、不慣れな作業者というのも往々にして出てきます。
SEが作業を依頼するときにも、そのことを念頭に置いた手順を作成する必要があります。
もし、上で例示した報酬の確認手順をオペレーターさんに依頼する場合、以下のような粒度になります。
![20181204_210402.png](https://qiita-image-store.s3.amazonaws.com/0/320947/1bd5f12e-2f97-e74c-18cc-36b10a838b90.png)
ここまでの粒度で作り込めば、どんなに経験が浅い人でも報酬画面にたどり着き、内容の妥当性を判断することができるでしょう。

テスターさん向けのテスト手順においてここまでの粒度で作成する必要はないと思いますが、以下のように最低限確認箇所、比較対象、判断基準くらいは書いておけば、属人系の薄いテストケースに近づくと思います。
![20181205_190205.png](https://qiita-image-store.s3.amazonaws.com/0/320947/a4398923-7919-d9c2-db58-e426828d1c84.png)

###テストケース作成者がテスト手順を理解する
ここは私自身結構ギャップを感じた点なのですが、テストケース作成の際、作成者はあくまで設計（≒観点出し）を行い、
詳細な確認方法はテスターさん、よしなにやってね、というのが割と一般的ということがあります。

この構造は作業を分担できているという点ではすごくいいことなのですが、**テスターさんがよしなに対応した確認方法を設計者が理解できない場合、属人化していたり、そもそも認識の齟齬があった際に検知できない**ことが問題です。

最低限、テスターさんが自分が作ったテストケースを使ってどのように検証を行ったかは理解し、手順の記載方法や確認内容に問題があるかどうかは追えるようにしておくべきだと思います。

##まとめ
業務システムのオペレーターさんはルール上、**書かれていないことはやってはいけない**、**わからなかったら夜中だろうが何だろうが電話でSEを叩き起こして聞く**ことが徹底されているため、SEも必死で伝わる手順を作成します。

オペレーターさんを貶めるわけではないのですが、ゲームQAのテスターさんはかなりアバウトでもなんとかしてくれることが多いので、QAエンジニア側は甘えやすい構造になってしまっているのではないかなと思いました。

今一度現場のテスターさんの努力に感謝し、QAエンジニアとしてプライドを持って仕事をしていきたいと思います！
React-Native-elementsで透過ボタン

RN-elementsのclearが反映されない。。。

検索エンジンで「React-Native-elements」で調べると、1.0.0-beta7が表示される。
<img width="1229" alt="スクリーンショット 2018-12-04 13.22.48.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/659f56e6-47d1-ef94-d5ad-367925d4c965.png">

下のrefarenceにボタンを透過する「clear」が表記されているが、これを書いても反映されない
<img width="844" alt="スクリーンショット 2018-12-04 13.23.32.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/8d9b8dfd-6329-5453-8010-02c8791c29ca.png">


##バージョンを確認すると、今は0.19.1らしい。
0.19.1の[Button Components](https://react-native-training.github.io/react-native-elements/docs/0.19.1/button.html)はこれ
<img width="1267" alt="スクリーンショット 2018-12-04 13.25.19.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/32d59ce3-8b52-96ef-b94b-be1632b85866.png">

下のRefarenceに「clear」が消えてます。
代わりに「transparent」が追加されています。

<img width="741" alt="スクリーンショット 2018-12-04 13.32.33.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/3d8fc7db-23bb-3c85-fcea-532dd258d6af.png">

##transparentで書いてみた

一応比較として、デフォルトも書きました。

```javascript
        <Button
          style={{marginVertical: 20}}
          title="default"
        />

        <Button
          title="clear Button"
          transparent
          color="blue"
        />
```

<img width="250" alt="スクリーンショット 2018-12-04 13.38.57.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/f77b6b13-a1f2-ccf5-f621-169c14b57a74.png"><img width="250" alt="スクリーンショット 2018-12-04 13.38.40.png" src="https://qiita-image-store.s3.amazonaws.com/0/252667/1a45f7d6-c662-7892-9bde-dff25ed23d50.png">

無事ボタン透過できました。
アプリ作成の記録 ~プロローグ~

#アプリ作成の記録

これから課題として””タスク管理アプリを作成していきます。
それを確認として残しておこう思いました。


Railsアプリを作る際は、”まずやること”があります。


##１・仕様一覧　を　作成する

>アプリケーションを作る際は、"仕様一覧"を作成します。

>"仕様一覧"というのは、これから作るアプリが、
どんなことができるのか全て列挙していきます。今回の”仕様一覧”はこのようになっています。


 - タスクの”一覧”が見られます

 - タスクを”登録できる機能”があります（新規登録）
  - タスク”名称”
  - タスクの詳しい”説明”が登録できる。(詳細）

 - 登録したタスクを”編集”できます
     - 登録された タスクを”削除”できます

このような仕様に沿ったアプリを作成していきます！


##2.DB設計

>次はデータベース設計です。


- モデルの名前をきめる  
 - なぜモデルの名前を決めるかというと、モデルの名前に複数形のSをつけたものが、テーブルの名前になるため。
（テーブルには複数の情報が格納されているため、複数形になります）

        - taskモデル　　　　　　　　　　 ←今回のモデル名
- tasksテーブル　　　　　　　　　　　      ←ゆえにその複数形になります

   - 名称(title)
   - 詳しい説明(description, content)          カッコの中はカラムの名前です









##３.URL設計##

>どんな画面が必要か。必要な画面の一覧を列挙する。

- 一覧画面(index)
     - /tasks                                   /~がURLの名前
- 新規登録画面(new)                   カッコ名はアクションの名前
     - /tasks/new
- 編集画面(edit)
     - /tasks/:id/edit
- 詳細画面(show)
     - tasks/:id

>以下は画面は持たないが、アクションとして存在するもの

- create
 - /tasks
- update
     - /tasks/:id
- destroy
     - /tasks/:id

 
>- この基本の7つのアクションのことをCRUD(クラッド)という
システムに４つの主要機能である「生成(Create)」「読み取り(Read)」「更新(Update)」「削除(Delete)のイニシャルを並べた用語のこと。



#４.タスクバラし（アプリ機能完成までにやることリストを一覧をあげる）以下、やることリストです

 ```rails newをする　　```　　　　　　　　　　　　 雛形の作成
 
 ``` githubのリモートリポジトリの準備　```　　　　 gitの準備
  
 ``` git init```
                                                           
 ```git add.```
 
 ``git commit -m ‘first commit’ ``(この時点でファイルができているため、一度githubにおいておく)

 ```git push origin -u master```（一番最初にpushする時だけ-uオプションが必要）

 ```rails db:create```
    rails newした段階ではデータベースは作られていないのでrails newしたら一回はrails db:create走らせる。

 ```rails g model task```

   - モデルを作成
     - モデルを作成するとマイグレーションファイルができる　
       - 注意: マイグレーションファイルにカラムを追加するのを忘れずに
         - rails カラムの追加 dbの作成方法でググる。。。
       - create_tableの設計書できる。

>マイグレーションファイルとは・・・データベースを変更する際の設計
          
  ```rails db:migrate```
＞設計書を実行する。

```rails g controller tasks```
routes.rbを編集
- viewsを編集

>タスクバラしの目的は、「現時点で、”やること”が漏れていたりだとか、”間違ったこと”をタスクバラしでしてるな、と気づいた場合は、必ず”実装している時も”手詰まったり、間違ったことをしてしまう。
なので事前に、わかるところ、わからないところを洗い出しておく必要があるため

~~ここまでの４つが終わった段階でアプリを作成して行こうと思います~~

**一人でできるように。。初心者を抜け出そうと思います！**
Augurのマーケット内訳(2018-12-04)

予測市場のプラットフォームである[Augur(オーガー)](https://www.augur.net/)の、2018-12-04現在のマーケットの内訳です。
カテゴリ名を元に分類し、そのカテゴリに含まれるマーケット数を合計しました。


# マーケットの内訳(mainnet)

メインネット上には現在706個のマーケットがあります。

PRE_REPORTING(売買受付中)のマーケットの内訳は、
暗号通貨関連(crypt currency)：278(-5)
スポーツ(sports)：105(-5)
政治(politics)：100(-1)
経済(finance)：70(-1)
その他(other)：153
でした。


![20181204-augur-market-count.png](https://qiita-image-store.s3.amazonaws.com/0/142577/8ba9753d-1698-413a-9e02-601c3ee4f6ab.png)


# 感想

前回からは大きなイベントもなく、マーケット数は減りました。「2018年末までにxx」というマーケットもあるので、年明けに動きがあるかと思っています。
マーケット数ではなくベットされた金額での比較を、[@crystalballbe](https://twitter.com/crystalballbe)さんがされているので、必見です。
今後もウォッチを続けたいと思います。
ionic-nativeを使ってandroidとiosでibeaconを使う

ionic-nativeでandroid,ios双方でibeacon使ったときにハマったり理解できたことがあったのでここに書いておきます。

#android,ios共通部

動かすにはbluetoothとgpsが必要なのでダイアログを表示して許可を得ましょう。

BLEプラグインをインストール
https://ionicframework.com/docs/native/ble/


ダイアログの例

```
//パッケージをインポート
import { BLE } from "@ionic-native/ble";

~省略~
 //ダイアログ表示
    this.ble.isEnabled().then(() => {
      console.log("bluetooth is enabled all G");
    }, () => {
      console.log("bluetooth is not enabled trying to enable it");
          this.ble.enable().then(() => {
              console.log("bluetooth got enabled hurray");
                }, () => {
                  console.log("user did not enabled");
          })
    });
```

gpsプラグインをインストール
https://ionicframework.com/docs/native/location-accuracy/

```
import { LocationAccuracy } from "@ionic-native/location-accuracy";

~省略~
 //ダイアログ表示
    this.locationAccuracy.canRequest().then((canRequest: boolean) => {
      if(canRequest) {
        // the accuracy option will be ignored by iOS
        this.locationAccuracy.request(this.locationAccuracy.REQUEST_PRIORITY_HIGH_ACCURACY).then(
          () => console.log('Request successful'),
          error => console.log('Error requesting location permissions', error)
        );
      }
    });
```

上記のコードでダイアログが表示されます。

#android側のコード
サンプルのコードそのままで動きます。
https://ionicframework.com/docs/native/ibeacon/
(プラグインインストールしてね)

ですが、ボタンを押したときだけビーコンを探したいときなど断続的に使いたい場合はモニタリングを止めてやり直させる必要があります。
```this.ibeacon.stopMonitoringForRegion(BeaconRegion);
```
これを適当な場所に書いてやればいいです。

#ios側のコード
こちらもほぼそのままで動きますがiosはandroid側と挙動が違います。
androidはモニタリングしたときからビーコン範囲内にいても```didEnterRagion```に入ってくれますがiosは入ってくれません。なので```didStartMonitoringForRegion```の中から```requestStateForRegion```を呼び出せば自分が指定したregionの範囲内か範囲外かわかるのでこれを使います。(気づくのに半日かかりました)。

#参考にしたところ
https://github.com/petermetz/cordova-plugin-ibeacon/issues/206
https://github.com/petermetz/cordova-plugin-ibeacon/issues/72
https://qiita.com/nosaka/items/5348dd5f8889d445d533
http://yoshiminu.tumblr.com/post/136513507383/ios-ibeacon%E3%81%AE%E3%81%A4%E3%81%BE%E3%82%8A%E3%81%A9%E3%81%93%E3%82%8D
http://enamelsystems.com/0011/
SNSいろいろ設定

# Twitter

## Twitterカード

https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/abouts-cards

```html
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@site_account">
<meta name="twitter:creator" content="@individual_account">
<meta name="twitter:url" content="https://example.com/page.html">
<meta name="twitter:title" content="Content Title">
<meta name="twitter:description" content="Content description less than 200 characters">
<meta name="twitter:image" content="https://example.com/image.jpg">
```
### 検証ツール
https://cards-dev.twitter.com/validator

## シェアボタン
https://publish.twitter.com

https://developer.twitter.com/en/docs/twitter-for-websites/tweet-button/overview

https://developer.twitter.com/en/docs/twitter-for-websites/tweet-button/guides/parameter-reference1

# Facebook

## シェアボタン
https://developers.facebook.com/docs/plugins/share-button/?locale=ja_JP#configurator

## OGP設定

http://ogp.me/

```html
<head prefix="og: http://ogp.me/ns#  website: http://ogp.me/ns/website#"> //トップページ
<head prefix="og: http://ogp.me/ns#  article: http://ogp.me/ns/article#"> //下層ページ

<meta property="fb:app_id" content="FBAppのID"><!--※-->
<meta property="og:url" content="サイトURL">
<meta property="og:type" content="website">//トップページ
<meta property="og:type" content="article">//下層ページ
<meta property="og:title" content="ページのタイトル">
<meta property="og:image" content="OGP画像パス">
<meta property="og:description" content="ページの説明">
<meta property="og:site_name" content="サイト名">
<meta property="og:locale" content="ja_JP"><!--サポート言語--><!--※-->
<meta property="article:author" content="著者名">　<!--※-->

```
title,description:プロパティがない場合すでにある<meta>から参照するがFBは必須としている
type:topはwebsite、それ以外はarticle
<!--※-->は無くてもよい

クイックスタート
https://developers.facebook.com/docs/javascript/quickstart

デバッガー
https://developers.facebook.com/tools/debug/

OGP画像シュミレーター
http://ogimage.tsmallfield.com
Google Mapsに鉄道路線を描画しよう

ヴァル研究所アドベントカレンダー2018の9日目です。

こんな風にGoogle Maps上に鉄道路線を描画したいと思ったことはありませんか？
![image.png](https://qiita-image-store.s3.amazonaws.com/0/79394/9f98b458-fa34-f3be-bee9-5fc5042b5334.png)
（東京の京王線を描画した状態）

もちろん座標データさえあればpolylineで描画できますが、そのデータをどこから入手するかが問題です。


# 1. 駅の緯度経度を結ぶ方法
**[駅すぱあとWebサービスの有償版](https://ekiworld.net/service/sier/webservice/api.html)を使うと、路線名で指定した路線上の全駅情報（緯度経度込み）を取得したり、経路探索してその経路で通過する全駅の情報を取得できたりします。**駅を結ぶ折れ線でよければ、単純にこの緯度経度をpolylineで結ぶだけです。

# 2. 国土数値情報を使う方法

国土交通省が公開している国土数値情報の中に、鉄道データというものがあります。
国土数値情報のライセンスはデータごとに定められており、ものによっては商用利用不可だったりするのですが、本記事の方法で鉄道データを描画することは

>（３）    商用不可の「国土情報」であっても、図化したり、GISによって空間演算した結果（データベースでないもの）については、原典及び加工者名を明示することによって、申請無しに再配布可能です。ただし、利用の成果物がGIS型式やエクセル型式等の データベースの場合は、データベースの著作権の侵害のおそれがありますので、国土情報ダウンロードサービス事務局にお問い合わせください。
> http://nlftp.mlit.go.jp/ksj/other/yakkan.html

に該当するので商用利用可であると私は解釈しています。

さて、[こちらのURL](http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N02-v2_3.html)から `N02-17_GML.zip` （平成29年）をダウンロードすると、下記のように様々な形式のファイルが入っています。

```
KS-META-N02-17.xml
N02-17.xml
N02-17_RailroadSection.dbf
N02-17_RailroadSection.geojson
N02-17_RailroadSection.prj
N02-17_RailroadSection.shp
N02-17_RailroadSection.shx
N02-17_Station.dbf
N02-17_Station.geojson
N02-17_Station.prj
N02-17_Station.shp
N02-17_Station.shx
```

この中の `N02-17_Station.geojson` をWebサーバに配置し、**同ディレクトリ**に下記の `index.html` を作成して配置します。（`アクセスキーを入れてね`の部分を書き換えてください）

```index.html
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8">
    <title>地図</title>

    <script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
    <script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=アクセスキーを入れてね"></script>

    <script>
      var map;

      $(function() {
        var center = new google.maps.LatLng(35.6813095277778, 139.76723425);
        var gmap_options = {
          zoom: 11,
          center: center,
        };
        map = new google.maps.Map(document.getElementById("gmap"), gmap_options);

        map.data.loadGeoJson("./N02-17_RailroadSection.geojson");
        // スタイルの設定
        map.data.setStyle(function(feature) {
          return ({
            strokeColor: "#0000ff",
            strokeWeight: 2,
            clickable: true,
            zIndex: 1
          });
        });
      });
    </script>

    <style>
      html, body  { height: 100%; }
      div#gmap { width: 100%; height: 100%; }
    </style>
  </head>
  <body>
    <div id="gmap"></div>
  </body>
</html>
```

ブラウザでアクセスしてみると、数秒して全国の路線が全部表示されるはずです。どうでしょうか？
（Webサーバに配置せず `file://` スキームで開くとエラーになると思います。 `loadGeoJson` はXHRでファイルをロードするためです）

![スクリーンショット 2018-12-05 9.50.33.png](https://qiita-image-store.s3.amazonaws.com/0/79394/0086405d-abc8-1c17-1b08-5ef944d08c90.png)

国土数値情報がgeojson形式で配布してくれていて、Google Mapsにgeojsonを描画するメソッドがあったので一発でしたね。あとはgeojsonファイルから描画したい部分を抜き出すなど、必要に応じて加工すればよいかと思います。

以上です。
WPF RadioButtonの使い方 覚え書き

# ListBoxをRadioButtonで表現する
よくやり方を忘れるので覚え書きです。

とりあえずはBinding用のクラスを用意する

```Item1.cs
public class Item1
{
  public int Id {get; set;}
  public string ItemName {get; set;}
}
```

ViewModelを用意
PrismとReactivePropertyを使用しているがここでは省略

``` Item1ListViewModel.cs
public class  Item1ListViewModel:BindbleBase
{
  public ReacitiveCollection<Item1> Items {get;} = new ReactiveCollection<Item1>();
  public ReactiveProperty<int> SelectedItem1 {get;} = new ReactiveProperty<int>(0);

  public Item1ListViewModel()
  {
     Items.AddRangeOnScheduler(
         new Item1 { Id = 0, ItemName = "ABC" },
         new Item1 { Id = 1, ItemName = "AAA" },
         new Item1 { Id = 2, ItemName = "BBB" },
         new Item1 { Id = 3, ItemName = "CCC" }
     );
  }
}
```

Viewを用意
今回は前後略でListBoxを記載する

``` 
<ListBox ItemsSource="{Binding Items}"
         SelectionMode="Single"
         SelectedValuePath="Id"
         SelectedValue="{Binding SelectedItem1.Value}">
    <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
           <StackPanel Orientation="Horizontal"/>
        </ItemsPanelTemplate>
    </ListBox.ItemsPanel>
    <ListBox.ItemContainerStyle>
       <Style TargetType="ListBoxItem">
          <Setter Property="Template">
              <Setter.Value>
                 <ControlTemplate>
                     <RadioButton Margin="3"
                                  Content="{Binding ItemName}"
                                  IsChecked="{Binding RelativeSource={RelativeSource TemplatedParent}, Path=IsSelected}"/>
                 </ControlTemplate>
              </Setter.Value>
          </Setter>
       </Style>
    </ListBox.ItemContainerStyle>
</ListBox>
```

これでとりあえずはRadioButtonが横並びに表示されます。
より詳しくは下記のブログから参照できます
参考URL : [RadioButton を ListBox で実装する(frog.raindrop.jp.knowledge) ](http://frog.raindrop.jp/knowledge/archives/002386.html)
NodeMCU-32SとESP32-DevKitCの違い。

ESP-32は技適を取得しており、日本で公正に使用することが可能です。
今回LineThingsを使用する際に、注目を集めたNodeMCUについて説明します。

ESP-8266は自動書き込みが可能なNodeMCUという規格が作られました。
（それまでは、書き込み時にResetとIO0をショートさせる必要がありました）
https://en.wikipedia.org/wiki/NodeMCU

ESP-32になると、ESP32-DevKitCなどでも標準的に自動書き込みが可能になり
日本ではESP32-DevKitCを秋月電子が取り扱うなどした結果、主流はESP32-DevKitCとなりました。
しかし、NodeMCUとESP32-DevKitCでは、基板のサイズが2.54mmほど違います。
この違いは、ブレッドボードを使用した際に顕著に現れます。
![IMG_8923.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/a9e2d785-417a-2190-2316-8c78120ccc59.jpeg)
新型のDevKitCは、ESP32-WROVER-B対応になっていますね。

NodeMCUは左右のピンが使用できるのです。
このため、各GPIOを生かしやすい点から私は、NodeMCU-32S（ESP-32 NodeMCU）をオススメしています。
LineThingsでは、NodeMCUにLEDがついていたことから注目を集めたようです。

識別方法は、基板のレイアウトと、表に、ピンのシルクが無いことです。
類似品で、ESP-32Sという、ESP-32のシングルコア版の製品があるので要注意です。

ちなみに、ESP-8266では、各GPIOのエクステンションボードが販売されておりましたが
ESP-32　NodeMCUでは、販売されていません。
このため、作ってみました・・・

左が、作ったもの、右がESP-12（ESP-8266)の既製品(技適無し）です。
![IMG_8924.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/e04b7e7a-5fc7-3ab5-d422-22e126b9618b.jpeg)

さらに作ったのが、12Vのバッテリーからモーターを駆動できるようにしたフル版です。
![IMG_8921.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/7009614d-f94f-7cc4-12f1-ff79427f741c.jpeg)
Amazon Elastic File System (EFS) による Web サーバー間の同期

## 1. 要約
この記事では、“Amazon Elastic File System (EFS) による Web サーバー間の同期” モデルを投稿します。
この方法で、過去のポストでご紹介した <a href='https://qiita.com/KyojiOsada/items/aa38868c0bbc057ab4e4'>GlusterFS によるモデル</a>と同じの課題を解決しつつ、より簡単に拡張性、弾力性、生産性の高いモデルが実現できるようになります。

## 2. はじめに
今年 (2018 年) の 7 月、AWS 東京リージョンで、Amazon Elastic File Fystem (EFS) がリリースされました。
US リージョンでは、前から提供されていたプロダクトです。
過去の記事 “<a href='https://qiita.com/KyojiOsada/items/aa38868c0bbc057ab4e4'>分散型フォールトトレラントファイルシステム GlusterFS による Web サバー間の同期</a>” では、GlusterFS による Web サーバー間のソースコードの同期方法を投稿しました。
この方法では、いくつかの課題を解決できますが、AWS 環境を利用されている場合、上記の方法よりも簡単にスケーラブルなモデルの実現ができるようになります。
GlusterFS でいうことろのサーバー部分は AWS が担ってくれますので、これらの構築や管理作業の削減ができるようになりますが、EBS などに比べると少しだけコスト高となります。
（コストの詳細は <a href='https://aws.amazon.com/jp/efs/pricing/'>Amazon EFS の料金 </a> などをご参照ください。）
では、以降で Amazon Elastic File System (EFS) を利用した設計と構築の一例を投稿していこうと思います。

## 3. Amazon EFS 環境
* AWS
* AWS EFS
* RHEL 7 系
* NFS4

## 4. Amazon EFS 設計
![EFS_diagram.png](https://qiita-image-store.s3.amazonaws.com/0/260161/b6f3beba-8a4a-4e00-4c8a-29032235a5d3.png)

## 5. Amazon EFS 設定
サービス &gt; ストレージ &gt; EFS を選択します。
設定方法の詳細は、<a href='https://docs.aws.amazon.com/ja_jp/efs/latest/ug/creating-using.html'>Amazon EFS のリソースを作成する</a> などをご参照いただき、適宜設定をしてください。

## 6. Amazon EFS クライアント
### 6-1. NFS パッケージインストール
@ Web サーバー 1, 2
`$ suto yum install -y nfs-utils `

### 6-2. Amazon EFS マウントターゲットの作成
@ Web サーバー 1, 2
`$ sudo mkdir /server`

### 6-3. Amazon EFS マウント
@ Web サーバー 1, 2
`$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx.efs.ap-northeast-1.amazonaws.com:/ /server`

### 6-4. Amazon EFS 自動マウント
@ Web サーバー 1, 2
`$ sudo cp -a /etc/fstab /etc/fstab.org`
`$ sudo vim /etc/fstab`

```text:/etc/fstab
fs-xxxxxxxx.efs.ap-northeast-1.amazonaws.com:/    /server    nfs4    defaults,_netdev    0 0
```

### 6-5. Amazon EFS 同期テスト
@ Web サーバー 1
`$ sudo touch /server/test.txt`

@ Web サーバー 2
`$ sudo ls /server/`
`$ sudo rm -rf /server/test.txt`

@ Web サーバー 1
`$ sudo ls /server/`

## 7. Amazon EFS: まとめ
この記事では、“Amazon Elastic File System (EFS) による Web サーバー間の同期” モデルを投稿してみました。
この方法によって、<a href='https://qiita.com/KyojiOsada/items/aa38868c0bbc057ab4e4'>GlusterFS によるモデル</a>と同じ課題を解決しつつ、より簡単に拡張性、弾力性、生産性の高いモデルが実現できるようになります。

次回以降の記事では、GlusterFS を利用した分散型フォールトトレラントメモリーキャッシュシステムについて投稿してみようと思います。
マイコン初心者キット（Arduino,STM32）

Arduinoなどのマイコン初心者向けのキットを製作しています。

今回は、Arduino Unoと、STM32　Nucleo、B-L475E-IOT01A - STM32L4 Discovery kit IoT nodeをご紹介します。
![IMG_8916.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/da46ffbe-d698-99a5-67d3-b081ccbe0f8a.jpeg)
キット構成は、USBケーブルと、ブレッドボードです。

本来は、ここにジャンパワイヤーや、LED、スイッチ類が必要でしょう。
STM32系は、アドオンボードを追加すると、この箱には入りません。

![IMG_8915.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/3c9fced0-acdc-36a3-7bfc-186360386a05.jpeg)
![IMG_8914.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/b1710e83-712e-36a9-b098-ec2c041fcba8.jpeg)

B-L475E-IOT01A については、こちらの箱を使用する方がいいかも知れません。![IMG_8918.JPG](https://qiita-image-store.s3.amazonaws.com/0/285344/47512132-8ef8-2952-1588-0e75349003f4.jpeg)
AWS Lambda LayersでpythonやNodejsのzipを作る便利なやり方

AWS Lambda Layersの発表により、Lambdaで外部ライブラリを使うのが容易になりました。

Macで外部ライブラリをアップするためには次のようにします。

## python

```
mkdir python
pip install -t ./python numpy #(入れたいモジュール名)
zip -r upload.zip ./python
```

## node 

```
mkdir nodejs
npm install -p ./nodejs lodash #(入れたいモジュール名)
zip -r upload.zip ./nodejs
```

# この方法の問題

- Macでライブラリのzipを作ると、lambdaで動かないことがある
- Windowsの標準zipでは、lambdaにアップしてもダメ

# どうする？
GitlabのCIでzipを作ってしまえば、Amazon Linuxの環境で作ったzipを簡単に手に入れることができます

## Gitlab
- アカウント作成
- プロジェクト作成

をすませてください。

## 実際のci用ファイル
`.gitlab-ci.yml`を作成します。
WEBコンソールから作業しちゃっていいと思います。
内容は下記のとおりです。

``` 
stages:
  - pymodule_zip
  - nodemodule_zip

pymodule_zip:
  image: lambci/lambda:build-python3.7
  stage: pymodule_zip
  artifacts:
    paths:
      - python
  script:
    - mkdir python
    - pip install ${PYTHON_PACKAGES} -t ./python
  only:
    variables:
      - $PYTHON_PACKAGES
      
nodemodule_zip:
  image: lambci/lambda:build-nodejs8.10
  stage: nodemodule_zip
  artifacts:
    paths:
      - nodejs
  script:
    - mkdir nodejs
    - npm i --prefix nodejs ${NODE_PACKAGES}
  only:
    variables:
      - $NODE_PACKAGES

```

# CIを環境変数付きで走らせます

`PYTHON_PACKAGES`でpythonのライブラリのzipを
`NODE_PACKAGES`でnodeのライブラリのzipを
作れるようになります
【usdz_converter】複数map画像のobjをusdzへ変換する方法

私的メモ

```
# Blender MTL File: 'ボーン入れ.blend'
# Material Count: 4

newmtl Material.001
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.081978 0.081978 0.081978
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 1

newmtl body
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 1
map_Kd body3.png

newmtl body_white
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 1.000000 1.000000 1.000000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 1

newmtl UV
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.000000 0.000000 0.000000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 1
map_Kd UV_01.png
```
mtlが読まれない＆こんな感じで複数map画像が使われている場合、`-color_map`を並べても上手くusdz_converterが変換してくれない。

##解決法
`-g`でMaterialNameへ移動してから画像の`-color_map`を指定してあげる。

```
xcrun usdz_converter obj.obj obj.usdz -g UV -color_map UV_01.png -g body -color_map body3.png
```


***
画像じゃない部分は真っ白になり、現状対処出来ないのでオブジェクト全部画像で出力するように
【資格取得】MOS Excel2016 Expertを取得する。

#私のスペック
・仕事でExcelをよく使う。
・割と得意なほう（…だと思う）。
#アイテム
・Microsoft Excel 2016 Expert 対策テキスト&問題集（FOM出版）
#勉強開始　1日目～3日目
・インプット中心。
・上記の対策テキストを読みながら、Excelで操作する。
#勉強開始　4日目～
・アウトプット中心。
・付属の模擬試験をひたすら行う。

※随時、更新していきます。
lambda上でweb3を使って送金する際にやっておくといいこと

# はじめに

これは Ethereum Advent Calendar 2018 の4日目です。

# 自己紹介

* 株式会社MidfreeのCTOの平田です
* [「ETHBOARD」](https://ethboard.jp)という、書き込むとEthereumを貰える匿名掲示板サービスを運営しています
    * このAdvent Calendarを見てる人はきっともれなく全員使ってくれるはず、、、w

# この記事について

web3.jsを用いて実際に送金処理を書いて色々触った経験を元にやっておくといいことをTips的に書いておこうと思います。

# 環境

```
lambda runtime node8.10 (serverless frameworkを利用)
web3 @1.0.0-beta.35
ethereumjs-tx @1.3.7
```

# 送金部分のコード

``` js
sendEth: async (fromAddress, toAddress, privateKey, ethAmount, nonce) => {
    // weiの単位に変換する
    let amount = web3.utils.toWei(ethAmount, 'ether');
    const parameter = { from: fromAddress, to: toAddress, value: amount };
    let gasLimit, gasPrice
    [gasLimit, gasPrice] = await Promise.all([web3.eth.estimateGas(parameter), web3.eth.getGasPrice()])
    // 余裕を持って送金できるようにLimitに余裕を持たせる
    parameter.gasLimit = web3.utils.toHex(gasLimit + 10000);
    parameter.gasPrice = web3.utils.toHex(gasPrice);
    // nonce値はあらかじめ計算しておく
    parameter.nonce = nonce;
    const transaction = new Tx(parameter);
    transaction.sign(Buffer.from(privateKey.substring(2, 66), 'hex'));

    return new Promise((resolve, reject) => {
      web3.eth.sendSignedTransaction('0x' + transaction.serialize().toString('hex'))
        .once('transactionHash', (hash) => {
          resolve({ parameter, hash })
        }).catch(err => {
          reject(err)
        })

    })
  }
```



# 秘密鍵による署名

秘密鍵は「0x」から始めて使用する。
MetaMaskなどでエクスポートする秘密鍵は「0x」が省略されているので注意が必要。

また、「0x」を省略した状態で署名すると、下記の参考URLにあるような「private key length is invalid」のエラーが発生するものの送金ができてしまうという事象が発生したので、それも注意が必要。

参考: https://ethereum.stackexchange.com/questions/55038/ethereum-transaction-rangeerror-private-key-length-is-invalid

# nonce値の算出

nonce値は0から始まって必ずincrementする必要がある。
通常、　`web3.eth.getTransactionCount(address)`　で取得可能。
nonce値の値を飛ばしてTransactionを送るとpendingのまま待機状態になり、間の数値のトランザクションが送られたタイミングで承認される。
つまり、

* 1 送信→pending
* 0 送信
* 0 と 1 →comfirming

のような流れになる。

そのため、nonce値をある程度コントローラブルにするために、DBに保存しながら対応するのがいいと思います。
僕の場合は、大まかには、

* getTransactionCount　と DBのMAX値を取得
* 大きい方を採用してトランザクション送信
* 失敗したらDBのデータを削除

みたいな形で実装しました。

# タイムアウトの設定

web3は通常、下記のようにHttpProviderなどのプロバイダーを登録して使用します。（下記はINFURA利用の場合）

```js
const web3 = new W3(new W3.providers.HttpProvider('https://ropsten.infura.io/v3/hogehoge')
```

タイムアウトを設定しておかないと、ノードの同期に問題が起きている場合などに全然レスポンス返ってこないことがあるので、
設定しておいた方がエラーハンドリングが楽になります。(タイムアウト時間はサービスの特性を元に検討してください。)

```js
const web3 = new W3(new W3.providers.HttpProvider('https://ropsten.infura.io/v3/hogehoge',{ timeout: 5000 })
```

# lambda特有の問題

web3に限った話ではないんですが、web3をlambda上で動かす場合は、nativeモジュールが必要になります。
なので、linuxで開発してデプロイするような場合を除いては、nativeモジュールでビルドしてからデプロイする必要があります。
僕はMacで開発しているので必要でした。

下記の記事を参考に、Dockerでリビルドしてからデプロイするようにしています。
参考: https://github.com/serverless/serverless/issues/308

# おわりに

この記事でweb３での問題にぶち当たる人が少なくなればいいなと思っています。
個人的には、gethの同期とかの方が問題多かったりするんですけど、ちょっと解説仕切る自信がなかったので今回は見送りましたw
OpenCV 顔検出をやってみる

初めまして、白井です。
OthloTech Advent Calendar 2018の15日目の記事を書いていきます。
OpenCVを使い始めて初歩の初歩の記事なので参考になりません。
あらかじめご了承ください。
今回、Haar特徴ベースのCascade型分類器を使った顔検出を行います。
#環境
- Mac　OS　Mojave　10.14.1
- OpenCV 3.4.1_5

#手順
以下の手順でやっていきます。
-画像を用意する
-分類機を用意する
-実行
#画像の用意
![1.jpg](https://qiita-image-store.s3.amazonaws.com/0/322631/ccceb676-3a9a-53b1-8d35-d3f4eaa3563b.jpeg)
[ぱくたそ](https://www.pakutaso.com/20181142311post-18434.html)
![2.jpg](https://qiita-image-store.s3.amazonaws.com/0/322631/d81a5c75-b124-604c-c015-ad9b53dff3e5.jpeg)
[ぱくたそ](https://www.pakutaso.com/20180553142post-16253.html)
ぱくたそさんから二枚の画像を用意しました。
1枚目は正面の顔が写っているもの。
2枚目は横顔が写っているもの。
#分類機の用意
分類機を用意するにあたって自作するには知識が足りず精度が落ちるとのことなので公式が用意している_haarcascade_frontalface_default.xml_を使わせてもらいました。
[GitHub](https://github.com/opencv/opencv/tree/master/data/haarcascades)
#プログラム
流れはこんな感じです
1 haarcascade_frontalface_default.xmlを読み込み、分類機を作成
2 分類機に画像を指定して顔を検出
3 検出した範囲を矩形で囲む

```ruby:main.cpp
#include <iostream>
#include <opencv2/opencv.hpp>
#define FILENAME "haarcascade_frontalface_default.xml"
int main(int argc, char const *argv[])
{
    //入力画像の読み込み
    cv::Mat src_img = cv::imread("画像ファイル");
    //出力画像を入力画像からコピー
    cv::Mat dst_img = src_img.clone();
    cv::CascadeClassifier cascade;
    cascade.load(FILENAME);
    std::vector<cv::Rect> faces;
    // 指定した識別器を用いて画像から顔を検出
    cascade.detectMultiScale(dst_img, faces, 1.1, 3, 0, cv::Size(20, 20));
    //検出した顔を矩形で囲む
    for (int i = 0; i < faces.size(); i++) {
        rectangle(dst_img, cv::Point(faces[i].x, faces[i].y), cv::Point(faces[i].x + faces[i].width, faces[i].y + faces[i].height), cv::Scalar(0, 200, 0), 3, CV_AA);
    }
    //入力画像の表示(比較用)
    cv::imshow("src", src_img);
    //出力画像の表示
    cv::imshow("dst", dst_img);
    cv::waitKey();
    
    return 0;
}

```
#実行結果
<img width="802" alt="スクリーンショット 2018-12-14 23.31.40.png" src="https://qiita-image-store.s3.amazonaws.com/0/322631/904be104-f489-96f2-926e-15c030d91c2e.png">
1枚目はうまく顔を検出することができました。
<img width="801" alt="スクリーンショット 2018-12-14 23.31.13.png" src="https://qiita-image-store.s3.amazonaws.com/0/322631/a80553cf-d7d4-69f3-5a21-0c6c89ba8c64.png">
2枚目は正面からの画像ではなかったため、顔を検出することはできませんでした。

#感想
今回は正面の顔の検出を行なったが、少ないコード量で動かすことができた。今後は横顔にも対応できるような分類機を自作してみようと思った。
また、この記事を書くにあたって初めてのことが多く、とりあえず動けばいいやと思ってコードを書いていたので仕組みももう少し詳しく理解していきたい。
最後に、記事を書く機会を与えてくれてありがとうございました。とてもいい体験をすることができました。今後も自分で情報を発信していこうと思えるきっかけになりました。
#参考文献
[ゴリラになる知識](http://gori-naru.blogspot.com/2012/11/blog-post_13.html)
dep ensure -updateで特定packageのみ更新する

下記コマンドだと依存package全ての更新をしてしまうので...

```
$ dep ensure -update
```

`-update`の引数にpackage名を渡すと特定packageのみ更新できる

```
$ dep ensure -update github.com/hogehoge
```

以下のように`.vendor-new`が存在するのでエラーだよと怒られた時は...

```
grouped write of manifest, lock and vendor:
scratch directory hogehoge/.vendor-new already exists, please remove it
```

指示通り`.vendor-new`を削除してから再度実行する
M1の得点を主成分解析にかけてみた

年末恒例M1グランプリが開催されたようで, 優勝者の名前や審査員のつけた得点なんかが聞こえてきた.
諸般の事情により本戦を見ることはどうしてもできず, ただ結果だけを知っているという状況なので, 審査員の得点から勝手に妄想してみた. 

# やったこと
M1グランプリ2018決勝の得点をRで主成分解析．
使用ソフトはR 3.5.1. 出発行列は相関係数行列. 
(i.e., `prcomp(得点データ, scale=TRUE)`)

# 結果
## 寄与率
累積寄与率を見ると, 第3主成分(PC3)で累積寄与率が95%を超えるので, PC3までを見れば, あらかた説明ができるらしい.

|             |PC1  |PC2|PC3  |PC4  |PC5  |PC6  |PC7  |
|---          |--:  |--:|--:  |--:  |--:  |--:  |--:  |
|標準偏差      |2.28|1.04|0.644|0.393|0.336|0.217|0.114|
|寄与率 [%]    |73.9|15.5|5.92 |2.21 |1.61 |0.67 |0.19 |
|累積寄与率 [%]|73.9|89.4|**95.3** |97.5 |99.1 |99.8 | 100 |

## 第1主成分(PC1).
PC1は, 総得点と綺麗に相関している. どうやらPC1=今大会での評価(=面白い順?盛り上がった順?)のようだ.

![M1_2018_Score.png](https://qiita-image-store.s3.amazonaws.com/0/261968/738898a7-8776-ad4d-a5dd-31296f5400d8.png "図2: 総得点 vs PC1")

PC1と各審査員がつけた得点の相関係数を見ても, かなり高い正の相関であり, ある程度順当な得点がつけられていった模様. 
そんな中, 若干相関係数が低いのが上沼恵美子氏と立川志らく氏. 逆張りというほどではないけれど, 数字を見ると我が道を行っている感がある. 

||巨人|中川家|塙|立川|富澤|松本|上沼|
|---|---|---|---|---|---|---|---|---|---|
|PC1|0.92|0.83|0.94|**0.65**|0.92|0.96|**0.76**|


## 第2主成分(PC2)と第3主成分(PC3)
個人的に面白かったのがPC2とPC3. 

||巨人|中川家|塙|立川|富澤|松本|上沼|
|---|---|---|---|---|---|---|---|---|---|
|PC2|0.055|0.32|-0.17|**-0.72**|0.057|-0.22|**0.62**|
|PC3|**-0.26**|**-0.42**|0.18|-0.13|**0.28**|0.13|0.16|

まず, PC2を見てみると, 先ほど我が道を行っていた上沼氏と立川氏が, 全く逆の相関係数を持っている.
かたや関西の女帝, かたや関東落語界の名門と考えると, PC2は関東・関西のお笑いの好みっぽい.
漫才協会理事である塙氏がごくごく弱いながら負の相関係数であるのも，それっぽさを加味している気がする. 

一方で, PC3を見てみると, 巨人氏・中川家礼二氏が弱い~やや強い負の相関係数である一方, 富澤氏が弱い正の相関係数となった.
これは勝手な印象として, PC3との相関が正だとコント漫才評価志向, 負だとしゃべくり漫才評価志向なんかいなという感想. まぁ, よくわからん. 

そんなこんなを無理やりこじつけると,　PC2得点 vs PC3得点で分類した時に第1象限(右上)は関西風コント漫才, 第2象限(左上)は関東風コント漫才, 第3象限(左下)は関東風しゃべくり漫才, で第4象限(右下)は関西風しゃべくり漫才と行った分類なのかなと.
そうか，松本氏は若干評価が東京寄りだったのか．．． 


![M1_2018_PC2vs3.png](https://qiita-image-store.s3.amazonaws.com/0/261968/6c7e11cd-737b-4d27-7392-de1d4c030631.png "図3: PC2 vs PC3")


以上ウダウダと数字をこねくり回してきましたが, これって一次データを見ずに"分析"するという一番やっちゃいけないことをしている.
ま，話半分面白半分ということで，どうかお目こぼしを