OmniAICreator/Qiita-1.07M huggingface dataset:
EKS利用時に注意すべきポイント

職場でEKSを利用しているので、EKS固有の注意点とかまとめられるといいな〜と思っていました。この記事ではオンプレでKubernetesを利用している人がEKSを使う場合にどういう点に気をつけるといいかを[Productionproofing EKS](http://techmovers.salemove.com/infrastructure/2018/11/01/Productionproofing+EKS.html)も参考にしてまとめてみます。**目次を見て、興味ありそうなら読んでみてください。**

ニッチなケースは対策までは考えれていないので、随時思いつけたら更新できるといいなと思います。

# ネットワーク
KubernetesはCNIによってネットワーク実装をプラガブルなものとしています。EKS利用時は[amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s)（以下、aws-cni)というCNIを利用します。そのためaws-cniの仕様に基づく固有の注意点を理解する必要があります。それぞれの注意点に結びつく、aws-cniの重要な特徴は「**PodのIPアドレスにEC2インスタンスのセカンダリIPを割り当てる**」ということです（参考：[セカンダリIPについて](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/MultipleIP.html)）。それではそれぞれの注意点を確認しましょう。

## Podの起動可能数はEC2インスタンスタイプに制限される
EC2に割り当てられるセカンダリIP数はインスタンスタイプごとに異なります。Podに割り当てられるセカンダリIPが不足してしまうと、Podを起動することができないので注意が必要です。各インスタンスタイプのネットワークインターフェイスあたりのIPアドレス数は「[Elastic Network Interface](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html)」を参考にしてください。例えば、m5.largeでは30個のIPを割り当てることができるので、primaryで利用する１個を除いた29個のIPをPodに割り当てることができます。
この制限については、EKSで利用するワーカーノードの起動スクリプトの[この部分](https://github.com/awslabs/amazon-eks-ami/blob/master/files/bootstrap.sh#L123)で対策がされています。kubeletに`--max-pods`オプションでワーカーノード上の最大起動Pod数を設定しています。この設定によりスケジューラは指定数以上のPodをワーカーノード上にスケジュールしなくなります。これでワーカーノード上にPodがスケジュールされたが、起動に失敗する事象は**起きづらくなります**。ただし、以下の状況で起きる場合があります。

- EC2へのENIのアタッチが失敗する
    - EC2へのENIアタッチが失敗するケースがあるそうです。その場合`--max-pods`より少ないセカンダリIPしかPodのために用意することができません。
- セカンダリIPがcooling中で割り当てができない
    - aws-cniでは[cooling mode](https://github.com/aws/amazon-vpc-cni-k8s/blob/74ecf61c60abb645aead82b3d7ad096788484455/docs/cni-proposal.md#pod-ip-address-cooling-period)を設けており、一度利用したIPをしばらく利用できないようにしています。
    - 例えば`--max-pods`が30の場合に、30個フルでIPを使っているとします。この時に10個のPodが停止しても、しばらくの間利用できるIPは１個もありません。しかしKubernetesのスケジューラは`--max-pods`の数にしたがって、Podをスケジュールしてしまうので、coolingが終わるまでPodが起動しません。


## Podの起動可能数はSubnetやVPCに制限される
セカンダリIPアドレスはEC2が所属するVPCのSubnetから払い出されます。つまりあるSubnet上では、SbunetのCIDRレンジ分しかPodを起動できません。例えば10.7.0.0/24のサブネット上では予約されたIPを除いた251個のPodしか起動できません。

# 認証認可
## RBACを使用する必要がある
KubernetesのRBAC機能は昔はありませんでした。EKSではRBACは必ず利用する必要があるので、利用していなかった場合は移行時に注意が必要です。

## IAMを利用する必要がある
EKSのKubernetes APIを利用する場合は、[aws-iam-authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator)を利用して、IAMによる認証を行わないといけません。AWS IAMの知識がないと困る部分もあるかもしれません。

## API Server endointはパブリック公開されている
EKSのKubernetes APIのエンドポイントはパブリック公開されています。上述の通り、IAMの認証により、保護されています。

# マネージドならではの注意点
## Kubernetesクラスタのカスタマイズができない
Kubernetesクラスタはマスターコンポーネントの起動時オプションによって様々なカスタマイズができます。しかし、マスターコンポーネントはAWSによって管理されているのでカスタマイズオプションが指定できません。そのため、例えば開発中の機能を利用できなかったり、細かい例をあげるとDockerコンテナのログローテート機能のon・offを選択できなかったりします。
オプションの例：[kube-apiserver - Kubernetes](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)

## 新しいバージョンが使えない
これは2018年のre:Inventで新しいバージョンへのインプレースアップデートが可能になると発表があったので2018/12/2現在の注意点です。
[[レポート]Deep Dive on Amazon EKS #reinvent #CON361 ｜ DevelopersIO](https://dev.classmethod.jp/cloud/reinvent-2018-report-eks-deep-dive/)


# 参考文献
- [Productionproofing EKS](http://techmovers.salemove.com/infrastructure/2018/11/01/Productionproofing+EKS.html)
プログラミング学習の履歴

#プログラミング学習の履歴
##Git/GitHub/Visual Studio
 https://qiita.com/shigural/private/b5bf2e1d14c5ebb00046

##Effective C++
 https://qiita.com/shigural/private/136745f92293f5b846ee

##吉田誠一のホームページ
　執筆中
　該当リンク：http://www.aerith.net/index-j.html

##More Effective C++
 https://qiita.com/shigural/private/97c163f2c2efa8ae1d92

##Effective Modern C++
 執筆中

##Effective STL
 執筆中

##C++ Coding Standards
 すべての内容が他の本でカバーできていた。

##リーダブルコード　より良いコードを書くためのシンプルで実践的なテクニック
 https://qiita.com/shigural/private/6d2d6caf3817f267ca5d

##ストラウストラップのプログラミング入門
 執筆中

##オブジェクト指向における再利用のためのデザインパターン（改訂版）
 https://qiita.com/shigural/private/660f66e1aaee61373c28

##プログラミング言語C++（第4版）
https://qiita.com/shigural/private/03348b3cb98ca828ea74

##ゲームエンジン・アーキテクチャ
 執筆中

##大規模C++ソフトウェアデザイン
 執筆中

##プログラマが知るべき97のこと
　執筆中
　参考：https://myenigma.hatenablog.com/entry/20110928/1317211887

##達人プログラマへの道
　執筆中
　参考：https://myenigma.hatenablog.com/entry/20130303/1362316040

##CODE COMPLETE 第2版
https://qiita.com/shigural/private/118d98fb0b737b471780

###大規模C++ソフトウェアデザイン
https://qiita.com/shigural/private/62b27adfff3089bdac78

### プレゼンテーション関連
https://qiita.com/shigural/private/dfb2b7c251b26feba29c
英語が苦手でもUdemyの英語の動画教材で学習する方法

# Udemyとは

Udemy（ユーデミー）はオンラインの有料動画学習サイトです。
IT系が充実していて、Udemyを利用している日本人エンジニアも多いと思います。
価格ですが、私が購入した動画や見たい動画は、価格は1～2万円ぐらいのコースが多かったです。なお、セールを実施していることが多く、90%引きで購入することも可能です（というかそれでしか購入したことがないです）。
ただし、日本の学習動画も増えていますが、英語の動画が圧倒的に多く英語が苦手な私（特にヒアリング）には敷居が高いサービスでした。


# 英語（特にヒアリング）が苦手でもUdemyを利用する方法

英語ヒアリングが苦手な私でもUdemyで学習できないかと調べてみたところ、Speechloggerというリアルタイム翻訳ソフトを見つけました。エンジニアは英語は必須だとは思いますが、リーディングができれば支障がでないことも多いため、ヒアリングが苦手な人も多いのではないかと思います（少なくとも私の周りはそういう方が多いです）。

やりたいことは、「動画に流れる英語を、英語のテキストに書き出し、日本語に翻訳する」です。
動画→VoiceMeeter→Speechloggerという流れでこれが実現できるので、以降で紹介します。
他に良い方法があれば是非教えてください。

# 翻訳環境を構築する

まず、翻訳環境を構築します。

## 環境

試した環境は以下のとおり。

- Windows 10（Windows7とかでも動かくかもしれませんが試していません）
- Google Chrome

ChromeはSpeechloggerの利用に必要になります。


## VoiceMeeterのインストール

VoiceMeeterは仮想オーディオデバイスです。これを利用して動画に流れる英語の音声をSpeechloggerにインプットし、翻訳します。

　https://www.vb-audio.com/Voicemeeter/index.htm

上のURLにアクセスすると以下のように表示されるので、「Voicemeter 1.X.X.X(EXE file)」をクリックします。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/179607/741086fa-1081-8635-3acc-726dd32bd8fb.png)

ダウンロードしたファイルを実行しインストールします。インストール後にWindowsを再起動してください。
これでVoiceMeeterのインストールは完了です。


## VoiceMeeterを有効にする

VoiceMeeterは仮想オーディオデバイスであり、インストール後にデバイスの設定を変更します。
Windows10では、以下のようにサウンドの設定を開き、出力デバイスと入力デバイスに「VoiceMeter」を選択します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/179607/8defab3d-0815-1f20-8b16-a3c2a3d6a6db.png)

それにより、「動画の音声」→「VoiceMeterのInput」→「VoiceMeterのOutput」→「Speechlogger」となるようです（たぶん）


## Speechlogger

SpeechloggerではGoogleのspeech-to-text技術を活用し、リアルタイムに音声認識と翻訳を行います。
まずは以下のサイトにアクセスします

　https://speechlogger.appspot.com/ja/

今回は英語から日本語なので、以下のように「English, US」、「Japanese」を選択し、自動句読点と翻訳をチェックします。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/179607/6deaa693-fe32-ec15-bcbb-fe59cb2a8386.png)

これで準備完了です。

# 動画を再生して翻訳する

動画を再生すると、左に音声認識した英語テキスト、右に翻訳した日本語テキストが表示されます。
今回はUdemyのプレビューの冒頭の動画を流してみました。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/179607/90469daf-b4d3-0fc3-efd1-4976f1918fed.png)
※最後のBrothers country rapは途中で音声認識を止めた影響なので、気にしないでください。

左の英語の認識はそこそこかなという印象。名前を「delete」と誤認識したので若干変な英語になっています。「the video may name is」と続いていることから、分の切れ目を認識するのも苦手なようです。
それでも、IT系は操作やソース等の音声以外の情報から読み取れる情報も多く、ヒアリングが苦手な人にとっては学習の補助として利用できるかと思いました。日本語の翻訳は元々の英語の認識がそこそこなので、若干厳しい印象です。左の英語を見て音声認識が間違っている個所を自分で補いつつ読んでみるとよいかと思いました。

# 最後に

まだ少ししか試していないので、これから利用を続けて、使えそうなら記事を更新していくかもしれません。
また、今回Udemyで試してみましたが、Speechloggerは動画の種類は関係なく利用できます。
ただし、Youtubeは独自の翻訳機能があるのでそちらを利用すればよいでしょう。
UnityのAndroid Build&Runができなくなったら考えること。



##過去の遺産を当たってみる。
Android Buildができなくなった際の対処方法の記事はいくつかあるので、まずはここを当たってみる。


おもちゃラボ　さんの
【Unity2018対応】Androidビルドでエラーが出る場合の対処法
http://nn-hokuson.hatenablog.com/entry/2017/09/05/202327

naichi's lab　さんの
【Unity、Android】最新のAndroidStudio入れたらUnable to list target platforms.が出て困った
https://blog.naichilab.com/entry/unable-to-list-target-platforms

@niusounds さんの
UnityのAndroidビルドができなくなった時の対処法
https://qiita.com/niusounds/items/bcbeee622b2114b4016e


私の場合は、これらでは解決しないレアケース？！でした。そして、意外なオチでした。

##Target Architecturesの設定

Build&Runをした際に以下のようなエラーメッセージが出るようになりました。
あれ？こんなの見たことない。。。。

![unity_error.PNG](https://qiita-image-store.s3.amazonaws.com/0/274029/d773c48d-130c-4b74-4c73-c986a804c00a.png)

Android SDK周りが悪さしているのだろうと、上記の記事を参考に対処しても状況変わらず。。

そこで、より詳細なエラーメッセージを確認できるため。
いったん、UnityでBuildしものを、コマンドプロンプトでinstall（UnityのRunの操作）をすることに。

```
> adb install -r C:\Users\xxxxx\Documents\apk\xxxxx.apk
> adb: failed to install C:\Users\xxxxx\Documents\apk\xxxxx.apk: 
Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]
```

ABIとは、
Application Binary Interface（アプリケーション・バイナリー・インタフェース、ABI）とは、アプリケーション（ユーザ）プログラムとシステム（OSやライブラリ）との間の、バイナリレベルのインタフェースである。（Wikipedia）

Failure [INSTALL_FAILED_NO_MATCHING_ABIS　というエラーメッセージで検索したところ、以下の記事が引っ掛かりました。
https://stackoverflow.com/questions/24572052/install-failed-no-matching-abis-when-install-apk

「INSTALL_FAILED_NO_MATCHING_ABIS is when you are trying to install an app that has native libraries and it doesn't have a native library for your cpu architecture. For example if you compiled an app for armv7 and are trying to install it on an emulator that uses the Intel architecture instead it will not work.」

「ARMのCPU向けとIntelのCPU向けに両方Buildできるんだけど、それがmatchしてないぞ！」

ということらしい。

そんな設定あったかなーと探してみたら、

![TargetArchtecture.PNG](https://qiita-image-store.s3.amazonaws.com/0/274029/793a24b4-a823-6f7b-d19b-1e746f200e89.png)

ここにチェックを入れると、正常にBuild&Runできるようになりました。

他の操作をしている際に誤ってクリックしてしまったのでしょう。汗
思いもよらぬ原因でしたが、動くようになってなによりです。
今から、すぐに、始める駅すぱあと路線図

[ヴァル研究所 Advent Calendar 2018](https://qiita.com/advent-calendar/2018/val) 6日目の記事です。
ブラウザ上で駅すぱあと路線図のプログラミングができる「駅すぱあとPlayground」を紹介します。

# はじめに
この記事は、「駅すぱあと路線図を試したいけど、キー発行依頼とかめんどくさい」、という人向けの、駅すぱあと路線図をすぐに試せる hello, world 記事になります。

※　この記事は個人の見解であり、所属する組織の公式見解ではありません。

# 駅すぱあと路線図とは
株式会社ヴァル研究所が提供している、鉄道の路線網を一枚絵にした路線図サービスです。
APIも提供されており、プログラマブルに扱うことができます。

詳しくは、以下のサービス紹介ページをご覧ください。
駅すぱあと路線図: http://rosenzu.strikingly.com/

また、触ってみるだけなら「[駅すぱあと for web](https://roote.ekispert.net/ja/rmap)」でも試せます。

# 駅すぱあと路線図で hello, world
今回は、駅すぱあと路線図の駅に「hello, world」というポップアップを表示することをゴールにします。

駅すぱあと路線図は、触るだけでも面白いですが、APIを利用して色々と可視化したり、その可視化をどうリッチにするかというのも面白さだと思います。
今回は、その一歩になる hello, world を、キー発行もなく、ディレクトリやファイルを作成することもなく試す方法を紹介します。

## 駅すぱあとPlayground
「駅すぱあとPlayground」は、駅すぱあと路線図で提供されている、Web上でコードを書いて、簡単に試せるオンラインコードプレイグラウンドになります。

駅すぱあとPlayground
https://rmap.ekispert.jp/playground/

では、早速試して行きたいと思います。
（ちなみに、駅すぱあとPlayground自体はとてもシンプルなので、細かい使い方の説明はここではしません。）

## hello, world
まず、[駅すぱあとPlayground](https://rmap.ekispert.jp/playground/)を開きます。

次に、[駅すぱあと路線図サンプル集](https://rmap.ekispert.jp/playground/)の[基本的なポップアップの立て方](http://rmap.ekispert.jp/sample/popup/popup_basic.html)から、テキストポップアップを立てる処理をコピーします。

■ コピーするテキストのポップアップを立てる処理のコード

```javascript
  // 2．文字列のポップアップ（飯田橋）
  // textPopupはHTMLタグ無効
  // ポップアップクラスを生成
  var text_popup = Rosen.textPopup();
  text_popup.setComment('飯田橋駅（いいだばしえき）は、東京都千代田区・新宿区・文京区にある、東日本旅客鉄道（JR東日本）・東京地下鉄（東京メトロ）・東京都交通局（都営地下鉄）の駅である。');
  text_popup.setAnchor("http://ja.wikipedia.org/wiki/%E9%A3%AF%E7%94%B0%E6%A9%8B%E9%A7%85");  // リンク先
  // 路線図にポップアップをセット
  rosen.setStationPopup(22507, text_popup);
```

コピーをしたら、駅すぱあとPlaygroundのコードの中で「駅がクリックされたら駅名を表示する」と書かれた部分と置き換えて、内容をちょっと書きかえます。。

■ 書き換えた後の内容（リンクは不要なので、削除しました。）

```javascript
    // 駅がクリックされたら駅名を表示する
    rosen.on("selectStation", function(data) {
      if (data.stations) {
        data.stations.forEach(function(station) {
          // ポップアップクラスを生成
          var text_popup = Rosen.textPopup();
          text_popup.setComment('hello, world');
          // 路線図にポップアップをセット
          rosen.setStationPopup(station.code, text_popup);
        });
      }
    });
```

これで、 `RUN` を押せば、左の路線図をタップすると「hello, world」がポップアップするようになります。

<img width="615" alt="スクリーンショット 2018-12-02 13.40.50.png" src="https://qiita-image-store.s3.amazonaws.com/0/31425/e1b90712-4852-7895-51f0-c2864a842e64.png">


#### ちょっと補足
以下の `station.code` は、タップした駅を指定しています。詳しくはAPIリファレンスを[参照](http://rmap.ekispert.jp/production/doc/document.html#rosen-setstationpopup)してください。

```javascript
rosen.setStationPopup(station.code, text_popup)
```

# 最後に
どうでしょうか。
これ以外にもサンプルコードをコピペすることで色々試すことができます。
また、キーを発行した後であれば、駅すぱあとPlaygroundの内容をそのままファイルに貼り付けて、キーを書き換えるだけですぐにローカルで実行することができるようになります。

とりあえず触ってみたい、そんな方にとてもオススメですので、ぜひお試しください。
復刊してほしいコンピュータ関連の技術書

# はじめに
　技術書をオススメしようと思っても絶版で入手しにくい書籍が多くあることがわかったので、復刊してほしいリストをまとめてみました。

# ソフトウェア開発設計関連
　　ダイクストラ先生、クヌース先生、カーニハン先生の本はどれもオススメなのですが、20世紀に出版された書籍は軒並み絶版になってしまっているようです。

-  [ソフトウェア作法][1]
[1]:https://www.amazon.co.jp/gp/product/4320021428

-  [プログラム書法 第2版][2]
[2]:https://www.amazon.co.jp/gp/product/4320020855

-  [文芸的プログラミング][3]
[3]:https://www.amazon.co.jp/gp/product/4756101909

-  [構造化プログラミング (サイエンスライブラリ情報電算機 32) ][4]
[4]:https://www.amazon.co.jp/gp/product/4781902766

-  [プログラミング原論―いかにしてプログラムをつくるか (サイエンスライブラリ―情報電算機)][5]
[5]:https://www.amazon.co.jp/gp/product/4781902863

-  [ライティングソリッドコード―バグのないプログラミングを目指して (マイクロソフトプレスシリーズ)  ][6]
[6]:https://www.amazon.co.jp/gp/product/4756103642

-  [注解 C++リファレンスマニュアル (アジソン ウェスレイ・トッパン情報科学シリーズ) ][7]
　C++初期の頃、理解にもっとも役に立った書籍
[7]:https://www.amazon.co.jp/gp/product/4810180271

# ハッカー向け
　他に類書が見当たらない本ばかりですが、ニーズが少ないのか、割と最近出版された本でもすぐに絶版になってしまうようです。

-  [ハッカー・プログラミング大全][11]
　バッファーオーバーフローを理解するのに、多分唯一と言っていい書籍
[11]:https://www.amazon.co.jp/gp/product/4887186339

-  [ハッカーズ大辞典 (Ascii books) ][12]
　ハッカーのセンスがわかる一冊
[12]:https://www.amazon.co.jp/gp/product/475614084X

-  [4.4BSDの設計と実装][13]
[13]:https://www.amazon.co.jp/gp/product/4756143466

# おわりに
　今でもオススメできる本ばかりで、いわゆる中古なら手に入りますが、できれば復刊してほしいと思います。
プログラミング初心者がProgate HTML&CSS初級編から学んだこと

では、ここでは「初心者がProgate HTML&CSS初級編から学んだこと」についてつらつら書かせていただきます。

でもまずは、プログラミングを初めてやってみて思ったことを書かせてください。
それは「プログラミングすごい！」ってこと。
だって僕らが毎日見てる色んなホームページとかって全部プログラミング技術で作られてるんですよね。こんなに生活になじみがあるものがどうやって作られているか知らず、しかも作り方も分からないっていうのは少し危機感を感じました。
これからどんどん勉強して、もっとプログラミングについて知っていきたいなって思います。
ではではそろそろ本題に・・・。

最初はHTMLに触れてみよう、ということで<ｈ>要素を使った見出し作りや、<ｐ>を使った段落の作り方を学びました。
聞けば<ｈ>はheading(見出し)の、<ｐ>はparagraph(段落)の略だそうで、それに関連付けると、覚えるのが楽になりそうです。
その他にはリンクや画像の貼り方などを学びました。

そして次はCSSを使い、先ほどHTMLで作った見出しや段落に書かれた文字の大きさ・色・配置などを整えていきます。
1つのプログラミング言語だけでなく、色々な言語が併用されて1つのサイトができているのも驚きですが、なんと厳密に言えばHTMLもCSSもプログラミング言語ではないそう。
もうなにがなんだか分かりませんが、勉強を進めつつちょっとずつ理解していきたいと思います。


そして苦労しつつもprogateの言われた通りにコードを書いていき、なんとか初級編をクリアできました。
でも、一度やっただけでは自分が何をしているのか、今書いているコードはレイアウトのどこに影響があるのかなんて全く分からず、説明なしでは絶対にクリアできませんでした。
きっと何周も何周もして、覚えていかないとダメなんですね。
先は長いですが、毎日前進していきたいと思います。

では、今回はこれにて。
Cloud Functions For Firebaseのローカル実行で、効率的にGoogleアシスタントアクションを開発しよう

## はじめに 
Googleアシスタントアクションを作る際、fullfillmentとしてCloud Functions For Firebase(以下、Cloud Functions)を使っている方が多いと思います。 いつも、デプロイしてActions Simulatorからリクエストを送ってE2Eテストばりのことをしてませんか? 
私はこの方法でやってきて、デプロイ完了までの時間と手間が非効率だと思っていました。。。

そこで、ローカル環境で試せる方法を調べたので、こちらにまとめて紹介します！ 

※ 注意: DialogflowとCloud Functionsを利用した開発環境を想定しています。

## Cloud Functionsをローカル実行する 
まずは、ローカル環境でCloud Functionsのエンドポイントを作りましょう。

`firebase serve --only functions`コマンドを実行することで、localhostで立てることができます。
Node.jsのバージョンが違うとwarningがでますが、Cloud FunctionsではNode.js v8も使えるようになっているので使う環境に合わせてnodebrew等でバージョンを合わせてあげるといいです。

```bash
$ firebase serve --only functions

=== Serving from 'xxx/xxx/xxx'...

i  functions: Preparing to emulate functions.
Warning: You're using Node.js v8.12.0 but Google Cloud Functions only supports v6.11.5.
✔  functions: main: http://localhost:5000/<endpoint-path>
```

## Dialogflow->Cloud Functionsのリクエストを再現する
エンドポイントができたので、あと動作確認をするためにDialogflowからCloud Functionsへのリクエストを作ります。
![post-data-dialogflow.png](https://qiita-image-store.s3.amazonaws.com/0/86747/7db86425-4607-b4f1-14bf-3364c14332a4.png)

- [Webhook request |  Dialogflow](https://dialogflow.com/docs/fulfillment/how-it-works#webhook_request)

こちらの公式ドキュメントにフォーマットがあるのですが、組み立てるのもなかなか面倒なので、実際に投げられているリクエストをコピーしてくるのが楽です。

### Dialogflowのリクエストをログ出力する
Cloud FunctionsのコードでDialogflowのインスタンス初期化時に`debug:true`を設定します。
これにより、Firebase consoleでリクエストやレスポンスのログを確認できます。
↓の図にある「Request」のJSONをコピーして、リクエストのサンプル用にファイルに書いておきましょう。

```js
const app = dialogflow({
  debug: true
});
```

![貼り付けた画像_2018_12_02_12_40.png](https://qiita-image-store.s3.amazonaws.com/0/86747/4c27dce1-41f9-ecbb-1dcf-1db14d988c84.png)

### リクエスト方法
localhostのエンドポイントにcurlでPOSTします。
POSTデータにDialogflowのリクエストが書いてあるJSONファイルを指定しましょう。
問題なければ、JSONレスポンスが返ってきます。最後に`jq`コマンドに渡して見やすくしています。


```bash
curl -X POST "http://localhost:5000/<endpoint-path>" -H 'Content-Type: application/json' -d @dialogflow-request-1.json | jq .
```
パターンを複数用意することで、いろんなパターンをローカルで試すことができます。

## まとめ
Dialogflowのリクエストを再現するのがちょっと面倒ですが、簡単に再現できました。 
Cloud Functionsのデバッグ時には、デプロイ完了までの待ち時間の省略・画面をポチポチする手間の削減できて、
より楽しくGoogleアシスタントアクションの開発ができるのではないでしょうか。

より簡単にDialogflowをローカルでモック化する方法があればもっと楽になるんだけどな。。
もしご存知の方がいらしたら、ご教授いただけると幸いです :pray:

## 参考資料
- [ローカルでのファンクションの実行  |  Firebase](https://firebase.google.com/docs/functions/local-emulator?hl=ja)
- [Google Assistant — Experiments – Jam3 – Medium](https://medium.com/@Jam3/google-assistant-experiments-2a71347d9a91)
Goでサーバー開発するときのMakefileを晒してみる

# はじめに
この記事は、[Go3 Advent Calendar](https://qiita.com/advent-calendar/2018/go3) の4日目の記事です。

Goで開発する際にはテストの実行やlintの実施といった細々としたコマンドを Makefile にまとめることが多いと思います。
これにはコマンド入力の手間を省くのももちろんですが、チーム内でコマンド実行の方法を統一するという意味もあります。「手元でのテストはReadmeに書いてある通りに実行してね」と伝えるよりも、Makefileにまとまってる方が親切です。

ということで、何番煎じか分かりませんが今回は業務で使っている Makefile を晒してみたいと思います。

ちなみに主に以下のツールを利用しています。

- パッケージ管理: [dep](https://golang.github.io/dep/)
- 自動リロード: [realize](https://github.com/oxequa/realize)
- DB migration管理: [goose](https://github.com/pressly/goose)

# Makefile
以下の物を使用しています。

```Makefile
setup:
	go get -u github.com/golang/dep/cmd/dep
	go get -u golang.org/x/lint/golint
	go get -u golang.org/x/tools/cmd/goimports
	go get -u bitbucket.org/liamstask/goose/cmd/goose
	go get -u github.com/oxequa/realize
	go get -u github.com/motemen/gore
	go get -u github.com/golang/mock/gomock
	go get -u github.com/golang/mock/mockgen
dep:
	dep ensure
lint:
	go tool vet app
	golint -set_exit_status app/...
fmt: lint
	goimports -w app
build: fmt lint
	go build -o dist/server app/server.go
run:
	realize start -n app-server
test:
	env ENV=test go test -cover -race -count=1 ./app/...
goose:
	goose up
	goose -env test up
setup-db: goose
	bin/mysql -T < db/dummy.sql
```

# 軽く解説
### setup
setupでは開発に必要なcliツールのインストールをまとめてやっています。
depではこういった実行ツール系の依存を解決できないため、このプロジェクトで使うツールの一覧をまとめるという意味もあります。

### fmt + lint
lint コマンドではgo vetとgolintによるコード解析をまとめて実施しています。分けて実施する意味もあまりないでしょうし。
fmtではgoimportsによるコードのformattingをしています。最初にlintを実施しているため、普段は`make fmt`とやってlintingもformattingもまとめて実施しています。

### test
testは何気に環境の指定やオプション指定などで暗黙知が生まれやすいコマンドだと思っています。
`-race`などは当然ciでもチェックしていますが、`push`前に手元でも見つけられるようにつけています。

ただしこの`make test`コマンドは`push`前の最終確認などで使うことが多く、開発中はvscodeやIDEの機能を使ってファイル単位でテストを走らせることが多いです。そのためどちらかというと利便性よりも網羅性側に切り倒して作っています。

### run
開発中のhot reloadのために[realize](https://github.com/oxequa/realize)を導入しています。ただし若干使い方が面倒なため、上の`setup`でrealizeを導入し`make run`コマンドで勝手に実行することで、新人さんなどがrealizeの存在を意識せず便利な開発環境が使えるようにしています。

# 終わりに
今回はプロジェクトで使用しているMakefileを晒してみました。
開発中に実行するコマンド類は暗黙知になりやすいため、出来るだけそのようなことが無いようにしていきたいと思います。
Vyper Compilerの使い方

# Ethereumとは

![Ethereum-Logo.jpg](https://qiita-image-store.s3.amazonaws.com/0/300943/f10a4016-7488-0730-700c-048fba1f1a3b.jpeg)

Ethereumはパブリックブロックチェーンネットワークです。Ethereumを使用すると、開発者は独自のDappを構築して展開できます。EtherはEthereumブロックチェーンの通貨です。Etherは、Ethereumネットワーク上で取引やサービスを支払うために使用されます。

Ethereumの詳細については、リンクを参照してください：
https://blockgeeks.com/guides/what-is-ethereum/
https://www.ethereum.org/

# Vyperとは

![Vyper.png](https://qiita-image-store.s3.amazonaws.com/0/300943/993a011a-65eb-dfa4-6cc9-04632779800e.png)


Vyperは、Ethereumブロックチェーンでスマートコントラクトを開発するために使用できる新しい言語です。Vyperはスマートコントラクトの作成プロセスを大幅に簡素化するように設計されています。VyperはSolidityと同じロジックを持ちますが、Pythonと同じ構文です。Vyperは2018年6月現在でもv0.1.0  - beta.1にあります！

## Vyper Compilerとは

Vyper Compilerを使用してVyperコードをコンパイルします。コンパイラを使用して、コードが正しいかどうかを確認します。 エラーがある場合、実行されません。

## Compilerの準備

Vyperは、Python 3.6以降を使用して構築することができます。Python 3.6をインストールする手順は次のとおりです。

**Ubuntu**

```javascript
sudo apt-get update
sudo apt-get install python3.6
```

**MacOS**

```javascript
brew install python
brew install gmp leveldb
```

**Installation**

```javascript
git clone https://github.com/ethereum/vyper.git
cd vyper
make
make test
```

## Vyper Compilerの使い方

コントラクトをコンパイルするには、以下を使用します:

```javascript
vyper yourFileName.vy
```

迅速に契約をテストできるように、Vyperは関数を即座に実行するためのコマンドラインツールを提供しています:

```javascript
vyper-run yourFileName.vy "yourFunction();" -i some_init_param, another_init_param
```

The vyper-run command is composed of 4 parts:

1. vyper-run
2. the name of the contract file you want to execute (for example: coolContract.vy)
3. a string (wrapped in double quotes) with the function you want to trigger, you can trigger multiple functions by adding a semicolon at the end of each function and then call the next function (for example: "myFunction1(100,4);myFunction2()") +
4. (Optional) the parameters for the __init__ function of the contract (for example: given __init__(a: int128, b: int128) the syntax would be -i 8,27).

vyper-runコマンドは、呼び出された関数の戻り値と、関数の実行中に出力されたすべてのログ出力を出力します。

Vyperを練習したい場合は、このリンクにアクセスしてください。https://vyper.online/

このリンクでVyperの詳細を知ることもできます：https://vyper.readthedocs.io/en/latest/
shallow clone したリポジトリのトピックブランチを後から fetch する

## TL;DR

```config:.git/config
fetch = +refs/heads/cool-topic-branch:refs/remotes/origin/cool-topic-branch
```

## shallow clone

`git clone` するときに巨大なリポジトリの全ての履歴を取得する必要はない, 最新版だけ取ってきたい, というような場合, `--depth` オプションを渡すことでそれを実現できます:

```
$ git clone --depth 1 https://github.com/pione30/example.git
```

`--depth` に指定する数字は取得したい最新 commit の数です.
このような clone を **"shallow clone"** と呼びます.

## shallow clone した リポジトリでの fetch

古いバージョンの Git では禁止されていたようですが, Git 1.9.0 からは [shallow clone したリポジトリに対する fetch ができるようになりました.](https://github.com/git/git/blob/master/Documentation/RelNotes/1.9.0.txt#L95-L100)
これでこそ通常どおり `pull / push` による開発ができるというものです.

しかし, 上記のように shallow clone を行った場合, リポジトリにトピックブランチが複数あったとしても, デフォルトではリモートの master ブランチしか追跡されません:

```
$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
```

なので, 例えば他の人が作成したトピックブランチを手元で検証したいというような場合, このまま単純に `git pull` してもそんなブランチは降ってこず, `git checkout` できなくて戸惑うことになります.

## Refspec

このときの `.git/config` を見ると, 以下のようなセクションがあるはずです:

```config:.git/config
[remote "origin"]
	url = https://github.com/pione30/example.git
	fetch = +refs/heads/master:refs/remotes/origin/master
```

これはどういう意味でしょうか? 公式ドキュメントを読んでみましょう:

> `.git/config` ファイルにセクションを追加して、リモートの名前（`origin`）、リモートリポジトリのURL、そしてフェッチする対象のrefspecを指定します。
>
> ```
> [remote "origin"]
> 	url = https://github.com/schacon/simplegit-progit
> 	fetch = +refs/heads/*:refs/remotes/origin/*
> ```
>
> refspecの書式は `<src>:<dst>` で、その前にオプションとして `+` を指定できます。ここで `<src>` はリモート側の参照に対するパターンで、 `<dst>` はそれらの参照がローカルで書きこまれる場所を示します。 `+` は、fast-forwardでない場合でも参照を更新するようGitに指示しています。
>
> (中略)
>
> 常にリモートサーバー上の `master` ブランチのみをプルして、それ以外のブランチはどれもプルしたくない場合は、fetchの行を以下のように変更します。
>
> ```
> fetch = +refs/heads/master:refs/remotes/origin/master
> ```
>
> (中略)
>
> 設定ファイルに、フェッチ用のrefspecを複数指定することもできます。 もし、常に `master` ブランチと `experiment` ブランチをフェッチしたいならば、以下のように2行追加します。
> 
> ```
> [remote "origin"]
> 	url = https://github.com/schacon/simplegit-progit
> 	fetch = +refs/heads/master:refs/remotes/origin/master
> 	fetch = +refs/heads/experiment:refs/remotes/origin/experiment
> ```
>
> _引用元: [10.5 Gitの内側 - Refspec](https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-Refspec)_

まさに "`master` ブランチのみをプルして、それ以外のブランチはどれもプルしたくない" ような状態になっていたのでした.
というわけで, 特定のブランチを `pull` の対象に含めたいときは

```config:.git/config
fetch = +refs/heads/cool-topic-branch:refs/remotes/origin/cool-topic-branch
```

のような fetch の行を `[remote "origin"]` セクションに追加すれば良いことになります.
いまさらですがLinuxで環境変数を設定したい

いまさらですがlinuxで環境変数を設定するときのいろいろです。

##環境変数とシェル変数
変数を設定したい、というとき、変数には2種類あります。
それが**環境変数**と**シェル変数**です。
この2つは設定の方法が違います。また、変数が適応される範囲(スコープ)も異なります。
以下、`NAME` といういう変数に `Taro` という値を保持例で説明します。

###シェル変数
```bash
1  $ NAME=Taro
```
このプロセス内でのみ変数は有効となります。
子プロセスには引き継がれません。このプロセスから新たにプロセスを立ち上げても、新たに立ち上げたプロセス内ではNAME変数は参照できません。

###環境変数
```bash
1  $ NAME=Taro
2  $ export NAME
3  # OR
4  $ export NAME=Taro
``` 
子プロセスでも変数を参照することができます。このプロセスから新たに立ち上げたプロセス内でもNAME変数を参照できます。
しかし、子プロセス内でNAME変数の値を変更しても親プロセス内でのNAME変数の値は変わりません。子プロセスが立ち上がるときに変数がコピーされるイメージです。

環境変数の説明コードに書いてあるように、シェル変数を定義し、その変数をexportすることでも環境変数となります(1、2行目)。
4行目のようにまとめて書くこともできます。

##設定した環境変数を表示する

###echoコマンド
```bash
$ echo $NAME
```
`echo`コマンドは引数でもらった値を表示することができます。
変数の中身を表示するときには、変数の前に`$`が必要です。

###printenvコマンド
```bash
$ printenv
```
環境変数にのみ対応しています。引数なしで実行することで環境変数の一覧を表示することができます。
また環境変数名を引数に渡すことで中身を見ることができます(`$`はいりません)。

###envコマンド
```bash
$ env
```
環境変数にのみ対応しています。引数なしで実行することで環境変数の一覧を表示することができます。

###setコマンド
```bash
$ set
```
環境変数とシェル変数の一覧を表示することができます。

##変数の削除
```bash
$ unset NAME
```
環境変数も、シェル変数も削除することができます。
`$`はいりません。

##毎回設定するのは面倒
上記の設定方法だと、ターミナルを立ち上げる度に変数を設定する必要があります。
設定ファイルに書くことで、毎回手動で設定する必要がなくなります。

linuxにはいくつか設定ファイルが存在し、読み込まれる順番やタイミングが決まっています。
詳しくは以下の記事を・・・
https://qiita.com/yunzeroin/items/480a3a677f78a57ac52f
https://qiita.com/magicant/items/d3bb7ea1192e63fba850

`~/.bash_profile`に環境変数、`~/.bashrc`にシェル変数を書いておきます。
以下、環境変数の例です。

```bash
# .bash_profile

NAME="Taro"
export NAME
```

これで、ログインするときにこの環境変数が設定されます。

※~/.bash_profileに書いただけでは読み込まれません。一度ログアウトしてログインしなおすか、以下のコマンドを実行します。

```bash
$ source ~/.bash_profile
```
【CSS】うにょうにょしたメタモンが作りたかった..【円をうにょうにょ】

息抜きがてらに読んでください(ﾟｰﾟ)
ポケモンやってたら野生のメタモンが出てきたので、CSSでメタモン作ってみました。
個人の技術不足な部分と、CSSだけだと限界があるなあと感じた瞬間でもありました...

## メタモン
ポケモンをやったことある人ならほとんどの人が知っているポケモンですね。
ピカチュウに変身した<a href="https://www.pokemon.jp/zukan/detail/132.html">メタモン</a>が好きです。
<img width="204" alt="スクリーンショット 2018-12-02 0.44.19.png" src="https://qiita-image-store.s3.amazonaws.com/0/302304/94310c3c-bb2e-bec6-431a-5d6975ef9239.png">
参照：<a href="https://www.pokemon.jp/zukan/detail/132.html">メタモン｜ポケモンずかん｜ポケモンだいすきクラブ</a>


## まずは、うにょうにょさせたい
メタモンはうにょうにょなイメージがあります（主観）

CSSの`border-radius` と CSS animationの組み合わせで
うにょうにょした円が作れます。

うねうね
![モニョ.gif](https://qiita-image-store.s3.amazonaws.com/0/302304/f210d83a-7385-e63b-43b1-4a0e305bf464.gif)

中身はこんなかんじです。

```style.scss
div {
  animation: unyo 3s linear alternate infinite;
}

@keyframes unyo {
  0% {
    border-radius: 50px 90px 60px 80px;
  }

  50% {
    border-radius: 80px 70px 90px 50px;
  }

  100% {
    border-radius: 90px 50px 80px 90px;
  }
}
```

## CSSメタモン
先ほどのうにょうにょを使えば、
うにょうにょ感がでるメタモンが作れるんじゃないかと思ってせっせと作っていました。

う...うにょうにょ....?????
<p data-height="410" data-theme-id="0" data-slug-hash="YRBLRa" data-default-tab="css,result" data-user="deren2525" data-pen-title="CSS Metamon(Ditto)" class="codepen">See the Pen <a href="https://codepen.io/deren2525/pen/YRBLRa/">CSS Metamon(Ditto)</a> by Deren (<a href="https://codepen.io/deren2525">@deren2525</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

円を7つくらい用意して合体しています。
アニメーションは7つとも統一です。バラバラな動きをしているようにみえますが、7つとも微妙に角度が違うのでバラバラな動きに見えるかんじです。
`border-radius`も、フレームも、細かくしています。正直、こんなに細かくすることもなかったなとも思っています。

```style.scss
@keyframes metamon {
  0% {
    border-radius: 60px 90px 70px 80px / 80px 90px 70px 60px;
  }

  10% {
    border-radius: 50px 70px 90px 60px / 60px 90px 70px 80px;
  }

  20% {
    border-radius: 70px 60px 80px 90px / 90px 80px 60px 70px;
  }

  30% {
    border-radius: 50px 70px 90px 60px / 60px 90px 70px 50px;
  }

  40% {
    border-radius: 80px 60px 70px 90px / 90px 70px 50px 80px;
  }

  50% {
    border-radius: 90px 50px 60px 70px / 70px 60px 80px 90px;
  }

  60% {
    border-radius: 60px 70px 80px 90px / 90px 50px 70px 60px;
  }

  70% {
    border-radius: 70px 90px 60px 50px / 80px 60px 90px 70px;
  }

  80% {
    border-radius: 60px 80px 70px 90px / 90px 70px 80px 50px;
  }

  90% {
    border-radius: 80px 70px 90px 60px / 60px 90px 50px 80px;
  }

  100% {
    border-radius: 90px 50px 70px 80px / 80px 70px 60px 90px;
  }
}

```

## まとめ
`canvas`でやればもっと細かい動きができるかなと思います。
作っていて、CSSでは限界があるなあと感じました。

だいぶ不恰好なメタモンになってしまいました...すまねえ...

## 追記（2018/11/09）
新たなメタモンが生まれていました。ありがとうございます。
私のメタモンよりもメタモンでした。勉強になりました！
[インスパイアされて『うにょうにょしたメタモン』を描きたくなった。](https://qiita.com/boseki/items/a41305456e5ff329d533#_reference-d1ffeec82d633bdb2427)
Markdown マークダウン という書き方、とても簡単、敬遠せずに使ってみよう!!

# マークダウン (Markdown) とは

文章の書き方の一つです。

まずはWikipediaより

- [Markdown \- Wikipedia](https://ja.wikipedia.org/wiki/Markdown)

こちらの記事も分かりやすいのでお薦めです

- [情報系以外の方にもおすすめしたいMarkdown \| 東京工業大学デジタル創作同好会traP](https://trap.jp/post/371/)


# Markdown の利用状況

Markdownという書き方(記法)ですが、いわゆるIT系エンジニアの間では10年以上前に登場した後、その扱いやすさもあって、急速に普及し、現在では多くのブログなどでも利用出来る書き方(記法)の一つとなっています。

とはいえ、まだまだ一般化しているとは言い難く、やはり「なにこれどうやって書くの、使えない」と言った意見も多く耳にします。

勿体ないです。

簡単に覚えられて、今後も利用機会も増加すると思いますので、是非この機会に興味を持って頂きたいです。


# Markdown どこで練習すれば良いの?

[HackMD](https://hackmd.io/)というメモなどを簡単に作成出来るサービスがあります。

ここで存分に練習出来ます。


HackMDに関しては、日本語の解説記事も多くありますので参考になると思います。

- [HackMD](https://hackmd.io/)
- [HackMDってMarkdownEditorが革新的で使いやすい \- Qiita](https://qiita.com/norinity1103/items/85aa990dbe6582b6d701)


また、QiitaにはHackMDというタグもありますので参考にしてみて下さい。

- [HackMDに関する9件の記事 \- Qiita](https://qiita.com/tags/hackmd)




# とにかくお薦めです

実はMarkdownに限らず、IT系エンジニアの中では他の書き方(記法)も多くあります。かつては乱立していた時代もありますが、今は文書作成に関してはMarkdownが主流になっています。

まずは3つほど覚えれば十分だと思います。

- ヘッダ(見出し)
- リスト
- 引用


結果的にMarkdownを覚えていれば使えるサービスも増えます。

ぜひ、挑戦してみて下さい。

実はQiita自体、記事の作成にはMarkdwonが必須(他の書き方は選択出来ません)なのでした ^^;

- [Qiita マークダウン記法 一覧表・チートシート \- Qiita](https://qiita.com/kamorits/items/6f342da395ad57468ae3)
- [Markdown記法一覧 \- Qiita](https://qiita.com/oreo/items/82183bfbaac69971917f)
- [Qiita Markdown 書き方 まとめ \- Qiita](https://qiita.com/shizuma/items/8616bbe3ebe8ab0b6ca1)
- [Markdown記法 サンプル集 \- Qiita](https://qiita.com/tbpgr/items/989c6badefff69377da7)
ローカルのプロジェクトをGitHubにアップロードするまで

#はじめに
過去に作ったコードをGitHubにあげておく必要が出来たものの完了まで時間を要したので、次回以降スムーズに運ぶよう備忘録として手順を記録します。（なお、他の方の記事のほぼ引き写しです。）

##前提
GitHubのアカウントは作成済みとする。
Windowsはgitクライアントをインストール済み。スタートメニューからGit Bashで使用。

#手順
ここから順に作業を列挙します。（思い出しながらなので順番が入れ替わっている可能性あり）
## SSHキーの生成
ローカルのマシン毎に生成しました。（GitHubに登録するキーとなりますが、あまり多く作らない方がいいか？）

```sh:
hoge@hoge-PC MINGW64 ~
$ ssh-keygen -t rsa
```
デフォルトではホーム下の```.ssh```ディレクトリにid_rsaとid_rsa.pub（公開鍵）が生成される。
unix系の参考資料だと、鍵id_rsaのパーミッションを```chmod 600 id_rsa```しますが、Windowsなので```ls -l```してもパーミッションは変わりません。
パスフレーズは入力推奨。

##SSHのconfigファイル作成
.sshディレクトリに設定ファイル```config```を作成します。

```:config
Host github
  Hostname github.com
  User git
  IdentityFile ~/.ssh/id_rsa
```
キー生成の際、ファイル名を変更している場合、IdentityFileのファイル名を合わせる事。

##GitHubに公開鍵を登録する
gitコマンドでGitHubにPushするため、GitHubに公開鍵を登録する必要がある。
生成されたキーファイルのうち.pubファイルの中身をエディタ等で開いてコピーし
GitHubの鍵登録画面
https://github.com/settings/keys (もしくはGitHubのSettings -> SSH and GPG keys)
で、Key欄に張り付け。
タイトル欄に識別できるようPush元のマシン名などを記載。(WinとかRaspberry Piとか）

##Gitのユーザー情報を登録（初回のみ）

```:
git config --global user.name "tarou"
git config --global user.email "tarou.yamada@gmail.com"
```

（2019/04/04追記）```$ git config --list```で登録されているconfig変数を参照できます。

##改行コードの自動変換設定(Windowsのみ)
WindowsからPushする際、改行コードの自動変換が挟まれて色々あるようなので、変換を無効にしておく。

```:
git config core.autocrlf false
```

##GitHubへのSSH接続の確認
GitHubへのPushの前に接続ができるか確認しておく。

```:
ssh github
```

.sshにconfigファイルを作ってあれば、これだけで接続確認ができる。（この記事を書いている際、鍵ファイル名をデフォルトから変更していたことを忘れていてconfigの```IdentityFile```の記述がファイル名と違っていたため、複数回Permission Deniedされました。）



##GitHubにリモートリポジトリを作成する
GitHubにリポジトリを作成する。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/18822/327c40df-fa9a-7532-01ee-e01788985961.png)
この際、READMEの初期化チェックを付けずにリポジトリ作成をした方が、この後の手順が例示されるので楽。（勘違いかもしれないが、初期化するとこの後のPushが上手くいかず、リポジトリの削除・作成を繰り返した。）
![image.png](https://qiita-image-store.s3.amazonaws.com/0/18822/0f61fffd-1e20-023c-cc74-2d375b76cd8b.png)
以降は、リポジトリ作成後に表示されるこの画面の情報”…or create a new repository on the command line”どおりに実行する。
（ちなみにHTTPSではなくSSHの情報を使う）

##プロジェクトのフォルダをGit管理下に
（先にechoでREADME.mdファイルを生成しておく。）
プロジェクトのディレクトリに移動した後、以下のコマンドでGit化する。

```:
echo "# my_project" >> README.md
git init
```

##プロジェクトの全ファイルを追加、コミットする

```:
git add -A
git commit -m "commit comment"
```

##プロジェクトのリモートリポジトリを設定する
プロジェクトに対応するリモートリポジトリを以下のコマンドで設定する。

```:
git remote add origin git@github.com:kcha4github/my_project.git
```

###（間違えた時）リモートリポジトリを変更するには
（一時、SSHと間違えてHTTPSを入力してしまったので以下のコマンドで修正した。）

```:sh
$ git remote set-url origin git@github.com:kcha4github/my_project.git
```

##リモートリポジトリへローカルのプロジェクトをPush
ローカルのプロジェクトをGitHubにPushします。

```:
git push -u origin master
```
上手くいけば、プロジェクト内のファイルがGitHubのリポジトリにアップされます。

#参考サイト
ローカル作業フォルダをGIT管理下においてGitHubにPUSHするまで
https://qiita.com/riversun/items/dac05d7fd9ac304dffa9
gitのremote urlを変更する(レポジトリ移行時)
https://qiita.com/minoringo/items/917e325892733e0d606e
今日からはじめるGitHub 〜 初心者がGitをインストールして、プルリクできるようになるまでを解説
https://employment.en-japan.com/engineerhub/entry/2017/01/31/110000
MacBookへのgit導入とGitHub運用

ようやくgitとGitHubを使えるようになったので忘れないようにメモしておきたいと思う。
内容としてはかなりの初心者向けになる。
前提条件１：作業環境はMacBook
前提条件２：[Homebrew](https://qiita.com/is-lab/items/e0443b79da117ed48294)をインストール済み
前提条件３：[GitHub](https://github.com)にアカウント登録済み

#gitのインストールからGitHubへプッシュするまで
まずはgitをインストールする。
`$ brew install git`

インストール完了したらgitのバージョンを確認しておこう。
`$ git version`

```
git version 2.19.2
```

次にgitの初期設定だ。
`$ git config --global '[ユーザー名]'`
`$ git config --global '[メールアドレス]'`

これでgitの初期設定はOKだ。

次にGitHubでリモートリポジトリを作り、gitに登録しよう。
※git側からはGitHubのリポジトリは作れない（あるいは私が方法を知らないだけ）
`$ git remote add origin [リモートリポジトリのURL]`

GitHubの次はローカル環境にリポジトリを作ろう。
`$ cd [リポジトリ管理したいフォルダ]`
`$ git init`

※作成したリモートリポジトリをクローンしてもいいようだ（`$  git clone [リポジトリのURL]`）。

では先ほどローカルリポジトリを作ったフォルダにファイルを作ってみよう。
おすすめはreadme.txtだ。
作成できたらファイルをgit管理に追加しよう。
`$ git add [作成したファイル名]`

ちゃんとgitに追加されているか確認しよう。
`$ git status`

コミットを行う。
コミットで送られるのはGitHubではなくローカルリポジトリということに注意。
`$ git commit -m '[コメント]'`

完了したかどうか一応確認しておこう。
`$ git status`

ではpushしてみよう。これでようやくGitHubにファイルを共有することができる。
`$ git push -u origin master`

```
Username for 'https://github.com': [GitHubのユーザーネーム]
Password for [自分のGitリポジトリURL]:　[GitHubのパスワード]
```

最後にブラウザなどで自分のGitHubアカウントにログインしてリポジトリを確認してみよう。
うまくファイルが共有できていればOKだ。

※実際のプロジェクトではブランチを切ったりプルリクエストを送ったりマージしたりといった作業が必要になるらしいが、それらは次回に回すことにする。

#各コマンドの意味
それぞれのコマンドについてざっくり意味を確認しておこう。

`$ git config --global '[ユーザー名]'`
`$ git config --global '[メールアドレス]'`
こちらはgitの設定を操作するコマンドだ。
gitの設定には`system`、`global`、`local`の三層があり、左から右に行くほどスコープが狭くなるらしい。
最初は`global`で設定しておけば十分だろう多分。

`$ git remote add origin [リモートリポジトリのURL]`
gitはリモートリポジトリ（ここではGitHub）とローカルリポジトリで相互にバージョン管理を行う仕組みだ。
そのリモートリポジトリとして`origin`という名前でURLを設定している。
ちなみにリモートリポジトリURLの設定は`$ git remote -v`で確認できる。

`$ git init`
ローカルリポジトリの作成と初期化を行う。
ターミナルの作業フォルダをバージョン管理したいフォルダにしておくことを忘れないように。

`$ git add [作成したファイル名]`
コミットするファイルを追加するコマンドだ。
この後に`$ git status`することで変更を確認できるので、こまめにやっておくと達成感が得られて楽しい。

`$ git commit -m '[コメント]'`
ローカルリポジトリに対しコミットを行う。
`$ git add [作成したファイル名]`で追加した対象のファイルがコミットされ、ローカルリポジトリのファイルが更新される。

`$ git push -u origin master`
リモートリポジトリに対しローカルリポジトリへのコミットを適用するコマンド。
上でも書いたが、gitはリモートリポジトリとローカルリポジトリで相互にバージョン管理を行う仕組みだ。
これでようやくGitHubのファイルが更新され、リモートリポジトリとローカルリポジトリで同じバージョンのファイルを持つこととなる。
ちなみに`origin`ではリモートリポジトリURLを、`master`ではプッシュするブランチの名前を指定している。
今回はブランチが存在しない状態のため、新たに`master`のブランチが生成されている……はずだ。

###参考資料
[Git の基礎勉強 〜Git によるバージョン管理を使う〜](https://tracpath.com/bootcamp/learning_git_firststep.html)
[GitHub登録からプッシュまでの流れ](https://qiita.com/KosukeQiita/items/cf39d2922b77ac93f51d)
[ローカルでgitを使用した後、gitHubに登録する方法](https://qiita.com/koshihikari/items/dcf126fa9c0de2b6fa7e)
[【GitHub超初心者入門】この前初めてGitHubを使い始めたエンジニア見習いが書くGitHubの使い方と実践～とりあえず一緒に動かしてみようぜ！～](https://qiita.com/nnahito/items/565f8755e70c51532459)
[Git/GitHubレベル別オススメ学習サイトまとめ完全保存版【2018.11】](https://qiita.com/think-a-lot/items/b3c2e9060f46f5d4ea46)
rubyでlambda

# この記事はOIC ITCreate Club Advent Calendar 2018の3日目の記事です。

こないだ
上司に「lambdaいいっすよlambda」と言ったら
「それrubyで書けるの？」と言われ、ぐぬぬとなっていたのですが
lambdaがrubyをサポートしたとのニュースが入ったので
早速試してみようと思います!

## 早速作成

いつも通り関数の作成を押してランタイムを選ぶと....!?
<img width="685" alt="スクリーンショット 2018-12-02 12.07.33.png" src="https://qiita-image-store.s3.amazonaws.com/0/134140/7ec9b47a-468e-de80-3a4e-e5bf865d4395.png">

ふおおおおおおおお！
Ruby 2.5がありゅううううううう!!!
<img width="691" alt="スクリーンショット 2018-12-02 12.07.40.png" src="https://qiita-image-store.s3.amazonaws.com/0/134140/c8cbf2bb-4f9e-b941-60f8-b1186b8e63c7.png">

こんな感じでできました~
<img width="779" alt="スクリーンショット 2018-12-02 12.08.34.png" src="https://qiita-image-store.s3.amazonaws.com/0/134140/9ca71230-4ef4-c63e-3552-33a0a9041e78.png">

## 考察
rubyでlambdaが書ける。
きっとみんながハッピーになる。

## 結論
amazon is god.

## 展望
時間があるときに
googleでgasを使ったapi公開と
awsでlambdaを使ったapi公開の手順を比較した記事を書こうかなと思います。

### 参考リンク様
[Announcing Ruby Support for AWS Lambda](https://aws.amazon.com/jp/blogs/compute/announcing-ruby-support-for-aws-lambda/)
[日本で 128 番目くらいに Ruby で AWS Lambda を試したメモ](https://qiita.com/inokappa/items/a8c4de8610d653577718)
SHA-1/SHA-2とは何か、SSLのどこで利用されているのか

# SHA-1, SHA-2はハッシュ関数  

ハッシュ化とは、元のデータから一定の計算手順に従ってハッシュ値と呼ばれる規則性のない固定長の値を求め、その値によって元のデータを置き換えること。チェックサムによく用いられるmd5もハッシュ化のひとつ。

# SHA-1, SHA-2がSSLのどこで使われているか

サーバから送付された証明書が正しいものであるかどうかを照合するために利用する。
具体的には、サーバ証明書に付与された署名（サーバ証明書をハッシュ化し、認証局の公開鍵で暗号化したもの）を復号した内容と、Webサーバから受信したSSLサーバ証明書をハッシュ化した値を比較するのです。この値が一致すれば、信頼のおける認証局から署名を受けた正規のWebサイトであることがわかります。

# SHA-1, SHA-2の違い

- SHA-1  
任意の長さの元データを元に160ビットの値を生成するハッシュ関数
- SHA-2  
SHA-1を改良したもの。SHA-224、SHA-256、SHA-384、SHA-512の4つのバリエーションがあり、末尾の数字がハッシュ値のビット長を表す。最長であるSHA-512が最も安全性が高いですが、一般的にはSHA-256が最もよく利用されている。SHA-2への移行が推奨されている。
- SHA-3  
SHA-2よりも安全性を向上させるために、2015年に公開された後継の規格となる。「SHA」との名称を引き継いでいるものの、内部構造などが異なるなど、SHA-2とは別系統として設計されているのが特徴とされる。今後、SHA-3の利用が増えていく可能性が見込まれている。


# 参考サイト

- [5分でわかるSSL通信　SHA-1、SHA-2の違いとは？](https://geechs-magazine.com/tag/lifehack/20160822_2/2)
- https://eset-info.canon-its.jp/malware_info/special/detail/211013.html
知っていると便利! Ceph 開発環境の作り方

# Ceph開発環境とは?
Ceph のように複数のサーバをまたいで稼働する分散システムは、動作検証やちょっとしたパラメータ修正を検証したい際でも動作環境を構築するのが、とても手間がかかります。

このような手間を小さくする方法として、Ceph では、開発環境を簡単に構築するための script を利用することができます。本ドキュメントでは、script を使って1台のホスト上に Ceph 開発環境を構築する手順について、まとめます。

# 何が便利なの?
例えば、Ceph の設定パラメータを tuning したいときに、効果や影響を見たいときに Ceph 開発環境が手元にあれば、すぐに評価ができて便利です。
また、Ceph 開発環境は Debug log がデフォルトで沢山出力されるようになっているため、プログラムの動作パスを追って動作の仕掛けを勉強する用途にも向いています。

## 参考情報
* Mimic (ceph version 13.x)
  - http://docs.ceph.com/docs/mimic/dev/quick_guide/
  - http://docs.ceph.com/docs/mimic/dev/index-old/
* Luminous (ceph version 12.x)
  - http://docs.ceph.com/docs/luminous/dev/quick_guide/
  - http://docs.ceph.com/docs/luminous/dev/index-old/
* Jewel (ceph version 11.x)
  - http://docs.ceph.com/docs/jewel/dev/quick_guide/
  - http://docs.ceph.com/docs/jewel/dev/index-old/

# 開発環境の作り方

## OSパッケージの初期インストール
次のパッケージを始めにインストールしておきます。

* Ubuntu18.04
    * ```sudo update```
    * ```sudo apt install build-essential cmake python-tox```
* CentOS7
    * ```sudo yum update```
    * ```sudo yum install git cmake gcc-c++ python-tox```

## ソースコードのダウンロード及びビルド

```
git clone https://github.com/ceph/ceph
cd ceph

# Jewel の場合
git checkout jewel

# Luminous の場合
git checkout luminous

# submodule を checkout する
git submodule update --init --recursive

# build を実施する
./run-make-check.sh
```

## 開発環境を起動する

### Jewel の場合
```
cd src
./vstart.sh -d -n -x
```

### Luminous の場合
```
cd build
make vstart
../src/vstart.sh -d -n -x
```

## 動作確認

### Jewel の場合
```
# status 確認
./ceph osd pool stats
./ceph osd pool stats cephfs_data
./rados df

# rados write テスト
./rados mkpool mypool
./rados -p mypool bench 10 write -b 123

# rados file upload テスト
./rados -p mypool put objectone <somefile>
./rados -p mypool put objecttwo <anotherfile>
./rados -p mypool ls
```

### Luminous の場合
```
# status 確認
bin/ceph -s
bin/ceph osd pool stats
bin/rados df
bin/rados mkpool mypool
bin/rados -p mypool bench 10 write -b 123
```

## 開発環境を停止する

### Jewel の場合
```
./stop.sh
```

### Luminous の場合
```
../src/stop.sh
```

## fio ベンチマーク

### Jewel の場合
```
./rbd create --image-feature layering --size 10240 test01
CEPH_CONF=./ceph.conf fio --direct=1 --rw=randwrite --bs=512 --ioengine=rbd --pool=rbd --rbdname=test01 --thread=1 --group_reporting=1 --time_based=1 --numjobs=1 --iodepth=128 --runtime=120 --randrepeat=0 --norandommap=1 --refill_buffers=1 --name=randw
```

# まとめ
Ceph 開発環境を使えば、bluestore やスケールアウト性能を検証するのは難しいですが、あまりハードウェアやネットワークには依存しないような内容についてはお手軽に検証ができてとても便利です。
お手元の AWS EC2 など、Public Cloud に Ceph 開発環境の EBS Volume を用意しておくのも良いかもしれません。必要な Spec としては、Volume 100GB、memory 8GB以上(swap 併用でもOK)、CPU 4VCPU以上 程度あれば問題なく動作しそうです。
いい感じにUnixtimeに変換するSPAを速攻で作った

この記事は[@HibikineCode 1人Advent Calendar](https://adventar.org/calendars/3251)2日目の記事です。

---

みなさん、UnixtimeってGoogleで調べたことありますか。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/152713/193c08fc-91d5-e190-d8be-976d307d261d.png)

一番上に出てくるツール、ぼくもよく使っています。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/152713/4534370c-d3ca-299e-9c3d-c7353863874a.png)

ところがこれ、SPAじゃないんですね。Enterキーを押さないといけません。フロントエンドエンジニアのみなさんは入力したら結果が出てほしいですよね？(脅迫

というわけでSPA化します。

## 仕様

* 変換したい時間を入力し、入力終了後1秒後にサーバーに送信する。
* 送信された文字列をPHPのstrtotimeに投げて結果を返す。
* 結果を**<font color="red">い</font><font color="goldenrod">い</font><font color="yellowgreen">感</font><font color="cornflowerblue">じ</font>**に表示する。

# 作った

https://hibikine.me/unixtime/

## スタック

* React
* Material-ui
* TypeScript
* Parcel
* PHP

## コード

[GitHub](https://github.com/HibikineKage/unixtime/)

動かすまで30分、体裁整えるのに数時間ってとこ。

サーバーサイドはPHPの`strtotime()`に投げてるだけです。

# 雑感

思ったことをつらつらと。

## Parcelはこういう開発にめっちゃ向いてる

Parcel使うと**`ts`ファイルインポートするだけ**で勝手に`yarn add --dev typescript`がバックグラウンドで走るので、何も環境構築しなくてもコードが書けます。超便利です。
`import React from 'react'`って書くと`yarn add react`が走ります。TypeScriptの型定義ファイルだけは自動で入れてくれないので、それだけ手動で`yarn add --dev @types/react`します。

最初見るとめっちゃ感動します。同僚も「Parcelは知ってたけど**ここまでとは思わなかった**」ってビビってました。

こういう小規模でパパっと作るときにはめちゃくちゃ便利です。自分のやり方に合わせるよりParcel式に合わせた方が良いです。

## やっぱDocker便利

とりあえずこういう時に`docker-compose.yml`をパパっと書けば速攻で開発用PHPサーバー立てられるのはDockerの強みですね。まあ`php -S localhost:8000`でも別にいいですが。

## まとめ

<font color="red">**ParcelとTypeScriptは絶対流行らせろ**</font>
react-railsでRailsにReactを導入する

#概要
Railsの一部にReactを使うためにreact-railsを利用しました。
バージョンの違いでつまずいたので、共有します。

#参考にした記事
 [react-railsを使ってReactのTutorialをやってみる](https://qiita.com/joe-re/items/96f12dda4a62470d1d7c)
2年前の記事なので少し古いですが、generatorなども含め丁寧に説明されています。前のバージョンだとこれが正のようです。
基本的にはこれに沿って進めると良いですが、そのままコピペするとうまくいかなかったので、注意が必要です。

#環境
- ruby 2.5.1
- rails 5.2.1
- react-rails 2.4.7

#バージョンごとの書き方の違い
##以前
```app/assets/javascripts/components/comment_box.js.jsx
var CommentBox = React.createClass({
  render: function() {
    return (
      <div className="commentBox">
        Hello, world! I am a CommentBox.
      </div>
    );
  }
});
```
##React15.5以降
React.createClassが非推奨となり、別パッケージに分かれたため、その影響によりreact-railsで`React.createClass`が使えないようです。
下記の参考記事にも書いてありますが、代わりに`createReactClass`を使うと良いです。
generatorでComponentを作成すると、自動的に新しい書き方になっています。

**つまり、`React.createClass`→`createReactClass`に書き換えるとうまく動きます。**

参考記事：[今からはじめるReact.js〜propsとstate、それからrefs〜](https://qiita.com/kuniken/items/a22adda392ccc30011b1)

#余談
generateorで作成すると拡張子が`.js.jsx`になりますが、これは`.jsx`に書き換えても大丈夫でした。
またコンポーネント名とファイル名は一緒でなくても大丈夫です。
重要なのは下記です。
- `rails g react:install`でcomponents.jsが作成される、application.jsにrequireが追記されること
- `rails g controller [コントローラ名]`で自動作成したコントローラがapplication_controllerを継承すること

#さいごに
Reactはバージョンの変化による影響を受けやすいので、[React公式tutorial](https://reactjs.org/tutorial/tutorial.html)を見るなどして定期的に追っていく必要がありそうです。
うまくいったときに、なぜうまくいったのか&うまくいかなかったのかを分析することは重要ですね。
SSL証明書を切らした話

もはや常時HTTPSが当たり前となっている環境ではありますが、HTTPSで注意しないといけないこととして、証明書の期限があります。

## 期限はなんのためにある？

まず大前提として、ふつうのコンピューターの暗号は、鍵が128ビットであれば可能なパターンは $2^{128}$ 通りしかないので、何も考えなくても全部試せば、理論的には解読可能です。

ただし、 $2^{128}$ は膨大な数で、毎秒1兆通り試せたとしても $10^{19}$ 年と、宇宙の寿命すら超越しかねない期間がかかってしまうため、現実的に総当たり攻撃は成立しません。SSLに使う暗号も、このような**計算量的安全性**に基づいています。

ということで、同じ鍵を使い続けることはそれだけ解読される危険が上がるということにもなりますし、また別な側面として使っている暗号の脆弱性が発見されることも考えられます。ということで、証明書はある程度のところで期限を切って、暗号方式や鍵をそこで強制的に見直させるようになっています。

## 証明書の更新について

まず、OVやEVといった、ドメイン以外の要素についても認証を行うようなものは、当然ながら機械的な処理だけで進まないので、人力による作業がどこかしら入ってくると思います。

DV証明書については、いろいろな方法があります。

* DNSのレコードに特定の値を書いておいて、それを確認する方法
* 当該のドメイン以下にHTTPでアクセスして、特定のURLに特定のファイルが置いてあるか確認する方法
* メールアドレスで確認する方法

ものによっては、自動化が可能ですし、AWSのACMなどでは半永久的な自動更新も実現していたりします。

## 実際に切らしてしまうと

諸事情があって自動化のシステムを組まずにLet's Encryptを使っていて、そしてそのまま期限の到来を忘れてしまいました。もちろんWebシステムは証明書エラーを起こすという事態に見舞われてしまいました。

## 対策

自動更新できるならそれ用のシステムを組んでしまったほうがいいですし、メール認証などでそれがかなわない場合には、証明書の期間を見てどこかでリマインダを仕掛ける、といった仕組みも必要かもしれません。
チームのモチベーションに繋がる4つの取り組み

### はじめに
社内で開発チームのリーダーをやっています。
最近勉強会で「どうやってメンバーのモチベーションをあげているか」
という話が話題になることがあったため、自チームでの取り組みをいくつかのせてみます。

前提として、以下のようなことがモチベーションを下げない、もしくは上げることに繋がると考えています。あまり学術的な「定義！」というものではなく、筆者の感じていることです。

- ストレスがたまりづらい、働きやすい環境がある
- 納得性のある仕事が出来ている（本人にとって価値のある仕事ができている）
- 主体的に仕事が出来ている

### おしながき
- KPT会
- ミーティングDay
- 1 on 1
- リモート
- まとめ

### ■KPT会
##### 概要
週に1度、作業の振り返りをします。
以下の3種類の付箋を用意します。


Keep：良かったこと、続けたいこと
Problem：悪かったこと、改善したいこと
Try：KeepとProblemから、これからチームとして取り組みたいこと。具体的な改善案

全員で、それぞれの付箋を書き、最後に投票により、次にやる「TRY」を決めます。

##### 良いところ
- 「こうしたらいいのに」という悶々としたわだかまりを解消する場が明確にある
- リーダーからの指示をやらされる側になるのではなく、主体的にやり方を決めやる側になりやすい
- 仮にTryが出来なくても、「チームでこの課題を認識していて、なおしていこうと思っている」というポジティブな印象を抱ける（「どうせ変わらないでしょ」といった感覚になりづらい）

##### 気をつけていること
- KeepとProblemはTryのネタを思いつくための「アイデアの種」なので、どんなに突拍子のないことを書いてもOKにしている
- Tryは必ず具体策とし、毎週2～3件、絶対にやる。「やりたいね」を確かめるだけの場にしてしまうと、目には見えづらい価値のMtgになる
- Tryには担当者をつける。誰がこの仕事を進めるのかが明確になり、ちゃんと改善が回る
- Tryのために業務の時間をちゃんと取る。「時間がある時に自主的にやっといて」はNG。「自主的にやって」はいつできるかわからない。他の仕事の速度を落とさず無理矢理進めると、仕事量が増えるし、改善タスクに対して悪印象を抱く

### ■ミーティングDay
##### 概要
毎週火曜日にMtgを集中させています。
筆者のチームでは、火曜日に以下のMtgがあります。（開発プロセスにはスクラム開発を採用しています。）

- 一週間の成果発表
- KPT会（振り返り）
- 次の一週間にやるタスクの見積のMtg（プランニングポーカー）
- 次の一週間にやるタスクの決定のMtg
- やるタスクの要件等、開発に関する不明点の整理のためのMtg

##### 良いところ
- Mtg、コーディング、Mtgなど、時間が切り取られると、集中しづらく、せっかく仕事がノってるのに...ということが少なくなる
- Mtgは大体が「何かしらの決定」を目的としており、それを一日にまとめることで、不明点を出来る限り火曜に解消できる。結果、残りの4日は決めたことをやるだけという状態になり、仕事がしやすい

##### 気をつけていること
- メリハリをつけるため、ガッツリ時間をとる。（うちのチームでは火曜日の5～6時間程度をおさえています）
- 不明点を出来るだけ減らすため、タスクは細かく分ける。（うちのチームでは、1タスク1時間までにしています）


### ■1 on 1
##### 概要
隔週で30分、リーダーとメンバーで、1対1で話をします。
話す内容は特に決めていません。人ごと、その時ごとに内容は変えています。
具体的には、フランクなことを話すこともあれば、今チームや会社に対して思っていることや、悩んでいることを話すこと、個人のキャリアについて議論する場合などもあります。

##### 良いところ
- リーダーとメンバーの距離が近いと、報告（特に悪い報告）などがしやすくなり、精神的なストレスをためづらい
- 皆がいる場では言いづらい、意見や困っていることなどを言う場が定期的にあるため、精神的なストレスをためづらい
- メンバーのモチベーションの元、考えていることがわかりやすくなる結果、メンバーにとって価値のある、納得性の高い仕事を任せやすい

##### 気をつけていること
- 1 on 1は基本的に「メンバーのための時間」なので、どんな内容でも、メンバーがもってきてくれた話が最優先
- 海外の1 on 1だと「メンバーに話したいことを持ってきてもらう」というのを推奨しているところも多いが、人によっては話したいことが本当になかったりするので、話すネタはリーダーも用意する
- お互いに対する信頼が無いと、思っていることを打ち明けづらいので、無理に引き出さない
- 30分は目安。せっかく大切な話をしてくれている場合、延長してでも聞いた方がいいので、なるべく後ろの時間は空けておく

[参考]
話すネタなどは結構世の中に転がってます（英語のものが多いですが）
https://jasonevanish.com/2014/05/29/101-questions-to-ask-in-1-on-1s/
https://getlighthouse.com/blog/one-on-one-meeting-questions-great-managers-ask/

### ■リモート推奨日
##### 概要
弊社では元々、必要がある際にリモートOKというスタンスなのですが、リモートをする人、しない人に分かれて、差がうまれてしまいます。そこで、「皆ある程度やってみれば？」ということで、月曜、水曜をリモート推奨日としています。

##### 良いところ
- そもそも「リモートをやってみたい」という気持ちをもっている人が少なからずいて、推奨することで、「リモートを取ってみたいけど取りづらい」という人が、行動にうつれる
- メンバー全員がリモートを実際することで、リモートする側の気持ち、メリットデメリットがわかる
- 集中して仕事ができる。副次効果的に、不要なミーティングを削減しようという意識が強くなる。

##### 気をつけていること
- 「リモートだから」で、Mtgをスキップしたり、先延ばしにしない
- 工数や、進捗の見える化が前提としてあると良い。リモートしていない側の「仕事をちゃんと進められているのか？」という疑念と、「そう思われているんじゃないか？」という余分な思いを払拭できる

### まとめ
以上4つの取り組みをあげました。
これ以外もいくつかあるのですが、説明できるかどうかなどを含め、上記4つを今回は選びました。

今回紹介した仕組みは、必ずしも「チームメンバーのモチベーションをあげるぞ！」という思いから始めたわけではありません。やってみたら、モチベーションの向上に繋がったなーということが多いです。

モチベーションが上がったかどうかに関しては、1 on 1でメンバーと話した内容を元にしているので、必ずしも全員のメンバーのモチベーションがこれで爆上がりした！というわけではないですが、何か取り入れてみたい！という方の参考になればと思います。
nuxtでのcss設計

# componentに書かれたcssはグローバルにきく

componentに書いたcssはグローバルにきく。基本的にはcomponentに記述すればok。

# components内に留めたいときはscoped

そのcomponentのみに効かせたい場合はscopedをつける

```javascript
<style scoped>
</style>
```

# 1ファイルにまとめたいならnuxt.config.jsをいじる

componentsにcssを書いていけばいいが共通のものをどこか1ファイルに纏めたくなった場合はnuxt.config.jsに下記の記述。app.scssにまとめる。

```javascript
module.export = {
  css:[
    "~/assets/scss/app.scss"
  ],
}
```