OmniAICreator/Qiita-1.07M huggingface dataset:
エンジニアがおさえておくと便利な広告まわりの用語&クリックをあげるTips 

ごきげんよう〜meloco(@usr_meloco)です。
新卒&Webエンジニア3年目の私ですが、今年は事業の売上UPをミッションとして主に広告周りを担当させていただきました。
プロダクト本体のユーザー数や会員数を上げるというよりは連携しているアフィリエイトや広告のCVRをいかにあげるかといったことで、
マネージャーでもマーケターでもなく1エンジニア目線で、やってみて良かったなと思ったことと、
CTR?グロース?そもそも数値ってどうやってみるの??ととにかくわからない単語が多かったので入門編としてまとめてみました。
普段つかわなくても、概念としてそういう基準を知ること自体が何かの参考になるかな〜という想定です。
クリックがあがりそうなタイトルも募集中です。

## エンジニアが数値UPに参加するメリット
一般的にグロースハックチームの最適な構成はマネージャー、エンジニア、デザイナーとされていることが多いようです。
エンジニアとして従事していると、普段からも何らかの数値を目標として掲げているパターンが多いかと思いますが、
広告においては見た目の改善だけでなく表示速度やコンバージョンまでの導線、
分析できる数値をいかに仕込めるかなど、エンジニアとしての技術的な頑張りが売上として顕著に反映されます。
日々自分の開発した成果がプロダクトの数値としてどう反映されたか定量的に測れることは重要でやる気にもつながりました。
また施策は早いサイクルで行っていくことがマストですが、仕様によっては実装が複雑になることも少なくなく
そんな中ここまでの実装なら効果もありそうだし工数も削減でき早く出せそう、といった意見を
エンジニアからいうことができ、効率の良い改善案につながるかな〜と感じました。
※ 個人的な意見です

## エンジニアが売上目標をもってよかったなと思ったこと
新卒プログラミング未経験で入社して、最初の2年間は〇〇を実装する、とか〇〇をいくつだすといった
技術力を磨きつつプロジェクトに貢献する、みたいな目標をたてていたのですが、ひたすらいかに実装するか戦ってきた部分が大きかったように思います。
自分なりに技術力もついてきたこともあり、自分で考えたことを自分で考えて実装することができてきて、結果は数値でしか測れない、となると
いかに早く実装するか、いかに効率よく実現するか、そういった中で自分で考えながら自然と技術を学ぶことができたかなと感じました。

ここまでは所感です!!
以下はがらっとかわって抑えておくと便利な主に広告や数値周りの単語などをまとめました。何かの参考になればと思います


## 数値周り

### KGI
KGI（Key Goal Indicator）とは、重要目標達成指標といいで最終的な目的が達成されているかを図るものです。
ex) 1ヶ月の売上を1000万から1500万にあげる

### KPI
KPI(Key Performance Indicator)とは、重要業績評価指標といいKGIを達成するための過程の指標のことです。
ex)1ヶ月の売上を1000万から1500万にあげることがKGIだった場合
・ユーザー数を〇〇にする
・広告面を〇〇こ追加する
・CVRを〇〇倍にする
といったことがKPIとしてあげられるかなと思います。

### PV(ページビュー)
アクセス数のことで、1ページ表示されるのが1PVとなります。

### インプレッション数(imp)
広告が表示された回数のこと。
1ページに3つ広告を貼っていた場合、1PVで1impとなります。

### クリック数
広告がクリックされた回数

### コンバージョン数
コンバージョンとは、成果となる行動をとった数のこと。
商品を買ってもらうことが目的のECサイトでは、閲覧履歴のあるバッグの一覧が広告として表示されていた場合、
興味をもって商品の詳細ページへ遷移した回数がクリック数、
そこから実際に商品を買った回数がコンバージョンとしてカウントされます。

### CTR(クリック率)
Click Through Rateの略でインプレッション数に対するクリック数の割合のこと。
ショッピングサイトにおいてとあるバッグを100人がみて1人が購入ボタンをクリックしたらCTRは1%。

### CVR(コンバージョン率)
Conversion Rateの略でコンバージョンに至った割合のこと。
基本的には コンバージョン数 ÷ imp数とします。
コンバージョンは人だったり回数だったり、impもサイト全体なのか特定のページなのか反映は様々です。

### CPC
Cost Per Clickの略でクリック単価のことです。
広告を掲載する代わりにクリックされたら1クリックあたり〇〇円もらえる、という単位です。

### CPA
Cost Per Action(Acquisition)とはコンバージョン1件にかかった広告費用のこと。


## 広告周り

### ネットワーク広告
広告配信会社が広告の掲載媒体に対して広告を配信するアドネットワークを利用した広告のこと。
ITエンジニアだとサイトをみていて右上の方の「転職してやる!!」みたい広告とかよくみるやつですね。

### アフィリエイト広告
成果報酬型の広告のことで、なんらかのコンバージョンがあったときに掲載している媒体に対して広告主から成果報酬が発生する広告。


あとDFPとか広告の種類はすごい数があるので今回は割愛します。。。
奥が深い。。。


## エンジニアができそうなクリック、コンバージョンを上げるTips

### 分析できる環境を用意する
これはそもそもなのですが、分析できる環境がないと数値はおえません(´；ω；｀)
アクセスログ、GA、トレジャーデータなどたくさんありますが、
私は先輩方がコンテンツに仕込んでくださったトレジャーデータで蓄積されたデータをもとに
ユーザーの動きや数値の推移を分析していました。
scriptタグ内に任意のDOMがクリックされたときにこのテーブルにこのデータを送信する、といったことが簡単にできるためおすすめです。

### 広告をなじませる
ちょっとデザインよりの話ですが、掲載している媒体になじませた方がクリックが高い場合はよくあります。
ただ、掲載媒体の色にかかわらず使用する色味によって顕著に変わってくる場合もあるのでベターですがABテストは重要。

### 速度改善
広告は速さが命です!0.1秒にも満たないくらいの速度改善でも規模によっては数十万、数百万変わってきました。
タイムアウト値をギリギリまで短くする、外部CSSを利用しないようにする、
画像を圧縮する、インフラ環境を整備するなどといったことでしょうか。

などなどなどなど。。。


## さいごに
1年ぶり2度目のQiita投稿ですが、まとまりのない感じになってきてしまったかな。。
と反省しつつ、こんな形で働いているエンジニアもいますよ〜ってことで何かの参考になれば(*^^*)
今更ではあるが、memcachedについて学習してみた


## 概要
NoSQL界隈ではRedisやCassandra、Couchbassが流行りと見受けられる。
だが、今回は業務で利用している、memcachedについて改めて学習したことをまとめていく。

## memcachedとは?
memcachedとは分散型キャッシュシステムを構築することができるソフトウェアである。
kvsの方式でデータを保存することができ、メモリ上にデータを保存するNoSQL。

```
kvsとは?
データの保存・管理手法の一つ。
任意の値(value)に対して対応する標識(key)を設定して保存する方法。
```

## 特徴
* メモリ上にデータを保存しているため、データの書き込み・読み込みが早い。
* RDBと組み合わせる事で、RDBの読み込みの負担を軽減できる。
* クライアントライブラリで分散処理を実装できる。
* メモリ上にデータを保存しているため、memcachedの再起動を行うとデータがリセットされる。
* 設定した容量を超えると利用されないキャッシュから順番に消える(LRU)。

```
LRUとは?
未使用の時間が最も低いものを判定するアルゴリズム
```

## 分散処理について
memcachedはクライアントライブラリで分散処理を実装することが出来る。
PHPのライブラリ（[Memcache](https://www.php.net/manual/ja/book.memcache.php)）では、分散処理はキーごとにサーバを使い分けることで実現している。
呼び出しも同様のアルゴリズムとなっているので、保存したmemcachedを参照する。

![分散処理の例](https://qiita-image-store.s3.amazonaws.com/0/39671/0dc47107-98b1-8a22-51ed-68c23b7fc86d.png)

## PHPのクライアントライブラリ
### [Memcache](https://www.php.net/manual/ja/book.memcache.php)
#### 特徴
* PHP4.3.3以上で使用可能
* インストール時に他のライブラリに依存しない

###[Memcached](https://www.php.net/manual/ja/book.memcached.php)
#### 特徴
* PHP5.2.0以上で使用可能
* インストール時にlibmemcachedモジュールが必要
* memcacheより利用できるメソッドが多いらしい

## 導入
### memcached
導入方法はソースでのインストールやyumでのインストールがある。  
今回はyumでのインストールを行う。

```
yum install -y memcached
```

### PHPライブラリ
PHPライブラリも同様にyumでインストールできる。
サーバのPHPバージョンに合わせること。
今回は動作確認のためにmemcacheとmemcachedの両方をインストールするが、実際に使う際はどちらか一つで問題ない。

```
yum install -y php72-php-pecl-memcache
yum install -y php72-php-pecl-memcached
```

あとは他のextensionと同様にphp.iniに追加する。

```
extension=memcache.so
extension=memcached.so
```
これで動くはずだったが、下記のWarningが発生した。

```
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/memcached.so' - /usr/lib64/php/modules/memcached.so: undefined symbol: memcached_touch in Unknown on line 0
```

[こちら](http://takashi-kun.hatenablog.com/entry/2013/11/23/031343)を参考に対応し、正常に動作するようになった。

#### 速度比較
PHPライブラリの読み込みと書き込みの速度を比較してみる。
実行結果を見ると僅かな差で Memcachedが勝っているようにみえる。

|ライブラリ名|書き込み|読み込み|
|:---------|:------|:-----|
|Memcache|0m23.270s|0m21.703s|
|Memcached|0m19.938s|0m19.213s|

[ソースコードはこちら](https://github.com/juve534/TIL/tree/master/memcached/workspace/code)

## 参考資料
PHPのMemcachedモジュールをインストール
http://takashi-kun.hatenablog.com/entry/2013/11/23/031343
時系列のデータを使い、遅延予測！！！

# はじめに
人間的な考え方の実現のために
ニューロンを取っ払っていこうと思います！！
不可能だと思ったらいってください。
作り始めてしまうので．．．

#　仕組み
**まず時系列のデータを用意します。**
イラスト、前よりうまくなってきた～☆
![無題.6.jpg](https://qiita-image-store.s3.amazonaws.com/0/216255/b7b1a913-2490-78fd-89f8-d77a6c7a86aa.jpeg)
**色を時間ごとにつけた**
矢印はわかりやすいようにつけた。
![無題.７.jpg](https://qiita-image-store.s3.amazonaws.com/0/216255/ca969fd2-dcfc-ad3a-c708-9a9c3c372db5.jpeg)
**過去の情報が現在の値を予想する（過去は場所によって影響力が違う）**
![無題.８.jpg](https://qiita-image-store.s3.amazonaws.com/0/216255/bfbcd8af-35d8-b191-eebd-01a69dd669b4.jpeg)
**というか必然的にそうなる。と考えられる（笑）**
![無題.９.jpg](https://qiita-image-store.s3.amazonaws.com/0/216255/455947aa-afa9-d63b-1b3a-6ab3d4106ea3.jpeg)
**情報量、計算量、バグが多い　と思う。しかし前回とは違い影響の場所、学習速度、人間に理由が理解しやすい　と思う。**
![無題.１０.jpg](https://qiita-image-store.s3.amazonaws.com/0/216255/a9f68704-fc49-55f0-367f-4c61808cb11d.jpeg)
# 終わりに
説明が下手ですみません．．．(-.-)
同じようなものを知っているなら教えてください！！
jQueryでランダムに生成したIDでハマった時の対応

# はじめに

なんとなく趣味でちょっとjQuery扱ってみたいなーと思ってハマった部分のメモ書きになります！
jsで同様の挙動になるかは試しておらず、特に調べもしていないので、既存でも記事があったらごめんなさいｗ


# 目標

* 背景divに対して `Math.rondom()` で生成した値を利用したidによる新規divを作成した上で、cssを追加する
    * divを勝手に作って、勝手に消えるような挙動を作りたいためにランダムにしたかった

# ハマったコード

```js
var hoge = "Hoge-"
var bg = $("#background")
var id = hoge + Math.random()
bg.append('<div id="' + id + '"></div>')

$("#" + id).css({
... //css記載
})
```
上記の場合、cssが適用されなかった

# 原因

* idに対して `.` が組み込まれていたせい
    * ですよね・・・そりゃ、なりますよね・・・

# 改善したコード

```js
var hoge = "Hoge-"
var bg = $("#background")
var id = hoge + Math.floor( Math.random() * 1000 )
bg.append('<div id="' + id + '"></div>')

$("#" + id).css({
... //css記載
})
```
* ものにはよりますが、1000個ぐらいのdivであれば、まぁ、重なることがないかなと

# 結論

* 使用できる文字列ぐらい、リファレンス読むかどうにかすべきだったｗ
* idに対して `.` が組み込まれていた場合、取得できない
    * 根本的原因調査まではしていないので、とりあえず動くからOKってことで・・・
glsl リプリケーションと平行世界

# リプリケーションとは
フラグメントシェーダーで、現在、処理している画素の座標をある数字で割ることで、図形がリプリケーション(複製)されるという現象のことでした。なんとなく、ある数字で割った余りなのだから、同じ図形が繰り返されるというのはイメージがつくかもしれませんが、とても不思議ですよね。

# まず前提として
glslは、頂点シェーダーであれば、頂点の数だけ、フラグメントシェーダーであれば、画素の数だけ同じプログラムが並列で実行されるのでしたね。
ということは、フラグメントシェーダーであれば、全く別個の平行世界が画素の数だけ存在するともいえますね。

このまま、何も基準もない状態であれば、全く別個の平行世界が画素の数だけ存在することになりますが、現在、処理している画素の座標(gl_FragCoord.xy)を基準とすることで1つの世界とすることができます。

このgl_FragCoord.xyを正規化したものをpとします。

```glsl
vec2 p = (gl_FragCoord.xy * 2.0 - r) / min(r.x, r.y);
```

このpを割るということは世界を割っているのに他ならないのです。
PostgreSQL事始め（ことはじめ）

初Qiita投稿です。わーい:grinning:

ちなみにこちらは、
Geek Women Japan Advent Calendar 2017 19日目の記事です。
https://qiita.com/advent-calendar/2017/geekwomenjapan

Geek Womenなのに、内容は**geekっぽくない**です。(はじめに)
なんかもう迷える子羊的な内容。。。

- 記事背景

 - 10月から派遣先が変わったが、そこがPostgreSqlだった。
 - 一人1システム担当 → DB設計～製作・テスト～リリースまで全部やる
 - PostgreSql初!! → 今まで使ったRDBはOracle、SQLServer、Mysqlとその仲間達(MariaとかAurora)

そんなに他のDBと変わらないよー。と言われてましたが、
いざやってみたら結構違うー:scream:

- テーブル一覧表示 
    - Postgresql : `\d` 
    - Mysql : `SHOW TABLES FROM データベース名`
- システム日付取得方法
 - oracle : `sysdate`
 - mysql : `now`,`sysdate`
 - postgresql : `now`,`current_timestamp`

このあたりは、あからさまに違うのでどこかにメモっておけばよいのですが、
一見違いがなさそうなのに、結構違う。というのが下記です。

[PostgreSQL 9.6.5文書　8.3. 文字型](https://www.postgresql.jp/document/9.6/html/datatype-character.html)

>空白で埋められる型を使用した場合の保存領域の増加、および、長さ制限付きの列に格納する際に長さを検査するためにいくつか余計なCPUサイクルが加わる点を別にして、これら3つの型の間で性能に関する差異はありません。 他の一部のデータベースシステムではcharacter(n)には性能的な優位性がありますが、PostgreSQLではこうした利点はありません。 実際には、格納の際に追加のコストがあるため、character(n)は3つの中でもっとも低速です。 多くの場合、代わりにtextかcharacter varyingを使うのがお薦めです。

…他のDBからPostgreSQLに移行したけど性能がでない。とか起きそう。


他にも変わっているところでは、下記の特別な文字データ型。

|型名|格納サイズ|説明|
|:--|--------:|:---------:|
|"char"|1バイト|単一バイト内部データ型|
|name|64バイト|オブジェクト名用の内部データ型|

"char"とcharactorは別物で、
"char"はシステムカタログで内部的に使用される。との説明が。
内部的に使用される?普通に使えないの?という疑問が

ちなみに"char"でテーブル作成して、insert, update, delete したけど、
普通に使えました。んー:rolling_eyes:
PostgreSQLまだまだ修行が必要です。。。
それでは、このへんで。

明日は [@KamekoKameKame](https://qiita.com/KamekoKameKame) さんです:sparkling_heart:
systemd-nspawnのイメージを用意するnspawn-bootstrap

[systemd-nspawn Advent Calendar 2017](https://qiita.com/advent-calendar/2017/systemd-nspawn) 22日目の記事です。


Githubに[nspawn-bootstrap](https://github.com/mafintosh/nspawn-bootstrap)というのがあったので紹介

# インストール

```bash
npm install -g nspawn-bootstrap
```
これだけ

# 使ってみる

```bash
# ubuntu
nspawn-bootstrap ./ubuntu-16.04.img --ubuntu xenial --size 4GB
# debian
nspawn-bootstrap ./debian.img --debian stretch
# arch
nspawn-bootstrap ./arch.img --arch --size 4GB

# import
machinectl import-raw ubuntu-16.04.img
```

サイズ省略すると4Gになります。


動作としては、サイズで指定したrawファイル作って,ext4でフォーマットして、debootstrap(archはpacstrap)でファイル入れるという挙動です
あんまりsystemd-nspawnをrawファイルで使わないからなぁ・・・
どっちかっていうとkvmとかで動かす場合に重宝しそう
問題検出をするためにXcodeのCode Diagnosticsを利用する。

SENSY株式会社のnamcoです。
業務ではiOS APPの開発をしています。

今回は、xcodeのScheme - Diagonosticsを見直した時の内容を、備忘録として書き残しておこうと思

下記のような流れで。
1. Address Sanitizer
2. Thread Sanitizer
3. Main Thread Checker
4. Undefined Behaviour Sanitizer
5. まとめ

## Address Sanitizer
[Address Sanitizer]
(https://developer.apple.com/documentation/code_diagnostics/address_sanitizer)

- 実行時にメモリ破損やその他のメモリエラーを検出するツール。
- チェックを有効にしてコードを実行すると、CPUの速度が2〜5倍に低下し、メモリ使用量が2〜3倍に増加する。 
- 検証例: [SwiftのAddress/Thread Sanitizer](https://qiita.com/mono0926/items/901d39ef06f2ac330c68)




## Thread Sanitizer
[Thread Sanitizer]
(https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer)

- スレッドセーフになってないオブジェクトに、意図せず複数スレッドでアクセスしてしまった時に検知をして、警告を出してくれる。
- Thread Sanitizerのチェックを有効にしてコードを実行すると、CPUが2〜20秒遅くなり、メモリ使用量が5〜10倍に増加する。
- 64ビットMacOSおよび64ビットiOSおよびtvOSシミュレータ（watchOSはサポートされていません）でのみサポートされている。デバイスでアプリケーションを実行するときはTSanを使用できない。
- 検証例: [SwiftのAddress/Thread Sanitizer](https://qiita.com/mono0926/items/901d39ef06f2ac330c68)


## Main Thread Checker
[Main Thread Checker]
(https://developer.apple.com/documentation/code_diagnostics/main_thread_checker)

 - Main Threadで呼ばれるべき処理が、Main Thread以外で呼ばれていないかを実行時にチェックしてくれる。
 - CPUのオーバーヘッドは1〜2％、プロセスの起動時間は0.1秒未満。
 - デフォルトで有効になっているが、問題の箇所でプログラムの実行を止めたい場合はPause on issuesにもチェックをつける
 - 検証例:[iOS 11 Xcode 9で“だいぶまとも”に！新機能をまとめてみた](https://dev.classmethod.jp/smartphone/iphone/xcode-9-new-features/)

## Undefined Behaviour Sanitizer
[Undefined Behaviour Sanitizer]
(https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer)

 - 実行時に未定義の動作を検出する。
 - デバッグ構成では平均20％のCPUオーバーヘッドがある。
 - 検証例:[iOS 11 Xcode 9で“だいぶまとも”に！新機能をまとめてみた](https://dev.classmethod.jp/smartphone/iphone/xcode-9-new-features/)




## まとめ
- Main Thread Checker以外は、どれを利用するにしても、パフェーマンスへの影響が大きいので、各種設定を有効にしたschemaを作っておき、デバッグしたい時のみ利用するのが良さそう。
- 諸々の使い方をappleが動画で解説してくれている。年末年始に確認しよう。<br>
[Finding Bugs Using Xcode Runtime Tools]
(https://developer.apple.com/videos/play/wwdc2017/406/)

下記参考にさせていただきました。ありがとうございます。

### 参考
[SwiftのAddress/Thread Sanitizer](https://qiita.com/mono0926/items/901d39ef06f2ac330c68)
[Finding Bugs Using Xcode Runtime Tools]
(https://developer.apple.com/videos/play/wwdc2017/406/)
[iOS 11 Xcode 9で“だいぶまとも”に！新機能をまとめてみた](https://dev.classmethod.jp/smartphone/iphone/xcode-9-new-features/)


以上です。
年会費プランの新規入会者数が10倍になった話

# 年会費プランの新規入会者数が10倍になった話

* ホワイトプラスで、マーケティンググループに所属しているoguraです。
* ホワイトプラスでは、クリーニング工場支援や、新規事業企画、サービスのPO、レポートの改善や廃止まで色々やっています。

## この記事で書いてること

* ネットの宅配クリーニングリネットにおける有料会員（年会費プラン）の新規入会を改善した話し
* 施策実施前後で新規入会者数が10倍に増加


![image.png (84.8 kB)](https://img.esa.io/uploads/production/attachments/2352/2017/12/15/6580/ca43d173-26b9-4dc8-b141-4674e9098b24.png)
* 新規入会者数10倍：施策実施後の加入者数と施策実施前との比較

## 対象者

* プロダクトオーナー
* サービスの運営者
    * 新しい機能・サービスを追加している人
    * または新しい機能を既存会員に使ってもらいたい人


## はじめに
* 「リネット」は、ネットで頼める宅配クリーニングです。（[詳しくはこちら](https://www.lenet.jp/trial)）
* リネットは、「[プレミアム会員](http://www.lenet.jp/premium)」という有料会員サービスを提供しています。
* プレミアム会員は、「月会費プラン」と「年会費プラン」の2コースがあります。

* サービス提供側の視点では、月会費プランと比べ、年会費プランに加入頂くほうが継続利用率が高く収益面で安定します。
* そのため、年会費プランのほうがお客様のメリットが大きくなるように設計しています。

## 年会費プランとは？

* 年会費プランは、2016年2月にスタートし、月会費プランと比べて、お得なプランでリリースしました。（＊月会費プランは2014年から提供しています）
* しかし、年会費プランはお得なプランにも関わらず、「月会費プランを1年以上使っているお客様」や「継続意向の高い（と予想される）お客様」でさえも、月会費プランを利用し続けたままでした。

* ということで、お客様にとってもメリットのある年会費プランの新規入会者数（月会費からの乗り換え）をどうやって増加させるかを考えました。

## 加入してもらえない理由 / 課題 は何か？
* とりあえず、加入してくれない理由を考えました。
    * ①特典内容に不満
    * ②1年間も使うかわからない
    * ③年会費プランを知らない

* 途中の調査・考察は省略しますが、
    * 結論としては、③年会費プランを知らない から 「年会費プランが伝わっていない」を課題として設定しました

## 伝わらない理由はなにか？

* 現状は・・・
    * お客様に、年会費プランの特典内容を説明すると、反応は良く、加入したいという声を頂けました。
    * 年会費プランの訴求は、リリース時に全ユーザに告知、都度の登録促進メールの配信をしていました。
    * しかし、入会者数が伸び悩んでいます。
* 伝えるタイミングを改善する必要があると考えました。
    * お客様がクリーニングを利用しないタイミングで訴求しても見てない、または見ているんだけど、利用するタイミングでは忘れてしまっていると考えました。


## お客様が利用する直前・利用中を狙う

* 入会促進するために、狙ったタイミングは2つ
    * ①お客様がクリーニングを意識する可能性が高い、衣替えの時期
        * DMやメール配信などを実施
    * ②クリーニングの注文をしたとき
        * 注文完了後に、バナーを表示

* すると、それぞれ高いCTR / CVR がでました。
    * 特に注文後に訴求の場合は、常に実施可能な施策のため継続的な効果が見込めました。またクリックした人のうち50%の人が加入するという高いCVRがでました（リリース直後の数値）

* 結果、年会費プランの新規加入者数が10倍にまで増加しました。


## まとめ

* 事業者都合（リリース告知や、定期的なメルマガ配信）のみの訴求だけではなく、お客様視点で利用しやすい訴求をする。
* 自社サービスの会員でも、例えばよいサービスでも、ただメールを送るだけでは伝わりません。
* お客様のニーズや行動を考え、適切なタイミングで伝えないと、効果は10倍以上に変わることになります。


## 最後に。

ホワイトプラスでは、[新しい技術にどんどん挑戦したい！という技術で事業に貢献したいエンジニアを募集](https://www.wantedly.com/projects/169974)しております。
Mapbox GL JS の描画の仕組み

ベクトルタイルと言えば MapBox、MapBox といえば ベクトルタイル。

というわけで、以前こんな↓記事を書きました。

* [Mapbox GL JS をデバッグするまで - Qiita](https://qiita.com/amay077/items/5b2cbde9e06184166f35)

Google Maps や Apple のマップアプリでは、もはや自然にベクトルタイルが採用されているわｋですが、あれらは当然ながらプロプライエタリ・ソフトウェアであり、ソースは公開されていません。

MapBox は多くのソースコードを公開してくれていて、プログラマにはありがたいかぎりです。

* [Mapbox - github](https://github.com/mapbox)

最近では、Android 向け Google Maps で、Web版のような「[２本指スクロール](http://appllio.com/google-maps-embedded-two-fingers-touch-scroll)」を実現しようとしたのですが、Google Maps SDK にはそのような機能はないので、 [MapBox のソースコード](https://github.com/mapbox/mapbox-gl-native/tree/master/platform/android/MapboxGLAndroidSDK/src/main/java/com/almeros/android/multitouch/gesturedetectors)を一部改造して実現してみたり。

## MapBox GL JS の描画処理を追ってみる

ということで、前回デバッグ環境を作ったので、今回は地図の描画処理を追ってみたいと思います。
描画のアルゴリズム自体は、必ずしもベクトルタイル特有のものではありませんが、その高速な描画処理は、他へも活かせるノウハウであると思っています。

さて、いろいろすっ飛ばして本題に入りますが、描画に係る主要なソースコードは [./src](https://github.com/mapbox/mapbox-gl-js/tree/master/src) ディレクトリに点在しています。主な登場人物は、次のとおりです。

* Mapbox
* Tile
* Bucket
* Layer
* Painter
* WebGL

``Mapbox`` は、画面に張り付いている「ビュー」です。
``Tile`` はみなさんご存知の「タイル」です。データはほとんど保持していなくて空間インデックスで使われる概念的なものです。
``Bucket`` が、``Tile`` のデータを表す存在です。[前日の記事](https://qiita.com/hfu/items/69fbe24be92654f634da)で @hfu さんが言われている ``.mvt`` や ``.pbf`` のようなベクトルタイルファイルそのものと言ってもよいです。
``Layer`` はGISでおなじみの地図のレイヤですが、GISでのレイヤほど縛りが強くないというか、地物に付いているタグのような印象を受けました（外しているかもです）。
``Painter`` は「描画者」で、実際に「WebGL」を使って``Bucket``のデータを描画するのが仕事です。
そして WebGL が描画に使用されています。

これらの仕事をシーケンス図風に乱暴に描くと次のようになります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/8227/2b056303-f802-4eee-6316-9753d5ae41dd.png)

1. ユーザーの操作などで地図の表示範囲が変更されると、その範囲に触れる ``Tile`` 群を計算して得ます。
2. 得られた ``Tile`` 群のデータをロードします。これは即ち ``.mvt`` ファイルをダウンロードして読み込み、内容を ``Bucket`` に変換することです。ここで WebGL ならではの重要なことは、図形の座標データの実体は ``Bucket`` が持つのではなく、WebGL の（**GPU上の**）「頂点バッファ」と呼ばれる領域にコピーすることです。そして ``Bucket`` は、各図形の座標群として、この「頂点バッファへのインデックス」を持ちます。 
3. ``Bucket`` のロードは非同期で行われるため、ロードが完了したときに Mapbox 側に通知を出し、再描画を促します。
4. ``Mapbox`` の描画命令が呼ばれると、ロード済みの ``Tile`` 群が対象になります。
5. ``Mapbox`` は ``Painter`` に ``Tile`` の描画を依頼します。
6. ``Painter`` は、``Layer`` から描画に必要なスタイル情報を得て、それを使用し ``Tile`` 内のすべての図形を WebGL を使って描画します。座標データはすでに GPU の頂点バッファにあります。ただしこれは画面座標ではなく、タイル内の相対座標?なので、画面座標へ変換して描画します。この変換処理も WebGL で、つまり GPU で行わせています。

このように、GISのライブラリを作ったことがある人ならば、普通のシーケンスであると思われるでしょう。
ただ 「WebGL を使う＝GPUの性能をフル活用する」ための工夫が見られます。再度抜き出すと次のようになります。

* データの実体を GPU 上に持ち、ムダなコピーを持たない
* 座標変換などの計算もなるべく GPU にやらせる

これらのノウハウは、ガチな描画系のプログラムを描く人には常識でも、私のような「にわか」には得られてよかったことです。

例えば GIS アプリケーションで必要な「投影法」や「座標系」などの変換を、GPU に行わせることはできないだろうかという興味が湧いてきます。
それがデータ変換プログラムなら、変換にかかる時間が短くなることが期待できるし、QGIS のようなデスクトップアプリならば、オンザフライでの投影法変換を行ってもサクサクと動くかも知れません。

今後もベクトルタイルならびに MapBox GL JS/Native の理解を進めて、C# に移植してみたいというのが目下の大きな関心ごとのひとつです。

## そもそも図形数が少ないのではないか説

おまけです。

ソースコードを対象改造して、描画した図形の数をカウントしてみたところ、下図の見た目で **約4500個** でした。ホントかなあ(もっと多そう)という感じがしますが、美麗なスタイルのせいで精度が高い＝図形数が多いと錯覚させるのかも知れません。

![image004.png](https://qiita-image-store.s3.amazonaws.com/0/8227/aeb62af8-6a9c-1bc6-c9c7-8a60d27a6f7b.png)
カーネルトリックと関数解析についてまとめてみた

この記事は、「[数学カフェ](https://adventar.org/calendars/2341)」アドベントカレンダー19日目の記事です。

# 記事の趣旨
蔵本モデルでよく出てきた関数解析って?
<b>「現実でどう役に立つの?」</b> これに尽きます。
※なので今回は、関数解析的な証明は行いません（できません…の方が適切ですが…）
※誤植勘違い等もあると思いますが、温かい目でお願いします。

## トピック

* 「関数解析は機械学習でどう役に立つの?」
* カーネルトリック

## 今回のアドベントカレンダーで関数解析について触れてる記事

* [06日目_作用素のスペクトル理論](https://ariririri.github.io/pdf/functionalanalysis.pdf)
* [11日目_掛け算作用素でCompact作用素・Fredholm作用素の理論を展開する](http://lyricalmaestrojp.hatenablog.com/entry/2017/12/11/230359)
* [13日目_関数解析復習会のその先「Weyl-von Neumannの定理」](http://lyricalmaestrojp.hatenablog.com/entry/2017/12/13/235019)
* [15日目_Selberg trace formula 1 - pi](http://unaoya-pi.hatenablog.com/entry/2017/12/17/Selberg_trace_formula_1_4)

# 「関数解析は機械学習でどう役に立つの?」
## 機械学習における関数解析の使いどころ

* 再生核ヒルベルト空間
* ニューラルネットの積分表現理論
* 確率的最適化
* 正則化の収束レート
* etc

まだいろいろあると思いますが、パッとトピックが浮かぶのがこのあたりです。

詳しくは、機械学習の中でも<b>統計的学習</b>などのトピックの書籍を参考にしてください。

他にもパラパラ、本や論文を読んでいる感じ、<b>強化学習</b>の本もちらっと読みましたが、だいぶ関係性が深いと思います。

# カーネルトリックについて

実際の応用例として、機械学習で用いられる手法(カーネル法)の保証に関数解析で重要なリースの表現定理が使われているということを紹介します。

## <b>[カーネル法](https://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E6%B3%95)</b>

### カーネル法（カーネルトリック）
データを高次元のヒルベルト空間（一般には無限次元）へ写像し、解析しやすいデータに変換する方法があり、ヒルベルト空間に再生核ヒルベルト空間を用いる手法のことのようです。

## [再生核ヒルベルト空間の定義](https://en.wikipedia.org/wiki/Reproducing_kernel_Hilbert_space)
入力空間を $ \mathcal{X} $ 、$\mathcal{X}$ からなるヒルベルト空間を $\mathcal{H}$ 、$\mathcal{H}$ より与えられる内積を$\langle \cdot, \cdot \rangle_{\mathcal{H}}$とする.

このとき,関数 $k:\mathcal{X}^2 \rightarrow \mathbb{R}$ が存在して,任意の $x\in\mathcal{X}$ と $f\in\mathcal{H}$ に対して

$$ k(x, \cdot) \in \mathcal{H}, \langle f, k(x, \cdot) \rangle_{\mathcal{H}} = f(x)$$

が成り立つとき, $\mathcal{H}$ を 集合 $ \mathcal{X} $ 上の再生核ヒルベルト空間(RKHS)という.

## [リースの表現定理](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AE%E8%A1%A8%E7%8F%BE%E5%AE%9A%E7%90%86)
$\mathcal{H}$ をヒルベルト空間とし、$\mathcal{H}$ より与えられる内積を$\langle \cdot, \cdot \rangle_{\mathcal{H}}$とする.
$\mathcal{H}$ で定義された有界線形半関数 $f(x)$ に対して

$$f(a) = \langle h, a \rangle_{\mathcal{H}} \quad \forall h \in \mathcal{H}$$

が成り立つような $\mathcal{H}$ の元 $a$ が一意的定まる.

### 二つの定義と定理を見比べてください
だいたい同じ形してますよね。（二つを見やすいように引用した文献から記号を変えています。）

リースの表現定理の詳しい証明は、下の資料の関数解析の書籍を参照してください。

## 主張
入力空間から特徴空間への写像を考えたとき、特徴ベクトルの内積計算が、関数に置き換えられるため、内積計算さえできれば，特徴ベクトルの具体的な形は知らなくてもよいということをカーネルトリックでは言っています。

# 今後…
リースの表現定理の具体的な証明やカーネル法の実装などそのうち…


# 参考資料
* [統計的学習理論](http://www.kspub.co.jp/book/detail/1529052.html)
* [関数解析](http://www.kyoritsu-pub.co.jp/bookdetail/9784320011069)
* [新版 応用のための関数解析](http://www.saiensu.co.jp/?page=book_details&ISBN=ISBN4-7819-1146-3)
* [カーネル法入門](http://www.ism.ac.jp/~fukumizu/OsakaU2014/OsakaU_1intro.pdf)
* [機械学習入門～ハードマージンSVM編～](https://qiita.com/pesuchin/items/c55f40b69aa1aec2bd19)
* [PRML第6章 ガウス過程による回帰 Python実装](https://qiita.com/ctgk/items/4c4607edf15072cddc46)
* [ニューラルネットワークと深層学習](https://nnadl-ja.github.io/nnadl_site_ja/index.html)
[Crystal] クラス継承とモジュールmix-inの挙動の違い

クラス（もしくは構造体，以下同様）の継承とモジュールのmix-inは，多くの面でよく似た様な挙動を示します。

例えば，あるクラスAを継承したクラスBのインスタンス`b`に対して`b.is_a?(A)`は`true`を返しますし，あるモジュールCをmix-inしたクラスDのインスタンス`d`に対して`d.is_a?(C)`もやはり`true`を返します。

```crystal
class A
end

class B < A
end

b = B.new

p b.is_a?(A)
#=> true

module C
end

class D
  include C
end

d = D.new

p d.is_a?(C)
#=> true
```

また，親クラスで定義されたメソッドをオーバーライドした際も，mix-inしたモジュールで定義されたメソッドをオーバーライドした際も，`super`でオーバーライド元のメソッドを呼び出すことができます。

```crystal
class A
  def x
    puts "A"
  end
end

class B < A
  def x
    puts "B"
    super()
  end
end

B.new.x
#=> B
#   A

module C
  def x
    puts "C"
  end
end

class D
  include C
  
  def x
    puts "D"
    super()
  end
end

D.new.x
#=> D
#   C
```

クラスもモジュールもジェネリクスの型引数として指定することができます。配列の要素の型としてクラスやモジュールを指定した場合，その配列には，要素の型として指定したクラスを継承したサブクラスや，モジュールをmix-inしたクラスのインスタンスを収めることができます。

```crystal
class A
end

class B < A
end

p Array(A).new << B.new
#=> [#<B:0x5644ae6d9fe0>]

module C
end

class D
  include C
end

p Array(C).new << D.new
#=> [#<D:0x5644ae6d9fd0>]
```

しかし，クラスの継承とモジュールのmix-inとで明確に異なる挙動を示す場合もあります。Crystalには複数の型を合成したユニオン型という考え方があります。例えば，`(String|Symbol）`は`String`型と`Symbol`型からなるユニオン型です。

ユニオン型を定義した場合，それらの型が共通の祖先を持っていると，コンパイラはそのユニオン型を共通の祖先の型としてみなします。

```crystal
class A
end

class B < A
end

class C < A
end

p (B|C)
#=> A
```

一方，共通のモジュールをmix-inした複数のクラスでユニオン型を構成した場合には，そのような集約は行われません。

```crystal
module A
end

class B
  include A
end

class C
  include A
end

p (B|C)
#=> (B|C)
```

こうした挙動の違いが問題になることはほとんどありませんが。それでもいくつかケースで直感的でない挙動に遭遇することになります。例えば，以下の例は問題なく動作します。

```crystal
class A
end

class B < A
end

class C < A 
end

class D
  @array : Array(A)
  
  def initialize(*elements)
    @array = elements.to_a
  end
end

p D.new(B.new, C.new)
#=> #<D:0x55acf7b7ff00 @array=[#<B:0x55acf7b7efe0>, #<C:0x55acf7b7efd0>]>
```

一方，同様のコードをモジュールのmix-inで実装した場合には，エラーが発生します。

```crystal
module A
end

class B
  include A
end

class C
  include A
end

class D
  @array : Array(A)
  
  def initialize(*elements)
    @array = elements.to_a
  end
end

p D.new(B.new, C.new)
#=> Error in line 20: instantiating 'D:Class#new(B, C)'
#
#   in line 16: instance variable '@array' of D must be Array(A), not Array(B | C)
```

クラスの継承[^1]では親子関係が生じるので共通の先祖を指定できるが，モジュールのmix-inでは親子関係は生じないためそれができない，といったところでしょうか。このこと自体は，クラス継承とモジュールmix-inの目的からしても納得できる動作だと思います。

ちなみに，クラス継承においてユニオン型が共通の先祖の型に置き換えられることの副作用としては，以下の様な場合に，DogとCatだけを受け入れる配列を作ることができません。

```crystal
class Animal
end

class Dog < Animal
end

class Cat < Animal
end

class Bear < Animal
end

pets = Array(Dog|Cat).new

p pets << Bear.new
#=> [#<Bear:0x557cf88c1fe0>]
```

もっとも，こうした場合はDogとCatに対してBearとは継承ツリーの別れた共通の先祖を設定すべきなんでしょうね。

[^1]: モジュールと同様にそれ自体ではインスタンス化できない抽象型（abstract classやabstract struct）を継承した場合も含む
Vue.js + TypeScript + webpack + npm v5でローカルフォルダをinstallしてハマった話

試行錯誤してみたものの根本解決に至らなかったので、ひとまず記録として書き残します。

# 何をしたのか？

- vue-cliのwebpackでローカルに汎用コンポーネント用プロジェクト作成
- Vue.js + TypeScriptで汎用コンポーネント作成
- buildの際、webpackの設定でVueを外部依存ライブラリに指定してバンドル
- 別のVueプロジェクト（以降は親プロジェクトと表記）で「npm install ローカルフォルダ」
- installしたコンポーネントをimportして使用した 

# 何が起きたか？

- npm run devするとブラウザのコンソールログにエラーが発生
- Unknown custom elementとか$attrさわんな！とかボコボコに怒られた
- ログをよくよく見ると、どうも親プロジェクトのvue.esm.jsと汎用コンポーネントプロジェクトのvue.esm.jsがどちらも実行されているらしい

# 試したこと

- Vue.js単独で汎用コンポーネント作成、親プロジェクトでの使用はエラーにならなかった
- buildした場合はエラーが発生しなかった

# 調べたこと

- npmはローカルフォルダをinstallするとシンボリックリンクを張る
 - バージョン3以前は親プロジェクトのnode_modulesにコピーしていた（普通のパッケージをinstallするのと同じ挙動）
- Vue.js + TypeScriptの場合、Vue.extendするにしろvue-class-componentを使うにしろ、import Vue from "vue"は必須
 - バンドルされたjsの中をのぞいてみると、冒頭にrequire("vue")のコードあり
 - 外部依存の設定はしていてもvue.esm.jsへの参照が残ってしまう？

# 推測したエラー発生への流れ

1. 親プロジェクトのvue.esm.jsが実行される
2. 汎用プロジェクトのバンドルされたjsを読み込む
3. バンドルされたjsの中のrequire('vue')が、親プロジェクトではなく汎用プロジェクトのnode_modulesのvue.esm.jsをrequireしてしまう
4. vue.esm.jsが多重起動してしまいエラー

# 暫定対応

- [install-local](https://www.npmjs.com/package/install-local)モジュールを使用し、親プロジェクトのnode_modulesに汎用プロジェクトを直接コピーした

# 課題

- 最低限の再現性あるプロジェクトを作成してgithubに上げたい
- webpackでバンドルしたjsを解析してみたい
- webpackの設定やプラグインで回避できそうな気もするので調べたい

もし解決策をご存知の方はコメントしていただけると大変ありがたいです。
ニューラルネットワークへの序章

今年に入って生活の中に猫が入ってきた。猫のしぐさを観察し、その姿を浮世絵の中に見つけるたびに、この小動物と人間の関係の近さを感じざるを得ない。しゃもじにかかわる話は特にない。

そこで唐突にニューラルネットの話になる。

数式とにらめっこをし sigmoid 関数を Python で実装したりすると世の中の流れが少しわかってくる。学習では TensorFlow が便利だ。Windows PC の上のバーチャルな Ubuntu (GPUなし)でもそこそこの早さだ。中身を理解するなら tyni-dnn が有益だった。自分でもレイヤーを追加できそうだ。

Polyphony でもそこを目指そう。

浮動小数点あるいは量子化という話は横に置いておいて、XOR で実装可能という二値化 NN を(C がない)目指すことにする。実装方法は PYNQ-BNN を参考にしよう。といっても、本格てな NN をつくるには少々スキルも必要そうだ。32x8 の演算でクリスマスを迎える準備をしよう。
# import を使ったパラメタ

```python:xor32_8_data.py
from polyphony.typing import List, bit32, bit8, bit6

DATA_W:List[bit32] = [ 1, 2, 3, 4, 5, 6, 7, 8 ]
DATA_th:List[bit6] = [ 1, 2, 3, 4, 5, 6, 7, 8 ]
```

Polyphony は Python の import が使える。この機能により、モデル本体とパラメタを切り離すことが出来る。

ビットのカウントにはテーブルを一部使い効率化しよう。

```python:count_table.py
m polyphony.typing import List, bit32, bit8, bit6, bit

xbit4_to_n:List[bit6] = [
    0,         # 0000
    1,         # 0001
    1,         # 0010
    2,         # 0011
    1,         # 0100
    2,         # 0101
    2,         # 0110
    3,         # 0111
    1,         # 1000
    2,         # 1001
    2,         # 1010
    3,         # 1011
    2,         # 1100
    3,         # 1101
    3,         # 1110
    4          # 1111
]
```

肝心の xor (掛け算の代用)のソースも掲げる。unroll を使っているので Polyphony の devel ブランチを必要とする。unroll を削れば 0.3.2 でもコンパイルできる。

```python:xor32x8.py
import polyphony
from polyphony import testbench
from polyphony.typing import List, bit32, bit8, bit6, bit4, bit
from polyphony import unroll

from xor32_8_data import DATA_W, DATA_th
from count_table import xbit4_to_n

def count_bit32(x:bit32)->bit6:
    mask:bit32 = 0xF
    shift_n = 0
    sum = 0
    for i in unroll(range(8)):
        sum += xbit4_to_n[((x & mask) >> shift_n)]
        mask <<= 4
        shift_n += 4

    return sum

def nn_xor32_8(x:bit32)->bit8:
    rv_xor8:bit8 = 0
    for wi in unroll(range(len(DATA_W))):
        tmp_x:bit6 = count_bit32(x ^ DATA_W[wi])

        rv_xor8 <<= 1
        rv_xor8 |= 0 if tmp_x < DATA_th[wi] else 1

    return rv_xor8

@testbench
def test():
    rv = nn_xor32_8(0x32)
    print(rv)
    #print('{:08x}'.format(rv))

test()
```

おまじないよろしくいつでも full unroll に頼ると巨大な回路を生成して使い物にならないだろう。unroll の省略可能な第２引数で unroll のまとめあげる数を指定可能だ。適切と思われる数字を入れれば回路規模と性能のバランスをとることが可能だ。適切な回数は何か？それこそ遺伝的アルゴリズムなどで自動中抽出して欲しいものだ。

いまのままでは xor の計算が出来ただけだ。まだまだニューラルネット・ワークとは言えない。しかし、学習パラメタをつくりこめば MNIST に適応できそうな感触はある。

次のステップはモデルの自動生成か？モデルの記述で比較的簡単のものにそぼれば Python コードのジェネレータはそれほど時間を掛けずにできるかもしれない。しかし、それでは長い目で見たらだめそうなこともわかっている。一度、モデルを Python のコードに落とすことで情報が欠落してしまうだろう。モデルからフローグラフを考えそれを直接 IR に変換する機構が必要だ。

それを実現する手立ては、大手企業が提供しているグラフ・コンパイラとでもいうツールに近くなるだろう。Polyphony は通常の CPU に対するコンパイラではなく RTL を生成するコンパイラだ。だから、実は内部にグラフを取り扱う機構がふんだんに入っている。工夫次第では CNN にマッチするのではないかとにらんでいる。
ProcessingとResolumeを連携させて、映像作ってみた時の話

こんにちは。
VJの話します……！！！

VJ（Visual Jockey）という言葉自体の流行りは、少し過ぎ去ってしまったような気がしますが、
近年、音楽と映像がより一体化するようになってきている中で、もはや、当たり前の技術になりつつあるといえるのではないでしょうか？

そんなVJを行うためのアプリケーションの有名どころの一つが**「Resolume」**です。

オランダ発のアプリケーションで、リアルタイムに映像を編集したり、プロジェクションマッピング等もできます。

他の有名なVJのツールはMacのみにしか対応していないものが多いですが、ResolumeはWinにも対応しているので、Winしか持ってない人もこれでVJがやれるわけです。

さて、今回は、**Processing** で作った映像をResolumeにリアルタイムで送ってみようと思います。

連動にはSyphon(Mac)、Spout(Win)を使うのですが、これはProcessing以外にもUnity、MadMapper、vvvv、openFrameworks、Processing等々、多くのアプリケーションと連携させることができます。

私は3D系のアプリをWindowsに入れており、ResolumeもWinに入っているため、Spoutを使って行きます。
Spoutは[ここ](http://spout.zeal.co/download-spout/)からDownloadできます。

まずは、Processingを起動し、Spoutのライブラリ**「Spout for Processing」**をダウンロードします。

<img width="737" alt="スクリーンショット 2017-12-18 23.54.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/217122/8bf3391d-6a77-e53f-4468-b5ef2a2ffbd0.png">

まず、spoutをimportします。

```java
import spout.*;
```

Spoutのクラス変数もつくっておきましょう。

```java
Spout spout;
```

processingの描写のための定義を行うsetupメソッド内で、spoutのインスタンスを作成し、senderを作成しておきます。

```java
void setup()
{
 size(1920, 1080, P2D);
 frameRate(30);
 fill(0, 60);
 .
 .
 省略
 .
 .
 spout = new Spout(this);
 spout.createSender("SP")
}
```

そして、描写内容を記述するdrawメソッド内で、送信用のメソッドを記載。

```java
void draw()
{
 ・
 ・
 省略
 ・
 ・
 spout.sendTexture();
}
```

Processingの方のプログラムを完成させた後は、Resolumeを起動した上でProcessingのコードを実行して下さい。

そうすると、下図のようにSourcesの中で、Spoutで受信したデータを選択できるようになります。

<img width="959" alt="Res_Pro_Spout.png" src="https://qiita-image-store.s3.amazonaws.com/0/217122/ad335e72-8ba6-51f6-db12-22e3051805a7.png">

後は、エフェクトをかけてあげるだけ。

ではでは、今日はこの辺にて
unroll と最適化

for 文の unroll 意外と使い勝手がある。マクロの代用みたいに使える。common lisp で(あるいは scheme で)マクロの強力さを実感してはいたが、unroll といった限られた形のマクロ展開（と呼んでおこう）が多くの場所で適用可能とは思っていなかった。勿論、その分、回路は大きくなるのだが。

どんな時に有益なのだろうか？

```:python
for i in unroll(range(8)):
    __h[i] = _h[i]
```

例えば、上のようなリスト(配列)のコピー。現在の Polyphony はリストの長さによってレジスタを使うか BRAM を使うかを切り分けている。マクロという観点から言うとリスト自身が FF へのマクロと言えるかもしれない。その場合、ここの FF へのアクセスを同時に行えるためunroll することで一気に(最良の場合は 1 clock で)値をコピーすることが出来る。

リストが BRAM である場合は unroll は効かないので、この場合はpipelined (パイプライン化の指示) を使うことになるだろう。

別の例を考える。リストにある数値をすべて足すような場合。Polyphony はどこまで最適化してくれるのだろう？

```python:sum0.py
from polyphony import unroll, pipelined

def sum0(data):
    sum = [0] * 16
    for i in unroll(range(8)):
        sum[i] = data[i] + data[i+8]

    for i in unroll(range(4)):
        sum[i] += sum[i+4]

    for i in unroll(range(2)):
        sum[i] += sum[i+2]

    return sum[0] + sum[1]


import polyphony
from polyphony import testbench

@testbench
def test():
    rv = sum0([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15])
    print(rv)

test()
```

まずはなんとなく、自分で最適化もどきを考えてみた。結果は 90 clock(データを準備する時間も入っている)。unroll しないバージョンとそう大差ない。ならば、全部自分で unroll でどうなるかみてみる。

```python:
def sum2(data):
    sum01 = data[0] + data[1]
    sum23 = data[2] + data[3]
    sum45 = data[4] + data[5]
    sum67 = data[6] + data[7]
    sum89 = data[8] + data[9]
    sumAB = data[10] + data[11]
    sumCD = data[12] + data[13]
    sumEF = data[14] + data[15]

    sum0123 = sum01 + sum23
    sum4567 = sum45 + sum67
    sum89AB = sum89 + sumAB
    sumCDEF = sumCD + sumEF

    sum0_7 = sum0123 + sum4567
    sum8_F = sum89AB + sumCDEF

    return sum0_7 + sum8_F
```

これだと 50 clock。しかし、こんなソースは書きたくない。書いてる途中に何度も間違えた。

```python:
def sum1(data):
    sum = 0
    for i in unroll(range(16)):
        sum += data[i]

    return sum
```

開発バージョンの polyphony では上のようなスマートな記述方法が取れる。50 clock。最適化はコンパイラに任せよう。参考までに書くと、コンパイラとしてもっと最適化できることはわかっていて、実験的にではあるが、19 clock まで縮めることができた。データを用意するのに 17 clock かかっているので、関数自体は 2 clock で結果を出すことが出来るという試算だ(もちろん全部FFに載せてという前提)。

現時点で Polyphony の最適化はコンパイラ的にかなりいい線はいっているが吐き出すコードは RTL としてはまだまだあまいところはある。しかし、今後の成長に期待が出来る結果が出始めていることも確かだ。
glsl パフォーマンスチューニング

# はじめに
glslはデバックが困難なので、まずは、ちゃんと動作するプログラムを作りましょう。
最初からパフォーマンスを考慮したトリッキーなプログラムを書くと、だいたいハマります。

# for文をなるべく使わない。
glslのfor文はループ回数を動的に変更できない＆パフォーマンス的にあまりよろしくない為、なるべくリプリケーションをうまく使いましょう。うまくいけば、for文を使うことなくやりたいことができます。但し、全く異なった発想の転換が必要になります。

# if文をなるべく使わない
glslは分岐命令に弱いのでなるべく使わないようにしましょう。stepを代替に使うと良いでしょう。

* [条件分岐のためにstep関数を使う時の考え方をまとめてみた](https://qiita.com/yuichiroharai/items/6e378cd128279ac9a2f0)

# 参考
* https://www.khronos.org/opengl/wiki/GLSL_Optimizations
* https://developer.apple.com/jp/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/BestPracticesforShaders/BestPracticesforShaders.html
GraphicSettings.TransparencySortMode.CustomAxis～Y座標が下のやつを手前に描画、上のやつを奥に描画する～

Unityの2Dスプライトの描画順序の管理は、Unity5.6でGraphicSettings.TransparencySortMode.CustomAxisが追加されたことでさらに簡単になりました。

例えば「Y座標が下のやつを手前に描画、上のやつを奥に描画する」


![sort.gif](https://qiita-image-store.s3.amazonaws.com/0/4125/603fcb9d-2745-2fed-41bf-aff6339ca048.gif)

(キャラクター画像は[臼井の会 香月清人様](https://enty.jp/usui634)のものです)

Unity 5.6以前は、Updateメソッド内でいちいちSpriteRenderごとにOrderInLayerを正しく設定する必要がありました。

Unity 5.6からはEdit > ProjectSettings > Graphics > Camera Settingsで

* Transparency Sort Modeを`CustomAxis`に
* Transparency Sort Axisを`(0.0F, 1.0F, 0.0F)`に

とするだけで、「Y座標が下のやつを手前に描画、上のやつを奥に描画する」を実現することができるようになりました。
わざわざコードを書く必要がなくなりました。

また、ProjectのGraphics Settingをいじるのが嫌な人は、次のように`Camera`コンポーネントのプロパティを設定することで実現することができます。

```csharp:
using UnityEngine;

public class OrderedCamera : MonoBehaviour
{
    void Awake()
    {
        var camera = GetComponent<Camera>();
        camera.transparencySortMode = TransparencySortMode.CustomAxis;
        camera.transparencySortAxis = new Vector3(0.0F, 1.0F, 0.0F);
    }
}
```


この設定による描画順序の制御は、OrderInLayerよりも優先順位が低いのでその点だけ注意が必要です。

参考関連

* https://docs.unity3d.com/ScriptReference/TransparencySortMode.html
* https://docs.unity3d.com/ScriptReference/TransparencySortMode.CustomAxis.html
ROSでの超基本的なプログラム実行

#はじめに
この記事では前回作成したプログラムの実行を行います。
最後に簡単な機能紹介もします。


##環境
ROS : indigo
OS  : Ubuntu14.04
言語 : python2.7
参考ページ : http://wiki.ros.org/ja/ROS/Tutorials/ExaminingPublisherSubscriber

#プログラム実行
実行方法は人によってかなり違います。
今回は公式でも紹介されている王道です。

##１つ目のコンソール
ROSを使うためにはMasterがいなければ話になりません。
roscoreを起動してください。

```
$ source ~/ros_ws/devel/setup.bash
$ roscore
```
エラーの場合は赤い文字が出るはずです。

おそらくROS_MASTER_URIの設定が間違っているのでしょう。
/etc/hostsの127.0.0.1のホスト名を覚えてください。
そして以下のコマンドによって再設定してください。

```
% export ROS_MASTER_URI=http://ホスト名:11311
```

##２つ目のコンソール
talker.pyを実行していきましょう。
まずはcatkin_makeの後にsetup.bashを通します。

```
$ cd ~/ros_ws
$ catkin_make
$ source /devel/setup.bash
$ rosrun ros_start talker.py
```
以下のような表示が出るはずです。

```
[INFO] [WallTime: 1314931831.774057] hello world 1314931831.77
[INFO] [WallTime: 1314931832.775497] hello world 1314931832.77
[INFO] [WallTime: 1314931833.778937] hello world 1314931833.78
[INFO] [WallTime: 1314931834.782059] hello world 1314931834.78
[INFO] [WallTime: 1314931835.784853] hello world 1314931835.78
[INFO] [WallTime: 1314931836.788106] hello world 1314931836.79
```

##３つ目のコンソール
最後にlistener.pyの実行

```
$ cd ~/ros_ws
$ rosrun ros_start listener.py
```
以下のような表示が出るはずです。

```
[ INFO] 1251943144.400553000: Received [Hello there! This is message [1]]
[ INFO] 1251943144.600712000: Received [Hello there! This is message [2]]
[ INFO] 1251943144.801003000: Received [Hello there! This is message [3]]
[ INFO] 1251943145.001407000: Received [Hello there! This is message [4]]
[ INFO] 1251943145.201229000: Received [Hello there! This is message [5]]
[ INFO] 1251943145.401417000: Received [Hello there! This is message [6]]
```
これがでればPublishされSubscribeまでできているということです。
ROSのプログラムを実行する一連の流れです。

#覚えてほしい便利機能
実行した後にどのようにつながっているのか確認するコマンドがあります。

```
$ rqt_grath
```
これを行えばノード同士がどのように接続されているのかを可視化して理解することが出来るようになります。

複雑な開発を行ったときに何故かSubscribeしてくれない...
そんな時に私は研究の際非常に重宝しました。

ちなみに私が１台のサーバに対し５台のクライアントすべてにROSのPublisherとSubscriberの機能を持たせた時の画像がこちらです。
最大で１０台まで接続した時には非常に助かりました。

![rosgraph5.png](https://qiita-image-store.s3.amazonaws.com/0/221456/8ffe8edc-62e5-0691-8013-41a90f2c6f96.png)

こんなものもROSのプログラムを理解すれば簡単に作れます。

#おわりに
これであなたもROSを使い放題です。
自分の目的にあったROSの使い方をしましょう。
目的に合わないのにも関わらずROSを使うのは無駄です。

次回はメッセージを利用したROS通信の解説を行う予定です。
gormのscopesが便利

gormのScopesが便利だったので記事にしました

`UserFind()`と`ProfileFind()`で`Where`で同じようにID検索する処理があるとする

```go
package main

import (
	"github.com/jinzhu/gorm"
	_ "github.com/jinzhu/gorm/dialects/postgres"
	"github.com/k0kubun/pp"
)

type User struct {
	gorm.Model
	Profile   Profile
	ProfileID int
	Email     string
}

type Profile struct {
	gorm.Model
	Name string
	Age  int
}

func main() {
	db, err := gorm.Open("postgres", "url")
	if err != nil {
		panic(err)
	}

	db.AutoMigrate(
		&User{},
		&Profile{},
	)

	user := UserFind(db, 1)
	pp.Println(user)
	profile := ProfileFind(db, 1)
	pp.Println(profile)
}

func UserFind(db *gorm.DB, id int) User {
	var user User
	db.Where("id = ?", id).Find(&user)
	return user
}

func ProfileFind(db *gorm.DB, id int) Profile {
	var profile Profile
	db.Where("id = ?", id).Find(&profile)
	return profile
}
```

これを`Scopes`を使うとIDで検索する共通のメソッドが作れる

```go
func UserFind(db *gorm.DB, id int) User {
	var user User
	db.Scopes(SearchByID(id)).Find(&user)
	return user
}

func ProfileFind(db *gorm.DB, id int) Profile {
	var profile Profile
	db.Scopes(SearchByID(id)).Find(&profile)
	return profile
}

func SearchByID(id int) func(db *gorm.DB) *gorm.DB {
	return func(db *gorm.DB) *gorm.DB {
		return db.Where("id = ?", id)
	}
}
```

## おわりに
使いようによっては色々な使い方ができそうだなって思った。
便利！使っていこう！
【小ネタ】pythonで同じkeyを持つインスタンスは一つにしたい

木系のアルゴリズムをpythonで実装しようとしていたら時間が無くなってしまったので小ネタ。

木系のアルゴリズムで、Nodeを共有したい場合ってありますよね。
下の図のオレンジ色のノードみたいに。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/112276/d04da15e-4ae6-4a13-7229-aefe34eb8d36.png)

Nodeを拡張する場合に、拡張したいNodeと同じNodeが既に存在しているかどうかを調べるのも結構面倒なので、そこをうまくやれるといいですよね。

Nodeにkeyを指定しておいて、同じkeyがあったら既存のインスタンスを返す、といった実装をしようと思ったら、metaclassを使えばできる、という小ネタです。

```python3
# 同じkeyをもつノードは一つにしたい場合
class NodeType(type):
    _instances = {}
     
    def __call__(cls, *args, key, **kwargs):
        # stateが同じものがあれば、すでに作られたインスタンスを返し、なければ新規作成
        if key not in cls._instances:
            instance = super(NodeType, cls).__call__(key=key, *args, **kwargs)
            cls._instances[key] = instance
         
        return cls._instances[key]

class Node(metaclass=NodeType):
    def __init__(self, key, name):
        self.key = key
        self.name = name
        self.id = id(self)
    
    def __repr__(self):
        return 'id: {}, name {}, key: {}'.format(self.id, self.name, self.key)

node1 = Node(key=1, name='1'); print(node1)
node2 = Node(key=2, name='2'); print(node2)
node1_2 = Node(key=1, name='1_2'); print(node1_2)
```

上記のようにtypeを継承したクラスを作り、metaclassを使うことで、実現可能です。

```
id: 1850359362728, name 1, key: 1
id: 1850359363008, name 2, key: 2
id: 1850359362728, name 1, key: 1
```

作られたインスタンスは、keyによって管理されています。

```python3
NodeType._instances
```

```
{1: id: 1850359362728, name 1, key: 1, 2: id: 1850359363008, name 2, key: 2}
```

時間がなさ過ぎたので以上。。。

この方法だと、NodeType._instancesにも参照が生じてしまうので、
今後は、弱参照をうまくつかって、ガベージコレクションがうまく働く方法を検討したいです。

(2017.12.19追記)
上記の方法だと、

```python3
del node2
node2_2 = Node(key=2, name='2_2'); print(node2_2)
```
このように一度消して再作成したつもりでも、

```
id: 1850359363008, name 2, key: 2
```
となり、nameやidの情報を見てわかる通り、最初に作成したインスタンスが生き続けています。
NodeType._instances で参照が残っているので、当たり前と言えば当たり前かもしれませんが。


そこで、弱参照を使ってこの問題に対応することを考えます。
pythonでは、weakrefライブラリを使うことで弱参照を扱えます。

下記にコードは書きますが、最初の4行しか変えていません。

```python3
from weakref import WeakValueDictionary

# 同じkeyをもつノードは一つにしたい場合
class NodeType(type):
    _instances = WeakValueDictionary()
     
    def __call__(cls, *args, key, **kwargs):
        # stateが同じものがあれば、すでに作られたインスタンスを返し、なければ新規作成
        if key not in cls._instances:
            instance = super(NodeType, cls).__call__(key=key, *args, **kwargs)
            cls._instances[key] = instance
         
        return cls._instances[key]

class Node(metaclass=NodeType):
    def __init__(self, key, name):
        self.key = key
        self.name = name
        self.id = id(self)
    
    def __repr__(self):
        return 'id: {}, name {}, key: {}'.format(self.id, self.name, self.key)

node1 = Node(key=1, name='1'); print(node1)
node2 = Node(key=2, name='2'); print(node2)
node1_2 = Node(key=1, name='1_2'); print(node1_2)
```

NoteTypeクラスの中で、_instancesを辞書型の代わりに
WeakValueDictionaryを使っています。

```
id: 1945971777040, name 1, key: 1
id: 1945971777432, name 2, key: 2
id: 1945971777040, name 1, key: 1
```
今度は、一度消して再作成してみると、

```python3
del node2
node2_2 = Node(key=2, name='2_2'); print(node2_2)
```

```
id: 1945971719192, name 2_2, key: 2
```
となり、インスタンスが新しく作られていることが確認できます。
Blueprint

仕事で使っている[blueprint](http://blueprintjs.com)というUIツールキットが良い感じなのでアドベントカレンダーに合わせて紹介記事を書いてみました。

## 特徴

- スタイリッシュなreactコンポーネント+cssを提供している
    - reactコンポーネントのインターフェースは特定のデータ構造を想定していない
    - なので、Immutable.jsでも普通のjsオブジェクトでも、ClojureScriptのオブジェクトでも動かすことが出来る
- デスクトップアプリを想定している
    - not mobile first
- TypeScriptで書かれており、型情報を利用することができる
- ドキュメントが充実してる

## 入っている物を一部紹介

### 配色

![image.png](https://qiita-image-store.s3.amazonaws.com/0/124830/90de88d8-f6de-8ff1-3cd0-88b5a65375ee.png)

### アイコン

![image.png](https://qiita-image-store.s3.amazonaws.com/0/124830/9290804f-7812-3837-12d8-328cd0c108b1.png)

### デートピッカー

![image.png](https://qiita-image-store.s3.amazonaws.com/0/124830/efc6b97e-9f39-ae91-f76d-98b731df27e1.png)

### デートレンジピッカー

![image.png](https://qiita-image-store.s3.amazonaws.com/0/124830/5a1dbd78-5c1a-0938-381c-4747f82a2e46.png)

### table

![image.png](https://qiita-image-store.s3.amazonaws.com/0/124830/aa7d143b-c11c-6fc2-4a38-11e2e1f613d6.png)

- エクセルに非常に近い操作性が実現できるのが魅力的

## インストール方法

- npmでインストール & ビルド
- cdn

の2通りがある。

## まとめ

- 使っていて生産性高くクオリティの高いUIを書けているように感じている
一部しか機能を紹介していないので、興味が湧いたようであれば公式ドキュメントが良い。
コード例と共に記載されていて非常にわかりやすくなっている。
windowsのhyper-vでsystemd-nspawn

[systemd-nspawn Advent Calendar 2017](https://qiita.com/advent-calendar/2017/systemd-nspawn) 21日目の記事です。

注意点としては

セキュアブートを無効化しないとLinux入れられなかった

![sboot.png](https://qiita-image-store.s3.amazonaws.com/0/106549/399a046e-f19e-7ced-2dc7-d49e59929722.png)

あとブリッジインターフェイスを外に出す場合は
MacアドレススプーフィングをONにしないと駄目だった

![macsp.png](https://qiita-image-store.s3.amazonaws.com/0/106549/b315f46d-267f-1292-fd26-d7a87dd11840.png)

それ以外は普通に使えた
全然systemd-nspawn関係ない記事になっちゃったな。。。。
Google Homeで家電制御するためのお手軽マイコンハック

この記事は
[IoTLT Advent Calendar 2017](https://qiita.com/advent-calendar/2017/iotlt_neo) 19日目の記事です。
この前の記事は@masashiokawaさんの[エンタープライズIoT事例](https://qiita.com/masashiokawa/items/ead72383df0caf8a67d1)です。

最近はGoogle Homeにハマっております、nokkiiです。
業務ではIoTの研究、新規事業開発と大規模サーバミドルウェア開発、採用活動などをやっています。最近社内でハードウェア開発を始めたのでmbedを始めとしたARM環境とドライバ、量産経験者を募集していたりもします。ご興味ある方はお声掛けください。
今回は[Google Homeで作ったスマートホームを自慢したい男たち](https://qiita.com/nokkii/items/4c83889fef4ad7a22b3b)のハードウェア詳解と言う形でやりたいと思います。

# 最近APIを生やした家電
### トースター
昔作った「[好きな焼き色を選んで焼けるトースター](https://www.youtube.com/watch?v=ZBsoqYi4cpA)」をGoogleHomeから制御できるようにしました
[![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/iX2Fg2jd_ZY/0.jpg)](http://www.youtube.com/watch?v=iX2Fg2jd_ZY)
動画では「パンを(時間)にトーストして」と命令を送ると炊飯器の予約のように時間を逆算して、タイマーを掛ける動作をしています。GoogleHomeに「朝ごはんはトーストにして」とお願いすると翌朝7：30にパンを焼いてくれます。課題としてはトースターにパンを刺しておかないといけないので、衛生面に不安がありますが2日くらいなら大丈夫でしょう(多分)。
### 電気暖炉
[![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/_YBL381joXg/0.jpg)](http://www.youtube.com/watch?v=_YBL381joXg)
Dimplexの電気暖炉にESP32でHTTP APIを生やして制御できるようにしました。このシリーズは炎のゆらめきを水蒸気で表現していて、加湿機能だけ使うこともできます。芯まで冷える季節になったら直接当たれますが、消費電力の割に部屋は温まらないのでいまは加湿器モードにしています。

# トースターのハードウェア解説
トースターはTOSHIBA FlashAirで操作しています。

<img width="400" src="https://qiita-image-store.s3.amazonaws.com/0/40630/d41e538d-610d-6582-34f6-839236584563.png">
元々のトースターの回路はすごくピタゴラ的に作られています。レバーを下ろすとヒーターが入り、ヒーターの電圧降下とダイオードによってタイマICにDC9Vが入ります。タイマICはタイマーが切れるまでの間電磁石を動かし、自己保持回路の役割をします。なかなかおもしろい仕組みではないでしょうか。

<img width="400" src="https://qiita-image-store.s3.amazonaws.com/0/40630/242ae8ac-578e-c027-0fab-afc6f1cab02a.png">
これをFlashAirで制御できるように改造します。楽にするためUSB電源を分解して入れ、3.3Vの三端子レギュレータでFlashAirの電源を作ってやります。FlashAirでリレーをドライブするためにトランジスタを入れ、電磁石をON/OFFします。
回路図には書き忘れてしまいましたが、ヒーターもFlashAirからON/OFFできるようにしており、レバーを下げた時点で電磁石はb接点, ヒーターはa接点で接続されているので初期化処理なしに「レバーを下げているけど、ヒーターは入っていないステート」を実現しています。あとはFlashAirの標準のHTTP APIでON/OFFすることができるのでFlashAir側のAPIはノンプログラミングで実現することができます。

## 具体的なAPIなど、
`/command.cgi?op=190&CTRL=0x03&DATA=0x1c` `電磁石もOFF`
`/command.cgi?op=190&CTRL=0x03&DATA=0x1e` `ヒーターもON`
`/command.cgi?op=190&CTRL=0x03&DATA=0x1f` `電磁石だけON`
configにデジタルIO出力を設定した後、このようにCTRLにWriteするIOピン番号の16進値、DATAにOFFにするマスク値を書くと標準でデジタルIOが動作する。このようにFlashAirを使うと、家電のAPI化がわりと簡単に実現できます。

## プログラム
使いようはないと思いますが、焼き色を選んで焼けるトースターのコードは公開されています。サーバが必要だったのをFlashAirのみでの制御に移行しているところなので、とっ散らかっていますが...。
https://github.com/nokkii/good_tooster


# 電気暖炉のハードウェア解説
![image.png](https://qiita-image-store.s3.amazonaws.com/0/40630/dfe3a9c1-c970-1ebc-d25a-f76fb01fde38.png)
電気暖炉にはステートを進めるボタンと電源を切るボタンがあるのでそこのON/OFFを制御します。リレーの制御回路的にはFlashAirと全く変わらないので、間違えてFlashAirと書いてしまいました。ESP32はノンプログラミングとは行かないまでもArduino気分でプログラミングでき、Webサーバのサンプルプログラムも公開されているので5分位のプログラミングで実装することができました。

## プログラム
ESP32のサンプルプログラムと殆ど変わりませんが、これも公開しています。改造して遊んでみてください。
https://gist.github.com/nokkii/72c173793d763d66e988c20b230447a6

## API

/heat 本体のステートを進めるボタン(加湿→弱→強)
/off 本体のOFFボタン押下
展望として、このマイコン自体にステートを記憶させて双方向に状態を取得できるようにするとグローバルの受け皿になっているエンドポイントのRaspberryPiが持っている暖炉のステートとずれにくくて良さそうです。

明日は@cw-hiramaさんです。よろしくお願いします。
フットサルの名将ヘスス・カンデラス氏に学ぶリーダーシップ

この記事は[iRidge Advent Calendar 2017](https://qiita.com/advent-calendar/2017/iridge)の18日目のエントリーです。

ひょんなことからフットサルの名将であるヘスス カンデラス氏の話を聞く機会に恵まれました。
スポーツチームの話ではあるのですが、マネジメントやリーダーシップはシステム開発にも通じるところが多分にあったので備忘録もかねて記事にします。

## 講演のテーマ
マネジメントやリーダーシップ、勝ち続ける組織とはどのようなものなのか、
というテーマでの講演でした。
様々なチームで監督として成功を勝ち取ってきたカンデラス氏がどのように物事を捉えているのかを垣間見ることができました。

以下、印象に残った話を挙げていきます。

## 測定せよ
マネジメント、評価、育成などなど様々な話を聞いたのですが、どの話にも一貫して「測定」という要素が入ってました。
何をするにせよ測定をすることが大前提とのことです。
スポーツなので結果（得点など）や身体的な数値（最近は走行距離や心拍数が計測できるシステムがあります）はもちろんですが、リーダーシップに関しても評価のためには計測するそうです。
どのような評価軸なのか聞きそびれてしまいました。残念。


## マネージャーの役割
マネージャーの役割として以下の３つを挙げていました。

- 専門家であること
- チームを育成する人であること
- メッセージを発信する人であること

専門家であること、というのはシステム開発の現場でも同じでしょう。
（たまにプログラムやネットワークのこと全然わからないマネージャーもいますが）

## 評価
カンデラス氏は評価を**競争力**と**リーダーシップ**の掛け合わせでするそうです。
競争力とは個人のスキルと近い考え方です。ただしそれが組織の競争力となっていることが前提です。
それぞれを３段階で評価し、マネージャーは以下の図の黄色の場所にいることが必要とのこと。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/224030/feb1317a-6440-bd0f-a1f6-14743431609c.png)


## フレームワーク
講演の随所に思考フレームワークが登場していました。
SWOT,SMARTを使って目標設定と評価をしているとのこと。

フレームワークは知識として知ってるけど、現場で使うべき時に使っていないことが多いので、ハッとさせられました。

## リーダーシップ
**「リーダーシップとは組織に影響を与えること」**と何度もおっしゃってました。
個人の性格や能力によって体現できるリーダーシップは異なるとも。
フットサルやサッカーで言えば運動量や頑張りで味方を鼓舞したり、闘志を全面に出すこと。ムードを盛り上げことなど様々です。
良い行動を起こし、組織に良い影響を与えることこそリーダーシップである、と。

## 勝ち続ける組織とは
- 小さなカイゼンを重ねること
- 常に変化をすること

勝利・成功を得るためには同じことをやっていてはダメで、常にカイゼンを繰り返すことが大事と何度も何度もおっしゃってました。

## カイゼン
とにかくカイゼンを重ねることだ大事、と何度も強調していたカンデラス氏ですが、TPS（トヨタ生産方式）に影響を受けたとのことです。

私が愛してやまないアジャイル開発もTPSを源流としており、様々な業界が繋がっていることを再認識することができました。

素晴らしい講演とその機会を与えてくれたカンデラス氏と[株式会社クリアソン](https://criacao.co.jp/)に感謝です。
Gracias Candelas !!
CAN通信用ICにチャレンジ（とりあえずハード側まで 2017-12-18）

**この記事は[高知工科大 Advent Calendar 2017](https://adventar.org/calendars/2305)の18日目の記事です。**

## はじめに
takamasavvv です。
突然ですが、一身上の都合でCAN通信を始めることになりました。
まだ完全には実装できていないので、今回はハードウェアだけやったよ日記を書きます。

## CANって？
CANのプロトコルについては[ここ](http://monoist.atmarkit.co.jp/mn/series/118/) を参照しています。
CANは、車載機器等に使われる、信頼性が大変高いプロトコルです。
データの信頼性を挙げるための様々な工夫がされており、データが落ちたことの検知は確実にできるようです。
細かい説明は上のリンクにあるので割愛します。

## どうやるのか？
今回はCANコントローラーのMCP2515とCANトランシーバーのMCP2561を使用しました。
この2つでマイコンからSPIでCANを制御できるようになります。
構成としては以下のようになります。
![sys.PNG](https://qiita-image-store.s3.amazonaws.com/0/106278/ba495068-6926-5c14-5661-de0e7ed8f243.png)

で、実際にブレッドボードに組んだのが以下のようになります。
![bb_ana.JPG](https://qiita-image-store.s3.amazonaws.com/0/106278/a6c92766-146e-b0ea-88a8-6e685cb6b3a2.jpeg)

このボードでとりあえずの動作試験をやります。
使ったマイコンはPSoC5LPのCY5888LTI-LP097です。
動作確認としては、MCP2515の設定用レジスタの一つであるCANCTRLというレジスタを読み、初期値になっているかどうかを確認します。

[動作確認用プログラム（クソ）](https://github.com/takamasavvv/WS_PriojectSettler/tree/master/CAN_MCP2515_Example.cydsn)

信号の確認のためにシグナルアナライザー（ブレッドボード写真左）を使っています。
以下がシグナルアナライザーの信号です。
![wav.PNG](https://qiita-image-store.s3.amazonaws.com/0/106278/00e10bc4-baca-47a4-cf8d-c411cf9756bf.png)

上がMOSI側、下がMISO側です。
MOSIではマイコンがしっかりMCP2515にレジスタの読み込み命令を出していますね。それに対してMISOはレジスタ内部の値である135(dec)を返しています。
動作モードビットはコンフィグレーションモードに設定しているので、135(dec)=10000111(bin)が帰ってきたのは正常といえます。

**ということで、ハードウェアは完成したっぽいです。**

完成ついでに、基板を書きました。
![print.JPG](https://qiita-image-store.s3.amazonaws.com/0/106278/226d0c56-d06a-1ae7-f9d5-cc8abca96ee2.jpeg)
（写真は後輩がはんだ付けしてくれたもの）
なかなか小さくまとめられました。やったね！


## 課題
 - どうやらクロック周りの部品設定が悪いのか、通信速度が遅い。要改善
 - 通信ソフトウェアをちゃんと実装するのが本番だよねー
 - ここまでするならPSoC搭載のCANモジュールでもいいのでは？

## 最後に
こんな感じで中途半端な状態で終わるのもなんなので、開発が進み次第、ここに追記していきます。
なので完成はもう少し待ってください。
AlexaSkillsKitの日本語ドキュメントを一通り読んで浅く理解したこと

最終的に対話だけで完結する何かしらのスキルを作るのが目的。
軽く噛み砕いて自分なりに章ごとにまとめてみた。スマートホーム端末系はやらない予定なので細かいところまでは書かない。
https://developer.amazon.com/ja/docs/ask-overviews/build-skills-with-the-alexa-skills-kit.html

## Alexa Skills Kitによるスキルの作成
* スキルの機能と種類を決める。AWSLambdaや任意のクラウドに建てたWebサービスと連携出来る。ただスマートホームスキルを使う場合はLambdaだけっぽい。

## Alexaのスキルで開発できる種類
* カスタムスキル
  * 細かいところまで自分で作成する種類らしい。対話だけで処理するスキルはほぼこれが該当すると思われる。
* スマートホームスキル
  * 使う人に特定のフレーズを覚えさせる事なく、スマートホーム端末を制御する端末を作るならこれ使ってねとあった。自分で特別な言葉を言わせずに「Alexa リビングの照明を付けて」で対応させられるって事のようだ。温度の上下、照明の上げ下げや点灯といったイベントは勝手に判定してくれて、その後の処理から自分で作成する。
* フラッシュブリーフィングスキル
  * フラッシュニュースに自分のスキル追加したいならこいつを使う。「Alexa 今日のニュースは？」で聞けるのは現状ニュースサイトのヘッドラインみたいなフラッシュニュースだけ。処理を書くというより、ニュース用のコンテンツを用意するだけっぽい。

## ユーザーによるスキルとの対話
> Alexaのコンテキストの対話モデルは、従来のアプリでのグラフィカルユーザーインターフェースに似ています。ボタンをクリックしてダイアログボックスからオプションを選択する代わりに、ユーザーは自分のリクエストや、質問に対する答えを音声で伝えます。

* ユーザの声（ウェイクワード） -> Alexa端末 -> Alexaサービス -> Alexa端末 -> ユーザ
  * リクエストとレスポンスを全て音声で行うって考えるとしっくり来る。
* ウェイクワードの後、カスタムスキルなら独自の対話モデルへ、スマートホームスキル等はAlexaが標準で用意している対話モデルへ移行する。例えば「Alexa おれおれてんきよほうで明日の天気教えて」の「おれおれてんきよほう」の部分がカスタムスキルで設定されたフレーズに該当するならその後独自の対話モデルへって事か。

## スキル開発の要件
* 共通で開発者アカウント作る。
* カスタムスキル開発の要件 
  * インターネットアクセス可能なエンドポイント用意してね。Lambda使うならAWSのアカウントも作ってね。
  * Alexaスキルのアイコン以外で、任意の音声ファイル等が必要ならS3使ってね。そうじゃないならホストしなくていい。
  * テスト用にAlexaが使える端末があればなお良し。一応ブラウザ上でテスト出来るけど、文字でリクエストするみたいなので実際に音声でテストが出来ないのと、位置情報とか一部の機能が制限されるっぽい。
* スマートホームスキルの開発の要件
  * 制御する予定のクラウド対応デバイス
  * AWSLambdaを使うためのAWSアカウント
* フラッシュブリーフィングスキルの開発の要件
  * RSSかJSONで継続的に更新されているコンテンツフィード。自分のメディア持ってたら多分一番楽に作れるんじゃないだろうか。個人のブログでもいけそうな感じですね。

## 終わりに
とりあえずどんなスキルが作れて、その為に何が必要か分かった気がする。次はカスタムスキルの具体的な詳細を読んでまとめる。