引越しに際して買ったものたち

前の家の部屋が手狭だったのと隣が夜になるとうるさくてストレスがマッハだったので先月引越しをした。
引越しってのは怖いもので、すでにデカい金が飛んでるのでもうちょっと出費が増えても問題ないんじゃないかなと麻痺する。

せっかくなので買ったものをあげていく。

山崎実業無双

あったら便利ってのは大体山崎実業が作ってくれている。

ペットボトルを乾かしたり、生ゴミ入れに使ってる。便利。

キッチンツール吊してる。
これを買った後に物件にも供えつけのフックがあることに気付いた 🙃

スポンジとスキレット洗う用のタワシをかけてる。

コートの置き場がないことに気付いてこれを玄関に。

料理するぞ料理するぞ

ここに住む以上魚を捌く必要があるのでいろいろ揃えた。

下村工業 ヴェルダン 出刃庖丁 150mm OVD-15

下村工業 ヴェルダン 出刃庖丁 150mm OVD-15

  • メディア: ホーム&キッチン

PP魚の内臓取り ササラ

PP魚の内臓取り ササラ

  • メディア: ホーム&キッチン

これで魚捌いていくぞ!!

室内干しネット

ダイヤ お風呂で平干しネット 室内干し

ダイヤ お風呂で平干しネット 室内干し

  • 発売日: 2016/11/01
  • メディア: ホーム&キッチン

冬だしニットを洗濯する機会が増えるので。
浴槽の上に2つ並べて使っている。超便利。

有機ELテレビ

部屋にちょうど置くのにいいスペースがあるので気になっていたところ、ヨドバシの店頭でネット最安ぐらいの額で買えたので買ってしまった…
デカいテレビで見るアニメは心が癒されます。もっぱらアマプラとYouTube流してる

ソファ

まだ部屋に来てない

よいコミットメッセージとはどういうものだろう?

tl;dr

なぜ「私たちは」これをしたのか?の理由を書こう


コミットメッセージといえば t_wada さんのツイートがよく引用されている

自分もこの考えに賛同してるので、コミットメッセージには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 に参加した

rhc.connpass.com

やったこと

学び

  • make parse を使うとRuby内部でどういう命令が呼ばれるのかわかる
  • メソッド呼び出しは opt_send_without_block とかで見れるけど、たまに最適化された処理を呼ぶ( Array#lengthとかだと opt_length)
    • 最適化を外して(どうやって外したっけ…?)ベンチマークをかけると目に見えて遅くなる

Baseball Play Studyでキーボードについて話してきた

bpstudy.connpass.com

スライドは入れた画像がいろいろマズいので公開の予定はありません
今回は自作キーボード系から野球の話をしました


まずは Ergodox EZにカープロゴのキーを入れた話

カープのロゴを背景抜いて ここで赤いキーにプリントしたものを使っています
トーク中は3000円ぐらいしたと言ったけど実際はキー $10.00 + 送料$14.25 だったのでもうちょっと安かったみたい


あとはファームウェアでいろいろ

1を打つと「とう(投)」Kで「さんしん(三振)」みたいなやつは、最終的に2JFで「ほ」「じゃ」「ひ」を打つための前振でした
途中で「じゃ」も「ひ」もF始まり(Foul と Fly)だったことに気付いて結局「じゃ」をJに割り当ててました

あとはCのタイプ数で対応する背番号の選手名を出す機能
5の長野久義を「ちょうのまさよし」と微妙に ガルパンおじさん 蝶野正洋が混ざってしまっていました😥

9のMaruPointerException がウケてよかった

ソースコードは↓に置いておきます

github.com

ほじゃひ用

Cを叩いた回数で選手名を出すところ


次回も登板するぞ!

今年の仕訳

前提

やること

  • 普段の出費を自動で記録されるようにクレカもしくは電子マネーを使う
    • 電子マネーの利用履歴は内容の詳細がわからないことが多いので極力クレカ
    • スタバみたいに専用のカードがあると突合が楽でいい
    • 自分のビジネス口座はジャパンネット銀行なのだがここはカードにVISAデビットがあるので、実際はクレカではなくこれを使っている
      • 即時に引き落としがされるので、クレカのように未払金を経由しなくていいので仕訳が楽
  • カバンに常時封筒を入れておいて仕事に関わってそうなレシートは常に入れておく
  • 月末になったら封筒を入れかえる
  • MoneyForward確定申告で1ヶ月分の仕訳をレシートと突合せながら行う
    • レシートが見付からなければその項目の仕訳は保留(年末までに見付かれば計上するし、見つからなければ諦める)
  • 終わったら封筒を封印

レシートを分類するみたいな話を聞いたとがあるけど、1ヶ月単位に纏まってたらそれも必要ないかなーと思い今年はこのやり方で言ってみようと思う。
すでに1月2月分の締めは完了しました。

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許容のカラムは悪い文明!!
粉砕する!!!


初稿時、不等号の向きとかがおかしかったので修正しました…