ActiveDecoratorはリレーションのオブジェクトには効かない

ActiveDecoratorで作ったメソッドにアクセスできなかったのでメモ。
@hoge.piyo.decorate_methodみたいな感じで、Hogeモデルに対してbelongs_toなモデル(Piyo)のメソッド(PiyoDecoratorで定義したdecorate_method)にアクセスしようとしたらmethod_missingになってしまった。

ググったら以下のサイトとスライドがとても分かりやすかった。

ActiveDecoratorが有効になるのは、renderされるタイミングrender partialされるタイミングで、そのときに渡されている変数に対してのみらしい。
なので、@hoge.piyoをrender partialのlocalesで変数として違うテンプレートに渡すなどをすればいいらしい。
だが、そこまでするほどでもないなー、仰々しい…という場合は、@を付けてしまえばいいなと思った。つまり、こう。

class HogeController < ApplicationController
  def show
    @hoge = Hoge.find params[:id]
    @piyo = @hoge.piyo
  end
end

こうしてしまえば、@piyoはActiveDecoratorが有効になった状態になるので、普通にviewで@piyo.decorate_methodが使えるようになる。


書評:「アイデアは才能では生まれない」を読んだ


いつもなにか面白いアイデアはないかと漠然と考えている中、アイデアに関する本は色々読んでみたかったので、買って読んでみた。

色んな商品やサービスの開発話が載っていて、読み物としてとても面白かった。

特に、カルビーのじゃがりこの話が面白かった。
カルビーのじゃがいもへのこだわりと、じゃがりこが生まれるための4つアイデア。

ターゲットを高校生と設定。

  • いつでもどこでも
  • 美味しいものを
  • 手を汚さずに
  • 食べ続けられて口寂しさを紛らわせて歯触りがよいスナック

というニーズがあることがわかったのでそれを実現させるアイデアを考えていったと。

  • 袋に入ってるどこでもは食べにくいので箱にする。
  • 生のじゃがいもから作る。(普通はフレーク状や粉末にしたものから加工するらしい)
  • 手を汚さないために、味を生地に練り込む。
  • カリッとしてさくさくした食感なら食べ続けられる

これらのアイデアを思いつくまではかなりの試行錯誤があったらしいですが、その後の話も面白い。じゃがりこのネーミング話とか。そして愛される商品にしていくためのアイデアとして、キャラクターを作ったと。じゃがりこあんまり食べないからか、キリンのキャラクターがいることは僕は知らなかったが、言われてみればたしかにいた気がする。また、デザインバーコードを取り入れる遊び心をいれたことで、じゃがりこファンが増えたらしい。
そして、アイデアを横展開へ。じゃがりこの姉妹商品のさつまりこを作ってみたところ、これもヒット。また、ブランド強化のためにじゃがりこの新しい味を作るのもまたアイデアがあったそうだ。そして最後のところで、アイデアは才能ではなく、経験と問題意識から生まれるというふうに締めていた。

他の話もまた面白かった。まさに逆転の発想というか、あえて逆にしてみる、というやつが割と多かったけれど、最終的に言えるのは、良い発想をするためには、周辺知識をたくさん蓄積していることが大事であるという点だった。それを持った上で、常識からやや外れた視点が持てるか、視野を広げて考えることができるか、が求められるのだろう。あとは、見えないつながりを見つける力。着圧インナーといわれる、テーピングの役割をもった矯正インナーも、「テーピングを衣料品で代替できないか」という関係のなさそうなところを着眼してつながりを作るというのが重要であるとのことだった。

アイデアはふっと湧いてくるものではなくて、ずっと問題意識をもって考え続けていた結果出てくるものなんだなぁと思えた。人の視点を学習することができたのと、商品の誕生秘話が面白かったので、この本を読めたのはとてもよかったと思う。


書評:「稼ぎたければ働くな」を読んだ


GWでブックオフが20%オフセールをやっていたので、ひさびさに本を5冊も買い込んでしまった。

今回は未来工業創業者の山田昭男氏の本を買った。前に違う本を読んだことがあるのですが、違う視点が得られるかもしれないと思って。
97%の企業が儲けが4千万以上なくて、他社と同じようなことをやっている。そんなので業績が伸びる訳がないというところから始まる。

未来工業では

  • ホウレンソウ禁止
  • 残業禁止
  • 携帯電話禁止
  • 人事部がない(採用は部署毎に任せる)
  • 出戻り社員を雇う
  • 成功 > 失敗 > 何もしない の順に評価される
  • 社長は口出ししない(自分より有能な人がいるから信頼して部下に任せる)
  • 営業にノルマがない(ノルマが足かせになる)
  • マイナス思考とリスク管理は違う
  • 人生を楽しむほうを優先しろ。働くな。

と、まだまだありそうだけれど、普通の会社とは真逆の方向をいっていることが多い。

ホウレンソウ禁止
ホウレンソウが禁止なのは、ホウレンソウをすると指示待ちになって考えなくなってしまうからである。責任をとらないでいい方法ばかりを考えるようになる。それでは人は育たないし、上司のウケばかりを狙うようになっていくから、良い事がない。
「常に考える」を未来工業の方針にしているので、いいと思ったことはどんどん勝手に実践されていくらしい。常に自分で考え、責任を追うから、差別化を思いついていく。
残業禁止
残業を許可すると、ずるずる仕事をする人が増える。残業代ほしさに残業をするようになる。コストがかかるし、人生の過ごし方としてもよくない。仕事を早く終わらせて遊んでいるほうが人間らしい。
携帯電話禁止
携帯電話を個人が買うのを規制するわけではない。ただ、会社からは配布しない。ホウレンソウを禁止しているので、別に携帯電話が必要になることがない。
人事部がない
人事部があると、その人たちを雇うコストがかかる。それぞれの部署で必要な人を雇うほうが理にかなっている。
出戻り社員を雇う
一度去った社員が戻ってきたいということは、未来工業がやっぱりよかったということ。最初から教え直す必要もないし、また辞めたいという可能性も低い。再び雇ってもらった恩義を感じてすごく頑張ってくれるに違いない。
成功 > 失敗 > 何もしない の順に評価される
失敗を畏れて何もしないのが一番よくない。失敗したことをマイナス評価すると、だれも挑戦しなくなる。失敗しても、きちんとプラス評価してあげなければいけない。
社長は口出ししない
権限があるのと能力があるのは全くの別問題。自分のフィールドだったところに口を挟むのならまだしも、それ以外のところには言うべきではない。社長の権限は伝家の宝刀なので、むやみに使うべきではない。必要なのは部下がやる気をだして働けるように環境に配慮すること。あとは信頼すること。
営業にノルマがない
営業にノルマがあると、卸のディーラーばかり回る(実際に注文する人のところ)。商品が使われている現場を回らなくなる。ノルマをなくして現場の職人の声を聞き続けていると、本当に欲しいものがわかって新しい商品につながる。
マイナス思考とリスク管理は違う
マイナス思考はありもしないことを畏れること。
リスク管理は実際に起こったことを検証して、それに備えること。これをはき違えている人が多い。
本当にそれが起きることか?実際に経験したことがあるのか?必ず問うてほしい。
人生を楽しむほうを優先しろ。働くな。
そもそも自分が働きたくない。みんなにも人生を楽しんでもらいたい。人間らしさは無駄から作られる。いっぱい遊んでいっぱい無駄をしろ。

他にも色々とあるのだが(年賀状やお中元・お歳暮は無駄とか、高く売れとか、人を雇ったら3年間は育てるつもりで見守れとか)、なんかもういちいち納得してしまう内容ばかりである。こういう文化は、先進的な会社には結構通じるところが多いと思うが、旧体質の会社はまだまだ無駄が多い。本当に、こういう『社会の常識』みたいなのはなんでできてしまったのであろうか…。これのせいで困っている人は無茶苦茶多いと思うのに、やらないといけないみたいなのは、何を畏れているのだろうか。そんなものがなくてもちゃんとうまくいっているモデルがあるわけだから、そこを学んでいくべきだと思う。


simple_formでボタン押したときにconfirmを出す方法

Ruby on Rails3のポケットリファレンスや検索をしても出てこなかったので、試行錯誤した結果をここに書いておきます。
退会フォームを作っていたときに、確認のためのダイアログを出したかったんです。link_toメソッドからのやつで大概削除するから、そのときはconfirm出しやすいんだけれど、フォームのときはどうするんだ?と思ってたんだけれど、だいたいのところでは、

= f.button :submit, '退会する', confirm: '本当によろしいですか?'

って書いてあるんだけれど、これ動かないから。
正解はdata: {confirm: ‘〜’}でした。

= simple_form_for @user, wrapper: :table do |f|
  table
    = f.input :current_password, hint: '本人確認のため、入力お願いします'
    tr
      td
        | &nbsp;
      td
        = f.button :submit, '退会する', data: {confirm: '本当によろしいですか?'}

30分以上悩んでしまった…。危うくJavaScriptでonSubmitとるか、onClickでなんとかするか…とかまでやりそうになったけれど、「しかしRailsでもう既にconfirmの情報はあるのに廃止されているわけはないだろうしなー」と思って実験してみた甲斐があった…。


CSS:ボタンとボタン風リンクの高さが合わない問題に終止符!

長年悩んでたやつなんですが、ボタンとボタン風リンクの高さが合わないやつ。
Chromeで開発してて高さを合わせてると、違うブラウザだとずれてる場合があります。今回も普通にやっていたら、ボタンの大きさが違うのをなんとかしてくださいって言われて、合ってるのに何言ってるんだ?と思っていたら思い切り違ってました…。

これはあれか?CSSをハックせにゃならんのか?と思ってcss ieでググっていたのですが、IE11でもずれるのはなんか変だしそろそろ解決策あるだろーと思って色々調べていたら、あった!!

cssで、aタグのdisplayをinline-blockにして、line-height: normalにするとよかった。ただ、全体的にline-heightを変えてないのであれば、これは必要ないんですが、だいたいのサイトはline-height変えてますよね…。
以下のresultとcssのタブを見てもらえたらわかりやすい。

ボタンは改行されることがないので(多分)、line-heightの変更の影響を受けていないのですが、aタグは本来はただの文字列中に登場するものなので、思い切りline-heightの影響を受けます。これを、ボタン風class内でnormalに戻してやる必要があったと…。

これが解決したときにはすげー感動しました。
ChromeとIE9,10,11で確認した限りだとこれでいけました。