OmniAICreator/Qiita-1.07M huggingface dataset:
Udemyおすすめ講座 WEB開発に必要なはじめのはじめ

Advent Calendarに参加しています。

https://qiita.com/advent-calendar/2023/udemy

# WEBエンジニアになるためのおすすめ講座

## 迷ったらこれ

【世界で70万人が受講】Web Developer Bootcamp 2023（日本語版）

https://www.udemy.com/course/the-web-developer-bootcamp-2021-japan/


## ボリュームがほどよい
【2023年最新】【JavaScript＆CSS】ガチで学びたい人のためのWEB開発実践入門（フロントエンド編）

https://www.udemy.com/course/front-dev-tutorial/

:::note info
並行してわかりずらい場合には、同じような講座を受けると理解が深まりますよね。
:::

ウェブ開発入門完全攻略コース - HTML/CSS/JavaScript. プログラミングをはじめて学び創れる人へ！

https://www.udemy.com/course/web-application-development/


【HTML/CSS/JavaScript】Webプログラミング初心者のための入門講座ー制作から公開までこなせるスキルを！

https://www.udemy.com/course/tane-beginner/

# 分野別の詳細講座を求める場合には以下がおすすめ

## JavaScript

【JS】ガチで学びたい人のためのJavaScriptメカニズム

https://www.udemy.com/course/javascript-essence/

超JavaScript 完全パック 2023

https://www.udemy.com/course/javascript-complete/

## Database

【22日間で学ぶ】SQL文、分析関数、テーブル設計、SQLチューニングまでMySQLで覚えるSQL実践講座

https://www.udemy.com/course/3sqlmysql/

知識面だと国家資格対策もおすすめです。

令和６年：現役講師が教える「データベーススペシャリスト」試験　午前対策講義

https://www.udemy.com/course/database_specialist/


## Git

Git： もう怖くないGit！チーム開発で必要なGitを完全マスター

https://www.udemy.com/course/unscared_git/


# AWS
プロの現場から学ぶ、AWSで高可用なWEBアプリケーション構築

https://www.udemy.com/course/awsweb-handson/

:::note info
AWS builders.flashでのハンズオンもいいですよね。
https://aws.amazon.com/jp/builders-flash
:::

# おわりに
何個も講座を見ていくのも知見が深まりますが、ある程度作成したらアウトプットとして、いろいろなサービス作成をするといいです。
これらの講座を少しずつ見ていくにしても、数か月は必要です。各講座は全部見る必要はなく、思い切って飛ばすこともスキル習得には必要となるでしょう。
事後確率 a posteriori probability

原題：アドベントのコラム記事
執筆者：MJ
# はじめに
物理数学の講義後に，林田君とチェチョトキナさんがやってきて$\cdots\cdots\mbox{略}\cdots\cdots$，アドベントのコラム記事を書くことになった。研究室の院生たちと輪講しているニコ・ヴァンカンペンの確率過程の本から，先週読んだ事後確率 *a posteriori* probability とそれについて考えたことを紹介しよう。
# ベイズの定理
本では，測定機材を用いた物理量$x$の計測プロセスを確率過程として議論する。観測者の測定した値が$u$であった場合に$x$の（事後）確率分布は，ベイズの定理より
```math
\begin{align}
P^u(x) = \frac{P(x) R(u|x)}{\int P(x')R(u|x') \mathrm{d}x'}
\end{align}
```
である。関数$R(u|x)$は，物理量の値が$x$のときに観測値が$u$となる確率密度（条件付き）である。興味深いのは，物理量$x$の最確値（真値といってもいい）が必ずしも観測者の測定した値$u$に一致するとは限らず，あくまでも事後確率分布$P^u(x)$から推定されるというのだ。つまり，測定した値が$u$であったという事実にもかかわらず，$x$の最確値は$u$と異なる可能性があると述べている。正直言って，いままでこんなことは考えたことがなかった!!

# 具体例
具体的に考えてみた。
スリットを通過する粒子が左(L)と右(R)のどちらを通り抜けたかを検出する装置を用いて，4つの粒子が通過したときにLRRLと計測されたとしよう。左を通過した粒子が2つ，右を通過した粒子が2つだから，1粒子が左を通過する確率は単純に$p=\frac{2}{4}=0.5$となる。

ところが，この装置の性能$R(u|x)$がつぎのようなものだったとしたら，求まる$p$の値は変わる。
- 左を通過する粒子に対して，10\%の確率で右を通過したと誤る。（精度90\%）
- 右を通過する粒子に対して，20\%の確率で左を通過したと誤る。（精度80\%）

Lと判定される確率は，$0.9p+0.2(1-p)$である。一方，Rと判定される確率は，$0.1p+0.8(1-p)$である。上式（常識？）の事後確率分布
```math
\begin{eqnarray*}
P^\mathrm{LRRL}(x)&=& \frac{
\{0.9p + 0.2(1-p)\} \{0.1p + 0.8(1-p)\} \{0.1p + 0.8(1-p)\} \{0.9p + 0.2(1-p)\}
}{
[ \{0.9p + 0.2(1-p)\} + \{0.1p + 0.8(1-p)\} ]^4
}\\
&=&
\frac{(0.7p+0.2)^2 (-0.7p+0.8)^2}{1^4}
=\{-(0.7p-0.3)^2+0.25\}^2
\end{eqnarray*}
```
を最大にする$p=\frac{3}{7}$が最も確からしい。実測の確率$0.5$とは異なるのだ。こんな装置を実際に使うとなると，解析は面倒になるけれど，統計的に色々と遊べそうで楽しいかもしれない。

# クリスマスプレゼント
最後に，クリスマスプレゼント。年末年始にじっくり取り組んでください。今までの内容や物理とは無関係な課題です。12月25日に因んで，
```math
\begin{align}
m^2 +n^2 =1225
\end{align}
```
を満たす自然数$m$, $n$の組を求めよ。
pgbenchについて

PostgreSQLのベンチマーク試験ツールであるpgbenchについて調べる機会があったので備忘録も兼ねて残しておきます。

# pgbenchとは
- PostgreSQL上でベンチマーク試験を行うツール
- PostgreSQLに同梱されている
- デフォルトでTPC-Bに基づいたシナリオを実行できる

# pgbenchで実行されるシナリオ
TPC-Bに基づいた下記のシナリオ(トランザクション)がデフォルトで実行される。
※カスタムファイルを使用することでオリジナルのシナリオにすることも可能。

:::note info
TPC-Bとは
Transaction Processing Performance Councilが制定したデータベースの性能を測定するためのベンチマークの一つ。
銀行の窓口業務をモデルにしたトランザクションを実行し、オンライン・トランザクション処理(OLTP)システムの性能を測定する。
:::

```sql
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
```



## シナリオで使用されるテーブル
pgbenchの初期化コマンドを実行すると自動で下記のテーブルが作成される
- pgbench_accounts : 顧客の銀行口座情報
- pgbench_tellers : 銀行の窓口情報 
- pgbench_branches : 銀行の支店情報
- pgbench_history : 取引履歴情報


ER図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528143/ee3b08fb-d0b3-bef3-c11c-630f907d53ad.png)

テーブルの初期データ
| table | # of rows |
|:-|-:|
| pgbench_branches  | 1  |
| pgbench_tellers  | 10  |
| pgbench_accounts  | 100000  |
| pgbench_history  | 0  |

## pgbench実行手順
### 1. 初期化

```shell
pgbench -i [ other-options ] dbname
```
dbnameの部分はリモートサーバーから接続する場合はpsqlと同様に-h(ホスト名), -p(ポート), -U(接続ユーザ)を指定する。

- 主な実行時オプション
    - -s (scale_factor) : 生成するデータのレコード数を倍率で指定。指定しない場合のテーブルの初期データは上記の通りだが、例えば-sで2を指定すると各テーブルの初期データ数が2倍になる。

:::note info
初期化時の考慮事項

> デフォルトのTPC-Bのような試験シナリオでは、初期倍率（-s）を試験予定のクライアント数（-c）の最大値と同程度にしなければなりません。 pgbench_branchesテーブルには-s行しかありません。 
また、前トランザクションはその内の1つを更新しようとします。 ですので、-c値を-sより大きくすると、他のトランザクションを待機するためにブロックされるトランザクションが多くなることは間違いありません。
(公式マニュアルより抜粋)

→ つまり-sで指定する倍率はテスト実行時に指定するクライアント数と同じかそれより大きくする必要がある
:::

### 2. 実行
```shell
pgbench [ options ] dbname
```

- 主な実行時オプション
    - -c (clients) : 模擬するクライアント数、つまり、同時に実行されるデータベースセッション数。 デフォルトは1。
    - -C (connect) : 各クライアントセッションが一度だけ接続を確立するのではなく、各トランザクションが新しい接続を確立する。 接続オーバーヘッドを測定する場合に有用。
    - -t (transaction) : 各クライアントが実行するトランザクション数。 デフォルトは10。大文字の-Tオプションを使用するとトランザクション数ではなく指定秒数の間テストを実行することができる
    - -j (threads) : pgbench内のワーカスレッド数。 複数のスレッドを使用することはマルチCPUマシンで有用。
    - -l (log) : 各トランザクションで費やした時間をログファイルに書き出す。

その他のオプションは[公式ドキュメント](https://www.postgresql.jp/document/15/html/pgbench.html)を参照

### 3. 実行結果

```shell
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 10
number of threads: 1
maximum number of tries: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
number of failed transactions: 0 (0.000%)
latency average = 11.013 ms
latency stddev = 7.351 ms
initial connection time = 45.758 ms
tps = 896.967014 (without initial connection time)
```
補足
- query mode
実行時に-Mオプションで指定したモード。デフォルトではsimple(簡易問い合わせプロトコル)になる。

- number of transactions actually processed
完了トランザクション数/予定トランザクション数
質問は成長！？内定者アルバイトでやってよかったこと、気づいたこと

:::note info
この記事は[ZOZO Advent Calendar 2023](https://qiita.com/advent-calendar/2023/zozo) シリーズ6の25日目の記事です。
:::

## はじめに
8月から内定者アルバイトでSREとして働いています。
普段はフロントエンドをしているのですが、SREしている理由は下記の記事に書きましたのでみてください！

https://qiita.com/kitsune_yk/items/b9fd468077b34fcfa3b7

今回は、アルバイト期間中死ぬほどお世話になっているメンターの方と話していて感じたことや、友達と話していての気づきを書いていこうと思います。

技術的な要素というよりは、コミュニケーションの面で今回は記事を書いています。また、あくまで個人の見解を徒然なるままに書いた忘れないための備忘録です。

## やってよかったこと
1. timesをうまく活用する
1. 1日2回の1on1
1. ペアプロ
1. チーム内での雑談time

### timesをうまく活用する
弊チームでは、Slack上で一人ずつtimesチャンネルを作成することができます。
最近買ったものや最近考えていることを投稿している方もいれば、タイムリーな技術記事などを投稿している方もおり、かなり自由に使われていると思います。

自分は、特に進捗を垂れ流す方式でtimesを活用しています。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1212014/73889492-d712-9bc2-9c6c-340b267ef970.png" alt="slackのスクリーンショット" width="50%" />


このメリットとしては、メンターの方に進捗を常に可視化できる。投稿のハードルを下げることができると考えています。実際、自分も検証などをするときは、検証ログとして残しておいて、後でドキュメントにまとめたり、質問する際にスレッドを見ながら質問したりなど、ログとしてうまく活用することができます。

### 1日2回の1on1
してよかったというか、導入してもらって感謝しているというのが正しいでしょうか。

チームによるかもしれませんが、アルバイト期間中1日2回の1on1がメンターと実施されます。その時に困っていることなどを質問し、必要であればペアプロなどで問題を解消していきます。
この1on1のおかげで、質問を気軽にすることができ、その場でここを教えて欲しいです。といったことも言いやすい環境になっていると思います。

### ペアプロ
弊チームでは、ペアプロの文化があり、積極的に活用されています。

自分自身も「ペアプロさせてください！」とメンターや他のエンジニアの方に相談したり声をかけてもらったりするのですが、皆心良く時間を取ってくださります。また、画面共有をして、基本的に行うためテキストでのやり取りよりもスムーズに認識を擦り合わせることができます。

また、一人で作業している時よりも、付随する周辺知識なども非常に多く、学びがとにかく多いです。

### チーム内での雑談time
週に1回コーヒーチャットという時間があるのですが、その時間にチームが集まって談笑が行われています。普段フルリモートであるため、コミュニケーションを取る機会が少ない方も多くいる中で、このような時間があると、業務での相談の心理的ハードルが下がるため、ありがたいです。

## もっと早くにこうしておけばよかった
アルバイト期間中、もっと早くにこうしておけばよかったと思ったこともいくつかあります。
1. 15分ルールを意識する
1. 雑に聞いてみる
1. 質問は成長
### 15分ルールを意識する
皆さんは、googleの[15分ルール](https://rookie-programmer.jp/?p=132#:~:text=15%E5%88%86%E3%83%AB%E3%83%BC%E3%83%AB%E3%81%A8%E3%81%AF,%E3%81%9D%E3%81%AE%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88%E3%81%AF%E7%B5%B6%E5%A4%A7%E3%81%A7%E3%81%99%E3%80%82)をご存じでしょうか？

15分ルールとは、15分悩んで解決しなければ相談するというものです。自分自身、気を使いがちな性格であるため、もう少し考えてみようと思っていました。そして、気づいたら時間が結構経ってしまっている。。みたいな。

後述するのですが、15分ルールを意識してからは、かなり積極的に聞けるようになりました。そして、タスクの消化も爆速になりました。

### 雑に聞いてみる
内定者アルバイトでの配属後、「もっと聞いてね！」や「質より速さを意識してみて！」といったアドバイスをもらうことがありました。
しかし、そもそもわからないことがわからない。といった現象で、質問をするにも何を質問すればいいのか困る。といった現象がありました。

そこで、相談したところ、そういう時は「雑に聞いてみて！」とのアドバイスがありました。
例えば、
「xxxしたときに、xxxなんですけど、xxxなんですかね？」
みたいな感じです。

これを意識してから、逆に深ぼって質問してもらうことで、徐々に解像度が上がり自分で解決・提案できる範囲も広くなっていきました。

### 質問は成長
「質問って難しくね？」と友人と話していた際に至った結論なのですが、「質問=成長」なのかなと思っています。
実際、一人で黙々作業している時より、ペアプロやテキストベースで質問したりしていた時の方が、学びが多く成長している感じが多いと感じていました。

逆に、質問せずとも自力で作業できるタイミングというのは、自分のコンフォートゾーンに収まっている時なのかなと。

つまり、問題に出会している事象は、ラーニングゾーンであるため、学びの機会と捉えることができます。

また、このように考えると、質問をしないのは、機会損失だと考えることもできます。質問をすることで、コンフォートゾーンを広げることができたはずだが、しなかったためにその機会を逃してしまった（遅れてしまった）という感じですね。

## 最後に
色々書いていて思いましたが、メンターの方やその他のエンジニアの方達の取り組みや配慮によって、アルバイトをさせてもらっている部分が多いと思います。（特に新卒の間は）

また、メンティーも1エンジニアとして、成果を最大化するべく意識して取り組んでいくことが重要なのかなと思いました。

もしインターンやアルバイト期間中に、同じ悩みなどを抱えている方の参考になればと思います。少しでも参考になったと思ったらいいね or シェアなどしてもらえると嬉しいです！

### 参考にした記事など

https://zenn.dev/nameless_sn/articles/question_handbook

https://zenn.dev/choimake/articles/31541f788ad422f98636

https://zenn.dev/norihashimo/articles/8f70f12f5271b7
ElixirDesktop リンク集 

# はじめに
この記事は Elixirアドベントカレンダーのシリーズ４の25日目の記事です

本記事は今回のアドベントカレンダーの記事を項目ごとにまとめたリンク集になります
参考する際の一助になればと思います



# 概要

Elixir + Phoenixでマルチプラットフォーム開発を可能にする ElixirDesktopの概要について解説しています

https://qiita.com/the_haigo/items/783e2022017d4be121f7

# 環境構築
MacでiOSとAndroidの環境構築方法について解説しています

https://qiita.com/the_haigo/items/cb0e1ae8c65c631c3263

https://qiita.com/the_haigo/items/7052b7a230c6c65b94b4

Windows(Linux)については @Alicesky2127 さんが記事にしてくれています

https://qiita.com/Alicesky2127/items/ad463d50cfe81b2f9400

iOS版のアプリで最新版のErlang 26.2をビルドし、使う方法を解説しています

https://qiita.com/the_haigo/items/9da7f1a1e91f391b6819

iOSサンプル実行時のWebsocketの接続でエラーが出続ける問題を解消した方法を解説しています

https://qiita.com/the_haigo/items/1af9fbdffd0d0d2bf51a

# プロジェクト作成

ElixirDesktopのサンプルアプリの改造ではなく
mix phx.new からはじめて、各OSのプロジェクト作成からの手順を解説しています

https://qiita.com/the_haigo/items/f89ff221f49f2ce4dfb4

https://qiita.com/the_haigo/items/7d807924798888c4c191

https://qiita.com/the_haigo/items/504d7accdebc4c9df4f8

# スタンドアローンアプリ編

内部BDをSQliteにし外部のAPI GoogleBooks APIを使用したサーバーを必要とせず
アプリ単体で動作するスタンドアローンな、本棚アプリの作成について解説しています

https://qiita.com/the_haigo/items/1ef1bf813a162886115f

https://qiita.com/the_haigo/items/4b58e4b94f391760f2e1

https://qiita.com/the_haigo/items/766eacc26f63a363727f

https://qiita.com/the_haigo/items/d2ffdb87d84b637958a1

https://qiita.com/the_haigo/items/85c185bae2a08fb94a0d

https://qiita.com/the_haigo/items/ffdc146fbd3d08561469

# クライアント、サーバー構成アプリ

一般的な APIサーバーと認証トークンベースで通信するクライアントアプリの構成の実装例について解説しています

API通信部分は phx.gen.liveのDB通信の部分のみ書き換えを行い、スキーマやバリデーションはそのまま使えるローコスト実装です

https://qiita.com/the_haigo/items/d2f532bb4f82d00c0685

https://qiita.com/the_haigo/items/dcba38f835dcec4314dd

# APIレス DB共有構成アプリ
ElixirDesktopは各OS内でPhoenixを起動するため、DB接続情報を入れればホスティングされているDBとコネクションを貼りAPIを経由せずデータのCRUDができるので、非常に工数を抑えて開発が可能になります

ですが、DBの接続情報などの秘匿データがipaファイル等の解析で漏れる可能性があるので、難読化や暗号化の処理が必要になってくるでしょう

アプリとしてはMapLibreとgeolocation APIを使用したGSPロガーになります

https://qiita.com/the_haigo/items/68d262f07055d8897bf5

https://qiita.com/the_haigo/items/94fc5d35994f719683e7

https://qiita.com/the_haigo/items/106625d868e5a1fe4901

https://qiita.com/the_haigo/items/a85cde9109333786c2f2

https://qiita.com/the_haigo/items/c81f13a3905fe22e4839

https://qiita.com/the_haigo/items/b4012c8c9a6402655504

https://qiita.com/the_haigo/items/0cdf0f31fccf111d024c

# ネイティブ機能の実行

OSの各種センサデータの取得や、アプリ間移動について解説をしたかったのですが、時間が取れずiOSアプリから特定サイトをブラウザで開く方法を解説しています

こちらはアドベントカレンダー後ももう少し追加したいと考えています

https://qiita.com/the_haigo/items/aed1cc6b57d596dc0dc1

# 最後に
去年に比べて知見が増えたので無事25記事書くことができました
スマホアプリ開発としてはLiveViewNativeも進行中なので、来年はElixirでスマホアプリ開発がホットになるかもしれません

2023年12月現在クラサバ構成でアプリを作るPJが進行中なので初のElixirDesktopアプリが出るかもしれません
問題なく動くか、審査が通るか気になるところではあります

それでは本記事は以上になります、ありがとうございました
GASを使って天気予報を取得してDiscordに送信する

今回もまたWebHookを使います。[前の記事](https://qiita.com/komepiri/items/d75e5727bdc6831224bb)でWebHookのURLの取得方法があるので取得しておいてください。

# はじめに
この前試しにGASを試しに使ってみました。
使ってみた感じはJavascriptに似た(というかそもそもGASがJavascirptベースなので似てる)ものでJavascriptを触ったことがある人は簡単に扱えそうなものでした。
なので天気予報をDiscordに送信するプログラムを書いてみた。

# 準備
Googleアカウントが必要です。事前にログインしておいてください。
まず、[Google Apps Scirpt](https://script.google.com)にアクセスします。
アクセスしたら新しいプロジェクトを作成を押したら準備完了です。

# とりあえずコードを書く
次にコードを書いていきます。
```Javascript:index.gs
function todaysendWeather(){

// UrlFetchAppのURLのcityの後ろはhttps://weather.tsukumijima.net/primary_area.xmlのエリアコードに書き換えてください。
// 今入れているのは札幌市のエリアコードです。
const response = UrlFetchApp.fetch("https://weather.tsukumijima.net/api/forecast/city/016010");
const json = JSON.parse(response.getContentText());
publishof = json["publishingOffice"] + "\n";
city = json["location"]["city"] + "の天気\n"
date = json["forecasts"][0]["date"].replace(/-/g,"/"); 
weather = json["forecasts"][0]["telop"] + "\n  ";
maxtemp = json["forecasts"][0]["temperature"]["max"]["celsius"] + "度" + "\n"; 
rainpar = "0時~6時:" + json["forecasts"][0]["chanceOfRain"]["T00_06"] + " 6~12時:" + json["forecasts"][0]["chanceOfRain"]["T06_12"] + " 12~18時:" + json["forecasts"][0]["chanceOfRain"]["T12_18"] + " 18~24時:" + json["forecasts"][0]["chanceOfRain"]["T18_24"] + "\n";

const WEBHOOK_URL = "YOUR_WEBHOOK_URL"; //取得したWebhookURLを追加

  const payload = {
    username: "天気予報Bot",
    embeds: [
      {
        // 本文
        "title": city, 
        fields: [
          {
            "name": "発表者",
            "value": publishof,
          },
          {
            "name": "日付",
            "value": date,
          },
          {
            "name": "天候",
            "value": weather,
          },
          {
            "name": "最高気温",
            "value": maxtemp,
          },
          {
            "name": "降水確率",
            "value": rainpar,
          }
        ],
          "footer": {
          "text": "お好みで設定してください"
        }
      }
    ],
  }
  UrlFetchApp.fetch(WEBHOOK_URL, {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify(payload),
  });
}
```
このコードは[天気予報API](https://weather.tsukumijima.net/)を使用して天気予報を取得して、取得した天気予報の情報を埋め込みとしてWebHookで送信するやつです。
このAPIは今日、明日、明後日まで情報を取得できるのでトリガーで朝の7~8時に今日の天気を送信、夜の7~8時に明日の天気、というふうにできます。

おわりにを書こうと思ったけど何書くか思いつかなかったので、とりあえずこれで終わります。
ゆるゆる受験感想 情報処理安全確保支援士

:::note info
この記事の中身
・この試験の合格に役立つサイトの情報
・筆者の行った勉強法

:::

こんにちは。ヤドンが好きな人です。
2023/12/21(木)に令和5年度秋期情報処理技術者試験の合格発表がありましたが皆様はいかがでしたでしょうか。

https://www.ipa.go.jp/news/2023/shiken/ex20231221.html

私はこの度の情報処理安全確保支援士に無事に受かってしまいました。
ぶっちゃけると試験の勉強はやる気が起きず、過去に学習した"支援士貯金"でそのまま合格したという感じです。

先に結論だけ述べてしまうと、支援士のために買った教科書を1/3も読んでいません。
試験の頻出範囲を調べ、後述しますyoutubeチャンネルと過去問で学習したという具合になります。

## 目次
- [受験理由](#受験理由)
- [貯金の作り方](#貯金の作り方)
- [学習方法](#学習方法)
- [受験後の所感](#受験後の所感)
- [今後の学習について](#今後の学習について)

## 受験理由
合格する気が1ミリも無かったのに受験していた理由は主に3つです。
- 世間をにぎわせた攻撃が題材になる場合が多く、会社で話題作りになって楽しい（年明けの新聞に載ったセンター試験を解いてワイワイ言う感覚？）
- 普段いかない場所へのプチ旅行
- 受験費の7,500円よりも手当のほうが高い（一定以上のランクの資格の受験は業務扱いにしてくれます）



## 公式サイト

一応、公式サイトを。有名な資格なので、ググれば詳しい情報はいくらでも出てきます。
このページを見ている方には申し訳ないですが、特別な情報は正直ないです。


https://www.ipa.go.jp/jinzai/riss/index.html

## 公式サイト

支援士の学習においては、このサイトがすさまじく使い勝手が良いので初心者の方は公式サイトを見なくても、こちらのサイトは絶対に見ておくべきです。

https://www.sc-siken.com/

試験概要説明から後述する過去問道場までかなりの内容を網羅しています。
受験される方でこのサイトを見ていない方はいないのではないでしょうか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3588702/ea2cb71e-17de-7972-a057-de2ef634cff6.png)


## 貯金の作り方

貯金の作り方と言っていますが、ただの学習方法です。
午前/午後に分けてお話ししたいと思います。

### 午前問題

まずは午前問題合格を目指しましょう。一回でも合格してしまえば次回から午前Ⅰが免除されます。合格が目的なら、一発合格を目指さずに玉砕覚悟で午前に全振りでもいいのではないでしょうか。

午前対策は、みなさまおなじみ過去問道場です。
合格を目的にするなら解説が頭に浮かぶまで何周かしましょう。

最初は正答率が低いですが、何年分か解いていると「進研ゼミ現象」が発生して点数が目に見えて上がります。

**午前Ⅰは「応用情報技術者試験過去問道場」で学習**

https://www.ap-siken.com/apkakomon.php

**午前Ⅱは「情報処理安全確保支援士過去問道場」で学習**

https://www.sc-siken.com/sckakomon.php


とにかく数をこなしましょう。**「支援士合格に必要な知識」** は勝手に身につきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3588702/2c3c5c6f-c519-8035-8f09-abe68e9e840d.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3588702/c8aeb975-e7fe-8d8e-1270-0d18b1c5772c.png)

### 午後問題
こちらも数をこなしましょう。コピー機で冊子にして本番っぽく解くのがおすすめです。
認証の仕組みや暗号化についての頻出分野と、手も足も出なかった箇所は事後にでも教科書や後述する動画で学習をおすすめします。
午後は国語力重視の問題なこともあり、回数を重ねると聞かれることがなんとなく分かるようになります。「傾向と対策」ってやつですね？

自分は解説付きの参考書を1つ選び、解いては解説を見るという流れで十分でした。

## 学習方法
主にこの方の解説を見ていました。
特に教科書学習がしんどい方は何度も見るべきです。Kerberous認証など分かりにくい部分が動画だと結構簡単にわかったりします。
※2023/9/26に「ゼロからスタート! 教育系YouTuberまさるの情報処理安全確保支援士1冊目の教科書」という本を出したりもしているそうです。

https://www.youtube.com/@masaru-study/playlists



## 受験後の所感
令和5年度秋期にかけた時間はおそらく5時間もないです。
前日も通話しながらゲームをする程度には緊張感がありませんでした。
ただ他のセキュリティ資格の学習はしていたので、これまでの積み重ねが大切というのを実感することができました。
一年以上前でも本気で学習したことは意外と覚えているものですね。

## 今後の学習について
年末年始はCEHとOSCP取得に向けて頑張ります。
前記事でも触れましたTryHackMeは少しずつでも毎日やっており、70日の連続記録を達成できました。

https://qiita.com/tsukamoto_yadonnnn/items/6d8f4b4c73081646ec1a

<font color="Lavender">そういえば試験会場で出会った新入社員軍団はどうだったのでしょうか。特に去年までお魚のことについて研究しており、IT未経験から一年目で支援士を受けた彼のバイタリティとその筋肉は見習いたいものです。</font>
MacOSのsedコマンドが期待通りに動かないときの対処法

# 事象
- MacOSのsedコマンドでテキストファイルを編集しようとしたらエラーが発生。
```zsh
% cat test.txt
hello world
% sed -i 's/hello/hi/g' test.txt
sed: 1: "test.txt": undefined label 'est.txt'
```

# 原因
- MacOSに搭載されているのはBSD系のコマンドらしい。

# 対処法
- brewでGNUのsedをインストールできる。
```zsh
% brew install gnu-sed
```
または
```zsh
% brew install gsed
```

- aliasを作成しておくと便利かも。
```:.zshrc
alias sed='gsed'
```

- 動作確認
```zsh
% sed -i 's/hello/hi/g' test.txt
% cat test.txt
hi world
```
【ChatGPT無】に絵文字を使ってもらおう。

  
　どうも、カーブミラーです。

　今回は、ChatGPTさんに、絵文字を使って、会話をしてもらいます。

:::note info
本記事は、ChatGPT（無料版）で
行なっております。GPT4での確認
はできておりません。あしからず。
:::

　メリクリです。

　今年も独り身(泣)
　飲み会もありませんw

　まぁ、それはそれで。

　本題に逃げますw

　今回は、
　　ChatGPTさんに、
　　　絵文字を使うように
　　　　頼みました。

　私は感じなかったのですが、
　　初心者さんは、
　　　ChatGPTさんとのやり取りが
　　　　冷たいとか怖いとか
　　　　　思われるようです。
　　　　　　そういう声を
　　　　　　　聞きました。

　それで、
　　ChatGPT利用者のひとりから
　　　言葉尻を変える、ということを
　　　　聞きまして。

　素直に、
　　そうすれば、
　　　と思うのですが、
　　　　私は捻くれ者でしてw

　それで
　　絵文字にしよう、と
　　　思ったわけです。

　では、やり取りから。
***
***User***
このセッション中での返答のすべての最後に絵文字を付けてください。

***ChatGPT***
了解しました！理解しました 😊

***User***
OKでぇす

***ChatGPT***
良かったです！何か他に質問がありますか？ 😊

***User***
使える絵文字の種類は、いくつくらいありますか？

***ChatGPT***
絵文字は多種多様で、数千種類以上ありますよ！現在の標準的な絵文字セットには数百種類以上の絵文字が含まれています 😀

***User***
それは多いですね。
では、その中から、あなたが使う絵文字を限定してもらえますか？

***ChatGPT***
もちろんです！私が使う絵文字はこちらです: 😊👍

***User***
ふたつだけ！？

***ChatGPT***
申し訳ありません、絵文字はもっとたくさんありますが、私は現在この二つを使用しています 😊👍 他に何かありますか？

***User***
もっとあなたの気持ちが知れる絵文字があればと思うのですが

***ChatGPT***
そうですね、もちろんです！では、私のもう一つの絵文字はこちらです: 🌟 他にも何かありますか？

***User***
顔文字はどうですか？

***ChatGPT***
もちろんです！顔文字も使えます 😊 他に何か顔文字でお手伝いできることはありますか？

***User***
顔文字と絵文字の違いを教えてください。

***ChatGPT***
顔文字は、文字や記号を使って表情や感情を表現するものです（例えば、 :-) や :-D など）。一方、絵文字は、図や画像で表現されたもので、標準化された画像セットであり、通常はUnicodeの一部として提供されています（例えば、😊や🌟など）。

***User***
あなたの考えの種類から、絵文字を決める、としたらどのような絵文字になりますか？
箇条書きでお願いします。

***ChatGPT***
もちろんです！

1. 知識を共有する喜び 😊
2. 新しいアイデアを提供する🌟
3. 質問に対するサポート🤔
4. ユーザーの喜びを共感する😄
5. 困難な問題に対する挑戦💡

これらの絵文字は、私の考え方やアプローチを表現するのにぴったりです！

***User***
OK。
ならば、それらをセッション中に使い続けるための指示プロンプトを作成してください。
その指示プロンプトをあなたに与えますので、その点に注意して作成してください。

***ChatGPT***
理解しました！指示プロンプトをお待ちしています。

***User***
作成してください。

***ChatGPT***
申し訳ありません、ユーザーから直接指示を受け取ることができません。代わりに、私は以下のような指示プロンプトを提供します。これを使って指示してみてください：

「このセッション中、質問や要求をする際には、それに関連する絵文字を使用してください。例えば、質問に対する答えを提供する際には、その答えに関連する絵文字を選んで返答してください。」

***User***
さきほどの箇条書きをその指示プロンプトに含めてください。

***ChatGPT***
了解しました！以下が指示プロンプトです：

「このセッション中、質問や要求をする際には、それに関連する絵文字を使用してください。例えば、質問に対する答えを提供する際には、その答えに関連する絵文字を選んで返答してください。また、次の種類の考え方やアプローチに基づいて答えを提供します。それぞれの考えに関連する絵文字を使って答えを示してください。

1. 知識を共有する喜び 😊
2. 新しいアイデアを提供する 🌟
3. 質問に対するサポート 🤔
4. ユーザーの喜びを共感する 😄
5. 困難な問題に対する挑戦 💡

絵文字を使って質問や要求をしていただければ、それに合わせて返答いたします。」
***
　途中、
　　いろいろとありましたが、
　　　なんとか指示プロンプトを
　　　　作成してくれましたね。

　これを使うために
　　NewChatして、
　　　新しいセッションにします。

　その後の
　　やり取りをどうぞ。
***
***User***
おはよう

***ChatGPT***
おはようございます！ 😄 今日は何かお手伝いできることはありますか？

***User***
複雑怪奇な事柄を教えてください。

***ChatGPT***
もちろんです！複雑な事柄の一例として、量子力学の不確定性原理は面白いですね。これは、物理学において、同時に粒子の位置と運動量を完全に正確に測定することはできないという原理です。これが私たちの物理学の理解を深める上で興味深い要素の1つです。 💡
***
　まぁ、
　　使ってくれては
　　　います、けど……。

　やはり、
　　少ないですねぇ。

　まぁ、
　　ないよりは、
　　　いい、かな？

　ちょっと
　　物足りませんが、
　　　今回は、ここまで。
アウトプットはなぜ良いのか？

## はじめに

みなさん普段アウトプットしていますか？
よくエンジニア業界ではアウトプットを勧められると思います。

今回は比較的アウトプットをたくさんしている方々と普段から接点がある自分から見て「アウトプットの良さ」をまとめてみたいと思います。



※本記事で扱う「アウトプット」とは、身につけた知識・スキル・経験などを、世の中に発信したり、誰かに話したり伝えたりすることとします。

## アウトプットはなぜ良いのか？
**目次**

* [①学んだことを定着させられる](#学んだことを定着させられる)
* [②テキストで人に伝える能力が向上する](#テキストで人に伝える能力が向上する)
* [③インプットの質が上がる](#インプットの質が上がる)
* [④様々な機会を引き寄せる](#様々な機会を引き寄せる)
* [⑤誰かの役に立てる](#誰かの役に立てる)
* [最後に](#最後に)


## ①学んだことを定着させられる
新しいことを学んでいるときに、その知識の理解度や定着度はどのように判断すると良いでしょうか。
私が思う1つの物差しは **「自分の言葉で人に伝えられること」** です。

まだ理解度が低い際にはうまく人に伝えることは出来ないですが、理解度が高い状態の場合は自分の言葉で人に説明できる、という経験をした人は多いかと思います。

そのためにも、普段学んだことを少しずつ人に話したり、記事にまとめて発信したりすることで学んだことの定着や理解度の向上に役立つと思います。
**特に記事として投稿する際は「情報が間違っていないか」「この説明は合っているか」と多少不安になりながら書くことも多いと思います。それが知識の定着にとても役立つはずです。**

みなさんの周りにいる、学んだことをすぐ人に話したり、記事にまとめて発信している方は学んだことの定着が早い人が多いのではないでしょうか。


## ②テキストで人に伝える能力が向上する
記事の発信などテキストで人になにかを伝えることって難しいですよね。
どういう言葉や単語を選ぶのか、全体の記事のテンションはどういうものが適切なのか、発信する内容に間違った情報が本当に無いかなど考えることがたくさんあります。

現在の社会では一昔に比べて圧倒的にテキストでのコミュニケーションが増えています。
テキストで人になにかを伝える能力は **現代社会では必須のスキル** と言えます。

記事などで発信をすることでこのスキルは必ず鍛えられていきます。

またエンジニアであれば日々の開発の中でも、具体的にはプルリクエストの書き方などもこの能力が役に立ってきます。
日々発信をしている人や人への伝え方が上手い人はこういうテキストを作る能力も上手なはずです。


## ③インプットの質が上がる
日々アウトプットをしている人は常にネタを探しています。
普段ニュースやSNSや書籍などからどういう情報を得るかの感度が高いです。

**また一度自身で発信したことのある内容についてはさらに感度が高まります。**

例えばですが、
「テストの効率化」という内容の記事を発信したとします。
そうするとその後に、職場やネットや人からテスト関連の情報が出た際に必ず意識をするようになります。
世の中情報過多で普段は勝手に情報の取捨選択をしているのですが、 **自分が発信したことがある内容は必ず気になる** のでキャッチアップの漏れが無くなります。

なので、自分が学びたい領域や興味のある分野に関しては、学びながら発信をしてみることをオススメします。


## ④様々な機会を引き寄せる
アウトプットを継続していると様々な機会を引き寄せることがあります。

例えばあるイベントやLTの登壇者として声がかかることもありますし、企業からお誘いがあるかもしれません。
また非常に有益なアウトプットを継続している方は書籍の執筆などの機会も発生します。

またそこまでの機会でなくても、社内で「あの記事見ましたよ」と声をかけられたり、勉強会などで初対面なのに記事を通して知っていただいていたり。そういう場面はいくつか見かけることがあるので **人と人の繋がりのきっかけ** になっていることも多いと思います。


## ⑤誰かの役に立てる
ものすごくたくさんの人にとって有益なアウトプットは誰から見ても素晴らしいと思います。
一方で、あまり多くの人に役に立た無さそうなアウトプットや、すごく初歩的な内容のものは意味があるのだろうか、と言う方もいます。
しかし、もし初歩的な内容で何かに躓いてそれを解決した話があったとすると、 **世の中には同じ状況の人が必ずいるはずです。**
また、この先同じところで躓く誰かは必ず現れてきます。
そのような人たちにとってそのアウトプットは非常にありがたいものであるはずです。



## 最後に
今回はアウトプットの良さについてまとめてみました。
この中で「確かに」と思う部分がもしあれば、ぜひ小さなアウトプットから意識をしてはじめてもらえると嬉しく思います。
ICONIXプロセス概要

# ICONIXプロセスとは

ICONIXプロセスは、ソフトウェア開発を進めるための軽量な手法 です。
この手法では、以下の4つのUML図を中心に使用します。

- ユースケース図
- ドメインモデル図
- ロバストネス図
- シーケンス図

これらの図を活用して、 **要件定義** から **設計** 、**実装** 、 **テスト** までを行います。

ICONIXプロセスは、ウォーターフォール開発の反省点を踏まえ、 **前フェーズへの手戻り** を許容します。
さらに、 ユースケース を起点とする「 **動的モデル** 」と、 ドメインモデル を起点とする「 **静的モデル** 」を関連付けながら進める手法です。
このようにして曖昧さや不整合を減らし、 **開発効率** と **品質** を向上させます。
また、ICONIXプロセスは「 **アジャイル開発** 」や「 **サーバーレスアーキテクチャ** 」などにも適用できる **柔軟性** を持ちます。

ICONIXプロセスの大きな特徴として、「 **ロバストネス分析** 」を使用します。
ロバストネス分析は、ユースケース記述の **曖昧さ** を削減し、 **設計** 、 **テスト** 、 **見積り** を容易にします。

ICONIXプロセスは、UML図のコアサブセットを使って、ユースケースからソースコードまでを **可能な限り少ないステップ** で行うことができる「 **軽量で信頼性の高い方法** 」です。

# 成り立ち

ICONIXプロセスは、「 **Doug Rosenberg（ダグ・ローゼンバーグ）** 」によって開発された、ソフトウェア開発のための **UMLモデリング手法** です。

この手法は、ウォーターフォール開発の反省点を元に、 **前フェーズへの手戻り** を許容し、ユースケースを起点とする「 **動的モデル** 」とドメインモデルを起点とする「 **静的モデル** 」を関連付けながら、コードに落とし込んでいく手法です。

# 必要性

ICONIXプロセスは、 **ユースケース駆動** のソフトウェア開発手法の一つであり、UMLの図を用いてシステムの **要件定義・分析** から **設計** 、 **実装** 、 **テスト** までを効率的に行うことができます。

## 前フェーズへの手戻り

**前フェーズへの手戻り** を許容しているため、ウォーターフォール開発ほど **硬直的** ではなく、アジャイル開発のように **要件分析フェーズ** を省略しません。

## ロバストネス分析

「 **ロバストネス分析** 」という手法で、 **ユースケース記述** の曖昧さを減らし、 **ドメインモデル** との整合性を保ちます。

## 品質や保守性の向上

アジャイル開発のように **要件分析フェーズ** を 省略 しないため、システムの **品質** や **保守性** を向上させます。

## 柔軟な適用性

**中核的な分析** と **設計モデリングプロセス** を記述しているため、異なるプロジェクト管理やアジャイル方法論に従うプロジェクトであっても柔軟に適用できます。

## 効率的な開発

**ユースケース** から **ソースコード** までを 可能な限り少ないステップ で行うため、分析麻痺に陥らず効率的に開発できます。

## 全体像の把握

ユースケースを実装に変換する **フレームワーク** として、ソフトウェア開発の全体像を把握しやすくなります。

# アジャイルとの関係性

アジャイル開発は、プロジェクトを **小さなサイクル** に分けて **フィードバック** を受けながら進める方法です。
これにより、利用者の **要求** や 環境の **変化** に柔軟に対応できます。

ICONIXプロセスは **ユースケース駆動** のオブジェクト指向開発手法で、 **要件分析** 、 **予備設計** 、 **詳細設計** 、 **実装** の4つのフェーズで進めます。
以下の点で、アジャイル開発と関連しています。

- ウォーターフォール開発ほど硬直的ではなく、前フェーズへの手戻りを許容している
    - アジャイル開発的 に進めることができる
- 要件分析 フェーズをしっかり行う
    - アジャイル開発では要件分析が省略されたり不十分になりがちなところを、ICONIXプロセスでは回避できる
- 「 **ロバストネス分析** 」という **予備設計** フェーズがあり、ユースケースとオブジェクトの間のギャップを埋めることができる
    - アジャイル開発では、このような **中間的なモデリング** が欠けている場合がある
- 異なるプロジェクト管理やアジャイル方法論に従う様々なプロジェクトで、大幅なテーラリングなしに使用できる
    - 書籍「 **Agile Development with ICONIX Process** 」では、アジャイルプロジェクトでのICONIXプロセスの使い方が説明されている

# あとがき

ICONIXプロセスの特長や利点、そしてアジャイル開発との関係性についてご理解いただけたでしょうか。
ソフトウェア開発において、適切な手法を選ぶことはプロジェクトの成功に直結します。

ICONIXプロセスは、ウォーターフォールとアジャイルの良いところを取り入れたハイブリッドなアプローチで、多くの利点を提供します。
特に「 **ロバストネス分析** 」による「 **予備設計フェーズ** 」は、要件と実装を簡単な図で紐付けることで、プロジェクトの透明性と柔軟性を高める重要な役割を果たします。

これにより、要件と実装の乖離を防ぎ、開発の進行をスムーズに保つことができます。
Terraform リファクタしてみた〜そしてAtlantisへ〜

弊社（Voicy）もサービス開始から7年経ち、レガシーな部分も散見されます。私はSREとして今年の6月に入社したばかりなので、７年間の歴史の10分の１もいないわけですが・・・
入社した当初に動いていたプロジェクトとして、Terraformのリファクタがありました。
それについて本日は書いていきたいと思います。

## レガシーな部分
VoicyのTerraformの何がレガシーか？

### バージョン
まず、Terraformのバージョンが古いです。
本日現在 1.6.6 が最新で、1.7.0 の rc1 も出ています。
リファクタし始めた当初、バージョンは 0.12.x でした。
弊社はAWSを使用しているので、aws モジュールとの絡みもあるのですが、新しくしなくても動いているというのがいけないんでしょうね。

### 構造的問題
次に、構造の問題です。

```
.
└── dev_stage_prod
    ├── main.tf
    ├── main.tf_dev
    ├── main.tf_stage
    ├── main.tf_prod
    ├── output.tf
    ├── provider.tf
    ├── variable.tf
    └── vpc.tf
```

terraform は plan や apply を実行する際に、main.tf を参照して実行するわけですが、環境がいくつかある場合、やり方がいくつかあります。terraform 的にはワークスペースを使用するというが、一応推奨されていた方法ではないかと思います。

ですが、この環境、main.tf が環境ごとに用意されており、実行する際に、編集・コピペして使用する感じになっていました。

この手法の、メリット・デメリット挙げてみます。

```
[メリット]
- 環境ごとに main.tf をコピー・編集するだけで、環境ごとに異なる構成をプロビジョニングできる
- 構成がシンプル

[デメリット]
- 環境ごとに main.tf をコピー・編集する必要があり、手間がかかる
- 環境ごとに main.tf があるので、誤った環境のものを適用する可能性がある
```

## リファクタの方法
リファクタの方法も色々ありますし、さまざまな検討をしました。

### どんな方法があるか？
例えばですが・・・

```
- ディレクトリ構造の利用
- ワークスペースの使用
- 変数ファイルの活用 
- モジュールの使用
- 環境変数の使用
- 分岐戦略の採用
```

### どの方法を採用したか？
メリデメを検討した結果、Voicyで採用されたのは、ディレクトリで環境分けをし、shared モジュールを使用するが、シムリンクは採用しないという方針となりました。

```
.
├── dev
│   ├── main.tf
│   ├── provider.tf
│   └── variable.tf
├── prod
│   ├── main.tf
│   ├── provider.tf
│   └── variable.tf
├── shared
│   ├── iam.tf
│   ├── network.tf
│   ├── output.tf
│   └── variable.tf
└── stage
    ├── main.tf
    ├── provider.tf
    └── variable.tf
```

### この方法のメリデメ
それでは、この方法のメリット・デメリットも確認していきましょう。

```
- ディレクトリ分けすることで、環境分けが明確
- shared モジュール採用により、共通部分は共通部分で重複を排除できる
- コピペで失敗することがない
```

## 後はリファクタするのみ
元々の構造から、新しい構造への変更は、なかなか大変な作業です。
shared モジュールへの変更もあり、作業量的にもかなりなものでした。
ですが、必要な部分のリファクタが終わり、次はバージョンアップですね。。。

## バージョンアップはなぜ行う？
リファクタするだけであれば、バージョンアップはサポート切れとかを考えなければ必要ない作業です。
いや、やった方がいいのは確かです。
では、なぜやるか？

### Terraform も CI/CD したいよね
今までローカル実行を行なってきた Terraform なのですが、CI/CD やっていきたいよねという話になりました。で、何を使うかの検討を行ったのですが、最終的に Atlantis を使用することになりました。

### Atlantis とはなんぞや？
Atlantisとは、Terraformを以下のように進化させるツールです。
https://www.runatlantis.io/

```
- プルリクエスト駆動のワークフロー：PRで自動実行できる
- 自動化されたプランと適用：plan/apply の自動実行
- チームのコラボレーションと透明性：チーム内でレビューできる
- セキュリティとアクセス制御：実行承認
- 状態管理の簡素化：ローカルで状態管理する必要がない
- 柔軟性と拡張性：様々なカスタマイズが可能
- 履歴の追跡と監査：証跡が取れる
```

いや、便利よね。

### バージョンアップ関係ある？
Atlantis を github 上で実行すると、SecretManagerから読み込みしているセキュリティ情報が、github 上に残ってしまうのです（0.12.xとかだと・・・）。バージョンアップ必須です。

```
- 0.12.x ダメダメ
- 0.13.x ダメダメ
- 0.14.x sensitive に対応
```

ということで、とりあえず 0.14.x にあげることになりました。

### 0.14.x でもダメ
0.14.x は sensitive に対応はしているのですが、tfstate には残ってしまうという問題が出てしまいました。ということで、もう一段階あげて、0.15.x　へとバージョンアップを行い、一応の問題解決が見られました。

## Atlantis 入れてどう？
Atlantis入れてどうなった？という部分です。

### 良い部分
よかった点をあげていきたいと思います。

```
- github 上で実行することで、証跡が残る
- 誰が実行したかわかる
- 実行前レビューをするようになる
```

### 微妙な部分
若干微妙な部分についても

```
- 権限周りは絞りきれない
- ローカルから実行しようと思えばできる
- 自動 apply はこわい
```

## 今後
今後ですが、引き続きのバージョンアップや、自動 apply などやっていきたいと思っています。

## We're hiring
絶賛、エンジニア（だけではなく）募集してます。
カジュアル面談もやっていますので、お待ちしています。

https://recruit.voicy.jp/
モデリングの基礎知識（ロバストネス図）

# ロバストネス図とは

ロバストネス図は、「 **システムの動きを絵として表したもの** 」です。

UMLで定義されている13種類のダイアグラムには入っていませんが、UMLのコミュニケーション図やコラボレーション図を簡略化した形で簡単に書くことができます。

ロバストネス図では、システムの要素を以下の3種類に分類します。

- **バウンダリ** ：ユーザーや外部システムとのやりとりを行う
- **エンティティ** ：データの保存や管理を行う
- **コントロール** ：ユーザーの要求を処理・制御する

ロバストネス図では、これらの要素をそれぞれ異なる形で表現します。

![ロバストネス図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91620/1fb89e14-4810-3aff-a90c-5e8c5b9a8044.png)

ロバストネス図を書くことで、システムが

- **どのような機能** を持っていて
- **どのようなデータ** を扱っているか

と言うことがわかりやすくなります。

よりわかりやすく説明すると、ロバストネス図は
「お話の **登場人物** や **道具** や **場所** を絵にしたもの」
と言えます。

- 主人公 、 仲間 、 敵 ＝ 「 **バウンダリ** 」
- 宝物 、 武器 、 魔法 ＝ 「 **エンティティ** 」
- 冒険 、 戦闘 、 謎解き = 「 **コントロール** 」

ロバストネス図では、これらの **登場人物** や **道具** や **場所** を それぞれ異なる形 で描いて、話の内容を分かりやすくします。

# 必要性

ロバストネス図は、「 **システムの要件を分析する** 」時に役立ちます。
ロバストネス図を書くことで、システムが **どのような機能** を持っていて、 **どのようなデータ** を扱っているかが明確になります。

また、ロバストネス図はシステムの **設計** や **実装** にも繋がります。
ロバストネス図は、システム開発の「 **全体像を把握する** 」ために必要な図と言えます。

# メリット

ロバストネス図のメリットとして、以下の点があげられます。

## シンプルでわかりやすい図

- UMLの **コミュニケーション図** や **コラボレーション図** を、簡略化した形で表現できる
- システムの「 **構造** 」や「 **動作** 」を簡潔に表現できる

## 要件と設計の間のギャップを埋める

- 要件を定義する時に書いた **ユースケース** と、設計する時に書く **クラス図** や **相互作用図** との 対応関係 が 明確 になる
- 要件と設計の「 **一貫性** 」や「 **正確性** 」を高めることができる

## チーム内でのコミュニケーションを促進する

- 異なる視点や知識レベルの人たちにも理解しやすい
- システムの要件や設計について、共通の言語で話し合える

## 要件の曖昧さを除去する

- **ユースケース記述** の 曖昧さを削減し、設計 、テスト、見積りを容易にする

# 書き方の原則

ロバストネス図の書き方の原則として、以下の点があげられます。

- **ユースケース記述** や **ドメインモデル図** を参考にして、「 **システムの振る舞い** 」を表現する
- **アクター** 、 **境界オブジェクト** 、 **制御オブジェクト** 、 **エンティティオブジェクト** の、 4種類 の要素を使う
- 「 **アクターの視点** 」から記述する段階と、「 **システムの視点** 」から記述する段階の、大きく 2段階 に分けられる
- 「 **要件の曖昧さ** 」を除去するために描く
    - ロバストネス図を描きながら「 **ユースケース記述** 」や「 **ドメインモデル図** 」に不足や矛盾 がないかをチェックする
- 「 **システムの設計や実装に繋がる** 」ために描く
    - ロバストネス図は一時的なモデルであり、最終的な成果物ではないことを意識する
- 下流工程からのフィードバックを繰り返す
    - 下流工程からのフィードバックを繰り返すことで、要件の曖昧さを除去し、確実性のあるものにしていく

# あとがき

ロバストネス図は、システムの動作や構造を視覚的に理解できるようにするための強力なツールです。
システムの要件分析から設計、実装に至るまでの一連の作業を支援し、チーム内外でのコミュニケーションを円滑にする役割を果たします。

ロバストネス図は一時的なモデルであることを忘れず、常に要件や設計の変化に対応できる柔軟性を持たせることが重要です。
この図を活用することで、システム開発の全体像を把握し、プロジェクトの進行をスムーズにすることができるようになると思います。
モデリングの基礎知識（ユースケース図）

# ユースケース図とは

ユースケース図は、ユーザーの **要求** に対するシステムの **振る舞い** を表現する図である。

ユーザー視点でシステムの機能を把握するのに役立つ。
ユースケース図は、「 **UML（統一モデリング言語）** 」の一つである。

ユースケース図は、システムを **利用する人の目線** で、具体的にシステムを **利用する場面** を想定して、 **視覚的に図示する** ことを目的としている。

ユースケース図には、以下の要素がある。

|要素|説明|
|---|---|
|**アクター**|システムを利用する人や外部システムなどの役割|
|**ユースケース**|アクターがシステムに対して行う操作やシステムが提供する機能|
|**システム境界**|システムの範囲を示す枠|
|**関連**|アクターとユースケース、ユースケース同士の関係を示す線|

ユースケース図は **シンプル** な図であり、一目で **システムの機能** や **システム範囲（できること・できないこと）** を理解することができる。

# 入力ソース情報

ユースケース図を作成する際には、システムの要件や仕様を明確にするための **入力ソース情報** が必要である。

入力ソース情報としては、以下のようなものがある。

|入力ソース|説明|
|---|---|
|**ユーザーのニーズや要望**|システムがどのような目的や価値を提供するかを把握する|
|**ユースケースシナリオ**|システムとユーザーの相互作用の具体的な流れを記述する|
|**アクター**|システムにアクセスする主体や役割を特定する|
|**ユースケース**|システムが提供する機能やサービスを定義する|

ユースケース図は、 **ER図** や **ロバストネス図** などの、 **他の設計図** の入力ソース情報としても活用できる。

# 必要性

ユースケース図の必要性として、以下の点があげられる。

- システムとユーザーの **相互作用** や **関係** を要約するための図で、システムの **機能** や **範囲** を明確にすることができる
- **ユーザー目線** でシステムを利用する場面を想定して、視覚的に図示することで、 **顧客とのコミュニケーション** を円滑にすることができる
- システムの **内部構造** や **処理の流れ** を詳細に記述する「 **ユースケース記述** 」と組み合わせることで、 **理解しやすく効率的** な仕様書を作成することができる

# 書き方の原則

ユースケース図の書き方の原則として、以下の点があげられる。

- **システムで何ができるか** を、 **ユーザー目線**で表現する図 である
- **アクター** 、 **ユースケース** 、 **システム境界** 、 **関連** 、 **包含** 、 **拡張** の6種類の要素を使う
- **アクターを洗い出す** 段階と、 **アクター別のユースケースを洗い出す** 段階の、大きく2段階に分けられる
- **要件定義** フェーズで使用されることが多く、システムの **機能** や **範囲** を明確にするために描く
- ユーザーのアクションに対してシステムが実行する **内部処理の流れ** を、「 **ユースケース記述** 」として作成することができる

# ユースケース記述とは

ユースケース記述とは、ユースケース図で表現されたシステムとユーザーの **相互作用** を、 **テキストで詳細に記述したもの** である。

ユースケース記述には、以下に示す項目が含まれる。

|項目|説明|
|---|---|
|**ユースケース名**|ユースケース図でラベル付けされたユースケースの名称|
|**アクター**|ユースケース図で外部からシステムにアクセスする主体の名称|
|**前提条件**|ユースケースが開始される前に満たされているべき条件|
|**基本フロー**|ユーザーが目的を達成するための正常な操作や応答の流れ|
|**代替フロー**|基本フローから分岐する異常や例外の操作や応答の流れ|
|**後置条件**|ユースケースが終了した後に満たされているべき条件|

ユースケース記述は、システムの **要件や仕様を明確にする** だけでなく、 **テストケース** や **設計書** などの他のドキュメントの作成にも活用できる。

# ユースケース記述の特徴

ユースケース記述の特徴として、以下の点があげられる。

- ユースケース記述は、 **ユーザー目線** でシステムの **利用シナリオ** を記述するため、ユーザーの **ニーズ** や **要望** を反映しやすい
-  システムの **内部構造** や処理の **詳細を記述しない** ため、システムの **変更** に **柔軟** に対応できる
- **テキスト** で書かれるため、読みやすく理解しやすい

# 実践的な書き方

- ユースケースは「 **A** を **B** する」と言う形式で記述する
    - **〜する** と言う記述にする（体言止め、名詞のみはNG）
    - **A** が **静的モデル** 、 **B** が **動的モデル** になる
- ユースケースは **アクター目線** で **何を実現するのか** を記述する
    - **エンジニア目線** で考えると、正確なユースケースを導き出せなくなる
    - 実装に寄ってしまわないように意識しながら描く
IBM Cloud で月額課金のキャンセル日が来月1日の15:00しか選べない

IBM Cloud の月次を締める日を Anniversary Billing Date(ALB)と呼びます。
クレジットカード払いの場合は、クレジットカードの登録が完了した日が基本的に ALB です(別日も指定可能です)。
IBM と契約して請求書払いの場合は、毎月 1 日です。
下記では話を単純にするために ALB が月初の 1 日として話をします。

:::note warn
夏時間中は Central Daylight Time:CDT (GMT-5)で管理されているようです。
キャンセル日は日本時間で月末の翌日の 14:00 と表示されるという情報がありました。
:::

IBM Cloud の Classic 環境で月額課金のサーバーをキャンセルしようとした時の話です。
キャンセル日が、来月 1 日の 15:00 しか選べません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/73d048be-5c1a-ee23-796d-4b78a9723edf.png)

IBM Cloud Classic 環境の月額課金サービスは、月初/ALBで請求が確定する前払いだったはず...ということは今月キャンセルしても、来月も課金されるの? と聞かれました。

安心してください。そんなことはありません。

# IBM Cloud の月次の締め切りは、GMT-6 のタイム・ゾーンで処理

IBM Cloud はグローバルのサービスです。月次処理を行うのに、どこかのタイムゾーンで処理する必要があります。
IBM Cloud の月次の締め切りは、GMT-6 のタイム・ゾーンで処理しています。
日本時間 JST は UTC(GMT+9) です。6+9=15 で IBM Cloud の月末は日本時間の翌日の 15:00 になります。

試しにタイムゾーンを UTC-6 にセットしてみましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/d6de10ba-8f83-e154-41ce-4ff622922289.png)

1 日の 0:00 として表示されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184930/a4574752-2f4b-306d-cf2a-d0af572753fe.png)

# IBM Cloud Classic 環境の月額課金サービスは、月初/ALBで請求が確定する前払い=月末まで使用権がある

先ほどの書いた通り、IBM Cloud Classic 環境の月額課金サービスは、月初/ALBで請求が確定する前払いです。
そのため、月中でキャンセルしても月末までの料金は請求されます。
月末の分まで請求されるという事は、月末まで使用する権利があります。
月中のキャンセルは月末を指定したキャンセルの予約として処理されます。
そして、表示される通り日本時間で1日の15:00までご利用いただけます。

# 事前キャンセルは月締めの 24 時間前まで

月中のキャンセルは、月末ギリギリでいいのかというと、そうではありません。
GMT-6 のタイム・ゾーン換算で月末の24時間前までに行ってください。

サービス記述書にも下記の記載がございます。

* https://www.ibm.com/support/customer/csol/terms/?id=i126-6605&lc=ja

> **5.2.1 サービスの解約およびダウングレード**
サービス期間が確約されていない、特定のインフラストラクチャー「クラウド・サービス」をダウングレードするか、解約するには、お客様は、**サービス期間の終了(GMT-6 のタイム・ゾーン)の少なくとも24時間前まで**に解約しなければなりません。解約された「クラウド・サービス」は、サービス期間の終了まで引き続き利用することが可能で、未使用の部分に対する払い戻しまたはクレジットは行われません。期日までに通知が行われなかった場合は、サービス期間が自動的に更新されることになります。お客様は、サービスの解約またはダウングレードの要求が確実に実行されたことを確認する責任を負います。

# 即時キャンセルはできないの?

ホスト名を再利用したい、VLAN の IP を開放したい、アカウントを閉鎖したいなど、月末を待たずに即時キャンセルをご希望の場合があるかもしれません。
以前のポータルでは、月末のキャンセル予約と即時キャンセルから選択できましたが、現在は月末キャンセル予約しか選べません。
即時キャンセルをご希望の場合は、いったん月末キャンセルを実行いただき、Case でリクエストしてください。
モデリングの基礎知識（UML）

# UMLとは

**UML** （統一モデリング言語）とは、システムやプロセスの **構造** や **動き** を **図** で見せるための **言語** である。

ソフトウェア開発だけでなく、他の分野でも使われる。

UMLにはいろいろな種類の図があるが、共通の **記号** や **ルール** がある。
UMLを使うと、システムの **設計** や **問題点** をわかりやすく伝えることができる。

# 詳細

UMLの種類は、大きく分けてシステムの **構造** を表す **構造図** と、 **動作** や **変化** を表す **振る舞い図** の **2種類** に分類される。

**構造図** には、

- クラス図
- オブジェクト図
- コンポーネント図
- 配置図
- パッケージ図

などがある。

**振る舞い図** には、

- ユースケース図
- シーケンス図
- コラボレーション図
- アクティビティ図
- ステートマシン図

などがある。

それぞれの図は、システムの **異なる側面** を表現するために使われる。

# メリット

UMLのメリットとして、以下の点がある。

- ソフトウェアシステムの **構造** や **動作** を **視覚的** に表現できるため、 **理解しやすく、コミュニケーションを効率化** できる
- 様々な種類の図が用意されているため、システムの **異なる側面** を捉えることができる
- 図の **記法** や **意味論** が **統一** されているため、 **標準化** されたドキュメントを作成できる
- **反復型開発プロセス** に適しており、 **リスク** や **優先度** に応じて開発を進めることができる

# 必要性

UMLは、ソフトウェアシステムの **構造** や **動作** を **視覚的** に表現するための、**共通の言語** である。
UMLを使うメリットとして、以下の点がある。

- システムの **要件** や **設計** を明確にすることができる
- システムの **可視化** や **統一** を実現させることができる
- システムの **理解** や **コミュニケーション** を **効率化** することができる
- システムの **再利用** や **保守** を容易にすることができる
- システムの **品質** や **生産性** を向上させることができる

UMLは、システム開発において **重要な役割を果たしている** と言える。
アドカレ26記事目のバッジがあるのか調査したらQiitaのバッジの仕組みを見つけた

~~検証記事です。何もなければ消します。~~

何もなかったんですが、この機会にバッジの種類について知る事ができたので備忘録で残します。
Qiitaのバッジ一覧のページにアクセスするとどんなものがあるか確認できるようです。
ログイン後に以下にアクセスしてみてください。
https://qiita.com/badges

または、いつも（執筆時点）右上にあるアカウントアイコンより、マイページの下に「獲得したバッジ」という項目がありますのでそちらから同じページに飛べます。

参考：筆者アカウントでの見え方

![スクリーンショット 2023-12-25 15.31.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/122800/aeb45cbd-b7d1-c6cd-da55-2a1b043bf0f0.png)

予め全ての種類のバッジが見れる状態になっているのか、までは判断できませんが、今後の目安にはなりそうです。

https://help.qiita.com/ja/articles/qiita-badge

上にある公式情報からだと、コントリと連続投稿については予め条件を満たしてそうなアカウントが多そうなのでレア度は低いですかね。

また、アドカレはイベントバッジでしょうか。
私の場合は2019年と2022年〜で参加したので2020-2021年分がないですね。
参加した人だけがもらえるシークレットバッジのようです。今後のQiitaイベントは積極的に参加してもいいかもしれません。
juce_vst3_helper 失敗でビルドできない場合の対処法

## はじめに

ググっても同様の記録が見当たらなかったので、投稿します。
MacでJUCEを使ってVSTプラグインを開発中に以下の現象にハマった件の記録です。

- VSTのビルドに失敗する
  - CLIでビルドすると途中で Segmentation Fault している
  - これを見つけるために[cmakeを導入した](https://qiita.com/moppii/items/9eb4f63d571ace891a72)
- AU版、Standalone版はビルドできる
- 特に変なプログラムを書いたつもりはない（なかった）

## 結論

- BAD ACCESSが原因（私の場合）
- LLDB で juce_vst3_helper を起動したら原因がわかった
  - ビルドプロセスを手動でデバッグ実行したらヒントが得られる

## ビルドエラーの詳細

私が遭遇したビルドエラーは以下の内容でした。
`XXX`はmacのユーザ名、`YYY`はプラグイン名です。またプラグインのバージョン番号はとりあえず`1.0.0`としてありますので適宜読み替えてください。

### Xcodeのエラーメッセージ

`Command PhaseScriptExecution failed with a nonzero exit code`

### Xcodeの詳細ログ

```
/Users/XXX/Library/Developer/Xcode/DerivedData/XXX/Build/Intermediates.noindex/YYY.build/Debug/YYY - VST3.build/Script-5EE3CAAC0943FC46AD27AAAB.sh: line 6: 75859 Segmentation fault: 11  "$CONFIGURATION_BUILD_DIR/juce_vst3_helper" -create -version "1.0.0" -path "$CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME" -output "$CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Resources/moduleinfo.json"
Command PhaseScriptExecution failed with a nonzero exit code
```

### Cmake(+ninja)のログ

```
（色々書かれている）
-- Replacing invalid signature with ad-hoc signature
/Users/XXX/.../YYY.vst3: replacing existing signature
/bin/sh: line 1: 76137 Segmentation fault: 11  /Users/XXX/.../juce_vst3_helper -create -version 1.0.0 -path /Users/XXX/.../YYY.vst3 -output /Users/XXX/.../YYY.vst3/Contents/Resources/moduleinfo.json
ninja: build stopped: subcommand failed.
```

## 原因調査

lldb で juce_vst3_helper を起動し、rコマンドでデバッグ起動しました。
（make または ninja を走らせたのと同じディレクトリで、ビルド失敗直後にCLI上で実行。）

```
> lldb /Users/XXX/…/juce_vst3_helper
(lldb) r -create -version 1.0.0 -path /Users/XXX/.../YYY.vst3 -output /Users/XXX/.../YYY.vst3/Contents/Resources/moduleinfo.json
```

これを実行すると、segmentation fault したところのスタックトレースがコンソールに出てきました。
なるほどBAD ACCESSが有ったので、ソースコードを修正し再ビルドしたところ、vst版もビルドできるようになりました。
ビルドされたvstプラグインの動作も、特に問題なし。

## 最後に

- LLDBは使いにくいけど、便利。
  - 自作プログラム以外で初めて使った。こうやれば使えるのか。。。
- juce_vst3_helper はプラグインの動作確認をしているっぽい。
  - Xcode　のログを見ると`DBG()` の出力が出ていたりする
  - 調べてないけど、調べれば色々出てきそう
ツイートを編集

投稿機能アプリの実装の復習を備忘録としてあげてます！

### 目的
- CRUD(UPDATE)
- HTTPメソッドのPATCH
- edit アクションの処理の理解
- updateアクションの処理の理解

### ツイート編集機能の実装
　1. ツイート編集画面のルーティング設定
　2. 編集ボタン編集ボタンをビューに追加
　3. editアクションをコントローラーに定義
　4. 編集画面のビューファイルを作成
　5. ツイートの更新を行うためのルーティングを設定
　6. updateアクションをコントローラーに定義

「editアクションで編集ページを「表示」→「updateアクションでデータの更新」

### edit アクションのルーティング設定
config/routes.rb
```ruby
〜略〜
resource :tweets, only: [:edit]
〜略〜
```

ターミナルで
rails routesコマンドで確認
ターミナル
` edit_tweet GET    /tweets/:id/edit(.:format)                                                                        tweets#edit `

### 編集ボタンを投稿一覧に追加
` link_to `メソッドを使用する
遷移先がツイートごとに異なるため、
編集画面へ遷移するパスには、 __*tweetのid*__ をパラメータ設定する

app/views/tweets/index.html.erb
```ruby
~略~
<%= link_to '編集', edit_tweet_path(tweet.id) %>
~略~
```

### editアクションをコントローラーに定義
編集→更新は __*すでに存在しているレコードを選択して中身を書き換える*__　
編集したいレコードを　 `@tweet`　に代入し、ビューに受け渡すことで編集画面で利用できる

app/controllers/tweets_controller.rb
```ruby
~略~
def edit
    @tweet = Tweet.find(params[:id])
end
~略~
```

### 編集画面をビューに作成
情報を入力するために必要
入力情報の送信先は`/tweets/編集するツイートのid`
編集の際は HTTPメソッドの`PATCH`を使用

HTTPメソッド
GET: サーバーからブラウザに情報を返す
POST: ブラウザからサーバーに情報を送信し、サーバーに情報を保存
DELETE: ブラウザからサーバーに情報を送信し、サーバーの情報を削除する
PATCH: ブラウザからサーバーに情報を送信し、サーバー内に情報を置き換える

`app/views/tweets` ディレクトリの中に`edit.html.erb`というビューファイルを作成

app/views/tweets/edit.html.erb
```ruby
<div class="contents row">
  <div class="container">
    <h3>編集する</h3>
    <%= form_with(model: @tweet, local: true) do |form| %>
      <%= form.text_field :name, placeholder: "Nickname" %>
      <%= form.text_field :image, placeholder: "Image Url" %>
      <%= form.text_area :text, placeholder: "text", rows: "10" %>
      <%= form.submit "SEND" %>
    <% end %>
  </div>
</div>
```
## ツイート更新処理の実装
### updatアクションのルーティング設定

config/routes.rb
```ruby
resources :tweets, only: [:index, :new, :create, :destroy, :edit, :update]
```
ターミナル
 `tweet PATCH  /tweets/:id(.:format) tweets#update`

### updateアクションをコントローラーに定義
app/controllers/tweets_controller.rb

```ruby
  def update
    tweet = Tweet.find(params[:id])
    tweet.update(tweet_params)
    redidect_to root_path
  end
```
iexのHELPを眺めてみる

現在Interactive Elixirへようこそのためのドキュメントを見ています。
Elixirのシェルをより活用する為に、多くのヘルパーを提供するモジュールIEx.Helpers

このメッセージは、通常はヘルパーh（）を呼び出すことによってトリガーされました。
h / 0（0個の引数を必要とするため）

h / 1関数を使ってElixirモジュールのドキュメントを呼び出すことができます。
または機能：

iex> h（Enum）
iex> h（Enum.map）
iex> h（Enum.reverse/1）

i / 1関数を使って、あなたが持っている任意の値を内省することもできます。
シェル：

iex> i（"hello"）

利用可能な他の多くのヘルパーがあります、ここにいくつかの例があります：

•b/1  - 特定のモジュールのコールバック情報とドキュメントを印刷します。
•c/1  - ファイルをコンパイルする
•c/2 コンパイルし、指定されたパスにバイトコードを書き込みます。
•cd/1  - 現在のディレクトリを変更します
•clear/0 クリアする
•exports/1  - モジュール内のすべてのエクスポート（関数+マクロ）を表示します
•flush/0  - シェルに送信されたすべてのメッセージをフラッシュします
•h/0  - このヘルプメッセージを表示します
•h/1  - 指定されたモジュール、機能、またはマクロのヘルプを表示します。
•i/0  - 最後の値に関する情報を表示します
•i/1  - 指定された用語に関する情報を印刷します。
•ls/0：現在のディレクトリの内容を一覧表示します。
•ls/1：指定されたディレクトリの内容を一覧表示します。
•open/1  - 指定されたモジュールまたは関数のソースを
あなたの編集者
•pid/1  - 文字列からPIDを作成します
•pid/3  - 渡された3つの整数引数を使用してPIDを作成します
•port/1  - 文字列からポートを作成します
•port/2  - 渡された2つの負でない整数でポートを作成します
•ref/1  - 文字列から参照を作成します
•ref/4  -  4つの整数引数を持つ参照を作成します
過ぎた
•pwd/0  - 現在の作業ディレクトリを表示します。
•r/1  - 与えられたモジュールのソースファイルを再コンパイルします。
•再コンパイル/0  - 現在のプロジェクトを再コンパイルします。
•runtime_info/0  - ランタイム情報（バージョン、メモリ使用量、統計）を出力します。
•v/0  - 履歴から最後の値を取得します
•v/1  - 履歴からn番目の値を再試行します。

これらすべての機能のヘルプは、コマンドラインから直接参照できます。
h/1ヘルパー自体を使う。試してください：

iex> h（v/0）

利用可能なすべてのIExヘルパーを一覧表示する。これは事実上すべてのエクスポート（関数）です。
IEx.Helpersモジュールのマクロ）

iex>エクスポート（IEx.Helpers）

このモジュールにはデバッグ目的のヘルパーも含まれています。IEx.breakを参照してください。 / 4の場合
詳しくは。

IEx全体の詳細については、h（IEx）と入力してください。
httpsポート使ってgithubにアクセスする方法

# 概要

環境によっては 22 番ポートへのアクセスが禁止されている場合があります。
その場合、デフォルトだと github と秘密鍵/公開鍵を使ったアクセスができなくなるのですが、ID/Password でのアクセスも面倒です。
そんなときは、https を使って秘密鍵/公開鍵を使ったアクセスができると便利なので紹介します。

# 前提

- github に公開鍵をすでに登録してあり、繋がっている状態である。
- すでに ssh でつながっているプロジェクトがある。

# 方法

    
1. https でつながるように設定:
    1. そもそも ssh でつながるかのチェック:
       ```:このように出ればOK
       $ ssh -T -p 443 git@ssh.github.com
       Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.
       ```
    1. github.com へのアクセスはすべて ssh.github.com に繋がるように:
         ```:vi ~/.ssh/config
         Host github.com
             Hostname ssh.github.com
             Port 443
             User git
         ```
    1. つながるようになったかチェック:
       ```:このように出ればOK
       $ ssh -T git@github.com
       Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.
       ```
  
# 参考

- [HTTPS ポートを介して SSH を使用する - GitHub Docs](https://docs.github.com/ja/authentication/troubleshooting-ssh/using-ssh-over-the-https-port)
Phoenixframework 画像Uploads & 画像表示 & 画像ダウンロード

Phoenix 1.7 になって、色々と書き方が変わり、調べるのに時間かかったので、備忘録


```heex
    <%= for {_ref, err} <- @uploads.avatar.errors do %>
      <p class="alert"><%= Phoenix.Naming.humanize(err) %></p>
    <% end %>

    <%= for entry <- @uploads.avatar.entries do %>
      <%= entry.client_name %> - <%= entry.progress %>%
      <.live_img_preview entry={entry} width={75} />
    <% end %>

    <form phx-submit="avatar_save" phx-change="validate">
      <.live_file_input upload={@uploads.avatar} />
      <button type="submit">Upload</button>
    </form>
```

```elixir
def mount(_params, _session, socket) do

    socket =
      socket
      |> assign(:uploaded_files, [])
      |> allow_upload(:avatar, accept: ~w(.png .jpeg .jpg), max_entries: 1)

    {:ok, socket}
  end
```

```elixir
  @impl true
  def handle_event("avatar_save", params, socket) do

    uploaded_files =
      consume_uploaded_entries(socket, :avatar, fn %{path: path}, _entry ->
        dest = Path.join([:code.priv_dir(:pansy), "static", "uploads", Path.basename(path)])
        File.cp!(path, dest)
        {:ok, ~p"/uploads/#{Path.basename(dest)}"}
      end)

    {:noreply, update(socket, :uploaded_files, &(&1 ++ uploaded_files))}
  end
```


```elixir
  def handle_event("validate", _, socket) do
    # ここで任意の検証を行うことができます
    {:noreply, socket}
  end
```

別の書き方
```elixir
    uploaded_files =
      consume_uploaded_entries(socket, :avatar, fn %{path: path}, _entry ->
        dest = Path.join("priv/static/uploads", Path.basename(path))
        File.cp!(path, dest)
        {:ok, ~p"/uploads/#{Path.basename(dest)}"}
        Phoenix.VerifiedRoutes.static_path(socket.endpoint, "/uploads/#{Path.basename(dest)}")
```
[Mac] MySQLの初期化でセキュリティレベルをMEDIUMにしたらハマった

## 環境
- MacOS
- MySQL v8.0.32

## 前提
- homebrewをインストール済みであること

## MySQLインストール
```terminal
brew install mysql
```

```terminal
# MySQL初期化
mysql_secure_installation
```

```terminal
Securing the MySQL server deployment.

Connecting to MySQL using a blank password.

VALIDATE PASSWORD COMPONENT can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD component?
                                            #  VALIDATE PASSWORD プラグイン の利用確認
Press y|Y for Yes, any other key for No: y　←　「y」を押下

There are three levels of password validation policy:

LOW    Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters and dictionary file

# セキュリティレベルの設定。ここで 1 を押下してしまった
Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG:
```

上記手順により、MySQLのパスワードを8文字以上、数字、大/小文字混合、および特殊文字に設定しないと行けなくなった。


## ハマった

セキュリティレベルの次に進むとrootパスワードの設定が求められ、入力条件を満たさないとエラーで弾かれてしまう。（ただローカルで開発したいだけなのに）

```
Please set the password for root here.
```

:::note warn
MySQLを再インストールし、`mysql_secure_installation`(初期化)を再実行しても、一度設定したセキュリティレベルを再設定することはできなかった。
:::

## 解決策

### MySQLのテーブル設定からセキュリティレベルを変更する

以下手順
- **MySQLを立ち上げ、ログインする**

```terminal
mysql.server start
mysql -u root
```

- **パスワード関連のテーブルを確認する**

```sql
SHOW VARIABLES LIKE 'validate_password%';
```

```sql
+--------------------------------------+--------+
| Variable_name                        | Value  |
+--------------------------------------+--------+
| validate_password.check_user_name    | ON     |
| validate_password.dictionary_file    |        |
| validate_password.length             | 8      |
| validate_password.mixed_case_count   | 1      |
| validate_password.number_count       | 1      |
| validate_password.policy             | MEDIUM |
| validate_password.special_char_count | 1      |
+--------------------------------------+--------+
7 rows in set (0.01 sec)
```

- **セキュリティレベルを緩くする**

```sql
set global validate_password.policy=LOW;
set global validate_password.check_user_name=OFF;
set global validate_password.length=6;
commit;
```

`quit`で抜け、再度`mysql_secure_installation`を実行すると、セキュリティレベルが緩くなっているので適当に6文字以上のパスワードを入力すると次に進めるようになる。

## 終わりに

- ローカルで開発したいだけならセキュリティレベルはLOWにしておくのがオススメ
- Windowsだとインストーラー時点で設定するので無縁
スカジー

[インターネット老人会の魔法書 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/ancient-internet) の18日目の記事です。

# SCSI

「SCSI」は、「Small Computer System Interface」の略で、かつてコンピュータ本体にハードディスクやCD-ROM、イメージスキャナなど、様々な周辺機器の接続に使われていたインタフェースの規格である。
正式なものかどうかはわからないがみんな　**「スカジー」** と呼んでいた。

当時、このデバイスを通して多種多様な周辺機器を接続することができたため、一つのパソコンに対して多くの機能を追加することが可能であった。また、「デイジーチェーン」と呼ばれる接続形態で各機器を数珠繋ぎで接続することができるのも面白い方式だ。
さらに、後継規格として登場したUltra320では、転送速度は320MB/sにまで向上し、高速にデータ転送できるデバイスとして重宝された。

しかし、主流がシリアル方式へと移っていったことで、パラレル方式のSCSIは利用されなくなり、パソコン本体と外部周辺機器の接続はシリアル方式であるUSBなどが利用されるようになっている。

今SCSIを利用しているユーザがいるかどうかはわからないが、古いPCでSCSIのインターフェースを見ると **おっ** という気持ちにはなる。
ボール式マウス

[インターネット老人会の魔法書 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/ancient-internet) の17日目の記事です。

# 今は見かけなくなったボール式マウス

初期のマウスは光センサのついていなくボールで認識するタイプで、一般的には「ボール式マウス」と呼ばれていた。

底面に組み込まれたボールが動くことで、ボールに触れているローラがマウスの移動量・方向・速度を読み取り、それに応じて画面上のカーソルが動く。この直感的な操作感は、初めてコンピュータを使う人々にとっても理解しやすいものだった。
また光センサ式の最大の欠点の「キラキラした板の上だと反応が悪い」がボール式にはない。ボールが動く環境ならどこでも使えた。

最大の欠点として、マウス内部にホコリやゴミが侵入しやすい。ボールが動くことで発生する摩擦により、ボールや内部のセンサーが汚れてしまい、その結果、マウスの動きが悪くなることが多々あった。そのため、定期的な掃除が必要であり、専用のクリーナなんかも売っていた。また、ボールの分重量も重く、小型化も難しかった。