何故やるのか

と聞かれた時、聞かれているのはそれの潜在的なニーズとか客観的なナニカじゃなくて、 やると言っている相手の中に何があるんだっていう気持ちの話をしているんだと思う。

何が衝動で何故掻き立てるのか、それを聞いてる。

何故やるのか。

掻き立てられるような衝動がなければ情熱には成り得ないし。 情熱なき行動はそもそも続かないしなにより誰にも響かない。

何故やるのか。

一番最初に出てくる言葉はなにか。

FactoryGirlで用意されたデータに望むこと

FactoryGirl というテストデータを用意するためのgemがあります。

読んだ人に、どんなデータが入ることを想定しているか、それが伝わるデータを用意していきたいですね。'MyString'じゃなくて、例えばどんなデータなのかを教えて欲しいのです。

伝わりづらい例

FactoryGirl.define do
  factory :post do
    title  "MyString"
    content "MyString"
  end
end

具体的な例

FactoryGirl.define do
  factory :post do
    title  "pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション"
    content "pplogの過去のポエムを複数単語で絞込できるようになりました。"
  end
end

FactoryGirl.define do
  factory :user do
    name 'Koshikawa Naoto' 
    twitter '@ppworks' # あー@付きなのだな、というのが伝わる
  end
end

postの例は、具体的過ぎてかえって分かりづらい可能性があります。

こんなときは、Fakerというgemを使ってダミーデーターに意味を持たせるのもひとつの手です。

FactoryGirl.define do
  factory :post do
    title  { Faker::Name.title } # blockで遅延評価することで毎回ランダムとなる
    content { Faker::Lorem.paragraph }
  end
end

実際このデータを使うと、例えば以下の様なデータが得られます。

post.title # "Direct Marketing Coordinator"
post.content # "Quia reprehenderit autem libero neque doloribus. Aut laboriosam aliquid praesentium quas facilis est. Id quasi quae eveniet reiciendis eum. Omnis corporis qui. Quia et quos soluta vitae ut recusandae."

具体的なデータと、Fakerを使うようなデータを上手く使い分けていきたいです。

rails3のactiveresource-responseを使っている環境でActiveResourceの結合テストを書く

訳あってActiveResourceのrails3系のテストを書きたいときの話。

activeresource-responseをrails3系で使うときには、v0.5.3を使うことになるんですが、Rails.env.test?がtrueのときに、ActiveResoruceをHttpMock化するというアグレッシブな仕様が入っているために、test環境でActiveResourceの結合テストが書けないんですね。

v1.0.2では解消されています。

ただrails3系でこの問題を回避したかったので、fork版を作りました。

gem 'activeresource-response`, github: 'ppworks/activeresource', rev: 'v.0.5.4'

てな感じで。

ただそれだけの超ニッチな共有でした。

OSSに貢献する気持ちを育てよう

会社のブログに「database_rewinderにpull requestを投げた結果」という記事を書きました。

rails の良い所の一つに、豊富なgemによるエコシステムが優れているという点があります。

gemの多くはOSSとしてgithubにそのソースが公開されています。githubにはPull Requestがあります。Pull Request、いい響きですね。世界の名だたるエンジニアの作ったソースコードにPull Requestが送れるだなんて、なんて感動的なのでしょう。

railsを使う企業であれば、そのエコシステムに入る覚悟が必要です。OSSへの貢献が自然とできるような環境で仕事出来る事ということは、railsを使う覚悟のある会社を見定める際の一つの基準になるかも知れません。

OSSに貢献する気持ちとは何でしょう、エコシステムの一員として当事者意識を持って関わるときの喜びを味わいたいのでしょうか。サービス開発とエコシステムへの貢献を両立できるような環境で働くことでその答えを探して行きたいです。

自分が困っていることは他の誰かも困っているかも知れない。そのときPull Requestを出したり、qiitaに投稿するのかもしれません。そのような行動がエンジニアのエコシステムをより良くしていくと思っております。

どうやってそんな時間を作るんだ？という方は

• togglで、これからやることを明確にする
• push通知を切り、情報は自分のタイミングでpullしよう - pblog

あたりで作業の効率化をイロイロ改善してみるのも良いかもしれません。

あわせて読みたい

• pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション
• コードレビューをし合える文化がチームを強くする
• コードレビューをしよう

togglで、これからやることを明確にする

仕事のスピードを早めるためには、シンプルな仕事に分けてタスクを瞬殺する に限ります。

1秒もムダにしない人の 超シンプル仕事術 (アスカビジネス)

そのためには、これからやることがシンプルで 明確である ことです。

作業開始の宣言

これからやることを明確にするためにも作業開始時に 何をやるか 宣言することが大切です。

• これからやることの範囲が決まる
• 横道にそれない
• 宣言したことをやり切ることで達成感が出る

宣言することでこのような効果が得られると思います。

togglは作業時間のトラッキングツールですが、

• 作業開始の宣言
• 経過時間の確認

だけに使っています。つまり、作業宣言ツール なんですね。

経過時間の確認

togglのタイマーを見てもいいですが、私は時計をチラチラと見る癖をつけています。そうすることで経過時間だけでなく、今何時かが分かり、「気づいたらもうこんな時間かー！」ということがないようにしています。

常にデスクトップに時計を表示するために以下のアプリを使っています。

デスクトップ時計: デスクトップ用ライブ壁紙とドックアイコン

• Voros Innovation
• 天気
• 無料
• 

標準のmacの時計だと画面左上にあるので視線移動が若干だるくて、なるべく疲れない位置においています。私は右下が好みです。

まとめ

作業に追われている感がある、作業がとにかく終わらない、そんな時は

• シンプルなタスクに分ける
• タスク開始前にやることを宣言する

そんなことを心がけると作業スピードが改善されるかもしれません。

あわせて読みたい

• push通知を切り、情報は自分のタイミングでpullしよう - pblog