けんちゃんくんさんのWeb日記
2014/9/28

インターネットが死んで復活した話

土曜日に家に帰ったら急にインターネットが繋らなくなっていて、VDSLのリンクができないっぽいので電話したらマンションの終端装置が壊れてしまっているっぽいかった。

夜だったので工事は日曜になるってことなので、体調も悪いのでほぼ丸一日寝続けていた。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/24

middleman を Ruby2.2.0-preview1 で使う

middleman-livereloadから依存しているeventmachineがmasterじゃないと動かないのでそこだけGemfileを書き換えている。

それ以外は特に問題ないし、ついでに何かのバージョンが上がって、個別の記事に謎のタイトルも出なくなってよかった。

手元はとりあえず 2.2 で生活しているけど今のところ困ることはそんなにないかな。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/21

RubyHiroba 2014 で生活発表しました

RubyHiroba 2014の生活発表会で最近お仕事生活で触っている shopify/active_merchant について発表してきた。

発表の時につかったコードリーディングのメモも Speaker Deck からリンクしたよ。

終わってから@kei_s氏といろいろ話せたのがすごく良かった!

  • ActiveMerchantはやっぱりクレカ前提だからコンビニ決済とかは実運用上つらいところがありそう
  • spree/spree はハマればすごい。
  • 両方ともモデリングはよく出来てるから参考にするべし

設計もそうだし、語彙もすごく勉強になるので、課金システムに携わる人は両方読むといいんじゃないでしょうか。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/19

RubyKaigi 2014 で LT をしました

1番目でめちゃくちゃ緊張したけど、なんとか3つのトピックを紹介できてよかった。

練習しているときは1トピックで5分くらいかかってしまっていて、これはまずいと原稿を整理してなんとかゴールまで辿りつけた感じ。

スライドにあるようなデータの作り方にすると、「それってFixtureでいいんじゃないの?」という意見が出てきてもおかしくないし、当日の午後のセッションでFixtureの話もあったのでねじ込んでみたけどさすがに間に合わなかった。

Fixtureは

  • 早くて
  • yamlやcsvで定義できて
  • validationやcallbackはスキップされる

という特徴があるので、どちらか一方だけを使うというのでなく、適材適所にしましょうという話。

で、見なおしてみるとmoroが数年前に言っていたことばかりだったりしたけど、違う人が同じトピックについて、それぞれの見方で発表するのは価値のある事だと思うのでみんなもっと独自研究の成果を発表するといいと思う。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/14

2014-09-14: 散髪ログ

前回からちょうど2ヶ月。RubyKaigiなので切った。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2021-09-02 15:32:22 +0900
2014/9/12

PCを家に忘れて一回休み

なんか背中が変だなーという違和感はあったんですよ。

どうしようもないので、余ってるPCを借りて日本語を書いたりしていた。

あと、Homebrewは複数アカウントで使えないということがわかったのは収穫であった。

/usr/local以下のファイルがインストールしたユーザのwrite権限しかないのが問題でなんだけど、とりあえず admin グループの人間は書けてもいい気がしたので、https://blog.strug.de/2012/06/my-homebrew-multi-user-setup/ を参考に、独自のグループではなくて admin グループに write 権限をくっつけて必要なツールとかを入れたのであった。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/11

(Railsで)プロフィール更新みたいなやつの注意点

前職と現職で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} 様

こうなってると、updatecurrent_user#name が不正な状態になってしまうとそれがそのまま画面に出てしまうよね。

dup や clone じゃだめなの?

dup は Shallow Copyなので、大丈夫って自身があるならそれでもいいんじゃないですかね。

よほど速度に影響するというわけじゃなければ find のほうが安全だと思っています。

まとめ

フォームで変更するオブジェクトが、フォーム以外の場所でも表示されている場合、フォームで変更するオブジェクトと表示するオブジェクトは分けておかないと意図していない挙動になるから注意しましょう。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/10

みんなでHerokuをcronとして使う

Heroku Button の勉強を兼ねて、とある業務を自動化して公開した。

kenchan/yuru-char-voter

Jenkinsを高度なcronとして使っているという事例はたくさんあるけど、アプリケーションのポータビリティが劇的に向上した2014年後半では、コードを公開してHeroku Buttonをつけることで他の人も簡単に自動化の恩恵を受けることができる。

細かい設定はできないけど、毎時、毎日何かをしたいというくらいであればscheduler addonで十分だし、他のaddonを使えば自分でサーバ管理してcron回すよりは安定して稼働させることができるだろう。

Addonの設定はapp.jsonではできなさそうなのだけど、こうやったらできるよーとかschedulerの設定を画面以外からやる方法を知ってる人いたら教えて下さい。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/9

RubyKaigiのLTに採択されたのでCFLTの内容を公開します

せっかくなので、提出したタイトルや概要を公開しておきますね。

うまく埋め込まれない方はこちら -> RubyKaigi 2014 CFLT - kenchan

日本Ruby会議2011 CFP虎の巻 を眺めながら、頑張って書いたかいがありました。

8月に所属企業が変わったわけですが、前職と現職で2アウトしているようなポイントが結構あって、そういうのをなるべくオープンして行きたいと思って応募したのでした。(前職でも結構議論したし、現職でも議論しているような事柄)

死霊がんばるぞい。

created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
2014/9/1

現在時刻を扱うメソッドはデフォルト引数を使いましょうという話

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
created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
新しい記事へ 古い記事へ