こちらの勉強会で話した資料です。 http://dev-revolution.doorkeeper.jp/events/8881 勉強会のまとめはこちらです。 http://togetter.com/li/631383
「納品のない受託開発」の先にある「エンジニアの働きかたの未来」
こちらの勉強会で話した資料です。 http://dev-revolution.doorkeeper.jp/events/8881 勉強会のまとめはこちらです。 http://togetter.com/li/631383
【鍵管理】~/.aws/credentials を唯一のAPIキー管理場所とすべし【大指針】 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSを利用していると、APIキーの利用は必要不可欠です。数多くのAWSアカウントを扱っていれば、たまたまAPIキーは利用せず、管理コンソールへのパスワードだけで済んでしまうケースもあるかもしれませんが、これはごく例外的な状況です。しっかりとAWSを使いこなしている以上、APIキーを管理する機会が必ずあります。 鍵管理が大変 というわけで、皆さんは自分用のAPIキーを数多く管理しているわけですが、その管理は行き届いているでしょうか。少なくとも「失くしたｗｗｗ」なんていう事態は是非避けたいものです。大丈夫すか？ では、とあるキーがありましで、それが書き込まれている場所を全て挙げられますか？ あちこちのファイルに書き込んだりしていませんでしょうか。aws-cli用の設定ファイルはもちろん、環境変数設定用の~/.bash_profileの中、シェルのhist
Docker で Web アプリを運用してみた - kotas.tech
Docker してますか！ 実は実験的に Docker で Web アプリを数ヶ月運用しており、色々と試行錯誤してきたので、少しずつアウトプットしていきます。 ちなみに Ruby 製のアプリで、AWS の EC2 上で運用している、小〜中規模ぐらいのものです。 2014-06-16 16:00: 追記あり Docker イメージのビルドについて Dockerfile を普通に書いてます。 今のところ、2層構造にしていて、 ベースとなるイメージ Ruby アプリケーションサーバー (Puma) アプリケーションのソース (git clone) bundle install デプロイされるイメージ (ベースイメージを元に作る) git pull してソース更新 bundle install し直してベースにない gem を入れる asset の precompile という感じでやってます。
RubyMotion で AWS iOS SDK を使う (もしくは Objective-C ライブラリの使い方、あるいはドラクエ10について) - naoyaのはてなダイアリー
ポロン「右手からRuby･･･」 ポロン「左手からiOS SDK･･･」 ポロン「合体!!!」 ポロン「魔力解放 RubyMotion!!!!」 ･･･いやぁロト紋、懐かしいですね。こんにちは。みなさんドラクエ10やってますか！ぼくは全職カンストなのでやってません！あと数日で公開のパッチ1.2を待ち焦がれています。次のアップデートに期待してるのはなんといっても魔法戦士ですよね。以前にみたところによると魔法戦士にはMPを他のプレイヤーに分け与えるMPパサーという職業スキルがあって、パラディンのHPパサーが専用じゃなかったようにこれも非専用スキルのようです。と、いうことは！余ったMPを武闘家なり盗賊なりに分けて無限タイガークローなんてことが可能そう。これは熱い･･･当初予定のMPパサーの仕様に修正が入らなければ、ですけど。スティック100に振ってる自分としてはスーパースターがスティック装備可能
開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー
開発メモその4です。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で、システム構成の変更時に EC2のスナップショットからインスタンスを複製して Elastic IP で切り替えているという話をしました。 ただ、この方法はそのままでは一点問題があります。スナップショットを取ったタイミングと現時点でシステム構成に差分があった場合にどうするか、です。例えば nginx の設定をほんの少しだけ書き換えたい、とかその都度スナップショットを取っていては流石に面倒。 その手のスナップショット時点からの差分を複製されたインスタンスに簡単に適用するために、基本的なサーバー設定周りは chef-solo で管理してます。chef はサーバー構築自動化ツールで、chef-solo は chef のクライアント・サーバーを必要としないライト版、とでも
死んでしまったサービスの供養
この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。 2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。 サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。 FANIC とは FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成＆音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作
Vagrant + Jenkins の CI を AWS でも回す - naoyaのはてなダイアリー
昨晩 Jenkins と Vagrant で CI だ、と書いたら という反応があった。確かに、可能なら物理サーバに依存しない形でテストできるとより嬉しい場面もありそうですね。 しかしそこは Vagrant。Vagrant はバージョン 1.1 から、バックエンドを VirtualBox だけでなく AWS (EC2) などの IaaS を指定して仮想サーバーを作ったり壊したりできるようになっています。詳しくは http://d.hatena.ne.jp/naoya/20130315/1363340698 この辺を。この機能を利用すれば昨日の Jenkins + Vagrant のフローをほとんど変えずに、EC2 のインスタンスでのインテグレーションテストができそうですね。 速見もこみち「では、早速やっていきましょう。」 Multi VM でローカル/リモート両対応に せっかくなので Vi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマに贈るクラウドとの上手な付き合い方
Amazon VPCトレーニング-VPCの説明
クックパッドでのVPC移行について
Gitを使ったRoute53の管理