« 2010年5月 | トップページ | 2010年7月 »

2010年6月

2010/06/28

iPadZine~iPadで読める電子書籍サービス

opakenさんがiPadで読める電子書籍サービスiPadZineを公開していたのでメモ。

【元ネタ】
「iPadZine」iPadでもっと電子書籍を読みたい人のための投稿サービスを作りました (eXtreme Gadget (エクストリーム ガジェット) ポケットに入るアジャイルな究極の小道具)

iPadZine - 無料の電子書籍投稿サービス

【説明文】
iPadZine(アイパッドジン)は、iPadで読める電子書籍の投稿とダウンロードが簡単にできるサービスです。
あなたが投稿した電子書籍は、iPadで直接ダウンロードしてその場で読み始めることができます。
iPadZineでは、様々な電子書籍に対応しています。一般的なPDFやEPUB形式だけでなく、i文庫HD用のテキスト原稿や、画像の圧縮ファイルなどのダウンロードも可能です。

青空文庫や有料の電子書籍ではなく、Blogや写真、テキストファイル、発表資料など、普通のファイルを電子書籍に変換してiPadで読めるようにしてくれるWebサービス。
とても使い易い。

電子書籍がこれだけ注目を浴びているのに、日本でなかなか普及しないのは、コンテンツがないから。
いわゆる既得権者がなかなか公開しないのが理由にある。
でも、Blogや写真、発表資料のような普通の素材でも、十分に電子書籍で読めるようになる。

まずは、Blogを電子書籍にしてしまえばいいのではなかろうか?

| | コメント (0) | トラックバック (0)

2010/06/27

Rebaseとトピックブランチ

Gitのリベース(Rebase)機能がようやく分かったのでメモ。
MercurialのMQは、GitのRebase機能を実現する重要な機能だ。

【元ネタ】
git rebaseって超便利じゃね? - Seasons.NET

Gitを使いこなすための20のコマンド - SourceForge.JP Magazine : オープンソースの話題満載

履歴の書き換えによって生じる問題

Mercurial: "Managing change with Mercurial Queues" を読む(3) | Inside ASCADE

Pro Gitの日本語

Mercurialではじめる分散構成管理:第6回 勝手に「分散構成管理」 ~非Mercurial環境との共存|gihyo.jp … 技術評論社

4.6. コミット ― TortoiseHg v0.8.2 documentation

Subversion ユーザーが Git を使ってみた (基本操作編) - まちゅダイアリー(2010-05-06)

入門Mercurial Linux/Windows対応」によると、リベースとは「ベースとなるソースを更新する」意味。
入門Git」では、216頁の図13-1.トピックのリベースで詳しく解説されている。

トピックブランチは、タスクブランチの一種で、一つのテーマに関してだけ修正や機能追加を試みるブランチ。
GitやMercurialなどの分散バージョン管理で多用されるブランチだ。

トピックブランチの利点は、メインライン(trunk)に中途半端なソース修正をコミットしないことと、トピックブランチでメインラインと無関係に自由に実験出来ること。
前者の利点は、メインラインが常時リリース可能な品質を保証できるし、後者の利点は、パッチやハックを自由に行って、実験できることにある。

しかし、メインラインでどんどん機能追加されていって、トピックブランチのソースが古くなった場合、どこかの時点で、トピックブランチへtrunkからPullしなくてはならない。

入門Git」によれば、トピックブランチへtrunkからPullするのは初心者が陥りやすいミスだと言う。
何故なら、trunkからマージされると、せっかくトピックブランチで育んだパッチが動かなくなるからだ。

だから、trunkからトピックブランチへのマージは、Rebaseが推奨されている。
Rebaseの仕組みは、トピックブランチのパッチを作り、更にtrunkの最新リビジョンから新規ブランチを作り、その新規ブランチへトピックブランチのパッチをマージすること。
つまり、Rebaseとは「ベースとなるソースを更新する」意味で文字通り、トピックブランチ→trunkへマージ作業が行われて、メインライン(ベースとなるソース)が更新される。

Rebaseによってコンフリクトが起きたり、動作しなくなったとしても、コミット履歴はtrunkへトピックブランチのパッチが当てられたことで残るので、その後の改修がやりやすくなる。

逆に、trunk→トピックブランチへPull(実際はmerge)すると、トピックブランチのパッチが動作しなくなってしまう危険性が高い。
コミット履歴は、トピックブランチへtrunkの機能がマージされたことが残るので、パッチの部分が分かりにくくなる。

GitがMercurialよりも優れている利点の一つが、Rebaseを使ってトピックブランチにturnkの新機能を追加しながら、トピックブランチを育てることが簡単なことにある。
最新版のMercurialでも、MQの機能がRebaseの機能を代用してくれるので、Rebaseを実施しやすくなった。
TorotiseHgでも、MQの設定をすれば、Rebaseが使える。
※注意:Mercurialでもrebaseコマンドがあり、Gitと同等な機能になっている。

分散バージョン管理の最大の利点である自動マージ機能は、トピックブランチの品質向上に大きく寄与してくれる。
トピックブランチのワークフローはバグ修正のそれと全く同じなので、システムテストや受入テストなどリリース直前のテスト管理や品質管理で大きな威力を発揮するだろうと思う。

最後に、「入門Git」は分散バージョン管理を使いこなす上で最もお勧めの書籍だ。
特にトピックブランチとRebaseの関係について詳しく説明している13章「リモートリポジトリ定義」と、OSSで主流のワークフローであるパッチ作業について説明している10章「パッチベースのワークフロー」は、非常に重要だ。

入門Mercurial Linux/Windows対応」にも12章「ソースアーカイブベースの勝手Mercurial化」で、MercurialのRebase作業について書かれているので要注意。

【補注】
objectxさんのコメント通り、Mercurialのextensionでrebaseコマンドが使えるようになっている。

RebaseExtension - Mercurial

tortoisehgならば、mecurial.iniへ
[extensions]
rebase =
を設定するだけでいい。

| | コメント (2) | トラックバック (0)

Pro Git 日本語版

分散バージョン管理Gitの解説本がPDFで公開されいていたのでリンクしておく。

Pro Git 日本語版PDF(Google Docsによるプレビュー)

※追記:
Pro Git 日本語版PDF (2011-05-06).pdf - Google Docs

Gitのコマンドの解説というよりも、実際のコミットのシチュエーションを例に解説してくれているので分かりやすい。
特に、トピックブランチにおけるリベース(Rebase)の図が良い。

GitやMercurialを使っているならば、トピックブランチを使って、マスターリポジトリのソースをハックしてパッチを当てながら、機能追加したりバグ修正したりする。
その時に、Rebaseを上手に使えば、マージ作業で品質が劣化することもないだろう。

入門Mercurial Linux/Windows対応」によると、リベースとは「ベースとなるソースを更新する」意味。
GitのRebaseは、MercurialのMQに相当する。
トピックブランチとRebaseは、GitやMercurialを使いこなす上でとても重要な概念なので、整理してみたい。

【追記】
Gitから日本語版PDFを作成する方法が書かれている。

携帯電話(Galaxy S II)で電子書籍(Pro Git)を読む

ProGitの英語版でepubも公開されている。

Pro Git - Table of Contents

| | コメント (0) | トラックバック (0)

TDDとTiDDの違い

角谷さんのつぶやきが、どういうコンテキストで話をしているのか、聞いてみたい。

Twitter / KAKUTANI Shintaro: TDDとTiDDの違いについて自分なりに整理がついたが、それを書くには140文字では足りないが日記力はもっと足りない。

RubyKaigi2010に関連していま思っていること, Pivotal TrackerのGetting Startedの翻訳, 2年前の動画をいま見てくれた人がいたということとRSpecのMacroについて - 角谷HTML化計画(2010-04-14)

| | コメント (0) | トラックバック (0)

2010/06/22

Redmine用テスト管理プラグインRedcase

HaruさんがRedmine用テスト管理プラグインRedcaseを紹介していたのでメモ。

【元ネタ】
Haru's blog: Redcaseのソースが公開された

Browse Redcase Files on SourceForge.net

RedCase is the first test case management plug-in for Redmine | QA Project

上記の画面を見ると、テストケースの管理やテスト結果の管理はできているようだ。
バグ管理システムBugzillaとテスト管理用プラグインTestopiaのように、RedcaseはRedmineのテスト管理用プラグインのデファクトスタンダードになるだろうか?

TestLinkに置き換えられるのか、興味深い。

| | コメント (0) | トラックバック (0)

2010/06/20

派生開発カンファレンス2010の記事

派生開発カンファレンス2010に参加した人のBlogが少しだけあったのでメモ。
「インターネットなどを用いた、セッション内容の無断転載を禁止する」通知があったそうで、公開されていないのはすごく残念。

【元ネタ】
「派生開発カンファレンス2010」開催案内

派生開発カンファレンス2010に参加 - Basic

派生開発カンファレンス2010に参加してきた - あしのあしあと

#xddp2010 派生開発カンファレンス2010 - ハッシュタグクラウド

TweetBuzz - 「派生開発カンファレンス2010」開催案内

「派生開発カンファレンス2010」開催案内: プログラマの思索

日本発の開発プロセスに関して、事例を中心としたカンファレンスだったようで、聞いてみたかった。
聴衆も、日本のお家芸といえる製造業を親会社に持つ組み込み系SIが多かったと思われる。
今時の開発は、スクラッチ開発よりも既存のプログラムを流用して、更に機能追加していく時が非常に多い。
つまり、新規開発というよりも、ソフトウェア保守だったり、カスタマイズを中心とした派生開発になる。

又、組込製品やパッケージ製品の開発では、一つの製品が良く売れた場合、その製品を元に移植したり保守したりして、次々に派生した製品ファミリーを作っていく時が多い。
この開発スタイルは、いわゆる製品ファミリー開発、つまりソフトウェアプロダクトライン(SPL)の開発プロセスになるだろう。
製品ファミリー開発で最も成功した例は、MSのOffice製品だったり、AppleのiPod/iPhone/iPadの製品群が相当するだろう。
もちろん、日本の携帯のように、カメラ、着メロ、写メール、オサイフケータイなどの機能を次々に追加していった製品も当てはまる。

ソフトウェアプロダクトラインの開発における特徴は、品質特性のうち移植性や保守性を重視していることだ。
実際、スクラッチで開発するよりも、コア資産やプラットフォームの上に次々に新機能を追加していくスタイルになるからだ。
そんな開発では、XDDPのような派生開発は非常に参考になるだろう。

カンファレンスの内容を是非公開して、日本のソフトウェア産業のスキルアップに役立てて欲しいと思う。

| | コメント (0) | トラックバック (0)

もう一つのテスト管理ツールTestopia

BugzillaのアドオンにTestopiaというテスト管理ツールがあるらしい。
TwitterでTestLinkを検索していたら、たまたま見つけた。

【元ネタ】
Twitter / Search - testlink

Questions on TestLink Tool - Software Testing Club - online QA & Software Testing Community

Bugzilla Main PageからのTestopiaデモサイト

Extension:Testopia Reports - MediaWiki

Testopia:Documentation - MozillaWiki

Testopia_Manual.pdf

もう一つのテスト管理ツールRTH: プログラマの思索

TestLinkの隠れ機能~工数集計とステータス設定: プログラマの思索

Testopiaのマニュアルを読んだだけで実際は知らないが、TestLinkのサブセットのようなテストケース管理ツールのように思われる。
テスト計画、テストケースとテスト結果はTestopiaで管理して、失敗したテストケースのバグ管理はBugzillaと連携しているようだ。

面白いと思ったのは、テストケース実行結果のステータスに「Idle:未実行」「Passed:成功」「Failed:失敗」「Blocked:ブロック」以外に「Running:調査中」「Paused:一時保留」があること。

- IDLE: This is the default status. Case has not yet been examined.
- PASSED: This test case met the requirement or ran as expected.
- FAILED: This test case did not run as expected or produced an unhandled exception.
- RUNNING: This test case is currently being examined.
- PAUSED: This status is used to denote a problem with the test case itself that prevents the test from being completed.
- BLOCKED: This test case has a dependency that failed.

上記2個のステータスのTestopiaの使い道はよく知らない。
だが、TestLinkを運用した経験から、何となく分かる。

「Running:調査中」は、テストを実施したものの、テスト結果を精査中で「成功」「失敗」を判定できていない時に使うだろう。
例えば、Amazonのような小売Webシステムでクレジットカードの注文フローを複雑なデータパターンでテストした場合、テスト結果はすぐに採取するが、テスト結果を精査するのに時間をかける時に使う。
だから、テストを実施してテスト結果(エビデンス)を取得する担当者と、そのテスト結果を精査する設計者の2人が交互に作業するワークフローになる。

TestLinkの隠れ機能~工数集計とステータス設定: プログラマの思索にも書いたが、「Running:調査中」はとにかくテストの見かけ上の進捗を先に進めたい時に使いたいのだ。

「Paused:一時保留」は「テスト完了を妨害するテストケースそのものに問題がある時に使う」と説明されている。
よく分からないが、テストケースそのものが間違っていて、テスト不能な状態を示していると思われる。
最終的には、顧客へ受入テストのテスト仕様書と結果を提出する時には、そのテストケースは削除する必要があるだろう。

Bugzillaを運用している人は、Testopiaを使ってもいいのではないだろうか?

| | コメント (0) | トラックバック (0)

Redmineの次のリリース日は?

Redmine 0.9.5のリリース予定日が過ぎているのに、Redmineがなかなかリリースされていない。
Redmine - Why the 0.9.5 is delayed? - Redmineのように、皆、いつリリースされるのか気にしている。

【元ネタ】
Redmine 0.9.5

Twitter / yusuke-kokubo: #redmine 1.0.0 RCのリリース予定日まであと15日なわけだけど…。

Redmine - Why the 0.9.5 is delayed? - Redmine

Twitter / Eric Davis: Redmine 0.9.5 release scheduled for next week (21st - 26th).

Redmine.JP | Redmine on Twitter

Redmineのコミッタと思われるEric Davis氏のTwitterによると、6月のnext week (21st - 26th)にリリースされるだろう、とのこと。

次のメジャーバージョンアップであるVer1.0も7月に控えている。
Ver1.0は、チケットの親子関係を実現するSubtaskingなど、たくさん機能拡張されているので、おそらく皆心待ちにしているに違いない。

Jean-Philippe Lang氏は休暇に出かけているのだろうか??

| | コメント (1) | トラックバック (0)

2010/06/19

ObserverパターンとMulticastパターン

JavaよりもC#が優れている点は、Deledateという機能があるおかげでイベント通知のロジックが書きやすい点にある。
Javaでは、Multicastというデザイパターンでカバーする必要がある。
平鍋さんの記事が分かりやすいのでメモ。

【元ネタ】
- デザインパターンによる進化的設計

Jude開発記

- Java プログラマのためのデザインパターン入門

[Effective C#] 項目21 デリゲートを使用してコールバックを実現する | まさくらのブログ

デザインパターンにあるObserverパターンは、デスクトップアプリを作る時に非常に重要なパターン。
GUI上のイベントをキャッチして、次のイベントを発火するロジックに使うから。

しかし、- デザインパターンによる進化的設計に書いてあるように、Push型のObserverパターンでもPull型のObserverパターンであっても、情報取得のロジックでキャストが発生する弱点がある。
つまり、画面の情報を取得して次のイベントを発火するする際に、イベントのオブジェクトタイプを判定(instanceof)して分岐する必要があるのだ。

updateメソッドでキャストが発生するということは、コンパイルエラーのチェックが効かないこと、つまり、タイプセーフ(型安全)でないことを意味する。
すなわち、オブジェクト指向に沿っていないのだ。

その解決方法として、Multicastパターンがある。
MultiCastパターンは,GoFの23パターンに含まれていないが、パターンハッチング―実践デザインパターン (Software patterns series)という本では、GoFの間でデザインパターンに入れるべきかどうか激論があったという節がある。

このパターンは、JavaではSwingのリスナー、C#ならDeledateが相当するだろう。
つまり、複数のイベントが発生して制御する場合は、各イベントに対応する各リスナー(Delegate)を用意して、リスナーをキューに溜め込んで、イベント変更の通知タイミングでリスナーを発火させる。

例えば、Javaのリスナーには、addListener(), removeListener()のようなメソッドを用意すればいい。
C#の場合は、Delegateに「+=」「-=」というメソッドがあるので、より直感的。

個人的には、Javaの方が仕組みがシンプルな分、手続きが多いけれど、仕組みが丸見えなので好きだ。
実際のコーディング量はC#の方が減るだろう。

Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻すに書いたけれど、JavaによるWebプログラミングには上記のようなイベント処理を書く状況が全くないと言っていい。
とはいえ、JavaScriptがクライアントアプリで重要になってきた現在、デスクトップアプリのベストプラクティスであるデザインパターンは、もう一度見直してもいいと思う。

| | コメント (0) | トラックバック (0)

IPAが公開したRubyやRails教育プログラム

IPAがRubyやRails教育プログラムを公開しているのでメモ。

【元ネタ】
情報処理推進機構:オープンソフトウェア:OSS人材育成:OSSモデルカリキュラム導入実証

IPA(独立行政法人・情報処理推進機構)は最近RubyやRailsに力を入れているようだ。
上記のPDFを読んでみると、Rubyプログラミング、MySQLの使い方、Railsのプログラミングについて、丁寧に書かれている。
Ruby初心者ならば、上記の教材を使って、プログラムを書く練習をすれば、無料で勉強できるだろう。

IPAは日本のIT業界のエスタブリッシュメントが集まった団体というイメージを持っているが、彼らは昨今のIT動向に非常に詳しいように思う。

| | コメント (0) | トラックバック (0)

テストツールはアジャイル開発と相性が良い

「テストツール導入の起爆剤はアジャイル」――英Micro Focus製品責任者が語る - ニュース:ITproを読んで思ったことをメモ。

【元ネタ】
「テストツール導入の起爆剤はアジャイル」――英Micro Focus製品責任者が語る - ニュース:ITpro

アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-

テストツールとアジャイル開発の相性が良い理由は、頻繁にリリースするためにはテスト工程の効率化が必須であること。
アジャイル開発では、イテレーション又はスプリントという定期的なタイミングでリリースしながら、機能拡張していく。
そのためには、設計・実装・テストを頻繁に繰り返す。
つまり、単純作業や同じ作業は自動化しようという動機が生まれるし、そのサイクルを早く回すほど品質も機能もどんどん良くなる。

テスト駆動開発は単体テストの品質を保証するし、継続的インテグレーションはコードラインが常時リリース可能であることを保証する仕組み。
この仕組みがあるから、XPは猿のように早く作ることができる。

しかし、機能テストや受入テスト、負荷テストでは、上記のプラクティスだけでは物足りない。
アジャイル開発チームのテストの観点については「アジャイルテストの4象限」という概念で、アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-で詳しく述べられている。

TestLinkは従来のアジャイル開発の弱点であった受入テストで、テストケース管理やテスト結果の管理やワークフロー管理を行うことで手動のテストの効率化を図ろうとする。
TestLinkを運用してみて、テスト管理や品質管理の技法には奥が深いことを痛感した。
そのプラクティスやアンチパターンは下記でまとめた。

TestLinkのベストプラクティス集: プログラマの思索

TestLinkのアンチパターン: プログラマの思索

特にテストは、データパターンによる単純な作業のテストや同じテストケースを何度も実施する回帰テストが多い特徴があるので、テスト管理ツールを導入して運用できた場合、その効果は非常に大きいと思っている。

| | コメント (0) | トラックバック (0)

最近のソフトウェア開発に政治力が必要になってきた

iPadを通勤電車で開いている人を見かけるようになってきた。
iPadの普及に伴い、電子書籍の動向に興味を以ている。
思ったことをメモ。

【元ネタ】
Life is beautiful: 電子出版に関する一考察:コンテンツのガラパゴス化の危機

Life is beautiful: 電子書籍ビジネスとフォーマットのオープン化と

日本の電子書籍に必要なたった一つのこと - もとまか日記

日本の電子書籍ビジネス 日販とトーハンが邪魔しているのか? - MIRAI THE FUTURE

最近のソフトウェア開発を見て思うことは、政治力やマネジメントという技術力以外の要素の比重が大きくなってきたことを痛感する。

Redmineでチケット駆動開発を実践すると、運用を効果的に考えることは確かに楽しいし、Redmineをカスタマイズするのも楽しい。
しかし、ITS(Issue Tracking System)をアジャイル開発のプロジェクト管理に使おうとするならば、チケットの取捨選択やロードマップというリリース計画作りなどのマネジメント力が重要になってくる。
本来のマネジメントが見える化されるために、マネジメントの技量がそのまま公開されてしまうのだ。
マネジメントの重要性を知らないチームは、チケット駆動開発はアジャイルごっこに過ぎない。

電子書籍もそう。
電子書籍リーダーなどの技術は既にソニーなど日本企業が先行していた。
しかし、日本では著作権やら出版社の利権が絡んで、電子書籍そのもののコンテンツがオープンにされないために、電子書籍リーダーのハードを作る製造業、電子書籍リーダーのソフトを作るソフトウェア企業が育ちにくい。
だから、日本の携帯はガラパゴスと言われたように、日本の電子書籍もガラパゴスと言われるかもしれない。

電子書籍が日本で思ったほど普及しないのは、技術があっても、流通業者や出版社などの利害関係者を調整する能力が日本のソフトウェア企業や製造業にないからだ。
今のソフトウェアビジネスは、政治力がかなり重要性を増しているような気がする。

最近思うのは、製造と小売を結ぶ流通という仕組みが、商社や卸問屋のような仲介業者がIT化によって無用の長物になり、逆に進化を阻害していること。
Google、Apple、Amazonのような企業が目指しているのは、流通をIT化してプラットフォーム化することによって、無数の開発者や企業が集まって、一つのエコシステム(生態系)を成し遂げていること。
足りない機能やサービスがあっても、それをニッチなマーケットと見なすことによって小さな企業でも参入できる余地がある。

上流工程の業務分析をやっていると、流通が絡む業務は複雑になりがち。
流通という業務が絡むと、取次業務が増えるため、仕入業者へ請求書の発行や出荷指示書を印刷したり、など無駄な仕事が増える。
流通という業務がない方がシンプルでモデル化しやすい。

プラットフォームという基盤があれば、生態系のように自己修復や自己最適化を多数の人の意思によって成し遂げる。
だからこそ、オープンソースというからくりが非常に重要になってくるのだろうと思う。
実際、日本の電子書籍のデファクトスタンダードは青空文庫とその文庫リーダーだ。
有志の方が無料で広めてくれたおかげで、日本語という縦書きに向いた文章のインフラが整った。
i文庫やSkyBookは非常に使い易いし、読みやすい。
そして、自分で作ったテキストを簡単に電子書籍にコンバートして、読むこともできる。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

電子書籍の作り方part3: プログラマの思索

オープンソースやBlog、Twitterというからくりは、僕自身もその構造を完全に理解できていないけれど、その影響力は我々が考えている以上に大きく広い。
今から電子書籍をやるなら、青空文庫の仕組みやアプリを真似た方が今後も生き残るだろう。

最近のソフトウェア開発は、技術力だけでなく、政治力やマネジメント力の比重が高まっている気がする。

| | コメント (1) | トラックバック (0)

2010/06/13

Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す

JavaでWebアプリを10年書いて思ったこと。
Webプログラミングは全然オブジェクト指向でない。
Sevlet+JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。

従来のWebプログラミングスタイルの問題点について書いてみる。
以下ラフなメモ書き。

【参考リンク】
Wicketって?

ウェブ開発をもう一歩前に

Wicketで始めるオブジェクト指向ウェブ開発:第1回 Hello, Wicket|gihyo.jp … 技術評論社

【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイコミジャーナル

【レポート】Wicket入門 - JavaとHTMLだけで作るWebアプリケーション (1) Wicketとは? | エンタープライズ | マイコミジャーナル

Javaで軽快に使える「軽量フレームワーク」特集 ~Apache Wicketで簡単Webアプリ作成(1)(1/5):CodeZine

【問題点 1】MVC2モデルは全然オブジェクト指向でない

オブジェクト指向はデスクトップアプリのプログラミングで試行錯誤した歴史から生まれた。
その基本思想は、MVCモデルにある。
MVCモデルは、Model・View・Controllerがあたかも生きているように、お互いにメッセージを通知して自分自身を更新する。
この設計思想のおかげで、複雑なデスクトップアプリを作れるようになった。

しかし、Webプログラミングは基本は、MVCモデルを変形したMVC2モデルから成り立っている。
StrutsもRailsも同様。
StrutsならActionServletがHTTP経由のやり取りを制御し、擬似的なMVCモデルを作り出す。

しかし、MVC2モデルでは、本来のモデルは出てこない。
JSPとServletの間では、従来と同じく、String型の値を渡しているだけ。
ServletはActionにリクエストパラメータを渡し、ActionはまさにVBライクに手続き型でプログラムを書いて、レスポンスへ結果を渡すのが普通。

だから、GoFのデザインパターンをフルに使えていない。
Webアプリにはイベントという発想がそもそもないのだ。
その根本原因は、Webアプリには「画面の状態を保持する」という仕組みがないことに尽きる。

そこから派生する問題については、以前Blogにも書いた。

Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ: プログラマの思索

【問題点 2】JavaよりもXMLを書いている時間が長い

Strutsが出現した2002年頃は、画期的なWebフレームワークだった。
何故なら、従来のJavaのWebフレームワークは大手SIが独自に開発した俺俺フレームワークが主流で、どれも使うのが苦痛だったから。
Strutsによって、ActionServletがJSPとActionの橋渡しを担当して、プログラマはXMLに設定ファイルを書いて、Actionだけに業務ロジックを書くのを専念すれば良くなった。

SeasarもRailsもStrutsの進化系に過ぎない。

しかし、XMLに画面遷移やフォームのバリデーションチェックなど各種のロジックを書くスタイルのために、JavaよりもどんどんXMLが膨らむ。
そもそもXMLに書いた方がJavaプログラムを変更しなくていいというのが利点だったらしいが、そのために、あちこちにロジックが散在してしまう。
Webプログラミングとは、ミドルウェア構築作業のように、たくさんのソースと設定ファイルの海を泳ぎ渡るもの、というイメージを大半の人が持っているのではないか?

だからこそ、SeasarやRailsはConversion on Configuration(CoC)の思想によって、コーディング規約を徹底することによって、設定ファイルをなくす方向へ進化した。

JavaではXMLは必要悪。
Railsはメタプログラミングできるので、XMLを保持しなくても、データがRubyプログラムのように扱えることでカバーしているが、発想は同じだ。

【問題点 3】セッション管理が大変

Webアプリで最も難しいのがセッション管理。
Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じだ。
セッションがWebアプリで重要な理由は、画面の状態をセッションに保持する必要があるからだ。

どのタイミングでセッションにデータを入れて、いつ更新して、いつ消すのか?
そのライフサイクルをプログラマが逐一考慮しないといけない。
C++のメモリ解放の問題のように、セッションクリアを忘れると、意味不明なバグが多発する。

セッション管理の問題点は下記に書いた。

Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ: プログラマの思索

Railsが持つCookie Session Storeは、セッションに保持した画面の状態をクッキーに保持しようとする。
利点は、画面の状態を復元するのが簡単なこと。
でも、根本的な解決方法ではないと思う。

Webアプリによく現れる問題「戻るボタン(バックボタン)」「注文ボタンの2度押し(二重ポスト)」「マルチウィンドウ」などは、従来のWebフレームワークでは解決できていない。

ブラウザの戻るボタンを使った後に再実行すると、予期しない結果に陥る。
注文処理を実行中に注文ボタンを2回押すと、2回注文されてしまうバグが発生する。
注文画面で同じ画面を複数個立ち上げると、予期しない動作が起きてしまう。
これらの処理を制御するために、Webプログラミングはややこしいロジックをいつも入れている。

【Wicket】
最近、Wicketに興味を以ている。
WicketはJavaのWebフレームワークで、Strutsのソースと全く違う。
C#のデスクトップアプリのプログラミング、Java のSwingのプログラミングみたいに、内部クラスや匿名クラスを多用する。
C#のDelegateがJavaにサポートされれば、もっと短く書けるんだろうと思う。

Webアプリを書いていて、オブジェクト指向って本当は何なの?みたいな気がずっとしていた。
Wicketなら、Webアプリをデスクトップアプリみたいに書ける。
オブジェクト指向、デザインパターンをフルに使える余地がある。

オープンソース徹底活用 WicketによるWebアプリケーション開発」を読んで理解できた点を書いてみる。

【Wicket 1】「Webアプリにオブジェクト指向を取り戻す」。つまりデザインパターンがフルに使える。

デスクトップアプリは手続き型からオブジェクト指向へ進化した時に、デザインパターンという優れたプラクティスを発見した。
だが、Webアプリではデザインパターンはそんなに使えていないのが現状。
MVC2モデルでは、所詮は手続き型プログラミングだから、Strategyパターンぐらいしかまともに使えていない。

でも、Wicketのソースはデスクトップアプリのプログラミングスタイルそのもの。
イベントを内部クラスや匿名クラスで書くから、デザインパターンをフルに使える。
Commandパターンは、イベントをキューに貯めるのに使えばいい。
Stateパターンは、画面の状態に応じてイベントを振り分けるのに使えばいい。
ObserverパターンやMulticastパターンは、オブジェクト変更の通知と更新に使えばいい。

これがオブジェクト指向なんだ、と理解できるから、書いていて楽しいはず。

【Wicket 2】セッション管理を考えなくていい

Wicketでは、HTMLはオブジェクトになる。
つまり、画面の状態はオブジェクトがいつも持っている。
その状態はセッションに保持されている。

オープンソース徹底活用 WicketによるWebアプリケーション開発」を読んだものの、Wicketのセッション管理についてはまだ理解出来ていない。
でも、メモリ管理のガベージコレクションのような機構をWicketは持っているみたい。
つまり、セッションの解放をプログラマが書く必要はないはず。

オープンソース徹底活用 WicketによるWebアプリケーション開発」を読んで面白かったのは、「戻るボタン」「二重ポスト」「マルチウィンドウ」の問題をWicketは解決出来ていることだ。
オープンソース徹底活用 WicketによるWebアプリケーション開発」の「すべてのページはURLを持つ」で詳しく説明されているが、Wicketでは、処理結果を表示するURLとフォーム送信先のURLを分けていて、処理結果を表示するURLのページオブジェクトを作った後に、フォーム送信先のURLへリダイレクトしているのが味噌だ。
更に、Wicketでは画面をバージョン管理して画面の状態を保持している。
デスクトップアプリなら、とても当たり前の動作なのだが、Webアプリではとても難しい。

そのおかげで、いつも画面の状態を知っているから、「戻るボタン」を使ってもどのタイミングで戻ったのかが分かる。
「注文ボタンの2度押し」があっても、同じ結果ページを再取得するだけで何も変えない。
「マルチウィンドウ」になっても、複数の画面はどれも独立している。

Wicketで面白いと思ったもう一つの特徴は、RedirectToUrlExceptionというリダイレクトを行う例外クラスがあること。
RedirectToUrlExceptionの使い道としては、現在の処理をすべて破棄して、別画面へリダイレクトできること。
よくある例は、注文や会員登録で再ログインさせる処理があるだろう。

リダイレクト処理はWebアプリでは結構面倒なのだが、Wicketならば、Javaの普通の例外処理として扱える。

【Wicket 3】Ajaxのように画面の部分更新機能を持つ

Ajaxの特徴の一つは、オフラインでも画面の一部を部分更新出来ることがある。
これによって、逐一サーバーに問い合わせて、セッションの状態を確認しなくても、画面のユーザインターフェイスをリッチに変えることができる。

オープンソース徹底活用 WicketによるWebアプリケーション開発」を読むと、WicketはAjaxの機能を使って、HTMLの一部を部分更新する機能を持っているらしい。
例えば、実行中であることをインジケータで表示したりすることもできる。

すると、サーバーに問い合わせて画面遷移して更新する場合とローカルで画面を部分更新する場合の2種類をWicketは意識的に使い分けることができる。
特に、後者のやり方だけで画面遷移できるならば、デスクトップアプリと同じ動きになる。
つまり、画面遷移する場合と画面の部分更新を意識して使い分ける設計が優れていれば、画面のユーザインターフェイスはかなり使い易くなるだろう。

Wicketは書いたことないけど、書いていて楽しそうな気がする。

| | コメント (1) | トラックバック (0)

2010/06/10

TortoiseHgはSVNクライアントとしても優秀

TortoiseHg1.0.4とhgsubversionを組み合わせると、簡単にTorotiseHgがSVNクライアントになる。
とても便利になったのでメモ。

【元ネタ】
TortoiseHgでSVNを使う方法: プログラマの思索

durin42 / hgsubversion / wiki / Home ― bitbucket.org

9. 他のバージョン管理システムとの相互運用 ― TortoiseHg v1.0.0 documentation

TortoiseHgでSVNリポジトリをチェックアウトできちゃった件 | endflow.net blog

durin42 / hg-git / overview ― bitbucket.org

MOONGIFT: ? MercurialでGitを扱う「the Hg-Git mercurial plugin」:オープンソースを毎日紹介

プログラムだろうが、Excelの仕様書だろうが、Wordの原稿だろうが、PPTの発表資料だろうが、ローカルでは全てTortoiseHgで管理している。
やっぱりバージョン管理は楽しい。
安心して修正できるし、コミットログを眺めるだけでも楽しい。

TortoiseHgの利点は、分散バージョン管理なので、ブランチのクローンを作ってマスタリポジトリと同期をとるのが簡単なことと、PushやPullなどでマージ作業が楽なこと。
Ver1.0以降、hgsubversionのパスを設定すれば、TortoiseHgがSVNクライアントに様変わりする。

使い方はこんなイメージ。
SVNをマスターリポジトリにして、TortoiseHgでローカルにリポジトリを作り、個人的なハックはローカルにコミットしておく。
最終的なソースをコミットする時は、SVNのマスターリポジトリへローカルリポジトリのリビジョンを指定してPushすればいい。
Gitにおけるgit-svnも同様の発想だろう。

他に、TortoiseHgからGitリポジトリへアクセスできるhg-gitもあるらしい。
こちらは試していないが、実用に耐えうるならば、サーバーのSCMが何であっても、クライアントはTortoiseHgだけで十分。

いろいろ試してみたい。

| | コメント (0) | トラックバック (0)

Perlのお勧め本

久しぶりに本棚にあるPerlの本を読んだのでメモ。

Perlの本と言えば、ラクダ本「初めてのPerl 第5版」が真っ先に浮かぶだろうが、僕の相性はよくなかった。
結城浩さんのPerl本「新版Perl言語プログラミングレッスン入門編」を読んで、ようやくPerlを理解できて使えるようになった。

初心者向けに書かれているが、正規表現やパターンマッチングなどを最初は易しく、後になるほど奥深く書かれている。
この本をマスターすればPerlは一通り書けるようになる。

新版Perl言語プログラミングレッスン入門編」のAmazonレビューにも書かれているが、Perlの入門編というだけでなく、Ruby・PHP・PythonなどLL(軽量言語)の入門編とも言える。
新版Perl言語プログラミングレッスン入門編」で正規表現を理解できたから、Rubyプログラミングにもすんなり馴染めた。

Perlで中級以上なら、「Perlベストプラクティス」が良いだろう。

結城さんは「増補改訂版Java言語で学ぶデザインパターン入門」など、読みやすいだけでなく、本質的な事柄を分かりやすく説明してくれているので、どれもお勧め。

| | コメント (0) | トラックバック (0)

2010/06/06

今の日本の会社でイノベーションを起こせるのか?

すだち師匠さんが会社でハッカソン(Hackathon:Hack- a-thon)をやった記事を読んで思ったことをメモ。

【元ネタ】
ハッカソンをやりました - mnishikawaの日記

社内のプログラミング好きな人達が、会社の施設を使って、好きな時に自由に好きな事をプログラミングできる環境は素晴らしい。
ソフト会社であるからには、やはりプログラミングで、自由な発想の元にどんどん書きまくって動かして、一つの作品に仕上げたいものだ。

優れたアイデアというものは、その時の気分や今までの思索、同僚からの助言から生まれる時が多いように思う。
個人のアイデアであっても、会社という環境、同僚と言う環境に大きく依存していると思う。
イノベーションは、個人と周囲の環境の複合物から生まれる。

しかし、昨今の日本のビジネス情勢を振り返ると、会社でハッカソンがやりにくいように思う。
会社は所詮は営利企業。
会社の施設を使ったとしたら、その経費はどこで落とすのか?
その経費は必ず四半期ごとの損益計算書・貸借対照表で公開されて、マーケットから常に監視される。
黒字ならいいだろうが、リーマンショック後の景気で赤字になれば、そんな余裕すらもない。

しかも、最近は残業禁止令が出ている会社も多い。
サービス残業すれば、労働基準局から詰問がくる。
だから残業代を払わないように、勤務時間をよりこまめにチェックする体制になる。
特に、J-SOXやコンプライアンスが定着してから、会社の管理がとても厳しくなった。

一昔前の日本の製造業では、工場の現場で、品質や生産性をいかにあげていくか、社員が自立して考えて行動する雰囲気があったのではないか。
多分それがQCサークル。
日本人が大好きなプロセス改善、品質改善も、QCサークルの遺産だろう。

しかし、コンプライアンスの悪影響が現れているのは、製造業のQCサークルや改善活動ではなかろうか?
QCサークルという自主的な活動の経費はどうなるのか?
残業代を払ってでも行う価値がある活動なのか?
そもそもQCサークルは自主的な活動であり、現場の地道な改善であるから、すぐに効果が現れるものではない。
それらの問いかけに対して、QCサークルも品質改善の活動も常に投資対効果を意識したものになってしまい、本来の機能を果たさなくなったのではないか?
試行錯誤しながら少しずつ改善していく活動を長い眼で評価する雰囲気がなくなってきたのだろう。

今の日本では、QCサークルのようなプロセス改善の活動は、少なくとも非常にやりにくい雰囲気になっている。
日本の製造業の強みとされた部分も、今の時代ではうまく活かされていないように思う。

でも、会社の外に目を向ければ、オープンソースやコミュニティなどの機運もある。
今の時代は、会社に閉じこもっていてはスキルの向上が見込めない。
自らオープンソースやコミュニティ活動に関わっていかないと、自社に特化した環境に慣れてしまってしまい、いざ会社の外に出ると自分のスキルが通用しない時代なのだろう。

今の日本の会社の環境ではイノベーションは起こしにくいだろうと思う。
IT業界では少なくとも、イノベーションはオープンソースを中心とした世界へ移ってきているように思う。

| | コメント (0) | トラックバック (0)

2010/06/05

Vistaの無限再起動

Vistaのバグにはまったのでメモ。

【元ネタ】
「更新プログラムを構成しています:ステージ 3/3 - 0%完了」でフリーズして、無限再起動 - 原因は「KB929547」? - Windows Live

Windows Vista および Windows 7 で更新プログラムをインストールするときに、更新プログラムが正常にインストールされず、メッセージが表示され、コンピューターが再起動される

VistaのWindows Update後に無限再起動の不具合 :: 男の日記

Vista 再起動を繰り返す それなりに/ウェブリブログ

Vista起動時に「更新プログラムを構成しています」が表示され無限再起動からの修復:It's a Tak by SkillExplore:So-netブログ

パソコン暦13年の無知: Vistaの無限ループにはまる

VistaでWindowsUpdateをかけると、更新途中で再起動を繰り返す致命的なバグ。
インターネット上で検索すると、溢れるほど見つかるから、数多くの人が被害にあっているのだろう。

Vistaの評判は散々で結局、Windows7に皆流れている。
こんな致命的なバグを放置して、マイクロソフトは大丈夫なのか??
多分彼らも、余りにも馬鹿でかくなったOSを持て余しているのだろう。

しかも世の中は、デスクトップPCからiPhone/iPad/Androidのようなスマートフォンなどへシフトしつつある。
Googleはクラウドとそれに関連する技術をどんどん突き進めている。
いずれの技術方向も、デスクトップPCの優位性を崩そうとしている。

マイクロソフトは大丈夫なのかな?

| | コメント (0) | トラックバック (0)

2010/06/02

障害管理の泥沼から脱出するには

リンク先から下記の記事を見つけたので、考えたことをメモ。

【元ネタ】
こんにちは。 ソフトウェアの不具合管理をしているのですが、現在はエクセルファイルを複数社で メール添付で行っています。 この方法だと、 ・どれが最新かわからなくなる.. - 人力検索はてな

不具合管理(障害管理)はソフトウェア開発の中で最も重要で、そしてコントロールが難しいマネジメントだ。
ウォーターフォール型開発で設計、開発、単体テストと順調に進んでも、結合テストや受入テストに入ると、バグが多発してしまって品質がボロボロになってしまうケースは数多い。

ソフトウェア開発が製造業など他の産業の工程と異なる箇所は、結合テスト以降の障害管理だと思う。
各種のモジュールを初めて結合して、インターフェイスが違っていたり、仕様通り作っていても性能が出なかったりする症状が分かる。
いわゆるビッグバン結合で頻発する。

上記の質問を読むと、地理的に分散した複数の開発チームと障害管理をメールベースで行っているようだ。
この状況では、抜本的な対策を打たない限り、泥沼から抜け出すのは難しいだろう。
というのも、障害の履歴を管理できておらず、どのバージョンに障害修正をリリースしていくかというマネジメントができていないように思えるからだ。
更に、複数の会社の開発チームが地理的に分散しているようだから、コミュニケーションの距離も遠いから尚更だ。

上記の解決方法は三つあるだろうと思う。

一つ目は、障害管理ツール(BTS)を導入すること。
Excelで障害の状況を管理し、メールベースで障害履歴を残しているから、バグ発見やバグ修正、バグ検証の状況が混乱しているのが原因の一つ。
まずは、Bugzilla、Mantis、Trac、RedmineなどのBTSを導入し、全てのバグはBTSで一括管理すればいい。
そうすれば、バグの記載漏れがなくなるし、障害履歴がBTSで統一されるから、バグの最新情報をいつでも誰でも共有できる。

BTSにはバグ修正のステータス管理機能が必ずあるので、バグ修正をワークフロー管理することによって、PGとテスターがペアプロのように作業できる。これによって、バグ検証は必ず二人の目を通すことによって品質向上できるはず。

二つ目は、メインラインモデルによる構成管理と継続インテグレーションによるビルド管理をセットで導入すること。
上記の質問には書かれていないけれど、障害修正が難しい理由の一つは、本番環境のバグを開発環境でバグ修正したとしても、構成管理やビルド・リリース管理に不備があるために、デグレが多発することだ。
デグレが多発すると、他人が作った成果物そのものの信頼がなくなるために、チーム内の信頼関係が壊れてしまう危険な症状だ。

メインラインモデルによる構成管理を当てはめれば、本番環境と同じメインライン(trunk)とバグ修正・バグ検証を行うタスクブランチ(トピックブランチ)でソースを使い分ければいいだろう。
つまり、メインラインはいつもでリリースできるコードラインであり、本番環境と同値。
タスクブランチは開発者がバグ修正を試すブランチと使い分ければいい。
あるいは、一つのトピック(バグ)を修正して検証するだけのブランチ(トピックブランチ)を作ってもいい。
とにかく、バグ修正のお試しコードラインと本番環境と同値のコードラインは使い分けないと、たくさんの手を入れる分、品質はすぐに劣化してしまう。

そして、HudsonなどのCIツールを導入して、バグ修正したコードラインを常時ビルド&リリースできるようにして、バグ修正とバグ検証のタイムラグを無くす。
バグ検証が完了したビルド番号のSCMリビジョンから、パッチを作り、trunkへパッチをマージすればいい。
MercurialやGitなどの分散バージョン管理を使えば、ブランチ管理やマージ作業はより楽になるだろう。

三つ目は、どのバージョンにどの障害修正を入れてリリースするか、リリース判定を下す課題管理会議を定期的に開催すること。
つまり、開発者・プロジェクトマネージャ・プロダクトオーナーなどのステークホルダーが集まって、どのバージョンをどのタイミングでリリースするか、そのバージョンにどんな障害修正を混ぜるか、今バグ修正はどんな状況なのか、どのバグを後回しにすべきか、などを決める。

例えば、アジャイル開発ならばスクラムオブスクラム、ITILならCAB(変更諮問会議)、PMBOKならCCB(変更管理会議)と言われる会議に相当する。
この会議こそが本来のマネジメントに相当する。

ユーザが業務でどのバグで困っているのか、リリース時期と要件の優先順位が出る。
そして、開発者の工数見積もり、多数のバグの依存関係から、どのバグを直していくか、作業の優先順位が出る。
ユーザと開発者のバランスから、バグ修正の優先順位が決まり、どのタイミングでリリースするか、バージョンを付ければいい。
つまり、リリースする機能のスコープ(範囲)を決めることで、納期と工数のバランスを崩さないようにする。

定期的にバグFixをリリースしていければ、リリース予定バージョンがイテレーションに相当するように自然に運用できるはず。
すなわち、課題管理会議はXPの計画ゲームを実践したり、Scrumのプロダクトバックログを決めたりする重要な会議なのだ。
だから、上記の状況ならば、定期的に自社と複数の会社が集まって課題管理会議で、バグ修正のリリース時期の確認、バグの棚卸しを行うべきだ。

障害管理が上手でない開発チームは、いくらBTSや構成管理ツール、ビルド管理ツールが揃っていても、リリース判定を下す会議(課題管理会議)でマネジメントの意思決定を行っていないために、泥沼にはまる。
マネジメントの弱い開発チームは、ソフトウェア開発に必ず失敗するように思う。

更に、地理的に分散しているならば、課題管理会議を開くには、Skypeやテレビ会議などのツールでサポートするしかないだろう。
つまり、リリース判定を下す会議を開催するハードルが高いという難点がある。

障害管理の泥沼から脱出するには、これら三つの解決方法が最低限必要だと思う。

| | コメント (0) | トラックバック (0)

« 2010年5月 | トップページ | 2010年7月 »