nDiki : レビュー

Markdown ファイルの拡張子を md にすると Google ドライブで不便

プライベートな日記をテキストファイルベースに移行した際、いったんファイルの拡張子を txt にしたのですが、 Markdown 形式で書いているのでテキストエディタのファイル形式判別的にも良いかなと思い md への変更を考えました。

試してみたところテキストエディタは OK (Emacs・iA Writer・JotterPad・Jota+) だったんですが、拡張子が md だと Google ドライブ上に検索用に同期して置いても検索されないし、Google Chrome で Google ドライブを使っている時にプレビューもできないし不便でした。

やはり txt でいくことにします。

[ ノート・日記はテキストファイルに ]

iA Writer の検索が不完全なので Atom を併用する

テキストファイルでのノート・日記を書くのにここ最近 iA Writer を使っているのですが、日本語の検索が完全ではない(マッチしないものがある)ので、標準で Markdown プレビューを備えている Atom を使ってみることにしました。

「プロジェクトフォルダを追加」することで IDE のように左側にディレクトリツリーが表示でき、ディレクトリ内の検索もできるので、キーワードでノート・日記を探すのに便利。

一般的なテキストエディタですから複数タブやペイン分割ももちろんでき、ノート・日記の整理をしたり nDiki の記事ファイルを書き起こしたりするのに便利です。

ノートツールとして使うには自動保存・自動再読み込みが欲しいので日本語メニュー化とあわせてまず以下のパッケージを入れました。

• japanese-menu
• autosave
• revert-buffer

これでひとまず使えそうです。

ただ iA Writer が不要になるかというと、完全には乗り換えられない感じです。 distraction-free さと新規ファイルを作る時の手軽さを考えるとまだiA Writer を手放せない感じ。

複数のツールを併用できるのもテキストファイルベースの良いところですね。

[ ノート・日記はテキストファイルに ]

nDiki ソースファイルの拡張子を txt に

この nDiki の記事ファイルはテキストファイルなのですが、ファイル名の拡張子を dkd/dkk にしていたのでテキストアプリでファイル一覧にでなかったり Dropbox や Google ドライブでプレビューできなかったりするなど不便でした。

なのでこの機会に nDiki (の日記システムである DiKicker)の仕様を変えて拡張子 txt でもよいように修正しました。あわせて1万以上ある記事ファイル名を修正。これで他のノート・日記系ファイルと同じように Dropbox 以下に移動 & Google ドライブに同期するようになりました。

パーソナルナレッジベースとしてのテキストファイル集約がこれでほぼ完了。

Ulysses でノート・日記が一括検索できるようになって個人的にかなり便利になりました。テキストファイル最高。

[ ノート・日記はテキストファイルに ]

今日のさえずり: Slack のスレッド機能、スレ立ての最初のメッセージにセンスが求められる

2017年01月19日

• 09:50 Slack の iOS アプリでスレッドにしてみた。 iOS アプリ上だとスレッド表示になったけれど Mac アプリケーション版(2.3.4) で見ると普通の投稿として表示された。
• 09:52 Web で見たらきちんとスレッド表示になってた。
• 10:31 Slack for Mac 2.4.1 にした。
• 12:00 Slack のスレッド機能、スレ立ての最初のメッセージにセンスが求められる。
• 13:29 「嫌われる勇気」買った。 (@ 青山ブックセンター 本店 in 渋谷区, 東京都) https://www.swarmapp.com/c/ai0nJbpQmsF
• 23:01 企画的なレビューを求められているのか技術的なレビューを求められているのか意識できるようにしたい。

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

• スプリントプランニング。スプリントバックログは空。

何をやったか?

• チームとして
  • デイリースクラム(朝会)はいつも通りやった。
  • プロダクトバックログリファインメントもいつも通りやった。
  • スクラム外でやったことをレビューした。
• 開発メンバがやったこと
  • プロダクトバックログアイテムを準備完了にするための情報収集・まとめをやった。リリースできるものはリリースまでした。
  • BTS にある不具合報告についてどんどん調査をした。
  • まとまった時間でシェルの設定を見直して開発しやすくした。QOL が上がった。

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

• 「スクラムを始める前のチケット駆動開発時代に戻った感じ。」
• 「スクラムで開発をしない場合(タイムボックスが無い場合)、個人でしっかり時間・タスク管理する能力が求められると感じた。」
• 「半年に1度くらい頻度でまたやりたい。」
• 「スクラムでやりたい。」

得られた気付きは?

• タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
• 複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。

Remember The Milk でタスクと親タスクを別々にレビューできるようにスマートリストを追加

Remember The Milk Pro はサブタスクを作れて便利。ただ何かストレスだなと思っていたのですがその理由に今頃気が付きました。

1つのリストに入れた「通常のタスク」と「サブタスクを持つタスク(GTD で言うところのプロジェクト)」をそのままレビューしているからですね。やはり高度が違ったものが混ざったままレビューするのは負担がかかります。

かといって高度別にリストを分けると操作が面倒。もともとプロジェクトには prj タグをつけていたので、レビュー用にこれを抽出するスマートリストを追加しました。

Remember The Milk は3階層までタスク階層を作れます。プロジェクトを1つにまとめておきたいことはあるので、そのようなプロジェクトには bigprj というタグをつけて、これまた別途レビューできるようにしました。

さらにその上の「重点的に取り組む分野 (Areas of Focus)」レベルまで Remember The Milk で扱うようにすると破綻するのでこれで十分かなと思ってます。

今日のさえずり: チームのかんばんの優先順位会議というかレビューをした

2018年02月06日

• 15:15 渋谷ヒカリエへ。ヒカリの道。 https://t.co/eXPDirIPVc
• 16:45 そろそろかなと今朝から花粉症対策としてアレグラを服用し始めた。「飲み忘れと飲んだか忘れ」対策に習慣化アプリ HabitHub でリマインダと投薬記録できるように今年も設定した。 HabitHub 便利。
• 17:15 Naney の日記: 一橋大学・津田塾大学写真部 @hitphoto 対外展2018 に行ってきました。フィルム一眼レフカメラで撮ったものからコンパクトデジタルカメラで撮ったものまで、いろいろな作品が混ざっていて飽きない写真展でし… https://twitter.com/...
• 20:15 渋谷、雪降ってる!
• 20:24 @hyuki ですです。粉のような雪が少しパラパラと。寒いですねー。
• 23:30 今日はチームのかんばんの優先順位会議というかレビューをした。感覚的にはプロダクトバックログリファインメント(見積もりはしない)のような GTD の週次レビューのような。なんとなく TODO だったものが明確になっていってスッキリ。

今日のさえずり: 「ダウンタウン熱血行進曲 それゆけ大運動会」で五代(ごだい)が名前・体力表示枠まで落ちちゃって動けなくなってしまった

2018年02月18日

• 10:24 RT @KeithYokoma: 高校生のころ、ジャヴァの試験受けたら合格だったのでやったーと思ってたら担任が俺よりテンション上がってて新聞記者さんよんできて取材され、新聞の地方欄に載り、それがインターネットにアーカイブされて2chに至ったのをよく覚えている。
• 10:27 RT @hidey: 実は貴重なものでは!? というものが発掘された https://t.co/w14V3HSLR0
• 10:30 RT @hidey: まぁ、模写ならどんなものが好きだったかわかる程度で致命傷ですむだろう(深夜の判断力) https://t.co/n4giml4xqs
• 11:47 RT @sn_f: ロリポップでどんなサイトを作っていたかより、ロリポップで借りたドメインがhttp://kill.jpだったことがいちばんの黒歴史って感じ
• 13:00 構成が変わっていてもはや写ルンですとは別物に。 Utulens より広角なのいいなあ。 / “Wtulens レビュー：写ルンですのレンズを二枚使ったWtulensは写りも激しい変態レンズでした！” http://bit.ly/2EBDrek
• 13:03 Utulens は APS-C サイズの α6300 だと 35mm 判換算 48mm の画角で写ルンですとはちょっと勝手が違ってくるんですよね。 http://bit.ly/2ht8a6M
• 15:30 帰りなさい! 帰りなさい! https://twitter.com/...
• 23:16 「ダウンタウン熱血行進曲 それゆけ大運動会」で五代(ごだい)が名前・体力表示枠まで落ちちゃって動けなくなってしまったんだけれど、どうすればいいのコレ……。 https://t.co/XyxtgcBQD5

GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使う

「Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。

私はgithubなどのmdファイル(https://t.co/nyoqRnjsN7)を読むために python製の grip 使って↓なスクリプトを書いて使ってます。

grip --export ${1:-README.md} - | w3m -T text/html

— Mitzyuki IMAIZUMI (@bsdhack) 2018年2月28日

さっそく試してみました。

 $pip2 install grip

でインストールしたら Markdown ファイルを指定して Grip を起動します。

 grip index.md

Grip が http://localhost:6419/ で Web サーバとして立ち上がるので Web ブラウザでアクセスすると index.md の HTML 変換されたものを見ることができます。なお

 grip -b index.md

とすれば起動と同時に Web ブラウザで開いてくれます。URL でパスを指定すればそのまま同じ/サブディレクトリにある Markdown ファイルもプレビューできるので、ハイパーリンク付けをしておくことでドキュメント群をブラウジングすることもできます。なるほどお手軽で便利。 GitHub 上とほぼ同様の見慣れたデザインになるのがいいですね。

そもそも Grip は「GitHub Readme Instant Preview」で GitHub 上での表示確認のためのツールで、 GitHub の REST API を使ってレンダリング結果を生成しているので当然といえば当然だったりはします。

ただそのかわり GitHub の API を使うので

• オフラインでは使えない(オフラインレンダリングは開発中)
• 外部サービスを使って変換させたくないドキュメントには使えない

と場合によっては不便な部分があります。なお後者については GitHub Enterprise があるなら Grip でそちらを指定するとう手もあります。

GitHub に push する前にチェックしたい時はもちろん、それ以外でさっと Web ブラウザで見てみたい時にも便利なツールですね。

• https://github.com/joeyespo/grip

今日のさえずり: イトーヨーカドー 大井町店のポッポとうとう今日まで。名残惜しい。

2018年02月28日

• 08:03 Google Chrome 68 の HTTP サイトでの表示は「保護されていません」になるのかな。ニュースサイトが書いていた「非安全」ほどはキツくない表現。 / “保護されたウェブの普及を目指して” http://bit.ly/2FBonP5
• 08:05 RT @mhatta: ジェットストリームのパーカータイプ替芯が出た http://www.mhatta.org/.../ https://t.co/IRBkuaDXVH
• 13:00 イトーヨーカドー 大井町店のポッポとうとう今日まで。名残惜しい。
• 15:15 Mac 上にある Markdown で書いたノートファイルを Web ブラウザで見るのに MkDocs を使ってみた。ビルトイン Web サーバ付き。 http://bit.ly/2F0lWV4
• 17:21 とんかつ屋さん #α6300 + GIZMON #Utulens http://bit.ly/2ht8a6M https://t.co/mNUuKKt3ep
• 22:27 @bsdhack ありがとうございます。 Grip 初めて知ったので使ってみました!
• 22:28 GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使ってみた。 http://bit.ly/2t4U2Wk
• 22:31 @bsdhack Grip で変換するの単独ページだけかと思ったらちゃんとディレクトリ階層中の Markdown ファイルも表示できて「おー」となりました。
• 22:36 お疲れ様でした & お大事に! @orga_chem / “退職の前座エントリ - 若き JavaScripter の悩み” http://bit.ly/2CP3vR9

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

• タイトル
• 概要 (What)
• 目標 (Goals)
• 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトビジョン
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むの・含まないもの)
  • (opt) 依存するプロジェクト・制約条件
  • (opt) リスク
  • (opt) 予算
  • (opt) メンバ
• 概要レベルのプロダクトバックログ
• プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトプラン
• 期間
• 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
• WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

• プロダクトバックログアイテム名
• ユーザーストーリー(誰・概要と目標・背景と目的)
• 満足条件(あれば成果物を含む)
• サイズ
• レビュー方法

タスクチケット

ちょっとしたタスク。

• タスク名
• 概要
• (opt) 背景と目的 (概要で自明でない場合)
• (opt) 成果物/アクション (概要で自明でない場合)
• 完了条件
• 期日

プロジェクト憲章

• プロジェクト名
• 概要
• 目標
• 背景と目的
• 成果物
• 完了条件
• スコープ(含むもの・含まないもの)
• (opt) 依存するプロジェクト制約条件
• (opt) リスク
• (opt) スケジュール・期限
• (opt) 予算
• (opt) メンバ

備考

他には以下のような形式もあります。

• One Pager
• インセプションデッキ
• 製品要求仕様書 (PRD: Product Requirements Document)
• リーンキャンバス

[ プロジェクトマネジメント ]