データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)
これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
"OpenID Connectは認可のための仕組みであるOAuth 2.0を認証のために拡張したもの" という表現が気になったが実は... - r-weblife
ritouです。 あることがきっかけで、これが気になりました。 10年間で熟成されてしまった感のある「OIDCはOAuth 2.0を"認証もできる(認証用途に利用できる)ように"拡張した」っていう表現だが、プロトコルの解説にあたってもその流れでやられるとモヤるところがあるのでなんとかしておくべきだったのかもしれない。— 👹秋田の猫🐱 (@ritou) 2024年2月1日 この表現、検索するとたくさん出てくるんです。 仕様策定の時期 OIDC Core 1.0にある "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol." という記述の解釈 というあたりからこのような表現になっているのでしょう。 ただ、この前提でプロトコル自体を解説、理解しようとすると何かうまくいかないところがあるの
フロントエンドで収集するべきテレメトリは何か
先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした（※本記事は上記記事の内容を知らなくても読み進められるようになっています）。 というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。 重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。 一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。 そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。 監視 SaaS と OpenTelemetry (OTel) Datadog, New Relic, Sentry のいずれかを利用することを考え
フロントエンド監視の全体像と実現方法
必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント
VMwareが「ESXi無償版」の提供を終了 移行先の有力候補は？
VMware（Broadcom）は2024年2月12日（現地時間）、「End Of General Availability of the free vSphere Hypervisor（ESXi 7.x and 8.x）（2107518）」（注1）で、「VMware vSphere Hypervisor」（ESXi 7.xおよびESXi 8.x）（以下、VMware ESXi）の提供を終えたことを発表した。永久ライセンス終了に伴って無償版である「ESXi Hypervisor」の提供も終了するとしている。 VMware ESXiのユーザーには中小企業や個人が多く、提供終了によって大きな影響が出るとみられる。サブスクリプションプランへの移行というVMwareの方針は、仮想化技術の使用方法や業界のエコシステム（生態系）に長期的な影響を及ぼす可能性もある。 VMwareは2023年12月、同社
富士通、NEC、NTTデータの最新受注から探る「2024年国内IT需要の行方」
DX（デジタルトランスフォーメーション）や基幹システムのモダナイゼーション、さらには生成AIブームで活気づいた2023年の国内IT需要。2024年はどう動くか。富士通やNEC、NTTデータグループ（国内事業会社は「NTTデータ」）のITサービス大手3社が相次いで発表した2023年度（2024年3月期）第3四半期（2023年10～12月）の決算から需要動向の先行指標となる受注状況に着目して見通しを探る。 「受注残高も高水準で積み上がっている」（富士通） 富士通が2024年1月31日に発表したITサービスにおける第3四半期の国内受注状況は、全体で前年度同期比115％、第1四半期からの9カ月累計（2023年4～12月）で同116％と大きく伸長した。 業種別の動向は、次の通りだ（表1）。
Node.jsから呼び出したWASMバイナリ（Rust製）と非同期に通信したい話
どうもこんにちは。筆者はここ1年くらいnitrogqlというTypeScript + GraphQL向けコード生成ツールを開発しています。（初手宣伝） このツールの本体はRustで書かれており、コンパイルするとWASMバイナリが生成されます。このWASMバイナリをNode.jsから呼び出すようなラッパーを作って、コマンドラインツールとしてnpmで公開しています。 その性質上、Node.js側とWASM側で通信（データのやり取り）が発生します。特に、設定ファイルなどが.jsや.tsで書かれていても読み込む機能があり、その際はRust側からNode.js側に制御を渡してNode.js側でファイルを読み込み、結果をRust側に返すようになっています。 実は、nitrogqlの（Rust側）コードにはこれまで非同期処理が含まれていませんでした。しかし、パフォーマンスのことなどを考えると非同期処理に
デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが） - mtx2s’s blog
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment（DORA）が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した（後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である）。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
