astah*Professionalファーストインプレッション

ようやくastah*Professionalを購入した。
JudeCommunityを2004年に使い始めてから5年以上経ち、色んな機能を使ってみたくなった。

astah* professional6.0の新機能

EnterpriseArchitectやRationalRoseも使ってきたけれど、astah*ProfessionalのUIや操作感の簡便さにはかなわない。
EnterpriseArchitectは殆どのモデリングをカバーしていて機能も豊富でピカイチだけれど、僕は何かフィットしなかった。
自分のアイデアをUMLで色んなダイアグラムで書きながら分析していく時に、サクサク書けるスピードはastah*Professionalが一番かなと思う。

astah*Professionalで気付いたのは、UMLがVer2.0に対応している事。
UMLはVer2.0になってとても複雑になったように思うが、その理由はおそらく組込みシステム向けのモデリング記法を整備したかったからだろう。
業務系システムや普通の開発ならば、UMLのVer1.x台で十分と思う。

astah*Professionalで面白い機能と思うのは下記5つ。

1・ER図
2・マインドマップ
3・フローチャート、DFD
4・要求テーブル、テストケース
5・JudeAPI

ER図があるおかげで、astah*Professional上でデータモデリングも可能。

マインドマップは要求分析で要求の洗い出し、要件の定義に使える。
でも、FreeMindに慣れているので、FreeMindと互換性があると嬉しいのだが。

要求テーブルやテストケースは興味惹かれる機能。
SysMLに合わせた仕様らしく、まだ使い方が分からない。
TestLinkの要件やテストケースがそのまま使えるならば、「要求→モデル←テストケース」の形で追跡可能になる。
モデルのトレーサビリティが可能になるから、試してみたい。

また、JudeAPIはJavaやJRubyからastah*Professionalのモデル情報を取得できる。
下記のように、モデルからファンクションポイントを自動計算できれば、見積りの精度が上がる。

JUDE改めastah*、ファーストインプレッション - TECH-moratorium ： テクモラトリアム

JRubyでJUDE CRUD-APIを試す - TECH-moratorium ： テクモラトリアム

JUDE APIでFPを算出するアプリ - TECH-moratorium ： テクモラトリアム

astah* Community Site - フォーラム

分析設計モデルをわがままに活用しよう　JUDE API入門（1/5）：CodeZine

他にも色々試してみたい。

クラウドではソフトウェアの品質が課金の差として出てくる

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日の文言「クラウドではソフトウェアの質は課金の差としてでてくる」が秀逸なのでメモ。

【元ネタ】
InfoQ: パフォーマンスを硬貨で測る

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日

(前略)
クラウドプラットフォームでは、CPU使用量を10%削減すれば、そのままクラウドプロバイダからの1ヶ月の請求が10%削減されることになる。
例えば、 Windows Azureは1計算機による1時間の計算に12セントかかる。
このことを知った上でよいプロファイラを使えば、文字通り特定のコードブロックが会社に1ヶ月どれくらいコストを発生させているかを言うことができるだろう。
(後略)

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

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

データストアがRDBからkey-value storeへシフトする流れがある理由は、クラウドによって、ソフトウェアの品質、特にパフォーマンスの差が利益率に直結する事実が大衆の目の前に出てしまったからだろう。

クラウド上のSW開発は、関数型言語によってデータ処理をMapReduceアルゴリズムでいかに高速化するか、が鍵を握るのかもしれない。
「クラウドコンピューティングは開発者にとってゲームのやり方を変えてしまうものである。」という指摘はとてつもなく鋭い。

クラウド時代のSW開発スタイル

「Twitterの衝撃 140文字がビジネスからメディアまで変える」を立ち読みした。
TwitterがRuby on Railsをフロントエンドで使っているのは知っていたが、メッセージの非同期処理(MQ)でScalaを使って性能改善したという説明があった。
気になったのでメモ。

【参考】
まだブロ: [Scala] Twitterの移行について

twitterがrubyからscalaへスイッチ - huixingの日記

第7回 関数脳のつくり方　First Season - 刺激を求める技術者に捧げるScala講座：ITpro

ScalaはJavaVM上で動く関数型言語。
TwitterがScalaをどこでどのように使っているのか、正直理解できていない。

しかし、大量のデータをさばく処理に対し、関数型言語を使ってMapReduceアルゴリズムで高速化を図っているのではないか、と推測している。
そのためにScalaを使ったのではないか、と。
上記の記事や本によれば、Scalaによるチューニングは大成功だったらしいから、そのノウハウが知りたい所。

Twitterは当初はRuby on Railsでアジャイルに実装しているという印象があった。
しかも、サーバーはクラウドのサービスを利用している。
#Twitter のホスティングは NTT Americaとのこと(コメントを受けて修正)

つまり、サーバー運用をアウトソーシングしているので、スケールアップしやすく、初期投資のリスクも低い。
クラウドというサービスは、ベンチャー企業にとってとても扱いやすいビジネス環境なのかもしれない。

今後のWebシステムの開発スタイルはこんな感じ。
フロントエンドはRailsやSeasarでサクサク作り、バックエンドやバッチ処理は関数型言語でMapReduceアルゴリズムをフルに使って高速化する。
そして、サーバー運用はクラウドのサービスを使ってアウトソーシングし、初期投資のリスクを抑えて、負荷が高まればスケールアップすればいい。

スクリプト言語、関数型言語、そしてクラウドが、今後のWebシステム開発のキーワードになるかもしれない。

Webシステム開発のトレンド

2002年頃、Strutsが出た時は興奮した。
それまでフリーでオープンソースのWebフレームワークは無かったから。

同じ頃、Eclipseが出てきた。
Javaの統合開発環境がフリーで、しかもプラグインを追加すれば、UMLやメトリクス出力、JUnitなど色んな機能を追加できる。
Eclipseでサーバー上のモジュールをリモートデバッグできた時は感動した。

Strutsが出る以前は、ベンダ製のWebフレームワークを覚えさせられて、正直嫌だった。
フレームワークのAPIを覚えても、他社プロジェクトで使えない。
フレームワークにバグがあっても、ソースが公開されてないので直せない。
結局、バッドノウハウが増えて、変なパッチが当てられて、どんどんソースが汚くなる。
そして、運用保守になると、誰もソースを触れなくなる。

日本のパッケージベンダーが駄目な理由: プログラマの思索
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

Eclipseが出る前は、ベンダ製の統合開発環境を高値で購入せざるを得ず、誰もが気軽にプログラミングできる環境がなかった。
特にVisualStudioに慣れていると、ベンダ製のJavaの統合開発環境はUIも機能も洗練されておらず、開発効率も悪かった。

Tomcat＋Struts＋Eclipseがあれば、Webアプリをフリーな環境でフリーなフレームワークを使って開発できた。
デザインパターン、オブジェクト指向プログラミング、リファクタリング、JUnitによるテスト駆動開発を実際に試す事ができて、結構面白い時期だった。

それから、Railsが出てきた時も衝撃的だった。
わずか10分でインストール＋ログイン画面が作れるムービーが流れていて、Javaでガリガリ書いていた環境から見れば革新的だった。
同じ頃にSeasarも出てきて、JavaのWebアプリ開発の敷居も相当下がった。

そして、クラウドが出てきた。
ASPの看板を入れ替えただけと思っていたが、AmazonEC2やGoogleAppEngineに触れて、その思想は理解できてないけれど、革命的である事は直感した。

クラウドでも特にSaaSを実現できれば、もはやWebシステムは自作して運用せずにレンタルすればいい。

サーバーと言うハードウェアの納品とその運用で収益を上げて、Webシステムはその付属品という従来のWebシステムの受託開発ビジネスは、昨今の不況もあいまって、クラウドの出現によって収益率が急激に落ちている。

クラウドは非RDBを必要とする: プログラマの思索
クラウド時代のビジネスモデル: プログラマの思索

Webシステム開発ビジネスは今後どこに行くべきか？
フレームワーク、クラウド等で発展したWeb技術は、どこにイノベーションがあるのか？

クラウドは非RDBを必要とする

最近流行するクラウドは、非RDBであるkey-valueストアを必要としている。
その理由を完全に理解できてないけれど、ネット上にある記事をメモしておく。

【元ネタ】
Web 時代の非リレーショナルデータベース: 第 3 回 Apache CouchDB で MapReduce フレームワークに基づく問いあわせを行う

「NoSQL」は「Not Only SQL」である、と定着するか？ － Publickey

クラウドが流行する背景には、Webサーバーのスケールアップは容易だが、RDBのスケールアップが難しいことがあるからだろう。
そして、ApacheのCouchDB(Erlangで作られている)、GoogleのBigTable等のkey-value storeをスケールアップしやすい理由は、MapReduceによる並行処理で高速化できるからだからだろう。

しかし、クラウドが分かりにくいのは、データストアをRDBではなく昔の汎用機の頃に戻しているからではないだろうか？
RDBに慣れているとkey-value storeを持つシステムは実装しにくく、正直分かりづらい。

色々探ってみたい。

NoSQL～RDBからkey-value storeへ

NoSQLという単語が最近流行しているらしい。

【元ネタ】
masuidrive on rails - NoSQL – SQLはもう古い?

NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog

NoSQL - Wikipedia, the free encyclopedia

言わんとすることは、RDBからkey-value storeへの流れ。

普通のWebシステムならば、RDBで十分使える。
しかし、ユーザ数やトラフィックがとてつもなく膨大な場合、データベースのパフォーマンスに問題が出てくる。
Webサーバーのスケールアップは、サーバーの増設で対処できるが、RDBのスケールアップが難しいのだ。

ApacheのCouchDB(Erlangで作られている)、GoogleのBigTable等のkey-value storeはいずれも、データストアをいかにスケールアップしやすくするか、と言う観点で作られていると考えれば、その方向性も理解しやすくなるだろう。

ソフトウェア開発チームはオーケストラに似ている

ソフトウェア開発の特徴で良い記事があったのでメモ。

【元ネタ1】
ソフトウェア開発組織はオーケストラ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発で伸びる人，伸びない人【第二版】：柴田 芳樹 (Yoshiki Shibata)：So-net blog

荒井さんの本「ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)」が紹介されていたので立ち読みしてみた。
「特別付録　音楽とソフトウェア開発」という章が面白かった。

ソフトウェア開発組織はスポーツではなくオーケストラ。
個人のスキルは前提条件であり、協調するのが大事。
一人のスキルが低いと、演奏する音楽全体の品質が落ちる。

オーケストラでは、指揮者(プロジェクトマネージャ)以外に、副指揮者(プロジェクトリーダー)、コンサートマスター(アーキテクト)の役割が必須。
管理者の仕事が3人に分かれているのに注意。
SW開発の大規模プロジェクト(数十人以上)も同様に、管理者の役割が分化されるはず。
アジャイル開発のような小規模チームでは、管理者が役割を兼務する時が多い。

バッハやモーツァルトもその時代の音楽楽器の技術をフルに使うことで、優れた楽曲を残した。
IT技術も、その時代に合った技術をフルに使えば、ベターなシステムが作れるはず。
しかし、IT技術は陳腐化が激しいので、システムの寿命も本来は短いのかもしれない。

【元ネタ2】
「ソフトウェアは工業製品ではない」　まつもとゆきひろ氏：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェアエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-net blog

日本のITベンダーのプロセス改善に何故、違和感を感じるのか？
彼らのプロセス改善の根底には、アートを作るのではなく、工業製品を作っているイメージがある。
ソフトウェア開発のプロセスが細分化されて、プログラミングではなくコーダになっている。

【元ネタ3】
ソフトウェアエンジニアの成長カーブ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
開発チーム（組織）の成長：柴田 芳樹 (Yoshiki Shibata)：So-net blog

ソフトウェア開発において、成長できない組織や個人は、プロセス改善できない。
ソフトウェア開発においてプロセス改善するには、プログラミング技術が時代に乗り遅れないように、常に磨かなくてはいけない。

パッチベースのワークフロー

オープンソースではパッチベースのワークフローがあるという記事をメモ。

【元ネタ】
gitster's journal - 入門Gitの目次はというと

入門Git - idesaku blog

2009-10-11 - 未来のいつか/hyoshiokの日記

gitster's journal - 入門Gitの目次はというとで、下記の文章が目を引いた。

第十章ではじめて、オープンソースの世界で多用されるパッチ・べースのワークフローを登場させた。
会社で仕事に使うだけ、というユーザには馴染みのないワークフローと考え方だと思うので、パッチ・べースのワークフローを使わない向きは飛ばして貰っても、本の他の部分を読むのには全く問題がない。
そのかわり、ボクがこれまでLinus君と一緒に仕事をしてきて学んだ、オープンソースコミュニティで生きてゆく際のコツ、といったものを「オープンな開発プロセス」という一節としてこの章に加えることにした。
ボクの経験が、少しでもオープンソースに関わる人たちに役に立ってくれると良いな、という考えからだ。

入門Gitは今予約中で読んでいないので、以下想像した事をメモする。
＃間違っていたら後で直す。

上記の言うパッチベースのワークフローは下記の意味だろう。
オープンソースコミュニティできちんと管理されているシステムのソースコードは、必ずコミッタが厳重に管理している。
ユーザが機能追加やバグ修正したソースを反映させたい時、パッチを作ってコミッタに送る。
コミッタはそのパッチをレビューして、フィードバックし、OKならコミットする。

このワークフローは実は、ReviewBoardやRietveldなどのコードレビューシステムと同じだ。
つまり、パッチベースのワークフローの目的は、コードレビューによる品質チェック、開発者同士の暗黙知の共有を指すと思われる。

普通のSIでは、上記のようなワークフローを持ったコードレビューは持っていないのではないか？
実は、オープンソースの方がはるかに高品質な開発プロセスを持っているのではないか？

また、パッチベースのワークフローをGitやMercuiralのような分散バージョン管理が補完している特徴も見逃せない。
マスタリポジトリはコミッタしか変更できないが、開発者は自分の好きな場所でリポジトリをコピーできてハックできる。しかも、マスタリポジトリから即座に最新ソースをマージして、常に最新バージョンにできる。
この分散バージョン管理におけるトピックブランチの仕組みが、パッチベースのワークフローを簡単にさせているのだろう。

GitもTortoiseGitがかなり機能改善されたので、TortoiseHgと比較しながら使ってみたい。

Webシステムのリリース作業とフォールトトレランス

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」を読んで、Webシステムのリリース作業の大変さ、非機能要件における性能・稼働率についてあれこれ考えた。
フォールトトレランスとリリース作業に関するメモ書き。

【元ネタ】
フォールトトレランス

フォールトアボイダンス

フォールトトレランスの定義と具体例が理解しやすい。

フォールトトレランス(耐障害性)とは、「失敗や障害が起きることを見越して、どんな事態に陥っても全体としての機能を失わないようにすること」です。
フォールトトレランスを実現する方法は下記の通り。

フェールソフト(周辺故障)とは、「システムが誤動作をしたり部品が故障したりしても、機能を完全に停止するのではなく、可能な範囲で稼動させること」
フェールソフトは継続性を重視しており、フェールオーバーを含むこともあります。

フェールセーフ(安全側故障)とは、「システムが誤動作をしたり部品が故障したりしても、安全側に制御すること」です。
フェールセーフは安全性を重視しています。

フェールオーバー(冗長性故障)とは、「設備を必要最小限よりも多く用意して、システムを冗長（リダンダント）化させて障害に備えることにより、フェールソフトを実現すること」。
フェールオーバーは継続性を重視しています。

フールプルーフ(誤操作対応)とは、「利用者が操作や手順を間違えても、危険を招かないように設計すること」です。
フールプルーフは安全性を重視しています。

フォールトアボイダンスとは、「失敗や障害の要素を完璧な精度にしたり十分に訓練したりして、失敗や障害を発生させないようにすること」です。
フォールトアボイダンスは古典的な手法ですが、「人間は間違いを犯す」という思想が広がり、フォールトアボイダンスだけでは不充分なため、現在はフォールトトレランスに重点を置くことが主流になっています。

リリース作業中、あるいは運用中でもシステムが障害を起こしてしまう時はある。
フォールトトレランス(耐障害性)を実現する4種類の方法は、障害が起きてもそのダメージを少なくする為のノウハウだ。

そして、特に組込み機器ではそれらの機能も実装する必要があるため、余分な開発工数をあらかじめ考えておく必要がある。

昨今のWebシステムでも、そのリリース作業は、10年前よりもはるかに高度になっている。
リリース中もシステムをダウンさせない手法が一般的になっている。

昨今の普通のWebシステムは、WebサーバーもDBサーバーも複数のサーバーへ物理的にも論理的にも冗長化されている。
その場合、ロードバランサによって、負荷に応じて各サーバーへ振り返られている。

昔のWebシステムのリリース作業は、手間が多かった。
まず、システムを停止し、アプリケーションを1個ずつデプロイし、Webサーバーを再起動する。
Javaならば、warやjarではなく、classファイルを1個ずつFTPでアップしていた。
更に、JSPは初回表示が遅いので、Webサーバー起動後、各画面を表示してJSPをリコンパイルさせていた。
だから、そのリリース作業中の数時間はWebサイトが使えません、とあらかじめユーザへ連絡する必要があった。
ユーザ企業としては、システムのダウン中はシステムから売上が出ないから、リリース作業と言えどもダウン時間が長いほどダメージは大きい。

それに対し、最近のWebシステムのリリース作業は下記が普通だ。
リリースする順番ごとに各サーバーをWebから切り離し、バックグラウンドでアプリケーションをデプロイして再起動していく。
リリースできたら、ネットワークにつなげて、次のサーバーへリリースしていく。
この手法ならば、ユーザ側からは、システムがずっと稼働中でダウンしているようには見えない。

情報処理試験にある信頼性の問題(午後1・問4)にもあるように、Webシステムの障害を検知する仕組みも以前に比べると洗練かつ複雑になっている。
Webサーバーの障害を検出する機能として、ヘルスチェックがある。
ヘルスチェック機能は、ping監視という最も基本的な方法から、ポート監視、プログラムやシェルによるアプリケーション監視がある。
例えば、ping監視やポート監視はWebアプリとは異なる外部サービスで行ったり、アプリケーション監視はログ出力やヘルスチェック用のJSPで実装したりする。

また、情報処理試験の問題にあるサーバー構成図のように、負荷分散と冗長化を兼ねたデュプレックスシステムのアーキテクチャで、WebサーバーとDBサーバーを冗長構成するのが普通になっている。
このやり方ならば、稼働率も安定する。

ネットの情報によれば、Googleは「サーバーやHDDは定期的に壊れる前提でサーバーを構成している」らしいから、おそらく冗長化の技術が普通のSIよりも優れているだろうと推測される。

システムはプログラミングだけでなく、稼働率の高いサーバーの構築というタフな作業もあるのだ。

MSMoneyのLinux版GnuCash

GnuCashは資産管理もできる家計簿アプリケーション。
MS MoneyのLinux版みたいなアプリ。

MS Moneyのファイルも読み込めるので、クレジットカードや銀行のWebページからMS MoneyファイルをダウンロードしてGnuCashに取り込めば、家計簿を簡単に付けれる。
複式簿記に対応できているので、ちょっとした財務管理に使えるかもしれない。

実際にインストールしてみたものの、操作やGUIは癖があるので、慣れないと使いづらい。
でも、オープンソースで公開されていて、随時バージョンアップされている。
日本語化されているので、試してみたい。

【元ネタ】
Free Accounting Software | GnuCash

GnuCash - Wikipedia

GnuCashを再び使ってみる | 我が心のあれこれ

Windows版のGnuCashを入れてみた - より良い環境を求めて

GnuCash チュートリアル・コンセプト ガイド

GnuCash - Linux on the Desktop