nDiki : 書き方

2006年11月3日 (金)

DiKickern 年日記機能を追加

久しぶりに DiKicker に機能追加。

n 年日記機能

ハイパー日記システムで書いていた旧 Web 日記である Naney's Diary の記事を nDiki に移すにあたり、n 年日記にあたる表示がなくて困るので実装した。

最近はぱったり「過去の今ごろ」を書かなくなったけれど、たまには n 年日記を見て振り返るのも悪くない。

n 年日記へのリンクをどこに置くか迷ったが、とりあえず1日の一番最後に置いてみた。 tDiary テーマとの兼ね合いもあって思案中。

diary-article:

記事書き用には

 [[diary-article:記事ID]]

という記法を追加。 今までは他の記事へのリンクは URL で指定するしかなかったのだけれど、これだと可搬性がないしスマートでなかったので、あわせて実装してみた。

過去記事も全部この書き方に直したいけれど、それなりに数があるので面倒くさい。 もちろん今のままでも問題はないんだけれど。

過去の(膨大|それなり)のデータをいつまでも利用できるようにシステムを維持することの重要性(と手間)を再確認。

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

2007年4月23日 (月)

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

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

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

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

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

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

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

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

TaskJugglerUI

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

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

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

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

印刷

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

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

面倒な点といえば

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

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

ということで

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

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

[ 4月23日全て ]

2008年3月30日 (日)

Google ドキュメントソフトウェアかんばん

ソフトウェア開発見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

  • TRICHORD - 本命。使ってみたいが予算が。
  • Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
  • 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
  • Wiki - 以前やって失敗した。
  • XPlanner - インストールと学習が手間。それと開発止まっている?
  • その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
  • Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

スプレッドシートの作成

以下のようにスプレッドシートを作る。

  • 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
  • 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
  • かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
  • かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

カードの書き方

内容
Aカード番号をつける。
ストーリーカードは S番号。タスクカードは S番号T番号とする。
Bカード作成日を書く。
Cストーリーカードの時にストーリー名と作成者名をかく。
Dタスクカードの時にタスク名と作者名をかく。
E期日をかく。
FTODO の時に @ とかく。DOING に移行した時は @ を消す。
GDOING の時に @ と開始日、担当者の名前を書く。DONE に移行した時は @ を消す。
HDONE の時に @ と終了日、担当者の名前を書く。
I備考欄

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

運用

  • カード番号は重複しないように。
  • カードの状態にあわせて @ を書き換えていく。
  • DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
  • 列単位でソートしないこと。
  • タスクの粒度はできるだけ揃える(例えば半日~1日にする)。

課題

  • カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
  • タイムボックス等にあわせて並べ替える時の手間。
  • カード番号が手動。
  • 集計について考慮していない。
[ 3月30日全て ]

2012年5月23日 (水)

[ 5月23日全て ]

2013年3月2日 (土)

【日記】春なので新しい手帳買ったし書類も書いた

rimage:/nDiki/Flickr/8520644496.jpg 新しい手帳が届いたり。この手帳があれば育て方調べるために毎回 iPad 使わなくても済むのですごい有用。

で、ケーキパーティーして、ルービックキューブの LBL 方式黙々と練習してミニマムなのだいたいマスターして、夜はちらし寿司パーティー。

明日に出しにいくつもりで、夜は懸案だった確定申告書類作成。メインの申告書は過去と同様 Web で作成するとして、追加で必要な書類は PDF ファイルをダウンロードして記入。PC で書き込もうとしたら保護されている PDF ファイルで書き込めなくて、しょうがないので iPad 上で GoodNotes でチマチマ書き込む(保護何それ? な感じで書き込める)。各項目の書き方Web で慎重に調べつつ埋めていって「できた! 次は申告書。」って Web で入力しはじめたら、さっきの書類の作成ウィザードが途中にはさまっていた……(そして最終的にそちらを含む PDF ファイルができあがる)。悪魔やー。先に作った書類で計算された数値を申告書に書くのだから、順番的に申告書作成は後で着手するでしょう普通(実はどこかに説明が書かれていたとかそういうトラップがあるかどうかは調べていない)。

[ 3月2日全て ]

2013年3月5日 (火)

Perl で "+{" は見かけるし使うけど、"{;" は見かけないし使ったことない

Perl で "{" はブロックの始まりと、無名ハッシュへのリファレンスであることの始まりが曖昧な文脈があって、後者であることを示すために "+{" という書き方がある。

このことが話題になったので、あらためて perlref を読んでみたら "{;" という書き方を発見。こちらはブロックであることを明示する時に使う。

以下 Perl 5.14.2 の prelref より抜粋。結果も 5.14.2 で確認。

 sub hashem {        { @_ } }   # silently wrong
 sub hashem {       +{ @_ } }   # ok
 sub hashem { return { @_ } }   # ok

上からリスト、 ハッシュリファレンス、ハッシュリファレンスを返す。

 sub showem {        { @_ } }   # ambiguous (currently ok, but may change)
 sub showem {       {; @_ } }   # ok
 sub showem { { return @_ } }   # ok

全てリストを返す。

[ 3月5日全て ]

2013年7月26日 (金)

今日のさえずり: 「PDF 形式」って書き方ムムムってなる

[ 7月26日全て ]

2013年8月7日 (水)

プログラミング言語仕様・振る舞いを確認するために小さいプログラムを書く

プログラミング言語仕様・振る舞いを確認するために小さいプログラムを書く。 「この式を評価すると値は何になるの?」とか「この2つの書き方どっちが速いの?」とか「この正規表現にどうパターンマッチングするの?」とかを確認したい時。

当たり前の進め方だと思っていたんだけれど、そうすることを勧めたらスルー気味だったので。

特にスクリプト言語なら 「a.ほげほげ 」(Perl なら a.pl)なファイル作って実行してみればいいじゃんと思うのだけれど手間に感じるのかな。本丸のプログラムのソースコードを書き換えて試す(Apache 再起動して Web ブラウザでアクセスしてデバッグプリント読むとか)よりよっぽどはやいよ。あと、単体テストファイルでやっちゃうのもアリ。

それに適当に記事としてまとめておけば、今度は自分が他人に説明する時にそれを示せば済むようになるしね。

[ 8月7日全て ]

2013年11月27日 (水)

SEO 的にタイトル要素中のサイト名を後ろにしたり、canonical 設定したりする

SEO 的にタイトル要素中でできるだけ前にキーワードが出現した方が良いらしいので、先頭にサイト名をつけていたのをやめて後ろに | で区切って付けるようにした。あとはトップページまわりと、記事ページとアーカイブページで重複コンテンツになるところについて <link rel="canonical" href="..."> を設定するようにした。

  • タイトル要素中で「サイト名: 記事のタイトル」のようにしていたところを「記事のタイトル | サイト名」に変更。
  • 旬別・日別・月日別アーカイブページで重複タイトルにならないように、日付や件数などを適宜入れるようにした。
  • RewriteRule ^$ /diki [L] としてパス無しでもパス有りでもトップページを参照できるようにしているので、後者の表示ではパス無しの URL を canonical 指定するようにした。
  • 日別アーカイブページで記事が1件しかない場合、記事ページとほぼ重複コンテンツになるので、その場合記事ページを canonical 指定するようにした。

最近 SEO の話を聞く機会が何度かあったこともあって、最近メンテナンスをしていなかったのでまずはサイト内でできることを変えてみたというところ。

あとは「zenbackキーワーズ」のまとめページの方がオリジナルより検索結果で上に来るのがシャクだからちょっと逆転させていというのもある。ちょっと前からまた Zenback を使うようにしているんだけれど、そうすると「zenbackキーワーズ」のまとめページに自動的に載るというサービスになっていて、まあそれはビジネス上いいとは思うんだけれどそっちの方が最近ちょっときがちなので負けていられないなーと。パーソナルナレッジベースとして自分の記事探したい時に不便だしね。

HTML 構造ずっとレガシーなままなので、こちらもそろそろ手を入れたいところ。

あとは本質的なところとして Web 日記とはいえもうちょっと書き方も意識した方がいいのかな。最初の2パラグラフが重要らしいので、より結論ファーストで書くとか。まあ日記なので引き続きだらだら書きたい時はそう書けばいっか。

[ 11月27日全て ]

2014年4月17日 (木)

今日のさえずり: あうぇーさむって読んでたけど、おーさむなのね

2014年04月17日

[ 4月17日全て ]

About Me

Naney Naney

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

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

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

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

最近検索されている記事

月別インデックス
Process Time: 0.063404s / load averages: 0.24, 0.35, 0.40
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker