Progect のデータを Palm::Progect で読み込んで XML::LibXML で DOM 化し、そのまま出力あるいは XML::LibXSLT を通して text や HTML に変換する方法を検討。
Progect のデータをそのまま欲しい形式変更するのが手っ取り早いのだが、プロジェクト中の抜き出したいタスクの指定方法や出力の整形方法の指定方法を定義するのが面倒なので XSLT で逃げようかと。 まぁ XSLT も書くの面倒ではある。
Palm::Progect::Converter::hoge を書くという手もあるが。
そのページにあった検索語を設定しておきたいのだが「Google AdSense プログラム ポリシー」によりコードの変更は認められていない。
ということで検索フォームを ID="SiteSearch" な div に入れておいて、 JavaScript から DOM で設定するようにした。
var ssdiv = document.getElementById("SiteSearch"); var element = ssdiv.getElementsByTagName("input"); for (var i = 0; i < element.length; i++) { if (element[i].getAttribute("name") == "q") { element[i].setAttribute("value", "ほげほげ"); } }
適当に書いたので、きっともう少しいいコードがあるはず。 Galeon、Mozilla だと問題出ていないがその他はまだチェックしてない。
www.naney.org だとTemplate Toolkit が動かない事がわかってしまったので、やっぱり手元で静的するセンにする。
今までは「XMLによるページ記述 + 自作ツールによる DOM ベースの変換 + XSLT」で生成していたのだが、あまりメンテしていないのでライブラリのバージョンが上がるたびに動かなくなったりいろいろ不便になってきた。 今後は現在いろいろいじっている Template Toolkit ベースにしたい。 まずは付属の ttree を使ったサイト生成にしてみる。
で、いくつかのページをこちらで生成してみることにした。 今までより出力を簡単に修正できるようになった。 ただし以前のXMLベースの時よりは崩れたHTMLを生成する可能性が高くなるので要注意。 GNU m4 でサイトを生成していた時の感じに少し戻った気分。
ユーザプロファイルをクリアしたついでに、インストールする拡張機能を整理してみる。
ブックマーク、Sage まわりその他がおかしくなったので、ユーザプロファイルを半年ぶりに作り直し。 拡張機能の整理(New は 前回から新たに使うようになったもの)。
要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText の文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。
まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。
Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredText を XML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。
最低限のものができて、早速コンバート。
これで生 LaTeX で書くより随分楽になった。よし。
この間やっつけでPerl で コンバータをちょっと書いたのだが、やはりここは正攻法で Docutils の Writer として書いておきたい。
Docutils に含まれている LaTeX2e Writer (docutils.writers.latex2e) のクラスを継承してカスタマイズ版を作ればいいかなと着手。 この Writer の生成する TeX ファイルがちょっと好みではないので、継承して自分好みの Writer を書いた上で、それを継承してドメイン毎の Writer を書く事にする。
Python でコードを書いたことはほとんどないのだがそれほど迷う点はない。 素直な言語なのかな。$ とか @ が出てこないのはちょっと寂しい。ブロックをインデントで示すので「閉じ」がなく、ちょっと「スースー」する。 わかる? この気持ち。
Docutils はパースした結果 DOM ライクなツリーができて、これに対して visit / depart 式の visitor を使って処理をしていけるようになっている。 そのあたりはフレームワークがあるし、典型的なパターンなので楽ではある。
ただし、docutils.writers.latex2e のクラスが継承されることを意識されている感じがしないので、メソッドをコピーして書き換えてオーバーライドといった事が必要になる箇所が思ったよりあるのがちょっと気になる。 今後バージョンアップした時に内部も変わる可能性があるだろうし、最終的にはごっそり Writer を作ってしまう方が良さそうだ。
JavaScript の勉強がてら「お互いに URL でリンクしている XML ファイルセットの簡易ブラウザ」を書き始める。
この間使い始めた Prototype を使って多少楽ではあるものの、それでもやっぱり面倒くさい。 コードを修正するたびに Web ブラウザで動作確認をするという流れが問題だな。
単体テストコードを書いて SpiderMonkey でテストできるかなと思ったが、document オブジェクトとかないし。
やはり JsUnit でテストを書くのが一番かな。
それと JavaScript (Web ブラウザ)の DOM API の情報がまとまっているものないかな。 Perl の XML::DOM の気分で書くといろいろ名前が違っていてうまく動かず、切ない。
一昨日、橋本大也氏の情報考学の記事「10月1日開催 Evernoteデベロッパーズミーティング@デジタルハリウッド大学大学院 秋葉原メインキャンパス」で、Evernoteの日本初のデベロッパーズミーティングが開催されることを知った。 会場が秋葉原で会社帰りに寄れるし、Evernote を利用している中で API についてもちょっと興味を持ち始めていたので、いい機会だと参加申し込み。 Evernote 遍歴を整理してみたり。
で、本日退勤後参加してきた。まだ若い企業であること・日本法人「エバーノート株式会社」も今年設立されたばかりであることなどもあってか、即席的だけれどフレンドリーな雰囲気のある、皆でこれから盛り上げていきましょう的な良い雰囲気の会であった。 Evernote 好き度ちょっとアップ。
以下ノート。
開会のメッセージ。
「Integrating with Evernote」
英語による発表。中島健氏が適宜通訳。
Evernoteサイトメモリー自体は思うところがあってまだ導入してみていなかったんだけれど、話を聞くことでサイトオーナーにもメリットがあることは感じられた。
OAuth も対応しているんだ。 また API を使えば Linux 版クライアントを作れる人は作れるんだな。
途中で Twitter ハッシュタグ指定が。 この時点で #EvernoteJP よりも多く Tweet れている #Evernote を推奨とのこと。
ENML については以前ドキュメントを読んだことがあるので流して聞く。
Android はやはり intent が強力だね。 今後新しい intent 対応があるとのこと。楽しみ。 個人的にははやくオフライン閲覧ができるようになってくれると嬉しい(すこし前のアップデートで準備段階としてキャッシュ機能が入ったのでもうすぐらしいんだけれど)。
デベロッパーズミーティングということで、ぜひ開発者の声をということで今朝プレゼンテーションを頼まれたとのこと。
初代 MacBook Air 用ディプレイ接続のアダプタを忘れたが、会場参加者にもっている人が貸してくれて無事プレゼンテーション。やはり Mac 率高い。
開発している iPhone RSS リーダに求められた「ニュース保存」に対応するために
と対応していった。Evernote の API 対応は1〜2日程度+テスト。工数少なく機能実装できたとのこと。メール送信によるノート新規追加を連携としているものが多いが、API 利用することでノート表示などもサポートできるという利点があるなど。
「Evernoteなう」
昨日のEvernoteデベロッパーズミーティングに刺激されて、この nDiki にサイトメモリーを導入。
まとめ記事で「Evernoteサイトメモリー自体は思うところがあってまだ導入してみていなかったんだけれど」と言うのは、「Evernote へクリップしてもみんながハッピーにならないんじゃない?」という思いから。 ソーシャルブックマークのように情報共有につながらないし、情報提供側にも伝わらない。Web サイト上でのアップデートがクリップに反映されないというのもある。
とはいえ、では自分はクリップしないのかというと結構クリップしてる。てへ。 「Web サイト上のページはいずれ消えて読めなくなる(場合が多い)」からやっぱり保存しておきたいというのと、必要な範囲だけ切り取っておきたいという気持ちから。 あとは直近で外から Evernote for Android で見たい時とか。
正直 Evernote で範囲選択してクリップするのって結構面倒なので、クリップする側に立てば、クリップボタン1発で適切な記事部分をクリップできるようになっているは便利だよね(実は押したことないけど)。 アフィリエイトプログラムも一応あるしね。
ということでこの nDiki にボタンを追加してみることにした。 実装的には、今の nDiki (DiKicker) にはクリップの単位に適した要素がないので、DIV 要素を追加。ID 属性に記事 ID を出すようにして、その DIV 要素内をクリップできるようにした。
ちょっとだけ余分なものが入るけど、思ったよりもいい感じにクリップされた(この記事の下の Evernoteサイトメモリーボタンを試してみて)。 追加するの思ったほど手間ではなかった。
ちなみにクリップに関して設置側で設定できる項目は以下。 Evernote.doClip メソッドのパラメータとして指定する。
クリップ内容については以下のどれかで明示的に指定できる。
クリップへの署名/ヘッダ/フッタも追加可能。
以上 Site Memory Developer Guide より。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。