はてなブックマーク

前から何回か興味を持ってるんだけど、ちょっとまとめて調べながら思ったことをザクザク吐き出しておくよ。 今のところ考えるちょうどいい使い方いろんな使い方ができると思うんだけど、リリースサイクルの都合ではなく どんな機能が現在のプロダクトで切り替え対象となっているのかの可視化 ( admin panel )サーキットブレイカーの意味で使うのを前提にしつつ、 カナリアリリースA/Bテストにも導入していく、くらいの感じだとよさそう。 大げさな感じがするかもしれないけど、ちゃんと考えて入れないとややこしくなるだけだなと感じているので。 雑な言い方すると feature toggle って global な状態分けの if ブロックなわけで、実際、特別な記法なんかなくたって環境変数と if だけで実現可能なわけですよ。でもそれって実装側からもプロダクトオーナー側からも実態が見えにくくなるだけでいいこと

何を解決するのかmkcertFiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you'd like. CAと証明書を作成できるCAを開発マシン上にインストールできるので、開発マシン上の https サーバを正しくユーザーに検証してもらえる開発環境を https にしておく必要がある場合に CA と証明書を管理するために openssl コマンドを覚えてくださいと言わなくて済む。 local-web-serverlwsjs/local-web-server: The modular HTTP2 web server for productive full-stack development 開発環境で便利に使えるサーバで h

Introduction · AnyProxy Node.js で動く proxy で https を扱えて（証明書生成もできる）Web UI があってheader も body も全部 Node.js で書き換え可能なやつ。Mitmptoxy の Node.js 版と言えば分かる人は分かると思う。 でまぁ、そんな目新しい話はないんだけど、昔話と今回の狙いを残しておこうと思う。 かつてCocproxyがあったazu/node-cocproxy: Convention over Configuration Proxy written in Node.js. いろんなバージョンがある1が、基本的には ホスト名と同じ名前のディレクトリ、パスを掘ってあげてそこにコンテンツを置いておきproxy を起動しブラウザの通信にその proxy を利用するように設定以上を満たすと local に該

Wisembly/basil.js: The missing Javascript smart persistent layer 要件は以下の通り以下のプラットフォームの両方で動くこと Node.jsBrowser動作するストレージが以下に対応していること WebStorageCookieMemoryそれとここものすごく重要なんだけど namespace に対応していること。Cookie も WebStorage も Same Origin の中で様々なコードが勝手気ままにデータを読み書きするので、ちゃんと自分の namespace を守っていく必要がある。 Memory対応は重要なぜかというと Node.js には WebStorage も Cookie もないので、Node.js 上でテストを実行した際に死んでしまう。Memory で動けば少なくともロジックのテストは行える。もちろんよ

問題意識Rails の validation の基本は ActiveModel::Validations だが、Strong Parameters を別に書くのは二重化してしまう 部分 があるさらに API クライアントみたいな SPA みたいなものがあると三重化してしまうConditional Validation はやめたいRails内でvalidationをDRYにするdry-validation例えば Laravel には独立した Validator があるし、Hanami::Validations も独立している。 Validation - Laravel - The PHP Framework For Web Artisanshanami/validations: Validation mixin for Ruby objectsで、Hanami::Validations は

自分向けのダンプであって、後半にいくほど間違いが含まれる可能性が高まります。 イベントドリブンプログラミングとは処理の流れに関するプログラミングモデル。 書いた順番の通りに処理が流れるわけではなく、起きたイベントによって様々なところから動作が始まる。歴史としては別に新しいものではなく、メインループとシグナル、と呼んでもよい。様々な分野、時代で様々な呼び方、様々なテクニックがあるはず。（ちょっと追いきれません。悪しからず） 基本的な登場人物は Event ListenerEvent Handler( 結果の Value )くらいでよい。どのような Event の種類があるかは扱うプラットフォームによって変わる。 基本的には後発のものほど抽象度を上げるテクニックが増えていると考えればよい。 なぜイベントドリブンなのか人類には早すぎる問題 ( スレッド )プラットフォームの制約マルチスレッドで

すっげー初歩的な話。初歩的すぎて『Web API: The Good Parts』にもたぶん載ってない。 あと envelop の話はあえて無視してます。envelop を付けるべきか否かはこのエントリでは扱いません。あくまでデータの話に限定しています。 まとめ自分でお手軽に作る時に key-value のデータをそのまま返しちゃう場合があるけど、これはやめた方がよい。 つい

ざざっとメモ。当たり前ですが網羅はしてません。いわゆる After Rails な Web MVC を想定しています。紹介するコードは Ruby か PHP だけです。システムの規模などに依存しない内容です。悪しからず。 続くかどうかも分かりません。 まず基本のベストプラクティス1. 名前重要それを表す最もよい名前を探すこと。 よい名前が付けられない場合はそのことについて十分よく知っているとは言えない。よくない名前、嘘をついている名前1はそれを後から読んだ時に混乱を生み、理解を妨げ、変更時に問題の温床となる。 2. KISS ( Keep It Simple, Stupid )いろんな業界、いろんなシーンで言われるのでよく分かると思う。プログラミングにおいては 変数を多くしすぎないfunctionを長くしすぎない（classに対して）functionを多くしすぎないとかそんな意味で考えると

デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、

※ 独自ドメイン関係の話は一切ないです。あくまで公開できる状態になるまでで S3 Web Site Hosting と CloudFront の Origin の設定と Protocol の話のみです。 S3はWeb Site Hostingにすべし最近は AWS 側で不必要に S3 Bucket を公開してしまわないように Web UI でいろいろ警告してくれるというか分かりやすくしてくれていて、「もしかして S3 の Web Site Hosting って実は使ってほしくないのかな？」という雰囲気を感じていたんだけど、どうもそういう意図はないらしい。うっかりを防ぎたいだけっぽい。 というのも、 Web Site Hosting にしておかないと IndexDocument などの機能が効かないので / で終わる Directory へのアクセスは不可能 だから。 ※ 逆に、 / で終わ

あるいは Kanazawa.rb meetup #76 に行ってきたよ の話。 割といつも言ってることと同じなんだけど、まぁせっかくなので。 エンジニアが集まると なんでそんなものになってしまったのか？ みたいな話で割と盛り上がれるわけですよ。 それ要る!? みたいなやつ。 そういうのを避けるために自分は「インフラは持つべきではない、全部PaaSかフルマネージドにしろ」という選択を数年前にしたんだけど、最近は「バックオフィス業務で独自に開発はすべきでない、そもそも開発を外部に依頼するのは難しいし、独自に作らなきゃいけないものなんてほとんどない」と思っている。 で、これって、結局「余計な失敗をしない」ということなのだろうなぁと思っている。 何か作れば、何かやれば、それには失敗がつきものだ。避けようがない。そしてその失敗をなくすためには実はかなり大きな、時に測定不能なコストが発生する。 なぜか

Nginx 使うには使うけど細かい設定はしていない1 Rubyist が Nginx だけで何かをする場合の設定をどうしたかのメモ。予め断っておくと、本当に今さらで内容も全然ない話。 単に開発環境でWebサーバが欲しい場合はLLでよいはい。最初にものすごく身も蓋もないことを書くけど、Nginx を使う必要はない。むしろ準備に手間が掛かる。Python の SimpleHTTPServer とか Node.js の http-server とか、そんなんでいい。 動的にサーバサイドを書く？ Rackでいいでしょ。言語もWebサーバも選べない？ なるほど、頑張ろう。 Nginxはreverse proxyのために入れる単純な Web アプリのためにはそんなに proxy 必要ないけど、一つ一つのアプリをシンプルに保とうとするほど、proxy は便利に使える。ということで Nginx を使うとき

あるいは Kanazawa.rb meetup #74 - Kanazawarb に行ってきたよ。 最近 Google Cloud Key Management Service について調べていた。 というのも、Cloud Functions で小さいツールを業務的に扱うことがたぶん今後増えるので、サービスアカウントが増える、ということはこのアカウントのキー管理が増える、ということを予想していた。 結論から言うとこの二つのうち両方を勘違いしていたのだが、その過程で面白いことが分かったのでまとめておこうと思う。 Cloud KMSは自分の管理したい鍵を直接管理してくれるものではなかったCloud Key Management Service | Cloud KMS | Google Cloud Cloud KMS は確かに鍵を管理してくれるのだが、今自分が管理したいと思っている、すでに存在し

JavaScript で Promise はそこそこ扱えるようになったけど、 retry をどうするか曖昧なままだったのでちょっと整理する。 まずダメなやつ普通に同期的なコードの場合、やり方はいろいろあると思うけど、素朴にはこんな感じに書けると思う。 function s() { return Math.random() > 0.5 } let retry = 3 let result while ( retry > 0 ) { result = s() if ( result ) { break } else { retry-- } } console.log(result) 実際には retry 付きで呼ぶ function に閉じると思うけど、だいたいこんな感じかなーと思う。 で、Promise でもこれを元になんとかしてみようとすると、うまくいかない。s() を Promise を

ES2017のasync/awaitのキソ練習 - あーありがち(2018-05-26) のあとにがっつりハマっていたのでそこで得た知見をメモ。 asyncの効果は各functionブロックで切れるので逐一指定が必要例えば

ちまちま各論のメモは起こしてあるけど、ざっくり全体のメモがなかったので、自分が現時点で意識していることをまとめてみた。 Vue.jsのメリットSingle File Componentが標準で扱えるSingle File Component がすべての問題を解決するとは思っていないのだけれど、まず自分は jQuery 的な DOM 要素とそのイベント中心の書き方Unobstrusive JavaScriptの組み合わせは「操作」が「要素」と密結合しているにも関わらず、コードとしては非常に距離が遠く凝集度が低すぎると考えている。HTML と JavaScript の紐付けは class や ID で行うが、ページをまたいで影響させるのは難易度が高すぎる。またコードがイベント中心かつ操作中心になりすぎてしまい、抽象度が低すぎる。本当に考えるべき状態やロジックまで意識を到達させるのはとても難しい

背景先日から Vue (Nuxt) + Vuex + Vuex PersistedSate でモノを動かしてるんだけど、 なんかふいにデータが矛盾して動作がおかしくなる ことが起きていた。 まぁアタリはついていて、Nuxtでrouteに応じてVuex Storeをmodule分割する方法 - あーありがち(2018-04-19) にある動的に module 構造の Vuex Store を生成している処理と、 Vuex PersistedState を通じて localStorage からデータが返ってくる処理がそれぞれバラバラに動いていることで、「Vuex Store の値を見て判定する処理」がタイミング次第の微妙なシロモノになっているんだろうなぁと思ってたんだけど、決定的な解決策が見つからないでいた。 通常の使い方だと問題にならないけどテストしてるとよく踏み抜くので、ごまかしごまかしや

最近（2018-05現在）はライブラリで Promise 前提のものが増えてきてるしサンプルにもしれっと普通の顔で async/await が登場するので慣れておかないといけない。特に Node.js ではもう LTS である 8 （正確には 7 の途中）で標準的に使えるので、今後はもっと当たり前に登場してくる機会が増えてくることが予想される。1 ということで今回はasync/awaitの練習。ただし await の入れ子や Promise.all で束ねるといった複雑なことは扱っていない。 ※ Promise.all() の話は async/awaitやPromiseで気をつけること - あーありがち(2018-06-15) で！ またここで扱っているのはあくまで ES2017 の async/await であって他の独自に実装された async ライブラリのことでもないです。確認は素の

まとめNuxtは各種のサーバサイドフレームワークと組み合わせられるがNuxtだけでもサーバとして機能するデフォルトで ETag は吐くが Cache-Control は吐かないのでそのまま CDN に食わせるといつまでもリフレッシュされない この影響を受けるのはあくまで vue-router を経由する Page だけassets に関しては nuxt start で serve している場合は問答無用で max-age は 1 year になる1optional な http response header を追加する middleware はどうもなさげ 他のフレームワークと組み合わせてその middleware を使えば追加できる（Koa で確認済み）そもそもWebのcacheってprivate cache と public cache があるCDN は public cacheブラ

まとめVue で監視していたのは data ではなく setter を通ったかどうかだった そこは Backbone.js 時代から変わってなかったArray や Object の一部を書き換える処理は setter を通らないので Vue は検知できない逆に丸ごと壊せば setter を通すことはできるしかし恐らくその場合は書き換える DOM の範囲が広がり、VirtualDOM の速さのメリットがスポイルされるコンポーネントを小さくしろというのはそういう意味でもあった参考Vue.js 2.0 の算出プロパティ周辺のコードリーディング - kitak blogInternels Vue.js 算出プロパティはどうやって動いているかArrayの変更、Objectの変更はsetterを通らないので検知できないまぁ、分かってしまえば当たり前の話なんですけど、こういう感じのコードがあると思いねぇ

先日来 JavaScript の ViewModel 系フレームワークで監視対象外のデータをどう扱うかというところに注目しているのだけど、これには理由があって、 VM Component の単位で影響を閉じ込めるという発想はGood単方向のデータバインディング、データフローもGoodVM Component が UI を司るのでどうしても VM Component が Model を mount するという形になり、かつモダン JS の世界では Rails 的にすべての Model が global に展開されるという考え方は NGVM Component のどこかに Model を mount しつつ「すべてのデータを監視対象とするわけではない」という形が扱いやすそう Angular で Change Detection を打ち消しまくろうとするアプローチは「気にしたくないものを網羅する

あるいは Kanazawa.rb meetup #66 に参加してきました。 UiFlowsとは自分が知ったきっかけは誰かのツイート経由で 画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | UXデザイン会社Standardのブログ だったのですが、37 Signals ( Basecamp ) で A shorthand for designing UI flows – Signal v. Noise 採用されている（今もなのかな？）シンプルに 表示内容操作内容リンク先を記述する言語です。 「ツール」と紹介されることが多いみたいだけど、具体的なツールというよりは「記法」と表現した方がまだ近いかも。元のブログでは普通に手描きのものが紹介されています。（ただ、そもそも UI Flows って「名前」は存在しないような気がしませんか？） 元のブログは英語です

ずっとSSL証明書面倒くさいなーと思ってたんですよ。まぁ今だと Let' Encrypt とか Heroku もそうだけど無料で自動更新みたいなのはあるにはあるんだけど、伝統的なやつをもうちょっと効率化できないかなとずっと思っていたわけです。1 ありました。 cfsslを知るcloudflare/cfssl: CFSSL: Cloudflare's PKI and TLS toolkit cfssl を使ってるのを最近よく見ます。https://t.co/VgDlANo6gZ — Yuanying (@yuanying) January 5, 2018本当は openssl + expect ? とか openssl -config <template> ? みたいなことを考えていたんだけど、swiss army knife が見つかっちゃいました。 cfsslの使い方とっても簡単。 Cr

まとめAWS の Policy の種類が復習できたAWS の Policy 関連用語と Terraform 用語の Resource, Data Source 用語との紐付けができた静的サイト向けの Policy に集中して考えた操作から切り離して概念を整理しやすいのでドキュメントベースになるとありがたい。 AWS S3 の Bucket を読み書きできるポリシーとその適用方法が揺れていたこれまでに存在しているポリシーが以下のようなひどいことになっていた。 S3 の Bucket Policy で Role と Action を割り当てているものS3 の読み書きに特化した IAM User を作り、そのインラインポリシー ( IAM User Policy ) 側に Bucket ( arn ) 情報が書かれているものIAM User Policy Attachment ( 未適用 )図に

前回の heroku の import の続き。 まとめTerraforming は本当にすごい。超簡単。.tfstate だけでなく .tf も出力できるし、IAM の KEY さえあれば特に何も書かなくてよい。逆に terraform import はなかなか大変。（詳細は前回のterraform import heroku_appはできたけど…使い方が悩ましい参照。）import はまだおまけ的な感じで、terraform が正しく動作するために .tf を書き、これを validate すると required な option がボロボロ出てくる。対応サービスの数は Terraform の方が多いが、ものによっては Terraforming でしか対応できていなかったりするので、しばらくは両方知っておくのがよさそう。AWS Certificate Manager は承認のプロセス

先日初めて terraform import のために .tf を書いたが（このインキー感がすごく微妙）、当然何回かハマったのでその際に使ったものをメモとして残しておく。 まとめ.tf というか HCL ( HashiCorp Configuration Language ) がカギ HCL は JSON 完全互換で Terraform だけじゃなくて HashiCorp 製品を扱ううえで大事HCL の仕様はオープンなので実装はいくつかあるrepl が欲しければ gem も使えるもしかして独自のツールの設定文法を HCL にするのもアリかも？使ったものterraform plan && validate何はともあれコレ。 irb + rhcl複雑な構造を持つ variable や resource を扱う場合、HCL の書き方がよく分からなくなるので、ムカついて調べたら HCL の Rub

背景先日から flow でシコシコ type 付けをしていたが、新たに lodash を使おうと思ったら以下のようなエラーが出てしばらく悩んだ。 3: import _ from 'lodash/lodash.min' ^^^^^^^^^^^^^^^^^^^ lodash/lodash.min. Required module not found まとめ上のエラーは最小限の declaration を用意することでしのげるdeclaration はデフォルトでは flow-typed/ 以下に置く（これなら .flowconfig で設定不要）declaration は module_vx.x.x.js の名前で作れる lodash/lodash.min なら lodash.min_v4.x.x.js内容は以下の通り 実はlodashには定義済みのtype情報があるんだけど、lodash/

背景JavaScript はオブジェクトの構造とかコンパクトでプラットフォーム非依存な仕様など、面白いと思う反面、 が true になってしまうなど割とつらい仕様もあるので、大々的には入れたくないなぁと以前から感じていたのですが、ここ数年は JavaScript に型を入れるというのは AngularJS 2 の TypeScript 採用、Facebook の Flow など話題だし、ES2015 にはなんとかえっちらおっちら追いつけそうなので、いっちょ Flow でも試してみることにしました。 ※ 私は Ruby を使っていますが、Ruby の場合は型が欲しいと思うことはありませんでした。Ruby にも静的型はないじゃないかと思うかもしれませんが、上のような謎挙動はないので、全然意味が違うということは添えておきたいと思います。 実際のところは直接書いたコードではなく簡易DSLのようなナ