タグ

2014年1月10日のブックマーク (5件)

  • Railtie, Engine 関係資料 - Qiita

    Rails3レシピブック外伝 https://speakerdeck.com/u/a_matsuda/p/rails3-recipe-book-gaiden 118ページ Engineを使う 使いやすくなった Rails 3.1 の Engine http://d.hatena.ne.jp/passingloop/20110801/p1 Rails Guides - Getting Started with Engines http://guides.rubyonrails.org/engines.html Extending Rails 3 with Railties http://www.engineyard.com/blog/2010/extending-rails-3-with-railties/ 日語訳 http://www.engineyard.co.jp/blog/2013

    Railtie, Engine 関係資料 - Qiita
    moqada
    moqada 2014/01/10
  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • serverspecとdocker-apiでDockerfileをTDD

    serverspecとdocker-apiDockerfileをTDD いくつかDockerfileを書いてきた.今書いているDockerfileは短くてシンプルなものばかりだが,もっと長く複雑化した時に不安になりそうだ.不安を解消するにはテストしかない.さらにテスト駆動的にDockerイメージを開発できたら素敵だ.つまり, テストを書く Dockerイメージを作成して,テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して,テストの実行 -> GREEN テストを… の流れができるとよい. ということで,RSpecを使ってTDDでDockerfileを開発するというのをやってみた,tcnksm/docker-rspec.今回実現したのは以下. Docker Remote APIDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp

  • クライアントサイドJavaScriptのテストカバレッジをCoverallsに投げる - Webtech Walker

    CoverallsというGitHubプロジェクトのテストカバレッジを記録するためのサービスがあって、クライアントサイドのJavaScriptのテストでもできそうだったんでやってみた。 最近のJavaScriptのカバレッジツールはBlanket.jsがいけてるらしいんだけど、これを使ってクライアントサイドJavaScriptのカバレッジをCoverallsに投げるの若干めんどそうだったんで、ponchoっていうラッパーを使ってみた。 ponchoはMocha、PhantomJS、Blanket.jsをうまいことつないでくれるやつで、普通にMochaでテスト書いてるプロジェクトだったらすごく簡単に設定できる。Mocha限定になっちゃうけど。 すでにMochaでテストが書かれてて、test/index.htmlとかでテスト実行できる(ブラウザで開いてMochaのテストが走る)とすると、まず、

    クライアントサイドJavaScriptのテストカバレッジをCoverallsに投げる - Webtech Walker
  • ssig33.com - Docker をプロダクトのデプロイに使う

    コミケの列に並んでたあたりのころから Docker 格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ