OmniAICreator/Qiita-1.07M huggingface dataset:
Google DomainsからCloudflareにドメイン移管する

Google Domains、終わるらしいですね。
ちょうどいいのでこれを機にCloudflareにでも
移管してみようと思ったので記録します。

# 前提
移管前の構成としてはGoogle Domainsで取得してDNS設定などはCloudflare側でしています。
ネームサーバーもCloudflareのものです。
つまりもうドメインの登録自体は終わってるって感じです。

# Google Domainsでロック解除と認証コードの取得
まず移管の設定を探します。このへんかな....
<img width="300" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/4592fdad-a6cb-a9b5-19f5-6fdde1ecbaab.png"> 
それっぽい設定がありました。　
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/17e90923-f9de-7b90-67d7-a092577bdbce.png"> 
移管には「認証コード」が必要みたいです。「認証コードを取得」をポチッと...
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/80267bb3-48d6-0566-3b60-30d885ad2367.png">
ロック解除しろと言われるがままに解除します。
次の画面で認証コードが発行されます。(あとから確認できますがメモしておきましょう)

:::note info
**つまり何をした**
Google Domainsの「登録の設定」より
「ドメインのロック解除」と「認証コードの取得」をする。
:::

:::note warn
**DNSSECについて**
前提においてCloudflareのネームサーバーを使用しているのでDNSSECの解除は不要と判断しました。
ただ状況によっては解除した方が問題なく手続きできるというサイトもあったので念のためリンクしておきます。
[Google Domains終了へ！移管の際はご注意ください](https://www.value-domain.com/media/google-domains-transfer/)
:::

# Cloudflareで移管手続き
必要なものが揃ったのでいよいよ移管手続きです。
サイトダッシュボードのこの辺から移管できそうですが...
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/ace1c1d4-3e60-9acc-e47d-cf55f06fe9aa.png">
グレーアウトして選択できない、マウスホバーすると...
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/1b14d997-4222-9dc2-d25f-9efdb84f7b98.png">
まだロック解除されたことに気がついてない or 内部的にはまだロック状態みたいです。
本当に数時間かかったので選択できるようになるまで待ちましょう。

移管できるようになったら画面の指示に従って手続きを進めます。
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/161d51a3-d4f4-2475-f82f-94b8998bd41d.png">
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/3eea5870-5362-b0fa-a4f6-25e034854637.png">

<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/e7dadde2-fd71-f62a-0e11-4c7b2b7fcac1.png">
 
移管中はこんな表示になります。自動更新つけておきましょう。
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/316959d9-b4b9-f1e8-8c2d-855e3e4e0253.png">

# Google Domainsで承認

しばらくするとGoogle Domainsから「移管リクエスト来たで～？」ってメールが来るので、
メール内リンクをクリックします。
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/7300481d-0f78-8981-b82f-ed628e58cc78.png">
書いてある通り、放置してても勝手にやってくれるようですがせっかちなので「移管」をクリックします。

# 完了！

承認さえしてしまえばもう終わりです。
Cloudflareから「移管おわたよ～」ってメールが来てるはずです。
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/d316c88b-2390-d7d2-bcff-742d5b3af5bb.png">
ダッシュボード上の表示もアクティブになっています。
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184264/328d4fd7-8ed1-a88e-a587-e80bceba66e0.png">
「ドメインの管理」>「構成」>「DNSSEC」を確認しましたが特に問題ないようです。

# 終わりに
今回はGoogle DomainsからCloudflareにドメインを移管する手順を紹介しました。

手順は難しくありませんがとにかく処理に時間がかかるので、
朝から別作業しつつたまに確認するぐらいの空気感で移管手続きをするのがいいのかなと感じました。

ちなみに移管するときにCloudflare側で1年分を追加する支払いが発生したのでそこはご注意を。
支払い情報未登録の場合はわからないです。
【超要約】UnityによるVisionOSのサポートについて: ベータプログラムの登録

# VisionOSのUnity対応の記事が出た？

https://blog.unity.com/engine-platform/unity-support-for-visionos

2023年7月19日
こんな英語記事が出たので日本語で要約していきます。

結論からいうと、2023年7月20日2:00現在ではすぐ使えるわけではなく、ベータプログラムの登録ができるようです。やっていおきましょう。

# 超要約

準備できることとして何をすべきかブログには書かれていました。

- Apple Vision ProのサポートとPolySpatialテクノロジーについて、[UnityのWWDCセッショントーク](https://developer.apple.com/visionos/)を見ておこう
- [Unity Hub](https://unity.com/download)からUnity 2022.3 LTS (2022.3.5f1+)をインストールしてプロジェクトをアップグレードしよう
- UnityのXRツールに慣れよう。具体的には
    - [AR Foundation](https://unity.com/unity/features/arfoundation?clickref=1100lwW8wLyV&utm_source=partnerize&utm_medium=affiliate&utm_campaign=unity_affiliate)
    - [XR Interaction Toolkit](https://docs.unity3d.com/Packages/com.unity.xr.interaction.toolkit@2.3/manual/index.html)
- プロジェクトをVisionPro向けに準備しよう
    - レンダリングパイプラインを[URP (Universal Render Pipeline)](https://docs.unity3d.com/Manual/universal-render-pipeline.html)にする
    - コントローラーベースのインタラクションを[ハンドベース](https://docs.unity3d.com/Packages/com.unity.xr.hands@1.0/manual/project-setup/install-xrhands.html)に変換する
    - [Unity Input System](https://docs.unity3d.com/Manual/com.unity.inputsystem.html)を使用する
    - [Shader Graph](https://docs.unity3d.com/Packages/com.unity.shadergraph@14.0/manual/Getting-Started.html) or Standard Shaderを利用する
- Unityのベータプログラムに参加希望者向けに登録する
    - 申し込みは[こちら](https://create.unity.com/spatial)

# ベータプログラムの登録

↓申し込んでみると次のような画面になる。
ベータプログラムの参加が決定したらメールでお知らせしてくれるようです。待ちましょう！

https://create.unity.com/spatial

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96970/f39489c6-ff7c-8db7-ebe1-0bd169cca13a.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/96970/01c702a0-3b98-2391-b428-56517ad62fd3.png)
JavaScriptで簡単な開閉メニュー

<h1>・はじめに</h1>

　JavaScriptとCSSを利用して簡単なアコーディオンメニューを作ったのでそれを記録する記事です。もっとこうすればいいよなどのアドバイスがあればよろしくお願いいたします。

<h1>・コードと解説</h1>

　今回作ったアコーディングメニューはcheckboxを利用したもので、１つ開くと他が閉じる仕様ではなく、開こうと思えばすべて開くことができるようになっています。

・処理の流れ

　CSSでクラス名を指定してメニューの内容を非表示にする⇒JavaScriptでチェックボックスをクリックしたとき、チェックボックスがtrue状態に変われば、CSSの非表示のクラス名を削除して表示状態に、反対にfalse状態に変わればCSSの非表示クラス名を追加させて非表示状態にする

という流れで行います。

```HTML:HTML
    <label>
    <input type="checkbox" data-checkbox="0">メニュー１
    </label>
    <p class="content" data-content="0">メニュー１の内容です。</p>

    <label>
    <input type="checkbox" data-checkbox="1">メニュー２
    </label>
    <p class="content" data-content="1">メニュー２の内容です。</p>
```

```CSS:CSS
    .content {
        /*メニュー内容の表示を非表示にする*/
        display: none;
    }

    input[type="checkbox"] {
        /*チェックボックスのチェックマークを消す。作成時はわかりやすいようにつけておいた方がいいかもしれません*/
        display: none;
    }
```

```JavaScript:JavaScript
(()=> {
    const $doc = document;
    const $checkbox = $doc.querySelectorAll('[data-checkbox]');
    const checkboxLen = $checkbox.length;
    const $content = $doc.querySelectorAll('[data-content]');
    const CONTENT_CLASS = 'content';

    const changeClassName = (e) => {
        const $this = e.target;
        const targetVal = $this.dataset.checkbox;
        //クリックされたチェックボックスを指定
        const $designatedCheckbox = $checkbox[targetVal];

        $designatedCheckbox.addEventListener("change", ()=> {
            //もしチェックに変化したら
            if($designatedCheckbox.checked) {
                //contentクラスを削除し、内容を表示させる
                $content[targetVal].classList.remove(CONTENT_CLASS);
            //もしチェックが消されたら
            } else {
                //contentクラスを追加し、内容を非表示にさせる
                $content[targetVal].classList.add(CONTENT_CLASS);
            }
    });
};

    //ループ文を使って発火させる(スコープによりどこのcheckboxが押されたかを特定できないのでこのような表現になっている)
    let index = 0;
    while(index < checkboxLen) {
        $checkbox[index].addEventListener('click', (e) => changeClassName(e));
        index++;
}
})();
```

<h1>・おわりに</h1>

　これで完成です。デザイン面のコーディングは特にしていないのでそちらはご自由にお願いします。
Mac のプロンプト表記で苦労した

# 目次
[1. bashとzshでプロンプト表記の書き方が違うらしい](#1-bashとzshでプロンプト表記の書き方が違うらしい)
[2. bashの書き方とzshの書き方を対応させてみた](#2-bashの書き方とzshの書き方を対応させてみた)
[3. まとめ](#3-まとめ)
[参考文献](#参考文献)

# 1. bash と zsh でプロンプト表記の書き方が違うらしい
会社から開発用に Mac が貸与された．イケてるターミナルを作ろうとプロンプト表記をいつも使っている設定を .bashrc から持ってきてそのまま Mac の .zshrc に張り付けても思い通りにいかなかった．
![prompt01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2600771/e3c18acf-dedc-727c-3ad6-dd273a8c2d2f.png)
*プロンプトとはこれのこと*

# 2. bash の書き方と zsh の書き方を対応させてみた
上の画像のようにプロンプトを設定したい場合の書き方を示します．
```shell:bashとzshプロンプト設定の比較
# bash
export PS1='[\[\e[1;32m\]\u@***\[\e[0;0m\] \[\e[1;34m\]\W\[\e[0;0m\]]\$ '

# zsh
export PROMPT='[%B%F{green}%n@*** %F{blue}%c%b%f] %# '
```
||bash|zsh|
|:-:|:-:|:-:|
|環境変数|PS1|PROMPT|
|ユーザ名|\u|%n|
|カレントディレクトリ|\W|%c|
|ユーザ種別|\$|%#|
|太字|\[\e[1\\]|%B|
|太字リセット|\[\e[0\\]|%b|
|緑色|\[\e[32m\\]|%F{green}|
|色リセット(白色)|\[\e[0m\\]|%f|
|カギかっこ等のエスケープ|\ |不要|

Bash の例では太字と色を ";" でつないで同時に指定しています．
"\*\*\*"の部分には PC の名前を適当に入れてます．自分はwsl2をよく使うので "wsl" とか入れてます．

bash と zsh ともに，すべての設定方法についてここでは言及しないので，参考文献を見るなり自分で調べるなりしてほしい．
これというプロンプトが見つかったら，.bashrc なり .zshrc なりに書きましょう．

# 3. まとめ
Mac 好きじゃないけど green とか使えちゃうあたりいいよね．てかそもそも設定自体シンプルでわかりやすい......

# 参考文献
- bashのプロンプトを変更するには, https://atmarkit.itmedia.co.jp/flinux/rensai/linuxtips/002cngprmpt.html, 2023-07-20 確認
- ターミナルプロンプトの表示・色の変更, https://qiita.com/hmmrjn/items/60d2a64c9e5bf7c0fe60, 2023-07-20 確認
- zshでプロンプトをカラー表示する, https://qiita.com/mollifier/items/40d57e1da1b325903659, 2023-07-20 確認
- 【zsh】いろいろなプロンプト表記 まとめ, https://qiita.com/syoshika_/items/0211c873475eb0d59e23, 2023-07-20 確認
応用情報のメモ

# 忘れるのでメモ用

## 信頼性のやつ

フェールセーフ 
英語："FailSafe"
目的：危なくなったときに安全を優先する。
…　障害が発生した際、障害を最小限に抑えて安全を最優先にする。

フェールソフト
英語："FailSoft"
目的：処理を継続させる。
…　障害が発生して機能が落ちつつも安全な状態に移行させて稼働させる。

フォールトトレランス(フォールトトレラント)
英語："FaultTolerance" トレランス(許容範囲)-> 耐障害性
目的：機能を保つ。
… 障害が発生しても機能を落とさずに稼働させる。

フールプルーフ
英語："FoolProof" プルーフ(証明)-> 絶対確実
目的：ミスを起こさない設計を立てる。
… 誤った操作ができないようにする。

フォールトアボイダンス
英語："FaultAvoidance" アボイダンス(避ける)-> 障害回避
目的：障害・故障をできる限り発生しないようにする。

フォールトマスキング
英語："FaultMasking" マスキング(遮蔽)
目的：障害による影響を外部に漏らさない。

## ○○可能プログラムのやつ
再入可能、再使用可能、再帰可能、再配置可能

https://www.ap-siken.com/kakomon/03_aki/q6.html

### ChatGPTが提案した覚え方
物語やアナロジーを用いて覚えやすくしたそうです。
```
「信長の遺志、そして三英傑とゴリラの出会い」

信長は天下統一の野望を胸に秘め、全国の城を制覇していった。
しかし、それぞれの城には異なる仕掛けが施されていた。
特に「織田城」は、「リエントラント（再入可能）」の性質を持っていて、
多くの武将たちが同時にこの城を攻めても、
城の内部の仕掛けはそれぞれの武将に対して
異なる反応を返していた。

信長が天下を統一する過程で、
彼の右腕として活躍していたのが秀吉だった。
秀吉は信長から「永遠の籠」を託されていた。
この籠には**リユーザブル（再使用可能）**の性質があり、
一度中に物を入れると、その物は何度取り出しても籠の中に残っている。
秀吉はこの籠を使って、物資を常に手元に持って戦を有利に進めた。

家康は、信長や秀吉とは異なる方法で天下を取ろうとしていた。
彼の得意技は「自己呼出の術」。
この術は、家康自身が再び自分を呼び出すことができる、
まさに**リカーシブ（再帰可能）**の性質を持った技で、
一度この術を使い始めると、同じ場所に次々と家康が現れた。

ところが、この三英傑の前に突如としてゴリラが現れる。
このゴリラは特別な「場所移動の腕輪」を持っていて、
腕輪を使うとどこにでも自由に移動できる。
ゴリラはこの腕輪の力で、瞬時に山の頂上から谷底、
さらには城の中心まで自在に移動していた。
この腕輪の性質は、**リロケータブル（再配置可能）**と呼ばれるものだった。

三英傑とゴリラ、彼らはそれぞれの特技を活かして、
新たな歴史を築き上げていくこととなった。

上記の物語では、信長、秀吉、家康、そしてゴリラが
それぞれ異なる特性やアイテムを持ち、
四つの用語の概念を具体的に表現しています。
```
JavaでCSVファイルを読み込む（気象庁のデータから最高気温を記録した日を調べる）

### 前置き
暑すぎる毎日たまーに風が吹くと天に向かって感謝します。

今回は前回の続きで読み込んだデータから最高気温を記録した日付と最高気温をコンソール出力してみました！
※JavaGoldの資格範囲からちょっぴり脱線します。

### 取得したデータを再確認
取得方法は前回投稿した通りです。
１～６行目までは列名など不要なデータです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3484672/1558ffe4-3603-122a-4f99-921cf8b6982d.png)


今回はデータの中で名古屋に絞って最高気温を記録した日を出力してみました。

「え、岡崎もやれよって？」

「すいません、忙しいからさぼりました(´;ω;｀)」

### プログラム
前回から特に変わったことはしていません。
今頭の中にある知識だけでソース組んでみました。

「きっと世の中にはもっとティピカルな方法があるんだろうなー...」
（最近、会社のすごい人がティピカルってよく使うから使ってみた笑）
```java
public class Main {
	public static void main(String[] args) throws Exception {

		String maxDate = ""; //最高気温を記録した日付
		String maxTemperature = ""; //最高気温
		int i = 0; //読み込み行数

		//csvファイルを読み込む
		FileInputStream fis = new FileInputStream("C:\\Users\\user\\Documents\\study\\data.csv");

		try {
			String line; //1行分のデータを保持

			//Shit-JISで読み込む
			try (BufferedReader b_reader = new BufferedReader(new InputStreamReader(fis, "Shift-JIS"))) {

				//lineに読み込んだ1行分のデータをセット。次に読み込んだ行がnullになるまでループ
				while ((line = b_reader.readLine()) != null) {

					//i行目のデータを処理中
					i++;

					//１～６行のデータは不要なためスキップ
					if (i < 7) {
						continue;
					}

					//配列に「,（カンマ）」で区切った値をセット
					String[] data = line.split(",");

					//7行目(1つめのデータ）は必ずセット
					if (i == 7) {
						maxDate = data[0]; //日付をセット
						maxTemperature = data[2]; //最高気温をセット
					} else {
						//最高気温を更新していたら、値をセット
						if (Double.parseDouble(maxTemperature) < Double.parseDouble(data[2])) {
							maxDate = data[0];
							maxTemperature = data[2];
						}
					}
				}
			}
			//最終結果をコンソールに出力
			System.out.println("対象期間で一日の最高気温が最も高かったのは");
			System.out.println("日付：" + maxDate);
			System.out.println("最高気温：" + maxTemperature);
		} catch (UnsupportedEncodingException e) {
			System.out.println(i + "行目で読み込み失敗しました");
		}
	}
}
```
splitメソッドで１行分の文字列をカンマ区切りでStringの配列にしているところがポイントです！

### 実行結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3484672/1c210600-e4e9-7faa-e7c2-d66beaf750ef.png)

とりあえず以上！

### 後書き
現場でGitに関する事件が起きたのでこれからJavaGoldの資格試験に関する記事と
Gitに関する記事を並行して投稿していこうと思います
Gitで派生元ブランチを間違えた時の確認と修正方法

# はじめに
チーム開発におけるGit運用で、運用方法が下手な故に間違えた派生元からブランチを切ってやらかすことがたまにあるので、その救済方法を書きます。
# やること
- 派生元ブランチの確認
- 派生元ブランチの変更

## 派生元ブランチの確認

```
確認したいブランチに切り替えた状態で

git show-branch | grep '*' | grep -v "$(git rev-parse --abbrev-ref HEAD)" | head -1 | awk -F []~^[]' '{print $2}'

// 結果
master
```

同一ブランチで暫く開発している時に「あれ、このブランチの派生元って間違ってないよね...」と不安になることがあるので、そういう時はこのコマンドで確認します。

## 派生元ブランチの変更

```
// git rebase --onto {本来親にしたかったブランチ} {間違って親にしたブランチ} {親を変更する作業ブランチ}
git rebase --onto origin/master develop test-branch
```

派生元のブランチが間違えていても、このコマンドを実行することで変更後のブランチをベースに自動でコミットを作成してくれるようです。

# 最後に

こんなことをする必要がない運用を心掛けたいです。
Qiitaで色付き背景メモ(？)３種の構文

# Qiitaで色付き背景メモ(？)３種の構文

__前文__
すぐ忘れるのでメモ。見ての通り、**太字**も使えるし`インラインコード`も使える。

表示順：緊急性だか重要性だかの低い順。

[追記＠2023/12/05]
色味：ダークモード時は記載の色味とは異なります
 「グリーン系」 → 濃い緑
 「クリーム系」 → 茶系
 「ピンク系」 → 濃い赤

## チェック印(✔︎)＋グリーン系背景

:::note
`:::note`と書く
チェック印(✔︎)＋グリーン系背景 は`:::note`と`:::`のブロック。
`:::`と`note`の間は ❗️半角スペースなし(空けない)
`note`は ❗️小文字
**太字**も使えるし`インラインコード`も使える
noteは、(この場合は)**備考**という意味
:::
```
:::note
`:::note`と書く
チェック印(✔︎)＋グリーン系背景 は`:::note`と`:::`のブロック。
`:::`と`note`の間は ❗️半角スペースなし(空けない)
`note`は ❗️小文字
**太字**も使えるし`インラインコード`も使える
noteは、(この場合は)**備考**という意味
:::
```

## びっくりマーク(！)＋クリーム系背景
:::note warn
`:::note warn`と書く
びっくりマーク(！)＋クリーム系背景 
は`note`後に半角スペースで続けて`warn`
warnは、**注意**などの意味
:::
```
:::note warn
`:::note warn`と書く
びっくりマーク(！)＋クリーム系背景 
は`note`後に半角スペースで続けて`warn`
warnは、**注意**などの意味
:::
```

## バツ印(x)＋ピンク系背景 
:::note alert
`:::note alert`と書く
バツ印(x)＋ピンク系背景 
は`note`後に半角スペースで続けて`alert`
alertは、**警告**などの意味
:::
```
:::note alert
`:::note alert`と書く
バツ印(x)＋ピンク系背景 
は`note`後に半角スペースで続けて`alert`
alertは、**警告**などの意味
:::
```
入緑しました。これまでやったことと、競プロをやっていてよかったこと

入緑記事です。振り返りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1919799/c7defc60-28b9-8065-7d64-841d024575c3.png)

## やったこと
### 毎週参加
C問題まで解けて、ある程度D問題も解けたので、パフォーマンスがだいたい800を超えていました。
800ちょい超え程度だと、上昇量は少ないです。でもやっていれば上がります。
そうして、とにかくやっていたら緑になりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1919799/9b4af90a-3276-5ebe-5029-c4cdbcf5be3a.png)
途中Unrated続きで心が折れてました。折れながらもルーティン的に続けられたので、習慣の勝利。(^^*)
結果論、Unratedだとしても、1時間40分集中しているときが一番成長を感じるので、それも含めて糧になっていると思います。

### 資格取得
基本情報と応用情報を取りました。
資格自体はAtCoderの特効薬にはなりませんが、取得の過程で身についた力がAtCoderに活きていたと感じました。
> アルゴリズム問題で身についた力は3つ、問題に取り組む忍耐力と、仕組みを考える力と、具体的な実装に起こす力です
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">AtCoder緑になったの、もちろん毎週参加でチマチマ上げたのもあるのですが、<br>主要因は基本情報・応用情報のアルゴリズム問題だと思いました<br><br>アルゴリズム問題で身についた力は3つ、問題に取り組む忍耐力と、仕組みを考える力と、具体的な実装に起こす力です<br>競プロ対策には遠回りなものの超良い資格</p>&mdash; れあ (@rare0b) <a href="https://twitter.com/rare0b/status/1681613717560233984?ref_src=twsrc%5Etfw">July 19, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

### 高校数学やり直し
数Ⅲまで一通りやりました。あと、線形代数もやりました。
具体的に技術が身についたわけではありませんが、問題の解像度を上げるのに貢献しています。

例えば以下のような問題に活きていたと思います。
- 動的計画法を使うなど、漸化式的考えが必要
- Σや微積など、直接的に数学が出てくる

こちらの件はQiitaの記事にしています。
[1年目エンジニアが半年かけて高校数学をやり直した記録](https://qiita.com/rare0b/items/99eb4aea4648d3ac95eb "1年目エンジニアが半年かけて高校数学をやり直した記録")

## 競プロをやっていてよかったこと
### コーディングテストに強くなる
AtCoder茶程度あれば、難しいものを除くと、だいたい解けます。

現在、2days～5daysのインターン4社に参加が決まっています。
全部コーディングテストが解けたおかげです。

具体的な内訳は、
- Track Job経由→2社
- Paiza(Aランク)経由→1社
- 選考過程でコーディングテスト有り→1社

です。

毎週参加していれば、なまることもないので、急なコーディングテストでも安心です。

ちなみに、大変お世話になっているTrack Jobでは、25卒向けのインターン獲得できる(かも)なコーディングテストが開催されています。一緒にやりましょう
https://job.tracks.run/challenges/programmingtest-25-01


### 実務をコードで効率化できる
Excelやテキストファイルのチマチマ業務に時間を取られていたところ、VBAやPythonを書いて効率化できました。
実務でやっていること(≒競プロの問題で達成したいこと)を、どう実装するか考え、具体的な実装に起こす、という過程がまさに競プロで培ったものでした。

なんの参考にもならないと思いますが、以下実際にやったことになります。
「コードを書けたから業務が回った」なんてこともあり、私なりにバリューを発揮できたのは嬉しかったですね。

- VBAで書いたもの
  - 60万行のデータから、6千個のグラフを作成する
  - Excel管理のデータベース定義情報から、自動でDDL作成
  - マクロの記録でツギハギされた複数VBAを、必要なロジックだけ抽出し1つにまとめる

- Pythonで書いたもの
  - スキーマ名を変えてSQLファイルを複製する作業を、ファイルパス入力のみで実行
  - 数万行のSQL実行ログから、正規表現で必要な情報を抽出
  - テーブル作成DDLで、テーブル毎に個別の設定値を記入

あと、競プロではC++、業務ではVBAやPythonを書いていた私から言わせると、
競プロで身についた力は他の言語でも発揮できます。
頭の中で・紙の上で考える段階までは全言語共通で、具体的な実装も言語差あるものの共通点が多いですから、当然ですね。

ちなみに、VBAは置いといて、なんでC++じゃなくPythonなのかというと、
Pythonはライブラリが豊富で雑な書き方でもコードが動くので、ぱっと書いてぱっと使うハードルが低いです。
私の業務では競プロと違って、1,000,000,000の入力なんて無く、せいぜい1,000、多くて1,000,000程度です。O(N)で解決できる問題ばかりで、未コンパイルPythonでも十分高速ですから、C++よりもすぐコード書けるPythonを使っていました。

## おわりに
お読みくださりありがとうございました。

Twitterで話しかけて頂けると喜びます。よろしくお願いします。
また、CodeQUEEN参加予定です。参加される方も、されない方も、ぜひ仲良くしてください。(女の子のエンジニア仲間と、25卒仲間、ほしい…)
SwiftUIの基本パーツでドット絵風のマリオを作ってみた

## 作ったきっかけ
SwiftUIの基本であるHstackとVstackとSpacerをより理解するために何か作れないかと
思い作ってみました。

## 完成物
下記の画像になります。


　　　<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265372/008a4812-3f5d-a444-1900-b6fc750ae887.png" width=50%>

こちらの画像のコード載せようと思ったのですが単調ですごく長くなるので一部だけ載せて
残りはgitのURLを貼っておきます。
下記は帽子を作成しているパーツになります。
基本は作りたいドットに合わせてパーツを組み合わせていくだけなのですが
唯一注意するのは上下のパーツの位置を合わせる時に Spacer().frame(width: 20)等で
位置を指定してあげる必要があります。

```swift
struct ContentView: View {
    var body: some View {
        VStack {
            VStack(spacing: 0) {
                //帽子のパーツ
                Group{
                    Rectangle()
                        .foregroundColor(.red)
                        .frame(width: 50, height: 10)
                    HStack(spacing: 0) {
                        Spacer()
                            .frame(width: 20)
                        // 右にスペースを追加
                        Rectangle()
                            .foregroundColor(.red)
                            .frame(width: 80, height: 10)
                        Rectangle()
                            .foregroundColor(.red)
                            .frame(width: 10, height: 10)
                    }
                }
```

もし全て気になる方いらっしゃいましたら下記にあります。
https://github.com/yasuyamakyosuke/DotMario

他にもドット絵なら色々作れそうで面白かったです。
Qiita CLI + GitHub Actionsで記事を自動更新するためのワークフローを作成する

## はじめに

[Qiita CLIのv0.5.0](https://github.com/increments/qiita-cli/releases/tag/v0.5.0)がリリースされました:tada:
アップデートの一つで`pull` コマンドに `--force` オプションが追加されました。
こちらを使って、GitHub Actionsのワークフロー上でQiitaの記事を自動更新するためのワークフローを作成してみました。

:::note warn
Qiita CLIはベータ版のため、今後のアップデートで仕様が変更される可能性があります。
:::

## ワークフローを作成する

- 特定時刻、または手動でワークフローを実行できる
- リポジトリのmasterブランチをpullして、Qiitaの記事を更新する
- 管理している記事ファイルに差分がある場合、Pull Requestを作成する

作成するワークフローは次のようになります。

```yaml:.github/workflows/sync-remote-and-create-pr.yml
name: Sync remote and create PR

on:
  schedule:
    - cron: '0 22 * * *' # 7:00 JST
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  sync_remote_and_create_pr:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v3
        with:
          ref: master
      - uses: actions/setup-node@v3
        with:
          node-version: '18.16.0'
      - run: npm install
      - run: npm exec qiita pull -- --force
        env:
          QIITA_TOKEN: ${{ secrets.QIITA_TOKEN }}
      - uses: peter-evans/create-pull-request@v5
        with:
          commit-message: 'Sync article files'
          delete-branch: true
          title: 'Sync article files'
          reviewers: fussy113
```

GitHub Actionsのワークフロー上で`qiita pull --force`を実行して、差分があった場合にはPull Requestを作成するようにしています。
Pull Requestの作成に関しては、下記記事を参考にしています。

https://qiita.com/mziyut/items/57486edcf8cbfa764dc1

これで記事を更新した後にワークフローが実行され、Pull Requestが作成されます。

![ワークフロー実行の様子](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/166596/a07976df-92c7-c565-3ef1-db397f9ec244.png)

![作成されたPR](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/166596/bea98f72-7ec2-07fe-32e3-d07ed4611196.png)

## 終わりに

Qiita CLIの`pull`コマンドに`--force`オプションが追加されたことで、GitHub Actionsのワークフロー上でQiitaの記事を自動更新するためのワークフローを作成しました。

Web上でQiita記事を更新した後、リポジトリの方でsyncしてあげる必要があるのですが、そちらを自動化することが出来るようになったので、より便利になった気がします:+1:
【Azure DP-900】Udemyの教材で8時間勉強して資格取得！おすすめポイントと勉強方法 🀄️

# 1.はじめに
どうも、ARIの名古屋支社に勤務している愛知県民こと、
新藏（にいくら）と申します♪
(/・ω・)/

先日、**AzureTechDay**というAzureのイベントに参加し、色々と講演を聞いてきました。

そして自分自身のAzure熱が高まり、
「Azureについてもっと知りたい・・・！」と感じたので、手始めにDP-900を取得しました。

私自身は業務でAzureを触る機会がないのですが、
試験勉強の時にとても良いUdemyの教材を見つけたため、
教材の紹介とおすすめポイントを説明したいと考えました。

・・・というわけで
**今回はDP-900を取得する時に使用したUdemyの教材について、**
記事にしたいと思います！

同じ資格を取得予定の方、Azure初心者の方の参考になれば幸いです。
(*^^)v

:::note info
ちなみにAZ-900は取得済で、その時の体験記は以下となります。

勉強のコツ・自宅orテストセンタ問題等について記載があるので、
こちらの方がためになる・・・かもです。

[【Azure】約25時間の勉強でAZ900を取得したので、勉強方法やコツを共有してみる](https://qiita.com/Aichi_Lover/items/63fe9f5cd4cedeb76c68 "AZ-900")
:::

# 2.Udemyの教材
いきなり結論となりますが、私が使用したUdemyの教材は**Cloud Mania-koさん**の
[【2023年最新版】試験に出るとこだけ重点対策！DP-900 Azure Data Fundamentals​対策講座​
](https://www.udemy.com/share/1097s83@o0CQio_k936wnoddDO4o9Do1ViAVwuwP1k5OeiulyPII6nexM5lId-a5PP7Fe2tJVA==/
 "Udemy")となります。

**セールで1600円**だったので、お財布にも優しいです♪

:::note alert
**2023/7/14現在、講座を購入することができない様子です。**
私の方でも定期的に確認し、購入が可能になり次第、本記事を更新してお知らせします。

もし通知を受け取りたい方は、「ストック」をお願いします。
m(__)m
:::

# 3.教材のおすすめポイント
では、教材のおすすめポイントについて記載していきたいと思います！

:::note info
説明に際して、画面キャプチャを貼りたい気持ちはあるのですが、
有料の教材のため文字だけの説明となります。
:::

## 3.1.DP-900の試験内容で聞かれる内容が分かる
本教材は基本的に動画での勉強、
具体的にはパワーポイントの様なスライドが表示され、
内容を説明する音声が流れる形式となります。

試験でよく出る内容がスライド内で赤字で記載されたり、
「XXXとYYYについてはDP-900で頻出の内容となります」という説明が流れたりするので、
**聞いていて何が試験で出やすいのか非常に分かりやすかったです！**

また、言葉も専門的になりすぎないように配慮されていると感じたので、
普段Azureを触らない人でも聞きやすいと感じました。

## 3.2.模擬試験(2回分)が含まれている
動画だけの教材だと、実際に学んだことをアウトプットするのは中々難しいと思います。

本教材には模擬試験が含まれているので、
**動画で学んだ内容を自分自身が理解できているのか、確認することができます！**

また、解説も付いている点も親切と感じました。

## 3.3.字幕が付いている
こちら、地味にありがたかった点となります。

私の場合、子どもを寝かせるときにスマホで学習をしていたのですが、
**字幕があるおかげで音声を流さなくても内容を理解することができました！**

電車やバスの中で勉強する時も、字幕は助かると思います。

## 3.4.最初と最後に作者の想いを話しているセクションがある
こちらは個人的に良いと感じた点となります。

本教材を作成したCloud Mania-koさん自身の紹介、
なぜ本教材を作成したのか、受験生に向けてのエール等
を話すセクションがあるため、**より勉強を頑張ろうという気持ちになりました！**

# 4.具体的な勉強方法
本章では、私が勉強した具体的な方法について記載します。

私の場合は試験勉強の期間は約1週間で、
平日に1時間、休日に1.5時間の勉強をしていました。

まずは教材の動画を全て確認し、模擬試験を解きました。

**模擬試験を解いた後は正解したが自身がない問題・不正解だった問題について、
正解するためにはどのような知識が必要だったのかを教材で再確認しました。**

その後2回目の模擬試験を解き、両方の試験が正答率が90%以上だったので、本番の試験を受けました。

結果は・・・916点で合格でした！

|![DP900のスコア.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1372071/afd5130f-bf3e-8b13-9f68-b44adf867ed9.png)|
|:--|

最後に、勉強で使用した時間は以下となります。

|項目|時間(h)|
|---|---|
|動画を確認する | 3 |
|模擬試験を解く | 1.5 |
|模擬試験で間違えた問題を復習する | 2 |
|再度模擬試験を解く | 1.5 |
|合計 | 8 |

:::note info
記載していて感じたのですが、オーソドックスな勉強方法ですね・・・
:::

# 5.おわりに
ここまで読んで下さり、ありがとうございます！！！
(^^)

自分自身、業務でAzureを触ったことがないのですが、
良い教材に出会って無事に合格することができました♪

次は・・・AI900ですかね？

また次回も何かしら記事にします！
(:3_ヽ)_
議事録の書き方とその役割

## 背景

#### ミーティングの内容を共有したいけどうまくまとめることができない

全員が出席できるミーティングはスケジュール上難しいが、内容は共有したい

#### そもそも議事録の目的を把握していない

議事録という言葉はよく聞くけど、**何のために**書いているのかわからない
**誰がどんな時に**見るものなのかわからない
だから、**情報の取捨選択**すらできない
　　

### 解決策としてUdemyで**議事録（議事要約録）の書き方マスターコース**を学んだ


***

# 議事録の役割

:::note
**意思決定事項の再確認ができる
ToDoがわかる
議論の経緯と決定事項がわかる
議論や決定事項を後で確認できるようにする**
:::


# 決定事項と未決定事項をまとめる

### 【決定事項のまとめ方】


- なにを
- なにで
- 誰が・誰に
- どのように
- いつから・いつまでに
- どこで

**最低限抑える項目：なにを、だれが、いつまでに**

### 【未決定事項のまとめ方】

**未決定の原因を明らかにしたうえで決定事項同様まとめる**
例）時間不足、参加者不足など


:::note
**決定事項とは
→議事録を読んだ人が、内容を理解して、次の行動に移れるまでを記す**
:::


# 論点と経緯が把握できるようにする

理由：不参加者の立場からすると、どんな経緯でそうなったのか気になる



## ＜議事録作成の手順＞





### ①会議の前に準備すること

- **会議の基本情報を得ておく**

**会議の基本情報とは**
・会議名（具体的に）
・参加者、欠席者
・主な議題
・時間、場所
・使用した資料
・作成者、作成日

- **略語をあらかじめ決める**
例）マネージャー：MGR
    OOプロジェクト：OOPJ

　　
- **議題を知っておく**（聞き逃しを防ぐ効果もある）
→想像ベースでもいいので流れと落としどころを把握しておく

### ②会議中のメモの取り方

マークしておく内容
- **決定事項**
- **今後のアクションにつながること**
- **未決定の内容**（？とかをつけておく）

### ③会議後にまとめること

- **決定事項**
　　→**方針レベル～アクションに落ちたもの**までを含めてまとめる
- **未決定事項**
　　→**次回持越し、議題から外すなどの結果**を含めて残す
- **今後のアクション**


:::note
**最終的に以下3点がまとまっているとベスト
・決定事項
・論点
・経緯**
:::

## 論点経緯をまとめるメモをする上でのポイント

### ①会議前
- **議題の記載**
- **それぞれの議題に数字を振っておく**
　→これ何の話？がなくなる
　　発言メモの横に対応する議題の数字を振っておく
### ②会議中
- **小見出しとして以下の発言に注目する**
依頼
問題事項
結論
質問

- **話の切り替えでラインを引く**

### ③会議後

#### 情報の取捨選択

- **記載の必要が低い発言**

例
・一方的な資料の説明
・雑談
・結論につながらない感想やコメント

#### 同じ内容の言いかえ

- **発言の順序ではなく、発言間の関係性で並び替える**

例
・因果関係（具体→抽象など）
・前後関係

#### 文章の精査

- **誤字脱字チェック**

- **話し言葉→書き言葉に変更**
例
次回もう一度話し合いましょう　→　継続検討

- **短文化**
- **指示代名詞を使っていないか**



# 議事録レビューのポイント

- **作成者の意図が伝わるようにする**

成果物の前提を伝える（完成 or 途中段階）
要確認事項を記載
締め切りを伝える
ずっとプロマネ畑だったけれど🔰AWS初心者として歩き出して楽しい話し

ジャーニーマン( @beajourneyman )です。

オーガナイゼーション参加記事としてキャリアについて書くのはなかなか難しいです。書き始めから筆が止まっています。ただ、伝えたいコトがあるので、書いてみます。

# 結論というかこの記事で言いたいコト

**技術に少しでも興味があれば、経験は関係なく学び始めれば良い。エキスパートなキャリアがあって「今更初心者に戻れない症候群」の影響で幅が狭まるのは勿体無い。自分の興味関心に素直に従ってチャレンジしよう。**

たまたま、Book&Appsの安達さんが、本稿と地続きなツイートをされていたので紹介します。そう、新しいコトを学び多様な経験をするのは、単純に楽しいのです。

https://twitter.com/Books_Apps/status/1681591455851384832

# 結論に至った背景（昔語りです）

## ベースのキャリア

未経験でIT業界に入り、新人研修を通してCOBOLプログラマー兼システムエンジニア(SE)になりました。ただ、プログラミングには楽しさは見出せず苦労していました。そんな中、当時の上司が案件の現場リーダーに指名してくれて、プロジェクトリーダー(PL)、プロジェクトマネージャ(PM)の道を歩みました。ベースはPM兼SEのキャリアです。

PM兼SEとして仕事をしてはいましたが、技術的なコトには興味関心が向かず、それまでの延長線上で学びは停滞していました。途中、サービスの拡販がミッションとなった時に、門外漢だった新規顧客開拓やビジネスグロース、リサーチ、マーケティング、プライシング、セールスなど、プロジェクトデリバリーの世界からは考えもしなかったビジネス側の世界を知りました。パブリッククラウドの存在を知ったのはその時です。ただ、技術者としての興味関心が枯れていた、また、広大なビジネス側の世界に強い興味が湧いていた状態だったので、クラウドの世界に飛び込むコトにはなりませんでした。

## マーケターへロールチェンジ

その後、いくつかの偶然が重なり、マーケティングとPRを数年担当しました。大きな軸はコンテンツマーケティングで、オウンドメディアの編集長兼メインライター、公式SNSの運用をしていました。詳細は以下のQiitaに書いたので譲ります。その時の学びはとても良い体験でした。学びの対象のひとつにAWSのコミュニティマーケティングがありました。

https://qiita.com/beajourneyman/items/cba703c5cea4f1c088a0

https://qiita.com/beajourneyman/items/729861c837038a250f7d

その時点ではエンジニアリングではなく、マーケティング軸でAWSと出会っており、自分自身がクラウドをエンジニア軸で学ぶコトになるとは想像していませんでした。

## さらなる転機

事情によりSEに戻りました。運用サービスを主体としたチームで日々の業務をしながら、アラート架電をロボットコールにする改善や自社ツールをBacklogに移行するプロジェクトなどの案件をいくつか担当しました。その後、大きな転機が訪れます。AWS基盤で稼働するシステムの維持保守・追加開発をするシステム開発部門へ異動になったのです。異動が決まって、CLFを目指すコトにしました。

https://note.com/beajourneyman/n/nb4ff9ff2cf19

受験を志した先には、マーケティング軸で出会った時には見えていなかった深淵なAWSの世界が広がっていました。ずっと技術から遠ざかっていた自分でしたが、その学びは新しい世界を知る楽しさを思い出させてくれました。

## システム担当になって

移動後、しばらくして担当システムのPM兼SEとしてメイン担当になりました。PMでありクラウドアーキテクトでもあれば、きっともっと仕組みを良くできる、そんな未来を感じました。まだ1年経っていませんが、多数の改善施策をリリースし、担当システムが良くなっている実感を持てています。受験記録は書き切らずにお蔵入りしてしまっていますが、何んとかSAAも取得しました(非常に難しかったです！)。2度の資格受験を通して、クラウドがインフラ・アプリの垣根を溶かしているように、PMでも実務経験が前提となるアソシエイト以下のAWS認定は全部取っても良いと感じています。(私見ですがCLFはIPAのITパスポートもしくは初級システムアドミニストレーター、アソシエイト系は基本情報処理技術者に近いと思っています。)

そして、今更なる技術的成長に向けて、社内の仲間と共に学んでいます。やや浮いている懸念はありつつも楽しんでいます。そのグループへ飛び込むきっかけになった出来事は [AWS GameDay](https://aws.amazon.com/jp/gameday/) 参加でした。結果、自分のできなさ加減を痛感しました。クラウド初心者としてゼロから技術を学び直す意識で歩き出しています。

https://qiita.com/beajourneyman/items/3034a0059c6e23d3d069

結論を再掲します。

**技術に少しでも興味があれば、経験は関係なく学び始めれば良い。エキスパートなキャリアがあって「今更初心者に戻れない症候群」の影響で幅が狭まるのは勿体無い。自分の興味関心に素直に従ってチャレンジしよう。**

## 追記
本ブログが骨子として [JAWS-UG 初心者支部 #59](https://jawsug-bgnr.connpass.com/event/310308/) で登壇したのでスライドをご紹介します。

https://www.docswell.com/s/8916250/ZP9DE2-2024-03-27-172413

以上です。
中間テーブルに気を付けよう

# 客先からこんな依頼が・・・
表Aと表Bの情報を任意の条件に合う形でcsvで取り出して出力したい。

通常なら、共通のキー（id）で結合して、情報を取り出せば良いのですが、
少しテーブルの形が特殊でした。
結合したものを取り出すところで少々詰まったので備忘録がてら書いています。
下に要点を絞って示します。
キー名、値は実際とは変えています。横に日本意をつけています。

テーブルA(部品情報)
| id_A(管理id) |part_no(部品番号) |Yearfrom(生産年) |...|
|:-----------:|:------------:|:------------:|:------------:|
| 6000      | sample1212       | 2023    |...|
| 6005     | sample5342      | 2021       |...|
| 6012   | sample3231   | 2022  |...|
| ：| ：   | ： |：|

テーブルB(製品製造情報)
| id_B(製品id) |company_no(製品番号) |PartsA(駆動部品A) |...|
|:-----------:|:------------:|:------------:|:------------:|
| 1      | AA56BB      | sample1212    |...|
| 255     | MMKK44      | sample3231       |...|
| 399   | LL9KKV   | sample5342  |...|
| ：| ：   | ： |：|

テーブルの説明をするとテーブルAは部品情報を表したもので部品に対しての生産年、型番などの情報が15カラムに渡り格納されていて、テーブルBはテーブルAの部品を使用して作成される製品についての情報が20カラムに渡り格納されています。

厄介なことにこのテーブルAとB、IDで紐ついているのではなくpart_no(部品番号)とPartsA(駆動部品A)で紐ついており、さらにpartsA以降の20カラムの別の駆動部品の情報とも紐づいていました。

# 試行錯誤の末に・・・

SQLでカラムを20個結合したりするのは現実的ではないため、UNIONを使ってなるべく計算負荷を減らそうとしましたが、上手くいかず駆動部品の20カラムを共通化したCommon_partsというカラムを加えた中間テーブルCを最終的に作成することにしました。(ちょっとカラムを省きます）

テーブルC(中間テーブル)
| id_A(管理id) |id_B(製品id) |part_no(部品番号)| company_no(製品番号) |Common_parts(駆動部品集) |...|
|:-----------:|:------------:|:------------:|:------------:|:------------:|:------------:|
| 6000      |    1    | sample1212    |AA56BB |sample1212|...|
| 6005     |  399     | sample5342     |LL9KKV|sample5342|...|
| 6012   | 255   | sample3231  |MMKK44|sample3231|...|
| ：| ：   | ： |：|：|：|：|

## 後は取り出すだけ
このテーブルCから、目的のカラムを取り出してCSVに出力するだけ。
私は安心していました。
中間テーブルはテーブルA,テーブルBから作成しているため、ざっくりですが、A.part_no,B.company_noとすればカラム情報を取り出せると思っていました。
しかし、実際は取り出すことができず、SQLが悪かったのか色々検討したため、半日ほど色々探す羽目に。
報告期限が迫っているため、焦る焦る。

## 何が原因だったか
中間テーブルCを作成していたため、そのテーブルからカラム情報を取り出すためにはC.part_no,C.company_noとする必要があった。
意外と盲点だった。


## 学んだこと

- 中間テーブルを作成し、そこから情報を取り出す際は元のテーブルではなく中間テーブルのカラムを指定すること
- 詰まった時はまずは簡単なことから見直してみること

# 後書き
エンジニアになってからおおよそ一年になるがアウトプットしようしようと思いながらおざなりになってしまっていた。
駄文かもしれないがアウトプットする機会を増やしていきたい
基本情報技術者試験合格までのメモ

# 著者スペック紹介
IT系専門学校卒
C++でのプログラミング経験はありますが、専門学校での授業を全く聞いてなかったのでIT系の知識はあまりありませんでした。

# 点数
科目A:925点
科目B:725点

# 勉強期間
大体三ヵ月くらい

# 勉強方法
## 科目A
基本情報技術者過去問道場で平成25年春期～令和元年秋季までの過去問を解きまくりました。
1日30問×30日×3ヶ月=計2700問くらい解きました。
最終的な正答率は80%くらいでした。

## 科目B
IPAが公開しているサンプル問題を解いてみたらいけそうだったので、特に対策等はしませんでした。(点数が思ったより低めなのはちょっとショックです。。。)
新制度に移行(2023年)してからプログラミングの問題は**独自言語**での出題となっているので、IPAのサンプル問題には目を通しておいた方がいいと思います。セキュリティの問題に関しては、問題文をしっかり読めば解けると思いましたまる。
【Linux】内容に特定の文字列を含まないファイルのパスを取得する方法

## `grep`コマンドで取得

`grep`コマンドを使用して内容に特定の文字列を含まないファイルのパスを取得するには以下のように実行します。  

```zsh
grep -Lr '検索する文字列' 対象のパス
```

* `-L`
検索する文字列が含まれていないファイルのパスのみ表示する。
* `-r`
ディレクトリを指定した場合にサブディレクトリ内のファイルも含めて検索する。

以下のようにファイルを作成し実際に実行してみます。

```zsh
$ tree
.
└── sample
    ├── example.txt
    └── test.txt

$ cat ./sample/example.txt
ABCDE

$ cat ./sample/test.txt
12345

```

```zsh
$ grep -Lr '1' ./sample
./sample/example.txt
```

`1`が含まれていない`example.txt`のパスが出力されました。
アジャイル開発の課題に立ち向かうために必要なこと

# アジャイル開発の課題

[Software Design 2023年8月号](https://gihyo.jp/magazine/SD/archive/2023/202308)が、アジャイル開発の課題とプラクティスについての特集でした。

> アジャイル開発の課題に立ち向かう
> 「なんとなくアジャイル」から脱却するためのプラクティス

これまでも「[More Effective Agile 〜 “ソフトウェアリーダー”になるための28の道標](https://amzn.asia/d/8dJBPwJ)」のように、実践に基づく経験からより効果的にアジャイル開発を行うための方法が記載された書籍はあったし、アジャイルのコミュニティを通じて、事例やプラクティスの共有はされているものの、網羅的にコンパクトにまとまっていて、私自身の経験と照らし合わせてみても頷くところ多き内容でした。

ただ、紹介されていたプラクティスも頷きまくりだし、アジャイル開発未体験な方、課題にどう向き合ったらいいか悩んでる方はみんな読むべきだよと思うものの、立ち向かうべきは課題であり、用いるプラクティスもチームによっても、チームの状況によっても段階があり、そのまま実践しようと思っても難しいことのほうが多いんじゃないかと思い、こんなツイートをしました。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">課題に立ち向かうことが重要で、プラクティスを適用することが目的になってはいけないよねと思う今日この頃である。 <a href="https://t.co/bbFuZ14bhG">pic.twitter.com/bbFuZ14bhG</a></p>&mdash; かず (@curanosuke) <a href="https://twitter.com/curanosuke/status/1681315775284666369?ref_src=twsrc%5Etfw">July 18, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

# 課題への立ち向かい方

アジャイル開発の手法の一つである「スクラム」での実践においても、POや開発者など、チームのメンバーのほとんどがソフトウェア開発やスクラムの知識と経験が豊富、最初からそんなメンバーが集まることは稀で、少なくともスクラムマスター1人と、経験のある開発者が1、2人から始まるチームがあったとします（それよりも少ないケースは、更に課題が多くなると思います）。

スクラムのプロセスに従い、スクラムイベントを開催していくことで、ある程度は、スクラムの三本柱である「透明性」と「検査」と「適応」が実施できていきます。ここで重要なのはチームをよく観察することで、見えなかったものを見えるようにしていく、見えるべきものを問いを立てて確認していくことで、少しずつ表出化される「透明性」です。

「透明性」がどれだけ確保できるかが、チームが「検査」と「適応」によって、改善のサイクルが効果的に進み、自己組織化が進むチームになれる一番の鍵じゃないかと思います。

というようなことを書いていて、そういえば、同じように「見えないものを見えるように気づかせてあげることが大事」ということを何処かで書いたことを思い出しました。

[『アオアシに学ぶ「考える葦」の育ち方』とアジャイル開発](https://note.com/curanosuke/n/n502683671a09)　という記事を去年のアドカレでも書いていたのでした。

課題への立ち向かい方としても、サッカーとアジャイル開発は共通点が多いと思っています。
技や戦術などのプラクティスの練習を重視しがちな日本のサッカーではなく、試合の中で学ぶことの方が大切だということが、「[競争闘争理論 サッカーは「競う」べきか「闘う」べきか?](https://amzn.asia/d/g8TsZTq)」にも書かれていました。

この記事を書き始めた時は、先ほどのツイートに続けて書いたランニングのプラクティスと絡めて書こうかなと思っていたのに、結局サッカーに戻ってきたので、スクラムもチームである以上、陸上のような競争の競技ではなく、闘争の競技であり、実戦の中で学ぶべきことの方が多いということなのだろう。でも、やっぱりプラクティスも知らないと見えてこないところも多いから、アジャイルだけじゃなく、アーキテクチャー、クラウドやCI/CDも含めたプラクティスも学ぶのも大事だよね。おわり。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">信頼できるトレーナーから教わったプラクティスをいろいろ試してみたところ、自分に足りなかったプラクティスが見つかったり、悩まされてきた症状が解決してきたりした。<br><br>これはランニングのトレーニングの話。<br><br>プラクティスを学んで、自ら試してみることも大切である。</p>&mdash; かず (@curanosuke) <a href="https://twitter.com/curanosuke/status/1681322221825056768?ref_src=twsrc%5Etfw">July 18, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
【AWS Lamba】コンテナイメージから Lambda関数を作成する



## ローカル環境の準備
- Golangインストール
https://go.dev/dl/

- Dockerfile作成
```dockerfile:Dockerfile
FROM golang:1.17-buster as builder
WORKDIR /go/src/lambda
COPY go.mod go.sum ./
RUN go mod download
COPY ./ .
RUN go build -a -o /main .

FROM debian:buster as runner
WORKDIR /app/
COPY --from=builder /main /main
ENTRYPOINT [ "/main" ]
```

- main.go作成
```golang:main.go
package main

import (
       "fmt"
       "context"
       "github.com/aws/aws-lambda-go/lambda"
)

type MyEvent struct {
       Name string `json:"name"`
}

func HandleRequest(ctx context.Context, name MyEvent) (string, error) {
       return fmt.Sprintf("Hello %s!", name.Name ), nil
}

func main() {
       lambda.Start(HandleRequest)
}
```

- モジュール初期化
`$ go mod init example.com/hello`

- モジュールの依存関係を最適化
`$ go mod tidy`

## コンテナ作成 / ECRプッシュ
ECRリポジトリからプッシュコマンドを表示させて、ECRにイメージをプッシュする
※詳細な手順は下記を参照
[【Amazon ECR】AWS CLI を使ってリポジトリへプッシュする](https://qiita.com/sakuchi/items/90886663f7adf3941472)

## Lamda権限をもつロール作成
※実際にLamda関数を作成する画面で使用します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/e19ac05f-4328-5fc2-1f74-05ccb2858dc6.png)

AWSLamda_FullAccess ポリシーを追加
 "Lamda_Full" でフィルタリング
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/6362951b-6ba0-8674-8709-78f66d51d9b5.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/81d1fed2-4bab-0287-11d5-b03aea49e8a7.png)


## Lambda関数の作成
コンテナイメージから作成する方法を選択
※事前にECRにイメージをプッシュしておく
前述で作成したロールを指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/cd906a78-5e76-1e60-0821-c45091a37ddb.png)

テスト実行
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/05246da1-b796-4eeb-ddd4-1726eac4f2dd.png)

<font color='darkorange'>**ポイント**</font>
Lambda関数は ECR のイメージを実行するのではなく、イメージをもとに作成されたコンテナで実行される。そのため ECR のイメージを削除しても、既に作成された Lambda関数は影響を受けない。

参考サイト
https://note.com/dd_techblog/n/n3187a9036354#ejGk9
Nullをなくし、エラーから解放されよう

Nullを返すか、あるいはNullを受け取ることがどれほど危険であるかはよく知られています。Nullに関するエラー、Javaにおける最も一般的なエラーの一つであり、コードを混乱させ、バグを引き起こし、デバッグに時間を奪います。だからこそ、Nullの問題を解決し、Null安全なコードを書くべきです。

## 1. Null安全の重要性

Null安全はプログラムの信頼性と保守性を向上させます。Nullを許容すると、エラーがコードのどこかで発生しやすくなり、それを特定するのが難しくなります。Null安全を実現することで、これらのエラーが発生する可能性を大幅に減らすことができます。

## 2. Nullを返す、渡す処理の避け方

Nullを返すメソッドやNullを渡す呼び出しを使用すると、それを呼び出すコードは常にNullチェックを行わなければならず、コードが複雑になります。その代わりにJava 8から導入された`Optional`クラスを利用することで、Nullを明示的に扱うことができます。 

`Optional`クラスは、存在しない可能性のある値をモデル化するためのコンテナです。それは値が存在するかどうかを明示的に示すことで、Null Pointer Exceptionの発生を防ぎます。

```java
Optional<String> getOptionalData() {
    // 値が存在しない場合はOptional.empty()を返す
    return Optional.empty();
}
```

`Optional`を使用すると、値が存在するかどうかを明示的にチェックでき、その結果、Nullチェックの必要性を減らすことができます。

## 3. Nullオブジェクトパターンの活用

Nullオブジェクトパターンは、Nullを返す代わりに、実際のオブジェクトが提供するのと同じインターフェースを提供する特殊なオブジェクトを返すデザインパターンです。このパターンは、Nullチェックの必要性を排除し、例外を回避するのに役立ちます。

```java
public interface Animal {
    void makeSound();
}

public class Dog implements Animal {
    public void makeSound() { System.out.println("Bark!"); }
}

// Nullオブジェクトパターン
public class NullAnimal implements Animal {
    public void makeSound() { /* 何もしない */ }
}
```

このパターンを使用すると、NullReferenceExceptionを心配することなくメソッドを呼び出すことができます。

## 4. アノテーションの活用

JavaのNull安全アノテーションは、Nullの扱いについて明確にするのに役立ちます。`@Nullable`と`@NonNull`の2つのアノテーションがあります。 

`@Nullable`は、変数がNullになる可能性があることを示します。一方、`@NonNull`は、変数が絶対にNullにならないことを示します。これらのアノテーションを使用すると、コンパイラとツールは、Nullが予期せずに使われるのを防ぐためのヒントを提供することができます。

```java
public void display(@Nullable String name) {
    if (name != null) {
        System.out.println(name);
    }
}

public void print(@NonNull String message) {
    System.out.println(message);
}
```

これらのテクニックを適切に組み合わせて使用することで、Null安全なJavaのコードを書くことが可能になります。Nullは不必要なエラーと複雑さをもたらすため、適切な代替手段を利用することでこれらの問題を克服しましょう。

以上、Nullの安全性についてのお話でした。
pytestで関数のモックと標準出力のテストをする

pytestはPythonでテストを書くのに人気なツールです。
今回はpytestで関数をモックする方法と標準出力をテストする方法をメモがてら記載していきます。

# 関数のモック
pytestでは`mocker`を使うことで関数をモックできます。

まずは`main.py`として`get_id()`関数を以下のように定義します。
```python:main.py
from uuid import uuid4


def get_id():
    id = uuid4()
    return f"Your ID: {id}"
```
このとき`uuid4()`は毎回ランダムな文字列を返します。
実行するたびに`id`部分が変わってしまうので、このままではテストをすることができません。

そこで以下のように`uuid4()`をモックすることができます。
`main.py`をテストする`test_main.py`を以下のように用意します。

```python:test_main.py
from main import get_id


def test_get_id(mocker): # 引数にmockerと指定
    id = "fef317a6-69fc-772d-51f6-8537aa728335"
    mocker.patch("main.uuid4", return_value=id) # 第一引数にモックする関数を指定
    value = get_id()
    assert value == f"Your ID: {id}"
```
ポイントはテスト関数の引数に`mocker`と指定するところです。
これによってpytestの`mocker`を使うことができます。

次に`mocker.patch`で関数をモックします。
第一引数にはモックする関数を、`return_value`にはモックとして返す値を指定します。

こうすることで、`main.py`内の`uuid4()`という関数は、テストの上ではモックされ、必ず`"fef317a6-69fc-772d-51f6-8537aa728335"`を`id`として返すようになります。

# 標準出力をテストする
ログがちゃんと出ているかをテストするには、標準出力を見る必要があると思います。
標準出力をテストで受け取るには`capsys`を使うことができます。

例として以下のような`main.py`があるとします。
```python:main.py
def print_log(user: str, message: str):
    print(f"{user=}")
    print(f"{message=}")
```
これをテストする`test_main.py`は以下のように書けます。
```python:test_main.py
from main import print_log


def test_print_log(capsys): # 引数にcapsysと指定
    print_log(user="test", message="Hi")
    captured = capsys.readouterr() # 標準出力と標準エラー出力を受け取る
    assert captured.out == "user='test'\nmessage='Hi'\n"
```
`mocker`と同じように、テスト関数`test_print_log`の引数に`capsys`を指定します。
`captured = capsys.readouterr()`とすることで、標準出力と標準エラー出力を受け取ることができます。
標準出力は`captured.out`に入っています。

# おわりに
pytestで関数をモックする方法と標準出力をテストする方法をまとめました。
特に関数のモックは複雑な関数をテストするのに必須となってくると思うので、様々に使えるようにしていきたいです。
Lama2のアプリ（申請不要）

Lama2はMicrosoftはMetaとの新た商用および研究目的の規模言語モデルです。
利用してみたいは申請が必要です。


モデルのダウンロード：
https://ai.meta.com/resources/models-and-libraries/llama-downloads/

申請したくない場合は下記のhuggingface spaceで試してください。

### Llama-2 7B Chat
https://huggingface.co/spaces/huggingface-projects/llama-2-7b-chat

### Llama-2 13B Chat
https://huggingface.co/spaces/huggingface-projects/llama-2-13b-chat

### Llama2 70B Chatbot
https://huggingface.co/spaces/ysharma/Explore_llamav2_with_TGI

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225269/2978cb4b-8313-2f11-7b23-8391cc237f9e.png)

Llama 2の詳細は下記の記事をご覧ください。
https://qiita.com/jingwora/items/49eec682a6e93ea08cc0
私の経験から考えるUiPathの実装ポイント～追加2点編～

## はじめに

この記事は、RPA歴約5年の自分が、UiPathを中心に数々の案件を経験してきて得た知識やポイントについて自分なりにまとめてみましたの第2弾です。
ほかの言語の実装でも活用できる...かは自分次第ですね。

①本記事は、2023年7月開催の「UiPathブログ 発信チャレンジサマー」の19日目のブログです。
ブログの詳細、参加方法については、以下のブログを参照ください。
https://note.com/shumpei_w/n/nd082bdf28853

②このブログ情報は、2023/7時点の情報です。
③この実装ポイントはあくまでも「筆者の経験」に基づくものです。
実装のルール(規定、開発標準)が決まっている場合は、そのルールに基づいて開発しましょう。

## 久しぶりに...
ここ最近モダンアクティビティ(Excel)の話ばかり書いていたので、本日はちょっと休憩がてら小話というか、実装時のポイントについて(自分が思っていることになりますが)書いていきたいと思います。
ちょっと前投稿の記事はこちら↓

https://qiita.com/saosao885/items/9940c547e2031540a6d4

今回は、上記の記事で書ききれなかったポイントを2点、追加で書いていきたいと思います。

## ポイント1 【エラー処理】エラーになったらどうするかはあらかじめ考えておく
これは当たり前なことなのですが、RPA初心者や開発経歴が浅い方はこのことまで考慮して実装することが結構難しいのではと思っています。
エラーといえば、Try Catchアクティビティを使うこともそうなのですが<b>「エラーが発生したとき、最終的にどうしたい？どうなってほしい？」</b>を考えながら実装することが大事です。
そのために、以下は心がけておくとよいでしょう。
・設計時に、エラーに遭遇した際はどうするのか考えておく(Aの処理はException？Bの処理はBusinessRuleExceptionで止めてしまう？)
・エラー処理(throw、rethrow)を使うのはどのパターンのエラーなのかを設計時までに考える
・繰り返し処理の最中にエラーが出た場合は、エラー情報をどう反映させる(処理結果ファイルに記載等)のか、その場でbreakで抜けてほしいのか等を考える
・シーケンス等に「このエラーは何か」「このエラーはこういう意味です」という感じで注釈をつけておく
・ログは出しておこう(レベルはErrorとかwarnが多いですね)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/a3aa77e3-b198-6c84-0885-2be9e15e3db4.png)

## ポイント2 【全般】表示名は既存でなくオリジナルの名前を書く、注釈は極力記載する
アクティビティを使う際や、ふとした瞬間に見るとアクティビティが配置されている。
ただ名前が「代入」とか「Excelアプリケーションスコープ...」とあるだけ。これ何のやつ？変数名から探る？
また注釈やアクティビティの名前に具体的な記載がないために<b>「なんの処理をしているのかわからない...」</b>ということはあったでしょうか。

特に自分が実装していない(要は他人が作成した)ロボットだと、設計書をいちいち見る必要もありますし(見るのはもちろん大切なことです)、下手をすると暗号解読？のような事態にもなりかねません。
可読性を高めるためには以下を心掛けるとよいと思います。

・アクティビティの名前をデフォルトでなく、わかりやすい名前にしておく
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/1fbf2bb6-b1db-595f-cacd-73725c30b0d6.png)

・特に「何をしているのか」わかりにくい場合は注釈(アノテーションとも言います)を入れておく
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/744485d9-8d72-db79-8ba6-62e83504d655.png)

・コメントアクティビティを活用する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502614/921ebc40-ff32-e48c-b30e-83924d44ddf4.png)

## まとめ
ちょっと記事としては簡潔に記載しすぎた気はしますが、ここに書いたことは結構大事なことではないかと思っています。
仕事柄、他の方が書いたものをレビューすることが増えてきたので、備忘録的に都度気付いたことなども書いていきたいと思います。
最後までお読みいただきありがとうございました。
リモートのスクラムチームでは共同作業時間を設けましょう

# 背景
初めてちゃんとスクラム開発を行った際に、共同作業時間を設けることが非常に重要だと感じたので普及のための記事を書きます。

## 最初に、スクラム開発で大事だと思ったこと
これは間違いなく __チームビルディング__ だったと言えます。ここで言うチームビルディングとは以下を実施することです。重要だと思う順に並べました。
1. 互いを知って話しやすい関係を作ることで、コミュニケーションコストを下げる。
2. コンテクストを高めることで、コミュニケーションコストを下げる。
3. スクラム開発に関する知識・認識を合わせることで、各イベントの品質を高める
4. プロジェクト（プロダクト）の目的・目標を共有することで、無駄なことをしない
5. （なるべく）開発メンバーのスキルを平準化して、個人がボトルネックにならないようにする。
3~5はスキルに関する内容ですが、それらを向上させるにはまずはチームとしてお互いを高められる関係性を築くことが大事だと感じました。

## 大事だと思ったことを実現するために有効だったこと
それが __チーム全体で集まって作業・会話をする場（共同作業時間）を設ける__ ことでした。
「もくもく会」「モブプロ」など呼び方はいろいろありますが大事なのは __１つの空間に集まって作業・ディスカッションをする__ ことです。
* 会話をすることで「この人にはどこまで説明すれば通じるかがわかる→コンテクストを高めることができる→コミュニケーションコストが下がる」
* 特に昨今はリモートワークが増えて、テキストコミュニケーションが主となっているため、ローコンテクストになりがちだと感じています。
* 隣の席に座っていたときには自然発生していた会話もリモートワークによって発生しづらくなっているので、それを促す施策は有効でした。

具体的には以下を実施しました。
* 毎日1時間の枠でWeb会議をつなげた状態で作業をする時間を設ける
* この時間帯で何をするかはその日のデイリースクラムで決定する
    * 例、レビュー、仕様検討、技術相談、モブプロなど
    * トピックスが無い場合や、直接関係しないメンバーは各々の作業をしつつ気になったことがあれば会話に加わる

会話、共同作業をすることで課題解決を加速することができましたし、直接会話・作業に参加しないメンバーも、各々作業していては知りえない情報や知見を得ることができるので非常に好評でした。

また、筆者はフルリモートワークだったので、孤独感の解消にも役立ちました。これもチームビルディングとしては重要な要素だったと思っています。

## まとめ
[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)に「プロセスやツールよりも個人と対話を」という一文がありますが、リモートワークの普及によりここが疎かになりがちなのではないかと考えています。
共同作業時間を設けることは、良いスクラムチーム・アジャイル文化の構築に寄与してくれると思います。
ESP32エラー

エラー

A fatal error occurred: Unable to verify flash chip connection (Invalid head of packet (0x01): Possible serial noise or corruption.).
Failed uploading: uploading error: exit status 2


解決方法

コンパイルは成功するのに書き込みが失敗する
about Nefry BT

エラー内容
2018年1月現在、ESP32のバグにより、Nefry BTのコンパイルは成功するのに、書き込み時にエラーが出てしまう場合があります。（本来正しく書き込めるプログラムが書き込めない状態）

解決策
何度か書き込みを再チャレンジすると書き込めます。または、Arduino IDEのUpload Speedを遅くするとうまくいきます（921600になっていたものを460800にするなど）。
Manage Cache proxy for Kong Gateway

Kong Gatewayの[Proxy Cache plugin](https://docs.konghq.com/hub/kong-inc/proxy-cache/)を使って、有効なキャッシュを保存したら、レスポンスが大幅に短縮できる見込みです。

一回目のアクセスでキャッシュがまだない(Miss)

```
❯ http :8000/demo1
HTTP/1.1 200 OK
...
X-Cache-Key: fcc4fd13443bebf109fdad1c8463e9079e7c83783fbf001e5f75f9013977ec41
X-Cache-Status: Miss
X-Kong-Proxy-Latency: 238
X-Kong-Upstream-Latency: 523
```

二回目のアクセスに有効なキャッシュがある(Hit)から、APIにアクセスする必要がなく、レイテンシが0に

```
❯ http :8000/demo1
HTTP/1.1 200 OK
...
X-Cache-Key: fcc4fd13443bebf109fdad1c8463e9079e7c83783fbf001e5f75f9013977ec41
X-Cache-Status: Hit
X-Kong-Proxy-Latency: 1
X-Kong-Upstream-Latency: 0
```

キャッシュはTTL時間を過ぎたらクリアされますが、手動でクリアすることも可能

```
http DELETE <admin API>/default/proxy-cache/<Plugin ID>/caches/<Cache Key>
```

全キャッシュをクリアするも可能
```
http DELETE <admin API>/cache
```
[TypeScript]TypeAliasとinterfaceType - interface

```typescript:interface基本定義
export type YesOrNo = 'Y' | 'N';
export type Name = string;
export type FooFunction = () => string; 

// 定義　開始
export interface IUser {
  readonly id: number;
  readonly name: Name;
  email: string;
  receiveInfo: boolean;
  active: YesOrNo;
}

export interface IUser {
  address?: string;
}
// 定義　終了

// 使用　開始
import * as allTypes from './type';

const iUser: allTypes.IUser = {
  id: 1;
  readonly name: 'jung';
  email: 'jung@gmail.com';
  receiveInfo: false;
  active: 'Y';
}

const foo:allTypes.FooFunction = function() {
  return 'fooFunction'
}
// 使用　終了
```
IUserの中ではオブジェクトタイプを定義しています。
タイプには最初に定義したtype aliasを使うことも可能です。
?はoptionalという意味です。（optaional：address属性があってもいい、なくてもいいという意味）
IUser interfaceが同じ名前で二つ定義されています。
interfaceは重複定義が可能です。
こうなったら既存のIUSerにaddress?:stringが追加された効果を出します。

「使用　開始」を見ると、
*（すべて）をallTypesというaliasにて包んでくれています。
こうすると、./type　に定義しているタイプを個別importする必要がなくなります。
iUserのタイプはIUserのため、
「定義　開始」中のIUserの規格と同じでなければならないです。
実際のデータすなわち、オブジェクトはこの規格と同じでなければならないです。
<br><br>
```typescript:type aliasでは重複定義ができません。
export type TUser = {
  readonly id: number;
  readonly name: Name;
  email: string;
  receiveInfo: boolean;
  active: YesOrNo;
}

export type TUser = {
  address?: string;
}
```
上記の場合は、エラーが出ます。
type aliasは重複定義が許されません。
<br><br>
```typescript:extends
// interfaceケース
export interface IUserProfile extends IUser {
  profileImage: string;
  github?: string;
  twitter?: string;
}
// type aliasケース
export type TUserProfile = IUser & {
  profileImage: string;
  github?: string;
  twitter?: string;
}
```
クラスのextendsと同じ機能を果たす。
type aliasもextendsを支援します。intersectionという。
IUser をintersection(&)するという意味です。(mergeと同じ機能)
<br><br>

```typescript:多重extends
export interface Color {
  fontColor: string;
  borderColor: string;
}

export type Display = {
  display: 'none' | 'block';
  visibilty: boolean
}

export type Geometry = {
  width: number;
  height: number;
}

// interfaceケース
export interface IStyle extends Color, Display, Geometry {
  tagName: string;
}
// type aliasケース
export type TStyle = Color & Display & Geometry & {
  tagName: string;
}
```

```typescript:属性の名前を定めていない時
export interface A {
  [key: string]: number
}

const iStyle: A = {
  borderWidth: 5,
  width: 300,
};

export interface B {
  [key: string]: any
}

export interface C {
  (url: string, search?: string): Promise<string>;
}

export type C = {
  (url: string, search?: string): Promise<string>;
}

const getApi: C = (url, search = '') => {
  return new Promise(resolve => resolve('OK'));
}
```
タイプを定義をする時、属性名を定めずに定義することも可能です。

interface Aの[key:string]:numberの意味は、
属性が文字列であり、valueがnumberタイプという意味です。
[key:string]のkeyは、私たちが望む名前で作成すればいいです。([xx:string]: numberも可能。)
もしvalueのタイプを制限しないと言ったら、interface Bのようにanyを使用すればいいです。

interface Cの場合は、
(url:string、search:string)は引数の規格を定義しています。
Promise<string>はリターンの規格を定義しています。
意外と「国土基本図図郭」のポリゴンを生成するライブラリがなかったのでPythonで作ってみた！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/203944/3bfaf733-5835-be49-f7a7-ce53b2b76f5a.png)
（[オープンナガサキ](https://opennagasaki.nerc.or.jp/)より）

## はじめに

先日、[長崎県全域の点群データが自由に使えるらしいからみんなで使っちゃおうぜ！？](https://qiita.com/nokonoko_1203/items/a8d58c12c31faf55a7f5)という記事を書きました！

長崎県全域の点群データが無料で使えるようになった！？という情報を最速でキャッチし、すぐにダウンロードしてCesiumJSで可視化してみましたーという記事だったのですが、ダウンロード出来る点群データは上記画像のような区画に分かれており、区画単位でダウンロード出来るようになっていました。

これは「国土基本図の図郭」と呼ばれるグリッドで、[平面直角座標系](https://www.gsi.go.jp/sokuchikijun/jpc.html)の原点(0, 0)を基準にm単位で分割されたグリッドになります。

これとは別に、日本全体を経緯度で分割した[標準地域メッシュ](https://nlftp.mlit.go.jp/ksj/old/old_data_mesh.html)も存在していてこちらもかなり利用されていますが、市区町村が公開する比較的狭い地域のデータや、範囲の限られた測量・調査などは国土基本図の図郭が利用されることも多いです。

で、圧倒的に「標準地域メッシュ」の方が利用されており、弊社の@kanahiro が作成した[japan-mesh-tool](https://github.com/MIERUNE/japan-mesh-tool)などを含め、情報が多いのですが国土基本図の図郭に関しては「国土基本図 図郭」などでググってもさほど情報が出てきません。
（※[こちら](https://club.informatix.co.jp/?p=1293)のサイトで詳しく解説されてはいます。）


また、このグリッドを利用してGISデータ分析を行おうとしても、ポリゴンデータは転がっておらず、作り方もよく分かりません…

ということで、今回はそんな「国土基本図の図郭」をPythonで作成するツールをPythonで作成し、PyPIで公開したので紹介します！

## こんなツール

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/203944/7727d6ed-a991-5a5d-2668-e26350d431fd.png)

プログラムを実行すると、こんなメッシュが取得できます！！！

## 使い方

リポジトリはこちらです。
[japan-basic-section](https://github.com/nokonoko1203/japan-basic-section)

使い方はとても簡単です。

まずはインストールします。

```bash
pip install japan-basic-section
```

その後、こんなPythonプログラムを作成してみてください。

```python
import os

from japan_basic_section.grid import Grid
from japan_basic_section.origin_coords import get_coord_info

system_number = 1
info = get_coord_info(system_number)

g = Grid(system_number, 50000)
grid_50000 = g.make_grid()

crs = info[1]["JGD2011"]
grid_50000 = grid_50000.set_crs(crs)

os.makedirs("../data/output", exist_ok=True)
grid_50000.to_file("data/output/grid_50000.fgb", driver="FlatGeobuf")
```

プログラムの実行方法はお使いの環境によって様々かと思いますが、今回は以下のように上記のプログラムを実行してみました。

```bash
poetry run python ./src/basic_section/__main__.py
```

すると`data/output/grid_50000.fgb`というファイルが作成されたかと思います！

これをQGISなんかで開くと上記のポリゴンが得られます。

図郭のレベル（縮尺）は50000, 5000, 2500, 1000, 500を選択できるようになっており、数値が少ないほど、細かいメッシュが得られます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/203944/0f3a2022-4a5e-1714-dfd6-747f1de7b431.png)
（※レベル2500の図）

ちなみに、ファイル出力ツールではなくGeoPandasのGeoDataFrameが出力される、Pythonパッケージですので、jupyter　notebookなどでもシームレスに利用可能です！

簡単な使い方は以下のnotebookにも書いていますので、参考にしてみてください。
https://github.com/nokonoko1203/japan-basic-section/blob/main/notebooks/sample.ipynb

## まとめ

ということで、今回は「国土基本図の図郭」を作成するツールの紹介でした！

以下だけ覚えて帰っていただけると嬉しいです！

- 日本のメッシュは「標準地域メッシュ」と「国土基本図の図郭」がある
- 市区町村などでは結構「国土基本図の図郭」が利用されるが、情報が少ない
- Pythonで「国土基本図の図郭」を作成したければ[japan-basic-section](https://github.com/nokonoko1203/japan-basic-section)を利用
- Pythonで「標準地域メッシュ」を作成したければ[japan-mesh-tool](https://github.com/MIERUNE/japan-mesh-tool)