メッシュルーターを買いました

Google WiFiを見て「メッシュルーター」というものの存在を知って以来、これいいな欲しいなとずっと思っていました。
我が家ではWiFiルーター1つで家じゅうをカバーしようとしているのですが、どうしても電波が弱い部屋があり、その部屋に追加でWiFiルーターを置いたりすると、今度は別の部屋でもそのルーターに勝手に繋がってしまい、弱い電波でネットを使うことがあったりして面倒です。
メッシュルーターなら一つのSSIDで運用でき、一番電波が強いルーターを自動的に選んでくれるということで、これ良いなとなりました。

今回、Linksys Velopのトライバンドモデルを購入したので、それを選んだ理由や使ってみた所感を書いておきます。

製品選び

メッシュルーターはいくつか製品がすでに出ています。一覧はこのサイトが便利です。
https://24wireless.info/mesh-wifi-compare
ここから、消去法で選択肢を絞り込んでいきます。

「Google WiFi」はブリッジモードで使えないのでNG

Google WiFiは、ブリッジモードで使おうとすると実質的にメッシュルーターとして使えなくなるため、候補から消えました。
http://www.itmedia.co.jp/pcuser/articles/1806/28/news115_6.html

「NETGEAR Orbi」はQoSがないのでNG

ルーターには、QoS機能という特定の端末の通信を優先するような機能がついているものがあります。将来的に、ゲーム機の通信を優先したいみたいなことが起きるはずなのでQoSは欲しく、NETGEAR Orbiは候補から消えました。

「TP-Link Deco」「ASUS」はトレンドマイクロが入ってるのでNG

メッシュルーター製品の中には、セキュリティソフトウェアが入っているものもあります。
入っていれば安心かなとも思う反面、そのソフトウェアがトレンドマイクロ製だったりして、昨今のトレンドマイクロの状況を考えるとなんか避けたほうが無難なのかなと思うので、風評被害を真に受けるような判断ですが、TP-LinkとASUSの製品は候補から消えました。

「AirStation Connect」は有線LANでメッシュを組めないのでNG

日本ではBuffaloがAirStation Connectという製品を出しています。この製品は子機側に有線LANポートが1つしかなく、これはデバイス側に繋ぐために利用するもののようです。あくまでもメッシュルーター同士は無線LANでの通信になるようです。
http://www.itmedia.co.jp/pcuser/articles/1808/03/news122.html
我が家はすべての部屋に有線LANポートがあり、せっかくだからそれを利用してメッシュルーターを使いたいため、それができないAirStation Connectも候補から消えました。そうでなくともBuffaloの製品はもう何年も避け続けているのですけどね。
ちなみにAirStation Connectはこの中で唯一、フレッツ光ネクストのIPv6接続（IPoE）に対応しています。IPoEを使いたい場合は候補に入るかも知れません。

選ばれたのは「Linksys Velop」でした

この条件で残ったのは、Linksys Velopだけになりました。つまり、ブリッジモードで使えて、QoSがあって、有線LANでメッシュが組めるルーターです。消去法での選び方でしたが、ネットの評判も良いみたいですし、これに決めました。
ただ、Linksys Velopにはデュアルバンドとトライバンドの2種類があります。どっちを選ぶべきか、そして何台セットで使うか、また悩むことになりました。

Linksys Velopをどういう構成で組むべきか？

Linksys Velopにはデュアルバンド製品とトライバンド製品があり、トライバンド製品のほうが値段が高い分、たくさんの機器を接続しても速度低下しにくく、またアンテナ数も多くて電波が届くエリアも広くなっています。
そしてデュアルバンド、トライバンドのいずれも1〜3台のセット売りをしており、まとめ買いすればその分、値段も安くなっています。何を買うのが適切なのか、よく考えました。

デュアルバンドかトライバンドか

我が家は2階建ての戸建てで、土地・建物ともに100平米前後ぐらいです。WiFiルーターは2階の端っこに置いてあるのですが、同じ2階の反対の端にある風呂場や、1階にある部屋で電波が入りにくくなることがあるという状況です。
そんな状況や、世のレビューなどを踏まえれば「（カバーエリアの狭い）デュアルバンド3台」か「（カバーエリアの広い）トライバンド2台」あたりが適切なのかなと思いました。
参考) 【レビュー】メッシュWi-Fiシステム「Linksys Velop」を導入！家の隅々まで届く快適な無線LANを実現

ちなみにトライバンドの3本目のバンドなのですが、ルーター同士の中継専用に用いられるのか、機器との通信でも使えるのか、よく分かりませんでした。このツイートによれば中継専用なのですが、ソースは見つけられませんでした。
https://twitter.com/99_honten_parts/status/1061089196163493888
我が家はすべての部屋に有線LANのポートを設けていて、メッシュルーターはすべて有線LANで繋ぐので、中継専用のバンドなどは必要ありません。バンドが中継専用かどうかの結論は出せませんでしたが、いずれにせよ、トライバンド製品のほうが電波が届く範囲が広いのは間違いなさそうなので、トライバンドで良いかという気持ちになってきました。

1台か2台

トライバンドに決めたので、あとは2台買うだけ、、、なのですが、Velopのサイトを見ていると、1台で185平米をカバーすると書いています。
https://www.linksys.com/jp/velop/
あくまでカタログスペックですし、壁や扉などがあるため185平米の隅々まで十分に出るわけでもないでしょうから、鵜呑みにはできません。ただ、1台でも何とかなるのでは？ とわりと迷い始めました。
ここで気づいたんですが、メッシュルーターは後から増設してエリアを広げることができるのですから、まずは1台だけ購入して、電波の弱い場所があれば2台目を増設することもできるんです。だったらまず1台だけ買おう、と決まりました。
なかなか値下がりしない製品ですが、ちょうどPayPayキャンペーンが始まり、定価の35%OFFぐらいの値段で購入することができました。

その後、使ってみてどうか？

実際に使ってみた感想ですが、前に使っていたWiFiルーター（Aterm WG1800HP2）に比べて圧倒的に電波が強く、これまで電波が安定しなかった部屋でもしっかり通信できるようになりました。 確かに1台で良かったなと。
ただ購入後の1ヵ月半ほどのうちに、お風呂場で通信できないことと、違う階の部屋で通信が異常に遅くなることが、1回ずつありました。あまり再現度が高くないので「そういう事もあるのかな。何かの電波干渉でもあったのかな」ぐらいに捉えていますが、もし今後もたびたび起きるようなら、ルーターを買い足そうと思います。っていう感じで買い足しで問題を解決できるのが嬉しいです。

ということで、せっかくメッシュルーターを買ったのに、いまのところ1台だけなので全くもってメッシュの恩恵を受けてないわけですが、「強い電波」と「困ったら買い足せるという安心感」、あと今回は話題にしてないですが「ルーターをスマホアプリからコントロールやモニタリングできる便利さ」にお金を払ったのかなと、そんな風に思っています。
またルーターを買い足すことがあったら、報告しますね。

※2019年12月2日追記

やはり1台で全部屋をカバーするのは厳しかったので、もう1台追加しました。
ただ振り返って考えると、有線LANを配線している家においては、トライバンド2台よりも、デュアルバンドを3台にした方がコストを抑えながらカバー率を上げられたんじゃないのかなと思いました。

AWS Amplify ConsoleからNetlifyに乗り換えました

前回、AWS Amplify Consoleすげー！ ってエントリーを書きました。
http://d.hatena.ne.jp/cero-t/20181203/1543851175

ただ、世の中にはそういうサービスが普通にあったんですね、ということをNetlifyを使ってみて気づきました。
https://www.netlify.com/

自分がサイトを立ち上げた後に、海外のFEXL勢が「fexl.tokyoを真似してサイト立てたよー」って言ってNetlifyのURLを送ってきたのが、Netlifyを知ったきっかけでした。
Netlifyは静的サイトを提供できるサービスで、Hugoにも対応しています。Hugoのファイルを置いたGitHubリポジトリを指定するだけで、CDNにデプロイされる流れはAmplify Consoleと同じです。もちろん独自ドメインにもSSLにも対応しています。

NetlifyとAmplify Consoleを比べてみて

そんなNetlifyとAmplify Consoleを両方使って比べた感想です。

まず、デプロイされたページの表示スピード。これはAmplify Consoleのほうが上でした。
きちんとベンチマークを取ってないんですけど（←取っとけや）、Amplify Consoleで使ってるCloudFrontはページをリロードしても「ローカルに置いてあるサイトかな？」って誤解するぐらい素早く表示されるんですが、Netlifyのほうは「一瞬だけ、表示に時間が掛かる」という感じでした（←だからベンチ取っとけや）

ただAmplify Consoleのほうが勝ってるのはそれだけかなと。
Netlifyにはフォームを置いてユーザーのデータを保存したり、AWS Lambdaを呼び出したりする機能がありますが、Amplify Consoleには今のところそういう機能が何もありません。AWSのことですからいずれ機能追加されるでしょうけど、今のところは素のビルドとデプロイしかありません。

また、コンテンツを更新した後のCDNへの反映なのですが、Amplify Consoleでは事前に決めたTTLが経過するまで反映されません。デフォルトではTTLが5秒とかになっていて短すぎるのですが、だからと言って24時間にすると、運が悪ければコンテンツを更新してから24時間近くCDNには反映されなくなっちゃいます。一方で、Amplify Consoleはコンテンツを更新すれば即CDNに反映されます。
AWSのCloud Frontにはコンテンツをinvalidateして、すぐにコンテンツを更新する仕組みがあるはずなのですが、Amplify Consoleではその機能が使えないんですよね。いずれアップデートされて使えるようになるのでしょうけど。
あと、Netlifyは小規模サイトであれば無料で運用できるので、コミュニティ活動で使う場合にはちょっと嬉しい感じです。

ちなみに地味に嬉しいのが、Netlifyはプルリクを受けつけると（プルリクをマージしてなくても）それも別のURLでデプロイしてくれるところです。URLは命名規則が決まっているので、プルリクを送ってくれた外部の協力者は、すぐにそのURLにアクセスして自分のプルリクした内容をプレビューすることができます。この辺も地味にかなり嬉しい機能です。

そんなわけで、fexl.tokyoのサイトはNetlifyに移動しました。
この辺りの分野は経験がまったくなかったので、ヘェェェっていう驚きばかりで新鮮ですね。

春にはこのブログも（はてダが）終了となるため移転を考えていたのですが、Netlifyで運用しようかなぁというのが最近のお気持ちです。どうしようかなぁ。

AWS Amplify Console + Hugoが想像以上に楽だった話

先日、HugoとAWS S3 + CloudFrontで作ったというエントリーを書きました。
ファイティングEXレイヤーの攻略サイトをHugoとAWS S3 + CloudFrontで作りました - 谷本 心 in せろ部屋

まさにこのサイトをデプロイをしたその日、AWSのre:Inventで「AWS Amplify Console」というものが発表されたんです。
新サービス「AWS Amplify Console」登場！簡単3ステップでWebアプリのCI/CD環境を構築！ #reinvent ｜ DevelopersIO
あれだけ難儀して構築したHugo + S3 + CloudFrontの環境に、さらにCI/CDまで付いたものができると言うんです。

今回は、このAWS Amplify Consoleを使ってみたら、思った以上にというか衝撃的に使いやすかったという話です。特にHugoやJekyllを使っているユーザーにはオススメです。

自動デプロイ環境がほしくてAmplify Consoleに手を出す

前回作ったサイトは、人力でデプロイをしています。
MarkdownファイルをGitHubで共有して、プルリクをもらったら僕がマージして、PCでビルドして、S3にデプロイして、CloudFrontのキャッシュを無効化してエッジサーバに再取得を促す、という流れでした。これだと明らかに「僕」がデプロイのSPOFかつボトルネックになっているため、これを自動化することにしました。
最初はGitHub Actionsを勉強がてら使おうかなと思ってβ版に申し込んだのですが、承認までちょっと時間が掛かるようだったので、せっかくなのでAmplify Consoleを試してみることにしました。

やりたかった事がいきなり全部できた

とりあえず自分のGutHub（https://github.com/cero-t/hugo_example）にあるMarkdownファイル群をデプロイしようと進めることにしました。まずはデプロイだけできたら、次はビルドファイルを更新してhugoコマンドを打てるようにするのが良いかな、、、なんて考えながら進めている途中、Amplify Consoleがこんな設定ファイルを出してきました。

version: 0.1
frontend:
  phases:
    build:
      commands:
        - hugo
  artifacts:
    baseDirectory: public
    files:
      - '**/*'
  cache:
    paths: []

えっ、なんか勝手にhugoのサイトだということが認識されてる？？
このファイルを使ってそのままデプロイしてみたところ、、、ちゃんとしたHTMLになってamplifyapp.comのサーバにデプロイされました！

そうなんです、Amplify Consoleはリポジトリで管理されているファイル群を自動識別して、最適なビルドを提供するようなんです。つまりデフォルト設定のまま進めるだけで、GitHubリポジトリからソースを取ってきて、hugoコマンドでビルドして、CloudFrontのエッジサーバにデプロイされる、という、一連の流れが全部できるようになりました。

ちなみに前回作ったfexl.tokyoのサイトは、リポジトリ内のルートではなく、一段下がった /site ディレクトリでHugo向けのコードを管理しているため、ビルドスクリプトを少しだけ変える必要がありました。

version: 0.1
frontend:
  phases:
    build:
      commands:
        - cd site
        - hugo
  artifacts:
    baseDirectory: site/public
    files:
      - '**/*'
  cache:
    paths: []

たったこれだけですから、ホントに簡単です。

なぜか遅い、って思ったら、プロダクトマネージャーの方が教えてくれて解決

デプロイまではすぐにできたのですが、デプロイしたサーバにアクセスしてみると、なぜかとても重いのです。Amplify ConsoleはCloudFrontを使っているはずなのですが、自分でCloudFrontにデプロイしたサイトに比べて10倍ぐらい応答に時間が掛かります。
nslookupしてみると日本のエッジサーバっぽいものが返ってくるし、Pingを打っても10msぐらいで返ってくるし、遅い理由がちょっと分かりませんでしたが、その旨をツイッターでつぶやいてみたところ、Amplify Consoleのプロダクトマネージャーからリプが来ました（！！）
https://twitter.com/TheSwaminator/status/1069550788106575873

どうやらエッジサーバのTTLがデフォルト5秒に設定されていて、アクセスするたびにエッジサーバがオリジンサーバにデータを取りに行くような状況になっているようです。そりゃ遅いですよね、オリジンサーバがどこにあるかは分かりませんけども。
ということで、このTTLを600（10分）に延ばしてみたところ、エッジサーバのキャッシュが効くようになり、アクセスが高速になりました。

あとちなみに、GitHubにファイルをプッシュするだけでビルドが始まるのも楽で良いです。

最後に、Route 53を設定して独自ドメインでアクセスできるようにする

Amplify Consoleが期待通り、いや期待以上のものだと分かったので、S3とCloudFrontによる運用をやめて乗り換えることにしました。そのため、fexl.tokyoというドメインをCloudFrontからAmplify Consoleに紐づけ直すのですが、ここでちょっと手間取りました。
既に運用しているドメインをAmplify Consoleに紐づけるためには、いくつか事前にやっておくことがあるようです。

• Route 53でAやCNAMEで追加していたものを削除する
• CloudFrontからドメインの紐づけを外す
  • （CloudFrontを事前に削除しておいたほうが良い？）

これを済ませておかなければ、ドメインとの紐づけがうまく行かないようです。その辺りで一時的にサイトにアクセスできなくなったり、SSL証明書の再発行が遅れて信頼できないサイト扱いになってしまったり、少しトラブってしまいました。正直、どうすればノンストップで移行ができたのか、正解が分からない感じですね。

何はともあれHugoユーザーがデプロイする環境を作るのは楽

という事で、拍子抜けするぐらい簡単にHugoで構築する静的ホスティングサイトの自動デプロイ環境が整いました。自分でビルドスクリプトを書かず、自動認識される辺りはホントにちょっと驚きました。もう少し凝った事が必要になるなら、個別にS3とCloudFrontを立てて設定する必要があるのでしょうけど、僕にはちょうど良い感じでした。
なんか細かいところでバグっぽいものがあったり、CloudFrontの実体が見えなくてアクセス数やキャッシュヒット率も分からないとか、デプロイ周りの挙動がよく分からないことがあるみたいな部分もありますが、ここまで簡単にできるということ自体が最高でした。しばらく使い続けてみたいと思います。

ファイティングEXレイヤーの攻略サイトをHugoとAWS S3 + CloudFrontで作りました

作ったんですけど、Googleとかで検索してもヒットしないので、自分のブログからリンクしてランクを上げたかっただけなんです。

でも本当にそれだけだと申し訳ないので、技術的な話も書いておきますね。

WikiもCMSも使わずにサイトを立てたい

最近のゲームの攻略サイトっていうと、だいたいWikiです。Wikiを立ててみんなでそれを更新する感じになります。ただ、僕がゲームをやってた時代には、まだWiki文化はなく、各自で攻略サイトを作って、掲示板とチャットで議論する感じでした。キリ番を踏んだ人はカキコお願いしますの時代です。
そんなわけで今回の攻略サイトも、Wikiではなく、かと言ってブログでもなく、いわゆるドキュメントサイトの形式で提供しようと思いました。ITエンジニアっぽくSpeaker DeckとかGoogle Sidesに攻略のプレゼンを上げても良いんですけど、網羅的な情報は、やっぱりドキュメントの形式ですよね。
あと、たかだか攻略サイトのためにEC2のインスタンスを立ててWebサーバやCMSを立てるのもお金がもったいないので、S3にHTMLを置いてアクセスさせれば十分かなと思いました。ただHTMLを置くとは言え、HTMLのタグ打ちは面倒だからMarkdownで書きたいです。

そんなことを考えながらググってたら、「静的サイトジェネレーター」という分野に行き当たりました。

静的サイトジェネレーターの中からHugoを選んだ理由

静的サイトジェネレーターとは、Markdown形式のテキストに、テンプレートやら何やらを適用して、HTMLやCSS、JavaScriptなんかを生成するツールです。企業や製品のサイト構築、ブログ、ドキュメントなどを作るために使えます。有名どころは、jekyll、hugo、hexo、gatsbyあたりで、中でもjekyllはGitHub Pagesが使ってるとか。
難点は動的コンテンツを入れられないことで、たとえばコメントをもらったりしづらいわけですが、それも、外部サービスと連携してコメントを受け付けられるようにできたりもします。時代は進んでる。俺たちは進んでいるのか？（問いかけ）

そんな静的サイトジェネレーターの中で、今回選んだのはHugoでした。選んだ理由は名前がスト3に出てくるキャラと同じだし、セットアップが一番簡単だったからです。Hugoはgoで実装されていて、セットアップなしでシングルバイナリを実行するだけで使えます。pythonとかnpmとかのセットアップをしなくて良いのは僕も楽ですし、今回はエンジニアでないゲーマーにも記事を書いてもらいたかったので、なおさらセットアップが簡単なことは重要でした。そういう用途のツールはGoで作られてると良いですね。

ほとんどの静的サイトジェネレーターはテーマ（日本だとテンプレートって呼んだほうが伝わりやすい？）がたくさん用意されていて、Hugoも例に漏れずたくさんあります（https://themes.gohugo.io/）
この中で一番ドキュメントっぽい雰囲気のdocdock（https://themes.gohugo.io/docdock/）を選びました。

Hugoの使い方を簡単に説明すると、markdownをワーッと書いておいて、プレビューするときは、

hugo server

これでPC上にサーバが立ち上がり、ブラウザからアクセスできるようになります。ちなみにdocdockは左側にメニューができるタイプのテーマで、そのメニューも自動で生成されます。えらい。

そして、公開するためにHTMLを生成するときは、

hugo

するだけで、publicというフォルダが作られてHTMLやら関連するリソースやらが置かれます。フォントファイルなどもできるので、Hello World程度でも8MBぐらいになります。スーパーマリオ200本分のサイズです。

AWS S3に置いて静的Webサイトホスティング

そうやってHugoで作った静的Webサイトを、クラウドに置きましょう。はい、↑の見出しにAWS S3って書いてるにも関わらず、Azureのサービスを登録しましたー。
https://twitter.com/cero_t/status/1062481542876868608

まずHugoで生成したファイル群をAzure Storageに置いて、Storageの静的Webサイトホスティングの機能を使うだけで、世の中に公開できました。やり方は、ググってください。
次に、独自ドメインを取ります。fexl.tokyoというドメインにしたかったので、お名前ドットコムで取得しました。やり方は、ググってください。
さらに、Azure DNSでfexl.tokyoを使うよう設定して、お名前ドットコム側ではAzureのDNSを使うよう設定します。やり方は、ググってください。

そしてここで気づいたんですが、「www.fexl.tokyo」のようなドメインであれば問題なくホスティングできるのですが「fexl.tokyo」といういわゆるZone ApexなドメインはAzure DNS + Azure Storageの静的Webサイトホスティング機能では使えないんです。AネームのエイリアスにAzure Storageを指定できないとかそういう類の理由で、そういえばAWSのRoute 53 + S3のホスティングも昔はそうだったよなと思い出しました。なのでAzureもいずれバージョンアップで対応すると思います。
ということでここでAzureに別れを告げ、AWSにホスティングすることにします。Route 53 + S3による静的Webサイトホスティングであれば、Zone Apexを使えるからです。

ということで、Hugoで生成したファイル群をS3に置いて、S3の静的Webサイトホスティング機能を有効にして、Route 53でfexl.tokyoを使うようにして、お名前ドットコムからRoute 53を見に行くようにして、そのやり方はもちろんググってください。

そんなわけで、fexl.tokyoのサイトをAWS上で運用できるようになりました。

HTTPが許されるのは平成までだよねー

ここまでの方法では、まだHTTPのアクセスになります。やっぱりこれからの時代はHTTPSが標準ですよね。攻略サイト程度でHTTPSが要るかどうかというと甚だ疑問ですが、HTTPSであらずんばWebにあらずぐらいの勢いでGoogleさんが煽ってくるので、HTTPS対応することにします。

SSL証明書は、AWS上で（たぶん無料で）取れます。ググるとすぐ分かります。
これをS3に適用・・・あれ、できない。そうなんです、S3による静的WebホスティングはHTTPS化できないんです。とは言えEC2を立ててWebサーバを立てるのもシャクなので、他の方法を探してみたところ、CloudFrontであればSSL化できることが分かりました。ググるとすぐ分かります。

CloudFrontは、何の設定をするにも15分ずつ掛かるあたりがちょっとストレスフルなのと、サイトをすぐに更新したい時には invalidation しなくてはいけなかったり、サブディレクトリの index.html を /sub/index.html ではなく /sub/ でアクセスできるようにしたいならOriginをS3のバケットにするんじゃなくて「(bucket名).s3-website-ap-northeast-1.amazonaws.com」みたいなpublicアクセスするほうのURLをOriginにしなくてはいけないあたりでハマりましたが、それらが分かるとなかなか可愛げのあるサービスです。
すみません、この辺は自分のためのメモなので、何を説明してるか分からなくても大丈夫です。そもそも半年後の自分ですら理解できるか危ういです。

ということで、fexl.tokyoのサイトをSSL化してAWSで運用し始めました。CloudFrontを使ってるので海外からのアクセスも早いと思います。コンテンツはぜんぶ日本語ですけどね、ガハハハハ。

Googleさんが振り向いてくれない

これでサイトの運用を始めたんですけどね、期待しているほどのアクセスがありません。なぜかって・・・ググっても見つからないから！
僕がこのサイトを立ち上げるために、どれだけGoogleさんにアクセスしたかはこのエントリーをここまで読んだ皆様ご承知のことと思いますが、それでもGoolgeさんは僕のことを見つけてくれないのです・・・（支離滅裂な発言）
Googleにインデックスされない件について調べてみると、Google Search Console（https://search.google.com/search-console/about）を使うと良いみたいな情報を見つけまして、確かにそれに登録してから36時間ほどで確かにインデックスされた感じになりました。でも全然、検索ではヒットしませんね。

ということで、単に自分のブログからfexl.tokyoへのリンクを張りたいがためにつらつらと書いた駄文に、最後までお付き合いいただきありがとうございます。ぜひ、その勢いで攻略サイトにアクセスし、あまつさえゲームまで買ってしまい、ツイッターで #FEXL のハッシュタグとともに「せろさんの影響で購入した」とツイートしていただければ、僕の株価もアゲアゲになること間違いなしかなと思いますので、どうぞよろしくお願いいたします。

US配列のキーボードに無変換キーと変換キーを作ってIMEのOFF/ONを割り当てました

日本語環境でUS配列のキーボードを使う時に、IMEのON/OFFをどうするか問題。ずっとWindowsを使い続けてきた人は「Alt + `」で構わないでしょうし、あとは「Shift + CAPS」や「Ctrl + Space」あたりがメジャーかも知れません。
しかしMacの日本語キーボードを利用していた人は、「左AltでIME-ON、右AltでIME-OFF」というアサインにしたくなります。現在ONかOFFを気にせずにON/OFFを切り替えられるので、とても便利です。

これを実現するために、alt-ime-ahkというツールがよく使われます。これは左右のAltキー空打ちを、それぞれIMEのONとOFFにアサインするツールです。
https://github.com/karakaram/alt-ime-ahk
ただ使い始めて3日もするとキー入力に慣れてきて、文章を書いている途中で「Altを離す前にキー入力を始める」ようになり、「Alt + D」みたいなショートカットが動いてしまうことが増えてきました。テキストボックスに入力してたのに、いきなりアドレスバーで入力が始まっちゃったりするんですよ。

さすがにストレスフルなので、これは根本的にキーアサインを変えるしかないぞと思い、挑戦してみました。

TL;DR

レジストリエディタで次の設定を入れて、AX配列にする。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

値の名称	データ型	値
LayerDriver JPN	REG_SZ	kbdax2.dll
OverrideKeyboardIdentifier	REG_SZ	AX_105KEY
OverrideKeyboardSubtype	REG_DWORD	1
OverrideKeyboardType	REG_DWORD	7

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID\{キーボードのPnP ID}{うんたらかんたら}\Device Parameters

値の名称	データ型	値
OverrideKeyboardSubtype	REG_DWORD	1
OverrideKeyboardType	REG_DWORD	7

※ここにキーがある場合だけ

次に、キーアサインを変更して、左Altを無変換、右Altを変換、右アプリケーションキーを左Altにする。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

値の名称	データ型	値
Scancode Map	REG_BINARY	00,00,00,00,00,00,00,00,04,00,00,00,38,00,5d,e0,5b,00,38,e0,5a,00,38,00,00,00,00,00

そのうえで、IMEの設定で「無変換をIMEオフ」、「変換をIMEオン」にアサインする。

配列の変更

Surface BookのUSキーボードはこんなレイアウトです。

これを次のようにします。

• 左AltをIME-OFFにする
• 右AltをIME-ONにする
• 右にあるアプリケーションキーをAltにする

Altキーが右側だけになってしまうのですが、そこは妥協せざるを得ません。本当は左にあるFnの位置をAltにして、右のアプリケーションキーをFnにしたいのですが、WindowsではFnキーのアサインを変更できないのです。

まずはUS配列からAX配列にする

いろいろググってみると、こういう事をしたい場合は、US配列のままにせず、AX配列にした方が良いようです。なのでまずはAX配列になるよう挑戦したのですが、少し難儀しました。

まずはこのサイトにある通り、レジストリエディタでレジストリを4つ追加/変更します。
Windows 10 でも AXキーボード | forzandoblog

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

値の名称	データ型	値
LayerDriver JPN	REG_SZ	kbdax2.dll
OverrideKeyboardIdentifier	REG_SZ	AX_105KEY
OverrideKeyboardSubtype	REG_DWORD	1
OverrideKeyboardType	REG_DWORD	7

ただこの設定を入れて再起動したところで、左右のAltキーはAltのまま変わらず、どうしてもAX配列にはなりませんでした。他のサイトを見ても同じ情報しか見つからず、いったん諦めかけたところで、このサイトにたどり着いて、もう一か所、設定が必要なことが分かりました。
[Windows7でのキーボードレイアウトの指定 | untitled document}

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID\{キーボードのPnP ID}{うんたらかんたら}\Device Parameters

値の名称	データ型	値
OverrideKeyboardSubtype	REG_DWORD	1
OverrideKeyboardType	REG_DWORD	7

この設定を入れて再起動したところ、右Altキーが「カタカナ」相当になり、AX配列になったことを確認できました。

キーアサインを変更する

AX配列になったものの、左AltはAltのままですし、右Altキーは「カタカナ」キーになっています。これを日本語キーボードと同じく、左Altを「無変換」、右Altを「変換」にアサインし直します。キーアサインはここを参考にしました。
Uchan Note: 日本語キーボードを US 配列で使いつつ、変換/無変換キーで IME ON/OFF

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout

値の名称	データ型	値
Scancode Map	REG_BINARY	00,00,00,00,00,00,00,00,04,00,00,00,38,00,5d,e0,5b,00,38,e0,5a,00,38,00,00,00,00,00

これで再起動すると、左Altが無変換、右Altが変換、そして右アプリケーションキーが左Alt相当になります。
ここまで出来たら、あとはIMEの設定で「無変換をIMEオフ」「変換をIMEオン」にアサインし直します。設定の仕方は調べればいくらでも出てくるので割愛します。

まとめ

長らくUS配列キーボードの日本語入力オン/オフに悩まされていて、結局は日本語キーボードのほうが良いかなと思っていました。ただ、この配列がかなり良さそうなので、今後は常にUS配列キーボードを選ぶことになりそうです。
ちなみにMacのUS配列キーボードもキーの数は同じですから、キーアサインを変更すれば同じ配列にできます。これでいつMacBookに戻っても大丈夫ですね。

ThinkpadからSurface Book with Performance Baseに乗り換えました

以前、MacBookからThinkpadに乗り換えたという記事を書きました。
MacBookからThinkpad X1 Yogaに乗り換えます。 - 谷本 心 in せろ部屋
今度はそこからSurface Bookに乗り換えたという話です。

ThinkPadの良かったとこ、悪かったとこ。

ThinkPad X1 Yogaはおおむね僕の期待通りのノートPCで、キーボードは打ちやすいし、HDMIがついてるし、そして何よりペンが良い。
普通のクラムシェル型ノートPCのスタイルでは、どうしてもキーボードが邪魔になってペンを使いづらいのですが、X1 Yogaは2-in-1スタイルにできるノートPCなので、こんな置き方にできます。

このスタイルならかなりペンが使いやすくなります。この辺りも含めて、X1 Yogaのスタイルにはかなり気に入っていました。
また、サポートも良かったです。チャットで問い合わせができるので、つながらない電話にイライラすることもなく、他の作業をしながら片手間に問い合わせが進められました。そして代替品の交換にしろ、本体の修理にしろ、すごく早くて良かったです。

一方でイマイチだったのが、ポインティングデバイスです。タッチパッドは細かい操作をしづらいし、キーボードを打ってる時に誤反応もするので、OFFにしました。またThinkPadのウリでもあるトラックポイントは、悪くはないもののやっぱりストレスがありました。本体のトラックポイントと外付けのThinkPad Keyboardについてるトラックポイントでも少し感覚が違ったりしてなかなか慣れず、結局、マウスを使える時にはマウスを使っていました。残念すぎますね。
また、キーボードにも少し不満がありました。打鍵感は最高なのですが、キーボードを高速入力してると「ryu」や「tyu」で3文字目の取りこぼしが発生して、たとえば「空中」と打とうとすると「くうちゅ」となり「くう(*´ε`*)ﾁｭｯﾁｭ」と変換されてしまうという最悪のエクスペリエンスが何度もありました。これはひとえに僕の入力のせいで「tyu」の3キーをほぼ同時に押してしまっていることが原因なのですが、それでも他の機種ではこの問題は起きないので、なかなか辛かったです。

とは言えポインティングデバイスもキーボードも些細な不満でしかなく、買い替えるほどの致命的な問題ではありませんでした。

きっかけは、Steam版のゲームが出ること

僕のツイッターをフォローしている皆さんは、最近の僕が格闘ゲームに心酔していることは既にご存知だと思います。これまでプレステ4でしか遊べなかったゲームが、もうすぐWindowsでも遊べるようになるのです。そうすると、やっぱりノートPCでもプレイしたくなるじゃないですか、ね、分かるでしょ、ね、ね。

ゲームをするにはThinkPad X1 Yogaは力不足なので、dGPUを積んだノートPCが欲しくなります。しかし、ゲーミングノートPCを買うというわけにもいきません。「ペン」や「2-in-1スタイル」はどうしても捨てがたく、そんなものを搭載したゲーミングノートはありません。
ペンが使える2-in-1で、ある程度良いGPUも積んでいるものとなると、Surface BookかHP Specte x360ぐらいしかありません。
（参考: HP Spectre x360 15（2018年10月モデル）製品詳細 - ノートパソコン | 日本HP）

そうやって悩んでた折、友人がSurface Book with Performance Baseを手放そうかなと話していたので、ブランカのサプライズフォワード並みに飛びついて安く譲ってもらう事にしました。たとえが分かりづらくて申し訳ないですが、友人には感謝しかないです。

即座に惚れたSurface Book

Surface Bookは、使い始めた瞬間から最高でした。
入力デバイスが何のストレスもなく使えますし、dGPUのGTX965Mのおかげで3D格闘ゲームも問題なくプレイできています。

キーボードの取りこぼしなどはありません。何キーロールオーバーか知らないですが、「qwertyui」ぐらいまでを同時押ししても全部認識されたのでそれ以上は調べていません。
タッチパッドも細かい操作ができ、誤反応もありません。おそらくWindowsノートとしては最高のタッチパッドで、MacBookのトラックパッドにわりと肉薄していると思います。たまに意図しないドラッグが発生してしまってイライラしていたのですが、設定で「2回タップしてドラッグすると複数選択」というチェックさえ外せばそれも起きなくなり、とても快適になりました。
また、Surface Bookは典型的な2-in-1とはスタイルが異なるものの、液晶部分を取り外してタブレットとして使えるので、ペンを使うときはこのタブレット形式にできます。よくこんなPC作ったな、という感じです。

むろん不満がゼロではなくて、3000 x 2000の解像度はどうだろうかって思ったり、iPad Proみたいにペンを本体の側面にくっつけて充電できれば良いのになと思ったり、Surface Pro/Go用のタイプカバーみたいな軽量キーボードがあればもっと最高なのになと思ったり、せめて本体と同じ配列のBluetoothキーボードを発売してくれないかなと思ったり。
ただそれはプラスアルファの望みであって、マイナスなポイントがほとんどないのはとても良いですね。

あ、本体の価格が高すぎるのが最大の欠点なんですけどね。

Surface Bookはいいぞ

そんなわけで、Surface Bookはおおむね最高です。たぶんこれWindowsノートとしては最高のデキなんじゃないですかね。これを使ってしまうと他のWindowsノートには戻れないのでは、という気持ちです。
せめて他のWindowsノートも、このぐらいのキーボードとタッチパッドを積んでくれると、まだしも選択の幅が広がるのですが。

あとは、格ゲーの発売日を待つばかりです。

Java Championになりました！

※画像はチャンポンです。

ちょうど10年前の2008年、初めて「JavaOne」に参加しました。
こういう場に登壇するのは到底できないけれど、Javaに関する様々なテーマを話す勉強会を開きたいなって思いました。
http://d.hatena.ne.jp/cero-t/20080502/1209738453
http://d.hatena.ne.jp/cero-t/20080509/1210420374

その1年後、2009年の冬に「関西Javaエンジニア」の会を立ち上げました。
今回、同時にJava Championになったjyukutyoも、立ち上げメンバですね。もう一人はミニ四駆やってます。
http://d.hatena.ne.jp/cero-t/20091105/1257437947

そして2012年、JavaOne Tokyoに登壇をしました。
日本開催とは言え、あこがれていたJavaOneを冠するイベントに初めて登壇できたのです。
http://d.hatena.ne.jp/cero-t/20120410/1333994945

そんな実績も影響してか、2013年、ついにサンフランシスコのJavaOneに登壇する機会が得られました。
http://d.hatena.ne.jp/cero-t/20130627/1372274652

自分で言うのも何ですが、僕がJavaOneに登壇したことで、他の日本人が登壇する流れができたと思います。
いや。言い直します。
「せろさんに登壇できるなら、自分にもできるだろ」って思わせることができたと思います。

そうやって海外での登壇や、日本でのJavaイベントなどに積極的に参加していた中で、昨年、2017年にJOnsenでJava Championたちと触れ合いました。
そして今年のJOnsenの中で「Java Championにならないか」と持ち掛けられたのです。

・・・代表的なものだけを取り上げましたが、こうした様々な出会い、活動などが積み重なり縁となって、このたびJava Championになる機会を頂けました。
私は決して殊勝なことを口にするような性格ではなく、すべては俺様が積み重ねた成果ゆえの選出だと心の底から思っておりますが、しかしながら今回の件は、Javaのコミュニティに関わる皆様や、僕の勝手気ままな生き方を支援する家族と会社、またこの選出に大いに貢献してくださったJava Championの皆さまのおかげなのは間違いありません。

皆さま、ありがとうございました。
あぁ、Java Championには英語で言わなきゃ伝わらないですよね、Thank you.

今後は、日本の情報を海外に発信したり、海外のエンジニアが日本のコミュニティに参加するような流れを、もっと作っていきたいなと思っています。僕たちも海外のエンジニアも、抱えている課題は同じなのですから。