タグ

2016年2月4日のブックマーク (12件)

  • Performance is a Feature

    20 Jun 2011 Performance is a Feature We've always put a heavy emphasis on performance at Stack Overflow and Stack Exchange. Not just because we're performance wonks (guilty!), but because we think speed is a competitive advantage. There's plenty of experimental data proving that the slower your website loads and displays, the less people will use it. [Google found that] the page with 10 results to

  • Rebuild: 127: Post-mature Optimization (omo)

    Hajime Morita さんをゲストに迎えて、f.lux, Michael Stonebraker, GitHub, JIRA, 高速化などについて話しました。 Show Notes Facebook admits that its app is draining your iPhone's battery 意見を持つ iOS 9.3 f.lux Sherlock Twilight Night Light mode in Google Play Books Readings in Database Systems, 5th Edition Michael Stonebraker dear-github: An open letter to GitHub from the maintainers of open source projects JIRA vs GitHub issues

    Rebuild: 127: Post-mature Optimization (omo)
    razokulover
    razokulover 2016/02/04
    この回おもしろかった
  • Readings in Database Systems, 5th Edition

    Readings in Database Systems (commonly known as the "Red Book") has offered readers an opinionated take on both classic and cutting-edge research in the field of data management since 1988. Here, we present the Fifth Edition of the Red Book — the first in over ten years.

    razokulover
    razokulover 2016/02/04
    おもしれ〜
  • DeNAの分析を支える分析基盤

    Hadoop/Spark Conference Japan 2016でのライトニングトークの資料 by Ryosuke Iwanaga (@riywo) This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS a

    DeNAの分析を支える分析基盤
    razokulover
    razokulover 2016/02/04
    アーガスくん怖すぎ
  • Google BigQuery クエリーリファレンス - Google Cloud Platform

    このページは、2015 年 3 月 1日現在の https://cloud.google.com/bigquery/query-reference の翻訳です。最新の情報は、こちらの英語のページもご確認ください。 修正等のフィードバックがあれば、こちらからお寄せください。 BigQuery のクエリーは、標準 SQL の SELECT 文にアレンジを加えたものを使って書きます。BigQuery は、COUNT、算術演算、文字列操作など、さまざまな関数をサポートしています。このドキュメントでは、BigQuery クエリーの構文と関数の詳細を説明します。 目次 クエリーの構文 BigQuery のすべてのクエリーは、次の形式の SELECT 文です。 SELECT [[AS] ] [, [[AS] ], ...] [() WITHIN ] [FROM [(FLATTEN(|()] [, |()

  • BigQuery の課金仕様と注意点をまとめてみた(2015-07 時点) - Qiita

    最初は安く収まっていた BigQuery の費用もだんだん膨らんできた ので、自分(社内)用にまとめたものです 広告事業(アドネットワーク)のログを BigQuery に入れているので、それなりにデータ量も増えてきて、こういうことも考えていかないといけなくなってきました どの操作にお金がかかるのか データを保存しておく データを Streaming Insert(≒ 追加)する データを走査して取得する クエリを発行する データの保存 $0.020 per GB, per month 1 TB を 1 ヶ月保持すると、$20 かかる データの Streaming Insert $0.01 per 100,000 rows until August 12, 2015. After August 12, 2015, $0.01 per 200 MB, with individual rows

    BigQuery の課金仕様と注意点をまとめてみた(2015-07 時点) - Qiita
  • いまさらだけど、Nginx が出力したアクセスログ(ltsv形式)を fluentd 経由で BigQuery に送ってみたよ - えいのうにっき

    前回の いまさらだけど fluentd に入門した - えいのうにっき に引き続き、「いまさら fluentd」シリーズ(?)。 blog.a-know.me 事例としてはめちゃくちゃありそうなこの組み合わせ、「自分的にかゆいところ」に手が届いてるかんじの記事がないような気がしたので、それを少しでも増やすことができれば、という思いで、書いてみる。 nginx のアクセスログの形式を ltsv 形式にする まずはこれから。 そのために nginx の conf に手を加える必要がある。たとえばこんな↓かんじかな。 log_format ltsv "local_time:$time_local" "\thost:$remote_addr" "\tforwardedfor:$http_x_forwarded_for" "\treq:$request" "\tstatus:$status" "\t

    いまさらだけど、Nginx が出力したアクセスログ(ltsv形式)を fluentd 経由で BigQuery に送ってみたよ - えいのうにっき
  • CloudFrontのログをfluent-plugin-bigqueryを利用してBigQueryに入れるようにした - Glide Note

    TL;DR Amazon CloudFrontのアクセスログをBigQueryに入れるようにした BigQueryへのデータ投入には社内の他プロジェクトでも利用していて実績があり、KAIZENがメンテナになっているfluent-plugin-bigqueryを利用 背景 ここ2ヶ月くらい、あらゆるログをBigQueryに集約しつつあって、今回はAmazon CloudFrontのアクセスログについて作業をした。 Amazon CloudFrontのアクセスログには以下のような特徴がある。 Amazon CloudFrontのアクセスログは数時間〜1日程度遅れでS3のBucketに追加される。時系列はバラバラ CloudFrontのアクセスログがtsv形式。 ベストエフォート型で全てのログがS3に収容される保証は無い gzで圧縮されてS3に追加される(BigQueryに入れるにはgz形式から

  • Fluentdの仕組み -バッファ機能でログ収集漏れを防ぐ- - Tech-Sketch

    OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合

  • fluentdを導入時にまず知っておいたほうがよさそうなこと(インストール、監視、HA構成、チューニングなど) - Qiita

    fluentdを導入時にまず知っておいたほうがよさそうなこと(インストール、監視、HA構成、チューニングなど)CentOSFluentdElasticsearchtd-agent fluentdを使う時にまず知っておいたほうがよさそうなこと はじめに 朝からElasticsearchへのデータの投げ込み方を考えていました。 データベースやメッセージキューなどにデータを投げ込んでおいて、ニアリアルなバッチでElasticsearchに投げ込むよりも、fluentdを使う方が圧倒的に簡単で信頼性が高いものができますね。自分で作りこむのがバカらしくなりますね。 ということで、fluentd利用時に気を付けておきたいことについて調べてみました。内容は公式ドキュメントの内容をベースに自身で調べたことを追記しています。公式ドキュメントへのリンクも貼ってありますので適宜そちらをご覧いただければと。 環境

    fluentdを導入時にまず知っておいたほうがよさそうなこと(インストール、監視、HA構成、チューニングなど) - Qiita
  • 偽のシンプル、正しいシンプル - komagataのブログ

    組織論でもプログラムでもデザインでも「シンプルにしよう」とよく言いますが意味がフワッとしてるので自分的まとめを。 Rich Hickeyのシンプルの定義 シンプルさの必要性 | eed3si9n 上記の俺的まとめ。 simpleの対義語はcomplex。simpleを語源・対義語から考えると、多数のものを組み合わせてない・一つのものという意味になる。それに対してeasyを語源から考えると、近くのものという意味になる。 complexこそが悪。 easyだけどcomplexなもの = 甘え hardだけどsimpleなものを恐れない。simpleなものはしばしばeasyでない。 命名 上記を使いやすくするために、easyでcomplexなもののことを偽のシンプル、hardでsimpleなもののことを正しいシンプルと名付ける。 simpleでeazyが最良でcomplexでhardが最悪だが、

  • AMP (Accelerated Mobile Pages) 導入前に知っておくといい話

    [レベル: 上級] GoogleのJohn Mueller(ジョン・ミューラー)氏が、英語版の公式ヘルプフォーラムで Accelerated Mobile Pages (AMP) について質問したユーザーに情報を提供しました。 AMP導入を検討している人の参考になるので紹介します。 AMP導入に参考になる情報 今のところは、正規の検索ではまだAMPページを表示していない。2月後半の開始を予定している。 まず最初は、ニュース系コンテンツをカルーセル形式で表示することになるだろう。エンジニアによれば、ほかのタイプも公開後すぐに追加していく予定とのこと。 一般的には、AMPページはページ単位で結び付けられる(各AMPページには対応する[通常の]ウェブページが存在する)。もちろんAMPだけのページを作ることもできる。 私たち[Googlebot]がクロールして link rel=amphtml

    AMP (Accelerated Mobile Pages) 導入前に知っておくといい話
    razokulover
    razokulover 2016/02/04
    ニュース記事以外は3月くらいかなー。対応するの早かったかもしれない。まだ仕様変わる可能性あるし。