OmniAICreator/Qiita-1.07M huggingface dataset:
Django on CentOS7, python34, apache2.4 mod_wsgi, mariadb #1 -- 基本環境構築

# Overview
　Webアプリケーションを作る必要が出てきたのでDjangoというのを使ってみることにした。
構築環境として指定された物は以下の通り

* CentOS7
* python 3.x
* django 1.10
* mysql

# 基本方針
* 可能な限りyum install (標準パッケージ)を使う
* 可能な限りOSデフォルトの挙動を変えない
    * デフォルト動作が変わると他のコマンドに影響が出て基盤管理が面倒くさくなる
* 可能な限り自動化する
    * ダルいから

## 方針に関するメモ
CentOS7のpythonは2.7がデフォルトなのでpython3.xは別インストールすると言うことになる。
また、djangoもyumパッケージは1.4だか1.6という化石のようなバージョンが標準なので
パッケージ名さえ同じであればいいでしょ、とはいかないので挫折してpipも使った

# How to Install packages

## Install git/ansible packages
　基本、インストールはAnsible化しているのでインストールはAnsibleとして説明するが
Ansible自体が入っていないと話にならないので、以下の作業は必須。

<pre>
 # yum -y install epel-release
 # yum -y install ansible git
</pre>

## Ansible play-books (roles/xxx/task/xxx.yml)

全てmain.ymlに記載しても良いが、メンテナンス性や可読性を考えると
別ファイルにしてIncludeした方が都合が良いことが多い。

### Python3.4
<pre>
- name: install packages from repo
  yum:
    name: "{{ item }}"
    state: latest
  with_items:
    - python34
    - python34-devel
    - python34-setuptools
    - python34-pip
    - gcc
</pre>

### Apache
<pre>
- name: yum install httpd
  yum: 
    name: "{{ item }}"
    state: latest
  with_items:
    - httpd
    - httpd-devel
    - mod_ssl
    - mod_wsgi
  tags:
    - prod
  become: yes
</pre>

### mariadb
<pre>
- name: yum install mariadb
  yum: 
    name: "{{ item }}"
    state: latest
  with_items:
    - mariadb-server
    - mariadb-devel
  tags:
    - prod
  become: yes
</pre>

### Django
<pre>
- name: install packages from pip3
  easy_install:
    name: "{{ item }}"
    state: latest
  executable: /usr/bin/pip3
  with_items:
    - django
    - pymysql
    - pip
  tags:
    - prod
  become: yes
</pre>

## Settings

### httpd.conf
python3.4を使っているので、パスを記載してやる必要がある。

<pre>
WSGIScriptAlias / /var/www/django/project/mysite/mysite/wsgi.py
WSGIPythonPath /var/www/django/project/mysite:/usr/lib64/python3.4/site-packages
WSGIDaemonProcess mysite python-path=/var/www/django/project/mysite:/usr/lib64/python3.4/site-packages
WSGIProcessGroup mysite
</pre>

### django
setting.py, wsgi.py, manage.py に細工が必要なところだけ記載

#### manage.py
<pre>
#!/usr/bin/env python3
import os
import sys
import pymysql
pymysql.install_as_MySQLdb()
</pre>

#### setting.py
<pre>
import os
import pymysql
pymysql.install_as_MySQLdb()
</pre>

#### wsgi.py
<pre>
import os
import pymysql
pymysql.install_as_MySQLdb()
</pre>

## Install

<pre>
 # ansible-playbook -i <inventory_file> <play-books> -vvv
</pre>

基本的にはこれで最低限の動作はしてくれる。
技術英語 > The age-old wisdom is [dead-on]. / dead end

@ Code Complete (No. 18249 / 36077)

> The age-old wisdom is **<font color=red>dead-on</font>**.

http://ejje.weblio.jp/content/dead+on
> まったく正しい、完ぺきな

https://www.merriam-webster.com/dictionary/dead%E2%80%93on
> :  exactly correct or accurate <a dead–on analysis> <his impersonations were dead–on>

<hr>
関連して思い出したのは

dead end

> https://www.merriam-webster.com/dictionary/dead%20end

1. an end (as of a street) without an exit
2. a position, situation, or course of action that leads to nothing further

[Grenning > 穴にはまっていることに気づいたら、掘るのをやめよう](http://qiita.com/7of9/items/33a8f21cb0bb17fa6cce)
vue.js: styleオブジェクトの型定義を作った

## モチベーション

TypeScriptでvue.jsのコードを書いている。

[クラスとスタイルのバインディング](https://jp.vuejs.org/v2/guide/class-and-style.html) にあるように、以下のような形で要素のインラインスタイルにJavaScriptのオブジェクトをバインドすることができる。

```html
<div :style="styleObject">
  Foo
<div>
```

```ts
@component({ ... })
class MyComponent extends Vue {
  get styleObject {
    return {
      color: "red",
      fontSize: "13px"
    };
  }
}
```

といっても日曜フロントエンドエンジニアだしcssのプロパティ名とかあまり覚えていない。

非表示にするのは `display: none` だっけ `display: hidden` だっけとか、 `flex-direction` は `column` だっけ `columns` だっけみたいなのがたくさんあるし、せっかくTypeScriptを使っているので、そういうなのは補完してほしい。どこかにあるんじゃないかと思って探したけど見つからなかった。


## できたもの

ので、取り急ぎ作りました。

https://github.com/wonderful-panda/vue-css-definition

これで、色々補完が効くようになります。

```ts
import { CssProperties } from "vue-css-definition"

@component({ ... })
class MyComponent extends Vue {
  get styleObject: CssProperties {
    return {
      color: "red",
      fontSize: "13px"
    };
  }
}
```

## 元ネタ

最初、Reactの型定義に同じようなのがあるはずなのでパクろうと思ったけれど、下のような感じで型が全部anyなので、いい感じに補完したいという目的からすると今一つだった。

```ts:react.d.ts
interface CSSProperties {
    alignContent?: any;
    alignItems?: any;
    alignSelf?: any;
    alignmentAdjust?: any;
    alignmentBaseline?: any;
    /* 以下略 */
}
```

他にMachine ReadableなCSS属性の定義はどこかにないかと思って探したところ、Visual Studio Codeのcss補完エンジンである[vscode-css-languageservice](https://github.com/Microsoft/vscode-css-languageservice) が使えそうな定義を持っていたので、それを拝借した。Machine Readable どころか jsコードなので require するだけというお手軽ぶり。
その定義を適当に整形してejsのテンプレートに食わせて d.ts を生成している。

あくまで補完の定義なので型定義として見た場合には正しくない箇所があり、できるだけ対応したつもりだけどまだ間違ってるところがあるかもしれないけど、今のところ快適。
RAWはRAWでもWWEではなくてパッケージング前の動画データのこと。でもWWEのRAWは面白いよね。

## どういうわけか

ネクストスケープ配信事業本部 Advent Calendar 2016 にまだ空いている日が有るのに、誰も埋めようとしない・・・。
これは、そんなカレンダーの隙間を埋める為の小ネタ。
そして恐らく、大半の人にとって全く必要の無い小ネタです。

## 極稀にですが
動画配信の仕事をしていると、納品されたコンテンツがパッケージングや暗号化処理の際にエラーになる時が有ります。

そんな時は、まあ、色々とゴニョゴニョして原因を特定していくのですが、そのゴニョゴニョの一つに
**RAWデータからの再パッケージ**が有ります。

要は、エラーになった **~~ffmpegでパッケージングされてたっぽい~~ mp4**をパッケージャを変えてmp4にしてみよう！
と言う事です。

## 具体的な手順は
次の様になります。H.264のシングルトラックを持つ some_video_ffmpeg.mp4 と some_video_mp4box.mp4 と言う
2つのmp4が有ったとして、ffmpegを使ってRAWでーたを取り出す時は

```
ffmpeg -i some_video_ffmpeg.mp4 -codec copy some_video_ffmpeg.h264
ffmpeg -i some_video_mp4box.mp4 -codec copy some_video_mp4box.h264
```
みたいな感じで、H.264のRAWデータが取り出せます。
ちなみに、H.264の映像データとAACの音声データがMUXされたmp4からそれぞれRAWデータを取り出すのは

```
ffmpeg -i some.mp4 -codec copy some.h264
ffmpeg -i some.mp4 -codec copy some.aac
```
と言った感じで。

mp4boxを使う場合は

```
mp4box -raw 1 some_video_ffmpeg.mp4 -out some_video_ffmpeg.h264 (1はTrackIDを指定しています)
mp4box -raw 1 some_video_mp4box.mp4 -out some_video_mp4box.h264 (1はTrackIDを指定しています)
```
と言う具合です。
-outのオプションは無くても構いません。mp4boxが勝手にコーデックを判別して、元のファイル名_track1.h264
みたいなRAWデータを作ってくれます。

パッケージングの方は、ffmpegだと

```
ffmpeg -i some_video_ffmpeg.h264 -codec copy some_video_from_ffmpeg.mp4
ffmpeg -i some_video_mp4box.h264 -codec copy some_video_from_mp4box.mp4
```
と、DEMUXとかと同じ感じで出来ます。

mp4boxだと

```
mp4box -add some_video_ffmpeg.h264 -new some_video_from_ffmpeg.mp4
mp4box -add some_video_mp4box.h264 -new some_video_from_mp4box.mp4
```
と、ちょっと見慣れないコマンドオプションでパッケージング出来ます。

## ここまで書いておきながら
実のところは、先日書いたDEMUX処理で再パッケージ処理は行われているんですけどね・・・。
でもまあ、出力されたmp4も微妙に異なっているし、個人的には一旦RAWデータを作って再パッケージしてます。
ID Map用テクスチャの作り方

個人的メモ。
Substance PainterでID Mapを使用する為にBlenderから出力します。
何か他にいい方法あったら教えて下さい。

Blender - 2.77a

1. Blenderでモデル作成。
1. 色分けする所はUVのSeamを付ける。
1. UV展開。大体は「Smart UV Project」
    - **ここで「Island Margin」を0.02くらいにしてUV間にマージンを作っておく**
1. 「UV/Image Editor」でテクスチャを設定。
    - 最終的にSubstance Painterや実機で使うテクスチャピクセル数に合わせて作成
1. 「Texture Paint」モードでパーツ毎に違う色を塗る
    - ![blender_idmap01.png](https://qiita-image-store.s3.amazonaws.com/0/58518/b1dbf00d-d4c7-6497-63eb-83571a006e17.png)
1. 「UV/Image Editor」から「Image」→「Save as Image」でpng出力。
1. **画像編集ソフトで各UVのピクセルを10px程拡張する**
    - UV端の位置が補間等で色が混ざる事が有るので
1. このテクスチャをID Mapとして使用する



何かTexture Paintで選択範囲のUVを拡張して塗る機能どっかに有りそうな気がする。
レキシカルとスタティックの違い

#スタティックとダイナミック

***【static】静的な***
変数などが定義されたスコープや関数内に所属し、スコープ外の同名の定義に干渉しない。

```C:Cの静的スコープ
int value = 123;

{
	int value = 456;
	{
		value ++;
	}
	// value : 457
}
{
	value ++;
	// value : 124
}

// value : 124
```

***【dynamic】動的な***
変数などが関数やスコープのなどの所属に関係なく動的に定義できる。

```javascript:javascriptの動的スコープ
var value = 123;

{
	var value = 456;
	{
		value ++;
	}
	// value : 457
}
{
	value ++;
	// value : 458
}

// value : 458
```

*この例では無名スコープですが、if文やfor文でも同じ挙動(衝撃！)*

#じゃあレキシカルって何？
辞書によると、
***【lexical】 語彙的な***
なんだこれは？！意味がわからん！日本語？

javascriptにとって**レキシカルスコープ**というのは、関数のスコープ内で限定的に使用できる擬似的な静的スコープ。

```javascript:上記C言語の例をjavascriptで実現
var value = 123;

(function(){
	var value = 456;
	{
		value ++;
	}
	// value : 457
}());

(function(){
	value ++;
	// value : 124
}());

// value : 124
```
（うおおおめんどくさい！！）

Q:　で、静的スコープと何が違うの？
A:　同じです（震え声）

では、なぜレキシカルと呼ばせるようになったのか？

これはあくまで想像
C言語などの静的変数と、javascriptのレキシカル変数の性質が似て非なるものなので、同じ名前を避けたのではないか？と推測

```C:C
int func(int num) {
	static int memory = 0; //静的変数
	memory += num;
	printf("%d\n", memory);
}

func(100); // 100
func(23); //123

/// 静的変数のmemoryへの直接アクセスは通常の方法では不可能
/// 「関数のポインタをキャストしてゴニョゴニョ・・・」「ハッカーですか？」
```

```javascript:javascript
function myClass(){
	return {
		memory: 0, //レキシカル変数
		func: function(num){
			this.memory += num;
			console.log(this.memory);
		}
	}
}
obj = new myClass();

obj.func(100); // 100
obj.func(23); // 123

memory = 1000;
obj.func.call(this, 234); // 1234 /////callでthisを指定できる
obj.func(0); // 123
obj.memory = 0; /////アクセスできる
obj.func(0); // 0
```

##私の仮定
**Static変数**という言い方が先にできて、反語として**Dynamic変数**が命名されたのだと仮定して、
**Lexical変数**は、「うちの言語だと、若干 **static**と性質違うし相応しい名称を考えよう」と思ったエライ人が、「じゃあ*Dictionary型(C#のハッシュ)で内部に変数を格納しているイメージ*から、索引的、辞書的 ＝ **lexical** と定義しようよ」と言って広まったんじゃないのかと予想。

しかし私は**レキシカル**な**スコープ**という言い方は、なんかどういう意味合いでもしっくり来ない。
なので単に**Dynamic**の反語だからという意味で誰かが使用し始めて、それが一般的になってしまったのではないか、と邪推してみます。

*追記*
*コメント欄より*
*[こちら](https://teratail.com/questions/41031)の説明で lexical=構文的 と説明されていて、*
*なるほど、lexical grammar -> 構文法 なので lexical も構文と訳せばしっくり来るね！という結論に至りました。*

#あらためて、lexicalとは
**【lexical】****lexicon**の形容詞形
そもそも英語で言う**lexicon**とはいわゆる語彙という意味もあるけど、知識量を表すだけではなく、**目録**、**索引**という意味合いがあるらしいよ！

日本人にとって【語彙】とはそもそも馴染みも薄い単語であって、一般的には「ボキャブラリー」と同義だと考える人が多いから、ちょっと理解しにくいんじゃない？

**もうレキシカルを「語彙的な」と訳すのはやめにしませんか？**(ぼそ)
「語彙的」と訳された時、日本人はまず*【語彙】個人の使う語の総量*と「的」をくっつけてしまう。これじゃ通る意味も通らない。

なので、**lexical**を**語彙的な**と訳すより、むしろ**目録的な**と訳せば日本人にとってもしっくり来ると思う
それにプログラム的にも目録的のほうが意味が通っていると思うのだけど・・・
キーボードのお話

WithOne AdventCalendar 6日目の記事です。

今回は技術的なお話ではありませんが、エンジニアである皆さんが業務で必ず使う「キーボード」について少し書いてみようかなと思います。皆さんはどんなキーボードを使っていますか？

## キーボードの種類
一重に「キーボードの種類」といっても色々な項目があり細かくは説明しきれないため、ここではキーボードを選ぶ際に特に気にするであろう項目だけ載せておきます。興味のある方はぜひ調べてみてください。

- キースイッチ
    - メンブレン（一般的なものはこれ、比較的安価）
    - パンタグラフ（薄い、ノートパソコンなどで採用）
    - メカニカル（キー1つ1つにスイッチ配置、スイッチに種類がある）
    - 静電容量無接点方式（高い耐久性と打ち心地、高価）
- キー配列
    - 日本語配列
    - 英語配列
    - 日本語／英語どちらでもない
- テンキー
    - テンキーあり
    - テンキーなし
- 接続
    - 有線（USB、PS/2）
    - 無線（Bluetooth、USBレシーバをPCに挿すタイプなど）
- 形状
    - 通常（いわゆる普通のキーボード）
    - エルゴノミクス（人間工学に基づいて使いやすいとされる形状）
    - 真ん中で2つに分離するもの（エルゴノミクスの一種）

## 有名なキーボード
キーボードと言えば？という話題で比較的よく挙げられるキーボードをいくつか紹介してみます。

### 東プレ「Realforce」
高級キーボードの代名詞。キースイッチには静電容量無接点方式が採用されており、打ち心地と耐久性を兼ね備えています。形状は一般的なキーボードですが、日本語配列／英語配列、テンキーあり／テンキーレスなどラインナップも豊富です。

### FILCO「Majestouch」
メカニカルキーボードといえばこちら。キー1つ1つにスイッチが配置されているのですが、そのスイッチにはいくつか種類がありスイッチの色で分類されます。代表的なのは、

- 青軸 ... スイッチ感があり、押す度に「カチ」とクリックしたような音が鳴る
- 赤軸 ... スイッチ感はなく、キーは軽め
- 茶軸 ... 青軸と赤軸の中間くらい、程良いクリック感とキーの重さ

で、これ以外にもキーの重さ違いなどで別色があります。（黒軸、白軸とか）

### PFU「Happy Hacking Keyboard」
通称「HHKB」、俗に変態配列と呼ばれる少し変わったキーボード。キーの数が60個と極端に少なくテンキー、F1などのファンクションキー、矢印キーなどがありません。（Fnキー＋特定のキーで代替）
私はこれを使っていますが、使ってみると実はそんなにおかしなキー配列でもなく、使ってたらすぐに慣れました。
キーが少なくかなりコンパクトなため、手の移動範囲も少ないですし、机を広く使えるのもメリットかと思います。

上記以外にもMicrosoftはエルゴノミクスキーボードで評価が高いですし、ロジクールは比較的安価で豊富なラインナップが用意されているので愛用者も多いかと思います。

## 良いキーボードってなんだろう？
高価なキーボード＝良いキーボード、なんてことは決してありません。
多くの人が勧めるキーボード＝良いキーボード、でもありません。

高価ということは機械的に優れていたり、内部的にすごい技術が使われていたりするのでしょう。多くの人が勧めるということは、きっと優れた機能を持っていたり、何かしら魅力があったりするのでしょう。

私は今はHHKBを気に入って使っていますが、今までで一番手に馴染んだキーボードはHHKBでも有名なキーボードでもなく、PCを自作した時にパーツ屋でサービスでもらった無銘のメンブレンの109キーボード（きっと1000円以下）です。

数年酷使した結果、リターンキーが潰れてしまい微妙な角度で押し込まないと認識されない状態になってしまいましたが、そんな状態でも使いやすかったし愛着もあって使い続けてました。最後はどこかが断線したのか全く言うことを聞いてくれなくなり廃棄しましたが。。

キーボードは道具、結局のところ「自分が使いやすいかどうか」「愛着を持って使い続けられるかどうか」が大事だと思っています。
（ただ「愛着を持って使い続けられるかどうか」という点で、見た目は実はかなり大事かなと思ってはいます）

## おわりに
値段はピンキリ、形状もデザインも打ち心地も千差万別、そんな中から皆さんも自分の手に合うキーボードを探してみませんか？

プログラム技術が身につく訳でもないし、タイピング速度が飛躍的に向上する訳でもないけれど、我々エンジニアが長時間を共にするキーボード、お気に入りの一品が見つかれば、きっとプログラムも楽しくなると思います！
サーバ上へのMeCabインストールメモ（忘備録）


サーバ上で形態素解析する機会が出来たので導入。
sudo使えないのでどうしようかと思っていたが、ドンピシャな記事をかかれていた方がおられたので丸パクで。。。

微妙に詰まったけどなんとかなった。


http://qiita.com/ragzboned/items/834c0bc3caaa494fc906
を参考に！（リンク先の方に感謝 m(_ _)m）

リンク先 **(5) Python向けモジュールのインストール** でsetup.pyが不具合で動かなかったので、

	pip install mecab-python3
	pip install --upgrade mecab-python3

で読み込み完了！以上！
（Mecab及び辞書のインストールはできているので、setup.pyは動かなくてもpythonのwrapper入れば問題無し）


：追記（20161212）
何故かpython3でインポートできなくなっていたました。
wrapperが2系で入っているため、3系では認識しない模様。。
MeCabをsudoでインストールできていれば```pip```で読み込めると思うんだが、```local```に入れているため認識しない模様...```pip```のインストール先を変更しても無理だった。

 - [natto-py 0.8.0](https://pypi.python.org/pypi/natto-py)
を入れた所動作したので、とりあえずはこれでok

		$ pip3 install natto-py

```python
from natto import MeCab

nm = MeCab()

print(nm)

<natto.mecab.MeCab model=<cdata 'mecab_model_t *' 0x802016640>,
    tagger=<cdata 'mecab_t *' 0x8020a44c0>, 
    lattice=<cdata 'mecab_lattice_t *' 0x802079600>, 
    libpath="/opt/mecab/lib/libmecab.so", 
    options={}, 
    dicts=[<natto.dictionary.DictionaryInfo 
        dictionary=<cdata 'mecab_dictionary_info_t *' 0x802079480>,
        filepath="/opt/mecab/lib/mecab/dic/ipadic/sys.dic", 
        charset=utf-8, 
        type=0>], 
 version=0.996>
```		

以上
スタートアップに放り込まれた学生、JavaScriptを学ぶ その1

こんにちは、CureAppの新卒1年目、@imoansです。私は新卒ではありますが、実は会社の古株でもあるんです。
あれは2年前、まだ会社が設立してまもない頃。プログラミング駆け出しの学生だった私が、開発メンバーとして放り込まれました。
そこから現在に至るまで、目まぐるしく進化するJavaScriptに目を回しながら食らいついていった実体験を紹介します。


# 放り込まれる前の話
## プログラミング、本気でやってやろう
2年前の私は、重たいWindows機でインターネットとレポートを書くだけの学生でした。
プログラミングを始めるきっかけとなったのは、CTOの@shinout氏との出会い。
もともとWebサイトやアプリを作りたいとぼんやり思っていたので、相談すると「本気でやるなら色々教えるよ」とのこと。早速Windowsを売り、勧められたMacBook Airを買って覚悟を表明しました。すぐさまMacBook Airは、氏によってなにやら色々インストールされカスタマイズされました。振り返るとここでhomebrewやらXcodeやらが入っていたのでした。


## 基礎の基礎から
これでやっとプログラミングができる！とワクワクしていた私ですが、甘かった...。タイピングは遅すぎるし、ブラウザのショートカットも使えないなど、基礎ができていない状態だったのです。1ヶ月「すし打」でタイピングを鍛え、ショートカットもひたすら使って覚えて、今度こそプログラミングだ！


## マウス禁止のあのエディタ
そう思っていたのも束の間。次の課題は、マウス禁止のあのエディタ、「Vim」でした。
Sublime TextやAtomなどという選択肢を知らないまま、プログラミングに必須の技術ということで叩き込まれました。2週間もすると、矢印キーを使う意義も感じなくなり、これもクリア！にしてもいつコードを書けるんだろうか...。


## プログラミング開始！
いよいよプログラミング開始。お手軽に学べて、CureAppでも使っているというJavaScriptをやってみることにしました。文法はネットで勉強してねと言われ、ドットインストールとschooを紹介されました。そこで基礎的な文法を一通りやった私は、なにかコードが書きたくてウズウズするようになりました。もともと、サイトの文章を自動で持ってきたい(スクレイピングのことです)、と思っていたので、それに挑戦しようとしたのですが、あっさり挫折。まずは世にあるプログラミングの問題でも解いてみようということで、paizaをやり始めました。


## お題は簡単なのに...stdinってなんやねん
paizaの問題は、難易度がいろいろありますが、簡単なものは例えば「数字の文字列を受け取って、それを足し合わせましょう」のようなレベルのものでした。これぐらいなら解けるだろと思い、自分の得意な言語 = JavaScript を選択。すると現れたのは...

<img width="448" alt="スクリーンショット 2016-12-06 0.27.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/88394/211f557c-ff3b-19cd-d7c0-7375936d434f.png">

え、なにこの呪文。


得意な言語を選んだら、見たこともないコードが現れ、「あ、これ初心者厳しいわ...」。
結局当時は、「そういうもの」として受け入れるしかありませんでした。


## 「そういうもの」で解けない問題、現る
しかしpaizaを進めていくと、この`process.stdin.on(‘data’`を理解しないと解けない問題が出てくるのでした。
今でも忘れられないのが、paizaのストーリー型の問題で、うまく解けると主人公の男性が憧れの女性とハワイ旅行に行けるというもの。しかし、どうしても最後のケースがうまく通らず、ストーリーがいい感じに進まなくて、箱根旅行になってしまっていました。


で、この上手く行かない理由、なんと、


「標準入力のサイズが大きく`process.stdin.on(‘data’, fn)`が2回実行されたから」


でした。当時、そんな事情など全く知らず、@shinout氏に「これはひどい…」と言われながら解いてもらいました。解けた後、種明かしをされても理解できず、プログラミングは奥が深すぎる、とおののくばかりでした。


そんなこんなで徐々にJavaScript力をつけていった私は、プログラミング開始してから約半年、ついにCureAppで働かせてもらえるようになります。
さらにJSに打ちひしがれる日々が始まるのです。


続く...。




# この時期を振り返って
## プログラミングの醍醐味を味わうまで
try & errorが最もしやすいプログラミング。しかし、その醍醐味を味わうには、様々な障壁がありました。
タイピングやショートカット、エディタなどの基礎力、そして環境構築。これらを飛ばしてtry & errorをしても、醍醐味には辿りつけなかったでしょう。ドットインストールやschooをやり始める前に、基礎力がついていたことが自分を後押ししていたなと思います。


## JavaScriptからプログラミングを始めるということ
JavaScriptは、よく「手軽に始められる」というメリットが挙げられています。Chromeのデベロッパーツールなどが引き合いに出されて。それはそのとおりなのですが、今のJavaScriptは初心者にも「環境」への理解を強いる言語です。ブラウザとコマンドラインの違いが分からないと、同じJavaScriptでも全然実行できません。検索しても、それがどの環境のものなのかを考える必要がでてきます。paizaの簡単な問題に答えるにも、Nodeの複雑な標準入力の仕組みを利用する必要があります。
そこを乗り越えるのは、「手軽」の一言では片付けられない難しさがあったなと思います。


次回は、会社にアルバイトとして入ってから、Promiseやbrowserifyに出会った、JS初心者の思いを綴ります。乞うご期待ください。


明日の[CureApp Advent Calendar](http://qiita.com/advent-calendar/2016/cureapp)は@fitzrさんです！
フリーランスと会社の違い

先日の記事が、なんだかはてブまで晒されて、炎上していますが、
ほぼ実話の話ですし、全然盛っていません。

まあ今日は、フリーランスと会社員の違いを比較してみます。

# フリーランスの社会的ポジション

 - 健康保険と年金は、国民健康保険と国民年金。
 - 法人でないと、厚生年金や協会けんぽは使えない。
 - 青色申告だと、経費は年間約７２万円まで。
 - 基本邸には自営業。
 - 雇用保険はなし。
 - 肩書きは、何でも名乗れるｗ
 - 屋号（会社名では無い）を税務署に登録することが出来る。
 - あくまで個人事業なので、法人関係の税金は非課税。

# 会社員（経営者）のポジション

 - 健康保険と年金は、国民健康保険と国民年金でもよいが、協会けんぽ等の健康保険組合の方が、月々の保険料は安い場合がある。
 - 国民年金ではなく、厚生年金扱いなので、年金の支払い額が（あった場合）は、現役の給与の半額程度
 - 法人として法務局に登記する必要がある
 - 法人として会社名は、同一法務局内に同じ会社名が無ければ登記可能
 - 登記には登記印紙代が必要（１０万円弱から25万円程度）
 - 経営者には雇用保険はなし
 - 年１回、決算日（決算月）を決めて、１年間の出納台帳を作成しなければならない
 - 会社（法人）と従業員（経営者も含む）は、別人格として扱う（これ重要）
 - 法人は決算が赤字であったとしても、最低限の法人県民税（都民税）、法人市民税（区民税）を支払う必要があり。だいたい年間７万円
 - 税理士や会計士と顧問契約をするとそのあたりも相談に乗ってくれる
 - 経営者の給与は、「役員報酬」となるので、決算時に役員会議で決定すると１年間変更ができない。(帳簿上は貰っていることになっているけど、実際に貰えないことが多い）
 - 退職金掛け金など、経費計上出来る保険金などがある

# 会社員（従業員）のポジション

 - 基本的には、会社が用意した健康保険と年金を利用する。（酷い会社だと、健康保険や年金は自腹という会社もある）
 - 正しくは、健康保険と厚生年金は会社と5割ずつの折半で支払う。なので、自己負担は半額
 - 雇用保険と労働保険があり（無い会社もあるけどね。違法だけど）
 - 従業員は労働組合を設立する権利はある。（まあ、面倒くさいからしないケースが多いけど）
 - 会社が仕事内容を指示するので、会社が指示した仕事を失敗しても、会社から損害賠償請求はされない。（時々、脅迫で損害賠償請求をするなんていう違法な会社がありますが、会社から指示された業務を正しくやっている限り、会社が従業員を訴えることはできるけど、裁判で負けます）
 - 市県民税は、基本的には特別徴収という形式で給与から天引きされる。（最近、特別徴収の徹底化がうるさいです）


まあ、極々一部ですが、フリーランスと経営者、サラリーマンを税金や待遇の面で並べてみましたが、このごく一部でもサラリーマンは優遇されている世の中です。

よほど、自分の腕（スキル）に自信がない限り、フリーランスはおすすめしないよ。

うーん、本当ならもっと違うことを書きたかったんだけど、明日以降は頑張ります。

あ、技術的要素が少ないって噛みつかれたけど、エンジニアの技術って、プログラミングやシステムの技術だけが「技術」じゃないと思うんだよね。

会社の職場内でも世代間の交流が少ないWeb系やIT系だからこそ、おっさんが経験したことを、若い人達に知識として知って欲しい。
そんなことで、Adventカレンダーを書いています。

プログラムやシステムの技術が知りたければ、他のAdventカレンダーを見て下さい。
ここは、エンジニアが生きていくための「技術」を、おせっかいなおっさんが淡々としゃべっているカレンダーです。
PythonでMIDIフェーダと通信するメモ（MIDIデバイス→PC)

以下のtweetで，つまみやらスライダが大量にくっついたMIDIデバイスが存在するらしいことを知った．
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">DaVinci Resolveを、MIDIデバイスでコントロール出来るようにするツール「MIDIGrade」 | 映像職人 <a href="https://t.co/FJXsdm6kKl">https://t.co/FJXsdm6kKl</a> <a href="https://t.co/k431Dc9Y1N">pic.twitter.com/k431Dc9Y1N</a></p>&mdash; 映像職人 (@eizoushokunin) <a href="https://twitter.com/eizoushokunin/status/768269530669862912">2016年8月24日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

探してみたところ，USB接続で手頃な価格（ヨドバシで￥4,000なり）のデバイスを発見．色々とパラメータを調整したりするのに便利そうだったので，MIDIコントローラとPythonで通信してみた．
http://www.korg.com/jp/products/computergear/nanokontrol2/

# 使ったもの
## Korg nanoKontrol2
上で紹介した[これ](http://www.korg.com/jp/products/computergear/nanokontrol2/)．
安い，小さいととりあえず試してみるにはぴったりなデバイス．
ボタン3つとつまみ，スライダのセットが8chあるほかにボタンが10個ぐらいある．
設定ソフトでボタンに付いたLEDの動作モードとか，ボタンの動作モード(トグルかモーメンタリか）が選べたりと意外と高機能．

## Python3 + rtmidi2
先行研究([「[python][web audio api]ブラウザとMIDIコントローラを繋げてみる。」](http://d.hatena.ne.jp/miujun/20120430))によれば，PythonからMIDIデバイスを読むには[pygame](http://pygame.org)を使えば良いらしい・・・
しかし，pygameは機能が多すぎるし導入は面倒だしで今回は見送り（便利なんだけどね！）．
そこでMIDIライブラリ[RtMidi](http://www.music.mcgill.ca/~gary/rtmidi/)のラッパーである[rtmidi2](https://pypi.python.org/pypi/rtmidi2)を使ってみた．
RtMidi自体がプラットフォーム依存では無いためrtmidi2もクロスプラットフォームらしい．最近，Windowsに対応してないライブラリが多い気がするのでありがたい話である．
ただし，C++のRtMidiをほんとうにそのままラップしただけらしく，結構Pythonicで無いところがある．

# 通信サンプル

以下は，接続されているデバイスからnanoKONTROL2を検索し，デバイス→PCのメッセージを延々と表示するサンプルと実行中にボタンを押したりつまみを回したときの出力である．`get_message()`で得られるMIDIデバイスからのメッセージは3要素のuint8_t配列で，1要素目がの上位4bitがメッセージタイプ，下位4bitがチャンネル，2項目がノート番号，3項目が変更後の値になっている．
よって，基本的に2項目と3項目を確認すれば，どのつまみやスライダがいくつの値になったかが確認できる．

``` python
import time
import rtmidi2

midi_in = rtmidi2.MidiIn()
print(midi_in.ports)

device_name = "nanoKONTROL2"
try:
    index = midi_in.ports_matching(device_name+"*")[0]
    input_port = midi_in.open_port(index)
except IndexError:
    raise(IOError("Input port not found."))

while True:
    time.sleep(0.01)
    message = input_port.get_message()
    if message: print(message)
```

```python:出力
[u'nanoKONTROL2 0']
[176, 34, 127]
[176, 34, 0]
[176, 50, 127]
[176, 50, 0]
[176, 18, 1]
[176, 18, 2]
[176, 18, 3]
[176, 18, 4]
[176, 18, 5]
[176, 18, 6]
[176, 18, 7]
[176, 18, 8]
[176, 18, 9]
[176, 18, 10]
[176, 18, 11]
# 以下略
```

# 注意点

## ポーリング間隔

上のサンプルでは，MIDIデバイスからのメッセージをポーリングで確認した．しかし，このポーリング間隔を短くしすぎるとPCがフリーズしてプロセスを殺すことさえ出来なくなるので注意．実際には，[rtmidi2のreadme](https://github.com/gesellkammer/rtmidi2#get-incoming-messages-using-a-callback----non-blocking)にあるように，コールバック関数を定義して非同期に処理をした方が無難．

## メッセージのタイミング

非常に残念なことにMIDIデバイスがPCにメッセージを送信するのは，デバイスの状態が変化したときだけの様子．
そのため，アプリケーション起動直後に現在のつまみやスライダの状態を一括で取得するといったことは出来ない．
欲を言えば任意のタイミングで任意の軸の現在値を取得できることが望ましいが本来そういう用途をするための物では無いので我慢である．

# 最後に

早いところPC→MIDIデバイスについても書いてしまいたい．
ページ単位のjavascript読み込み

# app/assets/javscripts/application.jsの修正
以下のコードの削除

```ruby:application.js
//= require_tree .
```

共通のjavascript配置
common.jsの呼び出し

```ruby:application.js
//= require common
```

コントローラ/アクション.js 形式でjavascriptの配置

app/assets/javascripts/top/index.js とか
app/assets/javascripts/top/create.js とか

views/layouts/application.html.erb の修正

```
<!DOCTYPE html>
<html>
<head>
  <title>TestJs</title>
  <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true %>
  <%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>
  <%= csrf_meta_tags %>

<%= javascript_include_tag "#{params[:controller]}/#{params[:action]}" if Rails.application.assets.find_asset("#{params[:controller]}/#{params[:action]}.js") %>

</head>
<body>

<%= yield %>

</body>
</html>
```


config/initializers/assets.rb の追加

```
Rails.application.config.assets.precompile += %w( top/index2.js )
```
「いいね」と「ストック」の位置を入れ替えるchrome-extension作りました！

先週以下のようなエントリをあげました。

[【注意！】Qiitaの「いいね」ボタンを押しただけだと記事はストックされませんよ！]
(http://qiita.com/gimupop/items/be53044143a9a3e90a4b)

みなさんの意見を見るに 
•ストックの位置にいいねが出来て押し間違えるのが頭にくる
•いいねを作った意義は多少理解できる
•いいねという概念ができて、運営が推す以上無視できない


と言うような感じかなと考え、いいねとストックのボタンを入れ替えるエクステンションを書いたので共有します。

#物はこれ
https://chrome.google.com/webstore/detail/qiita-like-change-stock/plhkhinekepahfoobginckihianlmeli?utm_source=chrome-ntp-icon

適用前
![image](https://qiita-image-store.s3.amazonaws.com/0/72169/5fd263d9-17a7-6175-11ad-b446c8458979.png)


適用後
![image](https://qiita-image-store.s3.amazonaws.com/0/72169/8514c968-a9f0-d292-45f6-fbf5f48caee2.png)

当たり前ですが、ストックと未ストック、いいねと未いいねは、ボタンが変化してビジュアルでわかるようにしてます。下部のストックといいねにも反応してボタンのビジュアルが変わります。

![image](https://qiita-image-store.s3.amazonaws.com/0/72169/65948c46-59fb-9e88-c2a6-5b79ca5d2abe.png)


自分はこのエクステンションを使って、押し間違え等のトラブルが減ってQOLが回復しました。同様の問題で悩んでいる方は、ぜひ使用して見てほしいです。


※もともといいねをストックで覆い隠すという雑なエクステンションだったんですが、多少綺麗に作り替えました。コードは力技ですが。

いいねを完全になくして、ストックボタンを押すと同時にいいねも押すパターンも作ったので、もし要望があれば配布します。使用感としては完全に昔のUIに戻すやつです。

現状、いいねした記事をフィルタリングできないいじょう、ストック中心の運用を行わざるを得ないので、ストックがメインになるこのエクステンションを書きましたが、ストックもContribution入るようにしてほしいですよねー。
Contribution上がるとすごい嬉しいしあげてあげたいけど、二つ押さないといけないのはちょっと面倒くさいですもんね。

一応コードはこれです。役に立ったらスターください！
https://github.com/gimupop/qiitaStockExtension
bump upを手でやらずにgemでやる

## <i class='fa fa-wrench'></i> bump gem
[bump](https://rubygems.org/gems/bump) gem は Ruby で bump up を支援してくれるツールです。
CLIとしての用法と、Rake Task としての用法があります。

## <i class='fa fa-download'></i> インストール
```sh
$ gem install bump
```

## <i class='fa fa-file-text'></i> CLI仕様
|command|description|
|:---:|---|
|current|現在のバージョンを確認|
|patch|パッチバージョンを更新|
|minor|マイナーバージョンを更新|
|major|メジャーバージョンを更新|

セマンティック バージョニングにもとづいてバージョンを更新します。
セマンティック バージョニングについては下記を参照ください。

[セマンティック バージョニング](http://semver.org/lang/ja/)

## <i class='fa fa-flask'></i> デモ - CLI
```sh
$ bump current
Current version: 0.1.0
$ bump patch
[master 037cb55] v0.1.1
 1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 0.1.0 to 0.1.1
$ git log --oneline
037cb55 v0.1.1
```

```sh
$ bump current
Current version: 0.1.1
bd9f1d4 test
$ bump minor
[master 0c5659e] v0.2.0
 1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 0.1.1 to 0.2.0
$ git log --oneline
0c5659e v0.2.0
037cb55 v0.1.1
bd9f1d4 test
```

```sh
$ bump current
Current version: 0.2.0
$ bump major
[master c5f6f14] v1.0.0
1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 0.2.0 to 1.0.0
$ git log --oneline
c5f6f14 v1.0.0
0c5659e v0.2.0
037cb55 v0.1.1
bd9f1d4 test
```

## <i class='fa fa-flask'></i> デモ - Rake
```ruby:spec_helper.rb
require "bump/tasks"
```

```sh
$ rake -T | grep bump
rake bump:current[tag]  # Show current gem version
rake bump:major[tag]    # Bump major part of gem version
rake bump:minor[tag]    # Bump minor part of gem version
rake bump:patch[tag]    # Bump patch part of gem version
rake bump:pre[tag]      # Bump pre part of gem version
rake bump:set           # Sets the version number using the VERSION environment variable
```

```sh
$ rake bump:current
Current version: 1.0.0
$ rake bump:patch
[master 539ab50] v1.0.1
 1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 1.0.0 to 1.0.1
$ rake bump:current
Current version: 1.0.1
$ rake bump:minor
[master 2c43b90] v1.1.0
 1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 1.0.1 to 1.1.0
$ rake bump:current
Current version: 1.1.0
$ rake bump:major
[master e0928c7] v2.0.0
 1 file changed, 1 insertion(+), 1 deletion(-)
Bump version 1.1.0 to 2.0.0
$ rake bump:current
Current version: 2.0.0
$ git log --oneline
e0928c7 v2.0.0
2c43b90 v1.1.0
539ab50 v1.0.1
c5f6f14 v1.0.0
0c5659e v0.2.0
037cb55 v0.1.1
bd9f1d4 test
```

## <i class="fa fa-book" style="font-size:1em;"></i> 外部資料
* [gregorym/bump - RubyGems](https://rubygems.org/gems/bump)
* [gregorym/bump - GitHub](https://github.com/gregorym/bump)
gibbon gemでmailchimpのリストを作成しメンバーを追加する

# ざっくりいうと

mailchimpをgibbonというgemで操作してみた。です。

APIを操作して

* リストの作成
* リストに対してメンバーを登録する(バルク)

をします。

# 環境

* gibbon 2.2.4
* mailchimp APIv3

```
MailChimp API v3.0 is now live!
Prior versions will no longer be supported after 2016, so all API users should begin transitioning to v3.0.
Check out the API v3.0 Documentation for more details.
```

v2おわるよーとのこと(自分が見たとき公式gemがv2相当のように見えた、はて？)


# 手順

## API キーをゲットする

公式のページが動画で紹介しているので迷わずゲットできそう。
http://kb.mailchimp.com/integrations/api-integrations/about-api-keys#Find-or-Generate-Your-API-Key

## gibbonのインストール

gemから

```
$ gem install gibbon
```

です。

## コード部分

まずはrequire

```ruby
require 'gibbon'
```

次に先程取得したAPI KEYを設定します。

```ruby
gibbon = Gibbon::Request.new(api_key: <取得した api_key>)
```

### リストの作成

APIのページはこちら => http://developer.mailchimp.com/documentation/mailchimp/reference/lists/#create-post_lists

API的には post /list にlistを作成するためのデータを与えてcreateする感じです。
そのパラメータが必須なものが結構多く、下みたいな感じになりました。
ここに入力する内容は、mailchimpのGUIでリスト作成時に入力している内容を見てみるとわかりやすいかも。

```ruby
list_params = {
  name: @list_name,
  contact: {
    company: 'company name',
    address1: '0-0, XXXXX',
    address2: 'XXXX Bldg',
    city: 'XXXXX-ku',
    state: 'Tokyo',
    zip: '000-0000',
    country: 'JP',
  },
  permission_reminder: 'message',
  campaign_defaults: {
    from_name: 'NAME',
    from_email: 'test@example.com',
    subject: '',
    language: 'ja',
  },
  email_type_option: true,
}

# 次でlistのidをとるためにresponseに入れている
responce = gibbon.lists.create(body: list_params)
``` 

こんな感じでbodyに与えてあげると作成できました。

### 作ったリストにアドレスを追加

次にリストにアドレスを追加します。普通にアドレスを1個ずついれるだけであれば
gibbonの公式を見ればそのままやり方が書いてあった気がするのでそちらを試していただくと良さそう。
わたしは数千、数万登録をする必要があったのですが、一斉登録で登録できる件数が500アドレスまでと決まっていてそれ以上はbulk処理をする必要があるとのことで以下はその感じになります。

```ruby
# 2件しか書いてませんがいっぱいあるイメージ
emails = [
  { email_address: 'receiver1@example.com', status: "subscribed" },
  { email_address: 'receiver2@example.com', status: "subscribed" },
  ...
]

# バッチ処理用のオペレーションパラメータを作成
# 本来1つずつ飛ばすAPI呼び出しをoperationsの中にガンガン突っ込んでいく
operations = []
emails.each_slice(500) do |emails_block| # 一つ分のAPI呼び出しにつき500件までな為配列から500ずつ取り出す
  operations << {
    method: 'POST',
    path: "/lists/#{response['id']}",  # response['id']はさっき作成したリストのID
    body: { members: emails_block }.to_json # <= ここのjsonにするタイミングが公式見てもよくわからず恐ろしくハマった。
  }

# バッチを呼び出して実行
batch_response = gibbon.batches.create(body: { operations: operations })
```

これで作成出来ました。
バッチは少し時間がかかるので、ちょっとまってから管理画面を見てみると反映されていたりします。
コード上ではバッチもIDを持っているのでそれに対して、retriveしてあげるとレスポンスに`status`というものがあるのでそれをみてあげると start/pending/finishが確認できます。

```ruby
response = gibbon.batches(batch_response['id']).retrieve
response['status'] #=> "finished"
```

の感じ。
バッチ処理のパラメータの渡し方はあまり検索していても乗っていなくて、かなりハマったので、もしかしたらご覧になっている方の環境では動かないかもしれないので、何卒。参考になれば幸いです。

メモを残していたものから走り書きしたので、何かと間違っていたらゴメンなさい。
クリッピング平面についてのメモ

とあるSlackのチャンネルでちょっと前に話されていたのを思い出して、メモとして残しておこうと思います。
（Three.jsのAdventCalendar（[Three.jsでのクリッピング平面の利用](http://www.kabuku.co.jp/developers/threejs_clipping)）見てふと思い出したのでｗ）

## 概要

そもそも、OpenGLには[glClipPlane](https://www.opengl.org/sdk/docs/man2/xhtml/glClipPlane.xml)という、クリッピング平面を指定する方法があるようです。
しかしWebGLではまだサポートされておらず、Three.jsではそれをフラグメントシェーダで行ってるよ、という会話があったのでそれの備忘録です。

※ ちなみに上記のSlackは[こちら（webgl-jp）](https://arcane-depths-9129.herokuapp.com/)から参加することができます。興味がある方はぜひ！

## Three.jsでの実装

どうやらフラグメントシェーダに以下のコードを追加することで対応しているようです。（by [@technohippy](https://twitter.com/technohippy)さん）

```glsl
#if NUM_CLIPPING_PLANES > 0
 for ( int i = 0; i < NUM_CLIPPING_PLANES; ++ i ) {
   vec4 plane = clippingPlanes[ i ];
   if ( dot( vViewPosition, plane.xyz ) > plane.w ) discard;
 }
#endif
```

大事なポイントは

```glsl
if (dot(vViewPosition, plane.xyz) > plane.w) discard;
```

の部分です。
つまり、「**フラグメントの位置と平面の位置ベクトルとの内積の結果**」が「**クリッピング平面の`w`の値**」より大きい場合にフラグメントを破棄することで実現しています。

ちなみにそのときに[@technohippy](https://twitter.com/technohippy)さんに図解してもらったのが以下の図です。
（今回用に清書しました）

![クリッピング平面.png](https://qiita-image-store.s3.amazonaws.com/0/5616/d78d3e00-e903-f903-844f-fe8cf671570a.png)

※ ちなみに `plane.xyz` は「平面の方向」であり、実際の位置ではなく正規化された値が入っています。

### Slackでの会話

Slackで [@h_doxas]() さんがとても分かりやすく解説してくれたのでそれをメモとして残しておこうと思います。
以下、doxasさんとのやり取り。

```
doxas
半径１０の球体があって 
高さ５のところに、法線が Y 方向にまっすぐ向いている面がある
球体の北極点のところは、法線がやっぱり Y 方向にまっすぐ向いてる 
北極部分の頂点座標と plane.xyz を内積で計算すると、計算結果は （0, 10, 0） 
これと、plane.w に相当する ５ を比較してやるといい

edom18
さすがの解説力・・・！

doxas
つまり内積した結果と、面との距離とを比較することで、一定の面以上のきょりにあるかどうかわかるというわけ
```

なんとも分かりやすい・・！

ちなみになぜ `plane.w` と比較しているのかというと。

`w` の値はプロジェクション行列の計算で算出されます。
そしてその値はオブジェクトの `z` の値がそのまま格納されます。
（そして後の工程で `w` で割ることですべてのオブジェクトを `0 ～ 1` or `-1 ～ 1` に正規化する同次座標系への変換に使われます）

なので図のように「**内積を取り、その結果と `w` を比較する**」ということは、そのままクリッピング平面との距離を比較している、というわけなのです。

そして結果として距離以上の（`w` より大きい）場合は平面を超えていることになるのでフラグメントを破棄している、というわけです。

それを踏まえて上の図を改めて見てみると、`w` の値がクリッピング平面との距離以上の場合に破棄するとクリップされることがよく分かると思います。
文字列を1文字ずつに分解する

bashやshellsciriptにおいて、文字列を1文字ずつに分解するとき、個人的にまず思いつくのはawkを利用する方法です。

```bash
echo 'helloworld' | awk -v FS='' '{
    for (i = 1; i <= NF; i++) print $i;
}'
```

`FS`はフィールドのセパレータを指定する組み込み変数であり、上記の例では空文字列を指定するで文字列を分解しています。上の例では分解してできた文字をそのまま標準出力に流していますが、__「その文字を利用して何らかの処理をしたい」__場合には、文字列操作にたけたawkを利用するのは大きな利点だと思います。

__文字列操作はとりあえずawkで何とかしたい派__のわたしとしては上の例で満足ですが、「文字列分解だけしたい。そのあとは別のコマンドに処理を流したい」というときにはややくどいのも事実。また__シェルスクリプト過激派の一部にはawkすら利用することをためらう/禁じる宗派も存在する__そうです。そういうときは`fold`を利用しましょう。

```bash
echo 'helloworld' | fold -s1
```

`fold`の存在を最近知ったのは内緒(´・ω・`)
Solrのインデックス削除のパフォーマンス

[Solr Advent Calendar 2016](http://qiita.com/advent-calendar/2016/solr) の6日目です。


# 経緯
ある日、私が担当していない違う現場のSolrの更新速度がいきなり落ちた(今まで1分ほどだったのが、２０分近くかかるようになった)ので見て欲しいと言われました。調べたところ削除リクエストの大幅な増加に起因するものでした。
今回と同じケースで問題になることはあまり無いと思いますが、せっかくなので記事にしたいと思います。

# Solrの削除リクエスト
Solrのインデックスから削除するドキュメントを指定するフォーマットには大きく２種類があります。
１つがユニークキーを指定する方法です。

```
{"delete":{"id":"500000"}}
```

これは下記の用に配列のように指定することもできます。

```
{"delete": ["500000", "500001"]}
```

もう１つがクエリで削除するドキュメント指定する方法です。
何らかの条件に合致するドキュメントをまとめて削除するのに適しています。
先に今回の結果を言うと、これが上手く使えていないために急激な削除パフォーマンスの悪化を招いていました。

```
{"delete":{"query":"id:500000"}}
```

今回は大量のドキュメントを削除する場合にどう指定すると高速に削除できるのかに注目して調査をしたいと思います。

# 調査に使ったインデックス
[前回](http://qiita.com/tkondo/items/20f5319b8ac5876ad881)と同じです

# Solrのバージョン
5.5.2


# 調査したパターン
インデックスが100万件(optimize済み)の状態から、1度の更新リクエストで5万件のデータを削除します。
初期のインデックスは同じデータで作られていて、削除対象のドキュメントも全て同じものを削除します。

指定する削除フォーマットは下記の４パターンになります。

1. 削除対象のドキュメントをユニークキーで指定
 * {"delete":{"id":"500000"},"delete":{"id":"500001"}, ... "delete":{"id":"550000"}}


2. ユニークキーを配列で指定
 * {"delete": ["50000", "50001", ... "55000"]}

3. 完全一致検索クエリで指定
  * {"delete":{"query":"id:50000"},"delete":{"query":"id:50001"}, ... "delete":{"query":"id:55000"}}

4. 範囲検索クエリで指定
  * {"delete":{"query":"id_int:[500000 TO 550000]"}
  * id_intはユニークキーを範囲検索で削除するために、idをコピーフィールドしたもの


# 結果と考察
|            |  処理時間(秒)|
|:-----------|------------:|
|    パターン1|          0.489|
|    パターン2|          0.422|
|    パターン3|          52.803|
|    パターン4|          0.445|

パターン2 > パターン4 > パターン1 > パターン3 の順番となりました。
概ね直感通りの結果になったと言えます。
まずパターン３ですが、これが冒頭で述べた更新速度低下の原因でした(そこは新しいインデックスの更新と削除をバッチでまとめてやっていた)。
見て分かる通り、何度も完全一致で削除対象のドキュメントを検索しているので、その分のオーバーヘッドがかなり大きく、時間がかかっていると思われます。
一方で、パターン4は１度の検索で大量のドキュメントを削除するため効率が良かったのだと思われます。
パターン1,2では２の方がわずかに高速でしたが、そこまで大きな差はありませんでした。

# パフォーマンスがいきなり落ちる問題について
過去に更新のパフォーマンスがいきなり落ちたので見て欲しいという経験が何度かあったのですが、大体が更新対象のデータが突然増えたというのが原因でした。
今回のケースも、もともと非効率なパターン３でインデックスの削除を実施していたのですが、その件数が一気に増えたことが原因でした。
いきなりパフォーマンスが悪なった場合はまずは量を疑ってみると原因に近づけるかもしれません。

# まとめ
クエリでの削除は柔軟な条件が指定できるため、条件指定で大量のドキュメントをするのに適しています。
一方でユニークキーを直接指定できる場合でそれで削除した方が高速です。
ただし、クエリでの削除はフォーマットが簡潔だったり、必ずしも削除するユニークキーが簡単に分かる状況にあるとは限らないため、ケースバイケースで適切な方法を選べればと思います。
開発PC変えてXamarinで作ったアプリを実機でデバックしようとしたら出来なかった話

#事件は突然起きる
ある日、XamarinでAndroidアプリじわじわ組みつつ、よーし実機で動作確認すっぞーと思い、いつものように実機で実行したら･･･

画面が切り替わる→（ ＾ω＾）
画面が元の状態に戻る→(´・ω・｀)
My実機は何も変わらずそこにいました。作ってるアプリ、実機に入ってないな･･･

出力コンソールにはデバッグでこう出てました

>Android application is debugging.
>The application could not be started. Ensure that the application has been installed to the target device and has >a launchable activity (MainLauncher = true).
>
>Additionally, check Build->Configuration Manager to ensure this project is set to Deploy for this configuration.


*この記事は、そんなエラーから脱出した記念に備忘録として投稿するのである。*

#当時の事件の概要
+ Xamarin.Androidで動作確認の為に実機でデバッグしようとした
+ 大学PCで作ったアプリをVisual Studio Team Service経由で自宅PCにプロジェクトを入れた
+ 自宅PCからプロジェクトをビルドしデバッグでMy実機であるAndroidに入れる
+ IDEはデバッグ用に一回切り替わり、元の状態に戻った
+ 実機は今まであった前のバージョンのアプリが消えてしまった…

#解決方法
[Debug on device — Xamarin Forums](https://forums.xamarin.com/discussion/56329/debug-on-device )に載っている通り、その開発しているアプリの情報が残っているのが原因で入らないそうです。
要は該当するアプリケーション消せよという話じゃん！はい解決～…なのですが、私は何を血迷ったのかAndroidのストレージ上から該当してるフォルダと思われるものを消したのですね…。それだけじゃダメでした。
やはり根本から消し去らないといけないので、adbコマンドでuninstallしようとしたら内部エラーでだめぽと出てしまいます。

じゃあどうやって解決したのか、それは**元のPCから開発中のアプリを入れ直しました。**
要は今回の場合、大学PCからアプリを入れ直すということですね。
そして自宅に持ち帰り自宅PCでデバッグ。それでも上記のエラーは吐きます。
でも実機上ではアプリのアイコンは消えてます。どうやら細かい見えない何かが残っている様子！
adbコマンドで以下のコマンドアンインストールする。

```
adb uninstall <Your app's package name>
```

**成功！やったぜ。**
自宅PCからビルドして実機デバッグすると無事に立ち上がりました。

###学んだこと
開発PCを変えて同じアプリをデバッグするなら

```
adb uninstall <Your app's package name>

(adbコマンドは https://forums.xamarin.com/discussion/56329/debug-on-device より引用)
```

で元あったアプリのデータを消してから入れよう。私はこれで解決しました。
決してそれっぽいフォルダを右クリックから削除とかしてはいけない。

この件でTwitterでアドバイス頂いた方々、ありがとうございました！
初めてのInline::Perl5

こんにちは、Perl 6アドベントカレンダーの六日目の投稿になります。

今まで全く使ってみたことがなかったのですが、せっかくなのでこの機会にInline::Perl5を初めて触ってみたいと思います。

# Inline::Perl5 とは

Stefan Seifert 氏作の Perl 6 から Perl 5 のモジュールを呼び出すことのできるモジュールです
もちろん Perl 5 のコードを実行することもできます

## 学習教材

+ 資料はいくつかWeb上にあがっているようです

github:
https://github.com/niner/Inline-Perl5

youtube:
Stefan Seifert (‎Nine‎) - Perl 5 and Perl 6, a great team‎ (40 min, English)
https://www.youtube.com/watch?v=ZRkots5Am1U

Stefan Seifert氏の個人サイト：
http://niner.name/talks/

# インストール方法

他にも方法はあるかと思いますが、今回はperlbrew + pandaでやります。
また、Inline::Perl5は2016/12/05時点で最新の0.22を入れてます

下記ページに従っていけばよさそうです。（手探り）:
https://github.com/niner/Inline-Perl5#building

```
$ perlbrew install --multi perl-stable -Duseshrplib # 一応 --multi付けました
$ zef install Inline::Perl5
```

# こんにちは世界!

一番簡単なコードを実行してみましょう

## コード

```pl:hello-simple.p6
use Inline::Perl5;

my $p5 = Inline::Perl5.new;
$p5.run(q'                                                                                      
    print "こんにちは世界\n";                                                                   
');
```

## 出力

```bash
$ perl6 hello-simple.p6
こんにちは世界
```

日本語でもちゃんと表示されました！


以上、初めてのInline::Perl5 でした。
次回は、@B73W56H84 さんの担当となります。それでは、お楽しみに！
PanCakeチートシート

#PanCakeチートシート
　IchigoJam用グラフィックボードPanCake用のチートシートです。
　画面レイアウトやテキスト、バイナリコマンドを送る場合に便利かもしれません。

![PanCakeScreenMap.png](https://qiita-image-store.s3.amazonaws.com/0/153092/6d5f092a-a03c-1b15-3485-b4afba52b28c.png)
D言語くんの公式グッズを買おう

# キミはD言語くんの公式グッズを知っているか？

全世界で大人気_[要出典]_のキャラクターのD言語くん。
そんなD言語くんに公式グッズが存在することは あまり知られていない。

デザインはD言語の設計者として知られるWalter Bright氏！
D言語くんファンなら垂涎モノのアイテムがここにはある…！

<b>※2019/6/23 追記</b>
新しいD言語くんマグのリンクを貼ります。画像は正常になっていました。

SOME ASSEMBLY REQUIRED MUGS
https://www.cafepress.com/mf/109464157/some-assembly-required_mugs?shop=digitalmars&productId=25298575


D-Man's Mug by digitalmars


http://www.cafepress.com/mf/1978862/dmans_mugs


![dman.png](https://qiita-image-store.s3.amazonaws.com/0/11172/b3fc15fb-4015-6b81-2fcf-0908ca676a48.png)


# 
ヤバイ（やばい）



えっと、なんか商品画像がやばいことになってますが、
D言語くんの貴重な公式グッズということで心を動かされ注文してみました。

海外通販なので注文してから到着までに2か月くらいかかった気がします。
不安の日々でした。


# そして

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">ヤター！D言語くんの公式グッズ届いたよー！ <a href="https://t.co/pgyrHrgTpG">pic.twitter.com/pgyrHrgTpG</a></p>&mdash; うえした (@ueshita) <a href="https://twitter.com/ueshita/status/715107437317980160">2016年3月30日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

ちゃんとWalterの絵がプリントされていました。よかったです。

# Digital Mars - Gift Shop

D言語の会社として知られるDigital Mars社は細々とギフトショップをしています。
D言語くん以外にも色々なグッズを売っているので、皆さんも興味があれば購入してみてはいかがでしょうか？

Digital Mars - Gift Shop
http://digitalmars.com/gift/index.html
clingをインストールしてc++のインタプリタ環境を得た

# 概要

C++のインタプリタ環境が手に入るっぽい(まだ実行していないのでわかってない)clingのインストールをしてみた。
C++の書いてビルドして実行してが面倒だったので、インタプリタ環境がないかなーと思っていました。

# 手順
<a href="https://github.com/vgvassilev/cling">https://github.com/vgvassilev/cling</a> ここにインストール方法が書いてあったんだけれど、どうもうまく行かず、 <a href="https://cdn.rawgit.com/root-mirror/cling/master/www/build.html">https://cdn.rawgit.com/root-mirror/cling/master/www/build.html</a> の方法で試したら実行できたようだった。

* shell scriptのダウンロード
    * スクリプトの実行権限を変更
        * `chmod +x ./clone.sh`
    * スクリプトを実行
        * `./clone.sh`
    * cmake がありませんとでたのでインストール
        * `brew install cmake`
    * もう一度実行
        * `./clone.sh`

もう一度実行するとインストールがすすむ 自分のマシンだと結構時間がかかりました。
実行したディレクトリにファイルができあがっていくので、
気になる人はスクリプトの中身見たほうが良いかもしれないです。
(そうじゃない人も見といたほうが良いかもしれません)

ディレクトリ752MBぐらいあった。

<pre class="lang:default decode:true " >% du -sh inst
752M	inst
</pre> 

## 実行してみた

こんな感じでした。

<img src="http://note.acairojuni.com/wp-content/uploads/2016/11/cling-640x410.jpg" alt="cling" width="640" height="410" class="alignnone size-medium wp-image-1059" />

用途的にC++だとあんまりインタプリタ要望ないのかもだけど。ちょっとしたことを確かめるのに良いかなとおもいました。ありがとうCling。
Unity SpritePackerで地味だけど快適になった画像管理について

※この記事は「[AltPlus Advent Calendar 2016](http://qiita.com/advent-calendar/2016/altplus)」の6日目の記事です。

こんにちは。オルトプラスでは主にUnityで2DGUIを作ったりしているkappalabです。

Unityは4.3系から使い始めて2年になりますがその間色々な変化がありました。特にVR周りの進化は目覚ましく、大いに語りたいと思いますが今回は極めて地味なSpritePackerについて書きたいと思います。

(Sprite Packerの設定方法は[公式マニュアル](https://docs.unity3d.com/ja/current/Manual/SpritePacker.html)をご覧ください)

# Sprite Packerってなに?

GUIオーサリングではボタンやパネル等にデザイン素材をアタッチし開発を進めていきますが、単純に進行していくと多数の画像ファイルがアプリケーションに含まれてしまいます。これは描画負荷やファイルサイズの肥大化の一因となり場合によっては大きな問題を引き起こします。

この問題を解決するには複数の画像を一枚の画像にまとめるという手法がよく知られており、前述のUnity4.3系の頃はNGUIに同梱されているAtlasツールを使用していました。（ちなみにWeb制作ではCSS Spriteなどが同種の手法と言えます）

![sp.png](https://qiita-image-store.s3.amazonaws.com/0/16284/33b9e317-3288-a7b5-279c-7076dd31c081.png)
複数の画像をひとまとめにする

## NGUI Atlas Makerの功罪

しかしNGUIのAtlasツールはいくつかの欠点がありました。

1. オリジナルファイル、結合ファイルを共にプロジェクト内に持つ
2. オリジナルファイル、結合ファイルの取り扱いを開発者が意識する必要がある
3. オリジナルファイルの変更は自動で結合ファイルに反映されない
4. メタファイルがぶっ壊れると結合ファイルもぶっ壊れる

とりわけ#1の欠点はナンセンスというほかありませんが、NGUIが悪いというよりUnityがこの手の機能を後回しにしたツケだと思っています。

対してSpritePackerでは基本的にオリジナルのみがプロジェクトに含まれ、結合ファイルはキャッシュとして保存されます。

![sc3.png](https://qiita-image-store.s3.amazonaws.com/0/16284/b793af3d-e2d2-f603-e161-172fe8d928f1.png)
(Library/AtlasCache以下に保存される)

この改善により基本的に結合ファイルは開発者から隠蔽されるので残りの欠点も自動的に解決しています。地味ですが非常に素晴らしいです。

# Resourcesに入れられない

そんなSpritePackerですが、一点だけ注意が必要です。SpritePacker対象とする画像は`Resources`に格納すべきではありません。

`Resources`に格納すると前述のキャッシュの作成対象ではなくなります。別ディレクトリでキャッシュを作成し、`Resources`へ移動することは可能ですがファイル更新などは無視されます。

`Resources`に格納する場合、ランタイムで動的で読み込むことを意図している場合が多いですが、こうした機能を満たすには`ScriptableObject`などを利用してオリジナルへの参照を保存するのが良さそうです。

また、`AssetBundle`として書き出す場合は実態としては結合ファイルが保存されていますがファイルパスベースで読み込むことができるので更に便利です。

```
bundle.LoadAsset<Sprite>("Assets/Images/Gui/xxxx_button.png")
```

# そういえばパフォーマンスって

冒頭で「描画負荷やファイルサイズが...」と言いつつ開発フローに関する話題ばかりだったので一応パフォーマンスに触れておきます。

今回のサンプルではiOS、Unity5.4.1.p1、画像枚数90枚で以下の結果となりました。

| オリジナル/SP | アプリサイズ | SetPath Call | Draw Call | 
|:-----------:|:------------:|:------------:|:------------:|
|オリジナル|88.4MB|4|96|
|Sprite Packer|72.1MB|4|68|

まずアプリサイズが20%減少と大きな効果を生んでいます。

次にSetPathCallに変化はありませんが、DrawCallは30%程減っています。実際に問題になるのはSetPathCallだとUnite等でも指摘されていますが、今回は絶対数が小さいこともあり効果を得ることはできませんでした。次回はもっと絶対数が大きくなる環境で試してみたですね。

ちなみにAssetBundleを使用した場合も同じようにPathCall,DrawCallが減少します。

# 開発環境の成熟に関して

パフォーマンスに関しては以前と根本的な変化はないので、個人的にはワークフローの改善をアピールしたいところです。

Unityは5系になってから`Instantiate`に親の`Transform`を渡せるようになったり、`SendMessage`に替わるメッセージングシステムを導入したり、`MultiSceneEditing`を備えたりと地味だけど嬉しい機能が随時追加されています。

VR関連機能も熱いですが、こういった「開発者を応援するぜ！」という気概にあふれた機能追加を続けるUnityにはこれからも期待していきたいですね。
SI→web系に転職したエンジニアのお話

これはマイネットエンターテイメント Advent Calendar 6日目の記事です。


この度は、この様な機会を頂きまして、誠にありがとうございます。
私は今年の8月からマイネットに入社させていただきました。
ゲーム運営携わることができて、充実した日々を過ごしております。


さて、今回私が話す内容は、濃い技術的な話は他の方がしていると思いますので、
転職して感じた業務系システムとweb系での開発方法の違いを記したいと思います。
 



### 確実性が最優先の業務系システムと<br>スピード重視のWeb系 
###### 1.開発手法の違い

　私が一番驚いたのが開発進行の速さです。
　業務系システム開発では、ウォーターフォール・モデル開発が、基本となります。
　業務システム開発は、開発期間が数年と長期に渡る事が多い為、
　工程進捗管理がしやすいウォータフォールモデルが使用されると思われます。
　要件定義や基本設計から参画すると、数ヶ月間エクセルで、
　設計書だけを書いてた何てことありました。
　ウォータウォール・モデルは、前工程が完了しないと、次に進めないため、
　簡単にスケジュール変更が出来なくなっており、期限厳守になりやすいです。
　業務を徐々にプログラムに落とし込んで行く為、
　実装時には設計書の内容をそのまま書くだけで、あまり考えないで
　実装できることもありました。
　現在行なっているweb系開発は、アジャイル開発が基本となり、
　仕様書から実装を行います。ソースコードを書きながら設計を考えるため、
　難しく思いました。また、機能をみながら進捗していくため
　日々開発して行くことになり、ソースコードをいじる期間が長いです。


###### 2.テストの考え方の違い

　また、テストの違いも大きくありました。
　業務系システム開発は、試験はVモデルで行うことが多かったです。
　Vモデルとは、試験工程を単体テスト(PT)、結合試験(IT)、
　システムテスト(ST)、受入れテスト(UT)と段階で分け、
　それぞれを設計工程を下記のように紐づけて試験を行います。
　* 単体テスト　→　詳細設計
　* 基本設計　→　結合試験
　* 要件定義　→　システムテスト
　* 要求分析　→　受け入れテスト

　単体テスト(PT)では、ホワイトボックステストを行います。
　単体試験項目書を作成し、カバレッジは、命令網羅（C0）または、
　分岐網羅（C1）で100パーセントを目指すことが多かったです。
　なので、実際にプログラム書く時間よりもPTの方が、時間が掛かかりました。
　結合テスト(IT)では、内部試験、外部試験と2段階にわけ試験を行います。
　内部試験は、自機能ごとのIFやデータのつながりを試験し、
　外部試験は、すでに稼働しているシステムや並行で開発している
　別システム等とのIF試験を行います。
　システムテストは、実際の業務を想定して、システムを動かす試験や、
　可用性を確認します。この工程は、業務知識が必要になります。
　最後の受け入れテストは、お客さんに実際にシステムを使用してもらう試験です。
　web系開発は、明確な設計書が存在しない為、上記のよう試験は行えません。
　仕様書から試験項目を起こします。また、試験期間が短く、
　全パターンの試験を行えない為、どの試験を行うかのか取捨選択が必要になります。
　この為、試験項目作成の難易度が高く思います。とにかく動かして試験し、
　とりあえず実際に利用出来るサービスを作り、
　ユーザーの反応を見て修正・改善するといった違いを感じました。
 
<br>

#### マネジメントのやりがいのシステム開発と<br>ユーザーに届くことが魅力のWeb系の違い
 
　やりがいの違いもあります。
　私が感じたシステム開発でのやりがいは、プロジェクトが完了するという事です。
　長期計画のシステム開発が、紆余曲折ありながら元々の計画通りにシステムが
　リリースされるとというのは、完成させたんだという達成感がありました。
　また、各開発工程ごとに区切りがあるおかげで、何をやるのかが明確になっており、
　自分の作業がわかりやすいというのがあります。
　技術的スキルよりも、作業管理や設計等のマネジメントの方を
　重要視している傾向を感じました。
　web系開発は、サービス終了まで終わりがなく、常に開発していく為、息をつく暇がありません。
　ただ、自分の仕事が、ユーザーからの反応で観れるという魅力があります。
　また、 技術的スキルの高さを重要視している傾向を感じました。


<br>

#### 最後に

　内容が技術的な話でなく、もうしわけございません。
　全体的に私が関わったことを話しているので、私見があると思われます。
　なので、これが考え方が全てをではないと、保険として書いておきます。
　同じエンジニアという仕事ではありますが、トップダウン方式で業務を細分化し、
　コツコツと構築して行く業務開発と、ユーザーの反応を観ながら開発するweb系で
　それぞれ全く別の文化を感じました。
　どちらも経験出来たのは、とても良かったと思います。

　以上
ホタルの光

10 CLS:?"ﾆｼﾉｹﾞﾝｼﾞﾎﾞﾀﾙ":LETI,0
20 OUT1,1:WAIT120
30 OUT1,0:WAIT120:I=I+1
40 IFI<3GOTO20
50 CLS:?"ﾋｶﾞｼﾉｹﾞﾝｼﾞﾎﾞﾀﾙ":I=0
60 OUT1,1:WAIT240
70 OUT1,0:WAIT240:I=I+1
80 IFI<3GOTO60
90 GOTO10
litaになりすましてコメントをする

# ざっくりいうと

litaになりしましてコメントをするhandlerを作成します。
slackを想定しています。

# 順番

## handlerのテンプレートを作成

puppetという名前でハンドラーを作成します。

```
# handlersというディレクトリを作成(やらなくてもいい)
$ mkdir handlers
$ cd handlers

# テンプレートを作成
$ lita handler puppet => lita-puppetというディレクトリとその配下にファイルが作成されます

# .gemspecを修正
$ vim lita-pappet/lita-pappet.gemspec
=> TODOになっているところなどを適当に変更してください。
```

## handlerの処理を書いていく

`puppet <部屋の名前> <メッセージ>`と打つと指定した部屋にメッセージがとぶイメージです。


 
```lita-puppet.rb
module Lita
  module Handlers
    class Puppet < Handler
      # ルーティングを作成
      route(
        /^puppet\s+(.{1,})\s+(.{1,})$/, # 一個目のカッコで部屋をキャプチャ、二つ目のカッコでメッセージをキャプチャ
        :puppet,                        # この対象に当てはまったものはpuppetメソッド(下)を呼ぶ
        help: { "puppet <room_name> <message>" => "messageをroomにパペットマペット" }
      )


      def puppet(response)
        # 部屋とメッセージを取得
        room_name = response.matches[0][0]
        message = response.matches[0][1]

        # 部屋とメッセージのオブジェクトを取得
        room = Lita::Room.find_by_name("#{room_name}")
        target_room = Lita::Source.new(room: room)

        # robotヘルパーに2つ引数を与えてメッセージ送信
        robot.send_message(target_room, message)
      end

      Lita.register_handler(self)
    end
  end
end
``` 

# 出来上がりイメージ

投稿
<img src="http://note.acairojuni.com/wp-content/uploads/2016/12/1.jpg" alt="1" width="359" height="61" class="alignnone size-full wp-image-1065" />
↓
自分に反映(ダイレクトメッセージでbotに話しかける)
<img src="http://note.acairojuni.com/wp-content/uploads/2016/12/2.jpg" alt="2" width="338" height="52" class="alignnone size-medium wp-image-1066" />
↓
実際にdevelopに反映される
<img src="http://note.acairojuni.com/wp-content/uploads/2016/12/3.jpg" alt="3" width="237" height="53" class="alignnone size-medium wp-image-1067" />
僕の作ったLINE bot

## 前書き

「個人開発者 Advent Calendar 2016」の記事です。
LINEのbot作りましたよ。
Goと公式SDKとHerokuです。
DBはPostgreSQLです。
駅名とかのAPIは使ってません。手作り！

## プロローグ

皆さんは山手線をよく使いますか？
使いますね？

「外回り」と「外回り」は覚えましたか？
覚えてませんよね？僕は覚えてません。もう覚える気ないですよ！:relaxed:

今いるところから最寄り駅を判断してくれて、しかも行きたい場所送れば分かる。

山手線どっち？

12/24より、ローカライズ部門対応のため、

「山手線どっち？」は台湾語・タイ語・マレー語に対応しました。

それぞれの選択肢で選択すればそれぞれの設定された旨の言語を返答してくれます。

![Image.jpg](https://qiita-image-store.s3.amazonaws.com/0/11951/f9d88eb9-3f93-4b54-4906-88c3d931c74b.jpeg)

![2Image.jpg](https://qiita-image-store.s3.amazonaws.com/0/11951/40bc1c29-54b5-8736-45b2-bcb5b9a8dc1e.jpeg)

今後その言語で使えるってことですね。

## 使い方

<img width="692" alt="Screen Shot 2016-12-06 at 12.19.45 AM.png" src="https://qiita-image-store.s3.amazonaws.com/0/11951/19cb0433-540e-cc7b-3fff-7f0358cb6cfe.png">


<div class='alert alert-warning'>じゃーん</div>

### QRコード

LINEを立ち上げてね。
iPhoneやAndroid持ってますね？
QRコードを読み取ろう。
「ともだち追加」から行いましょう。

![3.PNG](https://qiita-image-store.s3.amazonaws.com/0/11951/4a5f6285-09f7-998b-6ae7-976577a74ac9.png)


このURLにアクセスするのもあり

https://line.me/R/ti/p/F6pXKndFsh

### 使い方

1. まず左下の＋ボタンを押そう。

<img width="375" alt="IMG_3434.PNG" src="https://qiita-image-store.s3.amazonaws.com/0/11951/7c7115c6-7cb6-d975-a26d-5432ac66252d.png">

2. 次はロケーション※日本語版は「位置情報」かな？

<img width="375" alt="IMG_3435.PNG" src="https://qiita-image-store.s3.amazonaws.com/0/11951/7b630a47-5a92-7b80-02f8-91aecd8a5618.png">

3. 旗のマークの下を押す

<img width="375" alt="IMG_3436.PNG" src="https://qiita-image-store.s3.amazonaws.com/0/11951/87892301-655a-ffcd-2cb7-95369b022360.png">

4. すると最寄り駅を返してくれる


そのなかでランダムで行きたい駅の候補を返してくれる。

今回は「新宿駅」を選びました。
ちなみに、自分で「秋葉原」とか「秋葉原駅」とか送信してもOK。
※「駅」はつけてもつけなくてもOK


5. 結果

<img width="375" alt="IMG_3438.PNG" src="https://qiita-image-store.s3.amazonaws.com/0/11951/289f10b6-af1a-f145-2583-94cee6713aef.png">


おおお。すごすぎる！！！山手線どっち？
どの今から乗るホームの番号かも返してくれる。

降りるときのドア方向も。
※説明分かりにくいかもしれないので今後修正はいるかも？

６番乗り場って分かるし。しかも左側だって。

すごいね。
すごすぎる。

6. おまけ

「ヘルプ」とか送ればヘルプが来るよ。

<img width="375" alt="IMG_3439.PNG" src="https://qiita-image-store.s3.amazonaws.com/0/11951/727cfeca-0b8b-e341-768d-041c16fbfe41.png">

山手線どっち？　をよろしく。
スクラムマスタとマネージャの違い

スクラムマスタとマネージャー

まだスクラムをやったことがない人はスクラムマスタがマネージャのようなものかと思うこともあるかもしれません。
たまにスクラムマスタと名乗りながらマネージャの動きをしている誤解している人も居ました。

そこで、スクラムマスタとマネージャの違いに観点をおいて、書いてみようと思います。


## プロジェクトマネージャ

プロジェクトマネージャとは何をする人でしょうか？
タスクを振り分ける人。では、ありません。これはミッションでは無いです。
エンジニア上がりのマネージャでマネジメントの勉強をしない人は、これしか出来ない人がいますが、これはマネジメントの仕事の一部でしか無いです。
エンジニアとマネジメントの知識はまるで違います。
エンジニアが新しいプログラミング言語、フレームワーク、ライブラリを学ぶように
マネージャも新しい手法、チーム管理、人を動かす観点を学ばなければなりません。


では、プロジェクトマネージャのミッションは何でしょう？
計画を立て、それに従って進捗を進めることです。
究極的には計画を進めるためには基本的にメンバが壊れても構わないです。
ただ、知識を持つメンバが辞めたり、新しいメンバが参加した際の学習コストを考えると、通常、潰れるようなマネジメントをする人は長期的には厳しいチームになりやすいかもしれません。
ただ、基本的には長期戦略ではなくプロジェクトという短期の目標に対して最大限の力を注ぎ、責任を取る人間です。

スケジュールまでに完成させるスピードのために複数人で作業を進める必要があり、
そこで、タスクを割り振ることが出てきます。
ただ、タスクを割り振るだけが仕事ではなく、そのタスクが最大のスピードで消化されることこそがマネジメントの妙だと思います。

作業メンバのスキルや意識に合わせたタスクを割り振る。
作業メンバのスキルに合わせたタスクの落とし込みをしてからタスクを渡す。
メンバ同士のチェックペアを作り、ベテランと新人を組ませ品質を担保させる。
割り振ったタスクの意義を伝え、モチベーションを引き出す。


割り振ることが仕事ではなく、最速で品質高く仕上げることがミッションであれば
このようなことが仕事だと気がつくことが出来るでしょう。
もちろん、ここにあるのは一例であり、タスクの消化スピードを上げる方法は沢山あると思います。


## スクラムマスタ

実はプロジェクトマネージャの"本当"のミッションと"ほとんど"同じです。
そのチームで最大のスピードを出すことがミッションです。

ただ、そのアプローチと観点がちゃんと定義されてます。


スクラムが定義する用語にインペディメント(障害物)があります。
これを取り除いていく活動がメインのポイントに置かれています。

障害を見つけたらそれを解決に向かわせるように開発チームに促したり
チームが障害に対応しやすいように整理し、リスト化したり。
解決方法のアイデアを出したり、問題になっている技術的負債に対してチームが向き合うようなマインドを育てます。


最初に"ほとんど"と書いたのは、スクラムマスタはプロジェクトの終了がゴールではなく
より長期的にチームの力が最大化するような観点を持っています。

技術的な成長を促すような活動を出したり、そのリソースを確保するように動いたりすることです。
簡単に言うと勉強会を設定するように提案したり、業務で関わった高度な技術の情報シェアをメンバに促したりすることです。
情報シェアは勉強会だけでなくQiita:TeamやWikiなどのドキュメントにまとめるようなルールを定義したりします。


そうしてチームが成長し、ガッチリ肩を組んだスクラム体制になっていくなかで、相乗効果的に技術力が上がるようにして、強いチームを作っていきます。

スクラムマスタが普通のマネージャと違うのはスケジュール管理はメインミッションでは無いことです。
スケジュールに関しては責任は開発チーム自身に委ね、何を作るべきかはプロダクトオーナーの役割にしていることです。


それは何故かと言うと短期のスケジュールと中長期のチーム成長というものはたびたび相反する決定になるため、１人でその責任を果たそうとすると、より短期のスケジュールを優先するという判断になりがちだからです。

中長期的にチームの能力を向上させ、プロダクトの品質を上げるため技術的負債を解消することや開発する上での小さな障害の積み重ねになっていて中長期の開発スピードにボディーブローのように効いてくる事象を取り除くことが一番のミッションになります。


もちろん、全てスクラムマスタの言うとおりにするべきということではありません。
開発チームはスケジュールと合わせて、忘れがちな中長期的な視点についてアドバイスなどを受け、何度もその判断を促すことが重要です。


## 最後に

スクラムマスタがタスクを管理し、スケジュールを管理しだしたら、それは半分マネージャであります。


最初は専任でスクラムマスタを置くことが難しいため、マネージャと兼務することが多いですが、スクラムマスタはなにを重視する役割かを意識しながら行動してみてはどうでしょうか。


あとはマネージャの他にリーダーと言う立場もあります。
リーダーとは何をする人でしょうか？定義を考えてみて、その役割の行動が出来ているか考えてみて下さい。
もし、リーダーの定義が良くわからない方が居ましたら、コメント下さい(笑)
どこかに記事でまとめたいと思います。