タグ

2014年7月30日のブックマーク (5件)

  • 「開発現場で活用するVagrant」を発表しました

    JAWS-UG三都物語 2014 にて「開発現場で活用するVagrant」という発表を行いました。 Photo By Yuko Oshima 5 つトラックがあるなか、テクニカルトラックでの発表でした。開放感を感じる会場で、快適にセッションを行うことができました。 発表内容 Vagrant を現場で活用していく上で参考になる情報を、と考えたところ、やはり実際に動くデモが良いと思い、デモを中心にセッションを行いました。 発表資料は、以下です。 デモで利用した Varantfile などは、下記で公開しています。 https://github.com/shin1x1/vagrant-demo-20140705 デモでは、同じ PHP アプリケーションについて仮想環境やプロビジョニングツールを変えて構築を行いました。(実際に一からコードを書く時間が無かったので、できあがったものをお見せする形でし

  • ブックマークレットの書き方の段階的な発展の仕方 - ザリガニが見ていた...。

    ブックマークレットとは、JavaScriptコードが保存されたブックマークのことである。クリックすると、そこに保存されているJavaScriptコードが実行される。 通常のブックマークのアドレスには、http:で始まるURLが保存されている。 ブックマークレットのアドレスには、javascript:で始まるJavaScriptコードが保存されている。 はじめの一歩 WebブラウザのURLフィールドに以下のように入力して、returnキーを押してみると... javascript:alert("hello world!!") アラートダイアログが表示された! URLフィールドのアイコンをブックマークバーにドラッグ&ドロップすると、そのJavaScriptはブックマークレットとして保存される。 あるいは、aタグのリンク先にJavaScriptを設定しておけば、そのリンクをドラッグ&ドロップして

    ブックマークレットの書き方の段階的な発展の仕方 - ザリガニが見ていた...。
  • dogmap.jp を t1.micro から t2.micro に変更してみました - dogmap.jp

    CPUクレジット残高については、Cloud Watch で確認することができます。 「CPU Credit Usage (使用量)」「CPU Credit Balance (残高)」という項目が追加されているので、そちらを参照してください。 2014-7-18 追記 Amazon MarketPlace からも HVM 版の網元AMIが利用できるようになりました。 WordPress powered by AMIMOTO (HVM) t1.micro などの m1 インスタンスなどの HVM に対応していないインスタンスタイプはご利用になれません。 そちらが必要な場合は、従来の PVM 版をご利用ください。 さて、そんでは実際に1日 dogmap.jp を動かしてみて CPU 負荷がどれくらいだったのかを見てみましょう。 上のグラフは 7/3の0:00 – 7/4の0:00までのCPU使用

    dogmap.jp を t1.micro から t2.micro に変更してみました - dogmap.jp
  • Capistrano3を最後にもう一度だけ懇切丁寧にまとめてみる - そのねこが学ぶとき

    2017-08-15 追記 Googleの「Capistrano」検索順位で上位にあるためか、いまだにこの記事がたびたびブクマされるんですが、3年前の情報ですし、執筆者はRubyを専門としたプログラマーではないのでその点ご注意ください。(追記ここまで) いろいろエントリーを上げながら苦しんでいたCapistranoだが、ようやっとそこそこ落ち着いてきた気がするのでそろそろ完結編といく。Capistranoの基とかはすでにこちらのエントリーで書いたので、今回は各設定ファイルの書き方とか、その他ハマったポイントを中心に。 今回作成したファイル 以下4ファイルを作成した。 Capfile config/deploy.rb config/deploy/staging.rb lib/capistrano/tasks/unicorn.cap 基的にCapistranoを使う場合「必須」なのは上2つ

    Capistrano3を最後にもう一度だけ懇切丁寧にまとめてみる - そのねこが学ぶとき
  • MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋

    MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス

    MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋