自分はセックスワーク擁護派だけど、「セックスワーク差別は無知からやってくる」（https://anond.hatelabo.jp/20210714185723）を書いた元増田のロジックはだいぶマズいというか突っ込まれどころが多いので、もう少し理論武装してください。通常の賃労働とは違うセックスワーク固有の困難というのは確かにあって、セックスワーク当事者たちも、そのことはきちんと問題化しているので。 安全確保そもそもセックスワークというのはワーカーの安全確保がとても難しい。行為の性質的に、どうしても個別性・私秘性が求められ、たいていは誰からも見られない場所、多くの場合は密室で、1対1で行うということになる。特に非店舗型風俗では完全にアウェイな相手の自室に1人で入っていくことになるので非常にリスクが高い。男性相手の女性セックスワーカーの場合、フィジカルに圧倒的な差がある。事前のルールで決められた

この古い増田に関して解説を加えたいと思う。 ■肛門コンプレッサーまとめ https://anond.hatelabo.jp/20201105214157 なぜ肛門に圧搾空気を入れると人は死ぬのか？直腸が破れるからである。すると出血する。 しかし一番の問題はここからで、便が腹腔内に散らばるのである。こうなると便に含まれる様々な細菌が複合的な感染症を惹き起こし腹膜炎を発症する。 これをうんぺりという医者もいるらしい。腹膜炎はペリトナイティス、うんこによるペリトナイティスだからうんぺり。お医者さん…。 速攻で洗浄しないといけないから開腹手術が必要だ。腹膜はどんどん吸収して血管に流してしまうのであっという間に全身症状になり死んでしまう。 だからエアコンプレッサ浣腸なんてアフォな事をやった場合、死亡率は4割ぐらいになる。手術が成功してこの数字。 ウエットスーツ非着用での橋からのダイブでは高圧洗浄機カ

世界に10万店のコワーキングスペースで「働く場所」のアップデートを！ 10億円の前澤ファンドを一次通過しました はじめまして、株式会社いいオフィスの代表、龍崎コウです。 この度、ZOZO創業者である前澤さんが主催する前澤ファンドの一次審査を通過したのでご報告です。ありがとうございます。 私が行っているビジネスモデルに対して、各項目で前澤さんが直接評価をしていただけた事は非常に勉強になりました。 提案者のビジョンや想い、という項目で9点という高得点をつけていただけました。正直、このビジネスは世界の働き方をアップデートする取り組みだと思っています。誰よりも熱い想いで、この2年間取り組んできた事業なので、その熱意が伝わったのは非常に嬉しかったです。 今回、私の取り組む事業ついて、しっかりとご説明させていただきます。 自己紹介私はSNSなどをほとんどやらないので、まずはこれをきっかけに自己紹介をさ

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

Jamstackを既存のシステムに導入するかを検討する機会があった。 紆余曲折したものの、未だに暫定的な結論しか出ていない。 とはいえ、わりと頑張った。 今回は Jamstackとはなんぞや？ Jamstackの特徴 Jamstackの技術 弱みを解決する策 実際に検討した話 を雑に紹介したい。 個人的なメモなので、間違っているところがあるのを考慮願いたい。 Jamstackとは？ JamstackのJamは以下の頭文字をとっている。 JavaScript APIs Markup まず、フロントエンドを持たないAPI群がある。APIはブラウザのJavaScriptから叩かれるかもしれないし、後述するようなSSG =「Static Site Generator」のフレームワークが叩くかも知れない。どちらにせよユーザーに配信されるのはSSGが出力した、Markup。つまりプリレンダリングされた

曜「ねぇ、善子ちゃんって10個以上ノートアプリ持ってるって言ってたじゃん？」 善子「そうね。検索に強いGoodnotesに録音に強いNotability、万能なNoteshelf…そして手書きに強いNoteAlwaysとかね」 曜「手書きに強いって？」 善子「ふふっ、そういう訳で今日はNoteAlwaysを紹介するわ！」 曜「おー、なんだか久しぶりな気がする」 ジェスチャー善子「今回は初っ端から目玉機能からいくわよ！」 曜「なになに？」 善子「ズバリ！ジェスチャーが強力なの！」 曜「え？丸でかこんで…文字が消えた？」 善子「そう！丸で囲むとジェスチャーが発動するの。今やったみたいに丸でかこんでぶんぶんすると消したりね」 曜「ほぇー、面白い機能だね」 善子「もちろん丸で囲んで出来ることはこれだけじゃないわ。」 善子「こうやって色や大きさ、位置も変えられるのよ」 曜「ただ丸で囲むだけでここまで

人に説明するときに記事あると便利なので、開発環境向けのDockerfileとdocker-compose.ymlを書いておく。 Dockerfile FROM ruby:3.0.0 WORKDIR /app # Using Node.js v14.x(LTS) RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # Add packages RUN apt-get update && apt-get install -y \ git \ nodejs \ vim # Add yarnpkg for assets:precompile RUN npm install -g yarn # Add Chrome RUN curl -sO https://dl.google.com/linux/direct/google-ch

自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

Agile Business RulesDecision tables are at the core of our automated decision making. They are intuitive, easy to work with and versatile thanks to a variety of advanced functions. No-Code Business RulesMultiple rules like decision tables can be combined using rule flows. They allow you to build more complex decision making processes with clear visual representation.

「認証は OIDC 等のデファクトに乗っておけ」
というのはわかりました。ではその次。認証した後です。
残念ながらアクセス制御の枠組みにはデファクトがありません。
自分で設計するしかないのです。 しかし、我々は漠然と車輪の再発明を続ければいいのでしょうか。アクセス制御にスタンダードが無いなら無いなりに、
どのようにアクセス制御機構を整備すればいいのか？その考え方を整理していきましょう。Read less

マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その

今、僕が使っている歯ブラシと歯磨き粉は何も考えずに選んだものだ。 電動歯ブラシは友人が使っているのを見て、「ブラシが動くのがカッコいい」という理由だけで買ったし、歯磨き粉はスーパーで値段がいちばん高いものを選んだだけだ。「見た目は大人、頭脳は子供」という逆コナンの買い物の仕方である。 年齢が上がってきて洋服や家電はそれなりに良いものを買うようになったのだから、そろそろ日用品も自分に合った良いものをそろえていきたい。 口内ケア用品も効果がわからずなんとなく使っている。自分に合っているのかは一切わからない……。 磨き残しが口臭に影響しないのかも気になる。よし！ 良い歯ブラシを買うぞ！ と思ったところで、冒頭の「歯ブラシの選び方がわからない」という問題にぶつかる。

オンライン価格設定で面白いと思った結果を紹介します． 「適正価格を二分探索するとそこそこ良い方法になるが， 二分探索に少し手を加えるとさらに良い方法になる」という話です． 出典は R. Kleinberg and T. Leighton (FOCS 2003) の Theorem 2.1 です． この記事自体は Haifeng Xu 先生の講義スライド の第 1 回をかなり参考にしてます． ゲーム理論と機械学習の様々な興味深いトピックが網羅されていておすすめです． 問題設定 戦略の評価尺度：リグレット 自明な $\mathrm{O}(N)$ リグレット戦略 二分探索による $\mathrm{O}(\log N)$ リグレット戦略 二分探索を改良した $\mathrm{O}(\log\log N)$ リグレット戦略 まとめ 問題設定 あなたは A さんに $N$ 個のリンゴ を，$1$ 日

Laravel大規模開発入門！MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について ナイル株式会社メディアテクノロジー事業本部の工藤さんにMVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について解説いただきました。 こんにちは、ナイル株式会社メディアテクノロジー事業本部で開発マネージャをしています工藤@ta99toです。 今回は大規模で複雑度の高い開発をMVCフレームワークベースで構築する際に僕が課題と捉えているポイントやその具体的な解決手法について解説させていただきたいと思います。 「MVC以上の責任分離イメージがつかないよ！」 「DDDとかクリーンとかオニオンとかあのへんの設計パターンの導入モチベーションが不明」 「どうやっても最終的には複雑になって追加開発や修正開発が怖い状態になっちゃう」 ↑このような悩みを持った方に対して

はじめにIT産業が集まる街といえば、シリコンバレーが有名だ。Airbnb、Uber、Facebook、Salesforceなど数々の会社がサンフランシスコ近辺にオフィスを持つと同時に、名門VCオフィスが並ぶ「Sand Hill Road」もある。サンフランシスコのどのカフェに行っても、起業家が自分のアイデアを誰かにピッチしている姿を見かけるのが普通だった。テック業界の起点がサンフランシスコであるからこそ多くの会社はサンフランシスコにオフィスを抱えている。 引用：Gfycatただ、それが変わってきている。実はここ数年でサンフランシスコとカリフォルニア州の状況が悪化している中、起業家やVCはカリフォルニア州から撤退。そしてコロナがその動きを加速したことで、今ではかなりの勢いでサンフランシスコから他の都市へテック業界が分散され始めている。何故このような動きになっているのか？多くの方はサンフランシ

もっと! : 愛と創造、支配と進歩をもたらすドーパミンの最新脳科学 作者:ダニエル・Z・リーバーマン,マイケル・E・ロング 発売日: 2020/10/02 メディア: 単行本 研究者らが発見したのは、ドーパミンの本質は快楽ではまったくないという事実だった。ドーパミンは、それよりもはるかに影響の大きい感情を生み出している。これから紹介するように、ドーパミンに対する理解こそが、さまざまな領域での人類の努力を説明し、さらには予測するための鍵を握っているのだ。 その領域は、目をみはるほどに広い。たとえば、芸術、文学、音楽の創造。成功の追求。新世界や自然の法則の発見。神をめぐる思考。そして、恋もそのひとつだ。 (p.14) このシンプルな概念は、大昔からある疑問ーー愛はなぜ色褪せるのかという疑問を化学的に説明している。私たちの脳は予想外のものを希求し、ひいては未来に、あらゆるエキサイティングな可能性

この記事は京都開発拠点アドベントカレンダー 18日目の記事です。 マネーフォワードには開発拠点が複数ありますが、技術情報はSlackで議論・共有されています。 今日はそんなSlackの中から、東京拠点と京都拠点を跨いで開催した「Railsへコントリビュートする勉強会」について、東京拠点のアルパカ隊長が紹介します。 はじまりのSlack ふとした時に、社内SlackのRubyチャンネルでこんな会話がありました。 @alpaca-tc 程よい難易度で、kamipoさんが「これ自分がやらんでもええやろ」みたいなissueがあれば このslackに投げてもらって 誰かシニアエンジニアがサポートしつつ、新卒がRailsコントリビュートするみたいなのやりたい:eyes: すると、kamipoさんからすぐ解決できるものは見た瞬間に直してしまっていると前置きがあった上で、 こんなissueを教えてもらいま