OmniAICreator/Qiita-1.07M huggingface dataset:
Java Silverつまりどころ(その２)

# つまりどころ〜
　　
こんにちは。

Java Silverを勉強していて、「うーん」と個人的につまったことをまとめます。

## static
staticで修飾されたメソッドや変数は、「static領域」に配置される。
インスタンスは「ヒープ領域」。GCちゃんの対象。
staticなフィールドへは「クラス名．フィールド名」で直接呼び出す感じになる。

## staticのアクセス領域
○staticメソッドはインスタンス変数にアクセスできない
(設定：お嬢だからはずかしい)

```java:
　class Pine{
        int i = 1;              //インスタンス変数
        static int j = i;       //static変数
        System.out.println(i);  //コンパイルエラー
        System.out.println(j);  //エラーにならぬ！
   }
```

○staticメソッドはインスタンスメソッドにアクセスできない
(設定：お嬢だからはずかしい)

```java:
　Class Apple{
       static void apple1() {   //staticメソッド
           method2();           //staticメソッドだから呼べる
           Methods.apple2();    //これでも呼べる
           apple3();            //お嬢だから、インスタンスメソッドは呼べない（コンパイルエラー）
       }
       static void apple2(){}   //staticメソッド
       void apple3() {}         //インスタンスメソッド
```

## staticイニシャライザ

　　
staticイニシャライザとは
クラスの読み込み時に一度だけ実行される初期化処理のこと。

staticで宣言されたブロックや、変数を指す。
以下のように使うと、最終的にageは20になる。

```java:

class Adult {
    static int age = 10;
    
    static {
        age = 20;
    }
}
```



staticイニシャライザはコードの上から順に実行される。
そのために下記のように書くとコンパイルエラーになる。

```java:
class Adult {
    static {
        age = 20;
    }

    static int age = 10;
}
```

変数の宣言前に値を代入しようとしているためにコンパイルエラーになる。

また複数のstaticブロックや変数を書くこともできる。
その場合も上から順番に実行されることに注意！


アウトプットして、ちしき固めていくぞ〜。
Fess 管理画面でアップロード可能なファイルタイプを追加する

Fess 10.3
システム>ページのデザイン>アップロードするファイル
ファイルタイプtiffを管理画面からアップロードできるようにします。

アップロード可能なファイルタイプは
app/WEB-INF/classes/fess_config.properties
に記述されています。

1. supported.uploaded.media.extentionsにtiffを追加します。
2. **Fessを再起動します。**

```properties:fess_config.properties
supported.uploaded.js.extentions=js
supported.uploaded.css.extentions=css
supported.uploaded.media.extentions=jpg,jpeg,gif,png,swf,tiff
```
品位が問われるAdvent Calendar ― シェルスクリプトはどこでも動く！

やってきました、Advent Calendar 2016。ここ数年毎年参加してきたので、よし「今年も」と思ったのですが……

# 脳内の本音を喋る回路とTwitterを直結している人

Twitter上にこういう発言をしている人がいました。

* "シェルスクリプトはどこでも動くと言ったな、あれは嘘だ"
* "echoコマンド一つでも、/bin/echoかシェルの組み込みコマンドかを意識しないといけないの、はっきり言って現代人のやることじゃない"
* "シェルスクリプトのプロジェクトに「curlが無いときは？」「whichコマンドが無いときは？」という性格の悪いプルリクを投げるの好き。"

まぁ、もう誰とは言いませんけどね。[^1]

## ここには反論を書くことにしました

誰とは言いませんが、このAdvent Calendarの関係者の発言とだけは言っておきます。で、こうして品位を欠いた状態の場所にまともな話題を書いても不毛ですので、冒頭で取り上げたツイートに対する反論とその理由を書くだけにしようと思います。

# シェルスクリプトがどこでも動くというのは嘘じゃない

さて、冒頭のツイートに真っ向から反論します。

「シェルスクリプトはどこでも動く」というのは、今年ついに現実になったのです。

## Bash on Ubuntu on Windowsが今年、革命をもたらした

どういうことでしょう？鍵は[Bash on Ubuntu on Windows（Windows Subsystem for Linux）](https://msdn.microsoft.com/ja-jp/commandline/wsl/about)の登場です。

ご存じのとおり今年の8月2日、Windows 10 Anniversary Updateがリリースされました。これにはBash on Ubuntu on Windowsというコンポーネントが追加され、Windowsに今までとは比べ物にならないほど本格的なLinux環境、つまりPOSIX的な環境がもたらされたのです。

Windowsといえば、2016年現在PC市場でシェア9割を誇るOSです。そして残り1割がMacとUNIX系OSでぼぼ占められています[^2]。今出荷されているWindows PCのバージョンはほぼWindows 10ですから、出荷ベースでみれれば**シェルスクリプトはPCのほぼ100%で動くようになった**のです。確かにまだ「PCの出荷ベースで見れば」という条件が外せませんが、Windowsのライフサイクル（サポート期限）を鑑みればその条件が外れるのも時間の問題です。

これによりシェルスクリプトが動くOSはほぼ100%ということになりました。あとはシェルスクリプトの互換性が確保できればよいわけすが、そのための開発指針こそ、我々が研究・提唱している**POSIX原理主義**です（[外のAdvent Calendar](http://www.adventar.org/calendars/1787)で詳しくやってます）。一言で言えば、シェルスクリプトの共通語を覚えるということ。一部の環境でしか通用しない文法やコマンド、オプション等を、それが方言であると知らずに使うからよそで動かないだけで、きちんと知ればいいのです[^3]。

きちんと知れば、こうして[シェルスクリプト製Twitterクライアント](http://qiita.com/richmikan@github/items/24af09dfaba2c6a6ea97)だって作れます。Bash on Ubuntu on Windows、OS X、CentOS、Ubuntu、Raspbian、AIX、それにCygwinで動くことを確認しました[^3]。

ついにOSの壁を越えるプログラムが書ける時代がやってきたということで、**今年はコンピューター史に残る革命的な年**なのです。

以上


[^1]: すっかり炎上して有名になったし、もはやここに書く必要もない。

[^2]: [Windowsが全バージョンでシェア増加 - 10月OSシェア | マイナビニュース](http://news.mynavi.jp/news/2016/11/02/150/)

[^3]: もっと色々な環境（現役でサポートされているOS）で動くはずなので試してみたい。
TPSカメラからシームレスにシーケンサーのカメラに切り替えた備忘録

[裏 Unreal Engine 4 (UE4) Advent Calendar 2016](http://qiita.com/advent-calendar/2016/ue4_inside)の12月3日の記事です。

# はじめに
[シーケンサー](https://docs.unrealengine.com/latest/INT/Engine/Sequencer/Overview/)を再生すると、カメラが乗っ取られて一瞬で切り替わってしまいます。
それをどうにかシームレスに再生する方法になります。
（シーケンサー再生後にSetViewTargetWithBlendとか実行してもカメラ取れなかった気がする。何か他に方法とかあったら教えてください）


プレイヤーの周りをぐるりと回るシーケンサー。
再生開始したタイミングでシーケンサーのカメラにカクッと切り替わる
![01.gif](https://qiita-image-store.s3.amazonaws.com/0/58518/714f61f6-0461-3a50-f564-808c7deb9a87.gif)


# SetViewTargetWithBlendを使用した補間

![02.gif](https://qiita-image-store.s3.amazonaws.com/0/58518/49ec0f0b-794a-c13b-9cc7-532d85ecd45c.gif)


多分これが一番簡単だと思います。
現在のカメラ～シーケンサー用カメラへの補間（SetViewTargetWithBlend）　→　終わったらシーケンサー再生
![seamless_sequencer_01.png](https://qiita-image-store.s3.amazonaws.com/0/58518/37c1ba47-0f29-743d-f639-32d7906e4a21.png)


ただこの場合、補間待ちが入るのでボタンを押した瞬間からシーケンサーを再生できず、演出に一旦間が空いてしまいます。


# 親ノードを使用した補間
twitterでアドバイス貰ったのでやってみました。

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr"><a href="https://twitter.com/com04">@com04</a> シーケンサー用にレベル上にダミーActorを入れて、そこに最初のカメラを設置、レベルブループリント上でシーケンサーが始まる前にActorを注視点に移動、カメラをタイムラインで最初のカメラへヌルっと移動させるロジックを組めば良い感じになりそうな気がしないでもないです</p>&mdash; シンダ C91 一日目 西 ひ-09b (@deadfactory) <a href="https://twitter.com/deadfactory/status/798140991941185536">2016年11月14日</a></blockquote>

![03.gif](https://qiita-image-store.s3.amazonaws.com/0/58518/8d492e38-90ef-518b-9e0e-c0c9dcfb5c3b.gif)


こちらはシーケンサー再生開始と同時に現在のカメラから補間します。力技です。

- ワールドへの配置はこんな感じ。Rootにいい感じにオフセット付けて補間します。
![seamless_sequencer2_01.png](https://qiita-image-store.s3.amazonaws.com/0/58518/161d263b-55d5-0bb9-6950-53aef2f2c13d.png)

<br>

- カメラ設定。Lookat先を「LookAtTrack」に。本来のLookAt位置には後で合わせる。
![seamless_sequencer2_00.png](https://qiita-image-store.s3.amazonaws.com/0/58518/b03281c9-2cf8-97bf-5afc-a67cea199365.png)

<br>

- まずシーケンサー再生開始位置のカメラ位置と注視点位置をどうにかして保存しておきます
![seamless_sequencer2_02.png](https://qiita-image-store.s3.amazonaws.com/0/58518/509ba565-bb9c-482a-0d80-917e37ffcaf9.png)

<br>

- 再生部分
![seamless_sequencer2_03.png](https://qiita-image-store.s3.amazonaws.com/0/58518/4acf25c7-7e60-195c-71ef-85cfb473e44d.png)
    - 現在カメラ位置と、シーケンサーカメラの初期位置の差分を保存。
![seamless_sequencer2_04.png](https://qiita-image-store.s3.amazonaws.com/0/58518/7e7f4287-aba8-70ef-10cb-f91f08864fae.png)
    - 現在カメラ注視点と、シーケンサーカメラの注視点初期位置の差分を保存
![seamless_sequencer2_05.png](https://qiita-image-store.s3.amazonaws.com/0/58518/2d08f436-2a9f-7162-2e84-5829ab00c6ae.png)
    - 取った差を、カメラのRoot、注視点のルートに対して補間する
![seamless_sequencer2_06.png](https://qiita-image-store.s3.amazonaws.com/0/58518/d87f1725-3bfa-b9c2-a508-c35c72a6a6fb.png)

<br>

カメラ本体（CineCameraActor1）のTransformはシーケンサーに取られるので、親Actor（CameraRoot）を用意して
そっちを動かすことで補間用の位置オフセットを無理やり付けています。

<br>
<br>

- おまけ<br>
更に、シーケンサーのカメラを原点基準に作成、SeamlessCameraRootにプレイヤーのTransformを突っ込んだりしていけば、
固定位置のカメラではなく移動したプレイヤーの周囲を回るカメラ等も作れます。<br>
やってみました。<br>
[![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/4NpMOg2NXLg/0.jpg)](http://www.youtube.com/watch?v=4NpMOg2NXLg)

<br>

# 締め
明日の[裏 Unreal Engine 4 (UE4) Advent Calendar 2016](http://qiita.com/advent-calendar/2016/ue4_inside)はalweiさんの「UE4のモバイルDLC&パッチ処理周りについて」です。
Serializablitiyとは？ 2. View Serializabilityについて

## 前回のまとめ

**FSR**という基準を導入したが実用性がイマイチなので別の基準を考える。

### View Equivalency

さて、最後の状態が一致するかどうかでスケジュールの等価性をテストすると不都合が起きてしまうので、それにさらに制約を加えて行く。2つのスケジュール図の最後の状態の一致のみを見てはダメなので、2つのスケジュール図の**トランザクションのすべてのステップ**でのエルブランセマンティクスが一致した場合に満たされるのが**View Equivalency**（ビュー等価）である。
もちろん最後の状態も「すべてのステップ」のうちの1つなので**View Equivalency**を満たす場合**Final State Equivalency**も確実に満たす。また、トランザクションを直列に逐次実行したスケジュールと**View Equivalency**が満たされる場合、そのトランザクションは **View Serializable**(以下VSR)と呼ばれる。
これで例えばさっきの物がどうなるかというと、トランザクションaのi番目のステップをTxa_iと表記するとして

![inbw.png](https://qiita-image-store.s3.amazonaws.com/0/1716/6dba0375-449a-6b50-e994-8ddbc1c8f2bd.png)

```:↑のエルブランセマンティクス
Tx1_1 = x0
Tx1_2 = F1(x0)
Tx2_1 = y0
Tx2_2 = F2(y0)
Tx3_1 = F3()
Tx3_2 = F3()
x = F3()
y = F3()
```

とそれぞれ表される。先ほど**Final State Equivalent**だった以下のスケジュールについて

![inbw2.png](https://qiita-image-store.s3.amazonaws.com/0/1716/88fe3ad1-8ec0-14a3-0e05-bb065b5d80d7.png)

```:↑のエルブランセマンティクス
Tx1_1 = x0
Tx1_2 = F1(x0)
Tx2_1 = Write(y) = F1(Read(x)) = F1(x0)
Tx2_2 = Write(x) = F2(Read(y)) = F2(Write(y)) = F2(F1(Read(x))) = F2(F1(x0)))
Tx3_1 = F3()
Tx3_2 = F3()
x = F3()
y = F3()
```

となり、Tx2_*のエルブランセマンティクスが一致しないのでVSRではない。x,yは一致しているのでFSRではある。

![mono.png](https://qiita-image-store.s3.amazonaws.com/0/1716/fe1a54eb-05f6-3703-0c07-d8ba013cda14.png)

```:↑のエルブランセマンティクス
Tx1_1: F1()
Tx1_2: F1()
Tx2_1: F2()
Tx2_2: F2()
Tx3_1: F3()
Tx3_2: F3()
```

このスケジュール図はVSRを満たす(Tx1→Tx2→Tx3もしくはTx2→Tx1→Tx3の逐次実行とビュー等価)。だがもしTx3が居なかった場合に残される結果は「xはTx2が書いたもの」「yはTx1が書いたもの」という歪な形になる。この特性はアボートなどが今後含まれる事を考えると好ましくないので、ビュー等価でも人類はまだ満足できていないということになる。

なお、スケジュールが**VSR**の条件を満たすか否かはNP完全問題であることが証明されている。P=NPが証明された暁には特定の前提が満たされた状態でのトランザクションスケジューリングに大きなブレークスルーが起きるかも知れない。

ここまでで、スケジュール空間の中におけるFSR, VSRの包含関係は

![benz.png](https://qiita-image-store.s3.amazonaws.com/0/1716/eab56771-9e5c-7b20-9be7-948748715164.png)

このようになっている。
秋茄子を嫁に食わせても良いけど、暗号化されたFragmented mp4はffmpegに食わせない方が良いかもしれない

## 今日の小ネタは
割りとどうでも良い小ネタです。動画配信の仕事でもしていない限り、全く関わることは無いだろうから。
そんなffmpegの話。

## 本当に極稀にですが
```
ffmpeg -i some.mp4
```
とか

```
ffprobe some.mp4
```
とかmp4の情報を調べようとした際に、画角情報等がおかしな値で表示される場合があります。

![con_ng.jpg](https://qiita-image-store.s3.amazonaws.com/0/146592/f40beadd-ce7b-289c-8485-f6e0e4d5d71a.jpeg)

こんな感じで。なんすか、この**96x32**って言う画角は・・・。
ちなみに正しく表示された場合は

![con_ok.jpg](https://qiita-image-store.s3.amazonaws.com/0/146592/7d5ce708-0de4-f0cd-be19-3ee52c52feb7.jpeg)

こんな感じになります。
更に、正しく表示されないmp4をmp4boxやmediainfoに食わせてみると、画角情報は正しく表示されます。

## 実は、
このffmpegで画角情報が正しく表示されないmp4は、とあるDRMで**暗号化されたMPEG-DASH用のFragmented mp4**です。
とは言え、暗号化は映像データそのものに対して行なわれ、画角情報が入っている Track Header Box (tkhd) は暗号化されないので
暗号化されただけで正しく表示されなくなるのは変な話です。
暗号化されていても、mp4boxやmediainfoでは正しく画角情報が取得できますしね。
**一体どういうこと？**

## そんなわけで
根気よくffmpegの出力を眺めつつ（このmp4はサイズが2GBもあるので大量にログがコンソールを流れていきます）
色々調べた結果分かったのは、ffmpegはmp4の画角情報を **Sequence Parameter Set (SPS)** から取得しているらしいという事。
そして、ffmpegはSPSがmp4のパースの最中に見つかる度に前のSPSの情報を上書きしている事。

## 詰まるところ
普通のmp4ならSPSは**DecoderConfigrationRecord上に存在**するだけで、そこから画角情報を取り出して終了だったのですが、
不幸なことにこのmp4はFragmented mp4だった為、**各フラグメントの動画データの中にSPSが含まれて**しまっていました。
暗号化されたSPSはパース出来なくてエラーになって元の正しいSPSが上書きされることはないはずなのですが、
これまた更に不幸なことに、**本当に極稀に暗号化されたSPSのパースに成功**してしまい滅茶苦茶な値で**元のSPSが上書き**されていた
と言うのが事の真相です。

というわけで、暗号化されたFragmented mp4をffmpegに食わせると良くないことが起こるかもしれないので、余り食わせない方が
良いかもしれないと言う話でした。
尚、CommonEncryption (CENC) の2nd Ed.以降ではメディアデータ以外は暗号化しない、と言う事になっているので今回のような事は
起こらないと思います。
Railsで感嘆符！を理解しよう（save, save!）

# はじめに
Railsの勉強をしている際、「メソッドの最後に`!`がついているけど何だこれは？？？」と思ったことがありました。Rubyの場合は`!`で否定演算子や`!!`でメソッドの返り値をtrue/falseにするなどがありますが、今回は**Railsメソッドの感嘆符`!`について**説明していこうと思います。

#感嘆符`!`とは
感嘆符とはエクスクラメーションマークのことです。以下Wikipediaより
>（かんたんふ）とは、約物のひとつで、「!」 と書き表される。 雨垂れ、または俗にビックリマークとも呼ばれる。 また英語表記に由来した呼称「エクスクラメーション・マーク (exclamation mark)」と呼ばれることもある。

## `!`をつけるとつけないとでは何が違うのか？
よく使われるメソッドで`create`や`save`などがあります。これらの処理を実行しレコードの作成、保存に失敗した際、通常の場合は`nil`を返します。しかし、`create!`、`save!`のように`！`をつけることにより`ActiveRecord::RecordNotFoundエラー`を発生させることができます。
**つまり`！`をつけることにより、例外を発生させるか発生させないかの違いです。**

---

`create!`、`save!`　→　レコードの作成・保存に失敗　→　**例外**を発生させる　
`create`、`save`　→　レコードの作成・保存に失敗　→　**nil**を返す

---

`save`メソッドの場合は保存の成功と失敗を true/false で返すのに対して、`save!`メソッドは保存を失敗した場合に例外を返します。つまり、`save!`を使えば例外をトリガーにしてロールバックなどの処理を行うことができるため、比較的使用頻度が高いかと思います。

#### 補足：そもそも例外処理とは？
>プログラムがある処理を実行している途中で、なんらかの異常が発生した場合に、現在の処理を中断（中止）して、別の処理を行うこと。その際に発生した異常のことを例外と呼ぶ

つまり、プログラムがすんなり通らなかったときに行う処理のことを指します。理想とは違う処理が例外という解釈でもいいと思います。

#まとめ

- メソッドの最後に`！`をつけることにより、レコードの作成などに失敗した際の挙動をかえることができる。
  →　例外処理を書く際に利用できる。
20行以下のコードで楽しむ簡単GLSL

Shader Art好きなGLSLビギナーですが、記事を書いてみます。

#今回行うこと
GLSLは難しいイメージですが、時折予想できない結果が出てくるところが面白いと思います。今回は以下の2つの点を踏まえたデモを3つ掲載します。

- 20行以下のコードである
    - 圧縮せずに可読性を保つ
- コードからは実行結果が予想しづらい

#デモ1:光る玉
![image](https://qiita-image-store.s3.amazonaws.com/0/26043/db864474-79c0-b9da-c969-b3dcd2b08ca1.png)

http://glslsandbox.com/e#37038.1

```glsl
void main( void ) {
	vec2 p = (gl_FragCoord.xy*2.0-resolution) / min(resolution.x, resolution.y);
	float l = 0.3/length(p);

	gl_FragColor = vec4( vec3( 1.0, 1.0, 1.0 ) * l, 1.0 );
}
```

- lengthを使い中心からの距離を求める
    - 分母にあるので中心に近いほど値が大きくなる。なので白に近づく

#デモ2:玉がフラクタルに?
![image](https://qiita-image-store.s3.amazonaws.com/0/26043/bc955185-0126-c7e4-04f6-c875342e0ab1.png)

http://glslsandbox.com/e#37038.2

```glsl
gl_FragColor = vec4( vec3( 1.0, 1.0, 1.0 ) * fract(l), 1.0 );
```

- fractは小数点部分を返す
- フラクタルな図形?が描画される

![image](https://qiita-image-store.s3.amazonaws.com/0/26043/13a062d3-7ffe-91ef-9b0d-37af148ef5cd.png)

```glsl
float l = 100.3/length(p);
```
lの値を100倍大きくすると、上のような画像になる。

#デモ3:玉が分裂?結合?
![image](https://qiita-image-store.s3.amazonaws.com/0/26043/9185ce8d-326b-b888-d8f5-c29bbf185ae8.png)

http://glslsandbox.com/e#37038.3

```glsl
void main( void ) {
	vec2 p = (gl_FragCoord.xy*2.0-resolution) / min(resolution.x, resolution.y);
	
	float a = mix(p.x * p.x,  p.y, sin(time));
	float l = 0.3 / length(p + a);

	gl_FragColor = vec4( vec3( 1.0, 1.0, 1.0 ) * l, 1.0 );
}
```

- sin(time)
    - timeは時間
- mixは線形補間

なぜか分裂します。不思議な動きです。

#まとめ
GLSLは奥が深いですが、難しいコードである必要はありません。簡単なコードとほんの少しのイマジネーションで面白いものが作れるのではないかと思っています :thumbsup:
Elm 0.17~0.18版 NativeModuleの書き方

<div class="text-danger">
ElmでNativeモジュールを扱う方法は公式に公開されていません。<br>
（個人的な予想ですが、将来的にも公式に承認されることは無いと考えています。）<br>
利用する時は自己責任の元に利用するようにして下さい。
</div>

Elm0.17~0.18では従来の`Elm.Native`モジュールが提供されなくなったようです。

これに伴って従来の`Elm.Native`にモジュールを追加していくような書き方が出来なくなり、よりシンプルにNativeModuleを定義出来るようになっています。

この投稿では、Elm0.17でのNativeModuleの書き方について見ていきます。

## モジュールをセットするための変数

Elm0.17では、モジュールを拡張するためにあるルールにそって命名されたjavascriptの変数にモジュールをセットすることでElmからアクセス出来るようになっています。

あるルールというのは、`elm-package.json`の`repository`に記載されたパスを元に決定されます。

例えば、デフォルトの`elm-package.json`の`repository`は`https://github.com/user/project.git`となっています。

この時、モジュールをセットする変数は下記のようになります。

```js
var _user$project$Native_[module]
```

変数名はアンダーバーから始まり、`repository`のパス`user/project`のパスセパレーターを`$`に置き換え、最後に`$Native_[module]`といった形式で変数を定義することでElmからアクセス出来るようになります。

## モジュールの定義方法

モジュールの変数にたいして、即時実行関数を代入します。
モジュールの実装方法は前バージョンと異なり、`Elm.Native`モジュールを利用せず、シンプルに関数とプロパティを実装していくだけとなります。

以下にサンプルコードを記載します。

```js:Native/Sample.js
var _user$project$Native_Sample = function() {
  var foo = 'foo';

  function add(a, b) {
    return a + b;
  }

  return {
    foo: foo,
    add: F2(add) // 関数は前バージョン同様、`Fn`という関数で評価したものをセットします
  }
}();
```

## NativeModuleにElmの型を定義する

このあたりは前バージョンの方法と全く同じです。

先程定義した`Native/Sample.js`を元にサンプルコードを記載します。

```elm:Sample.elm
module Sample exposing ( foo, add )


import Native.Sample


foo : String
foo = Native.Sample.foo


add : Int -> Int -> Int
add a b = Native.Sample.add a b
```

ここまで出来たら、あと自由にElmからモジュールを利用するだけです！
Node.js での MD5値の求め方

# 環境

- Ubuntu 16.04 LTS
- Node.js 4.x, 6.x 

# 動機

aws-sdk の `AWS.S3#putObject()`[^1] でファイルをS3にUploadする時、 `ContentMD5` で Base64 でデコードしたMD5値を指定すると、アップロード後のMD5と比較してチェックしてくれる。
[^1]: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property 

この機能を使いたくて、Node.jsでMD5値を求める必要があったので備忘録も兼ねてまとめみた。

# シンプル版

まずは簡単に同期的に書いてみる

```js
var crypto = require("crypto");
var fs = require("fs");

function md5(filePath) {
    let b = fs.readFileSync(filePath);
    let md5hash = crypto.createHash('md5');
    md5hash.update(b);
    return md5hash.digest("base64");
}
```

## 問題点

この実装だと、読み込むファイルのサイズが大きいとクラッシュしてしまう。
試しに 8GBファイルのMD5を求めると↓のようになる。

```sh
$ node md5pf.js
buffer.js:25
    const ui8 = new Uint8Array(size);
                ^

RangeError: Invalid typed array length
    at new Uint8Array (native)
    at createBuffer (buffer.js:25:17)
    at allocate (buffer.js:158:12)
    at new Buffer (buffer.js:56:12)
    at Object.fs.readFileSync (fs.js:419:16)
    at md5F (/home/yasuhiroki/md5pf.js:33:16)
    at Object.<anonymous> (/home/yasuhiroki/md5pf.js:41:13)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
```

MD5というより、 `readFileSync()` で大きなファイルを読み込もうとしているのが問題。

# Streamを使った版

大きなデータを扱うならば Stream を使えば良い。
となると非同期処理になるので、Promiseを返す関数にする。

```js
var crypto = require("crypto");
var fs = require("fs");

function md5(filePath) {
    return new Promise((resolve, reject) => {
        var readStream = fs.createReadStream(filePath);
        var md5hash = crypto.createHash('md5');
        md5hash.setEncoding('base64');
        readStream.pipe(md5hash);
        readStream.on('end', () => {
            resolve(md5hash.read());
        });
        readStream.on('error', (e) => {
            reject(e);
        });
    });
}
```

crypto は pipe に渡せるので、シンプルに `readStream.pipe(md5hash)` と書くことができる。
あとは、 stream の end のタイミングで計算結果を読み込めば良い。

先程クラッシュした8GBファイルのMD5値を計算すると↓のようにうまくいく。

```sh
$ node md5pf.js
N11F4wTV+6JFRuh89jqaqQ==
```

# おまけ

そもそもの動機だった、 `AWS.S3#putObject()` で ContentMD5を指定してチェックする方法は、サイズの大きいファイルで使うと `The Content-MD5 you specified is invalid for multi-part uploads` というエラーが発生する。

巨大なファイルは multipart upload が使用されるので、ファイルが分割されて少しずつアップロードされる。そのため、MD5値は分割された単位で求めなければならず、せっかく↑で求めたMD5値は使えなかった。

https://github.com/aws/aws-sdk-js/blob/5691296bd1c981a4fed04ee6eb42179c277ac079/lib/s3/managed_upload.js#L47 を読むと、代わりに `computeChecksums` を使うべしとある。
このフラグを使うと、aws-sdkがいい感じにMD5値のチェックをしてくれるので、自分で計算しなくていい。

も、もっと早くに知っていれば....
Google Apps Scriptの日毎のトリガーで時間をもっと細かく設定する

Googleスプレッドシート等のGoogle Apps Scriptを指定した時・分に毎日実行させるための方法をまとめます。

# 日毎のトリガーに設定できるのは**時**単位

Googleドライブで使用できるGoogle Apps Scriptは、トリガーを設定することで様々なタイミングで自動的に実行することができますが、毎日6時のような指定をした場合、実行は時間ぴったりではなく6時から7時の間というアバウトなタイミングになってしまいます。
6時ちょうどや6時1分前のような指定はできないのです。

ここで[日タイマー]ではなく[特定の日時]を選択すると分単位まで指定することもできますが、これだと毎日実行させるには1日ごとにトリガーを設定しなければなりません。

# 解決方法
実はGoogle Apps Scriptにはトリガーを設定する関数があるので、予め設定しておいた日毎のトリガーから、その日の[特定の日時]のトリガーを設定することで、分単位の時間で毎日スクリプトを実行することが可能になります。

今回は毎日17時59分にスクリプトが実行されるようにしてみましょう。

まずはスクリプトエディタの~~[リソース]~~[編集][現在のプロジェクトのトリガー]にて、トリガーを設定するための関数を毎日実行するよう設定します。
(目的の時間より前に実行されるよう時間を早めにしてある)
![トリガー.jpeg](https://qiita-image-store.s3.amazonaws.com/0/146433/d9b085db-d19b-a530-03ca-0c8c84cd8b3f.jpeg)

スクリプトは以下の通り

```javascript
// その日の17時59分にトリガーを設定
function setTrigger() {
  var triggerDay = new Date();
  triggerDay.setHours(17);
  triggerDay.setMinutes(59);
  ScriptApp.newTrigger("main").timeBased().at(triggerDay).create();
}

// その日のトリガーを削除する関数(消さないと残る)
function deleteTrigger() {
  var triggers = ScriptApp.getProjectTriggers();
  for(var i=0; i < triggers.length; i++) {
    if (triggers[i].getHandlerFunction() == "main") {
      ScriptApp.deleteTrigger(triggers[i]);
    }
  }
}

// 実行したいスクリプト本体
function main() {
  deleteTrigger();

  //
  // ここで何かする
  //
}
```

これで毎日呼び出されるsetTrigger()により、その日の17時59分にmain()を実行するトリガーがセットされ、その結果めでたく毎日17時59分にスクリプトを実行させることに成功しました。
BaaSの停滞感をブレークスルーするには

それほどよいものなら、私たちのサービスやフレームワークがもっと流行っててもいいだろうと思われるに違いありません。
でも、流行ってないからといって短絡的にダメなものと決めつけてもいけません。

今日は、流行っていない原因とそれを解決できるかもしれない案について話をしたいと思います。

#「潰しが利かない」ジレンマ

特にBaaSについていえることですが、流行らない理由を一言でいうなら、「潰しが利かない」ということになるかと思います。

多くの開発者は、よくわからないBaaSのようなサービスや流行っていないフレームワークを使うよりはスクラッチで開発した方がいいと思うでしょう。私もそう思います。
なぜなら、情報量が多くて流行っているものであれば安心して使えるかもしれませんが、よくわからないものを採用してしまって、もしハマったら大変苦労するからです。流行っているから使い、流行っていなければ使わないというのは、鶏卵のように思いますが、現実はそんな感じです。

あるいは、短い開発期間しかないので習得に時間を割く余裕がないとか、採用した後で技術が古くなりメンテされない状態になったときに負の遺産化するのではないかとか、心配したらきりがありません。私たち自身、短納期が理由で、ある大規模プロジェクトでReactやAngluarなどのフレームワーク採用を見送りました。（この話は後日詳しく説明したいと思います。）

#可用性の低さも流行らない原因の一つ

「潰しが利かない」リスクには、いざというときでも問題なく業務を継続できるといった可用性も含まれます。

ついこの間、私たちのAWS（東京リージョン）のサービスがダウンしました。sshすらできません。インスタンスを作り直してもダメです。
問い合わせ先もなく、しばらく途方に暮れていました。
万事休すかと思いましたが、別のリージョンにインスタンスを立てることで復旧できました。

Google App Engineでも肝をつぶす瞬間がありました。ある日突然認証が通らなくなったのです。
それは、ClientLoginを廃し、すべてOAuth2に対応するための措置だったのですが、昨日まで使えていたサービスが突然使えなくなるのはとてもビックリします。(単に事前告知を忘れていたからですが・・）

こんな経験をすると、クラウドはもう怖くて使えないなと思ってしまいます。

世の中のBaaSやPaaSは、そこそこ流行っているものもありますが、多くは私たちと同じジレンマに陥っているような気がします。つまり、楽を手に入れるかわりに潰しが利かなくなるというジレンマです。
BaaSやPaaSがいまいち盛り上がらないのは、独自のルールに則る必要があって、気がつけば負の遺産化に陥りやすいこともあるかと思います。可用性の問題もしかりです。去年はこのジレンマをベンダーロックインという表現で説明しましたが、「潰しが利かない」リスクといった方がしっくりきます。

私たちのサービスも、ある程度の拡大は可能だとしても、「潰しが利かない」リスクが厳然として存在するかぎり、爆発的に普及することはないだろうとも思っています。これは、世の中のBaaSやPaasの今の状況を見れば明らかです。

#開発者自身が参加すれば話は変わる

一方で、開発者自身がプロジェクトに入るという条件であれば、意外とすんなり採用をＯＫしてくれることもわかっています。潰しがきいて安心だからです。

なので、私たちがセリングするときは、サービスやフレームワークを売りこむというよりは、ソリューションを提案したり、案件そのものを請け負って、内部でサービスやフレームワークを利用するといった感じになっています。

しかし、それでは、プロジェクトにジョインするか私たち自身が開発を請け負うかのどちらかの方法でしか広められないことになってしまいます。

ドックフーディングという意味ではいいのですが、このやり方ではスケールしないので、何らかのブレークスルーが必要です。
広く普及させるためには、「潰しが利かない」リスクをどう払しょくするかが鍵だと思っています。

#可搬性とインターオペラビリティでブレークスルー

元々、Google App Engineから生まれたvte.cx/ReflexWorksですが、いまでは様々なプラットフォーム上で動作するようになっています。
例えば、BaaSで動作する同一の業務アプリケーションをオンプレミスでも動作させることができます。
まずはBaaS(vte.cx)でプロトタイプを開発し、運用後に可用性などが重要になった段階でオンプレミスに移行するといったことが容易に可能なのです。

高い可搬性を実現できているのは、業務アプリケーションが基本的に疎結合であることが大きいと思います。
また、データストアに、BDBやGoogle Datastore、RedisなどのKVSの他、RDBなどを採用できますが、下位のレイヤーをアプリケーションから隠蔽しているため、どのプラットフォームでもAPIのインターオペラビリティが確保されています。

このように、vte.cx/ReflexWorksアプリケーションであれば、BaaSからオンプレミスまでカバーでき、ベンダーロックインや「潰しが利かない」リスクを排除できます。

vte.cx/ReflexWorksは、今はまだ採用のデメリットの方がメリットよりも大きいと感じてる人の方が多いとは思いますが、実績も豊富になって情報量が増えてくればおのずと多くの人が使ってくれるようになると信じてはいます。
もとより短納期の開発が可能になり、高い生産性と高い品質をもたらします。
そして潰しが利きます。
そんな良いものを拒む理由はありません。

それでは、また明日。:grimacing:
機械学習でよく出てくる「e」について

[機械学習に必要な高校数学やり直しアドベントカレンダー Advent Calendar 2016](http://qiita.com/advent-calendar/2016/math_for_ml)の3日目の記事です。

[2日目の記事](http://serihiro.hatenablog.com/entry/2016/12/02/000000)を書いて下さった[seri_k](http://qiita.com/seri_k)さんが紹介されたチャート式の参考書、懐かしいですね。「大学への数学」と並んで、高校の頃使っていた教材です。

で、そんな高校数学の参考書に出てくるもので、機械学習の分野でも頻出するのが $e$ という記号。シグモイド関数やソフトマックス関数などで使われますし、誤差関数でよく出てくる交差エントロピー誤差にも自然対数という形で出てきます。この $e$、高校数学で習うものですが、今回の[高校数学やり直しアドベントカレンダー](http://qiita.com/advent-calendar/2016/math_for_ml)を機に復習してみます。

#eの定義を見てみると...
教科書や参考書を見ると出てくる$e$の定義は以下の通りです。
$$e = \lim_{t \to 0}(1+t)^{\frac{1}{t}}$$

値としては $e=2.71828182845904･････････$ となるわけですが、いまいちピンときません。

そこで、ちょっと別の考え方で $e$ を見てみます。

#指数関数
その前に、まず指数関数を復習します。$f(x)=2^x$をグラフに書くと、以下のようになります。
<img width="500" alt="指数関数のグラフ" src="https://qiita-image-store.s3.amazonaws.com/0/123715/47c2bb9c-c621-e097-43b3-20b1aa99df35.png">

この関数における任意の $x$ の位置における傾きを求めてみます。例えば $x=1$ におけるこのグラフの傾き、つまり以下のグラフの赤線で示した接線の傾きですが、数値微分の考え方を用いて近似値を求めてみます。
<img width="500" alt="無題.png" src="https://qiita-image-store.s3.amazonaws.com/0/123715/10ddbac4-5db5-ac62-2b81-63556bc4ff47.png">


$x=1$から±0.01の範囲の値と、その$f(x)$の値を見てみると、
　　$x=0.99$のとき、$f(x)=2^{0.99}=1.986185...$
　　$x=1.01$のとき、$f(x)=2^{1.01}=2.013911...$
です。ここから、接線の傾きの近似値は$$\frac{2.013911 - 1.986185}{1.01-0.99} = 1.386305$$となります。
ここで、$x=1$のときの$f(x)$の値を求めると、
$$f(1)=2^1=2$$ですね。なので、接線の傾きとの差は、$$2-1.386305=0.613695$$です。

では、$f(x)=3^x$の時の$x=1$における接線の傾きはどうでしょうか？
先ほどと同様に、±0.01の範囲での近似値を求めてみると、
　　$x=0.99$のとき、$f(x)=3^{0.99}=2.967222...$
　　$x=1.01$のとき、$f(x)=3^{1.01}=3.033140...$
ですので、接線の傾きの近似値は$$\frac{3.033140 - 2.967222 }{1.01-0.99} = 3.295903$$となります。
ここで、$x=1$のときの$f(x)$の値を求めると、$$f(1)=3^1=３$$ですね。なので、接線の傾きとの差は、$$3-3.295903=-0.295903$$です。

同様に$f(x)=2.5^x$の接線の傾きの近似値は、$2.290759$。$f(1)$との差は、$0.209241$です。

$f(x)=2^x$のとき、$x=1$の接線の近似値は1.386305。$f(1)$の値と接線の近似値の差は0.613695。
$f(x)=2.5^x$のとき、$x=1$の接線の近似値は2.290759。$f(1)$の値と接線の近似値の差は0.209241。
$f(x)=3^x$のとき、$x=1$の接線の近似値は3.295903。$f(1)$の値と接線の近似値の差は-0.295903。
上記3つの指数関数の値と、その点における接線の傾きとの差は、それほど大きくありません。

この調子で探っていくと、$f(1)$の値と接線の傾きの差が0、つまり$$f(1)="x=1のときの接線の傾きの値"$$となる$f(x)$が見つかるのではないでしょうか？

これこそが、$e=2.71828182845904･････････$なのです。
上記と同様の計算を、この$e$の数値でやってみましょう。ちょっと桁数が多いので、$e=2.71828$で計算してみます。

$f(x)=2.71828^x$のとき、
　　$x=0.99$のとき、$f(x)=2.71828^{0.99}=2.691233...$
　　$x=1.01$のとき、$f(x)=2.71828^{1.01}=2.745599...$
ですので、接線の傾きの近似値は$$\frac{2.745599 - 2.691233}{1.01-0.99} = 2.718323476$$となります。$f(1)=2.718128$に非常に近い値が算出されています。eの数値の小数以下の桁数を増やして精度を上げれば、より近い値になります。
つまり、先ほど書いた$f(1)="x=1の時の接線の傾きの値"$となるわけですが、この関係は$x=1$のときだけに成り立つものではありません。$f(x)=e^x$では、$x$がどんな値の時にでもこの関係式は成り立ちます。上記の計算を、$x$の値を2や3など色々変えて試して見てください。どの値にしても、$f(x)$の値が接線の傾きの値と同じになると思います。

ここで思い出して欲しいのが微分です。微分は、グラフ上では関数の接線の傾きを表します。その接線の傾きが、$f(x)=e^x$のときには、$f(x)$の値と同じになるのです。

ですので、$f(x)=e^x$のときには、その微分は$f'(x)=e^x$になります。

この$e=2.71828182845904･････････$ですが、他にもいろいろ面白い性質を持つ不思議な数のようです。そのため、このような本まで出版されています。ご興味があれば是非。
・[不思議な数eの物語](https://www.amazon.co.jp/dp/4000059432)
・[対数eの不思議―無理数eの発見からプログラミングまで](https://www.amazon.co.jp/dp/406132862X)


[機械学習に必要な高校数学やり直しアドベントカレンダー Advent Calendar 2016](http://qiita.com/advent-calendar/2016/math_for_ml)の4日目は、[kazutarosu](http://qiita.com/kazutarosu)さんです。
エンジニアなりたての私がRailsのエラーについて考える（居酒屋編）

はじめまして、こんにちは。
今夏に営業からエンジニアにジョブチェンジをしたdhk-kです。
よろしくおねがいします。

アドベントカレンダー参戦にあたって、泣いて喚いて断っていたのですが、せっかくということで、こうして寄稿させていただくこととなりました。

# まえがき
さて、前述の通り私は、この夏7月頃にエンジニアにジョブチェンジをいたしました。
エンジニア歴5ヶ月のひよこでございます。
弊社入社前でも、保険会社で営業をしていたため、プログラミングの知識は一切ない状態からのスタートでした。

そんな私に技術的な話は不可能と言っても過言ではないでしょう。

# テーマを考える
そこで、はて、どういった観点から、記事を作成しようかと、悩みに悩みました。
趣味関連でいくか、業務関連でいくか…。

一部ピックアップ
・FG試投数から考察する来週のBリーグの勝敗予想
　・これは絶対ゆくゆくやる
・NBA移籍情報の自動取り込みデータベース化
　・NBA関連のサイトを見るために英語の勉強が必要だ...
・エンジニアになる前はわからなかったこと
　・この5ヶ月間すべてそうだったので書ききれない
・やっぱ筋肉いっちゃう？？
　・二番煎じ感満載なので、やめておこう...

悩みに悩んだ結果、改めてきちんと理解しなければいかないと思っていることを、今後自分と同じようにまったくの未経験からジョブチェンジしたひとのために、~~そして、自分自身の頭の整理のために、~~ここにまとめようと決意しました。

そのため、内容としては、いろはのいレベルにすら至っていないので、温かい目で見守っていただけると幸いです。
なんせ、ようやくハイハイで動き回るようになった赤ちゃんエンジニアですので...

# 素人の私がエラーを理解する（居酒屋でたとえる編）
赤ちゃんのくせに居酒屋に例えるとは何事か、と思われる方も多いでしょうが、安心してください。
実は、私三十路手前の立派な大人でございます。

私自身、エラーの処理を初めて実装したときに、周りのみなさまに教えていただいたことを、頭の中で「たとえ」をイメージしていたからであり、ふざけているわけでは決してありません。

では、初学者必読「たのしいRuby」をお供にまずは、いちから勉強していきます。

## エラーの種類
・データのエラー
>  家計簿の計算を行う際に、金額があるべき欄に商品名が書かれていては必要な計算ができません。

なるほど。これはわかりやすいですね。
生ビールの値段が、瓶ビールなどという記載があったら、大変です。
割り勘ができません。

・システムのエラー
> ハードディスクの故障のような明らかな障害や、（中略）プログラムの力だけでは回復できない問題が起こることもあります。

お客様「生ビール3つ！」
店員さん「かしこまりー」「オーダー！生3つ～！」
とここまでうまくリクエストが伝わってきたものの、キッチン担当が倒れて動けない

この場合は、お客様のもとへ生ビールが行き届くことはないでしょう。
まず、救急車を呼ばなくてはなりません。

・プログラムのミス
> 存在しないメソッドの呼び出しや、引数として渡す値の誤り、（中略）プログラムのミスによるエラーも考えられます。

メニューに誤って記載されている為、お客様からは発注を受けてしまうケースがこちらですね。
お客様「麻婆豆腐ひとつと、餃子ふたつ！」
店員さん「当店では、麻婆豆腐は扱っておりません」
お客様「いやいや、メニューに書いてあるじゃん！」
店員さん「当店では、麻婆豆腐は扱っておりません」
揉めますね。

## 対処
・エラーの原因を取り除く
・無視して続行する
・エラー発生前の状態を復元する
・もう一度試す
・プログラムを終了する
ふむふむ。

> エラーの原因がユーザにある場合や、プログラム自身がエラーの原因を取り除くことができない場合は、ユーザに対して、わかりやすいエラーメッセージを報告しなければ、やはり使いにくいプログラムとなってしまうでしょう。

なるほど。至言ですね。きちんと例外を拾って、表してあげることこを、皆様に好まれるよい居酒屋となるための一歩なわけですね。

エラーの種類に応じて、それぞれ適当な例外処理を与えてあげる必要がある、と。

## 居酒屋をイメージしつつエラーについて考える
では、例外設計を考えていきましょう。
ブラウザとサーバをそれぞれ、お客様とお店としましょう。
いきなり苦しい...

### エラーの分類
居酒屋におけるエラーとはどういったことが想定されるでしょうか。
ここで、注文した料理が

・Case1：お客様がメニューにない料理を発注してきたとき

・Case2：ホールスタッフが厨房までメニューを伝えられないとき

・Case3：ホールスタッフがストライキで帰ってしまったとき

なるほど、どうやらお客様起因のエラーと、当店起因のエラーのおおまかにふたつにわけられることがわかりました。
Case1がお客様起因、Case2、Case3が当店起因のエラーです。

### 対処
前段で2つのエラーがあることがわかりました。
それぞれ如何にして対処するかが必要です。

・Case1については、優しく諭してあげることが重要ですね。
答えはこうです。

店員「お客様当店では、そのメニューは扱っておりません。」

これだけでは、不十分ですね。
さらに、こうです。

店員「同様の味付けでしたら、ホッケの塩焼きがおすすめですよ。」

ここまで伝えてあげて正しい挙動へ誘導してあげましょう。

・Case2、3については、お客様から「注文が来ない」と言われ次第、謝り倒してすぐに対処、居酒屋としては状況に応じて割引なども検討するのもひとつですね。
答えはこうです。

店員「申し訳ございません！すぐに作ります！」
Case2では、メモを取らせるようホールスタッフを指導しなおす、Case3については、すぐに新しいキッチンスタッフを立てなければいけません。

ただ、それではあまりにお待たせすることになるので、緊急対応としてCase2ではキッチンスタッフが直接オーダーを伺いに行く、Case3では私が自ら調理をすることとなるでしょう。

# 最後に
私の拙いおつむでは、周りの支えてくださるエンジニアの方々の説明を、このように頭の中でイメージを置き換えて理解を進めていきました。
もし、言葉がわからないよ...ということでお悩みの未経験エンジニアの方がいらっしゃれば、身近なことに置き換えて少しずつわかっていくのもよいかもしれません。

正直まだまだ理解できていない点が多く、本記事の中でも意味不明な説明をしてしまっていること、あるいは、正しくない説明をしてしまっているかもしれません。
この場を借りて、深くお詫び申し上げます。

以上をもって、本記事を結ばせていただきます。
PocketCHIPでGoのGUIアプリを動かしてみる

昨今、サーバサイドでのサービスを支える分野で活躍が目立つGo言語ですが、すこし違う分野でも活躍できないかなーと考えている今日この頃。

PocketCHIPでGoを書けるようにする
--

[以前PocketCHIP手に入れました。](https://twitter.com/atotto/status/749128022825902081)
まずはこいつでGoをコンパイルできるようにします。

[PocketCHIP](https://getchip.com/pages/pocketchip)は、機能的にはraspberry piに近いですが、昔のゲームボーイのような形にカラーディスプレイとキーボードがついているマシンです。

![pocketchip](https://pbs.twimg.com/media/CmVv8qoUsAAUru6.jpg)

アーキテクチャはARMです。他のマシンでクロスコンパイルしたバイナリを実行しても良いですが、せっかくキーボードがついてるのでその場でコードを書いて実行できるようにしておきます。

### Goの環境をセットアップ

シンプルに行きます。

https://golang.org/dl/ にARM用にビルドされたコンパイラがあるのでそれを使います[^3]。
ARMに関連するドキュメントはこの辺りです
https://github.com/golang/go/wiki/GoArm

wifiにつながるのでwgetで(go1.7.4の場合):

    $ wget https://storage.googleapis.com/golang/go1.7.4.linux-armv6l.tar.gz
    $ tar xzf go1.7.4.linux-armv6l.tar.gz
    $ export PATH=$HOME/go/bin:$HOME/bin:$PATH; export GOROOT=$HOME/go; export GOPATH=$HOME

go envをみると:

```
$ go env
GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/home/chip/go"
GOTOOLDIR="/home/chip/go/pkg/tool/linux_arm"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
```

使えそうです。エディタはこの際面倒なのでvimで行きましょう。[^1]

GoのGUIアプリ（サンプル）を試す
--

せっかくX11が動いているのでGUIアプリを動かしてみましょう。[^2]

    $ go get golang.org/x/exp/shiny
    $ go get golang.org/x/mobile

動作確認

    $ go run src/golang.org/x/exp/shiny/example/basic/main.go

コンパイルに時間がかかりますが、動きます！

![IMG_6750.jpg](https://qiita-image-store.s3.amazonaws.com/0/30362/1bead619-637b-5e4c-7d86-4b0d0f801d56.jpeg)

flappy gopherも動きます:

    $ sudo apt-get install build-essential
    $ sudo apt-get install libegl1-mesa-dev libgles2-mesa-dev libx11-dev
    $ cd golang.org/x/mobile/example/flappy
    $ go build
    $ ./flappy

![IMG_6751.jpg](https://qiita-image-store.s3.amazonaws.com/0/30362/07a988ab-5122-0c06-647c-46a7b5cb1f04.jpeg)

画面タップでちゃんとジャンプします。

まとめ
--

思いの外、すんなりとGUIアプリが動きました。基本的にデスクトップLinuxと同じようにX11が動いてるので動いて当然と言えばそうかもしれませんが、ちょっと感動。

誰得記事な感じですが、普段とは違うところで動くGoも良いのでは無いでしょうか。

それでは！

[^1]: emacsユーザです
[^2]: go1より前、exp/draw/x11パッケージがあったような
[^3]: ありがたいことに、go1.6からARM用のコンパイラが配布されています
videoタグで画面いっぱいレスポンシブな動画を設置する方法

videoタグで設置した画面いっぱいの動画ですが、画面サイズを変更すると、横縦比が変動して動画が画面中央に設置されなかったので、以下の方法で対応してみました。

## そのまえに…基礎的なvideoの属性メモ

| 属性 | 値 | 効果 |
|:--|:--|:--|
| src="" | (URL) | ファイルのURL |
| height="" | 数値 | 要素の高さ |
| width="" | 数値 | 要素の幅 |
| autoplay="" | autoplay | 自動的に再生を行います。 |
| controls="" | controls | 動画再生をコントロールするUIを表示します。 |
| loop="" | loop | 動画を繰り返し再生します。 |
| preload="" | auto<br>none<br>metadata | 動画ファイルを読み込みはじめるタイミングを設定します。preloadが指定されていてもautoplayが入っている場合、autoplayが優先されます。<br><br>auto: 事前に読み込む/事前に読み込んでも良い<br>none: 事前に読み込まない<br>metadata: メタデータだけ読み込む |
| poster="" | (URL) | ブラウザが指定したファイルを再生できない環境の場合、代替する画像を指定できます。 |
| muted | muted | 動画に音声がついている場合、音を出さない設定にできます。 |
| mediagroup="" | 任意の文字列 | audioとvideoなどを同期できます。同じ値を入力することで、同じグループとして指定し、再生を同期することができます。 |
| crossorigin="" |   | 外部からの直リンクを防ぐことができます。デフォルト値（初期設定）の場合は、受信元のドメイン設定をしなくても読み込みは可能ですが` use-credintials"を設定することで、SSLやHTTP認証などを使った安全な読み込みを指定できるようになります。 |

## 実際のhtml/css/jQueryの記述

``` html
<div class="wrapper">
  <video id="video" poster="movie_bg.jpg" muted autoplay loop>
    <source src="/movie.mp4" type="video/mp4">
    <source src="/movie.webm" type="video/webm">
    <p>video要素がサポートされていないブラウザでご覧になっています。</p>
  </video>
</div>
```

CSSで画面いっぱいに動画を設置するように以下のように記述します。

``` scss
.wrapper {
  height: 100%; // 高さを画面いっぱいに指定する。(vhが効かない場合の対策)
  height: 100vh; // 高さを画面いっぱいに指定する。
  position: relative;  //横幅がウィンドウズサイズの縦幅よりもはみ出てしまう場合に、左にずらすために指定。
  width: 100%; // 横幅もいっぱいに。
}

#video {
  background: url('/video_bg.jpg') no-repeat; // 動画が再生を始めるまで、cssのほうでも背景を設定します。
  background-attachment: fixed; // 中央揃えになるように、fixed。
  background-position: center center; // positionも中央に。
  background-size: cover; // 画面サイズに応じてサイズを可変するように設定。
  left: 0;
  // 以下、画面いっぱいにするためのCSS設定
  min-height: 100%;
  min-height: 100vh;
  min-width: 100%;
  min-width: 100vw;
  // wrapperのサイズに応じて、leftの位置をjQueryで指定するため、positionはabsoluteにします。
  position: absolute;
  top: 0;
  // z-indexは調整してください。
  z-index: 1;
}
```

上記のままだと、画面の高さにメディアの高さが合ってしまうことで、メディアの横幅が画面サイズよりも大きくなり、leftの位置を調整しないと中央に寄らなくなってしまいます。

```
$(function() {
  var getWindowMovieHeight = function() {
    // ここでブラウザの縦横のサイズを取得します。
    var windowSizeHeight = $(window).outerHeight();
    var windowSizeWidth = $(window).outerWidth();

    // メディアの縦横比に合わせて数値は変更して下さい。(メディアのサイズが width < heightの場合で書いています。逆の場合は演算子を逆にしてください。)
    var windowMovieSizeWidth = windowSizeHeight * 1.76388889;
    var windowMovieSizeHeight = windowSizeWidth / 1.76388889;
    var windowMovieSizeWidthLeftMargin = (windowMovieSizeWidth - windowSizeWidth) / 2;

    if (windowMovieSizeHeight < windowSizeHeight) {
      // 横幅のほうが大きくなってしまう場合にだけ反応するようにしています。
      $("#video").css({left: -windowMovieSizeWidthLeftMargin});
    }
  };

  // 以下画面の可変にも対応できるように。
  $(window).on('load', function(){
    getWindowMovieHeight();
  });

  $(window).on('resize', function(){
    getWindowMovieHeight();
  });
});
```

縦横の現在のサイズを把握して、画面に合わせて leftを指定していくことによって、画面の可変にも耐えられるようになりました。
Stateパターンは素晴らしい

# なぜこの記事を書くのか
StateパターンはGoFのデザインパターンの中でも不遇だという記事を見た。あまり使えないパターンだということだろう。
確かに、私以外に使っている人を実務上で見たことがない。みんな知らないか、知っていてもifで書けばいいと思っているのだろう。
だが、私の知る限り、Stateパターンはかなり強力だ。理解には時間がかかったが、私の最も好きなデザインパターンの一つだと言える。
そんな世間とのかい離を感じつつ、Stateパターンが見直されることを願って、この記事を執筆する。
酔っぱらっているので後ほど加筆するかもしれない。

# Stateパターンの説明
Stateパターンは、オブジェクトの状態に応じて、その振る舞いを変える仕組みだ。これだけだとStrategyパターンと同じだと思われるだろうが、基本的には、振る舞いを行った後に遷移が生じる。
Strategy + 状態遷移と考えると外れないだろう。

# Stateパターンの洞察
現在のStateにおいて、呼び出されたメソッドに応じて振る舞いを行い、次のStateに遷移する。
それだけと言えばそれだけだが、ポイントは、状態遷移表を単純にコードに落とせるという点だろう。

|State       |Action1/transition|Action2/transition|
|:-----------|:-----------------|:-----------------|
| State1     |print('foo')/State2|print('foo2')/State1|
| State2     |print('baa')/State2|print('baa2')/State3|
| State3     |print('hoge')/State1|print('hoge2')/State1|

上記のようなMealy型の状態遷移図を作れば、確実にコードに落とせる。
Stateごとにクラスが分かれていて、実装するメソッドも決まっているため、上記の表が書ければ機械的にコードを書くだけで良い。
コードレビューの際には、上記の表のチェックを入念に行う必要があるが、コード上のミスは簡単に見つけられるので、
表だけに集中すればよい。

# Stateパターンの狙い
現代のソフトウェア開発の難しさは、設計と実装を等価に行うことの難しさにあると思う。設計上は完璧で、まったく無駄がなく、あらゆるユースケースに対して快適に動作する予定であっても、いざ実装を行おうとするとそれが実現できない場合や、実現する上で設計と異なってしまうことは往々にしてある。それをFeasibility Studyが足りないと断ずることは簡単だが(怒るだけならマネージャーは簡単だ)、ここ数十年の期間多くのプロジェクトが失敗している現実を見ると、やはりソフトウェア開発は非常に難しく、計画通りにいかないという点を認めるしかないのではないかと思う。
私は正直、500行くらいのコードなら頭の中で計画した通りに書けるようになったが、1000行を超えると想定外が生じて試行錯誤することが多い。つまり、実装途中に、あらかじめ想定していた設計ではうまく動かないことが分かり、ちょっと汚くなると分かりつつも変数やメソッドのscopeを広げて無理やり処理可能にすることがある。

Stateパターンでは、設計と実装のマッピングは非常にシンプルなので、大多数の労力は設計の正しさのチェックだけで済む。また、Stateの追加に伴う修正により、予期せぬ不具合が生じる可能性も非常に少ない。
表を正しく書けば、コードに不具合は発生しない。こんな当たり前のようなことが、現代のプログラミングにおいては非常に難しいが、これを実現できる数少ないパターンであることが、Stateパターンの魅力だと思う。
未来のソフトウェア開発は、きっと今のような困難は解決されている。大した役割を持っていない小さなクラスで、うっかり変数のnullチェックを忘れたからといって、NullPointerExceptionでシステム全体が落ちるなんてことはないはずだ。
Stateパターンは、そんな未来を先取りするかのような理想的なパターンで、設計が正しければ、実装も正しく行えるという夢のようなテクニックだ。
[1day1lang AdventCalender] day2 C++

２日目はC繋がりで、今まで触ったことのないC++

１日目の記事はこちら
[[1day1lang AdventCalender] day1 C言語](http://qiita.com/Qutjl/items/e4dae8343c46c10f4cba)

#環境構築
##コンパイラの確認
g++がインストールされているか確認

```bash
$ g++ -v
gcc version 5.4.0 20160609
```
昨日と同じく、元からインストール済み

##Hello World!

```cpp:helloworld.cpp
#include <iostream>
using namespace std;

int main() {
    cout << "Hello World!" << endl;
    return 0;
}
```

改行は`\n`でもいいが、`endl`がスタンダードらしい
helloworld.cppをコンパイル

```bash
$ gcc helloworld.cpp
```

今回も出力ファイル名を `-o` で名前を指定していないので、 a.out となった

```bash
$ ./a.out 
Hello World!
```
#ツリー描画

Cのソースをそのまま移植 + 出力を `printf()` から `cout` に変えただけのもの

```cpp:tree.cpp
#include <iostream>
using namespace std;

int main() {
    const char ASTER[] = "* ";
    const char SPACE[] = " ";
    const int  EVE   = 30;

    int sumAster = 0;
    int step = 0;
    int i,j;
    int trnk;

    while(sumAster <= EVE) {
        step ++;
        sumAster += step;
    }
    trnk = EVE - (sumAster - step);

    for (i = 1; i <= step; i++){
        if (i < step) {
            for (j = step; j > i; j--) cout << SPACE;
            for (j = 1; j <= i; j++)   cout << ASTER;
        } else {
            for (j = i - trnk; j >= 1; j--) cout << SPACE;
            for (j = 1; j <= trnk; j++)     cout << ASTER;
        }
	    cout << endl;
    }

    return 0;
}
```
実行

```bash
$ g++ tree.cpp -o tree.out
$ ./tree.out 
      * 
     * * 
    * * * 
   * * * * 
  * * * * * 
 * * * * * * 
    * * * 
```


#おわり
OpenSolarisのその後について

このエントリは[Solaris Advent Calendar 2016](http://qiita.com/advent-calendar/2016/solaris)の二日目のエントリです。

## OpenSolarisのその後
2005年1月、サン・マイクロシステムズ社はOSSとしてOpenSolarisプロジェクトを発足しました。
そして、様々な成果物を生み出しつつも、残念ながら2010年1月にサン・マイクロシステムズ社がオラクル社に買収され、OpenSolarisプロジェクトは終息しました。
ですが、OpenSolarisプロジェクトから派生した様々な成果物は現在も活動を継続しています。

## illumosとは
OpenSolarisプロジェクトから派生した成果物の中で重要な位置を占めるのがカーネルのフォークである[illumos](http://wiki.illumos.org/display/illumos/illumos+Home)です。
OpenSolarisのカーネルは歴史的経緯から一部にソースコードが公開されていないバイナリが使われていました。
illumosはこれらを完全なオープンスソースにする目的で開発されました。
現在では、OpenSolaris由来のZFSやDTrace、Zoneなどの機能の他にKVMやLinux Branded ZoneなどSolaris 11にはない独自の機能も備えています。
ちなみにillumosの先頭のiは必ず小文字で表記されます。これは特定のフォントではIとLの区別が付きづらいためです。

## ディストリビューション
illumosの主要なディストリビューションは[こちら](http://wiki.illumos.org/display/illumos/Distributions)から参照できます。
個々の詳細な内容は割愛しますが、汎用ディストリビューションの[OpenIndiana](https://www.openindiana.org/)やサーバー用途の[OmniOS](https://omnios.omniti.com/)、クラウド基盤向けの[SmartOS](https://www.joyent.com/smartos)、ストレージ・アプライアンスの[NexentaStor](https://community.nexenta.com/s/)など様々なディストリビューションが存在します。
中にはSPARCサーバ向けのバイナリを提供しているものもありますので、もしご自宅にSPARCサーバがある方は是非試してみてください。

## ZFSについて
また、FreeBSDやLinuxでも使われるようになっており注目度の高いZFSですが、現在は[OpenZFS](http://open-zfs.org/wiki/Main_Page)という形で開発が継続されています。[^1]
これは様々なプラットフォームで使われているZFSの開発を共有化する目的で発足されました。
また、毎年9月頃にOpenZFS Developer Summitが開催されています。
セッションの様子などは[こちら](http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2016)で閲覧できますので、ご興味があれば是非ご覧ください。

## まとめ
以上、簡単ですがOpenSolarisプロジェクトのその後を紹介させて頂きました。
是非一度触ってみて頂ければと思います。


[^1]: Oracle Solaris 11で使用されているZFSはOracle内部で開発されています。
LinuxサーバーをNew Relicで監視する

advent calendar2日目です。先週自分のサーバーにいれたサーバーの状態監視ツールを紹介します。
サクッとセットアップできて便利です。
5分くらいで終わります。

## 環境
CentOS6
[New Relic](https://newrelic.com/)

## セッティング
### タブからInfrastructureを選択

![スクリーンショット 2016-11-26 15.37.15.png](https://qiita-image-store.s3.amazonaws.com/0/95469/7e6c071a-3473-41b0-1845-9a64dcf77138.png)


### Linuxを選択



![スクリーンショット 2016-11-27 0.57.03.png](https://qiita-image-store.s3.amazonaws.com/0/95469/8c2fcb7a-c8e5-dc57-89aa-c48debfe9736.png)

### 出てきたコマンド実行

```bash

$ echo "license_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" | sudo tee -a /etc/newrelic-infra.yml

# Amazon Linux, CentOS 6, RHEL 6
printf "[newrelic-infra]\nname=New Relic Infrastructure\nbaseurl=http://download.newrelic.com/infrastructure_agent/linux/yum/el/6/x86_64\nenable=1\ngpgcheck=0" | sudo tee -a /etc/yum.repos.d/newrelic-infra.repo


# CentOS 7, RHEL 7

printf "[newrelic-infra]\nname=New Relic Infrastructure\nbaseurl=http://download.newrelic.com/infrastructure_agent/linux/yum/el/7/x86_64\nenable=1\ngpgcheck=0" | sudo tee -a /etc/yum.repos.d/newrelic-infra.repo

yum -q makecache -y --disablerepo='*' --enablerepo='newrelic-infra'

sudo yum install newrelic-infra -y
```


### 「Show me my data」というボタンを押すとデータが見れる。

![スクリーンショット 2016-11-27 1.00.20.png](https://qiita-image-store.s3.amazonaws.com/0/95469/89eb6a48-279f-3e0c-c90b-040ea703200f.png)

## まとめ
めっちゃ簡単
rubyで生成したインスタンスを使いまわし(singleton)

一回生成したインスタンスを全体で使い回ししたい
具体的に言うと`Twitter::REST::Client`で、毎度生成するみたいなのはなんか不経済な気がする。
Java方面から来たので、Springならconfigクラスで`@Bean`にしてってなもんですが、そんな感じのことをやりたい。

# moduleを使ってみる

```ruby:twitter_holder.rb
# frozen_string_literal: true
module TwitterHolder
  def self.client
    @client ||= Twitter::REST::Client.new do |config|
      config.consumer_key        = ''
      config.consumer_secret     = ''
      config.access_token        = ''
      config.access_token_secret = ''
    end
  end
end

```

これで`TwitterHolder.cilent`で使う形にしてみた。

# singletonモジュールは使わないのか？

`include Singleton`したとしても、結局同じインスタンスが返される処理は自分で書く必要があるはず。
あと`TwitterHolder.instance.client`といった感じで、長い！
であればクラスメソッドでいいんじゃないかと思ったんですが、さて……
ClojureでDBを扱う

# 書くこと
ClojureとKormaを使ってDBアクセスする。

# Korma
https://github.com/korma/Korma
http://sqlkorma.com/
必要なことはここに全て書いてあるので、英語だけど読めば下の記事は読む必要がない。

# 前準備
Leiningenは入ってるものとする。
適当にプロジェクトを作ってdependenciesにkormaを追加しておく。
今回はRDBMSにMySQLを使用するので、MySQLのドライバもいれておく。

```sh:init.sh
lein new default app
cd app 
vim project.clj
```

```clojure:project.clj
(defproject app "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [
                 [org.clojure/clojure "1.6.0"]
                 [korma "0.4.3"]
                 [mysql/mysql-connector-java "5.1.38"]
                 ])

```


```sh:init.sh
lein test
```
テストはコケるものが用意されているので正常にコケる

# DBに接続する

```shell-session
vim src/app/core.clj
```

```clojure:src/app/core.clj
(ns app.core)

(use 'korma.db)
(use 'korma.core)

; DB接続を作成する
(defdb mydb
  (mysql 
    {
      :db "app_database"
;手元の環境ではSSL証明書はないので使わなようにしておく。
      :subname "//127.0.0.1:3306/app_database?useSSL=false"
      :user "app_database"
      :excess-timeout 1000 
      :idle-timeout 1000 
      :initial-pool-size 1 
      :minimum-pool-size 1 
      :maximum-pool-size 1
      :password "app_database"}))

; 使用するテーブルを呼び出しておく
(defentity app)

; 既存のテスト関数
(defn foo
  "I don't do a whole lot."
  [x]
  (println x "Hello, World!"))
```

テスト用のDBを作っておく。

```sql:init.sql
CREATE DATABASE app_database;
GRANT ALL ON *.* TO 'app_database'@'%' IDENTIFIED BY 'app_detabase'; 
USE app_database;
CREATE TABLE app ( id INT(10) AUTO_INCREMENT PRIMARY KEY , name VARCHAR(20) , integer_value INT (10) DEFAULT 0);
INSERT INTO app ( name , integer_value) VALUES ("name1" , 1) ;
INSERT INTO app ( name , integer_value) VALUES ("name2" , 2) ;
INSERT INTO app ( name , integer_value) VALUES ("name3" , 3) ;
```
# CRUD
特に衒いがなく直感的な使いやすい形でインターフェースが揃っている。

## SELECT
CRUDさえできればとりあえずのことはできる。
Seectは帰り値がArrayで帰ってくるのでわかりやすく便利。

```clojure:select.clj
(def select-result (select app (fields :id :name)))
; SELECT id , name FROM app;
(println 
  (:id (first select-result)))
(println 
  (:name (first select-result)))

; WHERE句をつけて実行する。
(def where-result (select app 
  (fields :id :name)
  (where (= :id 1))
    ))
(println 
  (:id (first where-result)))

; 集計関数を使う
(def sum-result (select app 
  (aggregate (sum :integer_value) :integer_value_sum)
    ))
(println 
  (:integer_value_sum (first sum-result)))
```

## INSERT

```clojure:insert.clj
(insert app 
  (values {
    :name "name4" 
    :integer_value 33 
    }))
```

## UPDATE

```clojure:update.clj
(def update-result (update app
  (where (or (= :id 1) (= :id 2) (= :id 3000))
  (set-fields {
    :name "updated_name"
    :integer_value "20"
  })))
(println update-result) 
; 変更行数として2が表示される。
; id=3000の物は計上されない
```

## DELETE
```clojure:delete.clj
(delete app
  (where (>= :id 3)))
```
Quartz ComposerでPNG書き出し

あれ。[クリエイティブコーディング Advent Calendar 2016](http://qiita.com/advent-calendar/2016/creative-coding)、誰も書かない…
流れを絶やさないために、不肖ながら2連投します！

# Quartz Composerはもっと評価されるべき
![Quartz_Composer_Multiplexer.png](https://qiita-image-store.s3.amazonaws.com/0/13971/b7f61a7d-b5cc-4183-8a2c-e62a8f8acdf8.png)

長いこと開発止まってるけどね…
Mac買ったら誰でも使える謹製のVisual Programming環境！
[鹿野先生の未来派図画工作](http://www.zugakousaku.com)を見たら、もう感動するじゃないですか。
Quartz.framework経由でSwiftと連携できるし、常々もっと評価されても良いと思ってます。

# Quartz Composerの意外な弱点
多種多様なパッチがあるのに、Creative Coding系として致命的なのが「**静止画書き出し**」パッチが無いこと。
動画は「**Quick Time形式でのエクスポート**」があるので何とかなるものの、静止画出せないって…
静止画が出せれば、他との連携やFFmpegでの再加工など、いろいろ出来るのに。

# PNG書き出しサンプル
探したら、[Developer Library](https://developer.apple.com/library/content/samplecode/ImageExporter/Introduction/Intro.html#//apple_ref/doc/uid/DTS40009329-Intro-DontLinkElementID_2)にサンプルコードがありました。

でも、よく見ると…
> Last Revision:	Version 1.0, 2009-10-27
> Build Requirements:	Xcode 3.2 or later, Mac OS X v10.6 or later
> Runtime Requirements:	Mac OS X v10.6 or later

古すぎ。
案の定、El Capitan(10.6)な環境でもビルド失敗。

## 近代化！
ということで、Xcode 7.1 on MacOS 10.11でビルドできるように直しました:) → [Image2PNG@GitHub](https://github.com/szk-engineering/Image2PNG)

# まとめ
いろいろ書いた割に、サンプルコード直しただけですが、
誰かの役に立てば嬉しいです。

書き直すきっかけだった案件(定点観測+リアルタイムエフェクトみたいなもの)では、
2ヶ月間稼働し続けてもノートラブルで、画像加工と微調整に強いQuartz Composerの強みを活かしつつ、
最終的にはなかなかの規模の作品ができて良かったです。
AngularJS1.x系で子Componentから親Componentへパラメーター付きのイベント通知を発行する


近頃久しぶりに仕事でAngularJSの1.x系を使っています。
個人的には別物になってしまったAngular2よりかなりしっくりくるので今後も業務系アプリには使ってもいいかな、なんていうところで。

## scopeの`$broadcast`、`$emit`は使わない
scopeの`$broadcast`、`$emit`は手軽でとっても便利ですが、イベント名が重複してどこかで予期せぬ処理が走っちゃったり。引き継ぎが困難だったり。とにかく数えられない程の問題点が発生します。
（TypeScriptでイベント名や引数を管理すればある程度の軽減は可能。）

いろんな方法あるとは思いますが、私の場合はシンプルにComponentの属性としてイベント（のようなもの）を定義しそれを呼び出し元のControllerで受け取るという方法を取ります。

ざっくりこんなイメージ

`<child on-change="$ctrl.change($value)"></input-date>`

この場合パラメーターをどう受け渡すかという問題があります。
これがまたググっても意外と出てこなかったので、`ng-change`の実装部分を覗いて理解しました。

### 例
子Component上のinputへ文字が入力されるタイミングで、親Componentに都度変更内容を通知したい場合

```parent.ts
class Parent {
	static $inject = []
	constructor() {}
	
	private change($value: string) {
		// 子Componentのinputに入力された値が出力される
		console.log($value)
	}
}

angular.module('App').component('parent', {
	controller: Parent,
	bindings: {},
	template: '<child on-change="$ctrl.change($value)"><child>'
})

```

```child.ts
class Child {
	private value: string
	// こいつが今回のキモ。引数にオブジェクト渡しておくと 
	// on-change="$ctrl.change($value)" というふうにプロパティを指定して受け渡すことができる。
	private onChange: (param: {$value: string})=> void

	static $inject = []
	constructor() {}
	
	private change() {
		// 通知する
		this.onChange({$value: this.value})
	}
}

angular.module('App').component('child', {
	controller: Child,
	bindings: {
		onChange: '&'
	},
	template: '<input ng-model="$ctrl.value" ng-change="$ctrl.change()"><input>'
})

```

この例はとってもシンプルですがいろいろなケースで使用できます。
`$broadcast`や`$emit`よりグッと疎結合さが増しますね。最高。

例がざっくり過ぎるせいで`value`自体を`=`で受け渡してしまえばええやん、と思う方もいるかもしれませんが、そういう方は`親Componentから受け渡した値を子Componentで編集させるが、OKボタンが押させた場合のみ親Componentへ編集内容を反映する`なんていうパターンを考えてみてください。
Kernelの設定をミスしたことに気が付かずOSが起動しなくなった時の復旧方法

/etc/sysctl.confなどでkernelパラメータの設定を行いますが
やってはいけない設定をやってしまった時の復旧方法をメモ


やってしまったこと
/etc/sysctl.confに
vm.overcommit_ratio = 0
を設定し再起動したところ、OS起動時に下記エラーが出て起動しなくなってしまった。
init: Temporary process spawn error: Cannot allocate memory


復旧方法
1.サーバを電源OFFからの電源ON
2.起動時の「Press any key to ・・・」の画面で[ESC]キー押下
3.OS（CentOSなり、Redhat）を選択して[e]キーを押下
4.「kernel ・・・・」行にカーソルを合わせて[e]キーを押下
5.起動オプションを設定する。変更点は２つ！
 ・行末に init=/bin/sh を追加する
 ・[左矢印]キーで起動オプションの先頭付近にある ro を rw に変更する。
6.[Enter]キーで押すことでひとつ前の画面に戻る
7.[b]キー押下でboot
これでログインできるようになるので問題の箇所を修正して再起動すれば復旧するはず

補足
5のところで行末にsingleでシングルモードで起動することができるが、それでも今回の事象は復旧できなかった。
さらに一歩突っ込んで復旧するときはこれで復旧させる。
RubicでGR-CITRUSのmrubyプログラミング事始め２[MP3編]

[前回](http://qiita.com/shimo_cchi/items/7e4ff745cd68d703b27f)、開発環境を整えたのでこれから簡単な実際にモノづくりをしてみます。
お題はインターネット鳩時計みたいなものを作ることを目指します。
今後の流れは以下のように進んでいこうかなと。

1.　WA-MIKANを使ってSDカードにあるMP3データを鳴らしてみます。
2.　WA-MIKANを使ってUDP通信を行い、NTPから時刻(Unix-Time)をとる処理を行います。
3.　mrbgemsの入れて（めんどい）、mruby-timeを入れて、NTPから取ったUnix-Timeを時刻に変換する処理をします。
4.　今までのことを組み合わせて、1時間ごとにしゃべる時計を作ります。

ということで、今回は１を行います。

#今回つかうもの

+ GR-CITRUS
+ WA-MIKAN
+ MicroSDカード
+ 圧電素子
+ ブレッドボード
+ ブレッドボード・ジャンパーコード（オス－ワニグチ）×適当 

#GR-CITRUSのファームウェアを更新する。
MP3の再生をしたいので最新のファームウェアに更新します。
以下から、binファイルをダウンロードして下さい。
https://github.com/wakayamarb/wrbb-v2lib-firm/blob/master/firmware_develop/citrus_sketch.bin

そののち、CITRUSをPCにつけて、CITRUSのリセットボタンを押してください
![PICT0026.JPG](https://qiita-image-store.s3.amazonaws.com/0/151653/1d940586-d6f5-856c-a86d-45c4f1a3b625.jpeg)

USBファイルとして認識されるので、その中にダウンロードしたcitrus_sketch.binをコピーするだけでOKです。コピー後、CITRUSのLEDが点滅します。点滅が終わり点灯に変わったら書き換え終了です。

#MicroSDにMP3データを入れる
まず、MicroSDカードの中に適当にMP3ファイルを入れておきます。
ここでは[魔王魂](http://maoudamashii.jokersounds.com/)さんのサイトから適当に拝借したデータを3つ　

+ 「1.mp3」「2.mp3」「3.mp3」

という名前で、保存しておきました。

#WA-MIKANとGR-CITRUSをくっつける。
MicroSDカードをWA-MIKANに指してから、GR-CITRUSをWA-MIKANにくっつけます。
指す向きは写真のようにしてください。その後、ブレッドボード指して固定します。真ん中に渡るようにして指してください。
![PICT0025.JPG](https://qiita-image-store.s3.amazonaws.com/0/151653/6e6b99e9-6ce4-a9a2-3120-a7fc960a0d7d.jpeg)

#圧電素子をつなげる
[圧電素子](http://www.tdk.co.jp/techmag/knowledge/200803u/)とは圧力を加えると電圧が発生する素材です。安価で音を出すのに都合がよく、手軽に手に入ります。多分、いらなくなったオモチャとか分解すると出てくると思います。うちも漁ったら以下のようなものが出てきました。
![PICT0027.jpg](https://qiita-image-store.s3.amazonaws.com/0/151653/8f3c1400-1542-4713-48af-410521f2fc25.jpeg)
真ん中がプラスで、外側がマイナスです。ブレッドボード・ジャンパーコード（オス－ワニグチ）を使ってプラスをCITRUSの０番ピン、マイナスをGNDにつなげます。
![PICT0031.JPG](https://qiita-image-store.s3.amazonaws.com/0/151653/1fb85eca-97bc-b016-ae1a-16302e1e070c.jpeg)


#Rubicに書き込み
非常に簡単です。

```rb:main.mrb
#!mruby
Usb = Serial.new(0)

if( System.useMP3(3,4) == 0)then
   Usb.println "MP3 can't use."
   System.exit() 
end

l = ["1.mp3","2.mp3","3.mp3"]

l.each do |f|
    Usb.println f
    Usb.print MP3.play f
end
```

実行すると音が再生されます。これは便利！

[次回、ＵＤＰ接続編へ](http://qiita.com/shimo_cchi/items/20b629ea141349f5c86d)
SolrのCommitのタイミングと更新速度の違い

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


# Commitとは
Solrのcommitとは、

* 更新したインデックスを検索可能な状態にする(新しいSearcherを開く)
* インデックスをディスクに書き出す

という処理です。
[公式ドキュメント](https://cwiki.apache.org/confluence/display/solr/UpdateHandlers+in+SolrConfig)にも記載がある通り、頻繁にcommitするとパフォーマンスが悪くなります。
そこで、commitの発生回数と更新速度の違いを調査したいと思います。


# 調査に使ったインデックス
~~後ほどgitに上げます・・・！~~

20161204追記
[git](https://github.com/tkondo1223/solr-advent-calender2016/tree/master/commit)にインデックスのサンプルデータと一緒に置きました。


# Solrのバージョン
5.2.1を使用しています。

# 調査したパターン
インデックスが0件の状態から、
1度の更新リクエストで1万件のデータを更新しました。
これを100回、計100万件を更新します。
この時に、

1. 毎回 commit=true
2. 毎回 commit=falseして、最後に1度だけcommit=true

というようにcommitの発生タイミングを制御しました。
今回は諸事情から、solrconfig.xmlの設定でAuto Commitを15秒に1度に設定しディスクへ書き出しをさせます。
そのさいにopenSearhcerはfalseで設定しています。


# 結果と考察
以下のようになりました。

|            |  処理時間(秒)|
|:-----------|------------:|
|    パターン1|          196|
|    パターン2|          157|

やはり毎回commitする方法に対して、最後に1度だけcommitするパターン2の方が高速でした。
実際の運用環境では並列で更新リクエストをしたり、定期で走るバッチ更新や即時反映させたいリアルタイムのある更新リクエストなどもある場合、パフォーマンスの観点からは毎回commit=trueにするのはあまり良い方法では無いかも知れません。
一方で最後に一度だけcommitさせる方法は検索結果への反映が遅れてしまうという欠点もあるため、auto commitを上手く使いたいところです。

# まとめ
commitの頻度を減らすことでインデキシングが高速になることが計測から分かりました。
次回はSoftCommitについて触れたいと思います。