はてなキーワード: メソッドとは
静的型付け言語の話で
Interfaceだけ書かれてもわかるのはプロパティやらメソッドやらが存在するということだけ
なにかの修正をしないといけないとき、結局コード見るだけで解決できず、デバッグ実行してその時の実体が何かを見て調査することになる
それって動的片付け言語と一緒では?
わざわざ面倒な型を書いてるのに結局動的型付け言語と同じような方法で動作を理解したりしてるなら面倒なだけなんだよな
とりあえずInterfaceにせず基本は直接クラス書いて、可変にする必要ができたら初めてInterface化するくらいでいい
Interfaceの参照箇所を列挙すればありえるクラスは全部わかるはず
しかしTSみたいな言語は明示的にInterfaceを実装してなくてもそのプロパティやメソッドがあればなんでもいいよになってる
なんで二重の手間をかけなければいけないのか
https://www3.nhk.or.jp/news/html/20240820/k10014553531000.html
注意しといた方がいいかもね。
アメリカは官僚も終身雇用ではなく、共和党と民主党の政権交代に伴って官僚も全部入れ替わる。つまり民間から大量に雇い入れるんだけど、この慣習のせいで
「民間に戻ったとき自分のビジネスに有利になるよう法規制を弄くり回そう」というメソッドが普通にまかり通っていて、ちょいちょいメディアでも批判されている。
まあ、プレイヤーが数年間ルールメイカーに入れるってなったらそりゃあやるよね。
これは日本人ならお馴染みのザ•パソナ竹中スキームで、というか向こうの方が歴史は古いから竹中氏が真似したという話かもしれんが、
とにかく次の選挙でトランプが勝っちゃうとバイデンチームの官僚メンバーがドバッとビジネスの世界に戻って、これまでの4年間で蒔いた種の刈り取りを始めるというワケですよ。
投資界隈の人も手ぐすね引いて待ち構えてるんでしょうね。
折角ならどれが良さそうか増田に書いてって下さいよ。みんなでぼろ儲けしようよ。
「ダイエット術」が魔術的ないかがわしいものばかりになるのは、人が直接的に「いつ脂肪が燃えているのか」を見ることができないからだ。
もしそれが「脂肪残量モニター」のようなもので直接わかるようになれば、食べ過ぎる前に「もうよしとこう」、食べ過ぎたら「ちょっと運動で減らすか」なんてゲームのような対応が誰でもできるようになる。
残念ながらそこまでのことはできないが、脂肪燃焼のメカニズムを理解すれば、実は「今日はちゃんと脂肪が燃やせた」くらいのことを確認することはできる。
考え方は非常に簡単。
「脂肪は燃焼されてエネルギーを使ったあと、尿(水分)になって排出される」
これだけの原理を知ればすべてわかるのだ。
「ガス火は水蒸気が出るから、焼き鳥がうまく焼けない」なんて話がある。
燃料になる有機化合物は、酸素と結合してエネルギーを放出するときに、大部分がH2OとC02になる。
大雑把に原理を言えば、これらの有機化合物の主となる部分は -CH2- の炭素鎖である。
ここに 1.5 O2 が反応して、CO2とH2Oが大量にできると思えば良い。
脱水した炭素Cの塊である「炭」はこういう燃え方をしないので、水蒸気が発生せず、香ばしく焼けるということなのだ。
さて、この化学方程式自体は人体のいわゆる「脂肪の燃焼」でも同じである。(触媒によってゆっくり進むという違いがあるが…その辺は化学の教科書を読みなおして欲しい)
我々はつい「脂肪が燃焼」すると開放空間での石油燃料のようにその瞬間に消えてなくなってしまうと思いがちだが、人体内のような閉鎖系ではそうはいかない。呼気中の水蒸気や汗として発散されるのは微々たるもので、大部分は体液として残留する。
というわけで、この脂肪燃焼後の水分を解放するのは主に「放尿時」になる。
「脂肪が燃えた」ということは、実はこの尿の量を細かくモニタリングしていると観察できるのである。
増田はこれを、在宅ワーク中トイレ休憩のたびに前後の体重変化を量ることで発見した。
トイレとトイレの間にはだいたいコップ1杯(約200ml)の水分補給しかしないから、大抵の場合はトイレの前とあとで200gだけ体重が変化する。
そしてこの「体内に残留した水分」を解放したあとは、決まって身体が楽になり、なにかスッキリして、そろそろごはんでも食べようかという気になるのである。
はっきり言うが、増田がいちばん継続したダイエットのメソッドはこれだけであった。
運動したり糖質制限したり色々したが、そのたびに効果をこの「尿量計量法」で確認することだけは怠らなかった。
その結果、「朝、この残留水分排出が終わるまでは固形物を食べない」という形に落ち着くのが一番安定して痩せることができたが、それは結果論だ。
何より大事だったのは、このやり方で「今日は脂肪が燃焼した」を、絶対的な体重変化(食事量、いつ量るかなども影響)以外で着実に実感できたのが一番良かった。
増田はこれにより、間断的だがのべ1年ほどで30kg痩せた。
実測的にも、継続して痩せることができるのは1日100gから多くても200gほどである。
100gの脂肪が持つエネルギーは×9で900kCalなので、増田のようにデスクワークで基礎代謝の少ない人、特に女性ならこれくらいが目安だと思う。
コロナ禍も過ぎ(?)、在宅ワークが少なくなっているとは思うが、できる人はとにかく毎日やってみると意識が変わると思うよ。トイレ前後の計量。
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利なIDEが無かったので変数や関数の名前に長い名前を付けると実装が大変で
仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど
Copilotを使える時代にコメントを書く必要なんて皆無だし
仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメントは必要ない
コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLのリンクを貼ったり
「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど
それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル
そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い
「それでも無いよりはいいでしょ?」みたいに言う人いるが逆に問題になることも多い
コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり
ソースコードの修正に対してコメントが修正されていなくて後々で揉めたりする
当然ながらコメント部分にはLintが効かないので(ChatGPT使えば作れそうな気もするが)
チェック内容も増えるし良いことがほとんどない
ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い
まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな
書いたところで誰も読まないのにアホすぎる
FANZAの検索結果から熟女を除外するブックマークレット がうまく動いたので、気を良くしてはてなブックマークのコメント欄をスター数順にソートするブックマークレットを作りました。
作った動機は、「注目コメントに入りきれなかったちょっといいコメント」をサクサク探したいから。結果として建設的コメント順位付けモデルを無効化していますが、あのアルゴリズムには特に不満は特にありません。
javascript: (async () => {
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);
window.scrollTo(0, 0);
await wait(1000);
const p = document.querySelector('.js-bookmarks-recent');
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
l = l.filter(e => g(e) > 0);
l.sort((a, b) => g(b) - g(a));
p.replaceChildren(...l);
})();
ミニファイしたもの ※コードに一部誤りがありましたので訂正しました(2024-08-16 11:47)
javascript:(async()=>{const wait=ms=>new Promise(resolve=>setTimeout(resolve,ms));document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();window.scrollTo(0,document.body.scrollHeight);await wait(1000);window.scrollTo(0,0);await wait(1000);const p=document.querySelector('.js-bookmarks-recent');let l=Array.from(p.querySelectorAll('.entry-comment-contents'));const g=e=>{let n=e.querySelectorAll('.hatena-star-star').length;const c=e.querySelector('.hatena-star-inner-count');return c?n+Number(c.textContent):n};l=l.filter(e=>g(e)>0);l.sort((a,b)=>g(b)-g(a));p.replaceChildren(...l)})()
FANZAの検索結果から熟女を除外するブックマークレット 参照
javascript:
ブックマークレットに必要な、URLの種類を示すスキーム名です。
(async () => {
// 処理
})();
ページに元々ある変数たちとバッティングしないように、まず無名関数でラップします。処理の中で await を使いたいので async 宣言しています。
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);
「新着コメント」タブをクリックし、ページの一番下までスクロールダウンしてから少し待つ動作です。新着コメントの後半部分(スクロールきっかけの遅延読み込みになっているところ)の読み込みをうながしています。
window.scrollTo(0, 0);
await wait(1000);
ページの先頭に戻ってまた少し待ちます。合計2秒の待ち時間は雰囲気で決めていますので、これでなければならない・これで過不足ないという値ではありません。単にコメントの読み込み完了を判定する処理を書くのがめんどうだっただけです。
const p = document.querySelector('.js-bookmarks-recent');
新着ブコメの親要素です。繰り返し呼び出すので名前をつけています。
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
コメントのはてなスター数をカウントして返す関数です。たくさんスターがついてる ★256★ みたいなやつの数字も足します。
l = l.filter(e => g(e) > 0);
ソートする前に、無スターのコメントを消去しています。してもしなくてもいいことですが。
l.sort((a, b) => g(b) - g(a));
残ったコメントをスター数で降順ソートします。.querySelectorAll() で収集した要素を配列に入れ直したのは、この .sort() メソッドを使いたいからです(.querySelectorAll() が返す配列風の NodeList オブジェクトは、配列と共通のメソッドもいくつかあるものの、大半は使えないのです)。
p.replaceChildren(...l);
親要素の内容を、並び替えの終わったコメントでそっくり入れ替えて、処理完了です。画面を見ると新着コメントの中身が「スターのついたコメントのみ・スターの多い順」に並んでいます。元に戻す方法はないので、原状回復にはリロードします。ソート状態を示すフラグを立てておいてスター数ソート⇔日付ソートをかわりばんこに行うようにすればできそうだなと思ったけど実装はしません。連打スターを省く処理を追加してUU数でソートできればもっと厳正なランキングになるなーと今思いつきましたがそれも実装はしません。
おれがそうだし・・・
性欲は尽きることなく
毛は生えまくり
「お前の生きがいは?」と聞かれたらミリで「オナニーです」と臆面もなく答えられる
「あなたにとって快眠法は?」と問われれば「オナニーすることです」と自信を持って答える
好むと好まざるとにかかわらずそういう人生を歩んでしまっている
肉体的な快楽を欲するならば専門の店にいけばよろしい
しっぽりぐっちょりサービスしてもらえるし満足感も得られる
だけど頭の中で完結する物語は金も掛からないし労力もかからない
ただ無心になって己の理想とする女をイメージし、それに己の欲望をぶつけるまでだ
だれも犠牲にならない
そんなメソッドがあることは畢竟おれの身体じゅうに毛が生えているからだと思う
毛がなければこんなことにはならなかったはずだ
遅ればせながらミッドサマー見ました、ディレクターカット版。まぁ夏休みだからね。せっかく見たわけだから、感想をどこかに違法投棄したかった。
だった。
とにかく「共感」という感情の働きをグロテスクに、狂気的に描写している。下馬評を聞いて、カルト村にやってきたよそ者が現地のネーチャンとパコパコした後に、愉快な仲間と共にグロ処刑されるよ!って話だと思っていたので、なんか予想と違う角度からの露悪的な表現に、自室の椅子から転げ落ちてしまった。劇場で見なくてよかった。ありがとうamazon prime。
本作の主人公であるところのダニー、これがまた悲劇的人物で、双極性障害の妹がダニー以外の家族を巻き込んで無理心中してしまうという、壮絶な背景を抱えている(ルックバックであれこれ言われた我が国ではできそうもない設定だ)。さらに言えば、彼女自身もパニック障害持ちと、かなり苦難の人生を歩んでいる。
そんな彼女にも、理解のある彼くんこと、クリスチャンがいます……と思いきや、このクリスチャンは理解ある彼くんになるにしては力不足。作中冒頭でもダニーの電話に辟易としている様子が描写されている。ダニーが不安になるたびに電話がかかってくるので嫌になったんでしょうね。
また、クリスチャン自身もダニーの誕生日を忘れてしまっていたり、自分の旅行の計画を彼女に伝えてなかったりと、純粋に彼力が足りてない部分も描写されている。
そんな彼の落ち度をダニーが非難して謝らせ、ダニーはそこからさらに追撃(本当に心から謝ってる?攻撃)をかまし、そしてクリスチャンに非難され返して慌ててダニーが謝るという場面がある。
そんな彼女の前に現れるのがペレ。この物語はペレに誘われてホルガ村に来たクリスチャンとダニーとその仲間たちが、ダニーを除いて村の生贄にされる話であるから、彼は物語的には黒幕、あるいは元凶である。
そんなペレは、作中でダニーに対し「自分も同じ境遇(家族を失った)だから」と彼女の悲しみに寄り添おうとする。
……と思いきや、不思議なことに彼は作中一度もチンポを出さない[^2]と、いまいち意図がわからないキャラクターとなっている。なんなら誕生日を忘れたクリスチャンをフォローしたのもペレだ。NTR男だとしたら敵に塩もいいところだ。
そんな彼の動機も、作中中盤に明かされる。自身が家族を失った悲しみをコミューン(ホルガ村)に支えてもらったと。だから同じようにダニーもホルガ村で支え合えると。
つまり宗教である。男が女に寄るとき、その理由はセックスか宗教か金の3択だ。こいつも例外ではなかった……というのはさておき、動機だけ見ると善性寄りに思える。
作中でダニーたちが訪れるホルガ村。ホラー作品の類型に漏れず、この村は姥捨てからスピリチュアル儀式、人身御供までを幅広くこなす、分かりやすいキリスト文化圏外のエログロホラーカルト村だった。
ここまでは典型的な因習村といったところだが、ホルガ村にはホラー作品としては珍しい要素がある。
どういうことかというと
など。ホラー因習村としてはユニークな表現だ。そして、これこそがペレの言っていた「家族を失った悲しみをコミューンで支えてもらった」の真相である。この村は、とにかく村民同士で共感し合って、悲しみを乗り越えるようだ。
そして、紆余曲折あったダニーはホルガ村に迎え入れられ、紆余曲折あって知らん女とスピリチュアルセックス儀式をしていたクリスチャンを生贄に捧げることを決意したのであった。燃えるクリスチャンを遠目に眺めながらダニーはニッコリスマイルを浮かべて映画は幕を閉じる。
ここから先は物語の中では描かれず、それぞれの解釈に委ねられている。故に、自分も己の解釈を述べることにする。
ホルガ村で行われている、この共感メソッド。その目的は、個人が抱えるには重すぎる苦痛をコミューン全員が共有・分配することで苦痛を乗り越えることにある。また、協力して苦難を乗り越えることからコミューン内の結束力を高める効果もあるだろうし、感情の共有を徹底すれば「村民同士で共感しない感情については村として承認しない」という仕組みを作ることができる。これぞまさに共産主義的な支配に他ならない。
現に、姥捨の場面では「こんなことおかしい」と叫ぶ余所者の感情には一切共感せず、しかし村に迎え入れられたダニーの嗚咽には共感してみせた。このように、村をあげた共感の儀式は、その他の共感しない感情を排除する効果がある。カルト式の集団運営に一役買っているのだ。
双極性障害の妹から連絡が絶えた不安に共感して欲しい、この不気味な村から早く抜け出したい、そういった感情への共感を、ダニーはクリスチャンに求めてきた。しかしクリスチャンはそれを受け止め切ることができず、ダニーはそれに不満を感じていた。
そして、共感に対する内なる欲求をペレに見透かされたからこそ、ペレはダニーがホルガ村に来ると知ったすぐ側から、ダニーに寄り添い始めたのだ。村人が「ペレの見る目は確か」と言ったのは、そういうところを指しての言葉だろう。
しかしながら、ずっと笑顔の戻らなかったダニーが、スピリチュアルメイポールを通じて村の女性と心を通わせ、恋人を失う悲しみを共有することでやっと笑顔を取り戻すという展開からは、ホルガ村を迎え入れたことそのものが幸か不幸かは判断がし辛くはある。
人は誰しも自分の感情に共感してもらいたいものだ。しかしながら、共感を他人に問答無用で押し付け、そして押し付けられることを選んだコミューンの行き着く先がエログロカルト村というのも、寓意を感じずにはいられない描写だ。
なにより、ダニーのような、恋人に感情労働を押し付ける女がそのようなコミューンに適合するという描写が、そのような人間の行き着く先は地獄であると暗に示しているようでならない。
現代ではエコーチェンバー効果という言葉を聞くことも珍しくなくなってきた。思想の似通った者同士が通じ合い、かくして狂気は産まれるのだというストーリーは、思い返せば現実でもよく見る構図であった。
もし、この映画から得られる教訓があるとくれば、それは「共感のしすぎ、求めすぎ」は狂気を招くということではないだろうか。
是非とも身に覚えのあるメンヘラ女の諸氏におかれては、このことを胸の片隅にでも置きながら、周囲への配慮を怠らずにいてくれれば幸いである[^3]。
---
[^1]: このように書くと、パニック障害なのだから仕方ないじゃないか、差別だなどと書かれるかもしれないが、そもそも恋人は無料セラピストではないのだ。クリスチャン自身もダニーを支えきれないことを自覚し、別れ話を持ちかけようともしているのに、単純にクリスチャンをクズ男扱いして死んで当然扱いする感想記事があり、あまりにもあまりにもであったので、ささやかな抵抗として、このように駄文をゴミ捨て場に投げ捨てている。
[^2]: ちなみにクリスチャンはチンポを見せている。
[^3]: 決して私怨ではない。
たとえば ↓
https://www.launchexcel.com/what-jobs-use-excel/
https://www.fdmgroup.com/news-insights/advanced-excel-skills
ジャップランドで起こりがちなことはアメリカでは無いのかAIちゃんに尋ねてみたらこう言ってたよ
ワイ: 質問: 2024年において、アメリカの大企業および中小企業の間で、より一般的なデータ管理の方法はなんですか? 検索して最新のトレンドを教えてください。 - 方法A:内部データベースからCSVファイルとしてデータをダウンロードし、Excelで修正してから、
ETLツール(例:Informatica PowerCenter、Talend Open Studio)、BIツール(例:Tableau Prep、Microsoft Power Query)、
または他のデータベース(例:OracleDB)などの他のシステムにインポートする。 - 方法B:Excelのステップをスキップし、内部データベースを他のシステムに直接接続する。 - 方法C:レガシーシステムや複雑なシステムには方法Aを使用し、その他のシステムには方法Bを使用する。状況やシステム要件に応じて使い分ける。 質問のポイント: - 大企業におけるExcelの使用:大企業はデータクリーニングのためにExcelを使用するのを完全にやめましたか?それとも、古いメインフレームシステム、ERPシステム、または特定の業務プロセスの問題のためにまだ使用されていますか? - 方法A、B、Cのシナリオ:各方法の具体的なシナリオと製品名を教えてください。 - 2024年におけるCSVファイルのダウンロード:2024年現在、ETL/BIツールやクラウドベースのDWHを利用できないどころか、Oracle Gatewayなどの接続手段も利用できないデータベースの使用は完全になくなりましたか?
もしそのようなデータベースが2024年にもまだ存在する場合、直接的なデータ連携が困難なため、CSVファイルでのデータ抽出が唯一の方法となることがあります。
企業は膨大なコストがかかるために移行を延期していますか?それともすでに段階的に対応していますか? - Excelを使い続ける理由: 内部データベースを他のシステムに直接接続した方がシンプルなのに、なぜ一部の企業はデータクリーニングのためにExcelを使い続けているのですか?
↓
2024年には、大企業の間でメソッドB(直接接続)へのシフトが顕著になっています。しかし、特定のシナリオに応じてメソッドC(ハイブリッドアプローチ)も採用されています。中小企業においても、直接接続の利便性と効率性が認識され、その採用が徐々に増加しています。しかし、リソースとコストの制約により、Excelを使用したデータクリーニングやハイブリッドアプローチが依然として一般的です。
使用状況: この方法は、中小企業、レガシーシステム、複雑なデータ構造を含むシナリオで依然として一般的です。Excelはその柔軟性と使いやすさから、データ操作のための多用途ツールとして広く使用されています。
シナリオ:
製品:
具体的なシナリオ:
使用状況: この方法は、大企業や技術に精通した中小企業の間でますます一般的になっています。直接接続を利用することで、データワークフローが効率化され、手動エラーが減少します。
シナリオ:
製品:
具体的なシナリオ:
使用状況: 多くの企業が、レガシーシステムや複雑なシステムにはメソッドAを、その他のシステムにはメソッドBを使用するハイブリッドアプローチを採用しています。この柔軟性により、既存の制約と近代化の努力をバランスさせることができます。
シナリオ:
製品:
具体的なシナリオ:
データ管理ツールの進歩にもかかわらず、Excelは大企業におけるデータクリーニングと操作のために広く使用されています。これは主に以下の理由によります:
ETL/BIツールやクラウドベースのDWHと直接統合できないシステムに対して、データをCSVファイルとしてダウンロードすることは依然として一般的です。企業は高コストと複雑さのために移行を遅らせることが多く、段階的に対処しています。
しかし、直接接続はより効率的で広く採用されており、長期的にはデータ管理におけるExcelへの依存が減少すると予想されます。
クラウドベースのデータ統合ソリューションの台頭により、データ収集、クリーニング、統合がAI/ML技術によって自動化され、手動作業が減少し、データの一貫性と精度が向上しています。AI/MLアルゴリズムは、異常検出、欠損値の補完、パターン認識などのタスクを効率的に処理し、データ品質を向上させます。リアルタイムデータ分析の利点が明らかになるにつれ、直接接続の採用が増加し、より迅速かつ正確なビジネス意思決定が可能になります。
データセキュリティ、コンプライアンス、およびデータガバナンスの重要性が増すにつれ、このトレンドは続くと予想されます。
そうやって話をそらそうとするメソッド発動