YAMLファイルに別のYAMLファイルの値を参照、設定したい
こういうことがしたかったのですが、
# a.yml id: 1 type: foo description: baz # b.yml id: 2 type: bar description: (ここで a.yml の description の値を参照したい)
こんな風にしました。
YAML.add_domain_type(nil, "include") do |type, val| YAML.load_file("path/to/a.yml")[val] end # b.yml id: 2 type: bar description: !include "description"
最初は b.yml.erb みたいにすればまあ出来るかなと、こんな感じのことを考えましたが、後で知った上の方法に変更したのでした。
# b.yml.erb id: 2 type: bar description: <%= YAML.load_file(path)["description"] %>
2016/08/05 追記
深い階層の場合にも対応しようと思い、こうしました。
# a.yml id: 1 type: foo description: baz too: deep: key: !include "深い階層にも対応" # b.yml id: 2 type: bar description: (ここで a.yml の description の値を参照したい) too: deep: key: !include "too deep key" # 今回は space 区切りを想定した。 うっかり space が多く含まれてしまった場合にも対応している。 key: !include " too deep key " # YAML YAML.add_domain_type(nil, "include") do |type, val| y = YAML.load_file("path/to/a.yml")["some_key"] val.to_s.strip.split(/\s+/).each do |key| y = y[key] unless y.nil? end y end # ruby 2.3 の場合は Hash#dig でこう書ける YAML.add_domain_type(nil, "include") do |type, val| y = YAML.load_file("path/to/a.yml")["some_key"] y.dig(*(val.to_s.strip.split(/\s+/))) end
css 新旧 clearfix の書き方に関するメモ
最近は css も色々書いている。というか、渋々色々やっているという面があるのだけど、それは置いておいて。
昔からある css のメンテなどをすることになると、歴史上の色々な書き方に遭遇することもある。その中で clearfix についてメモしておく。まあ知ってる人達からしたらあたり前なことなんだと思う。
いつも以下の新しい方で書いていたけれど、古い方と出くわして、これどう違うの?という疑問があった。
古い方の :before は IE6/7 の為らしく、自分の場合もう切り捨てているのでいらないということになる。
display: table / block については何やら挙動が違う。自分は block でよい。
古い方
.clearfix { &:before { content: ""; display: table; } &:after { clear: both; content: ""; display: table; } }
新しい方
.clearfix::after { content: ''; display: block; clear: both; }
ちなみに、前にも調べたことがあるような形跡を見つけた。確かにそんな気はするし、どうせまた忘れるのかもしれない。
rails ActiveSupport 便利な String の活用形のメモ
[8] pry(main)> (:user_follows).to_s.singularize => "user_follow" [9] pry(main)> (:user_follows).to_s.pluralize => "user_follows" [10] pry(main)> (:user_follows).to_s.camelize => "UserFollows" [11] pry(main)> (:user_follows).to_s.classify => "UserFollow" [12] pry(main)> "backoffice/session".camelize => "Backoffice::Session" [13] pry(main)> :user_follows.to_s.camelize(:lower) => "userFollows" [14] pry(main)> :user_follows.to_s.camelize(:upper) => "UserFollows" [15] pry(main)> "AdminUser".underscore => "admin_user" [16] pry(main)> "Backoffice::Session".underscore => "backoffice/session" [17] pry(main)> "alice in wonderland".titleize => "Alice In Wonderland" [18] pry(main)> "fermat's enigma".titleize => "Fermat's Enigma" [19] pry(main)> "fermat's enigma".titlecase => "Fermat's Enigma" [20] pry(main)> "contact_data".dasherize => "contact-data" [21] pry(main)> "John Smith".parameterize => "john-smith" [22] pry(main)> "Kurt Gödel".parameterize => "kurt-godel" [23] pry(main)> "InvoiceLine".tableize => "invoice_lines" [24] pry(main)> "invoice_lines".classify => "InvoiceLine" [25] pry(main)> "User".foreign_key => "user_id" [26] pry(main)> "User".foreign_key(false) # => "userid" => "userid"
rails gravatar-ultimate を使う
email, password を入力してもらってユーザ登録できるやつで、 アイコンなど画像ファイルを自分のところで取り扱いたくない。 というケースで gravatar に頼る流れがあります。
https://github.com/sinisterchipmunk/gravatar
実装を見ると、サイズが指定できたり https を使ったり rating の指定ができたりするようで、 とりあえずこんな風にしました。
# Gemfile gem "gravatar-ultimate" # helper module ApplicationHelper def gravatar_for(user, size = 80, secure = true) Gravatar.new(user.email).image_url(size: size, secure: secure) end end # view <%= image_tag(gravatar_for(current_user), alt: current_user.email, class:"gravatar") %>
rails limitではなくtakeの使いどころ
limit 使えばいいし、take 使いどころ無いのでは?と思っていました。
先頭 1 件だけほしい時、Model.first すると、order by id ASC LIMIT 1 となります。
Model.limit(1) の場合、order by id しません。
Model.take も同様です。こういう時、take を使う気になりましたね。
[18] pry(main)> Article.first Article Load (0.8ms) SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT 1 [19] pry(main)> Article.limit(1) Article Load (0.7ms) SELECT "articles".* FROM "articles" LIMIT 1 [20] pry(main)> Article.take Article Load (0.2ms) SELECT "articles".* FROM "articles" LIMIT 1
input要素のpattern属性に関するメモ
pattern 属性。自分の場合頻繁に使うわけではないので、使うか。と思った時にもう忘れていて結局毎回調べたりして作業が止まるのが煩わしい。 どうせ次も調べるのだろうけど、この辺りを見れば手間も軽減する。ありがたい。