準二級.jp

Heroku-ja Meetup #1 に参加して、トークしてきました。確かに言われてみると「Heroku のユーザ」がいっぱい集まってお話する機会は、なかったのですね。主催の @junya さんはじめ、場づくりに貢献されたすべての皆さん、ありがとうございました！

会場がきれいで、設備も充実していて、とても素敵なところでした。

「ヘェ、あんたもロクっていうんだ」

発音について。Heroku が Salesforce に買収されたときに、Salesforce のお偉いさんが「ヘロク」と何度も言っていたらしく、それを聞いた日本の記者さんが記事に「ヘロク」と片仮名で書いたからその日がヘロク記念日？とか、そういうお話だった感じです！ぼくは「ハオク」っぽい呼び方をしています。

ぼくは、常日頃から Heroku 先輩にはとてもお世話になっています。接している時間が長い分、ときに「これ、どうすれバインダー」と困ることもたまにあって、自分は自分なりに解決するのですが、他の皆さんはどうやって Heroku と接しているんだろうなって、気になっていました。

そこで、今回はトークの枠をひとついただき、自分や自分たちにとっての「Heroku とのふつうの日々」を話し、他の皆さんのお話を引き出せるよう、がんばってみることにしました。もうちょっと言うと、Tシャツが欲しかったのです！

自分のように「つくりたいものはあるんです！」だけど「開発とか運用とか、なんでもかんでもできるわけじゃないし…」という、ふつうの人にとっては、開発を加速してくれる Rails や Sinatra などのフレームワークや、Heroku といった PaaS の存在は、とてもありがたいものです。頭の中にあるアイディアを現実に動くアプリケーションとして実現するまでの道を、見せてくれるわけです。ゆとり爆誕である…！

なので、自分と同じように「何かつくって動かしたい」と、自意識をこじらせている人がいたら、そういった人にはぜひとも Heroku は知っておいてほしいと思って、そんな気持ちでトークに臨みました。

開発者と、開発者ではない人も含めた3〜5人くらいの規模のスモールチームで Heroku を活用する事例を中心に、個人として Heroku を愛用する日々、Heroku で Rails アプリを動かす際のちょっとしたプラクティスなどを、お話させてもらいました。

From : http://www.flickr.com/photos/sooey/5913000622/

まとめ

おかげさまで、Heroku ユーザがたくさんいる地下闘技場で、たっぷりと Heroku のお話をすることができて、とても楽しかったです。開発寄りのお話もそうですが、エンタープライズ寄りのお話で「Heroku は稟議が…」といったお話も、新鮮で面白かったです。なるほどなぁ、なるほど。それと、Heroku の API や Add-ons については、自分ももっと意識を向けてみようと思いました。他のヘヴィユーザの皆さんのお話を聴いていて、今より一歩踏み込んだ使い方ができるかもな、というありがたい発見がありました。

最後にもう一度、お礼を。あの場にいたすべての皆さん、どうもありがとうございました！ノベルティ、ゲットだぜー！

18章の執筆者である濱崎健吾さまよりご献本をいただきまして、読むことができました！

O’Reilly Japan – ウェブオペレーション

「まえがき」から

かっこよすぎて、もう。

日々、我々は少しずつ賢くなり、少しずつ知恵をつけ、少しずつコツをつかんでいった。10年前に書いたスクリプトはツールや言語に発展した。我々の周りには産業ができた。知識・経験・ツール・プロセスは技芸になった。我々はそれを「ウェブオペレーション」と呼んだ。

ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は (少なくとも今はまだ) ない。我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。「正しい方法」はどこにも存在しない。そこにあるのは、(とりあえず今は) うまくいくという事実と、次はもっと良くするという覚悟だけだ。

「ウェブオペレーション」という言葉には馴染みがない、という人が多いことでしょう。自分も、この本を読み始めるまでは自分の中に持っていなかった言葉です。それでも、本書に少しでも興味を持った人は「まえがき」を読んでみることをおすすめします。本書を「かっこいい」と感じるかどうかは、それだけで分かると思います。

数々の戦場を生き抜いた戦士たちの戦いの記録

本書は、現場で活躍する人たちの「武勇伝」集でありました。「まえがき」にあった「次はもっと良くするという覚悟」の意味を、読み進める中で深く知っていくことになります。

逆に、本書は、これとこれとこれを覚えておけば大丈夫、という知識や事実の羅列ではありません。日本語版には1章から18章までがあって、それぞれ著者は別々の人たちなのですが、どの章も「あるときは、こうやったら、こういうことが起こった」「このときの経験から、こういうことを学んだ」「次は、こういうことにならないように、こうしてみようと自分は考えている」といった体験談、あわせて、体験から得た知見が綴られています。そしてだいたい「だからお前もこうしろ」ではなく「君には君の現場があるのだから、君が考えて振る舞うんだ」といった論調で全体がまとめられているのです。

それぞれの章には一人称の「ストーリー」を感じました。おかげで、自分にとってはとても読みやすかったのです。

ふと考えてみるとこれは、濱崎健吾さまが、一緒にごはんを食べているときにお話してくれる「最近はこんなことで悩んでいる」「こういうことを試してみたい」「もっとこうしていかなきゃいけないと思う」のストーリーにそっくりなんですね。ウェブオペレーションは、自分の立ち位置からすると、必ずしも専門のド真ん中というわけではないのですが、たとえて言えば、彼に読み聞かせてもらっているかのように内容を吸収することができて、とても楽しかったです。

また、同時に、彼がお話してくれる戦士の物語が、たまたま近くにいた自分がたまたま聞かせてもらえる特別なものではなく、より広く多くの人たちにも届く物語になったことを、心から嬉しく感じています。執筆、お疲れさまでした。

さらに加えて、やはり地獄の角征典さんの訳のおかげで読みやすかったのでした。本文中に「やべ！俺たちカッコいいわ。カッコいいわー」や「リア充」と言った文字列を見つけたときは、思わず声を出して笑ってしまうわけですが、伝わってくる雰囲気は、文章の流れからするとまったく違和感なく受け取れるものでした。さすがだなぁと思いました。

グッときた

本文中の気になった箇所をマークしておきます。

正しいコードの書き方を教えるのではなく、プロダクション環境での失敗から学ぶ環境を作るのだ。

4.5.1「なぜ継続的デプロイが有効なのか?」 4章 継続的デプロイ

「根本原因」をもとに評価をするのは、失敗の本質に関する技術的な理解からではなく、結果に対して社会的あるいは文化的な何らかの非難が必要だったものと考えられる。

7.1「いかにして複雑なシステムは失敗するか」 7章 いかにして複雑なシステムは失敗するか

一方、開発チームと責任を共有すれば、サイトの安定性やパフォーマンスが良くなることに気付いているグループも多い。開発者を全面的に信頼して、コードのダブルチェックをしなくなれば、開発者は自ずから責任感を持つようになる。

10.3「信頼」 10章 開発と運用の協力と連携

お互いに助け合う環境を作るには、障害にあとに非難を禁止した「ふりかえり」を開くとよいだろう。このとき「どんな間違いを犯したのか？」のような質問をしてしまうと、自己弁護に陥ってしまう。「次はどうすればうまくできるのか？」のように質問すれば、みんなが非難をせずに改善案を提案するようになる。

10.5「非難を避ける」 10章 開発と運用の協力と連携

ウェブオペレーションについて議論する前に、組織の技術標準が恥ずかしいほど低いということを正直に認めなければならない。ウェブ業界でしばらく働いていれば、それが嘘ではないことだと分かるだろう。わかっていないなら、あなたは本当に幸運か、大事に保護されているか、単なるバカだ。問題は何だろう？あらゆる技術の問題は、人の問題である。そして、解決策も人である。あらゆるバグ・障害・機能停止・復旧は、人によって行われる。

16章 アジャイルインフラストラクチャ

「アジャイル」になるかどうかなんて気にするな。「すごい」人を目指せ。技術的な問題を解決するのは人だ。みんなで幸せになろうよ。

16.5「結論」 16章 アジャイルインフラストラクチャ

通常、ウェブサービスのインフラエンジニアがユーザの方と接する機会は皆無に近いものだと思われるが、このフォームのおかげでインフラにかかわるユーザの声を直接受け取れるというのは、インフラ構築の指標の材料としても、エンジニアのモチベーションの原動力としても大変役に立っている。

18章 日本の料理のインフラ

総じて、自分が身震いとともに読んだ文章というのは「人そのもの」や「人の成長」を対象にしたものであると、こうして全体をざっと眺めてみて気が付くこととなりました。10章の「開発と運用の協力と連携」なんかは、ここでいう「開発」と「運用」をそれぞれまったく別の言葉に置き換えたとしてもそのまま言えるようなことがふんだんに書かれていて、それは、結局はチームの構成単位は「人」に他ならないことのあらわれだと確信します。16章の「アジャイルインフラストラクチャ」では「技術的な問題を解決するのは人だ」と言い切っています。これも、とてもしっくりくるものでした。18章の「日本の料理のインフラ」では「エンジニアのモチベーション」という表現で、人への注目があります。

本書を読み終えた直後に、ちょうど、濱崎健吾さまと面と向かってお話する機会にも恵まれて、技術者が自分の価値を相手に認めさせることと、技術をコモディティ化して自分への依存を排除することと、その間にある葛藤について意見を交わしました。なかなかに頭の痛いお話ですが、自分たちエンジニアにとっては、決して目を背けることはできないトピックであるとも思います。

そうなったときに残るものはなんだろうか、と考えると、自分の「成長」を信じることなのかな、と今は思います。たとえ専門分野が変わったとしても、置かれた環境が変わったとしても、できることといえば、その場での自分の役割をまっとうし、最高を求めて終わりのない旅をすること、くらいですよね。だとすれば、本書「ウェブオペレーション」に綴られているウェブオペレータたちの武勇伝から自分が学び取るべきことは、まさに、そこにあるはずなんです。

さてさて。引用はしないけれど、自動化のための Vim スクリプトのお話と、その訳注も面白かったです。

謝辞

献本をくださった濱崎健吾さま、どうもありがとうございました。献本の相手として選ばれたことを、心から光栄に思います。執筆という偉業への尊敬と、ありのままの感謝を。

訳者の角さん、編集の高さん、この文章を (自分にとっては極めて親しみやすい) 日本語で読むことができて、助かりました。偉業に感謝します。それと、角さんの訳文を高さんがどのようにハンドリングしているのか、そのプロセスにはとても興味があります。次にお会いしたときに、質問させてもらうと思います。

上記3名さま、RubyKaigi2011 の会場でお会いできそうなので、楽しみにしています！この度は、ありがとうございました！

おしまい。

監訳者の河村圭介さんよりご献本を頂戴しまして、読むことができました。自分がずっと家にいなくて、せっかく届いた本が戻ってしまったりしてご迷惑をお掛けしましたが… ご献本、ありがとうございました！

はじめての監訳作業「大規模Webアプリケーション開発入門」 – developer’s delight

大規模Webアプリケーション開発入門 ―変化に強いWeb開発を実現する10の原則 Kyle Loudon 河村 圭介 オライリージャパン 2011-03-25 by G-Tools

書籍のタイトルと内容について

自分は「Web アプリケーション開発者」という立場でこの本を読みました。

そうすると、すでに「Web アプリケーション開発」には「入門」しているわけで、タイトルにある「大規模」の部分が、この本から自分が学び取るべきことかな、と想像しながらページを開きました。

ほいで、ざっと読んでみての感想からすると、内容は「Web アプリケーション開発入門」といったところです。「大規模」と聞いてまっさきに想像した「パフォーマンス」のお話は第9章で語られるのみに留まっており、第2章「オブジェクト指向」第3章「HTML」第4章「CSS」第5章「JavaScript」などは、これから Web アプリケーション開発に関わることになる人たちに読んでもらいたい内容です。

「ちゃんと意味を考えてマークアップしましょう」などは、開発の対象となるアプリケーションが大規模かどうかに依らず、常に覚えておくべき提言です。なので、タイトルが「大規模」からはじまることで敷居が高く感じられるのだとしたら、少しもったいない気がしました！

自分の立ち位置の確認

本を一通り読んでみて、あらためて、今の自分の立ち位置を確認することになりました。

自分が Web アプリケーションをつくるときに、まず前提として大きく存在しているのは「これはプログラミングである」という認識です。なので、プログラミング一般に対して言われる「DRY 原則」などは、無意識のうちにコードに反映されていきます。本書の中で「モジュール化しよう」が繰り返し強調されているのは、すんなりと受け入れられました。

また、自分が Web アプリケーション開発に携わってきた期間は、ほとんどが「Rails/Sinatra と関わってきた期間」と言えます。Rails の routes.rb や Sinatra アプリケーションのコードを書くときは、否が応にも「URL 設計」を強く意識することになり、アプリケーション全体を「リソース指向」に設計する傾向があります。

その点で、本書に「URL 設計」の章がなかったのは、自分にとっては「ほう」と思う箇所でした。

まとめ

こうして思い直してみると、自分は「Web アプリケーション開発に入門」と明確に感じたことはなかったけれど、アイディアを形にしたい一心で、気が付けばいくつか Web アプリケーションを動かすようになっていたので、たとえば後輩に「どこから勉強すればよいですか」と聞かれたら、上手く答えられなかったことでしょう。再現性の低い学習プロセスを踏んだと思います。

本書のように「入門」に焦点を当てて整理された本が1冊あると、とりあえず網羅的に知識を付けておきたい、とか、自分に足りないものを明確にしたい、とか、そういった人とはスムーズにお話ができるようになりそうです。

最後にもう一度。河村さん、ご献本ありがとうございました！

実は「第2回 開発コンテスト24」に参加していました。タイトルにもある「1/2」というものをつくりました。

エンジニア向け「第2回 開発コンテスト24」開催 | クックパッド株式会社

課題（普段の生活で）半径3m以内にいる人が困っていることを解決する

エンジニア向け「第2回 開発コンテスト24」開催 | クックパッド株式会社

とは言え、今回、発案から実装までをメインで行ったのは @kei_s さんで、自分はちょっこし手伝った程度なので、作品の紹介は @kei_s さんに任せて、自分は、自分目線でどのような時間を過ごしたのかを、記録しようと思います。

他のメンバーの視点から

• "1/2" というサービスを作ってた24時間くらいのはなしをします – 札幌市西区
• 「できればいいのに」が現実になる場所: 1/2 Real-time Tab Sync の開発に混ぜてもらいました – dara日記

金曜日の夜

2011年4月22日(金)、21時。開発コンテスト24がスタートしていました。そのとき自分は代々木にいて「一時帰国中の @mootoh さんと、美味しいお米を食べる会」的なものに参加していました。「うぅ、お米が美味しくて泣ける」とか言ってもぐもぐしているときに @hmsk ちゃんに話しかけられて(ただし、mention ではない。若者の mention 離れ)、開発コンテストがすでに始まっていると気が付きました。

@mootoh さんと、それから、一緒にいた @kana1 ちゃんと「おお、コンテストがはじまっていた！」「入賞すると何かもらえるのかしらね」「今なら iPad2 がもらえるんじゃないのー」「そうそう、iPad2 が欲しくてさー」「ぺちゃくちゃ」「ぺちゃくちゃ」なんてお話しているうちに、金曜日の夜は更けていったのです。お米が本当に美味しかったです。

土曜日を迎えて

はい！

気が付けば、コンテスト終了まで残り12時間ほどになっていました。金曜日の夜の眠る前と、寝ている間と、土曜日に起きてからも、ずっとネタを探していました。「半径3メートルかあ」ってところを出発点に考えつつ、日頃、脳内にストックしてあるアイディアから、今回のコンテストのテーマに合いそうなものはないだろうか、と考えてみたり。

• いま、半径3メートル以内にいる人って、このマンションの住民さんぐらいだな
• お隣のお部屋の(この記述は自粛されました)
• 上の階にいる(この記述は自粛されました)

うわあ… (提出できるような)作品のアイディアがぜんぜん浮かばない！これはもう、あきらめて、普段通りのプログラミングでもするか。と考え始めた頃に、@kei_s さんが何やら開発を進めていると知ります。

「わたくしめにも、貢献させてください…！」「動作確認でもなんでもしますから！」

ここ最近の、自分の身の回りにあった、上手くいったプロジェクトの進め方は、いつもこんな感じでした。誰かが先行して、触って体験できるまでのものを、創る。それに共感した他の人は「こういう貢献をしたいです」を提示し、発案者からコミット権を頂戴する。あとは、ひたすら貢献あるのみ、です。

「1/2」のバックエンドの仕組みと、Chrome Extension の大枠は、すでに @kei_s さんが完成させていたので、自分は Web サイトの用意や、マークアップや UI の細かい部分で貢献させてもらいました。

こういった、生きているプロジェクトに関わるのはとても良い機会なので、無駄にしないように、自分の作業にも、どんなに小さくてもいいからなるべく何かしら新しい挑戦を含めるようにしています。今回は、Google Web Fonts の API を試してみました。日常の中でストックする「これ試してみたいなー」をちゃんと活かしてあげる心がけ。

Node と express と jade は初めて触ったのですが、ほとんど Ruby と Sinatra と Haml だなーと思って作業していたら、案の定「基本的にはその認識でよくて、だけど、細かいところでハマる」という想像通りの展開になりました。楽しかったです。Node 版 Sass とか Scss にも興味があったけれど、そこまで手が届きませんでした。次の機会には試そう。

開発作業に区切りをつけて、応募の内容を真剣に考え始めたのが、20:30くらいのこと。自分たちとしては、相当しっくりくる文章を書くことができて「この文章が一般公開されることもなくお蔵入りするのかと思うと、虚しくて笑えるねえ」なんて思っていました。

20:55頃。無事に応募が完了し、「Your entry is accepted」のメールを受け取り、チームは「お疲れさまでした」と言って解散しました。お腹が空いていました。

結果は「特別賞」

わぁ！本当にビックリしましたー！お蔵入りすると思っていた文章は、公式サイトにばっちり掲載されていて吹きました。

ブラウザとブラウザ 瞳と瞳と 手と手
同じもの同じ感じかたしてるの 愛してる 愛してる 愛してる
あたしまだ懲りてない 大人じゃわかんない
届かないって 言われたって このままジャンプしたい

まとめ

複数人でタブを同期してブラウジングできる「1/2」をつくりました。「おお、なんだこれ！」という、なかなか楽しい体験が待っていますので、興味のある人は、ぜひぜひ試してみてください。Chrome Extension です。自分の日常では「会議室で、誰かがマシンをプロジェクタにつないでいて、みんなであーだこーだと言いながら色んな Web サイトを見てまわっている」状況ってのがあるので、そんなときに使いたいです。「チャットで URL を教えてー」なんて言わなきゃいけないすべての状況を「1/2」で改善できます。

1/2 – Real-time Tab Sync

企画から実装までを担当された @kei_s さんにおかれましては、素晴らしいお仕事でしたね。お疲れさまでした。@darashi さんと一緒に乗っかることができて、とても楽しかったです。全員が自宅にいながらのリモート共同開発も、すっかり慣れてきました。Git のリポジトリと音声チャットがあれば、けっこう戦える。まぁ、気心が知れた仲だから、実現できることかもしれません。よいチームでした。それでも、作業が終わったあとに乾杯できないのは寂しいので、次に全員が揃う機会には、受賞を祝って乾杯しましょうね！

表彰式は5月中に行います。応募作品のLTも予定しておりますので、皆様のご参加お待ちしております。

第2回「開発コンテスト24」受賞作品発表 | クックパッド株式会社

表彰式も楽しみです！あたしも参加していいのかな…！クックパッドさま、素晴らしい企画をありがとうございました！お疲れさまです！川本真琴をひたすらリピートして聴きながら、楽しく作業できたのでした。

4月13日にサインアップ申請をしておいた Cloud Foundry から「準備できたよー」のメールが届いたので、さっそく触ってみました。今なら、サインアップから10日くらいで使えるようになるってことでしょうかね。

The industry’s first open platform as a service. Run your Spring, Rails and Node.js applications. Deploy from your IDE or command line.

Welcome to Cloud Foundry

今回は Rails アプリ、Sinatra アプリ、Node アプリのデプロイを試してみました。ソースコード一式を GitHub においてあります。

june29/cloudfoundry-samples – GitHub

(写真は本文と関係ありません。手に入って嬉しかったので載せました)

準備

コマンドラインのクライアントを gem でインストールしました。

$ gem install vmc
$ vmc -v
vmc 0.3.10

Rails アプリ

普通に Rails アプリをつくって、プロジェクトのディレクトリで vmc push を実行します。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29rails
Application Deployed URL: 'sample29rails.cloudfoundry.com'?
Detected a Rails Application, is this correct? [Yn]: Y
Memory Reservation [Default:256M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29rails'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (15K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

scaffold だけでつくったアプリをデプロイしてあります。普通にデータベースに書き込めている感じ。

http://sample29rails.cloudfoundry.com/

Sinatra アプリ

app.rb を書いただけ。これだけで vmc push したら動きました。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29sinatra
Application Deployed URL: 'sample29sinatra.cloudfoundry.com'?
Detected a Sinatra Application, is this correct? [Yn]: Y
Memory Reservation [Default:128M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29sinatra'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (0K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

http://sample29sinatra.cloudfoundry.com/

Node アプリ

ファイル名は app.js にしておく必要があると書いてあったのでそうしてみたら動きました。express を使ってみたので、package.json を書かなきゃいけなくて、npm bundle も実行しておかなきゃいけない。

参考にしたのは Deploying a Node.JS app with NPM dependencies : Cloud Foundry Community です。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29node
Application Deployed URL: 'sample29node.cloudfoundry.com'?
Detected a Node.js Application, is this correct? [Yn]: Y
Memory Reservation [Default:64M] (64M, 128M, 256M, 512M or 1G) 64M
Creating Application: OK
Would you like to bind any services to 'sample29node'? [yN]: N
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (123K): OK
Push Status: OK
Staging Application: OK
Starting Application: OK

http://sample29node.cloudfoundry.com/

おまけ

Heroku の heroku コマンドと同じ感覚で適当にコマンドを打ったら通るので面白かったです。

デプロイしたアプリの一覧を見るときは vmc list でした。

$ vmc list

+-----------------+----+---------+----------------------------------+----------+
| Application     | #  | Health  | URLS                             | Services |
+-----------------+----+---------+----------------------------------+----------+
| sample29sinatra | 1  | RUNNING | sample29sinatra.cloudfoundry.com |          |
| sample29node    | 1  | RUNNING | sample29node.cloudfoundry.com    |          |
| sample29rails   | 1  | RUNNING | sample29rails.cloudfoundry.com   |          |
+-----------------+----+---------+----------------------------------+----------+

デプロイしたアプリを削除するときは vmc delete です。

$ vmc delete #{app_name}

あとあと、vmc push したけど「何のアプリケーションか分からなかったよ」ってときは、以下のようになります。

$ vmc push

Would you like to deploy from the current directory? [Yn]: Y
Application Name: sample29
Application Deployed URL: 'sample29.cloudfoundry.com'?
[WARNING] Can't determine the Application Type.
Select Application Type: (Rails, Spring, Grails, Roo, JavaWeb, Sinatra or Node)

内部では、どのようにアプリケーションを判別しているのでしょうね。ちょっと興味があります。

まとめ

「Heroku さんが息をしていないから…」というわけでもないのですが、Web アプリのホスティング先として Heroku 以外の選択肢があってもいいですよね。Google App Engine も視界にはありつつあんまり手が伸びていなくて、Cloud Foundry は「Rails も Sinatra も最初から動くよ」と謳っていたので勢いで触ってみました。Node アプリが動くという意味では Joyent に並ぶ選択肢にもなるので嬉しいですね。

Heroku の場合は「ああ、git で push すればいいのか」だったのが、Cloud Foundry の vmc コマンドは、独自に覚えることが多くなりそうです。パッと触ってみたところでは「よく分かっていないけれど動かせている」感じで、もうちょっと踏み込んだことをしようと思ったら、色々と調べる必要が出てきそうです。

今後もちょこちょこ触ってみようと思いました！おしまい。

もっとちゃんと説明してあるエントリを見つけたのでリンクしておきます！

VMware発のPaaS、CloudFoundryを試してみた – y-kawazの日記