[{"_1":2,"_93":-5,"_94":-5},"loaderData",{"_3":4,"_92":-5},"routes/home",{"_5":6,"_10":11},"posts",[7,25,31,37,43,50,56,62,68,74,80,86],{"_8":9,"_10":11,"_12":11,"_13":14,"_15":16,"_17":18,"_19":20,"_21":22,"_23":24},"slug","firestore-repository","uiLocale","ja","contentLocale","hasEn",true,"title","TypeScript製の軽量Firestoreクライアント「firestore-repository」を作った","createdAt","2025-02-19","updatedAt","2026-06-13","description","firestore-repository\n\nnpm: firestore-repository\nGitHub: ikenox/firestore-repository\n\n特徴\n\nいわゆるRepository PatternでのFirestoreクライアントを提供...","content","

firestore-repository

npm: firestore-repository
GitHub: ikenox/firestore-repository

特徴

いわゆるRepository PatternでのFirestoreクライアントを提供
なるべく独自の概念や複雑な仕組みを持ち込まず、公式ライブラリの薄いwrapperに徹する
ドキュメントデータはPOJOとして表現されるので、アプリケーションコードがライブラリと密結合しにくい
バックエンド（Node.js）とwebフロントエンドの両方に対応。インターフェースも共通のため、バックエンドとフロントエンド間でスキーマやクエリ定義などの共有が可能

作った理由

Firestoreの公式クライアントライブラリを生で使うだけだと、以下のような点が不便に感じました。

公式クライアントを使ってドキュメントをreadすると DocumentSnapshot というオブジェクトが返ってくるが、このオブジェクトはメタデータ的なあれこれもくっついている。純粋なデータ本体は.data()で取り出せるが、一方でドキュメントのIDは.data()内には含まれないので、データとIDを一緒に取り回そうとすると結局 DocumentSnapshot自体をアプリ内で引き回すことになり、アプリ全体がFirestoreライブラリに密結合するような形になってしまう\n
- 密結合を避けようとすると自前でDocumentSnapshotからPOJOに変換するようなレイヤをコレクションごとに用意するような感じになり、それはそれで面倒
\n
ドキュメントデータに基本的には型がつかない。一応withConverterという仕組みは用意されていて、これを使うと.data()で返ってくる値に型をつけることはできるのだが、前述のIDがデータ本体と別になってる問題なども絡んできて結局のところ微妙に使い勝手が良くない
公式クライアントライブラリにもバックエンド向けとフロントエンド向けが存在しているが、インターフェースの互換性は無く、例えばバックエンドとフロントエンドでスキーマ定義を共有するような場合は工夫が必要となる

公式ライブラリという立場だとこれらはしょうがないというか、公式として提供できるものは限られている（unopinionatedでないといけない）だろうとも思ったので、それならその辺を解消するための簡単なwrapperを自分で書いてみようと思いました。

使い方

インストール

# バックエンドで利用する場合\nnpm install firestore-repository @firestore-repository/google-cloud-firestore\n\n# フロントエンドで利用する場合\nnpm install firestore-repository @firestore-repository/firebase-js-sdk

スキーマを定義

まずはcollectionのスキーマを定義します。このスキーマ定義はバックエンド/フロントエンドで共有できます。
\nスキーマを共有することで、フロントエンドとバックエンドそれぞれで同じコレクションのドキュメントを一貫性を保った形でread(+write)できます。

import {\n  rootCollection,\n  string,\n  double,\n  map,\n  optional,\n  literal,\n  array,\n} from 'firestore-repository/schema';\n\n// define a collection\nconst users = rootCollection({\n  name: 'Users',\n  schema: {\n    name: string(),\n    profile: map({ age: double(), gender: optional(literal('male', 'female')) }),\n    tag: array(string()),\n  },\n});

備考: スキーマ定義では、コレクション名(name)と、ドキュメントデータの各フィールドの型(schema)を指定します。フィールドの型としては、string / double / bool / timestamp といったプリミティブな型のほか、map(ネストしたオブジェクト)、array、union、literal、optional / nullable など一通りのものが用意されており、これらを組み合わせてスキーマを表現できます。
\nなお、ドキュメントはデフォルトでは{ id, data }という形のシンプルなモデルとして読み書きされますが、アプリ独自のモデル型へ変換したい場合は後述のMapperでカスタマイズできます。

Repositoryインスタンスの作成

前のステップで定義したスキーマと、公式ライブラリのDBオブジェクトを使って、Repositoryのインスタンスを作成します。

// For backend\nimport { Firestore } from '@google-cloud/firestore';\nimport { rootCollectionRepository } from '@firestore-repository/google-cloud-firestore';\nconst db = new Firestore();\n\n// For web frontend\nimport { getFirestore } from '@firebase/firestore';\nimport { rootCollectionRepository } from '@firestore-repository/firebase-js-sdk';\nconst db = getFirestore();\n\nconst repository = rootCollectionRepository(db, users);

使うための準備としては以上で、あとは作成したRepositoryインスタンスを通じて各種操作が可能です。

基本のread/write操作

一通りの基本的なドキュメントの読み込み/書き込み操作を型がついた状態で行えます。リアルタイムアップデートの購読も可能です。
\ngetやsetの返り値や引数のデータ型はスキーマ定義に沿って導出されたシンプルなPOJOとなるため、アプリケーションコードとFirestoreを疎結合に保つことができます。

Repositoryのインターフェースもバックエンドとフロントエンドで共通です。（バックエンド側にはバックエンド専用のメソッドが追加されていたりといった増分は存在）

// Set a document\nawait repository.set({\n  id: 'user1',\n  data: { name: 'John Doe', profile: { age: 42, gender: 'male' }, tag: ['new'] },\n});\n\n// Get a document\nconst doc = await repository.get('user1');\n// doc = {\n//   id: 'user1',\n//   data: {\n//     name: 'John Doe',\n//     profile: { age: 42, gender: 'male' },\n//     tag: ['new'],\n//   },\n// }\n\n// Listen a document\nrepository.getOnSnapshot('user1', (doc) => {\n  console.log(doc);\n});\n\n// Delete a document\nawait repository.delete('user2');

クエリ

クエリについても、公式のFirestoreクライアントでサポートされているような条件指定や集計操作は一通り行えます。
\nリアルタイムアップデートの購読も可能です。

クエリ定義についても、バックエンド/フロントエンドで共有可能です。

import { eq, gte, limit, query, where } from 'firestore-repository/query';\nimport { average, count, sum } from 'firestore-repository/aggregate';\n\n// Define a query\nconst q = query(\n  { collection: users },\n  where(gte('profile.age', 20), eq('profile.gender', 'male')),\n  limit(10)\n);\n\n// List documents\nconst docs = await repository.list(q);\nconsole.log(docs);\n\n// Listen documents\nrepository.listOnSnapshot(q, (docs) => {\n  console.log(docs);\n});\n\n// Aggregate\nconst result = await repository.aggregate(q, {\n  avgAge: average('profile.age'),\n  sumAge: sum('profile.age'),\n  count: count(),\n});\nconsole.log(`avg:${result.avgAge} sum:${result.sumAge} count:${result.count}`);

なお、クエリ条件の指定にも型がつくようになっています。
\nフィールド名には補完が効き、存在しないフィールド名を指定した場合にはきちんとコンパイルエラーが発生するようになっています。
\nまた、指定した値がフィールドの型と合っていない場合にもコンパイルエラーになります。

const validQuery = query({ collection: users }, where(gte('profile.age', 20)));\n\nconst invalidQuery1 = query({ collection: users }, where(gte('profile.foo', 20)));\n//                                                            ~~~~~~~~~~~ スキーマで定義されていないフィールド名のためコンパイルエラー\n\nconst invalidQuery2 = query({ collection: users }, where(gte('profile.age', 'foo')));\n//                                                                           ~~~ 数値型でないためコンパイルエラー

バッチ操作

一括でのsetやdeleteができるメソッドを用意しています。
\nbatchGet については現状バックエンド側のみサポートしています^[1]。

// Set multiple documents\nawait repository.batchSet([\n  {\n    id: 'user1',\n    data: { name: 'Alice', profile: { age: 30, gender: 'female' }, tag: ['new'] },\n  },\n  {\n    id: 'user2',\n    data: { name: 'Bob', profile: { age: 20, gender: 'male' }, tag: [] },\n  },\n]);\n\n// Delete multiple documents\nawait repository.batchDelete(['user1', 'user2']);\n\n// Get multiple documents (backend only)\nconst users = await repository.batchGet(['user1', 'user2']);

また、setやdeleteなどの各種書き込み系のメソッドの第二引数では tx パラメータに公式ライブラリのバッチオブジェクトを渡せるようになっており、それを利用することで複数種別の書き込み操作を1つのバッチにまとめることが可能です。

// For backend\nconst batch = db.batch();\n// For web frontend\nimport { writeBatch } from '@firebase/firestore';\nconst batch = writeBatch(db);\n\nawait repository.set(\n  {\n    id: 'user3',\n    data: { name: 'Bob', profile: { age: 20, gender: 'male' }, tag: [] },\n  },\n  { tx: batch }\n);\nawait repository.batchSet(\n  [\n    {\n      id: 'user7',\n      data: { name: 'Alice', profile: { age: 30, gender: 'female' }, tag: ['new'] },\n    },\n    {\n      id: 'user8',\n      data: { name: 'Carol', profile: { age: 25, gender: 'female' }, tag: [] },\n    },\n  ],\n  { tx: batch }\n);\nawait repository.delete('user4', { tx: batch });\nawait repository.batchDelete(['user5', 'user6'], { tx: batch });\n\nawait batch.commit();

トランザクション

バッチと同じ要領で、各種メソッドの第二引数で tx パラメータに公式ライブラリのトランザクションオブジェクトを渡せるようになっています。

// For web frontend\nimport { runTransaction } from '@firebase/firestore';\n\n// Or, please use db.runTransaction for backend\nawait runTransaction(db, async (tx) => {\n  // Get\n  const doc = await repository.get('user1', { tx });\n\n  if (doc) {\n    doc.data.tag = [...doc.data.tag, 'new-tag'];\n    // Set\n    await repository.set(doc, { tx });\n    await repository.batchSet(\n      [\n        { ...doc, id: 'user2' },\n        { ...doc, id: 'user3' },\n      ],\n      { tx }\n    );\n  }\n\n  // Delete\n  await repository.delete('user4', { tx });\n  await repository.batchDelete(['user5', 'user6'], { tx });\n});

サブコレクション

Firestoreのサブコレクションにも対応しています。サブコレクションはsubCollectionで定義し、parentに親コレクションの名前を階層順(ルート側から)に並べた配列を指定します。例えばUsers/{userId}/Postsなら['Users']、さらに深いUsers/{userId}/Posts/{postId}/Commentsなら['Users', 'Posts']となります。

ルートコレクションとの違いは、ドキュメントを特定するためのIDが「親ドキュメントのID + 自身のID」のタプル(配列)になる点だけです。クエリ・バッチ・トランザクションなどそれ以外の操作は、ルートコレクションとまったく同じインターフェースで利用できます。
\nこれにより、ネストしたコレクション構造であっても、親子のパスを型で安全に表現しつつ、ルートコレクションと変わらない使い勝手でアクセスできます。

import { subCollection, string } from 'firestore-repository/schema';\n\n// For backend\nimport { subcollectionRepository } from '@firestore-repository/google-cloud-firestore';\n\n// For web frontend\nimport { subcollectionRepository } from '@firestore-repository/firebase-js-sdk';\n\nconst posts = subCollection({\n  name: 'Posts',\n  schema: { title: string() },\n  parent: ['Users'] as const,\n});\n\nconst postRepository = subcollectionRepository(db, posts);\n\n// Set a document (id is [parentDocId, docId])\nawait postRepository.set({\n  id: ['user1', 'post1'],\n  data: { title: 'My first post' },\n});\n\n// Get a document\nconst post = await postRepository.get(['user1', 'post1']);

なお、タプル形式のIDが扱いづらい場合は、後述のMapperを使ってIDを{ userId: string; postId: string }のような独自のオブジェクトに変換することもできます。

const postRepository = repositoryWithMapper(db, posts, {\n  // 独自のIDオブジェクト ⇄ タプルの相互変換を定義するだけ\n  toDocRef: (id) => [id.userId, id.postId],\n  fromFirestore: (doc) => ({\n    id: { userId: doc.id[0], postId: doc.id[1] },\n    data: doc.data,\n  }),\n  toFirestore: (post) => ({ id: [post.id.userId, post.id.postId], data: post.data }),\n});\n\n// IDをオブジェクトで指定できるようになる\nconst post = await postRepository.get({ userId: 'user1', postId: 'post1' });

発展的な使い方

ここからは必須ではありませんが、知っておくとより便利に使える発展的な内容を紹介します。

serverTimestampやincrementなどの特殊な値

Firestoreには、書き込み時にだけ使えるサーバー側の特殊な値(サーバータイムスタンプ、数値のインクリメント、配列要素の追加/削除)があります。これらはfirestore-repository/server-valueから提供されるヘルパーを使って、通常のフィールド値と同じように渡せます。

例えばserverTimestamp()を使うと、書き込み時にサーバー側のタイムスタンプを記録できます。

import { serverTimestamp } from 'firestore-repository/server-value';\n\n// ここでは users スキーマに updatedAt: timestamp() が追加で定義されているものとする\nawait repository.set({\n  id: 'user1',\n  data: {\n    name: 'John Doe',\n    profile: { age: 42, gender: 'male' },\n    tag: ['new'],\n    updatedAt: serverTimestamp(), // サーバー側のタイムスタンプを書き込む\n  },\n});

また、timestamp()型のフィールドはread時に自動的にDateへ変換されて返ってくるため、アプリレイヤではfirestore.Timestampを意識せずそのままDateとして扱えます。

\n
備考: incrementやarrayUnion / arrayRemoveも同じくヘルパーとして用意されていますが、現状のsetは対象ドキュメントを丸ごと上書きするため、これらをsetで使っても「既存値への加算」や「既存配列への追加/削除」としては機能しません（例えばincrement(5)は既存値+5ではなく、単に5で上書きするだけになります）。serverTimestampのように既存値に依存しない値は問題なく使えます。
\n
これらをFirestore本来の意味で動かすにはupdate/merge相当の操作が必要ですが、これは「ドキュメントの一部分だけを更新する」という部分更新であり、「集約をまるごと取得・永続化する」というRepository Patternの考え方と噛み合わないため、このライブラリでは今のところ提供していません。
\n

カスタムMapper

rootCollectionRepositoryなどで作成したRepositoryは、デフォルトでは{ id: string, data: ... }という形のモデルを読み書きします。これは公式のFirestoreライブラリのデータ形式に近いですが、アプリケーション側では「IDとデータがフラットにまとまった独自のモデル型」で取り回したいケースも多いはずです。

そういった場合は、独自のMapperを定義してrepositoryWithMapperでRepositoryを作成することで、FirestoreドキュメントとアプリのモデルとをRepository内で自動的に相互変換できます。これにより、アプリケーションコードからは{ id, data }という構造を意識せず、後ろにFirestoreがあることを意識させない純粋なドメインモデルとして扱えるようになります。

Mapperは以下の3つの関数で構成されます。

toDocRef: アプリのモデルのIDをFirestoreのドキュメント参照に変換する
fromFirestore: Firestoreのドキュメントを読み込み用のモデルに変換する
toFirestore: 書き込み用のモデルをFirestoreのドキュメントに変換する

このMapperの定義自体も型安全に記述できます。fromFirestoreの引数(Firestoreから取り出したドキュメント)やtoFirestoreの返り値(Firestoreへ書き込むドキュメント)の型は、スキーマ定義から自動的に導出されます。そのため、ドメインモデルとFirestoreドキュメントの間の変換ロジックを、型のサポートを受けながら(フィールド名の補完や型の不一致のコンパイルエラーを効かせつつ)記述できます。

import { type AppModel, type Mapper } from 'firestore-repository/repository';\n\n// For backend\nimport { repositoryWithMapper } from '@firestore-repository/google-cloud-firestore';\n// For web frontend\nimport { repositoryWithMapper } from '@firestore-repository/firebase-js-sdk';\n\n// Define your application model type\ntype User = {\n  userId: string;\n  name: string;\n  profile: { age: number; gender?: 'male' | 'female' };\n  tag: string[];\n};\n\n// Define a mapper\nconst userMapper: Mapper<typeof users, AppModel<string, User, User>> = {\n  toDocRef: (id) => [id],\n  fromFirestore: (doc) => ({ userId: doc.id[0], ...doc.data }),\n  toFirestore: (user) => ({\n    id: [user.userId],\n    data: { name: user.name, profile: user.profile, tag: user.tag },\n  }),\n};\n\nconst repository = repositoryWithMapper(db, users, userMapper);\n\n// Now the repository accepts and returns your custom User type directly\nawait repository.set({\n  userId: 'user1',\n  name: 'Alice',\n  profile: { age: 30, gender: 'female' },\n  tag: ['new'],\n});\nconst user: User | undefined = await repository.get('user1');\nawait repository.delete('user1');

読み込み用と書き込み用で別々のモデル型を使う

カスタムMapperでは読み込み用と書き込み用で別々のモデル型を指定することもできます。
\n例えば「書き込み時はupdatedAtに'server-time'を指定するとサーバー側で現在時刻が書き込まれ、読み込み時はDateとして受け取る」といった、read/writeで非対称なドメインモデルを表現できます。ライブラリ固有のserverTimestamp()はMapperの中に隠蔽してしまえるので、アプリ側のモデルは分かりやすい表現に保てます。

import { serverTimestamp } from 'firestore-repository/server-value';\n\n// users スキーマに updatedAt: timestamp() がある前提\ntype User = { userId: string; name: string; updatedAt: Date };\ntype UserWrite = { userId: string; name: string; updatedAt: Date | 'server-time' };\n\nconst userMapper: Mapper<typeof users, AppModel<string, User, UserWrite>> = {\n  toDocRef: (id) => [id],\n  fromFirestore: (doc) => ({ userId: doc.id[0], name: doc.data.name, updatedAt: doc.data.updatedAt }),\n  toFirestore: (user) => ({\n    id: [user.userId],\n    data: {\n      name: user.name,\n      // 'server-time' のときだけサーバータイムスタンプに変換する\n      updatedAt: user.updatedAt === 'server-time' ? serverTimestamp() : user.updatedAt,\n    },\n  }),\n};\nconst repository = repositoryWithMapper(db, users, userMapper);\n\n// 書き込み時は 'server-time' を指定するとサーバータイムスタンプが記録される\nawait repository.set({ userId: 'user1', name: 'Alice', updatedAt: 'server-time' });\n\n// 読み込み時は Date として返ってくる\nconst user = await repository.get('user1');\nconst updatedAt: Date = user!.updatedAt;

まとめ

という感じで、一通りのことができる便利なFirestoreクライアントライブラリを作れました。
\nよければ使ってみてください。

\n
フロントエンド側については、一括取得は公式クライアントとしても未サポートとなっている https://github.com/firebase/firebase-js-sdk/issues/1176 ↩
\n

",{"_8":26,"_10":11,"_12":11,"_13":14,"_15":27,"_17":28,"_19":-7,"_21":29,"_23":30},"rebuilt-blog-with-astro-and-cloudflare","ブログをCloudflare Pages + Astroに載せ替えました","2023-10-07","仕事でNode.jsを触っていて、その流れでSSRやSSGといった文脈にも興味を持つようになり、その中でも最近よく話題になっているのを見かけるAstroとCloudflareにブログを載せ替えてみました。...","

仕事でNode.jsを触っていて、その流れでSSRやSSGといった文脈にも興味を持つようになり、その中でも最近よく話題になっているのを見かけるAstroとCloudflareにブログを載せ替えてみました。

Astro

https://astro.build/

触る前は .astro という独自の拡張子のファイルでページやコンポーネントを記述しなくてはいけない点がどうかなと思ってたんですが、いざ書いてみると書き方は直感的だなと思いましたし、VSCodeのAstro拡張も用意されていて補完も効くし、体験良かったです。

Cloudflare Pages

https://pages.cloudflare.com/

プレビューも簡単、デプロイも非常に高速かつスムーズで、触り始めて小一時間程度でGitHub Pagesからの移行をCI/CDの仕組みも含め完了できました。\n現状はSSGした静的サイトを公開しているだけですが、今後Cloudflare Workersをうまく使ってZennのリンクカードみたいな機能（外部サイトのOGP取得＆ブログ記事内に埋め込み）とか作ってみたいなと思っています。

余談

そろそろブログ記事よりもブログのフレームワーク入れ替えた回数の方が多い説が出てきました。

",{"_8":32,"_10":11,"_12":11,"_13":14,"_15":33,"_17":34,"_19":-7,"_21":35,"_23":36},"h2s-rs","RustでHTMLを宣言的にスクレイピングするためのライブラリ「h2s」を書いた","2023-05-01","h2s\n\ncrates.io: https://crates.io/crates/h2s\nRepository: https://github.com/ikenox/h2s-rs\n\nhtml-to-struct...","

h2s

crates.io: https://crates.io/crates/h2s
Repository: https://github.com/ikenox/h2s-rs

html-to-struct なので h2s です。

アピールポイント

スクレイピングロジックを宣言的に記述できる
シンプルかつ柔軟なインターフェース
エラー原因が詳細にわかる

詳細は後述します。

使い方

スクレイピング対象のHTMLドキュメントにどういう構造を期待するかをstructとして定義する
h2s::parse(html) を呼ぶ
スクレイピング結果がstructに入って返却される\n
- 定義したstructとHTMLドキュメントの構造が合わない場合にはエラーが返る
\n

例

例として、以下のようなHTMLドキュメントをスクレイピングしたいとします。

<html lang=\"en\">\n  <body>\n    <div>\n      <h1 class=\"blog-title\">My tech blog</h1>\n      <div class=\"articles\">\n        <div>\n          <h2><a href=\"https://example.com/1\">article1</a></h2>\n          <div><span>901</span> Views</div>\n          <ul>\n            <li>Tag1</li>\n            <li>Tag2</li>\n          </ul>\n        </div>\n        <div>\n          <h2><a href=\"https://example.com/2\">article2</a></h2>\n          <div><span>849</span> Views</div>\n          <ul></ul>\n        </div>\n        <div>\n          <h2><a href=\"https://example.com/3\">article3</a></h2>\n          <div><span>103</span> Views</div>\n          <ul>\n            <li>Tag3</li>\n          </ul>\n        </div>\n      </div>\n    </div>\n  </body>\n</html>

HTMLドキュメントに期待する構造の定義をstructで行います。structの各フィールドにおいて、attributeでCSSSelectorを記述します。\n一例としては以下のようになります。

#[derive(FromHtml, Debug, Eq, PartialEq)]\npub struct Page {\n    #[h2s(attr = \"lang\")]\n    lang: String,\n    #[h2s(select = \"div > h1.blog-title\")]\n    blog_title: String,\n    #[h2s(select = \".articles > div\")]\n    articles: Vec<Article>,\n}\n\n#[derive(FromHtml, Debug, Eq, PartialEq)]\npub struct Article {\n    #[h2s(select = \"h2 > a\")]\n    title: String,\n    #[h2s(select = \"div > span\")]\n    view_count: usize,\n    #[h2s(select = \"h2 > a\", attr = \"href\")]\n    url: String,\n    #[h2s(select = \"ul > li\")]\n    tags: Vec<String>,\n    #[h2s(select = \"ul > li:nth-child(1)\")]\n    first_tag: Option<String>,\n}

その後、h2s::parseを呼ぶとスクレイピングが実行されます。

let page: Page = h2s::parse(\"(前述したHTMLドキュメント)\").unwrap();

結果として、初めに定義したstructにスクレイピングした値が入って返却されます。

// 正しくスクレイピングできていることを確認\nassert_eq!(page, Page {\n    lang: \"en\".to_string(),\n    blog_title: \"My tech blog\".to_string(),\n    articles: vec![\n        Article {\n            title: \"article1\".to_string(),\n            url: \"https://example.com/1\".to_string(),\n            view_count: 901,\n            tags: vec![\"Tag1\".to_string(), \"Tag2\".to_string()],\n            first_tag: Some(\"Tag1\".to_string()),\n        },\n        Article {\n            title: \"article2\".to_string(),\n            url: \"https://example.com/2\".to_string(),\n            view_count: 849,\n            tags: vec![],\n            first_tag: None,\n        },\n        Article {\n            title: \"article3\".to_string(),\n            url: \"https://example.com/3\".to_string(),\n            view_count: 103,\n            tags: vec![\"Tag3\".to_string()],\n            first_tag: Some(\"Tag3\".to_string()),\n        },\n    ]\n});

structのフィールドに指定できるものとしては、文字列や数値型の他にもOptionやVec、また別のstructのネストなど、実際のユースケースで必要となりそうなものは一通りサポートしています。

このライブラリの利点

スクレイピングロジックを宣言的に記述できる

従来の手続き的なスクレイピングの方法だとHTMLドキュメントを走査していくロジックが冗長になりがちで、「HTMLドキュメントにどういう構造を期待しているか」が実際のコードからは読み取りづらいという状況になりやすいです。真面目にやろうとするとエラーハンドリングのような本筋でないロジックも多く混ざってくるため、より煩雑になりがちです。

h2sでは「HTMLドキュメントにどういう構造を期待しているか」を定義すればそれがそのまま動くので、手続的な方法に比べてロジックの見通しが良く、書くのも読むのも楽です。

シンプルかつ柔軟なインターフェース

宣言的という特徴とも被る部分はありますが、コード例を一目見ただけで使い方が迷わずわかるくらいのシンプルなライブラリを目指しました。

一方で、ライブラリとしてtraitを丁寧に定義して公開することを意識しており、それによりユーザー側でライブラリ各所において適切に拡張ができるようにしています。\n例えば、struct 定義の末端のフィールドとして、Stringやusizeなどの他に自前の構造体やh2sがデフォルトでサポートしていない構造体を指定したい場合は、その構造体に特定のtraitを実装することで利用できるようになります(コード例)。

エラー原因が詳細にわかる

h2sと同じアプローチを取っている先行のライブラリに unhtmlがありますが、こちらのライブラリではHTMLドキュメントが期待した構造ではなかった際に、具体的な問題の箇所や原因がわからないという課題がありました（作者も認識してそう）。\nこのライブラリがしばらくメンテも止まってそうということもあり、せっかくなら自分で書いてみるかというのがh2sを作った元々のモチベーションでもあります。

h2sではHTMLドキュメントの構造が期待と合わずエラーとなった際、「どこがどうマッチしなかったか」がわかるようなメッセージで返却するようにしています。これによりデバッグやエラーの調査が楽になることが期待できます。

エラーの例を示すため、以下のように先ほどのHTMLドキュメントの一部をコメントアウトした状態で再度スクレイピングを実行してみます。

<html lang=\"en\">\n  <body>\n    <div>\n      <h1 class=\"blog-title\">My tech blog</h1>\n      <div class=\"articles\">\n        <div>\n          <h2><a href=\"https://example.com/1\">article1</a></h2>\n          <div><span>901</span> Views</div>\n          <ul>\n            <li>Tag1</li>\n            <li>Tag2</li>\n          </ul>\n          <p class=\"modified-date\">2020-05-01</p>\n        </div>\n        <div>\n          <h2><a href=\"https://example.com/2\">article2</a></h2>\n          <div><span>849</span> Views</div>\n          <ul></ul>\n          <p class=\"modified-date\">2020-03-30</p>\n        </div>\n        <div>\n          <!-- 一部をコメントアウト -->\n          <!-- <h2><a href=\"https://example.com/3\">article3</a></h2> -->\n          <div><span>103</span> Views</div>\n          <ul>\n            <li>Tag3</li>\n          </ul>\n        </div>\n      </div>\n    </div>\n  </body>\n</html>

すると、HTMLドキュメントが期待している構造と合わないため h2s からエラーが返却されます。どの位置でどういったエラーが起きたかはエラー内部にスタック構造で保持されており、.to_string()で以下のようなエラーメッセージが得られます。

[articles(.articles > div)]: (index=2): [title(h2 > a)]: expected exactly one element, but no elements found

このエラーは、「articles(.articles > devにマッチする要素)の3番目(index=2)の要素において、\ntitle(h2 > aにマッチする要素)が見つからない」と読むことができ、詳細なエラーの原因箇所がわかるようになっています。

そのほか一例としては、要素数が想定と合わない場合などもきちんと検知し、その旨のエラーが出ます。

/// 例: 1つしか存在しない想定の要素が1つ以上見つかった場合\n#[derive(FromHtml, Debug, Eq, PartialEq)]\npub struct MyStruct1 {\n    #[h2s(select = \"h1\")]\n    h1: usize,\n}\n\nlet err = h2s::parse::<MyStruct1>(\"<div><h1>1</h1><h1>2</h1></div>\").unwrap_err();\n\nprintln!(\"{}\", err.to_string());\n// => [h1(h1)]: expected exactly one element, but 2 elements found

/// 例: ちょうど3つ存在する想定の要素が2つしか見つからなかった場合\n#[derive(FromHtml, Debug, Eq, PartialEq)]\npub struct MyStruct2 {\n    #[h2s(select = \"h2\")]\n    h2: [usize; 3],\n}\n\nlet err = h2s::parse::<MyStruct2>(\"<div><h2>1</h2><h2>2</h2></div>\").unwrap_err();\n\nprintln!(\"{}\", err.to_string());\n// => [h2(h2)]: expected 3 elements, but found 2 elements

その他のこだわり

ユーザビリティにはあんまり影響しなさそうだけど個人的に頑張った点です。

バックエンドの HTML パーサーライブラリを差し替え可能

h2sはHTMLドキュメントを文字列からパースしたり、DOMを走査したりするロジック自体は持っておらず、そこは裏で scraperを利用させてもらっています。ただし、h2sのコアからはscraperには直接依存せず、特定の traitを実装すれば他のライブラリもバックエンドとして利用できるような構成にしています。

実際差し替える需要とかあるの？と言われると、あんまりなさそうですねとなります。

Generic Associated Types の利用

h2sのコアロジックを書くにあたって「TとVec<T>とOption<T>を区別せずfn(T) -> Uを適用したい」みたいな場面が出てきて、それを綺麗に書こうしたところ関数型プログラミングでいうところのFunctorに近いものを実装したくなり、そこでGATsが必要になって使いました。

HTMLのツリーを走査してstructに当てはめていくというh2sの処理は、Functorをはじめとする関数型プログラミングの概念を持ち込むことでかなりスッキリ書けそうな見通しはあるのですが、現時点では半端にしか活かせていない状況です。\n現状のRustのGATsの表現力ではFunctorやMonadのような概念を表現するには不十分であるとされており^[1]、実際h2sで実装したのもFunctorもどきの半端なものとなってしまい、それによって本来共通化できそうな部分の処理が共通化できていないといった課題があります。\n現時点ではGATsを利用したのはかなり趣味の範疇であると言わざるを得ず、結果としてGATsがstableになったRust1.65以上を要求するようになってしまったので、デメリットの方がでかいのではないかという気はしています。\n今後GATsがパワーアップするかもしくは別のfeatureとして何らかの改善がなされたら、積極的にh2sにも取り込みたいなと思っています。

今後の課題

並行して複数のエラーが発生した時にも先頭の1つしか返せてないので、理想的には全部返せるようにしたいです。
「この中のいずれかの要素が必ず一つ含まれる」みたいなORの表現を提供できていないので、enumをサポートしてその辺をカバーできると良さそうだなと思っています。
Genericな構造体をサポートできたら楽しそうだなと思っています。

まとめ

個人の趣味で運用しているスクレイピングのシステムにて実際にh2sを使ってみているのですが、今のところ気持ちよく使えています。\nh2sのソースコード量やpublicなインターフェース数の少なさの割には柔軟に豊かな振る舞いをしてくれているような感覚があり、結構よくできたんじゃないかなと思っています。\nよかったら使ってみてください。

\n
https://zenn.dev/yyu/articles/f60ed5ba1dd9d5 ↩
\n

",{"_8":38,"_10":11,"_12":11,"_13":14,"_15":39,"_17":40,"_19":-7,"_21":41,"_23":42},"ideavim-search-actionlist","IdeaVimで「IntelliJでいつも使ってるあの機能」のaction名を探し当てる","2019-06-11","IdeaVim の action\nIdeaVim では、~/.ideavimrcに設定を記述することでキーマップに任意の IntelliJ の機能(action)を割り当てることができる。\n以下に設定の記述例を示す。...","

IdeaVim の action

IdeaVim では、~/.ideavimrcに設定を記述することでキーマップに任意の IntelliJ の機能(action)を割り当てることができる。\n以下に設定の記述例を示す。

nnoremap gd :action GotoDeclaration<CR>

これは、「ノーマルモードでgdを入力すると、GotoDeclarationという action を実行する」というキーマップの設定である。\nここでGotoDeclarationというのは、関数や定数の定義元にジャンプする IntelliJ の機能であり、デフォルトだとctrl+B(Mac ならcmd+B)\nに割り当てられている。

このように、IdeaVim では、任意の IntelliJ の機能をキーマップに割り当てることができるようになっている。

「IntelliJ でいつも使ってるあの機能」の action 名の見つけ方

では、「IntelliJ でいつも使ってるあの機能」の action 名を探し当てるにはどうしたらよいのか。

IdeaVim では:actionlist 文字列 コマンドによって、文字列に部分一致する action 名の検索が可能になっている。そして、\nIdeaVim の v0.51.2 からは、action 名の部分一致のほか、現在その action に割り当てられているショートカットキー\nの部分一致でも検索できるようになった。

これにより、目的の action 名が飛躍的に見つけやすくなった。\n(\nそれまでは、肝心の action 名がわからないのに action\n名の部分一致で検索するしかなかったので、頑張ってそれっぽい単語で検索してみて当たるまで繰り返すということをやるしかなかった)

例

:actionlist <M-I> で検索した場合

--- Actions ---\nImplementMethods                                   <M-I>\nMethodHierarchy.ImplementMethodAction              <M-I>

:actionlist <M-S- で検索した場合

--- Actions ---\n$Redo                                              <M-S-Z> <A-S-BS>\nActivateVersionControlToolWindow                   <M-9> <M-S-9>\nChangeTypeSignature                                <M-S-F6>\nCloseActiveTab                                     <M-S-F4>\nCollapseAllRegions                                 <M-S-m> <M-S-->\nCollapseBlock                                      <M-S-.>\n...

",{"_8":44,"_10":11,"_12":11,"_13":14,"_15":45,"_17":46,"_19":47,"_21":48,"_23":49},"validation-in-clean-architecture","Clean Architectureにおいてバリデーションはどこでやるべきか","2019-03-25","2025-03-16","クリーンアーキテクチャでwebアプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。\n結論から言うと\nバリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべきである。...","

クリーンアーキテクチャでwebアプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。

結論から言うと

バリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべきである。

バリデーションという単語は意味があまりに広く、「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同様にバリデーションについても、それぞれのレイヤごとに、それを受け付けてしまうと自分のレイヤの責務を果たすことができなってしまうようなinputがやってきた場合は弾くようにするというのがバリデーションである。
\nなので、バリデーションはレイヤごとに存在するし、バリデーションの責務や意味合いはレイヤごとに異なってくる。

そして逆に言うと、とあるレイヤで、そのレイヤの責務以上のバリデーションをしてしまうようなお節介をすべきではない。そのようなことをすると何らかの不都合が発生してしまうことが多い(後述)。

バリデーションは単なる仕様

バリデーションという言葉に引っ張られて、クリーンアーキテクチャの枠から外れてバリデーションを特別扱いして考えてしまってはいけない。バリデーションも単なる仕様であり、仕様の部分集合のことをわざわざバリデーションと呼んでいるだけに過ぎない。「クライアントはJSON形式でリクエストできる」「ユーザーは任意の文章を投稿できる」といった仕様があればまた、その裏返しとして「JSON以外の形式は受け付けない」「本文が空白の場合は投稿できない」といったバリデーションが必要というだけの話である。
\nシステムが、自身に言いつけられた仕様や責務を果たそうとした結果の副産物としてバリデーションが発生する。

ここまでで本質的な部分のお話は終わってしまった感があるが、ここから先は、具体的にクリーンアーキテクチャにおいてどの層でどういったバリデーションをすべきかについて考察していく。

Frameworks & Drivers 層におけるバリデーション

この層はクリーンアーキテクチャにおいて一番外側に位置する層であり、自分たちで実装する分量は少ないが、この層でもバリデーションが行われる場合がある。

たとえばnginxは、リクエストのデータが大きすぎる場合にHTTP Status Codeとして413(Entity Too Large)を返す設定があるが、これも一種のバリデーションと言える。あとは、SSL/TLSにおけるリクエストの改竄チェックとかもバリデーションと言っていいのかもしれない。このレイヤにおけるバリデーションは、OSやハードなど技術的詳細に起因する制限や、最低限のセキュリティの担保というのが主な役割になりそう。

Interface Adapter 層におけるバリデーション

Interface Adapterの責務は、アプリの内外のデータ形式の変換である。たとえば、外部から渡ってきたHTTP RequestのBodyに入っているJSON文字列を、辞書型のオブジェクトなどにデシリアライズして適切なUseCaseに渡す、といった処理である。

ここで、たとえばRequest Bodyが壊れておりJSONのフォーマットになっていない場合などは、内外のデータの変換が完遂できないのでエラーとするのが一般的であると思うが、これも一種のバリデーションエラーといえる。やりとりのためのプロトコルが守られていないことを検知して弾いていることになるので、立派なバリデーションエラーである。
\nInterface Adapter層におけるバリデーションは、「システム内外のやりとりのためのプロトコルが守られているかのチェック」であるといえる。

逆に、正しくオブジェクトにデシリアライズできたのであれば、Interface Adapter層ではそれ以上のチェック、たとえば文字数や数値範囲のチェックは不要である。なぜならそれをやると、内外のデータ形式の変換という役割から逸脱してしまうからである。

Application層とDomain層それぞれにおけるバリデーション

Application層^[1]にはアプリケーションロジックが書かれ、Domain層^[2]にはドメインロジックが書かれる。

ところで、アプリケーションロジックとドメインロジックの違いは？という問いについて、なかなか直観的かつ解釈にブレが生じづらい表現が難しいという問題があるのだが、ここでは一旦以下のような定義として話を進めさせてもらう。

\n
アプリケーションロジック: システム都合、アプリ都合のロジック。システムやアプリの形によりけりなロジック。システムやアプリという形になっているために存在しているロジック。ユースケース特有のロジック。例としては、送金サービスにおける、永続層(Repository)を介してのデータの保存/取得や「出金した際にはメール通知を飛ばす」といった仕様など。
\n
\n
ドメインロジック: ドメインを表現するロジック。システムやアプリの形によらず存在しうるロジック。扱いたいドメインがシステムやアプリという形になっていなかったとしても存在しうるロジック。ユースケースによらず成り立つロジック。例としては、送金サービスにおける、「残高以上の金額の送金はできない」といった仕様など。
\n

※ なお、アプリケーションロジックなのかドメインロジックなのかは、「そのシステムにおいてそもそも何をドメインとするか」で変わってくる可能性があることは注意。このへんの性質が、両者の違いの言語化が難しい要因のような気がする。

では、Application層とDomain層それぞれにおけるバリデーションについて、具体例で考えてみる。まずは以下のようなバリデーションについて考える。

ECサイトにおいて、サーバーの処理能力に限界があるため、一度に注文できる上限個数を99個に制限する。

先程の定義に照らし合わせると、これはアプリケーションロジックと言える。\nここでの99個という上限はシステム都合の仕様であり、ドメイン自体の表現に関わるロジックではない。なのでこれはアプリケーションロジックだし、Application層に書くべきであるといえる。

では次はどうだろうか。

ECサイトにおいて、1人あたりの購入上限個数が決まっている限定セールを行う際、一人が注文できる上限個数を3個に制限する。

これはドメインロジックと言える。このバリデーションがなかった場合には限定セールというドメインが成り立たなくなるためである。ドメインロジックなので、Domain 層に書くべきであると言える。

上記2つの例を見ると分かる通り、ややこしいのは、入力数値のバリデーションひとつ取っても、アプリケーションロジックになる場合もあるしドメインロジックになる場合もあるという点である。
\n文面的には両者はほぼほぼ変わらないため、この事実は見落とされやすい。とあるバリデーションについてApplication層に書くべきなのかDomain層に書くべきなのかの見極めは慎重に行う必要がある。

バリデーションを書く場所を間違った場合にどうなるか

ここまで、各層においてどんなバリデーションをすべきかについて述べてきた。\nでは、とある層がお節介をしてしまい他の層でやるべきバリデーションまでやってしまうとどうなるのかについて考えてみる。

内側の層でやるべきバリデーションを外側の層でやった場合

このパターンは割とデメリットがわかりやすいというか自明かもしれない。本来もっと内側の層でやるべきバリデーションを外側の層でやってしまうと、複数箇所に同じようなロジックがコピペ的に増えたり、必須のはずの処理の抜け漏れが発生しやすくなるということが考えられる。

ではこの逆のパターンだとどうなるか。

外側の層でやるべきバリデーションを内側の層でやった場合

たとえば文章投稿SNSにおいて、「サーバーの処理能力の関係で、書き込みの際の文字数は10000文字までとしておく」というバリデーションについて考える。ここで、10000文字という制限はシステム都合の上限値であるため、アプリケーションロジックと言えそうである。

このようなアプリケーションロジックを、より内側のドメイン層に書くとどうなるか。\n投稿文章エンティティのコンストラクタで文字数のバリデーションを行った場合に何が起きるか考える。

最初のうちは問題にならないかもしれないが、たとえばもしあとで、「サーバーの負荷がきつくなってきたので、5000文字に制限を引き上げる」といった変更が入った場合について考える。そうなると、既存の投稿を永続層から取り出してエンティティとして復元しようとしたときに、5000\n文字を超えている既存の投稿についてはコンストラクタのバリデーションに引っかかってエラーになり、復元できなくなってしまう。\nまた、この変更を決断した時点で、文章投稿SNSのドメインに変化があったわけではない。変化したのはシステム(アプリケーション)の状況だけである。にもかかわらず、ドメイン層に書かれたロジックを変更しなくてはいけないという、不自然な状態に陥ってしまっている。

これは本来アプリケーション層にあるべきロジックをドメイン層に書いてしまったがゆえに起こってしまった事象であると言える。アプリケーション層に書いておけば、バリデーションが走るのは新規投稿に関するユースケースのみに限るようにでき、既存の投稿には一切影響を与えずに新規の投稿についてのみ文字数制限を厳しくするという形にできたはずである。

このように、本来もっと外側の層でやるべきバリデーションを内側でやってしまうと、不要に強すぎる整合性に困らされる場面が出てくると考えられる。\nまた、一般に内側の層のクラスになればなるほど他のクラスから依存されることが増える傾向にあるため、内側にバリデーションを書きすぎるとその分依存する側でのエラーハンドリングのコードも増えてしまう。内側になればなるほど、バリデーションは本当に必要なもののみを最小限にとどめて書くことが重要であるといえる。

まとめ

こうしてみると、どの層も責務は違えど、自分の責務を果たそうとした結果としてバリデーションが発生していることがわかって、当たり前といえばそうではあるけど面白い。システム設計に関するプラクティスはどれも元を追えば、「各自自分の責務だけを忠実に果たすようにする」という単純な原則に帰結するのかもしれない。

意識的にバリデーションを書こうとするのではなく、各レイヤに適切な責務を持たせようとした結果として自然とバリデーションロジックが書かれるような設計実装の方針が理想と言えそうです。

\n
原典ではApplication Business Rules層と呼ばれている ↩
\n
\n
原典ではEnterprise Business Rules層と呼ばれている ↩
\n

",{"_8":51,"_10":11,"_12":11,"_13":14,"_15":52,"_17":53,"_19":-7,"_21":54,"_23":55},"corne-keyboard","Corne Keyboard (コルネキーボード) を組んだ","2019-01-21","Corne Keyboard は、 @foostan\nさんが設計している自作キーボード。ハッシュタグは #crkbd。\n設計図はオープンソースになっており、GitHub にて公開されている。\nなお実際には、Corne Keyboard というのは Corne\nシリーズの総称のようなものであり、具体的なキーボードの種類としては ...","

Corne Keyboard は、 @foostan\nさんが設計している自作キーボード。ハッシュタグは #crkbd。\n設計図はオープンソースになっており、GitHub にて公開されている。

なお実際には、Corne Keyboard というのは Corne\nシリーズの総称のようなものであり、具体的なキーボードの種類としては Corne Cherry、\nCorne Chocolateなど、いくつかの種類が存在する。\n今回自分は Corne Cherry のキットを購入させてもらったので、実際に作ったり使ったりしてみての感想を書いていきます。

なお、現在は遊舎工房さんのEC サイト\nや実店舗にてキットが販売されているようです。

完成物

見た目と使い心地ともにとても満足しています。会社で毎日バリバリ使ってます。

$\"My$

出会い

常日頃から、左右分離式のキーボードほしいな〜と思っており、はじめは Ergodox EZ あたりを買おうかと思っていたが、Twitter かどこかに流れてきた Corne Cherry の写真を見て一目惚れしたのがきっかけ。

Corne Cherry のいいところ

3 行 + 親指用キーしか無い

写真を見ての通り、数字列が無いという潔さ。Touch Bar モデルの MacBookPro のキーボードが 64 キーなのに対して Corne Cherry は 42 キーと、約\n2/3 になっている。\nそのため、数字、記号、カーソルあたりの入力はレイヤ切り替え機能を使って同時押しで行うことになるが、もともとホームポジションから遠いカーソルキーは ctrl と hjkl\n同時押しで代用したりしてたので、個人的にはそこまで問題とは感じなかった。むしろ、どのキーにもホームポジションから 1\nキー以内で到達できるので、使い慣れれば最もストレスなく速く打てるレイアウトなのではないか、と思った。

見た目がかっこいい

フォルムがかっこよい。無駄がない。\n透明なカバーから覗く OLED ディスプレイもかっこよい。

薄い

作者の方いわく薄さにこだわっているとのこと。\nマイコンを外側に出すといった工夫により高さが抑えられており、タイプしやすい。

ホットスワップ対応

PCB ソケットという電子部品を使うことで、キースイッチ自体にはハンダ付けが不要となっており、ハンダ付け無しで簡単にキースイッチの取り外しや付け替えをすること(\nホットスワップ)が可能。\nこれは後で判明したことだが、自作キーボードをしばらく使ってるとほぼ 100％他のキースイッチを試したくなってしまうので、ホットスワップが可能というのはかなり大きい。\nまた、メンテの際に基板からキースイッチを剥がして裸にできるという点も地味に便利。

そして購入

Corne Cherry の存在を知った直後、偶然にもその 1 週間後くらいに開かれる技術書典 5 にてキットが販売されると知って、購入を決意。\n技術書典の当日は開場 1 時間前くらいに到着して並び、開場後は速攻で販売ブースに向かったが、それでも既に 20〜30\n人くらいの行列になっていた。\n自分の番になる頃には、人気のカラーはすでに売り切れていた。自分はマットブラックのキットを購入させてもらった。

組み立て

キットには同梱されてないキーキャップやキースイッチをKBDfansで調達し、ハンダごてなどの工具類は amazon で揃えた。\n中学校ぶりのハンダ付けだったが案外すぐ慣れて、時間はかかったが大きなトラブル無く作り終えることができた。\n詳細なビルドログはいろいろな人が書いてくれてる気がするので自分は省略。

※ ただし、オプションの LED のハンダ付けは結構大変だった

キーマップ

キーボードのファームウェアは OSS のqmk/qmk_firmwareを利用する。\nそのままでもいいけど、カスタマイズすることでキーマップを自由に変更できたり、OLED ディスプレイに表示する内容を好きに変えたりできるようになる。C 言語で書かれているが、C\n言語が得意じゃなくても雰囲気で書き換えればなんとか動く。\nqmk ではレイヤ機能のほか、長押し/短押しでの入力文字の変更なども可能となっている。ほかにも、全部把握できてないけどいろいろな機能がありそう。

今のところのキーマップは以下の形に落ち着いている。\n文字入力のためのレイヤは、デフォルト含め 2 つしか無い。今のところはそれで事足りている。\nキーマップについてもなるべくミニマムで抑えるようにしている。

Default layer\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n|TAB| Q | W | E | R | T |    | Y | U | I | O | P | - |\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n|CTL| A | S | D | F | G |    | H | J | K | L | ; | ' |\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n|SFT| Z | X | C | V | B |    | N | M | , | . | / |SFT|\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n            |CMD|L2 |SPC|    |ENT|L2 |ALT|\n            +---+---+---+    +---+---+---+\n\nL2 layer\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n| ~ | @ | # | # | $ | % |    | & | * | ( | { | [ | _ |\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n| ` | 1 | 2 | 3 | 4 | 5 |    | + | = | ) | } | ] | | |\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n| ^ | 6 | 7 | 8 | 9 | 0 |    |   |   | < | > | ? | \\ |\n+---+---+---+---+---+---+    +---+---+---+---+---+---+\n            |CMD|   |SPC|    |ENT|   |ALT|\n            +---+---+---+    +---+---+---+

このほかに、ファンクションキー、音量キー、LED の ON/OFF 切り替えなどの、文字入力以外のためのレイヤもあるがここでは省略。

上記の図で表しきれてないキーマップ

キーが少ない分、同時押しや長押し/短押しによる出し分けなどをある程度駆使することになる。

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

入力	入力方法
\\	右の Shift キーを短く押す
英/かな切り替え	Command/Alt を短く押す
Esc	Ctrl + ハイフン
バックスペース	Ctrl + m

同時押しについては、HHKB 使ってた時代の名残もあり今はソフトウェアで制御してて、Karabiner-Elements を使って制御している。(\nまだきちんと調べられてないのだけど、ファームウェアでも同時押しのキーマップの設定は可能なのだろうか。)

実際に使ってみて

はじめての左右分離式

初めての左右分離式キーボードだったが、触り始めの頃はかなりおぼつかない感じで、タイピング速度が元の 1 割くらいしか出なかった。今まで 1 つだったものが 2\nつに分かれるだけで体の感覚がこうもリセットされるのかという感じ。\nただ、その違和感は一週間も触ってるといつの間にか消えるし、(アルファベットに関しては)タイピング速度も元の 8\n割くらいにはすぐ戻る。自分の場合は使い始めて二週間位でもともと使ってた HHKB のタイピング速度と同じかそれ以上で打てるようになった。

そして、Corne Cherry\nにしてから肩こりがなくなったような気がする。まぁもともとそこまで肩こりひどいタイプではなかったけど、夜まで仕事しててもデスクワーク起因っぽい体の疲れを殆ど感じなくなった。\n左右分離式だと肩幅で打るので肩を丸めなくて済み、良い姿勢でタイピングできると聞いてたが、たしかに効果ある気がする。

キーの数

普通のキーボードに比べて数字や記号類がホームポジションから近くなったので、プログラミングがかなり快適になった。キーが全部近いので打ってて楽だし楽しい。\n改めて普通のキーボードを触ると、もはや数字や記号がとても遠く感じるようになっていた。

個人的には、この 42\nキーというのは本当に無駄がなく、下限ギリギリのキー数であるように感じている。どのキーもまんべんなく使っていて、使用頻度低いキーが無い。これ以上減ると流石に厳しそう。\n実際には、ごくたま〜にキーが足りないと思うことはある。alt や command が両手に欲しくなったりする。ただそこまで致命的ではない。\nもしキー増やすとしても、親指用に左右それぞれ+1 キーくらいかな、と思った。

慣れ

前述したように、タイピング速度はアルファベットだけなら 2 週間くらいで長年使ってた HHKB と同等かそれ以上になった。\n問題は記号類で、キー数少ない関係で基本的には一般的な配列を無視して完全に配列を考え直しになるので、なかなか覚えられず最初の方は苦労した。作業に支障出るほどではないけど、今でも結構間違う。記号や数字については、極力自分の中で合理的かつ規則的な配置にしておくと良さそう。\nそのほか、親指部分に ENTER を割り当てたりしているが、それも最初は違和感が大きかった。

単に慣れるために練習しようとしてもやっぱり続かないので、まぁ一応打てるかなというくらいになったらさっさと業務に実戦投入するのが一番てっとり早いと感じた。自分もその戦略だったけど、やはり仕事で使い始めると一瞬で慣れた。

あと、慣れるまでの途中に、なぜか普通のキーボードも Corne Cherry\nもどちらもまともに打てなくなるフェーズがある。普通のキーボードを打ってるときに親指でエンター押したつもりがスペースキー押してるとか。\nそしてなぜかそこを乗り越えると、特に意識せず使い分けられるようになるし打ち間違いもなくなる。不思議。

そのほか

たぶん自分のハンダ付けが下手くそなせいなんだけど、使っててキーが急に反応しなくなったり、逆にとあるキーを押すとその列のすべてのキーが反応してしまったりという事が不定期で起きる。はんだ付けがうまくできておらず、ショートさせてしまってる箇所があったりするっぽい。\nさっきまで使えてたのに急に調子悪くなることとかもあり、不具合が起きたときは家に持ち帰ってメンテしている。

今の自分の電子工作の腕前だと、さすがに既成品の安定性には勝てない部分はあると感じた。もっと習熟すれば市販品に遜色ないクオリティで仕上げることが可能になるのだろうか。

そして沼へ

家にキーボードやキーボードのパーツが際限なく増えていく人たちの気持ちがちょっとわかるようになってきた。

自作キーボードは下手に自分でカスタマイズできてしまうせいで、より快適なキーボードを求めていろいろ試したくなってしまい、終わりが見えない。\n特にキースイッチやキーキャップの誘惑がすごくて、最初に Corne Cherry\nを作ろうと思った際には必要最低限な数のキースイッチやキーキャップだけを買ったはずなのに、なぜか今ではキーボードをもう 1 つ作れるくらいのそれが余っている。

$\"stock\"$

キースイッチについては、最初は静音黒軸を使ってたけど、静音じゃないほうが打ち心地が軽やかで気持ちいい気がしてしまい、気づいたら BOX 赤軸に変えていた。\nそしてそれから一週間経った今、今度は BOX 黒軸が欲しくなっている。多分この週末で買いに行くんだと思う。

(追記: BOX 黒軸じゃなくてTealios V2を買いました。打鍵感や LED\n光の通りやすさが最高。)

キーキャップについては、DSA Profile のキーキャップじゃなくて Cherry Profile\nのものを使ってみたくなって気づいたら購入していた。そのほか様々なカラーのキーキャップも少量ずつ購入してストックしています。

そのほか、いま興味があるのは以下。

MDA か XDA profile のキーキャップ欲しい、かわいい
2 台目作りたい\n
- 次はもっとうまくはんだ付けできるはずという自信
- いつのまにかキースイッチとかが余り出していたので、2 台目作れてしまいそうでハードルが下がっている
\n
BLE Micro Pro でワイヤレス自作キーボードを作って、コードの煩わしさから開放されたい

まとめ

自作キーボードは、作っても楽しいし、使っても楽しい。\n苦労しながらハンダ付けをして、動作確認時にきちんとキー入力を受け付けてくれたときや、LED\nがきちんと光ったときの嬉しさとか、いつまでも眺めてしまう感じとかは久々の感覚だった。\nこれからも楽しんでいきたい。

最後に

End-game への道は遠い

この記事は Corne Cherry Keyboard で書きました。

",{"_8":57,"_10":11,"_12":11,"_13":14,"_15":58,"_17":59,"_19":-7,"_21":60,"_23":61},"repository-pattern","データベースという名のグローバル変数との向き合い方(Repository Pattern)","2019-01-12","グローバル変数\nスコープ関係なく、プログラム中のどこからでもアクセスが可能な変数のこと。\nその性質上、扱いには気をつけないといけない。扱いを間違えると、「いつどこで変数が書き換えられるかの把握が難しく、プログラムの見通しが悪くなる」といった問題が生じる場合がある。...","

グローバル変数

スコープ関係なく、プログラム中のどこからでもアクセスが可能な変数のこと。\nその性質上、扱いには気をつけないといけない。扱いを間違えると、「いつどこで変数が書き換えられるかの把握が難しく、プログラムの見通しが悪くなる」といった問題が生じる場合がある。

データベースはグローバル変数

MySQL などのデータベースに格納されたデータはグローバル変数と同じ性質を持っている。SQL\nクエリ等を介すことでプログラム中のどこからでもアクセスでき、書き換えが可能である。\n「グローバル変数の扱いには十分気をつけないとヤバいことになる」というのは広く共通認識として存在するが、一方で「データベースはグローバル変数である」ということが常に意識の片隅にあるかと言われると案外そうではない気がする。

そのため開発現場では、「データベースというグローバル変数が、意図せずして雑に扱われている」という現象が起きやすい。\nなので気をつけないと、一般にグローバル変数のデメリットとして言われる「いつどこで変数が書き換えられるかの把握が難しく、プログラムの見通しが悪くなる」という問題が容易に発生してしまう。\n結果、テーブルの行を update するロジックが様々な場所に散らばり、「テーブル X のカラム Y\nは、どういう条件・状態のときにどういう値を取るべきで、どこでどう使われているのか」というのが全く見えてこなくなる。仕様を把握しきれず雰囲気で更新ロジックを新たに追加した結果、意図せずしてデータの整合性を崩してしまったり、気まぐれにしか\nupdate されない updated_at を爆誕させたりする。

こういった問題はサービスが成長してコードの規模が大きくなればなるほど深刻になる。開発者は改修のたびにコード全体を grep することに作業時間の大半を費やすようになり、開発速度は低下し、コードをいじるたびに黒ひげ危機一発をしてメンタルをすり減らすことになる。

Repository Pattern

この問題の一つの解決策となりうるのが Repository パターンである。\nRepository パターンを用いた簡単な疑似コードを書いてみる。

class HogeRepository {\n\n  public Hoge get(int id) {\n    Row row = db.execute(\"SELECT id, a, b FROM hoge where id=?\", id);\n    return new Hoge(row.getInt('id'), row.getInt('a'), row.getStr('b'));\n  }\n\n  public void save(Hoge hoge) {\n    db.execute(\"INSERT INTO hoge VALUES (?, ?, ?) ON DUPLICATE KEY UPDATE ...\", hoge.id, hoge.a,\n        hoge.b);\n  }\n}\n\nclass Hoge {\n\n  int id;\n  int a;\n  String b;\n\n  public Hoge(int id, int a, String b) {\n    this.id = id;\n    this.a = a;\n    this.b = b;\n  }\n\n  public void changeState() {\n    this.a = this.a * 10;\n    this.b = this.b + \" foo\";\n  }\n}\n\n// Repositoryの利用例\nclass SomeApplicationService {\n\n  HogeRepository hogeRepository;\n\n  public void sampleProcess() {\n    Hoge hoge = hogeRepository.get(id);\n    hoge.changeState();\n    hogeRepository.save(hoge);\n  }\n}

Repository の役割は、「とあるオブジェクトの取得と保存」のみである。\nRepository は、オブジェクトの状態変化などのロジックには一切関与せず、「オブジェクトをどうやってデータベースに保存するか」「データベースからどうやってオブジェクトを復元するか」のみを完ぺきにこなすようにする。\nやってることの概念は、オブジェクトと JSON 間のシリアライズとデシリアライズのようなものに近い。

Repository パターンで書かれたこのコード片には、以下のような特徴がある。

「Hogeの保存/取得(DB⇔ オブジェクトの変換ロジック)」と「Hogeの内部状態の変化（ドメインロジック）」を切り離せている。
HogeオブジェクトのchangeState()によって変化するのはHogeオブジェクトの内部状態のみ。オブジェクトの内部状態が変わるだけなので DB\nは全く関与しておらず、当然 DB の更新は行われない。
Repository は単にHogeオブジェクトを現在の状態のまま DB に突っ込んだり取り出したりするだけである。そのため、Hoge\nの内部状態がいつどのように変化するかなどは Repository は全く知らなくてよい。

そして、これらの特徴は、データベースがグローバル変数であるがゆえの弊害を以下のように緩和してくれる。

DB との接点が最小限に抑えられている。DB とのやり取りの窓口はgetとsaveの 2 箇所のみに限られるため、「どこでどうHoge\nテーブルが参照/更新されるのか」がすぐ把握できる。
データの整合性を保つ役割はHogeクラスの内部に閉じており、外からどうHogeオブジェクトやHogeRepository\nをいじっても、データの整合性が崩れることはなくなっている。
「Hogeテーブルの各値は、どういう条件・状態のときにどういう値を取りうるのか」は、Hoge オブジェクトのロジックの内部だけ見れば把握できる。

そのほか、Repository パターンには以下のようなメリットもある。

DB が絡むテストが最小限で済む。「Hogeオブジェクトを現在の状態のままきちんと保存できるか」「きちんとHoge\nオブジェクトに復元し直せるか」のテストだけ書いておけば良い。Hogeオブジェクトの内部状態の更新ロジックは Repository には関係ない。
今後の仕様変更などによって内部状態の変化パターンや変化ロジックが増えたとしても、それによって DB への update 文を増やす必要はない。\n
- HogeRepositoryはHogeの現在の状態のままそっくりそのまま保存/取得するので、内部状態がどう複雑に変化しようと関係ない。
\n
DB を RDB から KVS とかに変更するようなことがあっても、Repository の参照/取得のロジックだけ書き直せば動く。\n
- テストの際の DB のモックも容易になる。ただ単にインメモリでオブジェクト保持しておくだけの Repository に差し替えたりすればよい。
\n

このように、Repository パターンをうまく用いることで、アプリケーション上で扱う物事について、その複雑な内部状態の変化を DB\nから切り離して柔軟に取り扱うことが可能となる。\nRepository パターンは、DB が本質的にはグローバル変数であるがゆえの辛さを緩和してくれる効果がある。

なお逆に、ログデータみたいに一回書き込んだら不変だし複雑なロジックも持ちませんみたいな場合には Repository\nパターンの恩恵はあまり享受できないと思われる。\nRepository パターンを適材適所でうまく使って、柔軟で見通しの良いアプリケーションを作りましょう。

",{"_8":63,"_10":11,"_12":11,"_13":14,"_15":64,"_17":65,"_19":-7,"_21":66,"_23":67},"inheritance-delegation-interface","継承と委譲の使い分けと、インターフェースの重要性について","2018-08-28","この記事は、「継承と委譲はどういった性質の違いがあり、どういった基準で使い分けているか？」「インターフェースは何が嬉しいのか？」といった点に関して自分なりに言語化を試みたものです。\nTL;DR\n\n継承は子が親と同じ能力や責務を獲得する。委譲は子が親を単なるツールとして所有するだけで、能力や責務は同じにはならない。...","

この記事は、「継承と委譲はどういった性質の違いがあり、どういった基準で使い分けているか？」「インターフェースは何が嬉しいのか？」といった点に関して自分なりに言語化を試みたものです。

TL;DR

継承は子が親と同じ能力や責務を獲得する。委譲は子が親を単なるツールとして所有するだけで、能力や責務は同じにはならない。\n
- 子にとって親は単なるツールである場合は委譲を使うのが良い。継承してしまうと子が複数の責務を負うことになり、そのことによる不都合が生じる。
- 逆に、子が親と同じ責務を持つべき場合には継承を使う。委譲を使うと、子が親と同じ能力を持っていないことによる不都合が生じる。
\n
インターフェースを使うことで責務の分離を強制することができる。インターフェースを適切に設計することができれば、改修時の影響範囲が最低限に留まるなどシステムの保守性や堅牢性が向上し、テストの容易性も得られる。

継承と委譲の違いと使い分け

例として、「SQL データベースからユーザー情報を取り出したり保存したりする機能」を作ろうとしたときに、以下のような実装方針になったとします。

DB の接続状態を保持したり SQL クエリを実行したりする部分のロジックは、ユーザー情報の取得に限らず、データベースから情報を取得するとき全般で使い回せそう（使いまわしたい）
DB の操作周辺に関して使い回せそうな部分はクラスに切り出しておいて(ここではDatabaseクラスとする)\n、ユーザー情報の取得や保存をするためのクラスUserRepositoryからDatabaseクラスを何らかの方法で利用するようにすれば、Databaseクラスの\nDB 操作機能を使いまわせて良い感じ

ここで、UserRepositoryからDatabaseクラスを利用する方法としては、継承または委譲が思い浮かびます。\n結論から言うと委譲を使ったほうが良いのですが、継承を使って以下のようにやってしまいたくなるかもしれません。

委譲を使うべき場面で継承を使った例

class Database {\n\n  void connectToDatabase(String dbHost, String dbName, ...) {\n    // DBへの接続ロジック\n  }\n\n  Result doSQL(String sql) {\n    // 接続しているDBにクエリを投げ、その結果を返すロジック\n  }\n\n  // そのほかデータベースの接続状態の管理など\n}

class UserRepository extends Database {\n\n  User getUser(int userId) {\n    String sql = String.format(\"SELECT * FROM users WHERE user_id=%d\", userId);\n    Result result = this.doSQL(sql)\n    // クエリの実行結果をもとにユーザーオブジェクトを作って返す\n  }\n}

継承を使ったこの実装だと、UserRepository はDatabaseを継承しているのでDatabaseと同等の振る舞いをできるようになります。\nが、そのことによっていくつか不自然な点が生じてしまいます。

継承によって生じた歪み

継承によって、UserRepositoryは「特定のユーザーを取得する」という本来持たせたかった役割の他に、Databaseの持つ「DB との接続状態の保持や、DB\nへの SQL\nクエリ送信」といった役割も獲得してしまっています。これは単一責務の原則\nに反することになります。\n本来 UserRepositoryからすると、Databaseは DB 接続のための単なるツールとして使いたいだけで、Database自身になりたいわけではありません。

1 つのクラスが複数責務を持ってしまうとどうなるか

継承などによって 1 つのクラスが複数の責務を持ってしまうと、以下のようなデメリットが生じる場合があります。

とある責務を期待してそのクラスを使いたいときに、期待していない機能までくっついてくることになり、クラスの再利用性が低くなる。
単体テストがしずらくなる。\n
- 今回の例だと、DB との接続機能だけをモックしてテストするということが困難^[1]なため、UserRepository のテストのためには実際の DB\nを用意しなくてはいけない。
- 1\nつの操作に対して複数の責務それぞれから起因する仕様が同時に絡んでくることになり、それらの責務を独立してテストできる場合に比べてテストケースが膨らむ。m + n\nケースで良かったところが、m × nケースになったりする。
\n
親クラスがパブリックメソッドを持つような場合、それらのメソッドは子クラスのメソッドとしても呼び出せるようになってしまう。今回の例だと、「ユーザーの取得」とは直接は関係のない\nDB 操作のメソッドもUserRepositoryの利用側が使えるようになり、UserRepositoryが意図とは異なる使い方をされてしまう可能性が生じる。

UserRepositoryとDatabaseのように 期待される役割が異なっている 2 つのクラス間で継承関係を持つと、上記のようにいくつか不自然な点が出てしまいます。\nそういう場合は代わりに委譲を使うのが適していると言えます。

委譲を使って書き直した例

Databaseは先程と同じ実装のままで、UserRepositoryが変更になります。

class UserRepository {\n\n  Database database;\n\n  UserRepository(Database database) {\n    // UserRepositoryのインスタンス生成時にDatabaseのインスタンスをセット\n    this.database = database;\n  }\n\n  User getUser(int userId) {\n    String sql = String.format(\"SELECT * FROM users WHERE user_id=%d\", userId);\n    Result result = this.database.doSQL(sql)\n    // クエリの実行結果をもとにユーザーオブジェクトを作って返す\n  }\n}

継承はせず、Databaseのインスタンスを保持しておいて、必要に応じてそれを呼び出す(委譲)ようになっています。\nDatabaseのインスタンスは、UserRepositoryのオブジェクト生成時のコンストラクタなどで渡すようにします。

UserRepositoryはDatabaseを継承していないのでDatabaseとしては振る舞えず、DB 接続ロジックなどの実装についてもよく知りません。DB のデータ\n⇔User オブジェクトの変換ロジックにのみ責任を負っています。\nこのように、移譲を使うことで単一責務の原則を守ることができ、前述した継承を用いた際のデメリットについても解消できます。\n「期待される役割が異なっている」クラスの機能を利用したい際は、継承ではなく委譲を用いるのが適切と言えます。

継承の使いどき

逆に「子には親と同じ役割が期待される」場合には継承が適しています。

たとえば、Car(車)クラスとElectoricCar(電気自動車)クラスを考えます。\nCarのほうがElectoricCarよりも意味が広く抽象度は高いですが、Carを利用するときもElectoricCar\nを利用するときも「加速する/減速する」「窓を開ける/閉める」といった基本的な動作は共通して可能であることが期待されます。\n「電気自動車を運転する」ことを、「車を運転する」と言い換えても間違いではないように、CarとElectoricCar\nに期待される役割は基本的な部分では一緒であると言えます。

このような場合に委譲を使うと以下のようになります。

継承を使うべき場面で委譲を使った例

class Car {\n\n  void SpeedUp() {\n    // ...\n  }\n\n  void OpenWindow() {\n    // ...\n  }\n\n  // ...\n}

class ElectoricCar {\n\n  Car car;\n\n  void SpeedUp() {\n    car.SpeedUp();\n  }\n\n  void OpenWindow() {\n    car.OpenWindow();\n  }\n\n  // ...\n\n  // 電気自動車特有のロジック\n  void Charge() {\n    // ...\n  }\n}

加速や減速、窓の開閉など、Carの持っている機能の数だけElectoricCarにボイラープレートコードが増えていきます。Car\nに「ライトを点ける」動作が増えた場合にはElectoricCarにも変更を加えなくてはいけません。新たにHybridCar\nを増やそうとしたりすると目も当てられない感じになっていきます。\nまた、2 つのクラスは継承関係に無いので、ダックタイピングを許さないような言語だとこのままではElectoricCarをCarとして扱うこともできません。

継承を使って書き直した例

Carは先程と同じ実装のままで、ElectoricCarが変更になります。

class ElectoricCar extends Car {\n\n  // 電気自動車特有のロジック\n  void Charge() {\n    // ...\n  }\n}

当然といえば当然ですが委譲を使った際と比べて圧倒的にスッキリします。Carに新たなメソッドが増えるなどの変更が入っても基本的にはElectoricCar\nに変更を入れる必要はありません。継承関係を持っているためElectoricCarはCar型としても振る舞えます。\n「子には親と同じ役割が期待される」場合は、委譲ではなく継承を用いるのが適切と言えます。

ここまでのまとめ

子に親と同じ役割が期待される場合、親と同様に振る舞えるようになる継承を使うのが良い
子に親と同じ役割が期待されない場合、子にとって親は単なるツールである可能性が高いため委譲を使うのが良い

インターフェースの使いどころ

UserRepositoryについて再び考えると、極端な話UserRepositoryの利用側は、user\nさえ取得できればそれで良くて、その裏側にあるのがデータベースだろうが、.txtファイルに保存されていようが、オンメモリだろうがなんだって良いはずです。\nこういう「裏の実装は複雑な状態などを取りうるかもしれないが、使う側としては目的が達成できれば何でもいい」場合はインターフェースの出番であることが多いです。\nそこで、IUserRepositoryという「ユーザーを取得・保存する」役割のインターフェースを作り、UserRepositoryがIUserRepository\nを実装するようにしてみます。

interface IUserRepository {\n\n  User getUser(int userId);\n\n  void saveUser(User user);\n}

class UserRepository implements IUserRepository {\n\n  Database database;\n\n  UserRepository(Database database) {\n    this.database = database;\n  }\n\n  User getUser(int userId) {\n    String sql = String.format(\"SELECT * FROM users WHERE user_id=%d\", userId);\n    // ...\n  }\n\n  // ...\n}

UserRepositoryの利用側のロジックは例えば以下のようになります。

class SomeApplicationService {\n\n  IUserRepository userRepository;\n\n  void changeUserEmail(String email) {\n    User user = userRepository.getUser(userId);\n    user.setEmail(email);\n    userRepository.saveUser(user);\n  }\n}

IUserRepositoryはインターフェースのため、実装に関して全く言及をしていません。そのため、\nIUserRepositoryを利用しているSomeApplicationService側としては、\n「とにかく user が取得できることを期待しており、実装は問わない（実装の違いによってSomeApplicationService\nが影響を受けることはない）」ということをコードで表明していることになります。\nインターフェースは、何を公開し、何を隠すべきか？ということを明示的に定義し、それを強制させることができるというのが大きな魅力です。

インターフェースの恩恵

インターフェースIUserRepositoryは、DB の接続、状態管理、難しい SQL クエリといった色々な辛さがある外部世界をフィルタリングし、「なんか知らんけど userId を投げるといい感じに user を返してくれるし、user を投げるといい感じに user を保存してくれる」という、キレイで抽象的な世界だけを見えるようにしてくれている\nと言えます。

インターフェースを挟むことで、SomeApplicationServiceはUserRepositoryへの依存から開放されています。\nこのことによって、もしUserRepositoryの内部ロジックに何らかの大規模な変更が入ったとしても、仮に DB が MySQL から NoSQL\nに変わったとしても、インターフェースが変わらない限りは、SomeApplicationServiceまで連鎖的に変更が波及するようなことはありません。

この性質はテストの際にも大いに役立ちます。例えばSomeApplicationServiceのテスト用にIUserRepository\nを実装したインメモリのInMemoryUserRepository\nを用意しておいて、テストのときだけそれに差し替えるといったことも可能となるため、よりテストが容易になります。\n同じ要領で、インターフェースを使うと、たとえば「ユーザーにメールを飛ばす」といったクラスを、テストのときだけは「送っているように見えて実際には何もしない」クラスに差し替えるようなことも可能です。

インターフェースの重要性

インターフェースは、大規模な開発においては非常に重要な役割を果たします。\nインターフェースだけきちんとしてればその内部実装はまぁある程度雑でも案外困らないな、というのが最近の自分の考えです。\n逆に、初期にインターフェースの設計をミスると、いざ改修が必要になった時には既に手遅れになっているような場合も多く、その場合は大いなる苦しみを伴いながら作りかえを行うことになります。\nインターフェースの設計がその後のシステムの保守性・堅牢性の明暗を分けると言っても過言では無いため、インターフェースを設計するときは、抽象度は本当に適切なのか？余計な情報まで受け取ったり渡したりしてしまってないか？など、慎重に考えるとよいです。

インターフェースという概念

ここまで、インターフェースと言った際になんとなく Java の interface\nを意識して書いてきましたが、ダックタイピングが可能な言語ではわざわざ実装と別にインターフェースクラスを定義する必要性が薄い場合もあります。また、Java の\ninterface のような言語機能がない言語も存在するかと思います。\nただ、そういった場合でもインターフェースの重要さは変わらないと考えます。インターフェースの本質は、「どういう情報を公開情報としてクラスやオブジェクト同士がコミュニケーションを取るか」という点であり、そのことについて思考の余地がある言語であればインターフェースについて扱っていることになります。\nそこにある違いは、インターフェースという概念を具現化した言語機能が明示的に存在するか否かというだけであり、インターフェースの本質的な概念はプログラミング言語にかかわらず普遍的に存在し、とても大事な概念であるという点については変わりません。

おわりに

自分なりに継承/委譲/インターフェースについて解説してみました。\nわからない点や質問などあればぜひコメントいただけると嬉しいです。

\n
実態としてはこの表現はあまり正しくなく、例えば Java なんかはテスト用のモックライブラリを使うと好き勝手にメソッドをモックできるのであまり困らない。 ↩
\n

",{"_8":69,"_10":11,"_12":11,"_13":14,"_15":70,"_17":71,"_19":-7,"_21":72,"_23":73},"replaced-blog-with-gatsbyjs","ブログをGatsbyJSに載せ替えました","2018-08-04","GatsbyJS\nGatsbyJS\n今までブログはJekyllで生成してましたが、GatsbyJS に移行してみました。\nGatsbyJS を使うと React.js ベースの静的 PWA サイトを生成できます。\n...","

GatsbyJS

今までブログはJekyllで生成してましたが、GatsbyJS に移行してみました。

GatsbyJS を使うと React.js ベースの静的 PWA サイトを生成できます。\nBlazing-fast static site generator と謳っているだけあって、ページ遷移が爆速になったので満足です。

今までどおりホスティングは GitHub Pages ですが、GitHub Pages がいつの間にか独自ドメインの HTTPS をサポートするようになってたので、今まで使っていた\nCloudflare の SSL 証明書から GitHub Pages のものに移行しました。

",{"_8":75,"_10":11,"_12":11,"_13":14,"_15":76,"_17":77,"_19":-7,"_21":78,"_23":79},"perl-mousex-types-enum","MouseX::Types::Enum - PerlでJavaのenum(列挙型)のようなクラスを実現するモジュール","2018-05-20","MouseX::Types::Enum\nJava のenum型のように、フィールドやメソッドを持つ列挙型を Perl でも使いたくなったので、MouseX::Types::Enumというモジュールを作りました。...","

MouseX::Types::Enum

Java のenum型のように、フィールドやメソッドを持つ列挙型を Perl でも使いたくなったので、MouseX::Types::Enumというモジュールを作りました。

Dependencies

Mouseの拡張モジュールとして作ったので、Mouse に依存しています。

使用例

MouseX::Types::Enumでは、Java の列挙型のように各列挙定数がメンバ変数やメソッドを持つことが可能です。\n使用例を以下に示します。この例では、

APPLE, ORANGE, BANANAという 3 つの列挙定数を定義しました。use句でMouseX::Types::Enum\nを呼び出す際に、定義したい列挙定数の配列を渡してあげます。
列挙定数にname, color, has_seedというメンバ変数を定義しました。メンバ変数の定義には Mouse の文法であるhasが使えます。
make_sentenceというメソッドを定義しました。引数やメンバ変数をもとに文字列を組み立てて返します。

package Fruits;\n\nuse Mouse;\nuse MouseX::Types::Enum (\n    APPLE  => { name => 'Apple', color => 'red' },\n    ORANGE => { name => 'Cherry', color => 'red' },\n    BANANA => { name => 'Banana', color => 'yellow', has_seed => 0 }\n);\n\nhas name => (is => 'ro', isa => 'Str');\nhas color => (is => 'ro', isa => 'Str');\nhas has_seed => (is => 'ro', isa => 'Int', default => 1);\n\nsub make_sentence {\n    my ($self, $suffix) = @_;\n    $suffix ||= \"\";\n    return sprintf(\"%s is %s%s\", $self->name, $self->color, $suffix);\n}\n\n__PACKAGE__->meta->make_immutable;

use Fruits;\n\nFruits->APPLE == Fruits->APPLE; # 1\nFruits->APPLE == Fruits->ORANGE; # ''\nFruits->APPLE->to_string; # 'APPLE'\n\nFruits->APPLE->name; # 'Apple';\nFruits->APPLE->color; # 'red'\nFruits->APPLE->has_seed; # 1\n\nFruits->APPLE->make_sentence('!!!'); # 'Apple is red!!!'\n\nFruits->enums; # { APPLE  => Fruits->APPLE, ORANGE => Fruits->ORANGE, BANANA => Fruits->BANANA }

メンバ変数が不要な場合の宣言方法

メンバ変数が不要な場合は、以下のようにも宣言できます。

package Day;\n\nuse MouseX::Types::Enum qw/\n    Sun\n    Mon\n    Tue\n    Wed\n    Thu\n    Fri\n    Sat\n/;\n\n__PACKAGE__->meta->make_immutable;

use Day;\n\nDay->Sun == Day->Sun; # 1\nDay->Sun == Day->Mon; # ''\nDay->Sun->to_string;  # 'APPLE'\nDay->enums; # { Sun => Day->Sun, Mon => Day->Mon, ... }

備考

Java のenum型はordinal()というインスタンスメソッドを持っており、各列挙定数から呼ぶとその列挙定数の序数(ユニークな数値)\nを返してくれます。\nしかし、序数は列挙定数の宣言順に決まるため、列挙定数の宣言順が変化するとそれらに対応する序数も変わってしまうという性質があります。\nそのため、ordinal()\nで取得した序数がどこかで永続化された後に列挙定数の宣言順を入れ替えたり、新たな宣言を既存の列挙定数の宣言の間に追加したような場合に、序数に不整合が生じてしまうことが懸念されます。

この挙動は予期せぬバグを引き起こす可能性があるため、MouseX::Types::Enumではordinal()\nメソッドや序数の概念は定義しないことにしました。\nコードが増えることとのトレードオフではありますが、数値 ⇔ 列挙定数のマッピングは明示的にコード内のどこかに書くのが良いのではないかと考えています。

",{"_8":81,"_10":11,"_12":11,"_13":14,"_15":82,"_17":83,"_19":-7,"_21":84,"_23":85},"ideavim-getting-started","IntelliJ(Android Studio)のVimプラグイン「IdeaVim」の使い方と設定","2017-12-25","この記事はJetBrains Advent Calendar 2017\nの最終日分の投稿です。前日まで空いていたため、滑り込みで参加させていただきました！\nIdeaVim\nIdeaVim\nGithub: ...","

この記事はJetBrains Advent Calendar 2017\nの最終日分の投稿です。前日まで空いていたため、滑り込みで参加させていただきました！

IdeaVim

IdeaVim\nGithub: JetBrains/ideavim

IdeaVim は、IntelliJ や Android Studio などの JetBrains 系列の IDE で使える Vim プラグイン です。このプラグインを導入することで\nIntelliJ などを Vim っぽく操作できるようになります。
\nリポジトリ名を見るとわかるように、JetBrains の公式プラグインです。IntelliJ の初回起動時にもオススメされます。

※ 以下、IntelliJ を例にして進めますが、JetBrains 系列の IDE であれば基本的に一緒なはずですので自身の使っているものに置き換えてお読みください。

雰囲気

※キーマップはカスタマイズ済です。

$\"overview\"$

なぜ IdeaVim を使うか

個人的には、IntelliJ と Vim のそれぞれに対して以下の点に良さを感じています。

IntelliJ: 補完、コードジャンプ、リファクタ機能などの強力さ、またそれらの設定の容易さ
Vim: テキストエディタとしての編集操作の効率の良さ、キーマップやモードの概念

IdeaVim プラグインを使うと、\nIntelliJ を Vim のようなキーマップとして操作できるようになり、かつ、そのキーマップで IntellIJ の機能を呼び出すことも可能です。\nそのため、上記の双方の利点を同時に享受することができると考えています。細かい部分の挙動などはまだまだ本家 Vim との差分もありますが、\n自分のような比較的ライトな Vim ユーザーが Vim に求めている機能については、IdeaVim はその多くをカバーできているのではないかと思います。

この記事では IdeaVim の機能や設定方法の説明を通じて、IdeaVim の良さをお伝えしていきます。

IdeaVim がサポートしている機能の一例

細かい機能まで列挙するのは難しいため、普段自分がよく使う機能に絞ってその対応状況をまとめました。
\n行いたい操作が未実装だったという経験は筆者は無いですが、これは vim のヘビーユース度合いにもよるのかなとも思います。

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

機能	対応状況
モード	ノーマルモード、インサートモード、ビジュアルモードが存在
モーション	ヤンク(`y`), 削除(`d`), 変更(`c`), Undo(`u`), Redo(`Ctrl-r`),テキストオブジェクト操作(`ciw`,`vi(`, ...) などなど
検索	Vim と同様に`/`による検索が可能、`:set incsearch`によるインクリメンタルサーチも
置換	Vim と同様に`:s`,`:%s`,`:'<,'>s`などで正規表現による置換が可能
コマンド	`:w`, `:q`, `:tabnew`, `:split`, 一部`:set`オプションなどなど
設定・キーマップ	`.vimrc`と同様の文法で各種`map`や一部`set`オプションを`.ideavimrc`に記述可能また、IntelliJ の機能をキーマッピングすることも可能(後の章で詳しく説明)
マクロ	利用可能
レジスタ	利用可能
その他	`:set surround`することでvim-surroundを再現した機能を利用可能

より詳しく知りたいという方は、\nGitHub のレポジトリ\nの README などご覧になってみてください。

IdeaVim のインストール方法

通常の IntelliJ プラグインと同じく、[Preferences] > [Plugins]からインストールできます。
\nインストール後に IntelliJ を再起動すると IdeaVim が有効になります。

$\"Install$

EAP ビルド

IdeaVim のアップデートは現状だと年に数回程度しか行われていません。\nIntelliJ 内から[Settings] > [Plugins] > [Browse Repositories] > [Manage Repositories]に下記の URL\nを追加することで、まだ正式にはリリースされていない EAP^[1]ビルドの IdeaVim を利用することができます。

https://plugins.jetbrains.com/plugins/eap/ideavim

不便だと思っていた不具合が EAP ビルドでは直っているみたいなケースも少なくないので、筆者は常に最新の EAP ビルドを利用しています。

IdeaVim の設定方法

.ideavimrc

IdeaVim では、.ideavimrcというファイルに設定を記述してホームディレクトリに設置しておくことで、IntelliJ 起動時にその設定を読み込んでくれます。
\n.ideavimrcには 本家 Vim の.vimrcと同様、各種 map コマンドや set コマンドを記述することが可能です。

利用できるset\nコマンドのオプション一覧はこちらにあります。
\nまた、IdeaVim 独自のオプションとしてset surroundというものが存在し、本家 Vim\nで言うところのvim-surroundを一部再現した機能が利用可能となっています。

Vim と IdeaVim のキーマップの一元管理

mapコマンドが本家 vim と同じ記述で利用可能なため、nnoremap L $などとといったような基本的なキーマップは、通常の.vimrc\nから切り出して.vimrc.keymapという独立したファイルにしておき、.vimrcと.ideavimrcそれぞれからsource\nコマンドを使って読み込むのがおすすめです。
\nこうすることで、Vim と IdeaVim で共通して設定しておきたいような基本的なキーマップを一元管理できるようになります。これは.ideavimrcが.vimrc\nとほとんど同じ文法で記述できるからこそのメリットですね。

.ideavimrc

\" 切り出しておいた共通keymapファイルをロード\nsource .vimrc.keymap\n\n\" IdeaVim特有の設定はここに書き足していく

.vimrc.keymap

\" IdeaVimとvimどちらでも共通のキーマップはここに書く\n\nnnoremap L $\nnnoremap H ^\nnoremap ; :

参考までに、自分の.ideavimrcと.vimrc.keymapも以下に載せておきます。

.vimrc.keymap
.ideavimrc

IntelliJ の機能をキーマッピング

基本的なキーマップは.vimrc.keymapに切り出したので、.ideavimrcには IdeaVim 特有の設定が残ることになります。\n筆者の.ideavimrcを見てもらうと、たとえば以下のように、nnoremap XXX :action YYYという記述が多くあることがわかります。

nnoremap gd :action GotoDeclaration

:actionは IdeaVim オリジナルのコマンドで、このコマンドを使うと IntelliJ の機能を呼び出すことができます。GotoDeclarationは IntelliJ\nの機能の一つであり、「カーソル上の変数や関数の定義元に飛ぶ」という操作です。
\nつまり上記の 1 行は、「gdをキーストロークするとカーソル上の変数や関数の定義元に飛ぶ」という設定となります。\nこのように、IdeaVim では:actionコマンドで IntelliJ の機能(アクション)を呼び出して使用することができます。IntelliJ\nの強力なコードジャンプやリファクタ機能についても、Vim のキーマップ的な設定や呼び出しが可能ということになります。
\nカーソルの移動などの単純な操作から、リファクタやコードジャンプ等のもっと高次な機能まで、IntelliJ が API\nとして提供しているアクションや、インストールしているプラグインで定義されているアクションは全て呼び出せるようです。
\nこのアクション呼び出し機能によって、IdeaVim と IntelliJ の連携の自由度が格段に上がりました。以下に、筆者が高頻度で使うおすすめのアクションの一例を載せておきます。

設定しておくと幸せになれそうなアクションの一例

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Action	概要
SearchEverywhere	任意のクラス・関数・ファイルを検索・ジャンプ
FindInPath	開いているプロジェクト内の任意の文字列を検索(grep 的な)
FileStructurePopup	編集しているファイル内の任意の関数を検索・ジャンプ
GotoDeclaration	カーソル上の関数や変数の定義元にジャンプ
GotoSuperMethod	カーソル上の関数のスーパーメソッドにジャンプ
GotoImplementation	カーソル上のインターフェースの実装にジャンプ
JumpToLastChange	最後に編集した箇所にジャンプ
FindUsages	カーソル上の関数や変数の使用箇所一覧を表示
RenameElement	カーソル上の関数や変数の rename
ReformatCode	コードの整形
CommentByLineComment	コメントアウト
ShowIntentionActions	クイックフィックス
GotoAction	なんでも呼び出し

設定例

nnoremap ,e :action SearchEverywhere<CR>\nnnoremap ,g :action FindInPath<CR>\nnnoremap ,s :action FileStructurePopup<CR>\n\nnnoremap gd :action GotoDeclaration<CR>\nnnoremap gs :action GotoSuperMethod<CR>\nnnoremap gi :action GotoImplementation<CR>\nnnoremap gb :action JumpToLastChange<CR>\n\nnnoremap U :action FindUsages<CR>\nnnoremap R :action RenameElement<CR>\n\nnnoremap == :action ReformatCode<CR>\nvnoremap == :action ReformatCode<CR>\n\nnnoremap cc :action CommentByLineComment<CR>\nvnoremap cc :action CommentByLineComment<CR>\n\nnnoremap <C-CR> :action ShowIntentionActions<CR>\n\nnnoremap ,a :action GotoAction<CR>\nvnoremap ,a :action GotoAction<CR>

※ ビジュアルモードでの範囲選択に対する:actionコマンドの適用については、バージョン 0.49.3 以降で利用可能です。2018 年 2 月現在では EAP\nビルドの最新版で利用できます。

アクションの検索

「自分がいつも使ってるあの機能のアクション名を知りたい」といった際に、直接的に探す方法は無いのが現在の難点です。\nただ、下記の手順を踏むとだいたいはそこまで苦労せずに見つかるかと思います。

まず、IntelliJ の[Preferences] > [Keymap]から、設定したい機能を探します。その機能に IntelliJ\nデフォルトで割り当てられているショートカットキーから探すと早いです。

$\"keymap\"$

見つかったら、その機能の名前を確認しておきます。

次に、:actionlistコマンドを使うことで、IdeaVim で呼び出し可能なアクションの一覧を確認することができます。また、:actionlist XXX\nとすると、名前にXXXを含むアクションを検索することもできます。

$\"actionlist\"$

さきほど確認した機能名とアクション名は似ていることが多いため、機能名の一部や、その機能を連想するような単語（検索関連の機能ならsearch\nとか）で検索して、それっぽいのがヒットしたら試してみる、というのを当たるまで繰り返します。
\n検索結果には現在そのアクションに割り当てられているショートカットキーも表示されるため、それも参考にすると見つけやすいかと思います。\n(ショートカットキーでアクションの検索ができるようになってくれると便利そうですね…)

2019/04/29 追記: 出していたプルリク\nがマージされたので、v.0.52 からはショートカットキーでもアクションの絞り込みが可能となる見込みです。

おわりに

本記事では IdeaVim の機能や設定方法について紹介しました。
\nIdeaVim はまだ発展途上な部分もありますが、IntelliJ の強力な機能をそのまま活かしつつ Vim\nの操作性を取り入れることができる素晴らしいプラグインだと思います。
\nIdeaVim を使いこなして、快適な IntelliJ ライフを送りましょう！

\n
Early Access Program ↩
\n

",{"_8":87,"_10":11,"_12":11,"_13":14,"_15":88,"_17":89,"_19":-7,"_21":90,"_23":91},"first-commit","first commit","2017-10-15","Jekyll + GitHub Pages\nでブログを作ってみた。\n\n10 分程度あればブログを公開するところまで持ってこれて、その後のカスタマイズの自由度も高そう\n記事を Markdown で書ける...","

Jekyll + GitHub Pages\nでブログを作ってみた。

10 分程度あればブログを公開するところまで持ってこれて、その後のカスタマイズの自由度も高そう
記事を Markdown で書ける
記事を Git でバージョン管理できる

など、色々と嬉しい。\n普段の学習がインプットに偏り気味なので、アウトプットの場としてブログを活用していきたい。\nちなみに、Jekyll のテーマはTale をベースにした。

","root","actionData","errors"]