OmniAICreator/Qiita-1.07M huggingface dataset:
せたがやの１年を振り返る

Code for Setagayaの2015年を振り返ると、地道な活動を続けていく中で、少しずつ実を結んできたことが実感できる年でした。

# TWDW SETAGAYA 2015

改めて振り返ると、Code for Setagaya の活動に広がりが出てきたきっかけは、今年3月に開催されたこのイベントだったと思います。

世田谷を舞台に、地域と関わり暮らしを見据えた働き方にフォーカスするイベントで、このイベントの中で Code for Tokyoの皆さまと一緒に、ワークショップを開催する機会を頂きました。

「住みたい街をつくる方法 ～ Code for の活動事例から ～」と題して、全国のCode forの事例をあいだで紹介しつつ、参加者が地域でどんな活動ができそうかを考えるプログラムです。

このTWDW SETAGAYAでは、7日間のあいだに色々なプログラムが開催されますが、その中で、世田谷を拠点に地域活動しているさまざまな方々と出会うことができました。この「つながり」がその後の活動に繋がる大きなきっかけになりました。

TWDW SETAGAYA後は、そこで出会った方々が取り組んでいる色々なイベントに参加しました。その中で地域に対する理解を深めることができて、よりいっそう地域への愛着が強くなりました。家族参加で楽しめるイベントも多く、学びも大きかったです。

![cfs_n.png](https://qiita-image-store.s3.amazonaws.com/0/104146/da2c1009-844d-cae8-3878-d152115f64bc.png)

図：TWDW SETAGAYA 2015で説明したCode for Setagayaの理念

# ウィキペディア街道「大山道」

昨年12/24に川崎市と世田谷区は「川崎市と世田谷区との連携・協力に関する包括協定」を締結しました。

「多摩川を挟んで川崎や神奈川などの近隣Code forと連携して何かできたら楽しいだろうなー」と思っていた時に、ウィキペディア街道プロジェクトのお声がけを頂きました。もちろん即答でぜひ（笑）。

世田谷区は歴史的に江戸と西側との中継地点だった経緯もあり、神社・寺院をはじめとする名所旧跡が多く存在しています。またそれにちなんだお祭り等も行われていて地域の文化として根付いています。

一方で地域では有名な神社・寺院などの十分な情報がネット上で見つからないケースも多く、転入者が多い地域であることも踏まえて、ネットに情報を載せて知る機会を作ることで、もっと「地域を楽しむ」きっかけが作れるのではないかと期待しています。

今年はこれまで4回開催していますが、色々な地域の文化にも触れる機会が持てたことは、さまざまな地域モデルの可能性を感じるよい経験になりました。

また地域に閉じて活動していると、活動の継続が辛い時期もあると思いますが、近隣Code forの仲間たちが頑張る姿を見れることがとても励みになります。

【これまでの開催記録】
- 2015年5月23日 第1回 高津・溝口（川崎市）
- 2015年8月9日 第2回 用賀・瀬田（世田谷区）
- 2015年10月4日 第3回 海老名（海老名市）
- 2015年11月3日 第4回 二子玉川（世田谷区、川崎市）

# せたがやの防災を考える

TWDW SETAGAYAで出会った方のご紹介で、「せたがや防災NPOアクション」の取り組みを知り、参加させて頂くことになりました。

世田谷区は人口総数88万人、世帯数46万世帯が住む地域で、これは政令指定都市レベルです。それをカバーする防災活動拠点は23拠点、避難所は94箇所もあります。

この広大な世田谷が被災した時に、地域のNPO等の活動団体が力をあわせて、地域の復旧に向けて連携しながらアクションしていこうという試みです。地域活動が盛んな世田谷らしい取り組みだと思います。この取り組みは区の危機管理室災害対策課も連携しながら動いています。

情報連携も重要なキーとなる活動ですので、Code for Setagaya もIT活用の面で色々と協力しながら、取り組みに貢献していけたらと考えています。

# まとめ

2015年は地域の「つながり」の大切さを知り、深く感謝せずにはいられない１年でした m(__)m

活動の派手さはありませんが、引き続き来年も地道に一歩ずつ、地域が好きなみんなで楽しみながら、取り組みを進めていきたいと思います。
Macbookでproxy環境と非proxy環境のネットワーク設定をスマートに切り替えるメモ

Macbookで複数箇所のネットワーク環境を利用していて、そのうちの一つ以上がproxyな環境の場合、ネットワークを切り替える都度、proxyのON/OFFの設定が必要になる。その手間を最小化するためのメモ。

## Macでのproxyの設定方法

そもそも、Macでのネットワークにおけるproxy設定は（多分）以下の2箇所あって、それぞれ設定が同期されないみたい。

* 非ターミナル系：システム>環境設定>ネットワーク
    * 適用範囲はSafafi、 Chromeなどのブラウザなど
* ターミナル系：ターミナルからの環境変数の設定(**http_proxy**他)
    * 適用範囲はターミナルなど

## 非ターミナル系

基本的にはネットワークを変更した時にproxy設定を切り替えられるようにする。

Macでは**ネットワーク環境(Location)**という設定があるので、proxy環境用の**Location**を定義しておいてこれを利用する。
例えば、**Office**という**Location**を定義(作成)して、**Location**:**Office**だけproxyを設定した状態にする。非proxy環境からproxyをつかうネットワークに接続する環境へ切り替えるときは**Location**:**Office**にすると同時にproxy設定が適用される。

**Location**の変更だけだとアクセスポイントまでは連動しないようなので、Locationとアクセスポイントはセットで切り替えるようにする。

## ターミナル系

基本的には新規ターミナルを起動した時と、ネットワークを変更した時にproxy設定を切り替えられるようにする。

ターミナル系におけるproxyの設定はコマンドによっても読む環境変数が異なるのでhttp_proxyだけ設定すればいいというわけでもないのでその点は気をつける。

プロキシを切り替えるためのスクリプトを用意する。スクリプトは[こちら](https://blog-kazuhisya.rhcloud.com/2014/07/20/auto-switch-to-match-network-to-proxy-settings/)を参考にした。***YOUR_****の部分は自分の環境に合わせて書き換える。

```bash:.switch_proxy
proxy=YOUR_PROXY_HOST:YOUR_PROXY_PORT
switch_trigger_location=YOUR_LOCATION
switch_trigger_network=YOUR_ACCESS_POINT

function set_proxy() {
  export http_proxy=$proxy
  export ftp_proxy=$proxy
  export all_proxy=$proxy
  export https_proxy=$proxy

  git config --global http.proxy $proxy
  git config --global https.proxy $proxy
  git config --global url."https://".insteadOf git://
}

function unset_proxy() {
  unset http_proxy
  unset ftp_proxy
  unset all_proxy
  unset https_proxy

  git config --global --unset http.proxy
  git config --global --unset https.proxy
  git config --global --unset url."https://".insteadOf
}

if [ "`networksetup -getcurrentlocation`" = "$switch_trigger_location" -a "`networksetup -getairportnetwork en0 | awk '{print $4}'`" = "$switch_trigger_network" ]; then
  echo "Switch to proxy for office network"
  set_proxy
else
  echo "Unset proxy settings"
  unset_proxy
fi
```

いつでも`nswitch`コマンド一発で呼び出せるように、以下を追記。

```:.bash_profile
# Proxy
alias nswitch="source ~/.switch_proxy"
```

ターミナルを起動した時に呼ばれるように以下も追記。

```:.bash_profile
nswitch
```

ネットワークを手動で変更した時はターミナルから、以下のコマンドを発行して、proxy設定を行う。

```bash
$ nswitch
```

これで環境にあったproxy設定になるはず。

## 参考
* [Mac の bash でプロキシ設定を自動切替する | blog-kazuhisya.rhcloud.com](https://blog-kazuhisya.rhcloud.com/2014/07/20/auto-switch-to-match-network-to-proxy-settings/)
* [Macのネットワーク環境に合わせてHTTP_PROXYを切り替えるシェルスクリプト - Qiita](http://qiita.com/uetchy/items/b9991d1f86b23f4a184d)
Scala 2.11 で Hello World


## 前提条件
* OS : MacOS X
* brewインストール済み

## 1. Scalaインストール

```bash
# brewのリポジトリ更新
$ brew update

# scalaインストール
$ brew install scala

# scalaのインストール確認
$ scala -version
Scala code runner version 2.11.7 -- Copyright 2002-2013, LAMP/EPFL
$ calac -version
Scala compiler version 2.11.7 -- Copyright 2002-2013, LAMP/EPFL
```


## 2. Hello World

適当なフォルダにScalaファイルを作成

```scala:Hello.scala
object Hello {
  def main(args: Array[String]) {
    println("Hello, Scala!")
  }
}
```

コンパイルして実行

```bash
# コンパイル
$ scalac Hello.scala

# 実行
$ scala Hello
Hello, Scala!
```

## まとめ

一先ず、Scalaで Hello Worldができました。
次は、Webフレームワークの[Play Framework](https://www.playframework.com/)の動作環境を作ります。

Next > [Scala で Play Frameworkプロジェクトを作成する](http://qiita.com/gungnir_odin/items/ab28eac673cebba67c0a)
無料で使えるAWSサービス一覧


無料枠があるとかではなく、そもそもお金がかからないサービスです。
これらのサービスを利用して作成されたリソースの料金はかかります。

* ECS
* AWS Elastic Beanstalk
* Auto Scaling
* VPC
* AWS CodeDeploy
* IAM(AWS Identity and Access Management)
* AWS CloudFormation

他にもあったら教えて下さい。
Unityで一度Prefab化したオブジェクトを元に戻す方法

## Prefab化してみたはいいけれど..

この組み合わせは将来大量生産するかも?!と安易な気持ちでAssetsにドラッグ&ドロップしてPrefab化してしまったオブジェクト、結局は1つしかインスタンス化しなかったので何か見た目が気持ち悪いなぁ、ということがあります。
そんな時に、Prefab化してしまったオブジェクトをPrefab化する前の状態に戻す方法を~~見つけたので~~紹介します。

## 手順

HierarchyからPrefabのインスタンスを選択した状態で、
メニュー → GameObject → Break Prefab Instance
<img width="223" alt="0" src="https://qiita-image-store.s3.amazonaws.com/0/39561/1f95f4d4-e8ad-4d0e-f987-29a61259663d.png">
(@tsubaki_t1さん、情報ありがとうございます!)

以上です。

------------------------------------

ここから下は、今となっては回りくどいだけの試行錯誤の足跡です。何かの時の参考まで。

CubeをPrefab化して、元に戻すまでの手順を説明します。

まずは最初の状態です。
<img width="978" alt="1" src="https://qiita-image-store.s3.amazonaws.com/0/39561/6893da47-1656-2ac1-5dc0-f7c7c7cd3116.png">

次にCubeを一つ置いてみます。
<img width="978" alt="2" src="https://qiita-image-store.s3.amazonaws.com/0/39561/02871897-c64d-c113-119b-6a51ccf44061.png">

このCubeをPrefab化します。
<img width="978" alt="3" src="https://qiita-image-store.s3.amazonaws.com/0/39561/8171ddf0-d705-3f1c-e23b-798eea1c4e41.png">

ここから、Prefab化したCubeを元の状態に戻していきます。

おもむろに空のGameObjectを作ります。最終的に消すのでCubeやSphereでも構いません。
<img width="978" alt="4" src="https://qiita-image-store.s3.amazonaws.com/0/39561/05fe7e50-4d83-7b68-ff5b-11612265b746.png">

CubeをGameObjectの子にします。
<img width="978" alt="5" src="https://qiita-image-store.s3.amazonaws.com/0/39561/7220b807-bfbc-d7a2-970f-fca498e7b617.png">

AssetsからCubeのPrefabを削除してしまいます。HierarchyのCubeの文字が赤(朱色)に変わります。
<img width="978" alt="6" src="https://qiita-image-store.s3.amazonaws.com/0/39561/ca044cfb-1200-82ef-7e03-dcd75cbaabec.png">

そしてGameObjectをPrefab化します。なぜか必要なのです。
<img width="978" alt="7" src="https://qiita-image-store.s3.amazonaws.com/0/39561/b3ee0a11-ed84-f444-3147-69747eb0aece.png">

何とここでAssetsからGameObjectのPrefabを削除してしまいます。訳がわからないですね。私も分かりません。
<img width="978" alt="8" src="https://qiita-image-store.s3.amazonaws.com/0/39561/8c2f2499-fec1-4979-35b9-bae9806fd234.png">

前の段階でPrefabが削除されたGameObjectを複製します。
<img width="978" alt="9" src="https://qiita-image-store.s3.amazonaws.com/0/39561/bf53c863-878f-56ea-c6b3-5c85676a768a.png">

複製されたGameObject、ここではGameObject (1)という名前、にもCubeがあります。
このCubeをInspectorで確認すると、、、普通に戻ってる!!!
<img width="978" alt="10" src="https://qiita-image-store.s3.amazonaws.com/0/39561/b3422b3b-b8e7-95db-fffd-4db310ba5af8.png">

あとは、GameObject (1)のCubeを階層の一番上にドラッグ&ドロップしてから、不要になったGameObjectやGameObject (1)を消せば、めでたくPrefab化する前のCubeに元通り。
<img width="978" alt="11" src="https://qiita-image-store.s3.amazonaws.com/0/39561/5049dc8e-d5b8-575d-8ada-72c489c9a32c.png">

## 補足

もともと階層化されている複数のGameObjectから成るPrefabであれば、途中のGameObjectを作って階層化してPrefabにして...の処理は省略して、Prefabを削除してから複製すれば複製されたものが通常のオブジェクトに戻ることを確認しています。
最上位に単独で存在するオブジェクトのPrefabの場合、一旦階層化してPrefab化しないと元のオブジェクトには戻せないようです。

もっとスマートなやり方をご存知の方、ぜひご一報ください。
AmazonLinux SSH パスワードログイン許可

# AmazonLinuxは初期状態ではSSHでパスワードログインできない
いくつもインスタンスを作成した経験からですが、インスタンス作成時に必ずSSHの設定がリセットされるようです。例えば、SSHでパスワードログインを許可していたインスタンスから作成したAMIがあります。そのAMIから作成したインスタンスにSSHでパスワードログインしようとしても、SSHの設定が初期化されているため、一度ec2−userアカウントと作成した鍵でログインする必要があります。

# 設定手順

-  SSH設定ファイルのバックアップ

```
# cp /etc/ssh/sshd_config  ~/sshd_config_yyyymmdd
```

-  差分がないことを確認

```
# diff /etc/ssh/sshd_config  ~/sshd_config_yyyymmdd
```

- SSH設定ファイルの編集

```
# vi /etc/ssh/sshd_config
```

変更前```PasswordAuthentication yes```
変更後```PasswordAuthentication no```

- 編集後の設定ファイルとバックアップの差分確認。
修正箇所のみに差分があること

```
# diff /etc/ssh/sshd_config  ~/sshd_config_yyyymmdd
75c75
< PasswordAuthentication yes
---
> PasswordAuthentication no
```

- SSH設定ファイルの構文テスト。エラーがないこと

```
# sshd -t
```

- SSHの再起動。

```
# /etc/init.d/sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
```
※失敗したらどうなるかは試したくても試せないです。

- 別ターミナルからログインできること。上記の設定中に開いたコンソールを閉じると二度とログインできなくなる可能性があるので、別ターミナルから実施します。

```
ssh ec2-user@xx.xx.xx.xx -i private.key
```

以上。
僕たちandroidエンジニアがkotlinを書かなければいけない理由



# 久々の投稿！
お久しぶりです。今年度始めにはよく勉強会向けの記事を投稿していましたが、最近はめっきり投稿していませんでした。主にアプリの開発を行っていてアウトプットをすっかりしていなかったのですが、このadvent calendarを機会に少しずつandroidエンジニアのためになる記事を投稿していけたら、と思います。

# kotlinを書かなければいけない理由
早速本題に入っていきます。

## まず考えられる「書かなければいけない理由」
別に書きなれているJavaで書けばいいんですよ。私もそう思ってました。
私なんかはJavaもまだ二年目で対してキャリアもないですがjavaであればキャリアを積んでいる人はたくさんいるでしょうし、android開発の言語的利点はjavaは情報がとても多い、というところもあるでしょう。

簡単に言えば、書かなければいけない理由は「GoogleとOracleのJava裁判」によってもしかしたらandroidが今後Javaを捨てるかもしれない、という考えから次に代わりになる言語は何だろう、といったところです。
ちょっと私には難しい内容なのでざっくりとしか読んでいませんが[OracleとGoogleの判決文を斜め読む](http://qiita.com/shibukawa/items/9c99321b8edb6fc09cce)が上の「googleとOracleのjava裁判」についてです。

## じゃあ僕たちが次に書くべき言語は何か
まさかのGoogle製のGoLang!?
実はあり得ない話ではなかったんです。
[Go support for Android](https://docs.google.com/document/d/1N3XyVkAP8nmWjASz8L_OjjnjVKxgeVBjIsTr5qIUcA4/mobilebasic?pli=1)
こちらにそのようなことが書かれています。
しかし、JavaのAPIにとGoLangの間での互換性がなさ過ぎて少なくとも、すぐには無理。おそらく不可能、といった具合。
そこで...kotlinに目が付いたわけです。

## なんだよ急に！？
実は急ではないんですkotlinさん。
2011年頃登場した言語で、オープンソース。同じくJVM言語であるScalaやGroovyを意識した作りに。
利点は簡単、

- Javaとの相互互換が完璧
- 純粋なjavaと大差ない実行速度（コンパイル速度）
- Javaより安全（nullがない）

Kotlinを作った会社はJetBrainsです。
どこかで見たことないですか？IntelliJシリーズの会社です。

AndroidStudioはIntellJをベースに使われています。
これがすごい意味があって拡大解釈すると、
Google が　JetBrains　を　認めている　！
ということになるのではないでしょうか！？


## 書いたほうがいい理由
上までに書かなければいけない理由を書いてきました。
書いたほうがいい理由も書いていきましょう。
（繰り返しになることもあるかもしれません）

- Javaとの親和性の高さ
- 正式版公開
- 言語仕様
- ぬるぽ無し

### 親和性については言わずもがな。

### 正式版については現在は1.0.0-Candidate -> Beta -> Beta2と１１月までに来ています。
新年度前までには正式版が出てくるでしょう。正式版が出るということはkotlinが言語としての完成度や安定度がある、と見れるでしょう。
そうでなかったとしてもJetBrainsはIntellJの完成度を見れば言語への理解が高いので安心できるでしょう。

### 言語仕様
Kotlinは簡潔、安全といったところがよくあげられます。
まずは簡潔。これは比較対象がJavaなのが一番大きいですが最近のモダンな言語にかなり近いです。（型推論や関数リテラル）
Javaで書くと冗長的になり気分的に辛いものKotlinでは解消できます。
そして安全面。
KotlinはJVMで動くコンパイラ言語なのでソースコードの誤りを実行前に気づけます。具体的に言うと、実行可能コードのみしか動かないので安全、というべきでしょうか。
そしてJavaと比較したときにKotlinは静的片付けを行ったり参照型の取り扱いが違います。簡素と安全性の両立が非常にできている、と言えるでしょう。

### ぬるぽの無し
Javaを書く以上どんなに気を付けていても避けては通れない...
Null SafetyがKotlinでは頑張ってます。


## Kotlinに完全移行すべきか
結論から言えば
#### まだ早い
かな、と思います。
良い言語の定義はそれぞれかと思いますが私は、

- ドキュメントの成熟
- 関連の質問が増える（Stack Over Flow 等）
- 日本語情報の成熟（これはまぁあったらいいなくらい）
- ライブラリの増加

という部分がまだまだかなと思います。

## 終わりに
Kotlinは導入も楽です。（そりゃIntellJなのでもちろんなんですが）
皆もちょっとずつ移行の香りを匂わすのはいいかもしれませんね。
100%Kotlinである必要もないですし、ハイブリッドでも。
ExtJSでタッチイベントをサポートするための内部的な仕組み

####冒頭

Sencha Advent Calendar2回目の投稿です、佐藤です。
もう12月も半ばにさしかかり今年も残すところわずかとなりましたね。
今年一年はとても早かったなと感じています。仕事もプライベートも忙しかったのであっとゆう間に過ぎ去りました。こんな感じでどんどん時間が過ぎ去っていくんだなと考えると何となく焦りを感じます。
やりたいことはあるけれどなかなか実現できていないのでそろそろ本腰を入れてやらないと思っているので来年は節目の一年になるのでなんとかしたいと思います。勝手な決意です。では、本題に入ります。

1回目はデスクトップとモバイルの統合を兼ねて今後使用する機会が増えるのではと感じたレスポンシブについて説明したので、2回目もデスクトップとモバイルの統合に関するExtJsの内部的な話をしたいと思います。

####Sencha Touch
Sencha Touchはモバイル用のjavascriptフレームワークとして使われてきました。Sencha Touchが良かったと思う所は無料で使えたという所だと思っています。Ext JSはライセンスが必要になるので個人的な開発ではなかなか手が出ないと思いますが、Sencha Touchは無料なので誰でも簡単に触れることができました。
今のExtJsではサポートしていますが、これまでのExtJsではタッチデバイスのサポートはしていなかったため、
モバイル・タブレットに対応するにはSencha Touchを使うことになっていました。
現在ではExtJs6がリリースされ正式にSencha Touchは無くなりましたが、ではどのようにExt Jsでタッチデバイスのイベントを可能にしているのかという所を軽く説明します。

####イベントの正規化
このイベントの正規化はExtJSで開発したアプリケーションをタブレット上で実行するために行われています。
Ext Jsでmousedownなどのマウスイベントをそれに相当するタッチイベントに変換し、タブレット上でのジェスチャーを可能にします。これによりタッチイベントの実現が可能になるという仕組みです。
一部ですがイベント変換例を表にした資料がありますので[こちら](https://docs.sencha.com/extjs/6.0/core_concepts/tablet_support.html)をご覧ください。
上記表には一部変換例が記載されていますがもちろんこれ以外のtap、swip、pinch、dragなどのイベントも使用できます。

####代替えできないイベント
中には代替えできないイベントもあります。
mouseover/mouseout/mousenter/mouseleaveこれらのイベントは代替えできないため、このイベントをハンドラし処理を実行する必要のあるアプリケーションは、独自の対応が必要になります。

####まとめ
ざっくりでしたが以上でSencha TouchとExtJSの統合による内部的な仕組みについての説明を終わります。
Sencha TouchとExtJSの統合は開発者もそうですがエンドユーザー様にとってもメリットのある事だと思います。今までですとPCとタブレットで開発する場合はExtJS、Sencha Touchをそれぞれ使っていたため、単純に開発コストが2倍かかっていたという計算になります。(厳密には2倍はないと思います)しかし、統合された事により開発者にとってはコードのメンテナンスが容易になりますし、開発費用も抑える事ができるようになりました。
今回説明したことはExtJS6のdocsに記載されていますのでそちらも見ていただけるとより理解して頂けるかと思います。

以上、佐藤でした。
KiCad の小ネタ

8日目の [nosu_Z さん](http://tech.nosuz.jp/2015/12/kicad-bom/) に続く、[KiCad Advent Calendar 2015](http://qiita.com/advent-calendar/2015/kicad) の9日目です♪　
#はじめに
まず最初にお断りしておきます。
バリバリにKiCadを使ってる方には面白みのないネタで申し訳ありません。:disappointed_relieved: 
軽くスルーしていただけますよう、よろしくお願いします。。
お時間のある方、暇つぶしがてら眺めて頂ければ幸いです。
コンポーネントと回路図の作成に関する小ネタです。
#本文
先ずは、コンポーネント作成の小ネタを２つほど。
KiCadのライブラリに登録されているコンポーネントを見て、おやっ？っと思ったことはないでしょうか？
１つ目はピン番号のつけ方です。
下図はコンポーネントライブラリにあるダイオードのピン名とピン番号を表示させたものです。
![Diode_Original.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/4e0933a6-7bdc-44c4-e3cc-39cfc3f99627.jpeg)
ダイオードの方向とピン番号が統一されていません。
"IPC-7351 Surface Mount Land Pattern Zero Orientation"では、カソード(K)のピン番号は１番と定義されています。
新しく作られたものはこれに準拠してカソードを１番にしたようですが、古くに作られたものが逆になっています。
これでは分かりずらいので、個人で使うローカル・ライブラリではカソードを１番に統一しています。

次にトランジスタですが、こちらは下図のように名前のサフィックスがピン番号順になっています。
![TR_Original.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/67e6e25f-76d6-4542-74bc-8c59b8d34f5e.jpeg)
パッケージのピン並びに合わせてシンボルを使い分けるようになっています。
便利なようなんですが、私は逆に名前とピン番号が違うほうが分かりずらいのでBCEの１種類しか使わないようにしています。（フットプリントのほうを合わせています）

これ以外の部品についてのピン番号のつけ方ですが、基本的にはフットプリントのピン番号に合わせています。
上→下（Y軸）、左→右（X軸）の順で左上が１番です。
（但し、ICのピン番号は下図のように１番から反時計回りで番号を振られます。）
![QFP_Original.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/eb05ee28-7205-6703-be8a-d7e78c39724d.jpeg)

２つ目はICのシンボルです。
下図はコンポーネント・ライブラリにあるICの例です。
![IC_Original.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/c8cceb38-c0ca-5fea-a57d-f2104ff0432b.jpeg)
論理記号や信号毎のピン並びなので、ロジックを追うには便利ですね。
しかし、これでは部品のイメージが掴みにくく、例えば、インバータICが何個使われているか直感的に分からないです。
オペアンプにしても、１／２／４個入りと種類があるので、パッケージが何個使われているか分かりにくいです。
そこで、個人で使うローカルライブラリでは下図のようにパッケージが分かるようにシンボルを作っています。
![IC_Edited.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/146ae9d8-6ed1-27d2-2057-f3dd69a3acfe.jpeg)
これなら電源ラインも分かりやすく、実装を意識した回路図にも適しています。

続いて、回路図作成の小ネタです。下図をご覧ください。
![Circuit_Exsample.jpg](https://qiita-image-store.s3.amazonaws.com/0/103199/60da1de6-75c9-014e-7db3-b650dcb5d2d5.jpeg)
入力のGND側がそのまま伸びているのがお分かりでしょうか？
あっ石を投げないで下さ～い:confounded: 
GNDシンボルを使えばいいのに何て冗長な！とのご批判、ごもっともです。
ハードウェアの記述にはHDLを使うことが増えており、冗長さをなくして簡潔に記述できるため大規模な論理回路には大変便利です。
しかし図面には、同じ回路の表現でも容易に違う記述ができる冗長さを逆手にとって他の情報を持たせられるメリットがあります。
実はこれ、実装を意識した回路図で、GNDラインをパターンで分離する意味が込められています。
ステレオ信号のクロストーク、モーター等の大電流ラインのリターン、デジタル回路のノイズ等を考慮すると、回路設計の段階でGNDラインを分離したい部分がしばしば出てきます。
このように回路図へ反映させておくと、パターン設計者が別でも意図を伝えることができます。
また後で電源、GNDを見直す時にも便利です。（電源ラインの考え方も同様です）
#おわりに
デジタル回路全盛になり、接続さえ正しければ動作することが多くなりました。
またアナログ的要素もデジタル回路の高速化に伴い、高周波回路のノウハウの方が重視されています。
もはやあまり顧みられることのない低周波のアナログ回路ですが、パターンや実装のちょっとした変更でトラブル回避できることもあります。
実装を意識した回路図は、このような場合に役立つのでお勧めです。
（学生の方、学校では使わないで下さいね。直すよう指導されたり、減点されても責任は負いかねます。）

10日目は [やま しょう さん](http://qiita.com/qa65000) です♪
"格安pcb 発注　個人的な感想"、これは見逃せないですよ！
red5を忘れていないか。

東北では、この季節になると、テレビ会議の需要があります。
先月から、うちのsuseでred5を稼動しました。

red5は、rtmpのストリーミングサーバーです。
クライアントがswfです。

安請け合いして、テレビ会議を受注しましたが、どうにも、
音声が途切れます。

9人の仕様で、画像と音声を全てに配信しては無理です。
wifi環境では、さらに無理です。

結局、画像は無しで、「ラジオ会議」になりました。
Staringスマホアプリ開発テクニック その 1

#はじめに
こんにちは、harayokiです。今回は、自分がStarlingを使ってアプリを開発している時に、個人的に編み出したテクニックをお届けします。一般的には、Objectをプーリングしろだとか、Drawコールをまとめろとか、そういう話になるのですが、そのようなプログラマ観点ではなく、FlasherもといAnimetor(?)ならではの内容をお伝えします。

![title-logo.png](https://qiita-image-store.s3.amazonaws.com/0/8302/e5ec0dbf-fb12-2fde-46d2-3c36f3b9e234.png)

#UI作成には、タイムラインを積極的に使おう！
通常はStarlingでUIを作る、と言ったらFeathers( http://feathersui.com )の出番になりますね。はい、選択肢が沢山あるリストをヌルヌル動かしたいのならそれで正解です。派手なUIをAS3バリバリで動かしますか？それもStarlingまたはFeathersベースで正解かと思います。

しかし、作ろうとしているUIはそんなに動的で派手なものばかりでしょうか。タイトル画面、ヘッダ・フッタ、プロフィール入力画面、ポーズ仮面、ゲームオーバー画面、お知らせバナー、アイテム選択画面などなど。。意外と静的な画面に落ちついていたり、FeathersなどUIライブラリを用いても、複雑なことを行うには工数がかかるために、結局地味なUIに落ち着いていたりしないでしょうか。アニメーションもないか、あってもスライドしてIN/OUTする程度になっていないでしょうか。あるあるですよね？

ここで、このようなUIを昔ながらのタイムラインを使って製作することを考えてみましょう。

実は、スマホ上では遅くて使い物にならないといわれているタイムラインを使ったMovieClip/Spriteの描画ですが、**動かさなければFPSはほとんど落ちません。** あまりに古いスマホでなければ、**60FPSキープできます。**また、最近のスマホは処理能力が格段に上がっていますので多少動かしても気になる速度低下もありません。

DisplayObjectの入れ子が激しかったりすれば遅くなるのでしょうが、それはStarling側でも同じことです。もちろん、残りタイム表示など、更新が毎フレームあるテキストなどを担当するとFPSは下がってしまいますので、そこは、UIに**穴**を開けて背面に存在するGPU側(Starling)に描画処理を対応してもらえばいいのです。ゲーム本体は Starling(やAway3DなどGPUベースの描画エンジン)に頑張ってもらい、ヘッダやフッタ、その中のあまり操作しないUIはタイムライン側で描画してしまえばいいのです。

今やっている大ヒットゲームのUIもヘッダ・フッタやサイドバーは普段は止まっていたりしませんか？GPUベースのUIでも画像やテキストを差し込みまくっていると、結局動作がかなり重くなったりしていませんか？

画面全体に大きな範囲で存在する、美麗で繊細な図柄の動かない装飾などはまさに、タイムライン側の描画の出番です。テキストや画像が多量に差し込まれても問題ありません。ドローコール数が増加しないので、むしろその**アプリケーションがより速く動く**とも言えます。

#タイムライン＋ベジェでUIを作成した時のポイント
以下、GPUのビットマップベースで構築したUIと比較して、といった観点での考察です。

* 2x、3xなど解像度のちがう素材をいくつも用意しなくて良い
* 一般的にファイル容量がかなり小さくなる(デザインによっては逆効果)
* ピクセルパーフェクトになるのでにじみのない見た目になる
* SEの入れ込み対応がやりやすい
* 画面遷移を追いやすい、直感的に画面がつくれる
* 美しいグラデーション表示ができる、イラレからそのままデータが持ってこれる
* フィルターを使いテキストに派手な装飾をつけられる
* 別途UIビルダー的なソフトを使う必要がない(StarlingBuilder、MXML for Feathersなど)
* 大きな描画範囲でこみ入ったアニメーションさせると動作が重い
* スコア・タイムの表示など描画更新頻度が多いものには向かない
* アクションゲームの操作ボタンなどレスポンスが重要なUI表示には向かない
* 項目が多いリスト表示には向かない

#パフォーマンスを上げる細かいテクニック
以下は、タイムラインを扱ったFlashとしては枯れたテクニックですが、併記しておきます。このあたりはいくらでもネットに情報が落ちていると思うので、詳細は解説しません。

* Stage.qualityはMIDDLEで充分：スマホは解像度が高いので、HIGHやBEST設定にしても遅くなるだけでそこまで綺麗に見えません
* Cache as Bitmapを使おう：メモリは食いますが、ベジェ曲線の描画計算が行われなくなるので、MovieClipを動かす場合に速くなります
* アニメーションは平行移動やアルファ値の変更程度にとどめる：回転・フィルタなどのアニメーション処理はBitmapCache処理の計算し直しになるので遅くなります
* Bitmap素材を用いると速い(上にあげたベジェの利点はなくなりますが、部分的に用いるとよい)

#終わりに
StarlingにもMovieClipが存在するため、解説が多少くどい書き方になりました。上記だけ読むとFeathersを若干ディスっているようにも見ますが、Feathersはとてもいいものです。筆者も頻繁に利用しています。つまりは、適材適所ということです。Feathersの弱点は直感的に画面構成を作れないことですが、最近はFlexのMXMLを用いてUI画面作成ができるようになったようです。自分は追っていないのですが、これについて誰か詳しい人が記事にしてくれないかなあ。。

コンテンツ製作者としてはどうしてもアプリを60FPSで動かすことにこだわってしまいますが（そして上記で書いた内容も60fpsでアプリを動かすこと前提としていますが)、30FPSでも良いと妥協すると、タイムラインUIもそこそこ動かしつつGPU側の描画ともぴったり同期ができて、一番バランスが良いのかもしれないなあ、と思ったりもしています。

以上です。まだまだネタはまだあるんですが、その２はカレンダーに空きがあれば書きます(笑)。
ではまた。
fluent-plugin-influxdb を利用する際の注意点

## はじめに
ストリーム処理の需要の高まりから、最近注目されている時系列 DB [InfluxDB](https://influxdb.com) ですが、Fluentd 経由で InfluxDB へデータを転送する際、落とし穴があったので紹介します。

(追記 2016-06-07) この問題は、 https://github.com/influxdata/influxdb-ruby/pull/121#issuecomment-208588626 にて解決しました。

## fluent-plugin-influxdb にある落とし穴
Fluentd を通して InfluxDB へデータを転送する際に、利用可能なプラグインに [fluent-plugin-influxdb](https://github.com/fangli/fluent-plugin-influxdb) があります。このプラグインの実装は InfluxDB の Ruby クライアント [influxdb-ruby](https://github.com/influxdb/influxdb-ruby) のインスタンスを生成し、インスタンスの `write_points` メソッドを使用して InfluxDB にデータを転送するという非常にシンプルなものです。

しかし、[fluent-plugin-influxdb](https://github.com/fangli/fluent-plugin-influxdb) には、[influxdb-ruby](https://github.com/influxdb/influxdb-ruby) のインスタンスがエラーで落ちると、それ以降 InfluxDB にデータ転送できなくなるという落とし穴があります。データが転送できなくなっても Fluentd のプロセスは動き続けるので、その点も注意が必要です。プロセスが動き続けているから問題ないと思っていると、いつの間にかデータが可視化できなくなっていたり、バッファファイルが肥大化したりしてしまっています。

```fluent-plugin-influxdbが出すエラーの例、この後、プロセスはデータ転送ができなくなる
2015-10-21 17:21:33 +0900 [warn]: temporarily failed to flush the buffer. next_retry=2015-10-21 17:23:43 +0900 error_class="InfluxDB::Error" error="unable to parse 'test,status= count=2 1445414291': missing tag value\n" plugin_id="object:1ebf6a8"
```

[influxdb-ruby](https://github.com/influxdb/influxdb-ruby) のインスタンスは Fluentd プロセスを再起動すれば復活するのですが、未だ問題があります。現在、[influxdb-ruby にはデータのエスケープに幾つかの不具合があり](https://github.com/influxdb/influxdb-ruby/pull/121)、エスケープが必要なデータを転送してしまうと問題が再発してしまうのです。このため、たとえ Fluentd プロセスを再起動しても、Fluentd のバッファファイルにエスケープすべき、もしくは空値のデータが含まれていると問題が解消しません。


## 対策
現在、私を含め [influxdb-ruby](https://github.com/influxdb/influxdb-ruby) を修正した PR ([TrickyMonkey の PR](https://github.com/influxdb/influxdb-ruby/pull/119), [yhara さんの PR](https://github.com/influxdb/influxdb-ruby/pull/121)) が投げられているので、その元のブランチのコードを使うと一先ず解決できます。自分で言うのもなんですが、yhara さんのブランチがいいと思います。[influxdb-ruby](https://github.com/influxdb/influxdb-ruby) は、元の実装上、[InfluxDB の仕様に則ったエスケープ](https://influxdb.com/docs/v0.9/write_protocols/write_syntax.html)をすることが難しく、私の PR は「仕様とは違っているが、問題を解決できる最小限の変更」になっており、yhara さんの PR は「仕様に準拠しているが、やや大きな変更」になっています。私の利用範囲では、私の PR で問題無いですが、安全なのは仕様に準拠している方ではないかと思っています。

このため上記の PR がマージされれば、多くの問題は解決すると思っています。ただ、yhara さんの大きめのパッチが直ぐにマージされるかが分からないので、今回あえて記事にしました。

## まとめ
この記事を見ると、Fluentd と InfluxDB の相性は悪いのではないかと誤解させてしまうかもしれませんが、Fluentd と InfluxDB の組み合わせは非常に強力です。両ミドルウェアともに、非常に簡単にデプロイでき、スケールアウトさせることもできます。ストリーム処理をスモールスタートからはじめるには、これらのミドルウェアは悪くない印象を持っています。

この記事は、あくまで、現在そして近い未来に、Fluentd と InfluxDB の利用を検討されている方の躓きを未然にふせぐためのものです。この記事で、ストリーム処理を楽しく気軽に運用できる人が増えればいいなと思っています。（この記事を書いたのに、次の日には問題が解決していたというオチを期待しつつ…）
HPACK の never indexed はいつ使う?

> "I thought Falkor appeared in Never ending Story was a dog".

HPACK は HTTP/2 のヘッダーフィールドエンコーディングアルゴリズムです.  だいたい 30% 程度の大きさになります.  この圧縮率を実現するためいろいろなことをやっているのですが, 基本的なところは一度送ったヘッダーフィールドは大きさ制限の着いた FIFO キューに入れておいて (このキューは送信側, 受信側で同期して共有する), 次に送信する場合はキューの中のインデックスだけ送信すればよい, という部分になります.  このキューにいれることをインデックス化 (Indexed, Indexing) と RFC 7541 では述べています.  エンコーダーは必ずもインデックス化しなければならないわけではなく, インデックスする / しないという選択をヘッダーフィールド単位で制御できます.  インデックス化しない場合は, Literal Header Field without Indexing (以降, Without Indexing) というエンコードを使います.

さて, [RFC 7541, Section 6.2.3](https://tools.ietf.org/html/rfc7541#section-6.2.3) に Literal Header Field Never Indexed (以降, Never Indexed) というのがあります.  これは Without Indexing と同じでインデックス化しない, というエンコードです.  2 つを比べてみると 4 ビット目が違うだけで後は同じです.  Never Indexed はどのようなときに使うのでしょうか.

Never Indexed はセキュリティ対策として導入されたエンコード方法です.  当初 HPACK ドラフトにはありませんでしたが, セキュリティレビューの時に [CRIME](https://ja.wikipedia.org/wiki/Transport_Layer_Security#CRIME.E6.94.BB.E6.92.83) 攻撃のように一文字ずつの解読というのはできないが, 辞書による完全一致攻撃に対して脆弱性があるという指摘が上げられました.  短い cookie や authorization ヘッダーフィールドはインデックス化していると, 完全一致の場合インデックスを使うので出力が短くなる = 推測が当たっている, と攻撃者に情報を与えてしまうというものです.  そういう重要なヘッダーには Without Indexing を使えばいい, という単純な話にはなりませんでした.  というのはプロキシーがフォワードするときにインデックス化してしまう可能性があります.  そこで全てのフォーワードされるパスにおいてインデックス化してはいけない, ということを要求するために追加されたのが Never Indexed なのです.

実際に Never Indexed は使われているのでしょうか.  実は Firefox ではかなり前から実装されています.  Firefox は authorization ヘッダーフィールドや, 短い cookie ヘッダーフィールドは Never Indexed を適用するようになっています.  [nghttp2](https://nghttp2.org/) でも同様の手法を取りいれています.
間違えやすいGA分析その２：コンバージョン率の計算

# テーマ:コンバージョン率

コンバージョン率に関して、間違えやすい点について解説しようと思います。
ちなみにコンバージョンは設定してればコンバージョン -> 目標から見ることができます。 

# 問題

次の前提を踏まえ、ある動画サイトのコンバージョン率を求めましょう。

## 前提
コンバージョンは
1. 目標設定
テンプレート：メディア再生
2. 目標の説明
タイプ：イベント
で設定したとします。
つまり、動画の再生が目標として設定する行動です。

またもう一つの前提として、3人とも30分以内にすべての行動を終了したとします。

## 状況
Aさん＝再生→再生→再生→離脱
Bさん＝再生→離脱
Cさん＝離脱

# 答え

コンバージョン率＝66%

# 解説

言葉の定義を確認します。

## コンバージョン率

目標として設定した行動の完了を指し、そのカウントは訪問(セッション)が基軸。
つまり、1度の訪問(セッション)で複数回目標を達成したとしてもカウントされるコンバージョン数は1になります。

## 問題を振り返る

Aさんは動画を再生しているのでコンバージョンを達成しています。複数回動画を見てはいますが、訪問数は1なのでコンバージョン数は1になります。
Bさんも動画を再生しているのでコンバージョンを達成しています。
Cさんはページに来ただけで離脱してしまったので未達成になります。

以上のことからコンバージョン率は2 / 3 × 100 = 66%になります。

# ちなみに

前提のところで「30分以内にすべての行動を終了したと」する、と書いたのは、セッションがタイムアウトになる時間はデフォルトでは30分に設定されているからです。

# 最後に

間違えやすいGA分析その１は[こちら](http://qiita.com/akatsuki174/items/615a3467cfa9f2b55fdb)になります。
【FileMaker】別言語から来た時に陥りやすい処理 - Loopでフィールドを変更？いやいやいや！


FileMaker Advent Calendar 2015、９日目です。

今日は、別言語から来たときに「えええ！？」となる話です。
別言語では、選択した件数分同じフィールドを変更するときはLoop処理を実装しますね。

FileMakerでは、

**フィールド内容の全置換**

が使えますね。

これを知るまでは、FileMakerでいちいちLoop処理の中でフィールドの内容を設定していました。
知ってしまうとなんて便利。

例えば、検索条件に従って抽出されたデータのフィールドを一括で変更します。
![スクリーンショット 2015-12-05 20.23.44.png](https://qiita-image-store.s3.amazonaws.com/0/60538/f7188393-05af-ee72-9a4b-30c7fc81c46d.png)
はい、どこにもLoop処理はありませんね。

もちろん、FileMakerでもLoop処理はありますが、単純に一括でフィールドを変更するだけの場合はLoopせずにこの「フィールド内容の全置換」が使えます。

今回のスクリプトを実行する前の状態↓。
![スクリーンショット 2015-12-05 20.19.59.png](https://qiita-image-store.s3.amazonaws.com/0/60538/4dd8ecae-80a6-848a-9965-d6f76e098eff.png)

スクリプトで、本日よりも以前に作成されたデータ、かつ、削除フラグがたっていないデータのnameフィールドを一括で変更します。

はい！
![スクリーンショット 2015-12-05 20.24.11.png](https://qiita-image-store.s3.amazonaws.com/0/60538/174e3b2d-ffd2-2281-a711-754811b24dfd.png)
一括で変更されています。

全置換を実行した際、修正日付を自動で設定している場合はもちろん修正日付（全置換した日付）が入るので修正したという情報も残せます。

「Loopするのめんどうだな」と思ったら全置換を使うことを考えてみてくださいね。
MVVMやFRPに取り組みやすくするために

## 概要
+ MVVMやFRPを練習しやすいように、有名ドコロのライブラリを持ってきてサンプルを作る。

## 参考リンク
+ [MVVMをベースに複雑な振る舞いをしっかり把握できるアプリ開発](http://qiita.com/susieyy/items/2af5321b287b8d2f49f6)
+ [GUIアーキテクチャパターンの基礎からMVVMパターンへ](https://www.slideboom.com/presentations/591514/GUI%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3)
+ [MVVMのModelにまつわる誤解 - the sea of fertility](http://ugaya40.hateblo.jp/entry/model-mistake)

## 今までのiOSの設計の流れをざっくり

***
### MVC ( ~ 2012)
![MVC.png](https://qiita-image-store.s3.amazonaws.com/0/101267/c1e9acf7-2af7-5476-fb4d-84cfb98a64d4.png)
***
### MVP ( ~ 2014)
![MVP.png](https://qiita-image-store.s3.amazonaws.com/0/101267/d69e5b1f-290b-f9be-456b-47d4d8832bb9.png)
***
### MVVM ( ~ 2015 ~ )
![MVVM.png](https://qiita-image-store.s3.amazonaws.com/0/101267/685a96e8-3ff1-cb20-705d-09f43762214d.png)
***

### ライブラリ

下記の◎○△xは、個人的な使い勝手です。

||MVVM用|FRP or タスク分割用|総サイズ|
|-----|-----|-----|-----|
|RxSwift|◎|◎|33MB|
|ReactiveCocoa|△|○|26.8MB|
|ReactKit|△|○|7.8MB|
|ReactiveKit||||
|SwiftBond|◎|x|7.4MB|
|SwiftTask|x|◎|2.6MB|

#### 　ライブラリのインターフェースの扱いやすさ(個人的な感想です。)

|RxSwift<br />・扱いやすい/直感的<br />・XCode等のコード補完が効きやすい<br />|||||ReactiveCocoa3.0(昔のもの)<br />・扱いにくい/理解に時間がかかる<br />・XCode等のコード補完が効きにくい<br />|
|-----|-----|-----|-----|-----|-----|
|RxSwift|SwiftBond <br />SwiftTask||ReactiveCocoa4.0|ReactKit|ReactiveCocoa3.0|

* ReactiveCocoaは、だんだんRxSwiftにインターフェースを寄せてきている印象
* ReactiveKit(≠ReactKit)は、RxSwiftに便利なExtension(例えばCollectionまわり)を足したような印象(調査不足..)


### サイズ詳細

|ライブラリ|framework1|framework2|framework3|
|-----|-----|-----|-----|
|RxSwift|RxSwift.framework(22M)|RxCocoa.framework(9.6M)|RxBlocking.framework(648K)|
|ReactiveCocoa|ReactiveCocoa.framework(26M)|Result.framework(872K)||
|ReactKit|ReactKit(5.4M)|SwiftTask.framework(2.8M)||
|SwiftBond|Bond.framework(7.1M)|||
|SwiftTask|SwiftTask.framework(2.8M)|||

※実際にarchiveするとReactiveCocoaで10MB程度だった

### 個人的な使い勝手について

#### 　前提
* 方向性
  * 最終的には、MVVM + FRP をアプリに組み込むことを目指している。
  * MVVM + FRP 移行については、段階的に移行する。
* 移行順序
  1. 値変化の監視機能(KVO)を使ってMVVMを実現する。-> MVVM
  2. 値変化の監視機能を拡張(FRP)して監視能力に幅を持たせる。-> MVVM + FRP

#### 　前提を実現するために

1. MVVM導入パート
  * KVOの単純なWrapperとして扱うことができ、MVVMを実現出来るライブラリ。
  * FRP用として扱うライブラリと互換性がある。
  * 学習コストが低い。
     * -> SwiftBond
1. MVVM導入パート
  * MVVM+FRPを実現できること。(FRPについては、ReactiveXでも可とする)
    * -> SwiftBondからRxSwiftへ移行する。

#### 　ライブラリ選定の理由

* 初期は、MVVMだけの導入でいいのでチームの学習コストを抑えたい。
* SwiftBondとRxSwiftのインターフェースが似ている。
* (時間がある or チームのキャッチアップ力が高い 場合は、いきなりRxSwiftを利用する。)

## 本題

+ [Sample Project-0.0.1](https://github.com/ysmdsty/LikeMvvmTemplate)
embulk-parser-none および embulk-filter-stdout プラグインのご紹介

[Embulk Advent Calendar 2015](http://qiita.com/advent-calendar/2015/embulk)の9日目の記事です。

こんにちは @sonots です。３連投すみません。昨日に引き続き、淡々と拙作のプラグインの紹介をしようと思います。

本日紹介するのは embulk-parser-none および embulk-filter-stdout プラグインです。

## embulk-parser-none

URL: https://github.com/sonots/embulk-parser-none

何も parse せず、payload カラム(デフォルト)として保存するだけの便利プラグインです。Fluentd の none parser からパクっています。

file input プラグインと、自分の後ろの席の civitaspo が作っている [embulk-output-hdfs](https://github.com/civitaspo/embulk-output-hdfs) を使って、ローカルファイルをそのまま HDFS にアップロードしたくて作成しました。

使い方は、以下のように書いて、

```
in:
  type: file
  path_prefix: example.txt
  parser:
    type: none
    column_name: payload
```

例えば、example.txt の内容が以下のようになっている場合、

```
foo bar baz
foo bar baz
```

このように取り込まれます。

```
+----------------+
| payload:string |
+----------------+
| foo bar baz    |
| foo bar baz    |
+----------------+
```

書き出す場合、csv formatter を使ってもらって、以下のように指定すれば

```
out:
  type: file
  path_prefix: example.txt
  sequence_format: ""
  file_ext: .out
  formatter:
    type: csv
    delimiter: 0
    quote_policy: NONE
    header_line: false
```

元の内容のまま吐き出されます。やった！ただの cp ができた！

```
foo bar baz
foo bar baz
```

## embulk-filter-stdout

URL: https://github.com/sonots/embulk-filter-stdout

embulk の records を標準出力に吐き出すだけのデバグ用のプラグインです。アイデアは Fluentd の stdout filter からパクっています

```
in:
  type: file
  path_prefix: example.csv
  parser:
    type: csv
    charset: UTF-8
    newline: CRLF
    null_string: 'NULL'
    skip_header_lines: 1
    comment_line_marker: '#'
    columns:
      - {name: time,  type: timestamp, format: "%Y-%m-%d"}
      - {name: id, type: long}
      - {name: name, type: string}
      - {name: score, type: double}
filters:
  - type: stdout
out:
  type: file
  path_prefix: example.txt
  sequence_format: ""
  file_ext: .out
  formatter:
    type: csv
    quote_policy: NONE
```

他の filter プラグインの結果を確認するために、途中に差し込んだりして利用できます。大分捗ります。

## おわりに

一通り、拙作プラグインの紹介をさせて頂きました。embulk の plugin を作りっぱなしで、ブログなどには一切書いてなかったので、Advent Calendar が良い機会になりました。良かった。

まだ Advent Calendar 空いているので、自作プラグインの紹介とかもっと皆さん書いたら良いと思います！
logstashでapacheのアクセスログをelasticsearchに送信し、kibanaでグラフ表示

この記事は Elasticsearch Advent Calendar 2015 9日目です。
elasticsearchを初めて使ってみました。

## 参考

* [Logstash Configuration Examples](https://www.elastic.co/guide/en/logstash/current/config-examples.html)
* [logstash input plugin](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html)
* [logstash output plugin](https://www.elastic.co/guide/en/logstash/current/output-plugins.html)

## 概念

|種類|説明|
|:----------|:----------|
| logstash | 今回は/var/log/apache2/access.logを監視。追記があればelasticsearchに送信 |
| elasticsearch | ログデータを蓄積 |
| kibana | elasticsearchのログデータを解析しグラフ化 |


## elasticsearchとkibanaを起動

```bash:elasticsearchを起動(port9200,9300)
docker run -d --name elasticsearch \
  -p 9200:9200 \
  -p 9300:9300 \
  elasticsearch
```

```bash:kibanaを起動(port5601)
docker run -d \
  --name kibana4 \
  --link elasticsearch:es \
  -e ELASTICSEARCH_URL=http://es:9200 \
  -p 0.0.0.0:5601:5601 \
  kibana
```

* http://localhost:5601/ にアクセスしkibanaの画面が表示されることを確認。

## logstashダウンロード

* [Download Logstash Free • Get Started Now | Elastic](https://www.elastic.co/downloads/logstash)
  * debファイルがあるのでダウンロード、インストール
  * /opt/logstash/bin/ をPATH通す。

## 設定

* [ubuntuにLogstashを入れる - Qiita](http://qiita.com/duke-gonorego/items/be0307601a0dc15685e3)

```bash:~/test.conf
input { file { path=> "/var/log/apache2/access.log" } }

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
    locale => "en"
  }
}

output {
  elasticsearch { hosts => ["localhost:9200"] }
}
```

```bash:configtest
$ logstash --configtest -f test.conf
Configuration OK
```

```bash:実行方法
$ logstash -f test.conf
```

## kibanaのグラフ設定

![discover.png](https://qiita-image-store.s3.amazonaws.com/0/25728/76b17c42-6634-eaeb-1ab5-64d7f1c9337b.png)

![visualize.png](https://qiita-image-store.s3.amazonaws.com/0/25728/51941215-dadc-aeaa-6c8e-4f5b797a253f.png)

![graph.png](https://qiita-image-store.s3.amazonaws.com/0/25728/ef954a7c-a52d-72a9-b19a-0ed0f9ea71ff.png)

* 右上にsaveボタンがあるので押下

## おわりに

* この組み合わせだとapache以外のログも簡単にグラフ化できますね。
Swift で Dictionary 型から JSON を作成し API を呼び出す

AWS API Gateway + Lambda で API を作成し、それを Swift から呼び出すコードを書いています。

Swift サイドで JSON を String 型で作成すると、

```
let str = "{\"operation\": \"create\", \"tableName\": \"sample_table\", \"Item\": {\"id\": \"\(id)\", \"name\": \"swift\"}}"
```

と構造が全くわからないコードになってしまいました。

Web で調べてみると Dictionary 型から JSON を作成することができるみたいでこちらのが見やすそう！
ただ、Swift 2.x のコードがパッと見つからなかったので、この方法がベストか不明ですが備忘のために残しておきます。

```swift
// 引数で緯度経度情報が渡される
// 経度緯度情報とタイムスタンプを渡すと、それをDynamoDBに格納するAPI
func postPosition(longitude: CLLocationDegrees, latitude: CLLocationDegrees) {
    let url = NSURL(string: "https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/position")
    let request = NSMutableURLRequest(URL: url!)
    request.HTTPMethod = "POST"
    
    // ID 作成
    let now = NSDate()
    let dateFormatter = NSDateFormatter()
    dateFormatter.locale = NSLocale(localeIdentifier: "ja_JP") // ロケールの設定
    dateFormatter.dateFormat = "YYYYMMddHHmmss"
    let id = dateFormatter.stringFromDate(now)
    
    // JSON 化したいデータを Dictionary で作成
    let dict: [String: AnyObject] = [
        "tableName": "sample_table",
        "Item": [
            "id": "\(id)",
            "longitude": "\(longitude)",
            "latitude": "\(latitude)"
        ]
    ]
    
    var json: String = ""
    do {
        // Dict -> JSON
        let jsonData = try NSJSONSerialization.dataWithJSONObject(dict, options: []) //(*)options??
        
        json = NSString(data: jsonData, encoding: NSUTF8StringEncoding)! as String
    } catch {
        print("Error!: \(error)")
    }
    
    let strData = json.dataUsingEncoding(NSUTF8StringEncoding)
    request.HTTPBody = strData
    
    do {
        // API POST
        let data = try NSURLConnection.sendSynchronousRequest(request, returningResponse: nil)
        
        json = NSString(data: data, encoding: NSUTF8StringEncoding)! as String
        
        // JSON -> Dict
        let jsonDict = try NSJSONSerialization.JSONObjectWithData(data, options: []) //(*)options??
        print(jsonDict)
    } catch {
        print("error!: \(error)")
    }
    
}
```

(*) のオプションの部分が何を入れていいのかよくわからず。
Swift で JSON を作成するときのお作法知りたい。。
1分で地味に効く SQL

## はじめに

この Tips は初中級者向けです。

業務で SQL を書く人は多いと思いますが、その編集を行う際に使うエディタはこれといったデファクトスタンダードがなかったり別の言語の中で文字列として扱うことも少なからずあったりして、その記法などについて暗中模索をしている方が多いのではないでしょうか。

1分で理解できて、地味に効いてくる SQL の Tips を、＿＿ひとつだけだと寂しいので＿＿3つご紹介します。

1. [動的に検索条件が決まる](#tips1)
2. [結合条件は Join 句を使う](#tips2)
3. [テーブル名をキーワードと同じ行に書く](#tips3)

<a id="tips1"></a>
## 動的に検索条件が決まる

プログラムの中で動的に SQL 文を組み立てる人は多いのではないでしょうか。「検索条件が指定されなければ全件検索」という SQL を組み立てる際に、下記のように ```WHERE``` 句をつけるかつけないかも動的にしていませんか？

```php:Before
// PHP のコード例です。
$sql = "
    SELECT
        *
    FROM user_info
    ";

$and = " WHERE ";

// 検索条件に名前が指定された場合
if ($user_name != "") {
    $sql .= $and. " user_name LIKE ". $user_name;
    $and = " AND ";
}

// 検索条件に年齢が指定された場合
if ($age != "") {
    $sql .= $and. " age = ". $age;
    $and = " AND ";
}
```

検索条件を追加する処理が多く複雑になってくるといつ ```AND``` が入ってくるのか分らなくなってきます。検索条件ごとに処理を入れなくてはなりません。また全件検索が指定される場合は ```WHERE``` そのものが不要になる場合も。
そこで最初に「必ず真になる式」を書いておき、続く条件には必ず ```AND``` を書くようにします。これだけでかなりコードが省略できます。
また、デバッグする際に条件を一つずつコメントアウトしたりするのにも便利です。
具体的には下記のようなコードになります。

```php:After

$sql = "
    SELECT
        *
    FROM user_info
    WHERE 1=1 -- <-ここがポイントです
    ";

// 検索条件に名前が指定された場合
if ($user_name != "") {
    $sql .= "   AND user_name LIKE ". $user_name;
}

// 検索条件に年齢が指定された場合
if ($age != "") {
    $sql .= "   AND age = ". $age;
}
```

この Tips はどこかのサイトで見たものなのですが、どこだったのか失念してしまいました。

<a id="tips2"></a>
## 結合条件は必ず Join 句を使う

次のような SQL を書く人は多いでしょう。参考書などに書かれている最初のサンプルがそうですから。

```SQL:Before
SELECT 
    u.name,
    a.zip_code
FROM user_info     u,
     address_info  a
WHERE u.user_id = a.user_id
    AND u.age < 20
```

私は、以下のように Inner Join を使って書いています。必ずそうしています。

```SQL:After
SELECT
    u.name,
    a.zip_code
FROM  user_info     u
    INNER JOIN  address_info  a
        ON  u.user_id = a.user_id
WHERE  u.age < 20
```

「タイプ量が増えるだけで結果が同じ」と、あまりメリットが感じられないかもしれません。
しかしながら「結合のための条件を From 句の下に」「抽出のための条件を Where 句の下に」分離することができます。
結合するテーブルが増えてきてデバッグに苦労したり、忘れた頃にやってくる保守の時期になると、そのメリットが見えてくるのではないでしょうか。

<a id="tips3"></a>
## テーブル名をキーワードと同じ行に書く

複数行に渡るような大きな SQL を書く場合、いろいろな記法があり現在までコレと言った決め手が無いのが悩みどころです。大きなシステムの保守を引き継いだ際に、テーブル名で grep した時に、どこでレコードを挿入したり削除したりしているかがわかるように ```INSERT INTO```、```DELETE```、```UPDATE```、```FROM``` らとテーブル名は同じ行に書いておいた方が良いと思いました。あまり美しくはないですが...。

```SQL:Insert文
INSERT INTO table_name
(...
```

```SQL:Delete文
DELETE table_name 
WHERE...
```

```SQL:Update文
UPDATE table_name 
SET...
```

```SQL:Select文
SELECT
    *
FROM table_name...
```

ま、これもテーブル名が変数に入ってたりすると漏れは出てしまうのですが。

## 免責

コード例は説明のために極端に単純化しています。コード例以外の部分で基本的な事柄の説明が省略されているかもしれません。

【追記】
「説明のため極端に単純化」が通じない人が居たようなので追記します。最初に「**初**中級者」と書いたのに、確かにそれは不親切でもありました。
最初の Tips のように、**文字列結合で SQL に値を渡してはいけません**。プリペアドクエリを使ってください。例は説明用に極端な単純化をしているだけです。
Mac OS X標準でDvorak

## Mac OS X標準でDvorak

Dvorak Advent Calendar 9日目．

システム設定 -> キーボード -> 入力ソース

![](https://lh3.googleusercontent.com/yh2eJAoPQd6_SzuNcVcAUuFuNR8McDZjNroIQ7JpzVyJjH0Xwe-zPGV_zw361kUOAfkTdDfYTnMP3lSGUubzqh8eFuH-4W_7Cq_tq-8dSXcR3XzFS2MylSiq0vyL45dpoyNbCb8qRX47CERDOD-SUiNGZnYTC8m8_1Mudl6HuRvVc-iq-tbNwDScIGx80ZIWJJ8bO5kssIIL5tC_lCSJqsamwGsPomOx8edA_9lOLy0At6S4HR3aijbUWe7zNGDwEvtWN7H9SWLgdlsC6RxDeAbqTk7TvSKPwXloD-dPiel6Mg2JN7Hqc2QoV9aIdzeb2KIZEXyqdTUKZTgBNJ1UvcYKLJ6Ri5aZFwhtXwd9aS0mZ5uKPmCktMnrAVFqXxAjf8cbwUz-loRU9qgsPBjoX8jYKlQEwq6zDdD0j3JHhYnl_P93z5AZCboO0gHj7JCYREb4C6u62oXnmumIfwgmLma44wudokiyqeu6oopfLX6_QaPi1m4NRAjlD3T-Zj60KPtCdm0svqJpwbM2IMs9FvWZgaJfp9dTWPwY9elnsJvD=w648-h485-no)


で，左下の `+` ボタン押下で Dvorak を選択して追加すればOK．

![](https://lh3.googleusercontent.com/dvQKrkwqW_eziB6F2wHVY3M0YaMi6P8WrfHQ-78Z_lVDpxM5T0-aCxBAnY-cZdoXwcOniJzFLz5TkQPoUFO0XMlhWollDuJXdx-6f7ihyLFmvIcmE8DYaSPvKBSLZOsP14BjxCvsmaMYT3_OH_QXGaUrpRmCuak3QGWVzMHOz6UyU49fRAamvIIaR7I9NeNuN-IVxSYipNA8Rb8URS_zFoRviJW27mVme_nkXpg2FHGT7iqaN-is1MrYW4sdVkye6GVRV9j8KYbKPPRGTcUqJAExrnko9Wc_1cPe8PQjT_GVzf63i34Th5ZsahAVdWm1gj_SCb0-1F-tXorEvHG6Sx3JVaUFUEHy_-kCeROUQD_QSMuFK3-Zm4lx-XNwvCjT-V-Rb-KLMhrg24GOGKya_D193fkGg1qbrnewU3hhsNAgECJlvc08SB8kbXEYGQT-6co8ZlTMbyFRB53WrNCBl4Y18xmjvFCyMa_02hmJuCeKdJyGlCtoSCLzUTzCTfLo-8DHj2pnyLco_wAm0-t5r6KWP3LYBOZAJSAbpF1_-E47=w549-h412-no)
便利すぎる負荷試験テストツールGatlingの使い方~ブラウザ操作記憶編~

前回の[便利すぎる負荷試験テストツールGatlingの使い方~自力ソース編~](http://qiita.com/nii_yan/items/d7d0ea949abeab13aea7)に続き、今回はブラウザで操作した内容をそのままソースに落としてテストする方法です。

これを使えば自分でソース書かないでも、ブラウザ操作がそのままソースになるのでテスト作る時にも楽ですね！！


まずはRecoderと呼ばれるGUIを呼び出しましょう

```bash
#Gatlingのインスールされたディレクトリに移動
sh bin/recorder.sh
```

上記のコマンド叩くとこんな画面が立ち上がります。
<img width="949" alt="スクリーンショット 2015-12-07 20.02.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/80769/8b2f6906-d689-201c-513e-f9e85a67d164.png">


ブラウザ操作を記憶するにはプロキシ設定が必要なので、macのプロキシ設定画面を開きます。


wifiアイコンのとこから "ネットワーク"環境設定を開く＞詳細＞プロキシタブ

ここで、Webプロキシ(HTTP)にチェックを入れてWebプロキシサーバに
localhost:8000
を入力しましょう

![スクリーンショット 2015-12-07 20.08.42.png](https://qiita-image-store.s3.amazonaws.com/0/80769/fbc13b45-d642-c3b1-d082-ade7a4585101.png)


これで準備はOKです！
この後は

Recoder GUIのStart!ボタン押した後の操作が記憶されるので、まずは余計なタブとか全部閉じましょう。

その上でブラウザのシークレットモードでやったほうが確実です。

今回は以下のgatlingのテスト用に用意されているサイトを使ってみたいと思います。
http://computer-database.gatling.io/computers

まずStartボタン押してから上記のサイトにアクセス

<img width="1129" alt="スクリーンショット 2015-12-07 20.22.30.png" src="https://qiita-image-store.s3.amazonaws.com/0/80769/288fd3e3-63e0-968b-959c-e13319448e01.png">

次は「ASUS」とFilterのテキストボックスに入れてFilter by nameボタンをクリックしましょう。

今回はここでrecoderGUIのSTOPボタンを押すと今までのコードがソース化されます。

ソースは以下の場所に出来てるはず。
`GATLING_HOME/user-files/simulations/RecordedSimulation.scala`

中身ができてますね

```scala
import scala.concurrent.duration._

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.jdbc.Predef._

class RecordedSimulation extends Simulation {

	val httpProtocol = http
		.baseURL("http://computer-database.gatling.io")
		.inferHtmlResources()

	val headers_0 = Map("Upgrade-Insecure-Requests" -> "1")

    val uri1 = "http://computer-database.gatling.io"

	val scn = scenario("RecordedSimulation")
		.exec(http("request_0")
			.get("/")
			.headers(headers_0))
		.pause(8)
		.exec(http("request_1")
			.get("/computers?f=ASUS")
			.headers(headers_0))
		.pause(2)
		.exec(http("request_2")
			.get("/computers/20607")
			.headers(headers_0))

	setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}
```

実行方法は

```bash
sh bin/gatling.sh
```

とすると、先ほど記録したRecodedSimulationが選択肢に出てきます

```bash
Choose a simulation number:
     [0] RecordedSimulation
     [1] computerdatabase.BasicSimulation
     [2] computerdatabase.advanced.AdvancedSimulationStep01
     [3] computerdatabase.advanced.AdvancedSimulationStep02
     [4] computerdatabase.advanced.AdvancedSimulationStep03
     [5] computerdatabase.advanced.AdvancedSimulationStep04
     [6] computerdatabase.advanced.AdvancedSimulationStep05
```

なので、０を選択して実行すると先ほど記憶した操作が実行されました！！

APIのテストや、WEB画面のテストもこれ使えばすぐテスト行えますね！！

次回は戻り値のチェックなど行ってみたいと思います。

##続き
[便利すぎる負荷試験テストツールGatlingの使い方~戻り値チェック編~](http://qiita.com/nii_yan/items/81e7399000484d595b40)
主にビルドに使ってる node.js を v0.10系から v4系にしてみた感想

これまで長らく、v0.10系だったところを、[ember-cli が v4系に対応した](https://github.com/ember-cli/ember-cli/pull/4815)ので、これ幸いとバージョンアップしてみた。

変更してみて良かった・気になったのはざっくり以下の点。

1. `class` つかえる
2. `let` , `const` つかえる
3. アロー関数もつかえる
4. `require` するときのパスの指定がやや厳密になった

## class つかえる

個人的にはコンストラクタと getter がうれしい。自前のモジュールはclassに書き換えてみた。

```
'use strict';
class Hoge {
  constructor(fuga) {
    this._fuga = fuga;
  }
  get fuga() {
    return this._fuga;
  }
}
module.exports = Hoge;
```

## let, const つかえる

ブロックスコープになるのがうれしい。
ただ最初、勝手に `const` を定数だと思い込んでいてはまった。
実際には定数ではなく、読み取り専用（再代入の禁止）が正解なのでオブジェクトのプロパティは変更できる。

```
'use strict';
const x = 1;
x = 2; // これはできない

const o = { x: 1 };
o = { x: 2 }; // これはできない
o.x = 2; // これはできる！
o.y = 10; // これもできる！
```

以上を踏まえて、var, let, const の使い分けは、まだどうするのがベストか考えてないものの、
現時点では、以下のルールでお試し中。

- `require` するとき: `const`
- 定数的扱い: `const`
- それ以外: `let`
- `var` は使わない

```
'use strict';
const hoge = require('hoge');
const FUGA_VALUE = '定数';
let piyo = 'その他';
```

## アロー関数

`var self=this;` とか `.bind(this)` がいらなくなっただけで満足。

## requireのパス

プロジェクト内で `require('package.json');` して、package.json内の値を参照していたのだが、その部分がコケてた。
調べてみると[require するときのパス指定の仕様が変わっていた](https://nodejs.org/dist/v4.2.3/docs/api/modules.html#modules_all_together)せいだった。

具体的にパスを指定してファイルを読むときは、`/` or `./` or `../` でパスをはじめる必要がある。package.json をよみこむなら、

```
'use strict';
const packageJson = require('./package.json');
```

としないといけない。

既存プロジェクトの利用するnodeのバージョンを変更するときは要注意。だが、一度直してしまえば、より厳密な指摘が出来ることになるので、よい気がする。

### require.resolve
ちなみに、これを調べる中で知ったのが、 `require.resolve()` 。
`require.resolve('hoge')` とすると、 解決後のフルパスが取得できるので、参照がうまくいかない場合はこれで調べてみると早い。

## おわり

ビルドのためだけに node.js を使っているような場合は、そんなに気にせずバージョンアップ可能だと思うので、余裕のあるときにためしてみるとメリットが見つかる…かもしれない。個人的にはメリットが多めだった。

その他の、v0.10系からv4系への変更については[yosuke_furukawa さんの記事]
(http://yosuke-furukawa.hatenablog.com/entry/2015/09/18/104452)がくわしいので、こちらをどうぞ。

また、[node.js における、ES6対応状況](https://nodejs.org/en/docs/es6/)もあわせて。
mruby Cheat Sheet

[この投稿は mruby Advent Calendar 2015 の 9 日目の記事です。](http://qiita.com/advent-calendar/2015/mruby)

# この Cheat Sheet の説明
mrubyのmrbgemsを開発する上で、つい忘れがちなことをまとめています。

mrbgems を開発する際に手元に表示して、見るようにしたりしています。細かい動作などが気になってしまった場合はソースコードを見るしかありませんが、記憶から引っ張り出せる程度に記述するようにしています。

最近 mruby のソースコードのコメントが充実しているようで、それを見ると何をするものなのかが分かるようになっています。

また、rubyでC拡張ライブラリを書いたことがあるなら、それほど抵抗のなくmrubyの拡張ライブラリも書けると思います。


# Class / Module を定義する
```c
mrb_define_module();  // モジュールを定義する
mrb_define_class();  // クラスを定義する
mrb_define_class_method();  // クラスメソッドを定義する
```

# mruby 変数を生成する

```c
mrb_value = mrb_nil_value();  // nil

mrb_bool = mrb_true_value();  // true
mrb_bool = mrb_false_value();  // false

mrb_value mrb_fixnum_value(30);  // 数値

mrb_value mrb_str_new_cstr(mrb, "Come on!");  // 文字列


// 配列
mrb_value array;
array = mrb_ary_new(mrb);
mrb_ary_push(mrb, array, mrb_true_value());

// ハッシュ
mrb_value hash;
hash = mrb_hash_new(mrb);
mrb_hash_set(mrb, hash, mrb_str_new_cstr(mrb, "key1"), mrb_fixnum_value(22));

```

# メソッドの引数を mrb_value で受け取る

```c
  mrb_value val;

  mrb_get_args(mrb, "o", &val);
```

# mrb_get_args() で受け取る型を指定する
`mrb_get_args()` に渡す `mrb_args_format` は以下を参照。
[mruby/mruby.h at master · mruby/mruby](https://github.com/mruby/mruby/blob/master/include/mruby.h#L732-L757)

# nil かどうか

```
  if (mrb_nil_p(val)) {
    // 'val' is nil
  }
```

# mrb_value の文字列を C 文字列に変換する

```c
  char *p;
  mrb_int len;
  mrb_value val;

  mrb_get_args(mrb, "S", &val);

  p = RSTRING_PTR(val);
  len = RSTRING_LEN(val);
```

## mrb_value 変数の型に合わせて処理をする

```c
    mrb_value val;

    switch (mrb_type(val)) {
    case MRB_TT_STRING:
        ...
        break;
    case MRB_TT_FALSE:
        ...
        break;
    case MRB_TT_TRUE:
        ...
        break;
    case MRB_TT_FIXNUM:
        ...
        break;
    ...

```
知っておきたいデザインパターン 2.シングルトンパターン


こんにちは、@Im0_3です。LIGアドベントカレンダーの７日目です！

前回に引き続きデザインパターンについてです。

前回の記事はこちらからご覧ください。
[知っておきたいデザインパターン 1.モジュールパターン](http://qiita.com/Im0_3/items/3d46f900aa4d4c5c3cde)

# シングルトンパターンとは
シングルトンパターンとはとはクラスのインスタンスが１つのオブジェクトに制限されるパターンです。普段AngularJSを扱っているのですが、AngularJSのServiceやFactoryがまさにシングルトンな構造になっています。

# 実践シングルトンパターン

## シングルトンパターン実装例 その１
以下がシングルトンパターンの例です。

```js
var singleton = (function() {
    var instance; // [1]
    function init(){
        var privateValue = 'I\'m Private';
        function privateMethod(){
            console.log(privateValue);
        }
        return {
            publicMethod: function(){
                console.log('I\'m Public');
            },
            publicPropaty: 'I\'m Public'
        }
    }
    return {
        getInstance: function() { // [2]
            if(!instance){
                instance = init();
            }
            return instance;
        }
    };
})();

var singleA = singleton.getInstance();
var singleB = singleton.getInstance();

console.log(singleA === singleB); // true
```
クロージャーのなかでインスタンスを保持するための変数を持ちます。[1] 
そしてsingleton.genInstanceでシングルトンのインスタンスオブジェクトを返します。[2]

最初の実行（singleA）ではインスタンスが生成され、生成されたインスタンスは[1]に保持されます。そして２回目の実行（singleB）ではすでに生成されたオブジェクトを返すことで共通のオブジェクトを保持します。

同じオブジェクトを共有しているため、一方のpublicMethodを変更すると以下のようになります。

```js
singleA.publicMethod = 'change publicMethod!';

console.log(singleB.publicMethod); // change publicMethod!
```
## シングルトンパターン実装例 その２

より簡潔で安全性の高い方法を@frontainerから教えていただきました。

```js
var single = function() {
  if (single.$instance) return single.$instance; //[2]
  var privateValue = 'I\'m Private';
  function privateMethod(){
    console.log(privateValue);
  }
  return single.$instance = {
    publicMethod: function(){
      console.log('I\'m Public');
    },
    publicPropaty: 'I\'m Public'
  }
};
single.$instance; //[1]

var singleA = single();
var singleB = single();

console.log(singleA === singleB); // true
```

こちらはsingleに関数を渡して、その関数自身に対して`$instance`というプロパティを設定します。[1]

関数が実行された際にはまず、`$instance`内にインスタンスが存在するかどうかをチェックします。[2] 存在しない際はそれ以降の処理を実行し、`$instance`にオブジェクトを代入し返します。存在する場合はそのまま`$instance`を返します。

またこの実装方法では以下は全て同じになります。

```js

var singleA = single();
var singleB = single();
var singleC = new single();
var singleD = new single();

console.log(singleA === singleB); // true
console.log(singleC === singleD); // true
console.log(singleA === singleC); // true
console.log(singleB === singleD); // true
```

このように実装することで、コンストラクタとしてインスタンスを生成しても、関数として実行しても全て同じになります。
ただグローバルから`single.$instance`からアクセスできてしまうので、を書き換える事ができるので注意が必要です。


## シングルトンのメリット・デメリット
シングルトンのメリットは、利用することでインスタンスが一つしか生成されないことが保証されることです。このパターンで書くことによって、いくつかの箇所で生成しても常に同じオブジェクトを共有することができます。例えばWebアプリケーションなどで、データベースにアクセスするは最初の一回に止め、それ以降はデータを使い回したい時などに有効です。

またもともとインスタンスを複数作る設計ではないので、複数インスタンスが存在すると困るようなときに使うのが良いでしょう。

デメリットとしては他のモジュールとの密結合を招き、テストしにくいコードになる恐れがあることです。なので使いどころには注意が必要です。
parseInt()は面白い。

`parseInt()`。仕様が実に面白い。

`parseInt()`は、引数に文字列を与えると整数値に変換して返すというものだ。そして2つ目の引数で`基数`を指定することができる。

```js
parseInt('10',10); // 10
parseInt('10',2); // 2
parseInt('10',8); // 8
parseInt('010'); //?
```
最後の4つ目。これはどう解釈されるだろうか。実は古いブラウザだったりすると、`8`を返す場合がある。昔は基数を省略した場合、頭が`0`で始まる場合8進数または10進数で解釈される仕様になっているものがあったためだ。WSHなんかはそうだった。なので期待値が`10`なのに`8`が返ってきて小一時間ハマったことがある。
ES2015の仕様では10進数で解釈されるようになっているそうなので、そういうハマりは今はないと思うが。

これはどうだろうか。`10`だろうか。

```js
parseInt('0x10');
```

正解は`16`である。`parseInt()`の仕様では基数が省略されているかもしくは0で、文字列が`0x`もしくは`0X`で始まる場合、16進数として解釈しようとするからだ。

次はどうだろうか

```js
parseInt(10)
```

規格書によれば、引数はtoString()されるそうなので、答えは10になる。なので

```js
parseInt(10,2); // 2
parseInt(100,2); // 4
parseInt(10,16); // 16
parseInt(10,8); // 8
```
となる。

後面白い仕様として、`parseInt()`はできる限り数字に変換しようとしてくれる。例えば

```js
parseInt('15px'); //15
parseInt(' 15x');//15
```
この仕様、CSSの属性値を数値に変換するときになどに便利だったりする。
ただしこれはだめ。

```js
parseInt('x15x');//NaN
```
`parseInt()`の基数は36まで指定できるそうだが、36進数なんて使うのかね。。そういオーバースペックっぽいところも面白いよね。