OmniAICreator/Qiita-1.07M huggingface dataset:
爆速でコードを読む方法

## はじめに
初めまして、学生団体IDEAという団体で副代表を務めているKoderと申します。少し学生団体IDEAの宣伝をさせていただくと「バックグラウンドによらない学習環境を提供する」というVisionの基、活動している団体です。

学生団体IDEAのアドイベントカレンダーも残すことあと2日ということで、今日は爆速でコードを読む方法に焦点を当ててお話しさせていただきます。

## ソースコードを読むことの重要性
プログラミングにおいて、ソースコードを効率的に読むことは非常に重要です。プロジェクトの理解、バグの特定、また新しい技術の学習において中心的な役割を果たします。また、コードを読む能力は、効率的なチームワークとコラボレーションにも不可欠です。そんな日常コード読む行為を爆速で効率化することができた場合、成長間違いなしですよね？(多分)


## 先に結論
先に結論からお話しさせると、ChatGPTのプラグイン「Ask Your Code」を入れる。これがシンプルかつ僕が思う一番のソリューションです。

## Ask your codeとは
「Ask Your Code」は、ソースコードの解析と理解を助けるために設計されたChatGPTのプラグインです。このツールは、特定のコードセグメントの機能や目的を問い合わせることができ、またコード内の特定のパターンやアルゴリズムに関する説明を提供します。これにより、コードの理解が深まり、効率的な学習と問題解決が可能になります。


## 何ができるの？
「Ask Your Code」は、ソフトウェア開発におけるコード理解とナビゲーションを支援する革新的なツールです。プログラミングにおける複雑なコードベースの解析にしばしば直面する開発者にとって、このツールは貴重なリソースとなります。

開発者が新しいプロジェクトに参加する際、膨大なコード量とその複雑さに直面することは一般的です。このような状況で「Ask Your Code」を活用することにより、特定の関数の機能や変数の使用箇所など、コードの特定の要素に関する迅速かつ正確な情報を得ることができます。

## 具体例
どんな感じで、使うのかが分からないと思うので具体例を持ってきました。これは初めてのソースコードをキャッチアップする場面は下記のように聞くと物凄くキャッチアップが楽になります。 ディレクトリ構造 > ファイル単位 > 関数　といったように粒度の大きいものから聞いていくとどのような処理をされているかがすんなり理解できます。

<details><summary>ディレクトリについて聞いた場合</summary>

「live-coding」プロジェクトのディレクトリ構造と主要なファイルは以下の通りです：

ファイル拡張子: このプロジェクトには、.css、.js、.md、.prisma、.ts、.tsx の拡張子を持つファイルが含まれています。

ルートファイル:

```
/.gitignore
/middleware.ts: config などの変数が含まれ、authMiddleware を使用しています。
/next.config.js: nextConfig という変数を定義し、config モジュールを使用しています。
/postcss.config.js
/README.md: 「Getting Started」、「Learn More」、「Deploy on Vercel」といったセクションが含まれています。
/tailwind.config.js
/tailwind.config.ts: config という変数が含まれ、Config を使用しています。
/types.ts: Member、NetServer、NextApiResponse、Profile、Server、Socket などのさまざまなタイプを使用しています。
関連するサブディレクトリ:

/components: 100% の関連性
/app: 44% の関連性
/lib: 12% の関連性
/hooks: 9% の関連性
/pages: 9% の関連性
/prisma: 1% の関連性
```

</details>

<details><summary>/componentsについて聞いた場合</summary>


「live-coding」プロジェクトのディレクトリ構造と主要なファイルは以下の通りです：

ファイル拡張子: このプロジェクトには、.css、.js、.md、.prisma、.ts、.tsx の拡張子を持つファイルが含まれています。

ルートファイル:

```
/.gitignore
/middleware.ts: config などの変数が含まれ、authMiddleware を使用しています。
/next.config.js: nextConfig という変数を定義し、config モジュールを使用しています。
/postcss.config.js
/README.md: 「Getting Started」、「Learn More」、「Deploy on Vercel」といったセクションが含まれています。
/tailwind.config.js
/tailwind.config.ts: config という変数が含まれ、Config を使用しています。
/types.ts: Member、NetServer、NextApiResponse、Profile、Server、Socket などのさまざまなタイプを使用しています。
関連するサブディレクトリ:

/components: 100% の関連性
/app: 44% の関連性
/lib: 12% の関連性
/hooks: 9% の関連性
/pages: 9% の関連性
/prisma: 1% の関連性
```

</details>

</details>

## まとめ
みんなAskYourCodeを使おう！
まぁ、この記事もアドカレに間に合わないから、AI利用して爆速で書いてるんですけどね…

メリー苦しみます
日本語プログラミング言語の話題に否定のコメントをいきなりしてくる方がいらっしゃるのはなぜか考察してみた

# はじめに

日本語プログラミング言語の話題に否定のコメントをいきなりしてくる方がいらっしゃるのはなぜか考察してみました。

# 結論の制約
この結論はあくまでわたしの仮設です。この仮説を裏付けるファクトを収集できるほど広い範囲のシステム開発現場を知りえる知見はなく、そのような心理学的な実証研究もないので、あくまでわたしがこれまで経験した現場ならありうるだろうという推察半分の結論です。

# 結論
脳がバグっているからです。

## 結論の論拠
もう少し具体的には、ソフトウェアに関連する仕事の現場では、ソフトウェアを直接生産する実装言語の他に、当該のソフトウェアに関連する内容を表記した言語情報に接します。それは日本の場合、多くは自然言語の日本語です。

自然言語の日本語でソフトウェア的な事柄を不自然に記述されると、厳密な構造の記述の構築を要求される実装担当者はかなりイラっときます。

**ソフトウェア技術者は潜在的にこのネガティブな感情を「日本語」というワードに紐づけて脳が認識してしまっている**と十分考えられます。

そのため、日本語で書かれたプログラミング言語に嫌悪感が顕在化するというのは、心理学的には合理的な考察と考えられます。

# おわりに
これはポジティブな感情にも起こりえる状態で、最近の心理学ではこのような状態も「脳がバグる」と表現しているのは、ソフトウェア関連技術者としては興味深いです。

# 参考情報

[バグる脳 ---脳はけっこう頭が悪い ディーン ブオノマーノ amazon.co.jp](
https://www.amazon.co.jp/%E3%83%90%E3%82%B0%E3%82%8B%E8%84%B3-%E8%84%B3%E3%81%AF%E3%81%91%E3%81%A3%E3%81%93%E3%81%86%E9%A0%AD%E3%81%8C%E6%82%AA%E3%81%84-%E3%83%87%E3%82%A3%E3%83%BC%E3%83%B3-%E3%83%96%E3%82%AA%E3%83%8E%E3%83%9E%E3%83%BC%E3%83%8E/dp/4309252737)
nginx の設定ファイル

## nginxの設定ファイル

```bash:/etc/nginx/sites-enabled/default
server {
    listen 80;
    server_name site1.mydomain-name.net
    location / {
        proxy_pass http://127.0.0.1:5000;
    }
}
```

```bash:/etc/nginx/sites-enabled/default
server {
    include include.txt
    listen 80;
    server_name site2.mydomain-name.net
    location / {
        root /var/www/site2;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        include      snippets/fastcgi-php.conf;
    }
    location ~* \.cgi$ {
        root /var/www/site2;
        fastcgi_split_path_info ^(.+\.cgi)(/.*)$;
        include fastcgi_params;
        fastcgi_index index.cgi
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/var/run/fcgiwrap.socket;
    }
    location ~* \.png$ {
        root /var/www/site2
    }
}
```

```bash:/etc/nginx/include.txt
    location ~* \.html${
        root /var/www/site2;
    }
    location ~* \.jpeg${
        root /var/www/site2;
    }
    location ~* \.jpg${
        root /var/www/site2;
    }
```
もっと他にいい方法がありそうだが、これで一応動くのでヨシとする。
カスタムエラーメッセージ要素を試す

# はじめに

今回は Winter '24でリリースされた`カスタムエラーメッセージ`を試します。

https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_create_custom_error_messages_in_record_triggered_flows.htm&release=248&type=5

# カスタムエラーメッセージとは

Winter '24 の時に追加された要素で、
`カスタムエラーメッセージ要素`を通った場合のユーザー側に表示されるエラーメッセージをフロー作成時に決められるというものです。

![取引先_カスタムエラー-V1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/3ad8ca87-1d38-20d5-20d7-b56a35125b67.png)
![スクリーンショット 2023-12-23 18.39.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/cf91bc56-a737-8454-f4e4-63226cd4fa91.png)

# 使ってみる

挙動確認のため分岐でいくつかのパターンのカスタムエラーを試します。

![スクリーンショット 2023-12-23 18.46.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/9682d1f1-1a0c-cae9-8b2e-f712cb9ef9cf.png)

## レコードページのウィンドウ

![スクリーンショット 2023-12-23 19.10.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/bb0764f2-8d1a-b47b-16b9-ff45d9377eb8.png)

### 表示

- レコードページ
    - **設定したエラー内容**

## 項目のインライン、レコードページ同一のエラー表示2つ以上

`エラーメッセージを表示する場所`が同一の設定が複数だと保存できません。

![スクリーンショット 2023-12-23 18.51.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/44f32649-e360-c4d3-20d5-6919249540ab.png)

![スクリーンショット 2023-12-23 18.49.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/ec494ae0-5417-0daa-ac3c-c255df2d3c11.png)

## 項目のインラインエラーのフォーマット

`{設定したエラーメッセージ}: {エラー対象項目の表示ラベル}`

## 項目のインラインエラー：エラー数1

### 設定

![取引先_カスタムエラー-V1 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/fd2bfbba-c9b6-7bde-8cc9-dd0ef7d85f0b.png)


### 表示

- レコードページ
    - どの項目でエラーがあったか
- 項目のインライン
    - **設定したエラー内容**

が表示されました。

![Edge-Communications-取引先-Salesforce (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/5fb060c2-9411-8e66-689c-66deef645ce2.png)

## 項目のインラインエラー：エラー数2（レコード+項目のインラインエラー）

![取引先_カスタムエラー-V2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/97d682e7-090f-1059-badf-ea789b255ed9.png)

### 表示

- レコードページ
    - どの項目でエラーがあったか
    - **設定したエラー内容**
- 項目のインライン
    - **設定したエラー内容**

![Edge-Communications-取引先-Salesforce (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/376a180c-7e27-cc02-d2ff-a18c6c6d1f16.png)

## 項目のインラインエラー：エラー数2以上（レコード+項目のインラインエラー複数）

項目のインラインエラーの対象にする項目が別々であれば`エラー数2以上（レコード+項目のインラインエラー複数）`で設定できます。

![スクリーンショット 2023-12-23 19.07.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/9d9e51a3-2a81-bc08-bbe6-873a743e0f6d.png)

### 表示

- レコードページ
    - どの項目でエラーがあったか
    - **設定したエラー内容**
- 項目のインライン
    - **設定したエラー内容**

![スクリーンショット 2023-12-23 19.06.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/445600/77215374-d088-ca6f-1d30-b3b6e4e12eef.png)

# 最後に

`カスタムエラーメッセージ要素`について試してみました。
レコードトリガーフローは便利ですが、Salesforce利用者の見えてないところで動いているので
レコードを作成したり、更新したりして突然エラーがくる→よくわからないメッセージ
というのが今までありました。

そこで`カスタムエラーメッセージ要素`を使うことでユーザーにどこでなぜエラーが起きているかを伝えることができます。システム管理者目線でもエラー報告を受けた際にわかりやすいメッセージだと調査が楽ですね！

積極的に今後も使っていこうと思います。
MisskeyでBotを作ってみる

## 参考

https://misskey-hub.net/ja/docs/for-developers/bot/

## アクセストークンの発行

Misskeyの`設定>API`から、アクセストークンの発行を押し、必要な権限を設定して、アクセストークンを発行します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3589058/8e7b7d01-c0a4-4dcd-432d-e79d3f0a6a36.png)

今回は「ノートの作成・削除」の権限のみ付与しておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3589058/f1acba58-d1fd-3066-ce76-7cb2a954e846.png)


アクセストークンが発行されるので、コピーして保存しておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3589058/6ebfca6f-8efc-21b0-f0eb-b92d35c90920.png)

### 参考

https://misskey-hub.net/ja/docs/for-developers/api/token/#%E8%87%AA%E5%88%86%E8%87%AA%E8%BA%AB%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%82%92%E6%89%8B%E5%8B%95%E7%99%BA%E8%A1%8C%E3%81%99%E3%82%8B

## Node.js環境で叩いてみる

使いたいMisskeyのapi-docを確認してみます。

例: https://misskey.io/api-doc

今回はツイート(notes/create)をしてみます。
https://misskey.io/api-doc#tag/notes/operation/notes/conversation


```js/index.js
  const url = "https://misskey.io/api/notes/create";
  const data = {
    i: "さっき保存したアクセストークン",
    text: "ツイートしたい内容",
  };

  await fetch(url, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(data),
  });

```

```sh
$ node index.js
```

これで無事、MisskeyにNode.js経由でツイートできるはずです。
メモリを知ろう！~RAM・ROM~

# はじめに
structとclassの違いについて勉強している時、ヒープ領域・スタック領域は、プログラム中で一時的に使用するメモリのことで、RAM上の領域として割り当てられるということを知りました。
基本情報技術者試験とかで聞いたことあるけど、**RAMって何**という疑問が出てきたので、調べてみました！　　　　　　　　　

# 主記憶装置(メモリ)とは
主記憶装置はCPUから直接アクセスできる記憶装置のこと。
CPUはメモリのアドレスを指定して、データを読み込んだり書き込んだりする。
メモリにはRAMとROMの2種類ある。
# RAM
RAMとは、「Random Access Memory」の略称で、日本語に訳すと**自由に読み書きができるメモリ**です。主に、パソコンやスマートフォンに搭載されている作業用のメインメモリを指す。高速なデータアクセスと一時的なデータ保持能力を持つ。電源を切ると、データが消えるため、一時的なデータのみを保存する。**この性質を「揮発性」という。**
そこで、電源を切った後も継続的に保持する必要がある情報については、HDDやSSDなどの補助記憶装置に保存する。
# ROM
ROMとは、「Read Only Memory」の略称で、日本語に訳すると**読み取り専用メモリ**です。保存されているデータだけを読み込むことができるメモリで、書き込むことは基本的にできません。
コンピュータの基本的な動作情報が格納されている。書き換えることができないため、永続的な情報を保存するのに適している。
電源を切っても、データが失われず、データを保持し続ける。**この性質を「不揮発性」という。**

# 補助記憶装置とは
主記憶装置（メインメモリ）以外の外部記憶装置のこと。
# HDD/SSD
HDDはデータを永続的に保存することが可能。RAMのようにデータを書き換えることはできるが、電源を切ってもデータはそのまま保存される。大量のデータを保存できるのもストレージのメリットですが、RAMと比べるとデータの読み書きの速度は遅いのが欠点。
SSDは、HDDの遅さをカバーし、より高速なデータ処理を実現することができる。
# はじめの疑問の解決
RAMは、「システムが動作中に任意に書き換える可能性があるデータ」を格納する場所。プログラムが使用する変数データだけではなく、スタックメモリ・ヒープメモリなどもRAM上の領域として割り当てられる。

# 参考文献

https://nlab-notebook.com/entry/dram-sram-kind-of-ram#toc2

https://nlab-notebook.com/entry/kind-of-rom

https://www.foresight.jp/fe/column/main-memory/

https://uquest.tktk.co.jp/embedded/learning/lecture11.html
TI-Python でタートルグラフィック

# はじめに

TI-Python でタートルグラフフィックする方法について紹介します。

# タートルグラフックのためのモジュールをインストール

TI-84 Plus CE Python の TI-Python は標準でタートルグラフィック機能を提供していませんが、アドオンモジュールが TI から提供されています。

[ここ](https://education.ti.com/nl-be/product-resources/turtle-module/ti84ce-python)から `CE Python Turtle Getting Started.zip` をダウンロードしてきて展開します。

展開されるファイルから次の２つのファイルを TI Connect CE のファイル一覧画面にドラッグ＆ドロップするだけでインストール完了です。

* GRID.8xv
* TURTLE.8xv

# プログラミング

エディタ画面で `Fns...` のキーを押し、`Modul` 一覧から `Add-On` を選びます。 

![Capture1-1703325013350.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/cc433f3e-4f8a-cea0-279c-bd5e3b2c001b.png)

`turtle` モジュールのインポートがありますので、選択します。

![Capture17-1703325306328.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/b70b521a-3938-f7fd-a63a-0ecbe6cf1fcb.png)

エディタ画面に反映されます。オブジェクトの作成までやってくれています。

![Capture2-1703325369687.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/4421f920-8fc9-db06-5e45-bde07a4f1acd.png)

正方形を描いてみましょう。４辺あるので４回の繰り返しを用意します。

`Fns...` の `Ctl` 一覧から `for i in range(size):` を選びます。

![Capture3-1703325472904.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/69259e14-5856-620e-9422-b0554362fce4.png)

エディタ画面に反映されるので、`size` 指定のところに 4 を入力します。

![Capture5-1703325600446.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/13a01a75-c497-3779-7f48-df2543991c8b.png)

続けて `Fns...` の `Modul` 一覧から `turtle` を選びます。

![Capture6-1703325699162.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/76130e25-5b97-1e43-3e1e-e5d2dee2c44b.png)

`t.forward(distance)` (前進)を選びます。

![Capture7-1703325753145.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/4653fb03-0117-f4c4-c8f9-5c9e34c25650.png)

エディタ画面に反映されるので、`distance` として 100 を入力します。

![Capture11-1703325829244.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/5006f247-e03b-cf77-fd26-f06199078fb5.png)

同様の操作で `t.left(90)` （反時計方向に90度回転）と `t.done()` (描画終了)を入力します。

![Capture12-1703325980420.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/6d670ffd-b627-61ac-0412-5b645a787f99.png)

ここまでできたら、後は`Run` するのみです。正方形を描画していく様子を見ることができます。

![Capture15-1703326022813.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106817/635d6594-b7cc-ded4-fcc2-093661d5400f.png)
AWS CopilotでenvごとにDockerfileを動的に変える

この記事は **[リンクバルアドベントカレンダー2023](https://qiita.com/advent-calendar/2023/linkbal)** の24日目の記事です。

昨日は @furuyu_kasago さんの記事です！

https://qiita.com/furuyu_kasago/items/312d178adb4a9534a87c


## はじめに
[AWS Copilot](https://aws.github.io/copilot-cli/ja/)で、envごとにDockerfileの内容を変えたいことってありますよね？

例えば、フロントエンドの静的ファイルをビルドするDockerfileで、ビルド時に必須な環境変数を、環境ごとに異なる値にしたいときなど。
この場合は、Serviceの `manifest.yml` で `variables` や `secrets` を `environments` で環境ごとに設定しても、ビルドされた静的ファイルには `variables` や `secrets` の値は反映されていません。
なぜなら、これらの値は、起動したECSタスクに設定されるもので、Dockerのビルドはcopilotコマンドを実行したマシン上で行われるからです。

こういったときに、envごとにDockerfileの内容を動的に変える方法を紹介します。

 
## 結論
`image.build.args` を使いましょう！

公式ドキュメントはこちら。
リンク先はLoad Balanced Web Serviceですが、他のServiceタイプでも使えます。

https://aws.github.io/copilot-cli/ja/docs/manifest/lb-web-service/#image-build

## Dockerのargsとは
言葉のとおり、Dockerfileに渡す引数です。

例として以下のDockerfileで試します。

```docker:Dockerfile
FROM alpine:latest

# --build-arg オプションの値がHOGEとFOOに代入される
# 右辺は引数が与えられなかったときに使われるデフォルト値
ARG HOGE=hoge_value \
  FOO=foo_value

# ARGの値を環境変数に設定
ENV HOGE=${HOGE} \
  FOO=${FOO}

CMD echo ${HOGE}, ${FOO}
```

`docker build` の `--build-arg` オプションで使えます。

```sh
# --build-arg 未指定でビルド
$ docker build -t arg-sample-image .
# 略
$ docker run --rm arg-sample-image  
hoge_value, foo_value # 未指定なので Dockerfile のデフォルト値が入っている

# --build-arg を指定してビルド
$ docker build -t arg-sample-image . --build-arg HOGE=input_value --build-arg FOO=input_value2
# 略
$ docker run --rm arg-sample-image
input_value, input_value2 # 指定した値が入っている
```

公式ドキュメント

https://docs.docker.com/build/guide/build-args/

docker composeでも使えます。


## AWS copilot の `image.build.args` の使い方
さきほどのDockerfileの例だとすると、HOGEとFOOは `--build-arg` の値で柔軟に変えられます。

`manifest.yml` の例

```yaml:copilot/frontend/manifest.yml
name: frontend
type: Load Balanced Web Service

image:
  build:
    context: ./frontend
    dockerfile: Dockerfile
    args:
      TARGET_ENV: ${COPILOT_ENVIRONMENT_NAME}
      HOGE: default_hoge # prod環境用の値だとする
      FOO: default_foo # prod環境用の値だとする
  port: 80
  healthcheck:
    command: ["CMD-SHELL", "curl -f http://localhost:8001/ || exit 1"]
    interval: 10s
    retries: 2
    timeout: 6s
    start_period: 10s

# 略

# 環境ごとに固有の値で上書き
environments:
  dev:
    image:
      build:
        args:
          HOGE: dev_hoge # dev環境用の値を指定する
          FOO: dev_foo   # dev環境用の値を指定する

  stg:
    image:
      build:
        args:
          HOGE: stg_hoge # dev環境用の値を指定する
          FOO: stg_foo   # dev環境用の値を指定する
```

このファイルだと、`copilot svc deploy -n frontend -e dev` などの実行時のdocker buildコマンドは、次のようになります（多分）。

`$ docker build --file Dockerfile --build-arg HOGE=dev_hoge --build-arg=dev_hoge ./frontend .`


## ユースケース
環境ごとに以下を変えたいときなどにどうぞ。

- 参照するディレクトリ
    - 例えば、AppacheやNginxのIP制限/許可対象ファイルのディレクトリ
- パッケージマネージャーのコマンドのオプション
- FROMのイメージ

## 注意点
Dockerのレイヤーキャッシュが効かないことがあるかもしれないと、どこかで見た気がします。
※気がするだけで、ソースは探してません


## おわりに
おわり
Jetpack Composeで画像使用時に気をつけたいこと

# はじめに
今回はJetpackComposeでの実装直近で直面した画像使用時に気をつけたいことを紹介します
### 本文
今回時分が直面したのはIconとImageの違いです
Imageはpainterリソースに設定したものそのまま反映されますが、Iconを使ってしまうモノクロになってしまいます。
使う画像が単色のの場合はtintを設定すれば色を変えれるのでIconでも問題ないですが、単色じゃない場合はImageじゃないとダメです
何気なく使ってると不意直面してしまうので注意が必要です
### 最後に
今回は直近で自分直面した小さな気付きを記事にしました
どなたかのお役に立てれば幸いです
Angular のテスト環境事情を調べてみた。

この記事は、[Angular Advent Calendar 2023](https://qiita.com/advent-calendar/2023/angular) 23 日目の記事です
22 日目の記事は [@seapolis](https://qiita.com/seapolis) さんの [2024年から始めるAngular Universal (SSR) の本番運用](https://zenn.dev/seapolis/articles/6669b3c1cda5b0)でした。

## 今回のテーマ

皆さん、ユニットテストや E2E テスト書いていますか？
テストライブラリの EOL や Deprecated に気を使ってる方も多いと思います。
今回は、今年自分がテスト関連で気になった事を紹介していきたいと思います。

## ユニットテスト

Angular 標準のユニットテストといえば、Karma, Jasmine だと思います。
ここ数年で、Jest に移行された方も多いと思います。

### Web Test Runner について

2023.04.28 に下記記事がポストされました。
超ざっくり要約は、下記の通りです。

- Angular チームは、複雑でスケーラブルなアプリケーションの構築にはテストが不可欠と考えており、特にAngular ユニットテストに関する不満があり、それを改善するために Jest と Web Test Runner のサポートを導入することが発表された。
- Angular v16 では Jest の初期実験的サポートが提供されるが、まだ本番環境での使用はお勧めされていない。
- Web Test Runner もサポートされ、 Jasmine と統合して Karma のセットアップに近いテスト体験を提供する予定。
- 開発者調査では、Angular ユーザーのテスト満足度が低いことが明らかになり、改善の必要性が強調されている。
- Angular は Karma への感謝を表明しつつ、Jest と Web Test Runner が Angular エコシステムにポジティブな影響を与え、ユニットテストの体験向上が期待されている

https://blog.angular.io/moving-angular-cli-to-jest-and-web-test-runner-ef85ef69ceca

ユニットテストの実行時間が課題になっている方も多いと思います。
開発体験が上がることを期待したいですね。

Angular v17 になったので、Jest 環境も良くなっていると思います。

## E2E テスト
### Protractor について

2023.09 月に正式サポートが終了されました。

https://blog.angular.io/protractor-deprecation-update-august-2023-2beac7402ce0

既に Protractor から Cypress を導入・移行されている方は多いと思います。

### Cypress について

Cypress の状況は良くないようです。
場合によっては、予め違う選択肢を模索したほうが良さそうです。

https://javascript.plainenglish.io/cypress-io-is-dying-8a22757fe68f

https://zhiminzhan.medium.com/exit-strategy-for-cypress-testers-c951f26f6b04

https://javascript.plainenglish.io/a-follow-up-for-my-article-cypress-io-is-dying-after-3-months-a8b7fdda234c

他の E2E ツールだと、下記の候補があると思います。

### Playwright

https://playwright.dev/

Playwright の場合、Protractor からの[マイグレーション手順](https://playwright.dev/docs/protractor)が既にあるので、安心ですね。

### TestCafe

https://testcafe.io/

今回知りましたが、[@politie/angular-testcafe-builder](https://www.npmjs.com/package/@politie/angular-testcafe-builder) が Deprecated なっているようなので、今すぐは選択しないほうが良さそうです。

### Puppeteer

記事を書いている所に GDE の [Jecelyn Yeen](https://medium.com/@jecfish) さんが、 Puppeteer 記事を投稿して下さいました。

https://blog.angular.io/introducing-puppeteer-schematics-test-your-angular-apps-with-ease-dea6947f6299

[@puppeteer/ng-schematics](https://pptr.dev/integrations/ng-schematics) を使うことで E2E テストも有効のようです。

Puppeteer v21.6.0 の[最新リリース](https://pptr.dev/next/webdriver-bidi)で、WebDriver BiDi サポートにより、Firefox だけでなく Chrome でもクロスブラウザ自動化に Puppeteer の機能を活用できるようです。
非常に楽しみですね。


### まとめ

ユニットテストの将来は Web Test Runner が Angular の標準になると思います。
ng update を使ってのマイグレーション手順が出るまで待っても良いと思います。

E2E テストについては、[Jecelyn Yeen](https://medium.com/@jecfish) さんが、 Puppeteer を紹介されていることから、こちらに注目したほうが良さそうです。

明日 24 日は、我らが朱いちゃん（[@ver1000000](https://qiita.com/ver1000000)）です！
乞うご期待！
結局 async と defer のどっちを使えばいいのか

HTML のパフォーマンスを考える時、 `<script>` タグを用いたスクリプトの読み込みを最適化することが多々あります。`<script>` タグに指定する属性には主に `async` と `defer` がありますが、調べた限り日本語の多くのサイトでは詳しい比較がなされていなかったので書きました。

## script タグの読み込みに関わる属性

画像を引用します:

![](https://i.stack.imgur.com/qHAVc.png)

- https://stackoverflow.com/questions/13821151/can-you-use-both-the-async-and-defer-attributes-on-a-html-tag/68929270#68929270
- https://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html

### 無属性または `blocking` を指定

`<script>` タグが出現した時点で HTML のパースを中断し、スクリプトをダウンロード・実行します。DOM の読み込みが中断されるため、避けるべきです。

### `defer` を指定

`<script>` タグが出現すると HTML のパースとスクリプトのダウンロードを並行して行います。HTML のパースが終了するとスクリプトを実行します。複数のスクリプトがある場合 HTML に記述された順に実行されます。

### `async` を指定

`<script>` タグが出現すると HTML のパースとスクリプトのダウンロードを並行して行います。スクリプトのダウンロードが終わった時点で HTML のパースを中断してスクリプトを実行します。複数のスクリプトがある場合でも実行順は保証されません。

### `type="module"` を指定

スクリプトをモジュールとして読み込みます。デフォルトで `defer` と同じ挙動、`async` を指定すると `async` と同じ挙動になります。

## `async` と `defer` のどちらを使うか

上の図を見るとスクリプトの実行終了までにかかる時間は同じように思えます。日本語の多くのサイトではこれをもとにどちらでも変わらない、もしくは `defer` のほうが `DOMContentLoaded` を待つため無難とされていますが、複数ファイルの場合この解釈は間違いです。(`DOMContentLoaded` を待つ必要があるならばイベントリスナを設定すべきです)。

例えば HTML が次のようにスクリプトを読み込んでいるとします。

```html
<script src="script1.js" async></script>
<script src="script2.js" async></script>
<!-- または -->
<script src="script1.js" defer></script>
<script src="script2.js" defer></script>
```

`defer` の場合 `script1.js` のダウンロード終了が `script2.js` のダウンロードと HTML のパースより遅いと `script1.js` のダウンロード終了と実行を待つ空白の時間が発生します。一方 `async` を指定した場合は `script2.js` が `script1.js` を待たず先に実行されます。すなわち `defer` の場合は `script2.js` の実行時間分だけ読み込みにかかる時間が長くなります。

したがってできるだけ `async` を使ったほうがスクリプトの実行が早く終る可能性があります。ただし `script1.js` がグローバルに定義したオブジェクトを `script2.js` で使う場合など、ファイルの依存関係がある場合は `defer` を用いる必要があります。

### 判断基準

できるだけ `async`、難しいなら `defer`、最悪の場合無指定 (`blocking`) にすべきだと考えられます。

- `document.write` を使用する場合、無指定 (`blocking`) にする
  - そもそも `document.write` を使うべきではない
- スクリプトごとに依存関係がある場合 `defer` を用いる
  - CDN のライブラリがグローバルにオブジェクトを作る場合など
  - できればモジュール化してスクリプトから `import` を使うなど他のファイルへの依存をなくしたい
- `async` を使う
基本情報うけてみた

この記事は海洋大技術系サークルAdvent Calendar 2023 の24日目のものです！
## 初めに
この記事では、僕が応用情報技術者試験に落ちたのちに基本情報を受けた時のことについて結果とその詳細について書いていけたらなと思います。

自己紹介については　[こちら](https://qiita.com/Doragon-RH/items/b2177b8e705de131fbfb)

## 前提条件
前提条件ですが、私は情報系の大学に通う２年生(受験時点)であり、応用情報の対策をある程度行ったのちに受験しています
参考：　https://qiita.com/Doragon-RH/items/1e00fd6da78f570c2178

上記記事にも書かれていますが、１度応用情報に落ちてしまった私は非常に燃えました。燃え滾っていました。なので、やる気がすさまじかったことも前提条件です

上記のように非常にやる気に満ち溢れていた私はすぐにでもリベンジした意欲が出てきてしまい、応用情報技術者試験を受験してから１か月後に設定しました。
(CBT方式で受験しています)
## 学習方法
応用情報を受けて、その結果から上記の記事で書かれている結論に到達した僕は、まず基本情報の過去問を１回分受験してみました。

結果としては、科目A:65% , 科目B: 公式の公開しているサンプル問題は全問正解でした(科目Bは、問題が大幅に変更されたのちに公式が非公開にしたため、試験で使用された問題は載っておりません)

この結果を受け、おそらく合格できると感じましたが、応用情報のことがあるので慢心せず、徹底的に過去問を解きまくりました:muscle:

使用したサイトは、おなじみの基本情報技術者試験過去問道場です

基本的に大学の授業の空き時間など、とにかく暇を見つけては過去問を１問１問丁寧に対策を続けました。

１日の学習時間は平日は２時間・休日は５時間程度行っていたと思います。

このように学習し、試験直前では、科目A：75% (それまでに解いたことのない過去問１回分の結果)でした！
## 結果
結果は以下の通りです


何とか無事に合格できました！

本番の科目Aは過去問で解いた時より難しく感じ、正直受けてる最中は受かるか落ちるか内心ドキドキしながら解き進めていきました

科目Bについては、情報系の学部ということもあり、最初の10問くらいは特に簡単だと思ってしまいました。
こちらは問題を解いている最中に12問以上正解していると確信できたので勝ちを確信しました笑

結果が後日来るのかなと思っていたので、試験をすべて解き終わり、スクリーンに自分の点数がぱっと表示された時は何が何だかわからず、混乱しました笑

しかし、自分の点数であるとわかるとやり切った感が感じられてめっちゃよかったです！

## 終わりに
今回しっかりと合格でき、私としても非常にほっとしています。もし落ちていたら、応用情報含め完全にやる気がなくなるところでした笑

このように状況としては少し特殊な部分はありましたので、あまり参考にならないかもしれませんが、大体の感覚が伝わればよいかなと思います。

また、これからさらに勉強して応用情報へのリベンジへとつなげていきたいと思います！
ngrokでローカル環境をネット公開する

# はじめに
この記事は[プログラミングスクールRUNTEQ](https://runteq.jp/?utm_campaign=school&utm_source=google&utm_medium=named_buying&utm_term=&utm_content=jissouryoku&argument=8Y0vPq40&dmai=a615edff6e9c0c&gad_source=1&gclid=Cj0KCQiAm4WsBhCiARIsAEJIEzXn70e5GVyxePK4Cosrr4Rr4gq_5Kds8dtIjDcvPknEfRumrpljkxMaAjMDEALw_wcB)の[AdventCalendar2023](https://qiita.com/advent-calendar/2023/runteq) 23日目に参加しています。

11月から晴れてエンジニアになることができました。
入社してからngrokで苦戦したので備忘録にまとめておきます。

# [ngrok](https://ngrok.com/)とは
自身のローカル環境を、インターネット上にアクセス可能にするツールです。
なので、まだプルリク投げていない段階の開発状態を、他者のPCでも見られるようにできます。
macOS, Windows, Linuxにも対応しています。

:::note info
開発環境
- Macobook M1 Pro / Sonoma 14.2
- ngrok version 3.5.0
:::

# インストール
[公式サイトからユーザー登録](https://dashboard.ngrok.com/user/signup)します。
その後、ガイダンスに沿ってコマンドを実行しましょう。

```ruby:Homebrew経由でngrokインストール
brew install ngrok/ngrok/ngrok
```

```ruby:認証トークン追加
ngrok config add-authtoken **********
```

```ruby:ローカルポート80へドメイン転送
ngrok http 80
```

```ruby:URLが生成される
ngrok                                                                                                                                        (Ctrl+C to quit)

Build better APIs with ngrok. Early access: ngrok.com/early-access

Session Status                online
Account                       your_name (Plan: Free)
Version                       3.5.0
Region                        Japan (jp)
Latency                       -
Web Interface                 http://127.0.0.1:4040
Forwarding                    https://***-***-***-***.ngrok-free.app -> http://localhost:80

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00
```
「Forwarding」欄に、毎回新しい`https://***-***-***-***.ngrok-free.app`が生成されます。
ここにアクセスして、「Visit Site」を実行、無事表示されたらOKです！
他の人にもこのURLを共有すればアクセスしてもらうことができます。

# ログインが弾かれる場合 （Ruby on Railsアプリ）
ngrokを使用すると、ローカル開発環境に対して新しい外部ドメインが割り当てられます。
このドメインの変更は、セッションやCSRFトークンの検証プロセスに影響を与える可能性があり、ログインが弾かれることがあります。
もし弾かれた場合、[protect_from_forgery](https://railsguides.jp/security.html#%E5%BF%85%E9%A0%88%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3)を`SessionsController`や`ApplicationController`に追記します。
各リクエストに対して一意のセキュリティトークン（CSRFトークン）を生成してくれるので、ログインを正常に処理してくれます。

# おわりに
以上になります！
プログラミングスクール生の時は、自分の開発環境を自分で操作しながら、相手に画面共有して見せていました。
しかし、ngrokでURLを渡せば、自分と複数人の相手が別々の操作をすることができます。
もし便利そうだなと感じた方は、ぜひ使ってみてください。
Proxmoxのインストール時にネットワーク設定を飛ばしてしまった時。

## これば備忘録です。
N100搭載のミニPCを買ったので、Proxmox使ってみようと思い、
インストールをした際、
とりあえずWIFI接続でもいいかなと思ってしまったため、
インストール時のネットワーク設定を飛ばしてしまいました。

あとから設定を変えるとなると色々面倒で、
再インストールするほうが簡単でした。
猛省。
応用情報技術者試験受けてみた

この記事は海洋大技術系サークルAdvent Calendar 2023 の23日目のものです！
## 初めに
この記事は情報系の大学に通って1年と少し経った頃に受けた応用情報技術者試験の結果とどのような対策をしてきたか・また反省について書いていきたいと思います。

自己紹介については　[こちら](https://qiita.com/Doragon-RH/items/b2177b8e705de131fbfb)　から

## 学習方法
次に、学習方法です。
私の学習方法とその問題点、こうしたらよかったということを書いていきます

#### 前提条件
まず前提条件についてですが、情報系の大学で1年程度学習し、アルゴリズム・物流の知識はある程度身に付いた状態から学習を始めています。

#### ～試験2か月前？まで
言い訳になってしまいますが、大学2年の前半ではまだ授業が忙しく、夏休みに入るまで授業以外の対策はほとんどできませんでした

#### ～試験1か月前まで
このころは大学が夏休みに入り、ある程度まとまった時間があったため１日に2時間程度学習を進めました！

主に使用した教材は、応用情報技術者試験合格教本平成26年版です！

#### ～試験２週間前
このころは、大学が試験期間となり、再び応用情報の勉強は中断し、大学の試験勉強に専念しました。

#### 試験直前まで
応用情報技術者試験過去問道場でひたすら過去問を解き続けました！
(試験勉強時間は１日に４時間程度になります)

試験直前の過去問道場の正答率は62%前後でした
(受かる見込みは感覚で60%程度であると考えていました)

## 結果について
もったいぶってもしょうがないと思いますので、結果について発表した後反省点・改善すべきことについて話したいと思います。

結果としては下の通りです。

![スクリーンショット 2023-12-23 181728.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3620480/8250f373-c04c-2a2a-da63-8402124cdfe9.png)

## 反省・改善案
ここから、私の考える改善ポイントについて話していきます。

#### 教科書はざっくりとでよい！
これはあくまでも私の意見ですが、教科書に載っている内容は非常に細かく、内容量も膨大なものになっています。さらに、試験内容の60%は過去問を少しだけ変えたものであるという情報もあります。(参考: www.itec.co.jp/wp-content/uploads/shiken/2021s/2021s_ap_comment.pdf)

そのため、そのすべてを覚えていこうとするのではなく、過去問演習を主に行い、頻出の内容や、出てきた知識をその都度覚えていくという学習方法がよいと思いました。(私は試験が近づいてからそれに気づいたため、もっと早くから過去問に集中していればよかったと思いました)

#### まずは過去問を見るべし
これはどのような試験においても共通していることだと思いますが、ある試験を受験しようとしたとき、最初に過去にどのような問題が出題されていたかについてみたのちに対策をするべきであると思います。これができていなかった私は、実際の問題でどのように知識が使用されているかわからなかったため、学習効率が落ちてしまったと考えられます。

これらを踏まえてきちんと対策を行っていれば、合格できていた可能性は十分にあると考えています。
## 終わりに
いかがでしたでしょうか。この記事がこれから受験する方々に少しでも参考になり、合格する上での手助けになれば幸いです。(受験費用が7500円と馬鹿にできない金額ですし)

さて、今回は不合格という結果で終わってしまいましたが、もちろんこのまま終わるつもりはありません。2024年春季で必ずリベンジを果たしていきたいと考えています！
初めてのGoland

# はじめに
新卒2年目のエンジニアです。
この記事では、GolandというIDEの個人的に使いやすいと感じた点についてまとめていこうと思います。
もし、Go言語を使用して何かアプリケーションを制作したいという方のお役に立てればと思います。
ちなみにこの記事は、[株式会社アクティブコアAdvent Calendar](https://qiita.com/advent-calendar/2023/activecore) 16日目の記事になります。
# Golandとは
簡単に言うとVSCodeのようなIDEです。
基本的には以下がデフォルトで使用可能であり、その他の言語を使用するにはプラグインを入れたり、All ProductPackを購入する必要があります。
* Go
* HTML
* JavaScript
* TypeScript
* SQL(RDBMS)

ちなみにGolandは有償のツールですが、2年目以降はディスカウントがされるため、個人的にはお得感があります。
また、30日間のトライアル期間があるため、一度試してから購入を決めることをおすすめします。

# Golandを使用してて便利と感じた箇所
記載した部分について、VSCode等でもプラグインやそもそも入っている機能もあるかもしれませんが、そこはノーコメントでお願いします。

### Githubとの連携がしやすい
* Github関連の操作がしやすい
  * マージがしやすい
  右下にあるブランチ名をクリックし、ブランチのリストが見えます。
  そこからチェックアウトしていないブランチのプッシュを行ったり、現在のブランチをマージしたり逆に現在のブランチを該当のブランチにマージすることも可能です。
  * シェルフ機能が緊急の差し込みタスクがある場合にとても役立つ
   シェルフ機能というまだコミットしていない保留中の変更を一時的に保存する機能がとても便利です。
   * PRが見やすい
       現在出ているプルリクエストを確認でき、レビューをGoland上で行えます。
       変更されていないフラグメントを折りたたむこともできるので、変更箇所のみを確認することも処理の流れを確認することも簡単にできます。
* SQL操作がしやすい
    * DBeaverのように、視覚的にDBの参照や更新ができる
    視覚的にENUM型の値を確認したり、テーブル構成等を確認したり、レコードのINSERT/UPDATE/DELETE等を簡単に行うことができます。
    また、実行前にプレビューを見ることもでき、どのようなSQL処理を実行しようとしているかの確認もできます。
    * SQL文の実行が簡単
        `Ctrl`+`Enter`でSQLファイルの中で指定した範囲のSQL文を実行することができます。
* ファイルを跨いで一括修正が可能
    `Ctrl`+`Shift`+`R`にてファイルを跨いで文字列を置換することができます。
    また、`Ctrl`+`Shift`+`F`でファイルを跨いで文字列を検索し、検索タブでの文字列修正をすることも可能です。
    変数を右クリックして「リファクタリング」→「名前の変更」の順に押していくと該当の変数を使用している箇所含めて変数名を一括で変更することができます。
# まとめ
   色々Golandの個人的な便利箇所についてまとめてみました。
   VSCodeや他ツールでもプラグインいれたり新たなツールを別に導入すれば同じことももちろんできますが、Golandはデフォルトで上記のような機能があるので、試しに一度使用してみてはいかがでしょうか。
Next.js13でmetadataのtitleをpathを参照して動的に変更しようとしたけど無理そうだった

## やりたかったこと
以下の要領でパスごとに柔軟にページタイトルを変更させようとしました。

| パス | ページタイトル |
| ---- | ---- |
| / | サイトタイトル |
| /articles | 記事一覧 - サイトタイトル |
| /article/[id] | [idに紐づく記事のタイトル] - サイトタイトル |

### 脳内実装イメージ
ここら辺を参考にしました。

https://nextjs.org/docs/app/api-reference/functions/generate-metadata#generatemetadata-function

https://nextjs.org/docs/app/api-reference/functions/use-pathname

こんな感じの実装で良いかな～と考えてました
```どこかの共通コンポーネント.tsx

// Next13以降用意されたMetadata上書き関数
export async function generateMetadata({ params }) {

  // 現在パス名を取得
  const pathname = usePathname()

  // カスタムフックでパス別に適切なタイトルを生成
  const title = useBuildPageTitle(pathname, params)

  // 上書きしたい部分をreturn
  return {
    title: title,
  }
}
```

usePathnameをインプットに、動的にgenerateMetadataメソッドのreturnを設定するイメージです。しかし・・・

![cap1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3654730/a08ffae8-589e-7aca-6865-22c19c59dfe6.png)

>The metadata object and generateMetadata function exports are only supported in Server Components.
メタデータ オブジェクトと generateMetadata 関数のエクスポートは、Server Components でのみサポートされています。
>>https://nextjs.org/docs/app/api-reference/functions/generate-metadata#generatemetadata-function

![cap2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3654730/f0ab5d1d-f46b-920c-0e4e-5c8e4a350668.png)

>Reading the current URL from a Server Component is not supported. This design is intentional to support layout state being preserved across page navigations.
サーバーコンポーネントからの現在のURLの読み取りはサポートされていません。この設計は、ページナビゲーションをまたがるレイアウト状態の保持をサポートするための意図的なものです。
>>https://nextjs.org/docs/app/api-reference/functions/use-pathname

metadata上書き用のgenerateMetadataメソッドはサーバサイドでしか使用できず、逆に現在パスを取得するためのusePathnameメソッドはクライアントサイドでしか使用できない仕様でした・・・。

### 妥協した実装
```app/layout.tsx
export const metadata: Metadata = {
  title: {
    template: '%s - サイトタイトル',
    default: 'サイトタイトル',
  },
}
```

```app/articles/page.tsx
import { Metadata } from 'next'
 
// 各page.tsxにハードコーディングしていく
export const metadata: Metadata = {
  title: '記事一覧',
}
```

```app/article/[id]/page.tsx
import { Metadata } from 'next'

type Props = {
    params: { id: string }
}

// 各page.tsxにハードコーディングしていく
export async function generateMetadata(
    { params }: Props
): Promise<Metadata> {

    // 記事IDを取得
    const articleId = params.id
    
    // ～略～ params.idを使用して記事データを取得
    
    // 取得したデータから記事タイトルを取得
    const articleTitle = response.title

    return {
        title: articleTitle,
    }
}
```

ドキュメントからのほぼコピペですが、実装は上記のようになりました。

usePathnameでgenerateMetadataの挙動を制御できないため、ドキュメントにあるように、各page.tsxごとに静的にgenerateMetadataメソッドのreturnを設定する必要があります。

共通化して動的にせず各page.tsxにtitleをreturnするためのコードを書く必要があるのは正直かなり気になります・・・。

## おわりに
Nextはv13でかなり大きな変更がありました。
ネットに落ちているv12までのコードは動かないことがままあります。
今回の実装も、ネットからコードを拾ってきて10分もあれば動作確認できるだろうとたかをくくっていたところに思わぬ落とし穴がありました・・・。
Nextはドキュメントをしっかり読む力が養われるので、チャレンジし甲斐のあるライブラリだと感じました（無理やりいいように表現）。
量子コンピュータ初学者の理解(2)

NTTデータ先端技術株式会社の原田です。

この記事は量子コンピュータ初学者の学習による理解を記載したものです。
何分初学者ですので明らかに間違った内容があったりすると思いますが温かく流していただければと思います。

前回の記事は[こちら](https://qiita.com/koutaro_harada/items/4bc1cf36e324c4bfbf64)。

## 量子コンピュータの今
まずいわゆる一般的な製品としての量子コンピュータがある訳ではなく、さらに製品化への具体的なマイルストーンもまだ見えてはいません。
ので量子コンピュータを売るビジネスを語れる状況にはなく、ぶっちゃけて言うと筆者の所属する SIer 産業に取ってのノックアウトファクター。

が量子コンピュータの得意技的なものは見え始めていて (かつこれから研究がどんどん進むので)、将来実用化された際に当てはめるユースケースはいろいろ出てきている。
つまりこのユースケースを独占的に握っておくことで将来製品化が追い付いたときにブレイクスルーを迎えることができる、そんなビジネスモデル (≒妄想) だと認識しました。
この点は古典コンピュータの場合はどうだったかは改めて学んでみようかと思います。

## 日本の今
[量子未来産業創出戦略](https://www8.cao.go.jp/cstp/ryoshigijutsu/230414_mirai_gaiyo.pdf) にて 2030 年の目標として、

* 国内の量子技術の利用者を1,000万人に
* 量子技術による生産額を50兆円規模に
* 未来市場を切り拓く量子ユニコーン

が挙げられています。
で資料はひと通り読んでは見たものの情報量が多い上に複数要素がフラットに記載されているので正直よくわかりませんでした。何となくわかったのは、産学官で言うと中心 (お金使えるのは) は「学官」で我々のような「産」は呼ばれていくみたいな感じなのかなと。
違う方向から見ると資金力のある産は自分たちでやってしまうと言う良くあるスキームなので、量子コンピュータ中心に国家的なパラダイムシフト的なものはなさそうです。
ただワールドワイドでは活発な投資が行われていますので、腕に自信があれば個人レベルでのし上がっていけるんだと思います。

## 量子アニーリング
量子コンピュータとひと言で言っても複数の方式があり、そのうち前回の記事のベースは量子ゲート方式で他に量子アニーリング方式があることを知りました。

この量子アニーリング方式の説明にはイメージが掴めるところがあり、

1. 量子ビット間に相互作用を定義する
交差点に他の車両がいる場合は自分は侵入しないという定義 (ビットAがnの場合はビットBはnにはならないって感じでしょうか？)<br><br>
2. 量子ビットに磁場をかけて重ね合わせ状態にする
超並列計算の状態<br><br>
3. ここから磁場を弱めていくと最終的に最適解が観測される
条件を絞っていく過程

と言う振る舞いが為されるとのことです、何故最適解に落ち着くのかは量子力学の謎ですがプロセスは理解できました。
また同様のプロセスで最適解に至るモデルをリバースするとユースケースが出てくるというイメージもなんとなく掴めました。
あと超電導使うんですね、ここも量子コンピューティング実用化の技術的な壁かと思います。

## Azure Quantum
今回実際に触るところまでは間に合いませんでしたが Azure Quantum について見てみましたので要点を軽く記載しておきます。

* サクッと試せそうなコードとシミュレーターが用意されている

https://learn.microsoft.com/ja-jp/azure/quantum/get-started-azure-quantum

* 何と Copilot がある

https://news.microsoft.com/ja-jp/2023/06/23/230623-accelerating-scientific-discovery-with-azure-quantum/

* 費用
計算方法はわかりづらい、$500 の無料クレジットがあるようなのでその範囲で使ってみます。

https://learn.microsoft.com/ja-jp/azure/quantum/pricing?tabs=tabid-AQcredits%2Ctabid-AQcreditsPasqal%2Ctabid-AQcreditsQ%2Ctabid-AQcreditsRigetti

* Q# と言う独自言語がある
Python の方が多数派だろうし良いと思うけど…<br><br>

* 量子アニーリングプロバイダーはない？
Amazon Braket にはあるみたい。


## 量子コンピュータの未来
量子コンピュータのブレイクスルーのタイミングはやはりハードウェアもしくは仮想化技術に依存するんだと思います、画期的なユースケースはどんどん出てくると思いますがコスト対効果の観点で実用化には及ばずまだ試験研究の時期が続くのでしょう。
ビジネス的には投資フェーズと言うこともあり資金力のある産の近くでないと触れる機会がないのは問題ですが、個人レベルではコミュニティと言う選択肢があるようです。

ポイントは「ブレイクスルーが起きたときには既に量子コンピュータの事を知っている」と言う状況に自らを置けるかという点になるんでしょう。
ただ量子コンピュータ以外にも同じような未来が描かれるテクノロジーはあるのでどれを選ぶかは難問です、量子コンピュータだけ取ってもユースケースを見るかテクノロジー (ライブラリ開発など) を見るかと言う選択肢もあるので…。

## おわりに
前回の「じゃあ自分はどうする？」については、ひとまず Azure Quantum (合わせて Copilot も) を触ってからコミュニティに参加してみようかと思います。
あと全2回の予定でしたが Azure Quantum の体験レポートであと1回か2回増えるかもしれません。
2年間1人アドベントカレンダーをやって選んだ、おすすめSymfony Component 5選

[Symfony Component Advent Calendar 2023](https://qiita.com/advent-calendar/2023/symfony-component)の22日目の記事です。

[2022年](https://qiita.com/advent-calendar/2022/symfony-component)、[2023年](https://qiita.com/advent-calendar/2023/symfony-component)と2年間、1人アドベントカレンダーをやってきました。延べ49個のSymfony Componentを紹介してきました。
アドベントカレンダーの最後に、独断と偏見で選んだおすすめSymfony Componentを紹介します！

## 1. Symfonyといえばこれ、 "Dependency Injection"

1つめはDependency Injectionです。DIやオートワイヤリングによる自動注入を提供します。Symfony以外でも使えますが、Symfonyではほぼ何も考えずともこの恩恵を受けられます。Symfonyを使う理由の1/3くらいはこのコンポーネントにあると言えます。

そんな[Dependency Injection](https://qiita.com/ippey_s/items/2e279486e1114272a570)、この1年でさらに使いやすくなっており、`#[Autowire]`アトリビュートでのパラメータや環境変数のDI、`#[Autoconfigure]`アトリビュートなどを使った遅延機能など、進化が止まりません。ぜひ、Symfonyとともに体験して欲しいコンポーネントです。

https://qiita.com/ippey_s/items/2e279486e1114272a570

https://qiita.com/ippey_s/items/c5c7a3e0a9e6150c1fa6

## 2. 使いこなせば状態管理が超楽ちん、 "Workflow"

続いては[Workflow](https://qiita.com/ippey_s/items/e7fe47ea88fd5679b03e)です。状態を管理し、次の状態への遷移やチェックなどを行います。

実はこのコンポーネントは使ったことがなく、このアドベントカレンダーをきっかけに使うようになったコンポーネントです。このコンポーネントを使えば、『Aの状態だったら。。BとCの状態だったら。。』みたいなif文やswitch分地獄や、知らないところでの飛び級状態遷移を防ぐことができるので、おすすめです。

https://qiita.com/ippey_s/items/e7fe47ea88fd5679b03e

## 3. 新しいSymfonyのフロントエンド、 "Symfony UX"

3つ目は[Symfony UX](https://qiita.com/ippey_s/items/fa19147cc4ff1e91ead8)です。正確には、これは１つのコンポーネントではなくコンポーネント群になります。

このコンポーネントでは、JavaScriptを書かずにフロントエンドのUXを向上させることができますが、JavaScriptにPHPで作ったデータを渡しやすくなったというところも、Symfonyの新しいフロントエンドの開発体験を向上させるなと思っています。TwigComponentは特におすすめです。

なお、SymfonyはこのSymfony UXを通して、[Stimulus](https://stimulus.hotwired.dev/)を使うようになりました。

https://qiita.com/ippey_s/items/fa19147cc4ff1e91ead8

https://speakerdeck.com/ippey/narubekujavascriptwoshu-kanaide-symfonynouiworitutinisuru-symfony-ux

## 4. Webpackから脱出か？、 "AssetMapper"

4つ目は[AssetMapper](https://qiita.com/ippey_s/items/0dcf924a28b21b530df3)です。AssetMapperは画像やJSをロードするものです。

3つ目で挙げたSymfony UXですが、去年までは[Webpack Encore](https://github.com/symfony/webpack-encore)という、Webpackを使うためのコンポーネントが必須でした。ところがこの１年でAssetMapperが登場し、現在はWebPack EncoreとAssetMapperのいずれかを使えばSymfony UXが使えるようになりました。

今後のSymfonyのフロントエンドの構造が変わる可能性を秘めたコンポーネントになっています。

https://qiita.com/ippey_s/items/0dcf924a28b21b530df3

## 5. 外部サービスとの連携に、 "Webhook" & "RemoteEvent"

最後は[Webhook](https://qiita.com/ippey_s/items/2bac555da5edad6f0748)と[Remote Event](https://qiita.com/ippey_s/items/6a5280be5011135bcdfa)です。このコンポーネントは外部サービスと自身のサービスとのイベント（webhook）を簡単に行えるようにするコンポーネントです。

現在のWeb開発において、外部サービスを使う機会はとても増えました。その外部サービスと連携するためのWebhook開発にとても有効なコンポーネントになっています。このコンポーネントはSymfony 5.3からなのでまだ事例が少ないのですが、今後たくさんの事例や、Webhookコンポーネントの他サービスへの対応が進んでいくと思われます。

https://qiita.com/ippey_s/items/2bac555da5edad6f0748

https://qiita.com/ippey_s/items/6a5280be5011135bcdfa

## 完走した完走

というわけで、2年にわたりSymfony Componentの魅力について、紹介しました。さすがに2年、12月はほぼ毎日記事を書くというのはきつかったですが、記事を書くにあたって自分も使ったことがないコンポーネントを調べたり試したりできて楽しかったです。**でも来年はやらない**。

このような素敵なコンポーネントの多くはSymfony以外でも使えますが、Symfonyではさらに簡単に使うことができます。Symfony Componentももちろんですが、Symfony自体もぜひ体験してもらえたらと思います！

https://symfony.com/
Power Queryをどう学ぶか

# 1. Power Queryはノーコードツール

Power Queryに書かれた書籍や記事は、ほとんどGUIの操作について書かれています。大体のことは、GUI出できてしまいます。

従って、GUIの操作１つ１つを解説する書籍や記事を読めば、何となく使えるようになっていきます。

しかし、実際に問題にぶつかった時、どの方法を使って良いのかわからない、あるいは良くない選択をして行ってしまう場合がでてきます。GUIだけでは、実装機能が制限されてしまい、非常に非効率的な処理を行ってしまうことがあります。

# 2. Power Queryはローコードツール

そこで、Power Queryの詳細エディタを開いて、コードを書く方法を覚えることが重要になってきます。

しかし、Power QueryのM言語について学ぶには、参考になる日本語の書籍は見当たりません。英語のドキュメントにを読むことに不安だったりします。いざ、プログラミングを行っても、エラーばかりでなかなか進まなかったり、覚えることが多すぎて手に負えないと感じるでしょう。

M言語は、関数型言語です。VBAなどのような手続き型言語とは、動作の仕組みが異なっています。

# 3. Power Queryは関数型言語

関数型言語は、以下のような特徴があります。
1. 関数型言語は、変数の状態を変更しないので、信頼性が高い
1. 関数型言語は、関数を他の関数の引数や戻り値として使うことができる
1. 最適化が十分に機能する

習得するには、まず基礎となるデータ型について学ぶ必要があります。その後、関数の基礎を少しずつ身につけるようにします。

最初から完璧を求めるのではなく、まずはGUIで作成されたコードを見て、変更してみるなどから始めるのが良いでしょう。

# 4. Power QueryはETLツール

ETLとは、データベースなどに蓄積されたデータソースから必要なものを抽出（Extract）、目的に応じて変換（Transform）、データを必要とするシステムに格納（Load）することを指します。

抽出では、可能な限り少ないソースを利用するよう設計するのが理想です。

変換では、目的とするデータの構造となるよう、フォーマットの変換、構造の変更、意味的変換、重複排除、並べかえなどを行います。

そして、最後に取り込みを行います。

# 5. データの取り扱い

データがどこから来たのか、正確に把握しておくことが大切です。データの品質を示す、明確な基準を持っていなければ、出来上がったデータの信頼性が保証できません。

また、どの様に変換したのか把握しておくことも大切です。正しい手順で変換されたのか、第三者が検証できる必要があります。

そして、元のデータを直接変更することは避けなければなりません。変換前のデータが再取得可能になっていないと、変換後の検証ができません。また、変換作業に問題があったり、変更する場合、やり直すことが難しくなります。

# 6. 変換後のデータ構造

変換作業を通して、どのようなテーブルを作成するかは、すべての作業を通して非常に重要な問題です。

正規化されていないデータは正規化したり、正規化されたデータは非正規化する作業があります。

ファクトテーブルやディメンションテーブルの知識は、最低限必要です。そして、スタースキーマというデータ構造についての理解を進めてください。

---
# 学習用リソース

## 1. Power Queryはノーコードツール

https://learn.microsoft.com/ja-jp/training/modules/automate-data-cleaning-power-query/

https://learn.microsoft.com/ja-jp/power-query/power-query-ui

https://learn.microsoft.com/ja-jp/power-bi/transform-model/desktop-query-overview

## 2. Power Queryはローコードツール

https://learn.microsoft.com/ja-jp/powerquery-m/quick-tour-of-the-power-query-m-formula-language

## 3. Power Queryは関数型言語
https://learn.microsoft.com/ja-jp/powerquery-m/power-query-m-language-specification


## 4. Power QueryはETLツール

https://learn.microsoft.com/ja-jp/power-query/power-query-what-is-power-query

https://learn.microsoft.com/ja-jp/training/modules/clean-data-power-bi/

## 5. データの取り扱い

https://learn.microsoft.com/ja-jp/training/paths/prepare-data-power-bi/

https://learn.microsoft.com/ja-jp/power-query/best-practices

## 6. 変換後のデータ構造

https://learn.microsoft.com/ja-jp/power-bi/guidance/star-schema

https://learn.microsoft.com/ja-jp/training/modules/modern-analytics-data-modeling/
画像処理分野の基礎単語

# この記事の想定読者
画像処理を始めて行う人、画像処理についてこれから勉強を始める人 

## はじめに

画像AI研究に関わる中で、最初に何につまづいたというと、「用語」でした。
Webシステムを開発する中では聞いたことのない単語に溢れていて、急に宇宙に連れてこられたのかと思いました。

みなさんは私みたいに急に宇宙に連れて行かれることないように、地球で勉強しましょう。

### 頻出単語
| 用語名 | 意味 |
| -- | ------ |
| 矩形検出　| 四角形を検出する|
| 射影変換　| 斜めになってる写真を正面に向くようにキュッとするときなどに使います |
| ニ値化 | 白と黒の2色に変換すること |
| グレースケール | グレーのグラデーションを254階調で表したもののこと |
| ノイズ除去 | 光の加減などにより、どうしても点々と入ってしまうノイズの除去 |
| OCR | 光学文字認識 |
| AI-OCR | AIを用いた光学文字認識 |
| ガンマ補正 | カメラやディスプレイなどの機器によって出力される画像が、人間の目で見たときに適切な明るさや色味になるように補正する | 
| HSV | 色相(Hue ) 彩度(Saturation )明度(Value・brightness) |
| パーセントタイル | 計測値の分布（ばらつき）を小さい数字から大きい数字に並べ変え、パーセント表示すること |

## おわりに
この辺りの単語を知っておけば、話にはついていけるかなと思います。
画像AIの分野は、精度との戦いであり、発想の勝負であり楽しくも大変な世界でした。
画像AI分野の初心者向けの記事でした！
asnc/awaitが難しすぎるから少しだけ整理してみた【後編】

## はじめに
この記事は、プログラミング初心者が非同期処理について考える以下の記事の続きです。
先にこちらをご覧ください。

https://qiita.com/odendayoko/items/db811001573055da12f0

https://qiita.com/odendayoko/items/7788b886ba4c6ad87814

https://qiita.com/odendayoko/items/b632c4652a58130c04aa

ここまで長かった…
毎日非同期処理について考えていました。これで最後です！！

### asyncの復習
昨日の復習です。

:::note info
- asyncキーワードを使って関数を定義することで、その関数は非同期処理を含むことをコードを読む人に示すことができる。
- asyncで囲んだ関数の返り値は必ずPromiseインスタンスになる
- asyncで囲んだ関数の中でawaitが使える
:::


## await
asyncを使用することで、その関数内で await を使って非同期処理を行うことができます。awaitをつけると、**右側(右辺）の非同期処理が完了するまで次の処理は実行されません。**
具体例で確認します。
```javascript
async function fetchData() {
  // 何かしらの非同期処理を行う
  const response = await fetch('https://api.example.com/data');
  const data = await response.json();

  // 非同期処理の結果を使った後続の処理
  console.log(data);
}

// 非同期関数の呼び出し
fetchData();
```
fetchは引数に渡したパスに対してHTTPリクエストを送信する非同期関数です。通常であれば、リクエストを送ってレスポンスが返ってくるのを待たずに、次の行が実行されます。

fetchの前にawaitをつけると、fetchの処理が完了するまで待ち、最後まで完了したら次の行を実行させることができます。上から下へ順番に実行されるのでソースコードが読みやすくなります。

この待つという概念について詳しく説明します。
awaitはPromiseインスタンスの状態が、Pending（保留中）からFulfilled（成功）またはRejected（失敗）に変わるまで、その場で非同期処理の完了を待ちます。

次の章でPromiseインスタンスの状態について解説します。
## Promiseの状態
Promiseインスタンスは、pending、fulfilled、rejectedという３つの状態を持ちます。

- pending：処理が終わるのを待っている状態(初期状態）
- fulfilled：処理が成功した状態
- rejected：処理が失敗してしまった状態

`const response = await fetch('https://api.example.com/data');`
これを例に考えると、`fetch('https://api.example.com/data')`が実行されるとき、実行時点ではPromiseインスタンスの状態は`pending`ですが、`resolve()`が実行されれば状態は`fulfilled`に、`reject()`が実行されれば状態は`rejected`に変わります。

おそらくfetch関数の内部的に、HTTP通信のエラーコードによってresolve()を実行するか、reject()を実行するかの分岐が行われているのだと思われます。

イメージを考えてみました。ネットショッピングで例えてみます。
- 注文した時、状態はpendingです。
- 出荷・配送などの準備している時間が非同期処理です。
    - 全ての準備が問題なく完了し、商品が届けば成功です。状態はfulfilledに変化します。
        - =>成功した場合はおでかけします。
    - 準備中にどこかで問題が発生し、壊れた商品が届いてしまったので失敗です。状態はrejectedに変化します。
        - =>失敗した場合はクレームを入れます。

![スクリーンショット 2023-12-23 17.23.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3537832/04047d46-ebd2-3e49-4420-f76e0167bf42.png)

awaitはPromiseの状態が変化するまで、一時停止して非同期処理の完了を待ちます。
awaitの右辺のPromiseの状態がfulfilledとなった場合は、resolve()の引数がawaitの返り値となります。

一方、awaitの右辺のPromiseの状態がrejectedとなった場合は、その場でエラーをthrowします。エラーが発生したことを非同期処理の外に教えてくれるということです。エラーを感知できるなら、例外（エラー）が起こる可能性があるときに使って、エラーが起きた時にどうするかを書ける`try...catch構文`が使えます。


## エラーハンドリング
try...catch構文を使った例外処理（エラーハンドリング）はかなりスッキリ書くことができます。
`someAsyncOperation()`が失敗した場合、エラーが起きたことが伝わり、catchブロックに書いたエラー処理が実行されます。
```javascript
async function myAsyncFunction() {
  try {
    const result = await someAsyncOperation();
    // resultを使った処理
  } catch (error) {
    // エラー処理
  }
}
```

## async/awaitのまとめ
:::note 
- awaitをつけると右側の非同期処理が完了するまで次の処理は実行されない
    - =>上から下へ順番に実行されるからソースコードが読みやすい！
- awaitしたいときは、その関数をasyncで囲う
    - =>そういう決まりだから覚える
- asyncで囲んだ関数の返り値は必ずPromiseインスタンスになる
    - =>then/catchメソッドが使える
- awaitした非同期処理が失敗したらエラーを外に伝える
    - =>そのエラーをtry/catchで捉えられる
:::

## 終わりに
非同期処理、Promise、async/awaitと順を追ってまとめてきましたが、あまりにも難しすぎる。
全く理解できている気がしない…
実務で使う時に、調べた内容を思い出して実際に何が行われているのか？を意識しようと思います。
積読を減らすコツ

# はじめに

　積読はとても楽しいものですが、たまにプレッシャーになります。知識を得ないまま金銭と空間が圧迫されるので、「なんだか損しているかも」という気分になりがちです。

　そこで、今回は「積読を減らすコツ」について記事にしました。

 :::note info
良い手法があり次第、情報追記予定です。
:::

# 積読を減らすコツ

## 読書だけをする時間を確保する

　やっぱり、これが一番です。1時間単位では無理でも、10〜30分毎日スキマ時間を利用して読書を進めるだけで、「余った時間に読もう」と考えている時とは進捗が雲泥の差になります。

　例えば、荷物にならない電子書籍に移行して通勤時間や休み時間に読むなど、「誰にも邪魔されず読書をする時間」を決めてしまいましょう。

## 周りに買ったことを宣言する

　宣言をすることで、目標達成率が上がる「宣言効果」というものがあります。実際にやることを明確化することで、行動に移せるようになります。

　また、「前言っていたあの本読んだ？」とか「今進んでる？」とリマインドしてもらえることで、多忙の中やりたいと思っていたことを思い出すことができます。

　期限を決めて、誰かと一緒に読んでみるのも面白そうです。最近はオンライン読書会も流行っているので、参加してみても良いかも。

## 全てを読むことは諦める

　『遅読家の読書術』という本で、「全てを読む必要はない」という考え方を知ってから、読書をするときに気が楽になりました。

　まずは熟読はせずにざっと読んでから、気になったところを改めて詳細に読む方法に切り替えてからは、読書スピードに困らなくなりました。

https://honto.jp/netstore/pd-book_27670030.html

## 積読管理サービスを使ってみる

　積読の本が増えていってしまうという人は、自分が積んでいる本の冊数を把握していない場合があります。こんなにあるんだ！？と意識することで、読書を捗らせましょう。

### 積読ハウマッチ

　今積んでいる本の総額が分かる読書管理サービスです。むしろ積読の冊数がどれだけ多いか競ってしまいたくなりそう？笑

https://tsundoku.site/

**↓ note記事**

https://note.com/kira_puka/n/n9353671edd7c

## 積読はしょうがないと割り切る

　これは最後の手段ですが、もういっそのこと割り切ってしまいましょう。これからも素晴らしい本は出続けるのですし、積読について悩んでいる暇があったら買って、将来の自分へのプレゼントと思うのもアリかもしれません。

## （番外編）読書通帳を使ってみる

　図書館によっては、「読書通帳」というサービスを導入しているところもあります。

　読書通帳は、借りた本を銀行の通帳のように印字してくれるサービスで、「これだけ読んだんだ」と可視化してくれます。
 
　読書履歴を登録できるサービスは数多くありますが、図書館で借りるだけで目に見える記録を作れるので楽です。

https://www3.nhk.or.jp/lnews/nagano/20231004/1010028336.html

# まとめ
個人的には「積読」自体は良いことだと思っています笑　書店に行くとついつい面白そうな本が目について買ってしまいますよね…。

　ただ、「ああまた積読してしまった…」という気持ちになるのは精神衛生上悪いので、今回ご紹介した方法を使ってみていただけると嬉しいです！
asnc/awaitが難しすぎるから少しだけ整理してみた【前編】

この記事は、プログラミング初心者が非同期処理について考える以下の記事の続きです。
先にこちらをご覧ください。

https://qiita.com/odendayoko/items/db811001573055da12f0

https://qiita.com/odendayoko/items/7788b886ba4c6ad87814

本日はasync/awaitについてまとめます。

## async/await
async/awaitで最も重要なポイントは、**awaitの右側に書いた非同期処理が完了するまで、次の処理を実行しない**ことです。**上から下へ順番に処理を実行**してくれるようになります。
これにより、Promiseの問題点の1つだった、実行される順番がぐちゃぐちゃになる問題が解消されます。

今回もあまりにも難しすぎるので、理解することから逃げました。
最低限ここだけ押さえたいポイントを先にまとめます。

:::note info
- awaitをつけると右側の非同期処理が完了するまで次の処理は実行されない
    - =>上から下へ順番に実行されるからソースコードが読みやすい！
- awaitしたいときは、その関数をasyncで囲う
    - =>そういう決まりだから覚える
- asyncで囲んだ関数の返り値は必ずPromiseインスタンスになる
    - =>then/catchメソッドが使える
- awaitした非同期処理がrejectされたらエラーをthrowする
    - =>そのエラーをtry/catchで捉えられる
:::

## Async Functionの定義
asyncキーワードを使って関数を定義することで、**その関数は非同期処理を含む**ことをコードを読む人に示すことができます。

大前提として、asyncをつけなくてもJavaScriptは非同期処理を実行できます。しかし、膨大なソースコードの中で非同期処理が書かれている場合、読み手からするとどこからどこまでが非同期処理なのかは分かりにくいし、どんな順番で処理が実行されるのかも想像しにくいです。実際に動かしてみないとわからん！😇では実装する上で困りますよね。
asyncは、**この関数には非同期処理が含まれているよ！**　と読み手に示すことができる目印のようなものと解釈しました。

asyncは重要な2つの特性を持ちます。
- asyncで囲んだ関数の返り値は必ずPromiseインスタンスになる
- asyncで囲んだ関数の中でawaitが使える

### asyncで囲んだ関数の返り値は必ずPromiseインスタンスになる
おそらく、asyncをつけると内部的に下記の通常の関数のような処理が行われているのだと思います。難しいので飛ばしましょう。
ただasyncをつけるだけで、`Promise.resolve("値");`を書く必要がなくなっているのはスッキリして良いですね。
```javascript
// 通常の関数
function doAsync() {
    return Promise.resolve("hello");
}

// async関数
async function doAsyncAsync() {
    return "hello";
}
```
asyncで囲んだ関数の返り値は必ずPromiseインスタンスになるので、以下のように**then/catchメソッドが使えます！**
```javascript
// doAsyncAsync関数の返り値はPromiseインスタンス
doAsyncAsync().then(value => {
    console.log(value); // => "hello"
});
```
### asyncで囲んだ関数の中でawaitが使える
asyncキーワードを使用することで、その関数内で await を使って非同期処理を行うことができます。
awaitに関しては明日解説します。


### 参考

https://jsprimer.net/basic/async/#async-function

https://www.cview.co.jp/cvcblog/2022.05.30.488_DPHMY7ikiNc7KhEO1
Google Drive APIの紹介

## はじめに
皆さんはGoogle Drive APIをご存知でしょうか。このサービスはGoogle Drive上のファイルを操作することのできるREST APIです。また、このサービスは無料で利用できるのでAPIに興味のある方にはぜひお勧めしたいと思います。ではこれより実際にGoogle Drive APIを利用するための設定とGoogle Drive APIを使用する上でのメリットを紹介していこうと思います。

## Google Drive APIの設定
Google cloudからGoogle Drive APIを有効にする方法を紹介していきます。
1.Googleアカウントを作成します。（すでにGoogleアカウントがある方はログインでいいです。）
2.google developer consoleにアクセスします。
以下google developer console link
https://console.developers.google.com/
3.ライブラリにてGoogle Drive APIを有効にします。
4.認証情報を作成する。認証情報の作成の欄をクリックしその後　OauthクライアントIDを選択して設定します。
5.同意画面設定をクリックします。そこにてアプリケーション名やアプリケーションのロゴの設定等を行います。
6.pip installする。

以上の6つのステップにてGoogle Drive APIが使用することができます。

## まとめ
今回はGoogle Drive APIの紹介と使用するための簡単な接待方法の手順について紹介しました。今回の手順の最中にあるOAuthクライアント情報のクライアントIDとクライアントシークレット情報はとても重要ですので鍵情報の保管には注意してください。

## 実際に自分自身で行なった際の画面
![スクリーンショット 0005-12-23 17.35.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3641495/e1c39826-4fd9-b248-d285-08a49c9184d1.png)
![スクリーンショット 0005-12-23 17.33.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3641495/d62a4d26-8d5d-e256-be75-f17525fe5dbd.png)
![スクリーンショット 0005-12-23 17.32.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3641495/1d5ce04d-0e8d-f251-414e-fc0b1377be94.png)


参考文献
https://zenn.dev/wtkn25/articles/python-googledriveapi-auth