Webinar

Web関連情報のウェブセミナー

Webデザイン&レイアウトの最新常識 レビュー

html5 レビュー

面白法人カヤックが監修し、カヤックのデザイナー陣が中心になって執筆しているWebデザインに関する最新（2014年9月21日初版発行）の解説書です。

 

チャプターは大きく4つに分かれています。

  1. レイアウト & 配色
  2. UX & UI
  3. グラフィック & タイポグラフィ
  4. エフェクト & リッチメディア

 

本書を読んですぐにWebデザインに関する良書であるということはわかりました。

もう少し具体的に、本書を読んで感じた点について記しておきたいと思います。 

 

本として見やすい・わかりやすい。

まず解説本として見やすいです。わかりやすいです。

豪華デザイナー陣の執筆した本なので当たり前なのですが、どのページを開いても文章と図や写真のバランスや配置が良く、それらを見るだけでもワクワクします。

文章中のポイントとなる部分に蛍光ペンで線を引いている演出もニクイです。

 

説明と事例のワンセット

ある事項に関する説明を文章でした後には、ほぼ必ずその説明内容を表す事例として様々なサイトのデザイン事例が載っています。文章だけではわかりづらいものをわかりやすくイメージさせてくれます。また、文章と紐づく図を番号で双方に表示してくれている工夫もあり、文章と図をたどりやすいです。

 

ツール類・参考サイトの紹介

様々なデザインを紹介し、それらを開発するための最新のツール類や参考サイトの紹介も各チャプターでしてくれています。本に載っているデザインを実際に自サイトに取り入れるとなった場合でも、ハードル低く取り組むことができます。

 

本解説書によって、Webデザインの最新常識は一通り網羅されています。

Web開発者にはもちろん、Web開発には関係のない、この分野に関する概要の知識を得たい人にとっても必要十分な情報が整理されている良書と言えます。おすすめです。

 

WebのTLS通信における暗号化される範囲と暗号化されない範囲

TLS http/2

NSA（アメリカ国家安全保障局）による大規模ネットワーク傍受の暴露に端を発した通信暗号化の流れですが、HTTP/2でのChrome/Firefoxによる「httpスキームのサポート対象外の表明」を見ても分かるように、世界はその歩みを着々と進めています。

あまり遠くない将来、すべての通信は暗号化されているのが当たり前の世界になっていることは想像に難くありません。

本記事では、Webの暗号化においてもっとも普及しているプロトコルであるTLSについてその暗号化範囲とそこから見えることについて紹介します。

 

TLSの暗号化範囲

では早速TLSの暗号化範囲です。httpsで始まるURLのWebページにアクセスすると、TLSを用いた暗号化がされてWebサーバにパケットが向かっていきますが、そのパケットには以下のような情報が含まれています（これが全てではありません、また通信の途中にミドルボックスなどを経由すると変化する情報もあります）。

  1. 宛先（Webサーバ）IPアドレス/ポート番号
  2. 自端末のIPアドレス/ポート番号
  3. 宛先のURL
  4. 宛先に向けたHTTPリクエスト

そして、上のパケットへの返答としてのパケットには以下のような情報が含まれています。

  1. Webサーバ/自端末のIPアドレス/ポート番号（＝上記1、2）
  2. HTTPレスポンス
  3. Webコンテンツ

このうち、TLSで暗号化されるのは3、4、6、7のみです。

Webサーバと自端末のIPアドレス/ポート番号は暗号化されません。

下図の上半分がそれを表しています。

http://itpro.nikkeibp.co.jp/article/COLUMN/20080609/307119/zu07.jpg

出展：

セキュリティ基準「PCI DSS」 - 伝送データを暗号化しなければならない：ITpro

 

TLSの暗号化範囲を踏まえて言えること

つまり、宛先のWebサーバのIPアドレスは暗号化されず、傍受された場合には盗まれる可能性があるということです。DNSなどでIPアドレスからURLを逆引きするとURLもわかってしまうかも知れません。もちろんポート番号もわかってしまうので宛先がWebサーバであることもわかってしまいます。

あなたが受け取っているコンテンツ内容はTLSによって暗号化されているため、どんなコンテンツを見ているかが盗まれることはありませんが、「どこに」アクセスしているのかは盗まれているかもしれません。

特に、街なかにある、暗号化されていないWi-Fiアクセスポイントに接続して通信するようなときには、何が暗号化されていて何が暗号化されていないか、をなるべく意識して使った方がよさそうです。

 

LINEのクリエイターズスタンプの販売までの流れ

環境構築 ビジネス

LINEクリエイターズスタンプ

大人気チャットアプリLINEにはスタンプ機能があり、スタンプコンテンツは無料だったり有料だったりしますが、LINEを使ったことがある人であれば、1度はスタンプを送ったことがあるでしょう。

 

そのスタンプ、誰が作っているかと言うと、LINE本体や企業が作成/販売しているものが大部分を占めていますが、そのほかにも、個人で作成したスタンプをLINEアプリに登録して販売する（有料での販売のみで無料版は無い）ことができる仕組みが用意されています。それがLINEクリエイターズスタンプです。

 

本記事ではLINEクリエイターズスタンプを作成して、LINEによる審査を経て販売開始するまでのおおまかな流れを紹介したいと思います。

本記事を参考に、ぜひとも皆さんも自分の作ったスタンプを販売しておこづかいを稼いだり、LINE内で自分のスタンプを使ったりしてみてください。

 

一連の流れはすべてこちらのサイトから行うことになります。

creator.line.me

 

  1. クリエイターとしての登録
    各種のクリエイターとしての情報を登録してください。無料です。

  2. スタンプの作成

    ガイドライン - LINE Creators Market

    作る画像は全部で42個です。大変です。がんばりましょう。作成する画像の規定はガイドラインを確認してください。
    いきなり作り始めるのではなく、まずは42個のスタンプで表す内容の概要をテキストレベルで考えてからのほうが良いと思います。

  3. LINEによる審査

    審査ガイドライン - LINE Creators Market

    サイト上からLINEに審査をお願いすることになりますが、この審査、なかなか厳しいことで知られています。が、審査基準は公開されていますのでスタンプを作る前にきちんと目を通しておいてください。
    また、審査期間も結構かかります。申請の量やLINE側の体制にもよりますので最新でどのくらいの期間がかかるかは何とも言えませんが、私の場合は2ヶ月くらいかかりました。

  4. 販売開始
    審査が通ったら、あとはサイト上の販売開始のボタンを押すだけです。

 

以上がざっとした流れになります。私が作ったスタンプは今でも販売中ですが、家族以外の誰かに買ってもらったことが分かったときの感動はひとしおです。ぜひ皆さんもこの感動を味わいつつお小遣い稼ぎに励んでみてください。

（私のスタンプはお小遣い稼ぎにもなっていませんが。。。）

 

WebRTCを使ったライブ配信デモサイトを作ってみました（2/2） 受信者編

WebRTC 環境構築

f:id:t-webber:20150315000105p:plain

本記事は、「WebRTCを使ったライブ配信デモサイトを作ってみました」の後編です。

前編はこちら。

WebRTCを使ったライブ配信デモサイトを作ってみました（1/2） 配信者編 - Webinar

 

ライブ配信デモサイト　受信者編

では今回は受信者編のサンプルサイトです。

今回も結構長いコードなので先に構築のポイントです。構築のポイントとしては配信者と同じですね。配信者編と合わせて、ぜひ自分のサイトで構築してみてください。

  • x.x.x.xは自分のWebサーバのIPアドレスと読み替えてください。
  • API名のブラウザ差分を吸収するためにadapter.jsを自サーバに配置。
  • シグナリングはsocket.io（Websocket）経由で実施するので、socket.io環境も構築する。
  • stunサーバはGoogleのもの（stun.l.google.com）を使った。

 

続きを読む

WebRTCを使ったライブ配信デモサイトを作ってみました（1/2） 配信者編

WebRTC 環境構築

f:id:t-webber:20150315000105p:plain

本記事は、「WebRTCを使ったライブ配信デモサイトを作ってみました」の前編です。

後編はこちら。

WebRTCを使ったライブ配信デモサイトを作ってみました（2/2） 受信者編 - Webinar

 

WebRTC

WebRTCとは、広義のHTML5に含まれる通信系のAPIで、Flashのようなプラグイン不要でブラウザ間のビデオチャットや音声通話を実現する仕組みです。

Web Real-Time-Communicationの略で、W3Cで標準化が進められています。

もう少し技術寄りの言葉で端的にポイントを説明すると、

ブラウザが、「P2P」で「UDP通信」をできるようになる。

というのが説明になります。

音声やビデオのようなメディアだけでなく、バイナリデータを送信するAPIも規定されているため、P2Pでファイルを送り合うようなこともできます。

WebRTCを使ったP2Pファイル共有ソフトやCDNを作っているベンチャーなんかもあったりします。

 

本記事では、このWebRTCを使った片方向ライブ配信のデモサイトの作成方法を紹介します。

 

ライブ配信デモサイト　配信者編

このデモサイト、ライブ配信という名のとおり、片方向に映像＋音声を配信するものです。まずは配信者がとあるサイトに接続、配信を開始します。そしてそのサイトに受信者が接続し、受信開始ボタンを押すと配信者の映像が見られるというものです。

デモレベルの簡易なものですので、ログインや認証などの処理は無く、サイトに接続して受信開始ボタンを押せば見られてしまいます。

 

参考サイト、というかコードをほぼそのまま活用させていただいたのが以下。

連載 | WebRTCを使ってみよう！ | HTML5Experts.jp

がねこさんのHTML5Experts.jpの記事です。

ちなみに私はAWS上にこのサイトを構築してみました。インスタンスを作成し、OSを選び、Apacheをインストール/起動し、HTMLファイルを置くだけです。

 

今回はまずは配信者編ということで配信者側のHTMLファイルサンプルです。

ちょっと長いので、先にデモ構築のポイントを挙げます。皆さんぜひ自分のサイトに配置して使ってみてください。

  • x.x.x.xは自分のWebサーバのIPアドレスと読み替えてください。
  • API名のブラウザ差分を吸収するためにadapter.jsを自サーバに配置。
  • シグナリングはsocket.io経由（Websocket）で実施するので、socket.io環境も構築する。
  • stunサーバはGoogleのもの（stun.l.google.com）を使った。

 

続きを読む

Webプリレンダリング（prerender）によるWebアクセスの高速化効果

html5

WebアクセスにおけるUX向上施策

Webアクセスするにあたって、Webページにアクセスしてから表示完了するまでの速度が速いほうがいいのは言うまでもありません。

（厳密に言うとどの時点を表示完了とするのか？など、考えなければならないことはもう少しありますがここではもう少し表面的なハナシとして）

 

その速度を向上するための施策にはいろいろとあります。その全ては紹介しきれないので、本記事ではHTMLのタグ内で実施できる施策をいくつか紹介し、その内の1つの方法で実際にどのくらいの効果が出るのかを紹介したいと思います。

 

linkタグにおけるUX向上

HTMLのlinkタグには、Webアクセス時のUXを向上できる仕様が規定されています。

下記の3つです。

  • prerender：
    指定したWebサイトをバックグラウンドで事前に取得（キャッシュ）します。
  • prefetch：
    指定したWebサイトの指定したリソース（画像、cssやJavaScriptなど）をバックグラウンドで事前にキャッシュします。
  • dns-prefetch：
    指定したWebサイトのURLをバックグラウンドで事前にDNSアクセスでアドレス解決しておきます。

 書式はそれぞれ以下の通り。

 

検証方法

今回は、上記のうちのprerenderを使ったときの効果の検証を実施しましたので、その結果を紹介します。

 

検証の条件は以下。

  • AWS上に、90個の画像が配置されている（ファイルの多い）Webサイトを構築
  • 一つのトップページからプリレンダーあり/なしのそれぞれのページに遷移
  • リンクボタンクリックから全ての画像が表示されるまでの時間をNavigation timing APIを使ってms単位で取得

 

検証結果

上記を、3G / LTE / Wi-Fi(ADSL)の3種類のアクセスラインでそれぞれ20回ずつ計測し、平均値を取ってみました。（プリレンダー有無×3アクセスラインで6種類の平均値が出てきます）

単位はms（ミリセック：1/1000秒）です。

3G

LTE

Wi-Fi(ADSL)
prerender
あり		prerender
なし		prerender
あり		prerender
なし		prerender
あり		prerender
なし
374 8431 353 1984 300 3457

いずれの場合も、prerenderありの場合はキャッシュに入っているコンテンツを読み出すだけなので350ms前後となっています。体感的にもパッと表示され、相当早いです。

対して、prerenderなしの場合は、各アクセスラインの帯域スペックに概ね比例した感じの時間がかかっていて、prerenderありの場合の5～20倍ほどの時間がかかっています。画像がパラパラと表示されていくのが見ててわかります。

 

まとめ

WebアクセスのUXを向上する施策としてHTMLタグ内への記載で対応できる方法を紹介し、その効果を検証してみたところ、明らかの効果を確認することができました。

ただ、この効果の代償としてネットワークへ負荷を高めてしまうという課題があります。また、モバイルを前提にすると、パケット利用量が増えてしまうというのも課題です。

長い記事で記事が数ページに分かれているようなケースでは次のページに行くのはほぼ確実であると見込めるので、prerenderを仕掛けておくというのはありだと思いますが、UXとネットワーク負荷/パケット利用量増のバランスを考えて使う必要があります。

 

HTTP/2とは?を勉強し始めるのに役立つまとめリンク

http/2

f:id:t-webber:20150311222200p:plain

本記事では、HTTP/2を勉強し始めるときにとても役に立つコンテンツをリンク集の形でまとめてみました。

RFC化を目前に控え(2015/3/11時点で)、これからこの技術に関わる人も爆発的に増えてくると想定されるので、その人たちの学習スピードを上げ、すそ野を広げていきたいという思いもあります。

 

まずは基本のWikipedia

HTTP/2 - Wikipedia

何はともあれWikipedia。まだまだ充実しているとは言えない内容ですが、やはり概要の概要をつかむのにはここから。

 

SlideShare

SlideShareにアクセスし、「http/2」で検索してください。

中身のわかりやすさも重要ですが、今の時点で気にするべきは情報の鮮度です。

絶対に日付のある資料を見て、どの時点の情報なのかを意識して読んでください。

2015/3/11時点でのオススメはこの資料。

HTTP/2の現状とこれから

IIJ大津さんの資料です。情報の鮮度としても問題なく、概要把握を目的とした場合の内容としても、過不足なくちょうど良い感じです。

 

HTTP2 Advent Calendar 2014

2015/3/11時点で最新のAdvent Calendarです。今をときめくHTTP/2界隈の重鎮の方々が様々な観点からの記事を投稿したものがまとまっています。実はリンク集としてはこれだけでも十分というハナシも。。

HTTP2 Advent Calendar 2014 - Qiita

 

RFC

概要把握したいと言いつつ、1次ソースを確認することは概要把握のためにも重要です。

ということでRFC原文です。2015/3/11時点でDraft17(版数のこと)ですね。

draft-ietf-httpbis-http2-17 - Hypertext Transfer Protocol version 2

また、有志の方で日本語訳もされており、英語苦手な方はこちらをご確認ください。

こちらはDraft16です。

Hypertext Transfer Protocol version 2 (draft-ietf-httpbis-http2-16) 日本語訳

 

その他

 

 

  • 関連の仕様について
    ちょっと細かくなりますが、概要レベルから少し突っ込んだ仕様などの情報も見てみてください。SlideShareなどでHTTP/2と組合わせて下記のワードを検索いただくのが良いと思います。こちらも情報の鮮度には気をつけてください。
    HPACK、Alt-Svc、priority、PUSH
    結構Advent Calendarでカバーされていますね。

 

以上、HTTP/2の概要把握のための情報まとめでした。

HTTP/2への入り口として皆様に活用していただきたく、読んでくださいました方は別の人への紹介もぜひともお願いします。