最終更新: 2010-04-19T06:03+0900
Rails以前の化石級の知識をアップデートすべく手に入れた。10ページ目でみかけた、モジュール定義での extend self (module Foo; extend self; ～ end というような)。テストの章だから説明がなかったけど、これは当たり前には出てこない。一括 module_functionか？先頭に置いても平気なのか？検討が必要。できるだけ実際のコードを使用するという方針のメリットが早くも得られたかたちで、先が楽しみだ。
昨年末の記事だけど Gmailが対応したことで知った。非同期ファイルアップロード(20100415p01)はまだ便利なように拡張できるってわけだ。
機能するブラウザが限定される＆スクリプトがないと機能しないのであれば、ドロップエリアもスクリプトで用意しないといけないだろうな。
最終更新: 2010-04-17T11:07+0900
縁のなかった分野、著者の本を読む機会が続いたので記録。
最終更新: 2010-05-01T17:13+0900
リストをネストしたときだけ生のテキストに<p>タグが付くのがオリジナルのはてなと違うんだそう。ついでに空の<p>タグが生成されるのも気になるけどそれは別。
最初に。<li>はブロック要素もインライン要素も包含可能らしいけど両方を並べて含んでいいのかはわからなかった。読めない(block or inlineの 0以上の繰り返し、だという気はする)。Another HTML-lintが文句を言わなかったのでいいものとしよう。
次に、CodeReposの hatena_style.rbの中を見てみる。Hatena::Blockがなにやら特別な位置を占めてるけど、一応 Hatena::Inlineと同じように振る舞うみたい。ところで、Hatena::Blockはブロック要素の連なり、Hatena::Inlineはインライン要素の連なりを表してるけど、その両方の連なり(<li>の中身とか)を表すクラスがない。
てっとりばやく済ませるために、Hatena::BlockAndorInlineというクラスを用意して Hatena::Blockが行っていた仕事をごっそり移動するそれだけでなく。Hatena::BlockAndorInlineにはインライン要素を含んでいいのかを示すフラグを initializeを通して与え、それにより何が何でも<p>タグで囲むのかそのままにするのかという動作を変えることにした。現状、求められてるのがその違いだけだから。
Hatenaスタイルは使ってないからあからさまなバグがあっても気付かない可能性が大きいです。
suppress_ptag_in_nested_list.patch (7.1KiB, 2010-04-16, r37217との差分)古くなりました。
順序付きリストや定義リストの対応を忘れてる。
<dt>の中はインライン要素の 0以上の繰り返し、<dd>の中はインライン要素とブロック要素の 0以上の繰り返しっぽい。Hatenaスタイルでは定義リストにはインライン要素しか認めていないので対応は必要なし。順序付きリストだけ。
suppress_ptag_in_nested_list.rev2.patch (8.2KiB, 2010-04-16)
svn diffで -x -p (-x <ARG>: diffに渡すオプション, -p: Cの関数名を表示)を初めて付けてみたけど、Rubyスクリプトであってもクラス名は拾ってくれるみたい。
次々空いてくる穴をふさぐのはどちらかといえば好きだけど……。
それはそれとして、
Hatena::Section#bodyは期待通りうごかないかも。(目的がデバッグ出力だったなら OKだけど)
def body
@tree.body.to_s
end
@treeは以前は Hatena::Blockか Hatena::Inlineだった、俺の変更で Hatena::BlockAndorInlineか Hatena::Inlineになった。カスタマイズされた to_sメソッドを持っているのは Hatena::Blockだけ。
肝心の深すぎる再帰は再現できない。自分自身を子要素に持ってるなんてことはないはずだから convertメソッドが自分自身を呼び出すしかない。その可能性があったのは Hatena::Block#convertのみ。そのときは if @body == selfでチェックして @body(Hatena::Block).convertを回避していたし、今は @bodyに Hatena::Inlineか Hatena::BlockAndorInlineしか入っていないから自分自身を呼ぶことは考えられない。わからん。キャッシュのせいだったら拍子抜けだなあ。<<<以前は @bodyに Hatena::Blockが入っていたんだから、古いデータと新しいコードの組み合わせで無限再帰は十分ありうる話。.parserキャッシュにはクラス名やインスタンス変数も入ってるし。
fix_c37239.patch (623B, c37239の修正)
サブタイトルの有無の判断が間違って反対になっていた。
サブタイトルのみのときにエラーになっていた。
fix_c37240.patch (955B, c37240の修正)
順序付き、順序なしリストの階層が勝手に深くなっていた。
セクションの分割に失敗していた。
たぶん HTMLソースレベルの空行なんだと思う。Hatena::BlockAndorInline#convertでインライン要素の後だけは改行を付加しないようにすればなくせるが、<p>の有無と違って(white-space:preとかしない限り)見た目に関与しないのでこだわらない。(<p>の後ろと</p>の前にも改行が挿入される、だとか考え始めるときりがない)
スレ主は hatena_style.rbを使うことにこだわってはいないという。こちらは楽しんでやってるんだけど、いつまでもデバッグに付き合ってもらうわけにもいかないだろう。はてなはウクレレ記法ができてこそのはてなだと思ってるので、それができない hatena_style.rbから乗り換えるのも悪くないと思う。
「ウクレレ記法」で検索したら主犯が見つかった。最初は Hikiに実装したって書いてるよ。(始めて一か月ほどだったとも書かれていて)つくづくプログラミングは何に使うかが大事だと思う。(英語なんかと一緒でツール)
http://coderepos.org/share/ に書かれている通りにメールを送ってみたが音沙汰がない。スパム判定されたか。comitterってそのページに書かれてるので全てだよね。行動力のある人間なら(というか人並みの人でも) Twitterなり IRCなり blogなりでアクションを起こすんだろうが……。(だから手続きが自動化されてなさそうなのが嫌だったんだ。漏れるし遅れるし。それにサービス自体個人の奉仕に依存してる)
気になる。自分のバグも他人のバグも気になる。
Hatena::Section#initializeの部分の修正は、既に行頭の *で分割された文字列が与えられるから問題ないとして先のファイル(fix_c37240.patch)に含めてなかったけど、まあ subが gsubになったって減るもんじゃなし。
それだけでなく 実は一行だけ buffer = '' を buffer = lines.shiftに書き換えた。これがないと無限ループに陥るケース(「>>>」という本文。3文字目は他の文字でもいい)があるみたいなので。
最終更新: 2010-05-07T12:01+0900
設定画面に jQueryが仕込まれたのと、JavaScriptの置き場所が用意されたので、ファイルのアップロードを非同期に行う準備が整ったのではないか。独自のサブミットボタンを編集画面に貼り付けるプラグインが全部非同期になれば、プレビュー画面にアップロードフォームを表示しても(編集中の本文が消えたと)怒られないだろう。
ジャンクだけど Firefox3.6と Internet Explorer8と Google Chrome4.1で動くものをこの日記(最新じゃないので jQuery対応ではない)に仕込んでみた。
これで本文を書きながらプレビューもできるしファイルのアップロードもできる。
クリップボードアクセスのために Flashを使うよりはましだけど、<iframe>に頼らなければいけないというのもわりと屈辱的。<frameset><frame>以上に、これまで存在を認めてこなかったのに。
何となくできないものと思っていたけど <iframe>の中から外のドキュメントにアクセスすることができるみたい。それができたら編集画面が無制限に入れ子になる(編集画面の<iframe>の中の編集画面の<iframe>の中の……)ことを今より簡単に防止できて、スクリプトももうちょっと使いやすく書き換えられる。
「Karetta|[JavaScript] Firefoxでtextareaのカーソル位置に文字列を挿入した後にスクロールが先頭に戻ってしまう問題(karetta.jp)」で紹介されている通りで直った。といってもできるだけ余計なことをしないように条件を付けたが。
var scrollTop = textarea.scrollTop;
/*
ここで、テキストエリアに文字列を挿入する。
*/
if(0 == textarea.scrollTop && 0 < scrollTop) {
// スクロール位置がリセットされていたので復元する。
textarea.scrollTop = scrollTop;
}
ところで、Internet Explorer 8だけはテキストエリアのキャレット位置を保存しようなんてことを考えなかったみたいで、いったんテキストエリアがフォーカスを失うとキャレットが必ず末尾に移動する。スクロール位置がどうこうどころではないわな。
「何となくできないものと思っていたけど <iframe>の中から外のドキュメントにアクセスすること」 < HTML5 sanbbox属性
最終更新: 2010-04-13T09:43+0900
二つ目は AquaSnap。 Aero Snapや Aero Shakeを模倣するだけでなく拡張もし、カスタマイズもできる。スキン機能やフェードインしてくるアバウトダイアログに象徴されるように見た目にもこだわってる。でも Windowsキーと矢印キーを組み合わせたグローバルホットキーには対応してなさそう。下フレームのダブルクリックによる高さの最大化とグローバルホットキーの二つが加わるとありがたさが三倍に増すんだけど。
最終更新: 2013-08-20T01:04+0900
「makeplex salon：あなたのスキルで飯は食えるか？ 史上最大のコーディングスキル判定 (1/2) - ITmedia エンタープライズ」経由で「人生を書き換える者すらいた。: 人材獲得作戦・４ 試験問題ほか」
粘菌でも迷路問題を解けるというのだから負けてはいられない。Rubyで一時間半弱かかった。
#! ruby
# coding: Shift_JIS
# 迷路データ
maze = <<MAZE
**************************
*S* * *
* * * * ************* *
* * * ************ *
* * *
************** ***********
* *
** ***********************
* * G *
* * *********** * *
* * ******* * *
* * *
**************************
MAZE
# マップ
class Point
def initialize(x, y)
@x, @y = x, y
end
attr_reader :x, :y
def ==(other)
@x == other.x && @y == other.y
end
def to_s
"(#{@x},#{@y})"
end
def left
Point.new(@x-1, @y)
end
def right
Point.new(@x+1, @y)
end
def up
Point.new(@x, @y-1)
end
def down
Point.new(@x, @y+1)
end
end
class Map
def initialize(maze)
lines = maze.strip.split(/\r\n?|\n/)
@height = lines.length
@width = lines.first.length
y = -1
@map = lines.map{|line| y += 1
x = -1
line.split(//).map{|ch| x += 1
if(ch == 'G')
@goal = Point.new(x, y)
nil
elsif(ch == 'S')
@start = Point.new(x, y)
nil
elsif(ch == '*')
-1
else
nil
end
}
}
end
attr_reader :height, :width
attr_reader :start, :goal
def []=(point, value)
@map[point.y][point.x] = value
end
def [](point)
@map[point.y][point.x]
end
def up(point)
return -1 if point.y-1 < 0
return @map[point.y-1][point.x]
end
def down(point)
return -1 if self.height <= point.y+1
return @map[point.y+1][point.x]
end
def left(point)
return -1 if point.x-1 < 0
return @map[point.y][point.x-1]
end
def right(point)
return -1 if self.width <= point.x+1
return @map[point.y][point.x+1]
end
end
map = Map.new(maze)
#puts "width×height = #{map.width}×#{map.height}"
#puts "start:#{map.start} / goal:#{map.goal}"
map[map.goal] = 0;
#puts "goal=#{map[map.goal]}"
# 先端
nodes = [map.goal]
while node = nodes.shift
next if node == map.start
[node.left, node.right, node.up, node.down].each{|nxt|
case(map[nxt])
when -1
# 壁
when nil
# 未踏
map[nxt] = map[node] + 1
nodes.push(nxt)
else
# 既に到達したルートがある
if(map[node] + 1 < map[nxt])
map[nxt] = map[node] + 1
nodes.push(nxt) unless nodes.include?(nxt)
end
end
}
end
# Map to result
map.height.times{|y|
map.width.times{|x|
point = map[Point.new(x,y)]
print point == -1 ? '***' : ("% 3d"%point)
}
puts
} if false
result = maze.strip.split(/\r\n?|\n/)
node = map.start
until node == map.goal
[node.left, node.right, node.up, node.down].each{|nxt|
if(map[nxt] == map[node] - 1)
node = nxt
result[nxt.y][nxt.x] = '$'
break
end
}
end
puts result.join("\n")
ノードっていうのはひとマスのこと。「先端」っていうコメントが適当すぎる(植物では頂端分裂組織っていうらしい)。方針はゴールからスタートに向けて、一マス移動するごとに一ポイントを加算しながら全方位に触手を伸ばしていき、すでに他の触手が通過した道は、自分が最適な場合にのみ侵入するこの判断は不要。全ての触手が行き場を失うかスタートに到達するかしたら終了。スタートから一ずつ減っていく数字をたどると(一少ない数をもつ隣接マスが二つ以上あっても解答に求められていないので無視する)ゴールへ着き、それが最短経路(だったらいいな)。
最初は粘菌方式をまねようと思ったが、通路をすべて覆った状態からスタートして、スタートとゴールにつながっていない島を切り捨て、袋小路から撤退するのはいい。遠回りと近道を取捨選択するためにどういう評価をすればいいのかを決められなかった。どうすればいいの？粘菌は何を考えてる？例えば
二番目のリンク先のトラックバックを見てる。みんな優秀なのね、C++で一時間もかかってないし。何人かが言及している「BFS」。それって一般的知識？ 幅優先探索(Breadth-First Search)か最良優先探索(Best-First Search)の略だということはわかった。
壁のもつポイントを -1 に設定したことで、壁に侵入しないことを保証する when節を省略してもよかったんじゃないだろうか。気付くのが遅れたが。
ゴールにも $ って書き込んでら。(スタートには書きこまんように気をつけたんだが)
粘菌すごい。
培地に、三個以上の餌を置く。粘菌は迷路の実験のように最短距離を結ぶか？
結果は違った。
粘菌は、丸く、複数の経路を持つ管を作った。「最短経路だと一カ所故障したら必ず孤立する場所が出ます。だから粘菌は、一カ所が故障しても全体はつながり、なおかつ距離がなるべく短い経路を作ったのです」
部分部分がどういう反応をするとそういう結果になるんだろ？？？
粘菌の行動原理は、量子ドット間の近接場光を介したエネルギー移動プロセスに類似している
最終更新: 2010-04-04T06:25+0900
そんなあなたに、とある科学の超電磁砲の 4巻はいかがでしょう。俺はこの巻を読んで、作者は冗談では済ませられない、のっぴきならない一歩を踏み出したと感じた。まだ失望してもムカついてもいないが、危ういものを感じながら 5巻を待っている。
♭ BorsJoigreeBS GE VC KX LJ UZ ZY RW MS IS ML JE AL FWUN BR EJ AV DD XQ..
♭ ds14050解析班はどこだ？