YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

AMP対応 2016.02版

はじめに

こんにちは、Go界のエルゴノミクスキーボードです。今日Googleがモバイル検索で Accelerated Mobile Pages に対応したというアナウンスがありました。

また中の人が仕組みや導入手順を書いてくれたようです。やさしい!!

しかしながら、私も今回のGoogleのAMP対応に関して、なぜかいろいろと知見が溜まったような気もするので、忘れないうちにこの場に書いておこうと思います。これはあくまでも私個人の意見であって、ここのコメントになにか書かれても一切お答えしないことを先に書いておきます。なお2016.02版としているのは、これからもいろいろと追加されたり変更されたりする可能性があるので、とりあえず現時点のものだという意思表示です。

まずAMPで何が出来るのか

よく聞かれることですが、まず大前提としてAMPは「一切」技術的に新しいことはありません。それどころか、現在ブラウザ上でウェブアプリケーションが実現できることが100だとすると、10くらい、あるいはもっと少ないことしかできません。しかしながら、出来ることを絞っているからこそ高速に表示ができるという、ごくごく当たり前のものです。当たり前でしょう、ということがQiitaの記事で書いてあったのでここにリンクしておきます。

しかしできないことが少ないながらも、収益化や分析や最低限のエンターテイメント性のためにはカスタムタグを作って、極力出来ること残しているという形です。

なにを目的としているのか

プロジェクトの公式サイトにも書いてありますが、私の理解では「静的なページをユーザが求める速度で素早く表示する」というところが主目的だと考えています。ですので、多くのユーザーインタラクションが必要なページはAMP化を考えるよりもProgressive Web Applicationのような形で実現するほうが筋が良いように思います。

「静的なページ」が何を指すのかといえば、ニュース記事、ブログポスト、店舗ページ、商品ページなど、内容の変化が無いあるいは少ないページを想定しています。いくつかは実際にサンプルにも載っています。

どうすればAMP対応になるのか

先のGoogle Developers Japan Blogのポストに手順が紹介されていますが、どこからか得た知見を元にもう少し詳細に書いておこうと思います。特にこれはGoogleクローラーがインデックスするための内容です。

1. URL構造の決定

そもそもAMP化するという場合、既存のモバイル向けページを置き換えるというイメージを持たれる方がいますが、そうではなく、そのページは残したままAMP HTMLの仕様に従ったページを追加で作成するという形になります。*1 そして、元のページ(canonicalページ)とAMPページをお互いに <link> タグで指し合う必要があります。例示すると

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>Lorem Ipsum</title>
  <link rel="amphtml" href="https://example.ampproject.org/amp/article-metadata.html" />
  ...
</head>
<body>
  ...
</body>
</html>
  • AMPページ
<!doctype html>
<html AMP lang="ja">
<head>
  <meta charset="utf-8">
  <title>Lorem Ipsum</title>
  <link rel="canonical" href="https://example.ampproject.org/article-metadata.html" />
  ...
</head>
<body>
  ...
</body>
</html>

そのため、CMS等で自動生成する場合には元ページに対してAMPページをどのようにするか決めておく必要があります。たとえば

AMPページをGoogleクローラーが見られるようにする

キャッシュ出来るようにするためにはGoogleクローラーが見に行けないと意味ないのでrobots.txtやメタタグにnofollowなどがないようにします。 たとえばこういうタグがあったらアウトです。

<meta name="robots" content="nofollow,noarchive">

AMPページを作成する

AMP HTMLの必須事項にしたがってAMPページを作成します。特にAMP HTMLの仕様とGoogleインデックスの仕様で異なる部分はschema.orgの仕様にしたがったメタデータの付与が必須である点です。

またAMPが発表された直後のブログポストではboilerplateのタグが次のような形になっていましたが、これは古いので(一応validになりますが)変えたほうがいいでしょう。*2

<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>

いまのコードはこちらです。

<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

validatorを使って検証する

現在、開発者が使えるvalidatorは次の2種類があります。

  1. URLにフラグメント #development=1 をつけてGoogle Chromeなどのデベロッパーコンソールで確認できるもの
  2. node.jsで書かれたコマンドラインで動かせるもの

基本的には1でテストするのがお手軽ですし、開発中はこれが楽だと思います。ただCIなどに組み込む場合は2を使うのが良いと思います。当たり前ですが2のほうが実装としては新しいので、1で見つからないエラーが2で見つかることもよくあります。

メタデータが正しいか確認する

AMP HTMLの検証が通ると結構安心してデプロイしてしまうのですが、メタデータが正しくないとGoogleクローラーはキャッシュしてくれないので、Structured Data Testing Tool で検証します。また schema.org よりも制限があるところでよく引っかかるのは次の2点です。

  1. logoのImageObjectのurlがPNGJPEGGIFになっていない
  2. imageの横幅が696px未満

特に1はエラーになるので注意です。詳細はこちらのページにあります。

Search ConsoleのAMPレポートツールで状況を確認する

実際にインデックスされたAMPページはここに表示されます。手元でAMPのvalidatorやStructured Data Testing Toolで何もエラーが出ていないのに、ここでエラーが出ている場合でよくあるのが、テスト段階でクローラーが見に行ける場所にAMPページを置いていて、一度invalidな状態でインデックスされてしまった場合です。その場合はSearch Consoleから再クロールのリクエストをしましょう。

よくある質問やはまりどころ

canonicalページはPC版とモバイル版どちらを指定したらいいでしょうか

すでにPC版とモバイル版それぞれにおいてページを作成している場合に、AMPページで指定するcanonicalページはどちらを指すべきか、ということですが、結論から言えばPC版とモバイル版だけを見た場合に、その2つでcanonicalになっている方を指すようにしてください。(たいていはPC版がcanonicalになっていると思います)

整理するとPC版がcanonicalで、各々次のようなURLになっている場合

このような関係になります

amp-adはどのアドネットワークに対応していますか

まずはここを見ることをおすすめします。type属性で対応しているアドネットワークであれば非常に簡単に設置できます。

また使用しているアドネットワークが対応していなかった場合には、ぜひそのアドネットワークの方にampprojectのレポジトリにpull requestしていただけるようリクエストされることをおすすめします。アドネットワークの方であれば、ぜひ率先してpull requestされることをおすすめします。以下公式ドキュメントより引用。

We welcome pull requests by all ad networks for inclusion into AMP.

amp-xxxxというタグはどう使ったらいいでしょうか

とりあえず以下のページを見てイメージを掴んでから公式のドキュメントを見るのがおすすめです

公式のドキュメントはGitHubレポジトリのMarkdownファイルを見るのが最新なのでおすすめです。

アナリティクスを使いたいですがどうしたら良いですか

まずGoogle AnalyticsAdobe Analyticsは両方共対応しています。他にも多くのアナリティクスツールに対応しています。type属性を確認してください。詳しくは次のドキュメントを参照。

最も気になるところとして取得できるイベントとデータだと思いますが、現状日々増えているので常に次のドキュメントを確認することをおすすめします。

<amp-analytics> 要素を <head> 要素内に書きたい人もいますが、 <body> 要素内に入れてあげてください。またAMPプロジェクトが発表された直後の記事などに <amp-pixel> を使った例がありますが、こちらもあまりおすすめしません。

styleについて

AMPの制限で一番きついところの一つにstyleを <head> 要素内の <style amp-custom> 要素内で一発で決めないといけない、というのがあります。CMSなどの開発をされている中で、 <article> 要素の入稿である程度自由にタグを挿入できる機能がある場合は、まずあらゆるstyleを全部 <head> 要素内に押しやらないといけないですし、要素内の属性もかなり削ってやらないとinvalidになります。

AMP対応のブラウザはなんですか

まず、そもそも「Accelerated Mobile Pages」なので、デスクトップブラウザは(動かないわけではありませんが)無視してください。また最初に書いたとおり、AMP HTMLというのは、HTML5の仕様に制限をつけただけのものです。なのでHTML5を解釈するモダンなモバイルブラウザであれば基本的になんでも動きます。ただそれ由来で細かいところで差異が出てくることも承知しておいてください。(例: <amp-video> タグ)

おわりに

どこからか得られた知見でした。

*1:もちろん、AMP HTMLのページに置き換えることも可能です。その場合はそのページ自体をcanonicalページとします。

*2:ここにも古いって書いてあります

恵贈御礼 「Go言語にWebアプリケーション開発」読了

はじめに

こんにちは、Go界のパルメザンチーズです。オライリー・ジャパンより次の本をいただきました。ありがとうございます。

Go言語によるWebアプリケーション開発

Go言語によるWebアプリケーション開発

感想

Go言語そのものをまったく書いたことがない人がいきなり本書を読むのはいささか厳しいと思いますので、あらかじめ A Tour of Go などを終え、FizzBuzz程度でもいいので簡単なコマンドラインアプリを手元で書いてみてから読み始めるのが良いと思いました。

この本で一番読み応えがあったのは、監訳者の鵜飼さんによる日本語訳版オリジナルの書き下ろしである「付録B:Goらしいコードの書き方」でした。本書を読むにあたって、まず最初に読むべき章だと言っても過言ではありません。本文に出てきたソースコードをより洗練するためにどのような点に注意すればよいかが書かれている貴重な日本語資料です。また本文のいたるところで補足するべき箇所にきめ細かな監訳注があるのも、日本語訳版の素晴らしいところです。この監訳注によって本書の品質が大幅に向上していることは間違いありません。

内容そのものは、構造化された解説書というよりも、実践的なチュートリアル本というのが適切でしょう。Goの文法はわかったけれどどこから手をつけていいかわからないという方は、まずは自分が取り組んでみたいと思っているテーマに近い章を開き、本文にしたがって少しずつコードを書きながらGoでプログラムを書くことに慣れるというのがおすすめです。サードパーティーライブラリの紹介なども多かったので、他言語の経験があるけれどもGoは初めて、という方にも肩慣らし的に試すのには手っ取り早い本だと思います。

1-3章がWebSocketを使った簡単なチャットシステムのフロントエンドとバックエンド、4章で簡単なコマンドラインツール、5-6章では並列処理を使ったデータ解析サービスとそのREST API化、7章ではファイルバックアップシステムと、テーマは多岐にわかっていますので、つまみ食いでも始めやすいです。

Goはシステムプログラミング言語としてよく知られていますが、実際にどういう形で実現できるのか、本書で実感いただけるのではないかと思います。

読書メモ

ページ数は書籍版のものです。

p.21 監訳注2

デフォルトのパッケージ名は package キーワードで指定されたものであり、ディレクトリ名ではないが、通常は揃えるという話。違ってくる場合としてよくあるのはパッケージをバージョンニングするとき。たとえば、Google Drive APIのクライアントライブラリはv1, v2, v3と3つのバージョンがある。これをimportするときは次のようになる。

import github.com/google/google-api-go-client/tree/master/drive/v3

p.81 監訳注1

パッケージ名に commonlibutil を使わないようにしようという話はgoblogに詳しく解説されている。

p.158 ノート

GorillzはGorillaのtypoだと思う。muxerも自分で書いてみるような問題もあれば良いのにと思った。

p.221 監訳注2

const では指定しないかぎり型がないという話はgoblogに詳しく解説されている。

「高熱隧道」読了

はじめに

こんにちは。Go界の日本電力です。年末に買った本を年末年始で読めなかったので、昨晩一気に読み終えました。

高熱隧道 (新潮文庫)

高熱隧道 (新潮文庫)

仙人谷ダムと黒部ダム

プロジェクトXで取り上げられてたのは、黒部ダム(通称「黒四ダム」、黒部第四発電所のためのダム)で、この高熱隧道の舞台になっている場所よりもさらに奥地に建設されています。黒部ダムの建設に関する逸話は小説をはじめ、映画、ドラマやドキュメンタリーの形で取り上げられているため、名前を知っている人も多いし、自分もプロジェクトXではじめてその壮絶な工事を知ったときには圧倒されたことを覚えています。工事での殉職者が171人にも及んだというのは、高校生の自分には衝撃的な内容でした。黒部ダムの難工事に関する物語としては「黒部の太陽」が有名でしょう。

黒部の太陽

黒部の太陽

しかし、その20年以上も前、まだ戦時中に同じ黒部川水系で、黒部ダムに負けずとも劣らない難工事が行われていたことをこの小説で初めて知りました。その内容が本当に壮絶で、真の意味でデスマーチと呼びたくなるものでした。

本当のデスマーチ

どういう意味でデスマーチだったのか、ある程度ネタバレにはなりますが書いてしまうと

  • そもそも工区にたどり着くまでの道が切り立った岩場を繰り抜いた程度のもので道幅がわずか60cm程度。資材の運搬を行うボッカが工事着工前にあっという間に5名転落死する。
  • 工区そのものが温泉湧出地帯のまっただ中を通過することが工事着工前の地質学者による調査では明らかになっていなかった。
  • 掘削する岩肌が開始30m地点ですでに摂氏65度を超え、掘り進めるにしたがってどんどん加熱、最高地点では摂氏166度に。
  • 掘削中の隧道内はサウナ状態であり人夫が切端で作業を行える時間がたった20分に。それですら、失神する人夫も数多くいた。
  • 人夫を冷やすために渓谷から汲み上げた水を人夫にかけるが、その水が隧道内にたまり人夫の膝まで、ひどい時には腹までたまるほどに。しかも岩肌に暖められて水温が摂氏45度まであがることも。
  • 岩肌がダイナマイトの発火温度を超えるほどになってしまい、設置と同時に爆発。担当していた人夫が死亡。

まだまだこれは序の口で、最終的にこの工事による殉職者が300人に迫るほどになるわけですが、それに至る過程が緻密な描写で淡々と語られていくのがこの小説の恐ろしいところです。多数の犠牲者を出しながらも工事が中止とならなかった背景には、工事の発注元の日本電力の社運をかけた工事だったことと、当時電力が国家的に求められていたこと、しかも天皇からも恩赦がでるほどであったため辞めるに辞められなかったという状況があるようでした。

吉村昭氏の綿密な調査により、工事中の隧道の様子が細かな部分まで伝わってくる、素晴らしい「記録小説」でした。小説に登場する人物や企業はフィクションではあるものの、実際にそれに対応する人物や企業がいるようです。実際に小説中の各事件での殉職者数は現実の事件と一致しています。

デスマーチ」という言葉を職業柄よく聞きますが、真の意味で「デスマーチ」の物語でした。

YAMAGUCHI::weblogの2015年を振り返る

はじめに

こんにちは、Go界の北陸新幹線です。今日でまた1歳を歳を取りました。例のやつ貼っておきます。

関連エントリ

振り返り9年目です。

ymotongpooの2015年

昨年立てた目標

まず昨年立てた2015年の目標を振り返ります。

  • Go関連情報の継続的なアウトプット
  • Android開発の技術力の向上
  • 「通知」に関する研究
  • 英語力の向上
  • 仏教について学ぶ
  • 経済について学ぶ
  • RAWデータの現像技術の向上

Go関連情報の継続的なアウトプット

今年は特にGo関連のイベントも数多く開催され、アドベントカレンダーではGoのものが3つも満員になるなど、ますますGoが普及してきたことを強く感じています。

2年前からは考えられないほどの広がりを見せていて、自分がなにかするまでもなく多くの情報が共有されています。なので去年の暮れに立てた目標は、すでにコミュニティによってなされていたなあという印象です。

Go Conferenceも去年までは自分が主催でしたが、いまはもう完全に @tenntenn に引き継ぎ、自分も一参加者として楽しませてもらっています。

今度はまた新しく、よりディープな集まりを企画したいなあと考えています。

Android開発の技術力の向上

これはこの1年でぼちぼちかけるようになった感があって、楽しくなってきたなーと思います。(外に出せないやーつが多い)

来年はAndroid Wearの開発あたりをちょっと盛り上げていきたいなあと思います。

「通知」に関する研究

これは広いテーマなので1年でぱっと何か見つかるというものでもないと思いますが、自分のなかで「コンテキスト」と「コンテンツまでの距離」というキーワードで通知に関する考察が進んだ一年でした。

そのテーマについては、対外的なイベントで話したりもして、少しずつですが整理ができてきた感じがします。

「通知」は過去2年間関わってきていますが、これからはより「通知」のデザインや体験というものが重要になってくると感じているので、2016年はより多くの方から意見を聞きながら考えを深めていきたいと思います。

英語力の向上

漠然と目標として書いていたけれども、担当するプロダクトが増えたりして、本社とのやり取りも増えたので、英語でのやり取りが増え、結果として去年よりも確実にコミュニケーションが楽になっていると感じました。ただそれはあくまで日常的な業務をこなすレベルであって、逆にだいぶ本を読んだりするのがしんどくなってるんで、来年はもうちょい英語のブログなり記事を読む機会を増やしていこうと思います。

仏教・経済について学ぶ

ここに時間が割けなかったなーというのが今年の反省点。特に経済に関しては、2016年は家計の整理や運用などをしながら、理解を深めていこうと思います。

RAWデータの現像技術の向上

今年はイタリアに旅行に行ったり台湾に旅行に行ったりと写真を撮る機会が多い1年でした。それにともなってLightroomを使う機会も増え、だいぶ使い勝手がわかってきた感じがします。

ただクロッピングはまだ苦手なんで、より素材を活かせるよう、2016年も写真撮りまくっていこうかと思います。

今年特によくやってたこと

仕事など

あまり外に書くことがないので、改めてここに書こうと思います。自分はGoogleでDeveloper Relationsという組織の中で、Developer Partnersというチームに所属していて、ざっくり言うと、大きめの企業がGoogleの技術を利用してアプリの機能向上をする支援をしたり、そういった機能の普及を行うということをしています。関わった程度の大小はありますが、今年は外に出たもので言うと、次のような事例の裏で関わっていました。

直接、表に出る機会が減っていますが、多くの優秀な開発者と関わることができて楽しい1年でした。テーマとしている「コンテンツまでの距離」と「コンテキスト」を軸として、これからも多くの企業に機能を採用してもらえるよう、お手伝いできればと思います。

ffmpeg

今年は特に動画のトランスコーディングにはまった一年でした。毎日トランスコードをしまくっているわけですが、そのなかで徐々にffmpegのオプションを変えながら、いかに良い画質で小さいファイルサイズにするか、というところを突き詰めていくのが楽しくて仕方ありません。2015年中は、以前使っていたマシンを使いまわしていたわけですが、静音化を図るために、2016年は新しいマシンを組もうかと考えています。

またVP9やH.265など新しいコーデックもそろそろ普及に関しての動きが見えてきそうなので、興味がある人を探して情報交換をする機会を作れたらなあと思います。

360度動画に関する調査

今年のGoogle I/Oでは Google JUMPProject Spotlight などの360度動画に関連する発表がありましたが、ここは今後の静止画・動画の発展の方向として確実に広がる分野なので興味を持って仕様や各社の製品などを見ていました。

特にInterBEEや各企業の展示会などで360度動画カメラなどが多く出展されていたことからも、2016年は360度動画撮影の年になるんじゃないかなと感じています。

来年に向けて

  • 動画関連技術で遊ぶ
    • 特に自宅の動画トランスコーダの新設をしていろいろとコーデックを試したい
  • アクションカムと360度カメラで遊ぶ
    • GoPro HERO4とTHETA Sを手に入れたので動画撮りまくろう
  • Androidで遊ぶ
    • 遊ぼう
  • 資産運用を真面目に考える
    • もっとよく資産をうまく運用しないと

QNAPのTurboNASが吹っ飛んでtestdiskに助けられた話

はじめに

こんにちは。この記事は pyspa Advent Calendar 2015 の22日目の記事です。Go Advent Calendarとまったく同じ日に登録したことにあとで気づいて、すごく後悔しています。そんなわけで、今日は自宅のTurboNASが吹っ飛んでtestdiskに助けられた話をします。最後提灯記事っぽいけど、1ユーザとして便利なので書きました。

TL;DR

  • TurboNASは便利だけどデータが吹っ飛ぶ危険はある
  • testdisk超助かる
  • Google Apps for unlimited storage and vaultで安心を買った

QNAPのNASは素晴らしいです

2012年2月に買ってから自宅のNASとして活躍していたQNAPのTurboNAS(TS-659+ Pro、いまは売ってないっぽい)なんですが、こいつがなかなかすぐれもので、RAID 0/1/5/6/10なんかを簡単に組めて(ソフトウェアRAID)、イーサネットポートも2口、iSCSIでも使えて、CIFS/AFP/NFSでもマウント可能、他にもメディアトランスコーダーや、DLNAサーバー等々、各種サービスもWebのGUIでちょいちょいっと簡単に設定できる。Mac使ってる人にはTimeMachineにもなってくれる便利なやつです。

f:id:ymotongpoo:20151222171138p:plain

で、写真などのメディアや必要書類をスキャンした電子ファイルの保存など、結構重要な役割を果たしていました。そんな中、今年の10月末にHDDの警告が出ていたので、新規HDDに換装しようとしたところ、久しぶりだったため手順を誤ってしまいました。

ホットスワップができるというのが製品の売りなので、とりあえず前のHDDにもどして、再構成が終わるのを待ってたんですが、なんかいやな予感がするわけです。で、再構成が終わっても、RAID5の仮想ディスク領域をマウントできない。個々のディスクは認識してるので、まさかと思って確認してみるとRAID5のパーティションテーブルがぶっ壊れてました。

すでにその時ディスクには6TB-7TBくらいのデータがあったのでかなり冷や汗モノでした。

復旧作業

最初mdadmでRAIDから外れてるディスクを追加しようとしたものの、そいつ自体のパーティションテーブルが壊れてるということで弾かれ、しょうがないのでmke2fsでスーパーブロックのアドレス見てから、e2fsckで修復試みてみたものの全然状況が変わらないんで、これ以上手をいれるのはまずいということで、RAID自体の復旧は断念しました。

しかしディスク自体はまだ生きてるようなので、上書きされてしまう前にデータのサルベージを行うことにしました。諸々探してみた中で最も信頼性が高かったのが testdisk でした。

www.cgsecurity.org

testdiskはパーティションの復旧などをTUIでサポートするというのが主な機能ですが、復旧可能パーティションに対して、拡張機能(Advanced)の中にある List メニューを選択すると、読み取れるファイルがすべて表示されます。幸い中を確認したかぎりではファイル自体は生きてそうなので、急いで3TBの外付けHDDを購入し、TurboNASに接続、testdiskで2週間かけてほぼすべてのファイルをサルベージし、事なきを得ました。

Google Apps with unlimited storage and Vault

ところで、Google Appsには「Google Apps with unlimited storage and Vault」というプランがあります。これは5名以上いれば、月々1200円で容量無制限のGoogle Driveが利用できるというものです。(もちろん他のGoogle Appsの機能も使えます)

apps.google.com

閲覧用の写真のJPEGデータはいまはGoogle Photosで管理しているので、容量を心配することないんですが、オリジナルサイズやRAWデータはやはりデータが大きく、かと言って今回のようなことがあるとせっかくの思い出が全部消えてしまうのでなかなか扱いに困ってしまいます。これまではNASですべて管理してたのですが、今回の事故を期に有志を募ってこちらのプランを契約しました。先ほどの3TBの外付けHDDが14000円弱だったので、こちらのプランのほぼ1年分の価格です。その価格で安心を買えると思ったら安いものだなと思います。

また副次的に、ウェブでもスマホでもいろいろなクライアントがあるので、どこでも中身を簡単に確認できたりするのがとても楽です。スキャンしたPDFなんかを外で楽に閲覧できるのが地味に助かっています。

おわりに

やっぱりでかいファイルが多くなるとふっとんだ時のリスクがでかいので、大人しくストレージサービス借りたほうが結果的に安いですね。