ロバストネス図を活用したシステム設計
ロバストネス図とは 今回のテーマは「ロバストネス図」です。ロバストネス図とは、ロバストネス分析を行った結果のアウトプットとなります。ロバストネス分析とは、スリーアミーゴス（ソフトウェアの分野における統一モデリング言語（UML）を開発した3人）の1人であるイヴァー・ヤコブソンが提唱した分析手法で、システムを「バウンダリ」「エンティティ」「コントロール」の3つに分けて分析し（これらについては後述します）、要求モデル（ドメインモデル、ユースケースモデル）をロバスト（堅牢、強靭）にします。 ロバストネス図はUMLで定義されている13種類のダイアグラムには入っていませんが、UMLのコミュニケーション図やコラボレーション図を簡略化した形で簡単に書くことができます。ロバストネス図を書くことで要件の振る舞いが整理され、実装すべき点を明確にできます。 ユースケースシナリオを作成する ロバストネス図のインプッ
SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう
EXPLAINステートメントとは EXPLAINは、SQLの実行計画に関する情報を取得するためのステートメントです。実行計画とは「どのインデックスを使って（あるいはインデックスを使わずにテーブルスキャンで）クエリーを処理するか」をMySQLが判断した結果のことです。「インデックスはちゃんと使われているだろうか」「インデックスでどこまでクエリーを効率的に処理できているだろうか」という疑問が湧いた時には、「とりあえずEXPLAINで」となりますよね。 EXPLAINのマニュアルはこちらに、EXPLAIN の出力結果のカラムの意味についてはこちらに記載があります。 EXPLAINの何を見るか たとえば、次のような重いクエリーがあったとしましょう。 mysql> SELECT COUNT(some_column) FROM some_table WHERE some_column = xxx; +
なぜKubernetesが必要なのか？
はじめに Kubernetesはコンテナ化されたアプリケーションの展開、スケーリング、および管理を自動化するためのプラットフォーム（コンテナオーケストレーションエンジン）です。本連載では、Kubernetesを触ったことがない方でもKubernetesのコンセプトを理解し、実際にアプリケーションをコンテナ化して実行することが出来るようになることを目標としています。 ここ数年でDockerを皮切りにコンテナ技術への注目度が非常に高まり、実際にプロダクションでのコンテナ利用事例も増えてきました。プロダクション利用に耐えうるシステムを構築するにはDockerだけでは難しいため、Kubernetesに代表されるコンテナオーケストレーションエンジンとよばれるプラットフォームを利用することが一般的です。Kubernetesの他にもDocker SwarmやDC/OSなどもありますが、執筆時（2018年
BRMS（ルールエンジン）がもたらすメリット
こんにちは。SCSKでデリバリーを担当している植木と、レッドハットでプリセールスを担当している梅野です。3回にわたり、今注目を浴びているBRMS（ルールエンジン）について、主に技術的な観点からコラムを書かせていただきます。どうぞよろしくお願いします。 BRMSの特徴 BRMSついてはだいぶ認知されてきたと言えるでしょう。Business Rule Management System、その頭文字がBRMSです。内部構造としてはルールエンジンと、ルールを管理するマネージメント部分に分かれます。ここではそのうちのルールエンジン部分について解説していきたいと思います。 ルールエンジンはアプリケーションから呼び出されて動作する、1つのサービスと位置付けられます。ルールとは、業務で定義される「お約束ごと」です。例えば、 「請求金額は、同じ契約番号であれば提供している複数のサービスをまとめて計算する。」
[ThinkIT] 第6回：RailsとGrailsの比較（前編） (1/3)
前回までで、一通りJavaフレームワークとRailsの比較をしてきました。本連載の最後の比較は、少し趣向を変えてGroovy上に作成されたRailsライクなフレームワークGrailsとRailsの比較をしていきます。 GrailsはGroovy（Java公式仕様として策定が進められている、JavaVM上で動作するスクリプト言語）上で動作するRailsライクなフレームワークです。当初、Groovy on Railsという名称で作成が進められていたことからもわかるように、Railsに強く影響を受けていることが公言されています（後にRails作者の要請により改名）。 Groovyは豊富なJavaライブラリの利用が可能な上、言語設計自体もRubyの影響を受けているためRailsライクなフレームワークと相性がよいと考えられます。 Grailsに関する情報源には次のサイトがあります。
マシン・イメージを自動構築し、作業効率を高めるPacker入門
Packerとは？ Packerはマシン・イメージの自動生成や管理をするコマンドライン・ツールです。Packerの背景や機能解説のほか、AWS（Amazon Web Services）とDigitalOceanで実際にPackerを使う方法、Atlasとの連携方法をご紹介します。 マシン・イメージ管理とPacker Packerは何を解決するのか？ クラウド（IaaS）や仮想化環境を使う上で避けて通れないのが、マシン・イメージをどのように管理するべきかという課題です。ベンダーから用意されているマシン・イメージは、OS環境がほぼ初期状態のままです。その状態から、タイムゾーンや言語設定、管理用アカウントの作成、開発環境のインストール、ミドルウェアや各種サーバのセットアップなどを済ませて、実際に使える環境を整えるのに時間がかかります。 この課題を解決するのが、ある程度準備された環境をテンプレート
[ThinkIT] 第1回：O/Rマッピングとは？ (2/3)
Javaのようなオブジェクト指向の言語でリレーショナルデータベースを扱う際に、もっとも面倒な作業はオブジェクトとリレーショナルデータベースのマッピング作業です。これは両者の設計思想の違いから生じており、この問題を「インピーダンスミスマッチ」といいます。 Javaにおけるオブジェクト指向は、プログラムをオブジェクトとして設計し、現実世界のモデルに即したものとしてデータモデルを定義します。一方のデータベースでは、正規化という方法を用いて、データの検索／登録／更新処理に最適なモデルを定義します。データベース設計では、現実世界のモデルがどうなっているかは関係なく、あくまでも正規化といった、数学的世界の事情に基づいてモデルが考えられています。 なお、Javaとデータベースの設計思想の違いは、それぞれの役割を果たすために最適な構造であり、どちらの構造が優れているということはありません。 インピーダンス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チューニングに使えるJava性能監視ツール