HerokuでWBS砲を打ち返した話@kon_yu
Heroku で既存の本番環境をコピーしてステージング環境を作る - Qiita
すでに本番環境がHerokuにあって、ステージング環境もHerokuに作りたい場合 既にある Heroku の本番環境を fork してコピーする Forking Existing Apps | Heroku Dev Center これだけでいろんなアドオンや DB の中身もコピーされて、ステージング環境が出来上がる。アラ簡単。（http://APPNAME-stg.herokuapp.com でもう確認できる状態になってる） Collaborator 権限はコピーされないので、新たに追加し直す必要がある hook もコピーされないので、新たに追加する必要がある お手元のローカル環境に git remote add する ちょっと余談なのだが、このとき、herokuとかheroku-stgとかではなく、そのアプリケーションの名前でgit add しておくと、デプロイがプロジェクトによって違
仕事用とプライベート用のHerokuアカウントを切り替えて使う - setoya-blog
仕事でherokuを使っている人は、大体の場合プライベートでも使っていることが多いと思うが、これを切り替える方法でheroku-acccountsというherokuコマンドのプラグインがあるので、この使い方を紹介します。 参考 ddollar/heroku-accounts · GitHub heroku accountのインストール $ heroku plugins:install git://github.com/ddollar/heroku-accounts.git 切り替えたいアカウントを1つ追加する $ heroku accounts:add private Enter your Heroku credentials. Email: hogehoge@hogehoge.com Password: ****** Add the following to your ~/.ssh/co
まったりと過ごせるおれたちのインターネット、それがポエム pplog.net #pplog - ppworks.jp
@ken_c_loこと赤塚氏を中心にP氏といぬ氏と愉快な仲間たちでpplog - ゆるふわインターネットにポエムを刻もうをリリースしてました。コンセプトデザインとUIデザインは、@ken_c_lo氏です。@ken_c_lo氏のデザイナーサイドの記事は、 「俺たちのゆるふわインターネット「pplog」 をリリースしました（してました）」です。今回この記事ではプログラマーサイドとして書いてみます。 9月ぐらいから、ポエムのコンセプトを話す機会が何度かあって、issueにポエムのポエムが投稿されていました。昨年の9/27(らしい)に急に私の中のハッカソみが溢れ出てきてp4dハッカソンのノリで夕方から開発を始めました。日が変わる前にはherokuに上がっていたような気がします。ドメイン取ってから公開までが一呼吸で出来たのはherokuとrailsのおかげかなと思います。 ポエムのissueはこのよ
Sphinxで作成したドキュメントをherokuでホスティング、Continuous Documentationなススメ(Basic認証付き) - Qiita
Sphinxで作成したドキュメントをherokuでホスティング、Continuous Documentationなススメ(Basic認証付き)RubySinatraHerokuSphinx この記事は最終更新から1年以上経過しています。 気をつけてね。 ドキュメント作成に色々とよいSphinx、さてhtmlを作ったら何処でホスティングしましょうかね。 Sphinx詳細は公式:http://sphinx-doc.org 適当なレンタルサーバやs3やら、Giithub Pages等ありますが、heroku上でsinatraを使って配信する方法を紹介。 sinatraの準備 Gemfileにsinatraを入れましょう、rackupにはthinを使ってみます。
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Heroku を利用した Quipper の開発事例紹介