OmniAICreator/Qiita-1.07M huggingface dataset:
あなたのエンジニアレベルならどれを選ぶ？WEBサイトを公開する４つの方法

#前書き
**エンジニア**と言っても、フロント、サーバー、バックエンドなどなど、、、、etc
いろいろな専門があり、近年は各々でできる領域が増え、フルスタックエンジニアなるものまででてきました。

そんな中ですが、、、あなたはエンジニアとして、どの程度までできますか？
そんなふとした問いかけみたいなものです。

(追記 2017/4/14)
コメントでもご指摘ございましたが、少しフロントエよりの見方になっているかもしれません。それを踏まえてお読みください。

#WEBサイトの公開レベル
##レベル1 ☆ [ペライチ](https://peraichi.com/)
コードが書けなくてもサイトが公開できるレベル

###【必要工程】
使い方通りにボタンをぽちぽちすればok

###【考察】
え？コードが書かないんだったらエンジニアじゃないって？紹介すんなって？
確かにそうなんですが、、、、が**プレミアムプラン**という有料プランにすると、``html``,``css``,``javascript``を追加してカスタマイズできます（ただしがっつりは無理な模様）


##レベル2 ☆☆ [GitHub Pages](https://github.com/)
``html``,``css``,``javascript``が書け、基本的なTerminalの操作ができるレベル

具体的には、[GitHub](https://github.com/)のリポジトリに``html``,``css``,``javascript``を配置することで公開することができます

###【必要工程】
- GitHubアカウント作成、リポジトリの作成
- WEBページ作成(html,css,javascript)
- Gitの操作およびGitHubへのPush

###【考察】
Webページが作れる(html,css,javascript)かつ**Gitの操作**が必要になる。
エンジニアとして会社で何かしらの言語を書いていれば、GitやSVNなどのバージョン管理ツールには当たり前に触れるため抵抗なくできそうである。terminalこと黒画面には初見だと抵抗が多く、趣味レベルで行っている人はこの段階までいければ十分ではないだろうか。

####参考
[GitHubでWebサイトを公開する](http://qiita.com/kouh/items/1f5d93c85871ed6cd26e)

##レベル3 ☆☆☆ [Firebase Hosting](https://console.firebase.google.com/)
``html``,``css``,``javascript``が書け、Terminalでの操作に抵抗がないレベル

具体的には、[Firebase](https://console.firebase.google.com/)のホスティングサービスを使うことでサイトが公開できます

###【必要工程】
- Googleアカウントの作成
- GoogleアカウントでFirebaseにログイン、プロジェクトの作成
- Node.jsのインストールし、Firebaseのツールをインストール
- WEBページ作成(html,css,javascript)
- Gitの操作およびFirebaseへのデプロイ

###【考察】
作成したページをアップできるようにするまでの、Firebaseに関する設定がめんどくさい。
特に**Terminalによる黒画面**と**英語**を相手にすることになるので、その辺に抵抗がなければ問題ない。
最初がめんどくさい分、Firebase付属のデータベースを使用でき、その他にアナリティクスやクラッシュレポートなど様々な機能を使用できる。

####参考
[Firebaseの始め方](http://qiita.com/kohashi/items/43ea22f61ade45972881)

##レベル4 ☆☆☆☆ [Heroku](https://www.heroku.com/)
フロント側・サーバー側どちらも書くことができ、基本的なTerminalの操作ができるレベル

具体的には、フロントエンド・サーバーサイドのどちらも製作し、[Heroku](https://www.heroku.com/)にデプロイすることで公開できます（サーバー側はHerokuの対応している言語である必要があります）

###【必要工程】
- Herokuのアカウント作成、プロジェクト作成
- TerminalでHerokuのツールをインストール
- WEBページ作成(html,css,javascript)
- サーバー側の作成(Java,Perl,PHP,Ruby,Python,Nodeなど、お好きな言語で)
- Gitの操作およびHerokuへのデプロイ

###【考察】
Terminalで操作するだけで、案外やっていることはGitHubのWebページ公開と変わらない。
しかし、Herokuで公開するための環境設定であったり、Heroku上でうまく動作しない場合の対応、データベースとの絡み、なによりサーバーサイドからフロントまで全てを作らなければいけないという大変さがある。

####参考
[Heroku初心者がHello, Herokuをしてみる](http://qiita.com/Arashi/items/b2f2e01259238235e187)

#あとがき
個人的な勝手な格付けです（偉そうにすいません）
使ったことあるものしか載せてないのでこんなのあるよ！ってのあればどんどん教えてください！追加します！
できれば説明とかあるとたすかります、、、

個人的にはAWSが有料で手を出していないので、どのラインなのかわかっていません、教えてください泣
CowboyのHelloWorldまで

### この記事について

素の状態からcowboyでhello worldを返させるまでのメモ。

### 環境構築
環境構築は都度やっているとハマりそうなのでvagrantを使用。
https://github.com/lau/vagrant_elixir

### ベース部分の作成
`mix new —sup hello_world`を実行。
これによって、cowboyを載せるための土台が作成される。

### cowboyを導入

cowboyを使うことを明示するため、mix.exのapplicatio関数とdeps関数を下記のように書き換え。

```exs:application
def application do
  [applications: [:logger, :cowboy], # ← `:cowboy`を追記
   mod: {HelloWorld, []}]
end
```


```exs:deps
defp deps do
  [
    {:cowboy, github: "ninenines/cowboy"}, # ← 追記
  ]
end
```


`mix deps.get`を実行し、

### ハンドラを追加

実際にアクセスした時に、どのようなものを返すかを定義するhandlerを追加。
ここではplain-textを返すようにする。

`cowboy-trial/lib/hello_world/handlers/hello_world_handlers.ex`を追加し下記のように編集。

```hello_world_handlers.ex
defmodule HelloWorld.Handlers.HelloWorld do
  def init(req, opts) do
    req2 = :cowboy_req.reply 200, %{"content-type" => "text/plain"}, "Hello World", req
    {:ok, req2, opts}
  end
end
```

https://github.com/colorbox/cowboy-trial/blob/master/lib/hello_world/handlers/hello_world_handlers.ex

### ルーティング追加

`cowboy-trial/lib/hello_world.ex`を編集する


```hello-world.ex
defmodule HelloWorld do
  def start(_type, _args) do
    import Supervisor.Spec, warn: false

    dispatch  = :cowboy_router.compile routes
    {:ok, _} = :cowboy.start_clear :http, 100, [{:port, 4000}], %{:env => %{:dispatch =>  dispatch}}

    children = [
    ]

    opts = [strategy: :one_for_one, name: HelloWorld.Supervisor]
    Supervisor.start_link(children, opts)
  end

  defp routes do
    [
      {
        :_,
        [ {"/hello-world", HelloWorld.Handlers.HelloWorld, []} ]
      }
    ]
  end

  def hello do
    :world
  end
end
```
https://github.com/colorbox/cowboy-trial/blob/master/lib/hello_world.ex

### 起動して確認
下記コマンドで起動。
http://localhost:4000
にアクセスして`Hello World`と出力しているかを確認する。

---

参考
[cowboy2とectoでRESTサーバ - Qiita](https://qiita.com/p-baleine@github/items/0a3c5aec222000e44f69)
[ElixirからCowboy 2.0を使ってみる Part 1 - Qiita](https://qiita.com/hayabusa333/items/f5a1ab7a2121579ead25)
配列の要素を指定位置に移動させる

配列内の要素を指定位置へ移動させる
D&Dで要素を並び替えした時にデータを保存してあるcollectionに対してよく使うのでメモ

```js
function moveAt(array, index, at) {
    if (index === at || index > array.length -1 || at > array.length - 1) {
      return array;
    }
    
    const value = array[index];
    const tail = array.slice(index + 1);

    array.splice(index);

    Array.prototype.push.apply(array, tail);

    array.splice(at, 0, value);

    return array;
  }
```

## 実行結果
```js
  function fruitsMove(index, at) {
     const fruits = ['apple', 'banana', 'grape', 'orange', 'peach'];
     
     moveAt(fruits, index, at);
     
     console.log(fruits);
  }
   
  // 'apple' を fruits[1] へ移動
  fruitsMove(0, 1) // => ["banana", "apple", "grape", "orange", "peach"];
  
  // 'peach' を fruits[1] へ移動
  fruitsMove(4, 1); // => ["apple", "peach", "banana", "grape", "orange"]
  
  // 'apple' を fruits[4] へ移動
  fruitsMove(0, 4); // => ["banana", "grape", "orange", "peach", "apple"]
  
  // 'peach' を fruits[0] へ移動
  fruitsMove(4, 0); // => ["peach", "apple", "banana", "grape", "orange"]
```
Windows + IntelliJ + Gradle


# はじめに

Windowsでチーム開発することになりました。
せっかくなのでまとめて共有できるようにします。
記事を書いてる環境はMacOSになります。

# 想定とか

バージョン管理：Gitlab
開発端末：Windows10
IDE:：Atom, IntelliJ IDEA
ビルドツール：Gradle
開発言語：Java8
RDB：Oracle

# Setting

## 1.先行着手-インストール

ひとまず開発端末にJavaの開発環境を整えます。
1. OracleよりJdkをダウンロード&インストールし、Javahomeに設定する。
2. Jetbrainsより「IntelliJ IDEA CE」をダウンロード&インストールする。
3. Gradleをダウンロード&インストールする。
4. IntelliJを起動し、Gradleプロジェクトを作成する。
5. IntelliJにGitlabプラグインをインストールする。

## 2.先行着手-開発準備

Gradleプロジェクトをカスタマイズして、バージョン管理に乗せます。
1. 作成したプロジェクトから、IntelliJの「ターミナル」を起動し、「gradle wrapper」を叩く
2. build.gradleに依存関係を追加する。(lombokとか、jdbcドライバとか、FWとか)
3. IntelliJの設定で、アノテーションを許可する。
4. BuildSuccessを確認した後、Gitlabへプロジェクトをpush(ここらへんまだ不明)

## 3.後発-インストール

開発端末へJava等の準備をした後、Gitlabよりpullする
1. OracleよりJdkをダウンロード&インストールし、Javahomeに設定する。
2. Jetbrainsより「IntelliJ IDEA CE」をダウンロード&インストールする。
3. IntelliJにGitlabプラグインをインストールする。
4. IntelliJよりGitlabからプロジェクトをpullする(ここらへんまだ不明)
5. インポートしたプロジェクトから、IntelliJの「ターミナル」を起動し、「gradlew」を叩く

# IntelliJ IDEA

日本語化にPleiades.jarが使える模様

# 進捗状況とか
現在＃2.1までしか進んでないので、それ以降は妄想となっております。
実際手を動かしてみて、問題なければ加筆していこうかと思います。
retryするデコレータ

失敗してもretryするデコレータを書いてたら、頭の体操みたいなコードができました。
機能要件は、試行の最大回数と試行の時間間隔をデコレートするときに指定できるように…

それから、下記のコードはf文字列を使っているので python3.6+です。

```python
from functools import wraps
from time import sleep, time

def retry(count=0, delay=0):
    def _retry(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            _delay = delay
            _time = time()
            for c in range(count):
                print(f'time: {time()-_time:.1f}')
                success = func(*args, **kwargs)
                if success or c == count-1:
                    break
                sleep(_delay)
                _delay *= delay
            return success
        return wrapper
    return _retry

try_count = 0
@retry(count=3, delay=1.5)
def unstable_func(threshold):
    global try_count
    try_count += 1
    print(f'try count: {try_count}')
    return True if try_count > threshold else False

if __name__ == '__main__':
    print(f'unstable_func is {"succeeded" if unstable_func(3) else "failed"}')
    print()
    print(f'unstable_func is {"succeeded" if unstable_func(3) else "failed"}')
```

実行結果は

```sh
time: 0.0
try count: 1
time: 1.5
try count: 2
time: 3.8
try count: 3
unstable_func is failed

time: 0.0
try count: 4
unstable_func is succeeded
```

実際に使うときは、ちゃんとしたライブラリを使いましょう！

- [pypi/retry](https://pypi.python.org/pypi/retry/0.9.2) → ドキュメントが簡潔。
- [pypi/retrying](https://pypi.python.org/pypi/retrying/1.3.3)  → 機能豊富な感じ。
Prefab内でGizmoの選択をいい感じにする

## 要旨

結論だけ言うと`SelectionBaseAttribute`をつけろです。

## 問題

OnDrawGizmosでギズモを描画する場合通常はそのギズモをクリックすると対象のオブジェクトが選択されます。
例えば

```csharp:GizmoTest.cs
using UnityEngine;
using UnityEditor;

public class GizmoTest : MonoBehaviour {
	void OnDrawGizmos () {
		Gizmos.color = Color.red;
		Gizmos.DrawSphere(transform.position, 1);
	}
}
```

というコードがあり、

![u1.PNG](https://qiita-image-store.s3.amazonaws.com/0/199/d8cdac1a-cb2a-3a9c-ce59-7c28b7945f10.png)

でChildGizmoについてるとします。
この状態でsceneビューで赤い球をクリックするとChildGizmoが選択されます。

しかしここでParentをプレハブにしてみると、赤い球をクリックした時にParentが選ばれるようになってしまいます。
これはプレハブの[仕様](https://docs.unity3d.com/ScriptReference/SelectionBaseAttribute.html)でプレハブ内のオブジェクトを選択するとプレハブのルートのオブジェクトが選ばれるようになっているためです。
この仕様自体知らなかったのとGizmoが絡んでいてGizmoのせいだと思っていたのでかなりハマってしまいました。

さて結論でも述べましたが、これを回避するには`SelectionBaseAttribute`をつければ良いです。

```csharp:GizmoTest.cs
using UnityEngine;
using UnityEditor;

[SelectionBase]
public class GizmoTest : MonoBehaviour {
	void OnDrawGizmos () {
		Gizmos.color = Color.red;
		Gizmos.DrawSphere(transform.position, 1);
	}
}
```

これでプレハブ化した状態でも無事赤い球をクリックした時にChildGizmoが選択されます。
僕はまたAthenaのPartitionで死に申した。

CloudFrontのログ形式が `s3://orenocloudfront.com//ORENOPREFIX.2017-04-10-00.1a2b3c4d5e.gz` みたいになってるとき、 `paritioned by` 句をつけてCREATEしたTableからは何をどうあがいてもデータは取得できません。


https://docs.aws.amazon.com/athena/latest/ug/athena-ug.pdf

```
For the LOCATION clause, using a trailing slash
In the LOCATION clause, use a trailing slash for your folder or bucket, NOT filenames or glob characters. For

example:
Use:
  s3://path_to_bucket/
Don't Use:
  s3://path_to_bucket
  s3://path_to_bucket/*
  s3://path_to_bucket/mySpecialFile.dat
```

`/` 終わりじゃないといけないんだってさ。
S3の `/` はディレクトリじゃないって偉い人がいってたのに！！！！！！！
staticフィールドを@Autowiredの対象にしたい


とりわけユーティリティクラスの設計に際して、staticフィールドを`@Autowired`の対象にしたい場面があります。この場合は__対象のstaticフィールドのsetterを非staticメソッドとして定義し、そのsetterに対して`@Autowired`を付与してやればよい__ようです。以下がその例となります。

```java
public class SampleClass {

    private static StaticField staticField;

    @Autowired
    public void setStaticField(StaticField staticField) {
        SampleClass.staticField = staticField;
    }

}
```

ただし見るからにバッドノウハウなので、上記のようなことを頻繁に繰り返さねばならないようであれば、当該クラスをシングルトンにするなど、設計の見直しが必要になりそうです。もっともそう簡単に設計を見直したりできないのがシステム開発の現実なのですが(´・ω・｀)
Webpackのentryの文字列・オブジェクト・配列指定の使い所


## entry(文字列)の場合

```js
module.exports = {
  entry: "./src/app.js",
  output: {
    path: __dirname + "/dist",
    filename: "app.js"
  },
  ...
```

入門記事ではこんな書き方をしている場合が多い。

### 使い所
学習目的で手軽にコンパイルしたい時。
現実のアプリケーションではコンパイル対象が1ファイルなんてありえない。

## entry(オブジェクト)の場合

```js
module.exports = {
  entry: {
    'user': './src/javascripts/user.js',
    'admin': './src/javascripts/admin.js'
  },
  output: {
    path: __dirname + "/dist",
    filename: '[name].js'
  },
  ...
```

### 使い所
複数ページで起点となるJSを出力できるが、1ページに1ファイルしかコンパイル対象が存在しない小規模なサイトやアプリ開発向き。

[name].jsのnameの箇所にはentryのオブジェクトのキーであるuser,adminが出力される(user.js,admin.jsとなる)

## entry(配列)の場合

```js
module.exports = {
  entry: ['/vendor/jquery.js','./src/javascripts/user.js']
  output: {
    path: __dirname + "/dist",
    filename: 'app.js'
  },
  ...
```

### 使い所
配列で指定したJSを結合して1つのJSとして出力される。
文字列の時と同様に1ファイルしかコンパイル後のファイルが作成できないので、学習向き。

## entry(オブジェクト+配列)の場合

```js
module.exports = {
  entry: {
    'user': [
	   './src/javascripts/user_header.js',
       './src/javascripts/user_sidebar.js',
       './src/javascripts/user_content.js',
    ],
    'admin': [
       './src/javascripts/admin_header.js',
       './src/javascripts/admin_sidebar.js',
       './src/javascripts/admin_content.js',
    ]
  },
  output: {
    path: __dirname + "/dist",
    filename: '[name].js'
  },
  ...
```

### 使い所
実際のWebアプリケーションの開発向き。

複数ページに起点となるJSを出力でき、
各ページでコンポーネント単位に分割したJSを配列指定で結合することが出来る。

## まとめ
Webpackを実務のWebアプリケーションに導入する時はオブジェクト+配列の形式にしましょう。
どんな単位でオブジェクトと配列を分割するかはチーム毎に特色があると思うので、うちはこうしてるよ！とかありましたらぜひコメントください！
[Unity]対象のアセットと依存関係のあるアセットたちを、依存関係含めてまるごとコピーする

所用で表題のようなエディタ拡張が欲しくなったのですが、どうも無さそうな気がしたので作ってみました。
（もしかして、Unity標準の機能でできたりするんだろうか…）

コードはこちら → [Gist - アセットを依存関係まるごとコピーするやつ.cs](https://gist.github.com/k7a/de776fb84ee060385a78505e1c43ed94)
Unity5.3.4p5にて動作確認しています。

- 2017/4/14 更新
  - リファクタ
  - AssetBundle名の変更に対応
  - YAML形式かどうかを拡張子で判断していたのを、ファイルの行頭から判定するように変更
- 2017/4/15 追記
  - やっぱなんかうまく動いてない気がするのでまた見てみます…
- 2017/4/17 更新
  - 正常に動くようになりました

## 何をするためのものなのか

例えば、こんな依存関係のアセットがあるとします

```
# 線は依存関係を示す

AssetA─┬─AssetB
       ├─AssetC
       └─AssetD
```

普通にAssetAを複製すると、こうなる…

```
AssetA─┬─AssetB─┬─AssetA'
       ├─AssetC─┤
       └─AssetD─┘
```

これを以下のように依存関係まるごと複製したいときに使えます

```
AssetA─┬─AssetB
       ├─AssetC
       └─AssetD

AssetA'─┬─AssetB'
        ├─AssetC'
        └─AssetD'
```

## 使い方
コピーしたいアセットをProjectウインドウ上で選択して、コンテキストメニューの**DeepCopy**を選ぶことで実行できます。
コピー後のファイル名は、ファイル名の接尾辞に**2**をつけたファイル名になります。（GUI上で変更可能にしたかったのですが、面倒なのでやめました）
ただ、あんまりテストしていないので、以下に書いてある仕組みを理解できない方は安易に使わないようにしてください。。。
特に、下の懸念点の部分も読んでおいてください。

## 仕組み
ソースを見るとわかりますが、System.IO名前空間を使って直接metaファイルやprefabの値を書き換えたりというなかなかアレな事をやっています。
大まかな流れとしては以下のような感じです。

1. 選択したアセットが依存関係を持つ全てのアセットを取得
2. 上記で取得したアセットとそのmetaファイルを複製
3. 複製後のmetaファイルのGUIDを書き換え
4. 複製後のprefabやanimationが持っている参照先のGUIDを、3で書き換えた複製後のGUIDに書き換え

UnityのmetaファイルとGUIDについての知識があれば理解できるかと思います。
参考: [Unityの.metaファイルに書かれているguidについて - Qiita](http://qiita.com/wordijp/items/3e4b87756fd11c893a9d)

## 懸念点など
あまり使いまわしたりする予定も無いので、結構適当に書いてる部分があります。
~~特に92行目なんですが、上記4.の処理を行うかどうかの判定を拡張子で行っていて、多分この拡張子のパターンだけだと網羅できていない所があると思います。
ここはあまりいい方法が思いつかなかったのですが、なにかいい方法があれば教えてください…~~
→ ファイルの行頭から判断すれば良いというアイデアを貰ったので、採用させて頂きました！

## ハマったポイント

prefabの参照先のGUIDを書き換えた直後、AssetDatabase.ImportAssetをするとどうも書き換えが反映されないままインポート処理が走ってしまうようでした。
全てのファイルを書き換えた後、AssetDatabase.Refleshを走らせることで解決しました。
sympyでcos,sinの連立常微分方程式

sympyでcos,sinの連立常微分方程式
もっと短くなるような気もします。
(参考)三角関数 - Wikipedia＞微分方程式による定義 ?c'=-s,s'=c
https://ja.wikipedia.org/wiki/%E4%B8%89%E8%A7%92%E9%96%A2%E6%95%B0

```python
#sympyでcos,sinの連立常微分方程式
from sympy import *
var('x f g C1 C2')
eq = (Eq(f(x).diff(x),-g(x)), Eq(g(x).diff(x),f(x)))
ans=dsolve(eq)
f=ans[0].rhs
g=ans[1].rhs
dict=solve([Eq(f.subs(x,0),1), Eq(g.subs(x,0),0)], [C1, C2])
f=f.subs( [ ( C1, dict[C1] ), ( C2, dict[C2] ) ] )
g=g.subs( [ ( C1, dict[C1] ), ( C2, dict[C2] ) ] )
print("#f=",f)
print("#g=",g)
#f= cos(x)
#g= sin(x)
```
(参考)連立常微分方程式
http://docs.sympy.org/dev/modules/solvers/ode.html
(参考)sympyのeqの使い方を教えて下さい
https://ja.stackoverflow.com/questions/33961/
firebaseとvue-cliを利用した環境を構築する

# 前提

* Macで環境構築
* npmが入っていること
* FirebaseのHosting機能を利用する

# vue-cliの環境を構築する

```shell
% npm install -g vue-cli
% vue init webpack household_account
% cd household_account
% npm install
% npm run dev
```

# firebaseの利用準備をする

下記URLからFirebaseコンソールに遷移してfirebaseのアカウントを作成する。

https://firebase.google.com/?hl=ja

1. Firebaseコンソール「新規プロジェクト作成」から新規プロジェクトを追加する。
2. 「ウェブアプリに Firebase を追加」を選択し、表示されたscriptタグなどをコピーする(project_rootの`src/firebase.js`などに保存しておく)。
3. 「Authentication」から認証方法を選択する(Google認証、ID・Password認証など選択できる)。
4. 「Hosting」を選択して、画面の手順に従ってFirebase Command Line Interfaceをインストールする(`npm install -g firebase-tools`を実行する)。
5. `firebase login`でログインする(ブラウザでGoogle認証ができる環境が必要。もしサーバ内で実行したい場合には後述するトークンを取得することで対応できるが、最低1回はブラウザで認証させる必要がある)
6. `firebase init`を実行する。`Hosting`→`先程作成したProject名`を選択し、後は適宜選択する。
7. `firebase use --add`を実行する。先程作成したProject名を選択し、aliasを設定する(適当に、staging, develop, production)。
    作成したaliasは、`{project_root}/.firebaserc`で確認できる。

## Firebase Command Line Interfaceの使い方(参考)

```shell
firebaseにログイン
% firebase login

プロジェクトを開始:
% firebase init

アプリの起動
% firebase serve

ウェブサイトをデプロイ
% firebase deploy
```

# vuefireを利用する

`package.json`のdependenciesに以下のモジュールを追加する。

  * firebase
  * vuefire

# デプロイ

```shell
% npm run build
% firebase deploy
```

## ブラウザでGoogle認証できない環境でデプロイをする場合

### トークンの取得

前述のように、`firebase login`などのコマンドを実行するためには、ブラウザ側でGoogle認証を行う必要がある。
サーバ側でデプロイが必要な場合には、ブラウザでの認証ができないので、トークン認証させるためのコマンドを利用すると良い。

但し、認証用のトークンは、ブラウザ側でGoogle認証させないと取得できない。
従って、一旦は、どこかの環境(以下、「ローカル」という)でブラウザでGoogle認証させて認証用のトークンを取得する必要がある。

```shell
local> firebase login:ci

  省略(トークンが取得できる)
```

取得したトークンは以下のように利用できる。

```shell
> firebase deploy --token "トークン"
```

# 参考にさせて頂いたサイト

* http://qiita.com/st5757/items/9e651e8cffaa90681426
* http://qiita.com/567000/items/dde495d6a8ad1c25fa43
生のUI Automationの実行

生の UI Automation が使えるのか気になったので試してみた[^1]。
[^1]: UI Automation PowerShell Extensions に対して「生」と言っている。


下記コードを手元のPowerShell ISEで実行したところ、PowerSehllのコンソールが立ち上がった。

```.ps1
# UI Automation 系の dll のロード
Add-Type -Path "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\UIAutomationClient.dll"
Add-Type -Path "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\UIAutomationTypes.dll"

$UIAElement       = [System.Windows.Automation.AutomationElement]
$UIAChildrenScope = [System.Windows.Automation.TreeScope]::Children
$UIATrue          = [System.Windows.Automation.Condition]::TrueCondition
$UIAInvokePattern = [System.Windows.Automation.InvokePattern]::Pattern

# PowerShell ISE のプロセスを一つ取得
$targetProcess =
    Get-Process powershell_ise |
    Select-Object -First 1

# プロセスからメインウィンドウの AutomationElement を取得
$mainWindow = $UIAElement::FromHandle($targetProcess.MainWindowHandle)

# ツールバーを取得
$toolBar =
    $mainWindow.FindAll($UIAChildrenScope, $UIATrue) |
    Where-Object {$_.Current.Name -eq "ツール バー"}

# ツールバーから「PowerShell.exe を起動」ボタンを取得
$startPowerShell =
    $toolBar.FindAll($UIAChildrenScope, $UIATrue) |
    Where-Object {$_.Current.Name -eq "PowerShell.exe を起動(_H)"}

# ボタンの実行
$startPowerShell.GetCurrentPattern($UIAInvokePattern).Invoke()
```

コードを書けば！ボタンが！押せる！！！
キノコ困った Pepperが突然うんともすんとも

# Pepperが突如動かなくなった
- とあるイベントで急にPepperがシャットダウンし、その後電源すらつかなくなった。。

## 考えられる原因
- 可動域を無理に超えたような操作・モーションの結果ヒューズが飛んだ
- 強制終了ボタンがおされたままになっている

## 対処法
- 充電はできているかを確認し、胸ボタンを長押してみる
- 強制終了ボタンが解除されていることを確認する

## その他
- こういう所もPepperらしさといえばらしさですが、いずれの方法でも修復しない場合は修理ゆうきでしょう。。。
Let's Encrypt を使った SSL 設定 for Amazon Linux


## SSLのサイトを作ってみたくなった

ちょっとした無償サービスを作るにあたって、Let's Encrypt を使った SSL を試しに使ってみたくてやってみました。
環境は、Amazon Linux。

## 手順

```
$ wget https://dl.eff.org/certbot-auto
```
```
$ chmod a+x certbot-auto
```

```
$ ./certbot-auto
(中略)
FATAL: Amazon Linux support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
Alternatively, you can install OS dependencies yourself and run this script
again with --no-bootstrap.
```

Amazon Linux は、--debug をつけろというのでつけました。

```
$ ./certbot-auto --debug
(中略)
The following errors were reported by the server:

Domain: XXX.XXX.jp
Type:   connection
Detail: Failed to connect to XXX.XXX.XXX.XXX:443 for tls-sni-01 challenge
(後略)
```

よくよく調べると以下に該当。

https://letsencrypt.jp/usage/dvsni-challenge-error.html

セキュリティグループに、443を指定するのを忘れていたので指定して、コンソールからインスタンス再起動。

```
$ ./certbot-auto renew
```

インストールが終わったら、httpd を再起動。

```
$ sudo service httpd graceful
```

https でアクセスして完了を確認。

## 参考

https://letsencrypt.jp/
http://qiita.com/takahiko/items/a08895550727b95b6c36
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/SSL-on-an-instance.html#ssl_enable
iframe内の要素にCSSを適用したった

■前提
・jQueryを使う

■手順
①iframeが読み込まれた時にCSSが適用されるようにする(```load```イベント)
②iframe内のCSSを適用したい要素を取得する
③取得した要素にCSSを適用する

■コード

```javascript
$("iframe").on("load",function(){
 $("iframe").contents().find('header').css("display","none");
 $("iframe").contents().find('.selector').css({"margin":"15px","padding":"15px"});
});
```

(参考)
http://www.koikikukan.com/archives/2015/03/03-005555.php
Centos6.7で開発するためにvimを設定する


CentOS上にvimを設定して、快適にrubyやphp、html等のコーディングをするための覚書です。

## vimのインストール
まずは初期インストール状態のものを確認してみます。

```
# yum list installed | grep vim
vim-minimal.x86_64     2:7.4.629-5.el6  @anaconda-CentOS-201508042137.x86_64/6.7
```

vim-enhancedが入っていないので入れます。

```
# yum install vim-enhanced
# yum list installed | grep vim
vim-common.x86_64      2:7.4.629-5.el6_8.1
vim-enhanced.x86_64    2:7.4.629-5.el6_8.1
vim-filesystem.x86_64  2:7.4.629-5.el6_8.1
vim-minimal.x86_64     2:7.4.629-5.el6  @anaconda-CentOS-201508042137.x86_64/6.7
```

## エイリアスの変更
viコマンドでvimを起動できるようにエイリアスを設定します。
※今のCentOSではしなくてもいいような気もする。

```
$ vi ~/.bashrc
最下行に追加
alias vi='vim'
$ source ~/.bashrc
```

## vimrcの設定
.vimrcファイルを作成して、vimの設定をしていきます。

```
$ vi ~/.vimrc
以下内容を記入
set ignorecase "大文字/小文字を区別せず検索
set hlsearch "検索結果をハイライト
set number "行番号を表示
set showmatch "相関するカッコを強調表示
syntax on "シンタックスハイライトを有効に
set tabstop=4 "インデントをスペース4つ分に
```

設定はお好みで。
これだけで結構使える気がします。
swappinessのメモ



swappinessでシステムがスワップする頻度を設定されている。
設定可能な値のレンジは０～１００で
０に近いほどスワップファイルの利用の頻度がさがる

０にすると実メモリを使い切るまではスワップしない。
デフォルトは６０

## 現在値の確認

```sh:
# cat /proc/sys/vm/swappiness
60
```

書き換える方法は２つ
一時的な変更か、恒久的な変更か。

## 一時的な変更

```sh:
# set +o noclobber
# echo 10 > /proc/sys/vm/swappiness
# set -o noclobber
```
OS再起動までは有効。
そのままリダイレクトで書き込もうとすると怒られるので、
上書きできるようにset +o noclobberして終わったら
もどす。

## 恒久的なへんこう

```sh:
# vi /etc/sysctl.conf
~略~
vm.swappiness = 10
```
デフォルトでsysctl.confにかかれてはいないので
適当なところにかく。

反映。

```sh:
# sysctl -p
```

## 今回はじめて知ったこと
swappinessの値を変更しただけでは
スワップの使用率は変わらない。
すでにページアウトしてる子はそのまま。

ページインさせてあげないといけない。

```sh:
#  swapoff -a && swapon -a
```

swapon -sは/proc/swapsと同じ結果

```sh:
# swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       1048572 0       -1
 
# cat /proc/swaps 
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       1048572 0       -1
```


## ちょっと便利だと思ったswapの確認コマンド

```sh:
#grep VmSwap /proc/*/status | sort -k 2 -r | head
/proc/1486/status:VmSwap:            956 kB
/proc/1457/status:VmSwap:            808 kB
/proc/1468/status:VmSwap:            784 kB
/proc/1157/status:VmSwap:             76 kB
/proc/1522/status:VmSwap:             68 kB
/proc/1518/status:VmSwap:             68 kB
/proc/1516/status:VmSwap:             68 kB
/proc/1514/status:VmSwap:             68 kB
/proc/1520/status:VmSwap:             64 kB
/proc/1512/status:VmSwap:             64 k
```

[参考]
http://qiita.com/ikuwow/items/f0b4d1f509a0b83b5d7e
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html
https://oba-q.com/?p=2899
MastodonのAPIをcurlで叩いてみるサンプル

# Mastodon
![s_mastodon.jpg](https://qiita-image-store.s3.amazonaws.com/0/130686/9c532449-47ab-73be-b44e-5b2c616277f3.jpeg)

Mastodon
https://github.com/tootsuite/mastodon
twitter likeなオープンソースのSNS。
誰でもインスタンスを立てることが出来て、インスタンス内のTOOT（twitterでいうtweet）が流れてくるLocal Timelineと、他のインスタンスのTOOTも流れてくるFederated Timelineというのもあります。

# MastodonのAPIをcurlで叩いてみる
とりあえずどこかのインスタンスに登録したら、アプリケーションを登録してclient_idとclient_secretを手に入れます
（インスタンスによってurlは変更する）
（scopesは使う内容に沿って設定する）

```
$ curl -X POST 'https://mastodon.social/api/v1/apps' --data 'client_name=YourApp&redirect_uris=urn:ietf:wg:oauth:2.0:oob&scopes=read'
```


次に、今手に入れたclient_idとclient_secretを使ってaccess_tokenを手に入れます
(client_idとclient_secretは今後も使うので保存しておく)

```
$ curl -X POST -d "client_id=CLIENT_ID_HERE&client_secret=CLIENT_SECRET_HERE&grant_type=password&username=YOUR_EMAIL&password=YOUR_PASSWORD" -Ss https://mastodon.social/oauth/token
```


headerにaccess_tokenをセットすればok

```
$ curl --header "Authorization: Bearer ACCESS_TOKEN_HERE" -sS https://mastodon.social/api/v1/timelines/home
```

詳しいことはdocumentを参照。
https://github.com/tootsuite/documentation/tree/master/Using-the-API

# おわりに
Mastodon今のところ(2017/4/13現在)、twitter黎明期のような感じがして非常に面白いですが、
インスタンスの運営を個人でやってる方が多いので、その辺りはきちんと理解して支援できるところは支援しながら使っていきたいと思います。

追記: scopesに関する記述を追記しました
Ubuntu 16.04 LTSにProVerifをインストールする方法

Ubuntu 16.04 LTSにProVerifをインストールする方法についてまとめます。

#インストール方法
2. [ProVerif](http://prosecco.gforge.inria.fr/personal/bblanche/proverif/)からソースコードをダウンロードします。  
![ProVerif - Mozilla Firefox_020.png](https://qiita-image-store.s3.amazonaws.com/0/52291/e13aad77-2177-c769-045f-92c249f58be5.png)
1. ダウンロードしたtarファイルを解凍します。
2. 端末を起動します。
1. `sudo apt install opam`コマンドを実行し、OCamlをインストールします。
2. 解凍したProVerifのディレクトリへ移動します。
3. `./build`コマンドを実行し、ProVerifをインストールします。
4. `~/.bashrc`の末尾に以下を追記し、PATHが通るようにします。

```bash:追記
export PATH="{ProVerifのディレクトリ}:$PATH"
```

1. `source ~/.bashrc`コマンドを実行し、`~/.bashrc`への変更を適用します。

#関連記事
* [セキュリティプロトコルの形式検証ツール“ProVerif” - Qiita](http://qiita.com/yyu/items/f35f24516fd1776c19d9)  
ProVerifについてまとめられている記事です。
* [Proverifを導入(MacとWindows編) - Qiita](http://qiita.com/tatsuya_ooyanagi/items/682ea27c80bee7c4091b)  
WindowsやMacの方はこちらの記事が参考になるかと思います。

#参考文献
* [User manual](http://prosecco.gforge.inria.fr/personal/bblanche/proverif/manual.pdf)
* [UbuntuにOCamlをインストールする - Qiita](http://qiita.com/KenjiYamauchi/items/40aaab56b65777950877)
Firebase CloudFunctions でパーマリンクを実現する [BitScheduler開発日誌]

BitScheduler開発日誌、５回目です。

今回は Firebase CloudFunctions で HTTP Triggers を使った際のパーマリンクの実装方法です。
CloudFunctions の Requestオブジェクト、Responseオブジェクトは Express のオブジェクトとなっているため、以下のコードで実現できます。

```text:URL
https://us-central1-**********-*****.cloudfunctions.net/groups/hoge
```

```js:コード
// サービスを提供するパスは /groups
exports.groups = functions.https.onRequest((req, res) => {
    // パーマリンク取得。先頭のスラッシュも含まれる
    var subdir = req.path;
    res.status(200).send('<html><body>Your request permalink is ' + subdir + '</body></html>');
});
```

```text:レスポンス
Your request permalink is /hoge
```

開発中の「BitScheduler」ではアカウントごとに発行する識別子をパーマリンクとしてアクセスできるようにしたいのですが、CloudFunctions でも実現できそうです。


## BitSchedulerとは
開発中の出欠投稿サービスです。Googleカレンダーと連携することで簡単に管理、運用できることを目指しています。
ぜひ「いいね」して応援してください！

[BitSchedulerランディングページ](https://bitscheduler-fb66d.firebaseapp.com/)
macOS SierraからPPTPでVPNにつなぐ(無料で)

この記事にたどり着いた皆さんはご存知の通り、macOS Sierraから（OSの機能として）PPTPでのVPN接続が廃止されました。
どうしてもPPTPで接続する必要がある場合、サードパーティーのVPNクライアントを使用しましょう。

Flow VPN Mac Client
https://www.flowvpn.com/download-mac/

このクライアントは「Flow VPN」というVPNサービスが提供していますが、それ以外のVPNにも特に問題なく接続することが出来ます。
今は誰でも無償で使用できますが、ベータ版とのことなので将来的に有償化したりするのかもしれません。

特に難しい設定が必要なわけではありませんが、簡単に使い方を解説します。
（*この記事を執筆したときのバージョンは2.1です*）

<img width="503" alt="スクリーンショット 2017-04-13 19.46.19.png" src="https://qiita-image-store.s3.amazonaws.com/0/11369/4e40fad4-77a4-acb6-fafe-9a64366e08d2.png">
**1. 接続先、ユーザー名、パスワードを入力します**

+ ドロップダウンの内容は無視して接続先のURLを打ち込みましょう。
+ 細かいところですがキーボードショートカットでペーストできません*（右クリックメニューからならできます）*


**2. Connectボタンを押します**

+ 接続する度にパスワードの入力を求められます。
+ わかりにくいですが、「Disconnected」の表示が「Connecting...」に変われば成功です。
+ たまに「Connecting...」と表示されているのに失敗している場合があります。つながらないときはlogボタンから詳細を確認しましょう。
+ 設定が間違ってないのに接続に失敗するケースもあります。クライアントを立ち上げなおしたり接続と切断を繰り返すとうまくいくようです。
PostGIS あるある（備忘録）

## <i class="fa fa-cubes" style="font-size:1em;"></i> はじめに
QGISやArcGISでできることをPostGISでやりたい時、その手順を毎度調査するのですがすぐ忘れてしまいます。よく使うパターンをここにまとめておこうと思いました。
（自分の備忘録的なものです・・・どんどん増やしたいですが、もしかしたら増えないかもしれません）

## <i class="fa fa-database" style="font-size:1em;"></i> 環境
PostgreSQL 9.4.5
PostGIS 2.1.8



## <i class="fa fa-comments" style="font-size:1em;"></i> マルチポリゴンを結合してそのテキスト表現を取得。形状間引いてもいいけど、自己交差は解消して。
```SQL
SELECT ST_AsText ( ST_CollectionExtract ( ST_Multi ( ST_Union ( ST_MakeValid ( ST_Simplify ( geometry, 0.01 )))), 3 )) FROM table;
```
適度にポリゴンを間引き、(ST_Simplify)
間引いたことにより発生した自己交差を解消して、(ST_MakeValid)
結合する。(ST_Union)
出力をマルチポリゴンで統一し、(ST_Multi)
GeometryCollection型が返されたらGeometry型に変換する。(ST_CollectionExtract)
最後にテキスト表現で取得する。(ST_AsText)

## <i class="fa fa-arrow-circle-right" style="font-size:1em;"></i> 参照
[ST_MultiがGeometryCollection型を返したら、Geometry型に変換する](http://qiita.com/doritosist/items/9d8cc75fbf32cb33a754)
タックマンモデル

今日これを読みました。
https://gqjapan.jp/life/business/20160527/team-building

私はこれまでSESでいくらか外に出ていたので、

記事にあるギスギスしてあまり意見が出てこなく進まないことや、

プロジェクト中盤になって急にコミュニケーションが活発になり衝突する。

なんてケースを体験したことがあります。


<br />

プロジェクト発足する際にはふと読んで思い出し、

いかに「混乱期」を抜けるかを考えようと思いました。



書き始めると長ったらしくなるので、是非記事を読んでいただけたらと思います。
wordpress(※ワールドプレスではない)でGoogleタグマネージャーが反映されないっ(汗)と思ったら確認すること

①wordpressダッシュボードを開く
②外観 > テーマの編集
③header.phpにタグマネージャーのコードが記述されているか見る
④header.php意外にheader-rev.phpとかheader-slider.phpとか「header」が付くファイルが存在していないか確認
⑤存在していた場合はすべてのファイルにタグマネージャーのコードを記述してみる
⑥多分上手くいく(かもしれない)
※wordpressに関する情報です。ワールドプレスではありません。
Docker for Mac のボリュームの遅さを cached オプションで解消

ようやく Docker を使い始めたところ、Docker for Mac でホストのディレクトリをコンテナでマウントした時の遅さに驚きました。


バージョン
----

```
$ docker --version
Docker version 17.04.0-ce, build 4845c56
```


状況
----

とある Rails アプリについて、ホスト(macOS)にあるソースコードをホストで編集しつつ Docker コンテナで動かす事を考えます。

```:Dockerfile
FROM ruby:2.4.1

WORKDIR /app

ENV BUNDLE_PATH /bundle
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev
```

```yaml:docker-compose.yml
version: '3'
services:
  ...
  job: &job
    image: ...
    build: .
    volumes:
      - ./:/app
      - gems:/bundle
      ...
    depends_on:
      - postgres
      - redis
      - fluentd
    command: bundle exec rails jobs:work
    environment:
      ...
  api:
    <<: *job
    command: bundle exec rails s -p 3333 -b 0.0.0.0
    ports:
      - "3333:3333"
volumes:
  gems:
  ...
```

macOS 上で動かしたときと比べ、とある単純な Web API の応答時間が10倍くらいになりました(25ms/req → 250ms/req)。


対策
----

最近追加されたマウントオプション(consistency オプション)を利用することで、ボリュームのI/O性能(?)を向上させられる様です。

- [Flags for specifying bind mount consistency by yallop · Pull Request \#31047 · docker/docker](https://github.com/docker/docker/pull/31047)

デフォルトは `consistent` で、一貫性のために性能が犠牲になっている、ということでしょうか。それなりの性能を求めつつ、ホスト側の変更をコンテナに反映したい場合は `cached` オプションを使えば良さそうです。

> The consistency requirements for the mount; one of
> 
> - default: Equivalent to consistent.
> - consistent: Full consistency. The container runtime and the host maintain an identical view of the mount at all times.
> - cached: The host's view of the mount is authoritative. There may be delays before updates made on the host are visible within a container.
> - delegated: The container runtime's view of the mount is authoritative. There may be delays before updates made in a container are are visible on the host.
> 
> [docker/service\_create\.md at master · docker/docker](https://github.com/docker/docker/blob/master/docs/reference/commandline/service_create.md)

```yaml:docker-compose.yml
version: '3'
services:
  ...
  job: &job
    image: ...
    build: .
    volumes:
      - ./:/app:cached
      - gems:/bundle
      ...
    depends_on:
      - postgres
      - redis
      - fluentd
    command: bundle exec rails jobs:work
    environment:
      ...
  api:
    <<: *job
    command: bundle exec rails s -p 3333 -b 0.0.0.0
    ports:
      - "3333:3333"
volumes:
  gems:
  ...
```

雑に比較した(`ab -n100`)限り、 `consistent` で平均 250 ms/req 程度だった応答時間が、 `cached` では平均 85 ms/req 程度に改善出来ました。
まだ使い始めたばかりなので、ホスト側での変更がコンテナに反映されるまでの遅延については、要観察です。


まとめ
----

だいぶましにはなりましたが、macOS で動かした時は平均 25ms 程度なので、まだ体感的にも遅さを感じています…。Docker 慣れしてなさすぎて、そもそもの考え方を間違えているかもしれません。

今回例示した様な構成(ユースケース)では、現時点では [docker\-sync](http://docker-sync.io/) を使っておくのが無難だったりするでしょうか。


追記: 2017/04/13
----

### docker-sync

最低限の設定で unison を使った同期を試したところ、cached の半分以下の応答時間(計測環境が違うので正確ではない)で、macOS 上で development で動かした時と同程度でした。
1. FUJITSU Cloud サービス K5へ登録

このページは、
FUJITSU Cloud サービス K5 を使ってみる - Qiita
http://qiita.com/ynott/items/a256669c692625c5fd25
の「1. FUJITSU Cloud サービス K5へ登録」のページです。

まずは、K5クラウドを使えるようにしましょう。

Googleで検索すると、以下のページが
FUJITSU Cloud Service K5 : 富士通
http://jp.fujitsu.com/solutions/cloud/k5/
ヒットしますが、ここで登録できたら使えると思ってはいけません。
K5を使えるようになるには、登録が2種類必要だそうです。

一つは、

* K5ポータルへの登録
https://s-portal.cloud.global.fujitsu.com/SK5PCOM001/

もう一つは、上記を登録した上で、

* FUJITSU Cloud Service K5 | 富士通WEB MART forクラウド
https://cloud-direct.jp.fujitsu.com/pages/productinfo/870

を登録する必要があります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/afee2100-f0e2-e4e8-cb41-95f61c52b865.png)

# 1. FUJITSU K5 ポータルから登録しましょう
## 1-1. 登録開始
https://s-portal.cloud.global.fujitsu.com/SK5PCOM001/
を開いて、

![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/849c30d4-d4ff-a3e5-9c73-f9749bc83fea.png)

「K5をはじめる」をクリック

## 1-2. メール送信
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/562d1dd8-58a1-0086-eb49-52ed79351ab7.png)

メールアドレスと言語と拠点を入力します。
日本語なので問題ないですね。サクサクいけます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/1eae5bde-a2cb-bb83-f1c4-1173bc42c425.png)
利用規約は同意するにチェックしましょう。

申し込み完了が出たら、この画面は閉じてOKです。

## 1-3. 受信したメールのURLを開いて他の項目を登録

こんなメールが来るので、URLを開きましょう。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/0489fdb8-618b-ba37-22e4-391f8b883e40.png)

こんな感じのごくふつーの登録画面です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/2b0dba93-fc7e-f1f1-30d2-f0bc3c97fd94.png)

IaaSデフォルトリージョンは、以下のものがあるようです。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/15176/2a9795f0-bd09-4103-c5a1-039263d28616.png)

日本の方は、uk(イギリス)、fi(フィンランド)、de(ドイツ)、es(スペイン)を選択する必要はないので、
jp-east-1
jp-west-2
を選択しましょう。

## 1-4. 登録完了画面＆完了メール

登録完了画面と完了メールには、

```
契約番号
```
```
ユーザー名
```
という重要な情報が書いてあるので必ず保存しておきましょう。

パスワードもお忘れ無く。

----
次は、[2. 富士通WEB MART forクラウドへ登録](http://qiita.com/ynott/items/550cabdc9423a024544e) へ進みましょう。
Go1.7~ subTestsとTableDrivenTest

## ReadMeFirst

`go1.7`からSubTestsが使えるようになったのだけど、
使っていなかったので、調べがてら、その紹介とメモ。
あと、ついでにTableDrivenTestについて書いておく。

## Subtestsとは

Subtestsの追加によって、テストに階層を作ることができるようになりました。
[Run](https://golang.org/pkg/testing/#T.Run)メソッドを使ってテスト内に小さなテストを書いてみます。

### コード例

* example.go

```
package main

import "fmt"

func Example(name string) string {
	if name == "" {
		return "blank name"
	}
	return fmt.Sprintf("Hello %s", name)
}
```

* example_test.go

```
func TestExample(t *testing.T) {
	t.Run("case Empty", func(t *testing.T) {
		result := Example("")
		expected := "blank name"
		if expected != result {
			t.Fatalf("failed Test")
		}
	})
	t.Run("case Normal", func(t *testing.T) {
		result := Example("John")
		expected := "Hello John"
		if expected != result {
			t.Fatalf("failed Test")
		}
	})
}
```

t.Run内でPararell()を使った並行テストも可能です。

### 実行の仕方

サブテストの含まれるテスト関数を実行すれば良いだけです。
ドキュメントを見る限り、以下のような、オプションによるマッチングによって特定のサブテスト
だけを実行することも可能です。

```
go test -run Foo/A=  # For top-level tests matching "Foo", run subtests matching "A=".

Fooを含むトップレベルテスト(通常のテスト関数)内でA=を含むサブテストを実行する。

go test -run /A=1    # For all top-level tests, run subtests matching "A=1".

A=1を含むサブテストを実行する。

```

### 実行結果

```
$ go test ./...
--- FAIL: TestExample (0.00s)
    --- FAIL: TestExample/case_Empty (0.00s)
    	hoge_test.go:12: failed Test
    --- FAIL: TestExample/case_Normal (0.00s)
    	hoge_test.go:19: failed Test
```
失敗させると。第１引数で指定した名前を出してくれますね。

## Benchmarkでも使える。

testing.Bでも使えますので、Benchmarkについても階層化が可能です。
こちらはまぁ便利な気もする。

## SubTestの使いどころ

正直、個人的には`これを待っていたよ！`って感動を覚えるものではありませんでした。

というのも、階層が必要なほど複雑なテストが必要な場合は`テスト対象コードの仕事が多すぎる`気がしますし
1Test1Assertionで育ったこともあり、テスト関数自体を分けてしまうスタンスでしたので。
GoではErrorのような、処理自体は継続する事ができるので、`Assertion Roulete` のような事はないと
思うのですが、一つのテスト関数に複数を盛り込んで長くするのが、そもそも苦手なのもあり。

うーん。すごく複雑なテストケースが必要な場合もあるのかもしれないし、
見てみたさがあります。求む、エレガントな使用ケース (切実)

## TableDrivenTestで大体は十分

上の例程度のケースならgolangの推奨するTableDrivenTestでも可能です。
TableDrivenTestは`入力値`、`出力値`で構成するデータを用意して
iterateでテストを回す感じがコードも短く済むので、推奨されてます。

go公式から引用ですが。

```
var flagtests = []struct {
	in  string
	out string
}{
	{"%a", "[%a]"},
	{"%-a", "[%-a]"},
	{"%+a", "[%+a]"},
	{"%#a", "[%#a]"},
	{"% a", "[% a]"},
	{"%0a", "[%0a]"},
	{"%1.2a", "[%1.2a]"},
	{"%-1.2a", "[%-1.2a]"},
	{"%+1.2a", "[%+1.2a]"},
	{"%-+1.2a", "[%+-1.2a]"},
	{"%-+1.2abc", "[%+-1.2a]bc"},
	{"%-1.2abc", "[%-1.2a]bc"},
}

func TestFlagParser(t *testing.T) {
	var flagprinter flagPrinter
	for _, tt := range flagtests {
		s := Sprintf(tt.in, &flagprinter)
		if s != tt.out {
			t.Errorf("Sprintf(%q, &flagprinter) => %q, want %q", tt.in, s, tt.out)
		}
	}
}
```

要するにphpunitにあった`DataProvider`をfor文と`Errorf`で自力でやる感じです。
個人的にはメッセージも各パターン別にある方が親切かな。。。と。

```
{"input-a","out-a","message at failed"},
{"input-b","out-b","message at failed"},
{"input-c","out-c","message at failed"},
{"input-d","out-d","message at failed"},
```

とか。

## 参考
[TableDrivenTests](https://github.com/golang/go/wiki/TableDrivenTests)
[testing package](https://golang.org/pkg/testing/)
Node.js(Express) + express-sessionを利用する

express-sessionを使って簡単なセッション管理をしてみる。
[expressjs/session](https://github.com/expressjs/session)

バージョンは以下。
- express: 4.14.0
- node: v6.9.4
- npm: 3.10.10

セットアップ。

```
$ express -e login-sample
$ cd login-sample
$ npm install
$ DEBUG=login-sample:* npm start
```

一応確認。
続いて、インストールする。

```
$ npm install express-session --save
```

app.jsに下記を記載する。

```
// 読み込み
const session = require('express-session');

// ルーティング
app.use('/login', login);
app.use('/', index);

```

/routes/index.jsに下記を記載する。

```
var express = require('express');
var router = express.Router();


router.get('/', sessionCheck);

// loginしてる場合はindex pageへ、してない場合はlogin pageへ
function sessionCheck(req, res, next) {
	if (req.session.user) {
		res.render('index', { title: req.session.user.name});
	} else {
		res.redirect('/login');
	}
};


module.exports = router;

```

/routes/login.jsに下記を記載。

```
const express = require('express');
const router = express.Router();

router.get('/', function(req, res, next) {
	res.render('login');
});

router.post('/', function(req, res, next) {
	if (req.body.userName) {
		req.session.user = { name: req.body.userName };
		res.redirect('../');
	} else {
		const err = 'data is wrong';
		res.render('login', { error: err });
	}
});

module.exports = router;
```

/views/login.ejsに下記を記載。

```
<!doctype html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>ログイン前</title>
</head>
<body>
  <h2>ログイン</h2>
  <form action="/login" method="POST">
    <input type="text" name="userName" placeholder="username"/>
    <button type="submit">ログイン</button>
  </form>

</body>
</html>
```

以上、これで起動させる。
ユーザー名を入れてログインすると、index pageにユーザー名表示されて完了。

#### 参考
こちらを参考にさせてもらった。
[Node.js + Express.js + express-sessionでセッションにデータ格納する方法](http://qiita.com/moomooya/items/00f89e425a3034b8ea14)

ただ、この記事内で使われてる、`app.use('/', sessionCheck, index); `みたいな書き方ができなくなっていたみたいなので、sessionCheckを/routes/index.jsに持っていって、

```
router.get('/', sessionCheck);

function sessionCheck(req, res, next) {
	if (req.session.user) {
		res.render('index', { title: req.session.user.name});
	} else {
		res.redirect('/login');
	}
};
```

な感じで利用した。

今回作成したコードを一応ここに置いておきます。
[mazeltov7/loginProt](https://github.com/mazeltov7/loginProt)
FUJITSU Cloud サービス K5 を使ってみる

そもそもは、FUJITSU K5 クラウドで GitHub Enterprise が使えるようになったよぉ、という耳目を引いた話がありました。クラウドの方が話題になる前にサービスの方が話題になるというのも面白い話です。

もう一つ面白い点としては、え？富士通がGitHub？ という点もありました。どちらかと言えばレガシーっぽいイメージ(すみません)の会社さんなので、GitHubとはこれ如何にという印象でした。

トライアルあるお～。と聞いてテストしないわけには行きません。
オマケに「仮想CPU10、ブロックストレージ400GB、オブジェクトストレージ100GB、ロードバランサー1台、グローバルIPアドレス2個を無料で30日間ご利用いただけます。」
という大盤振る舞い

いつものownCloudテストもかねて、やってみた備忘録を記録したいと思います。
別途いつものownCloud検証レポートも作る予定です。
(一つの投稿にするのは大変そうなので、記事毎に分けます)

1. [FUJITSU Cloud サービス K5へ登録](http://qiita.com/ynott/items/2e13cdd57c92f6d3e577)
2. [富士通 WEB MART for クラウドへ登録](http://qiita.com/ynott/items/550cabdc9423a024544e)
3. [K5トライアル申し込み](http://qiita.com/ynott/items/244023ad5d5417b61596)
4. [使うのに困ったこと or 分かりにくかったこと](http://qiita.com/ynott/items/5c9b9f5a31e2f28bdd41)
5. [FUJITSU Cloud K5の検証は止まっています(解決済み)](http://qiita.com/ynott/items/0071ee9f683513bd5597)
6. [[Solved]K5 仮想ネットワークトラブル解消編](http://qiita.com/ynott/items/c0b751778077cd954c99)
7. [FUJITSU K5 PaaS GitHub Enterprise を申し込む](http://qiita.com/ynott/items/a6073d90922b74307715)
8. [FUJITSU K5 PaaS GitHub Enterprise を使ってみる](http://qiita.com/ynott/items/0391245e5444cd95cc9a)
9. [FUJITSU K5 に Rancher を導入](http://qiita.com/ynott/private/5e29f336fc2ca6fa83e2)
10. [Nextcloud を FUJITSU Cloud K5 上に構築する](http://qiita.com/ynott/private/f047af5f2c1f667d5530)

# 謝辞：皆さまご協力ありがとうございました。

無事、Nextcloudの稼働までこぎ着けました。
皆さまの協力無くしてここまでたどり着けなかったでしょう。

K5 の陰サポートととして、様々な相談にのって頂き、時には記事の執筆を催促していただいた @tnaoto 様にはひとかたならずご尽力いただき、誠にありがとうございました。
また、K5 を運用されている方々にも大変ご迷惑をお掛けいたしました。トラブル時には迅速に対応し、緊急保守対応していただいたことに感謝いたします。

また、Rancherのセットアップでは、あまりにも忙しく動くことができなかった私に変わり RancherJPメンバー @FoxBoxsnet がほとんどセットアップを担当してくれました。また、Nextcloud の Rancher Catalog も作成してもらって私はボタンを押すだけでした。本当にどうもありがとう！
Sidetiq亡き後の定期実行

# Sidetiq亡き後の定期実行

## NO LONGER MAINTAINED!!!

Rubyアプリケーションで定期的にジョブを回す場合(毎日2時にElasticsearchのインデックスを再構築とか)、かつては[sidetiq](https://github.com/endofunky/sidetiq)をつかうのが定番であったようです。

しかしsidetiqはずっと開発が停滞しており、とうとう今年1月に[「もうメンテナンスしないよ」と明言されてしまいました。](https://github.com/endofunky/sidetiq/commit/261f213d8955ca416625d19dbf4e5cff007ef55b)

私の関わっているプロジェクトでは10秒ごとにあるジョブを動かすためにSidetiqを利用しています。しかしメンテされていないgemを使い続けるべきではないだろう、というわけでsidetiqを置き換える方法を探してみました。

## Alternatives

### Sidekiq + clockwork

[Sidekiqの利用例](https://github.com/mperham/sidekiq/blob/master/examples/clockwork.rb)に載っている方法。[clockwork](https://github.com/adamwiggins/clockwork)というcronの代わりをするというgemを使います。

Sidekiqのレポジトリにのっているということは評価指標のひとつですが、clockworkの開発はそれほど活発ではないようですし、clockworkプロセスを動かさないといけないのも難点かと。これまでRailsアプリケーションとSidekiq(+Sidetiq)という構成であった場合、デプロイ処理も修正する必要があるでしょう。

### sidekiq-cron

[sidekiq-cron](https://github.com/ondrejbartas/sidekiq-cron)はSidetiqを直接置き換え可能な候補の１つです。アプリケーション側の修正だけで済みます。開発も活発にされているようですし、Star数も多いので乗り換え先としては最有力でしょう。

READMEから使い方を引用すると、

```ruby:hard_worker.rb
class HardWorker
  include Sidekiq::Worker
  def perform(name, count)
    # do something
  end
end

Sidekiq::Cron::Job.create(name: 'Hard worker - every 5min', cron: '*/5 * * * *', class: 'HardWorker')
# => true
```
というふうにジョブを作るようです。実行間隔はcronの設定と同じように設定します。

ここで１つ問題がありました。設定の記法がcronと同様ということは、最低でも実行間隔が1分になってしまいます。秒単位での指定ができません。冒頭に書いたように、私の必要なのは「10秒ごとに定期実行できる」ものであり、sidekiq-cronは採用しませんでした。

### sidekiq-scheduler

[sidekiq-scheduler](https://github.com/moove-it/sidekiq-scheduler)は前述のsidekiq-cronよりは少ないものの、そこそこの数のstarも集めており開発も継続中です。

こちらはsidekiq.ymlに設定を追記するのみです。個人的にはsidekiq-cronのようにアプリケーションコード内に書くより、こちらのほうが好みです。

```yml:config/sidekiq.yml
:schedule:
  hello_world:
    every: 1m   # Runs once per minute
    class: HelloWorld
```

また、こちらは秒単位での間隔指定にも対応しており、私の要件にマッチしています。こちらを採用することにしました。

コードの修正は
- Gemfileからsidetiqを取り除きsidekiq-schedulerに置き換える
- sidetiqを利用している部分のコードを置き換える
- sidekiq.ymlに設定を移す

だけでした。ほとんどあっという間です。

## Conclusion

Sidetiqを使っている人は、早めに乗り換えましょう。その際はsidekiq-cronかsidekiq-schedulerが候補になることでしょう。
Modern.IE(IE8、IE9、IE10、IE11)の検証環境をWindowsのHyper-Vでさくっと導入

# 概要

Webアプリケーションの保守・運用で欠かせないのが検証環境になります。
企業向けのレガシーシステムにおいては、いまだにレガシーIE（IE11未満）をサポートし続けているケースが多いと思います。
その際にIEバージョン別に物理マシンを確保＆保管するのが大変なので、
[Modern.IE](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)から提供されているIEバージョン別の仮想マシンイメージで容易に管理し、運用することができます。

Modern.IEで用意されているイメージは様々なプラットフォーム向けに準備されていますが、
せっかくWindows機を使っているのなら、標準搭載されているHyper-Vでさくっと動かす方法をご紹介したいと思います。

## Hyper-Vの動作環境

- Windows7, 8, 10 Pro以上
- Windows Server シリーズ

なお、Hyper-Vの管理マネージャーをインストールできない場合（Home Editionやポリシーで禁止されているなど）は従来のVMwareやVirtualBoxにインストールする方法を用いてください。

詳しくは下記をご参照ください

- [IE 確認用の仮想マシンの構築 (modern.IE)](http://qiita.com/aoi70/items/ba4012bfd15f327dede9)
- [VMware上の modern.IE (Windows7) をネットに繋ぐ前に](https://3u3.org/968)


# 方法

1. [Modern.IE](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)で対象のイメージをダウンロード
2. ダウンロードしたアーカイブを解凍
3. Hyper-Vマネージャーから対象のイメージをインポート  
   [Hyper-Vマネージャーのインストール(外部リンク)](https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)  
   ![import-image.png](https://qiita-image-store.s3.amazonaws.com/0/30522/5b674991-b8ba-369b-28fe-93eec42f0a77.png)
   ![import-image2.png](https://qiita-image-store.s3.amazonaws.com/0/30522/a0b96b45-cf13-ac3c-e913-c98fabcdd253.png)
   ![import-image3.png](https://qiita-image-store.s3.amazonaws.com/0/30522/ffa441fb-1256-65f3-9683-563f25eda76d.png)
   ![import-image4.png](https://qiita-image-store.s3.amazonaws.com/0/30522/98630cae-370f-3544-f96a-93567f111020.png)
   ![import-image5.png](https://qiita-image-store.s3.amazonaws.com/0/30522/1c6a9be2-43e8-2852-608c-d5cf38d9b896.png)

4. 外部通信できるように仮想スイッチを作成
   ![import-image6.png](https://qiita-image-store.s3.amazonaws.com/0/30522/8c832dc5-0815-03ca-ee66-2dd2ce043126.png)
   ![create-switch.png](https://qiita-image-store.s3.amazonaws.com/0/30522/afdfaa4d-2a20-b64c-8f67-35ce5f1abbaa.png)
   ![create-switch2.png](https://qiita-image-store.s3.amazonaws.com/0/30522/029617a0-7ad6-4761-161a-ba22945c6131.png)

5. 仮想マシンに作成したスイッチを割り当てる  
   ![attach-switch.png](https://qiita-image-store.s3.amazonaws.com/0/30522/a0334c4e-e858-5571-4eae-42608ef01dd7.png)
   ![attach-switch2.png](https://qiita-image-store.s3.amazonaws.com/0/30522/261022b4-be4a-c4bd-4800-a15fca9637b8.png)

6. 仮想マシンを起動
7. キーボードがUS仕様になっているので、日本語仕様に変更
   [変更方法(外部リンク)](http://yuukiar.co/blog/2013/05/06/japanese-keyboard-virtualbox-modern-ie/)
8. ライセンス認証
   起動した仮想マシンの壁紙に記載されている通りに作業を行えば問題なく、認証されます。
   ただし、最大90日間まで
   [壁紙の和訳(外部リンク)](https://3u3.org/810)
SLICECAP: PCAPファイルの分割並列処理

# パケット解析してますか？
ネットワークトラフィックを解析している人は[`libpcap`](http://www.tcpdump.org/)ライブラリを使ったことがある、あるいは`libpcap`を直接使うことがなくとも[`tcpdump`](http://www.tcpdump.org/)などでキャプチャしたPCAP形式のファイルを扱ったことがあるかと思います。

多くのトラフィック解析ツールがPCAP形式に対応しているため、この形式でデータを保持しておけば、後々様々なツールで利用できるという安心感があります。一般的な解析ならば既存のツールで十分でしょう。

しかし、高度な解析をしようとすると、PCAPデータやそこに含まれるパケットの内部構造などを細かく見ていきたくなります。PCAP形式のデータはパケットが羅列されたバイナリデータとほぼ同じなので、前処理プログラムを用いて必要な部分を取り出したり、加工したりしなければなりません。

最近はネットワークも高速化しており、ほんの数分のキャプチャでも場合によっては数十GBのデータになることすらあります。解析内容にもよりますが、すでに手法が確立されたものでない限り、データをいろいろな側面から様々な手法で繰り返し解析していくことになるでしょう。小さなデータなら問題ありませんが、データ量が増えるにつれ前処理にかかる時間も無視できなくなってきます。

本稿では大きなPCAP形式のファイルを高速に処理するためのソフトウェア「[**SLICECAP**](https://github.com/keiichishima/slicecap/)」を紹介します。

# 分割して処理せよ
大きなデータに取り組む時の常套手段は並列処理です。まず、元のデータを小さなデータに分割し、それぞれの小さなデータを複数のスレッドやプロセス、場合によっては複数のサーバに分散させて並列処理します。

PCAP形式のファイルについても同じように取り組みたいのですが、ここで問題が発生します。

PCAP形式のデータはパケットストリームを記録するためのものなので、パケット単位でのインデックス情報が存在しません。あるPCAPファイルに何個のパケットが含まれているのか、先頭から1000個目のパケットはファイル上で何バイト目から始まるのか、といった情報は、PCAPファイルを先頭から順番に調べていかなければなりません。たくさんのパケットが記録されているPCAPファイルを分割するとき、この処理に大きな負荷がかかります。

以下にPCAP形式を簡単に示します。赤いヘッダ部はグローバルヘッダと呼ばれ、PCAPデータ全体の情報が収められています。パケットヘッダと呼ばれる青いヘッダ部とその後に続く白いブロックがひとつのパケットを表しており、パケットヘッダ部に個々のパケット特有の情報が収められています。
![PCAP_FORMAT_FIGURE](https://qiita-image-store.s3.amazonaws.com/0/102672/421ac30f-940b-485b-0fce-ea785218d59b.png)

# 目的を思いだそう
さて、目的はPCAP形式のファイルを小さなサイズに分割することでした。複数のデータに分割して並列処理できればよいので、必ずしも分割後のデータに含まれるパケットの数が揃っていたりする必要はありません。SLICECAPはユーザが指定した分割数とPCAPファイル全体のサイズから、分割後のデータサイズを計算し、「**いい感じに**」パケットの区切りを探して分割します。

パケット境界の発見に利用するのは、各パケットヘッダ部に記録されているタイムスタンプ情報です。パケットは連続的に記録されているので、各パケットのタイムスタンプの値も似た値になっていると仮定できます。まず分割のために適当な位置にファイルポインタを移動し、そこから1バイトずつポインタを進めながら、似た値のタイムスタンプが記録されている位置までポインタを進めます。その後、パケットヘッダの他のフィールドが異常な値にならないかを検証し、「**それっぽい**」と判断すればそこで分割確定です。

分割されたデータは、グローバルヘッダを追加してPCAP形式に再構築され、プロセス間通信の仕組みで子プロセスに渡されます。分割されたPCAPデータが別々のプロセスで処理されるため、コア数に応じて処理性能が向上します。

# 使ってみよう
例としてPCAPファイルを10個の小さなPCAPファイルに分割する例を示します。

    slicecap -r source.pcap -n 10 -- "cat - > dest-{SLICE_ID}.pcap"

実際の解析では、`cat`よりももう少し役に立つフィルタプログラムを指定することになるでしょう。

次に示す図は、並列プロセス数を増やしながら[p2c](https://github.com/daisu-mi/pcap2csv/)コマンドを用いてヘッダ情報をCSVに変換した時の処理時間を計測したものです。
![SLICECAP_PARA_FIGURE](https://qiita-image-store.s3.amazonaws.com/0/102672/865ed893-ecfd-56a8-c6db-5cce5989d39a.png)
計測に用いたPCにはIntel Xeon E2697 v3 (14 core)が2個と256GBのメモリが搭載されています。58GBのPCAPファイルを解析し、IP/TCP/UDPヘッダを抜き出してCSV形式で出力する処理を実行しました。並列プロセス数を増やしていくごとに処理時間が短縮しているのがわかります。簡単な整数演算のみで完結してしまうためか、ハイパースレッディングの効果はあまり見られませんでした。処理内容によってはもう少し向上する可能性もあるでしょう。

# 入手先
SLICECAPはPyPiレポジトリに登録されています。`pip`コマンドでインストールしてください。ソースコードは https://github.com/keiichishima/slicecap/ で公開しています。バグレポ、プルリク歓迎です。