Movatterモバイル変換

[0]ホーム
URL:

mkdir blog && cd $_

ITエンジニアの雑感

Railsのcomposed_ofの使い方

Rails のcomposed_of の使い方をメモしておく。

巷にはcomposed_ofの説明がたくさんある。しかし自分が調べてもサクッと分からず、自前で実装して確認したことを残しておく。

railsdoc.com

前提

  • composed_of にする対象のカラムはjson 型

実装例

  • class_name のValueObject(モデル)にインナークラスを利用する場合には、class_name: "ExternalSetting::ServiceConfig" のように指定することで利用できる。
  • mapping にはマッピングをしたい[%w(当該モデルのメソッド名 class_nameで指定したValueObjectのメソッド名), ... で指定する
  • ValueObjectの中で構造体を利用してJsonのデータを設定できるようにする
# == Schema Information## Table name: external_settings##  id                    :bigint           not null, primary key#  external_service      :integer          default("default_setting"), not null#  service_config        :json#  created_at            :datetime         not null#  updated_at            :datetime         not null#classExternalSetting <ApplicationRecord  composed_of(:service_config,class_name:"ExternalSetting::ServiceConfig",mapping: [%w(external_service service),%w(service_config config)],allow_nil:true  )  enumexternal_service: {default_setting:0 }classServiceConfigattr_reader:service,:configDefaultConfig =Struct.new(:usase)dodeffoo?        usase ==:fooend      ....enddefinitialize(external_service, service_config)@service = external_service.to_i@config = service_configif service ==ExternalSetting.external_services[:default_setting]@default_setting_config =DefaultConfig.new(get_value(:usase))endendprivatedefget_value(key)      config.present? && config[key]endendend

利用方法

config = {usase::foo }external_setting =ExternalSetting.firstservice_config =ExternalSetting::ServiceConfig.new(external_setting.external_service, config)external_setting.service_config = service_configexternal_setting.saveexternal_setting.service_config.default_config.foo?

Session Managerログインイベントの取得と出力方法

AWS CloudTrailからSession Managerでログインした内容をAWSCLIで取得する方法をメモする。

Session Manager でログインをすると、StartSession というイベントになる。aws cloudtrail コマンドでStartSessionのイベントを取得して、レスポンスからjqで 時刻、ユーザー名、インスタンスIDを出力している。

$ aws cloudtrail lookup-events--lookup-attributesAttributeKey=EventName,AttributeValue=StartSession | jq-r'.Events[] | "\(.EventTime) \(.Username) \(.CloudTrailEvent | fromjson | .requestParameters.target)"'
2025-02-12T17:18:34+09:00 user_a i-0123456789a1b23e4562025-02-12T14:34:15+09:00 user_a i-0123456789a1b23e4562025-02-12T10:42:11+09:00 user_a i-0123456789a1b23e4562025-02-12T10:41:36+09:00 user_a i-0123456789a1b23e4562025-02-07T15:14:50+09:00 user_a i-0123456789a1b23e456

docs.aws.amazon.com

docs.aws.amazon.com

組織再編とスクラム開発

組織再編があった。まだ完全移籍ではなく2ヶ月ほど現チームと新チームの半々の状態で働くことになっている。新チームにジョインして1週間時点での状況と考えを残しておく。

異動先チームは、様々な事情から2ヶ月ほどメンバー1名で運用保守と開発をしていた。そこに自分がジョインして2名体制で開発をすることになった。

スクラムをするべきか？

異動前のチームでは(なんちゃってではあるが)スクラム開発をしていた。それなりに良い循環が出来ていたので新たなチームでも採用したいと考えていた。

まず、スクラムがマッチするかどうか、エッセンシャル スクラムで紹介されているクネビン(カネヴィン)フレームワーク で考えてみる。

ざっくりと内容を抜粋すると以下のような内容になる。

クネビンフレームワーク

  • 複雑な領域
    • 物事を予期できないことのほうが多い。正解があるとしても、後でふりかえって初めてわかる。
    • スクラムは、特にこの複雑な領域に取り組むのにうまく当てはまる。
  • 込み入った領域
    • 専門家が活躍する適切なプラクティスの領域になる。
      • e.g) システム全体のパフォーマンスを最適化するためにパラメータを調整するような作業。
    • シックスシグマのような戦術的・定量的アプローチの多くは特にうまくいく。
  • 単純な領域
    • 誰の目にも因果関係がはっきりしている。
    • スクラムは単純な問題にも用いることができるが、この場合は最も効率的というわけではない。適切に定義され、反復可能な手順が組み合わせられたプロセスを用いたほうがうまくいく。
  • カオスな領域
    • 危機に瀕しているので、これ以上の被害を食い止め、何らか秩序を回復するために素早い対応が求められる。
    • スクラムではうまくいかない。作業のバックログの優先順位を付けて、次のイテレーションでやるべき作業を判断するような状況ではない。
  • 無秩序
    • どの領域に自分がいるのかわからなければ、それは無秩序な領域にいる。この領域は危険である。
    • 残念ながらこのアプローチはソフトウェア開発ではほとんどうまくいかない。無秩序な領域から脱出するためには、状況を構成要素に分解して、それぞれをその他の4つの領域に当てはめることだ。

感じた課題

  • タスク管理が出来ていない。
    • チケットはあるがゴールが曖昧で属人的になっていた。
    • 優先度付のバランスが悪い。フレームワークのアップデートをしておらず、EOLになる
  • QAでの不具合が多い。
  • リリースのスケジュール管理が出来ていない。他チームとの兼ね合いがある点を考慮しても改善の余地がある。せっかく実装してもリリースされずに滞留している。

クネビンフレームワークに当て嵌めて考えると、「複雑な領域」になりスクラムにマッチしていそう。

en.wikipedia.org

最後に

成功した事例を、どんな環境にも柔軟に合わせて再度成功させることが出来るような、再現性が高い人間になりたい。

異動前のチームでは、品質が高く一定の頻度でリリースをする安定した開発が出来るチームへとリード出来た。

前提や環境が全く違うが、異動先のチームでもその再現をしていきたい。

Git Log Command Reference

Pull Requestのレビュー指摘を修正した後に、コメントで修正したコミットのハッシュを記載している。コピーするのが手間なので、コマンドでの手順をメモしておく。

前提

環境はMac

手順

  1. 直近N件のログをコミットハッシュと件名を出力する：$ git log -N --pretty=format:"%H %s"
  2. コミットハッシュをクリップボードにコピーする
    • 直近の場合：$ git show --pretty=format:"%H" --no-patch | pbcopy
    • N件前の場合：$ git show HEAD~N --pretty=format:"%H" --no-patch | pbcopy

e.g.)

直近N件のログをコミットハッシュと件名を出力する

$ git log-3--pretty=format:"%H %s"7fe68ebba167b4927bcd0636cc39379ca4e28fc2 :add: foo5efda28a322259427ff676e8d7f976a686af5479 :add: barb7d7fdd2b472c008de448ceb7c94be8695dc4e0b :update: baz

直近のコミットハッシュをコピーする

$ git show--pretty=format:"%H"--no-patch | pbcopy

3件前のコミットハッシュをコピーする

$ git show HEAD~3--pretty=format:"%H"--no-patch | pbcopy

参考

git-scm.com

勉強会でチームスキルの向上を目指す

社内の勉強会で実施したいテーマを考える。どうゆう軸で考えるべきかいつも迷う。

エンジニアチームの生産性の高め方 〜開発効率を向上させて、人を育てる仕組みを作る を読んで、「第6章　エンジニアリングイネーブルメント」の内容に興味を持った。本書にある「能力向上の取り組み」を自分なりに簡単に試してみる。

はじめに

第6章にある「開発プロセスの全体像の定義」と「能力向上施策の定義と実施」の内容をザックリまとめると以下のステップになる。

  1. 開発ステップの定義をつくる。自分のチームの開発プロセスを大きく何個かのステップに分けて書き出す。ステップを進めるために必要なもの(スキルや成果など)を成功ファクターとして定義する。
  2. ファクターから遂行するために必要なスキルを書き出す。
  3. スキルレベル表をつくる。(レベルはIPAのITスキル標準)

開発ステップの定義

簡易的だが開発ステップを洗い出してみた。

ステップ 要件定義 スプリントプランニング 設計 実装 スプリントレビュー レトロスペクティブ QA リリース 不具合・障害対応
ファクター 要求仕様 見積もりADR コーディング デモ プロセスの改善 デプロイ 監視・モニタリング
プロダクトバックログ 仕様書 設計レビュー コードレビュー メトリクス
テスト ログ
CI/CD
リファクタリング

スキルの書き出し

開発ステップのファクターに必要なスキルをパッと思いつく限り書き出してみた。

ステップ 要件定義 スプリントプランニング 設計 実装 リリース 不具合・障害対応 リリース 不具合・障害対応
ファクター 仕様書 見積もりADR コーディング テスト デプロイ 監視・モニタリング デプロイ 監視・モニタリング
スキル UI/UXの知識 開発手法 システム設計の知識Rubyrspec Docker CloudWatch メトリクス
ドメイン知識 Go go testGitHub Actions New Relic ログ
React Jest CircleCI
MySQL

スキルレベル表

本来はチームメンバー全員のレベルを出すが、一旦は自分のスキルレベルを一部書き出してみる。

スキルドメイン知識 開発手法 システム設計の知識Ruby Go ReactMySQL DockerGitHub Actions CloudWatch
レベル 3 4 3 4 3 3 3 2 2 2

まとめ

このフローに則れば、チームの業務に必要かつ向上すべきスキルが可視化できる。やみくもに勉強会のテーマを決めるよりも業務への即効性がありそうなので良いフレーミングだと思った。チームで早速試してみたい。

「カオスエンジニアリング」を読んで

カオスエンジニアリング ―回復力のあるシステムの実践 をサラッと読んだので簡単に所感をメモしておく。

「カオスエンジニアリング」という言葉は知っていた。しかし、具体的な内容は認識していなかった。本書を通じて「カオスエンジニアリング」の理解を深めることが出来た。

まずはそのきっかけ。カオスエンジニアリングがNetflixの危機から誕生して、度重なる障害の中で段階的に成長していくことで形成されていった。そして、「カオスエンジニアリングの原則」というのあることを知った。

principlesofchaos.org

本書を読み進めていく中で、カオスエンジニアリングの説明でしっくりきた箇所を抜粋しておく。

  • 「モノを壊す」ではなく「本番環境でモノを直す」。プロアクティブに複雑なシステムの安全性を改善することに注力した規律である
  • 実験の一種であり、テストではない
  • モノがどのように動くかではなく、動くかどうか自体に関心を寄せている
  • システムから予想外の結果が得られることを前提に、回復力(レジリエンス)のあるカルチャーを作り上げる取り組み。

その他、実際にカオスエンジニアリングをするにあたって、どう進めていくべきかなどの具体的な考え方や方法が参考になる、と感じた。

ただ、自分の組織ではまだカオスエンジニアリングを実践する段階には至ってはいない。しかし、考え方のエッセンスや段階的に取り入られる事はあると思った。

React Hook FormのhandleSubmitでEventを利用する方法

React Hook FormのhandleSubmitでEventを活用する方法をメモしておく。

前提

  • バリデーションにはYup を利用している。

動作

  • フォームのSubmitをしたらバリデーションをして、独自モーダルを表示する。
  • モーダルのボタンを押下したらAPIにリクエストをする。

実装例

typeformSchema=yup.InferType<typeofFooSchema>;exportdefaultfunctionApp(){const{register,control,handleSubmit,formState:{errors},} = useForm<formSchema>({      ...},    }  )asyncfunctionfetchAPI(    form:formSchema){    ...}functionhasError(errors:FieldErrors<formSchema>){returnObject.keys(errors).length >0;}const onClick = (_data:formSchema, e:any)=>{if (hasError(errors)){return;}    setShowModal(true);    e.stopPropagation();    e.preventDefault();}const onSubmit =async (data:formSchema)=> fetchAPI(data);return (<><form>        ...<inputtype="submit"onClick={(e)=>{            handleSubmit(onClick)(e);}}/></form><SampleModal...onClick={async ()=>{            handleSubmit(onSubmit)();}}/></>  )}

まとめ

モーダルのボタンを押下するタイミングでもバリデーションが実行されてしまうが、onClick でエラーがなければモーダルを表示するようにしているのでonSubmit でバリデーションエラーにはならないはず。もっと良い方法があれば見つけたい。

注目記事
検索

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

読者です読者をやめる読者になる読者になる
[8]ページ先頭
©2009-2025 Movatter.jp