bouzuya.hatenablog.com

ぼうずやのにっき

ErgoDox EZ 設定日記 (2)

昨日 (2017-05-10) に続き、 ErgoDox EZ で遊ぶ。設定の経過は bouzuya/ergodox に置いている。

  • v0 - v3: 2017-05-10 を参照
  • v4: http://configure.ergodox-ez.com/keyboard_layouts/qgdeyd/
    • Layer を 4 つにした。標準・不足キー・それらのシフト。 Modifier を標準に近い位置へ移動。
    • L0: 記号を削除
    • L2: L0 をシフトしたキーを追加
    • L1: 記号を追加
    • L2: L1 をシフトしたキーを追加
    • L0: Hyper & Meh & Alt+Shift & Application を削除
    • L0: Cmd, Alt, Tab, Esc を移動
  • v5: http://configure.ergodox-ez.com/keyboard_layouts/kombyr
    • L0: Enter & Backspace を親指から小指へ移動
    • L2: L0 から Del を移動
    • L1-L3: TO 0 を親指に追加
    • L1,L3: 記号の位置を左手から右手に移動

PC には ANSI キーボードとして認識させないと期待通りに動かないことが分かった。

現状 OSL (押した次のキーだけ、指定したレイヤーのものを使う) をよく使っているのだけど、もっとモーダルに TO で切り替えて良い気がしてきた。 Vim のようなイメージだ。不満点は Issue 登録するようにしはじめた。変更によって従来解決した問題が再発していることもありそうなので、テストケースをつくっていくほうが良いかもしれない。

文字の入力自体は良くなりそうなんだけど、アプリケーションのショートカットキーが一般的なキーボードを前提にしていることが多いので、使いづらくなりそうだ。まだ、もっと慣れと設定変更が必要だ。

ちなみに、毎日のように同じようなことを書くのは、忙しくてこれくらいしか手をつけられないからだ。

ErgoDox EZ を設定してみた

昨日 (2017-05-09) に届いた ErgoDox EZ を設定してみた。まだ使い物にならない。経過は次のとおりだ。

記号まわりの配置が分からなさすぎて常用できる状態にない。試用しつつ、まだまだ設定を変更していくつもりだ。

せっかくなので、設定の変更方法を覚え書きしておく。

ErgoDox EZのキーマップを変更する の記事によると、 CUI で設定することも可能らしいが、ぼくは GUI で設定した。

まずは公式で提供されている ErgoDox EZ Configurator (Graphical Configurator?) を使って hex ファイルをつくる。

右上の "Clone and modify this layout" を押す。編集可能な clone ができるので、キーを押しては変えていく。希望の形になったら "Compile this layout" を押して確定する。これで↑のぼくの履歴のように共有ができる。

あとは "Download this layout" で hex ファイルが手に入る。ちなみに "Print layout" から PDF にして持っておくと便利だ。

hex の次は "Download flashing tool" で hex を firmware に書き込む tool を手に入れる。ぼくは macOS だ。 Teensy を手に入れた。普段どおり、マウントしてアプリケーションへコピーする。

Teensy を起動すると小さなウィンドウが表示される。そこに hex を D&D する。 Auto ボタンを押して Program と Reboot をまとめて実行させるよう設定する。あとはキーボードのライトの右にある小さい穴 (RESET) をクリップなどで押す。これで D&D した hex が反映される。

物理ボタンを押すのが面倒なので、 RESET を配置してみたのだけど、上記の手順で RESET キーを押すと応答がなくなる。どうしたものか……。

まだまだだ。

ErgoDox EZ が届いた

ErgoDox EZ が届いた。まだ一時間くらいしか触っていないのだけど、第一印象を書いておく。

慣れていないので、ひどくタイプミスをする。理由はキーの物理的な配置だ。一般的なキーボードとは異なり、キーが格子状に配置されているためだ。特に最上段の数字や、下段の ZXCVB などでかなり距離を感じる。

慣れていないので、キーを探してしまう。親指周辺に追加のキーがあるくらいかと思っていたが、実際には縦や横のキーが明らかに足りないので、分かりにくい位置や別のレイヤーに押しやられている。既定の配置が分からないので、チートシートを見ている。

不満のように見えるが、慣れの問題だ。

キーボードのオープンワールドだ。目の前に広がるカスタマイズの世界、果てしなく続くカスタマイズの道を感じる。ぼくの考えた最強の、を地で行く感じだ。

まずは JIS 配列に近づけること、 sticky shift を積極的に使っていくあたりから試していきたい。

ああ、疲れる……。

bouzuya/bbn-json-hs 0.2.0.0 をつくった

昨日 (2017-05-07) のことだけど、 bouzuya/bbn-json-hs の 0.2.0.0 を公開した。

動作は Heroku および Amazon ECS: EC2 Container Service にデプロイして確認した。 Docker イメージを作成できており、手元で動くので、ほぼ間違いなく動くのだけど……。

機能については 2017-05-06 に書いたとおりのもので、 blog.bouzuya.net への Proxy だ。 HTTP リクエストを受け付けて、それに応じた HTTP リクエストを blog.bouzuya.net に投げ、結果を返す。それだけだ。

今回はまだ yesod を使わず、 wai & warp & aeson を使った。素朴な感じだ。また先日 (2017-05-06) は stack docker を使わないと書いたのだけど、結局、方針を変えて使うことにした。以下にその経緯を書く。

「さあ、デプロイしよう！」と思って docker images したら、サイズに 5.98 GB などと表示されていた。さすがに大きすぎる。 stack setup && stack build すると、もうダメっぽい。

いろいろ試行錯誤していて、ふと「ビルド済みの実行ファイル (exe) だけを持っていけば動くんじゃないか」と思い、ためしたら動いた。最近は JavaScript や Ruby ばかりを触っていたので、ソースコードなどをそのまま持っていくのが当たり前になっていた。まさか exe だけで良いとは思わなかった。環境 (インストールされているライブラリ) への依存はあるんだろうけど、そこをクリアできれば exe だけで動くのだろう。推測だし、よく分かっていないけど、動いたので良しとする。サイズも 992 MB 。まだ大きいけど、許容できる。

exe だけを配置することを前提に考えると、最終的に動く環境と類似の環境でビルドしておけば良さそうだ。つまり stack docker を使えば都合が良いということになる。今度は Dockerfile で stack build しないので、 Docker の入れ子になる心配もない。

経緯はこんなところだ。

まだいろいろ試さないといけない。さきの連休で試したかったことがまだ終わっていない。画像アップローダーの作成を通じて、試していきたい。

2017-W18 ふりかえり

2017-W18 をふりかえる。

2017-05 の目標

  • ☑ iOS アプリをつくる (ストアには公開しない)
  • ☑ Haskell でなにかつくる

2017-W18 の目標

iOS は bouzuya/bbni をつくった。 Haskell は bouzuya/bbn-json-hs をつくった。おさらいなのか怪しいので空欄にした。映画やゲームのことは書いた。

今週の記事

iOS は Tutorial のあと bouzuya/bbni をつくった。そこでひと区切りした。

Amazon ECS を試している。良い感触を得ている。

Haskell を実用すべく練習している。基本的な要素を模索しながら学んでいる段階だ。 bouzuya/bbn-json-hs をつくった。まだしばらく続きそうだ。

つくったもの

2017-05-01/2017-05-07

bbni: blog.bouzuya.net for iOS をつくった。 2017-04 にも書いた bbna: blog.bouzuya.net for Android の iOS 版だ (2017-05-04) 。

bbn-json-hs は Haskell の練習用に blog.bouzuya.net の JSON を返す API server だ。 Haskell での構成の確認が主目的だ。詳細はまた書く。

その他

ゲーム『星のカービィ スーパーデラックス』をクリアした。 2017-05-01 / 2017-05-03 / 2017-05-04 に続いて、今日『格闘王への道』をクリアした。プラズマでガードしつつためて攻撃する、攻撃したらまたガード……と繰り返す。ガード不能攻撃だけを注意してかわせば良い。ずるいが、勝ったので良しとする。これでひととおり遊んだはず。しばらくゲームをやめようか……時間がない。まだニンテンドープリペイド番号が 2500 円分くらいあるんだけど……。

この 2017-04 と 2017-05 で Rust -> Java (Android) -> Swift (iOS) -> Haskell の流れで進んできた。業務や勉強会などの都合で振り回されている。 Swift (iOS) 以外はやりたいとは思っていたので、そこまで嫌なわけじゃないんだけど……。 Haskell は (放置されている) PureScript につながるし、 Rust はもっときちんと押さえておいたほうが良さそうだと感じる。

読書。2017 の目標にある『型システム入門 (TAPL) 』やそれに向けての『アンダースタンディング コンピュテーション』が進んでいない。『純粋関数型データ構造』も前半を軽く流し読みしたあとで積まれている。 Haskell の件が一段落したら再開するか……。

2017-W19 の目標

stack docker をためすなど

bouzuya/bbn-json-hs をつくっている。公開分は stack new しただけのものだけど……。

bbn-json-hs は blog.bouzuya.net へ JSON を取得しにいき、簡素化した JSON を返す API server ……になる予定。特に難しい要素はない。簡単なリクエストの処理・外部サービスとの通信・レスポンスの JSON の構築、あとはインフラや CI などを確かめたかった。

あわせて stack docker をためした。 Docker 内で stack のサブコマンドを実行してくれる。詳細は Docker integration - The Haskell Tool Stack を参照。

stack.yaml に docker: enable: true を入れれば有効になる。確かに Docker コンテナ内で実行してくれるのだけど、ビルドされたものや依存関係にあるパッケージなどはすべて Docker コンテナの外(ホスト)側にあって、 volume でマウントしている。だから、そのイメージだけを別の場所に持っていって使えるわけではない。うーん。 persist オプションなどを工夫すればできそうだけど、面倒くさそうだ。

有効にしている場合、ほかの問題がある。別で Dockerfile をつくったときも、コンテナの内側で stack build すると stack.yaml に docker: enable: true が書いてあるものだから、docker の中で docker を使おうとしてしまう。うーん。コマンドラインに指定するか……。そこまでしてほしくもないし、そこまで動きに差が出ないだろうと信じて、結局 stack docker は無効に戻した。

Dockerfile は特に工夫していない。stack setup して stack build するだけのものだ。本来は $HOME/.stack のキャッシュを目的として *.cabal などのタイムスタンプを調整したりしないといけないんだろうけど、面倒なので割愛した。何度も依存関係にあるパッケージをビルドすることになり、検証にひどく時間がかかった。

検索していると Dockerfile には cabal を用いたものばかりで stack を用いたものは見かけなかった。時期や容量の問題なのだろうか。ぼくは面倒なので stack で進めている。イメージも stack build で使われているものをそのまま使っている。手抜きだ。

本当は、今日中にもうすこしつくって Heroku や ECS に載せるつもりだったのだけど、ダメだった。とりあえず、つくるものは決めたので、ゴールデンウィーク最終日の明日こそは。

Yesod をためしている

Yesod を試している。

https://www.yesodweb.com/page/quickstart や https://www.yesodweb.com/book を見ながら試している。まだもやっとしていて「これで大丈夫だ」って感じがない。うーん。

明日は ECS で動かしたいな。