ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
CircleCI 2.0でElasticsearchを起動しつつテストする - その手の平は尻もつかめるさ
例えば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
サービスを提供するにあたって取得されたくないアカウント名が集まっているライブラリが欲しいんですけど〜みたいな時 - その手の平は尻もつかめるさ
例えば `logout` みたいなユーザ名を取得されてしまうと，ユーザ側からすると不気味に見えるし，URL設計が終了している時などに脆弱性になり得る (とは言うものの，そもそもそういった脆弱性は根本的に防ぐべきだし，URL設計を終了させてはならない)． ので，タイトルのようなことをpostしたら知見がモリモリ集まってきた．ありがとうございます． 取得させたくないアカウント名を集めてあるライブラリ欲しい気がする．authとかlogoutとかdataとか……— アドセンスクリックお願いします太郎 (@moznion) 2017年4月10日 @moznion 所得させたくないアカウント名リストならこういうレポジトリがあります https://t.co/uyYJxaFbrX— kosuge (@9m) 2017年4月10日 @moznion このリストに追加で日本向けに regist っていうアカ
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
最近の社内Wikiの書き出し - その手の平は尻もつかめるさ
最近，社内Wiki書く時にその記事の頭に「この記事で分かること」というセクションを持ってくるようにしている．こんな感じ． wikiのページを開いた時に真っ先に「どういう情報が得られるか」が書いてあると，取捨選択を早い段階から行えるので調べ物のスピードが上がって良いような気がしている． あと所属している組織ではConfluenceを使っていて，Confluenceの検索機能に引っかかるような (引っかけやすいような) ワードを「この記事で分かること」に含めるように心がけている． 地味に便利になりつつある気がしている． [追記] そう言えばConfluenceの検索結果は「タイトル」と「サマリ」が出るんだけど，冒頭にこういう情報を書いておくとそれがサマリ部分に表示されるから，検索結果一覧の段階から情報の取捨選択できて便利というのもあった．
管理画面まわりの事情，負の UI/UX について - その手の平は尻もつかめるさ
管理画面を作ってると，「みだりに押されたくはないが，かといって無いと不便」みたいなボタン (或いはそれ以外の何か) を画面上に置きたくなる時があると思う． 例えばバッチで行うような処理を (なんらかの事情で) 即時実行するボタンのようなやつ．こういったボタンは便利だけれど，無闇に押されるとシステムに対する負荷が上がり，サービスの提供に悪影響を及ぼす場合があるのでなるべく押しにくくあるべきだと思う． そういった，おもてなしを目的とはせず，むしろ或る操作に対する敷居を高くするための，謂わば負の UI・負の UX をどうするべきかを軽く考えたのでここに記す． 警告を出す 例えばこの画像のような感じ． こうして注意を喚起することで精神に注意を促すくことで，みだりな利用を抑制するという方法．ボタンを赤くすることで危険な処理であることも表している． 加えてボタンが押された時に念を押すための confi
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
