• メインとなるメンバーが 5 名前後の小規模なプロジェクト
• そのうち何名かは非エンジニア

目新しい話は無いと思います.
様々な機能を使い倒していたりもしません.
あまり学習・運用コストをかけずに, いかに効率よく使うか, という方向性です.

ルールは少なく

チームの全員が Redmine に対して肯定的であることは稀です.
Redmine よりもメールや Excel で管理したい, という信じられないことを言う人も少なくありません.

そんな人たちも含むであろうチームで Redmine を楽しく運用するには, とにかくルールを簡単にすることが大事だと考えます.
優先度, 予定工数, カテゴリなど, 記入できる項目はたくさんありますが, その全てについてルールを設け, 意味を理解しない状態で記入させることで, 一体何が得られるでしょう?

まずは最低限「作業依頼はチケットに書く」ということだけ守ってもらうだけで, ToDo 管理にはなります.

最低限のラインでもいいので, とにかく Redmine を使い続けていると, 段々と不便さが気になりだします.
そういう不便さがチーム内で明確になってくれば, 各項目を細かく記入する意味もわかってくるので, そこで初めてルールを決めましょう.

と, ここまでルールという単語を使ってきましたが, 基本的には文化として自然に醸成されていくのに任せるのがいいと考えています.
プロジェクトの大規模化・複雑化などといった事情が無い限りは, ゆるく柔軟に運用していきたいものです.
これは XP における YAGNI の原則にも通じると思います.

期日を記入する

ToDo 管理としての Redmine から一歩先に進めるとしたら, まずはここから始めるのが効果的だと思います.

チケットに期日を入れることで, Redmine の重要な機能であるガントチャートにタスクが表示されるようになります.
ガントチャートを活用することで, 進捗状況は一気にわかりやすくなるので, これはエンジニア以外の人にも比較的理解されやすい機能だと思います.

また, 期日はチケットだけでなく対象バージョンにも設定できます.
こちらでは, より大きな単位で, ざっくりと俯瞰できるようになります.

チケット期日設定無し

チケット期日設定あり

対象バージョンにも期日設定

ゴールを明確に

どこまでやればそのチケットをクローズできるのかが明確になるように, 注意を払います.
依頼者と作業者の意思疎通を明確にするためです.

逆に, ゴールが明確になりにくい議論をチケット上で繰り広げても, よくわからないうちに流れてしまいがちです.

議論には, チケットよりもフォーラムを活用するのが好ましいと考えます.
もちろん, Redmine を離れて実際にミーティングするのもいいでしょう.

議論の中でやることが決まったら, そこで初めてチケット化しましょう.

チケット名が「~~~ について」といった曖昧な形式になっているのは, 良くない兆候です.
多少説明的でも, チケット名だけで作業のイメージができるような命名を心がけましょう.
名前重要.

まとめ

Redmine はとても魅力的なソフトウェアですが, 導入コストは決して安くありません.
まずは無理なく使い, 楽しくタスク管理ができるようになることが大事だと思っています.

今回はタスク管理ツールとしての Redmine に着目し, 最低限のルールで効果的にチケット機能を利用する方法を紹介しました.

See also

• Redmineによるタスクマネジメント実践技法
  Redmine を用いたプロジェクト管理について実践的に解説している書籍. 良書.
• 3年使ったRedmineの使い方について共有したい10のこと
  こちらは大規模プロジェクトでの話のようですが, プロジェクトの規模に関係なく適用できそうなことは参考にさせていただきました.

Facebook や Twitter によく似たインターフェイスのボタンではてブできるようになったようなので、早速対応させてみました。

./wp-content/plugins/wp-social-bookmarking-light/wp-social-bookmarking-light.php に以下の関数を追加して、設定画面で Services に hatena_button を加えるだけで OK です。

とりあえず表示できる、という程度なので、週末にでも微調整したいと思います。

See also

• WP Social Bookmarking Light NINXIT-BLOG

旧
Born Too Late » 記事タイトル
新
記事タイトル – Born Too Late

変更はこれだけ。

変更した理由は以下の通り。

• “»” (») だと、うまくコピペ時に失敗して文字化けすることがある。
• Permalink において主張すべきは「その記事が何であるか」であって、ブログの名前ではない。

このスクリーンショットを見てもらうとわかるとおもいますが、タイトルにも気を配らないと、ブラウザのサイドバー等で残念なことになります。

些細な変更でも、ユーザビリティ (ファインダビリティ ?) 的に大きな違いが出ることはよくあるものです。

See also

• ページタイトルの変更 WordPressを使ってみた
  この記事を参考にしました。

コンソールから使える git ブラウザ、tig が超便利

Vim に近い操作感で使えるのが Vim 使いには非常に嬉しいところです。以下で、インストール方法と基本操作について紹介します。

インストール

インストールは、まずソースコードからやってみたのですが、パッケージが存在することに気づいたので、 aptitude で入れ直しました。

sudo aptitude install tig

はい、簡単ですね。

起動する

カレントディレクトリを Git のワークツリーに移動して、 tig コマンドを実行します。

$ cd /path/to/work-tree
$ tig

ヘルプを表示する: h

何はともあれ、わからないことがあればとりあえず h を押してヘルプを調べましょう。

カーソルの移動: j, k

Vim ユーザなら、何の問題もないでしょう。 j で下へ、 k で上へ移動します。

メイン画面の表示: m

tig 起動時のデフォルト画面です。カーソルを移動して、詳細を確認したいコミットを選択し、 Enter キーで diff が表示されます。

Enter キーを押すと、上にコミットリスト、下には diff という 2 ペイン表示です。ちょうど上に載せたスクリーンショットの画面です。

フォーカスを移動する: Tab

2 ペイン表示時に Tab キーを押すと、カーソルのフォーカスがコミットリストと diff とで交互に移動します。

リポジトリ上のファイルツリーを表示する: t

リポジトリ上のファイルを参照するのに使います。カーソルを上下に移動して Enter キーで選択するとことで、ディレクトリを潜ったり、ファイルの中身を表示することができます。

これも 2 ペイン表示なので、 Tab キーでフォーカスの移動ができます。

キーワード検索: /,?

これも Vim ユーザにはお馴染みの操作ですね。 foo というキーワードで検索するときは、 /foo と入力して Enter キーを押せば、下へ向かって検索できます。

逆に、上へ向かって検索するときは ?foo と入力して Enter キーです。

また、これまた Vim と同じく、 n で最後に検索したキーワードで繰り返し下へ向かって検索し、 N で上へ向かって検索できます。

その他にもたくさんの機能があるようなので、Git ユーザの皆さんは是非使ってみましょう !

See also

• Index of /tig
  ソースコードはこちらから。
• The tig Manual
  公式ドキュメント。英語。
• コンソールから使える git ブラウザ、tig が超便利 って、なんでですか〜
  ネタ元。
• Tig(text-mode interface for git)を使う Kwappa開発室
  分かりやすい解説付き

基本的に最小限の機能が揃っている上、対応するウェブサービスも多いのでいい感じなのですが、ボタン表示されるのが記事個別の Permalink で参照しているときのようです。

というわけで、トップページでもボタンが表示されるよう、微修正を加えました。
YOUR_TWITTER_ACCOUNT の所は自分のものに書き換えてください。

ただし、個別のウェブサービスについては、 Twitter のみしか修正を行っていないのでご注意ください。このサイトで使用している hatena, hatena_users, facebook, facebook_like については特に修正がいらないようなのですが、その他のものについては特に確認しておりません。

このプラグインには公式の Tweet Button というのが使われています。パラメータによっていろいろ調整できるので、自分好みに修正が必要な方は、下記のページが参考になります。
Twitter / ツイートボタン

Enjoy !

外部のリソースが増えると、当然 HTTP リクエストも増え、ページ全体の表示時間に影響が出ます。

というわけで、以下のようなスクリプトを用意しました。

使い方

まずは、上記 Ruby スクリプトを syntax-highlighter-minimizer.rb といった適当な名前で保存します。

このスクリプトの動作には、 JSMin という Rubygems が必要なので、インストールします。

$ gem install jsmin --no-rdoc --no-ri

スクリプトは以下のように使用します。

$ ruby syntax-highlighter-minimizer.rb /path/to/syntax-highlighter-and-code-prettifier/script

プログラムの引数として、 sh***.js といったファイルの含まれるディレクトリのパスを渡して実行します。すると、ディレクトリ内に以下のようなファイルが保存されます。

• syntax-highlighter-all.js … sh***.js をすべて結合したもの
• syntax-highlighter-all-min.js … ***.js をすべて結合し、難読化したもの

仕上げとして、 JavaScript ファイルの読み込み部分を書き換え、ファイルを結合・難読化したものと置き換えます。

./wp-content/plugins/syntax-highlighter-and-code-prettifier/syntax-highlighter.php

18 もあった JavaScript ファイルがひとつにまとまりました !

難読化とは

文字通りに言えば、プログラムを読みにくくすることですが、実際はソースコードの圧縮が目的です。インデント等を極力少なくすることで、圧縮されます。

どれぐらいの効果があるか

以下のようなページを作って測定してみました。

• default.html … 元の 18 の JavaScript が読み込まれる
• all.html … 18 の JavaScript を 1 つのファイルに結合したものが読み込まれる
• all-min.html … 1 つのファイルに結合したのち、難読化したものが読み込まれる

いずれも、 script タグにより JavaScript が読み込まれるだけのシンプルなページです。 FireFox で Ctrl + F5 の強制更新で、 onload イベントの発生までの時間を計測しています。

難読化による効果は誤差程度に止まりましたが、 JavaScript ファイルをまとめることは、絶大な効果があるようです。今回の例でいえば、 2.8 倍近い高速化が実現できました。

ただし、実際のウェブサイトは、 JavaScript 以外にもたくさんの要素を含み、キャッシュ等の要因も絡むため、ここまでのインパクトは無いと思いますが、ページの表示時間が気になるときは、是非検討してみるべきでしょう。

今後の予定

今回は特定のプラグインに標的を絞りましたが、 WordPress といった CMS を使用する場合、プラグインで JavaScript や CSS の数がもの凄いことになっていた ! というのはよくあると思います。それらを 1 つ 1 つ潰していくことで、案外バカにできない効果が期待できそうです。

あと、 JavaScript ファイルを減らそう ! とかいいながら、この記事には GitHub の Gist が 2 つも貼り付けられています。これらは JavaScript の外部リソースによるものなので、ページ全体の読み込み時間に影響します。ページの読み込み時に読み込むのではなく、「このコードは読んでみたいな」と思ってクリックするまで、読み込みを遅延させる、という仕組みもアリかもしれません。

参考文献

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

Yahoo ! のフロントエンド最適化チームによるノウハウ集で、 JavaScript の結合・難読化についてはほとんどこの書籍に書いてあります。

その他にも様々なテクニックが紹介されていますが、その中でも特に敷居が低いのが、この JavaScript についての最適化です。

是非試してみてはいかがでしょうか。

git rm -r .

職場では Subversion だけど、来るべきときに備えて、ローカルに Git をインストール。ひとりで作っているプログラムを Git のバージョン管理下に置いてみた。そのときに、バージョン管理したくないファイルも一緒に git add してしまったので、ヘルプを見ながら上記のコマンドを打ってみたところ、ワークツリーのファイルが跡形もなく消え去ってしまった・・・。

git rmは、Working Tree (作業コピー)と index からファイルを削除するコマンドですが、 –cachedを指定する事で、 indexからのみファイルを削除する事ができます。

s21g :: Hello, world!「Gitで間違えたgit addをキャンセルする方法」

正しくはこうするべきだったようです。

git rm -r --cached .

不幸中の幸いは、消失したプログラムは数行程度だったこと、完全に個人的なプログラムだったこと、そしてこれが仕事ではなくプライベートだったこと。これを仕事でやってしまったら、と考えると眠れなくなる。やっぱり、プライベートでこういう遊びをやっておくのは大事だと思った。

入門Git

ただ、公式サイトの右下で Code Is Poetry とか謳ってるわりには、グローバル変数とかいっぱい使ってて正直いただけないコードかと・・・。

あと PHP は、オブジェクト指向的な表現力が格段にアップした、5 以降がいいと思うのですが、これについては世の中の PHP5 移行状況とか、そもそもの WP の開発状況とかも関わってくるところなので、まぁしょうがないのでしょう。というか、会社でやってるサービスの、PHP4 -> PHP5 移行作業で色々トラブった私としては、「4 でも 5 でも動くってすげえ！」と言わざるを得ないところでもあります。

さて、本題ですが、これは別に PHP のバージョンが関係しているわけではなく、凄く簡単に解決できます。

XREA では、WordPress をボタン一発でインストールしてくれる機能もありますが、最新版が使いたかったので、公式サイトからダウンロードして、自分でインストールしています。

/tmp というディレクトリに書き込み権限がない、ということが原因なので、書き込み権限のあるディレクトリを作成し、プログラム側の設定を変えれば OK です。ディレクトリ名は、./tp-temp として、WP のディレクトリ直下に置いたと仮定します。パーミッションは 707 にしましょう。

プログラム上の修正は以下の通り。

// ./wp-config.php 一番下あたり

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

// ↓この 2 行を追加してあげれば OK。
/** Absolute path to temporary files directory. */
define('WP_TEMP_DIR', ABSPATH . 'wp-temp/');

これで、あとはテーマなりプラグインなりを、「いますぐインストール」できるようになります。ブラウザ上で検索して、いくつかボタン押すだけで設定が完了するのはとても楽しいですね。

if 文の実行式を { /** ~~~ */ } で囲んでいなかったりと、コードはちょいとアレですが、機能美という点では素晴らしいツールだと思いました。