「URI」を含む日記

■[増田しぐさ] 増田CSSを紹介する記事(英文スパム対策付き)

Chrome系ブラウザには増田を快適に閲覧するための コンパクトな増田 という古い拡張機能があったが、Chromeの更新に対応し切れておらず、既にChromeには新規インストールできなくなってしまっている。Edgeにはまだインストール可能だが、いずれ対応しなくなる可能性が高い。

そこで、「増田のトップページで、言及エントリ(返信・トラバ)を一覧から除外することで、新規エントリだけを一覧できる」という機能に絞ってコンパクトな増田を再現、ついでにいくつかのおまけ機能を付与したスタイルシート(CSS)を今年の4月に公開していたのだが、今回改めて英文スパム対策を追加したので公開する。

これを導入するには Stylus という拡張が必要で、少し気軽さには欠けるが、増田以外にも活用できるので、この機会にぜひ導入してみてほしい。拡張をインストールしたあとは、下記のコードをコピペして新規スタイルとして導入する方法もあるが、スタイルシートを公開できる userstyles.world の増田CSSページ^{(※毎朝9:00直後はアクセスできない)} から [Install] ボタンでインストールするほうが、自動更新にも対応するので便利かもしれない。

増田CSS (7/20: 増田の文字数制限のため、スパム対策部分は省略しました)

/* トップページで言及エントリを除外 */
/* via: 最近ファーストブクマカが静か https://anond.hatelabo.jp/20250326171302 */
h1/*はてな匿名ダイアリー*/ + #intro/*名前を隠して楽しく日記。*/ + #body div.section:has(h3 > a/*■*/ + a:not(.keyword, .edit)/*anond:YYYYMMDDhhmmss*/){
  display: none;
}

/* うっかりクリックしがちなキーワードリンクを無効に */
a.keyword{
  pointer-events: none;
}

/* 執筆時のテキストエリアを広く */
textarea#text-body{
  min-height: 50vh !important;
}

/* 執筆時に特殊記号のヒント(疑似要素なので選択してコピペできないのがもどかしいけど) */
p.post-submit > span.explain::after{
  margin-left: 1em;
  padding-left: 1em;
  content: "特殊記号: &[&#38;] <[&#60;] >[&#62;]";
  background: url(/images/common/outsite-wh.gif) 0 3px no-repeat;
}

/* スパム対策部分は下記URLの [Install] ボタンで事前確認できます(随時更新中) */
/* https://userstyles.world/style/23028/ */

なお、このCSSを適用すると、NGワードを含むこの増田自体も、増田トップページからは消えてしまう(この増田単体の個別ページなら閲覧できる)。

PC・スマホ向けの導入方法

念のため、PC・スマホにCSSを適用する方法の解説にもリンクしておく。

PC: 【Stylus】ウェブサイトにCSSを適用できる拡張機能。自由にカスタマイズ！ | ナポリタン寿司のPC日記

https://www.naporitansushi.com/stylus/

※ StylusはFirefox版もある https://addons.mozilla.org/ja/firefox/addon/styl-us/

iPhone: MaKeoverアプリでiPhone SafariのCSSをカスタマイズ！万博パビリオン予約結果一覧を見やすくする使い方

https://gintachan.com/makeover-app-css-change-safari-how-to/

Android: スマートフォン Android版FirefoxのCSSカスタマイズ Stylus の使い方・初期設定方法

https://skypenguin.net/2025/06/21/post-109209/

(7/21追記) また、スパムが特に多い時は、1ページまるごとスパムということもあるので、PCなら uAutoPagerize (Chrome) や weAutoPagerize (Firefox) などの拡張を使うと、自動でページが継ぎ足されて快適に読み進められる。ただし、継ぎ足ししまくるとメモリ不足などでブラウザが重くなることがあるので、そうなったら page: 20 などのページ番号をクリックしてから続きを読もう。

(参考) 増田の頻出キーワードリンク上位20件抽出JavaScript

また、スパム対策の簡易NGワードは、下記のスクリプトを使って抽出した「直近の増田の頻出キーワードリンク上位20件」から、誤判定しそうな line と user を除いた18件を用いた。10件だと生き残る英文スパムがあったので20件にしたが、それでもわずかに洩れはある。しかし日本語による真っ当な(?)増田の直近の誤判定はなかった。はてなキーワードのリンクだけを対象にしているので、URLにはこれらのキーワードが入っていても大丈夫だ。ただし、スパムのトレンドが変われば話は変わってくるかもしれないし、過去や未来の増田の誤判定は当然あるだろう。気になる人は前掲のCSSを行単位で編集してほしい。

// AutoPagerizeでまとまった数のページを読み込ませた後に実行するとよい。
(function(){
  const keywords = [];
  // はてなキーワードの集計
  document.querySelectorAll('a.keyword').forEach(a => {
    // 4文字未満は誤検出の可能性が高まるので除外
    if(a.textContent.length < 4) return;
    let index = keywords.findIndex(k => k.keyword === a.textContent);
    if(index >= 0) keywords[index].count += 1;
    else keywords.push({keyword: a.textContent, count: 1});
  });
  keywords.sort((a, b) => a.count < b.count);
  // ランキング配列の出力
  console.log(keywords);
  // CSS埋め込み用に上位キーワードのみをURIエンコードして出力
  console.log(keywords.slice(0, 20).map(k => encodeURIComponent(k.keyword)).join('\n'));
})();

謝辞

anond:20250326171302 ←元はこの増田がきっかけでした。

anond:20250701194328 ←キーワード判定に踏み切る後押しとなりました。

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

ツイートシェア

■anond:20250624154639

じゃあ URI 作れないから商品ページやLPに直リン出来ないね

Permalink | 記事への反応(0) | 15:48

ツイートシェア

■

これJAL以外でもよくあるけどだいたいChromeの謎制約が原因でEdgeとかSafariなら問題なかったりするんだよなあ

CookieだかURIだかが長すぎると蹴られる

JALのダイナミックパッケージで予約した国内線旅程のフライト情報見ようとすると「Bad Request」になって強制終了でページが出ないんだけど、これどうやれば座席表見たりカレンダーに旅程登録（旅程表をメールで送信）できるんだ？— J (@j17sf) February 19, 2025

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

ツイートシェア

■anond:20250122201211

XのAPIのエンドポイントURIは2025年現在においても未だtweetという用語を用いているし、リポストはretweetのまま。

表書きこそXに名前を変えているが、後方互換性を保つためにもXのシステム内部はpost/repostではなくtweet/retweetで稼働しているんだよね。

イーロンの薄っぺらな施策で名前を変えたところで、イーロンにはシステム内部を変更して後方互換性を断ち切る決断力も技術力もないから内部はずっとそのまま。

その状況でソースコード外だけ改名を適用すると紛らわしくなるから、イーロンの改名はなかったことにしたほうが好都合なんだよね。

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

ツイートシェア

■anond:20250109070331

こういう疑問こそ、生成AIに回答を作ってもらうのが良いと思うよ。

Perplexity PROに聞いてみたよ。

質問

「大学の入学定員のアファーマティブアクションとして女子枠が設定されているのは日本だけですか？海外で女子枠が一般的にある国を列挙してください。特にEU諸国での考え方が気になっています」

回答：

　大学入学定員における女子枠の設定は、日本に限らず世界の多くの国で実施されています。ただし、その形態や規模は国によって異なります。以下に、女子枠が比較的一般的な国々を列挙し、特にEU諸国の状況について説明します。

女子枠が一般的な国々

1. インド

2. パキスタン

3. バングラデシュ

4. マレーシア

5. 韓国

6. 中国（一部の大学や専攻）

7. アメリカ（一部の大学や専攻）

EU諸国の状況

EUでは、高等教育における性別による直接的な割当制（クオータ制）は一般的ではありません。しかし、ジェンダー平等を促進するための様々な取り組みが行われています[1][6]。

EUの基本的な考え方

1. 法的枠組み：EUの基本条約では、男女平等の促進が重要な価値として位置づけられています[28]。

2. ポジティブ・アクション：EUは、形式的な平等だけでなく、実質的な平等の実現を目指しています。これには、一時的な特別措置（ポジティブ・アクション）の実施も含まれます[6][31]。

3. 分野別アプローチ：特に理工系（STEM分野）における女性の参画を促進するための取り組みが行われています[28]。

具体的な取り組み

1. ソフトロー：法的拘束力のない指針や勧告を通じて、ジェンダー平等を推進しています[11]。

2. 財政的支援：女性の参画を促進するためのプログラムに資金を提供しています[11]。

3. データ収集と分析：European Institute for Gender Equalityなどの機関を通じて、ジェンダー平等の進捗状況を継続的に監視しています[28]。

4. 企業の取締役会におけるクオータ制：一部のEU加盟国（フランス、ドイツ、イタリアなど）では、上場企業の取締役会における女性比率の目標を設定しています[10]。

日本の状況との比較

日本の大学入試における「女子枠」の設定は、EUの一般的なアプローチとは異なります。日本の取り組みは、特定の分野（主に理工系）における女性の参画を直接的に促進することを目的としています[15][18]。

一方、EUでは、教育システム全体を通じてジェンダー平等を促進する包括的なアプローチを採用しています。これには、早期教育からのステレオタイプの排除、キャリア指導の改善、ロールモデルの提示などが含まれます[28]。

結論として、大学入学定員における明示的な「女子枠」の設定は、日本を含むアジアの一部の国々でより一般的であり、EUでは直接的なクオータ制よりも、包括的かつ長期的なアプローチが採用されていると言えます。

Citations:

[1] spaceshipearth.jp/affirmative-action/

[2] univ-journal.jp/column/2024249156/

[3] feminist.org/news/european-court-of-justice-strikes-down-affirmative-action-law/

[4] mainichi.jp/univ/articles/20240925/ddm/010/100/018000c

[5] note.com/yourchoice_ycp/n/n644ad1296281

[6] www.jil.go.jp/institute/zassi/backnumber/2014/07/pdf/060-069.pdf

[7] eur-lex.europa.eu/legal-content/EN/TXT/?uri=legissum%3Ac10935

[8] jbpress.ismedia.jp/articles/-/80117

[9] www.kaonavi.jp/dictionary/affirmative-action/

[10] ja.wikipedia.org/wiki/%E3%82%A2%E3%83%95%E3%82%A1%E3%83%BC%E3%83%9E%E3%83%86%E3%82%A3%E3%83%96%E3%83%BB%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

[11] ehne.fr/en/encyclopedia/themes/gender-and-europe/gender-citizenship-in-europe/european-union-gender-equality-policies-1957

[12] www.keinet.ne.jp/teacher/media/guideline/backnumber/23/0203/shiten3.pdf

[13] www.gender.go.jp/kaigi/kento/positive/siryo/pdf/po02-2.pdf

[14] revistaidees.cat/en/la-unio-europea-a-lavantguarda-de-les-politiques-digualtat/?pdf=12310

[15] www.yomiuri.co.jp/kyoiku/kyoiku/daigakunyushi/20240308-OYT1T50053/

[16] waseda.repo.nii.ac.jp/record/10032/files/Honbun-7017.pdf

[17] www.nytimes.com/1997/11/12/world/european-union-court-upholds-affirmative-action-for-women.html

[18] www.nikkei.com/article/DGXZQOCD17DER0X10C24A7000000/

[19] journals.sagepub.com/doi/10.1177/00016993231163416?icid=int.sj-abstract.citing-articles.34

[20] news.tv-asahi.co.jp/news_society/articles/000341947.html

[21] www.eigo-net.jp/easy_readings/easy_readings-3403

[22] note.com/wakari_te/n/n8e298c2e524c

[23] eic.obunsha.co.jp/file/exam_info/2024/1108.pdf

[24] www.koov.io/column/13499

[25] www.gender.go.jp/policy/positive_act/pdf/positive_action_011.pdf

[26] www.gender.go.jp/research/kenkyu/ishiki/kekka53.html

[27] corp.miidas.jp/assessment/10794/

[28] commission.europa.eu/document/download/965ed6c9-3983-4299-8581-046bf0735702_en

[29] mainichi.jp/articles/20240426/k00/00m/040/090000c

[30] www.hosei.ac.jp/diversity/publication/newsletter/vol3-1/?auth=9abbb458a78210eb174f4bdd385bcf54

[31] www.era-comm.eu/oldoku/SNLLaw/04_Positive_action/116DV06_Selanec_EN.pdf

[32] admissions.titech.ac.jp/admissions/admission/admission/international

追加質問：アメリカでの状況を教えて

回答

アメリカの大学における女子枠の状況は、日本とは大きく異なります。

アファーマティブ・アクションの歴史と現状

アメリカでは、1972年の平等機会法（Equal Opportunities Act）以降、人種間の不平等是正を目的としたアファーマティブ・アクションが実施されてきました[4]。しかし、近年では性別に基づく優遇措置に対して批判が高まっています。

女子枠に対する批判

1. 法的問題：性別に基づく入学枠の設定は、教育改正法第9編（タイトル・ナイン）に違反する可能性があるとして、多くの苦情が申し立てられています[3]。

2. 男性への不利益：現在の大学では、むしろ男性が不利な状況にあるという主張があります[3]。

3. 違憲判断：2023年6月、最高裁判所がハーバード大学とノースカロライナ大学のアファーマティブ・アクションを違憲と判断しました[5]。

大学の対応

多くの大学が、性別に基づく優遇措置を廃止する動きを見せています：

1. 女性向け奨学金の廃止

2. 女性限定のリーダーシップ研修の中止

3. 女性のみを対象とした表彰制度の撤廃[3]

現在の状況

アメリカの大学、特にトップスクールでは、男女比がほぼ半々になっています。例えば、スタンフォード大学のコンピュータサイエンス専攻では、3人に1人が女子学生です[2]。

このように、アメリカでは明示的な「女子枠」ではなく、長期的かつ包括的なアプローチによってジェンダーバランスの改善を図ってきた結果、現在の状況に至っています。

Citations:

[1] note.com/wakari_te/n/n8e298c2e524c

[2] www.koov.io/column/13499

[3] forbesjapan.com/articles/detail/47454

[4] ipdi.w3.kanazawa-u.ac.jp/cdl/houkoku/doc/090317ppt.pdf

[5] x.com/LazyWorkz/status/1816616538717454751

[6] www.jstage.jst.go.jp/article/kyoiku/89/4/89_683/_pdf/-char/ja

[7] twitter.com/mph_for_doctors/status/1722428813601345935

[8] www.youtube.com/watch?v=MzQCj1EnZzI

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

ツイートシェア

■細かすぎて伝わらないはてなブックマークのエントリー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

ツイートシェア

■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: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 | 記事への反応(6) | 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

ツイートシェア