Dockerを使ったGolang開発環境 - unknownplace.org
しばらくiOSアプリのクライアントサイドばかり開発していてサーバサイドプログラムにご無沙汰だったのだけど、 最近またGoでアプリのサーバサイドを書くようになった。 ちょうど xhyve が話題になっているのもあって、OS X の仮想環境がアツい感じだったので、 ひさしぶりに Docker で開発してみよう、と思いたち、Dockerを使ったアプリ開発をやってみている。 docker-compose を使って依存ミドルウェアも一緒に立ち上げる docker-compose [1] というのを使うと、複数のコンテナを同時に立てられ、それぞれにリンクも良い感じにやってくれる。 開発環境を作るにはもってこいのツールだ。 GoのWebアプリ サンプルとして以下のようなアプリを考える。 // main.go package main import ( "fmt" "log" "net/http" "gi
Google認証なリバースプロクシ＆静的コンテンツ配信サーバー「gate」 - unknownplace.org
Kibana や Grafana を使う時に、これらはjsのツールなので、 Erasticsearch や InfluxDB といったバックエンドサービスにjsからアクセスできるようにする必要がある。 そのためには、 普通にバックエンドサービスのportを開放 nginxとかでリバースプロクシ とかする必要があり、めんどくさい。 さらにセキュリティのことを考えると、2の方法のうえに、nginxでSSL+Basic認証なんかにする必要があってよりめんどくさい。 さらに、僕はBasic認証が嫌いだ。 昔は Firefox + 1Password で良い感じにBasic認証の入力が行えたが、いまはだめになってしまったし、 Basic認証だとアカウントの管理もめんどくさい。 なので、Google認証なhttpdでリバースプロクシもできる、gateというツールを作った。 https://github
Go言語のOS X上でのGDBデバッグ環境構築 - unknownplace.org
Go言語は gdbでのデバッグがサポートされている のだが、OS X でそれを使おうとしたらいろいろ罠にはまったのでここに記しておく。 (このエントリ執筆時の手元の環境は OS X 10.9(.0) Mavericks + Xcode 5.0.1) 罠一覧 OS X 付属のgdbが古い Xcode 5.0.1のclangだとgdbのビルドがこける ビルドするgdbはpython2にリンクさせないとGo付属のruntime-gdb.pyが動かない[1] ビルドしたgdbにコード署名をしないと他プロセスをアタッチできない OS X 付属のgdbが古い Goのコードをgdbでデバッグするには、gdb 7.1以上が必要ということだが、OS X (Xcode?) 付属のgdbは古くて使えない。 手元のバージョンは GNU gdb 6.3.50-20050815 (Apple version gdb-
TwilioのRedisによる決済サービスの障害、2つの原因 - unknownplace.org
Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
GNU screen の裏にいる Window で完了したコマンドを Growl 通知したい - unknownplace.org
というようなことをつぶやいていたら、 Twitter / hchbaw: @typester 最近になって screen -Q windows とできるようになってますね。 と教えていただいた。 -Q コマンドというのは -X と同じようなものだけど、コマンド結果を screen 内のステータス領域ではなく標準出力で得ることができる。また、-X はつねに実行時にそれ自体がアクティブな screen セッションになるのに対し -Q はアクティブなセッションにクエリを投げる感じで、セッションが切り替わらない。（この辺は理解が怪しいので突っ込み歓迎） それでそれを使うと screen -Q windows と実行することで :windows で echo されるのとおなじ文字列を標準出力で得ることができる。その出力をパースすれば、自分が screen の裏にいるかどうか判断することができるという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
