がみぶろ

#がみぶろ

@jumpei_ikegami

技術書典5で、『完全SIer脱出マニュアル』という本を出します

f:id:jumpei_ikegami:20180922182207p:plain

こんにちは。 明日、2018/10/8(月)に開催される技術書典5「お27」ブースで、『完全SIer脱出マニュアル』という本を頒布します。

techbookfest.org

何でこの本書いたの?

技術書典4に一般参加して、知り合いが本を出しているのを見て「楽しそうだなー」と思ったのがきっかけでした。 さっそく技術書典5のサークル登録をしてから「自分にしか書けないことって何だろう?」と考えた結果、思い至ったのが「レガシーな環境からモダンな開発現場に転職して楽しく働くためのノウハウ」でした。

果たしてそれは「技術書」なのかという葛藤はありましたが、 技術書典公式のFAQにも、技術書の定義について「ITや機械工作とその周辺領域について書いた本」と結構広く書かれているし、「情熱プログラマー」みたいなライフスタイル系の本も技術書的な扱いを受けているので、この本も「情熱プログラマー」枠だと自分に信じ込ませて書きました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

で、お前誰よ?

gami(@jumpei_ikegami)と申します。 新卒で某大手SIerにSEとして入社したあとで、SaaSスタートアップにエンジニアとして転職しました。 転職後は、開発とかクライアントワークとかもしつつ、エンジニアの中途採用に関わって主に書類選考や一次面接をガシガシ担当しています。

また、趣味で「しがないラジオ」というTech系ポッドキャストを運営しています。 様々なゲストの方をポッドキャストに呼んでそのキャリアについて話を聞いているので、 特に若手エンジニアのキャリア選択に関する知見がバシバシ溜まっています。

ちなみに、この『完全SIer脱出マニュアル』はポッドキャストの相方であるzuckey(@zuckey_17)と共同執筆しています。

こんな人にオススメ

本の中にも書いている想定読者は、以下のような人です。

  • SIerやSES企業でSEや開発をしていて、毎週⽉曜⽇の朝に仕事に⾏くのがつらい⼈
  • いまよりもっと楽しく働きたいエンジニア

特に、「仕事が楽しいとか言ってる人のことが信じられない」とか、「我慢してつまらない仕事を続けなきゃいけないのは自分に技術やスキルが無いからだ」と思っているかつての僕みたいな人に読んでもらいたいです。

この本で伝えたいこと

この本で伝えたいことは、主に3つです。

  • 「楽しい仕事」というのは本当に実在する
  • 少しの努力や考え方のシフトで、「楽しい仕事」にも意外と手が届く
  • あなたの人生は、あなたの決断次第で良い方向に変えられる

ともすると意識高い系みたいな話になりがちであれですが、「自分に全く自信なかったけど、転職して楽しく働いてます」みたいなエンジニアと少なくとも10人以上はリアルで出会った上で書いてるので、けっこう実態に即していると思います。

タイトル燃えそうだけど大丈夫?

『完全SIer脱出マニュアル』というタイトルをSIerで楽しく働いている人が見たら、確かに悲しみや怒りが湧いてくるかもしれません。 しかし、それ以上にメリットが大きいと考えて、あえて燃えそうなタイトルにしました。

  • 「エンジニア労働市場への誤解や自身への過小評価によって能力を最大限発揮できていない人」が、あまりにも多い印象がある
  • しかし、この本を本当に届けたい人のほとんどは、技術書典を知らない
  • この本が炎上でも何でもしてインターネットで話題になれば、そんな人にも届くかもしれない

僕は楽しく働く人を増やしたいと考えています。 みんな楽しく働いた方が面白いモノが生まれやすいし、巡り巡って僕の人生にとってもプラスだと思うからです。 そんな訳で、話題になるための炎上なら、どんとこいです。

推しポイント

この本の推しポイントは、以下です。

  • 初めてのエンジニア転職でよくある疑問に答えています
    • 楽しい仕事とか、本当にあるの?
    • 若いうちに転職するのって、デメリットあるの?
    • ベンチャー企業って怖いの?即戦力しか要らないの?
    • いま技術力が無い人は、エンジニアとして雇ってもらえないの?
    • 「成長」って必要?
  • モダンな開発が未経験な状態からエンジニアとして転職をするための具体的なアクションを、7つのステップに分けて細かく解説しています
  • 一般論で終わらないために、各ステップについて実際に経験したエンジニアが話している「しがないラジオ」のエピソードを逆引き形式で紹介しています

詳しくは目次をご覧ください。

f:id:jumpei_ikegami:20181007093956p:plain

f:id:jumpei_ikegami:20181007094016p:plain

また、執筆裏話については「しがないラジオのep.32」でも話しています。

まとめ

僕も技術書典5の「お27」で売り子しているので、ぜひお会いしましょう!

以下、ワクワクが止まらない僕のTweetで締めくくります。

「人を知ること」が重要になったいま、なぜ「普通の個人」が輝く時代になったか? #CXDIVE

f:id:jumpei_ikegami:20180904230146p:plain gamiと申します。PLAIDという会社で、「CX(顧客体験)プラットフォーム KARTE」の開発や提供にまつわる仕事をしています。 プライベートでは、「楽しく働く人を増やす」ことを目指したポッドキャストしがないラジオ』のパーソナリティをしています。

今日は「CX DIVE」という最高なイベントに参加してきました。 cxdive.com

PLAIDが主催のイベントなので僕は完全に関係者なのですが、普通に参加者として行ってきて普通に得るものが大きかったので、個人のブログで感想を書きます。

CX DIVEは、CX(顧客体験)の今とこれからを考えるイベントで、セッション形式で12名の登壇者がテーマに沿ったトークをします。

僕はミーハー心でゆうこすさんやハヤカワ五味さんのセッションを聴いたのですが、その話の内容や2名の生き方から得られる気付きが多かったので、そこを中心に書いていきます。

女性の「モテたい」気持ちを全力で応援する24歳

ゆうこすこと菅本裕子さんは、HKT48脱退後に大きな挫折を味わい、そこからSNSをフル活用してフォロワーを増やしたクリエイター。 「モテクリエイター」を名乗り、各種SNSや動画配信サービスで女性がなりたい自分になるための情報発信をしています。

CX DIVEのセッションでは、自分のファンを分類してそれぞれに向けた発信方法を考える、新規流入向けとコアなファン向けでメディアを意図的に使い分ける、など、ファンを増やすための非常に具体的な方法論を語っていました。

twitter.com

元々は男性ファンが多いアイドルだったところから、今では圧倒的多数の女性ファンを抱え、累計フォロワー数150万人を突破したとのことで、個人とはいえ完全にマーケティングのプロという感じです。

また、「インスタ世代は『ググる』のではなく『タグる』(タグで情報を手繰り寄せる)」という話から、インスタのview数を増やすためのタグの重要性についてつなげていて、納得感がすごかったです。

僕はギリギリ20代ですでに若者文化から取り残されているので、ものすごく勉強になりました。

ゆうこすさんについては、僕も大好きなmilieuというメディアのインタビュー記事がとてもわかりやすいです。

milieu.ink

コンプレックスのある女性のためのファッションブランドを経営する23歳

ハヤカワ五味さんは、19歳で株式会社ウツワを設立した経営者。

胸が小さいことを「貧乳」と呼ぶのは間違っているという思いから「シンデレラバスト」というポジティブな呼び方を提唱し、シンデレラバスト専門の下着ブランドを運営しています。

ハヤカワさん自身もコンプレックスを抱いていたことから、同じような悩みを抱えた女性に届けたいプロダクトを作って販売しています。

CX DIVEのセッションでは、地域や世代で異なる「色眼鏡」をテーマに、マーケティングの文脈でも「事実より、知覚されたものが重要」であることを、具体的な事例を交えて話していました。

例えば、日本人の多くは「欧米人への憧れ」を抱いておりアパレル系のメディアに欧米人モデルが多いですが、中国では全くそんな「色眼鏡」は無いので日本と同じ感覚だと爆沈する、という話をされてました。 そこまで違うのか、という例が多く、学びが大きいです。

特に面白かったのは、「好景気眼鏡」として紹介していたバイアスでした。 好景気の時代を生きてきたおじさん達は無邪気に「最近の若者は欲がなくて、車も買わない」とか言いますが、普通に収入は減って支出は増えてるので、よっぽど好きじゃ無いと買わねえよ(意訳)、とバッサリ切り捨てていました。

ついつい、日本や自分が「普通」だという前提でモノを売ろうとしてしまうけれども、同じものを見ても意外とみんな全然違う感じ方をするんですよ、という話でした。

「バイアスなんて無い」という認知そのものがそもそもバイアスである、というメタ的な構造もまた面白かったです。

ハヤカワ五味さんについては、少し古いですが以下のインタビュー記事がよくまとまっていました。

news.yahoo.co.jp

なぜ中年たちはこぞって彼女達の講演を聞きに来るのか?

とても優秀だとはいえ、ゆうこすさんは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版』という鈍器、もとい書籍を読みました。

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さんにフォント愛を語っていただいた回があります。ぜひお聞きください!(宣伝)