5/18(土)に開催されたJJUG CCC 2019 Springに参加してきました。
その時のメモを復習がてらまとめてます。

資料まとめサイト

有志の方がセッション資料をまとめてくださっています。
https://sun0range.com/event-report/jjug-ccc-2019-spring-time-table

10:00~ 初めてのgRPC

• 資料：https://speakerdeck.com/line_developers/starting-grpc

  • 発表資料にサンプルコードがちょこちょこ書いてたので資料の充実さがすごい

• Swaggerからソースを自動生成できるけどなんだかんだ手を入れる必要がある

  • 仕様に変更会った時再生成したらまた編集しないとでしんどい。。。
• protoファイルは基本的にいじらないから楽？
• messageとかserviceとかprotoファイルの定義が必要だけど書き方がJavaのクラスとかIFっぽい
• gradleでプラグイン入れれば使える
  • オプションで細かいこと設定できるけど割と読み解くのが大変だったらしい
• Stubは3種類あるけど全部使おうとすると大変だから基本はBrockingStubを使えばいける
• 引数、戻り値にstreamをつけることで複数のデータ送受信ができる！
  • streamつけるとちょっとコードがめんどくさくなるらしい。。
• 1:1、1:複数までは割と実装しやすいけど、クライアントから複数渡す形式は実装がややこしい
  • そもそもクライアントから複数通信ってあんまり使わない。。。
• stream処理を書くための拡張みたいのは色々でてる
• ブラウザからはREST、内部だけgRPCで通信が良さげ？
• Spring bootとgRPCを合わせて使うライブラリが2つほどあり、実際に使うならその辺を使うのが現実的っぽい
• リバプロ型、クライアントサイド型とかもあるけど、サービスメッシュ型が最近は流行りっぽい
• 割といろんな仕組み使わないといけないから、マイクロサービスとの相性はよさげではあるけど、実装時点ではJava Servletレベルのエコシステムしかないから結構しんどいかも。。

感想

マイクロサービスを実際に作ってRESTで苦労した経験がそもそもないのでありがたみについてはあまりイメージできなかったです……
ただ、マイクロサービスの内部もRESTでカッチリやろうとすると消耗するみたいな話はよく聞くので、手段の1つとしては覚えておきたいところ。

11:00~ 大企業運営の法人向けサービスにおけるOpenJDK移行事例

• 資料：https://slides.com/hiroyuki_onaka/jjug-ccc-2019-spring/#/

• SIerの立場での発表！

• 単純な話JAVA_HOMEとかをきりかえる”だけ”
• RHEL系の話
• Apache FelixがOpenJDK11.0.1⇨11.0.2でバグ
  • リリースノートが提供されるようになったのは11.0.3からなので見れない。。。
  • コミットログとかを追った
    • 今後はトラブルが発生した時にOSS的に問題を切り分けてく必要がある！
      • Issueとかコミットログとか
• 芋づる式に地獄のバージョンアップ
  • OpenJDK以降の時にDBバージョンアップする必要が出てくる。。。
  • Tomcatのserver.xmlとかも。。。
• OS側がJDKを動かすための依存がOracleJDKとOpenJDKだと違う(OpenJDKのが多い)
• 通信相手のTLSアルゴリズムが古すぎると使えなくなる。。。
• インフラ周りを放置しすぎてると地獄
  • JDK6&Struts&古いWebLogicとかはやばかったらしい
  • 継続的にインフラをメンテできてればまだ対応しやすい
    • SIerにとって継続的にインフラをアプデできる体制に移行できるのはここが最後ですよ！！

感想

芋づる式のアップデートとか、まったく他人事じゃないよなぁって話でした……
実際今私がいる案件もまだ話は出てないものの、Tomcatバージョンが古かったりStrutsを使っていたり、継続的なメンテができているとはお世辞にも言えない状態なので地獄を見そうですね。

11:25~ 開発リーダー1年目。メンバーのスキルアップのためにやっていること。

• 資料：https://docs.google.com/presentation/d/1Xx5UPJkmy2dgzRloe8zaGGpEPWk1rhLiAMypK4TKRz8/edit

• 正社員2名でパートナー4人でうちでもありそうな構成

• 結局正社員だろうがパートナーだろうがキャリアとか環境に合ってないと思われるとみんなやめてく
• 輪読会、ランチ、夕会や雑談
• 輪読会を実際どのようにやってるか資料に乗ってる
  • うちでも割と有効そう
  • こういう本読んどいて〜とかは結局みんな読まない、とか読んでも内容はイマイチ。。みたいなパターンが多い
  • リーダブルコードとかを使うことで良いコードを意識するメンバーが増えた
• ランチを断る人もいるけど、断れる環境っていいよね
• マネージャとしてのキャリアってエンジニアとしてのキャリア+α
• 自分がやったほうが早いって考えはやめとけ
  • メンバがつまづくとこを直してくだけで1人がやるより断然速度は早くなる

感想

これまた全く他人事じゃない話。
私自身、入社してしばらくは本も全く読まなかったし、先輩からこれ読んだ方がいいよ！と言われても結局読まないことが多かったのでこの輪読会って方法は割と良さそうだと思いました。
雑談は本当大事！雑談がしやすい環境の案件、雑談がしづらい環境の案件のどちらも環境も経験しましたが、
雑談しやすい環境のが圧倒的に仕事のコミュニケーションも取りやすかったです。
現在の案件でもメンバーとして意識してることの1つですね～。

13:30~ 先行開発！Javaでクリーンアーキテクチャ – ゼロから始める新規開発

• 資料：https://nrslib.com/clean-architecture-with-java/

  • 記事としてもまとめてくださってる！

• クリーンアーキテクチャのよくある図の前にヘキサゴナルアーキテクチャ（ポートアンドアダプター）

  • ゲーム機本体とディスプレイなどの周辺機器の関係みたいな
  • アプリケーションだと入出力デバイスもデータストアのことも知らない
• クリーンアーキテクチャはヘキサゴナルアーキテクチャの実装方法を説明するアイデア
• ドメインとしてのエンティティとデータモデルは違うし画面出力用のviewmodelも違う

感想

以前自分で調べた際にあまりイメージできなかったクリーンアーキテクチャが、なんとなくイメージできるまでになったわかりやすい発表でした。
資料だけでもわかりやすい上、復習用に記事までまとめてくださっているため興味がある方はぜひ資料URLに飛んで見てみてください。
アーキテクチャそのものは非常に有用なものだと感じましたが、インターフェースをがっつり切る分実装のコストは大きそうで、「本当に必要か？」はよく考える必要があるように感じました。

14:30~ テストエンジニアが教える JUnitを書き始める前に考えるべきテスト

• 資料：https://speakerdeck.com/nihonbuson/jjug-ccc-2019-spring

• テストは品質レベルが”十分”であることしか示せない(※完璧じゃない)

• 実装の作り込みの防止もテストの大切な目的
• テストの内容についても議論しましょう！
  • ペアワークを実際にやったけど、テストの仕様を他の人と話すと、自分が気づいてないテストがでてきた
• プログラム書く前から”何をテストする？？”を話すだけでも効果がある
• テストケースを考える時は理由を必ず考える！
  • 選択肢5つのうち2つをテストします⇨どうして？⇨境界値
  • 理由がそのまま具体的なテストケース名になる
• 開発者がやるのはchecking、QAがやるのはTesting
• 自動テストでできるのはcheckingだけ
• 発表資料内にテストに関するおすすめ書籍あり
• JaSSTってイベントはおすすめとのこと

感想

思っていたより基本的な内容のお話でした。
ただ、わかってはいるけどやれてないって案件は実際多そうにも感じてます。
実装前に”何をテストする？”をしっかり考える部分については、工数に関係なく取り組める話だと思うので日々実践していきたいですね。

15:45~ 1400万ユーザーのWebサービスを15年運用して考える、Javaである理由

• 資料：https://speakerdeck.com/masao0127s/1400mo-yuzafalsewebsabisuwo-15nian-yun-yong-sitekao-eru-javadearuli-you

• 安定、社内の知見が理由でJava

  • 言語仕様以外のところが理由でチョイス
• 使ってる人が多いことによる情報収集のしやすさ
  • 人的リソースも集めやすい
• 静的型付け&コンパイラが強力
• ピクトリンクはAdoptOpenJDK8に移行
  • 11にあげるのはキツイしOracleは高い
  • OracleJDK8⇨AdoptOpenJDK8への移行はそんなに困らなかった

感想

いくつか理由は上げていらっしゃったものの、社内のナレッジ蓄積と人の集めやすさが結局大きい印象を受けました。
ここしばらくJavaScriptを触ってて型の厳しさに対するありがみは感じるようになりましたが、それもTypeScriptを使えばほぼ解決するんですよね……
言語的な部分で言うならJavaを使う理由ってそこまでないのかなぁと感じました。

16:45~ ストラングラーパターンによるマイクロサービスマイグレーションの勘所

• 資料：https://speakerdeck.com/kawakamitor/jjug-ccc-2019-spring

• Oracleがやっぱりボトルネック

• k8sのスタンダードな構成
  • それぞれはSpring Bootで実装
• Strangler Pattern
• Azureのサービスを一旦経由させて従来のDB⇨サービスからAzure上のDBを見るように
  • joinjoin&joinが厄介
  • 効果の高いところから始め、場合によっては大胆に移行するしかない
• SwaggerでSpringのControllerを自動生成
  • クライアントも自動生成できるからうまく使えばSwaggerは便利！
• k8sを使った開発ではこれまで以上にログ収集が必須
  • Papertrailを使用しているらしい
• spring-cloud-starter-sleuthはSpringBootならとりあえず入れとけ！
  • サービスをまたいだリクエストのログを識別できるようになる
• k8s周りは非互換なバージョンアップがあるので注意！
  • 基本的には新クラスタ立てて並行稼働しつつ切り替えていこう

感想

今いる案件でマイクロサービスをやるならまさにこのパターンになるんだろうなぁって感じのセッションでした。
joinしまくってる箇所の分割、移行は本当にネックですね……

17:45~ マイクロサービス：４つの分割アプローチの比較

• 資料：https://www.slideshare.net/masuda220/ss-146325870

• クラウド、コンテナは必要なものだけど、結局重要なのは設計スキル

• 前提として、発表者の人は（プロダクトには）枯れた技術しか使いたくない
• まずはモノリスで作ってからマイクロサービスへの検討
  • 多分うちもこんな流れになるよね
• そもそも関心の分離とか疎結合とかはマイクロサービスうんぬん関係なく必要な内容
• 実際問題マイクロサービスでどこまで小さくできるかはスキル次第
  • 最初はある程度まで分散して、経験、実績が出れば次の段階でさらに細かく分けるという方法
• マイクロサービス化した時にモノリスではありえなかった問題が出てくる
  • 経験をつめば問題なくなってくるが、ここを考えておかないと辛い目にあうだけ。。。
• マイクロサービス間の通信8つの勘違いと真実
  • ぶっささる人多い気がするので要チェック！

• 設計時点での論理的な分割はとにかく積極的に！

  • 設計がよくなればなるほどマイクロサービス化のハードルも下がる

• ビジネスロジックでの分割の説明中Twitterでコンウェイの法則？が話題に上がってた

• ユースケース単位での分割

  • ユースケースで分割した裏で、ロジックを領域ごとに整理して管理することで、重複やデータ不整合を防ぐ

• ドメイン駆動的な分割

  • そもそもエヴァンス流とバーノン流で違うっぽい？
  • わからん！とのこと

• ドメイン駆動設計の「モデル」はビジネスルール

• 時間の都合上トランザクションについては資料を参照してね

感想

マイクロサービス化を行うときに頭に入れておかねば……！みたいな内容がつまりにつまった濃いセッションでした。
個人的に以下2点は忘れないようにしたいと感じました。

• 論理的な分割は積極的に、物理的な分割は慎重に
  • 論理的な分割のノリで物理的な分割をやってしまい、システムが複雑になって地獄を見る……というのは実際にハマりそうなパターンだったので
• マイクロサービス間の通信8つの勘違いと真実
  • この勘違いをして地獄を見る想像が一瞬でできたので……

セッションは聞いてないけどtwitterタグ監視で見つけた話題

• Javaアプデについて
  • 今後JavaはLTSだけを追おうとすると変更多くてキツいのでちゃんと半年ごとのアプデチェックしましょう
• 教育系
  • Javaの従来型の新人研修は現場と乖離がある
  • 検収時点からLint入れて綺麗なコードを意識させる

NetlifyにデプロイしたアプリからSteamAPI呼んで遊ぼうと思ったら弾かれて悲しい思いしたのでメモ。

仕事で一度引っかかってつらい思いしたのにサックリ対応してなかったから頭に入ってなかったみたいです。
ちゃんと理解して対応しましょうね。

CORSとは

正式名称は”Cross-Origin Resource Sharing”(オリジン間リソース共有)。

ブラウザはセキュリティ上の理由で、自分自身と異なるオリジンからのアクセスを拒否するようになっています。
→もしこれがないとfoo.jpってサイトを開いたのに、知らない内にbar.jpってとこから情報抜かれてた！みたいなことがあり得る

ただ、実際今回のように異なるオリジンのAPIを呼ぶなんて日常茶飯事……
そこで出てくるのがCORS！
HTTPヘッダを使用して異なるオリジン間でもアクセスできるようにしてくれます！！

2種類のCORS対応

CORS対応にはpreflightという事前リクエストが必要なパターンと、必要でないパターンがあります。。
MDNによると、以下の条件を全て満たしていればpreflightリクエストは必要ないらしい。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

- 許可されているのは以下のメソッドのみです。
  - GET
  - HEAD
  - POST
- ユーザーエージェントによって自動的に設定されたヘッダー (たとえば Connection、 User-Agent、
  または Fetch 仕様書で "forbidden header name" として定義されている名前のヘッダー) を除いて、
  手動で設定できるヘッダーは、 Fetch 仕様書で "CORS-safelisted request-header" として定義されている以下のヘッダーだけです。
  - Accept
  - Accept-Language
  - Content-Language
  - Content-Type (但し、下記の要件を満たすもの)
  - DPR
  - Downlink
  - Save-Data
  - Viewport-Width
  - Width
  - Content-Type ヘッダーでは以下の値のみが許可されています。
  - application/x-www-form-urlencoded
  - multipart/form-data
  - text/plain
- リクエストに使用されるどの XMLHttpRequestUpload にもイベントリスナーが登録されていないこと。
  これらは正しく XMLHttpRequest.upload を使用してアクセスされます。
- リクエストに ReadableStream オブジェクトが使用されていないこと。

PUTとかDELEAT辺りを使おうとするとpreflightリクエストが必要みたいです。

実際に作って試してみる

今回はとりあえずpreflightが必要ないパターンについてサンプルを作って試してみました。

ソースはこちら

サーバーはexpress、クライアントはVue.jsで作成。
両方ともローカルで試していますが、サーバーを3000ポート、クライアントを8080ポートで立ち上げているためオリジンは別扱いとなります。

CORS対応なし

まずはcors対応なし。

クライアント

callボタンを押すとサーバーにGETリクエストを送り、取得したデータをコンソールに表示します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<template>
  <div>
    <button @click="callHello">Call</button>
  </div>
</template>
<script>
import Axios from "axios";
export default {
  name: "CallApi",
  methods: {
    async callHello() {
      try {
        const res = await Axios.get(`http://localhost:3000/api/v1/helloworld`);
        console.log(res.data);
      } catch (err) {
        console.log(err);
      }
    }
  }
};
</script>

サーバー

シンプルにHelloworldの文字列を含むjsonを返すAPIを作成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var express = require('express');
var app = express();

// CORS対応してないパターン
app.get('/api/v1/helloworld', (req, res) => {
  res.json({
    message: 'Hello world!!!!'
  });
});

// 3000番ポートで待ち受け
var server = app.listen(3000, function() {
  console.log('Node.js is listening to PORT:' + server.address().port);
});

実行結果

予想通り、クロスオリジンのエラーで弾かれます。

1
2
3
4
5

localhost/:1 Access to XMLHttpRequest at 'http://localhost:3000/api/v1/helloworld' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
CallApi.vue?cbce:17 Error: Network Error
    at createError (createError.js?2d83:16)
    at XMLHttpRequest.handleError (xhr.js?b50d:87)
xhr.js?b50d:178 Cross-Origin Read Blocking (CORB) blocked cross-origin response http://localhost:3000/api/v1/helloworld with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.

CORS対応あり

クライアント

クライアントは特に変更なく、APiをGETで呼ぶだけです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<template>
  <div>
    <button @click="callCorsHello">Call(cors)</button>
  </div>
</template>
<script>
import Axios from "axios";
export default {
  name: "CallApi",
  methods: {
    async callCorsHello() {
      try {
        const res = await Axios.get(`http://localhost:3000/api/v1/corshelloworld`);
        console.log(res.data);
      } catch (err) {
        console.log(err);
      }
    }
  }
};
</script>

サーバー

サーバーは少し実装が異なります。
何をやっているかというと、Access-Control-Allow-Originというヘッダーにリクエストヘッダーから取得したOriginの値を設定しています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var express = require('express');
var app = express();

// CORS対応してないパターン
app.get('/api/v1/helloworld', (req, res) => {
  res.json({
    message: 'Hello world!!!!'
  });
});

// CORS対応してるパターン
app.get('/api/v1/corshelloworld', (req, res) => {
  res.setHeader('Access-Control-Allow-Origin', req.header('Origin'));
  res.json({
    message: 'Hello world!!!!'
  });
});

// 3000番ポートで待ち受け
var server = app.listen(3000, function() {
  console.log('Node.js is listening to PORT:' + server.address().port);
});

実行結果

これで問題なくjsonを受けとることができました！

1

{message: "Hello world!!!!"}

まとめ

preflightが不要なら割と簡単に実装はできそうです。
ただ、対応が必要なのはサーバー側なので、今回最初に試そうとしていたように、Netlifyに配置した静的サイトから直接外部サービスのAPIを呼ぶのは無理そうですね……

lambdaとかからSteamAPIを呼ぶ処理を作り、その処理を静的サイトから呼び出すとかで実装できるんですかね。
試してみないと……

はるか昔11月のこと、Node学園祭の1日目に遊びにいってました。
その時のメモを残してたのにあげるとこがずっとなかったので、今更ですがまとめなおしました。

• 日時・場所
• keynote
• How I made some critical code much faster
• 11:15 B Nodeで作るインタープリター
• 13:00 B Diagnose your Node.js app
• 13:30 B State of SEO for SPA
• 14:15 Node.jsアプリの開発をモダン化するために取り組んできたこと
• 14:45　B WebアプリをNativeアプリにする Capacitor が広げるWebの可能性
• 16:00 B Service Workerを用いたキャッシング戦略 〜Wikiアプリケーションを例に〜
• 16:45 B 貢献できるOSSの見つけ方 -完結編-
• 17:15 B Vue.js/Nuxt.js で 実現できた PWA の リアルタイム動画ラップ・バトル・アプリ
• 終了後LT
• 個人的感想

日時・場所

• 2019/11/23(金)
• ヤフー株式会社

keynote

• ロゴが新しくなったらしい

  • 新ロゴのTシャツもらいました(この手のどこで使えばいいのかいまだわからん)

• 翻訳ツールを自作したらしい！

  • 英語音声を一度テキスト化したものを翻訳してスクリーンに表示
  • Twitterで反応見てた限りおもしろ翻訳が飛び出したり、制度はあんまりだったみたい……

• Node.jsとjsのファウンデーションが1つに！

  • 来年はnodeFesじゃなくてjsconfにしたいとのこと

How I made some critical code much faster

https://bit.ly/2BrhlMj

• 自動翻訳と聞いてウキウキで英語の部屋にいったらどうやら自動翻訳はメイン部屋のみだったらしく絶望
• 雰囲気で聞いてたけどとにかくパフォーマンスを突き詰めてることとSQLを解釈する箇所がボトルネックだった、程度の話しか理解できず

11:15 B Nodeで作るインタープリター

https://twitter.com/massie_g/status/1065791331362992128

• RubyでつくるRubyに感銘を受けて自分でも作ってみた方の話
• 発表内で紹介されていた記事がとても細かくまとまってたので、長編なもののいつか読んでみたい
• 本を読んで受けた感覚以上に難しかったとのこと

13:00 B Diagnose your Node.js app

https://darai0512.github.io/nodefest2018/index.html#/

• Node.js自体の特性についての話
• 非同期処理の処理順序がバージョンや環境によって異なるので注意！
  • 当たり前といえば当たり前ですがasync/awaitとかをちゃんと使えば大丈夫そう？
  • テストツールについても紹介されてたので要確認
• サードパーティを調べ始める前にNode.jsコアAPIをちゃんと調べること
  • コアAPIだけでもできることは結構多いみたい
• デバッグ方法についても多々紹介されてたのでNode.jsで開発する前には一通り確認しておきたい情報が多かった

13:30 B State of SEO for SPA

https://speakerdeck.com/kazuyaseki/seo-for-spa-cfb3706f-ae1d-4c6f-a83f-96dc2452f32b

• SEOについての話

  • 部屋から人が溢れるレベルで大人気のセッションだった

• 最近はちゃんとjsでのレンダリングも見てくれる

  • ただし、bot内部のChromeバージョンは41(2015/03くらいのバージョン)なため、アロー関数が使えなかったり色々制約はあるとのこと
  • 一応もっと新しいChromeでって話は公式でも上がってるらしい？
  • babelなんかを使ってChrome41対応すれば問題ないとのこと

• メタ情報だけSSRする方法はアリ

  • Nuxt.jsとかはSPAにしててもメタ情報はSSRしてくれてるらしい

• Dynamic renderingという手法をgoogleが推してるらしいので要チェック

14:15 Node.jsアプリの開発をモダン化するために取り組んできたこと

https://www.slideshare.net/bitbankink/nodejs-124129219

• タイトル通りの内容
  • これまた大人気のセッションだった
• 人数が多くなっていくにつれてモダン化させないことにはどうしようもなくなったとのこと
• アプリケーションフレームワーク”Nest”
  • githubスターも1万超えで最近はだいぶ使えるようになってきてるらしい
  • デコレータを使用してのControllerを作っておけばSwaggerのドキュメントを生成してくれる
    • ソースからAPIドキュメント生成できるので便利そう
• TypeScript + Nest + TypeORMの構成
• ユニットテストに必要なものをdockerのコンテナ上に配置して再現性を保証
  • dockerに馴染みがない人もdocker-compose.ymlを置いておくと自由にカスタムして使ってくれたりして馴染んでくれたとのこと
• Infrastructure as Codeの実践についてもTipsが色々あったので資料チェック

14:45　B WebアプリをNativeアプリにする Capacitor が広げるWebの可能性

https://speakerdeck.com/rdlabo/capacitor-web

• WebアプリをネイティブアプリにしてくれるCapacitorについての話

• HTML5アプリをネイティブアプリに変換するツール
• “Apache Cordova”というメジャーなツールの後継プロジェクトらしい
• デザインガイドラインが存在し、それに則ってアプリを作ることでネイティブアプリっぽい見た目になるらしい
• Core pluginがあり、ちょっとしたネイティブのAPI叩くくらいならこれでカバーできるとのこと

• PWA Elementsがあるので、それっぽいアラートやそれっぽいカメラ画面を出してくれる？

• そもそもネイティブアプリは必要？

  • パフォーマンスはそんなに変わらない
    • HTML5アプリが遅い場合は実装が悪いだけのパターンもある
  • モバイルアプリはなかなか新規で落としてもらえない
    • アプリをインストールすること自体が手間
    • 単純に多くの人に見てもらいたいのならWebアプリの方が良いのでは？という話

16:00 B Service Workerを用いたキャッシング戦略 〜Wikiアプリケーションを例に〜

https://scrapbox.io/daiiz/ServiceWorker%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%B3%E3%82%B0%E6%88%A6%E7%95%A5_~Wiki%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BE%8B%E3%81%AB~

• 実装周りの話が多く、そもそもService Workerを把握できてないレベルでは話に追いつけませんでした……
  • 資料が細かかったので、ちゃんと勉強してからまた資料を読み直したい

16:45 B 貢献できるOSSの見つけ方 -完結編-

https://speakerdeck.com/ohbarye/how-to-find-good-first-issues-final

• OSS貢献したいけどしたことない人向けの話

• 最初にプロジェクトを選んで課題を見つける部分が難しい

  • 実際プロジェクトを決めてしまえばそこからプルリク送るまではできる人が多いらしい
  • good first issueというラベルの存在
    • 文字通り初めてコントリビュートしたいという人向けのissue
• 簡単なIssueは新規コントリビュータ向けにあえて直さず置いておくみたいな文化もあるらしい

17:15 B Vue.js/Nuxt.js で 実現できた PWA の リアルタイム動画ラップ・バトル・アプリ

https://riotz.works/slides/?2018-nodefest#1

• フロントはNuxt.jsを使用
  • 発表時点ではまだ型定義が提供されていないが、マージ済みなのでそのうちリリースされるはず
• FirebaseのRealtime Databaseが便利
  • スピード第一ならモバイルベースかつ分かりやすくて良かったとのこと
• TypeScriptがAWS Lambdaのコールドスタートに強いらしい

終了後LT

https://speakerdeck.com/shimataro/remember-to-close-resources
https://speakerdeck.com/sota1235/how-to-choose-the-best-npm-module-for-your-team

個人的感想

• 英語がちゃんと読み聞きできればもっと色々聞けたのかもしれない
• SPAのSEO対策は最近ちょっと調べて、どれが正しい情報なのか混乱してるとこだったので整理できてよかった
• Nest, Capacitor辺りは実際に触ってみたい
• OSSへのコントリビュートはやったことないので、今個人的に作りたいものが落ち着いたらやってみたい
  • good first issueタグを頼る

• 前置き
• iframe 内 document 使いたい問題
• \$(要素).on(‘load’, ()=>{})でも要素が取れない問題
• 遷移時に Content Scripts が読み込まれない問題
• まとめ
• 参考 URL

前置き

最近 Vtuber にドはまりしており、その影響で Youtube 用 chrome 拡張を自作しました。

• youtube_chat_pinner ダウンロード
  • ソース(github)

Vtuber あんまり見ない人向けにも分かるように言うと、配信している Vtuber の知り合いがチャットを残した際にそれを画面に残してくれる拡張です。
ちょこちょこ同じ事務所の Vtuber が配信に来たりするんですが、作業しながら動画を流したりしてると

〇〇が来た！
〇〇もよう見とる
〇〇おるやんけ！

みたいなチャットに流されちゃって、そのチャットが見れなくて悔しい思いすることがあるんですよね……
配信してる Vtuber 自身もそのチャットに反応したりするので、見逃さなくなるのは我ながら本当に助かるツールです。

以下本編

iframe 内 document 使いたい問題

1
2

const chatFrame = document.getElementById('chatframe');
const chatFrameDocument = chatFrame.contentWindow.document; // iframe内文書の document

Youtube のチャット欄は iframe のため document からはアクセス不能。
普通に getElementById で取得してから contentWindow.document で取得できます。

初歩的な話ですが getElemetById と jQuery の\$(‘chatframe’)は取得するオブジェクトが異なるので注意

1
2
3

// これは動かない！
const chatFrame = $('#chatframe');
const chatFrameDocument = chatFrame.contentWindow.document; // iframe内文書の document

$(要素).on(‘load’, ()=>{})でも要素が取れない問題

1
2
3
4
5
6
7
8
9
10

// インターバルIDの取得
const setIntervalId = setInterval(startObserve, 1000);

function startObserve() {
  if ($('#chatframe').length) {
    clearInterval(setIntervalId); // setInterval解除

    // #chatframeを取得後に行いたい処理を記述
  }
}

Youtube チャット欄の iframe は遅延ロードされてるようで、iframe 自体の id を指定しても要素が取れませんでした。
jQuery の onload を使ってみても取得できなかったため、上記の実装で対応。

上記の実装では setInterval によって 1 秒ごとに startObserve 関数が呼ばれ、
#chatframe が見つかった時点で setInterval を停止させています。

遷移時に Content Scripts が読み込まれない問題

Youtube 拡張最後の罠。
動画再生ページで Content Scripts が動くように manifest.json を記述したのに、
画面更新しないと Content Scripts が読まれない場合があります。
理由は画面遷移時に画面更新が行われていないためでした。

その場合は manifest.json に以下の記述を追加。

1
2
3

"permissions":[
  "https://www.youtube.com/watch?*", "tabs", "webNavigation"
],

その上で background.js に以下を記述

1
2
3

chrome.webNavigation.onHistoryStateUpdated.addListener(() => {
  chrome.tabs.executeScript(null, { file: 'scripts/contentscript.js' });
});

これで画面遷移時に更新が行われなくても HistoryAPI を見て file に指定した js を呼んでくれるみたいです。
正直ここの実装はあまりちゃんと調べてないので詳しくは分かりませんが……

まとめ

DOM 拾って固定するだけなら簡単やろ！と思って作り始めた chrome 拡張でしたが、思ったよりハマりポイントが多かったです。
フロント詳しい人にとっては初歩的なことが多いかもしれませんが、ちょっとかじったレベルだと割とハマりやすい箇所かと思います。

みんなも chrome 拡張使って快適に Vtuber の配信見よう！以上！

参考 URL

• https://qiita.com/Rasukarusan/items/754de5d8943eea8cc4ce
• https://sota1235.hatenablog.com/entry/2016/12/01/150209

ブログ解説してみました。

Hexo + Github Pagesでお手軽に解説！
今ってこんなに簡単にブログ解説できちゃうんですね……

とりあえず書ければいいのでテーマもデフォルトのままですけど、気が向いたら触っていけたらいいなぁとは考えてます。

3日坊主にならないように祈るしかない……