nDiki : 2005年11月下旬

2005年11月21日 (月)

定型書式で内容を記述していくのに便利な形式は?

要求仕様書LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。

文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。

  • LaTeX + マクロ
    • 整形は綺麗。
    • 記述が繁雑になりがち。\マクロ名とか {} とか。
  • DocBook
    • 仕様デカスギ
    • 以前使ってみたことがあるが、手で書くのにはしんどい。
  • XML
    • 構造的な情報の表現には良いのだが、手で書くのはしんどい。開きタグも閉じタグも。
    • 普通の章節や、マークアップのルールを考えなければならない(定義するか借りてくるか)。
    • LaTeX等へのコンバータを書く必要あり。
  • YAML
    • レコードの並びだけだったら良いが、文書の他の要素を一緒に書くのには適さない。
    • ある程度の構造やボリュームがあると、思ったほど手書きしやすくない。
    • YAML Perl モジュールで痛い目にあっている。

Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。

構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも十分読み易いことを意識して定義されているので書くのは楽。

  • reStructuredText
    • いいらしい。
    • HTMLLaTeXXML へのコンバータがある。
    • 拡張性も考慮されているらしい。
    • でも Python
  • Markdown
  • WiKicker (Wiki)
    • かなり書き慣れている。
    • レコードの並びの書き方を考える必要あり。
    • 複数行にまたがる処理を書くのが面倒。
    • 自分で書いているシステムなので中身は何でも知っている。
    • マイナー。

レコード部分とは関係ないけれど reStructuredTextMarkdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。

要求仕様書用に使うかどうかは別として、要チェック。

スポンサード リンク
[ 11月21日全て ]

2005年11月22日 (火)

reStructuredText いいんじゃない?

昨日の続きであるが、reStructuredText がライトなドキュメント書きにはいいんじゃないかという感蝕を得た。

基本的にプレーンテキストのままで十分見られるので、そのままメールに貼りつけられる。

今までは文書を作成する際、メールで草稿をやりとりしたのち内容が固まったら LaTeX のコマンドでマークアップしてコンパイルしてPDF化していた。 これだとちょっと手間であるのだが、最初から reStructuredText 形式で書いていれば、そのまま rst2latex で LaTeX に落とせる。

また必要に応じて rst2html で HTMLに変換してWebサイトに置いておくこともできる。

これらで満足できない場合は Python のコードをいじって変更ということになるが、Python が駄目でも rst2xml でXMLに変換してしまえば他の言語でも reStructuredText のパーサを書かなくても(XMLの処理系を使って)コンバータを書くことができるの比較的楽である。

しかも欲しかったレコードの表現用にフィールドリストというシンタックスがあるではないか。

いいじゃん。

ということで早速今日から使うことにした。

Debian GNU/Linux sid にある Docutils 0.3.9 ではいわゆる全角文字も文字幅を1として扱かう。 このためテーブルなど桁揃えを用いる書式の部分がこのままだと不便である。 画面上では2文字分幅があっても1文字として数えられるため Docutils が通るようにするためには余計な空白などを入れて文字数を調整しなければならないが、そうすると今度は見た目的にずれるので可読性がかなり落ちてしまう。

この問題のためにMatsumoto,Tadashi氏がパッチ

を作成されているので、これを適用。

これでばっちり。

いい夫婦の日にボジョレー・ヌーヴォー

naney:66136540

明日は休日だしということで、買っておいたボジョレー・ヴィラージュ ヌーヴォーを開栓。 今年は3年前と同じラベル種ワイン

今回のお味であるが、それほど炭酸味はなくフルーティ感もあまりない気がする。 1杯目の半分ぐらいまではよかったけれど、その後があまりすすまず。

[ 11月22日全て ]

2005年11月23日 (水)

ON SUNDAYS で本を眺めつつヘーゼルナッツラテ

naney:66136568

栗原はるみ すてきレシピ37号で「ワタリウム美術館のミュージアムショップ ON SUNDAYS」にあるカフェが紹介されていて、ぜひ行ってみたいと思っていた。

今日神宮外苑に出たついでに足を運んでみた。 銀座線外苑前駅からだと青山通り渋谷方面へ進んで、青山ベルコモンズで曲がって外苑西通り(キラー通り)へ。で最初の信号のところ。

神宮外苑前から向かう際、間違えて手前の外苑前交差点で曲がってしまってタイムロス。 痛恨のミス。

ON SUNDAYS は(当然であるが)アート系の商品をそろえたショップ。 地下では FREITAG(フライターグ)の全商品を12月30日まで期間限定で販売中。

地下へ降りる途中にあるちょっとしたスペースにあるカフェでは、アートな気分を味わいながらくつろぐことができる。 座席数は少な目。 ヘーゼルナッツラテを飲みながら、ぼんやりと階下を眺める。

ON SUNDAYS の商品の方はかなりマニアックだったので、自分にとってはぶらっと何かを買いにくるといった感じではなかったかな。 近くを通ったらまたカフェには寄ってみたい。

帰りは千駄ヶ谷まで歩こうかと思って外苑西通りを北上したら、これがまた遠いのなんの。 11月下旬ともなると日が暮れるのも早く、明治公園・国立霞ヶ丘競技場のあたりではもう随分暗くなって寂しい限り。 またもや痛恨のミス。

大江戸線の看板を見つけ、そのまま吸い込まれて国立競技場駅で地下鉄にのって帰路へ。

naney:66136562

平成17年第9回神宮外苑いちょう祭りで豚の串焼き

naney:66136554

勤労感謝の日。 都合が良い年は、神宮外苑の銀杏並木を見にいくことにしている(いくことにしているというほどは行っていないが)。

F3/T を肩に下げて数年ぶりに神宮外苑へ行ってみた。

ここ数年11月23日だと、色付きが少ないように感じているがどうだろう。 今日もまだまだ緑色の葉が多く、落葉も舞うというほどではなかった。 近年、街中で見かける銀杏が黄色くなることなく散っている気がするのだが気のせいだろうか。

この時期、神宮外苑ではいちょう祭りとしてお店が出ている。 以前きた時は噴水の奥のグランドではスポーツ大会をやっていたと記憶しているが、今日はその奥にもテントが並んで食べ物や茶碗などが売られていた。

豚の串焼きと焼きそばで昼食がわり。 豚ウマ。

[ 11月23日全て ]

2005年11月24日 (木)

早速 reStructuredText から LaTeX へのコンバータを書く

要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。

まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。

Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredTextXML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。

最低限のものができて、早速コンバート。

これで生 LaTeX で書くより随分楽になった。よし。

[ 11月24日全て ]

2005年11月25日 (金)

パーティ日程ほぼ確定

先生のご都合が確認できたとのこと。

これで本格的に準備開始。

[ 11月25日全て ]

2005年11月26日 (土)

仕事のヒント

rimage:ISBN:4894512041

Web で紹介されているのをみて「仕事のヒント (神田昌典)」を昨日買ってみた。

すごいやり方」と同じく、1ページに1項目がババンと書いてあるスタイル*1

短いのでぱぱっと読める。 いや、読んで終わりというタイプの本ではなくて定期的にぱっと開いたページから新しい発見を得るというタイプである。 そういう意味では、リラックマ本も同列だったりする。

この本、表題は「仕事のヒント」であるが

  • 第1章 モノを売るヒント
  • 第2章 経営のヒント
  • 第3章 生き抜くヒント

という構成であり、どちらかといえば経営やマーケティング的な視点が多い(実はてっきり仕事術のような本かなと思って買ったのだったりする)。 しかしながらソフトウェア研究開発をしている自分にとっても、ハッとするヒントが盛沢山であった。 新しい企画提案をする際には本書を見返して、ポイントを外さないでいくようにぜひしたい。

特にベンチャーや中小企業の人にお薦めだ。

 売れない理由のトップは、
 「わかりにくいから」
 p.34, 神田昌典

あちゃー、耳がイタイ。

この本はかなりエッセンス的なもので、神田氏の本にはまだまだいろいろ書かれているらしい。 今度ぜひまた別の本も読んでみたい。


[ 読書ノート ] [ お薦めの本 ]

*1すごいやり方は、解説が次のページにあるので正しくは2ページに1項目)

ほぼ日手帳の秘密

naney:67051014

マーケティング戦略にまんまとのっかってしまっているとわかりつつ、神保町三省堂で購入。

巷に溢れる手帳術本とは違って、「目標達成のための秘訣にせまろう」などと気張らずに読み物として楽しめる。

手帳というと、ときどきビジネスとプライベートをどう書き分けるか(どちらかだけにするか、混在させるか)について思い悩んでしまったりする。 PDA だとカテゴリ別に表示を切り換えることができたりするが、紙の手帳ではそうはいかない。

その、おおもとのところをいえば、「仕事」と「個人」というのは、決して敵対しているわけじゃないということです。 (中略) 入り組んでて当たり前だと思うんです。-- p.30

でも、まあ仕事もプライベートもどちらも自分にとって人生の一部なんだから切り分ける必要はないのかもしれない。

それから、目の前でほぼ日手帳に書き込んでいるのをみるとなぜだかビーム*1したくなる。 ほぼ日手帳巻末の「この手帳についていないもの」の一覧に赤外線ポートを追記しておきたい。


[ 読書ノート ]

久しぶりに神保町をぶらぶら

のリクエストで今日は神保町に出かけることにした。

神保町は、中学生の頃は自転車でちょくちょくきていた(中学生に電車代はもったいなさすぎた)。 高校時代は三田線で。 浪人時代は……中央線で。 まあ、そこそこ馴染みのある町ではる。

本屋三省堂書店・文房堂・三省堂書店 自由時間などを巡る。 三省堂書店 自由時間にある「上島珈琲店 神田神保町店」で一休みしたのだが、便利な場所だしセルフサービスの気兼ねなく入れるお店だしとなかなか使えそうな感じで。

[ 11月26日全て ]

2005年11月27日 (日)

方眼手帳と方眼ミーティングメモ

naney:67408112

ほぼ日手帳の使い道であるが、Palm でやっているスケジュール管理をこちらに持ってこようと思う。 スケジュールと、あとログ。

さて、そうとなったら書き方だ。 せっかくなので、何か自分流のスタイルで方眼上でびしっとキメてみたい。

方眼といえば RHODIAミーティングの議事メモなんかは RHODIA No19 にカリカリと書いている。 メモ毎に方眼上にチェックボックスを書いておき、ミーティングが終わったら Palm にスケジュールやアクションを転記したり、その場で処理したりしてそこにチェックを入れていって全部チェックできたらオシマイ。

ここでちょっともやっとしているのが「何でもかんでもチェックボックス」にしている点。これだと処理の必要のない項目までチェックボックスになってしまっており、後でチェック印がはいらないのですっきりしない。

ということで、ミーティングメモも含めて共有の俺スタイルを考えてみた。 基本的にはチェックボックスを踏襲することにした。

種類マーク

チェックボックスの前にマークをつけて区別

  • 「→」アポイントメント
  • 「C」コミットメント
  • 「A」アクション (To Do)
  • 「W」待ち
  • 「I」情報
  • 「!」思い浮かんだこと。
  • マーク無しは大項目、あるいはスケジュール欄における「→」の省略
  • (→、C、A、W は要処理なので○で囲む)

写真撮ってから、→にも○があった方が整合性があることに気がついた。

処理マーク

チェックボックスに入れるマーク。

  • 「レ」完了
  • 「→」転記済み (将来のスケジュール欄、Palm 上の GTD、プロジェクトファイル等へ)
  • 「×」削除 (キャンセル他)
  • 「-」アクション不要

アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。

その他

  • UMLのアクターアイコン + 名前リスト」議事メモにおける出席者。
  • UMLのアクターアイコン + 名前 + 時間」発言、コミットした人の名前と時間。
  • 「スケジュール欄のスケジュール項目名の後に(MM/DD)」アポイントメントを取ったときの日付(TQ に書かれているテクニックより)。

とりあえずこんな感じ。

凡例を書いてほぼ日手帳の下敷きに貼り、しばらくはこれでやってみることにする。

私にとっての PDA の長所と短所

ほぼ日手帳Palm をどう使い分けようかと考えるために、自分にとっての Palm (主に DateBk5)の長所と短所を思いつくまま列挙してみた。

長所

  • 小さい (PEG-TJ25)
  • スケジュール
    • スケジュール変更が簡単。汚れない。
    • 定期的なスケジュールを自動処理できる (週毎・月毎・年毎・……)
    • アラームを鳴らせる
    • 数日前から予告表示できる
  • To Do
    • 繰り越し
    • 繰り返し
    • ビジネス / プライベートの切り換え

短所

  • 入力が面倒 (手間取ると会話の流れを止めてしまう)
  • (見にくくならない範囲で)1項目に書ける量が少ない
  • 開きっぱなし(つけっぱなし)にできない
  • 週間・月間表示に転記しなくても見られるのだけれど、1画面の情報量少なすぎて使えない

こうしてみると

To Do の繰り越し・繰り返しについては、文句なしに紙の手帳より PDA の方が強い。 紙の手帳だと付箋紙で繰り越し To Do を扱う方法があり、実際一時期やったこともあったが続かなかった(多いと邪魔なのと、だんだん糊が弱くなってくるのと、見た目がちょっとなのと)。飽きただけなのかもしれないが。

スケジュール管理(含む GTD の「日時指定の行動」)は、ほぼ日手帳へ移してもいいかもしれない。 それ以外は、ひとまず DateBk5 に留保だな。

[ 11月27日全て ]

2005年11月28日 (月)

にごり水だ。早く帰りたい。

今日の23:30 から「にごり水」である。

こういう日に限って帰りが遅くなる用事が入ったりするものである。 とっとと帰って食事を済ませ、風呂に入らねばならぬ。

結果幸いぎりぎり間に合った。セーフ。

で。

明後日もにごり水。 うちの近所は2連コンボでくる事が多い。 どこもそうなのか?

[ 11月28日全て ]

2005年11月29日 (火)

めざましマガジン Vol. 8 にしてやっともらえた

秋葉原駅前でも配っていたのだが、タイミングが悪かったりしてなかなか貰えないでいためざましマガジン。

この間ももらおうかと思っていたら、配布場所が悪かったのかスタッフが警備員のような人にに怒られているところでもらえずじまい。

そんなであったが、本日やっと手にすることができた。

中身の方は、うーん「めざまし」らしい記事はそれほど多くない。R25 を見慣れてしまうと紙も安っぽく感じるし、ちょっと期待外れ。

作っても自分の会社名が載らない

そういう仕組だとわかっていても、なんか虚しい。

[ 11月29日全て ]

2005年11月30日 (水)

ストーリーカードタスクカードを導入した開発の成果物を納品

naney:69018707

なんとか月内に発送できた。

今回はストーリーカードタスクカードを試験的に導入。 終盤ちょっとチェック頻度がさがってしまったという反省はあるものの、開発ペースがつかみやすくなったり、機能の実装漏れを防げたりと効果は十分あったと感じた。

その他、プログラミングについて互いに積極的に教えあうなどチームメンバそれぞれ学習できたという点でもなかなか良かったと評価したい。

チームの皆さまオツカレサマ。特に松下君オツカレサマ。

[ 11月30日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.048117s / load averages: 0.85, 0.74, 0.68
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker