nDiki : 文法
スポンサード リンク
Related term
2004年2月11日 (水)
■ [ DiKicker ] hnsからのコンバータ作成開始 
DiKicker のコードを書いている途中に「やっぱ先にデータがある程度ないとな」ということで、hns からのコンバータを作り始める。
hnfの文法は非常にシンプルなのでコンバータの作成が簡単(RTをのぞく)。 あらためて感心。
@ RT のスパン記号
||、== で上、左のセルと結合できるのか。 WiKicker にも欲しいな(| はセル区切りに使っているで、別の記号にする必要があるけど)。
- やっぱ hns (2003-11-20)
- WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
- 社内 Blog 開設 (2006-05-16)
- [ WiKicker ] WiKicker へ脚注機能追加 (2004-02-10)
- 最近の Twitter ステータスを nDiki 「最近のさえずり」ページ... (2007-11-23)
2004年5月11日 (火)
■ 文法の動的変更可能な言語 
昔研究していたネタ。 やまだ君のまわりで同じようなネタでちょっぴり盛り上がっているらしい。
実用度はかなり微妙だが、できると結構楽しい言語になると思うんだけどな。
動的変更可能な言語仕様記述言語で「言語仕様記述言語を動的に変更しつつ」「動的に変更可能な言語を定義する」といったことも当時考えていたっけか。
- 近谷研OB会代替OFF会 (2004-03-20)
- 早速 reStructuredText から LaTeX へのコンバータを書く (2005-11-24)
- 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
- 準備委員会キックオフミーティング (2005-11-19)
- m4s tkh再会新年会 (2005-01-06)
2005年5月10日 (火)
■ iモードHTMLシミュレータ Version 7.2 
iモード向けの簡単なCGI プログラムの開発を社内で頼まれているので、動作・レイアウト確認用にシミュレータを探してみる。
あら、NTTドコモで配ってらっしゃる。 ということでダウンロード。昔633S用につくったiモード向けページなどを閲覧してみる。
機種別のプロファイルのようなものはなくて、自分で画面サイズやiモード対応HTMLバージョンの選択をしてあげる必要があるけれど、HTTPヘッダのチェックやHTMLのソース表示、文法チェック機能などがあり今回はこれで充分いけそうだ。
- 633S ファーストインプレッション (2001-12-10)
- さよなら PHS (2007-02-10)
- 私的10大ニュース2005 [ comp ] (2005-12-31)
- 22:00 画像サイズと名前 (2002-01-20)
- GanttProject で開発スケジュールを作成 (2004-08-26)
2005年9月13日 (火)
■ [ WiKicker ] hell mode - HTMLタグ付けブロックの導入 
WiKicker では、直接 WikiPage にHTMLタグを記述して表示に反映させる機能を提供していない。
@ HTMLタグ付けを許すのは嫌だ
HTMLタグ付けを許すと
が起きやすくなるし、ページのソースの単純さが大きく失われてしまう。 レンダリングしてHTMLにした時に、正しいHTMLを出力されることを保証することが困難になるとともに、HTML以外へのレンダリング/コンバートもかなり難しくなる。
この機能を導入すると、Wiki の良さの半分(あるいはもうちょっと沢山か、もうちょっと少なめ)が失われてしまう。
@ でも
とはいえ欲しいという声があることも事実。 オープンな WikiForum では全くお勧めできないが、閉じたユーザグループの中ではまぁ必要悪なのかもしれぬ。
また正直ちょっとした表現を追加したい時に、WiKicker 用のプラグインを書くのも面倒だというのは確かにある。
WiKicker では開始・終了マーカによる複数行にまたがるブロックを表すための文法は(閉じ忘れを避けるため)意図的に排除してある。 このため、複数行にわけて書きたいような長いデータを扱うような拡張も導入しにくい。
ちょっと手抜きして「生HTML書けちゃえば」という誘惑はなくはない。
@ 大人の事情
ということでまあ自分に言い訳をしつつ、標準ではオフというかたちで HTMLタグ付けブロックを導入することにした。 スイッチは hell mode とかにしたい (今回は syntax.html というプロパティ名にしたけれど)。
記法は単純に、
normal wiki syntax text... <html> html tagged text... ... </html> normal wiki syntax text...
のように行頭が <html> である行から、行頭が </html>である行までをHTMLタグ付けブロックとすることに。 このため、<html>ではじまる段落が書けなくなるという小さな非互換が発生するが、いたしかたない。
@ サニタイズ
HTMLタグを直接使えるようにするとはいえ、全てを許してしまうのはあまりに危険で非人道的すぎる。 有効なHTMLタグや属性は限定的であるべきだ。
このあたりの処理は面倒だが、幸いにしてCPANにモジュールがある。 今回は HTML::Scrubber を使うことにした。 HTML::Parserを使って parse し、指定したルールに従ってサニタイズしてくれる。
ちょっと使ってみた範囲では日本語(UTF-8、UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。
ということで、これを採用することに。
どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。
- Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
- WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
- [ WiKicker ] form/list の paragraph から... (2003-05-03)
- Wikiの文法の標準化 (2004-02-10)
- 無制限 HTML タグ付けブロックを使って nDiki に Google ... (2007-08-23)
2005年11月21日 (月)
■ 定型書式で内容を記述していくのに便利な形式は? 
今要求仕様書を LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。
文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。
- LaTeX + マクロ
- 整形は綺麗。
- 記述が繁雑になりがち。\マクロ名とか {} とか。
- DocBook
- 仕様デカスギ
- 以前使ってみたことがあるが、手で書くのにはしんどい。
- XML
- 構造的な情報の表現には良いのだが、手で書くのはしんどい。開きタグも閉じタグも。
- 普通の章節や、マークアップのルールを考えなければならない(定義するか借りてくるか)。
- LaTeX等へのコンバータを書く必要あり。
- YAML
- レコードの並びだけだったら良いが、文書の他の要素を一緒に書くのには適さない。
- ある程度の構造やボリュームがあると、思ったほど手書きしやすくない。
- YAML Perl モジュールで痛い目にあっている。
Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。
構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも充分読み易いことを意識して定義されているので書くのは楽。
- reStructuredText
- Markdown
- reStructuredText よりもソーステキストが読み易いらしい。
- Perl
- HTMLへの変換しかない。
- WiKicker (Wiki)
- かなり書き慣れている。
- レコードの並びの書き方を考える必要あり。
- 複数行にまたがる処理を書くのが面倒。
- 自分で書いているシステムなので中身は何でも知っている。
- マイナー。
レコード部分とは関係ないけれど reStructuredText や Markdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールやプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。
要求仕様書用に使うかどうかは別として、要チェック。
- 早速 reStructuredText から LaTeX へのコンバータを書く (2005-11-24)
- Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
- reStructuredText いいんじゃない? (2005-11-22)
- 私的10大ニュース2005 [ comp ] (2005-12-31)
- WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
2005年11月24日 (木)
■ 早速 reStructuredText から LaTeX へのコンバータを書く 
要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText の文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。
まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。
Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredText を XML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。
最低限のものができて、早速コンバート。
これで生 LaTeX で書くより随分楽になった。よし。
- 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
- Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
- JavaScript でのプログラミングやっぱり面倒くさい (2006-07-23)
- Docutils の reStructuredText から LaTeX ... (2005-12-07)
- Progect -> XML -> text, HTML (2004-04-16)
2005年12月31日 (土)
■ 私的10大ニュース2005 [ comp ] 
今年は主に開発等よりもオンラインサービスの活用が中心的な話題であった。 来年度は、積極的に何かを産み出していきたところである。
@ Skype
年初はまずは Skype。
社内でも本社との連絡に活用されるようになった。
これほどツールがスムーズに社内に広まるのは珍しい。
社内といえば、やっと Wiki の利用が社内で広まってきた。今後より利用が進むといろいろ不満も出てくるはず。 それをうまく吸い上げていくことが重要。
@ ソーシャルブックマークサービス
Squrl を使いはじめて、はてなブックマーク1本へ。 2月のサービス開始から使いはじめてブックマークの数は 3,337。
folksonomy という観点では folk (folc / people) を実感できなかった。 タグは主に自分で分類するのに使っているというところ。
@ Flickr
2月に使い始めて、5月に Pro Account へ。 これで www.naney.org の容量を気にしなくて良いようになった。
@ Bloglines
RSS を発行しているサイトの巡回は Bloglines へほぼ集約。 斜め読み化が進んだ。
@ reStructuredText
可読性の高いプレーンテキストマークアップ文法。
この文法で書いておけば、メールでやり取りをしてまとまった内容をそのまま書き換え直さずに、小綺麗に整形してHTMLやPDF形式にすることができる。
ちょっとした文書の作成にもってこい。
今後環境整備や、自分なりの運用スタイルの確立がポイント。
- 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
- Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
- Bloglines に巡回先の一部を集約 (2005-02-13)
- reStructuredText いいんじゃない? (2005-11-22)
- Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
2006年5月16日 (火)
■ 社内 Blog 開設 
ウェブ進化論の中の Google の話に触発されて、そのうちやろうと思っていた社内 Blog の開設を行ってみた。
@ DiKicker を使用
ソフトウェアは nDiki で使用している DiKicker を。 コメント機能・トラックバック機能が無いためコラボレーション的な要素はあまり望めないかもしれないが、RSS フィードもあるし社内情報発信のとっかかりとしては十分かと。
そのかわりにキーワードで串刺し表示する機能を使ってプロダクト名やプロジェクト名など決まったテーマをまとめて読み進めることができるため、社内利用には向いているのではと考えている。
検索機能が無いのは痛いので、早めに手当てする必要あり。
@ 運用
特に全社的に強制導入とかではなくて、まずは自分が試行錯誤しながら運用してみるといった感じで進めるつもり。 自分がガンガン情報を書いて、メールに permalink を貼りつける。
メンバに定期的に見てもらうには、随時小ネタをしこむ必要があるかなぁ。 他にも書く人が現れて、社内での RSS 活用が進めばしめたものである。
ちなみに各人が使うのは DiKicker にこだわるつもりは全然無くて、適当に設置してくれればと考えている。 DiKicker 社内で使っている Wiki (WiKicker) と同じ文法とはいえ細かいところは便利じゃないので、むしろ違うものが流行ったほうがいいかなとも(数人は一緒に DiKicker を使ってくれると嬉しいけど)。
ある程度 alpha な人が開設し揃って波がおきたら、普通の人でも簡単に書けるような環境を整備してより広めていきたい。
- Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
- Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
- すべての情報を共有する。情報閲覧者が判断する。 (2006-05-15)
- Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
- 最近の Twitter ステータスを nDiki 「最近のさえずり」ページ... (2007-11-23)
2007年4月3日 (火)
■ WiKicker に JSON でのページ出力機能を追加 
最近は DiKicker ばかりに手を入れていたが、久しぶりに WiKicker の改良も行っている。 しばらく前から実装を始めていた JSON 形式での出力機能が今日完成。
今までは WikiPage について
という2つの出力形式を持っていたので、JSON が加わることで3つめとなる。
@ サーバ側で WikiPage の構文解析まではやる
クライアントサイドの JavaScript でページの内容に合わせて様々な処理をできるように、サーバ側で構文解析まではしてあげるというのが主な目的。
JavaScript でまたパーサを書いてメンテしていくのも大変なので、その部分はサーバでやってしまおうかと。 構文解析した結果の解析木を JSON 形式で返して、JavaScript 側であとはお好きにという形。
@ CPAN にある JSON モジュールを使用
サーバ側の Perl プログラムには、構文解析をして解析木を作れるようになっている。 この解析木から Visitor パターンで JSON 形式を生成していく。
依存モジュールを増やすことを避けるべく、最初は自前で JSON 形式に変換していこうと思ったのだがやっぱり面倒だった。 ということで CPAN にあるモジュールをチョイス。
JSON 関連では JSON、JSON::Syck、JSON::PC などがあるが今回はインストールのしやすさを考えて pure Perl モジュールとして実装されている JSON を採用することにした。
Visitor クラスで解析木を無名ハッシュ/無名配列のツリーに変換して、JSON モジュールに流しこめば OK。
use JSON; my $json = JSON->new(pretty => 1); my $js = $json->objToJson($tree);
WiKicker のフレームワークにはフォーマット別に出力を切り換える機構があるので、これに JSON を追加して application/json で送るようにして完成。
ちなみに残念ながら JSON 1.07 は Perl 5.005_03 では make test が fail するので、NaneyOrgWiki では使えない。
- Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
- [ WiKicker ] hell mode - HTMLタグ付けブロックの導入 (2005-09-13)
- WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
- 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
- 最新の Module::Install は Perl 5.005_03 ステ? (2006-04-29)
2007年11月23日 (金)
■ 最近の Twitter ステータスを nDiki 「最近のさえずり」ページに自動表示 
11月9日から「Twitter ステータスを nDiki サイドバーに表示」しているのだが、それで使っているスクリプトにちょっと手を加えて「最近のさえずり」という nDiki ページを自動生成/更新するようにした。
サイドバーは RSS フィードと同じく最近の20件を表示するのに対し、最近のさえずりページには数日分表示するようにした。
ここ最近は Twitter のステータスをとりまとめて、ライフログ的に nDiki に上げているのだが、今までは Twitter Web ページやサイドバーの部分から手作業でコピーして日時やリンクを整形していたので面倒であった。
今回の(30分毎に)自動更新するページは最初から WiKicker / DiKicker 用の Wiki 文法で出力している。 なので、これからはこの自動生成ページから必要なものだけを抜き出して貼り付ければよい。 これで楽ちんになるはず。
ほぼ自分用。自己満足。
- Twitter ステータスを nDiki サイドバーに表示 (2007-11-09)
- 社内 Blog 開設 (2006-05-16)
- WiKicker / DiKicker の AutomaticLink 長... (2007-03-01)
- はてなブックマーク上の検索結果を nDiki に (2005-10-30)
- クリッピングに便利な CMS 「Tumblr」を使ってみる (2007-04-13)
スポンサード リンク
■よく検索されるキーワード
torrent(109) x31(45) thinkpad(31) 動画(29) 提案書(26) mp980(24) 手帳(24) windows(23) linux(23) 画像(21) 使い方(21) リフィル(21) debian(20) usb(20) tc-1(19) perl(19) 筆まめ(18) 壁紙(17) ほぼ日手帳(16) 冷蔵庫(14) ドラマ(13) wiki(13) 書き方(12) ダイソー(12) システム手帳(12) 宮根誠司(12) ノート(11) so905ics(11) 無印(11) バッグインバッグ(11) 映画(11) 設定(10) 修理(10) 宮根(9) ssh(9) a6(9) ほぼ日(9) 黒田征太郎(9) バッグ(9) gmail(8) 感想(8) 娘(8) f-01a(8) メモリ(8) gtd(8) ブログ(8) nikon(8) allinanchor:*.torrent(8) ボールペン(7) 方眼(7) ポイント(7) 4c(7) ヨドバシカメラ(7) ケース(7) twitter(7) apache(7) ht-01a(7) ヨドバシ(7) ubuntu(7) truecrypt(7) n-02a(7) 作り方(7) minolta(7) af(6) インストール(6) ガントチャート(6) mp3(6) zippo(6) hdd(6) emacs(6) レビュー(6) カバー(6) vq1005(6) 日本語(6) ハクキンカイロ(6) 無印良品(6) グレゴリー(6) 交換(6) nikkor(6) pixus(6)■注目キーワード
購入 買った 発売日 フリー 無料 価格 値段 作り方 選び方 使い方 方法 設定 サンプル ダウンロード 限定 在庫 予約 穴場 比較 検証 レビュー 感想 評価 評判 使用感 使ってみた 口コミ 噂 最新 MP3 動画 意味 お薦め お勧め おすすめ 便利 Blog ブログ mixi 修理 デザイン ビックカメラ
Process Time: 0.0600349999999999s / load averages: 0.13, 0.17, 0.20
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)
スポンサード リンク