タグ

ブックマーク / qiita.com/najeira (5)

  • Go Web Frameworks 比較 - Qiita

    Go言語にはいろいろなWebフレームワークが存在して、はっきりとしたデファクトスタンダードが決まっていません。 しいて言えば標準パッケージの net/http がデファクトですが、世の中ではそこに機能不足を感じた人たちが多くのフレームワークを開発しています。 そこで、いくつかのフレームワークを取り上げて、簡単なベンチマークと、それぞれのフレームワークでのいわゆるHello Worldの書き方をまとめておきます。 これによって、フレームワーク選びの参考になればと思います。 対象 Bone Echo Gin Gocraft Goji Gorilla Kami Martini Revel、BeegoKochaなど、見かけたが入れていないものがいくつかあります。コマンドでスケルトンを作るもの、net/http の Handler interface を満たさないものは除外しました。 追加してくれ

    Go Web Frameworks 比較 - Qiita
  • ISUCON 5 決勝の天気APIの解説 - Qiita

    ISUCON 5が終わりました。 出題担当のtagomorisさん、kamipoさん、お疲れ様でした。非常に大変だったと思いますが、お手伝いさせてもらって刺激を受けましたし楽しかったし、良い経験になりました。ありがとうございます。 941さん、各言語の担当者の方々、参加者のみなさんも、お疲れ様でした。 来年もお手伝いしたいし、いや自分自身も参加もしたいし、迷うところです。 さて、ISUCON 5 決勝での天気予報APIを実装しましたので、APIの挙動や意図などを記しておきます(全体の講評は ISUCON5 選問題の公開と講評 をご覧ください)。 zipcode クエリパラメータとして zipcode を渡していましたが、APIはこれを見ていません。ところがアプリ側はzipcodeを渡すようになっています。 アプリ側の実装の意図については把握していませんが、おそらくキャッシュをしにくくする

    ISUCON 5 決勝の天気APIの解説 - Qiita
  • nginxのキャッシュ階層を深くしすぎてinodeが枯渇した - Qiita

    nginxのproxy_cache_pathの設定がよくなかったためにinodeが枯渇してエラーになったので、メモしておきます。 設定 以下のようにしていました。 proxy_cache_path /var/nginx/cache levels=2:2:2 keys_zone=hoge:10m inactive=10m max_size=100m; levels 今回の現象に関係あるlevelsについて説明します。 levelsはキャッシュファイルのディレクトリ階層を設定するパラメータです。 levels=2:2:2だと「2文字を3階層」になります。 キャッシュのキーのMD5がb7f54b2df7773722d382f4809d65029cの場合だと、キャッシュのファイルのフルパスは以下のようになります。 この設定により、ひとつのディレクトリに全キャッシュファイルを置くのではなく、ディレク

    nginxのキャッシュ階層を深くしすぎてinodeが枯渇した - Qiita
  • Go言語で非同期処理の結果を受け取る - Qiita

    Go言語にはgoroutineというものがあり、複数のタスクを並行(Concurrent)に実行したい場合に役立ちます。 またGo言語では、ライブラリなどのAPIは基的に同期版を提供し、非同期で処理したい場合は呼び出し側がgoroutineで非同期化するのが一般的です。 そこで、goroutineを使って関数を呼び出し、その結果を得るための実装方法について、自分なりに考えてみたので、ここにまとめておきます。 戻り値がない 戻り値がなく、処理が終わっていればよい場合: // boolでもよいが空struct done := make(chan struct{}, 0) go func() { // 何か処理をする close(done) }() // chanがcloseされるまでブロックする <-done 値の受け渡しがない場合はシンプルです。 Tips: 空structについて 値の受

    Go言語で非同期処理の結果を受け取る - Qiita
  • Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita

    時間 2014/11/27 の AM9時〜AM11時頃まで、全世界的に Amazon CloudFront に障害がありました。 CDNとして CloudFront を利用しつつ、障害時にはフェイルオーバーする方法をまとめました。 S3 CloudFrontのOriginがS3でない場合は、この項の設定は関係ありません。 CloudFrontのOriginとしてS3を使う場合、以下のようにします。 file.example.jp のような、使いたいドメイン名で S3バケット を作る Static Website Hosting を有効にしておく ドメイン名のバケットで Static Website Hosting が有効になっていないと、後述の Route53 の Alias Target に設定できません。 Health Check Route53 の Health Checks を

    Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita
    clavier
    clavier 2014/11/27
  • 1