はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以下では grpc-go (v1.12.2) を前提に書きます。 ただ、 grpc/proposal を参照しているので、ほかの言語のライブラリにも当てはまるところがあると思います。 gRPC クライアントの再接続 gRPC クライアントがサーバーと接続を確立したあとにネットワークが切れた場合、gRPC ライブラリ側で再接続を期待すると思います。 しかし、keepalive が適切に機能していない場合、基本的に再接続は行われません。 grpc-go では、デフォルトでアプリケーションレイヤーでの keepalive は無効です。 RPC

データベースの Primary Key （の少なくとも一部）をアプリケーションが生成した UUID にすると、冪等性のある API を設計しやすい。 例えば、iOS アプリからリソース生成リクエストが重複して行われることはよくある。リトライの仕組みを実装しなくてもボタンの重複タップを UI 側で完全に制御することは難しい。古い端末ではどうしても画面描画は遅くなるので、重複タップを画面描画でコントロールしていると間に合わなかったりする。このリソースにユニークな ID （相当の値）がなければサーバー・データベース側で冪等性を確保することはできない。こういったときに、リクエスト発行元である iOS アプリで生成した UUID をリソースに含めると冪等性は簡単に確保できる。ユニーク制約に従ってエラーになるからである。 上記の例以外でも、マイクロサービス化によってアプリケーションの外側にあるプロキシ

tl;dr すべての RPC に共通する処理には gRPC Interceptor を利用する 認証 Interceptor はすべての RPC で同じ処理を行って、認可 Interceptor は gRPC サービスごとに別の処理を行えるようにする 認証に使う Authorization 値は Metadata として送信する 複数の Interceptor をまとめて書くには go-grpc-middleware の chain を使う ここでは簡単のため Unary RPC を前提にまとめる gRPC Interceptor gRPC サーバーはオプションとして UnaryServerInterceptor 型を渡すことができる。UnaryServerInterceptor 型はすべての RPC の実行前後に処理のフックを追加することができるので、いわゆるミドルウェアを実装するために

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? tl;dr First Paint はウェブページの何らかが描画されたタイミングのこと。これが遅いということは、初回の真っ白な状態が長いということ。 First Paint は Chrome Developer Tool の Audit で簡単に確認できる。 HTML は描画の起点になるので、ロード時間はそのまま First Paint Timing の遅延になる。 CSS は描画に必須なので ロード時間はそのまま First Paint Timing の遅延になる。 JavaScript は同期で読み込むと、ロード時間がそのまま Fi

はじめに JWT{JSON Web Token} は RFC7519 で規定されている、JSON をセキュアにやり取りするための仕様です。特徴は次の通り。 鍵になる文字列（以降 secret ）か公開鍵ペアのどちらかを使って署名することで「セキュアにやり取り」できるようにしている。前者は HMAC アルゴリズム、後者は RSA か ECDSA が使われる。 「セキュアにやり取り」の意味はこの JSON が適切な者によって発行されて、改ざんもされていないことが保証されるということ JSON は署名されるだけで暗号化されるわけではないので、中身は誰でも閲覧可能な点に注意が必要 JWT は eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

モチベーションとしては、複数のバッチが並行して実行されているサーバーで、それぞれのバッチごとの CPU 使用率やメモリ使用量を可視化したかった 可視化して良かった点 バッチサーバーの CPU 使用率 or メモリ使用量を減らしたいときに、どのバッチを改修すればいいのかすぐに決めやすくなった その後、バッチの改修によって CPU 使用率 or メモリ使用量が減ったかどうかがひと目でわかるようになった 既存のプラグインなどで適うものがなかったので自作した 実装方法 https://github.com/yoheimuta/Linux-GetPidstat https://metacpan.org/pod/Linux::GetPidstat Perl 製 linux-get-pidstat というコマンドラインツールが付属する 名前の通り Linux 向け pidfile をもとに、プロセスメト

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最初は安く収まっていた BigQuery の費用もだんだん膨らんできた ので、自分（社内）用にまとめたものです 広告事業（アドネットワーク）のログを BigQuery に入れているので、それなりにデータ量も増えてきて、こういうことも考えていかないといけなくなってきました どの操作にお金がかかるのか データを保存しておく データを Streaming Insert（≒ 追加）する データを走査して取得する クエリを発行する データの保存 $0.020 per GB, per month 1 TB を 1 ヶ月保持すると、$20 かかる デ

Go 言語製 BigQuery にクエリ投げるときに簡単にデコレータをつけられるラッパーツール BigQuery の課金仕様と注意点をまとめてみた（2015-07 時点） - Qiita に書いたとおり、BigQuery の検索費用は、テーブルデコレータを使えば節約できますが、bq コマンドでアドホックに実施するには使いづらいところがあります 数時間前までの指定くらいなら自力でも計算できるが、開始日時から終了日時の Unixtime を計算するのは面倒 さらにタイムゾーン込みで計算するのも面倒 ドライランで確認できるバイト数（6862860066238 bytes of data など）からどれくらいコストがかかるのかを計算するのも面倒 ということで、bq query コマンドをラップする CLI ツールを作ってみました # ドライラン # この例では 2015-07-20 00:00:0

完成イメージ 今回は、プロダクトを紹介するサイト（ブログ）を公開します 公開されているサイトは http://yoheimuta.github.io/hugo-uno-mobile-videoplayer.js/ という URL で github pages 上にホスティングされています この中で紹介されているプロダクトは mobile-videoplayer.js という iOS Safari 上で動画を自動再生するための JavaScript ライブラリ です コード管理は github で、https://github.com/yoheimuta/hugo-uno-mobile-videoplayer.js にあります 公開・運用までの流れ 自動化するための準備が必要です（下記に詳述しています、この点はタイトルから誤解されたらお手数です） 準備が整えば、それ以後は次の手順だけを手元の

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? サーバー上のシステムをチームで開発する場合、開発環境の構築をどう共有するかは課題になると思いますが、いくつかの既存のやり方には問題があります 今までの開発環境構築のやり方 README.md などに手順を書く方法 これには次の問題が発生することがあります 本番環境（ex. Ubuntu）と開発環境（ex. Mac）で土台となる OS が違う 手順書の更新漏れがある 手順書の再現性の検証がおろそかになる 手順書の更新に対して、既存の開発環境をアップデートしないメンバーが出てくる Vagrant を使う方法 これは上記のいくつかを解消します

CI を中心としたワークフローやリリース（デプロイ）自動化システムを構築するには、現在対象としているコードベースの状態を把握する必要があります ブランチは、feature か master か プルリクエストをマージしたのか タグはついているのか Travis CI でそれらを把握するためには表題にある 3 つの環境変数の意味と組み合わせを理解しないと出来ないのですが、まとまった公式のドキュメントやネット上のレファレンスが見つからなかったので書きます http://aniszczyk.org/2012/04/05/travis-ci/ より Travis CI を使ったリリース自動化の例 例えば、最近試した iOS のプロジェクトでは、次のような、Travis CI を使った比較的複雑な、ワークフローの構築とリリース自動化を行いました なぜこうしているのかという意図などは、リンク先の RE

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 日時: 2014-12:12 19:00~22:20 場所: FreakOut イベントURL: http://gcpja.connpass.com/event/9647/ togetter: http://togetter.com/li/756806 スライドは見つけ次第、追記予定 トレタのBigQuery / Google Apps Script活用術 Apps Script 最も簡単に動かせる Server Side Javascript 無料 DB, bq にもアクセスできる たかはしさん slack ボット、勤怠管理、おはよう

日時: 2014-11:30 10:00~18:00 場所: 品川シーサイド 楽天タワー イベントURL: https://github.com/GoCon/GoCon/blob/master/2014autumn.rst togetter: http://togetter.com/li/751700 スライドは見つけ次第、追記予定 当日の品川シーサイドはミニ四駆大会があった Keynote1: Rob Pike (@rob_pike) (45min) Title: Simplicity is Complicated Go の成功の要因について話したい ちまたで言われているような早さ、容易さ、ツール、ライブラリ、並行性、インターフェースも違う 単純さが要因だと私は思ってる でもそれについて理解してもらうのは難しい 収束しようとしている言語たち Lang.Next カンファレンスにて、様々な