trailblazer/cells: View components for Ruby and Rails.
主に v2 以前から使っていた人向け。なんかずーっと ViewModel という言葉に引っかかっていたんだけど、ちょっと分かったかも。
まずは基本の使い方から。
定義
class SampleCell < Cell::ViewModel
..
end
呼び方
micro MVC 的な呼び方
cell(:<name>[, :<model>]).(:<state>[, options])
これで Cell の中のメソッドを読んだ結果を String として（to_sして）出力できる。View の中で micro MVC として使う Cells v2 以前の render_cell() 時代の使い方のイメージ。
ただのCellオブジェクトを取得する呼び方
cell(:<name>[, :<model>])
これで文字列になる前のただの初期化済み Cell オブジェクトが取得できる。
Cellの実体は.()でcallさせると安全にto_sできるオブジェクト
Cells は定義の部分よりは呼ぶ部分の方がちょっと気持ち悪い。まずマジカルさの一つは
cell().()
という見慣れない書き方なのだが、この .() は call() の syntax sugar だった。
Ruby | 「call」メソッド の Syntax Sugar 「.()」 について - Qiita
では call はどうなっているかというと、以下のようになっている。
def call(state=:show, *args, &block)
content = render_state(state, *args, &block)
content.to_s
end
call すると render して to_s している。1
さらに
def to_s
call
end
が定義されているので、 String として評価される context ではマジカルに #show が呼ばれ、view を render して何かが出力されるという算段になっている。
これを意図して rails generator で cell を作ると、まず
def show
render
end
だけを持つ class ができる。
ということで、「なんかいい具合に to_s するための仕組みの入っているオブジェクト」というのが Cells の実体と言ってよさそう。
一つ気をつけなきゃいけないのが、Cells は View ではなく Controller の context で実行されているということ。もう一つ、v4 以降の Cells は Rails 非依存なので、Controller を継承していない。cells-rails gem では関連 module はいろいろ include しているが、Controller を継承していることは前提にしてはいけない。
で、ViewModelとして扱うってどうよ？
Controller から View 向けのロジックを追い出すために Cells を使うとよいと「伝統的なサーバサイドWeb開発アンチパターンとその対策 - C, V編 - - あーありがち(2019-01-20)」に書いたが、Cells で本当によいのだろうか？という疑問は感じるかもしれない。むしろ PORO ( Plain Old Ruby Object ) の方がよいという意見もあるのではないかと思う。
結論から言うと PORO でもよいと思う。
ただ View 側に渡しやすい何かにするための ViewModel なはずなので、最初からそういう仕組みの用意されている Cells にしておけば自動的に置き場所も決まるし、安全に to_s されるし、独自の template を追加することもできるし、Helper も呼べるし、testability も考慮されてるし、まーだいたいよいことづくめだと思う。どうせ何らかの支援は欲しくなるはずだ。
個人的には Cell という名前だけが非常に引っかかっていて、どうしても micro MVC を用意するイメージが強いので、いっそのこと
app/cells/*_view_model.rb
みたいな名前付けで置いといて2、呼び方も
FooViewModel.new
みたいにしておくと、呼ぶ側からは明らかに render_cell の頃のアレとは違う使い方をしている感 が出るのでよいかもしれない。
これなら micro MVC 的な Cells と ViewModel を使い分けている感じをさせつつ、使っているツールは一つに絞れる。
うまく告知が拡散してないのでこっちで支援。
| 日時 | 2/16(土) 13:00 〜 17:00 |
| 場所 | いつものITプラザ武蔵 |
内容は
クラウド祭りだ！！
プログラムは濃いぞー
- クラウド概要
- Sqale で Rails アプリを動かす
- MOGOK の使い方
- 中の人による MOGOK の作り方（←!?）
参考
みんな来たらいいと思うよ
申し込み受付が遅れててすいません。
しかし、地方の弱小コミュニティで
- Rails アプリをクラウドで実際に動かす話
- クラウドの話は paperboy&co の Sqale と IIJ の MOGOK、なんと Ruby 対応 PaaS 2つ分!
- しかも MOGOK は中の人の裏側解説付き!!
なんて機会はなかなかないと思うよ！
Kanazawa.rbは参加者も協力してくれる人も大募集してます！
毎度困っているのは
- 懇親会の手配をしてくれる人
- ブログを書いてくれる人
です!!
金沢にいるのにまだまだ気づいていない人が多い！
Mashup Seminar in FUKUI 2011 | アップグレードふくい
道中すごい雪に当たったけど、なんとか無事に行って来れた。
アップグレードふくいに初参加
場所は福井県産業情報センタービル。初めて行ったけどこの辺はソフトパークふくいと言っていろんな企業、施設が並んでる。結構立派な建物で、会場もなかなか広かった。ぱっと見でパソコン開いてる人は1, 2割くらいで、年齢層は広め。女性も少ないながらもいたのは普段の勉強会と違うところか。1
アップグレードふくいはこのような催しの総称のようなもので、定期的に行われている。財団法人で新しいことを試みながらこれだけ継続しているのは北陸ではアップグレードふくいくらいじゃなかろうか。少なくとも石川ではコミュニティベースのもの以外は IT 系はまったく注力されていない。この違いはなんだろう。
感想
内容は紹介のページに譲るとして感想を。
Mashup Award 6をふりかえって
全体的に MA6 の可能性や熱さ、ゆるさは伝わったけれども、具体的に参加のためにこんなことをするといいよ！って話があったらもっとよかったかも。
特に今回の最優秀賞が EmiriSystem っていうのは心理的なハードルの高さがハンパないので。
EmiriSystem
いちばん上からいちばん下まですべて一人で開発、運営している EmiriSystem の全貌の話。
10年掛けてるとは言え、普通の人には時間的にここまでのものを作るのは不可能だと思う。よくよく聞いているともともと関係ない分野と言え研究開発が仕事だったり、グラフィックデザインにも興味があったとのことで、EmiriSystem そのものが直接仕事に活かせなくても何らかの形で生きているんだと思う。
単なる Mashup というレベルは完全に越えている。
印象に残ったのは今後の課題。継続性、専門性、品質。
1PACと世界の最近の事例から今後について
「透明化する境界線」というタイトルは話を聞くまで今ひとつピンとこなかったんだけど、なんというか、圧倒的だった。なんだこれ。Web の話は多くないですというかほとんどないというか。Web は「ソーシャル」という意味ぐらいしかなくなってきている。
いや、正しいのかもしれない。もともと Web の目的なんてシンプルなものだったし実装もシンプルなものだった。我々の日常の様々な活動は当然 Web では完結しないし、Web だけにこだわる意味もあまりないのかもしれない。それだけプラットフォームとして成熟したと言えるのかも。
そして「Web"上"」という「枠」も要らないのかもしれない。繋がり方はそれぞれで、HTTP は使っているかもしれないし Flash などの技術も使っているかもしれないけど、結果として我々人間とのインターフェイスはもはや Web と意識されていない、そんな世界に近づいている気がした。
Rails とか言ってる場合じゃないのか。いやまぁ、今回はフロントエンド中心の話だからね。バックエンドの話はまた別。
印象に残ったのは「会社としてできることの枠を広げる」というテクニカルディレクターの役割と、「新しいことに挑戦するのにデメリットはない」という言葉。
あと、普通にフィードバックとかアフォードとか言葉が出てきたけど、自分の足下を見てどれだけ通じるだろうという不安も感じた。
FITEA とコンペ報告
勉強会やってるよ、発表側になると勉強になっていいよ、具体的にはこんな感じだよ、という話と、学生さんのコンペの発表。
Twitter / @S Jun-ichi: FITEAはおっさんになりたい若い技術者を求めていま …
いや、それどうなの。
まぁ若い人もおっさんも一緒に頑張りましょうということで。
まとめ
Mashup Awards は興味はありながらも参加がかなわぬまま何年か経ってしまっている。そのまとめが聞けるならと、けっこう軽い気持ちで参加して、かなり内職する気まんまんだったんだけど、かなり間違っていたことを痛感した。
MA が、というよりは自分の意識の問題というか、あえて偏らせていたとはいえ、だいぶ「今」が分からなくなっていることを感じた。視点の違いでありアプローチの違いであり、可能性の違い。
自分は SIer でないにも関わらず最近はかなり SIer 的なスキルを自分に要求するようになっている。それは「結局システムの会社でない限りは社内の人間もお客様のような存在にならざるを得ないシーンが多いから」だ。SIer の課題を分かっているわけではないし、SIer によく聞く非効率的な制約もそれほどない環境ではあるが、「本来できるはずのことができていない」という感覚は強い。それを解決するための一つの方法として自分に SIer 的なものを求めている。
一方で、今自分に求めているやり方は、「失敗を減らし確実に前に進めるためには有効」だが「何か新しいものを生み出す」という意味ではたぶんベストではないと思う。そのこととそのために大切なことを、このセミナーでいくらか感じ取れたのではないかと勝手に感じている。
こういうのは、文字じゃ伝わらないんだよなー。
北陸はコミュニティベースよりも「公」の色があった方が女性参加者が増える印象。というか女性のコミュニティとは分断してるのかもしれない。 ↩
2009.10.29
09:14:00 >wtnabe< gemcutter サーバをイントラに立てられると便利だろうな
2009.12.03
21:14:52 >wtnabe< イントラに gemcutter サーバがあると便利だよね
酒を飲んだとかでなく、平気で同じことをくり返し言うようになってきている。まいりましたな。
それはともかく、gem server が簡単すぎてビビる件 を書いてから知らん間にずいぶん時間が経ってしまったが、やっと活用し始めた。
2010.01.22
11:37:34 >wtnabe< イントラに gem push したいしたいと思ってたけど、とり
あえず Rakefile に scp する task 足した。permission を考えたくないから
DAV 経由にした方がいいかなぁ。
どうしたかというと、cutagem で作った Rakefile に直接こんな task を書き足してお茶を濁した。我ながらひどい。
desc "push gem to intra gem server"
task :push_gem do
name = "#{NAME}-#{VERS}.gem"
sh %{scp name HOST:/PATH/TO/GEM_SERVER/gems}
end
こんなん。サーバ側では
/etc/cron.hourly/generate_gem_index
#! /bin/sh
GEM_ROOT=/PATH/TO/GEM_SERVER
gem generate_index -d $GEM_ROOT
chown -R Webサーバにしたんだっけ $GEM_ROOT
こんな感じで回してる。
scp で投げるのやめて DAV で投げられるようにすれば権限とか owner とか面倒なこと考える必要なくなるような気もするけど、あんま考えてない。どうせしばらく自分しか push しないだろうし。
あとはイントラで他に動いてるホストの
/etc/gemrc
に、ひっそり
:sources:
- http://HOST/PATH
で、gem を探すサーバを書き足してやる。
ちなみにイントラのgemはライブラリではなくshlauncherで固めたツール群の配信を想定している。
ごく簡単にメモ。
「検索」というキーワードを際立たせるためなんだろうけど、広告の話の中で AdSense を外してある。分かりやすさの代わりに Google の強さの一端についての情報が完全に消えてしまうので結構きわどい判断かも。
「あちら側」や「向こう側」という言葉にピンとこない層に対しても、Google という存在とそのサービスに依存する若者という構図を利用することで、オンラインサービスに対する依存とその状況の危うさを分かりやすく提示できている点はさすが。
ただ逆に映像がアメリカ中心すぎて Google のサービスとそれに対する依存の様子、また SEO, SEM の話や検索順位がビジネスに直結する状況などを「実感の湧かない海の向こうの話」にしてしまう感じはある1。あるいは若者世代のおばかさんぶり、という風に見えなくもない。日本の携帯キャリアとの提携の見せ方なども、ともすれば黒船来襲再びのように映っちゃったかも。
それが狙いなのかもしれないけど、別に Google や若い世代に限らない話だから、ちょっとどうかなぁと思った。余計なお世話かもしれないけど。
Google のアジアにおける苦戦の様子なども続編として描いてくれたら嬉しいな。
特に番組のメインターゲットは IT スキルが低くてそれほど Web 上のサービスを利用しておらず、身近な話として捉えるのは難しそう。 ↩
talby で撮った写真がちょっとたまってきたので携快電話を買った。これの新しいやつは Windows 版しか出ていない。本当は携帯Sync を Mac で使いたいのだけど、金沢には売ってる店がないらしい。すぐに手に入れたかったので携帯Sync を断念して携快電話を選択。くそっ。
USB 1.1 だからなのか CPU パワーの問題か、取り込みが案外遅い。しかしこれ UI は IE コンポーネントじゃないのか？ てーことは OS X 版も UI に Apple WebKit 使って、ドライバだけ書けば割と移植しやすいような。。。イチキュッパで出せとは言わないから頑張ってくれよ。恐らく開発者の IDE への習熟度の問題とか検証時間とかあるんだろうけど。
写真の整理には XnView を。。。あれ、ドラッグ＆ドロップでファイルの移動ってできないのか？ Windows 版はできたような気がするんだけどなぁ。サムネイルの HTML を吐き出して、、、って画像へのリンクが絶対パスだよorz こんなに使いにくかったっけ？ なんてことをちまちまと。ついでに GIMP で補正も少し。
普段やらない作業なので少し楽しい。
あー。これ USB-シリアルの変換アダプタなのか。携帯側の口ってひょっとしてずっと変わってないんだ。組み込み機器ってこの辺面倒だなぁ。今どきの携帯のメモリ容量はシリアルじゃつらいよ。
って番組が朝の8時から TOKYO FM であるんですが、
http://www.tfm.co.jp/on_the_web/timetable/
今日はその番組の中で金沢の旧町名復活の話題がありました。平成3年ごろから動きがあって、主計町なんかが復活したんですよ、てな話題があったのですが、この春から復活する木倉町なんかには触れられずじまい。また、なくなったはずの旧町名が実生活で使われ続けていたという事実も伝えてほしかったなぁ。うーん、残念。しかし、旧町名の復活って、金沢だけなんですね。知りませんでした
※ PukiWiki で日記のようなものを書いていたときの記述です。
PukiWiki 本体に少し手を入れて、編集時の textarea がウィンドウサイズに応じて変化するようにしました。で、その影響で Win 版 IE 5.5 では本文のエリアが狭くなりました(^^; IE 6 では大丈夫ですが、ある程度以上のウィンドウの幅がないと本文の部分が下の方に表示されちゃうという訳の分からない現象に見舞われます。
これは純粋にわたなべの勝手な都合で発生している現象ですが、おかげでかなり編集しやすくなりましたので、当面修正予定はないです。Win版 IE ベースのタブブラウザを使っている場合はけっこう不便かもしれませんが、これを機会に Opera 7 や Mozilla 系のブラウザへの移行をおすすめします :P Mac のブラウザでの挙動は確認してませんので、そっちで大きな不具合が出たら考えます。が、Netscape 7.0.1 の編集時に不具合が出るのは承知のうえで放置します。
ところで Win 版 IE 5.5 と Opera 6, 7 では通常の表示のときにバナーのうえにページ名が表示されます。編集のときには消えます。これ謎です。
※ タレコミがありました。css を指定する meta タグの記述が誤っていました。Mozilla でソースを表示すると閉じてるように見えてたのですが、実際には閉じてなかったようです。