【随時更新】よく使う単語の意味・英訳
【随時更新】使用したSQL文
はじめに
今、某フリマアプリのクローンサイトをrailsでチーム開発しております。
私は、本番環境(AWS)の構築と運用担当＆個人的な鍛錬のため、sequel Proから卒業し、ターミナルでSQLを使って操作することを自分に課しております。
そこで、この記事では、使ったSQL文をメモしたいと思います。
（随時更新します。）
テーブル内のレコードをすべて削除する
（2019/11/25更新）
構文
DELETE FROM [テーブル名];
例
brainsテーブルのレコードを全部消す。
DELETE FROM brains;
これで、頭の中が空っぽになります。
指定したレコードを削除する
（2020/01/17更新）
構文
DELETE FROM <テーブル名> WHERE 〜
例
brainsテーブルからmemoryカラムの値が「好きだったのに、思いを伝えられなかった中学３年間」を削除
DELETE FROM brains WHERE memory = "好きだったのに、思いを伝えられなかった中学３年間"
これで、甘酸っぱくてほろ苦い青春の思い出を忘れさることができます。
WHERE
（2019/12/09更新）
シンブルにWHEREの書き方をど忘れしてしまったため、自戒を込めて記載します。
RailsのActiveRecordいじり過ぎて、WHERE(name: 1);って書いてました…
構文
SELECT <カラム名> FROM <テーブル名> WHERE <カラム名>=<レコード>;
SQL文の入力を途中でやめたいとき
（2019/12/12更新）
SQLを書いているとき、いくら;を打っても抜け出せない（->が表示され続ける）ことがあって、一生SQL文を打ち続ける刑に処されたのかと思いました。
そこで、今日は入力を途中でやめたいときに、輪廻の連鎖から抜け出す方法を書きます。
そのコマンドは…
\c
です。
１つのカラムの値だけ、削除したい
（2020/01/29更新）
使用場面
usersテーブルに保存したレコードのうち、phoneカラム（携帯電話）の値だけを削除したいとき
方針
調べてみると….
DELETEで消せる最小単位は、レコード（つまり、特定のカラムの値だけを削除することはできない）UPDATEを使って、その値だけをNULLにする （「NULL クリア」）
ということがわかりました。
コード
今回はidが1のuserから、phoneカラムの値だけをNULLにします。
UPDATE users SET phone = 'NULL' WHERE id = 1;
注意点
NOT NULL制約など設定していると、更新できないです。
2019/11/05_MYSQL（テーブルの選択まで）
はじめ
チーム開発で、本番環境構築担当をしております。
そういえば、本番環境では、MYSQLをSQL文で操作するんだろうなーと気づいたので、MYSQLでテーブルを選択するまでの手順をまとめたいと思います。
ちなみに、ポスグレは以下にまとめました。
2019/09/25_数学、32点（簡単なpostgresqlとsql文） - 記憶の外付けHDD
MYSQLの操作
MYSQLに接続
mysql -u root
- mysqlにユーザー名rootで接続する
mysql>という表示がでてくれば、接続成功- 本番環境の場合は
mysql -u root -pにする
データベース一覧を表示
show databases;
データベースの選択
例）database「practice」を選択
use practice;
useを使用する
テーブル一覧を表示
show tables;
テーブルのカラムを確認
例）table「users」内のカラムを表示する
show columns from users
show columns from テーブル名
あとがき
データベースの種類によって結構コマンド違うんですね。
とりあえず、ここ数ヶ月はMYSQLを使うので、まずはMYSQL
をしっかり覚えたいです。
【随時更新】Gitのコマンド
はじめ
一週間前から、チーム開発をしており、チェリー本の読書記録を怠っておりました…
しかし、Gitを使いまくっているおかげで、Gitに関する知識が増えているので、それを記録したいと思います。
※ 随時、ちょっとずつ更新します！
Gitのコマンド
リモートリポジトリをクローン
(2020/01/26追記)
1. クローン作成するディレクトリに移動する
※ 今回は、projectディレクトリに移動
cd project
- クローンする
git clone <リモートリポジトリのURL>
ブランチの新規作成
（2019/11/04記載）
git branch <新ブランチ名>
ブランチの新規作成（checkoutも同時に）
（2019/11/04記載）
- 「新ブランチの作成」と「ブランチの切り替え」を同時に行う場合
git checkout -b <新ブランチ名＞
※ 調べてないのですが、新しいブランチをbirthするから、-bって覚えてます(笑)
ローカルブランチ名の変更
（2019/11/04記載）
名称を変更するブランチに切り替えた状態で
git branch -m <変更後のブランチ名>
※ どうやら、リモートブランチは名称変更できないため、削除する必要があるっぽいです
ローカルブランチの削除
（2020/01/04更新）
使用場面
- 開発ブランチの内容をmasterブランチに反映したため、開発ブランチが不要になった
コード
git branch -d <削除するブランチ名>
プッシュ
（2019/11/06記載）
git push <リモートリポジトリ名> <ブランチ名>
プッシュ&追跡ブランチの設定
（2019/12/07記載）
プッシュするときに-uを記載することで、追跡ブランチに設定することができます。
次回からのプッシュ時にgit pushだけで指定したリモートリポジトリのブランチにpushすることができます。
（つまり、煩わしい<リモートリポジトリ名> <ブランチ名>の記載が不要になる）
# プッシュ＆追跡ブランチの設定 git push -u <リモートリポジトリ名> <ブランチ名> # 次回から git push
追跡ブランチがわからなくなったら（その１）
（2019/12/09記載）
「あれ？ガスの元栓しめたっけ？」的な感覚で、「ちゃんと追跡ブランチを設定したっけ？」と疑心暗鬼になることが多々あります。
そんなとき、以下のコマンドで追跡ブランチを設定したか否か確認できます！
git status -sb
-sbは--short --branchの略--shortオプションは、git statusの内容を短く表示する
追跡ブランチがわからなくなったら（その２）
（2019/12/09記載）
普通にgit statusを打つと表示される以下の表示で確認することもできます。
Your branch is up to date with 'origin/hogehoge'.
↑ このブランチはorigin/hogehogeを追跡しているって意味です。
差分確認シリーズ
git addしたあとの差分確認
（2019/11/04記載）
- git commit前に確認したいときに使用する
git diff --cached
（chachedってどういう意味なんだろ…？）
git commitした後の変更点を見る
（2019/11/04記載）
git diff HEAD^..HEAD
HEAD^は 最新のコミットの１つ前HEADは 最新のコミット..は、↑の両者を比較する
の意味…？
コミット履歴の修正
（2020/01/13更新）
修正対象：前回のコミット
流れ
- 普通にコードを修正する
- 普通に
git addする git commit --amendする
→ エディターで前回のコミットメッセージ等が表示される
（コミットメッセージの修正も可能）
修正対象：２回以上前のコミット
プルリクしたあとの、レビュー後にコードを修正することになった場合、コミット履歴をきれいにする方法を記載します。
大きな流れ
git commit --fixup 統合先コミット番号で修正コミットと統合先コミットを結びつけるgit rebase -i --autosquash HEAD~数字で修正コミットと統合先コミットを結合するgit push -fでgit hub上のコミット履歴を強制的に変更する
git stash
(2020/01/04更新)
使った場面
- masterブランチを間違えて修正してしまった
git stash
一時的に修正内容を退避させたいとき
git stash save
※ saveは省略可能
stashにメッセージを追加したい場合
git stash save <message>
コミットメッセージの修正
（2020/01/11更新）
前回より前のコミットメッセージを修正
大きな流れ
git logで修正するコミット番号を確認git rebase -i <コミット番号>~1- エディターが開く
→ 修正するもののpickをrewordに変更
→:wq（エディターを閉じる） - コミットメッセージの修正
前回のコミットメッセージを修正
大きな流れ
git commit -- ammendを使う
分岐元のブランチを修正(git rebase)
（2020/01/11更新）
大きな流れ
- ローカルリポジトリのマスターブランチを最新の状態にする
- 開発ブランチにcheckoutする
git rebase master- コンフリクトを修正する
一時退避（git stash)
（2020/01/11更新）
退避しているものの確認
git stash list
退避しているものを戻す
例）git stash listでstash@{0}と表示されているものを戻す
git stash apply stash@{0}
2019/10/23_チェリー本（16日目）
はじめに
昨日もチェリー本をちょっとだけ読みました。
読んだ本
本編
読んだページ数
- 第4章（P125〜131）
新しく知ったこと
添え字付きの繰り返し処理
- each以外の繰り返し処理を行うメソッドで、each_with_indexメソッドのようなことをする場合、with_indexメソッドを指定する。
(もちろんeachでも使える) - 引数に指定した数から添え字を始めることもできる。
cm = ["カステラ","電話","文明堂"] cm.map.with_index(1){ |c, i| "#{i}:#{c}" } #=> ["1:カステラ", "2:電話", "3:文明堂"]
with_index(1)にしているので、０ではなく、１から始まっている。
「カステラ１番、電話は２番、３時のおやつは文明堂」をインスパイヤーした例なんですけど、わかりずらいっすよね…これ…
あとがき
いつのまにか、こんな時間に…
おやすみなさい！！
以上
2019/10/22_チェリー本（15日目）
はじめに
昨日もチェリー本をちょっとだけ読みました。
読んだ本
本編
読んだページ数
- 第4章（P119〜）
新しく知ったこと
文字列を配列に変換する
charsメソッドを使う
"目肩腰".chars #=> ["目", "肩", "腰"]
文字列が分解されて、各１文字を要素にする配列が作成。 筆者が最近凝り固まっている部分を要素とする配列が完成した。
ミュータブルとイミュータブル
| 種類 | 意味 | 代表例 |
|---|---|---|
| ミュータブル (mutable) |
「変更可能な」 →破壊的な変更 ○ |
Stringクラス |
| イミュータブル (imutable) |
「変更できない」 →破壊的な変更 ✕ |
Integerクラス Floatクラス Symbolクラス TrueClassクラス FalseClassクラス など |
試しに
bad_condition = :shoulderに対して以下の実験をしてみました。
bad_condition = :shoulder bad_condition.upcase #=> :SHOULDER bad_condition.upcase! #=> NoMethodError: undefined method `upcase!' for :shoulder:Symbol
イミュータブルであるSymbolクラスのオブジェクトに対して
- 非破壊的メソッド（upcase) → 使えた
- 破壊的メソッド（upcase!）→ エラーになる
という結果になりました。
あとがき
お気づきかと思いますが、今日、めっちゃ肩凝ってます(笑)
以上
