nDiki : 書き方

• マニュアルの書き方
• ビジネス文書の書き方
  • 議事録の書き方
  • アジェンダの書き方
  • 提案書の書き方、企画書の書き方
  • 報告書の書き方
  • アクションプランの書き方
  • ビジネスプランの書き方
• 手帳の書き方
• 万年筆の書き方
• 論文の書き方
• 履歴書の書き方
• 仕様書の書き方
• 年賀状の書き方
• 招待状の書き方
• ミーティングメモの書き方
• メールの書き方
  • ビジネスメールガイドライン案
• 手紙の書き方
• ドキュメンテーションガイドライン

ソフトウェア Word メモ ほぼ日手帳 Perl GTD RHODIA 計画 Palm 日本語 ポイント 書評 開発 プリント プロジェクトマネジメント ノウハウ 提案書 インストール 正規表現 ソフトウェア開発 会議 箇条書き メモ術 PDA LaTeX2e 出張 KDE ほぼ日手帳2007 reStructuredText コミットメント

■ Perl で lex/yacc

最近 Perl で字句解析ルーチン生成系/構文解析ルーチン生成系を作ろうかな、などと考えている。 前にもやろうと思っていたのだが、なにもしていなかった。なぜ Perl でかというと、

• C/C++言語にはすでに存在する(flex/bison)。
• Perl にはいいものが存在しない(知らない)。
• flex/bison はC/C++のものしか生成できない。
• これは動的に生成し利用すること、また動的に変更することが考慮されていない。
• Perl なら実行時にサブルーチン定義したり eval できたりする。
• Perl なら気が楽。

などが理由であろうか。 また自分の研究で設計している言語を Scheme 上で実装しようかなと思っているが、その字句解析ルーチン生成系/構文解析ルーチン生成系が欲しい(あることにはあるが)。 一旦 Perl で生成系を自作しておけば、簡単に他の言語の解析ルーチンを生成できるように拡張できるであろう(と考えたい)。

動的な側面が念頭にあるのは、自分の研究がそういうことをやっているから。

とりあえず lex/yacc(flex/bison)互換/ライクなものを作る予定である。 これらはそれぞれ仕様記述のファイルを読み込んで解析ルーチン(解析用テーブル)を生成する。 ので、とうぜんこの仕様記述言語の字句解析ルーチン/構文解析ルーチンが必要である。 手で書いてもいいのだが、それも面倒だ。 当然字句解析ルーチン/構文解析ルーチン生成系が欲しい。 しかしまだない。 これから作ろうとしているものそのものだから。

方法としては、

• Perl で手書きで解析ルーチンを作る。それで Perl 用生成系の仕様記述を読ませて、置き換える。
• Perl の既存の生成系を使う。
• flex/bison を使って C/C++ 版を作成。その後その生成系で Perl 用生成系の仕様記述を読ませる。

などが考えられる。今回はとりあえず一番最後の方法をとろうと思う。 ただし実際には完全に C/C++ で作るのではなく、字句解析/構文解析ルーチンを flex/bison で生成し、それを Perlエクステンションとして、Perl から呼べるようにすることにする。こうしておけば、

• まずその Perlエクステンションで、Perl 用仕様記述を読んで Perl で記述された字句解析/構文解析ルーチンを生成する。
• Perlエクステンションでかかれたものを、上記生成物で置き換える。

とすることができる。最初のものを全部 C/C++ で書くと、解析ルーチン生成部を C/C++ と Perl で2回書かなければならないが、この方法ならその部分は Perl で書いておけるので2度手間にならないであろう。

ということ一昨日は flex のコードを眺めて、昨日は Perl エクステンションの書き方を調べてみている。 flex で吐いたファイルをそのまま Perl エクステンションのコードとは当然できないので、そのトランスレータをまず作ることする。

• Twitter ベイジアンフィルタプロキシ (2007-12-29)
• PerlでScheme実装 (2004-08-13)
• 久しぶりの C++ は GNU Automake + CppUnit で (2009-03-13)
• ハッシュとは (2004-06-09)
• 新入社員 (2004-04-16)

■ 過去の今ごろ

過去の5月7日より。

• CppUnit 1.9.10 + 河童 2.0.3
  • しばらく C++ でコード書いてないからだんだん書き方を忘れちゃいそう。新人君には TDD も覚えて欲しいなぁなんて思っているのだが、さすがにまだ早そう。

• Perl で lex/yacc (1999-01-20)
• 今日のさえずり - 会議室から「サクラ大戦」とか (2009-03-13)
• 今日のさえずり: 危うく宗教戦争が勃発するところだった (2010-07-16)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• 久しぶりの C++ は GNU Automake + CppUnit で (2009-03-13)

■ 内側から見た富士通「成果主義」の崩壊

成果主義・目標管理・ムラ社会・低能だけれど高給取りといった話。 人事制度の難しさがよくわかる。 もちろん制度だけではなくて、制定する人間や運用する人間の問題も。

会社の制度に疑問・不満があったら読んでみるといいかもしれない。 それからこれから制度をいじろうとしている会社の人達も。

もちろん答はそこには無くて、頭を使ってそれぞれの組織にあったものを考えていくしかないのだが、いろいろなヒントが得られるだろう。

ちなみに巻末付録2のリストラ年表に「2004・3 富士通ゼネラル、冷蔵庫事業から撤退」とある。 そういえば、数年前に実家で買い換えた冷蔵庫が富士通ゼネラル製だったなぁ。 この時は設置場所の寸法上、これしか選択の余地が無かったのだが。

• 内側から見た富士通「成果主義」の崩壊

@ 光文社ペーパーバックス

4. 英語(あるいは他の外国語)混じりの「4重表記」

これまでの日本語は世界でも類を見ない「3重表記」(ひらがな、カタカナ、漢字)の言葉でした。この特性を生かして、本書は、英語(あるいは他の外国語)をそのまま取り入れた「4重表記」で書かれています。これは、いわば日本語表記の未来型です。(p.5)

というシリーズの理念に従った体裁になっている。 例えばこんな感じ。

そしてその結果、翌2002年度、リストラによって固定費 fixed expenses の削減 cut に成功した各社は、公約どおり業績を急回復 sudden recovery of business させた。(p.8)

非常に読みにくい。 理念では「4重表記」と言っているが、「3重表記」といっているものとは「n重表記」の意味が違うではないか。 この書き方では日本語の体をなしていない。日本語の単語を英単語(熟語)に置きかえるか、日本語の後に括弧付けするならまだわかるが、これは酷い。 もちろん英語の併記自体は役に立つのでよいことだけに惜しい。 「いわば日本語表記の未来型」とまで言ってしまう発案者は何を意図しているのだろう。

語の対訳掲載については「コンパイラ－原理・技法・ツール」の書き方が素晴しい。 索引の各語に対訳が書かれておりそのまま対訳表として使える。 プログラミングの際に、変数名・メソッド名を決める時に非常に役に立っている。 専門書の翻訳本はぜひ見習って欲しい。

• ただのにっき(2004-10-27)

[ 書評 ]

• 給与制度改革 (2005-01-05)
• 実家の富士通ゼネラル冷蔵庫から異音 (2006-11-18)
• 富士通ゼネラル冷蔵庫の機械部分は壊れてなかった? (2005-05-14)
• 美しき日々ファイナルコンサート後の興奮 (2005-05-07)
• このやり方でやると「すごいこと」が起きる。 (2005-06-08)

■ LaTeX2e マクロ&クラス プログラミング基礎解説

[ コンピュータ書籍 ]

dtxファイル、insファイルの書き方を知りたかったので「LaTeX2e マクロ&クラス プログラミング基礎解説」を購入。

[ 書評 ]

• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)
• テスト駆動開発入門読了 (2004-08-05)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• テスト駆動開発入門 (2004-08-02)
• LaTeX2e クラスファイルを .dtx + .ins 化 (2005-05-08)

■ LaTeX2e クラスファイルを .dtx + .ins 化

書籍や他のクラスファイルでの書き方を参考に、クラスファイルを .dtx 化。 だんだん構成がわかってきた。

• DocStrip (docstrip.tex) を \input した .ins ファイルが .dtx をフィルタリングするバッチファイルになる。
• .dtx ファイルは、% の部分に生成されるもののドキュメントを書く。.dtx はコンパイルした時に、もう一度自分自身を読み込むように書く。ここらへんは doc パッケージの機能を使う。

トリッキーだが、うまくできている。

ただマクロの定義順と説明したい順が違うと、悩むな。

• LaTeX2e マクロ&クラス プログラミング基礎解説 (2005-04-28)
• 音楽再生にあわせて処理をする amaroK スクリプトを書いてみる (2006-01-31)
• ビジネスメールガイドライン案 (2006-05-05)
• 方眼手帳と方眼ミーティングメモ (2005-11-27)
• 過去の今ごろ (2004-05-07)

■ フルハルターでスーベレーン M400 を注文

万年筆に興味を持ったので Web でいろいろ調べていたら、森山モデルで有名な万年筆のペン先研磨職人・森山信彦氏の万年筆専門店「フルハルター」が近所にあるというのを発見。

自分用に調整された万年筆。欲しい!

先月 TC-1 で大散財したばかりなので自粛モードのはずなのだが、欲しいものは欲しい。 調整をお願いしてから仕上がりまでの期間を考えるとちょうどクリスマスプレゼントではないか(勝手)。

しばらく前からいろいろ考えた結果欲しいモデルも絞れてきたし、万年筆の世界へ足を踏み入れてみますか。

@ フルハルター

家から歩いて5分ほど。去年からかかっている歯医者の隣のビル。なんだよく通っているところではないか。 「水銀電池代替アダプター」で有名な中古カメラ屋セレックが以前あったビルである(セレックは東京都大田区西糀谷に移転している)。

11:00すぎぐらいにお店にいくと、既に一人先客がいた。 隣に座って待つ間、話のやりとりを聞かせてもらう。 その後途中、スーベレーン M400 (多分)を受け取りにきた男性や、調整に出していたペンを受けとりにきた男性と森山氏とのやりとりにも耳を傾むける。 いろいろな話が聞けて非常に参考になる。 これフルハルターのスタイル。

その先客は広島から出張できたついでに立ち寄ったそうで、今回が2回目。 スーベレーンM1000グリーンを注文していった。1日の終わりに何とはなしに書くのに使うそうだ。

以下他の人とのやりとりなども含めて聞けた話。

@ 使用方法・メンテナンス

• キャップをつけて書くか、つけないで書くかなんてその人の全くの自由。そういうのを気にするのは日本人らしい。実際海外の工場の人はその質問を聞いて意味がわからなかったらしい。
• キャップをつけた方が転がりにくいというメリットがあるけれど、書いていない時はキャップはしておいた方がいいからね。
• インクを吸入する時はグリップ部分までインクにつけて。
• 吸入したら少し逆に回して数滴インクを落とすとタレ防止になる (すぐ使うならば不要)。
• インクを足す時は一旦全て出して。
• 水洗いはできるだけしない方が良い。

@ インク

• ブルーブラックは水に強いというメリットがあるものの、詰まった時などは水洗いではなおらずオーバーホールしなければならなくなるのでお薦めしない。
• 基本的にペンとは違うメーカーのインクはお薦めしない。ケミカル的な相性があり、組み合わせによっては部品を痛める可能性がある。ただし、ペンはもちろん所有者のものであるので、使うのは全く自由である(メーカーの保証がきかなくなるかもしれないが)。実際、もし壊れたら修理に8千円と聞いて「なんだそれぐらいなら、どんどん使うよ」といったお客もいるらしい。
• ドイツメーカー(モンブラン、ペリカン)の間でカートリッジの互換性があるのは、ドイツでは小学校で万年筆を使わせていてどこでもカートリッジを入手できる必要があるかららしい。そういう意味で、これらのメーカー間では(今後も)お互いに他社のインクを使っても問題が起きる可能性が少ないのではないかとのこと。

@ 調整

• 調整しても必ず良くなるとは断言できない。使い手の書き癖というのも千差万別。時間をかけてゆっくり書き易いものにしていく。
• 私の書き癖はまあ特に大きく変わったところもないようだ。
• もっとも書き方に「普通」というものはなくて人それぞれ違うということにすぎない。
• 人はその「年齢-5」ぐらいの間ものを書いてきてその人なり書き方のスタイルができあがっている。簡単に変えられるものではない。

@ 選択

用途は仕事でミーティングのメモを取ったりするのが主。 RHODIA の 5mm 方眼紙に書くぐらいの大きさの字で考えている。 候補はペリカンのスーベレーン M400 か M600 で考えてきた。

• 試し書きをした字の感じでは、太さはFぐらいが良さそう。(方眼に)きっちりおさめたいならEFという選択もある、あまり気にしないで書くならFでも。M だとかなり太くなるので向かないであろう。
• (ここでの)試し書きの紙は普通の紙より太めに書ける。
• BからFへの研ぎ出しで。
• M400 か M600 はいい選択ですね。
• 速書きしますか? 速書きするならば一般に持つ位置が前めで立つ傾向があるので短めでもいいだろうし、遅書きなら逆に持つ位置が後ろめになるので長めがが良いかもしれない。
• ポケットに入れて持ち歩くか? M600 は胸ポケットに入れると当たる感じがするかもしれない。

持った感じは M400 でも M600 でもどちらも違和感なく、馴染めそうであった。 うかがった話を参考に今回は M400 を選択。

ちなみにフルハルターでのお薦めはペリカンとアウロラ。

@ 万年筆業界

• 最近は100円ショップも増えて文房具屋も儲からなくなってきた。
• 進学の際のプレゼントとして万年筆が売れていた昔とは違い、万年筆も売れなくなってきている。高いしね。もちろん一生使えるものと考えれば決して高くはないのだけれど。それで毎回書く楽しみが味わえるなら幸せなことだね。
• フルハルターも開業当初はお客が少なかった。最近は万年筆に興味を持った人がネットでフルハルターを見つけて来店してくれる。雑誌などでは読んでも来る人は多くなかったけれど、ネットの場合は「欲しいと思った人」が検索してホームページを見て来店してくれる。
• フルハルターのサイトは当初知人が管理されていたそうだが、その人が海外にいかれた後は、奥さまが更新されているそうである。

@ 大井町

• フルハルターはこのビルの1番目(のテナント)。隣りのカメラ屋も知っていた。

結局12:30までゆっくりおしゃべり。 仕上がりは1カ月ほどを見てくださいとの事。

森山氏は物腰のやわらかく押し付けることのない、それでいて万年筆への造詣と哲学をもっている素敵な方であった。 万年筆の仕上がりが楽しみである。

• フルハルター

• 買った! 新品 TC-1 (2台目) (2005-10-13)
• ステーショナリーに手を出した - 私的10大ニュース2005 [ misc ] (2005-12-31)
• 今日のさえずり - 最初に思い浮かんだのが吸血鬼ハンターDだけど古すぎ? (2009-09-15)
• フルハルターで頼んでいたスーベレーンM400がついにできた (2005-12-11)
• 今日のさえずり - アプリケーションハンガリアンにしてまわったらこんな時間 (2010-03-03)

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

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

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

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

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

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

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

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

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

• reStructuredText いいんじゃない? (2005-11-22)
• 早速 reStructuredText から LaTeX へのコンバータを書く (2005-11-24)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)

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

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

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

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

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

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

@ 種類マーク

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

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

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

@ 処理マーク

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

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

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

@ その他

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

とりあえずこんな感じ。

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

• チェックボックスルール拡張 (2005-12-24)
• 2008年夏の GTD 運用ツール (2008-07-23)
• A6 方眼ノート比較 (2006-01-06)
• 渋谷のロフトにほぼ日手帳2006を見にいった (2005-09-11)
• ほぼ日手帳復帰 (2008-07-22)

■ ほぼ Perl 手帳

ほぼ日手帳のカバー・オン・カバーにProgramming Perlのカバーをはさんでみた。

縦 16.5cm に調整してプリントアウトしたもの。解像度はあまり高くないのだが、ぱっと見はいい感じ。

@ この手帳についていないもの:

東京地下鉄路線図、世界通貨一覧表、時刻表、東北新幹線時刻表、世界地図、演算子優先順位表、正規表現の書き方、標準 Perl ライブラリ一覧、おしゃれ小鉢、などなど、

• 方眼手帳と方眼ミーティングメモ (2005-11-27)
• ポケットぽっこりだけれど、色に魅かれてマンダリンオレンジほぼ日手帳2007 (2006-09-15)
• 2008年夏の GTD 運用ツール (2008-07-23)
• 今日のさえずり - ソフマップの店員にヨドバシカメラの場所たずねているジイチャン (2009-09-02)
• 結局自分も MOLESKINE に行き着くのか (2005-12-15)

■ チェックボックスルール拡張

ほぼ日手帳、RHODIA 上でのミーティングメモ用にチェックボックスの書き方ルールを1カ月ほど前に決めて運用してみた。 1カ月たって、改良点が見えてきたので以下の通り自分ルールを改良。

@ 種類マーク

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

• (S、A、→、C、W は要処理なので○で囲む)
• 変更点
  • 「S」 を追加。「A」 だとちょっと違和感があったものあったので。
  • 「R、⇒」 を追加。記録を予定等と明確に分けて書いておきたいので。

@ 処理マーク

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

• アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。
• 変更点
  • 完了マークバリエーションに 「/」を追加。「→、o」 とのオーバラップ用。
  • 「o」マークを追加。ミーティング時にその場で発言しておくべき点をメモした際に、すぐに探し出せるように。

@ 追記

「?」疑問点を追加 (2005年12月27日)

[ メモ術 ][ ノート術 ][ 手帳術 ]

• 方眼手帳と方眼ミーティングメモ (2005-11-27)
• 2008年夏の GTD 運用ツール (2008-07-23)
• 渋谷のロフトにほぼ日手帳2006を見にいった (2005-09-11)
• DELFONICS の Rollbahn Memo を GTD ツールに投入 (2006-03-27)
• A6 方眼ノート比較 (2006-01-06)