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

はてなブックマーク - 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システム開発のキーワードになるかもしれない。

クラウドは非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はいずれも、データストアをいかにスケールアップしやすくするか、と言う観点で作られていると考えれば、その方向性も理解しやすくなるだろう。

Rietveld のインストール方法

ReviewBoardとは別のコードレビューWebシステムRietveld をインストールしてみたら、すごくあっさりインストールできた。

Rietveld はGoogleのコードレビューシステムMondorianを作った人が開発しているらしい。
Rietveld のインストール方法についてメモ。

【元ネタ】
Google謹製 ソースコードレビューシステム rietveld(オープンソース版 Mondrian)を動かしてみましょう - ふにゃるん

オープン ソース アプリケーション: Rietveld コード レビュー ツール - Google App Engine - Google Code

ARMで動くかどうか試してみる - kinneko@転職先募集中の日記

Django での App Engine アプリケーションの実行 - Google App Engine - Google Code

【Rietveld のインストール方法】
まず、GAE for Pythonを取得する。

wget http://googleappengine.googlecode.com/files/google_appengine_1.2.7.zip
↓
rietveldの最新ソースを取得する。
rietveldのディレクトリは、GAEのルートフォルダに置く。

cd /usr/local/google_appengine
svn co http://rietveld.googlecode.com/svn/trunk/
↓
ノーハングアップでバックグラウンド起動する。

nohup python dev_appserver.py --address=サーバーのIPアドレス --port=8100 ./rietveld &
↓
http://サーバーのIPアドレス:8100 でアクセスできる。

使ってみた感じでは、GoogleCodeのようなUIで、ReviewBoardと似たような方法でコードレビューができる。
つまり、diffファイルをアップロードし、SVNリポジトリのパスを通せば、コードレビューができる。

コードレビューシステムとして、ReviewBoardとRietveld を比較すると、ステータス管理とBTS連携に違いがあるように思う。

ReviewBoardのステータスは「新規」「終了(submitted)」しかないが、Rietveldでは「新規」「担当中」「終了」の3種類がある。
Rietveldの一覧画面で、3種類のステータスごとに分類されて一覧表示されるので便利。
但し、ReviewBoardの一覧画面でも、「自分がレビューアのリクエスト」と「全てのリクエスト(新規・終了)」で表示されるから、どちらもできることは似ている。

また、ReviewBoardのリクエスト画面には「レビューの状態」項目がテキスト入力可能になっていて、この項目を更新していけばいい。
つまり、コードレビューのワークフローを管理することは可能だ。

他方、RietveldにはなくてReviewBoardにある機能として、BTSチケットと連携する機能がある。
TestLinkと同様に、コードレビューが発生した場合、進捗管理はBTSチケットで行い、ReviewBoardでコードレビューの詳細な作業を行うように区別したらやりやすいかもしれない。

色々試してみたいと思う。

形式手法とHaskellについてメモ

いけがみさんの記事を読みながら、思ったことをメモ。
＃まとまっていないので、あくまでも妄想です。

【元ネタ】
Inemuri nezumi diary(2009-02-05)

2009-06-23 - a-sanの日記
不正な状態遷移を見つけるアルゴリズム - a-sanの日記

僕が形式手法に興味を持った理由は、設計工程でモデリング作業の品質を上げることができて、更にテストケースを生成してくれるのではないか、という期待があったから。
でも、形式手法は確かに凄いのかもしれないが、言語もツールもオープンでないので使いづらい。
いけがみさんの言う通り、完璧な仕様を求めようとして、結局無駄な力を注いでいるのかもしれない。

モデリングは結局、事前条件と事後条件をつなげて一貫性と整合性が取れているか、そして状態遷移図が矛盾なく整合性が取れているか、という作業に落ち着くと思う。
関数型言語Haskellでも、形式手法でやりたかったことが同様にできるのではないか？

少なくとも、「不正な状態遷移を見つけるアルゴリズム - a-sanの日記」にあるHaskellのプログラムは、状態遷移図の整合性チェックができることを示しているように思う。

Haskellも僕にとって難しかった。
モナドや遅延評価だけでなく、関数型言語そのものの発想がないから。

でも、プログラムだからいくらでも試せる。
Howを考えるのではなく、Whatを考えるようにHaskellプログラムを書けばいい。
Haskellを書きながら、問題設定を考えながら、仕様を考えているのだ。
できれば、Haskellプログラムからテストケースを生成したい。

現在、考えている荒筋は下記の通りだ。

MSのPairwise法ツールPICTをエンジンに持つテストケース自動生成ツールMTGに状態遷移表を書けば、パラメータの組み合わせを生成してくれる。
その結果をTestLinkCnvMacroに貼り付けて、ちょっとだけフォーマットを整えれば、テストケースを出力できる。
そのテストケースをTestLinkへインポートすれば、TestLink上でテスト作業を一括管理できる。

つまり、質の良いテストケースを出力できれば、後はTestLinkでテスト作業をコントロールすればいい。
そのために、MTG→TestLinkCnvMacroのツールを使う。

MTG プロジェクト トップページ - SourceForge.JP

TestLinkCnvMacro - SourceForge.JP

後は、MTGへ吐き出すためのパラメータや制約条件がHaskellや形式手法、あるいはUMLの状態遷移図から作れればいい。
実際は、その部分が自動化できておらず、手作業になっている。

チケット駆動開発や構成管理に比べると、テスト工程の自動化はとても難しいが、どこまで可能か考えてみたい。

プログラミング言語の進化はベストプラクティスをサポートするためにある

yuguiさんのBlogで興味深い一言があったのでメモ。

プログラミング言語の進化の方向 - 世界線航跡蔵

言語の進化はベストプラクティスの取り込みにある、と。
言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。

プログラミング言語もツールも、ベストプラクティスの取込の歴史そのもの。
良いプログラミング言語に慣れれば、自然にオブジェクト指向も並列処理も身に付く。
同様に、良いプロジェクト管理ツールに慣れれば、自然にSW開発のマネジメント手法も身に付くはずだ。

『～ It!』シリーズの本は良書

【元ネタ】
エンジニアがタイトル買い、著者買いすべき本 - {Fight the Future => じゅくのblog}

『～ It!』シリーズの本は確かに良書だ。
『～ It!』シリーズの本は3冊ある。

「 Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」は、プログラマが身に着けるべき習慣が書かれている。

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」にあるノウハウは、Webシステムの環境構築やリリース作業で非常に役立つだろう。

「Manage It! 現場開発者のための達人式プロジェクトマネジメント」は、開発者のためのプロジェクト管理、特にアジャイル開発の導入に関するノウハウが書かれている。

後日、読んだ感想を書いてみる。

IronRubyの行方

JRubyがJVM上のRuby環境のように、IronRubyは.NET上でのRuby環境だ。
それに関するメモ。

【元ネタ】
InfoQ: IronRuby -- 1.0までの道のり

荒井省三のBlog : IronRuby で Ruby on Rails を動かしてみました

IronRuby と RSpec の概要

[Ruby] IronRuby 動かしてみた (第一種臨界不測日記)

.NETでRuby開発を体験してみよう － ＠IT

(中略)
開発環境がそろってくれば、作業を効率化するためのスクリプト系のプログラムはRubyで素早く書き、業務アプリケーションのような堅固なプログラムはC#で慎重に書くというような使い分けが行えるのではないかと想像している。

IronRubyの利点は、Win32OLEとの相性の良さだろう。
.NET上でRubyプログラムが動くということは、ひいてはIIS上でRailsが動作するようになるだろう。

IronRubyもJRubyと同じく要注意だ。

TortoiseHgで日本語が使えるようになった

TortoiseHg0.8.1になって、ようやく日本語がほぼ使える状況になったのでメモ。

【元ネタ】
TortoiseHg / wiki / install ― bitbucket.org

Windowsにてwin32mbcsを有効にしてMercurial 1.3 を使うとエラーになります - mercurial-ja | Google グループ

gitやめてmercurialとtortoiseHGをインストール

TortoiseHg0.8.1に同梱されているMercurial 1.3.1で、win32mbcsが効くようになったらしい。
実際、パスやファイル名が日本語でも、コミットエラーが出なくなった。
メニューも日本語化されて使いやすくなった。
但し、日本語のダメ文字は使えないので注意。

また、Mercurialのオライリー本の日本語訳がPDFで公開されているのでメモ。
分散バージョン管理の特徴とその利点が書かれており、無料で読めるのはとても素晴らしい。

"Mercurial: The Definitive Guide" 日本語訳の公開CommentsAdd Star - 彷徨えるフジワラ

Linuxならば分散バージョン管理はGitで十分だろうが、WindowsではMercuiralの方が使いやすい。
その理由は、MercurialのWindowsクライアントTortoiseHgがあるからだ。

TortoiseHgはまだ開発途中なので品質や使い勝手に難点はあるが、Googleのサポートもあるから今後も発展していくだろう。

TortoiseSVNのように、WordやExcelの差分機能やBTSチケットとの連携機能が追加されれば、ソース管理だけでなく、設計書のバージョン管理もできるし、変更履歴をBTSから追跡することもできる。

今後の機能拡張を待ちたい。