OmniAICreator/Qiita-1.07M huggingface dataset:
【PostgreSQL】テーブルとファイル間でデータをコピー

## コピーができるだと！？
テーブルとファイル間でデータのコピーができるようだ。
やり方は
- psqlのメタコマンド
- SQL

の2種類ある。

## コピーコマンド
### \copy
クライアント側のファイルとテーブル間のデータをコピーするコマンド

- ネットワークを介したデータの送受信が必要
- ファイル名は絶対パス・相対パスのどちらでも指定可能
- 実行に権限は必要ない

#### 構文
- テーブルのデータをファイルに出力する場合
`\copy テーブル名 to {ファイル名 | stdout} [with] [オプション]`

- ファイルのデータをテーブルに挿入する場合
`\copy テーブル名 from {ファイル名 | stdin} [with] [オプション]`

#### パラメータについて

| パラメータ | 説明 |
| :---: | :--- |
| stdout | テーブルのデータを標準出力にコピーする |
| stdin | 標準入力（キーボードからの入力）をテーブルにコピーする |


#### オプション
| オプション | 説明 |
| :---: | :--- |
| delimiter [as] '区切り文字' | 各行のデータを列ごとに判別するための区切り文字を指定する<br>デフォルトではタブ（テキスト形式）カンマ（CSV形式)が区切り文字として使用される |
| csv | コピー対象のデータをCSV形式で扱う場合に指定する |
| header | 出力時にはテーブルのカラム名をヘッダ情報として先頭行に付け足し、入力時にはデータの先頭行を無視する<br>※コピー対象のデータをCSV形式で扱うときのみ指定できる |

### COPY
- ファイル名は絶対パスのみ指定可能
- ファイル名を指定する場合に限り、実行にはデータベースのスーパーユーザ権限が必要

#### 構文
- テーブルのデータをファイルに出力する場合
`COPY テーブル名 TO {'絶対パスのファイル名' | STDOUT} [WITH] [オプション];`

- ファイルのデータをテーブルに挿入する場合
`COPY テーブル名 FROM {'絶対パスのファイル名'} [WITH] [オプション];`

#### パラメータについて
| パラメータ | 説明 |
| :---: | :--- |
| STDOUT | テーブルのデータを標準出力にコピーする |
| STDIN | 標準入力（キーボードからの入力）をテーブルにコピーする |

#### オプション
| オプション | 説明 |
| :---: | :--- |
| DELIMITER '区切り文字' | 各行のデータを列ごとに判別するための区切り文字を指定する<br>デフォルトではタブ（テキスト形式）カンマ（CSV形式)が区切り文字として使用される |
| FORMAT csv | コピー対象のデータをCSV形式で扱う場合に指定する |
| HEADER | 出力時にはテーブルのカラム名をヘッダ情報として先頭行に付け足し、入力時にはデータの先頭行を無視する<br>※コピー対象のデータをCSV形式で扱うときのみ指定できる |

※ 複数オプションやFORMATオプションは()でくくる
Chrome 拡張の３つの世界について

## この記事は何
Google Chrome の拡張機能を作成している際、
特定の機能がうまく動作してくれない事象に遭遇しました。
その調査の際に知った Chrome 拡張の３つの世界についての備忘録です。
また、この記事の内容は Manifest V3 に準拠しています。

## ３つの世界って？
恐らく、正式な名称として`３つの世界`というものがあるわけではなさそうで、
具体的には以下のものを指します。
作成したい拡張機能によって、以下の機能のいずれか、もしくは複数を駆使して作成していくことになります。

- Page Action
- Content Scripts
- Service Worker

### Page Action
ツールバーに表示されている、拡張機能のアイコンをクリックした際に処理を行わせることができます。
別途用意した html ファイルをポップアップとして表示したり、後述する Content Scripts を実行したりなど。

詳細は以下の公式ドキュメントから参照できます。

https://developer.chrome.com/docs/extensions/reference/api/action

### Content Scripts
ブラウザ上の DOM の操作を行うことができます。
直接操作できる Chrome API には制限があります。
具体的な API については以下を参照ください。

https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts?hl=ja#capabilities

直接操作できない API については、Page Action もしくは Service Worker で操作を行う必要があります。

### Service Worker
Chrome を起動している間に、バックグラウンドで動くスクリプトです。
自分がハマったポイントとして、Window 関数や DOM などは、直接 Serivce Worker からは操作することができません。

詳細は以下の公式ドキュメントから参照できます。

https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/events

## 必要に応じてやり取りを行う
例えば、Service Worker 上で何かしらのイベントを感知し、
その際にブラウザ上に確認ダイアログ (Window.confirm) を出したいとします。
そのまま Service Worker 上からは Window.confirm を操作することはできないため、
Content Scripts に対してリクエストをし、Content Scripts 上で確認ダイアログを表示するという手段が取れます。

リクエストを行う手段として、`sendMessage()`、リクエストに対してのレスポンスを処理する手段として`sendResponse()` というものが用意されています。
また、上記は単発でのリクエストでの用途になりますが、長期的な接続を行うための手段として `connect()`が用意されています。

詳細は以下の公式ドキュメントから参照できます。

https://developer.chrome.com/docs/extensions/develop/concepts/messaging

## 最後に
ネット上で拡張機能について調査すると、Manifest V2 までのものと Manifest V3 のものが混在しており、
実際に動かそうとしてみると Manifest V3 では動かない、といったことがよく発生し混乱しました。

とはいえ、作り方を理解しある程度自在に開発ができるようになれば
自分好みの拡張機能が作り放題になるので、引き続き理解を深めていこうと思います。
Chat GPT Español Gratis: La Revolución de la Comunicación Accesible

La comunicación es la columna vertebral de nuestras interacciones diarias, y con el avance de la inteligencia artificial, la forma en que nos comunicamos está experimentando una transformación notable. El Chat GPT Español Gratis se presenta como un hito en esta evolución, ofreciendo una experiencia de conversación fluida y accesible para los usuarios de habla hispana. Experimenta el sitio web ChatGPT en Español: https://chatgptx.es/

La Gratuidad como Puerta de Acceso
Una de las características más destacadas del Chat GPT Español Gratis es su accesibilidad. Al eliminar las barreras económicas, este sistema permite a usuarios de diversas regiones y contextos aprovechar la tecnología de procesamiento de lenguaje natural sin incurrir en costos. Esta gratuidad democratiza la comunicación avanzada y la coloca al alcance de una amplia audiencia.

Conversaciones Naturales y Contextualmente Relevantes
El Chat GPT en español gratuito no se limita a respuestas predefinidas; va más allá de las expectativas, generando respuestas que no solo son gramaticalmente correctas, sino también contextualmente relevantes. La capacidad de entender matices lingüísticos y adaptarse a diversos contextos hace que las interacciones sean más naturales y satisfactorias.

Aplicaciones Versátiles
Las aplicaciones del Chat GPT Español Gratis son diversas y abarcan desde asistentes virtuales hasta servicios de atención al cliente. Empresas, instituciones educativas y usuarios individuales pueden incorporar esta tecnología en sus plataformas para mejorar la calidad de la comunicación. Además, su uso gratuito lo convierte en una opción atractiva para aquellos con presupuestos limitados.

Desafíos y Oportunidades
Aunque la gratuidad es un factor positivo, el Chat GPT Español Gratis enfrenta desafíos en términos de la necesidad de mejorar la detección de intenciones y comprender contextos más complejos. Sin embargo, estos desafíos son oportunidades para el crecimiento y la mejora continua de la tecnología.
クラウドワークスでベネズエラ人のエンジニアを雇って、英語を使ってチーム開発する話2

こんにちは、リッキーです。

前回の記事はこちら
[クラウドワークスでベネズエラ人のエンジニアを雇って、英語を使ってチーム開発する話1](https://qiita.com/rickeysan95/items/cc02512eab7d30e4b1d6)

先日、2回目のミーティングをレオ（ベネズエラのエンジニア）としてきました。今回は、私がアプリのアイデアを考えてきたので、それについて意見をもらいました。

## 作りたいアプリ
英語でのコミュニケーションの体験を共有できるアプリ

オンライン英会話をしているときなど、言いたいことが言えなくてor間違っていて、講師に正しい表現を教えてもらうことはよくあると思います。
また、使おうと決めていた表現を使って、うまくコミュニケーションを取れると嬉しくなったりします。

「道案内のときに使える表現集」「"Thank you"以外にありがとうを伝える表現10選」のような書籍や本は多く存在しますが、なかなか記憶に残らず、また、具体的な使い時が分からなかったりします。

そこで、キーセンテンス（英語表現）を軸に、どのような状況でそのセンテンスを使ったか？どのような気持ちだったかなどを投稿できるアプリを作ろうと思います。

これにより、英語表現をただ覚えるだけでなく、実際に使って相手の反応を見る→伝わっているかを確認→アプリに投稿という流れが出来て、受け身の勉強法から主体的に英語を使うモチベーションになればよいと思います。
インプットからアウトプットです。
このアプリでは、ほかの人の投稿も見ることができます。

上記の内容で、英語のドキュメントを作成し、レオと共有しました。また、下記のようなイメージも作成しました。

私が用意した参考資料の一部（投稿アプリで、その投稿カードの内容）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1851421/c93e2528-4c9b-f0f4-7c21-70acae02f054.png)


## レオと話したこと
資料を使いながら、何とかアプリの概要を説明します。
レオはは素晴らしいと褒めてくださいました（私は彼に仕事を依頼している側なので、露骨にダメだとは言わないとは思いますが...）
レオはプログラマーだけでなく、教師の経験もあるので、そっち側としても意見もくれました。私はこのアプリの使いやすいを気にしていました。

Key Sentenceの欄は、英語を想定していますが、Sitiationの欄も英語にしてしまうと、投稿のハードルが上がるかなとも思います（特にSituationの欄は、長文になりそうなので、母国語の方が書きやすいし、ハードルは下がりそう）

Situationは母国語で入力できるようにするなら、右上に言語ラベルを付けてもいいよねという意見がレオから出ました。
私としては、「確かに悪くないな。でも英語アプリだから、やっぱり全部英語で書かせた方がいいかも。でもそれで誰も投稿してくれなかったら、本末転倒だよな。」などと考えていました。
自分の中でも考えがまとまらず、レオにそのことを英語で説明する力もなかったので、「Thank you for your idea. I'll decide later.」と、この話題を切り上げてしまいました。

その後もレオと話して、表情の絵文字はFacebookのように豊富に選べるようにしたい、Key Sentenceは音声APIを使って、読み上げ機能があるといいという意見が出ました。

レオは私の資料に書き込んでくれて、以下のようなスケッチが出来ました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1851421/c6401e30-91ef-a9f3-d588-0e001c16ce31.png)

また、技術セットはVue.jsとFirebaseを使うことにしました。

当初はLaravelの予定でしたが、今のところ作るアプリはすごく単純なので、わざわざLaravelを使う必要はないと判断しました。Firebaseはけっこう無料で使えます。
レオにも、それらの経験があったようで良かったです。

CSSライブラリは、レオのおすすめのVuetifyを使うことになりました。

## 次回の方針
次のミーティングまでに、Githubのリポジトリを作り、Vue.jsの初期セットアップを終わらせておくことを彼と約束しました。いよいよ開発に入ります。

## 英語力に関して
聞き間違いをしてしまいました。せっかくなので、これから作る英語アプリっぽく書きます。

**Key Sentence**
I heard wrong.
**Situation**
レオとアプリの話をしている際に、彼が「This app is cool」のようなことを言ったのですが、私には「This app is poor」のように聞こえました。poorってどういうこと？と聞き返して、私の聞き間違いだと気づきました。この時、sorryしか言えませんでしたが、I heard worngというべきでした。
:thinking:　2023/12/11 rickeysan
FlutterでGoogleMapアプリを開く

Flutterにおいて、url_laucherを使用してGoogleMapのUrl(https://www.google.com/maps) を立ち上げた場合、
どう表示するかはOSがよしなに対応してくれるので、動作が予測できない部分があります。
(GoogleMapアプリが立ち上がる or 開発アプリ内でgoogleMapのwebサイトにアクセスする、など)

地図に関してはアプリで閲覧したいユーザーが多いと思われるので、明示的にアプリを開きたいところです。
GoogleMapを含めた地図アプリの内、利用可能なアプリをに開くコードを示します。

```map_app_launcher.dart
final googleMapAppUurl = Uri.parse('comgooglemaps://q=$address');
final appleMapAppUrl   = Uri.parse('https://maps.apple.com/?q=$address');

if (await canLaunchUrl(googleMapAppUurl)) { // GoogleMapアプリは立ち上げられるか
  // GoogleMapアプリを立ち上げる
  await launchUrl(googleMapAppUurl);
} else if (await canLaunchUrl(appleMapAppUrl)) { // iOSの地図アプリは立ち上げられるか
  // iOSの地図アプリを立ち上げる
  await launchUrl(appleMapAppUrl);
} else {
  throw 'Could not launch url';
}
```

参考：https://naipaka.hatenablog.com/entry/2021/08/05/091411
参考：https://itecnote.com/tecnote/r-open-google-maps-app-if-available-with-flutter/
AWS SSM Amazon Linux2にSSM エージェントをインストールする方法

## 概要

Amazon Linux2（x86_64）にSSMエージェントをインストールする方法を簡単にまとめる。

## 方法

- 下記コマンドを実行する。

    ```shell
    sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
    ```

- 下記を実行してSSMエージェントが動作しているか確認する。（出力文字列の中に`Active: active (running)`があれば正常稼働中）

    ```
    sudo systemctl status amazon-ssm-agent
    ```

## 参考文献

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/agent-install-al2.html
Rspecでanythingを使うとエラーになってしまう

# はじめに

Rspecでモックを使おうとしたところ時間がかかってしまった箇所があるので書いておきます

# 問題

テストの引数のチェックで`anyting`を利用しました

```rb
    Api.should_receive(:update_new_document).with(shortname, anything())
```

すると以下のエラーが発生します

```
Failures:
       (Api).update_new_document("A-00001", #<RSpec::Mocks::ArgumentMatchers::AnyArgMatcher:0x007faba8fb9658>)
           expected: 1 time
           received: 0 times
     # ./spec/jobs/update_all_worker_spec.rb:19:in `block (5 levels) in <top (required)>'

Finished in 2.68 seconds
1 example, 1 failure
```

# 解決方法

`anything()`にして解決しました

```rb       
Api.should_receive(:update_new_document).with(shortname, anything())
```

# おわりに
久しぶりにRspecをかいてますが昔を思い出します。楽しい
業界未経験が未経験を育成するということ

株式会社OMJテクノソリューションズ Advent Calendar 2023　19日目の記事です。

私は異業種から転職して日も浅い身分なのですが、早々に未経験の部下を持つことになりました。とんでもないタイトルですが、普段何を考え動いているかを書き連ねようと思います。
経験の有無に関わらずどのようなマインドを持つべきかを考える機会になれば幸いです。また、部下の育成に戸惑っている方にも読んでいただけると嬉しいです。

# 技術的な育成
### 出来ません
当然ですが技術的な育成はできません。無理です。私自身が勉強中ですので人に教えられるような技術は皆無です。
ですので技術に関して、育成する側とされる側の関係はもはや無く同僚として知識交換をするに終始しております。自分が理解できているものについては共有し、理解出来ていないものに関しては分からないと言い切る。持つプライドもないのでこの態度で一貫することを心がけています。なんなら部下に教えを請うことも多々あります。
はっきり言って頼りになる教育者にはなれないです。部下が課題にぶつかったときは一緒に悩むくらいしか出来ていないのです。
あとは自分も部下も独自に学習し、得たものを共有し合うような仕組みをもってスキルアップを目指すという形を構築するのができることなのかなぁと頭を悩ませております。
特殊な状況下ですのでネガティブ部分が前面に出てしまうのですが、一方腹を割った関係性を構築することが容易であるという事実もあるかと思っております。日の浅い人間は隠し立てするような物事もないので開放的なコミュニケーションが基本になってました。加えて、未経験同士持っている視点も近いため認識齟齬が起こりにくいのです。その点を存分に活かすのが最良ではないでしょうか。
### 出来ないなりに
もちろん出来ないと開き直って終わるわけにもいきません。
育成という観点からは話が逸れますが、上司として出来ないなりに最低限として以下を心がけております。
・独学を止めない。
・可能な限り一歩前を進む。
・課題の解決方法など間接的な助力をする。
・物事を明確にする。
・プライドは持たない。
そもそも私自身が勉強中であるという大前提を納得してもらい、その上で上位にいさせていただくというベンチャー特有の状況を飲み込んでもらっているのです。不誠実であることが認められるわけはないので自己研鑽は必須でしょう。また、業務において直接的な技術の教育ができなくとも間接的なアドバイスであれば多少できることはあるはずですので、そういったところにも重きをおいております。
何よりも重要なのは物事を明確にしておくというところかと思います。物事の進め方や責任の所在、私自身が対応できる範囲など、不明瞭なものが残るほど不信感が増大するでしょう。具体的な話こそが納得感を得る最良の手段と捉えております。
前述している通り良好なコミュニケーションを確立しやすいので多少突っ込んだ話もしやすかったりするのです。一般的な上司から部下への一方的な注意・指摘よりも、相互で言いたいことを言い合う関係性というものを実現できるのではないかと思います。
# 技術面以外での育成
前述の通り技術面では何も出来ていないので、せめてそれ以外でできる育成を全うするのが最低限かと思ってます。異業種で社会経験自体は積んでいるので、その中で得た経験からIT業界でも活かせるものを抽出し共有する。これが唯一可能なところですね。
簡単に言っていますが、何がIT業界で活かせるかの判断も怪しいというのが実情です。なので常々自分の認識がズレているかを周囲に確認することが必須となります。異業種から来た身分だとそもそもの前提がズレた認識を持つことが多々あるため、確認を怠ると一瞬で害悪な存在になるポテンシャルを持っていると思います。育成云々以前に会社にとって毒とならないよう気をつけねばなりません。
# つまるところ
駄文を書き連ねましたが、業界未経験が未経験を育成するにあたって重要な点は以下の通りかと思います。
・技術的な教育は不可能。知ったかぶりでテキトウなことを言わない。
・自分も部下も独自で学習し共有しあうような仕組みを作る。
・技術面以外では経験から活かせそうなものを抽出し、内容を精査して共有する。
・そもそも発展途上な中の特殊な体制。信用を失うようなことがあってはならない。

育成という観点とは随分ズレた文章になってしまいましたが、私個人の考え方を書き下しました。あまりないとは思いますが似たような境遇にある方に何らかの足しになれば幸いです。
香川県の空家問題について　丸亀マルタス2023.10.20


<iframe src="https://docs.google.com/presentation/d/11-9wVzwQeBAu_JlTO-ZkuY1iKyi90mDP/edit#slide=id.p1" frameborder="0" width="960" height="569" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true">
</iframe>
何年か越しに正規表現の「ゔ」の謎が解けた件

この記事は[インフォ・ラウンジAdvent Calendar 2023](https://qiita.com/advent-calendar/2023/info-lounge) 12日目の記事です

前回は @ytkhs さんの[古めのAWS CDKv2で作ったAuroraServerlessV2を新しいCDKに対応させたときに悩んだ話](https://qiita.com/ytkhs/items/b1ef1c325b455badcd78)でした。
Auroraは名前しか知らないので、内容はさっぱりですが解決できたようでよかったです。

---

さて本題。
別の会社にいた何年か前に、フォームのかな入力の欄に「ゔ」が入力できず困ったことがありました。
ずっと心のどこかに引っかかっていたのですが、先日解決したので「なんでだったのか」、
「解決方法」をご紹介しようと思います。

## なんで「ゔ」が入力できなかったか

正規表現は以下のような感じでした。
検索したりしても大体下記のようなコードが出てくると思います。

```
/^[ぁ-ん]+$/
```

これがそもそも「ゔ」が含まれていない正規表現のようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/13242/2959e33d-92de-7867-0009-f2c54acd27c7.png)

[平仮名 \(Unicodeのブロック\) \- Wikipedia](https://ja.wikipedia.org/wiki/%E5%B9%B3%E4%BB%AE%E5%90%8D_(Unicode%E3%81%AE%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF)#%E5%B1%A5%E6%AD%B4)より引用

この表によると、小さい「ゕ」「ゖ」や繰り返しの「ゝ」「ゞ」、よとりの合字である「ゟ」もひらがなの範疇のようです。
「ゟ」は存在すら知りませんでした。

## 解決方法

それでは最後の「ん」を書き換えて

```
/^[ぁ-ゟ]+$/
```

にすれば解決かな？と思うと、そう簡単でもないようです。
もしひらがなの表の「ゟ」の後に追加されると、修正が必要になります。

そんな時に使えるのが

```
Unicode プロパティエスケープ \p{}
```

を使った

```
/^\p{scx=Hiragana}+$/u
```

です。

```
/^[ぁ-ゟ]+$/
```

同様に鍵括弧や句読点にもマッチしてしまいますので、
その辺は仕様によっても対応がまちまちにもなりますが、
今回の「ゔ」に対応したい、そしてなるべく修正したくないようなものにはマッチするかなと思います。

## デモ
<p class="codepen" data-height="300" data-default-tab="css,result" data-slug-hash="GRzPwpZ" data-user="ituki_b" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/ituki_b/pen/GRzPwpZ">
  ひらがなの「ゔ」をチェックに含めたい</a> by ituki_b (<a href="https://codepen.io/ituki_b">@ituki_b</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>
合成生物学のコミュニティー(iGEM)はAIを使用したプロジェクトを適切に評価できるのか？

# はじめに
<!-- 発端や概要を記載 -->
こんにちは　2023iGEMGifu代表の今川です。初出場で初代表は苦労も多かったですがiGEMに取り組む前と後では見違えるほど知識もついたし技術もついたと思います。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3633233/f3c8e3e4-79a7-4854-3980-782852352ddd.png" width="300">
# 目次
<!-- タイトルとアンカー名を編集 -->
1. [今回感じたこと](#Chapter1)
1. [この記事の目的と結論](#Chapter2)
1. [2nd Runner Up 🥉を受賞したNUS-Singaporeの研究](#Chapter3)
1. [まとめ](#Chapter4)

<!-- 各チャプター -->
<a id="#Chapter1"></a>
# 今回感じたこと
**AIを使ったプロジェクト空中戦じゃね？**　
空中戦: AIを使うほうもジャッジ側も理解も不十分でありモデルの複雑さ、学習データの量で評価している事

iGEMerでありKagllerである私(iGEN Kaggle部作りたい)はモデルと適切に評価することが一番難しいと感じています。
特に過学習（評価データや事前に知りえないデータを学習に使用すること(学校のテストでいうとカンニングや過去問の入手？）)を起こさないように十分気を付ける必要があります。

<a id="#Chapter2"></a>
# この記事の目的と結論
そこで入賞チームの研究を読み
*機械学習モデルの評価方法、*
*ベンチマークとの比較方法*
を通じ機械学習モデルを過大評価(もしくは過少評価)していないか調べることでiGEM2023ではiGEM)はAIを使用したプロジェクトを適切に評価されているかわかるのではないかと考えました。

**結論**
    -入賞チームの研究の見せ方、研究デザインには改良の余地がまだある。
    -ジャッジにも機械学習の素養を持った人がもっと加わると良い。
（上から目線ですいません:bow_tone1:）
<a id="#Chapter3"></a>
# 2nd Runner Up 🥉を受賞したNUS-Singaporeの研究
このiGEMプロジェクトでは、二つの主要なモデリング目標が設定されました。
そのうちの2つ目に機械学習を使用してました。
wiki: https://2023.igem.wiki/nus-singapore/
***研究概要(機械学習に関わるとこのみ)***

**表1 機械学習モデル別に見た研究の概要**
研究内容に対応するようコメントを書いてみました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3633233/82d4f062-7069-d08e-0a24-41e4300717d5.png)
下に行くほど複雑なモデルになっておりが分かると思います。
->線形回帰モデル,MLP,トランスフォーマーで学習するにつれて精度が良くなった印象を受けるが実際は3つのモデルで予測しているものは違うので一概に精度を比較することはできません。
今回評価指標に使われていた最小二乗誤差(MES)などの大きさはタスク(予測するターゲット)によりスケールが違うので小さいから良いモデルといえることはなく相対的な指標です。
->各モデル一試行分しか記載がなく工夫点が実際にどれほど予測に寄与しているか分かりません。

次に3つ目のモデルについて詳しく見ていきます。
1. **ディープラーニングモデル（RNAスイッチ）**:
   - 目的: RNAスイッチの性質を予測するための予測モデルと生成モデルの開発。
   - (a) **予測モデル（Siamese Large Languageモデル）**:
     - RNAスイッチの特性を予測する。
     - 結果: RNA間の相互作用を高精度（R2 = 0.937）で予測。
   - (b) **生成モデル（トランスフォーマーアーキテクチャ）**:
     - RNAスイッチの設計を行う。
     - 結果: 期待される配列と最大2塩基対の違いでトーホールドスイッチを生成。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3633233/4a17d7b7-7f28-030e-51b7-d6dbbc2dfefb.png)

図1　予測モデル（Siamese Large Languageモデル）の構造　
    wikiに記載されたもの

 we trained it from scratch ourselves.と記載があった
 ->複雑なモデルの学習には膨大なデータが必要であり、訓練するには相当な苦労があったと思う。

**評価方法について**
生成モデルがデザインしたスイッチを用いて実験したわけではないのでこのワークフローをそのまま検証することはできず実際には先行研究（Angenent-Mari et al., 2020）のデータセットで評価している。
->個人的にここが一番のトラップ(生成モデルも含めて評価したと誤解を与える)
->学習と推論データをどんな比率で分割したのか書いてあると良いと思いました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3633233/f02f1509-6d0c-7d38-48a2-2984550aac4f.png)
図2 3つ目のモデルのワークフロー
wikiに記載されたもの
<a id="#Chapter4"></a>
# まとめ
研究の見せ方、研究デザインには改良の余地がまだあると思いました
3つ目のトランスフォーマーモデルについて生成モデルからの出力を特徴量にしているが実際に評価するときには生成モデルは使用していない点に気づかないとこの研究を過大評価しかねないのでしっかりその旨を明記する必要があると感じました。
(私がジャッジならこの点を質問していたと思います。)

入賞研究を批判する暗い感じの記事になってしまいましたが最後まで読んでいただき嬉しいです。NUS-Singaporeの2023の研究は気になる点は多々見受けられるが機械学習以外のパートも含めて素晴らしい内容となっていてAIを使用したiGEMの先駆けとしては良い例だと思います。

今後この分野(分子生物学×AI)の発展が加速していく事は間違いないと思います。
学生が分子生物学×AIに実践的に触れられる場はiGEMだけでなく以下のような大会でも可能です。良かったらどうぞ―
Stanford Ribonanza RNA Folding(kaggle)
https://www.kaggle.com/competitions/stanford-ribonanza-rna-folding/overview
S3のフォルダごとの総容量、総サイズを知る方法

S3のフォルダごとの総容量、総サイズの調べ方調べると

```
aws s3 ls s3://[バケット名]/[フォルダ名]/  --recursive --human --sum
```

がよく出てくるんだけど、これだと数十万という大量のファイルが入ってるフォルダ調べるの時間かかるし、お金もかかるしもっといい方法あるんじゃないの？、と思ったらマネコンで簡単にできた。

# 手順

- AWS Management Console にサインインし、Amazon S3 コンソール https://console.aws.amazon.com/s3/ を開きます。
- 左側のナビゲーションペインで、[バケット] を選択します。
- [Buckets] (バケット) リストで、フォルダが保存されているバケットの名前を選択します。
- [Objects] (オブジェクト) リストで、フォルダの名前の横にあるチェックボックスをオンにします。
- [Actions] (アクション) を選択し、[Calculate total size] (合計サイズを計算する) を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21645/d87f61ff-0421-6746-4ccc-b91f6900e235.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21645/2b119e98-752b-6f75-934c-8f9f04dcdf34.png)

# 参考

[フォルダを使用して Amazon S3 コンソールのオブジェクトを整理する - Amazon Simple Storage Service](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-folders.html#calculate-folder)
Vue2からVue3へ「とりあえず」移行した際のメモ（Options APIのまま）

現在、ASP.NET Coreのcshtml中で利用しているVue2のコードを、Vue3でも動作するようにとりあえず移行した際のメモです。

# 前提
- 移行元のソース（Vue2）はOptions APIで書かれています。
- Vue3に移行する際にはComposition APIに置き換えたりせず、そのまま動作させます。
- 単一ファイルコンポーネント（.vue）ではなく、ピュアJavaScriptで動作させます。
- SPAではなく、cshtml単位でページ遷移する通常のWebアプリケーションです。
- Vueは現在、CDNからscriptタグで読み込んでいます。

# ライブラリのロード（CDNを使ったscriptタグでのロード）

下記はdevelopment用のファイル。production版を使いたい場合は vue.global.prod.min.js を参照。
※production版にすると余計なデバッグ情報が出力されないため、若干パフォーマンスが向上する。

```html:(旧)
<script src="https://cdn.jsdelivr.net/npm/vue@2.6.0"></script>
```

```html:(新)
<script src="https://cdn.jsdelivr.net/npm/vue@3.3.10/dist/vue.global.min.js"></script>
```

# ESM(ECMA Script Module)形式でのロード
ESM形式でimportしたい場合には、次のように書くこともできます。

```html:(新)
<script type="module">
    import * as Vue from 'https://cdn.jsdelivr.net/npm/vue@3.3.10/dist/vue.esm-browser.min.js';
</script>
```

# Vue初期化コード
```js:(Vue2 + Options API)
const app = new Vue({
	el: "#vue_app",
	data: {
		prop1: "hoge",
	},
 
    // メソッド群
	methods: {
	
	},

    // マウント時処理
	mount : {
	
	}

});
```

```js:(Vue3 + Options API)
// VueグローバルオブジェクトからcreateAppメソッドをインポート
const { createApp } = Vue;

// createAppの呼び出し
const app = createApp({
	data() {
		return {
			prop1: "hoge",
		}
	},

    // メソッド群
	methods: {
	
	},

    // マウント時処理
	mount : {
	
	}

}).mount("#vue_app"); // DOMにマウント
```
新プロ対応振り返り

# はじめに
皆様はじめまして。
QA歴4年目になり、現在はテストリーダー兼テスターをしている@QA_jellyです。
普段は運用中のゲームタイトルに対してテスト実行やテストケースの作成などを行っています。

今年は短期ローンチタイトルに携わる機会がありましたので、そのときの経験から感じたテスター目線で見えた課題と、私が実際におこなった対策についてお話しできればと思います。

## 前提
＜定常＞
・Webゲームのテストを担当
・10年以上続いている長寿タイトル
・日々の業務はテストリーダー/テスター/テストケースの作成

＜今回＞
・Webサイトのテストを担当
・ローンチタイトル
・業務はテストリーダー/テスター

# 所感
本題に入る前にまず所感をお伝えすると、常に柔軟な対応が求められていたということです。
普段、運用中のタイトルではテスト中の仕様変更は少なく、一度テストした箇所を再度テストすることは稀です。
しかし今回のタイトルでは仕様が固まってないことや、固まっていたが仕様不具合などもあり変更が頻繁におこなわれ、テスト中の仕様変更で再テストが頻繁に発生していました。
そのため、絶えず変化するテスト対象と、短期間のアサインと時間も制限されている中でどこまで効率的にテストを進めることができるのか柔軟性が問われました。

# 課題
### テスト対象へのナレッジ不足
今回のテスト対象は普段の運用タイトルとは毛色が異なるものだったため、知見がないこと、得た知見が高頻度の仕様変更により中々固まらないといった問題がありました。

- 対策：全体像を把握する
今回のタイトルではアサイン期間が短いこともあり、十分な知見を得る時間がありませんでした。
そこで私は毎日テスト実行前にテスト対象を機能ツリー毎に、少しでもいいので触れる作業をおこなうことにしました。
そうすることで、全体像から見た機能毎の役割を意識した知見を補いました。
結果、これがプロダクトの意図を推測する際の解像度を上げる手助けとなり、観点の漏れ防止や補強にもつながりました。

### 仕様変更時による不具合発生リスク
上でも挙げていますが仕様変更が多かったため、変更時による不具合発生リスクが高いことも懸念点としてあげられます。

- 対策：QA期間の最終日に探索的テストをおこなう

最終的に探索的テストを実行することで、変更時の不具合発生リスクを軽減しました。
また、その探索的テストの精度を上げるためにテスト中に検知した不具合が多かった機能を重点的にチェックするといったこともおこないました。

# 最後に
今回私が実際にテストをおこなった短期ローンチタイトルについては、変化の激しいテスト対象についてどこまで柔軟に対応していくことができるのかが、肝要であったといえます。
普段テスターをしている方にもそうでない方たちにも、本記事が少しでも力になれば幸いです。
【コードレビュー】レビュアー・レビュイーそれぞれの視点から意識すべきこと(実務経験1ヶ月の新卒未経験視点)

# 背景
OJTが始まって2か月、少しずつ難易度が高いタスクに着手していく中で、プルリクのレビューで質問や指摘などのコメントをたくさんいただくようになった。中にはコード整形の依頼やコメントのつけ忘れなど、レビューを依頼する前に最低限自分で確認しなくてはいけないような些細な事までレビュアーに指摘させてしまい、余計な時間を使わせてしまったと反省した。
そのため、レビュイーとして依頼をする前に最低限自分で確認しておくことと、チームメンバーのレビューの仕方を参考に今後自分がレビューする側になったときに意識したい事をまとめておくことにした。
(実務経験1ヶ月時点での視点なので、今後も随時アップデートしていく)


### レビュイーとしてコードレビューを依頼する際に意識すること
#### ■編集を加えた箇所を上からざっと見直す
そして見直す際に以下のことを確認する
- コード整形はしたか？
- 適切なコメントは入れたか？
- 不要なimport文はないか？


 #### ■実装・修正した箇所について説明ができる状態である
 具体的には以下のことを自分の口で説明できるようにしておく
- 機能仕様・このタスクで実現したいこと
- 実現のために行った修正や実装
- なぜこの書き方にしたのか（単に知識がなくてこの書き方しかできなかったのか、この書き方が最善だと思う理由があるのか）
- レビュアーから頂きたい意見やアドバイス（あれば）


### レビュアーとしてコードをレビューする際に意識すること


#### ■理解ができないコードは遠慮せず質問する
「新人だから、、」とか「こんなのも分からないのって思われそう、、」とか思わず、チームのコード可読性向上のために遠慮せず質問する。

#### ■コメントをする際、コメントの種類・重要度が一目でわかるようにする
略語をうまく活用してレビュイーがぱっと見でコメントの種類を理解できるようにする。

| 略語            |語源               |意味                 |
|:------------------|:-------------------|:--------------------|
| MUST             |       |絶対に読んでほしい・修正してほしい     |
| Want             |       |できれば直してほしいかも      |
| Q             |Question       |質問      |
| IMO             |In my opinion       |私の意見としては      |
| NIT / NITS      |Nit(s) pick         |強制ではないが些細な指摘や軽い修正をしてほしい時|
| FYI             |For Your Information|参考までに (関連記事のリンク張ったり)          |
| WIP             |Work In Progress 　 |対応中    　  　       |
| LGTM             |Looks Good To Me 　|自分的にはOKだよ    |
【LINE Messaging API】Flex Messageでイメージマップ風のメッセージを配信してみる

# はじめに

こんにちは！

この記事は[ミロゴス Advent Calendar 2023](https://qiita.com/advent-calendar/2023/milogos) 20日目の投稿です。

LINE Messaging APIでは、様々な形式のメッセージを送信することができます。
本記事では、見た目がイメージマップ風のメッセージをFlex Message形式で送信できるか試してみました。
かなりニッチな内容ですが、少しでも多くの方のお役に立てれば幸いです。

# やりたいこと

Flex Message形式でイメージマップ風のメッセージを配信できるか試してみたいと思います。

# 前提

1. イメージマップメッセージ・Flex Messageの各仕様については、以下のLINE Developersのドキュメントに記載があります。
    - [イメージマップメッセージの仕様](https://developers.line.biz/ja/reference/messaging-api/#imagemap-message)
    - [Flex Messgeの仕様](https://developers.line.biz/ja/reference/messaging-api/#flex-message)
2. 1:1の正方形の画像を指定した場合のイメージマップメッセージの見た目は以下です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2609800/34542ccf-3494-63e4-4b35-df13f4495cc6.png" width=30%>

# 検証結果

## 結論

Flex Messgeで`giga`サイズを指定すると、イメージマップとほぼ同様の見た目・サイズ感で配信できました。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2609800/15a27520-c6ed-8bbc-9b7a-45dd4af7df14.png" width=30%>

※メッセージJson

```json
{
	"type": "bubble",
	"size": "giga",
	"body": {
		"type": "box",
		"layout": "vertical",
		"contents": [
			{
				"type": "image",
				"url": "https://bcsr-media.mlgs.app/media/1/13fb35a5-986e-41d4-9bfb-856bc6af9ab3/original/image.jpeg",
				"size": "full",
				"aspectMode": "cover",
				"aspectRatio": "1:1",
				"gravity": "center",
				"action": {
					"type": "uri",
					"label": "action",
					"uri": "https://www.milogos.co.jp/"
				}
			}
		],
		"paddingAll": "0px"
	}
}
```

## Flex Messageの各サイズの見た目

参考までに、Flex Messageのサイズを変えて同じメッセージを送信してみました。

サイズは画面キャプチャ上から`giga` `mega` `kilo` `hecto` `deca` `micro` `nano`です（参考：[サイズについて](https://developers.line.biz/ja/reference/messaging-api/#bubble)）。

※画像は1024px × 1024pxのものを利用（= Flex Messageの最大画像サイズ）。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2609800/b0b70afb-6e04-6a92-b73e-bde02262a4d3.png" width=20%>

上述の通り、`giga`サイズだとメッセージの横幅がトーク画面いっぱいに広がるため、イメージマップの見た目と近しい形になりました。

# 補足
Flex Message形式で送信する際はpngの透過画像を指定しても透過されないので注意が必要です（イメージマップ形式では透過画像が使えます）。

また、Flex Message形式ではイメージマップのように1画像内に複数のリンクを設置できないのでその点も要注意です。

逆に、イメージマップ形式ではURL遷移やテキスト発話のアクションの設定が必須ですが、Flex Message形式はアクション設定なしでも配信もできます。

# さいごに

いかがだったでしょうか？

だいぶニッチな内容でしたが、Flex Messageでもイメージマップメッセージと同じような見た目で送信することができました。
Flex Messageは柔軟にデザインを組むことができるので、やはり噛みごたえがあるメッセージ形式だな〜と個人的には思います。
他にもFlexMessageでこんな面白いメッセージを送信できる！という耳よりな情報がありましたら、ぜひコメント欄でシェアいただけますと幸いです。

以上、ここまで読んでいただきありがとうございました！
【VSCode+SpringBoot】SpringBootでAPIを作る①

## はじめに
**SpringBoot**で**API**を作成するための環境構築

## 環境
* Windows10(11でも可)
* Visual Studio Code
* SpringBoot

## 環境構築
1.VSCodeダウンロード

https://code.visualstudio.com/

2.拡張機能インストール
「Ctrl + Shift + X」で拡張機能の検索バーを出す

「Java Extension Pack」と入力し検索
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/d9309c26-0538-1c5f-b899-bca87416af87.png)

Java Extention Packをインストール
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/5363fddb-62da-51b0-552a-492e9419f28d.png)
Java開発で使う基本的な拡張機能が詰まっている

3.プロジェクト作成
「検索」をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/289b0bb1-3de7-637f-ddd9-7891d7232c36.png)

「> spring」と入力し「Spring Initializr:Create a Maven Project」をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/f58bb4c8-ce41-62b5-bed8-103aa6e6643e.png)

バージョンを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/efa08c77-b63e-33e0-0824-0c8f5e943f61.png)

言語を選択(今回はJavaを採用)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/a161d73c-bca2-ccf3-c58f-44700e32adf4.png)

なんか出てくるので適当にEnter連打(チーム開発の場合はリーダーに聞く)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/f7794b98-98a5-9b5a-15f1-d44262b2d519.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/052a373f-1709-ba0f-5f38-bfdd5a710ee9.png)

ここはお好きなほうでOK！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/b7f9887a-1861-1637-0d1b-7856dabe8a58.png)

Javaのバージョンを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/dba27cb7-38e1-c44d-8107-f88d29410a32.png)

他に入れるフレームワークを選択(なければEnter)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/2101a984-6ec5-2019-ae2d-bceb76922992.png)

保存するフォルダを選択(なければ作成)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3627466/7db53aaa-c34d-b6e5-796b-cd01358d1375.png)
初めてのチーム開発

初めてのチーム開発

## 1.はじめに

はじめまして、私はWEBエンジニアを目指す24歳の社会人です
今回は、2023年10月より参加させていただいている、アプレンティスシップにて、初めてのチーム開発を経験することが出来たため、振り返りをしていきたいと思います。


## 2.何をつくったか

私たちのチームでは、オフラインwebページマネージャーというアプリを開発しました。

なぜこのアプリに決まったのかについては、今回の開発テーマが 「自分たちの役に立つもの」ということから色々案を出した結果、実際に私が直面した困りごととして、Ｗｉ-Ｆｉの接続が不安定になり、Githubを閲覧できず、アプレンティスの課題がわからなくなってしまった、という些細なできごとから、「ならオフラインでも閲覧できるようにするアプリを作ろう！」となったのがきっかけです。

実際の悩みからアイデアが決まるという貴重な経験にもなりました。

## 3.開発までの具体的なスケジュール

チーム開発は開発２ヶ月前から顔合わせを行い、週に２度のミーティングを行うという流れで開発が進んでいきました。

今回のアプリ開発、具体的には開発したアプリをプレゼンする日程（12月3日）までのスケジュールについてはNotionを使用して、下記のようにまとめました。

11/03(土)：アイデア決定【全員】、ざっくり担当者決め【全員】

スライド作成(デモストーリーを意識、大枠でOK、アピールポイントまとめ、この段階では最悪絵がなくてもok)【Aさん】
Githubリモートリポジトリの用意【Ｂさん】
11/08(水)：スライド確認【全員】、要件定義【全員】、画面遷移図作成【全員→私】

Githubリモートリポジトリへの接続確認【全員】
画面遷移図作成の続き【私】
11/11(土)：画面遷移図確認【全員】、タスク切り出し【全員】、担当者単位でタスク時間見積もり【全員】、担当者割り振り【全員】

ガントチャート作成【Ｂさん】(早めに)
11/15(水)：ガントチャートの確認【全員】

ワイヤーフレーム作成【誰か】
11/18(土)：設計と環境の確認【全員】

11/22(水)：予備日

11/25(土)：

プログラミング【全員】
プレゼン資料作成【Ａさん】

## 4.アプリの機能

 アプリの機能は一言でWebページをオフライン環境でも管理・閲覧ができる、というものです。
具体的には、Githubのアプレンティスのリポジトリの閲覧、Zenn記事・Qiita記事のダウンロード・閲覧ができるアプリです。

## 5.チーム開発を振り返って（良かった点）

(1)初めにスケジュールをたてることができた。毎回のスケジュールを立てることで具体的にタスクの見積りを考えることや、毎回のミーティングで滞りなく進行することができた。
(2)画面共有しながら相談することで、一人で悩む時間よりもスムーズに問題を解決できた。とくに環境構築のさいのエラーについてはほんとにわからないことだらけだったので、エラーを自分だけで解決しようとしてたら何倍もの時間を無駄にしてたと感じました。
(3)最後に自分なりに技術的な挑戦ができたことです。チームメンバーの補助もあり、自分のタスクが終わった後、JavaScriptを用いたページネーションの実装を試みました。この経験は、試行錯誤を経て、自身のスキルと学習への意欲を深める機会となりました。



## 6.チーム開発を振り返って（悪かった点と対策）
**(1)** 必要な技術が何かが不透明なまま進めてしまった。初めに、ガントチャートで個人のタスク振り分けをした際に、必要な言語、実装する内容（保存ページのＨＴＭＬ作成、Ｚｅｎｎ記事を表示するなど）実装までの期間などを決めていきました。しかし実際にとりかかろうとした際に、実際には何をするべきかわからないという感じで手が止まってしまい、結果チームメンバーの負担を大きくしてしまう結果になりました。
**(1対策）** そのため漠然として内容だけでなく、もっと深くこの実装にはこの技術が必要になってくるといったプロジェクト開始時に必要な技術要件を明確に話し合いをしていく必要があると感じました。まだまだ初心者のうえに、チーム開発の期間も短い点を年頭に入れ、少しでも詰まってしまうという時間を減らすことでより効率的に満足のいく開発ができるのではと思います。

**(2)** 相談不足。期間が短いのに一人で考え込んで時間を費やしてしまいました。１つ目とつながりますが、自分が任せられたタスクに責任をもって一人で挑戦したいという思いもあり、試行錯誤をしていましたが、チームメンバーに負担させる結果になったことは、自分のコミュニケーション不足であることを痛感しました。
**(2対策)** ミーティング以外でも相談する場を設ける。日頃から会話することで相談できる環境にする。ディスコードでのチームとのつながりはもちろんありましたが、実際にミーティング以外での使用がなかったため、躊躇してしまうことがあったので、日頃から会話があるような環境にしていければと思いました。

**(3)** 1つ目、2つ目ともつながりますが、単純にアプリの機能への理解が不足していることが挙げられます。ダウンロードといっても実際にはどのような仕組みで行われているのか、保存したものを管理するのがどのような仕組みなのか、ピンと来ないまま取り組んでしまったため、何の技術が必要なのか想像もできず、手が止まり時間を費やしてしまいました。
**(3対策)** そのため、1つ目、2つ目同様に、相談や綿密な計画にするなどを心がけていきたいと思います。


## ７．さいごに　

まず、無事にプレゼンまで終えることができて良かったです。一緒に開発に取り組んだチームメンバーにも感謝の気持ちでいっぱいです。

私個人としては至らない点が多く反省ばかりですが、チームとして計画をたてて完成までに至ることができて、この経験は本当に貴重な機会になりました。

今回の反省点をいかして、また次回のチーム開発では少しでもチームメンバーに貢献していきたいと強く思います。
AWSのアカウント作成



## はじめに
AWSのアカウント作成の備忘録です💁
初心者です😅
間違えてる部分多々あると思います。
もし見つけた場合、ツッコミいただけると助かります🙇

## 🦁 結論 🦁
:::note info
アカウント作成手順
1. AWSアカウント情報の入力（メールアドレスや氏名など）
2. 連絡先情報の入力
3. 請求情報の入力
4. SMSまたは音声電話による本人確認
5. AWSサポートプランの選択
6. AWSアカウント作成完了
:::

## アカウント作成URL
https://portal.aws.amazon.com/billing/signup#/start/email<br><br>

## AWSアカウント作成料金
### アカウント作成は無料です。

## 無料枠を理解する 
※2023年12月現在
| 無料利用枠サービス | 概要 | 主なサービス |
|------------------|:----:|--------------|
| ずっと無料のサービス | 利用期限がなく、半永久的に無料 | ・DynamoDB<br>　└25GBのストレージ<br>・Lambda<br>　└月100万リクエスト<br>・SNS<br>　└100万の発行 |
| 12ヶ月間無料 | サインアップ(アカウント作成)した日から1年間無料 | ・EC2<br>　└月750時間<br>・S3<br>　└5GB<br>・RDS<br>　└月750時間 |
| 無料トライアル | サービスごとに定められた期間や枠、データ量が無料 | ・SageMaker<br>　└2か月<br>・Redshift<br>　└2か月<br>・GuardDuty<br>　└30日間 |


:::note alert
注意点
* 課金に注意が必要
* 無料枠内でも支払い方法の設定は必須。クレジットカードが必要
* リージョンは<INS>「アジアンパシフィック（東京）　ap-northeast-1」</INS>を選択。
:::

## 参考にしたサイト📗
[超簡単！AWSアカウント作成手順](https://www.cloudbuilders.jp/articles/438/)

***

AWS Lambda関数作成 セクション　リンク
1. [<INS>AWSアカウントの作成](https://qiita.com/nyanyacyan/items/f533938e4f5d7960a32e)
2. [<INS>AWSの開発環境の構築](https://qiita.com/nyanyacyan/items/d1dd2fb874725226f9da)
3. [<INS>Lambda関数の開発とデバッグ](https://qiita.com/nyanyacyan/items/9644db9eb01bdc91d85b)
5. [<INS>IAMロールの作成と設定（途中まで作成したら、Step Functionsを設定する必要あり）](https://qiita.com/nyanyacyan/items/8b0bba4fe59b0c06a946)
6. [<INS>AWS Step Functionsの設定とデバッグ（完了後、IAMの権限にStep Functionsを追加）](https://qiita.com/nyanyacyan/items/004e0dc6145a0fc90b1d)
7. [<INS>API Gateway（発火API）の設定とデバッグ](https://qiita.com/nyanyacyan/items/3cd13fc016103d1de5c1)
8. [<INS>API Gateway（状態維持API）の設定とデバッグ](https://qiita.com/nyanyacyan/items/e96686b5b54b4059d2aa)
9. [<INS>Python（local環境）の開発とデバック](https://qiita.com/nyanyacyan/items/d76e98b0e6e9d9665a54)
GitHub Copilot の Visual Studio Code でのセットアップ

# はじめに
GitHub Copilot をVisual Studio Codeで利用できるようにする手順を記します。

# 前提
GitHub Copilot の登録や使い方についてはここでは触れません。

# Visual Studio Code でのセットアップ手順
## Extensionのインストール
`github.copilot` をインストールします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/12846bcb-80be-b161-910a-cd66d28264ef.png)

## GitHubへのサインイン
1. Sign in to GitHub をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/6f39067e-b78f-15f3-62c0-cdb2a9350a6c.png)

2. Allow をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/138c010e-74cd-fa9e-a8c0-06f0d64e0101.png)

3. 自身のアカウントでサインイン
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/7ba90a20-e70f-286e-07e4-c88c90bfd589.png)

3. VSCodeに戻る
- Open Visual Studio Code をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/d988a411-865c-aed9-755b-c493b4dc004e.png)
- Open をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/e4a6833c-3e9e-ead3-5f81-885afeeacec4.png)

## 状態確認
ソースコードを開いたときに Copilot のマークが見えてればOK
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/8f082691-9cab-c3f3-25e4-fad1157e338b.png)

以下はマークをクリックしたときのメニュー
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/c76ca171-bcf4-8d47-2416-e7ed50a68935.png)
  
## 動作確認
例： `test.ts` を作成し、コメントを入力するとサジェストが表示される
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/f1f1c7dd-40c0-f846-3510-0d21ffb3c60f.png)
「Loco」をCloud Runで実行する

## はじめに

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

最近Ruby on Rails(以下Rails)を触っていると、「うーん、型が欲しい」とわがままな悩みを抱えていました。
そこでC#のBlazorを触りはじめ、「おー！型だ！」と喜んでいました。
ただBlazorを触っていると「書きずらいな...」とさらに悩みを抱えました。(シンプルに努力不足)
そんな贅沢な悩みを抱えている中、
「RailsライクなWebフレームワークがRustからでたぞ！」
という記事を拝見し「どんなものか...」と触り、「あ、めっちゃRailsや」と感動したので今回のアドベントカレンダーの記事にすることにしました。
## Locoとは？
クラスメソッドさんがまとめてくださっているので引用させていただきます。
> Loco は、Rails からインスピレーションを得た Rust用のWebフレームワーク
> ほぼすべての Rails 機能が含まれている
>> Controllerとaxum経由のルーティング
>> ActiveRecordライクにSeaORMでモデル操作

> Rust の安全性・型指定・concurrency モデル・安定したライブラリとエコシステム
> デプロイでは単一のバイナリをサーバーにコピーしています。
> 手間をかけずに100,000 req/secリクエスト捌ける
> DB呼び出しでは 50,000 req/sec
## 前提条件
コマンドラインで扱うcargo、gcloudはインストール済み
GCPの課金も設定済み
## 開発・実行環境
* ローカル環境
Ubuntu22.04 on WSL2
Visual Studio Code
Docker
* クラウドサービス
Google Cloud Platform
## 準備
https://github.com/loco-rs/loco
のQuick Startを参考にし、一部変更を加えながら準備していきます。
```
$ cargo install loco-cli
```
次にloco newを実行
```
$ loco new
App name? > hello_loco
What would you like to build? › Stateless HTML
```
ディレクトリをhello_locoへ
```
$ cd hello_loco
> ~/hello_loco$
```

Dockerfileと.dockerignoreを準備
```Dockerfile:Dockerfile
# Use the official Rust image.
# https://hub.docker.com/_/rust
FROM rust:1.74.1-slim

# Copy local code to the container image.
WORKDIR /usr/src/app
COPY . .

# Install production dependencies and build a release artifact.
RUN cargo build --release

# Service must listen to $PORT environment variable.
# This default value facilitates local development.
ENV PORT 3000

# Run the web service on container startup.
ENTRYPOINT ["target/release/hello_loco"]

# cargo loco "start"
CMD ["start"]
```

```.dockerignore:.dockerignore
target
test
```

## DockerとGCP
### Docker
イメージ作成
```
docker build -t hello_loco .
```
Artifact Registry用にイメージを複製
```
docker tag hello_loco asia-northeast1-docker.pkg.dev/プロジェクトID/hello-loco-repo/hello_loco:latest
```
### GCP
#### Artifact Registry
GCPへログイン
```
gcloud auth login
```

Artifact Registry へのリクエストを認証するように Docker を構成
```
gcloud auth configure-docker asia-northeast1-docker.pkg.dev
```

Artifact Registryの作成
```
gcloud artifacts repositories create hello-loco-repo --repository-format=docker --location=asia-northeast1 --description="loco Docker repository"
```
Artifact Registryへイメージをpush
```
docker push asia-northeast1-docker.pkg.dev/プロジェクトID/hello-loco-repo/hello_loco
```

#### Cloud Run
今回Cloud RunはGCP上で操作していきます

<dl>
  <dt>既存のコンテナ イメージから 1 つのリビジョンをデプロイする</dt>
  <dd>選択 Artifact Registry pushしたイメージを選択</dd>
  <dt>認証</dt>
  <dd>未認証の呼び出しを許可</dd>
  <dt>コンテナポート</dt>
  <dd>3000</dd>
</dl>

上記の操作ができたら「作成」をクリック

作成後にできたURLをクリックして「Welcom to Loco website」が表示されたら完了！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/398501/27ff94d5-3c19-e89e-efcc-3fa9260a9c3a.png)


## 終わりに
いかがでしたでしょうか？
今回超ミニマムな環境構築を行いましたが、モデルやコントローラーもRailsライクに追加できるみたいなので色々試していきたいと思います。(あと型があるので最高)

それでは次回は@oryzae29さんです。

## 参考・引用

https://github.com/loco-rs/loco

https://dev.classmethod.jp/articles/rust-loco/
Tanzu PackagesでデプロイされたAppのStatefulSetのPVを拡張する

Tanzu PackagesでHarborのようなStatefulSetを持つAppをデプロイ後、StatefulSetのPVのサイズを変更しようとすると以下のようなエラーになる。

```sh
$ kubectl describe app -n my-packages harbor
：（省略）
    API server says:
      StatefulSet.apps "harbor-database" is invalid: spec:
        Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden (reason: Invalid)
```
これはStatefulSetがPVCのサイズの変更を許可していないためである。
このエラーが発生した際は、以下のように対処する。

1．PVCのサイズをvalues.yamlの値と合わせる
   
values.yamlで例えば2Giに変更した場合、以下のようにPVCも2Giに変更する。
```yaml
$ kubectl edit pvc database-data-harbor-database-0 -n tanzu-system-registry
：（省略）
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
```

2．StatefulSetを`Orphan`で削除する。

`kubectl delete`を実行する際、通常親リソースを削除すると子リソースも削除されるが、`--cascade=orphan`をつけると親リソースのみ削除できる。
これを使って稼働中のPodを止めずにStatefulSetのみ更新する。
```sh
$ kubectl delete sts --cascade=orphan -n tanzu-system-registry harbor-database
```

3．Appリソースのリコンサイルを待つ（もしくはspec.paused=trueを設定する）

リコンサイルが完了すれば、エラー状態が解消されてPVが正常に拡張出来る。
```sh
$ kubectl exec -it harbor-database-0 -c database -- df -h |grep postgres
/dev/sdc        2.0G   65M  1.8G   4% /var/lib/postgresql/data
```
Gather導入してみたけど、あまり浸透しなかった話

この記事は、[クラウドワークス Advent Calendar 2023](https://qiita.com/advent-calendar/2023/crowdworks) シリーズ1の12日目の記事です。

## はじめに
クラウドワークスの[@karukan029](https://qiita.com/karukan029)です。ハイクラス副業マッチングプラットフォーム[CrowdLinks](https://start.crowdlinks.jp/)の開発チームでエンジニアをしています。今回は[前回のアドベントカレンダー](https://qiita.com/karukan029/items/8e667cc521a9fa6bda66)で紹介したバーチャルオフィスサービス「Gather」を導入して1年経ち、過疎化してしまったことについてお話しします。これからバーチャルオフィスの導入を検討している方の参考にしていただけると幸いです。

## Gatherとは？
Gatherはバーチャルオフィスサービスです。リモートワークやオンラインでのイベントにおいて、物理的なオフィスや会場の体験をデジタル空間で再現することを目的としています。ユーザーはアバターを通じてバーチャルスペース内を自由に移動できます。Webミーティング機能も備えており、バーチャルスペース内の移動によってWebミーティングを開始できるため、より物理的なオフィスのような形で会話を始められます。

https://ja.gather.town/

## 過疎化してしまった原因
Gatherが過疎化してしまった原因は、2つあります。

### 運用ルールが設定されていなかった
導入当初は、ちょっとした会話や相談で活用していたSlackのハドルミーティングの代わりに利用しており、ミーティングに対する心理的障壁が軽減できていました。この形式での運用がうまくいっていたため、運用ルールを特に設定することなく今まで運用し続けてきました。

結果、SlackのハドルミーティングやGoogleのMeetなど、メンバーごとにちょっとした会話や相談レベルのMTGで用いるサービスがバラバラになり、GatherでMTGを実施する機会は導入当初と比べ減少しました。

### チーム状況の変化
導入当初、チームメンバーは7人いました。メンバーが増加していたタイミングであり、情報共有やコミュニケーションについて課題を感じていました。そこで、チームのtimesチャンネル作成に加えてコミュニケーション活性化のひとつとしてGatherを導入しました。主にチームメンバーのフォローやペアプロ・モブプロで活用されていました。(timesチャンネルの活用については、[前回のアドベントカレンダー](https://qiita.com/karukan029/items/8e667cc521a9fa6bda66#times%E5%88%86%E5%A0%B1%E3%83%81%E3%83%A3%E3%83%8D%E3%83%AB%E3%81%AE%E9%81%8B%E7%94%A8%E3%81%A7%E3%81%A4%E3%81%B6%E3%82%84%E3%81%8D%E3%82%92%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96)をご覧ください)

現在はチームメンバーが5人となり、導入当初よりチームメンバーが減少しました。メンバーが減少したことで、チームメンバーのフォローで活用する機会が減少し、Gather内でのMTGの実施回数も次第に減少していきました。同じタイミングで運用を開始したチームのtimesチャンネルが活発に活用されており、テキストベースでのコミュニケーションと定期MTGだけでもコミュニケーションが一定成立するようになりました。また、担当タスクが分かれていることが多く、ペアプロ・モブプロも実施することが無くなったため、必要に応じて相談するくらいの頻度で情報共有できれば十分になったことも過疎化した原因の1つです。

## なぜ運用を続けているのか
過疎化してしまったGatherですが、それでも運用を続けています。なぜかというと、一定の効果はまだあるためです。チャットでやりとりするの面倒だけど相談したいなくらいのコミュニケーションをとりやすくする効果は過疎化した今でもあります。ビジネスサイドの一部メンバーにも活用してもらっており、Gatherを利用してMTGをすることもあります。コミュニケーションのしやすさに一役買っているなら利用を継続してもいいかなと思っています。

また、新たなメンバーがジョインしてくることを考えるとあったほうがいいです。新たなメンバーがジョインするタイミングは特にコミュニケーションをとりやすくなる工夫が必要になります。チームメンバーのほとんどがリモートなので、チームに慣れるまではコミュニケーションコストは高くなりそうです。そのため、オフィスの相談しやすさに近づける工夫はできる限りあった方がよいと思っています。

## 過疎化は悪なのか？
利用しているサービスが過疎化した場合、その継続について検討することは重要です。もし利用にストレスを感じていたり、運用コストに見合わない場合は、使用をやめるべきでしょう。

そのようなネガティブな要因がなければ、継続することも選択肢となります。全部のMTGをGatherでやる、勤務中はGatherにいることをルール化すれば過疎化自体は解消できます。しかし、強制によるストレスや他チームとのMTGをGatherでやるか他のサービスを利用するかを判断が必要になるなどデメリットの方が大きいように思えます。無理に活用するよりは、ゆるく続けることが望ましいそうです。

## 最後に
いかがだったでしょうか？

Gatherの運用は今後も継続していき、より良い形で運用していけるよう改善を続けていきます。

導入したサービスの運用を続けるべきか、やめるべきか、無理にでも運用してもらえるようにルール化するべきか。0か100かで判断することも必要ですが運用自体が負担になっているわけではなければ、判断を先送りにするのも選択肢になりそうです。
「JSTQB FL アジャイルテスト担当者」のシラバス読書感想文

# 「はじめに」の前に

・JSTQBとは？
ソフトウェアテストの資格のひとつ。
https://jstqb.jp/committee.html

・アジャイルテスト担当者とは？
JSTQBは専門分野ごとにカテゴライズされております。
「JSTQB FL(Foundation Level) アジャイルテスト担当者」もその中の一つです。
https://jstqb.jp/syllabus.html

・「JSTQB FL アジャイルテスト担当者」のシラバスはこちら
https://jstqb.jp/syllabus.html#syllabus_foundation_extension

・君は誰？
QA組織のマネージメントをやっています。

# はじめに
スクラム開発に組み込まれたQAエンジニアが「スクラムのなかでQAとしてどう振る舞うのが良いのか」と、戸惑っている姿をたびたび目にします。スクラムの中にQAフェーズ(設計/実行の期間)を設けてみたりするものの(俗に言う(？)なんちゃってスクラム(=ちっちゃいウォーターフォール))、これでいいのかなと自問自答し、色々試行錯誤が続いている印象です。

試行錯誤は良いことですが、スクラムもそこそこ歴史がありますし、まずは先人の知恵を借りようじゃないか。ということで、JSTQBのアジャイルテスト担当者のシラバスを読んでみることにしました。内容を自分なりに咀嚼した上で、「アジャイル開発で、QAは何をすればよいのか？」を考えてみたいと思います。

なおタイトルにもあるように、当記事は**読書感想文** であり、シラバスのサマリーではありません。あしからず。

# 1章 アジャイルソフトウェア開発の基本
ウォーターフォールの時代は「入念な計画」が重要視されていました。
しかし、昨今は市場(=ユーザの要望)の変化が激しい時代になってしまったため、長期にわたる計画的な開発は、効果的ではないシーンが増えてきています。なるべく早くリリースし、ユーザの反応を見て、修正をなるべく早く行うことが重要です(=変化とスピードが大切)。

アジャイル開発は、「ユーザが求めているもの」を「なるべく素早くリリースする」ための考え方といえます。

# 2章 アジャイルテストの基本的な原則、プラクティスおよびプロセス
アジャイルテストにおいては、(ユーザとプロジェクトにとって利益となる)仕様の変化は歓迎しなければなりません。かつ、どのような状況でも、なるべく早くテストを終わらせる必要があります(「動くビルド」を素早く提供する)。

そのためのキーワードが「シフトレフト」「探索的テスト」「テスト自動化」になります。

ちなみに、これまでのQA組織は、仕様や計画の変化を避けたがる傾向にありますね。「仕様変更」と聞いて喜ぶQAを見たことがありません。しかし、このマインドセットはアジャイル開発では不利に働く可能性が高いです。変化を歓迎出来なければ、アジャイルQAとして成果を出すのは難しいかもしれません。

### 準備をどれだけ減らせるか。「テスト設計」というものを考え直す
これまでのテストとの大きな違いは「テスト設計」の扱いにあるかなと思います。ウォーターフォールではテスト設計の品質がプロダクトの品質に大きく関連していました。また、テスト設計に費やされる時間は、テスト工数全体の50%近くになるプロジェクトも見かけます。

しかし、一つ認識しておくべきことがあります。それは「テスト設計している時間は、サービスの品質向上に貢献していない」という点です。サービスの品質が向上するのは「テスト設計で作成した成果物をもとに、サービスを触った時」です。テスト設計は、あくまで準備なのです。

料理でいえば、テスト設計はレシピを考えている時間です。レシピをどれだけ考えても、味はしませんし腹は膨れません。

つまり、「テスト設計の時間をなるべく減らす。しかし、充分にテスト設計した状態と変わらない内容でテスト実行を行う」が理想的な状態といえるでしょう。

### シフトレフト
テスト設計をするな！というわけではありません。ただ、仮にテスト設計するのであれば、その内容は開発者にも共有するべきです。コーディングの段階でバグを潰すことができるでしょう。QAエンジニアは「品質のコーチ」としての役割も求められます。

### 探索的テスト
入念なテスト設計をせずとも、テスト実行の質を落とさない。そのために、探索的テストのスキルを向上させる必要があります。なお、本ドキュメントでは特に触れませんが、シラバスの第3章に探索的テストのノウハウが記されています。

### テスト自動化
細かい改修を重ねるアジャイル開発では、回帰テストは大切です。追加した機能や、改修した機能が、既存機能に影響を与えていないことを確認してこそ、安心してリリースが出来ます。

回帰テストは、システムの機能が増えるほテストケースの項目数が膨らんでいきます。また、リリースの頻度に比例して工数が増えていきます。品質を担保し、回帰テストの時間と工数を減らし、テスト担当者が探索的テストや開発者との対話の時間を確保するために必要なことが、「テスト自動化」です。


# 3章 アジャイルテストの方法、技法、およびツール
アジャイル開発で大切なことは、安定したビルド(品質が一定以上のビルド)を、継続的に迅速にデリバリーすることです。

そのためには、各セクション間(エンジニアとかQAとかPMとか)で、対話、協調、合意をベースにして、業務を進めていくことが求められます。適切なコミュニケーションによって業務を効率化し、それと同時に、可視化により不要な(というか過剰な)コミュニケーション(ドキュメンテーション含む)を減らすことを目指しましょう。

### QAに求められること
QAのタスクをブラックボックス化してはなりません。ツールを活用して、テストの観点、見積もり、テスト範囲、テスト結果、リスクを誰もが見えるようにしておくとよさそうです。

また、アジャイル開発のQAは、テストレベルによって求められる役割が異なります。具体的な一例は下記。

・対話やレビューを通して、関係者の品質意識を高めること
・開発者が作成するユニットテストのテスト観点の共有
・E2Eテストの自動化
・マニュアルテスト

上記のプロセスで成果を出すためには、コミュニケーションスキル(ペアワーク等の技法含む)、自動テストスキル、マニュアルテストスキル、開発プロセスへの理解、が必要となるでしょう。

# おわりに
私はアジャイル開発ではQAというロールに、幅広いスキル・素養が求められてるな、という感想を持ちました。

それは「難しい」という側面もあります。これまでのように「ドメイン知識が最低限あれば良し」という間口の広さは失われるかもしれません。一方で「いろんな長所を活かせる」とも言えると思います。開発が得意なら自動テストに寄せれば良いし、コミュニケーションを活かしたいなら対話で価値を出すこともできるでしょうし、マニュアルテストが得意なら爆速でハイクオリティなテストを提供することで価値が出せるかもしれません。

QAというお仕事は、システムと人間という複雑で曖昧なものと向き合う、とても奥が深いお仕事だと思うのでした。
藤村忠寿に一日のスケジュールを通知してもらうことにした

過去にnoteに書いた記事です。
(あくまで身内にですが)ちょっとした反響があったのでこっちにもリンク載せておきます。

[藤村忠寿に一日のスケジュールを通知してもらうことにした](https://note.com/guangen/n/n58a4f9956895)
AWS Lambda関数作成の流れ

AWS Lambda関数作成の流れ

## はじめに
自身で作成したAWS Lambda関数作成の流れの備忘録です💁
初心者です😅
間違えてる部分多々あると思います。
もし見つけた場合、ツッコミいただけると助かります🙇

始めてAWS Lambdaに携わる方などの少しでも参考になればいいなと思います😆

また各詳細はこれから、作成していく予定です。

## 作成したもの
「janコード」をリクエストしたら商品名と価格をレスポンスしてくれるAWS Lambda関数を作成

![unknown.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3522630/95930371-9435-b41c-1552-6e715f21c1a0.png)

￼
## 開発においての一連のプロセス
1. Pythonファイルで実行
2. CSVを読み込むデータを取得
3. API Gatewayを通してLambda関数へリクエスト
4. Lambda関数からリクエストあったものを処理
5. Lambda関数で処理した内容をPythonへレスポンス
6. PythonでCSVへ変換

この流れで稼働するように実装しました。


## 🦁 結論 🦁
### 作成順序
1. [<INS>AWSアカウントの作成](https://qiita.com/nyanyacyan/items/f533938e4f5d7960a32e)
2. [<INS>AWSの開発環境の構築](https://qiita.com/nyanyacyan/items/d1dd2fb874725226f9da)
3. [<INS>Lambda関数の開発とデバッグ](https://qiita.com/nyanyacyan/items/9644db9eb01bdc91d85b)
5. [<INS>IAMロールの作成と設定（途中まで作成したら、Step Functionsを設定する必要あり）](https://qiita.com/nyanyacyan/items/8b0bba4fe59b0c06a946)
6. [<INS>AWS Step Functionsの設定とデバッグ（完了後、IAMの権限にStep Functionsを追加）](https://qiita.com/nyanyacyan/items/004e0dc6145a0fc90b1d)
7. [<INS>API Gateway（発火API）の設定とデバッグ](https://qiita.com/nyanyacyan/items/3cd13fc016103d1de5c1)
8. [<INS>API Gateway（状態維持API）の設定とデバッグ](https://qiita.com/nyanyacyan/items/e96686b5b54b4059d2aa)
9. [<INS>Python（local環境）の開発とデバック](https://qiita.com/nyanyacyan/items/d76e98b0e6e9d9665a54)

この順序にて作成した方がいいと思います。

:::note info
押さえておくべき点
* AWSで書くコードはローカル環境とは少し異なっている。
* AWSは色々とサービスがあり、組み合わせることで利用できる。
* AWSはお金がかかるサービス。一定量、無料で使える
:::

:::note alert
注意点
* 無限ループなどの処理を利用する際には注意が必要（課金性があるため）
:::


## AWSで利用するサービス
### Lambda
関数を作成して実行できるようにする

### cloudShell
AWSのターミナルみたいなもの。環境構築の際に利用する。

### IAM
AWSのアクセス権限の設定をする。

### API Gateway
APIを作成して管理、公開、管理を行うツール。

### Step Functions
複数のAWSサービスを組み合わせて、一連の処理を自動で行うためのサービス。

### CloudWatch
ログを確認するためのサービス。

### S3
任意の量のデータをどこからでも保存および取得できるサービス。

## AWSの料金体系

### AWS Lambdaの料金体系
AWS Lambdaでは、使用したコンピューティング時間に基づいて課金される。
AWS Lambdaの無料利用枠には、1か月あたり100万件のリクエストと400,000 GB秒のコンピューティング時間が含まれている
[AWS Lambda 料金](https://aws.amazon.com/jp/lambda/pricing/)

### API Gateway料金体系
無料利用枠は最大12か月間、月間100万件のHTTP APIコール、100万件のREST APIコール、および月間100万件のWebSocket APIメッセージが利用可能。
無料枠を超えると従量課金制。
[Amazon API Gateway の料金](https://aws.amazon.com/jp/api-gateway/pricing/)

### Step Functions料金体系
無料利用枠は4000回/月まで。
[AWS Step Functions の料金](https://aws.amazon.com/jp/step-functions/pricing/)

## 参考にしたサイト📗
[AWS Lambda PythonでSeleniumを使える環境を構築する](https://dev.classmethod.jp/articles/aws-lambda-python-selenium-make-env/)
[【Selenium】ヘッドレスモード時だけ"element not interactable"になる](https://yuki.world/selenium-headless-chrome-not-interactable/)
[APIGatewayタイムアウト不可避を回避（神回避）](https://qiita.com/haruki-lo-shelon/items/9e5781668b0c92e955be)
2023年にMySQL Shellのデータダンプユーティリティにwhereオプションが追加されました＋α

この記事は[MySQL Advent Calendar 2023](https://qiita.com/advent-calendar/2023/mysql) 11日目の記事です。昨日は [yoku0825](https://twitter.com/yoku0825) さんの [MySQL公式のDockerリポジトリがcontainer-registry.oracle.comに引っ越していた | 日々の覚書](https://yoku0825.blogspot.com/2023/12/mysqldockercontainer-registryoraclecom.html) でした。

# はじめに
この記事では2023年にMySQL Shellのデータダンプユーティリティに追加された地味だけど便利な機能改善について伝えると共に、MySQLがユーザーの皆さんからのフィードバックに基づいて機能改善していることを伝えたいと思っています。

# 追加された機能
2023年1月にリリースされた[MySQL Shell 8.0.32](https://dev.mysql.com/doc/relnotes/mysql-shell/8.0/en/news-8-0-32.html)では、[データダンプユーティリティ](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html)に以下のオプションが追加されました。

---
[ダンプするデータを絞り込むためのオプション](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-opt-filtering)
- where
- partitions

whereオプションはSQLのWHERE句のように使えるので、特定の条件に合致するデータだけを抜き出せます。パーティショニングテーブルを使っている場合は、partitionsオプションを使って特定のパーティションだけを抜き出すこともできます。

---
[ダンプするデータの出力フォーマットを調整するためのオプション](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-opt-output)
- fieldsTerminatedBy
- fieldsEnclosedBy
- fieldsEscapedBy
- fieldsOptionallyEnclosed
- linesTerminatedBy
- dialect

出力フォーマットをcsv or tsvに変更したり、区切り文字や改行コードなどを細かく設定できるようになりました。

---

これにより、例えば古いデータをMySQLサーバーから削除したいけど必要に応じて再度ロードしたい、という場合などにもMySQL Shellのデータダンプ/ロードユーティリティを活用できるようになりました。なお、データのダンプ先、ロード対象にはファイルシステムだけでなく、オブジェクトストレージも指定できます。(オラクルクラウド、AWS、Azureのオブジェクトストレージを指定可能)


# この機能が追加された背景
私はオラクル社のMySQLチームで働いています。そして、2022年の8月にオラクルクラウド上でMySQLのマネージドサービスを使っている某ユーザーより「特定の日にちのデータだけを高速にMySQLから抜き出してcsv化したい」という要望を頂きました。

そこで、[MySQL Bugs](bugs.mysql.com)にMySQL ShellのDump&Loalユーティリティに対する機能改善リクエストを登録しました。その結果、今回紹介しているMySQL Shell 8.0.32での機能改善につながりました。

　※私が(オラクル社員が)MySQL Bugsに登録した場合、非公開バグ扱いになってしまうため、皆さんに内容を確認してもらうことができないのが歯痒いのですが、本件に関連した機能改善リクエスト(Feature request)を「[Bug #108062](https://bugs.mysql.com/bug.php?id=108062)」として登録しています。

もちろん、機能改善リクエストを登録すれば必ず対応してもらえる、というものではありませんが、その機能の重要性が開発チームに伝われば今回のように実装してもらえる可能性があります。
(今回の機能は実装が簡単な機能だったので直ぐに実装してもらえた、という背景もありますが)

# 皆さんに伝えたいこと
MySQLは[MySQL Bugs](bugs.mysql.com)を通してユーザーの皆様からのフィードバックを受け付け、機能改善に役立てています。MySQL Bugsという名前になっていますが、バグ報告だけでなく機能追加リクエストも受け付けていますので(※)、普段MySQLを使っていて感じている改善要望等があれば、是非気軽に登録して頂ければと思います！

　※機能追加リクエストを登録する際は、「Severity」を「S4 (Feature request)」にして登録して下さい。

明日は[@tomomo1015](https://twitter.com/yyamasaki1)さんです！
Vitis HLSにおける ERROR: [COSIM 212-330] Aborting co-simulation: top function ○○ is not invoked in the test bench. の解決法

## 概要
卒業研究でFPGAを使っている最中に遭遇したエラーと対処法について，エラーコードをググっても有益な情報が得られなかったためここに記しておきます．

## 状況
Vitis HLSにて自己組織化マップ(SOM)のハードウェア化を試みていたところ，C/RTL協調シミュレーション(Cosimulation)にて以下のエラーが発生．
```
ERROR: [COSIM 212-330] Aborting co-simulation: top function som is not invoked in the test bench.
```

エラーメッセージの内容は，「テストベンチの中でsomっていう関数が呼ばれてないよ」という意味．
somは今回作成しているシステムのカーネル(ハードウェア化する処理を記述した関数)で，当然テストベンチでちゃんと呼び出しているし，引数や戻り値も適切なはずでした．


## 原因および対処法
テストベンチにおいてカーネルのプロトタイプ宣言をしていなかったことが原因でした．
テストベンチのプログラム内にカーネルのプロトタイプ宣言を行うことでCosimulationが成功しました．
(単純な理由だったのでソースコードは載せていません．)