引越しに際して買ったものたち
前の家の部屋が手狭だったのと隣が夜になるとうるさくてストレスがマッハだったので先月引越しをした。
引越しってのは怖いもので、すでにデカい金が飛んでるのでもうちょっと出費が増えても問題ないんじゃないかなと麻痺する。
せっかくなので買ったものをあげていく。
山崎実業無双
あったら便利ってのは大体山崎実業が作ってくれている。
ペットボトルを乾かしたり、生ゴミ入れに使ってる。便利。
山崎実業 マグネットキッチンツールフック プレート ホワイト 2437
- 発売日: 2015/02/06
- メディア: ホーム&キッチン
キッチンツール吊してる。
これを買った後に物件にも供えつけのフックがあることに気付いた 🙃
山崎実業(Yamazaki) 蛇口にかけるスポンジホルダー ダブル ホワイト 約6X16X15.5cm タワー 4390
- 発売日: 2019/02/01
- メディア: ホーム&キッチン
スポンジとスキレット洗う用のタワシをかけてる。
山崎実業 ハンガーラック スリムコートハンガー ライン ホワイト 2767
- メディア: ホーム&キッチン
コートの置き場がないことに気付いてこれを玄関に。
料理するぞ料理するぞ
ここに住む以上魚を捌く必要があるのでいろいろ揃えた。
ゴムまな板アサヒクッキンカット 家庭用 M(380×210×13mm)
- メディア: ホーム&キッチン
これで魚捌いていくぞ!!
室内干しネット
冬だしニットを洗濯する機会が増えるので。
浴槽の上に2つ並べて使っている。超便利。
有機ELテレビ
LG 55V型 4Kチューナー内蔵有機ELテレビ Alexa搭載/ドルビーアトモス対応 2019年モデル OLED55C9PJA
- 発売日: 2019/04/25
- メディア: エレクトロニクス
部屋にちょうど置くのにいいスペースがあるので気になっていたところ、ヨドバシの店頭でネット最安ぐらいの額で買えたので買ってしまった…
デカいテレビで見るアニメは心が癒されます。もっぱらアマプラとYouTube流してる
ソファ
まだ部屋に来てない
よいコミットメッセージとはどういうものだろう?
tl;dr
なぜ「私たちは」これをしたのか?の理由を書こう
コミットメッセージといえば t_wada さんのツイートがよく引用されている
コードには How
— Takuto Wada (@t_wada) September 5, 2017
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
自分もこの考えに賛同してるので、コミットメッセージにはWhyを書くし書いて欲しいと思う。
では「Whyを書く」とはどういうことだろう?
「レビューで指摘された内容を反映した」
みたいなコミットメッセージを何度か見て頭をかかえたことがある。
「なぜこのコードを書いた」の理由ではあるので日本語としては間違っていないコミットメッセージではあるのだが、決してこの内容は欲しい情報ではない。
これならレビューで指摘された内容をコピペしてもらったほうがありがたく思う。
Whyを書いているのに何が食い違っているのだろう?
自分は主語の問題かな?と考えている。
「レビューで指摘された内容を反映した」 の主語は「私は」だと思う。
これだとレビュアーに指摘されたからが十分な理由になってしまう。
個人的にはコミットメッセージの主語は「私たちは」のほうがよいと考えている。
ここでいう「私たち」はチームだったり会社だったりコミッターチームだったり。
さきほどの「レビューで指摘された内容を反映した」の主語を私たちにしてみる。
またそもそもレビューもチーム内での話であるということを踏まえてみると以下のような奇妙な文章になる。
「私たちは私たちにレビューで指摘された内容を反映した」
一方レビュアーの指摘をそのまま書いたのは
「私たちはこういう考え(レビューの指摘事項)なので変更を行った」
という文章になるので前者よりもよっぽどいい内容になると思う。
Rails Upgrade業などで使える git command
git worktree
# git worktree add -b <branch名> <ディレクトリ> origin/master git worktree add -b rails6 app_rails_6 origin/master
チェックアウトしているリポジトリから、任意のブランチを別のディレクトリに切り出せる機能。
Upgrade業では、作業によって元の状態と挙動が変わっていないかを確認しながら続けてる必要があり、masterとupgrade用branchの行き来が頻繁に発生する。
これを git checkout によるブランチ切り替えで行おうとすると、そのたびに作業途中の変更を仮コミットしたりStashしたりする必要があるため非常に手間。
この手間がgit workflowを使うと不要になる(ディレクトリ移動で済むため)
なお worktreeで指定したほうにある .gitファイル( ディレクトリではない ) を見ると想像がつくが、.git/ は元のディレクトリのものを参照している。
このため作業完了時にworktreeを消そうとして、元のディレクトリを消してしまうと悲惨なことになるので気をつけてください。
git branch --contain & git tag --contain
gemを導入するとき、バグ自体は修正されているけど未リリースだったりして下のようにbranchやtag、またはリビジョンを直接指定することがある。
gem 'hogehoge', git: 'https://github.com/ghost/hogehoge', branch: 'patch-1'
このまま時間がたっていた場合、masterで入った修正などが取り込めないため早めにリリースバージョンを参照する用に戻したい。
かといって一気に最新に上げてしまうと、テストが落ちたときどこで落ちたかがわからなくなってしまう。
そのため一度「今まで指定していたコミットを含む最も古いバージョン」を使って一度確認しておきたい。
そんなときGemfile.lockに書かれてるsha1を使って git branch --contain <sha1>
または git tag --contain <sha1>
を使うとそのコミットが含まれるbranch、tagが一覧取得できる。
これを使うと、GitHub参照を外すときの参考になるのでオススメ
Ruby Hack Challenge Holiday #3 に参加した
やったこと
- GitHub - ko1/rubyhackchallenge を一通り
- ドキュメントの重箱隅つつきプルリクを1つ出した
- 題材探しに GitHub - benchmark-driver/ruby-method-benchmarks を動かしながら Ruby 2.6.3 からパフォーマンスが落ちているのを探したりした
学び
Baseball Play Studyでキーボードについて話してきた
スライドは入れた画像がいろいろマズいので公開の予定はありません
今回は自作キーボード系から野球の話をしました
まずは Ergodox EZにカープロゴのキーを入れた話
これはテンション上がる pic.twitter.com/4iXamyaXuN
— 馬美肉 (@chiastolite) 2018年3月14日
カープのロゴを背景抜いて ここで赤いキーにプリントしたものを使っています
トーク中は3000円ぐらいしたと言ったけど実際はキー $10.00 + 送料$14.25 だったのでもうちょっと安かったみたい
あとはファームウェアでいろいろ
1を打つと「とう(投)」Kで「さんしん(三振)」みたいなやつは、最終的に2JFで「ほ」「じゃ」「ひ」を打つための前振でした
途中で「じゃ」も「ひ」もF始まり(Foul と Fly)だったことに気付いて結局「じゃ」をJに割り当ててました
あとはCのタイプ数で対応する背番号の選手名を出す機能
5の長野久義を「ちょうのまさよし」と微妙に ガルパンおじさん 蝶野正洋が混ざってしまっていました😥
9のMaruPointerException がウケてよかった
ソースコードは↓に置いておきます
次回も登板するぞ!
MySQLのgenerated columnを使ってOR検索を潰す
製品に販売期間設定がある場合に、販売可能なものを探すのに↓のようなクエリが発行されるとする
(valid_from と valid_to が null の場合は、期間の設定が特に設定されておらず期限のチェックが不要という意味)
SELECT * FROM products WHERE (valid_from < '2018-12-26' OR valid_from IS NULL) AND (valid_to > '2018-12-26' OR valid_to IS NULL)
このとき valid_from と valid_to の複合インデックスがあっても、or検索があるため上手く使ってもらえない(と思う)
このorを消す方法を考える
valid_from、valid_to に NOT NULL制約をつけそれぞれに日付の最小値、最大値を入れることができればこの問題は解決できるが、既存のテーブルに値を追加していくのはDBでの対応以外にもアプリケーション側での対応も必要になる場合があり、すぐに対応ができないことがある。
そこで今回はgenerated columnを使う方法を試みる。
ALTER TABLE products ADD filled_valid_from datetime AS IFNULL(valid_from, '1000-01-01 00:00:00') ALTER TABLE products ADD filled_valid_to datetime AS IFNULL(valid_to, '9999-12-31 23:59:59')
↑のクエリを投げると、AS
移行の計算結果が filled_hogehoge の中に入ることになる。これによりNULLがない日付型のカラムが利用できることになる。
SELECT * FROM products WHERE filled_valid_from < '2018-12-26' AND filled_valid_to > '2018-12-26'
というわけで↑のように OR 〜 IS NULL
を消すことができた。
あとは↓のようにインデックスを貼ればよい。
ALTER TABLE products ADD INDEX idx_filled_valid_dates(filled_valid_from, filled_valid_to)
(ただこの例だと filled_valid_to
が使われることはない?かもしれない)
やはりnull許容のカラムは悪い文明!!
粉砕する!!!
まったく別件バウアーなんですけど、OR検索を潰すエントリの販売可能なものを探すクエリの不等号とかおかしくないですか??
— Ryuta Kamizono (@kamipo) 2019年1月23日
この方法でNULL排除してもこの不等号の向きを維持してORなくせないと思うんですが…!
初稿時、不等号の向きとかがおかしかったので修正しました…