よんてんごP @yontengoP ベーチェット病と痔瘻という難病に侵されたナプキンを付けた社畜です。優しく 接してあげて下さい。尻穴方面/IT方面/社畜方面/下ネタ方面のツイートが多い ですが、病気なので許してあげて下さい(傲慢) ▼昨今、週刊ダイヤモンド📖/ABEMA📺/美ST📖とかに出てます ✉お仕事ください よんてんごP @yontengoP 朝からまたシンドイ話するんですけど、何かしらミスがあった時に 👤「何故こうなった、理由は？」 👨‍🦱「はい、●●が~~で…」 👤「違う、理由は？」 👨‍🦱「え？ですから●●が…」 というのを何度か繰り返した結果 👤「違げぇだろ理由はまず 『ごめんなさい』だろ‼️✊」 って言い出す一幕があって 2023-11-30 09:19:11 よんてんごP @yontengoP いや理由聞かれて言い訳するなとか、全て自分の所為にしろ、

文章の中でかっこを多用する人っているよね（いるよね？）。 特に、がきかっこや丸かっこや二重かぎかっこ。 自分もかっこを多用してしまうんだけど、かっこを多用する人って発達障害のケがあるんだってね（今は引用元がわからないが）。 こうやって油断するとすぐにかっこを使って補足してしまう。 こんなものでは補足にならないと分かっているのに（本当にわかっているのだろうか）、『補足』できていると思い込みたいのかもしれない。どうだろう。 あなたはかっこを多用する人？ 自分に何か『問題』があると思うときってある？ （流石に意図的にかっこを使っていることは伝わっているかもしれないけれど）意図しなくてもこれくらいかっこを使ってしまうときがある（読みにくい）。 どうしたらいいんだろうね（わからない）。

インターネット、特にソーシャルメディアは人々の対立を激化させ、SNS上でやりとりされる投稿には憎しみや怒りがまん延しています。その原因は、フィルタリングにより見たいものしか見えなくなる「フィルターバブル」であるという考えが主流ですが、それよりもっと本質的な原因について、科学系YouTubeチャンネル・Kurzgesagtが解説しました。 The Internet is Worse Than Ever – Now What? - YouTube SNSなどのアルゴリズムは、ユーザーが見たい物を正確にリコメンドし、自分の意見に同意する情報だけを表示します。 その一方で、反対意見や情報は除去されます。 これが「フィルターバブル」です。 ところが、インターネットユーザーが見ているものや検索エンジンで表示されるものを調べた研究では、人々がイデオロギー的に孤立しているという証拠はほとんど見つかりません

頂き女子りりちゃんと話したことがある。 あまり詳しくは書けないけど、私はホストとか夜職とか全然関わりがなく、そういう界隈(？)にいるわけでもない普通のアラサー女であって、りりちゃんやその界隈を擁護したいわけではない。 ましてやりりちゃんがやったことを擁護したいわけではない。 のだけど、なんというか、りりちゃんは魅力的な子で、いわゆる「おぢ」が貢いでしまうのもわかるなと思った。人が「沼る」のがよくわかった。 ・自然体でリラックスした雰囲気 異常にテンションが高くてキャピキャピしている、もしくはだるそうに喋る、みたいなイメージをりりちゃんに抱く人も多そうだけど りりちゃんはとても癒し系かつ自然体だった。 肝が据わっているからなのかよくわからないけど、とにかくリラックスした雰囲気で、こちらまでほっとした。「ここにいていい」気持ちになったし、誰にも話さないようなことを話してもいいような気がした。

国内でも、Horizontal SaaSについで、Vertical SaaSと徐々にプレイヤーが揃い、PMFを獲得しつつあります。その過程で、いつ、どんなプロダクトを2つ目、3つ目のプロダクトとして展開していくべきか、という議論をよく耳にするようになってきました。 これは、言語や商慣習の障壁が高い国内において、市場が限定的であることから、USを中心としたグローバル・マーケットを対象としたSaaS企業よりもかなり早いタイミングで検討されているからです。特に、Vertical SaaSの場合、業界を限定するため、PMF前の段階から考え始められている印象さえあります。 そこで本記事では、ターゲットとする業界、業種やユーザーのペルソナによって、どのようなマルチプロダクト戦略を取るべきなのかについて、整理を進めていきたいと思います。 マルチプロダクト戦略とは SaaSにおけるマルチプロダクト戦略は1

ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023　の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

要点は「既存IDと勝手に統合する危険性」なのかな。だとしたらタイトルがよくない。／先に嘘のEmailでユーザーを作ってスクワッティングかけられていたらやばいだろう。（Emailの嘘の登録ができると問題になる。）

こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ

Development Division/Platform Team/Sys-Infra Unitの伊豆です。Sys-Infra Unitはインフラエンジニア・SRE 的な役割を担っています。 今回は、ある日突然SSHログインが遅くなったときに調査した内容を共有します。 SSHログインに数分かかる ある日、AWS EC2上で動いている開発環境のSSHゲートウェイにSSHログインすると30秒以上かかると報告がありました。-vvvオプションを指定してSSHログインしてみるとpledge: filesystemというログが出力された後、数十秒から数分程度かかってSSHログインが成功する状況でした。 pledge: filesystemやssh slowなどで検索してみると、主に以下のような対処法が挙げられていましたがどれを試しても状況は改善されませんでした。 systemd-logindを再起動