アジャイル開発プロセスの手順

開発プロセス

  • 業務の整理(アクセシビティによるビジネスプロセス分析)

  • 機能の洗い出し(ユースケースの洗い出し)

  • シナリオの作成(ストーリーのブレイクダウン)

  • TDDによる開発

    • To-Doリストの作成
    • テストコードの作成
      • まずは赤でエラー
    • ターゲットの作成

業務の整理

アジャイル開発では、ストーリーという単位でソフトウェアの要件を決めていく。

まず、

  • 顧客が求める機能をストーリーカードに書いていく。
  • そのストーリーに対して、エンジニアが工数を見積もり、開発を進めていく。

要件をだすためには、
業務フローを考えて、業務を整理した上で、そこに必要な機能を考えていく。

UMLのアクティビティ図を作成したりして、業務フローを書く。 ユーザーなどのエンジニアでない人でも、理解が用意にできるように。

よく聞くUMLって何? - Qiita

機能の洗い出し(ユースケースの洗い出し)

ソフトウェアはユーザーが使うもの。
業務のどこかでアクティビティがコンピュータ化されたもの。 アクティビティの中からアクションという動作から機能が起動される。 UMLではこの機能のことを「ユースケース」と呼ぶ。

ユースケースの説明

ユースケースとは、システムが外部に提供する機能です。
システムのユーザーが認識できるレベルの機能であり、システム内部の詳細な機能は表現しない。

機能の詳細

ユースケースやストーリーは、あくまで概要程度のことしか書かないので、 内容を把握するために詳細を記述する必要がある。
高速アジャイル開発では、顧客から詳細を聞いて、ドキュメントとして残しません。
大規模な開発にも対応するには、ユースケース記述を記述する。 ユースケース記述では、機能の詳細だけではなく、この機能が使われる条件等も書いていきます。
とりあえず、簡素な書き方でもOK。

シナリオからテストへ

シナリオからアジャイル開発プロセステスト駆動開発へとつなげていく。

テスト駆動開発とは、

テストを先に書いて、その後にターゲットのコードを書いていく手法。
テストを書きながらインターフェースを確定していき、内部構造は後から設計していく。
設計と同時にコーディングをしていくので、設計書などは残さずに、プログラムコードだけが成果物になるのがほとんど。

TDDは、
テストをはじめに作成し、それをもとにプログラムを設計し開発すること。
このテストは、あくまでソフトウェア開発のためのテストで、品質やパフォーマンスを検証する目的ではない。

従来はプログラムを先に作成した後に、テストを行いプログラムの検証をしていた。 現在主流になっているTDDでは、実際のプログラムコードより先にテストコードを作成する。この方法を「テストファースト」と呼ぶ。

テストを作成するということは、はじめにインターフェースを考えることになる。
呼び出すオブジェクトへのインターフェースを、テストを通じて設計する。
その後で、インターフェースの先のオブジェクトの構造を実装していく。

テストと実際のターゲットクラスのコードの両方が同時に作成され、テストコードは常に実行されます。このことで、バグのないコードを保ちつつ、ソフトウェアを開発していく。





GitHubのSSH keysが消えた


GitHub で clone しようとしたら、

$ git clone git@github.com:***/***.git
Cloning into '***'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.



は?



なぜかできなかった。
つい先日まではできたのに。

原因はわからないけど、どうやらこの辺かなあ。

magai.hateblo.jp


久しぶりでできなかったので、メンターさんにサクッと教えてもらった。


SSH公開キーを生成

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/***/.ssh/id_rsa):
/Users/***/.ssh/id_rsa already exists.
Overwrite (y/n)? ^C


中身を確認

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtBhfyZOPlJTvbQy+XRErXqfsKna9c/9Ix85hezflNPPW6GivQ68Y4PAZdsBS49scuRLHaUhWAXJ3CIXO2ZW9nGJ1PXeis4rmpuAUA302kUtL08R1nngYGTcpe2D2Fs3x6GOcbYOcDNFqVDzaESIMXT/7tu+xXhxYRqLWHgfXWh2vZFRrCZsaoPEyGT4cMKAnZYYlUspEpd1N1HtyyyUBt7EaGe3/gsDvtC45EHB7IkPfdtKwZVbVm/0zAm5AjBAU3Vztyaxq9mh5IomjsFLF6H5cBMpTxFZAMhIfv49vfr82OxBm3Csa08A5hzKEOg9tceCebaHbvRqD5XP6C9bth ***@MacBook-Pro.local


出力をまるっとコピー

$ cat ~/.ssh/id_rsa.pub | pbcopy


Githubに登録

f:id:tobibako45:20190318102208p:plain


おそるおそる

$ git clone git@github.com:***/***.git
Cloning into '***'...
remote: Enumerating objects: 94, done.
remote: Counting objects: 100% (94/94), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 94 (delta 6), reused 90 (delta 6), pack-reused 0
Receiving objects: 100% (94/94), 22.89 KiB | 1.76 MiB/s, done.
Resolving deltas: 100% (6/6), done.



できたできた





「プロになるためのWeb技術入門」を読んだ。Webサーバとアプリケーションサーバ

Webサーバ

Apache、nginx 、IISとか。

何してる?

webサーバとアプリケーションサーバを連携させる場合、
通常のHTMLやCSS、JS、画像、動画など、静的コンテンツのみで構成されるページはwebサーバ上に配置し、
動的な処理が必要な場合にアプリケーションサーバへリクエストを送り、受け取った結果をWebブラウザに返す。


アプリケーションサーバ

Javaアプリケーションサーバ
TomcatGlassFish

Ruby on Rails環境のアプリケーションサーバ
Unicorn、Thin、Rainbows、Puma、

何してる?

アプリケーションサーバはWebサーバから受け取ったリクエストをもとに、JavaphpRubyなどを実行し、Webサーバに結果を返す。

参考: Rails開発におけるwebサーバーとアプリケーションサーバーの違い(翻訳) - Qiita

まとめると

簡単にいうと、
HTTPリクエストをいったん、webサーバが窓口となって受け取り、URL内のパスによってはアプリケーションサーバへの処理をお願いしてしまおうということ。


webサーバとアプリケーションサーバの分担

一般的にwebサーバより、アプリケーションサーバの方が仕事量が多くなる。
それは、webサーバはHTTPリクエストでしてされたファイルをWebブラウザに返すだけでよいが、アプリケーションサーバでは、様々な処理を行うため。

これらの異なるノードに配置すると、軽い処理で回数の多い静的コンテンツのリクエストはwebサーバに、回数が少なく処理の思い動的コンテンツへのリクエストはアプリケーションサーバへと、異なる性格のリクエストをうまく分担できる。


ん?PHPアプリケーションサーバないの?

Apacheにはモジュールを追加することでアプリケーションサーバの役割を持てるようになります。
まだちゃんと理解してないが、mod_php というモジュールを使って、 「Apache のプロセス内で PHP を処理する」みたいな感じで理解した。 それだけではないようだけど。

参考:PHP - 「Apache」はアプリケーションサーバーとしての機能もあるのでしょうか?|teratail





「プロになるためのWeb技術入門」を読んだ。CookieとSession

HTTPはステートレスなプロトコル

httpは状態を持てない。

なら、どうやってログイン状態とかを記憶してるのか?

Cookie

HTTPの仕様を拡張して、WebアプリケーションとWebブラウザの間で情報を交換できるようにしたもの。

流れ

  1. webブラウザからリクエストを送る(ログイン情報とか商品情報とか)

  2. webサーバからwebブラウザへ、HTTPのレスポンス・ヘッダーを利用して小さな情報を送る。 「名前 = 値」の組み合わせで表す。これがCookie
    この時、webアプリケーションで、Cookieにどんな情報をいれるかを決める。

  3. webサーバからCookieを受け取ったwebブラウザは、次回同じwebサーバにアクセスする際、受け取ったCookieをそのままHTTPリクエスト・ヘッダに入れて返す。

  4. webアプリケーション側で、リクエスト・ヘッダに入っているCookieを調べることで。アクセスしてきた相手がどのような相手なのかを知る。


Cookieを受け取ったwebサーバと異なるwebサーバに対しては、Cookieを送れない。

Session

Cookieだとツールを使ったりして丸見えなので、より安全に多くの情報を保持するための方法がSession。

処理の進行状況を管理

ログインして〜
商品をついかして〜
注文内容を確認して〜

みたいな、一連の処理の流れのことを 「Session」 と呼ぶ。

Sessionの状態をどこに保持するか

銀行の受付番号みたいに、 SessionID として Cookieを利用して保持 する。

流れ
  1. webブラウザからリクエストを送る(ログイン情報とか商品情報とか)

  2. webサーバがSessionIDを発行して、HTTPレスポンスのCookieへ格納してクライアントへ渡す。

  3. クライアントは、それ以降のリクエストのときに、SessionIDを格納したCookieをサーバーへ送る。

  4. サーバはCookieからSessionIDを取り出して、それを元にメモリ上にもっているクライアントの状態(ログイン状態やカートの中身)を復元する。


PHPだとこんな感じでSessionを格納する。

// セッション開始
session_start();
        
// セッション変数にユーザ名を格納する
$_SESSION['user'] = $_POST['user'];

SessionIDから、ユーザー名とかを識別して、クライアントに返す。


感想

これもしているようで、はっきりしてなかった。 やっと自信もって人に話せるくらいに理解できかな。





「プロになるためのWeb技術入門」を読んだ。HTTPを知る

HTTPを知る

わかってるようで、わかってなかったから、いい掘り下げになった。
まとめるとこんな感じ。

HTTP

Webクライアントが通信を行う際、
どのような情報をやり取りするかという取り決めを、

通信プロトコル」と呼ぶ

HTTPSとかFTPとかSMTPとかとか。

主に、「情報の伝達方法」「情報の意味づけ」を規定するもの。

HTTPによる通信がどうやって相手に届けられるのか?

IPアドレス

簡単に言うと、

インターネット上の住所

これに尽きる。

HTTPリクエストで、URLの中のホスト名が書かれてるが、
これは人間にわかりやすく表現されているだけ。
実際は、IPアドレスという数値によって識別されてる、とのこと。

よく見る、

192.168.1.1

みたいなのがIPアドレス

TCP/IP

これまたよく見たり聞いたりするが、曖昧だったひとつ。

IPアドレスを頼りに情報を届ける役割を担うプロトコル

現実世界の郵便配達の位置づけと似ているらしい。

何をしてるかというと、


WebブラウザからHTTPリクエストなどの情報を受け取って、

パケットと呼ばれる小さな単位に分割して送信。

受け取った側でそれを復元して、Webサーバーなどのアプリケーションへ渡している。


携帯の通信とかで馴染み深いパケットはコレだったのね。


グローバルIPアドレスとプレイベートIPアドレス

IPアドレスは、インターネット上で唯一の値にならないといけないので、勝手に決めれない。
なので、特定の団体が管理している。

でも、家のPCでネットに接続する時に、いちいち申請とかは出さなくてよくて、そのへんをプロバイダがやっている。 プロバイダの役割ってこういうことだったのね。


ざっくりまとめると、

ICANN(世界の管理団体)から「この範囲のIPアドレスを使ってください」と割り当てられ、そこから、JPNIC (日本の管理団体)がインターネットサービスプロバイダに割り当てる。
んで、それを僕らが契約して使っている。

ということらしい。

それをグローバルIPという。

んじゃプライベートIPとは、

家やオフィスとかのネットワーク機器が互いに情報のやりとりをするために、それぞれの機器に割り当てられているIPアドレスのこと。 インターネットなど、ほかのネットワークに接続されていないネットワークを、プレイベートIPアドレスという。

DNS とは

ホスト名をIPアドレスに変換する仕組み。

ドメインIPアドレスの対応表を持ったコンピュータ(DNSサーバ)をインターネット上に配置しておき、DNSサーバーに問い合わせればドメイン名に対応する。

クライアント「www.○○○.comのIPアドレスを教えてください。」

DNSサーバー「219.101.198.19です」

みたいな感じ。

ポート番号

ホスト内の宛先を決定する番号。 アプリケーションを待ち受ける港のようなもの。

よく使われれるプロトコルについては、標準で使用するポートを取り決めておくおことになっている。
HTTPの場合は80番なので、URLに含まれるスキームがHTTPを使用するとわかった時点で、URL内にポート番号が指定されてなければ80番ポートを設定する。

なので、www.○○○.com:80 みたいに、わざわざ書かなくていい。


感想

Lesson3のほんとにざっくりしたまとめだが、
知ったかぶってるようなことが、ちゃんと理解ができてよかった。 この辺の内容くらいはしかっり頭にいれとかねば。





ブログをはじめました。

わたし。

沖縄県宜野湾市のプログラミングスクールCODE BASEの4期生。

2018年12月に卒業。

 

数年前に小さなwebサイト制作屋さんでHTML/CSSをさわってました。

wordpressを触る機会が多くて、PHPをなんとか調べてコピペして動かす毎日。

その後、転職したのですが、良いメンターにも会えず、結局は同じように自信も無く戦う日々。

 

アウトプット苦手を克服するため、

月100時間の学習を継続して続けて行くため、

できるかぎり何をやったか書いていこう思います。

 

きっかけ。  

いつも行く本屋の技術書コーナーで、何気なく立ち聞きした「Rail Girls」という単語を耳にして、CODEBASEにたどり着きました。

 

www.protosolution.co.jp

 

独学つらい。

正解がわからない。

メンターほしい。

仲間ほしい。

コピペで動いてるのコワイ。

もうコード書くのコワイ。

 

そんな私にCODEBASEはガッツリとハマりました。

 

HTML/CSSの基礎的なこと、bootstrapの使い方、JSの理解を深めました。

1番楽しみにしていたRubyの講義では、

Sinatraを使ったWeb Appを作りました。

 

2ヶ月間で、学習する習慣が身につき、わからないことは聞ける、

そんな環境がずっとほしかった。

何よりも、同じ志を持つ仲間や、素晴らしいメンターさん達に会えたことが1番の収穫になりました。

 

そして今。 

現在は、これをこなしてます。

qiita.com

 

Railsの教科書をそろそろ終えて、ProgateのRailsに入るとこ。

この学習のしくみを維持できるようにがんばります。