OmniAICreator/Qiita-1.07M huggingface dataset:
[Linux] AlmaLinux 9 をインストールする

# はじめに
Zabbixをインストールする用のAlmalinuxを作成します。前回構築した際は、手順書を作成しなかったので、自分への備忘録も兼ねて書きます。（Zabbixとは、オープンソースの統合監視ツールです。）

# 用意するもの
##  PC
どのようにマシンを運用するかによってスペックは変わります。今回はZabbixを運用するだけなので、要求されるスペックはそれほど高くありません。なので、余っている中古のノートPCを使用します。

| パーツ    | スペック                     |
|:----------|:----------------------------|
| CPU       | Core i5-8250U CPU @ 1.60GHz |
| Memory    | 8GB	                      |
| Storage   | SSD 256GB                   |

:::note
SSDは予めフォーマットしておくのを推奨します。
:::

## USBメモリ（フラッシュドライブ）
Almalinuxのブート用に使います。私は32GBのものを用意しました。

:::note warn
USBメモリに元々入っていたデータは全て消えるので注意してください。
:::


# Almalinuxをダウンロードする。
Almalinuxをダウンロードしてきます。

https://almalinux.org/ja/get-almalinux/

私は、前回使ったISOファイルがあったのでそれを使用します。バージョンは9.2でした。

# RufusでブータブルUSBメモリを作成する。
ダウンロードが終わったら、Rufusを使います。持っていない方はインストールしてください。

https://rufus.ie/ja/

起動すると、デバイスでUSBメモリを選択してください。ブートの種類では、「選択」を押して、先ほどダウンロードした、AlmalinuxのISOファイルを選択してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3522032/2955a3cb-a924-25d5-39ff-e11f49aa4cea.png)

:::note warn
USBメモリに元々入っていたデータは全て消えるので注意してください。
:::

「スタート」を押すと始まります。ポップアップが出てくると思いますが、「ISOイメージモードで書き込む」を選択してください。メニュー下部の緑のゲージが最後まで進行すると完了です。

# Almalinuxをインストールする。
作成したUSBメモリをマシンに接続して、PCを起動します。

:::note
USBでのブートを可能な状態にしておいてください。BIOSの設定はメーカーによって違うので、「メーカーの名前＋USBブート」で検索すれば設定方法が分かります。
:::

USBでPCがブートされます。真っ黒な画面に「Install Almalinux 9.2」と表示されたので選択し、インストールを開始します。

## 言語選択
まず初めに言語選択の画面が表示されます。好きな言語を選んでください。

## インストール概要
ここでは、
- インストール先の選択
- 時刻と日付の選択
- インストールするソフトウェアの選択
- rootユーザーのパスワードの登録
- user名とパスワードの登録
- ネットワークの設定

を行いました。

私は予めSSDをフォーマットしていたので、ここでフォーマットを行う必要はありませんでした。設定が完了すると、右下の「完了」ボタンを押して、インストールを開始します。

# インストール完了
インストールが完了すると、再起動します。再起動が終わると、Almalinuxのログイン画面が表示され、先ほど登録したユーザーのパスワードが求められます。これでインストールは完了です。

# 参考
https://www.server-world.info/query?os=AlmaLinux_9&p=download

# 次回
次回はAlmalinuxにZabbixをインストールしていきたいと思います！

https://qiita.com/TUDANUMA/items/3f7d5dd9afc8ffe52cbd
【Go】json.Decoderとjson.Encoder

# はじめに
GoでJSONを扱う場合、最初に出会うのが`json.Marshal`と`json.Unmarshal`だと思います。

しかし、これらはバッファにデータを格納したり、読み取ったりすることで実現されるのですが、`Decoder`と`Encoder`を使えば、リクエストボディのストリームから直接デコードしたり、エンコードしたりするため、一時的なバッファを作成する必要がなく、メモリ使用量を抑えることができます。

またコードも簡潔に書くことができるため可読性も上がります。

今回は、そんな`Decoder`と`Encoder`を使い方を確認します。

# MarshalとUnmarshalを使用する場合
```go
// POST /article
func PostArticleHandler(w http.ResponseWriter, req *http.Request){

	// Header.GETの返り値はstringなのでAtoiで整数に変換
	length, err := strconv.Atoi(req.Header.Get("Content-Length"))
	if err != nil {
		http.Error(w, "cannot get content length\n", http.StatusBadRequest)
		return
	}

	reqBodyBuffer := make([]byte, length)

	if _, err := req.Body.Read(reqBodyBuffer); !errors.Is(err, io.EOF) {
		http.Error(w, "fail to get request body\n", http.StatusBadRequest)
		return
	}

	defer req.Body.Close()

	var reqArticle models.Article

	if err := json.Unmarshal(reqBodyBuffer, &reqArticle); err != nil {
		http.Error(w, "fail to decode json≠\n", http.StatusBadRequest)
		return
	}

	jsonData, err := json.Marshal(reqArticle)
	if err != nil {
		http.Error(w, "fail to encode json\n", http.StatusInternalServerError)
		return
	}

	w.Write(jsonData)
}
```

# Decoderを使用する場合

```go
// POST /article
func PostArticleHandler(w http.ResponseWriter, req *http.Request) {
	var reqArticle models.Article
	if err := json.NewDecoder(req.Body).Decode(&reqArticle); err != nil {
		http.Error(w, "fail to decode json\n", http.StatusBadRequest)
	}

	article := reqArticle

	json.NewEncoder(w).Encode(article)
}
```

:::note info
ストリームから直接リクエストデータを取るようにしたことで、デコード前の「Content-Lengthヘッダフィールドの値からバイトスライスを作り、そこにリクエストボディの中身を書き込む」という操作がまるまるいらなくなっています。直接デコーダの Decode メソッドを呼び出すだけで済むため、コードの見通しがとても良くなりました。
:::


# Decoderを使用するステップ
## Decoder（Unmarshal）
__ステップ1：リクエストボディをデコーダーに渡す__
`json.NewDecoder`を使って、リクエストボディをデコードします。

```go
var reqArticle models.Article
decoder := json.NewDecoder(req.Body)
```
__ステップ2：デコードを実行する__
`Decodeメソッド`を使って、リクエストボディを構造体にデコードします。

```go
if err := decoder.Decode(&reqArticle); err != nil {
    http.Error(w, "fail to decode json\n", http.StatusBadRequest)
    return
}
```

## Encoder(Marshal)
__ステップ1: レスポンスのContent-Typeを設定する__
クライアントに返すレスポンスがJSON形式であることを示すため、Content-Type ヘッダーを設定します。
```go
w.Header().Set("Content-Type", "application/json")
```
__ステップ2：レスポンスボディをエンコードする__
`json.NewEncoder`を使って、構造体をJSON形式でレスポンスボディにエンコードします。

```
if err := json.NewEncoder(w).Encode(reqArticle); err != nil {
    http.Error(w, "fail to encode json\n", http.StatusInternalServerError)
    return
}
```
TypeError: hog() got an unexpected keyword argument 'multichannel'

skimage.features.hogを使用しようとしたときに発生。

発生したコード
```python
from skimage.feature import hog
from skimage import data, exposure

#hogとhog画像の取得
fd, hog_image = hog(
    img, orientations=8, 
    pixels_per_cell=(16, 16),
    cells_per_block=(10, 10), 
    visualize=True, 
    multichannel=True,
    feature_vector=True
  )
```
使用していたskimageのバージョンは```0.20.0```でしたが、どうやら引数が変わったみたいです。

代わりに```channel_axis```という引数が入ったようです。

変更後
```python
from skimage.feature import hog
from skimage import data, exposure

#hogとhog画像の取得
fd, hog_image = hog(
    img, orientations=8, 
    pixels_per_cell=(16, 16),
    cells_per_block=(10, 10), 
    visualize=True, 
    channel_axis=2,
    feature_vector=True
  )
```
これで無事に動きました。

![download.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594896/d76b3e60-f118-5a8f-23de-767cd432a9aa.png)

![download.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594896/67ce9550-719c-d11c-e1f8-5cbd3a266dce.png)
regreSSHion(CVE-2024-6387)バグ緩和策の問題を回避するシェルスクリプトをのぞいてみる

## 概要

- regreSSHion(CVE-2024-6387)の脆弱性そのものについての記事ではありません
- regreSSHionバグに対する緩和策(LoginGraceTimeの無効化)ではDoSを回避できないので、redhatがそれを回避するためのシェルスクリプトを配布(GPLv3)している。この記事はそのシェルスクリプトを覗いてみようという趣旨

## regreSSHion(CVE-2024-6387)バグについて

このバグは、過去に修正済みだった脆弱性がデグレによって復活したというものです
細かいことは下記URLを参照してください
- https://nvd.nist.gov/vuln/detail/CVE-2024-6387
- https://piyolog.hatenadiary.jp/entry/2024/07/02/032122

## 緩和策について

対策として、原則的にこの脆弱性を修正するパッチを適用することです
各ディストリビューションごとに修正版が配布されているはず

修正版への置き換えが難しいときは、下記の緩和策を行います

1. ```sshd_config```に対して、```LoginGraceTime 0```という設定変更を行う
1. sshdを再起動する

LoginGraceTimeの説明についてはマニュアルを参照してください
- https://man.openbsd.org/sshd_config

## 緩和策の問題

前項の緩和策を適用すると、ログインしないままのセッションがいつまでも残り続けることになります
残り続けると、リソースを食い潰してしまうためDos攻撃を受ける脆弱性があるということになります

redhatでは、その問題を回避するためのシェルスクリプトを下記URLにて配布(GPLv3)しています
- https://access.redhat.com/solutions/7077613

## シェルスクリプトの内容をのぞいてみる

redhatが配布しているこのシェルスクリプトの要件は
「sshサーバーと接続しておきながら、ログイン認証に成功も失敗もせずに120秒以上経過したsshセッションを検出して、それを強制切断させる」というものです
どうやってシェルスクリプトで実現すれば良いか想像できそうですか？

では当該シェルスクリプトのソースを読みながら処理をみてみましょう

このシェルスクリプトはそれほど難しくないです
全体で47行、そのうち20行ほどはコメント行です

1つめの処理は、処理対象となるプロセスの絞り込みを行っています
1. ```pgrep -x sshd```でsshdプロセスを抽出します
1. 抽出したプロセスごとに、```readlink -f /proc/${pid}/exe```が```/usr/sbin/sshd```かどうかをチェックします。```/proc/${pid}/exe```は、そのプロセスの実行ファイルへのシンボリックリンクですので、```readlink -f```で追跡しているということです
1. その次は、```/proc/${pid}/cmdline```の内容を調べます。ここを見ることでログインしているかどうかを見ているということになります
1. 上記2つのチェックで、実行ファイルが```/usr/sbin/sshd```でかつ、まだログインしていないプロセスが見つかった場合は、それらのプロセスは次の処理へ送られます

2つめの処理は、処理対象のプロセスが、起動してから120秒経過している場合は強制終了させるというものです
1. 処理時から120秒前のUNIX時間を算出して変数に代入しています
1. 処理対象のプロセスごとに、```/proc/${pid}```に対して```stat -c %Y```コマンドを実行して、このプロセスが作られたUNIX時間を算出して変数に代入しています
1. 上記2つの変数を比較すると、プロセスが始まってから120秒以上経過しているかどうかがわかります
1. 120秒以上経過していたら、そのプロセスをkillコマンドで強制終了させます

どうでしたか？想像どおりの内容だったでしょうか？

## 終わり
このスクリプトをcronなどで定期的に実行することで、緩和策によりセッションが無限に残り続けるという問題を回避できます
```/proc```をシェルスクリプトへ活用する参考例のようなシェルスクリプトでした
「封筒」で送られる情報には、情報以上の価値がある時代になっている。

「封筒」で送られる情報には、情報以上の価値がある時代になっています。

─── そして、価値があるということは、ユーザーがそれを積極的に取得したいと思える仕組みを作ることができるはずです。

ただ、私にはその価値をうまく提供する方法を思いつきませんし、それを実現しようというモチベーションもありません、ただ「こんな需要があるよね」ということに気が付いてしまったので、今日はそのお話をします。

<br>

# 封筒が届く、ということ
私はさっぱりなのですが、妻が投資をしており、たまにこんな封筒が届きます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/758664/a0f0a4a2-60e7-da88-f045-9f92695f9489.jpeg" width="500">

<br>

この封筒、どうやら投資をしている会社から送られてくるもので、今期の会社の状況やどれくらいの配当金が出たのかを情報として通知してくれるものらしいです。

で、この封筒ですが、投資をしている会社の分だけ届くみたいです。何十社にも投資をしている人は封筒がなん十通も届くそうです。

<br>

私は妻に、「これ、紙の無駄じゃね？」って言ってしまったのですが、実は結構大事なものらしくて、各社が『今期もお願いします！』というお願いも込めて送って来るものなのだというのです。

私は、ゲームをしながら「はぇー、そうやねんなー」って感じだったのですが、そのときに面白い話を聞きました。この封筒、送っている各会社が思ってもみないような価値をユーザーにもたらしているというのです。

<br>

# SNSではマウント合戦が起こっていた
さて、SNSでは面白いことが起こっています。

あとから「そのポスト載せてもいいの？許可貰ってるの？」みたいなことを言われても面倒くさそうだったので、ポストは載せませんが、大量に届いた封筒を並べたり、重ねたりしてSNSにアップする人がいます。

> 今年も大量封筒が届きました、配当金ほくほく！

> 見てこの量、100社以上に投資している者のみ見ることができる光景。

> まさに不労所得、配当金は追加投資に回します。積み上げていきましょ！

<br>

─── こんなポストが写真付きで上げられるわけです。もしかしたら、皆さんも一度は目にしたことがあるかもしれませんね。

こんな感じで、マウント合戦が起こっています！何のマウントだって？「俺はこんなに投資をして、配当金を得ているぜ！」マウントですよ。

（すみません、適当なことばっかり言っています。）


<br>

–

<br>


また、私は普段ブログ界隈にいるので、こんなハガキをSNS上でよく見かけます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/758664/0523d552-cc28-2221-452b-cde41df397a8.jpeg" width="500">

Google広告によって収益が発生した証拠とでもいいましょうか。簡単にいうと、この封筒が届いたのということは、Google Adsenseで収益を得たという証拠であり、ブロガーとして自慢できる代物です。

> ついにGoogleさんからお給料もらいました。

> 私のブログもついにここまで来ました。慢心せずに頑張ります！

> いったんAdsenseはクリアかなー、次はアフィリエイトで稼ぐぜ！

<br>

ブロガーの登竜門とも言われるGoogle Adsense、この封筒が届いたブロガーは「俺はGoogle様から給料をもらってるぜ！」ってマウントを取るわけです。

（すみません、適当なことばっかり言っています。）

<br>

───これらを見て、私は確信しましたね。

"封筒"ってやつは、いまや特別なものになっていると。

SNSに投稿しやすい封筒は、それだけで価値があると。

<br>

# "価値"の正体
現代において、ほとんどの情報はWebで見ることができ、それはまた便利です。ただ、それではどうしても満たせないものがあります。それが人間の承認欲求です。

もうすでに誤解は与えているのかもしれませんが、誤解を恐れずにいえば、彼らはSNSでどれだけ自分が凄いかをこの封筒でアピールしています。

<br>

それが特別な人しかもらえないものであればなおさらです。

<br>

封筒には可能性があります。
情報に付加価値をつけることができます。

<br>

面白いところは、それは「紙」程度でいいことです。大層なクリスタルスタンドや、商品券、賞状やトロフィーである必要がないことです。

ということでオチはありません。「封筒で情報を送ることについて、いま一度本気で考えたら、なにかひとつコンテンツを伸ばすことができるんじゃないか？」と思ったって話です。

<br>

私の記事はただの妄想ですが、誰かうまく使ってくれる人がいればぜひ！

<br>
<br>

以上です。
AWS責任共有モデル

# はじめに
AWSの責任共有モデルとは、クラウドサービス提供者であるAWSと顧客との間で、セキュリティとコンプライアンスに関する責任を分担する考え方です。AWSは物理的なインフラストラクチャのセキュリティを担当し、顧客は自身のデータとアプリケーションのセキュリティに責任を持ちます。
AWSにおいてこの責任の相違を「クラウド”の”セキュリティに対する責任」と、「クラウド”内の”セキュリティに対する責任」としています。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3733574/b7d68910-0ebd-737c-1f67-a4f2862627cd.png)

# AWSの責任共有モデルのメリット
AWSの責任共有モデルでユーザーが享受できる主なメリットとして、ユーザー側の作業負担軽減が挙げられます。AWS責任共有モデルは、企業が自社内で管理・運用するオンプレミス環境と比較して、AWS側にインフラの運用やプラットフォーム、ソフトウェアの管理を任せることができるため、管理コスト面でユーザーの負担を軽減できます。
それ以外にも、オンプレミスと比較した費用軽減が期待できます。オンプレミス環境では、インフラの購入や構築に初期費用がかかります。さらに、専門的なスキルと知識が必要であり、人材や時間にコストがかかります。しかし、AWSを利用することで、毎月の使用料のみで済み、初期費用や人材費用を節約できます。

# AWSの責任範囲
責任共有モデルにおいてのAWSの責任範囲は以下の通りです。
- 環境リスクを考慮したロケーション
- 物理的なアクセスに対する監視体制
- 冗長化・自動調整された電力と空調
- ホストOS
- キャパシティの計画
## 環境リスクを考慮したロケーション
AWSのデータセンターは、具体的な場所は公表されていませんが、洪水、異常気象、地震活動などの環境リスクを考慮した場所に配置されているとされています。
また、リージョンを構成するアベイラビリティーゾーン（AZ）間は物理的に分離されており、それぞれ独立して構築されています。これにより、自然災害や地震で一方のAZが影響を受けた時に、自動的に処理中のトラフィックを影響のある地域から移動できるようになります。
## 物理的なアクセスに対する監視体制
AWSのデータセンターは、物理的な位置によって保安要員、防御壁、侵入検知テクノロジー、監視カメラ、二要素認証などの多層セキュリティで厳重に保護されています。データセンターへの物理的アクセスは権限を持つ担当者のみが許可され、第三者のアクセスはAWSの担当者の承認により申請する必要があります。
また、データセンターへの入場にはアクセス申請が必要であり、業務上の正当性を詳細に説明する必要があります。さらに、許可されたアクセスも期限とエリアが制限され、すべてのアクセスは記録と監査対象となります。
## 冗長化・自動調整された電力と空調
データセンターの電力システムは完全に冗長化され、24時間年中無休で動作しており、電力障害時にはバックアップ電源を使って重要な業務を継続できます。空調は適切な温度と湿度を保つためのメカニズムを使用し、作業員とシステムは適切なレベルで温度と湿度を監視・制御しています。
## ホストOS
AWS管理者は承認を受けた拠点ホストから個別のログインを行い、多要素認証が利用されています。特別に設計された管理ホストが使用され、作業完了後は特権とアクセス権が削除されます。全てのアクセスはログが記録され、監査対象となります。
## キャパシティーの計画
AWSはサービスの利用状況を継続的にモニタリングし、アベイラビリティに関するコミットメントと要件をサポートするためにインフラストラクチャを整備しています。少なくとも月次のキャパシティープランニングモデルを維持し、将来の需要を評価することで情報の処理量、通信量、監査ログストレージの容量などを考慮しています。

# 利用者の責任範囲
次は利用者の責任範囲は以下の通りです。
- ゲストOS
- ネットワーク設定
- アプリケーション
- データの暗号化
- アクセス権限の管理
## ゲストOS
AWSの責任共有モデルにおいて、IaaSのようなホスティングサービスでは、ゲストOSの管理・運用はユーザー側の責任となります。Amazon Elastic Compute Cloud（Amazon EC2）インスタンスを使用する際には、ゲストOSの更新やセキュリティパッチの適用、インストールしたアプリケーションやファイアウォールの構成などがユーザーの責任です。
## ネットワーク設定
ネットワークの設定についてもユーザーが責任を負います。そう進言の許可・拒否や、送信先の設定を行うことが必要です。
## アプリケーション
ユーザーがAmazon EC2などのインスタンスにインストールしたアプリケーションについては、ユーザー側で管理・運用する必要があります。
## データの暗号化
AWSの責任共有モデルでは、ユーザーデータの暗号化についてはユーザーの責任範囲になります。データはユーザー固有の資産であり、ユーザー以外はその管理方法を決めることはできません。
## アクセス権限の管理
ユーザーは、データの暗号化と同様に、IDやデータへのアクセス権限の管理も責任範囲に含まれます。具体的には、サービスを利用するユーザーは、自身のIDやそれに関連するアプリケーションやシステム、ユーザーデータへのアクセス権の管理・運用に対して責任を持たなければなりません。

# 参考元、引用元
- https://aws.amazon.com/jp/compliance/shared-responsibility-model/
- https://is.gd/jFXjyc
【Power Automate Desktop】フロー制作のヒント


私は地方の会社で情報システムを担当しております.　

普段はVBA、Power Automate Desktop(以下、PAD)のフロー制作等をしております.

20代前半でまだ半人前ではありますが、アウトプットの練習も兼ね、記事を作成した次第です.

初投稿ですので届かぬ箇所等があるかと存じますが、温かい目でみてあげてくださると幸いです.

***

当社では過去にBizrobo,WinActorとRPAソフトを扱ってきましたが、現在はPADを使用しています. 

この記事で紹介することに関して、前述の2つのツール (に限らず、他のRPAにも使えるかもしれない) においても有効であると考えています.

#  キー操作


RPAのハウツー系動画等を見ていると、
「要素を捕まえて、RPA認識したら操作を行う」ことが紹介されており、私も最初はこの手段を多用してフローを作成していました.　

勿論このプロセスは非常に重要で、直感的に作ることのできるRPAの1つの良さですが、

RPAの性質上、要素を捕まえることに時間がかかる、要素が捕まえられなくなる等のエラーに衝突するリスクが大きくなりえます
(WinActorは画素数等に依存していたように憶えています)
(実行環境のスペック等の要因はあるかもしれません...).

このとき有効になってくるのが、キー操作というアクションです.

:::note warn
担当のフローで扱っているソフトがデスクトップアプリなので、ブラウザ等を扱う際に関して、この手段の適否はわかりかねますのでご了承ください...
:::
#### 

***
#### 例)ExcelをPDFにする

（今回は例として今回はExcelを例として扱っています）

要素を捕まえてExcelを起動→ファイルタブを選択→印刷を選択→...というフローを作ったとして、自分の場合可用性に長けたフローを作ることは困難でした. 

![スクリーンショット 2024-07-16 145649.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3839201/a95549d9-dadc-b67b-54c0-05acb53dd3b3.png)
わりと止まりがちなんですよね。。。

ここで、PADのアクション"キー操作"を利用します.


例えば...今回の場合...印刷を呼び出す際に"Ctrl + P"を入力すれば、一発で印刷画面に飛べますよね.

このようなショートカットキー等を入力することで、要素に依存しない動作を指示することができます.

以下、上記の例をもとにして作成した、xlsxをPDF化するフローの一例です:

![スクリーンショット 2024-07-17 155346.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3839201/8f756670-fa96-677a-9acd-bef7b5f52298.png)




上記の通りキー送信、クリップボードの操作等を駆使し、出来る限り要素に囚われない操作をすることで相対的に可用性、動作性の高いフローを作ることができます.

![スクリーンショット 2024-07-16 163404.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3839201/c28b955c-af8f-f769-e188-2b8898b022ab.png)

![スクリーンショット 2024-07-16 163442.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3839201/04eab3eb-9e75-3596-6ad5-2f224ca9da0a.png)


無事にPDFに変換することができました.

:::note warn
注意点
キー入力のアクションをする際、Waitアクションを挟み0.5秒ほど若干の待ち時間を加えることで、動作がさらに安定します
(長すぎると塵積で遅くなるので注意)(1秒、結構大きいです...)
:::
#### 

# まとめ

今回作成したフローのように、要素を掴んでアクションをすることがすべてではなく  キー操作、あらかじめ用意されているアクション(今回扱っていませんが)等、他のアクションを利用することで、よりよいフローを作成できる...と考えています.

RPAを触っていて、”ショートカットキーを知っている”ということは大きな武器になるのではないか、と感じています.



:::note info
今回の場合そもそもドキュメント印刷アクションステップ使ったら一発でしょ(;'∀')！←他のデスクトップアプリでも使用できるという点でキー操作を伝えたかったのでそこは目を瞑ってください(;;'∀')
:::
#### 

見てくださった方の参考になりましたら幸いです、
最後までご覧いただきありがとうございました.
(AWS) FSx で共有フォルダ GUI (fsmgmt.msc) を一瞬で開いちゃおう！

FSx で Windows MMC スナップイン(fsmgmt.msc)を使って、「共有」、「セッション」、「開いているファイル」を見たい時ありませんか？

公式の手順だと色々と煩わしい。
そんな時に簡単なショートカットを作るだけ一発で開けるようになります。

やり方は簡単

```共有フォルダー (FSx).lnk
C:\Windows\System32\fsmgmt.msc /computer=amznfsxltexxxxx.midoriya3.com
```

これだけです。
Revoltというchat

# RevoltというChatツール
どうも、kkk2zです
この夏はセミがのんのん鳴いています
夏からセミを取ると　サンジのいない麦わら海賊団です
そんなことは置いといて
Revoltを知っとりますか？
まぁいいや説明します(質問した意味とは,):relaxed:
Revoltとは、簡潔に説明すると　Discordをパクってオープンソース化した物です()
ほんとに簡潔ですねぇ
置いといて
このRevolt、使うとDiscordに慣れていると使いづらいですが、なれると便利!
なぜか、そう　そこが重要です
理由リスト
1:Revoltでは、Botを作成する際にTokenをプログラムに差し込むだけなので簡単なんです!
2:DiscordとRevoltがAutoMod経由でBridgeできます!
3:オープンソースだから自由にクライアントなどがホストできます
4:スタイルを好きに変更でき　好きなデザインにできます
5:サーバのソースコード含め公開されているのでChatを自分でホストできる
6:オープンソースなのでいろいろな方が改造をしているのでサポートがまぁまぁ充実
以上です!
あっ　そうそう　思い出した!
Revolt クライアントをホストシている人をご紹介!

kkk2z1
私です。
JF6DEU
中学生(?)らしい　Revoltを render.com などでホスト可能にしたすげー人
その人が運営する、Revite-forkの非公式サイトです
https://revite.jf6deu.net/
###### *reviteは、Revoltの安定化されたクライアントです
*2 Revoltのサーバ一覧一位のサーバにRevolt過疎サーバーと言う名前のサーバがありますが、彼らは、管理人の話のみを信じ、荒らしでもないことを荒らしといいそれを他の新規にも教え込んだり、人が発言すると「黙れ、死ね」とリプライする人がいるなど頭がとてもhotな人たちの一種のカルト化したサーバなので入ることは、推奨しません .
さらに言うと、本来コミュニティの管理人であるはずの人間ですら、某人間が、発言しただけで荒らしと言ったりする上　コミュニティの管理人ならば、コミュニティのユーザが、荒らし・暴言を行わないように　抑制するという仕事があるはずなのに実行しないヤバい人です
なので"絶対"にRevolt過疎サーバーというサーバに入らないでください!
あなたも、被害に合う可能性があります

---------------
筆者:kkk2z1
最終編集(?):2024/7/17
homepage: kkk2z1.ie-tnet

-----
AWS SAA-03 勉強してつまづいたメモ

AWS SAA-03 勉強してつまづいたメモです。

## 可用性、耐障害性、およびスケーラビリティ

#### 可用性（Availability）：
システムが継続して稼働できる能力や、その指標のこと。


#### 耐障害性（Fault tolerance）：
可用性について考えるときの概念である。サブシステムの障害に耐え、可用性を維持する (確立された SLA の範囲内で適切な処理を行う) 能力

冗長化（複数AZ、リージョンにサブシステム）やオートスケーリングが有効。


#### 障害隔離（fault isolation）：
可用性について考えるときの概念である。これにより障害発生時の影響範囲を最小限に抑えることができる。
通常、モジュール化によって実装され、ワークロードは小さなサブシステムに分割され、それぞれ個別に障害が発生し、個別に修復できる。

#### スケーラビリティ（Scalability）:
システムや機器、ソフトウェアの拡張性や拡張可能性のこと。

##### 参照
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html


## バックアップの方式

#### ポイントインタイムリカバリ（PITR）
DBなどの復旧方法のひとつで、特定の時点までのデータ変更をリカバリする機能のこと。

前提
AWS Backupとは
統合: AWS Backup を使用して、EC2、EBS、EFS、Amazon FSx for Lustre、Amazon FSx for Windows File Server、AWS Storage Gateway などの AWS のサービスをバックアップ。

組織: AWS Organizations を AWS Backupと組み合わせて使用​​すると、複数のAWSアカウントにわたってさまざまな AWS サービスをバックアップできる。

利点: バックアップにより一元管理が可能になり、バックアップを自動化し、データのライフサイクルポリシーを定義できる。バックアップ ポリシーを適用し、バックアップが確実に暗号化され、完 了後にバックアップを監査できるため、コンプライアンスが向上する。


##### 参照
https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource

##### つまづきポイント１
Redshiftはスナップショット、AWS　Backupを使う方法の二つがある。
スナップショットはS3を裏で使っていて、クラスターのポイントインタイムリカバリである。

##### 参照
https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/working-with-snapshots.html

##### つまづきポイント2
DynamoDBはDynamoDBと復元、AWS Backupを使う方法の二つがある。
AWS Backupはオンデマンドバックアップのみ。

DynamoDBの方では、DynamoDB のポイントインタイムリカバリとオンデマンドのバックアップと復元の二種類ある。
共通ーテーブルのパフォーマンスや可用性への影響なし
||オンデマンドのバックアップと復元|ポイントインタイムリカバリ|
|---|---|---|
|方式|いつでも完全バックアップ|増分バックアップ|
|最新|数秒以内で一貫性がある|過去5分以上で最新を復元可能|
|復元時点|任意の時点|過去35日間の任意の時点|
|用途|長期間のデータを保持|誤った書き込みや削除から保護|


##### つまづきポイント3
Amazon RDSは自動バックアップ、手動バックアップ（スナップショットの作成）と、AWS Backupを使う方法がある。

自動バックアップで取得したスナップショットをS3バケットへ手動でコピー（エクスポート）することもできる

||手動|自動|AWS Backup|
|---|---|---|---|
|保持期間|上限なし|最大で35日|上限なし|
|頻度|手動|30分間隔の時間に1日1回|1時間ごと、12 時間ごと、毎日、毎週、毎月の頻度|
|復元時点|ー|５分ごとにトランザクションログがあるので、5分間隔の時点|任意の時点|

##### 参照

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html

https://aws.amazon.com/jp/rds/features/backup/

## 全然違うのに名称が似てる
#### AWS AppSync
GraphQLマネージドサービス

#### AWS DataSync
オンプレミスからAWSへデータをS3, EFS, FSxに移行する

#### Amazon AppFlow
SalesforceなどのSaaSと安全にデータを交換できるフルマネージドサービス

随時追加予定
anyを書かない型チェック

TL; DR
```typescript
const isStrArray = (arr: unknown): arr is string[] =>
  Array.isArray(arr) && arr.every((s) => typeof s === "string");
```

TypeScript5.5からは型述語を推論してくれるのでもう少しシンプルになる
```typescript
const isStrArray = (arr: unknown) =>
  Array.isArray(arr) && arr.every((s) => typeof s === "string");
```
【2024マラソン37】音声入力 x 複数デバイス でQiitaマラソンを走り抜けた話

# 何の記事？
qiitaマラソンの38記事を走り抜けるべく、使った時短方法をまとめました。

# 誰向け？ どんな役にたつ？
- qiitaマラソンやアドカレなど、一定期間でコンスタントに記事を上げたい人
- qiita記事を書いてみたいが、書き上げる程のまとまった時間が取れない人
- Qiita記事を書くにあたって、執筆速度を上げたい人

# あらすじ
最初は38記事も行けるのか……？
だったのですが、意外と行けてしまったので、どういった要素が時短になっていたかをまとめてみました。

# 何をやったか
### 箇条書きから始める
markdownの見出しとリストを使って、どんな流れで何を書くかを箇条書きで書いて下書きを作ります。
なお、テンプレートは去年のアドカレで自分が作ったものを参考にし、記事内容に合わせて調整しました。

### 言いたい事を決める
最終的に言いたいこと、伝えたいことは何なのか？……を最初に書き、それを伝えるために必要な説明は……と、逆算して内容を埋めていきました。

### 誰向けかを決め、書くことを絞る
どんな人向けかが細かく決まると、記事が格段に書きやすくなりました。誰向けかが決まると、説明の粒度が決まります。
それによって解説を省いたり、付け加えたりと、記事の形が定まっていきました。

### 音声入力でインタビューに答えるように書いていく

各見出しをインタビュー項目のように捉えて、話し言葉で音声入力を使っていきます。
利点は、タイピングで腕が疲れて書けなくなる……ということがない他、iPhoneやiPadでもできることです。
改行や句読点はわざわざ発言するのが面倒なため、そこだけ手動入力を挟みながら、ベースは音声入力で書いていきました。

### 時間がない時はiphoneでも書いていく
かといって、家族がいるといつでも音声入力ができるものでもありません。
そのため、隙間時間を使ってスマホのフリック入力でも書いていきます。
qiitaはありがたいことにブラウザエディタがしっかりしているので、どの端末でも下書きに保存しておけばノータイムで続きを書き進められます。

なお、私の場合はiPhoneもiPadもホームから直で飛べるようにしているので、すぐに書き進められてよかったです。

### iPadのライブ変換を使う

音声入力は変換ミスがひどいですが、ノー変換で書き進めることを想定して実装されたライブ変換は、ほとんどタイピングを止める事なく書き進められます。
また、QiitaやBlenderなど、ソフトやサイト名もユーザ辞書に登録しておけば難なく変換できます。

### 文章にしなくても、箇条書きのままでも悪くない
箇条書きのままで十分伝わるものは、あえてそれ以上文章にしませんでした。
私の場合、qiitaのような技術記事を読むときは読み飛ばしながら読むので、むしろ見出しやリストに言いたいことがまとまっている方が有用ではないかと感じることもあります。

### Qiitaエディタをブラウザで開き、読み上げ機能を使う
読み上げチェックをすると誤字・脱字や、話が不自然な箇所に気づきやすいです。
黙読も悪くありませんが、基本的に画面上で読む文章は流し読みしてしまうので、強制的に音声で読み上げてもらう方が確認できます。
自分が読んで確認するための読み上げなので、読み上げ速度は1.75〜2.0位の速度で問題ありません。自分が聞いて認識できるギリギリで使うとちょうどいいかと思います。

# 現状の課題点
### 音声入力の変換ミスの訂正
音声入力はとてつもなく変換ミスが起こるので、入力後のテキストの訂正が必要になります。
訂正が必要な箇所のみ上手く洗い出せればいいのですが、現状は読み上げと目視で確認しているため、何か対策を講じたいところです。

### 表記揺れの手修正
話し言葉で文章を作ると、どうしても表記揺れが発生します。
以前、vimプラグインで日本語の表記揺れチェックができるものを見かけた気がするので、vimに持って行って最終整形をするのもいいかなと考えています。
初めてのハッカソンで人生が変わった話

# 目次
1.ハッカソンの概要
2.ハッカソンに出てみた理由
3.ハッカソンでの制作物の概要
4.ハッカソンで学んだこと
5.これからの課題とまとめ

# 1.ハッカソンの概要
参加したハッカソンはインターン型ハッカソンでは「音楽×○○」というテーマで行われました。

開発期間
2日

# 2.ハッカソンに出た理由
### ⑴.自分に何が足りないのかを明確化したかった。
普段と違う環境にいくことで自分に何か足りないのかを発見したかった。
### ⑵.チーム開発の経験をしたかった
**チーム**でアプリ開発は要件定義→設計→開発→テスト→リリースの流れを体験したかった。

### ⑶.今までのインプットをアウトプットする。腕試し
限られた時間の中でどこまで力を発揮できるか、つまり今の実力を知りたかった。

# 3.ハッカソンの制作物の概要
### エレベーターピッチ
**音楽×散歩**

[**運動不足を解消**]したい
[**通勤者**]向けの、
[**Hear Spot**](https://hear-spot.vercel.app)というプロダクトは、
[**ピンポイントな位置情報による選曲アプリ**]です。
これは[**あえて遠回りをしてみたり、1駅前で降りてみる動機づけ**]ができ、
[**Apple MusicやSpotify**]とは違って、
[**場所ごとに異なる音楽を拾い集める機能**]が備わっている。

### 使用技術
microcms
typescript/react/next.js


# 4.ハッカソンに出て学んだこと
### ⑴.アプリ開発は要件定義が一番大切なこと
『なぜそのアプリを作ったのか？、どこでマネタイズするのか？、既存のアプリとの差別化ができているか？』
**エレベーターピッチを正確に言える！**
**ユーザーストーリーが明確！**
結局要件定義がしっかりしていないとアプリを作ったところで意味がない！


### ⑵.チームでどのように開発するのか
自分はどの部分を担当するのかを決め、内容把握し、進捗状況を言語化して伝える。私にとってここが一番の壁だった。IT専門用語がわからなかったりバックエンドの知識不足でうまく連携が取れなかったりで、聞き返したり、教えてもらったりなどで開発の妨げになってしまった。フロントエンドエンジニアでもバックエンドの知識を網羅しないと、チーム開発においてお話にならないことが実際にチーム開発を経験することで改めて実感した。


# 5.これからの課題とまとめ
### 課題
⑴ SupabaseやfirebaseなどのSaaSに頼らずバックエンドの方も開発をして一通りのアプリ開発を体験し、バックエンドの知識を構築することで、アプリケーション開発知識をつける。

⑵ IT系の記事を読み込み、基礎知識を定着させる。仕事で使う用語やIT用語を使いこなすレベルまで持っていく。
 
 ### まとめ
 自分はある程度知識を持っていると勘違いしていて、開発の妨げになってしまい、泣きたいぐらい悔しかった。
 ハッカソンに出て満足せずに、今回得た課題について真剣に向きあい成長していきたいと強く感じた。
ITパスポート データの整列と集計

・整列（ソート）
データをある特定の規則に従い、並べ替えること

・昇順
値を小さい順（日付は古い順）に並べること

・降順
値を大きい順（日付は新しい順）に並べること

・整列キー（ソートキー）
データを整列するときの基準となる項目（列）

・集計
・xxx別に集計する
xxxごとに並べ替えて集計する
GitHub REST API のレートリセット時刻を確認する

# レート制限取得のエンドポイント

`rate` オブジェクトは非推奨とのことなので、`resources.core` を使いましょう。

> Note: The rate object is deprecated. If you're writing new API client code or updating existing code, you should use the core object instead of the rate object. The core object contains the same information that is present in the rate object.

https://docs.github.com/ja/rest/rate-limit/rate-limit

# つらい点

UNIX時刻が読めない。

```terminal
$ curl -s -H "Authorization: bearer <PRIVATE_TOKEN>" https://api.github.com/rate_limit | jq '.resources.core'
{
  "limit": 5000,
  "used": 1,
  "remaining": 4999,
  "reset": 1721222176
}
```

# コマンド

リセット時刻がUNIX時刻で返ってくるので日本標準時（JST）に変換して返す。

```terminal
$ curl -s -H "Authorization: bearer <PRIVATE_TOKEN>" https://api.github.com/rate_limit | jq '.resources.core | .reset = (.reset | tonumber + (9 * 3600) | strftime("%Y-%m-%d %H:%M:%S"))'
```

# 出力

日本標準時に直さないと読めないので助かる。
これでビビらずにいっぱいAPI叩けるね。

```terminal
{
  "limit": 5000,
  "used": 2631,
  "remaining": 2369,
  "reset": "2024-07-17 16:43:30"
}
```
What are the 10 Most Popular Python Frameworks for App Development?

What is a Python Framework?

A Python framework is a collection of modules and packages that allows developers to build apps through a pre-built implementation of redundant functions. They release developers from minor issues like thread management, sockets, and protocols.

The popularity of Python is because of its vast range of python libraries for mobile app development, packages, and frameworks.

Several best Python frameworks for mobile app development and web app development enable seamless, efficient, and swift application development. We’ve listed the best frameworks in this blog.

Here is a list of top 10 Python Frameworks for app development in 2024:

1-Django Framework
2-Flask Framework
3-Web2Py Framework
4-TurboGears Framework
5-Falcon Framework
6-CherryPy Framework
7-Tornado Framework
8-AIOHTTP Framework
9- Kivy Framework
10-BeeWare Framework

Read in Detail: https://www.ongraph.com/a-list-of-top-10-python-frameworks-for-app-development/
情報伝達手段はどこまで進化するのか？

# はじめに
情報伝達手段とは、情報を発信者から受け手へ伝える手段のことです。
これには、例えば一方的な手段や双方向的な手段が存在したり、アナログやデジタルが存在したりします。

# 現状
私が「情報伝達」と聞いてまず頭に浮かんできたのはDiscordです。Discordとはチャットサービスであり、開発者に向けてはBotを作るためのAPIを公開しています。
最近最も頑張って取り組んでいるのがDiscordのBotなので、思い浮かんできたというわけです。

今作っているのはマリオカートのタイムを記録できるBotであったり、音楽Botであったりといろいろですが、それらに共通する欠点があります。
それは、「情報が直感的につたわらない」ということです！

例えば、これ↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920761/578479df-a473-a730-292d-be9db75e140f.png)

これぐらい簡単なものを伝える、ということなら問題はないのですが、音楽Botなどになってくるとボタンを使用して一時停止とかスキップとかができるようにならないと不便です。
すると、こうなります↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920761/4fe6d546-e55c-e94a-3c96-feabc9dcef47.png)

**非常に見にくいです。**
埋め込みが全くきれいではありません。
文字で説明しないといけないのならアイコンはいらないでしょうよ…。
キューのボタンとか直接的に表せるアイコンがありません…。

これが限界です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920761/3e1cfebf-0909-d6a2-6623-428f08d569fa.png)

まだ見やすくなったぐらいで、正直あまり直感的ではありません。キューのボタンもアイコンだけでわかるようにしたいのですが…。どなたかいいアイデアがあれば教えてほしいです。
技術的な事を説明すると、もともとはDiscord APIの埋め込みを直接使用していわゆる「Now Playing」を出していたのですが、@napi-rs/canvasを使用して画像にして、それを埋め込みの画像として使っています。
本当はSpotifyみたいにしたかったのですが…。

# これを改善するために？
さぁ、どう改善すればいいのでしょうか？
**直感的にするしかありません。**
しかし、Discordの**テキストベースでは**これ以上直感的に**できません。**

これは行き詰まりではないか？と思った私の前にさっそうと現れたのがこれ↓
[Discord Embedded App SDK](https://github.com/discord/embedded-app-sdk)だ！！！！

これはもう作るしかありません。
ご存じない方むけに説明すると、Discordには、VC（ボイスチャット）でちょこっと軽いゲームができたりする機能があります。
これを、Discord側で用意されたものではなく全ての開発者にオープンにしたのがDiscord Embedded App SDKです。

つまり、私にとっての**最適解**です。

ですので、ちゃちゃっと作っていきましょう。

https://qiita.com/NovanMondon/items/43ef9f5ad6bafeed3c54

（上記、参考にさせていただきました、ありがとうございます！）

# 具体的に何をするのか？
まず、何を作るべきかについて説明します。
と言っても、そこまで作る必要はありません。もとから音楽Botのある程度の基礎はできているのでサーバーとうまくガッチャンコするだけです。

ということで、以下が作るもののリストです↓
1. 音楽Botとうまくガッチャンコされた、データを処理するためのAPIサーバーを作る
2. これまたうまくガッチャンコされた、Activityのページ配信用のバックエンドサーバーを作る
3. バックエンドサーバーから送られるHTML,CSS,更にデータをバックエンドに送るためのJSを作る

正直に言えばステップ3が最も難しいです。

# ステップ1

# と、いきたいところだったのですが
時間が、ありませんでした。
投稿が、間に合いません！

なんか竜頭蛇尾な記事になって本当に申し訳ないのですが、一旦ここで記事をまとめます…。

なんだかよくわからないエラーがDiscord Developer Portalで出てきており、これを解決できませんでした。

（この記事を書いている7/20時点では解決済み）

そのため、期限に間に合いませんでした。

が、期限はもう過ぎましたが経過ごとに追記させていただきます。

7/20（とりあえずベース）
先程の参照記事を参考にセットアップしたところ、取り合えずActivityを再生できるようにしました。
好きなクローラ発表ドラゴン (Scrapy + Playwright)

<B>好きなクローラ発表ドラゴン</B>
![好きな〇〇発表ドラゴン.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/540865/13dcfbd4-044b-f300-cae4-213bb30ef770.png)

# 目次
1. 諸言
2. なぜ好きなのか
3. クローラの辛みに効くScrapy+Playwright
4. 結言

# 諸言
初めまして！株式会社 Panta RheiのCEOです。かずさんと呼ばれているので以後そんな感じでお呼びください。Xのハンネはpandasista(@sotsogprinciple)です。
好きなクローラを発表します。

<B> scrapy </B>  +  <B> Playwright </B>です。

好き好き大好き。

# なぜ好きなのか
## Scrapyが良い
- ORM(SQLAlchemy)を標準装備しており簡単DB接続
    - データフローを構築しやすくパブリッククラウドと相性が良い
    - データ取得を自動化しやすい
- 多種類のWebサイトをクロールを統一の設定で実行できる
    - CookieやCacheなどの多種類の設定をTrueFalseのみで設定
- Middlewareとして多くの途中処理を追加できる
    - データを綺麗にする関数(例: 予想外のHTMLタグの削除)などをデータ取得時なのか、DB格納時なのか、何かの処理を行った後なのか、などデータの処理が柔軟かつ簡単
- 高速軽量！
    - 【高速】 SeleniumやPuppeterなどのクローリングパッケージは(ヘッドレス)ブラウザの利用を前提にしているが、Scrapyはそれがないためブラウザ起因の遅延なし
    - 【軽量】 JSを読まないため, SEO関連やSNS関連のscriptタグを無視。プレーンなHTMLテキストのみが対象なので、画像等のデータを読み込まず！

## Playwrightが良い
- JSを解釈！
    - JSによる動的なコンテンツを解釈できる
- Puppeterより良い
    - 参考資料: https://qiita.com/YusukeIwaki/items/f4616094c5572f1f7d25

## scrapy-playwrightが良い
JavaScriptがゴリゴリなページをクロールしようとすると、Scrapyではデータが取得できないです。「このページだけJavaScriptをexcuteして動的なコンテンツを取得したいなぁ」なんてとき、Playwrightを導入します。ScrapyとPlaywrightの繋ぎこみには```scrapy-playwright```です。

scrapyのspiderでは以下のように実装します。

```Python:spiders/spider.py
from playwright.async_api import async_playwright
class Spider(scrapy.Spider):
    name = "test"
    start_urls = [
        "https://test.test"
        ]

    def start_request(self, response):
        for start_url in start_urls:
            yield scrapy.Request(
                url=start_url,
                callback=self.parse,
                meta={
                    "playwright": True,
                    "playwright_include_page": True}
                )
    def parse(self, response):
        page = response.meta["playwright_page"]
        hoge_url = await page.locator("//div[@class='hogeclass']/a/@href").all()
        item["hogeurl"] = hoge_url
        yield item
```

JSを動かしたいページにscrapy.Requestする際に、```meta```という引数を渡してあげるます。
すると読み込んだページがJSを解釈できるようになります。

## それSeleniumでも良くない?
Seleniumはご存知の通り、E2Eテストやクローラにかなり用いられるパッケージです。が、現在ScrapyのアドオンとしてSeleniumを使うのはベスプラとは言いにくい状態です。
Scrapy上でSeleniumを用いるためのモジュールである```scrapy-selenium```の開発リリースが2019年で止まっています。Scrapyは2020年に大きなアップデート(1系から2系)があり、scrapy-seleniumを使い続けるとそのアップデートの良さみを享受できないことになります。


# まとめ
ScrapyはPlaywrightと合わせるとDB接続が容易で高速でJS解釈できるスーパークローラになるよ！

# 結言
[株式会社Panta Rhei](https://www.pantarhei.co.jp)はデータを用いて、さまざまな事業を展開しています。
- Google Cloudを用いたモダンなデータ収集基盤の構築
- 内製化AIの実装運用
- 企業データベースのAPI連携
などさまざまなソリューションを持っています。
何かお困りごと等ありましたら、ぜひご一報いただければと思います！
文系大学生によるNAIST合格体験記(2024年度)

### はじめに
私は、2024年度(2025年度入学)NAIST情報科学領域に合格しました。受験中、先輩方の体験記にかなり助けて頂いたので今後NAISTを受験する方々の助けになればと思いこの記事を書くに至りました。
### 目次
- NAISTとは
- 事前情報
- 対策期間
- 対策
- 結果
- おわりに
### NAISTとは
NAIST(奈良先端科学技術大学院大学)は奈良県に位置する国立大学院大学です。大学院大学とは学部を持たない大学の指し、他にもJAISTやOISTなどがあります。
NAISTの情報科学領域は書類(50)、数学(30)、英語(30)、小論文(90)の計200点の試験を行なっています。例年、140点後半程度を取れば合格するとされています。また合格者のTOEIC平均は730点、中央値が750点と言われています。
https://www.naist.jp/
https://www.youtube.com/watch?v=oTHVqOt4o9g&t=346s
### 事前情報
- バックグラウンド
私は某国立大学の経済学部に所属しており、B3までは情報系とは無縁の学生生活を送っていました。しかし友人の勧めからプログラミングまたAIに興味を持つようになりました。その後、B3の夏頃に情報系の民間インターンに参加、自分の能力の低さでは社会に貢献できないことを痛感させられました。そこで大学院に進学することを決意し、研究室訪問を行いました。この段階では"研究とは何か"や"自分が何をしたいか"については全く定まっておらず、教授の方々にいくつも指摘いただいたことを覚えています
- GPA　3.5/4.5
### 対策期間
- B3の8月~B4の1月
どこの大学院に進学しようか彷徨っている期間。
- B4の1月~B4の4月
指定教科書の２冊を分からないながら1周しつつ、研究計画を練っている期間(インターンでボツになったけど)。NAISTのインターンに参加することを決意し、志望研究室の教授にコンタクトをとる。
- B４の4月~B4の5月
NAISTのインターンに3週間ほど参加。他の記事でも言及されていますが、非情報系の方は必ず参加した方が良いと思います。ここで研究計画のほとんどを書き終える。
- B4の5月~本番まで
指定教科書をそれぞれ2周し&問題を1chapterごとに５問解いた。
### 対策
#### 数学
strangの線形代数とwangの解析をメインで使っていました。全体の復習を行うためにマセマを読んだ程度。特にstrangの線形代数は内容が本質的で難しいですが、youtubeに上がっている講義動画で全て理解できるようにしました。
自分の際は簡単な証明問題しか出ませんでしたが,SUVやジョルダン標準系等も出題されるようです…
#### 英語
TOIECについては直前に追い込みをかけ、ギリギリで提出しました。※真似しないでください
- 750 (B2の12月)
- 720 (B4の4月) <- 直前にも関わらずかなり低く、落ち込みました
- 800 (B4の5月)

TOEICを800点代に乗せることをイメージしながら参考書を用いて学習しました。特にリスニングは練習次第ですぐに上がるので、リスニングを重点的に対策した方がよいかも?
使用した参考書:
- TOEIC L＆R TEST 990点獲得 Part 1-4 難問模試　［音声DL] , https://www.beret.co.jp/book/46936
- 公式問題集 , https://www.iibc-global.org/toeic/support/prep.html
#### 小論文
先も述べたようにインターンに参加してやっと読めるレベルのものになりました。研究計画を書いたことがない方はインターンに参加することをお勧めします。
ちなみに提出した小論文には重大な誤植があり、みなさんは見直しを行ってから出してください。面接の際に恥をかいてしまいます。
#### 面接
小論文の内容を3分で説明するというものは頻出なのでかなり対策しました。
特に、「なぜこの研究をしたいのか」や「何を明らかにしたいのか」が直観的にわかるような説明を心がけました。また、就活が終わった友達3人に練習を手伝ってもらうことで、専門外の先生方にも理解していただける内容になったと思います。
面接の質問は全て研究に関するものでした。
失敗として聞かれた質問が想定以上に専門的であり、焦りから1つしか答えられませんでした。
### 結果
- NAISTに合格しました。
- JAISTに合格しました。
### 終わりに
NAISTは文系だからと言って合格できないような試験内容ではありません。しかし、理系の方々よりも専門性という観点では大きなハンデがあることも事実です。なので理系の方々が取り扱わない内容、また思いつくことが難しい観点から研究計画を書くことをお勧めします。これからNAISTを受験される方々の健闘を祈ります!
Azure 仮想ネットワークの作成（私の記事共通）

# はじめに
私の方で Azure や AVD に関する記事を多く投稿しています。
その中で、共通で使用している 仮想ネットワークの構成があるため、こちらの記事で外出しして 共通で参照する形とさせていただきます。

# 前提事項
Azure のリソースを作成する前に、Azure サブスクリプション の手配が必要です。
以下の記事で紹介していますので、参照ください。

https://qiita.com/carol0226/items/066c06d95cb68427f1d0

# ネットワーク設計
以下のネットワーク設計を想定して、作業を行っていきます。
名前やアドレスについては、以後 皆さんの環境の情報に読み替えてください。

| # |名称|アドレス|目的|
|:-:|:-:|:-:|:-:|
|リソースグループ|AVD-Environment|－|
|仮想ネットワーク<br>(アドレス空間)|AZ-DefaultVNet|10.10.0.0/16|
|サブネット１|Subnet1|10.10.10.0/24|ドメイン<br>コントローラー|
|サブネット２|Subnet2|10.10.20.0/24|VM<br>セッションホスト|

:::note warn
**陳謝**
10.10.10.0/24 の次に 10.10.10.20/24 を使うなんて、ネットワーク範囲を無駄に消費しているのは、重々承知なのですが、記事を見る上では 10.10.10.0 と 10.10.11.0 を見比べるより見やすいと思うので、ご理解ください <(_ _)>
:::

# 仮想ネットワークの作成手順
0. Azure Portal を開きます。
https://portal.azure.com/home
　<br>
0. **仮想ネットワーク** の画面を開き、**作成** をクリックします。
　<br>
0. **基本** タブでは **リソースグループ** の選択と、**仮想ネットワーク** の指定を行います。
地域（リージョン）は、仮想ネットワーク上に作成する VM が どのリージョンに配置する想定なのかを考えて決めてください。理由は、仮想ネットワークはリージョンを跨げないからです。迷ったら **Japan East** 一択で良いと思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/8a006c97-89de-41c2-1795-73d9baf1391c.png)
　<br>
0. **セキュリティ** タブでは、特に設定すべき項目はないため、**次へ** を押して進みます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d8c3ccaf-6a95-6bc8-2a52-4dae184eee26.png)
　<br>
0. **IP アドレス** タブでは、冒頭の **ネットワーク設計** を想定した場合は、下図のように構成を行います。設定を行ったら **確認 + 作成** を押します。<br><br>サブネットの設定を追加するために、緑枠の **＋サブネットの追加** を押します。変更する場合は、右側の 鉛筆マークを押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/6e8856e7-da5b-6c99-d613-f90783d4ca6b.png)
<br>**サブネットを追加する際は、以下を参考に設定します**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4451b46d-3ecc-a826-b822-ca05108b7bc1.png)<br><br>
0.  **確認および作成** タブで、最終確認を行って **作成** ボタンを押します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/84e94f25-e480-9972-67ed-1b8d7374e9b6.png)

# 本記事の参照元
今後、増やしていきます。

https://qiita.com/carol0226/items/c40de99f11fb1593f26b

https://qiita.com/carol0226/items/2504c08a88a53bb35f2b

https://qiita.com/carol0226/items/635408e1f343ba8bc649

https://qiita.com/carol0226/items/7318fdd7aff780f5177c

# 公開情報

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-overview
Kindleの読書メモをNotionデータベースに投稿するAppleショートカットをつくってみた

## TL;DR
- Kindleのハイライト機能でメモした文章をNotion DBに登録するためのAppleショートカットを作った。
- 本のタイトルも含めてDB登録できるので後で見直したり、検索するのに便利。


## 背景
本は基本的にiPad/iPhoneのKindleアプリを使って電子書籍で読んでます。

気になった文章はハイライト機能を使ってメモしているのですが、Kindleアプリには以下制約があります。
- 全てのメモを一覧表示する機能がない
- メモを検索する機能がない
- Kindle Unlimitedの本は返却してしまうとメモも失われる

というわけで、メモした内容をNotionでDB化できないか考えました。

## 既存のサービスを調べてみた
調べてみたところ、booknotionというドンピシャなサービスを見つけました。
が、無料プランで登録可能なのは月１冊・・・無料では実用に耐えられません。

https://booknotion.site/

一方で、Appleのショートカット機能を使えばNotion APIを利用してデータベースを更新できるということを知りました。

https://note.com/clockcrockwork/n/nd25c6271f88e#c1a3d3bf-8626-4451-9a27-53902f5a5438

これなら自作できそうということで作ってみました。


## Kindleから渡されるテキストの構造

流れとしては、Kindleアプリ上で文章をハイライトして、共有ボタンからショートカットを起動することでNotion APIコールすれば良いはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/2b5c386c-2de0-de25-f8a8-e512e9214a6d.png)

この時、以下のような４行のテキストが共有先に渡されます。

```
XXXXXXXX  #引用文
#空行
XXXXXXXX  #タイトル（出版社）・著者名
XXXXXXXX  #URL
```

というわけで、この４行のデータを元にNotion APIを使ってデータ登録できれば良さそうです。


## Appleショートカットの作成
作成したAppleショートカットについて解説します。

### 1. テキストからデータ抽出

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/f956339d-4fce-e823-ebb6-68a7e76317ec.png)

受け取ったテキストをリスト化して、１行ごとにループします。
ループの際にインデックス（何行目か）を見て、引用文、タイトル、URLを判別し、それぞれの変数に格納します。


### 2. Notion API呼び出し準備

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/646a6b7b-5370-a632-fedc-e6509d881935.png)

Notion API用のトークン、データベースID、データベースプロパティを変数に格納します。
トークン、データベースIDについては、こちらが参考になります。

https://qiita.com/ulxsth/items/3434471ac91f8fa311cf


Notion側のデータベースは、メモ、タイトル、URLの３列からなる構造になっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/98d55d14-4524-d9d3-f0ad-6ae0de298ca4.png)


### 3. Notion API呼び出し準備

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/9c37c050-9341-5e65-1796-fa45fd7855be.png)

「URLの内容を取得」を使用して、Notion APIをコールします。


## 実行結果

ハイライトをシェアする際に作成したショートカットが表示されます。

![スクリーンショット 2024-07-17 14.10.32.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/b208ccdf-41da-da32-d58e-18611d6b71bb.jpeg)


成功すると、このようにNotion DBにメモが登録されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2526943/39211f08-db39-211c-56de-0ddcec139d88.png)


作成したショートカットをこちらにアップしておきました。

https://www.icloud.com/shortcuts/d3e448c1f3824667b9d55fda92f4e564


## まとめ
読書メモをNotionに連携することで、Kindleアプリに頼らずメモを管理することができるようになりました。
もう少し改善できそうなのでトライしてみたいと思います。

今後の改善点

- 本のタイトルと著者名を別々のプロパティに格納できるようにする。
- 本ごとにNotionページを作成して、メモがページ内に集約されるようにする。
ITパスポート データの正規化

・正規化
データの重複や不整合が発生しないように、複数の表に分割する作業

・非正規形
正規化されていない表

・第１正規形
繰返し項目を排除する
計算で求められる項目を排除する

・第２正規形
主キーの一部の項目で一意に決まる項目を、別の表に分離する

・第３正規形
主キー以外の項目で一意に決まる項目を、別の表に分離する
[iOS] Apple Storeのリジェクト、Guideline 4.3(a) - Design - Spamへの対応

# はじめに
iOSアプリの申請をしていてリジェクトがくることも結構あるのですが、大半は審査側があまり良く見ずにリジェクトしているのではないかと思うような内容が多く、チャットで少しやり取りしたり、スクリーンショットを添付して送るとそのまますんなりと申請が通ることが多いです。

今回はリジェクトの対応に少し時間がかかってしまったので、解決法のひとつとしてメモしておきます。

# Guideline 4.3(a) - Design - Spam について
今回受けた上記のリジェクトの全文は以下の通りです。

>Guideline 4.3(a) - Design - Spam
>
>We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences.
>
>Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps.
>
>Next Steps
>
>Since we do not accept spam apps on the App Store, we encourage you to review your app concept and submit a unique app with distinct content and functionality.
>
>Resources
>
>Some factors that contribute to a spam rejection may include:
>
>- Submitting an app with the same source code or assets as other apps already submitted to the App Store
>- Creating and submitting multiple similar apps using a repackaged app template
>- Purchasing an app template with problematic code from a third party
>- Submitting several similar apps across multiple accounts
>
>Learn more about our requirements to prevent spam in App Review Guideline 4.3(a).
>
>Support
>
>- Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module.
>- Consult with fellow developers and Apple engineers on the Apple Developer Forums.
>- Help improve the review process or identify a need for clarity in our policies by suggesting >guideline changes.

要するにもうすでに自分のリリース・ストアに同じようなアプリがあるのでダメですよってことですね。

これ自体は割と良くあるリジェクトで検索するとその対応なども色々と出てきます。
この文章だけだともうすでに同じ機能を持ったアプリはリリースできないのか？とも思えますが、全くそんなことはなく、当然アプリストアに同じような機能を持ったり、デザインも似ている（そもそもレイアウト・デザインパターンなんてそこまでなく、似通ってしまう）ものは多数ありますので、本当に全く一緒に見えるようなもの以外は弾かれないんじゃないかなと思っています。

私自身もこれまでUIが似た別機能のアプリを申請していたのですが今まではデザインスパムのリジェクトを食らったことはなかったです。ただ、AmazonやAppleなど、この手の審査でリジェクトされたときに「前は大丈夫だった」「他のアプリはどうなんだ」と言うのは大抵意味がありません。（もしかしたら不利になることもあるかもしれない）



# 試してみたが今回は解決しなかった方法

- レビュアーへの問い合わせ
ネット上の記事を見るとこれを回避するのに「どの辺が同じか」「どのアプリと同じなのか」などの具体的な理由を聞くとそのままレビューが通ったとの記事がいくつかあったので試してみましたが私のケースではダメでした。
https://qiita.com/nakashimaakio/items/d7e4a446ec83476fac31
https://note.com/nappa7878/n/nc79c6ad00d36  
<br>

- 再提出
これは私自身が良くやるのですが、一旦提出をキャンセルしてそのまま再提出をしてみる。
正確なことはわからないのですが、同じ申請でチャットのやり取りをするのではなく、一度キャンセルするとレビュアーが変わるような気がします（感覚なので正確な情報ではないことを再度留意）
良く言われることですがAppleの申請はレビュアーごとに基準が結構違っていて、すんなり通る人とそうでない人の性激しかったりします。
ですが、何回かキャンセル、出し直し、チャットでお話をしましたが今回はこれでは通過せずでした。
<br>

- App Reviewへの異議申し立て
以下のURLからレビューへの異議申し立てができます。
レビュアーは結構いい加減だったりすることもあるので別口が用意されているようです。
ですが、今回は申し立て後も同じ対応となってしまいました。
https://developer.apple.com/contact/request/app-review/appeal/


# 今回解決した方法
結局チャットだけでは何度やってもリジェクトの堂々巡りになってしまったのである程度の修正を加えることに。

- デザインの軽微な変更
アセットをいつも同じものを使っていたので違うアイコンに変更したり、ボタンの位置を調整したりしました。
その前に背景色の変更をしたりしたのですが、それだけではダメでした。

- 共有機能の追加
簡単に付け加えられて大抵のアプリで使えそうな共有機能、今回は画像を扱うものだったので良くある感じのシェア機能を追加しました。

上記の変更を行うことで申請を通すことができました。

# 最後に
皆さんもリジェクトとうまく付き合い、良いApple Developerライフをお送りください。

以上です。
【備忘録】react-toastifyのトースト表示がおかしい時に確認する

# はじめに
**react-toastify** のトースト表示が添付画像のようになってしまっている時に確認すべきことを記した **備忘録** です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3348923/569c4a99-a86d-5730-5efc-3599f7edb939.png)

# 解決策
・``CSS``をインポートしましょう

```
import "react-toastify/dist/ReactToastify.css";
```

・添付画像のようにちゃんと **トースト表示** されるようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3348923/c233833c-4452-9ed2-2bfc-83f099b3c1df.png)
MySQLで複数テーブルに一度にデータをインサートする方法：ストアドプロシージャの活用

MySQLで複数のテーブルにデータを一度にインサートしたい場合、ストアドプロシージャを活用することで効率的に実現することができます。この記事では、ストアドプロシージャを使用して複数のテーブルにデータをインサートする方法を紹介します。

# ストアドプロシージャとは
ストアドプロシージャは、一連のSQL文をまとめて実行するためのサーバーサイドのプログラムです。ストアドプロシージャを使用することで、複雑な操作を簡単に呼び出せるようになります。特に、トランザクション管理を行いたい場合に便利です。

# 複数テーブルへのデータインサートのための準備
まず、例として使用する2つのテーブルを作成します。

```sql
CREATE TABLE table1 (
    id INT AUTO_INCREMENT PRIMARY KEY,
    column1 VARCHAR(255),
    column2 VARCHAR(255)
);

CREATE TABLE table2 (
    id INT AUTO_INCREMENT PRIMARY KEY,
    column3 VARCHAR(255),
    column4 VARCHAR(255)
);
```
# ストアドプロシージャの作成
次に、複数のテーブルにデータをインサートするためのストアドプロシージャを作成します。このプロシージャは、4つの引数を受け取り、それぞれのテーブルにインサートします。

```sql
DELIMITER //

CREATE PROCEDURE insert_multiple_tables(
    IN val1 VARCHAR(255),
    IN val2 VARCHAR(255),
    IN val3 VARCHAR(255),
    IN val4 VARCHAR(255)
)
BEGIN
    -- トランザクション開始
    START TRANSACTION;
    
    -- 最初のテーブルにデータをインサート
    INSERT INTO table1 (column1, column2) VALUES (val1, val2);
    
    -- 2つ目のテーブルにデータをインサート
    INSERT INTO table2 (column3, column4) VALUES (val3, val4);
    
    -- コミット
    COMMIT;
END //

DELIMITER ;
```
# ストアドプロシージャの実行
作成したストアドプロシージャを呼び出して、複数のテーブルにデータをインサートします。

```sql
CALL insert_multiple_tables('value1', 'value2', 'value3', 'value4');
```
このようにすることで、1回の呼び出しで複数のテーブルにデータをインサートすることができます。

### まとめ
MySQLで複数のテーブルに一度にデータをインサートする方法として、ストアドプロシージャを使用する方法を紹介しました。これにより、データの整合性を保ちながら効率的にデータを管理することができます。ぜひ、ストアドプロシージャを活用してみてください。
受信後に受信者が自分のメールアドレスを送信して検証コードを取得してリンクを開く方法


事前に外部のユーザにアクセス許可をしたファイルを準備します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/0bc88896-c4de-1d88-4285-5ac758dc8282.png)

このファイルのリンクをOutlookで送信するために、Outlookの「OneDrive」をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/38429f12-003c-b78b-42bb-622ad6c090f9.png)

宛先を入力するまでは問題ないのですが、宛先を先程の外部のユーザにしてもリンクがエラーになるんですよね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/beeaed57-3d3d-b3c6-038f-a87d745bca0c.png)

以下をみるとOneDriveのオンラインからリンクしたら、問題なさそうです。

+ [SharePoint Onlineの外部共有機能をつかって脱PPAP](https://mssp.tenda.co.jp/blog/sharepoint/2697/)


共有をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/5ccac970-8638-754f-4db8-411448caca0c.png)

ギアアイコンをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/f9c7b49a-5b59-83b8-c7b5-825dc4cd2bc7.png)

選択したユーザを選んで、適用
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/7892ed27-ce65-6407-6284-9e37f5138873.png)

リンクをコピーをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/a7a4b8b6-fab0-fdeb-63ab-175db37f727b.png)

あれ！！　さっき外部ユーザを選んだんだけど...
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/c1e24678-e1ed-35f9-b28b-038ce39fbd34.png)

ギアアイコンをクリックして既存アクセス権を持つユーザを選択します。
今度はリンクがコピーできました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/e46113ba-ef32-5b85-c3f9-63435388caf1.png)

あれ、ダメですね。送信先を登録するとまたリンクが赤くなった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/bb3c5a49-9cfb-afd8-e874-39111417360f.png)

ギアアイコンをクリックして選択したユーザを選んで、再度外部ユーザのアドレスを入力します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/5b5597ca-959d-b327-bb66-0121c1a197d1.png)

リンクのコピーをクリックすると、ちょっとメッセージが変わったような...

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/eae6d170-8a90-aee1-8aca-08eda3fc04a1.png)

今度はリンクが赤になってないので大丈夫？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/e7eef480-7da6-cc4e-f528-6123fda55d8c.png)

同じパソコンの違うブラウザで開いたけど、パスワードは聞いてこないですね。


スマホで開いたらやっとコード送信の画面が表示できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/c05bdbac-d9c6-ba59-8f64-38833aa83594.png)

リンクのコピーのデフォルトがすべてのユーザなので、注意しないと外部のユーザにも送ってしまいそうです。
どうもこの機能は使い勝手が悪くユーザには進められませんね。

以下のようにパスワードを付与させる方法ならOutlookのリンクボタンから設定しても機能するのでこっちの方法の方がよさそうです。まぁ、パスワードを掛けずに送ったらおしまいですが...

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/b420320e-7908-ecf5-3668-6e3b65459737.png)
【保育士必見！】ノーコードツール"Dify"で子どもの怪我対応に迅速でサポートするよ！



## 保育中に子どもが怪我をしたら・・・ ##

保育士は、怪我の負傷レベルにかかわらず、
**保護者に必ず状況や、怪我への対応**などをお伝えします。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/b33b4709-29d4-d629-10f7-60f637e93098.png" width=70%>



### 保育士さん教えてください！！ ###

怪我の正しい処置の仕方って知っていても
状況に応じて臨機応変を求められる環境の中
その場で自信もって対応できていますか？！

少なくとも私は
**とても不安になりながらも懸命に対応していました**

子どもたちが泣いている状況の中
何か**目安**があると冷静を保ち
今すべき対処に集中するという
迅速な対応ができると思いませんか？

そこで・・・考えました！

### 子どもが怪我をした時の対応を音声でサポートする ###

プロダクトです！！
これは、**VUIとDifyを使って作ることができます。**

→VUI：「Voice User Interface」とは、
　コンピュータと人間のやり取りを声（音声）によって行う操作方式。
 　人間がマイクに発話することで指示したり、システムからの応答を
  　合成音声によって伝達する（あるいはその両方）方式のこと。

まず初めに
**Difyで怪我の対応を教えてくれるチャットボット**を作りました。

### \ ここから使えます / ###

https://udify.app/workflow/m5VgPW9g5u5LaLAO

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/a773b595-3528-0aff-d2ab-8f46d861d3f4.png" width=70%>

textのところから「火傷の処置」を入力すると

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/1d3a4643-e0f4-aaca-0d7d-316f97c1db87.png" width=70%>

**ほんの１秒で具体的な処置の仕方を教えてくれます。**


今回はこのチャットボットの作り方をご紹介します。
（次回は作ったチャットボットをVUIの音声認識技術を使って
　音声でのやりとりで怪我の対応ができるプロダクトを作ります。）


### 保育現場の実情も書いています ###

https://zenn.dev/riyu/scraps/b795c5e515024c



## プロダクトの１歩目を作っていこう ##

### 準備するツール ###

💻**Dify**：https://dify.ai/jp
→　大規模言語モデル（LLM）を使った
　　アプリケーションの開発と運用を簡素化するための
 　　オープンソースプラットフォーム

[ 特徴 ]
**RAGを使用したチャットボットやAIエージェント**
ドラッグ＆ドロップインターフェースを使用した
AIワークフローをノーコードで構築できる


### 作り方 ###


①Difyでログインしワークフローで作成する
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/ba9971f1-b22b-a8dd-ef9f-18dcd634ef87.png
" width=70%>

②GoogleSearchを使うため、
　『承認する』のところからAPIキーを取得する

 ③LLMを選択しChatGPTから選んで設定をする

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/339f2391-645f-0fdf-a0b4-47148e988551.png
" width=70%>

【テキスト内容】

以下の「ユーザーの質問」に対して、
「Googleの検索結果」を用いて回答してください。
「ユーザーの質問」：
「検索結果」：

<br>

④最後終了の設定をする

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/252f3b1d-b1c4-2628-c05f-8f37bb0f3a9e.png
" width=70%>

すると・・・**完成しました！！**

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/97a6a09f-9ebc-7600-cf40-63eb2b1e5da1.png
" width=70%>

## 応用編：自信を持って対応したい人向け ##

先ほど完成したものにLLMのパラメーターを触ることで
より正確で一貫性のある回答が必要な場合に値するために
**Temperatureの部分を変更します。**


<img src="https://storage.googleapis.com/zenn-user-upload/bb536c24c59b-20240717.png
" width=70%>

現在0.7の出力設定になっているのですが
値が低くなっていくと創造性よりも正確性が出てくるようです。
『0.2』に値を変更してみてください。

<img src="https://storage.googleapis.com/zenn-user-upload/c834bf4ecea1-20240717.png
" width=70%>

もし質問ある方はコメントください😊

### perplexityって便利！！ ###

今回調べる時にperplexityを使いました。
とても具体的な作成の流れなども教えてくれるので
現在私の右腕となっております。

ぜひ調べる時には使ってみてくださいね！↓

https://www.perplexity.ai/

## 次回、保育現場に救世主が誕生する ##

冒頭でもさらっとご紹介させていただきましたが
次にやりたいことは

今回作ったチャットボットをVoiceflowというツールを使って
VUIの技術に組み込み、
実際に保育現場でも使えるようなプロダクトになるように
作っていきたいと思っています！！


<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3720831/ba81beb5-0f40-2ac2-a9bf-0ef81cde4cc6.png
" width=70%>

保育士さんたちのより安心できる保育環境のために
プロダクトを作っていきたいです！！
FastBERT: a Self-distilling BERT with Adaptive Inference Time

2020年の論文で少し古いですがやっていることが面白いと感じたのでメモ。

https://arxiv.org/abs/2004.02178

## 概要
モデルの効率的な推論手法にearly exitがあるが、これをBERTに適用した話。(だと思っています)

ポイントはトランスフォーマーブロックって何段も積み重ねているけど、途中までで十分じゃないの？ということ。

## Architecture

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594896/69a89f83-e6e3-170f-6c26-f6e8e1174ac2.png)

一番左のBackboneというのが通常のBERTです。

モデルはBERTの各Transformerブロックに Student Classifier(0~L-2)を付け加えた構成になっています。

図はバッチ推論(バッチサイズ4)の例です。

まず、Transformer 0までを計算し、Student Classifier 0を計算します。

その結果が十分に自信が持てるもの(図のサングラス)であった場合はそれを最終出力としてそれ以降の計算はスキップします。

それ以降は確信が持てなかったものに対して続きのlayerの計算を行って…ということを繰り返します。

最後までStudent Classifierの結果で自信が持てなかった場合は通常通りTeacher Classifierの出力が採用されます。

という流れで自信が持てた段階で以降の計算を行わずスキップするという策をとります。

## 学習方法
以下の流れで行います。
1. BackBone部分のFine-Tuningを行う(Branchは考えない)
1. Backboneのパラメータを固定してBranchの学習を行う

Branchの学習はTeacher Classifierを親とするSelf-distilling(自己蒸留)で行います。

具体的には $i$ 番目のStudentに対し、
Teacher Classifierの出力を $p_t = Teacher Classifier(h_{L-1})$、
Student Classifierの出力を $p_s = Student Classifier_i(h_{i})$ とすると、
```math
D_{KL}(p_s, p_t) = \sum_{i=1}^N p_s(i) \log \frac{p_s(i)}{p_t(i)}
```
をTeacherとStudentの誤差(分布の差)として考えることができます。

損失関数は全Studentについて$D_{KL}(p_s, p_t)$の和を考えて、
```math
Loss(p_{s_0}, ..., p_{s_{L-2}}, p_t) = \sum_{i=0}^{L-2} D_{KL}(p_{s_i}, p_t)
```
とします。

これにより各Student ClassifierがTeacher Classifierに近づくように学習されます。

## 推論時に自信があるかどうかの判断方法
推論時にStudent Classifierの出力結果が自信を持てるものかどうかの判断は以下のUncertaintyをベースに行う。
```math
Uncertainty = \frac{\sum_{i=1}^N p_s(i) \log p_s(i)}{\log \frac{1}{N}}
```
ここでの$N$はラベルのクラス数をあらわす。
Uncertaintyはクラスの予測結果がクラスによって差が大きい場合に小さく、差が小さい場合に大きくなる。

Uncertainty計算例：
![download.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594896/da462280-373c-c905-3d3e-7badb3aef2a5.png)
Uncertainty = 0.28812071961329816

![download.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/594896/f7378e7a-0f9b-6045-9918-e3e546eea211.png)
Uncertainty = 1.0000000000000002

このUncertaintyの値に対して閾値を設け、それ以下ならそれ以降をスキップする。