やる気がストロングZERO

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

設計

高トラフィックに耐える構成を考える

高トラフィックに耐える構成についてざっくり書いてみる。 インフラエンジニアでもないので間違いあるかも。 アプリケーションサーバー ステートレスに作っておいて、稼働台数を増やしてLBで振り分ける。 LBに対してはDNSラウンドロビンで負荷分散させる。 D…

行われている処理がイメージできるようなテーブル構造を設計したい

見れば行われている処理がイメージできるようなテーブル構造を設計するのが良いと思っている。 このテーブル構造で何が読み取れるか? user id state 1 active 2 active 3 disactive ... ... userはステータスを持っているのはわかる。 データを見るとほとん…

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

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

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

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

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

メモって難しい。 メモる事自体は難しくない。 メモった内容をあとから参照するのが難しい。 どこに書いたか忘れる問題 最近メモった内容であれば問題ない。 どこにメモったか覚えているのですぐ見つかる。 でも「1年前に着手していた作業の関連資料を置おい…

【エンジニア職】手元で実行できないシステムを作ると定時で帰れなくなる説

エンジニア職で慢性的な残業が発生している現場がなぜそうなるのかを考えてみた結果、原因の一つとして「手元で実行できないシステムを作ると定時で帰れなくなる説」を思いついたのでこれを提唱したい。 手元で実行できないシステムを作ると、仕様知識が失わ…

「全てのstateカラムを、生まれる前に消し去りたい。全ての宇宙、過去と未来の全てのstateカラムを、この手で」

「あいつ(stateカラム)ら……駆逐してやる! この世から……一匹残らず!」とも言う。 自分はstateカラムが嫌いで、痛い目しか見てないのでいい加減にこの世から無くなってほしいと思っているが、現実はそうも行かず、今なおどこかで新しく生まれ続けている気が…

PHPの文化を確認しようとGuzzleを読んでみた

仕事でまたphpに触れる事になった。 以前からphpのシステムに触れる時、配列に何でもかんでも入れるコードをよく見かけていた。 javaやC#であればDAOとしてclassを定義するところであるが、phpでは配列にどんなものでも入れられるのでそれを良いことに特にcl…

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

最近仕事で以下ツールを使ってみている。 Toggl track: タイムトラッキングツール todoist: Todoツール Anki: 記憶補助ツール まだ本格的に使いだして間があまりないが、今の所凄く良いように感じているのでそれについて書く。 toggl trackで自分が何に時間…

【テーブル設計】削除フラグを使わず削除テーブルを使うべき

データの削除機能において、何らかの理由でデータは残しておきたい場合には「削除フラグ」が使われがちだが、これは絶対にやめたい。 この場合は「削除テーブル」を用意してそちらにデータを移し、元テーブルからはレコード削除を行うようにするべきだと思っ…

システムドキュメントの管理方法のベストプラクティスを考える

システムドキュメントの管理って地味に難しい。 そもそもドキュメントが無かったり、どこにあるのか分からなかったり、あっても情報が古かったり、複数の場所や形式に分散していたりしていて、いざという時に全然使えないような状態になってしまってたりする…

【Golang】sql.Open(), Close()を呼ぶタイミング・場所について考えた

GoでDBアクセスする為のサンプルコードを探すとどこもこんな感じ func main() { # dbコネクション(pool)を取得 pool, err = sql.Open("driver-name", *dsn) if err != nil { // This will not be a connection error, but a DSN parse error or // another i…

アプリケーション要件に関わらずテーブルには事実を記録する

「このアプリケーションのこの機能は【年月日】までしか意識しない。【時分秒】はデータとして不要なのでテーブルにはdate型で【年月日】だけ持たせれば良い。」 と言われた事があったが例えアプリケーションにとって不要でもDBテーブルにはdatetimeとかtime…

扱いやすいテーブル・扱いにくいテーブル

システムのDBには様々なテーブルが定義されている。 色々作業していると「扱いやすいテーブル」「扱いづらいテーブル」がある事に気がつく。 なんとなく見えてきたパターンについて書いてみる。 ※もしかしたら当たり前の知識なのかもしれないが、自分の観測…

評価制度について考えた事

サラリーマンやってると人事評価(僕はされる側です)でいつも悩む。 「この業務って売上に直接かかわらないから評価され辛いんだよな。。」とか「なにはともあれコツコツ地道に真面目に頑張ってたらちゃんと上司は見てくれているハズ」とか、「え、もう人事…

バッチ処理のベストプラクティスについて考える

みずほ銀行の本を読んでいて、バッチ処理は鬼門だなと感じた。 みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」作者:日経コンピュータ,山端 宏実,岡部 一詩,中田 敦,大和田 尚孝,谷島 宣之発売日: 2020/02/14メディア: Kindl…

「シンプルな構造にすれば保守性があがる」わけではないという話

こんがらがったシステムの保守開発で苦労した経験から新規開発では「シンプルな構成・シンプルな実装にしよう」という話が出る。 目指す方向としては間違って無いように思えるのに、それだけだとうまく行かない。 「保守しやすい構造」とはそれなりに多くの…

やっぱり正規化をベースにしたテーブル設計しか勝たん

テーブル設計は正規化を基本にして設計する手法しか成功しない気がしてる。 DBやテーブル設計系の書籍を読むとどれにも「正規化」による設計手法が書かれているけど、現場ではなぜかあまり正規化に重きをおいた設計が行われていない場合が多かった。 先人の…

DDDのメリットを勘違いしてた件

僕はDDDで「俺が考える最強の契約管理システムを作る」というのをやってみている。 もう100回を超えた。 www.youtube.com 目的としては、外部からあれこれ言われず自分が思う通りに実装を進めて、自分だけの責任で躓いて、自分で「良い・悪い」を体験する事…

【DB設計】データ複製して持ちたくないと思ってる理由

僕はデータを複製して持ちたくないとずっと思っているけど、 色んな意見聞いてると自分でもそれが本当に良い事なのかわからなくなりそうだったので、 なぜ複製が嫌いなのか書きながら考えを整理してみた。 データを複製すると不整合が起きるから嫌だ 計算結…

「良いコード」と「良くないコード」の特徴

自分が思ってる「良いコード」と「良くないコード」の特徴を書きなぐってみる。 関数 良い 引数と返り値を見て、何をしているのかなんとなくわかる。 c = add(a, b) # aとbが加算されてるっぽい 良くない 引数と返り値を見ても、何をしているのかよくわから…

postgreSQLのtimestampはtimezone情報がないのでtimestamp with time zoneを使うのが良さそう

postgres のtimestampはタイムゾーンをもってない 。 だからデータを入れるとき、取得するときにタイムゾーンを気にしないといけない。 timestamp with time zoneで定義すべきかなと思う。 基本的にシステム内部で時間を扱うときは統一的にUTCで扱い、出力時…

kubernetesクラスタで永続化データを扱うのは難易度が高いのでやめたほうがいい

仕事でkubernetesの本番運用を検討して思ったことをまとめる。 あくまで「kubernetesをとりあえず動かせる」程度の理解レベルにての話で、知識豊富な専門家が取り組むのであればこの限りではないと思う。 kubernetesクラスタで永続化データを扱うのは難易度…

YouTubeで公開システム構築をやってみている

「俺が考える最強の契約管理システムを作る」というタイトルのYoutube動画を投稿している。 [再生リスト] 俺が考える最強の契約管理システムを作る - YouTube こんなん。 youtu.be 作業リポジトリも公開してます。 GitHub - mixmaru/my_contracts: 俺が考え…

【テーブル設計】フルネームで保持しているカラムを後から「名字・名前」に分けたい時

フルネームで保持しているカラムを後から「名字・名前」に分けたい時、どうすればいいか考えてみた。 出来たと思うけど、脳内シミュレーションしただけで実際にシステムに対して行ったことがあるわけではないので、もしかしたら穴があるかも。 サンプルケー…

読み解きづらいコード

自分が「読み解きづらいな」と思ったコードに対して、なぜ読み解きづらいと思ったのかを考察し、 また、そうならないようにどうしたいかを考えたので書いてみる。 個人的な考えだし、エンジニアレベルとか状況とかで変わると思うし、僕が見えてない事情とか…

【Go】gorpを使ってDDDのRepositoryを書いた

goを使ったシステムにて、DBアクセス周りでgorpを使うことにしたので色々調査してDDDで言うところのrepositoryを書いた。 gorp GitHub - go-gorp/gorp: Go Relational Persistence - an ORM-ish library for Go gorpを選んだ理由 データ取得は「SQL文を直接…

テーブル数が増えることを避けた末路(シミュレーション)

テーブルの正規化を理由にテーブルを増やす提案をしたら嫌がられた記憶がある。 「なるべくテーブルを増やしたくない。たぶんカオスになる」という考えっぽいけど、これは正しく設計されずに不要なテーブルを作成されまくってしまったケースの経験が元になっ…

業務でTDDしにくいけどTDDしてみた

業務でもTDDをやるのは有用だと思ってる。 個人的には必須だと思ってる。 いままで数カ所の現場で働いてきたけど、なぜかTDDを導入しているところは無かった。 有用だと思う理由とか経験 実装完了し、コードレビューや開発内手動実行テストが通った後、最終…

処理の内部で現在時刻を取得したくない

内部で現在日時を取得してそれによってなにか判断したてたりするやつが好きではない。 結構よく見かける。 例えば以下のような年齢を求めるロジック。 class human() def age() today = Date.today() age =# (todayと生年月日で年齢を計算) return age end e…