git cloneするときにブランチ指定して–depth指定する

よくチュートリアルのなどで

なんて感じでcloneして使うやり方を書いてあったりするけども

普通にgit cloneすると
他のブランチの情報とかも管理ディレクトリに持ってきている状態なので
ディスク容量も食うし、cloneする時間もかかる。

そこで、特にgit的な操作は以後しないのであればgit shallow cloneするのが良い。
やり方は

こうすると、ブランチの最新のリビジョンだけを持ってきてくれる。

herokuでMemory Quota Exceededと言うのが出るようになったので、puma_worker_killerを入れた話

最近、herokuで稼働させているRailsのアプリが「Memory Quota Exceeded」と言われる事が多くなり、定期的にワーカーの再起動をしたいと思ってました。

memory_quota_exceeded

見る限り、swapも出てしまい、レスポンスも遅くなっているようです。

このような場合、heroku以外だと、unicornを使うので、unicorn_worker_killerを入れるのですが

herokuだとpuma推薦なのでpuma使っていました。

で、pumaもuniconのようにworker killer系の物があるのかな?と探してたところ

puma_worker_killerがあるようなので、使ってみました。

https://github.com/schneems/puma_worker_killer

herokuでの使い方は、「Turn on Rolling Restarts」というのを使うのが推薦のようなので

その設定で行ってみました。

デフォルトだと6時間ごとに再起動ということになるので、ひとまず様子見で3時間に設定してみます。

以下が、3時間でリスタートがかかるようにした設定になります。

こちらを設定したところ

memory_quota_exceeded_after_config

ピーク時は少しswapが出る時もあるものの、割と落ち着いたのかなと思います。

しばらくはこの状態で様子見をし、アラートがまた増えるような感じであれば再度調整という事にしようと思います。

Docker for Mac bata(1.12)とpowが共存出来ない

Docker for Mac bataがリリースされ、早速インストールしてみました。

docker-app-icon

アプリケーションディレクトリに入れて、このアイコンをダブルクリックするだけで

Dockerの環境が自動的に構築されるようです。

docker-menu-iconメニューバーにはDockerのアイコンが表示されるようになります。

1.11以前にDocker ToolboxでDockerを使っていた場合、この初回の起動時に

既存環境を新しい環境で使えるように変換が行われます。(yesにした場合)

今回は、全く新しい環境にインストールをしているので

変換も何もなく、すぐにインストールが終わりました。

変換した場合には、既存環境に応じて、それなりのディスク消費があるので

ディスクの空きが少ない場合は要注意です。

さて、Dockerの環境としては、まだこれから試してみる事はたくさんありそうですが

ここで出てきた問題が、タイトルの通り

powと相性が悪そう、という点です。

powは、Rackサーバで、ローカルでバーチャルホストを提供します。

なので、test-appというプロジェクトであれば、http://test-app.devでアクセスができるようになりますが
test-app.devは127.0.0.1になるので、localhostです。

一方、Docker for Macもポートを80番で指定してコンテナを起動したりすると

http://localhost/でアクセスができるようになります。

Docker for Macは、今までのDocker toolboxとは違い

Mac上でネイティブにハイパーバイザーを使って環境を構築しているようです。

ですので、標準の設定のままだと、これらが衝突し、Dockerのコンテナにアクセスできない、といった状況が発生します。

自分でもこのあたりが今出来る設定で回避可能なのかどうかは、調査中ではありますが

覚書として書いてみました。

 

関連情報

http://pow.cx/

https://www.docker.com/

https://github.com/docker/hyperkit

http://bhyve.org/

consulとstretcherによるデプロイの検証

概要


consulのevent発行=>event watchの機能をフルに使ったデプロイになります。
event watchで起動されるデプロイツールがstretcherになります。

前提条件


オートスケーリングをする
ソースgzとかしてS3においておく
各サーバがS3からソースをダウンロードして展開する(stretcher)
オートスケーリングの仕組みは別途あるものとする

検証


consulの基本的な設定
webの場合
#/etc/consul.d/web.conf

/etc/consul.d/event.conf

インスタンスの作成時

サーバの起動スクリプトに以下を仕込んでおく
/usr/local/bin/stretcher s3://example/manifest.yml
アプリのリリース時
s3にリリースするソースファイルをアップしておく
s3のmanifest.ymlを更新しておく
consul event発行

クラスタリスタートさせる場合

/etc/consul.d/web.confに定義出来る

  • name
  • service
  • tags

の設定で頑張る事でなんとかなりそう。
具体例
/etc/consul.d/web.conf(クラスタ1のグループのサーバ)

/etc/consul.d/web.conf(クラスタ2のグループのサーバ)

クラスタ1のリスタートイベント発行

クラスタ2のリスタートイベント発行

1台だけ新しいソースにして動作確認する

これはサーバイメージの更新の時もありうるので
オートスケールの最低台数を+1する想定だけど
新しいmanifest-prerelease.ymlとかを作成して
/usr/local/bin/stretcher s3://example/manifest-prerelease.yml
として手で叩くでも良い。
それか、例えば、nginx.jsonに以下のような設定を入れ
サーバ1

サーバ2

サーバ3

サーバ4

consul reloadしてから

とすると、サーバ1だけにイベントが飛びます。

とすると、サーバ1とサーバ2にイベントが飛びます。

とすると、サーバ3だけにイベントが飛びます。
/etc/consul.d/nginx.jsonを、直接いじりたい場合(例えば、一台だけprerelease機にしたい場合)に
直接入ってファイルをいじって、consul reloadすれば、設定が更新されます。
その後に

とすれば、1台だけリリース可能。

全台デプロイ完了の検知

全台デプロイを検知する仕組みとして
consulの持つKey/Valueの仕組みを利用すると実現可能。
手順
deployイベント発行時にデプロイスクリプトであらかじめ

をしておく。

渡すmanifestファイルを以下のように

としておく。

としておく。
デプロイ時のスクリプトなどで
consul event〜〜
発行後

を監視。
keysがなくなれば全台デプロイ作業完了
最後に

を取得し
エラーがないことをチェックしてデプロイフローの完了となる。

感想

という事で、イベントを送る先をtagsで良い感じに制御出来ればconsulとstretcherによるデプロイは良さそうな気がします。
全台デプロイ完了の検知は、consulのイベントとかステータスとかだけでやりたかった。けど、なかなか上手くいかない。
引き続き良い方法があれば調べたい。
manifest.ymlはデプロイスクリプト(capistrano?)で自動で更新されるようにしたいため、ここにhook処理が羅列されるのは嬉しくない。
ソースを固めてs3に上げてmanifest.ymlを作るという部分はまだ考慮しきれていない。
各サーバでserviceにcheckという設定(このページではconsulの基本的な設定のweb.json)を付けると、指定したチェックが通るまではserviceとしては追加されないので
ロードバランサにぶら下げるときにも
consulのヘルスチェックを見てゴニョゴニョ出来たらいいのかと思ったりしました。

補足

イベント発行のAPI

gitにExcelファイルあげちゃった。そして差分も見たいです。

gitにExcelファイルあげちゃった。そして差分も見たいです。

エンジニア以外にもgithubを使い出しているところが増えつつありますが、

このような要望が少なくありません。

エンジニアとしては、それはExcelがちょっと・・・という感じかもしれませんが

非エンジニアとしてはExcelが自分の仕事の表現手段、というか

やはり操作感は他のツールとは別格かと思います。

そこにエンジニア目線で別のツールを押しつけるのもどうかと思ったりもします。

※別のツールを提供した方が効率が上がるケースももちろんあるので、その場合は提供した方が良いです。

ということで、Excelファイルをgitにあげて管理したい、しかも差分も見たいと言った場合

gitの設定を少しいじると雑ですが差分が出るようにはなります。

macの場合

前提条件

GOでコンパイル出来る環境

使用するもの

https://github.com/tokuhirom/git-xlsx-textconv

インストール

~/.gitconfig

を開きます。

git cloneしたリポジトリの直下に

.gitattributeファイルを作成します。

を追記します。

これでxlsxの結果が比較できるようになりました。

row追加

row削除

シート名変更

GOがコンパイル出来ない環境、Windows環境の場合のは、後日

Atomで特定のディレクトリの中でファイルを検索する時に使えるTips

Atom Editorで、プロジェクト内のファイルが多すぎてキーワード検索をかけると結果が多すぎて、そこからさらに検索かけたくなったりします。
そんな時に、例えばこのディレクトリは除外したい or このディレクトリ内だけ検索したい、なんて感じで条件が指定出来れば随分絞り込めると思います。

やり方は、
FindメニューのFind Project
普段、検索する時は

find

こんな感じで検索画面が開くと思います。
この3段目、検索する場所を絞る設定になっています。
例えば、
lib配下だけを検索したい場合には
ここに

と入れれば良い訳です。
もし、複数の場所から検索したい場合は

とすれば、libとappとpublicのディレクトリから検索出来ます。
さらに、例えばpublicの下に無駄に大きいassetsのautocompile結果が同時に格納されていたとして
その下は検索したくない、なんていう時は

とすれば、public/assets配下は無視されるようになります。
応用で、gitでsubmoduleを多用している場合、.git配下も検索対象になってしまいますが

としておくだけで、.git配下は無視するようになります。

では!

おまけ
grepで同様に絞り込んだりするのは

という感じでしょうか。

それでは!

Dockerを使っていく上で避けて通れないChef,ansibleとの付き合い方

こんにちは。

最近はローカルの開発環境も、ほとんどDockerに移行した感じです。

そこで、本番も見据えたDockerという事で気になることの一つ

構成管理ツール
chef、ansibleなどなどとの兼ね合い、どうするかな?

と言ったところ考えてみようと思います。

Dockerはコンテナ作成・管理ツールという性質上、コンテナ内部のパッケージやアプリの配備などをDockerfileで行う仕組みになっています。

ということは、端的に言ってしまうとchef、ansibleなどがなくてもコンテナを作れてしまいます。

わざわざDockerで作ったコンテナに対してchefを流して環境を作る、とか意味がありません。

では、Dockerfileの中でChefを呼ぶのはありか?という所ですが

個人的にはこれもあまり嬉しくないなと思います。

Dockerfileを見るだけで、そのコンテナがどんな環境になるのか、というのが一発でわかるようにしたいです。

また、構成管理ではないですが、Dockerでシェル叩いていたり、起動する単一プロセスに構成設定のシェルを指定しているDockerfileが割と多かったりしますが、これも実際何しているのか?というのをシェル見ないと分からなくなってしまうので避けるようにしています。

では、全く使わないのか?

と言われると、NOで

Dockerをそもそも動かすホストマシン側の構成管理については

Chef、ansibleが使える物と思っています。

最低限、Dockerが動かせる環境をChefで構築する

docker engine
docker machine
docker compose
docker swarm

あたりのインストールを自動化しとくのが良いと思います。

そうすることで、ホストマシンが自前だろうがAWSだろうがIDCFだろうがさくらだろうが

さらにOSがUbuntuでもCentOSでも、ホストマシンを自動で構築することも可能になってきます。

所定のdocker engineさえ入っていればコンテナが動くわけです。

なお、docker-machineを使う場合、docker-machineが対応しているクラウドサービスの場合は構成管理しなくても良い位手軽に起動する事が出来たりします。
これは、docker-machineのcreateで作成されるホストには、docker-machineが自動で上記のモジュール類を入れて環境設定してしまうためです。

Dockerを本気で使っている方々には当然の内容ではありますが、以上、一つの考え方として参考にしていただけたらと思います。

ベンチャー・中小企業における開発チームのあり方

どうも、GENDOSUです。

今回は今までの経験から、少しだけベンチャー・中小企業における開発チームについて思った事などを書きます。

ベンチャー・中小企業における開発チームで重要な事は

  • 短期間で動くものを作る必要がある
  • リーダー(CEO)の想像するものを理解し、形に出来る必要がある
  • 時には体力勝負
  • 開発メンバーは他のメンバーを信頼することが必要

まず
「短期間で動くものを作る必要がある」については、ベンチャーに限らずサービスを作っていく上で、競合よりも遅れてリリーする事は、その分野での先行優位性を失う事にほかならない。

「リーダー(CEO)の想像するものを理解・共感し、形に出来る必要がある」
これはメンバーがそれぞれCEOの考える未来を理解・共感できていなければ、少しの認識のずれから思いがけない意志の断絶が起きる可能性がある。

「時には体力勝負」
差し迫った締め切りを守れるかどうかという時には体力(気力)が重要になってくる。

「開発メンバーは他のメンバーを信頼することが必要」
ベンチャーは小規模から始める事が多く、その少ないメンバーの中で信頼できないメンバーがいる事はチーム崩壊を招く恐れがある。
また、メンバーとしては優秀であるが、人を信頼できないメンバーも同様のリスクがある。
すべての業務を自分が把握しなければいけないと思っている(各メンバーが皆そうであることが理想ではある)人が
他のメンバーを信頼できないことにより、タスクを抱え込んでしまい業務が集中し潰れてしまう事があるためだ。
さらには、信頼されないという事で他のメンバーのモチベーションが下がるという事も起こり得る。

これらはベンチャーの開発チームを立ち上げ・維持する上で重要な事柄であり、採用時には採用側・応募者側のそれぞれがお互いを見定めなければいけない。

採用側の視点で見ると、他のメンバーと技術レベルが近いか、その会社の雰囲気に合うか、人として問題ないか、プロダクトに共感しているか、将来像が想像できるか、などに比重を置く。
対して、応募者側としては、この会社のプロダクトに共感でき、10年後20年後まで自分が働いていけそうか(倒産するかしないか?という意味ではなく)、面接官だけではなくて、出来るだけ一緒に働く事になるメンバーとの接点を設けてもらう。その上でチームに馴染めそうかを確認する。
出来たら、数日実際の作業をしてもらいつつお互いが納得した上で採用が決まる事が望ましい。

という事を個人的意見として述べてみました。

次回、「ベンチャー・中小企業における開発チームの維持」

Mithril.js でちょっとはまった(いや、かなり)

Mithril.jsを始めてみて、早速というか、すごく初歩的な事かもしれないけど

バーチャルDOMという事での罠にはまりました。

バーチャルDOMはバーチャルな訳ですよ。

バーチャル

ということは、実際にリアルにはそこに無いわけで

何を言っているかわからないと思うが

もう少し具体例を出すと

Mithril.jsで動的にul・liのリスト構造を表示させる。

このul・liの各アイテムは、ドラッグ&ドロップ出来るようにする。

ドラッグ&ドロップは、sortable.jsという感じの別のjsライブラリを使う。

といった感じでリストを出力したいと思います。

このリストをドラッグ&ドロップにしたいときに、最初は上記のように

m.mountの行の下に置いてみました。

この場合、たまに動くけど、たまに動かないといった微妙な挙動になり、結構悩みました。

で、よくよく考えたら、m.mountをした時点でバーチャルがギリギリリアルになっていないのではないか?

という事でした。

たぶんこれはビンゴで、実際どのように解決したのかというと

mというメソッドの第2パラメータにconfigアトリビュートを追加します。

configというのは、リアルDOMの描画が終わった後に処理をさせたい内容を定義できる特殊なアトリビュートという事のようです。

先ほどのコードを、このような形に修正することで、

$(‘#sortedList’)が実際に描画された後に、sortableLoadというメソッドが呼び出されるようになります。

めでたし!

Mithril.js 始めました

Mithril.js はじめました。

https://lhorie.github.io/mithril/

今回、社内で使う管理画面の一部に、動的な制御入れたいな~という要望があり

その要望に対して自前で作ると

データの流れとかを考えたときにかなりややこしくなりそうだなと思い

それならクライアントサイドのjavascriptフレームワークを使おう、という事で

React.jsとMithril.jsで比較検討しました。

比較内容としては、他のサイトでも出ていると思うので、それはググっていただくとして

今回自分がMithril.jsを選んだ理由

それは学習コストが低い!

これにつきると思います。

どう低いのか?というと

mithril-doc

覚えるメソッドがこれだけです。

サンプルコードそのままですが

これだけで、bodyに動的にレンダリングしてくれます。

m.componentの書き方とか、非同期でリクエスト取りに行ったりするであるとか

書き方として覚えなければいけない部分はありますが、それでも

他のフレームワークと比べて簡単に導入できました。

次回以降、使ってみた感想というか、はまった場所、解決方法etcなどを順次上げていけたらと思います。

gendosu流、dockerの使い方(Docker composeを使う)

dockerを開発環境で使うに当たって

前回「gendosu流、dockerの使い方」という内容を書きました。

その内容だと、

通常Dockerコンテナを手動で起動するには
まず、Dockerfileを作って自分好みにイメージを作成
作成したイメージからdocker runコマンドでコンテナ起動
たとえば、memcachedとmysqlとredisを使った一通りの構成を手動で起動しようとした場合
それぞれにイメージ作成やdocker run(start)をして起動していかないといけないです。
コンテナ間にリンクを張っている場合は起動順序も考慮する必要があります。

面倒ですね。

そこで、今回はDocker-composeを使ってみたいと思います。
こちらのツールはDockerのオフィシャルで配布されているツールになります。

簡単に言うと、複数コンテナの情報を1ファイルに集約して、そのファイルを元に
1コマンドで全コンテナを起動できるようにするツール

という事になると思います。

早速

インストール

Docker composeのインストールは

https://docs.docker.com/compose/install/

をみて作業を進めます。

これでdocker-composeというコマンドが入りました。

docker-composeを使うには
コマンドを実行するディレクトリ配下にdocker-compose.ymlというファイルを作成します。

※ディレクトリ構成

今回は前回の構成
webとmysql
という2つのコンテナを起動するような構成でファイルを作ってみたいと思います。

Dockerfile(supervisordのディレクトリも)は前回の物を流用します。

# Dockerfile

EXPOSEとCMDは、次のdocker-compose.ymlで設定するので、ここでは設定してません。

# docker-compose.yml

これで設定ファイルの準備が完了しました。

起動はdocker-composeにオプションを指定して実行します。

docker-composeのオプションで、代表的な物は

  • up
    コンテナをイメージから作り直して起動する
  • stop
    すでに起動しているコンテナを終了する
  • start
    停止しているコンテナを起動させる

あたりかと思います。

起動してみます。

upというオプションを指定して起動させました。

Dockerfileのビルドが走った後に

各イメージからコンテナが生成されて起動された事が確認できると思います。

あとは、前回同様、ポート2200を指定してsshすることでwebコンテナへログインする事が出来ます。

gendosu流、dockerの使い方

以前よりローカルでの仮想環境の生成・破棄は容易になったような気がしますが

Vagrantでは、インスタンスの生成、破棄のコストが高い気がするので

そこのところをDockerを使ってやってみるようにしてみました。

gendosu流dockerの使い方

まずは、ベースになるマシンとしてUbuntu Server 14.10 64bitの仮想マシンを立ち上げます。

これは、VagrantでもVMwareでも問題ないです。

今後、頻繁にアクセスすることになるので、vmのIPをhostsに登録してしまいます。

hostsには

192.168.?.?    local-vm

として登録しちゃいます。

これで、vmに

ssh root@local-vm

という感じでログインできるようになりました。

ここから、dockerのセットアップをします。

ubuntu14では、

http://docs.docker.com/installation/ubuntulinux/

にあるとおりに

とやってインストールします。

これで、入ったので、dockerにコンテナを作ってみます。

ただ、普通にやるとコンテナ内へのアクセスが面倒なので

各コンテナ内にsshを起動してしまいます。

これで、ポート指定で外部からssh接続できるコンテナになります。

やり方ですが

Dockerfileを作ってイメージを作成するようにします。

# => Dockerfile

というファイルを作成します。

同じ階層にsupervisord/ssh.conf

を作成します。

こちらは

とします。

このDockerfileをdocker buildでイメージにします。

これで、sshdが起動するdockerコンテナのイメージが作成されました。

このイメージを元に、「run-ubuntu-ssh」という名前でコンテナを起動します。

これで、2200番のポートを指定してssh接続が出来るようになりました。

各コンテナでsshが起動するのは無駄な気がしますが

アクセスが容易になる分、開発環境では便利になるのではないでしょうか。

さて、sshdは起動しましたが、たいていの場合MySQLとかも同時に入れたりしたくなったりします。

MySQLの場合は、別のコンテナでMySQLだけが入ったものを用意します。

これは、Docker.ioのdockerhubから持ってきます。

https://registry.hub.docker.com/

この中に、MySQLというリンクがあるので、ここを開いて、手順通りにやると

MySQLの入ったコンテナが起動できます。

先ほど、「run-ubuntu-ssh」コンテナを起動したときに使ったコマンド

docker runに、別のコンテナへのリンクを追加するというオプションがあります。

今回はそのオプションを追加します。
※先ほどのdocker runを実行している場合、一度docker stop、docker rmでコンテナを破棄します。

mysqlという名のコンテナに対してリンクを張っています。

run-ubuntu-sshコンテナの内部からは、mysqlという名前でmysqlコンテナへ接続できるようになっています。

というコマンドでMySQLへ接続できていればOKです。

別のコンテナを起動する場合、先ほどのdocker runのコマンドで、-p 2200:22のところを2201:22という感じにインクリメントしていくことで、比較的容易にコンテナを管理できると思います。

Ruby 2.2 がリリースされました

クリスマスプレゼントなのか

Ruby2.2 がリリースされてました。

https://www.ruby-lang.org/ja/news/2014/12/25/ruby-2-2-0-released/

Rails使いとしては

たとえば、新しい Ruby のガーベージコレクタは Symbol オブジェクトのガーベージコレクトができるようになりました。 2.2 以前の GC は Symbol オブジェクトのガーベージコレクトに対応していなかったため、この新しい GC によって Symbol オブジェクトについてのメモリ使用が削減されます。 Rails 5.0 ではこの Ruby 2.2 以降でのみサポートされる Symbol GC が必須とされる予定です。 (詳細は Rails 4.2 のリリースについてのポスト を参照してください)

との事なので、今後のことを考えると、早めにRubyもバージョンをあげてしまいたいなと思ったりします。

git cloneした時に、Gtk-WARNING **: cannot open display:

git cloneしたときに

(gnome-ssh-askpass:***): Gtk-WARNING **: cannot open display:

という表示が出てエラーになる。

どうも、SSHの処理がパスワード入力ダイアログを出したいらしい。

これに関連する環境変数が

SSH_ASKPASS

という事で、これをunsetして見ます。

[shell]unset SSH_ASKPASS[/shell]

これで、無事git clone出来るかと思います。

 

TortoiseSVN・TortoiseGitでマージツールにお悩みの場合にはP4Mergeを

TortoiseSVNや、TortoiseGitで、競合が発生した場合に使用するTortoiseMergeですが、あまり使い勝手が良いとはいえないです。

そんなときは、P4Mergeを入れてみましょう。

インストールは

http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools

から。

キャプチャ

このように、Visual Merge Toolのみを有効にして、後は無効にします。

これでインストール。

インストールが完了したら、TortoiseGitの設定をします。

設定画面を開き、キャプチャ

 

マージツールの項目を選択。

外部を選択してから、P4Mergeのパスを設定します。

これで、設定は完了です。

git diffで違うブランチのファイル、または違う名前のファイルを比較する

同一リビジョンで違うファイルを比較する

違うブランチのファイルを比較する

同一名称でブランチ間比較

Windowsに複数バージョンのRubyをインストールする

今回の要件

  • Windowsに複数のバージョンのRubyをインストールする。
  • バージョンの切り替えを出来るようにする。
  • ネイティブなgemもインストールしたい。
    たとえばnokogiri とか jsonとか

ダウンロード

ということで、まずは必要なRubyのダウンロード。
以下のページからインストーラをダウンロードします。

http://rubyinstaller.org/downloads/
http://ruby-lang.org/からもリンクがあります。

今回はシステム側に2.0.0、切り替え用として1.8.7をインストールします。

なので、ダウンロードページから

2.0.0のインストーラと1.8.7のインストーラをダウンロード。
現時点でダウンロードページにアップされているインストーラは
Ruby 2.0.0-p353 (x64)
Ruby 1.8.7-p374

続いて、それぞれのバージョンでネイティブのgemをインストール出来るようにするために
DEVELOPMENT KITをダウンロードします。
DevKit-tdm-32-4.5.2-20111229-1559-sfx.exe
DevKit-mingw64-64-4.7.2-20130224-1432-sfx.exe

Ruby本体をインストール

まずは、2.0.0のインストーラで普通にインストールします。

[インストーラ画面割愛]

インストールパスは
C:\Ruby200-x64
とします。

システム環境変数へは、C:\Ruby200-x64\binをPathに追加設定します。

つづいて、1.8.7のインストーラを起動してインストールします。

インストーラ画面割愛

インストールパスは
C:\Ruby187
とします。

この1.8.7の場合はシステム環境変数へはパスを追加しないようにしてインストールします。

これで二つのバージョンをインストールしました。

これを切り替えるためのツールをインストールします。

切り替えるにはpikというツールを使います。

Linuxな環境とかだと、rvmのようなイメージです。

pikは以下のページよりダウンロードします。

https://github.com/vertiginous/pik/downloads

今回はインストーラ形式のものをダウンロードします。

インストールパスは
C:\pik
と指定します。

Append c:\pik\ to system path.

にチェックを入れておきます。

インストールが完了すると、プロンプト画面でpikコマンドが使えるようになります。

pikコマンドでは、rvmと同様、インストール出来るRubyのバージョンが一覧表示できます。

今回はすでに2.0.0と1.8.7をインストールしてあるので、これをpikのconfig.ymlに登録します。

pik add C:\Ruby200-x64\bin
pik add C:\Ruby187\bin

pikの設定は
c:\Users/hoge/.pik
というディレクトリに出来上がるconfig.ymlを編集します。
※出来てない場合、pik listとかをたたくと、出来上がると思います。
それでも出来上がらない場合、手で作りましょう。

設定がファイルに入ったことを確認します。c:\Users/hoge/.pik
というディレクトリに出来上がるconfig.ymlを確認します。

設定をしたら、設定内容をpikからも確認してみます。

を実行。

Rubyのバージョンを切り替えるには

切り替わると、pik listのコマンド結果で矢印の位置が1.8.7の前に来ていると思います。
Rubyのバージョンを確認してみましょう。

を実行。

続いて、

を実行。

これで、devkitがインストール完了です。

ネイティブなgemがインストール出来るか確認します。

ネイティブなgemをインストールする時にエラーが出る場合、オプションに–platform=rubyという指定をつけます。

試しにjsonを入れてみます。

これで問題なくインストール出来ていれば、完了です。

同様の作業をc:\Ruby200に対しても行います。

2.0.0用のdevkitは、また別のインストーラなので、それを使ってインストールします。

CentOS 5.9 で git をインストールする

CentOS 5.9 には、標準状態ではyumでgitをインストール出来ない模様。

なので、RPMforgeを使ってyumにリポジトリを追加してからgitをインストールして見ます。

http://repoforge.org/use/
このページを参考に、該当のrpmファイルをダウンロードします。

ダウンロードしたパッケージファイルをインストールします。

yumで検索してみます。

見つかったので、yumでgitをインストールします。

rvmを使った環境で、unicornをcrontabなどに登録する時の手順

rvmを使って実行環境を分けつつ、crontabなどで自動起動をさせたい時

まずはrvmでラッパーを作成する

これを実行すると、~/.rvm/binにstart_unicorn_railsというファイルが出来上がる

このファイルに対してunicorn_railsに指定するパラメータを指定してやると

rvmを読み込んだ状態でunicorn_railsを実行してくれる。