Hatena::ブログ(Diary)

主にボードゲームやプログラミング - k.bigwheelの日記 このページをアンテナに追加 RSSフィード Twitter

2016-08-07

Ergodox Ez買ってキーマップ変更までしてみた

この記事はとりあえずErgodox周りで感じたことなどをまとめるので割ととりとめないです。

購入動機

ErgoDoxを購入して人生がバラ色になった - YAMAGUCHI::weblog

などのページを見ててどうしても欲しくなったため購入。

キーボードへの出費としては今使っているRealForce 91(20k)を超える34K円の価格。

最近肩こりがひどくて、その原因が社内で使っているHHKが原因でないかと考えているのが1点。

社内で使っているMacBookProはディスプレイを1枚でも多く使いたい関係で閉じることができず、必然普通のフルキーボードは置き場所に厳しいのが1点。

昔からキー配置をいじるのが好きで試行錯誤を繰り返していたのだけど、Windows/Mac/Linuxと全環境でそれぞれのキー配置設定を行うのが辛くなってきて、またソフトウェア側でキー配置をいじるとペア・プロするときに問題があったり他人のPCを触るときにキー配置の違いで軽く困ったり、意図せず特定のキーをキー配置からなくしてしまって最悪OSログインできなくなるようなリスクがあるのでOS側でキー配置をいじるのが嫌になり、ハードウェア側に配置を焼き付けられるようなキーボードが欲しかったのが1点。

注文から到着までの日数

公式サイトから購入。先駆者のレポートだと数カ月や2週間という記述が多かったので1ヶ月ぐらいは覚悟していたのだが実際には購入から到着までわずか8日しかかからなかった。安定して供給できるようになって到着までの時間が短くなっている模様(あとで比較的新しいレポートを読んだらやはり8日で届いたという記述があった)。

配達は海外から国内まで一貫してUPSだったのだが、ここ18時以降は配達してくれないらしく社会人が平日受け取るのはなかなか厳しい感じ。

到着から組み立て

僕は組立済みフルセットを買ったのでケーブルつなぐだけでとりあえず使えるようになった。

キー配置の試行錯誤

デフォルトのキー配置は最初から使うつもりがなかった。

理由は僕がQWERTYと大きく異なる配置を使うつもりがないから。

エンターの位置が違うのはいいとしてもCtrlや特に日本語入力を切り替えるためのキーがないこと、なにより数字キーがQWERTYとずれているのは許容できない。

(ちなみになぜQWERTYとの互換を気にするかというと今後もErgodox以外のキーボードを使う機会や、あるいはErgodoxを脱却する可能性を見越しているため。また他人に自分のキーボードを打ってもらう時や逆に自分が他人のキーボードを打つときになるべく混乱を起こしたくないから。数字キーとか1列ずつQWERTYとずれているものに慣れると戻った時にひどいことが起こるのは目に見えている。この辺はDVORAK配列を試した時の教訓から)。

先駆者兄貴の記事から方法を調べてキー配置を流しこむ方法を確立。

その後は少し変えてはキーを打って感触を確かめる、を繰り返して最終的に落ち着くキー配列までたどり着いた。

かかった期間は約2週間、作業時間はながら作業で約10~15時間程度。

ただしこの時間はいろいろ試行錯誤しつつ最適なキー配置を目指しながらだったので、

自分の中でこういう配列にしたいという確固たる方針が決まっていればもっとさっくり終わるとは思う。

作成したキーマップ

Ergodox Ez Apple JIS キーボードに寄せたキーマップを晒す - Qiita

自分が忘れないためにも、このようなキー配置に至った背景を書いておく。

まず、僕が作ったキー配置は基本的にMACのJISキーボードと極力配置を合わせており、Ergodox defaultをMac JISキーボードに合わせたような配置にしている。

既存のキーボードへ極力準拠している理由は今後も普通のキーボードと併用していくことを考えているから。

今回買ったErgodoxは仕事用で会社に持っていくつもりだが、自宅ではRealForceを使い続けることになる。

また仕事柄他人のPCやサーバキーボードを利用する機会もあり、そのような機会に余計なリスクを持ちたくないため。

またErgodoxもいつまで使うかわからない。いつかまた別の配列キーボードを購入した時、またそのキーボードのためにキー配置を大きく変更することは不毛。

よって基本的に既存のQWERTYへ準拠した配置にしている。

準拠の対象がMACのJISキーボードであるのは現在使っているキーボード配列の中で最も使いやすいから。

まあ結局のところ違うのは日本語入力で、Ergodox EZ を使ってみよう - Qiitaでも述べられているが日本語入力のON/OFFをそれぞれ1キーで行うのが使いやすい。半角全角キーがいらないためErgodoxでは数字キーの行をよりQWERTYに近い配置にできるという利点もある。

あと追加しているのはErgodoxのファームウェア流し込み用のRESETボタン程度でLAYER1,2はほぼ変更していない。

LAYER1,2はまだほとんど使っていないため、今後使っていく中で変更したくなるかも。

キー入力速度を測ってみた

2時間ぐらい前にやっとキー配置に満足してこの記事はそのErgodoxを使って書いている。

タイピングソフトを利用して普段使っているRealforce91とどの程度速度差があるか測ってみた。

f:id:den8:20160807153355p:image

f:id:den8:20160807153356p:image

前者がErgodoxで後者が今まで使っていたRealforce

こんな感じでErgodoxの方もすぐ慣れてそこそこの速度でタイピングできるようになっている。

ちなみにこれ最初に実行したのがErgodoxだったので問題に対する慣れによりRealforceのほうが有利なのだけど、それほど差が出ていない。

慣れていない状態でこれだけでているのですぐにErgodoxの方での入力速度もRealForceに追いつきそう。

これから購入する人たちに対する奨め

Ergodox Ezは完全に組立済みの製品を送ってくれるため、組立作業は一切要りませんが一方で実用的に使用するためにはキーマップの書き換えがほぼ必須です。

キーマップの流しこみ手順はErgodox EZ を使ってみよう - QiitaErgoDox EZのキーマップを変更する - Qiitaの記事などで非常に丁寧に説明されていますが、それでも最低限C言語の知識は必要になります。

現実的にはプログラム経験のある人でないと厳しいでしょう。

もしキー配列を変えないのであれば、むしろKINESISでいいかもしれません。

値段は上がりますがErgodox Ezのデフォルト配列に比べれば比較的素直なキー配置になっています。

また、まだ3万円超と非常に高価なデバイスですのでキーボード作業を頻繁に行わないような人も費用対効果が薄いでしょう。

キー配置自体、まだ日本語入力用のデファクトスタンダードのようなものは認知されておらず各々が試行錯誤しながら自分のキー配置を決めている段階です。

自分でキー配置をいじるようなことを過去にしてきた、またはこれからする覚悟のある人間でないと難しいでしょう。



もし購入することを決断したら、はじめてのErgoDox EZ購入ガイド - Qiitaをチェックすることをおすすめします。

僕は勢いで買ったのでものが届いてから印字されたキーキャップと印字されていないキーキャップはキーキャップの形も違ったことなどを知りました(幸いフラットでないほうが良かったので後悔せずに住みましたが)。

キー配置については現状は各々考えがあると思います。

好みや経験によって人により最適な配置は違うと思うのでこうすれば良いというのはないのですが、

先駆者が推奨しているRESETキーの配置だけは絶対にやっておくことをおすすめします。

理由はそこにも書かれている通り非常にRESETボタンが深いためで、シャーペンも安全ピンもない我が家では部屋中探しまわって細長いものを探しました。

届いたら、個人的にはすぐキー配置を変更し始めることをおすすめします。

Ergodox Ez標準のキー配置はレイヤー等独自の概念を覗いたとしてもかなりの変態であり、特にキーボード最上段の数字キーがずれている点と左手小指左側のCtrl/Caps/Tab等が全く違う点、日本語入力用の英数/かな/入力切替等がまったくない点などそのままでは多くの人が使いづらいと感じるはずです。

それに合わせると決めて全力でデフォルト配置になれるのも一つですが、僕はデフォルト配置はなるべく使わずすぐに自分の使いやすいように変更することをおすすめします。

その際、できるだけ集中して素早く自分のキー配置を決めることをおすすめします。ここでだらだらするとErgodoxを使わないまま机の脇において使い慣れたキーボードを使ってしまい、そのまま誇りをかぶらせて3万円の置物にしてしまいます(Ergodox挫折する人がいると聞きましたが大方が自分のキー配置を決める手前で挫折するのだと思います)。

僕も自分のキー配置を決めるまで2周間かかりました。自分に最適なキー配置を試行錯誤していたためですが、動画等見つつながら作業で10時間以上はかかったと思います。もともとキー配置などを最適化することが好きだったためずっと楽しみながら作業していたのですが、すぐ使いたい人にとっては結構な苦痛かもしれません。

蛇足

Ergodox、これ完全ワイヤレスだったら+1万払っていいという人は多そう。というか僕は出す。

Ergodox Ezがワイヤレス版をリリースしてくれないかなあ。してくれたら今回買ったのは会社用にしてワイヤレスのを自宅用で追加購入するのだけど。

今後できたらいいなあと思うもの

Ergodox用のキー配置を共有、評価できるような専用サービスがあると便利そう。

あとkeymap.cをアップロードすると自動でコンパイルしてhexファイルをダウンロードできるようなサービスもあると便利だけどC言語だからセキュリティ関係の問題で厳しいか。

2015-02-26

lol中に激しいラグが発生したため調査したこと その後1

本日、以前と同じ現象がゲーム中に発生した(logsoflagの可視化結果はこちら)。

pathpingコマンドとpingコマンドでパケットロスが発生する箇所を調べたところ、やはりルータを出て直ぐの箇所(tok7nn1m3.vectant.ne.jp)だった。

おそらくマンション内にかなり近いところで問題があるとかんがえられるため、NTTフレッツのサポートへ連絡する。

続きを読む

2015-02-07

lol中に激しいラグが発生したため調査したこと

現象

lolをプレイ中にaaの間隔が不規則になったり移動がキャンセルされたり(ラバーバンド現象)敵やミニオンが瞬間移動するような現象が発生した。

目的

プレイ精度・ストレスを改善するために問題原因・解決法を見つける

調査過程

一緒にプレイしている友人に依頼してLogs of Lagを利用してネットワークログを調査した結果、以下のことがわかった。

  • 上記現象を感じたときは http://logsoflag.com/#N7Jcqlkw1VP のようにパケットロスが大量に発生
  • 現象を感じなかったプレイのときはパケットロスはほぼなし
  • 自分が現象を感じたとき、同じゲームを同時にプレイしていた友人側ではパケットロスなし
  • 上記現象が起こるのは平日の22時前後もしくは休日の昼間が多い
  • Logs of Lagサイトで表示される典型的なbad networkは http://logsoflag.com/#v1yiEVKr7_p のようにping値も瞬間的に増えるが自分のケースではすべてping値は120前後で安定している

今後の行動

調査の結果、まず自分の通信経路のどこでパケットロスが頻発しているのかを調べる必要があるという結論になった。

よって今後は以下のように動く。

  1. 次に上記現象を感じたプレイ中にコマンドを実行 「pathping -q 200 66.150.148.1」
  2. パケットロスが大きく発生する場所を確認
    • 国内で発生してる場合 → NTTもしくはプロバイダーに報告、改善を要求
    • 国外で発生している場合 → VPNを通して接続することで改善するか確認

参考:ラグを(それほど)感じない時のpathping結果とパケットロス

パケットロスが100%になっている箇所はおそらく直接のネットワーク接続を禁止している箇所かもしくはpingを拒否している箇所なので、もっとも怪しいのは5%のパケットロスを発生させている ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109] か。

http://logsoflag.com/#L_12aS5cgJ5

C:\Users\kbigwheel>pathping 66.150.148.1

66.150.148.1 へのルートをトレースしています。経由するホップ数は最大 30 です

  0  flagship [192.168.24.20]
  1  192.168.24.1
  2  tok7nn1m3.vectant.ne.jp [163.139.126.199]
  3  163-139-126-222.rv.vectant.ne.jp [163.139.126.222]
  4  163-139-68-53.rv.vectant.ne.jp [163.139.68.53]
  5  ae0.core1.otemachi.vectant.ne.jp [163.139.128.54]
  6  ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109]
  7  ae-11.r25.tokyjp05.jp.bb.gin.ntt.net [61.213.162.173]
  8  ae-1.r20.tokyjp05.jp.bb.gin.ntt.net [129.250.6.210]
  9  ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.12]
 10  ae-1.r05.sttlwa01.us.bb.gin.ntt.net [129.250.5.47]
 11  be3048.ccr21.sea02.atlas.cogentco.com [154.54.11.9]
 12  be2083.ccr21.sea01.atlas.cogentco.com [154.54.0.249]
 13  be2075.ccr21.sfo01.atlas.cogentco.com [154.54.0.233]
 14  be2164.ccr21.sjc01.atlas.cogentco.com [154.54.28.34]
 15  be2160.ccr21.lax01.atlas.cogentco.com [154.54.27.161]
 16  be2019.ccr21.lax04.atlas.cogentco.com [154.54.88.10]
 17  38.88.197.162
 18  border1.po1-40g-bbnet1.lax010.pnap.net [216.52.255.13]
 19  66.150.148.1

統計を 475 秒間計算しています...
            ソースからここまで   このノード/リンク
ホップ  RTT    損失/送信 = Pct  損失/送信 = Pct  アドレス
  0                                           flagship [192.168.24.20]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.24.1
                                0/ 100 =  0%   |
  2    4ms     0/ 100 =  0%     0/ 100 =  0%  tok7nn1m3.vectant.ne.jp [163.139.126.199]
                                1/ 100 =  1%   |
  3    6ms     2/ 100 =  2%     1/ 100 =  1%  163-139-126-222.rv.vectant.ne.jp [163.139.126.222]
                                0/ 100 =  0%   |
  4    7ms     2/ 100 =  2%     1/ 100 =  1%  163-139-68-53.rv.vectant.ne.jp [163.139.68.53]
                                0/ 100 =  0%   |
  5    8ms     2/ 100 =  2%     1/ 100 =  1%  ae0.core1.otemachi.vectant.ne.jp [163.139.128.54]
                                0/ 100 =  0%   |
  6    8ms     6/ 100 =  6%     5/ 100 =  5%  ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109]
                                0/ 100 =  0%   |
  7    9ms     4/ 100 =  4%     3/ 100 =  3%  ae-11.r25.tokyjp05.jp.bb.gin.ntt.net [61.213.162.173]
                                0/ 100 =  0%   |
  8    8ms     4/ 100 =  4%     3/ 100 =  3%  ae-1.r20.tokyjp05.jp.bb.gin.ntt.net [129.250.6.210]
                                0/ 100 =  0%   |
  9  101ms     3/ 100 =  3%     2/ 100 =  2%  ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.12]
                                0/ 100 =  0%   |
 10  111ms     1/ 100 =  1%     0/ 100 =  0%  ae-1.r05.sttlwa01.us.bb.gin.ntt.net [129.250.5.47]
                                3/ 100 =  3%   |
 11  128ms     5/ 100 =  5%     1/ 100 =  1%  be3048.ccr21.sea02.atlas.cogentco.com [154.54.11.9]
                                0/ 100 =  0%   |
 12  ---     100/ 100 =100%    96/ 100 = 96%  be2083.ccr21.sea01.atlas.cogentco.com [154.54.0.249]
                                0/ 100 =  0%   |
 13  ---     100/ 100 =100%    96/ 100 = 96%  be2075.ccr21.sfo01.atlas.cogentco.com [154.54.0.233]
                                0/ 100 =  0%   |
 14  123ms     6/ 100 =  6%     2/ 100 =  2%  be2164.ccr21.sjc01.atlas.cogentco.com [154.54.28.34]
                                0/ 100 =  0%   |
 15  126ms     4/ 100 =  4%     0/ 100 =  0%  be2160.ccr21.lax01.atlas.cogentco.com [154.54.27.161]
                                0/ 100 =  0%   |
 16  119ms     5/ 100 =  5%     1/ 100 =  1%  be2019.ccr21.lax04.atlas.cogentco.com [154.54.88.10]
                                0/ 100 =  0%   |
 17  119ms     4/ 100 =  4%     0/ 100 =  0%  38.88.197.162
                                0/ 100 =  0%   |
 18  114ms     5/ 100 =  5%     1/ 100 =  1%  border1.po1-40g-bbnet1.lax010.pnap.net [216.52.255.13]
                                0/ 100 =  0%   |
 19  114ms     4/ 100 =  4%     0/ 100 =  0%  66.150.148.1

トレースを完了しました。

2014-04-21

第4回elasticsearch勉強会

第4回elasticsearch勉強会 - elasticsearch勉強会 | Doorkeeperのログ

発表スライドは第4回Elasticsearch勉強会を開催しました。#elasticsearchjp - @johtaniの日記 2ndにまとまってる。超助かる。

株式会社シーマーク 大谷 純 @johtani タイトル:「アナライズ処理の仕組みとクエリDSL

  • elasticsearchのcharFilter, tokenizer, tokenFilterの適応順番
  • そもそもanalyzeされるクエリとそうじゃないクエリがある。どれが適応されるクエリ
  • apache solrのanalyze画面のように、analyzeの仮定を表示するプラグインの紹介

株式会社マーズフラッグ R&D部 やまかつ さん @yamakatu タイトル:「elasticsearch-hadoopを使ってごにょごにょしてみる」

  • 本質的にはhadoopストレージとしてelasitcsearch上のデータを扱えるようになる
    • hadoop上のデータを検索できるようになる、ではない。注意
    • hadoop上のデータをelasticsearchにwriteするだけっていうのもできる

株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak タイトル: 「CouchbaseとElasticsearchが手を結んだら」

  • couchbase - couchdbではない
    • メモリ+ストレージハイブリッド・キーバリューストア
    • スケールアウトなども考慮されてる
    • ただし、現状データ横断的な処理は苦手
  • couchbaseのcross data center rsync...? の機能を使って、elasticsearchをcouchbaseに見せかけるプラグインを使用して、elasticsearchをさもcouchbaseの1クラスタのように見せる
    • ただ、RDB, couchbase, elasticsearchの3構成でcouchbaseはDB
  • ちなみに、以下のように統一していく流れ
    • 外部からElasticSearchへ流し込むプラグイン → River Plugin
    • Elasticsearchから外部へ転送するプラグイン → Transport Plugin

Wantedly, Inc 内田誠悟さん @spesnova タイトル:未定

  • 詳細忘れた。この会社の知名度がすごく高くて驚いた

LTその1 スクリプト使ってみた

LTその2 basistechさんのプラグイン宣伝

2014-01-12

git-trash-branchを作ってみました

gitでブランチを操作しながら開発してるとき、よくブランチを完全削除ではなく一旦ゴミ箱的な場所に移したいと思うケースがありました。

gitのブランチ削除は復元する方法がないため、もし削除してしまったブランチをもとに戻す場合は泣きながらreflogでハッシュ番号を漁る必要があります。しかし、それを恐れて無駄なブランチを削除しないと使わないブランチがどんどん増えて、どれが今開発してる(生きている)ブランチなのかわからなくなってきます。

現状ではそういった「たぶんいらないブランチ」はgit branch -mオプションを利用してtrash/というプレフィックスをつけていました。これにより今使ってるブランチといらないブランチをはっきりと区別することができます。ただ、branchAをtrashへ移動させたい場合、

$ git branch -m branchA trash/branchA

とbranchAという文字列を2度打つ必要があり面倒でした。加えて、全体的にコマンドが長いです。

そこで、gitのサブコマンドを自作して以下のように打てるようにしました。

$ git trash-branch branchA

ソースコードインストール方法、使い方はbigwheel/git-trash-branchを参照してください。

今回はシェルスクリプトのコードに対してrspec単体テストを書くという自分では初めての挑戦をしています。これ、やってみるとかなり良かったです。ruby自体がかなりコマンド実行と親和性が高いため、両方書ける人ならかなり直感的に書くことができます。

あとやり残したこととしてはインストールをchefで書いて、chef-applyからコマンド一発でできるようにすることぐらい。