タグ

ブックマーク / hirose31.hatenablog.jp (34)

  • REST API フレームワーク Connexion のススメとその作例 - (ひ)メモ

    Python の Connexion というフレームワークとそのサンプルアプリケーションを書いたのでその紹介です。 https://github.com/zalando/connexion https://github.com/hirose31/connexion-tiny-petstore Connexion は「API (spec) First」を謳うフレームワークです。 「API First」とは、 ご存じ The Twelve-Factor App の追補として 2016 年に Pivotal 社が提唱したガイドライン Beyond the Twelve-Factor App の中のひとつです。 簡単にいうと、コードを書き始める前にまずAPIの仕様を定める。たとえば昨今のマルチデバイス対応のような複数チームで開発を進めるような現場で、お互いこのAPI仕様を拠り所とすることで、他方の

    REST API フレームワーク Connexion のススメとその作例 - (ひ)メモ
  • h2o試してみました、もしくはとりあえずサクッと既存のサイトをHTTP/2化する方法 - (ひ)メモ

    先日、HTTP/2が正式な仕様として承認されると同時に、その実装であるH2Oのv1.0.0もリリースされました。 Kazuho's Weblog: H2O, the new HTTP server goes version 1.0.0 as HTTP/2 gets finalized HTTP/2の情報はちょいちょいウォッチはしていたのですが、今までHTTP/2なサーバーを動かしたことはなく、いい機会なので自分のサイトをH2Oを使ってHTTP/2対応してみました。 https://www.irori.org 大したことはやってないのですが、Apacheでサービスしており、認証やアクセス制限、ごにょごにょ黒魔術、CGI(!)やSSI(!!)なども動いているので、ApacheをH2Oにリプレースするのは無理でした。 そこで、H2Oをリバプーとして前段に置き、Apacheを後段に置く構成にしまし

    yuiseki
    yuiseki 2015/02/23
  • Redisのクエリーアナライザー "redis-traffic-stats" を書きました - (ひ)メモ

    redis-traffic-stats という Redis のクエリーアナライザーを作りました。 https://github.com/hirose31/redis-traffic-stats redis-traffic-statsはtcpdump -wで書き出したpcapデータを解析して、以下のような統計を表示します。 総ネットワークトラフィック量と平均byte/sec 総リクエスト数と平均とピークのreq/sec コマンド毎のリクエスト数、総リクエスト数に占める割合、req/secを、リクエスト数が多い順に上位10コマンドを表示 コマンド毎の総転送バイト数、byte/secを、総転送バイト数が多い順に上位10コマンドを表示 コマンド別に、キー毎の総転送バイト数、byte/sec、リクエスト数、リクエスト数の割合、req/secを、総転送バイト数が多い順に上位10キーを表示 時間のかかっ

    Redisのクエリーアナライザー "redis-traffic-stats" を書きました - (ひ)メモ
    yuiseki
    yuiseki 2014/02/28
  • unix domain socketでファイル記述子をやりとりするソケットプーリングを書いてみた - (ひ)メモ

    unix domain socket経由でプロセス間でファイル記述子のやりとりができるので、コネクションをプーリングして、unix domain socket経由で別プロセスに貸し出すスクリプトを試しに書いてみました。 https://github.com/hirose31/socket-pooling poold.pl は起動すると 127.0.0.1:11211 へのコネクションを 3 つ作って保持し、unix domain socketをlistenしてクライアントからの貸し出し要求を待ちます。 ちなみに、unix domain socket は名前付きのではなく、abstract namespace のを作っています。これの利点は、パスに依存しないので、chroot内のプロセスと外のプロセスがやりとりできる点です。 client.pl は起動すると、unix domain sock

    unix domain socketでファイル記述子をやりとりするソケットプーリングを書いてみた - (ひ)メモ
    yuiseki
    yuiseki 2013/05/22
  • シンタックスハイライトするフィルタてないかな - (ひ)メモ

    シンタックスハイライトするフィルタてないすかねー 標準入力に色(ANSI color)つけて標準出力に出すだけのやつ。 view(vim)が出力して終了してくれればいいんだけど。。。 $ colorize < filename | less -Rとか $ crontab -l | colorize | less -Rとかしたい。 で、最終的にはLESSOPENで使いたい。 追記#1 PerlText::VimColorとTerm::ANSIColorでフィルタ書いたす。 $ colorize < httpd.conf | less -R $ crontab -l | colorizeLESSOPENで呼ばれるlesspipe.shをいじって必ずcolorizeでフィルタするようにしたら、ながーいファイルだとcolorizeの処理に数秒かかってイラっとしたのでこれはやめました。 その代わり

    シンタックスハイライトするフィルタてないかな - (ひ)メモ
    yuiseki
    yuiseki 2013/03/27
  • Re: 若者がパッケージ管理について思うこと - (ひ)メモ

    若者がパッケージ管理について思うこと - As a Futurist... 「パッケージ」を あまり入れ替えしないし、入れ替えたくもないもの 好きに入れ替えしたいもの の2つに分類して、ここ数年自分がどう管理してきたかを書いてみたいと思います。主に構成管理の切り口の話になります。 あまり入れ替えしないし、入れ替えたくもないもの 具体的には、 基的なソフトウエア coreutilsとかtarとかそういった類のもの です。 これらは最初の最初にサーバーをセットアップするときに、ディストリのバイナリパッケージを入れて基的にはそれでおしまいです。 バージョン管理、依存関係の管理はディストリのパッケージシステムにお任せです。 セットアップ後はよっぽどのことがない限り、アンインストール、ダウングレードは基的にしません。アップグレードも当に当に影響のあるセキュリティ修正のみ。追加インストールは

    Re: 若者がパッケージ管理について思うこと - (ひ)メモ
    yuiseki
    yuiseki 2013/03/16
  • Re: UNIX Command Idioms - (ひ)メモ

    Re: [twitter:@riywo]'s UNIX Command Idioms ps auxwwwwwww number of "w" depends on my mood in that day :D ps auxwwwwwwwww -L netstat -tna / -una / -tnl / -tnap tar xvf tar zxvf / jxvf / Jxvf are boring trailing slash in rsync rsync -av file [file] HOST:dir/ rsync -av dir/ HOST:dir/ tcpdump -i any -nlx strace -s 100 -fFTttt diff -u /path/to/file <(ssh host cat /path/to/file) see also: http://d.haten

    Re: UNIX Command Idioms - (ひ)メモ
    yuiseki
    yuiseki 2013/02/28
  • 感情に訴えかけるログ、 Log::Minimal::Emotional !!!! - (ひ)メモ

    某所で 人間の脳には人の顔を識別するための特別な神経回路が最初から組み込まれていて、人の顔の違いを見分けたりというのが、他の図形よりも格段に高速に行えるようになっています。ということで、ログメッセージに顔文字を入れてみたら、なにこれすごいヽ(=´▽`=)ノ ってなったところ。 という発言をみかけたので、つくりました。 Log::Minimal::Emotional - https://gist.github.com/hirose31/4958764 「エモーショナル」はお好みなものに容易に再定義可能です。 #!/usr/bin/env perl use strict; use warnings; use utf8; use Log::Minimal::Emotional; $Log::Minimal::Emotional::EMOTION->{CRITICAL} = '⊂二二二( ^ω^)

    感情に訴えかけるログ、 Log::Minimal::Emotional !!!! - (ひ)メモ
  • dstatの万能感がハンパない - (ひ)メモ

    サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47

    dstatの万能感がハンパない - (ひ)メモ
  • 垂れ流されるログのおしりを追いかける - (ひ)メモ

    滝のように流れるログは見ていて楽しいのですが、見ているばかりでは仕事にならないので、 https://github.com/hirose31/chase-tail というスクリプトを書きました。 機能はこんな感じで、 ログ中のきわどいキーワードに色をつけて目立たせる HTTPステータスの「50[0-9]」とかMySQLの「Lock wait timeout exceeded」とか 秒間にある一定行数以上ログが流れたら「NOTIFY_FLOOD」と出力する iTerm 2のPreferences→Profiles→AdvancedタブのTriggersにキーワードを登録しておくとGrowlで通知できるので、「NOTIFY_FLOOD」を登録しておけば、いつよりログがビャービャー流れたときにGrowlで知ることができます ちなみに、iTerm以外のアプリがフォアグラウンドでも、chase-ta

    垂れ流されるログのおしりを追いかける - (ひ)メモ
    yuiseki
    yuiseki 2012/01/21
  • フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - (ひ)メモ

    目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが

    フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - (ひ)メモ
    yuiseki
    yuiseki 2010/06/24
  • synergyで、キーボードだけでスクリーンを移動する - (ひ)メモ

    複数の PC を手元で操作 「Synergy」を使おう! -Win&Mac 混合対応版- - livedoor ディレクターブログ を読んで思い出したので。 通常、スクリーン間の移動はマウスポインタの移動によって行うのですが、switchToScreen(SCREEN_NAME) を使えばキーボード操作でもスクリーンの移動ができます。 「fvwm2で、ポインタ移動はマウスじゃなくてキーボード(Shift+Meta+矢印とか)で操作してます(キリッ」とかいう生粋のキーボーダーでなくても、多面スクリーンだとカレントスクリーンを見失うことがよくあると思うので、「このキーを押せばこのマシンがカレントスクリーンになる」ってのは便利なんじゃないかと思います。 自分は Linux にキーボード/マウスを繋いでいるのですが、~/.synergy.conf はこんな感じで。 カレントスクリーンがどこであって

    synergyで、キーボードだけでスクリーンを移動する - (ひ)メモ
    yuiseki
    yuiseki 2010/02/21
  • tcpdumpとiptablesの関係 - (ひ)メモ

    追記 2009-04-03 まったくもってブコメでいただいた指摘の通りです>< h2onda linux, tcpdump tcpdump(というかlibpcap)は、データリンク層(OSI layer2)レベルでパケットを取得する packet プロトコルを使ってるので、そうなります。参照: man packet(7) 2009/04/02 はてなブックマーク - h2ondaのブックマーク / 2009年4月2日 tt_clown network 細かいけど,図は逆(NIC が下)のが良いかなと思った./ "ip"tables と言う位だから,IP層でパケットをフィルタしてるて事だろうな.tcpdumpはEthernet Frameも見えるので,後は分かるな?・・・てとこか. 2009/04/02 はてなブックマーク - tt_clownのブックマーク / 2009年4月2日 pack

    tcpdumpとiptablesの関係 - (ひ)メモ
    yuiseki
    yuiseki 2010/02/14
  • そろそろFiciaについてひとこと言っておくか - (ひ)メモ

    えとらぼの『Ficia (フィシア)』、追加容量を大幅値下げ 〜315円(税込)で 100GB まで! 動画も写真もさくっとアップ〜 えとらぼ、写真ストレージサービス「Ficia」の追加容量を値下げ:ニュース - CNET Japan ぼくも携わっているフォトストレージサービスFiciaの利用料金が大幅に値下げになりました! これまで 2GBまで無料 2GB〜12GBまで315円/月 以後10GBごとに315円/月が加算 ↓ これから 2GBまで無料 2GB〜100GBまで315円/月 以後100GBごとに315円/月が加算 これまでの料金は、正直に言って高かったと思うのですが、今回の改訂でだいぶお手頃な価格(容量)になったのではないかと思います。 値下げに加え、機能的にも骨子のコンセプトの部分がだいぶ整ってきており、いい機会だと思うので、今まで我慢してきたFiciaに対する思いの丈をここ

    yuiseki
    yuiseki 2010/01/22
    FiciaがGallery Remote 2プロトコルでのアップロードに対応すれば、
  • kumofsの死活監視はこんな感じでNagiosでやってます - (ひ)メモ

    分散Key-Valueストア「kumofs」を公開しました! - 古橋貞之の日記 \(^o^)/ kumofsは、弊社のフォトストレージサービス Ficia で現在大絶賛モリモリ稼働中なんですが、その死活監視は自家製の Nagios プラグインで行っています。 というわけで、kumofsをサービスで使いたい人の一助になればと思い、ぼくが実際に行っている kumofs の監視について紹介したいと思います。 サーバノードとマネージャノード サーバノードとマネージャノードの監視には、それぞれのノードに対してステータスを問い合わせるコマンドを発行して、その応答で死活を判断するスクリプトを書いて使っています。 kumofs公開記念ということでgithubにpushっておきました。 http://github.com/etolabo/nagios-check_kumofs 問い合わせの処理は、管理用コ

    kumofsの死活監視はこんな感じでNagiosでやってます - (ひ)メモ
    yuiseki
    yuiseki 2010/01/19
  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
    yuiseki
    yuiseki 2009/10/27
  • Linuxの仮想環境 - KVM+QEMU w/ Intel VTなCore 2 Duo はかなり速そう - (ひ)メモ

    たまたまIntel VT対応なCPUのマシンが手に入ったので、ちょっとLinuxのKVM+QEMUを試してみました。その結果をちょちょっと書いてみます。 ちょちょちょっとなんで間違ってるとこがある可能性が高いのをまずお断りしておきます。m(_ _)m それから、ちょちょちょちょっとなんで、 Intel VT (Virtualization Technology) x86 virtualization Intel Core 2 KVM QEMU のあたりの説明とかインストール手順はさっくり省略します。 ちなみに Linuxの仮想環境の実装の比較は、 TechComparison - Linux Virtualization Wiki が見やすいかもです。 で、今回の環境: ハードウエア DELL, OptiPlex 745 Core 2 Duo - E6300 (2MB L2 キャッシュ、1

    Linuxの仮想環境 - KVM+QEMU w/ Intel VTなCore 2 Duo はかなり速そう - (ひ)メモ
    yuiseki
    yuiseki 2009/10/17
  • keepalivedのnb_get_retryの動きが不思議な件 - (ひ)メモ

    へんだなーと思ってたんだけど、やっぱ、意図したように動かないみたい。 [Keepalived-devel] HTTP_GET あと、hatena patch発見!! Keepalived-devel] PATCH: Include directive include ktkr!!

    keepalivedのnb_get_retryの動きが不思議な件 - (ひ)メモ
    yuiseki
    yuiseki 2009/07/23
  • keepalivedのnb_get_retryの動きが不思議な#2 - (ひ)メモ

    keepalivedのnb_get_retryの動きが不思議な件 の続き。 今回は keepalived 1.1.17 で試してみたす。 ヘルスチェック (HTTP_GETの場合) のループ間隔に関係ありそうな設定項目はこの3つ。 virtual_server group delay_loop (delay timer for service polling) real_server HTTP_GET nb_get_retry (number of get retry) delay_before_retry (delay before retry) コードレベルじゃなくて実験観察結果ですけど、まとめるとこんな感じ: ┌─────────┐ │ ↓ │ delay_loop │ ↓ │ CHECK (最大connect_timeout) │ Enable ↓ Disable │ <成功>──

    keepalivedのnb_get_retryの動きが不思議な#2 - (ひ)メモ
    yuiseki
    yuiseki 2009/07/23
  • gitのcommit、push待ちの状態をプロンプトに表示すると結構便利 - (ひ)メモ

    gitのブランチ名をプロンプトに表示すると結構便利 の続き。 gitでcommitし忘れ、pushし忘れないように、 _color_() { color=$1; shift echo -e "\e[${color}${@}\e[0m" } fg_black() { _color_ "30m" $@; } fg_BLACK() { _color_ "30;1m" $@; } fg_red() { _color_ "31m" $@; } fg_RED() { _color_ "31;1m" $@; } fg_green() { _color_ "32m" $@; } fg_GREEN() { _color_ "32;1m" $@; } fg_yellow() { _color_ "33m" $@; } fg_YELLOW() { _color_ "33;1m" $@; } fg_blue()

    gitのcommit、push待ちの状態をプロンプトに表示すると結構便利 - (ひ)メモ
    yuiseki
    yuiseki 2009/07/05