TL;DR; Eventual Consistencyとか言いながらどうせもっとまともな一貫性実装してることはよくあるんだからみんな適切な名前を使おうぜ。 なぜこの記事を書くのか NoSQLの文脈においてスケーラビリティとのトレードオフでEventual Consistencyという用語は結構な頻度で出てくる。 ACIDに対抗してBASE(Basicaly Avalilable, Soft state, Eventual consistency)なんて言葉が出てきたり、CAP定理の中のAとPだと言ってみたり、分散システムのスケーラビリティを高めるために人類は一貫性を諦めることに余念がない。 その一方で、諦められた一貫性に関しては雑な分類論で語られる事が多く実はもっと適切な言葉があるのに「Eventual Consistencyです」なんて言われる事が良くある。そこで、この記事では過去に並行

この記事では、 ALB Ingress Controller について書きます。 ※ zalando-incubator/kube-ingress-aws-controller については、 Kubernetes2 Advent Calendar 2017 7日目 @mumoshu 先生の記事で、 書かれていますので、そちらを参照して下さい WHY Kubernetes on AWS で運用している場合、 Kubernetes の Service を作成すると、 AWS の Classic Load Balancer が作成されます。 Classic Load Balancer 以外に Application Load Balancer を利用したい場合が以下のような時にあります。 http2 を利用したい /blog などリソース毎に向き先を区切る Kubernetes on AWS を

はじめに Kubernetes 上のアプリケーションに対して、curl や tcpdump など使い慣れたツールを使ってデバッグを行いたいと思う場合があるかと思います。kubectl exec を利用するとコンテナ内のコマンドを実行することができ、従来 ssh で行っていたデバッグに近いことが可能になります。一方、コンテナには必要最低限のものしか含めないことがベストプラクティスとなっているため、使いたいコマンドが含まれていないこともあるでしょう。 本記事では、kubectl exec を主としたデバッグの方法と、コンテナに使いたいコマンドが含まれていない場合や kubectl exec が利用できない場合の対応方法などについて説明します。確認は Kubernetes v1.8 で行い、コンテナランタイムは Docker を前提としています。 kubectl exec を使ったデバッグ ku

本来はWebサーバー側でクエリを対応することではありますが、 時々どうしようもないボーンとしている状態の時が突然来た経験はありませんか？ エンジニアから焦って問い合わせが来た時、突然のアラートが飛んできた時など。。。 そんな時にインフラエンジニアも一緒に焦ってしまわないように、どのクエリが問題なのかを特定して対処する方法のまとめました。 めちゃくちゃ時間がかかるクエリが走っていて、問題が起こっている場合の対処です。 問い合わせを行っているWebサーバー側で対応が出来ると良いのですが、どうしても DB サーバー側で対応の必要がある時があるのでその時の方法です。 pg_stat_activity で統計情報を取得 現在実行中のクエリはpg_stat_activityテーブルが管理しているため確認できます。 https://www.postgresql.org/docs/9.5/static/m

Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ

概要 仕事をしたことがある人なら心得ているけど、初めてインターンに参加したり、メンターもいてがっつりコードを書くインターンをしたことがない場合は、分からないことも多いはず。 インターンに行く前に事前に行っておくといいことや、開発する時に気をつけることをまとめました。 半分以上は仕事の進め方を書いています。設計を大きく間違えたり、メンターの人が話をしていることを勘違いすると、どんなにコードを書いても成果がでません。最初の1週間は、コミュニケーションの方法や、確認の方法などに慣れてください。 参加する前 インターンに行く会社のブログを見る(Wantedlyなら) 例) Wantedlyの開発フロー http://qiita.com/awakia/items/c571e93e96a1ec28044f (github) 初めてコードレビューされる人のためのpull requestとcommitの作

はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope

現在、Sync というメッセージングアプリのWindowsデスクトップ版を、Electronを使って開発している。(同じくElectronを使ったMacデスクトップ版はすでに公開済み!) 普段はMacのみでNode/Electronを開発しているのだが、今回WindowsでのElectron開発・ビルド環境構築の知見がいくらか手に入ったので、この記事でまとめてみた。 あらかじめ Kobito for Windows の開発方法について @mizchi さんに詳しく話を聞かせていただいておりそれがとても参考になった (ありがとうございました)。 OS Windows 10 Home 64bit をMac上のVM (VMWare Fusion) にインストールした。 ライセンスはWindows版開発のために新しく購入した。 マルウェア対策 アプリのバイナリの汚染や誤判定を防ぐため、開発環境では

Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

はじめに Swiftのコードは多様な記述の仕方ができるので柔軟でかつ表現力もありますが、チームで開発を行うとどうしても記述の仕方が統一できず可読性も上がりません。弊社（Wantedly）でSwiftのアプリを開発した経験をもとにアプリ開発におけるコーディングスタイルガイドを作成しました。このコーディング規約がベストプラクティスだというわけではなく、Swiftもまだまだ手探りなところもあるので、参考情報としてご参照ください。また、規約の範疇ではないですがエラーになりやすい記述も合わせてフォローしています。 バージョン v0.3 改版履歴は文末を参照ください。 コーディング規約の必要性について Swiftはプログラマがリスクを取ることによってより簡素に端的に記述ができたり、型推論が強力なので型の明記を省略して記述ができます。チームでSwift開発を行う場合は、詳細に記述するのか、省略して記述す

@@ -4,7 +4,7 @@ coreos: etcd: # generate a new token for each unique cluster from https://discovery.etcd.io/new # WARNING: replace each time you 'vagrant destroy' - #discovery: https://discovery.etcd.io/<token> + discovery: https://discovery.etcd.io/xxxxxxxxxxxxxx addr: $public_ipv4:4001 peer-addr: $public_ipv4:7001 fleet:

概要 Datadog というモニタリングサービスを利用して Docker コンテナの CPU やメモリなどのメトリクス収集・監視とコンテナの死活監視をするという話。 Datadog を使うメリット Docker をどうモニタリングすべきかのモデルとなる Datadog のエージェントは、 Docker が依存する Linux の "namespace" と "cgroup" が提供するメトリクスを 15 秒ごとに収集することでモニタリングを行っている。また Docker コンテナをどうモニタリングするか・どうメトリクスを収集するか・どんなメトリクスがあるかを学ばさせてもらっている。 参考: "How Docker monitoring works" Monitor Docker with Datadog - Datadog Blog コンテナへ自動でタグ付け Datadog は Docke

Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesにこぞって開発参加する理由GoogleAppEngineDockergooglecomputeenginekubernetesGoogleCloud Kubernetes is 何 先週末、Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesに開発参加を表明して話題になったが、この連携がどんな意味を持つのかすぐにピンときた方はどの程度いるだろうか。その前に、Kubernetesって何？　Dockerとどう関係するの？　読み方すら分からないんだけど……って反応が多いと思う。 Googleのソフトウェアエンジニアで、Kubernetesの開発者であるBrendan BurnsによるGoogle I/O 2014のセッ

Swiftが発表されてから、数日経過しましたがすでにたくさんのコードがGithubに上がっています。Swiftを始めたいエンジニアが参考になるサンプルをピックアップしてみました。 自分も今週末に珈琲を片手にコードを読んでみようと思います。 Githubの検索結果URL FlappySwift 4,700★ 半日くらいで作られたFlappy Birdのクローンです。 SpriteKitを利用していて、メインのゲームロジックは２００行弱ほどで書かれています。 Swiftでシンプルなゲームを作成するのに参考になります。 GameScene.swift 一部抜粋 // // GameScene.swift // FlappyBird // // Created by Nate Murray on 6/2/14. // Copyright (c) 2014 Fullstack.io. All rig

Swiftから既存のObjective-Cのライブラリもコールできるので、新規アプリを作成する場合は移行しやすいと感じました。 Movie Screenshot :-p We are hiring! Looking for Swift programmer :-p (日本語) Swiftなら誰にも負けないiOSエンジニア・ウォンテッド！！ Github CODE // // ViewController.swift // RSSReader // // Created by susieyy on 2014/06/03. // Copyright (c) 2014年 susieyy. All rights reserved. // import UIKit class ViewController: UITableViewController, MWFeedParserDelegate {

はじめに 本投稿では、Android開発を行う中で、筆者が有益だと感じた情報やつまづきやすいポイントを、オフィシャルのソースへのリンクを中心にまとめています。これから開発を始めるチームや個人の方の参考にしていただければ幸いです。 開発の心得 Android Developers のドキュメントを読みましょう！英語が苦手な方は敬遠しがちかもしれませんが、参考になる情報がたくさんあります。ある程度開発経験を積むとスムーズに理解でき、新たな発見もあって読んでいて楽しいと思います。 https://developer.android.com/index.html 初めて開発をするという方は、Training のドキュメントを、コードを書きながら読み進めるとよいと思います。 http://developer.android.com/training/index.html サポート対象のプラットフォー

概要 AIZU ONLINE JUDGEを使用。 ICPC国内予選の問題(Volume 11)の3番目まではどの年の問題でも最低限解けるようにするのが目標。 他にも、"Course"タブに使うアルゴリズムごとに別れた問題があるのでそれをやってもいいかも。 ICPC国内予選の３問目までと言うのは、特に難しいアルゴリズムの問題が出るわけではないので、バグを生みにくいくてサクッと書ける綺麗なコード設計をする良い練習になる。 具体的には以下の様な特徴がある。 １問目はやるだけの問題。if文、ループ、配列を使った基本的な操作ができればいいものが多い。 ２問目は少し複雑な実装問題で、データをどう持つかなどの設計力が問われる。 ３問目は大抵、再帰構造が書けるかどうかが問われる問題が出る システムに慣れる ユーザー登録 まずはRegistration。自分はAffiliationにカンマを入れたら登録でき

Emacsから本格的に乗り換えて１ヶ月ほど経ったので、使ってみて気に入ったpackageとかまとめてみる。 atom-beautifier ctrl-alt-f でコードフォーマットをかけてくれる。 atom-jshint jsの構文チェック。 autocomplete-plus タイプ中に補完候補を自動的に表示してくれる。デフォルトでは自動補完が無効なので、package設定からauto completionを有効にする必要あり。 editor-stats 便利機能ではないけど、時間別のキー入力の量をグラフ化してくれる。何時頃に活発に作業しているか一目瞭然に。 gist-it 開いているファイルを即座にgistへアップできる。gist.elみたいな感じ。 注意する点は、何も設定していないとAnonymousユーザとして投稿されてしまう事。 自分のアカウントで投稿したい場合は、README

バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳＋個人のメモ 情報が古い＋理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T