TIM Labs

2011年1月アーカイブ

「遷移図生成ツール blockdiag の紹介」というタイトルで Pycon mini JP で話をしてきました。
そのときの資料をアップします。

ちなみにスライド中にあるクローラはデモ用にざっくり作っただけなので
特に公開する予定がないのですが欲しい人いますか?

問題

git では空気を吸うようにブランチを作り空気を吐くようにマージを行います。 gitでマージ作業を中止して元の状態に戻す ではマージに際してよくある問題の対処方法について紹介しました。

運用をきちんとしていればトピックブランチのマージでコンフリクトが発生することは稀です。 しかし稀とはいえコンフリクトが発生するときは発生します。 例えば新機能Xの実装を始めるとしましょう:

$ git checkout -b topic-x master
$ $EDITOR
$ git commit -am 'Fix outdated comments'
$ $EDITOR
$ git commit -am 'Revise existing API'
$ $EDITOR
$ git commit -am 'Implement X'

          o---o---o  <- topic-x
         /
o---o---o  <- master

新機能Xを実装している間に他の人がバグ修正Yを行い、 それが master に取り込まれていたとしましょう:

$ git checkout -b topic-y master
$ $EDITOR
$ git commit -am 'Fix apple'
$ $EDITOR
$ git commit -am 'Fix banana'

$ git checkout master
$ git fetch
$ git merge origin/master
$ git merge topic-y
$ git push origin master

          o---*---o  <- topic-x
         /
o---o---o---*---o  <- master, topic-y

さて新機能Xを master にマージしたところ、 偶然にも topic-x と topic-y で変更範囲が重なっていたためコンフリクトが発生しました (グラフの * で示したコミットです)。 コンフリクトの解決は問題なく終わり、マージ作業を終えたとします:

$ git checkout master
$ git fetch
$ git merge origin/master
$ git merge topic-x  # (c1)
$ $EDITOR
$ git commit -a  # (r1)

          o---*---o  <- topic-x
         /         \
o---o---o---*---o---o  <- master
                ^
             topic-y

しかしマージ作業を終えたところで実は topic-x に致命的なミスがあったことに気付きました。 まだ git push する前だったので、 一度マージ作業を巻き戻してから topic-x を修正して再度マージすることにします:

$ git checkout topic-x
$ $EDITOR
$ git commit -am 'Fix $&*!)($&'

$ git checkout master
$ git fetch
$ git merge origin/master
$ git merge topic-x  # (c2)

          o---*---o---o  <- topic-x
         /             \
o---o---o---*---o-------o  <- master
                ^
             topic-y

これで手順としては何も間違っていないのですが、 当然ながら(c2)でも(c1)と同様のコンフリクトが発生します。 一度(r1)で解決したにもかかわらず、 同様の作業を繰り返すことになります。 いくらなんでもこれは面倒です。 どうにかして自動化できないでしょうか。

問題

git では空気を吸うようにブランチを作り空気を吐くようにマージを行います。

例えば新機能Xを実装する場合、

  1. X用のトピックブランチを作成し、
  2. 実装を進めて、
  3. 完成したら統合ブランチへマージする

というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります:

$ git checkout -b topic-x master
Switched to a new branch 'topic-x'

$ $EDITOR

$ git add foo.x bar.x baz.x

$ git commit -m 'Implement X'
[topic-x 0000001] Implement X
 3 files changed, 8 insertions(+), 5 deletions(-)

$ $EDITOR

$ git add qux.x

$ git commit -m 'Fix a typo'
[topic-x 0000002] Fix a typo
 1 files changed, 7 insertions(+), 5 deletions(-)

$ git checkout master
Switched to branch 'master'

$ git merge topic-x
Updating 0000000..0000002
Fast-forward
 foo.x |    5 ++++-
 bar.x |    4 ++--
 baz.x |    4 ++--
 qux.x |   12 +++++++-----
 3 files changed, 15 insertions(+), 10 deletions(-)

さてマージが完了したは良いものの、 よくよくログを見返してみると topic-x の内容に誤りがあり、 実はまだ完成とは言えない状態だということに気付いたとしましょう。 topic-x で修正を積み重ねてから再度masterへマージしてもよいのですが、 この作業はまだ外部へ公開(push)していないので、 できれば外面を綺麗に保つために一旦マージをなかったことにしてから 修正を行いたいものです。 しかしどうすればよいでしょうか。

マイクロソフトにしては静かにオープンし、人知れず勢力を伸ばし、知らぬ間にアップデートを続けているAzure。
オープンし1年を迎えるが、遅まきながらAzureに触れてみて「Azureってやばいかも?」と思っている

まあこんなブログ読んでいる人ならAzureが何かくらい知っているだろうし、適当にググればいくらでも紹介記事があるので詳細まで説明しないが、とにかくやばいのである

何が?やばいのか

1、OSやミドルウェアのライセンスがかからない

従来MSテクノロジーvsOSSではライセンス費用がかさむ分MSテクノロジーが不利だった。その不利を打ち消すように「便利ですよー」「高機能ですよー」とやっていたわけだ

しかしAzureではインフラ代金は請求されるがライセンスなどまったくかからない。月間1億PVを稼ぐサイトや超大手の基幹システムならいざ知らず、数千万規模のシステムではこれはとてつもない破壊力を持っている

考えてみてほしい。開発費3000万のシステムで、そのインフラ初期費用はいくらいかかっているだろうか?ケースバイケースだと思うが、MSテクノロジーを使えば1000万くらいは普通にかかるだろう。これをOSSにして500万などというのが従来の世界観だった。

「ちょっと待って、クラウドの特徴はスケーラビリティとか超大規模システムじゃないの?」とか思ったかもしれない。私も最初はそう考えていた。しかしAzureの仕様を理解するにつれ、このクラウドはごく普通の、むしろ小じんまりな案件でこそ破壊力があると思うようになった。


2、PaaS(Platform as a Service)の力


Azureで手に入るのはASP.NETのアプリケーションプールであり、SQLServerのインスタンスだ。どうやってロードバランスするかとか、障害時のリカバリをどうするかとか、セキュリティパッチをいつ当てるかとか、ディスクフルの監視をしなくちゃとか、そういった運用的な雑務から一切合切解放されている。
Azure以外でこれを実現できるのはGoogleAppEngineくらいのものだと思う。J2EEやPHPでは同じようなものがない。
そしてJ2EEで今後PaaSが出てくるとは思えない。なぜならJ2EEのプラットフォームの統一は絶望的だろうからだ。LAMPならできるかも知れない。というかすでにあってもおかしくない(私が知らないだけだ)

何が言いたいかというと、PaaS競争は値段もあるけど、結局プラットフォーム競争になるわけであって、現時点では実績、機能、統一性の総合点でASP.NETが最強で、それを他社がPaaSとして提供してもWindowsやSQLServerのライセンスから逃れられない以上、Azureが最強なんじゃないかと


よく言われているけどマイクロソフトは過去に大きな方向転換を何度かしている。
IBMと袂を別ちWindowsを出し、ハードのおまけだったOSが主役になり、ハードこそOSのおまけになったとき。
IEを出し、IISを出し、スタンドアローン中心からインターネットを中心にすえたとき。
そしてあと10年たってみれば、Azureがサーバ市場支配の始まりとして3度目の大きな転換に数えられるときが来るのかもと、思ったりしています




コンピュータを上手に使うには、アルゴリズムに熟知している必要があるという。その中でも、ソート、サーチは最も基本的なものであり、呆れるほど高速な手法がある。そのような手法が見つかっている分野では、それを勉強し、抱えている問題に適用するだけでできる。

実際には、アルゴリズムが確立していない分野がたくさんある。とくに、スケジューリング問題は未開地だ。アルバイトスケジュール、ナース・スケジュール、資源割り当て、学校の時間割、列車の運行管理、配船計画、などなど、いくらでもある。

これらは、見かけよりやたらに条件が難しい。AさんとBさんは仲が悪いから一緒には働けないとか、さらには休暇や研修で穴が開くとか、船の場合だと海賊のことも考えるとか。さらには、運用中にトラブル(病気、退職、事件)が発生し、急にスケジュール変更しなければいけないこともある。

とにかく条件は無茶苦茶なのだ。学校だと、非常勤講師は色々な仕事を掛け持ちしているので、働ける時間帯が限られる。効率よく講義できるように、曜日や時間をまとめないといけない。コストも考えないといけない。

スケジュール問題は、事前にどのような条件があるかさえ定かでない世界である。この世界に向くアルゴリズムは難しい。皆が好き勝手な条件をつけてくる世界である。

上記の問題のほとんどは、今でも人間が神業で作り上げていることが多いのだが、何とか自動化できないかとずっと考えている。神業でもどうにもならないときには、増員したり、休講や運休したり、担当者を丸め込んだりして、何とか誤魔化しているのが実情だし、現実解なのだ。

それでたどり着いた戦略が、「もうアルゴリズムを考えるのをやめよう」ということだ。

アルゴリズムを放棄したのだから、ついでにプログラムも放棄してしまおう。プログラムをガリガリ書いて、条件に合う組み合わせを見つけるのは大変過ぎる。

肝心なことは、ぐちゃぐちゃの要求に対して、条件を満たす解を示すことだ。それさえできれば、OKなのだから。

では、どんな方法があるだろうか。次までに「秘策」を考えておこう。

問題

gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) では一度コミットしてしまった変更を別のブランチへ付け変える方法について紹介しました。

この例では誤ったブランチに対して一度コミットしてしまいましたが、 コミットする前に誤ったブランチで作業していたことに気付くこともよくあります。 例えば以下のような状態です:

$ git branch
  master
* topic-y

$ git branch topic-x master

$ $EDITOR  # git checkout topic-x を忘れて作業してしまった。

$ git status
# On branch topic-y
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   application.source
#       modified:   library.source
#
no changes added to commit (use "git add" and/or "git commit -a")

一度コミットしていたのであれば git cherry-pick で対処できますが、 この場合はまだコミットしていません。 どうすればよいでしょうか。

今回は、実装よりのことについて。

以下のものを使おうと思っています。

・Ruby
・SQLite
・Sequel

多分まだ増えると思いますが、今のところはこんな感じで考えています。
以下、概略です。

このアーカイブについて

このページには、2011年1月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2010年12月です。

次のアーカイブは2011年2月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。