コールバックとオブザーバーの違い
ruby on rails 3
railsにはコールバックとオブザーバーのふたつの考え方がある。
これらは、モデルにおいて新規登録／更新／削除のタイミングで呼び出される処理を記述するもの。
コールバックはモデルに密接した処理を記載するのに対し、オブザーバーはモデルに密接していない(依存していない)処理を記載する。オブザーバーは、モデルを監視をするクラスとして独立しているイメージ。これにより、再利用性の向上、モデルに依存していない明確な意識付けができる。
コールバック
モデルAにデータを追加する時にログを書き込む例。
class A < ActiveRecord::Base
after_create do |b|
logger.info('created:' + b.inspect)
end
end
オブザーバー
モデルAにデータを追加するときにメールを送信する例。
- railsコマンド
rails generate observer Aでオブザーバーを作成する。 - 生成されたオブザーバーファイル
A_observer.rbに以下を追記する。
class AObserver < ActiveRecord::Base
def after_create(b)
NoticeMailer.sendmail_A(b).deliver
end
end
3.設定ファイルconfig/environments/development.rbに作成したオブザーバーを登録する。
config.active_record.observers = :book_observer
※ モデルとの連結は、ファイル名からクラスを特定して勝手に行ってくれる。
複数モデル用のオブザーバーも作成可能
オブザーバー先頭に以下の記述を加えれば、複数のモデルにて使用できるようになる。
observe :モデルA, :モデルB
プログラム上で処理対象のモデルを識別したい場合は、以下の記述を行う。
def after_create(b)
if b.is_a?(モデルA)
# モデルAの処理
else
# モデルBの処理
end
end
テンプレート呼び出しでモデルを渡すときに省略する
ruby on rails 3
勉強中、以下のような表記の場合に、どのテンプレートを指すことになるのか、さっぱりわからなかった。
<%= render @person %>
これ、テンプレートにモデル@personをパラメタ渡しすると、
自動で、部分テンプレート/views/persons/_person.html.erbを描画することになるらしい。
つまりは、 viewsフォルダ配下の(モデル名複数形)/_(モデル名).html.erb の省略。
省略せずに書くと、
<%= render 'persons/person' @person %>
ってことなんだね。
配列を渡すと・・・
配列をパラメタで渡すと、その配列数分、テンプレートを使った描画を繰り返すので便利。
また、配列のなかに複数のモデルが含まれている場合は、それぞれのモデルにおいて上記ルールのテンプレートを見に行く仕組らしい。
railsのjavascript格納場所
ruby on rails 3
public/javascripts/配下にJSファイルを格納する。
application.jsはデフォルト空白で、ここにJSを記述すると以下のヘルパーで展開できる。
<%= javascript_include_tag :all :recursive => true %>
:allはjavascriptsフォルダ配下の全てのJSファイルをインクルードする。
:recursiveで、サブフォルダ配下の再帰取得を行う。
ファイルの読み込みを高速化する場合は、:cache => true を付与することで、jsファイルを一つにまとめて all.js としてインクルードする。
はてなブログでも使えるMarkdown！おすすめのMarkdownエディターはこれだ！
世間を騒がせている、イケてる表記法「Markdown」
最近は何でもこの記法でテキスト入力するようにしている。
何を隠そうこのブログも、Markdown記法が使えるからという理由ではてなダイアリーから移行した。
Markdown記法の良い所は、学習不要でリッチなHTMLが作れるところだろう。
そして何よりも各サービスがこの記法を採用している点が大きい。作成したデータの再利用性が非常に高いのだ。
達人プログラマーにも「プレイン・テキストの威力」として、データ再利用の必要性について触れられている様に、この考えはとても大切なことだと思う。
そもそも、Markdownってどんな表記方法？
細かく書かれているところもあるけど、手っ取り早く理解するにはwikiが一番良かった。全て網羅されてるわけじゃないけど。
よく使うのは、# の見出しとか、* のリスト、1. で作られる順列リスト、そして、下のようなテーブル記法。
|A|B|C|
|:---|:---:|---:|
|あいう|えお|1|
|かきく|あいうえお|222|
|さしす|せ|3|
こうやって書くと、
| A | B | C |
|---|---|---|
| あいう | えお | 1 |
| かきく | あいうえお | 222 |
| さしす | せ | 3 |
こんな風にテーブル表記に切り替わる。これは設計書などに超便利！
どんなところで、Markdownが使われているか？
冒頭で書いたとおり、はてなブログやGitHub、Qiita、プロジェクト管理システムの
Backlog
なんかもMarkdown記法に対応するようになったみたい。
ただ、Backlogについては、過去の入力データもMarkdown記法で表示しようとするので、独自のBacklog記法で書いたwikiとか表示が崩れてしまう！残念！
回りくどいやり方だけど、
Markdown→Backlog記法のコンバーター
があるのでこれを利用する手もある。そう、回りくどいけど。
とにかく、設計書や説明書がとても簡単に、そしてシンプルに出来上がる表記だと思う。エンジニアは進んで修得するといいんじゃないでしょうか！
Markdownをどのようにして書くか？
Markdown記法に慣れるまでは、どのように表示されるのか試しながら書きたいところ。 そこで、どんな方法があるか調べてみた。
Markdownエディター
まずは、Markdownエディターとしてどのような物があるか。 Mac、Win共に様々なものが用意されているが、実際に使ってみたもの(Mac)は以下のエディタ。
Kobito
Kobito
Qiitaからリリースされている、純日本製のエディター。
Qiitaとの連携もバッチリなのでプログラミングに関するメモに最適。操作感が軽やかでシンプルなのがいい。
ただ、Markdown記法に完全準拠しているわけではないので、Markdonwエディターとして使うには難あり。
チーム間ファイル共有の機能もありプロジェクトに導入しやすそうなので、Markdown記法に完全準拠して欲しい。
無料。
LightPaper
LightPaper for Mac
フォルダ構成の表示、編集画面のタブ化など、最近の高性能エディターの風格を持つMarkdownエディター。
でも自分の環境だと、フォルダ構成が表示されない。なんでだ？
リストが自動挿入されたりと入力補助は申し分ないが、プレビューが入力部分を追従しないことがあったりして、いまいち変換結果の確認がやり辛い。
cssを自作する機能は準備されていないが、 /Applications/LightPaper.app/Contents/Resources/CSS下に自作のCSSを置けば、環境設定から選べるようになる。
無料。
Mou
Mou
LightPaperのように高性能ではないけど、シンプルでとても扱い易い。
一番良い所は、LightPaperで駄目だったプレビューの追従性が優れているところ。
このストレスがなくなると入力→確認のスピートが上がって良い。
CSSの自作も可能だしおすすめ。
無料。
いつものエディターでMarkdownを書く
使い慣れてるエディターでMarkdownを書く場合、プレビュー機能を追加する方法がある。
SublimeText2
以下にインストール手順が詳しく説明されている。
SublimeText2でMarkdownをプレビューするプラグイン - コードで一言
キーバインドで設定したキーを押すと、ブラウザが起動しプレビュー表示される仕組み。キーを押下する度にブラウザが立ち上がるので、ちょっと使い辛い。 Markdown記法になれた人が、文章作成後の最終確認に使う感じだろうか。
Emacs
以下にインストール手順が詳しく説明されている。
EmacsでMarkdownのプレビューをお手軽に確認する方法はこれかな？ - マスタカの ChangeLog メモ
SublimeText2と同じく、キー押下でブラウザが立ち上がるタイプ。
Gmail
GmailでもMarkdown表記が使いたい！って病気の人は、以下のエクステンションなんかもある。
Markdown記法の文字列を範囲選択、右クリックメニューからこれを選べばHTMLに変換される。
インストール無しでいつものエディターを使いたい場合
これまで紹介してきた方法はインストールが必要だったり、ブラウザが何度も立ち上がったりとあまり使い心地が良くない。 でも、次の方法だとインストール不要で、セーブアクションでのリアルタイムプレビューができる。ブラウザが次々立ち上がることもなくいい感じ。
楽して Markdown ファイルをリアルタイムプレビューできる仕組みを作ったった - blog.k11i.biz
お手軽だし、使い勝手もよいので超絶オススメ！
超えられない壁
そんな訳で身の回り近辺をすっかりMarkdownColorに染めてやったんだけど、ひとつだけ上手くいかないことが。。。
それはGoogleDocument。
こればっかりは方法がみつからない。仕事で多用してるからここをどうにかしたいんだよなぁ。
GASで作るとかかなぁ。。。
社長は少しバカがいい。
エステー株式会社会長 鈴木喬
独裁的な方針でチームを引っ張る。
製品企画から設計方針、そして営業まで統括するスタイルの社長。
自分の勘を信じ、「消臭ポット」を始めとするヒット商品を世に出した。
鈴木氏はこう言っている。
「独裁でなければスピード経営はできない。」
変化の激しい業界ではスピードが企業の生死を左右する。そのためには、経営者の思いをすぐ形にできるチームが必要なのだ。
鈴木氏がエステーの社長に就任したとき、役員の大半が彼に反感を持っていた。会社の経営状態も良くなかった。
彼は反発する役員を除し、バランスシートの健全化のため、不良在庫を徹底的に捨てた。
不良在庫は資産に計上されるがそれは本当の価値ある資産ではない。在庫を処分したらPLの見栄えが悪くなるので在庫を捨てれないでいるだけだ。
初めはそうやって一人で戦っていたが、成果が見え出すと賛同する社員が現れるようになった。
そうして、「消臭ポット」の発売につながったのだ。
鈴木氏は云う、過去を全面否定できるのは社長だけだ、と。
破壊的イノベーションは社員だけではつくれない。
いちサラリーマンとしては悲しくもあるが、小規模の会社であるならば彼の言うことは正しいと思う。
社長の強さが無いと社員はついてこない。
社長が情熱を持っていないと山は動かない。
社長は自分が正しいと思うなら、誰に臆することなく徹底的にやるべきなのだ。それでも社員が付いて来てくれるよう、しっかりと根回しをしておくべきなのだ。その自信がもてない社長は勝ち残ることができないだろう。
鈴木氏の考えを読み解くと、そう思えてならない。
「独裁」との言葉は嫌悪感を抱きやすい。
何か、考えに偏りがあり正確な判断ができない、そんな印象を持ってしまう。
しかしそれは、独裁者の中で正確な判断ができれば済む話しでもある。
極端にいうと、三人で出す結果を一人でだせればそれでいいのだ。
それよりも独裁で得られるスピード感が、現代のネットビジネスを始めとする現場で有効なのだ。
なんかこれは、サイバーエージェントの藤田晋氏にも通じる部分かなと感じた。
最後に、本書でとても気に入った部分を書き留めておく。
この頃は、絶対に反省しないと決めた。
もちろん、失敗した原因を突き止めて、次に活かすことは重要だ。だけど、いつまでもクヨクヨしてたって元気がなくなるだけ。それよりも、笑ったほうがいい。
(中略)
バカみたいな冗談でも言って、笑ってたほうが脳みそは動いてくれる。
- 作者: 鈴木喬
- 出版社/メーカー: WAVE出版
- 発売日: 2013/01/25
- メディア: 単行本（ソフトカバー）
- 購入: 2人 クリック: 6回
- この商品を含むブログ (8件) を見る
人を動かすもの
人を動かすもの
それは「もの」よりも「生きがい」
解っているつもりでも
それをチームに与えられているか？
うまく行った時のチームの「生きがい」が何だったか。
うまく行く時の自分の「生きがい」は何だったか。
もう一度、考える。
どういうわけだか
久々に書いている。
いろいろと思い悩む時期に来ているわけだ。
もう今年で34だとさ。
昔あこがれた上司と同じ年齢になった。
同じ年齢だと！？
俺には全然足りてない。上司の足元にも及ばない。
上司、尊敬する先輩方と仕事をしてから10年以上たった。
眩しい存在だったなと。彼らに今でも憧れる。
想像の中に生き続ける彼ら。
俺はいつ到達できる？
