一つ前の、droneでビルドできない問題は、.drone.ymlのscriptにcp -r ./ $GOPATH/src/github.com/wtnb75/xxxx/ みたいに書いておけばよいことを発明した！ 手間かけさせやがって。

Go(golang)はかなりいろいろなことがよく考えられた良い言語だが、大きな欠陥がある。その欠陥はやはりimport。gitやmercurial等のリモートリポジトリを指定できてそれはそれで大層便利ではあるのだが、タグやブランチ、バージョン等を指定できない(常にmasterのHEADが使われる)ことがしばしば問題となる。

このimport問題の中でもとりわけ大きなものが、local importの問題だ。

リポジトリ上で開発していて、同じリポジトリのサブディレクトリを対象にimportしたいとする。

import "./subdir"

通常はこれで良いのだが、$GOPATH/src以下もgo getでcloneしてくるリポジトリになっていて、ここのソースに対して作業をしていると、相対パスによるimportがエラーになる。

can't load package: /path/to/go/src/github.com/wtnb75/xxxxx/yyyy.go:16:2: local import "./subdir" in non-local package

つまり、$GOPATHにのっとって開発する(実際golangではそれが推奨されている)場合は、こう書かなければならない。

import "github.com/wtnb75/xxxxx/subdir"

それがgithub.com/wtnb75/xxxxxからimportする場合でもそうなのだ。これは時折深刻な問題を引き起こす。xxxxx/subdir以下の関数の引数を変更し、呼び出し元のxxxxxの呼び出し方も追随して変更することを考える。github flowではこのような場合ブランチを切ってcommit, pushし、作業が終了して動くようになったらPull Request(PR)を出し、レビューを受けてマージしてもらう。自分がメンバーに入っていない赤の他人のプロジェクトであればpush先を自分のテンポラリのリポジトリにしてPRを出すし、メンバーに入っていれば元のリポジトリのブランチで作業するわけだ。

このときdroneやtravis(jenkinsも)といったツールを使ってビルド/テストしたり、自分でもローカルでcloneしてビルドするとか、ブランチを切ってテストするといったことをする。$GOPATH以下にpullしてきてテストする場合は良いのだが、別のところにcloneしてしまった場合。このときimport文が元のままだと、この、、、

import "github.com/wtnb75/xxxxx/subdir"

これはmasterのHEADなわけだから、subdir以下のAPIは変更される前であって、呼び出し元はcloneされた新しいものだ。結果として起きるのはビルドの失敗。テストができない。github flowにおいてはmasterは常にデプロイ可能な状態である、という原則がある。そこで質問だが、ビルドもできないものを好んでmasterにマージしたい人はいるだろうか？

だから、私としてはimportは、それが$GOPATH/src以下であっても相対パスで指定できて欲しいと思う。実際go getで取ってきたディレクトリそのままのところでgitで差分を見ながら作業するってのがそれなりに快適なので、それを邪魔するような機能はつけないで欲しいと思う。local import in non-local packageのエラー…それをエラーにする意義はないんじゃないかな。

おそらく現状だとテスト側としては正しいのはgo getで$GOPATH/src以下に持ってきて、git checkoutでブランチを手動で切り替えてテストを続ける、という一手間だろう。go getやgo buildではcloneが起きるときはmasterだけどあと修正されたかどうかは気にしないので、これでうまくいく。

ただ面倒っちゃ面倒だよね。

$GOPATH/src以下でlocal importができるようになれば解決する。

コメント画面の「スパムをすべて削除」する操作が全く戻ってこない。しびれを切らしてリロードするとちょっとは消えてるけど大部分が残ったまま。

このサイトにはほとんどコメントは来ないのだが、普通の設定(akismetで自動判定されたspamが1ヶ月で自動消去)でも常時数千件のspamが溜まっている。それでたまに全件削除しようとボタンを押してみるが…スピードが遅すぎる。何をやっているのか？

MySQLのDELETEが遅いのかも、と思って試しに以下のSQLを実行してみたら、瞬時に終わった。綺麗さっぱり。まあすぐに10件を越えてくるのだが。

DELETE FROM wp_comments WHERE comment_approved='spam'

WordPressは出しているSQL文がものすごく下品なものになっているに違いないな。どうせPHPで1件1件チマチマ消しているんだろう。自動削除というのもたぶんメチャクチャなSQLを発行していて無駄に重くなっていた可能性もあるな。

SQLではカウンタのincrement/decrementは１つの文で済ますことになっている。

UPDATE table SET counter = counter + 1 WHERE ...

ActiveRecordのモデルにはincrementやdecrementの定義がある。そうか便利だなぁ…？？

1.9.3-p545 :021 > Tbl.take.increment!(:counter, 2)
D, [2014-09-04T00:36:32.902849 #73566] DEBUG -- :   Tbl Load (0.1ms)  SELECT "tbls".* FROM "tbls" LIMIT 1
D, [2014-09-04T00:36:32.903201 #73566] DEBUG -- :    (0.0ms)  begin transaction
D, [2014-09-04T00:36:32.904809 #73566] DEBUG -- :   SQL (0.4ms)  UPDATE "tbls" SET "counter" = ?, "updated_at" = ? WHERE "tbls"."id" = 1  [["counter", 10], ["updated_at", 2014-09-03 15:36:32 UTC]]
D, [2014-09-04T00:36:32.914149 #73566] DEBUG -- :    (9.1ms)  commit transaction
 => true

SELECTで読んで、Rubyが足し算して、UPDATEで足した結果を書き出す…こんなのってないぞ。それをORマッパーがincrementと名乗るか普通？

正解は、モデルのクラスメソッドのupdate_countersを使う。これは複数のカウンタの操作が可能。第1引数のオブジェクトIDも複数書けるし、第2引数以降のカラム名も複数書ける。オブジェクトから呼べないのが使いにくいのを除けば、普通のSQLが発行される。まあ↓の例ではIDを求めるのにSELECTは発行されるが、UPDATE自体は普通にDB側で加算されてくれる。

1.9.3-p545 :022 > Tbl.update_counters(Tbl.take.id, :counter=>1)
D, [2014-09-04T00:37:01.497430 #73566] DEBUG -- :   Tbl Load (0.2ms)  SELECT "tbls".* FROM "tbls" LIMIT 1
D, [2014-09-04T00:37:01.507024 #73566] DEBUG -- :   SQL (9.0ms)  UPDATE "tbls" SET "counter" = COALESCE("counter", 0) + 1 WHERE "tbls"."id" = 1
 => 1
1.9.3-p545 :023 > Tbl.update_counters(Tbl.take.id, :counter=>1, :counter2=>2)
D, [2014-09-04T00:37:06.088688 #73566] DEBUG -- :   Tbl Load (0.2ms)  SELECT "tbls".* FROM "tbls" LIMIT 1
D, [2014-09-04T00:37:06.098522 #73566] DEBUG -- :   SQL (9.4ms)  UPDATE "tbls" SET "counter" = COALESCE("counter", 0) + 1, "counter2" = COALESCE("counter2", 0) + 2 WHERE "tbls"."id" = 1
 => 1