最後に、広告以外で最も遭遇する可能性が高いユースケースである「埋め込みを提供しているが、ログアウトされてしまう」という不具合に対処する方法についての問題にした。これには幅広い回答がある可能性があるため、Storage Access API と CHIPS の 2 点をベースに半分ずつ加点し、その他の対応については内容に応じて加点とした。

なお、「ホワイトボードサービス M」は Miro のことであり、Miro がこの問題そのものの調査内容をブログに書いていることのヒントであった。

The end of third-party cookies and its impact on Miro apps and integrations | by Darren | Miro Engineering | Medium
- https://medium.com/miro-engineering/the-end-of-third-party-cookies-and-its-impact-on-miro-apps-and-integrations-ee73358cda1e

ちなみに、このブログでは、アドベントカレンダーの 14 日目で解説している。

3PCA 14 日目: Partitioning | blog.jxck.io
- https://blog.jxck.io/entries/2023-12-14/partitioning.html

大問 3

2023 年にめざましかった CSS の新機能に関する問題とした。

Nesting は、記法に何度か変更があったが、基本的には最新のもので落ち着いているため、それを選べていることを前提とする。ただし、他の記法も最新の仕様で間違っていなければ良しとする。

Scope は、ドーナツスコープ(上限と下限が決まったスコープ)の意味がある仕様にし、カードレイアウトのカードの中に「任意のコンポーネント」を配置でき、「そこに波及しないスコープを切る」という設問とした。

Subgrid は、まさしくカードレイアウトにおける頻出パターンであるため、「カード内のグリッドを揃える」という要件を満たすことができる。

便宜上実装は React だが、問題は React を知らない人でも普通に答えられるように作問している。

大問 4

非同期のエラーハンドリングは、地味ではあるが応用範囲の広い変更の 1 つだ。

AbortSignal.any()
AbortSignal.timeout()
addEventListener() の signal プロパティ

これら 3 つを用いることで、従来行っていた非同期処理の中断(Aborting)を、イベントリスナーが追加され続けるメモリーリークを解消する形で書き直す問題とした。

実は、このブログに書いた記事と全く同じ内容であるため、そこと差別化するのに苦戦した問題でもある(サーバのコードをフロントにしただけで基本は同じ)。

AbortSignal.any(), AbortSignal.timeout(), そして addEventListener() の Signal | blog.jxck.io
- https://blog.jxck.io/entries/2023-06-01/abort-signal-any.html

これも、様々な解法が予想されるが、基準は最終的にハンドラが綺麗に消えていれば良いとする。しかし、想定された API を使わず自前で実装するには、おそらく時間が足りないだろう。

作問意図

今回は、外部に広く募集したため、なるべく汎用的な問題にする方向にした。

去年は、エコシステム周りの問題として TypeScript の satisfies を採用したため、そうした問題も入れるつもりでいた。

2023 年といえば、React Server Component や Server Action など、エコシステム系でも相応のテーマがあったため、その方向で考えていた。

しかし、さすがに React や Next を使っていない人にはピンとこないだろうし、使っていたとしても、まだプラクティスなど諸々が定まっていない中で、回答が安定する問題を作るのも難しかった。

Signals といった、複数のフレームワークに波及した話題もあったが、少し対象が狭すぎるため外した。

大問 4 自体を複数用意し、選べる形式にするなどもあったが、作問の負荷をこれ以上上げるのは、現実的では無かった。

結果、どんな開発者にとっても知っておいて損のない内容で、かつ平均を 50 点代にする作問ができたため、ある程度目的は達成できたと思う。

来年以降も、一般の受験を募集したいと思っているため、特にライブラリ周りはどのようにテーマを絞り、不公平感の少ない作問をするか、悩ましいところではある。

反省点

作問が非常に難しい。

解答が一意に定まるような条件付け
大きすぎず小さすぎないコーディング問題の調整
対象を絞りすぎず、広げすぎないテーマ設定
60 分でギリギリできるくらいの難易度
2023 年という試験範囲
バグの無い問題と解答の用意

特に大問 3 では「Scope を切っているため、Nesting する必要がない」といった派生の回答や、大問 2 の「トライアルの名前」という表現は「Reverse Origin Trials」を想定していたが、「Deprecation trials: Trial for Third Party Cookie Deprecation」とトライアル自体の名前が回答されるなど、まだまだ隙はいくつかあった。

ガチガチに問題文で指定すると、それを書き起こすだけになりそうなため、ここはある程度採点で吸収するつもりではいたが、それが採点のブレを生じないようにするのもまた難しい。

あと、Codepen が「試験用」と「想定解用」を用意し、かつその中身を「想定回答の Docs」にも同期する必要があり、ここが微妙に面倒だった。次回は何かいい方法を考えたい。

Outro

何度も言うが、点数が目的ではなく、今回の試験を通じて知らなかったことなどを振り返るきっかけになれば良いと思う。

また、キャッチアップで手一杯になりがちなエンジニアは、過ぎゆく話題や、自分の業務に関係ない話題に触れる機会が減りがちだ。試験形式でこうした内容をまとめて振り返る機会というのは、Web 以外にも応用が効くのではと思う。(試験ばかりになると辛いが)

来年も実施できたらと思うが、来年もこの作問をするのかと思うと、少し気が重い。