Ruby

2016/12/17

WindowsのRubyのバージョン管理はuruを使う

WindowsのRubyのバージョン管理はuruを使うと良い、という記事を見つけたのでメモ。

【参考】
Windows7でRubyのバージョン管理!pikの代わりにuruを使う。 - 思い付くまでタイトル未定

pikの替わりにuru~windowsで複数バージョンのrubyを切り替える~ - Qiita

jonforums / uru / wiki / Downloads ? Bitbucket

複数のRuby環境構築はrvmかpik: プログラマの思索

もうpikは使えなくなった。
代わりにuruをインストールする。

uru_rt.exeを、C:\toolsに配置
環境変数PATHにC:\toolsを追加

cd C:\tools
uru_rt admin install

uru_rt admin add C:\Ruby-2.2\bin

uru_rt ls
220p0 : ruby 2.2.0p0 (2014-12-25 revision 49005) [x64-mswin64_100]

uruはRubyのバージョンだけでなく、Gemも切り替えてくれるので便利。

| | コメント (0)

2016/01/12

Rails製次世代型CRMのFat Free CRM

Rails製次世代型CRMと記載されていた「Fat Free CRM」のリンクをメモ。

【参考】
Rails製、次世代型CRM・Fat Free CRM MOONGIFT

fatfreecrm/fat_free_crm ・ GitHub

Rails Hub情報局: いま読みたいRuby on Rails3アプリ 10選

Fat Free CRM - Ruby On Rails-based open source CRM platform

日本Cloud Foundryグループ ブログ: Fat Free CRM を Cloud Foundry で動かす

どんな中小企業でも、個人事業主でも、営業していたら、見込客や既存顧客の状態を管理したくなってくる。
そこで、CRMに見込み客や既存顧客を登録しておき、営業で見つけた情報や引合の情報を登録して、後で精査したい。

フリーのCRMと言えば、SugarCRMやvTigerCRMが有名だろう。
でも、Railsアプリと言えば、RedmineやGitlabが有名だろうが、Rails製CRMがないか、探していた。
そんな時に見つけたのが、Fat Free CRM。

(引用開始)
今回紹介するオープンソース・ソフトウェアはFat Free CRM、次世代型のCRMを標榜するソフトウェアだ。

Fat Free CRMはRuby on Railsで作られたソフトウェアで、SQLite3やMySQLで利用できる。ごく手軽に導入できるのが利点だ。インタフェースは非常に見やすい。ラベルが色分けされているだけで随分見やすさが変わってくることが実感してもらえるはずだ。

主な機能はタスク、キャンペーン、顧客情報、案件のステータスなどを一元的に管理できる。顧客に対してタスクを紐づけることで、どの顧客が工数が多くなっているのか等も分かる。検索は各アクションに沿ってフィルタリングが可能で、細かく検索できるようになっている。
(中略)
一般的なCRMというと入力項目がとても多く、面倒な感じがしていたがFat Free CRMについてはすっきりとしたインタフェースも手伝ってそんな印象はない。また、スケジュール管理とかぶる機能が多いのも一般的なCRMでは多かったが、Fat Free CRMではタスクくらいだ。次世代型にふさわしい、進化したCRMと言えそうだ。
(引用終了)

パッケージ製品のCRMは、どうしてもUIが使いにくいし、見栄えも良くない。
一方、Rails製のCRMの方がUIも先進的だし、最新の技術も反映しやすいはず。
Fat Free CRMの画面キャプチャや概要を読むと、使いやすそうに見える。

DBに顧客情報や問合せ情報が登録されていれば、そのDBを直接参照することで、他システムとも連携しやすくなるはず。
個人的には、CRMにおけるサポートデスクの問合せ管理はRedmineの方が使いやすいと思うので、Fat Free CRMとRedmineが相互連携できるといいなあと思ったりする。
色々調査してみたい。

| | コメント (0)

2015/07/18

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか

Redmineを導入したいという話を受けて、Redmineを導入した時、後で気づくのは、ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか、という問題。
ラフなメモ書き。
結論はなし。

【参考】
akipiiさんはTwitterを使っています: "改めて読むとなるほどを思う。「ツールは高速道路だが、その上を時速何キロで走れるのかはチームの成熟度に依存しているのだ。」書評 アジャイルソフトウェアエンジニアリング http://t.co/mwzki9EZGi @ryuzeeさんから"

OjaさんはTwitterを使っています: "管理者受けし易い代わりに、うまく使えるかどうかも管理者次第なので、管理者の実力と評価がそのままRedmineの評価になるんじゃないかという仮説 RT @t_yoshi_tomi 何故、 Redmineを気に入る人と Redmineを毛嫌いする人がいるのだろうか・・・"

よしむさんはTwitterを使っています: "@kawanishi_ameya プロジェクトによって運用具合もバラつきがありますし、管理者次第というところが影響してくるんですね・・・(泣)"

akipiiさんはTwitterを使っています: "同感。RT @n_enot: チームでのソフトウェア開発って本当に難しくて、だからみんなPullRequest駆動やチケット駆動、あるいはもっと単純に相談&告知、最悪な例だと申請&ハンコ承認といった、とにかく協調して作業する方法が探られているわけです。"

みずのり(みずののりゆき)さんはTwitterを使っています: "個人的に。 プロセスとツールの両方を同時に変えるのは難しいので、まずはEXCELな従来ツールで展開ツール活用時に近いプロセスを実装。 そこから”ツールの方が便利ですよ”とやってみると導入しやすい感。 前者のプロセス変更に対応出来ないチームにはツール導入しても使われないっす。"

みずのり(みずののりゆき)さんはTwitterを使っています: "最近やったのはプロセス導入の段階で、かなり苦労して試行錯誤して枠組み作ったけど、そのプロセスの安定した形態はすぐにツールに置き換え可能なものでしたとさ。 チケット駆動の考え方をプロセスにしたので、redmine置き換えがすぐに出来るのは当たり前なのですが^^;"

僕個人の経験では、Redmineというツールを導入した後に、こういうふうにプロセスを回すのだな、と気づきながら運用していた。
だから、ツールを使いながら、あるべきプロセスを導き出したように思う。

でも、実際はそうではなかったかもしれない。
ツールの導入前は、アジャイル開発を実践した経験はほとんど無かったけれど、アジャイル開発の知識は持っていたし、こういうふうに運用したい、という思いはあった。

WF型開発できちんと変更管理するやり方も、色んなSIを渡り歩きながら、学んでいた。
SIer特製の障害管理Webシステムへの障害票の書き方、コミットする時には障害管理番号を記載すること、CVSのコミットログに変更理由を記入すること、などの運用ルールはある程度分かっていた。
だから、Redmineを障害管理からタスク管理へ発展させて使う方法はマッチできた。

実際は、プロセスが確立されたイメージを持ってツールを導入していたのだろう。

ツールは高速道路であり、上手く使えば、ゴールまで速く到達することはできる。
でも、高速道路の走り方も多少はあるし、車のエンジン(=チームの能力)が性能を出し切れなければ、国道を走っている時と変わらないかもしれない。

色々考えてみる。

| | コメント (0)

2015/05/10

IntelliJでRailsソースをリモートデバッグ

IntelliJでRailsソースをリモートデバッグする記事を見つけたのでメモ。

IntelliJ IDEA 13.1 + Ruby plugin 6.5.0.20140314 DE リモートインタプリタ Rails開発 - Qiita

EclipseやVisualStudioでも、JavaやC#の環境でデバッグ時に、ローカルサーバー上のWebサービスのソースをデバッグできる設定がある。
RubyのIDEでは、IntelliJ+RubyプラグインまたはRubymineが優れていると聞いているが、同様にできるみたい。
Rubyのようなインタープリタ言語でリモートデバッグできるとはすごいな、と思ったりする。


| | コメント (0)

2014/01/04

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代

2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。
#ラフなメモ書き。

【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。
何故なのだろう?

また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。
DOAやOOAは全く含まれていない点が衝撃だった。

ITアーキテクト カンファレンス 2013

最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。

【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。
ITの歴史の延長線上にあるだけで、そんなにすごい価値があるわけではないだろう、と。
単に仮想化なんでしょ、と。

クラウドサービスも、大昔のデータ計算センターや電算受託から始まったシステムサービス提供形態の現時点での変化形に過ぎない、と。

実際、ERPやメールサーバなどをクラウドへ構築する場合でも、フィットギャップ分析、セキュリティレベル、運営のコンセプト確認、負うべきリスクの整理、サービスレベル(SLA)の定義、など、従来の手法で検討する必要がある点は変わらない。
システム、ネットワークなどの利用面の進展があっても、利用に当たっての検討項目は本質的には同じである。

【3】しかし、クラウドが新しい観点をもたらし、アーキテクチャ設計に大きな影響を与えた点は2つあると思う。

【3-1】一つは、インフラ構築もアジャイルにプログラミングで開発できること。
その意味については、下記の記事で色々考察した。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例: プログラマの思索

「Infrastructure as Code」というキーワードがまさにそうであるように、サーバー構築手順は全てプログラム化できる。
従来は、サーバー購入や構築手順をあらかじめ計画段階で入念に実施し、レビューしてから作るというウォーターフォール型開発っぽいやり方しかなかったけれど、クラウドのおかげでサーバー構築もアジャイルに開発できる。

アジャイルに開発できる利点の一つは、失敗を何度も許容できる点があるだろう。
特に、サーバーの障害テストや負荷テストを何度もやり直せる利点はとても大きい。
従来なら、サーバーの負荷テストや障害テストは、準備も実行もすごく手間がかかりすぎて、何度もやり直すべき作業ではなかった。
アジャイルに障害テストや負荷テストを実施できることで、最初の計画を完璧にしなくても、プロトタイプのようにサーバーを構築して実現可能性(フィージビリティ)を調査したり、運用に合わせてハードウェア構成を柔軟に変える、などのオプションを持つことができる。

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

また、クラウド化することで新たに判明する点は、ソフトウェアの品質がそのままコストに跳ね返ってくる点だろう。
例えば、CPU使用量やメモリ使用量を10%削減できれば、請求代金を10%削減できるのだ。

クラウドではソフトウェアの品質が課金の差として出てくる: プログラマの思索

つまり、クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差=パフォーマンスの差=課金の差=コストの差=利益率の差

従来は、一度、サーバーを構築したら、そのハードウェア構成を変えるのは、次のハードウェアリプレースまでできなかったが、クラウドなら、柔軟にハードウェア構成を変えることができる。
したがって、クラウドによって、ソフトウェアの品質特性として、特に効率性(パフォーマンス)がより重要になってきた側面があるだろう。

他にも、クラウドによって、システムの移植性が高まる、信頼性の観点は壊れないシステムよりもすぐに直せるシステムの方が重要、など、品質特性の観点が変わってきた。
今後は、クラウドとエンタープライズのシステムの組合せでは、機能性や信頼性よりも、保守性・移植性・効率性の品質の方が重視されてくるだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

なお、クラウドで使われるツールで注意すべき点は、Chefなど、Rubyで書かれたプログラムが多いこと。
クラウド時代のサーバー構築では、Rubyという技術が必須になってきているように思える。

【3-2】もう一つは、DOAやOOAやサーバー構築の設計では、その時代の技術の制約があったために、バッドノウハウになっていた箇所に対し、クラウドを使うことで本来の目的がクローズアップされたこと。

クラウドを使ったサーバー構築の設計では、クラウドデザインパターンがまとめられているので、参考にすべきだろうと思う。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

クラウドアーキテクティング原則 - AWS-CloudDesignPatternに掲げられた下記の原則は、クラウドの使い方について的確に示していると思う。

◆できるだけサービスを利用
◆机上実験よりも実証実験
◆スモールスタートからスケールアウト
◆変化に対し全レイヤで対処
◆故障のための設計(Design For Failure)
◆最初だけでなく周期的なカイゼン

また、DOAでは、サマリ系テーブルは夜間の日次バッチ処理(特にCobol)で作る、とか、正規化しているために参照関係の複雑なテーブルを結合して参照するしかない、などの弱点が従来はあった。
でも、クラウドが出てきて変わった点は、MapReduceのような並列処理と相性が良いので、大量データを短時間で処理できる設計も可能になったこと。

更には、RDBを使うとパフォーマンスが出ない場面では、クラウドと相性の良いNoSQLを組み合わせて、KVSやドキュメント指向DB、列指向DBなどを使うことで、問題解決できる場面があること。
よく聞く場面は、SNSやソーシャルゲームのログイン時にユーザ情報を参照する処理のように、単純な参照処理だが大量のアクセスが発生する状況で使われる。

データベース技術の今後の動向: プログラマの思索

最近「ビッグデータ」というバズワードが頻出される理由は、クラウドが並列処理と相性が良く、大量データを短時間に処理できるために、大量データから意味ある論理を導くデータマイニングが注目されているからだろうと思う。
従来のDOAでは、データウェアハウスのような設計思想もあったけれど、パフォーマンスが悪くて、なかなか手軽に使えなかった状況があったからだ。

現場の業務システムは、運用後にかなりのトランザクションをためているものの、それらのデータを解析(データマイニング)して、そこから得られた知恵を再利用する手法はほとんど取られていない。
よくある例は、購買履歴から顧客の購買動向を分析するCRMが欲しいという要望が多かったが、その仕組みが従来はなかなか作りにくかった、という弱点があったと思う。
Amazonのおすすめ商品のような協調フィルタリングを実装するのは敷居が高い。

他にも、従来のDOAでは、製造業向け生産管理システムのMRP(部品の所要量計算)、会計システムの自動仕訳とPL・BSレポート出力も、普通は日次バッチ処理で1日1回(または月次バッチで月末1回、年次バッチで1年に1回)作られるだけだった。
従来のDOAを支えるRDBMSの制約、バッチ処理プログラムの性能が出ないなどの制約などの理由で、夜間バッチ処理でしか対応できなかったのだ。

「オンプレミス・システムの終わり」の始まり~AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

クラウドのもう一つの本質~ソフトウェアの可搬性を確保する: プログラマの思索

でも、クラウドとデータマイニング・データ集計の並列処理を組合せることで、CRMのデータを手軽に作り出せる。
MRPによる原価計算や、自動仕訳後のPL・BS出力も1日数回以上実施できるようになる。
そうすれば、原価計算や会計処理、CRMなどの経営分析も、アジャイル開発っぽく、何度も試行錯誤しながら仮説検証していくスタイルを実施しやすくなる利点がある。

最近、リーンスタートアップという経営手法が注目されている。
その理由は、経営手法でもアジャイル開発のやり方を実践して効果が出せるからだと思うが、その背景には、クラウドを使って、少人数でWebサービスをリリースすればすぐにビジネスを開始でき、スケールアップも容易である特徴を生かしているからだと思う。

クラウドという単なる一つの技術が、従来のDOAやOOAでは解決しにくかった問題に対して有効である場面が増えてきている。
それら効果についても今後、追いかけてみる。

【追記】
クラウドとセットで語られるNoSQLについては、7つのデータベース 7つの世界の本が個人的にはお勧め。
7種類のDB(PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redis)の特徴について、広く深く記載している。サンプルソースもあるので、とっつきやすい。

| | コメント (0)

2013/07/02

メールからRedmineのチケットを自動登録する時の注意点

メールからRedmineのチケットを自動登録する時の注意点をメモ書き。

【1】第8回RxTStudy勉強会で、@g_maedaさんは、顧客からの問合せメールをRedmineのチケットに自動登録する機能によって、ヘルプデスク管理をチケット管理に置き換える事例を紹介している。

第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

メール対応に付随する苦労の多いヘルプデスク管理をRedmineのチケット管理に置き換えたことによって、チケット管理の恩恵が得られる利点を強調されていた。
その反面、下記の課題がまだ残っていると話されていた。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
 メール対応という一つの目的で2つのツールを使っている。
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
 古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
 顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
 忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
 メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の課題のうち、手運用でカバーせざるをえないのは、(1)(3)(5)だろう。
(2)は、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきかもしれない。

そのうち、(4)と(6)の解決策について、考えてみた。

【2】サポートデスクからの送信メールと顧客からの受信メールで、同一のチケット番号を振るようにするプラグインを@yusuke_kokuboさんが公開されている。

Redmine Mail Intergration plugin - こくぼ@Everything is the experience.

(引用開始)
◆背景
Redmineにはチケットが更新されたときなどにメールで通知してくれる機能があります。さらにその通知メールに返信することで注記を書けたりします。
さらには、Redmineのメールアドレスを宛先に含めておくだけでRedmineがメールを受信してチケットにできる機能もあります。
いろいろ便利な機能がそろっているのですが、うちの会社の使い方ではちょっと痒いところに手が届きません。

◆なにに困ってるの
マネージャ「お客さんからこんなこと頼まれたんだけど、Aさんこの作業お願い!」
とお客さんからの依頼をAさんのメールアドレス宛にRedmineのメールアドレスをCCに入れて転送しました。*1
Redmineはメールを受信してチケットに起こして通知メールを投げます(投げったっけ?)。

◆Aさんが受け取ったメール
この時点でAさんはマネージャからのメールとRedmineからの通知メールを受け取っています。
AさんがRedmineからの通知メールに返信すればRedmineは注記として処理できます。しかし元々のマネージャからのメールに返信すると、Redmineは返信元のチケットを特定できないので、新たにチケットを作成してしまうのです。注記にできないどころか無駄なチケットが作られてしまいます。困りました。

◆そこで作ったプラグイン
Redmineがメール受信したときにメールのMessageIDと処理したチケットNoを覚えておくプラグインを作りました。
この場合でいうと、最初にマネージャが投げたメールを処理したときにMessageIDとチケットNoをDBに保存します。
そしてAさんからの返信を受信したときに、メールのin-reply-toからMessageIDを検索して処理元のチケットを特定します。

◆まとめ
これでRedmineを意識できない人でもとりあえず宛先にRedmineのメールアドレスを含めておいてもらえば、チケットに履歴が残っていってハッピーになれるかもしれません。
(引用終了)

つまり、(4)顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを一つのチケット番号でまとめる機能は、上記のプラグインで実現されている。

但し、MessageIDとチケットNo、ユーザ名を保持する新規テーブルが1個増えるので注意。
また、GitHubのemail.rakeを見ると最新版よりも古いので、パッチを当てるなどの動作検証が必要と思う。
だから、すぐに上記のプラグインですぐに解決できるとは限らないのが残念だ。

YusukeKokubo/redmine_mail_intergration

redmine_mail_intergration/lib/tasks/email.rake at master ・ YusukeKokubo/redmine_mail_intergration

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

上記のプラグインの機能をRedmine本家に取り込んでもらえないのだろうか?

【3】(6)発信元アドレスがチケットに記録されない課題については、RedmineはCRMソフトとして使えるか?: プログラマの思索にも書いたけれども、顧客問合せメールからRedmineチケット登録時に、顧客を新規ユーザとして登録する機能を使う方法もある。

メールからチケット登録する場合のRedmineのオプションはRedmine本家のWikiに書かれている。

RedmineReceivingEmails - Redmine

Redmineのソースemail.rakeを読むと、下記のオプションがある。

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

(引用開始)
General options:
unknown_user=ACTION how to handle emails from an unknown user
ACTION can be one of the following values:
ignore: email is ignored (default)
accept: accept as anonymous user
create: create a user account
no_permission_check=1 disable permission checking when receiving
the email
no_account_notice=1 disable new user account notification
default_group=foo,bar adds created user to foo and bar groups
(引用終了)

つまり、「unknown_user=create」オプションを追加すれば、Redmineのユーザーが作成されるのでメールアドレスを保持できる。
さらに、「default_group」オプションを追加すれば、作成されたRedmineユーザのユーザグループまで設定が可能だ。

従って、あらかじめ顧客ユーザだけを含むユーザグループ「顧客」を作っておき、顧客問合せメールからRedmineチケット登録時に、顧客をRedmineユーザとして新規登録するだけでなく、新規Redmineユーザとして「顧客」ユーザグループに属するようにオプションを使えばいい。

つまり、Redmineのユーザグループ=取引先企業、ユーザ=企業の担当者としてマッピングすれば、「企業◇--担当者」の関係を実現することができる。

例えば、外部サーバーからメールサーバーへIMAPで問合せメールを検知する場合、下記のようなrakeコマンドになるだろう。

#supportプロジェクトにbugトラッカーでチケット登録し、ユーザは顧客のメールアドレスで新規登録する。
#さらに、新規ユーザは、fooユーザグループに属する。

rake redmine:email:receive_imap RAILS_ENV="production" \\
host=imap.foo.bar username=redmine@somenet.foo password=xxx ssl=1 \\
project=support \\
tracker=bug \\
unknown_user=create \\
no_permission_check=1 \\
default_group=foo \\
allow_override=tracker,priority

但し、TO・Ccアドレス、Subjectの情報はチケットに登録してくれない問題はまだ残る。
Redmine本家に対する今後の改善要望となるだろう。

【3】「メールからRedmineのチケットを自動登録する」機能に注目する理由は、メール駆動の業務をチケット管理へ置換できる可能性を感じるからだ。
普通の社会人ならば、毎日数十~数百通のメールを受け取って、その返信に追われていないだろうか?
実際の仕事は、顧客からの問い合わせメールやシステムの障害検知メールなどが起点となって始まる場合が多い。
すると、メールの履歴を追いかけながら仕事せざるを得ず、メールという古い機能に縛られた流れでしか仕事できない。

メール駆動の仕事の弱点は下記に書いた。
メール駆動はExcel駆動と同様に、何らかの解決策が必要ではないだろうか?

メール駆動開発は時代遅れではないか: プログラマの思索

管理のためのExcelをチケット管理が駆逐しているように、外部とのやり取りはメールというインターフェイスで行っていたとしても、社内ではチケット管理で回せる仕組みが作れないか?
今後も考えてみる。

【追記】@sakaba37さんが、(1)(3)(5)の問題点に対し、返信メールを受け取る時に「ステータス=New(新規)」でチケット更新すればよいのではないか、と提案されている。
新規ステータスならば、問合せタスクが終了していないので、必ず対応状況のチェックで引っかかるから、現実的な解決策になると思う。
rakeコマンドにstatus=newをセットすればいいので実装は問題ない。

但し、rakeコマンドではデータをロードできないため、結局はシェルスクリプトでメールのヘッダ情報を取得する処理を作りこむしか無い。
From・To・Ccアドレスをrakeコマンドだけでチケットに表示できない課題はまだ残る。

[#Redmine] Redmineによるメール対応管理 - 第8回 #RxTstudy -: ソフトウェアさかば

(引用開始)
さて、前田さんの発表で課題とされていたものに、チケット番号が間違っているものや、クローズしたものの場合がありましたが、これは、関連チケットのステータスをnewか適当なものにすれば良いと思います。
ステータスを変える方法には色々あると思いますが、メールハンドラーを修正しなくてもメールの最後に「Status: New」という行を追加するフィルタのスクリプトを、メールハンドラの前にかませれば良いと思います。
こうすると、クローズされていないメールを管理するだけで、番号違いなども拾う事ができるでしょう。
(引用終了)

svn.redmine.org/redmine/trunk/lib/tasks/email.rakeを読むと、statusのオプションがあるので、実現可能だ。

(引用開始)
Issue attributes control options:
project=PROJECT identifier of the target project
status=STATUS name of the target status
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes
(引用終了)

【追記2】
@sakaba37さんが上記の課題に対して、幾つかの方法を試されている。

[#Redmine] Redmineによるメール対応管理(その2) - 検証編 -: ソフトウェアさかば

| | コメント (0)

2013/06/30

第5回品川Redmine勉強会の感想 #47redmine

第5回品川Redmine勉強会にスタッフとして参加してきました。
盛り上がって楽しかったです。
資料をリンクしておきます。
感想をラフなメモ書き。

【参考】
第5回勉強会 - shinagawa.redmine

第5回品川Redmie勉強会 2013/6/29 - Togetter

【1】@sakaba37さんの資料。
共通結合、データ結合などのソフトウェア結合度の観点と業務フローの類似性のお話と、社内業務にRedmineを適用した事例のお話。
構造化設計のお話は、今では情報処理試験に出るくらいしか使わないから、ピンと来る開発者はいたのかな?
社内業務で、PC資産のタスク管理にRedmineを使った事例は興味深かった。
ある業務でタスクが発生して、そのタスクを管理したい時、チケット管理は有効であるように思う。

【2】その後、「マネージャ」「開発者」「運用担当者」「Redmineシステム管理者」の観点でワークショップ形式で議論した。

いろんな議論が出てきた。
皆同じような問題を持っているのね、と共感している人も多かった。

僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。
顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。
トラッカー=顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。
実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。

この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。
このアイデアは、第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理機能にも関連する。
この辺りのアイデアはあとでまとめる。

他には、@naitohさんのRedmineシステム管理者としてのノウハウや事例が面白かった。
RedmineのVerUp作業は結構面倒だ。
Redmineを導入すると、開発チームはRedmineなしでは作業できなくなるので、気軽に改造したりVerUpして正常動作しなくなるのが怖いので、VerUpするのが難しくなる。

@naitohさんの話では、Ver1.4からBundlerでRubyGemをインストールするようになったおかげで、インストールしたRedmineの単位でRubyGemを管理できるようになった。
だから、Ver1.4以降では、異なるバージョンのRedmineを併存するのも問題ないとのこと。
特にVerUpするための検証作業で、既存の古いバージョンのRedmineと、検証中の最新バージョンのRedmineを一つのサーバーに入れている時は、Ver1.4以降なら問題ないみたい。

但し、プラグインはRedmineのVerUpで動作しなくなるので要注意とのこと。
Redmineは2.1になるまでに、Rails2→3、Ruby1.8→1.9、Prototype→JQueryへアーキテクチャが変わったために、追いつけていないプラグインが多い。

第8回RxTStudy勉強会で@marutosijpさんが言っていたように、プラグインと言えどもテスト自動化して日々ビルドする環境がなければ、ミドルウェアやライブラリのバージョンアップ作業に追いつけずに破綻してしまう危険があるのだろう。
改めて、TDDとCIの強みを印象づけられた。

また、Redmineのバックアップはやってますか?という質問もあった。
@naitohさんは、SQLiteなのでファイルコピーでやってます、とのこと。
@akiko_pusuさんからは、MySQLならDMP出力、Redmineの添付ファイルはrsyncでお手軽にやっています、というお話もあった。
DBのDMP出力、ファイルの同期作業は、Cronで日次に夜間に実施するなどすればよいだろうと思う。

【3】@tkusukawaさんのテーマ説明やLTでは、ヘッダに電子公告のように流れるメッセージが面白かった。

Twitter / hiyoshism: 勉強会の真っ最中に上司から「Redmineの導入は見送ります」というメールが届いた俺が来たよ。 #47redmine

【4】日経システムズの記者さんのLTでは、記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITproの記事の裏話を少しだけ聞くことができた。
読者アンケートを取った結果では、Redmineの読者評価が高いらしい。

Twitter / akiko_pusu: Redmineの特集は何回もやってます。なぜか読者評価が高いです。アンケートでは普及率22% #47redmine

日経システムズという雑誌は、IT業界でしか読まれないだろうし、日経の雑誌を購入する層を考えると、SIの中堅~大企業の30代以降のSEやPM層が多いだろうと思う。
20代の開発者はそもそも購入する人はかなり少ないのではないだろうか?
また、日本のSIではアジャイル開発を採用している会社はほとんどないだろうし、おそらくウォーターフォール型開発が主流の会社で、Redmineを使っている現場が多いのだろう。

そういう読者セグメントを考えると、Redmineは日本のSIの開発現場で好まれやすいツールなのではないか、という仮説が思いつく。
ウォーターフォール型開発が主流の中では、XPやScrumを実践できないけれども、それでも軽量かつ規律ある開発をやりたい現場にチケット駆動開発がマッチしているのではないか、と想像する。
その議論については、以前、本来のチケット駆動開発(TiDD)とは何なのか? - Togetterでまとめた。

Twitter / quicy: あえて残念な言い方をすれば、チケット駆動開発は、XP/Scrumを実践できない現場、それでも規律的なライトウェイト開発をやりたい、という現場開発者のための、救済なんちゃってアジャイル手法だと思う。

Twitter / quicy: 自分がBugzillaでチケット駆動開発と呼ばれる以前のものをやっていた時には、チーム外からは「ツール使ってるのね」という認識だけで、そこにある軽量さと規律の両立の妙を、なかなか理解してもらうことができなかった。名前と体系化は重要ですね。

この辺りのアイデアも色々まとめてみたい。

| | コメント (0)

2013/06/12

Rubyのガントチャート生成ツールTaskJuggler

フリーのマインドマップFreeMindをいじくっていたら、エクスポート機能にTaskJugglerという項目があった。
TaskJugglerはRubyのコマンドラインによるガントチャート生成ツールらしい。
以下メモ書き。

【元ネタ】
taskjuggler/TaskJuggler · GitHub

TaskJuggler 3 超入門 - 目次とTaskJugglerのインストール:プロジェクト管理 -- フリーソフトでやってみよう:So-netブログ

TaskJuggler - A Free and Open Source Project Management Software - About TaskJuggler

TaskJuggler 3.4.0 on Windows/on MacOS X:プロジェクト管理 -- フリーソフトでやってみよう:So-netブログ

TaskJuggler|オープンソース・ソフトウェア、ITニュースを毎日紹介するエンジニア、デザイナー向けブログ

Taskjuggler を mac にインストールしてみた - takenoko1977の日記

Bluetooth詳説 - TaskJugglerについて

TaskJuggler を触り始めた

nDiki: ガントチャート - 今日のさえずり: 男性が1人でするならマンションで、複数でするならメンションです (2012-02-07)

nDiki: ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

【インストール方法】
Rubyはインストール済み

gem install taskjuggler

tj3 --version
TaskJuggler v3.4.0 - A Project Management Software

【使い道】
サンプルファイルtutorial.tjpに対し、下記を実行すれば、HTML出力される。

tj3 tutorial.tjp

DSL風に、WBSやら期間、工数、担当者を入力すると、ガントチャートやバーンダウンチャート、リソースグラフなどを出力してくれるらしい。
出力形式はHTMLもあるし、色々あるみたい。
但し、PDF出力はない。

Product Burndownのサンプルは下記の通り。

Scrum Example Project - Product Burndown

コマンドラインしか使えないので、スケジュールに関するデータをテキスト形式に書かないといけない。
また、TaskJugglerのためのマクロを覚えないと、希望通りに出力されない。
でも、逆に言えば、テキストファイルでスケジュール管理できるので、バージョン管理で簡単に履歴管理できる。

元ネタのスケジュールをテキストで履歴管理するだけでなく、Webサーバー上へ定期的にHTML出力して公開するようにするやり方もある。
つまり、スケジュール管理も継続的インテグレーションで定期ビルドしてしまえばいいのだ。

使い道を色々考えてみる。

| | コメント (0)

2013/05/19

テスト駆動開発による組み込みプログラミングも良い本です

テスト駆動開発による組み込みプログラミング」を頂きました。
ありがとうございます。
既に色んな方が感想を書かれています。

【元ネタ】
「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook

[書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com

O'Reilly Japan - テスト駆動開発による組み込みプログラミング

書籍『テスト駆動開発による組み込みプログラミング』:柴田 芳樹 (Yoshiki Shibata):So-netブログ

"これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評

テスト駆動開発は設計技法である~組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索

C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモックのプログラミングが難しいため、C特有のテクニックが必要になる。
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」では、テストダブルのようないくつかのテクニックが公開されているので、組み込み系の人にとっては注目すべき内容だろう。

TDDによる設計の観点では、SOLIDという設計原則でまとめられている。
アジャイルソフトウェア開発の奥義」に詳しく書かれている。

・単一責任の原則(SRP)
・オープン・クローズドの原則(OCP)
・リスコフの置換原則(LSP)
・依存関係逆転の原則(DIP)
・インターフェイス分離の原則(ISP)

詳細は「オブジェクト指向の法則集@石井勝さん」のページが詳しい。

TDDでプログラミングする利点の一つは、テストしやすいインターフェイスを考えることで、自然にプログラム設計でき、しかもプログラムの品質も良くなることだろう。
手続き型言語でガリガリ書くと、どうしても長いメソッドになり、後からテストしにくい設計になってしまいがち。
ドライバやスタブでテストできるようにするには、そのようなインターフェイス設計にしなければならないからだ。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」は組み込み系の人だけでなく、JavaやRubyの人にも参考になる本だと思います。

| | コメント (0)

2013/02/24

CentOSにRubyをインストールする

CentOSにRubyをインストールする方法はいくつかある。
rvmでインストールするのが一番簡単だったのでメモ。

【元ネタ】
さくらVPS/CentOS 6.3 Ruby 1.93/RVMのインストール手順[Railsサーバへの道] - 酒と泪とRubyとRailsと

RubyはRPMがなかなか見つからない。
できれば、1.9.xを入れたいがRPMをソースから作るか、ソースからmakeしてインストールするかのいずれかしかない。

上記の記事では、rvmをインストールして、rvmからRubyの複数バージョンをインストールする方法が書かれている。
この方法ならば、1.8と1.9の両方を使えるし、rvmをアンインストールすればいいだけ。

sudo yum -y install curl curl-devel gcc gcc-c++ git openssl-devel httpd-devel readline-devel tk-devel make zlib-devel libffi-devel

sudo yum --enablerepo=epel -y install libyaml-devel

sudo bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

sudo usermod -a -G rvm root
sudo gpasswd -a ateam rvm
sudo gpasswd -a apache rvm

source /etc/profile.d/rvm.sh
rvm get head

rvm install 1.8.7
rvm use 1.8.7
rvm install 1.9.3

rvm use 1.9.3 --default

rvm list
で確認

cp -ip /etc/rvmrc /etc/rvmrc.org
vim /etc/rvmrc

rvm_trust_rvmrcs_flag=1
を追加

gem install bundler --no-ri --no-rdoc
もOK

| | コメント (0)