nDiki : 識別子

識別子 - identifier

2002年6月8日 (土)

14:00 お買い物

新宿へ。

「エーゲ海に誘われて」

昨年、新婚旅行でギリシャに行ってきた。 エーゲ海のミコノス島・サントリーニ島へ行ってきてとても良かったのだが、案外この地を写した写真集って見かけない。 「現地で買ってくれば良かったなぁ」とも思うのだが、実際現地でぷらぷら眺めたのだけれどいい奴なかったんだよね。

で紀伊國屋書店を覗いたら「萩野矢慶記写真集 エーゲ海に誘われて」東方出版 ISBN4-88591-741-7 というのを発見。 結構希望していたイメージのもので、お値段もリーズナルブルなので入手。

「すぐわかる統計用語」

東京図書 ISBN4-489-005220-9。 易しくまとめられた、事典っぽい統計の本。 各語に英訳がついているのが嬉しい。 プログラムを書く際の識別子のための辞書引きって結構大変だから。

マジシャン

伊勢丹のおもちゃ売場の手品コーナーにマジシャンがいましたよ。 子供の頃は近くだった博品館によく通っていたのだが、ここにもマジシャンが常駐していたんだよね。 その後いなくなったみたいだけど。 子供ながらに、からかってみたりして楽しんでいたんだけど今だに健在だったようでちょっぴり嬉しい(別人だろうけどなんとなくね)。

スポンサード リンク
[ permalink ]
[ 6月8日全て ]

2004年2月10日 (火)

[ WiKicker ] WiKicker へ脚注機能追加

WiKicker スタイルで日記を記述するにあたり欠けている機能として「脚注」がある。 Wiki としては必須でないので WiKicker には導入していないのだが、日記としては無いと困る。 脚注が使えると文を書く時に正直手を抜ける。 またハイパー日記システム上の旧記事をコンバートする時にも無いといろいろ面倒だし。

ということで実装。

インラインブロック

さてどうしたものか。 WiKicker の WRI (BracketName 等を含む識別子)としての実装なら、parser の変更もなく新しいWRI scheme の追加と対応するクラスを書くだけですむ。 しかし WRI は終端記号なので、そうすると脚注の中でWRIを使えなくなる。 それは困る。

ということで、やはり非終端記号が必要。 悩んだあげく、 

 {{scheme: ... }}

という「インラインブロック非終端記号」を導入。 {{..}} というのは確かいくつかの WikiEngine でプラグイン呼び出しで使っている記法だったような。

  • 一般的な文章中には現れず、
  • かといって文章中に混ぜてもそれほど違和感なく(wiki ではこれが重要)
  • これ以上文法を追加したくないので、今後機能追加の際に利用できるように scheme 指定できる

といった点から、このようにしてみた。 2番目の点で合格点の出せる記法かどうかは微妙だが、まぁ許せる範囲かな。

{{ }} は、1行中に現れる必要有り。 「...」は scheme specific part だが、今のところ scheme によらず、InlineParser で解析されて部分木になるため、WRI とか ... とかも書ける。 InlineParser では正規表現を使っていて括弧の数は数えないので、今のところ {{ }} の中に {{ }} は書けないが、まぁ問題ないでしょう。

脚注記法

で脚注は、 

 {{fn: ...}}

となる。 普通。

実装

  • InlineParser の拡張
  • InlineBlockNode クラスの追加
  • 各 Visitor に visit_InlineBlockNode を追加。
  • HtmlFragmentVisitor に fn: の処理を追加。

いざ実装してみると、ちょこっとのコードで実現。 脚注番号の降り方とか、今後改良する点はあるけど、大枠は完成。

[ permalink ]
[ 2月10日全て ]

2005年1月27日 (木)

国際化識別子IRIのRFC

IRIがRFC3987になった。

WiKicker を含めた WikiEngine など(非ASCII)キーワードからURIを生成するタイプのソフトウェア開発において今後要チェック。

[ permalink ]
[ 1月27日全て ]

2005年10月6日 (木)

WiKicker 0.28 リリース - バグ修正版

WiKicker には「RFC821」といった文字列のようにマークアップすることなく認識されて処理される SWRN という識別子というものがあるのだが、これを処理するモジュールでバグを発見。'use' していないパッケージを使用しようとしてエラーになる。

以前高速化のため、無駄な 'use' 文を削除した際に消しすぎてしまっていたようだ。

表示がエラーになるという意味では重大なので速やかに修正版をリリース。

[ permalink ]
[ 10月6日全て ]

2006年7月25日 (火)

Perl 用の doxygen のようなツールはないのかな

WiKicker のソースコードを人に説明するのにプリントアウトして説明するのに、doxygen のようなツールが欲しいのだけれど Perl 用のものはないのかな。

  1. ソースコードを色付けした HTML に変換してくれる
  2. Pod とコード本体を混在してドキュメント化してくれる
  3. ソースツリー内のファイルをそれぞれ処理してくれて、インデックスファイルも生成してくれる。
  4. できれば識別子がリンクになってくれる

というのが希望。1 だけなら結構いろいろなツールがあり、1 + 2 なら perltidy で実現できる。 しかし 3、4 までしてくれるツールが見つけられない。

とりあえず perltidy の Perl::Tidy と File::Find で再帰的にまとめて HTML に変換するスクリプトだけは書いて、一気に変換だけはできるようにしておいた。

インデックスの作成までは面倒なので未着手。

[ permalink ]
[ 7月25日全て ]

2007年4月23日 (月)

ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

[ permalink ]
[ 4月23日全て ]

2009年12月25日 (金)

今日のさえずり: 完璧に完璧って手書きした記憶がない

2009年12月25日

[ permalink ]
[ 12月25日全て ]

2013年3月8日 (金)

YouTube アカウント間違えて削除した

最近 YouTube のページを開くたびに、名前を Google+ プロフィールの名前にするか、YouTube のユーザー名(あるいは別の名前)にするか聞くパネルが出て邪魔くさいので、ようやくチョイスすることにした。

Google+ プロフィールの名前(本名)にするよりは、ハンドル名的な方がいいよねと思って今の YouTube のユーザー名の方を選択した。でも考えると「Gmail アカウントに YouTube アカウント追加」で作ったもので Gmail メールアドレスの @ の前の名前になっっていて、この名前もそれほどオープンに使ってないのでやっぱり別の名前を設定すれば良かったなあと思ったが、どうやら後の祭りだったらしい。

設定を探すもユーザー名は変更できない模様。YouTube アカウント削除しても Google アカウントが削除されるわけではないので、いったん削除して作るかな。動画もアップロードしたことないしコメントつけたりとかのアクティビティなども無いし。とうことで削除。注意書きとして同じ名前では登録できませんて出たのでちょっと迷ったけど。

で再度 YouTube。別の名前設定しておこうと思ったんだけれど取れなかった。ならば元の名前でキープしておけば良かったとも思うのだが、さっき削除した名前は当然駄目。

ああ、ちょっと軽率だったかなぁ。でもあの名前の設定を促すパネル、半強制的な雰囲気あったし、2択の一方は、変更できなくはない表示名的な Google+ プロフィールの名前で、一方は識別子的なユーザー名となっててちょっとわかりにくいよねぇ(言い訳)。後でヘルプとかでいろいろ確認してわかってきたけど、あのパネル内では説明不足感がある。

YouTube アカウントと Google アカウントとの統合という経緯があるのは理解できるけれどちょっとわかりにくくて、ちょっと残念な失敗をしてしまった。

後で見たヘルプ:

[ permalink ]
[ 3月8日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

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

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

月別インデックス
Process Time: 0.106239s / load averages: 0.54, 0.49, 0.50
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker