Drafts as my diary.

mysql 5.5 以下でも、online でスキーマ変更とかを可能とするあれだ。

http://www.percona.com/downloads/percona-toolkit/2.2.12/tarball/percona-toolkit-2.2.12.tar.gz

tar ball を持ってきて解凍して、中にある pt-online-schema-change だけ持ってきて使った。

例えばこんな風に使う。

• dry-run

  ./pt-online-schema-change h=localhost,u=username,D=databasename,t=tablename –alter "add index index_name(columnname)" –set-vars innodb_lock_wait_timeout=50 –dry-run

• execute

  ./pt-online-schema-change h=localhost,u=username,D=databasename,t=tablename –alter "add index index_name(columnname)" –set-vars innodb_lock_wait_timeout=50 –execute

• replication している場合には –nocheck-replication-filters などつける。

  ./pt-online-schema-change h=localhost,u=username,D=databasename,t=tablename –alter "add index index_name(columnname)" –set-vars innodb_lock_wait_timeout=50 –nocheck-replication-filters –execute

api 叩いて、そのクエリパラメータとDBの値を突き合わせてどうのこうの、ということをしていて、 あれー、一致するはずがなんかおかしいぞ。ということになっていた。

最近譲り受けてメンテすることになったコードでわからんので、コードを追っていく。

どうやらパラメータに "+" が混ざっていたことで起きていた。 サーバ側で文字列を突き合わせているが、"+" が半角スペース扱いされてしまっている。

なるほど url encode のよくあるアレだ。 とりあえず今すぐに、すぐさま動かすことが命題であったので、String.gsub(" ", "+") で難を逃れた。

Emmet を導入してみた。vim に。 大体今までは slim を好んで使ってきたけれど、 rails と分離してフロントエンドを考える場合に悩むことが多かった。テンプレートエンジンで。

もともと haml だ slim だと使い始めたのは、素の html を書くのが面倒だったからだ。 素の html が簡単に書けるのなら、問題ないはずだ。ちょっと使ってみた感じでは問題無さそう。

rails と分離するときはもう emmet で素の html を書けばいいかなと思っている。

slim の方が読みやすかったりするのかな? とか疑問はあるので 暫く使って様子をみたい。

Garage のコードを読み始めてまず目についたのが

require "rack-accept-default"

miyagawa/rack-accept-default

これはなんだろうと思うと、

まあ README の内容なんだけれど、

Rack::AcceptDefault is a tiny piece of middleware that sets default Accept: header when it isn't present, to work around Rails 3.x issues.

Rails default MIME negotiation (in ActionPack) handles requests without Accept: headers as invalid, and assume it wants the HTML view. This assumption is wrong per RFC 2616 HTTP/1.1 specification.

If no Accept header field is present, then it is assumed that the client accepts all media types Rack::AcceptDefault is a piece of Rack middleware that provides a convenient way to work around this problem, by setting the */* value to the Accept header when it is not present.

RFC2616 に、

If no Accept header field is present, then it is assumed that the client accepts all media types

Accept header が渡されない場合、all media types つまり */* とする。とある。

Rails では */* ではなくて html としている。

コードを見ると、Rails 3.x 限定というわけではなく、現在もそうだ。 該当箇所はこの辺。

rails/rails/actionpack/lib/action_dispatch/http

  def formats
    @env["action_dispatch.request.formats"] ||= begin
      params_readable = begin
                          parameters[:format]
                        rescue ActionController::BadRequest
                          false
                        end
      if params_readable
        Array(Mime[parameters[:format]])
      elsif use_accept_header && valid_accept_header
        accepts
      elsif xhr?
        [Mime::JS]
      else
        [Mime::HTML]
      end
    end
  end

ここにある。たまに失うのでメモしておく。

https://github.com/284km/rspec-minimal

javascript を書いて、closure-compiler で compile して頭に javascript: を付けるのが一番簡単ぽい。

http://closure-compiler.appspot.com/home

身近なところで、よく困っているところを目にする問題なので、ちょっとまとめておく。

まず問題となっているのは、rails4 にしたら画像が表示されない! みたいな事象。

それは、Rails4 からは digest 無しの js, css, image は作成しない仕様となった為。 以下で詳しく説明してくれている。

http://qiita.com/wadako111/items/03bc00d914e62243a511

ここでは以下の対処方法を提示してくれている。

• asset_path関数, image-url関数を使う

• public/assets 以下に画像を直接置く

• public/images 以下に画像を置く

個人的には以下の jnchito さん記事の non-stupid-digest-assets gemを導入する。 で一先ず対応しておくのがよいと思っている。

http://qiita.com/jnchito/items/07f2e3ca29f9881b83d6

issues も相当長くなっている。

https://github.com/rails/sprockets-rails/issues/49

以下のメッセージを最後に lock されているので、今後何らかの変更があるのかもしれない。と思っている。 そういう訳で、自分の場合は alexspeller/non-stupid-digest-assets を使ってとりあえず様子を見ておくことが、一番よいのではないかという考えをしています。

Thank you. I locked this conversation. We already have enough information to think about this issue and in fact we are going to handle it in some way (we already did some improvements on master branch to alleviate the pain). If we think we need more feedback from the community I'll reopen the thread.

ctrl + s で止めて

ctrl + q で再開する

初心者向けの技術書の選び方、 Amazon のランキングで選べばいい? って聞かれた。

うーむ、いいかもしれないけど、だめかもしれない。まあ、駄目だな。

駄目ってことはないかもしれない。その人にとって本を引き当てるかもしれない。 でも僕が駄目とした理由はそこではなくて、

なぜその本なのか。その理由が無くなってしまうから。

乱読ならそれでよいと思う。でもこの場合、技術書だ。知識を得るための選択をするべきだ。 そういう本は、ちゃんと選ぶべきだ。なぜその本を選んだのか。最終的に理由があるはずだ。

その理由を踏まえて読むとより効果的に知識を得られることがあるし、 その理由により、次に読む本。より深くだったり、足りない何かを補う為の別の本だったりするかもしれない。

こういった発展性が無くなってしまうんだ。ランキングだと。

そんなようなことを思った。

P.S.

これははてなブログに書いてもいいかんじの内容かなあとか考えてるけど何の為に使いわけようとしたんだっけとかよくわからないことになってる。

my.cnf どこにあるんだ? という時、以下で確認してみる。

mysql --help | grep my.cnf