はてなブックマーク

Intro 「毎時何時に実行」や「何時間ごとに実行」といった、タスクスケジューリングを実装する機会は少なくない。 タスクを実装し cron に登録すれば、動くものを実装するのは難しくない。 しかし、ひとたびタスクが思うように動かなかった途端、隠れていた要件が牙を剥く。 一度でも痛い目を見た人は、それを経験的に疑い「まず色々と前提を確かめよう」という気持ちになり、例外処理を事前に固めることができる。 今回は、実装方法そのものというよりも、「実装する前に確認すべき例外事項」を個人の経験を元に解説していく。 定時実行 「定時実行」とは、例えば「毎日 00:10 になったら、前日分のログをローテーションする」や「毎日 9:00 になったら一斉にメールを送る」といったものだ。バッチ処理などと呼ばれることも多い。 なお、00:10 のように微妙にずらすのは、00:00 には他のタスクも動いており、一度

Intro http://localhost:3000 での開発には限界がある。 しかし、本番と同じように https://example.com でアクセスできる環境をローカルに作るには、ドメインの解決、証明書の発行、443 での起動など、少し手間がかかる。 そこで、必要な全てを 1 つのツールで行い、様々な開発環境を再現するためのツールを開発したので、紹介する。 Jxck/sptth: reverse https proxy (https - sptth) for local development https://github.com/Jxck/sptth localhost の罠 localhost はあまりにも特別なホストであるため、権限などの挙動は、本番ドメインにデプロイすると変わる。 また、本番ドメインとは Origin が異なるため、連携のためのあらゆるセキュリティ境界も変

Intro コロナ禍が明け、カンファレンス文化も再開し、コロナ前かそれ以上の頻度で多くのカンファレンスが企画されるようになりました。 しかし、コロナ中の断絶によってノウハウの継承が途絶えた部分もあり、後発のイベントが既知の失敗を重ねている場面も見られます。 そこで、カンファレンス主催者の有志が集まり、それぞれのノウハウを持ち寄ってまとめた「カンファレンス開催ノウハウ」を作成しました。 📔 カンファレンス開催ノウハウ - Google ドキュメント 複数人で書いたため、この公開は同時に複数の有志によりブログなどで告知されます。 カンファレンス開催の勃興 特に Web フロントエンド界隈では、「フロントエンドカンファレンス」が各地域で同時多発的に発生したりと、新しいカンファレンスも増えています。中には、初めてカンファレンスを主催する主催者も多く、手探りで始めることも増えました。 コロナ前は、

Intro 小さい文字が見づらい場合、ユーザは OS の文字サイズを大きくすることで、視認性を調整することができる。 こうした機能は大抵の OS が備えており、システムフォントのサイズなどに反映される。 しかし、その指定がそのまま Web コンテンツにも反映されるかというと、必ずしもそうではない。 この問題を解決するために、いくつかの標準が提案され、策定と実装が進んでいる。 サイズの相対値指定 「ユーザは文字を拡大することがある」というのは、おそらく多くの開発者が認識しているだろう。 WCAG を引き合いに出すなら、以下のセクションで「200% までの拡大に対応すべき」といった基準(AA)がある。 text can be resized without assistive technology up to 200 percent without loss of content or fun

Intro GPC (Global Privacy Control) の策定と実装が進んでいる。 このヘッダは、サービス、ユーザ、ブラウザ、全てにとって「無視することができない特別なヘッダ」となりつつある。 たかだか 1 という値を送るだけのヘッダに、何の意味があるのか? 失敗して歴史に消えつつある dNT と何が違うのか? 解説していく。 dNT 長らく問題視されていた "3rd Party Cookie" は、技術そのものではなく、「トラッキング」というユースケースに問題があった。 したがって、Web の歴史の前半では「トラッキングからの Opt-Out」という手段を、ユーザが手に入れるための戦いが繰り広げられていた。 GdPR などが求めた Cookie Banner などが、その最たる例の 1 つだ。しかし、どうしても UI は邪魔になるし、毎回 deny を押すのも不便だ。 それ

Intro 2025 年の Web 技術を振り返る試験として、「Web 技術年末試験 2025」を実施した。 その問題と想定解答、平均点などを公開する。 Web 技術年末試験 この試験は、「去年の Web にはどんな変化があったか」「どんな新しい技術が出てきたか」などを、試験形式で振り返るコンテンツを作ってみたことに端を発している。2022 年に始まり、今年が 4 回目の実施となる。 試験形式であるため点数は出るが、目的は「今年はこんなことがあった」を振り返ることや、「こんなことがあったのは知らなかった」という取りこぼしに気づく機会になることである。 解答用紙/想定回答 [解答用紙]: Web 技術年末試験 2025 https://docs.google.com/document/d/1Ck9zKYMUV8UprBlS5fKkAGBIrGX6CPksMosnQbfwx28/ [想定回答]

Intro Web は誰のものでもなく、誰でも無料で使える。 しかし、その状態を維持するための費用が、かかっていないわけではない。 そこで、Web を生業にしている筆者としては、Web が壊れないための「維持コスト」をほんの一部でも負担するという意図をもって、寄付を行っている。 一括寄付 これまで、Web / Internet に関連する組織などへの寄付は、その都度ばらばらに行ってきた。 しかし、どこに寄付しているのかわからなくなってきたため、棚卸しをしつつ年始に一括して行うことにした。 また、寄付の対象も 15 の寄付先をリストアップし、5 ドルずつ寄付するようにまとめることにした。 寄付先 寄付先はガバナンスを維持する目的の組織を中心としている。また、筆者は「ブラウザがこれ以上減ると均衡が崩れる」という危惧を以前から持っているため、ブラウザ関連も対象とした。 今年の寄付先は以下の通りだ

Intro 例年通り 2025 年を振り返る。 blog 今年は 43 本書いた。近年だとかなり多い。 2025-12-09: 3PCA 33 日目: Outro 2025-12-08: Background Fetch API が消えそうだった話 2025-11-19: Web とは何か 2025-11-18: TPAC 2025 参加記録 2025-11-13: 1Password AC #10: SSH と Git コミット署名 2025-11-12: 1Password AC #9: Travel Mode 2025-11-11: 1Password AC #8: 1Password CLI 2025-11-10: 1Password AC #7: Group と Vault の運用 2025-11-09: 1Password AC #6: Business アカウント特典の無料

Intro このエントリは、2023 年の 3rd Party Cookie Advent Calendar の最終日とする。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie TPAC 2025 最後のチェックポイントとして、TPAC 2025 で関連 WG のミーティングに参加した。 ちょうど Privacy Sandbox の終わりが発表された直後であったため、各 WG がどのような議論になるか、メンバーからどのような反応が出るのか、議論の雰囲気を確認する目的だった。 関連するのは、以下のミーティングだ。 Private Advertising Technology Community Group https://

Intro 「Background Fetch を使っているのが、世界であなたのサイトだけなんだけど、この機能消しても良い?」 と、TPAC 2025 の会場で、Chrome の Service Worker チームの開発者と話していた際に言われた。 Background Fetch Background Fetch は、Service Worker を使って、文字通り Fetch をバックグラウンドで行う機能だ。 特に Android では、ダウンロードの UI にプログレスが表示され、終わったら Cache API に保存される。 筆者が運営している mozaic.fm のサイトは、Podcast アプリと同じようなことを Web でもできるように PWA 化し、様々な機能を試していた。 PWA: モバイルでインストールしてアプリとして使える Background Fetch: エピソ

Intro 見落とされがちだが、「Web とは何か」という仕様はない。 Web を定義した W3C のドキュメントもなければ、IETF の RFC もない。 Web は仕様ではないのだ。 これだけしっかりと標準化された技術の粋を集めた総体が、なぜそんなにもフワっとしているのだろうか? 我々は、何を "Web" と呼んでいるのだろうか? HTML+HTTP+URL? 黎明期から Web を見ている人ほど、URL で指定された HTML を HTTP で取得するアーキテクチャを Web と呼ぶ、と思うだろう。 たしかに、それは Sir Tim Berners-Lee が最初に示したコンセプトそのものであったことは間違いない。 ところが、そこから 30 年以上の間、この Web と呼ばれたコンセプトは、ありとあらゆるパーティーからの期待を背負うことになり、当初の最小限のコンセプトだけでは、実態を

Intro W3C が毎年開催する国際会議、TPAC 2025 に参加してきた。 TPAC 2025 今年は何年ぶりかの日本開催であり、会場は神戸コンベンションセンターだった。 TPAC 2025: Overview https://www.w3.org/2025/11/TPAC/ 一週間の日程の中で、様々なミーティングが行われ、今後の Web のあり方が議論される。 TPAC 2025: detailed schedule https://www.w3.org/2025/11/TPAC/schedule.html W3C は会員制なので、TPAC も会員企業所属などでないと参加できない。 今回はサイボウズ社の W3C 加入を手伝った縁で、サイボウズ社員に帯同して参加した。 印象に残る部分だけ振り返る。 月曜日 初日は、まず WebComponents CG があった。 WCCG - TP

Intro このエントリは、1Password Advent Calendar の 10 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1CZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw SSH の鍵を使って、直接サーバにログインするような運用は減っているかもしれない。 それでも SSH の鍵を使う場面が無くなったわけではない。 今回

Intro このエントリは、1Password Advent Calendar の 9 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1CZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw 入国管理でのリスク 検閲の厳しい国への入国などでは、入国管理で PC の中を見せるように言われることがある。 このとき、1Password もアンロッ

Intro このエントリは、1Password Advent Calendar の 6 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1CZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw ここでは、1Password Business アカウントに付随する、Family アカウントの無料特典について解説する。 要するに、Business

Intro このエントリは、1Password Advent Calendar の 2 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1CZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw 個人で 1Password を使っている人が、1Password Business を導入している組織にジョインする場合、新しく組織用のアカウントが発

Intro このエントリは、1Password Advent Calendar の 3 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1CZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw 前回は「1Password の Master Password はマルチアカウントで共通して使って良い」という解説をした。 1Password の M

Intro このエントリは、1Password Advent Calendar の 1 日目である。 1Password - Qiita Advent Calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password 1Password を個人で使うだけでなく、組織全体で利用することで、開発に必要なアカウントを共有したり、CLI を使って自動化するといった、様々なメリットがある。 組織で 1Password を展開する際は、1Password を Business プランで契約し、ドメインに所属するメンバーにアカウントを発行することになるだろう。 その際、組織でどのようなルールを設け、どのような方法で管理し、どのように組織に合わせた設計を行うかは、多くの人が同じような検証を実施することになると思われる。 今回は筆者

Intro このエントリは、_2023_ 年の 3rd Party Cookie Advent Calendar の 32 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 宙に浮いていた Privacy Sandbox プロジェクトの「後始末」が公開された。 Privacy Sandbox の軌跡 Privacy Sandbox の開始は、以下のエントリの公開と捉えることにする。 2019/08/22: Building a more private web https://blog.google/products/chrome/building-a-more-private-web/ そして、2025/

Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志

Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a

Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 本方式は、法的に有効な遺言の作成については範囲外である。 本方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような

Intro 親の年齢に限らず、生きているうちにやってもらった方がいい、たった 1 つのこととして、エンディングノートの作成がある。 終活は、それをどのくらい準備しておくかで、本人以上に遺族の負担が格段に減るからだ。 エンディングノート エンディングノートとは、自分が死ぬ前に残しておきたい情報やメッセージ、思い出をまとめておくノートを指す。 「これを老後の備えとして書いておきましょう」という形で、病院に案内が置いてあったり、書店で販売されていたりする。 弁護士や公証人の立会いなどはないため、いわゆる「遺言」とは違い法的な効力も保証はない、もっとカジュアルなものだ。 何を書くべきかについてのルールがあるわけでもない。 遺族側の視点で見ると、大きな目的は 2 つある。 何かあった時に「こうしてほしい」という意思があるなら、書いておいてもらえればできる範囲で尊重する 何かあった後に、遺族が困りそう

Intro 先日、Passkey 啓蒙の一環で、まだパスワードマネージャを導入してない人に対する「1Password 導入セミナー」を実施した。 その内容を再収録したものを公開する。 ざっくりと、前半が一般ユーザ、後半が開発者向けの内容となっている。 動画及び資料は、啓蒙目的であれば自由に使ってもらって構わない。 なお、筆者は 1Password との利害関係は一切無い。 Slide 1Password 導入セミナー | ドクセル https://www.docswell.com/s/jxck/KE89J6-passkey-via-1password Video Links Passkey への道 #0: Intro Passkey への道 #1: 平成の Password 感 Passkey への道 #2: 2FA/TOTP Passkey への道 #3: 手入力の限界 Passkey

Intro サービスは、ユーザを守るために Passkey をサポートし、ユーザの移行を促す努力をする必要があった。 このプロセスに対して、ユーザはまったくの受動的態度でいることはできない。 では、ユーザはいったい何をリテラシとして身につけ、どう自分の身を守っていくべきなのだろうか? パスワードマネージャという基盤 ユーザに「今すぐ Passkey を理解し、導入移行すべし」と言いたいところだが、それはさすがに飛躍が過ぎるだろう。 仮に、あまねくサービスが Passkey 対応を終わらせ、あとはユーザ次第という状態であれば、その態度もあり得るかもしれないが、現実は非常に中途半端な過渡期で黎明期だ。 今すぐにでもユーザが取り組めて、この先様々なフェーズに柔軟に対応していく現実的な解は、「パスワードマネージャを導入する」ことだろう。 平成においてパスワードマネージャは、セキュリティリテラシの高

Intro パスワード + TOTP は限界を迎え、Passkey へ移行しなければ、サービスがユーザを守りきれなくなった。 逆を言えば、サービスがユーザを守りたいと思うのであれば、Passkey を提供しないわけにはいかない時代に突入している。 では、令和のこの状況において、サービスはどう対応していくべきだろうか? サービスの対応 理想だけを言うなら、Passkey をサポートし、Username-Less のログインを可能にする。その上で、パスワード+TOTP の認証はサポートを止め、保持していてもリスクでしかないパスワードのハッシュを、サーバから消す。鍵の管理とリカバリにだけに注力すれば良い。 というところまで到達できればよいが、現実的にはまだまだ過渡期どころか黎明期だ。サービスをそのように実装できればシンプルで堅牢だが、ユーザはそこまでの準備が整っているとは言えない。 サービスがパ

Intro Apple が突如発表した Passkey。 実態は「WebAuthn の秘密鍵を iCloud で共有」するサービスだった。 そして、業界は本格的な Password-Less に向けて進んでいく。 Passkey と FIdO Passkey は Apple のサービスとして始まったが、単なるいちベンダのサービスでは終わらなかった。 もともと生体認証を牽引していた FIdO を中心にこの方式についての議論が行われ、最終的には業界全体が Passkey を用いて Password-Less を目指す方向で概ね合意することになる。 Apple 以外のパスワードマネージャも Passkey に対応(つまり、秘密鍵を登録しそれを共有する)ようになり、様々な場所で Passkey への移行が啓蒙されるようになった。 ちょうどコロナ禍と重なるくらいの時期だ。 ちなみに、ここまで Web

Intro TOTP/WebAuthn は、バックアップコードの適切な保管方法が示されないまま、移行だけが推し進められた。 YubiKey などの物理 Authenticator の扱いとして、「二本登録して、片方は普段使い、もう片方は貸金庫へ」などと、かなり無理のあるベストプラクティスが啓蒙されたりもしていた。 それらをスマホに移行して、登録は便利だが壊したら詰むでは、ユーザは安心して使えない。いや、正確には「よくわからないまま使って、詰んでから Apple のサポートに連絡する」という状態だったのだろう。 ここに解決策が提示されたのが、WWdC 2021 だった。 Passkey の登場 Apple による Passkey の発表は、いつも通り何の前触れもなく行われた。 Move beyond passwords - WWdC21 - Videos - Apple developer