はじめに OpenID Connect は OAuth 2.0 を拡張する形で策定されました。 OAuth 2.0 はアクセストークン発行手順に関する仕様で、**RFC 6749（The OAuth 2.0 Authorization Framework）**で定義されています（参考：一番分かりやすい OAuth の説明）。 一方、OpenID Connect は ID トークン発行手順に関する仕様で、主要部分は OpenID Connect Core 1.0 で定義されています（参考：一番分かりやすい OpenID Connect の説明）。 RFC 6749 は**認可エンドポイント**という Web API を定義しています。 この API は必須のリクエストパラメーターとして response_type を要求します。 OpenID Connect は、この response_ty
AWS を利用して静的な Web コンテンツを配信する方法として CloudFront + S3 の構成をよくとります。 構成方法は開発ガイド「安全な静的ウェブサイトの使用開始」や 巷の記事 が参考になります。 CloudFront のポテンシャルを十分に引き出すために、S3オリジンのキャッシュを存分に利かせて「爆速だー！ヒャッハー！」しようとしたら・・・ S3 に置いたファイルを上書きしても直ぐに反映してくれない。 ﾏｼﾞﾃﾞｽｶ… トラップカードの存在に気づきます。 とりあえず反映する方法 手作業で済む範囲で、すぐにキャッシュを更新したい場合は大まかに2通り。 キャッシュを無効にする CloudFront のビヘイビア設定にあるキャッシュポリシーを無効(Managed-CachingDisabled)に変更する方法です。まごうことなき急しのぎな回避策です。 応答パフォーマンスは確実に落
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
先日、Claude Code（コーディング用のAIエージェント）1を使って作ったiOSアプリ 『電光石火』 をリリースしました。 『電光石火』は、「九九」や英語の「代名詞」、「県庁所在地」など、反復練習ですばやく答えられるようになるべきものを、ゲーム形式で手軽に身につけられるiOSアプリです。「たしざん」「ひきざん」「L / Rの聞き分け」「炎色反応」「東西南北」など、定番のものから少し変わったものまで、様々なコンテンツを提供しています。 たとえば、小学1年生は毎日宿題でリングカード等を使って足し算の練習をしますが、『電光石火』を使えば、それをゲーム感覚で楽しく行うことができます。 AIエージェントを使ってコードを書いた話はたくさん耳にしますが、実際にプロダクトをリリースするところまで行った体験談は少ないと思います。 この記事では、AIエージェントを使って『電光石火』を開発・リリースしたこ
本記事はエムスリー Advent Calendar 2020 の9日目の記事です。 エムスリーエンジニアリンググループの木村です。 今回は今年遭遇したエラーの中で面白かったPostgreSQLのターゲット上限値エラーの話をします。 我々のチームで開発・運用しているアンケートシステムではデータベースにCloudSQL(PostgreSQL)を利用しています。 アンケートシステムでは、ユーザのアンケートの回答を集計するために様々なクエリを駆使します。 その時、発行しようとしたクエリは下記のような結果を得るものでした。 クエリ結果 具体的なクエリは以下のようなものになります(あくまでイメージ。実際はもう少し複雑です)。 SELECT user_id , question1_answer , question2_answer , question3_answer , (略) FROM user u
この表に記載した項目のうち今回は「記録データ」に注目します。 「記録するデータ」での制御とは 記録するデータによる制御とは、ここでは「ホストから受領したライトコマンドの書き込みデータをSLCキャッシュに記録するかどうかの制御」を指すこととします。例えば「このライトコマンドはデータサイズが小さいからSLCキャッシュに書こう」のような制御です。 SSDが対応するインターフェース（SATAやNVMeなど）において、ホストから受領するライトコマンドに付随する代表的な情報は以下のものです。 ライトするデータのアドレス(LBA) ライトするデータのサイズ（セクタ数） 不揮発メディアにデータを書いた時点でコマンド完了とするか ライトするデータの属性 このうち、3つめの「不揮発メディアにデータを書いた時点でコマンド完了とするか」という情報のみ他のものとは種類が異なります。このためSSDの内部処理に与える影
今回の記事では、上記の表に記載した項目のうち「容量」について、方式の内容とSLCキャッシュを上手く使う方法をまとめます。 SLCキャッシュの容量制御方式 SLCキャッシュの容量の制御方式には主に静的方式と動的方式があります。 静的方式は、例えばOver Provisioning (OP)から一定のサイズを常に（＝静的に）SLCキャッシュに割り当てる方式です（図1）。OPはあくまで余剰領域ですので（別記事参照）、容量をあまり大きくできません。 図1：容量静的方式のSLCキャッシュ（動作イメージ） SLCキャッシュにデータを記録していき容量分たまると（図1 (1)から(3)まで）、データの追い出しを実行してSLCキャッシュの空きを作ります（図1 (4)）。追い出されたデータは多値記録で記録されます。 この図1のSSDが搭載するNANDフラッシュメモリをTLC NANDだと仮定し、SLCキャッシ
Cloud Native Kubernetes management and cloud-native solutions
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この投稿について 前半でIPレピュテーションとは何か？という説明をしていますので、未読の方は一読することをお勧めします。 メールというインターネットの闇とIPレピュテーション（だけど重要）(前編) https://qiita.com/nfujita55a/items/5848fcfbbe6cbf7d98c3 この後半では、IPレピュテーションをよくしてメールを滞りなく送りたいときの光要素と闇要素を、光→闇の順に書いています。 メールを円滑に送るためIPレピュテーションを高めたい、何ができるの（光要素） まずは、IPレピュテーションを含
メールというインターネットの闇 ※この文書では メール＝e-mail です メールというと哀れみの目線がエンジニアからとんでくる昨今 わたしのお仕事の半分以上はメール関連なのですが、ITなエンジニアの集まりで「メールのお仕事してます」というと うわ、レガシーな領域の人なんだ！ メールってまだ仕事になるの？ スパム屋さんかな？ と、マイナスというか哀れみな目線をいただくことがあります。 大きな本屋さんに行ってみると分かるのですが（例えば、丸の内オアゾの丸善さんとか）、メールの書き方など仕事でメールをどう活かすかみたいな本はありますが、システム的な見地の送受信に関する本は、ここ5年出版されていません。 たぶん、Postfix実践入門(2010/9/3発売)が一番新しい思います。 https://www.amazon.co.jp/Postfix%E5%AE%9F%E8%B7%B5%E5%85%A
メールの世界にGmailさんが新たな闇を投入 (インターネットの)メール受信・送信は闇あふれる世界だと思うのですが(*1)、そこに 2023年10月7日、新たな闇要素をGmailさんが投げ込んでくれました。（正しくは2023/12月頭現在、闇がモリモリ増えてる。補足①②参照） (*2 最下部キャプチャあり) えーと、「1日あたり 5,000 件を超えるメールを送信する送信者」はこの事項を守ってね……とあります。要件と書いてあり、2024/2/1から実施と急なうえに、項目が SPFとDKIMの設定 逆引き 迷惑メール率 メール形式 Gmail の From: ヘッダーのなりすまし ARC DMARC ダイレクトメールの場合(……なんとかかんとか) 登録解除 と9個もある。 何これ……？と様々な人を戸惑わせています。 インターネットにつながっているそこそこの規模の組織は、1日あたり 5,000
PostgreSQLのパーティショニング機能には、パーティション数が多いほど親パーティションに対するクエリのプラン生成時間が長くなる問題がある。これは、PostgreSQL10のネイティブ・パーティショニング機能でも従来のパーティショニング機能でも同様である。 今回は以下5パターンにおけるクエリのプラン生成時間を比較して、パーティション数が多いほどプラン生成時間が長くなることを確認する。 パーティション分割しない 10パーティションに分割 100パーティションに分割 500パーティションに分割 1000パーティションに分割 PostgreSQL10のネイティブ・パーティショニングの場合 -- 指定の数だけ分割されたパーティションを作成する関数を登録する CREATE OR REPLACE FUNCTION create_partition_native ( parent TEXT, num
技術評論社は5月1日、技術情報誌「WEB+DB PRESS」について、2023年8月発売の「Vol.136」をもって休刊すると発表した。 WEB+DB PRESSは2000年に刊行されたWebアプリケーション向けプログラミング技術情報誌。休刊の理由として「物価上昇による製作費の高騰など諸般の事情」と説明。「22年以上の長きにわたり、絶大なご支援をいただきましたことを、厚く御礼申し上げます」としている。 同誌が扱っていた分野のコンテンツについては、今後も技術評論社が刊行する「Software Design」や「gihyo.jp」、書籍などで提供していく。また、今回の休刊は隔月刊誌としてであり、必要な場合には「特別号」の編集・刊行なども検討していくという。 関連記事 「日本カメラ」休刊 会社も解散、73年の歴史に幕 日本カメラ社（東京都中央区）は4月15日、月刊のカメラ雑誌「日本カメラ」を20
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで齋藤氏と尾野氏が、「LINEデータプラットフォームにおけるApache Icebergの導入」というテーマで、データ処理とデータのインジェスチョンパイプラインについて共有しました。ここからは、データのインジェスチョンパイプラインにおける課題と、解決に向けた取り組みについて。前回はこちらから。 自己紹介と後半のアジェンダ尾野健氏：ここからはスピーカーが代わります。尾野健と言います。Data Engineering1 teamに所属していて、LINEには2019年に入社しました。現在はインジェスチョンパイプラインを開発中です。 後半のアジェンダです。現在のログパイプラインの概要、そのログパイプラインが抱える問題、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く