メール送信のテストに mailtrap.io がとてもよい - Masatomo Nakano Blog
Quipper、日本オフィスができて半年以上達ち、このブログでも改めて色々発信してみようと思ってはいるのだけど、一度間が空いてしまったブログの再開はなかなか難しい(本人以外誰も気にしていない現実を知りつつ)。この状況を打破するために、軽いのをまず書いてみる。本当はQuipperの開発について色々書きたいんだけど、それはまた次回。 最近出会った mailtrap.io というサービスがWebシステム開発にとてもいい感じなので紹介してみる。 メール送信は、ある程度テストを自動化したとしても、繰り返し、手で実行して目で確認することも多い。テストするときは、送信先アドレスを自分にして、送信して、自分のメールボックスを開いて確認する、とか。めんどくさい。何か問題を発見したら、関係者にメールをフォワード、とかもめんどくさい。ステージング環境では実際に送らずに、ログに出すという方法もあるけど、これだと、
CircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog
最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。 CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。 色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう！ この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools /circleci.yml deployment: feature: branch: /^(?!^master$).+$/ commands: - ./script/staging_deploy.sh pro
さようならPuppet、こんにちはChef - Masatomo Nakano Blog
ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基本的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので
Gitをバックエンドに使ったプログラマ向きWiki - Gitit - Masatomo Nakano Blog
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
tenshiでサーバ上のログファイルを効率良く監視 - Masatomo Nakano Blog
tenshiとは サーバ上のログファイルは、ただ記録しておいて問題があったときの調査に使うだけではなく、リアルタイムで監視することでアプリケーションやサーバの不具合の早期発見をすることができる。問題が表面化する前に対策を行なうにはログの監視が不可欠だ。 しかし、サーバは、種類も数もどんどん増えていくものだし、それに合わせログファイルの種類も量もどんどん増えていく。全部見るのはもちろん不可能だし、適当に通知をしてもメールボックスを溢れさしてしまうことになり、結局は無視することになってしまい意味がない。 そこで、賢く効率的に監視するために tenshi というツールが非常に便利に使える。 このツール、最近しばらく使っていなかったのだが、最近会社で再び使い始め、便利さを再確認したので紹介してみる。知る人は知るツールだと思うけどいまいちマイナーなのかな？ tenshiは、元々はGentoo Lin
Gitリポジトリにあるコードを追う / コードレビュー - Masatomo Nakano Blog
これまではcommitされたコードを、commit(push時)メールでなんとなく見ていたが、取りこぼしも多いし、忙しいと、つい見なくなってしまうので、なんかいい方法はないかなとここ数カ月くらいぼんやり考えていた。で、簡単なスクリプトでできそうと気づいたのでメモ。Githubに置いてあるようなオープンソースなコードとかも追いやすいんじゃないかなー。 ちなみに、このスクリプトを書く前に、コードレビューシステム的なのを導入しようかとGerritとか、Review Boardを少し試してはみた。でも、うちで使うにはちょっと大げさ過ぎるので、導入してもツールに踊らされる or 使わなくなる、という感じがしたので、とりあえずやめた。 いまいち気に入らない点としては、Gerritとかは完全にcommit単位でのレビューなんで、ちょっとしたパッチレベルならいいのだが、がりがり書いていく中ではちょっと現実
CouchDBとMongoDBを比較してみた - Masatomo Nakano Blog
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
