http://techblog.lclco.com/entry/2017/12/29/211627
danger.import_dangerfile を利用して、組織独自の共通チェックを切り出しておくのは良さそう。
ただ、受託の会社で、各案件で利用しているチケット管理ツール・運営方法などが違ってる場合には、「共通チェック」として切り出せるものはかなり限定的になりそう。。？
https://cloud.google.com/apis/design/?hl=ja
もともとあったドキュメントが、最近日本語化された感じ？
gRPCの話だったら、個人的にはあんまり使わないかなーと思ったけど、REST APIの話も含まれているっぽいので、あとで読む。 結構ボリュームありそう。。。
https://employment.en-japan.com/engineerhub/entry/2018/04/03/110000
ソニックガーデンの方の記事。
「ルールを決める」ってのは確かに重要ですね。また、そのルールを定期的に確認・レビューしていくのも必要ですね。（スプリントの開始・終了あたりのタイミングとか？）
コードレビュー数ランキング、面白そうだと思ったけど、弊社だとお客さん環境でレビューしてたりするので、平等なランキングを作るのは難しそう。自社organizationだけランキング、なら作れるかも？
「質問する」という前提も共有しておく必要がありますね。
海外のエンジニアとやり取りすることが多いので、「Why did you use XXX instead of YYY?」とか書いた時に煽ってると勘違いされない関係性の作成が必要。（英語力が足りない、ってのもある）
https://dev.classmethod.jp/cloud/aws/secrets-manager/
RDSへの接続情報ローテーションを、簡単に設定できるのか。
それと、個別のkey : valueを設定しておいて、AWSのSDKを利用して取得してこれるっぽい。 Vaultと同じようなイメージかもしれないけど、全部をAWSが管理してくれるのは楽ですね。 「機密情報１つあたり、$0.40/月」 ってのは、地味に高いかもしれないですが。。
https://dev.classmethod.jp/ci/simple-branch-tag-operations-with-circleci-manual-approval/
dev.classmethod.jp/ci/simple-bran… 個人的には、2の方法にしちゃうことが多いかなぁ。 PRの形にしておけば、その差分が見えるし。（たいてい、量が多くて見てないけど）
ただ、Manual Approvalは良さげ。何かのタイミングで使ってみよう。
https://diary.app.ssig33.com/347
「どっかで見たと思うんだけどどこにあるか思い出せない」みたいな情報も「自分が見た範囲内から検索」ができるとあっさり見つかったりします。
これがしたかった。 ただ、PDFまでは考えてなかったなー。 Google driveと連携させるってのも頭良いな。
https://dev.classmethod.jp/cloud/aws/amazon-elasticsearch-service-kibana-user-authentication/
ようやくKibanaにログイン機能が！ 昔、一瞬使ってみたときは認証周りがめんどーだったので止めたことが。。
cognitoを使うっぽい。こっちもまともに使ったことないので、一度やってみたいなー。
https://note.mu/cocod3/n/n4e910ec83b60
単純にsketchの始め方としてもいい記事。 デザインセンスが壊滅的なので、こんな感じでトレースしてったら、いい感じのデザインが出来るようになるかな。。優先度の問題はあるけど。
http://yuroyoro.hatenablog.com/entry/2018/04/03/112830
実際の業務で使わないとしても、関数型の思想に触れておくことは大事かも。
https://inside.dmm.com/entry/2018/04/03/kotlin-custom-lint
いろんな人とチームを組んで開発しようとすると、コードレビュー以前に機械的にチェックしたいものは増えてきますよね。 また、Android標準のLintの仕組みに追加でき、Android Studio上に出てくるのは良いですね。
実装するためのおまじない？準備？はそんなに多くない印象で良いのですが、 PSIの構造を把握して、チェック処理実装に落とすのが難しそうな印象。
http://www.orangeitems.com/entry/2018/04/02/202052
・不正アクセスは起こってみるとだいたいが稚拙なところを狙われている。技術的には高いレベルではない場合が多い。いわゆる戸締りを忘れたぐらいなレベル。しかし攻撃者は全部のドアを開けようとしてくるからタチが悪い。ドアを設けないのが一番のセキュリティー対策。
大事ですよねー。
ただ、サービス止めたり、ログが多く出る設定にしたりってのは、サービス特性によっては難しい気がする。 （そもそも、そのへんの検討すらしてない、ってのはまずいでしょうけど。。）
にしても、「社外の専門家により構成される調査委員会を設置」とか、ちゃんとしてる感がすごい。固い系企業？のこういうところは見習わないといけないのかも。
https://medium.com/inuscript/vue-and-react-comparision-6c7cb44f18ba
誤解を恐れずに言うと、Reactはsimple寄りで、Vueはeasy寄りというのが近いかなと感じている。
これがわかりやすいですね。 React単独で考えると、少ないAPIを覚えるだけで良いけど、結局Reduxとかを使ったりで悩みが出てくる。 それを超えると、SFCなんかで役割をきれいに分割しつつ、大規模にも耐えやすい。
逆にVue.jsは便利なAPIがいろいろあって、そのへんをうまく使っていけば、簡単に構築できる。 公式のライブラリも充実していて、それを利用するだけである程度のものが作れる。
というイメージがあるだけで、ちゃんと実装したことがあまり無いので、ちゃんとやらないとなぁと。 また、変化の速度も速そうなので、式年遷宮していきつつ、手を動かしていかないと付いていけないですね。
https://dev.classmethod.jp/server-side/elasticsearch/site-search-in-corporate-site/
“サーチテンプレートによる検索のエンドポイントのみをパブリックに開放” ってことが出来るのか。知らなかった。 フロントから直接ES呼んじゃうってのは、ちょっと不安があるけど、調べてみよう。
https://speakerdeck.com/shibe97/osushinijian-ruhurontoendofalsesekiyuritei
ちゃんとして復活したのがすごい。 ヘッダの話とか、めんどくさがらずにちゃんとやらないとなー。
https://qiita.com/YusukeIwaki/items/3fb4e10ac87fa1c7f6ba
MediatorLiveData が何者か、そのうち調べる。
https://inside.pixiv.blog/usa/3841
あんまり観測してなかったんですが、脆弱性がいろいろ公開されてたんですね。 WEBrickのサーバーを迂闊に公開せず、信用できない値をそのまま使わない。ってことですかね。 兼業でRubyも書く自分にとっても、ゆるい感じで分かりやすくてよかった。
http://blog.shibayu36.org/entry/2018/03/29/183000
負債と一言に言っちゃうけど、その中にはいろんな選択があって、そこから引き起こされる問題も、その解消方法もちがうよね。 分類して、対応規模・緊急度を可視化出来れば、機能実装との優先度付けもできそう。 なるほど。
https://speakerdeck.com/operando/dezainfalseshi-zhuang-wojie-ti-suruji-shu
後半のapk引っこ抜くあたりはグレーな気がするけど、adbコマンドでいろいろ出来るってのは勉強になった。