食洗機を買ってよかった

こちらの食洗機を買った。

シロカ 2WAY食器洗い乾燥機 [食洗機/工事不要/除菌率99.9％/分岐水栓対応/液晶表示付き/タイマー搭載/360℃キレイウォッシュ] PDW-5D (ゴールド)

前々から欲しかったが、買ってみてやっぱり食洗機は生活を変えるマストアイテムだと改めて思ったので書く。

買ったこちらのタイプは分岐水栓工事が不要で置けば使えるタイプ。 自分は賃貸なので、管理人に確認が必要だったり、退去時にもとに戻す必要がある分岐水栓工事はやりたくなかったためこのタイプにした。

自分で水を入れる作業が必要だったり、一度に入る食器の量が少なかったりというデメリットもあるが、夫婦2人と赤ちゃん1人なら1日2回回せば足りる感じ。 子供が大きくなってきたら毎回回す必要が出てくるかも。

「洗い物残ってるなー」という重い気分が全く無くなった

洗い物が残ってると、食後リラックスしていても「Todo」として頭に残っていてどこかでリラックスしきれない。 ズルズル行くと最高潮に眠たくなったときに洗い作業をやるハメになったりする。

開発作業でVimを普段使いするためにやったこと

【ssl/tls】ルート証明書がどこにあるのかちょっとわかったけど、まだよくわからんメモ

証明書がどういう仕組で機能を実現しているのかざっくりは理解していた(https(ssl)通信設定の概要 - やる気がストロングZERO)つもりだったが、改めて考えてみたら、ルート証明書がどこにあって、どうやって使われているのかいまいちよくわかってなかったので調べてみた。

結果的に結局まだよくわかってないが、わかったことについてメモ。

Ubuntuでは/etc/ssl/certs/にルート証明書が入っていた

例えばrubygems.orgのサーバー証明書のルート証明書は「GlobalSign Root CA - R3」である。

【Toggl track】と【todoist】と【Anki】で仕事を補助するとなかなか良い

最近仕事で以下ツールを使ってみている。

• Toggl track: タイムトラッキングツール
• todoist: Todoツール
• Anki: 記憶補助ツール

まだ本格的に使いだして間があまりないが、今の所凄く良いように感じているのでそれについて書く。

【テーブル設計】削除フラグを使わず削除テーブルを使うべき

データの削除機能において、何らかの理由でデータは残しておきたい場合には「削除フラグ」が使われがちだが、これは絶対にやめたい。
この場合は「削除テーブル」を用意してそちらにデータを移し、元テーブルからはレコード削除を行うようにするべきだと思っている。
それについて書く。

削除フラグを使うと事故りやすい

シチュエーション：販売終了商品が削除フラグ=1でテーブルに残っている

例えばある商品が販売されていたが、今は販売されていない商品が以下のようなテーブルとレコードで表現されているとする。

id	商品名	価格	削除フラグ
1	ガム	100	1
2	キャンディ	120	0

id: 1のガムは今はもう販売されていないので削除フラグが1(true)になっている。
しかし、商品購入履歴などで必要なのでデータはそのまま残っている。

商品テーブルに削除商品があることを常に意識してないとすぐ事故る

「取り扱い商品一覧データ」を取得する際[WHERE 削除フラグ != 1]の記載を忘れるともう事故になる。
これくらいだったら「そんな間違いをする方が悪い」のかもしれないが「常に意識しないといけない」というのが地味に難易度が高い。

• 「外部の業者とのやりとりで必要なので商品データ一式をcsvでちょうだい」とかパッと言われてクエリを書く時
• 新機能実装中、ユーザー毎の販売商品数が必要なので商品テーブルをjoinしようとした時
• 新しくアサインされた新人が商品テーブルを使ったなんらかの集計値を算出する時

【Go】Gorpで[where in]をいい感じに書く方法

Gorpを使っていて以下のようなqueryを実行したい時がある。

select * from table where id in (1, 2, 4, 8);

"1,2,4,8"は動的に変えたいのでプレースホルダーにしたい。

select * from table where id in ($1, $2, $3, $4);

今回指定したidは4つだったけど、いつもそうとは限らないので渡す数も動的にしたい。

select * from table where id in ($1);

このqueryで以下のように実行してみるとエラーになる。

query := "select * from table where id in ($1);"
dbmap := &gorp.DbMap{
    Db:              db, // コネクション
    Dialect:         gorp.PostgresDialect{},
}
_, err := dbmap.Select(mapper, query, []int{1,2,4,8})

// エラーが出る
// sql: converting argument $1 type: unsupported type []int, a slice of int

方法：ExpandSliceArgsオプションを有効化してmap[string]interface{}型で値を渡す

以下のように書くと意図通りの挙動になる。

query := "select * from table where id in (:ids);"
dbmap := &gorp.DbMap{
    Db:              db,
    Dialect:         gorp.PostgresDialect{},
    ExpandSliceArgs: true, //スライス引数展開オプションを有効化する 

}
_, err := dbmap.Select(mapper, query, map[string]interface{}{"ids": []int{1,2,4,8}})

内部的には、query文字列を

select * from table where id in (:ids0, :ids1, :ids2, :ids3)

と展開して処理してくれている。

gorpのコードを読んでいてこの機能を知った。
この機能を知る前は、where in () の中を予めwhere in ($1, $2, $3, $4) となるように文字列をいじり、argsも[]interface{}型に変換してからdbMap.Select()に渡していたがめんどくさかった。。

システムドキュメントの管理方法のベストプラクティスを考える

システムドキュメントの管理って地味に難しい。
そもそもドキュメントが無かったり、どこにあるのか分からなかったり、あっても情報が古かったり、複数の場所や形式に分散していたりしていて、いざという時に全然使えないような状態になってしまってたりする。
そこで、これらの問題が起こりにくいドキュメント管理方法を考えてみた。