最近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
先週金曜日(12/2)にクックパッドインフラ勉強会に参加しまして、そこで同社の成田さんから「今日からできるApacheモジュール開発と運用」という発表がありました。 リアルタイム画像変換モジュールの「TOFU」を開発するに至った経緯と、Apacheモジュール開発についてのお話でした。 TOFUは、S3に置かれたマスターとなる画像ファイルを取得し、与えられたパラメータでリアルタイム(オンザフライ)にリサイズ・トリミングを行うモジュール(mod_tofu)です。 料理を楽しくする画像配信システム 実際は、モジュールによる画像取得・変換をベースに、キャッシュや配信までも含めた一連の画像配信システムと言えそうです。 この仕組みをNginxを使って実装できないかと考えて、リアルタイム変換の仕組みをNginxだけで実現する方法を実験してみました。 準備するもの HttpImageFilterModul
DNS の設定のお話。 どんなサブドメインでも、同じサーバーに繋がるように DNS を設定したい時があります。 たとえば、je-pu-pu.jp っていうドメインを持ってるとして、 www.je-pu-pu.jp でも、 blog.je-pu-pu.jp でも、 abc.je-pu-pu.jp でも、 zyz.je-pu-pu.jp でも、 サブドメイン ( www とか blog とか ) の部分がどんな文字でも、同じサーバーに繋がるようにしたい。という場合です。 そんな時の、BIND のゾーンファイルの設定です。 @ IN SOA ns.je-pu-pu.jp. root.je-pu-pu.jp. ( 2008082901 28800 14400 3600000 86400 ) IN NS ns.je-pu-pu.jp. IN A 192.168.1.4 * IN A 192.168.
業務経歴: 複数のコミュニティサービスの立ち上げ、システム責任者を歴任。現在は「Tellme」と「にーよんろぐ」のシステム責任者として従事。Ruby, JavaScriptでの開発・運用をしつつ、チームではスクラムマスター的な役割をしています。 序論 本稿は主に3つの項目で構成している。 継続的開発を行うためのチーム環境構築 (アジャイルのレフトウィング) 継続的開発を行うための開発環境構築 (アジャイルのライトウィング) 実際に起こる問題とその対策 まず、開発方針の軸となる反復リリースを支えるための両翼とよばれる、チーム開発構築と開発環境構築についての記載をする。特にレフトウィングにあるスクラムが現在のアジャイル開発手法の軸となっている。その後、それらを踏まえて、実際に起こる問題とその対策についての記載をする。 また本稿では、現場の目線を重視し、出来るだけ現場で利用不可欠なもののみを記載
2本指ドラッグ 2本指ドラッグを発生させようとする位置にポインタを置きます。 Optionキーを押したままにします。 指でタッチする位置を表す円を、開始位置に移動します。 Shiftキーを押したまま、円を目的の中心位置まで移動してからShiftキー を放すことにより、ピンチターゲットの中心点を移動します。 Shiftキーとマウスボタンを押したまま、ドラッグしたい方向に円を描 くように動かした後、Shiftキーとマウスボタンを離します。 ピンチ ピンチを発生させようとする位置にポインタを置きます。 Optionキーを押したままにします。 指でタッチする位置を表す円を、開始位置に移動します。 Shiftキーを押したまま、円を目的の中心位置まで移動してからShiftキー を放すことにより、ピンチターゲットの中心点を移動します。 マウスボタンを押したまま、
この記事は RubyMotion Advent Calendar 2012 の 4 日目の記事です。 以前「RubyMotion もくもく会」で HTTP 通信のテストはどうすれば良いのだろうかという話題でモックを用意するのですかねと話が収束したのですが、面倒だし極力アプリに手を加えたくないなぁと一人もやもやしておりました。 Proxy サーバを用意すれば比較的簡単にテストできるんじゃないかと思い、ブログに書いてみました。 きっかけは 何を検索していてたどり着いたのかは忘れましたが、http://ja.favstar.fm/users/Psychs/status/3507370903 というツイートを見かけ、 さすが @Psychs 先生。神!と思った次第です。iOS シミュレータなど Cocoa API を使ったアプリの HTTP 通信は簡単に Proxy を経由するように設定できるわけ
OAuth 2.0 への理解を深めるため、自分がOAuthをどう捉えているかを整理します。 多分に誤解が含まれている可能性があるので悪しからず。 OAuth 2.0 OAuth 2.0を利用してリソースサーバ(=Web API)と通信を行う場合、 以下の処理が行われます。 ユーザは認証情報を認証サーバに渡してアクセストークンを発行してもらう ユーザはリソースサーバと通信する際にアクセストークンを一緒に渡す リソースサーバは受け取ったアクセストークンからユーザを識別する リソースサーバは識別結果をもとに適切な処理を行いレスポンスを返す 認証情報 認証情報には幾つかのパターンがあり、以下の情報が含まれます。 アプリケーションを識別するための情報 ユーザを識別するための情報 認証方法などを表すメタ情報 認証サーバとリソースサーバ 認証サーバは、アプリケーションを登録したり、アクセストークンを発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く