#がみぶろ

@jumpei_ikegami

サイ本こと『JavaScript 第6版』全800ページを読破し、1万行のesaにまとめてわかった5つのこと

しがないラジオのgamiです。

JavaScript界隈では有名な、オライリーのサイ本こと『JavaScript 第6版』という鈍器、もとい書籍を読みました。

JavaScript 第6版

JavaScript 第6版

2012年に発行された、約800ページもある、かなり内容の多い本です。 僕は本を読むときにesaに要約しながら読み進めるのですが、サイ本のまとめesaは全体で「約1万行」という修行みたいな分量になっていました。

サイ本を要約しながらじっくりJavaScriptを学んだ人はこの世界にあまりいないと思うので、わかったことをまとめます。

読み始めたきっかけ

僕は約2年前に、富士通から、今働いているプレイドという会社に転職しました。 富士通ではCOBOL(!)とJavaしか書いていなかったので、Node.js+Vue.jsの会社に転職するための準備として、『JavaScript 第6版』を買った記憶があります。

今思えば、もっと軽い入門書もあったと思います。中二病だったのでしょう。

JavaScript 第6版』を読んでわかった5つのこと

サイ本を読んで、JavaScriptプログラミング言語としての立ち位置や面白さがわかりました。

JavaScriptを学ぶ」ことの多くは、「ブラウザの仕様を学ぶ」こと

サイ本は、大きく「コアJavaScript」と「クライアントサイドJavaScript」の2部に分かれています。「コアJavaScript」では、主にJavaScriptの文法について説明しています。型、演算子、文、関数、正規表現など、他のプログラミング言語の入門書でも必ず説明されるような内容です。

特徴的なのは、「コアJavaScript」よりも「クライアントサイドJavaScript」の方により多くの紙幅を割いている点です。他のプログラミング言語の入門書であれば、簡単にライブラリを紹介する章はあっても、言語自体の文法に関する説明よりも短く掲載される場合がほとんどでしょう。JavaScriptの場合は、「Webブラウザ」という切っても切り離せない巨大アプリケーション群があり、ほとんどの場合はその実行環境を前提として記述されます。そのため、「JavaScriptを学ぶ」ということの多くは、「ブラウザの仕様」や「DOMを含むWeb API群の標準仕様」を学ぶということなのだなあ、ということをサイ本を読んで実感しました。

例えば、ただJavaScriptで計算をしたいだけなら、別にWebページのHTMLをどのように操作できるかなど知らなくても何も困りません。ただし、JavaScriptを書きたい、学びたい、というモチベーションの多くは、Webのクライアントサイドに関わる以下のようなことです。

  • 動的にHTMLやCSSを変化させたい(DOMやCSSOMの制御)
  • ユーザーの操作に応じて処理を変えたい(イベント処理)
  • 外部サーバーと非同期で通信したい(Ajax
  • ブラウザ側にデータを保持して、IDやセッションを管理したい(Cookie、localStorage)

逆にクライアントサイドJavaScriptは、それを学ぶ過程で、HTMLやCSSの仕様に依存したAPIを学ぶことになります。なので、Webのクライアントサイドの技術について深く学びたい場合は、JavaScriptの学習をすることで、HTMLやCSSも含めたブラウザの仕様について深く理解できるようになると思います。

ちなみに、2007年に発行された一つ前の版である『JavaScript 第5版』の目次を『JavaScript 第6版』のものと比べると、ブラウザの機能の変遷がわかって非常に面白いです。

www.oreilly.co.jp

www.oreilly.co.jp

2007年の第5版では「Javaアプレット」、「Flash」、「XML」などの章がありますが、2012年の第6版ではそれらがすべて削除され、代わりに後述する「jQuery」や「HTML5 API」の章が追加されています。

クライアントサイドJavaScriptの爆発的変化

JavaScript 第6版』が出版されたのは、2012年の8月です。今が2018年の7月なので、たった6年前になります。ただし、この本に書かれている内容ですら、すでに一部の仕様が廃止されていました。

例えば、windowオブジェクトのメソッドとして本書で紹介されているshowModalDialog()は、MDNで調べると「この機能は削除されました。ウェブサイトやアプリケーションを修正してください。」と書かれています。

「ブラウザは後方互換性を大事にするので機能を削除できない」とよく耳にしますが、仕様の議論が不十分なままブラウザに実装された過去の機能については、廃止されているものもあるようです。

サイ本を読むとき、あまり聞いたことのない機能については、実際にブラウザのコンソールで本当に使えるのか試したり、MDNに記載があるかを調べたりしていました。少し古めのJavaScript本を読むときは、機能が廃止されている可能性を考慮しながら読んだ方が良さそうです。

なお、JavaScriptはES2015で以下のような新しいシンタックスがかなり追加されましたが、サイ本にはそれに関する以下のような記載はありません。

  • letconstによる変数宣言
  • アロー関数
  • class構文
  • 分割代入
  • importとexport

さらに、現代のクライアントサイドJavaScriptとは切っても切り離せない以下のような技術スタックには特に触れられていません。

フロントエンドの開発に求められるものの多様化とWeb技術の変化の速さを揶揄して「フロントエンド地獄」と呼ばれますが、サイ本もまた(少なくとも第6版の時点では)その地獄に囚われ古臭い本になりつつありました。

そのためサイ本は、「最新のJavaScript」ではなく、「時代を経ても変わらないJavaScriptのエッセンスや、すでに安定したWeb API」について学ぶための本として読んだ方がよいです。

「最新のJavaScript」については、出版されるかわからない『JavaScript 第7版』に期待しましょう。

ブラウザ間の差異から来る闇

JavaScriptという言語の特殊性として、その実装はブラウザベンダーに委ねられており、独自の方言が認められている点があります。もちろん、Webページを実装する開発者としては、1つのJavaScriptファイルが複数のブラウザで意図通りに動作することを期待します。ただし、歴史的経緯から来るブラウザ間の仕様の差異によって、その期待はしばしば裏切られてきたことが、サイ本を読むとわかります。

特に、Web標準の策定プロセスが今ほど洗練されていなかった時代に実装された機能については、多くの闇を生み出しているようです。例えば、window.onerrorというエラー時に呼び出される関数内では、エラー処理完了時に通常はfalseを返します。ただし、歴史的経緯から、Firefoxだけはtrueを返さなければいけないそうです。

このような問題に対処するには、本来の処理に加えて、どのブラウザで実行されているのかをチェックする「ブラウザテスト」を実施しなければいけません。 (なお現在では、window.onerrortry-catchによって代替され、ほとんど使われていません。)

特にブラウザ互換性についての話題で言及されやすいInternet ExplorerIE)については、本書でも「非互換性の多くは、IEに関連したものです」と、名指しで批判されています。

古いIEでは、Web標準として勧告されたメソッドを実装せず、同様の機能を持った別名のメソッドを使っていたりします。 例えば、IE8以前ではイベントハンドラを登録するaddEventListener()が実装されていなかったため、代わりにattatchEvent()というメソッドを使う必要があったそうです。

if (window.addEventListener)
    window.addEventListener("load", f, false);
else if (window.attachEvent) // IE8以前
    window.attachEvent("onload", f);

IEが天下を取っていた時代は、大半のWebページはIEで動けば問題なかったのでしょう。そんなIEに対抗するブラウザが登場し、健全な競争や議論の中でWebの標準化が進んだことは、非常に喜ばしいことだと思います。

また、Web標準の策定プロセスが整備されたことに加えて、Microsoft Edgeの登場、ブラウザ間の差異を埋めるPolyfillなどのライブラリの存在によって、ブラウザ間の差異を前ほど意識せずにJavaScriptを書くことができる環境になりつつあります。

かつてのjQueryがもたらした価値

サイ本では、第19章の約70ページ全てを、丸々jQueryの紹介に割いています。JavaScriptの1ライブラリとしては、破格の待遇です。

2012年当時、jQueryJavaScriptライブラリとしてデファクトスタンダードであったことがわかります。

今でこそ目の敵にされているjQueryですが、当時これほど流行った理由がサイ本を読んでいてわかりました。

前述のように、当時のフロントエンドの開発者はブラウザ間の差異から来る闇に苦しんでいました。生のJavaScriptではなくjQueryを使うことで、ブラウザ間の差異を吸収してくれ、どのブラウザでも同じように動作するJavaScriptを生成することができました。

また、JavaScriptやブラウザ自体の機能がまだ脆弱だった頃、jQueryは強力なAPIをどんどん追加していき、JavaScriptができることを広げていったようです。

jQueryAPIを覚えるだけで、ブラウザ互換性に配慮した動的なWebページを開発することができるとなれば、これほど使われるようになるのも必然でしょう。

ただし、現在では前述のようにブラウザ間の差異を前ほど意識せずにフロントエンド開発ができる環境が訪れつつあり、jQueryが果たした本質的な役割の意義が薄れつつあります。

また、jQueryのようなDOMへの要素挿入を中心としたアプローチではなく、宣言的なViewの管理によって要件を実現するVue.jsなどのJavaScriptフレームワークが、保守性などの観点から流行しています。一般にVue.jsなどが管理しているDOMを後からjQueryで書き換えるとアプリケーションがぶっ壊れるので、脱jQueryを進めるWebページやWebアプリケーションが増えている印象です。

もしも『JavaScript 第7版』が出版されたら、きっと『第19章 jQueryライブラリ』は無くなっているでしょう。

ブラウザにはワクワクする機能がたくさん追加されている!

サイ本の最終章である『22章 HTML5 API』では、以下のように当時では比較的新しかったAPIの仕様に関して言及されています。

  • 履歴管理
  • クロスオリジンメッセージング
  • Web Workers
  • Geolocation
  • IndexedDB

この本では「未来のAPI」のように語られているこれらのAPIですが、例えば「履歴管理」はSPAで戻るボタンを押せば当たり前のように機能しますし、Web Workersの1つであるService WorkersもついにiOS Safariで対応され、主要ブラウザ全てでPWAのキャッシュやプッシュ通知に使われ始めています。

ブラウザの仕様が目まぐるしく変わることで、そのキャッチアップが大変であったり、多くの負債が生まれたことは、前述の通りです。しかし、逆に新しい仕様が次々と登場することで、ブラウザで実現可能な範囲は毎年広がっています。例えば、「ブラウザ経由で位置情報を特定してその場所に応じたコンテンツを出す」みたいなことも、ブラウザの標準機能で実現できるようになっています。

また、この本に書かれた後に登場してきた新しい仕様によって、以下のような世界が当たり前になっていくかもしれません。

  • WebAssemblyで、C言語で書かれた世界中の資産がブラウザ上から使える
  • Payment Request APIで、ブラウザに登録しておいた支払方法や配送先を選ぶだけでブラウザ経由で決済できる
  • Web Publicationsで、HTMLで書かれた文書をそのまま電子書籍として閲覧、出版できる

JavaScriptを取り巻くエコシステムについて学び続けていると、そんなワクワクする話題がたくさん登場して、とても楽しい毎日を送れます。

この本について

ここまでサイ本を比較的ボジティブに解説してきましたが、正直に言って、JavaScriptを勉強したい多くの人には、この本はあまりおすすめではありません。『JavaScript 第6版』自体がかなり古くなっていて、最新のJavaScript事情を反映できてないからです。また、リファレンス的に利用するならまだしも、全章を読破するには、JavaScriptを記述する上では不要な内容が多い印象があります。

僕もJavaScriptを学び始めた当初は、サイ本より先に、『開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質』という本を読みました。

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

こちらの本の方が、JavaScriptのハマりポイントである以下のような点について、たくさんの例を交えて簡潔に記述されています。

  • プリミティブ型とオブジェクト
  • this
  • スコープとクロージャ
  • プロトタイプ継承

JavaScript初心者が中級者に上がるための本としては、こちらの『開眼! JavaScript』の方をおすすめします。

また、リファレンス的に利用するにしても、MDN Web DocsJavaScriptの最新仕様やブラウザ互換性についてよくまとまっているので、そちらの方が使い勝手としては良いでしょう。

「サイ本がこれだけ分厚いなら、JavaScriptのより低レイヤな領域についても記載があるだろう」と思う人もいるかもしれないですが、特にメモリ管理の話とかも出てこないです。

なので、仮に『JavaScript 第6版』を勧めるとしたら、「ある時点でのJavaScriptの仕様を、その歴史も交えて体系的に知りたい」人に対してのみになるかと思います。もしそのような奇特な人がいたら、ぜひ挑戦してみてください。

最後に、改めてサイ本こと『JavaScript 第6版』の目次を掲載します。

第I部 コアJavaScript

  • 2章 字句構造

  • 3章 型、値、変数

    • 3.1 数値
    • 3.2 テキスト
    • 3.3 論理値
    • 3.4 nullとundefined
    • 3.5 グローバルオブジェクト
    • 3.6 ラッパーオブジェクト
    • 3.7 不変な基本型値と可変なオブジェクト参照
    • 3.8 型の変換
    • 3.9 変数の宣言
    • 3.10 変数のスコープ
  • 4章 式と演算子

    • 4.1 単項式
    • 4.2 オブジェクトと配列の初期化子
    • 4.3 関数定義式
    • 4.4 プロパティアクセス式
    • 4.5 呼び出し式
    • 4.6 オブジェクト生成式
    • 4.7 演算子の概要
    • 4.8 算術演算子
    • 4.9 関係演算子
    • 4.10 論理演算子
    • 4.11 代入演算子
    • 4.12 評価式
    • 4.13 そのほかの演算子
  • 5章 文

    • 5.1 式文
    • 5.2 複合文と空文
    • 5.3 宣言文
    • 5.4 条件文
    • 5.5 ループ文
    • 5.6 ジャンプ文
    • 5.7 そのほかの文
    • 5.8 JavaScript文のまとめ
  • 6章 オブジェクト

    • 6.1 オブジェクトの生成
    • 6.2 プロパティの読み出しと書き込み
    • 6.3 プロパティの削除
    • 6.4 プロパティのテスト
    • 6.5 オブジェクトプロパティの調査
    • 6.6 プロパティのゲッターメソッドとセッターメソッド
    • 6.7 プロパティ属性
    • 6.8 オブジェクト属性
    • 6.9 オブジェクトのシリアライズ
    • 6.10 オブジェクトのメソッド
  • 7章 配列

    • 7.1 配列の生成
    • 7.2 配列の要素の読み書き
    • 7.3 疎な配列
    • 7.4 配列の長さ
    • 7.5 配列の要素の追加と削除
    • 7.6 配列の要素の巡回
    • 7.7 多次元配列
    • 7.8 配列のメソッド
    • 7.9 ECMAScript 5の配列メソッド
    • 7.10 配列の種類
    • 7.11 配列のようなオブジェクト
    • 7.12 配列としての文字列
  • 8章 関数

  • 9章 クラスとモジュール

    • 9.1 クラスとプロトタイプ
    • 9.2 クラスとコンストラクタ
    • 9.3 JavaScriptでのJavaスタイルのクラス
    • 9.4 クラスの拡張
    • 9.5 クラスと型
    • 9.6 JavaScriptでのオブジェクト指向的な技術
    • 9.7 サブクラス
    • 9.8 ECMAScript 5のクラス
    • 9.9 モジュール
  • 10章 正規表現パターンマッチング

    • 10.1 正規表現の定義
    • 10.2 パターンマッチング用の文字列メソッド
    • 10.3 RegExpオブジェクト
  • 11章 JavaScriptのサブセットと拡張

    • 11.1 JavaScriptのサブセット
    • 11.2 定数とスコープ付きの変数
    • 11.3 分割代入
    • 11.4 反復機構
    • 11.5 簡易表記関数
    • 11.6 複数のcatch節
    • 11.7 E4XECMAScript for XML
  • 12章 サーバサイドJavaScript

第II部 クライアントサイドJavaScript

  • 13章 Webブラウザに組み込まれたJavaScript

    • 13.1 クライアントサイドJavaScript
    • 13.2 HTMLドキュメントへのJavaScriptコードの埋め込み
    • 13.3 JavaScriptプログラムの実行方法
    • 13.4 互換性と相互運用性
    • 13.5 アクセサビリティ
    • 13.6 セキュリティ
    • 13.7 クライアントサイドフレームワーク
  • 14章 Windowオブジェクト

    • 14.1 タイマー
    • 14.2 ブラウザのLocationオブジェクトと移動
    • 14.3 閲覧の履歴
    • 14.4 ブラウザと画面情報
    • 14.5 ダイアログボックス
    • 14.6 エラー処理
    • 14.7 Windowプロパティとしてのドキュメント要素
    • 14.8 複数のウィンドウとフレーム
  • 15章 ドキュメントの制御

    • 15.1 DOMの概要
    • 15.2 ドキュメント要素の選択
    • 15.3 ドキュメント構造と探索
    • 15.4 属性
    • 15.5 要素のコンテンツ
    • 15.6 ノードの作成、挿入、削除
    • 15.7 例:目次の作成
    • 15.8 ドキュメントと要素位置とスクロール
    • 15.9 HTMLフォーム
    • 15.10 ドキュメントのそのほかの機能
  • 16章 CSSの制御

    • 16.1 CSSの概要
    • 16.2 重要なCSSプロパティ
    • 16.3 インラインスタイルの制御
    • 16.4 算出スタイルの取得
    • 16.5 CSSクラスの制御
    • 16.6 スタイルシートの制御
  • 17章 イベント処理

    • 17.1 イベントタイプ
    • 17.2 イベントハンドラの登録
    • 17.3 イベントハンドラ呼び出し
    • 17.4 ドキュメントのloadイベント
    • 17.5 マウスイベント
    • 17.6 マウスホイールイベント
    • 17.7 ドラッグ&ドロップイベント
    • 17.8 テキストイベント
    • 17.9 キーボードイベント
  • 18章 HTTPの制御

    • 18.1 XMLHttpRequestの利用方法
    • 18.2 <script>によるHTTP制御:JSONP
    • 18.3 Server-Sent Eventsを使ったComet
  • 19章 jQueryライブラリ

    • 19.1 jQueryの基本
    • 19.2 jQueryのゲッターとセッター
    • 19.3 ドキュメント構造の変更
    • 19.4 jQueryでのイベント処理
    • 19.5 アニメーション効果
    • 19.6 jQueryによるAjax
    • 19.7 ユーティリティ関数
    • 19.8 jQueryセレクタと選択メソッド
    • 19.9 プラグインによるjQueryの拡張
    • 19.10 jQuery UIライブラリ
  • 20章 クライアントサイドストレージ

    • 20.1 localStorageとsessionStorage
    • 20.2 クッキー
    • 20.3 IEのuserData永続化機構
    • 20.4 アプリケーションストレージとオフラインWebアプリケーション
  • 21章 メディアとグラフィックの制御

  • 22章 HTML5 API

    • 22.1 Geolocation
    • 22.2 履歴管理
    • 22.3 クロスオリジンメッセージング
    • 22.4 Web Workers
    • 22.5 型付き配列とArrayBuffer
    • 22.6 Blob
    • 22.7 Filesystem API
    • 22.8 クライアントサイドデータベース
    • 22.9 WebSocket
  • 索引

DevRel Meetup in Tokyo #31 〜初級者向け〜に参加してきました!

f:id:jumpei_ikegami:20180607202756j:plain

しがないラジオのgamiです。

今後のキャリアの選択肢の1つとして、DevRel(開発者向けPR)活動関わることに興味があるので、DevRel Meetup in Tokyo #31に参加しました!

devrel.connpass.com

若干ビジネスイベント感があって、最初に全員のテンション高めの自己紹介から始まるのに戸惑いましたw でも、エンジニア向けの勉強会とは雰囲気が違って面白かったです。

DevRelの基本とマーケティング戦略 by MOONGIFT 中津川篤司

speakerdeck.com

自己紹介

DevRelとは?

  • Developer Relation
  • PR(Public Relation)の開発者版

DevRel活動

  • セールスをするのではない
  • 認知度やマインドシェアを上げることで、土俵にあげてもらう活動

なぜ開発者?

  • 開発者は広告を一切見ない
  • 高ITリテラシー
  • ソーシャル、ブログでの拡散率が高い
    • 三者が公平に書いたブログは、CVRへの寄与度が高い
  • 穴を売るな、ドリルを売れ
    • 体験を売るべき
  • 自社製品の新しい魅力を生み出す

製品採用のステップ

  1. その技術を調べる
  2. 課題解決できる製品を並べる
    • Googleの検索結果に出てくることが重要
  3. 各製品の情報を調べる
  4. 検証する
  5. 購入する

注意点

  • 中長期的な戦略として実施する
    • 外資系の企業は、すぐに方針転換するw
  • すぐに効果は出ないので、続けることが重要
  • KGI/KPIをきちんと定めておく
    • 数字を出せないと、上を説得できない

DevRelのマーケティング戦略

  • SWOT分析をしてみる
    • 強みを生かし、弱みをなくしていく
    • 外部要因の弱みは啓蒙によって世間の目を変える

開発者主体で考えた分析軸

  • 1つ目
  • 2つ目
    • マーケットリーダー
    • チャレンジャー
    • ニッチプレイヤー
    • シューティングスター
      • 金に物を言わせて市場をぶん取ろうとするプレイヤー

ペルソナ決め

  • どんなに便利でも使ってくれない
  • 属性をラベリングしていく

ペルソナを決めると?

  • 本当に必要な機能がわかる

井の中の蛙になる

  • 小さな市場でトップシェアになることが重要
    • そこから、市場を拡大する

AARRR分析

  • DevRel的には、最初にAwarenessを、最後にProductを付ける

フォーカスを決める

  • 新規獲得?Churn Rate?
  • 収益?利用者拡大?
  • 認知度向上?
  • 非アクティブユーザーの活性化?

アクション評価シート

施策判断

  • 2軸の組み合わせで考える
  • マトリクスを作ってみて、施策の幅出しをする

施策の決定

  • ローリスク、ハイリターンの追求をする
    • 効果がすぐに出るものではないので、低予算で長く続ける
  • 基本は、ユーザー単価で判断する
    • PVは水増しできる
    • 「登録したらプレゼント」をしても、変なユーザーしか増えない

DevRelのABCDE

  • A: アドボケイト
  • B: ブログ
  • C: コミュニティ
  • D: ドキュメント
  • E: イベント

ブログ

  • 誰に何を読んで、どうなって欲しいのか?
  • ペルソナの課題解決がベスト

ドキュメント

  • 過不足ない
  • 検索フレンドリー

まとめ

  • 技術より情熱、お金より行動
    • LTをするだけなら、今日からでもできる!

小さく始めろ、評価は期待するな、理解ある上司を探せ、プロダクト愛を持て! by NTTコミュニケーションズ 仲さん

speakerdeck.com

自己紹介

  • @Tukimikage
  • SkyWay Teamのテクニカルソリューションズやサポートエンジニア

テーマ

SkyWayとは?

  • Enterprise Cloud WebRTCプラットフォーム SkyWay
  • 2013〜トライアル
  • 2017〜 正式リリース
  • RareJobなどで使われている

SkyWayのミッション

  • WebRTCを身近な技術に変える
    • 使いこなすためには、幅広い技術領域の知識が必要

SkyWayが提供する価値

  • WebRTCを使ったサービス開発のハードルを下げたい
  • サービス自体の価値向上に集中して欲しい

開発者に価値提供し続けるためには?

  • デベロッパーファーストであり続けることが重要
  • DevRelに力を入れている

実践していること

情報発信

  • FAQやサポートコミュニティの運営
    • 無償の場合、コミュニティで解決してもらう
  • SNSでの情報発信
  • GitHubやQiitaでの情報提供
  • 開発者向け公式イベント
    • 「いいオフィス」を借りて、100名規模で実施

ユーザーグループ立ち上げ

  • コミュニティマネージャーとして、開発者と共にUG立ち上げ
  • 東京、関西、福岡で実施

開発者と開発チームとをつなぐ

  • 開発者から受けたフィードバックをプロダクトに反映する営み
    • BackLogに追加していく
  • サポートコミュニティには開発チームからは書き込みをあまりしない

エヴァンジェリスト活動

  • WebRTCに関する啓蒙活動
  • 業界発展に向けた取り組み
    • WebRTC Conference Japan

NTTコミュニケーションズとは?

  • 従業員数が6,350人
  • ザ・エンタープライズ企業!
  • 単体でうるのではなく、ソリューションとして価値を提供することで、収益を拡大する

DevRel活動の課題

  • すぐに売り上げには結びつかない
    • そもそも、部署の目標と合っていない
    • 社内で評価されにくい
    • 仲間がなかなか増えない
  • 大企業特有の縦割り型環境だとやりづらい

小さく始めた

  • ユニット単位でかなりの裁量が認められていた
  • 数人で企画、開発、PR、運用まで全てやったので、DevRelの重要性も認知された
  • 結果を出したことで、他部署からも評価された

社内での評価は気にしない

  • 事業部では、売り上げに直結しないDevRel活動は評価されづらいので、気にしないw
  • 可能なら、指標化する

プロダクトに愛情を注ぐ

  • まずは自分がファン第一号であるべき
  • 誰よりも中身に詳しくあるべき
    • エンジニア畑出身者がやる方が良い

テクニカルエバンジェリストに求められる5つの基本スキル by 職業「戸倉彩」

www.slideshare.net

自己紹介

  • 職業「戸倉彩」

テクニカルエバンジェリストとは?

  • 誰のために、何をする人か?
    • 開発者向けに、技術を啓蒙し、エンゲージする

職種名いろいろ

企業内での課題

人間的な課題

  • 本名 or ニックネーム
  • 活動時間
  • 活動場所
  • 活動内容
  • 得意/不得意分野

経験者は語る

1. エンジニアであれ

  • 技術を信じ、情熱を注ぐ
  • IT業界のトレンドを理解する
  • 手を動かす

2. 正しい情報を伝える

  • 開発者の言葉
  • タイミングと情報の鮮度
  • 公式見解か個人の意見かを明確に

3. コミュニケーション

  • 開発者文化やスタイル
  • オンラインとオフライン

4. ビジネスセンス

  • 社会性をもつ

5. 人間力

  • IT業界での立ち位置
    • ただ可愛い、かっこいいではなく、「テクニカルに何ができる人なのか?」が重要
  • セルフブランディング

テクニカルエバンジェリスト2.0

  • 開発者向けに、技術を啓蒙し、エンゲージする + 「売り上げに貢献する」
  • DevRelの対象とは?
    • 開発者 + 開発者のお客様 + 次工程

1. 上昇志向のエンジニアであれ

  • フルスタックエンジニア
    • どんな技術にもチャレンジする

2. エンゲージメント

  • 技術と人間と会社との関係

3. コミュニケーション

  • グローバルに活動
    • 日本に限定しない活動をすべき
    • 英語でのアウトプット大事!

4. インパクトの出せるビジネスセンス

  • マネタイズ

5. ITヒーローを育てる

  • 次世代(後継ぎ)を考える

意識している3つのこと

  • 自分を恐れない
    • 自分の限界を決めない
  • 周りを恐れない
    • 周りの評価を気にせず、チャレンジする
  • 時代を恐れない
    • いまの主流と違うことであっても、変えるために啓蒙していく

課外活動で勉強会を主催していたら会社の事業になった話 by のびすけさん

liginc.co.jp

自己紹介

  • 元LIGエンジニア
  • dotstudioを経営
    • ものづくり教育事業

dotstud.io

今回の対象

  • 仕事は仕事で割り切って、業務時間外でやりたいことをやろうと思っている人

LIGについて

liginc.co.jp

Phase1. なんとなく始めたイベントが200人規模になった

  • IoTLTという勉強会を主催
  • きっかけ
    • 「リレーションズのエンジニアを外に出したい」という相談を土屋さんから受けた
    • IoTという言葉がバズりそうだったので、始めてみた
  • 第1回は、社内勉強会として始める
    • リレーションズとLIGの合同社内勉強会
  • 気付いたら、述べ1,000人を超える
  • いまは、述べ15,000人

Phase2. コミュニティ成長の一方で、目的を見失う

  • 当初の目的だった、リレーションズのエンジニアが参加できなくなってきた
  • 成長してきたコミュニティを前にして、どうすればいい?
  • 続けることで価値を見つけた
    • 毎月開催をし続けることで、「すごい楽しかった」「仕事につながった」という声が上がってきた
    • 来てくれる人がいるということは、価値があること
    • エンジニア向けにやっていたが、IoTに興味がある人なら誰でも集まるコミュニティになった

Phase3. 社内に対する承認欲求との戦い

  • 「この活動を会社が後押ししてくれればいいのに」と思うようになった
    • とはいえ、「話題になってるから勝手に会社も気付くだろう」とも思って社内共有しなかった
  • とある経営者の投稿
    • 「影の努力を気づく上司はほとんどいません」
    • 「評価をしてほしいなら、その努力を上司ないしキーマンに全力でみせましょう」
    • 見えているものでしか、評価はできない
    • 社内に対しても、アウトプットが必要
  • 社長を勉強会に呼んだ
    • 「めっちゃいい会だね」と連呼してもらう
  • 海外に行こうか迷ったタイミング
    • 海外転勤できなければ会社を辞めようと思った
    • 社長に止められた
      • 「新しくLIGの中で新規事業を立ち上げないか?」

Phase4. DevRel事業部を立ち上げた

  • 「技術障壁が高い」のはもったいない
  • 特にIoT領域で、プロモーションのお手伝いをしていく

まとめ

  • モチベーションが無くても、続けていれば価値につながる
  • 好きなことを業務に持ってくる、この為に社内へのアウトプットは重要
  • まず動いてみて、後から振り返ることで自分のやりたいことが見つかる

Phase5. おまけ: LIGから独立しました!

  • dotstudioを立ち上げ

LT: システムインテグレーターにおける"R"(序)

自己紹介

SIerにおけるリレーション

  • 既存のお客様との関係をイメージする人が多い
  • 他にももっとあるはず
    • パブリック、メディア、ガバメント、パートナー、デベロッパー...
  • 関係性から始まるRAIDMA

関係性の前に

  • そもそも、認知してもらう必要がある

取り組み

  • オンラインでリーチできる認知可能な情報の積み上げ
    • オンラインで検索できない技術は、無いのも同じ
  • Pay Forward
    • 情報収拾とアウトプットを、とにかく続けること

より詳細には...

qiita.com

最後に

以上で内容については終わりです。

DevRel界隈の常識すら知らない状態で参加したので、内容が新鮮で面白かったです!

全然知らない分野の勉強会に参加するのは、ノリや使っているワードが違うので楽しいことがわかりました。

イベントの様子は、以下のTLから感じられると思います! twitter.com

趣味で『しがないラジオ』を1年続けて、オフ会を開催したら40人も集まって驚いた話

f:id:jumpei_ikegami:20180602091313j:plain

こんにちは、しがないラジオのgamiです。

2018/5/23(水)に、しがないラジオのmeetupを開催しました! shiganai.connpass.com

ありがたいことに、40人もの方にご参加いただき、しがないラジオもよくここまで来たなあという感傷的な気持ちになりました。

当日の写真は、僕に消されるまで以下から見られます!
shiganai radio meetup - Google ドライブ

しがないラジオとは?

僕が新卒で入った富士通を1年半で辞め、株式会社プレイドというスタートアップに転職をしたのが2017年11月。

その4ヶ月後の2017年3月から、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」(略して「しがないラジオ」)というポッドキャスト富士通時代の同期のズッキーと始めました。

shiganai.org

最初は2人がたわいもないSIer批判話をしたり、趣味や気になる技術の話をするだけのポッドキャストでした。 そこから、少しずつ知り合いをゲストを呼び、そのゲストの知り合いが聞いてくれるようになり、直接知らなかった人もゲストに呼び、またそのゲストの知り合いが聞いてくれて。

そんなわらしべ長者方式で、ゲストとリスナーの輪が広がっていきました。

実はホスティング先のSoundCloudを見ると、毎回のエピソード毎の再生数がわかります。 始めた頃は1回のエピソードが100再生を超えれば大喜びしていましたが、最近のエピソードはその10倍の1,000回再生を超えて聴かれています。

これからもどんどん盛り上げていきたいですが、思えば遠くまで来たなあ、という感じです。

オフ会を開催した経緯

実は、2017/12/18(月)に「しがないラジオ忘年会」というイベントを開催したことがありました。 shiganai.connpass.com

過去のゲストさんを中心に10人くらい参加して、公開録音したりLTしたり飲み会したりしました。

そんな忘年会を無事終えた後で、今回のmeetupを公募して開催しようと思ったきっかけは、リスナーさんの1人であるいけさんに背中を押されたからでした。

会場の規模を決めるために、実際どのくらい来るのかTwitterで確認してみると、30-50人くらいは来てくれそうなことがわかりました。

めでたく開催が決定した瞬間です!ポッドキャストの相方のズッキーには、ほとんど相談せずに勝手に決めましたw

オフ会の準備

オフ会の準備は、主に以下をしました。

会場の予約

会場は、サポーターズさんのご好意で、レンタルスペースを無料で貸していただきました!

pages.supporterz.jp

会場費がかからないだけで、参加費がグッと抑えられるのですごくありがたかったです!

お酒とお菓子の注文

お酒とお菓子は、カクヤスで注文しました。 お酒は予定参加人数に対して1.5本/人くらいのお酒を注文したら、若干足りないくらいでした。

名札の購入と印刷

オフ会という性質上、ネット上のアカウントとリアルの人間の紐付けが楽な方が話が盛り上がるはずです。

ということで、てぃーびーさんに教えてもらって、@yoshiko_pgさんが公開している「参加者の名は。」というWebサービスを使いました。

yoshiko-pg.github.io

connpassのイベントページURLを入れると、予約している人のプロフィール画像と名前を見て、名札サイズのpdfを出力してくれます。 控えめに言って最高でした。

f:id:jumpei_ikegami:20180602081839j:plain

オフ会当日

オフ会当日は、富士通時代の同期でWeb系企業のデザイナーに転職したみっつんさんが写真を撮ってくれました!感謝!

当日の写真は以下から見られます!

shiganai radio meetup - Google ドライブ

オフ会当日の様子は、以下のTogetterや参加者の皆さんのブログをご覧ください!すごいたくさんブログ化されてて、本当にありがたいです!

togetter.com

ses.vtryo.me

note.mu

monry.hatenablog.com

gremito.hateblo.jp

kito0039.hatenablog.com

techblog.oscasierra.net

roo-ashi.hatenadiary.com

mascii.hatenablog.com

blog.haramishio.xyz

以下、独断と偏見で、エモいTweetだけ抜粋します!

収支

実は、今回のmeetupでは、飲食代などの経費を差し引いても、2万円ほどの黒字が出ました!

しがないラジオは、パーソナリティ2人やゲストさんの時間以外に、SoundCloudへのホスティング費用や、ドメイン代、ステッカー代などを支出していました。

2万円で足りるのかはよく知りませんが(笑)、編集・アップロード担当のズッキーに全部渡して、これらの支払いに当てさせていただきます!

初のmeetupを終えて

冒頭のTweetにも書きましたが、何者でもないSIerのSEだった僕が、転職してポッドキャストを始めて、そのオフ会に40人集まって、その40人で撮影した集合写真の真ん中に写ってるの、すごい話だと思いました。

ただ忘れてはいけないのは、僕と相方のズッキーは単なるきっかけを作っただけだということ。

本当に、毎回面白い話や役に立つ経験談を提供してくれるゲストの方々や、聞いてフィードバックをくれるリスナーさんたちが、『しがないラジオ』という2人の夢を一緒に盛り上げてくれたからこそ、今があります。

最近の盛り上がりを見ていると、『しがないラジオ』というコンテンツが、僕とズッキーの手を離れて、「コミュニティのものになっている」感がします。この感覚は、まだ『しがないラジオ』が無かったときに、しがないラジオep.1を僕の自宅で収録した頃の自分から考えると、すごく不思議な感覚です。

これから

2人よりは40人で支える方が強いと思うので、おかげさまで、これからもポッドキャスト『しがないラジオ』は続けられそうです!もし仮に少しの期間だけでもポッドキャストの更新が途絶えたら、きっと誰かがTwitterで「次の回まだー」と声をかけてくれるような気がします。「誰かが次のエピソードを待ってくれている」という状況は、ポッドキャストを続けるためにはすごく有利なものです。

ということで、これからも、「みんなの『しがないラジオ』」として、謙虚に楽しく続けていきます!

meetupの第2回以降についても、不定期で開催しようかと思っているので、ぜひ次回のmeetupもご参加お待ちしています!目指せ300人!

メルペイ社で開催されたNuxtMeetup#2でNuxt.js入門してきた

こんにちは、しがないラジオのgamiです。

今日は、NuxtMeetup#2にブログ枠で参加してきたので、その模様をお伝えします!

当日は、主催の@kotamatsさんの挨拶で乾杯し、お酒を飲みながらLTを聞きました。

スポンサーLT Welcome to Nuxt Meetup @andoshin11

自己紹介

  • Andy(@andoshin11)
  • 3月からメルペイのフロントエンドエンジニア
  • Vue.jsがメイン
  • React NativeやRails

merpeyの紹介

  • 信用を創造してなめらかな社会を創る
  • 株式会社ソウゾウの次の子会社
  • 「人々の新しいお財布」を目指している
  • お金の入り口と出口をつくる
  • Nuxt.jsをmerpeyでも使っている

Nuxt+TypeScript事始め @sue__71

自己紹介

  • merpay webフロントエンドiOS
  • ソリューションチーム
    • 技術課題を解決するチーム

今日はなすこと

  • VueのTypeScriptの対応状況
  • Nuxt+TypeScriptの対応状況

TSの特徴

  • 静的型付け言語的にJavaScirptがかける
  • 後付けで型定義がかける

TSのメリット

Vueの状況

  • Vue: 2.5から改善
  • vue-template: 解析されない
  • Vuex: 型定義があるが、微妙
  • Nuxt: 型定義がない

IDE

Lint

  • eslint-plugin-vueを使いたい
  • typescript-eslint-parserで対応
  • いくつかのルールをOFFにする必要がある
    • no-unuesd-vars
    • no-undef

Vue Component

  • 2.5から対応
  • tsconfigでnoImplicitThisをtrueにする

Vue Stateless Component

  • templateのみのファイルを読み込むためのtweak

Vue-Plugin

  • Vueにインジェクトされるものの型を定義する
  • VueCompontentOptionsに提供されるメソッドの型を定義する

Vuex

  • 一番TapeSafeに書きたい
    • anyで定義されるものが多いので、満たせない

型定義の改善

  • TS2.1のMapped Typeを利用することで、Vuexの型定義の改善が可能

Actions

  • dispatchやcommitの定義もtypesafeにできる

TypeSafeではあるが...

  • 実装と一致しないInterfaceを定義する気持ち悪さ
  • namespacedではない場合、さらに型パラメーターを渡さなければならない

Nuxt+TS

  • Nuxtから提供されるコンテキストAPIについて型定義する必要 -nuxtServerInitなど

Pages

  • /pages配下のコンポーネントに対して与えられる拡張
  • 別で定義した方が良さそう

まとめ

  • VueプロジェクトでTS採用するなら、型定義を書く気持ちが必要
  • 完全にTypeSafeで書きたいなら、AngularやReactがいい
  • Nuxtみたいに、機能の多いAPIを覚えるのが大変
    • 定義があると、どこで何ができるかすぐわかる!
  • とりあえず、TypeScriptは正義!

Web初心者がNuxtでサイトを一つ作るまでの技術選定 @corosuke_k

speakerdeck.com

今日はなすこと

  • 技術選定の話

サイト

  • 地域のお店を紹介するサイトをリニューアルしたい
  • HTML4系だった...
  • 管理画面も必要
  • Bootstrap感漂うサイト

実際に必要なもの

リソース

  • 1人
  • JS書いたことない

ルール

  • できるだけコードを書かない
  • 無料枠で済ませる

最初の構成

  • Vue+Firebase+Algolia+Cloudinary+bulma

なぜVue.jsか?

  • 学習が容易である必要がある
  • Web知識が流用しやすい
  • モジュール性がある
  • JSでどうにかしているものを採用したくない

課題

  • src/component以下が混雑
  • Babelやwebpackが難しい

Nuxtメリット

  • 設定がいらない
  • ディレクトリ構成がいい感じ
  • router設定もいらない
  • PWAにするのに、公式module入れればいい

Nuxtデメリット

  • 学習コストは上がった
  • components以下が混雑している問題は、解決しなかった
  • generateのビルドが長い

ビルド長い問題

  • nuxt-generate-clusterを使うと軽減された
  • 10.58s -> 3.48s

情報更新時に再ビルドが必要問題

  • Netlifyの存在知らない
  • nuxt devの状態と本番を同じ状態にしたい

SSRの問題点

Hostingを探した

  • now.sh

zeit.co

  • Realtime Global Deployments
  • zeitという会社が作ってる
    • Next.jsを作ったところ
  • CLIだけでdeploy可能
  • Nuxt.jsでつくったものは、そのままnow.shにdeployできる!
  • staticに戻すときも、そのままある

now.shのデメリット

  • now.sh自体の更新が頻繁
  • firebase hostingより費用がかかる
  • now.sh以外で購入したドメインの設定がハマりポイントあり
  • Asia Regionがない

全体の反省点

  • 自分は楽だが、引き継ぎが大変
  • Firebase依存の結果node_modulesが増えた

初の勉強会にて初LTをする初心者エンジニアのお話 @hirokinishizawa

自己紹介

  • 22才
  • 独身
  • 初心者
    • 3ヶ月前に初めてコードを触った
  • それまでは、屋上防水をしていた

仕事

  • 2週間、プロゲートで勉強
  • Nuxtを使って、メディアやLPの作成
  • 人材紹介マガジン
    • SCOUTER

テーマ

  • 初心者がどのようにメディアの作成を進めていったのか

step1 コンポーネント毎にプレビューを確認

  • デザインとにらめっこして、パーツに分ける
  • Componetsに各パーツ毎のVueファイルを作った
  • StoryBookで、Components一覧を確認

step2 一つのまとまりにするために

step3 共通部分はまとめましょう

  • 各ページで、共通部分がある
    • ヘッダー
    • フッター
    • コンテンツ

その他

  • Wordpressを使って記事を書いてるので、getしている

Nuxt.jsでサービス開発して困ったこと @takanorip

自己紹介

  • Takanori Oki
  • 株式会社スマートドライブ
  • フロントエンドエンジニア
    • Nuxt.js
    • React
    • Polymer
    • ウェブ制作
  • Polymer Japan翻訳チーム

SmartDrive Cars

  • Nuxt.jsで作っている
  • SSRはまだしてない

困ったこと

  • 結論: あんまり困らなかった
  • 公式ドキュメントとissueとPRを読めば、だいたい解決する
  • ドキュメント読む癖大事

nuxt-community便利!

maxChunkSize

  • buildオプション
  • JSファイルの上限を設定
  • 設定した数値よりファイルサイズが小さい
  • 使うとなんかエラーになる

外部JS動作しない問題

  • window.onloadの時しかJSが走らない

IEでVuexが動かない

  • babel-polyfillを食わせると動く

ライブラリをNuxtに組み込みたい

  • lodashとかをimportするのめんどくさい
  • pluginでvueとNuxt.jsに組み込むと便利
  • 余力があればモジュールとして公開

ローディング最適化

  • APIへのアクセスはasyncDataやfetchの中で行う
  • vendorへの登録忘れない
    • pluginのキャッシュができる
  • pwa-moduleは入れといた方がいい
    • SWがいい感じに動いてくれて、いい感じにキャッシュしてくれる
    • たまに、キャッシュが効きすぎて辛いことも

NUXTJS My Friend @Ryosuke_Suzuki

自己紹介

今日の話

  • Showcases
  • Nuxtで環境構築している話

KARTEインフォグラフィック

  • 3週間で開発
  • 開発2人、デザイナー1人

Hello! KARTE

  • static gen

なぜNUXTか?

  • static genできる
  • Webpack書かなくていい
  • SWまで生成してくれる

つまづき

  • CSS Preprocessorのコンパイル時エラーが起きる
    • PostCSSの設定が怪しい
  • 数百枚の画像の読み込み辛い
    • CSS spriteで画像を圧縮
  • Cloudfrontへのアップロード
    • キャッシュのクリアをちゃんとやる必要
    • Invalidation周り

NUXTで環境構築

  • 世の中のグローバル企業は、どれもUniversal web applicationだ
  • せっかくならSSRしたい

なぜSSRか?

  • Better User Experience?
  • SEO

SSR不要説

  • OGPしっかりしてれば、SSR不要
  • コンピュータリソース使う
  • 初期表示速いが、今のデバイスではそんなに問題じゃない
  • 環境構築面倒

なぜSSRか?(再)

  • グローバル水準
  • エンジニアの知的好奇心を満たす
  • どやりたい
  • 常に先端にいたい
  • SSRは必要か不要かではない。やるかやらないかだ」

構成

  • TS+Nuxt+Express
  • ProxyでSSRサーバとAPIサーバを分ける

Dir Structure

  • Monorepoっぽく分けた

なぜTSか?

  • JSの自由度を残しつつ、硬くかける
  • 中/大規模アプリケーション開発に向いている
  • VSCodeを使えば補完が強い
  • decoratorが強い

つまづき

  • d.tsしっかりかく
  • tsconfigが複数必要な場合、VSCodeがうまく読み取ってくれない
  • jest, vue-jest, ts-jestを入れるとjestでtest書ける

最後に

  • TSの環境構築はめんどくさい
  • Nuxtは公式docsを読めば詰まることは少ない

Static site generatorにおけるデータ調達の話 @miyaoka

Nuxt

  • いいですよね
  • 話すまでもない

なので

  • Gatsbyの話をします
  • Qiitaでも、Nuxtより全然人気じゃない

staticgen.com

www.staticgen.com

  • Static Site Generators for JAMstack Sites
  • 静的に書き出した方が楽だよねー
  • ランキング上位は、JSがほとんど

ReactやVueの静的サイトジェネレーター

  • React
  • Vue
    • nuxt.js
    • vuepress

データソース

  • VuePress
    • config
      • .js -> $site
    • data
      • .md -> $page
  • Nuxt+Nuxtent
    • data
      • .md -> .json
      • webpackのassetとしてemit
  • Gatsyby
    • data
      • fileでもapiでもcmsでもいい!すごい!
    • source plugin
      • nodes
    • content server
      • GraphQL
    • templete
      • components

パフォーマンス

  • リンク先リソースの先読み
    • 画面に表示されている領域を先読みできる

すごいところ

  • データソースの一元化
  • GraphQLで統一化されたクエリ
  • 超速(ちょっぱや)にかける意気込み

Guess.js

  • マシンラーニングで先読みを予測
  • "Plese support Vue.js"というissueはある

未来へ

  • Nuxtももっと超速(ちょっぱや)になる!

誰だったのか?

soussune.com

いまからはじめるnuxt-edge @potato4d

speakerdeck.com

自己紹介

  • VueやったりNuxtやったり

nuxt-edgeとは?

  • Nuxt2 is coming! oh year!という記事で紹介
  • 要はNuxt v2のEarly Access edition

medium.com

機能

  • webpack@4になって高速化
  • Support ESModules with .mjs extension

破壊的変更

  • Remove isClient / isServer flag
    • use process.browser / process.server
  • options.devがoptions.isDev
  • vendorsが消えた
    • Nuxt側でやってくれるようになった

モジュール側の追従

  • axios
    • 5.2.0では、nuxt-edgeに移っている
  • pwa
    • Coming soon
  • Other modules
    • independence

移行のための5step

  • yarn remove nuxt @nuxt/axios
  • yarn add nuxt-edge @nuxtjs/axios
  • s/isClient/process.browser/g
  • s/isClient/process.server/g
  • yarn dev

Yarn

  • Nuxtは依存管理をYarnでやっている
  • Yarnを使った方がいい

まとめ

  • Nuxt2は5月リリース!
  • 本番ですでにnuxt-edgeで使っているけど、ちゃんと安定稼働している!

宣伝

  • Nuxt tech bookという技術書同人誌を出版しました!

まとめ

以上です!当日の様子は、Tweetが流れるまでは#nuxtmeetupから追えると思います!

twitter.com

「イヌでもわかるウェブフォント」を読んで、こだわりのフォントをWebサイトで使おう!

f:id:jumpei_ikegami:20180501051539p:plain

#しがないラジオパーソナリティのgamiです。

2018/04/22(日)に、秋葉原UDXで開催された技術書典4に行って来ました!

techbookfest.org

今回は、戦利品の1つである『イヌでもわかるウェブフォント』の感想を書きます。

booth.pm

「エンドユーザーの環境によってフォントが変わるなんて許せない!」という人は、ウェブフォントを使うことで悩みが解消されるかもしれません。

ちなみに、著者であるtakanoripさんは、前にしがないラジオのゲストとしてご出演いただいたことがあります!

「イヌでもわかるウェブフォント」

本書は、特にウェブフォントの最適化の部分でかなり実践的な内容に踏み込んでいます。

ウェブフォントの導入に対する最も大きな反対意見は、「ウェブフォントを使うとサイトのレンダリングが遅くなる!」でしょう。適切な最適化をすることによって、エンドユーザーの体験を損なわずにウェブフォントを使うためのテクニックが紹介されています。

  • フォント自体の軽量化
  • preload
  • キャッシュ
  • フォントの読み込みが遅延/失敗した場合のフォールバック

フォント戦士の味方、「武蔵システム」

本書で紹介されているウェブフォントの最適化をいくつか試してみました。

まず、フォントの軽量化です。 フォントファイル自体を軽くするためには、主にフォントのサブセット化と、WOFF2対応をします。

それらを実現するソフトウェアとして、以下の2つが紹介されています。

どちらも、武蔵システムという硬派な名前のシステム会社が提供しているフリーソフトです。Windows版だけでなく、Mac版もあります。

どうでもいいですが、武蔵システムの会社情報のページに掲載されたメールアドレスは、font@opentype.jpでした。強いフォント愛を感じます。

フォントの軽量化と聞くと難しそうですが、これらのソフトウェアのおかげで非常に簡単にできました。

S3にフォントをアップロード!

独自のウェブフォントを使うためには、サーバーにフォントファイルをアップロードする必要があります。 著者のtakanoripさんオススメのフリーフォントの1つである「チェックポイントリベンジ」をS3にアップロードして使ってみました。

fontfree.me

Macでフォントをいじったことがある人にはお馴染みの宮沢賢治作『ポラーノの広場』を、HTMLにコピーして表示してみます。

CSSは、こんな感じです。フォントファイルもCSSファイルもS3にある想定です。

@font-face {
  font-family: "CP_Revenge";
  src: url("/foobar/CP_Revenge.woff2") format("woff2"),
       url("/foobar/CP_Revenge.woff") format("woff");
}

body {
  font-family: "CP_Revenge", sans-serif;
}

preloadでフォント表示を早くする

簡単に試せるウェブフォントの表示高速化として、フォントのpreloadがあります。

HTMLに以下のようにlinkタグを追加するだけで簡単に設定できます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="/foobar/style.css">
    <link rel="preload" as="font" type="font/woff2" href="https://s3-ap-northeast-1.amazonaws.com/foobar/CP_Revenge.woff2" crossorigin="anonymous">
    <title>ポラーノの広場</title>
</head>
<body>
...
</body>
</html>

preload無し

まずは、preload無しでChromeデベロッパーツールのNetworkタブを見てみます。 f:id:jumpei_ikegami:20180501053402p:plain

HTMLやCSSの後にフォントが読み込まれていることがわかります。

preload有り

続いて、preloadを設定して、キャッシュを消して再読み込みしてみます。 f:id:jumpei_ikegami:20180501053448p:plain

見事に、CSSファイルなどと並行して読み込まれています。これで、初回ロード時もテキストの表示がかなり速くなるのではないでしょうか?

まとめ

日本語話者として育ったからには、日本語フォントと向き合わなければいけません。漢字がたっぷり詰まった日本語フォントは、10MB以上になることもあります。

そんな重いウェブフォントでも、「イヌでもわかるウェブフォント」を読んで、サブセット化をはじめとする最適化を少しするだけで、かなり軽く速くなりました。

この記事で触れた内容以外にも、フォントが描画されるまでのブラウザの処理の流れなど、かなり踏み込んだ内容も本書には掲載されています。

ウェブフォント触りたいけどどうすればいいかわからん!という人は、ぜひBOOTHから電子版を購入してみてください! booth.pm

また、しがないラジオで著者のtakanoripさんにフォント愛を語っていただいた回があります。ぜひお聞きください!(宣伝)

『マンガでわかるDocker』を読んでDocker初心者がDockerがもっと好きになった話

f:id:jumpei_ikegami:20180424083652p:plain #しがないラジオパーソナリティのgamiです。

2018/04/22(日)に、秋葉原UDXで開催された技術書典4に行って来ました!

techbookfest.org

今回は、戦利品の1つである『マンガでわかるDocker』の感想を書きます。

llminatoll.booth.pm

なんと技術書典の1日間で冊子とダウンロードカード合わせて600部を売り上げる大盛況で、待機列が伸びすぎてサークルスペースが非常口近くに移動になったという伝説が爆誕したそうです。 note.mu

ちなみに、著者である湊川あいさんは、前にしがないラジオのゲストとしてご出演いただいたことがあります。

この本のレベル感

冒頭に、この本のレベル感が以下であることが明記されています。

購入前に読めるページの中に書かれているので、「思っていた内容と違った!」というミスマッチが起こらないような配慮を感じます。 なお、僕はDockerを少し触ったことがあるレベルでしたが、マンガとしても面白く、また知らない情報もあったので、楽しく読むことができました。

Dockerは怖くない!

Dockerを初めて使い始めるわかばちゃんは、こんな感想を持ちます。

  • そもそもDockerがなんなのか全然わからん!
  • せっかく立ち上げたDockerコンテナがすぐに止まっちゃうのなぜ???

これは僕がDockerを使い始めたときに感じたことと全く同じでした。おそらく、著者である湊川さんがDockerを初めて触ったときの気持ちをメモしていて、それを漫画にしたんじゃないかなーと思います。

初心者がある技術に触れるとき、最初に抱いた疑問を解消できないままにしておくと、その技術に対する漠然とした怖さや苦手意識が芽生えてしまいます。この『マンガでわかるDocker』を読むと、最初に抱いた疑問がスッキリ解消されるので、「Dockerは怖くない!」という実感をもってその先の学習に進めるようになっています。

デーモンは悪魔じゃない!

プログラミングをしていると、よく「デーモン」と呼ばれるプログラムが登場します。Dockerにも「Dockerデーモン」と呼ばれるプログラムがあります。 僕はずっと「悪魔」だと思ってたのですが、「悪魔じゃないよ!」ということが書かれていて、衝撃を受けました!

Wikipediaによると、「daemonは目には見えないが常に側にいて、その意志を働かせている何ものか」だそうです。 daemonはdemonの古い綴りらしいので元は同じ単語のようですが、守護神だと思った方が怖くないのでお得ですね。

複雑なものをキャラ化することの価値

湊川さんのマンガでは、プログラミング言語やプログラムがキャラ化されることが多くあります。

わかばちゃんシリーズのHTMLちゃんなどがその例です。

わかばちゃんと学ぶ Webサイト制作の基本

わかばちゃんと学ぶ Webサイト制作の基本

今回も、Dockerデーモンというクジラのゆるキャラ的なキャラクターが登場します。

Dockerデーモンについても、$ docker run hello-worldというコマンドを実行すると返ってくる味気ない標準出力の裏で、Dockerデーモンさんが裏でせっせと働いている光景を想像できるようになります。

複雑なものや怖そうなものを、キャラ化して親近感を抱きやすくする効果は、マンガならではの価値だなーと思いました。

「怖くない!便利!」から始まる学習

この『マンガでわかるDocker』を通じて、ある技術を初めて触る人には、以下を伝えることが大事だなーということに気付きました。

  • ○○は怖くない!
  • ○○を使えると、こんなに便利!

単に仕様が羅列してあるようなドキュメントを初心者が見てしまうと、「なんか怖そう...」とか「何に使えるのかわからないから別に勉強しなくてもいいか...」となって挫折しがちです。 苦手意識をもったままその技術に触れ続けていても、楽しく勉強できないので、学習コストはあまり下がりません。

逆に、「怖くない!便利!」という感覚を最初からもてると、楽しみながらどんどん学べるようになる気がします。

湊川さんの「学習コストを極限まで下げたい!」という思いについては、弊ポッドキャスト「しがないラジオ」にご出演いただいたときにも熱弁していただきました.

「Docker怖いけど学びたい!」という人は、ぜひ読んでみてください!

llminatoll.booth.pm

We Are JavaScripters! @18thでYosuke FURUKAWAさんの話を聞いてきた

#しがないラジオのgamiです。

We Are JavaScripters!の18thに参加してきました! wajs.connpass.com

今回初めて、WeJSのステッカーができて最高でした。

当日のLTの内容をざっくりまとめたので、ご覧ください!

LT1: レガシーなバッチ生成ページをNuxt.jsでSSRするモダンなページにしたい

twitter.com

自己紹介

  • Seiji Komatsu
  • サーバーサイド開発
  • 猫、珈琲、酒
  • Vue.js/Nuxt.js周りのフロントエンド頑張りたい

内容

課題

  • 2009年から稼働しているシステム
  • 日次バッチで13万枚のHTMLを生成
  • コンテンツ変更が即時反映されない
  • Mayaa(Javaの古いテンプレートエンジン)を使っている

要件

  • コンテンツ変更の即時反映
  • パフォーマンス
  • SEO
  • モダンな技術
  • メンテナンス性
  • CI/CD

ただし

  • フロントエンドがいない
  • デザイナー/コーダーがHTML書く

選定技術

  • Vue.js + Nuxt.js

理由

  • ReactはJSX辛そう
  • Angularと違って、部分的に始められる
  • 日本語翻訳ドキュメントの充実
  • SSRしたい

経過

  • APIがそもそも無いので、作る
  • 現在のテンプレートをVue.jsのテンプレートに変換中

レガシーシステムの辛み

  • CDNが挟まっていない
  • CDNを挟んだときの影響を1つずつ調査する必要

LT2: ブラウザからカメラを呼び出し手書きのサインを読み取って認証するぞ

twitter.com

内容

  • コードは出てこない!
  • ロゴステッカー作ろうぜ!
  • せっかく配るなら、遊びたい!

塚田○場

  • 名刺を貰える
  • 来るたびにランクが上がる

ステッカーが会員証になったら楽しい!

  • 署名!

ストーリー

  • ステッカーを配る
  • マジックでサイン
  • カメラで読み込むとユーザー名がわかる!
  • フレンド登録できる!
  • 前にあった人が、今日のイベントに参加しているかがわかる!

要素技術

  • カメラ呼びだし
    • MediaDevices.getUserMedia
  • 画像処理

カメラ

  • MediaDevices.getUserMedia
  • streamが得られるので、mediaElementに渡す
  • canvasにdrawImageすると、好きに加工できる
  • ブラウザ対応状況
    • iOS11から対応

OpenCV(wasm-build)

レシピ

  • 二階調化
    • 形だけにする
  • 輪郭検出
    • ロゴ検出
    • 五角形かつ一定以上の面積があるものだけ抽出
  • 透視変換
    • 斜めに撮っても大丈夫にする
    • 元のロゴについて最小矩形を作っておく
    • 入力画像についても最小矩形を作る
    • 矩形を合わせるように変形する
  • 二階調化(再)
    • 閾値を調整して、サインだけを抽出する

課題

  • どうやってマッチングするか?
    • サインを検索する方法を模索中

感想

  • 最近はJSの知識でなんでもできるから楽しい!

LT3: 1日一つ強くなる戦略としての UCDDD (Udemy Course Development Driven Development)

twitter.com

自己紹介

  • UdemyでReact+Reduxのコースを4月に公開
  • フリーのフロントエンドエンジニア
  • Reactの仕事募集中

UCDDD

  • Udemyコースを作ることで圧倒的に成長する
  • 教える方が、学べる
  • 何度も撮り直しをしていると、内容については完璧になる

やったこと

CodeSandboxに全コードを公開

  • npmもinstallできる
  • 各章のコードを全てCodeSandboxに追加していく

codesandbox.io

全レクチャーにテキストを用意

  • 概念的な部分は、テキストがあった方がわかりやすい
  • 講師側も、テキスト化すると勉強になる

まとめ

  • 日本語のコースはほとんど無い!
  • 申請すれば、誰でも通せる!

better-than-i-was-yesterday.com

LT4: スポンサーLT

forkwell.com

Forkwell 重本様

メッセージ

  • 幸せに働くITエンジニアを増やしたい!

LT5: メロンのはなし〜melonJSで始めるゲーム開発入門〜

twitter.com

自己紹介

  • 大武松生
  • フリーランスエンジニア
  • jQueryをReactに組み込むというくらい過去を持つ
  • Qiitaで10いいねを超えるのが夢

テーマ

  • モダンJSだけじゃなく、melon.jsを試すと気分転換になる!

melonJSとは?

作ったものを公開!!

どうやって作ったか説明

  • Boilerplateがある!
    • gruntが必要
  • Tiled Map Editorでお絵かき
    • マップ
    • キャラ配置
    • 見えない壁
  • melonJSのオブジェクトを使い倒す!
  • コード書いて素材入れてgrunt serveしたらできる!

所感

  • 環境構築が楽!
  • デプロイが楽!
  • 極めたら過ごそう!

LT6: 「LP完成しました!お問い合わせメールの繋ぎ込みだけお願いします!」なんて二度と言いたくないのでフロントの知識だけでお問い合わせを作った話‬

twitter.com

自己紹介

  • Taskey.inc
  • peepというアプリ作ってます!

背景

  • LP作ってますか?
  • デザイン見て
  • コーディングして
  • レスポンシブ
  • SEO
  • お問い合わせ
    • メールのためだけにサーバ立てる?
    • php書く?

Google Apps Script

  • JavaScriptで書ける
  • GmailApp.sendEmail(mail, title, text);

実際に作ってみよう(デモ)

  • 新規スクリプト作成
    • doGetで入力値を取得
    • sendEmailに渡す
  • アプリケーションを公開
    • エンドポイントができるので、formのactionに設定

課題

  • Gmailにしか送れない!
    • 転送設定すればOK!

LT7: reduxはいらないかもしれないし、context APIもあんまり使わなくていいかもしれない

twitter.com

自己紹介

  • 株式会社CureApp

目次

  • reduxはいらないかもしれない
  • context APIもいらないかもしれない
  • おまけ1
  • おまけ2

reduxはいらないかもしれない

  • 作者がMediumで言ってた
  • トレードオフがあるので、そこを理解して使おうね」
  • single state & serializableの恩恵
    • ローカルストレージに永続化し状態を復元
    • エラー時に状態をサーバーに投げておく
  • event sourcing風 & serializableの恩恵
    • actionを投げればコラボレーション環境を簡単に作れる
    • undo実装が簡単
    • 過去状態の復元が簡単
    • ツールの作りやすさ
  • ステートマシンを用意することの恩恵
    • 再利用性とUI交換のしやすさ
  • 普通に使っている

context APIもいらないかもしれない

  • 作者が言ってた
  • 「バケツリレーの代わりとしてそこかしこで使うものではない」
    • 未解決の問題を解消するためのもの
  • 使いどころ
    • 多言語対応くらい?

おまけ1

  • 「バケツリレーは、render propsが軽減できそう」と作者が言ってた

おまけ2

  • Formik
    • redux-formだるい人向け

LT8: .mjs

twitter.com

自己紹介

  • リクルートテクノロジーズ グループマネージャー
  • Node.js日本ユーザーグループ代表

Node.js v10リリースされます!

  • 明日リリース予定
  • Notable Changes
    • for-await-of
    • ESModules
    • fs/promise
    • private/public field

DEMO

fs/promises

  • fs.readFileでコールバックが不要に!?

ESModules

  • そのまま動かそうとすると、importがサポートされていないので動かない
  • node10 --experimental-modules fs.mjs fs.mjs

private/public field

  • #を付けた変数はプライベートになり、継承先からは参照できない
class A {
  #B = 1;
}

mjsとは?

  • Module !== Script
    • どっちのファイルを呼んでいるかを判定する必要がある
  • 長い議論の末、.mjsが必要だとなった
    • 拡張子だけを見れば、判定できる!
    • Simple and Faster

Module

  • デフォルトでstrictモード
  • top level scope
    • スコープが閉じている
  • reserved await

Script

  • non strict
  • global scope

.jsは使っちゃいけない?

loader optionを使えば回避できる

  • loaderを書く必要がある

--modeというflagを使う?

  • 議論中

結論

  • ESMを使わないなら、.jsでいい
  • v9-10でESMを使うなら、.mjsを使うべき
  • v10のESMをヘビーに使ってしまっても、仕様が変わるかも?

ファイル拡張子よもやま話

  • 「.jsではなく、.es3や.es4を使おう」という話が出たことがあった
  • Web does not have version
    • un-detectable featureについては、困る!
    • Modern JavaScriptでは、機能を判定するのは難しくなってきた!
  • Module JavaScript is JavaScript 2.0
  • We are JavaScripters! Every JSers would be better to enjoy chaos!

以上!

Tweetが流れてしまうまで、当日の雰囲気は#WeJSのTLから感じられますー twitter.com