読者です 読者をやめる 読者になる 読者になる

YAMAGUCHI::weblog

土足で窓から失礼いたします。今日からあなたの息子になります。 当年とって92歳、下町の発明王、エジソンです。

TypeScript 2.0.0とVisual Studio Code 1.4でChrome拡張を書く

TypeScript Chrome

はじめに

こんにちは。ナルゲンボトル愛好家です。ふと思い立ってChrome拡張作ろうかなと思ったんですが、どうせならTypeScriptでやるのがいいじゃねえかってことでやりました。で、最近ブログ書いてないし、なんかまとめたらいい感じかなと思ったのでまとめます。

構成

.
├── dist // 生成された拡張
│   ├── context-menu.js
│   ├── icons
│   │   └── icon48.png
│   └── manifest.json
├── gulpfile.js
├── .eslintrc.json
├── package.json
├── static
│   ├── icons
│   │   └── icon48.png
│   └── manifest.json
├── ts
│   └── src
│       └── context-menu.ts // Chrome拡張をTypeScriptでやってくやつ
└── tsconfig.json

毎回思うんですが、ちょっとのことやりたいだけなのに xxxx.json みたいな設定ファイルばっかりでほんとにだるい。だれかなんとかしてほしい。

下準備

typescript@2.0.0 を Visual Studio Code の参照先にする

あたりまえだけどまずTypeScriptが必要。今回は新しいやつを早く使いたかったんで @2.0.0 をグローバルに入れた。バージョン使い分けるほど使ってません。

$ npm i -g typescript@2.0.0

最近はエディタは軟派にVisual Studio Codeをよく使ってるんだけど、こいつがデフォルトで使うTypeScriptの設定を変えてやらないと新しい文法とか出てきた時にlintがうるさいので変えておく。Visual Studio CodeのUser Settingsでこんな感じの設定をしておく。ワークスペースごとに使うTypeScriptのバージョン違うという人がいたら、Workspace Settingにして、Workspaceのtypescriptを参照するようにしたらいいんじゃねえかと思いますが、やったことはありません。

"typescript.tsdk": "/Users/ymotongpoo/.nvm/versions/node/v6.3.0/lib/node_modules/typescript/lib"

Chrome Extension APIの型定義ファイルを参照する

TypeScriptの恩恵にあずかりたいので型定義ファイルを持ってくる。当然Chrome本体にモジュールはあるため、型定義ファイルだけあれば良いので、 id:otiai10 に感謝を唱えつつモジュールを落とす。

$ npm i @types/chrome

あとは普通に使えば良い。tsconfig.jsonとcontext-menu.tsはこんな感じでやっていく。tsconfig.jsoncompilerOptionsChromeがES5で頼むって感じだったはずなので target に気をつけるのと、あとでbrowserifyするんで modulecommonjs にしときました。momentは単に今回使ったので特に重要じゃないです。

{
    "compilerOptions": {
        "target": "ES5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": false,
        "noImplicitAny": false
    },
    "files": [
        "./ts/src/context-menu.ts",
        "./node_modules/@types/chrome/index.d.ts",
        "./node_modules/@types/filesystem/index.d.ts",
        "./node_modules/@types/filewriter/index.d.ts",
        "./node_modules/@types/moment/index.d.ts"
    ]
}

context-menu.tsでは参照しときましょう。

/// <reference path="../../node_modules/@types/chrome/index.d.ts" />

いい感じになった。

f:id:ymotongpoo:20160805131904p:plain

gulpの設定

grunt だとか gulp だとかなんか周辺ツール多すぎてホント嫌になってくるんですが、まあそういう形で回っちゃってるものはしょうがないので文句言いながら gulpfile.js 書きます。必要なパッケージを入れときます。

$ npm i -g --save-dev browserify
$ npm i --save-dev vinyl-source-stream tsify gulp-jsmin
$ npm i -u typescript@2.0.0

ローカルにもtypescript入れるのはtsifyでtypescriptモジュールをrequireしてるため。tsifyだけにしちゃうと依存してるデフォルトのバージョンが入っちゃうんでこうやってる。最初はgulp-typescript使ったりしてたんだけど、公式サイト見に行ったら使わないで一発でbrowserifyしてて楽だったので真似した。

const gulp = require('gulp');
const del = require('del');
const browserify = require('browserify');
const source = require('vinyl-source-stream');
const tsify = require('tsify');
const jsmin = require('gulp-jsmin');

const config = {
    browserify: {
        opts: {
            basedir: '.',
            entries: ['./ts/src/context-menu.ts'],
            cache: {},
            packageCache: {},
            debug: false
        }
    },
    source: {
        target: 'context-menu.js'
    }
};

gulp.task('copy', [], () => {
    return gulp.src('./static/**/*')
        .pipe(gulp.dest('./dist'));
});

gulp.task('build', ['copy'], () => {
    return browserify([], config.browserify.opts)
        .plugin(tsify)
        .bundle()
        .pipe(source(config.source.target))
        .pipe(gulp.dest('./dist'));
});

gulp.task('minify', ['build'], () => {
    gulp.src(['./dist/**/*.js])
        .pipe(jsmin())
        .pipe(gulp.dest('./dist'));
});

gulp.task('clean', [], () => {
    return del(paths.dist.dir);
});

gulp.task('default', ['minify']);

使ってたmoment.jsの型定義ファイルだけインストールして、肝心のmomentパッケージ自体をインストールし忘れたことで、当然concatされないことを気付かずに悩むみたいなバカなことをしたけど、まあ動いちゃえば単純。

distをパッケージにする

普通にここに書いてあるとおりにやるだけです。Macな人はコマンドが若干異なるけどほぼ一緒です。

$ '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome' --pack-extension=dist

というわけで dist.crx が出来て嬉しいですね。

おわりに

設定ファイル何個書かせるんだよ。めんどくさい。

CIサービスだけでErgoDoxのファームウェアをビルドして公開する

ErgoDox

はじめに

こんにちは、Go界のalva notoです。ErgoDoxを買ってから1ヶ月が経ちますが、毎日快適にデスクワークをしております。そして日々ErgoDoxを使いながら常に新しいキー配列を模索しています。ErgoDoxの良い点は単純にセパレート型で肩が開く点だけでなく、自より指(腱)に負担がかからない配列に自由に直せるという点もあります。ただ、自分でキー配列を変えたファームウェアをビルドするのはちょっと面倒。

これまでは単一キーのみのアサインだったのでMassdropのコンフィギュレーターを使っていましたが、さらなる最適化を求めてファームウェアを自前でビルドし始めました。しかしながら、毎度毎度VagrantやDockerで環境を立ち上げてビルドするのは面倒なので、CIでビルド出来るようにしましたので、その情報を共有します。

ビルドプロセスの設定

普通に手元で動くTeensy用ファームウェアのビルド環境があれば普通にdockerの環境で都度ビルドしたり、CIであればJenkinsなりdrone.ioなりでビルドを回せばいいのですが、自分はそのためにサーバを持ちたくなかったので、werckerでビルドしてビルド済みバイナリをbintrayにアップロードするようにしました。一連のプロセスを実施するwercker.ymlは次のファイルです。

今回はこのレポジトリをforkした前提で話を進めます。

bintrayの設定

まずアップロード先のbintrayの設定をします。まずアカウントを作ると何をしていいのかさっぱりわからないトップ画面に連れて行かれますが "Owned Repository" の "view all" をクリックすると自分が所有するレポジトリの一覧が表示されるので "username/generic" にいきます。 f:id:ymotongpoo:20160424120930p:plain

genericレポジトリ内に ergodox.hex というパッケージを作成します。*1 f:id:ymotongpoo:20160424121111p:plain

それが終わったら画面右上のユーザ名をクリックすると出てくるメニューから "Your Profile" を選択し、表示された画面で自分のアイコンの隣にある "Edit" ボタンを押します。進んだ画面で "API Key" のメニューを選択して、そこに表示されているAPI Keyをどこかにメモっておいてください。 f:id:ymotongpoo:20160424121515p:plain

これで bintray 側の設定はおしまいです。

werckerの設定

次に wercker の設定をします。ログインした後に、新規Applicationを作成します。 f:id:ymotongpoo:20160424121711p:plain

するとレポジトリの選択画面が出てくるので、forkしておいた qmk_firmwareレポジトリを選択し、"2. Configure access" ではデフォルトを選択します。最後にビルドの様子を公開するかどうかは適当に設定しておいてください。無事にApplicationが作成されたところで、Applicationの設定をします。

werckerではbuildフェーズとpipelineフェーズで各々の設定が必要です。まずbuildの設定をします。 Applicationの右上にある "Settings" から設定画面にとんで、"Environment variables" のメニューで環境変数 "TARGET_KEYMAP" の設定をします。もしレポジトリ内に気に入ったキーマップがあったらそのディレクトリ名を、特になければ default にしてください。 f:id:ymotongpoo:20160424125242p:plain

次にdeployフェーズでbintrayにファイルを置く設定をします。 "Targets" のメニューで表示された "Add deploy target" を選択します。適当に Deploy target name に名前を付けて、Auto deployにチェックを入れ、対象のブランチ名を書きます。 f:id:ymotongpoo:20160424124007p:plain

すると "Deploy pipeline" という項目が表示されるので、そこで deploy に必要な環境変数などを設定します。次の表のように環境変数を設定してください。

環境変数
BINTRAY_USERNAME bintrayのユーザ名
BINTRAY_APIKEY 先ほどメモしたAPI Key (protectedにチェックを入れておくと良い)

キーマップの変更とデプロイ

下準備が整ったところで、キーマップの変更をしましょう。ErgoDox EZ用のディレクトリが qmk_firmware/keyboard/ergodox_ez にあり、このディレクトリ内の keymaps にいろいろなキーマップが事前定義してあります。良いキーマップを見つけた人はそのディレクトリ名を先ほどのwerckerの TARGET_KEYMAP に設定すれば良いです。しかし、私は自分なりのキーマップにしたいので書き換えます。基本的に default を書き換えるようにしています。この keymap.c がキーマップの設定を持っているソースコードです。

C言語で書かなければいけないような雰囲気を感じますが、面倒な関数定義やマクロ定義はすべて終わってるので、そのなかのキーアサイン用の配列を書き換えるだけです。キーの設定に関してはこのドキュメントとヘッダファイルを読むと良いでしょう。

MOD_T系(CTL_T、GUI_Tなど)は「押しっぱなしにしていると修飾キーに、それ以外はマクロに渡したキーコードになる」という設定なので、これを使いこなすと非常に強力なのではないかと思うんですが、自分はその設定はしていません。

変更を行ってGitHubにpushすればあとはwerckerが自動でビルドしてbintrayにデプロイしてくれるのでちょっと落ち着いて待っていましょう。無事にアップロードされるとbintrayのほうに「ブランチ名-コミット番号」というバージョンができています。 "Files" のメニューからダウンロードして、Teensy Loaderなどを使ってErgoDoxに焼いてください。 f:id:ymotongpoo:20160424132131p:plain

おわりに

ErgoDoxのノウハウが世の中に多く出てくればいいなと思います。ぜひみなさんもシェアしてください!あと、自分のTLを見ていてみErgoDoxを自分で組立たり既成品を買ったりしている人がちらほらと増えてきたので、ぜひ現状確認会のような集まりをしたいと思っています。

参照

関連レポジトリ

ErgoDox

ErgoDoxを使うが起きる日本語の記事

*1:別にどんな名前でもいいんですが、上記のwercker.ymlを使い回すならこの名前にしてください。

ErgoDoxを購入して人生がバラ色になった

ErgoDox misc

はじめに

こんにちは、Go界のスコット・ヘレンです。最近はPrefuse 73を毎日聴いています。今日は久々に熱いガジェットが2ヶ月ごしに届いたのでその話を書きます。

エルゴノミクスキーボード

「エルゴノミクス」と呼ばれるものがあります。日本語では「人間工学」などと呼ばれています。普段使っている道具が作られた時に、人間の操作しやすさや疲労のしにくさといったものが考慮されていないことがよくあります。たとえば、PCのキーボードなんかはそうで、もともとタイプライターというものが存在した前提があって、そのキーの並びをそのまま持ってきたのが現在のキーボードの標準のキー配列であるQWERTY配列です。これはPCのキーボードの配列としては理にかなっていないということで、Dvorak配列というキー配列が登場したわけです。

キー配列に関してはすでに慣れてしまったので、いまからDvorakに変更するということは(おそらく)しないと思います。しかし、慣れの問題では済ませられないものがあります。それがキーボードの形状そのものです。PCのキーボードは、典型的なものでは長方形の板状の筐体に50個超のキーが配置されています。人間がそこに手を伸ばしてホームポジションに手を置いてキーを打とうとすると、どうしても手が内転してしまいます。腱鞘炎待ったなしです。そこでエルゴノミクスキーボードでは、なるべく手首が内転しないように真ん中を盛り上がらせたり、キーの配置を少し変えてみたり、あるいはKinesis Contouredのように、キーの配置を2箇所に分けた上にキーをおわん型に配置するなどの工夫をしています。

これですべて解決しているように思えますが、残念ながら自分はまだ納得入っていませんでした。5年ほど前にマッサージ師から肩こりがヒドイのでエルゴノミクスキーボードに変えたほうが良いとのアドバイスをうけ、Kinesis Contoured を使うようになり、たしかに肩こりはなくなりました。しかしながら、まだ肩が内側に入ってしまい、リラックスまであと一歩という状況でした。理由は簡単で、キーボードの幅と肩幅を比べた時に、肩幅のほうが広いからです。普通は肩幅よりも圧倒的にキーボードのほうが狭くなります。そうなると、キー入力の際には必然的に両手が肩幅よりも内側に来るようになります。試しにその状態で胸を張ってみてください。無理だと思います。人間はそういう姿勢で胸を張れるように出来てません。

ErgoDoxとの出会い

もちろん上記の不満点から、セパレート型のキーボードを検討したこともありました。しかし、そうすると今度はキー配置が気に入らないのです。Kinesis Contouredの良い点は単にキー配置を2箇所に広げただけでなく、十分に動くにも関わらず、普通のキーボードではスペースキーとAlt/Option、Command/Winキー程度にしか使われていない親指を有効に使えるよう、多くのキーを親指周りに配置しているところにもあります。

Kinesis Contouredのキー配列でセパレート式になったものが無いだろうか。ここ1年はとくにそのようなことを思っていたわけですが、ここで友人が動き始めたわけです。日本一握力のある男、そう超オス、 @hiroki_niinuma がμTRONキーボードを改造して親指に機能を多めに割り当てて使い始めたとのこと。快適であることを日々報告されると、ますますセパレート型キーボードが欲しくなる。しかしμTRONはキー配列が好みでない。

そんな折、ふとしたことでErgoDoxと出会ったのです。そう、あの対談です。

実は、このときこの場に同席していたんです。 f:id:ymotongpoo:20160129193318j:plain

ここで @nippondanji さんがErgoDoxについて紹介してくださって、実機を見せてくださいました。キー配列はKinesisと同じで、メカニカルキーボードであることも同じ、そして重要なセパレート型。すぐにErgoDoxに移行することを決意しました。問題はErgoDoxはオープンソースなキーボードであり、自力で作ることを想定していること。基盤を焼いたり、筐体を作ったり、キーをすべてハンダ付けしたり、などなど全部やらなければいけない。しかし、 @nippondanji さんがブログに書いていたように、すでにErgoDoxエコシステムと呼べそうなものができつつあり、パーツ代と手間賃を払えば完成品を送ってくるサービスがあるとのこと。いろいろ探して、自分も一台注文。

そして1月末に注文してから2ヶ月弱、ようやく今日届きました。

f:id:ymotongpoo:20160325174851j:plain

こういう感じで傾きをつけることもできるので、とても楽です。

f:id:ymotongpoo:20160325195803j:plain

使い始めてみると、本当に姿勢に余裕ができて、胸が大きく広がるため、堅苦しさを感じることがありません。また呼吸も深くでき常にリラックスできます。自分はエンジニア以前に人間としてなるべく元気でいたいと思っているので、日々のパソコン作業で極力体に負担がかからにようにするというのもひとつの重要な要素だと考えています。なので、いまこうやってErgoDoxを使って文章を書いていると本当にいい買い物をしたと思います。

ErgoDoxの買い方、あるいは組み立て方は他のサイトに譲るとして、もっと多くの人が楽な姿勢で仕事ができるようになればいいなと思います。

とりあえず現状のキーマップを晒しておきますね。

Ergodox Configurator - Massdrop

f:id:ymotongpoo:20160325213155p:plain

国産のキーボードメーカーへのお願い

日本には品質の高いキーボードを作っているメーカーが多いので、ぜひエルゴノミクスキーボードにも力を入れて欲しい。特にErgoDoxはオープンソースライセンスで基盤や基本的な筐体の設計図をすべて公開しているので、それこそPFUや東プレが誇る静電容量無接点方式のErgoDoxキーボードが出たらまず買います!

エンジニアが長いキャリアを積めるようになれば、キーボードメーカーの皆様におかれましても市場が拡大されると思いますので、ぜひご検討ください。

あわせて読みたい

AMP対応 2016.02版

AMP

はじめに

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

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に詳しく解説されている。