Svelteを使ってみる

svelte.jp

初手はここでよさげ。

svelte.jp

TODO

  • turborepoでの各Appごとの依存パッケージ管理の方法を調べる

  • 新しいプロダクトの名称を考える

  • hoge/hoge-front的にsvelteのディレクトリとAppの初期ファイルを生成して準備する

  • wired elementライブラリを使用できるようにする

積読消化:「The DevOps ハンドブック」

  • イントロダクション

  • 第1部 3つの道

  • 第2部 スタートのための糸口
  • 第3部 第1の道:フロー改善の技術的実践
  • 第4部 第2の道:フィードバックの術的実践
  • 第5部 第3の道:持続的な学習と実験の技術的実践
  • 第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践

第5部から読んでいく。

第5部📝

継続的な学習

実験の技術的実践

できる限りスピーディかつ頻繁に低コストで学習する機会を創り出す実践を説明する。

  • 安全を実現するジャストカルチャー(公正な文化)を確立する
  • 本番環境にエラーを注入してシステムの回復力を鍛える
  • ローカルな発見をグローバルな改善につなげる
  • 組織的な改善と学習のための時間を確保する

Ch19 日常業務での学習の実現と日常業務への学習の注入

複雑なシステムのなかで安全に仕事を進めるためには、自己診断と自己改善の能力を引き上げなければならない。

  • NetflixのChaos Monkeyの取り組み事例

この章では、このような学習システムの作り方とジャストカルチャーを確立する方法、学習を加速させるために日常的にエラーのリハーサルを行い、意図的にエラーを引き起こす方法を探求していく。

  • 公正なラーニングカルチャーを確立する

ラーニングカルチャー(学習する文化)を築くためにあらかじめ必要とされる要件の1つは、事故が起きたとき(事故は必然的に起きる)に、その対処方法が「ジャスト」(公正)に見えるようにすることである。

  • 腐ったりんご理論の誤り

私たちが目標とすべきは、組織的学習の機会を最大限に増やし、日常業務に潜む問題を暴いて広く共有する行動を評価する場を形成することである。そうでなければ、私たちが動かされているシステムの品質と安全性を向上させ、そのシステムのなかで仕事をしているすべての人々の間の関係を強化することできない。

情報を知識に転化させ、システムにその学習結果を組み込むことが、安全性と説明責任のバランスをとってジャストカルチャーの目標を達成するための第一歩になる。

学習を基礎に置くジャストカルチャーを作るためには、避難なしのポストモーテムと管理された形での本番環境への障害の注入という2つの実践が効果的である。複雑なシステムでは避けがたく起きる問題への対処方法を練習する機会を作るのである。

  • 事故が起きたあとに非難なしのポストモーテムを開く

事態を解決したあとで非難なしのポストモーテム(blameless post-mortem)を開くべきである。このblameless post-mortemという用語はJohn Allspawが作ったもので、「障害のメカニズムの状況的な側面と障害につながった個々人の意思決定プロセスに光を当てる形で誤りを」検証することを表す。

事故発生後できる限り早い時期、記憶が失われ、因果関係のつながりが見えなくなったり、状況が変化したりする前に、ポストモーテムを開くようにする(もちろん、まだ問題解決のために走り回っている人々の邪魔にならなように、問題が解決するのを待ってからである)。

  • 非難なしのポストモーテムですること
  • 誤りを犯した人を罰しないようにしながら、さまざまな視点から障害の詳細な事実を集めてタイムラインを描く
  • 自分が障害の発生にどのように関わったかについて詳細に説明できる場を設けて、すべてのエンジニアに安全性向上のための意欲を与える
  • 将来同じ過ちを繰り返さないための方法を社内のほかの人々に教えるエキスパートになるように、誤りを犯した人々を励ます
  • 人にはアクションを起こすか否かを判断する裁量の余地がかならずあり、その判断のよしあしの判定はあと知恵だということを認める
  • 将来、同じような事故が起きないようにするための対応策を提案し、期限とフォローアップ責任者を決めてその対応策の実施記録をかならず作る
  • 問題発生につながったかもしれない判断を下した人々
  • 問題を見つけた人々
  • 問題に対処した人々
  • 問題を診断した人々
  • 問題の影響を受けた人々
  • その他会議に出席したいと思っているすべての人々

まとめ

組織的な学習を実現する基礎となるジャストカルチャーを作るためには、いわゆる失敗、障害、エラーの意味を捉え直さなければならない。複雑なシステムでは避けがたいエラーは、適切に扱えばダイナミックな学習環境を作り出せる。それは、すべてのステークホルダーが安心して見たことを証言し、アイデアを提出できる環境であり、グループが期待外れになったプロジェクトを早期に立て直せる環境である。 非難なしのポストモーテムと本番環境へのエラーの注入は、どちらも障害を浮上させ、障害から学ぶことに慣れ、そうすることに責任を感じるような文化を築き上げる。事故の数が十分に減ったときには、許容範囲を狭めて学習を続けるようにすべきだ。Peter Sengeが言っているように、「唯一の持続可能な競争優位は、競合他社よりも早く学べる能力だ」

ゴーファー君と回し車をダッシュで回す その1

仕事でバックエンドの開発をするようになって早3ヵ月…バックエンド開発ちゃんとするの5年ぶりぐらいなうえに、Golangを触るのもはじめてということで兎も角として地力がなさ過ぎなので素振りする。

触る要素

使うフレームワーク・ライブラリ

github.com

github.com

github.com

github.com

DBはめんどくさいんで雑にSQLiteにすると思う(この時点でなんも考えてない)。

アーキテクチャの参考にしてみる。

github.com

42Tokyo(フォーティーツートウキョウ)体験会 in Hiroshimaに参加してきた

note.com

かなり圧縮されたサマリー版での体験でした。

レクチャーの構成要素をバラすと下記になりそう。

  • 課題ベースの学習
  • ペアワーク
  • ピアレビュー

なんと言うか、これは合う合わないがあるのと、これに合わなくても別にプログラミングはできるようになるし、ソフトウェア開発者にもなれるとは思った。

現役のソフトウェア開発者目線で欠けてるなと感じたのは、課題の探査、課題の分解の要素が弱い。不定形な人間の要求を解決、満足させることを計算機に命じるのがプログラマーの仕事の本質なのだけど、対計算機要素(コンピュータ)は強いが、対顧客(人間)の側面がない。

現役のソフトウェア開発者がイメージできるように説明するとタスクを受け入れ条件まで含めて要件仕様書として自然言語で切り出して渡すと自走してDONEにしてPRレビュー依頼をだすところまではいけるし、それに対してレビューしてフィードバックを返せばちゃんと学んで答えることはできるようにはなってるレベル感、ペアワークやコードレビューの習慣は身についているし、CSの基本的な素地、チーム開発経験まではないけどチーム内でのコミュニケーションに支障はないと言ったソフトスキル保持者をイメージすればよいのかなと言った感じがしました。このブートキャンプの経験者と直接話したことないので今日の体験会を受けてみての感想にすぎないけど。

解決するべき課題や解決することによって誰に?どんな価値を提供できるのかを考えてそもそもどういった課題なのかをコードに落としていくことは恐らくこのカリキュラムと言うか学習法だと無理そうとの肌感を得た。いや、そんなの教えてできるならそこいらじゅうに優秀なプロダクトマネージャーやシニアクラスのソフトウェア開発者が転がってることになるんだろうけど。

コード1行も書かずに課題を解決をするのがよい開発者であると思ってる人間からすると、なんつうか42Tokyoに合う人はプログラマーの三大美徳の一つである怠惰を欠いた人な気がする。あー、なんつうか私は無理だわと感じた。

The 車輪の再発明感がすごい。趣味でやる分には良いけど無駄が多くて、時間をすごく喰われるプログラムだと感じる。このブートキャンプは学生だとか、一定時間仕事をしないでよい人じゃないとこなすの無理だと思った。あと、ソフトスキルの方向性としては外に向けて何か働きかけるのが苦ではないタイプ、行動するタイプ、陽キャ的な人だろうなと感じた。所謂ギークな人は合わんと思った。

なんかディする気なかったのにディする感じになってしまった(自覚はある)。そもそも論として学習手段がその辺に転がっていて、広島なんて言う片田舎にすら開発者コミュニティがあるのになんでスクールとかブートキャンプのカリキュラムに通いたがるのか、そしてこれを提供する人たちはいったい誰のなんの課題を解決して価値提供をしているのか、ほんまなぞ。

ハッカソンでやってます感を出してる層に対する冷めきった目線に近いもんがあるな。自分のちょっと引いたこの感じは。

なんなんだろ、どんなに計算効率が悪くてイカシテないコードであろうと、偉大なる巨人の肩に乗っかったおんぶに抱っこのフレームワーク、ライブラリーまみれのコードであろうと、自分で課題を見つけて、そう自分で見つける!!!

それを実際に解決するのが何というかソフトウェア開発者の醍醐味だと思うんだけどな。なんかこう難しい課題を綺麗にコードベースに落として計算機に実行させるの確かに楽しいけど、なんなんだろ飽きる系の楽しさなんだよね。アドレナリンがどばーっと出るハイになる系の多幸感って疲れるし飽きるんですよ。もっとこう、自分の書いた不細工なコードによるプロダクトが実際にユーザーに使われて喜んでもらえて、でももっとこうしたいなって改善していくみたいなやつ。こうなんなんだろほっこりする小さな日々の積み上げ的な楽しさ的なものと言えばよいのかな。

やっぱこれはオッサンになったということなんかな。24時間空いてるオフィスでウェィウェイしながらコード書くのはもう無理だし、それじゃいい仕事はできんのだよと思ってしまう。

こいつには興味が出たので秋の夜長の読書リストに追加しておく。

📝

entgo.io

GoのORMフレームワークであるent.のチュートリアルちょっと触ってみた。なんか根本Golangの経験値が低すぎて色々とツラタンである。 仕事やって家事やって、スキルインプットの時間をとるのはやはりなかなかにしんどい。疲れたのでもう寝る。