OmniAICreator/Qiita-1.07M huggingface dataset:
bibファイルから簡単な年表を可視化

## 動機

過去にイントロ、関連研究を書くのに苦労した時の話です。

サーベイ中に書いたメモはどこへ、なんてことにならないように、`bib`とメモを一緒に管理しておいて、それらをまとめて年表にしてくれるのが欲しかったです。

とは言ったものの
以前、 [<img height="48px" src="https://avatars3.githubusercontent.com/u/11944219" ><img height="48px" src="https://qiita-image-store.s3.amazonaws.com/0/32636/9de3a16b-17d8-82de-3686-e3f74ce151e7.png" >](https://github.com/paper-yggdrasil-project/paper-yggdrasil-project.github.io/wiki/Share-Yggdrasil,-Create-World) なるものを作ろうとしましたが、構想が大きすぎ開発が全く進んでおりません。

そんな中、今パッと作れて使えるものを考えた時に、とりあえず、`bib`とメモをセットで年表にしよう！と思ったのでした。

そんなの作ってる時間あったらもう一回関連研究の論文読めって今は思います。

## UI

時間軸のUIで使えそうなもの。

* [Ben Bederson's Publication](http://www.cs.umd.edu/~bederson/papers/index.html)
* [Vertical Timeline](https://codyhouse.co/gem/vertical-timeline/)
* [TimelineJS3](https://github.com/NUKnightLab/TimelineJS3)

### Ben Bederson's Publication

![https://gyazo.com/9beb4307ad490c6c084550e1b34da403](https://i.gyazo.com/9beb4307ad490c6c084550e1b34da403.gif)

メモとの連携という要素がなければ、めちゃくちゃ素晴らしいのですが、諦めました。

### Vertical Timeline

![https://gyazo.com/4e4e6e875c70e6e0e41309164ed35cd4](https://i.gyazo.com/4e4e6e875c70e6e0e41309164ed35cd4.gif)

見た目がとてもかっこよくレスポンシブ対応で素晴らしいのですが
同じ年のものを並列に並べられなさそうなので
別の機会にとっておくことにしました。

### TimelineJS3

![https://gyazo.com/d6dedcb3f510946a290de247c59e2afb](https://i.gyazo.com/d6dedcb3f510946a290de247c59e2afb.gif)

結局、[TimelineJS3](https://github.com/NUKnightLab/TimelineJS3)を使ってみることにしました。

## セットアップ＆起動

特定のフォルダに `bib` ファイルを置いて、あるコマンドを打つと自動で `bib` たちを解析してくれて年表を表示してくれます。

![https://gyazo.com/208d597acc7587af181a00ba10b2ced6](https://i.gyazo.com/208d597acc7587af181a00ba10b2ced6.gif)

```
cp <your bib file> app/bib/
gulp timeline:generate
gulp serve
```

[こんな感じで](http://paper-yggdrasil-project.github.io/bibtimeline/)動きます。

## 実装
https://github.com/paper-yggdrasil-project/bibtimeline/

* [bibtexParseJs](https://github.com/ORCID/bibtexParseJs)により、`bib`を`json`に変換しています。
* `markdown`は[gulp-markdown](https://github.com/sindresorhus/gulp-markdown)により`html`にした後、`iframe` で読み込んでいるだけなので、[ここ](https://github.com/NUKnightLab/TimelineJS3/tree/master/source/js/media/types)を参考にちゃんと対応したいと思いつつ。。。
* `timeline.json` を生成するためのgulpのプラグインも自作しました。




## 参考

* [かっこいい年表が作れるウェブサービスまとめ | オタクの育児](http://otakunoikuji.com/timeline/)
* [gulp/README.md at master · gulpjs/gulp](https://github.com/gulpjs/gulp/blob/master/docs/writing-a-plugin/README.md)
* [Node.js - gulpプラグインの基本構造（プラグイン開発者向け） - Qiita](http://qiita.com/morou/items/1297d5dd379ef013d46c)
* [JavaScript - gulpの「Writing a Plugin - Guidline」日本語版 - Qiita](http://qiita.com/morou/items/abc05013053f6110bcb1)
* [gulpプラグインの作り方 | js | Horic Design](http://horicdesign.com/js/entry-146.html)
* [gulpで消耗したのでgulp(Stream)について調べてみる。](https://gist.github.com/podhmo/e6d8b1dbba26514817f8)
Schooの非同期パイプライン処理について

# はじめに

本投稿は、Schooの2016年末特別企画「Schoo advent calendar 2016」の5日目の記事になります。
エンジニア -> 法人営業 -> 新規事業立ち上げ <- いまここ
ということでエンジニアを離れてすでに半年以上が経過しておりますが、1年以上前のことを思い出せる範囲で書きたいと思います。
内容は今更感が否めないですが、2日目の[Schooの録画配信の裏側](http://qiita.com/hiro32itou/items/67f4b27bc0ec1f9415b8)でも登場してきた非同期パイプライン処理についてです。

# Schooの非同期パイプライン処理について
Schooの非同期パイプライン処理はAmazon Simple Queue Service (SQS)を用いて実装されております。
下図、例としてメール送信処理の流れです。
![スクリーンショット 2016-12-02 0.40.54.png](https://qiita-image-store.s3.amazonaws.com/0/151947/a6ca7436-9e10-f181-65eb-296c121b0bfd.png)

# 設計時のポイント

## Workerの並列処理のプロセス管理（ディスパッチャ）

- ディスパッチャはSQSからジョブを取ってきて各ワーカープロセスに割り振ります。
- Preforkモデルでマルチプロセス処理にしました。
    - シングルプロセスで動作させた場合、重いジョブに引きづられて他のジョブの処理が遅延してしまいます。

| signal | signal number | 処理 | 内容 |
|:-----------|------------:|:------------:|:-------------:|
| SIGINT       |        2 |     forced shutdown     | 子プロセスの処理の終了を待たずに子プロセスを強制的に終了し、親プロセスも終了する |
| SIGQUIT     |      3 |    graceful shutdown    | 子プロセスの処理が完了し次第終了する |
| SIGTERM       |        15 |     forced shutdown     | 子プロセスの処理の終了を待たずに子プロセスを強制的に終了し、新しい子プロセスをフォークして再開する |

## ショートポーリング or ロングポーリング

- SQSではメッセージを取得する際にWaitTimeSecondsでリクエストタイムアウト時間を設定できます。
-  ロングポーリング
    - SQSへのリクエストのタイムアウト時間を長くして、リクエスト回数を減らします。
    - リクエスト中はそのプロセスがロックされます。
        - キューの種類ごとにプロセスが分かれている場合などは有効です。
- ショートポーリング
    - SQSへのリクエストを頻繁にして、キューが作成されていないかチェックします。
    - リクエスト時間が短い分ロックされません。
        - 異なる種類のキューを横断的に一つのワーカープロセスが処理する場合は有効です。


## スケールアウト
- キューイングのスケールアウトはSQSに任せるので、ポイントはワーカー側のスケールアウトです。
    - SQSはほぼ無制限のスループットが提供されます。
- キューの種類とワーカーは1対1にしました。
    - このワーカーが担当するキューはこの種類に限りますと定めた。
    - 複数のキーを1つのワーカーが担当してしまうと、各キーにストックされているジョブの処理の重さが異るため、スケールアウトしにくいです。
    - ワーカーを分けておけば、このキーのジョブは重いのでこのキーを処理するワーカーは別サーバにして、複数台並列に並べる等が容易になります。
    - また、ソースコードの管理が分割できます。
        - すべてのソースコードが無くても、そのジョブに必要なソースコードさえあれば処理できます。

## 可視性タイムアウト
- SQSは可視性タイムアウトというものを設定できます。
- 可視性タイムアウトとは簡単に言うと、キューのメッセージを取り出してもそのメッセージはキューから削除されず、一定秒数取得できなくするという機能です。
- なぜこのような機能が必要かというと、キューからメッセージを受信する前に接続が切断されたり、コンポーネントで障害が発生してメッセージを正しく処理できない可能性があり、その際にリトライできるようにするためです。
- なので、コンポーネントがメッセージを正常に処理できた場合にのみ、そのメッセージを明示的に削除するように実装します。

## Dead Letter Queues
- [参考](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSDeadLetterQueue.html)
- 何回リトライして失敗したら、そのジョブをエラーとしてキューに入れますよ、という設定ができます。
    - キューイングされたジョブの中で、正しいフォーマットではないジョブなどは、何回リトライしてもエラーが発生して処理できません。

## ディスパッチャのルール定義
- キューイングするメッセージに保存する情報としては、キューの名前とワーカーに渡す引数のみに定めました。
    - ディスパッチャはキューから取得したキュー名を基にワーカーを起動し、引数を渡します。
- キューに対してワーカーが一意に定まるようにしました。
    - あるキューからジョブを取り出したら起動するワーカーが定まるようにしました。

## ワーカーごとの設定
- ワーカーの種類ごとに設定を変更できるようにしました。
    - ディスパッチャがフォークする子プロセス数
    - キューが空の場合の待機秒数
    - キューから1度に取得するメッセージ件数
    - SQSへのリクエストのタイムアウト秒数
    - 可視性タイムアウトの秒数

# おわりに

頑張って思い出しながら書いてみました。
次書くことがあれば、もっと自分ならではのエンジニア以外の視点も含めた内容にしようと思います。
Schooでは以下の職種を募集しておりますので、少しで興味のある方は遊びに来てください！
* リードエンジニア https://www.wantedly.com/projects/47833
* エンジニア（サーバサイド） https://www.wantedly.com/projects/49282
* エンジニア（サービス開発） https://www.wantedly.com/projects/67488
* テクニカルディレクター https://www.wantedly.com/projects/72407
* デザイナー https://www.wantedly.com/projects/70697
Vim 8.0 Advent Calendar 5 日目 タイマー

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

Vim 8.0 は新しくタイマー機能が追加されました。これにより、指定時間後に関数を呼び出すことができます。

## タイマーを開始する

以下の例では 1 秒毎に関数を呼び出し、その度にカウントダウンを行い、最後に `BOMB!` と表示して終了します。

```vim
let dict = {'count': 10}
function! dict.countdown(timer) abort
  let self.count -= 1
  if self.count
    echo self.count
  else
    echo 'BOMB!'
    call timer_stop(a:timer)
  endif
endfunction

let timer = timer_start(1000, dict.countdown, {'repeat': -1})
```

タイマーが起動した後、タイマーによって関数が実行されている間以外は、ユーザーは編集を続けることができます。
例によって Vim はシングルスレッドですので、タイマーによって Vim script が実行されている間はユーザーは操作ができません。

## 関数の解説

### `timer_start({time}, {callback}, [, {options}])`

タイマーを開始します。`{time}` ミリ秒後に `{callback}` 関数を呼び出します。
関数はタイマー ID を返します。この ID を使ってタイマーの操作ができます。また、`{callback}` 関数も引数にこの ID を受け取ります。
`{options}` には辞書でオプションを渡せます。今のところ有効なオプションは以下のものです。

- "repeat"
  `{callback}` を繰り返し呼び出す回数を指定します。
  正数を指定すると、{time} ミリ秒毎に指定した回数だけ `{callback}` が呼び出されます。
  -1 を指定すると、制限なく呼び出され続けます。
  指定しなかった場合は 1 回だけ呼び出されます。

### `timer_stop({timer})`

指定したタイマーを停止します。`{callback}` 関数は呼び出されなくなります。

### `timer_pause({timer}, {paused})`

タイマーを一時停止したり再開したりします。`{paused}` が TRUE の場合は一時停止、FALSE の場合は再開になります。

### `timer_info([{timer}])`

タイマーの情報を返します。`{timer}` 引数を渡すと指定したタイマーの情報を、引数を省略した場合は全てのタイマーの情報を配列で返します。
情報は辞書で、ID や残り時間、呼び出される関数など一通りの情報が得られます。

### `timer_stopall()`

タイマーは一歩間違えると暴発し、一切の操作ができなくなるような事態も起き得ます。`timer_stopall()` を呼び出すことで、全てのタイマーを停止することができます。
MVC5 Ajax.BeginForm()を利用するための手順

#はじめに

MVC5でAjaxを使って遅延読み込みをしようと思い、Ajaxヘルパーを使ってみたら色々と手こずったので、それについてまとめます。

# Ajax通信にならない

```antlr-csharp
@using (Ajax.BeginForm("AjaxList","Person",
    new AjaxOptions {
        HttpMethod = "POST",
        UpdateTargetId = "table-1"
    }))
{
    <button type="submit" value="更新"></button>
}
```
AjaxHelperの拡張メソッドにBegingForm()があり、こんな感じでHtml.BeginFormと似た感覚で簡単にAjax通信・・・と思いきや、Action側を見てみるとAjax通信になっていない。

```antlr-csharp
public PersonControler : Controller
{
    public async Task<ActionResult> AjaxList()
    {
        if (!Request.IsAjaxRequest())
        {
            // ここに入ってくる
        }
    }
}
```

# パッケージの参照が足りなかった

色々と調べた結果、[Microsoft.jQuery.Unobtrusive.Ajax](https://www.nuget.org/packages/Microsoft.jQuery.Unobtrusive.Ajax/) の参照がないことが原因でした。

パッケージを追加しないと動かないメソッドが System.Web.Mvc.Ajax.AjaxExtensionsの拡張メソッドに含まれてるのって罠ですよね。

# ビューでjsの参照が足りなかった

Microsoft.jQuery.Unobtrusive.Ajaxを追加したのに、まだ、Ajaxにならない。

Microsoft.jQuery.Unobtrusive.Ajaxをインストールすると

- jquery.unobtrusive-ajax.js
- jquery.unobtrusive-ajax.min.js

の2つのjavascriptがScriptsフォルダに追加されています。

MVCに慣れている人には当たり前すぎるかもしれませんが、ビュー側で追加されたjavascriptの参照を追加しないといけません。

そこで、validateにならって、ajaxもBundleに追加。

```antlr-csharp
public class BundleConfig
{
    public static void RegisterBundles(BundleCollection bundles)
    {
        bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
                    "~/Scripts/jquery-{version}.js"));

        bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include(
    　              "~/Scripts/jquery.validate*"));

        // Ajax通信用に追加
        bundles.Add(new ScriptBundle("~/bundles/jqueryajax").Include(
                    "~/Scripts/jquery.unobtrusive-ajax*"));
    }
}
```

レイアウトもしくは個別のビューに@Scripts.Render("~/bundles/jqueryajax")の追加も忘れずに。

これでAjax通信が動作するようになりました。
効率的な階乗計算法

数値計算を行う場合、アルゴリズムを変えてみるとぐっと速度が上がることがあります。

## 階乗とは
念のため説明しておきますが、「$x$の階乗」は「1から$x$までの数をかけ合わせた数」のことで[^1]、「$x!$」と書き表します。ビックリマークがついているように、急速に大きくなっていきます。

なお、あっという間に64ビット整数も超えてしまうので、多倍長整数を前提とします。

## 掛け算の性質
どうあがいても大量の掛け算は避けられないので、まずはその性質について吟味しておきます。

[以前Rubyで行った試験の結果](http://qiita.com/jkr_2255/items/95a0c0a573baa1578121)から、「掛け算の所要時間は大きい方の桁数×小さい方の桁数の平方根に比例する」ことが分かりました（Karatuba法やToom-3法を使う場合には、ほぼ共通する結果だと思います）。

ということで、「できるだけ同じ大きさの数同士で掛け算を繰り返す」ようにするだけでも、かなり高速化しました。

## 2の成分

高速な計算を行う上で、「2の累乗」と「奇数成分」を分離して計算を進めることが有力な方法となります。というのも、コンピューターが2進法で動くものなので、「2の累乗をかける」ことは単なる「ビットシフト」というごく軽い演算となるからです。

そして、$n! = 2^x\times (2k+1)$ というように分けた場合、$x$は「$n$から、『$n$を2進法で表したときの1の数』を引いたもの」となります（この事実自体は、数学的帰納法で証明できます）。「1の数」は[x64に専用命令が積まれる](http://qiita.com/jkr_2255/items/ec141731682a79f605d0)ぐらいに最適化がなされているので、階乗の2の累乗成分は高速に計算可能です。

### 奇数パートの計算法その1 素因数分解
いちばんシンプルに考えて、「階乗を素因数分解してしまう」という方法があります。例えば、「100!に含まれる3の累乗はどれだけか」を考えてみると、

* 1～100で、3で割り切れる数…100/3→33個
* 1～100で、$3^2$で割り切れる数…33/3→11個
* 1～100で、$3^3$で割り切れる数…11/3→4個
* 1～100で、$3^4$で割り切れる数…4/3→1個

ということで、33+11+4+1=49となります。これは100まですべての数を当たらなくてもいいので、効率的に各素因数について計算できます。

そのうえで、累乗して掛け合わせていくのですが、これまた累乗してからかけるより、バイナリ法などで全部の素数について一気に累乗＆掛け算とするほうが高速になります。

この手法は、素数テーブルの生成時間を無視できるならかなり高速です。

### 奇数パートの計算法その2 奇数以上に分解しない

では、素因数分解のコストを払いたくないという状況では、どのような方法を使えるでしょうか。素因数分解しない「奇数」単体で考えても、同じものは複数回登場します。

* 100/2=50→51～99までの奇数は1回だけ
* 50/2=25→27～49の奇数は2回（27、27×2）
* 25/2=12.5→13～25の奇数は3回（13、13×2、13×4）
* 12/2=6→7～11の奇数は4回（7、14、28、56）
* 6/2=3→5は5回（5、10、20、40、80）
* 3/2=1→3は6回（3、6、12、24、48、96）

このように分類したところで、また適宜掛け合わせれば、そこそこの速度で動きます。

[^1]: なお、$0!=1$ という約束になっています。
まだクラウドなんか使ってるの？

この記事はオールアバウトアドベントカレンダー 5日目の記事になります。

私は今年の8月にオールアバウトを退社し、**Retty株式会社**に転職しました。
なぜか、Adventカレンダーの招待がとんできたので書きたいと思います。

この記事は、**退職エントリ**では無く、いかに自宅サーバが素晴らしいかを書いた物です。
しかし、あまり体調が良くないので詳しい部分は追記させてください。

僕が真面目に書いたAdventCalenderは以下の2つです。
いいねを押したい時は以下にお願いします。
1. [MySQLのlogを可視化する](http://qiita.com/takumi-suzuki/items/e88db63a1bfe4295d580)
2. [MySQLのlogを可視化する Part2](http://qiita.com/takumi-suzuki/items/3ebbde82f29b018e75dd)
　
# なぜ今更、自宅サーバーなのか
以前までは、私もAWSやGCPといったクラウド環境を利用していました。
会社で、複数のマシンを構築していたら、無性に自宅にも欲しくなってしまいました。
そのため、当初は自宅内でのみ使う用に自作PCにUbuntuをインストールして使用していました。
しかし、それだとデカイ箱を自宅に置く意味が無くなってきました。
そこで、RaspberryPiを使用してrouterを作成し、VPNで自宅に接続できるように設定しました。

その結果、 **自宅サーバーってあったら便利ですね！**

## Raspberry Pi router設定
昨年、僕はrouterを作成していたのでここは以下を参照してください。
http://qiita.com/jp_taku2/items/6d9ad5c554cdaf8d5289

## VPNの設定
以下を参考にVPNの設定を行いました。
https://www.sitepoint.com/setting-up-a-home-vpn-using-your-raspberry-pi/


# 環境変更
## マシン構成の変更
最初の環境を使用していると、マシンのスペックに不満を抱くようになってきました。
また、ディスクの耐障害性が低く、GCSへのバックアップが必要でした。
そのため、ディスクのSSD4枚のRAID5とHDD2本のRAID1構成を取ることにより、耐障害性を高めクラウドへのバックアップを最小限に行うように変更しました。

### GCSのバックアップ方法
以下をインストールし、GCSのディレクトリをマウントする事により、大容量のバックアップが可能です。
また、これを使用してMacのTimeMachineのストレージとして使用しています。
https://github.com/GoogleCloudPlatform/gcsfuse

## ネットワーク環境の変更
Raspberry Piを使用してネットワーク環境を構築していましたが、中々運用が大変でした。
そんな時に、**EdgeRouter** を共同購入しないかという話があり、即購入を決意しました。
EdgeRouterに関しては下のサイトで詳しく解説してくれています。
https://yabe.jp/gadgets/edgerouter-x/

### EdgeRouterの設定
ここは後日設定ファイルを貼っておきます。

# まとめ
自宅サーバーを運用してみて思った事としては、ネットワーク周りの設定が非常に面倒だなと思いました。
一部のポートは外から入ってこれるようにしていたため、VLANを分けたりファイアーウォールを作成したりと中々面倒でした。
また、停止した状態をネットワークから起動させる設定など、変なところに気を使わなければいけませんでした。
電気代も上がってしまったり、自宅にリッチな環境があるせいで睡眠時間を削ったりと辛い思いをたくさんしましたが、ネットワークの勉強になりました。
最後に感想としては、

###「クラウド最高！！！！！！！」
きっと何者にもなれない俺たちのほんのちょっとの矜持 - IntelliJ の辞書を一緒に育ててみませんか -

# はじめに

* この記事は IntelliJ IDEA アドベントカレンダー 2017 の5日目の記事です
    * ささやか過ぎる記事ですいません。。。
* IntelliJ は大好きだけど、緑の波下線が気になる。。。（けど何もしていない）
* プロジェクト毎に設定した辞書に自分だけ登録して避けてるけど、他のプロジェクトでも同じ事すんの。。。（めんどくさい）
* あれ、この語句登録されてないの。。。（なんでやねん！）
* IntelliJ 使っててスペルチェックをオフにしていいのは幼稚園ま（ｒｙ
* IntelliJ 使ってて緑のチェックに波下線をほおっておいていいのは小学（ｒｙ

　

* こんな症状をお持ちのアナタ。そうそこのアナタ。公開辞書リポジトリを作ってみたんですよ。登録してみたくないですか！

# 使い方

* [spelling-dictionary](https://github.com/officel/spelling-dictionary) を clone します
* [FILE]メニューから[Settings]を選択します（デフォルトのショートカットは CTRL+ALT+S）
* 検索ボックスで "spell" とするか、[Editor] の中から [Spelling] を見つけます
* [Accepted Words] タブにいろいろ入ってたりしますよね。消しましょうｗ （冗談です。オプションです）
* 隣の[Dictionaries] タブを開いて [Custom Dictionaries Folder] の [+] を押して、先ほど clone したリポジトリのディレクトリを選択します。
    * all ディレクトリをセットすると全部の辞書が入ります
    * dictionaries ディレクトリにはわかりやすく個別のディレクトリがあるので、必要な分だけ選択してもOK
* Apply するか、 OK すると今まで緑の波下線で、TYPO!TYPO!ってなっていたところがきれいになります。なる予定。

# 協力者募集

* 辞書ファイルの作成に協力していただける方を募集しています
* 当方 github 慣れしていない素人（？）です
    * まともにプルリクしたこともありません（そんな度胸がありません）
    * git 自体は普通に使えるつもりなんだけど。。。
* プルリクの使い方から教えてやるぜ、という方
    * ぜひプルリクを送ってください
* 自分もプルリクの練習したいぜ、という方
    * 何事も慣れと挑戦が大事です。ぜひプルリクを送ってください
    * 辞書ファイルはただのテキストなので簡単です。のはずです
* ローカル辞書はたくさんあるぜ、という方
    * Issue に、登録したらいいと思う語句を叩き込んでください
    * １語句１Issue はやりすぎかもしれないけど慣れるまではいいかなって
* コントリビュータになって一緒にやりたいぜ、という方
    * ぜひ一緒にやってください（≒エンジニアとして仲良くしてください）
* さあ一緒にれっつ辞書！

# 今後の方針など

* せっかく github 上に projects や wiki があるので、基本的にはそちらでやりとりできればと思います
* もちろんココでやりとりしても構いません（後で勝手に転記するなりなんなりします）
* 家も職場もそこそこいいPCを使っているので、このスペル辞書がどのくらいのサイズになると影響があるのかわかりません
    * なので、たくさんの利用者の声が欲しいです
    * 利便性を考慮した改善提案も積極的に欲しいです
    * github を利用してエンジニア仲間が欲しいです
    * 安西先生。。。TYPOを気にしないでプログラミングが、、、したいです

# ちなみに

* IntelliJ 上で TYPO やその他のエラーにジャンプするデフォルトのキーボードショートカットは F2 (上方向には Shift + F2)
* TYPO の修正（に限らないけど）ALT + Enter でコンテキストメニューが表示されるので Typo: Save 'hoge' to dictionary 等でスルー
* という負の遺産を消し去りたい。まどか風に言うなら「全てのTYPOを消し去りたい。」
* そんないちIntelliJ使いのちっぽけな矜持
FileMaker API for PHP と FX.php の違い

# 用いられている機能の違い
FileMaker のデータを PHP を用いて操作する方法には、「FileMaker API for PHP」を用いる方法と、「[FX.php](https://github.com/yodarunamok/fxphp)」を用いる方法が主にあります。表面上はどちらも PHP で扱いますが、以下のような違いがあります。

### FileMaker API for PHP
「FileMaker API for PHP」は、「カスタム Web 公開 with PHP」を用いた機能です。

### FX.php
「FX.php」は、「カスタム Web 公開 with XML」を用いた機能です。

# 利用する上ではベースとなっている機能は意識する必要はない
上記のように内部的に利用する機能は異なりますが、どちらも PHP というラップにくるまれて利用できるので、利用する側でその内部機能の違いを意識する必要はありません。

# 実際の機能や性能の違い
これらを PHP 上で実際に扱う上での機能（性能）の違いはどうでしょうか。

###「[マイナビニュース](http://news.mynavi.jp/column/fmxphp/001/)」には以下のように記述があります。

#### FileMaker API for PHPのメリット
- オブジェクト指向でコードが書ける
- 機能が豊富

#### FileMaker API for PHPのデメリット
- 機能が豊富なかわりに、一部機能のパフォーマンスがFX.phpに劣る。例えばポータルが配置されたレイアウトにアクセスした場合、FX.phpと比較するとレスポンスが数秒遅くなり、また一度にあつかうレコードが多ければ多いほどこの差がでる
- 一部のコードが難読化されている。ライブラリ全体を通して何が行われているかの見通しがFX.phpと比較すると難しい

#### FX.phpのメリット
- ライブラリ自体が軽量
- 使い方がFileMaker API for PHPと比較しシンプル。またパフォーマンスもよい

#### FX.phpのデメリット
- 機能がFileMaker API for PHPと比較するとやや少ない。動的な複合OR検索を実現する場合は対応するクラスを自前で用意する必要がある

### 実際に比較検証してみたページ その1
[こちらのページ](http://blog.tpc.jp/2016/06/fm-web-performance-comparison-xmlapi.html)では、FX.php と FileMaker API for PHP と 生XML と ODBC の比較をしています。

結果はページにあるとおりですが、FX.php と FileMaker API for PHP は（相対的に）よくありません。「マイナビニュース」にある、FX.php が「パフォーマンスがよい」というのもあまり大きな差には見えません。

### 実際に比較検証してみたページ その2
[こちらのページ](http://blogs.yahoo.co.jp/nao_r1/54523450.html)でも FileMaker API for PHP と FX.php の比較の結果（MLの引用）を紹介しています。それによれば、FX.php の方が 8倍 速いとのことです。

# 現場では
もっとも、レスポンスにどのくらいの時間をかかるかをもってして性能の良し悪しを語るのは場合によってはあまり意味が無いことがあります。それよりも、先にプロダクトとしてリリースをすることが重要な場面もあるでしょう。

学習コストがかかることは前提の上で、ケースバイケースでいつでも使い分けられるような準備をしておくことが大切なのかなと思います。
奢ってもらえる飲み会なら高いものをじゃんじゃん頼もう

下請けCOBOLERとして生きていた頃のノウハウ Advent Calendar 2016の5日目の記事です。

ネタ切れ感がひどいのでひどい記事書きます。

正直な話、プロパーは想像以上に金持ちです。
払ってくれるという飲み会で金を払う必要なんてありません。

なぜ、プロパーは奢ってくれるのか、それは安い賃金でこき使っていることを知っているからです。
労働と賃金が不釣り合いな部分をこうやって補填してくれるのです。

そこを理解してかどうかはわかりませんが、自分の派遣先のプロパーさんはめっちゃ奢ってくれる人だったので本当に素晴らしい方でした。

いつでもゴールドカードで飲み代＆タクシー代全部払ってくれました。
プロパーさんは年収200万円の下請けエンジニアとは違い、四桁万円だってざらです。
一匹時価ののどぐろとうまい棒でも彼らには違いなんかありません！
遠慮せずにどんどん奢ってもらいましょう！
初参加のISUCON予選敗退で手に入れたもの

## 現実見せつけられて最高の学びだった

最終スコア5000ちょっと。そもそも正のスコアが出たのが半分以上終わってからでした。
私の貢献値はゼロ。完全に役立たずに徹したわけですが、役立たずだった分せめて学びにはしよう、ということで書かせていただきます。

ISUCONは、Webアプリの様々なレイヤーに強制的に触れることになります。
普段開発と運用、インフラとアプリが分離されているSIer仲間のみなさんにつきましては、ぜひ出場して一緒に打ちひしがれたいな、と思う所存です。

## 経緯

そもそもISUCONとは

> お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル
> (出典) ISUCON公式Blog http://isucon.net/

です。お題のWebアプリ(運営の方の手作り...!)がクラウドサービス上で配布されるので、決められた時間以内に決められたテストツール(こちらも手作り...!)のスコアを一番高くまで引き上げたチームが勝ちです。

私はTechCircleのコアメンバーである[@shiraco](http://qiita.com/shiraco)さんと[@ike_dai](http://qiita.com/ike_dai)さんにお声がけいただいて参加してきました。これまでも「あ、そういうのあるんだなー、おもしろそうだなー」と思ってはいたのですが、どこか自分事ではないような気持ちでTwitterやブログエントリを横目に見ていました。誘っていただいた時に急に自分事になったので、びっくりしながら即決しました。

## 結果

ベストスコア5000点ちょっとだったはずです。勿論予選落ちです。

## 事前にしたこと

素振りを0.5回、作戦会議を1回しました。
素振りは過去問を使ってやってみました。定石も何もわからない状態での手探りで、なんとなく雰囲気は分かった程度でした。

もっとやっとけよ、以外の何物でもないですね。なんかなんとかなるような気がしていたのでしょう。こういうところが現実の認識が甘いところでした。

## 当日

メモを取っていないので記憶ベースですが、以下のような流れで行いました。

1. まずベンチマークを取る。
1. 0点が出て驚愕する。
1. 開発環境を整える。(VMを誰でも触れるようにする、ソースコードをプライベートリポジトリに上げる、fluentdを仕込むなど)
1. コードリーディング。めちゃめちゃコードが短くて何もすることがない気がして焦る。
1. 何もしないわけにいかないので怪しげなところを考えて3人で役割分担する
1. うまくいかない
1. nginxのワーカー数がデフォルトで数個だったのをもう少し上げたら正のスコアが出る
1. 効果測定しながら少しスコアを稼ぐ
1. 終了

## 学び

### Webアプリの高速化の価値

> 普通のSEがうっかり作っちゃうようなアプリケーションを、同じリソースで100倍スピードアップするってすごい価値が高いイイ仕事！
> (出典) 予選後の反省飲み会メモ

私たちはせいぜい2倍程度にしかスピードを挙げられなかったのですが、上位の人たちが持っているスキルは価値が高いと心から思いました。同じサーバで100倍以上のパフォーマンス改善を行えるなら、それが大規模なアプリケーションであればあるほどリソースの購入コストを引き下げられます。それに、今あるものを使い倒してパフォーマンスを稼ぐのは美しいと思います。

### 現実見た

しかしそれより一番学びだったのは、今自分がなんとなく仕事をできているような気がしていても、それは誰かデキる先輩が敷いてくれたレールに沿って歩いているだけで、1人では何もできないという厳しい現実でした。

仕事はチームプレーで、私はまだ部分的に構成を決めることはあっても、最後は先輩やマネジャー、テックリードの人たちが引いた線路に乗っかることになります。そうやって下駄を履かせてもらっている中で想定通りの成果を上げたところで、こういう場にぽんと放り出されてなんでもいいからパフォーマンスの改善につながることをハックしてみろよ、と言われたら何もできませんでした。

それを痛感した1日は楽しかったですが悔しかったです。Webアプリを仕事で書いてるはずなのに、ぽんと渡されたWebアプリを全く改善できない自分を知ることができたのは、ガツンと殴られたような学びでした。

### 3人で良かった

歯が立たなくても一緒に頭を抱えられるチームメンバーがいるのはとてもありがたかったです。歯が立たなかったことを、一緒に悔しがって一緒に笑えたおかげで、変に苦しまずにいられました。

チームというか、応援してくれる関係者というのは仕事でも趣味でも必要だなと感じました。精神論ですが、自分の志向を知ってくれている上司がいたり、自分が作っているものに興味を持ってくれる人がいると、それだけでモチベーションが格段に保ちやすいです。

### 来年も！

誘ってくださった[@shiraco](http://qiita.com/shiraco)さん、[@ike_dai](http://qiita.com/ike_dai)さん、本当にありがとうございました。
来年は同じチームか別のチームか分かりませんが、また一緒に出て今度は本選にいきましょう！

明日はユーモア溢れかつ真面目な[@seiketkm](http://qiita.com/seiketkm)さんです。お楽しみに〜
パトリシア木の由来

1968年の10月、当時マサチューセッツ工科大学の院生だったパトリシアは論文執筆のために大きな辞書を頻繁に引かねばならなかった。
ある時彼女は自分の体が辞書の引きすぎで木になっていることに気付く。
それ以来彼女はパトリシア木と呼ばれるようになり、今も入力の長さnに対しO(n)の時間で語を引き続けている。
Two Phase Lock

## 実行スケジュールを動的に作成したい

**Conflict Serializability**(CSR)が担保される実行スケジュールはトランザクションの実装上好ましい性質を持っている。
そのCSRを動的に生成する方法の1つが**Two Phase Lock**(**2相ロック**または**2PL**)である。
厳密にはCSRより更に狭い範囲のスケジュールしか許容しないが、詳細はリカバリなどの議論を含むため後日にする。

**Two Phase Lock**とは、**成長相**と**縮退相**の2相からなるロックプロトコルである。
ロックプロトコルとは、複数のロックを獲得・解放する際の取り決め（プロトコル）を規定する物であり、特定のロック実装には依存しない。

**Two Phase Lock**の規定するプロトコルは以下である。

- **成長相**のあとに**縮退相**が来なくてはならない。
- **縮退相**のあとに**成長相**が来る事は許可されていない。
- **成長相**と**縮退相**はそれぞれ1つずつしか存在してはならない。
- **成長相**はロックを獲得し続けるフェーズ。トランザクションの進行と同時に都度必要なロックを取る事を想定している。
- **縮退相**はロックを解放し続けるフェーズ。最終的にはすべてのロックを手放す事を想定している。

図に書くと以下の様になる。

![2pl-graph.png](https://qiita-image-store.s3.amazonaws.com/0/1716/2390677d-7dd7-fc00-60b6-b93cd59dc71f.png)

例えば2つのトランザクションが並行して走るとする。

Tx1: Read(x) Read(y) Write(x)
Tx2: Read(x) Read(y) Write(y)

スケジュール図で表すと以下のようになる。

![2pl.png](https://qiita-image-store.s3.amazonaws.com/0/1716/8944938f-31f2-efa7-16dd-1122b809ecde.png)

これが並行して走る場合、**2PL**ではこのようにロックを取る。

![2pl2.png](https://qiita-image-store.s3.amazonaws.com/0/1716/0819a8af-df89-ba2b-fa01-8cc59b1abaca.png)

この**2PL**を実行した際の競合関係を整理すると、以下の2パターンのどちらかに限定される。どちらもCSRである。

![2pl_cr1.png](https://qiita-image-store.s3.amazonaws.com/0/1716/6a5ed001-39c0-e82d-f4e4-96b605d2ea57.png)
![2pl_cr2.png](https://qiita-image-store.s3.amazonaws.com/0/1716/c93ddf03-0404-de02-62bb-c86fe22dded9.png)

**2PL**のプロトコルに従う事によって、競合関係にあるデータ群へのアクセスは完全に直列化される。
教科書では何故直列化されるかと証明する際には背理法を使う事が多い。

**2PL**の亜種として、**Conservative Two Phase Lock**というものもある。

![c2pl.png](https://qiita-image-store.s3.amazonaws.com/0/1716/e1545cf0-e48f-6bf3-e578-fb3dcfc7581b.png)

これはトランザクション開始時に必要なロックをすべて取るという亜種である。成長相が一瞬で終了している。こちらは後に説明するデッドロックの問題が起きにくいという利点がある。
トランザクション実行前に触るデータがすべて確定はしないのではないかという懸念はある。だが

- 静的にトランザクション手続きを解析する
- 最初に取っていないロック以外を取りたくなった時は一旦全部ロックを手放してトランザクションを最初からやり直す

など、様々な工夫を用いて実用することも可能らしいが、商用システムで使っていると聞いたことは無い。
別の亜種としては**Strict Two Phase Lock(S2PL)**というものもある。

![s2pl.png](https://qiita-image-store.s3.amazonaws.com/0/1716/930d2602-6a24-ee42-a6da-b5917790d9a0.png)

こちらはトランザクションの完了後にロックを手放せというもので、プロセス障害などからのリカバリを考えた際に理想的な特性を満たす（詳細は後日）。そのため、データベースの文脈でただ2PLと書いている場合は**S2PL**を指していることも多い。
より厳密に言うと、ロックはRead-Writeロックで「Read-Lockはコミット前に手放しても良い」という制約が付いたものを**S2PL**と呼び「Read-Lockもコミットまで手放してはならない」という制約が付いているものを**Strong Strict Two Phase Lock(SS2PL)**と呼ぶ。この特性はコミット前に手放されたRead-Lockを別のトランザクションがWriteロックで取り追い越してコミットしてきた場合に少しややこしい議論になる。詳細はリカバリに付いて書く際に触れる予定。
Java Silverつまりどころ(その３)

# つまりどころ〜

　　
こんにちは。

Java Silver来年ほんきだす。


## デフォルトコンストラクタ

インスタンスが生成される際に自動的に呼び出されるメソッドのこと。

コンストラクタを1つも定義しない場合、自動的にデフォルトコンストラクタと呼ばれるコンストラクタが作成される。

下記のようなクラスを作った場合、```Hoge() {}```というデフォルトコンストラクタが作成される。

```java:
class Hoge {

}
```

こんな感じで。

```java:
class Hoge {
    Hoge() {

    }
}
```

引数なしコンストラクタの意味・・！
コンストラクタは実行される前に必ず親クラスのコンストラクタを呼び出すから。
実際には下記のようなコードが生成される。

```java:
class Hoge {
    Hoge() {
        super(); // 親クラスのコンストラクタを呼び出す
    }
}
```


## 注意点

継承しているクラス(Hoge)、継承されている親クラスがある(Parent)場合、
親クラスにデフォルトコンストラクタつくる必要がある。

```
　class Hoge extends Parent {
       Hoge() {  //Hogeのコンストラクタ実行時にsuper()が実行される。
       }         //Parentにデフォルトコンストラクタが作成されてない場合、コンパイルエラー
　　　　　　  
   }
```


super();は、最初によばないとだめだぞ〜。

```java:
class Hoge {
    Hoge() {
        System.out.println("だめだめー");
        super(); // 親クラスのコンストラクタを呼び出す
    }
}
```


　　
アウトプットして、ちしき固めていくぞ〜。
Realm移行時にStringly typedなAPIを回避する

iOS開発者にとって、Realmはそれまで敷居の高かったCore Dataと格闘するコストを削減してくれるDBライブラリです。

今やRealmはMobile Platformの導入により、iOS / Androidアプリ開発におけるDBのライブラリの代表格となっています。

Swift全般にも言えますが、Realmを使ってうれしいことは、strongly typed apiなので、
アクセスにおけるtypoが発生しないことです。

ですが、Objective-Cから存在するStringly TypedなAPIを使用する場面は発生してしまいます。僕が実際に遭遇したユースケースとその対処法を紹介します。

## APIから取得したデータをRealmに保存する

あるAPIによって、jsonをレスポンスとして得たとき、そのレスポンスをそのままRealmに保存するとします。

Dictionaryにシリアライズして保存してもいいのですが、Stringly Typedになってしまうので、Himotokiなどの型安全なJSONデコーダをつかって、Realmオブジェクトにマッピングします。

変換したJSONを、RealmObjectのサブクラスに生やした下記のようなメソッドでRealmObjectに変換します。

``` swift 
class Sample:Object {

    func convert(from response: APIResponse.Hoge) {
        let realm = try! Realm()
        do {
        		hoge = response.hoge
        		fuga = response.fuga
            
            try realm.write {
                realm.add(self, update: true)
            }
        } catch {
            
        }
    }
}
```

Himotokiの`decode`でこれをやらないのは、常にRealmに保存するとは限らないからです。

これはみなさんもよく遭遇するユースケースだと思います。

## DBとして用いられているUserDefaultsをRealmに移行する

UserDefaultsにDictionaryを入れて保存している場合がありますが、内部に一体何が保存されているのかわからないので、こういうものはとっととRealmにマイグレーションします。

上記と同じ例でいけそうです。

``` swift 
class Sample:Object {

	let hoge = RealmOptional<Int>()
	let fuga: String? = nil

    func converted(from data: [String : Any]) {
        let realm = try! Realm()
        do {
        		hoge.value = data["hoge"]
        		fuga = data["fuga"]
            
            try realm.write {
                realm.add(self, update: true)
            }
        } catch {
            
        }
    }
}
```

上記のユースケースなら遭遇する例も多く、また実装も難しいものではありません。RealmObject側をOptionalにしていますが、これはケースバイケースになると思います。

### 実際にあった怖い話：保存しているキーのTypo
これは実際にあった怖い話ですが、UserDefaultsに配列が保存されており、その内部がDictionaryになっているデータがありました。

こんなやつ

``` json
[
	{ "images" : 
		[ 
			{ "name" : "name" },
			{ "name" : "name" }
		]
    }
]
```

しかし、保存するメソッドが統一されておらず、キーのtypoによって、実際にはこんな感じになってました

``` json
[
	{ "images" : //imagesが正しい
		[ 
			{ "name" : "name" },
			{ "name" : "name" }
		]
    },
    { "image" ://typo!! 
		[ 
			{ "name" : "name" },
			{ "name" : "name" }
		]
    }
]
```

このままではマイグレーションできません。マイグレーションする前に、キーは統一しておかなくてはなりません。

Dictionaryを`decode`する時に下記のような処理を通さざるを得ませんでした。Himotokiを使っています。

``` swift
static func convert(from dictionary: [String : Any]){

	let images: [Image]? = {
		do {
			let images: [Image] = try e <|| "images"
			return images
   		} catch {
   			do {
   				let images: [Image] = try e <|| "image"
   				return images
   			} catch {
   				return nil
   			}
   		}
	}()
}
```

このような事故が起こらないように、日頃からStrongly TypedなAPIを使うように心がけたいですね。

## 結論
他にも古いプロジェクトでは、SQLiteから移行する場合等もあると思いますが、基本的には、RealmObjectのサブクラスにマッピング用のメソッドを生やすのがよさそうです。

Stringly Typed APIは良くないので、Strongly TypedなAPIになるように作り変えていきましょう。

## 参考資料
今回の内容はtrySwift!NYCでAndyy Hopeさんが発表されていたお話をRealm周辺で適応するとどうなるかという話でした。僭越ながら、Realmでこの講演の日本語への翻訳を担当させていただきましたので、ぜひこちらもお読みください。

[Swift Eye for the Stringly Typed API(日本語)](https://realm.io/jp/news/tryswift-andyy-hope-swift-eye-stringly-typed-api/)
TSLintでJavaScriptをLint

## TSLint v4
TSLintは、**TypeScript専用**のlinterでしたが、[TSLint 4.0](https://palantir.github.io/tslint/2016/11/17/new-for-4.0.html)から、**JavaScript**のlintができるようになりました :clap::clap::clap: とはいえ、ルールの数などでは、ESLintなどのJavaScript専用Linterにはかないません（ESLintには[TypeScript ESLint Parser](https://github.com/eslint/typescript-eslint-parser)という実験実装があるので、JavaScript専用というと怒られてしまうかもしれませんが :disappointed_relieved:）。そのため、TSLintでJavaScriptのLintが役立つのは、TypeScriptプロジェクトの中に、TSに対応していないごく一部のJavaScriptファイルがある場合だけです（e.g. gulpのソースのみJSで記述している場合など）。効果は局所的ですが、一部のファイルのlintのためだけに、TSLintとESLintを併用しているプロジェクトには役立つはずです。

## TSLintでJavaScriptをLint
それでは、いよいよTSLintでJavaScriptをLintしてみます。今回は手軽に検証できるように、VS CodeにVSCode-TSLintを入れてエディタ上に表示されるメッセージで確認します（VSCode-TSLintもJSに対応済みです）。必須環境はTSLint4.0以上とTypeScript2.0以上の2つだけです。この2つをローカル、またはグローバルにインストールします（以下の例ではローカルインストールにしています）。

```:cmd
npm init
npm install typescript
npm install tslint
```

続いて、**tslint.json**を作成して、新しく追加された**jsRules**プロパティを設定します。jsRulesに記述できるルール名はTypeScriptに適用するルール名と同じです。no-anyルールなど明らかにTypeScript専用のルール以外は、あらかたJavaScriptにも適用できます。

```json:tslint.json
{
    "jsRules": {
        "class-name": true
  }
}
```

設定はこれだけです。なお、class-nameルールは、クラス名の大文字始まりを強制します。ルールに違反したfooクラスを作ってみます。

```js:sample.js
class foo {
    
}
```

今回はVSCode-TSLintを入れているので、VS Code上で見ると、エラーを通知してくれています。

![無題.png](https://qiita-image-store.s3.amazonaws.com/0/67429/a046de92-8d10-8c3b-f0bf-81a17cdc44d2.png)


## jsRulesオプション
上述したように、tslint.jsonにjsRulesプロパティが追加されました。TypeScriptのみLintしたい場合は、従来の通りrulesプロパティのみを使います。ちなみに、jsRulesオプションが生まれたのは、TSとJSで異なるルールを適用したい場合を考えてのことです。

```json:tslint.json
{
    "rules": {
        "no-any": true,
        "no-var": true
    },
    "jsRules": {
        "class-name": true
  }
}
```

たとえば、上記のコード例では、TSにno-anyとno-varルールを適用しています。TS的には便利ですが、no-anyは型にまつわるルールのため、JSでは不要です。また、no-varはletやconstの使用を勧めるものですが、JSだとIEなどで実行できなくなるため必ずしも向いていません。そこで、JS向け個別設定ができるようにjsRulesプロパティが追加されました。

#### （おまけ）Lintの内部実装
Lintのアドベントカレンダーなので、少々内部実装の話を少しだけ。そもそもTypeScriptは、v1.8からJavaScriptをパースできるようになっていました。そのため、TSLintでは、JavaScriptをパースした構文木をTypeScript本体からもらっています。それに対して、TypeScriptと共通のルールを適用しているだけです。とはいえ、TypeScript固有の文法に対するルール（e.g. 型指定など）は当然使えません。実装の流れは大体この[PR](https://github.com/palantir/tslint/pull/1515)で追えます。
Java 系 Qiita Advent Calendar 2016

Java 大好きなんで、4 年ほど仕事では PHP ばかりで Java は述べ数ヶ月しかやってないけど Java 好きなんで、Java に関係する Advent Calendar をまとめてみました。

# [Java Advent Calendar](http://qiita.com/advent-calendar/2016/java)

総本山ですね。基本です。

# [Java EE Advent Calendar](http://qiita.com/advent-calendar/2016/javaee)

Java EE のカレンダーももちろんありますよ。
> Springやアプリケーションサーバなど、サーバサイドJavaに関連することであればなんでもOKです！

とのことです。

# [JavaFX Advent Calendar](http://qiita.com/advent-calendar/2016/javafx)

JavaFX です。Java と FX のあいだにスペースを開けてはいけません。

# [RxJava Advent Calendar](http://qiita.com/advent-calendar/2016/rxjava)

RxJava。

# [Java Puzzlers Advent Calendar](http://qiita.com/advent-calendar/2016/java_puzzlers)

楽しみながら Java の仕様に詳しくなれる Java Pazzlers の Advent Calendar です。
内容が難しく見えるのか、あまり見に来てくれる人がいないっぽいですが、読むだけならむしろ脱初心者、脱中級者を目指す人におすすめの内容です。（書くのはさすがに大変かも・・・）

# [Kotlin Advent Calendar](http://qiita.com/advent-calendar/2016/kotlin)

今話題の Kotlin です。私も今から勉強する予定です。

# [Scala Advent Calendar](http://qiita.com/advent-calendar/2016/scala)

Kotlin があるんだからそりゃ Scala もありますよ。

# [G*Advent Calendar(Groovy,Grails,Gradle,Spock...) Advent Calendar](http://qiita.com/advent-calendar/2016/gastah)

おっと、カレンダー名がわかりづらくて（言い訳）見逃していました。Groovy もありますよ。


そんな感じで。
安易にiOSのUUIDをアカウント認証ロジックに使ってはいけない

この記事は [Akatsuki Advent Calendar 2016](http://qiita.com/advent-calendar/2016/aktsk) の5日目です。

# はじめに
iOS端末のUUIDとソーシャルゲームアプリのアカウント認証にまつわる話です。

# 経緯
UUIDをアプリのアカウント認証のロジックに使用していたら、
iCloudバックアップ後にログインできなくなってしまった。

## UUIDとは
> UUID(Universally Unique IDentifier)とは、全世界で2つ以上のアイテムが同じ値を持つことがない一意な識別子のこと。
> 何らかの組織やシステムなどが管理・割り当てを行うわけではなく、誰でもいつでも自由に生成することができるが、他のUUIDと重複することは起きないようになっている。

出典: [IT用語辞典 UUID](http://e-words.jp/w/UUID.html)

UUIDは絶対に被らないユニークなIDです。
iOSでもUUIDを取得するメソッドが提供されています。
```例: [[UIDevice currentDevice].identifierForVendor UUIDString]```
このUUIDをアプリのアカウント認証のロジックに使用するケースがあります。

## iCloudによるバックアップ
iCloudとはApple社が提供するサービスで、バックアップやiPhoneを探すが有名かと思います。便利ですね。
iCloudを使って端末のバックアップを取ると、新しくiOS端末を購入したとしても、
すぐに元の端末の状態に戻すことができます。
ソーシャルゲームアプリのデータとかもiCloudの容量があればバックアップすることができます。
本当に便利ですね。しかし、ここでほいほいバックアップから復元すると、ある問題が起きます。

# 何が起きたのか
iCloudからのバックアップでiOS端末内のデータは丸ごと復元されますが、
端末が違うためUUIDが変更されています。
UUIDをゲーム認証ロジックに使用していた場合、アプリデータ自体は残っているため、
そのままアプリを起動すると認証に失敗してしまいます。(ゲーム内のIDは正しいが、端末が違う…)

よって、ユーザは新規アカウントで始めることを余儀なくされます。
前端末で遊んでいたデータを自己修復する術はないため、
ディベロッパーのカスタマーサポートにアカウント復旧をお願いするほかありません。

ユーザはアカウント復旧を待たなくてはいけないし、
開発者はアカウント復旧に頭を抱えてしまいます。

# どうすればいいの？
## 1. UUIDを端末内部に保存する
- 端末からUUIDを取得した時点でUUIDを端末内部に保存しておく
- もし取得したUUIDが違っていた場合(iCloudからのバックアップ、etc.)、保存してあるUUIDを用いて認証を行う
- 認証に成功した時点で、保存してあるUUIDを新しいものに書きかえる

## 2. UUIDを使わずに端末を特定するIDを発行する
- 端末から取得したUUIDではなく、サーバ側で発行したUUIDを用いて認証を行う
- 端末側ではそのUUIDをセキュアな場所に保存しておく

## 3. iCloudでバックアップするときは注意してください、と呼びかける
- 諦めの一手
- iCloudによるバックアップを行う前に、アプリ内の引き継ぎを行っておくように、とアプリ内でアナウンスする

## 結論
1や2を用いることでiCloudバックアップ対策になると思います。
3は冗談交じりですが、既に動いているサービスだと
なかなか全ユーザの認証の仕組みを変えるのにはリスクがあると思うので、手段としては有りかと。

# まとめ
> UUIDは絶対に変更されないもの。
> 変更されるときは機種変更のときだけだからその時はアプリ内のデータ引き継ぎはやってくれるだろう。

という前提は捨てましょうm(__)m
Styleの事

FreeBSDのカーネルソースをいじってPHABRICATORでレビューしてもらってheadにマージしてもらったのですが、Style(9)を何度か指摘されました。

私のコーディングスタイルは、ほぼ一から開発するようなケースはなく、類似のコードをコピーするところから始めます。大昔にシーナ&ロケッツの鮎川誠さんがイベントで、ホームページでJavaScriptを使っている事を聞かれて、「良さそうなページからコピーしてる。ロックの基本はコピーです。」とか言われて、私もロックな気持ちでプログラミングしています。:)

コピーから始めるときにいろいろなコードを見る事がうまくいく手助けになることがあります。SOCのネットワークコードを作ったときにTulip互換なのでdev/deのコードをベースにしようとしてうまくできませんでした。これはdeのコードはいろいろなデバイスのサポートのために、コードの見通しが悪くなっているためです。代わりにsys/mipsにあったコードをベースにしてどうにか作る事ができました。socベースのコードはそのデバイスのみのサポートになるので、比較的見通しが良いコードが多いです。

レビューの話に戻すと、PHABRICATORのツールのarcでもLINTは実行しているようなのですが、それ以上の項目がStyleでは指定されています。具体的に指摘された点は以下の通りです。

* defineの後の空白はスペースでなくタブで
* if,forの後には空白を入れる
* 演算子の前後にも空白を入れる
* //を使わない
* 変数の宣言と初期化は別にする
* 変数定義が無い関数は{の後一行開ける

既存コードにも違反しているものあって、それをコピーして指摘されるとちょっと凹みます。とはいえ、FreeBSDのコードの奇麗さにも貢献している事だと思うので、ちゃんと守っていきたいです。

私の場合、ロシアの方々が指摘してくれたのですが、manを見るよりも指摘された方が理解が早くありがたく思います。

Style対応のlintツールみたいなものがあったら良いのにと思ったりします。

ではでは。
gitやsvn等の管理下のファイルにpatchコマンドを使うときは--no-backup-if-mismatchを付けると少し楽

この記事は[ACCESS Advent Calendar 2016](http://qiita.com/advent-calendar/2016/access) 5日目の記事です。

## 背景

私が扱うunified形式のパッチファイルは、適用対象のソースコードとパッチファイルの内容との間で、行位置がずれていたりパッチファイル内の周辺部分のコードが変更されていたりすることが多い。
そのようなパッチファイルを `patch -pN <hoge.patch` で適用すると、パッチが当たるファイルとパッチファイルの内容とに違いがあった場合に、元ファイルがコピーされて "（元ファイル名）.orig" のファイル名でバックアップファイルが作成される。
しかし、gitやsvnなどのバージョンコントロールの管理下のファイルに対しては、このバックアップファイルの作成が邪魔に思えていた。バージョンコントロール管理下にあるので元コードに戻すのは簡単だし、バックアップファイルを削除するという手間が発生するし。
ということで、バックアップファイルを作らない方法が欲しかった。

なお、 `git apply --reject hoge.patch` は長ったらしくてタイプが面倒で、使わずにいる。

## 説明

gnu patchには no-backup-if-mismatch というオプションがあり、
http://www.gnu.org/software/diffutils/manual/html_node/patch-Options.html
バックアップファイルの作成をしないでいてくれる。

## 便利化

「カレントディレクトリがgitリポジトリ内なら no-backup-if-mismatch オプションを付けてpatchコマンドを呼ぶ」を勝手にやってもらう。
以下の記述を.bashrcあたりに書く。

```
patch() {
  local additional_patch_options=""

  if which git >/dev/null && git rev-parse 2>/dev/null; then
    additional_patch_options="--no-backup-if-mismatch"
  fi

  $(which patch) "$additional_patch_options" "$@"
}
```

あとはこれまでどおりpatchコマンドを使えばよい。

カレントディレクトリがgit管理下かどうかの判断には http://memo.sugyan.com/entry/20120323/1332507609 を参照した。
カレントディレクトリがsvn管理下かどうかの判断方法がさくっと分からなかったので、svnのフォローは省略。
`svn info` のexit statusを見るのがいい？

## 備考

--no-backup-if-mismatch はgnu patchで対応しているオプションのようなので、gnu版でないpatchコマンドでは--no-backup-if-mismatchが対応してなかったりバックアップファイル生成の挙動が異なったりするかもしれない。
例えばFreeBSDのpatchコマンドでは--no-backup-if-mismatchに対応してないらしい。
https://github.com/drush-ops/drush/issues/1502
IoT 初体験 Amazon Echo dotにPPAPを言わせる

### :cloud: 背景
今年のAWS re:Invent 2016 では、swag(参加者への特典グッズ)で、Amazon Echo dotが配布されました。

自分も参加しswagを頂いたので、「帰国したらあそぶんだー」と浮かれていたら、技適的な話でEcho dotは日本では使えないとのことでした。がっくりきていたわけですが、他の皆様がガンガンさわっている様子を拝見し、ふわっと熱を取り戻してきました。

### :robot: Custom Skillを作ってみた
チャンスはラスベガスにいる間と思い、自分も簡単ではありますがCustom Skillを作るところまでできました。

やってみた感想を先に言うと、率直に「これがIoT... ヤバい。面白すぎる。」というのが本音です。

これが自分にとってのIoT初体験になりました。

### :pen_ballpoint: :pineapple: :apple: :pen_ballpoint: 
これが実際に動かした動画になります。
https://youtu.be/Nn3SrQlFtQU
[![Youtubeが読み込めません](http://img.youtube.com/vi/Nn3SrQlFtQU/0.jpg)](https://youtu.be/Nn3SrQlFtQU)

やっていることは、

* 自分の作ったCustom Skill(※備考)をloadする。
* 1回言ってと指示する →　echo dot が１回答える
* 2回言ってと指示する →　echo dot が２回答える

ほんとにしょーもないのですが、実際に自分の書いたコードが目の前のモノと連動して動く姿は、**ちょっとした感動** :grinning: がありました。

2回言わせた時に、2回目は**アクセントが変わっている**あたりにグッときます。

今回のre:InventではIoTやAI押しな新サービスががっつり出てきて、一気に加速する予感がプンプンします。業務で使う予定はありませんが、IoTに俄然興味がでてきたので、もっと積極的に追いかけていこうと思います。


#### 参考
参考にさせていただきました。ありがとうございました。
http://dev.classmethod.jp/cloud/aws/sample-custom-skill-testing-by-amazon-echo-dot/

#### 備考
* Invocation nameを sample skillにしたので、動画ではSample skillと呼んでます
AMIとスナップショットの違いについて調べた

日頃あまり意識していなかったのですが、AMIとスナップショットの違いについて調べました。

## 当初の理解
- スナップショットは特定のEC2のデータを **全て** どこかにコピーしたもの
- AMIはEC2インスタンスを作る時に選択できるOSイメージ

## 疑問
1. スナップショットが特定のEC2のデータを **全て** 含むものだとしたら、スナップショットメニューからAMIを作成する際に何故カーネルIDを指定する必要があるのか

　以下スナップショットからAMIを作る際の入力項目です。
<img width="1365" alt="スクリーンショット 2016-12-03 21.40.12.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/7b7c3e8c-408c-6691-13f9-323a23e99936.png">

2. EC2インスタンスからAMIを作成する場合と、スナップショットからAMIを作る場合で入力しなければいけない項目に違いがあるのは何故か

　以下EC2のインスタンスからAMIを作る際の入力項目です。
<img width="1009" alt="スクリーンショット 2016-12-03 21.42.18.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/af0e6ca5-b136-ec23-c345-05941527d150.png">

3. スナップショットからAMIを作ると、スナップショットが消せないのは何故か

　以下消せない時のエラーです。
![スクリーンショット 2016-12-04 10.10.35.png](https://qiita-image-store.s3.amazonaws.com/0/147387/a4e28de9-3c54-0014-c0fd-6f5ca83b1e2b.png)

## 調べてみた
AMI = インスタンスを構成するメタデータ + スナップショット
スナップショット = (ルートデバイスストレージのデータ + ユーザデータ)を、S3にバックアップしたもの

## 結論
1. スナップショットが特定のEC2のデータを **全て** 含むものだとしたら、スナップショットメニューからAMIを作成する際に何故カーネルIDを指定する必要があるのか
  * スナップショットには「インスタンスを構成するメタデータ」が含まれていないため、EC2インスタンスのデータを **全て** 含むわけではない

2. EC2インスタンスからAMIを作成する場合と、スナップショットからAMIを作る場合で入力しなければいけない項目に違いがあるのは何故か
  * スナップショットには「インスタンスを構成するメタデータ」が含まれていないため。

3. スナップショットからAMIを作ると、スナップショットが消せないのは何故か
  * AMIはスナップショットに依存するため。

## さらなる疑問
1. 何故スナップショットにメタデータが含まれないのか
2. メタデータってどんな情報か
3. スナップショットからAMIを作成する時にカーネルIDを指定できるようにしている理由
4. スナップショットはS3にバックアップするということだが、どのバケットにあるのか

このあたりは別の機会に調べてみようかと思います。
大規模SIでSPAをあきらめた話と同時並行開発について

シングルページアプリケーション（SPA）は、いま注目を集めているWebアプリケーションのアーキテクチャです。  
vte.cxでもSPAを推奨しており、ReactやAngularなどを自由に使用することができます。
実際にAngularJSで構築した事例もあります。  

しかし、大規模プロジェクトにおいてSPAを採用す場合にはよく考える必要があると思っています。

今年、ある大規模プロジェクト（開発者50人以上、1年間）に携わったのですが、SPAを採用することはどうしてもできませんでした。

今日はこの話をしていきたいと思います。

#一応、様々なフレームワークを検討してみた

Reactは個人的に興味のあるフレームワークで、ぜひ使ってみたいと日頃から考えてはいますが、デザイン(HTML、CSSを含む）を別会社に外注しているので無理でした。別会社にJSXを書いてとは到底いえません。

AngularJSであれば実績もあったので提案すれば採用されたかもしれません。
しかし、私はそれも提案しませんでした。  

それは、よくいわれるSEOの問題じゃなく、主に学習コストの理由からでした。

 * 開発者のスキルがそれほど高くなく、SPAの開発経験者もいなかった
 * 第一次フェーズの納期が数ヵ月と短かった
 * シングルページを複数人が共有して開発する方法がわからなかった

#新技術はリスク要因として捉えられることもある

エンタープライズな案件で優先されるのは納期と品質です。
世の中を見てもSPAの大規模な事例は少なく、数人で数ヵ月とか、それぐらいの規模がほとんどです。
数人ならまだしも何十人もの開発者をゼロから教育する余裕はありません。
一番恐れたのは新しい技術を消化できずに手が止まってしまうことでした。
十分な開発期間があり、新しい技術に精通した技術者がいて、常にフォローしてくれるような環境であればまだ考える余地はあったかもしれません。しかし、開発期間は数ヵ月しかありません。フォローできるスペシャリストもいません。
納期を考えると、新しい技術のメリットを取るよりも新たなリスク要因を排除すべきだと思いました。また、同じ理由でTypeScriptも、ES2015やES2016+も採用していません。

#jQueryで普通のWebアプリケーションという選択肢

開発者の皆さんは、jQueryであれば経験があるといいます。ここはオーソドックスにjQueryを採用するしかありませんでした。
つまり、SPAをあきらめ、普通のWebアプリケーションにせざるを得なかったのです。
(つД｀)・ﾟ

jQuery不要論が叫ばれているのは知っています。
多分、それはエンタープライズの現場を知らない人がいっているのでしょう。まだまだjQueryは必要なのです。今は2016年です。  

異論のある方は、まず[2016年にJavaScriptを学ぶとこんな感じ](https://medium.com/japan/2016%E5%B9%B4%E3%81%ABjavascript%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%A8%E3%81%93%E3%82%93%E3%81%AA%E6%84%9F%E3%81%98-b969f5767d7c#.8y7aj93br)を読んでみてください。

>バックエンドに戻ることにするよ。こんなに多くの変更やバージョンやエディションやコンパイラやトランスパイラを僕には扱えないよ。こんなのにずっとついていくなんて考えられないよ、JavaScriptのコミュニティは狂ってる。

それでも反論できる者のみ石を投げてください。
ちなみに、vte.cxでは、npmとgulpは使っています。

#いかに並行に開発して生産性を高められるかの方が重要

一方で、開発者にいかに効率よく作業してもらうかが重要になります。
短納期ですが人数はたくさんいるからです。

SPAを諦めたおかげで画面単位に分けることは簡単にできます。
なので、ここはシンプルに画面単位で担当割りをすることにしました。

それに、SPAではないものの、サーバはAPIを提供する疎結合なアーキテクチャーになっています。つまり、サーバ側では画面のレンダリングを一切行わず、静的なコンテンツを返すか動的なデータをAPI経由で返すだけです。
各画面担当者はクライアント側だけで実装できるため、他の画面担当者のことを気にせず並行で開発を進められます。

ところで、今回、採用してよかったと思ったのはGitlabです。
各担当者がfeatureブランチを切り、テストが終わったものをdevelopブランチにマージ、リリースはmasterブランチから行うという、いわゆるgitフローが徹底されるようになりました。

このgitフローによって、複数人による同時並行開発が混乱なく進められたのは大きかったと思っています。

#vte.cxによる並行開発の実際

ただ、サーバ側のAPIがFIXできていないといろいろと問題になりますし、各自が自由にAPIにアクセスできる開発環境も用意してあげないといけません。

そこで、vte.cxの登場です。

vte.cxではマルチテナントになっており、各自が独立したサービスを立てることができます。また、サーバサイドJavaScriptによりAPIのモックを作成できます。
vte.cxでは、HTMLやCSS、JavaScriptといったフロントエンドのコードと一緒に、サーバのコード(JavaScript)も同時にDeployします。実体は/serverフォルダにJavaScriptファイルがあるだけです。

一方で、フロントエンドのローカル開発環境では、いちいちサーバにデプロイする必要はありません。gulp serveコマンドでローカルproxy環境を起動するだけです。
APIはproxyによりリモートサーバのモックAPIにつながるので、サーバサイドの本番環境と同じ動作を期待できます。
フロントエンドの画面ではJavaScriptでモックAPIに対してリクエストするように実装していきますが、フロントエンドのローカル環境では手元のJavaScriptなどを更新したらすぐに画面を確認できるのでサクサク開発できます。実際の開発については、[【vte.cx入門】2.ローカル環境でHTMLを編集する](http://qiita.com/takeyama/items/b849162b2d2bcc517a1f)を参照してください。

これは、RailsやPHPなどのサーバサイド言語を使わないで、APIモックだけで開発できるvte.cxの環境だからこそ実現できる世界です。

この高い生産性、サクサク感に慣れたらもう元には戻れません。

ということで、また明日。:relaxed:
homebridge-irmagicianを作りました

おうちハック Advent Calendar ２０１６ ５日目のエントリーです。よろしくお願いします。
大宮技研さんから出ている学習型リモコン irMagician の homebridge プラグインを作成しました。[irMagician](http://qiita.com/tags/irMagician) と [homebridge](http://qiita.com/search?q=homebridge) についてはこれまでに書かれた記事が詳しいかと思います。

![IMG_0015.PNG](https://qiita-image-store.s3.amazonaws.com/0/29554/5f7b7e03-f0b5-9b16-47bf-9d8fdb65ac41.png)

> homebridge-irmagician
> https://www.npmjs.com/package/homebridge-irmagician

今まで irMagician を homebridge で温度取得をする際は、cliツールを使って cron で定期的に温度をファイル保存して homebridge-temperature-file で読み込ませていました。 個人的に温度はリアルタイムで取得したいと思い homebridge-irmagician を作りました。

# できること
- 温度の取得
- ~~赤外線の送信~~(未実装)
- ~~赤外線の受信~~(未実装)

# インストール

```
$ npm install -g homebridge-irmagician
```

## raspberry pi の場合
インストール出来ない場合は上記のコマンドに`--unsafe-perm`オプションをつけて下さい。
あとは一日目を担当されていた tamaki さんのNode.js製プラグイン [irMagician](http://qiita.com/tamaki/items/f4127249ec211f7d70cd) を Node モジュールとして使っているのでインストール後に以下のコマンドを実行して下さい。

```
$ cd /usr/lib/node_modules/homebridge-irmagcian/
$ npm rebuild serialport --build-from-source
```

# 使い方
homebridge の config.json に設定します。

```
"accessories": [
    {
        "accessory": "irMagician",
        "name": "温度",
        "type": "temp"
    }
]
```

homebridgeのログ。こんな感じで温度取得が出来るようになります。
![12月-04-2016 22-35-10.gif](https://qiita-image-store.s3.amazonaws.com/0/29554/fa8bfccc-6bb1-436d-2b7e-190869e18271.gif)


# 今後やりたいこと
赤外線の送受信については、記事の公開に間に合わなかったので未実装です。。
追って実装しようと思ってます。プルリクエストもお待ちしています！

>jaxx2104/homebridge-irmagician
>https://github.com/jaxx2104/homebridge-irmagician
オープンソースソフトウェアを利用した開発作業の一端をご紹介

# はじめに

（以下は、会社を代表するものではなく、個人の意見です。）

筆者は会社にて、ソフトウェア開発および保守作業を行っています。

オープンソースソフトウェア（以下、OSS）を利用した作業は平時行っていますが、過去に非常に特徴的(と思っている)な作業を行いましたので、この場にてご紹介します。

内向け外向け問わず、共有フォルダの.txt、.docx、.xlsxファイル以外の情報発信について、筆者の周りで理解されることはとても少ないです。このような場があることを大変嬉しく思います。

# まとめ

* 利用しているOSSにおいて、`メソッドが見つからないエラー`が突然発生する事例が何度も発生していました。
* ソースコードを追いかけた結果、マルチスレッドに関するバグで、排他漏れのため、あるスレッドがメソッドを定義したつもりでも、他のスレッドからはスレッドが定義されていないと見えるバグでした。
* 回避する修正を行った後、__「他にも同様の問題がないのか？」__ という話になり、探してみることになりました。
* 類似の問題を検出し、さらに別の問題も解決する糸口が得られました。
* 方々からのプレッシャーにめげそうでしたが、諦めなくてよかったです。

# 肝心のバグ

* 発生頻度: 3〜6ヶ月に一度
* 傾向: 無し、様々な環境の同一プロセス中のコードで発生
* 影響: 普段は動作する処理で突然の `メソッドが見つからないエラー` による処理中断、半端な状態のままになる事象に対し、復旧に時間がかかりました
* 実際の処理: [このメソッド](https://github.com/rails/rails/blob/2-2-stable/activerecord/lib/active_record/attribute_methods.rb#L232)

自宅でも職場でも穴が開くほど見つめてわかりました。。。

その後は __.xlsxファイル__ にフローチャートを書き修正の論理を説明。規則に則り社内手続きを行って修正をリリースすることができました。

その過程で利用しているOSSで他にも問題がないのか、というご意見を賜りました。そのため、類似の問題を調べる作業が始まりました。
# バグを探す方法

* githubやcodehauseのissueをマルチスレッド関連のキーワードで検索
 - プロジェクトで利用しているバージョン〜最新のバージョンを対象に
 - githubはAPIを使い楽をしました
* ヒットしたissueの内容を確認
 - 修正の背景
 - 修正されたソース

# 怪しいバグが見つかった場合

* 携わっているプロジェクトにおける発生有無を検証。(時間をかけても出ないこともあると考えており、若干打ち切りましたが・・・)

# 調査対象

* サーバサイドで利用していたOSS 25個
* issue累計: 1152件
* マルチスレッドに関連しそうなもの: 108件
* プロジェクトにおいて発生するもの: 1件

# その後の作業

検出した問題について、修正をリリースしました。お客様や、他部署によるテスト環境で発生する前にリリースできたのは、非常に珍しく、また喜ばしいことでした。

# オチ

冒頭に記載したマルチスレッドに関するバグですが、実はしっかり[issueが発行されていました](https://github.com/rails/rails/issues/5967)。プレッシャーに追われた中だと見逃してしまったようです。プロジェクトで使用しているバージョンより新しいバージョンでのissueを見つけたから、使っている古いバージョンのソースにもバグがあるかも、と考えていくことは有事の際だと、できませんでした。

ノーメソッドエラーイミワカラナイよ。

問題に直面したときは、しっかりissueを確認するべきですね。そしてソースコードも。慌てたりプレッシャー、ダメ、ゼッタイ。

# 副産物

同時期にもう１つ、__2つのスレッドがハングする__ という別事象が発生していました。こちらも再現せず、特に傾向もなく、あちこちで発生していました。

諸々のissue調査の後、たまたまハング事象が再発しました。今回は始めからマルチスレッド関連と(根拠もなく)疑ってかかり、複数の環境で再現テストを行いました。

1. Windows2008(スペックの低い仮想マシン、2コア
2. Windows7(スペックそこそこ、8コア
3. CentOS(スペックの低い仮想マシン

2の環境で再現。偶然にも止まった箇所は、`メソッドが見つからないエラー`を出していたメソッドでした。後は[jstack](https://docs.oracle.com/javase/jp/6/technotes/tools/share/jstack.html)やら[visualvm](https://visualvm.github.io)を使ってJavaVMを覗いたところ、根本の原因は異なっていました。まさか古いJRubyのマルチスレッド関連バグにぶち当たるとは。。。先の修正にて発生しなくなることも確認できたので、無事解決となりました。


思い返すと、ずっと1、3の環境を利用していたので、`メソッドが見つからないエラー`も含め、全く再現しなかったのかと感慨深くなりました。

# 所感

突然発生する `メソッドが見つからないエラー` 、再現しないのでお手上げ、と諦めず数年に渡り(他のこともしてます)調べ続けていたから、この問題もなんとか解決できたなぁ、、、とホッとしたことを覚えています。

気軽に「回避する処理入れたらいいじゃない」と言われても、「どこで発生するのかわからないんです！」と叫びたい、「宇宙線の影響でメモリがおかしくなったことにしたい」そう思っていたことも、何度もありました(してません。

各所にご迷惑をかけ、`早く解決してね`という状況が何度も発生していたので、本当に、、、、良かったです。

# 余談

利用しているOSS、常に新しいバージョンを使っていたら問題の発生そのものを抑えられていたのは間違いありません。類似のバグ探しも、新しいバージョンを使っていけばそもそも不要だと論ずることもできます。ですが、そうすると新たなリグレッションの可能性や非互換などの可能性もゼロとは言い切れないため、なかなか難しい側面があります。

周囲を観測している限りでは、古い(枯れた、とよく呼びます)OSSを使うことが多いと思います。
しかしながら、比較的新しかったり、最新の技術・OSSを採用し、大規模な開発へ挑戦しているケースもございます。
日々、色々な希望と危機感とを持って開発、保守作業を行っております。

このような場をきっかけとして、様々な情報発信や共有が行われていくことになれば幸せと思います。今後とも皆様にはご指導ご鞭撻賜りますよう宜しくお願い申し上げます。
TouchBarはいいぞ！（おまけつき）

※この記事は「[AltPlus Advent Calendar 2016](http://qiita.com/advent-calendar/2016/altplus)」の5日目の記事です。
※そしてTouchBarタグ最初の記事ですw(察し)

はい！皆さんこんにちはこんばんは kotamat です。

いきなりですが、TouchBar使ってますか？エンジニアなら**当然**使ってますよね？
まだTouchBar搭載のMacBookPro買ってない方は、Xcodeの最新版でシミュレーションできるので、この記事読んだらすぐ起動してください。
Windows使っている人はしらね。他のOSのひとはお仕事お疲れ様です。

...さてさてポジショントーク(?)はこの辺にして、買い渋っている皆さんのためにTouchBarの素晴らしいところを挙げていこうと思います。

## 純正のアプリなら対応している！

Macって純正のアプリが幾つかプリインストールされています。このアプリでTouchBarが使えるんです！すごいでしょ？

## 音量とか光量とかニョロっと変更できる！

今までって、専用のキーボードを何回か押して変更していましたよね。これがTouchBarを使うと、こう、***ニョロ***って。

![IMG_2001.gif](https://qiita-image-store.s3.amazonaws.com/0/18556/4c3a9a5e-f1f3-54ed-ae6d-8eb0b6d5e895.gif)


## Siriがより身近な存在に！

一番右に丸い謎の画像があるのですが、これを押すと”ピピッ”っていってしばらく放置しておくと「すみません、聞こえませんでした。」と言ってきてくれます。

## 指紋認証できます！

皆さん指紋ありますか？ある場合はこの機能がつかえます！一番右の黒いところを登録した指で押すとPCの起動時のパスワードを入力せずにログインできたりします。

## 自分でもつくれます！

自分が作成したMacOS用のアプリに対してTouchBarの機能を実装することができます。

はい、皆さん、買いたくなったでしょう？
ん。魅力が伝わらない？
そんなあなたのために特別にアプリを作りました。

# slコマンド for TouchBar

(多分ここからメイン)
slコマンドをTouchBarで実装しました。
https://github.com/kotamat/sl


## 背景

slコマンドとは。 [Wikipedia](https://ja.wikipedia.org/wiki/Sl_(UNIX))

>　slはUnix系オペレーティングシステム (OS) のコマンドの一つ。コンソール画面をアスキーアートで描かれた蒸気機関車 (SL) が走り抜ける。

はい、蒸気機関車が走るんです。黒い画面の上を。
ここでお気づきの方もいらっしゃるのではないでしょうか。
今までのslコマンドには弱点がありました。
それはターミナルは通常そんなに横幅長くないので**駆け抜けてる感に欠ける**というものです。
しかし、TouchBarの最大の利点は**横に長い**。
つまり、TouchBar上で蒸気機関車が走れば、より蒸気機関車閲覧体験が向上するのです。
このような需要を満たすツールとしてTouchBarは非常に有効なのです。

## 動作フロー

動作フローは至ってシンプルです。

1. ターミナルに`sl`と打つ
2. `alias sl=open sl.app`と定義しておくことで、sl.appを起動
3. sl.appはTouchBarに蒸気機関車を描画
4. 描画が終了するとsl.appは強制終了

## 実行環境

**TouchBar**の入っている端末であればなんでもOK。もし無いならお近くのAppleStoreへ。

## デモ

![IMG_1999.gif](https://qiita-image-store.s3.amazonaws.com/0/18556/de1d144d-2450-24c4-d566-95c60a8f9e0c.gif)

# まとめ

- TouchBarいいぞ！
鍵の管理にはtrezorを使おう

# 読み方

* トレザー

![carousel_2.png](https://qiita-image-store.s3.amazonaws.com/0/9834/33c6437f-93e0-aebe-ddb1-faea8c2be061.png)

# trezorの特徴

* USBで接続、ブラウザやライブラリ(js,python)で扱える
* 電子署名を行うための専用チップがあり、チップ内に秘密鍵を内蔵し、耐タンパー性があり安全性を担保している
* 秘密鍵をニーモニック※1の形で磁気データ以外の形でバックアップできる（石板に刻むとか）
* ビットコイン以外にも使える、開発元はいろいろ応用例を模索しているようだ。FIDO U2Fに対応しているのでUSB認証デバイスとして使える
* SSHの鍵としてもあつかえる

※1 [ニーモニック（BIP39）](http://qiita.com/you21979@github/items/20391033f74cfa0a16d1)

# 普段使いのウォレットとして安全なWEBウォレット

https://wallet.mytrezor.com

* 秘密鍵をPCで直接扱わない
* 送金以外はtrezor無しで扱える
* 送金時に内容を確認できる

# 送金しない時はandroidのウォレットを使う

https://play.google.com/store/apps/details?id=com.mycelium.wallet&hl=ja

* myceliumと言うウォレットを使うとtrezorの公開鍵を使って受け取りだけに使えるウォレットが作れる
* 送金できないが着金はリアルタイムに確認できる

# trezorを扱うためのライブラリ

* エンジニア向けにライブラリも用意されている
* ビットコイン以外にも使える

https://github.com/trezor/trezor.js

https://github.com/trezor/trezor.js/blob/master/API.md

* ビットコインだけでなくEtherも扱える
* ウォレットさえあればlitecoinやdash、zcashも扱えるようだ

# U2F

firmware 1.4.0から二段階認証用のデバイスとして使える

* gmail
* google drive
* github
* gitlab
* dropbox

https://blog.trezor.io/secure-two-factor-authentication-with-trezor-u2f-e940fd5a60af#.xzewe5ftu

## U2Fでmacやlinuxのログインデバイスとしても使える

https://blog.trezor.io/trezor-u2f-login-into-your-mac-os-x-9fdd808b0aa4#.7xrwcdg70

https://blog.trezor.io/trezor-u2f-login-into-your-linux-mint-bd3684d4a8ba#.1yba7bomp

# ssh-agent

* https://github.com/romanz/trezor-agent

trezor-agentを使うとtrezorの秘密鍵を利用してssh公開鍵を生成できる
この公開鍵をサーバーへ登録することでsshを利用してログインできる

![sshtrezor.png](https://qiita-image-store.s3.amazonaws.com/0/9834/45241f64-38b6-90d7-0d9c-c66604681090.png)

画面に接続先の名前とuser名を確認できる
confirmのボタンを押して初めてサーバーにログインできる

* sshも扱えるということはgpgのサインにも使える

# 総括

trezorはシードとなる鍵から各アプリケーションごとの秘密鍵や公開鍵を生成するのでシードとなる鍵をバックアップしておくことで無くすことがない
バックアップも単なる文字の集合なのでメモ書きするなり石版に刻むなり安全な方法で一括してバックアップがとれる。
リカバリが容易なのでみんな使おう。