This repository is to write my result of daily learning
Jenkins⇒Slackで通知を飛ばす方法を学んだ。
参考：https://qiita.com/ryuthky_github/items/c7e68fba13ddf230159a
JenkinsとSlackのそれぞれの設定ページで連携を設定すると1 vs 1の紐づけができる。 ただし、この設定だとjenkinsジョブから1つのチャンネルにしか通知を飛ばせない。
Slack側の連携ツール「Incoming webhooks」を使用する。 通知を受け取るためのアプリケーションであり、Add Configurationすることで、Slack通知の送付先（End point）をURLの形で得られる。 このIncoming webhooksの設定を送信したいチャンネルの数だけ生成して、それぞれに対してcurlでメッセージを送ることで実装したい機能を実現する。
curl -X POST --data-urlencode "payload={\"text\": \"TEST\" }" https://~~
参考：ドキュメントのチュートリアル部分 https://fabric-ja.readthedocs.io/ja/latest/tutorial.html
pythonの機能をシェルスクリプト的に実行するためのツール(remote execution tool)である。
pythonで記載した関数（ex. deploy）をfab deployなどとコマンドライン城で実行するだけで機能させることができる。
scriptであり、ここからさらにローカルでのコマンド実行やリモートでの操作を誘発できるのでできることはかなりい多い。
上記のチュートリアルでも、一つのコマンド実行でテスト→gitへのpush→deployまでを実現している。。
タスクへの引数も渡しやすく作られている。 他、参考：https://qiita.com/momota10/items/030d12449f36d788a5b7
rebase運用が履歴の改変をするため危険ということは理解している。
ここではgit pull --rebaseの話
https://www.lancard.com/blog/2016/11/07/git-rebase-and-pull-rebase/
見る限り基本的には問題なさそう？？？
とはいえ立派な宗派争いみたいだ。 rebaseは基本的に履歴を改変して見栄え的に綺麗な形につくり変えるものと理解して良さそう。 個人的な感覚としてはあまりやりたくはないかな
https://medium.com/@kihapper/欧州の都市における-ものごい-をデザインする-557581521f3b
物乞いが尊厳を取り戻せる仕事とは？という試行実験の中でストリートディベートというより大きな問題にアプローチできる手法を発案したという話。 もちろん、同じことが日本でできるかというと、議論をする土壌がないため難しいかな、というところ。
でもこれこそが複数の問題を一挙に解決する”アイデア”という概念そのものだよね、というわかりを得た。
こういう発明はどのように生まれるのか？ このケースだと日常で見つけた身内の困難を解決したい一心で試みた施策の一つについて別の解釈をするとこういう手法になるよね？って解釈できたケース。 もしかしたら別の人の目を通した時に「これってこうじゃね？」と解釈が生まれたのかもしれないし、試行の中で通りがかった人の反応を見て気づいたのかもしれない。
参考：http://aimstogeek.hatenablog.com/entry/2018/01/17/154537 とはいえキャッシュの話がまだまだわからない。 使い分けとしてはここが参考になりそう：https://academy.gmocloud.com/know/20160125/1584
brew install tmux
これだけで使える！
Ctrl+b -> % で分割 Ctrl+b -> d で切断 tmux a でセッション復帰
Google Apps Script 参考：https://qiita.com/t_imagawa/items/47fc130a419b9be0b447 Chromeの拡張機能として導入できてDrive上のコンテンツと連携できるみたい。 なお連携できるのはContainer Bound Scriptのみの模様
Googleが公開しているライブラリもあるみたい！：https://github.com/gsuitedevs/apps-script-samples
ひとまず参考：https://www.oracle.com/technetwork/jp/ats-tech/tech/useful-class-7-520780-ja.html 大型Webシステムの運用時のパフォーマンス測定基準が書いてあるので参考にできる気がする。
- 同時接続ユーザー数(Number of Virtual Users)
- 時間あたりのユーザーシナリオ実行本数(Transactions per hour)
- 時間あたりのページ処理数(Received pages per hour)
- 時間あたりのヒット数（Hits per hour）
- サーバー平均応答時間(Average Server times, etc.)
- サーバー側のCPU使用率
1.はいわゆるDAU（Daily Active User）だから、ユーザーにIDがあれば基本的なアクセスログから抜き取れる。ソシャゲなら一種のKPIとして使われてるはず。 でも、ログインボーナスだけのユーザもいるから直接1.をシステムのパフォーマンス良し悪しの判断基準にすることは危険よなぁ
2〜4はサーバの処理性能として役立ちそう。 2, 3の差分が若干わからなかったけどページに含まれるコンテンツ量でもって判断するとよいようで納得。 コンテンツの大小にページ間で差があって、読み込みでかかる負荷が変わる場合はヒット数を使うそう。
逆にヒット数という指標はユニークなユーザ数が得られない環境においては、平均ヒット数でもってユーザ数の推定に使えるそうな あとはDBアクセス数も別の負荷基準として使えるか。 5.はクライアント側が存在する環境だと、ユーザ側に依存する部分が大きいからサーバ側を最速にする以外の対応はできないなぁ。
とはいえ、テスト環境と本番環境だと性能差があるから信頼できる測定値ってむずいなぁ
コマンドでの測定はこっちhttps://qiita.com/toshihirock/items/0e0b20064730469e93e6
https://tutorial.perlzemi.com/blog/20100507127089.html ひとまずプロファイラというツールの使い方や使用感はやってみて覚えるとする。
あとアウトプットについて、ちょっと気になる記事に行き当たったので https://note.mu/fromdusktildawn/n/nb7ee5a557447
アウトプットの出し方の部分でちょっと思い当たる節がありすぎるので変えていきたい。 実践を通してこそを理解として初めてアウトプットを生成する、ってすればどうにかモノになるか…？
https://go-tour-jp.appspot.com/welcome/1
5/8 時点でMethods and interfacesの手前まで進行中。-> とりあえず5/17くらいまでで全体を見切った
ResearchMap作成に取り組んだ？ってやつ
オンラインコース「教育のゲーミフィケーション」受講者募集のお知らせ https://ludixlab.net/?p=22
もっと早く調べていれば…って感じが漂う。 参考；http://digrajapan.org/
GDC2019の報告会っぽい公開資料 https://www.igda.jp/?p=9699 参考；GDC https://www.gdconf.com/
仕事でperlの単体テスㇳ、proveをちょっと見てたので気になって調べてみた。 https://www.infiniteloop.co.jp/blog/2014/03/beginners_test/
prove弄ってみないことにはあまりわからなそうだけどメリットは
がポイントな模様 proveの資料は : http://perl-users.jp/articles/advent-calendar/2011/test/21
https://blog.manj.io/entry/20181221/1545318000
を参考に。日本語切り替えを Ctrl+j。元にもどす時は lなので異様に速い
ただし漢字変換がかなり弱いのでオンライン辞書との連携は必要かもしれない
コーディングの際は便利かもしれないが、今みたいに日本語の文章を打つ場合はもっさりする
Windowsは システムキー + Space で切り替えできるのでつどつどで
Referenceはココ！