一人暮らしにこそドラム式洗濯機が必要なのでは

(正確にいうとドラム式というよりは乾燥機付き洗濯機)

先日↓のドラム式洗濯機を買った。
台数限定販売だったらしく最終的には125,000円と価格コムの過去最安値より安く買えたのは運がよかった。

日立 ドラム式洗濯乾燥機 ビッグドラム 左開き 11kg ホワイト BD-SV110AL W

日立 ドラム式洗濯乾燥機 ビッグドラム 左開き 11kg ホワイト BD-SV110AL W

最初は一人暮らしにドラム式はオーバースペックでは?と思っていたのだが、一人暮らしこそ買ったほうがいいのでは?と思えたのでここにメモとして書いておく。

時間が節約できる

これはどこでも言われていることだと思うけど、洗濯を開始して出勤して帰ってきたら洗濯物が乾いているのはとても楽でいい。
乾燥まで一通りやってくれるということは、「干す」という工程の時間だけではなく洗濯&脱水が終わるまでの待ち時間もなくなるということなので時間の余裕が大分増えた感じがある。

スペース&物が節約できる

何気に大きいのがこれ。

さきほどのように洗濯→乾燥までに必要な時間が減ったので、洗濯の頻度を上げられるようになった。
これにより、タオルなどを必要以上にストックしておく必要がなくなった。

以前はある程度まとめて洗う習慣になっていたので、途中で雨に降られる可能性などを考えると数日分の余裕を持っていないといけなったが、今は1日2日分持っておいて使用後すぐ洗えば困ることがなくなった。
その結果、買うべき物の量も減ったし収納スペースも必要以上に使う必要がなくなった。

結論

時間&物&スペースの分を考えたら逆に安いので、みんなドラム式をぜひ買ってみよう

1秒でも早くプルリクをマージしたい

最近プルリクを作ったり見るときに考えてること。

前提

  • プルリクはマージされてシップするまで顧客に対して価値を産んでいない
  • 1秒でも早くマージしてシップすることが何より大切
    • もちろん質をおろそかにしていいわけではない

この2つをレビュアーとレビュイーが共有する必要がある

どうやったら早くマージできるか

これは単純で

  • プルリクの意図/価値を共有しておく
  • やり取りの回数を減らす
    • 指摘→修正→指摘→修正みたいなのはさける
  • 読むべき量を減らす

だけでOK

レビュイーとして

  • プルリクの意図を必ず書く
    • 「なぜ」これが必要なのか
    • 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高)
      • 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい
  • 余計な変更は入れない
    • コードスタイルの変更などは読むときのノイズになる
  • 伝わりづらい/自分でもわかりづらいと思うときはコードコメント or 行コメントを残しておく
  • 確認しておきたい/見て欲しい箇所があるなら最初から書いておく
  • プルリクのサイズを小さく
    • 大きくなるなら実装途中とかで段階的にプルリクを見てもらう
      • 設計レベルの差し戻しがあったときにも有効
  • コードの差分では伝わりづらいものに気をつける
    • クエリ改善なら変更前後で発行されるSQLだったりEXPLAINの変化だったり
    • 画面ならスクショだったり

レビュアーとして

  • 細部にこだわりすぎない
    • 気になるとこがあっても好みの問題だったり後で直せるレベルというならコメントだけ残しておくけど別に直さなくていいですとか書く
      • コメントは後から見て気になったとこを思い出すためにも大事
  • どうやったらマージできるかを書く
    • 指摘するだけじゃなくて、どうなったらうれしいかを書く
    • 質問とか書いたとき、自分の理解を書いて合ってればマージしていいですと書いておく

後は

  • 人が指摘しなくていいものは機械にやってもらいたい

元々は

kamipoさんと飲み会で話したときのに強く影響されています

CircleCI 2.0 をつかったら Rubyで invalid multibyte char (US-ASCII) が起きた

日本語文字列を読んだ瞬間↑のエラーで死んでつらい気持ちになった

使っていたのは circleci/ruby:2.3.4 のイメージ
(2.4.2じゃないんですか!?という突っ込みお待ちしています)

結論としてはデフォルトのままだと LANGのja_JP.UTF-8 が使えない状態だったから

version: 2

jobs:
  build:
    docker:
      - image: circleci/ruby:2.3.4
        environment:
          - LOCALE=ja
          - LANG=ja_JP.UTF-8

    steps:
      - checkout
      - run: sudo apt update
      - run: sudo apt install task-japanese
      - run: echo 'ja_JP.UTF-8 UTF-8' | sudo tee -a  /etc/locale.gen
      - run: sudo locale-gen
      - run: sudo update-locale LANG=ja_JP.UTF-8

こんな風にしたらうまく行った
CircleCIのイメージってUbuntuじゃなくてdebianベースなんですね

MySQLは主キー以外でもauto_incrementができる 

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でこれをやろうとしたらできなくてむむむーんとツイートしたら速攻で対応していただけた。神かな?

ありがとうございます!!!

ISUCON7で人権を得ることに失敗した

isucon.net

同僚が会社のSlackで出ませんか?っと言っていたので手をあげる形で参戦してきて、結局今年も人権を得ることは叶わなかった。

最終結果は↓こんな感じ

f:id:Chiastolite:20171023142152p:plain

主にやったこと

  • 画像周りの処理改善
  • /fetch のN+1解消
  • 入れておいたよさそうなインデックスを適当に追加
  • channel_listの取得周りをmemcachedでキャッシュ化

画像周り

今回のキモだったアイコン画像の配信周り

とりあえず画像をDBから配信するのつらすぎってことで画像へ吐き出しをしてnginxで配信できるようにした。 ためしに1台で動かしてスコアが結構出てわいわいしてたら、複数台をベンチ対象にするとあたりまえだけど機能しないことに気付いてわちゃわちゃしてた。

いろいろ考えたけど「この際画像だけは1台から配信すればいいんじゃね?」と考えて、メンバーにnginxの設定を丸投げした。無茶ぶりに答えてくれた同僚には感謝の念を禁じえない…

channel_listのキャッシュ化

チャンネル取得が内部で呼ばれることが多く値はユーザーに依存しない言われたので、DBサーバにmemcachedを入れて適当にキャッシュさせることにした。 これだけでスコアが2万ぐらい上がった記憶がある

反省

結局最後まで Cache-control: public に気付くことはなかったので勝ち目はなかった。 事前の打ち合わせで最近Web界隈で話題になったことを上げていってたりはしたんだけどCDNの話が抜けおちてた…

また計測がおざなりになっていてアプリコードから「ここはさすがに遅いだろうなー」っていうところを直すような対応をしてしまっていた。 上位チームは計測をしっかりしていて戦略的だったので、ここは次回の参考としたい。

最後に

運営のみなさん、2日間の開催と準備おつかれさまでした & ありがとうございました。 ベンチマークツールがすごい快適でした!

チームメンバーの@jacksmam0、@hachi-eiji にも感謝感謝です😇