プログラム

  var _hashMerge = function(target) {
var sources = [].slice.call(arguments, 1);
sources.forEach(function (source) {
for (var prop in source) {
target[prop] = source[prop];
}
});
return target;
};

を定義しておけば、

var origin1 = {a: "foo"};
var origin2 = {b: "hoge"};
var merged = _hashMerge({}, origin1, origin2);
// => Object {a: "foo", b: "hoge"}

といった具合でマージできる

JavaScriptのハッシュのキーへ任意の変数名を設定したいつもりで、以下の様に書くと意図した挙動にならない。

例えば下の場合、

var key = "foo";
var data = {key: "hoge"};
// data
// Object {key: "hoge"}

dataというハッシュに foo というキーを設定したかったができていない。

そこで、以下の様に関数を定義してあげると所望する処理を実現できる。

var hash = function(key, value) {
var h = {};
h[key] = value;
return h;
};
var key = "foo";
var data = hash(key, "hoge");
// data
// Object {foo: "hoge"}

dataのキーにfooを設定できている。

Mocha とshould.jsでテストを書いていて例外が起こるテストを書いていて、少し詰まったのでメモ。

例えばhogeというメソッドに空文字列を渡すと例外が生じるというケースのテストを書きたいときに、

foo.hoge('').should.throw();

という書き方をすると、これは誤りで

(function(){ foo.hoge('') }).should.throw();

と書くのが正解。*1

実際に書いてみると下の様な形になる。(確認用なのでテストの中にクラス入れているが、ここは本来requireして呼び出す形。)

これでmochaを実行すると、

$ node_modules/mocha/bin/mocha --reporter spec
Foo
#sample1
✓ equal test
#sample2
✓ exception test
2 passing (8ms)

といった形で例外を起こすテストができている。

2度調べたので記録。

node.jsではパッケージ管理にnpmがあって、更に package.json というjsonファイルがあるとそこに定義してあるパッケージ依存関係に基いてパッケージのインストールがされる*1 のですが、これそもそもどうやって作るの？と思って調べたのでメモ。

$ npm init

これでOKだった。 これで package.json が作成される。

で続けて、プロジェクトに必要なパッケージをインストールする場合は、

$ npm install (パッケージの名前) --save-dev

とすれば、自動的に package.json に必要なパッケージが追記された上でプロジェクトディレクトリに node_modules というディレクトリが作成されてインストールが行われます。

minaでデプロイした際にIRCへ通知を行う様にしたのでその際の対応のメモ。ゴールとしては、IRCの任意のチャンネルにデプロイ開始時等にメッセージを流したいと思います。

そういえばIRCで流す文字に色を付けたい

上の様に貼った画像の様な形でIRC上に色つき文字で表示されると可視性も高くて良いのでStringIrc という便利GemをGemfileに追加しておきます。

# Gemfile
gem 'string-irc'

追加したら bundle install します。

config/deploy.rb にIRC通知用のtaskを追加

minaの設定中に、IRC通知用の定義を追加します。今回、自分は下の様な形で書いてみました。

require 'string-irc'
namespace :util do
desc "#hoge IRC notice. (start)"
task :irc_notice_for_start do
messages = [
StringIrc.new('[hoge Deploy] Start!').white('orange').bold.to_s,
"---> #{Time.now.to_s}",
"---> Deploy to: #{domain} / Git: #{repository} / Branch: #{branch}"
]
messages.each do |message|
irc_notice '#hoge', message
end
end
end

このタスク中にある、irc_notice というメソッドは別途定義していますが省略します。役割的には任意のチャンネルに任意の文字列を通知できる様にしています。*1

試しにこのタスクだけ動作を確認したければ、

$ bundle exec mina util:irc_notice_for_start

で確認できます。

deployタスク中にIRC通知用タスク追加

上まで準備できたら実際にMinaの deploy タスク中に上で新設したIRC通知用のタスクを追加します。

# config/deploy.rb
# (中略)
desc "Deploys the current version to the server."
task :deploy => :environment do
deploy do
# Put things that will set up an empty directory into a fully set-up
# instance of your project.
invoke :'util:irc_notice_for_start'   # ここを追加した
invoke :'git:clone'
invoke :'deploy:link_shared_paths'
invoke :'bundle:install'

以上で準備が完了です。実際にMinaで

$ bundle exec mina deploy

とすれば、設定したIRCのチャンネルへデプロイ通知された上でデプロイが行われます。

Chefでコンフィグレーションをさせることを先日から取り組んでいて、その中でサーバに接続する予定のユーザの公開鍵を予め配置しておきたいと思っていたところ以外とあっさりとできたのでそのメモ。

状況的にはチームで共有しているユーザがあって、

• 対象のサーバに存在するそのユーザを利用して複数の端末から公開鍵認証でのSSH接続を行いたい
• そのため各端末の公開鍵を予め管理してコンフィグレーションする際に自動的に設定したい

が、満たせれば満足。これができれば自分たちの状況であれば、LXCを作るたびにこのレシピを適用すればすぐにチームメンバがSSH接続を特定のユーザでログインできる様になります。

まず、公開鍵を配置するdefinitionを新しく定義します。

# site-cookbooks/base/definition/authorized_keys_for.rb
define :authorized_keys_for, :keys => "public-keys", :group => nil, :home => nil do
user  = params[:name]
group = params[:group] || user
home  = params[:home]  || "/home/#{user}"
keys  = data_bag params[:keys]
if keys.any?
ssh_public_keys = keys.map do |key|
data_bag_item(params[:keys], key)
end
directory "#{home}/.ssh" do
owner user
group group
mode 0700
action :create
only_if "test -d #{home}"
end
file "#{home}/.ssh/authorized_keys" do
owner user
group group
content ssh_public_keys.collect{ |x| "#{x['key']} ##{x['id']}" }.join("\n")
end
end
end

次に配置したい公開鍵をdata bagとして定義します。今後配置したい鍵が増えればその毎に定義を増やしていけばよくなります。

data_bags/public-keys/(ユーザ名).json に足していきます。

# data_bags/public-keys/hideack.json
{
"id": "hideack",
"key": "ssh-rsa AAAAB3…."
}

ここまで準備できたら、上のdefinitionをレシピ中で使えるので、記述します。

# site-cookbooks/base/recipes/default.rb
authorized_keys_for 'remper'   # ← これが上のdefinition呼出
%w{ 〜 }.each do |pkg|
package pkg do
action :install
end
end

実行してみます。

$ knife solo cook remper@*****
Running Chef on ****...
Checking Chef version...
Enter the password for remper@*****:
Uploading the kitchen...
Generating solo config...
Running Chef...
Starting Chef Client, version 11.8.0
Compiling Cookbooks...
Converging 10 resources
Recipe: base::default
* directory[/home/remper/.ssh] action create
- change mode from '0775' to '0700'
* file[/home/remper/.ssh/authorized_keys] action create
- update content in file /home/remper/.ssh/authorized_keys from d0209a to 5cf54f
(略)

これで、Chefを適用したサーバに対してSSH接続の認証に利用するための公開鍵の配置が行われました。地味に楽になりました...。

参照

• About Data Bags
• http://docs.opscode.com/essentials_data_bags.html
• Chef cookbook to add ssh public keys from a data bag
• https://github.com/skalar-cookbooks/authorized_keys

いま複数あるPadrinoのアプリケーションのデプロイでmina を使ってみようと試した際のメモ。
仕事ではCapistrano(+ Webistrano)を利用していますが、RubyのプロジェクトなのとソースコードもGit管理されているので試してみました。

準備

• プロジェクトのGemfileに gem 'mina' を追加した後、bundle install する
• プロジェクトルートで以下のコマンド実行してデプロイ用の設定ファイルを生成します
• 中身にかなりコメント等も含めたテンプレートが出力されるので非常にわかりやすいです

$ bundle exec mina init
-----> Created ./config/deploy.rb
Edit this file, then run `mina setup` after.

• 上で作成されたdeploy.rbを編集する
• 作成例としては https://gist.github.com/hideack/7275901 の様な形…。

接続先側(リモート側)

• あとデプロイ先のホスト(リモート側)に公開鍵認証のSSH接続をできる様にしておく必要があります
• また、更にデプロイ対象のソースコード取得にGithubを利用するのであれば、その接続先ホストからcloneできる様にする必要があります。
• リモート先の公開鍵をgithubに登録しておく。 ssh-keygen -t rsa で作成して https://github.com/settings/ssh で登録
• 登録したら、リモート側のホストでssh -T git@github.com で接続チェックしてホスト登録。*1

実行

ここまでできれば、あとはminaからsetupコマンドを実行して、リモート側のディレクトリ構成等を準備します。

$ bundle exec mina setup
-----> Setting up /home/hideack/sample
total 16
drwxrwxr-x 4 hideack hideack 4096 Nov  2 05:03 .
drwxr-xr-x 5 hideack hideack 4096 Nov  2 05:02 ..
drwxrwxr-x 2 hideack hideack 4096 Nov  2 05:03 releases
drwxrwxr-x 2 hideack hideack 4096 Nov  2 05:03 shared
-----> Done.
-----> Be sure to edit 'shared/config/database.yml'.
Elapsed time: 0.00 seconds

引き続きデプロイしてみます。上に書いたタスクだと、

• githubからclone
• bundle install の実行

が順に行われます。

$ bundle exec mina deploy
-----> Creating a temporary build path
-----> Fetching new git commits
-----> Using git branch 'master'
Cloning into '.'...
done.
-----> Using this git commit
-----> Symlinking shared paths
-----> Installing gem dependencies using Bundler
Fetching gem metadata from http://rubygems.org/.......
Fetching gem metadata from http://rubygems.org/..
Using rake (10.0.4)
(略)
-----> Build finished
-----> Moving build to releases/1
-----> Updating the current symlink
-----> Launching
-----> Done. Deployed v1
Elapsed time: 32.00 seconds

意外とあっさりとデプロイできてしまった。デフォルトでCapistranoで差分をデプロイする様になっている様で2回目以降のデプロイは相当スムーズです。(リポジトリの丸ごと clone は最初だけ、次回以降は差分のみ)

ほとんど引っかかることがなかったけど、使い始めたらいろいろ引っかかるかもしれないので、都度整理。

但し、ここまでではunicornが起動していない状態なので、タスクを更に追加していきます。(また今度)

参考

• Capistrano の対抗馬？ Mina の導入方法
• http://qiita.com/ne_ko_/items/23d447a7aba6ac910fff

突然ですがArduinoの話題。

Arduinoにイーサシールドを接続してDHCPでIPを取得し、ホスト名で示したレンタルサーバへアクセスする際の接続例。
単純にPCからtelnetしてあげるのと同じですが、接続先が共有レンタルサーバ等の場合はHTTPのリクエストヘッダにHostヘッダが無いと当然ですが接続先でホスト名を利用して切り分けられないのでになるので接続できませんね。*1

2020年10月17日注記

WordPress移設に伴いサンプルソースコードが読みにくくなっていたためgistに転載しました。

SqaleやHerokuといったPaaSサービスを利用していると環境変数を.envというファイルに定義しておくと、アプリケーション側でそのファイルの内容を環境変数として解釈してくれますが、rack-envというGemを利用すると開発環境でも.envで記載した内容を環境変数として解釈できる様になります。
以下、Padrinoで利用する場合。まず、Gemfileにrack-env追加。

# Gemfile
# Project requirements
gem 'rake'
gem 'rack-env', :group => "development"

で、app/app.rb に以下の1行を追加します。

module PadrinoSample
class App < Padrino::Application
use Rack::Env unless ENV['RACK_ENV'] == 'production' # 追加

これで本番環境と同様に開発環境上でも.envファイルを利用して環境変数を定義することができます。例えば、

HOGE=foo

と、.envファイルを定義しておけば、

get '/' do
ENV['HOGE'] #=> foo
end

これで、本番環境での動作を想定して開発環境で開発中からコード中で非公開にしたい情報をハードコーディングせずに済みます。