技術書典5で、『完全SIer脱出マニュアル』という本を出します
こんにちは。 明日、2018/10/8(月)に開催される技術書典5「お27」ブースで、『完全SIer脱出マニュアル』という本を頒布します。
何でこの本書いたの?
技術書典4に一般参加して、知り合いが本を出しているのを見て「楽しそうだなー」と思ったのがきっかけでした。 さっそく技術書典5のサークル登録をしてから「自分にしか書けないことって何だろう?」と考えた結果、思い至ったのが「レガシーな環境からモダンな開発現場に転職して楽しく働くためのノウハウ」でした。
果たしてそれは「技術書」なのかという葛藤はありましたが、 技術書典公式のFAQにも、技術書の定義について「ITや機械工作とその周辺領域について書いた本」と結構広く書かれているし、「情熱プログラマー」みたいなライフスタイル系の本も技術書的な扱いを受けているので、この本も「情熱プログラマー」枠だと自分に信じ込ませて書きました。
- 作者: Chad Fowler,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2010/02/26
- メディア: 単行本(ソフトカバー)
- 購入: 24人 クリック: 683回
- この商品を含むブログ (126件) を見る
で、お前誰よ?
gami(@jumpei_ikegami)と申します。 新卒で某大手SIerにSEとして入社したあとで、SaaSスタートアップにエンジニアとして転職しました。 転職後は、開発とかクライアントワークとかもしつつ、エンジニアの中途採用に関わって主に書類選考や一次面接をガシガシ担当しています。
また、趣味で「しがないラジオ」というTech系ポッドキャストを運営しています。 様々なゲストの方をポッドキャストに呼んでそのキャリアについて話を聞いているので、 特に若手エンジニアのキャリア選択に関する知見がバシバシ溜まっています。
ちなみに、この『完全SIer脱出マニュアル』はポッドキャストの相方であるzuckey(@zuckey_17)と共同執筆しています。
こんな人にオススメ
本の中にも書いている想定読者は、以下のような人です。
- SIerやSES企業でSEや開発をしていて、毎週⽉曜⽇の朝に仕事に⾏くのがつらい⼈
- いまよりもっと楽しく働きたいエンジニア
特に、「仕事が楽しいとか言ってる人のことが信じられない」とか、「我慢してつまらない仕事を続けなきゃいけないのは自分に技術やスキルが無いからだ」と思っているかつての僕みたいな人に読んでもらいたいです。
この本で伝えたいこと
この本で伝えたいことは、主に3つです。
- 「楽しい仕事」というのは本当に実在する
- 少しの努力や考え方のシフトで、「楽しい仕事」にも意外と手が届く
- あなたの人生は、あなたの決断次第で良い方向に変えられる
ともすると意識高い系みたいな話になりがちであれですが、「自分に全く自信なかったけど、転職して楽しく働いてます」みたいなエンジニアと少なくとも10人以上はリアルで出会った上で書いてるので、けっこう実態に即していると思います。
タイトル燃えそうだけど大丈夫?
『完全SIer脱出マニュアル』というタイトルをSIerで楽しく働いている人が見たら、確かに悲しみや怒りが湧いてくるかもしれません。 しかし、それ以上にメリットが大きいと考えて、あえて燃えそうなタイトルにしました。
- 「エンジニア労働市場への誤解や自身への過小評価によって能力を最大限発揮できていない人」が、あまりにも多い印象がある
- しかし、この本を本当に届けたい人のほとんどは、技術書典を知らない
- この本が炎上でも何でもしてインターネットで話題になれば、そんな人にも届くかもしれない
僕は楽しく働く人を増やしたいと考えています。 みんな楽しく働いた方が面白いモノが生まれやすいし、巡り巡って僕の人生にとってもプラスだと思うからです。 そんな訳で、話題になるための炎上なら、どんとこいです。
推しポイント
この本の推しポイントは、以下です。
- 初めてのエンジニア転職でよくある疑問に答えています
- 楽しい仕事とか、本当にあるの?
- 若いうちに転職するのって、デメリットあるの?
- ベンチャー企業って怖いの?即戦力しか要らないの?
- いま技術力が無い人は、エンジニアとして雇ってもらえないの?
- 「成長」って必要?
- モダンな開発が未経験な状態からエンジニアとして転職をするための具体的なアクションを、7つのステップに分けて細かく解説しています
- 一般論で終わらないために、各ステップについて実際に経験したエンジニアが話している「しがないラジオ」のエピソードを逆引き形式で紹介しています
詳しくは目次をご覧ください。
また、執筆裏話については「しがないラジオのep.32」でも話しています。
「ep.32 楽しいVue.js入門と完全SIer脱出マニュアル」を公開しました!
— しがないラジオ公式 (@shiganaiRadio) October 3, 2018
技術書典5、「完全SIer脱出マニュアル」、「Vue.js入門」、などについて話しました。https://t.co/Gvxmn3ea9v#しがないラジオ
まとめ
僕も技術書典5の「お27」で売り子しているので、ぜひお会いしましょう!
以下、ワクワクが止まらない僕のTweetで締めくくります。
技術書典、ついにサークルリストの被チェック数が印刷予定冊数である200を超えた!書籍版はすぐに無くなる予感。ダウンロードカードは大量に発注しといてよかった。#技術書典 #完全SIer脱出マニュアル #しがないラジオ
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) October 5, 2018
帰宅したら、『完全SIer脱出マニュアル』のダウンロードカードが届いてた!
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) October 5, 2018
ちゃんと印刷出来てて感動!紙版と同様に「購入者限定しがないラジオエピソード音源」も付いてるので、ぜひダウンロードカード版でもお買い求めください。#完全SIer脱出マニュアル #技術書典 #しがないラジオ pic.twitter.com/9FPKJv9Nrn
技術書典の設営を予行演習してみた!ブラックの布を敷くと高級感が出て良い。ポスタースタンドも存在感あるので、買ってよかった。あー楽しみ過ぎる。ワクワク感やばい。
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) October 6, 2018
(物理本はまだ無いので、写真の2冊は友情出演です)#完全SIer脱出マニュアル #技術書典 pic.twitter.com/MpgQ5DrvLn
技術書典5の『完全SIer脱出マニュアル』の被チェック数、現在247。紙の本は200部しか無いのでたぶん早い段階で売り切れますが、SIerの紙文化に嫌気がさしているチェッカーの皆さんにはダウンロードカード版の方がオススメです(暴論)#技術書典 #完全SIer脱出マニュアル pic.twitter.com/eH4CGU362F
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) October 7, 2018
「人を知ること」が重要になったいま、なぜ「普通の個人」が輝く時代になったか? #CXDIVE
gamiと申します。PLAIDという会社で、「CX(顧客体験)プラットフォーム KARTE」の開発や提供にまつわる仕事をしています。 プライベートでは、「楽しく働く人を増やす」ことを目指したポッドキャスト『しがないラジオ』のパーソナリティをしています。
今日は「CX DIVE」という最高なイベントに参加してきました。 cxdive.com
PLAIDが主催のイベントなので僕は完全に関係者なのですが、普通に参加者として行ってきて普通に得るものが大きかったので、個人のブログで感想を書きます。
CX DIVEは、CX(顧客体験)の今とこれからを考えるイベントで、セッション形式で12名の登壇者がテーマに沿ったトークをします。
僕はミーハー心でゆうこすさんやハヤカワ五味さんのセッションを聴いたのですが、その話の内容や2名の生き方から得られる気付きが多かったので、そこを中心に書いていきます。
女性の「モテたい」気持ちを全力で応援する24歳
ゆうこすこと菅本裕子さんは、HKT48脱退後に大きな挫折を味わい、そこからSNSをフル活用してフォロワーを増やしたクリエイター。 「モテクリエイター」を名乗り、各種SNSや動画配信サービスで女性がなりたい自分になるための情報発信をしています。
CX DIVEのセッションでは、自分のファンを分類してそれぞれに向けた発信方法を考える、新規流入向けとコアなファン向けでメディアを意図的に使い分ける、など、ファンを増やすための非常に具体的な方法論を語っていました。
元々は男性ファンが多いアイドルだったところから、今では圧倒的多数の女性ファンを抱え、累計フォロワー数150万人を突破したとのことで、個人とはいえ完全にマーケティングのプロという感じです。
もともと男性ファンの多いアイドルだったところから、女性向けの情報発信をして女性フォロワーが大多数になったとのこと。まさにマーケティング。#ゆうこすCXDIVE #CXDIVE
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) 2018年9月4日
また、「インスタ世代は『ググる』のではなく『タグる』(タグで情報を手繰り寄せる)」という話から、インスタのview数を増やすためのタグの重要性についてつなげていて、納得感がすごかったです。
インスタ世代は、「タグる」=タグで検索しているらしい。インスタでは適切なタグを付けるとタグ経由で新規流入を狙えるとのこと。「タグ多い人なんなの」としか思ってなかったので、めっちゃ勉強になる!#ゆうこすCXDIVE #CXDIVE
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) September 4, 2018
僕はギリギリ20代ですでに若者文化から取り残されているので、ものすごく勉強になりました。
ゆうこすさんについては、僕も大好きなmilieuというメディアのインタビュー記事がとてもわかりやすいです。
コンプレックスのある女性のためのファッションブランドを経営する23歳
ハヤカワ五味さんは、19歳で株式会社ウツワを設立した経営者。
胸が小さいことを「貧乳」と呼ぶのは間違っているという思いから「シンデレラバスト」というポジティブな呼び方を提唱し、シンデレラバスト専門の下着ブランドを運営しています。
ハヤカワさん自身もコンプレックスを抱いていたことから、同じような悩みを抱えた女性に届けたいプロダクトを作って販売しています。
CX DIVEのセッションでは、地域や世代で異なる「色眼鏡」をテーマに、マーケティングの文脈でも「事実より、知覚されたものが重要」であることを、具体的な事例を交えて話していました。
ハヤカワ五味氏曰く、ブランドにとって一番大事なのは、「一貫性のある顧客体験」である。しかし、色眼鏡=バイアスがあることを前提として考えるべき。事実より、知覚されたものが重要。これが、「超顧客視点」。なるほど。#CXDIVE_X #CXDIVE
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) September 4, 2018
例えば、日本人の多くは「欧米人への憧れ」を抱いておりアパレル系のメディアに欧米人モデルが多いですが、中国では全くそんな「色眼鏡」は無いので日本と同じ感覚だと爆沈する、という話をされてました。 そこまで違うのか、という例が多く、学びが大きいです。
確かに、例えば日本向けのアパレル系広告って欧米人モデルが多くて、自分が着たらどうなるか全然わからなかったりする。これも、「欧米人への憧れ」という日本人の色眼鏡が前提となっているのか。これが中国だと全然違うらしい。面白い。#CXDIVE_X #CXDIVE
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) September 4, 2018
特に面白かったのは、「好景気眼鏡」として紹介していたバイアスでした。 好景気の時代を生きてきたおじさん達は無邪気に「最近の若者は欲がなくて、車も買わない」とか言いますが、普通に収入は減って支出は増えてるので、よっぽど好きじゃ無いと買わねえよ(意訳)、とバッサリ切り捨てていました。
23才のハヤカワ五味氏が、好景気を生きてきた人たちの「色眼鏡」を、若者の年収低下や学費・年金などの支払額増加の統計を元にバッサバッサと切り捨てていくの、すごい気持ちいいw 確かに、月々5万円しか余らないのに、2万円の服はなかなか買えない。#CXDIVE_X #CXDIVE
— gami お27『完全SIer脱出マニュアル』@技術書典5 (@jumpei_ikegami) September 4, 2018
ついつい、日本や自分が「普通」だという前提でモノを売ろうとしてしまうけれども、同じものを見ても意外とみんな全然違う感じ方をするんですよ、という話でした。
「バイアスなんて無い」という認知そのものがそもそもバイアスである、というメタ的な構造もまた面白かったです。
ハヤカワ五味さんについては、少し古いですが以下のインタビュー記事がよくまとまっていました。
なぜ中年たちはこぞって彼女達の講演を聞きに来るのか?
とても優秀だとはいえ、ゆうこすさんは24歳、ハヤカワ五味さんは23歳です。 でもそんな2人のセッションは、狭い会場なら立ち見が出るほどの大盛況でした。 40代と思われる「おじさん」とかも、真面目な顔でメモを取りながら、彼女らの話を聞いていました。
きっと10年以上前であれば、こうしたカンファレンスで呼ばれる登壇者は大企業でたくさんの経験を積んだ中堅以上の社員だったでしょう。 それが、個人としての活動の延長線上で活躍している若いクリエイターの話をこぞって聴くようになったのです。 これは、何かのゲームのルールが変わったとしか思えません。
僕は、「人を知ること」の重要性が増したことがそのゲームチェンジの大きな原因かもしれないなあと、漠然とセッションを聞いていて思いました。 ハヤカワ五味さんの話にあるように、地域や世代などの環境によって、「色眼鏡」は大きく異なります。 今では、こうした「人の違い」に寄り添ったニッチなプロダクトの提供も、事業として可能になってきました。 逆に言えば、「人の違い」を無視した画一的なプロダクトは、どんどん売れなくなっています。 こうしたルールの中では、サービスやプロダクトを届けたい相手を深く知ることが、とても重要になります。
特に情報が爆発的に増えたここ10年の環境変化は目まぐるしく、ギリギリ20代の僕でも、5歳年下の若者たちのモノの見方や商品の買い方については全くわかりません。 また、インターネットによって多様な価値観が許容され、クラスタ毎に情報の受信や発信ができるようになりました。 インターネット上に露出した多様な人間像の全てを正しく理解することは不可能であり、その翻訳者としての「個人」が求められているのではないでしょうか?
ゆうこすさんや、ハヤカワ五味さんは、「若者」、「モテたい女性」、「身体にコンプレックスのある女性」などのクラスタの声を翻訳する代弁者として、圧倒的な価値があるように見えます。 若者の「眼鏡」を「おじさん」がダイレクトかつ身体的に理解することは、到底不可能だからです。
「普通の個人」としての輝き方
ゆうこすさんや、ハヤカワ五味さんのような、昔の価値観で評価すれば「普通の個人」であったような人が、ビジネス的な場所でも輝ける時代になっています。 それは、個人として輝きたい人にとっては素晴らしい時代であり、試される時代でもあります。
お2人の活動から、個人としての輝き方のヒントを得るならどこでしょうか?
「人を知ること」の重要性に照らして考えると、「自分はどんな人の『眼鏡』を知っているか」ということを問い直すことから始めればいいと思います。
例えば、何者でもない僕の例で考えましょう。
僕が持っている属性は、大小散りばめると、例えば以下のような感じです。
ここから、レアリティの高さとニッチさのバランスを考えて、「どんな人の『眼鏡』を知っている」と見せていくかを決めていくのが良さそうです。 例えば、「男性」というのは広すぎますが、「元『東大卒フリーター』」というのは狭すぎる気がします。
「レガシーなSIerからベンチャーに転職」という要素から、「SIerからベンチャーにエンジニアとして転職する人」の気持ちはわかるかもしれません。 実はそんな人向けにすでにポッドキャストで情報発信をしています。
他には、「マーケティング界隈で働くエンジニア」という要素を活かして、「プログラミングを学びたいマーケター向け」に上手く情報発信ができるかもしれません。
こんな風に、「自分はどんな人の『眼鏡』を知っているか」という軸で自分が持っているカードを整理することで、個人として輝くための方向性が見えてくる気がしました。
「ボーダーレス」と「コミュニティ」
今回のCX DIVEのキーワードに、「ボーダーレス」という言葉がありました。 この言葉は、最初のKey Sessionでも最後のClosing Sessionでも、示し合わせたように登場しています。 この「ボーダーレス」と絡めてこれまでの話を解釈してみるのも面白そうです。
ゆうこすさんもハヤカワ五味さんも、自分が欲しい情報やプロダクトを発信しているように見えます。 そこには「企業と消費者」のような境界はありません。 また、例えばゆうこすさんのインスタグラム投稿にはフォロワーからのコメントが100以上付き、そのコメントも含めて全てがコンテンツとして機能しています。 そこに「発信者と受信者」のような明確な境界はなく、誰もが発信者であり受信者であるような世界で、個人として自分のフォロワーたちの間に溶け込んでいます。
「企業と消費者」というレガシーな境界が溶けていった先にある「消費活動」は、もはや「コミュニティ」的な様相を呈してきます。 ライブ配信中に商品を販売するライブコマースなどは、その象徴的な例にです。
一歩踏み出した個人が、特定クラスタの内側から発信をし、その発信を核にコミュニティが形成されていく。 ある個人は複数のコミュニティに緩やかに所属し、そのコミュニティの中で情報の受発信や商品の売買を行う。 もしも、そんなコミュニティベースの有機的な経済活動が全ての世代で当たり前に行われる時代が来たら、ビジネスも今までとは全く違うルールで動くことになり、かなり面白い世界なんじゃないでしょうか?
そんな世界の「CX」とは何なのかを考えていくのは、面白そうじゃないですか?
サイ本こと『JavaScript 第6版』全800ページを読破し、1万行のesaにまとめてわかった5つのこと
しがないラジオのgamiです。
JavaScript界隈では有名な、オライリーのサイ本こと『JavaScript 第6版』という鈍器、もとい書籍を読みました。
- 作者: David Flanagan,村上列
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/08/10
- メディア: 大型本
- 購入: 12人 クリック: 252回
- この商品を含むブログ (18件) を見る
2012年に発行された、約800ページもある、かなり内容の多い本です。 僕は本を読むときにesaに要約しながら読み進めるのですが、サイ本のまとめesaは全体で「約1万行」という修行みたいな分量になっていました。
サイ本、3年越しくらいでやっと読み終わったあああああ!!!esaにまとめながら読んでたけど、コードも含めて約23万字、1万行の分量になっててesaが悲鳴あげてたw今度感想ブログ書く。多くの人には読む必要の無い本だけど、Web周りのJavaScriptの世界を概観するにはよかった。https://t.co/Ym3D5VRIgW
— gami@しがないラジオ (@jumpei_ikegami) 2018年6月24日
サイ本を要約しながらじっくり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群の標準仕様」を学ぶということなのだなあ、ということをサイ本を読んで実感しました。
JSのクライアントサイドAPIをちゃんと学ぶと、ドキュメントのレンダリングとかフォーム部品とかiframeとかイベントハンドリングとかCookieとかHTTPとか、Webフロント周りの知識が一通り身につくので、すごくいいと思った. サイ本を読めとは口が裂けても言えないが、JSを通じてWebを学ぶのはおすすめ.
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月22日
例えば、ただJavaScriptで計算をしたいだけなら、別にWebページのHTMLをどのように操作できるかなど知らなくても何も困りません。ただし、JavaScriptを書きたい、学びたい、というモチベーションの多くは、Webのクライアントサイドに関わる以下のようなことです。
- 動的にHTMLやCSSを変化させたい(DOMやCSSOMの制御)
- ユーザーの操作に応じて処理を変えたい(イベント処理)
- 外部サーバーと非同期で通信したい(Ajax)
- ブラウザ側にデータを保持して、IDやセッションを管理したい(Cookie、localStorage)
サイ本の13.3.4『クライアントサイドJavaScriptのタイムライン』がめっちゃいい. WebページのJS実行順が詳細に書いてある. document.write()、async属性、defer属性が全て考慮され、document.readyStateとwindowのloadイベントのタイミングが書いてある. 当たり前の情報だけど、ありがたい.
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月13日
逆にクライアントサイドJavaScriptは、それを学ぶ過程で、HTMLやCSSの仕様に依存したAPIを学ぶことになります。なので、Webのクライアントサイドの技術について深く学びたい場合は、JavaScriptの学習をすることで、HTMLやCSSも含めたブラウザの仕様について深く理解できるようになると思います。
ちなみに、2007年に発行された一つ前の版である『JavaScript 第5版』の目次を『JavaScript 第6版』のものと比べると、ブラウザの機能の変遷がわかって非常に面白いです。
2007年の第5版では「Javaアプレット」、「Flash」、「XML」などの章がありますが、2012年の第6版ではそれらがすべて削除され、代わりに後述する「jQuery」や「HTML5 API」の章が追加されています。
クライアントサイドJavaScriptの爆発的変化
『JavaScript 第6版』が出版されたのは、2012年の8月です。今が2018年の7月なので、たった6年前になります。ただし、この本に書かれている内容ですら、すでに一部の仕様が廃止されていました。
例えば、windowオブジェクトのメソッドとして本書で紹介されているshowModalDialog()
は、MDNで調べると「この機能は削除されました。ウェブサイトやアプリケーションを修正してください。」と書かれています。
サイ本に書いてあるwindow.showModalDialog()がChromeやFirefoxでは廃止されているというこの世界の希望. 要らない仕様はブラウザベンダーが結託して消していって欲しい. 強気MDN萌え:「この機能は削除されました。ウェブサイトやアプリケーションを修正してください。」https://t.co/jMpefmNge9
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月15日
「ブラウザは後方互換性を大事にするので機能を削除できない」とよく耳にしますが、仕様の議論が不十分なままブラウザに実装された過去の機能については、廃止されているものもあるようです。
サイ本に「keypressイベントを代替する次世代のテキストイベントや!(意訳)」とドヤ顔で書いてある"textinput"イベントさん、MDN検索しても全く出てこないので、消滅したという認識でよろしいか?
— gami@しがないラジオ (@jumpei_ikegami) 2018年4月13日
サイ本を読むとき、あまり聞いたことのない機能については、実際にブラウザのコンソールで本当に使えるのか試したり、MDNに記載があるかを調べたりしていました。少し古めのJavaScript本を読むときは、機能が廃止されている可能性を考慮しながら読んだ方が良さそうです。
なお、JavaScriptはES2015で以下のような新しいシンタックスがかなり追加されましたが、サイ本にはそれに関する以下のような記載はありません。
let
、const
による変数宣言- アロー関数
class
構文- 分割代入
- importとexport
さらに、現代のクライアントサイドJavaScriptとは切っても切り離せない以下のような技術スタックには特に触れられていません。
- webpackなどのモジュールバンドラ
- Vue.jsなどのJavaScriptフレームワーク
- TypeScriptなどのAltJS
フロントエンドの開発に求められるものの多様化とWeb技術の変化の速さを揶揄して「フロントエンド地獄」と呼ばれますが、サイ本もまた(少なくとも第6版の時点では)その地獄に囚われ古臭い本になりつつありました。
そのためサイ本は、「最新のJavaScript」ではなく、「時代を経ても変わらないJavaScriptのエッセンスや、すでに安定したWeb API」について学ぶための本として読んだ方がよいです。
「最新のJavaScript」については、出版されるかわからない『JavaScript 第7版』に期待しましょう。
ブラウザ間の差異から来る闇
JavaScriptという言語の特殊性として、その実装はブラウザベンダーに委ねられており、独自の方言が認められている点があります。もちろん、Webページを実装する開発者としては、1つのJavaScriptファイルが複数のブラウザで意図通りに動作することを期待します。ただし、歴史的経緯から来るブラウザ間の仕様の差異によって、その期待はしばしば裏切られてきたことが、サイ本を読むとわかります。
特に、Web標準の策定プロセスが今ほど洗練されていなかった時代に実装された機能については、多くの闇を生み出しているようです。例えば、window.onerror
というエラー時に呼び出される関数内では、エラー処理完了時に通常はfalse
を返します。ただし、歴史的経緯から、Firefoxだけはtrue
を返さなければいけないそうです。
サイ本. window.onerror内でエラー処理が完了したら通常falseを返すべきだけど、Firefoxだけはtrueを返さないといけないらしい. 『残念ながら、歴史的な理由により、Firefoxのエラーハンドラでは、ハンドラがエラーを処理したことを示すためには、trueを返さなければなりません』. 歴史的な理由とは?
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月15日
このような問題に対処するには、本来の処理に加えて、どのブラウザで実行されているのかをチェックする「ブラウザテスト」を実施しなければいけません。
(なお現在では、window.onerror
はtry-catch
によって代替され、ほとんど使われていません。)
特にブラウザ互換性についての話題で言及されやすいInternet Explorer(IE)については、本書でも「非互換性の多くは、IEに関連したものです」と、名指しで批判されています。
サイ本13.4.6「実際のところ、クライアントサイドJavaScriptでの非互換性の多くは、IEに関連したものです。」くそわろたwww
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月13日
古い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の標準化が進んだことは、非常に喜ばしいことだと思います。
サイ本. かつてはIEでしか動かないこんなページが存在したのか...闇...
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月10日
<script type="text/vbscript">
' VBScriptコードを記述
</script>
また、Web標準の策定プロセスが整備されたことに加えて、Microsoft Edgeの登場、ブラウザ間の差異を埋めるPolyfillなどのライブラリの存在によって、ブラウザ間の差異を前ほど意識せずにJavaScriptを書くことができる環境になりつつあります。
かつてのjQueryがもたらした価値
サイ本では、第19章の約70ページ全てを、丸々jQueryの紹介に割いています。JavaScriptの1ライブラリとしては、破格の待遇です。
2012年当時、jQueryがJavaScriptライブラリとしてデファクトスタンダードであったことがわかります。
今でこそ目の敵にされているjQueryですが、当時これほど流行った理由がサイ本を読んでいてわかりました。
前述のように、当時のフロントエンドの開発者はブラウザ間の差異から来る闇に苦しんでいました。生のJavaScriptではなくjQueryを使うことで、ブラウザ間の差異を吸収してくれ、どのブラウザでも同じように動作するJavaScriptを生成することができました。
サイ本にjQueryの章が約70ページもあるところを見ると、ブラウザ間で実装がバラバラだったJavaScriptを使う上で、jQueryがいかに重要な役割を担っていたかがわかる!
— gami@しがないラジオ (@jumpei_ikegami) 2018年5月3日
また、JavaScriptやブラウザ自体の機能がまだ脆弱だった頃、jQueryは強力なAPIをどんどん追加していき、JavaScriptができることを広げていったようです。
サイ本のjQuery章読み終わったけど、改めてjQueryは高機能かつAPIが強力すぎてすごいな。animationのqueue機構とか、ajax周りとか、強すぎる。逆にjQueryに頼りすぎてカオスになるという意味で、危険さを実感した。
— gami@しがないラジオ (@jumpei_ikegami) 2018年5月5日
jQueryのAPIを覚えるだけで、ブラウザ互換性に配慮した動的なWebページを開発することができるとなれば、これほど使われるようになるのも必然でしょう。
ただし、現在では前述のようにブラウザ間の差異を前ほど意識せずにフロントエンド開発ができる環境が訪れつつあり、jQueryが果たした本質的な役割の意義が薄れつつあります。
また、jQueryのようなDOMへの要素挿入を中心としたアプローチではなく、宣言的なViewの管理によって要件を実現するVue.jsなどのJavaScriptフレームワークが、保守性などの観点から流行しています。一般にVue.jsなどが管理しているDOMを後からjQueryで書き換えるとアプリケーションがぶっ壊れるので、脱jQueryを進めるWebページやWebアプリケーションが増えている印象です。
サイ本. 13.4「互換性と相互運用性」で当時のIEとMicrosoftがディスられている. JavaScriptの方言が強すぎた時代の通訳として、jQueryの価値が高かったのだろう. ESの標準化と実装差異の縮小とBabelの利用が進んだ現代においては、jQueryの通訳としての価値は無くなった.
— gami@しがないラジオ (@jumpei_ikegami) 2018年3月13日
もしも『JavaScript 第7版』が出版されたら、きっと『第19章 jQueryライブラリ』は無くなっているでしょう。
ブラウザにはワクワクする機能がたくさん追加されている!
サイ本の最終章である『22章 HTML5 API』では、以下のように当時では比較的新しかったAPIの仕様に関して言及されています。
- 履歴管理
- クロスオリジンメッセージング
- Web Workers
- Geolocation
- IndexedDB
この本では「未来のAPI」のように語られているこれらのAPIですが、例えば「履歴管理」はSPAで戻るボタンを押せば当たり前のように機能しますし、Web Workersの1つであるService WorkersもついにiOS Safariで対応され、主要ブラウザ全てでPWAのキャッシュやプッシュ通知に使われ始めています。
ブラウザの仕様が目まぐるしく変わることで、そのキャッチアップが大変であったり、多くの負債が生まれたことは、前述の通りです。しかし、逆に新しい仕様が次々と登場することで、ブラウザで実現可能な範囲は毎年広がっています。例えば、「ブラウザ経由で位置情報を特定してその場所に応じたコンテンツを出す」みたいなことも、ブラウザの標準機能で実現できるようになっています。
navigator.geolocation.getCurrentPosition(function(pos) {...});をMac版Chromeのコンソールで実行したら、かなり詳細に緯度経度特定されてびびった。サイ本を信じるならGPSが無くてもIPアドレスや検出可能な無線LANから特定するらしいけど、PCでもここまで特定できるのすごいな!
— gami@しがないラジオ (@jumpei_ikegami) 2018年6月24日
また、この本に書かれた後に登場してきた新しい仕様によって、以下のような世界が当たり前になっていくかもしれません。
- WebAssemblyで、C言語で書かれた世界中の資産がブラウザ上から使える
- Payment Request APIで、ブラウザに登録しておいた支払方法や配送先を選ぶだけでブラウザ経由で決済できる
- Web Publicationsで、HTMLで書かれた文書をそのまま電子書籍として閲覧、出版できる
JavaScriptを取り巻くエコシステムについて学び続けていると、そんなワクワクする話題がたくさん登場して、とても楽しい毎日を送れます。
この本について
ここまでサイ本を比較的ボジティブに解説してきましたが、正直に言って、JavaScriptを勉強したい多くの人には、この本はあまりおすすめではありません。『JavaScript 第6版』自体がかなり古くなっていて、最新のJavaScript事情を反映できてないからです。また、リファレンス的に利用するならまだしも、全章を読破するには、JavaScriptを記述する上では不要な内容が多い印象があります。
僕もJavaScriptを学び始めた当初は、サイ本より先に、『開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質』という本を読みました。
開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質
- 作者: Cody Lindley,和田祐一郎
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/06/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
こちらの本の方が、JavaScriptのハマりポイントである以下のような点について、たくさんの例を交えて簡潔に記述されています。
- プリミティブ型とオブジェクト
- this
- スコープとクロージャ
- プロトタイプ継承
JavaScript初心者が中級者に上がるための本としては、こちらの『開眼! JavaScript』の方をおすすめします。
また、リファレンス的に利用するにしても、MDN Web DocsにJavaScriptの最新仕様やブラウザ互換性についてよくまとまっているので、そちらの方が使い勝手としては良いでしょう。
「サイ本がこれだけ分厚いなら、JavaScriptのより低レイヤな領域についても記載があるだろう」と思う人もいるかもしれないですが、特にメモリ管理の話とかも出てこないです。
なので、仮に『JavaScript 第6版』を勧めるとしたら、「ある時点でのJavaScriptの仕様を、その歴史も交えて体系的に知りたい」人に対してのみになるかと思います。もしそのような奇特な人がいたら、ぜひ挑戦してみてください。
最後に、改めてサイ本こと『JavaScript 第6版』の目次を掲載します。
- 訳者まえがき
はじめに
1章 JavaScriptの概要
- 1.1 コアJavaScript言語
- 1.2 クライアントサイドJavaScript
第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章 式と演算子
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章 関数
- 8.1 関数の定義
- 8.2 関数の呼び出し
- 8.3 関数の引数と仮引数
- 8.4 値としての関数
- 8.5 名前空間としての関数
- 8.6 クロージャ
- 8.7 関数のプロパティとメソッドとコンストラクタ
- 8.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章 正規表現パターンマッチング
11章 JavaScriptのサブセットと拡張
- 11.1 JavaScriptのサブセット
- 11.2 定数とスコープ付きの変数
- 11.3 分割代入
- 11.4 反復機構
- 11.5 簡易表記関数
- 11.6 複数のcatch節
- 11.7 E4X:ECMAScript 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の制御
17章 イベント処理
18章 HTTPの制御
- 18.1 XMLHttpRequestの利用方法
- 18.2
<script>
によるHTTP制御:JSONP- 18.3 Server-Sent Eventsを使ったComet
19章 jQueryライブラリ
20章 クライアントサイドストレージ
- 20.1 localStorageとsessionStorage
- 20.2 クッキー
- 20.3 IEのuserData永続化機構
- 20.4 アプリケーションストレージとオフラインWebアプリケーション
21章 メディアとグラフィックの制御
- 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 〜初級者向け〜に参加してきました!
しがないラジオのgamiです。
今後のキャリアの選択肢の1つとして、DevRel(開発者向けPR)活動関わることに興味があるので、DevRel Meetup in Tokyo #31に参加しました!
若干ビジネスイベント感があって、最初に全員のテンション高めの自己紹介から始まるのに戸惑いましたw でも、エンジニア向けの勉強会とは雰囲気が違って面白かったです。
DevRelの基本とマーケティング戦略 by MOONGIFT 中津川篤司
自己紹介
- MOONGIFT代表
- いくつかの会社のエヴァンジェリスト
DevRelとは?
- Developer Relation
- PR(Public Relation)の開発者版
DevRel活動
- セールスをするのではない
- 認知度やマインドシェアを上げることで、土俵にあげてもらう活動
なぜ開発者?
- 開発者は広告を一切見ない
- 高ITリテラシー
- ソーシャル、ブログでの拡散率が高い
- 第三者が公平に書いたブログは、CVRへの寄与度が高い
- 穴を売るな、ドリルを売れ
- 体験を売るべき
- 自社製品の新しい魅力を生み出す
製品採用のステップ
- その技術を調べる
- 課題解決できる製品を並べる
- Googleの検索結果に出てくることが重要
- 各製品の情報を調べる
- 検証する
- 購入する
注意点
- 中長期的な戦略として実施する
- 外資系の企業は、すぐに方針転換するw
- すぐに効果は出ないので、続けることが重要
- KGI/KPIをきちんと定めておく
- 数字を出せないと、上を説得できない
DevRelのマーケティング戦略
開発者主体で考えた分析軸
ペルソナ決め
ペルソナを決めると?
- 本当に必要な機能がわかる
井の中の蛙になる
- 小さな市場でトップシェアになることが重要
- そこから、市場を拡大する
AARRR分析
- DevRel的には、最初にAwarenessを、最後にProductを付ける
フォーカスを決める
- 新規獲得?Churn Rate?
- 収益?利用者拡大?
- 認知度向上?
- 非アクティブユーザーの活性化?
アクション評価シート
- AAARRRPモデルのどこに引っかかるのかを、スプレッドシートで管理
施策判断
施策の決定
- ローリスク、ハイリターンの追求をする
- 効果がすぐに出るものではないので、低予算で長く続ける
- 基本は、ユーザー単価で判断する
- PVは水増しできる
- 「登録したらプレゼント」をしても、変なユーザーしか増えない
DevRelのABCDE
- A: アドボケイト
- B: ブログ
- C: コミュニティ
- D: ドキュメント
- E: イベント
ブログ
- 誰に何を読んで、どうなって欲しいのか?
- ペルソナの課題解決がベスト
ドキュメント
- 過不足ない
- 検索フレンドリー
まとめ
- 技術より情熱、お金より行動
- LTをするだけなら、今日からでもできる!
小さく始めろ、評価は期待するな、理解ある上司を探せ、プロダクト愛を持て! by NTTコミュニケーションズ 仲さん
自己紹介
- @Tukimikage
- SkyWay Teamのテクニカルソリューションズやサポートエンジニア
テーマ
- エンプラ企業でDevRel活動を始める人へ
- NTTコミュニケーションズでSkyWayのDevRel活動をやってきた経験を元に
SkyWayとは?
- Enterprise Cloud WebRTCプラットフォーム SkyWay
- 2013〜トライアル
- 2017〜 正式リリース
- RareJobなどで使われている
SkyWayのミッション
- WebRTCを身近な技術に変える
- 使いこなすためには、幅広い技術領域の知識が必要
SkyWayが提供する価値
- WebRTCを使ったサービス開発のハードルを下げたい
- サービス自体の価値向上に集中して欲しい
開発者に価値提供し続けるためには?
- デベロッパーファーストであり続けることが重要
- DevRelに力を入れている
実践していること
- 情報発信
- ユーザーグループ立ち上げ
- 開発者と開発チームとをつなぐ
- エヴァンジェリスト活動
情報発信
- FAQやサポートコミュニティの運営
- 無償の場合、コミュニティで解決してもらう
- SNSでの情報発信
- GitHubやQiitaでの情報提供
- サンプルアプリの提供
- 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 のびすけさん
自己紹介
- 元LIGエンジニア
- dotstudioを経営
- ものづくり教育事業
今回の対象
- 仕事は仕事で割り切って、業務時間外でやりたいことをやろうと思っている人
LIGについて
Phase1. なんとなく始めたイベントが200人規模になった
- IoTLTという勉強会を主催
- きっかけ
- 「リレーションズのエンジニアを外に出したい」という相談を土屋さんから受けた
- IoTという言葉がバズりそうだったので、始めてみた
- 第1回は、社内勉強会として始める
- リレーションズとLIGの合同社内勉強会
- 気付いたら、述べ1,000人を超える
- いまは、述べ15,000人
Phase2. コミュニティ成長の一方で、目的を見失う
- 当初の目的だった、リレーションズのエンジニアが参加できなくなってきた
- 成長してきたコミュニティを前にして、どうすればいい?
- 続けることで価値を見つけた
- 毎月開催をし続けることで、「すごい楽しかった」「仕事につながった」という声が上がってきた
- 来てくれる人がいるということは、価値があること
- エンジニア向けにやっていたが、IoTに興味がある人なら誰でも集まるコミュニティになった
Phase3. 社内に対する承認欲求との戦い
- 「この活動を会社が後押ししてくれればいいのに」と思うようになった
- とはいえ、「話題になってるから勝手に会社も気付くだろう」とも思って社内共有しなかった
- とある経営者の投稿
- 「影の努力を気づく上司はほとんどいません」
- 「評価をしてほしいなら、その努力を上司ないしキーマンに全力でみせましょう」
- 見えているものでしか、評価はできない
- 社内に対しても、アウトプットが必要
- 社長を勉強会に呼んだ
- 「めっちゃいい会だね」と連呼してもらう
- 海外に行こうか迷ったタイミング
- 海外転勤できなければ会社を辞めようと思った
- 社長に止められた
- 「新しくLIGの中で新規事業を立ち上げないか?」
Phase4. DevRel事業部を立ち上げた
- 「技術障壁が高い」のはもったいない
- 特にIoT領域で、プロモーションのお手伝いをしていく
まとめ
- モチベーションが無くても、続けていれば価値につながる
- 好きなことを業務に持ってくる、この為に社内へのアウトプットは重要
- まず動いてみて、後から振り返ることで自分のやりたいことが見つかる
Phase5. おまけ: LIGから独立しました!
- dotstudioを立ち上げ
LT: システムインテグレーターにおける"R"(序)
自己紹介
- Takeki Oizumi
- 元COBOLプログラマから、コンテンツマーケターへ
- セゾン情報システムズ
- STORESというオウンドメディアを運営
SIerにおけるリレーション
- 既存のお客様との関係をイメージする人が多い
- 他にももっとあるはず
- パブリック、メディア、ガバメント、パートナー、デベロッパー...
- 関係性から始まるRAIDMA
関係性の前に
- そもそも、認知してもらう必要がある
取り組み
- オンラインでリーチできる認知可能な情報の積み上げ
- オンラインで検索できない技術は、無いのも同じ
- Pay Forward
- 情報収拾とアウトプットを、とにかく続けること
より詳細には...
最後に
以上で内容については終わりです。
DevRel界隈の常識すら知らない状態で参加したので、内容が新鮮で面白かったです!
全然知らない分野の勉強会に参加するのは、ノリや使っているワードが違うので楽しいことがわかりました。
イベントの様子は、以下のTLから感じられると思います! twitter.com
趣味で『しがないラジオ』を1年続けて、オフ会を開催したら40人も集まって驚いた話
こんにちは、しがないラジオのgamiです。
2018/5/23(水)に、しがないラジオのmeetupを開催しました! shiganai.connpass.com
ありがたいことに、40人もの方にご参加いただき、しがないラジオもよくここまで来たなあという感傷的な気持ちになりました。
何者でもないSIerのSEだった僕が、転職してポッドキャストを始めて、そのオフ会に40人集まって、集合写真の真ん中に写ってるの、客観的にみてすごい話だ!
— gami@しがないラジオ (@jumpei_ikegami) May 23, 2018
本当に、ゲストやリスナーの皆さんのおかげでここまで来られました!ありがとうございます! #しがないラジオ #しがないラジオmeetup https://t.co/VDQrDWXqzA
当日の写真は、僕に消されるまで以下から見られます!
shiganai radio meetup - Google ドライブ
しがないラジオとは?
僕が新卒で入った富士通を1年半で辞め、株式会社プレイドというスタートアップに転職をしたのが2017年11月。
その4ヶ月後の2017年3月から、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」(略して「しがないラジオ」)というポッドキャストを富士通時代の同期のズッキーと始めました。
最初は2人がたわいもないSIer批判話をしたり、趣味や気になる技術の話をするだけのポッドキャストでした。 そこから、少しずつ知り合いをゲストを呼び、そのゲストの知り合いが聞いてくれるようになり、直接知らなかった人もゲストに呼び、またそのゲストの知り合いが聞いてくれて。
そんなわらしべ長者方式で、ゲストとリスナーの輪が広がっていきました。
実はホスティング先のSoundCloudを見ると、毎回のエピソード毎の再生数がわかります。 始めた頃は1回のエピソードが100再生を超えれば大喜びしていましたが、最近のエピソードはその10倍の1,000回再生を超えて聴かれています。
これからもどんどん盛り上げていきたいですが、思えば遠くまで来たなあ、という感じです。
オフ会を開催した経緯
実は、2017/12/18(月)に「しがないラジオ忘年会」というイベントを開催したことがありました。 shiganai.connpass.com
過去のゲストさんを中心に10人くらい参加して、公開録音したりLTしたり飲み会したりしました。
そんな忘年会を無事終えた後で、今回のmeetupを公募して開催しようと思ったきっかけは、リスナーさんの1人であるいけさんに背中を押されたからでした。
今日とあるイベントで、しがないラジオAdvent Calendarの14日目を書いてくれた"いけさん( @otty_375 )"とリアルでお話ししたけど、「 #しがないラジオ 忘年会行けなかったので、オフ会やってほしいです!」って言われた. 嬉しいので、やろうかなあ.https://t.co/VrRDIXsmqG
— gami@しがないラジオ (@jumpei_ikegami) February 25, 2018
会場の規模を決めるために、実際どのくらい来るのかTwitterで確認してみると、30-50人くらいは来てくれそうなことがわかりました。
時期は未定ですが、 #しがないラジオ のオフ会(たぶんLT大会)の需要を見たいので、「参加したい!」という人は、このツイートに『いいね』してください!
— gami@しがないラジオ (@jumpei_ikegami) February 25, 2018
多くのリスナーさんにリーチできるように、リツイートも歓迎です!
めでたく開催が決定した瞬間です!ポッドキャストの相方のズッキーには、ほとんど相談せずに勝手に決めましたw
#しがないラジオ オフ会ですが、いいね数を信じると30人規模くらいにはなりそうなので、開催の方向で動きます!初回は4月くらいかなー
— gami@しがないラジオ (@jumpei_ikegami) February 26, 2018
都内で30人規模の会場に心当たりのある人は、gamiまでご連絡ください!
オフ会の準備
オフ会の準備は、主に以下をしました。
会場の予約
会場は、サポーターズさんのご好意で、レンタルスペースを無料で貸していただきました!
会場費がかからないだけで、参加費がグッと抑えられるのですごくありがたかったです!
お酒とお菓子の注文
お酒とお菓子は、カクヤスで注文しました。 お酒は予定参加人数に対して1.5本/人くらいのお酒を注文したら、若干足りないくらいでした。
名札の購入と印刷
オフ会という性質上、ネット上のアカウントとリアルの人間の紐付けが楽な方が話が盛り上がるはずです。
ということで、てぃーびーさんに教えてもらって、@yoshiko_pgさんが公開している「参加者の名は。」というWebサービスを使いました。
connpassのイベントページURLを入れると、予約している人のプロフィール画像と名前を見て、名札サイズのpdfを出力してくれます。 控えめに言って最高でした。
もらった! #しがないラジオmeetup pic.twitter.com/pxkFXT412R
— ひかっち (@hikacchy) May 23, 2018
オフ会当日
オフ会当日は、富士通時代の同期でWeb系企業のデザイナーに転職したみっつんさんが写真を撮ってくれました!感謝!
当日の写真は以下から見られます!
shiganai radio meetup - Google ドライブ
オフ会当日の様子は、以下のTogetterや参加者の皆さんのブログをご覧ください!すごいたくさんブログ化されてて、本当にありがたいです!
以下、独断と偏見で、エモいTweetだけ抜粋します!
自分の発表が終わって15分、ようやく緊張が取れてきた…😇 聴いていただいたみなさんに感謝 #しがないラジオmeetup
— いけ (@otty_375) May 23, 2018
実は #しがないラジオmeetup をやろうと決めたのも、いけさんにイベントで会って「オフ会とかやってくださいよー」と言われたことで、背中を押されたからでした!背中を押したら、自分の背中に返ってきた!すごいいい話だ! https://t.co/W5pdXLQHJM
— gami@しがないラジオ (@jumpei_ikegami) May 23, 2018
いろんな方のおはなしをうかがっているとは、アウトプットしなければ……!と強い気持ちになる #しがないラジオmeetup
— とばち (@toda_kk) May 23, 2018
新卒で会社入る直前(2017/03)に #WeJS でしがないラジオを知ったけど、そのときからは考えられない人の集まり方だった #しがないラジオmeetup
— mascii (@mascii_k) May 23, 2018
すごく楽しかった!懇親会がこんなに盛り上がってる集まり初めて。二人の人柄あってのこのコミュニティですね。改めてエンジニアで良かったなと思いました。おつかれさまでしたー! #しがないラジオmeetup
— Shogo Mizuno (@nesheep5) May 23, 2018
昨日の #しがないラジオmeetup では色んな人と話せて、本当に刺激をもらった!改めてこのような会、コミュニティの場、パーソナリティのお二人、皆さんに感謝です!
— くろたろう (@7coAim) May 24, 2018
このブログ記事の末尾に書いておいた #しがないラジオmeetup 、参加登録者の出席率が9割越え?の大盛況でしたね。パーソナリティ、スタッフ、LT登壇者、参加者もみなさまありがとうございました! https://t.co/aRED72d5sL
— 駒戸(こまど) (@ky_yk_d) May 23, 2018
楽しかった!
— はっせー @七夕の国 (@Dear_you_cry) May 23, 2018
僕が聞いた回のゲストの方、僕の回を聞いていただいてる方と話せた貴重な会でした
(非公式な二次会から帰宅中)
#しがないラジオmeetup
受付した瞬間にシス管系女子のステッカー貰い大満足して、ズッキーさん&ガミさんや他の出演者って本当に実在するんだってなり、LTもすげー盛り上がるし誰と雑談しても楽しかったです!
— takech1 (@shuntakeuch1) May 23, 2018
パーソナリティや運営の方、参加者含め本当にありがとうございました。
#しがないラジオmeetup
まさにですね!#しがないラジオmeetup 控えめに言って最高に刺激受けました✨
— 湊川🌱わかばちゃんと学ぶGoogleアナリティクス発売中 (@llminatoll) May 23, 2018
めちゃ楽しかった。パーソナリティーの2人が参加者みんなに声かけてくれて、ゲストのみなさんを中心に輪ができる。まさにしがないだったなー。
— gohh56 (@gohh56) May 23, 2018
定期的にあるとよいなー。
#しがないラジオmeetup
皆さま、本当にありがとうございました!
— zuckey@しがないラジオ (@zuckey_17) May 23, 2018
普段感想をつぶやいてくださる方もそうでない方も、いろいろな人とお話しできて嬉しかったです😊#しがないラジオmeetup #しがないラジオ pic.twitter.com/I9yqgy6tie
@zuckey_17さんの「「#しがないラジオmeetup 1 」まとめ」が1000viewを超えたみたいだよ。すごいな、みんなが見てるってことだね。 https://t.co/cyD2DuW1us
— まとめのお知らせ (@togetter_pr) May 28, 2018
収支
実は、今回の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にブログ枠で参加してきたので、その模様をお伝えします!
着席しました! #nuxtmeetup
— gami@しがないラジオ (@jumpei_ikegami) 2018年5月15日
当日は、主催の@kotamatsさんの挨拶で乾杯し、お酒を飲みながらLTを聞きました。
乾杯して始めるので来た方は一人一つ持っていってください! #nuxtmeetup pic.twitter.com/wgK513X3YI
— kotamat Laravue NuxtMeetup (@kotamats) 2018年5月15日
スポンサーLT Welcome to Nuxt Meetup @andoshin11
#nuxtmeetup スポンサーLT! pic.twitter.com/W8T4NTUDxh
— kotamat Laravue NuxtMeetup (@kotamats) 2018年5月15日
自己紹介
- Andy(@andoshin11)
- 3月からメルペイのフロントエンドエンジニア
- Vue.jsがメイン
- React NativeやRailsも
merpeyの紹介
- 信用を創造してなめらかな社会を創る
- 株式会社ソウゾウの次の子会社
- 「人々の新しいお財布」を目指している
- お金の入り口と出口をつくる
- Nuxt.jsをmerpeyでも使っている
Nuxt+TypeScript事始め @sue__71
#nuxtmeetup メルペイさん! pic.twitter.com/45yLAJ2rup
— 炒飯コンドウ|SCOUTER人事🍺 (@sithkng) 2018年5月15日
自己紹介
- merpay webフロントエンドiOS
- ソリューションチーム
- 技術課題を解決するチーム
今日はなすこと
- VueのTypeScriptの対応状況
- Nuxt+TypeScriptの対応状況
TSの特徴
- 静的型付け言語的にJavaScirptがかける
- 後付けで型定義がかける
TSのメリット
- Type Safe
- コンパイル時に検証できる
- Less test / documentation
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にする- 暗黙的なthisへのマッピングを解決
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
今日はなすこと
- 技術選定の話
サイト
- 地域のお店を紹介するサイトをリニューアルしたい
- 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の問題点
- 費用
- ホスティング先
- cloud functionsも、管理コードが増える
Hostingを探した
- now.sh
- Realtime Global Deployments
- zeitという会社が作ってる
- Next.jsを作ったところ
- CLIだけでdeploy可能
- Nuxt.jsでつくったものは、そのままnow.shにdeployできる!
- staticに戻すときも、そのままある
now.shのデメリット
全体の反省点
- 自分は楽だが、引き継ぎが大変
- Firebase依存の結果node_modulesが増えた
初の勉強会にて初LTをする初心者エンジニアのお話 @hirokinishizawa
自己紹介
- 22才
- 独身
- 初心者
- 3ヶ月前に初めてコードを触った
- それまでは、屋上防水をしていた
仕事
- 2週間、プロゲートで勉強
- Nuxtを使って、メディアやLPの作成
- 人材紹介マガジン
- SCOUTER
テーマ
- 初心者がどのようにメディアの作成を進めていったのか
step1 コンポーネント毎にプレビューを確認
- デザインとにらめっこして、パーツに分ける
- Componetsに各パーツ毎のVueファイルを作った
- StoryBookで、Components一覧を確認
step2 一つのまとまりにするために
- Pages内に、今まで作ったコンポーネントをimport
- ヘッダーや記事が表示される
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
自己紹介
- Ryosuke Suzuki
- 明治大学4年
- Plaidでインターン1年目
- 大学でDeep Learning
- 日常でWeb Developer
今日の話
- 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不要説
なぜSSRか?(再)
- グローバル水準
- エンジニアの知的好奇心を満たす
- どやりたい
- 常に先端にいたい
- 「SSRは必要か不要かではない。やるかやらないかだ」
構成
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
- Static Site Generators for JAMstack Sites
- 静的に書き出した方が楽だよねー
- ランキング上位は、JSがほとんど
ReactやVueの静的サイトジェネレーター
- React
- gatsby
- next.js
- Vue
- nuxt.js
- vuepress
データソース
- VuePress
- config
- .js -> $site
- data
- .md -> $page
- config
- Nuxt+Nuxtent
- data
- .md -> .json
- webpackのassetとしてemit
- data
- Gatsyby
パフォーマンス
- リンク先リソースの先読み
- 画面に表示されている領域を先読みできる
すごいところ
- データソースの一元化
- GraphQLで統一化されたクエリ
- 超速(ちょっぱや)にかける意気込み
Guess.js
- マシンラーニングで先読みを予測
- "Plese support Vue.js"というissueはある
未来へ
- Nuxtももっと超速(ちょっぱや)になる!
誰だったのか?
- @miyaoka
- soussuneというポッドキャストをやってます
いまからはじめるnuxt-edge @potato4d
自己紹介
- VueやったりNuxtやったり
nuxt-edgeとは?
- Nuxt2 is coming! oh year!という記事で紹介
- 要はNuxt v2のEarly Access edition
機能
- 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から追えると思います!
「イヌでもわかるウェブフォント」を読んで、こだわりのフォントをWebサイトで使おう!
#しがないラジオパーソナリティのgamiです。
2018/04/22(日)に、秋葉原UDXで開催された技術書典4に行って来ました!
今回は、戦利品の1つである『イヌでもわかるウェブフォント』の感想を書きます。
「エンドユーザーの環境によってフォントが変わるなんて許せない!」という人は、ウェブフォントを使うことで悩みが解消されるかもしれません。
ちなみに、著者であるtakanoripさんは、前にしがないラジオのゲストとしてご出演いただいたことがあります!
のりぴーさんとの収録後の様子です! #しがないラジオ pic.twitter.com/xtv80fNfux
— gami@しがないラジオ (@jumpei_ikegami) 2018年4月19日
「イヌでもわかるウェブフォント」
本書は、特にウェブフォントの最適化の部分でかなり実践的な内容に踏み込んでいます。
ウェブフォントの導入に対する最も大きな反対意見は、「ウェブフォントを使うとサイトのレンダリングが遅くなる!」でしょう。適切な最適化をすることによって、エンドユーザーの体験を損なわずにウェブフォントを使うためのテクニックが紹介されています。
- フォント自体の軽量化
- preload
- HTMLレンダリングより前にフォントファイルを読み込んでおく
- キャッシュ
- フォントの読み込みが遅延/失敗した場合のフォールバック
フォント戦士の味方、「武蔵システム」
本書で紹介されているウェブフォントの最適化をいくつか試してみました。
まず、フォントの軽量化です。 フォントファイル自体を軽くするためには、主にフォントのサブセット化と、WOFF2対応をします。
それらを実現するソフトウェアとして、以下の2つが紹介されています。
どちらも、武蔵システムという硬派な名前のシステム会社が提供しているフリーソフトです。Windows版だけでなく、Mac版もあります。
どうでもいいですが、武蔵システムの会社情報のページに掲載されたメールアドレスは、font@opentype.jp
でした。強いフォント愛を感じます。
フォントの軽量化と聞くと難しそうですが、これらのソフトウェアのおかげで非常に簡単にできました。
S3にフォントをアップロード!
独自のウェブフォントを使うためには、サーバーにフォントファイルをアップロードする必要があります。 著者のtakanoripさんオススメのフリーフォントの1つである「チェックポイントリベンジ」をS3にアップロードして使ってみました。
Macでフォントをいじったことがある人にはお馴染みの宮沢賢治作『ポラーノの広場』を、HTMLにコピーして表示してみます。
#イヌでもわかるウェブフォント 読んで、ウェブフォントをS3に上げて試しに使ってみたけど、普通に簡単!軽いフォントなら500KB以下だし、キャッシュ効かせれば特に問題なさそう。フォント次第でだいぶ印象変わるので、特に尖ったフォント使いたい場合はウェブフォント使うべき。 pic.twitter.com/hK97jjXz25
— gami@しがないラジオ (@jumpei_ikegami) 2018年4月30日
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タブを見てみます。
HTMLやCSSの後にフォントが読み込まれていることがわかります。
preload有り
続いて、preloadを設定して、キャッシュを消して再読み込みしてみます。
見事に、CSSファイルなどと並行して読み込まれています。これで、初回ロード時もテキストの表示がかなり速くなるのではないでしょうか?
まとめ
日本語話者として育ったからには、日本語フォントと向き合わなければいけません。漢字がたっぷり詰まった日本語フォントは、10MB以上になることもあります。
そんな重いウェブフォントでも、「イヌでもわかるウェブフォント」を読んで、サブセット化をはじめとする最適化を少しするだけで、かなり軽く速くなりました。
この記事で触れた内容以外にも、フォントが描画されるまでのブラウザの処理の流れなど、かなり踏み込んだ内容も本書には掲載されています。
ウェブフォント触りたいけどどうすればいいかわからん!という人は、ぜひBOOTHから電子版を購入してみてください! booth.pm
また、しがないラジオで著者のtakanoripさんにフォント愛を語っていただいた回があります。ぜひお聞きください!(宣伝)
sp.26b【ゲスト: takanoripe】楽しいフォントマニアのフロントエンド談義を公開しました!!
— shiganai radio (@shiganaiRadio) 2018年4月22日
のりぴーさん(@takanoripe )をゲストにお迎えして、差分納品、ReactとVue、Nuxt.js、SSR、GraphQL、フリーフォント、などについて話しました。https://t.co/RE3jAAeAn1#しがないラジオ