メドピア開発者ブログ

集合知により医療を再発明しようと邁進しているヘルステックカンパニーのエンジニアブログです。読者に有用な情報発信ができるよう心がけたいので応援のほどよろしくお願いします。

Terraform コードリーディング会を開催し、エンジニア組織全体でインフラの知識の底上げができた話

SRE の田中 @kenzo0107 です。

Terraform コードリーディング会を実施した結果、 エンジニア組織全体でインフラの知識の底上げができた話です。

何故やることになったか?

弊社では以下のような背景がありました。

  • SRE チームが基本インフラ管理
  • 会社の成長に比例し管理するインフラが増加⤴️

SRE チームの処理能力が頭打ちにとなる未来が予想され、
インフラ管理は以下体制への移行が求められていました。

上記の体制へ移行活動の一環として、
まず 「Terraform を知る」こと、ひいては 「AWS を知る」きっかけを作るべく、 Terraform コードリーディング会を開催することとしました。

勉強会の頻度や基本方針

  • 週 1 回 30 分 × 15~6 回*1
  • 自身の携わるプロジェクトの勉強会に参加*2
  • 構成図を元にコードを読む範囲の構成を定める
    • 以下を見ながら、設定の意味や挙動を確認する
      • AWS 公式ドキュメント
      • Terraform のドキュメント
      • AWS Provider のドキュメント
  • おまけ
    • ディレクトリ構成
      • 弊社デファクトの構成やアンチパターンの共有
    • Actionsで実行してる内容:

参考図書

勉強会の例

以下開催した勉強会の一例です。*3

タイトル 内容
1 リーディング会実施の目的と terraform の概要 ・AWS とは?
・Terraform と Provider の関係性 *4
・バグ?と思った時の調べ先
・Terraformの文法
2 Terraformの使い方とTerraform Cloud ・Terraform インストール方法
・Terraform の各種コマンド
・State, Lock の役割
・Terraform Cloud
・Workspace
・Built-in Functions
演習 Built-in Function の挙動確認
 ・文字列分割, 配列長, 配列結合, 配列のネストの深さを揃える
3 RDS ・RDS とは?
・DB Subnet, Cluster, Cluster Instance
・Cluster Parameter Group と Parameter Group の違い
演習 DB パスワードのような秘匿情報はどの様に渡すか
4 LB ・ALB とは?
・NLB, CLB との違い
・メンテ時のリスナールールの挙動
演習 リスナールールで Host ヘッダーが正しいか制御しているのはどういう意図か?
5 ECS Part1 ・EC2 → ECS on EC2 → Fargate 歴史
・タスク定義で定義するもの
・EKS とは?採用するメリット・デメリット
演習 ECS EC2 と比較し Fargate を採用するメリット・デメリットは?
6 ECS Part2 ・ECS Cluster
・ECS Service
・デプロイ時の挙動 (RollingUpdate, Blue/Green Deployment)
・無限再起動ループ
AWS 勉強会 ECS 編 で補足
7 ECS Part3 ・ECS Service がどの機能で利用されているか認識合わせ
・タスクサイズを ECS Service 毎に変えている理由
・rails コンテナの WEB_CONCURRENCY とタスクサイズについて
8 Network Part1 ・VPC, Subnet, NAT Gateway の各役割
・AWS の各種リソースの所属ネットワーク
・provider のリージョン指定
 ・例: CloudFront の ACM は us-east-1 を指定する
 ・例: バックアップの設定で ap-northeast-2, 3 を指定する
・CIDR とは?
・Subnet の設計
 ・弊社デファクトの構成
 ・アンチパターン
演習
 ・NAT Gateway がどの AZ で起動しているかコードから追ってみてください
 ・NAT Gateway をマルチ AZ で配置している理由は?*5
9 Network Part2 ・Route Table
・Public Subnet 用の Route Table
・Private Subnet 用の Route Table
・Private Subnet からインターネットへアクセスする経路の確認
・VPC Peering
・演習: Route Table は何に紐付ける?
10 IAM Part1 ・IAM User と IAM Role
・IAM User は使わない!その理由
・IAM Group, IAM Policy
・IAM JSON Policy 言語
・IAMとリソース側のポリシー
・IAM ポリシーでアクセス許可と禁止がかちあった場合、どうなる?
演習
 ・パラメータストアに登録された SendGrid API Key を復号し値を取得する権限を所持する IAM ポリシー名は?
 ・その IAM ポリシーはカスタマー or AWS どちらの管理ポリシーですか?
11 IAM Part2 ・IAM Role
・Assume Role
12 S3 ・何故 S3 を使うか?
・プロジェクトでは何に S3 を利用しているか
・ACL (Access Control List) vs バケットポリシー
・パブリックアクセスブロック・SSE・バージョニング・アクセスログ・ライフサイクルポリシー
13 CloudFront ・CloudFront とは?
・CDN, エッジサーバとは?
・CloudFront を利用した各種 Web サービスの構成
余談 JR東日本が2023年5月27日以降、JR の改札機がセンターサーバ方式を採用 *6
14 WAF ・WAF とは?
・マネージドルール, カスタマールール
・WAF のルールの評価の仕方
・論理 statement 設定例
WAF でブロックされているか確認する方法
・おまけ:
 ・IP制限ってSecurity GroupとWAFのどっちでやるべき?
 ・セキュリティグループとWAFがアタッチされている場合どっちが優先される?
演習
 ・特定のリクエストでどの WAF ルールが評価されるか?
 ・本番・ステージング環境でデフォルトアクションを ALLOW にしている理由は?
15 デプロイパイプライン ・GitHub Actions
・Code シリーズ
16 Pull Requestの出し方 ・plan 内容を確認後レビュー依頼する*7
・適切なTerraform記法を利用しているか?
・専用のData Sourceを使える場面では使っているか?
・ファイル分割やファイル中のリソースの順序は周囲と統一してあるか?

弊社のサーバは基本 Fargate を採用していること、 ネットワーク関連・ IAM 関連は初学者を苦しめると思われる為、 手厚めに数回実施しています。

開催後のアンケート

とある 1 プロジェクトについて参加者にアンケートを取った結果です。

他プロジェクトを見渡しても
「ちょっとした変更なら実装できる気がする」以上になったことは 元々の関心の高さもありますが、理解の一助になったかと思います。

勉強会をして変わったこと

サービスチームへインフラ管理の移譲が進む様になり理解の底上げができた実感があります。

以下対応をいただくプロジェクトもありました。

  • RDS for MySQL から Aurora MySQL へリプレイス
  • Aurora MySQL 5.7 から 8 系へのバージョンアップ
  • Datadog の APM Tracer による監視追加

総評

まず勉強会で全エンジニアが Terraform を触るきっかけ作りができたことが良かったです。
プロジェクト間でノウハウを共有し効率化する流れが生まれたのも大きな変化です。

プロジェクトの人員数や理解度によって、段階的に管理を移譲していますが、 強制でなく、組織として望む体制として共有した上で進め、できる様になったら評価する、 というスタンスを取れたことが個人的にとても弊社らしいなと思いました。

アンケートでハンズオン形式でも開催を希望する声があったので今後の参考にしたいと思います。

改めまして勉強会参加いただきましたエンジニアに感謝です。

以上
参考になれば幸いです。


是非読者になってください


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube  www.youtube.com

■メドピア公式note
style.medpeer.co.jp

*1:30分は参加ハードルを下げるのにちょうど良かった。アンケートで1時間参加は業務的に難しい、という結果でした。

*2:参加したいプロジェクトがあれば任意参加可能

*3:プロジェクトによっては希望するコンテンツを別途用意したりと適宜対応しました。

*4:ファミコンとカセットで例えたら若者には伝わらなかった 😢

*5:弊社では耐障害性向上の為、 NAT Gateway は基本マルチ AZ に配置するポリシーです。

*6:エッジサーバでキャッシュして高速化するのと逆の解決方法として紹介しました

*7:対応リソース以外の変更がある場合や意図しない変更となっていないか確認後にレビュー依頼を出すことが大事

MedPeerをVue 3にアップデートしました🥳

こんにちは、MedPeerのフロントエンド開発を主に担当している森田です。

MedPeer( https://medpeer.jp )ではVue 2 系を長らく利用してきましたが、公式からの発表の通り 2023年12月31日 でEOLとなっております。

With 2024 almost upon us, we would like to take this opportunity to remind the Vue community that Vue 2 will reach End of Life (EOL) on December 31st, 2023. https://blog.vuejs.org/posts/vue-2-eol

EOLを迎えても直ちにセキュリティリスクに晒される可能性は少ないとは思いますが、 MedPeerは医療を扱うサービスの特性上セキュリティリスクは最小限に抑えたいのと、 最新のVueの機能を利用できることは開発体験としても良いためVue 3へのバージョンアップを行うこととしました💪

そして2022年9月頃から検討を含めて着手を始め、約1年間という時間が掛かってしまいましたが 2023年11月29日 にVue 3にアップデートすることができました🥳

EOL直前ではあるもののMedPeerをVue 3にアップデートした際に工夫した点や躓いた点等を整理しましたので、これからVue 3へのアップデートする方の参考になれば幸いです🙏

前提事項

まずMedPeerというサービスですが、バックエンドはRuby on Railsで記載されており基本的にはhamlやerbといったサーバーサイド側のテンプレートエンジンを利用したモノリシックでMPAなサービスで、フォームやモーダル等といったリッチなコンポーネントをVue.jsを使って実装しています。 (フロントエンドエンジニアだけではなく、バックエンドのエンジニアも実装しております。)

また、Vue 2系の最新(v2.7系)にはアップデート済の状態で、Vueを利用したコードベースの規模感としてはリポジトリ内に.vueファイルが400ファイル、行数にすると55,000行程度あり、それなりの規模感のサービスなのではないかと思っております。

アップデートの基本戦略

上述の前提事項を踏まえて、Vue 3へアップデート基本戦略として次の2つを取りました。

  • バージョンアップ作業は通常の開発を止めずメンバー全員で行えるようにする
  • バージョンアップのリリース差分はなるべく小さくする

バージョンアップ作業は通常の開発を止めずメンバー全員で行えるようにする

Vue 3へのバージョンアップは破壊的変更も多く対応箇所が膨大で時間が掛かりそうに思ったので、通常の開発業務への影響を抑えメンバー全員で行えるような方法が望ましいと考え以下を行いました。

  • Vue 3の破壊的変更の影響を受ける箇所を静的解析でエラーとしCIで検知できるようにする
  • 静的解析のエラーをtodoとして管理することで対応内容・箇所を明確化する

Vue 3の破壊的変更がCIでキャッチアップできないと期間中にどんどん影響を受ける実装が増えてしまい、いつまで経ってもアップデートできないといったことになってしまう懸念があったので、CIでエラーにできるように静的解析で主要な破壊的変更の影響を受ける箇所を検知するようにしました。

特にplugin:vue/vue3-recommendedから先行して有効化したruleの中でもVue 2系の最新でも利用できてVue 3から必須になるemitsの定義を強制できるvue/require-explicit-emitsは非常にありがたかったです 🙏✨

Vue.extendといったGlobal APIの利用はESLintのno-restricted-importsを利用することでimport Vue from 'vue'のようなGlobal API利用目的のコードを検知しエラーにするようにしました。

"no-restricted-imports": [
  "error",
  {
    "paths": [
      {
        "name": "vue",
        "importNames": ["default"]
      },
    ],
  },
],

また、カスタムコンポーネントに対するv-modelで渡されるpropsemitされるイベントが変更されるのは影響が大きかったので、以下のようなカスタムルールを作成して明示的に@inputvalueを利用して影響を受けない実装を促すようにしました。

'use strict'

const utils = require('eslint-plugin-vue/lib/utils')

module.exports = {
  meta: {
    type: 'problem',
    docs: {
      description:
        'disallow using v-model for custom component is affected by a breaking change in Vue 3.',
      categories: undefined,
      url: 'https://v3-migration.vuejs.org/ja/breaking-changes/v-model.html',
    },
    fixable: null,
    schema: [
      {
        type: 'object',
        properties: {
          ignoreComponentNames: {
            type: 'array',
          },
        },
      },
    ],
    messages: {
      error:
        'カスタムコンポーネントへのv-modelの使用は、Vue 3の破壊的変更の影響を受けるので使用しないでください。\nhttps://v3-migration.vuejs.org/ja/breaking-changes/v-model.html',
    },
  },
  /** @param {RuleContext} context */
  create(context) {
    const ignoreComponentNames = context.options[0]?.ignoreComponentNames ?? []
    return utils.defineTemplateBodyVisitor(context, {
      "VAttribute[directive=true][key.name.name='model']"(node) {
        const element = node.parent.parent
        if (
          utils.isCustomComponent(node.parent.parent) &&
          !ignoreComponentNames.includes(element.name)
        ) {
          context.report({
            node,
            loc: node.loc,
            messageId: 'error',
          })
        }
      },
    })
  },
}

静的解析でエラーとなる既存ファイルは以下のようにoverridesでファイルを無効化することで対応箇所・内容を明確化。todoとして管理することでCIが通ればVue 3の破壊的変更に対応できる状態とし、メンバー全員でVue 3のアップデート対応を行えるようにしました。

module.exports = {
  overrides: [
    {
      files: [
        'app/javascript/components/Foo.vue',
      ],
      rules: {
        'no-use-v-model-for-custom-component': 'off',
      },
    },
    {
      files: [
        'app/javascript/components/Bar.vue',
      ],
      rules: {
        'vue/require-explicit-emits': 'off',
      },
    },
    {
      files: [
        'app/javascript/components/Baz.vue',
      ],
      rules: {
        'no-restricted-imports': [
          'off',
          {
            paths: [
              { name: 'vue', importNames: ['default'] },
            ],
          },
        ],
      },
    },
  ],
}

バージョンアップのリリース差分はなるべく小さくする

リリース前の動作確認期間等でVue 3アップデートの対応branchをmergeせずに保持する必要があり、競合解決といったメンテナンスコストを抑えるためにリリース差分を最小限に抑えたいと思い、破壊的変更で事前に対応できるものは対応し、なるべくリリース時点での差分を少なくするように主なものとして以下を行いました。

  • snapshotテストの差分をリリース時点では無視する
  • createAppといったVue 3の記法の一部を先行して利用できるようにする

snapshotテストをリリース時に差分に含めてしまうだけでリリース用のPull Requestの差分が数万行になってしまうのと、Componentのtemplateの実装が変わるだけで競合してしまいメンテナンスコストが非常に高くなってしまいます。 snapshotテストでは以下のようなwrapperメソッド経由で検証することで、環境変数でskipを切り替えられるようにし、ローカルでは差分が問題なさそうなことを確認した上で、リリース時点ではCIでskipしsnapshotテストの更新をリリース後に遅延できるようにしました。

// NOTE: snapshotテストをCIではskip可能にする
// ```ts
// describe('components/Foo', () => {
//   skippableIt('snapshot', () => {
//     const wrapper = mount(Target)
//     expect(wrapper.element).toMatchSnapshot()
//   })
// })
// ```
export const skippableIt = (name: string, test: () => void) => {
  const skip = process.env.SKIP_TEST === 'true'
  if (skip) {
    it.skip(name, test)
  } else {
    it(name, test)
  }
}

さらに、以下のようなカスタムルールを作成しtoMatchSnapshotを含むitskippableItの利用を促し自動的に利用を促せるようにしました。

'use strict'

/** @type {import('eslint').Rule.RuleModule} */
module.exports = {
  meta: {
    type: 'problem',

    docs: {
      description: `
      require use skippableIt for snapshot test for Vue 3 version up.
      `,
    },
    fixable: 'code',
    messages: {
      error: 'Snapshotテストはskip可能とするために skippableIt を使用してください。',
    },
    schema: [], // no options
  },
  /** @param {RuleContext} context */
  create: function (context) {
    return {
      /** @param {CallExpression} node */
      CallExpression(node) {
        if (
          node.callee.name === 'it' &&
          node.arguments[1].type === 'ArrowFunctionExpression' &&
          node.arguments[1].body.type === 'BlockStatement'
        ) {
          const block = node.arguments[1].body
          const expects = block.body.filter((node) => node.type === 'ExpressionStatement')
          const isUseSnapShotIt = !!expects.filter((expect) => {
            return (
              expect.expression.type === 'CallExpression' &&
              expect.expression.callee.type === 'MemberExpression' &&
              expect.expression.callee.property.type === 'Identifier' &&
              expect.expression.callee.property.name === 'toMatchSnapshot'
            )
          }).length
          if (isUseSnapShotIt) {
            context.report({
              node: node,
              messageId: 'error',
            })
          }
        }
      },
    }
  },
}

また、Component周りの破壊的変更に関してはVue 2系の最新(v2.7系)を利用することでComposition APIがvueから利用できるようになり、Vue 3の記法に近い形で記述できるので助かったのですが、entry等でのGlobal APIを利用した実装への影響が大きくリリース差分が膨大になってしまいそうだったので、以下のようなWrapperを用意してVue 2でもcreateApp等のVue 3に近い形で実装できるようにし、アップデート時はWrapper内のVueに対する呼び出し部分をVue 3アップデート時に変更するだけで済むようにしました。

// NOTE: 各エントリーで以下のようにcreateApp相当の記述で利用できる
// import { createApp } from 'Vue3Impostor'
class Vue3AppImpostor {
  app: Vue
  constructor(options: object) {
    this.app = new Vue(options)
  }
  mount(...args: Parameters<typeof this.app.$mount>) {
    return this.app.$mount(...args)
  }
  use(...args: Parameters<typeof Vue.use>) {
    return Vue.use(...args)
  }
  component(...args: Parameters<typeof Vue.component>) {
    return Vue.component(...args)
  }
}
export const createApp = (options: object) => {
  return new Vue3AppImpostor(options)
}

export const reactive = <T extends object>(...args: Parameters<typeof Vue.observable<T>>) => {
  return Vue.observable(...args)
}

@vue/compatの利用も検討しましたが、2021年末でメンテナンスが終了する旨がREADMEに記載があり、いずれはVue 3相当の記述に書き直す必要があるため利用しない方針としました。

これらにより差分を減らすことで、最終的なVue 3アップデートの差分は27ファイル(+ 419, - 430)に収めることができました🎉

Vue 3アップデートのPull Requestの差分(27ファイル)

アップデートで苦労した点

以下にMedPeer固有の問題もあるとは思いますが、Vue 3へのアップデートした際に苦労した点を参考になればと思い記載します📝

周辺ライブラリの乗り換えやアップデート

MedPeerでは以下のようなVue関連のライブラリがVue 3に対応しておらず、乗り換え・バージョンアップを行いました。

以下の3ライブラリに関しては正式リリースは現時点でまだリリースされていないようですが、alphaやbetaバージョンでVue 3対応が行われており、そちらを利用するような対応を行いました。(現状は特に問題は問題は起きておりません)

  • vue-infinite-loading
  • vue-multiselect
  • vue-select

vue-js-modalに関しては、vue-final-modalを利用するように既存実装を修正しました。

乗り換えやバージョンアップを行うにあたって既存のコードの修正が発生したものの、 そこまで大きな影響が出ずに対応できたのでalphaやbetaバージョンや代替ライブラリが提供されていて助かりました 🙏

※その他サービス内の一部でだけ利用されているライブラリ等がありましたが仕様を調整、独自で実装して削除しました。

リアクティブにするとプライベートな値に依存したロジックが呼び出せない

バージョンアップ時にプライベートな値(#foo等)を持つインスタンスをrefでリアクティブにした後、プライベートインスタンスフィールドにロジック実行時にTypeError: Cannot read private member # ...といったエラーが発生する事象がありました。

Vue 3からrefでリアクティブな状態にする際にProxyでwrapされるようになりましたが、Proxy経由ではプライベートな値を参照できないため本事象が発生しているようなので、

プライベートプロパティは転送できない プロキシーは、やはり異なるアイデンティティを持つ別のオブジェクトであり、ラップされたオブジェクトと外部との間を運営する プロキシー です。そのため、プロキシーは元オブジェクトのプライベートプロパティに直接アクセスすることができません。 Proxy - JavaScript | MDN

実行時にtoRawを利用して元のオブジェクトに対して実行するようにして対応しました。

toRaw() Vue で作成されたプロキシの、未加工の元のオブジェクトを返します。 https://ja.vuejs.org/api/reactivity-advanced.html#toraw

参考情報) 関連してそうなissue

mountした要素の子要素を別のVueアプリケーションからmountすると、v-bindが削除される

これは元々の実装が良くなかったのですが、以下のように既にVueアプリケーションをmountしている要素の子要素に対して、別のVueアプリケーションをmountしている箇所があり、、、

<div id="vue-app-1">
  <!-- ... -->
  <div id="vue-app-2">
    <custom-component :active="false" />
  </div>
</div>

Vue 3へのアップデート後に、後者の子要素にmountしていたVueアプリケーションのComponentに渡していたpropsへの受け渡し処理 <custom-component :active="false" /> からv-bindが削除され <custom-component active="false" />となり、本来であればactiveの値はfalseとなるところ"false"となり、論理値の結果が正反対になってしまう事象がありました。

MedPeer内で発生したケースは、Componentに渡していたpropsへの受け渡し処理 がそもそも不要だったため該当箇所を削除して対応できたため、大きな影響はなく助かりました🙏

slotで挿入したコンテンツにscoped CSSが適用されない

Vue 3アップデート後に、Vue 2系では適用されていたslotで挿入したコンテンツに対するComponent内の<style scoped>内で記述したスタイルが適用されない事象が発生しました。

<template>
  <div class="custom-component">
    <slot />
  </div>
</template>
<style lang="scss" scoped>
.custom-component{
  .slot-content {
    // 挿入されるslotに対するスタイル
  }
}
</style>

Vue 3 Migration Guideには記述が見つけられなかったのですが、以下の通りVue 3のドキュメントには明記されており、

<slot/> によってレンダリングされるコンテンツは、デフォルトでは親コンポーネントによって所有されていると見なされるため、スコープ付きスタイルの影響を受けません。 https://ja.vuejs.org/api/sfc-css-features#slotted-selectors

当初気づくのに遅れてしまったのですが、ドキュメント記載の通り:slotted等のディープセレクタを利用して対応しました。

参考情報) 関連してそうなissue

本番ビルドでだけ例外が発生する

Vue 3アップデート後に、propsの値が不正なケース(:prop-name="")等で、開発ビルドを利用している場合にはVue warnでエラーにならないのですが、本番ビルドを利用しているとSyntaxErrorが発生する事象がありました。

<div id="vue-app-2">
  <custom-component :prop-name="" />
</div>

エラーやVue warnの発生箇所を特定し対応することで、エラー自体は解消できたのですが受け渡すデータによって発生するため、気づくのが難しく対応に苦労しました・・・!

参考情報) 関連してそうなissue

おわりに

Vue 3のアップデートは破壊的変更も多く作業に着手してから約1年と長い時間が掛かってしまいましたが、 MedPeerの開発メンバーにも多大に協力して貰いEOLを迎える前に無事にVue 3にアップデートできました🎉

静的解析等を活用して対応箇所を可視化しVue 3のアップデートの前に先行して対応できる環境を用意できたのは、 進捗状況が定量的に追いやすく、リリース時の差分もコンパクトで開発メンバー全員で対応・レビューもしやすい状況にでき、 孤独感も感じずバージョンアップを進められて良かったなと今回振り返って思いました 🙏

Vue 3アップデートは一旦無事に完了しましたが、まだまだ伸び代のあるサービスなのでこれからも頑張っていきたいです💪

最後まで読んでいただきありがとうございました✨

アップデートの参考にさせていただいた資料


是非読者になってください!


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube  www.youtube.com

■メドピア公式note
style.medpeer.co.jp

After Kaigi on Rails LT Night 参加レポート

こんにちは、サーバーサイドエンジニアの古川(@frkawa_)です。

10/27(金), 28(土)の2日間にかけて行われたKaigi on Rails 2023、お疲れ様でした。
私も現地で参加しましたが、多くの刺激を受けることができてとても有意義な2日間となりました。普段関わることの無い多くの方と交流できることが現地参加の何よりの魅力ですね。

弊社ではKaigi on Rails 2023のセッションレポートの記事も投稿しているので、是非一度ご覧ください。

tech.medpeer.co.jp

そんなKaigi on Rails 2023の熱が冷めやらぬ中、株式会社スマートバンク様、株式会社マイベスト様、そして弊社メドピア株式会社の3社合同で After Kaigi on Rails LT Night と称したアフターイベントを11/9(木)に弊社オフィスで開催させていただきました。
私も現地で参加してきたので、イベントの様子を余すところなくお伝えしていきます!

会場の様子

参加者数は何と77名(connpassの参加者数より)!
メドピアさんの会場スペース広いですね、と言っていただけることが多いのですが、それでもかなりの密度となっていました。
私も設営のお手伝いをしたのですが、イベントスペースの椅子が足らず会議室の椅子をかき集めて設置しています。笑

各社紹介

スマートバンクCTO堀井さんの司会進行のもと、主催3社の紹介からイベントスタートです。
Kaigi on Rails参加しましたかー?という質問から始まりましたが、やはりアフターイベントということでかなりの割合で手が上がっていました。

LT① 「エンジニア9名でプロポーザル8件、採択3件」を支える技術と文化

speakerdeck.com

LTトップバッターはスマートバンクohbaryeさん(@ohbarye)。
スマートバンクさんはKaigi on Railsで3名もの方が登壇されていたのが記憶に新しいですが、プロポーザル採択のためにどんな活動をしたか、というテーマでお話しされていました。
どんなプロポーザルが通りやすいかという実践的な話から、プロポーザルを作る上でチームとしてはどんなサポートをしているか、なぜカンファレンス登壇の挑戦に力を入れているか、といった内容まであり、刺さった方も多いんじゃないでしょうか。
個人的には、「感情は伝染する」「情熱やモチベーションも伝染する」という言葉が印象に残っています。

LT② WebAuthnを使ったパスワードレス認証をRailsアプリケーションで実装する

speakerdeck.com

二番手はメドピアの伊藤さん(@yuma_ito_bd)がRailsにおけるWebAuthnを使ったパスワードレス認証についてのLTを行いました。
Kaigi on Railsのセッションに触発されこのテーマを選んだそうです。
QRコードで実際にWebAuthnを体験するところから始まり、FIDOやパスキーといったパスワードレス認証に必要な前提知識の説明からWebAuthnの仕組み、Railsにおける具体的な実装例の説明まで、短い時間の中で非常に綺麗にまとまっている素晴らしいLTでした!
私も興味が湧いたので、Railsアプリで簡単なFIDO認証を試しに実装してみようと思いました。

LT③ こわくないフレームグラフ - Singedで始めるパフォーマンス改善

speakerdeck.com

続いてのマイベスト横山さん(@_shrrk)のLTは、フレームグラフは怖くない!という内容のトークです。
パフォーマンス改善において、APMツール上には現れない、クエリ元となっているRubyのメソッドをフレームグラフというツールを使って可視化するためのノウハウについてお話しされていました。
フレームグラフのどういった要素に恐怖を感じやすいかを分解し、それぞれの要素に対しどんなアプローチができるか、複数選択肢があるgemをどう使い分けるかという詳細な説明が論理立てて説明され、比較的難しい内容でも理解しやすい説明になっていたんじゃないでしょうか。
導入方法の説明も実際のプロダクトでイメージが付きやすい内容で、パフォーマンス改善をする際は是非試してみたいツールの一つだなと感じました。

公募LT① Sidekiqのオブザーバビリティを向上させた話

speakerdeck.com

公募LTの一番手は、imaharuさん(@imaharuTech)によるSidekiqにおけるオブザーバビリティの向上についてのトークです。
Sidekiqにおけるにオブザーバビリティは、遅いジョブがどれか、ジョブが完了していない原因は何かを特定できる能力であり、それを実現するためにSidekiqのログに必要な情報を吐くように改善した、という内容でした。
エラーログにjidやジョブの状態をハッシュに詰め込んだSidekiq::Context.currentを出力することでこれらのオブザーバビリティを実現したとのことです。

公募LT② Kaigi on Rails 2023 〜運営の裏側〜

続いては寺井さん(@krpk1900_dev)によるKaigi on Rails 2023の運営の裏側についてのトークです。
時系列で今回のKaigi on Rails 2023の開催に向けて2022年11月から何をやってきたかを事細かに語っていただけました。
本業が終わった後に20時から23時までミーティングをやっていたこと、2024年の会場を23年の3月時点で始めていること、スポンサー抽選にRubyのshuffleメソッドを使っていること、115件ものCFPを19時間かけて見たことなど、へぇ〜な話から衝撃的な話まで聞けて非常に面白い内容でした。
そして何より運営の大変さが伝わって来て、本当にたくさんの人の大きな労力で成り立っているイベントなんだなと思いました。
そんな運営が大変な中でKaigi on Railsに登壇もされて、直後の勉強会でも登壇されて、今回のアフターイベントでも登壇された寺井さんのすごさが際立つLTでもありました。

公募LT③ 無用な認知負荷を減らしてお手入れしやすいコードを書こう

shinkufencer.hateblo.jp speakerdeck.com

最後の公募LTは、しんくうさん(@shinkuFencer)による認知負荷に関するトークです。 人間には長期記憶と短期記憶があり、短期記憶を長期記憶に効率良く移すにはどんな認知負荷の種類があり、どんな負荷を減らすべきかという話から始まり、プログラミングにおいて保守性の高いコードがどんなものかを考える上でのヒントになる、という内容でした。 しんくうさんの説明では課題外在性負荷、つまり本質的ではない本来は不要な負荷を取り除くことが重要で、コードで言うとlinterや分かりやすい命名を使おうねという話に繋がるものでした。 ある程度経験があるエンジニアであれば感覚的に理解していることかもしれませんが、初学者の理解を助けることもできる普遍的な内容と言えるLTだったのではないでしょうか。

懇親会

LTの後は懇親会が行われました!
LTの終盤、お腹が空き始める時間に続々とピザが届き、そわそわしていた方も多いんじゃないでしょうか。
マイベストさんからはCTO選りすぐりの日本酒をご提供いただきました。ありがとうございます!
各所ではKaigi on Railsや各社のプロダクト開発についてなど、技術的な話を中心に大きな盛り上がりを見せていました。
懇親会は1時間半ほど行われ、皆さん名残惜しい中お開きとなりました。
後片付けも参加者の皆様にご協力いただきスムーズに終えることができました。この場を借りてお礼を申し上げます!

おわりに

アフターイベント、楽しんでいただけましたでしょうか?
登壇者の皆さん、スマートバンクさん、マイベストさん、ありがとうございました。
RubyやRailsのコミュニティは大きくて強い繋がりで結ばれているな、と感じることができるイベントになったかなと思います。
また次のイベントで皆さんにお会いできる日を楽しみにしております!


メドピアでは一緒に働く仲間を募集しています。
少しでも当社に興味が湧いた方は、ぜひ下記をご覧いただければと思います。ご応募をお待ちしております!

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube  www.youtube.com

■メドピア公式note style.medpeer.co.jp


是非読者になってください!

Daniel Roe から学ぶ!Nuxt ワークショップ参加レポート

こんにちは、フロントエンドサウナーの土屋 (@tutti2612) です。
フロントエンドサウナーとは、サウナの UI/UX にこだわるサウナ好きのことです。今考えました。
サウナ室、水風呂、外気浴スペースの動線がスムーズなサウナはポイント高いです。

先日、日本で唯一の Nuxt 公式パートナーである NuxtLabs Japan が主催する Nuxt ワークショップに参加してきたので、その様子をレポートしたいと思います。

ワークショップの概要

このワークショップは、Nuxt コアチームのテックリードである Daniel Roe さんが講師を務めるというなんとも贅沢なワークショップです。
さらに、NuxtLabs Japan のエキスパートの方々もワークショップのサポート役として参加してくれていました。

開催日時: 2023年10月25日(水) 13:30~ 18:30
開催場所: コワーキングスペース茅場町 Co-Edo

イベントの詳細は以下のページをご確認ください。
https://zenadvisor.io/nuxtlabs-japan/workshop

会場の雰囲気

ワークショップは、コワーキングスペース茅場町 Co-Edo で開催されました。親しみやすい雰囲気の中、Daniel さんに直筆のサインを書いてもらったり、記念撮影をしたり、参加者とスタッフとの距離の近さが感じられました。

気軽に写真撮影に応じてくれる Daniel さん

Daniel さん直筆のサイン

さらに、サプライズゲストとして、Nuxt コアチームの Harlan Wilton さんが登場し、ワークショップを盛り上げてくれました。

Harlan さんと私

ワークショップの内容

ワークショップは Daniel さんがデモを交えながら Nuxt の機能についてわかりやすく解説するという形式で進みました。
内容は Nuxt と Nitro の二つに大きく分けられ、以下のような特徴的な機能が紹介されました。

  • Nuxt
    • Volar
    • Routing
    • Nuxt DevTools
    • Middleware
    • Layout
    • client.js, server.js
    • useNuxtApp
    • definePageMeta
    • Nuxt Image
    • Nuxtr
    • useAppConfig
    • Nuxt Layers
    • runtimeConfig
    • useState
  • Nitro
    • useFetch
    • SWR
    • useStorage
    • Plugins
    • useSession

Nuxt3 の目玉機能から Nuxt エキスパートの方でも知らないような細かい機能まで丁寧に紹介してくれました。

この中でも、私は特に「Nuxt DevTools」に興味を持ちました。

Nuxt DevTools は Nuxt コアチームメンバーの Anthony Fu さんが中心となって開発している、Nuxt アプリケーションの構造を視覚的に理解することができるツールです。
詳しくは彼のブログ記事を見ていただけるとイメージが掴めると思います。

私が特に有用だと思った機能は、「コードジャンプ」機能と「Inspect」機能です。
Nuxt DevTools を使えば、ブラウザ上でコンポーネントをクリックすることで、そのコンポーネントのソースコードに素早くアクセスすることができます。
Inspect 機能は、Nuxt デフォルトのバンドリングツールである Vite が SFC(シングルファイルコンポーネント)をどのように処理しているのかをステップバイステップで確認できる機能です。
Inspect 機能のデモが行われたとき、参加者からは「おおー!」という感嘆の声が上がっていました。

Inspect 機能

Nuxt DevTools の一通りの機能は、公式の Playground で体験することができます。興味のある方はぜひ、試してみてはいかがでしょうか。

全編英語で進行されたワークショップでは、適宜通訳の方が Daniel さんの言葉を日本語に翻訳してくれたため、言語の壁を感じることなく内容を理解することができました。
参加者はワークショップ専用の GitHub リポジトリを通じて質問を投稿し、機能解説の合間に Daniel さんがそれに答えてくれました。質問は英語でも日本語でも受け付けていたのがありがたかったです。

機能紹介の後、ワークショップの締めとして、Nuxt と Supabase を使用した TODO アプリの作成に挑戦しました。Daniel さんと共に作業を進めることで、彼の卓越したタイピング速度とツール操作を間近で学ぶことができ、ツールの習熟度がいかに生産性に寄与するかを実感しました。

懇親会の様子

ワークショップの後は、懇親会が開催され、参加者は Daniel さんや Nuxt エキスパートたちと気軽に交流できました。Daniel さんからはまだ一般には公開されていない情報も聞くことができ、大変有意義な時間となりました。

懇親会の様子

おわりに

直接、著名なライブラリの作者と話ができる機会は、格別の学びがあると感じました。彼らの言葉は一次情報としての価値を持ちます。
日本において、国際的なエンジニアと交流できる機会は限られているため、今後もこのようなイベントには積極的に参加していきたいと考えています。

参加者全員で Nuxt ポーズ!


メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております!

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube  www.youtube.com

■メドピア公式note
style.medpeer.co.jp

Vue Fes Japan 2023 After Meetupを開催しました!

この画像は「Vue Fes Japan 2023 After Meetup」というイベントのバナーです。

MedPeerの開発をしている栗崎 (Ryohei Kurisaki (@0ryo0ryo) / X )です。

11月7日(火)に弊社オフィスにて、MNTSQ株式会社、株式会社hacomonoと3社合同でVue Fes Japan 2023 After Meetup を開催しました。

5年ぶりのオフライン開催となった Vue Fes Japan 2023の感想や思い出を語り合いました。

セッションのハイライト

メインセッション

Vue Fes Japan 2023のオーガナイザーであるkazuponさんによる 「Vue & Vite Rustify」のお話でした。

まずはViteの現状の課題についてお話されていました。

  • productionビルドが遅い
  • dev環境とproduction環境のbundleの一貫性がない

※ dev環境はesbuild, production環境はRollup

ViteはRollup互換のAPIを使用したRust製バンドラーRolldown*1をbytedance社のRspackチームと協力して開発を進めているそうです。

kazuponさんからはRolldownの構造についての解説や、webpackと比較したパフォーマンスの向上について話がありました。

また、Rust製のツールOXC について紹介されていました。

OXCはbytedance社のweb-infra-dev チームにより作成され、JavaScript、TypeScript向けのツールチェインになります。

Playgroundを始め、VSCodeの拡張機能も存在するそうです。

さらに、APIの提供もされており、今後もコミュニティとコラボし、より開発が進んでいくということでした。

終盤には、VSCode リポジトリを例にOXCを使ったLinterのが実行のデモされていました。

一瞬すぎて何が起きたのかわからない速さでLinterの実行が終わりびっくりしました!!

GitHubのREADMEにも記載があったので、私も手元でVSCodeリポジトリをcloneしLinterの実行をしてみました。 github.com

 $ npx oxlint@latest .

をディレクトリで実行すると、以下のような結果になりました。

Finished in 1.6s on 4560 files with 64 rules using 8 threads.
Found 1609 warnings and 0 error

1、2秒弱でリポジトリ内全てのソースコードの解析が終わりました(すごい!!)

ご紹介のあった、Rolldown、OXCを始め、すでに存在するvue-compiler等Rustを利用したツールが増えてきており、Rustの波がやってきているのを実感できました。

さらにエコシステムが強化され今後が楽しみだなと感じました。

LTの様子

「Vue Fes Japan を振り返る」 

トップバッターは弊社メドピアの岡澤さんの発表です。

Vue.jsクリニック*2で公開されていた質問とエキスパートの回答を聞き、過去のコンポーネント設計を振り返り、現在の考えをお話しされていました。

過去の失敗からの教訓

  • Pagesコンポーネントから書き始める
  • ファイル分割しすぎない
  • 共通処理以外は外部ファイルにしない

個人的にはコンポーネント設計に悩ましく同様の課題を感じていたため、岡澤さんの発表、Vue.jsクリニックでのエキスパートの回答のように、まずはシンプルに始め、リファクタリングしやすい小さいコンポーネントを作ることを意識したいなと思いました。

「UI フレームワークから始めるアクセシビリティ」

speakerdeck.com

続いては、MNTSQ株式会社の中島晃さんの発表でした。

Vue Fes Japan 2023での以下の2つのセッションを聞き、自身の関わるプロダクトに関するアクセシビリティの向き合い方についてお話しされていました。

アクセシビリティ対応を2つの具体的な方法で紹介されていました。

  1. 最低限の部分から対応

  2. オリジナルのデザインシステムで対応する

2つの方法にはそれぞれメリット、デメリットがあり、どちらもハードルは低くないため、 a11y*3に対応したFW、ライブラリを選定することが大切だというお話でした。

また、必要に応じて、独自のデザインシステムを利用するのが良いということでした。

個人的に印象的だったのが、MNTSQさんのビジョン「すべての合意をフェアにする」とa11y対応をやる意義を関連づけ待ったなしで対応したというのが素敵だなと思いました。

「Nuxt2 -> 3 を戦っていくには」

最後は、株式会社hacomonoのみゅーとんさんの発表でした。

Vue Fes Japan 2023のセッションを聞き、どこの会社もバージョンアップに苦労しているんだなという感想とVue Fes Japan 2023で得た知見について話されていました。

具体的にはNuxt 3 化の方法の知見をお話されていました。

  1. 一気に乗り換える
  2. Nuxt Bridge を導入
  3. 段階的に乗り換える

hacomonoさんは巨大リポジトリ、Nuxt Bridgeを使えない背景からもっともパワーのいる段階的に乗り換える方法を取ったそうです。

iframeを使い、Nuxt 2 側のページを開くという方法は驚きでした!

似たような話を聞いたなと思っていたのですが、Vue Fes Japan 2023のランチセッションで弊社の小林さんがVue2から3へのマイグレーションについても似たような対応方法のまとめを話されていましたね。

(こちらも併せてご覧ください。)

speakerdeck.com

パネルディスカッションの様子

kazuponさんとVue Fes Japan 2023のランチセッションで登壇された3名をパネリストに迎え、モデレーターをメドピアVPoTの平川さんが行いました。

登壇者のご紹介

  • メドピア株式会社: 小林さん
  • MNTSQ 株式会社: 安積さん
  • 株式会社hacomono: みゅーとんさん

テーマ1.「Vue.jsコミュニティと企業の関わり方」

いくつか話されていた内容をご紹介します。

Q 企業側に求めていることはありますか?

kazuponさん「Vueコミュニティの支援、フルタイムのコミッターが少ないため、支援があると嬉しいです。」

Q Vue Fes Japan 2023の登壇のきっかけは?

小林さん 「メドピアグループの多くのプロダクトでVueを使用しています。Vueを使っているため、報告とスポンサーシップをするのは当たり前の状態でした。」

安積さん「 会社の認知度向上のために行っています。 v-tokyoのイベントをきっかけに関与しやすくなりました。」

Q 企業からコミュニティへの貢献についてのお考えはありますか?

みゅーとんさん「自分が主導して、会社内のGitHubにPublic Organizationを作成して、公開したりしています。」

安積さん「eslintとか自分達が使う場面が多い、ユーティリティ的な機能はOSSで公開したいと思っています。」

安積さん「自分達が作っているものがVueでできているんよというのも公開していくといいのではと思います!最近だとOpenAIのサイトもVueで作られているんですよ。」

小林さん 「Apple 開発者向けのドキュメントページもVueで作られていますしね!」

kazuponさん「OSSではなくてもテックブログとかの記事公開することもコミュティへの貢献につながると思います。」

スポンサーで参加された企業だけでなく、個人スポンサーも行われていて、Vue Fes Japan 2023に参加して、多くの方がコミュニティへの貢献をされているなと思いました。

そして、このブログもコミュニティの貢献になったら嬉しいです 🙂

テーマ2.「WebFrontendを学んだ後のキャリアパス Now and Then」

時間が少しオーバーしてしまうほどの盛り上がりを見せたこちらのテーマについてもいくつかご紹介します。

Q WebFrontendを学んだ後のキャリアパスについてどうお考えですか?

安積さん「フロントエンドエンジニアを含む、 エンジニアチームのスキルマップを作成しています。」

※ Xでも公開されていました。

安積さん「マインドマップの近しい部分から勉強してみて、領域を広げていくのが良いと思います。 」

この後、登壇者の皆さんの過去の経験談がお話されました。

懐かしい技術と感じる方も多くいらっしゃったようで会場は沸いていました。

みゅーとんさん「好きなところを勉強していくのは大切だと思います。フロントエンドの見た目があって使い勝手の良さを追求できるのが好きです。それに加えて、開発者体験やデザイナーのデザインを再現できるのが良いと思います。」

小林さん「フロントエンドが好きで勉強を続けるのは大事です。私も中学生くらいからHP制作をしていまして、今も好きが高じてキャリアができています。」

個人的にはスキルマインドマップのお話がとても印象に残っております。

私自身、Ruby on Railsを使ったサーバサイドの開発がメイン業務ですが、業務の中でVueを使ったフロントエンドを始め、フロントエンドに興味を持ち、プライベートでは、Nuxt3を使ったアプリケーションなどを作成しています。

その時に、Ruby on Railsとの類似箇所や、接点になる部分などは、勉強もしやすく、理解しやすいことを痛感しました。

懇親会の様子

リアルイベントならでは懇親会の様子を写真を交えてご紹介します。

大量のピザとドリンクを手に交流を行いました。

メドベアチョコも作りました 🎉

登壇者を始め、多くの参加者と交流することができ、いい情報交換ができとても刺激的な時間になりました。

最後に

登壇者の皆さん、合同開催のMNTSQ株式会社、株式会社hacomonoの皆さんありがとうございました。

セッション、パネルディスカッションにもあったように、コミュニティとVueの関わりはとても強く、大切なものだなと感じました。

これからもVue、Nuxtのコミュニティが発展することを願っています。

来年のVue Fes Japanも楽しみにしています!!


メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております!

■募集ポジションはこちら

medpeer.co.jp

■エンジニア紹介ページはこちら

engineer.medpeer.co.jp

*1:現時点では、private repositryでの開発みたいです。

*2:Vue Fes Japan 2023で行われた、Vue.js に関して困っていること、素朴な疑問、ベストプラクティスなどをエキスパートに聞けるコーナー

*3:Web アクセシビリティの略語

Vue Fes Japan 2023にゴールドスポンサーとして参加しました!#vuefes

こんにちは、サーバーエンジニアの千葉です。

今回は日本最大級のVue.jsのカンファレンス「Vue Fes Japan 2023」に参加してきましたので、そのレポートをお届けしたいと思います。

私は今年が初参加でしたが、ブースやセッショントラックがいっぱいになるほどの盛り上がりを見せていました。

企業名、参加者の名前がずらり

ゴールドスポンサーとして

メドピアは今年、ゴールドスポンサーとして協賛させていただきました。それに加え、セッションルームネーミングライツスポンサーやスペシャルランチスポンサーとしても協賛しました。

セッションルームネーミングライツスポンサー

セッションルームネーミングライツスポンサーでは「メドピアトラック」という名前のルームを開設し、満席で立ち席ができるほど多くの方に来場していただきました。

メドピアトラックの様子

スペシャルランチスポンサー

スペシャルランチスポンサーでは、フロントエンド テックリーダーの小林さんが「Vue 2のEOLまで二ヶ月ですが進捗どうですか?」というタイトルで登壇しました。

Vue2 EOLの2023/12/31が迫る中、メドピアの各サービスがどのようにVue3へのmigrationにアプローチしているのかについて紹介しました。

まだVue2を使っているという参加者も多く見受けられたため、Vue3化への対応方針を考える上で参考になった方も多かったのではないでしょうか。

フロントエンド エンジニアの小林さんが登壇

speakerdeck.com

スポンサーブース

メドピアはスポンサーブースも出展し、多くの方がアルコールパッチテストを実施してくださいました。

お酒を飲める方が半数以上という結果となったので、アフターパーティでも安心してお酒を楽しめたはずですね👍

Vue開発者のEvanさんにもアルコールパッチテストを試してもらいました!

セッションの様子

今回のVue Fes Japanでは34ものセッションが行われました。その中で私が聞いたセッションを3つほど紹介したいと思います。

Vue.jsを活用して開発リードタイムが1/3になった話

Vue.jsを活用して開発リードタイムが1/3になった話ではなく、価値を生む技術提案についてのセッションです。 (登壇者曰く、急遽話したいことが変わったらしい)

提案の質がソフトウェア改善の成功要因になるということを、自身の経験則を元に話していただきました。開発内容ではなく、開発前の提案に関するプレゼンを聞くことは初めてだったため、とても新鮮で勉強になるセッションでした。

speakerdeck.com

vuefes.jp

Vueを使ってGrid Systemを実装した話

Vue.jsを使ってGrid Systemをライブコーディングするセッションです。

Grid Systemの実装はmedia queryにおける仕様上の問題もあり、上手く実装・運用できないことが多々あるため、セッションとして話すことにしたそうです。

個人的には業務でGrid Systemを使った実装を行い、苦戦したという背景があったのでとても参考になった回でした。

speakerdeck.com

vuefes.jp

18営業日で350コンポーネント規模のVueアプリにデザインシステムを導入する方法

18営業日で350コンポーネント規模のVueアプリにデザインシステムを導入する方法や知見を共有するセッションです。

技術的知見

  • AST を使用して事前にできる限り自動でマイグレーションした上で判別できない部分に全て TODO コメントを自動付与
  • ESLint のカスタムルールを実装してできる限りレビューは自動化
  • デザインシステムが壊れていないか確認するために VRT を実施
  • Autify による E2E テスト

プロジェクト管理上の知見

  • 手作業は短期集中でタスクのスイッチングコストをゼロに
  • 進捗は数値で管理
  • マニュアルテストを複数回実施してバグに対処
  • 最後にデザイナーとペアプロで細かいデザインを修正

システム導入ではBig Bangリリース(一度に大きな変更を加えるリリース手法)を採用したとのことで、その知見を聞けたことは個人的に一番の収穫でした。

speakerdeck.com

vuefes.jp

アフターパーティの様子

アフターパーティでは、Vue.js 日本ユーザーグループ代表のkazuponさんやNuxtコアメンバーのHarlanさんといったプロフェッショナルな方々とも交流することができました。

NuxtコアメンバーのHarlanさんと

まとめ

文字通り「Fes = お祭り」のように大盛り上がりのカンファレンスでした。

個人的には業務でフロントエンドを触る機会があり、Vueに対する熱が高まったため参加しましたが、とても良い経験と機会になりました。

フロントエンド少し触っただけ、触ったことないけど興味がある程度でも、分かりやすいセッションとお祭りのような雰囲気を味わうことができるため、まだ参加したことがない方は来年参加してみてはいかがでしょうか。

最後に

2023年11月7日(火)にメドピア株式会社、MNTSQ 株式会社、及び株式会社 hacomono でVue Fes Japan 2023 After Meetupをメドピアオフィスでオフライン開催します。

Vue.js 日本ユーザーグループ代表のkazuponさんを特別ゲストとして迎え、セッションやパネルディスカッションといったコンテンツを用意しています。

こちらのイベントもご興味がある方はぜひご参加ください!

medpeer.connpass.com


メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております!

■募集ポジションはこちら

medpeer.co.jp

■エンジニア紹介ページはこちら

engineer.medpeer.co.jp

Kaigi on Rails 2023 セッションレポート #kaigionrails

こんにちは!サーバーサイドエンジニアの近藤です。

Kaigi on Rails 2023 が、10月27日から10月28日にかけて開催されました。 2020年から続くKaigi on Railsですが、今年が初のオンライン&オフライン同時のハイブリット開催となります。 メドピアはゴールドスポンサーとして協賛し、15名ほどのメンバーが現地で参加しました。

当記事では、現地で聴いたセッションのうち印象に残った発表をピックアップしてご紹介したいと思います。

Exceptional Rails

speakerdeck.com

メドピアで技術顧問をしていただいている前島さんによるセッションです。 Railsにおいて例外をいかにして扱うか、というお話でした。

Railsコード中の例外処理ひとつ取っても、考えることは数多くあります。

  • いつ例外を発生させるか
  • 発生した例外をいつどのようにrescueするのか
  • 通知が必要な例外をどのように開発者に通知するのか
  • エラーページをユーザにどう表示するのか

エラーを扱う際のこれらの観点について、方針とその理由を身近な具体例を交えながら解説していました。

個人的に印象的だった話題は、外部サービス起因のエラーの通知についての話題です。 エラーを通知するか否かについて

  1. エラーが起きる状況を考えてみる
  2. そのエラーが開発者側では対応できないこと(外部サービスの不具合など)が原因で起きるものであれば(即時の)通知はしない
    • 対応できないエラーが来てもノイズになるため
    • レベルをwarningなどに設定し、短期間に頻発するようであれば通知するのはあり

といった判断基準を紹介しており、通知に対する考え方の面で学びになったお話でした。

全体的に、今後例外を扱う際にぜひ見返したくなるようなセッションでした。

Update Billion Records

speakerdeck.com

レコード数が50~60億という巨大なテーブルに対してカラムを追加し埋める際に、なにを考えどのような手段を取ったかについてのお話です。

この巨大なテーブルを更新するにあたって、
「更新中にサービスを止めてはいけない」
「更新処理はいつでも中断・再開できなければならない」
などの要件がありました。

適切な更新手段を見つけるために、最初は既存手法の踏襲から始め、

(要件や現状の)整理 →(手段の)発案 → 検証

というサイクルを繰り返し、最終的にたどり着いた手段は「更新対象をqueueで管理し非同期jobで少しずつ更新する」というものでした。

発表の後半で、スピーカーのtokutomiさんは今回の改修を次のように振り返っています。

最終的な構成も参考になるものでしたが、それと同じくらい、 最終的な構成に至るまでの改善プロセスも参考になる発表でした。

Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術

speakerdeck.com

弊社エンジニアの草分さんが「Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術」というタイトルで登壇しました。

[草分さん]「Hotwireという名前をご存知でしょうか?」

[会場] 「👏 👏 」

[草分さん]「では、Hotwireを本番環境等でちゃんと使っていましたでしょうか?」

[会場] 「......」

[草分さん]「🤯」

という笑い溢れる導入から始まったこのセッションは、 なにかと避けられがちなHotwireを実プロダクトで採用した話と、 その際にどのようにHotwireを使い時短を実現したかについての発表でした。

タイトルにもある「時短」について、

  • create (= フォームのsubmit) 前の確認画面
  • フォームの動的切り替え

という2つの状況を例に、 Hotwireを使った時短実装術をデモと共に紹介していました。

確認画面をモーダルで出すことでユーザー入力の再描画処理を省けたり、 Hotwireを使うことでリッチなUIもお手軽に実装できたとのことです。

スライドの左半分がデモ画面になっている超絶プレゼン技術でした

Hotwireをオススメできる状況として

  • 画面側がHotwireで十分実現できるとき
  • 社内向けの管理画面
  • バックエンドエンジニアが多いプロジェクト

を挙げており、実際にヤクチエの開発で採用した実例も紹介していました。

スライドの所々に小ネタが散りばめられており、会場から笑い声が絶えないセッションでした。

32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方

speakerdeck.com

既存システムを動かしたままREAD/WRITEの多いテーブルのカラムを置き換えるために、MySQLのオンラインDDL機能(ロックを取得せずにマイグレーションを行える機能)を利用したお話です。

一言で「オンラインDDL機能を利用」といっても、考慮すべき点は数多くあります。

たとえばオンラインDDLそのものに対する注意点として、

  • 本来はオンラインDDLの対象になる操作であっても、場合によってはそうならない場合がある
  • オンラインDDLは一部の期間でメタデータロックというロックを取得するため、ロックを取る他の処理の確認が必要

などの注意点を紹介していました。

また、リリースフローに関する注意として、 コンテナを用いてBlue/Greenデプロイをしているような環境では、
「マイグレーションの完了タイミング」と
「コンテナの入れ替わりタイミング」にずれが生じてしまいます。

これにより、古いアプリが新しいデータベースを見に行ってしまう状況が発生するため、 単純に「カラム名の変更」をするのではなく「カラムの追加 → 役割の置き換え → 古いカラムの削除」という手順を踏んでリリースしたとのことです。

実際のリリースでは下図のような段階的な対応を行ったとのことで、このリリースに万全の体制で臨んだことが伺えます。

現在私が携わっているプロダクトでも大きなテーブルのマイグレーションには苦しんでおり、オンラインDDLの注意点や段階的なリリース手法など、ぜひ今後の参考にしたいセッションでした。

おわりに

全体的なセッションの傾向として、実際のプロダクト開発に関連する内容のものが多くを占めており、 drinkupや懇親会の会場でもプロダクト開発の話題が数多く飛び交っていたように思えます。 Kaigi on Railsを軸にして、Railsまわりの知見の交換が行われているのを感じました。

今回のイベントで得た知見を、私も日々のプロダクト開発に活かしたいなと思いました。 Kaigi on Railsへの参加は初めてだったのですが、とても充実した2日間でした!

Afterイベントやります!

connpass.com

11/9(木)の19時から、メドピア株式会社、株式会社スマートバンクさん、株式会社マイベストさんの3社合同で、アフターイベント「After Kaigi on Rails LT Night」を行います。

各社から1名ずつのLTと公募によるLTが3つの、計6つのLTが行われる予定です。 会場はメドピアのオフィスで、最寄り駅は東銀座駅となります。 RubyやRailsの関連技術について、食事とともにお話できる場になればなと思います。

ご興味ありましたら上記リンクからぜひご参加ください!


是非読者になってください!


メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております!

■募集ポジションはこちら

medpeer.co.jp

■エンジニア紹介ページはこちら

engineer.medpeer.co.jp