「URI」を含む日記

■細かすぎて伝わらないはてなブックマークのエントリーIDの話

はてブのブクマページにはIDがある。

htmlタグのdata-entry-eid属性に書いてある数字である。はてなブックマークエントリー情報取得APIでも取得できる。

これをエントリーIDと呼ぶ。

各ユーザーのブクマのURLは以下のようになっている。

https://b.hatena.ne.jp/entry/{エントリーID}/comment/{ユーザーID}

あるいはユーザーのブクマ一覧中のブクマにアクセスする以下のURLもある。

https://b.hatena.ne.jp/{ユーザーID}/{日付}#bookmark-{エントリーID}

ところがこのエントリーIDは1つのエントリーに複数存在する可能性がある。

たとえば以下のブクマページ。

https://b.hatena.ne.jp/entry/s/nordot.app/1211910352128279184

エントリーIDは4760262558153474272である。

だから各ブクマのURLは以下のようになる。

https://b.hatena.ne.jp/entry/4760262558153474272/comment/{ユーザーID}

しかし一部のブクマのURLは以下のようにエントリーIDの部分が異なる。

https://b.hatena.ne.jp/entry/4760262556542860384/comment/{ユーザーID}

ブクマページはエントリーIDを使ってアクセスすることもできる。

https://b.hatena.ne.jp/entry/{エントリーID}

だから以下のURLでブクマページにアクセスできる。

https://b.hatena.ne.jp/entry/4760262558153474272

別のエントリーIDらしきものでも同様にブクマページにアクセスできる。

https://b.hatena.ne.jp/entry/4760262556542860384

つまりエントリーIDは複数存在するようだが、ブクマページやAPIで取得できるエントリーIDはただ1つである。

4760262558153474272はエントリーIDとして取得できるが、4760262556542860384はブクマページを探してエントリーIDとして使用しているブクマを見つけることでしか取得できない。

何かが修正されたときにエントリーIDが変わることがあるのだろうか？

「はてなブックマークエントリー情報取得API」でエントリーIDと各ブクマのユーザーと投稿日時を取得して、これを使って「はてなスターカウントAPI」でブクマが得たスター数を取得する場合、通常は以下のURLでスター数を取得できる。

https://s.hatena.com/entry.json?uri=https://b.hatena.ne.jp/{ユーザーID}/{日付}#bookmark-{エントリーID}

(uri=以降のパラメーターはURLエンコードする)

ところがエントリーIDが異なるブクマは当然個別のエントリーIDでないとスター数を取得できないので、はてブAPIだけでは情報が欠損する。

わざわざ現場のブクマを1個1個見る必要がある。

追記

別に細かくなく公式で言及のあった話でしっかりと伝わったのでタイトルは誤りでした。

ブクマするURLにパラメーターが付いているとエントリーIDが変わるということだそうです。

ご教示ありがとうございます。

Permalink | 記事への反応(2) | 00:32

ツイートシェア

■anond:20240822200241

アドレスはURI、URL、URNとか言う言葉で表現される

URI（Uniform Resource Identifier）

　　URIは大枠のルール定義

URL（Uniform Resource Locator）

URN（Uniform Resource Name）

　　URLは住所、URNは名前とか言われる

URLは通信プロトコルなどを含む情報で

URNはそれらを含まない固有名称

大雑把にはそんな感じ

DNSなどの仕組みによって解決されてパケットが運ばれる

よく、「URIって呼べよ恥かしい」みたいな人いるけど、そっちが恥ずかしいです

例えば、下記のようなURLがあったとして

https://test:[email protected]/index.html:8080

① スキーム

https

　→　セキュアなhttpプロトコルを使いますよぉって提示

ここには、「ftp」や「アプリ呼び出しの文字列」などが入る

ブラウザからアプリが呼び出せたりするのはここ

② オーソリティ

//test:testpw@hogehogefugafuga.jp/index.html:8080

　ユーザー　：test

　パスワード：testpw

　ホスト　　：hogehogefugafuga.jp

　パス　　　：/index.html

　ポート　　：8080

という情報で構成される（ユーザー・パスはまず使われない）

hogehogefugafuga.jp　にアクセスしますよぉ、提示した情報でというもの

インターネットを作った人は全世界の人が使うようになる前提で、ややこしいhttp://を決めたのかなぁ？

こんなに使われることになるくらいならもっとシンプルなものにしてた可能性が高かったんじゃないかなと技術脳ゼロの自分は思ってしまうわけです。

すげぇシンプルです

これ以上シンプルにするって逆にどうやるの？

ちなみに、「www」はサブドメインなのです

例えばメールサーバーには、「mx」や「mail」などのサブドメインが付きます

　　mx.hogehogefugafuga.jp

これに対して、webサーバーを示すサブドメインとして「www」を使ったわけです

　　www.hogehogefugafuga.jp

すげぇシンプルです

Permalink | 記事への反応(2) | 10:42

ツイートシェア

■ニコニコ復活で、ニコ生で4年間集めていたデータ(コメントログ用URL)が全て無効になってしまって辛い

コメントログへのアクセス先URIが書かれたWebSocketのデータ(↓こういうの)を、4年間集めてたんだけど、

{"type":"room","data":{"name":"アリーナ","messageServer":{"uri":"wss://msgd.live2.nicovideo.jp/websocket","type":"niwavided"},"threadId":"M.QyofMf3h0ahYa9PujZiwMA","isFirst":true,"waybackkey":"waybackkey","vposBaseTime":"2022-11-21T18:30:00+09:00"}}

https://live.nicovideo.jp/watch/lv338977521

以前から「そのデータからコメントログを全取得する作業を今年とかにやらないとな…」と思ってたが、ニコニコへの大規模攻撃が起こってしまって、さらに嫌な予感がしたがニコ生復活後に的中した。

まだ確認していないけども、自分が集めてたそのデータが全部無効になってしまってるだろうし、何も言えねえ。

(大規模攻撃関係無くいつか「wss://msgd.live2.nicovideo.jp/」が変わってただろうけども、長い事(数年間)そのuriで運用されていたし、もし攻撃されてなければ間に合う可能性もあった訳で…。)

溜め息しか出ない。

やっちまったなあ…。

ちなみに公式によるアニメ一挙配信のを主に集めてた。

運営に望む事は「有料会員は過去の生配信のコメントログがダウンロードできる」とか今後そういうサービスしてくれないかな…。はあ。

ちなみに、ニコ生がHTML5プレーヤー以前だった頃のソケット通信によるコメントログ取得って、もうできないよね…。　ちなみにそれもxmlファイルが1年分ぐらい溜めてる…。

Permalink | 記事への反応(1) | 19:56

ツイートシェア

■anond:20240528235414

そのURI、質問コーナーであって通報窓口ではないのでは？

Permalink | 記事への反応(0) | 08:16

ツイートシェア

■気持ちいい

女性のイラストレーターに嫌がらせしてる

健全な絵で18禁小説の挿絵をお願いしてる

アダルトな絵は描きません！って宣言してたり

ふわふわした可愛らしい絵柄を狙うのな。

お礼いいつつ作品のURI紹介するとすごい怒ってくるの。たのちい。えへへへ。

Permalink | 記事への反応(2) | 09:46

ツイートシェア

■anond:20230817212506

URIまたは特定できる名前を提示したほうがいいよ

それでフェミをガツンとやっつけてくれぃ！

Permalink | 記事への反応(0) | 21:26

ツイートシェア

■anond:20230817211612

そんな統計あるの？

なんで言う統計？

URIは？

Permalink | 記事への反応(1) | 21:18

ツイートシェア

■Next.js + nginx in Docker でハマった

Next.js を勉強中なんだが、Docker で negix (web) と Next.js のコンテナを起動していて、Next.js から web の API (ttp://127.0.0.1:8080 とする) を fetch するときに、Next.js 側がサーバーコンポーネントの場合 URI に ttp://127.0.0.1:8080 を指定すると fetch failed する。ttp://host.docker.internal:8080 じゃないと駄目だった。

やられた。これで何日持っていかれたのか。

クライアントコンポーネントだと ttp://127.0.0.1:8080 で普通に動作する。サーバーコンポーネントでも httpbin.org などの他の API は正常に動作する。web 側で Access-Controll-Allow-Origin も設定されている。だから、まー謎だった。エラーメッセージも全然詳しくねーし。

Twitter では死んだふりをしてるので取り急ぎここにメモ。SNS に復活することがあったらあとで消す。

参考

ttps://qiita.com/YasuhaF/items/8a72d2898736fb60315f

Permalink | 記事への反応(0) | 20:29

ツイートシェア

■anond:20230504230248

スタックトレースを読んだらrbsのリポジトリに書かれている定義を読んでいることがわかったんだけど、このディレクトリにopen-uriがないのよね。

https://github.com/ruby/rbs/tree/master/stdlib

---

結論、以下のメソッド定義が公式で提供しているのかと思ったのだけど、用意されていない!!

```

[error] Type `singleton(::URI)` does not have method `open`

│ Diagnostic ID: Ruby::NoMethod

│

└ response = URI.open 'https://api.github.com/XXXX'

```

余談だけど、steep、libraryがない時に各プロセスでスタックトレースを出すからエラーが不親切なのん。

Permalink | 記事への反応(0) | 23:37

ツイートシェア

■rubyで型を使ってみるぞ

Steepfileに `library "open-uri"` って書いたら ` `block in each_dir': Cannot find type definitions for library: open-uri ([nil]) (RBS::EnvironmentLoader::UnknownLibraryError)` っていうエラーになった。rubyの型システムは意味不明なんだよ。やめます！

Permalink | 記事への反応(1) | 22:47

ツイートシェア

■anond:20230206141008

なんだよブクマカの被スター数はAPIで一発じゃんかよ

ttps://s.hatena.ne.jp/blog.json?uri=http://b.hatena.ne.jp/はてなID/　　　　もしくは

ttps://s.hatena.ne.jp/blog.json?uri=https://b.hatena.ne.jp/はてなID/

プライベートモードでも404でも出てくるのでオススメ.

参考　anond:20230131183629

Permalink | 記事への反応(0) | 00:44

ツイートシェア

■anond:20230131183629

ブコメでも指摘されてるけども。

ある時を境にスターの集計先になるURLが切り替わっているので、すべてのスター数を知るためには2回APIを投げる必要がありそうだ。

たぶんはてブがHTTPS化された2019年5月あたりが境目だろう

https://bookmark.hatenastaff.com/entry/2019/05/28/141208

自分のはてなIDと昔使ってたIDで試した限りではこうなっているはず。

①ttps://s.hatena.ne.jp/blog.json?uri=http://b.hatena.ne.jp/はてなID/

②ttps://s.hatena.ne.jp/blog.json?uri=https://b.hatena.ne.jp/はてなID/

Permalink | 記事への反応(0) | 23:06

ツイートシェア

■なんだよブクマカの被スター数はAPIで一発じゃんかよ

これで出る。(出ない人もいる？)

ttps://s.hatena.ne.jp/blog.json?uri=http://b.hatena.ne.jp/はてなID/

はてなスターカウントAPIのドキュメントにブクマカの被スター数が取れるなんて書いてない。

裏技かYO.

しかし私が欲するのは誰が誰にいくつスターを付けたかってことなので求めてるものとはちょっと違う。

Permalink | 記事への反応(7) | 18:36

ツイートシェア

■anond:20230120231229

動画出た瞬間はまだURI出てなかったからなあ　ポータルは貼れてもそのものはそもそも貼れなかった

Permalink | 記事への反応(1) | 04:07

ツイートシェア

■

暇、パブコメのURI書かなかったのえらいな

いままでの社会問題提起系とは一線を画す、ちゃんと戦う意思を示して目的を明確にし、安易に味方を作らない

ずっと「こうあるべきだ」とかいう社会活動に対して持ってた疑念が、この点が不明瞭な人ばっかだったからというのはこの出来事を通してわかったこと

Permalink | 記事への反応(1) | 23:12

ツイートシェア

■anond:20221118203953

下書きなしで書く時、自分の貼りたいURIは9個未満なのか10個以上なのかわからないからエラー吐かれるよりは…とおもって最初からｈ抜きというのもないわけではない

Permalink | 記事への反応(1) | 08:40

ツイートシェア

■「【初心者向け】第2回 クソコードを書かないためのテクニック4選」という動画の内容がひどい

https://www.youtube.com/watch?v=yhDLmGpjdms

これよりもっとひどい動画はごまんとあるが、ここまでタイトルで煽っている以上指摘するわ。

全体を通じて

• Ruby なのにインデントがスペース4つ（タブ？）
• Ruby なのに戻り値に return を付けている
• 3問目に突然現れるRubyライクの架空の言語（function - end の形で関数定義する言語で、かつ elsif と表記する言語を自分はしらない）

個別

• 1問目にて、引数としてto_iしたものを渡せばよいと言っているがあえてそうするメリットがない（インスタンスで渡せばいい）
• 2問目にて、Ruby なのに is とか has とかをメソッド名に使っている（それをしないための接尾語「?」なのに）
• 3問目にて、変更後は変更前と挙動が異なる（変更後は例外が発生することがありうる）
• 4問目、これが最悪で、まずメソッド名がget_first_url_parameters_keyとあるが、「first」ならば「url_parameter_key」である（複数形ではない）
• 4問目、頑張って変数名を修正したようだが、修正後のfirst_parameter_keyはkeyではなく、keyとvalueである（ただしハッシュではなく文字列）
• 4問目、そもそもロジックが間違っていて、url.split('?').first だとURLパラメータ以前の部分が取得される
• 4問目、「ライブラリを漁ってみたらもっとうまく書けるかも」と言っているが、URLパラメータの処理をするのに文字列操作を行っている時点でひどいし、それの修正の手段として標準ライブラリを使う方法を提示しないというのはひどい（これは初心者でもURIモジュール使うレベルだし、使うべき）

プロフィール見るとCTOを経て独立してプログラミングスクールの会社やっているっぽいけど、すごい時代だな。

晒しになっちゃったけど、他にも有名（と思われる）プログラミング系YouTuberが実際にコードを書いている場合でひどいのはザクザク見つけられるから、見つけてため息をつくといいと思います。

Permalink | 記事への反応(3) | 11:35

ツイートシェア

■[はてブ]関連ページ・RSS一覧

はてブについて、情報検索したりクエリを投げたりして調べてまとめてみた。自分用メモとして書いたもので、極少数の人しか興味を持たない内容かと思うが、読んでいただければ幸い。

公式等[1・2（参照したページURLを最後に記載。以下同様）]で詳細を確かめられず素人の憶測で説明した箇所がいくつもあり、簡潔明瞭でも網羅的でもない解説だがご容赦を。

トップページ

ホットエントリと新着エントリの一覧への導線がある。

URL

1. https://b.hatena.ne.jp/

1a. https://b.hatena.ne.jp/hotentry/{1}（引数に"all"を入力した場合、1のエイリアス）

1b. https://b.hatena.ne.jp/ctop/{1}（カテゴリトップ[3]が過去に存在していた場合、1aにリダイレクト）

1c. https://b.hatena.ne.jp/hotentry/{1}/{2}

1d. https://b.hatena.ne.jp/hotentry/{1}/daily（1cにリダイレクト。前々日か前日の分が表示される）

1e. https://b.hatena.ne.jp/hotentry/{1}/{3}(?page={4})（()内のパラメータは省略可。以下同様）

1f. https://b.hatena.ne.jp/hotentry/{1}/{3}(?of={5})

2a. https://b.hatena.ne.jp/hotentry.rss

2b. https://b.hatena.ne.jp/hotentry/{1}.rss（"all"を入力した場合、2aのエイリアス）

2c. https://b.hatena.ne.jp/hotentry?mode=rss（2aのエイリアス）

2d. https://feeds.feedburner.com/hatena/b/hotentry（2aのエイリアス）[4]

3. https://b.hatena.ne.jp/entrylist/{1}(/{3}?page={4})（ブクマ登録数の閾値を設定するオプションがあったが、2018年3月に廃止された[5]）

4a. https://b.hatena.ne.jp/entrylist.rss

4b. https://b.hatena.ne.jp/entrylist/{1}.rss（"all"を入力した場合、4aのエイリアス）

4c. https://b.hatena.ne.jp/entrylist?mode=rss（4aのエイリアス）

カテゴリ

エントリは、8種類あるカテゴリ[7]のどれか1つに自動で区分される。そのアルゴリズムは不定期に更新されているようだ[8]。区分に異議がある場合、ユーザが変更申請することもできる[8・9]。

カテゴリは2013年2月に現在の名称・分類になった[10]。分類が現在と同じ8種類になったのは、2008年11月[11]。

なお、2011年以前のエントリはほぼ全て「暮らし」カテゴリに区分されている[12]。2017年から2019年の間に何らかの障害が起きたためと思われる[13・14・15]。

エントリページ

別名、ブックマークコメント一覧ページ[16]。

なお「（ブックマーク）エントリ」という呼称は、一般的用法、はてブに登録されたURLとその付帯情報、エントリページの情報等、多様な意味で使われる。

URL等

1a. https://b.hatena.ne.jp/entry/(s/){1}（"s/"はセキュアサイトのエントリページURLに付加される[16]）

1b. https://b.hatena.ne.jp/entry/{2}（正しく処理された場合、1aにリダイレクト）

1c. https://b.hatena.ne.jp/entry/{3}（1aにリダイレクト）

1d. https://b.hatena.ne.jp/entry?url={2}（1aのエイリアス）

1e. https://b.hatena.ne.jp/entry?eid={3}（1aのエイリアス）

2. (b:)id:entry:{3}（はてな記法[17・18]）

エントリID

はてブに登録されたURLはIDと1対1対応する。IDは、当初は1から始まる連番だったが、2018年12月頃から62bit以上の乱数値になった[20]。

余談だが、かつては番号が桁繰上りするたびにキリ番ゲッターがブクマしに集っていたようだ。理由は不明だが、欠番になったキリ番もある（キリ番と前後のエントリページ参照）。

エントリ統合

URLとwebページは1対1対応するとは限らない[21][22]ため、エントリ・ブコメは容易に分散する。

その改善のため2019年2月にはてブの仕様が変更され、一定の規則でエントリが収斂されるようになった[23]。現在エントリページは、複数のエントリと1対多対応していて、対応するどのID・URLを引数にしてもアクセスできる。

1対多対応の例

参考[1]のエントリページに対応するIDを昇順にし、各IDの確認できる最古のエントリをまとめた。非公開や削除済のブクマがあるせいか、完全な日付昇順ではない。

IDが正しく認識されない場合

以下に該当するIDやURLを引数として入力すると、エントリの一部または全ての情報の取得に失敗する

• 登録されたことが無いもの
• 登録されたブクマが全て削除されたもの
• 非公開ブクマしか登録されていないもの
• 特定文字（"&"[24]"#"[25]等）を含むURL文字列
• アクセス不能になったもの[26・27・28]

ブックマークコメントページ

コメントと、それに付けられたスターの情報が表示される。

URL

1. https://b.hatena.ne.jp/{1}/{2}#bookmark-{3}

2. https://b.hatena.ne.jp/entry/{4}/comment/{1}

検索ページ

はてブの全エントリから検索可能[29]。ただし単語の区切の判定が完璧でないため、連語や複合語等が関わると上手く動かない場合がある（例えば、「更年」で検索したら「更年期障害で欠勤、認められず」というタイトルがヒットしなかった）。

URL

1a. https://b.hatena.ne.jp/search/{1}?q={2}(&sort={3}&users={4}&safe={5}&date_begin={6}&date_end={7}&page={8}&mode={9})

1b. https://b.hatena.ne.jp/t/{2}（1aにリダイレクト）

2a. https://b.hatena.ne.jp/site/{10}(?sort={11}&page={8})

2b. https://b.hatena.ne.jp/entrylist?url={10}（2aにリダイレクト）

ユーザブックマークページ

各ユーザがブクマしたエントリが一覧表示される。

URL等

1a. https://b.hatena.ne.jp/{1}/(?page={2})

1b. https://b.hatena.ne.jp/{1}/?tag={3}(&tag={3}&page={2})

1c. https://b.hatena.ne.jp/{1}/{3}(/{3})（1bのエイリアス）

1d. https://b.hatena.ne.jp/{1}/{4}

1e. https://b.hatena.ne.jp/{1}/?url={5}(&page={2})

1f. https://b.hatena.ne.jp/{1}/bookmark（1aのエイリアス）

2a. https://b.hatena.ne.jp/{1}/bookmark.rss(?page={2})

2b. https://b.hatena.ne.jp/{1}/bookmark.rss?tag={3}(&tag={3}&page={2})

2c. https://b.hatena.ne.jp/{1}/bookmark.rss?date={4}

2d. https://b.hatena.ne.jp/{1}/bookmark.rss?url={5}(&page={2})

2e. https://b.hatena.ne.jp/{1}/rss（2aにリダイレクト）

3. https://b.hatena.ne.jp/{1}/search.data(?limit={6}&offset={7}) [31]

4. (b:)id:{1}(:{4}) [17]

マイブックマークページ

前節とほぼ同様だが、利用可能なオプションが多い[32・33]。

はてなスター

ログインすると、スター情報を閲覧できる。

余談だが、カラースターの価値は緑5円・赤12円・青110円・紫890円程度のようだ[34]。

URL

1. https://s.hatena.ne.jp/

2. https://s.hatena.com/（1のエイリアス）

3. https://s.st-hatena.com/（1にリダイレクト）

参考URL

ブクマされてるURLにはIDを付記。

anond:20220521221139 に続く

Permalink | 記事への反応(2) | 22:09

ツイートシェア

■anond:20220508112857

Uniform Resource Identifier (URI): 一般的構文

https://triple-underscore.github.io/rfc-others/RFC3986-ja.html#section-3

 URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

 hier-part   = "//" authority path-abempty
             / path-absolute
             / path-rootless
             / path-empty

: は scheme と hier-part を区切るために必要

// は 後に続くトークンが "authority path-abempty" とそれ以外であることを区別するのに必要

Permalink | 記事への反応(0) | 11:37

ツイートシェア

■きれそう

String path; // なかみはURI文字列

String uri; // なかみはパス文字列(/から始まるかどうかは不明)

ほんとこういうの書くやつ死んでくれ。殺意しかわかない

この実装のまま至るところで利用してるし、書いてる途中で自分の脳みそがばぐってるこにきがつかねーのか？ああ？ころすぞボケ

Permalink | 記事への反応(1) | 15:50

ツイートシェア

■anond:20211125112606

data:URIスキームっていうのでできるのは知ってる。

けど、それじゃ固定されたjpgデータしか埋め込めないじゃん。

使用する人のお好みに応じて、好きなjpgファイルをhtmlファイルと同階層に置いとけば表示できるようにしたいねんw

Permalink | 記事への反応(0) | 11:10

ツイートシェア

■anond:20210829130354

URLでは通信してないな

プロトコルとしてはhttp(httpsを含む)、アドレスの仕組みにURL(URI)を使ってるって話

Permalink | 記事への反応(0) | 13:05

ツイートシェア

■anond:20210802223623

まぁ、少なくとも画像認識系のAIは医師の仕事を奪ったね。交通事故が減ったから。あと、デンソーの QR コードは「DX」だと思う。人間から URI の、手入力を奪ったし。

Permalink | 記事への反応(0) | 22:39

ツイートシェア

■何故 Fastly を使うのか

数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。

キャッシュが消えるのがはやい

CDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。

これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタイムに更新していくことができる。 next.js + vercel などはこのあたりをフロントエンドから CDN まで一気通貫に提供することでリアルタイム風にコンテンツを更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。

設定の反映が速い

CDN の設定の反映の遅さというのは Cloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。

ただし上記の特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点を比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害はマジで全部落ちたのでこれとは関係ない問題だろう)。

Webからの設定が豊富+ツボを抑えている

Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。

いざとなれば Varnish の設定ファイル(VCL)をアップロードできる

大抵のユーザーは Web からの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルのスニペットをアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードを VCL でやってしまって、同じ URI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。

ただし VCL でいろいろな制御を実現しようと思うと、 VCL の表現力の低さにより地獄を見ることになるので、得られるベネフィットと相談しながらこのあたりはやっていくことになる。

Permalink | 記事への反応(6) | 09:53

ツイートシェア

■「PCのインターネット」の時代

「URLが分からない」はって定番ネタだよね。

2021年 https://togetter.com/li/1694773

2018年 https://togetter.com/li/1297268

そもそも「URLが分かる」方が例外だろうし。そこで雑だけどURL(URI)が分かる可能性が高い、PCのインターネットってやつに親和性の高い例外的な時代を取り出してみるよ！

古い側は、1995年。Windows95だもん。この時に20代なら、影響を受けている可能性が高いと仮定するよ。

一方の新しい側は、2005年とするよ。一応目安はあるんです。

前略プロフィールは、2004年開始。

https://ja.wikipedia.org/wiki/%E5%89%8D%E7%95%A5%E3%83%97%E3%83%AD%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB

こんな証言もあるよ。

https://kakeru.me/other/snl-zenryakuprofile/

「私たちの間で前略プロフが流行っていたのは、mixiが流行りだすよりも前。約10年前の2005年頃～2007年頃、中学2年生の頃ですね。」

魔法のiらんどは、サービス開始こそ1999年だけど、2006年に企業名を株式会社魔法のiらんどに変更。

https://ja.wikipedia.org/wiki/%E9%AD%94%E6%B3%95%E3%81%AEi%E3%82%89%E3%82%93%E3%81%A9

だから、2005年には携帯ネット接続がPCによるそれを凌駕していたと仮定して、この時期以降に高校生だったらPCより携帯が主になると仮定するよ。実際はもう少し前からこの状態だっただろうけどね。

• 1995年に29歳だった人は1966年生まれ
• 2005年に18歳だった人は1987年生まれ

というわけで、1966～1987年生まれの世代が、「PCのインターネット」のコア世代と勝手に推定してみる。もちろん雑な仮定だけどね！

2021年の年齢に換算すると34～55歳。なんとなく目安になってる・・・ような気がしない？

Permalink | 記事への反応(0) | 01:24

ツイートシェア