谷本 心 in せろ部屋

はてなダイアリーから引っ越してきました

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とかで検索してもヒットしないので、自分のブログからリンクしてランクを上げたかっただけなんです。


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

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

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


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

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

静的サイトジェネレーターとは、Markdown形式のテキストに、テンプレートやら何やらを適用して、HTMLやCSSJavaScriptなんかを生成するツールです。企業や製品のサイト構築、ブログ、ドキュメントなどを作るために使えます。有名どころは、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 Consolehttps://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キーが右側だけになってしまうのですが、そこは妥協せざるを得ません。本当は左にある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.


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

Dell XPS 15とThinkpad X1 Yogaを比較する(対戦格闘ゲーム編) #デルアンバサダー

Dell XPS 15 (9560)とThinkpad X1 Yoga (2017)の比較、第二弾。今回はSteam版のStreet Fighgter V: Arcade Editionをそれぞれで動かしてみます。
XPS 15はdGPUとしてGTX 1050を積んでおり、3Dゲームをやるのに申し分ない性能のはずです。一方でThinkpadIntel 620なので、3Dゲームは苦手なはずです。そんなわけで比較する前から勝負は明らかですが、実際にXPS 15ではどれぐらい安定するのか、Thinkpadでは本当に動かないのか、という辺りを見てみたいと思います。

Street Fighgter V: Arcade Editionを動かしてみた

こういうのは実際に動かした動画を見せるのが手っ取り早いので、動画を置いておきます。なお動画のキャプチャがゲームの動作に影響しないよう、それぞれノートPCからHDMI出力したものを外部機器(GV-HDREC)で録画しました。

Intel 620では標準画質ですらダメ

まずはデフォルト設定の標準画質から。解像度は1920 * 1080、画質は中です。
少し見づらいですが、左上に小さくFPSを表示しているので、そちらが参考になります。


XPS 15 標準画質


Thinkpad X1 Yoga 標準画質


差は明らかですね。XPS 15は何の問題もなく動作して60fpsで安定しますが、Thinkpad側はひどいスローモーションになってしまい15fpsぐらいしか出ていません。まぁこれぐらいの差は予想通りです。

Thinkpadでも低画質なら動くのか?

Thinkpadでは標準画質だとまともに動きませんでしたが、画質を下げれば動くのでしょうか。解像度と画質を下げてみます。解像度は1366 * 768、画質は低です。


Thinkpad X1 Yoga 低画質


見た感じきちんと動いていますが、完全に60fpsで安定しているわけではなく少しだけフレームレートが落ちることもあります。60fpsで安定させるためにはもう少し解像度なり画質なりを下げる必要がありそうです。たださすがにそこまでしてプレイする気にはなれない感じです。

XPS 15なら最高画質でも大丈夫か?

標準画質なら問題なく動いたXPS 15ですが、最高画質ではどうでしょうか。解像度は1920 * 1080、画質は最高です。


XPS 15 最高画質


ほぼ問題なく動いているのですが、真空波動拳を出す瞬間に57fps程度まで下がっていることが分かります。この画質で安定して動かしたければ、もう一段上のGTX 1060ぐらいが必要なんでしょうね。画質を「最高」ではなく「高」にすれば60fpsで安定したため、普通に遊ぶ分には全く申し分なさそうです。

描画の遅延はどうか?

対戦格闘ゲームなど、それなりにシビアな反応を要するゲームをプレイする場合、液晶や入力の遅延は無視できません。ディスプレイによって内部遅延(回路遅延)や描画遅延などが異なっていることは、ゲーマーの間でもよく話題に上ります。遅延については絶対的な計測はできないのですが、ディスプレイの遅延の比較であれば、本体のディスプレイとHDMI接続したディスプレイに同じものを映することで、どれぐらい差があるか比較することができます。


今回はLCD Delay Checker ( http://bygzam.seesaa.net/article/110314791.html ) というソフトウェアを利用し、ノートPCのディスプレイと、HDMI接続したゲーミングディスプレイに同じタイマーを表示して、その様子をハイスピード撮影することで、遅延の差を比較したいと思います。
HDMI接続するディスプレイは、HORIのポータブルゲーミングモニターです。独自に計測した結果ですが、一般的なゲーミングディスプレイと同等の遅延だということが分かっています。
ハイスピード撮影は、iPhone7のスローモーション撮影機能を利用しました。240fpsで撮影できるため、60fpsの描画1フレーム分を4コマに分けて撮ることができます。


なおYoutubeの動画は停止した後に . (ドット) でコマ送り , (カンマ) でコマ戻しができるため、よく比較して見るときにはその機能を使ってください。

XPS vs HORI Monitor

左がXPS 15、右がHORI Portable Gaming Monitorです


XPS側が動画中の3コマ分、つまり3/4フレームほど遅延していることが分かります。ミリ秒で言うと12.5msほどの遅延です。

Thinkpad vs HORI Monitor

左がThinkpad X1 Yoga、右がHORI Portable Gaming Monitorです


今度はThinkpadのほうが動画中の4コマ分、ちょうど1フレームほど先行していることが分かります。ミリ秒で言うと16.6msほど早いです。

結果と考察と体感

もしノートPCのディスプレイの表示と、HDMI出力側の表示が完全に同時であると仮定すると、上の結果から次のことが言えます。


(遅延:小) Thinkpad <(1.0F)< HORI Monitor <(0.75F)< XPS (遅延:大)


ただ、これは私の体感とは違っています。
ThinkpadとHORI Monitorを使ったときには、普段ミスしない連続技が「入力が遅いがために」ミスすることが多く、どうも2フレームほど表示が遅れているような体感があります。一方で、XPSとHORI Monitorを使う時にはそこまで大きな遅延を感じません。また、Thinkpad本体のディスプレイとXPS本体のディスプレイも、遅延には差がないという体感です。
この体感が正しいとすると、最初の仮定である「ノートPCのディスプレイの表示と、HDMI出力側の表示が完全に同時である」が誤っており、Thinkpadの場合は「HDMI出力に遅延がある」ということになります。
XPSThinkpadの本体ディスプレイの差がないと仮定すると、結果からは次のことが言えます。


(遅延:小) HORI Monitor + XPS <(0.75F)< XPS本体ディスプレイ ≒ Thinkpad本体ディスプレイ <(1.0F)< HORI Monitor + Thinkpad (遅延:大)


HDMI出力同士を比較すると1.75Fとなっており、2Fぐらいの遅延を感じるという体感とも近くなります。厳密っぽく計測しておいて、最後は体感に頼るというのは何ともアレな話なのですけどね。

ファンの音も比較

最後に、気になるファンの音について。
XPS 15のほうはやっぱりうるさいです。高い音ではないですが、扇風機ぐらい(?)の音はします。ゲームを終えれば少し静かになりますが、それでもしばらくは回り続けます。通常電圧のCPUと、性能が高めのGPUを積んでいるので、この辺りは仕方ないのでしょうね。
一方のThinkpadでは、一番うるさい状態がXPS 15の静かな状態とあまり変わらない、という程度の静かさです。そしてゲームを終えれば数秒でファンが止まります。
当たり前ですが、性能と静かさはトレードオフ、ということですね。

まとめ

3Dゲームを動かすという用途では、事前の予想通りXPS 15では高画質でも安定動作しました。一方、全く動かないだろうなと思っていたThinkpadでも低画質ならそれなりに動作することが分かったので、トレーニングモードで少し遊んだり調査するぐらいには使えそうです。
ただThinkpadのほうはHDMI出力が遅延しているのは予想外でした。たとえ本体の液晶がゲーミングディスプレイほどの性能でなかったとしても、HDMI出力すれば補えると考えていただけに、Thinkpadではそこが少し悪い方向に裏切られましたね。もちろん、2D中心で多少の遅延が許されるRPGシミュレーションゲームであればThinkpadでも問題なく遊べるので、ゲーム全般がダメというわけではありません。


ということで1ヵ月の間、XPS 15とThinkpad X1 Yogaの比較を行ってきました。
Thinkpad X1 Yogaはキーボードの打鍵感がよく、また話題にはしませんでしたがペン入力ができるというXPS 15にもMacBookにもない特徴を持っています(XPS 15もタッチパネルですが、ペンはありません)。そういう点で、エンジニアの開発マシンとしては良いでしょう。
またXPSはGTX 1050の恩恵もあって3Dゲームでも問題なく動作させることができます。HDMI経由でゲーミングディスプレイを接続すれば、より少ない遅延でプレイすることができます。今回の期間では試せなかったのですが、動画編集や配信などにおいてもXPS 15のほうが強いことが期待できます。そのような性能が必要となる作業向けマシンとして良いでしょうね。


最後になりましたが、XPSのレビュー機会を与えてくれたデルのアンバサダープログラムにはとても感謝しています。もしThinkpadXPSの両方を事前にモニターできていて、いま改めてXPSThinkpadのどちらかを買うか決めるのであれば、かなり悩んだでしょうねw
その場合、恐らくですが「XPSを買って外付けのキーボードを使う」という選択をしたと思います。ThinkpadHDMI出力が遅延するのは残念ですし、キーボード以外はXPSのほうが良い印象でした。


そんな感じでXPS 15とThinkpad X1 Yogaの比較はこれで終わります。このブログが、少しでも皆さんのPC選びに役立てば幸いです!