Hatena::ブログ(Diary)

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

2017-04-27

自炊のコツ

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

2015-02-26

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

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

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

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

続きを読む