  |
はてなキーワード: 記法とは
https://b.hatena.ne.jp/site/anond.hatelabo.jp
で動くスクリプトでたとえば投稿後10分以内にブクマされページに乗ったら「1 user」が「1 user セルクマ 1とか5(何分後にブクマされたか)」になる。もしマイナスなら誤判定なので無視して。
時間を置いたセルクマには効かないし普通のファーストブクマカがどれぐらいの頻度で確認してるかしらないけど5分以内や1分以内もポロポロあるのでまあ目安に。
.forEach(div => {
('.entrylist-contents-title > a')
とかの
を
<>
に変えてね
他にも見落としあるかも
誤判定が減るから非公開ファーストブクマを判定できたらいいんだけどね。
// ==UserScript== // @name hatebu masuda selkmark // @namespace http://tampermonkey.net/ // @version 0.1 // @description 特定時間以内にブクマされた増田を強調する // @author You // @match https://b.hatena.ne.jp/site/anond.hatelabo.jp* // @grant none // ==/UserScript== (function() { 'use strict'; const threshold = 60 * 10 // 何秒以内か const domain = 'https://anond.hatelabo.jp/' const dateTemplate = '202301020304' // 時分まで urlの時刻表記 const dateTest = new RegExp('\\d{' + dateTemplate.length + '}') document.querySelectorAll('div.entrylist-contents').forEach(div => { const masuda = div.querySelector('.entrylist-contents-title > a') const dateStr = masuda.href.substring(domain.length + dateTemplate.length, domain.length) if (!dateTest.test(dateStr)) { // キーワードとか console.log('not diary', dateStr) return } // new Dateできるように変換 // https://amateur-engineer.com/javascript-date-yyyymmddhhmm/ const year = parseInt(dateStr.substring(0, 4)) const month = parseInt(dateStr.substring(4, 6)) const day = parseInt(dateStr.substring(6, 8)) const hour = parseInt(dateStr.substring(8, 10)) const min = parseInt(dateStr.substring(10, 12)) const date = new Date(year, month - 1, day, hour, min) const bukumaDate = new Date(div.querySelector('.entrylist-contents-date').textContent) // 2023/01/23 00:00 const diffSec = (bukumaDate - date) / 1000 // ms to sec if (diffSec > threshold) { return } // ブクマ数 user const user = div.querySelector('span.entrylist-contents-users a').lastChild user.textContent += ' セルクマ ' + (diffSec / 60) // 古い記事がマイナスになる でも2015年ぐらいの記事までかな？新着はセーフ臭い /* if(diffSec < 0) { user.textContent += ' 異常差分:' + diffSec } */ }) })();
本人が何も問題は無いと明言しているので、ツイートを引用することにする。
問題は無いのだから、ツイートを消したりすることも決して無いだろう。
森奈津子に対してTwitterで粘着している人物なので、直ぐに発見てきるはずである。
「今日ね、こども虐待のことを学びたいと、中学生たちが会いに来てくれたの。みんな、すっっっごい熱心にノートをとってくれて、すっごい反応してくれながら真剣に聞いてくれました。
手土産まで持ってきてくれたの、すごくない？
男 子 が 全 員 イ ケ メ ン だ っ た。」
態々、全角スペース記法で、生徒たちがイケメンだったことを強調している。
「ちょっと15年後が楽しみな感じだったよー。
15年経ったらアタシ72歳だけどww」
「ジャニー喜多川みたいなことしないわよっ。
アタシが狙うのは、教師の方よっ。」
これに付けられたゲイ仲間のリプライは、次のようなものである。
「あら事務所つくりましょうよー！タリー歌川で。タリーズ事務所w」
ジャニー喜多川による若年男性に対する性的加害行為が、大きな社会問題としてクローズアップされているにも関わらず、それをゲイ同士で茶化している。
ここから生じるのは、一部のゲイコミュニティ内部では、若年男性に対する性的加害行為を軽く見ている、若しくは無視しているのではないかという、強い疑念である。
このような人物を有識者として講師に招く中学校や教育委員会にも、疑問を抱くと言わざるを得ない。
大学の講義で「生娘をシャブ漬けにする」と発言した外食産業幹部は講師を解任されたが、男子中学生をイケメン揃いと評してタリーズ事務所を設立云々している人物は、中学生を相手にする講師として相応しいのだろうか。
4. 条件式と分岐
https://www.python.jp/train/if_condition/index.html
以下、気になったところ。
コンピュータのプログラムは、どんなに複雑そうにみえるプログラムでも、細かく分解すれば次の3つの単純な構造の組み合わせで構成されています。
3. 条件が満たされている間、処理を繰り返す 反復処理
重要なことがサラッと書かれている。
これは一般的に「構造化プログラミング」と呼ばれている考え方のことだ。
構造化プログラミング（こうぞうかプログラミング、英: structured programming）は、コンピュータプログラムの処理手順の明瞭化、平易化、判読性向上を目的にしたプログラミング手法である。
一般的には順接、分岐、反復の三種の制御構造（control structures）によって処理の流れを記述することと認識されている。
制御構造は制御構文、構造化文（structured statement）、制御フロー文（control flow statement）とも呼ばれる。
また、プログラムを任意に分割した部分プログラム（サブルーチンとコードブロック）の階層的な組み合わせによるプログラムの構造化も指している。
このプログラミング手法の普及に貢献したのは、1968年の計算機科学者エドガー・ダイクストラによるACM機関紙への投書「Go To Statement Considered Harmful」と言われている。
プログラムを構成する要素は、(1)データと(2)処理であり、構造化プログラミングは、このうちの(2)処理に関する話という位置付けになる。
手続型プログラミング（命令型プログラミングの一種）では、処理を
後で学ぶ関数型プログラミングでも、この３つと同じことができる動作が登場する。
参考までに手続型と関数型の基本動作について、対応関係を押さえておこう。
| 手続型 | 関数型 | 動作 |
| 順接 | 合成 | 処理をつなげていく |
| 分岐 | パターンマッチ | 処理を場合分けする |
| 反復 | 再帰 | 処理を繰り返す |
構造化プログラミングの仕組みは、文字でゴチャゴチャ説明されるよりも、目で図解を見た方が早いと思う。
Googleの画像検索で「構造化プログラミング」を検索して、分かりやすそうな図解を探してみよう。
https://monoist.itmedia.co.jp/mn/articles/1008/17/news092.html
↑ちなみに、図解で出てくる流れ図みたいなのは「フローチャート図」と呼ばれていて、プログラムの構造を紙に書くときよく使われる書式である。
値を比べる方法が紹介されている。
はてなアノニマスダイアリー（通称：増田）で記事を書く時、一部の文字はエスケープされて元々の文字を表示できない。
& → &
< → <
> → >
| 演算子 | 条件 |
| a < b | a は b より小さい |
| a <= b | a は b と等しいか小さい |
| a > b | a は b より大きい |
| a >= b | a は b と等しいか大きい |
| a == b | a と b は等しい |
| a != b | a と b は等しくない |
真か偽かを示すデータの種類として、ブール型という新しい型が紹介されていた。
ブーリアン型（ブーリアンがた、英: Boolean datatype）は、真理値の「真 = true」と「偽 = false」という2値をとるデータ型である。
ブーリアン、ブール型、論理型（logical datatype）などともいう。
2種類の値を持つ列挙型とも、2進で1ケタすなわち1ビットの整数型とも、見ることもできる。
また、各種ブール演算を行うことができ、論理積 (AND、&、*)、論理和 (OR、|、+)、排他的論理和 (XOR、NEQV、^)、同値 (EQV、=、==)、非同値 (NEQV、<>、!=)、否定 (NOT、~、!) などの操作が可能である。
ブール代数（ブールだいすう、英: boolean algebra）またはブール束（ブールそく、英: boolean lattice）とは、ジョージ・ブールが19世紀中頃に考案した代数系の一つである。
ブール代数の研究は束の理論が築かれるひとつの契機ともなった。
ブール論理の演算はブール代数の一例であり、現実の応用例としては、組み合わせ回路（論理回路）はブール代数の式で表現できる。
cf. 「Boolean」の翻訳を「論理型」とすべき3の理由 – Kenchant
https://senooken.jp/post/2016/03/21/2571/
プログラミング言語やHTMLのようなマークアップ言語などプログラミングに関する文書を呼んでいるとboolean（ブーリアン）という単語に出くわす。
Booleanとは真（True）と偽（False）という2値をとるデータ型のことである。
情報元によって、このBooleanの翻訳や呼び方が異なっている。以下のように呼ばれたり訳され、最後に「型」や「値」がついたりつかなかったりする。
このBooleanの呼び方としてどの訳し方がよいか気になったので調べた。
その理由は以下3点だ。
文字列同士の比較では、人間の感覚とはことなった比較結果となる場合があるので注意してください。
一般的には、半角の数字やアルファベットの比較は、次のような結果になり、安心して利用できます。
1. 数字は、文字の0が最小、9が最大(0 < 1 < 2 < ... < 9)
2. アルファベットでは、a が最小、z が最大 (a < b < c < ... < z)
3. 大文字は小文字より小さい (A < a, B < b, ...)
文字列の大小の比較に、ユニコードという文字一覧表を使っており、その文字コードの大小で比較しているという種明かしをしないと意味が分からないと思う。
種明かしをしていない、という意味で、この説明もあまり良くないと思った。
cf. python 文字列の比較 | Hello, Pygineer
文字列 (str のインスタンス) の比較は、文字の Unicode のコードポイントの数としての値 (組み込み関数 ord() の返り値) を使った辞書式順序で行われます。
抽象文字のレベルで (つまり、人間にとって直感的な方法で) 文字列を比較するには unicodedata.normalize() を使ってください。
文字列の比較は、一致か不一致かを調べる場合が多いと思うので、大小の比較はあまり気にしなくても良いような気がする。
if 条件式:
処理1
処理2
...
Pythonの書き方を特徴付けている１つが、この「インデント記法」
if 文の書き方
条件式の後ろに、: 記号が必要ですので、忘れないように気をつけてください。
if 条件式: の次の行から、条件式が True となった場合に実行する処理を記述します。
インデント
条件が満たされたときに実行する処理は、行の先頭に スペース文字 を 4文字 入力してから記述します。
if a == 100:
処理1
処理2
処理3
^^^^
関数型プログラミング言語「Haskell」でも、Pythonのインデントと似た「レイアウトルール」「オフサイドルール」という記法が用意されている。
https://www.tohoho-web.com/ex/haskell.html#layout
Python の様にインデントを用いることで、{ ... } ブロックの { と } を省略することができます。
main = do
話を戻すと、Pythonではインデント（字下げ）が文法的に意味を持っており、省略できないということ。
Pythonでは、１つのブロック（コードの塊）をインデントの位置で束ねている。
他のプログラミング言語では、ブロックの開始と終了を表す記号（「{」と「}」など）がよく使われたりするけど、Pythonはその代わりにインデントを使う。
外見は見やすくなるけど、逆に言えばインデントを間違えたら、コードの意味が変わってくるので、長所と短所を両方併せ持った記法とも考えられる。
元々、Pythonは教育用途の言語としたスタートした歴史があるので、可読性を重視しており、誰が書いてもある程度同じようなコードになることが求められている。
その要求に対する答えの１つが、インデント記法ということだったのだろう。
関数型プログラミングの考え方を参考にする場合、if文を使った関数はelse節を省略しないで、Trueの場合でもFalseの場合でも、必ず戻り値を返すように設計しておいた方が良いと思う。
ifも文ではなく式として見るならば、評価した結果を必ず返すようにしておく必要がある。
（副作用の有無に関わらず）TrueでもFalseでも、必ず値を返すようにしておけば、戻り値なし（void）を避けられる。
これは後々、例外処理の書き方などで効いてくるので、Pythonでもif文でelse節を省略しないで書けないか？考える習慣を身につけておきたい。
特になし。
特になし。
https://b.hatena.ne.jp/entry/s/togetter.com/li/2175640
のブックマークコメントで、自分の好きな冷凍食品に言及しているコメントをピックアップして、メーカー別にまとめました。
内容には万全を期していますが、間違いはご容赦頂ければ幸いです。
味のレビューとかあるといいなと思って、Youtubeの検索もつけていますが、
メーカーのCMへのリンクが先に来るのであまり面白い結果にはなってないかも。
某動画サイトで、トップバリュの食品を食べまくるずんだもんみたいなのが見つかることを期待していましたが、
今「AI絵師は絵師を名乗るな」みたいな議論が多いですが、私も「絵師」は名乗らないで欲しいなと思ってます。
.
なお、増田記法が使えない情弱なので文章の見栄えは許してほしい。
.
最近だとpicrewさん(https://picrew.me/ja)が多いと思います。
世の中にはpicrewの作品をファンアートと呼ぶ方々がいます。
違和感を覚えませんか？パーツ組み合わせただけでファンアートらしいです。やってることはAI絵と変わらないですよね。
ただ、これをファンアートと呼ぶ層は日常的には絵を描かず、機会があって絵を生成したことで「ファン(が作った)アート」と呼ぶらしいです。
また、その人もpicrewやアイコンメーカー等で作ったことを隠さず併記させています。
.
「出来合いのパーツから着想を得て組み合わせている」ことから、ハンドメイド界隈ごと叩く人がいるそうです。
「ハンドメイド」のサジェストに「作家気取り」「何様」と出るので、「AI絵師」という呼称への反発に近いものを感じます。
同じ「パーツ(AIならプロンプトの言葉や画風指定)を組み合わせてる」創作ですが、個人的にAI絵師との違いを感じるのは「材料を有料で仕入れていること」です。
そして、AI絵の絵柄は作者が望んで売ってるものではないので、同じ行為でも背景は違います。
(絵柄を望んで売る人が現れたらいいんでしょうけどね)
.
結論、プロンプターとか作家は名乗っていいかもしれないなーと思いました。
組み合わせて作ってみたよ！見てみて〜！はいいと思いますが、それをいちから描いた絵師さんと同列に見てもらえるとは思うなよ！！
.
.
NotionかVScodeかどっちかなあ
ahomakotomさんもまあブクマカによくいるタイプの人（婉曲的な表現）なので、わざわざ増田まで書かんでも、と思いながら見てたけど、これは面白いから言及しちゃお！
増田ってこういうなんだか頭良さげな形式でものを言おうとするけどうまくいってない人がいっぱいいるから大好き！
もうほんとめちゃめちゃでどこから手をつけていいかわからないけど、頑張って君が間違っているところを指摘していくね！
これに準拠してるって言いたいんだろうけど、それならそのことは最初に言わなきゃダメだよ！意味不明だよ！
そしてどこからこの内容が読み取れるか書いてないんだよね。結果的にこの前提が間違ってるからもう全部腰砕けなんだけど。
元増田が批判してる根拠は、あっ、前提っていったほうがいい？ごめんね。良く知らなくてそういうの。学がないからさあ俺。
たった100円を払わず
ここだよね。数字がコピペできねえぞ。リスト記法ってどうやんだっけか。まあいいや。
ではなさそうだよねえ。
君の好きそうな感じで書くならば
こんな感じ？4の条件を満たしているかは意見が分かれるところだろうね。
でもまあ人を批判しようってんなら普通以上の注意力を持って文章を読むべきですよね。「寛容の原則」でしたっけ？うふふ。
ここまでの内容で「前提3-1」はバッテンだね。だから3-1に対する疑問もバッテンだね。大本の前提が間違ってるからこれ以上バッテンつけてもしょうがないんだけど。
「前提3-4-1」もほとんどバッテンだね。元増田は「どんでん返しの伏線」って言ってるように「誰であっても明らか」とまでは考えてなさそうだね。
だから疑問のほうもほとんどバッテンなんだけど、一応言っておくとコメントは皮肉を読み取れなかったのは前提だね。そう！前提！元増田もahomakotomさんが皮肉を読み取れたのにあえてあんなブコメを書いたとは思ってないだろうね。これは誰であっても明らかに読み取れることだよ。
皮肉に気づかず記事を批判するのはダセエし、他のコメントから皮肉に気づいても訂正しないから悪質性が高まってる、って論旨だね。
色々と書いてしまったけど、君の問題点は元文章を真摯に読んで批判しているわけではなくて、批判が先にあって、自分が批判しやすくなるような前提があるものだと決めつけてしまっていることだと思うよ。どこかで見た構造だね。
こめん、真摯に読んでないっていうのは寛容の原則から言ってよくないね！単に愚かだね。「オッカムの剃刀」とか、そういうの好きだよね！きっと！
まとめます！
・十分な議論を行う場合、論者は相手の議論に対して十分な寛容性を持つべきである。
だそうな
| pre記法 | ＞ | ～～ | ＜ | 整形したテキストをそのまま表示します（pre） |
