OmniAICreator/Qiita-1.07M huggingface dataset:
ArchLinuxのLiveCDをつくってみる

# はじめに
Linux®に限らずOSというものは、大抵マシンにインストールして使うものだと思う。しかし頻度が少なく、かつ特定の用途でのツールとして利用するのであれば、LiveCDでの利用が選択肢に入る。（あと特にWindowsインストール済環境の場合、デュアルブートはWindows Update関連で問題が起きるので避けたい）
そこで、今回はArchLinuxのLiveCDの作成とカスタマイズ手順を簡単にまとめた。

## ArchWiki
実は、本家ArchWikiにほとんどの手順が載ってる！

https://wiki.archlinux.jp/index.php/Archiso

本記事ではArchWikiの内容に、若干の追加手順を記載する。ただLiveCD作りたいだけならArchWiki見たほうが早いかも。

## 作業環境

LiveCDの作成のためだけにArchLinuxマシンを用意するのも手間なので、WSL2を利用した。構築は以下の記事を参考。

https://qiita.com/utyujin/items/71f65929a6313ecbd569

また、ArchLinuxのバージョンは2024-12-01-x86_64を利用した。

## 準備
ArchLinuxのLiveCDをビルドしてくれる```archiso```をインストールする。
```shell
$ pacman -S archiso
```
その後、archisoが用意してくれるプロファイルを作業ディレクトリにコピーする。
```shell
$ cp -r /usr/share/archiso/configs/releng/ archlive
```
このarchisoディレクトリをビルドすることで、LiveCDのISOを生成できる。
なお、```/usr/share/doc/archiso/README.profile.rst```にこのプロファイルの構造が記述されている。

## ビルド
下記のカスタマイズが済んだあとに、ビルドコマンドを実行する。

```shell
$ cp mkarchiso archlive
```
特にカスタマイズ不要ならば、そのままビルドしてしまって問題ない。

## LiveCDイメージのルートディレクトリ
```archlive/airootfs```がLiveCDイメージのルートディレクトリになる。
LiveCDのディレクトリ構造を編集したいときは、ここを編集する。

## パッケージ選択
```packages.x86_64```でLiveCDに内包するパッケージを記述する。記述は、一行に一つずつ記述する。
はじめからvimとか色々入ってるので、追加で必要なものはそんなに多くなさそう。目的に応じて追加していく。

# キーマップ
ArchLinuxのインストールをしたことがある方には説明不要かもしれないが、LiveCDのイメージはデフォルトでキーマップがUSキーとなっている。これをJISキーにしておくには、archlive/airootfs/etc/vconsole.confで指定する。
```bash
echo KEYMAP=jp106 > archlive/airootfs/etc/vconsole.conf
```

## 起動時メッセージ変更
起動時に表示されるメッセージがデフォルトではArchLinuxインストールのためのメッセージとなる。特定の用途のためのカスタムLiveCDであるならば、その用途での使い方を表示してほしいところ。
これは、通常のLinux同様```airootfs/etc/motd```を編集すれば良い。

## 起動時メニュー表記変更
移動時メッセージと同じ理由で、起動時の選択メニューの「Arch Linux install medium...」というメニューを変更する。これは、BIOSなら```archlive/syslinux/archiso_sys-linux.cfg```の当該箇所を変更する。なお、UEFIの場合は試していないが```archlive/efiboot/```内のファイルを編集するとのこと。

以下のように記述してビルドすると
```diff:syslinux/archiso_sys-linux.cfg
LABEL arch64
TEXT HELP
Boot the Arch Linux install medium on BIOS.
It allows you to install Arch Linux or perform system maintenance.
ENDTEXT
- MENU LABEL Arch Linux install medium (x86_64, BIOS)
+ MENU LABEL My Custom LiveCD medium sys (x86_64, BIOS)
LINUX /%INSTALL_DIR%/boot/x86_64/vmlinuz-linux
INITRD /%INSTALL_DIR%/boot/x86_64/initramfs-linux.img
APPEND archisobasedir=%INSTALL_DIR% archisosearchuuid=%ARCHISO_UUID%

# Accessibility boot option
(以下省略)
```
こうなる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3940069/4f03f16e-302a-7147-02df-786767fd9d50.png)
メニューの表記が「My Custom LiveCD medium sys」になった。やったね！

## その他
サービスは、systemctlでenableにしたとき生成されるシンボリックリンクを手動で配置する必要があるとのこと。（参考： [ArchWiki](https://wiki.archlinux.jp/index.php/Archiso#systemd_.E3.83.A6.E3.83.8B.E3.83.83.E3.83.88)）今回、私は利用しなかったので記載しない。
また、ユーザ作成やカーネル選択も、今回は必要なかったので記載しない。（LiveCDでユーザが必要なケースは稀では？）
注意点として、記事の最初の方にビルドする方法を記載したが、再ビルドするときには、ビルド時に生成されるworkディレクトリを削除しないと再ビルドされなかった。再ビルドする際は、このディレクトリを削除する必要がある。

## おわりに
今回、特定の用途向けツールとして使うためにArchLinux　LiveCDを作成する手順を簡単にまとめた。
はじめは、LiveCDのイメージを作るのには大変そうな先入観を持っていたが、やってみると全く難しくなかった。

---
※ Linux® は、Linus Torvalds 氏の米国およびその他の国における登録商標です。
※ Windowsは、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
NiagaraのマテリアルにColorを反映させる【UE5/UEFN】

![スクリーンショット 2024-12-20 180222.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/624aebdf-276b-34d8-84eb-b755461b1ace.png)

カラーのモジュールで色を設定し、いざレベル上に配置してみると。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/72358dc2-bd45-f112-5727-38917fb5bcd4.png)

デフォルトの色のまま…（今回は白のテクスチャを使っているので白だけが表示されてる）

これの対処法です。

## Particle Colorノード

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/7aec79b2-4f4c-194c-5871-fef264cf0684.png)

ということで、今回重要となるのは「Particle Color」ノードです。こちらは名前の通り、Niagara内で指定された「RPGA」の情報を出力するノードです。RPG(A)とあるように、アルファ（透明度）の情報も当然出力されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/c9eb8c3f-e46b-0993-4784-a920ece692a1.png)

では試しに、このようなつなぎ方をして確認してみます（Blend Mode: Translucent, Shading Model: Unlit）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/10e31a94-5f70-b149-9cc5-911c86422a5e.png)

するとこのように、グラデーションされてNiagaraが表示されます。次にNiagara内でColorにアルファ（透明度）を設定してみてください。すると…先ほどのマテリアルノードでは何も変化が起こらないはずです。それもそのはずで、先ほどParticle Colorは色の情報を示す「RGB」とは別に、透明度を示す「A」を出力するといいました。しかし、先ほどのノードにはA部分には何もしていません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/a807b20e-82a8-8cae-a62a-0cc0ba80e444.png)

なのでこのように、オパシティ（もしくはオパシティマスク）にAのピンをつなげてあげると。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/0f8d8f74-ba10-c3c8-a365-e7b66c4b9152.png)

このように透明度部分も表示に反映されました（半透明の場合は、背景の色を混ざった色になるはず）

## 好きな形

さて、これで完成！とはいきませんよね。

現状はマテリアルの標準の形である四角で固定されてます。ピクセル調のゲームなら合うかもしれませんが、もっと煙っぽかったり、複雑な形にしたいはず。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/80383e87-3ad3-db81-84d8-07028e2a41b6.png)

ということで、テクスチャファイルをマテリアルノード内に入れたら、TextureとParticle ColorのRGBAのピンをMultiplyで乗算し、カラーとオパシティにつなぎます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/37ba449b-669e-9869-457a-0ce10f9872fd.png)

すると画像の形のエフェクトに切り替わるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958482/80383e87-3ad3-db81-84d8-07028e2a41b6.png)

色に対するMultiply(乗算）は、色の合成みたいなイメージで大丈夫です。もともとは白単色のため、乗算するとParticleで設定した色がそのまま反映されるのです。例えばここを灰色の画像にしてみると、元の色から少しくすんだ色になります。

また、画像は透過素材を使っているため、透明度の情報もアルファとして持っています。
透明度は1が不透明だとして、0に近づくにつれて透明になっていきます。
そして、今回の例の画像ファイルだと形に添って縦横にアルファの情報が並べられているため、それに対しNiagaraのアルファを掛け合わせることで、

例えばNiagaraのアルファが0.5の場合↓
- 透明部分(0.0) × Niagara(0.5)で0.0の透明となり
- 不透明部分（1.0) × Niagara(0.5)で0.5の半透明となります。

これを縦横に画像のサイズだけ計算を行うことで、形を保ったままParticle Colorの透明度も反映できるのです。

と、マテリアルの細かい解説はすごい長くなってしまう気もするので別の機会に。

## 最後に
ということで、Niagaraの色をマテリアルに反映させる方法でした！
TouchDesignerユーザーへ向けた、PLATEAUの魅力

この記事はTouchDesignerユーザーへ向けた、PLATEAUの魅力解説です。
# 想像してみてください：
従来の3Dモデルでは「参考程度」の都市表現でしかなかった舞台が、PLATEAUをTouchDesignerで扱うことによって「あなたや来場者が暮らす、あの街そのもの」になります。国土交通省が定める精度基準に従って構築されているPLATEAUは、ただの3Dアセットではなく、公式に認められた精密な空間情報を内包した都市モデル。その都市空間は地理情報（GIS）や多彩なAPIとの連動が容易で、実社会で動いている交通状況、気象データ、人口動態など、リアルなデータセットをダイレクトに組み込むことが可能です。


# なぜ、これが特別なのか？
例えば、東京の特定地域をPLATEAUデータで表示し、そこに現在の交通混雑状況や気象APIから取得した気温変化、さらにはSNSトレンドや各種オープンデータをリアルタイム反映できたとしたらどうでしょう。触れると地域が生き生きと反応し、時間帯や季節によって変化が視覚化される——これは単なるCG表現ではありません。そこに暮らす人たちが、いつも見慣れた街の姿を、データに裏打ちされた生々しい動態として、直感的に理解できるようになるのです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616052/58ed112b-12cc-ad39-80c1-2d40ea58161b.png)
参照＊https://www.mlit.go.jp/plateau/libraries/technical-reports/?category=data

# 街が「自分ごと」になる瞬間
この「自分の住む街」を素材にした作品は、見る人を引き込みます。観賞者は、抽象的なグラフィックではなく、自分が現に存在する都市、あるいはかつて生活したことのある町、旅行で訪れたエリアを目にすることで、まるで自分自身がその空間の中に立ち、五感で感じ取れるような没入感を得ます。
街角の建物に関連するアート表現、データドリブンな光のパターン、特定通りをなぞるようなサウンドの反響——すべてが、リアリティと親しみを伴って迫ってくるのです。これにより、インスタレーションは「きれいなビジュアル」以上の存在に進化し、「あ、この街は実際こうなんだ」という共感や発見を導き出す体験へと昇華します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616052/53db26e3-6c91-aaa5-4107-f4551ea134db.png)

# クライアントからの評価と可能性の拡張
こうしたリアリティとデータ整合性を備えた都市ビジュアライゼーションは、スマートシティ関連や公共空間の情報展示、ブランドのローカルコミュニティへのメッセージ発信など、多種多様な案件で新しい価値を提供できます。「これは本当に、ここに存在する街です」と胸を張って見せることで、エンドユーザーやクライアントも説得力を感じ、ただの演出ではなく「意味あるインタラクティブメディア」として認知してもらえます。

# 属性情報が生む新たな奥行き
PLATEAUは、建物や土地に対し、高さや用途、築年数、素材、土地利用といった豊富な属性情報を持っています。これらの属性をTouchDesignerで操作することで、都市ビジュアライゼーションはさらに深みを増します。


**・用途や築年数による動的なレイヤリング：**
建物をその利用目的ごとにカラーリングしたり、築年数や歴史的変遷をアニメーション表示することで、実際の都市が経てきた時間や変化を可視化します。
**・データドリブンな意匠作り：** 
属性情報をキーに、気候・人口分布・エネルギー使用量など、外部のリアルタイムデータとリンクさせれば、都市はデータに反応する生きたキャンバスに。これにより、クライアントは都市そのものがインフォグラフィックとなった新たなブランドストーリーを示すことができます。

![スクリーンショット 2024-12-20 183004.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3616052/a9068fdb-59b7-8344-933f-f6b4bbbc2ac5.png)
属性情報は、都市をただの3Dオブジェクトではなく、「意味ある空間」に変えるカギです。TouchDesignerで得意とするプロシージャルな演出やインタラクション機能に、この本物のデータレイヤーを組み込めば、現実世界と観賞者との距離は急速に縮まります。魅せるだけでは終わらない、理解や発見を促す作品を生み出す強力な武器として、PLATEAUの属性情報を存分に活用してください。
初心者が感じたテスト自動化あるある

今年の4月にHITOTSUに入社し、Playwrightを使用したテスト自動化の実現に向けて日々取り組んできました。前職ではRPA開発に携わっていたものの、業務でコードを書く機会はほとんどなかったため、新しい分野に挑む期待と不安を抱えながらスタートしました。今回は、この9ヶ月間の経験を通じて感じた「初心者にありがちだな」と思うことについて書いてみたいと思います。
# テストコードを書くことに集中しがち
初心者にありがちなのが、テストコードを書くことにばかり集中してしまうことです。もちろん、テストコードを書くことは重要ですが、それだけではテスト自動化を実現することはできません。実際にテスト自動化を進めるためには、まずテストが動く環境を整えることが必要です。CI環境で何かを実行してみることを優先することで、テストコードが完成した際にスムーズにCI環境で動かせるようになります。
# 様々なテストを一度にやろうとする
できるだけ多くのテストを一気に実行したいという気持ちから、たくさんのコードを書き進めていました。しかし、中には難しい部分もあり、なかなか完成に至らず悩んでいました。そこで、最初の目標を「簡単な操作のテストを毎日回すこと」に設定し、一度に多くのことをやろうとするのを控えることに決めました。実際、毎日回してみると、簡単な操作のテストでも失敗することが多々ありました。失敗の原因はさまざまですが、大抵は要素の出現を待機するなどの工夫で、失敗を減らすことができました。もし最初に多くのテストを一度に作成して実行していたら、一気に多くの失敗が発生し、対応が大変になっていたかと思います・・。
# 自動テストは多ければ多いほど良いという考え
はじめは、できるだけ多くのテストを自動化した方が良いと考えていました。しかし、テストについて学んでいくうちに「テストピラミッド」という概念を知りました。テストピラミッドとは、テストの種類を階層的に分けたもので、理想的にはE2Eテストが一番少なく、下層に位置するユニットテストやサービスレイヤーのテストが多くなる構造です。

なぜテストピラミッドが有効かというと、E2Eテストは実行に時間がかかり、壊れやすいため、継続的にメンテナンスするのが難しいという点があります。一方で、ユニットテストは個別の機能を高速にテストでき、変更にも素早く対応できます。ユニットテストを多く実施することで、システム全体の動作を確認する前に個別のバグを早期に発見でき、効率的に品質を保つことができます。したがって、「自動テストは多ければ多いほど良い」という考えは正しくないということです。

# 最後に
まだまだ分からないことや、どうすべきか悩んだりすることもあり、学ぶべきことは多いですが、これからも試行錯誤しながら、より効率的で安定したテスト自動化を実現していきたいと思います。
【UiPath】「疎結合」でワークフローを作ろう

プログラミングでは各要素がお互いに強く依存している「密結合」よりも、お互いの関わりが薄い「疎結合」のほうが保守性などの面において優れるとされている。
UiPathにおいても考え方は同じで、操作を入れ子にしすぎず分けて作成することで、より保守しやすいワークフローになる。

## 実装例

今回は以下の要件のワークフローを作成する。

- Qiitaにログインする。
- トップページからアドベンドカレンダーがあと何日で終了するかを取得する。
- Excelに書きこむ。
- Qiitaからログアウトする。

#

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/c9706298-1b02-c4ba-41c5-25ea2a6fde5f.png)

要件の処理順番の通りに書いたのが上記のワークフロー。動作としては問題ないが、「ブラウザーを使用」の中にExcelの処理が入っているため、ブラウザの部分やExcelの部分だけテストしたりといったことが難しい。

#

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/baa706bd-c633-ba93-30e1-80333779b42c.png)

「疎結合」を意識して少し改良を加えたのが上記のワークフロー。「Qiitaログイン→値取得→Qiitaログアウト→Excel出力」の順に処理するよう変更し、ブラウザの処理とExcelの処理を分離した。これにより、各要素の単体での動作確認がしやすくなり、保守しやすくなっている。

## 参考
https://qiita.com/Guz9N9KLASTt/items/e4ed966fc889d019c725
統計検定1級合格体験記、皆様への還元

## はじめに
2024年度統計検定１級統計応用に合格（A評価）し、2021年度に取得した統計数理と合わせて統計検定1級を取得することができました！

![投稿用画像し.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/346827/36c57b2d-325a-9622-bb69-8449ea9a24f1.png)

## この記事で触れること
統計検定1級合格にあたって有益な情報を残すために体験記および対策を残します。

 - 合格までの道のり
 - 必要な知識・バックグラウンド
 - 勉強法（試験対策）
 - 試験当日のこと
 - 結果発表を受けて

## 1.合格までの道のり
大学時代に授業で統計学を勉強したことがあり、せっかく大学で統計を学んできたので、2021年度のタイミングで統計検定1級を受験しました。その時は統計数理のみ合格し、統計応用（理工学）は不合格となってしまい、苦い思い出がありました。
以降はあまりいい思い出がなかったのですが、社会人になり月日がたったこのタイミング2024年度に再度落ちてしまった統計応用（理工学）に再挑戦し、見事合格することができました！

 - 2021年度：数理統計　合格
 - 2024年度：統計応用（理工学）A評価合格

## 2.必要な知識・バックグラウンド
 - 微分積分（少なくとも数Ⅲ）
 - 線形代数
 - 基本的な統計学の知識
 
は必要かなと思いますので、まずは簡単な教科書から勉強することをお勧めします。ちなみに、統計学に関しては自分が大学時代授業を聞いても全く理解できなかったので、本当に初歩から勉強を進めました。（自分が基本的な統計学の知識を身に着けるため大学3年頃でたどった順番です）
　→　この内容は統計検定1級でなくても、準一級、二級を受けるうえでも十分に役立つ

### ①.完全独習統計学入門　著：小島寛之　出版：ダイヤモンド社
 - 数式等を用いずに統計に関する考え方がすっと入ってくる
 - まずはこれを2～3周して考え方を身に着けた

https://amzn.asia/d/h86P0IN

### ②.統計学キャンパスゼミ　著：馬場敬之　出版：マセマ
 - 大学生向けの本だが、解説がものすごく丁寧に記載されており、数式等を用いて自分の知識定着が図れた
 - 個人的に中心極限定理の証明パートの説明が鬼わかりやすい

https://amzn.asia/d/5zm4QHk

### ③.明解演習数理統計　著：小寺平治　出版：共立出版株式会社
 - 40年以上前の本だが、2までやった内容の演習を行うことで知識がめちゃくちゃ定着した
 - 古い本だからと言ってなめちゃいけない。重要なエッセンスが詰まっている

https://amzn.asia/d/eR2X7W7

### ④.数理統計学-基礎から学ぶデータ解析- 著：鈴木武、山田作太郎　出版：内田老鶴圃
 -　いわゆる大学の授業で利用するような教科書
 -　かなり細かい内容まで記載されており、統計応用を受験する上で必要な知識が乗っている。

https://amzn.asia/d/9fmioSe

# 3.勉強法（試験対策）
※他の合格体験記と大きく異なるので注意※
まず試験対策という意味でいうと、
 - 過去問(2012年～2023年）：90％
 - 未知の分野の教科書読み（公式の統計本、理工学で出てくる実験計画の本）：10%

しかやっていません。ほぼ過去問頼りの試験対策となります。
 - 2021年時は、2012年度～2019年度までの数理統計、統計応用の過去問を3周ずつ
 - 2024年時は、統計応用の過去問2012年～2023年を3周ずつを行いました

最初は全く正解できませんでした。ただ、試験に合格することも目的とするならば、それが一番近道だと思います。

```
過去問挑戦　→　何とか考えて解答を絞りだす　→　回答見て理解する、自分との差分を分析する　→　足りない知識を教科書で補う
```
これを繰り返すことが、最も効率的です。（1問解くのに時間はかかりますが）

21年度に統計応用で落ちた要因は、未知の分野の問題（確かあの年に決定木の問題出て何それってなり動揺したことだと思ってます。なので、24年度から未知分野への対策をしましたが、基本路線は変わらないです。

# 4.試験当日のこと
  - 21年の時は、初めて且つ長丁場2連荘だったので、結構疲れました
  - 24年の時は、1科目だったのと立川にある統計数理研究所で受けたのでそのパワーもあったかもしれません（笑）
  - やっぱり過去問ベースで勉強していることで試験の形式や問題の特性はよく理解できていて、怖じ気ずくことなく太刀打ちできたかと思います。
  - 具体的な点数はわかっていませんが、自己採点感覚50%～60%くらいかなと思っています。（具体的な数値が出ないので参考までに）
  - ※重要※わからない問題でも最初の方に方針（○○して解けば導ける、等）を記載しておくと点数に繋がるかも（仮説）

# 5.結果発表を受けて
 - 自己採点感覚的に落ちたかもしれないなぁ、、、と思っていましたが蓋を開けてみたらA評価合格でした。
 - 例年の問題との難易度と受験者平均を鑑みても、自己採点感覚とずれていないのでわんちゃん最初の方針だけ書いたのが効いたのかも？ｗと思っています。
 - という冗談半分もありつつ、やっぱり本番においてとるべき問題とらない問題（普通に考えたり計算したら絶対に時間が足りない問題）を取捨選択できて、とるべきところをとれたのが良かったと自分で分析しています。


# 最後に
 - 統計検定1級を取って今後どう活かしていくのか今後の課題だと思っています。（社内で言っても、お～すごいね！、で終わってしまうので）
 - 持っているからこそできることを見つけ、勉強頑張った意味を見出したいと思います。
 - （こういう使い方敬われ方笑、があるって方いたら教えてください）
問題: JavaScript には参照渡しはありません

参照渡しでググると 参照渡しできない言語なのに 参照渡しができるような記事がごろごろみたいな例がまままままあるのがよくあります。

勿論 JavaScript は 参照渡し の「無い」言語です。
何故なら 変数の 参照を 引数に直接渡すことができないからです。

勿論、後述の方法で 参照渡しが無くても参照を渡す方法は無いわけではない為、参照渡しができるようにする 野良プロポーザルとかもあります。

https://github.com/rbuckton/proposal-refs

で、参照渡しの話ですが、
Wikipedia だと 参照渡しの説明としては次の様にあります。

> # 参照呼び
> 参照呼び（call by reference、参照渡し: pass by reference）では、仮引数が実引数そのもの、すなわちエイリアス（[Aliasing]( https://en.wikipedia.org/wiki/Aliasing_(computing) )）になる。実引数は、左辺値を持たねばならない（[Pascal]( https://ja.wikipedia.org/wiki/Pascal )のように、実引数を変数に限定した言語もある）か、左辺値を持たない式の場合は呼び出し側で一時的オブジェクトを構築する言語もある。
> https://ja.wikipedia.org/wiki/%E8%A9%95%E4%BE%A1%E6%88%A6%E7%95%A5#%E5%8F%82%E7%85%A7%E5%91%BC%E3%81%B3

つまり、参照渡しは 仮引数が 実引数のエイリアス関係にある状態の渡し方であるということです。

C# の資料からですが別の説明を。

> "参照渡し" は、メソッドに変数へのアクセスを渡すことを意味します。
> https://learn.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/method-parameters

変数そのものを渡していると解釈してもよさそうです。

# 本題の問題

で 今回言いたかったのは次の問題。 ① が 1,2 ② が 2,1 を出力する場合、関数 swap の実装③はどうなるか といった 問題です。

```js
let a1 = 1;
let a2 = 2;
console.log(a1, a2);
// ① -> 1, 2
swap(a1, a2);
console.log(a1, a2);
// ② -> 2, 1
function swap(a, b)
{
    // ③
}
```

# 解説

Javascript は 変数へのアクセス(=参照)を取得する方法は実は幾つかある言語です。
ただ、変数自体を引数に渡す方法は無いです。

例えば import した変数は モジュールで定義された変数の参照 であり、且つ エイリアスとして別名にすることもできます。（※ただし、import 先では読み取り専用で代入を許容しない）

例えば クロージャ は 関数の外にある 変数そのものを扱うことができます。

そうです。 クロージャです。

つまり次のが正しい答えです。

# 答え

```js
let a1 = 1;
let a2 = 2;
console.log(a1, a2);
// -> 1, 2
swap(a1, a2);
console.log(a1, a2);
// -> 2, 1
function swap(a, b)
{
    [a1, a2] = [a2, a1];
}
```

# 終

以上、 参照渡しという仕組みを持たなくても 変数にアクセスできるのであれば 変数自体を書き換えることだってできます。

という話でした。
【UiPath】「あれ？今宣言した変数どこいった？」となったらデータマネージャー

UiPath Studioでは変数宣言時、スコープは最小の範囲で設定される。
具体的に言えば、変数作成時にフォーカスしていたシーケンスをスコープとして作られる。



![メディア1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/7c87cfda-67b0-7015-8748-a65dbb621340.gif)



「変数のスコープは最小限にする」というプログラミングの考えに基づく仕様だが、UiPathの変数ウィンドウでは現在選択しているシーケンス（スコープ）に含まれる変数しか表示されないため、うっかり意図しないシーケンスを選択したまま変数を宣言してしまい、宣言したばかりの変数を見失ってしまうことがしばしばある。
そんな時に役立つのがデータマネージャーだ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/839ef3b4-183e-822f-9e7a-bd59e7e94de0.png)

データマネージャーの「変数」欄には変数が宣言されているシーケンスのみが表示されるため、デザイナーパネルで一つ一つシーケンスを開いていくより効率的に変数を探すことができる。変数名の目星がつくのであれば「データを検索」から検索してもよい。

## 参考

https://qiita.com/ETech222/items/432bc1523b55a3ec07fc
Vue 3におけるTSXとComposition APIの組み合わせについて

# Vue 3におけるTSXとComposition APIの組み合わせについて

Vue 3は、Reactのようなモダンなフレームワークであり、UIの構築に非常に柔軟性があります。Vue 3の主要な新機能の1つが**Composition API**で、これはコードをより効率的かつ再利用可能にするための新しい方法を提供します。一方、**TSX**（TypeScript XML）は、TypeScriptとJSXを組み合わせたものです。今回は、Vue 3で**TSX**を使用し、**Composition API**と組み合わせてUIコンポーネントを作成する方法について紹介します。

## **TSXとは？**

**TSX**は、**TypeScript**と**JSX**を組み合わせた構文です。JSXは、Reactでよく使用される構文で、HTMLのようなタグをJavaScript内で記述することができます。TypeScriptは、JavaScriptに型安全性を提供するスーパーセットです。TSXは、これらを組み合わせて、TypeScriptの型安全性とJSXの直感的な記述方法を提供します。

Vue 3は基本的に**テンプレート構文**を使用してUIを作成しますが、TSXを使うことで、JSXのようにUIを作成でき、より動的で柔軟なコードを書くことができます。特にTypeScriptとの組み合わせによって、型安全性が強化され、開発者にとっては大きなメリットとなります。

## **TSXを使う理由**

- **型安全性**: TypeScriptとTSXを使うことで、コンポーネントのプロパティや状態に型を指定し、開発中にエラーを早期に発見できます。
- **柔軟性**: Composition APIとTSXを組み合わせることで、コードをよりモジュール化し、再利用性の高いコンポーネントを作成できます。
- **直感的な構文**: JSXとTSXはHTMLライクな構文なので、視覚的に直感的で、HTMLのような記述方法に慣れている人にとっては非常に使いやすいです。

## **Vue 3でTSXとComposition APIを使ったコンポーネントの作成**

Vue 3でTSXを使うには、まずプロジェクトの設定を行う必要があります。ここでは、**Vite**を使った設定方法を説明します。

### 1. **必要なパッケージのインストール**:
Vue 3とTSXを使うために、以下のパッケージをインストールします。

```bash
npm install vue@next @vitejs/plugin-vue @vitejs/plugin-vue-jsx
```

### 2. **Viteの設定**:
Viteの設定ファイル(vite.config.ts)に、TSXをサポートするプラグインを追加します

```typescript
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import vueJsx from '@vitejs/plugin-vue-jsx';

export default defineConfig({
  plugins: [vue(), vueJsx()],
});

```

## **TSXを使ったコンポーネントの例**

ここでは、簡単なカウンターコンポーネントをTSXとComposition APIで作成します。
```typescript
// Counter.tsx
import { defineComponent, ref } from 'vue';

export default defineComponent({
  name: 'Counter',
  setup() {
    const count = ref(0);

    const increment = () => {
      count.value++;
    };

    return () => (
      <div>
        <p>Count: {count.value}</p>
        <button onClick={increment}>Increment</button>
      </div>
    );
  }
});

```
RegexValidateError混乱する

# はじめに
Djangoで正規表現のバリデーションを作成していて、混乱したところについて記述しました。

# RegexValidateErrorとは
valueがどのようなときにエラーがでるのかで混乱しました。
公式ドキュメントより、以下の記述があります。

> RegexValidator は、与えられた value を指定された正規表現で re.search() で検索します。デフォルトでは、一致が 見つからない 場合に message と code を持つ ValidationError を発生させます。
（参考:[https://docs.djangoproject.com/ja/5.1/ref/validators/](https://docs.djangoproject.com/ja/5.1/ref/validators/)）

ここから、**指定した正規表現とvalueが一致しないときにエラーが出る**ということがわかります。

> inverse_match を True に設定することで、動作を逆にできます。この場合、一致が 見つかった ときに ValidationError が発生します。
（参考:[https://docs.djangoproject.com/ja/5.1/ref/validators/](https://docs.djangoproject.com/ja/5.1/ref/validators/)）

**inverse_match**をつけると**指定した正規表現とvalueが一致するときにエラーが出る**ことになります。文章に直すと否定がない分こちらの方が好みです。

# 例：全角数字の制限
例えば、電話番号など半角数字で入力してほしいものを全て全角数字で入力されている場合、どのようなバリデーションになるでしょうか。

以下のように実装できます。

```
 RegexValidator(r'^[^０-９]+$', '全角数字は使用できません。')
```
使用した記号のおさらい（参考:[https://www.megasoft.co.jp/mifes/seiki/meta.html](https://www.megasoft.co.jp/mifes/seiki/meta.html）))

| 記号 | 意味 | 例 |
|:-:|:-:|:-:|
| ^  |  行頭 | 「^あ」　→ 「あ」から始まる  |
|[^〜]　　|  ～に含まれない１文字 | [^あいう] → 「あ」「い」「う」以外の１文字  |
| + |  直前のものを1回以上 | 「あ+」 → 「あ」を１文字以上 「あ」の前には何が入っていても良い |
|  $ | 行末  |  「あ$」　→ 最後の文字が「あ」|

**指定した正規表現と一致しないとき**にエラーがでるので
正規表現は通したいvalueについて書くことになります。

全角文字の制限を行う場合、通したいvalueは**全て全角の数字で書かれていない**文字列です。そこで「全て全角の数字で書いている」に否定をつけているんですね。


# まとめ
以上、短いですがRegexValidatorと正規表現についてでした。「**指定した正規表現と一致しないとき**にエラーがでる」をとりあえず覚えます。記事も結局ウンウン悩んで書きました。
【GPTプロンプト講座基礎編⑥】プロンプトエンジニアリングを極めるためのマインドセットと学び方

# §プロンプトエンジニアリング基礎編⑥
※本記事は執筆にあたり生成AIツールを使用している箇所があります
※プロンプトの基礎部分は生成AIで作成し、具体例や体験談を自分の視点で補完しています

こんにちは。ゆずかきです。
前回は、高度なプロンプトエンジニアリングにおける応用例を紹介しました。今回はさらに一歩進み、AIを最大限活用するために重要な「マインドセット」と「学習方法」をお話しします。
プロンプトエンジニアリングは、単に技術を身に付けるだけではなく、日々の考え方や取り組み方も大きな影響を与える分野です。これを押さえることで、あなたのAI活用スキルがさらに進化しますよ！


# §プロンプトエンジニアリングを支える3つのマインドセット
プロンプトエンジニアリングに取り組む中で、私が大切だと感じる考え方を3つにまとめました。

#### 1. 試行錯誤を楽しむ
プロンプトエンジニアリングは、正解が一つではないのが特徴です。むしろ、「これで完璧だ！」と思ったプロンプトが全然期待通りに動かないこともよくあります。

私も以前、「就職活動で強みESを書いて」と指示したのに、なぜか別の専門性での強みESが出てきたことがありました。
何が悪かったのかと振り返ると、自分の背景を含む文脈をAIにきちんと伝えていなかったことが原因でした。
　
**失敗するたびに原因を探り、新しいプロンプトを試してみる**
　
AIと付き合う上で最も大切かもしれません。
このプロセスを楽しむことが、上達の道です。 
「まずはやってみる」という姿勢でどんどん実験しましょう！

#### 2. シンプルさを追求する
プロンプトが複雑になるほど、AIが意図を正しく読み取れなくなるリスクが高まります。だからこそ、「できるだけ短く、要点を絞る」ことを意識しましょう。

例えば、以下のようなプロンプトを比較してみます。

- 悪い例: 「このテキストを見て、何かを要約して、それを初心者向けに書き直して、その後に追加情報も加えて、箇条書きにしてください。」
　
- 良い例: 「このテキストを、初心者向けに3つのポイントで要約してください。」

良いプロンプトの方が、明確でシンプルですよね。
　
**シンプルなことは、悪いことではありません。美学です。**
　
「自分の意図が伝わらない場合は、もっと簡潔にできないか？」と考えるクセをつけることが大切です。

#### 3. AIを「相棒」と考える
AIは万能な存在ではなく、あくまで補助的なツールです。プロンプトエンジニアリングを通じて、 「AIをどう使いこなすか」 を考えることが重要になります。

たとえば、AIに「エッセイを書いて」と頼むだけでは、期待通りの結果は得られません。けれど、具体的な構成やトーン、長さを指定すれば、アウトプットの精度が一気に上がります。
　
**AIを一方的に「命令する」ものと考えるのではなく「共に成果を作るパートナー」として接する**
　
このマインドセットを持つことで、もっと深い活用が見えてきます。


# §プロンプトエンジニアリングを学ぶ効果的な方法
次に、プロンプトエンジニアリングを効率的に学ぶための方法を紹介します。これらを意識することで、短期間でスキルアップが期待できます。

#### 1. 小さな成功体験を積み重ねる
まずは、単純なタスクから始めましょう。たとえば、「テキストを50字以内で要約して」といった基本的なプロンプトです。小さな成功体験を重ねることで、AIの反応を理解しやすくなります。

さらに、成功したプロンプトを記録しておくのもおすすめです。成功パターンを蓄積していけば、いざという時に応用できる引き出しが増えます。

#### 2. 実際の課題に挑戦する
プロンプトエンジニアリングは、実務や趣味の中でこそ本領を発揮します。自分が抱えている課題や、興味のある分野にAIを活用してみましょう。

たとえば、私はブログ記事を書く際に、AIに「このテーマでキャッチフレーズを考えて」と頼むことがあります。AIが出してくれた案を参考にしつつ、自分なりにアレンジを加えることで、効率的に記事作成が進められました。

#### 3. 多様なプロンプトを試す
同じタスクでも、プロンプトの言い回しや出力形式を少し変えるだけで、AIの応答が大きく変わります。
たとえば、以下のように出力形式を工夫してみましょう。

- 「箇条書きで要約してください」
- 「初心者向けに200字以内で解説してください」
- 「3つのポイントを挙げ、それぞれ簡潔に説明してください」

このようにプロンプトを多様に試していくことで、AIの挙動や特性をより深く理解できます。

#### 4. 他の人の成功例を参考にする
プロンプトエンジニアリングは、他の人が試したプロンプト例を参考にすることで、自分のスキルを効率的に伸ばせます。

たとえば、Qiitaやブログで共有されている成功プロンプトを研究し、それを元に自分の課題に合わせてアレンジするのがおすすめです。読者として学びながら、自分のアイデアを育てていきましょう。


# §まとめ
プロンプトエンジニアリングを極めるには、技術的なスキルだけでなく、適切なマインドセットと効率的な学習法が欠かせません。

試行錯誤を楽しむこと、シンプルさを追求すること、そしてAIを相棒として活用すること。この3つを意識しつつ、小さな成功体験を積み上げ、多様なプロンプトを試していきましょう。

**🔑 この記事のポイントまとめ**
**試行錯誤を楽しむ → 失敗を分析し、改善プロンプトを繰り返すこと！**
**シンプルさを追求 → 短く、要点を絞った指示を意識せよ。**
**AIを相棒と考える → 命令ではなく共に成果を作る意識を持つこと。**
**小さな成功体験を積み重ねる → 基本タスクから始めて学びを蓄積せよ。**
**多様なプロンプトを試す → 言い回しや出力形式を変えてAIの特性を理解せよ。**
　
次回は、実際にプロンプトをどうシステム化して活用するかについて掘り下げていきます。どうぞお楽しみに！

ご訪問いただきありがとうございました！
【UiPath】「HTTP要求」でkabuステーションAPIから日経平均を取得する【kabuステーション】

以下の記事の続き。
前提としてトークン取得が必要なので、そこまでの流れはそちらを参照してほしい。

https://qiita.com/Davoi/items/7dd8e1546b477066b24d

## 実装
以下がワークフロー全体。一つ目のHTTP要求はトークン取得の記事で解説しているので、ここでは二つ目のHTTP要求から解説する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/7e317559-a460-b047-873f-6b334ec77cdb.png)

初めに、複数代入で任意のString型変数（ここでは`symbol`と`exhange`）にそれぞれ`101`（日経平均の銘柄コード）と`1`（東証の市場コード）を代入する。これらはHTTP要求のリクエストURLに使用する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/b7f184b9-3d34-d460-4300-84866d795163.png)

ここから二つ目のHTTP要求の設定。一つ目のHTTP要求の設定から、以下の点を変更する。

- エンドポイント：`"http://localhost:18080/kabusapi/board/" & symbol & "@" & exchange`
- 要求メソッド：`GET`
- ヘッダーの`Accept`を削除し、新たに以下の設定を追加
    - 名前：`X-API-KEY`，値：`jsonResponse("Token").ToString`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/3cfc9c1b-17e3-ccde-b33e-c264c0b9a033.png)

「本文」は不要なので削除し空欄にしておく。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/d0f21df0-ed39-36d7-08b5-c3a68ef08d92.png)

トークン取得時と同じように出力された変数を逆シリアル化し、値を抽出する。今回は現在価格を取得するよう「1行を書き込み」には以下を設定した。

- `"日経平均: " &  jsonResponse("CurrentPrice").ToString`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/363ae2bc-545e-6483-ee7d-5b60b58e3b4d.png)

実行結果がこちら。無事に日経平均を取得できた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/578020/fac5d866-0032-ab8a-26a9-687a77f17815.png)

## 参考
https://qiita.com/Davoi/items/315652b2980e3b552c4b

https://qiita.com/hmdsg/items/c6842fe87ec4e0365241
○○年△月形式のデータをYYYYMM形式に変換する方法

業務で○○年△月(西暦下二桁+1~12月)形式のデータをYYYYMM形式への変換を行ったので、正規表現の使い方の記録として残します。

# 手順

①00年~24年のデータを2000年代として置換
```
< \b(0[0-9]|1[0-9]|2[0-4])年(\d{1,2})\b
> 20$1$2
```
②残りのデータを1900年代として置換
```
< \b(\d{2})年(\d{1,2})\b
> 19$1$2
```
③1~9月を01月~09月に変換
```
< \b(\d{4})年(\d{1})\b
> $1年0$2
```

# 正規表現の復習
```[]``` ```{}```については省略。
文字|説明
--|--
\b|単語の先頭・末尾を表す
\d{n}|n桁の数字を表す
$n|n番目のキャプチャグループを表す

※キャプチャグループ……正規表現の中で```()```でまとめられた要素

参考：https://qiita.com/List202/items/05a27c46d9b11d04fb39
BigQuery Editionsの管理プロジェクトの費用を各プロジェクト毎に分割する

BigQuery Editionsを利用する時には、Reservationを作成するための専用のプロジェクト(管理プロジェクト)を作成することが推奨されています。このような構成にすることで複数のプロジェクトで1つのReservationを共有したり、あるReservationで余ったスロットを別のReservationにお裾分けすることができ、コスパ良くBigQueryを利用できます。

https://cloud.google.com/bigquery/docs/reservations-intro#admin-project

しかし、この構成を取ると請求コンソールや請求情報のBigQueryエクスポート的には管理プロジェクトが全ての費用を使っているように見えてしまいます。BigQueryのコスト管理をする際には各プロジェクトの費用が分かっている方がやりやすいため、管理プロジェクトの費用を各プロジェクトに分割する方法を紹介します。

まずは、以下のクエリでそれぞれのReservationに所属するプロジェクト毎のSlot利用割合を求めます。
GCPの費用はPST(米国西海岸時間)で月次の締め処理が行われるため、タイムゾーンをPSTにしてあります。

```sql
with consumed_slot_hour_by_reservation_project_date as (
  select
    reservation_id,
    project_id,
    date(creation_time, 'America/Los_Angeles') as date_pst,
    ifnull(sum(total_slot_ms), 0) / 10000 / 60 / 60 as slot_hour,
  from `<INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION>`
  where reservation_id is not null and reservation_id <> 'default-pipeline' and
  job_type = 'QUERY' and 
  statement_type != 'SCRIPT' and
  creation_time > current_timestamp - interval 30 day
  group by all
), reservation_consumption_rate_by_project_date as (
  select
    * except(slot_hour),
    slot_hour / sum(slot_hour) over (partition by reservation_id, date_pst) as reservation_consumption_rate,
  from consumed_slot_hour_by_reservation_project_date
  order by reservation_id, date_pst, project_id
)
```

次に、このクエリで各Reservationに割り当てられたSlot時間の積算値を日毎に求めます。

```sql
with assigned_slot_by_reservation_date as (
  select
    reservation_id,
    date(period_start, 'America/Los_Angeles') as date_pst,
    sum(slots_assigned + autoscale.current_slots) / 60 as slot_hour,
    edition,
  from `<INFORMATION_SCHEMA.RESERVATIONS_TIMELINE>`
  where period_start > current_timestamp - interval 30 day
  group by all
)
```

最後に上記の2つの情報を組み合わせることで、Edition毎・プロジェクト毎にどのプロジェクトが何割の費用を発生させているのかを求めます。

```sql
with assigned_slot_by_project_date as (
  select
    reservation_id,
    edition,
    date_pst,
    project_id,
    slot_hour * reservation_consumption_rate as slot_hour,
  from reservation_consumption_rate_by_project_date
  left join assigned_slot_by_reservation_date
  using(reservation_id, date_pst)
), cost_consumption_rate_by_project as (
  select
    date_pst,
    edition,
    project_id,
    slot_hour / sum(slot_hour) over (partition by date_pst, edition) as cost_consumption_rate,
  from (
    select
      date_pst,
      edition,
      project_id,
      sum(slot_hour) as slot_hour
    from assigned_slot_by_project_date
    group by all
  )
)

select * from cost_consumption_rate_by_project
```

このクエリで出力された `cost_consumption_rate` をそれぞれの日のそれぞれのエディションの費用に対して掛けると、管理プロジェクトの費用を各プロジェクトに分割できます。
【PowerShell】kabuステーションAPIから指定した市場・銘柄の現在価格を取得する【kabuステーション】

以下の記事の続き。
前提としてトークン取得が必要なので、そこまでの流れはそちらを参照してほしい。

https://qiita.com/Davoi/items/315652b2980e3b552c4b

## コード
```PowerShell
function Get-KabuAPIToken {
    param (
        [string]$BaseUrl,
        [string]$ApiPassword
    )

    # kabuステーションAPIの設定
    $tokenEndpoint = "$BaseUrl/token"

    # トークン取得のリクエストボディ
    $body = @{ "APIPassword" = $ApiPassword }

    # HTTPリクエストオプションの設定
    $headers = @{ "Content-Type" = "application/json"; "Accept" = "application/json" }

    # トークン取得リクエストを送信
    try {
        $response = Invoke-RestMethod -Uri $tokenEndpoint -Method POST -Headers $headers -Body ($body | ConvertTo-Json -Depth 1)
    } catch {
        Write-Host "トークン取得中にエラーが発生しました: $($_.Exception.Message)"
        return $null
    }

    # トークン取得成功時の処理
    if ($response.ResultCode -eq 0) {
        $apikey = $response.Token
        return $apikey
    } else {
        Write-Host "トークン取得に失敗しました: 結果コード $($response.ResultCode)"
        return $null
    }
}

function Get-SymbolPrice {
    param (
        [string]$BaseUrl,
        [string]$ApiToken,
        [string]$Symbol,
        [string]$Exchange
    )

    # kabuステーションAPIの設定
    $tokenEndpoint = "$BaseUrl/board"

    # ヘッダーにトークンを設定
    $headers = @{ "X-API-KEY" = $ApiToken; "Content-Type" = "application/json" }

    # リクエストURLの作成
    $uri = "$tokenEndpoint/$symbol@$exchange"

    # 日経平均情報の取得リクエスト
    $response = Invoke-RestMethod -Uri $uri -Method GET -Headers $headers

    # レスポンスの返却
    if ($response) {
        return $response
    } else {
        Write-Host "取得に失敗しました。"
        return $null
    }
}

# 関数を使用してトークンを取得
$baseUrl = "http://localhost:18080/kabusapi"
$appPassword = "パスワード"
$apiToken = Get-KabuAPIToken -BaseUrl $baseUrl -ApiPassword $appPassword

# 日経平均の銘柄コードと市場コード
$symbol = "101"  # 日経平均の銘柄コード
$exchange = "1"   # 東証の市場コード
$symboltPrice = Get-SymbolPrice -BaseUrl $baseUrl -ApiToken $apiToken -Symbol $symbol -Exchange $exchange
Write-Host "現在値: $($symboltPrice.currentPrice)"
```
ベースURLは（`"http://localhost:18080/kabusapi"`）は共通なので、トークン取得の関数（Get-KabuAPIToken）についてもを引数で受け取るように変更している。
日経平均の関数（Get-SymbolCurrentPrice）ではベースURL、APIトークン、銘柄コード、市場コードを渡し、APIからレスポンスが返却される。
レスポンスはJson形式で、例えば`currentPrice`からは現在価格が取得できる。その他の詳細は公式のリファレンスを参照してほしい。

https://kabucom.github.io/kabusapi/reference/index.html#operation/boardGet

## 参考
https://qiita.com/Davoi/items/315652b2980e3b552c4b

https://qiita.com/hmdsg/items/c6842fe87ec4e0365241
【AWS CLF-C02試験】短期間で合格するための勉強法とスケジュール


この度、AWSのCLF-C02試験（AWS Certified Cloud Practitioner）に合格しました。この記事では、私の準備経験を共有し、これから受けたい方の参考になれば幸いです。


[CLF-C02とは？](https://aws.amazon.com/jp/certification/certified-cloud-practitioner/)  



## 1. 個人
- フロントエンド開発者  
- AWS使用経験: 約半年  
   - S3 / CloudFront, S3 / EC2ベースのインフラ構築ができる
   - ACM / Route53を利用したドメイン管理やDNS設定をできる

AWS初心者レベルでしたが、しっかりと計画を立てて学習を進めることで合格を目指しました。



## 2. 試験言語について

試験の問題は原文は英語であり、日本語版の試験はそれを翻訳したものになります。問題文の日本語に違和感を感じます。その理由で、私は英語で受験しました。

ただし、**試験中は、申し込み時に日本語を選択した場合でも、英語の原文を読むことができます**。なので日本語で受験しても大丈夫です。もし皆さんが受験した時に、問題文の日本語に違和感を感じた場合は、英語の原文を参照することをお薦めします。



## 3. 使用した資料
### （1）AWS公式チュートリアル

一推し！是非観てください。

[AWS Cloud Practitioner Essentials（日本語版）](https://explore.skillbuilder.aws/learn/course/external/view/elearning/1875/aws-cloud-practitioner-essentials-japanese) 

![スクリーンショット 2024-12-20 16.31.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827838/a416f26c-9007-bef3-86d9-ea6d01822ca7.png)


### （2）問題集  

私がおすすめした問題集を使わなくても大丈夫です。問題集はネットで検索すればいくらでも見つかるので、どれを選んでも構いません。とにかく繰り返し練習して覚えていきましょう。

[AWS Certified CLF-C02 Practice Tests](https://education.ditectrev.com/modes?url=https%3A%2F%2Fraw.githubusercontent.com%2FDitectrev%2FAmazon-Web-Services-AWS-Certified-Cloud-Practitioner-CLF-C02-Practice-Tests-Exams-Questions-Answers%2Fmain%2FREADME.md&name=AWS+Certified+CLF-C02)


## 4. 勉強ステップ
### 一、AWS公式チュートリアル （合計 11 セクション）
- **12月5日**: 1～5セクション  
- **12月6日**: 6～11セクション  

### 二、問題集 （ 597 問）

無料なので説明はありません。でも、分からない質問があれば、GPTに投げれば説明をもらえます。


#### 1回目
- **12月8日**: 1～100問  
- **12月9日**: 101～300問  
- **12月10日**: 301～400問  
- **12月11日**: 401～500問  
- **12月13日**: 501～597問  

#### 2回目
- **12月13日**: 1～210問  
- **12月14日**: 211～412問  
- **12月15日**: 413～597問  

#### 3回目
（2回目で間違えた問題のみ）
- **12月16日**: 80問  

#### 4回目
（3回目で間違えた問題のみ）
- **12月17日**: 23問  

---

12月18日午前受験。 その場で結果を出す。

7日と12日は休みましたので、準備時間は**合計12日**です。
集中的に勉強時間は**約50時間**だと思います。



## 5. 短期間での合格のコツ

**キーワードを覚えること**

人間が瞬時に記憶できる情報量は数文字程度と言われています。数文字といえば単語のレベル。試験に出るようなキーワードに絞り込んで、それを覚えることに注力するのです。

たとえば、以下のような要点を押さえました：

- **EMR:** cluster, vast data
- **Athena:** Serverless, a query service for analyzing data in S3 using SQL 
- **Security Groups:** Virtual firewalls for EC2.  
- **Personalize:** AI/ML service to create personalized recommendations for users
- **CloudTrail:** records API calls, providing logging



## 6. その他

試験当日の注意点や心構えについては、以下の記事も役立ちます：  

[おさえておきたい試験当日10のポイント](https://blog.trainocate.co.jp/blog/aws10points2_005#5ddf5af58b8a6f67372f44a5-1596004937893)



## おわりに

一番難易度が低いとされているCLF ですが、各種AWSサービスの理解だけではなく、「AWSとは何か？どんなメリットがあるのか？」や「一般的なIT知識」を理解することができるので、個人的にはたくさん勉強になりました。

この記事が少しでも助けになれば嬉しいです。
ブロックを引数として明示的に受け取る

>ブロックのメソッドの引数として明示的に受け取ることもできます。ブロックを引数として受け取る場合は、引数名の前`&`をつけます

### ブロックを引数として渡せる
```rb
irb(main):016* def greeting(&block)
irb(main):017*   puts "おはよう"
irb(main):018*   text = block.call("こんにちは")
irb(main):019*   puts text
irb(main):020*   puts "こんばんは"
irb(main):021> end
=> :greeting
irb(main):022* greeting do |text|
irb(main):023*   text * 2
irb(main):024> end
おはよう
こんにちはこんにちは
こんばんは
```

```rb
irb(main):001* def greeting(&block)
irb(main):002*   puts 'おはよう'
irb(main):003*   unless block.nil?
irb(main):004*     text = block.call('こんにちは')
irb(main):005*     puts text
irb(main):006*   end
irb(main):007*   puts 'こんばんは'
irb(main):008> end
=> :greeting
```
### ブロック処理を引数とする
```rb
irb(main):009* greeting do |text|
irb(main):010*   text * 2
irb(main):011> end
おはよう
こんにちはこんにちは
こんばんは
=> nil
```
### 引数なし
```rb
irb(main):012> greeting
おはよう
こんばんは
=> nil
```

### ブロックの範囲
```rb
numbers.each `do |n|
  sum += n
end`
```
`以外の青の部分をブロックの範囲
p91

https://gihyo.jp/book/2017/978-4-7741-9397-7
サックス奏者が贈る、JSでつくるクリスマスキャロル

# 1. はじめに
クリスマスシーズンが到来し、街中でクリスマスキャロルを耳にする機会が増えてきましたね。
私は普段Webエンジニアとして働きながら、趣味でサックスを演奏しています。
今回は、プログラミングと音楽を組み合わせて、Qiita上でクリスマスキャロルを演奏してみたいと思います！

`qiitaでクリスマスキャロルを演奏する`という目標達成にあたり、
[abcjs](https://paulrosen.github.io/abcjs/)というJSライブラリを採用しました。

abcjsの特徴は以下の通りです。
- 「ABC記法」（テキストベースのシンプルな楽譜記述法）での記譜
- SVGでの楽譜レンダリング
- MIDI再生機能の実装
- レスポンシブ対応
- 軽量で導入が容易

# 2. ABC記法について
### 楽譜の基本情報
```js
X:1          // 曲番号（必須）
T:Joy to the World  // タイトル
M:2/4       // 拍子。2分の2拍子を表す（1小節に2拍）
L:1/8       // 基準の音符の長さ。ここでは8分音符
Q:96        // テンポ指定
K:D         // 調性。ここではニ長調（D major）
```

### 音符の書き方
基準が8分音符(L:1/8)なので、数字がない場合は8分音符となります。
```js
D    // 8分音符のレ
D2   // 4分音符のレ（8分音符の2倍）
D3/2 // 付点8分音符のレ（8分音符の1.5倍）
D4   // 2分音符のレ（8分音符の4倍）
```
### 実際の楽譜の一部を例に解説
1番上のパート（1st Violin）の冒頭部分を見てみます。
`d2 c3/2B/2| A3 G |`
```js
d2      // 4分音符の高いレ（8分音符×2）
c3/2    // 付点8分音符の高いド（8分音符×1.5）
B/2     // 16分音符のシ（8分音符×0.5）
A3      // 付点4分音符のラ（8分音符×3）
G       // 8分音符のソ
```
### その他の記号の説明
```js
// 小節線と装飾
|       // 小節線
||      // 終止線
(Dd2)B  // ()内の音符をスラーで結ぶ

// 強弱記号
!p!     // ピアノ（弱く）
!mp!    // メゾピアノ（やや弱く）
!mf!    // メゾフォルテ（やや強く）
!f!     // フォルテ（強く）

// パート設定
V:1     // パート1の開始
%%MIDI program 40  // 音色設定
```

# 3. 実装してみました
:::note warn
音量が大きいため、端末の音量設定を極小にしてお楽しみください。
:::
<p class="codepen" data-height="900" data-default-tab="result" data-slug-hash="jENmPxW" data-pen-title="Untitled" data-user="acciplsk-the-animator" 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/acciplsk-the-animator/pen/jENmPxW">
  Untitled</a> by 飯山若奈 (<a href="https://codepen.io/acciplsk-the-animator">@acciplsk-the-animator</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>


## 工夫したポイント
### 音楽表現の向上
楽譜上の強弱記号とMIDI音量を連動させ、より自然な演奏表現を実現しました。
### クリスマスらしいデザインへのカスタマイズ
- 演奏を追跡するカーソルと演奏中の音符の色
- 音符をクリックした時の色
- 下部の再生ボタンとプログレスバー

## 実装上の課題
### 開発環境について
CodePenを初めて使用したため、使い方の習得に時間を要しました。
ただし、環境構築の手間が省けたため、結果的には良い選択だったと感じます。
### 生成AIの活用と限界
- JavaScriptでの実装支援としては大変有効でした。
- 「『もろびとこぞりて』をABC記法で出力して」と依頼したり、楽譜のファイルを添付して読み込ませたりしてみましたが、全く違う曲（知らない曲）が生成されました🤦‍♀️
- サックス用の移調を依頼すると不協和音が発生[^1]

### 技術的な課題
- MIDI音源の全体の音量調整に苦心
  - 音量調節のお手間をおかけしすみません。
- 個別の音符をクリックして音を鳴らす機能は、時間の都合で断念しました。

## 印象的だった点
- 音楽面での達成
  - 4声が綺麗にハモって出力された瞬間
  - 強弱記号による表現の幅の広がり（今回は時間の都合で一部のみ実装）
- 技術面での発見
  - プログレスバーで再生位置を指定すると、該当の小節/音符がハイライトされる

# 4. 終わりに
- 普段から楽譜には馴染みがありますが、JSを使用して記譜するというのはとても新鮮な経験でした。
- 年末にかけてお忙しい方も多いかと思いますが、皆様素敵なクリスマスをお過ごしください🎄✨

[^1]: ヴァイオリンの「ド」とサックスの「ド」は別の音が出ます。ヴァイオリンの「ド」をサックスで表現するためには、「ラ」を出す必要があります（アルトサックスの場合）
初めてモブプログラミング/スウォーミングを体験した感想

このエントリは、[SmartHR Advent Calendar 2024](https://qiita.com/advent-calendar/2024/smarthr) シリーズ1の22日目の記事です。

# この記事は何？

SmartHRに10月にJoinして約3ヶ月、チーム開発でモブプログラミング（以下モブプロ）、スウォーミングを体験してきたので、感じたこと・工夫したことなどをまとめます。

# この記事で取り扱わないこと
- モブプロ、スウォーミングを導入する方法
    - すでにチームで文化として成立していたため
- モブプロ、スウォーミングのやり方
    - 詳しい記事は他に沢山あるので、そちらに譲ります

# 個人背景
- ペアプロでの開発経験は少しだけあるが、基本的にはソロプログラミングでやってきた
- モブプロに興味はあったが実践する機会はなし
- スウォーミングという言葉はこのチームに入ってから知った
- プログラミングはじっくり考えて、ひらめきがあったときに喜びを感じるタイプ

# チーム背景
- チームメンバーは5人（内エンジニア4人）、フルリモートでスクラムでの開発を実施
- 10月にJoinした直後はちょうど忙しい時期で、各々開発をしていた
- 10月半ばにモブプロを開始
- 11月頃から、ベロシティを上げるための施策としてスウォーミングを実施

# モブプロについての感想
## どのように実施していたか
- 1つのタスクを全員で実施
- 20分交代で1人がドライバー、残りがナビゲーターとして作業
- ナビゲーターが画面を共有して作業をする

## メリット
- チームに参画してすぐ、右も左もわからない状態において、ドライバーをやることはキャッチアップをするためにはとても良かった
- 複雑なタスクについて相談しながら進めることができたので、一人で詰まることがなかった
- ↑と合わせて、複雑な仕様をその場で全員に共有できる
- 全員が実装を把握しているため、PRオープンからアプルーブまでのサイクルタイムは短い
- 他の人の作業環境が見られるので、便利機能やTipsを共有することができた
    - オフラインで仕事しているときはこういうのよくあったよなと思い出した

## デメリット
- 全員の時間を使うので、簡単なタスクをモブプロでやると時間がもったいない
- 全員の時間を使うので、ドライバーをやるときにとても緊張する
- 右も左もわからない状態だと、ナビゲーターで価値をあまり発揮できない
- 他の人が会議などで抜けて1人になったとき、「どうしよう？」となることがあった
    - 個人タスクを別で持っておくとか、一人で進めてOKとか決めておくことで対応できる
- じっくり考える時間はあまり取れない

# スウォーミングについての感想
## どのように実施していたか
- 各個人がタスクをそれぞれ持つ
- ミュートで通話を繋いだ状態でそれぞれ作業する
- 相談したいとき、レビューして欲しいときなど声を掛けて、モブプロに移行する

## メリット
- じっくり考えつつ、困ったときにはパッと相談できる
- それぞれタスクを進めるので、タスクの消化が早くなった
- 困ったらすぐ相談できるという安心感

## デメリット
- 相談したいけど、今集中してたりしないかな？とか気にしがち
    - お互い様なので気にせず声をかけよう、とチームで合意したことにより解消

# 全体を通しての感想
- 現在はモブプロとスウォーミングのいいとこ取りで実施しています
    - 基本はスウォーミングだが、複雑なタスクはモブプロ
- 常時通話繋いで相談できるのはチームの文化があってこそだと思うので、チームに感謝
- 基本ミュートにしているので、いっぱい話したのにミュートだったというのはよくある
    - ミュートし忘れて配信事故になるのはまだやっていない
    - 手元でミュートできるUSBマイクを購入したが、入力ソースが違うものになっていたということはよくあるので、ミュートのショートカットは把握しておくといい
- 普段はMacのMisson Controlを多用してるけど、画面共有される側からすると画面の切り替わりで酔いそうな気がするので、なるべく使わない/使うときはゆっくり切り替えるを意識している
UiPath Studio Web を知ろう！

# UiPath Studio Webを活用するためのポイント
はじめまして！
Ken_shinと申します！

先日「AIオートメーションフォーラム 2024」に参加した際、皆さまに刺激され初めて記事を書いています！

UiPath Studio Webの活用を推進する者として、業務効率化やプロセスの自動化を進める際に、
プロジェクトを成功させるための意識していきたいポイントをまとめました。

## はじめに

UiPath Studio Webは、インストール不要でブラウザ上で動作する新しいRPA開発ツールです。
クラウド環境に対応しており、プロジェクトの迅速な開始や共同作業の効率化が期待されます。
この記事では、筆者が社内でUiPath Studio Webを試用し、導入・運用に際して注意すべき点を解説します。

---

## 1. UiPath Studio Webの特徴

### 1.1 ブラウザベースであることの利点

- **環境構築の簡略化**: インストールが不要なため、新しいメンバーがプロジェクトにすぐに参加できます。

- **クロスプラットフォーム対応**: Windows、Mac、Linuxなど、さまざまなOSで利用可能です。

### 1.2 制限事項

- **機能の制約**: デスクトップ版UiPath Studioに比べ、一部の高度な機能が利用できない場合があります。詳細は公式ドキュメントの[既知の制限事項](https://docs.uipath.com/ja/studio-web/automation-cloud/latest/user-guide/known-limitations)をご参照ください。
- **インターネット接続が必須**: オフライン環境での開発には不向きです。

---

## 2. 導入時に注意すべきポイント

### 2.1 チームでの運用を見越した設定

- **アクセス権限の管理**: 開発者や運用担当者ごとに適切な権限を設定しましょう。<!--具体的なアクセス権限の設定方法は[公式ドキュメントのセキュリティガイド](https://docs.uipath.com/ja/automation-cloud/latest/user-guide/security)に記載されています。-->
- **プロジェクト管理のルール**: ファイル命名規則やフォルダ構造を明確化し、混乱を防ぎます。<!--これについては[プロジェクト管理のベストプラクティス](https://docs.uipath.com/studio/latest/user-guide/best-practices)を参照するとよいでしょう。-->

### 2.2 セキュリティ対策

- **データの取り扱い**: 社内データや顧客情報を扱う場合、データの暗号化やアクセス制限を徹底しましょう。
- **クラウド利用規約の確認**: 自社のセキュリティポリシーと照らし合わせ、クラウド利用に問題がないか確認しましょう。

---

## 3. プロジェクト進行中の工夫

### 3.1 ブラウザ互換性の確認

- **ブラウザ互換性の確認**: 利用するブラウザによって挙動が異なる場合があるため、主要ブラウザでのテストを実施しましょう。

### 3.2 開発プロセスの見える化

- **ドキュメント化**: フローや設定の詳細をドキュメント化し、誰が見ても理解できる状態を目指します。<!-- 公式では[開発プロセスのドキュメント化](https://docs.uipath.com/studio/latest/user-guide/documentation-guidelines)が推奨されています。-->
- **フィードバックの迅速化**: チームメンバー間で早期にレビューを行い、問題を素早く修正しましょう。

<!--レビューの具体的な実践方法は、[コードレビューのベストプラクティス](https://docs.uipath.com/studio/latest/user-guide/code-review)を参考にすると便利です。-->

---

## 4. 導入後の運用改善

### 4.1 継続的な学習

- **UiPath公式ドキュメントやフォーラムの活用**: 新機能や事例を常にキャッチアップしましょう。公式ドキュメントは[こちら](https://docs.uipath.com/ja)からアクセスできます。
- **社内勉強会の開催**: ノウハウを共有し、メンバー全体のスキル向上を図ります。

### 4.2 定期的なメンテナンス

- **プロセスの見直し**: 自動化した業務が現状に合っているか定期的に確認しましょう。
- **バージョン管理の徹底**: クラウド上での変更履歴を確認し、意図しない変更が加わらないよう注意が必要です。

---

## まとめ

UiPath Studio Webは、その手軽さと柔軟性から、特に小規模なプロジェクトやリモート環境での利用に適しています。

一方で、導入にはクラウド環境特有のセキュリティや機能制限を理解し、適切な運用ルールを整備する必要があります。

拙い文章ではありますが、UiPath Studio Webの導入や活用を検討している方々の参考になれば幸いです。



---

## 参考リンク

- [UiPath Studio Web 概要](https://docs.uipath.com/ja/studio-web/automation-cloud/latest/user-guide/overview)
- [UiPath Studio Web 既知の制限事項](https://docs.uipath.com/ja/studio-web/automation-cloud/latest/user-guide/known-limitations)

<!-- 
- [セキュリティガイド](https://docs.uipath.com/ja/automation-cloud/latest/user-guide/security)
- [プロジェクト管理のベストプラクティス](https://docs.uipath.com/studio/latest/user-guide/best-practices)
- [コードレビューのベストプラクティス](https://docs.uipath.com/studio/latest/user-guide/code-review)
-->
RSpecのカバレッジ率を出力してみた

# はじめに
本記事は[Progaku Advent Calendar 2024](https://qiita.com/advent-calendar/2024/progaku)の20日目の記事となります。

今回はRSpecを書いていてどれくらいソースコードに対してテストを網羅出来ているかを可視化してみようというテーマで書こうと思います。

試した環境は
・Rails 7.1.3
・Ruby 3.3.3
・RSpec 6.1.3
です。

# gemを導入する

今回はSimpleCovというgemを使用してみました。
[GitHub](https://github.com/simplecov-ruby/simplecov0)

README通りGemfileに下記を追記して```bundle install```を実行します。

```ruby:Gemfile
gem 'simplecov', require: false, group: :test
```

spec/spec_helperの***最上部に***下記を追加します。

```ruby:spec/spec_helper
require 'simplecov'
SimpleCov.start
```

# 導入結果
rspecを実行します。
```ruby
bundle exec rspec
```

実行後に```coverage```というディレクトリが追加されます。

![スクリーンショット 2024-12-20 17.21.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/474880/ba4fc5d1-eacb-2090-bab5-40d2dc3d0335.png)

この中にあるindex.htmlを開いてみます。

![スクリーンショット 2024-12-20 17.25.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/474880/2c848f29-49fb-773d-c6d7-153e15f390b4.png)

全体のカバレッジ率と各ファイルに対するカバレッジ率が可視化出来ました。

個別ファイルを見ると、カバー出来ている部分は緑、カバー出来ていない部分は赤でハイライトされています。

![スクリーンショット 2024-12-20 17.30.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/474880/c3d10a46-76d6-9755-6b16-9aa85600d9d7.png)

上記コードは```spec/rails_helper.rb```になりますが、こんな感じでハイライトされるというためのものなので内容に特に意味はないです。

# 設定関連
specディレクトリは対象から除外しても良いかなと思うので、spec/spec_helperに以下を追記します。

```ruby:spec/spec_helper
SimpleCov.start do
  # add_filter "対象外にしたいディレクトリ"を記載することでカバレッジの対象外になる
 add_filter "/spec/"
end
```

これで/specはカバレッジの対象外となります。

また、ModelsやControllersなどでグルーピングしたい場合は以下を追記します。

```ruby:spec/spec_helper
SimpleCov.start do
  add_group 'Models', 'app/models'
  add_group 'Controllers', 'app/controllers'
end
```

設定後に再度```bundle exec rspec```を実行し```/coverage/index.html```を開くと下記のようにグルーピングされます。(赤枠部分)

![スクリーンショット 2024-12-20 17.53.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/474880/32980522-887a-05c9-d7c2-6b26771b6d13.png)


また、git管轄で```coverage```を管理する必要もないかと思うので、```.gitignore```に```coverage```を追記しておくか、
```
echo coverage >> .gitignore
```
で設定しておくといいかもしれないです。

# まとめ
導入も簡単に出来るので、

どこまでRSpecを書けばいいんだろう

どれくらいソースコードに対してテスト出来てるのか知りたい

みたいな方は一度導入してみるのもいいのかなと思いました。
[Bookmarklet] 動的なDOM生成を指令したあとその要素を取得するまで待つ

# 僕が忘れた時用

## やりたいこと

ブックマークレットでDOMの動的生成を行う要素に対し`click()`などを実行してDOMの生成を促した後、生成された要素を取得したい。

## 解決すべき課題
要素が生成されるのを待つ必要がある。

## こーど

```javascript
function afterExec(ms, f) {
	return new Promise((r) => setTimeout(() => r(f()), ms));
}
async function waitLoadElementById(elementId) {

	const target = await afterExec(10, () => document.getElementById(elementId));
	
	if(target == null) {
		return await waitLoadElementById(elementId);
    }
     
    return target;
}
```
```javascript
javascript: (async function () {
....
....
  const elem = await waitLoadElementById("elemenNoID");

...
```

## 問題点

再帰呼び出しを行っているので、ロードがあまりにも遅い、あるいはIDを間違えているなど要素が存在しない場合、スタックがオーバーフローする。
カラーユニバーサルデザインで誰にでも読みやすいドキュメントを作成しよう

# はじめに

資料を赤字で訂正したのに、「これどこを直したの？」なんて聞かれた経験はありませんでしょうか。
大学時代研究室で重度の色弱の先輩にお世話になり、私自身も軽度の色弱を持つ当事者として、資料作成の際に注意したいカラーユニバーサルデザインについて簡潔にまとめました。



# カラーユニバーサルデザインとは

> カラーユニバーサルデザインとは、多様な色覚に配慮して、情報がなるべくすべての人に正確に伝わるように、利用者の視点に立ってデザインすることです。

https://www.fukushi.metro.tokyo.lg.jp/kiban/machizukuri/kanren/color.html

※[東京都カラーユニバーサルデザインガイドライン](https://www.fukushi.metro.tokyo.lg.jp/documents/d/fukushi/colorudguideline2)より抜粋

色弱者は、目の錐体細胞のうちどの色を感じる細胞の働きが弱いかによってP型,D型,T型の3タイプに大別されそれぞれ区別を苦手としている色が異なります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3519892/b7503d5c-6b55-443b-9036-10607171e457.png)
例えば、P型,D型の色弱者の方は赤緑の区別が難しく、以下のような色の組み合わせを苦手としています（あくまで一例です）。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3519892/d1dc44a5-4de5-ae7a-360d-df4fedfb4c1e.png)
より詳しく知りたい方は冒頭のリンク先の資料をご覧ください。

# 具体的な注意点
### 黒との対比は原色を避ける
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3519892/b0d06dfd-344a-c385-f12f-26f8f9159a07.png)
彩度が高い（原色に近い）色は、色弱者にとって黒との区別が難しいことがあります。
明度の違いだけでも見分けられるよう明るめの色への代替が望ましいです。

### 彩度や明度の近い色の組み合わせは避ける
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3519892/7ad1383d-484f-9e8c-34a6-0d54a959692e.png)
【P型色覚、D型色覚の方が特に区別の困難な色の組み合わせ】の図で例示されているように、赤と緑、黄緑と濃い黄色、水色とピンクなどの組み合わせは注意が必要です。
街中でも見かける組み合わせなのでついやってしまいがちですが、片方の色を明るく/暗くするとより分かりやすくなります。

### 線の細いフォントの使用は避ける
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3519892/f7dd1fc9-674f-7017-a46c-755ea25a40bb.png)
色弱者に限った話ではありませんが、着色されている部分が少ないほど色の判別はより難しくなります。ドキュメントに文字色を使用した情報が含まれることが分かっている場合は、フォント選びの段階でより線の太いフォントを使用するとよいでしょう。

### 色以外の強調表示を活用する
色による識別にこだわる必要がない場合には、**太字**、*Italic(斜体)*、<INS>下線</INS>など色以外の強調表現を活用する手もあります。ただし、フォントの選択によっては太字、Italic(斜体)が分かりにくい場合もあるので注意です。

# まとめ

色弱は日本人男性の約5％が該当するとされており、決して珍しい障害ではありません。また、加齢により色の認知機能が衰えて今まで問題なかった方も色の判別が難しくなる場合もあります。
[具体的な注意点](#具体的な注意点)の図で<font color=red>×</font>の例として挙げた色の組み合わせには特に注意していただけると、トラブル軽減につながるかと思います。
長く続いてるプロジェクトではいきなり配色を変えるのは難しいケースもありますが、カラーユニバーサルデザインをはじめとしたドキュメントの読みやすさへの配慮の意識が高まり、参画者全員がストレスなく仕事を行える素敵な環境が少しでも増えれば幸いです。

※私の所属する現場にて相談に快く応じてくださり、ドキュメントの修正箇所の着色を赤→水色へと変える柔軟な対応をしていただいた上長、同僚の皆様にはこの場を借りて深く感謝申し上げます。
iPhoneで撮影したHEIF形式のファイルをHEICのままアップロードする

## はじめに
株式会社メディアテック所属の @mt-h2 です。
普段は [OutSystems](https://www.outsystems.com/ja-jp/) を利用したローコードでシステム開発を行っています。

今回は iPhone の写真に関する内容になります。

## 前置き
撮影した写真を Web からサーバにアップロードする、というよくある対応が必要になりました。iPhone で撮影した写真は [HEIF形式](https://ja.wikipedia.org/wiki/High_Efficiency_Image_File_Format) で保存され、Windows ではコーデックなしでは表示できないものになります。

Qiitaの記事（[iPhoneで撮影したHEIF形式の画像はJPEGに変換される](https://qiita.com/sxa/items/abf4b4b51beba89a8987)）を拝見すると、Web ページの input からアップロードしたものは jpeg に変換されるとの事でしたので実際に検証しました。

結果、記事の通り jpeg に変換された状態でアップロードされました。

**ある条件を除いて…**

## 何があった
iPhone から input タグを選んでファイルをアップロードする際、以下いずれかの選択肢からアップロードファイルを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3803085/af9f0ff1-838d-de3b-2e9d-95c9eb987e40.png)

この中から「ファイルを選択」を選んだ時に、ある手順で用意したファイルを選択すると HEIF形式（hoge.heic）のままアップロードされる事が確認できました。

### HEIF 形式のまま Web に写真をアップロードする手順
1. 事前にiPhoneで写真を撮影する
1. 「写真」アプリを起動
1. 撮影した写真を選択
1. 共有から「"ファイル"に保存」を押下
1. ファイルに保存されたファイルを Web にアップロードする
1. **アップロードしたファイルは jpeg に変換されず、HEIF形式 が保持される**

## あとがき
iPhoneで撮影した写真を Web サイトの input タグからアップロードした場合、基本的には jpeg で保存されますが、今回のような手順を踏んだ写真は HEIF形式 のままアップロードされる事が確認できました。全て jpeg に変換されると思い込んでいたため注意が必要という事が分かりました。

## さいごに
株式会社メディアテックでは絶賛 [開発メンバを募集中](https://www.mediatech.jp/recruit) です。
ローコード開発だけではなく、RPAやBIエンジニア諸々多数の募集をしておりますので、みなさまのご応募をお待ちしております。
AWS Amplify 試してみた

# AWS Amplify を試してみた


### はじめに

こんにちは、株式会社TechoesのKです（アプリエンジニア3年目）
今回はAWS Amplifyを使用してみたので導入方法についての記事となります

## AWS Amplifyについて

AWS Amplifyは、フロントエンドおよびモバイルアプリケーションの開発を加速させるためのフルスタックな開発プラットフォームである

AWS Amplifyは、以下の特徴を持つツールとサービスのセットを提供する：

- **簡単なバックエンド構築**  
  認証、データベース、ストレージ、APIを簡単にセットアップできる

- **フロントエンド統合**  
  React、Vue.js、Angular、Next.jsなど、主要なフロントエンドフレームワークに対応している

- **ホスティングサービス**  
  静的ウェブサイトやシングルページアプリケーション（SPA）を簡単にデプロイできる

- **開発者向けCLI**  
  Amplify CLIを使用すると、インフラストラクチャのプロビジョニングが簡単に行える

このように、AWS Amplifyは、開発の初期段階からスケールに至るまで、迅速かつ効率的なアプリケーション開発をサポートする


<br>


## 実際に導入してみる

<br>

### 導入するコード
  今回はNext.jsの初期状態のコードをデプロイしてみます

https://nextjs.org/

![aのコピー.tiff](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/2a02c357-18ff-6af0-be66-2e7f74d95e3a.tiff)




<br>

### 導入手順

今回はブラウザのAWSコンソールからデプロイする方法で導入する


<br>



- まず、AWS Amplify コンソールにログインする

https://aws.amazon.com/amplify/



<br>

- ログイン後、"新しいアプリを作成"を選択
  　![スクリーンショット 2024-12-10 15.31.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/0f30efcb-82df-a998-35f7-b730a306be35.png)

<br>

- "Github"をオプション選択して次へ
   
     ![スクリーンショット 2024-12-10 15.32.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/62df8349-9b47-1b64-9a41-7f21f6a26fa2.png)

<br>

- Githubアカウントの連携認証後、デプロイするリポジトリとブランチを選択
  (※リポジトリがモノレポの場合、オプションでフロントだけ設定可能）

  ![スクリーンショット 2024-12-10 16.23.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/5248dbb9-b5ed-9c17-eaa4-15b8c69e77ff.png)



<br>

- サイト名やビルドの設定などを細かく設定できる（パスワードの追加など）

  ![スクリーンショット 2024-12-10 15.46.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/71621591-7aee-048a-3809-bb11d09ba90d.png)

<br>

- 設定を最終確認してデプロイ

  ![スクリーンショット 2024-12-10 16.24.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/26f287a6-155c-0efb-aa60-10b0f3c996a7.png)


<br>

- デプロイ完了後、URLからサイトを開くことができる

  ![スクリーンショット 2024-12-10 16.48.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/696ad48b-ab7c-688a-e5d8-2c7c659a457a.png)



<br>

## 導入後の最終状態

![導入のコピー.tiff](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/0b4879e6-33ec-228a-3a7c-eb8dccd4065d.tiff)


URLがデプロイ画面に対応したものとなっている
無事デプロイできていることが確認できた


<br>


### おまけ

AWS Amplifyではカスタムドメインを設定することができる、以下にAWSコンソール上の設定手順を紹介する


<br>



- 左サイドメニューから「ホスティング」→「カスタムドメイン」を選択
- 「ドメインを追加」を選択
![スクリーンショット 2024-12-17 18.11.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/8fce33d4-be88-a43a-d7af-4589b276ec02.png)


<br>


- ルートドメインを選択後、「ドメインを設定」ボタンをクリック
![スクリーンショット 2024-12-17 18.13.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/dd104ca3-a013-dd0d-0719-3e87858dbad5.png)




<br>

- サブドメイン設定後、「保存」ボタンクリックで設定完了
- 数分ほど待ち、ステータスが使用可能になったら問題なく設定されている
![スクリーンショット 2024-12-17 18.19.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3714682/067fea65-2701-3ecf-9a11-55a2c2586251.png)



<br>




## 感想

Githubのリポジトリ、ブランチを選択するだけでデプロイできるほか、カスタムドメインの設定も簡単にできるため、フロントエンドデプロイの選択肢としてかなり優れている印象を受けた

今後も積極的に利用していきたい