にしし らぼらとりー

/usr/bin/perl と /usr/local/bin/perl とでPerlのバージョンが異なるというケースもあるのか。ロリポップの「eco7xx、eco8xx、lit7xx、lit8xx、std7xx、std8xx、ent7xx、ent8xxのサーバーの場合」だとそうなっているようだ。

さっき、『「ここ本当に変更して大丈夫なのか」みたいな疑問』と書いたが、よくよく考えるとそういう疑問が出るケースはあまりない。コメントがたっぷりあるので、だいたいの役割は分かるから。それよりもよくあるのは、「書き換えるのは本当にここだけで充分なのか」みたいな疑問だ。ソースがスパゲッティすぎて、1つの機能を実現するための記述が1カ所に留まっていない場合がよくある。「ここを書き換えるなら、あっちも同時に書き換えないといけない」みたいなケースがあって（そういう箇所はまさしくリファクタリングすべき箇所なのだが）、そういうのを見逃していないかどうかの確認が必要なケースがよくある。

設計はほぼナシの、思いつきだけでちょくちょく機能を増やしてきたツールなので、ソースがスパゲッティすぎるのよな……。「ここ本当に変更して大丈夫なのか」みたいな疑問は、やってみて動かしてみて確かめる、という方法しかない。さすがになんかちょっとリファクタリングをする方が良いとは（ずっと）思っているのだが、リファクタリングは重い腰を上げてするものではなくて、もっと頻繁にやっとかないといけないものだよな……。あまりにもソースが絡まりすぎると、もはやリファクタリングする気力が出なくなる。「オブジェクト指向？ナニそれ」というソースだしな。久しぶりにソース量を確認したら17,636行あった。よく書いたな……。まあ、ざっくり3割くらいはコメントだと思うけども。コメントは本当に潤沢に書いておかないと未来の自分がソースの意味を把握できなくなるので、過剰気味に書いておかないと開発が続けられなくなる。

今のカスタマイズ方法ページに掲載しているリファレンスはやはり見やすいとは言い難いので、なんか専用記法だけを独立させた（PDFとかで）「てがろぐカスタマイズ・チートシート」みたいなのを作った方が良い気がしている。

次のβ版は、明日（もう今日だが）には出せる予定である。今回はほとんど、スキンを自前で大きくカスタマイズする方々向けの機能ばかりだけども。それを配布したあとは、画像管理機能の強化に進みたい。たぶん11月のてがろぐ開発はそればっかりになる気がしている。

INCLUDEされたファイルの中からでも、さらにINCLUDEの記述を可能にした。ただし3階層（3重）まで。別に何階層でも単にループすれば良いだけなので処理は簡単だが、同じファイルを呼び出して無限ループにはならないように。3階層もたどれば充分だろう。「複数のスキンで埋め込みたい一連のファイル群を1つのINCLUDEファイルにまとめておきたい」みたいな需要は、2階層で充分満たせるだろうから。

いま実施中のアンケートの自由入力欄で、『INCLUDEしたファイル内に [[CALENDAR]]、[[DATEBOX]]、[[LATESTLIST]] 等を書いても埋め込まれないが、[[SEARCHBOX]]、[[CATEGORY]]、[[HASHTAG]] は反映された。全部反映されるようにして欲しい』という感じの要望を頂いた（※表現はもっと丁寧だった）。そういえば、そのような動作になる可能性もあった（そうならない場合もある）。その点もソースを修正したので、次のバージョン(β版)からは、どの記述もすべて（INCLUDEされたファイル内でも）使えるようになる。

代替文字とキャプションを画像管理画面で登録できるようになるなら>>2238、投稿本文内に代替文字やキャプションを含ませる必要はないわけだから、No.2212みたいな複雑な記法は必要なくて、単に [PICT:FIG:ファイルパス] みたいな感じだったら登録済みの代替文字とキャプションを使って figure要素＋img要素＋figcaption要素を出力する……みたいな処理でいいか。もし引数FIGがなくて [PICT:ファイルパス] だったり、引数にFIG以外の文字列が指定されている場合 [PICT:ぶひぶひ:ファイルパス] だったら、従来通り img要素だけを出力すれば良いわけで。