SCSKの畑です。 前回の投稿 に引き続き、3回目として非同期処理部分のフロントエンド実装についてピックアップして説明していきます。 フロントエンドにおける非同期処理実装の方針について まず前提として、同期処理で実装していた部分を非同期処理に変更しても、画面の遷移/見せ方自体は基本的に同期処理時と同一にする必要があります。例えば、テーブルデータの取得処理を非同期にただ変更するだけだと、データ取得が完了しない内にテーブルデータの表示画面に遷移してしまうため、単純に想像すると取得が完了するまで空の表が表示され

SCSKの畑です。 前回の投稿 に引き続き、今回は非同期処理部分のバックエンド実装についてピックアップして説明していきます。 バックエンドにおける非同期処理実装の方針について 前回の投稿で説明した通り、密結合・同期処理前提の実装を、疎結合・非同期処理前提の実装に変更する必要がありました。この内、密結合を疎結合に変更する過程については、非同期処理として分割すべき処理単位を頑張って中身を見ながら分割していく・・くらいしか極論書くことがないので割愛します。 一方、非同期処理への変更については処理ロジックそのもの

SCSKの畑です。期せずして昨年と同じく年明けからの投稿となりますがよろしくお願いします。 まずは昨年度の投稿で主に言及していた Redshift データメンテナンス用の Web アプリケーションについて、今年度も引き続き携わっている中で主に実施していた取り組みについて数回に渡って記載していきたいと思います。 アーキテクチャ概要 一年ぶりの投稿となるので載せておきます。今回はアーキテクチャの変更や改修を伴う内容ではないのですが、AppSync や Lambda が関連する話題となります。要するにバックエン

分散型金融 (DeFi) の取引判断には、ブロックチェーンの価格と流動性データが必要です。 しかし、ブロックチェーンノードへの直接クエリは非効率的でリソースを大量に消費するため、タイムリーな意思決定のボトルネックとなります。 ブロックチェーンは効率的なデータクエリに最適化されておらず、データは順次 (ブロックごとに) 保存されています。 特定の情報を取得するには、多くの場合、ブロックチェーン全体をスキャンする必要があります。 インデクサーは、この問題に対するソリューションを提供します。 インデクサーは新し

はじめに こんにちは、久保です。 AWSではBedrockをはじめとした様々な生成AIのサービスが提供されています。 生成AIアプリケーションを構築、利用したい場合に、フロントエンドとして何を利用するかについても様々な選択肢がありますが、 本記事ではDifyをお試しで利用したい場合の構築方法についてご紹介します。 AWSの構築ワークショップとして以下URLで提供されているCloudFormationテンプレートをベースに、HTTPSで利用できるようにした構成を紹介します。 Dify での生成 AI アプリ

.entry .entry-content .table-of-contents > li > ul { display: none; } 1. はじめに 検索基盤部 検索基盤ブロックの佐藤（ @satto_sann ）、岡田（ @ryokada33 ）、SRE部 検索基盤SREブロックの富田（ @kei_gnu622 ）です。 ZOZOTOWNアプリ用に検索機能を提供していたオンプレサーバー上のレガシーなAPIを、約1年かけてクラウド環境へ全面リプレイスしました。 このリプレイスプロジェクトでは スパイ

こんにちは、ミイダステックオフィスです。技術書『 リーダブルコード 』や『Clean Architecture』の翻訳者として知られる角 征典さんを講師にお招きし、「アンクル・ボブに学ぶクラフトマンシップ」をテーマとした社内勉強会を開催しました。 ソフトウェアが社会の中核を担うようになった今、エンジニアはどのような姿勢でコードと向き合うべきなのか。今回の勉強会では、技術トレンドや個別の実装テクニックにとどまらず、 エンジニアとしての倫理、規律、そして仕事への向き合い方 について、改めて考える時間となりまし

G-gen の杉村です。当記事では、Google の生成 AI サービスである Gemini アプリ や Gemini Enterprise 、 NotebookLM 、 Gemini for Google Workspace 、 Vertex AI などについて、それぞれの違いや使い分けなど、組織へ導入する際の検討に役立つ情報を解説します。 はじめに サービス全体像 当記事で紹介する AI サービス 概要図 比較表 AI 機能別比較表 管理機能別比較表 Gemini Enterprise Gemini

こんにちは、広野です。 AWS re:Invent 2025 で、Amazon S3 Vectors が GA されました。 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 aws.amazon.com 以前は RAG 用のベクトルデータベースとして Amazon OpenSearch Service や

こんにちは、広野です。 AWS re:Invent 2025 で、Amazon S3 Vectors が GA されました。 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 aws.amazon.com 以前は RAG 用のベクトルデータベースとして Amazon OpenSearch Service や

こんにちは、広野です。 AWS re:Invent 2025 で、Amazon S3 Vectors が GA されました。 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon S3 Vectors は、プレビュー時の 40 倍の規模で一般提供されています。 aws.amazon.com 以前は RAG 用のベクトルデータベースとして Amazon OpenSearch Service や

急成長を遂げるメガベンチャーにおいて、マイクロサービスアーキテクチャの採用は事業スピードを加速させる強力な武器となります。 しかし、品質保証の観点に立つと、その複雑性はモノリスなシステムとは比較になりません。 サービスが細分化されるほど、チーム間でのテスト方針のズレや、予期せぬ場所での副作用、そして重すぎる統合テストといった課題が顕在化します。 現場の個別改善だけでは限界が見え始めている今、QAマネージャーに求められるのは、各チームを俯瞰し、リソースをどこに集中させるべきかを示す「テストの地図」を描くこと

事業が急速に拡大するメガベンチャーにおいて、複数プロダクトやマイクロサービスの品質を横断的に担保することは容易ではありません。 各チームが独立して開発を進める中で、テスト方針の不一致や手戻りの増加に課題を感じる場面も多いはずです。 これまでのUI主体のテストだけでは、リリースの高速化と複雑なシステム構造に対応し続けることは限界を迎えています。 そこで重要となるのがAPIテストの自動化です。 今回は部分最適に陥りがちな現場の改善を全体最適へと導くために、APIテスト自動化の戦略的な進め方や具体的な手法につい

リリース直前のテストや本番環境で、「まさかこんな操作をするなんて」「そこまで想定していなかった」という不具合に遭遇し、肝を冷やした経験はないでしょうか。 QAエンジニアとして真面目に仕様書と向き合っている人ほど、記載された「正しい挙動」を完璧に確認することに集中してしまい、異常な入力や予期せぬ操作に対する備え、すなわちネガティブテストが手薄になってしまうことがあります。 「テスト観点が浅い」という指摘を恐れる必要はありません。ネガティブテストが漏れてしまうのには明確な理由があり、それをカバーするための「思

はじめに こんにちは、2025年10月入社のr.tesakiです！ 本記事では、2025年10月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ S.N.  自己紹介 KI