Hatena::ブログ(Diary)

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

2018-05-17 30歳エンジニアのおっさんが転職した

気持ちと考えを整理するため、列挙してく。

まだ混乱中なので順番も中身もまったく整理できていないが多分あとにも書き直さないと思う。ものぐさなので。

エンジニア転職・異動希望者に対して伝えたいこと
  • 転職活動中仲間に対する裏切り行為に感じられるのは普通。でも転職したいと思っているとしたら多分やったほうがよい
  • 転職活動は数を打て。自分との相性が120%で自分も相手の会社も利益しかない職場でも面談者と相性が悪ければさっくり落とされることもある。落ち込むがめげるな
  • 少なくとも2018年現在は売り手市場らしい。頑張るエンジニアなら確実にキャリアアップできる。自信を持っていけ

上が伝えたいことです。以下はくだらない自分語りなので興味ある人だけ読めばいいと思います。

概要

転職した。正確には6/30まで今の会社で、7/1から次の会社に行く。

今日直上の上司に希望を伝えた。

うちの会社の場合は通常上司と1対1で面談して意思を確認して徐々に進めるのが普通だが、

上司が本日会議付けで捕まりそうになかったのと引き継ぎ時間をなるべく長く取るために早く伝えたかったこと、あと自分の進退を秘密にする意義も見いだせなかったのでオフィスでみんないる中で退職したいと普通に伝えた。

常識考えろよという振る舞いだったが結果的にそこから引き継ぎなどの話をしやすくなったのでよかったのかな?と思った。

齢30にして初めての転職。親の金で博士課程前期まで行かせてもらいそこから今の会社へ新卒で入社して丸6年勤めた末にである。

精神状態について

最悪である。特に同僚と直上の上司が素晴らしく、この人達とはずっと仕事をしてもいいと思える職場だった。

以前からちょくちょく退職を匂わせては居たものの、彼らに何一つ咎ない上で退職していく自分は明らかに彼らの信頼や期待を裏切っている。

ふと自分が犯罪者同然に感じるときがある。

しかし、その上でも転職すべきだとは感じて転職した。

自分の人生に責任を持てるのは自分ひとりで、自分あるいは家族のために転職するべきだと感じたらするべきである、と今でも信じてる。

落ち込むが、転職をやめようとはついぞ思わなかった。

転職中も精神状態はかなり異常だった。

一睡もできずに面接に行って挙動不審になったり4月の陽気に滝のような汗を流したり。

転職ではなく一旦退職して無職になることも検討したが、ニート適正◎の自分では一度会社をやめたあと、また就職できる自身がなかった。

また職歴に間が空くことにより採用で不利になるんじゃないかという恐れもあった(結局の所そうだったのかはわからない。案外そうでもないのかもしれない)。

あと一度ニートになると社会保険失業保険など数々の公的手続きが必要になるのが億劫だったのもある。

軽い気持ちでいった面接でも落とされると恐ろしく落ち込んだ。

特に面接での感触が悪くなかった場合はなおさらである。

これは転職活動開始時の躁状態のどこにでも入れるような、勘違いした無限大の自信を折られた反動だったのだと思う。

そういえば新卒での就職活動時に冷やかしで行った任天堂に落とされたときもそれはそれでショックだったなと思い出した。

冷静に思い出すとゲームへ情熱を持てないまま任天堂に入ったからと行っていい仕事をできたかは怪しいので面接の人の見る目があったということなのだと思う。

転職理由

転職理由のネガティブな面を社会性フィルタを通すと何も書けなくなるのでポジティブな面を書くと、

コーディング裁量とユーザーへ価値を届けることの3点である。

コーディングについてはあと5年はまだ書いていたいと感じていて、ここ2年SRE的な仕事をしていてこれはこれは非常に楽しかったのだけどプログラミングの問題解決やパズル的要素などが恋しくなってきた。

いずれコードを書かなくなるにしてもまだ今はその時ではないと感じていて、次の職場ではコードをバリバリ書こうとしている。

裁量については今の会社は大きな会社なので意思決定や働き方の成約がきつく、フロントからインフラまで一通りできるようになった今では窮屈に思えるようになったことが一因。

組織が大きいがゆえに大規模にサーバなどを動かせたり役割が縦割りされているがゆえに雑務を他の部署や人に担保してもらっている側面もあるので一概に悪い面ばかりでもないのだが、

ものを解決するときに多数の選択肢を考えられるようになった今は裁量の狭さが故に最良と思える選択肢が取れないことがストレスになっていた。

そして組織とはそういったものと割り切ることも現時点ではまだ難しい。

組織に属する以上、多かれ少なかれ組織のルールに縛られることは当然ではあるが、より小規模なベンチャー企業であれば取れる選択肢が広がるのではないかと思ったのが一つ。

最後はユーザーへ価値を届けることで、先述の通り今の仕事はSRE寄りであるため行っているサービスがユーザーへどのように価値を届けているか、幸福にしているかって言う点が見えづらくなってしまっていた。

そこがベンチャー企業へ行くことでユーザーとの距離がつまり、より実感しやすくなるのではないかと思っている。

転職は博打の要素はある。ベンチャーであるがゆえに3年後ない会社もたくさんあるだろうし、入ってみると聞いていた話と違うということもたくさんあるだろう。

入って数ヶ月後には辞めたくなっている可能性もあるが、まあその場合はまた転職したらいいや程度には考えている。


いざとなったら自営業でもいいやと思えるようになった

部署異動を繰り返して気がついたらフロントからバック、インフラ(AWSだけど)まで何でもできるようになっていた。

今の会社に入社した頃は不安で仕方がなく、今の会社を辞めさせられたら生きていける自信がまったくなかった。

それが今ではIT企業ならどこででも役に立つ人間ですよって自信を持って言えるようになっていた。

文句もたくさんあるがこれは明らかに会社に育ててもらった結果なので素直に感謝を述べたい。

自分一人で人様に出せるサービスを公開できるようになって、いざとなったら一人企業でできることに気がついた。

コネもコミュ力もないのでフリーランスで仕事をつなぐことは難しそうだが、実力的にはやれると確信している。


高専から就職して社会にでることが恐怖でまったくやっていけると思えず、社会から逃げるためだけに大学へ編入した。

ただ、逃走のためだけに入った大学で世の中の広さを知った。自分が今まで付き合ったことのないいい加減な人間、パチンコとダーツにおぼれて留年する人間、

普通に卒論提出できず卒業できない人間、テニサー インカレテンプレみたいなリア充人間。

よーいどんの成績レースで上位にならないと生きることすら難しい、少しでもコースからはみ出すともはや生きていくことすら難しいと感じていた僕にとって、

そういった人間でも許容して回していける大学という組織は目からウロコだった。

そんな中で麻雀をしてボードゲームをしてMOにハマり研究室へはいい加減で適当な研究を提出して親の金15万で買った自転車にはロクに乗らず、

そうやって割と世の中自由な生き方許容するだけの器があるんだなと知った。世界は僕が思っているよりはみ出し者にも優しかった。

今、また世界の広さを実感している。

新卒入社時は本当に幸運にも拾ってもらえた、ここで頑張らなければ、コースをずっとまっすぐ誰よりも早く走ろうとしなければ生きていけないだろうと感じていた。

能力が上がるにつれ、自分が思っていたより更に世界が広いことに気づいた。

大企業の安定した職を捨ててベンチャーで一旗揚げようとしている人がいる。

同じ大企業でも組織が全く違うやり方のところもある。

自分一人でウェブサービス作れるようになったら無敵である。

スマフォアプリも無くなりそうにないがウェブサービスはもっとなくならないだろう。

2017-04-27

自炊のコツ

  • 全体
    • 裁断、スキャン、目視の確認。それぞれだけをやったほうが全体の作業効率はよくなるが、裁断が切り詰めすぎていたりスキャン設定がまずいことを似早めに気づくため、5冊ぐらいは順番にやったほうが良い。
    • 裁断とスキャンののそれぞれの最大枚数から、裁断は200ページごとに、スキャンは100ページごとに行うと作業がしやすい
  • 裁断について
    • なるべく端で裁断すると画像が多く残るが、ノリ・接着剤が残りスキャン時に詰まったり紙が引っかかり敗れる原因になる。時間が4倍かかるようになるのでノリが残らない程度に切るのがよい。
  • スキャンについて
    • 百ページごとにスキャンすると、あとで飛ばしていないかの確認が楽になる
    • ノイズスキャン部のガラスに残ったノリ。固まっていて手触りでわかるものもあるがノイズとして触ってもわからないものもある。アルコール液とティッシュでかなり強めに拭き取ること。
    • スキャン設定について
      • エクセレントは画集などの一部だけにする(遅い)。基本はスーパーファインでOK
      • ホワイトぺージ飛ばしは無効(削除はあとからできる)
      • カラー白黒判定は無条件でカラー固定(白黒の画質が微妙&白黒にはあとからできる)
      • 小説などの小さいものは横に倒してスキャンすると紙が滑り落ちず良い。
        • 2018/06頃にやったときは横に倒すと文字が傾いてスキャンしてしまいがちだった。よくないかも
      • 右90度回転の右・左綴じが小説に最適
      • 継続読み取りは有効がおすすめ
      • 読み取った紙の端にノリがつく気がするので、大きな本から順に単行本までスキャンすると良さげ

2017-01-08 [翻訳]スクレイピングについてのライオットのスタンス(原題: Riots s

URL: [Riot's stance on Scraping \- Riot Games API](https://developer.riotgames.com/discussion/announcements/show/oklxAP21)

Riot's stance on Scraping

スクレイピングについてのライオットのスタンス

submitted about 2 years ago in Announcements by Riot Sargonas

ライオットサーゴナスによる2年前に投稿されたアナウンス

I wanted to share some updates regarding the Riot API and other LoL data.

私はRiot APIと他のLoLデータについてのいくつかの更新について共有したい。

When we released the Riot API, we had many goals in mind. The biggest, naturally, was to help empower folks like you to build amazing content for the League community.

私達がRiot APIをリリースしたとき、私達は心の中に多くのゴールがあった。その中で最も大きく、自然なゴールはリーグコミュニティのために素晴らしいコンテンツを構築するあなたのような人々を支援することだった。

We also wanted to help provide a unified resource for accessing data, rather than relying on janky workarounds and undocumented resources.

私達はまたゴミのような代替案とドキュメント化されていないリソースの代わりに、データアクセスのための統一されたリソースを提供したかった。

We've been hard at work trying to level up what the API offers over the last few months, and we feel like it is starting to reach a state that truly empowers our community to build off of.

私達はここ数ヶ月の間に求められているAPIについてレベルアップを試みよく働いた、そして私達は(build off ofするための)私達のコミュニティを真に支援する状態にたどり着き始めたと感じている。


We've now reached the point where we need to focus on another one of our key goals with the API: to help relieve stress on our live services.

このAPIの私達の鍵となる他のあるゴールへフォーカスする必要がある点まで私達は今たどり着いた: そのゴールとは私達のライブサービスのストレスを和らげる手伝いだ。

Prior to the existence of the Riot API, many parties relied on scraping our live service platforms to obtain information.

このRiot APIの存在より前、多くのパーティが情報を取得するために私達のライブサービスプラットフォームへ依存していた。

We allowed this process to continue as we rolled out the API over the last few months

このAPIを公開したここ数ヶ月にわたって私達はこのプロセスの継続を許容した

(even though we did include provisions against doing this in the API Terms of Use because we understood the API was a fledgling service at the time.

(API利用規約の中でこれを行えるように条項を含めたあとでさえ、なぜなら私達はこのAPIはこの時点では出来立てのサービスだったから.

We’ve reached the point, however, where we need to move forward with phasing out 3rd party reliance on scraping.

しかしながら、私達はスクレイピングについての3rdパーティの頼りを段階的に停止させていく必要がある点に達した。

Scraping can cause occasional stability issues for us, and most importantly, it also increases the complexity and difficulty for Riot to detect and fix problems with our Live Services without first sorting through the “white noise” of these extraneous connections.

スクレイピングは不定期の安定性問題を私達に引き起こす可能性があり、そして最も重要なことは、それはRiotにとって私達のライブサービスの問題発見・解決をより複雑かつ難しくさせている、これらの例外的な接続の"ホワイトノイズ"を最初にソートし終えることなく。

We need to be able to focus on giving players the most reliable platform as possible, and removing this variable from the equation will go a long way towards that.

私達はプレイヤーたちに最も信頼できるプラットフォームを可能な限り提供することにフォーカスする必要がある、そしてこの方程式からこの変数を除去することはそれに叶うだろう。


Because of this, we've decided to establish a deadline of October 1st for all 3rd parties to discontinue the practice of scraping our live services.

これらの理由により、私達はすべての3rdパーティのために10/01の締め切りを設けることを決めた、そこで私達のライブサービスのスクレイピングの実践は継続されなくなる。

Moving forward from that date, the only authorized method of communication with the Riot systems will be through the API itself, per the API Terms of Use.

この日より先は、Riotシステムとのコミュニケーションの認証された方法はこのAPIそれ自身を通してのみとなり、このAPI使用規約。


We understand that this may have a direct impact on how some sites currently function, however as always our first focus is on providing the best experience for the players, and the reliability of our platform plays directly into this.

私達は理解している、これは直接影響があるかもしれない、いくつかのサイトの今の機能に、しかしながら私達の最初のフォーカスは常に最高の経験をプレイヤーに与えることであり、そして私達のプラットフォームの安定性はこれへ直接影響する。

However, while it might change some of the user experience, we feel the majority of these issues can easily be overcome by creative solutions using existing data in the API.

しかしながら、それはユーザー経験のいくらかを変更するかもしれないのに対して、私達はこれらの問題の大部分は簡単に克服できると感じている、このAPIの存在するデータを使用する創造性に飛んだ解決策により。

We’re also committed to working to bring some of the data unique to RTMP calls to the API at a later date.

私達はまたいくらかのデータをもたらすための仕事にも協力している、後ほどこのAPIを呼ぶRTMPコール。

However, we cannot commit to a time frame at this time due to a vast quantity of work needed to establish this functionality.

しかしながら、私達はこのときはまだこの時間帯をコミットすることはできない、なぜなら膨大な量の仕事がこの機能を確立するために必要であるから。

Therefore, it is unlikely that it would be completed before the 1st.

これにより、それは1stより前に完了しないかもしれない。


We know this is a lot to digest, so if you have any questions, we’re here!

私達はこれが多くのことの要約であることを知っている、もし質問があるなら私達はここだ!


(edit - we should probably be clear that all of this applies to "Riot Regions", that is, Regions where Riot runs the systems and not our partners like Garena.

(追記 - 私達はおそらく明確にするべきである、この適用の"Riot領域"のすべてについて、それはつまり、Riotがこのシステムを実行する領域とGarenaのようなRiotではない私達のパートナーについて。

In those regions how they wish to craft policy around this is up to them, as they handle the live systems.)

これらの領域ではかれらはこれは彼らに委ねられておりポリシーの工作をしたいと思っている、かれらはライブシステムの制御をしているように。


(edit 2 - As to the spectating question, this does not apply to the spectating and generation of replay files by op.gg and other sites.

(追記 2 - この観戦についての質問にように、これは観戦とリプレイファイル(op.ggと他のサイトによる)には適用されない。

They are welcome to keep this functionality for the time being and we hope one day to maybe even add spectator based replay generation to the API to make it easier for all, possibly.)

かれらはこの機能の維持をさしあたっては歓迎しており、私達はいつの日にか観戦ベースのリプレイジェネレーションのためのAPIがすべてを簡単にすると願っている、たぶんね.)

2016-12-29

統計情報からサポートチャンピオンのクラスタリングと有利不利のグラフを作成してみた

結論

f:id:den8:20161229063958p:image

統計をコネコネして最終的に今回得られた結果がこれ。

ただし情報元のサンプル数が少ないため、より正しい図を書くためにはサンプルの拡大が必要(でもお金と時間がかかるので尻込みしている)。

また統計解析の結果は見るものによって大きく解釈が異なるので、単一の解には程遠いし今の段階ではなんらかのヒントを示しているだけの段階。

平たく言うと、現段階の図はあまり真に受けないでください。

発端

slackで以下のtweetが回ってきたのがきっかけ。

観点として非常に面白いと思った(あと絵が素晴らしい!)。一方で統計的な勝敗情報(winrate)によりこのグラフを書いてみるとどうなるかと思った。

そこで、ゲームの勝敗結果のデータを使って上と同じようなグラフを作ってみることにした。

前提条件

同じタイプである、と分類できるほどタイプが似通っているチャンピオンは各チャンピオンに対するwinrateも似通ってくるはずである、という前提のもとクラスタ分析を行う。

例:

LeonaとBraumが同タイプのチャンピオンならば、Poke系Supportに対してはwinrateが低くInitiate系Supportに対してはwinrateが高い、といった同じ傾向のwinrateを示すはず。

入力(情報ソース)

Champion.ggのサポートチャンピオンマッチアップ勝率

本当はRiotAPIを直接叩いて一から統計データを構築するべきだが時間もお金もないのである程度集計されているchampion.ggを使用

出力(目指すアウトプット)

サポートチャンピオンクラスタリング

似ているチャンピオンをはっきりさせ、どういった群のチャンピオンたちに対して有利/不利であるかを可視化する。

過程

1. champion.ggのページをスクレイピングマッチアップ表を作成

コードは bigwheel/scrape-championgg-support-matchup

出来上がった表をgoogle spreadsheetに貼ったのがこれ https://docs.google.com/spreadsheets/d/1RmWnlCjvBqQvZIqdaANBEDo8vcIoUabL6Gt1LAvBQ4U/edit?usp=sharing

2. クラスター分析を使って各チャンプの勝率表からチャンピオンタイプを腑分け

データは出ているのであとは数学手法で分類するだけ。こういった処理をクラスター分析というらしい。

クラスター分析にもいくつか手法があるらしいが、今回は一番シンプルそうな階層的クラスター分析を行う。

2.1 勝率テーブルから直接ユークリッド距離を算出して階層的クラスター分析

f:id:den8:20161228194749p:image

ツリーの近いところのものほど似ている(はず)という分析。

それほど悪くない分析かもしれないが、うまく言っているようにも見えない(特にLeonaとZyraが隣り合っていたりするところは明らかに直感に反する)。

もっともこれは想定内。勝率をそのままユークリッド距離の算出に利用しているため全体勝率が同じ程度のものは必然近くなってしまう(LeonaとZyraは勝率11位と12位で隣り合っている)。

全体勝率はそのときどきの他ロールのメタ(例えば他レーンでtankがはやっていないなら必然supportではtankを使うと勝ちやすくなる)やアイテムの強弱に影響されるため、

クラスター分析では全体勝率の影響を排除したい(各チャンピオンのタイプ分けという目的に対してノイズになるため)。

2.2 個別の勝率から全体勝率を差し引いたのち、直接ユークリッド距離を算出して階層的クラスター分析

f:id:den8:20161228202545p:image

こちらは結構想定通りのグラフが出てきている。

特にBraum, Nautilus, Leona, Alistarが同じ塊になっているところなどはドンピシャといっていい。

ただ、まだ少し直感に反するところがあるので(threshとsonaが隣り合っているところなど)もう少し分析手法を試行錯誤してみる。

個別勝率から全体勝率を差し引いたことで全体勝率の影響を弱めることには成功したはずだが、もうちょっと統計学的にまともな手法があったはず。

たしか偏差,標準偏差,分散とかがそれらに用いられた気がする・・・・。

2.3 勝率偏差値を出したのち、直接ユークリッド距離を算出して階層的クラスター分析

f:id:den8:20161229034718p:image

よくなったような悪くなったような。分散で割ることによりサンプル数が少なくてピーキー勝率になっていたtahm kenchがtankクラスタに吸収されたのは良くなった点だが、

Brand/Vel'kozの殺意100%クラスタの隣にsorakaがいるのは間違っている気がする。

ただ、これ以上により高い精度で分析するには現在データ元のサンプル数が少ないため(チャンピオン同士によっては100回も当たってないデータがある)、

クラスタリングの試行はこれぐらいにして、次はこれらのクラスタリングの解釈とそれぞれの相性関係を考察する。

クラスタ結果考察

f:id:den8:20161229034718p:image

上記の樹形図をだいたい5.4ぐらいの高さでぶった切って、以下のようにチャンピオンたちを分類する。

  1. バーストメイジA(バーストA)
    • Annie
    • Zyra
  2. ピール寄りユーティリティ(ピール弱)
    • Lulu
    • Taric
  3. その他(その他)
    • Lux
    • Sona
    • Thresh
    • Blitzcrank
    • Karma
    • Nami
  4. ピールガチ勢(ピール強)
    • Zilean
    • Morgana
    • Bard
    • Janna
  5. バーストメイジB(バーストB)
    • Soraka
    • Brand
    • Velkoz
  6. CCタンク(CCタンク)

これらのクラスタごとにwinrateの偏差値平均値を取った表がこちら

f:id:den8:20161229044724p:image

さらにこれから強弱関係が際立っているもののみを抽出した有向グラフがこれ。

矢印の元のクラスタは矢印の先のクラスタに対して優位に立っているという意味。

f:id:den8:20161229052800p:image

ここから図に起こしたらこんな感じ

https://drive.google.com/file/d/0Bx1bwUKdICdQT2EzQVl2VWdyUkU/view?usp=sharing

f:id:den8:20161229063958p:image

参考資料

基本的に各ページを斜め読みしかしていないので、正しい知識を付けたいのなら直接各ページへ飛んで読んだほうがよい。

(余談だけど、このような素晴らしい資料がネット上に転がっているなんてすごい時代になったもんだなあ)

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言語だからセキュリティ関係の問題で厳しいか。