Zenn
📌

2021-05-24週覚え書き

2021/05/28に公開
#
memo
tech

その日に読んだ記事をざっとリストアップしたもの

2021-05-27

  • https://speakerdeck.com/mathetake/isolated-multiple-trust-domain-mtls-in-envoy-and-istio
    • envoyとIstioのサービス間での通信の信頼性を担保する仕組みの説明と、それをマルチクラスタ構成に拡張した時の問題それを解決する仕組みについての説明
    • セキュリティに興味が湧いてきたところだから気になるけど、まだ分からないところが多い
  • https://speakerdeck.com/mathetake/wasmdeguang-garuenvoytoistiofalseshi-jie
    • wasmをEnvoy、Istioで採用するまでの流れとこれからの課題と展望
    • 細かいところは把握しきれてない
    • wasmもEnvoy/Istioも興味があるからそれぞれもう少し深掘りしてみたい
  • https://codezine.jp/article/detail/14062
    • Engineers in VOYAGEに記載されていた技術的負債を返済するためのアプローチに関するデブサミ2021のセッションレポート
    • それぞれのアプローチのメリットデメリットと実例が挙がっていて分かりやすかった。本の方も泥臭いところがしっかり書かれていて実感を持って読めたからおすすめ。
  • https://nostarch.com/art-webassembly
  • https://www.slideshare.net/hiroiso/zgc
    • JVMのパラメータ調整を自動化しつつ、GCログを可視化してトレンドを把握しやすくした話
    • パラメータの調整はOptunaを使っていたらしい。確かにMLに限らずパラメータ調整の分野ではトライしてみてもよさそう。
    • 組み合わせの最適化だと量子コンピューティングもあるけど、そっちとOptunaを比較したらどんな感じになるんだろ？
  • https://theupdateframework.io/
    • pipやyumなどをソフトウェア更新システムとカテゴライズしていて、その更新システムに対する攻撃を防ぐためのフレームワークらしい
    • 例えば、攻撃者が古いバージョンを新しいバージョンだと偽ってインストールさせたり、同じファイルを渡しつづけて実質的に更新できないようにしたりするらしい
    • ざっと読んだだけだとどこがスコープなのかが把握しきれなかった
  • https://plus.qconferences.com/plus2021/presentation/resilience-supply-chain-security
    • サプライチェーンセキュリティに関するQCon plusのセッション
    • 弾力性を持ったサプライチェーンセキュリティを構築することの重要性とその方法を解説していた
    • が、英語のヒアリングが弱くてあまり内容を聞き取れていない
  • https://codezine.jp/article/detail/14114
    • フィーチャーフラグの仕組みとそれを利用したプロセスの例について説明している、シリーズの1回目
    • デメリットも挙げられていて採用を判断する際に参考になりそう
    • 実際に採用した時のイメージが持てていないので、これからの説明で具体的な事例を期待
    • なんだかんだ新しい仕組みはコストがかかるので、プロジェクトやチームの特性に合わせた向き不向きが分かるような情報があると嬉しいかもしれない
  • https://www.docker.com/blog/dockercon-live-2021-registration-is-now-open/
    • DockerCon、始まってるけど時間も時間だし後でオンデマンドで見られるやつを見る
  • https://toris.io/2021/04/speeding-up-amazon-ecs-container-deployments/
    • Amazon ECSでコンテナの起動を高速化するためのノウハウ
    • GKE触っていた時の体感だとコンテナは起動速度に拘って損はないので、困ったらこの記事を思い出してざっと読んでみるといいかもしれない
      • 起動速度の面でかなり強いので、JVM系の言語よりも直接バイナリにコンパイルする言語が採用されるのも分かる

2021-05-28

  • https://www.fastly.com/blog/quic-is-now-rfc-9000
    • QUICが標準化されたらしい
    • FacebookがQUICを適用するまでに数年かかったらしいけど、標準化されてエコシステムがそれなりに揃ってくると思うしもう少し短い期間で色んなサービスに導入されるかな？
    • HTTP/2に切り替えたケースだと、用途によっては思ってたよりも効果がないみたいな話を聞いたけど、今回はトランスポートレイヤーから影響あるから影響大きいかな？
  • https://os.phil-opp.com/
    • RustでOSを作ってみよう！ってページ。Rust触ってみる時にやってみよう
  • https://blog-dry.com/entry/2020/11/02/000313
    • Rust on 組み込みの話を聞いた時に出てきた '!' の細かい説明をまとめた記事
    • Rustがよくわかってないのでまだピンと来ない。Rustを素振った後に戻ってこよう
  • https://www.amazon.co.jp/dp/4863543379
    • 上と同じくRust on 組み込みの話を聞いた時にお勧めされた本。読みたい。
  • https://docs.github.com/en/issues/organizing-your-work-with-project-boards/managing-project-boards/changing-project-board-visibility
  • https://servicemesh.es/
    • サービスメッシュをプロダクトごとに比較している
    • 機能が充実してそうだから、サービスメッシュを一通り試してみたいならIstioかな？実際に使うと（バグの影響もあるけど）リソースがかなり必要だったから業務に導入する時には立ち止まりたいけど。
  • https://www.infoq.com/jp/articles/service-mesh-ultimate-guide/
    • サービスメッシュについて整理されていてかなり参考になった
    • 触ったことがないと実感をもてないところもあるかもしれないけど、サービスメッシュとはなんぞや？と思っている人は一読して損はないと思う。
    • 将来的には、大きいSI案件だと基盤チームが作るような機能をサービスメッシュで担当するようになるのかな？
  • https://note.com/miyaccchi/n/n71945eaf38a5
    • UXライティングという領域の話
    • 「プロダクト内での目的の達成を、テキストでサポートすること。」がUXライティング
    • ユーザのことを考えて適切に技術を用いてプロダクトの目的を達成する、というのは他の領域（技術とか）にも当てはまるから、プロダクト志向の組織にはハマりそう
    • ちょっとしたテキストでもユーザビリティの向上につながることはありそうだし、頭の片隅に置いとこう
  • https://be-ars.colopl.co.jp/team/cloud_spanner.html
    • コロプラがSpannerを導入した経緯が分かる記事
    • 基準があると技術選択の属人性が少しは抑えられそうな気がするけど実際どうなんだろう（尖った技術はやっぱり俗人化せざるを得ないだろうけど
  • https://aws.amazon.com/blogs/quantum-computing/hello-quantum-world/
    • AWSが量子コンピューティングに関するblogを立ち上げたよって記事
    • 色々書いてるけど、機械学習を導入する過程でエコシステムを整備する必要があったから量子コンピューティングの領域では実用化される前にそのあたりの整備を進めるよ！ってのが積み上げてるなーって感じがして面白かった
    • 2月の記事だから、キャッチアップしつつ追いつきたい
  • https://zenn.dev/uji/articles/f6ab9a06320294146733
    • Goのポインタの特徴と使い所がまとまってる
    • よくわかってなかったからためになった
  • https://learning.oreilly.com/library/view/learning-go/9781492077206/
    • Goのイディオムがなぜそうなっているのかを背景の考え方なんかから書いている本
    • ポインタの話なんかも書いてたし、全体的に振り返ってみたい時におすすめ
  • https://qiita.com/imoty/items/c1017099e63cd4630946
    • GoのGCでオーバーヘッドが大きい場合の回避策を紹介している記事
    • GCが大きそうな時に思い出すといいかも
  • https://bells17.medium.com/things-you-should-know-about-reading-kubernetes-codes-933b0ee6181d
    • タイトルの通り、Kubernetesのコードを読む時に知っておいたほうがいいこと
    • CRDを作ってみた時の経験とだいたいあってるけどやっぱり広い範囲の知識が必要だなぁ。。。
  • https://go-vargo.booth.pm/items/1566979
    • CRDを作った時に参考にしてた本
    • 今のバージョンだとそのまま写経するのは難しいかもしれないけど、Kubernetesの仕組みが理解できたしお勧め
  • https://www.infoq.com/jp/articles/optimizing-mlops-enterprise-ai/
    • AIを最大限活用するためにはMLOpsをきちんと整備するのが大事って話とそのための仕組みの紹介
    • AIを改善しつつプロダクションで利用するには専門性の高い複数の領域が協働する必要があり、複数の領域に強い人は少ないため詳しくない領域に踏み出さないといけない人がいるとそこがオーバーヘッドになる。それを防ぐには、それぞれが得意な領域に集中できるようにするため、MLの改善が最適なサイクルで回るような仕組みを整備しないとね、という話
    • ちょろっとだけML周りに関わった時に感じた課題感と同じ。次の機会があったらこの記事思い出そう。
GitHubで編集を提案

Discussion