DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog
Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
スラド終了のお知らせ | スラド
皆さんに長年ご愛顧いただいたスラドだが、残念ながらこの度終了する運びとなった。 アピリッツが OSDN を OSChina へ譲渡する際、スラドを分離して別の受け入れ先へ譲渡する対応をお願いしていたが、対応が進まないまま時が過ぎていたようだ。最近になって OSChina からスラドと OSDN を閉鎖する計画があると聞いた編集部が交渉したところ、分離してかまわないとの回答を得たのだが、日本側受け入れ先の都合が悪く、分離計画は頓挫してしまった。 スラドはしばらく更新を続けるが、1 月末にはサービスを停止する。データを保存したい方は早めに進めてほしい。
Rails で結合先のテーブルで条件つけたいけど結合元のレコードは全部欲しいってときは Scoped Association
プレーヤーがいないチーム C も一覧に表示されているのがポイントです。 以上の設定が、「結合先のプレーヤーテーブルにおいて論理削除されていないという条件をつけたいけど、チームのレコードは全部欲しい」という状況になっているのがお分かりいただけるでしょうか。 どうクエリメソッドを書けばよいか？ まずパッと思いつくもの 例えばこんなのはどうでしょうかね。 Team.eager_load(:players).where(players: {deleted: false}) すると以下のようなSQLが発行されます。 SELECT "teams"."id" AS t0_r0, "teams"."name" AS t0_r1, "teams"."created_at" AS t0_r2, "teams"."updated_at" AS t0_r3, "players"."id" AS t1_r0, "p
Immutable.jsとImmer、ちゃんと使い分けていますか？
昨今のフロントエンド開発では、データをイミュータブルなオブジェクトとして扱うのが主流です。すなはち、データが変わるときはオブジェクトを書き換えるのではなく、新しいデータを持った新しいオブジェクトを作ります。最近ではオブジェクトがデータとしてプログラムのあちこちで取り回されることが増えて、一度余所に渡されたデータの中身が後から変更されるのは混乱をきたし設計が困難になるというのが主な理由です。 データを変更するたびに新しいオブジェクトを作るのは、特にデータが複雑になったりネストしたりしていると面倒だしプログラムの見通しが悪くなります。そこで使われるのが、データをイミュータブルに扱うためのライブラリであるImmutable.jsとImmerです。 データをイミュータブルなものとして扱うという目的はどちらのライブラリでも達成することができますが、現在では Immer のほうが開発が活発であり、独自
Immutable (イミュータブル) - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
イミュータブル（不変）オブジェクトとは、内容を変更できないオブジェクトのことです。 オブジェクトは、さまざまな理由でイミュータブルである可能性があります。 例えば次のような理由です。 パフォーマンス向上のため（オブジェクトの将来の変更を計画しない） メモリ使用量を減らすため（オブジェクト全体を複製するのではなくオブジェクト参照 を行う） スレッドセーフにするため（複数のスレッドは互いに干渉することなく同じオブジェクトを参照できます）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ActiveRecord Scoped Association - ohbarye
Upcase : Querying with Custom Joins | Online Video Tutorial by thoughtbot