VagrantでリモートのVirtualboxを実行するvagrant-remoteを作ってみました

Posted filed under Mac, Programming.

 もうちょっとで新しいMacBook 12″が出ますよね。軽いのにRetinaですごく良さそうなのですが、CPUが非力なのが気になります。  私はサーバサイドの開発がメインで開発環境の構築にはvagrantを使っています。vagrantはメモリもCPUも食うのでMacbookではちょっと厳しそう。特にテストの実行は数十分待たされそうな予感もあり、メインの開発には力不足です。  別にvagrantの実行はローカルホストで行う必要はないので、aws providerを使ってEC2上で動かしてみたりしたのですが、ネットワークやインスタンスコストの問題で常用は躊躇していました。  検索していくと、本家のIssuesでもvagrantをリモート実行する議論が行われていました。そこで紹介されているプラグインを試してましたが用途とは合いませんでしたし、バージョンアップの多いvagrantで使い続けられるか心配でした。  でもよく考えれば用途さえ限定すれば、リモート実行は難しい事じゃなのではないかと思い自分でvagrant-remoteコマンドを実装してみました。 https://github.com/masuidrive/vagrant-remote  まだ未完成のコマンドですが、とりあえず公開する事にしました。自分でもまだ使っていないので自己責任でお願いします。  Vagrantfileと同じディレクトリに下記の様な.vagrant-nodeファイルを置き、リモート実行するホストを指定します。あと同時にテンポラリディレクトリを指定します。 # .vagrant-remote export REMOTE_NODE=”user1@10.0.1.9″ # ユーザ名は省略できます export REMOTE_PATH=”/Users/masuidrive/tmp” # 指定しなくてもOK  リモート実行するノードはLinuxかOSXでvagrantをインストールしておいてください。OSXでのみテストしているので、Linuxで動かなかったらPull Requestをお待ちしてますw。 Vagrantfileも一カ所だけ変更の必要があります。homeディレクトリをマウントしている部分を下記の様に変更してください。 config.vm.synced_folder “.”, “/vagrant” ↓ config.vm.synced_folder (ENV[‘MOUNT’] || “.”), “/vagrant”  これで、vagrant-remote upをすると、リモートノードにsshしてNFSでローカルフォルダをマウントしてvagrant upを実行します。  vagrant-remote sshでsshはできますが、今のところポートフォワーディングは行いません。そのうちやるかも。

アジャイルな環境作り – そんなに急いでどこへ行く

Posted filed under Programming, Publications.

 先月、永和さんで「アジャイルな環境作り – そんなに急いでどこへ行く」と題して、私の開発環境の紹介をしてきました。  下のslideshareは、遅くて表示出来ない場合があるので、うまく見れなかった人は、PDFをダウンロードしてください。  主に、自分用のデプロイ環境を紹介しています。

YUIの開発チームは複数でのブラウザテストをどうやっているのか?

Posted filed under Programming.

 結論、リロードして目視。orz  昨日、cssniteでYahoo UI Libraryチームの方が、講演をするというので、自分の原稿もそこそこに、アップルストア銀座に聴きに行ってきました。  YUIはちょこちょこと使っているので、講演自体には目新しさはなし。 質問タイムがあるというので、頑張って英語で2つ質問してみました。

続masuidrive的プロジェクトの方針

Posted filed under Programming, Ruby on Rails.

 オレンジニュースさん、textfile.orgさんにも取り上げてもらい、masuidrive的プロジェクトの方針が予想以上の反響を頂いてちょっとびっくりしてます。  この文章自体の前提が普通の会社の組織じゃないので、そのまま参考にはちょっとならないかもしれません。ただ自分の考えをプレゼンにするというのが、すこしでも普及してくれると嬉しいなと思ってます。プレゼン資料を作りつつ、脳内プレゼンをしていると、意外に抜けている自分に気がつくので。  この対象のプロジェクトメンバーは波長の合う人を社内公募などで募って、そもそもこれを受け入れて一緒にやっていける人を前提に考えています。なのでかなり上段から見たような文章になっていますw ウチの会社自体は、とがった会社ではないので他部署で適用することは、あまり考えてません。  私が個人でやってきた方法論が、どこまで組織で通用するのか、どこで行き詰まるのかを自分で楽しみにしてます。それを糧にもう少し一般化した方法論が書けないかなとも思っています。  Tracを重要視するのは、RSSリーダで新しい指示の確認ができるからです。プロジェクトメンバーには、情報収集の意味も含めて全員RSSリーダを常用してもらおうと思っているので。 自分でも社内の他の部署との仕事もあり、情報を一元管理できないと、すでに追えない状況になっています。他部署の方に、「私への指示はTrac経由でのみ受け付けています」とはお願いできないので、まずは自分の部署からという感じです。  もぎゃさんからリクエストの「subversionでのファイル管理方法」も含めて、もう少し細かい部分も書いていきます。この連休ぐらいには。

プロジェクトの始まりはTracから

Posted filed under Programming, Publications, Ruby on Rails.

そんなわけで、プロジェクトの始まりはTracから。これがないと仕事が始まりません。 Tracが一番良いわけでも無いんだけど、日本語マニュアルがあるところと、ユーザが多いことから、subversionとの連携スクリプトなどが多数公開されているところが、選択理由です。 Railsベースでも複数、プロジェクト管理ソフトが出てきているので、どれか良い物に育ってくれると嬉しいなと思っています。 さて、tracのインストール方法はwebで沢山見つかるので、それを参考にインストール。 Tracは初期設定でも十分使いやすいんですが、チケット登録で担当者をドロップダウンリストにするために設定を変更します。 tracの設定ファイル conf/trac.iniの下記の項目を変更してください。 [trac] default_charset = utf-8 # 文字コードはUTF-8で [ticket] restrict_owner = true # 担当者をドロップダウンリストにする ユーザ登録は、.htpasswdにユーザを登録後、下記のコマンドを実行して権限を与えます。 trac-admin ./ permission add アカウント名 TRAC_ADMIN そのあと、このユーザにはログインしてもらい、画面の右上「ユーザ設定」からメールアドレスを登録してもらいます。これを登録して貰わないとチケット登録画面の担当者として選択できません。 あとは、コンポーネントと優先度を変更します。まずは優先度を日本語にします。 trac-admin ./ priority change blocker 今すぐやる trac-admin ./ priority change critical 急いでやる trac-admin ./ priority change major 普通 trac-admin ./ priority change minor あとでもいい trac-admin ./ priority… Read more »

masuidrive的プロジェクトの方針

Posted filed under Programming, Ruby on Rails.

 初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど)  NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。  仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。  仕事をする上ではコミュニケーションが欠かせませんが、特に社内のコミュニケーションは口頭による指示が中心になると思います。何か指示をするにしても、「なぜ今その指示をするのか」「これをすると何のためになるのか」と言った背景が全ての指示で語られることはありません。実際、すべてを説明している時間は無いはずです。  しかし、理由や目的の伝わらない指示は、なかなか思うとおりに実行されません。ここにメンバー間でしっかりとした共通認識があれば「この指示はこの部分に必要なんだろうな」と目的を推測したり、「ここは私ならこう思うから、違う理由を聞いてみよう」などの、アクションが取りやすくなると思います。  そこで、せっかく個人では無く、会社員として仕事をするので、この共通認識の部分をプレゼンにまとめて、これを基盤に仕事の方針を決めていきたいと思います。とは言っても、初めてこういう事をやるので、まだまだ全然なダメダメな資料です。しかし明示することによって、おかしいところも気がつきやすく、見直しもしやすくなるだろうと思って、ブログに公開することにしました。  オンラインとPDFで公開しているので、もし良ければご覧下さい。  一緒に仕事をする人には、この資料を読んで「masuidriveなら、こういう風に考えるだろうから、こうしておこう」とか「この指示は、こういう考えでだしたんじゃないかな」と考えて貰えるようになれば大成功だと思っています。  なにせ会社員経験が浅いので、一般的な会社の仕事の進め方が分からず、この資料のどこに違和感を感じるか、実行するのに何が難しいのか、もっと良い方法はどういう事があるのか、など分からない事だらけです。  もしこのプレゼン資料をみたら、何かコメントを残して貰えると嬉しいです。ぜひお気軽によろしくお願いします。  JRubyを中心に活躍されている、大場 光一郎さん <koichiro@meadowy.org>には、資料作成とブログの校正でご協力いただきました。この場を借りてお礼をさせていただきます。