やる気がストロングZERO

やる気のストロングスタイル

性別カラムを1,2で用意するとき、1が男, 2が女だという情報をどこに持つか

性別カラムを1,2で用意するとき、1が男, 2が女だという情報をどこに持つか。

user情報テーブルに性別カラムを用意して男女を1or2で保持させる場合、1が男、2が女である情報をどこに持つのがよいか以前議論になったのを思い出した。

システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
こういう話もあるけど、今回提示した「性別カラム」は例であって、この記事に記載されているようなことは一旦考えない

案A: コード上に持つ。

個人的観測範囲でよく見かける。
DBには1, 2という情報しかなく、アプリケーションコード側に対応表を持たせている(dictデータ構造で'男' => 1, '女' => 2など)
DBで持ってもレコードが追加されることも、値が変更されることもまずない。更新されることがないのであれば、変化するDBへ持っておくメリットはなく、定数としてコード上に埋め込んておくほうがよい、というような意見だった気がする。

案B: テーブルでデータを持つ。

性別マスタテーブル(1, 男 2,女の2レコードのみ)を持つ。
個人的にはこちら派。

自分が案Bが良いと思う理由。

案Aの場合、DBだけ見た時1が何なのか、2が何を意味するのかわからない。
案Bの場合、DBだけで意味が理解できる。
「DBの寿命はコードよりも長い」に従って、仮にアプリケーションコードが死んで、DBだけ生き残って引き継がれた場合、案Aだと一部の情報が失われてしまうあたりが「それでいいのか?」と気になっている。
そんな状況、実際どれくらい発生するねんって話ではあるけど。

案Aの場合、未定義の値(例えば99等)が入れられてしまうことが可能。
案Bの場合、外部キー制約で1or2しか入らない。これが大きいと思っている。

テスト駆動開発の一番大きいメリットは「テストコードができる事」ではなく「システムの複雑性が下がる事」

僕はテスト駆動開発(以下TDD)の信者だ。
TDDを学びだした最初は「TDDのメリット」とは「テストコード」が同時に出来上がり回帰テストが可能になる事だと思っていた。 しかしすぐに「TDDで開発を行うとシステムの複雑性が下がりやすい」事こそが最大のメリットであると気がついた。 その事について書く。

TDDで開発しない場合

構造に対して興味が薄い人が作業した場合、以下のような感じでコードが書かれている事が良くある。

# userのtypeを更新する(コード構造イメージを示すだけで、処理自体に特に意味はない)
X処理() {
    # DBからデータ取得する処理
    user = load()

    if user.status == 1 {
        user.type = 1
    } else {
        user.type = 2
    }

    # DB保存処理
    save(user)
}

データの取得や永続化と処理がごっちゃに実装されている。 この関数を使っている側からのコードの見た目は以下のようになる。

続きを読む

俺専用の最強メモアプリを作ってる(メモった内容を後から探すのムズい問題の解消)

メモって難しい。
メモる事自体は難しくない。
メモった内容をあとから参照するのが難しい。

どこに書いたか忘れる問題

最近メモった内容であれば問題ない。
どこにメモったか覚えているのですぐ見つかる。

でも「1年前に着手していた作業の関連資料を置おいてある共有ディレクトリのパス」をどこにメモったかなんて覚えてない。

続きを読む

食洗機を買ってよかった

こちらの食洗機を買った。

前々から欲しかったが、買ってみてやっぱり食洗機は生活を変えるマストアイテムだと改めて思ったので書く。

買ったこちらのタイプは分岐水栓工事が不要で置けば使えるタイプ。 自分は賃貸なので、管理人に確認が必要だったり、退去時にもとに戻す必要がある分岐水栓工事はやりたくなかったためこのタイプにした。

自分で水を入れる作業が必要だったり、一度に入る食器の量が少なかったりというデメリットもあるが、夫婦2人と赤ちゃん1人なら1日2回回せば足りる感じ。 子供が大きくなってきたら毎回回す必要が出てくるかも。

  • 「洗い物残ってるなー」という重い気分が全く無くなった
  • 手洗いよりもピカピカ
  • 夫婦喧嘩の種が一つ消えた

「洗い物残ってるなー」という重い気分が全く無くなった

洗い物が残ってると、食後リラックスしていても「Todo」として頭に残っていてどこかでリラックスしきれない。 ズルズル行くと最高潮に眠たくなったときに洗い作業をやるハメになったりする。

続きを読む

開発作業でVimを普段使いするためにやったこと

  • Vim普段使いにトライしようとした理由
    • JetBrains製IDEだと別言語の複数プロジェクトを並行して扱おうとするとフラストレーションが溜まる
    • VsCodeや各エディタのVimプラグインではなくVimを使いたい理由
  • 過去にVim使いになろうとして失敗した原因と今回の対策
    • 使い方を一気に大量に覚えないと全く使えない
  • 対策:マスタリングVimを読みながらankiに使い方を登録して一気に覚えた
    • 僕はIDEの定義場所ジャンプや参照先検索やコード補完に依存しているのでこれがないと効率が落ちる
    • 対策: LSPを使う
  • 結構快適に使えている
    • 対象ファイルを探して開くのが早くなった
    • アプリの行ったり来たりがなくなって作業が楽になった
    • マウス操作が格段に少なくなって楽になった
    • オープンソースのコードリーディングが捗る
  • それでもまだたどたどしい
    • ワークスペースがまだ安定してない
    • たまに未知の操作に遭遇し詰む
    • 落ち着いていないと詰む
  • よくわからない挙動がある
    • LSPはまだ使いこなせていない
  • まとめ
続きを読む

【ssl/tls】ルート証明書がどこにあるのかちょっとわかったけど、まだよくわからんメモ

証明書がどういう仕組で機能を実現しているのかざっくりは理解していた(https(ssl)通信設定の概要 - やる気がストロングZERO)つもりだったが、改めて考えてみたら、ルート証明書がどこにあって、どうやって使われているのかいまいちよくわかってなかったので調べてみた。

結果的に結局まだよくわかってないが、わかったことについてメモ。

Ubuntuでは/etc/ssl/certs/にルート証明書が入っていた

例えばrubygems.orgのサーバー証明書ルート証明書は「GlobalSign Root CA - R3」である。

続きを読む

【Toggl track】と【todoist】と【Anki】で仕事を補助するとなかなか良い

最近仕事で以下ツールを使ってみている。

  • Toggl track: タイムトラッキングツール
  • todoist: Todoツール
  • Anki: 記憶補助ツール

まだ本格的に使いだして間があまりないが、今の所凄く良いように感じているのでそれについて書く。

  • toggl trackで自分が何に時間を使っていたかを記録する
  • todoistでやることを全部管理する
  • Anki で業務知識を覚える
  • まとめ
続きを読む