フロリダでヘラクロスとケンタロスとサニーゴを捕まえたときの話

※ 今回は開発的な話とは全く関係ない話です。ポケモンGoに興味ない方は読まないことを推奨します。まじで。

なぜフロリダなのか

2017/10時点で私が持っていないポケモンは、ヘラクロスとケンタロスとサニーゴの３つだけでした。
ガルーラは昨年オーストラリアで、ミュウツーは運良くEXレイドで捕獲済み。そしていつのまにかTL40。
そして、その３つが一気に捕獲できる場所を世界地図上で探したところフロリダという結論に。

オーランドにケンタロスはいない

フロリダで観光といえばオーランド。ディズニーワールドですね。
がしかし、ここで注意点が。オーランドではケンタロスは出ません。
フロリダ内でもかなり北の方に移動しなくてはいけないのです。

デイトナビーチには低確率で出現する

事前に海外トレーナーのTwitter投稿などをチェックすると、フロリダ内でもデイトナビーチでのケンタロス捕獲情報が。
そこで5日間の滞在のうち1日だけデイトナビーチまで足を伸ばす計画にし、日帰りでデイトナビーチに行ってきました。

がしかし、デイトナビーチ沿いにルアーを大量にともし、3時間いったりきたり歩き続けても全くケンタロスは出ず。
日が暮れてきて、諦めてタクシーに乗ったところ（デイトナビーチ⇔オーランドのバスは数日に1本しかなかった...）少し離れた浜辺にケンタロスの影が・・・
運転手に事情を説明して（同伴者が）浜辺の近くまで行ってもらい、10分ほど待ってもらいました。
オーランドに到着したときは、協力してくれたタクシーの運転手に多めにチップ渡しました。（当然ですね）

感想

サニーゴは結構いましたが、ヘラクロスもオーランドにたくさんいるかと思いきや1日1匹程度でした。
アバターエリアで一緒にレイドしたシカゴからきたという青年は、「Many Tauros in Chicago」と言ってました。
確実にケンタロス捕まえたい人はもっと北へ行ったほうが良さそうです。
自分はアプリ自体は無課金でやってますが、投資した交通費と時間はなかなかだと思います。
プラスルどうしようかな・・・

おまけ

BigQueryとData Studioで野球の分析レポートを作ろう

これはなに？

先日、第35回 GTUG Girls Meetup で初心者向け&女性向け BigQuery × Data Studio のハンズオンをしました。

gtuggirls.connpass.com

ハンズオンの資料

枚数が多くなるので、Markdownで一度作ったものを Reveal.js でスライドにしました。

https://omohayui.github.io/gtuggirls35/

※ 間違っていたSQL修正しました。

なごみタイムの様子

#gtuggirls DeNAオフィスで「BigQueryとData Studioで野球の分析レポート作ろう」やるよー！
今日のなごみタイムは豪華！！
DeNAさん日本シリーズ進出記念でお花がいっぱい！！ pic.twitter.com/9XGdGqrOVR

— yuzuafro (@yuzu_afro) 2017年10月25日

女子向けイベント＆ハロウィンシーズンということで、人事が奮発してくれました。
あと、日本シリーズ出場が決まった直後だったのでエントランスにお花が。

感想

• ハンズオンは資料作りが予想以上に大変
• ハンズオン直前に修正したSQLが間違っていた...
  • 確認大事
• 量が多かったかな・・・と思いつつ皆さん最後までいけた
  • 皆さん素晴らしい & チューターさんありがとう
• 一つ一つにSQLにコメントと説明をつけておくべきだった
• もっとデータ量豊富な野球データを使ってさらに分析っぽいことしたい

Sierra で Karabiner が使えず Escape のキーマップに困っていた人へ

[追記] High Sierra も Karabiner-Elements がサポートしているようです。

Sierra にアップデートしたときの問題

macOS に Sierra が登場し、とりあえずアップデートしたときの自分は Karabiner (キーカスタマイズツール) が使えず発狂寸前でした。
Vimユーザーにとっては Esc の位置は最重要です。（たぶん）
今までは、Karabiner で 「Control_L to Control_L (+ When you type Control_L only, send Escape)」の設定で、快適に過ごしておりました。

過去の記事： Macでキーマッピングを変更する方法 - omohayui blog

がしかし、Karabiner が使えない & 代替ツールの Karabiner Elements にも [Control] キー単体押しに [esc] を割り当てる設定がなく、 私は Sierra にアップデートするのを諦めました。

Karabiner Elements が進化している

先日PC(MacBookPro)を新しくして、また同じように Karabiner Elements 入れてみたところ・・・
彼は進化していました。 複数キーのリマップに対応していたり、特定アプリケーションだけで機能させたり。

Karabiner-Elements 11.0.0 から stable release となっているようです。

[Control] キー単体押しに [esc] を割り当てる方法

1. Karabiner Elements をインストールする

Karabiner - Software for macOS

2. Karabiner Elements を起動

「Complex Modifications」> 「Rules」> 「Add Rules」を click

3. Webから Rule を Import する

「Import more rules from the Internet (open a web browser)」を click

Karabiner-Elements complex_modifications rules から「Change control key」を Import

4. Import した Rule を有効にする

「Post escape if left_control is pressed alone.」を 「enable」 にする

以上！

Google Fonts が @import で読み込まれないとき

Google Fonts とは

fonts.google.com

Googleさんが提供している。Webフォント。
サーバー上の各フォントデータを読み込むことで、オサレなフォントが使えるようになるわけです。 そして無料。

起きていた問題

はてなブログのデザインをちょっと変えようと思って、
[デザイン] > [カスタマイズ] > [デザインCSS] の一番上で “Share Tech Mono” を import してみたところ、
プレビュー画面には表示されるが、更新後のブログには Google Fonts が反映されない。

@import url('https://fonts.googleapis.com/css?family=Share+Tech+Mono');

原因

詳細までは調べられてないが devtool 等で確認したところ読み込みタイミングがよろしくなさそう。

回避策

[デザインCSS] で読み込むのをやめて、headで指定するように修正。
[設定] > [詳細設定] > [検索エンジン最適化] > [headに要素を追加] に下記を追加するだけ。

<link href="https://fonts.googleapis.com/css?family=Share+Tech+Mono" rel="stylesheet">

これでブログ上も反映されるようになった。

リサイズした画像がぼやける件

Image Resizing Algorithm

経緯

Retina対応等が進む中、大きい画像をWeb上で縮小表示し高解像度ディスプレイに対応するケースが多々あります。
がしかし、ブラウザ固有のリサイズのアルゴリズムや表示画像サイズによっては、レンダリングされた画像がぼやけることも。
そこで、リサイズのアルゴリズムを正しく理解した上で、適切な対応方法を検討したい、という話なのです。

縮小表示の例

表示サイズ	width: 280px (原寸)	width: 140px (4px → 1px)	width: 145px (3.86...px → 1px)	width: 145px (3.86...px → 1px)
image-rendering	auto	auto	auto	pixelated
画像

（サンプル画像が古いことへの突っ込みは受け付けません。久しく絵と呼べるものを描いていないのです。）

Chromeで見た場合

• width: 140px は実画像サイズの1/2なので、4ピクセルが1ピクセルに縮小される計算
  • ⇒ ボケない
• width: 145px は実画像サイズから表示サイズに縮小する際にピクセル数が割り切れない少数になってしまう
  • ⇒ エッジがボケた感じになる
• width: 145px に style属性で image-rendering: pixelated; を指定すると、縮小アルゴリズムが「最近傍 (Nearest Neighbor)」に指定される
  • ⇒ エッジがギザる

IEで見た場合

ChromeのリサイズアルゴリズムがBilinearやBicubicといったエッジを滑らかにするアルゴリズムであるのに対して、 IEは元々Nearest Neighborのような単純なアルゴリズムを使っているようで、width: 145px をIEで見てもボケるというよりギザる感じでした。 （※個人的な主観です）

拡大表示の例

表示サイズ	width: 100px (原寸)	width: 300px (3倍)	width: 300px (3倍)
image-rendering	auto	auto	pixelated
画像

拡大表示の方がアルゴリズムの違いがわかりやすいです。

• 原寸の画像はあえてドットが分かりやすいようにしている 100x100pxの画像
• そのままブラウザで３倍のサイズに指定して表示すると、ドットのギザギザはブラウザのレンダリングの仕様によってぼかされて表示される
• style属性で image-rendering: pixelated; を指定すると、原寸のピクセルをそのまま拡大され、ドットがはっきり表示される

image-renderingの指定について

ブラウザ上のリサイズアルゴリズムを指定するのに使っていた image-rendering ですが、 まだ実験段階、開発途上といったところみたいです。

developer.mozilla.org

値	説明
auto	デフォルト値 バイリニア (Bilinear) リサンプリングなどの「滑らかな」色が許容されるアルゴリズムで拡大/縮小 高品質
crisp-edges	画像内のコントラストとエッジを保つアルゴリズムにより拡大/縮小 画像の処理過程で滑らかな色やぼかし効果が現れない ピクセルアートなどの画像を想定
pixelated	画像拡大時に「最近傍 (Nearest Neighbor)」などのアルゴリズムが使用され、画像が大きなピクセルで構成されたように表示される 縮小する時は、'auto' と同じになる → みたいな記述があるが実際に試してみると縮小表示でも「最近傍 (nearest neighbor)」が使われている模様

各ブラウザに対応させたい場合

.pixelated {
  -ms-interpolation-mode: nearest-neighbor;   /* IE8+ */
  image-rendering: -webkit-optimize-contrast; /* Safari (WebKit) */
  image-rendering: -moz-crisp-edges;          /* Firefox (Gecko) */
  image-rendering: -o-crisp-edges;            /* Opera 12.x */
  image-rendering: pixelated;                 /* Chrome 41+, Opera 29+ (CSS4) */
}

参照：http://memo.sdn-project.net/post/113148316679/pixelated

よく使われるリサイズアルゴリズム

滑らか度	名称	説明
低	NearestNeighbor (最近傍補間)	最も単純な拡大アルゴリズム 参照する位置に最も近い位置にある画素の輝度値を参照する 拡大縮小後の画素の実数を整数とみなしたときの誤差をそのまま表示すため、エッジにはジャギー（ギザギザ）が発生する 処理速度が非常に高速
中	Bilinear (バイリニア補間)	単純な線形補間による拡大アルゴリズム 補間対象となるピクセル周辺の２×２画素（４画素）を使って、輝度値を直線的に補間して輝度値を求める
高	Bicubic (双三次補間)	高度な拡大アルゴリズム 補間対象となるピクセル周辺の４×４画素（１６画素）を使って、輝度値を三次式で補間して輝度値を求める Photoshop の 「バイキュービック法 - 滑らか」がこれにあたる
高+	Lanczos3	動画や写真の縮小処理などで高品質で有名 補間対象となるピクセル周辺の６×６画素（３６画素）のピクセルを参照し、Bicubicとは異なる計算式で算出 処理速度は最も遅い 線画の縮小時にちらつきが見受けられたりする（経験談）

参照：http://imagingsolution.blog107.fc2.com/blog-entry-142.html, http://www.geocities.jp/numada777/ip05.html, http://www.amedama.com/blog/20110220392.html

対応案とまとめ

縮小表示

• 理想は表示サイズの２倍３倍といった整数値でピクセル表示ができる元画像サイズを用意する（とにかくこれ）
• ユーザーに入稿してもらったものを表示する際や１つの画像を同一画面で使いまわす際、縮小時にエッジがボヤける（特に線画）と言った場合は、 CSSで image-rendering を指定するといった手法もあり（※あまりおすすめできない）

拡大表示

• 通常の画像の場合は表示画像より大きいもの（Retina対応するのであれば４倍）を用意する
• ドット絵等あえてジャギー（ギザギザ）を見せたいものは、CSSで image-rendering を指定する方法もあり

Goのresizeパッケージ、giftパッケージを使って画像ファイル自体のリサイズ処理も色々と試したので、その話も書いておきたい気持ちある。