OmniAICreator/Qiita-1.07M huggingface dataset:
useEffectの基本的な使い方を初心者向けに解説！


# useEffectの基本的な使い方を初心者向けに解説！

## はじめに

React を触り始めたばかりの方にとって、`useEffect` は少し分かりにくいフックの一つかもしれません。  
この記事では、**そもそも useEffect とは何か？** から、**どんな時に使うのか？** まで、初学者向けに丁寧に解説します。

---

## 前提知識

この記事は、以下のような方を対象としています：

- JavaScript の基本文法（`const`, `let`, `関数定義`など）がわかる
- React のコンポーネントを作ったことがある（`useState` を使ったことがある）

---

## useEffect とは？

`useEffect` は、React の **副作用（side effects）** を扱うためのフックです。

副作用とは、以下のような処理のことを指します：

- データの取得（APIリクエスト）
- DOM の直接操作
- ログの出力
- タイマーの設定

```js
import React, { useEffect } from 'react';

useEffect(() => {
  console.log("コンポーネントがマウントされたよ！");
}, []);
```

このコードは、コンポーネントが初めて画面に表示（＝マウント）されたときに、`console.log` が一度だけ実行されます。

---

## 基本構文

```js
useEffect(() => {
  // 実行したい処理
}, [依存配列]);
```

### 依存配列（dependency array）とは？

- `[]`：一度だけ実行（マウント時）
- `[count]`：`count` が変わるたびに実行
- `undefined`（省略）：毎回実行（非推奨）

---

## 例：カウントアプリで useEffect を使う

```js
import React, { useState, useEffect } from 'react';

const Counter = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log(`カウントが ${count} に変わりました`);
  }, [count]);

  return (
    <div>
      <p>{count} 回クリックされました</p>
      <button onClick={() => setCount(count + 1)}>カウントアップ</button>
    </div>
  );
};

export default Counter;
```

この例では、`count` の値が変わるたびに、`useEffect` の中の `console.log` が実行されます。

---

## よくある注意点

- `useEffect` の中で **非同期関数**を直接書くのは NG（関数内で定義して呼び出す）
- **依存配列の漏れ**に注意（使っている変数はすべて書く）
- **クリーンアップ関数**を使えば、アンマウント時の処理もできる

```js
useEffect(() => {
  const timer = setInterval(() => {
    console.log("毎秒実行中...");
  }, 1000);

  return () => {
    clearInterval(timer); // クリーンアップ（アンマウント時）
  };
}, []);
```

---

## まとめ

- `useEffect` は副作用を扱うためのフック
- 依存配列によって「いつ実行されるか」が決まる
- タイマーやAPI通信などに活用される
- クリーンアップ関数で後処理も安全に書ける

---

## 参考リンク

- [React公式ドキュメント（useEffect）](https://ja.reactjs.org/docs/hooks-effect.html)
- [useEffect の使い方とパターンまとめ](https://zenn.dev/)
Git Bash × asdf × Python3.13でインストールを頑張ろうとして沼った話

こんにちは。

[株式会社KANGEN Holdings](https://kangen-holdings.co.jp/)の野中康生です！

#  はじめに

最近、現場で Windows を使うようになりました。これまでの現場ではMacを使っての開発ばかりだったので、Windowsでの開発経験はほぼありません。そしてこれまではPythonのバージョン管理に `asdf` を使ってきており、「**Windows にgit Bash入れているし、同じ感じでやれるっしょ**」と思ってたら…

ハマってしまいました・・・。

今回は、その沼から脱出した内容を備忘録として残しておきます。

## 発端：Python 3.13 を asdf 経由で入れようとした

あるプロジェクトでは`Python3.10系`を使用していて、別プロジェクトでは`Python3.13系`を使用することになったので、Git Bashを使ってasdf経由で`Python 3.13`を導入しようとしていました。

最初は、Git Bash上にasdfをcloneしてきて、インストールみたいな流れでいけるだろうと思ってました。

ところが、asdfコマンドを入れ、パスを通した上で、いざ

```bash
asdf install python 3.13.2
```

を実行するとインストール時に次のようなエラーに直面しました：

```bash
error: implicit declaration of function 'setenv'
```

これはどうやら、Windows環境では setenvが標準で使えないために発生するビルドエラーらしいです。

asdfの公式HPを見ると推奨のパッケージマネージャーにHomebrewに加えて、`Pacman`の記載があったので、

https://asdf-vm.com/ja-jp/guide/getting-started.html


[MSYS2](https://www.msys2.org/)をインストールしました。で以下のようにインストールしました。

```bash
pacman -Sy --noconfirm
pacman -S --noconfirm base-devel mingw-w64-x86_64-toolchain \
  mingw-w64-x86_64-openssl \
  mingw-w64-x86_64-zlib \
  mingw-w64-x86_64-xz \
  mingw-w64-x86_64-bzip2 \
  mingw-w64-x86_64-readline \
  git curl
```

ただし、3.13系をインストール時のエラー内容は変わらずでした・・・。


# 解決策

結局はWindowsにUbuntuを導入し、そこでasdfをインストールしたらすぐに解決できました。

## 1. Ubuntuのインストール & 初期設定

まずはコマンドプロンプトやPowerShellで以下のコマンドを実行し、`Ubuntu`をインストールします。

```bash
wsl --install
```

Ubuntuを起動して、ユーザー名とパスワードを設定します。


## 2. 依存パッケージのインストール

asdfのインストールに必要なパッケージをよしなにインストールします。

```bash
sudo apt update && sudo apt install -y \
  make build-essential libssl-dev zlib1g-dev \
  libbz2-dev libreadline-dev libsqlite3-dev curl \
  libncursesw5-dev xz-utils tk-dev libxml2-dev \
  libxmlsec1-dev libffi-dev liblzma-dev \
  uuid-dev libgdbm-dev libnss3-dev libedit-dev
```

## 3. asdfのインストール

そして、asdfをクローンして、パスを通します。

```bash
# 調べた時点での最新版。ここは適宜バージョンを変えてください。
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.16.7 
echo 'export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH"' >> ~/.bashrc
source ~/.bashrc
```

## 4. asdfからPython3.13系を導入

最後にasdf経由でPython3.13をインストールしました。

```bash
asdf plugin add python
asdf install python 3.13.2
asdf local python 3.13.2
```


```bash
python --version
# => Python 3.13.2
```

無事Windows環境で、asdf経由でPython3.13を導入することができました！

## 最後に

これまでは、Macのbrewコマンドで一発で行けていたので悲しみ・・・。

```
brew install asdf
asdf plugin add python
asdf install python 3.13.2
asdf local python 3.13.2
```
アメリカのQAエンジニア事情まとめ【2025年版】

## アメリカのQAエンジニア事情まとめ【2025年版】

---

### 1. 年収・待遇

- **平均年収**  
  アメリカのQAエンジニアの平均年収は約838万円。大手企業（例：Apple）では1,700万円超のケースもあり、日本の平均（約540万円）と比べて圧倒的に高い水準です。
- **年代別の目安**  
  初級（20代）：約800万～1,000万円  
  中堅（30代）：約1,000万～1,300万円  
  上級（40代～）：約1,200万～1,500万円  
  ※勤務地や企業規模で大きく変動。

---

### 2. 主な業務内容

- テスト計画・設計・実施
- テスト自動化（Selenium等のツール利用）
- バグ報告・品質管理
- テストプロセス改善
- クライアントや開発チームとの調整

---

### 3. 求められるスキルTOP10（2025年）

1. テスト設計・実行力
2. テスト自動化（Selenium, Appiumなど）
3. プログラミング（Python, Java等）
4. CI/CDツール活用
5. 品質保証・管理の知識
6. 問題解決・分析力
7. ドキュメンテーション
8. コミュニケーション（チーム連携・報告）
9. UX/UIの基礎理解
10. 新技術へのキャッチアップ力

---

### 4. アメリカと日本の違い

- アメリカはエンジニアの社会的地位が高く、給与も高い。
- IT＝サービスを生み出す手段という認識が強く、QAにも高いスキルと責任が求められる。
- 日本は「コスト削減のためのIT」という意識が根強く、待遇面で大きな差がある。

---

### 5. キャリアパス・働き方

- QAエンジニア→QAリード→QAマネージャー→QAディレクターと昇進可能。
- リモート・フレックス勤務も一般的。
- 英語圏のQAコミュニティやカンファレンスも活発。

---

### まとめ

アメリカのQAエンジニアは高待遇・高スキルが求められ、キャリアアップや専門性の幅も広い職種。グローバルな環境で活躍したい人には非常に魅力的な選択肢です。

情報源
[1] 2025年版 年収ガイド：テクノロジー（IT） | ロバート・ハーフ https://www.roberthalf.com/jp/ja/insights/salary-guide/technology
[2] ＜プレスリリース＞［世界のITエンジニア給与を独自集計］USドル ... https://note.com/athuman/n/n5cd03ccf06c5
[3] アメリカと日本におけるエンジニアの給与を比較してみた https://engineer-shukatu.jp/column/archives/26529
[4] エンジニアの平均年収は？20代～30代など年代別の相場を解説 https://saiyo.migi-nanameue.co.jp/posts-1/engineer_heikin_nensyu/
[5] QAエンジニアのキャリア形成ってナンダ？ #テスター - Qiita https://qiita.com/simplemon1230/items/525efe5acea26073bea5
[6] アメリカで働くQAエンジニアの現場から - Speaker Deck https://speakerdeck.com/keijiuetsuki/amerikadedong-kuqaenziniafalsexian-chang-kara
[7] 2025年版 年収ガイド：業務改革 | ロバート・ハーフ - Robert Half https://www.roberthalf.com/jp/ja/insights/salary-guide/business-transformation
[8] アメリカで最も高給な15のIT職種 - CIO https://www.cio.com/article/2108302/%E3%82%A2%E3%83%A1%E3%83%AA%E3%82%AB%E3%81%A7%E6%9C%80%E3%82%82%E9%AB%98%E7%B5%A6%E3%81%AA15%E3%81%AEit%E8%81%B7%E7%A8%AE.html
テスト１

# Sakilaデータベースで使える調査系SQLまとめとJOIN準備の基本

Sakilaデータベースを使って、テーブル構造の調査やJOIN設計に役立つSQLをまとめておく。  
JOINを書く前にどのテーブルがどこに接続されているかを確認することで、ミスを減らして設計をスムーズに進められる。

---

## ✅ よく使う調査系SQLコマンド一覧

### 1. テーブル一覧を確認する

```sql
SHOW TABLES;

2. テーブルのカラム構造を確認する

DESCRIBE テーブル名;
-- 例：
DESCRIBE actor;

主キー、データ型、NULL制約などを確認できる。
3. CREATE TABLE の定義を確認する

SHOW CREATE TABLE テーブル名;
-- 例：
SHOW CREATE TABLE payment;

外部キー制約やインデックス、デフォルト値なども含めてすべての定義を確認できる。
4. 外部キーの一覧を確認する（JOIN設計の地図）

SELECT 
  TABLE_NAME, 
  COLUMN_NAME, 
  REFERENCED_TABLE_NAME, 
  REFERENCED_COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE 
  TABLE_SCHEMA = 'sakila'
  AND REFERENCED_TABLE_NAME IS NOT NULL;

どのテーブルがどこを参照しているかを一覧で確認できる。
5. 全テーブル・全カラムの一覧を確認する

SELECT TABLE_NAME, COLUMN_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'sakila';

カラム名のあいまいな記憶を補うのに便利。
6. インデックスを確認する（パフォーマンス対策）

SHOW INDEX FROM テーブル名;

または：

SELECT * FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'sakila';

7. テーブルのレコード数を確認する

SELECT COUNT(*) FROM テーブル名;

テーブルの規模感を知っておくことでJOINのパフォーマンス見積もりにも使える。
🔁 JOINを書く前のチェックリスト

    SHOW TABLES; で全体像を把握する

    DESCRIBE テーブル; で主キーの確認

    SHOW CREATE TABLE で外部キー・制約を確認

    KEY_COLUMN_USAGE でテーブル間のリレーションを一覧で見る

    必要なJOINを書き始める

🧩 CREATE文の中に出てくる構文の意味
CONSTRAINT（制約）

CONSTRAINT `fk_payment_customer`

制約の名前。外部キーやユニーク制約などにつける。
後で削除・変更する際に指定できる。
FOREIGN KEY（外部キー）

FOREIGN KEY (`customer_id`)

このカラムが外部キーであることを宣言する。
REFERENCES（参照先）

REFERENCES `customer` (`customer_id`)

外部キーがどのテーブル・カラムを参照しているかを示す。
組み合わせた構文の例

CONSTRAINT `fk_payment_customer`
  FOREIGN KEY (`customer_id`)
  REFERENCES `customer` (`customer_id`)

    payment.customer_id は外部キー

    参照先は customer.customer_id

    この関係を fk_payment_customer という名前の制約として登録している

🧭 まとめ

JOINを正確に書くためには、リレーションの把握が必須。
特にSakilaのようなリレーションが多いサンプルデータベースでは、外部キーの一覧やCREATE文を確認しながら設計していくのが重要。

JOINに迷ったときは information_schema を使えば、ER図がなくても十分戦える。
Nest.js　その２ appModule.ts

appModule.ts

```typescript
import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { UserModule } from './users/users.module';
import { TypeOrmModule } from '@nestjs/typeorm';
import { AppDataSource } from './config/typeorm.config';
import { TodoModule } from './todos/todos.module';
import { NewsModule } from './news/news.module';

@Module({
  imports: [
    UserModule,
    TodoModule,
    NewsModule,
    TypeOrmModule.forRoot(AppDataSource.options),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}
```
<br><br>
どの機能を組み込むかをまとめている場所

```typescript
@Module({
  imports: [
    UserModule,
    TodoModule,
    NewsModule,
    TypeOrmModule.forRoot(AppDataSource.options),
  ],
```

<br><br>
AppDataSource.options
.options を渡すことで、forRoot() が正しく DB(データベース) に接続してくれる。
```typescript
forRoot(AppDataSource.options),
  ```


<br><br><br>
アプリで使う「コントローラー（Controller）」を指定する。
URL に対応した関数をまとめておく場所
```typescript
 controllers: [AppController],
  ```

<br><br><br>
アプリで使う「サービス（Service）」を指定する
ビジネスロジック（処理の中身）を担当する場所
たとえば、データベースからデータを取ってきたり、計算したり、メールを送ったりする。
```typescript
providers: [AppService],
```

<br><br>
NestJS のアプリは「モジュール」を組み合わせて作っていく。
その中でも一番最初に読み込まれる メインモジュール が AppModule。
NestJS アプリの「メインモジュール（ルートモジュール）」を定義してエクスポートしている。
export をつけることで、他のファイル（main.ts）からも使えるようにしている。
```typescript
export class AppModule {}
```
Django環境構築メモ(venvバージョン)


## Djangoバージョン確認

[Djangoの最新バージョン確認](https://docs.djangoproject.com/ja/5.2/faq/install/#what-python-version-can-i-use-with-django:~:text=%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82-,%E3%81%A9%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%20Python%20%E3%81%A7%20Django%20%E3%81%8C%E4%BD%BF%E3%81%88%E3%81%BE%E3%81%99%E3%81%8B%3F,-%C2%B6)

現時点で最新の5.2を使用（Pythonは3.13.3を使用）

## Pythonバージョン設定

```bash
# イントールできるバージョンの確認
pyenv install --list

# インストール
pyenv install 3.13.3

# インストールされたバージョンの確認
pyenv versions

# バージョンの指定
# システム全体
pyenv global 3.13.3

```

## プロジェクトディレクトリ作成 & Python仮想環境作成

```bash
# プロジェクトディレクトリ作成、移動
mkdir django-project && cd django-project

# Python仮想環境作成
python -m venv .venv

# 仮想環境活性化
source .venv/bin/activate

# 仮想環境化確認
which python
```

## Djangoインストール

```bash
# pip 準備
python -m pip install --upgrade pip
python -m pip --version

# Django インストール
python -m pip install django

# Django のバージョン確認（インストールできたか確認）
python -m django --version
```

## Djangoアプリ作成 & 開発サーバー起動

```bash
python -m django startproject mysite .

python manage.py runserver
```

`http://127.0.0.1:8000/`にブラウザでアクセス

![スクリーンショット 2025-04-17 22.29.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2520235/d2186b24-a6bd-4faa-b019-b69476cb2da3.png)

**Done!!**
メモ：ollamaをローカルにインストールしてみた

インストールなどは下記URLをかくｎ
https://qiita.com/misu007/items/4d629957a2099abe875b
https://rabiloo.co.jp/blog/run-llm-on-local

Misral:7Bをpull

ollamaで利用できるローカルLLMのリスト
https://ollama.com/library
【マジで草】はてブ炎上して学んだこと！新人向けQiita記事を書いたら叩かれた話

ギャルエンジニアの日記

![1000006406.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3571614/91cdcab0-ce00-468f-8885-a13a6375a800.jpeg)


## 1. なんか知らんけどQiita記事、バズってたんだけど！？  

え、なにこれ。  
2024年の12月に書いたQiitaの記事がさ、  
**はてブのトレンド入りしてたんだけど！？えぐっ！**

[これがその記事！](https://qiita.com/nozawanatsu/items/e5e576d08663dffc4250)  
[はてブの様子も見て！](https://b.hatena.ne.jp/entry/s/qiita.com/nozawanatsu/items/e5e576d08663dffc4250)

まじでビビった。  
いつものノリで書いただけだったのに、なんかの拍子に火ついたらしい。

## 2. でもコメント欄、地獄すぎてメンタル死んだわ〜

でさ、調子のってコメント欄見に行ったの。  
**もうね、地獄。激萎え。心がドロドロに溶けた。**

「これって情シス…？」とか  
「情シスならこのリンクはいるっしょ」とか  
マジで陰湿。ネチネチ。ヒリヒリ。なんなん？

いやさ、傷つくとか以前に、  
**「ヒマかよ！？もっと楽しいことしよ？」って言いたい。**

## 3. てか、文句言ってるそこのアナタ、なんか投稿してるん？

いやマジで思ったんだけどさ、  
そうやってネチネチしてる人って、  
**自分ではなんか発信してんの？？？**

こっちは勇気出して記事書いてんだよ。  
慣れないMarkdownとかタグとか使ってさ〜。  
陰口叩くヒマあったら、アウトプットしよ？な？

## 4. 私が書いたのは、新人ちゃんたち向けっしょ！！

あの記事ね、ベテランさん向けとかじゃないから〜！  
**IT入社したての「え？右も左もわかんないです…」って子たち向けね！？**

新人ってまじで、何調べればいいかすらわかんないんだよね。  
情報多すぎだし、業界用語のカタカナ爆弾で脳ミソふっとぶ。  
だからこそ、ちょっとしたキーワードとか事例で  
「へ〜！ITってこういうことあるんだ〜！」って興味持てるキッカケを作りたかっただけ。

## 5. てかさ、IT業界、ネチネチ多すぎじゃね？

ごめんこれ、あくまで**個人の感想です**ってことで聞いてほしいんだけどさ、  
**ITってネチネチ率高すぎじゃね！？！？**

知識マウント大会すぎるのよ。  
「え〜？そんなのも知らないんだ？」って、  
あんた誰目線なん？って聞きたくなるやつ多すぎ。

もっとさ、「一緒に覚えてこ〜！」みたいな雰囲気になってくれ！頼む！！

## 6. 結論：ウダウダ言ってる人の声、スルーでよくね？

てことで、結論っていうか、私のスタンスはこれ。

**ごちゃごちゃ言ってくる人、無視でヨシ！！**

気にせず、**自分のペースで楽しく学んで、発信しよ！**  
アウトプットは最高のインプットだし、  
自分の成長が何より大事っしょ！

だから、この記事も気に入ってくれたらうれしいし、  
文句ある人は、知らん！笑  
**私はこれからも、ゆるっと記事書いていくからヨロシク〜！！**
Amazon SESについての備忘録(ルールセットの運用などについて ちょびっとだけ...)

ノベルワークスのとっしー([@tossy](https://x.com/A1vbzr4SVP8))です.
AWS SESについて気になったことについて, 調べたり教えていただいたりしたので, 備忘録として残しておきます.

### リージョン内で複数のドメインを運用は問題ないのか
 > 1リージョンにつき, ルールセットを1つのみ有効にできる.
 このルールセットに対して, 各ドメインごとの複数ルールを作成するという運用を考えていた.
このような運用は実務上よく採用される方法なのか.

この方法はよく採用される方法らしく問題ないようです.
いくつか注意する点があります.

 - ルールは順番に評価されること気を付けること
 - ドメインが増えるとルールセットが複雑になり, 管理が難しくなること
 - 特定のメールが複数のルールに一致する場合, 不要な処理をしたくない場合は[停止アクション](https://docs.aws.amazon.com/ja_jp/ses/latest/dg/receiving-email-action-stop.html)を使用して以降のルールの評価を中止すること 
(オプションで, 停止アクションが実行されたときにAmazon SNSを通じて通知を飛ばせるようです)

### ルールセットを複数作成する際のユースケースについて

> SESでは1リージョン内に複数のルールセットを作成できるが, 有効化できるのは1つのみ.
どのようなユースケースで複数ルールセットを利用するのか.

複数ルールセットを作成する主なユースケースは以下のようなものがあるようです.

 - ルールセットを簡単に切り替えたい場合
     - 過去のルールセットをバックアップとして保持しておき, 必要に応じて切り替えることができます. また, 新しいルールセットを事前に作成しておけば, 任意のタイミングで迅速に切り替えることもできます
     - 例) テスト環境と本番環境の分離
     　異なるルールセットを使用してテスト環境と本番環境を切り替えることで, 新しい設定や機能を簡単に試すことができます

 - 異なるワークフローへの対応
     - 特定期間や特定プロジェクト向けに異なるメール処理フローを設定できます
     - 例) 年末年始のキャンペーンで, 特定のメールを受信した場合に特別な処理を実行
    → キャンペーン期間中は受信メールをS3に保存してアーカイブなど
Flutter 多言語化対応備忘録

# Flutterでアプリを多言語対応させる：非エンジニアでも編集しやすいarbファイルを使う

以前は `localizationRiverPod` で自作ローカライズをしていましたが、Flutter公式の方式に移行した際の手順をまとめました。

---

##  今回やりたいこと

- Flutterアプリを日本語などの多言語に対応させる
- `.arb` ファイルを使って、翻訳をわかりやすく管理（JSONライクな形式）⭐️誰でも編集しやすい
- Flutterウィジェット（Material, Cupertino, Widgets）の標準翻訳も有効化

---

## 🧱 セットアップ手順

以下の通りに進める

https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization#advanced-topics-for-further-customization

---

### 1. パッケージの追加

```bash
flutter pub add flutter_localizations --sdk=flutter
flutter pub add intl
```

---

### 2. MaterialAppにローカライズ設定を追加

```
return MaterialApp(
  title: 'Localizations Sample App',
  localizationsDelegates: [
    // ⭐️自作ローカライズもここに追加予定
    // 追記
    GlobalMaterialLocalizations.delegate,
    GlobalWidgetsLocalizations.delegate,
    GlobalCupertinoLocalizations.delegate,
  ],
  supportedLocales: [
    Locale('ja'), // 対応する言語を追加
  ],
);

```


#### `GlobalMaterialLocalizations.delegate`

Material Design 系のウィジェット（例：`AppBar`, `DatePicker`, `Dialog` など）に使われている文言を、自動的に翻訳してくれます。

---

#### `GlobalWidgetsLocalizations.delegate`

ウィジェットのテキストの方向（左→右 / 右→左）などの制御をしてくれる翻訳です。

---

#### `GlobalCupertinoLocalizations.delegate`

iOSスタイル（Cupertino系）のウィジェット（例：`CupertinoAlertDialog`, `CupertinoDatePicker`）に含まれる文言を翻訳してくれます。
   
### 3.
1で追加したintlライブラリによる自動生成を有効化する
``` pubspec.yaml
flutter:
    generate: true
```

### 4.
ルートディレクトリにl10n.yamlを作成する

```

# arbファイル（翻訳ファイル）を置くディレクトリ
# デフォルトはlib/l10n
arb-dir: lib/l10n

# 基準となるarbファイル（自動生成するファイルの元になる言語ファイル）
# デフォルトはapp_en.arb 
template-arb-file: app_ja.arb

# 自動生成されるDartファイルのファイル名
output-localization-file: app_localizations.dart

# 自動生成されたDartファイルの出力先ディレクトリ
output-dir: lib/localization/generated

# falseにすると 自動生成されたファイルが↑のディレクトリに出力される。
# 中身の確認がスムーズなのでfalseにしておく
synthetic-package: false

```

### 5.　.arbファイルを作成

```app_ja.arb
{
  "animal": "動物",

  "greet": "こんにちは{name}です",
  "@greet": {
    "description": "昼間の挨拶を表示します。{name}はユーザーの名前です。",
    "placeholders": {
      "name": {
        "type": "String",
        "example": "太郎"
      }
    }
  }
}

```
⚠️ 末尾に,を書かないとエラーになるので注意

**example**や**description**を記入しておけば、このテキストがアプリのどの部分に表示されるかを知らなくてもニュアンスが伝わりやすい。

**flutter gen-l10n**でコードが自動生成される
flutter pub getでもOKだけど、ローカライズ周りだけを更新するgen-l10nの方が実行が早い

あとは、一行入力するたびにターミナルで実行でOK
「これ、当たり前すぎる...」と思ったら逆に書くべき理由 - エンジニアの共感が記事の本当の価値

## はじめに

「既に誰かが書いているかも...」
「これって当たり前すぎるかな...」
「この内容じゃ価値がないんじゃ...」

Qiitaに投稿しようとするとき、こんな不安に駆られたことはありませんか？私は何度もあります。記事を書こうとエディタを開いた瞬間、「この内容は他の人が既に書いているかも」という思いが湧き上がり、書く前から諦めてしまう...。そんな経験をした方も多いのではないでしょうか。

実はこれ、多くのエンジニアが抱える共通の悩みなのです。今日はこの「新規性へのこだわり」について考えてみたいと思います。

## 新規性にこだわる理由

なぜ私たちは「誰も書いていないこと」「新しい発見」にこだわってしまうのでしょうか。その理由はいくつか考えられます：

1. **自己価値の証明**: 新しいことを発見・発信することで自分の価値を示したい
2. **他者との差別化**: 既に語り尽くされた感のある話題では埋もれてしまう不安
3. **「車輪の再発明」への批判**: エンジニア文化における重複作業への批判精神
4. **「いいね」や評価への期待**: 新規性のある記事の方が注目されるという思い込み

確かに新規性は価値の一つです。しかし、それが**唯一の価値**でないことを忘れてはいけません。

## 共感こそが真の価値

技術記事の本当の価値は何でしょうか？それは「誰かの役に立つこと」「誰かの共感を得ること」ではないでしょうか。

例えば、「Git入門」や「Docker基礎」といったテーマは、既に何百もの記事が存在します。しかし、そんな中でもあなたの記事が「あ、これなら分かる！」と誰かの心に響くことがあるのです。

なぜなら：

1. **人はそれぞれ異なる理解の仕方をする**: あなたの説明がピタッとハマる人がいる
2. **経験と文脈が異なる**: あなたが遭遇した特定の問題と解決法は、同じ問題に直面している誰かの助けになる
3. **時間の経過による変化**: 1年前の記事より、最新の環境に基づいた記事が欲しい人もいる
4. **共感による安心感**: 「自分だけじゃないんだ」という気持ちが大きな励みになる

## 「当たり前」を疑う

「これって当たり前すぎるかな...」と思うことでも、実はそうではないケースが多々あります。

エンジニアとして成長すると「当たり前」だと思うことが増えていきますが、それは単に「あなたが既に学んだこと」に過ぎません。今日あなたにとって当たり前のことは、昨日のあなたにとっては新鮮な学びだったはずです。

思い出してみてください：
- 初めてGitのconflictを解決できたときの喜び
- 初めてDockerで環境構築がスムーズにいったときの達成感
- バグの原因がやっと分かったときのスッキリ感

これらの経験と感情を共有することは、同じ道を歩む人にとって大きな励みになります。

## 共感を生む記事の書き方

では、新規性よりも共感を重視した記事はどう書けばいいのでしょうか？

1. **自分の躓いたポイントを正直に書く**: 「ここで3時間ハマりました」という告白が、同じ問題に直面している人の救いになります

2. **感情を込める**: 「このコマンドを実行するとき、毎回緊張します」といった感情の機微が共感を生みます

3. **具体的な文脈を提供する**: 「文系卒未経験エンジニアとして、本当にやれるのか不安だった私は...」といった背景があると読者は自分と重ね合わせやすくなります

4. **失敗談を惜しみなく共有する**: 成功事例より失敗談の方が学びが大きいことも多いです

5. **質問形式を取り入れる**: 「皆さんはこんな経験ありませんか？」と問いかけることで読者の共感を引き出せます

## 実例：共感を得た「当たり前」の記事

実際にQiitaで人気を集めた記事の中には、特に新規性はなくても多くの共感を得たものがあります：

- Git操作の失敗談と回復方法
- デバッグ時の思考プロセスの共有
- リファクタリングで気づいた単純だけど効果的なプラクティス
- 新人エンジニアが陥りがちな罠とその対処法
- レガシーコードとの向き合い方

これらはいずれも「新しい技術」や「誰も知らない裏技」ではなく、多くのエンジニアが経験する普遍的な悩みと解決策です。それでも（あるいは、だからこそ）多くの共感を呼び、価値ある記事となっています。

## 「誰かの役に立つ」という視点

記事を書く際に意識してほしいのは「誰かの役に立つ」という視点です。

私が昔書いた「初めてのJavaScript非同期処理」という記事は、正直なところPromiseやasync/awaitについての基本的な内容で新規性は皆無でした。しかし、ある日突然コメントが届きました：

「この記事のおかげで、3日間悩んでいた問題が解決しました。本当にありがとうございます！」

この一言が、私の記事執筆のモチベーションを大きく変えました。新規性よりも「誰かの役に立つこと」に価値があると実感したのです。

## まとめ：あなたの経験こそがかけがえのない価値

結局のところ、あなたにしか書けない記事があります。それは、あなた自身の経験、感情、文脈を含んだ記事です。

同じ技術トピックでも、あなたの目線から見た景色は他の誰とも違います。その独自性こそが、新規性よりも大切な価値なのです。

だから、こう言いたいと思います：

**「新規性に拘る必要はない！！」**

大事なのは、あなたの言葉で、あなたの経験を、あなたの感情とともに伝えること。そうすれば、必ず誰かの共感を得られるはずです。

今日からは「これ、書くべきかな？」と迷ったら、「誰かの役に立つか？誰かが共感するか？」という基準で考えてみてください。そして、少しでも「Yes」と思えたら、迷わず書いてみましょう。

あなたの記事が、誰かの助けになりますように。

## さいごに

この記事も「新規性はない」と言われればそうかもしれません。「記事を書く勇気」について語った先人は数多くいます。

しかし、この記事を読んで「そうそう、自分もいつもそう思ってた！」と思ってくれる方がいたら、それだけで私の目的は達成されたことになります。

あなたのその経験、その知識、その感情を、ぜひ記事にしてください。誰かがきっと、あなたの言葉を待っています。

---

この記事があなたの背中を押す一助になれば幸いです。共感していただけましたか？ぜひコメント欄でお聞かせください。そして、あなたが「書くべきか迷っていた記事」について教えてください。きっと「書くべき！」と背中を押してあげられると思います。
「(向聴数) = 8 - (面子の数)×２ - (面子候補の数)」という向聴数計算アルゴリズム（笑）は間違っています

計算機上で向聴数を計算するアルゴリズムとして「(向聴数) = 8 - (面子の数)×２ - (面子候補の数)」という式を計算するものが紹介されることがあります．しかしながら，この計算アルゴリズムは端的に言って間違っています．tomohxx氏の記事「[ブロック分解方式向聴数計算アルゴリズムの精度の検証](https://zenn.dev/tomohxx/articles/aecace4e3a3bc1)」では，この計算式がコーナーケースで（ごく一般的な麻雀のルールにおける）向聴数とは異なった数値を返すということを指摘するだけでなく，向聴数と異なる数値を返す牌姿のケースの総数を数え上げ，さらには向聴数と異なる数値を返す牌姿のケースを分類するという大偉業を成し遂げています．

この「(向聴数) = 8 - (面子の数)×２ - (面子候補の数)」という計算は，向聴数と異なる数値を返すケースが牌姿全体の総数と比べて著しく少ない（上記tomohxx氏の記事を参照すること）ため，この計算が速度上の利点を持つならば近似アルゴリズムとしての意義もあります[^1]．しかしながら，現状における最速クラスの向聴数計算アルゴリズム[^2]と比較しても特にそういうことはありません．したがって，近似アルゴリズムとしての意義も無く，単に間違っていると断じても現状では問題ないと思われます．

しかしながら，この間違ったアルゴリズムが現状はびこっています．例えば，向聴数計算アルゴリズムとしてしばしば参照される「[あらの（一人）麻雀研究所](https://mahjong.ara.black/)」が[この計算式で向聴数を計算できる](https://mahjong.ara.black/etc/shanten/index.htm)としています．また，向聴数計算アルゴリズムの実装として世界で最も広く利用されている [Python の mahjong パッケージ](https://github.com/MahjongRepository/mahjong)の向聴数計算もこのアルゴリズムであるため，[特定の牌姿に対して向聴数でない数値を返します](https://github.com/MahjongRepository/mahjong/issues/43)．学術論文においてこの計算式を向聴数計算アルゴリズムとして言及するものも散見されます[^3]．

では，現状として，（各ルールにおいて）正しく向聴数を計算するアルゴリズムはどれを用いれば良いのかというと，筆者が知る限り以下の3つが挙げられます：

- [天鳳牌理](https://tenhou.net/2/)のアルゴリズム（これまで ad-hoc なアルゴリズムだと考えられていたが，上記のtomohxx氏の記事により正しいことが間接に証明された），
- [枝刈り DFS](https://tomohxx.github.io/mahjong-algorithm-book/dfs/)，
- [01-BFS によるもの](https://habara-k.hatenadiary.jp/entry/2021/06/09/181140)．

以上により，今後，計算機上で向聴数を計算する場合は，特定のケースで向聴数と異なる数値を返し，速度上の利点も特に無い，この「(向聴数) = 8 - (面子の数)×２ - (面子候補の数)」という計算アルゴリズムを採用することは避けたほうが良いと考えます．

[^1]: 計算機上における向聴数計算ではなく人間による向聴数計算の場合，この計算式の簡易性から存在意義は依然としてあると考えられます．
[^2]: 例えば https://github.com/tomohxx/shanten-number, https://github.com/Cryolite/nyanten, https://github.com/Apricot-S/xiangting
[^3]: 例えば https://ipsj.ixsq.nii.ac.jp/records/145803 や https://www.jstage.jst.go.jp/article/jsaikbs/124/0/124_28/_article/-char/ja/
【完全ガイド】DatabuttonのFirestoreインテグレーション

---

## 🔥 Firestoreとは？

FirestoreはGoogle Cloudが提供するNoSQLドキュメント型データベースです。以下のような特徴を持ちます：

- スキーマレスなデータ構造（JSON形式）
- ドキュメント/コレクション階層で直感的に管理可能
- リアルタイム同期と自動オフライン対応
- 高いスケーラビリティとセキュリティ（Firebase Authenticationと統合可能）

---

## 🧩 Databutton × Firestoreの魅力

Databuttonでは、Firestoreをバックエンドとして使うことで以下のような使い方が可能になります：

- ユーザー入力データの保存
- AIアプリのチャットログ記録
- JSON構造の設定情報管理
- UIフォームとリアルタイム連携

---

## 🚀 インテグレーション手順

### ① Firestoreの準備

1. [Firebase Console](https://console.firebase.google.com/) でプロジェクトを作成  
2. 「Cloud Firestore」を有効化  
3. サービスアカウントキーを作成し、Databuttonの **Secrets** に以下のように登録：

```json
{
  "FIREBASE_PROJECT_ID": "your-project-id",
  "FIREBASE_PRIVATE_KEY": "-----BEGIN PRIVATE KEY-----\\n...",
  "FIREBASE_CLIENT_EMAIL": "firebase-adminsdk@your-project-id.iam.gserviceaccount.com"
}



⸻

② DatabuttonでのFirestore操作

Databuttonでは、以下のようにシンプルなコードでFirestoreにアクセスできます。

🔸 データ追加

from databutton.firestore import collection

collection("users").add({
    "name": "Taro",
    "email": "taro@example.com"
})

🔸 データ取得

users = collection("users").get()

for user in users:
    print(user["name"])

🔸 データ更新

collection("users").document("user_id").update({
    "email": "new@example.com"
})

🔸 データ削除

collection("users").document("user_id").delete()

```

⸻

💡 実用ユースケース
	•	アンケートフォームの結果をFirestoreに保存
	•	AIチャットの履歴をドキュメント化
	•	アプリ設定情報をJSONで動的に管理
	•	管理者ページからリアルタイムで投稿を編集

⸻

✅ まとめ

DatabuttonとFirestoreを組み合わせることで、複雑なバックエンド開発なしにデータ永続化とリアルタイム性を持ったアプリケーションが構築できます。

ノーコードで始めたいが、データはちゃんと扱いたい。そんな開発者にとって、Firestore連携は最適な選択肢です。

⸻


📎 関連リンク：
- [Databutton公式サイト](https://databutton.com?via=takahiro19)
- [firestore ドキュメント](https://firebase.google.com/docs/firestore?hl=ja)
- https://ronbun-ai.org
【Go】ARPパケットを作成

ネットワークがかなり苦手なので、ネットワークの理解のため、Go言語で、ARPパケットを作成してみました.
以下の手順で行いました.
 1. sudo apt install arping
 2. sudo ip -s -s neigh flush all
 3. sudo tcpdump net 192.168.56.0/24 -w arping.pcapng
 4. sudo arping 192.168.56.111 -c 1
 5. mkdir arp-go
 6. go mod init arp-go
 7. go get github.com/google/gopacket
 8. vim main.go
 9. sudo ip -s -s neigh flush all
10. sudo tcpdump net 192.168.56.0/24 -w arp-go.pcapng
11. sudo env "PATH=$PATH" go run main.go

# ScreenShot
左がarpingのパケットキャプチャで、右がGo言語のパケットキャプチャです.

Request
![スクリーンショット 2025-04-17 212406.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/498946/559fcc9d-709f-42e1-bf89-e5759c33b152.png)
Reply
![スクリーンショット 2025-04-17 212432.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/498946/8cac2d9b-e609-4cef-9b9a-1a200af3a886.png)

# GitHub
https://gist.github.com/mniyk/1d98c6b037f5ecb1453bcc8222dd1c5f
Growiにチャレンジしてみた

:::note warn
注意：この記事はQiita初心者が書いた記事です。
:::

# やってみたかったこと<br><br>Growi構築 
# やり方
構成 
```
OS Ubuntu Server
CPU 8C8T
RAM 8.00GiB
Disk 64.00GiB
```
といった感じです。
手順

## 1.まず、以下のコマンドを打ってMongodbを立てましょう。
```
docker run -d --name mongodb -p 27017:27017 mongo:latest
```
これで、MongoDBがポート27017で起動します。

:::note info
Dockerがない場合はインストールして下さい。
:::
<details><summary>インストール方法</summary>
sudo apt update && sudo apt install docker.io

以上！（）
</details>

## 2. 次に、Growiのインストールです

インストールはこのコマンドです。
```
docker run -d -p 80:3000 --name growi \
  -e MONGO_URI=mongodb://mongodb:27017/growi \
  -e APP_PORT=3000 \
  growi/growi
```
このコマンドでは、以下のことが行われます：

mongodb://mongodb:27017/growi はMongoDBのコンテナを参照しています（同じネットワーク内でコンテナ名を使用）。

APP_PORT=3000 でGrowiのポートを3000に設定します。

-p 80:3000 でホストのポート80をコンテナの3000ポートにマッピングします。

これで、GrowiがDockerコンテナ内で動作し、ポート80でアクセスできるようになります。
## 3.アクセス
以上で構築は終了です！
![setup.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3943123/6d7936d4-467d-4add-bb63-8d179e2dbdaf.png)
この様の画面になれば構築成功です！
ここでユーザー登録すればあとはもうご自由にお使いいただけます！

:::note alert
ユーザー登録後、ユーザーIDは変更できません
:::
### なんでタグにProxmoxがあるの？
実は、Uniproject(https://uniproject.jp) 様のProxmoxサーバーを使っているんです！
なんでProxmoxタグが付いております
StarDistをDockerで動かす

### Stardist GPU環境をDockerで構築する（Ubuntu + TensorFlow + Jupyter + StarDist）

環境：
- Ubuntu 20.04 LTS
- NVIDIA RTX 4000 SFF Ada
- NVIDIA Container Toolkitインストール済
- Docker, Docker Composeインストール済

---

## Dockerfile
```Dockerfile
# Use TensorFlow 2.10.1 GPU Jupyter image as base
FROM tensorflow/tensorflow:2.10.1-gpu-jupyter

# Ensure root privileges
USER root

# System updates and tools
RUN apt-get update && \
    apt-get install -y sudo gosu && \
    rm -rf /var/lib/apt/lists/*

# Upgrade pip
RUN pip3 install --upgrade pip

# Install Python packages
RUN pip3 install \
    "numpy<2" \
    "stardist[tf2]" \
    gputools==0.2.15 \
    EDT \
    reikna==0.8.0 \
    numba \
    jupyterlab

# Setup working directory and symlinks
RUN mkdir -p /notebooks && \
    ln -s /data /notebooks/data && \
    ln -s /tf/tensorflow-tutorials /notebooks/tensorflow-tutorials

# Copy helper script
COPY createuser.sh /usr/bin/createuser.sh
RUN chmod +x /usr/bin/createuser.sh

# Expose port for Jupyter Lab
EXPOSE 8888

# Use custom user creation script as entrypoint
ENTRYPOINT ["/usr/bin/createuser.sh"]

# Default command
CMD ["jupyter", "lab", "--ip=0.0.0.0", "--notebook-dir=/notebooks", "--no-browser", "--allow-root"]
```

---

## docker-compose.yml
```yaml
version: '3.8'
services:
  stardist:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: stardist_container
    runtime: nvidia
    environment:
      - USER_NAME=dockeruser
      - GROUP_NAME=dockeruser
      - USER_ID=1000
      - GROUP_ID=1000
      - USER_PASSWORD=yourpassword
      - ROOT_PASSWORD=yourrootpassword
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,utility
    volumes:
      - /home/youruser/Data:/data
    ports:
      - "8777:8888" #自分の環境では8888がもう使われているので。
    tty: true
```

---

## createuser.sh
```bash
#!/bin/bash
USER_NAME=${USER_NAME:-dockeruser}
GROUP_NAME=${GROUP_NAME:-dockeruser}
USER_ID=${USER_ID:-1000}
GROUP_ID=${GROUP_ID:-1000}
USER_PASSWORD=${USER_PASSWORD:-password}
ROOT_PASSWORD=${ROOT_PASSWORD:-rootpassword}

# Group setup
if ! getent group "$GROUP_NAME" >/dev/null 2>&1; then
  groupadd -g "$GROUP_ID" "$GROUP_NAME"
fi

# User setup
if ! id -u "$USER_NAME" >/dev/null 2>&1; then
  useradd -m -s /bin/bash -u "$USER_ID" -g "$GROUP_NAME" "$USER_NAME"
  echo "$USER_NAME:$USER_PASSWORD" | chpasswd
  usermod -aG sudo "$USER_NAME"
fi

echo "root:$ROOT_PASSWORD" | chpasswd

# Drop privileges to created user
exec gosu "$USER_NAME" "$@"
```

---

## entrypoint.sh
```bash
#!/bin/bash
# Print the URL to access Jupyter Lab
echo "Access Jupyter notebook at http://localhost:8888 (or http://<your_docker_host>:8888 if accessing from another machine)"

# Start Jupyter Lab
exec jupyter lab --ip=0.0.0.0 --no-browser --allow-root
```

---

これを `Stardist` ディレクトリにおいて`docker compose up --build -d`

💡 `createuser.sh`と`entrypoint.sh`は、「rootでログインするのがなんとなく嫌」「ボリュームマウントをミスなく行いたい」という目的でおまじない的に入れています。
💡`notebooks`ディレクトリを作っておかないとJupyter Labを立ち上げたときにマウントしたボリュームが見えないです。

参考：
https://forum.image.sc/t/difficulty-installing-stardist-tensorflow-gputools-with-anaconda/104305/15
調子に乗っていました

最近は、生のJavaScriptを沢山書いてます。

やっぱりTypeScriptとかReactって流行っててなんだかカッコいいじゃないですか。
まあ、頑張れば書けるし読めるしっていうぐらいには分かるんですけど、明らかに自分のレベルに合っていない！！（以前作成していたアプリも断念していまいました(T_T)頭の中の考えをコードに落とし込めていない）

以前、お世話になっていた会社のエンジニアの方と話していて、まずJavaScriptの基本をしっかり抑えてから次の道具を使うようにしなさい、といった事を指摘頂きました。
そうだよな、と思い、しっかりJavaScriptを最近は書いています。
楽しいね、、、無理しなくっていいんや。
とりあえず、JavaScriptを頑張って書いて余裕できてきたら、他のに移るって感じでやります。
PhpStorm 2025.1 Local Changes + Modal を復活させる

1. (Pluginに[Git Modal Commit Interface](https://plugins.jetbrains.com/plugin/26647-git-modal-commit-interface) が入ってなかったらインストールする)
1. `Settings` → `Advanced Settings` → (`modal commit`で絞り込み)
1. `Use modal commit interface` のチェックを入れる

![スクリーンショット 2025-04-17 16.09.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281147/2285bdc2-5471-42b6-8652-ccfd2a65249d.png)

https://www.jetbrains.com/ja-jp/phpstorm/whatsnew/
ITサービスマネージャー 試験　令和6年　問1　解説


# R6　問1　サービスの予算業務及び会計業務

【解説】
クラウドサービスの利用が進む中、クラウドサービスの利用体系と特徴を踏まえた予算化や、予算と実際に発生する費用の管理が重要になっている。除法系サービスのクラウドサービスへの移行計画を通して、予算と費用実績管理を実施する能力を問う出題である。


>設問1【Rクラウド利用料の見積り】について答えよ。なお、計算の最終結果で小数が発生する場合は、小数第一位を四捨五入し、答えは整数で求めよ。
（1）本文中の（a）に入れる適切な数値を答えよ。ここで、情報系サービスにおける1年間の平日は260日とする。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1186920/937f907c-93db-442c-8f0e-4bea00f70722.png)

表1より、情報系サービスの利用時間は「平日の6時から21時まで」とあるので1日15時間となる。260日稼働するため、15（h）×260（日）＝3,900

**3,900**
***

>(2)本文中の（b）に入れる表3中の価格モデルの記号➀又は➁を答えよ。

1台あたりの料金を求めて比較すれば良い。
➀従量制料金：3,900×100＝390,000
➁使用量予約：（100×24×365）×0.75=65.7000

空欄（b）には、**➀**

>(3)表4中の空欄（c）に入れる適切な数値を求めよ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1186920/dcfbebe9-c823-4b1a-993b-51778428c42e.png)

- 表1から2023年4月時点での情報系サービスが利用されている利用料は、「100TB」
- また、2024年期初に2023年期初に比べて20％の容量・能力増加が必要」と示されているため、2024年度のストレージは120TBであることが分かる。

120TB＝120,000GB
120,000÷10GB×0.75×1ヶ月＝10,800,000円となる。
よってく空欄cには、**10,800**

***

>設問２【サービス事業本部への費用の提示】について
（1）本文中の下線（ア）についいて、ITサービスの需要見込みに対する実績の差異を確認する観点で報告すべきリソース実績は何か。30字以内で答えよ。

本文中の下線（ア）は、「新たに割り当てる直接費についても関連するリソース実績をT事業部に報告することにした」とある。新たに割り当てる直接費とは、情報系クラウドのサーバとストレージの使用料のことである。
よって、回答としては、**Rクラウドのサーバとストレージの使用量（19字）**


>（2）本文中の下線（イ）について、指摘された問題の内容を、30字以内で答えよ。

本文中の下線（イ）は、「現在の間接費の配賦の方法では問題がある」との指摘について考える。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1186920/5fdf2d89-ecef-42a7-83dc-040aa75027fa.png)

黄色マーカー部分よりRクラウドへ移行後もT事業部としては、DCを利用していないにも関わらず、DC使用料の課金を請求される点が問題である。よって、回答としては、**DCを利用しないT事業部にもクラウド移行後もDC使用料を間接費として配賦すること**

***
>本文中の下線（ウ）予算管理上のリスクを、35字以内で答えよ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1186920/ac1b73ff-193d-4f4c-90b6-8e3240dc9356.png)

黄色マーカ部分より、今後Rリソースを拡張する可能性があることが分かる。
Rクラウドでは、リソースの拡張によって使用料が増加するため、当初の予算計画より実績が超過してしまう可能性がある。したがって**急増する需要に対してリソースを拡張し、予算を超過する**

>（2）本文中の下線（エ）について、予算管理者として検討すべき対策を40字以内で答えよ。

ITサービスマネージャとしては利害関係者と合意を得ることが重要。また、事業部門の立場としては、リソース拡張のための費用を念頭にキャンペーンを立案することになるが、予算超過する場合はそれを承認するプロセスが必要である。

よって、回答としては、**予算を超過して費用支出する場合の承認手順を作り、利害関係者者と合意する**
【NestJS】ワイのNestJSにTimezoneを設定できない件について

## 導入
NestJSを使用して個人開発を進めています。
ある日、レスポンスの確認をしている最中にこのように思いました。
「日本時間じゃないのウザいな」
<img width='70%' src='https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3566879/78266f71-a33f-4dab-8ca7-b56c144360ea.png'>
※updated_at, created_atカラムです。

緊急でもなく、重要でもないですが、息抜きがてら触ってみることに。
ということで、timezoneを設定しようと考えた次第です。
自分は今までLaravelを多く使用してきました。
Laravelでは、非常に簡単にtimezoneを設定できます。
そのため、すぐ設定し終わるだろうと思っていました。
だがまさかできないとは！
そんなフレームワークあるのかとまで思いました。
NestJSにtimezoneを設定する機能はなく、プログラムに時間操作を実装するしかないようです。
バッチ処理なんかはダルそうですね。
「それでも！NestJSの可能性を、俺は信じたい！」
（ガンダムUC、パチンカスなら分かる）

## とりあえず取り組んでみたこと
### データベースのtimezone
NestJSのtimezoneは一旦諦めて、データベースのtimezoneに注目してみました。
ちなみにPostgreSQLです。
以下のコマンドでログイン後、timezoneのセッティング
```
psql -U ユーザ名 -d データベース名

SET timezone TO 'Asia/Tokyo';
```

timezoneの変更後も改善されませんでした。
どうやらデータベースのtimezoneは原因ではないようです。
### ORMのtimezone
ORMによる影響も考えました。
なぜなら、.schema.prismaというファイルでテーブル仕様を定義するためです。
ちなみに、Prismaはこの.schema.prismaを読み込んで、すべてを実行するSQLを作り、実行します
updated_at, created_atは以下のように定義しています。
```
    updated_at          DateTime      @default(now())
    created_at          DateTime      @default(now())
```
2カラムだけを載せています。
`DateTime`は型、`@default(now())`はデフォルト値です。

ここはORMで生成されているので、ORMが原因なのではと考えました。
ですが、僕が使用しているPrisma ORMにはtimezoneを設定することができないようでした。
これもかい。
これができれば、最も楽だと思うのですが。
やはり、NestJSやPrismaが日本で流行らないのもそれなりの理由があるようですね。
まあ僕は使いますが、

## 解決策
上述では、デフォルト値をORMから生成していると述べました。
つまりこれをデータベース側から生成すればよいわけです。
PostgreSQLではtimezoneを設定できました。
以下のように.schema.prismaを編集しました。
```
    updated_at DateTime @default(dbgenerated("NOW()"))
    created_at DateTime @default(dbgenerated("NOW()"))
```

デフォルト値の生成をORMではなく、データベースに委ねるという意味です。
これで、データベースに入る時刻はデフォルトで日本時間となりました。
## 懸念
バッチ処理など、バックエンドのアプリケーションベースで時刻が必要になる場合にはこの手は使えません。
9時間足すという脳筋処理や、ミドルウェアによる処理などが考えられるかと思います。
ミドルウェアによる処理も実装していこうかな、おもしろそう。
また、ほかの記事を見てみると、Node.jsにはtimezoneを設定できるようです。
それでNestJSに設定できないなんてことあるか？と思いながら、、、
こっちも探ってみようかな
## 個人開発って楽しい
結構楽しいですね、勉強にもなります。
転職にも有利になるかな、とも思いながら頑張っています。
(新卒で転職考えてるのは内緒で)
dart/flutter で行番号付きのデバッグプリントをする

dart で行番号付きのデバッグプリントをするパッケージ(output)を作成しました。

https://pub.dev/packages/output

とりあえず、デモ用のソースを提示しておきます(dart-sdk-3.7.2 と dart-sdk-3.9.0-14.0.dev で動作を確認しました。また flutter web, flutter windows desktop でも動作しました(flutter-sdk-3.29.3))。

echo(), dump() ともに第二引数にタイトル文字列を指定すれば、
[タイトル] ==> [第一引数に指定した値]
のように表示されます。

また、dump() ではまず、スタックとレースから呼び出し関数名および呼び出し行番号をまず印字してから第一引数の値を表示します。(第二引数のタイトルが指定されていた場合は、上記のようにタイトル付きで表示されます)

```pubspec..yaml
name: qiita
description: A sample command-line application
version: 0.0.1
publish_to: none

environment:
  sdk: ^3.7.2

dependencies:
  

dev_dependencies:
```

```dart:demo.dart
import 'package:output/output.dart';

void main() {
  final list = [11, 22, 33];
  echo(list); // (1)
  echo(list, "list"); // (2)
  dump(list); // (3)
  dump(list, "list"); // (4)
}

/*
【実行結果】
[11, 22, 33] // (1)
list ==> [11, 22, 33] // (2)
[DEBUG] @ main (file:///D:/home11/dart/qiita-output/bin/demo.dart:7:3) // (3)
[11, 22, 33] // (3)
[DEBUG] @ main (file:///D:/home11/dart/qiita-output/bin/demo.dart:8:3) // (4)
list ==> [11, 22, 33] // (4)
 */
```
【読書感想】プロジェクトマネジメントの基本が全部わかる本

ランニングしながらAudibleで聴いた本の感想です。
本のまとめというより、自分が心に残ったことを3つだけ書いてます。
とりあえず思ったことをメモするのが大切と思い、なるべく30分以内で書き上げています。

# 読んだ本
プロジェクトマネジメントの基本が全部わかる本
橋本 将功 (著)

プロジェクトマネジメントの本です。といっても、PMBOK的な内容というより、プロジェクト「あるある失敗」を踏まない方法が紹介されています。
「これからの時代の基礎」的な内容が図解で抑えられており分かりやすかったです。

個人的には新しい内容というより知っている内容が多かったです。ただ、こういう基礎的な内容を忘れると落とし穴にハマるケースもあります。
そういう意味で、主語が大きいタイトルですが、それに見合った良い本だとは感じました。（個人的満足度２／３、一般的なおすすめ度２．５／３）

# 心に残ったこと

## 馴れ合い型組織より戦友型組織を目指す

チームには2種類あり、コミュニケーションが活発で仲も良い「馴れ合い型」と、コミュニケーションは適度で、成果に重点を置く「戦友型」があるとのことです。
前者は、日本では昔からある「メンバーシップ型」、後者は「ジョブ型」ともニュアンスが近いです。
仕事上のチームは、もちろん戦友型（ジョブ型）を目指すべき、とのことでした。

さらに、**タスクをアサインするときは、そのメンバーが「ジョブ型の志向を持っているか？」を見極めるべき**、とのことでした。
ちょっと残酷ですが、メンバーシップ型の人に、個人に紐づいた重要な仕事をアサインするのは注意が必要、ということです。
この「タスクをアサインする前にメンバーの志向を考える」という点は、個人的に新しい概念でした。

## アジャイル（スクラム）開発はメリットばかり強調されるが、本当は難易度が高い

変化の激しい・答えのない時代に、ウォーターフォールとの対比で、アジャイル（スクラム）開発のメリットが強調されます。
スクラム開発では、小さい開発サイクルを回して、製品の完成度を高めていくという手法で、変化に柔軟・答えがなくても回せる、というように見えます。

しかし、「**スクラム開発ではメンバー1人1人に高い能力が要求されるので、本当は難しい**」とのことでした。
マネージャー含め、メンバー全員が優秀なチームで何かを開発するのであれば、スクラム開発は問題ありませんが、ほとんどの場合そうでないと思います。

対処法として、スクラム開発に似せて「試作品を作る」というステップを間に挟んだウォーターフォール開発も検討すべきとのことでした。

## 要件定義が一番山場

「**プロジェクトにおいて後から要求が増えるのは、ラーメンを頼んでおいて、後から餃子を追加するようなものである**」という例えがありました。
また、「プロジェクトの失敗は後から取り戻すのが難しい」ということも強調されています。
実際のプロジェクトでも、開発途中での要望変更や、要件が曖昧に書かれていたせいで予期せぬ対応が必要になり納期遅延となるケースが多いと思います。
そのため、「**要件定義が一番山場で、ここがPJの成否を決める**」とのことでした。

また、要件定義は、要求（〜したい）と要件（〜する）を明確に分けるべき、とのことでした。
さらに、「顧客が望むものが、欲しいものとは限らない」とのことでした。（これは有名な絵がありますが・・・）
デザイン思考の考えを用い、まずは共感したうえで解決策を考える、というのが重要なのかなと個人的に思いました。
リスク対応の4種類をまとめてみた

## リスク対応の4種類を知ろう

リスクマネジメントにおいて重要なのが、「リスク対応」の考え方です。この記事では、実務やプロジェクト管理でよく使われるリスク対応の4種類について、具体例とともに解説します。

---

### 1. リスク回避（Avoidance）

**リスクそのものを発生させないようにする方法**です。  
例：リスクが大きい新規事業を見送る、危険な作業をやめるなど。

---

### 2. リスク低減（Mitigation/Reduction）

**リスクの発生確率や影響を小さくする方法**です。  
例：セキュリティ教育の徹底、システムの二重化、耐震補強など。

---

### 3. リスク移転（Transfer）

**リスクが発生した場合の損害を第三者に移す方法**です。  
例：保険への加入、業務委託、契約による責任分担など。

---

### 4. リスク保有（Acceptance/Retention）

**リスクを受け入れて、特に対策を講じない方法**です。  
発生確率や影響が小さい場合や、他の対策がコストに見合わない場合に選択されます。

---

## まとめ

| リスク対応策 | 内容 | 具体例 |
|---|---|---|
| 回避 | リスク自体をなくす | 危険な事業をやめる |
| 低減 | 発生確率や影響を下げる | 教育、システム強化 |
| 移転 | 他者にリスクを移す | 保険、外部委託 |
| 保有 | 受け入れて何もしない | 小さなリスクを許容 |

状況に応じて、これらを組み合わせて最適なリスク対応を選択しましょう。

---

> **リスク対応は、リスクの性質や事業の状況に合わせて柔軟に選ぶことがポイントです。**
---

情報源
[1] リスクマネジメントとは？4段階のプロセスやリスク対応方法を解説 https://manebi.co.jp/column/m-0103/
[2] 情報セキュリティにおける「リスク対応」とは？4つの対応方法 ... https://secure-navi.jp/blog/000036
[3] リスク対応（Risk Treatment） - ニュートン・コンサルティング https://www.newton-consulting.co.jp/bcmnavi/glossary/risk_treatment.html
[4] リスクマネジメントとは｜基本の考え方、プロセスを簡単に解説 https://www.persol-group.co.jp/service/business/article/397/
[5] 4種類のリスク対策 ～予防・軽減・移転・容認 https://mngmnt.jp/2016/09/09/risk-measures/
[6] 簡単に理解できる！企業がすべきリスク管理の重要性とやり方 https://www.contracts.co.jp/useful/17304/
[7] リスク管理のカギはリスク対応計画にあり｜流れと役割とは https://www.lrm.jp/security_magazine/risk-response-plan/
[8] 企業リスクとは？リスクの種類・管理体制を構築する際のポイント ... https://www.abitus.co.jp/column_voice/cia/column_voice6.html
提案を通すことに固執しない

# 提案が通らなかったとき、QAとしてどう考えるか

QAとしてプロジェクトに関わっていると、  
「こうした方がもっと良くなるんじゃないかな？」と思う場面ってよくあると思います。  
僕自身も、仕様の詰めや優先順位の相談などで、ちょこちょこ提案をすることがあります。

ただ、そんなときにいつも意識していることがひとつあります。

それは、**提案を通すことに固執しすぎないこと。** です。

---

## 提案が通らないのは、よくある

もちろん、自分が考えた提案には理由があって、  
できれば「なるほど、それでいこう」と言ってもらいたい気持ちはあります。

でも、実際にはプロダクトの状況、チームの事情、優先度など、いろんな要素を総合して判断された結果、**通らない**ということは普通にあります。  
むしろ、通らない方が多いくらいかもしれません。

そこで無理に押し通そうとすると、その場では折れてもらえたとしても、  
「ちょっと強引だな」とか「また言ってきそうだな」って思われてしまって、  
長期的な信頼関係に影響が出ることもあるんじゃないかと思うんですよね。

---

## 提案が通らなかったとしても、価値はある

じゃあ、提案が通らなかったときって意味がなかったのか？というと、  
僕は全然そう思っていません。

むしろ逆で、提案によって**現状の意思決定がより強固になった**と捉えられることもあると思うんです。

たとえば、仕様や優先順位の意思決定が進んでいる中で、  
QAとして「この視点はどうですか？」と提案する。

それに対して検討したうえで「やっぱりこのままでいこう」となったとしたら、  
それって**違う視点からの意見も含めた上で意思決定が強くなった**ということですよね。

つまり、提案が通っても通らなくても、プロジェクトの意思決定の“精度”を上げることに貢献できている。  
そう考えられると、だいぶ気持ちが楽になります。

---

## 提案が通ったら最高、通らなくてもオッケー

提案が通って意思決定が変わったら、それはそれで最高。  
「チームの視点を広げることができた」っていう実感もあるし、素直に嬉しいです。

でも通らなかったとしても、現状の意思決定を改めて見直すきっかけを作れたなら、  
それもまた貢献なんじゃないかなと思っています。

---

## まとめ：提案は目的じゃなく、より良い意思決定のための手段

提案すること自体が目的になってしまうと、通らなかったときにガッカリしたり、  
関係性を悪くしてしまうリスクが出てきます。

そうじゃなくて、**プロジェクトとしてより良い判断ができるように、視点や材料を投げ込む**くらいの気持ちでいると、提案の仕方も関係性も自然と良くなっていく気がします。

長期的にチームに信頼されるQAでいるためにも、「通すことにこだわりすぎない」って、
実はすごく大事なスタンスなんじゃないかなと、僕は思っています。
【学習】GithubCodespacesの理解。仕組みについて

## はじめに
GithubCodespacesという機能？をはじめてりようしました。
そこでの疑問と初心者向けにDockerの関係をまとめてみたいと思います。


## わたしの疑問

- 「GitHub Codespaces は Dockerコンテナ上で動作する開発環境」というものをなにかでめにした。
- 「GitHub Codespaces」はクラウド上でうごくVscodeのようなエディタという認識であっている？
- 「Dockerコンテナ上で動作する開発環境」らしいが、私のPCにインストールされているDockerDesktopを起動していないのに動く？？どういうこと


### GitHub Codespaces と Docker の関係について
**結論**

✅ 「GitHub Codespaces」はクラウド上で動作する VSCode のようなエディタ
✅ Docker Desktop を起動していなくても、Codespaces は Docker コンテナ上で動作する
✅ Docker は「GitHub のクラウド環境」で動いているため、私のPCのDocker Desktop とは無関係

---

### 💡 GitHub Codespaces の仕組み
GitHub Codespaces を使うと、クラウド上に**「開発専用の仮想マシン（VM）」**が作られる
この VM の中で **Docker コンテナ** が動いていて、そこに Ruby や Rails などをインストール。

**🛠 簡単に言うと…**
- 私のPCには何もインストールせずに、クラウド上の仮想環境で開発できる
- Docker コンテナは GitHub のクラウド内にあるので、私のPCの Docker Desktop とは関係ない
- PCのブラウザ上で VSCode っぽいエディタを開いているだけ

---

### 💡 なぜ Docker Desktop を起動していないのに動くの？
Docker は **クラウド上の GitHub サーバーで動いているからです！

---

### 💡 わかりやすい図

以下のようなイメージです👇

```
  🚀 GitHub Codespaces の仕組み
  ───────────────────────────────────
  | あなたの PC (ブラウザで操作)       |
  | ┌──────────────────────────┐     |
  | |  Codespaces の VSCode風エディタ | |
  | └──────────────────────────┘     |
  ───────────────────────────────────
       ⬇ インターネット経由で接続
  ───────────────────────────────────
  | GitHub クラウド (データセンター)   |
  | ┌──────────────────────────┐     |
  | |  仮想マシン (VM)          |     |
  | |  ┌──────────────────┐    |     |
  | |  |  Docker コンテナ  |    |     |
  | |  └──────────────────┘    |     |
  | └──────────────────────────┘     |
  ───────────────────────────────────

```

---

### 💡 まとめ

✅ GitHub Codespaces は、クラウド上にある Docker コンテナを使って開発する環境
✅ 私の PC には Docker は不要（Docker Desktop を起動しなくてもOK）
✅ ブラウザで VSCode みたいに編集できるが、実際のプログラムは GitHub のクラウドで動いている

GithubCodespacesについてすこしでも理解が深まれば幸いです
MacBookユーザー必見｜使えば作業効率3倍アップする必須MacBookアプリ集

私が初めてMacBookを買ったのは、大学一年の春です。デザイン系の授業が始まるタイミングで「みんな使ってるから」となんとなく買ったのがきっかけでした。

ところが、最初の1ヶ月はほぼSafariとメール、たまにWord程度。

「Macって、意外と使いづらい？」とさえ思った時期もあります。

でも、ある先輩のひとことが転機でした。

「Macはアプリを入れて初めて“武器”になる」

その言葉どおり、用途に合ったアプリを入れていくうちに、Macは“ただのパソコン”から“最強の作業空間”へと変わっていったのです。

## なぜMacBookにアプリが必要なのか？

Macは非常に洗練されたUIとパフォーマンスを持っていますが、ファイル整理、PDF編集、画像・動画編集、生産性向上、セキュリティ管理などといった日常的なタスクは、標準アプリだけでは限界があります。

むしろ、自分の用途に合ったアプリを導入することで、Macの“可能性”は無限大になるのです。

## Macbookに入れるアプリ一覧｜初心者からプロまで必携の厳選アプリ

### ファイル整理・クリーンアップ系

**[BuhoCleaner](https://www.drbuho.com/jp/buhocleaner)**

Macのストレージを可視化し、不要ファイルや重複ファイルをワンクリックで削除できるアプリ。

- ゴミ箱やキャッシュ、自動起動項目をまとめて掃除
- 不要なアプリを一気にアンインストール
- PhotoshopやLightroomなどのキャッシュも一発で軽量化
- ストレージを最適化し、空き容量を増やす

ユーザーの声：「BuhoCleanerのおかげで、Macの動作が劇的に軽くなった」

**AppCleaner**

アプリ削除時に関連ファイルまでごっそり削除してくれる無料ツール。

### 生産性アップ＆効率化

**Alfred**

キーボード操作で何でも呼び出せる“Mac版ランチャー”。

- 「Ctrl + Space」でアプリ・ファイル・Web検索を一発呼び出し

- 自作Workflowを組めば、SlackやChatGPTとも連携可能

**Notion / Obsidian**

情報整理、ノート、知的生産にはこの2強。

- Notionはチーム向け、タスクとデータベース連携が神

- ObsidianはZettelkasten（知識カード）管理に特化

ユーザーの声：「Obsidianで書いたメモが、数ヶ月後のアイディアに繋がったときの快感は異常」

**Magnet**

ウィンドウをドラッグして画面分割配置できる神アプリ。

- Ctrl＋Option＋方向キーで2画面作業が劇的に捗る

### PDF・ドキュメント編集

**PDF Expert**

Adobeより軽量で、注釈・署名・ページ並び替えまで完璧に対応。

- 学生・士業・営業など、資料を扱う全ての人におすすめ

**CleanShot X**

スクリーンショット・画面録画・GIF作成を1本で完結。

- 注釈・ぼかし・タイマー撮影がプロ仕様

## 動画・画像編集

**DaVinci Resolve（無料）**

プロも使う動画編集ソフト。YouTube初心者にも大人気。

- カラーグレーディング・音声調整が無料とは思えないレベル

**Pixelmator Pro**

Photoshopより軽快。Macネイティブの画像編集アプリ。

- シンプルな操作でSNS用画像も爆速制作

**[Filmora](https://www.topsoftwaretips.com/wondershare-filmora/)**

インフルエンザも利用している動画編集ソフトで、Adobeの代わりアプリと見られます。
- 最新のAi技術も搭載し、動画を編集して、アップロード
- 初心者から上級者までサポートする動画編集アプリ
- スマホ、パソコンとも対応する

## 【Tips】Macbookに入れるアプリで実現した私のBefore/After

⛔ Before

- 何も整理されていないデスクトップ
- タブだらけのSafari
- 動画書き出しに30分以上

✅ After

- BuhoCleanerでMacの起動が15秒短縮
- Alfredでアプリ起動が3倍速に
- Notionで複数プロジェクトを一括管理
- DaVinci Resolveで編集→書き出しまで10分以内に

まさに、Macの持つ本来のスペックを“アプリの力”で引き出せた瞬間でした。

## 【まとめ】Macbookに入れるアプリは“自分の作業環境”をつくるもの

MacBookは単体でも優秀なデバイスですが、入れるアプリ次第で「武器」にも「相棒」にも変わります。

今回ご紹介したアプリは、すべて私自身が実際に使ってきたものばかり。

まずは自分の目的に合う1〜2個からでOK。

アプリを厳選して取り入れていくことで、きっとあなたのMac体験は劇的に変わるはずです。
Gitリポジトリ切替による、開発環境の移行作業メモ

# やりたいこと
Home Assistantのカスタムインテグレーション開発環境（以下、HA開発環境）において、
これまで開発用とリリース用で分けていたGitリポジトリを一本化しました。

リリース作業の簡素化、IssueなどのGitHub機能の一元管理を目的としたもので、
リリース用リポジトリにdevelopブランチを作成し、開発も同じリポジトリで行う構成に変更しています。

Git操作にまだ不慣れなところもあるため、備忘録として移行作業の手順を残しておきます。

ちなみに、今回出てくるHome Assistantのカスタムインテグレーションはこちらです。

https://github.com/NaNaLinks/homeassistant_nature_remo


### ■現状
- 開発用リポジトリ：homeassistant_config（プライベート）
- リリース用リポジトリ：homeassistant_nature_remo（パブリック）

※開発・リリースが別々のリポジトリで管理されていた

### ■変更後
- リリース用リポジトリ homeassistant_nature_remo に develop ブランチを作成
- 開発環境も同一リポジトリ内で行うことで、GitHub機能を一元活用

### 開発環境

- OS：Ubuntu
- 構成：`~/homeassistant-dev/config` に開発用リポジトリをクローン済み
- Home Assistant Core（venv構成）
- 開発リポジトリの履歴は移行しない方針

### やりたいこと

- 開発・リリース統合リポジトリへ環境を切り替え
- developブランチで開発継続
- Home Assistantがこれまで通り動作すること


# 移行手順

### Step 1：既存の開発用リポジトリのバックアップ

```bash
sudo apt update
sudo apt install zip

cd ~/homeassistant-dev
zip -r config_backup_$(date +%Y%m%d).zip config
```

※ zip が入っていない環境では、最初にインストールします
※ config_backup_20250415.zip のように日付付きファイルが作成されます


### Step 2：リリース用リポジトリに develop ブランチを作成

GitHubのWeb UIから操作するのが簡単です：
１. main ドロップダウンをクリック
２. develop と入力して「Create branch develop from main」をクリック

<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4016885/4976429f-a222-43f1-8e3e-5aab3213cfde.png">

３. ブランチ作成を確認

<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4016885/bb647b6d-53f6-4b69-8ed8-282e363a94f8.png">


### Step 3：開発環境の config/ を切り替える

```bash
# .git削除してGit追跡を外す
cd ~/homeassistant-dev/config
rm -rf .git

# config ディレクトリを退避
cd ~/homeassistant-dev
mv config config_old

# developブランチを新しくクローン
git clone -b develop https://github.com/NaNaLinks/homeassistant_nature_remo.git config

# developブランチになっていることを確認
cd config
git branch
```


### Step 4：旧configから必要なファイルを移植

```bash
cd ~/homeassistant-dev

# カスタム統合をコピー
cp -r config_old/custom_components/nature_remo config/custom_components/

# 基本設定ファイルをコピー
cp config_old/configuration.yaml config/
cp config_old/secrets.yaml config/
cp config_old/automations.yaml config/
cp config_old/scripts.yaml config/
cp config_old/scenes.yaml config/
```

### Step 5：.gitignore を整理

```.gitignore
# Python
__pycache__/
*.pyc
.env
.venv/
.idea/
.vscode/
*.egg-info/
dist/
build/

# Home Assistant
*.log
*.db
*.db-shm
*.db-wal
secrets.yaml
.cloud
.storage/
home-assistant.log*
deps/
.HA_VERSION
blueprints/
configuration.yaml
automations.yaml
scenes.yaml
scripts.yaml

# optional
custom_components/__pycache__/
```

.yaml ファイルはGit管理しない方針にしています


### Step 6：移行後の環境でHome Assistantを起動

```bash
source ~/homeassistant-dev/venv/bin/activate
hass -c ~/homeassistant-dev/config
```

- 初回起動時はユーザー登録画面が表示される
<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4016885/2ee75d06-4151-4ea7-b418-385794cebf95.png">

- DBは移行していないため、新規環境としてセットアップされる


### Step 7：旧環境 config_old を削除

```bash
rm -rf ~/homeassistant-dev/config_old
```


# まとめ
- リポジトリを一つに統合することで、運用がかなり楽になりました。
- ブランチを活用することで、開発・検証・リリースのフローもスムーズにできそうです。
Basic PHP Syntax

![Introduction to PHP for Beginners.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3943666/f47012b0-8aa3-46c8-8a6b-6153feb30673.jpeg)

---

### Basic PHP Syntax

#### PHP Tags

PHP code is embedded within HTML using special tags. The most common tag to start and end PHP code is `<?php` and `?>`. This tells the server to process the code within these tags as PHP.

For example:

```php
<?php
  echo "Hello, PHP!";
?>
```

You can also use short tags like `<?` and `?>` but be aware that short tags are not always enabled on all servers, so it’s best to stick with the full `<?php` tags for compatibility.

#### Echoing Content

In PHP, you often want to display information to the user, and you do that using the `echo` statement. The `echo` statement outputs data to the screen. You can use `echo` to print text, variables, or even HTML elements.

Here’s a simple example:

```php
<?php
  echo "Welcome to PHP!";
?>
```

This code will output: **Welcome to PHP!**

You can also use `echo` to display variables or HTML:

```php
<?php
  $name = "John";
  echo "Hello, $name!"; // Outputs: Hello, John!
  echo "<br>"; // Outputs a line break in HTML
  echo "<h1>PHP is awesome!</h1>"; // Outputs an HTML header
?>
```

#### Comments in PHP

Like most programming languages, PHP allows you to add comments in your code. Comments are important for explaining your code to others (or to yourself, months later). PHP supports both **single-line comments** and **multi-line comments**.

- **Single-line comments**: Use `//` or `#` for a single line of comment.

```php
<?php
  // This is a single-line comment
  # This is another way to write a single-line comment
?>
```

- **Multi-line comments**: Use `/*` to start the comment and `*/` to end it.

```php
<?php
  /*
    This is a multi-line comment.
    You can write comments over multiple lines.
  */
?>
```

### Summary of Basic PHP Syntax:
- PHP code starts with `<?php` and ends with `?>`.
- Use `echo` to output text or variables.
- Add comments with `//`, `#`, or `/* */` for single-line or multi-line comments.

---