インターネットが死んで復活した話
土曜日に家に帰ったら急にインターネットが繋らなくなっていて、VDSLのリンクができないっぽいので電話したらマンションの終端装置が壊れてしまっているっぽいかった。
夜だったので工事は日曜になるってことなので、体調も悪いのでほぼ丸一日寝続けていた。
土曜日に家に帰ったら急にインターネットが繋らなくなっていて、VDSLのリンクができないっぽいので電話したらマンションの終端装置が壊れてしまっているっぽいかった。
夜だったので工事は日曜になるってことなので、体調も悪いのでほぼ丸一日寝続けていた。
middleman-livereloadから依存しているeventmachineがmasterじゃないと動かないのでそこだけGemfileを書き換えている。
それ以外は特に問題ないし、ついでに何かのバージョンが上がって、個別の記事に謎のタイトルも出なくなってよかった。
手元はとりあえず 2.2 で生活しているけど今のところ困ることはそんなにないかな。
RubyHiroba 2014の生活発表会で最近お仕事生活で触っている shopify/active_merchant について発表してきた。
発表の時につかったコードリーディングのメモも Speaker Deck からリンクしたよ。
終わってから@kei_s氏といろいろ話せたのがすごく良かった!
設計もそうだし、語彙もすごく勉強になるので、課金システムに携わる人は両方読むといいんじゃないでしょうか。
1番目でめちゃくちゃ緊張したけど、なんとか3つのトピックを紹介できてよかった。
練習しているときは1トピックで5分くらいかかってしまっていて、これはまずいと原稿を整理してなんとかゴールまで辿りつけた感じ。
スライドにあるようなデータの作り方にすると、「それってFixtureでいいんじゃないの?」という意見が出てきてもおかしくないし、当日の午後のセッションでFixtureの話もあったのでねじ込んでみたけどさすがに間に合わなかった。
Fixtureは
という特徴があるので、どちらか一方だけを使うというのでなく、適材適所にしましょうという話。
で、見なおしてみるとmoroが数年前に言っていたことばかりだったりしたけど、違う人が同じトピックについて、それぞれの見方で発表するのは価値のある事だと思うのでみんなもっと独自研究の成果を発表するといいと思う。
前回からちょうど2ヶ月。RubyKaigiなので切った。
なんか背中が変だなーという違和感はあったんですよ。
どうしようもないので、余ってるPCを借りて日本語を書いたりしていた。
あと、Homebrewは複数アカウントで使えないということがわかったのは収穫であった。
/usr/local以下のファイルがインストールしたユーザのwrite権限しかないのが問題でなんだけど、とりあえず admin グループの人間は書けてもいい気がしたので、https://blog.strug.de/2012/06/my-homebrew-multi-user-setup/ を参考に、独自のグループではなくて admin グループに write 権限をくっつけて必要なツールとかを入れたのであった。
前職と現職で2アウト案件。
Railsに限らないけど、ログインユーザの情報を変更するときは current_user
みたいな変数を変更するんじゃなくて、DBを引き直して更新しましょうって話。
ダメな例
class ProfileController
def update
if current_user.update(profile_params)
redirect_to :root
else
render :edit
end
end
end
良い例
class ProfileController
def update
@user = User.find(current_user)
if @user.update(profile_params)
redirect_to :root
else
render :edit
end
end
end
バリデーションエラーが起きた時に current_user
が不正な状態になってしまうから。
こういう書き方をしてるってことは、だいたい _form.html.haml
はこういう感じになっているはず。
- form_for current_user do |f|
= f.label :name
= f.text :name
...
これだけ見ると大丈夫そうだけど、問題は ヘッダなどに current_user の情報を表示している ようなケース。
%header
.name= #{current_user.name} 様
こうなってると、update
で current_user#name
が不正な状態になってしまうとそれがそのまま画面に出てしまうよね。
dup は Shallow Copyなので、大丈夫って自身があるならそれでもいいんじゃないですかね。
よほど速度に影響するというわけじゃなければ find
のほうが安全だと思っています。
フォームで変更するオブジェクトが、フォーム以外の場所でも表示されている場合、フォームで変更するオブジェクトと表示するオブジェクトは分けておかないと意図していない挙動になるから注意しましょう。
Heroku Button の勉強を兼ねて、とある業務を自動化して公開した。
Jenkinsを高度なcronとして使っているという事例はたくさんあるけど、アプリケーションのポータビリティが劇的に向上した2014年後半では、コードを公開してHeroku Buttonをつけることで他の人も簡単に自動化の恩恵を受けることができる。
細かい設定はできないけど、毎時、毎日何かをしたいというくらいであればscheduler addonで十分だし、他のaddonを使えば自分でサーバ管理してcron回すよりは安定して稼働させることができるだろう。
Addonの設定はapp.jsonではできなさそうなのだけど、こうやったらできるよーとかschedulerの設定を画面以外からやる方法を知ってる人いたら教えて下さい。
せっかくなので、提出したタイトルや概要を公開しておきますね。
うまく埋め込まれない方はこちら -> RubyKaigi 2014 CFLT - kenchan
日本Ruby会議2011 CFP虎の巻 を眺めながら、頑張って書いたかいがありました。
8月に所属企業が変わったわけですが、前職と現職で2アウトしているようなポイントが結構あって、そういうのをなるべくオープンして行きたいと思って応募したのでした。(前職でも結構議論したし、現職でも議論しているような事柄)
死霊がんばるぞい。
GMOペパボ1ヶ月記念に、おそらく一番最初にコードレビューで伝えたことを書いておこうと思う。
現在時刻を扱うようなメソッドには、デフォルト引数で Time.now
を使って、外からも時刻を渡せるようにしましょう。
2014年の今となっては、テストのために時刻の扱いを気をつけましょうという必要もない気がするけど、CodeIQの和田さんの解説にもあるように、システム全体の時刻をスタブしたりするのは多少のリスクが伴うと思う。
問題は 複数の現在時刻を扱うロジックを連続で実行すると現在時刻が変わってしまう ということである。
1つのコード例は以下の通り。
class Article < ActiveRecord::Base
scope :recents, -> { where('created_at > ?', 1.week.ago) }
end
class HogeController
def summary
@articles = Article.recents.count
@comments = Comment.recents.count
end
end
大体の場合は問題無いだろうけど、例えば日またぎの場合や、ビューに「集計日時」みたいなのがあったことを想像してみてほしい。
別のケースとしてはこんなものもある。
class Article
def recent?
created_at > 1.week.ago
end
end
%ul
- articles.each do |article|
%li= "#{article.title} #{article.recent?}"
これは、回しているうちに同じ結果を期待する複数のオブジェクト間で結果が変わってしまう可能性がある。
「そうなったときにリファクタリングすればいい」というのはそうなんだけど、大抵の場合はこういう使われ方をするので最初からデフォルト引数を使うようにしておいたほうがいいんじゃないかというのが実感としてある。
メソッド名はもっとよいものがある気がするけど、私がざっと書くなら最初からこんな感じ。
class Article < ActiveRecord::Base
scope :recents, ->(now = Time.now) { where('created_at > ?', 1.week.ago(now)) }
def recent?(now = Time.now)
created_at > 1.week.ago(now)
end
end