2022年4月4日のブックマーク (6件)

  • 外部キー制約が一切ないと何に困るのか?

    こんにちは。株式会社プラハCEOの松原です 注目を集めつつあるMySQLプラットフォームのPlanetScaleですが、外部キー制約が効かないという一見致命的に見える仕様について調べていたところ、こちらのDiscussionで興味深い回答が開発者から寄せられていたので日語でまとめ直してみようと思いました。 外部キー制約がなくてもそれほど困らない理由 今回の話はParentテーブル(id)とChildテーブル(id,parent_id)を前提に考えていきます そもそも外部キー制約は何に役立つのか 今回のDiscussionでは質問者から「外部キー制約がないとこういう時に困るよ!」と質問が寄せられています: 外部キー制約がないと参照先のデータが存在していることを保証できない! 外部キー制約がないとデータの重複を回避できない! それぞれの質問に対して回答者の回答は以下の通りです: 外部制約がな

    外部キー制約が一切ないと何に困るのか?
    xlc
    xlc 2022/04/04
    外部キーを使うと性能に問題が出るので、試験時には外部キーを貼っておき(制約違反はエラーにする)、運用時に外すのがよいよ。
  • すべての社内文書はMarkdownで書けばいいと思うこれだけの理由 - Qiita

    Markdownを社内に布教したい、というモチベーションからMarkdownを勧める理由をまとめたもの。 同じようなことを考える方へ、周囲への説得材料になると嬉しい。 1. Markdownを勧める理由 1-1. 圧倒的理由 全人類がマークダウンを学習すべき理由|情報デザイン力を鍛えよう Markdownとは (日Markdownユーザー会) をMarkdownで引用する。 Markdown(マークダウン)は、**文章の書き方**です。 デジタル文書を活用する方法として考案されました。特徴は、 - 手軽に文章構造を明示できること - 簡単で、覚えやすいこと - 読み書きに特別なアプリを必要としないこと - それでいて、対応アプリを使えば快適に読み書きできること などです。 Markdownはジョン・グルーバー(John Gruber)によって2004年に開発され、 最初は [Darin

    すべての社内文書はMarkdownで書けばいいと思うこれだけの理由 - Qiita
    xlc
    xlc 2022/04/04
    MarkdownなんてREADMEくらいにしか使えないだろ。中国のIT企業勤務だが、そういえば社内文書がないことに気づいた。全部Webだった(なのでHTML)。
  • 「理研600人リストラ」に中国人ITエンジニアは「不思議です」と繰り返した(NEWSポストセブン) - Yahoo!ニュース

    国立研究開発法人の理化学研究所の労働組合などが、約600人の研究者が雇い止めとなる可能性があるとして、文部科学相と厚生労働相あてに要望書を提出した。近年は、日人のノーベル賞受賞者がまるで口をそろえたように、日の科学力の低迷と研究環境の悪化を訴えてきたが、歯止めどころか拍車がかかっているような出来事だ。俳人で著作家の日野百草氏が、中国技術者が日の研究者や技術者の環境をどう見ているのか聞いた。 【写真】アーチの天井に装飾柱もある歌劇場でマイクを向けられるノーベル賞受賞者・眞鍋淑郎氏。他、ハイアールの重厚感ある銀色の洗濯機が並びゴシック姿の女性が立つ様子 * * * 「日は優秀な人がとても安いと思います。なぜ辞めさせるのですか」 筆者の旧知の中国技術者から話を伺う。ITエンジニアゲーム開発にも精通している。中国人のエリートならごく当たり前だが4ヶ国語を話せて日語も堪能だ。しかし

    「理研600人リストラ」に中国人ITエンジニアは「不思議です」と繰り返した(NEWSポストセブン) - Yahoo!ニュース
    xlc
    xlc 2022/04/04
    日本は「コミュ力重視」の文系文化なので、理系人材を嫌悪するのです。だから衰退したのですがね。若者はバカで逆らわず安月給で働くので歓迎されます。
  • 『毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba』へのコメント

    ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有

    『毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba』へのコメント
    xlc
    xlc 2022/04/04
    コメントから「意識高い系」のヤバさがわかる。個人の範疇で作業したものを日に何度もリリースしたら絶対にバグが出る。チームで保障すべし。バグは出しても修正すればいいという文化?それがダメな世界もあるよ。
  • 毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba

    CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン

    毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
    xlc
    xlc 2022/04/04
    CIが保証するのは「テストが行われること」であって新規機能のテスト内容が正しいことではない。自動デプロイの危険性はそこにある。/ 日に何回も直すなら機能追加でなくリファクタリングか。最初から綺麗に書けよ。
  • ほとんどの説明会は読めば分かることをいちいち説明する会なので、文章に抵抗がない人にとっては苦痛になりがち

    George @Love_yellowhat ほとんどの説明会は読めばわかることをいちいち説明する会なので、文章を読むことに抵抗がない人にとっては、説明会自体が大変苦痛なのである。 2022-04-01 17:53:51

    ほとんどの説明会は読めば分かることをいちいち説明する会なので、文章に抵抗がない人にとっては苦痛になりがち
    xlc
    xlc 2022/04/04
    説明する側がちゃんと理解しているかチェックするために説明会を開いてもらってる。見積もり依頼とか特にそう。説明してもらって初めて重要事項が書かれていないことが判明する。