タグ

2018年5月2日のブックマーク (2件)

  • ネットハラスメントにはパスワード変更を奨めよう! - 山形浩生の「経済のトリセツ」

    ツイッターもフェイスブックも、あれもこれも、ネットコミュニティが同じ意見の連中が集まるエコーチェンバーと化し、その連中がお互いをブートストラップしあって勝手に舞い上がり、威勢良くなって、するとますます引っ込みがつかなくなって中にははた迷惑な実力行使にまで及ぶバカがたくさん沸いてくる、というのはもちろん周知のこと。 で、これを抑えるにはどうしたらいいのかってことで、みんなで注意しましょうとか、理性的に説得しましょうとかいうのは正論ながら無力なのももちろんご存じの通り。すると、「運営に言って取り締まらせろ」なんてことをみんな言うわけだが、これまたむずかしい。いきなりアカウント停止にすべきなの?ゼロトレランスとか言ってそういうのをやるところもあるけど、結局何を許すか赦さないかは、かなり恣意的にならざるを得ない。やられたほうは、なんで自分だけが、と不満に思い、またどっちサイドでもかなりの人は「あれ

    ネットハラスメントにはパスワード変更を奨めよう! - 山形浩生の「経済のトリセツ」
    tenkoma
    tenkoma 2018/05/02
  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
    tenkoma
    tenkoma 2018/05/02