OmniAICreator/Qiita-1.07M huggingface dataset:
ゼロから始めるSnowflake（10/10）

# 非構造化データとCortex LLM関数

## 概要
PDF文書を解析し，Cortex関数を使用して情報を抽出してテーブルに記録する．その上で，別のCortex関数を使ってテーブルのデータ行にラベルを付ける．それを元に分析クエリを作成し，Streamlitで可視化を行う．最後に，他の3つのCortex関数の概要を簡単に紹介する．

## 非構造化データとは何か

非構造化データとは，事前に定義されたデータモデルやスキーマに対応しない情報を指す．例として，テキストデータ，画像，動画，音声などが含まれる．Snowflakeは，これらのデータのアクセス，共有，処理を支援する機能を提供する．

## やること

1. Cortex LLM関数を使ってPDF文書を解析し，テーブルに情報を記録する．
2. Cortex LLM関数を使ってデータ行にラベルを付ける．
3. Streamlitにより情報を分析して可視化する．

これらの作業を通じて，非構造化データを制御するための基本的なテクニックを習得する．

## SnowflakeのCortex関数

### Cortex LLM関数

Snowflake Cortex LLM関数は，非構造化データの抽出，分析，生成を行うSQL関数である．これにより，非構造化データから情報をワンステップで抽出し，簡単な操作で実用的な情報に変換できる．

使用する関数は次の通り．
- `PARSE_DOCUMENT()`: PDF文書からテキストを抽出する．

## テキスト抽出の流れ

1. ステージにあるPDFファイルのリストをSQLを使って収集する．
2. `PARSE_DOCUMENT()`関数を実行し，PDF文書からテキストを抽出する．
3. 抽出したテキストを新しいテーブルに書き込む．

## 実装ステップ

### PDF解析
1. SnowflakeのUIで以下のSQLクエリを実行し，ステージにあるPDFファイルをリストアップする．

```sql
SELECT METADATA$FILENAME
FROM TABLE(
  INFER_SCHEMA(
    LOCATION=>'@my_stage/pdf_files/',
    FILE_FORMAT=>'(TYPE=>CSV)'
  )
);
```

2. `PARSE_DOCUMENT()`関数を用いて，PDFからテキストを抽出する．

```sql
SELECT PARSE_DOCUMENT($1) AS EXTRACTED_TEXT
FROM @my_stage/pdf_files;
```

3. 抽出したテキストを新しいテーブルに挿入する．

```sql
CREATE OR REPLACE TABLE extracted_texts (
  filename STRING,
  content STRING
);

INSERT INTO extracted_texts
SELECT METADATA$FILENAME, PARSE_DOCUMENT($1)
FROM @my_stage/pdf_files;
```

### ラベル付け
1. `EXTRACTED_TEXTS`テーブルの各行にラベルを付与する．

```sql
CREATE OR REPLACE TABLE labeled_texts AS
SELECT filename, content,
  CASE
    WHEN content LIKE '%重要%' THEN 'High Priority'
    WHEN content LIKE '%確認%' THEN 'Medium Priority'
    ELSE 'Low Priority'
  END AS label
FROM extracted_texts;
```

### Streamlitによる可視化
1. Streamlitアプリを作成するために，次のPythonコードを使用する．

```python
import streamlit as st
import pandas as pd
from snowflake.connector import connect

# Snowflake接続設定
conn = connect(
    user='USERNAME',
    password='PASSWORD',
    account='ACCOUNT',
)

# データ取得
query = 'SELECT * FROM labeled_texts;'
with conn.cursor() as cur:
    cur.execute(query)
    rows = cur.fetchall()

# データフレームに変換
data = pd.DataFrame(rows, columns=['filename', 'content', 'label'])

# Streamlitで表示
st.title('ラベル付きテキストの可視化')
st.dataframe(data)
```

2. Streamlitアプリを実行して結果を確認する．

```bash
streamlit run app.py
```

## 他のCortex関数の紹介

以下の3つのCortex関数を簡単に紹介する．

1. `ANALYZE_TEXT()`
   - テキストデータを解析し，感情分析やキーフレーズ抽出を行う．

2. `GENERATE_TEXT()`
   - 指定されたプロンプトに基づいて新しいテキストを生成する．

3. `SUMMARIZE_TEXT()`
   - 長いテキストを要約し，重要なポイントを抽出する．

これらの関数は，非構造化データの高度な処理に役立つ．
Microsoft Fabric でレポート作成時にありがちなエラー 「モデルを読み込むことができません」

## はじめに

以下のエラーメッセージの原因の一例と対処を記載します。

>**モデルを読み込むことができません**
>このレポートに関連付けられているモデル スキーマを読み込むことができません。サーバーに接続できることを確認して、もう一度やり直してください。

## 原因

モデル上にテーブルが存在しない場合に発生します。

既定のセマンティックモデルを使用すると起きがちです。

## 再現手順

1. [サンプルウェアハウス](https://learn.microsoft.com/ja-jp/fabric/data-warehouse/create-warehouse-sample)を使うか、任意のウェアハウスでテーブルを作成します。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/eb26936d-57f6-e9cc-ece9-66b38ae72ab1.png)

2. (省略可能)モデルレイアウトでリレーションシップを作成します。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/979d69db-d8d1-a0a6-3d5d-cf76dd436c52.png)

3. ワークスペースからウェアハウスに付随の既定のセマンティックモデルを開き、レポートの作成をします。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/12d3fc7d-071d-28f9-0876-a6b0b938efca.png)
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/7b606e76-37ae-6954-bf15-26e2cd64e2ac.png)

4. 再現が確認できます
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/cd386acb-728b-0ddd-c27b-924b93255958.png)

## 原因と対処

この事象はセマンティックモデルにテーブルが登録されていないために起きるエラーです。

したがって、以下のボタンを押して、セマンティックモデルのテーブルを同期してやることで解消されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/874933f0-af2e-878b-29a1-80cdcefb5f42.png)

例：**既定のセマンティックモデルの管理** から指定したテーブルのみ同期

設定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/2929c1e1-0767-053f-1c03-705c7971af34.png)

結果
データタブにテーブルが追加され、エラーが解消

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/00254200-32f7-c7a6-777d-8c6354204dae.png)


例：**セマンティックモデルオブジェクトを自動的に更新する** を実行し、現在存在するすべてのテーブルとビューをモデルに追加
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/f88f7566-782b-2e1d-6cbd-dcc66a1a5dee.png)

結果
データタブにすべてのテーブルが追加され、エラーが解消
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/d4d0428d-4aae-85e3-864b-b62b119dc72a.png)

:::note info

こうしたレポートの動作のほか、新しいメジャーボタンもモデルに追加されていないテーブルでは無効となる点をご承知おきください。

モデルに追加前のテーブル例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/afb25a5a-ed88-4aef-6e3e-bde151135774.png)


:::



また、既定のセマンティックモデルには [ウェアハウス/レイクハウスのSQL分析エンドポイントに対する同期設定](https://learn.microsoft.com/ja-jp/fabric/data-warehouse/semantic-models#sync-the-default-power-bi-semantic-model) があります。

こちらをONにすることで、ONにして以降のテーブルは自動的にモデルに追加されるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281819/57e43252-ab30-8535-0c06-8fcb393cbfce.png)


:::note info

テーブルの追加後に同期設定をオンにしても既存のテーブルは追加されないことに注意ください。
また、自動同期ジョブがバックグラウンドで実行されるようになるため、Fabric 容量の CU 消費を少しでも抑える場合にはオフにしておきましょう。

:::
個人開発の光と闇を~RPG風にて

# はじめに
2024年の自身のチャレンジとして、
個人開発を行い筋トレアプリをリリース出来た事があげられる。

そこには、多くの闇と、少しばかりのまばゆい光があった。

ある個人開発者の生々しいストーリを追体験して、もし何か共有できる物があればと思う。

チック、タック、チック、タック、、、、、
![Chrono_Trigger_Adventurous_Illustration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/138863/b44a988d-d5e6-feba-1497-9d1802db9e2c.png)

# 第一章: 個人アプリをつくるまで

まず自身は、2023年少しばかりメンタルを落としていた。
その際に見つけたソリューションが、「筋トレ」だ。

「朝起きたら、腹筋10回」からはじめ
スモールに筋トレを習慣化していたら、
だんだん物足りなくなって、「筋トレ系Youtub」とかを見るようになって
それで、だんだん「できるな」と思ってきて、
少しづつメンタルが回復してきたのを覚えている。


それで、
「この体験を皆に追体験してもらいたい」というのと
「毎回自分がyoutube動画探すの面倒だな」というので
個人開発アプリを作ることにした。

それで、作った筋トレアプリがこちら

https://choitore.hp.peraichi.com/

こちらを作ったときの奮闘は、下記に

https://qiita.com/yuto-ktok/items/87df741aa4a4b52d5af7


開発を完了したあとに、リリース前に待っていたのが

**「Android公開めっちゃ大変の闇」**

「20人以上のテスターを集め、14日以上連続で使ってもらわないとリリースできない」ですよ。ボッチ開発者絶滅計画としか思えませんでした。

最初は全然集まらなくて、だいぶ心折れました。

そのときやさぐれてたときの様子がこちら

https://qiita.com/yuto-ktok/items/f13d56d6aaceba892ecb


最終的には、できました！！ゴマダレ〜〜〜！♪♪

その時お手伝いいただいた心優しいかけがえのない友達と、
運営者ギルドには大変お世話になりました。

**御恩は、来世も忘れません。**

# 第二章: リリース後の闇
無事Androidもリリースでき、闇を超えたと思ったのですが、

その後には「真の闇(ボス)」が待っていた。

それは、おそらく多くの個人開発者がぶち当たる2大闇であろう

- **ユーザが全然集まらない**
- **自身の開発熱が冷めてしまう**

という2大闇

まずユーザが集まらないという点ですが、

こちらは自身のマーケティング力不足もあり、

1年間で、146ダウンロード
という燦々たる結果でした。

![Screenshot 2024-12-23 at 20.52.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/138863/0db0c562-2615-0185-7391-5c230e4f1f7b.png)


リリースすることで満足してしまった自分も正直いました。
同時に一番のユーザである自分もチョコザップに浮気したり、

会社で同僚と筋トレ部を作ったりと、筋トレという筋で別のステージに進んでしまい
自分の開発したアプリを使わなくなってしまいました。。。

**そして、アプリは永き眠りについたのでした。。。**

![A_mystical_and_legendary_sword_sealed_in_a_pedesta_converted.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/138863/9fc0914f-52a9-de4c-0803-51f78504fc4c.png)



# 第三章: その後見えてきた光
しかし、その封印が2024年の夏　解かれます。
それは、ある筋トレYoutuberとの奇跡の出会いでした。

ある飲み会で「筋トレYoutuber」と出会います。

そして、
「自身がそのYoutuberの動画のユーザであること」
「また筋トレを広げたく自分で作っていること」
を明かしました。

するとあれやあれやと盛り上がり
「一緒に筋トレアプリ作りましょう！！！」
となったのです！！！

**そう「仲間」ができたのです！！！**
**ダウンロードはさっぱりでしたが、個人開発に意味はあったのです！！**
**プロジェクトに失敗しても、行動に意味が出るパターンがあるのです。**

![Screenshot 2024-12-23 at 19.59.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/138863/da8ae7c0-50dc-c7e6-89a4-f55a561d5393.png)


ここで、新たに筋トレアプリを作り直すことが決まりました。
そして、半年間再度アプリを企画からやり直し、新しいアプリができました。

そちらがこの「できトレ」です。

https://dekitore.jp/


1月公開予定です。(現在先行利用ユーザ登録を募っています。)
もし、ジムトレを諦めてしまって、でも筋トレを家でライトに習慣化したい
という人はぜひ見てみてください。

# 3行まとめ
筋トレアプリ個人開発したら、全然使われなかったよ。開発飽きたよ。
でもそれをキッカケに新しい仲間できて、超グレードアップして帰ってきたよ。
運営者ギルドにも入れて、そこでも仲間でできたよ！**色々あったけど行動大事！！** 今後の船出に、乞うご期待！！

# おわりに
最後まで読んでいただき、ありがとうございます！
もし「イイね」いただければ、今後の励みになりますし「強くてニューゲーム」できる気がします。
よろしくお願いします。m_ _m
Azureの次のステップ：PaaSと自動化を使った高度な運用術

前回の記事では、AzureのPaaSとAutomation アカウントを活用した基本的な使い方をご紹介しました。今回は、それを一歩進めて、AzureのPaaSとAutomationを活用した高度な運用術や具体的な応用事例を掘り下げていきます。

# 高度なPaaS活用術
## 1. Azure API ManagementとLogic Appsの統合
Azure API Managementは、APIの公開、保護、管理を行うためのサービスです。これをLogic Appsと組み合わせることで、APIのワークフローを自動化できます。

ユースケース
APIリクエストのバリデーション: 受信データをLogic Appsで事前処理し、APIバックエンドに渡す。
エラー処理の自動化: APIの失敗リクエストをAzure Blob Storageにログ保存。
実践例: データ検証フローの構築
Azure API ManagementでAPIを公開。
Logic Appsをトリガーに設定し、データを検証。
問題があれば通知（例: TeamsやSlackに送信）。

## 2. Azure Event GridとFunctionsによるイベント駆動型アーキテクチャ
Azure Event Gridは、リソース間のイベントを連携させるためのサービスです。これをFunctionsと組み合わせると、イベントドリブンなシステムを簡単に構築できます。

ユースケース
ストレージへのファイルアップロードをトリガーに画像処理を実行。
IoTデバイスのデータをリアルタイムで処理。
実践例: ファイルアップロードイベントの処理
Azure Blob Storageに新しいファイルが追加されるたびにEvent Gridがトリガー。
Azure Functionsがそのファイルを処理（例: 画像のリサイズ）。
サンプルコード: Event GridとFunctionsの連携

javascript
module.exports = async function (context, eventGridEvent) {
    context.log('Event received:', eventGridEvent);
    // イベントデータを処理
};


## 3. Azure Cosmos DBとPaaSサービスの連携
Azure Cosmos DBは、グローバル分散型のNoSQLデータベースです。これをPaaSと組み合わせることで、スケーラブルなアプリケーションを構築できます。

応用例
Functionsと連携: Cosmos DBに新しいデータが追加された際に、Functionsをトリガーとして処理を実行。
Logic Appsと連携: Cosmos DBからデータを取得し、別のシステムに送信。
実践例: Cosmos DBのデータ変更検知と通知
Cosmos DBの変更フィードを利用してデータ更新を検知。
Functionsをトリガーとして実行し、変更内容をTeamsで通知。


# 自動化の次のステップ：複雑なワークフローの構築
## 1. Hybrid Runbook Workerでオンプレミス環境を自動化
Azure AutomationのHybrid Runbook Workerを利用すると、オンプレミスのリソースを管理するRunbookを実行できます。

ユースケース
オンプレミスサーバーのパッチ管理。
ネットワーク機器の設定変更。
実践例: オンプレミスサーバーのバックアップ

Hybrid Runbook Workerをセットアップ。
Runbookでバックアップタスクを作成。
スケジュール設定で定期的に実行。

## 2. 複数サービスをまたぐ自動化フロー
Logic AppsとAutomation Runbookを連携することで、Azure内外のサービスを横断した自動化が可能です。

シナリオ例: サーバーレスCI/CDパイプライン
Azure DevOpsでコードがプッシュされたらLogic Appsをトリガー。
Automation Runbookで環境をプロビジョニング。
Azure Functionsでアプリケーションをビルド・デプロイ。

# 運用をよりスマートにするツール連携
## 1. Azure MonitorとAutomationの連携
Azure Monitorでリソースのメトリクスやログを監視し、特定条件をトリガーにAutomation Runbookを実行できます。

実践例: 高負荷時のスケールアウト
Azure MonitorでCPU使用率を監視。
CPU使用率が80%を超えた場合にRunbookでVMを追加スケール。

## 2. Power BIによる運用データの可視化
Logic Appsでデータを収集し、Power BIに送信することで運用データの可視化が可能です。

ユースケース
仮想マシンの稼働状況をダッシュボード化。
セキュリティイベントのトレンドをリアルタイム監視。

# ベストプラクティス：自動化とPaaSを組み合わせるポイント
## 1.小規模な自動化から始める

初めは単純なRunbookやLogic Appsフローを構築し、徐々に複雑なワークフローに拡張。

## 2.ログと監視を統合

Azure MonitorやLog Analyticsを活用し、自動化の実行結果やエラーをトラブルシュートしやすくする。
## 3.Infrastructure as Code（IaC）の採用

Azure Resource Manager（ARM）テンプレートやTerraformを活用し、リソースのデプロイと自動化をコードで管理。
## 4.セキュリティを優先

Automation アカウントのRun Asアカウントの適切なロール割り当てや、SecretsのKey Vault管理を徹底する。

# まとめ
AzureのPaaSとAutomation アカウントを活用すれば、複雑なワークフローやマルチサービスを横断した運用の自動化が可能です。本記事では以下を重点的に紹介しました：

PaaSサービス（API Management、Event Grid、Cosmos DB）の応用。
自動化の進化（Hybrid Runbook Workerや複数サービス連携）。
Azure MonitorやPower BIによるスマートな運用。
これらを駆使して、運用を効率化し、開発やビジネスにより集中できる環境を整えてみてください！

さらに高度な設計や運用ノウハウを学びたい方は、以下の公式ドキュメントをチェックしてください：

https://learn.microsoft.com/ja-jp/training/azure/
https://learn.microsoft.com/ja-jp/azure/?product=popular
ノートパソコンが起動しにくい（CMOSバッテリー）

# CMOSバッテリーの消耗でノートパソコンが起動しない

CMOSバッテリーが消耗すると、起動しなくなるノートパソコンがあるようです。

マウスコンピューター社の[DAIV 4P-H(型番:21054P-TGL-H)](https://www.mouse-jp.co.jp/store/g/gdaiv-4p-h-o1/)も、それに該当し、CMOSバッテリーを交換したところ、起動が安定しました。

**他の機種の情報（Qiita記事）**

> CMOS電池が切れたらBIOSすら立ち上がらなくなる機種も存在するよう

→ はい、覚えておきます。

https://qiita.com/0h_su1/items/b5486fde756edaa96ee3#cmos%E3%81%AE%E3%83%90%E3%83%83%E3%83%86%E3%83%AA%E3%83%BC%E3%81%8C%E5%88%87%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B

> CMOSバッテリーが寿命を迎えていると、ハードウェアクロックが進まなくなりgrubへのカウントダウンも止まってしまうよう

→ その原因が何かなんてわかりませんよね。

https://qiita.com/trtrbz21/items/ab01cfcf771b3c226599

> ※ CMOS電池 ... BIOSの情報を保存するための電池。5〜10年ぐらいで電池切れになり、BIOSの起動が行えなくなるらしい。

→ 同様の症状です。

https://qiita.com/hassoubeat/items/83cb8d901d47592975d7



# ちょっと安めの中古ノートパソコン

Windows11対応のノートパソコンが欲しかったので、中古でマウスコンピューター社の[DAIV 4P-H(型番:21054P-TGL-H)](https://www.mouse-jp.co.jp/store/g/gdaiv-4p-h-o1/)を購入しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252891/96421218-e5a0-5483-f291-13bfe291fa48.png)

## 中古価格が安かった理由？

メモリ標準容量が32GBのノートパソコン同士を比較して、一番安いのがこのノートパソコンでしたので、購入しました。

### ファンの音がうるさい

[価格.comのレビュー](https://review.kakaku.com/review/K0001362017/)を見ると、「ファンの音がうるさい」とありました。

https://review.kakaku.com/review/K0001362017/

これは、そのとおりでした。

でも、本当の理由は、起動時に難があることのようです。

### 電源ランプが点灯してもすぐに消灯してしまう

症状としては、電源ボタンを1回押しただけでは、Windowsが起動しません。電源ランプが点灯するものの、数秒で消灯し、起動しません。何度も繰り返し押すとmouseのロゴが表示され、Windowsが起動します。

BIOS画面も現れないし、何かが点滅表示するわけでもなく、単に電源ランプが消灯するだけで、原因を教えてくれないのです。

唯一、起動が成功する合図として、マウスパッド左上のランプが一瞬だけ点灯するので、これが点灯されるまで、根気よく、繰り返し電源ボタンを押します。

:::note warn
実は、店舗で「起動確認させてください」とお願いしたのですが、「起動するとマイクロソフトアカウントの登録が必要となって云々」と店員さんに断られました。
:::

# 交換したCMOSバッテリー

交換したCMOSバッテリーは、コネクタが**1.25mm 2P**のCR2032です。

[DAIV 4P-H(型番:21054P-TGL-H)](https://www.mouse-jp.co.jp/store/g/gdaiv-4p-h-o1/)には、CR2016が装着されていましたが、スペースがあるので、厚みのあるCR2032でも内部に収まります。

[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/252891/26a91c54-a469-d9f7-09a8-b38ceccb07fe.png)
https://amzn.to/405Cvux](https://amzn.to/405Cvux)

# そのおかげで

2021年頃に出荷されたPCのCMOSバッテリーが2024年には、消耗してしまうんですね。
そのおかげで、中古のノートパソコンを安く入手できました。
Ubuntu22.04LTSにアプデしたらUSキーボードになってしまった

## これは何?

重い腰を上げてUbuntuのバージョンを上げたらキーボードがUSキーボードになってしまい，直すのに一苦労したので防備録。

---

## 環境

- Thinkpad X1 Carbon GEN9
- Ubuntu 20.04 LTS→Ubuntu 22.04 LTS

---

## もともとどんな設定だったか

- Ubuntuのデフォルトアプリのキーボードの設定でJapanese Mozcを選択していた。

https://qiita.com/nanbuwks/items/bcd6c838487c906a70e1

写真撮っていなかったのでイメージ図お借りしました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/9074fbb5-4191-130e-020d-238e8101bd12.png)

---

## Ubuntu 22.04に上げたらどうなったか

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/7db4f6bd-b312-576f-d300-1888867d93e0.png)

設定画面からmozcが選べなくなっていました。

---

## 直し方

### Fcitx5をインストールする

> Fcitx5 は、軽量コアを備えたインプットメソッドフレームワークであり、アドオンを介して追加の言語サポートを提供します。 Fcitx の後継です。 [ArchWiki](https://wiki.archlinux.jp/index.php/Fcitx5)

```shell
sudo apt install fcitx5-mozc
im-config -n fcitx5
```

### 設定アプリからVirtual Keyboardの設定変更

Virtual KeyboardをにFcitx5を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/2544d91a-9795-d9d5-6129-ce5174138fd0.png)

### Fcitx5 Configureのアプリからmozcを選択する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/6152ff29-f51b-7eeb-1a2f-3f7ded2efb69.png)

これでrebootすると右上に`A`がでます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/c2f15496-1063-fee7-3020-161bb8cbc4be.png)


### ibusの設定ファイルを編集する

/usr/share/ibus/component/mozc.xmlを見ると以下のように書いてあります。
ローカルの設定ファイルがありそうなのがわかります。

```/usr/share/ibus/component/mozc.xml
<component>↲
  <name>com.google.IBus.Mozc</name>↲
  <description>Mozc Component</description>↲
  <exec>/usr/lib/ibus-mozc/ibus-engine-mozc --ibus</exec>↲
  <version>2.26.4220.100+dfsg-5.2</version>↲
  <author>Google Inc.</author>↲
  <license>New BSD</license>↲
  <homepage>https://github.com/google/mozc</homepage>↲
  <textdomain>ibus-mozc</textdomain>↲
  <engines exec="/usr/lib/ibus-mozc/ibus-engine-mozc --xml" />↲
</component>↲
↲
<!-- Settings of <engines> and <layout> are stored in ibus_config.textproto -->↲<!-- under the user configuration directory, which is either of: -->↲
<!-- * $XDG_CONFIG_HOME/mozc/ibus_config.textproto -->↲
<!-- * $HOME/.config/mozc/ibus_config.textproto -->↲
<!-- * $HOME/.mozc/ibus_config.textproto -->↲

```
- layoutがdefaultになっているので変更します。

```$HOME/.mozc/ibus_config.textproto
cat .mozc/ibus_config.textproto 
engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "jp"
}
```

---

## 再発したケース

Fcitx5をアプリランチャーから再起動すると再発しました。rebootしたら直った。

---

## 参考にさせていただいたサイト

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0689

https://qiita.com/dimanche/items/ebeefc82c90d03ead81f
主観に頼らないUXライティングのレビュー方法を考えてみる

## はじめに
みなさんこんにちは。株式会社リンクアンドモチベーションでストレッチクラウドのUX/UIデザインを担当している[mizo](https://x.com/mizodesign_0607)です。今回は、直近でチームでも悩んだUXライティングのレビューについて、まとめてみようと思います。

## なぜUXライティングのレビューは難しいのか

##### UXライティングのレビューは主観が入りやすい
UXライティングのレビューで最も難しいのは、**「個々の読解力やバックグラウンドに影響される」** という点です。極端な話、小学生でもレビューができてしまう領域です。得体の知れない専門分野ならレビューは困難ですが、「日本語」という身近なツールを使っているため、誰でも意見を出せてしまうのです。この特性が、レビューを複雑化させる要因となっています。

##### 「正解」が一つに定まらない表現の多様性
UXライティングにおいて「正解」が一つに定まらない理由は、言葉が持つ多層的な意味やニュアンスにあります。たとえば、「簡潔に書くこと」が一般的には良いライティングの基準とされますが、それが必ずしも全てのケースでユーザーにとって最適とは限りません。ペルソナのITリテラシーやプロダクトへの理解度によって、どの程度丁寧に説明すべきかは大きく変わります。初心者向けには詳細でわかりやすい説明が求められる一方、熟練者にとっては冗長に感じられることもあります。


## 主観的なレビューになりがちなシチュエーション
##### 異なる職種間でレビューを行う場合
特に最近、レビューに時間がかかってしまったシチュエーションです。

	・デザイナーの視点：「直感的に操作を連想できる文言にしたい。」
	・エンジニアの視点：「データの条件によってこの文言が変化する場合を考慮したい。」
	・プロダクトマネージャーの視点：「対となる概念との兼ね合いを考慮したい。」
上記のような、職種間で大切にしたい観点の違いによって、レビューが何度も行き来することがありました。それぞれの観点はどれも重要で、誰の意見も間違っているわけではありません。ただし、これらすべてをまとめて最適な文言を導き出すのは簡単ではなく、答えがなかなか出せない状況が続いていました。

## 主観を排除するためのアプローチ

例えば、以下のようなユーザーを削除する際に表示されるモーダルについて考えてみてください。「シンプルでわかりやすくすべき」「削除の結果についても記載した方がいい」「トーンを柔らかくした方がよい」など、さまざまな意見が思い浮かぶのではないでしょうか。このように、意見がまとまらずなかなか決まらない場合には、以下の2点を意識すると良いかと思います。

![スクリーンショット 2024-12-23 20.00.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2641301/4651d5aa-88f9-34a1-d2d0-3cec9d2a5158.png)



### 1. 基準を明確にすること
 :::note warn
レビューをお願いするときに「ざっくり」依頼をしてしまっていませんか？
:::

ざっくりと依頼してしまうと、決め切るのが難しくなります。そこで、どの観点でレビューすれば良いのかをリスト化し、その観点に沿ってレビューできる環境を整えることが重要です。

```
例)
- 文言は簡潔か？（20文字以内など具体的に設定）
- ユーザーに期待される行動が明確か？
- 不安を煽る表現になっていないか？
```

### 2.ユーザーを中心に考える

 :::note warn
結局ユーザーが理解できる言葉ですか？
:::

社内でのレビューや同じ職種間での壁打ちはもちろん重要です。しかし、どれだけ議論を重ねて導き出した答えであっても、最終的にユーザーが理解できるかどうかはユーザー自身にしかわかりません。であれば、合理的に判断した案を実際にユーザーに見せるのが最も早い方法です。インタビューの調整が難しい場合は、メールなどで簡単に意見を聞く方法もおすすめです。


## まとめ
弊社でも、UXライティングのレビューがスムーズに進まないことがあります。異なる意見が出るのは「全員が顧客価値を向上させるため」に考えているからです。決して意地悪でいろんなレビューをしている訳ではありません。その点を改めて念頭に置きながら、チェックリストを少しずつ充実させたり、レビューを依頼する際のコミュニケーションに気を配ったりと、地道な取り組みを続けていくことが重要だと思います。

ここまでお読みいただき、ありがとうございました！
モダンなAWSマルチアカウントの実装

# 1. はじめに

AWSのマルチアカウント構成について、Control Tower、Organizations、IAM Identity Centerを使用した実装方法をまとめてみました。

以下の構成図は、GitHubとの連携やSlack通知を含めた、実践的なマルチアカウント環境を示しています。

制限のない自社開発企業やスタートアップ企業には是非とも導入して欲しい構成です。

![aws_multi_account.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263017/7b3a356d-63b5-0773-7841-7ef1662436ab.png)

# 2. アカウント構成と役割

## 2.1. 管理アカウント（Management Account）
管理アカウントには以下の主要サービスを配置します：
- Control Tower：マルチアカウントの管理
- Organizations：組織単位（OU）の管理
- IAM Identity Center：シングルサインオンの提供

## 2.2. Security OU
セキュリティ関連のアカウントを管理するOUです：

### 2.2.1. 監査アカウント（Audit Account）
- セキュリティ監査の実施
- コンプライアンスの確認
- AWS Configルールの管理
- SecurityHub、Inspector、GuardDuty、IAM Access Analyzerなどのセキュリティサービスの集約

### 2.2.2. ログアカウント（Log Account）
- Config、CloudTrailログの集約
- セキュリティログの保管
- ログ分析環境の提供

## 2.3. Member OU
各環境のワークロードを管理するOUです。
アプリケーションやWebサービスの種類ごとに、独立したアカウントを作成することをお勧めします：

### 2.3.1. アカウント分割の考え方
1. **環境による分割**
- 開発環境（dev）：開発者が自由に検証できる環境
- ステージング環境（stg）：本番相当の検証環境
- 本番環境（prod）：実サービスの運用環境

2. **サービスによる分割**
- アプリケーションごとにアカウントを分離
- マイクロサービスごとの分離
- プロジェクトやチームごとの分離

このような分割により：
- サービスごとの独立した開発が可能
- 環境ごとの適切なセキュリティ設定
- コストの明確な分離
- 障害影響範囲の局所化

### 2.3.2. 開発環境（dev-アプリ）
- 開発用のリソース管理
- テスト環境の提供
- 開発者向けの柔軟な権限設定

### 2.3.3. ステージング環境（stg-アプリ）
- 本番相当の検証環境
- 結合テスト環境
- リリース前の最終確認環境

### 2.3.4. 本番環境（prod-アプリ）
- 実サービスの運用環境
- 厳格なセキュリティ設定
- 本番データの管理

# 3. CI/CD構成

## 3.1. GitHub連携
- アプリケーションコードの管理
- インフラコードの管理
- GitFlowベースのブランチ戦略

## 3.2. ブランチ戦略とデプロイフロー

### 開発環境（dev）
- feature/XXXブランチで開発
- developブランチへのマージで自動デプロイ
- 単体テスト、lint チェックの自動実行

### ステージング環境（stg）
- developブランチからstagingブランチへのマージで自動デプロイ
- 結合テスト、E2Eテストの自動実行
- QA・動作確認用の環境として利用

### 本番環境（prod）
- stagingブランチからmainブランチへのマージで自動デプロイ
- 本番リリース用のタグ付け
- リリースノートの自動生成

### 共通基盤環境（Management/Security OU）
- management、audit、logアカウントはdev/stg/prodの環境分離なし
- GitHub Flowに従い、mainブランチへのマージで直接デプロイ
- 変更時は事前承認プロセスを実施
- デプロイ前の自動テスト実施必須

## 3.3. GitHub Actions
- 環境変数は各環境のSecretsで管理
- デプロイ時のSlack通知連携
- 各種テストの自動実行
- インフラのProvisioning自動化
- フロント・バックエンドの自動デプロイ

## 3.4. 各種フレームワーク対応
- Terraform：インフラのコード化
- Rails/Go/Nuxt.js等のアプリケーションデプロイ
- コンテナイメージのビルドと管理

# 4. 通知・モニタリング

## 4.1. Slack連携
- デプロイ結果の通知
- アラート通知
- 承認ワークフローの連携

# 5. IAM Identity Center構成

## 5.1. 権限管理
- AWS Developer権限の付与
- 環境別のアクセス制御
- MFAの強制適用

## 5.2. SSO設定
- GitHubとの連携
- 環境別のロール設定
- アクセス監視

# 6. セキュリティ設定

## 6.1. ガードレール
- Control Towerの予防的ガードレール
- Control Towerの検出的ガードレール
- 各OUごとのSCP設定

## 6.2. アカウント間の連携
- CloudTrailログの集約設定
- AWS Config集約設定
- SecurityHubの統合
- InspectorやGuardDutyの統合などなど

# 7. シングルアカウントからの移行

## 7.1. 移行の基本方針
- 既存のシングルアカウントを本番環境（prod）として位置づけ
- シングルアカウント内の開発・ステージング環境は段階的に削除
- 新規の開発・ステージング環境は新アカウントで構築

## 7.2. 移行手順
1. Control Towerのセットアップ
2. Security OUの構築（audit, log）
3. Member OUの構築（dev, stg）
4. IAM Identity Centerの設定
5. 既存アカウントのOrganizationsへの招待
6. 既存アカウントの開発・ステージング環境の削除

## 7.3. 移行時の注意点
- 既存リソースの依存関係の確認
- 移行期間中の一時的な権限設定
- デプロイパイプラインの更新
- 監視・アラートの再設定

# 8. さいごに

この構成により、開発からセキュリティまでをカバーした、実践的なマルチアカウント環境を実現できます。Control Tower、Organizations、IAM Identity Centerの組み合わせにより、効率的かつセキュアな運用が可能になります。
Dockerファイルの作成から実行まで

## はじめに
dockerファイルの生成から実行までを記載します。
基本的には公式ドキュメントの内容になりますが、要所要所で細かな調査や解説を交えていきます。

## 参考サイト

https://docs.docker.jp/windows/step_four.html

## 前提条件
Dockerのインストールはすでに完了しているものとします。

## 環境
Ubuntu24.04
WSL2
Windows11

## 手順


### Dockerfileの生成を行う

```
touch Dockerfile
```
を実行しDockerfileを作成します

### ファイルに内容を記載する
作成されたファイルに以下の情報を記述します

```
FROM docker/whalesay:latest

RUN apt-get -y update && apt-get install -y fortunes

CMD /usr/games/fortune -a | cowsay
```

順番に内容を解説していきます。

#### 1行目
FROMはイメージの指定の箇所になります。
今回はdocker/whalesayのlatestつまり最新版を取得しています。

> FROM 命令は、新しい 構築ステージbuild stage を初期化し、以降の命令で使う ベース・イメージ を指定します。そのため、正しい Dockerfile とは FROM 命令で始める必要があります。イメージとは、適切なイメージであれば何でも構いません。 公開リポジトリ から イメージを取得して始める のが、特に簡単です。

https://docs.docker.jp/engine/reference/builder.html#from

#### 2行目
RUNは実行するコマンドについてです。
ここではapt-get -y updateとapt-get install -y fortunesを実行しています。
アップデートをした状態でインストール作業を行っています。

#### 3行目
CMDはコンテナ実行時のデフォルト（初期設定）を指定するためのものになります。
CMDはDockerfile中で１度しか使えず、複数のCMD命令がある際は最後のCMDのみ有効となります。

https://docs.docker.jp/engine/reference/builder.html#cmd

### ビルドを実行する
docker build -t docker-whale .を実行します
-tはタグを付けるオプションとなります
ビルドを実行する際のDockerfileはそのディレクトリに依存します

https://docs.docker.jp/engine/reference/commandline/build.html#t

### イメージの実行
イメージが生成されたのかの確認のために``` docker images ```を実行します
イメージの生成を確認できたのなら``` docker run docker-whale ```を実行します
賢くなりました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/330568/e16d4321-65c3-218b-504b-a95c83ad9617.png)
AzureでPaaSと自動化を最大限活用する方法：初心者ガイド

こんにちは！この記事では、Microsoft AzureのPaaS（Platform as a Service）と自動化機能に焦点を当てて解説します。Azureは多機能なクラウドサービスですが、その中でも特に開発者の負担を軽減し、運用を効率化するPaaSと自動化ツールの使い方を具体例と共にご紹介します。

# Azureとは？
Azureは、Microsoftが提供するクラウドサービスプラットフォームで、IaaS（Infrastructure as a Service）、PaaS（Platform as a Service）、SaaS（Software as a Service）を提供しています。

PaaSは、アプリケーションの開発に必要な環境を提供するサービスモデルで、サーバー管理や運用の手間を省き、開発そのものに集中できます。

# Azureの代表的なPaaSサービス
## 1. Azure App Service
Azure App Serviceは、WebアプリやAPIを簡単に構築・ホストできるPaaSサービスです。

特徴
多言語対応: .NET、Java、Python、Node.jsなど幅広く対応
自動スケーリング: トラフィック増減に応じてリソースを調整
セキュリティ対応: Azure Active DirectoryやSSL証明書の統合が簡単
ユースケース例
ビジネス向けWebアプリケーションのホスティング
スマートフォンアプリのバックエンドAPI
実践例: 簡単なWebアプリのデプロイ

Azureポータルで「App Service」を作成
必要な設定（ランタイム、リージョンなど）を選択
アプリをデプロイして即座に稼働確認
## 2. Azure Functions
Azure Functionsは、サーバーレスアーキテクチャを簡単に構築できるサービスです。

特徴
イベントドリブンの自動実行（例: ファイルアップロード時の処理）
トリガーの種類が豊富（HTTPリクエスト、タイマー、Azureストレージなど）
実行した分だけ課金されるためコスト効率が高い
ユースケース例
定期的なデータ処理（ログの集計など）
IoTデバイスから送信されるデータのリアルタイム処理
サンプルコード: 定期実行タスク（タイマートリガー）

javascript
module.exports = async function (context) {
    context.log('Scheduled task executed at', new Date());
};
## 3. Azure Logic Apps
ノンコーディングでワークフローを構築できるサービスです。ドラッグ＆ドロップでプロセスを自動化できます。

特徴
多彩なコネクタ（Slack、Salesforce、Google Driveなど）を標準装備
定期実行やイベントドリブンで柔軟に設定可能
ユースケース例
新しいメールを受信したら、添付ファイルを自動保存
データベースの更新をトリガーにレポートを生成
Automation アカウントを使った自動化
PaaSを活用するだけでなく、Azureの「Automation アカウント」を使うことで、さらなる運用効率化が可能です。

## 4.Automation アカウント
Azure Automation アカウントは、運用タスクの自動化を支えるツールで、以下の機能を備えています：

Runbook: 定義されたスクリプトやワークフローをスケジュール・実行
Update Management: 仮想マシンのパッチ適用を自動化
Change Tracking: 設定変更の追跡
Desired State Configuration (DSC): サーバー構成の一貫性を保証
Automation アカウントの主要機能と実践例
### 1. Runbookで繰り返しタスクを自動化
Runbookを使えば、サーバー操作や定期的な管理タスクを自動化できます。

実践例: VMのスケジュール起動/停止

powershell

Azure Automation用のPowerShellスクリプト
$resourceGroupName = "myResourceGroup"
$vmName = "myVM"
Start-AzVM -ResourceGroupName $resourceGroupName -Name $vmName
このスクリプトを登録し、スケジュールを設定するだけで、毎朝VMを自動起動可能です。

### 2. Update Managementでパッチ適用を自動化
仮想マシンのパッチ適用を自動化し、セキュリティリスクを低減できます。

手順

Automation アカウントを作成し、Update Managementを有効化
VMをリンクし、スケジュールを設定
必要なパッチを自動適用し、結果を確認
### 3. Desired State Configuration (DSC)で構成を一貫化
DSCを使うことで、サーバーが常に「望ましい状態」に保たれます。

構成例: IISインストール

powershell
Configuration IISInstall {
    Node "localhost" {
        WindowsFeature IIS {
            Name = "Web-Server"
            Ensure = "Present"
        }
    }
}
#### 自動化とPaaSの応用事例
##### 1. リソース最適化
未使用リソースの削除: Automation Runbookで、タグに基づいて不要なリソースを定期削除
コストレポート生成: Logic Appsと連携して利用状況をレポート化
##### 2. セキュリティと運用強化
脅威検出後の自動対応: Azure Security CenterとRunbookを連携
システム変更の追跡: AutomationのChange Trackingを利用
##### 3. 災害復旧（DR）の自動化
Runbookを活用し、障害発生時に別リージョンのリソースを自動起動する仕組みを構築可能。

# まとめ
AzureのPaaSサービスとAutomation アカウントを活用すれば、開発と運用を効率化し、リソースの無駄を削減できます。特に、Azure App Service、Functions、Logic Appsで開発に集中し、Automation アカウントで繰り返しタスクを自動化する組み合わせは強力です。

ぜひこの記事を参考に、Azureを使った開発と運用の自動化を実践してみてください！
【Panda CSS】Vite で Panda CSS を使ってみた

# はじめに
この記事では、Vite 環境で Panda CSS を利用する手順を記載します。

https://vite.dev/

https://panda-css.com/

# 開発環境
開発環境は以下の通りです。

- Windows 11
- React 18.3.1
- TypeScript 5.5.2
- Vite 6.0.3
- Panda CSS 0.49.0
- npm 10.9.0
- Node.js 22.11.0

# Vite プロジェクトファイルの作成
以下のコマンドでプロジェクトファイルを作成します。

```powershell
npm create vite@latest panda-css-vite -- --template react-ts
```

プロジェクトファイルが作成されたら以下のコマンドを実行して、ローカルサーバーを起動します。

```powershell
cd panda-css-vite
npm install
npm run dev
```

ローカルサーバー起動後、ターミナルに表示される URL へアクセスすると、以下の画面が表示されます。

http://localhost:5173/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/4c981a4a-c4cb-81aa-fb31-515873eed1be.png)

# Panda CSS のインストール
以下のコマンドで Panda CSS をインストールします。

```powershell
npm install -D @pandacss/dev
```

# 設定ファイルの追加
以下のコマンドで Panda CSS の設定ファイルを作成します。

```powershell
npx panda init --postcss
```

コマンドが実行されると `panda.config.ts` と `postcss.config.cjs` の2ファイル作成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/2941bd90-1efc-b5e2-fbae-e98c567185c7.png)

各ファイルの中身は以下の通りです。

```panda.config.ts
import { defineConfig } from "@pandacss/dev";

export default defineConfig({
  // Whether to use css reset
  preflight: true,

  // Where to look for your css declarations
  include: ["./src/**/*.{js,jsx,ts,tsx}", "./pages/**/*.{js,jsx,ts,tsx}"],

  // Files to exclude
  exclude: [],

  // Useful for theme customization
  theme: {
    extend: {},
  },

  // The output directory for your css system
  outdir: "styled-system",
});
```

```postcss.config.cjs
module.exports = {
  plugins: {
    '@pandacss/dev/postcss': {},
  },
}
```

# package.json の更新
`package.json` の `scripts` に [panda codegen](https://panda-css.com/docs/references/cli#panda-codegen) を実行するスクリプトを追加します。

```package.json
  ...,
  "scripts": {
    "prepare": "panda codegen",
    ...,
  },
  ...
```

:::note
この手順により依存関係をインストールする度に Panda の出力ディレクトリが再作成されます。そのため、`.gitignore` に styled-system が自動で追加されていますが、気にする必要はありません。
:::

# CSS ルートファイルの設定
CSS のルートファイルに以下のコードを追加します。

```src/index.css
@layer reset, base, tokens, recipes, utilities;
```

# Panda CSS を利用して実装する

```src/App.tsx
import { css } from '../styled-system/css';
 
function App() {
  return (
    <div className={css({ fontSize: "2xl", fontWeight: 'bold' })}>Hello 🐼!</div>
  )
}
 
export default App;
```

ローカルサーバーを再起動して、動作確認をします。
Panda CSS が適用された「Hello 🐼!」が表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/01d0814a-1af4-df18-6ffb-10c776f4941a.png)

CSS の変更が反映されることも確認できます。

```src/App.tsx
import { css } from "../styled-system/css";

function App() {
  return (
    <div className={css({ fontSize: "8xl", fontWeight: "bold" })}>
      Hello 🐼!
    </div>
  );
}

export default App;

```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318188/829c2c8a-ff73-728a-2c98-21656b0ee741.png)


# 参考
- [Using Panda CSS with Vite](https://panda-css.com/docs/installation/vite)
ゼロから始めるSnowflake（8/10）

# コードの確認

## INFORMATION_SCHEMAを利用したメタデータクエリ

`INFORMATION_SCHEMA`は，データベース，スキーマ，テーブル，ビューなどの統計情報を保持するメタデータのリポジトリである．

以下のSQLを実行し，ユーザーのGARDEN_PLANTSデータベース内のすべてのスキーマを取得する．

```sql
SELECT *
FROM garden_plants.information_schema.schemata;
```

## 作業確認コードの実行

### チェック1: 必須スキーマの存在確認
以下のSQLを使用し，FLOWERS，VEGGIES，FRUITSスキーマが存在し，PUBLICスキーマが存在しないことを確認する．

```sql
WITH schema_check_1 AS (
    SELECT COUNT(*) AS count_1
    FROM garden_plants.information_schema.schemata
    WHERE schema_name IN ('FLOWERS','VEGGIES','FRUITS')
),
schema_check_2 AS (
    SELECT COUNT(*) AS count_2
    FROM garden_plants.information_schema.schemata
    WHERE schema_name = ('PUBLIC')
)
SELECT IFF((count_1=3) AND (count_2=0),'\u2705 正解','\u26D4 間違い．確認して，再実行してみましょう．') AS schema_check
FROM schema_check_1, schema_check_2;
```

### チェック2: 作成したスキーマの名前確認
スキーマ名が正しいかを確認するためのSQLを実行する．正しい場合，3行が返される．

```sql
SELECT schema_name
FROM GARDEN_PLANTS.INFORMATION_SCHEMA.SCHEMATA
WHERE schema_name IN ('FLOWERS','FRUITS','VEGGIES');
```

### チェック3: ROOT_DEPTHテーブルの存在確認
VEGGIESスキーマ内にROOT_DEPTHテーブルが作成されているか確認するため，以下のストアドプロシージャを呼び出す．

```sql
CALL common_db.resources.local_grader('OB03', '{{user}}');
```

## クエリ履歴の確認

Snowflakeでは，クエリ履歴を確認することで，実行したクエリを再チェックできる．

1. SQLセルの右上に表示される実行時間をクリックする．
2. ダイアログ内の青い**ID**リンクをクリックし，クエリプロファイルを開く．
3. クエリプロファイルで詳細な実行手順を確認し，緑色のチェックマークが表示されているか確認する．

:warning: チェックが通らない場合は，エラーを修正して再実行すること．
ゼロから始めるSnowflake（9/10）

# ステージと半構造化データ

## ステージオブジェクトの作成

Amazon S3バケットに対するステージを作成する．

### ステージの作成手順

1. Snowsightで**UTIL_DB**データベースの**PUBLIC**スキーマを選択する．
2. **作成**ボタンをクリックし，**外部ステージ** > **Amazon S3**を選択する．
3. **ステージ名**に`like_a_window_into_an_s3_bucket`と入力する．
4. **URL**には`s3://uni-lab-files`を指定する．
5. **ディレクトリテーブル**オプションを有効化したままにする．
6. **作成**ボタンをクリックしてステージを作成する．

作成後，ステージ上のファイルがSnowsightで確認できるようになる．

## LISTコマンドの利用

`LIST`コマンドを使用してステージ内のファイルを確認する．ステージ名を参照する際は`@`を先頭に付ける．

```sql
USE SCHEMA UTIL_DB.PUBLIC;

LIST @like_a_window_into_an_s3_bucket;
```

### Snowflakeの命名規則

- Snowflakeは大文字/小文字を区別しない．オブジェクト名は大文字に変換される．
- Amazon S3では大文字小文字を正確に区別する必要がある．

## COPY INTO文によるデータロード

### テーブルの作成

```sql
USE SCHEMA GARDEN_PLANTS.VEGGIES;

CREATE OR REPLACE TABLE vegetable_details_soil_type (
    plant_name VARCHAR(25),
    soil_type NUMBER(1,0)
);
```

### データのロード

以下のSQLを使用して，ステージ内のデータをテーブルにロードする．
ファイルはSnowflakeが提供しているウェブコンテンツ[Badge 1: Data Warehousing Workshop](https://learn.snowflake.com/en/courses/uni-essdww101/)からダウンロードする．

```sql
COPY INTO vegetable_details_soil_type
FROM @util_db.public.like_a_window_into_an_s3_bucket
FILES = ('VEG_NAME_TO_SOIL_TYPE_PIPE.txt')
FILE_FORMAT = (
    TYPE = csv,
    FIELD_DELIMITER = '|',
    SKIP_HEADER = 1
);
```

### LU_SOIL_TYPEテーブルの作成とデータロード

以下のスキーマを使用して新しいテーブルを作成し，データをロードする．
ファイルはSnowflakeが提供しているウェブコンテンツ[Badge 1: Data Warehousing Workshop](https://learn.snowflake.com/en/courses/uni-essdww101/)からダウンロードする．

```sql
CREATE OR REPLACE TABLE lu_soil_type (
    soil_type_id NUMBER,
    soil_type VARCHAR(15),
    soil_description VARCHAR(75)
);
```

- **FIELD_DELIMITER**: タブ区切りの場合は`'\t'`を指定する．

```sql
COPY INTO lu_soil_type
FROM @util_db.public.like_a_window_into_an_s3_bucket
FILES = ('LU_SOIL_TYPE.tsv')
FILE_FORMAT = (
    TYPE = csv,
    FIELD_DELIMITER = '\t',
    SKIP_HEADER = 1
);
```

## 半構造化データの取り扱い

### `VARIANT`データ型

`VARIANT`は，階層構造や入れ子構造を持つ半構造化データを格納するためのデータ型である．以下の例では，`VARIANT`列を持つテーブルを作成する．

```sql
CREATE OR REPLACE TABLE GARDEN_PLANTS.VEGGIES.VEGETABLE_DETAILS_PLANT_HEIGHT (
    record VARIANT
);
```

### JSONデータのロード

以下の`COPY INTO`文を使用して，JSONファイルをロードする．
ファイルはSnowflakeが提供しているウェブコンテンツ[Badge 1: Data Warehousing Workshop](https://learn.snowflake.com/en/courses/uni-essdww101/)からダウンロードする．

```sql
COPY INTO vegetable_details_plant_height
FROM @common_db.resources.course_files/veg_plant_height.json
FILE_FORMAT = (TYPE = 'JSON');
```

### ロードしたデータのクエリ

`VARIANT`データ型に格納されたデータをクエリするために特別な演算子や関数を使用する．
【debian12】xrdp+pipewire-module-xrdpでRDP接続先のサウンドをローカルで鳴らす

■xrdp側の環境
　クライアント側は「ローカルで音を出すよ」って宣言できるrdpクライアントなら何でも良い
 
```
$ lsb_release -d
No LSB modules are available.
Description:	Debian GNU/Linux 12 (bookworm)
```
■xrdpサーバ側のサウンドドライバが「ダミー出力」や「Dummy Output」では音が出ないというのが課題

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193274/a79b777d-37fd-885c-a847-8d774aa01845.png)

■xrdpサーバ側の現状
　xrdpのモジュールを入れるかソースからコンパイルするかが必要な状況

```
$ dpkg -l | awk '$1 ~ /ii/ && $2 ~ /xrdp|remmina/{print $2,$3,$4}'
xorgxrdp 1:0.9.19-1 amd64
xrdp 0.9.21.1-1 amd64
```

■サーバ側バックポートを追加、backports版のxrdpモジュールを使う
　debianはデフォルトがpulseaudioではなくpipewireなので。
 
```
$ tail -3 /etc/apt/sources.list
# pipewire-module-xrdp 
deb http://deb.debian.org/debian/ bookworm-backports main non-free-firmware contrib non-free
```
■bpo12版のxrdpとpipewire-module-xrdpをインストールして対処
　「-t bookworm-backports」でリポジトリを指定
 
```
$ sudo apt-get update

$ apt-cache search pipewire-module-xrdp
pipewire-module-xrdp - audio over xrdp for PipeWire based systems

$ sudo apt-get purge xrdp
$ sudo apt-get install -y pipewire
$ sudo apt-get -t bookworm-backports install -y xrdp pipewire-module-xrdp

$ dpkg -l | awk '$1 ~ /ii/ && $2 ~ /xrdp|remmina/{print $2,$3,$4}'
libpipewire-0.3-modules-xrdp:amd64 0.2-2~bpo12+1 amd64
pipewire-module-xrdp 0.2-2~bpo12+1 all
xorgxrdp 1:0.9.19-1 amd64
xrdp 0.9.24-5~bpo12+1 amd64
```

■xrdp起動エラーの対処
　証明書を読み込む権限のお話なので
 
```
$ sudo systemctl restart xrdp.service
...
xrdp[2573]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
```

```
$ sudo adduser xrdp ssl-cert
$ sudo systemctl restart xrdp.service
$ sudo systemctl status xrdp.service 
```

■クライアント側に必要なのはremminaだけ。backports版である必要はない

```
$ dpkg -l | awk '$1 ~ /ii/ && $2 ~ /xrdp|remmina/{print $2,$3,$4}'
remmina 1.4.29+dfsg-1 amd64
remmina-common 1.4.29+dfsg-1 all
remmina-plugin-rdp:amd64 1.4.29+dfsg-1 amd64
remmina-plugin-secret:amd64 1.4.29+dfsg-1 amd64
remmina-plugin-vnc:amd64 1.4.29+dfsg-1 amd64
```

■remminaクライアント側は「ローカル」で鳴らすように設定するだけ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193274/4572e20f-ff20-95f7-a82a-d287b3c7a173.png)


■xrdpサーバ側で出した音がローカルで鳴る
　音質の途切れ具合いはレイテンシ等の調整でなんとかなる気はするけど？

```
$ sudo ps aux | awk '/pw-cl[i]/{print substr($0,68)}' | awk '{for(a=1;a<=NF;a++){print "  "$a}}'
  pw-cli
  -m
  -d
  load-module
  libpipewire-module-xrdp
  sink.node.latency=2048
  sink.stream.props={node.name=xrdp-sink}
  source.stream.props={node.name=xrdp-source}
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/193274/3ff99850-816c-393d-1e8f-1dd7ba4c5009.png)
エンドポイントサービスでプライベートDNS名を有効化した時の動作

# 内容
エンドポイントサービス作成時、下記「プライベートDNS名を有効化」した場合に設定される内容と名前解決の流れについて記載します。

![vpce.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/58933369-e488-7b2e-7a8b-4bc4f1383f3f.png)

# 設定される項目
左側VPCのVPCエンドポイントから右側VPCのエンドポイントサービス経由でNLB、EC2に接続する構成とします。

![スライド1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/4e04f2a9-d956-3459-52a7-6f9bfa8dd52d.png)

* ①プライベートDNS名を有効化（エンドポイントサービス）
エンドポイントサービス作成時にプライベートDNS名を有効化します。例としてプライベートDNS名は`test.example.com`とします。
※この際指定するのはパブリックドメインである必要があります。

* ②レコード検証
`example.com`が自分が管理しているパブリックドメインであると証明する必要
があります。その方法として`example.com`ホストゾーンにTXTレコードを作成してレコード検証を行います。レコードが作成出来る＝ドメインの管理者といった仕組みです。

* ③プライベートDNS名を有効化（VPCエンドポイント）
VPCエンドポイント作成時も「プライベートDNS名を有効化」という項目があるのでこちらにチェックを入れて有効化した状態で作成します。

* ④プライベートホストゾーン作成（自動）
③までの設定を実施することで、`test.example.com`プライベートホストゾーンが自動的に作成されVPCエンドポイントを作成したVPC内から`test.example.com`の名前解決が可能になります。

コマンドで確認すると下記の用にVPCエンドポイントが内部的に使用するホストゾーンが作成されていることが分かります。

```shell
aws route53 list-hosted-zones-by-vpc --vpc-id vpc-xxxx --vpc-region ap-northeast-1
{
    "HostedZoneSummaries": [
        {
            "HostedZoneId": "xxxxxxxxxxxx",
            "Name": "test.example.com.",
            "Owner": {
                "OwningService": "vpce.amazonaws.com"
            }
        }
    ],
    "MaxItems": "100"
}
```


# 名前解決の流れ（VPC）

VPC内のEC2サーバからはRoute53 Resolver経由で名前解決が可能です。赤線の流れで名前解決を行いオレンジ線の流れでサービスに接続します。


![スライド2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/fccd1c70-d933-f9cc-60af-c0fc96781e17.png)


# 名前解決の流れ（オンプレミス）

オンプレミスから名前解決するためにはRoute53 Inbound Endpointが必要です。この場合、オンプレミスDNSにフォワーダーの設定を行い`test.example.com`の名前解決をRoute53 Inbound Endpointに転送します。こちらも赤線の流れで名前解決を行いオレンジ線の流れでサービスに接続します。

![スライド3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/4d319cc1-c33f-6b49-e380-348c1cc6889f.png)
フロントエンドの負債解消で取り組んだこと

## はじめに

この4ヶ月間で、フロントエンドのリポジトリにおける負債解消を行いました。取り組みに際しては、課題と目標を明確にし、計画的に進めることを意識しました。

開発環境

- React v18
- Next.js v13
- CSS Modules

## 課題

負債解消のために取り組んだ際に直面した、主な設計や構造に関する課題を以下に示します。

###  共通のデザイン箇所がそれぞれベタ書きで書かれている

ページごとに共通のレイアウトが存在していたにもかかわらず、共通化がされていない箇所が多く、各ページで個別にコードが記述されていました。その結果、デザインに一貫性が欠け、ページ間で違いが生じてしまう問題が発生していました。

### ビューとロジックが１つのファイルにまとめられている

ビューとロジックが同一ファイル内に集約されているため、コード量が増大し、可読性が低下していました。また、どこにどの機能が実装されているか分かりにくく、問題の特定や修正が難しくなる可能性がありました。

### コンポーネントがパーツとレイアウトで適切に区切られていない

1つのコンポーネントフォルダ内に複数のレイアウトファイルが混在しており、汎用性が低い設計になっていました。これにより、コードの可読性が悪化し、管理が煩雑になっていました。

### ファイル名が長い

コンポーネント名が長く、同じ名前のバリエーション（例: "HogeBlockInnerFeature"、"HogeBlockInnerItem"）が多く並んでいるため、親コンポーネントと子コンポーネントの関係が分かりにくくなっていました。このような命名は、構造の理解を難しくする原因となります。


### フォルダがバラバラの場所に存在している

コンポーネントが参照される場所がバラバラで、ファイルの場所を毎回確認しなければならない状態でした。これにより、開発者がコードの構造を把握するために多くの時間を費やすことになりました。

### 命名規則・フォルダを作る際にルールがない

コンポーネント作成のルールが不明確であり、開発者ごとに異なるアプローチが取られていました。その結果、コードベースにばらつきが生じ、メンテナンスが困難になる要因となっていました。


### 削除されていないコードや機能が存在する

実際に使用されていない可能性がある機能が残っており、不要なコードが多くなっていました。これがリポジトリの肥大化を招き、全体的な可読性を低下させていました。

## 課題により起こり得る問題

これらの課題が放置されると、以下のような問題が発生する可能性があります。

- 新しい開発者がチームに加わった際に、コードベースの理解が難しく、認知負荷が高くなる
- エラーが発生しやすくなり、バグの原因を追跡するのが困難になる
- ルールがないため、コードレビューが属人化し、チーム全体での品質保証が難しくなる
- 同じ機能を追加したい場合に、再利用可能なコードがないため、再実装が必要になる

## 目標

課題に対して、理想的な状態を実現するために以下の目標を設定しました。

- ファイル構造の見直し: 認知負荷を減らし、効率的に開発が進められるようにする
- コードのリードタイム短縮: 開発スピードを上げ、素早い施策実施を可能にする
- 保守完了期限: 6ヶ月を目標に、SP全体の保守作業を完了させる


## 進め方

- 優先順位付け: 施策で頻繁に触るコンポーネントから優先的に進める
- 安全な改修: 大規模な変更（ディレクトリ構造など）は避け、最小限の変更で進める
- スケジュール管理: 進捗状況を把握するため、計画的にスケジュールを立てて作業を進める

## 具体的に取り組んだこと

以下の取り組みを実施しました。

- 課題整理: 複雑な構造のコンポーネントはFigmaでスクリーンショットを貼り、現状の課題を視覚的に整理する
- コードの共通化: 共通化可能な部分はパーツコンポーネントとして切り分け、再利用性を高める
- 不要な機能の削除: 使用されていないコードや機能を削除し、デザインの見直しも行う
- レビュワーに共有: 具体的な取り組み内容やその意図、確認してほしいポイントをすり合わせる

## 成果との紐付け

リファクタリングは直接的なビジネス成果には結びつきにくい場合がありますが、以下のような長期的なメリットが期待できます。

- エラー削減: 問題のあるコードを整理することで、将来的なエラーのリスクを減少させることができる
- 開発スピードの向上: より効率的に開発できるようになるため、施策を迅速に実施できるようになる
- 品質向上: コードレビューの負担を軽減し、チーム全体で品質が向上する

このように、リファクタリングと保守作業は、ビジネス成果と切り離して考えるべきではなく、並行して取り組むことが重要です。また、コードだけでなく、ドキュメント作成や開発ルールの整備も並行して進めることで、属人化を防ぎ、チーム全体の生産性向上に寄与します。
swingで作成したプログラムからexe形式で実行できるデスクトップアプリを作成する手順

swingで作成した「Hello World」と表示するプログラムをexe形式で出力し、デスクトップアプリを作成する
![スクリーンショット 2024-12-23 202011.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/ed88be9a-b412-f87c-f1ec-5cee6ee3e7ad.png)

## jarファイルを出力する

「ファイル(F)」→「エクスポート(O)」をクリック。
![スクリーンショット 2024-12-23 200156.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/9f8dc5d3-de74-e82e-6b64-de1cb203a637.png)

「実行可能JARファイル」を選択し、「次へ(N)」をクリック。
![スクリーンショット 2024-12-23 200233.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/a34ff9b6-2fc6-6cb2-63db-adeaa763c046.png)

以下を入力後、「完了(F)」をクリック。
・起動構成(L)：mainメソッドがあるクラスを選択する
・エクスポート先(D)：jarファイルの出力先を選択する
![スクリーンショット 2024-12-23 200322.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/a16dd5c9-0a82-bde9-f10c-6cef18343875.png)

## exeファイル（デスクトップアプリ）を作成する
Launch4jを起動し、Output fileとJarを入力後、左上の歯車マークをクリックする。
![スクリーンショット 2024-12-23 201409.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/458b6c3d-48ec-915a-cba4-1250c64206a3.png)

保存先とファイル名を入力し、保存をクリックする。
![スクリーンショット 2024-12-23 201537.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/0004e9fd-2645-0b7f-1c98-4efaec73d9b2.png)

出力したexeファイルをダブルクリックすると、アプリが起動する。
![スクリーンショット 2024-12-23 201757.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/229456/a2e443f3-8d02-99b4-b8eb-ead4c2b6c3b3.png)
iex -S mixとは？

iex -S mixについての理解を深めるために記事を執筆する

そもそもiexとは？
公式サイトにて以下のように記述されていました。

> Elixir's interactive shell.
Some of the functionalities described here will not be available depending on your terminal. In particular, if you get a message saying that the smart terminal could not be run, some of the features described here won't work.

以下google 翻訳
Elixir の対話型シェル。
お使いの端末によっては、ここで説明する機能の一部が利用できない場合があります。特に、スマート ターミナルを実行できなかったというメッセージが表示された場合、ここで説明する機能の一部は動作しません。

https://hexdocs.pm/iex/IEx.html

対話型シェルのことです。

-S mixについて

> iex 内でスクリプトファイルを実行するには、 iex -S SCRIPTNAME とします。あとで Mix や Elixir ビルドツール、そしてコンパイル方法とそのアプリケーションを iex -S mix run で起動する方法についても学んでいきます。

https://elixir-lang.jp/getting-started/introduction.html

つまりmixというスクリプトファイルを実行するためのコマンドが-s mixとなります。

そしてMixは以下のサイトの内容が参考になります

https://elixirschool.com/ja/lessons/basics/mix

iexでelixirについて学ぶのかmixを利用した実行をするのかはある程度意識できるようになった方が良さそうです。
API呼び出しに失敗した状態をGoogle Chrome開発者ツールで再現してみる

### 始めに
WEB開発を行っており、とある異常なデータを検知しました。
ログを探るとフロントであるAPIの呼び出しがネットワークの不調により失敗をしていたことが分かりました。そのAPIの呼び出しに失敗し、取得できるはずのデータが存在しなかったため、その後の処理で異常になったように見えます。
ただし、本当にそうであるか再現確認をする必要があります。

ネットワークを低速モードにして、途中まで読み込んだら読み込み停止！　など頑張っていましたが、思うようにいかず、別の方法で失敗できないか調査したところ、よいブロックの方法が見つかりました。

### ブロックのやり方
折角ですのでQiitaの自身のアイコンをブロックして見えなくしたいと思います。操作はWindowsで実施しています。

1. 対象のページを開く
https://qiita.com/organizations/uniquevision
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/8bcc757d-267b-9c82-a1fc-7e5aa6f32250.png)

2. おもむろに開発者ツール(F12)を立ち上げる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/6a9a31cd-68fa-c99e-feb3-9884a1134b97.png)


3. ページを更新(F5)する
Qiitaでは「デバッガ内で一時停止」と表示されますが、この再現確認では関係してこないのでそのまま再生のアイコンを押してください
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/a1e21178-0319-c3f0-1994-e1c04fdd39a0.png)

4. ネットワークのタブを開き、失敗したいAPIを右クリックする
画像取得系はアイコンが出ているので分かりやすいです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/eb13dd5d-f565-3985-6bc9-da6be32203c1.png)

5. 「ブロック リクエストのURL」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/47582753-beec-e8c0-423d-8b85343f049b.png)

6. 再度更新(F5)する
アイコンが表示されなくなりました。実際にも失敗したAPIで同様のことを行い、無事再現確認が出来ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/e6726a65-b9ac-a9c3-884b-1f224f6de37d.png)


### ブロックの解除の仕方と戻し方
一度ブロックしたとしても開発者ツールを閉じて更新(F5)すると、ブロックは解除されます。
ブロックした際の設定はしっかり残してくれています。
再度開発者ツールを開き、「ネットワーク」から「ネットワーク リクエストのブロック」を確認すると、以前設定していた項目が無効な状態で残っています。
「ネットワークリクエストのブロックを有効にする」を有効にするか、さらに別のリクエストをブロックすることで、リクエストのブロックは有効になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/cec2649f-3d35-42ff-02c5-0893c86ed0b8.png)


### その他
- 手順5で、「リクエスト ドメインのブロック」を指定するとすべてのiconが表示されなくなります
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1227398/eb98d573-ded2-231e-a629-29ea71c701a0.png)

- ワイルドカードを使用してあるパターンにマッチするAPIをブロックすることも可能です
ゼロから始めるSnowflake（7/10）

# Snowflakeタスクにおけるテーブル更新のSQL

以下に，Snowflakeタスクを利用したテーブル更新に関するSQL例を示す．

## テーブル構造

### ソーステーブル
```
CREATE TABLE source_table (
    id INT,
    value STRING,
    updated_at TIMESTAMP
);
```

### ターゲットテーブル
```
CREATE TABLE target_table (
    id INT,
    value STRING,
    updated_at TIMESTAMP
);
```

## 更新SQLの例

ソーステーブルからターゲットテーブルにデータを同期するためのSQLを以下に示す．

```
MERGE INTO target_table AS target
USING source_table AS source
ON target.id = source.id
WHEN MATCHED THEN
    UPDATE SET
        target.value = source.value,
        target.updated_at = source.updated_at
WHEN NOT MATCHED THEN
    INSERT (id, value, updated_at)
    VALUES (source.id, source.value, source.updated_at);
```

## タスクの作成

Snowflakeタスクを利用することで，上記のSQLを定期的に実行することが可能である．以下にタスク作成の手順を示す．

### タスクの作成例
```
CREATE OR REPLACE TASK update_target_table
WAREHOUSE = my_warehouse
SCHEDULE = 'USING CRON 0 * * * * UTC'
AS
MERGE INTO target_table AS target
USING source_table AS source
ON target.id = source.id
WHEN MATCHED THEN
    UPDATE SET
        target.value = source.value,
        target.updated_at = source.updated_at
WHEN NOT MATCHED THEN
    INSERT (id, value, updated_at)
    VALUES (source.id, source.value, source.updated_at);
```

### タスクの有効化
```
ALTER TASK update_target_table RESUME;
```

タスクを有効化すると，指定したスケジュールに従って自動的に実行される．

## 注意点

1. **リソースの確保**: タスク実行時に使用するウェアハウスが十分なリソースを持つよう設定する必要がある．
2. **エラーハンドリング**: 必要に応じてTRY-CATCH構文を利用し，エラー時の対応を明確にする．
3. **データの一貫性**: タスク実行中にデータの一貫性が保たれるよう，適切なロックや分離レベルを設定することが推奨される．
ゼロから始めるSnowflake（6/10）

# Snowflakeの仮想ウェアハウス

## 仮想ウェアハウスとは
仮想ウェアハウスとは，Snowflakeにおけるデータ処理を行うためのコンピューティングリソースの単位である．各ウェアハウスは，クエリの実行やデータのロード，およびその他の操作を処理するために必要な計算能力を提供する．

## 主な特徴
1. **スケーラビリティ**
    - 仮想ウェアハウスはサイズを柔軟に変更できる．必要に応じてスケールアップやスケールダウンが可能である．
    - サイズ変更は実行中のクエリには影響を与えない．

2. **複数のウェアハウス**
    - 複数の仮想ウェアハウスを作成することで，異なるユーザやワークロードを分離できる．
    - ウェアハウスごとに独立したリソースが割り当てられるため，パフォーマンスが干渉しない．

3. **自動停止と再開**
    - 非アクティブ状態が一定期間続いた場合，仮想ウェアハウスは自動的に停止する設定が可能である．
    - 停止中は課金が発生しない．
    - クエリの実行要求があると，自動的に再開される．

## 仮想ウェアハウスのサイズ
仮想ウェアハウスのサイズは，計算リソースの量を指定するものである．以下はSnowflakeが提供する典型的なサイズの一覧である：

- **X-Small**: 最小の計算リソースを提供
- **Small**: 小規模なワークロード向け
- **Medium**: 中規模のワークロード向け
- **Large**以上: 大規模なワークロードや並列処理向け

サイズが大きくなるほど，並列処理の能力が向上し，クエリの処理速度が速くなる．

## 仮想ウェアハウスの管理

### 作成
以下のコマンドで仮想ウェアハウスを作成できる．

```sql
CREATE WAREHOUSE my_warehouse
  WITH WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE;
```
- `WAREHOUSE_SIZE`: ウェアハウスのサイズ
- `AUTO_SUSPEND`: 非アクティブ状態が続いた場合の自動停止までの時間（秒）
- `AUTO_RESUME`: クエリ実行時に自動的に再開する設定

### スケールアップとダウン
サイズ変更には以下のコマンドを使用する．

```sql
ALTER WAREHOUSE my_warehouse
  SET WAREHOUSE_SIZE = 'MEDIUM';
```

### 停止
ウェアハウスを手動で停止するには以下のコマンドを使用する．

```sql
ALTER WAREHOUSE my_warehouse SUSPEND;
```

### 再開
手動で再開する場合は以下のコマンドを使用する．

```sql
ALTER WAREHOUSE my_warehouse RESUME;
```

## 仮想ウェアハウスの監視
仮想ウェアハウスの使用状況やパフォーマンスを監視するために，Snowflakeの**履歴ビュー**や**クエリプロファイル**を利用することが推奨される．

- **履歴ビュー**: 過去のクエリ実行状況を確認できる．
- **クエリプロファイル**: 各クエリの詳細な実行ステータスを提供する．

## ベストプラクティス
1. 必要最小限のサイズでウェアハウスを作成し，負荷に応じてスケールアップする．
2. 自動停止と再開を有効にして，コストを最小限に抑える．
3. 複数のウェアハウスを利用して，異なるチームやワークロードを分離する．
ゼロから始めるSnowflake（5/10）

# テーブル，データ型，データロード

## 概要
植物の根の深さに関する値を保持するテーブルを作成し，`INSERT`文を使用してデータをロードする．また，`SELECT`文と`LIMIT`句を使用してデータをクエリする方法について学ぶ．


---

## Root Depth テーブルの作成

以下のSQLコードを使用して`ROOT_DEPTH`テーブルを作成する．

```sql
CREATE TABLE IF NOT EXISTS GARDEN_PLANTS.VEGGIES.ROOT_DEPTH (
   ROOT_DEPTH_ID number(1),
   ROOT_DEPTH_CODE text(1),
   ROOT_DEPTH_NAME text(7),
   UNIT_OF_MEASURE text(2),
   RANGE_MIN number(2),
   RANGE_MAX number(2)
);
```

テーブルの作成後，ノートブック画面の左側にある**データベースオブジェクトブラウザ**で，`ROOT_DEPTH`テーブルを確認する．テーブルが見つからない場合
- オブジェクトブラウザまたはブラウザ全体を更新する．
- 実行時のロールやスキーマを確認する．

---

## データの投入
テーブルが作成されたら，以下の方法でデータをロードする．

### `INSERT`文を使用
以下のSQLを実行して，テーブルに1行を挿入する．

```sql
USE SCHEMA GARDEN_PLANTS.VEGGIES;

INSERT INTO ROOT_DEPTH (
    ROOT_DEPTH_ID,
    ROOT_DEPTH_CODE,
    ROOT_DEPTH_NAME,
    UNIT_OF_MEASURE,
    RANGE_MIN,
    RANGE_MAX
)
VALUES (
    1,
    'S',
    'Shallow',
    'cm',
    30,
    45
);
```

挿入後，データプレビュー機能を使用して，テーブルにデータが正しくロードされたことを確認する．

### データプレビュー
1. テーブル詳細画面の**データプレビュータブ**を開く．
2. または，ノートブック左側のオブジェクトブラウザからテーブルを選択し，虫眼鏡アイコンをクリックする．

---

## クエリ実行

### `SELECT *` 文
テーブルのすべての列を取得するには，以下のようにクエリを実行する．

```sql
SELECT *
FROM ROOT_DEPTH;
```

### 列の操作オプション
`SELECT *`文に以下のオプションを付け加えて，出力を調整することができる．

- **EXCLUDE**: 特定の列を除外する．
  ```sql
  SELECT * EXCLUDE (range_min, range_max)
  FROM ROOT_DEPTH;
  ```
- **REPLACE**: 特定の列の値を置き換える．
  ```sql
  SELECT * REPLACE (root_depth_code||'-RDC' AS root_depth_code)
  FROM ROOT_DEPTH;
  ```
- **RENAME**: 列に別名を付ける．
  ```sql
  SELECT * RENAME (range_min AS root_depth_range_min,
                   range_max AS root_depth_range_max)
  FROM ROOT_DEPTH;
  ```
- **ILIKE**: 指定パターンに一致する列を取得する．
  ```sql
  SELECT * ILIKE '%ROOT%'
  FROM ROOT_DEPTH;
  ```

### `LIMIT`句
必要な行数だけを取得する場合は，以下のように`LIMIT`句を使用する．

```sql
SELECT *
FROM ROOT_DEPTH
LIMIT 1;
```

---

### データの追加
以下のSQLを編集して2行追加する．

```sql
INSERT INTO ROOT_DEPTH (
    ROOT_DEPTH_ID,
    ROOT_DEPTH_CODE,
    ROOT_DEPTH_NAME,
    UNIT_OF_MEASURE,
    RANGE_MIN,
    RANGE_MAX
)
VALUES (
    2,
    '#',
    '#',
    '#',
    45,
    60
);

INSERT INTO ROOT_DEPTH (
    ROOT_DEPTH_ID,
    ROOT_DEPTH_CODE,
    ROOT_DEPTH_NAME,
    UNIT_OF_MEASURE,
    RANGE_MIN,
    RANGE_MAX
)
VALUES (
    3,
    '#',
    '#',
    '#',
    60,
    90
);
```

### 結果確認
全データを取得し，以下のクエリを使用して結果を確認する．

```sql
SELECT *
FROM ROOT_DEPTH;
```

---

## エラー修正
エラーが発生した場合は以下を確認する．
1. コンテキストを再設定する．
   ```sql
   USE DATABASE GARDEN_PLANTS;
   USE SCHEMA VEGGIES;
   ```
2. 完全修飾名を使用する．
   ```sql
   SELECT *
   FROM GARDEN_PLANTS.VEGGIES.ROOT_DEPTH;
   ```

---