Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont
2021年になってJavaScript、TypeScript、Node.jsの勉強を始めました。 この記事では、読んで良かった本、記事、公式ドキュメントなどをまとめていきます。 ※2021/03時点の情報です。 個人的なリンク集ですが、「これも読むと良いよ」というものがあればぜひ教えてください。 ECMAScript ECMAScriptの仕様は、EcmaのTC39で策定されている Ecma TC39 GitHub organization ep78 TC39 | mozaic.fm Node.jsの各バージョンでのECMAScriptサポート状況 JavaScript Misreading Chat - #86: JavaScript: the first 20 years JavaScript 二十年の歴史についての回 JavaScript チュートリアル | MDN JavaScri
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
※二重管理になってしまうため、エンジニアの情報収集法まとめ - Qiitaに情報集約することにしました。 今後はQiita記事を参照してください。こちらの記事は情報更新しません。 はじめに プログラミング系の時事ネタは能動的に情報収集しないと入ってこないのですが、若手だった頃はどうやって情報を仕入れればよいのかさっぱり分かりませんでした。 情報収集のコツを掴んでからパッと視界が開けた経験があるので、特に新米エンジニアの方は参考にしてみてください。 ニュースアプリ Gunosy、SmartNewsなど色々試しましたが「はてなブックマーク」がプログラミング系記事多めでした。 通勤時間などに流し読みして、気になるものは深く調べると良いです。 はてなブックマーク はてなブックマーク - 人気エントリー - テクノロジー ITニュース Webサイト TechCrunch Japan TechCrun
エンジニアお茶会 2020/08/19 pastak.icon @pastak この発表のゴール 現代のウェブブラウザの目指している方向性について紹介する モダンブラウザで使える最新の面白便利APIを紹介する ちゃんと仕様に入りそうなもの(Googleの力技で…も含む) （前半の各ベンダの話はpastak.icon個人の見解を含みます） 次ではない フロントエンドなんでも相談室 前提知識のコーナー "WebAPI"とは何を指すのか、標準化について ECMAScript Ecma InternationalにてECMA-262という規格番号 ほぼLiving Standardという雰囲気もあるけど、年に1回タグが付く ES2020: ECMAScript® 2020 Language Specification 最新の様子: https://tc39.es/ecma262/ Array、Nu
はじめに 2015年度新卒でドワンゴに入社しました@ytanakaといいます。普段はAndroidアプリ開発を主に担当していますが、大学院時代は増井俊之先生のもとでユーザインタフェースと情報推薦システムの研究をしていました。 ドワンゴに入社後、それまでの研究を活かしプログラマ向けのニュースキュレーションサービスMenthas(メンタス)を個人開発しました。今回はせっかくの機会なので、開発の経緯と概要そして仕組みについて述べたいと思います。 追記： 続編を書きました こちらの記事は以前のバージョンの内容になります。現行のMenthasの仕組み・構成は以下にまとめています。 約3年かけてプログラマ向けニュース推薦アプリを作り直した話 背景 さて、この記事をご覧になっているのはプログラマの方が多いと思いますが皆さん普段どうやって情報収集をしていますか？ 自分の見聞きする限りではTwitterやは
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
ド素人が完全自作SNSを作ってみてわかったこと。 http://anond.hatelabo.jp/20130104184115 の元増田です。 ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、 まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。 素人のフリをしているとか、出版社のステマだとか色々言われましたが、嘘は一切書いてないです。 ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスのステマにしかなっていないような気がします…。 公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。 ～増田記事を公開してから今までの経過～ ・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。 ⇓ ・以前、完全
Intro 「毎回やるなら bookmarklet にでもすれば?」と言ったら、後輩が「そんな便利なことできたんですね、知りませんでした」と言っていた。 そんな時代にこそ、今更だれも解説しないであろう、 bookmarklet という技術についてもう一度書いておく。 Bookmarklet 簡単に言えば、 JS を書き、それを Bookmark として登録すれば、クリックするだけで現在のページでそれが動くというものだ。 ブラウザ上で何かを自動化したいと思うなら、最も簡単に実現できる便利な技術だろう。 似たような手法ではブラウザの Extension などもあるが、 Bookmarklet の良いところは一切誰にも邪魔されないというところだ。 開発者登録も、ストアへのアップロードも、難解なドキュメントを忖度して煩雑な設定ファイルを書く必要もない。 開発者ツールで、「こんなことできないかな」と
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
達人出版会:技術系電子出版・電子書籍
探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う！ オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 なぜ依存を注入するのか DIの原理・原則とパターン Steven van Deursen, Mark Seemann(著), 須田智之(訳) 高機能ヘッドレスCMS『Storyblok』入門 大宮 薫 初めてのPython配布パッケージ作成 窓川 ほしき 今日から現場で使える速習SymbolブロックチェーンJavaScript版 特定非営利活動法人 NEM技術普及推進会NEMTUS 改訂新版 ファーストステップ情報通信ネ
http://www.meteor.com/ で公開された Meteor.js を少し触ってみました。TechCrunch なんかでも話題になっていましたね。 Meteor.js は JavaScript によるウェブアプリケーションフレームワークですが、クライアントサイドでもサーバーサイドでもない、"Isomorphic" なフレームワークです。 コンセプトとしていくつか特徴があるのですが、その最たるものは "Reactive Programming" で、モデルやセッションなどのストレージを更新するとその更新内容がリアルタイムに、そのアプリケーションを開いている全クライアントに伝わるようなアプリケーションを簡単に作ることができます。 この辺は実例を見るのが早いです。 http://www.meteor.com/examples/leaderboard ここにある動画では、あるブラウザで
はじめに 最近、サーバサイドJavaScript環境であるnode.jsをいじったりしています。 node.jsはまだ書籍も出ていない新しい分野なので、情報収集の手段はインターネットがすべてになります。Webサイトやブログなどを読みながら勉強していくにつれて、node.js界のすごい人たちというのがだんだんとわかってきました。 そこで、これからnode.jsを勉強する人のために、日本におけるnode.js界隈のスーパーエンジニアたちをまとめてみました。彼らの代表的なエントリを書かせていただきましたが、これ以外にもたくさん有用なエントリがあると思いますので、ぜひ探してみてください。 @mesoさん twitter：http://twitter.com/#!/meso おすすめエントリ Node.jsについてのよくある誤解 - 自分の感受性くらい @sugyanさん twitter：https
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
Web over HTTPS
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
はじめに node.jsが熱いですね。 これからnode.jsを勉強したり、node.jsで何かアプリケーション作ってみたいという人のために、node.jsの環境構築（インストール）系のエントリを集めてみました。 サーバサイドJavaScript Node.js入門posted with amazlet at 14.02.16清水俊博 大津繁樹 Jxck 小林秀和 佐々木庸平 篠崎祐輔 高木敦也 西山雄也 アスキー・メディアワークス 売り上げランキング: 247,116 Amazon.co.jpで詳細を見る プラットフォーム別に分けてみましたので、お好きな環境でnode.jsに触れてみてください。ざっと眺めてみた感じ、Macでやるのが一番簡単みたいです。 Windows + cygwin Windowsでもcygwinを入れてあげてればnode.jsは動きます。 node.jsをWindo
ちょっと趣向を変えてJavaScriptの情報をどうやって集めているかという話を書きたいと思います。 使っているもの Twitter RSS(feedly) Pocket はてブ TwitterはただフォローしてTL見ていたり検索してたまに見ているだけでリストを作ったりはしてなくて暇な時に見ている感じです。 RSSはこれから紹介するようなサイトとかこの人のブログ面白い！というものだけを登録しています。未読が100件増えると消化する気がどんどんなくなっていくので...。 PocketはTwitter、RSSで気になったものを後で読むためにとりあえず突っ込むのに使っています。 こうすることでRSSはすぐに終わるので、その後で時間があればPocketで読みます。 Pocketに溜まった記事はちょっとした合間に読んだりしていて、たまにまとめて読んだりして消化しています。 今見ると20件くらいあるの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
牧歌的 Cookie の終焉 | blog.jxck.io
ローカル開発環境の https 化 | blog.jxck.io
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
2021年にJavaScriptやNode.jsを勉強し始めたので、読んで良かった資料をまとめる
SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
XMLHttpRequest とはなんだったのか | blog.jxck.io
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
エンジニアの情報収集法まとめ - nesheep5's blog
面白Web API 100連発 - pastak-pub
プログラマ向けニュースキュレーションサービスを作ってみた話 - Qiita
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Webはインターネットになった - naoyaのはてなダイアリー
ド素人が完全自作SNSを二週間運営してみてわかったこと（後始末編、技術編、モチベーション編）
Bookmarklet という一番身近な自動化技術 | blog.jxck.io
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Spectre の脅威とウェブサイトが設定すべきヘッダーについて
Meteor.js - naoyaのはてなダイアリー
今すぐフォローすべきnode.js界のスーパーエンジニア - 小さい頃はエラ呼吸
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
これからnode.jsを始める人のためのインストール系エントリまとめ - 小さい頃はエラ呼吸
私のJavaScript情報の集め方 - Qiita