さくらのクラウドを使う

さくらのクラウドでこんな構成を作りたい。
さくらのクラウドのドキュメントがわかりやすいので、これを読めば分かると思う。

さくらのクラウド ドキュメント

あとは、チュートリアル形式のものがあるので、この通りにやれば作れる。

スイッチを使ってローカルネットワークを構築してみよう – 「楽しいさくらのクラウド」(5) | さくらのナレッジ

ローカルネットワークを構築しよう｜teratail新年度応援企画

たぶん忘れるので残す。

最初の状態。サーバを1つ作成。ここからDBを作りつなぐ。

共有セグメントはパブリックで外部とつながっている。

DBをつくるにはスイッチが必要なので、スイッチを作る。

スイッチのトポロジからネットワークがどう繋がっているのか見える。今はスイッチの設定をしていないので、どこにもつながっていない。

DBを作る。

サーバのNICに作成したスイッチを追加。

現在のネットワークはこうなった。

サーバのIPアドレスを設定する。黒丸をクリックするとIPアドレスを編集できる。

・ethの設定をする

 サーバを起動。

ip addr show

eth0は共有セグメント、eth1がローカルネットワーク。

eth1に192.168.0.1を設定する。

nmcli connection add type ethernet con-name local-eth1 ifname eth1 ip4 192.168.0.1/24 gw4 192.168.0.254

・ssh接続したターミナルからDBに入る

sudo yum install postgresql

MariaDBの場合は、mariadbをインストール。

コマンド例を入力、DB作成時のパスワードを入力すれば、DBにログインできる。

ネットワークの知識がなさすぎて、スイッチについてはさっぱり理解していない。

マスタリングTCP/IPを読む時が来たか・・・。

■

考えすぎても先に進まないから作りはじめたいけど､何も考えずに作りはじめると失敗するんだよなぁ｡先を見通して作るって難しいなぁ｡

『Head First オブジェクト指向設計』第2章

第2章　要件収集

この章で学ぶこと

素晴らしいソフトウェアへの第1歩は、顧客が必要としている処理の実行。
顧客の真の必要性をどのように把握するのか？顧客自身が真の必要性に気づいていない場合､顧客にどうやって気づかせればよいのか？
この章では、顧客が本当に要求したい内容を実現することによって、顧客を満足させる方法を学ぶ。

要件とは正確には何なのか

システムが正しく動作するために実行しなければいけない特定の事柄です。

1. 「システム」とは、現在取り組んでいる完全なアプリケーションまたはプロジェクト。
2. 「システムが正しく動作する」かを確認するのは顧客。要件を取り汲み損ねた場合、顧客が要望を出すのを忘れた場合も、システムは正しく動作しているとは言えない。
3. 「実行しなければいけない」ことは顧客がシステムの実行内容として思いつくあらゆる事柄。
4. 「特定の事柄」とは、要件は通常1つの事柄であり、要件が実際に満たされているかを確認するためにその事柄をテストできる。

顧客へのヒアリング

システムが実行しなければいけないこと(What)に注意する。
システムがどのように実現するか(How)は後で考える。現時点では、システムがすべき内容を確認するだけにする。

顧客の要件を収集することは最も困難なことの一つ。本当にやりたいことが何なのか気づいていない顧客も多い。
要件の漏れを防ぎシステムがすべき処理を正確に判断するためには、何が必要であるかを考えさせる質問を顧客に対して投げかける必要がある。

要件の構成要素

顧客が要望する以外の多くのことから要件は構成される。
要件の良い集合は、顧客が指示した内容だけで構成されるのではなく、予想外の環境でもシステムを動作させるために必要な内容も含まれる。
参考:牛乳卵問題に学ぶ、要望 と 要件定義 と 設計 と 実装 の違い

アプリケーションは顧客が望むように動作しなければいけない。そのために開発者が思い描くアプリケーションの使用方法と異なることもある。
開発者はシステムが実行しなければいけない内容、顧客がシステムを使用する方法を理解しなければいけない。

ユースケース

ユースケースは、特定の顧客目標を達成するためにシステムが実行する内容を記述する。

顧客目標がユースケースの要。システムは顧客目標の達成に役立てなければいけない。
単一のユースケースは、単一の目標に着目する。
犬用ドアの製作の例の単一の目標は、ベッドからでなくても犬を外に出せるようにすること。
ユーザはシステムの外部に位置し、システムの一部とはみなされない。

ユースケース:
ユースケースは、新規システムまたはソフトウェア変更における潜在的な要件を把握するための技法。ユースケースごとに、1つまたは複数のシナリオが存在し、特定の目標を達成するために、エンドユーザまたは他システムとの間で相互作用する方法が伝達される。

参考:ユースケース図の作成【チュートリアル】 - 分析編 -オブジェクトの広場

よいユースケースの3つの要素

1. システムに対する明確な価値
   顧客の目標(この場合リモコンで寝ながらに犬用のドアの開閉をできるようにする)に役立たないユースケースは無意味。

2. 明確な開始条件と終了条件
   プロセスを開始し完了する条件がどこかに存在しなければいけない。

3. 外部起動者
   どのシステムも、システムの外にいる、外部起動者によって開始されなければいけない。人以外の場合もある。

ユースケースまとめ

• ユースケースの目的はシステムが実行すべき内容を理解すること。
• 良い要件が存在するようにするために、システムのユースケースを作成する。
• システムの目標ごとに1つのユースケースが存在する。システムの目標が増えれば、ユースケースも増える。
• どのようにプログラミングするかといった詳細は扱わない。
• ユースケースを作成することで、不完全または欠けていた要件が明らかになり、要件を追加することができる。
• あらゆるユースケースを可能とする要件一覧が、要件の良い集合である。
• 必要な機能がわからなければコードは書けない。