OmniAICreator/Qiita-1.07M huggingface dataset:
今年使って便利だったカスタム関数

今年、実際に使って便利だったカスタム関数を実例元にご紹介できればと思い、参加しました。
紹介するカスタム関数は今年作られたものでもなく、以前からあるものなんですが...
何卒お手柔らかにお願いします。

###やりたいこと

ある期間の受注データを検索し、以下のような分析結果を出したい。

- 受注の全件数
- 明細の商品点数
- 平均購入点数と最大購入点数
- 購入点数分布 件数と比率
- 平均購入額と最高購入額
- 購入金額分布 件数と比率

今までは検索した受注データをExcel出力し、Excelでフィルターやらピボットやらで、上記のような内容をせっせと毎回分析しておったようでした。
そりゃめんどいわな、さくっと分析したいわなー、と。
じゃあVBAでやりゃーいいじゃん [^1]というご意見もあるかと思いますが、今回は頑なにFileMakerで。

###やったこと
分析したい受注データを絞り込んだ状態からスタートです。

- 現在絞り込んでいる受注データの注文番号を改行区切りテキストで取得。
- 分析に必要な値を改行区切りテキストで取得。[GetNthRecordSet関数](http://www.briandunning.com/cf/439)
- 取得した値を改行以外の記号 **｜区切り** で連結。[ConcateList関数](http://www.fmpro.jp/fmi/xsl/plugin/cf.xsl?SearchKeyword=ConcateList&-sortfield.1=FunctionName&-sortorder.1=ascend&-skip=0)
- 具材は揃った、さあ分析だ。[GetKeyLine関数](http://www.fmpro.jp/fmi/xsl/plugin/cf.xsl?SearchKeyword=GetKeyLine&-sortfield.1=FunctionName&-sortorder.1=ascend&-skip=0)をさらにカスタムしました。

それがこちら↓

``` 
GetKeyNumLine ( Data; Key; KeyNum; Cnt; Value )

引数：
Data:改行区切りデータ
Key:キーワード文字
KeyNum:「|」で区切った項目左から何番目か
Cnt:1または""。どちらでも動作する
Data:""


Let ( [
Cnt = If ( Cnt="";1; Cnt );
Data = If ( Right ( Data; 1 ) ≠ "¶"; Data & "¶"; Data );
Max = PatternCount ( Data ; "¶");
Line = MiddleValues ( Data ; Cnt ; 1 )
];

If (
    Cnt > Max;
    Value; 
    GetKeyNumLine ( Data; Key; KeyNum; Cnt+1; Value & 
     If ( PatternCount( GetValue(Substitute(Line;"|";"¶");KeyNum);Key ) = 0;
        "";
        Line )
        )
   )
)
```

GetKeyLine関数は、先頭列の値に指定した引数の値があれば抜き出す、という関数です。

`＄hogelist` という変数に下記のような値が入っていたとします。

```

111|aaa|hoge
222|bbb|hooge
333|aaa|hoge
222|ddd|hoge

```

`GetKeyLine( $hogelist: "2"; 1; "" )` の実行結果は以下のようになります。

```

222|bbb|hooge
222|ddd|hoge

```

GetKeyNumLine関数は、**n番目の列** 引数を追加して、先頭以外の｜で区切った列の値も使えるように拡張しました。
ちなみにこれらの関数で抜き出される値は前方一致で判断され、数値で「1」で抜き出そうとすると、「10」の位の値まで引き連れてくるのでご注意を。

###問題点
ご覧の通り、再帰しまくりのカスタム関数を使いまくっております。前日の記事にもあるとおり、再帰処理には上限回数があります。
しかも、分析対象のレコード件数が多くなればなるほど、処理が返ってこなくなり、最終的にFileMakerが固まってしまいます。
再帰の上限回数ギリギリで、カスタム関数の呼び出しをLoopで実行などして、現状は凌いでいます。
分析する対象範囲がそこまで膨大ではないため、今のところはこれで必要十分かなとしてます。（言い訳？）

###おまけ
今回使用したカスタム関数を紹介しているサイト

http://www.fmpro.jp/fmi/xsl/plugin/cf_index.xsl
大体そろってるので、ここからさらにカスタム関数をカスタムしたり、
今は標準機能で賄えるものもあったりしますね。

http://www.briandunning.com/filemaker-custom-functions/
英語サイトでいろんな方がいろんな書き方であげてらっしゃるので、
キーワード検索で絞り込んだりして目当てのものを探してます。

カスタム関数Loverとか言っときながら、実はあまりカスタム関数を一から自作したことはありません。
こんなのカスタム関数でできそうだなぁって思った時は、まず探してみる。そして大概見つかります。みんな考えること同じなのねと。
どこかの誰かも同じものを作ってて、親切にもネットにあげてくれてるもんなら、遠慮なく使わせていただこうと。

###もひとつおまけ
[SetVariable関数](http://www.briandunning.com/cf/1333) を最近多用しています。なんでもっと早く知らなかったのか！と過去の己に申したいぐらい。まだ構想段階ですが諦めていたあんなこともこんなこともできそうだなーと。また機会があれば、実用例として記事[^2]にできたらいいなぁと。

今回初めてこういった記事を書きました。やり方に関しては、別のいい方法もあるようにも思いますし、何が最善かは環境やその時々に応じて変わりゆくものですし、そういった変化に柔軟に対応しやすいのはFileMakerの強みかなーと思ったりします。

[^1]: 今後改修した場合のファイルの配布や、端末ごとでの管理が煩雑なので。
[^2]: もし25日までにできそうなら記事にします！
Amazon Auroraの障害シミュレーションとバッファキャッシュの維持（ウォームアップ）の関係について確かめてみた

以前書いた、

 * **[Amazon Auroraのレプリカとバッファキャッシュのウォームアップの関係について確かめてみた](https://qiita.com/hmatsu47/items/01b9de19106293ea2539)**

の続きです。

# 1. 確認する事項

AWS Aurora（MySQL互換）では、SQL（コマンド）で障害をシミュレートできますが、

 * プライマリインスタンス（Writer）のみ
 * プライマリ／レプリカインスタンスでクラスタを組んでいるときのプライマリ（Writer）側
 * プライマリ／レプリカインスタンスでクラスタを組んでいるときのレプリカ（Reader）側

で、

 * インスタンス障害（`ALTER SYSTEM CRASH INSTANCE`）
 * ディスパッチャー障害（`ALTER SYSTEM CRASH DISPATCHER`）
 * ノード障害（`ALTER SYSTEM CRASH NODE`）
 * 1分間／100%のディスク障害（`ALTER SYSTEM SIMULATE 100 PERCENT DISK FAILURE FOR INTERVAL 1 MINUTE`）
 * 1分間／100%のレプリカ障害（`ALTER SYSTEM SIMULATE 100 PERCENT READ REPLICA FAILURE TO ALL FOR INTERVAL 1 MINUTE`）※クラスタ構成時のみ

を疑似的に発生させて、各インスタンスのバッファキャッシュが維持またはウォームアップされるかを確認します。

なお、利用するDB・テーブル・データは[前回](https://qiita.com/hmatsu47/items/01b9de19106293ea2539)のものをそのまま利用します。

※AWSのサイト（以下のページ）に以前あったはずの、障害シミュレーションコマンドのリファレンスが、なぜか見当たらないですね…。

 * **[Amazon Aurora DB クラスターの管理](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Managing.html)（
AWS Documentation RDS ユーザーガイド）**

また、以下の記事で書かれた内容とは、実際の挙動が変わっているところがあるようです（フェイルオーバーしません）。

 * **[Amazon Auroraの障害テストを試してみた。](https://dev.classmethod.jp/cloud/aws/recovery-test-aurora/)（Developers.IO／きうちさん）**

こちらの記事にも「フェイルオーバーしない」旨、記されていますね。

 * **[Amazon Auroraの耐障害性を検証してみました](https://engineer.muragon.com/entry/10.html)（ムラウチドットコム エンジニアブログ）**

# 2. 結果

「○」は維持（ウォームアップ）される／「×」はクリアされることを示します。

## 2-1. プライマリインスタンス（Writer）のみで疑似障害

| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|:--|:--:|:--:|
| インスタンス障害 | ○ | - |
| ディスパッチャー障害 | ○ | - |
| ノード障害 | ○ | - |
| ディスク障害 | ○ | - |

## 2-2. クラスタを組んでいるときのプライマリ（Writer）側疑似障害

| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|:--|:--:|:--:|
| インスタンス障害 | ○ | × |
| ディスパッチャー障害 | ○ | × |
| ノード障害 | ○ | × |
| ディスク障害 | ○ | ○ |
| レプリカ障害 | ○ | ○ |

## 2-3. クラスタを組んでいるときのレプリカ（Reader）側疑似障害

| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|:--|:--:|:--:|
| インスタンス障害 | ○ | ○ |
| ディスパッチャー障害 | ○ | ○ |
| ノード障害 | ○ | ○ |
| ディスク障害 | ○ | ○ |
| レプリカ障害 | ○ | ○ |

プライマリインスタンス（Writer）側障害でインスタンス／ディスパッチャー／ノード障害が発生した場合、レプリカインスタンス（Reader）が再起動して一旦接続が切れ、再接続した時点ではバッファキャッシュが残っていませんでした。

それ以外では、プライマリインスタンス（Writer）が再起動する場合でも、バッファキャッシュは維持されました。
ノード障害の時はクリアされると思ったのですが（「キャッシュ消えるよ」という説明が書かれているようですし）、インスタンス／ディスパッチャー障害を個別に発生させるのと同じ結果になりました。

※ログは省略します。

# 3. まとめ

やはり、レプリカインスタンス（Reader）側のバッファキャッシュのウォームアップについては注意が必要なようです。

なお、シミュレーションではなく実際の障害では、DBサービスだけでなくインスタンスのOSレベルの障害が発生する可能性もあるため、先に示したものとは違う結果になる可能性があります。

そのため、この結果は参考程度に見ておいてください。

※勝手な想像では、リアルなノード障害は以下のようになると思っています。

| 障害パターン | プライマリ（Writer）の挙動 | レプリカ（Reader）の挙動 |
|:--|:--|:--|
| プライマリのみ存在 | 再作成される間停止し、再作成後はクリアされて起動 | 　　　　　　　- |
| クラスタ構成でプライマリ障害 | レプリカからのフェイルオーバーが発生し、クリアされる | 再作成される間停止し、再作成後はクリアされて起動 |
| クラスタ構成でレプリカ障害 | 維持される | 再作成される間停止し、再作成後はクリアされて起動 |

2番目のケースではプライマリインスタンス（Writer）側のバッファキャッシュが維持されそうな気もしますが、レプリカインスタンス（Reader）にREDOログ（※）／メタデータが送られる前または送られる途中でプライマリインスタンス（Writer）が停止するとストレージ上のデータとの間で不整合が生じるため、安全を考慮してクリアされるのではないかと想像しています。

（※）ストレージに記録されるものではなく、レプリカインスタンスのバッファキャッシュに更新データを反映するためにプライマリインスタンスから送信されるもののことです。

---

 * **[Qiitaに投稿したAmazon Aurora関連記事](http://hmatsu47.hatenablog.com/aurora)**
Seleniumデザインパターン＆ベストプラクティスで紹介されているパターン紹介

色々なコードの書き方に「あぁ、これは〇〇パターンだな」って思えるとそれがアンチパターンだとしてもなんかカッコいいですよね。

また、他の人と話すときに「この部分は〇〇パターンを適応した方がよいのでは？」みたいな話ができると齟齬が少なくなりそうです。

Seleniumデザインパターン＆ベストプラクティスという本を読んで、「とりあえずSelenium IDEで記録するか」という方法がレコード＆プレイバックパターンと紹介されていてこのことを強く思いました。

この本には自分があんまり馴染みのなかったパターン名が紹介されていたので、ここで紹介したいと思います。

## Record and Playbackパターン

ユーザが通常おこなう活動を記録しておき、それをテストツールを通して再生できるようにするというパターン。

### 利点

* すぐ作成できる
* プログラミング言語が書けなくてもテストを作成できる

### 欠点
* 吐き出されるコードの可読性が低い
* 仕様変更に脆い
* テストとデータが密結合
* コードベースのメンテナンスは至極悪い

## スパゲッティパターン
テストの実行順序に依存し、各テストがプライベートなコンポーネントを共有し独立していない。1つのテストケースが1つのテストか、絡み合った複数のテストを表しているのかわからないようなアーキテクチャや設計が認識できないパターン。

### 利点
* すぐに取り掛かれる
* コードベースが小さくなる（他のテストの処理に依存するため、重複する処理を省略できる）

### 欠点
* 密結合している
* 順序をランダムにできない
* テストを並列に実行できない
* 失敗の発見が遅れる（1テストケースで複数のテストをおこなっているため）
* テストの可否が他のテストに影響する

## DRYテストパターン
DRY原則（Don't Repeat Yourself）を取り入れたパターン。
重複したコードを取り除くだけでなく、重複したテスト目標も取り除く。

### 利点
* 重複を取り除く
* テストがモジュール化される
* 保守性が高くなる

### 欠点
* プロジェクト構造が複雑になる
* 絶えず管理する必要がある
* プログラミングスキルが要求される

## Hermeticテストパターン
スパゲッティパターンの対極で、各テストが完全に独立しているパターン。
他のテストや制御できないサードパーティ製サービスへの依存も排除する。

### 利点
* クリーンな状態で開始できる
* テストの可否が他のテストに影響しない
* ランダム実行できる
* 並列実行できる

### 欠点
* 事前の設計が必要になる
* 実行時間が長くなる（各テストで環境をセットアップするため）
* 使用リソースが増加する


## Black Hole Proxyパターン
サードパーティにまつわる不確実性を取り除いてテストを安定させるパターン。

### 利点
* 速度が改善される
* テストが安定する

### 欠点
* レイアウトが壊れる（SNSボタンなどに依存していた場合）
* サードパーティコンテンツのテストができない

## まとめ

本で紹介されていたパターンを少し紹介しました。
本で紹介された利点・欠点をコードなしに紹介しているためよくわからない箇所もあるかと思いますが気になりましたら続きは本で📚

なぜ、私がこの内容にしたかというとレコード＆プレイバックやスパゲッティコードにすらパターンという接尾語を与えると利点と欠点があり、どのパターンで進めていくのか考慮するときの選択肢としての１つとしてなり得るのだなと感嘆したからです。

本の中ではスパゲッティパターンから徐々にHermeticテストパターンに書き換えていく流れや他の様々なパターンが紹介されています。
データ駆動テストや振る舞い駆動テスト（BDD）などを適用してテストスイートの育て方が書かれていて面白かったのですが、一番印象に残ったのは名前を付けることの大切さです。
facebookのソーシャルプラグインを削る時に「Black Hole Proxyパターンを適用しましょう」で共通認識できればなんかイケてない？って感じで少し上がりますよねｗ

あなたの無意識に行っているコードやテストもどこかに名前が与えられていないパターンが存在するかもしれませんよ。
プロ生ちゃん3Dモデルの表情を座標値で操作

#概要
プロ生ちゃん3Dモデル
http://3d.nicovideo.jp/works/td8608
の表情を以下の手法で操作します。
http://udasankoubou.blogspot.jp/2017/07/undebuggable-rittai-chan.html
※超絶簡易版として実装します。

![bandicam-2017-12-05-00-24-56-519.gif](https://qiita-image-store.s3.amazonaws.com/0/183870/18f4e34f-6ffa-1030-1874-d194abdf4848.gif)
＞＜がちょっと変ですけど組み合わせ吟味すれば少し良くなるハズ……

#スクリプト
```csharp
using UnityEngine;

public class ChangeFace : MonoBehaviour
{
    [SerializeField]
    SkinnedMeshRenderer skinn;

    [SerializeField]
    int up;

    [SerializeField]
    int down;

    [SerializeField]
    int left;

    [SerializeField]
    int right;

    void Update()
    {
        Vector2 stick = OVRInput.Get(OVRInput.RawAxis2D.RThumbstick) * 100;

        skinn.SetBlendShapeWeight(up, stick.y);
        if (stick.y < 0)
        {
            skinn.SetBlendShapeWeight(down, -stick.y);
        }

        skinn.SetBlendShapeWeight(right, stick.x);
        if (stick.x < 0)
        {
            skinn.SetBlendShapeWeight(left, -stick.x);
        }
    }
}
```

#設定
プロ生ちゃんの表情設定はここにまとまってるみたいです。
ここで値を調整しながら上下左右に割り当てるindex(上から順に0から気合で数える。)を決めます。
「まばたき」と「笑い」のように一緒にすると変になる組み合わせは上下または左右に割り当てると操作時に自然です。
![00.png](https://qiita-image-store.s3.amazonaws.com/0/183870/07f5b7b3-1f02-c34a-7bcb-1f0a81929e44.png)

割り当てるindexが決まったら、SkinnにSkinnedMeshRendererが付いてるObjectを割り当て、上下左右にindexの値を設定します。
![01.png](https://qiita-image-store.s3.amazonaws.com/0/183870/c989dbb7-ad1a-49a4-78f9-014a191c6b1b.png)

※今回のスクリプトは1つで上下左右4つなので、目と眉と口で3つ付けると表情がはっきりします。
デザイナーがSQLを書けるようになったら、デザインフローが早くなった話

こんにちは！
リブセンスで[転職ナビ ネイティブアプリ](https://play.google.com/store/apps/details?id=jp.j_sen.job.jstaff_android&hl=ja)のデザイナーをしているmynと申します。
技術に関わるお話をするQiita Advent Calendar、去年から2回目の参加です。
これに参加すると、「お前は今年ちゃんと成長をしたのか？プログラミングも勉強したいな〜とか言っただけだったんじゃないのか！？」と、真正面から問い詰められている気持ちになりますね。

でも大丈夫。一生懸命思い出せば何かはあるはず。そう、SQLとか！

#リブセンスのSQL文化について
リブセンスは[営業さんまでSQLを書く文化のある会社](https://www.slideshare.net/livesense/150225-sql-foreveryone-45695818)です。

一般的なところはよく知らないのですが、「SQL書く人/全社員」人口比の高さははなかなか珍しいようです。というのも、弊社には[Livesense Analyticsという独自の分析基盤](https://speakerdeck.com/livesense/ribusensufalsedetafen-xi-ji-pan-falsequan-mao)があり、Access logsと顧客データを突き合わせて自由に分析できる環境なので、「これを使わない手はない！」という便利な環境がそういう文化を作ったのだと思われます。

こういった環境の中で、「デザイナーもSQL書けるようになっちゃいなよ！」という厳しくも温かい上司（エンジニア）の後押しを受け、一年ほど前に[SQL書き方ドリル](https://www.amazon.co.jp/%E6%94%B9%E8%A8%82%E7%AC%AC3%E7%89%88-%E3%81%99%E3%82%89%E3%81%99%E3%82%89%E3%81%A8%E6%89%8B%E3%81%8C%E5%8B%95%E3%81%8F%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%82%8B-SQL%E6%9B%B8%E3%81%8D%E6%96%B9%E3%83%89%E3%83%AA%E3%83%AB-PRESS-plus/dp/4774180661)を手に取ったのが始まりでした。

今日は、それから1年が経ち「デザイナーがSQLを書けるようになって良いことあったよ！」という事例をご紹介したいと思います。

#Case：転職ナビアプリの自己PR入力画面
<img width="300" alt="スクリーンショット 2017-12-04 18.44.59.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/84fa64b2-a52a-4233-c175-73fc5c035de2.png">
##課題「入力補助機能が２つある」
- テンプレート
- 4つの質問から自動作成（a.k.a. KCシステム）

##日々こんなことを思ってました
ここのデザインごちゃごちゃだわ〜。情報を整理してもっとシンプルにしたいわ〜。
でも、「なんかごちゃごちゃなんでシンプルにしたいっす〜！」でデザイン変えるわけにはいかん。だってプロだもん。。

##そんな中でのディレクター兼POとのやりとり

<img width="930" alt="Screen Shot 2017-12-05 at 00.05.47.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/8d5f78a4-d87a-3990-d027-3010eeedad31.png">


ここでいつもだったら・・・
<img width="908" alt="Screen Shot 2017-12-05 at 00.05.26.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/28b4a064-3744-e31f-4270-7eb77c65c877.png">


という流れが通常です。
##一歩前進してみる
<img width="900" alt="Screen Shot 2017-12-05 at 00.05.17.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/a801b38b-b808-bd97-b68c-d4485331d9d0.png">


という流れもわりとよくあります。
##ここで、わたしがSQLを叩けると
<img width="901" alt="Screen Shot 2017-12-05 at 00.06.27.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/395737c1-fca8-40c5-6390-8d760e4967fd.png">

という新しい潮流が生まれた！

##叩いた結果
KCシステムを使った人：テンプレートを使った人＝10:1
<img width="909" alt="Screen Shot 2017-12-05 at 00.08.26.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/82b81235-d218-a219-4528-bed4905b7c66.png">

双方に納得感のあるコミュニケーションが実現！


<img width="300" alt="Screen Shot 2017-12-05 at 00.09.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/116957/9ee3c780-d734-0408-2781-43b2bbcf6083.png">

デザインも機能を取捨選択したことにより訴求文言を増やし、より理解のしやすいバナー表示にすることができました。

#まとめ
SQLでやってることは簡単だし当たり前のことなんですが、これを<font color="Red">**自**</font>分で叩けるようになると日々のデザイン業務 、特に情報設計などの考える部分が早くなりました。

今まで定性的なところでしかデザインの根拠を作れず、そしてそれは伝えることがとても難しかったのですが、Livesense Analyticsを使えると情報設計やユーザー行動を定量的に検証でき、事実としてあるので人に説明しても納得感を醸成しやすいです。

また個人的には、これまでユーザーテストでしかユーザーの生の意見を集めることができなかったのですが、アクセスログからリアルなユーザー行動を抽出できることに改めて感動しました。

#おわりに
ここまでお付き合いいただき、ありがとうございました＼(^o^)／
末筆ですが、SQLを辛抱強く教えてくださるチーム内外のエンジニア・ディレクターのみなさん、今年も一年大変お世話になりました＆本当にありがとうございました。
来年も良いものを楽しく作れるプロダクティブな一年になりますように！
findの使い方色々

#はじめに
ファイルシステム検索に使用するfindコマンドのサンプル集。
個人的に現場で割とよく使う書き方を集めてみました。

#コマンド
ディレクトリ検索
`$find . -type d`
　→ディレクトリだけがヒットする。

ファイルのみ検索
`$find . -type f`

特定のファイル名検索
`$find . -name "*log*"`
　→"log"を含むファイル・ディレクトリがヒットする。

シンボリックリンク先も検索
`$find -L . -type d`
　→-Lがないと、シンボリックリンク先は辿ってくれない。

logファイル以外のファイルを検索
`$find . -type f  ! -name "*.log"`

logまたはtxtファイルを検索
`$find . -name "*.log" -o -name "*.txt"`

1～2階層先だけ表示
`$find . -maxdepth 3 ～`

find の結果をlsで表示
`$find . -name access_log | xargs ls -ld`

abc.logより古いファイルを削除
`$find . ! -newer abc.log | xargs rm`

本日日付から10日より前のファイルを検索する。
`$find . -type f -mtime +10`
→今日が1/14なら、1/3以前のファイルがひっかかる
　(1/4～1/13の１０日分は対象外）。

対象ディレクトリ配下のファイルをフルパス、かつ権限・オーナー込みで表示。
`$find / -exec ls -ld {} \;`
{}は検索したファイル名を指す。\;はコマンドの終了を指す。
「{}」と「\」の間にスペース要。
Excelを使ってプリンタインクの在庫を管理する

# 概要
Excelのワークシート関数を使って、簡単な在庫管理システムを作ってみます。

# やること
プリンタのインクの在庫を管理する

■ インクの種類
青, 赤, 黄, 黒

# 仕組み
インクを購入したり、インクを交換したりすると、在庫が変動します。
この在庫の変動を履歴として残します。

■ インク在庫変動履歴

|種類| イベント | 在庫 |日付|
|:--:|:--------|--------:|:--:|
|赤| 購入 | +1 |2017/10/07|
|青| 交換 | -1 |2017/11/23|
|黒| 交換 | -1 |2017/12/05|

この履歴によって在庫の増減が分かりますが、現在の在庫がいくつなのかは分かりません。
それは、最初の在庫がいくつだったのか、どこにも情報がないからです。
そこで、在庫変動履歴の最初に、初期在庫のデータを入れておきます。

■ インク在庫変動履歴（初期在庫数含む）

|種類| イベント | 在庫 |日付|
|:--:|:--------|--------:|:--:|
|青| 初期在庫 | +3 |-|
|赤| 初期在庫 | +1 |-|
|黄| 初期在庫 | +2 |-|
|黒| 初期在庫 | +4 |-|
|赤| 購入 | +1 |2017/10/07|
|青| 交換 | -1 |2017/11/23|
|黒| 交換 | -1 |2017/12/05|

これで、現在の在庫が分かる表が出来上がりました。
現在の在庫を表示する表は、以下でいいでしょう。

■ インク在庫

|種類| 在庫 |
|:--:|-----:|
|青| 2 |
|赤| 2 |
|黄| 2 |
|黒| 3 |

# 実装の検討
インク在庫が増減するたびに、インク在庫変動履歴を手で追加する事にします。
すると、プログラミングする必要があるのは一か所だけです。
それは、在庫変動履歴を初期在庫から全て合計する処理です。
この処理は、インクが一種類しかないなら、SUM関数を使って合計すればうまくいきます。
しかし、今回の例のように、複数の種類のインクがある場合、SUM関数ではうまくいきません。
SUM関数では、インクの種類に関わらず、全ての在庫変動を合計してしまうためです。
今回必要なのは、青インクなら青インクの変動履歴だけを、赤インクなら赤インクの変動履歴だけを合計する処理です。
Excelには、ちょうどぴったりのワークシート関数があります。

- SUMIF関数<br/>
指定された検索条件に一致するセルの範囲を合計します。<br/>
=SUMIF(範囲,検索条件,[合計範囲])

SUMIF関数を使って、インクの種類ごとに在庫変動履歴を全て足すことにします。

# 実装
まず、Excelシートに上述の表を作成します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/10723/bab94760-3f62-d021-9716-dc904d0a6cac.png)


インク在庫一覧の「在庫」列のセルには、以下のワークシート関数を記述します。

```text:SUMIF関数
=SUMIF(F4:F999,"青",H4:H999)  // 在庫一覧「青」
=SUMIF(F4:F999,"赤",H4:H999)  // 在庫一覧「赤」
=SUMIF(F4:F999,"黄",H4:H999)  // 在庫一覧「黄」
=SUMIF(F4:F999,"黒",H4:H999)  // 在庫一覧「黒」
```
SUMIF関数で参照する範囲は、現在の「在庫変動履歴」表よりずっと広く取っています。
それは、これからインクが増減するたびに「インク在庫変動履歴」に履歴が追加されるため、追加される履歴の範囲を見込んで、参照範囲を広くとったのです。

# テスト
では、インク在庫変動履歴に履歴を足してみましょう。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/10723/c2278477-c50c-fe85-ad37-af1429f74660.png)

インク在庫一覧の黄色の在庫数が増えている事が確認できます。



# 環境
Excel online
.NET Core を使って Windows と Mac でプロジェクト共有してみる


結論から言うと設定は何もいりませんでした。

## 開発環境

- Visual Studio 2017
- Visual Studio for Mac
- ASP.NET Core 2.0


## プロジェクト作成

今回は Mac からプロジェクトを作ります。Windows から作っても問題ないはずです。Web API を作ってみました。
プロジェクトの共有に GitHub を使うため、バージョンコントロールの設定にチェックを入れてあります。

[![https://gyazo.com/e1d13e91c58dbef5d216b19c735aae27](https://i.gyazo.com/e1d13e91c58dbef5d216b19c735aae27.png)](https://gyazo.com/e1d13e91c58dbef5d216b19c735aae27)

[![https://gyazo.com/e828d39e73780578bbd611c98faebc0c](https://i.gyazo.com/e828d39e73780578bbd611c98faebc0c.png)](https://gyazo.com/e828d39e73780578bbd611c98faebc0c)


## コントローラーのコード変更

HelloWorld! が返ってくるように ValuesController を修正します。

[![https://gyazo.com/ffa130e62ac40749e271c5b22641543c](https://i.gyazo.com/ffa130e62ac40749e271c5b22641543c.png)](https://gyazo.com/ffa130e62ac40749e271c5b22641543c)

```csharp
[Route("api/[controller]")]
public class ValuesController : Controller
{
    // GET api/values
    [HttpGet]
    public IEnumerable<string> Get()
    {
        return new string[] { "Hello", "World!" };
    }
}
```

## Mac の動作確認

ビルド→実行します。HelloWorld! が返ってきます。

[![https://gyazo.com/c9e2b912be8f3c0fc211acf5e4aebaca](https://i.gyazo.com/c9e2b912be8f3c0fc211acf5e4aebaca.png)](https://gyazo.com/c9e2b912be8f3c0fc211acf5e4aebaca)


## Windows の動作確認

Mac で作ったプロジェクトを開きます。

[![https://gyazo.com/464f06ca1411915bb6ba2f0537aeb85c](https://i.gyazo.com/464f06ca1411915bb6ba2f0537aeb85c.png)](https://gyazo.com/464f06ca1411915bb6ba2f0537aeb85c)

[![https://gyazo.com/69cdeffe456e9fa3b683d5053fb4918e](https://i.gyazo.com/69cdeffe456e9fa3b683d5053fb4918e.png)](https://gyazo.com/69cdeffe456e9fa3b683d5053fb4918e)

ビルド→実行します。HelloWorld! が返ってきます。これにて完了です！

[![https://gyazo.com/46e2dc6a823aac6f0a982a687c0e937a](https://i.gyazo.com/46e2dc6a823aac6f0a982a687c0e937a.png)](https://gyazo.com/46e2dc6a823aac6f0a982a687c0e937a)
enumerizeで設定しlocale対応した値に対して、ransackで検索するときのtipsメモ

### enumerizeで設定した値で検索を出来るようにしたい。
enumerizeで値を設定？したカラムに対して、ransackの検索をかけたい場合にベターなやり方を見つけたのでメモ

### ベターな方法見つける前

```
# model
# enumerizeがlocaleされている。
extend Enumerize
enumerize :account_type, in: { normal: 0, easy: 1, hard: 2, test: 3 },scope: true

# controller
@types = User.account_type.options
@types.map.with_index { |type, index| type[1] = index }

# view
<%= f.select :account_type_eq, @types %>
```
enumerizeで設定したaccount_typeの値の一覧を取得したい場合、`User.account_type.options`で呼び出せば、`[[ノーマル, normal],[イージー, easy],[ハード, hard]]`と多次元配列が取得できる。（値だけのリストを取りたいなら`.values`）
だいたい、enumerizeで設定している値は`config/lang/ja.yml`でlocaleされているので、上記のようなリストが取得される。

このままviewのf.selectに使っても、valueがlocaleされている値なので、検索がうまいこといかないので、locale前の値（1,2,3とかの数値）に変換する処理：`@types.map.with_index { |type, index| type[1] = index }`をいれて対応していた。

しかし、indexをリストのvalueに置き換えるのはきつい。もし万が一、enumerizeで設定している値が連続値でなかったら、この処理では破綻してしまう。


### ransackable_scopeで対応
なんかうまいことできないかな〜と思い、ググってたら…。
https://twitter.com/naturalhokke/status/762456397573349379

検索をカスタムできる[ransackable_scope](https://github.com/activerecord-hackery/ransack)を利用すれば、上のわけの分からない処理も消せるので、リファクタリング！

```
# model
extend Enumerize
enumerize :account_type, in: { normal: 0, easy: 1, hard: 2, test: 3 },scope: true

scope :search_by_type, -> (type) { where(type: type) }


# view
<%= f.label :search_by_type, 'タイプ：', class: 'col-md-2 control-label' %>
<%= f.select :search_by_type, User.type.options, {include_blank: true}, {class: 'form-control'} %>

```
これでcontrollerに書いていたリストのvalueの変換処理はなくなって、スッキリします！
enumerizeとransackはよく使うgemだけど、連携してて「あれ？これどうやるんだ？」と思ってたので備忘録
DB2でデッドロック発生の調査・対策ポイント

#はじめに
デッドロック発生時の調査ポイントについて、思いつくところを書いてみました。

#ロックの仕組みについて学ぶ
DB2特有のロックの動作を理解するため、まずは以下の資料を読むことをお勧めします。

DB2デザイン・ガイド: ロックの基礎【V9.7対応】
https://www.ibm.com/developerworks/jp/data/products/db2/design-guide/lock_v97.html

OracleとDB2、ロッキング・メカニズムはこれだけ違うhttp://www.atmarkit.co.jp/ait/articles/0410/06/news118.html

#DB2特有のデッドロック発生原因
Oracleとの最大の違いは、DB2は読み取り(SELECT)時にロックが発生しうることでしょう。
A・BテーブルをJOINしたSELECT(共有ロック)を行うトランザクション1と、B⇒Aテーブルの順にUPDATE(排他ロック)をかけるトランザクション2でデッドロックが発生する、なんてこともありうる（SELECT実行のトランザクションでデッドロックエラーが発生したときは、ん？と思ってしまったのだが）。

#デッドロック発生時の調査・改善検討ポイント
デッドロックが発生した際に見るべき箇所。

**(1)SELECT文の実行計画に問題がないか。**
　不必要な表スキャン（表ロック）を発生させるような効率の悪いSQLとなっていないか？
　表ロックが多いと、前述のようなデッドロックの発生確率が上がる。
　[対策]実行計画上、インデックスを使用していない箇所がある場合はインデックスを使用可能なようチューニングできないか、検討する。

**(2)LOCK関連のDB構成パラメータが適切か**
　DB構成パラメータLOCKLIST、MAXLOCKSが極端に小さな値で設定されていないか確認する。
　これらは行ロック情報を保持するメモリ領域だが、数値が小さいと、ロックエスカレーション（行⇒表ロックへの格上げ）が発生しデッドロックの可能性が高くなる。
　[対策]値が小さい場合は、数値を大きくできないか検討する。
　※ただし当パラメータはバージョンによってはAUTOMATIC(最適値に自動チューニング)されるので、AUTOMATIC設定であれば基本的にいじる必要はない。

**(3)分離レベルCSで、CUR_COMMITED=ONとなっているか。**
　分離レベルCSかつ、DB構成パラメータCUR_COMMITED=ON（参照時点でコミットされているデータを参照する）の設定の場合、ロック取得待ちを発生させることがない。
　DB2が当設定となっていれば、SELECTによる共有ロック起因でのデッドロックは発生しなくなる（はず！未検証なのでウラがとれたら記事修正します）。
　[対策]CUR_COMMITED=DISABLEDの場合、ONに変えることができないか検討する。
 
#その他対策案
思いつくのはこんなとこ？
1. SELECTの末尾にWITH URをつけて、ロック取得しないようにする。
　（ただし未コミットデータも参照してしまうので業務上問題ないか確認必要）
2. LOCK TABLE 表名 IN EXCLUSIVE MODE で、先に更新対象テーブルの排他ロックをときっちゃう。

# 雑感
インフラを触りやすい環境ならよいが、DB構成パラメータ変更はDB全体に効いてくるので変更を嫌がられる可能性あり。その場合は基本的にはSQL修正かインデックス追加などでチューニングしていくしかないかなぁ。
他にもいろいろありそうだけど、書くのに力尽きたので後日加筆します。。
delete, delete_all, destroy, destroy_allについて


ActiveRecordでよく使う４つの削除系インスタンスメソッド、delete, delete_all, destroy, destroy_all。
個人的に毎回使い分けが混乱してしまうので、それぞれの動作をまとめました。

## 前提
* Rails5系
* Ruby-2.4

モデル関連は以下のような感じを想定してまとめます。（RailsGuides参照）

```
class Author < ApplicationRecord
  has_many :books, dependent: :destroy
end
 
class Book < ApplicationRecord
  belongs_to :author
end
```

## destroy
削除を行う際に一番使うメソッド（だと思う）。
ActiveRecordを介して指定した条件のレコードを削除する。削除する際に、Modelに`dependent: :destroy`が設定されている関連がある場合、その関連も一緒に削除してくれる。

例えば、`Author.find(1).destroy`とすれば、一人のAuthorとそれに関連しているBook達を削除してくれる。
注意しないといけないのは、Modelに設定した`dependent: :destroy`。これがないと、Authorは削除されて、Booksだけが孤立してしまう状態になる。
稀にdependentを設定していないから、「あれ？関連付けが削除されない！！」ってあたふたするときが、個人的にあるw

#### 補足
あと関連付け設定には、`dependent: :destroy`のほかに、`dependent: :delete_all`ってのもある（has_one関連の場合は`dependent: :delete`）。
この場合、destroyを実行すると、ActiveRecordを介さないで直接SQLを実行して関連付けも削除します。

`:destroy`を設定した場合と`:delete_all`を設定した場合で、destroyを実行してログを見てみるとわかるが、前者はDELETEクエリが関連の数だけ実行されるが、後者だとDELETEクエリ１回だけ実行する。
つまり、後者の方が効率よく関連を削除できるというメリットがあるということ！

まだ自分はRails経験浅いのでわからないが、基本的なWebサービスとかでは`:delete_all`はあんまり使う機会無い気がする…。だいたい`dependent: :destroy`で事足りる気がする。


## delete
指定した条件のレコードをSQLを直接実行して削除する。つまり、ActiveRecordを介さない。（「DELETEクエリを直接実行するのがdelete」という感じで覚えておけば、destroy、deleteどっちだっけ？？ってことはなくなるかと。）

また関連付けられてるレコード削除しない。`dependent`が設定されていても関係なし。

個人的には、既にmodelでdependentで関連付けられてるけど、今回は関連付けは消したくない！って時に使う機会が多い気がする。

## destroy_all
例えば、こんな感じ

```
Author.find(1).books.destroy_all
```
これで、一人のAuthorに関連しているbookがActiveRecordを介してすべて削除される（Authorを削除するわけじゃない）。

ちなみに、以下のようなモデル関連付けだったとすると、booksの関連付けのcategoriesもコールバックが呼び出されて削除される。

```
class Author < ApplicationRecord
  has_many :books, dependent: :destroy
end
 
class Book < ApplicationRecord
  belongs_to :author
  has_one :categories, dependent: :destroy
end

class Category < ApplicationRecord
  belongs_to :book
end  
```

## delete_all
ここまで説明見ていただけたら察しがつくと思うが、

```
Author.find(1).books.delete_all
```
とすれば、一人のAuthorに関連付けられているbooksをすべてActiveRecordを介さないで削除してくれる。
この場合、`delete`と同様にbooksの関連付けなどの設定は無視する(deleteコールバックが呼ばれない)。

つまり、まとめて複数のbooksデータを削除する場合に、効率よく削除ができるということ。
個人的にはあまり使う機会に出会ってないのだけど、`delete`と同様で関連付けを無視してまとめて削除したい時に使うのが良いと思う。もしくは関連のみを削除する時とか？

## ココまで踏まえて注意する所
* 関連付けで削除するなら、modelにdependentの設定を忘れずに。
* 関連付けも削除するdestroy,destroy_allか、関連を無視して削除するdelete, delete_allか、よく考えてコード書きましょう！

これ系の記事はググる一杯出るので、なんでわざわさまとめたかって言うと、以前仕事で退会処理みたいな処理を作ったのだが、has_manyで関連付けがあるオブジェクトをdelete_allで削除するようにしてたのだが、その関連付け先のオブジェクトが削除できておらず、DBに取り残されてしまう事案を起こしてしまった…。
その関連付けは把握してたのだが、delete_allとdestroy_allの違いを把握してなかったために起こしてしまったミスだった。


# 参考URL
* [RailGuides - Active Record の関連付け (アソシエーション)](https://railsguides.jp/association_basics.html)

色々記事があるけど、公式ドキュメントが一番いい。
ハンズオン・レポート＠2017/12/3 IBM BMXUG 冬の大勉強会

## :flag_jp:自己紹介

>特技でDTMやってます。: [coconala](https://coconala.com/users/914436) / [SoundCloud](https://soundcloud.com/eiji-pon)

>執筆した本：[AIには到底、想起不可能！親父ギャグの玉手箱](https://www.amazon.co.jp/dp/B07B69442Q)

>趣味でアプリ開発やってました（過去形...）。:[Sound of Love lab.](http://sound-of-love.com/)

---
## :hugging:ひょんなことからQiitaデビュー

最近、仕事がてらいろんな会社さんのフォーラムやらハンズオントレーニングに参加する機会があって結構刺激を受けておりました。
BluemixについてもSwiftやら、
社内で見かけたNode-Redきっかけで少し興味が沸いており、
先月IBM Cloudで一回だけ遊んでみていましたが、
**「Bluemix ハンズオン」**でググってみたところ
**「12/3(日） IBM BMXUG 冬の大勉強会」** 
をたまたま見つけて、日曜日だけど奥さんに許可を得て行ってみるかと、
とても軽いノリでハンズオンに参加してきました！

　　![冬の大勉強会](https://qiita-image-store.s3.amazonaws.com/0/34108/2245b3c6-d23f-592a-0914-e1c4b92e5aa8.png)

なんでも「**アドベントカレンダーに登録したらノベルティをいただける**」ということで気軽に参加登録しました。

で、いただいたのがこちら。↓
　　![タンブラー](https://qiita-image-store.s3.amazonaws.com/0/34108/8a85f2e0-583b-60db-7963-99e4ed8c9a68.png)

ということで、ノリでQiitaに初投稿することになりましたので、お手柔らかに。


## :angel:感想： PCもラズパイも持って行かなかったけれど、楽しめた！
　お菓子に、水に、ノベルティまでいただき、スタッフの方々ともお話でき、
　なかなか楽しい時間でした。

### :alien:前半： "Watson"を使ってAIアプリを作ろう! 
>　 (参考)https://ibm.biz/watson1203
  
　　![ハンズオン](https://qiita-image-store.s3.amazonaws.com/0/34108/2e98058f-3b98-8acc-c6b1-f17f180015e9.png)
  
　※PCを持参していなくてiPad mini初代でやろうとしたが、流石に性能が足りず現場ではできませんでした。
　※おうちで早速トライしてみましたが、
　　カタログ -> Conversation -> スペースの選択の欄ところで、
　　スペースがないと言われて、作成ができず手詰まり。

　　一旦諦めモードでおりましたが、ついさっき(12/5 0:00)突破方法が判明。
　　デプロイする地域に**「米国南部」**を選択すると上手くいくではありませんか！！！
　　続きはまた後にするーーー:triumph:！

　※ハンズオン資料のP21のところです。。。
　  **必見！ライトアカウントならではの大事なポイント↓**
 　  ![米国南部](https://qiita-image-store.s3.amazonaws.com/0/34108/7d4a6d73-bac4-6b67-a55e-826530b1de15.png)


### :robot:後半： ラズパイで動く人工知能ロボットTJBotをつくるハンズオン
 > (参考)https://qiita.com/zuhito/items/ead9579a8676cb930556


　→ とはいっても、ひたすらガワを作るだけの工作演習！！
　　でもでも、素晴らしいキット（ダンボール図面と手の部分）をいただき、結構夢中になりました！
　　![IMG_0286.png](https://qiita-image-store.s3.amazonaws.com/0/34108/fc16661d-b3df-175b-d0b0-1e0aefad4ffb.png)

　　で、できたのがこちら。↓

　　![TJBot](https://qiita-image-store.s3.amazonaws.com/0/34108/d746c569-e346-de58-f720-424afe9c90ef.png)

　「これを機会にワンコイン・ラズパイ(Raspberry Pi Zero？)でも買ってみようかな・・」と少しIoTの世界にプライベートでも足を踏み入れる動機作りには繋がりました！

---
## :santa_tone2:ライトアカウントの注意点
・米国南部を 選択すること！
・1000回だか、10000回たたくと、月を跨るまで使えなくなる（らしい）。
・メモリーは、256MBまで。
・10日間何もしないと非アクティブになる。(でも、「更新すればまた、使えるようになるよ!」とのこと。)
※詳しくは、[こちら](https://www.ibm.com/cloud-computing/jp/ja/bluemix/lite-account/)。

---
## :relieved:あとがき
ちなみに、IBMさんは15年ほど前に新卒で内定をいただいたご縁があり、
それっきりでしたが、今回再び親近感が沸く機会となりました〜。
夜はAfter Partyもあったみたいだけれど、
いつもの日曜日のパパに戻るため、お先にお暇（いとま）させていただきました。

by [EijiPon](http://eijipon.jimdo.com)
(DEPRECATED) Kubernetes Bootcamp (0から始めるKuberenetes公式ブートキャンプ) (現Learn Kubernetes Basics)

(2018-09-05追記) :warning: :warning: :warning:  こちらの記事で紹介している[Kubernetes Bootcamp](https://github.com/kubernetes-retired/kubernetes-bootcamp)はkubernetes/websiteにLearn Kubernetes Basicsとして統合されました。今後は以下のLearn Kubernetes Basicsをご利用ください（ソースコードは[kubernetes/website](https://github.com/kubernetes/website/tree/master/content/en/docs/tutorials/kubernetes-basics)にあります）:

https://kubernetes.io/docs/tutorials/kubernetes-basics/

----

今週からいよいよKubeCon + CloudNativeCon North America 2017が始まります。本編は12/6からですが、Pre-eventが今日12/4から始まります。3500人以上のレジストレーションがあるようです。

## Kubernetes Bootcamp

アプリケーションを開発・運用する企業にとって、Kubernetesを利用していく中で一番の課題の一つはアプリケーションエンジニアに対するKubernetesについての理解・トレーニングなのではないかと思います。

![](https://qiita-image-store.s3.amazonaws.com/0/49113/8c40ad0f-a946-78b2-7eff-3980a9f7f558.png)

- https://kubernetesbootcamp.github.io/kubernetes-bootcamp/

今日はKubernetes BootcampというKubernetes公式の入門コースを紹介します。

> By the end of this bootcamp you will understand what Kubernetes does. You will also learn how to deploy, scale, update and debug containerized applications on a Kubernetes cluster using an interactive online terminal.
https://kubernetesbootcamp.github.io/kubernetes-bootcamp/

このBootcampを体験すると、Kubernetesが何者なのか分かるはずです。
Bootcampの中にオンラインターミナルがあるので、Kubernetesクラスタを準備するというような手間をかけることなく、Kubernetesの本質が理解できると思います。

この用意されたKubernetesクラスタ上で、あなたのコンテナ化されたアプリケーションをデプロイ、スケール、更新、デバッグできるようになります。

所要時間はわずか60分。これまで名前は聞くけど、触れてこなかったという方もぜひ一度試してみてください。

## 更新について

このKubernetes Bootcampは2016年の夏頃に公開されました。その後、細かい修正などが入っていますが、Kubernetes 1.5 (1.5.2) 前提での内容になっています。Bootcampの範囲においては現在のKubernetes 1.8との互換性はあるので、問題ないと思います。

## リポジトリ

このBootcampリポジトリ/イシュートラッカーはGitHub上のKubernetesオーガニゼーションで公開されています。誤植や改善はPRで行なうことができます。

https://github.com/kubernetes/kubernetes-bootcamp
OpenFOAMの$FOAM変数

# OpenFOAMの$FOAM～
OpenFOAMをインストールしてインストールフォルダのetc/bashrcを読み込むと$FOAM～の変数が使えるようになる。
以下各変数をechoで表示させたときの内容を示します。mmer547とある場所は各人のユーザー名で置き換えてみてください。
(本記事はv1706を対象としています。)

#$FOAM_APP
アプリケーションフォルダのパス。

```
$ echo $FOAM_APP
/home/mmer547/OpenFOAM/OpenFOAM-v1706/applications
```

#$FOAM_EXT_LIBBIN
scotchなどのライブラリのあるディレクトリへのパス。

```
$ echo $FOAM_EXT_LIBBIN
/home/mmer547/OpenFOAM/ThirdParty-v1706/platforms/linux64GccDPInt32/lib
```

#$FOAM_MPI
OpenFOAMで使用しているmpi。
$FOAM_ETC/bashrcで選んでいるもの。

```
$ echo $FOAM_MPI
openmpi-system
```

#$FOAM_SIGFPE
Floating-point signal handlingと$FOAM_ETC/bashrcには書いてある。

```
$ echo $FOAM_SIGFPE

```

#$FOAM_SOLVERS
ソルバのソースファイルディレクトリのパス

```
$ echo $FOAM_SOLVERS
/home/mmer547/OpenFOAM/OpenFOAM-v1706/applications/solvers
```

#$FOAM_USER_APPBIN
自作アプリケーションの保存場所。デフォルトでは存在しないため、mkdirを組み合わせて作成する。

```
$ echo $FOAM_USER_APPBIN
/home/mmer547/OpenFOAM/mmer547-v1706/platforms/linux64GccDPInt32Opt/bin
```

#$FOAM_APPBIN
アプリケーションの実行ファイルがあるディレクトリへのパス。

```
$ echo $FOAM_APPBIN
/home/mmer547/OpenFOAM/OpenFOAM-v1706/platforms/linux64GccDPInt32Opt/bin
```

#$FOAM_INST_DIR 
OpenFOAMのインストールディレクトのパス。

```
$ echo $FOAM_INST_DIR
/home/mmer547/OpenFOAM
```

#$FOAM_RUN
ユーザーのrunフォルダのパス。勝手にできるものではないのでmkdirを使用して作る。runフォルダにはrunコマンドで飛ぶことができる。

```
$ echo $FOAM_RUN
/home/mmer547/OpenFOAM/mmer547-v1706/run
```

#$FOAM_SITE_APPBIN 
デフォルトでは存在しない。

```
$ echo $FOAM_SITE_APPBIN 
/home/mmer547/OpenFOAM/site/v1706/platforms/linux64GccDPInt32Opt/bin
```

#$FOAM_SRC
乱流モデルや境界条件等のソースコードディレクトリへのパス。

```
$ echo $FOAM_SRC
/home/mmer547/OpenFOAM/OpenFOAM-v1706/src
```

#$FOAM_USER_LIBBIN
ユーザーのライブラリディレクトリへのパス。この辺に入れておけばOpenFOAMのライブラリと同じようにタブ補完の対象になる。

```
$ echo $FOAM_USER_LIBBIN
/home/mmer547/OpenFOAM/mmer547-v1706/platforms/linux64GccDPInt32Opt/lib
```

#$FOAM_ETC
OpenFOAMのインストールディレクトリ下のetcディレクトリへのパス。

```
$ echo $FOAM_ETC
/home/mmer547/OpenFOAM/OpenFOAM-v1706/etc
```

#$FOAM_LIBBIN
OpenFOAMのライブラリディレクトリへのパス。

```
$ echo $FOAM_LIBBIN
/home/mmer547/OpenFOAM/OpenFOAM-v1706/platforms/linux64GccDPInt32Opt/lib
```

#$FOAM_SETTINGS
不明

```
$ echo $FOAM_SETTINGS

```

#$FOAM_SITE_LIBBIN
デフォルトでは存在していない。

```
$ echo $FOAM_SITE_LIBBIN
/home/mmer547/OpenFOAM/site/v1706/platforms/linux64GccDPInt32Opt/lib
```

#$FOAM_TUTORIALS
チュートリアルディレクトリへのパス。

```
$ echo $FOAM_TUTORIALS
/home/mmer547/OpenFOAM/OpenFOAM-v1706/tutorials
```

#$FOAM_UTILITIES
ユーティティのソースコードがあるディレクトリのパス。

```
$ echo $FOAM_UTILITIES
/home/mmer547/OpenFOAM/OpenFOAM-v1706/applications/utilities
```

#まとめ
$FOAM変数を使うことでOpenFOAMの各種ディレクトリに素早くアクセスできる。よく使うやつは覚えておくと便利。
僕が過ごしてきたSP2LC

# はじめに
サレジオ工業高等専門学校情報工学科4年在学，そして現役のSP2LC所属の学生をやっている北村です．
この記事は，誰も12/4に参加登録してくれないので**つなぎ**という意味も込めて，自分が所属しているSP2LCについてと，そこで僕が感じたことをつらつらと書き連ねていこうと思います．当日夜になって急いで書いているので内容の薄さとか雑さとか目立つと思いますが悪しからず．

# はじめの印象
SP2LCへは，確か全国高専プロコンへの参加に併せて入りました．ここら辺の「プロコン」と「SP2LC」の関係は少しわかりにくいので割愛します．

入った当初，同級生はかなりの人数いましたが後々抜けていったので印象が薄いですが，先輩の印象はかなり強かったように感じます．部屋には，大きいホワイトボード，パソコンのデスク，黒い箱(サーバーラック)があり，サークルや部活というよりかは事務所とかオフィスに近いような印象でした．

中学二年生ぐらいからプログラムを少しかじったり自作PCを組み立てたりしていたこともあって，自分に自信がありました．そこで先輩たちに出会って，まだまだ上がいることや，自分はまだ未熟であることを思い知らされたような気がします．

# プロコンでの活動

入った当初は，プロコンでメインのコーダーになるような力はなかったので，支援ツール等の開発をしていました．最初の年は競技部門に所属していたので，プログラムの性能評価等をやっていました．競技内容を適当に説明すると，「画像を64x64以内で正方形に分割し，バラバラに並べたものを問題とし，元に戻す手数の少なさと解答時間を競う」というものでした．

まず最初は練習問題の作成からやりました．imagemagickをCUIでごにょごにょした記憶があります．ここでBashのちょっとした操作等は覚えました．

次は，プログラムが出した解答を，アニメーションで可視化するWebAppのようなものを作りました．
完成したとき，相当嬉しかったのかFacebbookに動画を投稿していました．以下にリンクをば．

https://www.facebook.com/kai.kitamura.980/videos/368616529956357/

これを通じてPHP, HTML, CSS, JavaScript(+jQuery)が少し触れるようになりました．

時間がないので大規模な割愛をしていきます．

その後は，競技プログラムの開発にも参加するようになり，2年生で競技部門に登壇したり，後輩教育をするようになったりしました．

# 振り返ってみて
SP2LCに入っていなかったら，ここまで積極的にプログラムを書くようにはなっていないと思います．
というのも，何より環境が良かったように感じます．研究用ネットワークに制限がなく早いので調べものがスムーズでしたし，先輩は2つも3つも上の年代がいていろんな話が聞けるし，大会への参加でプログラムを書く目的があるし．というような感じで，自分にとっては楽しいことづくしでした．
LT大会とか，プレゼン資料作成とかもやるので，必然的にそこら辺のスキルが身についていたりします．就職活動等をはじめるようになって，このあたりを褒められると，つくづくSP2LCでの活動が身になっているなあと感じます．

後輩にも，ここでの活動を将来に生かしてほしいなあとか思いながら教育だったり伝承だったりをしています．

# おわりに
かなり雑ですがここらへんで．もう何回か書くことになると思うので，そこら辺では技術的なことも絡めていきたいと思います．
次はOBの先輩の記事です．お楽しみにー！
ソフトウェアエンジニアのためのArduino入門

#はじめに
Arduino沼へようこそ！！
この記事は、ソフトウェアエンジニアがArduino沼にハマった経験を活かし、仲間を増やすため、沼へ引きずりこむことを目的として書いています！

#自分のきっかけ
昔のマイコンは高かった。開発環境も有料が多かったし、情報も少なかった。
互換機安い！500円ぐらい！
勉強がてら、何か作ってみよう！あわよくば売って儲けよう！
って流れで吸い込まれていきました。

#Arduinoのいいところ
##①安い
AmazonでUno互換機が500円ぐらい。Nano互換機が300円ぐらい。Digispark互換機で250円。
Aliexpressとかで中国輸入するとさらに安く入手できます。
正規品は、3000円ぐらいです。
互換機ばっかり買って、本家に還元なくて悪いなーと思う方は、寄付もできます！

##②情報が多い
 
[本家(英語)](https://www.arduino.cc/)
チュートリアル、フォーラム等。

[Arduino 日本語リファレンス](http://www.musashinodenpa.com/arduino/ref/)

その他、たくさーーんのブログなど。
「Arduino やりたいこと」、パーツ名、型番で検索すると、だいたい情報が見つかります。

##③コミュニティがある
Arduinoのすごいところは、SW・HW・開発環境・コミュニティが揃っているところだと思います。
本家のフォーラムは世界中から書き込みがあるようです。
日本では、[Arduinoファン](https://www.facebook.com/groups/arduinofun/)というグループが活発に活動されています。頻繁にもくもく会(みんなでもくもく作る会)を開催されています。


##④オープンソースソフトウェア、オープンソースハードウェア
ソースはもちろん、ハード：回路図や部品の情報も公開されています！！
自分でパーツ集めて、互換機作ってもいいよ！売ってもいいよ！という決まりです。
Arduinoという名前やロゴの使い方に制約があるみたい。

##⑤組込みの勉強になる
組み込み開発には、Webやアプリ、Winのソフトとはちょっと違った知識が必要です。
いきなり業務でやるには難しいですし、家で業務と同じ環境を作るのは難しいです。
そこでArduino！
基本的な考え方や、メモリの制約、I2CやSRAMとか勉強になりました。
あと、組込みの基本的な技術は陳腐化しにくいと思っています。
20年前の組込の技術がそのまま今でも役に立つと思います。

PHPのフレームワーク多すぎー！
CMSの種類多すぎー！
JSのライブラリ多すぎー！
AngularJSわかんねー！
Objective-C？Swift？
JAVA？Kotlin？
HTML5？Monaca？Xamarin？PhoneGap？
ふぁぁーーーー！！！！
覚えること多すぎー！！
と思っているあなた！！！安住の地へようこそ！
Arduinoは世界中で流行っており、マイコン入門のデファクトスタンダードと言っても過言ではないと思います。
今流行りのIoTやってみようってのにも対応できますよ！！

#言語は？
基本はC++。Arduino言語と呼ばれているみたい。
ここはクリアしていれば、「Arduinoちょっとできる」の半分できたも同然です！！

[JSで動かす方法](https://ics.media/entry/4758)もあるみたい。
RUBYやPythonで動かせるマイコンもあるみたい。最後のその他のマイコンを参照。

スクラッチでも動かせます！
[Arduino専用ビジュアルエディタBlocklyDuinoの使い方](https://qiita.com/okhiroyuki/items/f6ed9a78a41612e8ec08)

#どんなことができるの？
Lチカ(LEDチカチカ)=電子工作界の「Hello World」
カラーLEDをド派手にピカピカ(ギャル電的な)
サーボモータで、
　マウスをずっと動かす君
　電源ON/OFF連続試験治具
LED点灯しているか判定マシン(HWの試験治具に)
3Dプリンタ、CNC、レーザーカッターのコントローラ部分にも使われていたりします。
USB機器を作る。キーボードを作る。
なんでもできます！なんでも！(気持ちだけで発言)

##自分の作ったプロジェクト
###XFD
  [アラーム君](https://qiita.com/onoche/items/ebcf3e58d5461e9d3692)
  [見える！「IoT」 NefryでJenkinsのXFD作ってみた](https://www.slideshare.net/BlueTone1/170810-jenkins-nefryjenkinsxfd)

###スペースデジミン
[「スペース・デジミン」Arduinoと赤外線センサーを使ったテルミンデバイス](8http://letsmakebt.blogspot.jp/2017/03/arduino.html)

###モヒートマシン
[FABLAB北加賀屋](http://fablabkitakagaya.org/noncategory/4868/)のプロジェクトに参加しました。
[動画](https://twitter.com/bluetoneinfo/status/929546125694058497)
[説明(作成中)](https://fabble.cc/morikoh/mojitobot)


時代はメイカー！
DIY！

#環境構築
Arduino IDEをインストールします。
互換機はCH340というドライバ入れる必要があります。
そう、ソフトウェアエンジニアなら余裕ですね。

#ライブラリ
便利なライブラリがたくさーんあります。
IDEのメニューの「ライブラリを管理」から入れるか、Zipで落としてZipでインストールか、直接ライブラリフォルダへ。
GitHubで管理されているものが多い。
詳しくはググってください。

#Arduinoの種類
いろんな種類があります。
http://ideahack.me/article/134

自分が好きな、代表的なものを紹介。

- UNO 一番ポピュラー。
- MEGA　ピン数、メモリが多い。
- NANO 小さい。機能的にはUno相当。ピン数も同じ。

- Pro Mini USBシリアル無し。小型。3.3vで省電力な設計もできる。
- DigiSpark　小さい！安い！ピン数は少ない。

- ESP8266　Wifi付きマイコン　ブートローダを書くことで、ArduinoIDEでも開発できる。
- Nefry、Nefry BT　ESP8266やESP32が乗ったIoTデバイス。便利なライブラリーがセットになっているので、簡単にIoTできます！IFTTTやAWSなど、WEB系サービスとの連携もサポート！日本語の情報も多いです。

#その他のマイコン
こんな感じのキーワードで調べてみてください。
IchigoJam(Basic)
mruby(ruby)
Micro Python(Python)
ラズパイ(Linux)
mbed
FPGA

#あとがき
どうですか？Arduinoやりたくなってきましたね？
まずは、Unoを買って、Lチカしてみてください！
あとは、やりたいことをやりたいように！
Arduino、電子工作、楽しいですよー！！
POV-Rayでの変数の宣言

# はじめに
これは [POV-Rayによる数学お絵かき入門 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/povray4math) の4日目の記事です.

最初はカメラについて書く積りでしたが, 予定を変更してPOV-Rayにおける識別子(変数)の宣言について書きます.

公式ドキュメントでは
http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_2
http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_5
辺りの内容が近いです.

# 最初の例
POV-Rayで変数を宣言するには例えば次のようにします.

```
#declare a=1;
```

これは変数`a`に数値`1`を与える命令です.
POV-Rayでは変数の型を明示的に指定する必要はありません.

行末のセミコロン`;`は基本的には必要です.
数値やベクトルなど以外では`;`が不要らしいですが, 書いても問題ないので全部書くようにするのが吉です.
http://www.povray.org/documentation/view/3.6.0/237/
http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_5_2

# 数値
POV-Rayでは整数と実数は明確に区別されません.
具体例を挙げるなら「`1`と`1.0`を区別する事はできない」になります.
これについては別の回で詳しく書くかも知れません.

## 例

```
#declare e=2.718281;
```

# ベクトル
POV-Rayではベクトルを`< >`で囲んで表します.

## 例

```Povray
#declare r=0.1;
#declare c=<1,1,1>;
sphere{c,r}
```

とすれば$(1,1,1)$中心の半径$0.1$の球面が描けます.

## 注意
### ベクトルの次元
基本的によく使うのは3次元のベクトルですが, 他にも2, 4, 5次元のベクトルを扱う事ができます.
例: `<1,2>`, `<1,2,3,4>`, `<1,2,3,4,5>`
ただし`<1>`のような1次元ベクトルは許容されません.

これらの用途は次です:

| 種類 | 用途 |
| -------- | -------- |
| 2次元 | 2次元座標, `prism`などのオブジェクト |
| 3次元 | 通常の座標, 色の指定(`rgb`) |
| 4次元 | 4次元座標, 色の指定(`rgbf`, `rgbt`) |
| 5次元 | 色の指定(`rgbft`) |

これについてもまた詳しく書きます.

### ベクトルの要素の取り出し方
ベクトルの成分を取り出すには次のように`(ベクトル).(成分の指定)`とします.

```Povray
#declare a=<1,2,3>.y;
```

この例では`a`に`2`が代入されます.
2次元ベクトルでは`u`, `v`
3次元ベクトルでは`x`, `y`, `z`
4次元ベクトルでは`x`, `y`, `z`, `t`
が成分の指定の記号として使われます.

### ベクトルの解釈
実はPOV-Rayでは次のような指定が記述が可能です.

```Povray
sphere{1,0.1}
```

`sphere`は第一引数にベクトルしか受け取りませんが, ここでは数値を指定しています.
このような場合は`1`は`<1,1,1>`のように全てに同じ成分を並べたものとして解釈されます.
(`1`と`<1,1,1>`が内部的に同じものとして扱われている訳ではありません.)
これを使えば次のような記述も可能です.

```Povray
#declare a=<1,2,3>-1;
```

この例では`a`に`<0,1,2>`が代入されます.

3次元のベクトルを引数に取る筈の所に2次元ベクトルを書けば$z$成分に$0$が保管される, 等もあります.
たとえば`sphere{<1,2>,0.2}`と書けばこれは`sphere{<1,2,0>,0.2}`と同じです.

### ベクトルの要素
ベクトルの要素には数値しか許容されません.
POV-Rayではベクトルとは別に配列が用意されています. (後述)

# 文字列
しばらくは文字列を扱う事はありませんが, 同様に

```Povray
#declare a="hoge";
```

として宣言が可能です.
POV-Rayで文字列が活躍するのは(後で書く予定の)

* `text` (テキストオブジェクト)
* `debug` (テキスト出力)

になります.

# 配列
配列を書くためには次のようにします.

```
#declare hoge=array[3];
#declare hoge[0]=1;
#declare hoge[1]=2;
#declare hoge[2]=3;
```

単に配列を宣言しただけでは, 配列は初期化されていません.
(参照するとエラーになります.)
次のような書き方も可能です.

```
#declare hoge=array[3]{1,2,3};
```


## 注意
### 配列のインデックス
上で既に見ましたが, $n$次元配列の要素を参照する際には`[0]`から`[n-1]`までのインデックスを使います.

### 配列の長さの宣言
C言語では配列の要素数を与えるには`#define`を使う必要がありますが, POV-Rayでは全て`#declare`で書けます.

```
#declare l=3;
#declare hoge=array[l];
```

### 配列の要素
古いバージョンでは配列の要素は固定(数値なら数値, 文字列なら文字列)の制約がありましたが, 最近のバージョンでは混在していても問題ありません.

### 多次元配列
他の多くの言語と同様に

```
#declare hoge=array[2][3]{{1,2,3},{4,5,6}};
```

などで宣言が可能です.

# 真偽値
POV-Rayの真偽値はC言語と同様に数値の`0`, `1`で表現されます.
比較演算子には`=`, `<`, `>=`等が用意されていて, 例えば`1=2`, `1<2`, `1>=2`はそれぞれ`0`, `1`, `0`と評価されます.
(等号には`==`を使いません)

# 変数のスコープ
`#declare`で宣言した変数はグローバル変数として扱われます.
(別の回で解説予定の)macroやincludeファイル内で有効な変数を宣言するには`#local`を使います.

http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_2
ビジネスロジックが複雑なときはRequestオブジェクトを作るといいんじゃないかというお話

この記事は [Relux AdventCalendar](https://qiita.com/advent-calendar/2017/relux) 6日目の記事です。

# Requestレイヤーを導入した話

Webアプリケーションのソースコードは、リクエストデータの妥当性チェックとデータ整合性チェックとデータ整形などなど、往々にして長くなりがちです。ビジネスロジックが複雑になっていくほど、データ整合性のチェックや、外部サービス連携のためのデータ整形の処理が膨らんでいきます。

そこでリクエストデータを精査してアプリケーションに使いやすい形で渡す役割として、Requestオブジェクトというレイヤーを導入してみました。

# Requestレイヤーの役割

## リクエストデータのバリデーション

フォームからPOSTされた値の「必須項目」や「値型」のバリデーションだけでなく、DBのデータを参照してビジネス要件的に妥当なリクエストかどうかの確認もRequestオブジェクトが行います。

```
# ReservationRequest.php

class ReservationRequest extends Request
{
    public $validate = [
        'plan_id' => [
            'notEmpty' => [
                'rule' => ['notEmpty'],
            ],
            'exists' => [
                'rule' => ['planExists'],
            ],
            'inSalesPeriod' => [
                'rule' => ['inSalesPeriod'],
            ],
        ],
    ];

    /**
     * 宿泊プランが存在するかチェックする	
     */
    public function planExists()
    {
    	return $this->plan() ? true : false;
    }

    /**
     * 宿泊プランが利用可能な日程かチェックする
     */
    public function inSalesPeriod()
    {
    	$plan = $this->plan();
    	$schedule = $this->schedule();
    	return $plan->inSalesPeriod($schedule);
    }

    /**
     * 宿泊プランを返す
     */
    private function plan()
    {
        if (!$this->hasCache('plan')) {
            $model = ClassRegistry::init('Plan');
            $plan = $model->findById($this->get('plan_id'));
            $this->setCache('plan', $plan ? $plan : null);
        }
        return $this->getCache('plan');
    }

    /**
     * 宿泊日程オブジェクトを返す
     */
    private function schedule()
    {
        return new Schedule(
            new DateTimeImmutable($this->get('checkin')),
            new DateTimeImmutable($this->get('checkout'))
        );
    }
```
この擬似コードでは予約フォームからリクエストされたプランIDとチェックイン日・チェックアウト日が実際に予約できるかまでバリデーションをかけています。

## リクエストデータの整形

カスタマーにできるだけストレスを感じずに予約してもらえるようにある程度の入力ミスを許容して、サーバー側で変換することも大切です。

例えば電話番号を全角数字で入力してしまった場合に、半角数字に変換して後続処理に回すということは良くやると思いますが、これもRequestクラスが行います。

## コントローラーで処理するオブジェクトを生成して返す

Requestオブジェクトを実装した当初は、整形したリクエストデータを返してくれるオブジェクトとしてコントローラーで使いまわして、予約Entityを生成し、予約処理を実行することを想定していました。

しかし予約はWebブラウザだけでなくAPIなど複数のフローが存在します。そのフローごとに１度にリクエストされるパラメータが異なるため、予約Entityのプロパティがどこまでセットされるかはそのフロー（リクエスト）に依存します。そこに対応するためにEntity生成までをRequestオブジェクトの責務としました。

```
# ReservationRequest.php

    /**
     * 予約データを生成する
     */
    public function toEntity()
    {
        $model = ClassRegistry::init('Reservation');
    	$plan = $this->plan();
        $schedule = $this->schedule();
        $properties = ['Reservation' => [
            "plan_id" => $plan->id,
            "checkin" => $schedule->checkin(),
            "checkout" => $schedule->checkout(),
            // more properties...
        ]];
        return $model->entity($properties);
    }
```

RequestオブジェクトからEntityを生成してもらったコントローラーは、予約処理フローを流すことだけに集中してもらうことで、可読性を高くすることができました。

## まとめ
ビジネスロジックのゴタゴタをコントローラーに持っていく前に、Requestレイヤーに吸収してもらうと幸せになれます。
放置されていた Rubocopのバージョンを上げて onkcop の導入を始めた

みんなのウェディング Advent Calendar 2017 の 14日目の記事です。

----

業務で Rubocop を使っています。ただし、2017年4月まで放置気味でした。
しかし「[Rails 5.0 へのバージョンアップ作業過程](https://blog.mwed.info/posts/rails50.html)」で Rubocop もバージョンをアップしました。


# 2016年1月 から 2017年4月まで 同じバージョンだった理由
  
ある日、tachikoma からのプルリクエストのテストが落ちました（当時、平日は[tachikoma](https://github.com/sanemat/tachikoma) による gem のアップデートをしていました。現在は deppbot を利用しています）。原因は、Rubocop に入った cop の指摘の対応ができなくて、「あとでやる」と書いてそのまま放置してしまいました。1年ちょっとぐらい...

## 最新のバージョンにアップした方法

Rubocop の指摘について対応するツールはあるのですが、ツールだけじゃ足りなく1つ1つ潰していく時間が必要でした。1つ潰しては、プルリクエストにしてマージして...を繰り返していきました。当時、テストのカバレッジも低く、手動テストも合わせていました（テストカバレッジについては別な話）。

## 追加になった cop で気づいたこと

追加になった cop の対応をすすめる時に、指摘されている内容を見ると「なるほど」と思う指摘がありました。そのなかからいくつか抜粋です

### Lint/IneffectiveAccessModifier

クラスメソッドなのに、private なのはないよね、という指摘をしてくれます。
指摘されて、「そりゃそうだ」と思ったのを覚えています。

```ruby
# Bad
class Article
  private
  def self.by_tag_id(tag_id, limit=5)
    ... 
  end
end

# Good
class Article
  def self.by_tag_id(tag_id, limit=5)
    ... 
  end
end
```

### Style/ConditionalAssignment

下記の例だけだとわかりにくいのですが、Ruby っぽい Cop です

```ruby
# Bad
if foo
  x = 1
else
  x = 2
end

# Good
x = if foo
  1
else
  2
end
```

余談ですが、Rubocop には、Bad と Good のサンプルがあります。全部にある状態ではないので、「[RuboCop のドキュメントに example を追加してみる](https://qiita.com/pocke/items/ade84e1f21629220715d)」を読んで実際に書いてプルリクエストをいくつか出しました（v.0.52.0 に入ってました）。

# onkcop の導入

バージョンを上げた後、onkcopを 2017年5月 に導入しました。
onkcop を導入した理由は、コードの品質を下げないためです。Rubocop は導入されているけれど、設定が緩めで「意味あるのこれ？」という話から設定を少しづつ厳しくしています。

時々、この設定はナゼ？と思うこともあります。そのときは、プルリクエストや定期的に開催されるエンジニアリングミーティングで話したりしています。

# 「あとでやる」は「あとでやらない」

ふりかえると、Rubocop の導入自体は大切な一歩です。
Ruby でプログラムを書いた経験の少ない人達で開発を始める時、コードに一定のルールを持たせるために、Rubocop は必要なツールだと思います。
ただし、Rubocop を導入しただけではダメで、「なぜ、その Cop が設定されているのか？」についても考える必要があったのだと思います。そこについて話せないまま「あとで対応しよう」では Rubocop の意味がありませんでした。

とはいえ、まだまだ rubocop-todo.yml をそっと閉じたくなる気持ちが湧く状態です。ここも解消してきたら、また別な知見としてまとめる日が来そうです。
protocolで宣言されたassociatedtypeの型を判定する

この記事は[yurueアドベントカレンダー](https://qiita.com/advent-calendar/2017/yurue)の７日目の記事です！

SwiftでAPIクライアントを書いていて、リクエストごとにクラス・構造体を作成した経験はありませんか？
そのリクエストについて記載したものの中には恐らく、Responseの型が記述されているのではないでしょうか。
今回は、protocolで宣言されたassociatedtypeの型を判定するサンプルを書こうと思います。

##ソースコード

```swift:playground
protocol P {
	associatedtype Response
}

func typeDetect<T: P>(instance: T) {
	switch T.Response.self {
	case is String.Type:
		print("String")
	case is Int.Type:
		print("Int")
	default:
		print("else")
	}
}

class C1: P {
	typealias Response = String
}

class C2: P {
	typealias Response = Int
}

let c1 = C1()
let c2 = C2()

typeDetect(instance: c1) // String
typeDetect(instance: c2) // Int
```
Raspberry Pi 2でLチカ その① モニタとキーボード無しでMacからRaspberry Pi を操作


この記事は[「IDOM Engineer Advent Calendar 2017」](https://qiita.com/advent-calendar/2017/idom-engineer)の5日目の記事です。

# はじめに
エンジニア組織に所属している非エンジニアの[sachitaro](https://qiita.com/sachitaro)です。普段は企画管理業務を行なっており、コーディングやIoT機器などには一切触れていません。
そんな初心者の私が、社内のエンジニア勉強会で教えてもらいながらRaspberry PiのLチカができるようになったので、一人でも再現できるようにここに記載します。

今回はその①としてRaspberry PiをMacからリモートで動かすところまで。次回その②では、Raspberry Piをリモートで動かしながらLチカを行っていきます。

# 用意するもの
- Raspberry Pi 2 （OSインストール済。3でなく2の理由は、買い間違えたから…）
- LED
- ブレッドボード
- MacBookAir
- LANケーブル＆Thunderboltコネクタ

本来Raspberry Piを動かすためにはモニタとキーボードを用意する必要がありますが、今回はMacを使い、モニタとキーボードなしで動かすことにしました。
![pic2.jpg](https://qiita-image-store.s3.amazonaws.com/0/211390/1031498d-0fef-f0de-cec8-a0611fe63720.jpeg)


つまりRaspberry Piの操作は、Mac経由でリモートで行うことになります。

# 1）機材をつなぐ
その①ではRaspberry Piの動作確認だけでLチカは行わないので、ブレッドボードとLEDは使いません。
1. LANケーブルをThunderboltコネクタに差し込み、それをMacにつなぐ
2. LANケーブルのもう片方をRaspberry PiのLANコネクタに差し込む
3. Raspberry Piの電源ケーブルを電源に差し込む

# 2）Raspberry Piをネットにつなぐ（Macからインターネット共有する）
Macで　システム環境設定＞共有＞インターネット共有　を選択します。「インターネット共有」にチェックを入れ、「共有する接続経路」をWi-Fiにします。「相手のコンピュータでのポート」をThunderbolt Ethernetに設定します。
これで、Macのwifi経由でRaspberry Piをネットにつなぐことができました。

# 3）MacからRaspberry Piに接続する（SSH接続）
次に、MacからRaspberry Piを動かせるようにします。MacからSSH接続でRaspberry Piにつなぎます。
※SSH接続：リモートでサーバーに安全に接続してコマンド操作を行うこと

## Raspberry PiのIPアドレスを調べる
SSH接続するには、接続先（今回の場合はRaspberry Pi）のIPアドレスを入力する必要があります。そのためにまずは、Raspberry PiがつながっているIPアドレスを調べます。
Macから　Finder＞アプリケーション＞ユーティリティ＞ターミナル　でターミナルを起動。ここに以下のコマンドを入力し、IPアドレス一覧を表示させます。
```arp -an```
そこに表示されるIPアドレス一覧の中で、at以下が B8:27:EB で始まるものがRaspberry PiのIPアドレスです。
※ARP（アドレス解決プロトコル）)：MACアドレスを調べるコマンド

## MacからSSH接続でRaspberry Piにつなぐ
調べたIPアドレスを使って、SSH接続をします。なお途中でRaspberry PiのIDとパスワードを要求されますが、初期IDとパスワードはID:pi、パスワード:raspberryです。
まずはターミナルに以下を入力。
```ssh [ID]@[IPアドレス]```
初めて接続する際には以下のように聞かれるのでyesと入力します。
Are you sure you want to continue connecting (yes/no)? 
次に以下のように聞かれるのでパスワードを入力します。
[ID]@[IPアドレス]'s password: 
これでMacからSSH接続でRaspberry Piにつなぐことができました。

# 4）MacからVNCを使ってリモートデスクトップでRaspberry Piにつなぐ
SSH接続のままでもよいのですが、1行ずつコマンドを入れなければならないので使い勝手がよくありません。そこでGUI形式でリモートデスクトップができるVNCを使うことにします。
※GUI（Graphical User Interface）：視覚表現を使ったUI。マウス等で操作。
※VNC（Virtual Network Computing）：クロスプラットフォームなリモートデスクトップ。マシン間のOSなどのプラットフォームに依存することなく利用できる。

## Raspberry PI にVNCサーバをインストール
まずRaspberry PI にVNCサーバの一つ、TightVNCサーバをインストールします。
以下のコマンドを入力します。
```sudo apt-get update```
```sudo apt-get install tightvncserver```
これでインストール完了。
次にVNCサーバを起動します。
``tightvncserver``
初めて接続する際には以下のようにパスワードの設定を求められるので何か設定します。
You will require a password to access your desktops.
## MacからVNCサーバに接続
MacからFinderを開き、上部のメニューから　移動＞サーバへ接続　を選択します。するとアドレスを入力するウインドウが開くので、以下のアドレスを入力します。
``vnc://[IPアドレス]:5901``
接続を押し、Raspberry PI のデスクトップが表示されたら成功です！

![23669117_319804501832524_997253714404436558_o.jpg](https://qiita-image-store.s3.amazonaws.com/0/211390/d86705bc-1145-2ba9-23b1-41b43aa64560.jpeg)

次回その②では、Raspberry Piをリモートで動かしながらLチカを行っていきます。


さて明日は勉強会の師匠、[9muta](https://qiita.com/9muta)さんの記事をお届けします。