いものやま。

雑多な知識の寄せ集め

Karabiner-Elementsで英数/かなの切り替えをトグルにしてみた。

Macを使っててちょっと困るのが、英数/かなの切り替えがトグルでないこと。

まぁ、トグルでなくて明示的に指定した方が分かりやすい、という人もいるけど、仕事では(残念ながら)Windowsを使っているので、MacWindowsで操作が違うのは、けっこう面倒。
あと、自分の場合、(絵を描くわけでもないけど)マウスの代わりにペンタブを使っているので、ペンを持った状態のままキーを叩こうとすると、右手の親指を動かすことが出来ず、「かな」キーを押しづらいというのもある。

そんなわけで、以前はKarabinerを使ってトグル切り替え出来るようにしてたんだけど、困ったことに、MacSierraになったときに、Karabinerは使えなくなってしまった。
これに困った人はたくさんいて、代替ソフトがいろいろ出てたんだけど、どれも微妙な感じ。

なので、ずっと我慢して、かなに切り替える場合、右手を下に引いて右手の人差し指で「かな」キーを押すとかいう無茶をやってたんだけど、久々に調べたら、Karabinerの後継であるKarabiner-Elementsで英数/かなのトグル切り替えが出来るようになったとのこと。
そこで、Karabiner-Elementsを使って英数/かなのトグル切り替えを出来るようにしてみた。

ダウンロード&インストール

ダウンロードは、以下のサイトから:

Karabiner - Software for macOS

ダウンロードしたら、dmgファイルを開いて、その中に入っているpkgファイルをダブルクリックすれば、インストーラが起動する。
あとは、インストーラの指示に従ってインストールすればOK。

インストールが終われば、アプリケーションフォルダにKarabiner-Elements.appとKarabiner-EventViewer.appがインストールされる。

設定

ここで行う設定は、以下の2つ:

  • 「英数」キーを押したとき、英数/かなをトグルする
  • 'ろ'のキー(右Shiftの左側のキー)を押したときに、バックスラッシュ(\)を入力し、Shift+'ろ'を押したときに、アンダースコア(_)を入力する

後者の設定もWindowsのキーマップに似せるためのもので、何も設定してないとバックスラッシュではなくアンダースコアが入力されるので、 \TeXを使うときに地味に不便だったりする。

何はともあれ、まずはKarabiner-Elementsを起動。
アプリケーションフォルダを開き、Karabiner-Elements.appを開く。

f:id:yamaimo0625:20180114124349p:plain

起動すると、おそらく次のような設定ダイアログが表示されるはず。

f:id:yamaimo0625:20180114130417p:plain

表示されない場合、メニューバーにあるKarabiner-Elementsのアイコンをクリックし、そこから"Preferences..."を選択すればいい。

この設定ダイアログにはいくつかのページがあり、上の画像のページ("Simple Modifications")では、あるキーを別のキーに置き換えるということが出来る。
ただ、今回はそんなシンプルな話ではないので、ここは使わない(使えない)。

ちなみに、"Virtual Keyboard"ページでは、キーボードの種類が選べるので、適切なキーボードになっているか、確認しておいた方がいい。

f:id:yamaimo0625:20180114131150p:plain

今回行うような複雑な設定には、"Complex Modifications"ページを使う。
ただ、その前にJSONファイルを用意しておかないといけない。

まず、ターミナルなどを使って、以下のフォルダを開く:

$ open ~/.config/karabiner/assets/complex_modifications/

ここに、適当な名前のJSONファイル(例えば、my_option.json)を用意して、以下の内容を入力して保存:

{
  "title": "自分用の設定",
  "rules": [
    {
      "description": "英数キーで入力をトグルできるようにする",
      "manipulators": [
        {
          "type": "basic",
          "description": "入力ソースが英字の場合、ひらがなにする(入力ソースがひらがなの場合、上書きの必要なし)",
          "from": { "key_code": "japanese_eisuu" },
          "to": [ { "key_code": "japanese_kana" } ],
          "conditions": [
            {
              "type": "input_source_if",
              "input_sources": [ { "language": "en" } ]
            }
          ]
        }
      ]
    },
    {
      "description": "'ろ'にバックスラッシュ、Shift+'ろ'にアンダースコアを割り当てる",
      "manipulators": [
        {
          "type": "basic",
          "description": "'ろ'にバックスラッシュを割り当てる(Shift+'ろ'は、上書きの必要なし)",
          "from": { "key_code": "international1" },
          "to": [ { "key_code": "international3" } ]
        }
      ]
    }
  ]
}

この詳細については、後ほど。

ファイルが用意できたら、"Complex Modifications"ページを開き、"Add rule"をクリック。

f:id:yamaimo0625:20180114133335p:plain

以下のようなシートが表示されるはずなので、「自分用の設定」の"Enable All"をクリック。

f:id:yamaimo0625:20180114133508p:plain

すると、以下のようになるはず:

f:id:yamaimo0625:20180114133615p:plain

これで完成!

ちゃんと「英数」キーで英数/かなのトグルが出来るし、'ろ'でバックスラッシュ、Shift+'ろ'でアンダースコアが入力されるようになってるはず。

設定の詳細

ここからはオマケ。
上のJSONファイルでうまくいかなかったり、自分でKarabiner-Elementsの設定を行いたい人向け。

まず、Karabiner-Elementsの動作イメージを説明しておくと、Karabiner-Elementsが起動している場合、入力デバイス(キーボードやマウス)で起きたイベント(キーが押された、など)を、直接Macに渡すのではなく、Karabiner-Elementsを経由させてからMacに渡す、という感じになっている。
なので、JSONファイルでは、どのイベントをどのイベントに変換するか、というのを記述することになる。

詳細については、karabiner.json Reference Manual - Karabiner - Software for macOSを参照。

JSONファイルの構成

"Complex Modifications"のルールを記述するJSONファイルの全体構成は、以下のようになっている:

{
  "title": "(ルールセットのタイトル)",
  "rules": [
    {
      "description": "(ルール1の説明)",
      "manipulators": [
        {
          // 変換操作の内容1-1
        },
        ...
        {
          // 変換操作の内容1-n
        }
      ]
    },
    ...
    {
      "description": "(ルールmの説明)",
      "manipulators": [
        {
          // 変換操作の内容m-1
        },
        ...
        {
          // 変換操作の内容m-n
        }
      ]
    }
  ]
}

変換操作の記述

変換操作の記述は、以下のような感じ:

{
  "type": "basic",
  "description": "(変換操作の説明)",
  "from": {
    // 変換元のイベント
  },
  "to": [
    {
      // 変換後のイベント1
    },
    ...
    {
      // 変換後のイベントn
    }
  ],
  "conditions": [ // 変換操作を行う条件(オプション)
    {
      // 条件1
    },
    ...
    {
      // 条件m
    }
  ]
}

なお、toの他に、to_if_aloneto_if_held_downto_after_key_upto_delayed_actionなどもあるけど、省略。
基本的にはtoを使えばいいと思うので。

あと、conditionsはあってもなくてもいい。
指定した場合、条件が満たされたときだけ変換操作が行われるようになる。
今回の場合は、入力が英数のときだけ、「英数」キーを「かな」キーとして働かせることになるので、そのときに使っている。

fromに関して

変換元のイベントの記述は、以下のような感じ:

"from": {
  "key_code": "(入力されたキーのキーコード)",
  // 以下はオプション
  "modifiers": {
    "mandatory": [ // 必須なキー(組み合わせたときにだけ働く)
      "(必須なキーのキーコード)",
      ...
    ],
    "optional": [  // 一緒に押せるキー(組み合わせても働く)
      "(一緒に押せるキーのキーコード)",
      ...
    ]
  }
}

なお、key_codeの他に、consumer_key_codepointing_buttonanyというのもあり、そのいずれかを指定することになっている。
ただ、基本的にはkey_codeでOKのはず。

modifiersは、指定しなかった場合、他のキーと組み合わせたときには働かなくなる。
少しややこしいのだけど、以下のように考えればいいと思う:

やりたいこと modifiersの指定
他のキーと一緒に押されたときは、変換操作をやりたくない modifiersなし
特定のキーと一緒に押されたときだけ変換操作をやりたい modifiersmandatoryを指定する
特定のキーと一緒に押されたときにも変換操作をやりたい modifiersoptionalを指定する

例えば、今回だと、'ろ'のキー("international1")が押されたときにバックスラッシュのキー("international3")が押されたイベントを送るようにしてるんだけど、Shiftと一緒に押されたときにも変換処理が行われてしまうと、縦棒(|)が入力されてしまう。
なので、modifiersなしにすることで、Shiftと一緒に押されたときにはバックスラッシュのキーではなく'ろ'のキーがそのまま送られるようにしている。
(結果として、Shift+'ろ'でアンダースコアが入力される)

toに関して

変換後のイベントの記述は、以下のような感じ:

"to": [
  {
    "key_code": "(変換後のキーのキーコード)",
    // オプション
    "modifiers": [
      "(一緒に押されたとするキーのキーコード)",
      ...
    ],
    "lazy": false,
    "repeat": true
  },
  ...
]

なお、key_codeの他に、consumer_key_codepointing_buttonshell_commandselect_input_sourceset_variableというのもあり、そのいずれかを指定する。
基本的にはkey_codeのはず。

ちなみに、select_input_sourceを使うことで、入力ソースを切り替えるイベントを送ることも出来る。
最初はこれを試して、Safariとかでは問題なく動いたんだけど、ターミナルで入力ソースが切り替わらないという自分としてはかなり致命的な問題が生じたので、素直にキーコードを送るイベントを使うようにしている。

あと、lazyは他のキーが押されるまでイベント変換を遅延させるかどうかという設定、repeatは繰り返し変換を行うかどうかという設定。
まぁ、明示的に指定する必要があるケースはあまりなさそう。

conditionsに関して

変換操作を行うかどうかの条件にはいくつかタイプがある:

タイプ 説明
frontmost_application_if, frontmost_application_unless アプリのバンドル名、ファイルパスの条件
device_if, device_unless バイスの条件
keyboard_type_if, keyboard_type_unless キーボードの種類(ansiやjisなど)の条件
input_source_if, input_source_unless 入力ソースの条件
variable_if, variable_unless 変数の条件

それぞれのタイプで、指定する内容は異なってくる。

今回は、入力ソースが英字のときにだけ変換操作を行いたかったので、input_source_ifを使ってる。

input_source_ifは、以下のような感じ:

{
  "type": "input_source_if",
  "input_sources": [
    {
      "language": "(言語の正規表現)",
      "input_source_id": "(input source idの正規表現)",
      "input_mode_id": "(input modeの正規表現""
    },
    ...
  ]
}

なお、languageinput_source_idinput_mode_idはそれぞれオプショナルなので、特に問題がなければlanguageを指定しておくだけで十分。
ちなみに、これらの値はKarabiner-EventViewer.appを起動して、"Variables"ページを見ると、確認できる。

キーコードの確認について

あと、キーコードの確認も、Karabiner-EventViewer.appを起動すると、出来る。
"Main"ページを開いて適当なキーを押すと、そのキーのキーコードがテーブルの"name"列に表示されるので、それを使えばいい。

なお、"japanese_kana"や"japanese_eisuu"はエイリアスで、本来の名前はそれぞれ"lang1"、"lang2"となっている。
どんなエイリアスが使えるのかは、コードを確認する必要がある。

以下のリポジトリで、src/share/types.hppを参照するといい:

今日はここまで!

pLucidをいじってみた。(その2)

前回はLucidの処理系であるpLucidについて紹介した。

今回はLucidについて触れていきたい。

Lucidとは?

Lucidというのは、前回も触れたとおり、データフロープログラミング言語の1つ。

データフロープログラミング - Wikipedia

Lucid (プログラミング言語) - Wikipedia

自分がこの言語に触れて一番変わってるなぁと思ったのは、変数が数列のように履歴を持つというところ。
なので、プログラミングが、漸化式を書くような感じになってたりする。
まぁ、これは実際の例を見てみないと分かりづらいと思うので、後で。

Hello, world!

とりあえず、新しいプログラミング言語に触れるなら、まずこれでしょ、ということで、Hello, world!から。

LucidでHello, world!を書くと、次のようになる:

`Hello, world!'

ちょっと注意が必要な点としては、最初のはクォートはバッククォートで、最後のはシングルクォートだということ。

これをpLucidで実行するには、まず適当なファイルに保存して(ここではhelloというファイルとする)、以下のようにコンパイル

$ lucomp hello

ただし、これはlucompから呼び出されるpass1、pass2、pass3、pass4、pass5が、PATHの通った適当な場所に置かれているのが前提。
もしこれらがPATHの通った場所に置かれていない場合、以下のようにして、パイプで処理をする:
(ここではpass1〜pass5がカレントにあると仮定)

$ ./pass1 hello | ./pass2 | ./pass3 | ./pass4 | ./pass5 hello

すると、hello.iという中間のバイナリファイルが生成される。

中間のバイナリファイルが生成されたら、次のように実行:

$ luval hello.i

さて、実行したらどうなるのかというと、こうなる:

$ luval hello.i
Evaluation begins .........

output(  0) : `Hello, world!' 
output(  1) : `Hello, world!' 
output(  2) : `Hello, world!' 
output(  3) : `Hello, world!' 
output(  4) : `Hello, world!' 
...(省略)...
output(995) : `Hello, world!' 
output(996) : `Hello, world!' 
output(997) : `Hello, world!' 
output(998) : `Hello, world!' 
output(999) : `Hello, world!'

$

なんじゃこりゃ!?、ってなるよねw

ただ、これがつまり、変数が数列のように履歴を持つということを意味している。

Lucidでは、一番外側にある式が評価され、その値が出力となる。
このHello, world!では、`Hello, world!'という文字列が式になっていて、その値が評価される。

だったら、`Hello, world!'が一回表示されて終わりなのでは?となりそうだけど、そうはならない。
というのも、これは、Lucid的には次のような意味になるから:

 {
output(n) = `Hello, world!' \quad (n = 0, 1, 2, \cdots )
}

そう、outputという変数は、単一の変数ではなくて、数列のように、0番目の値、1番目の値、2番目の値、・・・と、複数の値を含んでいるようになってる。
なので、pLucidはその値を順番に出力していった、と。
(実装的に上限が1000で固定になってるので、999番目の値で出力は止まってる)

うん、変な言語w

Hello, world!(真)

じゃあ、一回だけHello, world!を出力して終わりにしたかったら、どうするか。

数学的に考えれば、次のように場合分けすればいいことになる:

 {
output(n) = \left\{ \begin{array}{ll}
`Hello, world!' & (n = 0) \\
eod & (n \ge 1)
\end{array}
\right.
}

なお、eodは、データの終わりということ。

これをLucidで書くと、次のようになる:

`Hello, world!' fby eod

さっきと同じようにコンパイルして実行すると、以下のような出力になる:

$ ./luval hello.i 
Evaluation begins .........

output(  0) : `Hello, world!' 

Statistical Information about the evaluation
# of memory buckets created    =          0
# of space/time/place tags created   =          3

このとおり、1回だけ出力され、終了する。
(それ以外の出力もなんかいろいろ出てるけど・・・)

ここでポイントとなっているのは、fbyという演算子
これは"followed by"の略で、1回目は左項が評価され、2回目以降は右項が評価されるようになっている。
なので、output(0)は左項が評価されて`Hello, world!'になり、output(1)以降は右項が評価されてeodとなるので、データの終了ということでそこで出力が停止する、と。

ちなみに、fbyは右結合なので、次のように書くと、2つ出力して終わる感じになる:

`Hello, world!' fby `Good bye!' fby eod

実行例は、以下:

$ ./luval hello.i 
Evaluation begins .........

output(  0) : `Hello, world!' 
output(  1) : `Good bye!' 

Statistical Information about the evaluation
# of memory buckets created    =          0
# of space/time/place tags created   =          4

理屈としては分からなくもないけど、なんとも分かりにくい(^^;
アイディアは面白いと思うんだけど、もうちょっと分かりやすい記法はなかったものか・・・


なお、今自分がいじっているGitHubリポジトリは、luvalを実行するとセグメンテーションフォールトが発生するので、ここでの実行例は、おそらくGCCでオリジナルのコードをそのままビルドして作られたバイナリを使ってる。
自分のいじってる方も、そのうちちゃんと動くようにしたい。

今日はここまで!

pLucidをいじってみた。(その1)

最近、pLucidをいじってるので、それについて少しずつ書いていこうと思う。

pLucidとは?

pLucidというのは、Lucidというデータフロープログラミング言語の処理系の1つ。

データフロープログラミング - Wikipedia

Lucid (プログラミング言語) - Wikipedia

新年の挨拶と今年やっていきたいこと。(2018年) - いものやま。で書いた通り、最近データフロー指向というのに興味を持っている。
そこで、どんなデータフロープログラミング言語があるのかなとwikipediaを見てみたんだけど、いくつか言語がリストアップされているものの、HDL(ハードウェア記述言語)でなく、(LabVIEWのような)ビジュアルプログラミング言語でもないものとなると、かなり少ない。
Lucidはそんな条件を満たす言語の1つで、しかもある程度情報があり、pLucidという処理系も一応ある。
ということで、このpLucidをちょっといじっていこうかな、と。

Lucidは、wikipediaによれば1976年に登場した言語で、けっこう古い言語といえる。
C言語が登場したのが1972年とかで、標準化されたのは1990年(ANSI C)。
そして、pLucidはC言語で書かれてるんだけど、そんなわけで、標準化される前のK&Rの文法だったりする。

そんなpLucid、Google Codeにコードがアップされていたんだけど、Google Codeが閉鎖されたので、今はGitHubにコードは移っている。

plucid - Google Code

ただ、Google CodeからGitHubリポジトリをエクスポートしている人は何人かいて、どれが本流なのかがよく分からない・・・
まぁ、どれもオリジナルからほとんど変更していないようだけど。

ということで、とりあえず適当な人のリポジトリからフォークして、自分のリポジトリを作ってみた。

ちなみに、K&R時代のC言語で書かれてたこともあって、かなりハチャメチャなコード。
グローバル変数だらけだし、型もかなり適当。
マクロでけっこう無茶なことやってたり、もう何が何やら・・・

そもそも、Clangだと普通にビルドエラーが起きてビルドが通らなかったり(^^;

なので、とりあえずコードのフォーマットと明らかにおかしいところを修正して、とりあえずビルドエラーと警告を全部消した。
これだけで約33klocの差分w
ほぼすべて書き直しw

これで一応ビルドは出来るようになって、ソースを中間のバイナリファイルに変換するところまでは動くようになった。
けど、このバイナリファイルを解釈させて実際に動作させるプログラムを動かすと、セグメンテーションフォールトになる(^^;
標準のmalloc使えばいいのに、なんか自前で独自のメモリ管理やってるし、グローバル変数だらけで初期化の順番も怪しかったりするんで、たぶんその辺りが原因。
この辺りも、あとで解決していかないとなぁ・・・

さて、肝心のLucidについては、次回で。

今日はここまで!

2017年に初めて遊んだゲーム、ベスト3。

2016年に引き続き、2017年に初めて遊んだゲームで、特に気に入ったものを選んでみた。

2016年、2015年のは、以下から:

なお、2017年は8月くらいからあまりゲームを遊べなかった。
なので、ホントは5つ取り上げたいんだけど、4位と5位が難しかったので、上位3つだけ。
この3つは、とりあえず順位はつけたけど、どれも甲乙つけがたいレベルで好き。

第3位「ボブジテン」

f:id:yamaimo0625:20180104222657p:plain

2017年のゲームマーケット春で発表された、TUKAPONさんのゲーム。

ルールは簡単で、お題のカタカナ語を、カタカナ語を使わないで説明しよう、というもの。
ホントこれだけのルールなのに、めっちゃ面白いw

「ほら、えっと、あれだよ、あれ!」みたいに、言いたい言葉がなかなか出てこないw
普段、どれだけカタカナ語に頼りきってるのかを実感するw

例えば、お題で『エンターキー』とか出てくると、「パソコンのキーボードで入力を確定させるときに押すキー」と言いたいんだけど、「パソコン」も「キーボード」もアウトw
じゃあ、パソコンってカタカナ語を使わないでどう説明するよ、って、ほら、電脳的な箱とか、そんなパワーワードが出てくるw
お題を出す方は、ああでもない、こうでもないと頭を捻るし、回答する側も、まさに忖度を働かせて答えを探っていくのが面白い。

そんな、ただでさえ面白いゲームに、さらに華を添えるのが、トニーの存在。
お題を決めるときにトニーが出てくると、出題者はカタカナ語に加え、助詞も使ってはいけないという縛りが追加される。
なので、「えー、球、二人、棒、叩く、んー、あっ、松岡修造!」みたいな片言にw
そして、トニーが出てるわけでもないのに、なぜか不思議とみんな片言になっていくというねw

これは面白いので、オススメ。
ちなみに、拡張で「ボブジテン2」や「わたしのボブジテン」というのも出てたりする。

第2位「アノウ」

f:id:yamaimo0625:20171230102740p:plain

Trick Taking Partyゲーム賞2017に応募された、与左衛門さん作のトランプを使ったトリックテイキングゲーム。
ちなみに、大賞受賞作。

(今気づいたけど、2017ってことは、今年もやるのかな?w)

アノウというのは、石垣造りの技術者集団で穴太衆(あのうしゅう)というのがいて、そこからつけられた名前とのこと。
実際、トランプを石に見立てて、立派な石垣を作っていくのがこのゲームの目的になっている。

穴太衆 - Wikipedia

各トリックで、1位の人はプレイされたカードから1枚、2位の人は2枚を獲得し、自分の場に並べる。
このとき、自分の場には4つの列が用意されていて、各列には同じスートを並べていく。
ただし、列ごとに上限が決まっていて、左から、1枚、2枚、3枚、4枚となっている。
もし上限を超えてしまった場合、その列は1枚あたり-1点となってしまい、逆に、上限以下で抑えられれば、その列は1枚あたり+1点となる。
なので、場の状況と手札とで相談して、取ることが少なそうなスートは左側に、逆にたくさん取ることが出来そうなスートは右側に置いていくことになる。

これがホントによく出来たシステムで、ある程度はカードが欲しいけど、取りすぎたらマイナス点になってしまうので、ヒヤヒヤしながらカードを取っていくことに。
狙ったカードが欲しければトリックを取りにいくのがいいし、枚数が欲しければ2位を狙っていくことになる。
けど、終盤になってくると、自分の場ももう空きがなくなって、取りたくない状況になってくる。
そんなときに、うっかり2位にさせられてしまって、欲しくもないカードを押しつけられたり(^^;
そして、これはスートに対するビッドと見ることも出来たり。
取るトリック数に対するビッドはよくあるけど、スートに対するビッドは、かなり珍しいんじゃないかな?

それと、トリックをとって列を作っていくと、写真のような感じになっていって、まさに石垣を作っていってる感じになって、すごくいい。
そして、石を高く積みすぎると、崩落する、とw
トリテはあまりテーマを乗せづらいイメージがあるけど、このゲームはテーマとシステムが見事に一致していて、ホント大賞にふさわしい見事なゲームだと思った。

第1位「クイビット」

f:id:yamaimo0625:20171230102757p:plain

可愛い見た目、簡単なルール、対象年齢は7歳から。
そんなゆるふわな雰囲気からは程遠い、ガチゲーム

ルールはホントに簡単で、手札からカードを1枚選んで一斉に公開し、カエルの駒を進めていく。
カエルの駒が、カエルと同じ色の葉っぱか蓮の花に止まれれば、出したカードは手札に戻り、そうでない場合、出したカードは捨てられることになる。
それを繰り返していって、手札がなくなったら、脱落。
そして、最後の1人だけになるか、誰かを1周遅れにさせたら、ゲーム終了。

これだけのルールなんだけど、読み合いがガチw
他の人がどのカードを出すのかがある程度読めるので、あの人はおそらくこのカードを出すはずで、となるとあの人はこのカードを出すはずだから、と、もうひたすら真剣に計算するw
脳汁出まくりw

大人はみんな、こういうゲームはガチよ、ガチw
大人気ない? 大いに結構!
真剣に他人を蹴落とし蹴落とされするからこそ、面白いw

と、そんな感じで、可愛い見た目とは裏腹に、ガチで濃厚なバトルが楽しめるのが、このゲーム。

ちなみに、遊んだときに「このゲーム、対象年齢7歳からなんだって」と言ったら、「確かに7歳から遊べると思うけど、これ、子供泣いちゃうよ?」って言われたw
うん、自分もそう思うw
子供でも遊べるかもしれないけど、本当にこのゲームを楽しめるのは、汚い大人だけw
けど、そんな子供でも遊べるゲームを、大人がガチで真剣に遊ぶからこそ、面白い!

今日はここまで!

新年の挨拶と今年やっていきたいこと。(2018年)

あけましておめでとうございます!
今年もよろしくお願いします!

f:id:yamaimo0625:20180102155429p:plain
初日の出@大洗 with 5LINKS and KhodaaBloom

ということで、今年やっていきたいことのリストアップ。

全般

もうちょっとね、更新頻度をね(^^;

今年はゲームとアニメに割く時間をちょっと減らそう・・・
代わりに、コードに触れる時間をもっと増やしていきたい。

技術

去年の振り返りでも触れたとおり、今、興味を持ってるのが、コンパイラと実行環境のところ。
それに関して、アウトプットを出していきたいな、と。

具体的には、以下のとおり:

  • 『OS自作入門』の続き
  • System Verilogやハードウェア周り
  • データフロー指向

データフロー指向というのは、聞きなれない言葉だと思うんだけど、これが今自分が注目しているパラダイム
System VerilogなどのHDL(ハードウェア記述言語)も、大枠としてはデータフロー指向に含まれたりする。

データフロープログラミング - Wikipedia

データフロー指向というのは、まぁ古いパラダイムで、関数型言語の親戚みたいなもの。
関数型言語が発展していく中で、(おそらく実用性、汎用性に難があって)忘れ去られてしまったんだと思うんだけど、これが見直されてくるんじゃないかな、と。

関数型言語が注目されている原因の一つは、並列処理をうまくかけるんじゃないか、という期待があるから。
コアの数が増えてくると、その能力をフル活用するには、処理を複数のタスクに分割し、並列処理をしていってやらないといけない。
けれど、これが普通の手続き型だと、並列処理を間違いなく書くというのは、かなり難しかったりする。
そこで、副作用を持たない関数を使ったり、その解決を遅延させるようにして、並列処理をうまいこと動くようにしよう、と。

ただ、関数型言語Haskell)に触れてみて分かったのは、そんなにうまい話にはなってないな、ということ。
というのは、確かに、純粋関数の部分だけみれば、その実行の順番には依存がなく、ある関数が他の関数から必要とされたタイミングで処理が実行されるので、人間が処理の順番を考える必要がないようになっている。
けど、ここにモナドが関わってくると、厄介で。
モナドというのは、結局のところ、関数の合成をやっているので、その中の関数は必然的にシリアライズがかかってしまう。
(だから、状態を扱えるようにもなるんだけど)
そして、Haskellの場合、一番トップレベルの関数はmainというIOモナドなので、それだけだとうまく並列化はされない(はず)。
ちゃんと並列処理を行うには、それなりにいろいろやらないとダメらしく、それだけで本が一冊出てるくらい・・・(読んだことはない)

そこで注目したのが、VerilogなどのHDL。
HDLは、本質的に並列な処理を記述するので、データを処理する各モジュールを記述し、その繋がりを定義して、あとはデータを流すだけ、となっている。
実は、これはモナドの考えに近くて、モナドではある一つのデータ(状態だったりリストだったりIOだったり)に関する関数を並べていった1つの関数を定義して、最後にその関数に対象のデータをポンと流す、となっている。
データフロー指向というのはその考え(モナド)の拡張になっていて、モナドだと(暗に)流れていくデータは(そのモナドの中で)1つだけだったけど、どのデータも関数の繋がりの中を流れていくものだとして、各関数の処理と、その関数間のデータの流れを記述していくことになる。

まぁ、ホントにこれでちゃんと処理が進むのか、普通の処理が書けるのかは、だいぶ怪しいと思うので、そういったところも含めて、いろいろ試していかないとなんだけど。
それについては、またそのうち。


ここからはオマケ。

一昨年、去年に引き続き、今年も大洗で初日の出を見てきた。

これまではロードバイクで大洗まで自走してたんだけど、今年は体調も不安だったので、別の方法で。
そう、5LINKSが今年はあるからねw

出発〜水戸

12月31日の午前中に水戸のビジネスホテルを予約し、年越しそばを食べてからの出発。
最寄駅まで5LINKSで行った後は、輪行状態にして輪行
柏駅特急券を購入し、特急ときわに乗れば、あっという間に水戸に到着w

今回泊まったのは、コートホテル水戸というビジネスホテル。

f:id:yamaimo0625:20180102173023p:plain

ここがなかなかに優秀だった。
水戸駅から徒歩10分弱と近く、素泊まりで4,500円と安い。
1Fにはデニーズ、近所にはマクドナルド、それにセブンイレブンも。
部屋も清潔で、加湿機能付きの空気清浄機も置いてあり、ユニットバスではあるものの、アメニティもバッチリ。
さらには1Fには無料のコーヒーメーカーまであって、至れり尽くせり・・・
もちろん、折りたたんだ自転車も、嫌な顔されず、ちゃんと室内に持っていけた。
一昨年泊まったビジネスホテル六号に爪の垢を煎じて飲ませたい。。。

さて、そんなわけで21時にチェックインして、セブンイレブンで軽い朝食を確保し、ジルベスターを見ながら年を越して、4時まで仮眠・・・
だったんだけど、枕が合わなかったのか、全然眠れなかった(^^;

水戸〜大洗

軽い朝食を食べ、シャワーを浴びたら、チェックアウト。
輪行状態を解除し、ライトの電池が切れかかってたのでセブンイレブンで購入して、出発したのが5時20分頃。

f:id:yamaimo0625:20180102174908p:plain

ルートは簡単で、国道51号をひたすら走っていくだけ。
そして、途中で県道2号に入れば、大洗はすぐそこ。
距離にして、10km強といったところ。

途中、県道2号に入ったところから、渋滞がすごいことになってた。

f:id:yamaimo0625:20180102175145p:plain

みんな、大洗海岸を目指してるのね・・・
まぁ、自転車なんで、渋滞もなんのその、華麗にスルーしていくのだけど。

そんなこんなで、6時頃に大洗駅に到着。

f:id:yamaimo0625:20180102175440p:plain

駅にはラッピングバスも停まってた。

f:id:yamaimo0625:20180102175640p:plain

f:id:yamaimo0625:20180102175658p:plain

f:id:yamaimo0625:20180102175712p:plain

f:id:yamaimo0625:20180102175729p:plain

海岸近くのコンビニはトイレが行列になってるのが必至なので、ここでトイレを済ませ、いつもの海岸へ。

と、ここで思わぬ遭遇がw
鳥居下の交差点に行ったら、なんと、KhodaaBloomの白いFarnaに乗った人が!
おそらく、去年、潮騒の湯に行ったときに停めてあった人!

思わず声をかけ、写真を撮らせてもらってしまったw
そのあと、自分はそそくさと退散してしまったけど、今思えば、もうちょいいろいろと話しておけばよかったな(^^;

初日の出

さてさて、そんなことがありつつ、初日の出。

今年はけっこう雲がかかってたけど、無事見れたので一安心。

f:id:yamaimo0625:20180102180941p:plain

f:id:yamaimo0625:20180102181030p:plain

ちなみに、ガルパンの立て看は、今年もあったw

f:id:yamaimo0625:20180102181132p:plain

f:id:yamaimo0625:20180102181145p:plain

f:id:yamaimo0625:20180102181205p:plain

潮騒の湯

初日の出も見終わって、じゃあ初詣に行こうと思ったんだけど、ここで一つ困ったことが。
なんと、持ってきた自転車用の鍵が、壊れてしまっていて使えないという事態に。
ママチャリとかならいざ知らず、5LINKSの自転車は10万はするので、さすがにこれを鍵なしで停めておくのは怖すぎる・・・

ということで、一旦お茶を濁すべく、潮騒の湯へ。
潮騒の湯なら、最悪輪行状態にすればフロントで預かってもらえると思ったので。

この読みはドンピシャで、輪行状態にして、フロントで預かってもらえることになった。
ホント、助かった・・・

湯けむり作戦セットをチョイスして、まずはご飯。
お刺身とあんこう鍋のセット。

f:id:yamaimo0625:20180102181930p:plain

あんこう鍋は、最初食べたときに食べ方がよく分かってなくて、骨のある部分をガリっとやっちゃって失敗したんだけど、それで学んだので、今回は骨のある部分はちゃんと取り除いて。
そうやって食べると、ぷりぷりの白身がすごく美味しいね、これ。
お刺身も美味しくて、大満足。

鍵をゲットしに

ご飯を食べた後は、お風呂に入って、そのあと、ちょいと検索。
調べてみると、自転車屋はいくつかあるっぽかったけど、多分お休み・・・
と、ここで、100均にならもしかして売ってるんじゃないかと思いつき、検索。
すると、キャンドゥが大洗にあることが発覚!
さっそく向かってみた。

ちなみに、潮騒の湯を離脱するときにちょいと見てみたら、あの白いFarnaがやっぱり停まってたw

さて、まず自転車屋を見て回ったけど、どこも予想どおりでお休み。

なお、関係ないけど、寄せ木戦車専門店なんてのがあったw

f:id:yamaimo0625:20180102183021p:plain

f:id:yamaimo0625:20180102183039p:plain

クオリティすごっ!

で、肝心の100均・・・
ここで無事、鍵をゲット!
もし、鍵をゲットできなかったら、今回はいろいろ諦めて帰るしかないと思ってたので、これで一安心。

大洗シーサイドホテル

鍵も無事手に入ったことだし、磯前神社に初詣に行こうと思ったんだけど、ズラっと長い行列が・・・
これはちょっと待って、お昼時を狙ったほうがいいんじゃないかな、と大洗シーサイドホテルに行ってみた。

フロントでは、巨大ボコと新年のボードがお出迎え。

f:id:yamaimo0625:20180102183817p:plain

そして、レストランで戦車ケーキセットを注文。

f:id:yamaimo0625:20180102183713p:plain

このケーキセット、普通に美味しいんだよね。

そのあと、メニューにあったあんこう天丼が美味しそうだったので、食べきれるかどうか少し不安だったけど、注文。

f:id:yamaimo0625:20180102184253p:plain

いやー、これも美味しかった。
あんこうの身とあん肝も揚げられてたり。
そして、ボリュームたっぷりw

磯前神社

お腹もかなり膨れたので、磯前神社へ初詣。
ちなみに、行列は全然短くなってなかった(^^;

寝不足でかなり朦朧とした状態で列に並び、参拝するのに1時間くらいかかったw

f:id:yamaimo0625:20180102190249p:plain

f:id:yamaimo0625:20180102190304p:plain

散策〜帰路へ

初詣も済ませたので、あとは商店街をさらっと散策し、15時には大洗を出発。

f:id:yamaimo0625:20180102190705p:plain

f:id:yamaimo0625:20180102190734p:plain

f:id:yamaimo0625:20180102190747p:plain

f:id:yamaimo0625:20180102190802p:plain

f:id:yamaimo0625:20180102190822p:plain

f:id:yamaimo0625:20180102190846p:plain

秋山殿はもふもふ可愛いなぁ・・・

ちなみに、大洗〜水戸の車両が、ちょうどラッピングされたものだったw

f:id:yamaimo0625:20180102190917p:plain

今日はここまで!

ブログの今年一年を振り返ってみた。(2017年)

2017年も終わりなので、ブログの今年一年を振り返ってみた。

全体

まず、全体的なところから。

更新頻度

もうこれは酷いとしか言いようのない状態で・・・(^^;
特に、9月以降はよくて月1回、11月は投稿0という酷い有様。

これは原因はハッキリしていて、一つはアニメとゲーム。
ついついそっちに流れてしまって、全然勉強やブログに時間を割けていなかった。
FGOとか・・・

もう一つは、体調的な問題。
9月頭に筑波山まで自転車で行ったんだけど、その後から体調を崩してしまって、頭痛と37度前後の微熱が地味に続く状態が続いたり・・・
普段は寝れば大抵の頭痛は治ってたんだけど、なかなか治らないもんだから、念のために脳神経外科に行ってCTを撮ってみたり(結果は問題なし)、普段通ってる医者で薬を処方してもらったり。
なんやかんやで10月中頃には治ったけど、そんなだったから、あまり無茶をする気になれなくて、ゲーム会に行く頻度も落ちたし(これは別の要因も大きいんだけど)、自転車で長距離走るのも控えめに。
で、休日も体力回復のためにダラっとアニメ見たりゲームしたり寝てることが多かった(^^;

来年はもうちょっとアニメとゲームを控えて、体力ももう少し戻し、アウトプットを増やしていきたいところ。

内容

さて、そんなわけで、今年書いた記事はそもそも数が多くない・・・

だいたい、次のような内容:

  • 技術
    • OS自作入門
    • LilyPond
  • ゲーム
  • 自転車
  • 昔のブログで書いた記事の紹介
    • 言語に関する考察

『OS自作入門』は読み途中なんだけど、コンパイラを導入するのにそれなりに気合が必要なので、ちょっと止まってる。
あと、Lilypondの勉強や音楽理論の研究も同様・・・
この辺りは、来年ちゃんと再開できればいいのだけど。

アクセス数

去年は更新頻度が下がってもアクセス数自体は伸びてたんだけど、今年はさすがに減った感じ。
強化学習の記事もアクセス頻度下がってる感じだし。

はてなカウンターがサービス終了してしまったので、今年はGoogle Analyticsのデータ。
なので、去年とは単純に比較できないけど、以下のような感じ:

ユーザー セッション
1 10822 13079
2 9223 10995
3 9057 10827
4 8983 10862
5 9358 11563
6 7993 9721
7 7381 9044
8 7126 8585
9 7162 8559
10 7605 9246
11 7246 8685
12 6482 7791

(※12月は12/29まで)

う〜ん、やっぱりちゃんと更新しないとね(^^;

今年の目標の振り返り

さて、今年やっていきたいと挙げていたのは、以下のようなこと:

お、おぅ・・・
一応、LilyPondを入れはしたけど、全然達成できてない。。。

まぁ、これはやりたいことの優先度が自分の中で変わったというのもある。

今、自分が興味を持ってるのが、コンパイラやそれを動かすための実行環境という部分。
実のところ、『OS自作入門』を読み始めたのも、そのための勉強という部分が大きかったり。
他には、最近だと『ディジタル回路設計とコンピュータアーキテクチャ』というのを読んだり、『きつねさんでもわかるLLVM』を読んでいたりする。

30日でできる! OS自作入門

30日でできる! OS自作入門

ディジタル回路設計とコンピュータアーキテクチャ 第2版

ディジタル回路設計とコンピュータアーキテクチャ 第2版

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

きつねさんでもわかるLLVM ~コンパイラを自作するためのガイドブック~

なんでこの辺りに注目してるのかを説明するのは、仕事の話も出てきて話せないことがちょこちょこあるので、ちょっと難しい・・・
すごく端的にいうと、ハードが拡張されていっている現状に合わせて、ソフトも新しいパラダイムを獲得していかないといけないと思っているのが、その理由。
もっとも、実際にはずっと昔に作られて、そして忘れ去られてたパラダイムなので、再発見されなければならない(そして、焼き直されなければならない)という感じなんだけれども。

まぁ、それについては、いずれまた。

人気の記事

さて、今年アクセスの多かった記事は、と紹介したいところなんだけど、確認してみると、上位に来てるのはどれも2016年や2015年の記事・・・
まぁ、今年はほとんど更新しなかったから、仕方ないのだけど。

とりあえず上位3つだけ挙げておくと、以下のとおり:

今年書いた記事で上位に入ってたのは、以下のようなところ:

ちなみに、『21世紀の貨幣論』はホントに面白かったので、オススメ。

21世紀の貨幣論

21世紀の貨幣論


といったところで、短めだけど、今年はおしまいかな。
来年こそは、ちゃんと更新していこう。

今日はここまで!
良いお年を!

『劇場版 カードキャプターさくら 封印されたカード』を観てきた。

カードキャプターさくら』の劇場版2作目、「封印されたカード」が、今日12月29日からリバイバル上映だった。
ということで、さっそく観てきた。
とりあえず2回ほどw
その感想とか、簡単に。

f:id:yamaimo0625:20171229190426p:plain

実のところ、この「封印されたカード」は、自分の中でとにかく特別な作品で。

そもそもの話、マンガやアニメが好きになった原因というのが、高校のとき、駅から高校までの道の途中に貼ってあった1枚のポスター。
それが何を隠そう、「封印されたカード」のポスターw
冒頭のバトルの青い衣装を着たさくらが描かれたもので、当時は当然さくらなんて知らなかったわけだけど、この可愛い子はなんなんだろう、と気になって。
そこから、いろいろ調べて『カードキャプターさくら』という作品に行き着き、学ランでめっちゃ恥ずかしい思いしながら少女マンガのエリアに入って行って、単行本を買い集め、さくらちゃん可愛いとどハマりしていった。
ここからさらに、『東京BABYLON』を読んで4巻の話に頭をガツンと殴られて、もうそこからはCLAMPにどハマり。
CLAMPの商業誌は全部集めて、「CLAMP研究室」(not「CLAMP研究所」ーー研究所の方は公式)なるHPをYahooジオシティーズで作ったりして・・・
そして、長屋(文化部部室棟)の影響で他のアニメなども見始めるようになって、今に至る、と。

「封印されたカード」は、そんなわけだから、完全にハマったときにはもう上映してなくて、DVDで鑑賞。
思えば、初めて買ったDVDかもしれないw
そして、その作品の構造に非常に感激したのを覚えてる。
こんなに劇中劇をうまく使って心の葛藤を引き出させ、さらには、さくらに思っていることと真逆のことを言わせるとか。
どんなドSだよ!
そんな、すっごいツラいところからの、ラストへの繋がり・・・
締め上げて締め上げて、めっちゃ締め上げ切ったところからの解放!
もうね、これをなんと言い表したらいいのかと。

それに、小狼に自分の想いを伝えたいのになかなか伝えられないさくらちゃんがめっちゃ可愛かったり、たまに挟んでくるギャグが小気味よかったりと、もうホントに素晴らしい。

が、そう。
知ったときには、もう上映は終わっていたわけでーー
こんな素晴らしい作品を、しかし、知ったときにはもう二度と劇場で見られる機会はないと知るというね。。。

けど、そこから時が流れること約17年、今年1月に劇場版1作目がリバイバル上映されることに。
否が応でも高まる、2作目ーーすなわち、「封印されたカード」も、リバイバル上映されるんじゃないか、という期待。
(と同時に、なんで2作目じゃなくて1作目がリバイバル上映なんだよ、という憤慨も少し)

そこからさらに時は流れ、とうとう今年9月に2作目もリバイバル上映が決定!
もうね、喜び勇んで前売り券を買いに行ったよね。

そして、そこからさらに3ヶ月経ち、とうとう今日。
17年越しの念願叶って、「封印されたカード」を劇場で観ることが出来た、と。

もうDVDは何度も観てるから、ストーリーとか全部知ってるわけだけども、やっぱり劇場で観るのは違う・・・
積もり積もった想いが大きすぎて、ホント何でもないシーンでもそのあとの展開とかを思い出したりしてしまって思わず涙ぐんでしまったり、観たいとずっと思ってきたものが観れているというその事実だけでもう胸が一杯になってしまって、もうホントにダメ。
終始、ボロボロだった。

最初から何回か観ようと思ってたんだけど、これは続けて観るのはダメだと思って、時間を空けて2回目を観てきた。
こちらは少し落ち着いて観れて、でも、やっぱりいい作品なわけで、最後は涙腺がね。
ホント、いい作品だよーー

で、まだ上映は続くようなので、あと何回かは観に行く予定。
とりあえず、直近で明日3回目を観てくるw

ちなみに、入場特典はさくらとケロちゃんだったw

f:id:yamaimo0625:20171229200205p:plain

さくらのTVシリーズをある程度見てることが前提になるんで、万人に勧められる作品ではないんだけど、ホントに素晴らしい作品なので、興味のある人はこの貴重な機会にぜひとも観てもらいたいなぁ。

今日はここまで!