技術ブログ

(技術系中心)基本自分用備忘録なので、あくまで参考程度でお願いします。

DB設計をするときに気をつけていること

データベースはシステムの基盤です。

DB設計に失敗するとアプリケーションの実装が複雑になる、などの辛い思いをします。

また、後から修正するのは実装影響が大きいため容易ではありません。

DB設計する上で自分が普段気をつけている箇所を記載します。

1, 検索するカラムにはINDEXを貼るようにする。(JOINするテーブルが2つ程度なら問題ありませんが、JOINの回数が増えると急激に重くなるの)

2, 後から必要になりそうなデータ(ユーザー情報)削除は物理削除ではなく、論理削除にする

3, booleanの場合はnull許容しない、またdefult値を必ず設定する

4, 自分だけではなく他人が見てわかりやすいカラム名称をつける

5, ユーザー(利用者)の購入履歴などのユーザーが後で見返したい情報は履歴テーブルに保存する

6, 開発者が後のバグなどを調査しやすいようにログテーブルを作成する

7, Json形式での保存はできる限り避ける(JSONデータ型は汎用性が高く便利だが、保存内容が不透明、SQL検索しづらいなどのデメリットが多い)

8, booleanのカラムはひと目でわかるようにする(is can has_ の様なprefixを付ける)

9, 正規化する

参考

DBエンジニア必見 => 名著「失敗から学ぶRDBの正しい歩き方」のまとめ - Qiita

【初心者向け】データベースのテーブル設計で僕が意識している6つのこと - Qiita

データベース設計の際に気をつけていること - 食べチョク開発者ブログ

データベース(RDB)設計の進め方! - Qiita

gitコミットをまとめる方法

gitコミットをまとめる方法

コミットメッセージを修正する場合

コミットID_4 (HEAD -> master)コミットメッセージ_4
コミットID_3 コミットメッセージ_3
コミットID_2 コミットメッセージ_2
コミットID_1 コミットメッセージ_1

1, git rebase -i <コミット ID>

コミットID_2 〜 コミットID_4 をまとめる場合は コミットID_1

git rebase -i HEAD^^^ HEAD^^^^で3つ分のコミットを編集します。

2, Edit モードで rebase 指示書を修正する

r コミットID_2 コミットメッセージ_2
f コミットID_3 コミットメッセージ_3
f コミットID_4 コミットメッセージ_4

# Rebase xxxxx..yyyyy onto zzzzzz
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]

3. コミットメッセージの修正

Edit モードを :wq でセーブして抜けるとコミットメッセージの修正が求められるので修正する

ミスったときの対象方法

error: cannot 'fixup' without a previous commit
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.

こうなった時は、git rebase --abortで元に戻せます

参考リンク

基本これみればOK

コミットをまとめる方法(git rebase -i)

gitで細かくコミットしたのを1つにまとめる|十 taro 十|note

【Git】離れた複数のcommit(コミット)をまとめる方法|Webエンジニア研究室

Gitのコミットメッセージを後から変更する方法

ケース1「直前にコミットしたメッセージを変更する」

あ、コミットメッセージ名をtypoしてしまった!などの時に利用できる。

1. コミット履歴を確認して、直前のコミットしたメッセージ内容を確認

git log --onelineでコミット履歴を確認して、メッセージ内容を再確認する

2. git commit --amendでコミットメッセージ修正

git commit --amendでメッセージ修正できます。

例)git commit --amend -m "cssを修正"とすると直前のコミットメッセージをcssを修正と変更できます。

3. コミットログを見て内容が書き変わっているか最終確認

git log --onelineで再度直前のメッセージを確認してみよう。

直前のコミットメッセージが"cssを修正"`に変更されていればOK

参考リンク

Gitのコミットメッセージを後から変更する方法をわかりやすく書いてみた | 株式会社グランフェアズ

Gitのコミットメッセージを後から修正変更する方法! | Qumeruマガジン

ActiveRecord::Type::Booleanでフラグ条件判定する便利な方法

has_option_thumbnail == 'true' みたいな条件判定をした場合、has_option_thumbnail == 'TRUE'のような場合ではfalseと判定されてしまいます。

この対策としてhas_option_thumbnail == 'true' || has_option_thumbnail == 'TRUE'にすればOKなんですが、なんかダサい。

■ Active Model Type Booleanで条件判定する

Active Model Type Booleanを利用すればスマートに条件判定できます。

ActiveRecord::Type::Boolean.new.cast('true' ) -> true ActiveRecord::Type::Boolean.new.cast('TRUE' ) -> true

参考リンク:

ActiveRecord::Type::Boolean

仕事する上でのtips

仕事していく上で大事なロジカルシンキングの考え方やチップスのまとめ

話し方

■ 結論ファーストで話す

何が言いたいのかわからない人の典型的パターンは「で、何が言いたいの?」

その対策として結論ファーストで話すように意識する。

PREPを意識するともっと良い

Point => 結論
Reason => 理由づけ
Example => 具体例
Point => 結論の繰り返し

■ 数字で語る

感情で物事を話すのではなく、客観的な数字を根拠に物事を語るのが大事。

また、数字で説得することで「証拠」を見せつけることができるので人を納得させられる可能性が上がります。

 

仕事の進め方

■ 優先度と緊急度で取り掛かるタスクを決める

しないといけないタスクが多い場合は優先度と緊急度で取り掛かるタスクを決める。

例)

タスクA 優先度4 緊急度5 = 合計9
タスクB 優先度2 緊急度5 = 合計7
タスクC 優先度3 緊急度2 = 合計5

タスクAの合計点が一番高いのでタスクAを最優先で取り掛かる

■ 取り掛かる前に手順を考える

タスクに直ぐに取り掛かる前に一度、まずかアプローチ方法を考えるの大事。

まずは大きな設計図を描いて、その後に細部に落とし込むことが大事。

■ 相手の期待値を把握する

仕事を振られたときに相手が何の成果物を求めていて、どのぐらいのアウトプットの期待値を求めているか把握することが大事。

相手が期待する中身がわかったら、それを絶対に外さない。

そして、相手の期待値以上の成果を出す。

■ 答えを求める前に1分でも良いので自分で考える時間を作る

すぐに答えを求める前に一度自分の頭で考える癖をつけると成長につながる

■ 相談するときは自分の意見も添える

どうしたらいいですか?とすぐに答えを求めるのはNG?

ダメな例)
こういう現象が起きていて困っているのですが、どうすれば良いですか?

良い例)
こういう現象が起きて困っています、Aという方法でこの現象を解決できると思うのですが、どう思いますか?

考え方

■ 課題にはロジックツリーで現状分析する

ロジックツリーのメリット

  1. 問題を発見しやすくなる
  2. 問題の原因を特定しやすくなる
  3. 問題の解決策を考えやすくなる
  4. アクションの優先順位をつけやすくなる
  5. チームを動かしやすくなる

参考文献

コンサル一年目が学ぶこと

JavaScriptの引数について

呼び出し時の引数が多いとき

関数の仮引数に対して引数の個数が多い場合、あふれた引数は単純に無視されます。

function add(x, y) {
    return x + y;
}
add(1, 3); // => 4
add(1, 3, 5); // => 4

デフォルト引数

lhiroki1205.hatenablog.com

可変長引数

仮引数名の前に...をつけて呼び出すと、、関数に渡された値が配列として代入されます。

function fn(...args) {
    // argsは引数の値が順番に入った配列
    console.log(args); // => ["a", "b", "c"]
}
fn("a", "b", "c");
function fn(arg1, ...restArgs) {
    console.log(arg1); // => "a"
    console.log(restArgs); // => ["b", "c"]
}
fn("a", "b", "c");

配列展開して関数に引数を渡す方法

function fn(x, y, z) {
    console.log(x); // => 1
    console.log(y); // => 2
    console.log(z); // => 3
}
const array = [1, 2, 3];
// Spread構文で配列を引数に展開して関数を呼び出す
fn(...array);
// 次のように書いたのと同じ意味
fn(array[0], array[1], array[2]);

JavaScritpの暗黙的型変換について

JavaScritpの暗黙的型変換について

JavaScriptでは演算子による演算や関数の処理過程で暗黙的な型変換が行われます。

// 異なる型である場合に暗黙的な型変換が行われる
console.log(1 == "1"); // => true
console.log(0 == false); // => true
console.log(10 == ["10"]); // => true

さまざまな暗黙的な型変換

1 + "2"; // => "12"
// 演算過程で次のように暗黙的な型変換が行われる
"1" + "2"; // => "12"

上記のように2つまでなら、結果の型を予想できます。 しかし、3つ以上の値を扱う場合に結果を予測するのが難しくなります。

const x = 1, y = "2", z = 3;
console.log(x + y + z); // => "123"
console.log(y + x + z); // => "213"
console.log(x + z + y); // => "42"

まとめ

JavaScriptは、型エラーに対して暗黙的な型変換をしてしまうなど、驚くほど曖昧さを許容しています。

思わぬバグに繋がるので顕著なアプリケーション作りたいならTypeScriptがお勧め

参考

暗黙的な型変換 · JavaScript Primer #jsprimer