今年の9月にこれまで働いていたメドピア株式会社を退職しました。そして翌月の10月にラクスル株式会社に入社しました。

入社して既に1ヶ月半ほど経ちましたが、まだ記憶が新鮮なうちに今回の転職活動について記録しておきます。

なぜ転職したのか

私が所属していたチームでは、主にプロダクト横断でフロントエンド関連の課題の解決に取り組んでいました。 直近ではデザインシステムの導入や UI ライブラリの構築に携わっていましたが、それらに区切りがつくタイミングだったことがきっかけとしては大きかったです。

また、私は製薬会社の MR としてキャリアをスタートしており、前職でも医療に関するプロダクトを開発していましたが、それとは異なるドメインで社会課題に向き合ってみたい気持ちも強く、今回の転職活動に踏み切りました。

転職活動について

期間

転職活動の期間としては、約2ヶ月間取り組みました。 具体的なスケジュールは、キャリア棚卸しを本格的に始めたのが6月初旬で、転職活動を完全に終えたのが8月中旬でした。

媒体

キャリアエージェントは Findy、ビズリーチ、Forkwell の3つを利用しました。また、リファラル採用や直接コーポレートサイトから応募した企業もありました。

Forkwell

当初は Forkwell を利用する予定はなかったのですが、転職活動を始めて少しのタイミングで赤川さんの登壇を拝見し、すぐに面談の予約を入れました。IT エンジニアのキャリアオタクと呼称されるのが納得できるくらい、公開されている記事も濃い内容のものばかりでとても面白いです。

• テックリードはキャリアの分岐点。取材でわかった6系統の役割と市場価値のリアル
• あなたは上位何％？ITエンジニアの年収分布まとめ【データベース完全公開】
• 本当にエンジニアバブルは崩壊したのか？

最終的に最も頼らせて頂いたのが Forkwell で、キャリアの壁打ちや職務経歴書の添削、選考の進捗管理などもご協力いただき、非常に心強かったです。 特に、転職活動は孤独で不安になることが多いのではないかと思いますが、Forkwell ではエンジニア経験のある方に親身になって自分のキャリアについて考えていただき、終始とても心強かったです。

以下は選考の進捗状況を管理していたスプレッドシートで、実際に Forkwell で用意してくださったフォーマットを活用しました。 カジュアル面談を受けて、実際に選考に進んだのは9社でした。

最終的に入社を決めたラクスルは Forkwell 経由での応募ではなかったのですが、それでも選考に際しては多分にご協力いただき助かりましたし、感謝しております🙏

転職活動を振り返って

転職活動を振り返ると、短期間ではあったものの非常に中身の詰まった活動期間だったと改めて思います。

企業の中の人と話ができる

普段仕事をしていて、直近ではなかなか社外の人と話す機会を得られていなかったこともあり、社外のエンジニアや役員の方と話す機会を頂けるのは貴重だと感じました。 特に子どもが生まれてからは勉強会への参加にも消極的になっていたので、色んな会社の技術的な話を多く伺うことができたのは、純粋に勉強になることが多く楽しかったです。

また、複数社の選考を通して自分を見つめ直すきっかけにもなりましたし、最終的な意思決定をする際には最後の最後まで本当に悩みました。

キャリアを振り返るきっかけになる

普段業務に忙殺されていると、なかなかキャリアを振り返る機会をつくれないです。 ただ、転職活動のたびに思うことではあるのですが、1年も経つとそれまでやっていたことを詳細に思い出すことは難しくなるので、転職意向の有無に関わらず、定期的にキャリアを振り返る機会を設けることが大事だと改めて感じました。

最後に

ラクスルでは、屋台骨として成長し続けるプロダクトの商品開発から組織づくりまで積極的に関わっていきたいと思っています。数多くの課題の解決に向けてトライできる環境ですので、興味がある方はお気軽にご連絡ください！

はじめに

プロダクト開発において、コーディング規約を定めておくことはコードの品質を保つ上で重要です。しかし、ドキュメンテーションを行なう場合にあがるのがメンテナンスの問題です。ドキュメントは定期的に見直して更新していく必要がありますが、更新するのも一定のコストがかかります。更新されないことでドキュメント自体が負債になるケースも考えられるでしょう。

基本的には開発ルールを 意識せずに 遵守していくために、Linter や Formatter の力を借りるのがベストだと考えています。

今回は ESLint のカスタムルールで指定した拡張子以外のファイルを配置した場合にエラーを発生させる仕組みを作ったのでご紹介します。

手順

今回は ESLint のプラグインとしてルールを追加し、package.json で依存関係として管理する方法を選択しました。

プラグインを作成する

次のコマンドを実行し、プラグインのひな形を作成していきます。 便宜上ルートディレクトリにディレクトリやファイルを作成していますが、より適切なディレクトリに配置できるとよいでしょう。

mkdir eslint-custom-rules
cd eslint-custom-rules
npm init -y
touch index.js
mkdir rules
touch rules/restrict-extensions.js
mkdir tests
touch tests/restrict-extensions.spec.js

ESLint のプラグインとして package.json で管理したいため、追加した eslint-custom-rules ディレクトリに移動して npm init -y コマンドで初期化しています。

package.json がデフォルトで追加されるので、name を eslint-plugin-<plugin-name> のフォーマットに変更します。（他のプロパティは初期値のままです）

{
  "name": "eslint-plugin-custom-rules",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

main に指定している index.js が Entry point となるため、Export するルールを追加します。

module.exports = {
  rules: {
    "restrict-extensions": require("./rules/restrict-extensions"),
  },
};

ルールの記述

本題であるカスタムルールを書いていきます。フォーマットは ESLint の Custom Rules ドキュメントを参考にしています。

"use strict";
 
module.exports = {
  create: function (context) {
    return {
      Program: function (node) {
        const options = context.options;
        const filename = context.getFilename();
 
        for (const { directory, extension } of options) {
          if (directory && extension) {
            if (filename.includes(directory) && !filename.endsWith(extension)) {
              context.report({
                node,
                message: `'${directory}'ディレクトリにファイルを配置する場合、ファイルの拡張子は'${extension}'としてください。`,
              });
            }
          }
        }
      },
    };
  },
};

ルールのオプションとしてディレクトリと拡張子を渡します。また、いくつかルールを適用させたいディレクトリがある場合を考慮し、復数のオプション渡すことができるようにしています。

このルールを適用することで、ディレクトリ配下に指定した拡張子以外のファイルが検知された場合にエラーが発生します。

テストの追加

ESLint のバージョンアップやルール内容の更新を考慮してテストを用意しておきます。Testing library は jest を想定しています。

"use strict";
 
import { RuleTester } from "eslint";
import Rule from "../rules/restrict-extensions";
 
describe("restrict-extensions", () => {
  const tester = new RuleTester({
    parserOptions: { ecmaVersion: 2020, sourceType: "module" },
  });
 
  tester.run("restrict-extensions", Rule, {
    valid: [
      {
        code: "let validExtension;",
        filename: "app/javascript/packs/file.ts",
        options: [{ directory: "app/javascript/packs/", extension: ".ts" }],
      },
      {
        code: "let validExtension;",
        filename: "app/javascript/components/common/file.vue",
        options: [
          { directory: "app/javascript/types/", extension: ".ts" },
          { directory: "app/javascript/components/", extension: ".tsx" },
        ],
      },
    ],
    invalid: [
      {
        code: "let invalidExtension;",
        filename: "app/javascript/packs/file.js",
        options: [{ directory: "app/javascript/packs/", extension: ".ts" }],
        errors: [
          {
            message:
              "'app/javascript/packs/'ディレクトリにファイルを配置する場合、ファイルの拡張子は'.ts'としてください。",
          },
        ],
      },
      {
        code: "let invalidExtension;",
        filename: "app/javascript/components/common/file.ts",
        options: [
          { directory: "app/javascript/types/", extension: ".ts" },
          { directory: "app/javascript/components/", extension: ".tsx" },
        ],
        errors: [
          {
            message:
              "'app/javascript/components/'ディレクトリにファイルを配置する場合、ファイルの拡張子は'.tsx'としてください。",
          },
        ],
      },
    ],
  });
});

テストを実行し、成功することを確認します。事前に filename や options の値を変更して意図的に失敗させておくとより安心でしょう。

> jest --runInBand --runTestsByPath eslint-custom-rules/tests/restrict-extensions.spec.js
PASS  eslint-custom-rules/tests/restrict-extensions.spec.js
  restrict-extensions
    restrict-extensions
      valid
        ✓ let validExtension; (14 ms)
        ✓ let validExtension; (1 ms)
      invalid
        ✓ let invalidExtension; (2 ms)
        ✓ let invalidExtension; (1 ms)
 
Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        1.221 s
Ran all test suites within paths "eslint-custom-rules/tests/restrict-extensions.spec.js".
Done in 5.46s.

ルールを適用させる

ルールを適用させたいリポジトリの package.json に次のような記述を追加し、開発時の依存関係としてインストールします。

  "devDependencies": {
    "eslint-plugin-custom-rules": "file:./eslint-custom-rules",

.eslintrc.js にプラグイン・ルールを追加することで、カスタムルールが適用されます。

module.exports = {
  plugins: ["custom-rules"],
  rules: {
    "custom-rules/restrict-extensions": [
      "error",
      { directory: "app/javascript/packs/", extension: ".ts" },
      { directory: "app/javascript/components/", extension: ".tsx" },
    ],
  },
};

.tsx 拡張子に制限しているディレクトリ配下に .js 拡張子のファイルを配置すると次のようにエラーメッセージが表示されました。

最後に

今回はプラグインとしてカスタムルールを作成する方法をご紹介しました。

ESLint の設定ファイルは今後 eslintrc から Flat config が推奨されることが公式ブログの記事で発表されました。Flat config に移行することで eslint.config.js 内でカスタムルールを直接 import できるようになります。Flat config をすぐに適用できる環境であれば、今回ご紹介した方法ではなくそちらを使う方がよいでしょう。

既存の ESLint のプラグインでは満たせないような仕組みが柔軟に作れるので、今後も積極的に使っていきたいです。

前置き

2023 年 1 月 27 日に実施した社内勉強会でのポストを一部改変して転記しています。

概要

現在 Vue.js を使っている各プロジェクトにおいて、Vue 2 → Vue 3 へのアップグレードが進行しています。 このアップグレードにおける破壊的変更は非常に多く、今後フロントエンド開発を継続する上での学習コストは少なくないため、Vue 3 における主要機能やアップグレードすることによるメリットを Vue 2 までの機能と比較しながら解説していきます。

Vue 3について

Vue 3 は 2020 年 9 月 19 日にリリースされました。2023年01月27日現在の最新バージョンは v3.2.45です。 Vue 2 と比較したメリットはざっくり次の通りです。

• Composition API などの主要機能追加によるコードの最適化
• 全面的な TypeScript のサポート
• ビルド後のバンドルサイズが大きく改善したことによるパフォーマンスの向上

コードの最適化

Vue 2 では Options API が主に利用されていましたが、Composition API に変更することで次のようなメリットがあります。

• JavaScript らしい記法でコンポーネントを記述できる
• フレームワークにそこまで依存しない記法なので、変数や関数の型定義がしやすい
• リアクティブな値（ref, reactive, computed）やそれに関するロジックが UI コンポーネントに依存しない
  • 再利用性が向上し、Pure な JS/TS の関数になるためより testable になる
• ライフサイクルフックが少し単純になった

また、Vue 3.2 で追加された <script setup> 記法を使うことでよりコードがシンプルに記述できるようになります。

JavaScript らしい記法でコンポーネントを記述できる

Options API では、ボイラープレート的なフレームワークに依存した記法を覚える必要がありました。

export default Vue.extend({
  data: () => ({
    name: "",
  }),
  methods: {
    input(value) {
      this.name = value;
    },
  },
  computed: {
    call() {
      return `${this.name} 様`;
    },
  },
});

Composition API を利用することで、フレームワーク独自の記法が少なくなるので、より JavaScript らしいコードでコンポーネントを記述できるようになります。

export default defineComponent({
  setup() {
    const name = ref("");
    const input = (value) => {
      name.value = value;
    };
    const call = computed(() => {
      return `${this.name} 様`;
    });
 
    return { name, input, call };
  },
});

const, let などの JavaScript のキーワードを用いて変数や関数を宣言できるので、setup 内のコードは非常に記述しやすくなります。

リアクティブな値やロジックが UI コンポーネントに依存しない

setup 内で宣言するリアクティブな値や関数は、UI コンポーネントから切り離すことができます。

export default const useForm = () => {
    const name = ref('')
    const input = value => {
      name.value = value
    }
    const call = computed(() => {
      return `${this.name} 様`
    })
 
    return { name, input, call }
}
 
// Vue コンポーネント側
export default defineComponent({
  setup() {
    const { name, input, call } = useForm()
 
    return { name, input, call }
  }
})

コンポーネントに関係する値やロジックを独立できるので、単体テストが書きやすくなります。 また、複数コンポーネント間で値やロジックの使いまわしができるようになるのもメリットです。

ライフサイクルフックが単純になった

refs: ライフサイクルフック

beforeCreate, created がなくなり、本来これらのライフサイクルに書かれていたロジックは setup 内で直接記述するようになりました。

export default defineComponent({
  setup() {
    // 従来の created のタイミングで実行される
    console.log("Component is created!");
    // mounted
    onMounted(() => {
      console.log("Component is mounted!");
    });
  },
});

Vue 3.2 で追加された記法について

Vue 3.2 からは <script setup>というシンタックスシュガーが追加され、よりシンプルにコンポーネントを構成できるようになります。 これまでの記法と比較することで違いがわかりやすくなるので、順を追ってコードを比較していきましょう。 （それぞれのタイトルが Playground のリンクになっています）

Options API

<template>
  <form method="post">
    <label for="name">Name</label>
    <input id="name" v-model="name" type="text" />
    <input type="submit" />
  </form>
</template>
 
<script lang="ts">
import Vue from 'vue'
 
export default Vue.extend({
  data: () => ({
    name: '',
  }),
  methods: {
    input(value) {
      this.name = value
    },
  },
  computed: {
    call() {
      return `${this.name} 様`
    },
  },
}
</script>

Composition API

<template>
  <form method="post">
    <label for="name">Name</label>
    <input id="name" v-model="name" type="text" />
    <input type="submit" />
  </form>
</template>
 
<script lang="ts">
import { defineComponent, ref, computed } from "vue";
 
export default defineComponent({
  setup() {
    const name = ref("");
    const input = (value) => {
      name.value = value;
    };
    const call = computed(() => {
      return `${this.name} 様`;
    });
 
    return { name, input, call };
  },
});
</script>

<script setup>

<script setup lang="ts">
import { ref, computed } from "vue";
 
const name = ref("");
const input = (value) => {
  name.value = value;
};
const call = computed(() => {
  return `${this.name} 様`;
});
</script>
 
<template>
  <form method="post">
    <label for="name">Name</label>
    <input id="name" v-model="name" type="text" />
    <input type="submit" />
  </form>
</template>

とてもシンプルになりました🙌

一度 Composition API の記法でコードを書けるようになれば、<script setup> 構文に全く違和感なく、むしろ気持ちよく移行できるはずです。 公式のサンプルコードを見てもわかると思いますが、script → template の順序に変わっているので、本稿のサンプルコードもそちらに準拠しています。 ちなみに逆の順序でも問題なく動くので、Playground で試してみてください。

Language server

これまで Vue の Language server は vuejs / vetur でしたが、<script setup> 構文には対応していないため johnsoncodehk / volar の利用が推奨されています。

以下公式ツイート https://twitter.com/vuejs/status/1429195877365780486?s=20&t=s8ZKmwmrabCWU7hhsx0eZw

Components

これまではテンプレート内で import した components 使うには props などの並びで一度列挙して登録する必要がありましたが、 import するだけで直接利用できるようになりました。

<script>
import MyComponent from "./MyComponent.vue";
 
// これまでは登録する必要があった
export default {
  components: { MyComponent },
};
</script>
 
<template>
  <MyComponent />
</template>

<script setup>
// import のみでコンポーネントを使える
import MyComponent from "./MyComponent.vue";
</script>
 
<template>
  <MyComponent />
</template>

props, emit

props と emit については defineProps, defineEmits を利用することで <script setup> 構文内で宣言ができます。 これまでは props, emit の型定義や型推論や完全ではありませんでしたが、Pure な TypeScript の記法で宣言ができるようになるので自然に型を定義でき、型推論もされるようになります。

<script>
export default {
  props: {
    name: { type: String },
  },
  methods: {
    onInput(target) {
      this.$emit("input", target.value);
    },
  },
};
</script>

<script setup lang="ts">
const props = defineProps<{ name: string }>();
// デフォルト値を入れたい場合は withDefaults を使う
// const props = withDefaults(defineProps<{ name: string }>(), { name: '太郎' })
 
const emit = defineEmits<{ (e: "input", value: string): void }>();
 
const onInput = ({ target }: { target: HTMLInputElement }) => {
  emit("input", target.value);
};
</script>

definePropsや withDefaults、 defineEmits は <script setup> 内でのみ使用可能なコンパイラマクロなので、インポートせずに利用できます。

最後に

今回紹介できなかった機能もたくさんあるので、ぜひ公式ドキュメントなどをチェックしてみてください！

また、TypeScript サポートが手厚くなっていることで今後も TypeScript のコードは増えていくと思うので、ドキュメントを読んでみたり 実際に手を動かしてみる のもいいと思います👩‍💻

vuejs-challenges は Vue 3 対応しているので、課題にトライしていって今回紹介したような記法に慣れておくのもいいですね👍

参考資料

• Composition API FAQ
• 2022年の最新標準！Vue 3の新しい開発体験に触れよう
• Composition APIを使って感じた「これどうなの？」
• 機能開発を止めずに、500コンポーネント規模の Vue 3 移行を完了させた開発プロセス
• 【Vue.js 3.2】<script setup> 構文がすごくすごい

VoiceOver とは MacOS や iOS に標準でインストールされているスクリーンリーダーです。VoiceOver を利用すれば、画面上にあるテキストや画像などの情報を音声で読み上げてくれるため、画面を見なくてもデバイスの操作ができるようになります。

なぜ使ってみたのか

スクリーンリーダーを一度使ってみたかったからです。

私は普段の業務でプロダクトを開発しているチームに所属し、Web サービスのバックエンドからフロントエンドまで開発を担っています。

プロダクトを利用するユーザーは非常に多様であり、より多くのユーザーにとって使いやすく不便さを感じさせないプロダクトを目指しています。

主な操作をスクリーンリーダーを介して行なっている人に対するプロダクトの使いやすさを考慮する上で、実際に自分が使ってみることは不可欠だと考えました。

VoiceOver の使い方

VoiceOver をオンにする方法は複数あります。

MacOS

• ショートカットキー
  • Command ＋ F5 キーを押す
  • Command キーを押したまま Touch ID を素早く 3 回押す
• システム設定
  • サイドバーのアクセシビリティから VoiceOver を選択し、オンにする
• Siri に「VoiceOver をオンにして」と話しかける

iOS

• 設定
  • アクセシビリティ → VoiceOver を選択し、オンにする
• コントロールセンターに追加する
• アクセシビリティのショートカットに設定して使用する
• Siri に「VoiceOver をオンにして」と話しかける

Siri は設定次第では音声入力のみで利用開始できる点が優れていると感じました。

実際に使ってみて

実際に画面を見ないで音声案内に従い、iPhone, MacBook を使って普段の操作をある程度再現できました。

一方で、実際に使ってみて操作するハードルも多分に感じました。

• 操作前に音声を聞き取り理解することが前提である
  • 聞き取り理解する行動がオーバーヘッドとなり、操作に時間がかかる
  • 音声を正しく理解できないと意図した操作に繋がらない
  • アプリケーションやブラウザ上のページによっては、操作する上で必要十分な情報を音声として読み上げてくれない

特に後半の項目の改善はプロダクトの開発者次第なので、普段からスクリーンリーダーによってどのように読み上げられるのかを考えていく必要がありそうです。

まとめ

今回は複数のデバイスで VoiceOver を使ってみましたが、多くの気づきを得られました。

リンクやボタンのテキスト、要素によっては WAI-ARIA を使って音声のみでも操作可能なマークアップをすることが望ましいですが、実際にスクリーンリーダーを通して発見できる改善点も必ずあるはずです。

より多くの人に価値を届けられるプロダクト開発に繋がるはずなので、今後も開発する際には積極的に使っていこうと思いました。

参考資料

• https://support.apple.com/ja-jp/guide/voiceover/welcome/mac
• https://support.apple.com/ja-jp/guide/iphone/iph3e2e415f/iOS

CSS Nesting とは

CSS で Sass や Less のような入れ子構造での記述を可能にするものです。

例えば

<div class="container">
  <p class="container__text">Hello</p>
</div>

このような HTML に CSS を当てる場合、

.container {
  padding: 16px;
}
 
.container .container__text {
  font-size: 12px;
}

これまでは親子関係にあるセレクタでも上記のように同じ階層に書いていましたが、CSS Nesting を使うと次のような記述ができるようになります。

.container {
  padding: 16px;
 
  .container__text {
    font-size: 12px;
  }
}

セレクタの階層構造がネストによって表現され、適切に利用することで保守性が高まります。

ネストの記法

Sass を書いたことがあれば、基本的には同じようにネストして書くことができます。

クラスや ID を選択するセレクタの場合

冒頭で書いたような記法がスタンダードですが、Nesting Selector である & を Prefix として付与できます。

.container {
  padding: 16px;
 
  & .container__text {
    font-size: 12px;
  }
}

main, h1 といった要素を選択するセレクタの場合

要素をネストする場合は & を付与したうえで選択します。

<main class="container">
  <h1>Hello</h1>
</main>

このような HTML に CSS を当てる場合、

.container {
  padding: 16px;
 
  & h1 {
    color: blue;
  }
}

このようにすることで、.container の子要素である h1 をスタイリングできます。

一部のブラウザでは CSS Nesting のサポートが進んでおり、次のように & なしで要素を選択できます。

.container {
  padding: 16px;
 
  h1 {
    color: blue;
  }
}

12/19 時点でサポートを開始したブラウザとバージョンは次の通りです。

• Chrome 120(2023/12/8~)
• Safari 17.2(2023/12/11~)
• Firefox 117(2023/8/29~)

+, ~, > といった結合子を使って選択するセレクタの場合

<div class="container">
  <p class="container__text">Hello</p>
  <div>
    <p class="container__text">こんにちは</p>
  </div>
</div>

このような HTML の場合で、.container の子要素の .container__text のみ選択したい場合は次のように書くことができます。

.container {
  padding: 16px;
 
  > .container__text {
    font-size: 12px;
  }
}

擬似クラス : や疑似要素 :: を使って選択する場合

Sass と同様に & に連結することで選択できます。

button {
  &:hover {
    opacity: 0.5;
  }
}

has() は本日 12/19 に Firefox 121 でサポートが開始されたことにより、すべてのモダンブラウザで利用できるようになりました。 このような関数擬似クラスを利用する場合は次のように書くことができます。

html {
  &:has(dialog[open]) {
    overflow: hidden;
  }
}

サポート状況

https://caniuse.com/css-nesting

関連資料

• https://www.w3.org/TR/css-nesting-1/
• https://drafts.csswg.org/css-nesting/

今年の 3 月に子を授かり、半年間の育休を取得しました。出産が 2 週間早まってしまったため、育休の開始時期も早まり出産前後は落ち着かなかったです。 特に子に関するさまざまな手続きに関しては、提出先や期限が複数あり煩雑であったため、主にどのような手続きがあったのか振り返っておきます。

職場での手続き

基本的には会社からの指示に従って進めていきましたが、同僚への引き継ぎ等も並行して行なうことから、できるだけ余裕を持って進めるとよいでしょう。

具体的には、次のような手続きがあります。

• 出産報告
• 育児休業申請
• 扶養追加申請
• 各出生関連書類の提出
  • 夫婦共同扶養収入額確認票
  • 母子手帳のコピー
  • 育児休業にかかる記載内容に関する確認書

職場によって提出書類や手続きが異なる場合があります。 健康保険証の発行や育児休業給付金の申請に関して、健康保険組合ではなく国民健康保険である場合には役所での手続きが必要になるようです。

その他に、母親の場合は出産育児一時金や出産手当金の申請が必要です。特に出産手当金に関しては、職場に提出する請求書を産院で事前に記載してもらう必要があり、私の依頼先の病院では返却までに 1 週間ほど要したので、出産前に請求書を用意しておき早めに産院と連携しておくとスムーズでしょう。

役所での手続き

役所においてもいくつか手続きを進める必要がありますが、ものによって担当課が異なります。役所によっては課名が異なる場合があるのでご了承ください。

出生届

• 担当課
  • 戸籍課
• 期限
  • 生まれた日から 14 日以内
• 必要なもの
  • 産院でもらえる出生届
  • 母子手帳
  • 印鑑

児童手当金

自治体によっては郵送での申請が可能です。

• 担当課
  • こども家庭支援課
• 期限
  • 生まれた日の翌日から 15 日以内
• 必要なもの
  • 申請用紙
  • 印鑑
  • 健康保険証
  • 通帳又はキャッシュカードのコピー
  • 申請者・配偶者のマイナンバーカード

医療証

• 担当課
  • こども家庭支援課
• 期限
  • なるべく早く（1 か月健診で必要になるため）
• 必要なもの
  • 申請用紙
  • 印鑑
  • 子の健康保険証のコピー
  • 申請者のマイナンバーカード

出生連絡票

母子手帳に付属している用紙です。保健師の乳児家庭訪問に必要であるため、なるべく早く提出する必要があります。

まとめ

事前にどういった手続きが必要なのか知っておくことで余裕が生まれます。産後に母と子が退院するのはあっという間で、その後に怒涛の育児が始まることを考えると事務手続きは退院前にはできるだけ済ませておきたいところです。

プライベートで利用している M1 MacBook Air(2020) を初期化する機会があったため、セットアップの手順を記録しておきます。

前提

移行アシスタントや Time Machine を利用すれば基本的に待機するだけでセットアップが完了しますが、社用パソコンの初期セットアップなどそれらを利用できないケースが考えられます。

そのため、今回は新規にユーザーを作成したうえでセットアップを進めます。

システム環境設定

次の手順でシステム環境設定を行ないます。

• Apple ID でサインインする
• Wi-Fi
  • ネットワークの接続をする
• Bluetooth
  • ワイヤレス機器を接続する
• サウンド
  • 通知音を OFF にする
• 一般
  • OS のソフトウェアアップデートをする
  • ログイン項目で必要なアプリケーションを追加する
• 外観
  • 外観モードをダークにする
• コントロールバー
  • メニューバーに表示する項目を設定する
• コントロールセンター
  • コントロールセンターに表示したい項目を選択する
• デスクトップと Docks
  • Docks のサイズ変更
• Touch ID とパスコード
  • Apple Watch でロックを解除できるようにする
• キーボード
  • キーのリピート速度を最速にする
  • リピート入力認識までの時間を最速にする
  • キーボードの輝度を最低にする
  • キーボードショートカット
    • 入力ソース
      • 前の入力ソースを選択
        • ⌘ + Space
    • Spotlight
      • Spotlight 検索を表示を OFF にする（raycast による検索を利用するため）
    • 修飾キー
      • Caps Lock キーと Control キーを入れ替える
  • 入力ソース
    • ABC, ひらがな（Google）を設定
      • Google 日本語入力の入力ソースが表示されない場合は、一度他の入力ソースを設定したうえで再度入力ソースの編集を行なう
• トラックパッド
  • 軌跡の速さを最速にする

ターミナル

次の手順でターミナル上で設定を行ないます。

1. Homebrew をインストールする

• /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. Git をインストールする

• brew install git

3. dotfiles を clone する

• git clone https://github.com/reona5/dotfiles.git
• make コマンドを実行し、セットアップを行なう

4. asdf でプラグインを追加し、動作するバージョンをインストールする

• Ruby、Go、Node.js

5. pnpm でグローバルパッケージをインストールする

• pnpm add -g typescript typescript-language-server prettier @fsouza/prettierd eslint eslint_d

6. Neovim を起動し、次のコマンドを実行してプラグインをインストールする

• :Lazy

7. tmux server を起動した状態で prefix + I を押下し、プラグインをダウンロードする

8. GitHub の access token を設定する

• 以下を参考に access token を生成する
  • https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token
• push 時に username と password を求められるため、username に GitHub のユーザー名、password に access token を入力

各種アプリケーション

インストール済みの各種アプリケーションを起動し、初回設定を行ないます。アプリケーション一覧は Brewfile に書かれています。

• https://github.com/reona5/dotfiles/blob/main/.Brewfile

追加で設定が必要なアプリケーションは次のとおりです。

• Alacritty
  • Finder 上で ⌘ キーを押下しながらクリックして開く
• Google Chrome
  • Google アカウントでログインして設定の同期を行なう
  • Google Meet PWA をインストールする
    • https://support.google.com/meet/answer/10708569?hl=ja
• Raycast でショートカットキーを設定する
  • Raycast Hotkey
    • ⌘ + Control
  • Clipboard History
    • ⌘ + Control + v
• DeepL でショートカットキーを設定する
  • ⌘ + ;
• LINE でトークの送信方法を変更する
  • ⌘ + Enter

終わりに

今回は macOS のセットアップ手順をまとめました。

dotfiles を利用することでほとんどの設定を行なうことができますが、システム環境設定は初回に設定して頻繁に更新するこ伴いので、忘れていることもあり設定に予想以上に時間がかかりました。

また、dotfiles は CI で build 時の挙動を担保しているのですが、インストールしたアプリケーションを実際に起動しようとした際に依存しているリソースがなく立ち上がらないこともありました。 そのため、追加でライブラリをインストールするなど dotfiles の内容を見直すいい機会にもなりました。

今後も macOS をセットアップする機会はあると思うので、追加で気づいたことがあればこちらの記事に追記します 📝

Next.js のテンプレートを使って作られたブログを Astro で作り直しました。

2023/06/29 追記：Next.js に出戻りしました。Astro 版はリポジトリを分けて残しています。https://github.com/reona5/dev-by-astro

Astro を選択した理由

Astro は SSG として機能する Web フレームワークです。ブログのような静的コンテンツの配信を目的とするウェブサイトの構築に向いています。 ランタイムで JavaScript を生成しないことからパフォーマンス水準が高く、他の SSG フレームワークと比較しても高速なページの描画を可能とします。

当ブログでは記事の執筆やブログの構築を通しての知識のアウトプットを目的としており、Web アプリケーションのような複雑な挙動はそれほど必要としないことから、Astro が最適と考えました。

また、仮に JavaScript を利用して複雑な挙動を実現したい場合でも Components Island を利用することで最低限の JavaScript でパフォーマンスの低下を最小限にできます。 React や Vue などのコンポーネントを組み込むことができるのも、さまざまな技術を試すことができる点で魅力的に感じました。

Astro には他にもいくつかの利点があります。詳しくは次のドキュメントをご参照ください。

Astro を選ぶ理由

構築手順

全体の流れとして、reona.dev のリポジトリ内新規の Astro プロジェクトを立ち上げて、1 つの Pull request で移行を進めました。

Getting Started に沿って、CLI コマンドを実行します。執筆時点での Astro の最新バージョンは v2.2.1 です。パッケージマネージャーは pnpm を利用します。

1. pnpm create astro を実行

❯ pnpm create astro
pnpm create v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning prettier-plugin-astro@0.7.2: The engine
  - pnpm appears to be invalid.
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
 
success Installed
  - create-astro@3.1.2 with binaries:
      - create-astro
 
╭─────╮  Houston:
│ ◠ ◡ ◠  Let's build something fast!
╰─────╯
 
 astro   v2.2.1 Launch sequence initiated.

2. プロジェクト名を入力する

   dir   Where should we create your new project?
         ./dev

3. テンプレートを選択する

今回の用途に沿うようブログのテンプレートを選択します。

  tmpl   How would you like to start your new project?
         ○ Include sample files
         ● Use blog template
         ○ Empty

次のリポジトリがテンプレートとして採用されています。

Charca / astro-blog-template

4. 依存ライブラリのインストール有無を選択する

  deps   Install dependencies? (recommended)
         ● Yes  ○ No

5. TypeScript の利用有無を選択する

    ts   Do you plan to write TypeScript?
         Yes
 
   use   How strict should TypeScript be?
         ● Strict (recommended)
         ○ Strictest
         ○ Relaxed

推奨されているとおりに strict モードを選択します。

6. Git リポジトリを作成有無を選択する

   git   Initialize a new git repository? (optional)
         ○ Yes  ● No

これで新規の Astro プロジェクトが作成されました。 pnpm dev コマンドでサーバーを立ち上げることができます。

今後やりたいこと

すでに TailwindCSS への変更やダークモード対応、下書き機能の追加や markuplint の追加等は実施しましたが、他にも issue に起票して機能追加を実施していく予定です。

結論

次の issue にある設定を行なう。 How to use true colors in vim under tmux? #1246

" 1. Edit .tmux.conf
set -g default-terminal
  - tmux-256color
set -ga terminal-overrides
  - ,*256col*:Tc
 
" 2. Edit: .vimrc
if exists('+termguicolors')
  let &t_8f =
  - \<Esc>[38;2;%lu;%lu;%lum
  let &t_8b =
  - \<Esc>[48;2;%lu;%lu;%lum
  set termguicolors
endif

はじめに

これまで開発時には iTerm2 を使っていて特段困ることはなかったが、 Neovim での開発時、特にファイルサイズが大きいと少々カクつくことがあるのは気になっていた。 そうは言っても Neovim 利用時に限定しているので、基本的にはプラグインの整理をして対処していたが、 Rust 製でパフォーマンスがよい Alacritty というターミナルエミュレータがあると Twitter でたまたま情報を見かけたので、一度試してみることにした。

Alacritty - A fast, cross-platform, OpenGL terminal emulator

インストール

Manual Installation を見て一通りの設定を行なった。

git clone https://github.com/alacritty/alacritty.git
cd alacritty
 
// rustup をインストール
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup override set stable
rustup update stable
 
// MacOS の場合
make app
cp -r target/release/osx/Alacritty.app /Applications/
 
infocmp alacritty
sudo tic -xe alacritty,alacritty-direct extra/alacritty.info
sudo mkdir -p /usr/local/share/man/man1
gzip -c extra/alacritty.man | sudo tee /usr/local/share/man/man1/alacritty.1.gz > /dev/null

shell ごとに補完機能のインストール手順が最下部に書いてあるので、そちらも実行。

つまづいた点

tmux の prefix を Ctrl + q に設定しているのだが、反応せず。 ctrl + q を 2 回押すと tmux のキーバインドが反応したが、ピンポイントで Alacritty の Issue が挙がっていたのでこちらを参考に key_bindings を設定することで対応。

Ctrl+q not working #1359

- { key: Q, mods: Control, chars: - \x11 }

メリット

• 開発が活発に行なわされている印象

メインのターミナルエミュレータにする上で、放置されているようなプロダクトは使いたくないので、この点に関しては非常に好印象。

• OS 間で互換性がある

iTerm2 - macOS Terminal Replacement

iTerm2 は MacOS 用のソフトウェアであるため、Linux であったり Windows 環境では使うことはできない。特にマシンを買い替えて違う OS での開発に主軸を置く予定はないが、いつ違う OS で検証が必要になるかなんてわからないし、互換性があるに越したことはない。

• alacritty.yml に設定をまとめることができる

設定ファイルを yaml 形式で保管できるのは個人的には大きなメリット。互換性のメリットにも通ずるが、config 系のファイルは reona5/dotfiles にまとめているので、マシンが変わってもコマンド 1 つで開発環境を再現できるのは嬉しいポイント。

• iTerm2 よりかなり速い

割とこれはすぐに実感できるレベルで違いがわかる。 fzf のファイル検索とか ag でまだもたつきは感じるので、 Neovim のプラグイン周りで改善の余地がありそう。（この辺のベストプラクティスというか、他の人がどう管理してるか見てみたい）

デメリット

• 機能が限定的である

これは速さとトレードオフなポイントではあると思う。私の場合は、もともとタブやペインなどを Neovim + tmux で完結させていたので全く問題なかった。

• 日本語入力のインライン入力ができない

日本語を入力する際にインライン入力ができないので、google 日本語入力の補完候補はでるので使えなくはないが、かなり違和感がある。 ミスタイプをした際に delete キーを押すと、入力中の文字でなくその前の文字が消えてしまうので、ミスタイプが多い人はかなり大変だと思う。邪道ではあるが、私は Neovim の設定で emacs のキーバインドを有効にしているので ctrl + h で文字を削除することで入力中の文字を削除できた（普段 delete の方がよく使うので、慣れないといけない）

• 日本語の表示がバグることがある

これも致命的ではないけど結構気になる。Twitter とか見てるとインライン入力も含めて問題になってるみたい。

最後に

ターミナルエミュレータを変更したついでに colorscheme や font も変更した。

colorscheme: morhetz/gruvbox -> Nord

font: Ricty -> JetBrainsMono Nerd Font

Nord は tmux, Alacritty, Vim それぞれのライブラリが用意されているので、統一感が出せて非常に気に入っている。