A interactive Git visualization tool to educate and challenge!
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
はじめてのDocker on Mac OS X | DevelopersIO
ども、大瀧です。 今週金曜日にあるDocker Meetup Tokyo #2という勉強会でLTすることになりまして、大慌てでDocker触ってます。Dockerの開発は非常に活発で、新機能や仕様変更が続々と出ており刺激的なのですが、手元の開発環境として使っているMBAでのセットアップ方法が以前と変わりすぎていたので、備忘録としてまとめておきます。 Dockerの実行方法はVagrantを使う方法などいくつかありますが、今回はDocker公式ドキュメントをベースに、Homebrewで簡単にインストールする方法をチョイスしてみました。すぐに陳腐化する恐れがありますので、そこんとこオナシャス！です。 必要なソフトウェア OS X Mavericks(DockerはSnow Leopard以降をサポート) VirtualBox Homebrew VirtualBoxおよびHomebrewのインス
[Vagrant] Vagrant で複数のVM を立ち上げて、お互いに通信できるようにするには [VirtualBox] - Qiita
[Vagrant] Vagrant で複数のVM を立ち上げて、お互いに通信できるようにするには [VirtualBox]VagrantVirtualBox Vagrant では、一つの BASE BOX イメージから、複数の VMを起動することができるようになってえらくステキです。 勿論、複数のイメージファイルを指定することもできますけれども、BASE BOX は素の状態にしておいて、各サーバは Chef の Role を使って識別して、構成できるようにするのが宗教的理由により優れていると判断しましたので、そのように構成してみようと至ったわけです。 今は、たまたま、ZABBIX2.2の環境を構成しようとしているのですが、ZABBIX の Webフロントエンドと、ZABBIX本体(+DB)を別々のサーバにして構成してみようというところから、この考えに至ったというか、今朝、入門Chef So
![[Vagrant] Vagrant で複数のVM を立ち上げて、お互いに通信できるようにするには [VirtualBox] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b17ce683526f7a43a00407458df55ee593cb6fe1/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCVmFncmFudCU1RCUyMFZhZ3JhbnQlMjAlRTMlODElQTclRTglQTQlODclRTYlOTUlQjAlRTMlODElQUVWTSUyMCVFMyU4MiU5MiVFNyVBQiU4QiVFMyU4MSVBMSVFNCVCOCU4QSVFMyU4MSU5MiVFMyU4MSVBNiVFMyU4MCU4MSVFMyU4MSU4QSVFNCVCQSU5MiVFMyU4MSU4NCVFMyU4MSVBQiVFOSU4MCU5QSVFNCVCRiVBMSVFMyU4MSVBNyVFMyU4MSU4RCVFMyU4MiU4QiVFMyU4MiU4OCVFMyU4MSU4NiVFMyU4MSVBQiVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSVBQiVFMyU4MSVBRiUyMCU1QlZpcnR1YWxCb3glNUQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTdiMWZjYjUzYjZhMzc3MjAzNDg4OWNlNWUyNmE5ODhm%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2hvNzY1MCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODQ5NWQ2OWY5YjY3ZmU1MzI5ZTlmNzYxMTI0YmZiMWQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Ddcfda677266e8df0c6ab5db83c469bcf)
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 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
Better Specs { rspec guidelines with ruby }
translations Documentation RSpec is a great tool in the behavior-driven development (BDD) process of writing human readable specifications that direct and validate the development of your application. On the web there are many resources that give complete overview of _what_ you can do with RSpec. But there are fewer resources devoted to how to create a great RSpec test suite. Better Specs tries to
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
