こんにちは。wiki.ciklone担当のhayashidaです。
何だか熱くなったり、寒くなったりで体調管理が難しい気候が続きますね。皆様お元気でお過ごしですか？
そんな今も空はどよどよ。今朝はレインコート着て出勤しました。
さて、cikloneの新バージョンが近日中にリリースされそうです。それに伴いcikloneHPもリニューアル致します。
残念ながらwikicikloneのデザインは変わらずですが・・・cikloneの新機能に付いてなど詳しく掲載していくつもりです。
※wiki.cikloneではciklone（サイクロン）のマニュアルやら便利なTipsやらFAQやらを掲載しています。
いつまでの無料のフリープランもこれまでと同様に使用頂けます。
今日はご報告までですが、次回はより詳しいバージョンアップ内容をご報告出来ると思います。
ではまた！
こんにちは。wiki.cikloneを担当しています、hayashidaです。
残念ながら、wiki.cikloneの認知度が低いので、ブログ側でもちょっと紹介させて頂こうとやって来ました。
wiki.cikloneはciklone（サイクロン）のマニュアルやら便利なTipsやらFAQやらを掲載しているページです。
そもそもciklone（サイクロン）って何さって方はこちら、
一言で言うとクラウド型のバージョン管理システムです。
ちょっとだけ、サイクロンの画面のイメージをお見せするとこんな感じになります。
バージョン管理やインシデント管理の必要性は感じているけど、サーバーの設置や管理メンテが面倒・・・という方は是非、いつまでの無料のフリープランから試してみて下さい。
そして利用方法等で不明な点はwiki.cikloneをのぞきに来て下さい。
もちろんお問合わせもおまちしています！（まだまだ情報不足なので・・・）
では、また。wiki.cikloneで更新した情報などこちらでも紹介しにきます。
「インシデント管理、どうしていますか?」
など。他にもあるでしょうが･･･
エンドユーザから見た場合、自分たちの業務を支えてくれる便利屋さん、と思っている人も多いのではないでしょうか。
エンドユーザから、「昨日までは出来たのだけれど」「ログインできません」「やり方がわからない」など、日々のサポートで昼間は自分たちの仕事が出来ない、という声も聞いたことあります。
など、やろうとしたときにできない状況のことです。
Wikipediaより「サービスサポート – インシデント管理」
エンドユーザにとって、
システム管理者や保守運用担当者にとっては、インシデントを解決したからと言ってそれで終わりではありません。
をナレッジとして残し、同じ問題が発生したときの事例として活用する仕組みまで考えなければいけないのではないでしょうか。
本ブログではソースコードの管理にバージョン管理を使ってみたいけど、次にどうすればよいかわからないという方に向けたファーストステップになるような説明をします。
まず、「バージョン管理」とは時間の経過と共に変更が加えられる、プログラムのソースコードやドキュメントなどの各種リソースの作成日時、変更日時、変更点などの履歴を保存しておきます。何度も変更を追加されたファイルでも、過去の状態や変更した人、変更内容を確認したり、過去に遡って状態を復元することができます。
このようにバージョン管理のメリットは理解しているけど、これまでのやり方を変えて導入することが難しい。
バージョン管理システムの導入を検討しているけど、用語が特殊であったり、機能が複雑と感じて導入に躊躇している。などの声を聞きます。
すぐに社内のプロジェクト標準ツールとして導入することは難しいかもしれませんが、1人での開発、2，3人のチーム開発という小さい単位で使ってみることをお勧めします。実際に導入され、開発ツールとして浸透し、無くてはならないツールとなるのは数ヶ月かかるかもしれません。バージョン管理を導入された方からの声をまとめたページがあります。
最近のプログラミング環境では必須と言われているソースコード管理。
オープンソースでは有名なソフトウェアがたくさんあります。一度使ってみてはどうでしょうか。
trac でプロジェクトを運用をするのが初めての方などは特にですが、「チケットって何を書けばいいの？」となることが多いとおもいます。
私も初めて使ったときはチケットとはどういうものかよくわからなかったものです。
雛形があればどうにかチケットを書くことができるのではないか。
そんなプラグインなんて・・・ありました！
今回はチケットのテンプレートを作成できるプラグイン Trac Ticket Template Plugin をご紹介いたします。
社内標準でTracベースのバグ管理システム cikloneを使い始めてかなり経ちます。
使っていく中で、多いのがプロジェクトによってはいつも同じページを参照していて、そこにショートカットが欲しいなー。
というものです。
とはいえ、自分の為にWikiStartにリンクつくるのもどうかなと思うし。。
そんなわけで、Tracにブックマーク機能を追加する、BookmarkPlugin を作りました。
レポジトリからインストールします。0.11と0.12で動作検証済みです。
> easy_install http://trac-hacks.org/svn/bookmarkplugin/0.11/
ブックマークプラグインをインストールして、enableしたら、ログインしましょう。
ログインすると、コンテキストメニュー(グローバルメニューの下) に灰色の星マークが表示されます。
灰色の星マークをクリックすると、黄色に変わります。
これでブックマークされました。右端の “Bookmark” というリンクからプルダウンで該当のページに行くことができます。
黄色の星マーククリックで削除です。
“Bookmark” リンクそのものは /bookmark というページにリンクしていて、ブックマークの一覧を表示します。
BookmarkPluginは初めてtrac-hacks に上げたプラグインなのですが、VotePluginを参考にして作りました。
trac と subversion を用いてプロジェクトを管理していて、subversion で管理しているソースをコミットする時
チケットの参照
refs #1, #2 * commit message
チケットの解決
fixed #3 * bugfix
などのメッセージを入れるかとおもいます。
このコマンドをメッセージとしてコミットすると対応するチケットのコメント欄は下図のようになります。
数個のコメントならいいですが、たくさんのコメントが付いた場合どのチェンジセットがこのチケットに関わるものなのかわかり辛くなります。
そんなときに便利なのがこのTicket Changesets Plugin です。
Tracの日付入力はテキストボックスでめんどくさいな。。と思ったことが誰でもあるはず。
カレンダーポップアップ プラグインはそんな悩みを解決してくれる、はず。。
easy_install でインストールですね。
> easy_install http://trac-hacks.org/svn/calendarpopupplugin/0.11/
wiki のHowto をみて設定してみます。
「まずは、ポップアップを表示したい input field のHTML-IDとファイル名を特定しましょう。」。。。もしかして、自分で1づつ指定しないといけないんですね。。
とりあえず、例の通りにやってみます。
[calendarpopup] ids=duedate=MM/dd/yy << これがDOM ID files=milestone_edit.html << これがファイル名
どうやら、マイルストーンの期限にポップアップをつけるようです。
設定したら、マイルストーンページを確認してみます。
お、でました。
MM/DD/YY で入力できましたね。
他に日付入力を探してみたんですが、意外とないです。。
マイルストーンの完了日は 時間も入力することになっていますが、ここにもポップアップを設定してみます。
今度は管理画面から設定
以下のように入力します。
files
- milestone_edit.html
ids
- completeddate,duedate=MM/dd/yy
フォーマットが。。。。そのまま更新したらエラーになってしまいました。。
フォーマットは id ごとに指定していくことになっているみたいです。
files
- milestone_edit.html
ids
- completeddate=MM/dd/yy,duedate=MM/dd/yy
チケットのカスタムフィールドで期限とか運用しているととっても便利な気がします。
awesome attachments とはなかなか勢いのあるネーミングです。
何がすごいと言ってるかというと、チケットへのファイルの添付をチケット作成前にできる。ということみたいです。
たしかに、tracではチケットに添付ファイルをつけるときは一度チケットを作ったあとに添付しないといけないので、画像を添付するときは
1. チケット作成
2. 画像ファイルを添付
3. 画像ファイルを展開するマクロ [[Image()]] をチケット本文に追加
みたいに面倒な感じでした。
0.11 版だけしか提供されていないですが、インストールしてみます。
まずはeasy_install コマンドでインストールします。
> easy_install http://trac-hacks.org/svn/awesomeattachmentsplugin/0.11
trac.ini には [components] セクションに2行書き足します。
この辺、マニュアルの通りですね。
trac.ticket.web_ui.TicketModule = off awesome.awesomattachments.* = enabled
enableになっています。
では、チケットを作ってみましょう。
チケット作成画面にアップロード用のフォームが追加されています。
プラスボタンで複数添付もできるようです。
画像をアップロードすると、なんと本文に自動的に Image マクロが追加されました。うーん、これは便利。
そんなわけで、チケットを作ると、画像が開いた状態で表示されます。
これはなかなか便利かもしれません。
ゴキブリを１匹見つけたらその１０倍は家に潜んでいると、誰かから聞いたことがありますが、それは本当なのでしょうか？
ソフトウェアのバグもそんなにあったら嫌だなあと最近つくづくと感じています。
そもそも、システム開発工程でバグを作りこまないようにすればいいのですが、必ずと言っていいほど作りこまれてしまいます。設計書の誤り、誤解や思い込み、錯覚あるいは検討もれなど、原因はたくさんありますが、どうやら人間の行動にはミスがつきまとうものだと理解した方がよさそうです。
設計者ならば、どれくらいバグが潜んでいるのか興味があると思いますが、信頼性予測のモデルによってソフトウェアの信頼性を数理的なモデルで計量化して予測する方法もあります。プログラム開発者が意図的にプログラム中にバグを埋め込んでおき、デバッグにより発見したバグのうち意図的に埋め込んだバグの発見率から全体のバグの数を推定するのです。
次のような式になります。（詳細はこちらを参照のこと）
（発見済み埋め込みバグ数）/（埋め込みバグ数）
＝（発見済み潜在バグ数）/（潜在バグ数）
ソフトウェア開発者の能力によりバグの作りこみ数も変わってくるような気もしますが、バグの収束を願う設計者の気持ちはひしひしと伝わってきます。
バグを見つけるためには効果的なテストが必要ですが、どんなテストをすれば重大なバグが素早く見つかるのでしょうか。一般的なテスト作業では、コンポーネントとして実装したプログラムが要求仕様とおりに動作することを単体テストで確認し、結合テストによりさらに大きなモジュール単位での動作を確認します。当然のことながら、どんなテストツールを使うか、どんな体制でテストチームがテストを進めるかが重要になってきます。テスト工程を管理するテストツールも沢山出ているので、うまく利用すれば自動テストや結果分析も効率化できると思います。
デバッグとは関係ありませんが、2つの似た絵があって右の絵と左の絵でどこが違うのか探すような、間違い探しのクイズを考えてみてください。答えを見れば、何だそんな所か、とわかるのですが、意外なところ、想定外のところに違いがあると案外と見つかりにくいものです。もちろん、得手、不得手はありますが、ちょっと見方を変えることでバグが見つかるということがあります。他の人の見方や意見を参考にするのも、新鮮な視点を持つという点で、効果的です。開発者は、失敗を繰り返しながら、テストの達人に成長していくものなのでしょう。
ある先輩が言っていた言葉を思い出します。
「バグを全部見つけるのは無理だが、事故再発防止により品質向上できる」
類似不良を出さないことが最低限必要なのだと理解しましたが、これはいつの時代も通用することだと思います。
バグ管理システムcikloneでは、チーム開発の進捗、wikiによる情報共有基盤を備えています。そのため、プロジェクトのチームメンバと情報交換をしながら、テストも進められます。バグ管理データベースで過去の類似バグも管理しているので、同じ失敗を繰り返さないようにできます。
無料版での利用が可能なので、皆さまも是非、御検討下さい。
