Windows 環境で Blue Yeti のマイクのモニタ (入力フィードバック) が聞こえない場合の設定 / モニタをオフにする方法

問題 - モニタ音声 (フィードバック音声) が聞こえない

USB 接続で高音質な音声入出力が可能な Blue Yeti Microphone。3.5 mm のステレオミニジャックがついており、PC 等の出力デバイスの音を聞きながら 遅延ゼロで入力音声をミックスしてモニタリングできる機能 が非常に便利な使い勝手のいいマイクで、podcast をオンラインで収録したり YouTube 配信したりゲームのボイスチャットに利用したりされています。

Blue Microphones Yeticaster Yeti Radius III Compass イエティ キャスター ブロードキャスト セット BM400C 国内正規品 2年間メーカー保証

↓後継機種

Blue Microphones Yeti Nano USB コンデンサー マイク Shadow Gray イエティ ナノ シャドー グレー BM300SG 国内正規品 2年間メーカー保証

Blue Yeti で検索すると一般的にこの 入力音声をモニタリングする機能はオフにできない と書いてあります。ですが、Windows で場合によってはこのモニタリング音声が聞こえない場合があります。ヘッドホンをした状態で自分の声がフィードバックされないとしゃべるのが非常に困難で問題になります。

解決法 (or Blue Yeti のモニタ音声をオン / オフにする方法)

ポイントは 録音デバイスではなく再生デバイスのプロパティを操作すること です。録音デバイスの入力レベルを操作しても モニタの音量は変更できません。

1. タスクトレイのサウンドインジケータを右クリックしてサウンドの設定を開く

2. サウンド コントロール パネル を開く

3. 再生デバイスの Yeti Stereo Microphone のプロパティを開く

4. レベルタブを開くとマイクの項目があるのでここでモニタの音量調節が可能

以上です。お疲れさまでした。

Blue Microphones Yeticaster Yeti Radius III Compass イエティ キャスター ブロードキャスト セット BM400C 国内正規品 2年間メーカー保証

Blue Microphones Yeti Nano USB コンデンサー マイク Shadow Gray イエティ ナノ シャドー グレー BM300SG 国内正規品 2年間メーカー保証

型クラスの原点 How to make ad-hoc polymorphism less ad hoc を読んだ話

以下の記事は 2018 年 2 月 に Qiita に投稿した記事の移植です

pixivFANBOX にも投稿しています。ご支援頂ける場合はよろしくお願いいたします。

www.pixiv.net

---

オレオレ型クラスの話をやめろ。原典に当たれ。ということで、Haskell に型クラスの導入を提案した論文とされる Philip Wadler. How to make ad-hoc polymorphism less ad hoc を読んだのでそれをまとめる話です。

型クラス導入の目的

2 つの多相

多相にはアドホック多相、パラメトリック多相の 2 つの種類がある。

アドホック多相

アドホック多相は、ある関数が受け入れる型によって 型に応じた振る舞いをするような多相 。典型的なのは関数や演算子のオーバーロード。

3 * 3
3.14 * 3.14

同じ演算子 * だけど、整数型と浮動小数点数型どちらでも使えています。

パラメトリック多相

名前の通り、型を表すパラメータを取ることによって 型によらない共通の振る舞いをする多相 。典型的なのは length 関数。

 length :: [a] -> Int

配列であれば中の型に関係なく使うことができる。

Hindley/Milner 型システムと多相

パラメトリック多相については Hindley/Milner 型システムがよく扱えるということで広く用いられていたけど、アドホック多相については良い手法がなかった(ためアドホック多相が導入されていなかった)。

この論文では、型クラスってものを導入して Hindley/Milner 型システムを拡張することでオーバーロード = アドホック多相ができるようにするよ。

アドホック多相の制約

算術演算の場合

整数型と浮動小数点数型にオーバーロードされた乗算演算子 * を考える。この演算子 * はアドホック多相にできるけど、それを利用した関数はアドホック多相にできない。

-- これはできない
square x = x * x

square 3
square 3.14

関数自体を Int -> Int と Float -> Float にオーバーロードさせることもできるけど

squares (x, y, z) = (square x, square y, square z)

みたいな関数を考えるとき、組み合わせが爆発する。

同値評価の場合

同値性を評価する場合にも同じような問題がある。

-- これはできない
member [] y = False
member (x:xs) y = (x == y) \/ member xs y

member [1, 2, 3] 2
member "Haskell" 'k'

そこで同値性についてはパラメトリック多相で対応するアプローチが試された。

(==) :: a -> a -> Bool
member :: [a] -> a -> Bool

ただ、この方法だと関数型や抽象データ型などの同値評価ができない型を渡しても静的に型エラーを起こすことができず、実行時に評価しようとしてエラーすることになってしまった。

そこで同値評価できる型だけに同値性評価できるように制約を書ける方法が Standard ML で導入された。

(==) :: a(==) -> a(==) -> Bool
member :: [a(==)] -> a(==) -> Bool

この方法では、関数型や抽象データ型などを member 関数に渡すと型エラーにすることができるようになったけれど、Standard ML では参照型の同値性評価は他の型の同値性評価と異なるように設計されていたので、同値性評価する型の峻別のためにランタイムシステムを構築する必要が出てきてしまった。

これに対してオブジェクト指向では、データに対して実装を与えるメソッドのポインタの集合 = 辞書 を持っているので、同値性評価関数に渡ってくる引数のいずれかの辞書に含まれる同値性評価のメソッドを用いて評価することができる。

このメソッドの集合をデータと一緒に渡すのがいい感じだから、型クラスでもこのアイディアが背景としてあるよ。

型クラスの導入例

まず、型クラスを実際に導入したコード例を示す。

class Num a where
    (+), (*) :: a -> a -> a
    negate   :: a -> a

instance Num Int where
    (+)    = addInt
    (*)    = mulInt
    negate = negInt

instance Num Float where
    (+)    = addFloat
    (*)    = mulFloat
    negate = negFloat

square            :: Num a => a -> a
square x          = x * x

squares           :: Num a, Num b, Num c => (a, b, c) -> (a, b, c)
squares (x, y, z) = (square x, square y, square z)

型クラスの定義

このコードで型クラス Num が class キーワードによって定義されている。Num 型クラスは (+)、(*)、negate が定義されている型 a が所属している。

続いて、instance として型 a を具体化した実装を与えている。これらは Num の要求する関数を実装しているか型検査される。たとえば

addInt :: Int -> Int -> Int

が検査される。

型クラス制約の利用

型クラスの導入によって、前述の square や squares が実装できた！

ここで square の型は Num a => a -> a となっているが、Num a => によって型 a は Num が実装されていることが要求されている。この square は次のように利用できる。

square 3
square 3.14

そしてもちろん

square 'x'

は Num Char の instance が存在しないからコンパイル時に静的に型エラーにできる！

アドホック多相が実現できていることが確認できる。

型クラスの 変換

実際にはこの型クラスの仕組は、コンパイル時に型クラスを用いない形に変換されて Hindley/Milner 型システムで扱えるようになる。つまりは型クラスはある種の糖衣構文になっている。

上記のコード例を型クラスを用いない形に変換したものが下記のコード。

data NumD a = NumDict (a -> a -> a) (a -> a -> a) (a -> a)
add (NumDict a m n) = a
mul (NumDict a m n) = m
neg (NumDict a m n) = n

numDInt     :: NumD Int
numDint     =  NumDict addInt mulInt negInt

numDFloat   :: NumD Float
numDFloat   =  NumDict addFloat mulFloat negFloat

square'          :: NumD a -> a -> a
square' numDa x  =  mul numDa x x

squares'  :: (NumD a, NumD b, NumD c) -> (a, b, c) -> (a, b, c)
squares' (numDa, numDb, numDc) (x, y, z)
          =  (square' numDa x, square' numDb y, square' numDc z)

class 宣言の代わりに、class で定義されていた関数の型を持つデータ型の辞書 NumDict とそれらのメソッドにアクセスするための関数が定義されている。¹

instance で宣言されていた部分は、上記の NumD a 型のデータ型の値として変換される。

numDInt     :: NumD Int
numDInt     =  NumDict addInt mulInt negInt

やってることは単純で、NumDict 値コンストラクタで値を埋めているだけ。Float も同じ。こうやって作った辞書をもとに演算は以下のように書き換えられる。

x + y     -->  add numD x y
x * y     -->  mul numD x y
negate x  -->  neg numD x

ここで引数に渡っている numD は適当な演算の入った辞書。

ここからが型クラスのマジックで、適当な演算の入った辞書が型によって自動的に挿入される！

3 * 3       -->  mul numDInt 3 3
3.14 * 3.14 -->  mul numDFloat 3.14 3.14

これによって型によって処理を切り替えるというアドホック多相が実現された。

square'          :: NumD a -> a -> a
square' numDa x  =  mul numDa x x

square 3     -->  square' numDInt 3
square 3.14  -->  square' numDFloat 3.14

力尽きたので Eq 型クラスからの話(型クラスの継承等)については割愛。変換のルール自体は上記に示されたもの。あとで書くかもしれない。

まとめ

というわけで、型クラスはオブジェクト指向でない静的型付け言語、特に Hindley/Milner 型システムを持った言語において、Hindley/Milner 型システムを用いてアドホック多相を実現する手法として導入されました。その型クラスのお手本になったのは実はオブジェクト指向言語のサブタイピング多相であり、オブジェクト指向における関数ポインタの辞書を文字通り Haskell におけるデータ型の辞書として読み替えて この辞書を型に応じて挿入する というものでした。

型クラスの原典に当たって、これで一安心ですね。

実は、全く同様の実装が Scala で借用されており、Haskell における型クラスが脱糖されたような状態で書けるようになっています。また、最近登場した Swift や Rust でも型クラスと似たようなことができるようになっています。おもしろいですね。

おしまい

参考

Philip Wadler. How to make ad-hoc polymorphism less ad hoc Instances and Dictionaries - School of Haskell

---

1. 現在の GHC の実装ではレコードによって一括定義するようにしているらしい data NumD a = NumDict {add :: a -> a -> a, mul :: a -> a -> a, negate :: a -> a} みたいな↩

【Haskell や圏論が出てこない】Scala で型クラスを完全に理解した話

以下の記事は 2018 年 2 月 に Qiita に投稿した記事の移植です

pixivFANBOX にも投稿しています。ご支援頂ける場合はよろしくお願いいたします。

www.pixiv.net

---

TL;DR

結論から。

型クラスはちょっとすごいオーバーロード であり 型に対して静的にメソッドを挿入する方法 です。

この記事は

• Haskell や 圏論等の難しそうな知識・議論なしで型クラス概念を具体的に理解する
• 型クラスが実は単なるすごいオーバーロードで、ちょっとした便利なものだと実感できる
• 型クラスとインターフェイスの違い論争で消耗しなくなる
• 型クラスを知っているとなにがオトクなのかわかる
• Haskell 等の高度な抽象化の恩恵を Java 的な慣れ親しんだシンタックスで書ける Scala は便利でたのしいと感じる

ことを目的としています。

対象読者

• 関数型とか型クラスとかモナドとかよく聞くけど全然わからない…でも理解したい気持ちはある
• 型クラスの概念はいろいろ読んでなんとなく分かるけど説明が Haskell ばかりで実感がわかない
• 型クラスがなんなのかはぶっちゃけどうでもいいが、便利なのかどうか、どう便利なのかを知りたい

Scala 自体はわからなくても大丈夫です。

まえおき

最近またにわかに 型クラス が話題になっていました。

モナドや圏論同様、Haskell の神秘じみた概念の一つして定期的に話題になっていて、なんだかすごくてかっこよさそうなんだけれど、そもそも Haskell をよく知らないし、理論色の強い解説が多くなかなかスッキリ消化できない方が多いのではないかと思います。私もその一人です。Haskell とかさっぱりです。

しかし 型クラスが本当に素晴らしいものなら Haskell を使わなくても素晴らしいといえるはず ということで、この記事では Pure Scala で型クラスを具体的に理解することを目指します。

"型クラス" とはなにか

最初に、型クラスそのものではなく、"型クラスという誤解を招きやすい名称" について整理したいと思います。Java や C++ 等にはじまる多くのオブジェクト指向言語では クラス は特別なキーワードとして扱われてきました。そして、それは 型 と呼ばれる概念とほぼ一対一対応しています。

この慣習がまず 型クラス という言葉をわかりづらくしてしまっているように思います。そこで一旦、OOPL での型やクラスという概念を忘れて、本来的な言葉の定義を考え直してみます。

型 は

けい【型】［漢字項目］の意味 - goo国語辞書 - goo辞書 1. 同形のものをいくつも作るとき元になるもの。いがた。「原型・紙型・母型」 2. 基準となる形。タイプ。「型式／定型・典型・模型・類型」

となっており、鋳型等、同じ形をしたものを作るもの・その枠といった意味です。もうちょっとプログラム的に言えば 一定の決まったデータ構造の約束 と言えそうです。

一方 クラス は

Weblio - class (共通の性質を有する)部類、種類、(学校の)クラス、学級、組、(クラスの)授業(時間)、(編物教室などの)講習、クラスの生徒たち、同期卒業生、同年兵

となっており、共通の性質をもった集まり であると言えそうです。

つまり、型クラスとは型のクラス = 似たような性質を持った型の集まり、というふうに読み取ることができ、これは実際型クラスをよく説明する表現になっています。

型クラス = 共通の性質を持った型の集まり

というわけで前置きが長くなりましたが、言葉の意味を明らめたところで実際に型クラスとはどういうもので、型クラスが一体何を実現してくれるのか見ていきたいと思います。

型クラスを見て体験する

まずは、型クラスがどんなコードの見た目をしていて何ができるのかを確認してみます。Scala のコードですが、Scala を知らない人でも雰囲気がつかめれば大丈夫ですので、細かいシンタックスは気にせず見てみてください。

まずは、以下のような仕様の実装について考えます。

sum という List を受け取ってその合計を返す関数を定義したいとします。この際、sum が引数に受け取る型は、ただ 1 つの List[Int] などではなく、合計という概念が適用できる型 を幅広く受け取れるようにしたいでしょう。このように多くの型を受け取れることを「多相」と呼びます。

言い換えると、合計という概念が適用できるある型 A を要素に持つ List[A] を引数に取る多相なメソッド sum を作りたい、です。ここで、型 A は拡張できない or 拡張したくない既存の型とします。

ここでいったん合計という概念の詳細は考えずに、まずは Int と String の2つに対応してみましょう。自然に実装できるでしょうか？

sum メソッドのナイーブな実装

def sum(xs: List[Int]): Int = xs match {
  case Nil => 0
  case head :: tail => head + sum(tail)
}

def sum(xs: List[String]): String = xs match {
  case Nil => ""
  case head :: tail => head + sum(tail)
}

sum(List(1, 2, 3))        // => 6
sum(List("a", "b", "c"))  // => "abc"
sum(List(true, false))    // Kaboom! Can't compile

型クラスがでてくるかと思いきや拍子抜けしたかもしれませんが、実はオーバーロード / アドホック多相で上記の仕様を満たすことができます。簡単にコードの説明をすると

1. 引数の List を match (switch のようなものです) で Nil と それ以外で場合分け
2. Nil だったら受け付ける型のデフォルト値を返す
3. List が要素を持つならその先頭の値 head と List の残りの要素 tail の総和を足す

ということをやっています。

オーバーロードの引数の型として、合計という概念が適用できる型を列挙し、それぞれの実装を与えることで自然に型にそった処理を実現できています。

この実装によって明らかになった性質がいくつかあります。

• 合計という概念が適用できる型を明に列挙することで、それ以外の型で利用しようとした場合は静的にコンパイルエラーにすることができる
• オーバーロードの制約となる型は既存の型であり、既存の型を修正したり拡張したりせずに新たに振る舞いを追加できる
• 合計というセマンティクスは共通だが、型ごとに実装は異なる

同時に、この実装にはいくつか問題を指摘することができるかと思います。

まず、sum(xs: List[Int]): Int と sum(xs: List[String]): String でほとんど実装が重複してしまっています。DRY じゃないですね。

また、今の sum は Int と String のみにしか対応できていません。もちろんこれら以外の合計が適用できる型には対応できていないですし、仮に多くの型のオーバーロードを用意したとしても、 sum の利用者が追加する独自の型に対応することはできません。つまり、拡張性・再利用性が無い状態になってしまっています。

これらの問題を解決して拡張性を得るためには、合計という概念が適用できる型 をきちんと取り扱う必要がありそうです。

そこで少し今の sum の実装を見直してみます。問題点として挙げた 実装の重複 という観点から、Int と String で共通な部分と異なる部分を抽出してみます。

共通な部分は

• リストの要素の たぐり方
• リストが Nil だったときには、引数の型のデフォルト値を返す
• 引数の型同士の加法を利用した合計の実装

異なる部分は

• Int、String それぞれのデフォルト値
• Int、String それぞれの加法の具体的な実装

です。

ここから List に内包される 合計という概念が適用できる型 の条件として 加算が定義できる型 であることが言えそうです。このような加算が定義できる型を Addable な型と呼ぶことにしましょう。そうすると、sum メソッドは Addable な性質を定義できる型の集合 を要素として持つ List を受け入れたいと言えます。

それができる すごいオーバーロード が 型クラス ということになります。

早速上記の仕様の型クラスでの実装をみてみましょう。

sum メソッドの型クラスでの実装

def sum[A](xs: List[A])(implicit addable: Addable[A]): A = xs match {
  case Nil => addable.unit
  case head :: tail => addable.add(head, sum(tail))
}

trait Addable[A] {
  val unit: A
  def add(x: A, y: A): A
}

implicit object AddableInt extends Addable[Int] {
  override val unit: Int = 0
  override def add(x: Int, y: Int): Int = x + y
}

implicit object AddableString extends Addable[String] {
  override val unit: String = ""
  override def add(x: String, y: String): String = x + y
}

sum(List(1, 2, 3))        // => 6
sum(List("a", "b", "c"))  // => "abc"
sum(List(true, false))    // Kaboom! Can't compile

Scala を知らない方は trait や object、implicit 等の見慣れないキーワードが出てきてちょっと混乱するかもしれませんが、落ち着いてオーバーロードの実装と見比べてみると概形が見えてくるのではないかと思います。Scala の説明もしながら、順を追って見ていきます。

まず sum メソッドの実装を 1 ヶ所に集中するために、型パラメータ A を導入しました。

def sum[A](xs: List[A])(implicit addable: Addable[A]): A = xs match {
  case Nil => addable.unit
  case head :: tail => addable.add(head, sum(tail))
}

早速いくつか Scala 特有の記法があるため簡単に補足します。 def はメソッドを定義するキーワードで、def hoge(): Piyo のような形で使います。最後の Piyo が戻り値の型です。Scala ではメソッドのパラメータを複数の パラメータリスト として記述することができます。なので () が 2 つありますが、単に引数が並んでいるだけだと思ってもらって大丈夫です¹。2 個目のパラメータリストにあるキーワード implicit は型クラスを実現する重要な機能で、オーバーロードと同様に 型情報を元にコンパイラが暗黙的に挿入すべき値を解決します。つまり、Addable[A] の型を見て自動的にその型に適合した addable が挿入されます。型によって実際に呼び出すメソッドが決まるオーバーロードそっくりですね。

ここで、あらためて sum の型 A に関する実装について、共通の部分と異なる部分を再確認してみます。

共通な部分は

• リストの要素の たぐり方
• リストが Nil だったときには型 A のデフォルト値を返す
• 型 A 同士の加法を利用した合計の実装

異なる部分は

• 型 A のデフォルト値
• 型 A の加法の実装

です。

sum[A](xs: List[A])(implicit addable: Addable[A]): A メソッドには共通の List のたぐり方が実装されています。対して型 A に共通の振る舞いが sum の次の Addable[A] に定義されています。

trait Addable[A] {
  val unit: A
  def add(x: A, y: A): A
}

trait というのは実装の持てる interface のようなものです。ここには見ての通り、ある型 A のデフォルト値が unit という変数で表され、加法が add(x: A, y: A): A というシグネチャで宣言されています。ここで宣言した Addable = 加算が定義できる 性質が、合計という概念を適用できる型の条件でした。

さて、ここまでで sum に共通な要素を記述することができました。ここからはオーバーロード同様に、合計という概念が適用できる型それぞれについて Addable の実装を与えていきましょう。

implicit object AddableInt extends Addable[Int] {
  override val unit: Int = 0
  override def add(x: Int, y: Int): Int = x + y
}

implicit object AddableString extends Addable[String] {
  override val unit: String = ""
  override def add(x: String, y: String): String = x + y
}

またしても implicit キーワードが出てきましたが、ここまでくればもう分かる通り、この implicit は sum メソッドの引数における implicit とこの実装を紐付けるための目印になっています。オーバーロードでは、共通のメソッド名で異なる引数型であれば自動的にオーバーロードであることがコンパイラに伝わりますが、implicit を利用する場合にはコンパイラに明示的に教えてあげる必要があります。

object というのは シングルトンオブジェクト のことで、Scala では言語組み込みの仕様になっています。object は定義と同時に型の名前でアクセスできる static なクラスのようなものだと思ってください。このシングルトンオブジェクトで、Int、String それぞれの型に固有の処理を実装として与えています。

さて、一通り眺めてきましたが、いまここを読んでいる方は上記のシングルトンオブジェクトの実装がオーバーロードのように見えてきているのではないでしょうか？もう一度、実際に並べて比べてみます。

オーバーロードと型クラスの比較

オーバーロード

def sum(xs: List[Int]): Int = xs match {
  case Nil => 0
  case head :: tail => head + sum(tail)
}

def sum(xs: List[String]): String = xs match {
  case Nil => ""
  case head :: tail => head + sum(tail)
}

型クラス

def sum[A](xs: List[A])(implicit addable: Addable[A]): A = xs match {
  case Nil => addable.unit
  case head :: tail => addable.add(head, sum(tail))
}

trait Addable[A] {
  val unit: A
  def add(x: A, y: A): A
}

implicit object AddableInt extends Addable[Int] {
  override val unit: Int = 0
  override def add(x: Int, y: Int): Int = x + y
}

implicit object AddableString extends Addable[String] {
  override val unit: String = ""
  override def add(x: String, y: String): String = x + y
}

型クラスのほうがちょっと実装が長くなってしまっていますが、オーバーロードの実装で問題の一つだった重複した実装が、ジェネリックな sum メソッドによって一本化できています。

さらに、オーバーロードのもう一つの問題点だった拡張性についても、型クラスでは改善しています。今、合計という概念が適用できる型として Double を発見し、Double についても sum メソッドが利用したくなったとします。この時、sum の実装については手を加えずに、sum を拡張することができます。

implicit object AddableDouble extends Addable[Double] {
  override val unit: Double = 0.0
  override def add(x: Double, y: Double): Double = x + y
}

sum(List(1.0, 2.0, 3.0)) // => 6.0

さらにさらに、自作の有理数を扱う Rational クラスをつくったとしましょう。Rational クラスには Rational 同士を加算する add メソッドが定義されているとします。この時、sum の実装については手を加えずに

implicit object AddableRational extends Addable[Rational] {
  override val unit: Rational = Rational(0, 1)
  override def add(x: Rational, y: Rational): Rational = x.add(y)
}

sum(List(Rational(1, 2), Rational(1, 3), Rational(1, 4))) // => 13/12

気持ちよくなってきた。

というわけで型クラスを見てきましたが、もう型クラスについては怖くなくて、オーバーロードのようにすっかり手に馴染むようになってきたのではないでしょうか？

型クラスとは

ここで、型クラスの性質をまとめてみます。

• あるジェネリックなメソッドが 受け入れられる型の集まり を型クラスの実装として明に列挙することで、それ以外の型では静的にコンパイルエラーにすることができる(型クラス制約)
• 型クラス制約を与える型は既存の型でよく、既存の型を修正したり拡張したりせずに新たに振る舞いを追加できる
• 型クラス制約を受ける型の振る舞いは共通だが、型ごとに実装は異なる
• 既存の型クラスに適合させたい型が増えた場合には、その型クラスの実装を提供するだけでよい(たとえば sum メソッドに手を入れる必要がない)

これは前述のオーバーロードの満たす性質と近く、より抽象的な / 拡張に対して開いたものになっています。特に、ライブラリ実装者が型クラスを用いることで、利用者はライブラリによってなされた実装に対して手を加えることなくそれを拡張することができます。

実際、今回扱った sum メソッドでは Double や Rational といったすでに存在する一般の型について、sum メソッドだけでなく型そのものについても直接変更を加えず、後付で Addable な性質を実装することができました。

これらが、型クラスが便利で、コードをより抽象的で整理されたものにしてくれるといわれる所以ではないかと思います。

そもそも実は、型クラスという仕組み自体が この記事で名前の出せないあの言語 で一般性の高いアドホック多相 / オーバーロードを実現するための仕組みとして導入されました。これについては別記事で扱っていますが、型クラスがちょっとすごいオーバーロード というのは言い過ぎではないはずです。

型クラスがわかってきたところで、よくある 型クラスとインターフェースの違い について考えてみます。

型クラスとインターフェースとの違い

型クラスは、ある型に対するメソッドの存在を約束するという点でインターフェースと似ており、よく比較されています。実際、Scala の型クラスの実装でも trait Addable[A] のようなかたちで、trait による抽象化が行われていました。

では、インターフェース(トレイト)と型クラスではなにが違うのか、sum や Addable の実装についてインターフェースを用いたサブタイプ多相による実装を考えてみます。

Addable[A] インターフェースを継承したクラスの値を扱う sum

trait Addable[A] {
  val value: A
  def add(x: Addable[A]): Addable[A]
}

class AddableInt(override val value: Int) extends Addable[Int] {
  override def add(x: Addable[Int]): Addable[Int] = new AddableInt(value + x.value)
}

def sum[T](xs: List[Addable[T]]): Addable[T] = xs match {
  case Nil => null
  case head :: Nil => head
  case head :: tail => head.add(sum(tail))
}

sum(List(1, 2, 3).map{ new AddableInt(_) }).value // => 6

渡された List が空の場合はデフォルト値が取得できないので null を返してしまったり、そういう設計のため add や sum の引数・戻り型が A でなく Addable[A] になってしまっていたり、 List[Int] を包み直したりなかなか難儀な感じになってしまいましたが、ほぼ似たような実装ができています。が、型に紐づく処理を挿入するためだけにすべての値をインターフェースに適合した型にラップしており無駄が多いし素直じゃないですね。

Java だとこういうときは ストラテジーパターン が自然かもしれません。

AddStrategy[A] インターフェースをストラテジーとする sum

def sum[A](xs: List[A])(addStrategy: AddStrategy[A]): A = xs match {
  case Nil => addStrategy.unit
  case head :: tail => addStrategy.add(head, sum(tail))
}

trait AddStrategy[A] {
  val unit: A
  def add(x: A, y: A): A
}

object AddStrategyInt extends AddStrategy[Int] {
  override val unit: Int = 0
  override def add(x: Int, y: Int): Int = x + y
}

sum(List(1, 2, 3))(AddStrategyInt) // => 6

もうおわかりだと思いますが、これはほぼ完全に型クラスによる実装と同じです。implicit による自動挿入だけがない状態になっています。

インターフェース・サブタイピング、Scala でできないこと

インターフェースの実装でできていなこと、ひいては Scala でできないことは、結局のところジェネリックなメソッドの型パラメータ A からスタティックなメソッドが呼べないことです。(既存の型 A に対して unit 等の拡張ができないというのもありますが...²)

// これはできない
def sum[A](xs: List[A]): A = xs match {
  case Nil => A.unit
  case head :: tail => A.add(head, sum(tail))
}

Scala は pure な OOP を標榜しており、method は常にそれの所属するインスタンスを必要とします。Scala に static キーワードがなく、実質的な static として機能するのがシングルトンオブジェクトである object であることからも、Scala がメソッドの呼び出しに常にインスタンスを必要とするオブジェクト指向を目指していることがわかります。

そこで、型に紐付いた static なメソッドを呼び出すためのプレースホルダ が implicit object だったわけです。上記の A と下記の addable: Addable[A] が対応していることがわかるかと思います。

// 型クラスによる A の addable への置き換え
def sum[A](xs: List[A])(implicit addable: Addable[A]): A = xs match {
  case Nil => addable.unit
  case head :: tail => addable.add(head, sum(tail))
}

型クラスとインターフェースの違いまとめ

まとめると、インターフェースと型クラスは似ているようですが、そもそも目的の違うもので比べるものではない ということです。

インターフェースはそれを継承したものにその 実装を強制する仕組み です。この仕組自体は型クラスの実装でも用いられていました。

一方型クラスは、その約束された実装を 型情報に基づいて自動的に挿入する 仕組みでした。型クラスを実現するためには挿入する実装を約束するために、インターフェースが必要 でした。

型クラスとインターフェースは似たような性質を見かけ上持っているため比較されたりしていますが、そもそも対置して比較できるものではなく、むしろ型クラスがインターフェースに依存している、協調的な関係になっています。

インターフェースでの実装でも示した通り、インターフェース自体は様々な使い方ができ、ポイントだったのは 型に対する実装をデータ型と同じ場所に置くか、違う場所に置いて適宜挿入するか ということでした。

この、型に対する実装をインターフェースで約束して、データ型と違う場所に置いて自動的に挿入してくれる仕組みこそが型クラスの正体でした。

その点でも、型クラスが アドホック多相・オーバーロードのための仕組み = 型情報に基づいて自動的に実装を挿入する仕組み であるということが納得できるかと思います。

長々とやってきましたが、最後に型クラスを知っているとなにが嬉しいかを紹介して終わりにしようと思います。

おまけ - なぜ型クラスとインターフェースが混同されてしまったか

おそらく、型クラスの原点である Haskell において、型クラスがインターフェースの仕組みを暗黙に内包していることが原因ではないかと思います。

前述の通り、型クラスは仕組み上、実装の約束をするためのインターフェースを必ず必要とします。しかし、Haskell はオブジェクト指向な言語ではないため、そもそもインターフェースというオブジェクト指向の仕組みを持ちませんでした。継承とかないですからね。

そのため、型クラス導入の際に、型クラスを実現するキーワード class が実質的にインターフェースの部分を担うことになりました。

このことが型クラスとインターフェースが混同されて議論される原因の一端ではないかと思っています。おまけおわり。

型クラスを理解すると嬉しいこと

型クラスを理解しているとなにが嬉しいでしょうか。個人的には、ライブラリやフレームワーク等の抽象的なコードを書く側でない限り 型クラスによる実装を書く機会はめったにない と思います。

では、型クラスの知識はムダなのかというとそんなことはありません。ライブラリを作成する際はもちろん、 ライブラリを利用する・コードを読む際にとても役立ちます。

Scala のライブラリでは、標準ライブラリも含めて型クラスによる実装が様々なところに見つけられます。Scala のコレクションのように 高階型 を伴う実装や Json パーサー等の型によって異なる実装を挿入したい場合において型クラスは非常によく用いられているため、それらを利用する際に型クラスの知識があると シグネチャから実装の意図が容易に汲み取れます。

たとえば、Scala の Json パーサーの 1 つである play-json の Json.fromJson メソッドのシグネチャを見てみます。

def fromJson[T](json: JsValue)(implicit fjs: Reads[T]): JsResult[T]

型クラスの知識があると、ドキュメントがなくても Reads[T] 型の意図するところ、求められる実装がこのシグネチャからわかるのではないでしょうか？実際にこのメソッドを使うコードを示します。

case class Cat(name: String, age: Int)
object Cat {
  implicit val jsonReads: Reads[Cat] = Json.reads[Cat] // 型クラスの実装の提供
}

val json = Json.parse(
  """{
    "name" : "Tama",
    "age" : 4
  }"""
)

val cat = Json.fromJson[Cat](json)  // ここに implicit に jsonReads が渡されている
// --> val cat = Json.fromJson[Cat](json)(jsonReads) と同じ

Json.reads[Cat] は実はマクロで、Cat 型の実装から Json を Cat 型にパースする Reads[Cat] のインスタンスを生成してくれます。Cat 型に特殊化した実装を型クラスのインスタンスとして提供しているわけですね。

このように、ユーザー側で定義した型について、型クラスを利用することで型固有の処理をあとから利用者が差し込めるようになっています。型の定義場所にその型のパーサを implicit に提供することで、実際に Json をパースするところでは型に固有のパーサーを意識しなくて済むようになっています。

というわけで、型クラスを知っていると利用者としてもメリットが有ることがわかったかと思います。自分で積極的に使わなくても、コードを読む際に重宝するという点で、Scala におけるデザインパターンの一つとして捉えても差し支えないでしょう。

どうでしょうか？型クラスがどんなものか具体的に理解できたでしょうか。

本当に型クラスの指すものがこれであっているのか気になる、型クラスの定義自体を知りたい、という場合は型クラスの原点 How to make ad-hoc polymorphism less ad hoc を読んだ話も参照してみてください。

型クラス完全に理解した。

補足1 - sum メソッドと fold

今回の sum メソッドの実装は、デフォルト値と加算という処理を使って List の値を走査して単一の戻り値を作っていました。これについて、関数型と呼ばれる言語を扱ったことがある人は fold が思いついたのではないかと思います。まさに fold は sum のようなリスト構造をたぐる処理の一般的表現になっています(より一般性があるのは foldLeft / foldRight ですがここでは簡単のため fold とします)。

def fold[A1 >: A](z: A1)(op: (A1, A1) => A1): A1

Scala のコレクションの根幹になっている GenTraversableOnce[+A] にこの定義がありますが、これはデフォルト値 z と、 A1 型の 2 つの値を取って A1 型の値を返す関数オブジェクトを引数にとっており、それぞれが Addable の unit と add に相当してることがわかると思います。fold を使って sum と同様の実装を与えてみます。

List(1, 2, 3).fold(0){ (acc, i) => acc + i }
List(1, 2, 3).fold(0){_ + _}
List(1, 2, 3).fold(AddableInt.unit){ AddableInt.add }

2 行目は省略記法で、1 行目と意味するところは同じです。fold では型クラスやオーバーロードよりさらに柔軟に、利用するその場で処理を記述できるようになっています。これは関数を一級市民として扱うことで、関数型という型 の宣言ができるようになり、それがインターフェースとして機能しているわかりやすい例だと思います。3 行目はわかりやすさのため、という名の悪ふざけです。

fold に対して型クラスが優れている点は、型に応じて自動的に処理が挿入される点ですが、概ねの場合はこういった関数オブジェクトを渡すことでなんとかなるのではないかと実は思っています。実際、ここで挿入される関数オブジェクトは List(1, 2, 3) から推論される型 Int により (Int, Int) => Int であることが静的に解決されるので、型的に安全になっています。

補足2 - Context bound な型クラス制約の書き方

Scala の型クラスについてはもうちょっとオシャレに書く方法が用意されています。Context bound というやつです。

def sum[A: Addable](xs: List[A]): A = xs match {
  case Nil => implicitly[Addable[A]].unit
  case head :: tail => implicitly[Addable[A]].add(head, sum(tail))
}

引数として渡されていた (implicit addable: Addable[A]) をなくして、implicitly[Addable[A]] というかたちで Addable[A] の実態を参照できるようになりました。おしゃれではあるのですが、見た目が直感的じゃないので賛否両論かもしれません。

参考

Martin Odersky. Poor man's Type Classes Philip Wadler. How to make ad-hoc polymorphism less ad hoc JSON automated mapping

---

1. カリー化などで調べると説明があるかと思います↩

2. implicit を用いた暗黙の型変換(Pimp my liblary パターンとも呼ばれるらしい)で既存型に対して拡張は可能ですが、わかりづらさ等の理由で最近はあまり推奨されていないようです。↩

Scala の implicit parameter のスコープと左辺値型推論で困った話

以下の記事は 2016 年 7 月 に Qiita に投稿した記事の移植です

pixivFANBOX にも投稿しています。ご支援頂ける場合はよろしくお願いいたします。

www.pixiv.net

---

Scala の特徴的言語仕様の一つであり、憎まれたり便利だったりする implicit の小ネタです。いろいろ検証過程を書いてるので、結論だけ知りたい人は最後を見てね。

便利な implicit parameter

implicit には何種類かあるのはご存知という前提で。implicit parameter 便利ですよね。

implicit val g = "Hello "

def hoge(name: String)(implicit greet: String) {
  println(greet + name)
}

hoge("Biacco") // 2番めのパラメタ群については implicit に渡される

ただ、この implicit が解決されるスコープと型推論が組み合わさるとややこしいことになるようです。

implicit parameter の解決スコープと型推論がうまく動かない例

今回ハマったのはこれ。

object Main extends App{
    import Hoge._
    val h = new Hoge
    h.hoge
}

class Hoge {
    def hoge(implicit s: String) { println(s) }
}

object Hoge {
    implicit val hs = "hoge!"
}

一見動きそう。でもコンパイルすると

error: could not find implicit value for parameter s: String

なるほどわからん。

検証1: スコープを確認する

スコープに正しく入ってないのかな？と思って以下を試す。

object Main extends App{
    import Hoge._
    val h = new Hoge
    h.hoge(hs) // 明示的に hs を渡してみた
}

class Hoge {
    def hoge(implicit s: String) { println(s) }
}

object Hoge {
    implicit val hs = "hoge!"
}

動くんですよねこれが。コンパイル通ります。おっかしいな〜〜〜〜〜〜〜〜〜〜

検証2: ローカルスコープにおいてみる

というわけで、スコープに存在しないわけではないというのがわかった。じゃあ間違いなくアクセスできるということで試しにローカルスコープにおいてみる。

object Main extends App{
    import Hoge._
    
    implicit val hs = "hoge!"
    
    val h = new Hoge
    h.hoge
}

class Hoge {
    def hoge(implicit s: String) { println(s) }
}

object Hoge {
}

これもOK. この辺でかんべんしてくれという気持ちになり始める。

問題の定義: implicit な変数がスコープ内にいるにもかかわらず implicit parameter で解決されない

というわけで、現在の問題は

• implicit な変数はスコープ内にいる
• implicit parameter がそれを解決できない
• implicit な変数はローカルスコープではなく import のスコープにいる

になります。一応 暗黙のパラメータ解決優先順位 なんかを見てみるものの、import した場合は Prefix なしの状態で参照できることとなっているが、 import Hoge._ しているのでそこも問題なさそうである。

解決法

まぁ、タイトルにもしているのでお気づきかと思いますが、この問題は implicit parameter と左辺値型推論が組み合わさると発生するようです。なので明示的に型注釈を与えてみます。

object Main extends App{
    import Hoge._
    
    val h = new Hoge
    h.hoge
}

class Hoge {
    def hoge(implicit s: String) { println(s) }
}

object Hoge {
    implicit val hs: String = "hoge!"　// implicit な変数に型注釈をつける
}

と、コンパイルできるようになりました！出力もちゃんと hoge! になる。なんだったんだこれ...

解決した後に見つけたんですが OE さんがもう書いてた。死にたい。

Scala コミュニティでは定期的に話題になる問題のようです。きびしい。

コミケ C97 サークル「たのしい人生」のお知らせと今年の振り返りの話

この記事はキーボード Advent Calendar 2019、23 日目の記事です。

adventar.org

22 日目は ai03 さんの「海外コミュニティでの活動から学んだこと」でした。

docs.google.com

24 日目は foostan さんの「Let's Split Rebuild Log」です。

fstn.hateblo.jp

コミケ C97 告知

最初にコミケ告知です！サークルスペースは 4 日目 南ホール ラ13a です。クレジットカード決済対応予定です！

びあっこ @Biacco42

biacco42.booth.pm

KbD C96 August 2019 特集「遊舎工房インタビュー」「キーボードカスタマイズ最前線」

実店舗の遊舎工房成立の経緯とこれからを語っていただいたり、2019 年になって大幅に変わった自作キーボードのトレンド、カスタマイズの最新情報、そのなかでもアルチザンキーキャップワークショップ主催のお二人へのロングインタビューなど、2019 年の自作キーボードシーンを記録するコレクションとしてどうぞ。電子版もありますが、製本版に関しては在庫分で終了予定です。

既刊 KbD C95 も持っていく予定です。こっちも歴史やキーボードキットの情報の一覧など、資料性が強いかもしれない。

biacco42.booth.pm

せきごん @_gonnoc

I2C 接続可能なマウス IC 評価用モジュール。下の写真は作例。

マウスIC評価用モジュール

作例 (I2C 接続可能)

いつの間にかモジュール化されてましたすごい。

Kugel-1

booth.pm

言わずとしれた自作トラックボール付キーボードキット。

ゆーち @F_YUUCHI

Lily58 Lite

Lily58 Lite

Columnar Staggered の定番 Lily58 の初心者向けに改良されたバージョン。組み立てやすくなっているとのこと。10,000 円予定。

というわけで、サークル「たのしい人生」はコミケ C97 4日目 (12/31) 南ラ13a でお待ちしています！

告知終わり。

今年の振り返り

ここからは、今年は目標としていたところと、期せずしてできたことがあったので、それらを軸に簡単に振り返ろうと思います。

目標：人を頼る・チーム作業をする・人と仕事をする

私はどうにも人を頼るのが苦手で、できることならスタンドプレーでやっていたいというタイプなのですが、歳を重ねるにつけていろいろと制約を感じたり、一人でいつまでやり続けられるのかという不安も出てきていました。

現職の仕事も 1 案件 1 エンジニアみたいなのが基本なので、ともかくチームでの作業やコミュニケーション、頼り頼られるみたいな人間的生き方からあまりにも離れすぎていたため、ちょっとまずいかな、と。こういう思考になるのは歳なんですかね。

ということで「人を頼る」「チーム作業をする」「人と仕事をする」というのをふんわり目標にしていました。目標というかほとんど焦燥感と言ってもいいかなと思います。

この観点・目標については今年はかなりがんばれたし、蒔いた種から収穫できたかなと思っていて、結構満足しています。具体的な話を 3 つほど。

ほぼ週刊キーボードニュース

実際には去年から種を蒔いていたほぼ週刊キーボードニュースですが、おかげさまで「ほぼ毎週」、 1 年間走り抜けることができました。

www.youtube.com

ともかく「人と協力し」「スケジュールを守りながら」「継続する」と、私の苦手なもの三段重ねの、今思えば随分攻めたプロジェクトでした。でも、兎にも角にもこれを実現してやりきれたのは、私を叱咤し諦めず一緒に創り上げてくれたぺかそ氏のおかげです。本当によく見捨てられなかったなと思います。

キーボードニュースに関しては、間違いなく私一人では絶対にこんなに良い結果にはならなかったし、そもそも継続も実現もできなかったと思うので、「人を頼って」「チーム作業をして」一人ではできないものづくりができたので、これは本当によかったなと思っています。

分業やマネジメントの仕方についても、二人で手探りながら少しずつ進めてこれました。ぺかそ氏が何事もプロフェッショナルなので、コミュニケーションも円滑で、チーム作業でありながらやりたいことなんかをサクサク実現できたりして、とても心地よい経験でした。チームとしてちょっと都合が良く回りすぎた (たぶんぺかそ氏が回してくれていた、が正確なのですが…) フシもあるので、来年はもうちょっと分業・マネジメントの仕組についても勉強・実践していきたいところです。

来月にはほぼ週刊キーボードニュースも放送開始 1 周年になります。まだまだやりたいことあるので、来年はもっとリスナーの方々とも関わりながら、楽しんでいただける放送を一緒に創り上げられたら幸いだなと思っています。

サークル「たのしい人生」

もうちょっとゆるい形で「人を頼る」ために、お声がけをさせてもらって、個人サークルだった「たのしい人生」が複数人の参加するサークルになりました。響きだけならめちゃめちゃリア充っぽい…。

上の告知でも書いたとおり、せきごんさん、ゆーちくんと 3 人で少しずつ活動させてもらっています。

ほぼ週刊キーボードニュースのように、1 つのものをガッツリ複数人で作る、というのはこれはこれで特殊スキルなので非常におもしろいんですが、やはりコミットの責任が伴います。なので、もうすこし軽く「人を頼る」ために、それぞれが作ったものを持ち寄るという形でのサークル活動をはじめてみました。

自作キーボード界隈では有名な「沼人の会」もそれぞれがそれぞれの成果物を持ち寄るという点で似ているのですが、いい意味で沼人の会は非常に進捗圧が高い空間のようなので、たのしい人生の方はもうちょっとほんわかした、自作キーボードの「きらら枠」になったらいいかなという感じで、おかげさまで非常に頼りまくってしまっています。

ともかく今まで、成果を出し続けること以外で人と関わることができない人間だったので (文字にするとひどすぎる)、今こうして見捨てられずに一緒にいてくれることに感謝しかないです。来年は少し自分も還元できるものを還元しつつ、まだまだ頼ってたのしいサークル活動ができれば…と目論んでいます。

ハロー、自作キーボードワールド

ここまでは「人に頼る」「チーム作業をする」など基本的には、協力する人間を作る、というテーマだったのですが、もう一つ、少し緊張感を足す目的で考えていたのが「人と仕事をする」でした。というわけで、つい先日始まった ITmedia さんでの連載「ハロー、自作キーボードワールド」です。

www.itmedia.co.jp

最近だと、連載とは別で新型 HHKB こと HHKB HYBRID のレビュー記事なんかも書かせていただきました。

www.itmedia.co.jp

これらは、明確に仕事として連載を請け負うということで、ある種の「契約という形での人との関わり方」「人と仕事をする」という目標がラッキーなことに実現させていただけたお話になります。締め切りや受け入れ品質のチェックなど、ある程度責任を負って、プロとして人となにかを作り上げる、という経験を今絶賛させていただいてます (編集井上さん、記事遅れていてすいません)。

上のような書き方だとちょっと敵対的に見えてしまうかもしれませんが、実際には編集の方に非常に支えられた状態で作業をさせていただいていて、いい人間・いい仕事をする方が社会にはちゃんといるんだ、と感動しています。

他にも蒔いてる種がちょっとだけあるのですが、それはもうすぐお披露目されると思うので、お楽しみということで。

というわけで、自分なりに目的意識を持って、人と関わる、人と一緒につくる、ということをやってきたつもりの 2019 年でした。とは言うものの、忙しかったり疲れたり、必ずしも常に気を配って過ごせていたわけではなかったのですが、結果としては「目的として意識してよかったな」と思える大満足な結果になったかと思います。

ただ、これはどれも関わってくれた、支えてくれた人たちのおかげで、当然一人で達成できるタイプの目標ではなかったので、迷惑をかけたことも多かったと思います。ですが、過度に自らを律しすぎず、「お互い様」精神で迷惑をかけることも、かけられることも自然と受け入れられるようになれたのなら、少しは成長できたのかな、と感じます。周りから見たら迷惑なおっさんが発生しただけにみえる…と今気づいてしまいましたが、そこは一旦目をつぶっておこうと思います。

できたこと・やれたこと

完全に期せずしてできたこと・やれたことといえば、ずっとコンプレックスだったお絵かきを始めることができました。

一端のオタクなので、やはり絵を描くということにはちょっとした神聖性を感じずにはいられないのですが、どうにもセンスが無いというか、人生で幾度となく挑戦しては挫折して、「自分には絵のセンスがないんだ」と自分を納得させてきました。ですがここ数年、ありがたいことに絵を描く友人・機会に恵まれ、「iPad Pro がお絵かきデバイスとしていいらしい」なんて話も重なって、昨年末から iPad Pro お絵かきマンとしてデビューしました。

挫折した、なんて言っていますが、今までどう描いていいかまったくもって見当もつかず、ほとんど手を動かすこともかなわないまま、ただちょっと描いては諦めていただけだったのですが、信頼できる友人に絵を見てもらい、レクチャーをしてもらうことできっかけを掴んで、絵を描き始めることができました。

なんだかんだ言ってこれも人の縁のおかげということで、なんだか今年は特別な年だったんだなぁ、と振り返ってみてひしひしと感じています。人脈が大事！という人間は信用できないですが、刺激を受けられるよい友人の存在は代えがたいですね。

ちゃんと仕上げたのは 6 枚ぐらいしかないんですが、自慢します。

びあっこちゃん

まともに描いた絵としてはこれが初です。ほぼ週刊キーボードニュースのリリース期限が迫っていた 1 月、必死で描いたのを覚えています。よく絵もかけないのに VTuber にいきなりなろうとしたなと、我ながら驚きます。

現場ぺかそちゃん

なんか突然描いてみたくて描いた。当時は本当に全然描き方がわからなくて、これ描くのに 4 時間ぐらいかけたんじゃないかと思います。アホでは？

www.pixiv.net

習作。このころから本格的に、神絵師に 囲んで棒で叩かれながら 優しく指導していただきながら練習をはじめました。これは好きな作家さん (ぎゃりん先生) の絵をトレース、模写練習をした後、手に感覚が残っているうちになぐり描きしたものです。当時は顔のパーツや輪郭などを完全に感覚というか何も理解せずに描いていたので、今見るとよく描けたなって感じがします。

www.pixiv.net

「いや、びあっこちゃん描けよ」というあまりにもまっとうな指摘を受けて描きました。背景もちゃんと描いたえらい。まだこのころは骨格等の意識が曖昧だったはず。よく描けたな (2)。

www.pixiv.net

ダンベル何キロ持てる？ブームで、同作品より立花先生。キーボード然り、愛はやっぱり原動力ですね。

www.pixiv.net

VTuber 事務所のにじさんじより、健屋花那。これはきちんと骨格等を意識して描きました。ポージングなんかも、骨格表現の練習としてつけたフシがあります。この絵はなんと健屋本人に使ってもらうことができました！生きていてよかった…

【脚本募集！】

お芝居したい～！朗読配信もやりたい～！！でも脚本を書く時間がない～～！！！そんな健屋に皆さんのお力を貸してください！

脚本募集用メールアドレスをつくりました✉
jpnsukokobirds@gmail.com
※こちらのメールアドレスは送信専用です※

添付画像をお読みの上ご応募ください！ pic.twitter.com/aRV9WfB1TD

— 健屋 花那(すこや かな)💉💘 (@sukosuko_sukoya) 2019年11月20日

脚本募集の要項にこちらのイラストをお借りいたしました！それな〜っ！ありがとうございます🥰🥰🥰 https://t.co/iESJ9AVtPb

— 健屋 花那(すこや かな)💉💘 (@sukosuko_sukoya) 2019年11月20日

という感じで、今年は新しいこと、それも苦手意識を持っていた絵を描くことを始められました。絵を描く世界は過当競争で、とても自分がなにか意味のあることをできるとは思えないですし、「そんなことしてる時間でもっと価値のあることを…」という指摘も尤もなんですが、キーボードも絵も「自分が欲しい物」が市場にない以上自分で作るしかない、そして少なくとも絶対自分は得をするので、自分のためにやり続けようと思います。

まとめ

というわけで、後半は完全に自己満でしたが、振り返ってみると基本的に今年もキーボードを中心に生活が回っていたんだなぁ、という感じの 1 年でした。ずっと言及を避けていましたが、modulo！ ほそぼそ試作開発を続けています！ちょっとどころじゃなく遅れていて申し訳ないですが、2020 年は modulo year にする (なる) ので、よろしくお願いします！

では、また来年。自作キーボードのたのしみが、より多くの方に広がって社会の総幸福が増えますように。

この記事は Ergo42 Towel (Gateron Silent Red Stock / Big Bang / Eucalyn 改配列) で書きました。 (7125文字 / 3 時間)

meishi2 keyboard ビルドガイド

meishi2 - The updated micro macro keyboard をご購入、もしくはリポジトリから製造いただきありがとうございます。この記事では、meishi2 keyboard の組み立て方を簡単に紹介します。

必要なパーツ

項目	数量
meishi2 PCB	1
Pro Micro	1
ダイオード(1N4148)	4
リセット用タクトスイッチ(5 mm ピッチ 2 本足)	1
クッションラバーシール	4
キースイッチ (Cherry MX 互換 / Kailh Choc)	4
キーキャップ	4

※キースイッチとキーキャップは別売りです

(オプション) 組み立てに必要・あると便利な道具

白光(HAKKO) ダイヤル式温度制御はんだこて FX600-02

温度調節機能が便利(ない安物は温度が高すぎてはんだづけが難しいし基板焼いちゃいやすい)。加温も早くてよいです。

白光(HAKKO) こて台 FX-600/FX-601/PRESTO/DASH用 633-01

コテ台も安いのもあるんだけど、熱いものを扱うのでちゃんと固定できる・保護できるものがおすすめ。これはコテ先クリーナーもついていて、スポンジに水をつけるタイプと比べてもめちゃめちゃ扱いやすいので総合的にお得だと思います。

goot(グット) はんだ吸取線 幅3.0mm 長1.5m CP-3015 日本製

はんだ吸取り器があったほうがよい場合も多いんだけれど、自作キーボード、多分そんなにはんだをミスったりするような複雑な部分もないし、とりあえずはこれだけあれば十分。

フジ矢 スモールニッパ 110mm 刃部鏡面仕上げ より線Ф2.0まで切断可能 MP4-110

デバイスの余った脚を切るのに必要。

これぐらいあればこのキーボードを作る分には十分だと思います。

はんだづけ

はんだづけは、合金であるはんだ線を高温で溶かして、2 つの金属接点を電気的に接続して固定する方法です。はんだは接着剤ではなく、きちんと加熱して接点同士を合金として接合しないと正しく動作しないです。 というと難しそうですが、 はんだは温度が高い方に流れる という基本ルールさえ押さえれば基本は大丈夫です。

はんだづけする際は、上記の はんだは温度が高い方に流れる の原則に沿って、まずは繋ぎたいパッド (写真の丸い輪っか状の銀色の部分) と端子 (写真のコンスルーの金色の棒) をはんだごてのコテ先で加熱します。このとき、母材 (繋ぎたいパッドと端子) を温めるのが目的なので、まだはんだ線は 溶かしません 。3 ～ 5 秒程度、十分に母材を温めてから、はんだ線をコテ先につけてはんだを溶かして流します。この時、母材が十分に温まっていれば、自然とはんだが母材に吸い付くように流れます。富士山型になる程度、軽くはんだを流し込んだら、はんだ線を離し、その後にはんだごてを離します。

1. まず母材を温める

2. はんだ線をつけてはんだを流す

組み立て

基本的には、すべてのパーツを正しく配置して、はんだづけしてキーキャップ・脚シールをつけるだけです。はんだづけの基本は背の低いパーツから、なのでその順番で付けていきます。パーツはロゴマークがついている側につけていきます。

完成図

ダイオード

ダイオードの向き

ダイオードという部品は基本的には一方向にだけ電流を流す整流用に使われます。なので、どちらに電流を流すかという 向き の概念があります。この向きを間違えると正しく動作しません。

写真のダイオードの右側、黒い線が入っている側が カソード、逆に入っていない側が アノード といい、アノード側からカソード側に向けて電流が流れます。

キーボードに固定する際には、この黒線の入ったカソード側を、基板の白線のある側、四角いパッド側に向けてセットしてください。

ダイオードを差し込むときは、ダイオードの根元付近でリード (銀色の線の部分) を折り曲げて、スルーホール (銀色の穴) に通してください。通した後、軽くハの字型にリードを広げると固定されてはんだづけがしやすくなります。

タクトスイッチ

続いて、タクトスイッチをはんだづけします。タクトスイッチには向きがないので、スルーホールに通してはんだづけをするだけでオッケーです。

Pro Micro

Pro Micro の固定方向

上記写真のように、ロゴマークが入っている面を上にして、Pro Micro の USB 端子が基板の外に向くように設置します。

ピンヘッダの接続

通常のピンヘッダを用いてはんだづけで基板と接続する方法と、コンスルーと呼ばれる抜き差し可能なピンヘッダを用いて基板と接続する方法の 2 種類があります。付属するピンヘッダによってそれぞれ以下の章を参照してください。

通常のピンヘッダ

写真のように Pro Micro の部品実装面が上になるようにピンヘッダをはんだづけします。ピンヘッダをはんだづけする際は、基板にピンヘッダをテープ等で仮止めして作業すると Pro Micro に対してピンヘッダが斜めにならずに固定しやすいです。

裏面も同様にはんだづけします。

コンスルー

コンスルーの固定方向

遊舎工房で販売されている meishi2 キットには、コンスルーという基板にはんだづけしなくても抜き差しが可能になるパーツが付属しています。 (Update) 2022 年現在コンスルーの入手が非常に困難になっており、コンスルーは付属しなくなっています。 コンスルーがある場合は Pro Micro にコンスルーをはんだづけします。コンスルーを Pro Micro の部品実装面と逆側になるようにはんだづけします。

コンスルーには向きがあり、金色の軸が側面から見える側 (窓側) が同じ向きになるように、また窓が端子に近い側を Pro Micro 側になるように揃えます。

キースイッチの固定

この基板は Cherry MX / Kailh Low Profile 両対応仕様です。3 pin 仕様のキースイッチ (固定用の脚が出ていないもの) だと多少の遊びがあり斜めにキーを固定できてしまいます。そのため、5 pin 仕様のキースイッチ、もしくは、はんだづけする際に、セロハンテープ等でスイッチの向きを固定してはんだづけすることをおすすめします。

5 pin 仕様のキースイッチ

完成状態

表面

裏面

ファームウェア書き込み

組み立てが完了したらファームウェアをビルドして書き込みます。meishi2 keyboard では QMK Firmware が利用できます。

QMK Firmware

ここでは詳細は省きつつ、ファームウェアをビルドしてインストールする手順と、キーマップの変更方法を「黒い画面」を使わない方法と、CUI で行う方法の 2 つで簡単に紹介します。

従来のファームウェアビルド・書き込み方法は後半の章に移動しました

2021/11/18 Remap のファームウェア書き込み機能とキーマップ書き換え機能に対応しました！ Google Chrome 等の対応ブラウザでファームウェアの書き込み・キーマップの変更が可能です！🎉

Remap meishi2 カタログページ

meishi2 を PC に接続した状態で、Remap カタログページの FIRMWARE タブ → FLASH でファームウェアを書き込むことが出来ます。

FLASH ボタンを押したあと書き込み方法のダイアログが表示されるので、Firmware が meishi2_via for meishi2、Bootloader が caterina になっているのを確認して FLASH を押します。

FLASH を押すと Google Chrome 上で serial port を選ぶダイアログが表示されます。

そうしたら meishi2 のリセットボタンを押してください。

リセットボタンを押してブートローダーが書き込みモードになると Google Chrome の serial port ダイアログに Arduino Micro (やそれに類する名前) があるはずなのでそれを選択し Connect を押します。

書き込みが正常に完了したら、USB を抜き差しすると PC に meishi2 キーボードとして認識されます。

(2023 9/11 追記) Remap が QMK 0.22 系に対応し、0.18 系のキーマップ書き換え対応は https://qmk018.remap-keys.app になりました。現在 Remap にホストされている Ergo42 / meishi2 のファームウェアは 0.18 系なので、キーマップの書き換えは https://qmk018.remap-keys.app を利用してください。

近いうちに 0.22 系のファームウェアを Remap にアップロード予定です。

お疲れ様でした

ここまで来たらあなたも立派な自作キーボーダーです。おそらくここまでたどり着けたなら、他のより高度な自作キーボードについてももう自分で作ることができるようになっていると思います。

しかしここで触れた内容は自作キーボードのほんの一部に過ぎません。キーキャップやキースイッチにこだわるのも楽しいですし、QMK firmware にはここでは紹介しきれなかったたくさんの機能があります。ぜひ、このキーボードをそういった次のキーボード道の道標として利用していただければ幸いです。

ようこそ自作キーボード沼へ！

Help

組み立ての際に困ることやトラブル等あるかと思います。その際には Twitter で @Biacco42 にリプライを飛ばしていただくか、Self Made Keyboard in Japan Discord server で相談していただければ対応します。特に Self Made Keyboard in Japan Discord server には私以外にも自作キーボードを製作している方がたくさんいるので、より多くのアドバイスを得られるかと思います。大変気楽なコミュニティですので、ぜひこちらの利用も検討してください。

おわり

従来のファームウェアビルド方法と書き換え方法は以下の章を参照してください。

従来のファームウェアビルド・書き込み方法

「黒い画面」を使わずにビルド・書き込み

なんと 2019 年にもなると、黒い画面を使わなくてもファームウェアをビルド・書き込みできるようになりました🎉

手順が、以下の動画で紹介されているので参考にしてみてください。動画中で Ergo42 としているところを meishi2 に読み替えるだけでオッケー (なはず) です。

また、サリチル酸さんの入門記事もまとまっていておすすめ です。

基礎からわかる！自キ入門講座 第12回「ファームウェアのカスタマイズ」

CUI でビルド・書き込み

QMK firmware documentation でデフォルトで紹介されている方法はこちらになります。CUI に慣れている人は、マクロ機能等自由な拡張ができる他、内部で何が起こっているかわかりやすくなるので、やってみるのも一興です。

ファームウェアの実装とビルドの詳細については QMK firmware documentation のドキュメントを参照してください。

環境構築

Git

まず Git が必要です。Windows / Mac / Linux 環境でそれぞれにインストール方法が異なるため、それぞれのプラットフォームの Git をインストールしてください。

Mac でかつ brew がインストールされていれば (brew についてはここでは説明しません)

$ brew install git

Debian 系 Linux であれば

$ sudo apt install git

等でインストールできます。とりあえずファームウェアのビルドの目的だけであればこれで大丈夫です。

Git が準備できたら、ソースをダウンロードします。

ソースコードをダウンロードしたいディレクトリに移動して

$ git clone https://github.com/qmk/qmk_firmware.git

でソースコードを取得できます。

Build 環境

Mac / Linux の場合

QMK のプロジェクトルート配下の util/qmk_install.sh を実行することで、ビルドに必要な依存が解決されます。

$ ./util/qmk_install.sh

Linux の場合だと特権を要求されるので、

$ sudo ./util/qmk_install.sh

としてください。

Windows の場合

こちらの QMK-MSYSを使ってWindows上に最速でqmk環境を構築する を参照して環境構築をしてください。

ファームウェアのビルドと書き込み

組み立てた meishi2 キーボードを USB ケーブルで PC に接続しておいてください。

ビルド環境が構築できたら、ファームウェアをビルドします。

$ make biacco42/meishi2:default:avrdude

でビルドとインストールをいっぺんにできます。途中リセットしろよという旨のメッセージが出るので、そこでリセットボタンを 1 回または 2 回連続で押します(ブートローダーによって挙動が異なるようです)。リセットを検出すると自動的に書き込みが始まります。

Linux 環境の場合は書き込みに特権が必要かもしれないので、権限不足で書き込めなかった場合は

$ sudo make biacco42/meishi2:default:avrdude

としてください。

動作の確認

正常にファームウェアが書き込めたら、キーボードとして認識されて動作するはずです。default キーマップでは左から順に Ctrl-z Ctrl-x Ctrl-c Ctrl-v の配置になっています。動作が確認できたら meishi2 キーボードの完成です！お疲れ様でした。コピペがはかどりますね。

ファームウェアの改造

以上の工程でキーボードは完成しましたが、せっかくの自作キーボードですからコピペ以外にも使えるようにしたくなります。そのためにはファームウェアの改造が必要になります。その方法を簡単に紹介します。

meishi2 キーボードのキーマップを変更するには、キーマップが記述されている <QMK firmware root>/keyboards/biacco42/meishi2/keymaps/default/keymap.c を編集します。また、新たに名前をつけてキーマップを作成したい場合は default ディレクトリをコピーして適当に名前を変えて keymap.c を編集してください。その際ビルドコマンドは

$ make biacco42/meishi2:<your keymap directory name>

になります。

keymap.c で実際にキーマップが定義されているのは

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
[0] = KEYMAP( /* Base */
  LCTL(KC_Z),  LCTL(KC_X),  LCTL(KC_C), LCTL(KC_V) \
),
};

の部分、特に LCTL(KC_Z), LCTL(KC_X), LCTL(KC_C), LCTL(KC_V) の部分になります。これが左から順番にキーの割当を表しています。簡単ですね。

このキーマップに指定するキーの一覧については QMK firmware documentation の Keycodes Overview に一覧があります。初期状態だと、LCTL(KC_Z) のような形で、Ctrl と Z の同時押しを表現しています。 LCTL を外せば単なる Z キーになりますし、MEH(kc) とすれば Ctrl+Alt+Shift+kc が一発で入力できます。その他にもメディアキー(音量操作等)や電源キー(KC_SYSTEM_POWER)等の便利キー系もあるので、いろいろ試してみてください。

また、ここでは説明しませんが、マクロ機能もあり、あるキーが押されたら一定の複雑なキーコードや文字列を送信することもできます。5000 兆円欲しい！キーボードとか。

5000兆円欲しい！キーボードできた pic.twitter.com/APR6BYsaHS

— ぺかそ⌨️ (@Pekaso) 2017年10月9日

Maker Faire Tokyo 2019 に Self-Made Keyboards in Japan が出展します！

今年も Maker Faire Tokyo が 2019 8/3 ~ 8/4 に開催され、Self-Made Keyboards in Japan Discord 有志メンバーが今年も出展申し込みしています！

2018 年は自作キーボードが大きく羽ばたいた 1 年でしたが、2019 年、より裾野を広げ、多様性を増し、よりパワーアップした自作キーボードの世界を展示予定です。

今後の展示当落情報・展示内容等はこの記事を随時更新して提供する予定です。おたのしみに！

C95 たのしい人生お品書き

この記事は 自作キーボード Advent Calendar 2018 その 3 の 24 日目の記事です。

adventar.org

昨日ははのちゃさんの キースイッチが可愛い話 & キースイッチを愛でるアプリの話 でした。

メリクリ

メリークリスマス。みなさん良いクリスマスを過ごされたでしょうか？ 私はこの時間に 24 日の Advent Calendar 投稿を行っている時点でお察しください。

なんにつけても脱稿しました！ C95 は新刊と新自作キーボードキットが！でます！！！
(新キットは動作検証が取れたら出ますが、大丈夫なはず)

C95 お品書き

コミックマーケット C95 2日目 12/30(日) 東6 ナ18a たのしい人生 (Biacco42) で出展します。

本の部

KbD C95

出ます！

今回はちょっといろいろやりすぎた部分も多く、結果として工数が爆発したりしてアレだったのですが、結果として観れる本・飾れる本にはなっていると思います。正直言ってかっこいいです。

フルカラーで 1000 円になります。前回の瞬殺よりはだいぶ部数を刷ったので、即なくなることはないとは思いますが…

KbD C93

少部数ですが、既刊である KbD C93 も持っていきます。

今回新刊が、用語説明とかをかなり端折っているので、沼の住人でない場合はこちらも買っていただいたほうがいいかもしれないです。

自作キーボードキットの部

Modulo Black Pill Pendant and Ergo42 Modulo Beta

動作検証がとれたら出ます。写真は Ergo42 Modulo Alpha ですが外見的には変わらないはずです。アクリルが新しい設計になったのでもうちょっとケースがきれいになるかも。

動作検証できましたので Ergo42 Modulo Beta / Modulo Black Pill Pendant 頒布あります！

Beta 版ということで、基板とケースの材料のみの販売です。電子部品及びネジ等のパーツは自分で揃えていただくキットになります。ただ、Alpha 版と違って動作検証ができているので、その点は安心できます。7 台限定 7000 円です。

Modulo BT Pendant Alpha

明日のC95 2日目 東6 ナ-18a 「たのしい人生（Biacco42）」にてModulo BT Pendant α版を頒布します！　moduloなキーボードにガシャっと挿して無線化するモジュールで、半完成品1個3000円です！！　よろしくお願いします！！！ https://t.co/mM2T22hfXj pic.twitter.com/TM2sJorjQw

— せきごん@BLE Micro Pro予約受付中 (@_gonnoc) December 29, 2018

Modulo 準拠キーボードに差し込むだけで無線化できる Modulo BT Pendant の Alpha 版がなんとはやくもコミケで登場します！ 1 つ 3000 円。

Ergo42 Towel

白アクリル Ergo42 Towel を 5 台限定会場価格 10,000 円で頒布します。

おわり

というわけで、12/30(日) コミケでお待ちしております。

以上、脱稿後の限界オタクでした。

この記事は Ergo42 Modulo Alpha + Kailh Pro Burgundy + Eucalyn 改で書かれました。

モジュラーな自作キーボードアーキテクチャを求めて

この記事は 自作キーボード Advent Calendar 2018 その 1 の 12日目の記事です。

adventar.org

昨日は IKeJI さんの 今年作ったキーボードまとめ でした。

この記事では Modulo という新しい自作キーボードのアーキテクチャとその展望について紹介します。

30 分前に動くようになった Modulo Series の試金石 Ergo42 Modulo Alpha

Modulo とは

Modulo は名前からもこの記事のタイトルからも分かる通り、モジュラーな設計が可能な自作キーボードアーキテクチャの名前です。大きく分けて、MCU を持つ Pendant Module と、いわゆるキーボートやトラックパッドなどの Input Module の 2 つの Module から成り立っています。

Modulo イメージ図

Modulo について、よく自作キーボードに使われる プロジェクト と言う言い方ではなく アーキテクチャ という言葉を使っていますが、これは Modulo が、私が設計するキーボードに特異な ―たとえば Ergo42 の次世代機― の設計というわけではなく、多くの自作キーボードに適用可能な汎用的な設計・仕組みであることを表しています。もっと言えば、Modulo は自作キーボードにおける 規格のようなもの 、ソフトウェア的な言い方をすれば フレームワーク と言ってもいいかもしれません。

なにがうれしいの？

モジュラーな設計の最大の旨味は、車輪の再発明の大幅な削減が期待できることです。また、自作キーボードの場合、副次的な効果として MCU のキーボードからの分離による小型化・薄型化が期待できます。具体的にどんなうれしいことがあるか、いくつか考えてみます。

• MCU がキーボードから離れるため 小型化・薄型化 がしやすい
• Pendant / Input Module のインターフェースが規定されているので機能の追加・交換・共有が簡単
  • 新しいキーボードを設計するときに Pendant の実装部分については考える必要がない
  • Pendant を Bluetooth 対応のものに差し替えるだけで 追加開発なしに無線化 が可能
• カスタマイズが簡単
  • このキーボードにテンキーパッドがついていればいいのに…というとき新規設計なしに 既存の Input Module の組み合わせでカスタマイズ が可能
  • トラックパッド等のキーボード以外の Input Module も登場予定で簡単に追加ができる

などなど、でしょうか？

前述の通り Modulo をフレームワーク、たとえば Ruby on Rails のアナロジーで考えてみると、みんなで同じ機能を何度も開発せずに、gem を組み合わせてサービスを構築する、というのを想像してもらうとしっくり来るかもしれません。

Why Modulo?

私はもともと ErgoDox という自作キーボードを使っていて、それはそれでメチャメチャにかっこよくてある種の完成形だと今でも思うのですが、それでもいくつか不満点が出てきてしまい、勢い余って Ergo42 というキーボードを自分で設計するに至りました。その顛末については 以前詳しく書いたので そちらを参照していただきたいのですが、Ergo42 でほぼ End Game だなと思っているものの、今度はその開発プロセスに対して不満が出てきてしまいました。

車輪の再発明と学習コスト

近年良く見かける QMK に準拠した自作キーボードの設計は基本的に

• 一体型で、キーボード基板に Pro Micro 等の開発ボードや MCU を直接実装したもの
• 分割型で片手の基板に開発ボード / MCU を、もう片手の基板には I/O Expander 等を実装したもの (ErgoDox 型)
• 分割型で両手の基板ともに開発ボード/ MCU を実装したもの (Let's Split 型)

の 3 つに大別でき、いずれもキーボードの基板と MCU が一体となった設計となっています。市販のキーボードもそういった設計なので、自然な発想と言えます。

ですが、 ぼくのわたしのかんがえたさいきょうのキーボード を自分で設計しようと思うと、すべての機能がキーボード基板に詰め込まれているため、

• 既存の全部入りキーボードの設計を読み解き設計意図を解釈し
• 複数ある実装手段についてそれぞれの比較評価を行い
• すべての機能を改めて自分で実装し直す

というかなり冗長でコストの高い手順を踏まなければいけません。

よくよく考えてみるとわかるのですが、自作キーボードを設計しようという動機の概ねはキースイッチの物理配列を変更したいという要求ではないかと思います。スイッチの物理配列を変えるために、MCU の仕組みやマトリックス回路について知らなければならない、ましてや設計実装まで行わなければいけないのはあまり DRY とは言えません。知らなくていいところはできればブラックボックスとして扱えるようにするのがエンジニアリングの常套手段です。

また、最近では無線化やトラックボールの実装など新たな機能の開発も活発に行われています。それらについても、それぞれのキーボード設計者が個別に調査し重複する設計実装をするのはあまりにももったいない し私がやりたくない ので、自作キーボードにもモジュラーな設計を導入し、エンジニアリングできないかと考えたのが Modulo です。

Modulo の現在とこれから

Ergo42 Modulo Alpha

Modulo は現在開発中でありまだまだこれからですが、5 月に Tokyo MK で展示した原理検証を始めてから、ついにキーボードとして使えるところまではたどり着くことが出来ました！(2018/12/12 現在)

天キーで頒布させていただいた、Ergo42 をベースにした Ergo42 Modulo Alpha が無事動作しており、これにて Modulo の基礎的な技術検証は完了したことになります。Ergo42 Modulo Alpha では Modulo 型の設計により、Cherry MX 互換スイッチを搭載するキーボードとしてはほぼ最薄となる本体厚さ 9 mm も実現することが出来ました。

アクリルの加工精度の問題等改善すべき点はまだまだありますが、一旦キーボードとしては満足して使えるレベルになっています。今後は Ergo42 だけでなく新しい設計のキーボードの横展開も計画しています。

Modulo Track Pad & Modulo BT Pendant

@_gonnoc さんの協力の下、Modulo Series として接続できるトラックパッド Modulo Track Pad と、無線化 Module の Modulo BT (Bluetooth) Pendant の開発が進行中です。今後公開予定の Modulo Series のキーボード / 公開予定の Modulo 仕様に準拠したキーボードに装着するだけで無線化できるようになるよう開発を進めています。

Lime40 with Modulo (仮)

現在 @eucalyn_ さんが開発中の曲面配置キーボード Lime40 の Modulo Series 対応検討を進めています。また、Lime40 のような立体形状 / 空中配線キーボードに使いやすいような Modulo Breakout が計画されています。

C95 (冬コミ)

C95 2日目(日) 東 ナ-18a にて、たのしい人生が出展します！

Ergo42 Modulo Alpha / Modulo Pendant Alpha をベースに Ergo42 Modulo Beta-1 と Modulo Pendant Beta-1 を冬コミにてリリースできればと思っています (届けば)。また、欲張って他のデザインのキーボードの Modulo 版も出せれば出すかもしれません。

同時に Modulo BT Pendant についても、冬コミにて参考出展ないし頒布で準備を進めています！続報をお待ち下さい。

また、この Modulo について詳しく解説した KbD C95 という薄い本もリリース予定です。この記事で興味を持っていただけた方に、より一層詳しい Modulo の情報を提供できる本になる予定です (それ以外にも自作キーボードの情報を掲載予定です)。

Future Work

現在 Modulo Pendant はよく自作キーボードで使われる AVR ではなく ARM Cortex-M シリーズで開発されています。現在のファームウェアは QMK をベースに開発を行っていますが、C 言語書くのが大変とか個人的な趣味とかで Rust で ARM 向けファームウェアを開発する計画もあります (今止まってますが…)。いずれは、ハードウェアの設計のリファクタリングに合わせて、ソフトウェアの方も刷新していけたらたのしそうだなぁと思っています。

また、Modulo はキーボード側の設計がかなり単純化されるので、GUI でキースイッチ配置決めたら基板がポン as a Service できたらいいなぁとは思っています。思ってばっかだなお前。

まとめ

というわけでちょっと駆け足でしたが、いかがでしたでしょうか？ この記事を通して Modulo シリーズや、自作キーボードそのものに興味を持っていただければ幸いです。

そしてそれらに興味を持っていただけたなら、ぜひ Self-Made Keyboards in Japan Discord Server も覗いてみてください。現在 900 人ほどのメンバーでワイワイやっています。Modulo の開発状況の共有や、開発にコミットしてくださる方とのディスカッションの場もこちらになっています。ぜひに。

以上、自作キーボード Advent Calendar 2018 その 1 の 12 日目に記事でした。明日 (今日) 13 日目はみなもさんの オリジナル自作キーボード開発(2D)を早足で説明する です。時空が歪んでいる。

この記事は Ergo42 Modulo Alpha + Kailh Pro Burgundy で書かれました。

The Beauty of Self-Made Keyboards

TL;DR

この記事は、最近話題になっている 自作キーボードを始めた人・これから始めたい人向け に、自作キーボードを実際に使ってみるとどうなのか？本当に使えるの？という疑問を解消するために書かれました。特に 自作キーボードって変な形してるけどちゃんと使えるの？どうやって入力するの？ という点について、自作キーボードでの 具体的な入力方法を動画付きで解説 します。

自作キーボード 実用 入門

最近いたるところで自作キーボードの話題を見るようになり、本当に自作キーボード流行ってきていますね。

speakerdeck.com

qiita.com

techlife.cookpad.com

scrapbox.io

japanese.engadget.com

“究極”のThinkPad X1 Extremeに新型スマートウォッチ、はんだで作るキーボードを生チェック、ポチったのは？ - ITmedia NEWS

【PR】KbD C93 印刷版再入荷しました & Ergo42 complite キット販売中

booth.pm

tanoshii-life.booth.pm

本日開催の 技術書典5 でも、いくつかのサークルが自作キーボードに関連する出展を行っています。今この記事を読んでいる方も、少なからずこういった最近の盛り上がりを見聞きして自作キーボードに興味を持たれたのではないかと思います。

一方で、現在巷にあふれている自作キーボード情報は、自作キーボードの組み立て方法や自作キーボードの完成形の情報等がほとんどで、自作キーボードを作る理由、そして 自作キーボードを使う理由・使うことでどういった事ができるのか についてはあまり言及されていないようです。これは自作キーボードという文化がまだまだ日本では未知で、そもそもどうやって始めていいのかという入門のハードルが高かったことや、自作キーボードで先行していたアメリカでの文化が photogenic な傾向にあり、日本における自作キーボードもこの文化の流れを多分に汲んでいることなどに起因していると思われます。

身近に自作キーボードを使っている人がいれば、実際に自作キーボードを触ったり、使っている人から話を聞いたりする機会が得られるかと思うのですが、まだまだそういった機会は十分には多くはないのが現状です。そこで、実際に私が作っている自作キーボード Ergo42 での打鍵動画を参考に、自作キーボードでどのように入力するのか、自作キーボードだとどううれしいのかご紹介します。

自作キーボードでの入力

まずは動画を観てみてください。

www.youtube.com

Ergo42 は自作キーボードの中ではそれほど少なくないキー数の、いわゆる 60 %キーボードというものに属していますが、それでもご覧の通りファンクションキーはおろか数字キーの行もありません。カーソルキーもありません。ですがご覧の通り数字や、それだけでなく記号もしっかり入力できていますし、この動画ではわからないですがファンクションキーももちろん入力できます。このような少ないキー数でしっかりフルサイズのキーボードと同様の入力ができる、自作キーボードでは常識で一般的には非常識な、いくつかの仕掛けがあります。

ハードウェアとソフトウェア

そもそも自作キーボードの両輪として、ハードウェアとソフトウェアという両方の要素が必要です。ハードウェアは写真で見たとおりスイッチがたくさん並んだものですが、ソフトウェアとしては一般にファームウェアと言われる 押されたスイッチに対応したキーの情報をコンピューターに送る ものが存在します。ハードウェアは自作というのが 見た目にわかりやすい ですが、この目に見えない ファームウェア というものもオープンソースで自分たちでカスタマイズが可能になっていて、こちらのソースコードを変更することで様々なカスタマイズが可能になっています。このカスタマイズ性によって、上記の動画のような比較的キー数の少ないキーボードでも自由な入力が実現されています。

レイヤー切り替え

自作キーボードではずせない、必須の機能としてあげられるのが、 レイヤー切り替え機能 です。この機能はざっくり言うと、ラップトップ PC でよく見る Fn キーと同様のもので、レイヤー切り替えキーを押すことで一時的にキーの配置を変更することができる機能です。例えば、上記の動画で使っているキーマップでは、メインのアルファベットのレイヤー、数字・ファンクションキー・カーソルキー等のレイヤー、記号レイヤーの 3 つのレイヤーを使っています。

Base Layer (アルファベット)

,------------------------------------------------.   ,------------------------------------------------.
| Tab  |   Q  |   W  |   E  |   R  |   T  |  [   |   |  ]   |   Y  |   U  |   I  |   O  |   P  |  @   |
|------+------+------+------+------+------+------|   |-------------+------+------+------+------+------|
| Alt  |   A  |   S  |   D  |   F  |   G  |  (   |   |  )   |   H  |   J  |   K  |   L  |   ;  |  :   |
|------+------+------+------+------+------+------|   |------|------+------+------+------+------+------|
| Sft  |   Z  |   X  |   C  |   V  |   B  |  {   |   |  }   |   N  |   M  |   ,  |   .  |   /  |\/Sft |
|------+------+------+------+------+------+------|   |------+------+------+------+------+------+------|
| Ctrl | GUI  |  App |PrtSc |ESC/  |Space/|Tab/  |   |Back  |Enter/| Del  |PrtSc |=>GAME|=>SYMB|  \   |
|      |      |      |      |~SYMB |RCtrl |Shift |   |Space |~META |      |      |      |      |      |
`------------------------------------------------'   `------------------------------------------------'

Meta Layer (数字・ファンクションキー・カーソルキー等)

,------------------------------------------------.   ,------------------------------------------------.
|   1  |   2  |   3  |   4  |   5  |   6  |  [   |   |  ]   |   7  |   8  |   9  |   0  |   -  |  ^   |
|------+------+------+------+------+------+------|   |-------------+------+------+------+------+------|
| Alt  |  F1  |      |Muhen | Henk |      |  (   |   |  )   | Left | Down |  Up  |Right |      |      |
|------+------+------+------+------+------+------|   |------|------+------+------+------+------+------|
| Sft  |  F2  |  F3  |  F4  |  F5  |  F6  |  {   |   |  }   |  F7  |  F8  |  F9  | F10  | F11  |\/Sft |
|------+------+------+------+------+------+------|   |------+------+------+------+------+------+------|
| Ctrl | GUI  |  App |PrtSc |ESC/  |Space/|Tab/  |   |Back  |Enter/| Del  |Reset |=>GAME|=>SYMB|  \   |
|      |      |      |      |~SYMB |RCtrl |Shift |   |Space |~META |      |      |      |      |      |
`------------------------------------------------'   `------------------------------------------------'

Symbol Layer (記号)

,------------------------------------------------.   ,------------------------------------------------.
|   !  |   "  |   #  |   $  |   %  |   &  |  [   |   |  ]   |   '  |   (  |   )  |   ~  |   =  |  ~   |
|------+------+------+------+------+------+------|   |-------------+------+------+------+------+------|
| Alt  |      |      |      |      |      |  (   |   |  )   |      |      |      |      |   +  |  *   |
|------+------+------+------+------+------+------|   |------|------+------+------+------+------+------|
| Sft  |      |      |      |      |      |  {   |   |  }   |      |      |   <  |   >  |   ?  |  \   |
|------+------+------+------+------+------+------|   |------+------+------+------+------+------+------|
| Ctrl | GUI  |  App |PrtSc |ESC/  |Space/|Tab/  |   |Back  |Enter/| Del  |PrtSc |=>GAME|=>SYMB|  \   |
|      |      |      |      |~SYMB |RCtrl |Shift |   |Space |~META |      |      |      |      |      |
`------------------------------------------------'   `------------------------------------------------'

このようにレイヤーを使うことでキー数を実質何倍にもすることができるため、物理的にかなり少ないキー数でも不足のない入力ができるようになっていて、自作キーボードの 物理的なレイアウトの自由度が高まって います。

長押し

もう一つ、普通のキーボードと大きく異なる自作キーボードの特殊な機能として、長押しでキーの機能を変えられる というものがあります。上記のキーマップだと / で区切られているものが <短押し>/<長押し> のキーマップになっています。この操作は通常のキーボードにはまずないモノでかなりトリッキーですが、うまく使うとより少ないキー数・指の移動量で打鍵をすることができます。個人的におすすめなのが親指の Space キーを長押しにすることで Ctrl キーになるというもので、これがあると Ctrl を小指で押すという不合理から開放されるので、コピペ操作が頻出する方も 目が 5 個の宇宙人 を信仰している方も小指がダメになるリスクを大幅に低減できます。

独自配列

勘のいい方はすでに気づいているかもしれませんが、このように自作キーボードではソフトウェアでキーの配置を自由に決められるので、当然 アルファベットの配置も自由 にすることができます。現在通常用いられているキー配列は QWERTY と呼ばれるものですが、これは歴史的な背景やなんやかんやいろいろあって、合理的な配列ではないという話や実は打鍵速度的にはいいという話等錯綜しているのですが、すくなくとも 指の移動距離は比較的長い配列であることは知られています。

そこで、より合理的なモダンな配列を考えようという話になるのですが、この分野で言うと有名なのは Dvorak 配列で、これはみなさん聞いたことはあるんではないかと思います。ただ、一般に Dvorak 配列のキーボードというものは売っていないため、専用のソフトウェアなどで対応していました(が、外部デバイスから入力されるキーをソフトウェアで差し替えるという操作になるため、不具合が多かったりもしたようです)。

ですが、自作キーボードならキーマップは完全に自由で不具合フリー [要出典] です！こういったカスタマイズ可能なキーボードの出現の流れも手伝ってか、最近では新たな 僕の私の考えた最強のキーマップ が誕生してきています。その中でも、おそらく最も新しい世代のキーマップの一つが Eucalyn 配列です。

eucalyn.hatenadiary.jp

Eucalyn 配列は、Dvorak 配列同様左手のホームポジションに母音を並べることで左右交互打鍵を基本的な設計にしつつ、zxcv のようなショートカットキーとしてよく用いられているキーは QWERTY の位置を保つようにし、vim キーでカーソルに相当する hjkl をカーソルキー型の形状に配置するなど、移行コストを抑えながらホームポジションからの移動量が少ないキーマップを実現しています。

私はこの Eucalyn 配列を改変した Eucalyn 改配列を最近は使っていますが、その Eucalyn 改配列と QWERTY 配列との打鍵比較動画が以下になります。

www.youtube.com

動画中で使った Eucalyn 改配列

,------------------------------------------------.   ,------------------------------------------------.
| Tab  |   ;  |   ,  |   .  |   P  |   Q  |  [   |   |  ]   |   Y  |   G  |   D  |   M  |   F  |  @   |
|------+------+------+------+------+------+------|   |-------------+------+------+------+------+------|
| Alt  |   A  |   O  |   E  |   I  |   U  |  (   |   |  )   |   B  |   N  |   T  |   R  |   S  |  :   |
|------+------+------+------+------+------+------|   |------|------+------+------+------+------+------|
| Sft  |   Z  |   X  |   C  |   V  |   W  |  {   |   |  }   |   H  |   J  |   K  |   L  |   /  |\/Sft |
|------+------+------+------+------+------+------|   |------+------+------+------+------+------+------|
| Ctrl | GUI  |  App |=>BIAC|ESC/  |Space/|Tab/  |   |Back  |Enter/| Del  |PrtSc |      |      |  \   |
|      |      |      |      |~SYMB |RCtrl |Shift |   |Space |~META |      |      |      |      |      |
`------------------------------------------------'   `------------------------------------------------'

動画を見ていただければわかるかと思うのですが、ホームポジションからの移動量が少なくて快適な打鍵ができています。アルファベット配列の変更はそれなりにコストが高いですが、うまくやれば QWERTY とバイリンガルにはなれますので、チャレンジしてみる価値はあります。アルファベット配列の変更 (のよさとその大変さ) については、Eucalyn 配列の考案者である @eucalyn_ と対談した podcast もあるのでぜひ聴いてみてください。

つまり…

ここまで、自作キーボードがどのように少ないキー数での入力を実現しているのか紹介してきました。自作キーボードの写真等を見かけることも多くなったかと思いますが、それらのような特徴的で自由なレイアウトのキーボードが実現できるようになったのも、オープンソースのファームウェアによって キーボードの動作がカスタマイズできるようになった ことが非常に大きな役割を果たしたことがわかるかと思います。

ファームウェアは目に見えないため自作キーボードの重要な一側面であることが伝わりづらいのですが、実際はこのファームウェアのカスタマイズ性のために自作キーボードをやめられないという人もいるほど重要な要素です。また、自作キーボードは通常のキーボードに比べるとかなりキー数が少ない傾向にありますが、大抵の場合、いたずらにキー数を減らしているわけではなく、自作キーボードを長く使っているとだんだんと上記のレイヤー切り替えや長押し等の機能を使いこなして ホームポジションから極力移動しない キーマップに落ち着いていく傾向があり、結果として小さいキーボードにたどり着きやすいようです。

自作キーボードは、ハードウェアのキースイッチの種類で感触や音が変えられたり、キーキャップで好みの見た目にできたりと、 自分だけのカスタマイズ ができることが大きな魅力の一つですが、実はソフトウェアもカスタマイズできて、自分だけのキーマップ・挙動を実現できるのでした。自作キーボードは万年筆のようなもの、と言ったりしますが、万年筆もペン先やインクの粘度・色、そして所有欲を満たすデザインを選んで自分だけの書き味を追い求める、自作キーボードに似た所が多く見受けられます。自作キーボードでデザインにまでこだわる方が多いのも、こういった 日々使う上質なもの に対する執着のようなものがあるのかもしれません。

というわけで、キー数が少なかったりレイアウトが独特だったりしても、意外となんとかなるので、ビビらずにぜひ作ってみて自分だけのカスタムキーボードを作ってみてください。(ハードウェア的に) 完成してからが、本当の自作キーボードだ…

おまけ

本日開催の技術書典5 では自作キーボード島とまでは行きませんが、4 つの自作キーボードサークルが け61 ～ け64 に並んで出展しているほか、場所は散っていますがいくつかのサークルさんが参加されているようです。たのしい人生は今回サークル出展はしていないのですが、 け62 のゆかりやさん、け01 の nopnop さんで既刊 KbD C93 や Ergo42 Towel フルセットキット 等を委託させていただいています (キット販売は け01 nopnop さんのみ) 。

よろしかったらぜひ、本日開催の技術書典5 で立ち寄っていただけたら幸いです。

ギリギリですいません！技術書典5 で け62 ゆかりや (@eucalyn_) さんと、け01 nopnop (@tomykaira_2) さんで、委託販売させていただく事になりました！以前冬コミで発行した KbD C93 はいずれのサークル様でも、Ergo42 / Meishi キットと KbD Pre は nopnop さんでの委託になりますどちらもよろしく🙏 pic.twitter.com/17XqysJUqv

— 人生たの椎名林檎 技術書典5 け62 ゆかりやさん け01 nopnop さん委託 (@Biacco42) October 7, 2018