ikuma-t.com

chezmoiの変更をClaude Codeにコミットさせる

ikuma-t — Sun, 11 Jan 2026 00:00:00 GMT

chezmoiでdotfilesを管理しています。

chezmoiでは変更に対して自動でコミットを行うことができ、これまではautoCommitをtrueにすることで、自動コミットを起動させ、自分でコミットメッセージを入力していました。

[git]
    autoCommit = true
    autoPush = false
    commitMessageTemplate = "{{ promptString \"Commit message\" }}"

dotfilesは頻繁に変更が入るのでコミットメッセージを書くのが面倒です。また内容もアプリケーション開発よりも自明なものが多く、自分がコミットメッセージを入力する必要はなおのことないと思い、コミットの入力をClaude Codeに移譲することにしました。

chezmoi の Hooks 機能を使って、変更時に事前に登録しておいたコミット処理を起動します。この場合コミット処理は Claude Code に移譲するため autoCommit は不要になります。

[git]
    autoCommit = false
    autoPush = false

[hooks.add.post]
    command = "bash"
    args = ["-c", "cd ~/.local/share/chezmoi && claude -p \"/commit\""]

[hooks.edit.post]
    command = "bash"
    args = ["-c", "cd ~/.local/share/chezmoi && claude -p \"/commit\""]

なお -p は print オプション。これにはスラッシュコマンドも渡せるので、コミットを行うコマンドなりを渡してやれば良いというわけです。

これで変更反映時に自動で Claude Code によるコミットが実行されるようになりました。

Obsidianでアバターアイコンを挿入できるようにする

ikuma-t — Fri, 09 Jan 2026 00:00:00 GMT

esaやscrapboxでは自分のアバターアイコンを文中にサッと入れられますが、これをObsidianでもやる方法です。

手順はシンプルで、テンプレートとして画像を挿入するホットキーを作ります。

自分のアイコン画像を適当なフォルダに配置する（CSSで調整しますが、20px x 20pxくらいの正方形で用意）
テンプレートを作成する。

![[me.png|me]]

スタイリングのために、Altをつけています。

カスタムCSSを配置する

img[alt="me"] {
  width: 20px;
  height: 20px;
  border-radius: 50%;
  vertical-align: middle;
  margin-right: 6px;
  display: inline;
}

Templater Pluginを利用して、2で作成したテンプレートにホットキーを適用する

Advanced Functional Programming With Elixirを読んだ

ikuma-t — Tue, 30 Dec 2025 00:00:00 GMT

X のタイムラインに流れてきたのがきっかけで Advanced Functional Programming with Elixir: Model Behavior, Manage Complexity, and Maximize Maintainability by Joseph Koski を読みました。

本書の概要

テーマパーク「FunPark」を題材として、各章ごとに FP のデザインを学んでいきます。

Introduction
Build FunPark: Model Real-World Data
Implement Domain-Specific Equality with Protocols
Create Flexible Ordering with Protocols
Combine with Monoids
Define Logic with Predicates
Compose in Context with Monads
Access Shared Environment with Reader
Manage Absence with Maybe
Model Outcomes with Either

各章ごとに出てくる FP のパターンは次の通りです

章	出現するパターン
1-3	Eq, Ord
4	Monoid
5	Predicate
6-7	Monad, Reader
8	Maybe
9	Either
10	Effect

対象読者

The Pragmatic Bookself では「Expert」とされていますが、これは「Elixir には習熟しているが、完全な FP には傾倒していない人」を想定してのものに感じました。関数型プログラミングの書籍としては、上述の出現するパターンの通り比較的基本的な部分も多いため、Beginner から Intermediate の中間くらいに相当するかと思います。

近いレベルの書籍としては以下の 2 冊でしょうか。

これら 2 冊よりも、より具体的に「Monad」「Applicative」といった関数型プログラミングのワードを取り扱っているのが本書です。関数型プログラミングの概念を理解したい、上記 2 冊を読んだがもう少しパターンを補完したい、という方に推奨できる一冊に思います。

学んだこと

律（Laws）

関数型プログラミングでは、抽象化には必ず「律」（laws）が伴います。律とは、その抽象化が満たすべき数学的な性質のことです。

Monoid の律：

単位元律：combine(x, empty) = x、combine(empty, x) = x
結合律：combine(combine(a, b), c) = combine(a, combine(b, c))

Functor の律：

恒等律：map(id) = id
合成律：map(f . g) = map(f) . map(g)

律があることで、コードの振る舞いが予測可能になります。律を満たさない実装は「壊れた抽象化」であり、合成したときに予期しない動作を引き起こします。

Functor、Applicative、Monad の階層

この 3 つは階層構造を成しています：

Functor     ⊂ Applicative ⊂ Monad
(map)         (map + ap)     (map + ap + bind)

Functor は「箱の中身を変換する」能力を持ちます。map だけで十分な場合は Functor です。

Applicative は「独立した計算を組み合わせる」能力を追加します。ap を使って、複数の箱の中身に関数を適用できます。重要なのは、各計算が独立していること。バリデーションで全エラーを集めたい場合は Applicative を使います。

Monad は「前の計算結果に依存する計算を連鎖させる」能力を追加します。bind（flatMap）を使って、前の結果を見てから次の計算を決められます。ただし、依存関係があるため、最初のエラーで停止します。

本書で traverse と traverse_a の違いを学んだとき、この階層の意味が実感できました。traverse は Monad（依存、最初のエラーで停止）、traverse_a は Applicative（独立、全エラー収集）です。

共変と反変（Covariant / Contravariant）

TypeScript の型定義でも出てくる共変と反変。

共変（Covariant）は、map で出力を変換します：

map: (a -> b) -> F a -> F b

反変（Contravariant）は、contramap で入力を変換します：

contramap: (b -> a) -> F a -> F b

本書では、FastPass の時刻で等価性を判定したい場合に contramap を使いました：

def eq_time do
  Eq.Utils.contramap(&get_time/1)
end

また、Patron をチケット階層で順序付けしたい場合にも contramap を使いました：

def ord_by_ticket_tier do
  Ord.Utils.contramap(&get_ticket_tier_priority/1)
end

contramap は元のデータを変更するわけではなく、「比較のために一時的に射影する」だけです。既存の Eq や Ord から新しいものを宣言的に導出できる強力な道具です。著者も章末で「本当に contramap を理解しているか自問せよ」と強調していました。

lift（持ち上げ）

lift は、ある文脈の外にある値や関数を、文脈の中に持ち込む操作です。本書では頻繁に登場しました：

lift_predicate：述語を Maybe や Either に持ち上げる
lift_either：Either を Effect に持ち上げる
lift_func：通常の関数を Effect に持ち上げる

関数型プログラミングに精通している方のツイートなどをみていると「持ち上げる」という概念がよく出てくるので、アハ体験でした。

Kleisli 関数

a -> M b という形の関数（値を受け取って Monad を返す関数）のことです。bind は Kleisli 関数を連鎖させる操作です。バリデーション関数（Patron -> Either ValidationError Patron）は Kleisli 関数の典型例でした。

おわりに

10 章のメッセージが良いなと思ったので、日本語訳（訳：Claude）にて引用します。

チェスと同じだ。もっとゲームをプレイしても上手くならない——構造とフィードバックが必要だ。マスターは「手」で考えない。「パターン」で考える。ボードをシステムとして見る：繰り返し可能、予測可能、合成可能。

関数型プログラミングも同じシフトを提供する。より小さく、より安定した単位でロジックを合成するツールを与えてくれる——コードの書き方だけでなく、考え方そのものを形作る。

そのシフトには練習が必要だ。マスタリーは見ることや繰り返すことからは来ない——作ること、実験すること、振り返ることから来る。FunPark の例を実行するだけではダメだ。バリエーションを試せ。自分のを作れ。壊して直せ。理解はそうやって深まる——一度にではなく、一歩一歩。

この本は君の代わりに仕事はできない。でも道を照らす手助けはできる——何を練習するか、どの順番で、なぜ重要かを示すことで。注意を向けるべき場所、よくある落とし穴の避け方、目的を持って前に進む方法を示すことで。

なっとく関数型プログラミング、関数型ドメインモデリング、本書と読んできて、だいぶ基本的な概念には馴染みが出てきました。一方で純粋関数型言語が主戦場ではないので、どうしても部分的に関数型っぽい感じで書くにとどまっており、関数型が身についているかというと微妙なところです。マスタリーを目指すために、Haskell を使ってパターン・メンタルモデルを染み込ませる活動をやっていこうと思います。

また昨年末くらいまでは「関数型プログラミング」のレイヤーもよくわかっていませんでしたが、基礎の部分はだいぶ見えてきました。結果として TypeScript のライブラリで出てくるような概念（例：Optics）はまだリーチできていないことがわかりました。次は Scala の赤い本が良さそうなので読んでみようと思います。

ページ内検索を活かすために仮想スクロールを採用しないという選択

ikuma-t — Mon, 15 Dec 2025 00:00:00 GMT

この記事は株式会社エス・エム・エスAdvent Calendar2025 12月15日の記事です。

横断でのコンポーネント改修作業を効率化するために、コンポーネントの利用状況分析ツール「cuin」を個人で開発しています ¹。

このツールは引数として受け取ったディレクトリを対象として、コンポーネントの利用状況の分析を行うことができます。

Terminal window

# カレントディレクトリを対象
npx @ikuma-t/cuin

# パス指定
npx @ikuma-t/cuin -p /path/to/directory

分析結果として、次の 2 つのコレクションをいくつかの検索条件を用いながら閲覧することができます。

1. コンポーネント一覧

2. 特定のコンポーネントの利用箇所一覧（以下、詳細ページ）

今回はこのツールの開発において、ページ内検索を利用するために仮想スクロールを使わずに大きめのリストを表示するために行った試行錯誤をお伝えします。

ページ内検索利用の経緯

静的解析の限界からテキスト検索の実装を検討

詳細ページのファセットナビゲーションとして、「コンポーネントの利用箇所のパッケージ」と「使用されている Props とその値の分布」は必須と考え実装していました。

これらに加えて検討していたのが、フリーテキストによる検索です。テキスト検索を検討した背景として、コンポーネントの静的解析の限界があります。AST によるコンポーネント解析はその性質上、動的に決まる値を完全に解析することはできません。

たとえば次のコードにおいて、valueは文字列であることはわかりますが、その値は解析時に決定するものではありません。またonChangeにはhandleInputが渡されていることがわかりますが、その定義は別の hooks からきています。

import { useState } from 'react';
import { useInput } from './useInput'

function MyComponent() {
  const [value, setValue] = useState('');
  const { handleInput } = useInput();

  return (
    <input type="text" value={value} onChange={handleInput} />
  );
}

もちろん最終的な値が静的なものである場合は、定義元を多段で解析をしていくことで値を取得できますが、実行コストがかかるのでこのツールでは対応していません。

解析を緩めにすることで絞り込みできないケースへの補助的な手段として、テキストによるコンポーネント利用状況の検索を検討していました。

自前実装を見送った理由

検討をしてみたはいいものの、Props や Package のような絞り込み方法が明白なプロパティと異なり、テキスト検索は精度・結果の表示それぞれに自由度があり、どう実装するかが非常に悩みどころでした。

完全一致で検索させるのか、曖昧検索をするのか
ソースコードの改行を考慮して検索をするのか
検索結果はハイライトするのか

加えてドッグフーディングをしてみても、そもそもテキストで検索したいケースが常ではなかった（いつもなくてもいいけど、たまに心が検索したがる程度）ため、どう配置しても「かえって邪魔になる」という始末。

そのため今回はテキスト検索の機能としては実装せず、検索したくなった時にはブラウザのページ内検索を活用する方針としました。

仮想スクロールではページ内検索ができない

ページ内検索自体は普通にブラウザを使っていれば使える機能ですが、このツールでは当初仮想スクロールを採用しており、ページ内検索を利用することができませんでした。

仮想スクロールは表示されていない範囲の DOM を描画しないため、ビューポートに現れない要素についてはページ内検索の対象になりません。

仮想スクロールを利用していたのは、いずれのコレクションも少なくとも 1,000 件以上の表示 (詳細ページは 5,000 件) を想定していたことや、詳細ページは特に1要素ごとの情報も多いためです。

ページ内検索を利用できるようにするために何の工夫もなしに仮想スクロールをやめてみたところ、初期描画は辛うじて出来ても、以降のフィルタリングやソートで画面がフリーズしてしまったことから、いくつか調整を行う必要がありました。

仮想スクロールを使わずに描画するための調整

ここからは仮想スクロールを使わずにリストを表示するために行なった試行錯誤を紹介します。

前提

実装の制約として、以下の理由でReact Server Component や Astro といった (ランタイムかビルド時に関わらず)サーバを要求するアーキテクチャは使えないことを前置きしておきます。

npm として配布する関係上、UI 部分を事前にビルドしておきたいため
将来的に GitHub Pages などの静的ホスティングを行いたい場合に、サーバランタイムが足かせになるため

また以降で述べる話については、全体的にパフォーマンスの根拠となる検証値がないのですが、悪しからず…。

React から SolidJS への切り替え

いきなりだいぶ荒療治ですが、React で書かれていたコンポーネントを SolidJS に置き換えました。

もちろん React のまま useMemo や useDeferredValue を利用して適切なレンダリング・体験に調整していく方法もありますが、画面数も多くなかったことと、クライアントサイドフィルタリングが重いことから、いっそのこと仮想 DOM を使わないのが近道なのでは？と思い、バッサリ切り替えました。

なお仮想 DOM を使わないフレームワークの選択としては Svelte、 Vue Vapor Mode、SolidJS、（部分的に）Qwik などがありますが、もともと JSX で書いていたことからそれを維持できる SolidJS を採択しています。

この時点で一覧ページでのフィルタリング、詳細ページも 500 件くらいであればフリーズせずに動作するようになりました。

details 要素を利用する

SolidJS への切り替えだけでは詳細ページの想定件数に届いていないのでもう少し調整が必要です。

仕様としてコンポーネントの各要素はいわゆるアコーディオン UI としています。初期実装では特に深く考えず UI ライブラリ（Ark UI）の Accordion を利用していましたが、これを HTML の details 要素に置き換えました。

details 要素に置き換えるメリットは次の 2 つです。

アコーディオン自体を表現するための JavaScript が不要になる
（Safari を除くブラウザで ²）details が閉じていても、内部をページ内検索できる ³

details 要素自体は open 属性を指定することで開閉状態を切り替えることができます。今回の実装では表示する要素が 300 件を超えた場合、open=false で details 要素を閉じた状態で初期表示するようにしました。

false になっている要素は DOM として存在しますが、描画処理自体は行われないため、初期描画時の負荷を削減できます。

details の開閉をバッチ処理にする

details 要素が閉じることで初期描画は軽くできますが、実際に閲覧する際に1つ1つ details 要素を開いていくことはストレスなので、合わせて全開閉用のボタンも配置しています。

開閉自体は先述の通り open を変更したい状態に合わせて書き換える（開くのであれば open=true）だけなのですが、これも純粋にループで行うと開閉処理中は画面が固まってしまいます。

そのためいくらかの件数ごとにバッチ処理にした上で、Viewport の中央から放射線状に開閉が行われていく実装としました。単純なバッチ処理としていないのは、上から順にバッチで開閉していくと、リスト下部にいた際にボタンを押したタイミングと開閉が行われるタイミングがズレるためです。

const DEFAULT_BATCH_SIZE = 100;

// 全details要素の取得（実態はSet）
const items = Array.from(getItems());

// ビューポートの中央の要素を取得
const centerIndex = findCenterElement(items);
// 要素の中央から順にインデックスを配置
const indices = centerOutIndices(items.length, centerIndex);
// バッチサイズごとに分割して処理を実施する
const batches = batchIterate(indices, DEFAULT_BATCH_SIZE);

await new Promise<void>((resolve) => {
  const processBatch = () => {
    const { value: batch, done } = batches.next();

    if (done) {
      resolve();
      return;
    }

    for (const idx of batch) {
      // callbackでdetailsのトグルを開閉
      callback(items[idx]);
    }

    requestAnimationFrame(processBatch);
  };

  requestAnimationFrame(processBatch);
});

省略した関数部分

const findCenterElement = <E extends HTMLElement>(
  items: E[]
): number => {
  const target = window.innerHeight / 2;
  let low = 0;
  let high = items.length - 1;

  while (low < high) {
    // biome-ignore lint/suspicious/noBitwiseOperators: perf
    const mid = (low + high) >>> 1;
    const rect = items[mid].getBoundingClientRect();
    const pos = rect.top + rect.height / 2;

    if (pos < target) {
      low = mid + 1;
    } else {
      high = mid;
    }
  }

  const candidates = [low - 1, low, low + 1].filter(
    (i) => i >= 0 && i < items.length
  );

  let closestIndex = candidates[0];
  let closestDistance = Number.POSITIVE_INFINITY;

  for (const i of candidates) {
    const rect = items[i].getBoundingClientRect();
    const pos = rect.top + rect.height / 2;
    const distance = Math.abs(pos - target);
    if (distance < closestDistance) {
      closestDistance = distance;
      closestIndex = i;
    }
  }

  return closestIndex;
};

function* centerOutIndices(
  totalCount: number,
  centerIndex: number
): Generator<number> {
  if (totalCount === 0) {
    return;
  }

  const center = clamp(centerIndex, 0, totalCount - 1);
  let upper = center;
  let lower = center + 1;

  while (upper >= 0 || lower < totalCount) {
    if (upper >= 0) {
      yield upper;
      upper -= 1;
    }
    if (lower < totalCount) {
      yield lower;
      lower += 1;
    }
  }
}

export function* batchIterate<T>(
  items: Iterable<T>,
  batchSize: number
): Generator<T[]> {
  let batch: T[] = [];

  for (const item of items) {
    batch.push(item);
    if (batch.length >= batchSize) {
      yield batch;
      batch = [];
    }
  }

  if (batch.length > 0) {
    yield batch;
  }
}

開閉ではないですが、イメージとしては以下の動画のように中央から徐々に処理を適用します。

これを実際にツールに適用したものが次の動画です。

リスト全体の中央付近で「ExpandAll」をクリックした際に、detailsを開く作業は3秒程度かかっている（右上のExpandAllがdisabledになっている）のですが、ビューポートで見えている範囲については開く作業が瞬時に終わっています。

content-visibility を利用して要素の描画をやめる

details 要素で描画するようにして、大量件数の場合に初期描画で閉じるようにしても、各要素をすべて開いた場合には描画は重くなります。その対策として各 details 要素には content-visibility: auto を付与しています。

content-visibility は要素がビューポートに近づくまで要素のレンダリングを遅らせることができる CSS プロパティです。CSS 版仮想スクロールみたいなものですが、JavaScript での仮想スクロールと異なり、要素自体は DOM に存在するためページ内検索の対象になります。

このプロパティをdetailsのコンテンツ部分に適用し、リスト下部の不要な要素のレンダリングを抑制しました。

Shiki のハイライトを遅延させる

各 details の要素は利用箇所のコードブロックを持っており、これは Shiki によってシンタックスハイライトされています（本当はシンタックスハイライトのような処理は事前ビルド or サーバサイドでやれると良いのですが、前提の通りクライアントサイドでハイライトをする必要があります）。

シンタックスハイライトは details に含まれる要素の中では比較的重い JavaScript 処理なので、要素が実際にビューポートに入るまでは処理を遅延したいです。先ほどのcontent-visibilityはあくまでDOMの話なので、JavaScriptに対しては別途制御をかける必要があります。

こういうケースでは IntersectionObserver を利用してビューポートに入ったかを監視することが多いと思いますが、今回のようにcontent-visibility: auto を活用している前提においては contentvisibilityautostatechange イベントを利用することができます⁴。

Element: contentvisibilityautostatechange イベント - Web API | MDN

contentvisibilityautostatechangeイベントは content-visibility: auto が適用された要素のレンダリング状態が変化した時に発火するイベントで、対象の要素のレンダリングがスキップされるかどうかを skipped で判定することができます。

MDN のコード例がわかりやすいので拝借します（引用元：ContentVisibilityAutoStateChangeEvent - Web API | MDN）。

const canvasElem = document.querySelector("canvas");

canvasElem.addEventListener("contentvisibilityautostatechange", stateChanged);
canvasElem.style.contentVisibility = "auto";

function stateChanged(event) {
  if (event.skipped) {
    stopCanvasUpdates(canvasElem);
  } else {
    startCanvasUpdates(canvasElem);
  }
}

// キャンバスの更新を始める必要があるときに呼び出されます。
function startCanvasUpdates(canvas) {
  // …
}

// キャンバスの更新を停止する必要がある場合に呼び出されます。
function stopCanvasUpdates(canvas) {
  // …
}

stateChanged 関数で使われている skipped がこのイベント固有のプロパティで、レンダリングされる場合（=ビューポートに content-visibility: auto の要素が近づいた場合）は false(=レンダリングする) になります。

同様の仕組みを適用することで、前述の仕組みと合わせて、details 要素が開いた状態でビューポートに近づくまでシンタックスハイライトを行わないようにすることできます。

// ※ コードはイメージです
const handleStateChange = (e: ContentVisibilityAutoStateChangeEvent) => {
  if (!e.skipped) {
    syntaxHighlight();
  }
};

<details>
  <summary>
    <ChevronDownIcon />
    <div>{props.summary}</div>
  </summary>
  <div onContentVisibilityAutoStateChange={handleStateChange} style={{
    "content-visibility": "auto";
    "contain-intrinsic-size": "auto 200px";
  }}>
    {props.children}
  </div>
</details>

デモ

約5,000件の利用箇所をもつコンポーネント（というかdivですが）を対象に操作をしてみました。ページ内検索は検索してからブラウザ側のフィードバックが返ってくるまでに少し時間がかかりますが、仮想スクロールなしでページが固まることもなく、ページ内検索も利用できました。

おわりに

今回はページ内検索を活かすために、仮想スクロールを使わずにそれなりの要素を描画するための試行錯誤を紹介しました。

今回採択している方針や検証の基準は、利用ユーザーが開発者であるという前提のもとに、「NEWLY AVAILABLE であっても問題なし」「（開発者である自分の PC で）ある程度軽快に動けばよし」という判断をしているものなので、すべてのケースでそのまま利用できるわけではありませんが、仮想スクロールを使いたくないケースでの実装の参考になればと思います。

以上、株式会社エス・エム・エスAdvent Calendar2025 12月15日の記事でした！明日は@Schumi543さんです！

Footnotes

ツール開発の背景については、スライド - Speakerdeck にあるのでそちらを参照してください。 ↩
2025/12 月時点の実装状況による。Chrome、Edge、Firefoxの各Stable版、Safari（Technology Preview）で実装済。refs: https://wpt.fyi/results/html?label=master&label=stable&aligned&view=interop&q=label:interop-2025-details ↩
2 についてはライブラリによっては対応しているものがあるかもしれませんが、もともと使っていた Accordion | Ark UI ではページ内検索の対象とならないようでした。 ↩
contentvisibilityautostatechangeのBaselineはcontent-visibilityと同じです。 ↩

JSConf JP 2025に参加した

ikuma-t — Mon, 17 Nov 2025 00:00:00 GMT

JSConf JP 2025 に参加してきました。現地参加は 2 年連続 2 回目です。

PreEvent

JSConf.jp 2025 Pre Event - connpass

LT の機会をいただけたので、今年は PreEvent@Google 渋谷オフィスにも行きました。

今年からデザインシステム関連の活動も少しずつやり始めていて、その中でコンポーネントの利用状況にアクセスできたら便利なのに（そしてそんなのはエンジニアリングの得意なところだろうに）と思って調べたり、自分で作っていたもの ¹ を発表しました。

すでにツールがあることを知らなかったのは事実なんですが、実際 SaaS である Omlet を使わないとなると、react-scanner に何かしらの View を作りたくなると思うので、そのイメージにつながるといいなと思っています。

発表中でも触れましたが、今回の内容に近いところを GitHub の人も言っているので、気になる方は見てみてください。

ここから本編

グッズ購入

地味に楽しみにしていたグッズ購入。

昨年は「接続安定 200」と書かれたのお守りを購入したんですが、今年はトートバッグとステッカーと缶バッジを購入。来場者がもらえるシャツとトートバッグも可愛くて使いやすそう。

いままで PC にステッカーを貼るタイプの人間ではなかったのですが、PreEvent 会場の Google さんから Baseline、サイボウズさんのスポンサーブースで W3C の新ロゴステッカーを入手できたこともあり、バグちゃんのステッカーと一緒に貼ることにしました。

前日の PreEvent で作者の shelly さんにもお話できてよかった。来年のグッズも楽しみです。

ブース

多分全ブース回ったはず。サイボウズさんのブースで FE 横断の改善活動について聞けたのが面白かったです（「俺たちがコンテンツだ」は強い）。

あとブース横のコーヒースタンドの従量課金コーヒー美味しかったです。

セッション

聞いたセッション。

午後のセッション聞いているうちに「CommonJS…」という気持ちになりました😇

どのセッションも DeepDive していて面白かったのですが、個人的には Technical Discussion with TC39 がすごい良かったですね。今出ている Proposal から話をしているので当たり前といえばそうなんですが、そこまでのトークで出ていた Composites、Module Harmony、using、ES2015 など全部繋がっていてとても良いセッションでした。

懇親会

Nuxt の話、Electron の話、帳票エンジンの話など色々とお話できました。お話しいただいた皆さんありがとうございました。

最近仮想 DOM を使わずに実装したい箇所があって SolidJS を選んでいるケースがあったんですが、Vue の Vapor Mode もあるぞ、という話を懇親会で教えてもらったのでちょっと試そうと思ってます。

おわりに

今年のセッションもどれも聞いていて刺激になるものばかりでした。JavaScript はやっぱり面白いですね。来年は自分も本セッションで話せるように、仕込んでいこうと思いました。

運営の皆さん、登壇者の皆さん、素敵な機会をありがとうございました。また来年。

Footnotes

だいぶ荒い実装ですが、一応公開しています。 https://www.npmjs.com/package/@ikuma-t/cuin ↩

goghを購入した（Steam版）

ikuma-t — Sat, 23 Aug 2025 00:00:00 GMT

作業支援系アプリ？ゲームの gogh を購入しました。これ系のアプリを使ったことがないのですが、結構多機能です。

アバター作成
チル系の BGM
タイマー
Todo 管理
日課管理
キャラ育成

M3 Macbook Air でもサクサク動いています。

スペースなしのGitエイリアスを設定する

ikuma-t — Sun, 10 Aug 2025 00:00:00 GMT

Git のエイリアス

自分の環境では、git に対して zsh で g を割り当て、各 git コマンドに対して gitconfig でエイリアスを設定しています。

.zshrc

alias g = "git"

~/.config/git/config

[alias]
  # [Basic Snapshotting]
  a = add
  e = commit --amend --no-edit
  s = status -s
  c = commit -m
  fix = commit --fixup
  fixup = "!f() { git fix \"$1\" && git ria \"$1^\"; }; f"
  r = restore
  rs = restore --staged
  z = reset --soft HEAD^
  zs = reset --soft
  zh = reset --hard

  # [Branch and Merging]
  b = branch
  co = checkout
  sw = switch
  swc = switch -c
  m = merge
  t = stash
  ta = stash --apply
  tp = stash pop
  td = stash drop
  tag = tag
  w = worktree

  #[Sharing and Updating Projects]
  f = fetch
  pl = pull
  p = push
  pf = push --force-if-includes --force-with-lease
  remote = remote

  # [Inspection and Comparison]
  d = diff
  ds = diff --staged
  l = log

たとえば commit であれば g c で実行できるわけですが、毎回スペースを追加するのは面倒です。かといって、各コマンドごとにスペースを含まないエイリアス（コミットの例であれば、gc='git commit'）を都度貼るのは非効率です。

スペースなし版エイリアスを自動で設定する

.zshrc

if command -v git >/dev/null 2>&1; then
  for alias in $(git config --get-regexp '^alias\.' | sed 's/^alias\.\([^ ]*\) .*/\1/'); do
    alias g${alias}="git ${alias}"
  done
fi

git config --get-regexp で正規表現に一致した gitconfig の内容を取得できるので、これを使って動的にエイリアスを貼ります。

これで次のようにスペースなしで git コマンドを実行できるようになります。

Terminal window

❯ alias gc
gc='git c'

VSCodeでプロジェクトの設定と異なるSeverityでESLintエラーを報告する

ikuma-t — Sat, 01 Mar 2025 00:00:00 GMT

課題： ESLintルールはそのままに、自分のエディタ上の表示を変更したい

とあるTypeScriptプロジェクトにおいて、「あるESLintをチェックすることはOKだが、視認性の関係でエディタ上でのSeverityを変更したい」という要求がありました。

例えば@typescript-eslint/no-unused-varsをerrorに指定していると、使用していない変数がある場合にエディタ上で赤く波線が表示されます。

使われていない変数があることをチェックするのはルールとして残しておきたいが、エディタ上ではエラーではなく警告を示す黄色の波線として表示したい、という要求です。解決策の一つは愚直にルールのSeverityを変更することですが、これは他の開発者にも影響を与えてしまうという問題があります。

VSCodeの`eslint.rules.customizations`を使ってSeverityを変更する

VSCodeのESLint拡張には、このような要求を満たすための設定があります。それがeslint.rules.customizationsです。

eslint.rules.customizations (@since 2.1.20) - force rules to report a different severity within VS Code compared to the project’s true ESLint configuration. Contains these properties:

設定できるプロパティは次の3つです。

rule: 対象とするESLintのルール名。ワイルドカードとして*、否定として!が使えます。
severity: ルールのSeverity。default、off、info、warn、error、downgrade、upgradeのいずれかを指定します。後2つはeslintの設定に対して緩めるか、厳しくするかの指定です。
fixable: autofixを有効にするかどうか。trueかfalseを指定します（※autofixが可能なルールのみ）。

先にあげた例を実現するならば、次のように設定します。

  "eslint.rules.customizations": [
    {
      "rule": "*no-unused-vars",
      "severity": "downgrade" // もしくはwarnでもよい
    }
  ]

もともとエラーの赤線だったものが、警告の黄色線に変わり、期待していた挙動を実現できました。

記載はユーザー固有のsettings.jsonでも適用されるため、もしプロジェクト全体に影響を与えたくない場合は個人の設定として適用することができます（オーバーライドする設定なので、ワークスペース側の設定に書くことはないと思いますが）。

Astro Content Layer で個人ブログのコンテンツ取得はもっと楽になる

ikuma-t — Tue, 10 Dec 2024 00:00:00 GMT

この記事は株式会社エス・エム・エス Advent Calendar 2024 12月10日分の記事です。

もうそろそろ冬休みですね。「冬休みは個人ブログを作って（あるいはリニューアルして）、来年はアウトプットを頑張るぞ！」という方も多いのではないでしょうか。

Astro や Eleventy、Next.jsなど、各フレームワークによりMarkdownブログは超速で作れるようになりましたが、外部のCMSからデータを取得するとなるとやや面倒です。

Astro v5 からは Content Layerという機能が追加され、外部のコンテンツデータを利用したサイト作成がより簡単になりました。この記事では、Content Layer が何を解決し、どのようにコンテンツサイト構築に使えるのかを紹介します。

なぜ Content Layer を使うのか

個人ブログ開発はどうコンテンツを取得するかが9割

個人ブログを自作する際に必要な技術はさまざまですが、コアとなる技術はコンテンツを取得し HTML として描画できる形に変換することです。もちろん正しいマークアップや魅力的なスタイリングなども重要ですが、それらもコンテンツがあってこそ必要になるものであり、コンテンツがなければ何も始まりません。

これまでの Astro においても、この部分を簡素化するためにContent Collectionsという機能が提供されていました。

これは zod によるメタデータ（タイトルや公開日など）のバリデーションと、ファイルシステムからのデータ取得を簡単にするための Query API を提供するもので、以下のようなスキーマ情報を定義するだけで、Markdown ファイルによるブログ記事の取得を簡単に行うことができます。

src/content/config.ts

import { defineCollection, z } from 'astro:content';

// defineCollection を用いて、ブログのメタ情報を定義（これとは別に本文が含まれる）
const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    description: z.string().optional(),
    publishDate: z.date(),
    category: z.enum(['tech', 'idea', 'life']).default('idea'),
    draft: z.boolean().default(true),
    tags: z.optional(z.array(z.string())),
  }),
});

export const collections = { blog };

src/pages/blog/1.astro

---
import { getEntry, render } from 'astro:content';

const entry = await getEntry('blog', '1');
const { Content } = await render(entry);
---
{/* メタデータを表示する */}
<p>Published on: {entry.data.published.toDateString()}</p>

{/* Markdownがhtmlに変換されているので、そのまま記事を描画できる */}
<Content />

Content Layer はコンテンツ取得を抽象化する

Content Collections は便利な機能ですが、ローカルの Markdown ファイルでしか利用できないという課題がありました。

そこで Content Collections をベースに、より抽象的に「コンテンツを取得する」機能を提供するのが Content Layer です。

コンテンツを取得するためのAPI（Content Collections）はそのままに、次の概念が追加されています。

Loader: データソースからデータをフェッチし、DataStore に格納するための関数
Schema: zodにより定義された、コンテンツのメタデータのスキーマ情報
DataStore: データソースから取得されたデータを保持するストア¹
DataEntry: DataStoreに格納される1つ1つのデータ。メタデータとしてdata、HTMLとしてレンダリングされた際に表示するコンテンツとしてrenderedを持つ。

コンテンツが DataEntry として抽象化されたことによって、規定のインターフェースを満たすようにデータをフェッチして格納する関数さえ実装できれば、どのようなデータソースからでも同じようにデータを取得することができるようになりました。

また Loader はビルド時（開発時はサーバ起動時）にすべてのデータをフェッチし、zodによるスキーマバリデーションを行うため、ランタイムでのデータ取得エラーやバリデーションエラーを防ぐことができます。

Content Layer の実例：Speakerdeck の RSS フィードから登壇ページを実装する

実例として、このサイトの登壇ページは Speakerdeck の RSS と Content Layer を組み合わせて実現されています。

Content Layer がない場合、次の内容を自前で実装する必要がありました。

Speakerdeck の RSS を fetch し、特定のデータ構造にパースする関数
キャッシュ取得のビルドプロセスへの組み込み
キャッシュデータからコンテンツを取得するユーティリティ関数

Content Layer を利用することで、これらの実装を省略し、Speakerdeck のデータを取得するための Loader を実装するだけで済みます。加えて RSS フィードについては、コミュニティですでに公開されている Loader があるため、自前で実装する必要もありません。

マークアップは省略していますが、登壇ページの実装はおよそこれだけです。

src/content/config.ts

import { defineCollection } from 'astro:content';

const talks = defineCollection({
  // コミュニティで公開されている feedLoader を利用
  loader: feedLoader({
    url: 'https://speakerdeck.com/ikumatadokoro.rss',
  }),
});

export const collections = {
  talks,
};

src/pages/talk/index.astro

---
import { getCollection } from 'astro:content';

const talks = await getCollection('talks');
const talksByYear = Map.groupBy(talks, (talk) => talk.data.pubdate!.getFullYear());
---

<div>
  {talksByYear.entries().map(([year, talks]) => (
    <p>{year}</p>
    {talks.map((talk) => (<TalkCard talk={talk} />))}
  ))}
</div>

Content Layer を利用する

Content Layer を利用する際には、コミュニティで公開されている Loader を利用するか、独自の Loader を実装するかの2つの方法があります。

細かい使い方や定義は Astro の公式ドキュメントに譲るとして、実際にどのような形式で使えるのかを見ていきます。

コミュニティが公開している Loader を利用する

自分が利用したいデータソースの Loader がすでにコミュニティで公開されている場合は、それを利用することで手軽にコンテンツを取得できます。

Loader は npm パッケージとして公開されており、現在公開されている Loader は Astro公式のIntegration ページから確認することができます。

現在コミュニティで公開されている Loader の例としては、次のようなものがあります。

Notion
Google Spread Sheet
RSS Feed
GitHub Discussions

使用方法は設定ファイルである src/content/config.ts に対象の loaderを指定するだけです。

多くの Loader は取得元を特定するために追加の引数を受け付けます。たとえば先ほど例に挙げた RSS の Loader は、取得元の URL を引数として受け付けます。

src/content/config.ts

const talks = defineCollection({
  // feedLoader は フィードの url を引数に取り、Loader を返す関数
  loader: feedLoader({
    url: 'https://speakerdeck.com/ikumatadokoro.rss',
  }),
});

この状態で開発サーバを起動すると、コンテンツの取得およびインメモリの KV ストアへの格納が行われ、RSS フィードから取得した内容をアプリ内で描画できるようになります。簡単ですね！

独自の Loader を実装する

自分が利用したいデータソースのLoaderがない場合や、必要なメタ情報のスキーマが異なる場合は、自分で Loader を実装することもできます。

Loader はdefineCollectionの中に直接記述することもできますが（Inline loaders）、保守性の観点から別途関数として定義することをおすすめします（Object loaders）。

Loader関数の全体感は次のようになっており、最終的にLoaderの名前（name）、スキーマ（schema）、データ取得処理（load）をプロパティに持つオブジェクトを返すように実装します。

src/content/loader/awesomeLoader.ts

import { type Loader, type LoaderContext } from 'astro/loaders';

export const awesomeLoader = (options: { yourApiOptions: string }): Loader => {
  const schema = /* メタデータのスキーマ定義 */;
  const load = /* データ取得処理 */;
  return { name: 'awesomeLoader', schema, load };
};

schemaはタイトルや日付、タグなどのコンテンツのメタ情報を表すもので、zodにより定義されます。

const schema = z.object({
  title: z.string(),
  createdAt: z.date(),
});

loadはデータを取得して DataStore に格納するための関数です。利用したいデータソースによって詳細な実装は変わりますが、大まかには次の3段構成で捉えると実装しやすいでしょう。

const load = async (context: LoaderContext) => {
  // 1. データを取得し、必要に応じて加工する
  const apiUrl = 'https://...';
  const data = await fetch(apiUrl);
  const json = await data.json();

  // 2. 取得したデータのバリデーションを行う
  const parsedData = await context.parseData(json);

  // 3. データをStoreに保存する
  const store = context.store;
  store.set({
    id: parsedData.id
    data: parsedData,
    rendered: {
      html: parseData.body
    }
  });
};

contextからは Loader に必要な情報が提供されており、具体的には Vite の機能を利用したHMRを実現するためのwatcherや、ログを記録するためのloggerなどがあります。

より詳細を知りたい方は Astro Content Loader API | Docs を参照してください。

コラム：Markdownコンテンツのパース

実際にLoaderを実装しようとすると、MarkdownコンテンツをHTMLとして扱えるようにしたいケースが多いと思います。

Astro が提供するrender APIを用いることで、DataStoreに格納された各DataEntryのrenderedプロパティをHTMLとして描画できます。

---
import { render } from 'astro:content';

const entry = await getEntry('blog', '1');
const { Content } = await render(entry);
---

<Content />

しかしこのrender関数はあくまでstring型のentry.rendered.htmlをそのまま表示するだけで、MarkdownをHTMLに変換する機能は内包されていません。

この部分は自前で実装する必要があり、たとえば@astrojs/markdown-remarkを利用することでMarkdownをHTMLに変換することができます。

import { AstroConfig } from 'astro';
import { DataEntry } from "astro:content";
import { createMarkdownProcessor } from "@astrojs/markdown-remark";

export const renderToString = async (config: AstroConfig, entry: DataEntry) => {
  const processor = await createMarkdownProcessor(config.markdown);
  const result = await processor.render(entry.body || '');
  return {
    html: result.code,
  }
};

おわりに

2024年は人生初の北海道（生まれてからずっと千葉県民）のカンファレンス²に行き、「個人ブログ、もうリニューアルしないぞ！」という発表をしてきました。

長期休みは個人ブログを作り直しがちで、ちょうど1年前のお正月にブログを作り直しています…。北の大地で交わした約束を反故にするわけにもいきませんので、今年の年末年始は自分ではない誰かのブログをリニューアルさせることを目標にこちらの記事を執筆しました。

冗談はさておき。個人ブログを開発することは、普段扱っているアプリケーションとは異なる視点での開発ができるためおすすめです。今回紹介した Content Layer を使って、より簡単にコンテンツを取得することができるようになりましたので、ぜひ今年の年末年始は個人ブログを作ってみてはいかがでしょうか。

参考

Footnotes

記事執筆時点（2024/12/10）ではインメモリのKey-Valueストアとして実装されている ↩
Tech RAMEN Conference 2024。旭川で開催されたいろいろと異色のカンファレンス。 ↩

Make Impossible States Impossibleを意識してReactのPropsを設計する

ikuma-t — Fri, 15 Nov 2024 00:00:00 GMT

このブログ記事は下記のLT登壇資料を文字起こし（？）したものです。

Reactが関数型プログラミングの影響を受けているということをきっかけに、最近 ¹ は関数型プログラミングを少しずつ学んでいます。

関数型プログラミングそのものにももちろん興味はありつつ、日常のプログラミングで使えるエッセンスとしても何か学びはないか、という視点で向き合っています。いろいろとやっていく中で、「Make Impossible States Impossible」という考えを知りました。「不可能な状態が起こらないように型/インターフェイスを設計しよう」という意味です。

考え方自体はAPIの設計において汎用的に使える指針であり、フロントエンドに関連のある領域だと、Production Ready GraphQLやKent C. Dodds氏のブログ記事で取り上げられていました。

Make Impossible States Impossible とは

繰り返しになりますが、Make Impossible States Impossible、あるいは Make Illegal States Unrepresentable は「不可能な状態が起こらないように型/インターフェイスを設計しよう」という設計思想です。

関数型プログラミング言語のコミュニティを出自とする設計思想で、TypeScriptやReactの界隈でも何度か取り上げられているようです。少し前に日本語訳が発売された関数型ドメインモデリングでも「Making Illigal States Unrepresentable In Our Domain」というセクションで紹介されています。

具体的な出典については、Appendixに掲載しましたので、そちらをご参照ください。

Reactでの実践例

ここからはReactのコードを例に、Make Impossible States Impossibleの適用を見てみます。

単一のプロパティでの例はさほど問題にならない

たとえばprimaryとsecondary、2つのスタイルを持つボタンコンポーネントを考えます。

実装パターンの1つはそれぞれをスイッチ的なフラグで定義することです（2値しかないと、1つのフラグで管理することが可能ですが、ここではサンプルのためご容赦ください）。

type Props = {
  primary?: boolean;
  secondary?: boolean;
}

<Button primary /> // primary
<Button secondary /> // secondary

これは一見良さそうですが、少し考えるとprimaryとsecondaryを同時に指定することができてしまいます。これは不整合な状態を引き起こします。

<Button primary secondary /> // ??

この例では、primaryとsecondaryのそれぞれが2つの値を取るため、合計で4つの状態が考えられます。このように、プロパティの数が増えると、「プロパティが取りうる値のパターン」と「プロパティの数」の積だけ状態が増えてしまい、結果として不正な状態が発生しやすくなります。

これを解消するための方法の1つは、Union型を使ってプロパティを排他的に定義することです。

type Props = {
  variant: 'primary' | 'secondary';
}

<Button variant="primary" />]
<Button variant="secondary" />

variant²はprimaryかsecondaryのどちらかを取るため、不正な状態が発生しません。また取りうる状態も2つ（取りうる値の組み合わせの数の和）になりました。

この例のようにvariantでスタイルを定義するパターンは多くのUIライブラリが同様に実装していることもあり、割と当たり前になっていると個人的には感じています³。

そのため、単一のプロパティを使った状態についてはMake Impossible States Impossibleも自然に実現されることが多いでしょう。

複数のプロパティでの例

問題となるのは複数のプロパティの例です。コンポーネントの状態に作用するプロパティが複数ある場合、「それぞれのプロパティが取りうる値の数」と「プロパティの数」の積だけ、発生しうる状態が増えてしまいます。

ここで実例として、Empty Stateコンポーネントを考えます。Empty Stateコンポーネントは、データが存在しない場合の統一的な見た目を提供するコンポーネントです。次の画像のような見た目をしています。

このコンポーネントのPropsは、シンプルに次のように定義できます。

type Props = {
  title: string;
  description: string;
  buttonText: string;
  onClick: () => void;
}

初期時点では新規作成ボタンだけが要件としてあり、すべてのプロパティは必須です。この時点では特に問題はありません。

ここで要件として、新たに「アプリ内で新規リソースを作成するわけではない場合、ボタンをリンクのスタイルで表示したい」という要件が追加されたとします。

type Props = {
  title: string;
  description: string;
  buttonText: string;
  buttonText?: string;
  onClick: () => void;
  onClick+: () => void;
  /* リンクのテキスト。これを指定するとリンクを示すアイコンが表示されます */
  linkText?: string;
  /* 外部リンクかどうか。アイコンが変わるのと別タブで開く挙動が追加されます */
  isExternalLink?: boolean;
  /* リンク先URL。これを指定するとリンクが有効になります */
  href?: string;
}

追加の変更だけで要件のスタイルを実現できました。しかしここには問題があります。ここまでで述べてきたように、「linkTextを指定しているが、hrefを指定していない」「buttonTextとhrefが同時に指定してある」など、不正な状態が発生してしまいます。

Discriminated Unionによる解決

解決策の1つは、TypeScript の Discriminated Union を用いて、状態を排他的に定義することです。

type AddResourceButtonProps = {
  type: "button"
  buttonText: string;
  onClick: () => void;
}

type AddResourceLinkProps = {
  type: "link"
  linkText: string;
  href: string;
  isExternalLink?: boolean;
}

type Props = {
  title: string;
  description: string;
  addResourceUIProps: AddResourceButtonProps | AddResourceLinkProps;
}

このサンプルでは、typeがタグとしての機能を果たしているため、type="button"の時にはAddResourceButtonPropsのプロパティが、type="link"の時にはAddResourceLinkPropsのプロパティだけが指定できるようになります。

Compositionによる解決

もう1つの解決策は、Compositionを使うことです。Empty Stateコンポーネントが内包するButtonのスタイルが複数あることがそもそもの複雑さの原因なので、これを分離することで問題を解決します。

渡された関数、ここではButtonコンポーネントを呼び出すことだけを任せます。

type Props = PropsWithChildren<{
  title: string;
  description: string;
}>

ボタンのスタイルはchildrenに渡すButtonコンポーネント側で定義します。

/* Buttonのパターン */
<EmptyStatePanel title="..." description="...">
  <Button variant="primary" size="md" onClick={createPost}>
    記事を書く
  </Button>
</EmptyStatePanel>

/* Linkのパターン */
<EmptyStatePanel title="..." description="...">
  <Button variant="secondary" size="lg" asChild>
    <Link href={supportPageURL} external>
      サポートページへ
    </Link>
  </Button>
</EmptyStatePanel>

/* Linkのパターン（LinkButtonをスタイル使い回しのために別途用意する */
const LinkButton: FC<PropsWithChildren<{ href: string }>> = ({ href, children }) => {
  return (
    <Button variant="secondary" size="lg" asChild>
      <Link href={href} external>
        {children}
      </Link>
    </Button>
  );
}

<EmptyStatePanel title="..." description="...">
  <LinkButton href={supportPageURL}>
    サポートページへ
  </LinkButton>
</EmptyStatePanel>

Buttonに関する状態はButtonコンポーネント側で管理されるため、EmptyStatePanelコンポーネントでは先ほどのような不整合な状態が発生しません（前提として、Buttonコンポーネントが不正な状態が定義できないようになっている必要がありますが）。

既存コンポーネントの変更の際には状態の増加に気をつける

新規でコンポーネントを作成する際には、組み合わせの数が少ないか、組み合わせ自体があっても実装者がすべてのパターンを意識して設計するため、自然とMake Impossible States Impossibleを満たした設計になりやすいと感じます。

反対に既存のコンポーネントに対して変更を加える際には、新しく追加しようとしている状態だけにフォーカスが向いているために、不正な状態が発生しやすいと感じます。

特に既存の汎用コンポーネントを修正する際には、既存の構造に引っ張られることもあり、isFooのようなフラグ的なPropsを生やす引力が働きやすいのもかもしれません。

フラグが1個増えたら、単体で状態が2個増え、最終的に同じ箇所に影響するPropsの数の2倍分、考えうる状態が増えます。そのため、既存のコンポーネントに対して変更を加える際には、状態の増加に気をつけることが重要です。

まとめ

Make Impossible States Impossibleは、不正な状態が発生しないように型/インターフェイスを設計する考え方。
API 設計においても、React コンポーネントの Props 設計においても適用できる。React では Discriminated Union や Composition を使うことで実現できる。
特に既存コンポーネントを実装する際には、既存実装の引力が働きやすいことと、実装対象にフォーカスしていることが多いので、新しく追加する実装が不正な状態を引き起こさないかを意識することが重要。

React における Make Impossible States Impossible の考え方について、簡単な例を交えて紹介しました。

TypeScriptの文脈だと、最近はTSバックエンドで語られることご多い気がしますが、冒頭で述べた通りAPI設計で汎用的に使える考え方なので、ReactのProps設計にも適用できます。実践方法である Discriminated Union や Composition については、React や TypeScript では基本的なものです。重要なのはこれらのテクニックというより、これらを適用するための1つの指針としての Make Impossible States Impossible の考え方を意識することだと感じます。

今回挙げた例では「単一責任の原則」「不要な結合関係を排除する」などさまざまな視点からもアプローチができると思いますので、あくまで設計時に使える1つの視点として参考にしていただければと思います。

Appendix

Make Impossible States Impossible / Make Illegal States Unrepresentable について言及された記事・動画

私が調べた範囲で記載します。2011年くらいから言及されていて、2016-2019あたりの記事が多い印象です。

Jane Street Tech Blog - Effective ML Revisited
- 2011年で調べた中ではもっとも古い出典。
Make Impossible States Impossible
- React界隈で有名なKent C. Dodds氏によるブログ記事
David Khourshid - Infinitely Better UIs with Finite Automata - YouTube
- XStateの作者（stately.ai社のファウンダー）であるDavid Khourshid氏による動画
“Making Impossible States Impossible” by Richard Feldman - YouTube
- わりと色々なところで言及されることの多い、Elm Conference 2016でのRichard Feldman氏の講演
関数型ドメインモデリング
- Part II. Modeling The Domain 6. Integrity and Consistency in the Domain の中で「Making Illigal States Unrepresentable In Our Domain」というセクションがある。
Designing with types: Making illegal states unrepresentable | F# for fun and profit
- 上記の関数型ドメインモデリングの著者のブログ記事
「ADT, 直和・直積, State Machine」 #TypeScript - Qiita
- 上記の著者のブログをベースに解説された日本後の記事
pragmatic-types/posts/making-impossible-states-impossible.md at master · stereobooster/pragmatic-types
Patrick Stapfer: Making Unreasonable States Impossible - ReasonML Munich Meetup - YouTube
Make impossible states impossible - Elm Patterns
Make Impossible States Impossible
Making Impossible States Impossible with TypeScript
Making impossible states impossible with TypeScript - DEV Community
Making impossible states impossible: data structures in React - Jack Franklin
Avoid impossible UI states with React, Typescript and xState
Making impossible states impossible ft. Zod and Typescript
Avoiding impossible state with TypeScript
Making Impossible States with fp-ts and TypeScript in a React Application by Cristhian Motoche
rwieruch/react-making-impossible-views-impossible: React UI State: An example to make impossible views impossible.
Making Invalid State Impossible: in TypeScript and React | Steven Solomon
Making Illegal States Unrepresentable - mrsekut-p

XState と Zag.js と状態と

上記のリストの中に、状態管理ライブラリのXStateの作者による動画がありました。

XStateはステートマシンを中心に据えた状態ライブラリで、状態と遷移を明示的に定義することで、不正な状態を排除することができます。

さらにこの XState を内包した Zag.js は Chakra UI によるコンポーネントライブラリ（？）で、状態に応じた data 属性や、アクセシビリティのための属性を付与してくれます。

本記事の中では「状態」についての定義には触れませんでしたが、不正な状態を作らないためには、何が適正な状態かを明確に意識することも当然ながら重要です。

Zag.js ではさまざまなコンポーネントの状態をステートマシンとして定義しているため、UIコンポーネントにおける状態の参考になるかもしれません。

Zag.js のソースの追い方はまた別途記事にしようと思います。

Footnotes

2024年の夏前くらい？どこからどこまでが最近なんでしょうね。 ↩
この名前もどこが出典なのかはわかりませんが（意味的に自然にたどり着いている可能性も十二分にある）、関数型プログラミング言語であるOCamlにはvariantという概念があり、ここに影響を受けている部分は少なからずあるかもしれません。 ↩
とはいいつつ、Vuetifyの2系とかはもともとスタイルごとにbooleanで指定する形式で、Vuetify3系でvariantに変更されたので、ここ数年の話なのかもしれません。 ↩

CSSで親のコンテナのサイズをはみ出す子要素を作る

ikuma-t — Mon, 04 Nov 2024 00:00:00 GMT

コンテナから要素をはみ出したい

このブログでは全体のレイアウトを定義した上で、その中にヘッダーやフッター、メインコンテンツを配置しています。

イメージとしては次のようなHTML構造です。

<div class="container">
  <header>...</header>
  <main>...</main>
  <footer>...</footer>
</div>

.containerに対してはmax-widthを設定して、コンテンツが画面幅いっぱいに広がらないようにしています。

.container {
  max-width: 1200px;
  margin: 0 auto;
}

これによって共通の幅を確保できるのはいいのですが、たとえばヘッダーは横幅いっぱいに広げたい場合どうすればいいでしょうか？

解決策の1つはスタイルを共通ではなく、各セクションごとに定義することです。

<div>
  <header class="full-width">...</header>
  <main class="container">...</main>
  <footer class="container">...</footer>
</div>

これでもよいのですが、そのほかのスタイルをTailwind CSSで複数適用していたため、できれば共通のスタイルを使いたいところです。

calcでネガティブマージンを利用してはみ出す

はみ出したい子要素に対して、以下のスタイルを適用することで、やりたいことを実現できます。

body {
  container-type: inline-size;
}

/* ヘッダーをはみださせる */
header {
  width: 100vw;
  margin-inline: calc(50% - 50cqi);
  /* 親の幅に要素を寄せたい場合 */
  /* padding-inline: calc(50cqi - 50%); */
}

/* 変更なし */
.container {
  max-width: 1200px;
  margin: 0 auto;
}

HTMLについては、次のようになります。

<div class="container">
  <header>...</header>
  <main>...</main>
  <footer>...</footer>
</div>

適用のイメージについて、個人的には次のように考えるとわかりやすいかと思います。

親要素を基準に、100vwで要素を横幅いっぱいに広がる。親基準なので、画面の端からではなく親の端から広がる。これを調整したい。
親要素の左右それぞれに対して（つまり半分ずつに分割して考える）、画面幅の要素から親要素を引いた値をうめたい。これをネガティブマージンで再現する。
margin-inlineを利用して、水平方向に対して、2のマージンを適用する。

細かいポイントがコンテナクエリを使っていることです。50vwだと、スクロールバーを含めた部分までで横幅を計算するので、横スクロールバーが生じてしまいます。

bodyに対しての純粋な半分が欲しいので、bodyをコンテナに指定した上で、その半分である50cqiを指定すればこの問題も解決です（cqiはコンテナーのインライン（横書きだと水平方向）の1%をさす単位です）。

参考

技術書典17 オフライン会場での戦利品紹介

ikuma-t — Mon, 04 Nov 2024 00:00:00 GMT

技術書典17 オフライン会場に行ってきました！

昨日（2024/11/03）に池袋サンシャインシティで開催された技術書典17のオフライン会場に行ってきました！

オフライン会場は前回の技術書典16で初参加。その際は一般来場者としてでした。2回目となる今回はサークル主として自著を提げて参加しました。

そのため前回ほどゆっくりは会場を回れなかったのですが、色々なサークルの方の書籍を購入できたので、簡単な感想と共に戦利品紹介をしたいと思います。

現地会場での戦利品紹介

今回は現物で10冊、在庫が売切で電子で購入させていただいたのが1冊で、現地では計11冊購入させていただきました！

戦利品を書籍の五十音順で簡単に紹介します。

あざといLT

あざといLT：LT同好会

X上で面識のあるkaitouさんが書かれている、ということもあったのですが、自分自身がときどき外部登壇をしているので参考にしたい！と思い購入しました！

「LT登壇の必勝法は一点突破」というセクションがありまして、中身がぼやけがちな自分には結構刺さりましたね … …。聞き手の課題感・レベル感を想像して、それに対して自分の出せる手札から珠玉の一品を出すために、KJ法使ってみようと思います！

ちょうど今月またLTの機会があるので、その際は本書の内容を参考にします！

アクセシビリティを考えはじめるための本

アクセシビリティを考えはじめるための本：20 Hour Exception

「アクセシビリティの重要さは認識しているし、それを実現するために重要な技術トレンドもとりあえず追いかけてはいるが、自分が向き合っているサービスにその観点を落とし込みきれていない」という課題感を持っていたので、とてもありがたい内容でした。これは普段のお仕事のときにも常に横に置いておく一冊になりそうです。

あとこれは本の内容ではないのですが、行間・字間が適切に取られていて読みやすかったです（後半の章に「知覚しやすい表現を使う」というセクションがあり、「なるほど〜」と一人で納得していました）。

急いで購入していたので、ボイスオーバーによる売り上げの読み上げを存分に味わうことはできなかったのが少し心残りですが、現物を購入できたのでよし！

Amazon BedrockとGitHub Actionsで文章自動レビューを実装してみる本

Amazon BedrockとGitHub Actionsで文章自動レビューを実装してみる本：杜の都の開発室

ブログ執筆にはtextlintでのチェックを入れているのですが、もう少しチューニングした形でチェックしてもらえたらたしかに嬉しいなあと思い、購入しました。

Amazon BedrockはAWS開催のワークショップに参加して試していたのですが、ちょっとお高いな〜というイメージがありそれ以来使っていませんでした。なので最後の第4章の「トークン数とコストの把握」の内容はありがたかったです。今の記事投稿ペースくらいならBedrockを使ってもいいかも、と思いました！

好きなことなら本当に続けられるのか　〜100日連続イラスト投稿してきた日々を振り返る〜 / 鍛錬するとコードレビューがループする　〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜

みずりゅさんのサークルの書籍を2冊購入させていただきました。

好きなことなら本当に続けられるのか　〜100日連続イラスト投稿してきた日々を振り返る〜：URAMASU

習慣化の技術、みたいな書籍はときどき読んでいるのですが、なかなか続けられないのが実情（私は日記を途絶え途絶えやっています）。みずりゅさんは100日以上イラスト投稿を続けられていて「すごい！」と心で微笑んでいました。

今回の技術書典参加にあたり自分も人物イラストで表紙を描こうと思ったのですが、まったく納期に間に合う気がしませんでしたので、今回はキャラクターで妥協しました。次回以降の機会に備えて練習しようかなあ。

鍛錬するとコードレビューがループする　〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜：URAMASU

もう1冊はコードレビューについての書籍。コードレビューのプラクティスの関係性を図で表現したものです。個別の要素についての内容を深ぼったものは結構ある印象ですが、こういう全体像の関係性をまとめたものはありそうでなかったので、参考になりました！改善施策を考える上で非常に助かりますね。

みずりゅさんは過去にGleamに関する書籍を出されていることもあり（Gleamだからかサークル配置が隣）、今回ご挨拶できてよかったです。

店舗を読み解く技術～小売業ドメイン知識入門～

店舗を読み解く技術～小売業ドメイン知識入門～：株式会社プレーンテキスト

自分は小売業ドメインでは働いていないのですが、実利がなくても業界の知識覚えるのっておもしろいよね！ということで購入。

2章の「店を読む技術」がとくにおもしろく、「そんなところに専門用語ついているんだ」「そういう分類で現場の人は店を見ているのか！」と勉強になりました。ゴンドラエンド、日常でもつかいたいですね。

業界を捉える視点を整理するための書籍、という意味でもとてもよいと感じました。もちろん自分が携わる業界を知るには実際に働く人のところへ行くのが一番だとは思うのですが、エンジニアとしては常にそうしてもいられないし、どうしても座学で把握する必要があります。新しい業界を見る際に、本書の構成は良いガイドラインになりそうだな〜と思っています。

これは余談ですが、本書に出てくる「クルベ」を運営する「ベルク」は私のお気に入りのスーパーです。ベルク大好きエンジニア座談会とかいつか開催されないかなと勝手に思っています、はい。

虎の穴ラボの薄い本。vol.8

虎の穴ラボの薄い本。vol.8：虎の穴ラボ

東葛.devで知り合ったkounoさんに献本いただき入手しました（協賛ブースは地味に遠かったので、なかなか離れられない1人サークルにはありがたかったです！）。

自分は普段フロントエンドやっているので、Next.jsでのマーケティングツール導入、DenoでのWeb・CLI開発あたりを興味深く読ませていただきました。Cliffyは昔このブログのCLIを作るときに使っていたんですが、結構便利ですよね〜。

あとは随所に散りばめられているキャラの挿絵がとてもかわいくてよかったです …!最終ページの地方住まいマップもニコニコしながら読ませていただきました🤭

「ポッドキャストをやりたい！」と思ったらまず読む本

「ポッドキャストをやりたい！」と思ったらまず読む本：小沢あや

「ポッドキャストをやりたい！」と思っているので、購入させていただきました！ポッドキャスト、なかなか進まず、しかしながら今年中に始めたいと思っていたので、どんぴしゃりな内容でした。

ハウツーの部分ももちろん刺さったのですが、「変にバズらず、狭く、深く、ゆっくり届く」という章が自分にはとても興味深かったです。やさしいせかいだ … …。ますますやってみたい意欲が高まりましたね。

頑張って今年中に技術系のLTを軸にしたひとりポッドキャストを始めたいと思ってるので、本書の内容参考にします！

まじでめちゃくちゃ分かりやすい棒針編み入門漫画＜1巻＞

まじでめちゃくちゃ分かりやすい棒針編み入門漫画＜1巻＞：オノデラユズカオ制作

自分は過去に刺繍をはじめてみたこともあるのですが、どうも室内でできる趣味領域を開拓したい傾向があり、その流れで購入しました。

棒針編み、アニメとかで見て憧れますよね〜。できたらいいなと思いつつ、自分はあまり裁縫系（というか立体視？）が得意ではなく、書籍にある図を見ても「どれをどうしたらこうなるんじゃい … …」と途方に暮れることもしばしば。一方この本は図も大きくめちゃめちゃわかりやすいので、なんだか自分でもできる気がしました（漫画だけでも読み物として面白かったです）！

やったことは愚か道具すらないのですが、本書を読んで冬休みの予定が決まりましたね。

Ruby on Rails8入門！

Ruby on Rails8入門！：def合同会社

お隣のお隣のサークル（といいつつ、お隣のブースはお休みだったので、実質お隣）で販売されていた書籍です。こちらのブースにお越しいただいて話していたのですが、実は意外に接点があり盛り上がっておりました。

物理本は売り切れとのことだったので電子版で読ませていただきました。

最近はあまりRubyも書いておらずちゃんと中身まで見ていたのがRails 7系、DHHのポスト等をちらみしてワードだけは追っているが … … というレベル感だったので、本書でキャッチアップできてよかったです。

Rails、初学者のときはアプリを作るのは簡単だけど、デプロイが難しい、という印象があって、kamalは結構良さそうに思いました。少し前から開発用のDockerも含めてデフォルトで使えるようになっていましたが、ここらへんどんどん便利になっていきますね〜。

ゆるIETF

ゆるIETF：asnokaze

今回のオフライン会場で絶対に入手したい一冊でした。ASnoKaze blogは内容わかるときもわからない時もあるのですが、毎回読ませて勉強させていただいています。

HTTP/3のマスコットキャラの話や言語缶バッジの話など、おもわずふふッとなるお話しが多く、IETFという一般的な印象では固いテーマながら非常に楽しく読ませていただきました。標準化って難しいイメージあるけど、そこにはやっぱり人がいるんだなあという感想です。

最後の章では最新技術の動向を追う方法についても記載があり、自分はあまりここら辺を実践できていないので、今後の参考にさせていただこうと思います。

サークル参加

… … と、ここまで購入してきた書籍は基本的に15分くらいの休憩時間でシュバっと購入して、あとは自身のサークルの販売をやっていました。

まだマイナーな言語なので、正直数冊売れてくれれば十分だと思っていたのですが、思いの外多くの方にご購入いただけて嬉しかったです！

オンラインマーケットではまだ電子版および電子+紙版が購入できるので、ぜひチェックしていただければと思います！

はじめよう！Gleam：ikuma-t - 技術書典オンラインマーケット

Nihonbashi.js #9に参加してStorybookの話をしてきた

ikuma-t — Fri, 01 Nov 2024 00:00:00 GMT

Nihonbashi.js #9に参加してきた

Nihonbashi.js #9 - connpass

2024年11月1日開催のNihonbashi.js #9に参加してきました。

Web Developer Conference以来、2度目のサイボウズさんのオフィスでした。前回行っておいたおかげで迷わずにつけた … …。

LT会→懇親会の流れですすみ、懇親会ではStreamについて色々と教えていただいたり、ほかの会社さんの開発組織事情を聞くことができ、おもしろかったです。

今回はLT枠で申し込みさせていただいたので、5分間Storybookについて話してきた内容の詳細をこの記事では記録しておきます。

LT：いまさらのStorybook

タイトルの「いまさらの」は「みんなもう使っているだろうけど、こっちは業務で使ってひと月だから … …」というエクスキューズです。実際話してみると、全員が全員そういうわけでもなかった模様なので、期待値調整は難しいですね。

内容としてはスライドの通り2部構成になっています。

Storyで使うTypeScriptの型定義
Storybook自体がどのように動くか

スライドの通りではありますが、少しだけ文章で補足します。

Storyで使うTypeScriptの型定義を読み解く

Storyの型定義

Storyのファイルを書くと、基本的には次のような形になります。

import type { Meta, StoryObj } from '@storybook/react';

import { Button } from './Button';

const meta = {
  component: Button,
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof Button>;

export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
};

ここにはMetaとStoryObjの2つの型がありますが、これらはいずれもStorybookが準拠するComponent Story Format 3に必要な属性を規定する型になっています。

CSF3に必要な属性を定義するBaseAnnotationsインターフェイス

型定義を追っていくと、いずれも最終的にはBaseAnnotationsというインターフェイスをimplementしていることがわかります。

export interface BaseAnnotations<TRenderer extends Renderer = Renderer, TArgs = Args> {
  /**
   * Wrapper components or Storybook decorators that wrap a story.
   *
   * Decorators defined in Meta will be applied to every story variation.
   * @see [Decorators](https://storybook.js.org/docs/addons/introduction/#1-decorators)
   */
  decorators?:
    | DecoratorFunction<TRenderer, Simplify<TArgs>>[]
    | DecoratorFunction<TRenderer, Simplify<TArgs>>;

  /**
   * Custom metadata for a story.
   * @see [Parameters](https://storybook.js.org/docs/basics/writing-stories/#parameters)
   */
  parameters?: Parameters;

  /**
   * Dynamic data that are provided (and possibly updated by) Storybook and its addons.
   * @see [Arg story inputs](https://storybook.js.org/docs/react/api/csf#args-story-inputs)
   */
  args?: Partial<TArgs>;

  /**
   * ArgTypes encode basic metadata for args, such as `name`, `description`, `defaultValue` for an arg. These get automatically filled in by Storybook Docs.
   * @see [Control annotations](https://github.com/storybookjs/storybook/blob/91e9dee33faa8eff0b342a366845de7100415367/addons/controls/README.md#control-annotations)
   */
  argTypes?: Partial<ArgTypes<TArgs>>;

  /**
   * Asynchronous functions which provide data for a story.
   * @see [Loaders](https://storybook.js.org/docs/react/writing-stories/loaders)
   */
  loaders?: LoaderFunction<TRenderer, TArgs>[] | LoaderFunction<TRenderer, TArgs>;

  /**
   * Function to be called before each story. When the function is async, it will be awaited.
   *
   * `beforeEach` can be added to preview, the default export and to a specific story.
   * They are run (and awaited) in the order: preview, default export, story
   *
   * A cleanup function can be returned.
   */
  beforeEach?: BeforeEach<TRenderer, TArgs>[] | BeforeEach<TRenderer, TArgs>;

  /**
   * Define a custom render function for the story(ies). If not passed, a default render function by the renderer will be used.
   */
  render?: ArgsStoryFn<TRenderer, TArgs>;

  /**
   * Named tags for a story, used to filter stories in different contexts.
   */
  tags?: Tag[];

  mount?: (context: StoryContext<TRenderer, TArgs>) => TRenderer['mount'];
}

https://github.com/ComponentDriven/csf/blob/v0.1.11/src/story.ts#L339

BaseAnnotationsはStorybook側のリポジトリではなく、csfのリポジトリで定義されています。中身としてはいつもStoryを定義している際に使っている属性を含んだ型となっているようです。

Componentレベル・Storyレベルでの設定を実現するためのMeta型、StoryObj型

MetaとStoryObjは定義する属性としてはほぼ同じですが、設定の粒度が異なります。前者はComponentレベル、後者はStoryレベルの設定を可能にします。

具体的な例として、コンポーネントに渡すargsを実例に、型による設定レベルの切り分けの実際をみていきます。なおサンプルのコンポーネントとしては、Reactで以下のように定義されたButtonコンポーネントを使います。

type ButtonProps = {
  label: string
  variant?: "solid" | "ghost" | "outline"
  onClick = () => void
}

const Button: FC<ButtonProps> = ...

const meta = {
  // ...
} satisfies Meta<typeof Button>;

export default meta
type Story = StoryObj<typeof meta>

Meta（Componentレベル）ではコンポーネントのPropsを任意で設定できる

まずStoryレベルのMetaでは、すべてのPropsを任意で指定できるようにしています。Componentレベルはあくまで共通で設定したい場合に使うものであるためです。具体的な型としては次のような定義になっています。

/**
 * Metadata to configure the stories for a component.
 *
 * @see [Default export](https://storybook.js.org/docs/formats/component-story-format/#default-export)
 */
type Meta<TCmpOrArgs = Args> = [TCmpOrArgs] extends [ComponentType<any>] ? ComponentAnnotations<ReactRenderer, ComponentProps<TCmpOrArgs>> : ComponentAnnotations<ReactRenderer, TCmpOrArgs>;

ここでTCmpOrArgsはtypeof Buttonなので、ComponentAnnotations<ReactRenderer, ComponentProps<TCmpOrArgs>>がかえります。

interface ComponentAnnotations<TRenderer extends Renderer = Renderer, TArgs = Args> extends BaseAnnotations<TRenderer, TArgs> {
    /**
     * Title of the component which will be presented in the navigation. **Should be unique.**
     *
     * Components can be organized in a nested structure using "/" as a separator.
     *
     * Since CSF 3.0 this property is optional -- it can be inferred from the filesystem path
     *
     * @example
     * export default {
     *   ...
     *   title: 'Design System/Atoms/Button'
     * }
     *
     * @see [Story Hierarchy](https://storybook.js.org/docs/basics/writing-stories/#story-hierarchy)
     */
    title?: ComponentTitle;
    /**
     * Id of the component (prefix of the story id) which is used for URLs.
     *
     * By default is inferred from sanitizing the title
     *
     * @see [Story Hierarchy](https://storybook.js.org/docs/basics/writing-stories/#story-hierarchy)
     */
    id?: ComponentId;
    /**
     * Used to only include certain named exports as stories. Useful when you want to have non-story exports such as mock data or ignore a few stories.
     * @example
     * includeStories: ['SimpleStory', 'ComplexStory']
     * includeStories: /.*Story$/
     *
     * @see [Non-story exports](https://storybook.js.org/docs/formats/component-story-format/#non-story-exports)
     */
    includeStories?: StoryDescriptor$1;
    /**
     * Used to exclude certain named exports. Useful when you want to have non-story exports such as mock data or ignore a few stories.
     * @example
     * excludeStories: ['simpleData', 'complexData']
     * excludeStories: /.*Data$/
     *
     * @see [Non-story exports](https://storybook.js.org/docs/formats/component-story-format/#non-story-exports)
     */
    excludeStories?: StoryDescriptor$1;
    /**
     * The primary component for your story.
     *
     * Used by addons for automatic prop table generation and display of other component metadata.
     */
    component?: (TRenderer & {
        T: Record<string, unknown> extends Required<TArgs> ? any : TArgs;
    })['component'];
    /**
     * Auxiliary subcomponents that are part of the stories.
     *
     * Used by addons for automatic prop table generation and display of other component metadata.
     *
     * @example
     * import { Button, ButtonGroup } from './components';
     *
     * export default {
     *   ...
     *   subcomponents: { Button, ButtonGroup }
     * }
     *
     * By defining them each component will have its tab in the args table.
     */
    subcomponents?: Record<string, TRenderer['component']>;
    /**
     * Function that is executed after the story is rendered.
     */
    play?: PlayFunction<TRenderer, TArgs>;
    /**
     * Override the globals values for all stories in this component
     */
    globals?: Globals;
}

そしてこのComponentAnnotationsは先ほどのBaseAnnotaionsをimplementしています。ComponentAnnotationsにはargsはありませんが、これはBaseAnnotationsに定義されています。

型引数のTArgs>にはComponentProps<TCmpOrArgs>>が渡りますので、合わせるとargsの型は次のようになります。

{
  args: Partial<ComponentProps<ComponentProps<typeof Button>>>>
}

したがって、argsはButtonのすべてのPropsをOptionalで受け入れる型になり、Componentレベルの設定を満たすことになります。

StoryObj（Storyレベル）ではComponentレベルで定義したPropsは任意になる

つづいてStoryObjです。

/**
 * Story object that represents a CSFv3 component example.
 *
 * @see [Named Story exports](https://storybook.js.org/docs/formats/component-story-format/#named-story-exports)
 */
type StoryObj<TMetaOrCmpOrArgs = Args> = [TMetaOrCmpOrArgs] extends [
    {
        render?: ArgsStoryFn<ReactRenderer, any>;
        component?: infer Component;
        args?: infer DefaultArgs;
    }
] ? Simplify<(Component extends ComponentType<any> ? ComponentProps<Component> : unknown) & ArgsFromMeta<ReactRenderer, TMetaOrCmpOrArgs>> extends infer TArgs ? StoryAnnotations<ReactRenderer, AddMocks<TArgs, DefaultArgs>, SetOptional<TArgs, keyof TArgs & keyof DefaultArgs>> : never : TMetaOrCmpOrArgs extends ComponentType<any> ? StoryAnnotations<ReactRenderer, ComponentProps<TMetaOrCmpOrArgs>> : StoryAnnotations<ReactRenderer, TMetaOrCmpOrArgs>;

StoryObjは分岐が多くぱっと見読みづらいです。Reactコンポーネントで形成するMetaを渡した場合の型を抜粋するとこの部分のなります。

StoryAnnotations<ReactRenderer, AddMocks<TArgs, DefaultArgs>, SetOptional<TArgs, keyof TArgs & keyof DefaultArgs>>

StoryAnnotationsは名前から察するとおり、さきほどのComponentAnnotationsのStory版です。

type StoryAnnotations<TRenderer extends Renderer = Renderer, TArgs = Args, TRequiredArgs = Partial<TArgs>> = BaseAnnotations<TRenderer, TArgs> & {
    /**
     * Override the display name in the UI (CSF v3)
     */
    name?: StoryName;
    /**
     * Override the display name in the UI (CSF v2)
     */
    storyName?: StoryName;
    /**
     * Function that is executed after the story is rendered.
     */
    play?: PlayFunction<TRenderer, TArgs>;
    /**
     * Override the globals values for this story
     */
    globals?: Globals;
    /** @deprecated */
    story?: Omit<StoryAnnotations<TRenderer, TArgs>, 'story'>;
} & ({} extends TRequiredArgs ? {
    args?: TRequiredArgs;
} : {
    args: TRequiredArgs;
});

ここではargsの型は、3つめの型引数に渡した型、つまりSetOptional<TArgs, keyof TArgs & keyof DefaultArgs>になります。SetOptional自体は何かというと、type-festで定義されている型ユーティリティで、指定したキーをOptionalにするものです。

https://github.com/sindresorhus/type-fest/blob/main/source/set-optional.d.ts

ここではkeyof TArgs & keyof DefaultArgsがOptionalにする対象なので、Componentレベルで定義したProps（DefaultArgs）があれば、それらはOptionalになります。

Storyの型定義のまとめ

csfから提供されるBaseAnnotationsという型によってComponent Story Formatに必要な属性を規定する
MetaもStoryObjもBaseAnnotationsをimplementしたCSFを定義する型

Storyはどのようにコンポーネントカタログになるのか

たとえばstorybook devコマンドを実行した時に、定義したStoryがどういう過程を経てStorybookのあのUIになっているのかが気になっていました。 Storybookと実際のアプリケーションとの環境間差異を把握したいためです。全体像を把握しておけば新しいBundlerやPluginが追加になっても、ある程度想像がつくようになると考え、ざっとですが、storybook devからUIが立ち上がるまでを追いかけてみました。

対象バージョン：Storybook 8.3.6

結論

エントリポイント

2つのBuilder

ManagerBuilderとPreviewBuilderという2つのBuilderが取得されています。

  const [previewBuilder, managerBuilder] = await Promise.all([
    getPreviewBuilder(builderName, options.configDir),
    getManagerBuilder(),
    useStatics(router, options),
  ]);

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/core-server/dev-server.ts#L76-L80

これらについてはStorybookのドキュメントのBuilder APIのセクションに説明があります。

画像の通りではありますが、アプリケーションのコンポーネントを描画するiframe部分のためのビルドツールをPreview Builderと読んでおり、それ以外のStorybook自体のUI部分のためのビルドツールをManager Builderと呼ぶそうです。

Manager Builder

Manager BuilderではStorybookのUIをビルドします。実際にはStorybookに内包される部分だけではなく、StorybookのUI部分に作用するAdd-Onもビルドの対象です、

実態を追っていきます。まずManagerBuilder自体の取得は次のとおり、動的なimportによって実行されます。

export async function getManagerBuilder(): Promise<Builder<unknown>> {
  return import('@storybook/core/builder-manager');
}

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/core-server/utils/get-builders.ts#L7-L9

（Manager BuilderとBuilder Managerだと違う意味に取れそうなものですが … …）。

ここで取得されたManager Builderもといbuilder-managerパッケージに対して、dev-server側はstartを呼び出しています。

start関数自体はそこそこに長い処理ですが、やっていることとしてはesbuildによるビルド実行→sirvを介してビルドした静的ファイルをサーブする、という2点です。

getData関数ではesbuildのインスタンスやHTMLファイルのエントリポイントとなるejsファイルを取得します。

export const getData = async (options: Options) => {
  const refs = getRefs(options);
  const favicon = options.presets.apply<string>('favicon').then((p) => basename(p));

  const features = options.presets.apply<Record<string, string | boolean>>('features');
  const logLevel = options.presets.apply<string>('logLevel');
  const title = options.presets.apply<string>('title');
  const docsOptions = options.presets.apply('docs', {});
  const tagsOptions = options.presets.apply('tags', {});
  const template = readTemplate('template.ejs');
  const customHead = options.presets.apply<string>('managerHead');

  // we await these, because crucially if these fail, we want to bail out asap
  const [instance, config] = await Promise.all([
    //
    executor.get(),
    getConfig(options),
  ]);

  return {
    refs,
    features,
    title,
    docsOptions,
    template,
    customHead,
    instance,
    config,
    logLevel,
    favicon,
    tagsOptions,
  };
}

ここで読み込まれるのは、次のejsファイルです。

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />

    <title><%= typeof title !== 'undefined'? title : 'Storybook'%></title>
    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />

    <% if (favicon.endsWith('.svg')) {%>
    <link rel="icon" type="image/svg+xml" href="./<%= favicon %>" />
    <% } else if (favicon.endsWith('.ico')) { %>
    <link rel="icon" type="image/x-icon" href="./<%= favicon %>" />
    <% } %>
    <style>
      // 省略
    </style>

    <link href="./sb-manager/runtime.js" rel="modulepreload" />

    <% files.js.forEach(file => { %>
    <link href="<%= file %>" rel="modulepreload" />
    <% }); %> <% if (typeof head !== 'undefined') { %> <%- head %> <% } %>

    <style>
      #storybook-root[hidden] {
        display: none !important;
      }
    </style>

    <% files.css.forEach(file => { %>
    <link href="<%= file %>" rel="stylesheet" />
    <% }); %>
  </head>
  <body>
    <div id="root"></div>

    <% if (typeof globals !== 'undefined' && Object.keys(globals).length) { %>
    <script>
      <% for (var varName in globals) { %>
        <% if (globals[varName] !== undefined) { %>
          window['<%=varName%>'] = <%- (globals[varName]) %>;
        <% } %>
      <% } %>
    </script>
    <% } %>

    <script type="module">
      import './sb-manager/globals-runtime.js';

      <% files.js.forEach(file => { %>
        import '<%= file %>';
      <% }); %>

      import './sb-manager/runtime.js';
    </script>

    <% if (!ignorePreview) { %>
    <link href="./sb-preview/runtime.js" rel="prefetch" as="script" />
    <% } %>
  </body>
</html>

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/assets/server/template.ejs

ランタイムとして同梱される./sb-manager/runtime.jsでは、StorybookのUIをレンダリングするrenderStorybookUI関数を呼び出しています。

const { document } = global;
const rootEl = document.getElementById('root');

// We need to wait for the script tag containing the global objects
// to be run by Webkit before rendering the UI. This is fine in most browsers.
setTimeout(() => {
  // @ts-expect-error (non strict)
  renderStorybookUI(rootEl, new ReactProvider());
}, 0)

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/manager/runtime.ts#L45-L53

ここから先はいつものReactの世界でした。

export function renderStorybookUI(domNode: HTMLElement, provider: Provider) {
  if (!(provider instanceof Provider)) {
    throw new ProviderDoesNotExtendBaseProviderError();
  }

  const root = createRoot(domNode);
  root.render(<Root key="root" provider={provider} />);
}

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/manager/index.tsx

Storybookのレイアウト

  <Layout
  hasTab={hasTab}
  managerLayoutState={managerLayoutState}
  setManagerLayoutState={setManagerLayoutState}
  slotMain={<Preview id="main" withLoader />}
  slotSidebar={<Sidebar onMenuClick={() => setMobileAboutOpen((state) => !state)} />}
  slotPanel={<Panel />}
  slotPages={pages.map(({ id, render: Content }) => (
    <Content key={id} />
  ))}
  />

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/manager/App.tsx#L26-L35

Previewコンポーネントが実際にコンポーネントを描画する領域で、いくつかコンポーネントを潜っていくと、iframeを見つけることができます。

const StyledIframe = styled.iframe(({ theme }) => ({
  backgroundColor: theme.background.preview,
  display: 'block',
  boxSizing: 'content-box',
  height: '100%',
  width: '100%',
  border: '0 none',
  transition: 'background-position 0s, visibility 0s',
  backgroundPosition: '-1px -1px, -1px -1px, -1px -1px, -1px -1px',
  margin: `auto`,
  boxShadow: '0 0 100px 100vw rgba(0,0,0,0.5)',
}));

https://github.com/storybookjs/storybook/blob/v8.3.6/code/core/src/manager/components/preview/Iframe.tsx#L7-L18

Preview Builder

Preview Builderは先述の通り、ユーザーが定義したStoryのためのBuilderです。Builderは次のインターフェイスを満たすことを必要としており、実際にdev serverの中でもstartやbailなどが呼び出されています。

export interface Builder<Config, Stats> {
  start: (args: {
    options: Options;
    startTime: ReturnType<typeof process.hrtime>;
    router: Router;
    server: Server;
  }) => Promise<void | {
    stats?: Stats;
    totalTime: ReturnType<typeof process.hrtime>;
    bail: (e?: Error) => Promise<void>;
  }>;
  build: (arg: {
    options: Options;
    startTime: ReturnType<typeof process.hrtime>;
  }) => Promise<void | Stats>;
  bail: (e?: Error) => Promise<void>;
  getConfig: (options: Options) => Promise<Config>;
  corePresets?: string[];
  overridePresets?: string[];
}

https://storybook.js.org/docs/builders/builder-api#builder-api

現在Storybookで利用できるBuilderにはwebpackとViteがあるので、今回は@storybook/builder-viteを読んでみます。

builder-vite

builder-viteもStorybookのリポジトリに格納されています。 https://github.com/storybookjs/storybook/tree/v8.3.6/code/builders/builder-vite

export const start: ViteBuilder['start'] = async ({
  startTime,
  options,
  router,
  server: devServer,
}) => {
  server = await createViteServer(options as Options, devServer);

  const previewResolvedDir = join(corePath, 'dist/preview');
  router.use(
    '/sb-preview',
    sirv(previewResolvedDir, {
      maxAge: 300000,
      dev: true,
      immutable: true,
    })
  );
  router.use(iframeMiddleware(options as Options, server));
  router.use(server.middlewares);

  return {
    bail,
    stats: {
      toJson: () => {
        throw new NoStatsForViteDevError();
      },
    },
    totalTime: process.hrtime(startTime),
  };
};

startの処理はこれだけで、やっていることととしては次のとおりです。

middlewareModeでViteのcreateServerを実行する。
Storybookのcoreディレクトリを起点としてdist/previewを静的アセットとして配信できるようにします。
iframeMiddlewareをミドルウェアとして指定します。
1をミドルウェアとして指定する。

まず1のmiddlewareModeについて、これによりルーティングの制御はrouter、つまりStorybookがpolkaを用いてたてたHTTPサーバに移ります。結果としてルーティング後の処理をViteが受け持てるようになります。サーバーサイドレンダリング | Viteがわかりやすく、この例ではexpressを使っていますが、polkaを使っていても同じ要領で読めるかと思います。

次に2のdist/previewですが、これはViteが配信するiframe.htmlで読み込まれるスクリプトを指しています。

3のiframeMiddlewareは同じファイルに定義されており、どうもiframe.htmlでリクエストが来た場合に、@storybook/buider-vite/input/iframe.htmlをごにょごにょして返すmiddlewareのようです。

function iframeMiddleware(options: Options, server: ViteDevServer): Middleware {
  return async (req, res, next) => {
    if (!req.url || !req.url.match(/^\/iframe\.html($|\?)/)) {
      next();
      return;
    }
    // the base isn't used for anything, but it's required by the URL constructor
    const url = new URL(req.url, 'http://localhost:6006');

    // We need to handle `html-proxy` params for style tag HMR https://github.com/storybookjs/builder-vite/issues/266#issuecomment-1055677865
    // e.g. /iframe.html?html-proxy&index=0.css
    if (url.searchParams.has('html-proxy')) {
      next();
      return;
    }

    const indexHtml = await readFile(require.resolve('@storybook/builder-vite/input/iframe.html'), {
      encoding: 'utf8',
    });
    const generated = await transformIframeHtml(indexHtml, options);
    const transformed = await server.transformIndexHtml('/iframe.html', generated);
    res.setHeader('Content-Type', 'text/html');
    res.statusCode = 200;
    res.write(transformed);
    res.end();
  };
}

というわけでViteの世界のエントリポイントはiframe.htmlになりそうなので、次はここを起点に処理をみます。

iframe.html

  <body>
    <!-- [BODY HTML SNIPPET HERE] -->
    <div id="storybook-root"></div>
    <div id="storybook-docs"></div>
    <script type="module" src="./sb-preview/runtime.js"></script>
    <script type="module" src="/virtual:/@storybook/builder-vite/vite-app.js"></script>
  </body>

iframe.htmlの中身は薄く、bodyとしてはこれだけです。いくつかdivがあるのでStorybookのUIと照らし合わせると、たしかにiframeの中にこの要素がありますね。

さきほども出てきましたが、sb-preview/runtime.jsが出てきているので、これを確認します。

sb-preview/runtime.js

実際のディレクトリでいうと、code/core/src/previewを指していそうです。このモジュールでは、Storybookの各モジュールをグローバルスコープに突っ込む役割を担っています。

あまり具体的な処理はなかったので、もう1つのscriptをみます。

@storybook/builder-vite/vite-app.js

Viteの仮想モジュールなのですが、具体的にどのファイルの処理で生成されるものを指しているのかいまいちわからず … …。

残念ながら今回はここでタイムアップです。

おわりに

発表ではStorybook 8.3で発表されたexperimental-nextjs-viteにも触れたのですが、こちらもあまり深追いはできておらず、サラッと紹介する程度でした。まだまだコード読解力が足りませんね。

ただ今回のドキュメントリーディング、コードリーディングを経て、だいぶStorybookに対して自信が持てました。

「こんにちは TAG-さん!」とは何か

ikuma-t — Sat, 04 May 2024 06:50:06 GMT

こんにちは TAG-さん!

https://github.com/w3ctag/design-reviews/issues

W3C Technical Architecture Group が保有する design-reviews というリポジトリでは、新しい仕様に対するレビューが GitHub Issue で行われています。

直近の Issue のすべてが「こんにちは TAG-さん! 」で始まっており、なぜ突然日本語が出てくるのか不思議に思ったので調査することにしました。

調査結果

この挨拶文は ISSUE TEMPLATE に含まれている。
W3C TAG では定期的に Face to Face Meeting を行っており、その開催地に合わせて挨拶文が変わる。
ただし厳密な運用はしておらず、「こんにちは TAG-さん!」は 2023 年 04 月に開催された東京での MTG に合わせたもの。

調査詳細

Issue template を確認する

全員同じ始まりということはおそらくテンプレートがそういう形式なのだろうということで、確認したところ、確かにテンプレートに「こんにちは TAG-さん! 」の文字列が含まれていました。

https://github.com/w3ctag/design-reviews/blob/main/.github/ISSUE_TEMPLATE/005-early-design-review.md?plain=1#L11

https://github.com/w3ctag/design-reviews/blob/main/.github/ISSUE_TEMPLATE/010-specification-review.md?plain=1#L11

https://github.com/w3ctag/design-reviews/blob/main/.github/ISSUE_TEMPLATE/020-dispute-escalation.md?plain=1#L10

ISSUE TEMPLATE は 3 種類あります。

template 名	内容
005-early-design-review	初期段階での方向性について考えやガイダンスを提供してほしい場合に使用
010-specification-review	現在取り組んでいる Web 技術の仕様についてレビューしてもらいたいの場合に使用
020-dispute-escalation-review	現在の論争について意見を求める場合に使用

Issue template の起源

https://github.com/w3ctag/design-reviews/commit/68a1436aa797b7b30002a5ec39f4ce1dfa451942

git blame すると、2019年05月23日にこのテンプレートが作成されたことがわかります。ここを確認すると、この時点で「こんにちはTAG!」（現在は「こんにちは TAG-さん!」）という文字列が含まれていることがわかりました。

作成された際のコミットメッセージは次のとおりであり、もともと「specification review」というテンプレートがどこか（メーリングリストとか？）にあったことが伺えます。

Create issue templates in the new format Make issue templates in the new format. Use the existing template as a “specification review” template, and create a somewhat different template for “dispute resolution”.

なお Issue Template をこのリポジトリに作成した人物は Google に勤めるエンジニアの L. David Baron さんです。

https://github.com/dbaron

もっと！Issue template の起源

現在の Issue Template はここまでしか辿れませんが、日付と過去に別のテンプレートがあった、という情報が手に入ったので、リポジトリ全体の History を参照してみました。

すると、2019年05月09日に ISSUE_TEMPLATE.md を変更しているコミットを発見。

https://github.com/w3ctag/design-reviews/commit/426a9a8b3fc6314deb9f44a60ade76d2edaca6fd

このファイルの履歴を辿ってみます。

https://github.com/w3ctag/design-reviews/commits/426a9a8b3fc6314deb9f44a60ade76d2edaca6fd/ISSUE_TEMPLATE.md

まず 2016年11月02日にテンプレートのファイルが作成されていました。

https://github.com/w3ctag/design-reviews/commit/9ed6f17be379a5d0d9397c5311ac9634fcab84d4

コミットメッセージには「F2Fからの Issue template。共同で構築。」と記載があります。

Issue template from F2F. Collaboratively constructed.

この「F2F」について検索してみると、どうも W3C が開催している「Face to Face」 Meeting のことを指しているようです。

TAG Meeting 2016@Tokyo

2016年11月02日あたりに開催された TAG の Meeting を検索してみると、どんぴしゃで2016/10/31 - 2016/11/02 @東京開催のMTGがあることがわかりました。

https://www.w3.org/events/happenings/2016/technical-architecture-group-tag-meeting-2/

Web サイトのリンクがあったので眺めてみる。どうも日経ビルでやっていたそうな。

https://github.com/w3ctag/meetings/tree/gh-pages/2016/11-tokyo

議事録があるようですが、どれも W3C TAG のトップページに飛んでしまい参照できませんでした。最新の MTG の議事録の格納場所に移動されていないかみてみたものの、最近では直接 GitHub に保存しているのでダメそうです。

これ以上は追えないものの、ここを起源にテンプレートが生まれたことがわかりました。

greeting の変遷

https://github.com/w3ctag/design-reviews/commit/6bd78d4e674e5428c32f914bec64739164ba7a54

テンプレートが作成されて以降、初めて挨拶部分が変更されたのがこのコミット。2017年07月にはたしかにロンドンで F2F MTG が開催されており、これに合わせて「Dear Sirs and Madam of TAG!」に変わっている。

テンプレートができた時から、初めて挨拶部分が変更されたときまでに、02-boston、04-tokyo の2回が開催されている。ボストンについてはアメリカなので変更の余地がありませんが、なぜ東京は変えなかったのか…（東京の時に Hello で作ったので、変えようと思わなかったのかも？）？

何はともあれ、2017年07月以降、その回の MTG の会期中に、次回の開催地の挨拶文に変わるという文化が始まったようです。

改めて「こんにちは TAG-さん!」を確認する

https://github.com/w3ctag/design-reviews/commit/d7015be036a57a19e9be170eeb914e425db9b65c

この変更が入ったのは、2023年02月13日。確かに2023年04月には東京で F2F MTG が開催されているものの、それ以降も MTG は開催されており、一方で挨拶文は変わっていない。

よくよくみてみると、必ずしも毎回挨拶文が変わっているわけでもなく、厳格な運用（挨拶文の変更に厳格な運用も何もないが…）はされていないようでした。

おわりに

あまり重要ではない情報の調査に時間を使ってしまったような気がしましたが、調査の過程で W3C TAG に少し詳しくなれたのでよかったです。

GraphQLの「Serving over HTTP」とは何か

ikuma-t — Fri, 03 May 2024 00:00:00 GMT

サマリ

モダンな Web アプリケーションフレームワークは、HTTPを用いてやり取りを行い、ミドルウェアを利用して認証やリクエストの検証、変換を行うパイプライン型のアーキテクチャを採用している
GraphQL においても、事前に認証・検証が行われた上でリクエストを処理するのがベストプラクティス
そのために、GraphQL のリクエストを REST のような形式でマッピングして処理する

Serving over HTTP

https://graphql.org/learn/serving-over-http

GraphQL サーバは GET と POST の 2 種類の HTTP リクエストをハンドリングできるようにします。

マッピングされるパラメータは次のとおりです。

パラメータ	意味	必須
query	クエリそのもの	必須
variables	クエリの変数	任意
operationName	クエリの名前。複数のオペレーションを同時に実行する場合には必須	任意

GET

GET リクエストでは、GraphQL Query が query というクエリパラメータにマッピングされます。

hero.graphql

query HeroQuery($id: ID!) {
  hero(id: $id) {
    name
  }
}

このクエリは、次のようにエンコードされます。

Terminal window

http://myapi.com/graphql?query=query($id: ID!){hero($id: ID!){name}}&operationName=HeroQuery&variables={"id":"avagfads732"}

POST

POST リクエストでは、application/json でリクエストを送信する。次の形式の JSON をボディとして送信されます。

{
  "query": "...",
  "variables": "updateHeroName",
  "operationName": { "id": "avagfads732", "name": "Andrew" }
}

レスポンス

レスポンスは JSON 形式で返される。GraphQL の仕様に則り、dataフィールドかerrorsフィールドが含まれます。

{
  "data": {
    "hero": {
      "name": "Andrew"
    }
  }
}

{
  "errors": [
    {
      "message": "Cannot query field 'hero' on type 'Query'",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ]
    }
  ]
}

[Draft] Transport Specification / GraphQL over HTTP

ここまでの内容が GraphQL 公式で公開されている内容で、ここから先はまだドラフト段階です。

仕様の定義場所

https://graphql.github.io/graphql-over-http/draft/

概要

GraphQL over HTTP は Serving over HTTP の仕様を拡張したもの。
HTTP サーバは 1 つ以上の URL を介して、GraphQL スキーマへのリクエストを受け付ける必要がある。
サーバおよびクライアントは、少なくとも JSON の形式でリクエストをサポートする必要がある。
レスポンスにおける Media Type は application/graphql-response+json が推奨。
サーバは POST リクエストに必ず対応する必要があり、そのほかの GET のようなメソッドも対応する可能性がある。
サーバはリクエストの処理の成功時にはその結果を、失敗時にはエラーを返す必要がある。

skim で移動/コマンド履歴検索をインタラクティブに行う

ikuma-t — Thu, 02 May 2024 11:34:51 GMT

モチベーション

新しく M3 Macbook Air を購入したので、これを機に色々とツールを乗り換えています。

Fuzzy Finder にはこれまで peco を使っていたのですが、全部 Rust 製に統一したいという思いがあり、skim に乗り換えました。

乗り換えたはいいのですが、キーバインドやコマンドの設定を怠っており活用できていなかったので、調べて設定してみた、というのがこの記事の内容です。

zoxide の絞り込みに skim を使う

https://github.com/ajeetdsouza/zoxide

zoxide には標準で zi というエイリアスが設定されており、これを使うことでインタラクティブにディレクトリを選択できます。しかし内部的には fzf が使われており、そのままだと fzf もインストールしなければなりません。

これを skim で使うための設定が以下の Issue で提案されていました。

https://github.com/ajeetdsouza/zoxide/issues/228

Terminal window

function __zoxide_zi() {
    \builtin local result
    result="$( \
        zoxide query -ls -- "$@" \
        | sk \
            --delimiter='[^\t\n ][\t\n ]+' \
            -n2.. \
            --no-sort \
            --keep-right \
            --height='40%' \
            --layout='reverse' \
            --exit-0 \
            --select-1 \
            --bind='ctrl-z:ignore' \
            --preview='\command -p ls -F --color=always {2..}' \
        ;
    )" \
        && __zoxide_cd "${result:7}"
}
zle -N __zoxide_zi
setopt noflowcontrol
bindkey '^z' __zoxide_zi

通常のシェルインテグレーションと同様に、__zoxide_zi 関数を定義し、zoxide query でディレクトリを取得し、sk で選択するようにしています。

https://github.com/ajeetdsouza/zoxide/blob/main/templates/zsh.txt#L69-L73

履歴検索を skim で行う

最適かは分かりませんが、履歴検索を skim で行う設定を以下のようにしました。

Terminal window

function hist() {
    BUFFER=$(history -n -r 1 | sk --query "$LBUFFER" --reverse)
    CURSOR=$#BUFFER
    zle reset-prompt
}
zle -N hist
bindkey '^r' hist

zle、bindkey is 何？

Zsh Line Editor の略で、Zsh のコマンドライン編集機能を提供します。ターミナル上の文字列やカーソル位置をシェルスクリプト上で操作するための機能のようです。

今回出てくる -N オプションは、新しく関数をバインドするためのオプションです。

-N new-keymap [ old-keymap ] Create a new keymap, named new-keymap. If a keymap already has that name, it is deleted. If an old-keymap name is given, the new keymap is initialized to be a duplicate of it, otherwise the new keymap will be empty.

bindkey は、キーバインドを設定するためのコマンドです。指定したキーに対して、指定した関数をバインドします。

https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html

参考

https://speakerdeck.com/naoya/sierunolu-li-toikunrimentarujian-suo-woshi-u

https://k-koh.hatenablog.com/entry/2020/10/24/160323

https://www.rasukarusan.com/entry/2020/04/19/193450

Astro で Warning ReactDOMServer.renderToStaticNodeStream() is deprecated. が出るようになった原因と対応

ikuma-t — Wed, 01 May 2024 00:00:00 GMT

Astro で突然非推奨の警告が出るようになった

このサイトは Astro で実装されており、一部コンポーネントに React を使用しています。ある日を境に、開発サーバの起動ログに以下のような警告が出るようになりました。

Terminal window

Warning: ReactDOMServer.renderToStaticNodeStream() is deprecated. Use ReactDOMServer.renderToPipeableStream() and wait to `pipe` until the `onAllReady` callback has been called instead.

メッセージで検索してみると、同様の Issue が GitHub に起票されており、対応の Pull Request もマージされていました。

https://github.com/withastro/astro/issues/10899

https://github.com/withastro/astro/pull/10893

2024/05/01 時点ではまだリリースされていませんが、数日以内にリリースされると思われるため、@astrojs/react のバージョンアップで修正されると考えられます。

2024/05/03 追記: 変更がリリースされ、警告が出なくなりました。 https://github.com/withastro/astro/blob/HEAD/packages/integrations/react/CHANGELOG.md#332

この記事ではそもそもなぜこの警告が出るようになったのかを調査しました。

前提

astro: 4.7.0
@astrojs/react 3.3.1
react 18.3.1
react-dom 18.3.1

どの箇所を起因として警告が出るようになったのか

https://github.com/withastro/astro/blob/c238aa81ee91ce85f40740234fe6878faa27dceb/packages/integrations/react/server.js#L153-L173

Astro の react インテグレーションで ReactDOM.renderToStaticNodeStream() が使用されている箇所がありました。

https://github.com/facebook/react/pull/28874

https://github.com/facebook/react/blob/main/CHANGELOG.md#react-dom

React 側では 2024/04/25 の 18.3.0 のリリースでこの警告を追加しています。

description を確認すると次の理由から非推奨に指定されたことがわかります。

This API has been legacy, is not widely used (renderToStaticMarkup is more common) and has semantically eqiuvalent implementations with renderToReadableStream and renderToPipeableStream.

ReactDOM.renderToStaticMarkup() がより一般的に使われている。
加えて ReactDOM.renderToReadableStream() と ReactDOM.renderToPipeableStream() が同等の実装を持っている。

ReactDOMServer.renderToStaticNodeStream() とは何か？

ReactDOMServer は、サーバ上で React コンポーネントをレンダリングするための API を指しており、具体的なパッケージは react-dom/server です。いわゆる Static-Site Generation や Server-Side Rendering と言われるような事前レンダリングに用いられます。

https://ja.react.dev/reference/react-dom/server

この API 群には動作環境とレンダリング結果の分類によっていくつかのメソッドが用意されているようです。

環境	メソッド	ストリーム	ハイドレーション
Node.js	`renderToPipeableStream`	可	可
Node.js	`renderToStaticNodeStream`	可	不可
Web Stream	`renderToReadableStream`	可	可
ストリームサポートなし	`renderToString`	不可	不可
ストリームサポートなし	`renderToStaticMarkup`	不可	不可

上記の表の繰り返しになりますが、renderToStaticNodeStream は Node.js 環境において、React コンポーネントをストリームとして出力するための API を指します。

React ではなぜ ReactDOMServer.renderToStaticNodeStream() が非推奨となったのか

ドキュメントを参照すると、注意点として以下の内容が記載されています。

renderToStaticNodeStream の出力はハイドレーションすることができません。 React 18 時点において、このメソッドはすべての出力をバッファリングするため、実際にはストリームを使用する利点が得られません。

この特徴を踏まえると、renderToStaticNodeStream は実際にはストリームとしての利点を享受できないため、ケースによって既存のメソッドに置き換えることができそうです。

ハイドレーションが不要で、ストリームも不要な場合：renderToStaticMarkup
ハイドレーションが必要で、ストリームも必要な場合：renderToPipeableStream（Node.js環境）、renderToReadableStream（Web Stream）

ユースケースをカバーできる他の API があるので、renderToStaticNodeStream は非推奨となったと考えられます。

補足: Astro における対応

if ("renderToReadableStream" in ReactDOM) {
  html = await renderToReadableStreamAsync(vnode, renderOptions);
} else {
  html = await renderToPipeableStreamAsync(vnode, renderOptions);
}

Astro では、環境に応じて renderToReadableStream か renderToPipeableStream を使うようになっていました。

参考

https://www.reddit.com/r/astrojs/comments/1cdbito/libsupabase_error_v46_and_v47_warning/?onetap_auto=true&one_tap=true&rdt=62227

Go におけるツールの依存関係を追跡できるようにする

ikuma-t — Tue, 30 Apr 2024 13:28:33 GMT

解決したい課題

gqlgen のように、ツールとしては確かにプロジェクトで使用しているけれども、アプリケーションのコードベースに出てこないパッケージを利用するケースがあります。

このようなツールは go mod tidy を実行した際に、import されていないため、module が消えてしまいます。

解決策

tools.go ファイルを作成し、そこで依存関係を追跡するツールをインポートすることで、Go におけるツールの依存関係を追跡できるようにします。具体的には以下のような tools.go を作成します。

//go:build tools
// +build tools

package tools

import (
    _ "github.com/99designs/gqlgen"
    _ "github.com/99designs/gqlgen/graphql/introspection"
)

このファイルで import が実行されているため、go mod tidy を実行してもツールの依存関係が消えることはありません。また //go:build tools を記載することで、このファイルは go build などのビルド時には無視されるようになります。

// +build tools は、このファイルが tools というビルドタグを持つことを示しています。

参考

https://go.dev/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

GitHub Issue から Markdown ファイルを生成してブログ記事を公開する

ikuma-t — Sun, 28 Apr 2024 08:27:11 GMT

モチベーション

このブログは Astro を用いて実装されており、記事は Markdown ファイルとして管理されています。基本的に PC で作業しているのでこの形式でも問題はないのですが、たまにスマホから記事を書きたいと思うことがあります。

しかしながら記事は GitHub 上の Markdown ファイルとして管理されているため、スマホで書くにはやや面倒です。特に YAML フロントマターは PC 上では VSCode のスニペットにより簡単に挿入できるのですが、スマートフォンではそうもいきません。

GitHub Issue から Markdown ファイルを生成する

そこで、GitHub Issue から Markdown ファイルを生成する方法を考えました。

Markdown で管理することを前提として、スマホでも書きやすくするための選択肢としては次のようなものが考えられます。

GitHub Issue から Markdown ファイルを生成する
CodeSpaces を利用して、ブラウザ上で記事を編集する
記事作成用の Web アプリを作成する

今回はお手軽に実施したかったことと、CodeSpaces をスマホで触るのは体験としてやや無理がったので、GitHub Issue から Markdown ファイルを生成する方法を選択しました。

実装

全体の構成

GitHub Issue を作成する（Issue テンプレートとして、ブログのテンプレを用意しておく）
GitHub Actions でラベルが付与されたことをトリガーに GitHub Actions を実行する
1. ラベルを検知し、publish が付与されていれば後続の処理を実行する
2. Issue の内容から Markdown ファイルを生成する
3. Issue の内容を元に Markdown ファイルを生成し、新たにブランチを作成する
4. プルリクエストを作成する
5. 対象となった Issue にプルリクエストを紐付け、Issue を Close する
Cloudflare Pages　のプレビューが走るため、プレビューする
問題なければマージし、記事が公開される

GitHub Actions のワークフロー

GitHub Actions のワークフローは次のようになります。

name: publish content from GitHub Issue

on:
  issues:
    types: [labeled]
  workflow_dispatch:

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check issue labels
        if: contains(github.event.issue.labels.*.name, 'publish') != true
        run: exit 0
      - name: Define title
        id: define_title
        run: |
          title=$(echo "${{ github.event.issue.title }}" | sed -r 's/([a-z0-9])([A-Z])/\1-\2/g; s/ /-/g' | tr '[A-Z]' '[a-z]')
          echo "title=$title" >> $GITHUB_OUTPUT
      - name: Create Content File
        run: |
          echo -e "${{ github.event.issue.body }}" | sed -e "s/publishDate:/publishDate: $(TZ=-9 date -Iseconds)/" | sed -e "s/modDatetime:/modDatetime: $(TZ=-9 date -Iseconds)/" >> src/content/blog/${{ steps.define_title.outputs.title }}.md
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Commit Content File
        uses: EndBug/add-and-commit@v9
        with:
          new_branch: ${{ steps.define_title.outputs.title }}
      - name: Create PullRequest
        run: gh pr create --title "${{ github.event.issue.title }}" --body "#${{ github.event.issue.number}}" --base main --head ${{ steps.define_title.outputs.title }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Close Issue
        run: gh issue close ${{ github.event.issue.number }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Issue テンプレート

Issue を起点に作成するので、テンプレートも用意しておきます。

---
name: blog
about: create blog draft
title: ""
labels: ""
assignees: ""
---

## <!-- Issueタイトルはslugとして使用。時刻は埋めなくて良い -->

author: ikuma-t
publishDate:
modDatetime:
title:
featured: false
draft: false
tags:

- description:

---

##

Issue テンプレート自体の YAML フロントマターと衝突するため、やむを得ず一行コメントを挟んでいます。

ショートカットの追加

MacroDroid を使って、メニュー部分に「ブログを追加」ボタンを設置します。

Issue Template はクエリパラメータで設定できるので、その URL を登録しておきます。

GitHub Mobile がインストール済みであれば、ブラウザではなくこちらで Issue を作成することができます。

Web 版よりも Markdown エディタが使いやすく便利です。

おわりに

GitHub Issue から Markdown ファイルを生成する方法を紹介しました。

画像の挿入には対応していないものの、比較的お気軽に記事を投稿できるようになり満足です。

このブログのパッケージマネージャを pnpm に変更した

ikuma-t — Sat, 27 Apr 2024 07:35:32 GMT

pnpm へ移行

もともとこのブログのリポジトリでは npm を使っていましたが、他の箇所では pnpm や bun を使っていることもあり、速度に不満があったため pnpm に移行しました。

移行手順

pnpm のインストール

Terminal window

npm install -g pnpm

既存の node_modules の削除

Terminal window

rm -rf node_modules

package-lock.json の削除

Terminal window

rm package-lock.json

package のインストール

Terminal window

pnpm install

補足： pnpm コマンドのみを許可する

package.json に以下の設定を追加することで、npm や yarn コマンドを使わないようにできます。

{
  "scripts": {
    "preinstall": "npx only-allow pnpm"
  }
}

なお only-allow は特定のパッケージマネージャのみを許可するパッケージです。

実際のところ、コマンド実行時は azu/ni.zsh: Alternative `ni` written in zsh: npm/yarn/pnpm/bun with the same command を使用しているので間違えることもないですが…。

VSCode Conference Japan 2024 で登壇しました！

ikuma-t — Mon, 22 Apr 2024 13:38:00 GMT

VSCode Conference Japan 2024 で登壇しました！

先日 4/20 に開催された VSCode Conference Japan 2024 に登壇してきました！

VSCode Conference Japan のアーカイブ動画を拝見したことがあったのですが、参加するのははじめてでした。

自分の登壇内容

登壇資料・登壇動画

動画のアーカイブもあります。

モチベーション

RubyMine入門や Code Tour を使ってじっくり確実にコードを読む、Railsアプリをコスパよく読むための環境整備などなど、エディタ関連のアウトプットはあれど、カンファレンスには登壇したことないなあと思っていたので、今回の機会に登壇してみようと思いました。

プロポーザルは結構難産なことが多いのですが、ツール系は自分の趣味分野ということもあり、割とあっさりとテーマを決めることができました。

話せることが結構あるからあっさりテーマが決まったわけですが、登壇時間 15 分に対して、スライド 59 枚は多かったなあと反省しています。

発表の構成

そのまま並べても資料としては成立するだけのボリュームだったのですが、そうすると Tips 集になってしまって話を聞かなくてもいいかなと思いそう…と感じ、冒頭に「なぜ見た目から始めるのか」という Why からはいる形式に。

内容は普段業務でもやっている小さな改善系において考えていることの流用ですが、この進め方にしてみたところ扱う Tips の取捨選択がうまくできてよかったです。

感想

懇親会や X でも「参考になった」と言っていただけてとても嬉しかったです！

これまで自分の手元に溜め込んでいた「すぐアウトプットできるけど、1つ1つは記事にするほどでもない」ネタたちを一気に放出できてスッキリしました！

Biomeに寄付をすることにした

https://twitter.com/unvalley_/status/1781603651288809515

同じく登壇されていた unvalley さんの登壇内容がとても印象的でした。

資料内で引用されていた資料も併せて貼っておきます。

https://erika.florist/articles/dontunderestimateeditorintegration/

Biome 自体は新規で小さなツールを書く際に利用していたのですが、これを機にこのサイトでも Biome を利用するようにし、また Open Collective 経由で Biome への寄付を始めました。

https://opencollective.com/biome

とりあえず $5 ずつ月額寄付をしていますが、これからも継続していきたいと思います（給料上がったらもう少し増やす）。

おわりに

最近ソフトウェアアーキテクチャの基礎を読んでから、技術に触れる時に Technology Radar の 4 象限を意識するようになりました。前々から薄々気がついていたのですが、自分はかなりツールに傾倒する傾向があり、時間の使い方的にどうなんだと思っています。趣味という点ではいいんですけどね。

なので今回ツール系のネタを放出できたのを一つの区切りにして、今後、最低でも半年はツール系のネタは封印してやっていこうと思っています。

区切りをつけようと思えたのは、年に一度の VSCode のお祭りで登壇できたから & 楽しかったからこそです。運営の皆様、ありがとうございました！

現在のディレクトリから新しいリポジトリを作成する

ikuma-t — Mon, 11 Mar 2024 12:00:19 GMT

何度やっても忘れるのでメモ。

private repository

Terminal window

gh repo create --private  $(basename $(pwd)) --push -s .

public repository

Terminal window

gh repo create --public $(basename $(pwd)) --push -s .

学習用のリポジトリを作成するときに便利。

ミスドのネット予約を使うと、チョコファッションのチョコを全体にかけられる

ikuma-t — Sun, 10 Mar 2024 11:43:45 GMT

この前初めてミスタードーナツを予約してみた際、「事前予約専用ドーナツ」なるものがあることを知りました。

https://www.misterdonut.jp/m_menu/new/240207_net_order/

自分はミスドで何かを買う時、オールドファッション系のドーナツを頼むことが多いです（お腹に溜まるから）。当然チョコファッションも購入するのですが、景気とともにチョコの量がどんどん減ってきている気がしており、毎回ちょっぴりしょぼんとしていました。

https://www.misterdonut.jp/m_menu/donut/net_order24_01.html

今回見つけた予約専用の「たっぷりチョコファッション」は、表面前面にチョコがかかっているというもの。注文の手間はかかりますが、通常のチョコファッションに 10円上乗せするだけで、チョコを3倍楽しめます。

特にオチはないです。

Code Tour を使ってじっくり確実にコードを読む

ikuma-t — Sun, 10 Mar 2024 10:28:45 GMT

Code Tour を使ってじっくり確実にコードを読む

日々のタスクに忙殺されていると、ついつい既存コードを流し読みして、ざっと動くコードを書いてしまいたくなります。一発でうまく動けば短期的にはいいのですが、長期的にはコードの理解が追いつかなったり、一発でうまく動かなかった場合にかえって時間がかかってしまいます。

VSCode の拡張機能である Code Tour を使うと、コード上にメモを残しながら読み進めることができるので、既存のコードを読む際に便利です。

Code Tour とは

https://marketplace.visualstudio.com/items?itemName=vsls-contrib.codetour

VSCode の拡張機能で、コード上にメモを残しつつ、そのメモをたどることができるツールです。

使い方

ツアーを始める

コマンドパレットから「Code Tour: Record Tour」を選択すると、ツアーの記録モードになります。

ツアーの名前
どのソースに紐づけるか（紐付けなし、ブランチ、タグ）

を選択すると、リポジトリ直下に .tours/${指定したツアー名}.tour というファイルが作成され、ツアーの記録が開始されます。

メモを残す

ツアー記録モードだと、エディタの行番号横に「+」ボタンが表示されます。単一行または複数行を指定することで、その行にメモを残すことができます。メモには、Markdown が使えるので、コードの説明や、参考リンクなどを記述することができます。

シンタックスハイライトも適用されるので、「自分の見慣れない文法だったので、小さいサンプルとともにメモしておきたい」「ライブラリの実装を読んだので、関連部分にメモしておきたい」などの場合にも便利です。

ツアーの記録を終了する

コマンドパレットから「Code Tour: End Tour」を選択すると、ツアーの記録が終了します。

ツアーを再生する

コマンドパレットから「Code Tour: Start Tour」を選択すると、ツアーの再生モードになります。

各ツアーのメモにはページ送りボタンがあるので、これを利用して前後のツアーに移動することができます。

なお画像中の Insert: Code はコードブロックがある場合に表示されるもので、これを押すと、そのコードブロックがエディタに挿入されます。

ユースケース

開発中のサービスの特定機能の概観を理解したい

サービスの機能の振る舞いは知っているけど、実際のコードとしてはどういう構成になっているのか実は把握できていない、というケースで Code Tour を利用しています。

読み方は掲載した図の通りで、

エントリポイント（UI、ジョブ、CLI…）にメモする
機能のアウトプットを行って箇所（レスポンスを出力しているところ、帳票やログ出力）にメモする
どういうデータ構造で保存しているかメモする
外界からの入力をどう受け取っているのかメモする
ビジネスロジックをどう実装しているかメモする

といった感じです。

ビジネスロジックの部分は複雑になりがちなので、設計によってはいくつかのファイルに散らばることもありますが、これによりそれぞれのファイルにメモを取るとどうしてもメモが多くなってきたり、Tour も行ったりきたりになってしまいます。

そのためコアのファイル以外は精読せずに、ざっくりとインターフェースからこんなことをやってくれそう、という内容をコアファイルのメモとして取るようにしています。

反対にコアとなるファイルはちょっとした文法でもわからないところがあると、全体像がボヤけるので全力で調べてメモを残しています。

特定のライブラリに依存した機能を理解したい

ここでいうライブラリとは管理機能やドキュメント生成ライブラリなど、土台となるフレームワーク（React、Next.js、Rails、Spring Boot など）の上に乗り、特定の機能群を実現するライブラリを意図しています。

例えば管理機能を作る場合に React Admin を使っていたりすると、React は知っていても、React Admin がいい感じに隠蔽しているので、どうやって書けば良いかスッとは出てこない、というケースがあります。その際には Code Tour を使って公式ドキュメントと実際のコードを読んでいます。

管理機能系であれば、通常のコードと別ディレクトリ（例： app/admin）に分かれていることが多いので、ツアーを始める際にはディレクトリをエントリポイントにします。

ディレクトリを指定して「Add Code Tour Step」を選択することで、ディレクトリに対してメモを取ることができるので、最初に公式ドキュメントや全体像をメモするようにしています。

ディレクトリのツアーに対しても、仮装のファイルが開き、通常のソースファイルと同様にメモを確認することができます。

ディレクトリ内に置かれているファイル数にもよりますが、なんとなく頭の中に知り合いを増やしてからドキュメントを読んだほうが個人的には馴染みが良いです。

そのためざっとすべてのファイルに目を通しつつ、よくわからないDSL的なものが出てくれば「なんだこれ？」とだけメモし、あとはドキュメントに書いてある内容や実際に動かした挙動で随時編集しています。

おわりに

以前はコードを読む際にソースコードのURLとメモをマークダウンファイルに残していましたが、Code Tour を使うようになってからはソースコードとメモが一体化しているので、読み進める際にスムーズになりました。

私は .tours ディレクトリをグローバルに ignore しているのでチームには共有していませんが、Gist経由で記録したツアーを共有することもできるので、チームでのコードリーディングにも使えるでしょう。

Code Tour で素敵なコードリーディングライフを！

個人ブログを再度Astroで作りました

ikuma-t — Sun, 10 Mar 2024 00:00:00 GMT

個人ブログを再度Astroで作りました

Remixで作っていたのですが、雑に作ったせいかときどきクラッシュするので、またまたAstroで作りました。今回は制作時間をかけないように AstroPaperというテンプレートを使いました。

WhichKeyでVSCodeのショートカットをすいすい叩けるようにする

ikuma-t — Sat, 06 Jan 2024 00:00:00 GMT

はじめに

VSCode を利用し始めてかれこれ1年くらい経ちますが、基本的なものを除いていまいちショートカットが覚えられません。

JetBrains 系のエディタのプラグインにある Key Promoter X の VSCode 版を導入してみたのですが、結局正しいキーはなんなのかがわからずうまくいきませんでした。

これに対し、 Which Key という拡張機能を使うことでショートカットを覚えずに、ショートカットを活用できるようになったので紹介します。

WhichKey とは

WhichKey は　VSpaceCode という Spacemacs ライクなキーバインドを実現する拡張機能が提供している拡張機能です。

キーバインドに対応したコマンドパレット / チートシート機能を提供します。もともと Emacs に搭載されている機能を VSCode の拡張機能として実装したもののようです。

インストールと初期設定

VSpaceCodle をインストールしても Which Key は導入されますが、 Whichey 単独でもインストールすることができます。

https://marketplace.visualstudio.com/items?itemName=VSpaceCode.whichkey

私の場合は VSCode NeoVim を利用しているので、以下のようなキー設定を追加して、 cmd + space で Whichkey が起動するようにしています（alt + space は Raycast ですでに使っていた）。

{
  "key": "alt+space",
  "command": "whichkey.show",
  "when": "editorTextFocus"
},

メニューのカスタマイズ

表示されるメニューは settings.json で編集することができます。

1つのキーに対して1つのアクションを指定する場合は以下のように設定します。

"whichkey.bindings": [
  {
    "key": "バインドしたいショートカットキー",
      "name": "任意の名前。メニューで表示される",
      "type": "command",
      "command": "VSCodeのコマンドの名前"
  }
]

またショートカットキーをネストさせることもできます。その場合は次のように設定します。

"whichkey.bindings": [
  {
    "key": "バインドしたいショートカットキー",
      "name": "任意の名前。メニューで表示される",
      "type": "bindings",
      "bindings": [
      // ...以下単一のアクションを設定する場合と同じシンタックス
      ]
  }
]

WhichKey 自体の設定

WhichKey 自体の挙動を settings.json に指定できます。冒頭の初期設定で述べた、 whichkey.show もその一例で、すでに説明した通り WhichKey を起動するためのコマンドです。

その他の細かな設定については Reference | VSpaceCode をご参照ください。

わたしの Which Key

こんな感じの key bindings を設定しています。

  "whichkey.bindings": [
    {
      "key": "q",
      "name": "Quit",
      "type": "command",
      "command": "workbench.action.closeActiveEditor"
    },
    {
      "key": ";",
      "name": "commands",
      "type": "command",
      "command": "workbench.action.showCommands"
    },
    {
      "key": "a",
      "name": "Toggle Sidebar",
      "type": "command",
      "command": "workbench.action.toggleSidebarVisibility"
    },
    {
      "key": "e",
      "name": "Editors...",
      "type": "bindings",
      "bindings": [
        {
          "key": "d",
          "name": "Close active editor",
          "type": "command",
          "command": "workbench.action.closeActiveEditor"
        },
        {
          "key": "e",
          "name": "Show all editors",
          "type": "command",
          "command": "workbench.action.showAllEditors"
        },
        {
          "key": "f",
          "name": "Focus active editor",
          "type": "command",
          "command": "workbench.action.focusActiveEditorGroup"
        },
        {
          "key": "m",
          "name": "Close other editors",
          "type": "command",
          "command": "workbench.action.closeOtherEditors"
        },
        {
          "key": "n",
          "name": "Next editor",
          "type": "command",
          "command": "workbench.action.nextEditor"
        },
        {
          "key": "p",
          "name": "Previous editor",
          "type": "command",
          "command": "workbench.action.previousEditor"
        },
        {
          "key": "u",
          "name": "Reopen closed editor",
          "type": "command",
          "command": "workbench.action.reopenClosedEditor"
        },
      ]
    },
    {
      "key": "f",
      "name": "Find & Replace...",
      "type": "bindings",
      "bindings": [
        {
          "key": "f",
          "name": "File",
          "type": "command",
          "command": "editor.action.startFindReplaceAction"
        },
        {
          "key": "p",
          "name": "Project",
          "type": "command",
          "command": "workbench.action.replaceInFiles"
        }
      ]
    },
    {
      "key": "g",
      "name": "Git",
      "type": "command",
      "command": "workbench.view.scm"
    },
    {
      "key": "h",
      "name": "Split Horizontal",
      "type": "command",
      "command": "workbench.action.splitEditorDown"
    },
    {
      "key": "m",
      "name": "Toggle Minimap",
      "type": "command",
      "command": "editor.action.toggleMinimap"
    },
    {
      "key": "o",
      "name": "Open File",
      "type": "command",
      "command": "workbench.action.quickOpen"
    },
    {
      "key": "s",
      "name": "Show search",
      "type": "command",
      "command": "workbench.view.search"
    },
    {
      "key": "x",
      "name": "Show explorer",
      "type": "command",
      "command": "workbench.view.explorer"
    },
    {
      "key": "t",
      "name": "Terminal...",
      "type": "bindings",
      "bindings": [
        {
          "key": "t",
          "name": "Toggle Terminal",
          "type": "command",
          "command": "workbench.action.togglePanel"
        },
        {
          "key": "f",
          "name": "Focus Terminal",
          "type": "command",
          "command": "workbench.action.terminal.toggleTerminal",
          "when": "!terminalFocus"
        }
      ]
    },
    {
      "key": "v",
      "name": "Split Vertical",
      "type": "command",
      "command": "workbench.action.splitEditor"
    },
    {
      "key": "w",
      "name": "Window...",
      "type": "bindings",
      "bindings": [
        {
          "key": "h",
          "name": "Move editor group left",
          "type": "command",
          "command": "workbench.action.moveActiveEditorGroupLeft"
        },
        {
          "key": "j",
          "name": "Move editor group down",
          "type": "command",
          "command": "workbench.action.moveActiveEditorGroupDown"
        },
        {
          "key": "k",
          "name": "Move editor group up",
          "type": "command",
          "command": "workbench.action.moveActiveEditorGroupUp"
        },
        {
          "key": "l",
          "name": "Move editor group right",
          "type": "command",
          "command": "workbench.action.moveActiveEditorGroupRight"
        },
        {
          "key": "t",
          "name": "Toggle editor group sizes",
          "type": "command",
          "command": "workbench.action.toggleEditorWidths"
        },
        {
          "key": "m",
          "name": "Maximize editor group",
          "type": "command",
          "command": "workbench.action.minimizeOtherEditors"
        },
        {
          "key": "d",
          "name": "Close editor group",
          "type": "command",
          "command": "workbench.action.closeEditorsInGroup"
        },
        {
          "key": "x",
          "name": "Close all editor groups",
          "type": "command",
          "command": "workbench.action.closeAllGroups"
        }
      ]
    },
    {
      "key": "z",
      "name": "Toggle Mode...",
      "type": "bindings",
      "bindings": [
        {
          "key": "f",
          "name": "Toggle full screen mode",
          "type": "command",
          "command": "workbench.action.toggleFullScreen"
        },
        {
          "key": "z",
          "name": "Toggle zen mode",
          "type": "command",
          "command": "workbench.action.toggleZenMode"
        }
      ]
    },
  ],

おわりに

WhichKey は見た目もスッキリしているし、ショートカットを忘れずに済むのでおすすめです。ぜひ使ってみてください。

1年の目標は正月に1回失敗しておくくらいがちょうどよい

ikuma-t — Fri, 05 Jan 2024 02:22:00 GMT

1年の目標は正月に1回失敗しておくくらいがちょうどよい

タイトルは今年立てた「日記を毎日書くぞ」が昨日途絶えてしまった自分への言い訳でもあり、毎年考えているものでもある。

あまり深く考えずに立てると、今年の目標は「毎日/毎週/毎月 XXするぞ！」といった類の内容になりがちだが、日本のカレンダー構造的に序盤戦がハードであるため、達成が難しい。

1月。目標立て始めでモチベは高いものの、休み中に目標達成のために作った環境やルーティンが、仕事の始まりと共に崩壊しがち。

2月。そもそも月数が他の月に比べて不利。週に2本はブログ書くぞ！といった目標はこのステージによって破られた。

3月。4月始まりの会社の場合、締めがここになるのでなんやかんや忙しい。

これらのステージのいずれかで連続ストリークが途絶えると、敗戦ムードとなり目標は自然消滅する。どうせ負け戦になって中途半端に終わるくらいなら、正月早々に負けておいて、次の負けムードのときに「1回負けたけど、まだ持ち直せるよ〜」という心持ちで年末を迎えた方が得策ではないか。

というわけで今日は忘れずに日記を書きました。えらいぞ🤗

Kaigi on Rails 2023で登壇しました！

ikuma-t — Sun, 29 Oct 2023 08:44:00 GMT

Kaigi on Rails 2023 で登壇しました！

昨日、一昨日（2023/10/27 - 28）で開催された Kaigi on Rails 2023 にSpeakerとして登壇してきました！

今年は初のオフライン開催。私自身Rubyコミュニティのオフラインイベントに参加するのが初めてだったコトと、カンファレンスでのオフライン登壇自体も初めてだったので（今年はスクラムフェス仙台でも登壇したけど、あれはサテライト配信だったので目の前に観客がいなかった）いろんな刺激を受けることができました。

この記事では参加者・登壇者それぞれの視点で今回のKaigi on Railsで感じたことを振り返っていきたいと思います。

これが「オフライン」…！

初オフライン Kaigi on Rails めちゃめちゃ楽しかったです！発表があって、ブースがあって…という構成は変わらないものの、やっぱり受ける刺激の量は全く異なり、来てよかったなあと感じました。これが「オフライン」…！

オフラインしぐさ

「懇親会の開始前に前説でパックマンルールを説明しよう」「2人で会話している人を見かけたら話しかける狙い目。2人だと話題を繰り出し続けるのも大変だし、会話抜けるタイミングも計れないしで困っているはず」みたいなオフライン懇親会仕草を徐々に取り戻していきたい。失われた技術。
— Takafumi ONAKA (@onk) July 24, 2023

前述の通りオフラインイベント慣れしていなかったので、懇親会やブースではonkさんのツイートに記載のあったロストテクノロジー¹をふと思い出し。自分は積極的に話しかけるのが苦手なので、会場うろちょろして2人でお話している方々を見つけては「話している人が2人…来るぞikuma！」²と心の中で叫んでいました。

一応自分のアイコンを含めたポストカードを前日にデザインして持って行きましたが、アイコンによってオンラインの姿と同期ができたのは一定効果があったようです。XのQRコードもつけたのですが、URLが間違っていたらしくこちらは全然意味をなさず…。来月もオフライン登壇の機会があるので、おとなしくプレーリーカードを作成しようと思います。

オンラインで知っている方/知らなかった人とお話しさせていただくことができて、嬉しかったです！お話しいただいたみなさん、ありがとうございました！

冷めても美味しいお弁当よりも、今ここでしか味わえない味を

登壇者的には「もっと現地を重視した構成にすればよかったなあ」と反省もありました。

エンジニアになってからの登壇はすべてオンライン配信だったため、いずれも意識的にオンライン向けに特化させた形になっていました。

リアルタイムでの反応が弱めなら、終わった後の体験の方に力を入れよう、具体的には後から見た時にも資料からおおよそのコンテキストが汲み取れる状態にする、といった具合です。お弁当用にちょっとおかずの味を濃いめにするみたいな気持ちです。

当たり前ですがオフラインの場合はすぐそこに聞いている人がいます。次回以降の登壇では以下のようなポイントを意識したいなあと、他の方の発表を見ている中で思いました。

全編とまでは言わないが、心に残すためのインタラクションを
丁寧に構成された緻密なロジックよりも、その瞬間で理解できる単純なサンプルを
完全な解説よりも、考える余地というギフトを

ただ後から見返すための資料はそれはそれでメリットがあるので、そこはバランスですかね〜（2種類作るか）。

なんだか強くなった気がする！

今年は最初に自分の番を終えることができたので³、常にHall A/Bいずれかのセッションを聞かせていただいておりました。

Kaigi on Railsのコンセプトに「明日からの仕事に使える」がありますが、前回の参加時（エンジニア経験4ヶ月）に比べ、「仕事」も増えたことから「わかりみ」と「やらねば」のオンパレードでした。最近Railsも書いていなかったのですが、発表を聞いていく中で自分の中で眠っているRails筋が活動を再開する音が聞こえたような気もします（それは本当か？）。

ところで結構AI生成のイラストを使っているスライドが多く見受けられた印象が合って、逆張り系人材としては来年までに油絵や水彩画を学習して、オリジナリティを確保しようかなと思っています、たぶん。

自分の発表のふりかえり

昨年に続き、独自系・網羅系でいくと後者の分類のトークでした。HTTPを手で書いて学ぶファイルアップロードのしくみ - ikuma-t.com。

発表のモチベーション

そもそも今年Kaigi on RailsにCFPを出すのか、そもそも行くのか迷っていました。

昨年の6月にエンジニアになってから仕事では

昨年のKaigi on Railsまで：Rails
今年のKaigi on Railsまで：React（+ときどきGo）
今年のKaigi on Railsから：Rails

と、1年近くフロントに傾倒していたので、今年はパスかな〜と思っていたのですが、社内でRailsを書いていたhoguccさんとsanfrecce_osakaさんがCFPを出す雰囲気を感じたので、その勢いに便乗して書くことに。

結果CFPは通って登壇できたし、偶然またRails書くことになったしで、やってよかったです。

登壇テーマ

上述の通り、Railsをテーマにして話すのはちょっと無理があったので、今回も昨年同様「曖昧に使っている技術を最小実装で自分のものにしよう」という方向性で検討。資料中にもあったようないくつかのファイルアップロードに関する経験から、今回はHTTPを手で書いてファイルアップロードの基本を理解する、というテーマにしました。

「この技術は課題に対してオーバーキルではないか？」という疑念がいつもあり、そういう視点でちょいちょい仕様とかを調べたりしたものがCFPのタネになっているのですが、いかんせんまとめていないので、CFPを書く際も、実際に資料を作る際にも時間がかかる…。生活をリリースして登壇をアドバンス召喚するのはなかなか大変なので、よくアウトプットをされている方たちを真似て⁴これ登壇できるかもと思ったら、ストックするようにしたいなとあらためて思いました。

登壇資料

「フロントでは頑張ってたんだよ〜」という免罪符が欲しかったのか、発表資料はHTML + CSS + JSで書いていて、（ほぼ出番のなかった）資料埋め込みデモはReact + Ruby Wasmでできていたりします。ここは長いので気が向いたら別記事で書こうと思います。

「ファイルアップロード」が一般的で広いテーマゆえ、今回は昨年よりも内容の取捨選択が難しかったです。

HTTPの仕様改訂やら、もう少し実世界と繋げた説明やら、JSにおけるBlobとか、もともと入っていたが消えた内容も…。加えて練習時間があまり取れなかったこともあり、半分ぶっつけ本番・超早口で30分に無理やりねじ込む内容になってしまいました…。これは次回以降の反省点です。

Grow.rbに今年も感謝

Grow.rb特別回：登壇相談会2023【登壇ビギナー歓迎】

チーフオーガナイザーの大倉さんが開催されているGrow.rbでは、Kaigi on RailsのCFP提出が解禁されると登壇特別回と称したCFP相談会⁵が開かれています。

昨年に引き続き今年もこちらで壁打ちをさせていただいたおかげで、CFPをブラッシュアップできました。大倉さん、アドバイスいただいた皆さん、ありがとうございました！

おわりに

あまりコミュニケーションが得意な人間ではないので、「勉強会やイベントには登壇者として参加することで、謎の免罪符を得る」戦略をFJORD BOOT CAMP時代からやっているのですが⁶、この戦略に頼りすぎて、免罪符なしで存在を保つことができるのか不安です。…ってことは存在を保つために、来年もKaigi on RailsのCFP出すしかないな！！

ブログを書いたし、アンケートも全部答えたのでこれにて私のKaigi on Rails 2023は終了です！運営の皆様、お疲れ様でした！

Footnotes

ロストテクノロジー - Wikipedia 現存しない技術というよりかは取り戻すべき技術 ↩
レベル4のモンスターが2体…来るぞ遊馬！ ↩
昨年は Day2の最後だったので、最後までそわそわ ↩
例えばkoicさんはBasecampで書いているそう。またonkさんは社内のscrapboxにLTネタを貯めているそう。 ↩
私の中での通称は「大倉塾」 ↩
謎の免罪符とかは言及されていないが、初心者でも登壇してみるのは話しやすくなるしおすすめ、ということは言われていたと思う、たぶん。 ↩

.env.developmentからdirenvで読み込む用の.envrcを作成するワンライナー

ikuma-t — Sun, 15 Oct 2023 00:00:00 GMT

ベースとなる環境変数ファイルから、direnv用のファイルを一発で作りたい

環境変数のベースとなるファイルを.env.developmentやらで作成しておき、実際の値は.gitignoreに記載された.envなどのファイルを各開発者のローカルで編集する、といった運用はよくある。

プロジェクトだけで使う環境変数をグローバルにexportするのもアレなので、こういった時にはdirenvが使える。しかし

.env.developmentはHOGE=foo形式で記述されている
.envrc（direnvの読み込みファイル）はexport HOGE=fooで記述する

という時に、単純にcp .env.development .envrcとするだけでは動かない。

とはいえ全部に手でexportをつけるのもだるいのでワンライナーだとどうやるのか少しばかり試行錯誤してみた。

結論

Terminal window

awk '{if (NF > 0 && $0 !~ /^#/) print "export " $0; else print $0}' .env.development > .envrc

解説

解説というほどの大きなスクリプトでもないが、小さな心配りを説明する。

NF > 0: Number of fieldsが0より大きい、つまり非空行のみを対象にする。環境変数のグループを明示的にするために空行があったりする場合にexportだけが残らないようにする心配り。
$0 !~ /^#/: #から始まらない、つまりコメント行でない行を対象にする。

Terminal window

HOGE=foo
FUGA=bar

# animals
TAMA=cat
POCHI=dog

例えば上記の.env.developmentから次の.envrcが生成される。

Terminal window

export HOGE=foo
export FUGA=bar

# animals
export TAMA=cat
export POCHI=dog

O'REILLYのLearning PlatformにLLMを使った質問機能が追加されていた（Beta）

ikuma-t — Sat, 14 Oct 2023 00:00:00 GMT

O’REILLYの書籍読み放題のサブスクリプションLearning Platformを開いたら、サイドバーに「Ask a question」というメニューが追加されていました。

近頃ではこの形式のUIを見ると「AIか〜」と当たり前のように納得するようになってきましたね。最初は現在開いている書籍に関して問い合わせできるのかと思ったのですが、そうではなくLearing Platformに登録されている書籍から回答を生成しているようです。

日本語書籍も登録はされていて回答の参考にされていましたが、日本語で質問しても回答自体は英語で返ってくる模様。

1つのトピックに対して複数の書籍をあたりたいケース、例えばプロダクト開発や開発プロセスに関する書籍を探す際には、この機能をきっかけに書籍を見つけるのもありかな〜と思いました。

dockerのimageとvolumeを選択して消せるか、賑やかしができるdockern（どっかーん）コマンド

ikuma-t — Sat, 14 Oct 2023 00:00:00 GMT

作ったもの

dockern

denoを使っているので、READMEの通りinstallしてdockernで実行できます。

経緯

色々とDockerコンテナをガチャガチャしていて、何度もimageやvolumeをまとめて削除したいケースが発生しました。

docker compose系のコマンドはエイリアスも貼ってあるし、覚えているのですが、dockerコマンドは全然覚えていないので、ここら辺をラップしてやってくれるコマンドを作ることにしました。（なおアイデアとライブラリだけ選んでほぼChatGPTで作った）。

仕事中に「dockerをドッカーンと」とか聞いたような記憶があったので、名前はdockernです。

ぐるぐるどっかーん

スプー世代の方はわかると思います。

Terminal window

$ dockern guru2
ぐるぐるぐるぐるどっかーん🎺

まあメインコマンドはdockernだけで実行できるので、明日以降これを実行することはないでしょう。

おわり

今消したいimageやvolumeがないので、あまりしっかり動作確認はしていません。業務中に動かなくなったら都度直していこうと思います。

WEBRickのqueryをパターンマッチで取り出す

ikuma-t — Sat, 14 Oct 2023 00:00:00 GMT

WEBRickではリクエストのクエリをreq.queryで取得できます。

WEBrick::HTTPRequest#query (Ruby 3.2 リファレンスマニュアル)

この戻り値はHashなので、例えばhogeを取得するのであればreq.query['hoge']のようにすれば値を取得できます。できますが、せっかくなのでパターンマッチで取得します。

req.query.transform_keys(&:to_sym): req.queryのHashのキーはStringなので、パターンマッチで取得するためにSymbolに変換します。
req.query.transform_keys(&:to_sym) in :hoge: パターンマッチでhogeを取り出します。ローカル変数hogeにreq.query[“hoge”]の値が格納されます。

気がついたらパターンマッチのカッコは省略可能¹になっていたので、変数1,2個取り出すくらいならガンガンに省略していきたいですね。

Footnotes

Ruby3.1からだったみたい。知らなかった。 ↩

slidevでスライドの進捗に応じたプログレスバーを表示する

ikuma-t — Mon, 09 Oct 2023 00:00:00 GMT

Slidevでスライドを作成する際に、現在のページを表示しつつ、全体に対する進捗をプログレスバーとして表示したいと思い作ってみました。

Slidevではglobal-bottom.vueというファイルを作成すると、自動ですべてのスライドにそのコンポーネントがレンダリングされます。

以下の内容をglobal-bottom.vueとして配置することで、プログレスバーを表示できます。

<script setup lang="ts">
import { computed } from 'vue';

const r = 40
const strokeWidth = 11
const circumference = 2 * Math.PI * r

const progress = computed(() => {
  return ($slidev.nav.currentPage / $slidev.nav.total) * circumference;
});

const offset = computed(() => {
  return circumference - progress.value;
});
</script>

<template>
  <footer class="abs-br m-3">
    <svg w-8 viewBox="0 0 100 100">
      <circle class="base-circle" cx="50" cy="50" :r="r" fill="none" :stroke-width="strokeWidth" />
      <circle class="progress-circle" ref="progressCircle" cx="50" cy="50" :r="r" transform="rotate(-90 50 50)" fill="none" :stroke-width="strokeWidth" :stroke-dasharray="circumference" :stroke-dashoffset="offset"/>
      <text class="progress-text" font-size="9" x="50" y="52" dominant-baseline="middle" text-anchor="middle">{{ $slidev.nav.currentPage }}</text>
    </svg>
  </footer>
</template>

<style>
// 色は適当に調節してください
:root {
  --bg-stroke-color: #e2e8f0;
  --progress-stroke-color: #b91c1c;
  --text-fill-color: #020617;
}

.base-circle {
  stroke: var(--bg-stroke-color);
}

.progress-circle {
  stroke: var(--progress-stroke-color);
}

.progress-text {
  fill: var(--text-fill-color);
}
</style>

Tailwind CSSのクラスをいい感じにマージするshadcn/uiの`cn`ユーティリティ

ikuma-t — Fri, 11 Aug 2023 00:00:00 GMT

はじめに

shadcn/uiをインストールすると、utilsとしてcn関数がついてきます。これが自分でTailwind CSSを使ったコンポーネントを作る際にも便利なのですが、何をやってくれているのか理解していなかったので調べてみました。

要約

cnはtwMergeでclsxをラップした、「外部から指定されたTailwind CSSのクラス名をマージしつつ、オブジェクトの形式で条件付きのクラスを定義」をすることができるユーティリティ関数である。

cnの中身

記事執筆（2023/08/11）時点でのcn関数の実装は次のとおりです。

import { type ClassValue, clsx } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

twMergeでclsxをラップしていることがわかります。他に実装はないので、これら2つの効能を見ていきます。

twMergeの効能

https://github.com/dcastil/tailwind-merge

twMergeはライブラリtailwind-mergeから提供される関数の1つです。

Tailwind CSSでは同じ効果をもたらす別のプロパティがclassに指定された場合、CSSのルールに則っていずれかのプロパティしか適用されません。例えば、px-2 py-4を持つコンポーネントにp-5を適用しても、p-5は適用されません。

そういうことを頻繁にやるべきかどうかの議論はさておき、これは既存のコンポーネントのスタイルを外側から上書きする際に不便な挙動です。

twMergeを使用することで、衝突するクラス名だけを外から渡したものに上書きすることができます。

const MyButton = ({ classNames, ...props }) => {
  return (
    // hover:opacity-70はそのままに、Propsとして提供したclassNamesが適用されるようにclassNameがマージされる
    <button className={twMerge('px-2 py-4 hover:opacity-70', classNames)} />
  )
}

詳細なマージの挙動については公式ドキュメントを参照してください。

clsxの効能

https://github.com/lukeed/clsx

clsxは文字列や配列、オブジェクト含めてclassNameをいい感じに連結することのできるユーティリティライブラリです。

公式のUsageをそのまま貼り付けます。

import clsx from 'clsx';
// or
import { clsx } from 'clsx';

// Strings (variadic)
clsx('foo', true && 'bar', 'baz');
//=> 'foo bar baz'

// Objects
clsx({ foo:true, bar:false, baz:isTrue() });
//=> 'foo baz'

// Objects (variadic)
clsx({ foo:true }, { bar:false }, null, { '--foobar':'hello' });
//=> 'foo --foobar'

// Arrays
clsx(['foo', 0, false, 'bar']);
//=> 'foo bar'

// Arrays (variadic)
clsx(['foo'], ['', 0, false, 'bar'], [['baz', [['hello'], 'there']]]);
//=> 'foo bar baz hello there'

// Kitchen sink (with nesting)
clsx('foo', [1 && 'bar', { baz:false, bat:null }, ['hello', ['world']]], 'cya');
//=> 'foo bar hello world cya'

さまざまなパターンでの連結と、Falsyな値をパージする機能があります。後者は特にオブジェクト記法でクラスと条件をマッピングしておくことで、条件付きスタイリングの際に重宝します。

twMergeとclsxを組み合わせて使う理由

「Tailwind CSSのクラス名のマージと、オブジェクトでのクラス名の指定を行いたいから」 です。

tailwind-mergeでもクラス名の文字列連結を行うためのtwJoinという関数が提供されていますが、こちらはオブジェクトでの記法がサポートされていません。

実装されていない理由はこちらのDiscussionに記載があります。曰く、オブジェクトの記法はキーにクラス名が、バリューに条件がくることで、そのクラスがいつ適用されるかの認知負荷が高いと判断した、とのことです。リーダブルコードにもこんな感じの条件分岐の話がありましたね。

Discussionの続きになりますが、スタイルを変更するにはクラスをまずはみるのだからオブジェクトにも対応してほしいとの返信があり、議論の結果としてshadcn/uiでも使用されているcn関数のような記述が返されています。

import { twMerge as twMergeOriginal } from 'tailwind-merge'
import clsx from 'clsx'

export function twMerge(...args) {
    return twMergeOriginal(clsx(args))
}

これによりこの関数になんでもかんでもクラス名を指定すれば、自分が最後に指定した内容が意図通りにスタイリングとして反映される便利関数の完成です（雑）。

型定義

再掲になりますが、cnでは次のようにして、clsxと同等の引数を受け取れるようにしています。

import { type ClassValue, clsx } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

おわりに

今回はshadcn/uiで提供されているユーティリティ関数cnを見てみました。

cnという名前がclassName由来なのか、shadcn由来なのか気になりますね…。

shadcn/uiにはもう1つ、ウィンドウ幅に応じてTailwind CSSにおけるブレイクポイントを画面上に表示してくれるDevtools的なものがあるので、また別の機会にそちらの実装をまとめてみようと思います。

刺繍をはじめてみました

ikuma-t — Thu, 10 Aug 2023 00:00:00 GMT

刺繍をはじめてみた

Twitter | Xでペンギンの刺繍を見かけたことをきっかけに刺繍を始めてみました。ドット絵を過去にやったこともあったのですが、そのときも事物をデフォルメした形で表現するのがいいなあと思って始めたので、こういう系統が自分の趣味かもしれません。

やってみたもの

こんな感じの刺繍キットを買ってみました。

お花を刺繍していって、最後にトートバッグを作るようです。

刺繍をやる部分はこのような枠で布を貼るのですが、この道具のビジュアルが最高です。手仕事感が前面に出ていて、クリエイター魂が燃え上がります。

1日目は青い花を縫い終わりました。

習得した技術

ロングアンドショートステッチ
フレンチノットステッチ
サテンステッチ

ロングアンドショートステッチは細かさよりも、均等に幅を刻んでいくことが大事だと学びました。

感想

楽しい！！時間を忘れて縫っていました。針を手に持っているのでスマホを途中で取るという行為もできず、デジタルデトックスが必要な私には非常に良かったと思います。

新規開発であってもdocker-composeやnpm createをすれば一発で環境が立ち上がる、ミスをすればgitで戻せばよい開発と異なり、環境構築も全くわからんし、ミスったら物理的に戻せない点も非常に刺激的でよかったです。

今回の進捗は花1つなのですが、これがあと12個 + エコバッグを組み上げる作業があるので、アニポケでサトシがジムバッジ集めてリーグ挑戦するくらいかかりそうな予感はしていますが、ぼちぼちやっていこうと思います。

技術書を写経する時は、予習の写経・復習の写経の2段階に分けると定着がいい

ikuma-t — Tue, 08 Aug 2023 00:00:00 GMT

はじめに：ハンズオン系の技術書を読むときの難点

ハンズオン系の技術書、得意ですか？私は結構苦手です。

読書自体はそこまで苦手ではなくて、紙面だけで完結するような書籍であれば割とスラスラと読めるのですが、ハンズオンが含まれると途端に進みが悪くなります。

読み始めて最初の数章はいいんですが、だんだん写経するのが面倒になってくる一方で、とはいえハンズオンが売りの書籍でハンズオンをやらないと知識定着しないし…という感情のせめぎ合いに、しまいには読み進めること自体を放棄してしまうこともしばしば。

今回はこの課題感を解消するためにやってみた「予習の写経」「復習の写経」が結構良かったので紹介します。

技術マスター予習の写経 / 復習の写経

アイデアのきっかけは、以前時雨堂さん主催の勉強会の形式にあった「勉強会の中で同じコンテンツを2回繰り返す手法」です。これに倣い、写経を同じセクションに対して2回行うのが、今回紹介する方法になります。

予習編

Git管理下のリポジトリを用意し、そこに読んでいる書籍のハンズオンを実装していきます。もし書籍側から提供されているコードがあればそれを利用するのもいいでしょう。

この段階では書籍の内容を読むことを中心にして、ざっくりと概要を掴みます。

書籍にもよりますが、大体1つの章の単位で区切りをつけると良いと思います。あまり復習までの間隔が短すぎると内容を覚えてしまっているので退屈感が増してしまい、もともと解決したかった課題にそのままぶつかることにになるからです。

スイッチ

予習が終わったら写経したハンズオンをコミットした上で、実装の詳細を全て消します。例えば次のような形です。

// Before
const greet = (name: string) => {
  return `Hello ${name}`;
};

// After
const greet = (name: string) => {
  // 実装の詳細を消す
};

消す範囲は自由に決めて良いと思いますが、全部消すと内容が思い出せなさすぎるので、コードを見ればなにをすればいいのかがわかるくらいには残すのがポイントです。

復習編

テキストを見ないで吹っ飛ばした実装の詳細を自分で実装します。

ここでは1つのセクションやファイルが自分で実装できるたびにGitの差分を確認し、復元できているかをチェックします。動作としてはハンズオンでやったとおり動いていても、微妙に実装内容が違ったりすることもあり、思わぬ自分の手癖の発見に繋がったりします。

メリット・デメリット

一度予習した内容が頭にありつつも、完全に定着していない知識をあぶり出し、定着させられるのがこの方法のメリットです。実装が思いつかない・思い出せない部分は自ずと詳しく読むことになるので、最初の予習時に心理的にサラッと読めるのも良いと感じています。

一方で一度だけ読む方法に比べれば手間がかかるのは事実です。知識が定着できなかった場合はトータルで見ても時間ロスかもしれません。

またこの手法は今のところ何かしらのファイルに実装を重ねていくハンズオンでしか実施していませんが、コンソールで試していくタイプのハンズオンには向かないかもしれません。zxがマークダウンを解釈できますが、これの各言語版があると全ては解決かもしれません。

おまけ：大AI時代ならではの困りポイント

初めてこの方法を思いついて実施してみた時に、穴埋めになったコードをGitHub Copilotが全力で補完してきました😅。実施時はオフにしておくのがよさそうです。

個人サイトをリニューアルしました！（N度目）

ikuma-t — Mon, 07 Aug 2023 00:00:00 GMT

N度目のリニューアル

もう何度目かわかりませんが、個人サイトをリニューアルしました。

元のサイトはこちらです（vercelにFreeでアップしているので、生き残ってはいる）。

本当は以前のサイトをもう少し継続して使用する予定だったんですが、色々とローカルでいじっていたらAstroがぶっ壊れてしまい、直すのも面倒なので作り直したという経緯です。

使用技術

Remix
Tailwind CSS / shadcn/ui
Newt
Cloudflare Pages

今回はこんな構成で作ってみました。Next.jsのAppRouterを使っても良かったのですが、Cloudflareを使ってみたかったので相性の良いRemixを採用した次第です。

Remix

かなりゴリゴリ書いてしまったので、正直Remixの開発体験がいいのか悪いのかはジャッジできません。リファクタリングしないといけない箇所がたくさんあるので、修正するなかでまた感想を書こうと思います。

Cloudflareとの相性という点ではセットアップ時にCloudflare Pagesへのデプロイを指定できるので、ここはめちゃくちゃ良かったですね。あとからちゃんと確認しましたが、npm scriptsでnpm run devをwranglerにリフレクトするような仕草もデフォルトで入っていたので、デプロイはかなりスムーズでした。

Newt

Astroでローカルがぶっ壊れたのはエラーメッセージ的におそらくMDXのパースと踏んでいたので、同じ轍を踏まぬように今回はCMSを使うことに。

microCMSを使っても良かったのですが、あえてNewtを使ってみました。なんとなくです。

CMSのエディタが個人的には好印象で、表示部分はNotionのようにいくつかのビューを選択でき、登録・編集部分では「絵文字」や「カラー」などの珍しいフォーム部品もありました。このブログでも絵文字をCMS側で登録して、それをブログ一覧に表示しています。

マイナス点としては2つあり、1つはモデルの定義の場所がわかりにくい & 設定変更後保存しなくてもアラートが出ないのでよく保存し忘れること。もう1つはSDKの使い方が微妙に分かりにくいことです。後者はある程度使っていけばわかるようになりますが、初見でGitHubのREADMEを見ただけでは、複雑なクエリの発行が難しかったです。

Cloudflare Pages

ずっと使おうと思って早数ヶ月、やっとことさ使うことができました。Pagesの方はNetlifyやVercelを使ったときの体験と大体同じなので割愛です。

今回ブログの動的OGP生成のためにCloudflare Pages functionsを使おうとしたのですが、結果として1MBの制限を超えられず使用を断念しました。

vercel/ogのcloudflare-pages版が出ていたのでそれを使った実装を考えていたのですが、おそらくvercel/og自体のバンドルサイズやらで容量制限に引っかかっていそうです。考えている過程はこちらを参照いただければと思います。

まあ固定でもいいっちゃいいんですが、時間がある時にまた対応しようと思います。

残タスク

とりあえず公開できるくらいにしましたが、まだまだ実装残があります。

記事移行
技術スタックのページをつくる
アンカーリンクがページ移動するだけで、リンクが切り替わらない
ブログ、登壇の動的OGP対応
リンクカード対応
ページネーション

まずは過去記事を移行しようと思っています。

おわりに

もともと記事しかなかった個人サイトもリニューアルするたびに機能が増えていっています。

前回の更新では登壇情報が増えましたが、今回は以下の機能が増えました。

ブログのカテゴリわけとタブ表示
個人的なお知らせ機能
年ごとの登壇数集計

突然の移管は不本意でしたが、乗り換えることによって、自分の実装力の向上を図ることができ、結果として良かったかなと思っています。

とはいえ次は1年以上もつといいなあ…。

[Node/Deno]ちょっとしたCLIで使えるスピナー

ikuma-t — Sat, 03 Jun 2023 00:00:00 GMT

はじめに

ちょっとした CLI を作っている時に、ある程度長い処理（最近だと OpenAI の API 呼び出しとか）を実行している際に、ローディング時間が気になります。

そんなときにスピナーを表示して、実行中であることを視覚的にわかるようにしたいのですが、これをやるためだけにライブラリを追加するのもやや微妙です。

そのため、Node.js/Deno でちょっとしたスピナーを作ってみました。

実装

いずれの場合も基本形は同じで、それぞれのランタイム固有の API に置き換えているくらいです。

Node.js

const FRAMES = ["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"];

export class Spinner {
  constructor(
    private intervalId: NodeJS.Timer | undefined = undefined,
    private currentCharIndex = 0
  ) {}

  start(message?: string) {
    this.intervalId = setInterval(() => {
      const spinner = FRAMES[this.currentCharIndex++];
      const spinnerMessage = message ? `  ${message}` : "";
      process.stderr.write(`\r${spinner}${spinnerMessage}`);
      this.currentCharIndex %= FRAMES.length;
    }, 100);
  }

  stop(message?: string) {
    clearInterval(this.intervalId);
    process.stderr.write(`\r${message ?? ""}`);
  }
}

Deno 実装

const FRAMES = ["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"];

export class Spinner {
  constructor(
    private intervalId: number | undefined = undefined,
    private currentCharIndex = 0
  ) {}

  start(message?: string) {
    this.intervalId = setInterval(() => {
      const spinner = FRAMES[this.currentCharIndex++];
      const spinnerMessage = message ? `  ${message}` : "";
      Deno.stdout.write(
        new TextEncoder().encode(`\r${spinner}${spinnerMessage}`)
      );
      this.currentCharIndex %= FRAMES.length;
    }, 100);
  }

  stop(message?: string) {
    clearInterval(this.intervalId);
    Deno.stdout.write(new TextEncoder().encode(`\r${message ?? ""}`));
  }
}

使い方

// 使い方（Node.js）
import timers from "node:timers/promises";

(async () => {
  const spinner = new Spinner();
  spinner.start("ロード中...");
  await timers.setTimeout(3000);
  spinner.stop();
})();

// Deno
import { sleep } from "https://deno.land/x/sleep/mod.ts";

const spinner = new Spinner();
spinner.start("ロード中...");
await sleep(3); // sleepはミリ秒ではなく、秒を渡すインターフェース
spinner.stop();

spinner 自体には実行時間等の役割は持たせず、あくまで表示のみを行うようにしています。そのため、何かしら長い処理の前後に spinner.start() と spinner.stop() を挟む形で使うことになります。

このインターフェースは大きめの CLI になるとやや微妙かな？と思ったりしましたが、今回はささっと使える Spinner を用意するのが目的だったのでこれでよしとしています。

解説

NodeJS.Timer

https://nodejs.org/api/timers.html#timers

window.setInterval の場合や Deno の場合も、setInterval の戻り値は number なのですが、Node.js ではイベントループを管理するためのオブジェクトとして NodeJS.Timer という型が用意されています。

Node.js においては、setInterval の戻り値がTimeout クラスであり、このクラスの型が NodeJS.Timer です。

実際の型定義は以下の通りです。

declare module "timers" {
  // ...
  let setInterval: typeof global.setInterval;

  // ...
  global {
    namespace NodeJS {
      interface Timer extends RefCounted {
        hasRef(): boolean;
        refresh(): this;
        [Symbol.toPrimitive](): number;
      }

      // ...
    }
  }
}

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/3197efc097d522c4bf02b94e1a0766d007d6cdeb/types/node/timers.d.ts#L31-L35

interface RefCounted {
  ref(): this;
  unref(): this;
}

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/3197efc097d522c4bf02b94e1a0766d007d6cdeb/types/node/globals.d.ts#L234-L237

ドキュメントを読む限りでは、以下のような感じでした。

デフォルトでは Timer はイベントループが有効な間は生存する
このデフォルトの挙動をカスタマイズできるように、ref() と unref() が用意されている
Timer#refresh() は Timer オブジェクトをリフレッシュする（タイマーがリセットされる）
Timer#Symbol.toPrimitive() は Timer オブジェクトを数値で返す。これによって、ブラウザでの setInterval との実装の互換性を実現できる。

今回のように、ブラウザの setInterval と同じような感覚で使用している場合にはあまり効果はないですが、イベントループを意識した処理を書く際にはこれらのインターフェースが役に立つのかも？

キャリッジリターン

\rのことですが、単純にconsole.log()してしまうと、改行が発生してスピナーのフレームが変わるたびに 1 行ずつ表示されてしまいます。

そのため、それぞれのランタイムの出力を利用して出力し、さらにキャリッジリターンを使って、カーソルを行の先頭に戻すようにしています。これでその位置に留まり続けるスピナーの完成です。

カスタマイズ

ローディングに表示されるアイコンを変える

FRAMES に好きなアイコンを定義すれば、その通りに表示されます。

今回表示している点字は https://github.com/sindresorhus/cli-spinners を参考にさせてもらいましたが、これ以外にも適当な絵文字（🍣 とか 🍺 とか）を使っても良いかもしれません。

標準出力にまぎれないようにする

こういったことをしたいユースケースとしては、「ターミナル上ではローディングを見せたいけど、処理結果を pipe 等で後続処理に渡したいので、標準出力には出力したくない」というケースかと思います。これは現時点での暫定解なのですが、標準出力ではなく標準エラー出力に出力すればとりあえず解決します。

解決は解決なんですが、本来エラーのために用意されている箇所を、こういったハックのために使うのはいかがなものかという気もしますね…。

おわりに

今回 intervalId を持っていて欲しかったので、イメージしやすくクラスとして作りましたが、関数型でやるとどうなるのかは気になるところ。気が向いたらやってみようと思います。

…こういっていて気が向いたことはないので、多分やりません。どなたか実装されたら教えてください。

『問いのデザイン創造的対話のファシリテーション』を読んだ

ikuma-t — Sat, 03 Jun 2023 00:00:00 GMT

はじめに

お通夜会議を脱したい

「こういう感じで考えてみたんですけど、ご意見ある方いらっしゃいますか？」

「…」

沈黙が走る。

たたき台を作ってまとめる、そこまでは順調に進んだが、実際にチームにシェアする場面で投げかけた一言にはなかなかレスポンスがなく、どう進めようか画面の前で汗ダラダラ…。何か前に進めなければと思って振り絞るも、結局進め方がわからず「ｱｯ…」となってしまう。なんやかんやしているうちに、1 人が出したよさそうな意見がめちゃめちゃ眩しい…。なんだかいい感じだ！みんなも良さそうと言っているし…ええいもう「なんとかなれ〜！！」。

…とまあここまで極端ではなくても、参加者の意見をリアルタイムに汲み取りながら進めていくタイプのミーティングでこうした状況になってしまうことはままあります。

そのためどうにか再現性高くこのお通夜会議¹を脱したいと思っていました。

『問いのデザイン創造的対話のファシリテーション』を読んだ

画像引用元: https://book.gakugei-pub.co.jp/gakugei-book/9784761527433/

前から認識してはいたのですが、課題感が募った今がまさに読み時だろうと思って問いのデザイン創造的対話のファシリテーションを読んでみたので、この本を読んで得たヒントをまとめてみます。

なお本書の構成としては「課題のデザイン」「プロセスのデザイン」の前後編に分かれており、ざっくり前者は What を、後者は How を解説した内容になっています。どちらも参考になる部分がとても多かったですが、今回は特にお通夜会議攻略の糸口という観点で「プロセスのデザイン」に今の自分に刺さるヒントがあったので、そちらの内容を整理してみます。

ファシリテーションのヒント

課題への道を経験のプロセスとしてデザインする

これは 4 章ワークショップのデザインに書かれている内容なので、通常運営のミーティングとはややニュアンスが異なるかもしれませんが、自分としては十分応用できる内容だと思いましたので自分の解釈と共に紹介します。

まず本書におけるワークショップは「普段とは異なる視点から発想する、対話による学びと創造の方法」となっていて、その実現のために経験のプロセスをデザインすることが大事だと言います。具体的には最終的な課題に対して、「導入」「知る活動」「作る活動」「まとめ」の 4 つのプロセスを設計していきます。美味しい料理を作るために下ごしらえが必要なように、課題に対してアウトプットを出す際にも、情報を知ることなり、それぞれがイメージやビジョンを巡らせるなどの下準備が必要というわけです。

よくよく考えてみるとお通夜会議も、得てして「問いかけられた側が答えを持っている」かのような前提で始まることが多い気がします。実際のところは、その会議を持ちかけた側が課題に対しての熱量と情報量が高く、反対に持ちかけられた側は日常の別タスクをこなしているところからその課題に向き合うため、全くもって準備万端ではありません。そう考えると反射的に答えられないこともよく頷けます。

そのため会の目的にもよりますが、最終的な課題へ参加者の頭を切り替えさせるようなアイスブレイクや問いの足場を段階的に設けることが必要になりそうです。例えばスプリントレトロスペクティブであればいきなり KPT をあげるという「作る活動」に移行するのではなく、まずはチームでいいところも悪いところもあげるようなアイスブレイクを「導入」として用意し、そのスプリントでどんな積み上げをしてきたのかを「知る活動」を設けた上で、KPT に挑むという具合です。（これに倣って最近では「賛否両論」というアイスブレイクをレトロスペクティブに取り入れてみたりしています。これはまたいつか紹介します。）

例に挙げたスクラムイベントのようにある程度定期的に開催されるイベントはこのようにかっちりと当てはめやすいですが、日々流動的に発生するミーティングにこれを適用するのはやや難しいなと感じています。そのため、大枠としてミーティング全体を Input・Output の 2 枠で捉えて、Output に対して必要な Input の部分が荒くないか？という観点でミーティングを観察し、必要に応じて後述の制約を設けた問いを投げるようにしてみています。現状成功率は 8 割くらいですが、全く道標がない状態よりも大枠を一定のプロセスとして捉えることは、一定成果があるように思います。

問いに制約を設ける

もう 1 つなるほどと思ったポイントが、問いに対して制約を設けることです。

具体的には以下のようなテクニックを使うことで、問いに対して制約を課し、参加者の思考の足がかりを形成することを試みます。

価値基準を示す形容詞をつける
ポジティブとネガティブを示す
時期や期間を指定する
想定外の制約をつける
アウトプットの形式に制約をつける

お通夜会議でよくある「何か意見あればお願いします」や「感想でもなんでもどうぞ」は、問いかけとしては広すぎるため、参加者からすると「どこから考え始めていいのかわからない」ことに加え、一見どんな意見も許容しているように見えて、参加者心理では回答のガイドラインがないために「この内容を答えてしまっていいのか？」という不安が生まれてしまいます。

各テクニックの詳細は本書を参照していただくとして、自分がいいなと思ったのが「アウトプットの形式に制約をつける」テクニックです。この方法では、「〇〇するための 3 つの条件は？」「〇〇を起承転結で表すと？」といった具合にアウトプットの形式に制約がかかっています。お通夜会議では Input のフェーズで話している内容が絞られておらず、自由に発散しているため議論が収束しにくいです。そのため、いくつかの発散が行われたタイミングで「この中から 1 つだけ対応すると考えた時、どれを選びますか？」と問いかけを行うと、参加者の思考の足がかりになり、議論が進みやすくなるのではないかと思いました。²

感想

本書を読むまでは、お通夜会議に陥った際に、出口までの順路がぐにゃぐにゃになってしまって、着地できるかどうかは運任せでした。

最近では少しずつちいかわ状態に陥った際にもリカバリがわかってきて、「今はインプット・アウトプットどちらに当てるべき時間か」「場に投げられている問いは広いか？広いならどう制約をつけたせそうか？」といったことを考えながら発言したりしています³。これは別に自分がファシリテーターではなくても有効な考え方で、自分が一参加者の場合もお通夜会議になりそうだったら、今回挙げたようなポイントで出口を探っています。ファシリテーターはあまり余裕がないので、共通認識として本書の考え方が通っていると、全体の議論の質も上がりそうです。

色々試しつつ、少し成果を出しつつもありますが、まだまだ課題も色々あります。

ファシリテーターとしての帽子と開発者としての帽子を同時に被るのは大変
- 基本的に「この問いが広いのか、狭いのか」「全体の熱量はどのくらいか」といった観点は、議論から一歩引いた姿勢になる。
- 日常に湧き起こるミーティングのほとんどは自身も当事者であり、それだけがうまくできていればいいわけではない（本質は課題を解くこと）。
- 別の誰かがコントロールしてくれている、誰かが意識しなくても自然とうまく進んでいるときであれば、当事者としてのアクセルを全開にするような切替が求められそうだけど、難しい。
ファシリテーターは黒子だけど、うまく解決できることが楽しくなってくると黒子ではなくなる
- この手法で楽しくなっちゃっているレベルはまだまだなんだろうなという気持ち
- エンジニアの麻疹のように、まずはガッチリ使い込んで、その後に自分なりの解釈を加えていきたい
いつも成功するわけではない
- いろいろ試している感覚として、お通夜になったときにそこに再度アクセルをかけるのは 8 割 5 分くらいの成功できていますが、それ以降確実に収束の方向性へ迎えるかは正直運なので、確度をあげたい

というわけでもう少し意識的に続けてもっと良くできるように頑張ってみたいと思います。

Footnotes

別名ちいかわ会議 ↩
ちょくちょく仕事でもこの質問を投げる機会があるんですが、聞く時には脳内で BUMP OF CHICKEN の「ダイヤモンド」が流れています（サビの歌詞参照）。 ↩
しかしこれが周囲から見て機能しているかはまた別問題である。。。 ↩

アイコンが重なってて、ホバーするとニュッとするそれ

ikuma-t — Sun, 28 May 2023 00:00:00 GMT

アイコンが重なってて、ホバーするとニュッとするそれを作ろう

これは dev.to の記事リアクションの表示です。Slack でハドルミーティングが発生している時の参加者の表示にもこういったアイコンを重ねるレイアウトがよく見られます。

よく見かけるけど自分では作ったことがなかったので、CSS Animated Grid Layoutsを参考にしつつ、今回はこちらを少し捻ったもの練習として作ってみました。

要件

アイコンの数は 1〜5 個
アイコンは重ねて表示する
アイコンのいずれかをホバーすると、全体が広がり、後ろのアイコンも見えるようになる

実装

See the Pen{" "} <a href="https://codepen.io/ikumatadokoro/pen/RweOMXb"> アイコンが重なってて、ホバーするとニュッとするそれ </a>

https://codepen.io/ikumatadokoro/pen/RweOMXb?editors=1100

実装メモ

1 次元配置なので、Flexbox でもいけると思うのですが、今回は参考ソースに合わせて GridLayout での実装になります。

アイコンを重ねて表示する

このレイアウトの中核は、アイコンより狭めに設定された列トラックです。

今回は横方向にアイコンを積んでいくため、grid-auto-flow: columnを指定した上で、grid-template-columnsで列の数を指定します。

このとき、列幅を以下のように定義しています（必要部分のみ抜粋）。

.icons {
  --gap: 1em;
  --icon-size: 5em; /* 実際のアイコンのサイズ */
  --overlap-size: 2em; /* 列トラックのサイズ。アイコンよりも小さめ */
  --num-children-1: calc(var(--num-children) - 1);
  --grid-cell-size: var(
    --overlap-size
  ); /* アイコンよりも小さめの列トラックが定義されているので、重なって見える */

  display: grid;
  grid-auto-flow: column;
  grid-template-columns: repeat(var(--num-children), var(--grid-cell-size));
  grid-auto-columns: var(--grid-cell-size);
  gap: var(--gap);
  /* 植木算的な感じで全体の幅を要素に応じて調整している */
  width: calc(
    var(--grid-cell-size) * var(--num-children-1) + var(--gap) * var(
        --num-children
      ) + var(--icon-size) + var(--border-size)
  );
}

これで各列が重なるようになりました。

ホバー表示

ホバー時は、scaleを使って拡大表示しています。また、z-indexを指定して、ホバーしたアイコンが最前面に表示されるようにしています。

.icons > div:hover {
  scale: 1.1;
  z-index: 100;
  border-width: var(--border-size);
  border-color: var(--icon-color);
}

要素数に応じて幅計算を行うための CSS 変数

.icons:where(:has(> *:nth-of-type(1):last-child)) {
  --num-children: 1;
}
.icons:where(:has(> *:nth-of-type(2):last-child)) {
  --num-children: 2;
}
.icons:where(:has(> *:nth-of-type(3):last-child)) {
  --num-children: 3;
}
.icons:where(:has(> *:nth-of-type(4):last-child)) {
  --num-children: 4;
}
.icons:where(:has(> *:nth-of-type(5):last-child)) {
  --num-children: 5;
}

だいぶ力技感がありますが、5 個までの制約のもとに CSS だけで幅を計算するために、上記のような CSS 変数を定義しています。

where: 条件を満たす要素を選択する。
has：子要素又は子孫要素の中に、指定したセレクタにマッチする要素が存在する場合に、その親要素を選択する。

つまりこのセレクタでは「.iconsクラスの要素で、その最後の子要素がnth-of-type(1)の要素を持っているもの（=1 番目の要素）を選択する」という意味になります。要素数が 2 個の場合は、nth-of-type(2)の要素を持っているもの（=2 番目の要素）を選択する、というように、要素数に応じて幅を計算することが可能になります。

おわりに

全ての要素を削減したくはないけど、なんとなくの全体感を把握したい。そんなときに使えるのが「重ねて表示する」レイアウトと考えており、その目的に hover での展開を加えるメリットがあまりないので、実際にはこのレイアウトを使う日は少ないかも？と思っています（hover を実装したい時は「各要素は細かく見えるようにしたいけど、全体を見た時に他の要素も多いため、通常時は少し詰めて表示したい」と考えるときではないでしょうか）。

いずれにせよアイコンを重ねる実装自体は共通で使えるので、grid によるレイアウトの引き出しとして今後も活用していきたいと思います！

書籍「Web Workers」を読んだ

ikuma-t — Sun, 21 May 2023 00:00:00 GMT

画像引用元：https://www.oreilly.co.jp/books/9784873115962/

オライリーのWeb Workersを読みました。そろそろ Cloudflare Workers を触ろうと思っていて、そしたら Service Worker は知らんとな → そもそも Worker ってなんとなくわかるけど、ちゃんと説明できないな、ということで少し古めですが本書を読んで基本をかじってみることにしました。

この本で学んだこと

Web Worker は HTML5 の機能の一つで、JavaScript でマルチスレッドを実現するためのもの。メインスレッドの DOM を操作できない制約がある。
main と worker でオブジェクトは共有されない。メッセージをやりとりすることで通信するが、オブジェクトのコピーによりパフォーマンスに影響が出る場合は、移譲可能オブジェクトを利用できる。
Web Worker の種類には Dedicated Worker（専有）と Shared Worker（共有）がある。前者は 1 つのスクリプトからしかアクセスできないが、後者は複数のスクリプトからアクセスできる。

総じて「そもそも Web Worker ってなにもの？？」という超初歩的な問いに対しての答えを得ることができました。Web Worker における Hello World 的な存在が素数計算だということも初耳でした（今後サンプル作る時にやろう）。

読んでいる中でいくつか「これはどうなんだろう？」と疑問に思って調べたポイントをいくつかまとめます。

Web Worker VS Promise

「メインスレッドから処理を移譲することで、コンテンツの描画をブロックしないでおくことができる」という内容を見た際に、 これは Promise でも実現できるのでは？ と思いました。例えばインポート処理を行うボタンを押した際に、取り込み処理自体は Promise で非同期に実施し、適当にローディングアニメーションを付けて他の箇所は操作可能にしておくという実装はそれほど難しくありません。

この質問に対しての 1 つの回答は、 「CPU に負荷のかかる処理は、メインスレッドで順序を入れ替えても解決しないので Web Worker を使う意味はある」 です。

例として処理時間が 30 秒かかる画像のリサイズ処理を考えます。Promise で非同期に実行する場合、結局は画像のリサイズ処理を行うスレッドが 1 つしかないので、同期的に 30 秒待つことはなくとも、トータルとしては 30 秒の処理時間が必要になります。

一方で Web Worker を複数起動すれば、それらはメインスレッドとは別のスレッドとなり、その処理を並列で処理することができます。3 つの Worker をたて、1 つの Worker が捌く量を全体の 1/3 にすることで、ガバガバ計算ですが各スレッド単位での実行時間は 10 秒になります。そしてこれらは並列に処理されるので総実行時間も 10 秒です。

そのため計算処理自体が重い場合は Web Worker の使用を検討する材料の 1 つになりうるでしょう。

Shared Worker VS BroadCastChannel

これは半分勘違いだったのですが、 「複数のブラウジング・コンテキスト間で情報を共有できるという側面だけからこれらを見た時に、それぞれをいつ使うのか？」 と疑問に思いました。

そこであらためてそれぞれがどういう API なのか書き出してみました。

BroadCastChannelAPI: 異なる文書やウィンドウ間でメッセージを送信するための API
Shared Worker: 複数の文書やウィンドウから利用可能な共有のワーカースレッドを作成するための API

「複数のブラウジング・コンテキスト」をターゲットに機能していることは共通していますが、単純にメッセージを送信するのか、それとも実際に計算処理やコネクションを保持するといった具体的な処理を行うのかという点で、そもそもの目的が異なっています。

そのためこれらは競合するものではありません。例えば Shared Worker で Web Socker のコネクションを共有し、各ブラウジング・コンテキストに対しては BroadCastChannelAPI を使ってメッセージを送信するといった使い方もできるでしょう。

実際に実装していないので動くのかはわかりませんが、HTTP/1.1 における Server Sent Event のドメイン接続上限（6 つまで）を、Shared Worker を使って回避するといった使い方も可能なのではないでしょうか。

この本で学べなかったこと

Service Worker について
結局 Worker を実際のアプリケーションレベルでどう使用すべきか
- comlink を使うとか？
TypeScript における Worker の利用方法

この本を読む際の注意点

この本は 2013 年に出版された本です。そのため、以下の点に注意して読む必要があります。

出版当時にまだ世に出ていなかった Service Worker についての解説がありません。
全体的にサンプルコードが古いです。具体的には、大きいところで現状と異なる仕様の Twitter からのデータ取得を行うサンプル（これは今年の頭に出しても動かなくなっていそうですが）や、https ではなく http が使われている、細かいところでは変数宣言でvarが多用されているなど。
ブラウザの対応状況が諸々異なっています。Can I Use などで適宜確認してください。

感想

やや内容は古めでしたが、内容がコンパクトだったので数時間で読め、ざっくりと Web Worker とは何者かについて知ることができました。

Web Worker がメインスレッドの DOM 操作ができないことがわかると、PartyTown が Service Worker から同期 XHR で DOM を参照している仕組みが、俄然興味深いものに感じます。

というわけで今度は MDN と web.dev あたりを読みながら Service Worker に対する理解を深めていきたいです。

GitHub Actionsをローカルで試せるactを試してみる

ikuma-t — Wed, 10 May 2023 00:00:00 GMT

最近開発生産性を取得したりで GitHub Actions をよく書いています。最近では GitHub Actions の VSCode 拡張が出てきたことで、構文的なエラーには気が付きやすくなりましたが、やはり実際に動作するかは GitHub に push しなければならず、やや面倒でした。

N 番煎じではありますが、ローカルで GitHub Actions を実行できるnektos/actを使って、GitHub Actions のローカル実行を試してみました。

act の概要

act は Docker を利用して、.github/workflows のワークフローを実行するための Go 製のツールです。実行環境は現時点で ubuntu のみです。

https://github.com/nektos/act#runners

インストール方法はこちらの通りで、今回は Mac で使用するため、HomeBrew でインストールします。

Terminal window

brew install act

act の使い方

https://github.com/IkumaTadokoro/forke

ここからはこのリポジトリをサンプルに進めていきます。このリポジトリでは以下の GitHub Actions が定義されています。

.github/workflows
├── lint.yml
├── test.yml
└── release.yml

リポジトリのワークフローの確認

まずは対象のワークフローが認識されているかを確認します。

$ act -l

WARN  ⚠ You are using Apple M-series chip and you have not specified container architecture, you might encounter issues while running act. If so, try running it with '--container-architecture linux/amd64'. ⚠
Stage  Job ID   Job name  Workflow name  Workflow file  Events
0      lint     lint      Lint           lint.yml       push
0      release  release   Release        release.yml    push
0      test     test      Test           test.yml       push

期待通り、3 つのワークフローが認識されています。 M1 Mac を使っているので、実行時にエラーが出るかもと警告が出ていますが、一旦無視して進めます。

ワークフローの実行

今回は vitest によるテストを実行する Job「test」を実行してみます。特定の Job を指定するには-jオプションを使います。初回なので、DryRun（-n）で実行してみます。

$ act -j test -n

? Please choose the default image you want to use with act:

  - Large size image: +20GB Docker image, includes almost all tools used on GitHub Actions (IMPORTANT: currently only ubuntu-18.04 platform is available)
  - Medium size image: ~500MB, includes only necessary tools to bootstrap actions and aims to be compatible with all actions
  - Micro size image: <200MB, contains only NodeJS required to bootstrap actions, doesn't work with all actions

Default image and other options can be changed manually in ~/.actrc (please refer to https://github.com/nektos/act#configuration for additional information about file structure)  [Use arrows to move, type to filter, ? for more help]
  Large
> Medium
  Micro

*DRYRUN* [Test/test-1] 🚀  Start image=catthehacker/ubuntu:act-latest
*DRYRUN* [Test/test-2] 🚀  Start image=catthehacker/ubuntu:act-latest
*DRYRUN* [Test/test-3] 🚀  Start image=catthehacker/ubuntu:act-latest
*DRYRUN* [Test/test-2]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true
*DRYRUN* [Test/test-3]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true
*DRYRUN* [Test/test-1]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true
*DRYRUN* [Test/test-3]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-3]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-2]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-2]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-1]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-1]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
*DRYRUN* [Test/test-2]   ☁  git clone 'https://github.com/actions/setup-node' # ref=v3
*DRYRUN* [Test/test-3]   ☁  git clone 'https://github.com/actions/setup-node' # ref=v3
*DRYRUN* [Test/test-1]   ☁  git clone 'https://github.com/actions/setup-node' # ref=v3
*DRYRUN* [Test/test-2] 🧪  Matrix: map[node-version:18.x os:ubuntu-latest]
*DRYRUN* [Test/test-2] ⭐ Run Main actions/checkout@v3
*DRYRUN* [Test/test-2]   ✅  Success - Main actions/checkout@v3
*DRYRUN* [Test/test-2] ⭐ Run Main Use Node.js 18.x
*DRYRUN* [Test/test-2]   ✅  Success - Main Use Node.js 18.x
*DRYRUN* [Test/test-2] ⭐ Run Main Install
*DRYRUN* [Test/test-2]   ✅  Success - Main Install
*DRYRUN* [Test/test-2] ⭐ Run Main Unit Test
*DRYRUN* [Test/test-2]   ✅  Success - Main Unit Test
*DRYRUN* [Test/test-2] ⭐ Run Post Use Node.js 18.x
*DRYRUN* [Test/test-2]   ✅  Success - Post Use Node.js 18.x
*DRYRUN* [Test/test-2] 🏁  Job succeeded
*DRYRUN* [Test/test-3] 🧪  Matrix: map[node-version:20.x os:ubuntu-latest]
*DRYRUN* [Test/test-3] ⭐ Run Main actions/checkout@v3
*DRYRUN* [Test/test-3]   ✅  Success - Main actions/checkout@v3
*DRYRUN* [Test/test-3] ⭐ Run Main Use Node.js 20.x
*DRYRUN* [Test/test-3]   ✅  Success - Main Use Node.js 20.x
*DRYRUN* [Test/test-3] ⭐ Run Main Install
*DRYRUN* [Test/test-3]   ✅  Success - Main Install
*DRYRUN* [Test/test-3] ⭐ Run Main Unit Test
*DRYRUN* [Test/test-3]   ✅  Success - Main Unit Test
*DRYRUN* [Test/test-3] ⭐ Run Post Use Node.js 20.x
*DRYRUN* [Test/test-3]   ✅  Success - Post Use Node.js 20.x
*DRYRUN* [Test/test-3] 🏁  Job succeeded
*DRYRUN* [Test/test-1] 🧪  Matrix: map[node-version:16.x os:ubuntu-latest]
*DRYRUN* [Test/test-1] ⭐ Run Main actions/checkout@v3
*DRYRUN* [Test/test-1]   ✅  Success - Main actions/checkout@v3
*DRYRUN* [Test/test-1] ⭐ Run Main Use Node.js 16.x
*DRYRUN* [Test/test-1]   ✅  Success - Main Use Node.js 16.x
*DRYRUN* [Test/test-1] ⭐ Run Main Install
*DRYRUN* [Test/test-1]   ✅  Success - Main Install
*DRYRUN* [Test/test-1] ⭐ Run Main Unit Test
*DRYRUN* [Test/test-1]   ✅  Success - Main Unit Test
*DRYRUN* [Test/test-1] ⭐ Run Post Use Node.js 16.x
*DRYRUN* [Test/test-1]   ✅  Success - Post Use Node.js 16.x
*DRYRUN* [Test/test-1] 🏁  Job succeeded

初回ではどのサイズの image を利用するか聞かれます。一般的なワークフローであれば Medium で良さそうです。無事にワークフロー自体は正常終了したようなので、今度はテストの内容を変えて再度実行してみます。

# 日付差分を分単位で計測する関数の期待値を変えて失敗させてみる。
  test.each<[Date, Date, number]>([
    [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T01:00:00Z"), 60],
   [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:06:00Z"), 6],
   [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:06:00Z"), 7],
    [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:05:00Z"), 5],
    [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:01:00Z"), 1],
    [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:00:01Z"), 0],
  ])(`[DEFAULT: minute]calcTimeDiff(%s, %s): %s`, (date1, date2, expected) => {
    expect(calcTimeDiff(date1, date2)).toBe(expected);
  });

$ act -j test

...

[Test/test-1]   ✅  Success - Main Install
[Test/test-1] ⭐ Run Main Unit Test
[Test/test-1]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/3] user= workdir=
|
| > forke@1.1.4 test:ci
| > vitest run
|
|
|  RUN  v0.30.1 /Users/ikuma/src/github.com/IkumaTadokoro/forke
|
|  ✓ src/lib/__test__/mathUtil.test.ts  (12 tests) 5ms
|  ✓ src/lib/__test__/stat.test.ts  (9 tests) 8ms
|  ❯ src/lib/__test__/dateUtil.test.ts  (24 tests | 1 failed) 56ms
|    ❯ src/lib/__test__/dateUtil.test.ts > calcTimeDiff > [DEFAULT: minute]calcTimeDiff(2021-01-01T00:00:00.000Z, 2021-01-01T00:06:00.000Z): 7
|      → expected 6 to be 7 // Object.is equality
|
| ⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
|
|  FAIL  src/lib/__test__/dateUtil.test.ts > calcTimeDiff > [DEFAULT: minute]calcTimeDiff(2021-01-01T00:00:00.000Z, 2021-01-01T00:06:00.000Z): 7
| AssertionError: expected 6 to be 7 // Object.is equality
|  ❯ src/lib/__test__/dateUtil.test.ts:41:40
|      39|     [new Date("2021-01-01T00:00:00Z"), new Date("2021-01-01T00:00:01Z"…
|      40|   ])(`[DEFAULT: minute]calcTimeDiff(%s, %s): %s`, (date1, date2, expec…
|      41|     expect(calcTimeDiff(date1, date2)).toBe(expected);
|        |                                        ^
|      42|   });
|      43|
|
|   - Expected  - 1
|   + Received  + 1
|
|   - 7
|   + 6
| ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯
|
|  Test Files  1 failed | 2 passed (3)
|       Tests  1 failed | 44 passed (45)
|    Start at  20:40:05
|    Duration  868ms (transform 143ms, setup 0ms, collect 456ms, tests 69ms, environment 0ms, prepare 514ms)
|
[Test/test-1]   ❌  Failure - Main Unit Test
[Test/test-1] exitcode '1': failure
[Test/test-1] 🏁  Job failed

...

マトリクス実行しているのと、act 側のログが大量に出ているので実行部分のみ抜粋ですが、ローカルファイルの変更を反映してワークフローが実行されていることがわかります。これは便利。

ログ出力を抑制する

「act 側のログが大量に出ている」と先に挙げましたが、実例としては次のようなものです。

[Test/test-3]   💬  ::debug::{"archiveLocation":"***","cacheKey":"node-cache-linux-npm-eb3cb123726e2245d1ac05822a0ed4f5b7ab0e59926ef990db3189e8565ae3f7","result":"hit"}
[Test/test-3]   💬  ::debug::Archive Path: /tmp/71f659f3-b296-414e-a049-7495a8b9fd5e/cache.tzst
[Test/test-3]   💬  ::debug::Use Azure SDK: true
[Test/test-3]   💬  ::debug::Download concurrency: 8
[Test/test-3]   💬  ::debug::Request timeout (ms): 30000
[Test/test-3]   💬  ::debug::Cache segment download timeout mins env var: undefined
[Test/test-3]   💬  ::debug::Segment download timeout (ms): 3600000
| Cache Size: ~39 MB (40876809 B)
| [command]/usr/bin/tar --use-compress-program unzstd -xf /tmp/71f659f3-b296-414e-a049-7495a8b9fd5e/cache.tzst -P -C /Users/ikuma/src/github.com/IkumaTadokoro/forke
| Cache restored successfully
| Cache restored from key: node-cache-linux-npm-eb3cb123726e2245d1ac05822a0ed4f5b7ab0e59926ef990db3189e8565ae3f7
[Test/test-3]   ❓ add-matcher /run/act/actions/actions-setup-node@v3/.github/tsc.json
[Test/test-3]   ❓ add-matcher /run/act/actions/actions-setup-node@v3/.github/eslint-stylish.json
[Test/test-3]   ❓ add-matcher /run/act/actions/actions-setup-node@v3/.github/eslint-compact.json
[Test/test-3]   ✅  Success - Main Use Node.js 20.x
[Test/test-3]   ⚙  ::set-env:: NPM_CONFIG_USERCONFIG=/tmp/.npmrc
[Test/test-3]   ⚙  ::set-env:: NODE_AUTH_TOKEN=XXXXX-XXXXX-XXXXX-XXXXX
[Test/test-3]   ⚙  ::set-output:: node-version=v20.1.0
[Test/test-3]   ⚙  ::set-output:: cache-hit=true
[Test/test-3]   ⚙  ::add-path:: /opt/hostedtoolcache/node/20.1.0/arm64/bin
[Test/test-3] ⭐ Run Main Install
[Test/test-3]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/2] user= workdir=

毎回この量が出るのはしんどいので、これを-q, --quietオプションで抑制します。

$ act -j test -q

…が、期待通りにはなりませんでした。この--quietオプションはワークフロー側のログ出力レベルを抑制するもので、今回のワークフローの例で言えば、vitest の実装結果が省略されることになります。

おわりに

ログ出力の多さゆえに使えないということはないですが、このツールは試行錯誤中に利用したいものだと思うので、デバッグ用の情報はシンプルな方が嬉しい気がします。それを加味してもローカルで検証できることで GitHub への push 回数は抑制できると思うので、しかるべきときに使っていきたいですね。

ワークスペース内の画像のパスをパンッとはれるVSCode拡張をリリースした

ikuma-t — Sat, 06 May 2023 00:00:00 GMT

はじめに

ワークスペースにある画像のパスをそのまま or Markdown 形式でパンッと簡単にエディタに挿入できる VSCode 拡張、その名も SrcPan をリリースしました。

https://marketplace.visualstudio.com/items?itemName=IkumaTadokoro.srcpan

この VSCode 拡張機能には現時点で以下の機能があります。

ワークスペース内の画像ファイルをサイドバーに一覧表示する機能
選択した画像をサイドバーでプレビュー表示する機能
選択した画像のパスをそのまま or Markdown 形式でエディタに挿入する機能

なぜ作ったか

このブログは各記事を MDX で作成しています。記事には画像をしばしば挿入しているのですが、これに際して私が感じていた課題点は以下の 2 点です。

ブログコンテンツとブログ自体のコードが 1 つのリポジトリに共存しているため、画像以外のものがファイルエクスプローラーに表示されてしまい、画像を探すのが面倒である
astro では静的コンテンツのパスは「public」を省略して記述するルールだが、しばしば忘れる

これを解決するために、最初に述べたような「画像だけを一覧して、プレビューした上で、Markdown のパスですぐ挿入できる」VSCode 拡張を作りました。

何ができるのか

基本機能

拡張機能をアクティビティバーで選択すると、2 つのペインが開きます。

上部は現在開いてるワークスペースに含まれる画像を、ディレクトリ構造そのままに表示するペインです。そして下部がプレビュー表示ペインで、上部で選択した画像をプレビュー表示します。

上部のペインで画像をホバーすると、リンク挿入ボタンが表示されます。このボタンをクリックすると、画像のパスをそのまま or Markdown 形式でエディタに挿入します。

【設定】挿入するパスのフォーマット変更

デフォルトでは、画像のパスをそのまま挿入します。しかし、astro では静的コンテンツのパスは「public」を省略して記述するルールなので、そのディレクトリにある画像だけは、最初のパス部分を省略した形式で挿入したいという要望がありました。これに対応するため、正規表現でフォーマットを変更したいパスと、変更後のパス形式を指定すると、その形式でパスを挿入できるようにしました。

例えばこのブログでは先のとおり astro のルールに合わせて「public」から始まるディレクトリでは、その一つ下の階層からのパスを貼り付けるようにしたいです。そこで、settings.json に以下のように設定します。

"srcpan.pathFormatRules": [
    {
        "pathRegExp": "^\\/public(\\/.+)$",
        "replacement": "$1"
    }
],

pathRegExp には正規表現を指定することができ、replacement には任意の文字列を指定することができます。pathRegExp にキャプチャグループを指定した場合は、replacement に$1のように指定することで、キャプチャされた部分を挿入することができます。この設定により以下のように、/publicから始まるパスでは、/publicの 1 つ下の階層から始まるパスを挿入できるようになりました。

本来のパス： /public./srcpan-view.png
挿入されるパス： ./srcpan-view.png

このルールは配列形式で指定するので、複数のルールを指定することができます。public ディレクトリ、assets ディレクトリでそれぞれ最初の階層を省略したい場合は以下のようにします。

"srcpan.pathFormatRules": [
    {
        "pathRegExp": "^\\/public(\\/.+)$",
        "replacement": "$1"
    },
    {
        "pathRegExp": "^\\/assets(\\/.+)$",
        "replacement": "$1"
    }
],

【設定】一覧から除外するディレクトリを指定

デフォルトではワークスペースに含まれる.gitignoreを読み取り、そこに含まれるディレクトリは表示から除外するようになっています（これ自体も設定: useGitIgnore を false にすることで無効化できます）。

// 無効にする場合
"srcpan.useGitIgnore": false

.gitignore にはないが、一覧に表示する必要ないディレクトリがある場合は、追加で設定を記述することで対象外とすることができます。例えばこのブログではpublic以外は記事を作成する際に不要です。そのため、src/, integrations/ それぞれのディレクトリを除外するように設定します。

"srcpan.excludePatterns": [
    "src/**/*",
    "integrations/**/*"
]

ややこしいですが、こちらは glob パターンを配列で指定します。本当はいずれのオプションとも正規表現か glob パターンのどちらかに寄せようと考えていたんですが、パスの方は置換後の文字列を宣言的にかけた方が良いと思い正規表現を採用し、除外するディレクトリの方は glob パターンで指定する方が一般的だと思い glob パターンを採用しました 😅。

今後の改修予定

現時点では必要最低限の機能（README もろくに書いてない）しか実装していないのですが、今後は以下のような機能を追加していきたいと考えています。

ファイルのアップロード・更新機能

現在のファイルツリーは、変更・更新・削除に追随して更新されるようにはなっているのですが、あくまでファイルの更新はエクスプローラーから実施する必要があります。

一応回避策として、下図のように SrcPan をエクスプローラーに D&D してドッキングすることで一つのサイドバーで完結させることができるのですが、サイドバーの表示領域が窮屈なのでどうにかしたいところです。

ディレクトリの絞り込み

特定のディレクトリの画像のみ表示しているとはいえ、ファイル数が多いとそれでも探すのが大変です。そこで、ディレクトリを絞り込む機能を追加したいと考えています。 1 つの記事を書いている際に参照するディレクトリはせいぜい 1 つなので、記事名を入力して絞り込むか、現在開いているファイル名で絞り込む、みたいな機能があるといいかもです。

プレーン形式と Markdown 以外の形式でのパス挿入

これは今後自分の中で需要がどれだけ出てくるかにもよるのですが、import 文と HTML の img タグの形式でパスを挿入する機能があると便利かもしれないな〜と思っています。

おわりに

今回初めて VSCode 拡張機能を作ってみたんですが、環境構築が結構簡単で、API も多く想像よりも簡単に実装できました。パッケージ公開のためのvsceコマンドで*.vsixファイルを作ってしまえば、開発チーム内でのみ使用する Extension を作成することができ、チーム内の DX 向上の選択肢が増えたのは大きいですね。

今回作成した Extension は、こちらからインストールできます。ぜひお試しください。 README 含めてまだまだ整備できていないので、徐々に改善していきたいと思います（機能要望、バグ等あれば GitHub の Issue へどうぞ）！

余談：名前

「img の src をパンッと挿入できる」と「ソースパン（フライパン）」を掛けて「SrcPan」と名付けました。音優先でソースパン →「パンッと貼り付けられる」とこじつけましたが、たぶんこの擬音は「パンッ」ではなく、「シュッ」な気がしています 😅。

VSCode拡張、GistPadを試してみた

ikuma-t — Thu, 04 May 2023 00:00:00 GMT

GistPad が便利という Tweet を見かけたので、自分も導入してみました。

概要

https://marketplace.visualstudio.com/items?itemName=vsls-contrib.gistfs

GistPad は、お気に入りのエディタで快適に GitHub の Gist やリポジトリを編集できる Visual Studio Code の拡張機能です。Gist やリポジトリを開く、作成する、削除する、フォークする、スターを付けることができ、クローン、プッシュ、プルすることなく、まるでローカルにあるかのようにシームレスにファイルの編集を開始することができます。コードスニペット、よく使われる設定やスクリプト、プログラミング関連のメモ、ナレッジベース、インタラクティブなサンプルなどを構築し、参照するためのあなただけの開発者ライブラリのようなものです。 - マーケットプレイス紹介文を DeepL で翻訳

導入

VSCode に GistPad をインストール
アクティビティーバーの GistPad をクリック
GitHub にログイン

これで自分が作成した Gist の一覧が見られるようになります（鍵付きのものは Secret Gist。鍵がついているけど別に見られて困るものではないのでそのままスクショ掲載しています）。

気になった機能：Scratch Notes

表題の決まった Gist とは別に、メモを取るための Gist を作成できる機能が備わっている。デフォルトでは Markdown が生成され、そこに自由にメモができる。

内部的には Secret Gist が生成されているだけですが、削除・生成を GistPad 側でやってくれるので、気軽にメモができるというメリットがあります。開発時のちょっとしたメモを取りたいときに使えるかなあと思ったけど、Secret Gist はリンクがわかれば誰でも見れるので、業務用のメモには使えないですね〜。

上述のように業務の開発時の TODO メモ等には使いにくいですが、個人的な開発のメモや、コードスニペット管理には使えそうです。

zshrcが吹き飛んだので、修復ついでに色々整理する

ikuma-t — Sat, 15 Apr 2023 00:00:00 GMT

雑に作業しすぎて zshrc は吹っ飛んだし、雑に管理してたので復帰できなかった

昨日 GitHub Copilot for CLI の順番待ちがようやくまわってきたので設定を.zshrc に追加したんですが、雑にやりすぎて完全に上書きしていました（シェルの再起動をしていなかったので、事態を把握するまでに少し時間がかかった）。

幸い吹っ飛んだのは.zshrc だけで、エイリアス等を書いている別の config は無事だったため、そこまで被害は出なかったのですが、これを機にちゃんと dotfiles もコミットしておこう& ついでに色々シェルを整理しようと思ったので、やったことをまとめておきます。

chezmoi への反映を簡易化する

もともと dotfiles の管理にはchezmoiを使っていたのですが、.zshrc を直接更新した際に、これをどう chezmoi 側のコピーに反映するかがよくわからず、ほったらかしにしていました。

直接更新してしまった場合は、chezmoi addで現在のファイルの内容をそのまま chezmoi 管理下に追加するか、chezmoi mergeで chezmoi 管理下のファイルと現在のファイルをマージするかを選ぶことができます。

Terminal window

chezmoi add ~/.zshrc
# or
chezmoi merge ~/.zshrc # デフォルトではvimdiffが開く

上記は直接編集してしまった場合ですが、基本的には chezmoi 管理下のファイルを更新して apply するのが正しいので、以下手順で反映させます。

Terminal window

chezmoi edit ~/.zshrc
chezmoi apply ~/.zshrc
source ~/.zshrc

ただ毎度これをやるのは面倒臭いので、シェルスクリプト化しておきます。

Terminal window

# moi ~/.zshrc のように呼び出すことで、対象のファイルをchezmoi管理下に追加してapplyし、現在のシェルにも反映する
moi() {
  local target_file=$1
  chezmoi edit $target_file && chezmoi apply $target_file && source $target_file
}

chezmoi には変更を自動でコミット、push する機能もありますが、一応公開リポジトリとしているので自動ではなく手動で管理する方針にしました。

Rust 製の CLI ツールを追加でいくつか入れる

もともとzoxideは入れていたんですが、せっかくなので、いくつかの Rust 製の CLI ツールを入れてみました。

fd: find コマンドの代替
lsd: ls コマンドの代替
- lsを割り当てました。アイコンが表示されるので見やすいです。
delta: git diff を見やすくする
- side-by-side で表示されるので、見やすいです。

おわり

あれ、意外と整理することなかったな？と思いつつ、今回はここまでです。 chezmoi の作成するファイルが結局どういう体系になっているかがよくわからないので、またわかったら追記します。

このブログのRSSフィードを配信できるようにした

ikuma-t — Wed, 15 Mar 2023 00:00:00 GMT

はじめに

RSSフィードを配信できるようにしました。

https://ikuma-t.com/feed.xml からご購読いただけます。

RemixでのRSSフィードの作り方

PRはこちらです。

https://github.com/IkumaTadokoro/site/pull/25/files

もうPR以上に説明することもないのですが、やっていることとしては以下の2つになります。

routes/feed[.]xml.tsxを作成して、/feed.xmlのコンテンツを作成する
RSSフィードを配信するloaderを実装する

おわりに

解説することがなさすぎて、秒でおわりにまでたどり着いてしまいました。

最後にあらためましてチャンネル登録・高評価お願いいたします！

https://ikuma-t.com/feed.xml

登壇資料を掲載するTalksページを作った

ikuma-t — Sun, 12 Feb 2023 00:00:00 GMT

Talks ページを開設した

https://ikuma-t.com/talks

このブログに登壇資料を一覧できるページを作成してみました（追加が終わってないので、まだ全部の資料はないです。順次追加します）。

作った経緯

個人サイトのコンテンツがブログだけってのはなあ…と思ったから
登壇の記事を書くほどでもないけどって時に、雑にメモをかける場所が欲しかったから

LT とか小規模な登壇って、もう資料に載っていることがほぼすべてだからわざわざブログに書くほどでもないことが結構あるんですよね。

一方でちょっとした経緯とかゆるい感想くらいは備忘として残したいなあと思ったりしていました。

個人サイトのコンテンツに個人の発表を載せるのは至極当然であろうということで、登壇の一覧+ちょいメモできるようなページを作ってみた感じです 🤙

お気に入りポイント

特にメモを追記していない場合は、でっかい表紙画像と一言だけが表示され、ちょっと美術品ぽいです。

最近は頑張って効率化に努めているのでスライドの傾向も似通ってきていますが、基本的に同じデザインだとすぐ飽きる人間なので、そのときどきでころころ変わるスライドの傾向を眺めつつ、ちょっとした一言を眺められるこのテイストが気に入っています。

そろそろまた登壇しよう

最近 Slidev で高速にいい感じのスライドを作るためにテンプレートを整備していて、一通りできた（つもり）ので、また今年も外部の勉強会で登壇していきたいです。なんかいい感じのフロントエンドの勉強会あったら教えてください 🙏。

ikuma-t.workからikuma-t.comへ移管

ikuma-t — Sat, 04 Feb 2023 00:00:00 GMT

はじめに

プログラミング勉強し始めて 1 ヶ月くらいの時に初めてお名前.com でドメインを取得し（ikuma-t.work）、それ以降めんどくさくてずっとお名前.com のまま使っていました。

取得した当初も思っていましたが、やはり UX が個人的には辛過ぎる（何か操作しようとするたびに出てくる、やりたい操作から遠ざけようとするモーダルとか）ので、ドメインの更新期限催促が来たこのタイミングで Google Domains に移管することにしました。

.work は Google Domains でサポート対象外

お名前.com から Google Domains にドメイン移管するに則って進めていたのですが、「.work」がサポートされていない…

料金とサポート対象のドメイン末尾 - Google Domains ヘルプ

ikuma-t.works は取れるんですけど、年間 ¥3,500 するので却下です。

ikuma-t.work→ikuma-t.com

というわけで安いドメインを探していたら、ふつうに ikuma-t.com が転がっていたので、これを購入しました。はじめてドメイン買った時、めっちゃ高くて ikuma-t.work にした気がするんですが、今見たらほぼ変わらなかった…。

Vercel 側の設定

設定 > domains > ikuma-t.com を新規追加

Google Domains 側にも設定

5 分くらいで反映完了です。ikuma-t.com でアクセスできるようになったら、Vercel 側の ikuma-t.work の設定は消しておきます。

お名前.com の削除

更新期限が迫っていたのですが、登録していたクレジットカードの有効期限切れで情報が変わったため、自動更新ができていない状態でした（自動更新されていたら乗り換えようと思わなかったかもなのでナイス）。メールはめっちゃ来てるけど…。

というわけで、自動更新さえ停止してしまえばお片付け終了です。

サイトの更新

サイト内に「ikuma-t.work」と書いている箇所が結構あったので、これを置換します。

ページタイトル等も忘れずに変更しておきます。

以上で

おわりに

2020 年から使っていた ikuma-t.work も連載終了です。これからは ikuma-t.com をよろしくお願いします！

Renovateを導入してみる

ikuma-t — Sat, 28 Jan 2023 00:00:00 GMT

はじめに：継続ライブラリアップデートのために…

脆弱性が検知されたり、ちょっと開発環境を改善したい、となって npm パッケージをいざバージョンアップしようと思っても、日常的にアップデートをしていないと期待するバージョンにアップするまでが茨の道デス（諦めたくなることもしばしば）。

dependabot はよく見かけるんですが、最近ではどうも Renovate がいいぞという記事をよく目にするので、今回は Renovate をこのブログのリポジトリに導入してみようと思い、色々と設定を調べてみました。

Renovate の導入

GitHub Apps のインストール

GitHub Apps として公開されているので、以下のリンクから Install します。

https://github.com/marketplace/renovate

必要な項目を入力して、Save。

Complete order and begin installation とかあるので、クリックして進みます。スクショ忘れましたが、このあと導入先のリポジトリの選択が求められるので、対象のリポジトリを指定します。

Configure Renovate

Renovate をインストールしたリポジトリに対して、自動で Renovate 設定のための PR が立ち上がります。

これをマージすると、renovate.json という設定ファイルが作成され、Renovate によるライブラリアップデートが開始されます（PR が作成されるようになる）。

renovate の設定

デフォルトの設定

作成された renovate.json は以下のようになっています。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"]
}

$schema は JSON の定義なのでさておき、extends というプロパティがあります。これは Renovate やサードパーティ・ローカルが公開したプリセットを読み込むためのものです。

config

は renovate が提供しているプリセットであり、具体的には以下の内容が適用されています。

{
  "extends": [
    ":dependencyDashboard", // GitHub Issueとしてrenovateのダッシュボードを作成する。
    ":semanticPrefixFixDepsChoreOthers", // semantic commit messageを見つけたときに、依存関係のあるコミットにはfix、それ以外のコミットにはchoreでコミットする
    ":ignoreModulesAndTests", // node_modules, bower_components, vendorとテスト関連のフォルダ（/__tests__/**とか）を無視する
    ":autodetectRangeStrategy", // アップデート可能なバージョンの範囲に関する設定をautoにする。
    ":prHourlyLimit2", // 1時間に作成できるPRの数を2つに制限する
    ":prConcurrentLimit10", // 同時にOpen可能なPR数を10個に制限する
    "group:monorepos", // 有名なmonorepo構成のパッケージのアップデートを1つのPRにまとめる
    "group:recommended", // monorepo以外でよく使われているパッケージ群のアップデートを1つのPRにまとめる
    "workarounds:all" // アップデートでよくあるワークグラウンドを一挙に適用する
  ]
}

より詳細な説明は下記リンクを参照してください。

カスタマイズの方針（公式 Docs の Key concepts を参考にする）

ベースとして適用されている設定を把握したところで、設定ファイルを自分のリポジトリに合わせて修正していきます。

Renovate の Key concepts

ライブラリアップデート方針はチームの状況や言語のエコシステムに依存するので一概にこうとは言えません。そのため、renovate の Docs にある Key concepts を理解し、その上でチームとして必要な設定を行うのが妥当に思えます。

Key Concepts では次の 5 つのトピックスが紹介されています。

Presets
Dependency Dashboard
Pull Requests
Renovate Scheduling
Automerge

Dependency Dashboard はそこまで設定に重要ではないのて、それ以外を見てみます。

Key concepts: Presets

Presets - Renovate Docs

Presets は先ほどの config

のようなもので、よく使用されるルールをグルーピングしたものです。Presets を使うことで、

いい感じの設定でボットを動かすことができる
設定の重複を避けることができる
他の人と設定を共有しやすくなる（これは Presets を独自に定義することができることから）
他の誰かの設定を利用し、その上でさらに自分用のルールを拡張しやすくなる

と記載があります。ESLint でもできるだけ個別適用は避け、既存のルールを利用するのが良いように、設定の簡易化のために Presets を使用するのが良いと感じました。

具体的には個別のプロパティが表示されている「Configuration > Repository」から設定が必要な値を探すのではなく、「Included Presets」の中から、自分がやりたいことをセットで提供しているルールを適用するのが良さそうです。

Key concepts: Pull Requests

アップデートの PR をグループしない限りは、PR のタイトルやブランチ名は一意になります。

アップデートを見送りたいためユーザーが Close した PR があった場合、次回の renovate bot の稼働時にそのブランチ名と PR タイトルから該当のライブラリのアップデートの PR を検索することで状況をチェックし、同一バージョンでのアップデートの PR を再度送らない仕様です。

ただし「アップデートの PR をグループしない限りは」ということなので、グループ化は例外です。

例えばすべてのメジャーアップデート以外をまとめるグループ化設定を付与した結果、「All non-major updates」というタイトルでアップデート PR が作成されたとします。もし一度この PR を Close してしまうと、次回以降の PR も「All non-major updates」というタイトルであるがために、renovate は PR を作成しません。

そのため、設定時にグループ化を行う際には、そのグループにライブラリアップデートを無視する可能性がないか、グループの粒度は適切かを検討した方が良さそうです。

Key concepts: Renovate Scheduling

カスタマイズの方針がそのまま書いてありました。

Tell Renovate what timezone you want to use

デフォルトでは UTC でスケジュールされているため、ローカルタイムでわかりやすくするには、チームのタイムゾーンを設定した方が良さそうです。

{
  "timezone": "Asia/Tokyo"
}

Learn about the scheduling syntax

renovate のスケジューリングは以下の制約があります

最小単位は 1 時間。分単位のスケジュール実行や、正確な時間での粒度をサポートしていない。
時刻形式はbreejs/laterの形式に則る。
- Parsers

例としてはここら辺が設定できるようです。

every weekend
before 5:00am
[after 10pm, before 5:00am]
[after 10pm every weekday, before 5am every weekday]
on friday and saturday

Optional: configure a “in repository schedule”

先の制約に基づいて時刻を設定します。例では毎日午前二時と一般的な影響時間外での設定が紹介されています。

{
  "schedule": ["before 2am"]
}

{
  "schedule": [
    "after 10pm every weekday",
    "before 5am every weekday",
    "every weekend"
  ]
}

またスケジュール自体にも Presets があるようです。

Schedule Presets - Renovate Docs | Renovate Docs

個人的には月初日の午前 3 時以前が起動範囲の schedule

なんか良さそうな気がしています。

Optional: create packageRules with a custom schedule for specific packages

スケジュールは全体に対するものだけではなく、特定のパッケージに対するスケジュールも指定できます。例では aws-sdk のような頻繁に更新されるパッケージだけ週次実行にするサンプルが掲載されています。

{
  "packageRules": [
    {
      "matchPackageNames": ["aws-sdk"],
      "schedule": ["after 9pm on sunday"]
    }
  ]
}

ライブラリアップデートを自動化して楽にするためのツールがノイズになってしまっては本末転倒なので、更新頻度が予見できるもの・稼働中に気になったライブラリは、独自スケジュールを設定すると良さそうです。

Key concepts: Automerge

renovate には CI がとおった PR を自動マージする機能があります。

ドキュメントでは devDependencies や自動テストがしっかりしている PJ の dependencies であれば自動マージが効果的とありますそりゃそうだ）。

設定例が上がっていたので抜粋します。

lockFile のメンテナンスの自動化（依存関係は崩さずに、lockFile だけ更新する）。

{
  "lockFileMaintenance": {
    "enabled": true,
    "automerge": true
  }
}

Linter の自動化

{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchPackagePatterns": ["lint", "prettier"],
      "automerge": true
    }
  ]
}

非メジャーバージョンの自動化

{
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

自動マージはやや怖いですが、運用の中でチェックが形骸化しているライブラリについては自動マージを検討してもいいかもです。

ここまでのまとめ：Key concepts に合わせた設定方針

簡易化のため各設定については個別に設定するのではなく、できる限り Presets から選択する。
ライブラリのグループ化を検討する際は、そのグループにライブラリアップデートを無視する可能性がないか、グループの粒度は適切かを念頭に置く。
“timezone”でチームのタイムゾーンを指定する。
更新頻度が予見できるもの・稼働中に気になったライブラリは、独自スケジュールを設定する。
運用の中でチェックが形骸化しているライブラリについては自動マージを検討してもいいかも。

カスタマイズの方針（個人的にやれた方がいいことが実現できるか確認してみる）

ここまでは公式の方針に則って汎用的な設定方針を見てきましたが、ここからは実際に個人や仕事で使いたいようなことが実現できるのかを確認していきます。

生成される PR のタイトルを変更したい。リリースノートを PR タイトルで作成するので、フォーマット（タイトル頭にセマンティックコミットメッセージ）をつけたい。

Renovate はベースブランチの直近の 10 件のコミットメッセージを見て、そのリポジトリがセマンティックコミットを採用しているかどうかを判断し、セマンティックコミットがある場合にセマンティックコミットメッセージを採用するようです（おそらくこれが semanticCommits オプションの auto の挙動）。

Semantic Commit messages - Renovate Docs | Renovate Docs

PR では Prefix を採用しているが、コミットまではルール化していない場合にはルールが適用されないので、明示的にセマンティックコミットを使うような Presets を指定します。加えて、セマンティックコミットメッセージのスコープも設定することができるので、チームに必要な形式でそれぞれ以下のように設定すると良いでしょう。

// https://docs.renovatebot.com/presets-default/#semanticcommits
// 結果: chore(deps)
{
  "extends": [":semanticCommits"]
}

// https://docs.renovatebot.com/presets-default/#semanticcommittypeallarg0
// 結果: ci(deps)
{
  "extends": [":semanticCommits", ":semanticCommitTypeAll(ci)"]
}

// https://docs.renovatebot.com/presets-default/#semanticcommittypearg0
// 結果: ci(package)
{
  "extends": [":semanticCommits", ":semanticCommitTypeAll(ci)", ":semanticCommitScope(package)"]
}


// https://docs.renovatebot.com/presets-default/#semanticcommitscopedisabled
// 結果: ci
{
  "extends": [":semanticCommits", ":semanticCommitTypeAll(ci)", ":semanticCommitScopeDisabled"]
}

https://docs.renovatebot.com/presets-default/#semanticcommits

なお commitMessagePrefix や prTitle という指定もあるのですが、前述の通り現状の Renovate が PR タイトルで Close 済みかどうか等を判断しているため、こちらでの設定は推奨されていないようです。

リポジトリ内のあるフォルダ階層より下だけを対象としたい。1 つのリポジトリにフロントエンドとバックエンドが入っていて、フロントエンドだけ Renovate を使用したい。

config

を設定することで、node_modules, bower_components, vendor とテスト関連のフォルダ（/tests/**とか）を無視することができますが、リポジトリにあるそれ以外のファイルはすべてアップデートの対象になります。

ignorePaths を指定することで、無視するパターンを追加することができます。

{
  "ignorePaths": ["**/backend/**", "**/hoge/**"]
}

https://docs.renovatebot.com/configuration-options/#ignorepaths

npm だけを対象にしたい。

{
  "extends": [":onlyNpm"]
}

https://docs.renovatebot.com/presets-default/#onlynpm

メジャー以外の@types は CI が通ったらマージしたい。

{
  "packageRules": [
    {
      "packagePatterns": ["^@types/"],
      "automerge": true,
      "major": {
        "automerge": false
      }
    }
  ]
}

TypeScript はコアすぎるので、手動でやりたい。

{
  "packageRules": [
    {
      "excludePackageNames": ["typescript"]
    }
  ]
}

https://docs.renovatebot.com/configuration-options/#excludepackagenames

Linter 系は 1 つの PR にまとめる

{
  "extends": ["packages:linters"]
}

Presets である”packages

”が次のようになっています。

{
  "extends": [
    "packages:emberTemplateLint",
    "packages:eslint",
    "packages:stylelint",
    "packages:tslint"
  ],
  "matchPackageNames": ["prettier", "remark-lint", "standard"]
}

さらに”packages

”は以下のようになっています。

{
  "matchPackageNames": ["@types/eslint", "babel-eslint"],
  "matchPackagePrefixes": ["@typescript-eslint/", "eslint"]
}

TypeScript プロジェクトの場合、ESLint（eslint と@typescript-eslint）と Prettier がカバーできれば良さそうなので、結果として”packages

”だけの指定で良さそうです。

https://docs.renovatebot.com/presets-packages/#packageslinters https://docs.renovatebot.com/presets-packages/#packageseslint

最低 N 人の Approve が必要でも、オートマージできるか？

https://github.com/apps/renovate-approve

Renovate が提供しているこの Bot を利用することで、最低 1 人の Approve が必要な場合でも自動でマージが可能になるようです。

https://github.com/apps/renovate-approve-2

最低 2 人の Approve が必要な場合は、こちらのボットも追加で導入が必要です。

ラベルをつける

デフォルトではラベルは適用されず、labels を指定することで適用されます。あまり差分はありませんが、1~2 個のラベルを指定できる Presets もあります。単純にラベルを付与するだけであればこちらで良いでしょう。

https://docs.renovatebot.com/presets-default/#labelarg0 https://docs.renovatebot.com/presets-default/#labelsarg0-arg1

{
  "extends": [":labels(dependencies, renovate)"]
}

またラベルはパッケージレベルで付与することもでき、この場合は labels オプションを個別に適用します。

https://docs.renovatebot.com/configuration-options/#labels

以下のようにすることで、eslint 系のライブラリである場合は「linting」が適用されます（ラベルルールはマージされず、最後にマッチしたものが適用される）。

{
  "labels": ["dependencies"],
  "packageRules": [
    {
      "matchPackagePatterns": ["eslint"],
      "labels": ["linting"]
    }
  ]
}

調べていて「へ〜」となった、Pin

「pin の PR を自動マージ」という設定が何箇所かで出てきて、「pin is 何？」と思っていたんですがこれは npm のバージョン固定の話みたいですね。

package.json のチルダ(~) とキャレット(^) - Qiita

https://docs.renovatebot.com/dependency-pinning/

SemVer で package を指定すると、その範囲でのアップデートが発生する。アップデートによりアプリに動作影響があった場合に、前回値と今回値の中のどれかのバージョンが原因になるが、それを 1 つずつ見ていく必要がある。
バージョンを固定（Pin）すれば、上記問題は解決する。一方で Renovate を使用していると固定したバージョン以外はすべて PR が作成されるためノイズになる。
この対応策として Renovate は自動マージを提案する。自動マージに向いているライブラリ/リポジトリの特性は前述の通り。また PR 自動マージでは GitHub の通知がノイズになりうる。これに対しては automergeType を branch に設定すれば、CI が失敗しない限りは PR が作成されずにマージされる。あとは必要に応じてグループ化を行うことも検討されたし。
.lock ファイルを使用しているのに、なぜ依存関係を固定する必要があるのか？
- lock ファイルのメリットは複数人での開発時に同じ依存関係をインストールできる点
- yarn upgrade を一括で実行した場合にはどれが開発ソースに対して影響を及ぼすライブラリの変更なのかわからない。
- もちろん手動で一つずつ上げる手もあるけど、固定しておけば、Renovate 側が個別に実行してくれるので「どのパッケージ」の「どのバージョンが壊れたのか」の推測可能性を保ちつつも、より少ない工数でアップデートを行うことができる。
といいつつも Renovate 自体は”Flexible, so you don’t need to be”というスタンス。

https://github.com/commitizen/cz-conventional-changelog-default-export/pull/4#issuecomment-358038966

こちらも参照とのこと。

最終的な renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:base",
    ":timezone(Asia/Tokyo)",
    "schedule:monthly",
    ":label(renovate)",
    "packages:linters",
    ":onlyNpm",
    ":semanticCommits",
    ":semanticCommitTypeAll(task)",
    ":semanticCommitScopeDisabled"
  ],
  "ignorePaths": ["**/backend/**", "**/hoge/**"],
  "packageRules": [
    {
      "packagePatterns": ["^@types/"],
      "automerge": true,
      "major": {
        "automerge": false
      }
    },
    {
      "excludePackageNames": ["typescript"]
    }
  ]
}

まずはこのブログのリポジトリでこの設定で動かしてみて、問題があればまた追記・修正したいと思います。

おわりに

dependabot より柔軟、されど設定項目が多いという前評判は確かに,,,という感じでした。 CLI 版を使ってローカルで起動することもできるっぽいので色々実験しつつ、仕事で使っている環境にも入れていきたい所存です。

参考

SJISのファイルをFileReaderで読み込む

ikuma-t — Fri, 27 Jan 2023 00:00:00 GMT

はじめに

SJIS の文字コードで表されたテキストファイルを UTF-8 として受け取る実装について、ライブラリを使用した実装の記事が多くあります。有名どころだと iconv-lite や Encoding.js あたりでしょうか。

しかしながら、SJIS to UTF-8 くらいであればブラウザ標準の API で十分対応できたので、この記事で解説します。

結論

ブラウザ標準の API で SJIS で表現されたテキストファイルを UTF-8 として受け取るには以下のいずれかの方法を使用する。

FileReader.readAsText() の第二引数にエンコーディング情報として「sjis」を渡す（reader.readAsText(file, ‘sjis’)）
ArrayBuffer として読み込んだ内容を、TextDecoder で decode する（decoder.decode(‘sjis’)）

ソースコードとデモ

https://stackblitz.com/edit/react-ts-3kwzkx?file=App.tsx

1. FileReader にエンコーディング情報を指定して、SJIS を読み込む

FileReader とは

https://developer.mozilla.org/ja/docs/Web/API/FileReader

FileReader はブラウザ標準で用意されたオブジェクトで、input タグ（type="file")または DnD で指定したファイルの内容にアクセスできます。

// FileReaderのインスタンスを生成する
const reader = new FileReader();

reader.onload = () => {
  // ファイル読み込み時のイベントリスナーを指定

  // FileReaderのインスタンスプロパティ result に読み込みを行った結果が格納されている
  const { result } = reader;
  // ...
};

reader.onerror = () => {
  // 読み取りエラー時のイベントリスナーを設定
};

// ファイルの読み取りを実行する。正常に動作すれば、reader.onloadが発火する。
reader.readAsText(file);

その他の使い方は MDN のドキュメントにまとまっているので割愛します。

FileReader の 4 種類の読み取りメソッド

FileReader にはファイルの読み込み形式によって 4 種類のインスタンスメソッドが用意されています。各メソッドとそのメソッドを使用した場合に result として取得できる形式は次の通りです。

readAsArrayBuffer(): ArrayBuffer
readAsBinaryString(): 生のバイナリデータ
readAsDataURL(): data: の URL
readAsText(): テキスト文字列

FileReader.readAsText でエンコーディングを指定する。

https://developer.mozilla.org/ja/docs/Web/API/FileReader/readAsText

FileReader.readAsText()はデフォルトでは utf-8 でファイル（Blob）を解釈します。そのため、SJIS のテキストファイルをアップロードすると文字化けが発生します。

UTF-8 以外のエンコーディングの文字列を読み込むために、FileReader.readAsText の第二引数にはエンコーディング文字列を指定することができます。

const reader = new FileReader();
reader.readAsText(file, "sjis"); // エンコーディングにSJISを指定

これで SJIS のファイルでも文字化けせずに表示できるようになりました。

この方法には一点注意点があり、それは「誤ったエンコーディングで読み取りを行っても、エラーが発生しない」という点です。

例として先ほど SJIS で読み取るようにした処理を使って、UTF-8 のファイルを読み込んでみると、文字化けが発生します。

この時、console 等にも警告は出ておらず、正常終了したことになっています。

そのため FileReader.readAsText にエンコーディングを指定する方法は 「読み取り対象のファイルのエンコーディングが明らかである」 ときに限り使用すべきです（要件として SJIS しか使わない、別のライブラリを使ってあらかじめエンコーディングを判定しておく、などなど）。

脱線： FileReader の Promise 化

FileReader は上述の通りイベントベースの API です。

const reader = new FileReader();

reader.onload = () => {
  // ...
};

reader.onerror = () => {
  // ...
};

そのため、煩雑な処理が読み込み時にあったり、アプリケーションの複数箇所で FileReader を呼ぶ実装があると、コード行数が膨らんだり、処理の分割が難しくなったりします。

これに対応するために、FileReader 自体を Promise でラップすると取り回しがよくなります。実装例としては次のような感じです。

const readFileAsTextAsync = (file: File): Promise<string> => {
  const reader = new FileReader();
  return new Promise((resolve, reject) => {
    reader.onload = () => {
      resolve(<string>reader.result);
    };
    reader.onerror = () => {
      reject(reader.error);
    };
    reader.readAsText(file);
  });
};

ファイルを読み込む関数の中では次のように呼び出します。

const getFileContent = async (inputFile: File) => {
  const content = await readFileAsTextAsync(inputFile);
  // ... ファイルの中身 content を使った処理 ...
});

脱線： Blob.text()

上述の Promise 化は FileReader がイベントベースの古い API であることに起因したものですが、そもそも Promise を返す API である Blob.text()があります。FileReader で使用している File オブジェクトは Blob オブジェクトを使用しているので、この text()メソッドも使用できます。

const getFileContent = async (inputFile: File) => {
  const content = await inputFile.text(); // Blob.text()
};

https://developer.mozilla.org/ja/docs/Web/API/Blob/text

MDN のドキュメントに差分について記載があるので引用します。

Blob.text() がプロミスを返すのに対し、 FileReader.readAsText() はイベントベースの API です Blob.text() は常にエンコーディングとして UTF-8 を使用しますが、FileReader.readAsText() は Blob の種類と指定されたエンコーディング名に応じて、異なるエンコーディングを使用することができます

単純に Promise 化したいだけであれば、Blob.text()
今回のようにエンコーディングも指定したい場合は FileReader.readAsText()

という使いわけが良さそうです。加えて TypeScript においては、Blob.text()の方が読み込んだ内容の型が string になっているというメリットがあります。

なにをそんな当たり前のことを、と思うかもしれません。しかしながら FileReader のテキスト読み込み（readAsText）と、実際の読み込み完了時のイベント（onload）は実質的にはつながっているものの、静的には関連性がないため、onload 内で取り扱う FileReader.result はstring | ArrayBuffer | nullという型になります（readAsText 以外にも readAsArrayBuffer 等で読み込まれる可能性があるため）。

そのためresolve(<string>reader.result)と、アングルブラケット構文による型アサーションを行う必要が出てくるのですが、まず型アサーションを行いたくないのと、as 構文でもない型アサーションがあまり出てこない形式なので尚のこと使いにくいです。

そのため、個人的には Blob クラスが持っているメソッドを推していきたい派です。

脱線： FileReader 　利用終了後のイベントリスナーの破棄

MDN のドキュメントの中では、

FileReader が使用されなくなったら、メモリーリークを防ぐために removeEventListener() でイベントリスナーを取り外してください。

とありますが、今回の例では不要です。

https://stackoverflow.com/questions/56497788/do-i-need-to-remove-event-listeners-for-filereader-after-im-done-with-it

イベント自体が FileReader からしか参照されていなく、なおかつ FileReader 自体は Promise でラップされた関数の中に閉じ込められています。そのため、そもそもメモリ上に展開されるのが Promise をラップしている関数のみとなり、その関数自体も実行が完了すると GC の対象となるので、イベントリスナーが残り続けることによるメモリリークの可能性はない模様です。

2. ArrayBuffer として読み込んだ情報を、TextDecoder で decode する

ArrayBuffer とは

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer

JavaScript で用意されている ArrayBuffer はバイナリオブジェクトのことです。Array と名前にありますが、いわゆる配列っぽいことはできません（添字アクセスできないとか、可変じゃないとか）。

ArrayBuffer 自体は生のバイナリで、それ自体では何もできません。実際の値を参照するには TypedArray（型付き配列）という view オブジェクトが必要になります。この TypedArray は Uint8Array とか Uint16Array が具体例で、要は生成されたバイナリをどの倍率で見るかが「Uint8」やら「Uint16」やらで表されています。

まあ色々とありますが、人間が読みやすいテキストではなくて単純なバイナリデータっていうのが重要です。

デコード？エンコード？

エンコードはデータを他の形式へ変換すること
デコードはエンコードされたデータを元の形式に戻すこと

です。これからやろうとしていることは、「何らかの文字コードで表されたテキストをバイナリの形式で読み込み、それを特定の文字コード（SJIS）のルールで表されたものであるとして、その文字コードの形式にデコードする」です。

ではデコードはどのように行えば良いでしょうか？

TextDecoder とは

デコードを行うために用意されているクラスが TextDecoder です。

https://developer.mozilla.org/ja/docs/Web/API/TextDecoder

TextDecoder のコンストラクターにはデコード方式を渡すことができます。型定義はこんな感じでした。

var TextDecoder: new (
  label?: string,
  options?: TextDecoderOptions
) => TextDecoder;

label: 有効なエンコーディングを指定
options: デコード失敗時の挙動を決める fatal と、ファイルの BOM に関する挙動を決める ignoreBOM がある。fatal については後述。

「何らかの文字コードで表されたテキストをバイナリの形式で読み込み、それを特定の文字コード（SJIS）のルールで表されたものであるとして、その文字コードの形式にデコードする」

label の部分には、SJIS として解釈したければ「“csshiftjis”, “ms_kanji”, “shift-jis”, “shift_jis”, “sjis”, “windows-31j”, “x-sjis”」のいずれかを、UTF-8 として解釈したければ、「“unicode-1-1-utf-8”, “utf-8”, “utf8”」を（もしくはデフォルト値なので何もしていない）それぞれ設定すればいいということになります。

ArrayBuffer として読み込んだ文字列を TextDecoder で encode する

さきほどの FileReader の例では FileReader.readAsText でテキストとしてファイルを読み込みましたが、今回は ArrayBuffer としてファイルを読み込みます。

このとき、FileReader の同様の API である readAsArrayBuffer を使っても良いのですが、Blob.text()同様、Promise ベースの Blob.arrayBuffer()が用意されているので今回はこちらを使用します。

const getFileContent = async (inputFile: File) => {
  const buffer = await inputFile.arrayBuffer(); // ArrayBufferとして取得される。
};

読み込んだバイナリ文字列を SJIS としてデコードします。デコードするためには、TextDecoder の decode メソッドを利用します。

const getFileContent = async (inputFile: File) => {
  const buffer = await inputFile.arrayBuffer(); // ArrayBufferとして取得される。
  const sjisDecoder = new TextDecoder("sjis");
  return sjisDecoder.decode(buffer);
};

補足： TextDecoder の fatal オプション

ここまででの実装では、UTF-8 のファイルを渡した場合に、文字化けが発生します。が、これは本来望ましくない結果ですよね？

TextDecoder のコンストラクターに指定できる fatal オプションを true にすると、読み込んだバイナリと指定した label が異なるエンコーディングであった場合に、TypeError を起こすことができます。

export const blobReader = async (inputFile: File) => {
  const buffer = await inputFile.arrayBuffer();
  const utf8Decoder = new TextDecoder("utf-8", { fatal: true });
  const sjisDecoder = new TextDecoder("sjis");
  try {
    return sjisDecoder.decode(buffer);
  } catch {
    try {
      return utf8Decoder.decode(buffer);
    } catch (e: unknown) {
      if (e instanceof TypeError) throw e;
    }
  }
};

少々ネストは発生しますが、これにより SJIS で読み込めない場合は UTF-8 で読み込む、というような挙動ができます。もちろん多段 try-catch は厳しくなるので、文字コードを幅広く持つ場合はライブラリ等で文字コードを判定してから処理を行うのが無難でしょう。

おわりに

標準でできるなら標準でやるのが一番いいと思うんですよね〜（依存ないし、ファイルサイズ的に軽いし）。最近の dialog 然り、Web でよくやることはブラウザ側が汲み取って来てくれている印象なので、ライブラリに頼る前に標準でいけないか確認していきたいところです。

Gitでマージをdry-runする

ikuma-t — Fri, 13 Jan 2023 00:00:00 GMT

はじめに

大きめの作業内容なのでトピックブランチを作っていたのですが、作業内容の大きさゆえに時間がかかってしまい、実際に main にマージする際に「果たしてこのブランチをマージして、デグレとかしないか？コンフリクト出てないからたぶん大丈夫だけど…」となりました。

git merge コマンドの--no-commitオプションを使用すると、実際に発生する差分をチェックすることができて便利だったのでメモしておきます。

結論

ローカルのブランチで

git merge --no-commit --no-ff ブランチ名

内容に問題なければ

git commit

すると、マージコミットが作られる（FastForward でも作られるので、こだわりがある場合は以下の abort で中止して、再度 git merge するのが吉）。

やっぱりこれマージしたらあかんわ、ならば

git merge --abort

これでマージのチェックのために一時的に追加されていたステージングエリアが元に戻る。

使用しているオプション

—no-commit

マージコミットを作成する直前に停止し、コミット内容を精査するためのオプション

—no-ff

--ffだと FastForward。つまり、一直線上にある場合にマージコミットが作成されない。
その反対でどんな関係にあろうとも、マージコミットを作成するオプション

—abort

マージ作業中の場合に、作業を中断してマージ前の状態に戻すためのオプション

参考

scaffdogでブログのテンプレートを作成できるようにした

ikuma-t — Tue, 03 Jan 2023 00:00:00 GMT

ブログの執筆コストを下げたい

ブログを書くハードルを下げたかったので、scaffdog でフロントマターまで入力した状態で作成できるようにしました。

このブログはリポジトリ内に蓄えたマークダウンファイルを変換して表示しており、メタデータは各ファイルの YAML フロントマターで定義されています。こんな感じですね。

---
title: "個人サイトをAstroで作り替えました。"
description: "もともと Next.js で個人サイトというかブログを作って運用していたのですが、これを Astro に置き換えました。理由としては巷でよく言われているところで、個人ブログ程度には Next.js は too much だったからです。..."
publishDate: 2023-01-03

layout: "@layouts/BlogLayout.astro"
tags: [astro]
---

で、こういうのは入力が面倒なので、前作のブログではどこからでもブログが作成できるように Deno を使ったオレオレブログ CLI を作成していたのですが、GitHub Codespaces 上で作業を行うことで作業ディレクトリの縛りがなくなったため、今回は scaffdog でやってみました。

scaffdog の導入

Terminal window

# インストール
npm install scaffdog

# 初期化（ここではpostという名前でテンプレートを作った）
npx scaffdog init

作成されたテンプレートに次のように記載しました。

---
name: "post"
root: "."
output: "src/pages/blog"
ignore: ["."]
questions:
  fileName: "ファイル名"
  title: "タイトル"

  tags: "タグ（カンマ区切りで複数指定）"
---

# `{{ inputs.fileName }}.md`

```markdown
---
title: "{{ inputs.title }}"
description: ""
publishDate: "{{ date('YYYY-MM-DDTHH:mm:ss') }}"
 inputs.category }}"
layout: "@layouts/BlogLayout.astro"
tags: [{ { inputs.tags } }]
drafts: true
---

## TOC
```

入れ子になっているのでわかりにくいですが、markdownのコードブロックで囲まれている部分が自動生成対象です。

ほとんどの項目はフロントマターで定義した質問の回答（inputs.xxx）をそのまま埋め込んでいますが、日付だけはビルトインのdate関数で現在日付を設定しています。

あとは npm scripts として次のようなコマンドを入れてあげれば準備 OK です。

"scripts": {
    "gen": "scaffdog generate post"
}

動作イメージ

Terminal window

$ npx gen

ℹ Output destination directory: "src/pages/blog"
? ファイル名 create-blog-template
? タイトル scaffdogでブログのテンプレートを作成できるようにした
? カテゴリ ブログ
? タグ（カンマ区切りで複数指定） scaffdog,blog

🐶 Generated 1 file!
     ✔ src/pages/blog/create-blog-template.md
Done in 39.86s.

そんで出来上がったのが、この記事というわけです ✌️

個人サイトをAstroで作り替えました。

ikuma-t — Tue, 03 Jan 2023 00:00:00 GMT

Astro でリプレイス

もともと Next.js で個人サイトというかブログを作って運用していたのですが、これを Astro に置き換えました。理由としては巷でよく言われているところで、個人ブログ程度には Next.js は too much だったからです。

候補としては他に STUDIO を使ってノーコードでやってしまうということも考えていたのですが、やはり個人サイトの運用コストを気にしたくはなく、そうなると CMS がいずれ有料になってしまうのは良くないなと思い、結局自前で実装した次第です。

Astro での開発体験

めちゃめちゃ快適でした。さすがサイトを作るなら Astro でよくね？と公式で言っているだけありますね。Next.js でやると、地味に Markdown の変換部分でプラグイン選定とかがあったりして面倒だったのが、Astro だと全く意識せずにできるという点がグッジョブでした。

ざっと公式のドキュメントを読んで…っていうのを数ヶ月前にやり、それらの内容を忘れたお正月休みの 1 日で出来上がるくらいなので、基本的に直感的に開発できたかと思います。

Markdown コンテンツのスタイリング(tailwindcss-typography)

https://github.com/tailwindlabs/tailwindcss-typography

今回使用したテンプレートが Tailwind でスタイルをおこなっているものだったのですが、記事部分に以下のような指定しかなく、はじめは「どうやってスタイリングしているんだろうと思いました。

<div class="mx-auto prose prose-lg mt-6">
  <slot />
</div>

このproseというプロパティが肝で、これは tailwindcss-typography というプラグインから提供されているものです。

https://tailwindcss.com/docs/typography-plugin

なんとこれを追加するだけで、HTML 部分のスタイリングをいい感じにやってくれるやつだそうで、上記のコードブロックもこのプラグインがよしなにやってくれています。すげー。

今後は

ブログ以外のコンテンツ拡充
Codespaces を用いて ipad でもサクッと記事を更新可能に
MDX タイプの記事の作成

あたりをやっていけるといいかな〜と思っています。

Kaigi on Rails 2022で登壇しました！

ikuma-t — Sat, 22 Oct 2022 08:44:00 GMT

Kaigi on Rails 2022 で登壇しました！

10 月 21 日、22 日に開催された Kaigi on Rails 2022 に Speaker として登壇しました！

Kaigi on Rails 2022

初のカンファレンス登壇で順番最後、かつギリギリまで準備が終わらず、最後の最後までずっとソワソワして参加者としてはガッツリは参加できなかった（アーカイブ見るぞ）のですが、とてもいい経験ができました！運営の皆さん本当にありがとうございました！

登壇資料はこちらです！

登壇資料

せっかくなので自分の発表についてつらつらと書いていきたいと思います。

登壇へのモチベーション

スライドにもあるとおり、FJORD BOOT CAMP での学習期間を経て、今年の 6 月からエンジニアとして働き始めています。

FJORD BOOT CAMP

で、やっぱりエンジニアになったからにはカンファレンスとか登壇してみたいわけですね。学び初めの時は「地域 rb に顔出すのは上級者」くらいの気持ちだった人がそう思っているのは、完全に FJORD BOOT CAMP にいた影響だと思っています。

なんか知っている人結構いるし、卒業生の中から RubyKaigi に登壇している人もいるし、じぶんもやってみたい！と自然に思えるようになっていました。

登壇テーマの選定

今回はブラウザ自動化技術を登壇テーマに選んだんですが、理由としては 2 つありました。

ブラウザ自動化を便利に使っていたが、その中身はよく知らないままだなと思っていたので、その中身を知りたかった
もともとブラウザ自体に興味があった

1 つ目は発表にあった通りで、2 つ目については Web アプリを作る以上ブラウザに載せることがほとんどなので、そこをちゃんと知りたいなあという思いです。

昨今では CSS フレームワークとかもよくできているので、見栄え的にはあまり考えなくてもまあまあ綺麗なものができるのですが、でももうちょっとブラウザ自体を知らないとブラウザの真価を発揮したりとかセキュリティ意識したりとかいろんな環境を意識して作るとかできないよなあと。

動きを把握する時にはやっぱり実際に動きが始まるところから見るのがわかりやすいと思うのですが、ブラウザ自動化は自分が知っている領域でもあり、ブラウザに対するエントリポイント的な位置付けなので、今回はここにフォーカスしようという気持ちもありました。

近いうちに簡易なレンダリングエンジン実装とかやってみたいですね（Olelink とか OleKit とかですかねえ）

準備

実際に WebDriver や CDP を読んでいく

発表ではわりとさっくり「意外とシンプルに接続できる」という流れで紹介していましたが、当然のごとくミリしら状態で仕様を見始めたので、なかなかうまくいかず苦労しました。

資料の中で「Capabilities」や「WebSocket」が用語で 1 ページとってありますが、これは実際に試している中で「なんだこれ」とか「いまいちわからん」と詰まった箇所です（ActionCable ちゃんと使ったことないのがバレた）。

例えば WebSocket の接続をする際にも WebSocket 自体の理解が曖昧で、最初は色々と回りくどい方法で URL を取得していたのですが、Ruby の CDP クライアント ferrum のソースを読んでいる中で「あ、サブプロセスで起動した Chrome の標準出力を正規表現で抽出して、WebSocket の URL 取得しているじゃん、これでええやん」と理解し、発表のような説明となりました。先人偉大なり。

https://github.com/rubycdp/ferrum/blob/efb6f2035c442582e815328e633d1f1d6c97e456/lib/ferrum/browser/process.rb#L99-L102

大変といえば大変だったんですが、その分色々と自分が知らない知識も増えて面白かったです。例えば上記箇所だと ObjectSpace.define_finalizer を知ることができました（一人 igaiga ふむふむタイム）。

https://twitter.com/igaiga555/status/1569154474060705792

ObjectSpace#finalizer

chromedp/pdlgen の実装を読むのが大変だった

なにが大変だったって、Go の文法を一切知らない状態から始めたのもあるんですが、chromedp で CDP をパースしているライブラリの最新ブランチが master じゃなくて old だったことなんですよね 😅

自分のローカルに Clone して chromedp/pdlgen を実行した時に panic になって落ちてしまいました。 Go の知識が乏しく「自分の環境が悪いってことかな」と思って何日か文法調べつつ読んでいき、最終的に一部分岐で落ちていることがわかったため、Issue で報告しようとしたタイミングで同じ事象の Issue があることに気が付き…

https://github.com/chromedp/pdlgen/issues/16

I guess its required to use the old branch?

Yes, the old branch is the latest branch.

old ブランチにしたら動きました 😅

実装：Olaywright の実装で頭ごっちゃに

CFP 提出時点で Olenium は動くものができていたので、上記の調べ物をしたのち、Olaywright の実装に取り掛かりました。

が、この辺りで「フロントエンドエンジニア」となったため、仕事前には Ruby 書いて業務中は TypeScript だけ書いてて、仕事終わったら Ruby 書いて…となり、地味に大変でした。マジで何回 const で変数定義して、const がなくて怒られたと思っているんだ？（===もめっちゃやったなあ）

まあそれくらいならまだいいんですが、オブジェクトに対する考え方が完全に JavaScript に引っ張られていたのが一番大変でした。今回の発表では JSON をパースして、Ruby のメソッドとして呼び出せるようにしていましたが、そこです。

縛りなしで、個人的にもっとも実行しやすいインターフェースを考えると、たとえば Target.createTarget という CDP のメソッドはtarget.create_target(url: 'https://google.com')という形で呼べるのが Ruby っぽくかつシンプルで分かりやすいと考えました。

で、これを静的に定義しておこうと思ったところで頭がこんがらがります。

Chrome へのメソッド実行は、実際のところメソッド名をただメッセージに渡すだけ。つまりメソッドの中身がないので、わざわざあらかじめ定義しておく意味があまりない。
JSON で落ちてきた CDP には、そのメソッドに関する説明が多分に入っており、それをすべて削除するような構造になってしまう。 target.create_target()がメソッドだとすると、CDP でやってくる「Target.createTarget の説明」や「Target.createTarget は experimental かどうか」といった情報をtarget.create_target.description、target.create_target.experimental?のように持たせるのが難しい（私がわからなかっただけなので、できたらどこかで教えてください〜〜！）

さらにめんどうなことに

Go の方読んでたら構造体が出てきてクラスが歪み始める
一日の大半は TypeScript を書いているので、またまたオブジェクトに対する認知が歪み始める

となり、かなりの日数手が止まったあげく最終的には以下のような方針・実装になりました。

やっぱりtarget.create_target.descriptionとかtarget.create_target.experimental?とか呼び出せると嬉しい（なお boolean を返すメソッドには Ruby ライクに「?」つけたかったのですが、忘れていたので実際のコードではやっていないです。）
WebSocket へメッセージを送信する部分以外は振る舞いではなく、単なる情報（説明とか実験的機能だとか任意のパラメータだとか）の集まりなので、Struct でいいんでは？
JS の Function オブジェクト的な感じで格納できればなおのことよかったんだけど、それは Ruby ではできない（？）ので、Struct のプロパティの中で他の情報と並列にexecというプロパティを保持し、ここに Proc オブジェクトを持たせる形で定義する
- Sturct のメソッドとして定義すりゃよかったんですが、Olaywright クラスで持っている WebSocket の接続情報のコンテキストを渡すのがさっとできなかったので、呼び出しが Proc の呼び出し（exec[]）になったわけです。
愚直によぶとbrowser.domains.page.navigate.exec[url: 'https://google.com']のような長さになる。これは嫌だ。
というわけで最終的に必要な Domain の情報を一行パターンマッチでキャプチャすりゃあええやろ（browser.domains in { page: }）

https://gist.github.com/IkumaTadokoro/26e08130f849c9aac8c4b18a1adc7561

かなり頭の中で考えるのに時間を使ってしまって、ちょっと前髪整えますねくらいのリファクタリングはしたんですが、そこまでで力尽きてインスタンス生成に 3 秒かかるプログラムになりました 💦 どう考えてもループしすぎですね、どうもありがとうございました。

実装：Gem 使うかどうか

String#underscoreを refinement で拡張しているところとか別に ActiveSupport 入れてもよかったんですが、ライブラリ使わないでも Ruby 本体だけで欲しいもの書けるんだ！っていう思いも発表にこめたかったので自前で定義しています（発表では見せませんが）。

じゃあなんで WebSocket はライブラリを使っているかというと、この Gem の管理を現在やっているのが運営のうなすけさんだったので、何か選考に有利に働いてくれないかなあと思い、CFP の時点でこの Gem を使うということを明記したという経緯でした笑

https://rubygems.org/gems/websocket-client-simple

名前の通りめちゃくちゃシンプルでコードも読みやすいので、想定聴者がジュニア〜中級くらいのこの発表の筋にもあっている気がして、WebSocket の中でもこの Gem にしたというのもあります。

websocket-client-simple のコードを読む過程で EventEmitter について知り、一人ターミナルチャットアプリやってました。勉強にはなりましたが寂しかったです。

なんで irb で動かすことにしたの？

苦肉の策で上記の通り多段 Struct をやった結果、Olenium 同様にスクリプトを書いても全然補完が走らず、これはどうしたものかと思ったところ、「irb 上でインスタンス化した後なら補完走るじゃん！！」と思い立ちこうなりました。いやあ irb 便利。

ちなみに補完が走る際に、Struct ではセッターの方のメソッドも補完が走ります。これはスクリプトを動かす際には使わないのでどうにか消したかったんですが（freeze はしているけど）やり方わからず断念しました（Struct のサブクラスに対して、これ呼べないですよね？できるのであれば教えてほしいです〜〜）。

Olaywright.usage

こうやって作っていく上でもう Playwright の面影なぞ全くないに等しかったので、もう好き勝手やろうと思って追加しました。

def self.usage
  puts <<~USAGE
    ○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●
       ____  __                          _       __    __
      / __ \/ /___ ___  ___      _______(_)___ _/ /_  / /_
     / / / / / __ `/ / / / | /| / / ___/ / __ `/ __ \/ __/
    / /_/ / / /_/ / /_/ /| |/ |/ / /  / / /_/ / / / / /_
    \____/_/\__,_/\__, / |__/|__/_/  /_/\__, /_/ /_/\__/
                /____/                /____/
    ○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●○●
    ┌─────────────────────────┐
    │   What is Olaywright?   ├────────────────────────────┐
    └┬────────────────────────┘                            │
     │  "Ole no" Playwright.                               │
     └─────────────────────────────────────────────────────┘
    ┌─────────────────────────┐
    │       Basic Usage       ├────────────────────────────┐
    └┬────────────────────────┘                            │
     │ # Setup                                             │
     │ browser = Olaywright.new                            │
     │ browser.domains in { page:, target: }               │
     │                                                     │
     │ # Exec Command ex) Target.createTarget              │
     │ # Notice: Use snake_case. You're in Ruby world.     │
     │ target.create_target.exec[url: 'https://google.com']│
     └─────────────────────────────────────────────────────┘
  USAGE
end

これは Monodraw というツールで描いてみました。

https://monodraw.helftone.com/

GitHub の人が ER 図をアスキーアートで書いてコミットメッセージに貼ることがあるという記事を見かけて、なるほどお！と思ったのをきっかけにインストールし全然違うきっかけで使ってしまいました。非常に便利なので今後も活躍しそうです。

資料作成

今回の資料、再掲部分も結構ありますが、合計で 78 枚となっています。自己最多量です。

カラーパレットとコンポーネント

作成は Figma で行なっていたのですが、調査とか実装が煮詰まった時にカラーパレットとコンポーネントを作成していたのが、直前になって非常に役に立ちました。

今回は背景色に真っ白を選択しました。今年の Kaigi on Rails のテーマカラーが大人ダークな色だったので、Youtube に載せた時に画面共有の枠が目立つように白にしたという感じです。

フォント

フォントに関しては今回は 3 種類をミックスしていて

Noto Sans JP
New Rodin Pro
Montserrat

を使用しています。これまではコーポレートロゴ ver2 とかラグランパンチとか奇抜なフォントを使っていたのですが、今回は時間も長いのとカンファレンスなので、読みやすいフォントにしました。

コード部分

コードを掲載する部分も結構あったのですが、これには Figma の Code Syntax Highlighter プラグインを使用しています。

生成されたものをちょっとだけ加工して、角丸を作ったりしています。

表紙について

あと、最後にほんとどうでもいいところなのですが、表紙に載っている丸は実は点字になっています。

発表練習

資料ができたのが、本番二日前の遅い時間だったので、通しでの練習を始めたのは発表の前日。そのため、1 日目は要所要所でしか発表が聞けず残念でした 🥲

今回すごい当たり前のことに気がついたんですが、30 分の登壇って通しで練習すると 30 分かかるんですよ…。なので 2 回練習すると 1 時間とぶ。なので、セクションごとに目標時間決めて各セクション単位で練習し、早口で喋ればぎりぎり時間内におわることは計測できたので、2 日目は普通に楽しみました。

本番の時間オーバーだけは避けなければならなかったので、とにかく「とまるんじゃねえぞ」で早口でしゃべっていたらなんと巻きで終わりました。あらら笑

感想

今回 CFP 提出にあたり、業務経験値的には話せるものはあまりないのでソフトトークに踏み切るという選択肢もありましたが、職業エンジニアになった以上、今回は絶対技術系の話をメインにしたいという思いが強くありました。

「スパイス的にソフトトークを混ぜる感じにするといいかも」と CFP 考案中にレビューをいただいたので技術 9

1 くらいの構成にしましたが、ちゃんと技術メインで話せたこと、話を構成していくその過程で業務とは直接関係ない知識をじっくり読み解いていき、それを自分の言葉に落とし込んでいく過程を締切つきでやれたのは非常によかったと思っています。

また CFP を出すこと自体も勉強になりましたし、カンファレンスで話すというのがどういう準備が必要なのかというのも今回知ることができました。

一方で Olaywright のコードを書く部分で技術力的な脆さを感じたり、資料デザインも使える引き出しの数に限界を感じている部分もあったので、そこは今後の課題としてやっていこうと思います。

今は仕事で Ruby を書いていないですが、今後も Ruby 関連のイベントには参加していきたいと思いますし、あとは今回カンファレンス登壇をさせていただいた経験を糧にフロントエンド関連のカンファレンスも登壇挑戦していきたいです！

謝辞

今回 CFP を出すのも初めてだったので、チーフオーガナイザーの大倉さんには Grow.rb を通じて 2 回相談にのっていただきました。1 回目の時にはまだテーマも決まっていない状態で、2 回目の時には技術トークとソフトトークをどれくらいの割合にするかの方向性についてなど相談させていただきました。

当初は自分の発表で 30 分も話すのは…と思っていたのですが、「話したいことがあるなら 30 分でもいいと思う」とアドバイスをいただけたおかげで今回の発表につなげることができました。

この 1 回目の Grow.rb ではうなすけさん、ima1zumi さんに実際に RubyKaigi に提出した CFP を見せていただき、どういうふうに CFP を書いていくべきかについて非常に参考にさせていただきました。おかげさまでしっかりと CFP を書ききることができました。

会社の開発チームの方も CFP 提出前にレビューいただきありがとうございました！

運営の皆さんも準備から当日までありがとうございました 🙇‍♂️ 来年はハイブリッド開催とのことで非常に楽しみです！ではでは！

type-challenges 21日目: Trim Left

ikuma-t — Mon, 12 Sep 2022 00:00:00 GMT

久しぶりのチャレンジ

問題

https://github.com/type-challenges/type-challenges/blob/main/questions/00106-medium-trimleft/README.md

文字列を受け取り、その文字列の左側の空白を削除した新しい文字列を返すTrimLeft<T>を実装する。

解答

Template Literal Types

typescriptlang.org/docs/handbook/2/template-literal-types.html

Template Literal TypesはJSのテンプレートリテラルと同じ記法で特定の形式を満たす文字列リテラルを型として定義することができます。

解答

type space = ' ' | '\n' | '\t'
type TrimLeft<S extends string> = S extends `${space}${infer L}` ? TrimLeft<L> : S

ObjectSpace.#define_finalizer

ikuma-t — Sun, 11 Sep 2022 00:00:00 GMT

ソースリーディングしているGemの中で、接続開始したタイミングでセッションをkillするスクリプトがあったのをきっかけに調べた。

https://docs.ruby-lang.org/ja/latest/method/ObjectSpace/m/define_finalizer.html

class Foo
  def Foo.callback
    proc {
      puts 'bar'
    }
  end

  def initialize
    ObjectSpace.define_finalizer(self, Foo.callback)
  end

  def hoge
    puts 'hoge'
  end
end

Foo.new
Foo.new.hoge

Terminal window

$ ruby define_finalizer_sample.rb

hoge
bar
bar

そのオブジェクトが解放されたタイミングで実行される処理を登録することができる。読んだソースの中では、先の通りセッションを開いたタイミングで対象のpidを指定してセッションのkillを予約している構造になっていた。

Tailwind CSSのimportant

ikuma-t — Sun, 04 Sep 2022 00:00:00 GMT

Tailwind CSSにはimportantという属性を指定できる。

module.exports = {
  important: true,
}

これを指定することで、Tailwindのユーティリティクラスが!importantとして読み込まれるようになる。

type ImportantConfig = boolean | string

https://tailwindcss.com/docs/configuration#important

Tailwind CSSの型定義を参照すると、値としては公式ドキュメントに記載があるbooleanの他にstringも指定できる。

これも公式ドキュメントに記載があるが、important: trueとすると、MUIのようなインラインスタイルを要素に追加するライブラリとTailwindが競合する可能性がある。そこでimportant: #appのように、ID Selectorを値として指定することで、importantの適用範囲を限定することができるのだそう。

https://tailwindcss.com/docs/configuration#selector-strategy

やせた（2022-08）

ikuma-t — Tue, 23 Aug 2022 00:00:00 GMT

自分でもびっくりしたんですけど、ここ3週間で4kg痩せました。

原因は食生活とリングフィットをサボっていることだと推測しています。

まず食生活なのですが、季節の野菜を味噌汁でいただくスタイルが多くなりました。

最近鍋を変えたり、奥さんがシンプルな暮らしをしたがっていたり等々あり、このスタイルになったと記憶しています。

https://www.vitacraft.co.jp/lineup/oregon/

ビタクラフトのおかげなのかわかりませんが、まあ味噌汁がとても美味しいこと。この前心地の良い風が吹いた日にさつまいもときのこで作った味噌汁は、秋を感じさせて最高でした。

ちなみに出汁はこれを使っています。

https://kuzefuku.com/?page_id=13&eci_product=fsh02536

もともとめちゃくちゃな食生活はしていなかったのですが、野菜が多くなったので脂肪がつきにくくなったのかなと思ってます。

次にリングフィットについて。こちらは転職直後は毎朝やっていたのですが、いかんせん業務外でコード読んだり勉強したり、ゲームしたりで時間がなくなったのでやめました。

筋肉量が減ったので、その分の体重も落ちたと思われます。

おわり

社内イベント開催を支える技術

ikuma-t — Fri, 19 Aug 2022 00:00:00 GMT

社内イベントで司会をやった

先日社内のイベントがあり、スタッフの一人として司会をやりました。

今までオンラインのイベントを回したことがなかったので、今後自分が再度イベントの司会をやるときや他の人が参考にするときようにメモを残しておきます。（ツールの使い方的な話で、話術の話はしないです）

前提

イベントはGatherで実施します。

社内イベント開催を支える技術

オープニング・クロージングのスライド作成

何の変哲もないFigmaで作ったスライドをただ流しているだけだったのですが、素材の入手場所が増えたのでそこだけ。

今回はライトなイベントだったので、アイソメトリックな画像にしようと思ったんですが、そのときに以下のサイトを利用しました。

https://www.manypixels.co/gallery

検索で「Types」を「Isometric」にすると色々出てきます。あとは適当にFigmaで繋げて完成です。

Gatherの会場設営技術

今回はGatherのスペースの中で開催場所が事前に決まっていたため、ロケを敢行して障害点をチェックし排除しておきました。やったことは次の4つです。

環境音を発生させるアイテムを事前に削除
Privateスペースを拡張
Spawnを指定して当日の案内を省略化
看板を設置して低コストでイベント会場化

前提としてMapMakerの権限を持っている必要があります。

1. 環境音を発生させるアイテムを事前に削除

Gatherには配置すると音が出るオブジェクトがいくつかあるのですが、開催場所にもこれが置いてあったため削除しました。

設定から音量をなくすこともできるのですが、Gatherに慣れていないユーザーもいるので根本ブレイクです。（Gatherに慣れていない時に波の音がする場所で打ち合わせしてて、マジで内容聞き取れなかったことあるマン）

2 ~ 4の全体像を先に示しておきます。

2. Privateスペースを拡張

Gatherは通常ある程度近くにいないと音声が聞こえない仕組みで、複数人で話すにはPrivateスペースを用意する必要があります。

事前に確認したところ全員が集まれるだけのスペースがなかったので、これを拡張しました。

なお、先ほどの図では別のPrivateスペースと重複していますが、こうなるとそのPrivateスペースに入ってしまった場合、周りの音声が聞こえなくなるので、実際にはこれらを削除した上でイベント用のPrivateスペースを展開しています。

3. Spawnを指定して当日の案内を省略化

今回のGatherのロケーションはログインすると直接いける場所ではなかったので、Gatherに不慣れなメンバーにはややハードルが高いです。

なので当日になって「ここからいけますよ」みたいな案内をしたり、迷っている人がいないかチェックしたりする必要があるのですが正直これは面倒。

GatherにはSpawnという場所に対してリンクを貼る機能があり、これを使って案内を省略しました。

あらかじめユーザーを遷移させたい場所にMapMakerの「Tile Effects」からSpawnを設置した上で、通常の画面からイベント作成を開き、このリンクをコピーします。すると、このリンクでGatherに入った場合開始位置がSpawnで設定した場所になります。（実際にはここでイベントを作ればいいのですが、今回は別の方に事前にカレンダー登録をしていただいていたので、リンクだけコピーしました）。

4. 看板を設置して低コストでイベント会場化

画像のとおりです。仕事の合間に準備やってたので、一からマップを作る気にはならず、とりあえずオープニング用のスライドを画像化して適当に貼りました。

超低コストの割に「何をやっているのかわかりやすい」という意見があり、これはいいかもと思っています。

OBSによる配信技術

当日はイベント感を出すためにただ画面を共有するのではなく、ちょっと加工したものを共有していました。

画面切り替えと司会業を同時にやるとタイムマネジメントが難しいので、逆転の発想で時計を画面に配置し、この問題を解消すると共に200%のLIVE感の演出に成功しました（当社比）。

https://obsproject.com/ja/download

配信にはOBSを利用してます。

構成

各種素材をシーンとしてあらかじめ構成しておき、OBSのスタジオモードで切り替えています。

当日はPCとモニターの2画面で、アフタートークに備えてSlackと登壇者トークを見つつ、配信切り替えを行なっていたので全画面表示は厳しく、仕方なしに番組の方を「ウィンドウプロジェクター（番組）」で配信しました。これで、バックグラウンドでこのウィンドウを画面共有しつつ、画面を自由に使うことができます。

素材

時計に関しては以下のものを拝借しています。

https://booth.pm/ja/items/2912843

それ以外はOBS標準の「色ソース」や「テキスト」、ブラウザやPDFが素材です。

シーンをあらかじめ作っておく

イベントの構成としてゲストトークを3本やる形式だったので、画面構成はほぼほぼ同じです。そのため、シーンは1つでテキストを都度変更するという手段を最初は考えていました。

しかしながら、先の通り当日はだいぶ慌ただしいと想像できたので、ほぼ同じ画面構成でも別途シーンを作っておきました。結果としてこれは正解でした😅

合わせ鏡にはご注意を

OBSやGatherに限った話ではありませんが、共有している画面を配信してしまうと、無限に共有している画面が映り込んでしまうのでそこにだけご注意を。

OBSによる録画技術

OBSには標準で録画機能が備わっているので、先の構成で番組として配信しているものを録画することができます。

画面としては大丈夫なのですが、音声側に1点問題があります。そのまま録音すると、自分の声は録音できるもののGather上で話している他の人の声が録音できません。

これを回避するために、Background Musicというアプリを入れました。

https://github.com/kyleneideck/BackgroundMusic

Background Musicを使うことで、システム側で流れている音声を横取りすることができます。つまり

【Before】「システム音声（他人の声）」→「スピーカー」
【After】「システム音声（他人の声）」→「BackgroundMusic」→「スピーカー」

という構成に変更できるわけです。耳ではスピーカーの音声を聞きつつ、OBSには別途Background Musicをソースとして渡すことで、リアルタイムで音声を聞きつつの録音が可能になります。

OBSでは音声ソースを複数指定することができるので、一方を自分のマイク、もう一方をBackground Musicにして対応しました。

感想

オンラインイベントは自分からはOKに見えても、他の人は見えていなかったり聞こえていなかったりします。

今回は同じ開発チームのメンバーに「事前確認したいことあったら協力するんで言ってください！」と言ってもらえたおかげで、万全の状態でオペレーションに臨めました。ありがとうございます😊

いやあYoutuberとかって結構大変なんだなあと今回実感しました。なんかもう少しうまいことできる方法があったらまたブログで共有します。

esbuildのGASテンプレート

ikuma-t — Sun, 31 Jul 2022 00:00:00 GMT

GAS作成用のテンプレートを作成した

https://github.com/IkumaTadokoro/esbuild-gas-template

社内の業務改善とか自動化でたまにGASが出てくる場面があるそうなんですが（自分はまだ一度も書いていない）、GASのエディタで書くとnpmが使えなかったり、TypeScriptが使えなかったりします。

GASで業務効率化できるのは良いことなんですが

普段と異なる環境でコードを書くのはストレスが多い
生JavaScriptを書く機会は業務のコードではほぼないので、GASのためだけにJSを書くのはなんだかなあ

ということで、いつもと同じように書けるようなテンプレートを作ってみました。なぜかリポジトリのREADMEを英語で書いてしまって後々使い方を忘れそうなので、ぼちぼちこの記事に追記しておきます。

よく使うやつをとりあえず入れる

とりあえずいつも使っているESLint、Prettier、TypeScriptは全部突っ込みました。

esbuild

コンパイルとトランスパイルにはesbuildを採用しました。採用理由は「esbuildは速い」と聞いていて前から興味があったからです。結果めちゃめちゃ速いし、ビルド用の設定が1スクリプトだけで済んでいるので、小規模なGASとの相性も良さそうです。

monorepo

これをmonorepoと呼ぶのかはちょっとよくわかっていないんですが、要は複数のGASプロジェクトを1リポジトリに突っ込みます。

npm run gen -name=<プロジェクト名>

ってやると、app配下にテンプレートが作成されて、このプロジェクトが1つのGoogleAppsScriptに対応する形になります。

もともとは1リポジトリ1スクリプト構成だったんですが、

小規模なGASのためにいちいちリポジトリたてるのもな〜
パッケージを使う場合に更新忘れそうだな〜
汎用的な処理は一箇所にだけ書いて他のスクリプトでも使いまわしたいな〜

ということで、さっき変えました。TurborepoとかNxとか流行っているやつもみてみたんですが、too muchな感じだったので、とりあえずnpm workspaceにしました。ちゃんと使えているかは正直微妙です。

今後

適当なGAS書いてみてとりあえず機能することはわかったのですが、いかんせん本運用にはまだ載せていないので、動かしながらちょいちょい修正していきたいと思います。

chezmoiの備忘録

ikuma-t — Mon, 18 Jul 2022 00:00:00 GMT

ちょっと設定をいじる時にchezmoiの管理方法をいつも忘れるので書いておく。

https://www.chezmoi.io/#considering-using-chezmoi

編集する

変更をchezmoi側から追加する

~.local/share/chezmoiディレクトリ内のファイルが編集できる

Terminal window

chezmoi edit <file>

で変更を反映する。

Terminal window

chezmoi apply

変更を元ファイル側から追加する

Terminal window

chezmoi add <file>
# or
chezmoi re-add

こっちの方が使いやすいかも

Gitに反映する

ディレクトリ移動して、普通にgit

chezmoi cdで chezmoiが管理しているディレクトリに移動することができる

Terminal window

chezmoi cd
git add .
git commit -m 'commit message'
git push

どこからでもgitを叩く

Terminal window

chezmoi git add .
chezmoi git -- commit -m 'commit message' # フラグを持つ場合は、`--`で区切る必要がある
chezmoi git push

自動で変更を反映する

~/.config/chezmoi/chezmoi.tomlに以下の設定を追加する

[git]
    autoCommit = true
    autoPush = true

herokuのOAuthトークン流出の行方まとめ

ikuma-t — Wed, 06 Jul 2022 00:00:00 GMT

HerokuのOAuthトークン流出からしばらく経って、「あれ、これって今どういうステータスなんだ？」と思ったので、調べてみました。

要約

2022年4月にTravis CIのOAuthトークン流出からはじまったHerokuのインシデントは2022年5月30日で収束し、現在はGitHubとの連携も再開している。

時系列

日付（UTC)	イベント
時系列不明	攻撃者がTravis-CIのOAuthトークンを用いた攻撃を行う
2022-04-07	攻撃者がHerokuのデータベースにアクセスし、OAuth Appのトークンおよび一部ユーザーのConfig Varsをダウンロード
2022-04-09	攻撃者がHerokuのOAuthトークンを用いてプライベートリポジトリをダウンロード
2022-04-13	GitHubからHerokuに対して通知
2022-04-13	Herokuが漏洩したOAuthトークンを無効化
2022-04-15	Herokuが調査している旨を公開
2022-04-16	HerokuがGitHubと統合しているOAuthトークンを無効にする旨を発表
2022-04-17	HerokuがすべてのOAuthトークンの失効を完了
2022-04-19 ~ 2022-05-03	Herokuが頑張っている報告が続く
2022-05-05	Herokuがすべてのユーザーのパスワードをリセット開始
2022-05-07	Herokuがすべてのユーザーのパスワードのリセットを完了。セキュリティベンダーとの調査で2022-04-14以降、不正アクセスはないと発表
2022-05-25	HerokuがGitHubとの連携を再開
2022-05-30	調査終了の報告

詳細

Heroku Statusの一件ずつ機械翻訳して追っていきます。

2022-04-15: 調査開始

At Salesforce, trust is our number one value. We’re actively investigating a report received on April 13, 2022, from GitHub that a subset of Heroku’s GitHub private repositories, including some source code, were downloaded by a threat actor on April 9, 2022. We proactively notified our Heroku customers regarding this issue and will continue to provide updates to assist them as the investigation continues. If Salesforce or GitHub becomes aware of unauthorized access to customer GitHub repositories connected to Heroku, we will notify affected customers by email without undue delay.

セールスフォースでは、信頼が第一の価値観です。2022年4月13日にGitHubから受け取った、一部のソースコードを含むHerokuのGitHubプライベートリポジトリのサブセットが、2022年4月9日に脅威行為者によってダウンロードされたという報告について、積極的に調査を行っています。当社は、この問題についてHerokuのお客様に積極的に通知し、調査が進むにつれて、お客様を支援するための最新情報を提供し続けます。Herokuに接続されているお客様のGitHubリポジトリへの不正アクセスをSalesforceまたはGitHubが認識した場合、影響を受けるお客様に電子メールで過度の遅滞なく通知します。

2022-04-15: 概要発表。OAuthトークン流出

On April 13, 2022, Salesforce Security was notified by GitHub that a subset of Heroku’s GitHub private repositories, including some source code, was downloaded by a threat actor on April 9, 2022. Based on Salesforce’s initial investigation, it appears that unauthorized access to Heroku’s GitHub account was the result of a compromised OAuth token. Salesforce immediately disabled the compromised user’s OAuth tokens and disabled the compromised user’s GitHub account. Additionally, GitHub reported that the threat actor was enumerating GitHub customer accounts using OAuth tokens issued to Heroku’s OAuth integration dashboard hosted on GitHub. Based on the information GitHub shared with us, we are investigating how the threat actor gained access to customer OAuth tokens. The compromised tokens could provide the threat actor access to customer GitHub repos, but not customer Heroku accounts. With the access to customer OAuth tokens, the threat actor may have read and write access to customer GitHub repositories connected to Heroku. Given the incident is still active, please review the recommended actions provided below.

2022年4月13日、Salesforce SecurityはGitHubから、一部のソースコードを含むHerokuのGitHubプライベートリポジトリのサブセットが、2022年4月9日に脅威行為者によってダウンロードされたことを通知されました。Salesforceの初期調査によると、HerokuのGitHubアカウントへの不正アクセスは、侵害されたOAuthトークンの結果であったと思われます。Salesforceは直ちに漏洩したユーザーのOAuthトークンを無効化し、漏洩したユーザーのGitHubアカウントを無効化しました。さらに、GitHubは、脅威者がGitHubにホストされているHerokuのOAuth統合ダッシュボードに発行されたOAuthトークンを使用してGitHubの顧客アカウントを列挙していたことを報告しました。GitHubが教えてくれた情報に基づき、我々は脅威者が顧客のOAuthトークンにアクセスした方法を調査しています。漏洩したトークンは、脅威者が顧客の GitHub リポジトリにアクセスすることはできても、顧客の Heroku アカウントにはアクセスできない可能性があります。顧客OAuthトークンへのアクセスにより、脅威者はHerokuに接続された顧客GitHubリポジトリへの読み取りおよび書き込みアクセスが可能になる可能性があります。このインシデントはまだアクティブであるため、以下の推奨されるアクションを確認してください。

このタイミングでHerokuとOAuthとの連携の切断が推奨されます。

2022-04-16: OAuthトークンの無効化発表

To mitigate impact from potentially compromised OAuth tokens, we will revoke over the next several hours all existing tokens from the Heroku GitHub integration. We are also preventing new OAuth tokens from being created until further notice. Your GitHub repositories will not be affected in any way by this action.

OAuthトークンの漏洩による影響を軽減するため、今後数時間以内にHeroku GitHub統合の既存のトークンをすべて失効させる予定です。また、追って通知があるまで、新しいOAuthトークンの作成を禁止しています。この措置により、お客様のGitHubリポジトリが影響を受けることはありません。

2022-04-17: すべてのOAuthトークンの失効完了

At 5
p.m. PT on April 16, 2022, Salesforce completed the revocation of all OAuth tokens from the Heroku Dashboard GitHub integration.

2022年4月16日午後5時（PT）、SalesforceはHeroku Dashboard GitHubインテグレーションからすべてのOAuthトークンの失効を完了しました。

2022-05-05: すべてのパスワードリセット

Separately, our investigation also revealed that the same compromised token was leveraged to gain access to a database and exfiltrate the hashed and salted passwords for customers’ user accounts. For this reason, Salesforce is ensuring all Heroku user passwords are reset and potentially affected credentials are refreshed. We have rotated internal Heroku credentials and put additional detections in place. We are continuing to investigate the source of the token compromise.

また、我々の調査により、同じ漏洩したトークンを利用してデータベースにアクセスし、お客様のユーザーアカウントのハッシュ化および塩漬けパスワードを流出させたことも判明しました。このため、Salesforce では、すべての Heroku ユーザーのパスワードをリセットし、影響を受ける可能性のある認証情報をリフレッシュするようにしています。私たちは、社内のHeroku認証情報をローテーションし、追加の検知を実施しました。トークン漏洩の原因については、引き続き調査中です。

2022-05-07: 不正アクセスの履歴はないと発表。

Since our last update, we confirmed that Heroku has completed the necessary password resets. We have no evidence of any unauthorized access to Heroku systems since April 14, 2022. This analysis is based on our investigation to date, backed by a leading third-party security vendor and our extensive threat detection systems. We also wanted to address a question regarding impact to environment variables. While we confirmed that the threat actor had access to encrypted Heroku customer secrets stored in config var, the secrets are encrypted at rest and the threat actor did not access the encryption key necessary to decrypt config var secrets.

前回の更新以降、Herokuは必要なパスワードのリセットを完了したことを確認しました。2022年4月14日以降、Herokuのシステムに対する不正アクセスの証拠はありません。この分析は、大手サードパーティセキュリティベンダーと当社の広範な脅威検知システムに裏打ちされた、これまでの調査に基づいています。また、環境変数への影響に関する質問にもお答えしたいと思います。脅威者は config var に格納された暗号化された Heroku の顧客秘密へのアクセスを確認しましたが、秘密は静止状態で暗号化されており、脅威者は config var の秘密を解読するのに必要な暗号化キーにアクセスしませんでした。

2022-05-25: GitHub連携が有効化される

We are happy to report that the GitHub integration is re-enabled! You can now reconnect with GitHub and restore your Heroku pipeline functionality, including Review Apps, with newly generated tokens. You can connect to GitHub immediately or wait for the enhanced integration as described in this blog post. To re-establish your GitHub connection now, please follow these instructions.

GitHubとの連携が再有効化されたことをご報告します!GitHubとの再接続が可能になり、新たに生成されたトークンでReview Appsを含むHerokuパイプラインの機能を復元することができるようになりました。すぐにGitHubに接続することもできますし、このブログポストで説明されているように統合が強化されるのを待つこともできます。今すぐGitHub接続を再確立するには、以下の手順に従ってください。

ブログポストはこれ。色々セキュリティ向上につとめてますよ、とのこと。

OAuthで要求するスコープを見直すとか
GitHub Appsへの移行とか
RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens 日本語訳とか。

https://blog.heroku.com/github-integration-update

以下の手順はこれ。普通に再度GitHub接続すればいいみたい。

https://help.heroku.com/UIUA61EH/how-do-i-reconnect-the-github-integration

2022-05-31: インシデント終了のお知らせ

Our investigation has concluded, and as previously mentioned, we restored the GitHub integration on May 25, 2022. We have no evidence of customer impact beyond what has already been reported, including no additional evidence of threat actor activity after April 14, 2022. We will publish details of the attacker’s actions on status.heroku.com the week of June 13, 2022.

調査は終了し、前述のとおり、2022年5月25日にGitHubとの連携を復旧させました。2022年4月14日以降、脅威行為者の活動を示す追加の証拠はないなど、すでに報告されている以上のお客様への影響はありません。攻撃者の行動の詳細については、2022年6月13日の週にstatus.heroku.comで公開する予定です。

2022-06-15: Follow-up Reportが掲載

Thank you for your patience and feedback throughout this incident. With the conclusion of our investigation, we are now providing our customers with an overview of the threat actor’s actions. The summary of our investigation includes mitigations and changes we are making to address the evolving threat landscape. For updates on the enhanced GitHub integration, please visit this blog post.

この件に関しまして、お客様には大変ご迷惑をおかけいたしました。調査の終了に伴い、現在、脅威行為者の行動の概要をお客様に提供しています。調査結果の概要には、進化する脅威の状況に対応するための緩和策と変更が含まれています。GitHubとの連携強化に関する最新情報は、こちらのブログポストをご覧ください。

ブログポストはこれ。2022-05-25のものと同じ。

https://blog.heroku.com/github-integration-update

ここからは調べごとのメモです

OAuthトークンはなぜ盗まれると困るのか？

とりあえずOAuthの理解ができていないといけません。

OAuthはRFC6749で定義されている認可のためのプロトコル。OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可FW。
登場人物はリソースオーナー（私たち）、クライアント（Heroku、Travis CI）、リソースサーバー（GitHub）、認可サーバー（GitHub）
OAuth認証はOAuthでユーザー情報のAPIを叩いて、それを使ってログインすること
認可サーバはリソースオーナーが承諾した場合、リダイレクトURIを介してアクセストークン（誰のリソースがどのような権限に紐づいているか、有効かなどの情報を持つ）をクライアントに渡す

OAuthトークン（アクセストークン）が盗まれると、その発行元であるリソースサーバーに対して、アクセストークンの範囲内でアクセスができてしまうわけです。 HerokuとかTravis CIは大体リポジトリの読み取り権限以上のものをもっているので、privateなnpmのリポジトリのデータが不正ダウンロードされたわけですね。

Travis CIやHerokuからなぜOAuthトークンが流出したのか？

調べた限りではTravis CIが漏れたのがもともとの原因で、標的型攻撃とのことだったのでそのアクセストークンを使ってHerokuへの攻撃がはじまったという感じっぽいです。

とすると、なぜTravis CIから漏れたのか？なんですが、Hacker Newsに関係ありそうな調査結果がありました。

Unpatched Travis CI API Bug Exposes Thousands of Secret User Access Tokens

記事はクラウドセキュリティファームのAqua社がブログで出しているレポートについて紹介してます。Aqua社は初めて知ったのですが、コンテナセキュリティ製品のAquaも提供していて、日本の代理店とクラスメソッドがパートナー契約をしているので、ある程度信憑性のあるソースとみて良いかと思っています。

https://blog.aquasec.com/travis-ci-security

私たち Team Nautilus は、最新の調査において、誰でも過去の平文ログにアクセスできる Travis CI API を通じて、何万ものユーザートークンが公開されていることを発見しました。無料層ユーザーの7億7000万件以上のログが公開されており、そこからGitHub、AWS、Docker Hubといった人気のクラウドサービスプロバイダーに関連するトークン、秘密、その他の認証情報を簡単に抽出することが可能です。攻撃者はこの機密データを利用して、大規模なサイバー攻撃を仕掛けたり、クラウド内で横移動したりすることができます。

どうもこの問題は過去2015年と2019年にも指摘されているみたいなんですが、それに対してTravisCIの対策は

API呼び出しの速度を遅くさせた
昔に比べてマスクされている情報が増えたけど、それでもトークンがマスクされていないバリエーションが20種類ほどある

とだいぶ杜撰な感じで、

GitHubへのアクセストークン
AWSへのアクセスキー
MySQLやPostgreSQLなどのデータベースへのアクセスを許可する、メールやユーザー名、パスワードなどの認証情報セット
Docker Hubのパスワード

などなどが実験してみたら取れそうとのことでした（2FAはちゃんとやろうね）。ひええ。

参考ソース

type-challenges 20日目: 62-Type Lookup

ikuma-t — Sun, 26 Jun 2022 00:00:00 GMT

問題 & 回答

代数的データ型（algebraicdatatypes;ADT）を表現するユニオン型から、その属性を取得するようなLookUp型を定義する。

1つ目の型引数にUnion型をとり、2つ目の引数には、typeというプロパティに期待する属性をstringで指定する。

type LookUp<U, T extends string> = U extends { type: T } ? U : never

Conditional Typesのいつもの（never返すやつ）を利用する。問題文の指定では、取得対象の型はtype: xxxを必ず保持しているので、2つ目の引数Tで指定された値を利用した{ type: T }の部分型であるinterfaceを返す。

分配法則が効くので、ユニオン型の中の合致しない型はneverによって無視される。

感想

Conditional Typesってほんまに高度な型なんかな〜と思うくらい毎日のように出てきますね〜。

ESLintのno-plusplusはなぜ怒られるのか

ikuma-t — Sat, 25 Jun 2022 00:00:00 GMT

どうもCopilot無料にならなかった私です。先日Copilot経由でforループを書いていたら++演算子が補完されたのですが、これがESLintルールで怒られました。どうもno-plusplusだと。

結局forEachに書き直して（最終的にはそれすらも消え）何事もなかったのですが（そのまま使うとしても+= 1にするだけ）、ESLintのルールはどういう意図でこれを設けているのかわからなかったので調べてみました。

結論

インクリメント演算子は前にも後ろにも置ける。
JavaScriptは内部的にセミコロンが無い文にセミコロンを挿入して文を解釈する。
結果として前置の++が、後置の++になる可能性があるので、それを禁止するルールがno-plusplus

インクリメント演算子

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Increment

インクリメント演算子（++）は前置と後置の2種類があって、どちらもオペランドをインクリメントしますが戻り値が異なります。

前置：インクリメント前の値を返す
後置：インクリメント後の値を返す

今回のポイントは「前にも後ろにも置ける」ということです。

ESLintのドキュメントをみてみる

https://eslint.org/docs/latest/rules/no-plusplus

Because the unary ++ and — operators are subject to automatic semicolon insertion, differences in whitespace can change semantics of source code.

単項演算子++と--は、セミコロンの自動挿入の対象になるので、ソースコードの意味が空白の違いで変わってしまうとあります。

Automatic Semicolon Insertion

ここでいうセミコロンの自動挿入はASIと呼ばれるものです。

ASIは「Automatic Semicolon Insertion」の略称です。 JavaScriptはセミコロンを書いても書かなくてもOKな言語ですが、内部的にはセミコロンを自動で挿入して文を区切っています。

https://262.ecma-international.org/13.0/#sec-automatic-semicolon-insertion

Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

色々とルールがあるようですが、今回のケースでは次のような解釈が発生するために問題となるようです。

// i++として解釈される
i　++
j

// ++jとして解釈される
i
++
jj

1つ目はぱっと見でわかりますが、2つ目は挙動がわかりづらいですね（こんなコード書かないとは思いますが）

no-plusplus

https://eslint.org/docs/latest/rules/no-plusplus

再びドキュメントに戻りまして、上記のような事態を抑制するのがno-plusplusルールです。

module.exports = {
  env: {
    browser: true,
    commonjs: true,
    es2021: true,
  },
  extends: 'eslint:recommended',
  parserOptions: {
    ecmaVersion: 13,
  },
  rules: {
    'no-plusplus': ['error'],
  },
};

このルール下では++や--を使うと上記の理由で怒られます。代わりに+=や-=を使用します。

allowForLoopAfterthoughtsオプション

for ([initialization]; [condition]; [final-expression])

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/for

forループのfinal-expression（ループのそれぞれの最後に評価される式）では++や--を許可するオプションです。

Afterthougtsがfinal-expressionを指しているようです（公式なのはわかりませんが、「for loop afterthoughts」でググるとちょっとヒットした）。

感想

全然関係ないんですけど、ECMAScriptの仕様書のサイト結構重いですね…。

type-challenges 19日目:20-Promise.all

ikuma-t — Wed, 22 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00020-medium-promise-all/README.md

PromiseAllに型をつける。

declare function PromiseAll<T extends any[]>(values: readonly [...T]): Promise<{
  [P in keyof T]: T[P] extends Promise<infer R> ? R: T[P]
}>

問題文にもありますが、PromiseAllの戻り値の型はPromise<T>で、引数の型は配列です。as constが使用されているケースがあるので、ここまでで

declare function PromiseAll<T extends any[]>(values: readonly [...T]): Promise<T>

こういう感じです。あとはどっかの回でやった再帰的なやつにやや近いですが、TがPromiseだった場合にはそれを解除してやる必要があるので、mappedTypesとinferキーワードを使って最終的にはこうなります。

declare function PromiseAll<T extends any[]>(values: readonly [...T]): Promise<{
  [P in keyof T]: T[P] extends Promise<infer R> ? R: T[P]
}>

感想

眠いです笑

type-challenges 18日目：16-Pop

ikuma-t — Tue, 21 Jun 2022 00:00:00 GMT

問題 & 回答

https://github.com/type-challenges/type-challenges/blob/main/questions/00016-medium-pop/README.md

配列Tを受けとって、配列の最後の要素以外の型を返すPop<T>を実装する。

type Pop<T extends any[]> = T extends [...infer Rest, unknown] ? [...Rest] : never

Conditional Typesとinferキーワード、Variadic Tuple Typesを用いて実装しました。

感想

最初unknown部分をanyで書いていたのですが、回答を見ていたら、anyは怒られがちだし、どうせ使わないならunknownでよくない？みたいなコメントを見つけて、こっちに変更しました。

仕事を始めたので、数日空いてしまったのですが速攻で解けたので安心しました。

最近お仕事で初めてちゃんと動くTypeScriptのコードを書いたのですが（）、このtype-challengesをやったおかげで先輩の言っていることがチンプンカンプンということがないので、やっといてよかったな〜と思っています。

今後も優先度は少し低くなりますが、こつこつやっていきます。

v-modelとはなにか

ikuma-t — Tue, 21 Jun 2022 00:00:00 GMT

バージョンによる挙動の違いやカスタムコンポーネントで使用する際に、v-modelの挙動が5秒くらいわからないときがありました。

1秒以内でv-modelを利用したコードを読めるように、未来の自分に向けてv-modelを説明しておきます。

v-modelの概要

v-modelはVuejsのディレクティブの1つで、主にフォーム入力バインディングの文脈で利用されます。

v-bindディレクティブとv-onディレクティブをまとめて書くためのシンタックスシュガーであり、v-model="hoge"の形式でリアクティブな変数hogeにフォームの値を束縛し、入力相当のイベント（inputとかchangeとか）発火時に入力値をhogeに代入するという動きをします。

v-model理解のためにはシンタックスシュガーを分解するのがよいのですが、Vue2とVue3で使用する変数名が異なるので、別々に解説します。

Vue 2系におけるv-model

<input v-model="inputText">

これはVue2系の場合、次のシンタックスシュガーになります。

<input :value="inputText" @input="inputText = $event.target.value">

:valueはv-bind:valueのショートハンド、@inputはv-on:inputのショートハンドです。

読み下すと、「このフォームにvalueという変数を束縛し、inputイベント時に$event.target.value（入力値）をvalueに設定する」という意味になります。

Vue2系でのv-modelのデフォルト値は

プロパティ名：value
イベント名：input

となっています。これはあくまでデフォルトであって変更することもできますが、それは後述のカスタムコンポーネントの章で紹介します。

Vue 3系におけるv-model

<input v-model="inputText">

これはVue3系の場合、次のシンタックスシュガーになります。

<input :modelValue="inputText" @update:modelValue="inputText = $event.target.value">

Vue2系との差分はプロパティ名とイベント名です。

プロパティ名：modelValue
イベント名：update:modelValue

1つのコンポーネント内でシンプルにv-modelを使用している場合は問題ないのですが、複数のコンポーネントでv-modelで定義した値をやりとりしたり、イベントで発火する処理を変更する場合はVue2と同様にすると動かないので注意が必要です。

こちらもVue2同様、あくまでデフォルトの値ですが、それは後述のカスタムコンポーネントの章で紹介します。

カスタムコンポーネントでv-modelを使用する

ここまでは単一のコンポーネントで使用するケースを確認してきました。

<input v-model="inputText">

これだけならだいぶ理解もしやすいのですが、カスタムコンポーネントに対してv-modelを使用するとなると一瞬理解のスピードが落ちるのでここで解説します。

// カスタムコンポーネントでは値をどうやって受け取る?
<MyCustomComponent v-model="inputText" />

基本的な考え方は結局のところ「props down, event up」です。各バージョンごとに詳細を確認します。

Vue2系概要

先述のようにVue2ではv-modelは次のシンタックスシュガーです。

<MyCustomComponent :value="inputText" @input="inputText = $event.target.value">

そのため、子コンポーネント側でこのinputText（親でv-modelに渡した値）を変更するには、次の要件を満たす必要があります。

propsでvalueという名前でinputTextを受け取る（props down）
値が変更されたタイミングで、新しい値とともに、親コンポーネントのinputイベントを発火する（event up）

いくつか書き方があるので、それぞれ見ていきます。

Vue2: Optins API

愚直に受け取る

<template>
  <input :value="value" @input="$emit('input', $event.target.value)">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  props: {
    value: {
      require: true,
      type: String
    }
  },
}
</script>

シンプルにvalueをpropsとして受け取り、子コンポーネント内のinputイベントで親のinputイベントをemitします。

modelオプションを指定して受け取る

Vue2系ではmodelオプションを指定することができます（Vue3では廃止）。これを指定することで、子コンポーネント側でv-modelを受け付ける際に、v-modelのプロパティ名とイベント名を変更することができるようになります。

<script>
// プロパティ名がvalueからvalueOfModelに、イベント名がinputからvalueOfModelEventに変更される
model: { prop: 'valueOfModel', event: 'valueOfModelEvent' }
</script>

これを利用することで、先程のコードを次のように修正することができます。

<template>
  <input :value="valueOfModel" @input="$emit('valueOfModelEvent', $event.target.value)">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  model: { prop: 'valueOfModel', event: 'ValueOfModelEvent' },
  props: {
    valueOfModel: {
      require: true,
      type: String
    }
  },
}
</script>

なお、この場合でも親コンポーネント側の呼び出し（v-model=xxx）は変わりません。あくまでカスタムコンポーネント側で受けたv-modelをどう処理するかの名前を変更するだけです。

v-modelと双方向算出プロパティで受け取る

算出プロパティcomputedを用いることで、カスタムコンポーネント内の記述でもv-modelを使用することができるようになります。

以下の手順で説明します。

computedのsetter
子コンポーネントでのprops直接編集禁止
v-modelと双方向算出プロパティで親のv-modelに子もv-modelでアクセスする

1.computedのsetter

computedはプロパティ名のみを指定した場合、getter関数として定義されますが、明示することでsetterを定義することもできます。

<script>
export default {
  // ...
  computed: {
    fullName: {
       // getterの定義
       get() {
         return `${this.firstName} ${this.lastName}`}
       },
       // setterの定義
       set(newValue) {
       const [newFirstName, newLastName] = newValue.split(' ')
         this.firstName = newFirstName
         this.lastName = new LastName
       }
    }
  }
}
</script>

この仕組みを利用すると、直接編集できないなんらかの値に対して、リアクティブ性を損なわずに参照と編集を行うことができるようになります。

2.子コンポーネントでのprops直接編集禁止

もともとサンプルとして出していたカスタムコンポーネントに戻りましょう。

<template>
  <input :value="value" @input="$emit('input', $event.target.value)">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  props: {
    value: {
      require: true,
      type: String
    }
  },
}
</script>

inputタグの部分でやっていることがv-modelと同じっぽいのでこれをv-modelに置き換えてみます。

<template>
  <input :value="value" @input="$emit('input', $event.target.value)">
  <input v-model="value">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  props: {
    value: {
      require: true,
      type: String
    }
  },
}
</script>

この実装をすると一見良さそうな感じもしますが、これではVue側で「親の値を直接変更すると、再レンダリングのたびに値が上書きされる」といった警告が出てしまいます。親から貰ってきた値を子が直接編集できてしまうと、複数のコンポーネントで同じようなことをやった時に収集がつかなくなります。

なので、v-modelのシンタックスシュガーの恩恵を受けつつ、算出プロパティを用いて間接的に値を編集します。

3.v-modelと双方向算出プロパティで親のv-modelに子もv-modelでアクセスする

まずはv-modelに直接紐づけられている親のvalueを別の値に変更します。

<template>
  <input v-model="value">
  <input v-model="innerValue">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  props: {
    value: {
      require: true,
      type: String
    }
  },
}
</script>

このままでは定義が値の定義がされていないので、算出プロパティで「getterでは親のvalueの値を表示する、setterでは親のinputイベントを発火する」ように定義します。

<template>
  <input v-model="innerValue">
</template>

<script>
export default {
  name: 'MyCustomComponent',
  props: {
    value: {
      require: true,
      type: String
    }
  },
 computed: {
   innerValue: {
     get() {
       return this.value
     },
     set(newValue) {
       this.$emit('input', newValue)
     }
   }
 }
}
</script>

これによりこのコンポーネントのinnerValueは次のように動作するようになります。

（親の）v-modelで定義した値がpropsとして子に渡る
innerValueのgetterで親のvalueを表示する
inputタグに値を入力すると、innerValueのsetterでnewValueを引数に親のinputイベントが発火する
親コンポーネントのv-modelで定義した値が変更される

… 1に戻る

もちろんVue2系であれば、この方法の中でもmodelオプションを利用することもできます。

Vue2: Composition API

CompositionAPIの場合も同じです。modelオプションを使用することもできます。一例として算出プロパティを利用する例をComposition APIに書き換えてみます。

<template>
  <input type="text" name="name" v-model="innerValue">
</template>

<script>
import { computed } from '@vue/composition-api'

export default {
  name: 'MyInputComposition',
  model: { prop: 'modelValue', event: 'update:modelUpdate' },
  props: {
    label: {
      require: true,
      type: String
    },
    modelValue: {
      require: true,
      type: String
    }
  },
  setup (props, { emit }) {
    const innerValue = computed({
      get() {
        return props.modelValue
      },
      set(newValue) {
        emit('update:modelUpdate', newValue)
      }
    })

    return {
      innerValue
    }
  }
}
</script>

Vue3系概要

Vue3ではv-modelは次のシンタックスシュガーです。

<MyCustomComponent :modelValue="inputText" @update:modelValue="inputText = $event.target.value">

そのため、子コンポーネント側でこのinputText（親でv-modelに渡した値）を変更するには、次の要件を満たす必要があります。

propsでmodelValueという名前でinputTextを受け取る（props down）
値が変更されたタイミングで、新しい値とともに、親コンポーネントのupdate:ModelValueイベントを発火する（event up）

またVue2との変更点として、modelオプションが廃止されました。その代わりにv-modelに引数を取ることができます。

例えばカスタムコンポーネントの呼び出し側で

<MyCustomComponent v-model:title="inputText" >

とした場合、これは次と同じ意味になります。

<MyCustomComponent :title="inputText" @update:title="inputText" >

ちょうどデフォルト値のmodelValueの部分が指定した引数に置き換わるような形です。

次に各APIでのカスタムコンポーネントの書き方を見ていきます。簡略化のため、引数は用いずにデフォルト値で実装します。

Vue3: Options API

<template>
  <input type="text" name="options" v-model="innerValue">
</template>

<script>
export default {
  name: 'MyInputOptions',
  props: {
    modelValue: {
      type: String
    }
  },
  computed: {
    innerValue: {
      get() {
        return this.modelValue
      },
      set(newValue) {
        this.$emit('update:modelValue', newValue)
      }
    }
  }
}
</script>

算出プロパティを使用した形式ですが、Vue2で使用していた他の形式も使用できます（ただしmodelオプションは使えません）。

差分としては先述のプロパティ名とイベント名です。

Vue3: Composition API

Vue3.2.26からはscript setup構文が使えて、基本的にはこれが推奨されているので、その形式で書き直してみます。

<template>
  <input type="text" v-model="innerValue">
</template>

<script setup lang="ts">
import { computed, defineEmits, defineProps } from 'vue'

interface Props {
  modelValue: string;
}

interface Emits {
  (e: "update:modelValue", value: string): void;
}

const props = defineProps<Props>()
const emit = defineEmits<Emits>()

const innerValue = computed({
  get() {
    return props.modelValue
  },
  set(newValue: string) {
    emit('update:modelValue', newValue)
  }
})
</script>

一部tsが入ったことでPropsとEmitsの型が追加されましたが、冗長なreturn文が消えてスッキリしました。

v-modelの修飾子

v-modelではv-model.modifierの形式で修飾子を補うことで、v-modelにbindしている値を任意の形式に変換することができます。

Vue 2系

Vue2では組み込みの修飾子3種類のみが定義されています。

.trim：入力から空白を取り除く
.number：入力をnumberへ型キャストする。
.lazy：inputイベントではなく、changeイベントでイベントを発火する

Vue 3系

Vue3では上記の3種類の組み込み修飾子に加えて、カスタム修飾子を定義することもできるようになりました。

公式のサンプルにもある、最初の一文字を大文字にするcapitalize修飾子を実装します。

親コンポーネント

<script setup lang="ts">
import { ref } from 'vue'
import MyVModelModifier from './components/MyVModelModifier.vue'
const text = ref('')
</script>

<template>
  <MyVModelModifier v-model.capitalize="text"></MyVModelModifier>
  {{ text }}
</template>

子コンポーネント

<template>
  <input type="text" :value="modelValue" @input="emitValue" />
</template>

<script setup>
const props = defineProps({
  modelValue: String,
  modelModifiers: { default: () => ({}) }
})

const emit = defineEmits(['update:modelValue'])

const emitValue = (e) => {
  let value = e.target.value
  if (props.modelModifiers.capitalize) {
    value = value.charAt(0).toUpperCase() + value.slice(1)
  }
  emit('update:modelValue', value)
}
</script>

v-model.modifierの形式で記述すると、modelModifiersというpropが使用できるようになります。例えば、`capitalize“をmodifierの位置に指定すると、

modelModifiers = {
  capitalize: true
}

という具合にtrueを値に持つプロパティが作成されます。Vue側が提供するのはこのフラグ的な機能のみで、これを利用して実際にv-modelに紐づいたイベントで期待する処理（ここでは大文字にする処理）を実装する形式になります。

感想

ちょっと前までずっとscript setupで書いていたので、久しぶりにOptionsAPIだったり3.2.26以下のCompositionを触る機会でちょっと頭がこんがらがりました（「あれ、これVue3から使えるのか？CompositionAPIだから使えるのか？3.2.26以上で使えるのか？」など）。

今回整理したので、これでしばらくは大丈夫でしょう！

type-challenges 17日目: 15-last-of-array

ikuma-t — Mon, 13 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00015-medium-last/README.md

配列Tをとって、最後の要素の型を返すLast<T>を実装する。

Variadic Tuple Typesが要素の最後でなくても使えるのがポイント。最後以外の要素を_Restとして受けて、最後の要素をLastで参照する。

type Last<T extends any[]> = T extends [...infer _Rest, infer Last] ? Last: never

類似の問題はこれ。

https://ikuma-t.work/posts/type-challenge-first-of-array

別に参照する必要がないのであれば、inferにする必要もない

type Last<T extends any[]> = T extends [...any, infer Last] ? Last: never

そのうち、Lastを書くのも煩わしくなるくらいに慣れてきたら、これくらいが妥当なのかもしれない。

type Last<T extends any[]> = T extends [...any, infer L] ? L: never

感想

類似の問題とはいえ、久しぶりに解く問題でもスラスラと解けるようになっているので、これをやっている意味はあると思われる。

type-challenges 16日目: 12-Chainable Options

ikuma-t — Sun, 12 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00012-medium-chainable-options/README.md

option(key, value)を任意の数チェインして、最終的な結果をget()で呼び出すような 2 つの関数を提供する型を定義する。

type Chainable<Options = {}> = {
  option<K extends string, V>(
    key: K,
    value: V
  ): Chainable<Options & { [S in K]: V }>;
  get(): Options;
};

全然わからなくて答えをみたので、解析していく。まず、単純にoptionメソッドを持つオブジェクトを考える。

このメソッドの要件は

引数はkeyとvalueで、keyにstring、valueに任意の型を受ける
戻り値はここまで追加された option（オブジェクト）と、今回メソッドに渡された key と value で生成された option（オブジェクト）が合わさったもの。

// ここまでに定義されたOptionをチェーンする。何もOptionがなければ`{}`が初期値として設定される
type Chainable<Options = {}> = {
  option<K extends string, V>(
    key: K,
    value: V
  ): Chainable<Options & { [S in K]: V }>;
};

declare const base: Chainable; // Chainable<{}>

// Optionsは初期値`{}`
// Chainable<{} & { "require": boolean }>
// Chainable<{ require: boolean }>
const requireOptionAdded = base.option("require", false);

// optionで返されているOptionsは`{ require: boolean }`
// Chainable<{ require: boolean } & { old: boolean }>
// Chainable<{ require: boolean,  old: boolean; }>
const oldOptionAdded = requireOptionAdded.option("old", true);

あとは現在保持している Options を返すようにgetを実装する。

type Chainable<Options = {}> = {
  option<K extends string, V>(key: K, value: V): Chainable<Options & { [S in K]: V }>
  get(): Options;
}

調べたこと

アンビエント宣言（`declare`）

JavaScript コードを生成せずに、型推論のためだけの情報を渡すのに使用する。

declare;
a: number;

感想

再帰とはまた違った形式だけれど、地味に汎用性の高い型定義だと思うので覚えておこう

type-challenges 15日目: Tuple to Union

ikuma-t — Sat, 11 Jun 2022 00:00:00 GMT

問題 & 解答

タプル型を受け取って、その要素からなるユニオン型を返すTupleToUnion<T>を実装する。

type Arr = ['1', '2', '3']

type Test = TupleToUnion<Arr> // expected to be '1' | '2' | '3'

ルックアップ型を利用して、配列の要素の型を取得します。numberで取得すると配列の要素すべての型がユニオン型で返ります。

type TupleToUnion<T extends any[]> = T[number]

感想

TupleToObjectよりも簡単（Mapped Types使ってないし）と思ったんですけど、どうなんだろう。

type-challenges 14日目: Deep Readonly

ikuma-t — Fri, 10 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00009-medium-deep-readonly/README.md

オブジェクトの各プロパティを再帰的にreadonlyにするDeepReadonly<T>を実装する。

前提：オブジェクトのみが渡される前提（クラスや配列、関数は考慮しなくてよい）

思考過程

単純にReadonlyにするのであれば、Mapped Typesで定義すれば良い。

type Readonly<T> = { readonly [P in keyof T]: T[P] }

再帰的にこの定義を実装していくので、Recursive Conditional Typesも使う。

type DeepReadonly<T> = { readonly [P in keyof T]: T[P] extends T[P]がオブジェクト ? DeepReadonly<T[P]>  : T[P]   }

T[P]がオブジェクトであるかどうかってどうやって判断するんだっけ？ここでいうオブジェクトには関数とか配列は含まなくて、単純な{ key: value }構造インデックスシグネチャを利用する？ブル本には推奨されていなかったけど、一旦これでやってみる。

type DeepReadonly<T> = { readonly [P in keyof T]: T[P] extends { [key: string]: unknown } ? DeepReadonly<T[P]>  : T[P] }

一応代入しようとすると、readonlyになっているんだけど、型定義を確認すると

type Expected = {
  readonly a: () => 22
  readonly b: string
　// DeepReadonlyは適用されているものの、展開されていない
  readonly c: <DeepReadonly {
    d: boolean
    // 略

となっていて、厳密な一致にはなっていない模様。

…というところでもうわからんとなったので、他の方の回答をみました。

type DeepReadonly<T> = keyof T extends never ? T : { readonly [k in keyof T]: DeepReadonly<T[k]> }

https://github.com/type-challenges/type-challenges/issues/187

base caseをkeyof T extends neverで拾って、recursive caseでDeepReadonly<T>を呼び出しています。

感想

Objectの中でRecursive Conditional Typesを使うとなぜだめなのかがわかりませんでした。

ちゃんと代入しようとするとreadonlyになっているのに…。

type-challenges 13日目: 8-Readonly 2

ikuma-t — Thu, 09 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00008-medium-readonly-2/README.md

二つの引数T、Kをとり、Kが指定されていればTのそのプロパティを、指定されていなければすべてのTのプロパティを読み取り専用に変換するMyReadonly<T, K>を実装する。

type MyReadonly2<T, K extends keyof T = keyof T> = { readonly [P in K]: T[P] } & Omit<T, K>

「readonlyなKで指定されているプロパティ & Tに含まれるK以外のプロパティ」を目指して作っていきます。

1. `readonly`な`K`で指定されているプロパティを作る

これが通常のReadonlyの実装です。

type MyReadonly2<T, K extends keyof T> = { readonly [P in T]: T[P] }

このままだとKの値がreadonlyにならないので、mapped typesでぐるぐるするところを変えます。

type MyReadonly2<T, K extends keyof T> = {
  readonly [P in T]: T[P]
  readonly [P in K]: T[P]
}

これによりKに渡されたプロパティはreadonlyになります。

2. `T`に含まれる`K`以外のプロパティ

これだけだとKに含まれるプロパティしか含まれていません。そのため、Kに渡されなかったプロパティの型を取得する必要があります。これはTの中からKに該当するプロパティを除いたものです。

例えば以下のようなTとKを渡すことを考えます。

// こっちがT
type Music ={
  name: string,
  artist: string,
  releaseYear: number
}

// こっちがK
type ReadonlyRequiredParams = "artist" | "releaseYear"

最終的にMyReadonly2に期待するのは次のような形式なので、name: stringを取り出せれば良いはずです。

type Expected = {
  name: string,  // TODO: これから取得したい
  readonly artist: string,  // { readonly [P in K]: T[P] } で表現される
  readonly releaseYear: number  // { readonly [P in K]: T[P] } で表現される
}

これは昨日出てきたOmit（組み込みの型の方です）を使用して、Omit<T, K>の形式で取り出すことができます。

type Music2 = Omit<Music, ReadonlyRequiredParams>
// type Music2 = { name: string; }

3. 1と2を合体

これらをインターセクション型で繋ぎこむと、解答を得ることができます。

type MyReadonly2<T, K extends keyof T> = { readonly [P in K]: T[P] } & Omit<T, K>

4. `K`のデフォルト値を設定する

…と思ったらまだエラーが出ています。この型はKを省略可能なのでそこでひっかります。Kは参照されるので何かしらの値を入れておく必要があります。

TypeScriptは型引数にデフォルト値を取ることができます。

https://typescriptbook.jp/reference/generics/default-type-parameter

今回は「Kを指定しなかった場合、すべてのプロパティがreadonlyになる」ので、Kには「Tのプロパティすべて」を設定します。

type MyReadonly2<T,
  K extends keyof T
  K extends keyof T = keyof T
>

他の人の解答を見ていたら、Omit<T, K>の部分を& Tで繋ぎ込んでいる解答もあったのですが、これではだめでした。

interface Todo1 {
  title: string
  description?: string
  completed: boolean
}

interface Todo2 {
  readonly title: string
  description?: string
  completed: boolean
}

type TodoX = Todo1 & Todo2

const todoX: TodoX = {
  title: "JavaScriptを勉強する",
  completed: true
}

todoX.title = "TypeScript"  // titleはreadonlyではない。

感想

う〜ん、最後のインターセクション型の挙動についてはドキュメントをざっと読んだのですが、期待する記述は見つけられませんでした。readonlyだけならいいんですが、他にも自分が理解できていない部分があると怖いです。

type-challenges 12日目: 3-Omit

ikuma-t — Wed, 08 Jun 2022 00:00:00 GMT

問題 & 解答

組み込みのOmit<T, K>を実装する。Tのプロパティから、Kを除いた型を返す。

type MyExclude<T, U> = T extends U ? never : T;

type MyOmit<T, K extends keyof T> = { [P in MyExclude<keyof T, K>]: T[P] }

別解（こっちの方がナウい）

type MyOmit<T, K extends keyof T> = { [P in keyof T as Exclude<P, K>]: T[P]  }

調べたこと

Key Remapping in Mapped Types

Mapped Typesで使えるプロパティ名（キー）の再定義方法。

一例としてすべてのプロパティをreadonlyにするような型を書いてみます。（組み込み型としてReadonlyがありますが、理解のためにあえて再実装します）

// Mapped Typesを使って、各プロパティをreadonlyにする
type MyReadonly<T> = { readonly [P in keyof T]: T[P] }


// 以下はサンプル
type Book = {
  name: string,
  author: string,
}

const book: Book = {
  name: "ABC殺人事件",
  author: "アガサ・クリスティ"
}

const readonlyBook: MyReadonly<Book> = {
  name: "銀河鉄道の夜",
  author: "宮沢賢治",
}

book.name = "オリエント急行の殺人"; // OK

// Mapped Typesによってreadonlyになっているので、変更が禁止されている。
readonlyBook.name = "注文の多い料理店"; // TS2540: Cannot assign to 'name' because it is a read-only property.

このMapped Typesの使用法では、プロパティの属性は変わっていますが（指定なし→readonly）、プロパティ名自体は変わっていません（nameはnameのまま、authorはauthorのまま）。

TypeScript 4.1 以降で導入されたMapped Typesで使用できるasキーワードを使用すると、プロパティ名を変更することができるようになります。

// as キーワードを利用して、`keyof T`で取得される「name」「author」をそれぞれ「specialName」「specialAuthor」に変換する
type MySpecial<T> = { [P in keyof T as `special${Capitalize<string & P>}`]: T[P] }

// プロパティ名が変換されている
const specialBook: MySpecial<Book> = {
  specialName: "SPY FAMILY",
  specialAuthor: "遠藤達哉"
}

console.log(specialBook.name); // TS2339: Property 'name' does not exist on type 'My Special".

asの後ろに変換後の名前を指定します。今回はTemplate Literal Typesを利用して、動的にプロパティを組み立てています。

`special${Capitalize<string & P>}`  // "specialXxxxx..."に変換

Capitalizeについては、TypeScriptのコンパイラに組み込まれている型でその名の通り1文字目を大文字にして返します。定義としてはCapitalize<string>になりますが、keyofで取得しているのはオブジェクトのプロパティなのでstring | symbol | numberの可能性があるため、参照したプロパティ名をそのまま使用してしまうとエラーになります。

`special${Capitalize<P>}` //TS2344: Type 'P' does not satisfy the constraint 'string'. Type 'keyof T' is not assignable to type 'string'.Type 'string | number | symbol' is not assignable to type 'string'.Type 'number' is not assignable to type 'string'.

そのため、インターセクション型を利用して、stringに絞り込んでいます。

ここまでの例では単純にプロパティ名を変換しているだけでしたが、asはneverを返した場合にそのプロパティを除外することもできます。これが今回の問題の別解です。

// Conditional Typesでそのまま実装した形式
type MyOmit<T, K extends keyof T> = { [P in keyof T as P extends K ? never : P]: T[P] }

// 組み込みのExcludeを使用する
type MyOmit<T, K extends keyof T> = { [P in keyof T as Exclude<P, K>]: T[P] }

参考

https://www.typescriptlang.org/docs/handbook/2/mapped-types.html#key-remapping-via-as

https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html

感想

組み込みのExcludeを使っていいのかどうかわからなくて再実装しました。Excludeは過去回で登場しています。

https://ikuma-t.work/posts/type-challenge-exclude

解いた後にantfuさんの解答のスレッドをみてasが使えることを知って色々と調べました。ワカラナイコトマダマダタクサンネ・・・。

デスクを変えたのでモニターアームが使えるようになった

ikuma-t — Tue, 07 Jun 2022 00:00:00 GMT

月1で「Fika」をやっている

最近「Fika」と称して家族会議的なものを月1でやっています。

これは月に1度ただカフェに行って夫婦間で「そういえばこれ変えたいんだけど」とか「本当はこういう暮らしがしたい」みたいなことをただ言っていく試みです。「Fika」という名前はスウェーデン語のコーヒーブレイク的な意味で、「短い名前だと予定入れやすいし、可愛い名前だとテンション上がるよね」ということで命名しています。

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3%82%AB

もともとこういう夫婦感の課題解決みたいなところはだいぶ前から挑戦していて、TrelloやNotionにタスクを積んだりしていたのですが、如何せんそういうのが好きなのは私だけでして、妻はまったく見ず、何も解決に向かわないことからがっつり時間を設けてその中で発散し、アクションを決めていくスタイルに移行しました。This is Fikaです。

一応議事録の役割と話のフレームみたいなものがあった方が課題を見つけやすいので、Transnoを利用して1枚のマインドマップを毎回その場で更新しながら話をしています。

transnoで作成しているマインドマップ

Transnoについてはこちらの記事で紹介しています。

https://ikmbear.hatenablog.com/entry/20211215/1639551694

今日のテーマは「家」から派生して「ものを減らす」だったので、アクションとしてあがったものを色々と整理した上でそのついでにリビングの机と作業用のデスクを入れ替えました。

デスク入れ替えでモニターアームが使えるように

もともと横長のそこそこ大きいデスクを使っていたんですが、机の各辺に12cmくらいの返しがあったため、モニターアームを購入しておきながら使えていませんでした（2年くらい倉庫に眠っていた）。

もともとの机は写真のデスクの2倍の長さがあったので、「モニターアームが使えるようになるのはいいけど、メモリが狭くなるのはいたしかたなしか〜」とややネガティブに捉えていたのですが、入れ替えてみると全然問題なし。

むしろ広いスペースにものがおけなくなったことで、本当に必要なものだけがおけるようになりました。これはパーキンソンの第N法則に掲げていいかと。

モニターアームを導入したことでモニター配下にクラムシェルのMacが配置できるようになったので、とても良い感じです。

来週から新しいお仕事が始まる予定なので、今回のデスク含めて現状の作業環境で使用しているものを近日中にまとめておいて、定点観測で何が不要で逆に何が必要だったかまとめたいと思います。

type-challenges 11日目: 2-Get Return Type

ikuma-t — Tue, 07 Jun 2022 00:00:00 GMT

問題 & 解答

組み込みのReturnType<T>を実装する。

inferで戻り値の型を取得して、あとはいつものU or neverです。

type MyReturnType<T extends (...args: any[]) => any> = T extends (...args: any[]) => infer U ? U : never

調べたこと

`ReturnType`

https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype

関数Fを渡すと、その戻り値の型を返す。

type T0 = ReturnType<() => string>
// type T0 = string

感想

昨日の問題の変化系ですね。

https://ikuma-t.work/posts/type-challenge-parameters

任意の関数を示すのに、(...args: any[]) => anyがさらっと出てくるようになったのは成長の証です。

ところでMediumの問題とEasyの境目はなんなのでしょうか…。

Reactのchildrenとはなにか

ikuma-t — Tue, 07 Jun 2022 00:00:00 GMT

要約

Reactのchildrenはpropsが保持しているプロパティです。親コンポーネントのタグに入れられた要素を参照します。

Reactナニモワカラナイ

いままでVueとVanila JSしか触ってこなかったので、現在TypeScriptとReactのキャッチアップをしているのですが、まずはTypeScriptに時間を割いているためReactはちょっと後回し気味です（のわりにDenoやってるやんけワレ）。一応チュートリアルくらいはやっています。

いやでもReact と TSが目につくようにこのブログはNext.js + TypeScriptで作成しているのですが、カスタマイズにあたってReactの初歩的な知識でつまづいたのでまとめます。

Reactのchildren

対象バージョン

React v18.0

意味

Reactのchildrenはpropsが保持しているプロパティです。親コンポーネントのタグに入れられた要素を参照します。

例えばこのブログでは共通レイアウトをLayoutコンポーネントで定義しています。

type Props = {
  children: React.ReactNode
}

const Layout = ({ children }: Props) => {
  return (
    <>
      <Meta />
      <div className="min-h-screen flex flex-col">
        <main className="flex-1">{children}</main>
        <Footer />
      </div>
    </>
  )
}

Layoutコンポーネントは各所で使用されており、一例としてブログのトップページを示すpages/index.tsxでは次のように呼び出されています。

const Index = ({ allPosts }: Props) => {
  const morePosts = allPosts
  return (
    <>
      <Layout>
        <Head>
          <title>ikuma-t</title>
        </Head>
        <Container>
          <Intro />
          {<MoreStories posts={morePosts} />}
        </Container>
      </Layout>
    </>
  )
}

この時、<Layout> ~ </Layout>の間の部分がchildrenとなります。

        <Head>
          <title>ikuma-t</title>
        </Head>
        <Container>
          <Intro />
          {<MoreStories posts={morePosts} />}
        </Container>

Layoutコンポーネントでは最終的に次のような内容が描画されます。

    <div>
      <Meta />
      <div className="min-h-screen flex flex-col">
        <main className="flex-1">
    {// ここからchildrenの内容が描画されている}
          <Head>
            <title>ikuma-t</title>
          </Head>
          <Container>
            <Intro />
            {<MoreStories posts={morePosts} />}
          </Container>
    {// ここまでchildrenの内容が描画されている}
        </main>
        <Footer />
      </div>
    </div>

childrenの型

先のサンプルコードの通り、childrenの型はReact.ReactNodeです。どうもv18から仕様が変わったようで、明示的に型を指定していない状態でprops.childrenを使用すると、エラーになるようになったそうです。

参考：https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#updates-to-typescript-definitions

おわり

type-challenges easyを解きおえた

ikuma-t — Mon, 06 Jun 2022 00:00:00 GMT

https://github.com/type-challenges/type-challenges

type-challenges、easy問題の全13問を解き終えたので、一旦振り返りたいと思います。

各問題の振り返り

一言書こうと思ったのですが、終盤にいくにつれて特筆事項がなくなったので、ただの羅列です😅

:::details 各問題へのリンク

https://ikuma-t.work/posts/type-challenge-pick

type MyPick<T, K extends keyof T> = { [P in K]: T[P] }

キーワード：keyof、Indexed Access Type、Mapped Types

初見で無事ギブアップした回。最初は全くもって意味不明な記号でしたが今は見慣れました。

https://ikuma-t.work/posts/type-challenge-readonly

type MyReadonly<T> = { readonly [P in keyof T]: T[P] }

キーワード：Mapped types、readonly

当日も自力で解けたと言っています。今回も解けました。

https://ikuma-t.work/posts/type-challenge-tuple-to-object

type TupleToObject<T extends readonly string[]> = { [P in T[number]]: P }

キーワード：Tuple、Indexed Access Type、`Mapped Types

ここらへんでMapped Typesに慣れてきました。

https://ikuma-t.work/posts/type-challenge-first-of-array

type First<T extends any[]> = T extends [] ? never : T[0]
type First<T extends any[]> = T extends [infer U, ...infer Rest] ? U : never

キーワード：infer、Conditional Types, Indexed Access Types

inferキーワード初出。これも今はだいぶ見慣れてきました。

https://ikuma-t.work/posts/type-challenge-length-of-tuple

type Length<T extends any[]> = T["length"]

キーワード：Indexed Access Types

https://ikuma-t.work/posts/type-challenge-exclude

type Exclude<T, U> T extends U ? never : T

キーワード：Conditional Types、Union Types、Distributive

分配法則初登場回

https://ikuma-t.work/posts/type-challenge-awaited

type MyAwaited< T extends Promise<any>> = T extend Promise<infer U> ? MyAwaited<U> : never

キーワード：infer

再起的な型推論

https://ikuma-t.work/posts/type-challenge-if

type If<C extends boolean, T, F> = C extends true ? T : F

キーワード: Conditional Types

https://ikuma-t.work/posts/type-challenge-concat

type Concat<T extends any[], U extends any[]> = [...T, ...U]

キーワード: Variadic Tuple Types

https://ikuma-t.work/posts/type-challenge-includes

// この回はわからなかったのでコピペしました。
type Includes<T extends readonly unknown[], U> =
  T extends [infer First, ...infer Rest]
    ? Equal<First, U> extends true ? true : Includes<Rest, U>
    : false;

キーワード: Conditional Types、infer、 Variadic Tuple Types

めちゃくちゃ難しかった回です。厳密な等価評価の部分は今でもよくわかっていません。

https://ikuma-t.work/posts/type-challenge-push

type Push<T extends any[], U> = [...T, U]

キーワード: Variadic Tuple Types

https://ikuma-t.work/posts/type-challenge-unshift

type Unshift<T extends any[], U> = [U, ...T]

キーワード: Variadic Tuple Types

https://ikuma-t.work/posts/type-challenge-parameters

type MyParameters<T extends (...args: any[]) => any> = T extends (...args: infer U) => any ? U : never

キーワード： infer、Conditional Types

:::

感想

出てきたキーワードで重複しているものはConditional Types、infer、Variadic Tuple Types、Mapped Types、Indexed Access Types、keyofって感じですかね。

自分はプリミティブ型とそこそこの用語だけオライリーの本で覚えて、あとはエイやでTypeScriptの世界にきてしまったので、いわゆる「高度な型」を実際に学ぶことができているのはとても良いなあと思います。

もともとTypeScriptを勉強しようとしたきっかけは、自作サービスを作っている時に、各ライブラリのドキュメントとかソースが軒並みTS化していて、「これTypeScriptがわからないと、単位時間あたりで取得できる情報量めちゃくちゃしょぼいんじゃね」と思ったのがきっかけでした。

自分で練習で書いているコードではeasyの問題に出てくるようなコードもまだそこまで書いていませんが、本来の目的であるライブラリのソースを理解するという点では非常に役に立っていると思います。

というわけで明日からはmedium編に突入です。これまでの延長で解けるのか、はたまた撃沈するかわかりませんが、毎日1問解いていきます！

type-challenge 10日目(その2): 3312-Parameters

ikuma-t — Mon, 06 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/03312-easy-parameters/README.md

組み込みの型Parametersを実装する

やりたいことは、関数Tの引数の型を動的に取得することなので、inferを使用する。参照したらいつものパターン

type MyParameters<T extends (...args: any[]) => any> = T extends (...args: infer U) => any ? U : never

調べたこと

Parameters型

https://www.typescriptlang.org/docs/handbook/utility-types.html#parameterstype

Parametes<T>の形式で、関数Tの引数の型のタプル型を生成する。

type-challenge 10日目: 3060-Unshift

ikuma-t — Mon, 06 Jun 2022 00:00:00 GMT

問題 & 解答

Array.prototype.unshiftを型で実装する。

あれ、これ昨日とほぼ同じでは？

type Unshift<T extends any[], U> = [U, ...T]

Variadic Tuple Typeで解くことができました。

感想

Unshiftを先にやってからPushをやった方がよかったかもしれないです（Variadic Tuple Type)の位置が最後でなくても使えるというはっけんがあるから）

ブログ用のコマンド試作その4

ikuma-t — Sun, 05 Jun 2022 00:00:00 GMT

https://ikuma-t.work/posts/create-blog-command-3

前回の時点ではただファイルを生成するシェルスクリプトでしたが、今回思い切って一気に色々機能を追加しました。

というわけでできたものがこちら。

https://github.com/IkumaTadokoro/blog-cli

もともとRubyで書いていてThor gemで作ろうと思っていたのですが、インタラクティブなものを作るのが大変そうだったのと、2日前くらいから「Denoってなんかいいな」と思い始めたので、途中からDenoに切り替えて実装しました。各機能を順番に紹介していきます。

実装

Terminal window

❯ deno --version
deno 1.22.2 (release, x86_64-apple-darwin)
v8 10.3.174.6
typescript 4.6.2

Third PartyにはcliffyというCLI用のフレームワークを使用しているのみです。

https://cliffy.io/

追記: 嘘をつきました。frontmatter@v0.1.4 | Denoも使っていました。

機能一覧

Terminal window

❯ blog -h

  Usage:   blog
  Version: 0.1.0

  Description:

    ✍️ CLI tool for my blog: https://ikuma-t.work

  Options:

    -h, --help     - Show this help.
    -V, --version  - Show the version number for this program.

  Commands:

    completions  - Generate shell completions.
    list         - List the last 5 articles
    open         - Open blog in browser
    config       - Config BLOG_PATH
    new          - Create new article
    edit         - Edit article in editor.

各機能紹介

設定: `config`

Terminal window

❯ blog config
 ? 記事の格納ディレクトリを指定してください > path
 設定が完了しました

Terminal window

❯ blog config -h

  Usage:   blog config
  Version: 0.1.0

  Description:

    Config BLOG_PATH

  Options:

    -h, --help  - Show this help.

設定用のコマンドです。ブログ記事のあるパスを雑にJSONファイルにして保存しています。

補完：`completions`

Terminal window

❯ blog completions -h

  Usage:   blog completions
  Version: 0.1.0

  Description:

    Generate shell completions.

    To enable shell completions for this program add the following line to your ~/.bashrc or similar:

        source <(blog completions [shell])

        For more information run blog completions [shell] --help

  Options:

    -h, --help  - Show this help.

  Commands:

    bash  - Generate shell completions for bash.
    fish  - Generate shell completions for fish.
    zsh   - Generate shell completions for zsh.

cliffyのビルトインコマンドの1つで、各シェルの補完機能を提供します。

https://cliffy.io/docs@v0.24.2/command/build-in-commands#completions-command

私の場合はzshを使っているので、.zshrcあたりに

Terminal window

source <(blog completions zsh)

と書いてあげることで、自動的に補完が使用できるようになります。

ブログを開く： `open`

Terminal window

❯ blog open -h

  Usage:   blog open
  Version: 0.1.0

  Description:

    Open blog in browser

  Options:

    -h, --help  - Show this help.

ブラウザでブログを開きます。

一覧: `list`

Terminal window

❯ blog list -h

  Usage:   blog list
  Version: 0.1.0

  Description:

    List the last 5 articles

  Options:

    -h, --help  - Show this help.
    -a, --all   - List all articles instead of the last 5 articles

デフォルトでは最新の記事5件を取得します。-aオプション指定時には全て取得します。

表示するのは左から、

ファイル名
記事名（YAMLフロントマターから取得）
投稿日（YAMLフロントマターから取得）

です。

Terminal window

┌─────────────────────────────┬─────────────────────────────────────┬─────────────────────┐
│ name                        │ title                               │ published_at        │
├─────────────────────────────┼─────────────────────────────────────┼─────────────────────┤
│ join-mdn-translate-event.md │ MDNドキュメントの翻訳に参加                 │ 2022-06-18          │
├─────────────────────────────┼─────────────────────────────────────┼─────────────────────┤
│ sample.md                   │ サンプルの記事                           │ 2022-06-05 22:06:58 │
├─────────────────────────────┼─────────────────────────────────────┼─────────────────────┤
│ create-blog-command-4.md    │ ブログ用のコマンド試作その4                   │ 2022-06-05 21:06:49 │
├─────────────────────────────┼─────────────────────────────────────┼─────────────────────┤
│ type-challenge-push.md      │ type-challenge 9日目: 3057-Push     │ 2022-06-05 15:06:43 │
├─────────────────────────────┼─────────────────────────────────────┼─────────────────────┤
│ type-challenge-unshift.md   │ type-challenge 10日目: 3060-Unshift │ 2022-06-05 15:06:11 │
└─────────────────────────────┴─────────────────────────────────────┴─────────────────────┘

出力はcliffyのTableを使用しています。

https://cliffy.io/docs@v0.24.2/table

日本語が全体的にダメで、ちょっとずれてしまっているんですが、実害がないので無視しています。

新規作成: `new`

Terminal window

❯ blog new -h

  Usage:   blog new
  Version: 0.1.0

  Description:

    Create new article

  Options:

    -h, --help  - Show this help.

タイトルとファイル名を指定して記事を作成します。

cliffyのInput promptにはlocal storageもしくは配列を使用して入力値をサジェストできる機能があります。

https://cliffy.io/docs@v0.24.2/prompt/types/input#auto-suggestions

シリーズものの記事を書く際に、以前の回の記事名などを参照することがあるので、過去記事を配列につっこんでカーソルキーで候補が出るようになっています。

編集: `edit`

Terminal window

❯ blog edit -h

  Usage:   blog edit
  Version: 0.1.0

  Description:

    Edit article in editor.

  Options:

    -h, --help              - Show this help.
    -e, --editor  <editor>  - Choose your editor. Default is vim  (Default: "vim")

ファイルを指定して編集します。エディタはオプションで指定できるのですが、デフォルトはvimです（たまにmiで登録しているRubyMineで編集することがあります）。

cliffyのSelect promptにファイル名を投げて選択しているのですが、便利なのがenable-search-inputです。search: trueを指定することで、インクリメンタル検索ができるようになります。これはとても嬉しい…!

https://cliffy.io/docs@v0.24.2/prompt/types/select#enable-search-input

感想

とりあえず作ってみたんですが、候補から選択できるのがかなり便利ですね。これを作成する前は、似たような記事を一度別で開いてコピーして…みたいなことをやっていたので、生産性めちゃくちゃ上がりました。

Denoはこれの前に練習として、deno-jpsumという、ダミー文作成メーカーLorem JpsumをCLI化したものを作っていましたが。

https://github.com/IkumaTadokoro/deno-jpsum

が、まだ仕様があまり頭に入っていないのと、そもそもTypeScript自体を最近始めたので、全体的にコードがお粗末です…。

とはいえ、Denoは標準でFormatterやLinterを提供しているし、TypeScriptも設定なしで使えるし、cliffyは多機能だし、CLIツールの開発体験としては非常によかったです。

今後もDenoやっていくぞ！

type-challenge 9日目: 3057-Push

ikuma-t — Sun, 05 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/03057-easy-push/README.md

ジェネリクス版のArray.prototype.pushを実装する。

これはえ〜と、Variadic Tuple Typesですね。Tの型を展開することができます。

type Push<T extends any[], U> = [...T, U]

感想

ブルーベリー本を買ったので、Variadic Tuple Typesについてもみてみました。「6.7.3 可変長タプル型」に載っていました。

https://ikuma-t.work/posts/type-challenge-concat

この回でも書いたのですが「...で展開される型はextends readonly any[]ようです。

any[]はまあいいんですけど、ただの配列だったらreadonlyはいらないのかな〜。

type-challenge 8日目: 898-Includes

ikuma-t — Sat, 04 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00898-easy-includes/README.md

JavaScriptのArray.includesを型で実装する。

はじめはこういう回答を考えました。

type Includes<T extends readonly any[], U> = U extends T[number] ? true : false;

が、全然ダメでした…。

// 全部落ちているテストケースです
Expect<Equal<Includes<[{}], { a: 'A' }>, false>>,
Expect<Equal<Includes<[boolean, 2, 3, 5, 6, 7], false>, false>>,
Expect<Equal<Includes<[true, 2, 3, 5, 6, 7], boolean>, false>>,
Expect<Equal<Includes<[{ a: 'A' }], { readonly a: 'A' }>, false>>,
Expect<Equal<Includes<[{ readonly a: 'A' }], { a: 'A' }>, false>>,
Expect<Equal<Includes<[1], 1 | 2>, false>>,
Expect<Equal<Includes<[1 | 2], 1>, false>>,

全然わからなかったので、今回は答えを見ました。見つけた回答がこちら

type Includes<T extends readonly unknown[], U> =
  T extends [infer First, ...infer Rest]
    ? Equal<First, U> extends true ? true : Includes<Rest, U>
    : false;

https://github.com/type-challenges/type-challenges/issues/1568

順番に読み下していきます。

type Includes<T extends readonly unknown[], U>

型Includesは第1引数（配列）、第2引数を受けます。

T extends [infer First, ...infer Rest]

inferキーワードとVariadic Tuple Typesを利用して、配列Tの最初の要素の型情報をFirstとして、以降の要素がある場合にそれらの型情報をRestとして推論します。

以下はそれぞれinferとVariadic Tuple Typesが出た回です。

https://ikuma-t.work/posts/type-challenge-first-of-array

https://ikuma-t.work/posts/type-challenge-concat

T extends [infer First, ...infer Rest] ? @ : false

Conditional Typesの一つ目の分岐で一旦脳をセーブします。ここの部分で、なんらかの配列であればtrue、そうでなければfalseを返す型になります。ここから始まるRecursiveな型探索のbase caseです。

では次に進みます。

Equal<First, U> extends true

Equal型はtype-challengeがutilityとして定義している独自の型で、次のように定義されています。

type Equal<X, Y> = (<T>() => T extends X ? 1 : 2) extends <T>() => T extends Y ? 1 : 2 ? true : false

ちょっとここを読むのは時間がかかりそうなので、一旦は「XとYの型が同じかどうかを判定する」と認識しておきます。

https://zenn.dev/razokulover/articles/890102685d5ea2

https://github.com/microsoft/TypeScript/issues/27024

https://stackoverflow.com/questions/68961864/how-does-the-equals-work-in-typescript

話を戻します。

Equal<First, U> extends true : Includes<Rest, U>

先程inferで推論されたFirstと、ジェネリクスUが等しいかをチェックし、同じであればtrue、そうでなければ残りのパラメータを使用して同じ処理を実施します。

type Includes<T extends readonly unknown[], U> =
  T extends [infer First, ...infer Rest]
    ? Equal<First, U> extends true ? true : Includes<Rest, U>
    : false;

一致する型が存在するまで要素を探索し、見つからなかった場合にはfalseが返るという仕組みでした。

調べたこと

`Array.prototype.includes`

特定の要素が配列に含まれているかどうかをbooleanで返すメソッド。第2引数で検索を開始するインデックスを指定することができる（省略可能）。

const fruits = ['apple', 'banana', 'orange']

// searchElementのみを指定する
fruits.includes('cherry')
// false
fruits.includes('apple')
// true

// fromIndexを指定する
fruits.includes('apple', 0)
// true
fruits.includes('apple', 1)
// false

感想

今日はめちゃくちゃ難しかったです…。type-challengeでユーティリティとして提供されている型Equalsを使っていましたが、実質2個定義しないと解けなかった訳ですね。

Equalsのところを、シンプルにFirst extends Uとか[First, U] extends [U, First]とか試してみたんですが、readonlyを抜けられなかったり、booleanにfalseが通ってしまったりと、意外と抜け漏れがあり、これはTypeScriptの内部的な比較を知らないと解けないなあと思いました。 TypeScriptなにもわからん…。

あと問題に載っているサンプルがなぜかジョジョだったのですが、作者の方は日本人の方でした。

type isPillarMen = Includes<['Kars', 'Esidisi', 'Wamuu', 'Santana'], 'Dio'> // expected to be `false`

type-challenge 7日目（その2）: 533-Concat

ikuma-t — Fri, 03 Jun 2022 00:00:00 GMT

問題 & 解答

JavaScriptのArray.concatを型システムで構成する。

Variadic Tuple Typesを使って次のように定義する

type Concat<T extends any[], U extends any[]> = [...T, ...U]

調べたこと

Variadic Tuple Types

タプル型の中でに...Tと書ける機能
...で展開される方はextends readonly any[]を満たす必要がある。
ちなみにVariadicは「可変長引数」

TypeScript: Documentation - TypeScript 4.0

感想

Variadic Tuple Typesという名前がわからないまま、「こんな感じにできそうかな」と思ったら通ってしまいました。 TypeScript難しい…

type-challenge 7日目: 268-If

ikuma-t — Fri, 03 Jun 2022 00:00:00 GMT

問題 & 解答

https://github.com/type-challenges/type-challenges/blob/main/questions/00268-easy-if/README.md

条件CがtruthyであればTを、falsyであればFを返すIfを実装する。

type If<C extends boolean, T, F> = C extends true ? T : F

感想

さすがにConditional Typesは慣れてきました。

type-challenges 6日目: 189-Awaited

ikuma-t — Thu, 02 Jun 2022 00:00:00 GMT

問題 & 解答

Promise 風な型が持っている型を取得する方法を考える。

type X = Promise<string>; // stringを取り出す。
type Y = Promise<{ field: number }>; // { filed: number } を取り出す
type Z = Promise<Promise<string | number>>; // string | numberを取り出す

最初はこういうことかなと思って、ConditionalTypes の中で infer を利用するような形で解いてみたのですが、Promise<Promise<string | number>>のように Promise がネストしている場合に引っ掛かりました。

type MyAwaited<T extends Promise<any>> = T extends Promise<infer U> ? U : never;

というわけで再帰的に中を掘っていくやつです。

type MyAwaited<T extends Promise<any>> = T extends Promise<infer U>
  ? U extends Promise<any>
    ? MyAwaited<U>
    : U
  : never;

感想

今回の問題はinferにちゃんとたどり着けるかどうかが肝だなと思いました。

ConditionalTypes でネストする場合って、どこで改行するのが正解なんだろうというのは少し疑問です。

type-challenges 5日目: 43-Exclude

ikuma-t — Wed, 01 Jun 2022 00:00:00 GMT

問題 & 解答

組み込みのExclude<T, U>を自前で実装する

Conditional Typesの分配法則を用いて、次のように記述する。

type MyExclude<T, U> = T extends U ? never : T

例えば

T："a" | "b" | "c" | "d"
U："c" | "d" | "e" | "f"

であるとき、まず"a"はUのサブセットではないので、Tつまり"a"が返る。一つ飛ばして"c"はUのサブセットなので、neverが返る。

分配法則によりこれらの結果を結合したものが返るのでMyExclude<"a" | "b" | "c" | "d", "c" | "d" | "e" | "f">は"a" | "b"をあらわす

調べたこと

Exclude型

差集合を表す型

// Exclude<UnionType, ExcludedMembers>

// (a, b, c)
type T0 = Exclude<"a" | "b" | "c", "a">
// type T0 = "b" | "c"

type T1 = Exclude<"a" | "b" | "c" | "d", "c" | "d" | "e" | "f">
// type T1 = "a" | "b"

TypeScript: Documentation - Utility Types

Conditional TypesとDistributive（分配法則）

Conditional types がGeneric型である時、Union型が渡された場合は、分配法則に従う。

// 各Tがanyでを満たせば`T[]`を返す
type ToArray<T> = T extends any ? T[] : never;

type StrArrOrNumArr = ToArray<string | number>;

StrArrOrNumArrでは、TとしてUnion型のstring | numberが与えられている。

// StrArrOrNumArrの右辺は次のようになる(ちょっと表現としては変だけど）
(string | number) extends any ? T[] : never

// 分配法則により次のように読み下せる
(string extends any ? string[] : never) | (number extends any ? number[] : never)

// anyはすべてを満たすので`StrArrOrNumArr`はこうなる
string[] | number[]

type-challenges 4日目: 14-First of Array

ikuma-t — Tue, 31 May 2022 00:00:00 GMT

問題 & 解答

type-challenges/README.md at main · type-challenges/type-challenges

配列Tを受け取って、その配列の最初の要素の型をとるようなジェネリクスFirst<T>を実装する。

type arr1 = ['a', 'b', 'c']
type arr2 = [3, 2, 1]

type head1 = First<arr1> // expected to be 'a'
type head2 = First<arr2> // expected to be 3

Conditional Typesを利用して、要素がある場合には1番目の要素の型を返すようにする

type First<T extends any[]> = T extends [] ? never : T[0]

別解を見ていたら、inferを使っているケースもありました

type First<T extends any[]> = T extends [infer first, ...infer _Rest] ? first : never

inferキーワードを使ってfirstという名前で配列の1番目の要素の型を推論している。...infer _Restの部分はrest parametersを使って、配列の残りの要素の方を_Restに押し込んでいる。といっても今回は使用しない型なので_始まりにしているっぽいです。

調べたこと

Conditional Types（条件型）

条件に応じて動的に型を定義する方法

type IsString<T> = T extends string ? true : false

inferキーワード

条件の一部としてジェネリック型を宣言できる機能。conditional typesのextendsの条件部分に限定して使用することができる
infer Uの形式で推論した型情報をUとして扱うことができるようになる。

type SecondArg<F> = F extends (a: number, b: infer B) => string ? B : never

このサンプルでは、渡された関数Fが、number型の第1引数と何かしらの第2引数を持ち、stringを返す関数である場合、第2引数の型をinferで推論して返すというもの。

never型

neverは決して戻ることのない関数の型。無限ループや単純に例外をthrowするような関数の戻り値
他の全ての型のサブタイプであるbottom型：値を持たない型
どんな変数も入れることができない | どんな方にも入れることができる
無限ループや

Index Accessed Types

Lookup Typesと同じ。type-challenges 3日目: 11-Tuple to Object | ikuma-tに書いてある「配列の要素の型を取得する」と同じ
公式：TypeScript: Documentation - Indexed Access Types
Lookup Typesと同じであることのソース：TypeScript: Documentation - Overview
- indexed access types, also called lookup types

感想

今日は条件分岐型を覚えました。1週間前くらいまではジェネリクス型見たら「うわっ」って感じだったんですけど、だいぶ慣れてきました。（感覚としてはギター始めたての頃のBm7-5に近い）

手元にオライリーのプログラミングTypeScriptをおいてリファレンス的に使っているんですが、第4版が2021年発行なので、ちょっと情報が古いかもと思い始めています。もう一冊くらい手元においておいてもよいかなあ。

type-challenges 4日目（その2）: 18-Length of Tuple

ikuma-t — Tue, 31 May 2022 00:00:00 GMT

問題 & 解答

type-challenges/README.md at main · type-challenges/type-challenges type-challenges/README.md at main · type-challenges/type-challenges

タプルが与えられるので、その長さを型とするLengthを実装する

type tesla = ['tesla', 'model 3', 'model X', 'model Y'] as const
type spaceX = ['FALCON 9', 'FALCON HEAVY', 'DRAGON', 'STARSHIP', 'HUMAN SPACEFLIGHT'] as const

type teslaLength = Length<tesla>  // expected 4
type spaceXLength = Length<spaceX> // expected 5

constアサーションが適用されているので、readonlyな配列Tを定義する。 Array.prototypeのインスタンスプロパティlengthを指定して、長さを取得する。

type Length<T extends readonly any[]> = T['length']

調べたこと

Array.prototype.length

Array.length - JavaScript | MDN

length は Array 型のインスタンスであるオブジェクトのプロパティで、配列の要素の数を設定または取得します

感想

今回はIndex Accessed Typesとプロトタイプチェーンの復習でした。

最初にPickを解いた時は「これでeasyかよ！」と思ったりしていましたが、だんだん妥当に感じるようになってきました。でもeasyで高度な型がでているってことは、mediumはえげつないのかな。

IkumaScriptと37進数

ikuma-t — Mon, 30 May 2022 00:00:00 GMT

ikuma, akuma, xkuma, ukuma…

JSやTSのサンプルコードで、よく自分の名前ikumaを一文字変えて使っているのだけれど、毎回入力するのも面倒なので、スニペット化しました。ikumaを複製するので、ECMAScriptを文字ってIkumaScriptです。

[...Array(26)].map((_, index) => `${(index + 10).toString(36)}kuma`)

// [ 'akuma', 'bkuma', 'ckuma', 'dkuma', 'ekuma', 'fkuma', 'gkuma', 'hkuma', 'ikuma', 'jkuma', 'kkuma', 'lkuma', 'mkuma', 'nkuma', 'okuma', 'pkuma', 'qkuma', 'rkuma', 'skuma', 'tkuma', 'ukuma', 'vkuma', 'wkuma', 'xkuma', 'ykuma', 'zkuma' ]

親の顔よりよくみた連番作成処理を行います。

[...Array(26)].map((_, index) => index)
// [ 0,  1,  2,  3,  4,  5,  6,  7, 8,  9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 ]

実際には+ 10しているので10 ~ 35までの値を含む配列が取得できます。

ここからN進数を利用してアルファベットに変換を行っていきます。文字としての数字は0から9までの10種類しかないので、36進数に変換すると、10 ~ 35がそれぞれa ~ zに相当することになります（36 - 10 = 26個のアルファベットが必要になる）

37進数にはどの記号が採用されるのか

ここでふと疑問に思うのが、37進数以降の場合、アルファベットで賄えない部分はどうなるのかということです。実際にやってみました。

 (36).toString(37)
// Uncaught RangeError: toString() radix argument must be between 2 and 36
    at Number.toString (<anonymous>)

Number.prototype.toString() - JavaScript | MDNにも記載がありましたが、37以上はエラーになるようですね。

Rubyでも試してみます。

36.to_s(37)
# => (irb):3:in `to_s': invalid radix 37 (ArgumentError)

Integer#inspect (Ruby 3.1 リファレンスマニュアル)

こちらもリファレンスに記載がありましたが、37以上を指定するとエラーになるようです。

おわりに

ikumaという名前が名付けられた経緯には色々な意味があるのですが、時代背景的に悪魔ちゃん命名騒動 - Wikipediaがあったこともあり、あえて一文字ずらして「ikuma」になったみたいな理由もあると以前母から聞きました。

1文字どころかたくさんずらして遊んでます。 — 息子より

type-challenges 3日目: 11-Tuple to Object

ikuma-t — Mon, 30 May 2022 00:00:00 GMT

問題 & 解答

type-challenges/README.md at main · type-challenges/type-challenges

タプルを受け取り、その各値のkey/valueを持つオブジェクトの型に変換する型を実装する

const tuple = ['tesla', 'model 3', 'model X', 'model Y'] as const

type result = TupleToObject<typeof tuple> // expected { tesla: 'tesla', 'model 3': 'model 3', 'model X': 'model X', 'model Y': 'model Y'}

文字列型の配列を受け取り、各要素をキーと値に持つオブジェクトとしてマッピングする。

type TupleToObject<T extends readonly string[]> = { [P in T[number]]: P }

// このテストケース特有なら以下の方がいいかもしれない
type TupleToObject<T extends readonly [string, string, string, string]> = { [P in T[number]]: P }

調べたこと

Tuple型

タプルは配列のサブタイプで、固定長の配列を片付けするための特別な方法
配列の各インデックスでの値は特定の既知の型を持つ
タプルと配列の構文は同じであり、またTypeScriptは配列に対して型推論するためのルールを持っているため、タプルを宣言する際には明示的に型を宣言する必要がある。

let a: [number] = [1]
let b: [string, string, number] = ['ikuma', 'takuma', 2]

参考：O’Reilly Japan - プログラミングTypeScript

const assertion

as constを末尾に記述することで、再帰的にreadonly`にする仕組み

参考：constアサーション「as const」 (const assertion) | TypeScript入門『サバイバルTypeScript』

インデックスシグネチャ

{ [key: T]: U }：このオブジェクトの型Tのすべてのキーは型Uの値を持たなければならない
オブジェクトのキーを抽象的に定義する方法。

配列の要素の型を取得する

number型の添字を使うと配列から要素の型を取得することができる。
タプルの場合は、0、1またはアクセスしたいインデックスを表す数値リテラル型を使う

readonlyな配列

いくつかの定義方法がある

// readonly T[]
const names: readonly string[] = ['akuma', 'bkuma', 'ckuma']

// ReadonlyT[]>
const names: Readonly<string[]> = ['akuma', 'bkuma', 'ckuma']


// ReadonlyArray<T>
const names: ReadonlyArray<string> = ['akuma', 'bkuma', 'ckuma']

タプルの場合は次のように定義する

// readonly
const names: readonly [number, string] = ['akuma', 'bkuma', 'ckuma']

// Readonly
const names: Readonly<[number, string]> = ['akuma', 'bkuma', 'ckuma']

感想

解いた後に回答をみたら、any[]で受け取っている人もいたり、string[]で受け取っている人もいたり、何がいいんだろうと思いました。自分はもともと「タプルなんだから、[string, string, string, string]で受け取るだろう」と思ってやっていたのですが、そういう感じでもないんですかね。

Next.jsで作成したブログにRSS機能を追加する

ikuma-t — Sun, 29 May 2022 00:00:00 GMT

このブログにRSS機能を実装したので、メモを残しておきます。

RSSについて

RSSの概要

具体的な実装の前にRSSそのもの仕組みを確認していきます。

RSSとは、“Rich Site Summary”の略で、サイトの概要を記述する為のXML形式の文書のこと
提供されたRSSのことをRSSフィードという

RSSの拡張子

以下の2種類がある
- RDF：Resource Description Framework
- XML

RSSの歴史

RSS 0.9：NexScape社が自社のポータルサイトで使用したのが始まり。元々はRDFを使用していたので、「RDF site summary」と呼ばれていた
RSS 0.91：XMLで記述される。より多くの情報が配信できるようになったため、「rich site summary」と呼ばれるようになる
RSS 1.0：NetScape社がRSS開発から撤退したことにより、「RSS-DEV Working Group」と「Dave WinnerとUserLand Software社」の二派に分かれる。1.0は前者により実装されたもので、RDFで実装されている
RSS 2.0：RSS1.0の実装方針（拡張子、名前空間の複雑化）は一部層から不満があるものであったため、UserLand Software社はRSS 0.91からの派生（≠RSS 1.0の後継）としてRSS 0.92~0.94をXMLで実装した。2003年にDave Winnerが移籍したことにより、この流れを汲むRSS 2.0系はハーバード大学へ移管された。

Atom

Atomも配信形式の一つである
RSSは上記のような論争があるため、しがらみのないところで始めたいという動悸もあってAtomが生まれた。
RFC 4287 - The Atom Syndication Format

参考

RSS機能の実装

このブログはSSGを利用しているため、getStaticPropsの中でfeedを作成するように追加します。実際に行った変更は以下の部分です。

https://github.com/IkumaTadokoro/blog/pull/1/files

タスクとしてはこんな感じです。

RSSフィードを生成する処理を作成する（generateRssFeed）
- feed - npmを導入する
- FeedクラスをnewしてRSSフィードの基本設定をする
- Feed#addItemで記事のRSSフィードを登録する
- public/rss配下に各仕様ごとのRSSフィードを出力する
getStaticPropsの中でgenerateRssFeedを呼び出す

RSS自体の仕様がよく分からなくてとりあえずで作ってみたら、リーダーの中でコンテンツが表示されず、RSS 2.0 Specification 日本語訳 - futomi’s CGI Cafeを参考にして値を設定し直しました。

そのため、Feedlyに一度コンテンツがないRSSフィードが載っかってしまったのですが、どうもFeedlyは一度載っかったフィードはFeedly側でキャッシュされてしまうらしく、今もFeedly上の最初の数本の記事のコンテンツはなくなったままです…。どこか別のところで試せばよかった…。

type-challenges 2日目: 7-Readonly

ikuma-t — Sun, 29 May 2022 00:00:00 GMT

問題 & 回答

type-challenges/README.md at main · type-challenges/type-challenges

組み込みのユーティリティ型Readonlyを使用しないで、Tのすべてのプロパティを読み取り専用にする

interface Todo {
  title: string
  description: string
}

const todo: MyReadonly<Todo> = {
  title: "Hey",
  description: "foobar"
}

todo.title = "Hello" // Error: cannot reassign a readonly property
todo.description = "barFoo" // Error: cannot reassign a readonly property

mapped typeを利用して、Tをすべて読み取り専用にします。

type MyReadonly<T> = { readonly [K in keyof T]: T[K] }

調べたこと

readonly修飾子

オブジェクトのフィールドを読み取り専用に指定するための修飾子

Readonly型

Readonly<T>は、オブジェクト型Tのプロパティをすべて読み取り専用にするユーティリティ型。挙動は今回実装したMyReadonly<T>と同じ
参考：TypeScript: Documentation - Utility Types

感想

今日は昨日の発展系だったので、自力で解けました！ TypeScript初めて数日の身からすると、まずは型の見た目に拒絶反応を起こさないようにすることが大切なので、このtypechallengesはいいですね〜。明日も頑張ります。

「今日のesa」という自分用のChrome拡張を作ってみた

ikuma-t — Sat, 28 May 2022 00:00:00 GMT

FJORD BOOT CAMPを卒業したことにより日報の提出先がなくなってしまったので、自分でesaに登録するようにしていたのですが、今日の分の日報を作るのが面倒 & 結構頻繁に別のページに飛んでしまって、今日の日報ページに戻るのが面倒だったので、とても雑にChrome拡張を作りました。

IkumaTadokoro/kyo-no-esa: (Chrome Extension) Add kyo-no-esa button in the sidebar of esa.io that opens or create today’s diary

GitHubはREADMEすら治してません…自分用なので。

使い方

上記PJをcloneして、npm run buildでdistフォルダに出力します。
Chrome側で「パッケージ化されていない拡張機能を読み込む」でdistフォルダを指定します。
「拡張機能のオプション」からオプションページを開き、諸々設定します。
esaのページのサイドバーに「今日のesa」がでてくるのでクリックします。今日の日報があればそれを、なければ新規作成画面に移ります（テンプレートがある前提）

感想

「Chrome拡張作ってみたいな」と前々から思っていたので、Vite + TypeScript + Vueで作ってみました。

これくらいの規模の拡張機能なら割とあっさりできるんですが、結構ゴリ押しで進めてしまったので、次はもう少ししっかり設計を練ってから挑みたいです。

RubyとJavaScriptにおける正規表現

ikuma-t — Sat, 28 May 2022 00:00:00 GMT

正規表現系のメソッドがいつもごちゃごちゃになって、その場その場でリファレンスを見ているので、このタイミングでまとめてみます。

正規表現に対するメソッド体系

用途	Ruby	JavaScript
正規表現のパターンにマッチした最初の部分を文字列に置換する	String#sub	String.prototype.replace
正規表現のパターンにマッチしたすべての部分を文字列に置換する	String#gsub	String.prototype.replaceAll
正規表現のパターンにマッチする文字のインデックスを返す	String#=~	String.prototype.search
正規表現のパターンにマッチする文字列を返す	String#match or Regexp#match	String.prototype.match
正規表現のパターンにマッチするかどうかをbooleanで返す	String#match? or Regexp#match?	RegExp.prototype.test
正規表現のパターンにマッチする文字列すべてを返す	String#scan	String.prototype.matchAll

ちょっと試してみた

正規表現のパターンにマッチした最初の部分を文字列に置換する

'ikuma-t, yamada-d, tanaka-p, okurag, tarou-d'.sub(/-/, '~')
#=> "ikuma~t, yamada-d, tanaka-p, okurag, tarou-d"

'ikuma-t, yamada-d, tanaka-p, okurag, tarou-d'.replace(/-/, '~')
// 'ikuma~t, yamada-d, tanaka-p, okurag, tarou-d'

正規表現のパターンにマッチしたすべての部分を文字列に置換する

'ikuma-t, yamada-d, tanaka-p, okurag, tarou-d'.gsub(/-/, '~')
#=> "ikuma~t, yamada~d, tanaka~p, okurag, tarou~d"

'ikuma-t, yamada-d, tanaka-p, okurag, tarou-d'.replaceAll(/-/g, '~')
//  'ikuma~t, yamada~d, tanaka~p, okurag, tarou~d'

JavaScriptのString.prototype.replaceAllを使用する際には、グローバルフラグを持つRegExpオブジェクトを指定する必要がある。

正規表現のパターンにマッチする文字のインデックスを返す

'ikuma-t' =~ /.*-./
# => 0

'ikumat' =~ /.*-./
# => nil

'ikuma-t'.search(/.*-./)
// 0

'ikumat'.search(/.*-./)
// -1

正規表現のパターンにマッチする文字列を返す

# Regexp#matchの方を使っています
/.*-./.match('ikuma-t')
# => #<MatchData "ikuma-t">

/.*-./.match('ikumat')
# => nil

'ikuma-t'.match(/.*-./)
// [ 'ikuma-t', index: 0, input: 'ikuma-t', groups: undefined ]

'ikumat'.match(/.*-./)
// null

正規表現のパターンにマッチするかどうかをbooleanで返す

/.*-./.match?('ikuma-t')
# => true

/.*-./.match?('ikumat')
# => false

/.*-./.test('ikuma-t')
// true

/.*-./.test('ikumat')
// false

正規表現のパターンにマッチする文字列すべてを返す正規表現のパターンにマッチする文字列すべてを返す

'ikuma-t'.scan(/[aiueo]/)
# => ["i", "u", "a"]

['ikuma-t'.matchAll(/[aiueo]/g)]
// [ [ 'i', index: 0, input: 'ikuma-t', groups: undefined ], [ 'u', index: 2, input: 'ikuma-t', groups: undefined ], [ 'a', index: 4, input: 'ikuma-t', groups: undefined ] ]

JavaScriptのString.prototype.matchAllを使用する際には、グローバルフラグを持つRegExpオブジェクトを指定する必要がある。

remarkでtableのMarkdownを解釈できるようにする

ikuma-t — Sat, 28 May 2022 00:00:00 GMT

tableはCommonMarkdownではない

このブログはremarkを使用してMarkdownをパースしているわけですが、tableを投稿してみたところ原文のまま表示されてしまいました。

なんでかな〜と思って調べてみると、unifiedjsのドキュメントに

Tables are a non-standard feature in markdown: they are not defined in CommonMark and will not work everywhere.

という記述を見つけました。tableのスタイルってGitHub Flavored Markdownなんですね〜。というわけでGitHub Flavored Markdownもパースできるように改修していきます。

remark-gfmを適用する

Terminal window

yarn add remark-gfm

import { remark } from 'remark'
import html from 'remark-html'
import prism from 'remark-prism'
// remarkGfmを追加する
import remarkGfm from 'remark-gfm'

export default async function markdownToHtml(markdown: string) {
  const result = await remark().use(html, { sanitize: false }).use(prism).use(remarkGfm).process(markdown)
  return result.toString()
}

ここまでで、tableタグとして解釈されるようになりました。

スタイルを適用する

シンプルにtable関連タグが適用されているだけなので、それに従ってスタイルを適用します。このブログではTailwind CSSを利用しているので、次のような感じです。

table {
  @apply w-full text-sm text-left text-gray-500 overflow-x-auto shadow-md sm:rounded-lg;
}

thead {
  @apply text-sm text-gray-700 bg-gray-50;
}

th {
  @apply px-6 py-3;
}

tr {
  @apply border-b;
}

td {
  @apply px-6 py-3;
}

これでいい感じにテーブルが表示されるようになりました。

type-challenges 1日目: 4-Pick

ikuma-t — Sat, 28 May 2022 00:00:00 GMT

問題 & 回答

type-challenges/README.ja.md at main · type-challenges/type-challenges

Pick<T, K>：Utility Typesの一つ。既に存在するT型の中からKで選択した一部のプロパティのみを含んだ新たな型を構築する。
これを独自に実装すると次のような形式になる

type MyPick<T, K extends keyof T> = { [S in K]: T[S] }

調べたこと

ルックアップ型

定義済みの型["キー"]とすることで、指定したキーに対応する型を取り出すことができる。

type Todo = {
  id: number
  title: string
  comment: string
}

// キー`id`の型`number`を取得する
type Id = Todo['id']

const id: Id = '1' // TS2322: Type 'string' is not assignable to type 'number'.

`keyof`演算子

オブジェクトの全てのキーを、文字列リテラル型のUnion型として取得する。

type Todo = {
  id: number
  title: string
  comment: string
}

type TodoKeys = keyof Todo // type TodoKeys = "id" | "title" | "comment"

マップ型（`mapped type`）

オブジェクトのキーの型と値の型をマッピングするための方法。どの値の型がどのキーの名前に対応するかを制約できる

// P：Parameter（引数型）
// K：Constraint（制約型）
// T：Template（テンプレート型）
{  [P in K]: T}

ここまでの内容を踏まえると次のようになる。

interface Todo {
  title: string
  description: string
  completed: boolean
}

type MyPick<T, K extends keyof T> = { [S in K]: T[S] }

// { 'title': string, 'completed': boolean }
// keyofを使用しているので、`contents`とかTodoにないキーを指定するとエラーになる
type TodoPreview = MyPick<Todo, 'title' | 'completed'>

const todo: TodoPreview = {
    title: 'Clean room',
    completed: false,
}

感想

初日から全然とけなかったんですが…。型を理解するためにこれを始めたので、根気強くやっていきたいと思います！

Gemfileにある`require: false`ってなんでしたっけ？

ikuma-t — Sat, 28 May 2022 00:00:00 GMT

Gemfileで度々でてくるrequire: false。ざっくり理解はしているけど、ちゃんと公式ドキュメントを読んでいなかったので、思い出しついでに読んでいく。

まずrequire: falseのそもそもの意味はBundler: gemfileに記載があって、

false to prevent any file from being autorequired.

つまり、自動でrequiredしないようにするには、require: falseと書くことになる。

Bundlerを使用していない場合、通常requireを各ファイルで各gemに対して書く必要があるが、Bundlerにはロードを行うパスの解決を行うBundler.setupとそこで指定されたGemを自動的にrequireするBundler.requireという機能があり、これによりGemfile記載のgemは全て自動でrequireされる。

これを無効にするのがrequire: falseである（デフォルトがtrue）

どういう場面で使用するかというと、「依存関係は管理したいが、アプリでは使用しない」といったケースで使用する。例えばRakeタスクで自動的にデータを取得するのに使用しているけれども、アプリで使うのはデータであって、そのgem自体は使用しない、みたいな場合にrequire: falseを指定してあげるといった例がある。

「Bundler.setupとかBundler.requireとかあまり使ったことないんだけど…」となるものそのはずで、Railsの場合はフレームワーク側でそれが組み込まれているので普段は意識しない。

Bundker.setupはconfig/boot.rbに記載されている。

ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../Gemfile", __dir__)

require "bundler/setup" # Set up gems listed in the Gemfile.

Bundler.requireはconfig/application.rbに記載されている。

require_relative "boot"

require "rails/all"

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)
...

ブログ用のコマンド試作その1

ikuma-t — Fri, 27 May 2022 00:00:00 GMT

雑に投稿するためのコマンドを作ってみた。ファイルがなければmarkdownファイルと画像格納用のディレクトリを作成し、ファイルがあればmarkdownファイルを開く。

#!/bin/bash

if [ -e ~/blog/_posts/$1.md ]; then
    vim ~/blog/_posts/$1.md
else
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

あまりにも雑すぎるけど、これでどこにいてもターミナル上でささっとブログがかける。

1日1問、半年以内に習得シェル・ワンライナー160本ノック：書籍案内｜技術評論社をみてシェルスクリプトに親しむか、もはやzxを使ってTypeScriptで書いた方がよさそう。

ブログ用のコマンド試作その3

ikuma-t — Fri, 27 May 2022 00:00:00 GMT

初回作成時に2回コマンドを叩くのはめんどいだろうということで、if文を変えた。

#!/bin/bash

if [ ! -e ~/blog/_posts/$1.md ]; then
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

vim ~/blog/_posts/$1.md
cd ~/blog
git add ~/blog/_posts/$1.md
git commit -m "feat: update post"
git push
cd -

これでblog hogeとすれば、その瞬間に記事を書くことができる。

ブログ用のコマンド試作その2

ikuma-t — Fri, 27 May 2022 00:00:00 GMT

ブログ用のコマンド試作の続き。もはや保存した瞬間にデプロイしてしまって良いのではと思ったので、ただただgit pushするまでのコマンドを組み込んだ

#!/bin/bash

if [ -e ~/blog/_posts/$1.md ]; then
    vim ~/blog/_posts/$1.md
    cd ~/blog
    git add ~/blog/_posts/$1.md
    git commit -m "feat: update post"
    git push
    cd -
else
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

画像とかを入れていきたい場合は微妙な感じがするけど、そういう場合はエディタちゃんと開いてやるし、ターミナルでささっと学習メモをあげるにはこれで十分なのでは？と思っていたりする。しばらくこれで運用してみます。

ブログをNext.jsで作りました

ikuma-t — Thu, 26 May 2022 00:00:00 GMT

はてなブログのエディタをわざわざ開いて書いていくのが非常に面倒で、TypeScript→React→Nextの順で学んでNext.jsでブログを作ろうと思っていたけど、だいぶ時間がかかるので、ささっとtemplateを使って作りました（レイアウトだけ少し整えた）

Markdownをおいたら公開されるようにはなっているんですが、最小工数で記事公開まで持って行けるようにしたいので、コマンド一発で作業できるといいなあと思っています。

Terminal window

# これでmarkdownファイルと画像用のディレクトリが作成されて、適当にフロントマターを入れてくれる感じにしたい
$ blog sample-title

Google Meetで相手の画面やプレゼンテーションが見えないときの対処法

ikuma-t — Mon, 18 Apr 2022 18:41:03 GMT

Table of contents
相手が見えない…
結論
詳細
- バージョン
- 設定：受信時の解像度（最高）
終わりに

相手が見えない…

先日Google Meetでお話をする機会があったのですが、相手のプレゼンテーションやお顔がまったくみえないという事象に出くわしました…。

お相手の別の端末で会議に参加していただいたところ、すべて映っていたところから「これは自分側に問題があるぞ」と切り分けまでできたのですが、その時間では解決できず1時間音声+テキストで会話を続けました😅

終わってみて色々試してみたところ原因がわかったので、メモしておきます。

結論

設定 > 動画 > 受信時の解像度（最高）が「音声のみ」になっていると相手の動画全般が見えない。
「音声のみ」以外の選択肢に変更する

詳細

バージョン

確認したバージョンは以下の通りです。

OS：macOS Monetery バージョン 12.1
Chrome：100.0.4896.88（Official Build）（x86_64）

設定：受信時の解像度（最高）

原因はGoogle Meetの受信時の設定にありました。設定 > 動画 > 受信時の解像度（最高）を確認します。

相手の画面やカメラが見えていない時は、ここの設定が「音声のみ」になっていました。これにより音声しか受信しなくなるので、相手の動画はすべて見えないというカ$1リでした。

この設定は次回以降も保存されるそうなので、なにかの拍子にここを「音声のみ」にしてしまっていて、それが今回も引き継がれていたということになります。

終わりに

過去に「送信時の解像度（最高）」を高画質にしようとしたけど、カクツキすぎるので自動に戻したということがあって、おそらくその際に手が滑ったのでしょう…。

ネット上には「発信している側起因で見えない」ケースが結構転がっていますが、「受信する側起因で見えない」ケースはあまりなかったので、どなたかの参考になれば幸いです。

Vue3のReactivity TransformをJestでもコンパイルできるようにする

ikuma-t — Tue, 15 Mar 2022 19:53:53 GMT

要約

Reactivity Transformを使った$1をテストしていて、それが原因でJestが落ちるときは、@vue/vue-jest@27.0.0-alpha.3以上を導入しよう！

yarn add -D @vue/vue3-jest@latest

環境

※この記事は2022/03/15書いたものです。執筆時点ではReactivity Transform自体がExperimentalかつ、vue-jestのアルファ版でしか対応していないため下記のような対応が必要になりますが、しばらくすればここらへんは意識しなくても良くなるはずです。

Vue：3.2.26
Jest：27.5.1

前提：Reactivity Transformとは

Vue 3.2.25からExperimentalとして追加された$1ーマクロで、Vueが提供しているReactiveな値を.valueを経由せずに取得することができるようになります。

// 通常のrefimport { ref } from 'vue'const counter = ref(0)console.log(counter.value) // 0// Reactivity Transformconst counter = $ref(0)console.log(counter) // 0

公式ドキュメントでは以下の章で紹介されていて、refだけでなく、computedも$computedとして使用することができます。

vuejs.org

問題：JestがReactivity Transformを解釈できない

今開発しているアプリはWebpackを利用しているので（正確にはWebpacker…殺せっ！）、ドキュメントの通り、明示的に設定に追記することでこの機能を有効化することができます。

vuejs.org

module.exports = {  test: /\.vue$/,  loader: 'vue-loader',  options: {    reactivityTransform: true  }}

これでアプリ実行時はうまくいくのですが、$1に使用しているJestではWebpackは関係ないため、この構文の解釈ができずにエラーになります。

node:internal/process/promises:265            triggerUncaughtException(err, true /* fromPromise */);            ^[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "ReferenceError: $computed is not defined".] {  code: 'ERR_UNHANDLED_REJECTION'}

今回はこれを解消します。

対処：@vue/vue3-jest@27.0.0-alpha.3以上を導入する

yarn add -D @vue/vue3-jest@27.0.0-alpha.4もしくは@vue/vue3-jest@latestを実行します。

2022/03/15時点ではalpha4が最新版なので、こう書いていますが27.0.0-alpha.3以上を導入すればOKです。

これによりテスト実行時のログに、webpackで実行したときと同じようにexperimentalに対するログが出るようになり、Reactivity Transformが正しく解釈されるようになります。

[@vue/ref-transform] Reactivity transform is an experimental feature.Experimental features may change behavior between patch versions.It is recommended to pin your vue dependencies to exact versions to avoid breakage.You can follow the proposal's status at https://github.com/vuejs/rfcs/discussions/369.

解説

Reactivity Transformのみならず、Vueの仕様についてはGitHub Discussionsにて議論されています。

この中でJestへの対応に関する質問がありました。

github.com

VueとAngularのコントリビュータであるCédricさんが「vue3-jest」に新しいオプションを加えたよという話をしています。それがこのPRです。

github.com

READMEにも同様の内容が書いてあるのですが、27.0.0-alpha3以降は以下のオプションでReactivity Transformを解釈できるようになります。

globals: {  'vue-jest': {    compilerOptions: {      refTransform: false    }  }}

デフォルトではこれがtrueだそうで、先に述べた通りalpha3以上を導入すれば自動的にReactivity Transformが解釈できるようになるわけです。

おわりに

これを解消したはいいんですけど、まだ私のJestはエラーを出力しています。やばいですねっ！

【Rails】collection_selectで表示するテキストには、Procを指定できる

ikuma-t — Thu, 03 Mar 2022 08:53:01 GMT

事の発端

自分で作ったGem「jp_local_gov」を使って、自作サービスを実装しています。

実装にあたって、市区町村名のセレクトボックスが必要でした。

jp_local_govではView Templateに記載の通り、collection_selectで使用する候補を返すことを目的の一つとしたJpLocalGov.allというAPIを実装しているので、一見以下の形式で目的は達成できそうです。

f.collection_select :local_gov_code, JpLocalGov.all, :code, :city

たしかにこれでも動作としては問題ないのですが、cityとしか指定していないので、「市区町村名」しか表示されません。

日本には「$1府県は異なるけど、市区町村名が同じ市区町村」がそこそこ存在します。

JpLocalGov.all.group_by(&:city).select { |k, v| v.size > 1 }.map { |k, v| { k => v.map(&:prefecture) }}=>[{"伊達市"=>["北海道", "福島県"]}, {"松前町"=>["北海道", "愛媛県"]}, {"森町"=>["北海道", "静岡県"]},...

そのため、$1府県と市区町村を合わせてテキストに表示したかったので、雑に以下のようにやってみたのですが動かず。

f.collection_select :local_gov_code, JpLocalGov.all, :code, "#{prefecture}#{:city}"

collection_selectで表示するvalueとtextにはProcを指定できる

api.rubyonrails.org

困った時のAPI Dockというわけでチェックしてみると、

The
_method and
parameters are methods to be called on each member of collection. The return values are used as the value attribute and contents of each tag, respectively. They can also be any object that responds to call, such as a proc, that will be called for each member of the collection to retrieve the value/text.

要はcollection_selectの第1引数に指定したオブジェクトが対応できるメソッドを呼び出すことができ、それゆえにProcも呼び出せるようです。

結果として、

f.collection_select :local_gov_code, JpLocalGov.all, :code, ->(lg) { "#{lg.prefecture} #{lg.city}" }

こんな感じにProcを渡してあげると、JpLocaGov.allで取得されたすべての市区町村がイテレーションされてlgにわたり、それぞれの「都道府県名市区町村名」として表示できるわけです。

Formオブジェクトのロケールファイルの定義方法（i18n）

ikuma-t — Wed, 23 Feb 2022 10:00:00 GMT

Formオブジェクトを利用した場合の翻訳キーはどれ？
要約
前提
- 対象バージョン
- サンプルケース
RailsがModelのi18nを探索する手順
- バリデーションメッセージ
- カラム（画面表示項目）

Formオブジェクトを利用した場合の翻訳キーはどれ？

通常DBに紐づくモデル、つまりActiveRecord::Baseを継承したクラスに対応するフォームを作成する場合、次のような$1ファイルを作成することで、バリデーションメッセージや表示される項目を多$1することができます。

ja:  activerecord: # activerecordをキーにする    attributes:      user:        name: 名前        password: パスワード

一方DBへの保存だけではなく、複雑な$1を実装する場合にはFormオブジェクトを作って対処します。例えばフォームから入力されたデータを用いて、メール送信を行うような場合です。

Formオブジェクトは複数のモデルを扱ったり、DB以外の操作が伴うため、基本的にはActiveModel::Modelをincludeした形で実装します。

また、form_withからの$1判定を行うために、to_modelをオーバーライドし、メインとなるModelクラスに向けることもあります。

…こうなってくると、i18n用のi18nファイルをどうやって書いたらいいのかよくわからなくなってきたので、Railsがどのようにi18nファイルを解釈しているのか調べました。

要約

ActiveModelとActiveRecordはそれぞれi18n_scopeを実装していて、これによりActiveRecordファイルのトッActiveRecordルの探索キーが決まる。
Formオブジェクト側で行っている処理（例：バリデーション）はactivemodelをキーにする
to_modelをオーバーライドしてActiveRecord::Baseを継承したモデルを参照している場合、それらの表示に対する翻訳はactiverecordをキーにする

前提

対象バージョン

ActiveRecord：~> 7.0.0
ActiveModel：~> 7.0.0

サンプルケース

モデル：User

class User < ApplicationRecordend

フォームオブジェクト：UserForm

class UserForm    include ActiveModel::Model  include ActiveModel::Attributes  attr_reader :user  def initialize(user = User.new, **attributes)    @user = user    attributes = default_attributes if attributes.empty?    super(attributes)  end  validates :name, presence: true  # バリデーションがいっぱい  attribute :name, :string  # カラム定義も様々  def save    # 実際の処理  end  def to_model    user  endend

RailsがModelのi18nを探索する手順

バリデーションメッセージ

バリデーション用のエラーメッセージの組み立ては、ActiveModel::Error.generata_messageで行われています。

https://github.com/rails/rails/blob/main/activemodel/lib/active_model/error.rb#L64

def self.generate_message(attribute, type, base, options) # :nodoc:      type = options.delete(:message) if options[:message].is_a?(Symbol)      value = (attribute != :base ? base.read_attribute_for_validation(attribute) : nil)      options = {        model: base.model_name.human,        attribute: base.class.human_attribute_name(attribute, { base: base }),        value: value,        object: base      }.merge!(options)      if base.class.respond_to?(:i18n_scope)        i18n_scope = base.class.i18n_scope.to_s        attribute = attribute.to_s.remove(/\[\d+\]/)        defaults = base.class.lookup_ancestors.flat_map do |klass|          [ :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.attributes.#{attribute}.#{type}",            :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.#{type}" ]        end        defaults << :"#{i18n_scope}.errors.messages.#{type}"        catch(:exception) do          translation = I18n.translate(defaults.first, **options.merge(default: defaults.drop(1), throw: true))          return translation unless translation.nil?        end unless options[:message]      else        defaults = []      end      defaults << :"errors.attributes.#{attribute}.#{type}"      defaults << :"errors.messages.#{type}"      key = defaults.shift      defaults = options.delete(:message) if options[:message]      options[:default] = defaults      I18n.translate(key, **options)    end

https://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-generate_message

抜粋するとこんな感じです。

def self.generate_message(attribute, type, base, options) # :nodoc:    # 1： 対象のクラスについて、i18n_scopeを実行し、キーを取得する。  if base.class.respond_to?(:i18n_scope)    i18n_scope = base.class.i18n_scope.to_s    attribute = attribute.to_s.remove(/\[\d+\]/)    defaults = base.class.lookup_ancestors.flat_map do |klass|      [ :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.attributes.#{attribute}.#{type}",        :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.#{type}" ]    end    # 省略  end  # 2. 取得できた情報でデータを翻訳文を作成し、つっこむ  key = defaults.shift  defaults = options.delete(:message) if options[:message]  options[:default] = defaults  # 3. 2で作成されたデータで翻訳処理を行う（ロケールに応じたファイルを選択する）  I18n.translate(key, **options)end

ここで肝になるのはi18n_scopeというメソッドです。このメソッドにより、activerecordを見にいくのか、activemodelを見にいくのかが決まります。

ではその実装はどうなっているのかというと、ActiveModelの場合、次のようになっています。

# Returns the +i18n_scope+ for the class. Override if you want custom lookup.def i18n_scope  :activemodelend

https://github.com/rails/rails/blob/75a9e1be75769ae633a938d81d51e06852a69ea3/activemodel/lib/active_model/translation.rb#L26

一方で、ActiveRecordでも同じメソッドがオーバーライドされており、次のように実装されています。

# Set the i18n scope to override ActiveModel.def i18n_scope # :nodoc:  :activerecordend

https://github.com/rails/rails/blob/75a9e1be75769ae633a938d81d51e06852a69ea3/activerecord/lib/active_record/translation.rb#L20

これにより、翻訳対象のクラスが

ActiveModelの場合は、activemodel
ActiveRecordの場合は、activerecord

が翻訳キーとして採用されることになります。

ここで、バリデーションメッセージについては、Formオブジェクト、つまりActiveModelで実装されたものです。そのため、エラーメッセージの翻訳キーはactivemodel始まりになります。

ja:    activemodel:        user_form:            name: 名前            password: パスワード

カラム（画面表示項目）

カラム（画面表示項目）の翻訳についても先のi18n_scopeで説明がつきます。

form_withでフォームを作成する際に、to_modelによって、ActiveRecordであるUser側にクラス判定が向くため、ActiveRecordのi18n_scopeが採用されます。

そのため、以下のような$1ファイルを記述します。

ja:    activerecord:        user:            name: 名前            password: パスワード

なおUserモデルに含まれない項目をFormオブジェクトに定義した場合も、翻訳ファイルはactiverecord下に記述することに注意が必要です。

以上Formオブジェクトでの翻訳キーの参照先についての調査でした。

Slapdashを使って、瞬間で Notionにアイデアを追加する

ikuma-t — Thu, 17 Feb 2022 10:30:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220217/20220217080548.png

Notionは情報を貯めるには便利だけど、開くのは面倒

Notionも「辛い」と言われるくらいに普及してきましたね。英語版だけだったり、無料ユーザーはブロック数に制限があったりした時代が懐かしいです。

やっぱり1つの情報を複数の表示形式で閲覧することができるのは非常に画期的で、自分もブログネタを管理するのに使用しています（同じDBをボードとカレンダーで表示して、コンテンツの状況と締切を一覧している）。

こうやって溜まった情報を閲覧するにはすごい便利なんですが、問題はちょっとリッチ & ゆるすぎて、新しい情報を登録するためにわざわざNotionを開くのが面倒くさいんですよね。

特にブログ記事みたいなア$1は、他の作業をしている時にふっと思いつくものなので、Notionを開くことによる$1が発生するのがネックでした。

そこでSlapdashというコマンドランチャーの機能を使い、Notionへの登録を簡略化したのですが、これが結構よかったのでご紹介したいと思います。

Slapdashの使い方

Slapdashとは

Slapdashは各種Webアプリを統合し、まとめて操作できるランチャーアプリです。

TrelloやAsanaといったプロジェクト管理ツールから、GitHub、Figmaといったクリエイティブツールまで、このアプリから一括で検索、追加、編集を行うことができます（※：アプリによって、操作できる範囲は異なります）。

slapdash.com

例えばGitHubを連携した場合、GIFのようにどこからでもコマンドパレットを立ち上げ、自分が関与しているGitHubのIssueを横断して検索することができます（ここからIssueを選択し、登録・編集操作が可能です）。

価格についてはBasic、Pro、Teamsの3つのプランがありますが、今回紹介する範囲はBasic、すなわち無料で使える範囲での機能紹介になります（私もBasic会員です）。

ランチャー画面とは別に起動画面があり、ここからアプリを連携したり、Spaceと呼ばれる空間にリンクを突っ込んだり、自分専用のコマンドを作成することができます。

Notionと連携する

SlapdashはNotionにも対応しており、操作としては

ページの新規作成（Not DB）
DBに新たにページを追加
既存のページに対してコンテンツを追加

の3つに対応しています。

Notionを連携する場合は、Slapdashを起動してから「Apps」を選択し、

「App Store」からNotionを選択します（私の場合は接続済になっているので表示が異なりますが、新規接続の場合はConnectというボタンが表示されているので、それを選択します）。

この接続を行った時点で存在するNotionのページやDBに対して、Slapdashへと編集の許可が降りるようになっています。そのため、接続後に新しくNotionページやDBを追加し、それらに対してSlapdashから操作を行いたい場合は、Notion側でAPIを許容する必要があります（Notion右上のShare → SlapdashをInviteする）。

Slapdashから実行できるNotionの操作

Notion内の検索を行う

「Notion」と入力し、「Filter by Notion」を選択することで、Notionのページを横断的に検索することができます。また「Notion」と入力しなくても検索ワードを直接入力してもページやDBにたどり着くことができます。

SlapdashからNotionのページを作成する

「Notion」→「Create New Notion Page」と進むことで、単一のページを作成することができます。作成する際には作成場所となる親のページを指定します。

作成する際にページタイトルやコンテンツは指定できません。あくまでページを作成するのみです。

SlapdashからNotionのデータベースにページを追加する

「Notion」→「Add to Notion Database」と進み、対象のDBを指定することで、そのDBに新しくページを追加することができます。

紙芝居でイメージをご紹介しましょう🐵🦀

例えば私の場合だと、このようなプロパティを持ったブログネタ管理用のDBがあります。ここに新しくページを追加します。

対象のDBとして「ブログ」にカーソルを合わせTab or Enterキーを押します。

するとこのDBのプロパティとコンテンツを入力するためのフォームが出てきます。各プロパティには、Notionであらかじめ指定しておいたフォーマットに合わせて入力を行うことができます（リストやカレンダーなど）。

「Add」を押すと、作成した記事に対するアクションを指定することができます。今回は「Open in Notion」で作成した情報をチェックしてみましょう。

先程入力した内容がNotionに追加されました。Markdownも正しく反映されています。

追加したNotionのページにコンテンツを追加する

先ほどはNotionにページを追加する操作でしたが、追加したページに内容を追記することもできます。

「Notion」→「Add to Notion Page」と進み、ページを指定することでコンテンツを追加することができます。こちらも紙芝居で動作をみていきましょう。先程追加した「新しいブログ記事」に対して追加を行っていきます。

ページを選択すると、コンテンツの入力フォームが表示されます。こちらもMarkdownで内容を記述することができます。

内容を追記したら「Add」を選択し、先程と同じように「Open in Notion」で作成した情報をチェックしてみます。

ページの最下部に今追加し内容が追記されました！

Tips：templateを作成する

「このDBにテーブルを追加することがほとんど」「新規作成時はこのステータスで登録する」といった具合に、具体的なケースがある場合はSlapdashのテンプレート機能を利用して効率化することができます。

Slapdashから「Create Command」→「Template」と進みます。

テンプレートは連携しているサービスに対してそれぞれ作成できるのですが、今回はNotionへのDB追加のテンプレートを作成するため、「Add to Notion Database」を指定します。

まずはNotionのテンプレートを指定します。ここで指定した項目がSlapdashからの登録時のデフォルト値になります。

Notion側の設定を終えたら、ページをスクロールしテンプレート自体の設定を行います。

Nameにはテンプレートの名前を、その他アイコンや説明を追記します。$1を設定しておくと、Slapdashのコマンドパレットにその$1を入力することで、テンプレートを呼び出すことができます。

設定が完了したら「Create Command」を押して、実際に試してみましょう！今回はwtという$1を貼ったので、これをキーに呼び出してみます。

呼び出した入力画面に、あらかじめ設定した内容が反映されていることが確認できました。

おわりに

というわけでSlapdashを使ったNotionの更新フローの紹介でした。

私はこれを使って、冒頭にも述べた通りブログネタを登録して思いついた時にア$1を追記したり、やりたいことリストを追加したりしています。

思いついた時に登録することでア$1を漏らさず、かつどこからでも登録できることで現在のタスクから大きく$1をすることもなく、快適に生活できています。

SlapdashはNotion以外のツールにも対応していますので、ぜひ試してみてください。

Appraisalを使っている状態でもRubyMineのGUIでRSpecを実行する

ikuma-t — Wed, 09 Feb 2022 10:00:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220209/20220209071635.png

きっかけ
TL
;
前提のおさらい
- Appraisal
- RubyMineでのRSpec実行
問題点
対応策
scriptを作成する
RubyMineにscriptを認識させる
実行結果
感想

きっかけ

github.com

先日開発したGemはActiveRecordへの対応を仕様として盛り込んでいるため、Appraisalを使って、複数verのActiveRecordでテストができるようにしています。

それはそれでいいんですが、この状態でいつものようにRubyMine上からテストを実行しようとすると、Appraisalで指定しているはずのGem（ActiveRecord）がないためにテストが落ちるようになってしまいました（ActiveRecordからAppraisal経由でテストをすれば問題なくとおる）。

Testing started at 7:13 ...An error occurred while loading spec_helper. - Did you mean?                    rspec ./spec/spec_helper.rbFailure/Error: require "active_record"LoadError:  cannot load such file -- active_record# ./spec/spec_helper.rb:6:in `require'# ./spec/spec_helper.rb:6:in `<top (required)>'Run options: include {:full_description=>/JpLocalGov\.find/}All examples were filtered out

というわけで今回はAppraisalを経由しても、RubyMine上でテストを実行できるようにしていきます。

TL
;

Apppraisalを導入する場合、各種コマンドはbundle exec appraisalの形式で呼び出す必要がある。
RubyMine標準のRSpec実行はbundle exec rspec …. であるため、Appraisalが導入されていて、そこでインストールされたGemに依存する実装・テストを書いている場合、RubyMine経由でRSpecが実行できなくなる。
AppraisalのCLIを経由するscriptを作成し、RubyMineに設定することで、RubyMine経由でもRSpecを個別に実行できるようになる。

前提のおさらい

Appraisal

Appraisalはthoutbot社が管理している、複数のバージョンでのテストを同時に行うためのGemです。

github.com

公式READMEからの拝借になりますが、以下のように指定することで、Railsの3と4の双方の環境でテストを実行することができます。通常のGemfileでは1つのGemに対して、1つのバージョンしか指定できないため、複数環境に対応したい場合に重宝します。

appraise "rails-3" do  gem "rails", "3.2.14"endappraise "rails-4" do  gem "rails", "4.0.0"end

Appraisalを使用する場合、各種コマンドは次のように実行することになります。

bundle exec appraisal {実行対象の環境} <実行したいコマンド># 上記例で、rails-3のかんきょうでテストしたい場合、bundle exec appraisal rails-3 rspec

RubyMineでのRSpec実行

RubyMineではテスティングGUIに関係なく、GUI上でテストの実行ができます。

一括実行と個別実行の双方を行うことができます。

内部的には、各テスティング$1のexampleやname指定のオプションなどを付与しながら、bundle exec rspecを実行しているだけです。

問題点

上記の通り、Apppraisalはbundle exec appraisalの形式で各コマンドを呼び出すことで、指定した環境のGemfileでコマンドを実行することができます。

逆にいえばAppraisalを経由しないと、Appraisalで指定したGemfileは認識されません。冒頭に述べた通り、Appraisalは複数のバージョンでのテストを可能にするためのGemなので、Appraisalを経由しない = テストが実行できないということです。

RubyMineでのテスト実行はAppraisalを経由しない形式になっているので、結果としてAppraisalを利用すると、テストが実行できないということになります。

対応策

以下の2ステップで対応します。

Appraisal経由でテストを実行するscriptを作成する
1のscriptをRubyMineに認識させる。

scriptを作成する

github.com

require 'rubygems'require 'bundler/setup'require 'appraisal'require 'appraisal/cli'begin appraisal_name = ''rails-5.0" # this is just an example, use the appraisal that you have installed  cmd = [appraisal_name, 'rspec'] + ARGV  Appraisal::CLI.start(cmd)rescue Appraisal::AppraisalsNotFound => e  puts e.message  exit 127end

AppraisalのIssueを確認していると、同じような問題が起票されていました。

AppraisalにCLIがあるので、それを間接的に呼び出すようです。このコードでは特定のAppraisal環境をしていするようになっていますが、とりあえずすべてのAppraisal環境で実行するように少し修正しました。

require "rubygems"require "bundler/setup"require "appraisal"require "appraisal/cli"begin  `bundle exec appraisal list`.split(/\R/) do |appraisal_name|    cmd = [appraisal_name, "rspec"] + ARGV    Appraisal::CLI.start(cmd)  endrescue Appraisal::AppraisalsNotFound => e  puts e.message  exit 127end

RubyMineにscriptを認識させる

RubyMineのGUI実行は、それぞれ実行の構成を指定することができます。

zenn.dev

複数の構成に対して、まとめて設定を行うためには「Edit configuration templates…」を選択します。

左側のサイドバーからRSpecを選択し、「Use cutom RSpec runner script」に、1で作成したscriptを設定します。scriptはどこにおいてもいいですが、Appraisalはプロジェクト固有のものだと思うので、私はプロジェクトのbinフォルダにおいています。

これにより、RubyMineがRSpecを実行するときは、このコマンドを実行するようになります。

実行結果

BUNDLE_GEMFILE=/Users/tadokoroikuma/RubymineProjects/jp_local_gov/gemfiles/rails61.gemfile bundle exec rspec

これらの設定でRSpec実行時にAppraisalのCLIが走るようになり、Gemfileを指定した状態でテストが実行できるようになりました。

感想

Appraisalで作成した環境に対してCLI実行する分にはこのCLIでいいんですが、「ある特定のテストを特定の環境でのみ実行したい」というケースは対応できないので、対応できるようにしておきたいです（CLIの引数処理→Appraisal CLIの引数処理の部分だけクリアできれば、ちゃちゃっとできると思うので）。

Conventional CommitでGemのCHANGELOGをコミットから自動作成する

ikuma-t — Tue, 08 Feb 2022 10:00:00 GMT

Conventional Commitとは

概要

Gitのコミット粒度はまずConventional Commitsで種類が混ざりにくいようにしつつ、「小さいコミットを後からくっつけたり並べ替えたりする方が、大きいコミットを後から分割するよりもずっと簡単なので、迷ったら細かくコミットして後から見直せばいいよ」とよく言っていますhttps://t.co/ySrZSP2xQ7

— Takuto Wada (@t_wada) 2021年12月3日

t_wadaさんが以前Twitterで言及されているのを見かけて、Conventional Commitなるものがあることを知りました。

Conventional Commitとは、以下のようなコミットメッセージの規約を指します。

Conventional Commits の仕様はコミットメッセージのための軽量の規約です。明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は **SemVer**と協調動作します。

引用元：https://www.conventionalcommits.org/ja/v1.0.0/

形式

Conventional Commitは以下の形式を取ります。

<型>[任意 スコープ]: <タイトル>[任意 本文][任意 フッター]

型はfeatやfix、docsなど、変更を端的に表した単語です。具体的には次のようになります。

feat(subscribe): メール購読解約時のログインを不要にしたユーザーのストレス軽減のため（適当）Closes: #79

RubyMineでのサポート

www.conventionalcommits.org

にもある通り、Conventional Commitをサポートするためのツールはかなりたくさんあります。所詮はコミットメッセージなので、人力で入力してもConventional Commitにはできるのですが、型やフッターを選択肢から選べたり、枠が決まっているので形式を意識せずにメッセージを作れたりするので、あった方が何かと便利です。

このページにもInteliJ用のツールは掲載されているのですが、私は別途「Conventional Commit」というツールを使っています（RubyMineのPluginストアで評価が高いのを選んだだけ）。

plugins.jetbrains.com

Conventional CommitでCHANGELOGを作る

で、ここからが今回の本題で、Conventional CommitからCHANGELOGを作成します。

何故-conventional-commits-を使うのかには、理由の1つに

• 変更履歴 (CHANGELOG) を自動的に生成できます。

とあって、どうやって自動生成できるのかなと思ったんですが、コミットメッセージが規約に則っていることで、別途ツールを使用すればCHANGELOGにCHANGELOGが作成できるということのようです。

今回は以前リリースしたGemのCHANGELOGを作成してみることにしました。

conventional-changelog

Conventional Commitから色々やるためのツールが、conventional-changelogとしてまとまっています。

github.com

この中のconventional-changelog-cliを使用してCHANGELOGを作成します。

github.com

インストール

conventional-changelog-cliはnpmなので、まずはインストールします。

リリースのためだけに$1を汚したくないので、グローバルインストールします（グローバルを汚すのはいいんかい）。

$ npm i -g conventional-changelog-cli

コマンド

conventional-changelog コマンドで実行します。helpを見ると分かる通り、結構色々なオプションがあります。

$ conventional-changelog --help  Generate a changelog from git metadata  Usage    conventional-changelog  Example    conventional-changelog -i CHANGELOG.md --same-file  Options    -i, --infile              Read the CHANGELOG from this file    -o, --outfile             Write the CHANGELOG to this file                              If unspecified, it prints to stdout    -s, --same-file           Outputting to the infile so you don't need to specify the same file as outfile    -p, --preset              Name of the preset you want to use. Must be one of the following:                              angular, atom, codemirror, conventionalcommits, ember, eslint, express, jquery or jshint    -k, --pkg                 A filepath of where your package.json is located                              Default is the closest package.json from cwd    -a, --append              Should the newer release be appended to the older release                              Default: false    -r, --release-count       How many releases to be generated from the latest                              If 0, the whole changelog will be regenerated and the outfile will be overwritten                              Default: 1    --skip-unstable           If given, unstable tags will be skipped, e.g., x.x.x-alpha.1, x.x.x-rc.2    -u, --output-unreleased   Output unreleased changelog    -v, --verbose             Verbose output. Use this for debugging                              Default: false    -n, --config              A filepath of your config script                              Example of a config script: https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-cli/test/fixtures/config.js    -c, --context             A filepath of a json that is used to define template variables    -l, --lerna-package       Generate a changelog for a specific lerna package (:pkg-name@1.0.0)    -t, --tag-prefix          Tag prefix to consider when reading the tags    --commit-path             Generate a changelog scoped to a specific directory

実際に作ってみる

conventional-changelog -p eslint -i CHANGELOG.md -s

今回はESLint形式で、CHANGELOG.mdに対して追記をしていきます（なんでESLintにしたかというと、ESLintが一番よく知っているパッケージだからというだけです、すみません😅）。

このコマンドを実行してできたCHANGELOGがコチラになります。

# [](https://github.com/IkumaTadokoro/jp_local_gov/compare/v0.1.0...v0.) (2022-01-14)### chore* Add RSpec Runner for JetBrains IDE ([83d8c86](https://github.com/IkumaTadokoro/jp_local_gov/commit/83d8c8649f69506c9a08acf275960480316eb988))* Make JpLocalGov::Data::Importer#prefecture_capital? to return true/false ([82daafd](https://github.com/IkumaTadokoro/jp_local_gov/commit/82daafd19b47e52ff2c1c341a243aef7e5dffae4))### ci* Add spell checking GitHub Actions Workflow ([fc23bd1](https://github.com/IkumaTadokoro/jp_local_gov/commit/fc23bd1a3c10cc49f8aaf4e869c0062b50255f03))### docs* 💅 ([61c6d66](https://github.com/IkumaTadokoro/jp_local_gov/commit/61c6d66a43b75339036656a1b110dec97156177e))* Add how to use JpLocalGov.valid_code? ([2e14d71](https://github.com/IkumaTadokoro/jp_local_gov/commit/2e14d71c146d823e4bc3fa268da2e3a0c5f7ebe1))* Add issue template ([9f416a3](https://github.com/IkumaTadokoro/jp_local_gov/commit/9f416a335247c3be5c52e450b914bd73c380092d)), closes [#47](https://github.com/IkumaTadokoro/jp_local_gov/issues/47)

Closing Keyword を使ってIssueをクローズしていると、参照先のIssueも表示されるみたいです。これは結構便利ですね。

PRをもらった場合にどうするか？

そのOSSにコミットする人がみんなConventional Commitを使うかというとOSSの場合はそうもいかないと思います。

私も実際にそのケースに出くわしたのですが、「今回は特例で手動でCHANGELOGを追加するか」ということで、特に調べず終わってしまいました。

で、この記事を執筆する過程で調べてみたところ、以下の記述が見つかりました。

www.conventionalcommits.org

いいえ！ Git で squash ベースのワークフローを使用する場合は、主要メンテナがマージ時にコミットメッセージをクリーンアップすることができるため、臨時のコミッタには作業負荷がかかりません。また、これをするための一般的な方法としては、プルリク$1トからのコミットを git システムが自動的に squash し、主要メンテナによるマージ時に適切な git コミットメッセージを入力するためのフォームを表示するというものです。

Conventional Commit側の主張は、「メンテナが都度直せばいいじゃん」とのことでした…。他のRailsとかどうしているんだろう？それこそRailsのような大きなRailsだとなかなか難しいと思うんですが。

感想

というわけでConventional Commitで自動的にCHANGELOGを作る方法でした。

個人的にはコマンド1つでCHANGELOGが完成するので、気楽にupdate作業をできていい感じです。

PRのマージコミットメッセージの件も含めて、他のOSSがどんな感じにCHANGELOGを書いているのかがすごい気になったのですが、残念ながら作成する過程は見えないので、地域rbとかで聞けたら聞いてみようと思います。

余談：もう少しコミットは細かく積もうかな

少しずれるのですが、最近ちょっと前に以下の動画を見た影響もあって、「できるだけコミットはsquashしておこう」と強く意識しすぎていました。

www.youtube.com

そうすると、なかなかコミットが打てなくて作業的には辛いので、

作業時はconventional commitでこまめにコミットを打つ
Pushするときにsquashする

みたいなフローにしたほうがいいなと記事を書いていて思いました。

スマホ中毒改善のために空き箱でスマホケースを作る

ikuma-t — Sat, 05 Feb 2022 12:30:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220205/20220205090821.jpg

$1をついつい触ってしまう…

勉強中もそうなんですが、ベッドにも$1を持ち込んでしまって、色々と質を落としているのが最近の問題点でした。

毎週1回、個人のGKPTを振り返っていて、この問題に対しては以下のような議論がなされました。

$1を金庫に入れれば良いのでは？
- 休憩中にすぐ見られない。
- しまうのと出すのが億劫になって結局継続できなさそう
$1を触らない、持っていかないという鉄の意志を持つ
- 意志の力に頼るのは根本的解決にならない
$1の定位置を机の上にもうけるのはどうだろう？
- 見える位置にあると結局触る
- 視覚的に見えない位置に収納すると良いのでは？
- あまり遠い場所に置くと、$1をなくす問題が発生する
机の近くで、かつ見えにくい位置にシュッとしまえるケースがあれば捗りそう

捗りそう…！？

で、プロトタイプ作ってみた

というわけでプロトタイプ作成です。イメージ図はこんな感じ。

右利き & モニターの右側にMacを置いているので、机の左側面にMacケースを作れると、「離着席時にはMacがよく見え、作業時には視界に入らない」という感じにできそう、っていう魂胆です。

次は材料探し。プロトタイプってことで家にある材料を探したら、FILCOのキーキャップの空き箱がありました。これを使います。

開いてほしい方向と、実際に箱が開く方向があべこべだったので、カッターで無理やりくり抜きました。不器用なんで辛かった…。

机に接着して完成です。両面テープも家にはなかったんで、ビニールテープでHOT LIMITにしています。

いざ装填！

設計通り、$1がシュッと入りました！

目論見通り、作業中は左側に全然意識が向かず、$1を触る時間が格段に減りました。びっくりするほどに睡眠の質もめちゃくちゃ上がりました！$1恐るべし…。

一つ難点があるとすれば、貼り付けがあまりにも適当すぎるので、定期的に押さえつける必要があることくらいでしょうか。

やっぱり人間ってのは定位置が決まっていると、うまく整理・整頓できるもんですね。$1の片付けが言っている「姿置き」ってやつですね。

[図解]トヨタの片づけ

作者:$1
$1

Amazon

このプロトタイプでしばらく持ちそうですが、HOT LIMITが解放されてしまったら、ちゃんとしたの作ろうと思います。

Steepで使えるコマンドを見てみよう

ikuma-t — Fri, 04 Feb 2022 10:04:52 GMT

資料はこちら

speakerdeck.com

昨日omotesando.rb#71で話したネタです。元々はRails7から追加されたActiveModel::APIの話をしようと思っていたんですが、資料作ろうと思った翌日にTechRachoで紹介されていたのでやめました。

資料にも書いたのですが、RubyMineでLSPがうまく起動できませんでした…。

github.com

一応ここに書いてある方法でやっているんですけど、なんかがうまくいっていないみたいなので、継続調査していきたいと思います。

わたしがRubyMineを使う理由

ikuma-t — Thu, 03 Feb 2022 10:00:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220203/20220203082003.png

「RubyMineの何がいいのか？」という問い

みなさんRubyMine使っていますか？昨今のエディタシェアでは、やはりVSCodeが一番大きなパイを占めているような感じですが、私はRubyMineが好きなのでずっとRubyMineを使っています（一部例外で、LiveShareを使いたいとか、Slidevのスライドを作る時だけVSCodeを使っています）。

そんな中、FJORD BOOT CAMPで「みんながおすすめするのでRubyMine使ってみたけど、他のエディタに比べて何がいいんだろう」という質問が出てきました。

というわけで今回は一利用者として「私がRubyMineを使う理由」を述べてみました。

世界中の開発者体験が機能として実装されている

VSCodeもかなり便利ですよね。VSCodeを追加していけば「RubyMineではこんなことできるよ」の大多数はVSCodeでもできると思います。これはVimやEmacsを使った場合でも同じで、つまりフルパワー状態の単純な機能比較によっては、普段使用していて馴染んでいるエディタにRubyMineが勝る点はあまりないかもしれません。

ではRubyMineを使用するメリットは何かというと 「世界中の開発者体験が、あらかじめ機能として実装されていること」 です。

たしかにVSCodeにVSCodeを追加すれば、RubyMine相当の機能を動かせるかもしれませんが、それはその機能にあなたが 「気がついた」 場合です。使えたら便利だけど読むには細かいGitコマンドのオプションや、DBの操作方法の全てに気がつくことができるでしょうか？少なくとも私には難しそうです。

RubyMineを運営するJetBrains社は毎年開発者に対して調査を実施し、製品開発のためにJetBrains製のエディタのドッグフーディングを行なっています。これによりRubyMineには、世界中の開発者が「これは開発によく使うし、あると便利」と思っている機能が最初から、つまり 「気がつかなくても」 使えるようになっているわけです。

1人で学習を進めているいまだからこそ、私は世界中の開発者の動きを学習の補助輪とするために、RubyMineを使用しています。

コマンド操作が全部「見える」から

RubyMineの操作は基本的にすべてGUI上で実行されます。

そのため、コマンドで実行すると複雑な操作も、実際にどういうことをやっているのかイメージがつきやすいです。

例えばGitのrebase は最たる例で、よくわからないけど必要だから…と$1上でやると、「なんかよくわかんない…」「変な感じで取り込まれてしまった…」となりがちです。

これをRubyMine上でやると、すべてを画面操作として実行できるので、

実際にどういう作業ができるのか
今自分が行った操作はどのような結果になるのか

が画面上で確認できるため、そのコマンドでできること、自分がやっていることのイメージがしやすくなります。いわばRubyMineが各コマンドの「図解！〇〇」的な役割を担うわけですね。

もちろんGUI→CUIへの変換は必要になりますが、コマンドの実行イメージがあるおかげで、CUIで実行する際にも意図通りに実行しやすくなり、実行への恐怖感も薄れます。

はじめこそ、ちゃんと整備された道具を使ったほうがいい

私は高校時代に初めてギターにさわり、パン作りを始めました。

ギターの方は安いアコギを買ってしまったがために、弦高が高くてしばらくバレーコードが弾けなかったのですが、友達の高いギターはとても弾きやすくて、それを借りて練習しているうちに、安い方のアコギでもバレーコードが弾けるようになりました。

パン作りの方はずっと独学でやっていたのですが、大学時代にアルバイトで実際に製パンをやらせてもらえることになり、そのときに初めて整備された環境でパンを作ったことで、一気にパン作りのコツを掴むことができました。4年分の成長が3日で追い越されるくらいのブレイクスルーでした。

双方の話に通じるのは、「初めから整備された環境でやっていれば、もっと早く成長できたのに」ということです。何も最高級の環境を整えろというわけではありませんが、最初のうちは**「どんな道具が必要か」**がわからず「正しい型」もわかっていない状態です。

そんな状態だからこそ、はじめのうちこそRubyのためのフルマネージドなIDEであるRubyMineを使うのがいいんじゃないかなと思っています。

「弘法筆を選ばず」と言いますが、そもそも弘法って達人の域の話なので、個人的には「初めのうちは筆を選んでいけ」という気持ちです。

おわりに

というわけで今回は「私がRubyMineを使う理由」をお届けしました。

私自身も初学者であるがゆえに、全体的に初学者向けの内容になってしまいました（ある程度プログラミングできる人は、自分の欲しい機能とか開発スタイルでエディタを選ぶ気がするんだ…）。

speakerdeck.com

以前FJORD BOOT CAMPの中で行われたLT会でも「初心者こそ！RubyMineで始めよう！」という話をさせていただきましたが、やはり最適化された開発フローをエディタを通じて学べるからこそ、自分のようなエンジニア未経験者でもお金を払ってRubyMineを使用する価値はあると思っています。

とはいえ、エディタってやっぱりエンジニアの道具の中で一番大きい部分なので、最後は「自分が使いたいエディタ」で楽しく開発するのがいいんじゃないですかね、と雑にしめて終わりにしたいと思います。

宣伝：RubyMine入門は無料で読めます！

この記事を読んで、「RubyMine使ってみようかな…でも使いこなせるか不安…」と思った方、ZennでRubyMine入門という無料で読める$1を出しています！

zenn.dev

基本的な操作からGit、エディタの見た目変更まで、RubyMine初心者に必要な内容を詰め込んだ一冊になっているので、ぜひに！

OSS gateにビギナーとして参加しました！

ikuma-t — Sun, 30 Jan 2022 11:30:05 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220130/20220130112941.png

昨日 OSS Gateオンラインワークショップにビギナーとして参加してきました！

OSS Gateとは？（引用）

「OSS Gate」とはOSS開発に参加していない人が参加する人に変わる「入り口」を提供する取り組みです。

OSS開発に未参加の人向けに参加方法を伝える場を継続的に提供することにより、OSS開発に参加する人を増やすことができるのではないか。それを実現することが「OSS Gate」という取り組みの目的です。

参考：OSS Gateへようこそ！

oss-gate.doorkeeper.jp

参加した理由

OSS Gateのアンケートには一つだけ書いたんですが、よくよく考えると3つくらいありました。

いつもOSSにお世話になっているので、自分もそこに貢献したいと思ったから
2020年にCOVID-19のサイトがOSSとして作成された時に、自分はIT業界で働いているのに何もできなくて、ちゃんと勉強して社会の役に立ちたいと思ったことが原点の一つとしてあるから
（OSSに限らず）不満に対して文句を言うんじゃなくて、それを改善できるように生きていきたいと思っている。そのための手段としてプログラミングを学び始めたから

というような思いが常々あって、でもやっぱり見ず知らずの人にパッチとかIssueを送るのはちょっと気がひけるので、背中を押してもらうために参加しました。

作業内容

イベント自体は10

〜17

、そのうち手を動かしている時間は11

~15

（途中で休憩あり）。

今回はオンライン開催だったので、Discord上で作業を進めました。作業ログを見て適宜サポーターさんから$1 & 後述の作業ログのコメントで「いいですね〜」「こういうところを見てみるのもいいかも」みたいなサポートをもらいつつ進める感じです。

作業内容としては、貢献したいOSSを選んで、それを公式のドキュメントに則って動かす中で改善した方がいいこと、エラーになったことを投げるという形式だったので、私は最近利用したMarkdownを使ってスライドが作れるツールのSlidevを対象にすることにしました。

github.com

OSS Gateの特徴として、作業中は常に作業ログを取っていきます。実際に私が取った作業ログはこんな感じです。

github.com

以前、「ログ駆動開発」というテーマでLTを行ったことがあって、自分も普段から作業時は全部ログを書いているんですが、これに似ているかな〜とか思いました。

ikmbear.hatenablog.com

成果物

作成したIssue

というわけで実際に投げたIssueがこちらになります！

github.com

Slidevには作成したスライドのExport機能があって、これがplaywright-chromiumというパッケージに依存しています。

これがない場合には、コマンド側はnpm i playwright-chromiumをするように例外を投げるのですが、一方でドキュメントにはnpm i -D playwright-chromium、つまりdevDependenciesとして追加をするように推奨していて齟齬があり、ここを統一した方がいいのでは？というIssueを立てました。

サポーターさんにも👍をいただいたポイントなのですが、この2つの文言が追加された経緯をGit Blameで辿っていけたのがよかったです。

遡っていくと、これらの文言は全く同じコミットで追加されていることがわかり、「書き間違いというか表記揺れかな？」と思えたことが主張の安心材料になりました。

気づき

午前中にさわっていた時は「エラーにはなったけど、別にログを見ればわかるからここはフィードバックポイントじゃないかな〜」と思っていたんですけど、サポーターのDaipomさんとPiroさんが書いていただいたコメントから、間接的にですが「あれ？案内している文言が違うかも」と気がつくことができました。自分でやるときはちょっとでも「ん？」と思ったところは一旦視点を変えて見つめ直すのがいいかな〜と思いました！

あとはIssueの下書きが出来上がった際に、「やっていないことを書いてみると文意が伝わりやすくなるかも」「こういう返答も想定されるので、自分のお気持ちも書いておくといいかも」といったアド$1をもらうことができました。前にkoicさんの動画でみたと思うんですが、「なぜそれを取り込む必要があるのか」「そのための判断材料」を意識して書いていくのがやっぱり大切なんだと、自分でやってみて感じました✍️

前提知識として何が必要か？

「OSSを動かした際のポイントをフィードバックする」というプログラムなので、そのOSSに対してめちゃくちゃ詳しくないといけないということはないかな〜という印象です。

技術的な前提としては

Git / GitHubが使える
黒い画面が使える

ってところですかね。実際私も、ブラウザでドキュメント読む→ターミナルでインストールする→ブラウザ上でIssueを立てるって感じでした。

あとは対象となるOSSを自分で決める必要があるので、最近使ったアプリをちょっと思い出しておくといいかもです（私は当日ふと頭に出たのでSlidevにしましたが、Gemとかでもよかったかも）。なおOSSかどうか、Issueをたてるポイントがありそうかは、プログラムの中で確認するので事前チェックは不要です。

感想

参加する前は「本当にこの時間内でIssueを立てられるのかな？」と内心不安だったんですが、本当に立てることができて、驚き & とても嬉しかったです！

OSS Gateの目的として「自分1人でもOSSに参加できるようになる（気持ちになる）」という点があるのですが、今回実際にIssueを立てることでこれからもやっていけそうだな！と感じました。

（…実際にOSS Gate終了後に今回扱ったSlidevの別件の対応の準備を始めました💪）

OSS貢献へのあと一歩が踏み出せなかった理由に「こんなんで大丈夫なのかな？」という気持ちがきっとあったのですが、今回サポーターの皆さんに自分のやっていることを「承認」してもらえたり、「客観視」した上でアドOSSをもらえたことで、自分1人の中に沈み込んでいた不安が大きく開けた気持になりました！

今回の挑戦をステップに、どんどんOSSの世界を楽しみたいと思えるイベントでした！サポートいただいた皆さん、ありがとうございました！！！！😊

余談

…当日Piroさんに言えなかったんですけど、「シス管系女子全部持ってます！初めてLinuxの勉強する時に買いました！」とここに書き残しておきます😅

おわりに：次回OSS Gateのご案内と気になる方へ

OSS Gateは定期的に開催されていて次回は3/8みたいです。

oss-gate.doorkeeper.jp

参加できるサポーター枠によって、ビギナーとして参加できる方の数も変わってくるのですが、ビギナーには「サポーターを1人以上連れてくるビギナー」枠があります。

「サポーターを1人以上連れてくるビギナー」枠

今回のワークショップに「サポーター」で参加する人を見つけ、自分は「ビギナー」で参加する枠です。

実際に「サポーター」の登録者が1人増えたら繰り上がります。

どの「サポーター」がどの「サポーターを1人以上連れてくるビギナー」に対応しているかはわからないので一番最初に登録していた「サポーターを1人以上連れてくるビギナー」が繰り上がります。

もし「OSS Gate興味あるけど、枠もいっぱいだし…」という方がいたら、次回開催に限らず、お声がけいただければサポーターとして参加しようと思うので、コメント欄でもTwitterでもお気軽にご連絡ください！

⚡️K-Rubyと銀座Railsで自作Gemの話をしました！⚡️

ikuma-t — Fri, 28 Jan 2022 12:00:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220128/20220128104136.png

自作Gemの話をしてきました！
プロモーション活動の成果
登壇してみて感じたこと
自分の中の発表に関するQ&A
チャンスを掴む握力も才能って杉江さんが言ってる
銀座RailsもK-RubyもLT枠募集中みたいです！
おわりに

自作Gemの話をしてきました！

K-Rubyと銀座Railsで先日作成した自作Gemの話をしてきました！

ikmbear.hatenablog.com

ginza-rails.connpass.com

k-ruby.connpass.com

登壇資料はこちらです。Rails青緑みたいになってます（そこは赤じゃないのかよ：銀座Railsの赤にしようと思ったけど、全面赤は目に良くないのでやめた）

こっちがK-Ruby

speakerdeck.com

こっちが銀座Rails

speakerdeck.com

同じことを話しているので、ベースは同じなんですが、ちょっとだけまとめの方向性が違います。

K-Rubyの方は過去のイベントの登壇資料の感じから「自分の学習成果を発表する」っていうところに重点を置いていると感じたので、感想はあっさり目に、自分が工夫したところを多めに話しています。
銀座Railsの方は初のLT枠募集で、初心者の自分が貢献できるのは「エンジニア未満の人でも気軽にLT登壇していいんだ」という気持ちにプッシュするというところだと思ったので、「初心者の気持ち」に重点を置いてまとめています。

プロモーション活動の成果

github.com

気持ち的には「こういうところでの発表もチャレンジしよう！（そして登壇者特典のパーカーもらおう）」というライトな気持ちで参加したのですが、Gemの方に実利的なフィードバックもあったので、さっくりご紹介しようと思います。

$1のStarが2個増えました（ありがとうございますありがとうございます🙇‍♂️）
修正のPRをいただけました！Ruby 3.0以降をサポートしていたのですが、2.7からサポートできるようになりました（リリースはまだです）
yasulabさんから地方公共団体コードを実際に使っている事例を教えていただけました！継続メンテのモチベーションにすごい繋がりました！

登壇してみて感じたこと

いろいろな方に発表そのものとGemについてフィードバックをもらえたのが嬉しかったです！やっぱり言わないと伝わらないな〜とあらためて感じました！

あとは銀座Railsの懇親会に初めて参加できたのも嬉しかったです！

今までは「懇親会って緊張するし、パスかな」と思って参加したことがなかったのですが、「発表した」っていうある種の免罪符的なものがあったので、参加することができました。

懇親会ではRubyの書き方でワイワイできたり、Railsガイドの裏側の話とかが聞けてすごく楽しかったです。発表内容と被りますけど、Rubyっていう言語を介してつながりが広がっていく感じがとても心地よかったです！

…あとアンケートは毎回ちゃんと書こうと思いました😅

自分の中の発表に関するQ&A

今回発表するときにはもうあんまり感じていなかったのですが、今まで、LTという短い枠とはいえ登壇にあたって色々と気にしていたことを3点書きます。「登壇したいけど…」と思っている方の参考になれば…！

※あくまで一個人の意見です。

自己PRはあさましいか？

発表すること自体に「エゴ感強くない？」と感じるかどうかって話ですけど、全然そんなことないと思います。

私の場合、前職では部署内で数少ない若手であるがゆえに、自己PRをしていなくても、能力の如何にもかかわらず、勝手に注目されたんですよね。だからなのかちょっと自己PRをわざわざすることに少し抵抗がありました。

でも、自分はこれからエンジニアとして再スタートを切ろうとしているわけだし、突出した能力があるわけでもないので、新卒はおろか、それより前からプログラミングをやっていた人に対しては大幅にハンディキャップがあるわけですよね。

そんな状態で、企業側に「なんかいい感じに頑張れるから雇ってくれよ」ってのも無理があるし、そもそも見つけてももらえないと思っているので、最近では「外に発信することが礼儀」くらいの感じで個人としては捉えています。

…みたいな話をもっとちゃんと書いている有名な記事を貼っておきます✍️

blog.jnito.com

初心者が話して迷惑じゃないか？

いろんな人が聞いている場ほど、「自分なんかの発表で時間とってしまって申し訳ない」と思ってしまいがちですが、そんなことはないと思います。とりあえずそういう気持ちがあればちゃんと練習とか資料とか考えると思いますし。

「経験者」の人には「初心者」の意見は新鮮だと思いますし、同じ「初心者」の人には共感がもらえると思います。

また「初心者」って一口に言っても、Rubyは同一ではないので、同じことをやってもその人だけの切り口があります（今回の発表だと、仮に同じようにGemを作った話だとしても、心理学者のRubyと「たのしい開発スタートアップRuby」が同時に出てくる発表がカブる確立は限りなく低いはずです）。

あとはRubyコミュニティはやっぱり優しいので、初心者でも大丈夫って感じでしょうか。

私は気にしいなので、「初心者だけど優しく受け入れてくれ」っていう無償の優しさを求めるだけなのは抵抗があって、最近はRubyistHotlinks読んだり、Rubyistの人の古い本買ったりして読んで勉強させてもらってます（なので発表に「たのしい開発スタートアップRuby」が出てくるわけですが😅）。そういう気持ちのやわらげ方もありかもです。

同じことを何度も言うのは申し訳ないか？

今回のGemの発表は短期間に2つの場所でLTをやっていて、さらにFJORD BOOT CAMP内の自作サービス進捗報告会でもちょいちょい言っているので、なんとな〜く心のどっかで「みんな知っている話をするのは申し訳ない感じするな〜」と思っていました。

実際に聞いている方がどう思われているかは別として、個人としては

発表者$1たらずっとその内容を考えていて、その流れの一つに発表があるけど、聞いている人的には別に発表の瞬間しかその内容に触れないので、重複感はそこまでないのでは？
人は結構覚えていないものなので、大事なことは何度も言った方がいい（何度も言わないと伝わらない）
プレゼンは「誰に」「何を」伝えたいかってのが骨子にあると思っていて、客層が変われば「誰に」が変わるので、そこらへんを意識して話し方とか情報の濃淡に手を加えると自分でも安心感が出るのでは？

とか考えて別にいいんじゃないかな〜と思うようにしました。

チャンスを掴む握力も才能って杉江さんが言ってる

SHIROBAKOっていう人生のバイブルみたいなアニメがあるんですが、その中で杉江さんがこんな言葉を言っています。

僕は才能っていうのはなによりまずチャンスをつかむ握力と失敗から学べる冷静さだと思う。絵の上手い下手はその次だ。僕は僕より上手い人間がわずかな自意識過剰やつまらない遠慮のせいでチャンスをとりこぼしてきたのを何度も見た。惜しいと思うよ。未だにね。———SHIROBAKO #22 ノアは下着です！より

「チャンス」の定義は難しいですけど、個人的には「いつかやってみたい」と思ったことをやる機会があるなら、それはまさしく「チャンス」だと思います。

私はアウトプット文化が好きということもあって、こういう発表をやってみたいと常々感じていたので、今回のチャンスを掴めたのはとてもよかったです！！

銀座RailsもK-RubyもLT枠募集中みたいです！

ちょっと硬いことも書いちゃいましたが、LTはコミュニティでのコミュニケーションのきっかけにもなるし、そこからいろんな人とRubyのこと、それ以外のことも含めて話せるのは楽しいので、この記事が読んでいただいた方のLT参加モチベーションアップに繋がると嬉しいです！

k-ruby.connpass.com

ginza-rails.connpass.com

次回の銀座RailsもK-RubyもまだLT枠を募集しているみたいなのでリンク貼っておきます！

…あと最近はまたコロナが復活してきてオンライン開催が多いですが、オンラインで発表すると、100人に話しても5人に話しても感覚的に変わらないので、いいかもしれません。

（Youtubeにあがっている過去のRuby関連のオフラインイベント見てると、リアルタイムでリアクションがあっていいなあと思ったりしますが）

おわりに

というわけでLT登壇レポでした。

LT自体は初めてではなくて、FJORD BOOT CAMP内でやっている「初めてのLT会」で2回、練習の機会をいただいていました。その時の参加レポはこちら

ikmbear.hatenablog.com

こちらの記事でも書きましたが、初めての『初めてのLT会』に参加する際には、FJORD BOOT CAMP内のいろんな人に勇気をもらいました。あらためて感謝感謝です🙏

ikmbear.hatenablog.com

今後も「出ない神本より出るクソ本」の精神でアウトプットの敷居を下げつつ、もっと意欲的に学習して、技術的にも、聞いていただけるみなさんのプラスになるような登壇ができるように頑張っていきたいと思います！

日本の地方公共団体コードをパースするGemをリリースしました

ikuma-t — Tue, 18 Jan 2022 16:25:08 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220118/20220118162141.png

作ったもの

jp_local_govという日本の$1コードを市区町村の情報にパースしてくれるGemを作りました。人生初Gemリリースです🎉

github.com

rubygems.org

「そもそも$1コードってなんやねん」方も多いと思いますが、

$1（ぜんこくちほうこうきょうだんたいコード）[注釈 1]は、日本の地方公共団体につけられた、数字3桁または5桁または6桁の符号（コード）である。コードが与えられる$1とは、都道府県・市町村・特別区、一部事務組合・地方開発事業団・広域連合、加えて、$1ではないが行政区・東京都区部である。

全国地方公共団体コード - Wikipedia

というものです。JIS規格にも指定されています。

3桁、5桁、6桁とありますが、ルール的には

上2桁が$1府県、
続く3桁が市区町村
残りの1桁がチェックディジット

になっているので、このGemでは6桁フルの状態をパースできるようになっています。

READMEにも書いているのですが、jp_prefectureのア$1に多大に影響を受けています。

github.com

作った背景

今作っているサービスで必要だったからです。

ざっくりいうと公共料金を計算するサービスで、その計算のための料率が市区町村ごとに違うために、市区町村ごとにレコードを持つ必要がありました。

で、市区町村だけのテーブルをもつのもなんだか微妙だし、市区町村のための管理画面をもつのも面倒だったので、「Gemでできないかな〜」と思っていたのですが、似たようなア$1のGemは更新が数年前…。

…みたいなことを、FJORD BOOT CAMP内で日報に書いたら、メンターさんから「作ってみては」とアド$1が。

「ちょっと難しいかも…」と思いつつも、内心「作ってみたい、MY FIRST GEM」という思いが心の中に溢れてきたので、作ることにしました！

使い方

だいたいREADMEに書いてある通りなんですが、英語なので日本語でも書きます。

インストール

一応Ruby3.0.0以上が対象です。

普通にインストールするか

gem install jp_local_gov

Gemfileを使ってインストールします

# Gemfilegem 'jp_local_gov'

bundle install

必要に応じてrequire します。

require 'jp_local_gov'

id指定の検索（`JpLocalGov.find` ）

$1コード（String）を指定することで、$1の情報を取得することができます。

chiyodaku = JpLocalGov.find("131016")# => #<JpLocalGov::LocalGov:0x00007fe706a8f148 @code="131016", @prefecture_code="13", @prefecture="東京都", @prefecture_kana="トウキョウト", @city="千代田区", @city_kana="チヨダク", @prefecture_capital=false>chiyodaku.code# => "131016"chiyodaku.prefecture_code# => "13"chiyodaku.prefecture# => "東京都"chiyodaku.prefecture_kana# => "トウキョウト"chiyodaku.city# => "千代田区"chiyodaku.city_kana# => "チヨダク"chiyodaku.prefecture_capital# => false

この後のメソッドでも共通ですが、取得できる情報は

$1コード
$1府県コード
$1府県（漢字）
$1府県（カタカナ）
市区町村（漢字）
市区町村（カタカナ）
$1所在地かどうか

です。

ひらがなとか英字とかも追加するのは苦ではないんですが、$1が出している元データは漢字とカタカナだけなのと、あんまり$1が見つからなかったので、一旦出していません。

あと東京都の都庁所在地は一応「東京」って習ったと思うんですが、「新宿」として登録しています。

条件指定での検索（`JpLocalGov.where`）

上記の取得できる情報をキーとして、ハッシュを渡すことで、指定した条件に合致する市区町村の情報が配列で返ってきます。

なお複数の条件を指定した場合はAND検索になります。

misato = JpLocalGov.where(city: "美郷町")# => [#<JpLocalGov::LocalGov:0x00007fb1c594cb08 @code="054348", @prefecture_code="05", @prefecture="秋田県", @prefecture_kana="アキタケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>, #<JpLocalGov::LocalGov:8 @code="324485", @prefecture_code="32", @prefecture="島根県", @prefecture_kana="シマネケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>, #<JpLocalGov::LocalGov:0x00007fb1c1a3ce40 @code="454311", @prefecture="宮崎県", @prefecture_kana="ミヤザキケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>]misato.map { "#{_1.prefecture}:#{_1.city}" }# => ["秋田県:美郷町", "島根県:美郷町", "宮崎県:美郷町"]JpLocalGov.where(prefecture: "東京都", prefecture_capital: true)# => [#<JpLocalGov::LocalGov:0x00007fb1c219e418 @code="131041", @prefecture_code="13", @prefecture="東京都", @prefecture_kana="トウキョウト", @city="新宿区", @city_kana="シンジュクク", @prefecture_capital=true>]JpLocalGov.where(prefecture: "東京")# => nil# Exact match search. You should specified "東京都" instead of "東京".

全件検索（`JpLocalGov.all`）

すべての$1の情報を取得したい場合に使用します。戻り値は配列です。

JpLocalGov.all# =>  [#<JpLocalGov::LocalGov:0x00007fdf3a9c6758 @code="011002", @prefecture_code="01", @prefecture="北海道", @prefecture_kana="ホッカイドウ", @city="札幌市na="サッポロシ", @prefecture_capital=true>, #<JpLocalGov::LocalGov:0x00007fdf3a9c6730 @code="011011",...

Railsだと、collection_select を使用することで、すべての市区町村のコンボボックスを簡単に作ることができます。

ランダムな$1情報の生成（`JpLocalGov::Random`）

ランダムな$1情報から、指定したプロパティを返します。

JpLocalGov::Random.code# => "281077"JpLocalGov::Random.city# => "大島町"JpLocalGov::Random.city_kana# => "チュウオウシ"JpLocalGov::Random.prefecture# => "青森県"JpLocalGov::Random.prefecture_code# => "46"JpLocalGov::Random.prefecture_kana# => "ヒョウゴケン"

一応想定するケースとしては、FactoryBotで$1コードを指定する際に、決めうちではんく探索的なテストデータを作成しておきたいという場合を想定しています。

後述しますが、Railsで使用する場合はDBに保持するカラムはlocal_gov_code だけなので、その他のプロパティのメソッドはあまり使い所がないかもしれません笑

補足として、あくまでプロパティ単位でしかランダムな値を生成しないので、ランダムな$1の$1を作成する場合は、

JpLocalGov.find(JpLocalGov::Random.code)

という具合に呼んでやる必要があります。需要があれば、JpLocalGov::Random.new みたいなのを作るかもです。

Railsでの使用（基本）

このGemをModelクラスにincludeすることで、そのモデル内でlocal_govenment というメソッドが使えるようになります。

jp_local_gov :<地方公共団体コードを保存したカラム名> とすることで、そのカラム（$1コード）から、$1府県名や市区町村の情報を展開することができるようになります。

# app/models/insurance_fee.rb:class InsuranceFee < ActiveRecord::Base  # local_gov_code:String  include JpLocalGov  jp_local_gov :local_gov_codeend

insurance_fee = InsuranceFee.newinsurance_fee.local_gov_code = "131016"insurance_fee.local_government.city# => "千代田区"

なおカラム「$1コード」の作成時、型はStringにする必要があります。

Railsでの使用（バリデーション）（`JpLocalGov.valid_code?` ）

$1コードのチェックのためのメソッドを設けているので、これをカスタムバリデーションに組み込むことで、$1コードのチェックができます。

class InsuranceFee < ApplicationRecord  include JpLocalGov  jp_local_gov :local_gov_code  ## カスタムバリデーションで利用する  validate :valid_code?  def valid_code?    unless JpLocalGov.valid_code?(local_gov_code)      errors.add(:local_gov_code, "is not valid code")    end  endend

実施しているチェックは

コードが文字列かどうか
コードが正しい長さか（6文字）
チェックディジットを満たしているか
正しい$1府県コードを持っているか

です。

チェックディジットについては、$1コードの仕様に記載があります。

11 検査数字

$1における検査数字は、電算処理にあたって、不正なコードが使われないよう第6桁目をチェック用としたもので、次の方式により算出した数字とする。(方式)第1桁から第5桁までの数字に、それぞれ6.5.4.3.2を乗じて算出した積の和を求め、その和を11で除し、商と剰余(以下「余り数字」という。)を求めて、11と余り数字との差の下1桁の数字を検査数字とする。ただし、積の和が11より小なるときは、検査数字は、11から積の和を控除した数字とする。

出典：https://www.soumu.go.jp/main_content/000137948.pdf

実装としてはこんな感じです。ボリューム的にもプログラミングのちょうどいい問題だと感じていて、結構好きな仕様です。

CHECK_DIGITS_INDEX = 5CHECK_BASE = 11sub_total = code.chars                .take(CHECK_DIGITS_INDEX)                .map.with_index { |digit, index| digit.to_i * (CHECK_DIGITS_INDEX - index + 1) }                .sumcandidate = (CHECK_BASE - sub_total % CHECK_BASE) % 10check_digits = sub_total > CHECK_BASE ? candidate : CHECK_BASE - sub_totalcode[CHECK_DIGITS_INDEX] == check_digits.to_s

なお最初はチェックディジットだけのチェックでいいかなと思っていたんですが、チェックディジットを満たしていても、$1府県コードがイレギュラーになるケースに後から気がつきました。

'481238' # 都道府県は47までなので、こんな市区町村はない# 第1桁から第5桁までの数字に、それぞれ6.5.4.3.2を乗じて算出した積の和を求める80# その和を11で除し、商と剰余(以下「余り数字」という。)を求めて、11と余り数字との差の下1桁の数字を検査数字とする。8　　# 存在しない市区町村だけど、チェックディジットを満たす

なので、$1府県コード（1..47）のチェックも入っています。

仕組み

そこまで複雑なGemではないのですが、一応こういう仕組みです。

総務省｜地方行政のデジタル化｜全国地方公共団体コード

情報の元は$1のこのページです。手順的には以下のような感じです。

元データ（PDF）をGem：pdf-readerで読み取る
sqliteにぶん投げる
sqlite内でソートを行う
JSON府県ごとにSELECTしてJSONに出力する
出力されたJSONを使ってJSONコードをパースする

このGemはGitHubコードの情報が命なので、この処理自体をRakeタスクとして登録して、GitHub Actionsで1ヶ月に1回、自動でPRを作成する形式にしています。

今後の展望

まだIssueにも登録していませんが、ここらへんはやりたいなと思っています。

`JpLocalGov.all` で$1の行政区を除外する

「区」って東京のイメージが強いですが、実は各$1府県の$1には区があります。例えば札幌市には$1や東区があります。

市区町村を選択するのに、ここら辺を選択したい場合もあれば、「札幌市」という市区町村の単位だけがあればいいケースもあると思っています（私のアプリもそうです）。

なので、これをオプションで除外できるようにしたいです。一応、$1府県コードに続く3桁の決まりでなんとか除外できそうなので、近いうちに入ると思います。

YARDでドキュメントを書く

@params とかかいてあるあれです。

このGemはRBSを使っているので、それが半分ドキュメントの役割を果たしている感じもしますが、まだまだ普及率も高くないことと、自分自身が書いてみたいので、これも時間ができたらやる予定です。

各RubyバージョンでのテストのCIを実行する

強いGemのCIで走っているあれです。

今はrubyにruby-versionをおいて、それをGitHub Actionsで参照するようにしているのですが、これを各Rubyバージョンで実行できるようにしたいです。

どうやってやるのかわからんですが。

曖昧検索、一つのプロパティに対して複数条件検索、OR検索

今実装しているwhere は完全一致検索かつAND検索で、一つのプロパティに対して一つの条件しか指定できないんですが、ここら辺をもうちょっと柔軟にしたいです。

あんまり使う機会ないんですけど、なんかできたら良さそうな感じするじゃないですか。

変更差分の$1

リリースしてからまだ時間が立ってないので、$1コードの変更は起こっていないんですが、変更が発生した場合になんかいい感じに見せられないかな〜とぼんやり思っています。

終わりに

というわけで、$1コードをパースしてくれるGem「jp_local_gov」をリリースしたというお話でした。

前にもnpmを作ったことはあったのですが、今回はちゃんと実践的に使えるものを作ったので、いろいろと学びも多かったし、楽しかったです😄

（npmの話はこちら）

ikmbear.hatenablog.com

市区町村まで必要になるケースってそんなに多くないかもですが、もしこのGemを作っていただける方がいるなら嬉しいです！バグや要望はIssueにお気軽に登録してください！

github.com

最近のScrapboxの使い方（2021/12）

ikuma-t — Sun, 19 Dec 2021 10:00:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211015/20211015135059.png

ikmbear.hatenablog.com

2ヶ月前にこんな記事を書きましたが、微妙に進化している & LT会でScrapboxについてお話ししたので、現状のカスタマイズをScrapboxと合わせてご紹介します。

UserScriptとUserCSS
- UserScript
- UserCSS
UserScript
UserCSS
- ピン留めされたページを別の段として表示する
- セクション用の見出しCSS
運用方法
Scrapbox用クライアント

UserScriptとUserCSS

この記事に記載してあるカスタマイズ内容には、ScrapboxのUserScriptとUserCSSを使っています。

UserScript

JavaScriptを使ってページを動的にカスタマイズできる機能です。

UserScriptの有効化

有効化：TOP > User settings > Extensions > User Script「Enabled」をオンにする

自分のユーザーページ（ユーザー名と同じタイトルのページ）にcode:script.jsという形式でコードを定義することで、そのJavaScriptを有効にすることができます（コード変更直後は、一度トップページに戻って、表示されている「再読み込み」的なボタンをクリックする必要があります）。

scrapbox.io

UserCSS

CSSを使って見た目をカスタマイズできる機能です。

settingsというページを作って、code:style.cssというCSSを書くことで、そのプロジェクトでのみ有効なCSSを定義することができます。

UserCSSの設定例

scrapbox.io

UserScript

UserScriptでカスタマイズしている機能を紹介します。

テンプレート

各種テンプレートをボタンクリックで挿入する$1です。

仕組み

テンプレート機能は次の3つから構成されます。

テンプレートボタンを追加する機能（UserScript）
テンプレートボタンの見た目を編集する機能（UserCSS）
挿入するテンプレート（ただのページ）

テンプレートボタンを追加する機能

// UserScriptとしてユーザーページに追加するaddTemplateItemsToPageMenu()  function addTemplateItemsToPageMenu() {    // テンプレートメニューの定義ここから ----------   const __templates = [     { title: '🥞today', url: '/api/code/ikuma-t/template/today.js' },     { title: '🥞tomorrow', url: '/api/code/ikuma-t/template/tomorrow.js' },     { title: '🚀release', url: '/api/code/ikuma-t/template/release.js' }     // メニューを追加する場合は、同じように行を追加する。     // titleにはテンプレートメニューに表示する名前を、urlはそのテンプレートがあるスクリプトのURLを指定する     // `api/code/{自分のユーザー名}/{テンプレートファイルを置いているページ名}/{テンプレート名}.js   ]   // テンプレートメニューの定義ここまで ----------      const __templateMenuTitle = 'Templates'   scrapbox.PageMenu.addMenu({ title: __templateMenuTitle, image: '/assets/img/logo.png', onClick: () => { } })   __templates.forEach((template) => {       scrapbox.PageMenu(__templateMenuTitle).addItem({            title: template.title,           onClick: () => { __loadTemplate(template.url) }})   })      const __loadTemplate = templateUrl => {     if (scrapbox.Page.lines && scrapbox.Page.lines.length == 1) {       const line = document.getElementById('L' + scrapbox.Page.lines[0].id)       const lastChar = line.querySelector('span.char-index:last-of-type')       const textarea = document.getElementById('text-input')       lastChar.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: true}))       textarea.dispatchEvent(new KeyboardEvent('keydown', {bubbles: true, cancelable: true, keyCode: 35}))       // テンプレートを読み込む       $('#text-input').load(templateUrl, function (response, status, xhr) {         if (status == "success") {           try {             // 読み込んだテンプレートをテキストエリアにセット             textarea.value = /\.js$/.test(templateUrl) ? eval(response) : response             // テキストエリアのinputイベント             textarea.dispatchEvent(new InputEvent('input', {bubbles: true, cancelable: true}))             console.log("できました")           } catch (ex) {             console.log("だめでした>< \n" + ex)           }         } else {           console.log("だめでした>< \n" + status)         }       })     }   } }

テンプレートボタンの見た目を編集する機能

こんな感じにFontAwesomeを使っていい感じのアイコンにします

/* UserCSSとしてSettingsページに追加する */a#Templates.tool-btn:hover { text-decoration: none }a#Templates.tool-btn::before { position: absolute; content: '\f067'; font: 900 21px/46px 'Font Awesome 5 Free' }a#Templates.tool-btn img { opacity: 0 }

挿入するテンプレート

これは適当なページを作って、そこにテンプレートをコードブロックとして定義するだけです。
なおJavaScriptで書く必要があります。

ただし、「テンプレートボタンを追加する機能」からアクセスするので、ちゃんとテンプレートごとに別々の名前で定義しておく必要があります。

ページ名についてはなんでも良いのですが、管理がしやすいので「template」というページに設置しています。

以下に自分が作成しているテンプレートのコード例を示します。

日報テンプレート

毎日の日報ページを作成するためのテンプレートです。

// today.js (function() {  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+today.getDate()).slice(-2)  const yesterdayDate = ("0"+(today.getDate()-1)).slice(-2)  const tomorrowDate = ("0"+(today.getDate()+1)).slice(-2)   return `　←[${year}/${month}/${yesterdayDate}]：[${year}/${month}/${tomorrowDate}]→　　[{ 日報] [*** 👍やったこと]  [_]  [*** 🎓学習したこと] [** 【わかったこと】] [** 【わからなかったこと】]  [*** 🥷次にやること]  [*** 🍘感想・余談] 　[{ ライフログ]` })()

私は毎日明日分の日記を作ってから1日を始めるので、明日分のテンプレートも作っています（ほぼほぼ同じです）。

// tomorrow.js (function() {  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+(today.getDate()+1)).slice(-2)  const yesterdayDate = ("0"+(today.getDate())).slice(-2)  const tomorrowDate = ("0"+(today.getDate()+2)).slice(-2)   return `　←[${year}/${month}/${yesterdayDate}]：[${year}/${month}/${tomorrowDate}]→　　[{ 日報] [*** 👍やったこと]  [_]  [*** 🎓学習したこと] [** 【わかったこと】] [** 【わからなかったこと】]  [*** 🥷次にやること]  [*** 🍘感想・余談] 　[{ ライフログ]` })()

じぶんRelease Notesテンプレート

週/1ペースで書いているじぶんRelease Notesのテンプレートです。
最近作ったばかりなので、ちょっと荒削りです。

// release.js  (function() {   const today = new Date()   const year = today.getFullYear()   const month = ("0"+(today.getMonth() + 1)).slice(-2)   const date = ("0"+(today.getDate()+1)).slice(-2)   const thisWeek = Math.floor(date / 7) + 1   const lastWeek = thisWeek - 1   const nextWeek = thisWeek + 1      const birthDayYear = 1995      const age = year - birthDayYear     return ` 前：[じぶん Release Notes（ver 0.${age}.${month}.${lastWeek}）] 次：[じぶん Release Notes（ver 0.${age}.${month}.${nextWeek}）]  本日[${year}/${month}]/${date}、ikuma-t（ver 0.${age}.${month}.${thisWeek}）がリリースされました  [** 今週の日記]  [*** 📆振り返り（KPT）] [** KEEP]  [** PROBLEM]  [** TRY]  [*** 🍳感想] 　`  })()

今日のページに移動するボタン

別のページを開いているときに、ふと自分の日報ページにメモを残したくなることがあります。そのためのボタンです。

  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+today.getDate()).slice(-2)  const formatToday = encodeURIComponent(`${year}/${month}/${date}`)  const menuTitle = 'Daily'   scrapbox.PageMenu.addMenu({    title: menuTitle,    image: 'https://twitter.com/favicon.ico',    onClick: () => window.location.href = `https://scrapbox.io/ikuma-t/${formatToday}`  })

こちらも見た目をFontAwesomeにするために、UserCSSを書いています。

 a#Daily.tool-btn:hover { text-decoration: none } a#Daily.tool-btn::before { position: absolute; content: '\f783'; font: 900 21px/46px 'Font Awesome 5 Free' } a#Daily.tool-btn img { opacity: 0 }

$1などを表示する

ログを書くための拡張表現をJavaScriptで描画する機能です。どっかから拾ってきたんですけど、どこから拾ったか忘れました。

 const tagIconStyles = {    "!" : "{ content: '\\f06a'; color: #F6AE2D }",   /* ひらめき */   "?" : "{ content: '\\f059'; color: #758E4F }",   /* 疑問、要調査 */   "*" : "{ content: '\\f069'; color: #F26419 }",   /* 重要 */      " " : "{ content: '\\f0c8'; color: #08BDBD }",   /* タスク */   "x" : "{ content: '\\f14a'; color: #2489C5 }",   /* 完了タスク */   ">" : "{ content: '\\f14d'; color: lightgrey }", /* 先送りしたタスク */   "<" : "{ content: '\\f274'; color: lightgrey }", /* 日付を決めたタスク */   "e" : "{ content: '\\f192'; color: #F26419 }",   /* イベント */      "good" : "{ content: '\\f164' }",   "bad" : "{ content: '\\f165' }", };  (function(m){   let charSelectors = [], afterLinkSelectors = [], iconStyle = ""   const linkSelFmt = ".line:not(.cursor-line) a[href='./#']:not(.icon)"   const charStyle = "{display:inline-block;width:0;text-indent:-9999px}"   const afterLinkStyle = "{display:inline-block;min-width:1.15em;padding-left:1px;font: 900 110%/normal 'Font Awesome 5 Free';text-align:center}"   const a = "::after", f = " span"   const enc = ['@$&+=:;", ','@$&+=:;",_']   const encode = tag => Array.from(tag).map(c => {      const i = enc[0].indexOf(c)     return -1 < i && enc[1][i] ? enc[1][i] : encodeURIComponent(c) }).join("");   for (var k in m) {     const href = encode(k)     charSelectors.push(linkSelFmt.replace(/#/, href) + f)     afterLinkSelectors.push(linkSelFmt.replace(/#/, href) + a)     iconStyle += linkSelFmt.replace(/#/, href) + a + m[k]   }   let style = document.createElement('style')   style.appendChild(document.createTextNode(charSelectors.join(",") + charStyle))   style.appendChild(document.createTextNode(afterLinkSelectors.join(",") + afterLinkStyle))   style.appendChild(document.createTextNode(iconStyle))   document.head.appendChild(style) })(tagIconStyles)

UserCSS

UserCSSでカスタマイズしている機能を紹介します

ピン留めされたページを別の段として表示する

Scrapboxではページをピン留めすることで、トップページの最上段に貼り付けられます。
このCSSはピンされたページだけ別の段として表示するものです。

 .page-list-item.pin + .page-list-item:not(.pin) {    clear: both; }

セクション用の見出しCSS

日報に使っているセクション用の見出しを作るCSSです。[{ 文字 ]とすることで、見た目が変わります。

   .deco-\{, .deco-\} {     font-size: 0.9em;     color: #fff;     background-color: #FB7476;     padding: 0 0.5em 0 0.5em;     margin-bottom: 0.4em;     border-radius: 0.2em;     display: inline-block;     max-width: calc(100% - 100px);     vertical-align: top;   }

運用方法

概要

個別のメモページはそのままページを作っていますが、それ以外のページは以下の4種類です。

日報 & $1（毎日）
じぶんRelease Notes（毎週）
月次ページ（毎月作って、毎日更新）
年間ページ（毎年作って、毎月更新）

日報 & $1

毎日作るページです。

基本的に1日のはじめに「今日やったこと」にやることをタスク形式で書き込みます（UserCSSにより[_]と書くことでUserCSSが、[x]とすることで完了のUserCSSが、それぞれ描画できます）。

だいたい前日の「次にやること」をコピペしています。

あとはすべての作業を$1以下に書き込んでいき、1日の終わりにこれを日報の各セクションに振り分けて、FJORD BOOT CAMPに提出します。

ScrapboxはMarkdown形式ではないので、変換が必要ですが、これは後述のsbeというアプリで行っています。

じぶんReleaseNotes（週報）

週の振り返りです。毎週金曜日に書いています。金曜日書く理由は働いている時は土日が最も時間がとれたので、土日をスタートにすると週の計画がうまくいきやすかったからです。

内容は単純なKPTと感想です。あまり無理しないように書いています。また今週の日記を貼り付けて見直す時間にもしています。

月次ページ

月の日記をまとめたページです。今月の目標と達成確認も簡単に書いています。

11月の途中からですが、日付の横にはその日の気分の絵文字とタイトルを載せています。（これはKPTで提案されたものです）

ここの部分もテンプレート作れるんですが、1ヶ月に一回しかやらないのと、ブラウザのコンソールですぐに作れてしまうので、毎回for文を書いてリンクを作成しています。

Scrapbox用クライアント

ブラウザでも見られるのですが、sbe: An unofficial Scrapbox desktop appというScrapbox用のクライアントを使っています。

タブが使える
見出し（[* ]など）を⌘ + 1（数字）で挿入できる
右クリックメニューから、Markdownとしてコピーできる

という理由で使っています。他にも色々できるのですが、今のところちゃんと使っているのは上記3つです。

以上、最近のScrapboxの使い方（2021/12）でした〜！何かご質問があればTwitterまたはコメントでお願いたします！

⚡️初めてのLT会 Vol.10で登壇しました！！

ikuma-t — Sun, 19 Dec 2021 10:00:00 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211218/20211218205648.png

⚡️初めてのLT会 Vol.10に参加しました！

昨日FJORD BOOT CAMPで開催された、ライトニング$1初心者のための発表会、「⚡️初めてのLT会 Vol.10」に参加しました！

今回のテーマは「一年間で得た学びと気づき」ということで、私は「作業するときにログを書いていくと、進捗が捗るよ〜」という話をさせていただきました。

この記事では、主に発表した内容の補足と今回のスライド作成で使ったツールなどを説明したいと思います。

⚡️初めてのLT会 Vol.10に参加しました！
参加の経緯
テーマ：ログ駆動開発
自分の作業の進め方（内容補足）
資料の作成方法（Figma）
練習のために使ったツール：CleanShot X
感想

参加の経緯

初めてのLT会自体は、以前にも登壇者として参加したことがありました。

その時の記事はこちら↓

ikmbear.hatenablog.com

前回登壇した時から1年以上経っていたので「そろそろ登壇しておかなければ」と思い、今回手を上げさせていただきました。主催者のparuさん、ありがとうございます！

テーマ：ログ駆動開発

「ログ駆動開発」ってちょっと言葉としては大袈裟ですね笑。ビジネス本として出したら叩かれそうですが、LTという短い尺だったので、コンパクトにタイトルつけさせていただきました。

もともとは「寄り道レトロスペクティブ」というタイトルで、今年はRailsとかGemのソースにいろいろと寄り道してきた話をしようと思ったのですが、ボリュームが大きすぎたので、その話の中で「どうやって難しい内容に対しても安定して進捗を出していくか」というセクションだけ切り出した内容が今回の話になります。

話している内容的には、以下の記事と多少オーバーラップするところがあるので、気になる方はこちらも読んでいただければ

ikmbear.hatenablog.com

ここからツールの話多めです

自分の作業の進め方（内容補足）

LT会での質問で

どこにログを書いているか
どんな内容を書いているかみてみたい

という内容がありました。LT会中も話した部分はありますが、このブログで一連の作業ルーティンを補足として説明させてもらればと思います。

どこにログを書いているか

ログはすべてScrapboxに書いています。やり方としては1日ごとにページを作成して、その中に書いていくようなイメージです。

ikmbear.hatenablog.com

この記事で書いた内容と変わっていないのですが、次のように日報作成ボタンをJavaScriptでカスタムしているので、それを使って今日のページを作成します。

←[2021/12/17]：[2021/12/19]→[{ 日報][*** 👍やったこと] [_][*** 🎓学習したこと][** 【わかったこと】][** 【わからなかったこと】][*** 🥷次にやること][*** 🍘感想・余談][{ ライフログ]

CSSや「日報」の見た目はCSSで拡張してわかりやすいように表示しています。（長くなるのでコードは割愛します。どっか別の記事で書くと思います）。

「日報」のセクションは、そのままFJORD BOOT CAMPで提出するための日報テンプレートになっています。

で、「$1」のセクションが今回のLT会でお話ししたログを書く場所です。ここにログを記載していきます。

どういう風にログを書いているか（ルール）

ルールはあまりありませんが、

日付と時刻を入力する
内容が後から参照できそうなら別のページに切り出す
あとでページになりそうな内容は、とりあえずリンクにしておく

という感じでやっています。

日付と時刻の入力

Scrapboxでは⌃ + Tで日付を入力することができます。3つのフォーマットがあるのですが、3回押した際に出てくる時刻入りのフォーマットを使って、ログの入力を開始します。

時刻を入力するタイミングは厳密には決めていませんが、時間が経っていたり、内容が変わるときには大体日付を入力し直すようにしています。

別のページへの切り出し

ログを書いている中で、「これまた見返しそうだな」と思ったり、独立した内容になっていたら、その部分を選択して「New Page」を選択することで別ページに切り出しています。

こうすることで後から参照しやすくなります。

とりあえずリンクにしておく

ログを書いていると、「この単語後からまとめたいけど、今は時間ないな」「こういう概念でまとめておいたら、自分の考えがまとまりそう」みたいな要素に出会うことが多々あります。

そういう時は文中で、積極的にリンク（[リンクにしたい単語]）を利用していきます。たとえその時点でメモを作らなくても、あとでメモを見返したときに「あ、ここ追記しておこう」という感じで、過去のログから知識が進化する余地を残せます。

タグの機能も使えますが、基本的にはコンテキストの中で自然に残せる内容はリンクとして雑に定義する方針を取っています（こうしておくと自分のメモ見返すの楽しいんですよ）。

どういう風にログを書いているか（実例）

Scrapboxの中に個人的な内容も書いているので、ある時からScrapboxをprivateにしてしまいました。なので抜粋してお届けします。

気持ちの整理

本来であればタスクを整理→作業開始、くらいの感じだと思うんですが、やる気が出なかったようなのでタスク整理する前に気持ちを整理しているメモです。

自分で自分を鼓舞していること、今自分の身に起きていることをとにかく書き出していることがポイントです。

レビューしてもらった内容があまりいいものではなくて、気持ちが落ち込んでしまった時のログです。なんだかモヤモヤしてしまって、「明日作業するのだるいな〜」と思っていたので、その日のうちに頭の中にあることをとにかく書き出しました（この後めちゃくちゃ寝て、翌日朝から快調に作業ができました）。

「悔しい！劣等感だ！いつだって上がり調子でいたい」「でもこの劣等感はずっと味わっていなかった感情だ！！！うれしくもあるぞ」

見返すと恥ずかしいですが、当時の自分はこうやって吐き出せたことで、悩んでいた時間は5分くらいだった模様です。

普通のログ

普通のログは結構やった作業を全部書いていることが多いです。

一番最後に「気になることを書き出してみよう」と書いていますが、このパターンは結構使っていて、実装中もできるだけ頭の中は空っぽにして、今やっていることだけにフォーカスするのに役立っています。

だいたいこのパターンの後に「よしじゃあひとつずつ見ていこうか」「全然わからんな」「本当？今自分が知っていることは何？」みたいな常套句が続きます。

これはリファクタされたメモの例で、ログを振り返ると全然書いていないように見えるんですが、例えば「$1・$1・住民税の計算方法」は次のように別のページとして成立した内容になっています。

これは技術全然関係ないですが、例えば「PostgreSQLでエラーになった」とか「Railsで例外発生」みたいな事象にあったときには、とことんログを書きながら調べていって、後から別ページに切り出すと、検索性も高くなってとても良きです。

その他のScrapboxの使い方（Scrapbox用のクライアント、各種Scrapbox）については別の記事で紹介したいと思います（長いんで）。

資料の作成方法（Figma）

発表中、資料内のイラスト等にも質問をいただきましたのでここに書いていければと思います。

資料はFigma

今回の資料はFigmaで作成しました。結局Keynote使ったの前回の一回だけだった笑

Figmaを使う理由は

色やフォントをストックしておける
$1を使える
スライドを一覧しやすい

という理由です。

今回のテーマと色選定用ツール

今回は「ログ」についてのお話でした。ログの語源って「ログブック」つまりは「航海日誌」なんですよね。なので、スライドのテーマになっているのは船です。

季節的には冬だったので、冬の夜の暗い海とそこに灯る赤い船のライトをイメージしたカラーにしたらいいかな〜と思っていました。

以前ブログで紹介したPalettableも利用しているのですが、今回はAIで色を提案してくれるHueMintというサービスを使って配色のベースを選択しました（結構ライト目な内容だと最近よくこのサービス使っています）。

huemint.com

ここでベースの黒と文字のグレーを決めて、あとは感覚で合いそうな色をパレットとして作成し、スライドを作成しました。

画像の引用元

漫画風デザイン

この画像はどこから？という質問があったのですが、これはOpen Peepsという素材を使っています。

pablostanley.gumroad.com

素材の中にこういう漫画っぽいイラストがあったので、コマ割りと中に出てくるキャFigmaターをFigmaで編集しました。

それだけでもよかったんですが、漫画といえば集中線とか$1、$1があった方がいいでしょ、ということでマンガパーツSTOCKというサイトから素材を拾ってきて合成し、今回のスライドの完成です。

mangasozai.com

正直今回のスライドで一番時間がかかった部分でした笑

表紙のイラスト

表紙にはログ→航海日誌→船の連想から、船の画像をのせています。これはLoose Drawingというサイトから拾ってきたものです。何かイラストが必要な時は、ソコストかLoose Drawingで拾ってくることが多いです。

loosedrawing.com

アニメの画像

これは私が持っているSHIROBAKOのBluray-Diskをスクショしただけです。

SHIROBAKO Blu-ray BOX 1 スタンダードエディション (3枚組)

Amazon

絵文字っぽいの

FigmaではFontAwesomeを利用することができるので、図解にFigmaを使いたい時はFontAwesomeを使っています。

練習のために使ったツール：CleanShot X

今回はFigmaでスライドをつくったのですが、そうすると録画機能がないために練習をどうしようか迷いました（録音するので）。

で、最近購入したCleanShot Xは$1だけではなく、GIFや動画も撮影できることがわかったので、今回はこれを使って録画練習をしました。

cleanshot.com

しかも録画するときにワイプで自分の画像もうつせることに気がついたので、もっぱらこのスタイルで録画をしての練習でした。

ここらへんも長くなるので、CleanShot Xについては別記事で書きます（と思います）。

感想

登壇をやるのはそれなりに大変だけど、その分自分の考えをいろんな人に知ってもらえて、やってよかったな〜と改めて思いました！

今回はFJORD BOOT CAMP内でしたが、来年は今作っているGemの内容で外部のLT会にも登壇しにいきたいと思っています！

ではでは〜！

【アウトライナー】transnoというアプリがすごくフィットしている

ikuma-t — Wed, 15 Dec 2021 16:01:34 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211215/20211215152126.png

ア$1をまとめるときには$1を使っている

私は何か文章を書いたり、図を作ったりする際には$1を使って整理しています。

$1とは以下のように$1状になった箇条書きリストのことです。

タイトル
- Chapter1
  - 内容
  - 内容
- Chapter2
  - 内容
  - 内容

もともとはNotionを$1として使っていたのですが、最近Transnoというアプリに切り替えてだいぶいい感じなのでご紹介したいと思います。

Transnoとは

概要

Transno - Outlines, Notes, Mind Mapは、オンラインで使用できるアウトライン兼$1です。

シンプルかつフレキシブルなリスト
ワンタッチでアウトラインを$1に切り替え可能
$1で共有し、チームで編集できる

といった特徴があります。

PCからはWebアプリとして、$1・$1からはアプリとして使用することができます。

価格は無料です。…というか、Proという機能があるんですが、料金が書いておらず、今のところ課金もされていないんですよね笑

ある程度ユーザー数が伸びるまではPRのためにProを解放しているのかもしれません。

機能紹介：アウトライン編

$1なので、メインはアウトライン機能です。

アウトライン作成

TransnoではTransnoteという単位でアウトラインを作成することができます。
一般的な$1同様にEnterでリスト追加、Tabでリストの構造切り替えを行うことができます。

アウトラインには文字だけでなく画像も含めることができます。

フォーカスイン

アウトラインの一つ一つのリストをクリックすると、クリックした要素を親とする階層にジャンプすことができます。

Notionではリストは俯瞰でしかみられなかったので、これは便利！
結構リストが長くなってくると、だんだん見辛くなってきたり、他の部分に気を取られてしまうので、これを使いながら一つ一つの要素を書いています。

折りたたみ

一つ一つのリストを折りたたむことができます。
同じ階層にあるリストの粒度を確認したい時に便利です。

アウトラインへのアクション（メモ、チェック）

アウトラインのリスト自体にメモをしたり、チェックをすることができます。

ア$1以外の部分で、例えば「ここはあの本を参照する」みたいなメモを残しておきたいケースが多々あるので、メモは非常に重宝しています。なお、クリックしなくてもメモはリストに対してShift + Enterで登録することができます。

チェック機能の方はあまり使うことはないですが、買い物リストみたいな使い方する時には便利なのかも。

エクスポート

作成したアウトラインはWord、PDF、画像、HTML、OPML形式で出力できます。
なおエクスポートはエディタ上で見えているのとほぼ同じ形式で出力されます。

機能紹介：$1編

私がTransnoを気に入っているのは、$1に切り替えられるからです。

アウトラインってどうしても長くなると全体が俯瞰しにくくなるので、「使いにくいな〜」と思っていたのですが、Transnoであれば途中で$1に切り替えることができるのでその問題が解消できました。

$1への切り替え

アウトラインを開いた状態で、$1のアイコンをクリックすると、$1へ切り替えることができます（もう一度押すと元に戻ります）。

$1の形式はいくつかあるテンプレートから選ぶことができます。

$1で使える機能は$1でも使える

リストを折り畳んだり、メモを残すという$1として紹介した機能は$1上でも使用することができます。

こういうことをやるためにわざわざアウトラインに戻らなくていいのもポイント高いですね〜。

おわりに

というわけで簡単にですが$1「Transno」をご紹介しました。

途中でも述べましたが、なぜか今はProが無料で使えるので、ぜひ今のうちに試してみてはいかがでしょうか。

【ツール】リストをコピーすると、Scrapbox用のリンク/リストに変換してくれるAlfredWorkflowを作る

ikuma-t — Sun, 12 Dec 2021 12:45:23 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211212/20211212124414.png

なんで作ったか

QiitaとかZennに投稿されている記事で、「お、このリストいいな。自分のメモにコピペして一つずつ深掘りしていこう！」と思う時があります（「レビュー依頼をする前に見るリスト」とか「転職で聞かれる質問リスト」とか）。

私はメモにScrapboxを使っているのですが、そのままコピペしてしまうと、

そもそもリストにならない
各リストごとにページ内リンクとして作成したいが、プレーンテキストにしかならない

という問題があります。

そこで今回は、Alfred Workflowを利用して「リストをコピーすると、Scrapboxのリンク/リストを作成してくれるツール」を作ってみました。

今回作ったもの

LiLink：リストを渡すと、Scrapboxのリンクリストを作成してくれるAlfred Workflow

Alfredのメニューから「lilink」と入力することで呼び出せます。スペースを開けてコピーしたリンクを貼り付けると、Scrapboxのリンクかつリスト形式に変換したものをScrapboxに出力します。

プラグインについて：以下のプラグインを導入するために、プラグインについて学びます学習を支えるプラグイン：学習を支える3つのプラグインを紹介しますRubyMineのウィンドウ：RubyMineを開いた時に見える各ウィンドウの名称を整理します↓（変換） [プラグインについて：以下のプラグインを導入するために、プラグインについて学びます] [学習を支えるプラグイン：学習を支える3つのプラグインを紹介します] [RubyMineのウィンドウ：RubyMineを開いた時に見える各ウィンドウの名称を整理します]

作成過程

ツールの名前を決める

なんでもいいんですが、今後ツールを増やしていくことを考えると、ある程度わかりやすいものがいいです。今回は、ListとLinkを作ってくれるので、「LiLink」にしました。

ドット絵を描く

AlfredはWorkflowに対して、任意の画像を設定することができます。

私はドット絵が趣味なので、ドット絵でリストの中黒とリンクのアイコンを合わせたアイコンを作成しました。

ちなみにドット絵はiPadのdotpictというアプリで描いています。

Workflowを作る

大した$1も書かないので、今回はBlank Workflowに対して一から作成しました。

基本的な情報を設定して、

引数つきでキーワード「lilink」を受け取るように設定

rubyrubyを書いていきます。

# 前段の入力をARGVとして受け取る（`with input as argv`）設定なので、これを処理するquery = ARGV[0].split("\n").map { |line| " [#{line}]" }.join("\n")# 次の処理に渡すために、`query`という名前で出力するprint query

$1へのコピーアクションを設定し

あとは全部がっちゃんこして完成🎉

おわりに

これくらいのRubyRubyなら、適当に作ってコマンド置き場に設置してもいいんですが、

標準入出力をAlfredが担ってくれるので、ロジックだけ書けばいい
アイコンや説明がつくので、コマンドを実行する時に思い出しやすい
ターミナルを開かなくていい

という利点があるので、AlfredWorkflowとして作るのもありだな〜と思いました。

AWS SAA試験に合格しました🎉

ikuma-t — Mon, 06 Dec 2021 19:41:25 GMT

本日AWS ソリューションアーキテクト-アソシエイト試験を受験し、合格しました🎉せっかくなので、当日ルポから受けた経緯等々を綴ってみたいと思います。（なおこの記事の95%は試験を受ける前に書かれたものです。合格してよかったね笑）

試験当日ルポ
なぜ試験を受けようと思ったか
- プログラマとして働く上で、知識として持っておきたいと思ったから
- クラウドプラクティショナーでは物足りないと思ったから
学習時間は？
- 累計：46時間20分
- 前提
どうやって学習した？
試験を受けてみての感想
- 練習問題とのレベル感
- 受かってよかったね

試験当日ルポ

現地入り

、12

$1にINしました。基本的に会場INは早めなタイプです。合宿とかあると、集合時間2時間前に集合しているタイプです。

験担ぎでBurger Kingを食べる

資格試験のときは、いつも$1$1口にあるBurger Kingで昼食をとりながら最後まで復習しています。基本的にお腹弱いんですが、なぜか$1ーだけは試験前に食べてもお腹壊さないので…。（逆にカフェに行って、カフェラテとか飲むと100%お腹壊す）

全然関係ないですが、$1スーツを着た就活生がめちゃめちゃ多かったです。冬季$1の時期ですかね？

いざ試験会場入り

いざ試験へ！自宅からは少し距離があるのですが、これまで5資格をここで合格してきた実績がある & 勝手のわかっている会場なので、ここで受験しています。

合格…ってコト？

わ〜い、合格できました🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉（合格から3時間後にレポート出ました）

試験中は予定通り30分程度で一周解き終えたあとに、見直しを行いました。

私はいつも配布されるメモ用紙に全問題分のマス目を用意して、そこに各問題の回答の自信度を「○」「△」「×」で記入しています。

見直し時には「○」の中でも自信があるものを「◎」に、「△」を検証してほぼあっていると思うものを「○」に格上げするというチェックを行い、「◎」「○」の合計が合格ボーダーに乗っかるくらい、「△」も含めるとボーダーを5問以上オーバーするくらいでテスト終了します（試験時間140分なので、大体時間が余ります）。AWS SAAは72%が合格ラインです。

今回は試験中自己採点は「73%」でしたが、実際の結果は画像の通り、「80%」でした。

なぜ試験を受けようと思ったか

$1として働く上で、知識として持っておきたいと思ったから

私は現在$1を目指して勉強中です。かなり広く取ると、アプリケーションエンジニアを目指しています。

AWSといえば「インフラ」みたいなイメージもありますが、S3のようなストレージサービスや、Step Functionsのようなジョブ実行サービスなど、いわゆる低レイヤーに留まらない、さまざまなサービスも含まれます。また大規模なネットワーク構築、例えばDirect Connectを使ったオンプレ環境との接続や、DRサイトのためのAWS構築などは（それこそ情シスとかインフラエンジニアの）専任の領域になるかもしれませんが、自分たちが使っているサーバやコンテナの管理くらいはアプリケーションエンジニアにも求められる知識だろうと思っています。

そのため、AWSの各種サービスを理解することは必要であろうと考えて、この試験を通じて知識を習得しようと考えました。

$1プ$1ティショナーでは物足りないと思ったから

今年（2021年）の1月に$1プ$1ティショナーを受験し合格しました。

もともとAWSプAWSティショナーを受験しようと思ったのは、当時の職場で部内のプロジェクト別AWS環境を構築する必要があったためです。人がいなかったので立候補したはいいんですが、知識がまったくなかったので資格試験を通じて知識を習得しながら、社内の環境構築をしました。

で、そのときにいろいろと調べたり、他の人でもメンテできるようにドキュメントに整理したりと頑張ったんですが、それはあくまでその会社の中の話なので、対外的にも「基礎的なところはわかっているのかな、AWS」と思ってもらえるものがあると嬉しいなと思いました。

そう考えた時に$1プ$1ティショナーはちょっと初級すぎるかもと思って、「SAAとるか〜」となった次第です🙂

学習時間は？

累計：46時間20分

46時間でした。隙間時間、メインの学習時間全部を漏らさず集計していましたので、リアルな時間です。

前提

結構AWS試験のルポって「未経験者が2週間で…」みたいな触れ込みの記事が多くある印象があると思うんですが、AWSの経験にかかわらず、いろんな知識が前提知識として有利に働く試験なので、なんとも言えないなあという気持ちです。

というわけで、参考までに私の前提を晒しておきます。

$1プ$1ティショナーを持っています
$1・$1を持っています
Linuxの基礎的な知識があります（Linuxブートキャンプをやっているので）
RDBの基本的な知識があります（Oracleを使っていた、RDBブートキャンプをやっている）
基本的なIT用語を理解し、それを使っている現場に$1ではない立場で関わったことがあります（ETLツール、BIツール…etc）
AWSではありませんが、社内のちょっとした環境をAWSで構築したことがあります。そのため以下のサービスを使用したことがあります。
- EC2（踏み台サーバを利用したメンテ、ただしすべてWindows）
- VPC
- Route53
- ALB、NLB
- SES
- Lambda

…なので、学習開始時点で試験内容の3〜4割くらいは既知の内容だったかなあと思います。

どうやって学習した？

巷でよく聞く教材ばかりですが、以下の教材を使用しました。

改訂新版徹底攻略 AWS認定ソリューションアーキテクト − アソシエイト教科書［SAA-C02］

(模擬問題付き)改訂新版徹底攻略 AWS認定ソリューションアーキテクト − アソシエイト教科書[SAA-C02]対応

作者
昭寛](http://d.hatena.ne.jp/keyword/%C4%BB%C3%AB%C9%F4%20%BE%BC%B4%B2),[宮口光平](http://d.hatena.ne.jp/keyword/%B5%DC%B8%FD%20%B8%F7%CA%BF),[菖蒲淳司
$1

Amazon

基礎固め & 問題演習後の復習用に使っていました。最初は用語とか重要な概念をとりあえず頭に入れて問題演習に臨み、解けなかったら索引から検索して、その周辺のページを深読みするという使い方をしていました。

SAA試験はその名の通り、ソリューションを構築できることが重要なので、用語は当然として各ケースでどういった対応をとるのか、というベストプ$1ティスを把握することが大事だなと思います。

これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）

www.udemy.com

基礎固めで使用しました。結構長い&前半までの内容は大体自分でやったことがあったので、動画だけみてハンズオンはスキップしていました。後半戦は実際に自分で手を動かしてやってみていました。

ソフトウェア系の試験はどれもそうだと思いますが、実際にやってみていると「これはありえない」という選択肢が直感的にわかるようになるのでやっておいて損はないと思います。

…というか資格を取るためだけに勉強しているわけではないのであれば、やっておいたらいいと思うんだ😅

【SAA-C02版】AWS 認定ソリューションアーキテクトアソシエイト模擬試験問題集（6回分390問）

www.udemy.com

全6回を複数回（4周くらい？）ときました。1周目はどれも50点くらいでしたが、2周目は大体80%くらいのスコアで、試験前日の状態では、平均スコア90%でした。

CloudTech

aws-cloud-tech.com

いろいろ有料制度もあるんですが、フリーコース（無料：会員登録必要）でSAA試験の練習問題200問を解きました。Udemyの問題で80%とれるようになったくらいでこちらを解いて、大体85%くらいの正答率でした。試験前日の段階では200問連続で解いて、195問正解という感じで試験に挑みました。

難易度的にはUdemyの問題集よりもちょっと易しめで、一方でUdemyの問題集と全く同じ問題も結構ありました。

試験を受けてみての感想

練習問題とのレベル感

全体的には練習問題よりも難しかったです。わからない問題はそもそも問題文が何を言っているのかわかりませんでした。あとは各所で言われていますが、日本語訳が変な問題が結構多くて、英語をみてから「ああ、そういうことをいいたいのね」となるような問題が5問くらいありました。ここら辺が練習問題との差かもしれません。

受かってよかったね

なにはともあれ、受かってよかったです（$1プ$1ティショナー合格してると、SAAの受験料半分なので、金銭的にも今回で受かってよかった）😊

以上、AWS SAA試験合格レポートでした〜！

RubyMine2021.2.3でdocker compose環境のRailsを動かしてみる

ikuma-t — Mon, 15 Nov 2021 20:17:43 GMT

動機

昨今の開発において、常識になっているDocker。

私もそろそろ学ばねばということで、書籍を使って概要を掴みました。

仕組みと使い方がわかる Docker＆Kubernetesのきほんのきほん (Compass Booksシリーズ)

作者
種高
$1

Amazon

Dockerの仕組み、Dockerfile、Docker Composeの基本はわかったけれど、実際にRailsアプリを動かしてみたらどうなるんだろう？と気になっていたところ、RubyMineの公式がDocker Compose環境でRailsを動かすサンプルRailsを公開していたので、Railsアプリの起動までやってみました。

やること

チュートリアル: リモートインタープリターとしての Docker Compose | RubyMineをやる

サンプル$1：

github.com

やってみる

まずはgit clone

コマンドでも構いませんが、RubyMineを使用しているので、「Get from VCS」からサンプルVCSのURLを設定して、cloneを実施します。

DB設定をPostgresqlに変更する

cloneした時点ではDB設定がsqlite3になっているようなので、config/database.ymlを開き、使用するDBを変更します。

コンテナを起動する

次にdocker-compose.ymlを開いて、ガターにある矢印アイコンを押します。

これで/usr/local/bin/docker-compose -f /Users/tadokoroikuma/RubymineProjects/sandbox/sample_rails_app/docker-compose.yml up -dというコマンドが実行されます。

つまりは、このdocker-compose.ymlをベースとして、バックグラウンドでサービス（コンテナ）を起動するわけです。
これでPostgresqlとRubyのコンテナがそれぞれ作成&起動されます。

Rubyーとして、コンテナ上のRubyを指定する

次にRubyMineに対して、コンテナ上のRubyを参照するように設定します。

Preferences > Ruby SDK and Gemsを開き、「+」から「New Remote」を選択します。

続いて、Docker ComposeのwebコンテナのRubyを参照するように設定し、「OK」を押します。

DB作成と$1を行う

次にrails db:createとrails db:migrateを実施します。
これに限らずですが、ターミナルからコンテナに入ってコマンドを直接実行する方法と、RubyMineの機能を使って実行する方法の2種類があるので、それぞれ解説します。

ターミナルからコンテナに入ってコマンドを直接実行する方法

# webコンテナを指定してコマンドを実行する（bashを起動する）$ docker-compose exec web bash # DBの作成を行う（rails db:migrateも同様）$ rails db:createCreated database 'sample_rails_app_db'Created database 'sample_rails_app_db_test

RubyMineの機能を使って実行する方法

RubyMineのRunAnythingに包含されている、Rake Taskの実行を用いて起動します。
（rakeタスクのコマンドはrailsコマンドに移管されたのですが、RubyMineの機能を使う場合は、Rakeタスクとして扱う必要があります。というかRailsコマンドで実行しても結局はRakeタスクを叩いているだけなので…）

^を2回押して、RunAnythingを呼び出し、rake --tasksと入力してEnterで実行します。

これをしないとどうもDocker環境でRakeタスクが認識できないようで…（これは不便）。

これでRakeタスクが使えるようになったので、RunAnythingからrake db:createを実行します（rake db:migrateも同様）

DBが作成されたか確認する

$1にはありませんが、RubyMineのDBクライアント機能を使って作成されたDBを確認してみましょう。

まずはDatabaseツールウィンドウを開いて、「+」ボタンからDataSourceとしてPostgreSQLを選択します。

次に接続に必要な情報を以下の通り設定していきます。

項目	設定	説明
Port	54333	docker-compose.ymlで設定したポート$1ードにもとづき、54333を指定します。
Authentication	User & Password	postgresのコンテナの設定にしたがい、この認証方法を指定します。
User	postgres	database.ymlで定義した内容に従って、postgresを指定します
Password	<空欄>	docker-compose.ymlで指定した内容にて、パスワード不要のオプションを設定しているため、空欄にします
Database	sample_rails_app_db	database.ymlで指定した内容に基づき、この名前のDBへの接続を指定します

入力が完了したら、TestConnectionを行い、問題なければOKを押してください。

うまくいけばこのようにDatabaseの中身を確認することができます。

Railsアプリケーションの実行

RAILSの実行対象に「DEVELOPMENT

_RAILS_APP」を指定し、再生ボタンを押します。

ブラウザを開き、http://0.0.0.0:3000/にアクセスするとサンプルアプリが起動します。

なおターミナルから実行する場合は以下のようにします。

$ docker-compose exec web bash$ bin/rails s -b 0.0.0.0

バインドマウントがされているか確認してみる

後述のdocker-composeの設定で、node_modulesを除くすべてのファイルの変更がコンテナ上に反映されます。
実際にソースを少し改変して、反映されることを確認してみましょう。

app/views/static_pages/home.html.erbを開き、23行目にある内容を書き換えてみましょう。

    <h2>      BindMountTest      This is the home page for the      <a href="https://www.railstutorial.org/">Ruby on Rails Tutorial</a>      sample application.    </h2>

この状態でアプリをリロードします。

たしかに内容が変更されていることが確認できました。

定義ファイルを確認する

ここまでで実際にRailsアプリを立ち上げることができました。ここからはこの環境を作成した定義ファイルを確認していきたいと思います。

docker-compose.yml

まずはdocker-compose.ymlからです。

version: '3'services:  db:    image: postgres    volumes:      - ./tmp/db:/var/lib/postgresql/data    environment:      POSTGRES_HOST_AUTH_METHOD: trust    ports:      - "54333:5432"  web:    build: .    command: tail -f /dev/null    volumes:      - .:/sample_rails_application      - /sample_rails_application/node_modules    ports:      - "3000:3000"      # Ports required for debugging      - "1234:1234"      - "26166:26168"    depends_on:      - db

順番に見ていきます。

version: '3'

これは使用するDocker Composeのバージョンを指定しているだけです。
今回はバージョン3を指定しています。

services:  db:    # 略  web:    # 略

次にservices、つまり使用するコンテナの設定です。今回はdbというコンテナとwebというコンテナの2種類を立てます。
順を追ってみてみましょう。まずはdbコンテナです。

  db:    image: postgres    volumes:      - ./tmp/db:/var/lib/postgresql/data    environment:      POSTGRES_HOST_AUTH_METHOD: trust    ports:      - "54333:5432"

以下各定義内容の説明です。

定義	意味
`image:postgres`	dbコンテナではpostgresqlをイメージとします
`volumes`	`docker-compose.yml`からみた$1で`var/lib/postgresql/data`が呼び出されたら、ホストの`./tmp/db`に読み取り、書き込みを行います。これによりデータが永続化できます
`environment`	Postgresqlとして、`POSTGRES_HOST_AUTH_METHOD`を定義し、その値に`trust`を指定します。このオプションはPostgresqlのパスワードが不要になるもので、推奨はされていません（今回は検証用のPostgresqlなので…）
`ports`	ホストのポート54333を5432にポート$1ードします。

volumesの指定は、Dockerの2つある方法のうちの「バインドマウント（Dockerエンジン上ではなく、ホストの指定した箇所に保存する）」の指定で、:を境にホスト

。

参考：Postgres - Official Image | Docker Hub

続いてwebコンテナを確認します。

  web:    build: .    command: tail -f /dev/null    volumes:      - .:/sample_rails_application      - /sample_rails_application/node_modules    ports:      - "3000:3000"      # Ports required for debugging      - "1234:1234"      - "26166:26168"    depends_on:      - db

こちらも同様に各定義内容の説明です。

定義	意味
`build`	`docker-compose`から見た$1で`.`つまり、カレント$1リにあるDockerfileをベースにしてコンテナを作成します。
`command`	コンテナ起動時のコマンドを指定する。`tail -f /dev/null`は何もしないで起動を続けるためのコマンドで、RubyMine側でRailsを起動する際に、コンテナ内でRailsが立ち上がっているとプロセスが重複して起動できなくなることを回避するために、このようにしています。
`volumes`	一行目は、コンテナの`./sample_rails_application`に対して、ホストの`.`（カレント$1リ）をバインドマウントしています。2行目はコンテナ上の`node_modules`$1リを名前なしボリュームとしてマウントしています
`ports`	ポート$1ードを定義しています
`depends_on`	dbコンテナに依存することを定義しています

結構ややこしいのが、node_modulesの名前なしボリュームでのマウントです。
まず先の通り、手元のソースの反映はバインドマウントによって、すべてコンテナ上と同期されます。
こうすると、ホスト上とコンテナ上のnode_modulesがそれぞれ同期されてしまうのですが、せっかくコンテナ上で固定したnodeが、ホストによって破壊されることになってしまいます。

そのため、node_modulesのみはバインドの対象外とするのですが、コンテナが破棄されたのちもデータを永続化するため、DockerEngine上に名前なしボリュームとしてマウントする手段をとっています。

参考：VSCode&Docker Volumeにおけるnode_modules問題を解決する

ここまでに記述した内容でたしかにコンテナが起動しているかは、コマンドでも確認することができますが、RubyMineのServicesタブを使って確認することができます。

webコンテナのポート$1ード設定を確認

Dockerfile

つづいて、Dockerfileです。

# ruby2.7.2のイメージを使用するFROM ruby:2.7.2# yarnのリポジトリを追加します（apt-key add -は標準入力の内容を追加します。つまりcurlで取得した内容を追加します）RUN curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -# teeコマンドを使ってyarnのAPTパッケージレポジトリを自分のシステムに追加しますRUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list# 必要なパッケージをインストールしますRUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs postgresql-client yarn# RUN CMD ENTRYPOINT ADD COPYの際の作業ディレクトリを`/sample_rails_application`に指定RUN mkdir /sample_rails_applicationWORKDIR /sample_rails_application# 必要な初期設定系ファイルのコピーCOPY Gemfile /sample_rails_application/GemfileCOPY Gemfile.lock /sample_rails_application/Gemfile.lockCOPY package.json /sample_rails_application/package.jsonCOPY yarn.lock /sample_rails_application/yarn.lock# 初期設定系のインストールRUN gem install bundler -v '2.2.15'RUN bundle installRUN yarn install --check-files# イメージに`. /sample_rails_application`の内容を追加するCOPY . /sample_rails_application# ポート3000で通信するEXPOSE 3000

このimageを元に、docker-composeのwebコンテナは作成されるようです。

感想

素晴らしい書籍のおかげでDockerの基礎を理解できたのはよいものの、実際にRailsアプリを一から起動するとなると、ややハードルが高かったです。
しかしながら、この$1はすでに出来上がっている$1を使ってアプリを動かすので、その中継点として非常にちょうどいい題材だと思いました。

一点気になったのが、node_modulesはVolumeTrickを使って名前なしボリュームにマウントしているのに、Gemfileはいいのか？というところです。
なんか同じような類なので、Gemfileもボリュームマウントした方がいい気がするんですが、その話はまた別の機会に調べようと思います。

git initで作成されるブランチ名を変更する

ikuma-t — Wed, 20 Oct 2021 10:12:48 GMT

久しぶりに$1からgit initしたら、以下のようなメッセージが表示されました。

 % git init hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint:  git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint:  git branch -m <name>

git config --global init.defaultBranch <name>とすることで、ブランチ名のデフォルトを変えられるようです。最近いつもmasterで作成してからmainに変更していたので、これをmainに変えてみます。

% git config --global init.defaultBranch main

この状態で、git initをしてみると、ブランチがmainで作成されていました。

文字列に数値が含まれているか判定する

ikuma-t — Mon, 18 Oct 2021 12:02:56 GMT

Rubyである文字列wordに数値が含まれているかどうかをBoolean値で判定するには次のようにする

 def self.include_number?(word)    (word =~ /[0-9]/) != nil end

docs.ruby-lang.org

String#=~は、$1を引数にとり、マッチすればそのインデックスを、そうでなければnilを返す。

このメソッドでは、nilと比較することで、

見つからない場合はnil != nil はfalseを返す
見つかった場合は3 != nilのようになり、trueを返す

という仕組み。

文字列に大文字と小文字が混在していることを判定する

ikuma-t — Mon, 18 Oct 2021 11:55:49 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211018/20211018115513.png

小ネタ。Rubyで書いているけど他の言語でも同じ。

ある文字列wordに大文字と小文字の両方が含まれているかチェックするには

wordをすべて大文字にした結果とwordが等しいか（例：IKUMAとikuMaが等しいか）
wordをすべて小文字にした結果とwordが等しいか（例：ikumaとikuMaが等しいか）

の$1を返せば良い。

コードは次のようになる。

   def include_upper_and_lower_case?(word)     # 戻り値はBoolean     word.upcase != word && word.downcase != word   end

spotifyのプレイリストを自動で作るnpm（recommendify）を作った

ikuma-t — Sun, 17 Oct 2021 21:03:13 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211017/20211017210157.png

少し前にspotifyブートキャンプの課題でspotifyのプレイリストを自動作成してくれるnpm：recommendifyを作ったので、紹介します。

何を作ったの？

以下の4つの質問に答えると、それにあったSpotifyのプレイリストを作成してくれるnpmです（15曲入っています）。

最近聴いた曲から1~3曲
曲の明るさ
アーティストの人気度
曲のBPM

recommendify - npm

どうして作ったの？

Spotifyのプレミアムプランに契約して、まあまあ曲は聴いているし、毎日使っているんですが、ついつい同じ曲を選んでしまうんですよね。
自分で探しに行けばいいんですけど、Spotifyの検索画面ってジャンルを選ぶと人気の曲が出てくるので、結局最近聴いた曲ばっか出てきてしまう…。

そこで「いっそのことプログラムに勝手にプレイリストを作らせてしまえばいいのでは」と思い、本npmを作成するに至りました。

どうやって使うの？

recommendify - npmにも記載がありますが、一応日本語でも記載しておきます。

※Spotifyアカウントを持っていることが前提になります。

前準備

Spotifyの開発者Spotifyボードにログインする

developer.spotify.com

「CREATE AN APP」を選択する。App nameとApp descriptionに適当な値を入れてチェックをし、「CREATE」を選択する

「EDIT SETTING」を開き、コールバックURLにhttp://localhost:8888/callbackを設定する

クライアントIDとクライアントシークレットを控えておく

実行

recommendifyをインストールする

% npm i -g recommendify

以下のコマンドを実行し、クライアントIDとシークレットを入力して、$1ンの取得を行う

% recommendify settoken

これでrecommendifyが実行可能になります！プレイリストを作成しましょう！

% recommendify

工夫したところは？

曲をどうやって選出するかですね。

SpotifyのWebAPIでは結構いろいろなパラメータがあって、最初はそれらを全部選べるようにもしようかと思ったのですが、ランダムな曲を選ぶのにパラメータをいくつも選ぶのはいかがなものかと思いまして、現在の形に至りました。

ガチャを回すので4手くらいが限界かなあと。

あとは一応同じ選択肢を選んでもランダムになるように、曲にはシャッフルをかけています（一応SpotifyのAPIは同じパラメータだと同じ内容を返すように見えましたが、登録されている曲のリストが変われはその限りではないとも思っています）。

難しかったところは？

アクセス$1ンが切れた場合のリフレッシュ処理に少し苦労しました。

SpotifyのアクセスSpotifyンはたしか1時間くらいで切れてしまうのですが、切れるたびにエラーになってはストレスなので、confというnpmを使ってリフレッシュSpotifyンをローカルに保存し、アクセス時にSpotifyンの有効期限が切れていれば、アクセスSpotifyンの再取得を行うようにしました。

const callApi = (func, argumentArray) => {  return (async function callSpotifyApi (retryCounter = 1) {    try {      return await func.apply(spotifyApi, argumentArray)    } catch (error) {      if (error.body.error.status === 401 && retryCounter) {        await refreshAccessToken()        return await callSpotifyApi(retryCounter - 1)      }      throw new Error(error)    }  }())}

github.com

とはいっても、何回もリトライすると無限ループに陥る可能性があるので、$1処理として実装しつつも、複数回は実行しないようにする部分に結構頭を使いました。

おわりに

個人的に結構気に入っているアプリです（本当はWebアプリとして実装できたらいいんですが…）。
皆さんもぜひダウンロードしてみてください。

雑なプログラミング問題（LEET変換プログラム）

ikuma-t — Sat, 16 Oct 2021 21:47:09 GMT

ネットで見かけたプログラミング問題をRubyで解いてみました。簡単なテストコードも作ったので、みなさんも是非解いてみてください。

問題

Leet - Wikipediaとは、一部のアルファベットを一定のルールに基づき、数値や記号に変換して表す遊び、仕組みです。ここでは、以下の変換ルールが適用されています。

a/A = 4
b/B = 8
e/E = 3
l/L = 1
o/O = 0
s/S = 5
t/T = 7
z/Z = 2

例えば、文字列I am a studentはI 4m 4 57ud3n7に置き換えられます。
変換対象の文字列：original_stringが与えられるので、それをleet文字列に変換した結果を返す関数leetifyを作成してください。

# 出力例leetify('I am a student') # I 4m 4 57ud3n7leetify('do re mi fa so ra si do') # d0 r3 mi f4 50 r4 5i d0leetify('Dairantou smash brothers') # D4ir4n70u 5m45h 8r07h3r5

テストコード

gist.github.com

回答

ハッシュテーブルを利用して変換します。

gist.github.com

解説

すごい短いので解説することもないですが…

今回は文字列をString#charsを利用して一文字ずつ配列に分解し、ハッシュテーブルを利用することで変換しています。
ハッシュテーブルに値がない場合は文字列そのままを返す必要があるのですが、これは短絡評価を利用することで短く表記しています。

3項$1を使って書いてみると以下のような感じです。

def leetify(original_string)  string.chars.map { |s| LEET_TABLE[s] ? LEET_TABLE[s] : s }end

ちなみに、すべてハッシュテーブルの中に値があることがわかっている場合は以下のように書けます。

def leetify(original_string)  string.chars.map(&LEET_TABLE)end

この記法はHash#to_proc (Ruby 3.0.0 リファレンスマニュアル)を利用したものです。

おしまい

最近のScrapboxの使い方（2021/10）

ikuma-t — Fri, 15 Oct 2021 13:51:29 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211015/20211015135059.png

私がいままでやっていたことは「情報の整頓」だった

Notion、Mem、Bear、InkDrop…etc。メモアプリは色々と試してきました。いずれのアプリも最初のうちは「おお！めちゃいいやん」と快調にメモができていたのですが、メモの量が増えるにつれて、だんだん使いづらくなっていき、メモアプリヒッピーに。

そんなときに『知的生産の技術』を読んだのですが、次のフレーズにハッとさせられました。

整理というのは、ちらばっているものを目ざわりにならないように、きれいにかたづけることではない。それはむしろ整頓というべきであろう。ものごとがよく整理されているというのは、みた目にはともかく、必要なものが必要なときにすぐにとりだせるようになっている、ということだとおもう。

『[知的生産の技術]』（$1刊）$1

自分が今までやっていたメモアプリの挫折は、まさにこの「整頓」に執着していることが原因だったのか！
新しいメモアプリを使い始めた瞬間は、使い始めた時点での情報、つまりは有限な要素であるため、綺麗に並べられる。
しかし情報が増えていくにつれて、使い始めた当初の分類では抑え切れなくなり、整頓が破綻していたのです。

階層型のメモアプリでは、どうしても情報量が増えた際にスケールしなくなると感じ、いままでサブ的に使用していたScrapboxをメインのメモアプリに据えることにしました。

なんでもScrapboxにつっこむ

先に述べた通り、Scrapboxをメインのメモアプリにしたため、なんでもかんでもScrapboxにつっこんでいます。

現状では、日記ページを毎日作成し、そこからリンクを派生する形で色々なメモを作成しています。

日記ページは現時点で以下のようなセクションで構成されており、$1の部分に雑にメモを書いていきます。

前日 | 翌日のリンク
タスクリスト
感想
$1

基本的にはその時の気持ちとかやったこととかをだらだら書いていますが、何かしら別テーマで書きたいことが出てきたら[]でリンクを作成して、そこから別ページにメモします。

日記ページは前日、翌日のリンクがあるので、暇な時にたまに見返すのですが、ここに別ページへのリンクを貼っておくとついついそのページも見て、知識の整理ができるというメリットがあります。

もともと自分はpixiv百科事典を眺めるのが趣味で、芋づる式に関連項目に飛ぶのが面白いなと思ったことから、単独でページを作成せずに、最低限作成日からリンクを飛ばすような仕組みにした経緯があります。

あと書いている最中は$1の中に書いていたけど、見返すと別テーマに切り出せそうなものは後から別ページにしています。これは$1でメソッド切り出しを行うような感じがしていて、結構気に入っています。

使っているUser Scriptの紹介

…とここまでが（ざっくりですが）最近のScrapboxの使い方で、ここからは使用するにあたって利用しているUser Scriptを紹介します。

なおUserScriptは、自分のプロフィールページにJavascriptでコードを書くことで、Scrapboxをカスタマイズできる機能です。詳細はリンク先参照。

テンプレートボタン

日記ページを自動で作成してくれるボタンです。新規ページを開いている時に押すことで機能します。

ソースはテンプレートを使ってページを作成（UserScript版） - Scrapboxとあそぶで紹介されているものを一部修正して使用させていただきました。

今日の日記ページに移動するボタン

名前の通りです。別のメモを書いてから日記ページに戻るのに、一度トップページを挟むのが煩わしくて作りました。

  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+today.getDate()).slice(-2)  const formatToday = encodeURIComponent(`${year}/${month}/${date}`)  const menuTitle = 'Daily'   scrapbox.PageMenu.addMenu({    title: menuTitle,    image: 'https://twitter.com/favicon.ico',    onClick: () => window.location.href = `https://scrapbox.io/tadokoro/${formatToday}`  })

見た目をFontAwesomeアイコンにするために、UserCSSも利用しています。

 a#Daily.tool-btn:hover { text-decoration: none } a#Daily.tool-btn::before { position: absolute; content: '\f783'; font: 900 21px/46px 'Font Awesome 5 Free' } a#Daily.tool-btn img { opacity: 0 }

あとは見た目関連のCSSやCSSをちょちょっといじって使っています。何か気になるものは質問いただけば、回答します。
Scrapboxに雑にメモできるせいで、記事もなんとなく雑になっちゃいましたね💦
皆さんもぜひScrapbox使ってみてください（締めまで雑）

Node.jsでファイルが直接実行されたときだけ処理を呼び出す方法

ikuma-t — Thu, 19 Aug 2021 00:30:44 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210819/20210819002958.png

経緯

JavaScriptの練習として、JavaScriptを解いており、ついでにJestでテストも書いていました。

// 実行ファイル：fizzbuzz.js// fizzbuzz関数const fizzbuzz = (num) => {    ...}// 表示処理for (...) {    console.log(fizzbuzz(num))}module.exports = fizzbuzz

// テストファイル：fizzbuzz.spec.jsconst fizzbuzz = require('./fizzbuzz')describe('FizzBuzz:1~20', () => {  test('3の倍数の場合には「Fizz」を返す', () => {    // テスト処理  })  ...})

テスト自体はパスするようにできたのですが、テスト結果にも実行ファイルに書かれているconsole.logの結果が表示されてしまう始末。これをどうにか表示させないようにするため、色々と調べてみました。

# テスト実行% npm test> test> jestPASS ./fizzbuzz.spec.js  FizzBuzz:1~20    ✓ 3の倍数の場合には「Fizz」を返す (1 ms)    ✓ 5の倍数の場合には「Buzz」を返す    ✓ 3と5両方の倍数の場合には｢FizzBuzz｣を返す    ✓ そのほかの数の時はそのままの数を返す (1 ms)# ==========テストとは関係ないので表示したくない（ここから）==========  console.log    1      at Object.<anonymous> (fizzbuzz.js:18:11)  console.log    2      at Object.<anonymous> (fizzbuzz.js:18:11)# ==========テストとは関係ないので表示したくない（ここまで）==========Test Suites: 1 passed, 1 totalTests:       4 passed, 4 totalSnapshots:   0 totalTime:        0.488 s, estimated 1 sRan all test suites.

TL
;

Node.jsでファイルが直接実行されているかどうかは、require.main === moduleで判断することができる。参考：https://nodejs.org/api/modules.html#modules_accessing_the_main_module

if (require.main === module) {    // 直接呼び出された場合にだけ実行したい処理}

Rubyの`FILE = $PROGRAM_NAME`的なイディオムがないか探してみる

やりたいことは次の2つです。- 実行ファイル（fizzbuzz.js）を実行した際には、console.logの結果を表示したい- 別のファイルから呼ばれた際には、console.logを表示したくない

Rubyの場合、以下のように記述することで、そのファイルが直接実行されたときだけ、特定の処理を呼び出すことができます。

if __FILE__ = $PROGRAM_NAME    # 直接呼び出された場合だけ実行したい処理end

JavaScriptでも同じような処理ができないかと思い、「FILE JavaScript」で検索してみました。
しかし、JavaScriptの__FILE__はファイルのJavaScriptを参照し、また$PROGRAM_NAMEに相当するものも見つからなかったため、一度この方向性は断念しました。

fjordbootcamp内で質問してみる

上記経緯からfjordboocamp内で質問してみたところ、「『Jest console.log』で$1と、console.logをMock化しろと出ているよ」との声をいただきました。

先ほどは実行ファイルの方で表示を制御する方法で検討していましたが、テストファイルで表示を制御する方法を提示いただいたわけです。

Jestでconsole.logをMock化してみる

「Jest console.log」で検索した見つかった、下記記事を参考にMock化を図りました。

Jestでconsole.logをモックする. 最近はテストを書くときはほとんどJestを使っています。今回は、v19から導入さ… | by 赤芽 | Medium

console.logの結果が残っています。これは、mockObj.mockImplementation(() => customImplementation) かobject[methodName] = jest.fn(() => customImplementation) を使うことで上書きできます。

Jestのドキュメント（jest.spyOn）にも記載されているとおり、以下の記述でconsoleオブジェクトのlogメソッドを別の処理（x => xつまりなにもしない）に置き換えることができます。

// consoleオブジェクトのlogメソッドをMock化して、その処理を`x => x`に置き換えるjest.spyOn(global.console, 'log').mockImplementation(x => x);

しかしながら、テスト実行結果には変わらずconsole.logの結果が出力されています。
Mock化とメソッドの上書きが正しく実行されているのか、それとも置き換え対象のメソッドがないのかの切り分けのため、以下のようにconsole.logが呼ばれたかどうかをテストに追記します。

const fizzbuzz = require('./fizzbuzz')describe('FizzBuzz:1~20', () => {  test('3の倍数の場合には「Fizz」を返す', () => {    // テスト処理    // 追記箇所：console.logが呼ばれているか確認    expect(console.log).toBeCalled()  })  ...})

この結果はテスト失敗、つまりconsole.logは呼ばれていないこととなり、テストケースで呼ばれていない処理をMock化しても意味がないことがわかりました。

console.logが何によって実行されているか確認してみる

テストケース内で呼ばれていないことがわかったため、消去法的に実行ファイルfizzbuzz.jsをrequireした瞬間にconsole.logが実行されていると推測できます。

（ちょっとここらへんどう検索したか忘れましたが、）実際にrequireは実行された瞬間にそのファイルを読み込む仕様とSなっており、これを回避するための策として、以下の手順が書かれている記事をいくつか見つけました。

if (!module.parent)    // 直接呼び出された時だけ実行される処理end

module.parentはrequire元であり、自身がrequireされていれば、falsyになるという仕組みです。

module.parentの代替案を探す

いずれの記事も更新日時が古かったため、Node.jsの公式ドキュメントを確認すると、module.parentは非推奨となっていました。

Deprecated: Please use require.main and module.children instead.

Modules: CommonJS modules | Node.js v16.7.0 Documentation

代わりにrequire.mainかmodule.childrenを利用するように記載があります。
require.mainを確認すると、参考リンクに探し求めていた解決方法がありました😄

When a file is run directly from Node.js, require.main is set to its module.Modules: CommonJS modules | Node.js v16.7.0 Documentation

「Node.jsから直接ファイルが実行されると、require.mainには、自身のmoduleが設定される。」つまり、次のように記述することで要件を満たすことができたのでした。

if (require.main === module) {    // 直接呼び出された時にだけ実行される処理}

まとめ

今回全部調べ終わってから気がついたのですが、「JavaScirpt　直接実行された場合のみ」とか検索すると、日本語記事もいくつかヒットしましたね。しかしながら、非推奨のmodule.parentを記載しているものもあったので、自分で調べてみてよかったです。

【RubyMine】意図しない拡張子でファイルを開いてしまった時に、開く拡張子を変更する

ikuma-t — Wed, 11 Aug 2021 15:49:00 GMT

発端

パーフェクトRailsを読みながらRailsの復習をしており、rails db:migrateした結果を、RubyMineのDatabaseウィンドウで確認しようとしたのですが、誤ってdb/development.sqlite3を「テキストファイル」として開いてしまいました。

そのため、RubyMine上で拡張子が誤認されたファイルを、正しい拡張子に変更する方法を調べてみました。

なおRubyMineのバージョンは2021.2です。

結論

Preferences > File Typesから、誤って指定したファイルタイプを選択し、File name patternを修正する。

詳細

Preferencesは、⌘ + ,もしくは、上図の場所から展開できます。

Preferencesを開くと、Editor > File Typesという項目があるので、これを選択。
すると、各拡張子ごとに、「どのようなファイル名であればそのタイプとして認識するか」の一覧が表示されています。

今回はTextに対して、「.sqlite3」が紐づいてしまったので、これを選択して「-」で削除することで、紐付けを解除できます。

紐付けが解除されたことで、今回は自動でDBとして再認識され、Databaseウィンドウも無事に開くことができました🎉

参考

ファイルタイプの関連付けを設定する | RubyMine

リーダブルコード第1部を読みました

ikuma-t — Tue, 10 Aug 2021 10:37:33 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210810/20210810103304.png

リーダブルコード第1部を読みました

名著と名高い、リーダブルコードの第1部を読み終えたので気になった部分をまとめてみました✍️

https://www.amazon.co.jp/dp/4873115655/ref=cm_sw_em_r_mt_dp_CKCCTS6RS380FVEWK26K

プログラミングの時間のほとんどはコードを読む時間

プログラミングの時間のほとんどはコードを読む時間なのだっ！— p.43

第1部では「表面上の改善」と題して、名前やコメントのあるべき姿を述べています。

本書全体を通して、「理解しやすい」コードを書くためのTipsが散りばめられていますが、なぜ理解しやすいコードが必要なのでしょうか。

本文の中にもいろいろと書いてあるのですが、個人的に一番ビビッと来たのは冒頭に引用した言葉です。

SIerで初めてJavaを触った時、プロダクトのコードが全く理解できなくて、既存のコードをずーっと読み続けている時期がありました。読んでいくと次第に法則性がわかるようになってきて、法則性がわかると自分でも書けるようになっていきました。これが私がプログラミングの面白さに触れた原体験の部分であるため、「読む」という部分には強く共感しました。

コードは読むもの→求められるのは論理性・国語力

プログラミングというと、どうしても「このメソッドを使うとより短く書ける」「この記法を使うと$1で書ける」といった部分を想起しがちですが、本書第1部で述べられているのはそういった$1なところではなく、もっと$1的な、教科で言えば「国語」的なアプローチです。

例えば「3章誤解されない名前」には次のような一節があります。

名前が「他の意味と間違えられることはないだろうか」と何度も自問自答する— p.30

本書では、filter メソッド名は抽出結果が曖昧である（取り除く対象なのか、取り除かれたものなのか）という例があげられています。

この問い、つまり「他の意味と間違えられることはないだろうか」について、もう少しどういう考え方が必要か自分なりに考えてみると、「そのメソッドのインプットとアウトプットが、メソッド名で正しく紐づくか」という観点が重要なのではと思いました。

A→(method)の結果がBに特定できるのであればいいけれど、B以外のCが検討できたり、そもそもBに紐づかないことはNG。A→（method）→Bとなるように因果関係を正しく構築できているかを確認することで、わかりやすいメソッドにできるのではないでしょうか。

これはちょうど学生時代に国語の問題で因果関係が正しくなるように線で結ぶ問題と同じようなものです。プログラミングは論理的思考が求められるといいますが、それはプログラムの流れだけではなくて、名前にも適用されるのかもな〜なんて考えました🤔

情報密度の高い言葉を使う

一応コンサルみたいなことやっているので、日常的にカタカナ言葉にさらされているのですが、基本的によく意味を理解せず横文字を連発する人は嫌いです。

それはさておき、英単語と日本語では厳密なイコールにならないため、英語一単語で複数の日本語を言い表せることもあります。概念的な言葉であれば尚のことです。

本書ではコメントを圧縮して見やすいものにするために、これらを使うことを提案しています。

どこまでが一般認知とされているか
対応する単語はどれか、別の捉え方にならないか

といった部分を考慮しないといけないので、簡単そうに見えて意外と難しそうなテクニックです。

これも言葉の言い換えスキルなので、国語力が求められるといっていいのかなと感じました。

おわりに

プログラミングといえば、$1や$1力などが重要なイメージですが、本書第1部ではそれよりも論理力・国語力が重要である印象を受けました。

私は文系かつ就職してからプログラミングに出会った人間なので、いわゆるプログラミング的な素養は乏しいですが、これまで経済・経営（社会科学）に向き合うことで培ってきた姿勢を生かして、リーダブルなコードを書けるように精進していきたいと思います。

ブログをGatsbyjsに移行.... しかけてやめました

ikuma-t — Mon, 09 Aug 2021 10:20:00 GMT

Gatsbyjsでブログを作ってみました。

久々の投稿です。
仕事が忙しくてこのブログも学習も放置気味だったのですが、やっと落ち着いてきたので、いろいろ再開しています。

実は7月の末あたりからブログを移管しようと考えていて、実際に以下のGatsbyjsでブログを作成しました。

ikuma-t.work

JavaScriptはほとんど触ったことなかったので（もちろんReactも）、表記の仕方にだいぶ苦戦しましたが、なんとか形にはなりました。

SEOが貧弱すぎるので、しばらくははてな継続

独自ドメインを取得して公開してみたはいいんですが、びっくりするほど検索に引っかからないです。

今回ネットで検索してみて初めて分かったんですが、世の中には結構な数の「ikuma」さんがいました🐻なので「ikuma-t ブログ」なんて大きなキーワード検索しても辿りつかないわけです。

必要最低限のmetaタグは設定こそすれど、SEOについてはいろいろと考えることが多そうなので、一旦メインブログはこのはてなブログで継続していくつもりです。（どちらもmarkdown形式で記述できるので、しばらくは両方に同時投稿するかもです）。

ikuma-t.work

👆この記事は嘘ですね笑

自分でブログを作ってみて思ったこと

よかったこと

「Gatsbyjs使いたい！」という気持ちに一区切りついた
JavaScriptへの耐性が少しついた（ブログ作るために、少しJS Primerとかかじったので）
自分でデザインを考えられるので自由度が恐ろしく高い。
HTML、CSSの復習ができる
ブログサービスではなかった、デプロイ、ドメイン取得、meta設定などを体験することができた

微妙だったこと

タグ機能とか、Twitter用カード設定とか、ブログで必要そうなことも基本的には自前でやらないといけない
SEO対策を自分でやらないといけない（これははてなでも同じだとは思いますが、もっと根本的なところからという意味で）
絶妙に情報が少ないので（自分はCMSにContentfulを使用していますが、こちらの情報が少ない）、調べるのに苦労する

おわりに

今後もこのブログではやってみたこと・学んだことをアウトプットしていきますので、よろしくお願い致します〜😊

Gatsbyjsで作成したブログのTwitterCardを表示させる

ikuma-t — Fri, 06 Aug 2021 00:00:00 GMT

問題

Card Validator | Twitter Developers

ブログを作ってみたはいいんですが、投稿があるたびにTwitterで共有しようにもTwitterCard（OGP画像）が表示されずに困っていました.

そこで今回はこのエラーの原因を突き止め、TwitterCardが表示されるようにしてみました。

TL
;

プラグインgatsby-react-helmetが追加・設定されていなかったことが原因
Developer　Toolで確認するとmetaタグがあるように見えても、実際にビルドされたHTMLを確認して、必要なmetaタグが追加されているか確認することが大事

調査

まずは次のような調査方針で進めてみました。

TwitterCardが表示される仕組みを調べる
1と現状のサイトを比較し、足りていない要素を調べ、追加する
2で表示されなければ、調査方針再検討

TwitterCardが表示される仕組み

カードの利用開始

【2020年版】Twitterカードとは？使い方と設定方法まとめ

これらの記事を確認する限り、TwitterCardを表示するために必要なことは、以下のmetaデータを設定することのようです。

<meta name="twitter:card" content="カード種類" /> <!--①-->
<meta name="twitter:site" content="@ユーザー名" /> <!--②-->
<meta property="og:url" content="記事のURL" /> <!--③-->
<meta property="og:title" content="記事のタイトル" /> <!--④-->
<meta property="og:description" content="記事の要約（ディスクリプション）" /> <!--⑤-->
<meta property="og:image" content="画像のURL" /> <!--⑥-->

現状のサイトと比較

確認したところ、エラー発生時には、次の3つのmetaデータがありませんでした。

<meta name="twitter:site" content="@ユーザー名" /> <!--②-->
<meta property="og:url" content="記事のURL" /> <!--③-->
<meta property="og:image" content="画像のURL" /> <!--⑥-->

Twitter特有のmetaとしては、twitter:siteがもっとも怪しそうなので、まずはこちらを追加してみます。

{
    name: `twitter:card`,
    content: `summary_large_image`,
},
{
    name: `twitter:site`,
    content: `@ikumatdkr`,
},

なおも失敗してしまったので、og:urlを追加してみます。

{
    property: `og:url`,
    content: `https://ikuma-t.work/`,
},

またもや失敗してしまいました。エラーメッセージが変わらないのが気になるところです🤔

最後に、まだ不足しているog:imageを追加します。

{
    property: `og:image`,
    content: `https://ikuma-t.work/static/logo.png`,
},

エラーメッセージ含めて、何も解消されません。

方針再設定

設定をしたにもかかわらず、Card Validatorが表示するメッセージが変わらないことを考慮すると、どうやら別のところに原因がありそうです。

しかも登録しているmetaタグはいくつもあるのに4 metatags were foundとしか表示されないことを考えると、次の2つの可能性が考えられます。

metaタグが実際には生成されていない
metaタグが生成されてはいるが、読み取られていない

まずは1つ目について確認してみることにしました。

生成されたmetaタグを確認する

ここまではChrome Developer Toolで確認してきましたが、実際にgatsby buildによって生成されたhtmlがどうなっているかを確認してみます。

すると、metaタグに相当するのは4件のみで、Twitter関連で設定した内容は全く反映されていません。

どうやらここが怪しそうです。

gatsby-react-helmetが正しく機能しているかを確認

メタデータを追加するために、react-helmetを使用しているのですが、Gatsbyjsで使用するためにはgatsby-react-helmetも必要です。

つまり、以下のような実際にmetaタグを定義するコンポーネントだけではNGで

import { Helmet } from "react-helmet"

const Seo = () => {
  return (
    <Helmet>
      /* meta情報を記述 */
    </Helmet>
  )
}

それを使用する前提として、プラグインを追加し、

Terminal window

$ yarn add gatsby-plugin-react-helmet react-helmet

それをgatsby-config.jsで宣言しておく必要があるのです。

plugins: [`gatsby-plugin-react-helmet`]

gatsby-plugin-react-helmet

…確認してみたところ、プラグインの追加と宣言が漏れていました。

そのため上記設定を施し、再度gatsby buildを実行すると、ビルド結果のHTMLにmetaタグが追加されていました。

Developer Toolでの確認結果も、metaタグが上位に表示されるようになり、

metaタグも読み取られ、Twitter Cardが表示されるようになりました。

ついでに各記事ページごとにヒーローイメージを取得するように設定して、本件は任務完了です🥷

キーキャップをマンチェスターシティ色に替えてみた

ikuma-t — Tue, 03 Aug 2021 00:00:00 GMT

キーボードへの情熱の高まり

先日日暮里散策をしている際に、秋葉原まで足をのばして遊舎工房さんにたちよったのですが、その際にど〜〜しても新しいキーボードが欲しくなってしまいました。

しかしながら、愛機Majestouch2はまだまだ現役、新しいものを買っても使用用途が複数あるわけでもないので、今回はキーキャップを変更することで、気分一新することに。

ダイヤテックのオフィシャルサイトでキーキャップを購入

あまりキーボード界隈には明るくなく、購入したキーキャップがはまらないという可能性も考えられたので、今回はMajestouchの販売元であるダイヤテックさんのオフィシャルサイトでキーキャップを購入することにしました！

キーキャップの一覧 FILCO取り扱いキーキャップ | ダイヤテック株式会社

もともとのキーキャップは日本語配列かつ、かな文字印字タイプだったのですが、かな文字は不要なので、日本語配列かな文字なしから選択し、以下の４つの商品を購入。

トータルで7000円くらいしました…💸

いざ入れ替え作業へ

…といっても、キーキャップをとって、新しいものをはめるだけなので作業的には特に難しいことはないですが、今回は自分で配色をミックスするので、どんな色配置にするかが悩みどころでした。

もともとkeychronのキーボードを購入しようと思っていたのですが、試し打ちしたところキーストロークが意外と浅かったので断念した経緯もあり、EscとBackSpaceは色を変えたいというイメージがありました。

あわせてデザイン的に気に入っていたiqunixを参考に、文字部分と特殊キーの色は変えるイメージでキーキャップ入れ替えを実施しました。

完成！！

できたのがこちら！文字部分を水色、それ以外を黒としながら、Tabキーと使用しないPrintScreen等を漆塗りのキーキャップにしてみました。

替えて数時間後にこのブログ書いてますが、ここの3つのキーはそもそも何だったか忘れました。 WindowsでOfficeソフトの作業する際にたまに使えるんですが、ほぼ使えないので、ここは飾り枠です。

BackSpaceもアクセントカラーになっていて、いい感じです😊

感想

イギリスのキーキャップ、水色…図らずもマンチェスターシティみたいなキーボードになっちまいました。

それはさておき、自分で色を決めて配置したことでよりキーボードに愛着が湧いてきました！これからもMajestouch2でスコスコしていきたいと思います💪

独習Gitを読んでみた

ikuma-t — Sun, 01 Aug 2021 00:00:00 GMT

GUIに頼りきりでGitコマンドうろ覚え

RubyMineを使っていると、Git操作はGUIで完結してしまい、ちょっとコマンドが覚えづらいというデメリットがあります（コマンドの概念と便利さを知る分には十分有用です）。

もちろんgit add、git commitといった基本的なコマンドは使えますが、「差分コミットしたい」「一部だけステージから下ろしたい」など、イレギュラー操作はちょっとしたところでもコマンドでやろうとするとググらないといけないレベルです。

そのため、この度独習Gitを購入し、コマンドの習得に励んでみました💪

独習Git（リック・ウマリ吉川邦夫）｜翔泳社の本

学習方針

先に述べたようにGitコマンド全部がわからないわけではないので、本書に登場する未知（or既知だけれども習熟していない）コマンドだけを、各章にある「この章のコマンド」ページから抜粋します。

学習内容

3章：Gitに馴染む

git config --list(ショートハンドは-l)：すべてのGitの設定値を表示。エイリアスの設定値を確認するのにたまに使うけど、オプションを忘れがち。git configだけ実行すると、usageが表示されるので、そこから再実行するのもよし。

4章：リポジトリの作り方と使い方

git ls-files：リポジトリにあるファイルをリスト表示する。使い所あるかなあ。

6章：ファイルの追跡と更新

git commit -a -m "Message"：git addとcommitを同時に実行する。

Terminal window

$ git commit --help
#
-a, --all
           Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

aオプションはallオプションのショートハンドで、変更があったファイルを自動的に追随するようにする内容見たいです。これは結構使い所が多そう。

git log --shortstat --oneline：オプション重ねがけ。--shortstatは各コミットで変更されたファイルのリストを一行で表示し、--onelineはコミット自体を一行で表示する
git add {-n | --dry-run} <変更対象>：git add <変更対象>を実行した際に、どう言ったステージングが実施されるかを表示する。実際にはステージングはされない。
git diff、git diff --staged：GUIでやっているとつい忘れがち。前者が作業ツリーとステージングエリアの差分、後者がステージングエリアとリポジトリとの差分を表示する

7章：変更箇所をコミットする

git rm <ファイル名>：ステージングエリアからファイルを削除する。作業ツリーに対して削除を実施した場合、それをステージングエリアに反映する必要があるが、このコマンドの場合、直接ステージングエリアのファイルを削除できる。
git add -p：部分的なステージングを実行する。コマンドを実行すると、ステージング対象のハンク（一塊）が、順番に表示される。それぞれに対して、以下のいずれかを指定する。

Terminal window

Stage this hunk [y,n,q,a,d,K,g,/,e,?]? ?
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
K - leave this hunk undecided, see previous hunk
e - manually edit the current hunk
? - print help

※続きは随時更新

Exercism(Ruby)で学んだこと

ikuma-t — Sun, 01 Aug 2021 00:00:00 GMT

Exercismとは

Exercismは、無料でできるプログラミング練習問題サイトです。言語ごとに100種類近い練習問題が用意されており、ちょっとした文法の練習に最適です。（文法だけ読んでると退屈なので、これで遊んで覚えます）

Exercismでの問題を解く流れは次の通りです。

練習問題をコピー
自分で解く
提出
他の人の回答が見られたり、レビューを受けられたりする

今回Rubyが久々ということもあって、人の回答を見る中で「そういうのもあるんか！」と思ったものが多々ありました。そこで、個人的に気になったものを随時この記事にまとめていこうと思います。

学んだこと

Integer#digits

登場回：Armstrong Numbers

base を基数として self を位取り記数法で表記した数値を配列で返します。 base を指定しない場合の基数は 10 です。class Integer (Ruby 3.0.0 リファレンスマニュアル)

ナルシシスト数の導出のために、与えられた数値を桁ごとに区切る必要があったのですが、自分の回答では、以下のように一旦文字列に置換してから分割処理を実施していました。

irb

153.to_s.chars
#=>["1", "5", "3"]

Integer#digitsであれば文字列を介さずに、分割することが可能でした。ただし、1のくらいから順に格納されるので、中身は同じですが、順番が異なる配列が完成することに注意です。

irb

>> 153.digits
#=> [3, 5, 1]

冪乗の`e`

登場回：Gigasecond

これはRubyというよりも数学的なところですが、10の冪乗はeを使っても表せるようです。浮動小数点になることに注意が必要ですね。

irb

>> 1e9
#=> 1000000000.0

参考

Rubyで等比数列

登場回：Grain

Rubyで等比数列を作る場合、以下のように記述できるようです。

geometric.rb

# num: 初項
# ratio: 公比
# length: 数列の長さ
def geometric_sequence(num, ratio, length)
  Array.new(length) { |n| num * ratio**n }
end

参考：【Ruby】等差数列・等比数列を作成する１番シンプルな処理 - Qiita

余談：このGrainという問題は、「Wheat and chessboard problem」といって、歴史ある数学的問題のようです。

ブログをGatsbyjsに移行しました

ikuma-t — Sun, 01 Aug 2021 00:00:00 GMT

はてなブログから乗り換えました

もともとセットプチフォッカというブログをはてなブログでやっていたのですが、Gatsbyjsでブログを作ってみたかったのと、独自ドメインで運営したかったので、この度ブログを作り替えました。

制作にあたっては、Gatsby入門を参照しました。いまのところ、デザインも機能もここに記載の通りなので、徐々に拡張していきたいと思います。

RubyMineのショートカット

ikuma-t — Sun, 01 Aug 2021 00:00:00 GMT

だめだ…RubyMineのことが思い出せない

どうもikuma-tです。仕事が忙しかった関係で、3ヶ月くらいRubyを触っていなかったのですが、それに伴いRubyMineのショートカットを半分くらい忘れました😅

ここ1週間くらいは、このブログを立ち上げるためにJavaScriptとHTMLとCSSを触ってはいたのですが、なにせVSCodeでやってしまったもので、VSCodeのショートカットが馴染んでしまい、RubyMineで動かしても「あれ、動かない…」

そんなわけで、次忘れた時のために、最低限覚えておきたいキーボードショートカットを書いておきます。

前提

RubyMine：2021.02

ショートカット

行削除：⌘+⌫
新規行を追加：⇧+Enter
ターミナルを開く：⌥+F12
指定したファイルを分割ウィンドウで開く：ファイルを指定した状態で、⇧+Enter
選択行を上下に移動：⌥+⇧+↓or↑
リファクタリングのコンテキストメニューを開く：Ctrl+T
大文字小文字の切り替え：⌘+⇧+u
キャメルケース等の切り替え：⌥+⇧+u

参考

日暮里で散策

ikuma-t — Sun, 01 Aug 2021 00:00:00 GMT

日暮里で散策

今日は天気も良かったので、日暮里周辺にちょっとお散歩に出かけてきました。

日暮里駅の駅舎は古き良き町並みにあう景観になっていました。日暮里駅の文字がねこになっているのが可愛らしい😸

TAYORIでお昼

お昼は気になっていたTAYORI(食の郵便局TAYORI – 食の郵便局です。）というお店へ。

ランチは5種類くらいから選べるんですが、今回は今週の日替わり=白身魚の唐揚げ定食に！

白身魚はとてもふわふわで、全体的に薄味ながらもしっかりと旨みを感じる料理で大満足でした👍

MOTHER HOUSEでマネークリップ購入

お昼を食べて路地へ。「そういえば薄い財布買うと言っておきながら、全然買ってないね」なんて妻と話していると、商店街のMOTHER　HOUSEというお店が目に飛び込んできました。

マザーハウス｜MOTHERHOUSE

「お、ちょうどマネークリップあるじゃん！」

と興奮気味にマネークリップを物色し、5分ほどで購入決定。革でありながら、価格帯も1万円台とお求め安く、いい買い物ができました。

なんか保護クリーム的なものを塗ってもらったので、2日間くらい休ませてから実際に使用です！楽しみ〜😄

おわり

まあこのあともフィルムカメラみたい、キーボード見に行ったりしたんですが、全部写真撮り忘れましたので割愛です😅

散財こそすれど、出かけて、いろんな商店を覗いたことで世界が広がった1日でした。また日暮里散策したいです。

おわり

うちNotion

ikuma-t — Fri, 07 May 2021 18:10:27 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210223/20210223123237.png

Notionいいよね

Notionいいですよね。日本でも最近かなりアツいプロダクトとなっていて、企業でも使われるケースが増えてきています。

私も結構前からNotionを利用していて、

個人用のNotion（ぼくNotion）
家庭用のNotion（うちNotion）

と用途別にアカウントを作って、運用しています。

今回は家庭用（私と妻の二人暮らしです）に運用している「うちNotion」について紹介したいと思います。

Notionいいよね
これが「うちNotion」の全貌だ！
苦労の末に辿り着いたNotion家計簿
我が家の「土曜ロードショー」はNotionがきっかけ
- 「いつか一緒に見たい」を確実に
家事へのアプローチをNotionで平準化
- 毎回修正される洗濯物と、頭の働かない私
- Notionでサイロ化した洗濯業務を見事解消
おわりに：Notionのはじめたては、作り込みすぎないのが大切

これが「うちNotion」の全貌だ！

我が家のサイドバーはこの5種類です。

田所家：家族ページ。家族で使っているサービスとかNotionページへのリンク
家計簿：我が家の家計簿
カンバン：かんばん形式で家のタスクを管理。かなり緩め。
映画：見たい映画、見た映画を管理するページ
おうちメモ：家事の仕方やレシピ、2人で話したことをまとめています

「うちNotion」は「ぼくNotion」よりも運用コストを意図的に小さくしているので、アイコンは基本的にNotionのプリセットアイコンを使用しています。

ただ家計簿だけは例外でフリーのアイコンサイトから落としてきたものを使用しています。

Download Free Icons - 110,361+ Icons To Choose From Iconscout

家族ページとかんばんは結構一般的な形態で特筆事項もないので、それ以外について紹介したいと思います！

苦労の末に辿り着いたNotion家計簿

まずはNotion家計簿です。我が家のNotionはもともと家計簿ページだけから始まり、Notion運用に慣れてきたところで他のページをビッグバン的に作成しました。

歴史があるだけあって、やや内部ページは多めですが、構成としては次の3つです。

実際に毎日の入力を行う家計簿はこんな感じになっています。

家計簿の始まりはGoogleGoogleだった

結婚して大体2年くらいになりますが、一緒に生活を始めたあたりから家計簿自体はつけていました。最初の数ヶ月は妻が家計簿アプリを使っていたのですが、私が入力する機会も多くなったので、共同編集ができるようにGoogleGoogleに切り替えました。

左）$1での家計簿（第2版くらい？）。明細を一行ずつ入力すると、別シートで集計する。右）レイアウトをカレンダービューにしようとした際のプロトタイプ

$1は$1アプリなので集計は問題なかったのですが、運用を続けるにあたって次の問題が浮上してきました。

モバイルで入力するのが面倒
毎月の集計列を作成するのが面倒
計算式が複雑になってきてメンテナンスが大変

加えて、妻から「もっと上がるデザインがいい（意訳）」という要望が出たこともあり、妻がカレンダービューを持った家計簿を作成。

しかしながらこちらも$1だったので同様の問題点があり、かつカレンダー入力のために費目をアルファベットにしたところ、入力が面倒に。

そこで個人で使用していたNotionを使って家計簿を組んでみることに。

これまでの$1運用で必要要件はわかっていたので、あとはそれをリンクドデータベースと、デザインに落とし込んでサクッと構築。

ふんだんにアイコンも盛り込んで、妻も大満足なのでした😁

家計簿テンプレートの構造

家計簿テンプレートは4つのDBから構成されていて、これをレゴブロックのようにはめこんで1ページに埋め込んでいます。

家計簿入力（カレンダー）
費目ごとの予算
支払方法別集計
全体収支

使い方としてはシンプルで、①のカレンダーに費目を入力するとRollUpで各DBが自動更新される仕組みです。

テンプレートは都度見直し、更新履歴を記録

テンプレートを使っていると、「この費目が欲しい」とか「もっと入力を楽にしたい」という要望が出てくるので、都度都度更新しています。

更新履歴は「家計簿テンプレートの使い方」ページに追加し、変遷をみられるようにしています。

例えば最近だと、「妻は$1からNotionを起動して家計簿を入力する。大体スーパーの買い物で、支払手段は固定」という$1がわかったため、家計簿入力のテンプレートに「スーパー」というテンプレートを追加したりしています。

我が家の「土曜ロードショー」はNotionがきっかけ

続いては映画ページです。このページでは、みたい映画、みた映画を2つのビューで管理しています。

我が家では毎週土曜の夜は勝手に「土曜ロードショー」を開催しており、その際にボードビューでみる映画を検討しています。

「いつか一緒に見たい」を確実に

妻はかなり映画やドラマが好きで、時間があれば一日中Netflixでなにかみています。

対して私はというと、興味がないわけではないのですが、普段全然映画を見ません。パソコンをずっといじっているのが好きです。

そんな映画の興味に格差がある家庭ですので、

妻「これ今度一緒に見たい！」

私「おお！みよう」

…で結局見ない、そして妻は何をおすすめの映画を忘れるという事態が多発していました。

そこで「パソコンをずっといじりたい自分」と「映画をおすすめしたい妻」の利害を一致させることを画策。

「Notionで映画ページを運用する」ことで私の映画に対する興味を駆り立て、妻の記憶を共有。結果土曜ロードショー開催にこぎつけたのでした。

なお見終わった映画には、ざっくりなレートとそのとき食べたおつまみをプロパティとして登録しています。

ドライいちじくとゴーダチーズの組み合わせは最高😊

家事へのアプローチをNotionで平準化

最後は「おうちメモ」です。こちらではざっくりといろんなメモを格納しています。

何回かこういう類のページを作ってきたのですが、はじめはテーマごとにページを作るよりも、タグで分類する方が管理コストが低いのでおすすめです。

タグごとに絵文字をテンプレート化しておくと、ぱっと見た時の見栄えもいいです。これはzenn.devから着想を得ました。

毎回修正される洗濯物と、頭の働かない私

我が家では妻が洗濯を担当しているのですが、面倒になったり、忙しかったりするとたまに私がやります。

で、Notion導入前はほぼ毎回洗濯が終わるたびに、妻からの指摘が入っていました😅

こうなると私は洗濯をしたくないし、妻も「頼むくらいなら自分でやろう」と思う悪循環です。

Notionでサイロ化した洗濯業務を見事解消

そこで「Notionに作業メモ作るから、一から教えてください」と懇願し、洗濯作業テンプレを作ることに。

あらためて文字に起こすことで、「洗濯物が干せればよかった私」と「洗濯物にいかにシワがつかず、乾きやすくなるように干せるかを考えている妻」とのギャップが浮き彫りに！以降、このメモを元に洗濯を行うことで、洗濯での指摘は大幅に減りました（なおゼロにはなっていない模様）

おわりに：Notionのはじめたては、作り込みすぎないのが大切

いかがでしたでしょうか。Notionはかなり自由度が高いアプリなので、ついつい作り込んでしまうのですが、それゆえに「Notionをいじっていたが、なにも生活に寄与していない。ただ時間が溶けただけ」となりがちです。

そのため、「何を解決したいのか」「どういう風に使っていくのか」を考え、スモールスタートで始めるのがいいんじゃないかなあと思っています。

次回は「ぼくNotion」の方を紹介したいと思います！

COMMENT

. 空白のブロックを2つ作る1. 1で作ったブロックの一方をドラッグして、横並びにする（これで2列になる）。1. 別に作っておいたカレンダーとテーブルを2で作った列に配置する。私はこちらの手順で横並びにしています。手順1,2は以下のツイートでも紹介しているので、ご参考までに😁https://twitter.com/ikumatdkr/status/1288772066355769344COMMENT:EMAIL: m3104.510@gmail.comいきなりのコメント失礼します。私も今notionで家計簿を作ろうとしていますが、カレンダーとテーブルビューが横並びにできないのですが、どうやって作成されましたか？

【Excel】社内でExcelのデータ操作機能について勉強会をしました

ikuma-t — Mon, 15 Feb 2021 15:05:18 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210215/20210215110559.png

ちょっと前なのですが、社内勉強会でExcelについての勉強会を行いました。
せっかく資料を作ったので、供養のためにこのブログで晒します。

実際に発表した資料はこちらです↓↓↓

speakerdeck.com

スライド中でも述べていますが、Excel2010あたりからExcelにPowerQueryという機能が追加されました。

簡単にいうとExcelでRDBMS的なデータ操作（JOINとかGROUP BYとか）ができるようになる機能で、ちょっとしたデータの加工だったらExcelで事足りるようになります。（詳しい使い方はスライドを参照してください🙇‍♂️）

便利ではあるんですが、すでにRDBMSにデータが入っている場合はそちらを使った方がパフォーマンス的にも手間的にも得策ですね。

わたしのリフレッシュ方法（2021年版）

ikuma-t — Sat, 16 Jan 2021 14:23:32 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210116/20210116135617.png

最近ふと、「あ、これ疲れた時によくやっているなあ」と思ったので、私のリフレッシュ方法3選をまとめてみました。

ちなみに選考基準はずばり「手軽さ」です。
リフレッシュはJustInTimeで届けないと意味がないことに加え、金がかかるとリフレッシュすることをためらってしまうので。

シナモン

Amazon | ハウス GABAN シナモンシュガー<パウダー> 32g×5個 | GABAN(ギャバン) | スパイス・ハーブ通販

甘い匂いで一気にリフレッシュ！
砂糖も入っているので、焼いたトーストにバターを塗ってこれを振りかけるとシナモンシュガーバタートーストの完成です。

アロマもいいですが、これは食えるところがいいですね。

$1ー

ジャスミン茶　600ml | セブンプレミアム公式セブンプレミアム向上委員会

これはオフィス勤務時によく買っているやつです。
シナモンと被りますが、こちらも$1の香りでリフレッシュ！飲んだ後にさっぱりするのもポイントですね〜。

少し前からパッケージにでかでかと「茶」の文字が主張するようになりました。
私にはなぜかコムギに見えます。

コンビニで買える$1ーとしては、ファミマの$1ミルク$1というのもおすすめだったのですが、今はもう売っていないようです。
（代わりに烏龍ミルク$1が出ていました。伊藤園　タリーズ　烏龍ミルクティー）

肩のストレッチ

ちょうどいい画像がなかったので引用。以下のサイトの「二の腕のストレッチ」のことです。【部位別40種類】初心者向けストレッチのやり方を写真で解説！ | | Dews (デュース)

子供の頃はなんてことのないストレッチだったのですが、大人になってからすごいきく！

肩こり予防、血流改善に効いてそうです。

たまにTarzanを立ち読みして、「オフィスでできるストレッチ」みたいな特集をみるんですが、静まりかえったオフィスで大仰なストレッチをするのは無理+ストレッチ自体が思い出せないというのがほとんど。

その点このストレッチは、腕の部分だけで、スペースを取らず、しかも慣れ親しんだ動きでできるので非常にいいです。

以上、わたしのリフレッシュ方法（2021年版）でした〜。

RubyMineでライブラリのソースをGrepする方法

ikuma-t — Sat, 16 Jan 2021 11:05:46 GMT

ActiveStorageのwith_attached_#{name}がどこに定義されているのか確認する過程で、RubyMineでの調べ方を覚えました。

対象バージョン

RubyMine 2020.3.1

Find in Files

RubyMineでGrep検索を行うには、編集 | 検索 | パス内検索 ⇧⌘ Fから「Find in Files」メニューを起動します。

Find in Files画面

試しにwith_attachedあたりで検索をかけてみても、自分のソースで書いた部分しか引っ掛からず、定義元は抽出されません。
これは検索の対象（図中、緑枠）がIn Projectになっているのが原因でした。

オプション	検索対象
In Project	現在のプロジェクト（外部ライブラリは含まない）
Module	モジュール指定ができるようになる。指定したモジュールの範囲で検索する
Directory	$1リ指定ができるようになる。指定した$1リの範囲で検索する
Scope	スコープが指定できるようになる。事前に定義されたスコープの範囲で検索する

スコープについては、こちらを参照。
要はファイルを目的に応じてグルーピングできる機能です。

自分で定義しなくてもRubyMineのプリセットがいくつかあるようですが、今回は大雑把にAll Placesで$1を実施し、見事欲しいソースに到達できました。

ActiveRecord::PendingMigrationErrorに初遭遇したので、ちゃんと対処する

ikuma-t — Sun, 10 Jan 2021 19:56:03 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210110/20210110195519.png

ActiveRecord::PendingMigrationErrorに初めて出会ったので、備忘がてらまとめていきます。

発生時の状況
- 環境
- 開発状況
ActiveRecord::PendingMigrationErrorとは
対処方法（今回のケースの場合）
おまけ1：bin/rails db:migrate
と bin/rails db
おまけ2：マイグレーションの状況確認のために、覚えておくと良さそうなコマンド
おまけ3：bin/railsするべきか
参考

発生時の状況

環境

Rails 6.1
Ruby 3.0.0

開発状況

各ブランチのDDLファイルは以下の通り。DDLファイルの数は違うが、最終的に実行されるDDL文は同じ（ブランチAはRails6.1、ブランチBはRails6.0での作業→6.1アップグレード）。

ブランチA：（自分）ActiveStorageに関する$1を実行
- 20210108102934_create_active_storage_tables.active_storage.rb
ブランチB：（他の人）ActiveStorageに関する$1を実行
- 20201122075737_create_active_storage_tables.active_storage.rb
- 20201227052520_add_service_name_to_active_storage_blobs.active_storage.rb
- 20201227052521_create_active_storage_variant_records.active_storage.rb

ブランチAでbin/rails db:migrateを実行しているため、DBにはすでにテーブルが存在する。
ブランチAでの作業後に、ブランチBに切り替えbin/rails sしたところ、ActiveRecord::PendingMigrationErrorが発生。

ActiveRecord::PendingMigrationErrorとは

未実行の$1ファイルが存在するということ。
今回の場合は、ブランチBで作成されている3つの$1ファイルが実行されていないので、エラーとなっています。

ちなみにRailsは次のような形でRailsファイルの実行状況を確認しているみたいです。
参考：rails/migration.rb at 914caca2d31bd753f47f9168f2a375921d9e91cc · rails/rails

$1リ内の$1ファイルをすべて検索
テーブルschema_migrationから適用済みの$1ファイルを検索
1と2の差分を確認する（差分がある場合に、ActiveRecord::PendingMigrationErrorを発生させる）

なおschema_migrationはDBに追加されているテーブルで、以下のような構造です。

versions
20201122065204
20201121230730
20201121231228
20201121231845

対処方法（今回のケースの場合）

bin/rails db

今回の場合、$1自体を行っていないのがそもそもの原因なので、bin/rails db:migrateを実施すれば良さそうです。
しかしながら、実際に$1を実行してみると

Caused by:ActiveRecord::StatementInvalid: SQLite3::SQLException: table "active_storage_blobs" already exists

…こんな感じで怒られます。

それもそのはずで、まったく同じ内容のDDLを実行しようとしているが故に、DB側でテーブルの重複が指摘されているわけですね。
じゃあどうするか？今回は2パターンの解決方法を記載してみようと思います。

その1：bin/rails db
@ブランチB

メリット：お手軽
デメリット：登録してきたデータが全て消える

「テーブルが重複するなら、消せばいいじゃない」という考え方です。

bin/rails db:resetは内部的には以下のコマンドを実行しています。

bin/rails db:reset
- bin/rails db:drop：現在のDBを全て削除する
- bin/rails db:setup
  - bin/rails db:create：データベースの作成
  - bin/rails db:schema:load：$1（schema.rb）からのテーブル作成
  - bin/rails db:seed：初期データの登録

seedファイルにあるデータがあればいい、というのであれば別に問題ありませんが、コツコツ積み上げてきたデータがあった場合それらが消えてしまうので注意が必要です。

その2：bin/rails db
[STEP=戻す数]を実行する@ブランチA

メリット：データが消えない
デメリット：なんですかね。たまにコマンド忘れるとかかな😅あと一手間かかる

「テーブルの追加を無かったことにしよう」という考え方です。

bin/rails db:rollbackは$1ファイルを一つ前のバージョンに戻します。
STEPパラメータを指定することで、指定した数だけ$1することができます。

今回であればbin/rails db:rollback STEP=1を実行した上でブランチBに移動し、DDLを実行すると、正常にDDLが実行されます。

実際にやってみました。

% bin/rails db:rollback STEP=1== 20210108102934 CreateActiveStorageTables: reverting ========================-- drop_table(:active_storage_variant_records)   -> 0.0028s-- drop_table(:active_storage_attachments)   -> 0.0011s-- drop_table(:active_storage_blobs)   -> 0.0009s== 20210108102934 CreateActiveStorageTables: reverted (0.0105s) ===============# テーブルが破棄され、schema.rbに変更が加えられる。

$1ファイル自体は削除されないんですが、DBのschema_migrationから該当の$1ファイルのレコードが削除されることで、pending判定にはかかりません。
schema.rbが変更されているので、git stashして、ブランチBにうつります。

% bin/rails db:migrate== 20201122075737 CreateActiveStorageTables: migrating ========================-- create_table(:active_storage_blobs)   -> 0.0033s-- create_table(:active_storage_attachments)   -> 0.0030s== 20201122075737 CreateActiveStorageTables: migrated (0.0065s) ================= 20201227052520 AddServiceNameToActiveStorageBlobs: migrating ===============-- column_exists?(:active_storage_blobs, :service_name)   -> 0.0016s-- add_column(:active_storage_blobs, :service_name, :string)   -> 0.0011s-- change_column(:active_storage_blobs, :service_name, :string, {:null=>false})   -> 0.0153s== 20201227052520 AddServiceNameToActiveStorageBlobs: migrated (0.0337s) ======== 20201227052521 CreateActiveStorageVariantRecords: migrating ================-- create_table(:active_storage_variant_records)   -> 0.0029s== 20201227052521 CreateActiveStorageVariantRecords: migrated (0.0031s) =======

正常に$1を実行することができました🎉
（見せられないですが、別のテーブルに作成していたデータもそのまま残っています）

おまけ1：bin/rails db:migrate
と bin/rails db

どちらもDBや$1を一度削除するのは同じですが、再作成に用いるファイルが異なります。

bin/rails db:migrate:reset：$1ファイルをすべて再実行し、DBを再作成します。
bin/rails db:reset：schema.rbを実行し、DBを再作成します。

schema.rbに変更が適用されていない$1ファイルがある場合、意図したとおりのDBにならない可能性があります。
そういった点でbin/rails db:resetはbin/rails db:migrate:resetよりも、強力なリセットと言えるでしょう。

今回のケースではブランチBの内容さえ使えればいいので、bin/rails db:resetで十分です。

おまけ2：$1の状況確認のために、覚えておくと良さそうなコマンド

bin/rails db:version：現在の実行済みの$1のバージョンを表示します。

% bin/rails db:versionCurrent version: 20210108102934

bin/rails db:migrate:status：$1の実行状況を、バージョンID、$1名とステータスで一覧表示します。

% bin/rails db:migrate:statusdatabase: db/development.sqlite3 Status   Migration ID    Migration Name   up     20201121230730  Create books   up     20201121231228  Add author to books   up     20201121231845  Add picture to books   up     20201122003800  Devise create users   up     20201122011641  Add name and postal code and address and self introduction to users   up     20201122065204  Add omniauth to users  down    20201122075737  Create active storage tablesactive storage  down    20201227052520  Add service name to active storage blobsactive storage  down    20201227052521  Create active storage variant recordsactive storage   up     20210108102934  ********** NO FILE **********

ステータスは、upが適用済み、downが未適用です。
この実行結果はブランチBで実行しているので、3つの$1が未実行、最新の$1ファイルがブランチAにしかないので********** NO FILE **********となっています。

おまけ3：bin/railsするべきか

この記事では、すべてのコマンドをbin/railsで記載しており、実際に使用しているコマンドもその形式です。

bin/railsを使用する理由は、Springを使用して高速にコマンドを実行するため、なのですが残念ながらbin/rails db...系のコマンドはSpringが起動しないので関係ありません。

コマンドによってSpringが起動したりしなかったりする+つけても実害はないので、忘れないようにすべてbin/railsの形で記載しています。
なので例えばbin/rails db:resetはrails db:resetでも問題ありません。

参考

独習Ruby on Rails
FJORD BOOT CAMPのQ&A

【Todoist→Pixela】Todoistでタスクを完了したら草生やす

ikuma-t — Fri, 08 Jan 2021 12:28:06 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210108/20210108111222.jpg

Todoistのタスクが完了したら草を生やしたい

Pixelaというサービスを知ってから、私の頭の中は「どう草を生やすか」で持ちきりです。

pixe.la

今回は私が日常的に使っているタスク管理アプリ「Todoist」と連携し、タスクが完了したら草を生やすようにしてみました。

なんでも草を生やしたがるお年頃

ikuma-t/todoist-graph | Pixela https://t.co/2eRIHRZq5W #Pixela

— Ikuma_t (@ikumatdkr) 2021年1月8日

Todoistのタスクが完了したら草を生やしたい
Pixela側の設定
Todoist側の設定
- 方法1：IFTTTを使う
  - 1. If ThisにTodoistを設定する
  - 2. Then ThatにWebhookを設定する
- 方法2：TodoistAPIを使う（※Todoistプレミアムユーザ向け）
草はいいよね

Pixela側の設定

一億総草生やし社会の実現のためには、「いつものそれ」ではいけませんね。というわけで、Pixela側の設定も記載します。

手順としては次の通りです。全部ターミナルからcurlコマンドで実行しています。

（ユーザー未登録の場合）ユーザー登録
Todoist用のグラフの作成
Webhook の登録

1. （ユーザー未登録の場合）ユーザ登録

$ curl -X POST https://pixe.la/v1/users -d '{"token":"{PASSWORD}", "username":"ikuma-t", "agreeTermsOfService":"yes", "notMinor":"yes"}'

tokenの後ろの{PASSWORD}には任意のパスワードを、usernameにはグローバルに一意な自分のユーザIDを設定してください。 ※以降も設定した値に置き換えて進めてください。

2. Todoist用のグラフの作成

$ curl -X POST https://pixe.la/v1/users/ikuma-t/graphs -H 'X-USER-TOKEN:{PASSWORD}' -d '{"id":"todoist-graph","name":"todoist-graph","unit":"updates","type":"int","color":"ichou","timezone":"Asia/Tokyo"}'

指定できるパラメータはPOST - /v1/users//graphs - Pixela API Documentを参照してください。 Scrapboxの更新頻度で草を生やす際に芝生色を使ったので、今回はcolorにichouを指定しています。

3. Webhookの登録

$ curl -X POST https://pixe.la/v1/users/ikuma-t/webhooks -H 'X-USER-TOKEN:{PASSWORD}' -d '{"graphID":"todoist-graph","type":"increment"}' | pbcopy

リク$1トすると

{"webhookHash":"xxxxx.....xxxxx","message":"Success.","isSuccess":true}

こんな感じの値が返ってくるのですが、これをコピーするためにpbcopyをくっつけています（手動でコピーしてもいいんですけどね）。実際に使うのは"webhookHash":"xxxxx.....xxxxx"の値だけです。

これでPixelaの設定は完了です！Todoistの設定をしましょう！

Todoist側の設定

Todoistのタスク完了時に草を生やすには2種類の方法があります。

	TodoistAPI	IFTTT
利用可能なTodoistプラン	プレミアム	制限なし
送信可能なタイミング	タスク（追加、更新、完了、完了解除、削除）メモ（追加、更新、削除）プロジェクト（追加、更新、削除、$1、$1解除）ラベル（追加、更新、削除）フィルタ（追加、更新、削除）リマインダー（発火時）	タスク（追加、完了 ※いずれもPJもしくはラベル指定可能）

今回はタスクを完了したら草生やすだけなので、どちらを使っても変わらないです。この記事では両方の方法をご紹介したいと思います。（ちなみにIFTTTを通さない分、少し反映が早い(?)ので私はTodoistAPIを使っています）

方法1：IFTTTを使う

※IFTTTのアカウントを持っている前提で話を進めます。

ifttt.com

こちらから新しいアプリを作成していきます。

流れとしては

If ThisにTodoistを設定する
Then ThatにWebhookを設定する

以上です！

1. If ThisにTodoistを設定する

※初めての場合、IFTTTとTodoistの連携が必要です。今回は省略いたします。

1.If Thisからスタートします。

2.連携するサービスにTodoistを設定します。

3.トリガーを設定します。各トリガーの説明は図の通りです。今回はタスク完了時を想定しているので、「New Completed Task」を設定します

4.Todoistのどのプロジェクトを監視対象にするか設定します。今回は全部のタスクを監視対象としたいので「Any Project」のままにしておきます。

5.Create triggerを押して設定を完了します。

2. Then ThatにWebhookを設定する

1.Then Thatからスタートします。

2.連携するサービスにWebhooksを設定します。

3.道なりに進みます。

4.リク$1トを設定します。

URLには以下の値を設定します。なお{webhookHashの値}は、Pixelaの設定「3. Webhookの登録」で取得したwebhookHashの値に読み替えてください。

https://pixe.la/v1/users/{ユーザID}/webhooks/{webhookHashの値}

Pixelaはリク$1トボディを必要としない（セットしても無視される）ので、画像の通り、Bodyは空欄にしておきましょう。 POST - /v1/users//webhooks/ - Pixela API Document

ここまできたら、Create action > continue > finishと道なりに進んで設定完了です！試しにtodoistでタスクを完了してみると、草が生えますwwww

方法2：TodoistAPIを使う（※Todoistプレミアムユーザ向け）

次にTodoistAPIを利用した設定方法を説明します。

developer.todoist.com

1.Todoist App Management Consoleにアクセス

2.Create a new appを選択

3.Pixelaをアプリとして登録する。 App display nameはなんでもいいです。わかりやすいように今回はPixelaとし、Create Appを選択します。

4.Webhookの設定をする下にスクロールすると「Webhooks」の設定欄があるので、以下のように設定しActivate webhooksを選択します。なお{webhookHashの値}は、Pixelaの設定「3. Webhookの登録」で取得したwebhookHashの値に読み替えてください。

項目	値
Webhooks callback URL	https://pixe.la/v1/users/`{ユーザID}/webhooks/{webhookHashの値}`
Webhooks version	8（デフォルト）
Watched Events	item

5.開発用のアクセス$1ンを発行する「Webhooks」の少し上にcreate test tokenボタンがあるので、押してください。

ここまでできたら設定完了です！試しにtodoistでタスクを完了してみると、草が生えますwwww

草はいいよね

草を生やすと、「は！今日も草生やさなきゃ！」とモチベーション維持に繋がって良いですね〜。

次は「Notionを更新したら草を生やす」に挑戦したいのですが、

Notionからの更新通知受け取り先はSlackしか対応していない
Slackに投稿されたことをトリガーにしようと思っても、Pixelaへのリク$1ト時にchallengeに失敗してしまう

という状況なので、ちょっと難しいかもですね。うまくできたらまたブログにまとめたいと思います！

【Rails】ActiveRecord::core#==はidを比較する（Rails6.1）

ikuma-t — Mon, 04 Jan 2021 21:22:08 GMT

きっかけ
ソースをみる
- Rubyの演算子の優先順位
- コメントを眺めてみる
まとめ

きっかけ

<% if @user.id == current_user.id %>

$1ブートキャンプの課題で、こんなコードを書いていたら

ActiveRecordはデフォルトでid同士を比較するので@user == current_userでOKです。

とレビューいただきました。

「$1〜そうなんや」ではもったいないので、ソースを追っかけてみました。

ソースをみる

# Returns true if +comparison_object+ is the same exact object, or +comparison_object+# is of the same type and +self+ has an ID and it is equal to +comparison_object.id+.## Note that new records are different from any other record by definition, unless the# other record is the receiver itself. Besides, if you fetch existing records with# +select+ and leave the ID out, you're on your own, this predicate will return false.## Note also that destroying a record preserves its ID in the model instance, so deleted# models are still comparable.def ==(comparison_object)  super ||    comparison_object.instance_of?(self.class) &&    !id.nil? &&    comparison_object.id == idendalias :eql? :==

rails/core.rb at c7dfe33f3958295a857d7bfb1070302e5b7429ff · rails/rails

それでは頭の悪さを晒していきましょう。

RubyのRubyの優先順位

$1ばっかりで面食らいました。

&&は||よりも優先順位が高いので、このメソッドは以下のように書き換えることができます。

def ==(comparison_object)  super || (comparison_object.instance_of?(self.class) && !id.nil? && comparison_object.id == id)end

参考：演算子式 (Ruby 3.0.0 リファレンスマニュアル)

Rubyは式全体の真偽を決定するまで、左辺から順に式を評価します。
つまりはsuper（自分とまったく同じオブジェクトなら真）が偽であれば、||以降の内容が評価されることになります。

コメントを眺めてみる

ソースに書いてあることを全部調べた上で、コメントをみてみましょう。

Returns true if +comparison_object+ is the same exact object, or +comparison_object+ is of the same type and +self+ has an ID and it is equal to +comparison_object.id+.
比較対象がまったく同じオブジェクト、もしくはクラスが同じで、IDを持ち、かつIDの値が比較対象同士で同じならtrueを返す

これはソースそのものの通りですね。

Note that new records are different from any other record by definition, unless the other record is the receiver itself.
新しいレコードは、他のレコードがレシーバ自身でない限り、定義上、他のレコードとは異なることに注意してください。

Besides, if you fetch existing records with +select+ and leave the ID out, you’re on your own, this predicate will return false.
また、既存のレコードを+select+で取得する際にIDを対象外とすると、このメソッドはfalseを返します。

いずれもこのメソッドでは!id.nil?が条件となっているので、必ずfalseがかえるということですかね。

1つ目は、newしたばかりのレコードはidがnilだから、
2つ目はselectでカラムを指定する際にidを対象外とすると、idはnilだから、ということでしょうか。

Note also that destroying a record preserves its ID in the model instance, so deleted models are still comparable.
また、レコードの削除はモデル$1のIDを保持するので、削除されたモデルはまだ比較可能であることにも注意してください。

いまいちよくわからなかった箇所。結局idが残ってさえいれば、いつまでもtrueがか返すということでしょうか…🤔

book = Book.find(1)bookA = Book.find(1)book == bookA#=> truebook.deletebook == bookA#=> true

まとめ

ActiveRecord::core#==はid同士を比較する
idがnilの場合は、必ずfalseを返す
idとクラスさえ合っていれば、他の値が違っていてもtrueを返す

「$HOME/git/ignore」と「$GIT_DIR/info/exclude」と「.gitignore」の使い分け

ikuma-t — Sat, 02 Jan 2021 10:48:29 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20210102/20210102104736.png

現在のプロジェクトで「自分だけ」が使用しているファイルをGitの対象外にしたい
結論
Gitの対象外とする際の使い分け
参考：Git - gitignore Documentation

現在のプロジェクトで「自分だけ」が使用しているファイルをGitの対象外にしたい

最近Railsを6.1にあげたのですが、これが原因でrailwaysというRubyMineでルーティングを表示するRailsが使えなくなりました😅

Rails6.1にあげた事でrake routesが使用できなくなり、RubyMineのrailways$1（rake routesが必要）が動かなくなった。https://t.co/OzkrSsW3dw https://t.co/M5WJnv3FfX

— Ikuma_t (@ikumatdkr) 2021年1月2日

railwaysが対応してくれるまでは、一旦Rakeタスクを自分で追加しています（他力本願…自分で直せるようになりたい😓）。

暫定対応として、routes.rakeファイルを作ってrails routesをラップしてる（毎回やるのは面倒😅)

— Ikuma_t (@ikumatdkr) 2021年1月2日

このファイルの使用状況は以下の通りです。

自分しか使っていない（RubyMineでrailwaysを使う人しか必要ない）
railwaysが治れば、このファイル自体が不要。なのでグローバルにはGitの対象外としたくない（あとあとメンテナンスが面倒なので）

この場合どうGitの対象外にすればいいのか迷ったので、調べてみました。

結論

現在のプロジェクトで「自分だけ」が使用しているファイルをGitの対象外にするには、$GIT_DIR/info/excludeに追記する

Gitの対象外とする際の使い分け

Gitの対象外とするには次の3つの方法があります。

.gitignoreに追記：特定の$1を利用するすべての人が対象外とすべきものをここに追記する。
$GIT_DIR/info/excludeに追記：特定の$1で対象外とすべきだけれど、他の人に共有すべきではないものをここに追記する。
$HOME/git/ignoreに追記：自分が利用するすべての$1で対象外とすべきものをここに追記する。

例えば今FJORD BOOT CAMPでRailsアプリケーションの課題を進めていますが、その場合の設定例は次の通りです。

.gitignore

Railsのデフォルトに加え、画像のアップロード先、Railsの設定先を対象外として追記しています。

# See https://help.github.com/articles/ignoring-files for more about ignoring files.## If you find yourself ignoring temporary files generated by your text editor# or operating system, you probably want to add a global ignore instead:#   git config --global core.excludesfile '~/.gitignore_global'# Ignore bundler config./.bundle# Ignore the default SQLite database./db/*.sqlite3/db/*.sqlite3-journal/db/*.sqlite3-*# Ignore all logfiles and tempfiles./log/*/tmp/*!/log/.keep!/tmp/.keep# Ignore pidfiles, but keep the directory./tmp/pids/*!/tmp/pids/!/tmp/pids/.keep# Ignore uploaded files in development./storage/*!/storage/.keep/public/assets.byebug_history# Ignore master key for decrypting credentials and more./config/master.key/public/packs/public/packs-test/node_modules/yarn-error.logyarn-debug.log*.yarn-integrity/public/uploads/*.env

$GIT_DIR/info/exclude

railways用に今回の$1に追加したRakeタスクを対象外とします。

# git ls-files --others --exclude-from=.git/info/exclude# Lines that start with '#' are comments.# For a project mostly in C, the following would be a good set of# exclude patterns (uncomment them if you want to use them):# *.[oa]# *~/lib/tasks/routes.rake

$HOME/git/ignore

Mac上でRubyMineを使用して開発をしているので、全Macで対象外とします。

# General.DS_Store.AppleDouble.LSOverride# Icon must end with two \rIcon# Thumbnails._*# Files that might appear in the root of a volume.DocumentRevisions-V100.fseventsd.Spotlight-V100.TemporaryItems.Trashes.VolumeIcon.icns.com.apple.timemachine.donotpresent# Directories potentially created on remote AFP share.AppleDB.AppleDesktopNetwork Trash FolderTemporary Items.apdisk# RubyMine.idea.ediotorconfig

参考：Git - gitignore Documentation

Which file to place a pattern in depends on how the pattern is meant to be used.

Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file.

Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.

Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.

年始に向けてブログのデザインを整える

ikuma-t — Thu, 31 Dec 2020 16:26:56 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20201231/20201231150902.png

みなさん年末いかがお過ごしでしょうか。私は職場の勉強会の資料を作りたくなくて、現実逃避しています。

さて今日で一年も終わり。来年はたくさんブログを書けるように、CSSのカスタムCSSを利用してブログのデザインを変更してみました。

大した変更ではありませんが、地味にハマったところを自分への備忘録として書き残しておきたいと思います。

カスタムCSSの使い方
変更点（ざっくり）
やっていてつまったところ
- メディアクエリが適用されない
- 1階層目のリストにだけ、CSSを適用するセレクタ
おわりに

カスタムCSSの使い方

カスタムCSSを開くには、まずCSSの右上に表示されている「デザイン」メニューを選択します。

次に、表示されたデザインメニューのサイドバーから「カスタマイズ」を選択します。

カスタマイズタブにある「カスタムCSS」の欄にCSSを書いていくことで、デザインが適用されます。

フォームからフォーカスが外れるとプレビューが更新され、画面上部の「変更を保存する」ボタンを押すことでブログにCSSが反映されます。カスタムCSSの使い方は以上です。

変更点（ざっくり）

デザインについては、無料配布されているsobokuというテーマをベースにしています。

記事全体

囲んで影つけて、各アイテムごとのタイトル文字を太くしました。

#wrapper {    box-shadow: 0 2px 4px rgba(67,133,187,.1);    padding: 20px 30px;    border-radius: 12px;    background-color: #fdfdfd;}/* スマホ用 */@media screen and  (max-width: 559px){#container {    padding: 10px}#wrapper {    padding: 10px 10px;}}.entry-content h2 {    font-weight: 700;}.entry-content h3 {    font-weight: 600;}.entry-title-link {    font-weight: 700;    }

.entry-content .table-of-contents {    background-color: #f7f9f9;    border-radius: 5px;    padding: 16px 20px;    margin: 36px 0;    border: none;}.entry-content .table-of-contents:before {    content: "◆目次";    border-bottom: 1px solid #e6e6e6;    font-weight: 600;    margin-bottom: 16px;    color: #787c7b;}    .entry-content .table-of-contents>li>a {    font-weight: 600;    padding-top: 3px;}.entry-content .table-of-contents * {    color: #787c7b;    text-decoration: none;    list-style: none;    padding: 8px 4px;}

コードブロック

背景を黒にしました

.entry-content pre {    padding: 16px;    border-radius: 3px;    background-color: #2c2d3a;    color: #F7F7F7;}

引用ブロック

背景色をグレーに変更して、文字色も薄くしました。
全体的に余白を大きく取っています

.entry-content blockquote {    border: none;    color: #626e77;    margin: 1.4rem 0;    padding: 25px 36px;    line-height: 36px;    background: #f7f9f9;    border-radius: 3px;}

サイドバーのアイテム

囲んで影つけて、各アイテムごとのタイトル文字を太くしました。

.hatena-module {    padding: 15px 20px 15px;    box-shadow: 0 2px 4px rgba(67,133,187,.1);    border-radius: 12px;    background-color: #fdfdfd;}.hatena-module-title {    font-weight: 700;    }

やっていてつまったところ

メディアクエリが適用されない

記事全体について、修正初期段階では$1で見ると少し幅が狭かったです。

ブログのCSS少しいじった。PCは良さげだけど、CSSだともっと画面いっぱいに広げた方が読みやすそう。
暇な時変えよう pic.twitter.com/GB2l3QTyOa

— Ikuma_t (@ikumatdkr) 2020年12月31日

メディアクエリで$1の場合だけpaddingを広げようとしたのですが、なぜか適用されませんでした。

/* ミスっていた時のCSS * //* スマホ用 */@media screen and  (max-width: 559px){#container {    padding: 10px}#wrapper {    padding: 10px 10px;}}#wrapper {    box-shadow: 0 2px 4px rgba(67,133,187,.1);    padding: 20px 30px;    border-radius: 12px;    background-color: #fdfdfd;}

これはCSSの書き順の問題だったようで、メディアクエリーの箇所を最後に適用するようにしたら、正しく反映されました。This is「カスケードスタイル」…

1階層目のリストにだけ、CSSを適用するCSS

目次部分はすべて順序付きリストで構成されているので、単純にli指定だとすべてのアイテムに装飾が施されてしまいます。

今回は一階層目（つまり記事内の見出し2）だけを太字にしたかったので、直下の子要素を指定する>を利用して、.table-of-contents>li>aとしました。

参考：CSSのセレクタチートシート | webliker

おわりに

ブログのデザイン変更は今年中にやろうと思っていたので、完了できてよかったです😊

来年の執筆まわりの目標としては

ローカルの執筆環境を整える（バージョン管理したい）
月5本は記事を投稿する
読みやすい文章に関する知識を蓄える

こんなところをやっていけたらいいな〜と思っています。

それではみなさま良いお年を〜🐄

Rubocop実行時のparserに関する警告を解消する

ikuma-t — Mon, 28 Dec 2020 21:04:12 GMT

環境

macOS
RubyMine
.3
Ruby
.7.1
Rubocop
.4.2
parser
.7.2.0

Rubocopからの警告

Rubocop実行時にいつの間にか、以下の警告が出るようになっていました。

warning: parser/current is loading parser/ruby27, which recognizeswarning: 2.7.2-compliant syntax, but you are running 2.7.1.warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.

please seeのURLに飛んで、いろいろ調べてみたところ

RubocopはRubyのRubyにwhitequark/parser: A Ruby parser.を使用する
RubyはパッチリリースごとにRubyへのバックポート*1を盛り込むことがある。Rubyを担うparserはこれに対応する必要がある。
上記に対応するため、parserは1つのバージョンで複数のマイナーバージョンをサポートできないそう（parser2.7.2.0では、Ruby2.7.2のみをサポートしていて、2.7.1をサポートしていない）
そのため、Rubyのバージョン（2.7.1）とparserの対応しているバージョン（2.7.2）が異なると警告が出る。

今回事象が発生している環境では特にRubocopのバージョンもしていなかったので、parserも最新版が入っているみたいでした。

# Gemfile.lockparser (2.7.2.0)

参考記事

parserのバージョンを下げる

Rubyに合わせてparserを2.7.2.0未満に下げることでエラーを解消します。

1.Gemfileにparserのバージョンを追記する

# 2.7.2.0未満の最新版をインストールするgem 'parser', '< 2.7.2.0'

2.parserをupdateするGemfile.lockで既にparserの2.7.2.0が指定されているので、updateしていく。

% bundle update parser

3.Rubocopを実行する

% bundle exec rubocopInspecting 20 files....................20 files inspected, no offenses detected

見事エラー解消！

実は（今回は）無視してもいい警告

* Bump 2.7 branch to 2.7.2 by koic · Pull Request #748 · whitequark/parser

Ruby 2.7.2 has been released.https://www.ruby-lang.org/en/news/2020/10/02/ruby-2-7-2-released/
It seems like no changes have been made to ruby27.y where Parser gem should be changed (backported).ruby/ruby@v2_7_1…v2_7_2

特にRuby2.7.1と2.7.2の間に変化はないっぽいので、今回はこの警告を無視してもRubocopの実行結果は変わらなそうでした。

でも、ドキュメント読んだりエラー解消したり、いろいろと勉強になったのでよしとしましょう！

以下、調査過程のメモ

原文

whitequark/parser: A Ruby parser.

Unfortunately, Ruby MRI often changes syntax in patchlevel versions. This has happened, at least, for every release since 1.9; for example, commits c5013452 and 04bb9d6b were backported all the way from HEAD to 1.9. Moreover, there is no simple way to track these changes.This policy makes it all but impossible to make Parser precisely compatible with the Ruby MRI parser. Indeed, at September 2014, it would be necessary to maintain and update ten different parsers together with their lexer quirks in order to be able to emulate any given released Ruby MRI version.As a result, Parser chooses a different path: the parser/rubyXY parsers recognize the syntax of the latest minor version of Ruby MRI X.Y at the time of the gem release.

単語・語句・構文

Ruby MRI：CRuby（Matz’ Ruby Implementation）
backport：あるバージョンのソフトウェアに追加した機能やセキュリティ対策などの改良を、それより以前のバージョンのソフトウェアにも取り込むこと。
c5013452、04bb9d6b：いずれもparse.yにおけるバックポートの例。
lexer quirks：lexerが字句解析。字句解析の特徴といったところ？

内容に関する知識

parse.y
- ruby/parse.y at master · ruby/ruby
- parse.yはRubyのRubyのルールを記述したもの（記述されたPGは、字句解析→Rubyの順に解析される）
- yaccは、パーサを自動生成するツール。 .yという拡張子のファイルを入力とし、 Cのソースを出力する。
- Ruby開発者・まつもとゆきひろ氏の新言語「Streem」のソースコードを読んでみよう！～文法と構造を規定する「lex.l」と「parse.y」 (1/4)：CodeZine（コードジン）
- プログラミング言語を作る/yaccとlex

疑問点と思考過程

中の人が言及している記事があった：Parser gem のバージョニングと RuboCop の TargetRubyVersion - koicの日記
RubyのバージョンアップごとにrubocopのRubyを担うparserもそれに追随するが、各バージョンのparserは複数のパッチバージョン (2.7 系, 2.6 系, 2.5 系, 2.4 系, 2.3 系…) のみ。
Gemfile.lockを確認してみるとparser (2.7.2.0)、つまりは2.7系では2.7.2のみに対応しているので、今回のような警告が発生している。
- * Bump 2.7 branch to 2.7.2 by koic · Pull Request #748 · whitequark/parserで言及されているように、特に影響はなさそう。

訳文（deepLと少し自分）

残念なことに、Ruby MRI はパッチレベルのバージョンで構文を変更することがよくあります。例えば、コミット c5013452 や 04bb9d6b は HEAD から 1.9 までバックポートされています。さらに、これらの変更を追跡する簡単な方法はありません。このポリシーにより、ParserをRubyのMRIパーサーと正確に互換性を持たせることは不可能になっています。実際、2014年9月時点では、リリースされたRuby MRIバージョンをエミュレートするためには、10種類の異なるパーサを、それらのlexerの癖と一緒に維持し、更新する必要があります。その結果、Parserは別の道を選択します: parser/rubyXYパーサーはgemのリリース時に最新のマイナーバージョンのRuby MRI X.Yの構文を認識します。

、それより以前のバージョンのソフトウェアにも取り込むこと。

アウトプットを阻むプライドと戦う〜スモールアウトプットのすすめ〜

ikuma-t — Fri, 18 Dec 2020 06:47:03 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20201217/20201217221725.png

この記事は「フィヨルドブートキャンプ Part 1 Advent Calendar 2020 - Adventar」の18日目の記事です。Part2もあります→フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventar

昨日の記事はharukusさんの「初めてのオンラインLT会の準備と感想 - harukus ぶろぐ」でした!

さて、憧れの$1人生初挑戦ということで、せっかくなので技術系の記事を書く予定でした。

そう、予定でした。

「これが師走ってやつか」

つぶやく側から物凄い勢いで殴りかかる仕事。12月の業務調整に見事に失敗した私には、技術系の記事をしっかり書く時間など残っておりません。というわけで技術系の記事は来年に期待です。

気を取り直して。みなさん、アウトプットはしているでしょうか？「インプットよりアウトプットが大事」なんて分かってはいるつもりでも、なかなかアウトプットって難しいし、時間がかかりますよね。

今回はそんなアウトプットについて、私が感じていることを書きたいと思います。

アウトプットをさまたげるのはプライドだ
- アドベントカレンダー全然かけないの刃無限列車編
- 一時はプライドを克服するも…
「こだわりは手の速さを手に入れてから少しずつ」
スモールアウトプットのすすめ
やっぱり「出ない神本より出る糞本」

アウトプットをさまたげるのはプライドだ

$1全然かけないの刃無限列車編

繰り返しになりますが、アウトプットって難しいですよね。7月から$1ブートキャンプに参加して以来、何度もその難しさに悩まされています。なぜアウトプットに苦しむのか。私の場合「自分のプライドが邪魔をしているから」です。

この記事も書くまでに何回もアウトラインが変わり、いよいよ公開前日の帰りの電車で書いています😭ここ3日間くらい$1の記事を書いては消し、書いては消しとしていますが、その時に頭に浮かんでいることはこんなことです。

アニメ版とpixiv大百科で$1のストーリー全話補完した$1「あぁ〜〜、$1生の記事みんないい話・ためになる話すぎるよぉ。僕そんなん書けないよぉ、たんじろぉ」
「まぁ12月入ってから残業もめちゃくちゃ多かったしぃ、引越しもしてたしぃ、wifiも通ってないしぃ、しょうがないよね、うん仕方ない」

つまり私はこんなことを思ってしまっているんです。

みんなが書いているようなすごい記事を書きたい
内容を評価されたい
しょぼい自分を晒したくない、めちゃくちゃ言い訳したい

なさけない…

一時はプライドを克服するも…

そんな私が初めてプライドと向き合ったのは、iosブートキャンプに入って26日目、2020年8月6日のこと。iosエンジニアの堤さんのこの動画をみました。

www.youtube.com

その日の日報でメンターのkomagataさんとこんなやりとりをしています。

私「自分は「ネタは自分の渾身の知見」と思っていたことがハードルになっていて、全然ブログをかけていないと感じました😅。」

komagataさん「僕も昔からブログ書いてますが、「ネットで見る凄い人のようにレベルの高いことを書きたい。」「レベルの低い話は恥ずかしいので書きたくない。」みたいに思いがちなところを、「現在自分のレベルが低いのは客観的な事実。」「レベルの低い状態は誰しもが通過している。その時期に見栄をはって隠すか隠さないかの違いだけ。」
「現状を素直にアウトプットした方が成長は早まる。」と考えたらどんどん書けるようになりました。」

そして翌日、早速VSCodeVimで使えるインデントオブジェクト - セットプチフォッカを書きます。ここまでは絵に描いたような理想ムーブです。

しかしながらその時の心をすっかり失い、今も私はプライドに汚染されています。プライドってのはなかなか曲げられないからプライドなんですねえ（他人事）

「こだわりは手の速さを手に入れてから少しずつ」

話は変わりますが、私は「SHIROBAKO」というアニメ制作が舞台のアニメが大好きです。アニメは5周 + 音声だけで2周するほど好きです（まだ映画版は見られていない）。

それはさておき、アウトプットの話をするとSHIROBAKOのキャラの1人、ベテランアニメータである杉江さんの言葉がいつもよぎるのでご紹介します。

「速く描くには上手くなる、上手く描くにはいっぱい描く、いっぱい描くには速く描く」
「技術とスピードは、実は全く別の問題でね」
「仕事へのこだわりは、手の速さを手に入れてから少しずつだな」

う〜ん、何度聞いてもいい言葉🧝‍♀️

スモールアウトプットのすすめ

さて

みんなが書いているようなすごい記事を書きたい
内容を評価されたい
しょぼい自分を晒したくない

こんなプライドに惑わされず、

こんな風に数をこなすために、どうしたらいいのでしょうか。

私は「一回のアウトプットの範囲を小さくする」ことをおすすめします（まだ全然成果は出ていないけど、言いきりましょう）。

小さな範囲にすることで

すぐ書ける
たくさん書ける
一つの記事のテーマが小さいので、見返りを求めなくなる

というメリットがあります。具体的には次のようなツール・やり方をしています。

Scrapboxを使ってみる

「$1と$1って似てない？」と思ってから、$1の面影を感じる芸能人を集めているikuma-t-kokoro

$1ブートキャンプの中でも、結構使われている方が多かったので、自分も使ってみたのですが、すぐにかけるのが非常に心地いいです。

記法はあるが、基本WYSIWIGで書ける
下書きと公開の区別がない
メモ同士がタグで結びつくので、あとあと大きなアウトプットにつなげる際にもまとめやすい

個人的には下書きモードがないというのが結構ポイントです。書いたものがそのまま曝け出されるので、ブログだったら「う〜ん仕上がりがいまいちだから、後悔はやめよう」と思っていたところが、自然と「まずは書いて公開しよう」というフローに変わりました。

twitterやtwitterのように「誰がみた」「誰がいいねした」というのがないのも、プライドに惑わされずアウトプットするポイントです。

Stockrを使ってみる

自分の場合は人に見せない記事でも、割とカチッとやらなければと思うタイプみたいなので、結構振り返りにも苦労していました。

振り返りはしっかりやりたい
→振り返るための仕組みをNotionとかでかっちり作る
→毎日書くのが大変。
→大変だから振り返り自体をしなくなる

そこで最近ではStockr | 気づきの習慣化をサポートするアプリを使用しています。

これはtwitterみたいに振り返りをつぶやくと、毎朝7時に過去の振り返りをリマインドしてくれるだけのアプリです（どこにも共有されません）。

こちらもシンプル故に、「振り返りのアウトプットをたくさんして、力に変えていく」という本来の目的を達成しやすくなりました。

日報は最低15分、感想（と書ければやったこと）があればいいことにする

一時期勉強する時間はあったけど、$1ブートキャンプの学習記録=日報がとだえた時期がありました。

真ん中の青くない部分がそう

復帰明けに書いていた日報には、こんなことが書いてあります。

時間がない→5分だけでもやろう（実際にやる）→やったら日報書かなきゃ→（わかったことに書くことがなく）う〜ん、日報に書くほどのことはやっていないな→じゃあ今日は日報書かないでいいか→（…習慣が途切れる音…）今日もやらなくていいか…というのがモチベーション停滞の原因だったのかなと思います。

この「日報に書くほどのことはやっていないな」というところに「日報はある程度のレベルに達しなければ、書いてはいけない」というプライドが感じられます😅

# ✔︎やったこと# ✎学習したこと# ☞次にやること# ♨︎感想・余談

今も昔もテンプレートとしては上記のようなものを使用していますが、当時は「これを全て埋めないと提出できない！」と勝手に$1ラインを作ってしまっていました。

この日報にメンターの方からは以下のコメントが。

個人的には日報にはやったことと感じたことの2点があればOKかなと思ってます。さらにどちらか選べと言われたら「感じたこと」を取りますね。

これ以来、書けなさそうな時はテンプレートを加工して、とりあえず以下の内容がかければいいことにしています。

# ✔︎やったこと# ♨︎感想・余談

…とはいいつつも、$1生の日報ってかなり面白いんですよね。それでついつい「自分も面白いもの・しっかりしたものを書かなければ」と思ってしまうんですが、日報が途絶えて思うことは「やっぱり日報を継続して書いているときは調子がいい」ということ。だからこそ、ちょっとしたことだけでも、まずは書くことが大切なんじゃないかな〜と思います。

日報については、今回の$1で佐野さんが書かれているので、こちらもどうぞ！日報を書こう! (日報自動投稿プログラムもあるヨ!) - 佐野真潮(Mashio Sano)の個人日記

やっぱり「出ない神本より出る糞本」

今回のこの記事も書きながら「こんなレベルでいいんかなあ」と思いながら、書き上げました。正直あんまり役に立たないかもしれないです。

でも公開しなかったら、絶対に誰の役にも立ちません。公開したらもしかしたら誰かの役に立つかもです。もし誰の役に立たなかったとしても、自分が書いたという経験は積み上がります。積み上がった経験で書いた記事はきっと誰かの役に立ちます！

…と、自分に言い聞かせて終わりたいと思います！みなさまもスモールアウトプットで素敵なアウトプット生活をお過ごしください👨‍👨‍👧‍👧

⚡️初めてのLT会 Vol.5でRubyMineの話をしました！

ikuma-t — Sun, 25 Oct 2020 13:03:27 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20201025/20201025125820.jpg

⚡️初めてのLT会 Vol.5に参加しました！
参加の経緯
- 前回のLT会に感化され、参加を決意
- テーマはぼんやりと「RubyMineを布教する」
資料作成
- 発表内容を決める
- スライド作り/Keynoteに挑戦！
  - 配色選び
  - レイアウトを考える
スライド完成！練習
当日リハーサル
本番！たのしかったLT会！
おまけ。RubyMineのはじめの一歩。
参考
- 調査の過程で読んだ記事

⚡️初めてのLT会 Vol.5に参加しました！

昨日FJORD BOOT CAMP（フィヨルドブートキャンプ）で開催された、ライトニング$1初心者のための発表会、「⚡️初めてのLT会 Vol.5」に参加しました！

今回のテーマは「Rubyブートキャンプの歩み方🏃‍♂️」ということで、私は開発ツール「RubyMine」を使うことでRubyの学習が捗るよ〜という話をさせていただきました。

文字通り初めてのLT参加だったので、参加に至る経緯〜発表を終えるまでを振り返ってみようと思います！

参加の経緯

前回のLT会に感化され、参加を決意

初めてのLT会は、今回でVol.5となるFJORD BOOT CAMPの継続コンテンツです。私が初めて参加したのはVol.4だったのですが、皆さんの発表を見て「自分もやってみたい」「こういう機会でやらなきゃ、死ぬとき絶対後悔する」と思い、その日の日報にやってみようかなと書いてみました（2020/8/22のこと）。

この日報に心配ごとへのTipsや後押しのコメントをいただき、参加の決意を硬くしたのでした。後押しいただいたみなさま、ありがとうございます🙏

テーマはぼんやりと「RubyMineを布教する」

こちらも日報でのやりとりからです。

メンターの伊藤さんの「RubyMine布教してみては」というコメントから、「たしかに自分も使いこなせていないし、アウトプットを通じてRubyMineについて詳しくなるのもいいな」と感じ、ぼんやりと次の機会があったらRubyMineについて発表しようと思っていたのでした。

資料作成

発表内容を決める

前述の経緯から、ぼんやりと「RubyMineを布教しよう」ということは決まっていたのですが、具体的なところは未定状態でした。

RubyMineについて調べる

まずは情報収集ということで、RubyMineを知るところから始めました。

ということで、世間一般で言われている「RubyMineどこがいいのよ」という話をかたっぱしから読んでみたり、公式マニュアルをみて試したことを$1（Xmindを使用）にまとめました。

※実際に読んだ記事はこの記事の参考に載せているので、チェックしてみてください！

調べたことにツッコミを入れる

次は調べたことにツッコミ（本当にそれ便利なの？）を入れました。

コードジャンプでGemの中がみられるのは嬉しいけど、FJORD BOOT CAMPのプRubyティスではgemなしでRubyの課題解くよな
rails系の機能って、後半戦にならないと使わないのよね。私もまだrailsやってないし
SearchEverywhereもよく便利と言われるけど、ファイル1つで完結するようなRubyの課題ではそれほどメリット感じないよな（もちろんアクションとかの検索にも使えるけど）
Gitもめちゃくちゃみやすいし使ってるけど、今のプRubyティスの順番だとRubyの方が先なんだよな

…などなど。ツッコミの結果から、競合分析ってほどではないですが、自分が話すことで他の人にメリットをありそうなところを確認。結果として「初心者=PureRubyでFJORD BOOT CAMPのRubyプRubyティスを進める人」への機能に絞って、発表することに決定しました。

あとから振り返ると、ペルソナを仮定して準備を進めると、発表の粒度の指針ができていいなと感じました（今回だと、「IDEってなんのことか説明する」「RuboCopとは何かを説明する」など。

手書きでざっくりと話したいことをまとめる

最初は手書き（ipadのGoodNotes5を利用）で、話したいことをどういう風にスライドを配置するかを考えます。

またスライドを作るとどうしようもないネタ（およそ自己満足）が生まれることがあるので、そういうことを客観視するための機会でもあります。

今回も「RuboCopハードモードってキャッチーでええやん！」と思いつきで書いてみたものの、

全然本質ではない、そんなにキャッチーでもなく面白くもない
話すときに文字数を食う
RuboCopがゴゴゴしてるイラスト作るの大変

などの理由で手書きの段階で却下しました。

この段階で30枚くらいのスライドになりそうだったので、全体のバランスをみながら集約できそうな情報はまとめ、いらない情報は削りました。

よくビジネス本で言われることですが、スライドにいきなり取り掛かるとレイアウトに気がとられてしまうので、まずは手書きがおすすめです（RuboCopのゴゴゴも、もしスライドにいきなり作っていたらサンクコストが原因で変なスライドになっていた可能性があります）。

スライド作り/Keynoteに挑戦！

話すことが決まったら、実際にスライドに落とし込んでいきます。普段の仕事ではWindows、PowerPointユーザなので、今回Keynote初挑戦！

せっかく初めて使う機会なので使い方を覚えるために、テンプレートを使用せずに一から自分で作って見ることにしました。

PowerPointユーザがKeynoteを使ってみた感想はちょっと長そうなので、また別の記事で。今回はデザインの部分だけを簡単に。

配色選び

配色選びにはPalettableというサイトをよく使っています。

このサイトでは表示された色に「Like」「DisLike」を選択していくだけで、自分の好きな色を使ったよさげなカラーパレットが出来上がります。

今回はRubyMineのブランドカラーから、「赤系」と「黒系」をマストでチョイス。加えて配色の裏テーマとして、「錦鯉」を選び、錦鯉にはいってそうな色を「Like」していきました。（鯉の登竜門伝承と「はじめてのLT会は、LTの登竜門」というところでシンパシーを感じたのです😅）

というわけでできたカラーパレットがこちらです。実際には一番右は使っていなかったり、ディスプレイをみて赤の彩度を調整したりしてます。

レイアウトを考える

今回のレイアウトはそんなに複雑ではないですが、一応ポイントはやっぱり「錦鯉」です笑。

錦鯉の丸い模様をスライドのあしらいとして利用しました。なので表紙のスライドはこんな作りになっています。

他にアクセントとして使っているのはふきだしですが、こちらはデザイン研究所というデザインのいろはを教えてくれるアカウントが呟いていた「プロっぽい$1の話」を参考に作りました。

2日で1万人のフォロワーが増えた？話題の吹き出しデザインをプロっぽくするテクニック「プロと初心者のフキダシの違い」 - Togetter

twitter.com

スライド完成！練習

1人web発表会

今回はオンラインでの登壇なので（もちろん初）、見ている側の見え方を探るためにPC2台を用意し、zoomでプレゼンしてみました。

すると当然ですが、オンライン故にスライドをめくるところにタイムラグがあることが判明。

上図のようないわゆるLTっぽい、秒で通過するスライドが非常に使いづらい（話すタイミングとスライド切り替えのタイミングが若干ずれる）ことがわかったので、ほとんど消しました。

keynoteのスライドショー記録機能で録音

keynoteにはスライドショーを記録してくれる機能があります（再生 > スライドショーを記録）。これを使うと、スライドの切り替えと音声を記録してくれます。

自宅でmacで録音→iCloudで自動同期されるので、通勤中にiPadで確認、という感じでセmacビューを実施（iPadでは録音はできませんが、同じように全画面再生が可能）。

話していて練習不足以外で詰まるところは、そもそも論に無理があるので、スライドを適宜修正しました。

お風呂で練習

とはいえ嫁さんも家にいるので、録音を大体的にするのは恥ずかしかったりします。なので、お風呂でプレゼンの練習もしております。

中学で生徒会長をやっているときから、演説の前には毎回お風呂で練習していたのですが、これがなんだかんだ一番きいている気がしますね〜。

当日リハーサル

当日の本番直前に配信テストをやったのですが、その際に表示されるスライドが思いのほか小さいことに気がつきました。

そこそこデカイ字で書いていたつもりですが、見えない可能性を危惧して、本番開始前に少しだけ画像やフォントサイズを大きくしました。

これがSpeakerDeckに上げている版。こっちが当日用に大きくしたスライド。

ここらへんは前回のLT会の動画をみていれば気づけたので、もうちょっと研究しておくべきでした。

本番！たのしかったLT会！

いよいよ本番。緊張しましたが、なんとか喋り切ることができました！（なんだかんだ本番が一番つまらずに喋ることができたという😅）

この発表の後に、何人かRubyMineを試している方がいらっしゃって、「自分の経験したこと、調べたこと」が誰かの役に立つんだ！ととてもうれしく思いました😆

皆さんも「自分のレベルでは話すことなんてないな」と思わず、**「自分の経験を自分の言葉でアウトプットすれば、まず自分の知識が深まる！そしてきっと誰かの役に立つ。」**と思ってぜひLTに登壇してみてください！

おまけ。RubyMineのはじめの一歩。

LT後の懇親会で、「どうやってRubyMineの使い方を覚えました？」と聞かれたので、ざっくりと。

公式ヘルプをみる

RubyMine 入門 - 公式ヘルプ | RubyMine

RubyMineには公式で日本語ヘルプがあります。インストール含めて必要な機能は大体ここにあるので、まずはここを見るのがいいと思います。

日本語化$1を入れる

RubyMineを日本語にするには、日本語化パッケージを別途配置して設定ファイルに記述する方法と$1を使用する方法があるのですが、後者がおすすめです。

どちらも日本語訳の範囲と訳語のレベルはそこまで変わらないのですが、$1の場合は切り替えが楽（設定の書き換えが不要）だというメリットがあります。

機能を知りたい！という意味では日本語の方がわかりやすいのですが、プログラミングで使う用語は英語の方がわかりやすいことが多いです。例えば、「属性アクセサー」より「attribute accessor」の方が個人的にはわかりやすい気がします（人によるのかもですが…）。

こういうときに気軽に言語をスイッチできた方が個人的には便利かな〜と思うので、$1の方がおすすめです！

KeyPromoterXを導入する

RubyMineではどんなことでもShift二回押せば検索できるのですが、より適切なショートカットを覚えて直接起動できた方が、効率的に作業できます。

ショートカットを覚えるのに便利な$1が「KeyPromoterX」です。

この$1は、ショートカットが割り当てされているメニューをクリックで起動すると、そのショートカットと今までショートカットを忘れた回数を表示してくれます。

RubyMine 公式ショートカット一覧 (日本語版) Macと一緒にショートカットを覚えるのがおすすめです！

今日のTipsを確認する

ヘルプメニューの中に今日のTipsということで、RubyMineの便利機能を教えてくれるメニューがあります（非表示にしていなければ起動時に勝手に出現するはず）。

開発の息抜きがてら、「こんな機能あるのね〜」と覚えてみるのもいいかもです。

以上、初めてのLT会参加レポでした〜。

参考

調査の過程で読んだ記事

今月のフォカッチャ〜ドライトマトのフォカッチャ〜【2020/08】

ikuma-t — Sun, 13 Sep 2020 18:58:17 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200913/20200913185635.jpg

今月のフォカッチャは$1のフォカッチャです

同じレシピだとブログネタとして代わり映えしないので、今月は$1のフォカッチャです。

…って言っても、この前のフォカッチャに$1のっけただけですが。（そしてしれっとまた月を跨いでいる）

レシピ

今日は昼も夜もフォカッチャを食べたいというリク$1トにお応えして、いつもの2倍量で作ります

パン生地
- 強力粉：600g
- 塩：10g
- 砂糖：10g
- $1：10g
- オリーブオイル：20g
- 水：400g
トッピング
- $1（オイル漬け）：適量
- バジル・$1：適量
- 岩塩：好きなだけ。適量

環境

室温：26℃
オーブン：SHARP　RE-S70A
ゴムベラ：セリアで買った100円のゴムベラ
ボウル：$1のボウル（もらいもの）

作り方

混ぜる

前回同様、ひたすら混ぜます。今回と前回の相違点は「作る量が倍である」という点です。

倍だからといって、混ぜる時間が倍になるとか、混ぜる労力が倍になるということはありませんが、量が増えたことで気にしなければならない点が出てきます。それは「だま」ができやすくなることです。

$1がかなりだまになりやすく、またオリーブオイルも水を挟まないで直接粉にかけるとそこでだまができます。

というわけで、

粉はあらかじめ全部混ぜておく
オリーブオイルは水を入れた後、水のある場所に注ぐ

といった工夫が必要です。

今回のTipsは手間もほぼ変わらず、半量でも効果があるので「パンを作るときはすべからくそうすべし」と鵜呑みにしてしまってもよいのですが、必ずしもそうではないですよね。

「ある一定の規模なら効果があるけど、少ない量の時は全然効果ないし、ただの手間」というならやるべきではないわけです。

「大規模になることで、小規模では見えなかった問題点が顕在化し、それに対して先人たちは知恵を残し、その恩恵を後に続く人が享受する。お前はただ利益のみを享受するのではなく、その背景をしっかり把握しなさい」と、またパン生地に教えられました。

とか言いながらオリーブオイル直接入れました。教え忘れちゃいました。忘れちゃいましたけど何か？（真顔）

一次発酵

いい感じに混ぜ終わったら、ラップをして1hくらい発酵させます。気温が高いとサクサク発酵してくれるので楽チンですね。

分割・ベンチタイム

今回は倍量なので、生地を2つに分割し、あとで成形しやすいように軽くまるめておきます

（あまり丸めすぎると、生地がしまってしまい成形までに時間がかかるので、軽めにします）。

成形・二次発酵・$1

まるめた生地を麺棒で伸ばし、型にはいる大きさにします。

フォカッチャは$1中の破裂を防ぐために生地にくぼみをぷすぷすと刺すのですが、今回はこのくぼみに$1をつっこんでいきます。

ちなみに今回のトッピングはこの人たちです。$1はカルディで買いました（700~800円くらい）。こいつのせいで原価爆上がりです。

トッピング量ですが、以下のような基準でふりかけています。

$1：フォカッチャに開いた穴の分だけ。穴を開ければ開けるほど、家庭に穴が開く。
バジル・$1：好きなだけ。$1自体が割と$1風味だったので、今回はバジルの方が多め。
岩塩：好きなだけ。目玉焼きに醤油とかソースをかける感覚で、「このパンにちょっと塩降るならこんなもんかな〜」と自分が思う量。

焼いている間も生地は膨らむので、生半可な気持ちで$1をつっこむと、焼き上がりに$1が浮いてしまいます。なので「これはお前のためにやっているんだよ」という気持ちで、容赦無く$1をめり込ませます。

生地を二等分したので、片方は$1、もう片方はさらにチーズをトッピングして$1です（チーズの方は撮り忘れました）。

焼きは250℃に余熱したオーブンで20分前後（家庭用オーブンは癖が強く火力も弱いので、適宜調整してください）です。

うちのオーブンのサイズでは一つしか入らないので、ちゃんと二次発酵すると2枚目が過発酵気味になります。なので、

1枚目の生地を成形する
オーブンの余熱を始める
2枚目の生地を成形する、余熱が終わり次第1枚目をオーブンに入れる
1枚目が焼け次第、2枚目を焼く

という感じで作業をすると、1枚目は微妙に発酵足りない感じ、2枚目はまあまあいい感じで仕上がります。まあでもあんまり厳密にやらなくても美味いから大丈夫です。

完成

うわ〜うまい！うますぎる〜！ただのピザ〜〜〜

感想

もう焼く前からすでに美味いという確信があったのですが、実際にめちゃめちゃおいしかったです。

オイル漬けの$1の場合、惜しみなくそのオイルをパンに塗っておくと、トマトがない部分もトマトの味がしていいなあと思いました。

次回は何フォカッチャにするかな〜。

【RubyMine】デバッグ時、requireで怒られたときの対処法（小ネタ）

ikuma-t — Sat, 15 Aug 2020 15:51:29 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200815/20200815154953.png

RubyMine小ネタです。

Byebugを無視した罰当たり

本日チェリー本でByebugを覚えました。

「覚えたからって関係ねえ、Byebugを使用せずに私はRubyMineで$1をやるんだ」と$1を試みたところ、デバッガが異常終了してしまいました。これは罰当たりか…？

Uncaught exception: cannot load such file -- ./lib/effects    /Users/username/RubymineProjects/ruby-book/lib/word_synth.rb:1:in `require'    /Users/username/RubymineProjects/ruby-book/lib/word_synth.rb:1:in `<top (required)>'

原因は$1の構成

$1から通常通り実行していた際は、以下のrequireで問題なく動いていました。

require './lib/effects'

これを以下のように書き換えてあげるとうまく実行できるようになります。つまりシェルからの実行時と、Rubymineのデバッガでは$1の基準点がずれているわけです。

require './effects'

ではカレント$1リがどこで決まっているかというと、画面右上のプルダウンをクリックすると展開されるので… その中のEdit Configrationsを押すと、各ファイルごとの設定をみることができます。

上図内赤枠の「Working Directory」が$1の基準点になるので、

このパスを書き換える

もしくは

実行ファイルのrequireのパスを書き換える

ことで、$1実行が正しくできるようになりました。

以$1ネタでした〜。

RubyMineのIdeaVimで、jjをEscにマッピングする方法

ikuma-t — Fri, 14 Aug 2020 08:15:03 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200814/20200814073502.png

タイトルの通り設定しました。設定の再読み込みが$1からうまく実行できなかったですが（現在も原因はわからぬまま）、とりあえず設定自体はできたので書きます。

結論以降は試行錯誤の記録なので、設定方法だけわかればいいという方は飛ばしてください。

結論

~/.ideavimrcを開く
imap jj <Esc>を入力して保存
RubyMineを再起動

環境

macOS Catalina 10.15.6
RubyMine
シェル：zsh

~/.ideavimrcにキー$1を追記

デフォルトのキー$1だけで頑張ってきたのですが、Escはどうも手が届かないのでjjに変更しようと思い、下記参考に設定しました。
vim - Intellij Ideavim how to set key map for - Stack Overflow

具体的には

% vim ~/.ideavimrc

もしくは、RubyMineの画面右下にIdeaVimのアイコンがあるので、そこから開いても良しです。

そして、.ideavimrcに

imap jj <Esc>

と記述して、保存。ここまでは何も問題ありませんでした。

$1からの再読み込みがうまくいかない

こういう設定ファイルの常ですが、設定を追記したら再読み込みしないと設定が適用されません。

というわけで再読み込みを実行するわけですが…

% source ~/.vimrc.ideavimrc:1: parse error near `>'

う〜ん、>付近で解析できなかったと言われてもコマンドはこれだしなあ…。いろいろググって、似たような事例で「”」で囲むといいよという例あり。試してみる。

ruby on rails - zsh: parse error near `\’ when Adding AWS keys as environment variables - Stack Overflow

% vim ~/.ideavimrc# シングルクォートで囲むimap jj '<Esc>'

そして実行

% source ~/.ideavimrccommand not found: imap

imapコマンドがないと言われてしまえば、もうお手上げ。残念無念また来年。

RubyMine自体を再起動しました

結局RubyMine自体を再起動すれば、設定ファイルは読み込みされるので再起動しました。

ちなみに、現在起動中のプロジェクトを閉じると、プロジェクト選択ウィンドウが出ますが、こちらも閉じないと再起動にはなりませんのでご注意を。

再起動すると、無事にjjでINSERT MODEから抜けられるようになりました…！？

NORMAL MODEにはなっているのですが、「”」が入ってしまいました。これは先ほどの試行錯誤で

% vim ~/.ideavimrc# シングルクォートで囲むimap jj '<Esc>'

としたせいです。つまり「jjというキーをおしたら、''を入力して、‘Esc’するよ」という$1になってしまいました。なので元の通りの設定に直しておきましょう。

% vim ~/.ideavimrc# シングルクォートを除外するimap jj <Esc>

bashでも試してみる

たまにzsh特有のエラーである可能性もあるので、RubyMineのシェルをbashに変更して試してみます。シェルの変更方法はターミナル - 公式ヘルプ | RubyMineを参照しています。

Prefereceを開き、TerminalメニューにあるShellPathを/bin/bashに変更します。

APPLYを押して、設定を閉じます。ターミナルを一度閉じてもう一度開くと、bashに切り替わるので、zshと同じように試してみます。

$ source ~/.ideavimrcsyntax error near unexpected token `newline'

bashでもzshと同様にエラーが出てしまいました。どうやら大人しくRubyMineを再起動した方が良さそうですね。

感想

結局$1からの再読み込みはできずじまいで、少しもやもやです。そんな頻繁に設定いじらないからいいんですけどね。

フィヨルドブートキャンプに入って1ヶ月が経ちました

ikuma-t — Tue, 11 Aug 2020 11:44:19 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200810/20200810130426.png

$1ブートキャンプに入ってから、1ヶ月が経過しました〜。せっかくなので、この1ヶ月を振り返っていきたいと思います。

1ヶ月でやってきたこと
学習の継続に役立っている仕組み
学習の継続に役立っている考え方
これからの話（ざっくり）
- アウトプットを習慣化する
- 将来を考えていかないといけない
最後に

1ヶ月でやってきたこと

どのくらい勉強しましたか？

学習時間としては、30日で190.3時間。1日平均で大体6hくらい勉強しました。平日は働いているので、ざっくりこんな感じの生活を送っています。

実際にはこれよりも残業していたりもするので、もう少し学習時間が少ない時もあります（コロナの影響で基本リモートワークですが、たまに外勤もしているのでこの通りにいかない日もあります）。休日は6~12hくらい勉強してます。暇人ですね〜。

ちなみに進捗は39%です。

何ができるようになったんですか？

細々書くといろいろあるんですが、プ$1ティスに沿って記述すれば
「LinuxサーバでNginxを動かし、ちゃんとCSSも適用した静的ページをローカルPCから配置・配信できるようになった。あと作ったページはバージョン管理もできるよ。」
といったことができるようになりました。

とりあえず、突然母親に「いま私がやってるサークルのサイト立ち上げてよ」と無茶振りされても役に立つことができるようになりました。え？お問い合わせフォーム？会員専用ページ？ごめんなさいまだ無理です。

$1ベルで進捗を例えると（なぜ例えるし）、

ザケル・ラシルド・ジケルド（HTML・Linux・Nginx…etc）はまだ初級ランクだけで使える。技のコンビネーションでなんとか敵は倒してる。
そろそろバオウ・ザケルガ（Ruby）覚える。
たぶんバオウにのまれる展開（Rubyむずい〜〜〜）がそのうちある

まずはバオウ・ザケルガ覚えて、リオウ戦（Railsとかかな）ですごい感情抱いて、ザケルなどの初級呪文がギガノ級へ進化することを期待する日々です。

独学をやめたことで風向きは変わりましたか？

方向性が見えたことで、先に進めるようになった

Railsブートキャンプのコースは「RailsRailsコース」と銘打っているので、Rubyが初級の状態ではまだまだです。

しかし、自分でサーバーを借りてそこから静的ページを配置することができるようになったことは、独学時代になしえなかった大きな一歩でした。

もう少し詳しくいうと、独学時代には

「どこまでできるようになればいいんだCSS。模写か、模写を続ければいいのか」
「サーバ立ち上げるにも何が必要かわからん。前提知識は何が必要？そもそもこのPCでできるの？」

と思い悩んでずっと同じ場所から進めていなかったのですが、

「CSSはまずHoly-Grail layoutの成果物が作れるようになろう」
「サーバを立ち上げるにはLinuxのこれは最低限必要。んでもってHTTPLinuxも知っておいて…」

と、方向性が見えていることで前に進めるようになりました。

学習時間を純粋に「技術を習得するための時間」に当てられるようになった

こうして方向性が見えることによる変化は、学習時間の使い方の変化にもつながっています。

これまでは「う〜ん、学習の進め方が悪いのかも。他の人のやり方を調べるか。」「計画をしっかりたてやってみよう」と学習の進め方自体に時間をかけていたのですが、キャンプイン後はほぼすべての時間を**「具体的な技術を習得するための時間」にかけることができるように**なりました。

$1ブートキャンプを1ヶ月間つづけていて、辛いことはありますか？

強いてあげるなら

（後述）学習の習慣化のために、最初の1ヶ月は$1ブートキャンプのプ$1ティスを進めることに全振りしていたので、プ$1ティスに関係ない本はいったん読めなかった。
睡眠時間が少し減って眠い。

ぐらいです。

プログラミングが楽しくて始めたことなので、今のところはあまり辛くないです。

わかんないことが出てきても、わかった時の$1が全て精算してくれるので、むしろプラスです。

学習の継続に役立っている仕組み

せっかく1ヶ月続いたので、働きながらの学習に役立っている仕組み・考え方を振り返ってみます。まずは仕組みの方から。

todoist

可処分時間を増やすために、本業のタスク管理で使用しています。

どのタスクをいつまでに終わらせる必要があるのかを一覧で認識できる。
仕事が降ってきた際に、進め方を考えてから着手できるよう無限に子タスクに分解できる。
可処分時間を勉強に回すと、記憶のキャパシティが足りないので、すべて機械が覚えて通知してくれる。
タスク自体にコメント（PDFファイルとかも）を追加可能なので、ここをみとけば全部把握できる
タスク管理ツール自体を使うのに多大な$1がかからない

可処分時間のほとんどを学習時間に当てたことによる、**「実は今まで頭で覚えていた」部分の抜け漏れが怖かったため、**柔軟に繰り返しタスク追加ができるtodoistはかなり重宝しています。

Notion

学習におけるNotionの役割は次の3つです。

$1ブートキャンプの学習計画管理（ゆるめ）
学習メモと参考記事のストック
ビジュアル担当

1.$1ブートキャンプの学習計画管理（ゆるめ）

学習計画

まず学習管理というほどの管理ではないのですが、Notionのカレンダービューを使って、直近1ヶ月のプ$1ティスの取組日程を記載するようにし、完了したらチェックを入れる形にしています。

（1ヶ月以降の日程も一応$1していますが、こっちは適当です。そこにたどり着く時に自分がどんな前提知識あるのかもわからないですし）

$1ブートキャンプは$1カの大学ばりに卒業するのが大変（FAQ | FJORD BOOT CAMP（フィヨルドブートキャンプ））ということで有名なので、毎日学習を進めていても「のれんに腕押し、糠に釘、豆腐にかすがい…」と思ってしまわぬように、「あらかじめここまで進めるんだ」「自分はこれだけ進んだんだ」と自分で納得感を出せるようにしています。

カレンダーのあるページには、各言語の学習メモへのリンクと自分の考えたこと（アウトプット）も一覧できるようにしています。これも「やった感」を自分に訴えかける工夫のひとつです。

2.学習メモと参考記事のストック

次に学習メモと参考記事のストックです。

$1ブートキャンプには日報システムがあるので、そこにつらつら書き連ねるのも一つの手ではあります。ただ横断検索と$1がないことに加え、自分の場合は学習に関する情報をNotionに集約したかったので、Notionで学習メモと参考資料をまとめています。あとは「何でもかんでも日報に書くのはあれだけど、勉強のためにメモしておきたいな〜」という場面が多いということも理由です。

学習内容ごとに一つのページを用意し、学習メモと参考記事を配置するテンプレートを採用しています。

（NotionTip的なところですが、テンプレートで作るとChromeのWebClipperでどれも同じ名前になってしまうので、インラインページにもちゃんとアイコンを設定することをおすすめします）。

Rubyの学習ページ

学習メモは参考書を読む時、課題に取り組む時、調べ物をする時は必ず用意し、

学習時点ではよくわかっていることでもわりとしっかり書く
自分がやってみたことは手順をまとめておく

こんなことに気をつけて書いています。

カリキュラム上は課題を提出すればクリアになるのですが、それは「この技術とはもうお別れだよ」でも「この技術は完璧にマスターしたね」でもありません。

カリキュラム上で先に出てくる技術は、その後の技術の前提知識です。そして人間なので時間と共に忘れる可能性があります。

そのため少し時間はかかりますが、トータルの学習効率を優先して、「忘れた時に自分がスッと分かっている状態に復帰できるメモ」「初心者の自分が、理解したことを後から教えてくれるメモ」となるように書いています。

参考記事は、Chrome拡張のwebclipper機能でどんどん入れていきます。ブックマークバーだといくつあっても足りないので。

3.ビジュアル担当

完全に個人的な好みです。私は仕事でもExcelのフォントや配色が適当だと気になるタイプなので、モチベーション維持のためには学習に使用するツールがビジュアル的にいけていることがマストでした。

Nginxの学習ページ

ちなみに今のところ、一番綺麗だなあと思っているのはNginxの学習ページです。「NGINXってアロマ通販サイトの名前なのか」と錯覚するような$1ル系ビジュアルです。

しょうもないですが、意外とこういうところは学習の継続に効いているんじゃないかと個人的に思っています。

朝勉強できたカレンダー

私の場合、学習の絶対時間を伸ばすためには、朝時間の活用が欠かせません。

そのため6

、学習する習慣としています。この習慣を支えるのが朝学習カレンダーです。

朝学習カレンダー

ルールは簡単で、

習慣を守れたら奥さんにサインをもらう
サインが1ヶ月たまったら、二人でおいしいものを食べる

これだけです。大学時代も「6

→11

→16

」みたいなことはやっていたのですが、仕事の疲れや加齢とともに前ほどすっきり早起きできなくなっているので、朝学習を続ける仕組みは多ければ多いほどいいです（面倒でないほどに）。

朝の$1

毎日6

、sasaboさんという方がslack上で朝の$1を開いてくださっています（本当にありがたい）！

私の朝は6

、slackに返信して始まります。繰り返しますが、朝学習を続ける仕組みは多ければ多いほどいいです。

$1ブートキャンプの日報へのコメント

$1期なので仕組みといえるか微妙ですが、$1ブートキャンプでは学習をした日は必ず日報を書きます。そしてたまにコメントがきます。

「良いやり方ですね」「いい心がけですね」「その調子で頑張ってください！」「参考になりました！」

コメントは基本こないものだと思っているので、不意打ちで来て嬉しさ倍増。

これで明日も頑張れそうな気がします。

$1ブートキャンプの芝

Githubブートキャンプのプロフィールページには、Github同様にキャンプでの勉強時間に応じた芝が実装されています。

「いっぱいあったら、いっぱいうれしい」

そんな単純な人間です。

学習の継続に役立っている考え方

役立っているという観点とは少し違うけれど、単にそういうこと考えているよ〜といった類のことも混じっています。

プログラミングは面白い

だから$1ブートキャンプに入っているんですが、やっぱり**「楽しい」は最大のモチベーション**ですね。朝起きて勉強するのも楽しいから続いているわけで。

習慣化の法則にのっかる

「ずっと読み続けている一冊はありますか？」と言われて、真っ先に答えるのがこの本です。

https://www.amazon.co.jp/gp/product/B01KJAOI9E/ref=dbs_a_def_rwt_bibl_vppi_i5

www.amazon.co.jp

習慣には種類があり、「学習を続ける」といった行動に関する習慣は行動習慣に分類される。
一般的に行動習慣は定着までに30日かかる。
人間は現状維持を好む。多くのことを並行して習慣化しようとすると、拒絶反応が大きいので、習慣化する内容は一つに絞るべき。

本書の内容に沿って「$1ブートキャンプでの学習を継続したい」という習慣だけをこの1ヶ月は徹底しました。仕事は別として、「運動不足だから毎日運動するか」「やっぱ読書習慣身に付けたいな」と思っても、全部やらずに徹底したことで1ヶ月の勉強習慣が定着したと感じています。

新しいことを学ぶ時は「郷に入っては郷に従え」の精神

なまじ仕事でJavaとかAPサーバをかじったことがあるおかげで、プJavaティスで出てくる新しい概念も「ああ、これはJavaでいうあれね」といった比較による吸収が可能です。

これ自体は効率的でいいとは思うのですが、如何せん比較対象の知識自体が曖昧なので、比較による理解はせず、新しく学ぶ概念の言葉で理解するように心がけています。比較で学習しようとすると、比較元の理解度でしか新しい概念を理解できないような気がするので。

「人には人の乳酸菌」の精神

$1ブートキャンプにはいろいろな人がいます。バックグラウンドも違うので、学習進度の比較はあまり意味がありません。「自分がちゃんと進めているか？」を大切にします。

※そのための仕組みがNotionです。

問題を解く時は「シャーペンじゃない、ボールペンで」の精神

学習している過程では間違えるのは当たり前。だったら臆せずにどんどん間違えを晒して残して、成長につなげようといった意味合いです。

ここから余談ですが、これはもともと中学の数学の教師に言われた言葉です。
自分で言うのもなんですが、私は「学校」で常に高い評価を得られていたので、常に「優等生」であろうとしていました。そのことが邪魔をして、ノートに問題を解く時も間違った記録を残さないよう消して、あたかも最初から正しい解答をしているかのように書き直す癖があったんですね。
そして次第にテストの点数が上がらなくなった時に、それを見抜いたのか数学の教師から言われたのが
「問題を解く時はシャーペンじゃなくて、ボールペンで$1にかけ。間違いをたくさん積み重ねろ」
大人になった今でも「失敗を晒すのは恥ずかしい」と思っている自分はどこかにいますが、その度にこの言葉を思い出して「今は間違え時」と言い聞かせています。

これからの話（ざっくり）

アウトプットを習慣化する

先の習慣化の話には続きがあって、

「人間は新しい習慣を拒むけれど、一方で同じ習慣が続くと飽きる生き物。習慣が身についてきたら、新しい習慣を始めることでマンネリを防ぐべき」

という説明があります。これに則って、8月からは学習習慣にプラスしてアウトプットを習慣化したいと思います。1週間に2記事くらいかけるといいなあと思っています。

将来を考えていかないといけない

「楽しさ」を原点として本腰を入れ始めた**プログラミングに対して、「どうして仕事にしたいのか」「どんな仕事をしたいのか」**ということを、これからぼちぼちと考えていきたいと思っています。

仕事であれば、その時間含め長い時間プログラミングに触っていられる。
個人とは規模感が違う。その規模感ならではの$1を体験することができる。
仕事には責任が伴う。責任があるからこその試行錯誤がありそれが楽しい。…etc

最後に

最近「自分はいい時代に生まれたよなあ」と思っています（Windows95と同い年です）。

もしプログラミングという概念が生まれたばかりの時代だったら
もしJavaScriptが使えないものだと思われている時代だったら
もし個人でさくっとWebアプリが作れる時代でなかったら

今ある技術はなくて、そしてその技術を懇切丁寧に教えてくれる環境もきっとなかったんですよね（もちろん、その中で学んでいくことも楽しいんだとは思いますが、今よりずっと大変）。

せっかく$1ブートキャンプという場所を選べる時代に生まれて、その機会を自分で選択したのだから、最後までやり通さないと損ですよね！

1ヶ月くらいで「やりきった」テイストの記事書いてますが、まだまだこれから！！プログラミング楽しんでまいります！

↓こちらもどうぞ

ikmbear.hatenablog.com

zshからの実行時、 Rangeオブジェクトを使った繰り返しで、最後の文字が「%」になって困った

ikuma-t — Mon, 10 Aug 2020 16:01:01 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200810/20200810155847.png

実行環境
なぜ範囲の最後の数字が出力されない？
Rangeオブジェクトは、ドットの数で境界を含むかどうかが変わる。
環境起因かを確かめてみる
zshでは改行のない結果行を出力する時に、プロンプト「%」を表示する
- 余談
「%」を排除するにはどうすればよいか
感想
参考

実行環境

macOS Catalina 10.15.6
Ruby 2.7.0
シェル：zsh

なぜ範囲の最後の数字が出力されない？

実際に取り組んでいた問題はもう少し複雑だったんですが、簡単にいうとこんなコードを書いていました。やりたいことは、1から10までをただ横並びに出力したいということです。

# print_num.rb#!/usr/bin/env ruby(1...10).each {|n| print n}

これをVSCodeのターミナル（zsh）から実行すると…

% ./print_num.rb123456789%

「あれ？10が出ない代わりに”%“が出力されている？」

Rangeオブジェクトは、ドットの数で境界を含むかどうかが変わる。

class Range (Ruby 2.7.0 リファレンスマニュアル)

さしずめ、「あれドットの数って何個だったけな？国語的には3つで1つだから、3つで書いてみるか…。お！動いたやっぱり3つか！」みたいことを思っていたのでしょう、この私。甘すぎて尼になっちゃうわ。

「Rangeオブジェクト」のリファレンスマニュアルを確認すると、次のようなサンプルがあります。

Range.new(1, 5) # 1 以上 5 以下1..5            # 同上1...5           # 1 以上 5 未満

つまり、Rangeオブジェクトは

ドットが2つの場合、終端を含む
ドットが3の場合、終端を含まない

という仕様です。なので、今回やりたいことは次のように書けば解決します！

# print_num.rb#!/usr/bin/env ruby(1..10).each {|n| print n} # ドットを一つ減らし、終端を含むように変更した。

これを実行すると…

% ./print_num.rb12345678910%

あれれ？10は表示されましたが、「%」の謎は残ったままです…。

環境起因かを確かめてみる

この実行結果はVSCodeのターミナル（zsh）で実行したものなので、環境起因の可能性がないかチェックします。

mac標準のターミナル（zsh）で実行して結果を確認してみると、同じ現象が発生しています。

一方、pryでの実行結果を確認すると、こちらは%は表示されていません。

つまり、「%が表示されるのはzsh特有の現象」であると言えそうです。

zshでは改行のない結果行を出力する時に、プロンプト「%」を表示する

zsh特有だというヒントが得られたので、ドキュメントをチェックしてみます。

zsh: 16 Options

PROMPT_SP Attempt to preserve a partial line (i.e. a line that did not end with a newline) that would otherwise be covered up by the command prompt due to the PROMPT_CR option. This works by outputting some cursor-control characters, including a series of spaces, that should make the terminal wrap to the next line when a partial line is present (note that this is only successful if your terminal has automatic margins, which is typical).When a partial line is preserved, by default you will see an inverse+bold character at the end of the partial line: a ‘%’ for a normal user or a ‘#’ for root. If set, the shell parameter PROMPT_EOL_MARK can be used to customize how the end of partial lines are shown.NOTE: if the PROMPT_CR option is not set, enabling this option will have no effect. This option is on by default.

順に読んでいきましょう。

Attempt to preserve a partial line (i.e. a line that did not end with a newline) that would otherwise be covered up by the command prompt due to the PROMPT_CR option.

「PROMPT_CR オプションにより$1で覆われてしまうような部分行 (改行で終わらない行) を保存しようとする」

PROMPT_CRオプションについてはその上に記述があり、プロンプト（zshでは%）を表示する前にキャリッジリターン（CR）を印刷する（同一行の行頭に戻す）仕様のようです。

This works by outputting some cursor-control characters, including a series of spaces, that should make the terminal wrap to the next line when a partial line is present

「カーソル文字（一連のスペースを含む）を出力することで、部分行を次の行に折り返す」

When a partial line is preserved, by default you will see an inverse+bold character at the end of the partial line: a ‘%’ for a normal user or a ‘#’ for root.

「これが実行される時は、デフォルトでは反転して太文字で部分行の最後に一般ユーザなら「%」が、ルートユーザなら「#」が表示される」

字面だけだといまいちよくわからないので、具体的なソースと合わせて、動きを書いてみたいと思います。

まずrubyプログラムを実行します。printメソッドは改行を出力しません。

% ./print_num.rb123456789

ここでPROMPT_CRオプションに基づいて、CRを印刷します。すると改行がされていないため、同一行の先頭に移動した結果、出力結果が消えます。これが「PROMPT_CR オプションにより$1で覆われてしまうような部分行」ということです。

% ./print_num.rbusername@userMacbook folder%

で、こういうことが起こらないように、PROMPT_SPオプションがPROMPT_CRオプションに先んじて仕事をします。具体的には、一般ユーザであれば改行を含まない行の最後に（色が）反転した「%」を表示して改行します。

% ./print_num.rb123456789%

最後にPROMPT_CRオプションのCRが印刷されたのち、プロンプトが表示され、結果はこうなります。

% ./print_num.rb123456789%username@userMacbook folder%

余談

PROMPT_SPオプションを無効にすることで、「PROMPT_CR オプションにより$1で覆われてしまうような部分行」を実際に確認することができます。

% vi ~/.zshrc# .zshrcを編集unsetopt PROMPT_SP% source ~/.zshrc

実行結果

部分行がCRにより覆われてしまい、見えなくなっていることがわかります。

「%」を排除するにはどうすればよいか

一つの手段はRuby側で改行を出力することです。最初のプログラムで

# print_num.rb#!/usr/bin/env ruby(1...10).each {|n| print n}puts "\n"

としておけば、出力結果が部分行に相当しないので、%は表示されません。

別の手段は、zshの設定（~/.zshrc）を書き換えてしまうことです。

If set, the shell parameter PROMPT_EOL_MARK can be used to customize how the end of partial lines are shown.

ここに記載の通り、PROMPT_EOL_MARKが、部分行の最後に出力される文字です。

これを「”（空白）」にしてしまえば、%は表示されず、部分行も保持されます。

% vi ~/.zshrc# .zshrcを編集export PROMPT_EOL_MARK=''% source ~/.zshrc% ./print_num.rb123456789

感想

プログラム側で制御でき、環境に依存しないという点ではRubyで改行を出力してしまうのがいいのかなあと思いました。
あと誰かが英訳力をプレゼントしてくれないかなと思う今日この頃です。
ついでに記事のタイトルつける力もください、なんでもしますから。

参考

VSCodeVimで使えるインデントオブジェクト

ikuma-t — Fri, 07 Aug 2020 12:35:31 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200807/20200807101559.gif

Vimではiiコマンドで全選択できる？
iは「インデントオブジェクト」（VScodeVim）
実践！インデントオブジェクト
まとめ
感想
参考

Vimでは`ii`コマンドで全選択できる？

Google検索で「vim 全選択」と検索すれば、こんな感じのコマンドが出てきます。

gg
Shift + v（行選択ビジュアルモードにしないと、最後の一行がうまく選択されないので注意）
G

この方法が正攻法なのですが、へっぽこvimmerである私はキーボーvimmerチャコンの末に別の方法で全選択する方法を見つけました（注意：結論としてはこれは全選択のコマンドではありません）！

ビジュアルモードにした後、コマンドiiを入力すると、上図のような結果（全選択）になります。

「テキストオブジェクト「ii」を入力すると全選択できる？」
「いやちょっと待てよ、テキストオブジェクトで「i」なんて聞いたことないぞ」
そこで今回はiiすなわち「inner i?」の「i」とはなんぞやを調べてみました。

`i`は「インデントオブジェクト」（VScodeVim）

まず同じテキストファイルに対して、シェル上で同じコマンドを入力しても全選択にはなりません（無効なキーを押した時のあの音がなります）。

ということは、この機能はVSCodeのVSCode「VSCodeVim」特有の機能ということになります。

そこでvimのページを確認してみると、「vim-indent-object」なるものが。

Based on vim-indent-object, it allows for treating blocks of code at the current indentation level as text objects. Useful in languages that don’t use braces around statements(e.g Python)

要はカーソルの現在位置と同じインデントを、テキストオブジェクトとして扱うことができるということです（以降インデントオブジェクトと呼ぶ）。

（私はPython触ったことないので初めて知りましたが）Pythonのようにインデントでブロックを構成する言語には、このインデントオブジェクトはめちゃ便利ということらしいです。

a = 3if a == 5:    print "AAA"    # if文の対象    print "BBB"    # if文の対象print "CCC"        # if文の対象ではない

引用：とほほのPython入門 - 構文 - とほほのWWW入門

実践！インデントオブジェクト

VSCodeVimの概要ページにはコマンドの説明もあるので、実際に試してみます（ビジュアルモードで試すので、オペレーターは指定しません）。

`<operator> ii` ：カーソルの位置と同じインデントを指定

冒頭でのべた「iiで全選択」は**「一番外側のインデントにカーソルをおいて、インデントオブジェクトiiを指定すれば、実質全選択」**ということでした。

（サンプルのアニメで上下移動も怪しいへっぽこvimmerだということがばれましたね…）

`<operator> ai` ：カーソルの位置と同じインデント+そのインデントの一行上を指定

`<operator> aI` ：カーソルの位置と同じインデント+そのインデントの一行上と下を指定

テキストで再確認

テキストで各コマンドの範囲を確認すると、以下のようになります。

<div>  <p>vimvimvimvimvimvimvimvimvimvimvimvimvim</p>    <div>　<!--aiと、aIの上方向はここまで-->      <p>vimvimvimvimvimvimvimvimvimvimvimvimvim</p> <!--iiだとここまで-->      <p>vimvimvimvimvimvimvimvimvimvimvimvimvim</p>      <p>vimvimvimvimvimvimvimvimvimvimvimvimvim</p>      <p>vimvimvimvimvimvimvimvimvimvimvimvimvim</p> <!--ここでコマンドを実行-->    </div> <!--aIの下方向はここまで--></div>

まとめ

VSCodeVimでは、標準で「インデントオブジェクト」がサポートされている。
「インデントオブジェクト」：現在のカーソル位置のインデントを基準として、同じインデントの範囲を指定する。
一番外側のインデントにカーソルをおいてインデントオブジェクトを指定すると、実質全選択をすることができる。

感想

vimの世界だけでも広かったのに、VscodeVimの世界も広がってしまいました（vimの説明をみた限りでは、なんか他にもいろいろ独自のvimがありそうな感じでした）。
困ったら都度都度覚えるしかないですね〜😭

参考

今月のフォカッチャ

ikuma-t — Thu, 06 Aug 2020 00:05:14 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200728/20200728164816.png

今月のと言いながら焼いたのは先月（2020/7）

パンとの思い出
フォカッチャ作り
- 今回作るもの
レシピ
作り方（簡易版）
感想

パンとの思い出

エンジニアとしてのアウトプットブログなのに、3記事目からパンの話だと「こいつエンジニアの卵の化けの皮を被ったパン屋だな」と思われそうです。

一応、高校上がりたての頃は本気でパン屋になろうと思っており、大学入学と同時にチェーンのベーカリーへ。
1年間働いた後、「一からパン作りがしたい」という思いから、$1の個人経営ベーカリーに転職（※バイトです）し、大学卒業まで製造〜売り子までやっていました。

1店舗目は出来合いのパン生地を発酵させるだけで、なんか腑に落ちなかったんですよね。
自分で仕組みを理解して作り上げるという工程を踏まないと気が済まないみたいです。

そんなこんなで現在も趣味でイタリアの食事パン「フォカッチャ」を焼いているので、月に一度のご紹介です。

フォカッチャ作り

今回作るもの

まず今回作るのはこちらのフォカッチャです。大量のバジルと岩塩で味をブーストさせたベストオブ食事パンです。

レシピ

強力粉：300g
塩：5g
砂糖：5g
$1：5g
オリーブオイル：10g
水：200g

作り方（簡易版）

混ぜる

まずはひたすら混ぜます。

2件目のパン屋で働く前は、「手でこねるのこそ至高。パン職人はこうあるべき」とか思ってたんですが、今はゴムベラしか使わないです（成形段階になったら手でやりますが）。混ぜるときは手につかない方が効率がいいし、生地の量も減らなくて済むので。

しかもパン屋は機械使ってますからね。フランスのパン屋は「いかに楽をするか」ということを常に考えていて、それゆえ作業の機械化が進んだとかなんとか。まるでエンジニア。

こうしてパン生地を捏ねていると、自分の思い込みの極論ではなくて、ちゃんと現実と向き合って、目的に見合ったやり方を採択することが大事なんだと思い知らされます。

Excelを使うことが悪なんじゃない。システム化の中でExcelの方が費用対効果がいいときだってあるし、Excelにしかないメリットがあるんだとか。何でもかんでもExcelでやろうとするからいけないんだみたいな。

一次発酵

写真くらいまとまってきたらラップして一次発酵です。時間は適当。大体勉強しながら作るので、いつのまにかいい大きさになっています（冬場だと気温が低いので発酵しにくいですが）。

この工程も昔は生地にハリツヤが出て、$1チェック合格できるくらいまで捏ねていました（画像くらいだと15~20分くらい捏ねたところです）。市販のパン作りの教科書に書いてあるので、それが正しいと思ってずーっと捏ねていました。

でもこれくらいの捏ね具合でも、発酵を重ねるときれいになって、美味しいパンになるんですよ。

「基本に忠実に、完璧になるまでそこをやるっていうのもいいが、大体把握できたらまずはその先へ行ってみて、各工程・レベルのエッセンスを掴むことこそが大事ではないか」、とパンに言われているような気がしました。

二次発酵〜$1

一次発酵後です。あとはガスを抜いてもう一回発酵し、型に入れます（以降の工程の写真は撮り忘れました）。

焼きに入れる前に、塩とバジルとオリーブオイルを振りかけます。
塩はうまいものがいいです。これは実家の母が知り合いからもらったいい塩です。めちゃうまいです（馬鹿みたいな文章だなあ）。

感想

原価100~150円くらいでできるので、めちゃくちゃお得〜
エンジニア全然関係ないですけど、同じ内容を定点観測していくとアウトプットの質も上がる気がするので、これからもフォカッチャ作りお届けしたいと思います！

突然ssh接続でDebianに繋がらなくなったときの対処法

ikuma-t — Wed, 05 Aug 2020 23:43:05 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200805/20200805215246.png

記憶喪失のDebian？

3日前くらいに、さくらVPS上のDebianに対して公開鍵の設定しました。
設定当初から問題なく公開鍵認証で接続できていたのですが、今日ssh接続を試みると、突然Permission denied (public key)と言われてしまいました。

何も設定を変えていなかったので、どうしたもんかと。アニメ「一週間フレンズ」しかり、Debianは数日立つと私のことを忘れてしまうのでしょうか。

「Debian！俺だよ！思い出してくれよ！」
そう叫んだところで相手はシステム。思いは届きません。一つずつ確認しましょう。

記憶喪失のDebian？
前提
思い出せDebian編
Debianは覚えていた編
感想
参考

前提

sshクライアント：macOS Catalina（10.15.6）
接続先：さくらVPSに構築したDebian10.4
以前は公開鍵認証で問題なく接続できていたが、突然Permission denied (public key)により接続できなくなった。
公開鍵認証については、ssh接続を鍵認証で行うを参考に実施済み。つまり
- client_rsaというキーペアを作成
- クライアントのキーチェーンには$1を登録済（ssh-add -K ~/.ssh/client_rsa）
- Debian側にも公開鍵を登録済
- Debian側のsshd_configは以下の設定がしてある

PasswordAuthentication  noChallengeResponseAuthentication  noUsePAM  yes

思い出せDebian編

覚えてるか？俺たち、昔はパスワードでssh接続したりしてさ…

確認したいこと：原因が公開鍵認証によるものなのかの切り分け
確認方法：Debian側のsshd_configでPasswordAuthentication yesに設定変更する。
確認結果：パスワード認証では問題なくssh接続できる。

Debian「今もパスワード認証できるで」

覚えてるか？この鍵。半分、お前に渡してさ…

確認したいこと：公開鍵がちゃんとサーバ側に格納されているかどうかを確認
確認方法：macで作成した公開鍵を確認し、debian側のフォルダに配置されているものと比較する。
- 具体的には以下の流れでクライアント、サーバでのcat結果を比較。

# クライアント（mac）にキーペアが作成されていることを確認$ ls ~/.ssh$ cat ~/.ssh/client_rsa.pub# サーバ（debian）に公開鍵が配置されていることを確認$ ls ~/.ssh$ cat ~/.ssh/authorized_keys

確認結果：作成した公開鍵がサーバ側に正しく格納されている。

Debian「今もちゃんと持ってるで、覚えとるで」

なあDebian、閉ざした心を開いてくれよ…

確認したいこと：エラーメッセージにあるPermission Deniedが本当に$1が原因か確認する。
確認方法：クライアント、サーバ側それぞれの.sshsshリのsshを確認する。
- クライアントは700（rwx）
- サーバ側は600（rw）
確認結果：どちらも期待通り。

Debian「心オープンやで〜」

Debian、お前もしかして…

Debian「さっきから好き勝手疑ってくれてますけど」
Debian「全然こっちは問題ないですから。」
Debian「もうひとつ言っておくと、使用する鍵をちゃんと指定すればssh接続できますから！こんな感じで。」

$ ssh -i ~/.ssh/client_rsa -p 3090 YYYYYYYYYYYY@XXX.XX.XX.XXX

Debianは覚えていた編

忘れたのはクライアント（mac）のキーチェーン

実は問題があるのはDebianではなく、キーチェーンの方でした。
macOS 10.12 Sierra以降、キーチェーンが再起動時に読み込まれなくなる仕様となったそうです。

タイトルに「突然」とありますが、実際には「macの再起動」をトリガーとして本事象が発生します。（事象発生まではmacbookをスリープするだけで、再起動していなかったんでしょうね…）

キーチェーンにDebianとの友情を邪魔させない。

再度ssh-add -K ~/.ssh/client_rsaを実行することで、一時的には繋がるようになりますが、再起動すると、またssh接続できなくなってしまいます。
そのため、恒久対応として~/.ssh/configに以下の設定を追加します。

Host *  UseKeychain yes  AddKeysToAgent yes

もっとDebianと仲良くなる

せっかくconfigの設定をしたので、毎回ポートやipを打たずに済むような設定もしておきます。

Host ikuma-t  HostName XXX.XXX.XX.XX  User ikuma-t  IdentityFile ~/.ssh/client_rsa  Port 3090  TCPKeepAlive yes  IdentitiesOnly yes

これで再起動してもssh ikuma-tで繋がるようになりました！

感想

コマンドだけでリモートとやり取りするような部分って、「これ何やってんだ？」「どれチェックしたか忘れた…もう一回しらみ潰しにやり直してみよう」ってことが多いと思います。

今回はDebianが記憶喪失したというストーリーで擬人化して考えましたが、とっつきにくい内容だからこそ、自分で噛み砕いてコミカルにしてみるのはなかなか効果的でした！

Debian「途中で設定とかストーリー書くの面倒になったでしょ」
私「ファッ！！！」

参考

フィヨルドブートキャンプにキャンプインしました

ikuma-t — Wed, 22 Jul 2020 19:45:45 GMT

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20200722/20200722142831.png

はじめに
プログラミングスクールに入るまでの経緯
入ってみてよかったこと（キャンプのいいところ）
- 「どれから勉強を進めていくか」に終止符をうつことができた
- 自走のための環境が整っている
入ってみてよかったこと（副産物編）
最後に

はじめに

この度フィヨルドブートキャンプというプログラミングスクールに参加しました。本業（SIer）との両立で大変なところもありますが、エンジニアとしてのスキルを伸ばすべく頑張ります！

プログラミングスクールに入るまでの経緯

プログラミングとの出会い（2017/12〜2019/12）

先の通り、私の本業はSIerで現在入社3年目（新卒から入った会社です）。内容は業務コンサルよりな仕事です。

SIerに入社こそしていますが、大学の学部は文系だったため、プログラミングに本格的に出会ったのは就職活動の時でした。ネットワーク系のSIerでの計3日ほどのSIerで、完全にこのITの世界にハマりSIerに就職。

ただこの時は特にプログラミングをやっておらず、一方で技術を理解して伝えるという点に強みを感じていたため、「〇〇 × IT」、つまり「自分は〇〇を解決するために、ITという手段をうまく使う人」という考えで、コンサルよりのSIerを選びました。

入社してから1~2年目は、研修含めてJavaを習得。業務知識も順調に習得し、現場ではコンサルしながら、Javaしてバグを直しと個人的にめちゃくちゃ充実した日々を送っていました。
このとき「ああ、私はSIerのSIer*1になるんだな」と確信しました。

プログラミングとの別れ（2020/1〜）

一つ目のPJを有終の美で終えたのち、次のPJに入ったところで突然プログラミングとの別れがきました（あくまで最初のプログラミングはお試し期間だったようです）。
でも大丈夫、私にはSQLがついているじゃないか。batじいさんだっているんだ、ちょっとしたツールを作る喜びはある!
$1だって怪我しても、ホームラン打ってますし。

しかしCASE文と$1での一人遊びはそう長く続きません。

Qiitaに、メルカリ、$1、どんどん増えていく若手エントリー。
増える手取り、感じる焦り、一人始めるProgate。

独学時代（2020/2〜6）

最初の一年をかなり飛ばしていたおかげで、燃えつき症候群&時間を持て余していたので、Progateに粛々と挑戦。

Progate

1ヶ月ほどでいわゆるWeb系っぽいおおよそのコースはクリア。

その後udemyでいくつかのコースをやり、

Qiitaのハンズオン系記事に飛びつく期間が続きますが、

基礎が終わったような気がするし、実戦で経験値を積みたい。でも実際には基礎ができていない、のかもわからないが、まずは前提知識を増やさないといけない。
やろうと思っても、基礎はどこまで？どこからやればいい？となり進めない。
その通りにやれば最後まで辿り着ける講座は、応用になるとうまくできない。

と壁にぶつかるのでした。

もちろんJavaをやっていたわけですから、RubyとかRailsをやってみても、各メソッドがどう関連して作用していくのかは理解できました。
ただ、Javaをやっているときは「すでに出来上がっているアプリに、改修を加えていく」という作業だったため、フロントエンドやインフラの細かい点を意識せず、サーバサイドの具体的なロジックをどうするかだけ考えればよかったんですよね。
一から作る場合は、インフラ含めたそのロジックが作用する土台や、見た目を作っていく必要があるので、そこの前提知識が全然足りなかったのかなと思っています。

キャンプイン（2020/7〜）

「このままではずっと同じところから抜け出せないなあ、でもどうやって勉強進めたらいいかわからないなあ」
そんな現状を打破すべく、$1ブートキャンプにキャンプイン。

選定理由は雰囲気です。
やっぱり学習をしていく上で、このコミュニティでやっていくのはしんどいな、と思うことがあっては続かないと思うんですよ。じゃあどうやってそれを判断するかといったら、私の場合は雰囲気、フィーリングなんです。これが$1ブートキャンプのホームページですけど、この画像をみて「怪しいな」「弱そう」「かわいい」「優しそう」といろんな感じ方ができるかと思います。
私はこれをみて「なんか優しい雰囲気そうだな、やっていけそうだな」と思ったのでこれにしました。

みすず理論ってやつですね（私が勝手に呼んでるだけですが）。

あのCMを見て、「何となく面白そうだな」と感じる、シャレの分かる、明るくて素直な子に来てほしいのです。みすず学園

もちろん価格とか、カリキュラムといった最低限の情報はみましたけどね。

入ってみてよかったこと（キャンプのいいところ）

「どれから勉強を進めていくか」に終止符をうつことができた

ここが今のところ、一番大きいです。
自分の場合は、「プログラミングはできるようになりたい。自分で勉強もできる。けれど、学ぶべき技術が幅広すぎて、どこから手をつけていいかわからない」という悩みがありましたが、カリキュラムがあるキャンプに入ることはこの悩みを直接的に解決してくれました。

成長$1という本に、「進むべき道でブレーキを踏んでしまうことは、成長を阻害する要因の一つ」という一節があります。

https://www.amazon.co.jp/%E6%88%90%E9%95%B7%E3%83%9E%E3%82%A4%E3%83%B3%E3%83%89%E3%82%BB%E3%83%83%E3%83%88-%E5%90%89%E7%94%B0-%E8%A1%8C%E5%AE%8F-ebook/dp/B07CBTDJ5F

www.amazon.co.jp

「基礎はやらなきゃいけないけど、本当にこれから初めていいのかな。どこまでやればいいのかな」と思い続けながら自走しようとしていた時期は、完全にブレーキを踏みながらアクセルを踏んでいる時期でした。
「カリキュラムがある」という点は別のスクールでも同じだと思っているので、これは「勉強方針に迷っている社会人がプログラミングスクールに入ってよかったこと」ですね。

自走のための環境が整っている

$1ブートキャンプでは、演習に対して提出物があるものの、そこに至るステップを明確に規定しません。代わりに参考書籍・サイト、ドキュメントなどが課題ページに書いてあるので、自分で必要なものを選んで学習し、課題に挑みます。

もちろんそれだけでは足りないこともあるので、キャンプ内の生徒・メンター全員がみられるQ&Aや他の人の日報を参考にしながら進めます。

ここがいい点だと思う理由は次の3点です。

プログラミングの楽しさである、自分で考えて解決する余地を残している
課題を解決するための探索力向上を促す一方、いざ聞くべき環境はシステムとして用意している
同じ課題をやる生徒を見つけることで、モチベーション意地に繋がる

物事に絶対はないので、カリキュラムを充実させることにももちろんメリットがあります。

スクール側は運営が楽になり、スケールさせやすい。すると、生徒の環境に資金投下もしやすい（$1ブートキャンプの場合は、メンターさんの頑張りで支えられている感じがします。そして生徒さんの間でも支え合いの概念が浸透しているように思います）。
生徒としても、カリキュラムをやることで一定のレベルが保証される（自分で考える余地があるということは、やらなかったら当然力にならない）

ここは考え方次第です。私の場合は自分で自走したいけれど、先の通り、どう進めればいいかわからないという悩みを解決したかったので、キャンプのシステムがあっているかなと。
小$1から大手塾が苦手で、受験の時だけ基本放置なこじんまりした塾に通っていて結果が出ていたので、そういう人間なのかも。

入ってみてよかったこと（副産物編）

ここからは、別にキャンプ特有の内容ではありません。社会人が何かを勉強するコミュニティに入ったら、勝手にそうなったというだけですが、一応紹介します。

レビュイーの気持ちを思い出せる

一般的に社会人3年目って、仕事の流れを一通り覚えて、後輩もできて…みたいな年頃かと思います。
そして放置される年頃かと思います（私の場合、割と入社当初から最初から放置されがちでした）。

そうすると、上からのレビューを受ける立場（レビュイー）は徐々に減り、逆にレビュアーになるんですよね。私は特殊スキルで「謎の信頼」を発動しているので、レビューの場を設定しても何も言われなくなりました。

で、キャンプに入ったことで、また教えをこう立場に戻れたわけです。すると仕事をする際にも、レビュイーの気持ちに共感しやすくなる（同感はNGですが）というメリットがありました。どこまで教えようか、どう伝えようか、などなど。

生活リズムが規則正しくなる

普段は本業をやっているので、どこかで学習時間を確保しないといけません。私の場合、今はテレワーク中なので、

6
~ 8
キャンプ
8
~ 17
(~19
) 仕事
19
~ 23
キャンプ

とすることで時間を確保しています。時間を確保するためには早起きしないといけないので、必然的に生活リズムがよくなりました。ついでにいうと、仕事も切り上げないと勉強できないので、タスク管理も今まで以上にテキパキやっています（感覚ですが）。

ちなみにキャンプではslackに学習用チャンネルがあり、そこで「朝の$1」を開催してくださっている生徒の方がいらっしゃるので、私も便乗してなんとか朝の習慣を続けています。

slack文化に慣れる

本業の方でもslackはあるのですが、基本的にメール文化です。すると、slackを使ったやりとりに$1ハードルがあるんですよね。

私も最初は会ったことのない人にチャットをするのは緊張しましたが、慣れました。
SIerから転職ありきでプログラミングスクールに入るのであれば、Web系ではslackは当たり前に使われていると思うので、練習できる場があるのは嬉しいかな〜と個人的に。

最後に

まずは本業とキャンプの両立を維持しながら、コツコツとプ$1ティスを進めていきたいと思います。やっていく中で、学んだこと、感じたこと、時々フォッカチオ作りをこのブログに描ければなと思います。

、一般的にはどちらかの$1リストを目指す

$1 図17より引用

ikuma-t.com

chezmoiの変更をClaude Codeにコミットさせる

Obsidianでアバターアイコンを挿入できるようにする

Advanced Functional Programming With Elixirを読んだ

本書の概要

対象読者

学んだこと

律（Laws）

Functor、Applicative、Monad の階層

共変と反変（Covariant / Contravariant）

lift（持ち上げ）

Kleisli 関数

おわりに

ページ内検索を活かすために仮想スクロールを採用しないという選択

ページ内検索利用の経緯

静的解析の限界からテキスト検索の実装を検討

自前実装を見送った理由

仮想スクロールではページ内検索ができない

仮想スクロールを使わずに描画するための調整

前提

React から SolidJS への切り替え

details 要素を利用する

details の開閉をバッチ処理にする

content-visibility を利用して要素の描画をやめる

Shiki のハイライトを遅延させる

デモ

おわりに

Footnotes

JSConf JP 2025に参加した

PreEvent

グッズ購入

ブース

セッション

懇親会

おわりに

Footnotes

goghを購入した（Steam版）

スペースなしのGitエイリアスを設定する

Git のエイリアス

スペースなし版エイリアスを自動で設定する

VSCodeでプロジェクトの設定と異なるSeverityでESLintエラーを報告する

課題： ESLintルールはそのままに、自分のエディタ上の表示を変更したい

VSCodeのeslint.rules.customizationsを使ってSeverityを変更する

Astro Content Layer で個人ブログのコンテンツ取得はもっと楽になる

なぜ Content Layer を使うのか

個人ブログ開発はどうコンテンツを取得するかが9割

Content Layer はコンテンツ取得を抽象化する

Content Layer の実例：Speakerdeck の RSS フィードから登壇ページを実装する

Content Layer を利用する

コミュニティが公開している Loader を利用する

独自の Loader を実装する

おわりに

参考

Footnotes

Make Impossible States Impossibleを意識してReactのPropsを設計する

Make Impossible States Impossible とは

Reactでの実践例

単一のプロパティでの例はさほど問題にならない

複数のプロパティでの例

Discriminated Unionによる解決

Compositionによる解決

既存コンポーネントの変更の際には状態の増加に気をつける

まとめ

Appendix

Make Impossible States Impossible / Make Illegal States Unrepresentable について言及された記事・動画

XState と Zag.js と状態と

Footnotes

CSSで親のコンテナのサイズをはみ出す子要素を作る

コンテナから要素をはみ出したい

calcでネガティブマージンを利用してはみ出す

参考

技術書典17 オフライン会場での戦利品紹介

技術書典17 オフライン会場に行ってきました！

現地会場での戦利品紹介

あざといLT

アクセシビリティを考えはじめるための本

Amazon BedrockとGitHub Actionsで文章自動レビューを実装してみる本

好きなことなら本当に続けられるのか 〜100日連続イラスト投稿してきた日々を振り返る〜 / 鍛錬するとコードレビューがループする 〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜

店舗を読み解く技術～小売業ドメイン知識入門～

虎の穴ラボの薄い本。vol.8

VSCodeの`eslint.rules.customizations`を使ってSeverityを変更する

好きなことなら本当に続けられるのか　〜100日連続イラスト投稿してきた日々を振り返る〜 / 鍛錬するとコードレビューがループする　〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜

「ポッドキャストをやりたい！」と思ったらまず読む本