はてなブックマーク

おはようございます。@chiastoliteです。2021年12月25日の朝です。 このエントリはやんちゃクラブリスナー Advent Calendar 2021、第25日目の記事です。 なんでお前が最終日なの? 大体 @onk のせいです。 onkさんは何日なんですか!!!????https://t.co/RijFdJeofK— Kakutani Shintaro (@kakutani) November 12, 2021 12月18日被っていて取られちゃったんですよねぇ。。 #誕生日アドベントカレンダー— Takafumi ONAKA (@onk) November 12, 2021 これ、最終日は俺が書くやつ？#誕生日アドベントカレンダー— 馬美肉 (@chiastolite) November 12, 2021 ということで、本日は私の誕生日です。祝え。 やんちゃクラブに関してのい

パリパリキューブとは? これ 島産業 家庭用生ごみ減量乾燥機 「パリパリキューブライトアルファ」 トリコロール PCL-33-BWR 発売日: 2018/05/01メディア: ホーム&キッチン これがどういう商品かというのをざっくり説明すると 「生ゴミ用の乾燥機」 それだけである。 言葉にすると単純なのだがこれを導入することで得られた体験がなかなかよかったので紹介する。 背景 コロナ禍になって料理をする機会が増えた。 以前より高い頻度で料理をするようになってくると、いろいろ面倒くさいポイントが見えてくる。 たとえば買い物。 これは幸いマンションにクックパッドマートのステーションが設置されたことによってほぼ解決した。 次に出てきたのが生ゴミの処理だった。 生ゴミ問題 生ゴミは料理をする以上どうやっても出てくるがこの処理がなかなかめんどくさい。 溜めてしまうと臭いやらが出てきてしまうし、かとい

tl;dr なぜ「私たちは」これをしたのか？の理由を書こう コミットメッセージといえば t_wada さんのツイートがよく引用されている コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした— Takuto Wada (@t_wada) September 5, 2017 自分もこの考えに賛同してるので、コミットメッセージにはWhyを書くし書いて欲しいと思う。 では「Whyを書く」とはどういうことだろう？ 「レビューで指摘された内容を反映した」 みたいなコミットメッセージを何度か見て頭をかかえたことがある。 「なぜこのコードを書いた」の理由ではあるので日本語としては間違っていないコミットメッセージではあるのだが、決してこの内容は欲しい情報ではない。 これならレビューで指摘された内容をコピペしてもらったほうがあり

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で指定したほうにある .gi

製品に販売期間設定がある場合に、販売可能なものを探すのに↓のようなクエリが発行されるとする (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制約をつけそれぞれに日付の最小値、最大値を入れることができればこの問題は解決できるが、既存

明日の最終出社にそなえてSlackのアカウントを一時的に停止してもらった。 これをすると自分が設定しているインテグレーションがすべて停止される。 ↑このようにインテグレーションが停止された旨のメッセージがチャンネルに投げられる。 今後も必要なものは他の人に有効化してもらえばいいので、いい感じに棚卸しができる。 ただし、private チャンネルに向いたインテグレーションに関しては他人から触れないので、既存のは削除して作り直しが必要。 これをしないと↓のように削除も編集もできないインテグレーションの残骸ができてしまう… 参考 SlackでPrivavteチャンネルにIntegrationsを設定するときの注意点 - Qiita TwtterでのSlack公式のやりとり Hi! If it was private, you won't be able to completely remove

サービスは運用していくうちに、トレードオフをした結果だったり歴史的経緯だったり外部要因によったりで一見不思議な仕様が生まれたりする。 そういうものを途中から入った人が、頭ごなしに否定するのは幸せとはいえない。 ということでesaに↓みたいなテンプレートを作ってみた。 疑問に思ったことを書いて経緯をしってる人が答えるみたいな運用を期待している。 また回答がない記事を一覧表示できるよう、解答待ちリスト用リストを出すための記事を用意してテンプレートでそこにリンクを張るという工夫をしている。 どの機能/サービス? --- 疑問に思ったこと --- ソースコード --- (場所がわかれば。なおGitHubのリンクを貼るときは y を押してSHA1を指定してもらえると後々ズレが出なくてうれしいです) 理由 --- (可能であればコンフル/Slack/Backlogなどのパーマネントリンクも添えてくださ

最近プルリクを作ったり見るときに考えてること。 前提 プルリクはマージされてシップするまで顧客に対して価値を産んでいない 1秒でも早くマージしてシップすることが何より大切 もちろん質をおろそかにしていいわけではない この2つをレビュアーとレビュイーが共有する必要がある どうやったら早くマージできるか これは単純で プルリクの意図/価値を共有しておく やり取りの回数を減らす 指摘→修正→指摘→修正みたいなのはさける 読むべき量を減らす だけでOK レビュイーとして プルリクの意図を必ず書く 「なぜ」これが必要なのか 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高) 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい 余計な変更は入れない コードスタイルの変更などは読むときのノイズになる 伝わりづらい/自分でもわかりづらいと思

create table tbl_name( `id` int(11) NOT NULL, `hoge` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`), KEY (`hoge`) ) なるほどな なおAUTO_INCREMENTするカラムはKEYになってないといけないので注意が必要 ridgepoleでこれをやろうとしたらできなくてむむむーんとツイートしたら速攻で対応していただけた。神かな? `--create-table-with-index` というオプションを追加したので試してみてください（v7.1.beta4）— 関東圏から出たい (@sgwr_dts) 2017年11月7日 ありがとうございます!!!

このエントリは Classi Advent Calendar 2016 - Qiita の24日目です 前回話した複数DBは? 進捗ダメでした 学校向けのサービスを作るということ 7月からClassiにJOINして「学校」というものに久し振りに触れてみて、いろいろ思うことを書いていこうかと思います。 ピークがわかりやすい これは想像つきやすいと思うのですが、学校という現場においては想定外のイベントによってアクセスが急増するということはそうそうありません。 Classiは校務や授業などの支援だったりご家庭への連絡だったりといろいろ機能がありますが、1日毎でピークタイムがかわるということがないため そのピークを捌けるか? 逆にアイドルタイムに過剰にならないようにということだけを考えていればいいのはかなりうれしい話です。 どのサービスでもピークタイムとアイドルタイムは来まってくるとは思うのですが

このエントリは Classi Advent Calendar 2016 8日目の記事です。 そういえばいまだに転職エントリーを書いていませんが7月に転職をしていましてClassiのファースト社員となりました 💪 複数DB on Rails Classiではセキュリティやら何やらの関係でみんな大好き複数DB on Railsになっています。 R/W Splittingやシャーディングではなく、1つの共通DBとテナント毎のDBがあるマルチテナンシー(?)構成です。 class User < ActiveRecord::Base has_many :entries # (共通DBへの接続情報) end class Entry < ActiveRecord::Base belongs_to :user # (テナントDBへの接続情報) end User.connection # => 共通DBの

去年の前フリ Airbnbで怖いとこは確保した宿が無くなるとか条例で使えなくなるとかだよな— cなんとかe (@chiastolite) 2015年12月15日 RubyKaigiの前泊当日にホストからキャンセルをお願いされる airbnbってホスト都合で当日ドタキャンあるんだ…というのを目の当たりにした— chezou (@chezou) 2016年9月7日 ありえねぇ…— cなんとかe (@chiastolite) 2016年9月7日 ウケる(ウケない— cなんとかe (@chiastolite) 2016年9月7日 モリタハウス、始まる前から盛り上がってる— cなんとかe (@chiastolite) 2016年9月7日 そもそも モリタハウスは概念— cなんとかe (@chiastolite) 2016年9月7日 モリタハウス、もう少しで馬肉食っただけの架空の存在になるところだった

(最後の追記も見てね) 資料はこちら プレゼンアプリが固まって慌ててPDF出力したりして発表してた Itamaeと自分 実はまだItamaeをちゃんとプロダクションで使ったことがない。 最初にItamaeを知ったのは、Chefに疲れた/合わなかった勢がAnsibleに流れてた時期だった気がする。どうもAnsibleが手に合わなかった(YAMLで書きたくなかった)ので、Itamaeのシンプル&プログラマブルなとこに魅力を感じた。 ガリガリ使ってウチらでItamaeを盛り上げてこっ！ってことをやりたかったんだけど、当時は転職直後でインフラを使う機会が無かった。そこでItamaeの利用を促せるツールを作ることを考えた結果が vagrant-itamae だった気がする。 次にやりたいこと まだ Itamae は packer で使えなくてこれをなんとかしたいなと思ってる。 冬休みにGoの勉強も兼

Git Advent Calendar 2015 6日目のエントリーです。 昨日は oh-sky さんの aliasにできないならsub-commandにすれば良い でした みなさんはgitで操作をした後、内部のグラフがどうなっているかを意識していますか? 自分はGitの中身を勉強するまでは漠然としたイメージしかもっておらず、なんとなく操作して失敗するたびに泣きたい気持ちになっていました このエントリでは簡単な例を上げて以前自分が勘違いしていたことと間違いに気付いてからの話をしたいと思います さて問題です E - F(topic) / A - B - C - D(master) (A〜FはSHA-1のハッシュ値、カッコで囲まれているのはブランチ名ということにしてください) たとえば上のようなグラフがあったとき以下のコマンドを実行したらどうなるでしょうか git rebase master