CellsはLayoutを持っているか

Jan 27, 2019

RubyのCellsには独自のlayoutがある

trailblazer/cells: View components for Ruby and Rails.

使い方は以下のような感じ。

class FooCell < Cell::ViewModel
  layout :simple

  def bar  # state
  end
end

※ Rails の Controller 的にはメソッドは action なんだけど Cell::ViewModel 的には state になる。

レイアウトはどこに置くかというと、cell 用の view を置く場所にそのまま。名前付けに何かルールがあった方がよさそう。

cells/foo_cell.rb
cells/foo/bar.erb    <-- state用template
cells/foo/simple.erb <-- layout

Laravelのtorann/cellsにはlayoutはない

※ 上の Laravel 4 用の torann/cells は fork 版です。オリジナル版は type hint が邪魔して実際には使えないので。

この Cells にはそもそも独自の view object というものは存在しない。あくまで Blade の中に一つの記法（directive）を用意して、その中で独自に template を読んで render した結果を返すだけ。CellBaseController はあるが Laravel の Controller のようには layout を指定する機能はない。

というか Laraval の Controller は Layout 制御を積極的に支援していないので、考え方が違う。@extends, @section, @yield と、Ruby 版の Cells と同じように名前付けのルールがあればよい。

今さらab以外のテストツール調べた

Jan 27, 2011

ふと twitter 上に httperf という文字がよぎったので、はてなんだべと調べていたらこれが見つかった。

Programing Bible：Webの負荷テストに使えるフリーソフトウェア (1/2) - ITmedia エンタープライズ

で、感想としては

普段使いなら ab でいいかな
より複雑で実際の環境に近いテストは Siege がよさげ
- Siege 入れられない環境とか ab 入ってない環境は httperf がよさげ

という感じかな。httperf は流行ってるらしいけど ab から積極的に乗り換えるほどでもないように見えた。もちろん Apache をインストールしていない環境の場合は話は変わってくると思うけど¹。

Siege

proxy で URL 収集ができる。収集した URL からランダムにマルチスレッドでリクエストを投げるので、より実際の環境に近いテストができる。らしい。

パッケージ	有無
fink	NO
CentOS	YES
Debian	YES
MacPorts	YES

httperf

パッケージ	有無
fink	YES
CentOS	YES
Debian	YES
MacPorts	YES

参考

上の記事は日本語訳は sf.jp が元記事で、さらにオリジナルは linux.com らしい。これだけリンクしとけば情報源としてどれかは生き残るだろう。

Apache 1.3系が信用できないとかいう話になるとそれはもう残念ですねとしか言いようがない。 ↩

Capistrano の :ssh_options と Net::SSH

Jan 27, 2009

また twitter の log から。

00:11:35 wtnabe< それ以前に :ssh_options の設定方法をミスっていたらし
い。:config => true を外してもそのまま認証できた。。。
00:11:43 wtnabe< 昼間のオレはバカすぎたということか。
00:12:18 wtnabe< オプションの与え方は set :ssh_options,
00:13:03 wtnabe< オプションの与え方は set :ssh_options, {} で、何がセッ
トできるかは net-ssh の ssh.rb を読むと書いてある。

lib/capistrano/ssh.rb

まず Capistrano の ssh 関係のファイルを読んで行くと以下のような記述が見つかる。

   # If an :ssh_options key exists in +options+, it is passed to the Net::SSH
   # constructor. Values in +options+ are then merged into it, and any
   # connection information in +server+ is added last, so that +server+ info
   # takes precedence over +options+, which takes precendence over ssh_options.
   def self.connect(server, options={})
     connection_strategy(server, options) do |host, user, connection_options|
       connection = Net::SSH.start(host, user, connection_options)
       Server.apply_to(connection, server)
     end
   end

ということで :ssh_options に設定するらしい。何が与えられるかというと、Net::SSH.start を読めばいいのかな。

lib/net/ssh.rb

   def self.start(host, user, options={}, &block)
     invalid_options = options.keys - VALID_OPTIONS
     if invalid_options.any?
       raise ArgumentError, "invalid option(s): #{invalid_options.join(', ')}"
     end

この上の start メソッドのコメントにオプションというオプションがズラーっと書いてある。ここ読めば全部分かります。あまりの量で引用の範囲を明らかに超えそうなので控えてしまいました。

なるほどな。いやこの Net::SSH ってホントすごいな。

ちょっとダウン

Jan 27, 2005

日々

今週頭から調子悪かったんだけど、どうも昨日からいよいよ風邪っぽい。知恵熱？とか思ったが、だったら鼻水ズルズルにはならないだろうから違うと思う。

気をつけているつもりだったんだがなぁ。うがい、手洗いをやっていても、もらっちゃうときはもらっちゃうんだな。

オレオレ証明書クイズがらみ

Jan 27, 2005

Security

オレオレ証明書クイズに対する高木さんのコメント

を読んで、やっぱりこれが自分の使う言葉だなと感じた。高木さんの言葉は切れ味が鋭すぎて問題を理解させるための材料には使いにくい。

いや実際にこの結城さんの言葉を使ったのです。過去にね。で、そのサイトは今第三者認証を得た https をユーザーに提供しています。

そもそも SSL って何？ベリサインて何？という人に対しては

通信の暗号化
接続先サイトの真正性の証明

の2つをちゃんと分けて、なおかつこれは別の次元の問題だという説明をしなければいけない。しかし高木さんの書き方は「証明書がなきゃ意味ないじゃん」という前提（要するにセキュリティを考える人間にとっての常識）に頼っている部分があるので、前提を分かっていない人に対して何が問題なのか理解させにくい。

「設問がよくない」のは SSL という全体像を捉えて、正しい SSL を一発で解答したい場合に限って正しい指摘だが、設問がよくないかどうかも分からない人にとっては、片方だけではダメなことがはっきり分かる形にするために問題文もあえて分けてやった方がよい。

ただ結城さんの問題は (2) がいきなり高度かなという気もする。ここも YES/NO で答えられる形で「間違いなく自分の意図するサーバに接続しているかどうか」を問うた方がよかったように思う。そうしておくと SSL に限らず普段見ているサイトが果たして本物かどうかを考える契機にもできるから。

diff の RSS が抱えてるっぽい問題と自分のスタンス

Jan 27, 2005

辺りを読んで、現在 RSS 1.0 で最新の diff だけを配信している rssdiff.inc.php はちとまずいなぁという思いが少し強くなった。（以前から使いにくさは感じている。）

RDF 的な意味のおかしさ

RSS 1.0 は RDF の縛りを受ける。RSS1.0によるdiff配信に反対を読むと「diff のページへリンクを張っている RSS」として提供する分には問題なさそう。diff の RSS なんだから別にいいじゃんと思っていたがかずひこ氏が Hiki の RSS 出力をマシにしよう計画で

「content とか言っておきながら差分だけですか？」というのが気にならないでもないのですが、description のところに「わかりやすく」差分を見せるのも難しいような気がします。

となんか変だなと感じていたのも根っこはこの部分なんだな。きっと。

しかし逆に diff にリンク貼られてもあまり嬉しくないんだよなぁ。これは diff を pre で表示しちゃう PukiWiki の特性かもしれないけど。少しでも文章が長いととにかく横にスクロールさせなきゃならなくて見にくい。

RSS 2.0 だとこの辺の diff にリンクすべきという問題は解決できるんだろうか？解決できるなら RSS 2.0 という選択肢はがぜん現実味を帯びてくるな。

人間にも意味が分からなくなる可能性

これはおおいにありうる。自分のように細かく修正を保存しながら書いていくタイプの人間が使っている Wiki では diff があまりに断片的になりすぎて使いものにならなくなる可能性は高い。ただしこれには解決策とあまり問題にならないのではないかという2つの解答が自分の中にある

diff の基点を明示できるようにしたらどうか？

現在の Wiki のインターフェイスにこういうものは存在していないが、近いものは KakiWiki である。使ったことはないが、KakiWiki にはスナップショットを保存するという機能がある。これは実は自分の考える理想の Wiki に少し近い。自分の現在考える理想の Wiki は cvs commit のような明示的なアクションで snapshot を保存し、diff はそこからの差分を表示するという形のものである。commit を自動で毎回行い、権限の管理を行わないという方法もあるだろうし、commit の権限を core member に限定してしまうという方法もありだと思う。個人的には core member に限定して commit 時にちゃんと log を書くという方法の方が嬉しい。断っておくがここで編集の権限と commit の権限はベツモノである。あ、例えばこれを利用すれば特定のリビジョンにロールバックするのも簡単にできそうだ。

こうすると細かく保存しながらある程度まとまったところで commit、変更点を分かりやすく書くことで追跡を容易にするという芸当が可能だ。

「細かく保存しなければよい」という選択肢もあるが、指が無意識のうちに保存のための動作を行うようなタイプも居るのだ。細かく保存せずに長文を書くなんてちょっと昔の安定しない OS を使ったことのある人間や冬の北陸に住んだことのある人間¹には恐ろしくてとてもできない。これは Web アプリでも同じだ。

当然のことながら Wiki 上でコミュニケーションまでやってしまっているような使い方ではこういう方法は採用しにくいだろう。が、これはそもそもそういう使い方は Wiki としてどうなのか？という疑問の方が強いので考慮しないことにする。

あまり気にしなくてもよいか？

まず前提があって、自分は Wiki の RSS をすべて diff にするということは考えていない。RSS も目的別にあってしかるべきだと思う。だから diff についての RSS ですべてをまかなう気はないし、diff の RSS では一見については考える必要はないと思っている。diff の RSS を必要としているのはリピータである。しかも荒らしを見つけてくれるようなディープなリピータ（小人さんとも言う）である。どちらかというと core member。diff の RSS はそういうユーザーにフォーカスされていていいと思う。

もちろんフォーカスされていても時間が経てば diff だけ見ても何がなんだか分からないということはあるだろうけど、そういう場合は諦めて全文読み直してくれってことだ。RSS が万能である必要もないと思う。

しかしあれだなー。こういうネタのときは TrackBack 送れないのはもどかしいなぁ。やっぱ引っ越しますか。