はてなブックマーク

小ネタです。 条件に該当するレコードが存在するかを確認したい ActiveRecordで条件に存在するレコードが存在するかを確認するのに、つい、 と書いてしまいがちですが、これはパフォーマンス上の問題が生じる可能性があります。 .present? は ActiveSupport によってモンキーパッチされたメソッドです。 Mode.where(conditions) のような ActiveRecord_Relation クラスのオブジェクトに .present? を適用するとどうなるか？ すると条件に該当するレコードを全てDBから取得して、（Rails上のモデルの）配列として評価することになります。 配列に要素が存在すれば true、 しなければ false ですね。 なぜこれはダメなのか 一見すると問題なさそうですし、実際結果自体は正しいのですが、条件に該当するレコードが1つでも存在する

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

小ネタです。 AxiosはBearer認証がめんどくさい axios でAPIを呼ぶときの認証にBearerトークンを指定する場合、下のような書き方をすると思いますが、 axios.get('https://api.example.com/api/v1/foo', { headers: { Authorization: `Bearer ${token}`, } })

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

開発サーバでソフトを動かすときにサーバ証明書が必要になるときってありますよね。 今話題のHTTP/2を試すにはSSL通信が必須だったりしますし。 もちろんOSやソフトについてくるサンプル用の証明書でもSSL通信はできるけど、証明書が検証エラーになるわけでブラウザの警告画面が鬱陶しいし、検証エラーを無視するための設定変更をする必要がある場合もあります。 かといって、わざわざ開発サーバのためにSSL証明書は買えないし…。 そんなときの救世主がLet's Encryptで、無料で正規のSSL証明書を発行してくれるありがたい存在です。 しかし、Let's EncryptでSSL証明書発行するためにはドメインがDNS登録されている必要がありますので、社内（組織、自宅）内の内部で使ってる"abc.localdomain"みたいなドメインには対応してません。 結局、自前でLocal CAを運営する必要が

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

我ながら意味不明なタイトルだ（笑） 解決したい問題 多数のサーバやサービスがある。 環境ごとの設定（db名や接続ユーザ、パスワードなど）が各サービス（リポジトリ）ごとに保存されている。 設定内容がバラバラに保存されてしまう。 時に設定値が二重管理どころか多重管理になってしまう。 設定値をリポジトリに保存するときに暗号化しないといけない。 差分管理ができず、デプロイプロセスが複雑化してしまう。 特にマイクロサービスアーキテクチャを採用している場合は、設定値が分散しがちなのでこれを何とかします。 解決方法 設定情報を一元管理する。 外部からアクセスできないローカルに設定専用gitサーバを立てて、そこのリポジトリに設定情報をplainで保存。 これで機密性と差分更新を両立。 環境ごとにetcdを立てる。 設定値をこのetcdに投入する。 本番環境のetcdはクラスタリングで冗長化。 各サーバには

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ローカルPCに個人開発環境を建てたいけど、母艦は汚したくないものです。 そうすると、だいたいの場合vagrant(virtualbox)かdockerかの2択になると思います。 この使い分けにいつも迷うのでどうするべきかの指針を考えてみました。 お断り: 以下は個人の見解であって、所属先の見解ではありません。 vagrant カーネルに依存する操作を行いたい場合 dockerの場合、いじれるカーネルパラメータが限られています。 特定バージョンのカーネルの環境を用意する必要がある場合や、カーネルパラメータに特殊な設定が必要な環境では仮想マ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

お断り: この記事の内容は、所属先の見解ではありません。 わりと何でもありのPHP界隈ですが、長年その状態を放置してきたため様々なスタイルのコードが存在することになり、PEARのようにまともにメンテナンスされてないコードを生み出してしましました。 さすがに何かしらの標準が必要では？　ということで、PHP-FIGという組織がPHPに関するコーディングスタイル、autoload仕様、インターフェイス仕様を決めており、事実上の標準になっています。 PHP-FIG発足とほぼ同時に制定されたPSR-1, PSR-2はコーディングスタイルに関する標準で、PSR-1が基本的な内容、PSR-2がそれに追加してカッコの位置、スペースの入れ方、インデントのとりかたなど細かい内容になっています。 PSR-1は誰でも割りと受け入れられやすい内容だとは思いますが、PSR-2はコーディングスタイルに深く踏み込んでるの

APIサーバの動作確認をどうやるか。それが問題だ。 APIサーバ全盛期のサーバサイドですが、RESTベースのAPIサーバとなるとブラウザからでは動作確認が面倒です。 そこで何か良いツールは無いかな？　と思ったらInsomniaというツールを見つけました。 有償プランもあるツールですが、無償で使える範囲でも十分便利に使えます。 注意: InsomniaXという別のツールがありますが、これは全く違うツールです。 起動 起動するとこんな感じの画面が出ます。 一番左が保存したAPIリクエストや環境設定、真ん中がリクエスト内容、右がレスポンス結果です。 真ん中の部分で送信するURLとメソッド、パラメータ・ヘッダ内容を選択して"Send"ボタンを押すと、結果が右側に表示されます。 さて、ここまでは類似のツールでもよくあることです。 ここでInsomniaにある便利な機能をご紹介。 environmen

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Webフォームのバリデーションをするのって面倒ですよね。どうせサーバサイドでバリデーションするのに…。 といいつつも、利用者を苛つかせないためにも、無駄な通信を減らすためにもフロントサイドのバリデーションは重要です。 何か良いライブラリが無いかなと思ってgithubを漁っていたら、良さげなライブラリを見つけました。 validatorjs "A data validation library in JavaScript for the browser and Node.js, inspired by Laravel's Validator."とあるとおり、LaravelのValidatorに似た感じになっているのが特徴です。 Laravelといえば、JSはreact.jsではなくてvue.jsだろうということで、Vueのコンポーネントでのサンプルです。(CSSはBootstrap) もちろ

Webアプリケーションの認証トークン（セッション）はCookieヘッダで送信するのが一般的だとは思いますが、 そろそろこのCookieに依存した方法は負の遺産ではないでしょうか？ 認証トークンの送信はRFC 7235で規定されているAuthorizationヘッダを使うと良いです。Basic認証とかDigest認証で使うやつですね。 実はBasicやDigestの他にRFC 6750でBearerというスキームが登録されています。単一の文字列を認証情報として送信するためのスキームで、トークンを送信するのにピッタリです。 参考: トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた その場合は、認証トークンはCookieではなくlocalStrage（またはsessionStorage）に保存することになると思います。

タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！　という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio

プログラムの開発中はエラー発生の連続なものですが、特に開発の初期にはログ出力部分が未整備で、必要な情報が記憶されてなかったりするものです。 こんなときクラッシュレポートサービスを使うと、ほんの少しの手間でエラーが発生したら自動的に情報をクラッシュレポートサーバに転送してくれるようになります。 後はブラウザからその時のパラメータ、スタックトレースなどの情報を見ることができるようになります。 有名なクラッシュレポートサービスとしてはAirbrakeがありますが、有料サービスなので気軽に試してみることができません。 実はErrbitというAirbrake互換のオープンソースプロジェクトがあります。 Airbrake互換ということは、クライアントプログラムに仕込むプラグインがAirbrakeのものが使えるということです。 Errbitのインストール Errbitはrubyで書かれています。 特にパ

Docker便利ですね。 仮想マシンを立ち上げるまで大袈裟ではないけど、母艦のマシンを汚したくないときはDockerでコンテナを立ち上げると便利です。 Dockerを使うにはイメージが必要なわけで、デフォルトではDockerfileでプロビジョニングするわけですが、せっかくなら最近のトレンドである専用ツールであるAnsibleを使ってプロビジョニングしたいものです。（playbookの共有ができますし。） VagrantでおなじみのhashicorpからリリースされているPackerを使うと、それができます。 Pakcerとは？ Packerは仮想コンテナで使用されるイメージ作成に特化した自動実行ツールです。 Dockerだけではなく、 EC2 (AMI) Azre DigitalOcan Docker Google Compute Engine OpenStack Parallels Q