OmniAICreator/Qiita-1.07M huggingface dataset:
DALL-E2もGoogle Colabで動かしたい！

AI画像生成のQiita記事Stable DiffusionばっかりでDALL-E 2の記事少なくない！？
ということで、海外のGithubを参考にDALL-E 2をローカルで動かします。

https://github.com/ezzcodeezzlife/dalle2-in-python

## DALL-E 2とは
https://openai.com/dall-e-2/
ここ最近流行りのAI画像生成のサービスの１つで、主に文章から画像を生成するAIを利用することができます。 
類似したサービスないしプログラムだと「Midjourney」、「Stable Diffusion」、「NovelAI Diffusion」などが有名ですね。 
最近「Azure OpenAI Service」や「Bing」にも組み込まれたり、「Microsoft Designer」にも利用され始めており、また**HOT**になってきているサービスです。 


## やり方

1. DALL・Eに登録していない人は登録して、メールにて登録されたことを確認してください。
https://labs.openai.com/waitlist

2. 上のGitHubに書かれている方法を利用してトークンを取得します。これで利用の準備は完了です。
`sess-XXXXXXXXXXXXXXXXXXXX`

3. pipを使用し、DALL-E 2をインストールします。
`pip install dalle2`

4. コードを書いていきます。DALL-E 2ライブラリを読み込みます(2.で取得したトークン使用)。
`from dalle2 import Dalle2`
`dalle = Dalle2("sess-xxxxxxxxxxxxxxxxxxxxxxxxxxxx")`
5. 画像を生成するコードを書きます。
`generations = dalle.generate("プロンプト")`

実行した結果、以下の結果を得ることができます。
```
[
    {
        'id': 'generation-b3LLf5D59JwRQJSetvAONLOw',
        'object': 'generation', 
        'created': 1664740126, 
        'generation_type': 'ImageGeneration', 
        'generation': 
        {
            'image_path': 'https://openailabsprodscus.blob.core.windows.net/private/user-xxxxxx/generations/generation-xxxx/image.webp'
        }, 
        'task_id': 'task-k6i8TV46DDa2gKPqFlyZuJ6N', 
        'prompt_id': 'prompt-DiiBTh2I1xHhjWS9wf5J79Ti', 
        'is_public': False
    }
]
```

ダウンロードしたいときは
`generations = dalle.generate_and_download("プロンプト")`

その時は`content/xxx.webp`という形でcontentフォルダにwebp形式で保存されます。

## 実践

今回、`butteflies flying in the sky`というプロンプトを利用しました。

<img width="400" alt="generation-3bl8iYHBorrTEFxzfP8uYr29.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1189481/1b9d124b-6055-797b-4fea-d917a0bfdaf3.png">
<img width="400" alt="generation-3bl8iYHBorrTEFxzfP8uYr29.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1189481/766c8da8-d0c6-c75b-7586-e52148d9e7ad.png">

それらしきものがちゃんと出力できましたね！
APIからの起動でもちゃんとクレジットは減るのでご注意を
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1189481/c8fe6597-71fa-90be-062c-16be9337b50e.png)

それではよきAIライフを。
IBM Cloud :  IBM Cloud Load Balacer for VPC(ALB)のmax connectionsの挙動

# 1. はじめに
IBM Cloud Load Balancer for VPC(ALB)には[max connections](https://cloud.ibm.com/docs/vpc?topic=vpc-advanced-traffic-management&locale=en)という同時接続数の上限を定める機能がある。

>Max connections
>
>Use the max connections configuration to limit the maximum number of concurrent connections for a given front-end virtual port. If you do not configure a value, the system uses a default of 2000 concurrent connections. The maximum concurrent connections for a given front-end virtual port, or system-wide across all front-end virtual ports, is 15000.

ただし、このMax connectionsに定めた値以上の接続がきた時にどういう挙動になるのかがわからなかった（ALBが即時にエラーを返す？待たされる？）し、これがALBサービスとしての接続数なのかALBインスタンスごとの接続数なのかが不明だったので、動作確認を行った。

# 2. 結論

- Max connections以上の接続が発生した場合、後続の接続は待たされる（ALBによって接続試行時に即時にエラーが返される訳ではない）。
- Max connectionsの設定はインスタンスごと。

# 3. 検証

## 3-1. Max connectionsを2に設定する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/30638a95-43b5-0674-67c4-303e2832548f.png)


## 3-2. バックエンドサーバーにApacheを用意し、100MB程度のデータを配置する。

```
[root@syasuda-webserver1 ~]# dd if=/dev/zero of=test.img bs=1024k count=100
[root@syasuda-webserver1 ~]# mv test.img /var/www/html/.
```

これにより、

- これは時間がかかる処理
    - `curl http://<VPC ALB FQDN>:8080/test.img` 
    - `curl http://<VPC ALB IP-Address1>:8080/test.img` 
    - `curl http://<VPC ALB IP-Address2>:8080/test.img` 
- これは即時に結果が返ってくる処理
    - `curl http://<VPC ALB FQDN>:8080/index.html` 
    - `curl http://<VPC ALB IP-Address1>:8080/index.html` 
    - `curl http://<VPC ALB IP-Address2>:8080/index.html` 

というアクセス方式が作成できた。

## 3-3. テスト

ALBには一般的にFQDNでアクセスし、DNSの名前解決の結果によってALBインスタンスの間で負荷分散される。ALBはデフォルトではインスタンスが2つデプロイされ、アクセス数や障害に応じて動的にインスタンス数が増減する。今回はdigコマンドでFQDNのIPアドレスを入手し、FQDNではなく直接IPアドレス経由でアクセスすることで、max connectionsの挙動を確認する。

### 3-3-1: 同じALBインスタンスに2つ接続した場合
```txt:Terminal-1
$ curl http://<VPC ALB IP-Address1>:8080/test.img
（データダウンロード中）
```
```txt:Terminal-2
$ curl http://<VPC ALB IP-Address1>:8080/index.html
（すぐに結果が返る。）
```

 まだMax connectionsに達していないのだから、2つ目のアクセスは期待通りすぐに結果が返る。

### 3-3-2:  同じALBインスタンスに3つ接続した場合
```txt:Terminal-1
$ curl http://<VPC ALB IP-Address1>:8080/test.img
（データダウンロード中）
```
```txt:Terminal-2
$ curl http://<VPC ALB IP-Address1>:8080/test.img
（データダウンロード中）
```
```txt:Terminal-3
$ curl http://<VPC ALB IP-Address1>:8080/index.html
（待ち）
```

Max connectionsに達しているので、3つ目のアクセスは待たされる（当初エラーが返ってくる可能性も考えたが、実際は待たされる）

### 3-3-3: 同じALBインスタンスに2つ接続した上で、異なるALBインスタンスに接続した場合

```txt:Terminal-1
$ curl http://<VPC ALB IP-Address1>:8080/test.img
（データダウンロード中）
```
```txt:Terminal-2
$ curl http://<VPC ALB IP-Address1>:8080/test.img
（データダウンロード中）
```
```txt:Terminal-3
$ curl http://<VPC ALB IP-Address2>:8080/index.html
（すぐに結果が返る）
```

3つ目のアクセスは待たされる可能性があると考えていたが、実際は待つことなく即時結果が返った。2つ目のALBインスタンスでは、Max connections=2にはまだ抵触していないということだろう。
【備忘録】ローカルリポジトリの内容をリモートリポジトリにpushするまで

# 【Gitの登録】
##### 1. ユーザー名を登録
`$ git config --global user.name <username>`
##### 2. メールアドレスを登録
`$ git config --global user.email <emailaddress>`
##### 3. 登録内容を確認
`$ git config --global --list`



# 【ローカルにプロジェクトファイル作成（Linuxの場合）】
Ubuntu上で実行する

##### 1.ディレクトリを作成する場所まで移動
`$ cd /var/www/html`
##### 2.テストディレクトリ作成
`$ mkdr test`
##### 3.テストファイルを作成
`$ sudo git init`

# 【リモートリポジトリに上げたい新規ファイルを作成】
1. テストディレクトリに新規ファイルを作成
$ sudo touch test.txt
2. 現在のリポジトリ内のステータス状況を確認
$ git status
3. testファイルをステージングに追加
$ sudo git add hello.txt
4. ステージングにあるtestファイルをローカルリポジトリに追加
git commit -m 'first commit'


# 【リモートリポジトリを作成】
1.Githubにログイン
2.管理画面よりリモートリポジトリを作成
![2022-10-19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920579/25aee871-2d2f-1f65-e52b-67b62f051b42.png)
右上の「＋」ボタンを押下し、「New repository」よりリモートリポジトリを新規作成

リポジトリ名(Repository name)をtest、説明(Description)を「テストです。」とし、「Create repository」ボタンを押下すとリモートリポジトリが出来上がる。

【リモートリポジトリに接続する】
1.Gitとリモートリポジトリを紐づける
`$ git remote add test（リモートリポジトリ名） git@github.com:[ここにはアカウント名が入ります]/test.git（リモートリポジトリURL）`
※リモートリポジトリURLはリモートリポジトリ作成時に表示されています。
![2022-10-19 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920579/5d12c310-c4d2-2860-63c4-ce992a85d668.png)
2.ブランチ名をmainに変更する（しなくてもよい）
`sudo git branch -M main`
2. ローカルリポジトリの内容をリモートリポジトリにPush
`$ git push test main`
BPMと音符の間隔からn打/秒のnを求めるプログラム

初投稿です。
投稿のテストとして簡単なプログラムを作ってみました。
プログラムの内容としては太鼓の達人というゲームである音符の間隔（16分や8分など）が出てきた際に秒速にいくら叩く必要があるかというものです。
例えば、BPM200の曲（Rotter Tarminationやそつおめしき）で24分が出てきた際には秒速20打必要であるとされています。
ちなみにこれはBPM300の曲の16分と秒速の値が同じであり、以下のような式が成り立つと考えました。

:::note info
叩く回数/秒 = BPMの速さ*(音符の間隔/16)/15
:::
小数点1桁を四捨五入し整数で表現した値とdouble型でそのまま表現した値2つを出すようにしてみました。
0<n<1になる場合は全部1にしました。（ただの個人的な違和感解消のため）


:::note warn
一応BPM、音符の間隔は1以上100000以下想定です。丸め誤差や打ち切り誤差によってプログラムに書いた正確な値が正確な値でない可能性もあります。
:::

書けたプログラムがこちら↓
```java:byousoku.java
import java.util.*;

public class byousoku {
	public static void main(String[] args) {
		Scanner sc = new Scanner(System.in);
		System.out.println("x音符: xを入力してください");
		double Onpu = sc.nextDouble();
		System.out.println("BPM:y yを入力してください");
		double BPM = sc.nextDouble();
		double tpers = BPM*(Onpu/16)/15;//叩く回数/秒
		int a = (int)tpers;
		double q1 = tpers - a;
		double q2 = a + 1 - tpers;
        if(a == 0 && tpers != 0){
			System.out.println("1打/秒必要です");
			System.out.println("正確な値:" + tpers + "打/秒");
		}
		else if(q1 < q2) {
			System.out.println(a + "打/秒 必要です");
			System.out.println("正確な値:" + tpers + "打/秒");
		}
		else {
			System.out.println(a + 1 + "打/秒 必要です");
			System.out.println("正確な値:" + tpers + "打/秒");
		}
	}
}
```

出力結果
①BPM180の32分音符
```
x音符: xを入力してください
32
BPM:y yを入力してください
180
24打/秒 必要です
正確な値:24.0打/秒
```
②BPM7の300分音符
```
x音符: xを入力してください
300
BPM:y yを入力してください
7
9打/秒 必要です
正確な値:8.75打/秒
```
ちゃんと四捨五入されていますね

③BPM1の1分音符
```
x音符: xを入力してください
1
BPM:y yを入力してください
1
1打/秒必要です
正確な値:0.004166666666666667打/秒
```
④BPM0の0分音符（例外だけど一応）
```
x音符: xを入力してください
0
BPM:y yを入力してください
0
0打/秒 必要です
正確な値:0.0打/秒
```

といった感じで完成しました。
今回は小数点第1桁を四捨五入しましたが小数点第2桁、小数点第3桁で四捨五入したりするのもいいかもしれません。
その際はBigDecimalとかtoString()メソッドとか使って組んでみようかと思います。
開発体験コンテンツの進め方

# 概要

開発体験コンテンツの読み方、進め方について說明します。

# コンテンツの前提

本コンテンツは開発や技術の習得がゴールではなく、ドキュメントを作成するに際し、「開発や技術というのはこんなものなんだな」ということを体験し、肌感覚を持ってもらうことをゴールにしてます。
そのため、以下のような特徴・注意点があります。

* 細かな技術說明はしません
* コピペで開発を体験できるようにしています

# 参考：技術を学習するために

開発や技術を学習したい方は、ネットの専用コンテンツ（他社）を見ていただくのが一番かと。
開発の基本的な内容であれば、

* [ドットインストール](https://dotinstall.com/)
* [Progate](https://prog-8.com/)

といったサービスが有名です。

>本コンテンツをよりスムーズに理解するために、先に上記サービスにてHTML、CSS、JavaScript等を学習しておくのもありかと思います。

# コンテンツの構成（読み方）

本コンテンツ、特にソースコード（プログラム）はコピペをしやすいよう、少し変わった構造になっています。基本サンプルは以下の通りです。

>まだ、表現手法を模索中です。。。

![000001.jpg](https://drive.google.com/uc?export=view&id=1VYsgfnaqBGdog4vjsW5y7z84emT6O2xK)

## 実装内容の説明

コピペコードの前後に、何のための操作をしているのかを記述しています。
それぞれの操作がどの実装に影響を及ぼすのかが簡単に理解できるようにしています。

## 編集対象のファイルのコード
編集対象のファイル名が左上部に表示されているので、編集するファイルを確認します。
変更部分はハイライトされており、コード中には、左側に「＋」「−」が記載されており、以下の意味があります。

* 「＋」は編集で追加するコードを表しています
* 「−」は編集で削除するコードを表しています

```diff_html
+ 追加（もしくは変更）を表す
- 削除を表す
```

>この表現はソースコード管理で一般的なGit(hub)等で採用されている一般的な表現です。

編集する箇所がどこなのか、どんなコードを追加するのかを確認したり、コピペするために使います。

## コピペの仕方（コピペ部の表現）

### まとまった複数行のコピペ

コピペしやすいよう、（まとまった）複数行のコードは、コードの下部に「コピペ用」コードが記載されています。上の編集対象ファイルコードの「＋」「−」見て、追加する場所を確認し、コピペ用のコードを該当部にコピーしてファイルにペーストすることを想定しています。

:::note info 
 新規作成ファイルの場合は、コピペ用コードはありません。編集対象のファイルコードをそのまま新規作成したファイルにコピペして使ってください。
:::

### 1行のみのコピペ

変更箇所が1行のコードについてはコピペ用コードは用意しておらず、変更箇所のコードをそのままコピペしてください。

![000010.jpg](https://drive.google.com/uc?export=view&id=1vOGNUUKWtSDi9kUPkfkAH4WQseApxapg)

### 複数行に渡る変更

変更が複数行かつ飛び飛びに存在する場合は、差分だけではなく全体をコピペ用として記載していますのでコードのどの部分かを確認しながら進めてください。

![000020.jpg](https://drive.google.com/uc?export=view&id=1Br0T8gUrLjuMA1x_jUy0Af9rfzTj7IHi)


## 完成版の全てのコードが記事の最後にあります

コピペ迷子になった場合は、各コンテンツの最後に「最終的なコード」を記載していますので、最終的なコードと見比べて進めてください。

>各STEPを踏まず、一気に完成品を確認したい人は全てのコードを利用ください。
オープンソースやクリエイティブコモンズ、パブリックドメイン等の有名OSSマスコットまとめ

有名OSSマスコットのライセンス・作者をまとめました。

### Rust
![rustacean-orig-noshadow.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/29defb9d-a8e6-b747-350c-0bf66eda35f3.png)

Rustのマスコットキャラクター。名前はFerris。
|ライセンス|作者|
|:------------|:------------|
|CC0[^1]|Karen Rustad Tölva[^1]|
[^1]:https://www.rustacean.net/

### Linux
![tux-large.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/f1c3a5b4-90cc-eb36-5bad-0e8000bcce42.png)

Linuxのマスコットキャラクター。名前はTux。
|ライセンス|作者|
|:------------|:------------|
|Public Domain[^2]|Larry Ewing[^2]|
[^2]:https://github.com/garrett/Tux

### Lisp
![1__XEK5hMqdyjVw0GzQu-KUw.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/a83659f8-b221-dd0a-d3cd-fe2f14de77d4.png)

Lispのマスコットキャラクター。名前はTux。
|ライセンス|作者|
|:------------|:------------|
|Public Domain[^3]|Conrad Barski, M.D.[^3]|
[^3]:https://www.lisperati.com/logo.html

### Android
![Android_Robot.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/d9c155fb-6843-234c-144c-031cd6ae1873.png)

Androidのマスコットキャラクター。名前はAndroid ロボット。
|ライセンス|作者|
|:------------|:------------|
|Creative Commons 3.0 Attribution License[^4]|Google[^4]|
[^4]:https://developer.android.com/distribute/marketing-tools/brand-guidelines

### Go
![gopher_color.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/776090d3-cd12-ed43-f970-83112b47e5c7.png)

Goのマスコットキャラクター。名前はGopher。
|ライセンス|作者|
|:------------|:------------|
|Creative Commons 3.0 Attributions license[^5]|Renee French[^5]|
[^5]:https://go.dev/doc/gopher/README

### GNU
![heckert_gnu.big.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/6818f504-c804-d34c-80a0-fed28ea1d137.png)

GNUのマスコットキャラクター(の、この画像はBOLD版)。GNUライセンスとFree Art LicenseとCCライセンスのデュアルライセンス。
|ライセンス|作者|
|:------------|:------------|
|GNU Free Documentation License v1.3, or the Free Art License, or the Creative Commons Attribution-ShareAlike 2.0 License[^6]|Aurélio A. Heckert[^6]|
[^6]:https://www.gnu.org/graphics/heckert_gnu.html

### Java
![Hips.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/4fe75e27-74db-86e9-18f3-dc251c8b3383.png)

Javaのマスコットキャラクター。名前はDuke。
|ライセンス|作者|
|:------------|:------------|
|New BSD license[^7][^8]|Joe Palrang[^8]|
[^7]:https://wiki.openjdk.org/display/duke/Main
[^8]:https://dev.java/community/duke/

### PHP
![Webysther_20160423_-_Elephpant.svg.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2612381/2d79ffba-0446-fa00-c6cf-9874f901a870.png)

PHPのマスコットキャラクター。名前はElePHPant。
|ライセンス|作者|
|:------------|:------------|
|GNU General Public License[^9]|Vincent Pontier[^9][^10]|
[^9]:https://commons.wikimedia.org/wiki/File:Webysther_20160423_-_Elephpant.svg
[^10]:https://www.php.net/elephpant.php
プロジェクト 'Default' が見つかりません/Project "Default" is not found

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/368087/7cdf27db-0d4b-83de-11ff-c06a222ea70d.png)
slnソリューションではないため、
上記のエラー発生しました。
「報告書（顛末書）」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 報告書（顛末書）の概要

ITプロジェクトに関わっているといろいろな報告書を書く場合があります。
ここでは最も頻度が高い？顛末書を書いてみたいと思います。

>顛末書は「事故報告書」とか呼ぶこともあります。

|項目|内容|
|-|-|
|作成目的|何か報告を求められたとき（事故が起こったとき）|
|記述すべき内容|発生から解決までの経緯（要点）を時系列で說明|
|誰がつくるのか|報告を指示された人（開発会社）|
|誰向けに作るのか|報告を求める人（発注元）|
|作成タイミング|事象が収束しつつあるとき（対応優先）|
|ファイル形式|Excel, Word|
|備考|会社により様式が異なる|

### ダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1fm2Rcp-igYIpY-niClVtcnO0aI92OUGq)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 事故の際は対策優先（少し落ち着いてから書く）

事故時の報告書の作成は、クライアントから求められない限り、問題解決を優先すべきです。
ある程度問題の全容、解決策が見えてから記述したほうが内容のある報告書を作成できます。

>内容の無い報告書（特に解決法とかが無いもの）を出すとむしろクライアントの怒りの火に油を注ぐことになります。

#### 時系列に要点を整理する

事象の発生（発見）から解決までの経過を時系列に沿って完結に記述する。

### 構成（記述項目）を考える

ケースバイケースですが、凡そ下記のような感じでしょうか。

* 発生事象
* 原因
* 経緯
* 再発防止

その他、お客さまがいるようなサービスの場合は、

* お客さまへの影響
* お客さまへの対応

なども記述することが多いです。

### 記述例（サンプルの說明）

#### 報告書（顛末書）

![000001.jpg](https://drive.google.com/uc?export=view&id=1NCxA7kHGEHXs9wKXtqsVAxugLNpPHnUh)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
「稟議書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 稟議書の概要

稟議書は各会社で設定されたルールに従い、許可をオフィシャルに得るための書類です。
多くの場合は一定金額以上の購入や発注をするときに必要になります。

>場合によっては出張稟議とかもありますよね。


|項目|内容|
|-|-|
|作成目的|会社に発注や支払を依頼し、許可を得る（それを記録に残す）|
|記述すべき内容|依頼内容|
|誰がつくるのか|稟議起案者|
|誰向けに作るのか|会社|
|作成タイミング|何か稟議が必要になったとき|
|ファイル形式|ExcelかWord|
|備考|稟議書の必要な条件、記述内容は会社により異なる|

### ダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1fm2Rcp-igYIpY-niClVtcnO0aI92OUGq)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 稟議完了に必要な時間を想定して動く

作成は会社のルールに従って淡々と行えばいいのですが、稟議の決裁者（確認者）が複数いるときは、完了までにそれなりの時間（場合により数週間）を要す場合もありますので、稟議にかかる時間を考慮した行動が必要です。

### 構成（記述項目）を考える

記述することはそれほど多くなく、本文は、

* 稟議のタイトル
* 稟議の内容

という感じで、添付書類として、

* 見積書
* 決定時の議事録（あれば）

を付けます。見積はほぼ必須です。

### 記述例（サンプルの說明）

#### 稟議書

![000001.jpg](https://drive.google.com/uc?export=view&id=1dPojahTnw_9CibAujV1K65kDVwGdK-lT)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
LaTeXでlongtableを使って長い表を貼りたい

# はじめに
LaTeXで何か書く際に、縦に大きな表を用意する必要が出てくることがあります。
普通の大きさの表であれば標準のtableを使えばいいのですが、表の大きさがデカくなった際にページからはみ出てしまうことがあります。
そこで登場するものがlongtableです。
longtableでもtableの書き方がベースにはなりますが、少し違う部分があるので自分の備忘録も兼ねて解説したいと思います。

# 例
実際にlongtableを使うときはこんな感じです。
```latex:document.tex
\documentclass{jartcle}
\usepackage{longtable} % longtableを使う際に必要
\title{longtableを使ってみる}

\begin{longtable}{|c|c|c|}

% firsthead
% 表の一番最初に表示されます。
% 省略した場合はheadの内容が表示されます。
\caption{長い表} \label{tab:long} \\ % 強制改行が必要
\hline 要素1 & 要素2 & 要素3 \\ \hline 
\endfirsthead

% head
% 各ページの最初に表示されます。
% 省略した場合は何も表示されません。
\hline 要素1 & 要素2 & 要素3 \\ \hline 
\endhead

% foot
% 各ページの最後に表示されます。
% 省略した場合は何も表示されません。
\hline \multicolumn{3}{|r|}{次のページへ続く。} \\ \hline
\endfoot

% lastfoot
% 表の一番最後に表示されます。
% 省略した場合はfootの内容が表示されます。
\hline \multicolumn{3}{|r|}{終了} \\ \hline 
\endlastfoot

% ここから表の内容
% tableの書き方と同じです。
お試し1 & お試し2 お試し3 & 3.141592 \\
お試し1 & お試し2 お試し3 & 3.141592 \\
お試し1 & お試し2 お試し3 & 3.141592 \\
お試し1 & お試し2 お試し3 & 3.141592 \\
お試し1 & お試し2 お試し3 & 3.141592 \\

\end{longtable}

\end{document}
```
:::note warn
コードを短くするために表の内容を省略しています。
:::
コンパイルするとこんな感じです。

1ページ目
<img width="100" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568101/aadd2e96-22b1-3973-9d7c-44ebee28de77.png">

2ページ目
<img width="100" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568101/29858496-2f31-2f4e-32b0-f6dd31fee444.png">

最後
<img width="100" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/568101/3abb0ea8-527c-311a-305e-d37b89b68fad.png">


:::note info
クリックで拡大表示できます。
:::

# tableとの違いについて
tableでは先に`\begin{table}`をしてから、表の部分はさらに`\begin{tabular}`をすることが多いですが、longtableでは、いきなり`\begin{longtable}`から始める事ができます。
もちろんキャプションやラベル等も含めることができますが、注意が必要です。
longtableにキャプションやラベルを埋めた際はその後ろに`\\`を入れる必要があります。
また、tableとは違い、複数ページにまたがることが想定されているため、ヘッダーやフッターを指定することができます。
なお、センタリングは自動で行われるので`\centering`の必要はありません。

# 書き方について
`\begin{longtable}`でlongtableを開始する際にtabularと同様に各列の位置を指定できます。
表のデータ自体の書き方はtabularと同様の書き方ができますが、先頭行と末尾行だけ書き方が少し違います。

# 各ヘッダー・フッターについて
各ヘッダーとフッターは`\endhead`のように`\end~`の形で書きます。書く際最初にbegin等は書きません。
### firsthead
表の一番最初のみに表示されます。
最初のキャプションなどをここに書くと良いと思います。
省略するとheadの内容が表示されます。
### head
各ページの最初に表示されます。
前のページから続いていることを書いたり、各列の名前について再度記すことができます。
### foot
各ページの最後に表示されます。
次のページに続いていることなどを書くことができます。
### endfoot
表の一番最後のみに表示されます。
この表がここで終了していることなどを記すことができます。
「議事録」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 議事録の概要

ビジネスの現場で最も登場し、かつ、最も基本的な書類です。
議事録がちゃんと書けるかでその人の実力がわかると言っても過言ではありません。

>というわりにサンプルはしょぼいです。まあ、実力がわかるということで。

### 概要

資料の概要は下記の通りです。

|項目|内容|
|-|-|
|作成目的|会議の内容、特に決議事項、継続検討事項（宿題）を記録として残す|
|記述すべき内容|出席者の発言（の要約）|
|誰がつくるのか|会議主催者（が手配した記録係）|
|誰向けに作るのか|会議参加者|
|作成タイミング|会議中メモ、会議後整理、（その後、共有・確認）|
|ファイル形式|ExcelかWord？|
|備考|会社の文化により様式が異なる|

### ダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1fm2Rcp-igYIpY-niClVtcnO0aI92OUGq)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 発言は要約するのが基本

議事録をどう取るのかは会社の文化に依存するところが多いですが、発言をそのまま議事録に残すのではなく、発言内容の趣旨が変更されないよう注意しながら要約して記述するのが一般的です。

>時折、発言のまんま記述する人がいて見ていて面白いのですが、だいたいそれを見た上司に怒られますね。

例）

会議で、社長と田中さんで下記のようなやり取りがあったとしたら、

社長：「○○はむちゃくちゃ重要なので、今月中にぜったいやれよ！死んでもやれよ！わかったな！田中！」
田中：「あ・・・はい・・」

議事録には、

「○○は非常に重要なため、今月中に必ず実行してほしい」（社長）
「承知しました」（田中）

と書きます。
また、発言した場合でも「あ、これは議事録に残さないでね」と言われたものは除外します。

#### 議事録は参加者が確認の上、修正するのが基本（あまりされないけど）

実際に運用されない場合もありますが、議事録は記述後、参加者に共有され、発言や認識に齟齬が無いか確認をし、必要に応じて修正などを行うのが基本です。

例）

社長が、下記の議事録を見て、

「○○は非常に重要なため、今月中に必ず実行してほしい」（社長）
「承知しました」（田中）

あ、今月中と言ったけど、今週中の誤りです。修正お願いします。と言ってくれば修正します。
（この場合、田中さんにも確認をとる必要があります）

### 構成（記述項目）を考える

まあ、議事録というのはだいたい下記のような感じです。

* 会議名（議題）
* 開催日時
* 参加者
* 話し合いの内容（サマリ）
* 決定事項
* 宿題（誰の）

### 記述例（サンプルの說明）

#### 議事録

![000001.jpg](https://drive.google.com/uc?export=view&id=1stqwKagXr20ZAbTVQw600uvOFx0ephVg)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
「請求書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 請求書の概要

請求書についても特に說明することは無いかと思います。

|項目|内容|
|-|-|
|作成目的|支払してもらえるように請求する|
|記述すべき内容|請求書名、請求内容、金額|
|誰がつくるのか|開発会社|
|誰向けに作るのか|発注者|
|作成タイミング|検収書受領後|
|ファイル形式|ベースはExcelだが、最終版はPDFか紙|
|備考|検収書（番号）を添付する場合もある|

### ダウンロード

初期費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1MyRNOZn-1JLrL6p7IKmIDS_b5qeBYSci)から。
保守費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1h3pf98A2cyiMZgBopTnhbDytg6SgbP8_)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
>営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 検収書受領後速やかに

検収書をもらったら、直ぐに作成・送付しましょう。
請求書の送付は検収書をもらえてることが前提になります。まだ検収が終わってないのに事務的に請求書を出してしまうと話がこじれることがありますので注意が必要です。

>「貴社の責任で納期ズレてるのに、請求書は納期通りに送ってくるとはいい根性してますね」とか嫌味言われます（苦笑）

### 構成（記述項目）を考える

基本的には見積、発注、検収書の内容を踏襲した形になります。

* 請求名
* 請求項目（検収書準拠）
* 検収（書）番号（あれば）

### 記述例（サンプルの說明）

#### 請求書

![000001.jpg](https://drive.google.com/uc?export=view&id=19vyauyiQaCus6UKGxp2JPoTW3M_Yny44)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
【Flutter】iOSでバックグラウンドオーディオがうまく機能しない

audioplayers0.20.1 を使ってオーディオをバックグランドで再生しようとすると、iOSでうまく機能しない。
解決策が見つかったので書き残します。
```info.plist
<key>UIBackgroundModes</key>
	<array>
		<string>audio</string>
	</array>
```
info.plistに上記を追加します。

```Swift:AppDelegate.swift
import UIKit
import Flutter

@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    GeneratedPluginRegistrant.register(with: self)
    UIApplication.shared.beginReceivingRemoteControlEvents() //この一行を追加する
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }
}
```
僕の場合はこれでバックグラウンドで機能しました。
「検収書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 検収書の概要

発注した作業が完了したことを発注側が確認したことを証明する書類です。
検収書が無いと請求できない場合や請け側においても売上計上できない場合がありますので非常に重要な書類です。

>会計基準がはっきりしている企業では入金よりもむしろ検収書の有無が重要視されることすらあります。たまに営業担当者が検収書を偽装したりしますが（それくらい重要）、監査法人の残高確認プロセスでバレるでやめましょう。

|項目|内容|
|-|-|
|作成目的|納品および受入が完了したことを通知する|
|記述すべき内容|検収した内容|
|誰がつくるのか|発注者（作成自体は請け側が作る場合も）|
|誰向けに作るのか|開発会社|
|作成タイミング|受入検査後|
|ファイル形式|ベースはExcelだが、最終版はPDFか紙|
|備考|検収書が無いと原則請求できない（売上計上できない）|

### ダウンロード

初期費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1MyRNOZn-1JLrL6p7IKmIDS_b5qeBYSci)から。
保守費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1h3pf98A2cyiMZgBopTnhbDytg6SgbP8_)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
>営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 発注書の内容に準拠

通常は発注書の内容に準ずる内容で作成されます（発注に対する検収なので）。
Excelや受発注管理システムで発行する場合は、自動的に見積（発注）内容が反映されたりします（サンプルでもそうしています）。

### 構成（記述項目）を考える

以下のような感じかと。

* 検収対象名
* 検収対象項目（発注書準拠）

### 記述例（サンプルの說明）

#### 検収書

![000001.jpg](https://drive.google.com/uc?export=view&id=1-yI9oMGYjWuRxePaEmekoW560KG79eP5)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
「発注書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 発注書の概要

発注者が正式に請け側に依頼する（した）ことを証明する書類です。
発注書が無いのに先行して作業する（させる）ことは、状況に寄っては発注側、請け側どちらにおいても問題になることがあるので注意が必要です。

原則として発注側が用意する書類ですが、請け側が準備し、発注側に署名・押印してもらうこともあります。

|項目|内容|
|-|-|
|作成目的|開発会社に発注依頼を正式に行う|
|記述すべき内容|発注内容、発注金額、支払条件等|
|誰がつくるのか|発注者（作成自体は請け側が作る場合も）|
|誰向けに作るのか|開発会社|
|作成タイミング|発注時|
|ファイル形式|ベースはExcelだが、最終版はPDFか紙|
|備考|開発会社が作成し、発注会社に押印をもらう場合もある|

### ダウンロード

初期費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1MyRNOZn-1JLrL6p7IKmIDS_b5qeBYSci)から。
保守費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1h3pf98A2cyiMZgBopTnhbDytg6SgbP8_)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
>営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。

## 作成してみる

では、作成してみましょう。

### 作成のポイント

#### 見積書の内容に準拠

通常は見積の内容に準ずる内容で作成され、新たに設定された発注条件などがあれば追記されます。
Excelや受発注管理システムで発行する場合は、自動的に見積内容が反映されたりします（サンプルでもそうしています）。

>金額が大きい場合などは契約書を締結する場合もあります（契約書 + 発注書のときもあり）。

### 構成（記述項目）を考える

まず基本内容としては、

* 発注対象名
* 発注内容（見積書準拠）

あたりが記述され、但し書きとして、

* 納品日
* 支払方法・予定日

などを記述します。

### 記述例（サンプルの說明）

#### 発注書

![000001.jpg](https://drive.google.com/uc?export=view&id=17ZHRrZqDSwow_4bJR3nqwSBPEnpv2hLM)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
「見積書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 見積書の概要

見積書については說明する必要もないかもしれませんが、意外と見積書を作ったことの無い人、作れない人多いです。
しっかり作れるようになりましょう。

>そのためには業務プロセス、各プロセスの内容・負荷理解、人月単価等の理解が必要です。

|項目|内容|
|-|-|
|作成目的|クライアントに費用を伝える|
|記述すべき内容|見積対象項目、金額（小計）、合計、但し書き（有効期限等）|
|誰がつくるのか|見積を出す会社（開発会社）|
|誰向けに作るのか|クライアント|
|作成タイミング|発注前（クライアントから要求があったとき）|
|ファイル形式|ベースはExcel。クライアント送付時はPDFか紙|
|備考|会社により様式が異なる|

### ダウンロード

初期費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1MyRNOZn-1JLrL6p7IKmIDS_b5qeBYSci)から。
保守費用のサンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1h3pf98A2cyiMZgBopTnhbDytg6SgbP8_)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
>営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。

## 作成してみる

では、作成していきましょう。

### 作成のポイント

#### 見積書をいきなり書かない（まず、内部用の見積根拠資料を作る）

見積書に記述できる内容は限られているので、ある程度サマリを記述することになります。「システム開発費用 一式」として総額を出すという究極のサマリ方もありますが、多くの場合「内訳」を聞かれます。そんなとき、直ぐに答えられるように見積書のための内部用の見積根拠資料を準備しておくといいでしょう。

また、「ひとまず要件定義までを発注したい」といった感じで、プロセス別に個別発注となるケースもあるので、どのような要求が来ても再見積をスムーズにできるように内部的な見積根拠資料を別途作成しておくのが無難です。

（見積根拠資料の例）
カテゴリ別の再見積や見積根拠を聞かれても直ぐに対応できます。

![000001.jpg](https://drive.google.com/uc?export=view&id=1PA2mKcmK8cLYQYGTaC2bGSCCRk2TK2O5)

#### 但し書きを適切に入れる

必須項目としてオーソドックスな項目は「有効期限」ですが、その他、「支払条件」や、要件が曖昧な状況で見積を求められたときなどは、「要件定義後に再見積とさせていただきます」などを追記する場合があります。

#### その他

当然のことですが、見積書をクライアントに提出する際は、内容を必ず上司に確認してもらってから提出します。

>会社によっては見積プロセスも厳密に決まっている場合が多いので、一度確認してみてください。

### 構成（記述項目）を考える

* 見積項目
* 数量
* 単価
* 小計
* 合計
* 但し書き

### 記述例（サンプルの說明）

#### 見積書

まあ特に変わったところはありません。項目は工期が短いので工程別ではなく、全行程にかかる人月＋開発環境としています。

>ま、一定以上の工数ならほぼ100%、工程別に分けてとか言われます。
>いずれにしても内容について聞かれたら算出根拠含め、しっかり說明できる状態になっておくことが重要です。

![000010.jpg](https://drive.google.com/uc?export=view&id=1yiJByiplAZnKxNM1uNZ_uvUyjTJMBLqG)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
「ヒアリングシート」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## ヒアリングシートの概要

ヒアリングシートには、下記の２つがあるかなと思いますが、ここでは営業用のヒアリングシートを想定しています（一般ビジネスドキュメントなので）。

* 見積等を行うために概要を聞く過程で作成するもの（営業用のヒアリングシート）
* 要件を聞く過程で作成するもの（要件定義用のヒアリングシート）

|項目|内容|
|-|-|
|作成目的|相談・案件の内容を網羅性を持って確認する（見積に必要な情報視点）|
|記述すべき内容|目的、納期、予算（教えてくれるなら）を確認するのが基本|
|誰がつくるのか|開発会社|
|誰向けに作るのか|開発会社（社内用）|
|作成タイミング|お客さまから相談を受けたとき、見積を依頼されたとき|
|ファイル形式|Excelかな|
|備考|技術的なヒアリングシートもありますが、ケースバイケースなので今回は見積作成視点|

### ダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1MyRNOZn-1JLrL6p7IKmIDS_b5qeBYSci)から。

>複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
>営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。

## 作成してみる

では、作成していきましょう。

### 作成のポイント

いわゆる5W2H系を中心に、漏れなく聞きます。
あとは案件やプロジェクトに依存した注力点、留意点、制限事項などを確認します。
また、特殊な業界（医療や金融等）の場合は、法的規制や準拠すべき業界基準などがないかも確認します。
というのは、例えば医療ではそもそも広告に制限があったり、金融では準拠すべき業界ルール（例えばクレジットカード番号を保持するならPCI-DSSに対応しろ）があり、システム構築とは別にルール準拠にそれなりの工数（費用）がかかる場合などがあります。

>EC系なら酒類の販売、古物の販売など、、、意外と気にしないといけないこと多いです。

### 構成（記述項目）を考える

ひとまず以下のような項目を設定してみました。

* プロジェクトの概要（目的）
* 納期
* 予算
* 運用対応
* 作業分掌
* プロジェクト依存の留意点
* 遵守・準拠すべき法令や社内ルール

### 記述例（サンプルの說明）

#### ヒアリングシート

![000001.jpg](https://drive.google.com/uc?export=view&id=1KYdH9rVXPrdMq1gJk3dLyU6S85egqAFv)

## 一般的には

>実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。　

ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。
[PHP] readfileでcsvをダウンロードさせると余計なものが挿入される

# 何が起きたのか
webアプリケーション上でcsvダウンロードボタンを作った。
動いたものの、元のcsvファイルデータと一緒にPHPの警告や、htmlソースがデータ化されてしまっている。。。
| column_1 | column_2 |
|:-----------|------------:|
|1|tree|
|2|mono|
|3|ace|
|4|believe|
|\<!DOCTYPE html>|||
|\<html lang="ja">|||

# 解決した

```diff_php
$filename = 'child.csv';
$csvFilename = '/tmp/child.csv';

header('Content-Type: application/stream');
header('Content-Disposition: attachment; filename='.$fileName); 
header('Content-Length: '.filesize($csvFileName)); 
readfile($csvFileName);
- unlink($fileName);
+ unlink($csvFileName);
```
unlinkの設定を修正したら、正常になりましたとさ。おしまい。
nokogiriの使い方メモ 


初投稿&マークダウン慣れついでに、簡単に[nokogiri](https://github.com/sparklemotion/nokogiri "nokogiri")の使い方のメモ。
[nokogiri](https://github.com/sparklemotion/nokogiri "nokogiri")はRubyでスクレイピングする際に使うライブラリ。


### 環境
```
ruby 3.0.0
MacOS Mojave 10.14.4
```

### インストール&バージョン確認
権限エラーがあれば`sudo`つけること
```
gem install nokogiri
nokogiri -v
```

### タイトル取得
下記のポータルサイトのタイトルをnokogiriを使用して、スクレイピングしてみる。
[プログラミングに関するブログ](https://supremecourtlawlibrary.org "ProCode")

```
require 'nokogiri'
require 'open-uri'
 
url = "https://supremecourtlawlibrary.org/".freeze
charset = nil

html = open(url) do |f|
  charset = f.charset
  f.read
end
 
page = Nokogiri::HTML.parse(html, nil, charset)
 
p page.search("title").text
```

実行結果
```
"ProCode"
```
タイトルタグ以外にも、記事のタイトルやURLなど、色々取得できる。
また後日付け加えるので、一旦ここまで。
###
参考・引用資料
https://supremecourtlawlibrary.org/
https://github.com/sparklemotion/nokogiri
https://nokogiri.org/
【UE5】当たり判定衝突時にプレイヤーをリスポーンさせる方法

UE4/5でプレイヤーが当たり判定の設定されたActorに衝突した場合、初期地点にリスポーンする方法が探しても見つからなかったのでメモ代わりに残しておく。

- 前準備
  衝突判定のあるアクタ(以降トゲA)を追加する。
  追加方法は前の記事の4-3に記載した。前記事：[Unreal Engine5を使用したゲーム作成のチュートリアル(個人的メモ)](https://qiita.com/connyaku/items/0146cde147fe579d6e2a)
- Blueprintの追加
  トゲAのBlueprintを以下のように設定する。
説明：衝突Eventを受けたら、トゲAに衝突したアクタを削除(Destroy)し、その後Playerを初期地点に設置する。
(今回はRestart Playerを使用しているため、衝突したのがplayer以外のアクタで、そのアクタをリスポーンさせたい場合は使えない。汎用性が低いのが課題)
  ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1235659/769cab9e-fe8a-d5cc-6235-f13b31cb9026.png)
  ※Restart Playerが追加できない場合の対処法
　「Destroy Actor」の実行ピンからだと実行可能なアクション検索時に「Restart Player」が検索に引っかからないため、まず「Cast To BP_ThirdPersonGameMode」の実行ピンから「Restart Player」を追加し、もう一度「Cast To BP_ThirdPersonGameMode」の実行ピンから「Destroy Actor」を追加すると上画像のようになる
  
最終的な動作が↓
![Videotogif.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1235659/b3eeee11-a953-183a-5742-648f032faf47.gif)

- 参考サイト
アンリアルエンジン4.27のドキュメント：[プレイヤーキャラクターをリスポーンする](https://docs.unrealengine.com/4.27/ja/InteractiveExperiences/HowTo/RespawnPlayer/)
⇒こちらには特定キー入力によるリスポーン追加方法が記載されている
GASでスプレッドシートからPDFファイルをたくさん作る

この記事は移行しました！[最新の内容はこちら](https://naoqoo2.github.io/blog/GAS%E3%81%A7%E3%82%B9%E3%83%97%E3%83%AC%E3%83%83%E3%83%89%E3%82%B7%E3%83%BC%E3%83%88%E3%81%8B%E3%82%89PDF%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E3%81%9F%E3%81%8F%E3%81%95%E3%82%93%E4%BD%9C%E3%82%8B/)をご覧ください😀


スプレッドシートのデータをPDFファイルとして大量に出力したいときが、人生に1度や2度はやってきますね。
そんなときはGASで。

## やりたいこと

スプレッドシートの1行1行をPDFファイルにしてGoogleドライブに出力する。

例）
A列：ファイル名
B列：URL（本文の内容）

## GAS

```js
function createPdfFiles() {
  Logger.log('start');
  var sheet_id = '{スプレッドシートのID}';
  var sheet_name = '{スプレッドシートのシート名}';
  var folder_id = '{出力先のGoogleドライブのID}';

  var sheet = SpreadsheetApp.openById(sheet_id).getSheetByName(sheet_name);
  var folder = DriveApp.getFolderById(folder_id);

  var sheet_data = sheet.getDataRange().getValues();
  for (var i = 1; row = sheet_data[i]; i++) {
    var item = rowToItem(row);
    createPdf(item, folder);
  }

  function rowToItem(row) {
    var item = {};
    item['name'] = row[0];
    item['url'] = row[1];
    return item;
  }

  function createPdf(item, folder) {
    let doc = DocumentApp.create(item['name']);
    let body = doc.getBody();
    var paragraphs = body.getParagraphs();
    var p1 = paragraphs[0];
    p1.appendText(item['url']).setLinkUrl(item['url']);

    // 一旦Googleドキュメントとして保存（保存しないとPDFとして取得できなかったため。。）
    doc.saveAndClose();

    var pdf = doc.getAs('application/pdf');
    pdf.setName(doc.getName() + '.pdf');
    folder.createFile(pdf);

    // 一旦保存していたGoogleドキュメントを削除
    DriveApp.getFileById(doc.getId()).setTrashed(true);
  }
}
```
ヒストグラム分析 (Histogram)

[Teradata Vantage - Vantage Analytics Library](https://docs.teradata.com/r/Vantage-Analytics-Library-User-Guide/January-2022)[2022/9/22時点]の翻訳です。
(リリース番号 : 2.1.1 | リリース日 : January 2022)
> この記事はVantageアナリティクスライブラリ シリーズのコンテンツです。

# 概要
ヒストグラム解析は、連続した数値の分布を示すヒストグラムグラフを作成するためのデータを提供します。

# 前提条件
・Teradata Vantageインスタンスにアクセスできること。
・Vantage アナリティクス・ライブラリがインストールされていること。

::: note info
Vantage アナリティクス・ライブラリのインストールについて、既にVantageを導入頂いているお客様はTeradataサポートサービスにお問い合わせください。
Vantage Express (評価版)やクラウドサービスのDIYでご利用頂く場合は[Teradata Dounload](https://downloads.teradata.com/download)からダウンロードし利用可能です。
Vantage アナリティクス・ライブラリのインストール手順は「[Vantageアナリティクス・ライブラリのインストール](https://qiita.com/ykswi/items/12d0da2ac69b4b161881#vantage%E3%82%A2%E3%83%8A%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AF%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)」の記事に従い行います。
:::

# データの準備
## サンプルデータの入手とデータベースへの格納方法
こちらの「[チュートリアル用のサンプルデータを用意する](https://qiita.com/tmsky/items/4d86ca35aef753290020)」を参照ください。


# 実行方法
## SQLから実行する場合の例
```SQL
CALL td_analyze (
  'histogram',                        /* 分析手法　*/
  '
  database        = QID;              /* データベース名 */
  tablename       = Superstore;       /* テーブル名 */
  columns         = Sales;            /* カラムリスト */
  '
);
```
:::note information
出力結果をテーブルに書き込む場合は以下オプションを指定可能です。
outputdatabase = 出力データベース名;
outputtablename = 出力テーブル名; 
overwrite = {true | false}; --- 未指定の場合はtrueで上書きします
:::
## 出力結果
|xdb|xtbl|xcol|xbin|xbeg|xend|xcnt|xpct|
|:-|:-|:-|:-|:-|:-|:-|:-|
|QID|Superstore|Sales|1|0.444|2264.2476|9876|98.81929157494497|
|QID|Superstore|Sales|2|2264.2476|4528.0512|91|0.910546327796678|
|QID|Superstore|Sales|3|4528.0512|6791.8548|13|0.13007804682809687|
|QID|Superstore|Sales|4|6791.8548|9055.6584|6|0.06003602161296778|
|QID|Superstore|Sales|5|9055.6584|11319.462|5|0.05003001801080648|
|QID|Superstore|Sales|7|13583.2656|15847.0692|1|0.010006003602161296|
|QID|Superstore|Sales|8|15847.0692|18110.8728|1|0.010006003602161296|
|QID|Superstore|Sales|10|20374.6764|22638.48|1|0.010006003602161296|

## 出力結果の説明
| カラム名 | データタイプ | 説明 |
|:-|:-|:-|
|xdb|VARCHAR (128)|データベース名|
|xtbl|VARCHAR (128)|テーブル名|
|xcol|VARCHAR (128)|カラム名|
|xbin|INTEGER|ビン番号|
|xbeg|FLOAT|ビンの開始境界|
|xend|FLOAT|ビンの終了境界|
|xcnt|FLOAT|レコード数|
|xpct|FLOAT|値の割合|

# おわりに
:::note information
サンプルコードはSQL関数から掲載し順次Pythonコードも掲載していく予定です。
:::

:::note warn
警告
この本書は[Teradata Vantageドキュメンテーション](https://docs.teradata.com/)よりトピックに必要な情報を抜粋したものです。掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。正確な内容については、原本をご参照下さい。
また、修正が必要な箇所や、ご要望についてはコメントをよろしくお願いします。
:::

#### Teradata Vantageへのお問合せ
[Teradata Vantage へのお問合せ](https://www.teradata.jp/About-Us/Contact)
「リリース判定基準書」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## リリース判定基準（書）の概要

リリースしてもよいかを判定する条件を設定・記述した書類になります。

>リリース判定基準書という言葉はあまり一般的ではないと思います。実践ガイドブックでは「移行判定」、「稼働判定」という言葉を使っているようです（リリース判定という言葉も文中にはありますが）。

### 概要

資料の概要は下記の感じです。

|項目|内容|
|-|-|
|作成目的|リリースを判定する条件を記述|
|記述すべき内容|リリース判定基準、判定合否時の対応|
|作成タイミング|リリース判定まで|
|対象者|プロジェクトメンバー（非技術者、技術者）|
|ファイル形式|パワーポイント、Excel、Word|
|備考|リリース判定基準書というような言葉が一般的にあるわけではない|

>一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。

### サンプルダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1XI5nu0GejxOqZUr6FGnYovDsqRWcvgNr)から。

## 要点解説（抜粋）

では、資料作成における要点について簡単に說明します。

### 先行資料（作成準備）

リリース判定基準のメインコンテンツはテスト結果なのでテスト結果報告書が先行書類の代表かと思います。一方、リリースの判定には単にテストがOKだったかということではなく、運用を含めた周辺準備ができているかという総合的な視点が必要です。

* テスト結果報告書
* 運用テスト結果報告書

### 作成のポイント

#### テスト結果のみではなく周辺要素も含めて検討

先行資料でも書きましたが、リリース判定のメインコンテンツが「テスト結果」であることは間違いありませんが、技術だけでなく、運用、営業、マーケティング等の周辺状況も考慮した上で基準を設定する必要があります。

>もちろんその結果、「テスト結果がOKならリリース」というのもありです。

### 記述内容（アウトライン）

今回は下記のような項目を記述してみました。

* リリース判定基準（概要）
* リリース判定会議
* リリース判定項目対応状況
* リリースについて

### 記述例（サンプルから抜粋）

では、サンプルの主要なページについて少し解説したいと思います。

#### 表紙

特に補足することはありません。

![000001.jpg](https://drive.google.com/uc?export=view&id=18YC7Tngba-EZizVB5lHKbHsg4jHZeNV0)

#### 目次

こんな感じ。

![000010.jpg](https://drive.google.com/uc?export=view&id=1fPzGDkfNONChTILlLqRsnatOTzMQez5U)

#### リリース判定基準（概要）

まずはリリース判定条件の一覧です。
各種テスト結果に加え、その他の条件も追加しています。

![000020.jpg](https://drive.google.com/uc?export=view&id=19cXMmGnk4TYNC1ZVCQ8EMixQ5u9vlHKX)

#### リリース判定会議

リリース判定会議をいつ、誰の出席で開催するか記述。予備日も設定しておくほうが無難。

![000030.jpg](https://drive.google.com/uc?export=view&id=1gw-_2lUZGfmsqiWMYJyuIsGF_aYXhbCQ)

#### リリース判定項目対応状況

リリース判定の条件を満たしているか記述。もちろんこれが記述できるのはテスト結果報告後。

![000040.jpg](https://drive.google.com/uc?export=view&id=1lLDLJzRfYlbaCx93mgzct6vxWdbCxDup)

#### リリースについて

リリース判定承認、否決時の対応について明確にしておきます。

![000050.jpg](https://drive.google.com/uc?export=view&id=1FcHdW5aw4aRvQCfrgi9lj-xi8tftAzjg)


## 一般的には（参考）

### 実践ガイドブックでは？

実践ガイドブックにはリリース判定に関するテンプレートはありませんが、受入テスト計画書の「合否判定基準」がある程度参考になります。

合否判定基準の記述は下記の通り。品質基準、合否判定基準に加え、不合格時の対応などもありますね。

<img width="550" alt="000060.jpg" src="https://drive.google.com/uc?export=view&id=1EG4610Rr2DG54eFK6l6VRS5oFoKKKRUH">

また、リリース判定という言葉ではなく、（本番への）移行判定・稼働判定の基準についての說明が本編（第3編7章 設計・開発 P58）に存在しており、それぞれについて「いつ」、「誰が」、「何を判定するために」、「どのような条件で」、「どのように」判定するのかを決定・合意しておくべきとしています。

なお、移行判定と稼働判定の差は以下としています。

<img width="800" alt="000070.jpg" src="https://drive.google.com/uc?export=view&id=1Oh9vKtHLb1fUv79dEDHMz3imJsCBKSrl">

* 移行判定：リリースしてもいい状態かを判断
* 稼働判定：実際に稼働させる判断

という感じのようです。

## 参考

* [デジタル庁 デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard_guidelines/)
* [DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック　各種テンプレート](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/ec6f6641/20220422_resources_standard_guidelines_guideline_09.zip)
ターミナルでファイルをコピーしてフォルダごとに分ける

## 授業の資料を複製
Keynoteを章立て分コピーしてフォルダ内に分けるというのを手作業でやるには現実的ではなかったので、ターミナルを使ってやる事に。

やりたかったのは、
* 文字列操作
* 繰り返し複製＆フォルダ分け
* 指定フォルダに移動
といったところだったが、何せ`なんちゃってCUI慣れ`している状態だったので、そこそこの期間を要したのはここだけの話(白目)
最終的なコマンドは以下の内容になったので、備忘録的に記しておく。

```
for var in `ls *.key`
do
 mkdir ${var%.*}

 for i in {1..5}
  do
      cp $var ${var%.*}_0$i.key
 done
rm $var
 for i in {1..5}
  do
   mv ${var%.*}_0$i.key ${var%.*}/${var%.*}_0$i.key
 done

done

```

## 文字列操作
ターミナルで文字列操作をするという事が今までなく、その機会があっても手作業で逃げられるところは逃げてしまっていた次第で。改めて文字列操作と、その確認方法を復習。

### デバック
#### echo
編集した文字列を確認したい場合を先に記しておくと、`echo`というコマンドを覚えておく。
これは、結果をそのままターミナルに表記するので、文字列操作の確認時はまず必要な機能にはなってくる。
…ここに辿り着くにもそこそこ時間がかかったのもここだけの話(白目)


#### script
結果をテキストに保存するという事も可能。
`$ script sample.txt`で、テキストファイルに書き出し、`exit`で書き出し終了という流れで使える。自分の場合は、基本`cd`でディレクトリ指定して作業するので、書き出されるテキストファイルはそのディレクトリに保存されてる。

自分の使い方としては、ffmpegの書き出し結果が毎度見切れる＆見づらいので、テキストに出力するようにしている。

参考記事
https://qiita.com/mihooo24/items/d67c2b14729dfaefa1a8

### 拡張子を消す
ディレクトリを作るために、ファイル名を抽出する。
ここはKeynoteの`〜.key`を消したいところなので、`.`で分割しようと思う。
`${var%.*}`

参考記事
https://qiita.com/aosho235/items/c36568830a8d47288284

## 繰り返しの複製＆フォルダ分け
繰り返しの作業はfor文を使用したのだが、連番をファイル名に入れるのに頭に番号がついてしまうとカリキュラムごとにまとめるのが面倒に。
なので、ファイル名の後に連番を付与するとする。

### ファイル名と拡張子の間に連番を付与して複製
ファイルの複製は`cp`コマンドを使用。
`cd <複製する元ファイル> <複製後のファイル名>`という書き方になる。

ここで、ファイル名と拡張子の間に連番を入れるという部分をまとめる。

```
 for i in {1..5}
  do
      cp $var ${var%.*}_0$i.key
 done
```
元々for文で繰り返し作業をするのだが、`i` の部分に繰り返し番号の整数が入るようになっているので、これを使用する前提とする。1番目のループということで、1を使いたかったら`$i`と書けば、1番目のループで1という整数が使える。

文字列の連結に関しては、`$~`で変数を使用する事ができるが、文字の結合に関しては、C#などの記法`+`などは不要となり、そのままつなげてしまって良いようだ。

これはフォルダ名を付けるための文字列操作と同じコマンドなのだが、ファイル名の定義なので、連番の後に分割してしまった拡張子を付け直す必要がある。それが`〜.key`の部分になる。

## 指定フォルダに移動
ファイルの移動に関しては、冒頭のファイル名を使用した`mkdir`で作成されたディレクトリに、連番付与されたファイルを`mv`コマンドを使って移動させる。

`mv <元のファイル名> <移動先ディレクトリ名＆ファイル名>`
ここで注意しないといけないのが、連番を付与したファイル名を再定義する事と、ファイル名をディレクトリとしたので、もう一度ディレクトリ名を定義しないといけないという点＆ファイル名も再定義する必要があるという事。
基本前に使ったコマンドをコピペする形で再定義は可能。

```
 for i in {1..5}
  do
   mv ${var%.*}_0$i.key ${var%.*}/${var%.*}_0$i.key
 done
```

以上がターミナルでファイルをコピーするコマンド一覧になります。
もうちょっとでターミナルに慣れてきた感あるぜ…
「運用マニュアル（業務）」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## 運用マニュアル（業務）の概要

運用マニュアル（業務）では、システムを利用して行う業務の手順を記載しています（かなり簡易です。すみません）。
また、システムを利用したい業務手順についても、流れとして記載しています。

|項目|内容|
|-|-|
|作成目的|運用（業務）の手順の說明|
|記述すべき内容|各種業務の実施手順|
|作成タイミング|運用テストの実施まで|
|対象者|運用担当者（非技術者）|
|ファイル形式|パワーポイント, Excel, Word|
|備考|いちおう業務マニュアルも作ってみます|

>一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。

### サンプルダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=134M_mEWjpop0fBEL6F5tnisIFBDcshwv)から。

## 作成してみる

では、作成していきましょう。

### 作成方針・ポイント

作成のポイントは特にありませんが、実際に運用を担当するメンバーの業務経験やITリテラシ等を考慮した内容にすべきと思います。代表的な業務を１例にサンプルマニュアルを作成し、事前にレビューを受けるなどが理想です。

>既にマニュアル的なものがある場合はその形式に準拠する方がユーザーフレンドリーかもしれません。

### 構成（目次）を考える

今回は下記のような項目を記述してみました。

* 運用業務一覧
* 新規問合せ確認および対応業務概要 [業務例１]
* 補足：スプレッドシートの開き方（業務手順）
* 補足：メール返信テンプレート（テンプレート等）

>概要、補足情報を業務分用意します。

### 記述例（サンプルから１業務抜粋）

では、サンプルの主要なページについて少し解説したいと思います。

>本当にサンプルで書いてるだけで、実業務ではもっとしっかり書くべきです。

#### 表紙

特に補足はありません。

![000001.jpg](https://drive.google.com/uc?export=view&id=1hbTsosnguxpON7ReBy7Y2zM4rnaQEMAt)

#### 目次

こんな感じ。

![000010.jpg](https://drive.google.com/uc?export=view&id=1e5fpaZgJiHeYoIXLe3QkRI4Gx0nKvGL8)

#### 運用業務一覧

まずは当該資料で說明の対象となる業務の一覧を提示しています。

![000020.jpg](https://drive.google.com/uc?export=view&id=1x943zR_QtBexgg29w5HJ6axhhTmtAgEI)

#### 新規問合せ確認および対応業務概要（業務概要）

そして、各業務の概要を說明。

![000030.jpg](https://drive.google.com/uc?export=view&id=1gnHgBHE1IcuWgmKvkxW1WuOd6MWg43El)

#### 補足：スプレッドシートの開き方（業務手順）

それぞれのサブタスクに応じた補足說明をしています。
ここではスプレッドシートを見る方法を說明（かなり手抜き）。

![000040.jpg](https://drive.google.com/uc?export=view&id=1cnNXKtDqWnZJhNM6zxT7vK06aKPpxhgR)

#### 補足：メール返信テンプレート（テンプレート等）

場合によりメールのテンプレートやQ&A例などを提示する場合もあるかと思います。

![000050.jpg](https://drive.google.com/uc?export=view&id=1lWoo3j_FveNcAfdhY2N-Cc2jNPnAEDrS)

#### 対応済み（終了）問合せ削除業務（概要）

２つめの業務の概要。

![000060.jpg](https://drive.google.com/uc?export=view&id=1k6VyIaRNTwmFr7MigRNW-WunPMnbGUzj)

#### 補足：スプレッドシートの開き方

同様にスプレッドシートの開き方。

![000070.jpg](https://drive.google.com/uc?export=view&id=1z0zPjXu5pRuP1opZL2tfMndAPObCZ5lR)

#### 補足：スプレッドシートのバックアップ

バックアップの方法。

![000080.jpg](https://drive.google.com/uc?export=view&id=1kLFVf3VvPxYl78OpQErH6F7XoidW-IuB)

#### 補足：終了案件の削除

削除方法。

![000090.jpg](https://drive.google.com/uc?export=view&id=1gf5enkpuvtnmEwZcDbb5n3146iuSsgkm)

## 一般的には（参考）

### 実践ガイドブックでは？

実践ガイドブックには運用マニュアルに関するテンプレートは共有されていませんが、業務マニュアルについては「業務マニュアル サンプル」とか「業務マニュアル　テンプレート」とかで検索すればサンプルが沢山見つかると思います。


## 参考

* [デジタル庁 デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard_guidelines/)
* [DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック　各種テンプレート](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/ec6f6641/20220422_resources_standard_guidelines_guideline_09.zip)
x | |= 1 （自己代入）について

## 環境
Ruby2.6

## はじめに
**x ||= 1**のような書き方をすることを、**自己代入**と呼びます。他言語からRubyに移った人から見れば、パッと見ただけでは、「何をやっているのだろう？」と思うものです。ググってみると、変数の値が下記の場合、右辺の値（この場合１）をセットするとあります。
- nil
- false
- 変数が定義されていない

３パターンに当てはまらない場合は、変数が現時点で保持している値を、そのまま維持し続けることになります。つまり、１に変換されません。

## 動作確認
x変数が未定義の場合、右辺の１を返します。x変数が未定義ということは、ロジックの上位個所で、x変数がまだ一度も現れていないということになります。x変数を始めて定義して、初期値に１をセットしたことと同じ意味になります。つまり、x = 1と同じです。
```test.rb
x ||= 1         # => 1
```

x変数に、nil or falseがセットされている場合、１に置き換えるという意味になります。
```test.rb
x = nil
x ||= 1         # => 1

x = false
x ||= 1         # => 1
```

**nilと ""** は別物です。nilの場合は１に置き換えても、""の場合は１に置き換えません。falseの場合は１に置き換えても、trueの場合は１に置き換えません。Boolean型とその他の型をごっちゃに考えること自体、混乱の元のような気がしますが・・・。
```test.rb
x = ""
x ||= 1         # => ""

x = true
x ||= 1         # => true
```

このように、文字列型、整数型は、当然、１に置き換えません。本来保持している元の変数が、そのまま有効になります。
```test.rb
x = "aa"
x ||= 1         # => "aa"

x = 1
x ||= 1         # => 1

x = 0
x ||= 1         # => 0
```
学生団体CAコラボに参加して刺激を受けた話

# はじめに

こんにちは！現在watnowという学生IT団体の運営メンバーをしています、山口結己と申します。

この記事では、2022年10月9日に行われた、「関西エンジニアカンファレンス2022」に行ってきた感想と変化した自分のエンジニア理想像について話していきたいと思います。

イベントの写真
![スクリーンショット 2022-10-19 1.51.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2609178/a1b9ebc7-ed3d-f97c-9bac-96766aacc5bb.png)
# イベントの流れ
今回のイベントは、
- **CA社員さんのLT**
- **各団体のLT**
- **交流会**

というような流れで行われました。
# CA社員さんのLT
まず、CA　社員2名によるLTが行われました。お二人とも若い年代でありながら、プロジェクトにおける裁量が大きく、「IT人材の育成」に力を注いでいるCAさんのリアルを実感できました。具体的には、未経験者でもトレーナーの方が1on1で付いてくださり、進捗管理や技術的な相談が可能な点や、開発の担当は職種関係なく選ぶことができる点がありました。以前、CA BASE NEXT 2022を拝見したときにも感じたことですが、「**若いうちからいろんな経験をたくさんしたい**」と思う人ならきっとCyber Agentさんは魅力的な会社であると思います。


# 交流会
ここでは、4つの分野に分かれて（モバイル・バックエンド・フロントエンド・CA社員さん）、自分が交流してみたい分野の人たちと自由にお話するといった形でした。自分はCA社員さんとたくさんお話をさせていただきましたが、現在興味のあるゲーム領域以外にもたくさん魅力的なところも知ることができ、終始ワクワクしていました。また他団体との学生ともたくさんお話させていただき、どんなインターンシップに行っているのか、将来の目標は何なのかなどを語り合い、いろんな刺激を与えてもらいました。

# 自分の理想像について
イベント全体に出席したことで、今まで自分が目指していた「理想像」に変化があったので、ここに書き記しておきます。
「もっとつかう人に喜んでもらえるモノ、もっとおもしろいモノにするために、よりよい手法を自分の作品を用いて提示できるような人材」になりたいと思うようになりました。まだ、自信をもって提示できるようなモノは作っている（技術を学んでいる）最中なので、これからもこのイベントを通じて獲得したモチベーションや刺激を大切に頑張っていきたいと思います！

# 最後に
イベントの感想についてもっと詳しく知りたい方は、watnowメンバーが出した記事が他にもありますので、そちらをご覧下さい。
[学生団体CAコラボカンファレンスに行ったらめっちゃ刺激を受けた話](https://note.com/syunya_fujisawa/n/nf2c178217c85)
[学生団体✖️CAイベント開催](https://note.com/nanndemokakuyo/n/n3950fb290ca3)


ここまで読んでいただき、ありがとうございました！
「テストシナリオ（指示書）」を作成してみる

この記事は、「[架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）](https://qiita.com/minimumskills/items/aedf6a93658db3f74747)」の記事の一部です。

## テストシナリオ（指示書）の概要

テストシナリオ（指示書）はテスト計画で設定した各種テストの具体的な実施内容、方法について記述したものです。

|項目|内容|
|-|-|
|作成目的|各テストの具体的な内容を指示する|
|記述すべき内容|テストの内容（シナリオ）、実施環境、方法|
|作成タイミング|テスト実施の前|
|対象者|テスト実施者（技術者）|
|ファイル形式|パワーポイント、Excel、Word|
|備考|普通は各テスト毎に分けますが、サンプルでは一緒に書いちゃいます|

>一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。

### サンプルダウンロード

サンプルのダウンロードは[こちら](https://docs.google.com/uc?export=download&id=1nJW1pxmZedLQaHTpvvNLq22YtWz_j3tj)から。

## 作成してみる

では、作成していきましょう。

### 作成方針・ポイント

通常、テストシナリオはかなり膨大になるので、テスト別に分けて作成しますが、ここでは1つのファイルにまとめ、かつ、最低限の記述だけ行ってみます。

### 構成（目次）を考える

今回は下記のような項目を記述してみました。
まあ、実施するテスト毎に必要な内容を淡々と記述するだけ。

* 機能テスト（シナリオ）
  * 単体テスト
  * 結合テスト
* 非機能テスト（シナリオ）
  * 可用性テスト
  * 性能テスト
  * セキュリティーテスト
  * 留意事項１：Webの公開
  * 留意事項２：推奨ブラウザでの正常閲覧確認

### 各内容を記述する（サンプルの說明）

では、構成に従って作成したサンプルの内容について解説したいと思います。

#### 表紙

特に細くはありません。

![000001.jpg](https://drive.google.com/uc?export=view&id=18_lK9EwOFIWcIYAnJ_T4E-sWmr84_9N5)

#### 目次

こんな感じ。

![000010.jpg](https://drive.google.com/uc?export=view&id=1J1V-T7OTo-1Jyz9wJL6ExTWtGSSSJBTx)

#### 機能テスト：単体テスト

通常は数十から数百に項目が及ぶのでExcelで管理することが一般的です。
また、テストカテゴリも以下を行うのが一般的かなと思います。

* 正常系：正常な動作をテスト
* 境界値系：以上、以下などの境界値が正常に処理されるか
* 異常系：異常値が与えられたときに期待通りの動きをするか

>開発コンテンツの方の実装も少しだけ実装してます。すみません。

![000020.jpg](https://drive.google.com/uc?export=view&id=1UGd2jQbHoezyrtR-lkWgWiojJAeFfE1R)

#### 機能テスト：結合テスト

単体テスト同様、通常は数十から数百に項目が及ぶのでExcelで管理することが一般的です。
またカテゴリも正常系、境界値系、異常系を行うのが一般的でしょうか。

あと、多くの場合

* １回目は手動
* ２回目以降は自動化

とかやるときもあります。

>開発コンテンツの方でも一部自動化してます。

![000030.jpg](https://drive.google.com/uc?export=view&id=1MnCLZy9hmAO8mz2eKDWxTXCrqZg5SsRO)

#### 非機能テスト：可用性テスト

サーバレスサービス使うのでSLAとかだけキャプチャするように設定しています。

![000040.jpg](https://drive.google.com/uc?export=view&id=1sHvTP0L28yvPSK6dUbGecKHjjOjOL-Wo)

#### 非機能テスト：性能テスト

性能テスト用のスクリプトを書いて実行することを想定。

![000050.jpg](https://drive.google.com/uc?export=view&id=18i8LWOn78ndKvblX_q_0dIRu0u4W5XPF)

#### 非機能テスト：セキュリティーテスト

OWASP-ZAPでなんちゃってテストを行うことを想定。

![000060.jpg](https://drive.google.com/uc?export=view&id=1HVYfd6BBIXgNVgSD1OFW5v5Rcv7zRVCg)

#### 非機能テスト：留意事項１

その他、機能テスト以外で追加があれば記述。

![000070.jpg](https://drive.google.com/uc?export=view&id=1Un-hqqACXeMQ5qA9FhyUEXHX7H0uIcF2)

#### 非機能テスト：留意事項２

その他、機能テスト以外で追加があれば記述。

![000080.jpg](https://drive.google.com/uc?export=view&id=1cVoG7_AP08qdiEyf74PtxyfXmLcH4Dcx)

## 一般的には（参考）

### 実践ガイドブックでは？

残念ながら実践ガイドブックではテストシナリオのテンプレートは提供されていません。また、項目等も提供されてないです。。。

受入テスト計画書のシナリオのセクションには下記のような項目例が記載されています。
説明書きにも記載されていますが、受入テストは結合や総合テストなどのシナリオをベースにすることが多いため、あまり細かくフォーマットが記述されていません。

<img width="500" alt="000150.jpg" src="https://drive.google.com/uc?export=view&id=1DmmBDeseClLfonaHNdW2LnLjSq7Oxb1y">

とはいえ、悩むことはなく、複雑なフォーマットは不要で、

* 一覧でテストの内容を列挙
* 必要に応じて各テストの実施内容を記述

が基本になるかと思います。

## 参考

* [デジタル庁 デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard_guidelines/)
* [DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック　各種テンプレート](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/ec6f6641/20220422_resources_standard_guidelines_guideline_09.zip)