ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

pprof って go のやつでしょ？　node のプロファイルが取れるわけ無いやろ，と僕も思っていたんですが以下のライブラリを使うことで取れることがわかりました． github.com 使い方については Using the Profiler に書いてあるとおりで，アプリケーション側に const profile = await pprof.time.profile({ durationMillis: 10000, // time in milliseconds for which to // collect profile. }); const buf = await pprof.encode(profile); fs.writeFile('wall.pb.gz', buf, (err) => { if (err) throw err; }); という風に書いてあげるとwall time

bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--

tcpdumpの提供する-Wオプションと-Gオプション，ならびにcrontabを併用するといける． tcpdumpの-Wオプションはログローテーションを行う回数で，-Gはそのローテーション期間を秒数で指定できる． 例えば $ tcpdump -w ./%Y%m%d%H%M%S.pcap -W1 -G60などとやると，ログローテーション1回，ローテーション期間は60秒となるので，つまり60秒tcpdumpを実行した後にexitする (ローテーション1回指定なので)． ちなみに-wオプションで指定するファイル書き出し先についてはstrptimeと同じフォーマットが利用できるのでこういう時に便利． あとはcrontabでこのコマンドを仕込んでやるとOK (id:hirose31さんから「crontabでは%をエスケープする必要がある」との指摘があり修正しました)． 55 * * * * tcpd

例えばElasticsearchを使ったプロジェクトがあったとして，それをCircleCIで継続的にテストしたいとする．CircleCI 2.0はコンテナベースのCI環境なので，そのプロジェクトが採用している言語のコンテナの上でElasticsearchを動かす必要がある．どうするか． circleci.com CircleCIのドキュメントに記されている通り，docker imageは複数起動することができる．一番目に指定したdocker imageはprimary containerとして取り扱われ，stepsに書く手続きは全てそのコンテナ上で実行される．それ以降にdocker imageを指定した場合はそのimageがprimary containerと共通のネットワーク上で立ち上がり，そのコンテナ上で公開されているポートについてはprimary containerのlocalhos

私信ですが転職いたします．以下の通りです． From: LINE To: Soracom 関係各位に感謝を申し上げます．ありがとうございました． 以上です．よろしくお願いします． なお本記事は以下のレギュレーションに従いました． タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。— laiso (@laiso) 2017年8月1日 twitter.com [追記] 職場崩壊だとか，ネガティヴな方向に持って行きたがる向きが散見されますが，それらに対する回答は以下の通りです．職場崩壊なんて一切無かったし，本当に良い会社及び同僚でした．これ，キラキラレギュレーションに引っかかりますかね？ まあいいや！ ブクマ100超えたら突然見当違いなことを言って来る人が

最近はサーバのメトリクス収集にPrometheus，その可視化の為のフロントエンドとしてGrafanaをハードに使っている．Grafanaは予想よりもはるかに格好良いグラフが生成されるのでやる気が出て良い．デモを触るとなんとなく温度感がわかると思う． そうしているうちに，これは便利なのでサーバのメトリクス以外の情報も入れてみましょうという発想があり，サービスのKPIに関するような情報も入れ始めている． とまあここまでは良いのだけれど，そうやって収集したデータも，格好良く可視化したグラフも，人に見られなければ一切の意味が無いのでそうした無意味を避けるためにデイリーでグラフを社内チャットに放流することにした． という事になるとGrafanaで描画したグラフを画像としてエクスポートする必要が出てくる． Grafanaにはグラフを画像としてシェアする機能があるのだけれど，これはブラウザをポチポチす

人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！　しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する

mysql Connector/J を使う時に色々効きそう (あるいは効かなそう) な設定項目を調べたのでまとめておくこととします．なお，対象としている mysql のバージョンは5.6 (以降)，Connector/J のバージョンは5.1.34 (以降) です． Connector/J は設定できる項目が多くて迷ってしまうんですが，道標となる資料も幾つかあるのでそれについてもまとめておきます． 何か追記すべき事項があったら適宜追加してゆきたいと思っています．「これも入れたほうが良いのでは無いか」というようなご指摘ありましたらご一報ください． 設定項目 characterEncoding おなじみの文字コード．要設定． ちなみに以下の様なテクがある． Driver doesn't support utf8mb4 for servers 5.5.2 and newer. The drive

HikariCP のような connection pool を利用する上で犯しがちなミスとして，connection leak (pool から connection を borrow しっぱなしで pool に返却しないこと) があると思います．connection leak を放っておくと pool 内の connection が枯渇してにっちもさっちもいかなくなるため再優先で修正しなければなりません． connection leak を修正するには，まず connection leak の発生を検出する必要があります． 以前紹介したような，JMX を使って connection の状態をモニタリングする方法 もありますが，この方法では leak が発生した瞬間を検出することが出来ませんし，どこで発生したかもわかりませんからデバッグが難しくなります． そこでどうするかというと，Hika

さて2015年も暮れになってきましたので，各位に於かれましては常識の如く kamipo TRADITIONAL を有効にしていることと存じます． kamipo TRADITIONAL とはなんぞや，という方は以下のエントリが参考になりますからご一読下さい． さて Java で kamipo TRADITIONAL を有効にするテクについては 上記のエントリで紹介したわけですが，21世紀の我々には文明があるので connection pooling というものを使う (あるいは使えと言われる) ケースが多くなっております． ということで HikariCP を使うわけですが，この時に kamipo TRADITIONAL をどう設定するのかという話題があります．connection を borrow する度に sql mode を set するというのも渋いので，以下のようにしてやるとよろしい

本記事はサクッと perl6 (rakudo) が動く環境を作って，ズバッと Hello world してみるというやつです． 早速行ってみましょう． 1. rakudobrew をインストールする rakudobrew をインストールします rakudobrew というのは perl5 で言うところの perlbrew/plenv，ruby で言うところの rvm/rbenv のようなものです． なぜこうした物を使うかというと，perl6 は開発が非常に活発な言語であるためにデイリーで変更が入っていて，直っていたり壊れていたりするためです． 2015年10月現在，perl6 をやるときは rakudo と MoarVM は HEAD を使うというのが紳士の嗜みとなっています *1． というわけで入れましょう． git clone https://github.com/tadzik/rak

kamipo traditional については以下の記事が詳しい． ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 ところでこれをJava，というかJDBCで有効にするには以下のように書いてやるとよろしい． try (final PreparedStatement preparedStatement = connection.prepareStatement( "SET SESSION sql_mode = 'TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY';")) { // This is "kamipo TRADITIONAL". More strict, healthy, nice. // https://github.com/kamipo/etcfiles/blob/

fluentd (td-agent) をプロジェクトで使う際に，開発途中で「fluentd に対して正しい内容のログを飛ばせてるのかどうか」みたいな事をテストしたくなる瞬間というのがあると思います． td-agent のモックサーバ的なものを立てて，そこに実際に payload を投げつけて内容を確認するというのでも良いとは思うんですが，もっとお手軽な感じで「送信自体しないで，インターナルなデータ構造に対してログをスタックしておく」という風にすることでテストやデバッグを簡単に出来るのではないか，ということでそういう動きをするSenderを書きました．Maven Central にも上げています． 使い方は synopsis に書いてある通りです．MockSender 経由で put したログについては fluentd に対して送信されず，代わりに MockSender 自体がメンバーとして

大昔に収録した職質テックトークの第9回をやっとこさアップしました。 http://shock-sheets-tech.tumblr.com/post/69076765242/09-ytnobody よろしくお願いします。 12月9日 (月) にはMachida.pmもあるようですので，そちらも是非。 職質テックトーク第10回 やります。 12月7日 (土) の15:00〜16:00の間くらいから放送するんじゃないでしょうか。 ゲストはYAPC 2013のベストスピーカーであり，先日JPA理事に就任された和田裕介さんです。 おや、ゆーすけべーさんがこのpodcastに出演されるのは2回目ですね。 YAPC 2014の話など，色々聞けると思うので楽しみです。 以下のアドレスから視聴いただけます。よろしくお願いします。 http://www.ustream.tv/channel/shock-sh

新潟県長岡市というのは非常に学びのある都市で、 定期的に「長岡 IT開発者 勉強会(NDS)」という催しが開催されています。 (とは言っても僕が参加したのは今回が初めてですが) このNDSが何かというと、まあその名の通り長岡市で開催されている IT開発者の勉強会です。主な参加者は新潟県在住のエンジニアの皆さんのようです。 おお、一切説明になってねえなこれ！ で、今回のNDSのテーマが「Scala入学式」という非常に魅力的な題材で、 Scala とか触ったこと無いし、折角の機会だからこの際入学しようじゃないか、 ってことで上越新幹線に乗ってトコトコ長岡まで行ってきました。 この会まで Scala 触ったこと本当に無くて、 def main(args: Array[String]): Unit = { ... } みたいな構文を目の当たりにした時に「正直これ僕には無理じゃね？」とか 思ってたん

幸運にもはてなインターン2013に参加する機会に恵まれましたので、謹んで参加して参りました。 「参りました」っていうのは、「精神的に参ってしまいました」とかそういう意味合いではありません。謙譲語です。 (非常に遺憾な事に、他のインターン参加者のブログを見ると、僕が精神的に参っている人のように描かれているので) さて、本エントリの前半でははてなインターンの全般の話を取り上げます。が、このへんは他のインターン参加者のブログの方が詳しいし丁寧だと思うので、そちらを読むと良いでしょう。本エントリではできるだけ技術的な部分 (というか、開発プロセスのあたり) に触れて行きたいと現時点では考えていますが、スピリッチャルな内容になるかもわかりません。 エントリの後半は与太話です。それは例えばソフトウェアエンジニアの話かもしれないし、漫画家の話かもしれないし、サラリーマンの話かもしれないし、あるいはそう、