2025年12月7日日曜日

クロニクル MacでIntelliJ

 1. IntelliJ IDEA Community Editionのダウンロードとインストール


1-1.ダウンロード:

Mac用のCommunity Edition(無料版)を選択し、**.dmg**ファイルをダウンロードします。

ここからダウンロードしました。

https://www.jetbrains.com/idea/download/?section=mac


1-2.インストール:

ダウンロードした**.dmg**ファイルを開きます。

表示されたウィンドウで、IntelliJ IDEAのアイコンをApplicationsフォルダにドラッグ&ドロップします。


1-3.起動:

ApplicationsフォルダからIntelliJ IDEAを起動します。


2. 新規プロジェクトの作成


2-1.「New Project」の選択:

IntelliJ IDEAのウェルカム画面で**「New Project」**を選択します。


2-2.プロジェクトの設定:

左側のリストで**「New Project」**が選択されていることを確認します。

Name: プロジェクト名(例: HelloWorldApp)を入力します。

Location: プロジェクトの保存場所を設定します(デフォルトで問題ありません)。

Language: **「Java」**を選択します。

Build System: **「IntelliJ」**を選択します。


2-3.JDKの選択/設定:

**「JDK」**のドロップダウンメニューを開きます。
すでにインストールされているJDKが表示されていましたが、
「Download JDK...」**を選んで「Oracle OpenJDK」をダウンロード・設定します。

なぜか、インストール済みのものだとうまくいきませんでした。

**「Add sample code」**にチェックが入っていることを確認します。
(これはmainメソッドを含む基本的なJavaファイルを作成する設定です)。

2-4.プロジェクトの作成:

画面下部の**「Create」**ボタンをクリックします。


3. 「Hello World」コードの確認と実行

3-1.コードの確認:

プロジェクトが作成されると、srcフォルダ内にMain.javaというファイルが自動で開きます。

そのファイルを以下のような「Hello World」コードに直しました。

void main() {
    IO.println(String.format("Hello World!!"));
}



3-2.プログラムの実行:

mainメソッドの左側にある緑色の実行アイコン(▶のようなマーク)をクリックし、
表示されるメニューから**「Run 'Main.main()'」**を選択します。


3-3.結果の確認:

IntelliJ IDEAの下部に**「Run」**ツールウィンドウが開き、プログラムの出力結果が表示されました。

コンソールに**Hello world!**と表示されました。







2025年12月5日金曜日

論文 THE MOST COMMON FACTORS FOR THE FAILURE OF SOFTWARE DEVELOPMENT PROJECT


プロジェクトの失敗要因に関して調査した論文です。

最もよくある失敗要因として、以下を上げています。

1.顧客やユーザの参加の不足

2.明確でない目的やゴール

3.貧弱な要件定義

4.リソースの不足

5.チーム内のコミュニケーション、チーム行動の失敗

6.計画とスケジュールのミス

7.コストの見積ミス

8.不適切なコストの見積方法

9.不適切なコストの見積ツール

10.テストの不足

11.リスクマネジメントのミス

12.非現実な、(好転するという)期待





2025年11月30日日曜日

Java 型推論

 1.文法

ローカル変数を、var で宣言すると、型が推論されます。


2.サンプル

public class Main {

    public static void main(String[] args) throws Exception {

        //型推論

        var var1 = "Test" ; 

        //型を出力

        System.out.println(var1.getClass().getSimpleName()) ; 

    }

}


3.実行結果

String 

が出力されます。







Java JDKのバージョンの取得

 1. 文法など

System.getProperty("java.version")

を利用します。


2.サンプルコード


public class Main {

    public static void main(String[] args) throws Exception {

         System.out.println(System.getProperty("java.version"));

    }

}


3.実行結果

paiza.io( https://paiza.io/ja )で試してみると、

18.0.2

と表示されました。





ベームのスパイラルモデル

 ベームは、リスク・ドリブンのソフトウェア開発方法論、

スパイラルモデルを提唱した。

これは、リスクマネジメントとインクリメンタルな開発を統合したものである。


ソフトウェア開発は、らせん(スパイラル)のように進む。

らせんの1周が、ソフトウェア開発のフェーズにあたる。

最初のフェーズは、システムのフィージビリティスタディに関するものである。

次のフェーズは、要件定義、次のフェーズは、システム設計・・・

と進む。

スパイラルモデルは、変更に対して耐性がある。

スパイラルモデルのそれぞれのフェーズは、次の4つのセクターに分けられる。

1.目標の設定

このフェーズの目標を設定する。制約等に基づき、成果物が特定され、

詳細な計画が作られる。プロジェクトのリスクが特定され、

リスクに対応するための代替プランが作成される。


2.リスクアセスメントと、リスクの低減

プロジェクトのリスクを特定し、その分析や低減が行われる。

例えば、要求の不明瞭さに対しては、プロトタイプを開発するなど。


3.開発と検証


4.計画

プロジェクトのレビュに基づき、スパイラルの次のループを実行するかを、

決定する。


スパイラルモデルの、他のモデルとの違いは、明示的にリスクを認識すること、

である。

リスクが特定され、それに対する開発を実行した結果で、次のフェーズの

計画を作ることとなる。





2025年11月15日土曜日

MPAとSPA

 MPA

・Multi Page Application 

・リクエストのたびにブラウザとサーバの間の通信が発生する。


SPA

・Single Page Application

・最初にサーバからHTMLやJavaScriptをダウンロードし、

以降はJavaScriptでサーバと通信する。

画面全体の書き直しは、発生しない。




Struts2の動作

 Struts2は、MVCフレームワークである。

コントローラは、dispatch servletフィルターや、Interceptorとして実装される。

モデルは、Actionとして実装される。

ビューは、result typeとresultとして実装される。


struts2のrequestのライフサイクルは、以下である。

1. ユーザがrequestを送る。

2.Filter Dispacherが、requestを受け取り、適切なActionを決定する。

3.Configured Interceptorの機能で、validationやFile uploadなどが実行される。

4.選択されたActionが実行され、requestに対する処理が行われる。

5.必要に応じてConfigured Interceptorが、後処理を行う

6.結果が、ビューとして返される


Struts2のコアコンポーネントは、次である。

Action

それぞれのURLは、特定のActionにマッピングされる。

Actionは、ユーザからのリクエストに応じたロジックを処理する。

Actioには、他2つの重要な処理がある。

Actionは、requestの情報をViewから受け取る。

また、Viewの描画するデータを決定する。

Actionの結果によって、正常なViewやエラー処理のViewのように、

Viewが使い分けられる。


Interceptors

Interceptorは、actionから分離された処理を実行する。

Actionが実行される前後の処理、例外処理などに使われる。




2025年11月9日日曜日

クロニクル Tomcatでhello world

tomcat-10.1.48です。

1. ファイルの作成

tomcatのインストールディレクトリ/webapps

の下に

test

ディレクトリを作成します。

testディレクトリの下に、以下のような、helloworld.txt

を作成します。

hello world


2. 確認

tomatを起動し、ブラウザーで、

http://localhost:8080/test/helloworld.txt

を指定すると

hello world

が表示されます。




クロニクル MacでTomcat

 java 17.0.16 2025-07-15 LTS


がインストールされているとします。


1. ダウンロード


以下のサイト


https://tomcat.apache.org/download-10.cgi


から、


Core zip版をダウンロードします。


apache-tomcat-10.1.48.zip


がダウンロードしました。


2.展開


1.でダウンロードしたファイルを以下のコマンドで展開しました。


unzip apache-tomcat-10.1.48.zip


apache-tomcat-10.1.48フォルダーができました。


3.起動


apache-tomcat-10.1.48/binで


%chmod 775 startup.sh

%chmod 775 catalina.sh

% ./startup.sh


4.確認


ブラウザーで、


http://localhost:8080


を指定すると、


Apache Tomcat/10.1.48

If you're seeing this, you've successfully installed Tomcat. Congratulations!


画面が表示されました。


5.停止


% chmod 775 shutdown.sh

% ./shutdown.sh


で停止しました。



2025年11月3日月曜日

論文 SYSTEMS DEVELOPMENT METHODOLOGIES: CONCEPTUAL STUDY

 公開されている

SYSTEMS DEVELOPMENT METHODOLOGIES: CONCEPTUAL STUDY

のキモ部分を読んで勉強してみたいと思います。


System develoipment methodology(SDM)は、

システムの分析、設計、実装、保守を行う上で、

組織が従うべき標準的なプロセスである。

System development life cycle(SDLC)は、

システム開発をステップあるいは、フェーズに分けるものである。

SDLCは、計画、分析、設計、実装、保守の5つのステージを定義する。

計画では、開発のための計画が作られ、優先順位づけがなされる。

次は分析工程である。この工程では、要求が決定され、System Analysis(SA)

を使って構造化される。続く設計では、要求をもとに、情報システムの

アウトプットなどが設計される。

続く実装では、設計結果からコーディングとテストが行われる。

実装にはドキュメンテーションとトレーニングが含まれる。

ドキュメンテーションは、対象をインストールして利用しようとする

ユーザ向けに作られる。トレーニングは、ユーザにシステムの使い方を伝える。

システム開発が完了すると、保守フェーズに入る。ここでは既存システムの保守が

行われる。


1970年代には、ウォーターフォールモデルが提案された。

それ以降、ウォーターフォールモデルの欠点を克服する、あるいは、

効率化や、システム開発プロセスの品質改善に向けて、いろいろなモデルが

提案された。次にシステム開発のモデルを示す。

(1) 1970年代まで

 ・形式的技法

 ・コンポーネントベース開発

 ・リニアでシーケンシャルなモデル

(2) 1970~1993

   ・インクリメンタルでイテレイティブなモデル

   ・OODAD

   ・アジャイルモデル

(3) 1993~2000

   ・SOA

   ・Open Source development 

(4) 2000~

 ・現代アジャイルモデル 


1967年 形式的技法

1968年 コンポーネントベース開発

1970年 ウォーターフォールモデル

1970年代 プロトタイプモデル

1974年 Join Application and Development

1982年 Vモデル

1986年 スパイラルモデル

1990年代 アスペクト指向

1991年 Rapid Application Development 

1993年 Wモデル

1993年 スクラム

1994年 Concurrent Development

1994年 Dynamic Systems Development Method

1996年 Rational Unified Process 

1996年 Service Oriented

1997年 Feature Driven Development

1998年 クリスタル方法論

1998年 Open Source Development

1999年 eXtrem programming 

1999年 Adaptive Software Development

2002年 Agile Unified Process

2003年 Test Driven Development

2003年 Behavior Driven Development

2004年 kanban Software Development


SDM from 1970 to 1993

ウォーターフォールモデルが導入され、

システム開発が、よりフォーマルとなった。


Liner Sequence Model

Liner Sequence Modelは、ソフトウェアライフサイクルの

最初に十分な要求を収集し、それをベースラインとする。

システムの開発中は、その要求を変更することはできない。

システムが完成した後に、利用者は、フィードバックを行う。

この方法は、大規模で複雑なシステムに対して、有効である。

あらかじめ要件が、確定している。

この方法論の問題は、利用者のライフサイクルへの関与が薄いため、

保守コストが高いことにある。

リニアで、シーケンシャルなモデルには、

ウォーターフォールモデル、V-Model、W-Modelがある。


ウォーターフォールモデル

ウォーターフォールモデルでは、次のフェーズがはじまる前に、

それぞれのフェーズを完了する。

このモデルは、要求の変化が少ないプロジェクトに有効である。


V-Model

V-Modelは、ウォーターフォールモデルでの、システムの品質の

改善のためテストに焦点をあてたものである。

コーディング工程とユニットテストの工程を対応させ、

Low levelのデザインドキュメントが、コンポーネントテストのInputとなる。

High levelのデザインドキュメントが、統合テストのInputとなる。

System Requirement Specification(SRS)が、システムテストのInputとなる。

Business Requirement Specification(BRS)が、受入テストのInputとなる。

V-Modelは、成功したモデルで、広く企業で受け入れられている。


インクリメンタル・イテレーションモデル




--続きます--

2025年11月2日日曜日

入力チェックの種類

 1.ニューメリックチェック


数値として扱えるもののみ


2.シーケンスチェック


対象とするデータが一定の順番で並ぶ


3.リミットチェック


データが、定められた範囲内にあるか


4.フォーマットチェック


日付など、データ形式が正しいか


5.照合チェック


 入力されたコードが、マスターに存在するか、など


6.論理チェック


関連する項目間に矛盾がないか




2025年11月1日土曜日

O記法

 O記法

 計算量のオーダーを表す。次のようなオーダーが使われる。(速い順)

O(1) 

O(log n) 

O(n)

O(n log n)

O(n2)

 

線形探索法

先頭から順に調べる。

最悪は、O(n) 。最良は、O(1) 

 

二分探索法

データがソートされている場合に使われる。

最悪は、O(log n)。最良は、O(1)


挿入ソート

最悪は、O(n2)。最良は、O(n)

 

選択ソート

最悪、最良とも、O(n2)

 

バブルソート

最悪、最良とも、O(n2)

 

クイックソート

最悪、O(n2)。最良は、O(n log n) 


マージソート

最悪、最良とも、O(n log n)

 

 

 

 

 

 

 



2025年10月31日金曜日

Agile to Lean Software Development Transformation

公開されている

「Agile to Lean Software Development Transformation」のキモ部分です。

間違っていたら、ごめんなさい。

 

0.概要


アジャイルをスケールアップする方法として、リーン開発が提唱されている。

この論文の目的は、アジャイルをリーン開発へ変更することについて

(1)そのメリット(2)変更点(3)変更を測定するメトリクス

を明らかにすること。

その方法として、 Systematic Literature Review(SLR)を利用した。

結果、主なメリットとしては、次があった

(1)時間の削減 (2)フローの改善 (3)継続的な改善(4)欠陥のFIX率の改善

主な変更点としては、次があった

(1)マインドセットを変えること (2)無駄の削減のコンセプトの理解 (3)スケールのフレキシビリティ

利用されるメトリクスとしては、(1)リードタイム が最も使われていた

1.はじめに


リーンソフトウェア開発は、開発プロセスを最適化するために、ムダを削減するものである。

この論文の目的は、アジャイルからリーンへの変更に関して、そのメリット、変更点、利用されるメトリクスを明らかにすること。

2.SLR


Systematic Literature Reviewは、文献をシステマティックな方法でまとめるもの。

A.Needs for an SLR


 アジャイルからリーンへの変更に関しての研究は、ウォーターフォールから、アジャイルへの変更に関しての研究に比較して、少ない。

B.リサーチクエスチョン

RQ1 アジャイルにリーンの原則を組み込むことで、どんなメリットがあるか

RQ2 アジャイルにリーンの原則を組み込むことで、どんな変更があるか

RQ3 アジャイルにリーンへ変更することに関して測定するメトリクスは

C.Search strategy & Study selection

省略

D. Study quality assessment criteria

対象の18の論文に関して、目的に合っているかを確認するために、次の調査を行った。

c1. アジャイルが変更前の状態か

c2.実際に、リーンソフトウェア開発のプラクティスを採用したか

c3.変更のメトリクスがあるか

3.SLA Result


A.benefit (RQ1)

レポートされているbenefitを分析した

(1)リードタイムの短縮

もっとも多く報告されているbenefitであった

(2)フローの改善

(3)継続的な改善


B.challenges(RQ2)

アジャイルから、リーンへの変更には、いろいろなことが必要となる。プロセスの可視化、持続性のマネジメント、チーム間のコミュニケーションが、よく見られるものである。

テストプロセスの変更もよく重要な変更と言われる。それは、ソフトウェアの欠陥に関して、真の原因を見つけるものである。

アジャイルからリーンへの変更のキモとして、ムダの最小化と品質の改善がある。

C.メトリクス(RQ3)

(1)リードタイム

(2)欠陥数

単位時間当たりの欠陥など

(3)欠陥の修正時間

(4)Velocity

Velocityは、タスクの完了に必要と予測した時間を、実際にかかった時間で、割ったものである。

(5)Line of code

(6)イテレーション事のストーリー数

(7)リリースの頻度

4.結論


概要と同じ






2025年10月27日月曜日

アルゴリズムの考え方

総当たりアルゴリズム



すべての場合をためし、解を求める。


近似アルゴリズム



 ・正解に近い解を探す

・正解との誤差がある範囲におさまると保証されているものを

 精度保証付アルゴリズムという。

・精度の保証のないアルゴリズムを、発見的手法(ヒューリスティック)
 
 という。




2025年10月26日日曜日

Webエンジニアリング

WEBアプリケーションの仕様化と分析

 

仕様化とは、次の問いに答えること

・Webアプリケーションが必要となる主要なモチベーションは、何か?

・誰が、Webアプリケーションを必要としているか?

・誰が、Webアプリケーションを使うか?

これを基に、目標を設定する

目標には、次が含まれる

・どんな情報やコンテンツを提供するか

・Web App で何ができるのか

分析は、要件を定義するものであるが、Web特融の点としては、以下がある


1.コンテンツの分析


 Webアプリケーションで提供するコンテンツを特定する
 
 データモデリング手法も利用できる


2.インタラクション分析


 ユーザとのかかわり合いを分析する

 ユースケースを利用できる


3.機能分析

  ユースケースシナリオを作り、オペレーションや機能を特定する


4.コンフィグレーション分析

 Webアプリケーションの環境やインフラを定義する



Webアプリケーションの設計


 

アーキテクチャ・デザイン

 

 Webベースのシステムのアーキテクチャデザインは、Webのコンテンツの構造を定義する

 

ナビゲーションのデザイン


異なるロールのユーザに対して、アクセスできるコンテンツが異なる場合がある

その時、個々のロールに応じたナビゲーションを決定する必要がある

また、ナビゲーションの手段として、テキストベースのリンク、アイコン、ボタン、画像等から適切なものを選択する

また、ボタンが押せる、押せないを、ボタンの形状で変える、テキストベースのリンクの色で変更する等からも選択する

これ以外にも、サイトマップの利用、インデックス、サーチエンジン、helpの利用等を考慮する必要がある

 

インターフェースのデザイン


インターフェースのデザインに関していは、次のようなものがある

・サーバエラーを、利用者に見せない

・レスポンスを保つため、テキストや画像の両をしぼる

・スクロールを少なくする

・メニュー、ナビゲーション、ヘッダー、フッターは、統一し、すべてのページで利用可能とする

・意図が伝わらないアイコン、画像等はさける






2025年10月25日土曜日

ストレージの種類

ブロックストレージ


ブロック単位でアクセス。FCやiSCSIなどのプロトコルが使われる。


ファイルストレージ


ファイル単位でアクセス。NFSやNASなど。


オブジェクトストレージ


オブジェクト単位でアクセス。RESTでのAPIアクセスなど。








2025年10月21日火曜日

アルゴリズム「エラトステネスのふるい」の例

 たとえば、100までの素数を求める場合、以下のアルゴリズムとなる。

(1) 100個の配列を用意する。

(2) すべて配列の値を、1とする。

(3) 2の倍数番目の配列の値を、0とする。

(4) 3の倍数番目の配列の値を、0とする。

(5) 4は、すでに、0なので、次に進む。

(6) 5の倍数番目の配列の値を、0とする。

これを、100の平方根まで繰り返す。




2025年10月20日月曜日

[データ構造]グラフの種類

無向グラフ


エッジに方向がなく、エッジで結ばれたノードは、双方向の関係がある。


有向グラフ


エッジに方向があり、エッジで結ばれたノード間には、意味のある関係がある。


(親子関係など)

非連結グラフ


エッジで結ばれていないノードが、1つ以上ある。


非巡回グラフ


循環を含まないグラフ。


完全グラフ


すべてのノードが他のすべてのノードとエッジでつながる。


重み付きグラフ


ノード間のエッジが重み付けられたグラフ。


2025年10月19日日曜日

論文 Software Application Security Test Strategy with Lean Canvas Design


公開されている論文

Software Application Security Test Strategy with Lean Canvas Design

のキモ部分です。

1.概要

この論文は、ソフトウェアのセキュリティテスト計画に対して

リーンキャンパスデザインが、利用できるかを検証するもの


2.問題

セキュリティの品質を保持するチームは、多くの問題に直面する

・セキュリティテスト戦略の不足

・セキュリティテストが早期に開始できない

・セキュリティテストに精通した要因がいない

・適切なツールがない

・適切なテスト計画やテストデータがない


3.SDLCにおけるセキュリティテストとリーンキャンパスデザイン

SDLCにおけるセキュリティテストは、以下のように扱われる

(1)要件定義

セキュリティ要件や、誤利用などのテストケースを分析する。

(2)設計

システムのリスク分析を行う

(3)コーディングとユニットテスト

認証・認可、暗号化、入力の検証やエンコーディング

ユーザセッションの管理、エラーと例外ハンドリング、

監査とロギングなどの実装とテスト

(4)総合テスト

ブラックボックスでのテスト

(5)システムテスト

SQLインジェクションなどのホワイトボックステスト

(6)稼働

脆弱性のSCANや、ペネトレーションテスト

(7)サポート

ソフトウェアのパッチ、アップデート


4.アジャイルとセキュリティテストの関連

(1)新しいイテレーションの開始

セキュリティ要求の収集

(2)ユーザーストーリー

セキュリティアーキテクチャのレビュ

(3)ユーザーストーリーの実装

アプリケーションの脆弱性の検査

(4)Deploy

外部のセキュリティテスト


5.セキュリティアーキテクチャの概要

(1)要求

・ユーザーストーリー

・アーキテクチャやシステムコンポーネントのリスク分析

・セキュリティ要求の詳細化

(2)設計

・リスク分析

・脅威モデル

(3)コーディング

コードのレビュ

(4)テスティング

ペネトレーションテストなど

(5)リリース

セキュリティポリシーの設定、セットアップ

(6)保守

オペレーションのセキュリティ








ソフトウェア開発での再利用の対象

 再利用の対象は、ソフトウェアの生産性や品質を上げるのに、重要な手段である。

一般的には、次のような再利用の対象が考えられる。

・アーキテクチャ

・ソースコード

・要求定義

・設計

・データ

・見積 

・画面

・プロジェクト計画

・テスト計画

・テストケース

・テストスクリプト

・ユーザ文書

・ユーザインターフェース






2025年10月18日土曜日

論文 Web Frameworks, Database and Web Stacks

 公開されている

「Web Frameworks, Database and Web Sacks」

のキモ部分を読んで勉強してみたいと思います。



概要

Webアプリケーション構築には、フロントエンド、バックエンドとも

多くのフレームワークがある。

適切なフロントエンド、バックエンド、データベースを選択することが必要である。

フレームワーク、データベース、OSの環境をWeb Stackと呼ぶ

Webアプリケーションを構築する技術やフレームワークは、数多い。

その1つにマイクロサービスベースのアーキテクチャがある。

マイクロサービスは、システムをサービスの集合体とすることで、

疎結合、高い保守性、独立したディプロイを提供しようとするもの。

サービス間は、APIでつながる。


フロントエンドは、ユーザインタフェースを提供し、

バックエンドは、ビジネスロジックを提供する。

この2つを独立させることで、迅速な開発、容易なアップグレード、高い保守性を実現できる


フロントエンドのフレームワーク


ユーザとのインタラクションを提供するコンポーネントをフロントエンドという。

フロントエンドに関するテーマは、パフォーマンスとレスポンシビリティ。

また、画面の大きさに合わせた出力等も必要になる。

1.AngularJS


SPAをつくるJavaScriptのフレームワーク。

HTMLを拡張してアプリケーションのコンポーネントを表現する。

2.ReactJS


効率的で多機能なユーザインタフェース向けのJavaScriptフレームワーク。

再利用可能な部品から複雑なUIを組み立てる。

ReactJSは、JSXを利用する。

JSXは、XMLのシンタックスにJavaScriptを加えたプリプロセッサである。


3.VueJS


Vueは、ユーザインタフェース、SPAを作るフレームワーク。

リアクティブやコンポーネントの利用に特徴がある。




バックエンドフレームワーク


バックエンドは、数多くの機能からなる。

たとえば、外部からの攻撃に対するAPIの保護、認証、データベースとの連携、

ユーザからのリクエストに応じた処理等である。

NodeJS


NodeJSは、非同期でイベントドリブンなJavaScriptのランタイムで、

スケーラブルなアプリケーションを構築することができる。

数多くのコネクションを同時に管理できる。

それぞれのコネクションは、コールバックがトリガーとなる。それ以外の時は、Sleepしている。

この動作は、他の多くのスレッドを利用する同期モデルとは異なる。

さらにNodeでは、lockを利用しないので、デットロックを心配する必要がない。

I/Oを発生させる機能が少ないため、プロセスがブロックされることはない。

これらの特質のため、Nodeは、スケーラブルなものとなっている。

Nodeは、オプティマズされたV8エンジンを利用している。

 

Django


Python用のWebフレームワーク。

高速に動作し、開発者が迅速に開発できるようになっている。

開発者がビジネスロジックの実装に集中できるようにしている。

Gjangoは、認証、サイトマップ、コンテンツ管理、RSS feedsなど、

多くの機能を支援している。

Djangoは、MVCアーキテクチャを採用している。

Modelは、ロジカルなデータ構造で、Webインターフェイスとデータベースの仲介を行う。

Viewは、ユーザインターフェイスのロジックを含む。

controllerは、modelからviewのデータのやり取りを行う。


Spring Boot


Spring bootは、巨大なモノリックなアプリケーションより、

マイクロサービスに適している。

Docker のコンテナにダイレクトにDeployできる。

サーバサイドのアプリケーション、REST API、イベント駆動型の処理を容易に作成できる。

また、health check(モニタリング)、メトリクスデータの提供などの機能もある。

SAMLやOAuth、LDAPなど業界標準の認証プロトコルをサポートする。

多くのリレーション、非リレーショナルのデータベース、クラウド・サービス、

MapReduceフレームワーク等に対応している。


データベース


リレーショナルデータベース(SQL)とノンリレーショナル(NoSQL)のデータベースの

選択がある。リレーショナルデータベースは、データが少ないOLTPに適している。

ノンリレーショナルデータベースは、非構造データを利用するときに好まれる。

PostgreSQL


PostgreSQLは、OLTPシステムに適している。また、分析用データベースにも適している。

高いスケーラビリティを持ち、Webシステムにも適している。

Django、Hibernate、NodeJSなどモダンなフレームワークと一緒に使われることが多い。

レプリケーションに優れており、多くのサーバが必要になる時などに利用される。

NoSQLスタイルでも利用できる。

MongoDB


ドキュメント指向のNoSQLのデータベースである。

コレクションとドキュメントと呼ばれる概念がある。

ドキュメントには、key-valueのペアが含まれ、こればリレーショナルデーターベースのレコードにあたる。

同じタイプのドキュメントの集合がコレクションである。

MongoDBは、レプリケーションの機能を利用して、スケーラビリティを実現する。



WEB STACK



webアプリケーション構築に必要なソフトウェアの集合である。

web stackには、OS、データベース、プログラミング言語、Webサーバが含まれる。


〇 LAMP/LEMP

Linux 、Apache/Nginx、MySQL、PHP

〇 MEAN/MERN/MEVN

MongoDB、ExpressJS/AngularJS/ReactJS/VueJS、NodeJS

〇 Spring STACK






[データ構造]線形リストの種類

単方向線形リスト


リストに保管するオブジェクトが、次のオブジェクトの位置が分かる。

(ポインターを持っている)

双方向線形リスト


次のオブジェクトではなく、前のオブジェクトの位置も持っている。

環状リスト


最後のオブジェクトが、最初のオブジェクトの位置も持っている。


2025年10月16日木曜日

クロニクル ユースケースシナリオ:初期画面表示を書いてみる


ユースケースシナリオの練習です。


1.ユースケース名

 初期画面表示

2.事前条件

 利用者がシステムへログインする

3.事後条件

 利用者へ応じた初期画面が表示される

4.正常系シナリオ
 
 (1)システムは、ログインした利用者の属性を取得する

 (2)システムは、(1)で取得した属性から、属性に応じた画面名を取得する

    (3)システムは、(2)で取得した画面を表示する

5.異常系シナリオ
 
 (1)正常系シナリオの(1)、(2)、(3)のいずれかで失敗した場合は、
  システムはSorry画面を表示する






2025年10月15日水曜日

論文 Does Software Modernization Deliver What It Aimed for ?

論文

Does Software Modernization Deliver What It Aimed for ?

の概要です。

1.概要

ソフトウェアのモダニゼーションで、ビジネスの目的が達成されたかの研究は少ない。

5つのケーススタディからこれを分析する

2.はじめに

ソフトウェアのモダニゼーションは、主に保守性や柔軟性を高め、コストを削減するもの

3.関連研究

literature reviewでは、次のBenefitがあった

・コスト削減

・再利用性の向上

・アジリティの向上

・柔軟性の向上

・パフォーマンスの改善

・保守性の向上

・競争への追随

・可用性の向上

・市場投入のスピードアップ

・相互運用性の向上

4.Case Study

(1)ケース1

次の目的で、モダナイズされた

・ユーザビリティの向上

・一貫性の向上

・保守性の向上

意図しなかった効果

・組織内でのコミュニケーションの向上

(2)ケース2

次の目的で、モダナイズされた

・フレキシビリティの向上

・保守性の向上

・ユーザビリティの向上

意図しなかった効果

・メンテナスコストの低減


(3)ケース3

次の目的で、モダナイズされた

・保守コスト、運用コストの削減

・レガシーテクノロジーからの脱却

意図しなかった効果

・組織のフレキシビリティの向上


(4)ケース4

次の目的で、モダナイズされた

・運用コストの削減

・レガシーテクノロジーからの脱却

意図しなかった効果

・システムの高速化

・自動化の拡大

・セキュリティの向上


(5)ケース5

次の目的で、モダナイズされた

・運用コストの削減

・パフォーマンスの向上

・レガシーテクノロジーからの脱却

意図しなかった効果

・ベンダーロックインの回避

・柔軟性の確保





アルゴリズム設計の考え方

1.力ずく戦略

すべての方法を、しらみつぶしに試す


2.分割統治戦略

大きな問題を、小さな均質な問題に分割する


3.ダイナミック・プログラミング

分割された問題には、同じものが存在するのでこれを、何回も解くことを回避する


4.欲張り選択戦略

分割した服問題の1つを選び、他は破棄することで、効率を確保する











Comparative Study of MVC Architecture with respect to Struts Framework and PHP

 公開されている

Comparative Study of MVC Architecture 

with respect to Struts Framework and PHP

のキモ部分を読んで、Strutsを勉強してみたいと思います。


概要

Model、View、Controller(MVC)アーキテクチャは、主にミドルウェアで実装される。

MVCは、主にWebアプリケーションで利用される。

というのも、開発者が理解するのが容易だからである。

MVCアーキテクチャは、ビジネス層(Model Logic)、

表示層(View Logic)、コントロール層(Controller Logic)に分離するもの。

この研究は、StrutsとPHPを用いて、MVCの実装の差異について、

確認するもの。

MVCアーキテクチャは、複雑なアプリケーションに利用される。

Strutsを用いて、MVCを実装することは、容易である。

様々なIDEのサポートがあるためである。

PHPでは、Model、View、Controllerのフレームワークを

手動で作る必要がある。


イントロ

MVCは、大規模で複雑な問題のソリューションとして、

デザインされた。

最初は、Smalltalk-80のフレームワークとして利用された。

MVCは、理解が容易で、Webアプリケーションで利用される。

MVCは、データとコードの分離、複雑性の低減、

ビジネスロジックの統合を実現できる。


MVCアーキテクチャ

Model

モデルは、データを持つクラスで、getterやsetterを持つ。

データベースへの接続はなく、データベースから抽出されたデータを

マネジメントするだけである。

model クラスの主要な活動は、viewクラスからのリクエストへの応答、

controllerクラスからの指示への応答である。


View

Viewの主な責務は、クライアントからの指示に従って、

modelコンポーネントを適切に表示すること。

viewにも情報を持つ。modelからのレスポンスに応じて

アウトプットのための表現をつくる。

JSP、ASP、PHPなどのフォーマットでデータを表示する。


Controller

ユーザからのリクエストに応答するのが、Controllerである。

Controllerは、ユーザのインプットをViewから読み込み、

データをmodelに渡す。modelやviewの変更を起動する。

Controllerクラスは、viewやmodelクラスと関連する。



-- つづきます。--

2025年10月14日火曜日

[データ構造]木の種類

二本木

ルートノード、ノードの下のノード、リーフが2つ以下の木


全二本木

二本木の中で、全てのノードが2つの子ノードを持つ木


完全二本木

深さが同じ全二本木


平衡木

二本木にノードを追加する時、完全二本木に近づける。

ルートから葉ノードまでの深さが、ほぼ等しい二本木





2025年10月13日月曜日

変数のネーミングの方式

キャメル記法


1つ目の単語の頭文字は、小文字。

複数の単語を連結する場合には、2つ目以降の単語の頭文字を大文字にする。

例) userName

パスカル記法


1つ目の単語の頭文字は、大文字。

複数の単語を連結する場合には、2つ目以降の単語の頭文字を大文字にする。

例) UserName

アッパースネーク記法


すべての単語を大文字にして

複数の単語を連結する場合には、アンダースコアで連結する。

例) USER_NAME



A study of MVC - A software Design Pattern for Web

公開されている

A study of MVC - A software Design Pattern for Web

のキモの部分を読んで勉強してみたいと思います。


Model - View - Controllerのデザインパターンは、Javaの

Web開発用フレームワークで数多く採用されている。

これらの webフレームワークの欠点を分析する。

MVCは、動的なソフトウェアシステムを構築するためには、

有効である。Model、View、Controllerが独立性を保った

パターンを考える。

Model

データやアクティビティを表現する。データベースのテーブルを表したり、

コンピュータ上のプロセスを表す

View

モデルの表現

Controller 

モデルの状態の変化の管理


MVCは、J2EEでも利用されている。

Struts2 フレームワークのMVCパターンは、以下である。

(1) ユーザインターフェースのコンポーネントをViewとする

(2) アプリケーションのロジックをModelとする

(3) 制御機能をControllerとする

Strutsのview componentは、JSPのtagとして実装される。

これは、フロー制御、モデルへのアクセス、HTMLのフォーマッティングなどの機能がある。

Controllerのcomponentは、actionと呼ばれるJavaのクラスで実装される。

actionは、ユーザのインプットを検証しモデルに対するトランザクションを実行する。

XMLの構成ファイルやJavaのアノテーションがActionを制御するために使われる。

Actionと出力の対応づけを行うことで、フロー制御を行う。

MVC-Webにおけるmodelの役割は、次である。

(1) データベースに対してデータの一貫性を保証する

(2) トランザクション処理

(3) 外部連系

(4) ViewとControllerからのリクエストへ対応するクエリー処理

View Component の責務は次である。

1.情報の表示

2.入力フォームの表示などユーザとのインタラクションの管理

3.クライアント側での処理

Controller の責務は、次である。

1.リクエストの処理

2.アクションの起動



-----

クロニクル ユースケースシナリオを書いてみる



名前:新規予約


目的:新たな予約を受けつけ、可能ならば予約する


起動者:利用者


主シーケンス


(1)利用者は、予約要求情報(利用日、対象会議室、利用者、開始/終了時間)を入力する

(2)システムは、
 
(3)システムは、予約要求情報に従って、会議室予約情報を作成し、予約を行う
 
(4)システムは、予約が完了した旨のメッセージを出力する


代替シーケンス


(a)主シーケンス(2)の予約要求情報が正しくない場合
 
    (a-1)正しくない内容に応じたエラーメッセージを出力する
 
     (a-2)主シーケンス(1)に戻る

 

名前:予約確認

目的:日を指定すると、その日の会議室の予約の一覧を表示する

起動者:利用者

主シーケンス

(1)利用者は、利用予定日を入力する

(2)システムは、利用予定日が正しいかチェックする

(3)システムは、利用予定日の会議室予約情報を取得する

(4)システムは、利用予定日の会議室予約情報を表示する

代替シーケンス

(a)主シーケンス(2)で、利用予定日が正しくない場合

  (a-1) システムは、利用予定日が正しくない旨のメッセージを出力する

      (a-2)主シーケンス(1)に戻る



Comparative Study on Agile software development methodologies

 公開されている

Comparative Study on Agile software development methodologies

のキモ部分を読んで勉強してみたいと思います。


概要


環境変化が激しく、その変化に合わせてソフトウェア要求も変わる。

そしてスピードが求められる。

計画主導の方法では、追いつかない。

アジャイル・ソフトウェア開発は、継続的に価値のあるソフトウェアを

リリースすることで顧客への価値を提供する。

アジャイルは、イテレーティブで、インクリメンタルなプロセスであり、

自己組織化されたクロスファンクショナルなチームによって開発される。

この論文は、ソフトウェア開発プロセスを改善するアジャイルの要因を分析する。

また、アジャイル開発と伝統的な開発の比較を行う。

素早く継続的な価値のあるソフトウェアのリリースが、

伝統的な方法論に比較し、価値があるのではないかと考えている。


アジャイルには、多くの方法論があり、

ソフトウェア開発におけるテクニックやプラクティスがある。

多くのアジャイル方法論では、プロジェクトのライフサイクルを通じて、

チームワーク、コラボレーション、適用に重点を置く。


アジャイルの方法論には、XP、スクラム、ダイナミック・システム・ディベロップメント、

適応型ソフトウェア開発、クリスタルなどがある。


初期の頃から、よく知られたものは、スクラムとXPである。

スクラムは、ソフトウェア開発のプロジェクトのマネジメント、成功に重点を置いている。

XPは、ソフトウェアの実装に重点を置いている。


アジャイルには、多くの方法論があり、

ソフトウェア開発におけるテクニックやプラクティスがある。

多くのアジャイル方法論では、プロジェクトのライフサイクルを通じて、

チームワーク、コラボレーション、適用に重点を置く。



要求の変更への対応


変更への対応は、ソフトウェアプロジェクトにおいて

成功のカギとなる。重量級の方法論では、製品の機能は凍結され、

変更を受け入れない。

アジャイル方法論は、「変更を歓迎する」。


軽量メソッド


ウォーターフォールやスパイラルなどのモデルでは、計画のための費用が高価であり、

事前に定められたとおりのフェーズで進み、大量のドキュメントを作り、設計に時間がかかる。

アジャイルのような軽量のプロセスでは、コードや製造に重点を置く。


ソフトウェアプロダクトの迅速なリリース


アジャイル開発では、ソフトウェアプロダクトの迅速なリリースに重点をおく。

早いサイクルと頻繁なリリースである。

ソフトウェア開発の伝統的な方法論は、要件定義、設計、実装、保守

という工程に従って進めるものである。


ウォーターフォールモデル、計画ドリブン、ドキュメントドリブン、

重厚方法論などと呼ばれている。


これらの方法論では、25%以上の要求が変更されている、と言われている。

アジャイル方法論は、ソフトウェアへの要求はダイナミックに変化するということを

前提においている。


アジャイルチームは、複数のスキルを持つ個人の集まりである。

開発者は、オンサイト顧客で、要求をよりよく理解するために、

絶え間なくドメイン知識を獲得している。

短いライフサイクルで、要求の変更へ対応し、より必要な要求を発見する。

アジャイル開発の定義に共通することは、イテレーティブで、インクリメンタルで、

自己組織化されたアドホックなソフトウェア開発であること。

アジャイルメソッドは、軽量プロセスで、短いイテレーティブで、

ユーザと協働し、要求や優先順位を決めていく。



(つづきます)

2025年10月12日日曜日

Gitを用いた開発の流れ

Gitを用いた開発の流れ

1.Clone


共有リポジトリから、ローカルへコピー

2.ファイル編集


3.add


編集したファイルをcommit対象として登録

4.commit


ローカルリポジトリへ反映

5.push


ローカルリポジトリから、共有リポジトリへの差分送信

6.pull


共有リポジトリから、ローカルリポジトリへ


他のユーザが更新した差分を反映







2025年10月11日土曜日

ラムダ式の表現



関数表現  f(x) = x + 1 

ラムダ表現  λx.x +1 

λx.x +1 で、引数 x = 2 とした場合の表現は

(λx.x +1 )2






Software Development Life Cycle AGILE vs Traditional Approaches

 公開されている

Software Development Life Cycle AGILE vs Traditional Approaches

のキモ部分を読んで、 勉強してみたいと思います。


概要


ソフトウェア開発ライフサイクルは、ソフトウェア開発で必要となる

フェーズを記述するもの。この論文では、伝統的な方法論、

およびアジャイル方法論の、それぞれのメリット、デメリットを述べる。

また、アジャイル開発の改善を提案する。


イントロ


ソフトウェア開発ライフサイクル(SDLC)は、ソフトウエアシステムを

構築、保守するプロセスである。

開発を計画し、コントロールするフレームワークである。

現在の方法論には、伝統的な方法論とアジャイル方法論がある。


伝統的な方法論


water fall モデル、V-Model 、RUPは、伝統的な方法論と呼ばれており、

重量級の方法論に分類される。

これらの方法論は、シーケンシャルに進む方法である。

要件定義、ソリューション開発、テスト、ディプロイ等である。

伝統的な方法論では、プロジェクトの最初に要件を定義し、

ドキュメント化し、固定的な要求セットをつくる。


伝統的な方法論は、4つのフェーズからなる。

最初のステップは、 プロジェクトの要求を決め、

プロジェクトの期間などを見積り、リスクを洗い出すことである。

要求が固まると、次のステップは、設計とアーキテクチャの計画、

インフラの計画である。

アーキテクチャや設計の計画が終わると、開発フェーズに入り、

コードが作られる。そして、テストされ、ディプロイされる。

伝統的な方法論は、事前に定義されたプロセスと、次工程のためのに

作られたドキュメントに依存する。


プロジェクトの成否は、開発を始める前に、どれだけすべての要求を

理解しているかに依存する。途中での要求への変更は、何等かの問題を起こす。

というのも、プロジェクトのコスト、スケジュール、リソースの配分は、

速い段階で決められるから。


3. アジャイル ソフトウェア開発


アジャイル開発は、インクリメンタルで、イテレーティブな開発に基づいている。

 開発の中で、フェーズが何度も行われる。

イテレーションは、顧客からのフィードバックなどで行われる。

アジャイル開発では、開発ライフサイクルは、小さな部分に分割される。

インクリメンタルやイテレーションと呼ばれるものである。

アジャイル開発方法論に分類されるものには、

クリスタル方法論、タイナミックソフトウェア開発、

フィーチャードリブン開発、リーンソフトウェア開発、

スクラム、エクストリームプログラミングがある。




2025年10月5日日曜日

クロニクル MacでC#

1. NETのインストール


こちらから、プラットフォームに合うインストーラーをダウンロードしました。

https://dotnet.microsoft.com/ja-jp/download

今回は、.NET8のSDKにしました。

ダウンロードしたファイルを実行して、全てデフォルトで実行。

無事終了しました。

確認のため、ターミナルで、以下を実行しました。

$dotnet --version
          
8.0.414


2.Hello world 


ターミナルで、作業用のディレクトリを作成する。

$mkdir work
$cd work

C#のコンソールアプリの雛形を作成する。

$dotnet new console

実行してみる

$dotnet run 

Hello, World!

が表示されました。


3.修正してみる


  Program.csを、次のように修正します。

 修正前
    Console.WriteLine("Hello, World!");

 修正後
   using System;
 
          class Program
         {
              static void Main()
            {
                Console.WriteLine("Hello, World!!!");
           }
       }

コマンドプロンプトで、ビルド&実行してみます。


$dotnet build

$dotnet run

Hello, World!!!

が表示されました。修正できているようです。



方法論 DOAの概要

1.概要


・システムを設計する際にデータを中心において設計する方法。

・データはプロセスに比べれば普遍的(変更が少ない)であると考え、

業務プロセスについてもデータを中心に設計することで、変更に強いシステムができる。

・データを決め、そのデータを処理するプロセスを決める、

方法でシステムの分析、設計を行う。

・データの操作が、プログラムごとに重複してしまうことを防止し、

システムの保守効率の向上、データの整合性や一貫性の維持を図る考え方。

2.進め方


まず、データを共有物として設計し、そのデータに基づいて、

システムを設計していく。




2025年10月4日土曜日

擬似コードの文法例

擬似コードの文法例

Input:〇〇


入力や関数の引数などを記述する

Output:〇〇


出力や関数の返り値を記述する


for 変数 = 値1 to 値2  do 
      処理
end for


変数の値を、値1から値2まで、1ずつ増やしながら処理を実行する

while 条件 do
     処理
end while


条件が真の間、処理を実行する

if 条件 then 
   処理1
else 
   処理2
end if 


条件が真ならば、処理1を、真でなければ、処理2を実行する

return 値


関数の返り値として、値を返す

値1 == 値2 (比較演算)


値1と値2が等しければ、真。そうでなければ、偽

値1 != 値2 (比較演算)


値1と値2が等しくなければ、真。そうでなければ、偽

条件1 and 条件2 (論理演算)


条件1と条件2が、ともに真のとき真

条件1 or 条件2 (論理演算)


条件1か、条件2のいずれかが、真のとき真

変数 = 値(代入演算)


変数に値を代入

配列名[添字]


配列の添字番目の要素








2025年10月3日金曜日

木構造

・節点(ノード)を、線(枝、エッジ)で結んでいくもの

・頂上の節点がルート、一番下の節点が葉(リーフ) 

・節点が持つ子の数が、2つ以下のものを、2分木という 

 ・2分木の中で、すべての葉が同じ深さを持ち、

 葉以外のすべての節点について、子の数が2つの2分木を、完全2分木という 

 ・子の値が、親の値よりも、つねに等しいか大きい、という成約があるものを、

 ヒープという

 ・木構造において、左右の節点の数のバランスが取れている(ほぼ同じ)ものを、

 平衡木という 

・平衡木の中で、節点に複数の子のキーを格納するものを、B木という



2025年9月29日月曜日

code smell の例

 コードの重複


長いクラス


長いメソッド


不適切なコメント


単一責務違反


複雑な判定条件


不適切なネーミング







2025年9月28日日曜日

Webのパフォーマンスのテスト/チェック内容の例

 1.ページロードの時間は、想定内か?


2.ネットワークが細い状態でのページのロード時間は?


3.アクセスが、少ない、普通、多い状態でのレスポンスの時間は?


4.データベースのストアードプロシージャやトリガーのパフォーマンスは?


5.データベースへのQueryの実行時間は


6.アプリケーションのロード時間は?


7.アプリケーションに負荷がかかった状態でのレスポンスは?


8.ビーク時のCPUやメモリの負荷は?







バージョン管理システムの用語

リポジトリ

バージョン管理を行うファイルや構成情報を管理する場所。


チェックアプト

リポジトリから編集のためにファイルなどを取り出す。

作業用コピーがつくられる。


チェックイン

変更をリポジトリに保存する。


更新

リポジトリに(他の人が)加えた変更を作業用コピーに反映させる。


コンフリクト

同じコードの同じ部分を、異なる人が、更新してしまう。


ロック

指定したファイルを、他の人が変更できないようにする。









Webエンジニアリング

WEBアプリケーションの仕様化と分析


仕様化とは、次の問いに答えること 

 ・Webアプリケーションが必要となる主要なモチベーションは、何か? 

 ・誰が、Webアプリケーションを必要としているか? 

 ・誰が、Webアプリケーションを使うか? 

 これを基に、目標を設定する。 

 目標には、次が含まれる。 

 ・どんな情報やコンテンツを提供するか 

 ・Web App で何ができるのか 


 分析は、要件を定義するものであるが、Web特融の点としては、以下がある。

1.コンテンツの分析


 Webアプリケーションで提供するコンテンツを特定する  データモデリング手法も利用できる。

2.インタラクション分析


 ユーザとのかかわり合いを分析する  ユースケースを利用できる。

3.機能分析


  ユースケースシナリオを作り、オペレーションや機能を特定する。

4.コンフィグレーション分析


 Webアプリケーションの環境やインフラを定義する。



 

Webアプリケーションの設計


アーキテクチャ・デザイン


 Webベースのシステムのアーキテクチャデザインは、Webのコンテンツの構造を定義する。

ナビゲーションのデザイン


異なるロールのユーザに対して、アクセスできるコンテンツが異なる場合がある。 

その時、個々のロールに応じたナビゲーションを決定する必要がある。 

 また、ナビゲーションの手段として、テキストベースのリンク、アイコン、ボタン、画像等から適切なものを選択する。 

また、ボタンが押せる、押せないを、ボタンの形状で変える、テキストベースのリンクの色で変更する等からも選択する。 

 これ以外にも、サイトマップの利用、インデックス、サーチエンジン、helpの利用等を考慮する必要がある。

 

インターフェースのデザイン


インターフェースのデザインに関していは、次のようなものがある。

 ・サーバエラーを、利用者に見せない 

 ・レスポンスを保つため、テキストや画像の両をしぼる 

 ・スクロールを少なくする 

 ・メニュー、ナビゲーション、ヘッダー、フッターは、統一し、すべてのページで利用可能とする 

 ・意図が伝わらないアイコン、画像等はさける



2025年9月27日土曜日

クロニクル GCEでhttpサーバをあげてみる

 サーバは、作成済みとします。今回は、Red Hat Enterprise Linux release 10.0

です。


1.Apacheをインストール


sudo yum install -y httpd


2.サービスを起動する


sudo systemctl start httpd


3.ファイアウォールで、HTTP / HTTPSを許可


許可してリロードします。


sudo firewall-cmd --permanent --add-service=http

sudo firewall-cmd --permanent --add-service=https

sudo firewall-cmd --reload


4,サーバのあるVPCのファイアウォールは、空いているとします。


5.ブラウザでアクセスしてみる。


http://<サーバのIP>


でアクセスすると、


Test Page


が表示されました。






2025年9月25日木曜日

ソフトウェア 設計の原則(SOLID原則)

SRP:単一責任の原則


クラスを変更する理由は、1つだけ。

 

OCP:オープン・クローズドの原則


ソフトウェアの構成要素は、拡張に対して開いていて、 修正に対して、閉じていなければ、ならない。

 

ISP:インターフェース分離の原則


クライアントが利用しないメソッドへの依存を強制しては、 ならない。

 

DIP:依存関係逆転の原則


・上位のモジュールは、買いのモジュールに依存しては、ならない。  どちらも「抽象」に依存すべき 

 ・抽象は、実装の詳細に依存しては、ならない。  実装の詳細が、抽象に依存すべき



enabling PaaS application using Twelve-Factor App

 公開されている


enabling PaaS application using Twelve-Factor App

のキモの部分を読んで、勉強してみたいと思います。

 

概要

クラウドコンピューティングのメリットを得るためには、

クラウドネイティブの原則に従う必要がある。

この論文では、伝統的なJavaのエンタープライズ・

アプリケーションを、クラウドネイティブ・

アプリケーションへ変換したことを対象としている。

Docker 、Kubernate、OpenShift などのクラウド関連技術、

Jenkisなどの自動化技術を利用した。

Twelve-Factor Appの方法とクラウド・ネイティブの原則に

従った。

 

イントロダクション

クラウドコンピュータ上のアプリケーションは、伝統的な

アプリケーションとは異なる。

クラウドの便益を得るための特徴を持っている。

自動化されたプラットフォーム、インフラやネットワークの

ソフトウェア化、マイグレーション、異なるクラウドインフラでの

相互運用性などである。

このような種類のアプリケーションは、クラウドネイティブ・

アプリケーションと呼ばれる。



1.1 背景

 伝統的なエンタープライズ・アプリケーションの中で、

最も有名なものに、Java EEがある。

 Java EEは、企業の環境やインターネット環境で、

 分散システムを構築するために利用される。

 

1.2 問題

Javaのエンタープライズ・アプリケーションを、クラウドへ

どう、マイグレーションするか?

Twelve-Factor Appは、PaaSのアプリケーションを構築する際に、

よく知られた方法である。そして、クラウドネイティブの

原則に従うことで、クラウドコンピューティングのメリットを得る

ことができる。 

このプロジェクトは、伝統的なJavaアプリケーションを、

 クラウドネイティブの原則、Twelve-Factor Appの方法に従って、

クラウドネイティブ・アプリケーションへ変換したもの。

 

2.1.1 JavaEE

Javaは、汎用的なコンピュータ言語で、並列処理、

クラスベース、オブジェクト指向の特徴を持つ。

大規模な分散システムでは、JavaEEが利用される。 

Javaは、write once , run anywhere と言われる。

JVMを利用することで、コンパイルされたJavaのコードは、

再コンパイルなしで、別のプラットフォームでも、動く。

JavaEEのコードは、bytecode へ変換され、

 Web Application Archive(WAR)や、

Java Archive(JAR)などへパッケージングされる。

WAR あるいは、JARファイルは、必要となるすべてのクラスファイルを

含む。

WARやJARファイルは、Tomcatのようなアプリケーションコンテナへ

deployされる。 

これらのアプリケーションコンテナは、HTTPSやJDBCなどの

機能を提供する。



ソフトウエア開発では、次のような環境が利用される。

1.Development 

開発者用の環境

2.Integration 

すべての開発者がコードをコミットする

3.Staging

Production環境をシミュレートする

4.Production

アプリケーションが提供される環境

 

クラウドコンピューティング

クラウドコンピューティングの利点としては、次がある。

・無限のリソースを、オンデマンドで調達できる。

・利用者の増加に対応することができる。

・短期間だけ必要なコンピュータリソースを準備することが容易

・巨大なデータセンターを利用することでの規模の経済性

・オペレーションが単純になる

 

SaaS と Cloud-Native Application 

クラウドコンピューティングのメリットを得るためには、

アプリケーションもスケーラビリティ、保守性、ポータビリティなどに

対応する必要がある。

これに対応したものが、Cloud-Native Application 。

次の原則を満たすものである。

・自動化されたプラットフォーム上で稼働する

・インフラとネットワークをソフトウェア化する

・異なるクラウド上での相互運用性

 

Twelve-Factor Appは、SaaSを作るときのベストプラクティス。

Twelve-Factorを使って作ったアプリケーションには、

以下の特徴がある。

・セットアップの自動化のために、明示的な宣言を使用して、

ディプロイのための時間やコストを最小化している。

・OSの以下と、クリーンな関係で、実行環境のポータビリティ

を最大化している。

・クラウド環境でのディプロイに最適化。

・開発と製品の間を最適化。継続的ディプロイで、

アジリティを最大化している。

・ ツールやアーキテクチャ、開発のプラクティスの

重大な変更を伴わないスケールアップ。



Twelve-Factor Appは、次のもの。

 1. コードベース

1つのアプリケーションは、1つのリポジトリに対応し、

1つのリポジトリには、異なる環境のソース等が含まれる。

これは、開発者の生産性に関して有効である。

リポジトリには、アプリケーションをビルドして実行する

ために必要なすべてのソース、コンフィグファイルなどが含まれる。

 

2.依存性

アプリケーションを実行するためには、宣言を明示する必要がある。

バージョンを指定するころで、互換性の問題にも対処する。



3.設定

設定は、コードに依存するもの。一方、コードは設定に依存しない。

環境によって異なる設定は、アプリケーションの外部から動的に変更する。

設定は、そのためのファイルや環境変数などを利用する



4.Backing Service

Backing Serviceとは、アプリケーションがアクセスする

データベースや外部のアプリケーションのこと。

これらは、アプリケーションとは疎結合とする。

つまり、アプリケーションに影響を与えることなく、

新しいインスタンスに置き換えることができる。



5.Build , Release , Run

BuildとReleaseとRunは、別のステップとして実行する。



6.プロセス

アプリケーションは、ステートレスとして実行する。

ステートは、外部のデータベースへ保管する。



7.Port Binding 

サービスは、Port Bindingで公開する。

アプリケーションは、その機能をネットワークポートを通じて、

提供する。



8.Concurrency 

アプリケーションのスケール性を保証する。

アプリケーションは、水平、垂直のスケーリングができる。



9.Disposability

アプリケーションは、クラウド上で、restartされる。

リソースに対する接続を適切にcloseすることなど。

適切にシャットダウン、スタートアップできること。



10.Dev/prod Porting 

環境間の差異を最小限にすること



11.Logs

ロギングは、アプリケーションのパフォーマンスに

大きな影響をもたらす。



12.管理プロセス

管理のためのプロセスは、独立した短いプロセスとする。

管理のためのタスクは、デバグやトラブルシューティングの

ために必要となるものである。



クラウドテクノロジー

Dockerは、容易な相互運用性やマイグレーションを実現するために利用される。

Open Shitは、kubernateに基づき、弾力性のあるプラットフォームを

提供するために利用しリソースのプロビジョニングを行う。

Dockerも、Open Shiftも、インフラのソフトウェア化のために利用される。


コンテナ:Docker

クラウドコンピューティングでは、リソースはシャアされる。

仮想化のためには、virtual machine とコンテナの2つの技術が利用される。

virtual machine は、物理的なハードウエアの上にパイパーバイザーと呼ばれる

ソフトウェアがあり、パイパーバイザーが物理的なリソースを抽象化する。

この技術は、1つのハードウエアの上へ複数の環境を作ることができる。

この環境のことを、virtual machine といい、IaaSを提供するテクノロジーとして、

提供される。このテクノロジーにも欠点がある。

各virtual machine は、それぞれOSのイメージを持ち、メモリやストレージの

オーバヘッドとなる。




2025年9月24日水曜日

MVVM

 Model , View , View Model (MVVM pattern)は、次のような分割である。


Model     データを保持するだけで、ビジネスロジックは持たない

ViewModel   ModelとViewをつなぐ

View             フォーマット化されたデータを保持する

責務は、次のとおり。

(1) Model 

・オブジェクトを保持する

・オブジェクトの変更を通知する

・データのバリデーション

(2) View 

レイアウト

(3) ViewModel 

・Viewにデータを提供する

・ロジックを提供する





2025年9月23日火曜日

コードのチューニングテクニック


・評価( if  , case)は、真になる可能性が最も高いものが、最初に実行されるようにする


・最も回数の多いループを、内側へもってくる


・配列の次元を削減する




Cloud Native Software Engineering

公開されている

Cloud Native Software Engineering

のキモの部分を読んで勉強してみたいと思います。


概要

クラウドネイティブなアプリケーションに関しての

ソフトウェアエンジニアリングのプラクティスは、少ない。

クラウドネイティブなアプリケーションは、

クラウドプラットフォーム向けに設計、実装され、

ディプロイされるソフトウエアのこと。

この論文は、クラウドネイティブなソフトウェアエンジニアリングの

概要を目指す。


クラウドネイティブ・コンピューティングとは

次の特徴を持っている。

Well Architected System

ソフトウェアエンジニアリングのベストプラクティスを

提供するだけではなく、機能、非機能をクラウドが提供する。

たとえば、認証の実現、セキュリティ要件への対応、

信頼性や、スケーラビリティへの対応などである。


-- つづきます --

2025年9月22日月曜日

Rapid application development(RAD) : an empirical review

 公開されている

Rapid application development(RAD) : an empirical review

のキモ部分を読んで、RADを勉強してみたいと思います。


イントロ


Rapid application development(RAD) は、James Martin が提唱したもの。

Martin は、RADのキーとなる目標に関して、

高品質のシステムを高速にローコストで開発する

としている。

RADの方法論の1つとして、

dynamic systems development method (DSDM)がある。

DSDMは、次の5つのエリアをカバーしている。


(1) Model of development process

DSDMは、イテレイディブで、インクリメンタルなモデルである。


(2) Set of techniques

DSDMは、joint requirements planning work shop や

joint application design workshop 、タイムボックスなどの

概念を提唱しているが、ER図など伝統的な方法も利用する。


(3) Documentation methods


(4) 哲学


RADのコンポーネントには、次がある。


Joint application design(JAD)


RADは、4~8人の小さなチームで行う。

利用者と開発者から成り立っており、意思決定の権限がある。


Joint application development workshop(JAD)


要求の引き出しなどで広く使われる。

このワークショップの中で、主要なユーザ、クライアント、開発者が

ファシリテーターの元、システムのスコープやビジネス要求を決めていく。

開発者は、3~5日でビジネス要求をドキュメント化することが

期待される。


Rapid of development


RADのプロジェクトは、比較的、小規模短期間である。

一般的には、2~6か月が普通であると言われる。


Clean rooms


JADのworkshopは、通常のビジネスや開発の現場から離れた

クリーンルームで行う。クリーンルームは、通常の仕事からは離れ、

ポストイットのような必要なものが揃った場所である。

ここで問題解決に集中する。


Incremental prototyping


プロトタイプは、システムをインクリメンタルに構築していく方法。

開発者は、最初の調査の直後、モデルを作ってユーザへデモを行う。

開発者とユーザーは、プロトタイプについて、議論し、

改善に合意する。

RADプロジェクトでは、この検査-議論-改善のプロセスが、

3回は、繰り返される。


プロトタイプは、要求の収集、アプリケーションのデザイン、

アプリケーションのBuild、テストなど、どの工程でも利用できる。

RADは、インタラクティブな要素が多く、複雑でないプロジェクト

で利用されている。


Dynamic System development method(DSDM)


DSDMは、RADの方法論の1つである。


DSDM Principle


1.ユーザの参加は必須


2.DSDMのチームは、意思決定を委譲されている






(つづきます)


2025年9月21日日曜日

テスト技法

同値分析法


同じ結果となる入力の範囲を同値クラスとして、

同値クラスの代表値のみをテストする。


境界値分析法


同値クラスの境界の上限や下限などをテストする。


ディシジョンテーブル法


テスト対象をディシジョンテーブルをもとに作成し、

漏れを防ぐ。







バケットソート

 (3,6,1)を昇順にソートする例です。


1. (3.6.1)の最大値を見つける。

 この場合は、6


2.1の最大値分の配列を用意する。

 例えば、a[6]とする。


3.a[6]の各要素を初期化する。

 例えば、0とする。


4.(3.6.1)の最初の要素から次を繰り返す。


5.最初の要素(3)を、その添え字にもつa[6]の配列に、

 その値を入れる。

    a[3] = 3 


6.次の要素(6)を、その添え字にもつa[6]の配列に、

 その値を入れる。

 a[6] = 6


7.a[6]の配列の中で、初期値でないものを順に取り出すと、

 ソートされている。





2025年9月20日土曜日

A Comparison of User Experience in Progressive Web Apps and Cross-platform Framework Apps

 公開されている

A Comparison of User Experience in Progressive Web Apps and Cross-platform 

Framework Apps

のキモ部分を読んで、勉強してみたいと思います。


概要

モバイルアプリケーションでは、クラスプラットフォームでの開発が進んでいる。

クロスプラットフォームのフレームワークは、数多くある。

Progressive Web Appでのアプローチは、数好きない。

Progressive Web Appは、オフラインでも利用できるもので、

ブラウザで動作することで、クロスプラットフォームを実現する。

しかし、利用者には、普通のアプリに見える。


この年休は、クロスプラットフォームとProgressive Web Appでの

UXの違いを、パフォーマンス、機能評価、外観の違いから比較する。

また、起動時間、バッテリーの使用、アプリのサイズ、機能のロード時間

を測定した。そして、カメラ、シェア、通知、認証などの見た目や機能を

評価した。

評価のため、2つのアプリケーションを作成した。

Progressive Web Appは、Reactで、クロスプラットフォームは、

React Nativeで作成した。両方のアプリが同じ機能を実装する。

この2つのパフォーマンス、外観、機能を、AndroidとiOSで比較する。

結果、低スペックの端末では、React Nativeのアプリが、

Progressive Web Appsを上回り、見た目や機能性も、より、

ネイティブアプリに近いことが示された。

ただし、その差は小さい場合が多く、クロスプラットフォーム開発においては、

Progressive Web Appも有効な選択肢となる。

しかし、伝統的なWeb appには、いくつか制限がある。

ブラウザで動かすこととなるため、スクリーンには、

アドレスバーが現れる。

また、ハードウェアへのアクセス、ハードウェアが提供する機能、

ローカルストレージの利用、通知などに制約がある。

 Progressive Web Apps(PWAs)は、これらの制限を克服するための機能を

Web appに導入するもの。

PWAは、オフラインでも利用できる。

Webからインストールでき、普通のアプリのように動作するが、

app storeは、必要ない。

PWAでクロスプラットフォームのappを開発する時は、OSが提供する

いくつかの機能とUIを使うことができるため、

ネイティブアプリのような外観が実現できる。

この研究は、ReactでつくったPWAと、React Nativeでつくった

アプリとのUXの比較である。


問題

マルチプラットフォームのアプリを開発する場合、PWAを利用するか、

クロスプラットフォームのフレームワークを利用するかの選択肢がある。

この選択肢は、1つのcodebaseで、複数のプラットフォームへ対応する

ニーズから出ている。

この研究のリサーチクエスチョンは、次である。

RQ1:Reactで作られたPWAsとReact Nativeで作られたアプリで、

起動時間、バッテリーの利用、アプリのサイズ、機能のロード時間が、

どのように異なるか?

起動時間、バッテリーの利用、アプリのサイズなどのパフォーマンスは、

UXにとって重要である。ユーザ入力後のレスポンスタイムも重要である。

RQ2:Reactで作られたPWAsとReact Nativeで作られたアプリは、

機能や見た目がどう異なってくるのか。

OSが提供するUIと似たものになれば、UXに大きなインパクトを与える。


目的

PWAとクロスプラットフォームのappの間のUXの差異には、どのような

要素があるかを評価する。

1.Reactを使ったPWAとReact Nativeを使った、同じシンプルな

 アプリを作る。

2.2つのアプリから、パフォーマンス、外観、機能に関するデータを得る。

3.2つのアプリの類似点や差異を抽出する。


モバイル開発

Native 

ネイティブアプリを開発する伝統的な方法は、OSに合わせた手法である。

OS特有のSDKや言語を利用する。OSが提供するAPIを利用して、

OSの機能を直接利用する。

これにより、Look&Feelは、一般性があるものとなる。

それぞれのOSは、独自のAPIを持つため、それぞれのOSをターゲットとした、

codebaseが必要となる。

Androidのアプリケーションは、Androidのフレームワークを利用して、

Javaあるいは、kotlinでプログラムされる。

一方iOSでは、Appleのフレームワークを利用し、

objective-cあるいは、swiftでプログラミングされる。

異なるSDKやフレームワークに対応した複数のcodebaseを開発、維持していくのは、

コスト高につながる。

そこに1つのcodebaseで複数のプラットフォームに対応できる

クロスプラットフォーム開発のメリットがある。


クロスプラットフォーム開発

クロスプラットフォーム開発は、1つのアプリケーションで、

複数のプラットフォームに対応するもの。

複数のプラットフォームに対して、同一のcode baseで対応することができる。

クロスプラットフォーム用のフレームワークを利用する。

フレームワークは、各ブラットフォームのAPIをラップする抽象化レイヤを作る。

この抽象化レイアが、プラットフォームの違いを吸収する。


Web App

単一のcode baseで、クロスプラットフォームを実現することは、

モバイルデバイス上のWebブラウザでwebアプリを実行することで、

達成できる。

このアプリは、HTML、CSS、JavaScriptで作られ、

モバイルデバイス用に最適化されている。

このアプローチには、欠点もある。ブラウザーの

アドレスバーなどに大きな面積をとられること、

デバイスやシステムが提供する機能へのアクセスに制限があること、

オフラインでは利用できないこと、である。


Progressive Web Apps

PWAsは、webアプリケーションで、Web APIを利用することで、

アプリのようなUIを実現するもの。

PWAは、ネイティブアプリの利点と、Webアプリの利点の両方を実現するもの。

インストールでき、オフラインでも利用でき、デバイスやシステムの機能に

アクセスできる。webを通じて得ることができ、アプリストアが必要ない。

単一のcode baseで、いくつかのプラットフォーム上で稼働する。

webサイト同様、PWAはURLを通じて、アクセスできる。

app manifestが、インストールに必要な情報を提供する。

インストールされると、PWAは他のアプリと同じように見える。

アイコンがスクリーン上に現れ、フルスクリーンで開き、

アプリケーションのスイッチャ上に現れる。

PWAは、ブラウザーで動いてはいるものの、ユーザには、

他のアプリと変わりない。

Service workerを使うことで、PWAは、オフラインでも利用できる。

また、push通知なども実現できる。

PWAのインストール

PWAは、ブラウザーからインストールすることができ、

アプリストアが必要ない。

ブラウザでURLへアクセすることで、PWAにアクセスできる。

そして、普通のアプリとして利用できる。

App Manifest

PWAのエッセンシャルな部分に、app manifestがある。

app manifestは、JSON形式でアプリの外観と振る舞いを記述するもの。

アプリの名前、アイコンなどを指定する。

React

Reactは、Webアプリを開発するオープンソースのJavaScriptのライブラリ。

UI、ロジック、外観についてのコンポーネントを扱う。

Reactのアプリケーションを作るためには、React projectのセットアップツール

を利用する。そこで使われるテンプレートは、PWAsをサポートする。

App Manifestファイルと、キャッシュのロジックを実装する

サービスワーカーfileを含む。

デフォルトのままでも、静的なアセットはキャッシュされ、PWAが

オフラインでも利用できるようになる。

React Native and Expo

React Nativeは、オープンソースのプラットフォーム

開発用のフレームワーク。

Reactに基礎を置き、クロスプラットフォームのために、

JavaScriptを利用する。

React Nativeは、アプリのUIや機能を作るためのコンポーネントと、

APIを含む。開発者は、コンポーネントやAPIをJavaScriptで利用し、

デバイスでは、JavaScriptがネイティブプラットフォームにアクセスする。

この方法で、プラットフォームSDKをコンポーネントやAPIに隠蔽する。

React Nativeプロジェクトでは、Expoという追加のプラットフォームが、

活用できる。

Expoの一部に、ExpoSDKがあり、React Nativeに含まれないコンポーネント

ライブラリを活用できる。

--つづきます---








2025年9月16日火曜日

Understanding the Correlation between Code Smells And Software Bugs

 公開されている

Understanding the Correlation between Code Smells And Software Bugs

のキモの部分を読んで勉強してみたいと思います。


概要

バグ予測は、ソフトウェアの品質保証を助ける。

ソフトウェアのテストに必要なeffortが予測できるためである。

アンチパターンとcode smellは、コード品質に大きな影響を持つと言われる。

リファクタリングは、これらアンチパターンの負のインパクトを取り除く

ものである。

この論文では、code smellの影響とバグの重大度に関するもの。

BIRT、AspectJ、SWTのプロジェクトの複数のバージョンから分析する。

異なるcode smellとバグの重大度の間の相関関係を分析した。


イントロ

コード中のエラーは、重大度に基づく優先度順に修正する必要がある。

ソフトウェア開発にかかわる費用の80%が、バグFixに使われている、

という報告もある。

このコストを削減するため、多くのバグ予測モデルが提案された。

これらのモデルは、ソフトウェアシステム中のどこにバグばあるかを、

予測するものである。

バグ予測モデルの多くは、コードの複雑度や

プロセス(code churn)などのメトリクスが利用される。

開発者はコードの中にcode smellを入れてしまうことがある。

こららのアンチパターンやcode smellは、システムの機能には

影響を与えないが、保守を困難にする。

code smellは、また、バグを生む可能性がある。

過去の研究では、code smellを含むclassは、そうでない

classに比較して、バグ proneであった。

バグを減らすためには、code smellを減らす必要がある。

これを行うのが、リファクタリングやコードの再構築である。

アンチパターンやcode smellを削減するリファクタリングや

再構築のツールは、数多くある。

code smellとdefectの間の関係がわかることには、意味がある。

そこで、code smellとバグの間の関係を、wekaが提供する

機械学習のアルゴリズムで測定することに挑戦した。

データは、BIRI、SWT、AspectJ の3つのオープンソースから

抽出した。

次のリサーチクエスチョンに応えるものである。

RQ1:code smellは、バグの重大度と関係があるのか?

code smellのいくつかは、他のcode smellより重大度に

インパクトを与えるものとした。

RQ2:機械学習のアルゴリズムで更なる情報がわかるか

code smellは、重大度に影響するだけではなく、

バグの数にも影響した。


方法

code smellの発見器では、次のようなアンチバターンが発見できる。

Cyclic Dependency

2つ以上のモジュールが、直接あるいは、非直接的にでも、

お互いに依存している。


Blob Class

すべての機能を持ち、すべての責務を持つClass。


God Class

多すぎる数のクラスをコントロールする。

大きすぎるロジックを持つクラス。


Data Class

データと、そのセッター/ゲッターのみを持つクラス。


Schizophrenic Class

関連しない/利用されないpublic methodを持つクラス。


Refused ParantBequest

サブクラスで、親クラスから継承したメソッドや、

プロパティの一部しか利用していないクラス。


-- つづきます。--

クロニクル MacでIntelliJ

 1. IntelliJ IDEA Community Editionのダウンロードとインストール 1-1.ダウンロード: Mac用のCommunity Edition(無料版)を選択し、**.dmg**ファイルをダウンロードします。 ここからダウンロードしました。 https:...