技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選（新規開発のメモ書きシリーズ1）
新規開発したプロダクトについて ｢世の中に URL は出ているが、まだ正式公開していない｣という微妙な位置付けなのでプロダクト名と詳細は避けつつ述べます。短めの開発期間で急いでつくって、慌てて年末にβ版をリリースしたところです。 次の動きに向けてまったりしたり、Inside Frontend の開催に向けて四苦八苦しているところでメモ書きです。 このシリーズの他の記事はこちら。 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離 依存するパッケージの厳選 新しい技術、ライブラリを試すこと、それらを使って生産性の向上にチャレンジすることは必要です。とはいえ、程度が過ぎると逆に生産性を下げかねない
ZapierにLINE Notifyを対応してみた - Qiita
私は、多くのエンジニアがそうであるように、色々自動化するのが好きです。もちろんIFTTTも利用していますが、IFTTTは無料で使える一方で対応しているAPIやトリガーが少ないので、仕事ではZapierを利用しています（API連携が３つまで無料）。 このZapierには、対応していないAPIであっても自力で対応させる事ができるという、エンジニア向けの機能が用意されています。 OAuth認証にRESTfulというような、標準的なAPIであれば、ブラウザ上でポチポチボタンを押しながら、フォームの項目を埋めていくだけで対応できます。APIのリクエスト方法やレスポンスの内容がちょっと標準的でない場合であっても、Scriptingと呼ばれるフィルターを実装できる機能（こちらはコードを書く必要がある）を利用することで、無理やりリクエストのヘッダーやパラメータを変更したり、レスポンスの内容を使いやすく加工
rfc6749 The OAuth 2.0 Authorization Framework - OpenID Foundation Japan
Abstract OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It re
Kubernetes上でgRPCサービスを動かす
Kubernetes上でgRPCサービスを動かすことが多くなってきている．が適切にロードバランスをする，リクエストを落とさずサービスをデプロイするためにいくつか注意することがあるので簡単にまとめておく． 以下の2つを意識する． Kubernetes ServiceはL4のLoad balancer（LB）であること gRPCはコネクションを使いまわすこと KubernetesのPodは死んだり作られたりを繰り返す．KubernetesのPodにはそれぞれ内部IPがアサインされるが，このIPはPodが新しく作成される度に変わる．IPが変わってもPodにアクセスするためにKubernetesではServiceをつくる．ServiceはPodを抽象化しVirtual IP（VIP）を提供する．VIPを使うことでPodのIPが変わってもPodにアクセスすることができる． VIPはNetwork i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Expect · Jest
Nomad by HashiCorp
BLOGOS サービス終了のお知らせ