【Zenn で十冊目となる本を公開 🎉】 本書籍では、HTML・CSS・JavaScript の基礎を学びながら、魅力的なポートフォリオサイトを作成します。 13 万字を超える大ボリュームとなっています。 一週間「無料」で公開します。ぜひご覧ください。 zenn.dev/farstep/books/creat…

「なぜドメイン駆動設計が重要か」 上記の問いの答えが、このスライドで示されている。 スライドには下記のように記されていた。 「ドメイン駆動設計の重要性は、ビジネス競争力の維持・向上と密接に関連している」 ・競合他社に勝つために、独自の機能や利便性を追求する必要がある ・仮説検証のために、システム仕様を迅速に変更する必要がある ・ドメインレイヤー（システム仕様を担う層）を素早く変更できる設計が求められる 他にもドメイン駆動設計の本質的な話が多くあり、非常に勉強になった。 speakerdeck.com/pospome/lian…

バックエンドエンジニアの技術面接で必ずと言って良いほど聞かれる質問「リレーショナル DB と非リレーショナル DB の違い」について、十個の項目で比較しました。 それぞれの項目について、詳しく解説します。 1. データモデル リレーショナルデータベースは表形式のデータモデルを使用し、行と列で構成される。一方、非リレーショナルデータベースは多様なデータモデルを採用している。文書指向、キーバリュー、ワイドカラム、グラフなど、さまざまな形式でデータを格納できる。この違いにより、非リレーショナルデータベースは多様なデータ型や構造に対応できる柔軟性を持つ。 2. スキーマ リレーショナルデータベースは事前に定義された固定的なスキーマを要求する。これに対し、非リレーショナルデータベースはスキーマレスまたは柔軟なスキーマを採用している。非リレーショナルデータベースでは、同じデータベース内で異なるデータ構造を許容し、開発の迅速化や要件の変更に対応しやすい特徴がある。 3. スケーラビリティ リレーショナルデータベースは主に垂直方向のスケーリング（より強力なハードウェアの使用）に依存する。非リレーショナルデータベースは水平方向のスケーラビリティを重視しており、ノードを追加することで容易にスケールアウトできる。この特性により、非リレーショナルデータベースは大規模データや高トラフィックに対応しやすい。 4. クエリ言語 リレーショナルデータベースは標準化された SQL を使用してデータの定義や操作を行う。一方、非リレーショナルデータベースには標準的なクエリ言語がなく、データベースの種類によって異なるクエリ方法を採用している。この違いは、開発者の学習曲線や異なるデータベース間の互換性に影響を与える可能性がある。 5. データ整合性 リレーショナルデータベースは ACID（原子性、一貫性、分離性、耐久性）特性に準拠し、強力なデータ整合性を保証する。非リレーショナルデータベースは多くの場合、CAP 定理に基づく結果整合性モデルを採用している。これにより、非リレーショナルデータベースは可用性と分断耐性を重視するが、即時的な一貫性が要求される場合には課題となる可能性がある。 6. トランザクション リレーショナルデータベースは複雑なトランザクションや複数レコードの更新を必要とする操作に適している。非リレーショナルデータベースは比較的単純なトランザクションに適しているが、複雑なトランザクションの管理は課題となる場合がある。 7. 大規模データ リレーショナルデータベースは構造化データの大量処理に効率的だが、非常に大規模なデータセットになると複雑化し効率が低下する可能性がある。非リレーショナルデータベースは非構造化や半構造化データを含む大量のデータ処理に優れており、ビッグデータ分析などに適している。 8. 柔軟性 リレーショナルデータベースはスキーマの変更が複雑で破壊的になる可能性があり、柔軟性に制約がある。非リレーショナルデータベースはデータモデルやスキーマの変更に対して高い柔軟性を持ち、急速に進化するデータ要件に対応しやすい。 9. 関係性 リレーショナルデータベースは外部キーと結合操作を通じてデータ間の関係性を効果的に管理できる。非リレーショナルデータベースはデータ関係の管理に本質的に適していないため、複雑な関係性のモデル化には追加の複雑さが伴う可能性がある。 10. 用途 リレーショナルデータベースは明確な関係性を持つ構造化データ、複雑なクエリや高いデータ整合性を要求するアプリケーションに適している。非リレーショナルデータベースは大規模データ、リアルタイムウェブアプリケーション、急速に変化するデータ要件を持つアプリケーションに適している。 これらの違いを理解することで、特定のプロジェクトやアプリケーションに最適なデータベース選択が可能となります。

エンジニアの技術面接で聞かれる「OS の役割」について、言語化しました。 最低限下記を知っていれば良さそうです。 OS とは、コンピュータシステムの基盤となるソフトウェアで、以下のような役割を果たす。 1. ハードウェア抽象化 OS はコンピュータのハードウェアコンポーネント（CPU、メモリ、ストレージデバイスなど）を抽象化し、アプリケーションから直接アクセスできないようにする。代わりに、OS は標準化されたインターフェース（システムコール）を提供し、アプリケーションがハードウェアリソースを間接的に利用できるようにする。 2. リソース管理 OS はシステムリソース（CPU 時間、メモリ、ストレージ、ネットワーク帯域など）を管理し、複数のプロセス間で公平に分配する。これにより、システムの安定性と効率性を確保する。 3. プロセス管理 OS はプロセス（実行中のプログラム）の作成、スケジューリング、終了を管理する。複数のプロセスを同時に実行させ、CPU の使用を効率的に制御する。 4. メモリ管理 OS はシステムメモリを管理し、各プロセスにメモリ領域を割り当てる。また、仮想メモリ技術を使用して物理メモリを拡張し、多くのプロセスを同時に実行できるようにする。 5. ファイルシステム管理 OS はファイルシステムを提供し、データの保存、取得、管理を行う。ファイルやディレクトリの構造化、アクセス制御、データの永続性を確保する。 6. デバイスドライバ管理 OS は様々なハードウェアデバイス（キーボード、マウス、ディスプレイ、プリンタなど）とのインターフェースを提供し、これらのデバイスを制御するためのドライバを管理する。 7. ネットワーク管理 OS はネットワークプロトコルスタックを実装し、アプリケーションがネットワーク通信を行えるようにする。また、ネットワークインターフェースの設定や管理も行う。 8. セキュリティ管理 OS はユーザ認証、アクセス制御、暗号化などのセキュリティ機能を提供し、システムとデータを保護する。 9. ユーザインターフェース 多くの OS はグラフィカルユーザインターフェース（GUI）やコマンドラインインターフェース（CLI）を提供し、ユーザがシステムと対話できるようにする。 10. システムサービス OS は様々なシステムサービス（時刻管理、ログ記録、バックアップなど）を提供し、システムの円滑な運用をサポートする。 11. アプリケーション実行環境 OS はアプリケーションの実行に必要な環境（ライブラリ、ランタイム）を提供し、アプリケーションの互換性を確保する。 12. エラー処理と回復 OS はハードウェアやソフトウェアの障害を検出し、可能な限り回復を試みる。また、エラーログを記録し、トラブルシューティングに役立てる。 これらの機能により、OS はハードウェアとソフトウェアの間の複雑さを隠蔽し、開発者がアプリケーションの核となる機能に集中できるようにする。また、ユーザに対しては一貫性のある操作環境を提供し、コンピュータシステムの利用を容易にする役割を果たす。

現役バックエンドエンジニアが最近読んで良かった技術書を紹介。 【良かったの定義】 ・特定の言語やフレームワークに依存しない、普遍的な知識を提供している ・理論だけでなく、実践的な例やケーススタディが充実している ・最新の技術トレンドを反映している #駆け出しエンジニアと繋がりたい

「プロダクトの価値を最大化するエンジニアの思考と行動」が詳細に解説されている良い資料を見つけたので、構造的にまとめました。 これらを常に意識してプロダクト開発を行いたい。 資料. speakerdeck.com/happy_imafuk…

新卒の技術面接でも聞かれる「Dockerを使うメリット」について、言語化しました。 最低限下記を知っていれば良さそうです。 ① アプリケーションのデプロイプロセスが簡素化される 🚀 従来は、アプリケーションを新しいサーバーにデプロイする際、OS やミドルウェア（アプリケーションの実行に必要な他のソフトウェア）のインストール、各種設定、ライブラリのバージョン管理など、多くの手順と時間が必要でした。特に、開発環境と本番環境で使用する OS やミドルウェアのバージョンが異なると、「開発環境では動くのに本番環境で動かない」といった問題が起きやすく、環境差異の調整に多大な工数がかかっていました。 一方、Docker を使うと、アプリケーションとその実行に必要なライブラリ等すべてをコンテナにまとめてパッケージングできます。 このコンテナを本番環境にデプロイすれば、OS やミドルウェアのインストール、設定は最小限で済みます。 コンテナには動作に必要なものがすべて含まれているので、開発環境とまったく同じ環境をサーバー上に簡単に再現できます。 Docker コンテナなら、サーバーに Docker エンジンさえインストールしておけば、そのサーバー OS に関わらず、どこでも同じように動かすことができます。コンテナを使ったデプロイなら、環境差異に悩まされることなく、開発者はアプリケーション開発に、運用担当者はサーバーの管理に集中できます。 ② 従来の仮想マシン（VM）に比べてとても軽量 🪶 VM は、アプリケーションごとにゲスト OS を含む仮想マシンを構築するので、各 VM のサイズが大きくなり、起動や終了に時間がかかります。 一方、Docker コンテナは、ホストマシンのカーネルを共有し、必要最小限のライブラリしか含まないため、サイズが小さく、起動や終了にかかる時間が短縮されます。 この軽量性と高速さのおかげで、開発中のアプリケーションを何度も動かしてすぐに確認したり、一台のマシンに大量のコンテナを立ち上げてスケールするといったことが可能になります。 ③ 開発チーム内で開発環境を統一することができる 🤝 プロジェクトに参加する開発者それぞれの PC 環境は、OS やインストール済みのソフトウェアが異なることが多く、環境差異から生じるバグなどが問題になりがちです。 「私のマシンでは動くのに、他の人のマシンでは動かない」といった事態は珍しくありません。 Docker であれば、Dockerfile というテキストファイルに環境構築手順を書いておくだけで、どの開発者のマシンでも、Dockerfile から完全に同一の開発環境をコンテナとして構築できます。 しかも、そのコンテナ環境をチーム内で共有することで、バージョン管理システム（Git 等）で管理できるので、環境の再現性が格段に向上します。 開発環境の統一により、環境差異から生じるバグが減り、開発者同士のコミュニケーションも円滑になります。 メンバーが入れ替わっても、新メンバーはすぐに同じ環境をマシンに構築できるので、チームとしての生産性を高く保つことができます。 以上のように、Docker には、デプロイの簡素化、軽量性、開発環境の統一など大きなメリットがあり、開発から運用までのソフトウェアライフサイクル全体を効率化できる優れたツールだと言えます。