OmniAICreator/Qiita-1.07M huggingface dataset:
環境変数の設定（連載第17回/25回）

# はじめに
環境変数は、システムやユーザーの設定を管理するために重要です。環境変数を適切に設定することで、システムの動作やアプリケーションの動作をカスタマイズできます。ここでは、`export`、`env`、`set` の基本的な使い方を紹介します。

# コマンド説明
#### `export` - 環境変数の設定

`export` コマンドは、新しい環境変数を作成したり、既存の環境変数を現在のシェルセッションに適用するために使用されます。

```powershell
# 使用例
export 環境変数名=値
# PATH 環境変数に新しいパス /new/path を追加します。
export PATH=$PATH:/new/path
```

#### `env` - 環境変数の表示
`env` コマンドは、現在設定されている環境変数の一覧を表示します。特定の環境変数の値を一時的に変更してコマンドを実行することもできます。

```powershell
# 環境変数の一覧を表示：
env
# 環境変数を一時的に変更してコマンドを実行：
# PATH 環境変数を一時的に /new/path に設定して command を実行します。
env PATH=/new/path command
```

#### `set` - シェルと環境変数の設定
`set` コマンドは、シェル変数と環境変数の両方を設定および表示するために使用されます。
`set` コマンドを使用することで、シェルの動作をカスタマイズすることができます。

```powershell
# 使用例
set [オプション]
# シェル変数と環境変数の一覧を表示：
set
# 一時的な環境変数の設定
export TEMP_VAR="Temporary Value"
echo $TEMP_VAR
# シェルスクリプト内で環境変数を設定
#!/bin/bash
export MY_VAR="Hello, World!"
echo $MY_VAR
# 環境変数を使用してアプリケーションの動作を変更
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
java -version
# 特定のコマンド実行時にのみ環境変数を変更
env PATH=/custom/path ls
```
# おわりに
環境変数の設定を理解し、適切に管理することで、システムの動作やアプリケーションの設定を効率的にカスタマイズできます。

次からの記事では、セキュリティ対策について解説します。

https://qiita.com/yu1016/items/7b819b1e42314faa8954

一覧

https://qiita.com/advent-calendar/2024/pig
Security

[Previous << Manage Configuration](https://qiita.com/flowcadence/items/b600e1896db8cc1f5297)
[Next >> Get Block](https://qiita.com/flowcadence/items/023eaeb0632a3ad2b653)

https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a#flow-cli-と-fcl


アカウントおよび秘密鍵の管理には本質的に危険が伴います。CLI を使用する際には、秘密鍵のデータが漏洩しないよう、特に注意する必要があります。

Flow CLI には、プライベートなアカウントデータを保護するためのオプションがいくつか用意されています。

⚠️ 警告：設定ファイルでプライベートキーを使用する時にはご注意ください。決してプライベートキーのデータをソース管理にコミットしないでください。もしプライベートキーのデータをテキストで保持する必要がある場合は、ソース管理に含まれない別ファイルを使用することをお勧めします。（例: `.gitignore`で除外する）

<h1>Private Account Configuration File</h1>

アカウントのキーをソース管理に含まれない別ファイルに保存すること（例: `.gitignore`で除外する）は、より良いセキュリティへの最初の一歩となります。

**Main configuration file**
```ruby
...
"accounts": {
  "my-testnet-account": { 
    "address": "3ae53cb6e3f42a79",
    "key": {
      "type": "file",
      "location": "./my-testnet-account.key"
    } 
  }
}
...
```
**Separate account key file**

⚠️ このファイルは`.gitignore`に追加してください。

`my-testnet-account.key`ファイルは、16進数でエンコードされた秘密鍵のみが含まれます。
```
334232967f52bd75234ae9037dd4694c1f00baad63a10c35172bf65fbb8ad1111
```
***
**Private configuration file**

⚠️ このファイルは`.gitignore`に追加してください。
```ruby:flow.testnet.json
{
  "accounts": {
    "my-testnet-account": {
      "address": "3ae53cb6e3f42a79",
      "key": "334232967f52bd75234ae9037dd4694c1f00baad63a10c35172bf65fbb8ad1111"
    }
  }
}
```

<h1>Store Configuration in Environment Variables</h1>

非公開にすべき値（秘密鍵やアドレスなど）には環境変数が使用できます。

以下の例を参考にしてください。
```ruby
PRIVATE_KEY=key flow project deploy
```
```ruby:flow.json
{
  ...
  "accounts": {
    "my-testnet-account": {
      "address": "3ae53cb6e3f42a79",
      "key": "$PRIVATE_KEY"
    }
  }
  ...
}
```
<h1>Private Dotenv File</h1>

CLIは、現在のディレクトリの`.env`ファイルに定義された環境変数を読み込みます。これらの変数は他の環境変数と同様、`flow.json`内で置換に利用することができます。

⚠️ `.env`ファイルは決してをソース管理にコミットしてしないでください。特に、秘密鍵などの機密情報が含まれている場合は、絶対に避けてください。

`.env`ファイルの例:
```ruby
PRIVATE_KEY=123
```
<h1>Composing Multiple Configuration Files</h1>

複数の設定ファイルを次のように使い分けることができます。
```ruby
flow project deploy -f main.json -f private.json
```


*Last updated on **Nov 21, 2024** by **Jordan Ribbink***

翻訳元

https://developers.flow.com/tools/flow-cli/flow.json/security

***
<b>[Previous << Manage Configuration](https://qiita.com/flowcadence/items/b600e1896db8cc1f5297)
</b>

[Flow blockchain / Cadence version1.0ドキュメント](https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a) (Security)

<b>[Next >> Get Block](https://qiita.com/flowcadence/items/023eaeb0632a3ad2b653)</b>
Cloudflare はネームサーバーNSを変更できない！


# Cloudflare Registrarでのネームサーバー設定の制約と選択肢

Cloudflareは、高速で安全なDNSサービスやWebサイト保護を提供するプラットフォームとして広く利用されています。そのCloudflareが提供する「Cloudflare Registrar」は、リーズナブルな価格でドメイン登録サービスを提供します。しかし、ネームサーバーの設定に制約があるため、利用を検討する際には注意が必要です。




# Cloudflare Registrarのネームサーバーの制約

Cloudflare Registrarを利用してドメインを登録した場合、Cloudflareのネームサーバーを必ず使用する必要があります。他社のネームサーバーを設定することはできません。

これにより、Cloudflareの強力なDNS機能やDDoS防御を最大限に活用できますが、特定の他社サービスを利用するためにカスタムネームサーバーを設定する必要がある場合、適した選択肢ではない可能性があります。




# カスタムネームサーバーの利用 (Businessプラン以上)

CloudflareのBusinessプラン以上を利用している場合は、「カスタムネームサーバー」機能を利用することができます。この機能を使うと、以下のことが可能です。

独自のドメイン名を使用したネームサーバーを作成

企業ブランディングに合わせた名前の設定


# しかし、これらのカスタムネームサーバーもCloudflareのインフラ上で動作しているため、完全に他社のネームサーバーを利用することはできません。


# Cloudflare Registrarを選択する際の注意点

Cloudflare Registrarでのドメイン登録を検討する際は、以下を確認してください。

1. Cloudflareのネームサーバーを利用する必要があることを理解する


2. 他社のネームサーバーを使用する必要がある場合は、別のドメイン登録サービスを選択する


3. ビジネスプラン以上を利用する場合、カスタムネームサーバーで独自ドメインを設定可能





# まとめ

Cloudflare Registrarは、コストパフォーマンスに優れたドメイン登録サービスを提供しています。しかし、ネームサーバー設定に関する制約があるため、特定の用途には適さない場合があります。

Cloudflareの機能を最大限活用したい場合：おすすめ

他社ネームサーバーが必要な場合：別のサービスを検討


Cloudflare Registrarを利用する際には、これらの特徴を理解した上で選択することをお勧めします。
【ネットワーク】３分間NetWorking 第24回〜25回 OSI参照モデル レイヤ3 DHCP

# はじめに
この記事は、3分間NetWorkingを読んでインプットした知識をアウトプットするために執筆しています。
学習内容のまとめ、学習してみての所感や疑問などを記載しています。
記事を読んでみて、間違っていることへの指摘や感想などありましたら、ぜひコメントをいただければ幸いです。
3分間NetWorkingのリンクは以下の通り。
https://www5e.biglobe.ne.jp/aji/3min/

#### :bulb:記事のトピックス
・カプセル化
・DHCP

# カプセル化に必要なアドレス
カプセル化の流れとして、レイヤ4から、セグメントが渡されて、レイヤ3でIPヘッダを付けてパケットにします。
その後、レイヤ2に渡して、イーサネットのヘッダとトレーラを付けてフレームにします。
IPヘッダもイーサネットヘッダも、どちらも4つのアドレスが必要になります。
宛先MACアドレス、宛先IPアドレス、送信元MACアドレス、送信元IPアドレスです。
つまり、データを転送するには、4つのアドレスを知る必要があります。

# 送信元MACアドレス
送信元MACアドレスは、NICを取り付けた段階で認識されます。
自動的に送信元MACアドレスは取得しているため、特にやることはありません。

# 送信元IPアドレス（静的）
送信元IPアドレスは、MACアドレスとは異なり、機器に付属しているアドレスではないため、自動で取得することはできません。
静的な送信元IPアドレスの場合は、ネットワーク管理者が割り振ることになるからです。
そして、ネットワーク管理者から割り振られたアドレスを、手動で入力することになります。

静的IPアドレスとは、スタティックIPアドレスや固定IPアドレスとも呼ばれ、ネットワーク管理者がアドレスを割り振り、手動で変更しない限り常に変わらないIPアドレスのことを指します。
静的IPアドレスのデメリットとして、IPアドレスを手動で入力するため、入力ミスが起きる可能性があること、ネットワークを移動すると、ネットワーク番号も変わるため、その度にIPアドレスを打ち直す必要があることです。
ネットワークの規模が大きくなると、管理も煩雑になってくるので、後述の動的IPアドレスを割り当てるのが一般的です。

# 送信元IPアドレス（動的）
ある程度の台数を管理するようなLANや、頻繁にデバイスの移動が起こるようなLANでは、動的なIPアドレスの割り当てが一般的になっています。
動的IPアドレスは、ダイナミックIPアドレスとも呼ばれ、ネットワークに接続した時点で自動的にIPアドレスを取得します。

IPアドレスの取得には、DHCPサーバというサーバに接続し、IPアドレスを要求し、割り当てて貰います。

# DHCP
DHCPは、割り当てるIPアドレスを管理し、実際に割り当て作業を行うDHCPサーバと、割り当ててもらうDHCPクライアントから成り立ちます。
DHCPサーバも全てを自動的にやってくれるわけではありません。
ネットワーク管理者があらかじめ割り当てるアドレスの範囲を決めておく必要があります。
例えば、192.168.1.0のネットワークがあったとし、192.168.1.1～192.168.1.254までのアドレスを割り振ってよい。という具合に範囲を決めておきます。
範囲内の中で、特定のアドレスを指定して、このアドレスは割り当ててはいけませんという設定も可能です。
この割り当てて良い範囲のことを、IPアドレスのプールと呼びます。

サーバは設定されたプールの中から、要求してきたクライアントに対して、それぞれがユニークになるようアドレスを割り当てます。
さらに、ネットワーク管理者は範囲の他にIPアドレスのリース期限も設定します。
これは、IPアドレスを割り当てられたまま、他のネットワークの場所に移動してしまった時に、DHCPサーバが、移動したことを検知できないことによります。
他のネットワークに移動したことを検知できないため、割り当てたIPアドレスはずっと割り当てられたままになってしまうため、あらかじめリース期限を設けておき、IPアドレスの再利用性を確保するのです。

リースの期限設定に縛りはないですが、ホストが頻繁に移動するような環境では、リース期限も短く設定するのが一般的です。
逆にホストが頻繁に移動しないような環境であれば、長く設定することもできます。
リース期限が来た時、クライアント側の処理としては、リースを延長をリクエストするか、新しいIPアドレスの取得をリクエストするかの２択になります。

# DHCP 割り当て動作の詳細
DHCPは、大雑把に言うとクライアントがIPアドレスを要求して、サーバがあらかじめ決められたアドレスプールの中から自動的にIPアドレスを割り当てます。
しかし、実際には以下の表のようにもっと細かな動作が行われています。

メッセージタイプ       | 送信者           | 説明
-----------------------|------------------|---------------------------------------------------------------
DHCPDISCOVER           | クライアント      | 新しいIPアドレスを要求する際に、利用可能なDHCPサーバを探すためのブロードキャストメッセージ。
DHCPOFFER              | DHCPサーバ       | クライアントからの要求に応じて、利用可能なIPアドレスを提案するメッセージ。
DHCPREQUEST            | クライアント      | 提案されたIPアドレスを要求する確認メッセージ。また、リースの延長や既存のアドレス再取得時にも使用。
DHCPACK                | DHCPサーバ       | クライアントの要求を承認し、IPアドレスのリースを確定するメッセージ。
DHCPNAK                | DHCPサーバ       | クライアントの要求を拒否するメッセージ。例: 提案したIPアドレスが無効になった場合など。
DHCPDECLINE            | クライアント      | 提案されたIPアドレスが競合している場合（他のデバイスが同じIPを使用中）に送信するメッセージ。
DHCPRELEASE            | クライアント      | 使用中のIPアドレスをリリースして、サーバに返却する際に送信するメッセージ。
DHCPINFORM             | クライアント      | 固定IPを使用しているクライアントが、DHCPサーバから追加の設定情報（例: DNSサーバなど）を要求する。

# まとめ
今回はOSI参照モデル レイヤ3 ネットワーク層のDHCPについてまとめました。
次回もレイヤ3 ネットワーク層についてまとめます。
最後に、記事を読んで間違いの指摘などがあればコメントで教えていただけると幸いです。
ありがとうございました。
ファイルシステムのチェックと修復（連載第16回/25回）

# はじめに
ファイルシステムのチェックと修復は、データの整合性を保ち、システムの信頼性を維持するために重要です。ここでは、`fsck`、`mount`、`umount` の基本的な使い方を紹介します。

# コマンド説明
#### `fsck` - ファイルシステムのチェックと修復

`fsck`（file system check）コマンドは、ファイルシステムをチェックし、エラーを修復するために使用されます。

***主なオプション***
-a : ユーザーの介入なしに自動的に修復
-r : インタラクティブモードで修復
-y : 全ての質問に対して「yes」で答える

```powershell
# 使用例
fsck [オプション] デバイス
# ルートファイルシステムのチェックと修復：
sudo fsck -a /dev/sda1
# 特定のパーティションのチェックと修復：
sudo fsck /dev/sdb1

# システム起動時に自動でファイルシステムをチェック
# このコマンドは、システム起動時に全てのファイルシステムをチェックします。
sudo fsck -A
```
#### `mount` - ファイルシステムのマウント
`mount` コマンドは、ファイルシステムを指定されたマウントポイントにマウントするために使用されます。

```powershell
mount [オプション] デバイス マウントポイント
# 外部デバイスをマウントする：
sudo mount /dev/sdb1 /mnt
# 特定のファイルシステムタイプを指定してマウントする：
sudo mount -t ext4 /dev/sdb1 /mnt

# NTFSファイルシステムをマウント
# このコマンドは、NTFSファイルシステムを /mnt にマウントします。
sudo mount -t ntfs-3g /dev/sdb1 /mnt
```

***主なオプション***
-t : ファイルシステムのタイプを指定
-o : マウントオプションを指定

#### `umount` - ファイルシステムのアンマウント
`umount` コマンドは、指定されたマウントポイントからファイルシステムをアンマウントするために使用されます。

```powershell
# 使用例
umount [オプション] マウントポイントまたはデバイス
# マウントポイントからアンマウントする：
sudo umount /mnt
# デバイスをアンマウントする：
sudo umount /dev/sdb1

# 強制的にファイルシステムをアンマウント
# このコマンドは、/mnt にマウントされているファイルシステムを強制的にアンマウントします。
sudo umount -f /mnt
```
***主なオプション***
-f : 強制的にアンマウント
-l : 忙しいファイルシステムを遅延アンマウント

# おわりに
ファイルシステムのチェックと修復の基本的なコマンドを使用することで、データの整合性を保ち、システムの安定性を維持できます。

次からの記事では、環境変数の設定のチェックと修復について解説します。

https://qiita.com/yu1016/items/e99005836762d03054b6

一覧

https://qiita.com/advent-calendar/2024/pig
[MySQL docker環境]　Fatal error: Illegal or unknown default time zone ‘Asia/Tokyo’

## 筆者について
21歳、大学4年です。
大学は文系ですが、プログラミング歴はだいたい1年半くらいです。

<ul>
    <li>雀魂で麻雀始めたけど、ルール全く分からん</li>
    <li>国内サッカー好き(柏レイソルサポ・アウェイも行くよ)</li>
    <li>海外サッカー好き(プレミア・セリエAは毎節最低2試合は視聴)</li>
    <li>ゴルフの打ちっぱなしにハマり中(パター買わなきゃ)</li>
    <li>禁煙７日目</li>
    <li>週４ジム通い</li>
    <li>エナドリ中毒(頑張ってやめる)</li>
    <li>週１サウナ</li>
    <li>漫画・アニメ好き(最近は刃牙買いたい)</li>
    <li>ジョージがモチベーター(いつもありがとう)</li>
    <li>ギター始めたい</li>
</ul>

以上が僕の特徴です。
もしこれに共感したのであれば、気軽にコメントしてください、仲良くしましょう。

## Timezoneのエラー

そこまで大したことないエラーの備忘録です。

```
Fatal error: Illegal or unknown default time zone ‘Asia/Tokyo’
```

Asia/Tokyoというタイムゾーンを設定しながらも、どこだよそれとmysql側から怒られています。
これはdocker-compose.ymlのデータベース項目に以下の記述をする必要があります。

```
environment:
    TZ: Asia/Tokyo
    または
    - TZ=Asia/Tokyo
```
この書き方はenvironmentにある他の項目に合わせる必要があります。
また、environment項目に少しでも不備があると、docker-composeコマンドが一切通らなくなるので注意です。

:::note warn
.ymlを書き換えた際は必ずコンテナの削除、再起動を行いましょう。コンテナの設計書を編集しただけでは、変更は反映されません。
:::

## P.S
こんなにも中身のない記事ですが、記事を書いて発信することがしたいです。
<ul>
    <li>アウトプットを習慣にしたい</li>
    <li>自分のプロフィールを公開しつつ、縁を広めたい</li>
</ul>

割と良いこともたくさんあると思うので、続けます。
読んでくれた人、ありがとう。
他の記事は中身あるので、ぜひ読んでみてください。
【TabOut】Tabキーで括弧から抜け出そう

## はじめに

VSCodeなどのコードエディタでは、コードを書く際に `(` を入力すると、対応する `)` が自動補完されます。  
普段、この機能を当たり前のように使っているため、補完が効かないテキストエディタを使うと、その便利さを改めて実感する人も多いのでは無いでしょうか。

ここで、`( )` 内に引数や値などを入力した後、括弧の外にカーソルを移動して続きのコードを書く場面は頻繁にありますよね。

このとき、皆さんはどのようにカーソルを移動していますか？  

多くの方はトラックパッドやマウス、または矢印キーを使うのではないでしょうか。

中には、矢印キーを避けて `control + f` でカーソルを移動している方もいることでしょう。  
僕自身、矢印キーを使うとホームポジションが崩れてしまうので、`control` と `f` `b` `p` `n` `e` `a` を組み合わせてカーソル移動することがよくあります。

けれども `control` はキーボードの種類によって位置に揺れがあり、誤入力してしまうことも少なくありません。  
(例えば、MacBookでは左下に `fn` その右隣が `control` ですが、一般的な外付けキーボードでは左下が `control` になっています。)  

また、`control` を押しながら `f` `b` などを入力するのは**如何せん押しづらい**ように感じます。  
矢印キーを使いたくない一心でこのショートカットを使っていますが、正直ホームポジションの崩れと天秤にかけると判断に悩むところです。

コードや文章を修正する際には、トラックパッドや矢印キーを使う方が効率的な場合もあります。  
一方で、変数を入力した後に括弧の外に1文字分だけカーソルを移動する操作は、プログラミング言語に限らず、またプログラミング以外にもMarkdownやLaTeXといった文章作成においても頻発する操作です。   

この**括弧の外へ移動する**たびに `→` や `control + f` を押したり、マウスを使ったりするのは、よくよく考えると煩わしく、効率的ではないと感じませんか？

そこでご紹介したいのが、**TabOut**と呼ばれる拡張機能です。

## TabOut

![TabOut.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950009/2a887266-dc7b-3e3e-bfc8-87a7de12ff93.png)


VSCodeのサイドバーで「Extension」を選択(または `command + shift + x` )し、**TabOut**を検索してインストールしてください。

使い方はとても簡単です。
`( )` の中身の入力を終えた後に `Tab` キーを押すだけで、括弧から抜け出すことができます。  
また `()` に限らず、`""` `<>` `''` `{}`　からも `Tab` 1つで抜けられます。

![TabOutDemo.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3950009/7cd4eb4e-3b07-d424-6cb0-d2d521fef785.gif)


このように `()` の中に `""` や `{}` が含まれている場合でもスムーズに括弧の外へ移動できます。

**TabOut**を使うことでホームポジションを崩すことなく、滑らかにコードを紡ぐことが可能になります。

いやはや、本当に便利です。もっと早く知りたかった.......。  
皆さんもぜひ試してみてください。特に `control + f` を多用する方には強くお勧めします！
プログラミング言語の分類

こんにちは、とほほと申します。今年からスクールでプログラミングの勉強を始めた初学者です。
プログラミング言語の分類について、自分の整理も兼ねて記事を書いてみようと思います <(_ _)>
初学者につき、もし間違いなどがあればお気兼ねなくお知らせいただけますと幸いです！

この記事では**記述形式**と**変換形式**と**型付け**の 3 つの観点で分類について説明します。

## ①記述形式で分類
記述形式は「手続き型言語」と「オブジェクト指向型言語」に分かれます。

### 手続き型言語
プログラムを 1 行ずつの「手続き」という細かい単位で記述し、順番通りに 1 行ずつ記述します。

<dl>
  <dt>メリット：</dt>
  <dd>1 つ 1 つの手順を明確に記述するシンプルな記述形式のため、分かりやすく効率的に作成できます。</dd>
  <dt>デメリット：</dt>
  <dd>プログラムの規模が大きくなると複雑になりやすいため、大規模な開発では管理が難しくなります。</dd>
</dl>

### オブジェクト指向型言語
データをオブジェクトと呼ばれる単位にまとめ、そのオブジェクトに処理を行うメソッドを関連付けます。
オブジェクトは、クラスと呼ばれる設計図に基づいて作成することが出来ます。
また、継承と呼ばれる機能によりコードを再利用することが出来ます。

<dl>
  <dt>メリット：</dt>
  <dd>類似したオブジェクトを 1 つのクラスで共通化できるため、プログラムの開発効率を高めやすいです。</dd>
  <dt>デメリット：</dt>
  <dd>手続き型言語に比べると概念が複雑で、学習コストがかかりやすいです。</dd>
</dl>

## ②変換形式で分類
変換形式は「コンパイラ型言語」と「インタプリタ型言語」に分かれます。

### コンパイラ型言語
プログラム全体をあらかじめ機械語に変換してから実行します。「コンパイラ」は変換処理を行うプログラムのことです。

<dl>
  <dt>メリット：</dt>
  <dd>事前に変換をすべて完了させるので実行時の変換が不要になるため、比較的高速でプログラムを処理できます。</dd>
  <dt>デメリット：</dt>
  <dd>プログラムの書き方に問題があると変換処理でエラーが発生します。プログラムを変更するたびに変換処理が必要になり、すぐに動作を確認できません。</dd>
</dl>

### インタプリタ型言語
プログラムの実行時に 1 行ずつ機械語に変換します。「インタプリタ」も変換処理を行うプログラムのことです。

<dl>
  <dt>メリット：</dt>
  <dd>事前の準備が不要で、効率的にプログラムの動作を確認できます。</dd>
  <dt>デメリット：</dt>
  <dd>実行のたびに変換処理が行われるので、コンパイラ型に比べると速度面では及びません。</dd>
</dl>

## ③型付けの分類
変換形式は「静的型付け」と「動的型付け」に分かれます。

### 静的型付け
プログラムを実行する前に型付けを行います。たとえば、変数の宣言時に以下のように型の記述が必要になります。
```
//数値
int num = 123;

//文字列
String user = "蘇我馬子";
```

<dl>
  <dt>メリット：</dt>
  <dd>プログラムを読む側にとって、型が明記されておりわかりやすいです。</dd>
  <dt>デメリット：</dt>
  <dd>型を記述するためコードが冗長になってしまいます。</dd>
</dl>

### 動的型付け
プログラムの実行時に適切な型が割り当てられます。たとえば、変数を宣言する際は以下のようにシンプルな記述になります。

<dl>
  <dt>メリット：</dt>
  <dd>コードを簡潔に書くことができます。</dd>
  <dt>デメリット：</dt>
  <dd>プログラムを読む側にとって、一見して型がわかりにくいです。</dd>
</dl>

## まとめ
これまで紹介してきた分類ごとに、以下に主要なプログラミング言語の一覧表を作成してみました。

|プログラミング言語名|記述形式|変換形式|手続き型|
|:--:|:--:|:--:|:--:|
| C  | 手続き |コンパイラ | 静的 |
| Go |手続き |コンパイラ | 静的 |
| C++ |オブジェクト |コンパイラ | 静的 |
| C# |オブジェクト |コンパイラ | 静的 |
| Java |オブジェクト |コンパイラ | 静的 |
| Swift |オブジェクト |コンパイラ | 静的|
| PHP |オブジェクト |インタプリタ | 動的 |
| Ruby |オブジェクト |インタプリタ | 動的 |
| JavaScript |オブジェクト |インタプリタ | 動的 |
| Python |オブジェクト |インタプリタ | 動的 |

どの種類にもそれぞれメリット・デメリットがあるため、用途に応じて選択するべきということですね…。
それぞれの違いについて理解できてきたかな…と思います！お付き合いいただきありがとうございました！

## 参考記事
[プログラミング言語を3つの方法で分類！特徴をわかりやすく解説](https://www.sejuku.net/blog/143201)
[手続き型プログラミングとオブジェクト指向の違いとは？言語の特徴や例をわかりやすく解説！](https://jitera.com/ja/insights/36278)
[コンパイラ型言語とインタプリタ型言語の違いとは？メリット・デメリットや種類を解説](https://tech-camp.in/note/technology/93845/)
[【社員ブログ】第2回　動的型付けと静的型付けはどちらがトレンド？](https://libroworks.co.jp/?p=3475)
システムのシャットダウンと再起動（連載第15回/25回）

# はじめに
システムのシャットダウンや再起動は、メンテナンスやトラブルシューティングの際に必要となる基本操作です。ここでは、`shutdown`、`reboot`、`halt` の基本的な使い方を紹介します。

# コマンド説明
#### `shutdown` - システムのシャットダウン

`shutdown` コマンドは、システムを安全にシャットダウンするためのコマンドです。シャットダウンのタイミングを指定することができます。

***主なオプション***
-h : システムをシャットダウン（halt）
-r : システムを再起動
-c : 予定されているシャットダウンをキャンセル
+m : 指定した分後にシャットダウン

```powershell
shutdown [オプション] 時間
# システムをすぐにシャットダウンする：
sudo shutdown -h now
# システムを10分後にシャットダウンする：
sudo shutdown -h +10
# システムをすぐに再起動する：
sudo shutdown -r now
# 予定されているシャットダウンをキャンセルする：
sudo shutdown -c
# 特定の時間にシステムをシャットダウン
# このコマンドは、システムを午後8時にシャットダウンします。
sudo shutdown -h 20:00
# 再起動前にメッセージを表示
# このコマンドは、5分後にシステムを再起動し、ユーザーにメッセージを表示します。
sudo shutdown -r +5 "System will reboot in 5 minutes. Please save your work."
```
#### `reboot` - システムの再起動
`reboot` コマンドは、システムを再起動します。`shutdown` コマンドと異なり、オプションが少なくシンプルに再起動を実行します。

```powershell
reboot
# システムをすぐに再起動する：
sudo reboot
```

#### `halt` - システムの停止
`halt` コマンドは、システムを停止させます。`shutdown -h` と似ていますが、通常はファイルシステムのアンマウントを行わずに停止します。

```powershell
halt
# システムをすぐに停止する：
sudo halt
# システムの停止を確認
# このコマンドは、システムを停止します。
sudo halt
```
# おわりに
システムのシャットダウンと再起動の基本的なコマンドを使用することで、メンテナンスやトラブルシューティングを安全かつ効率的に行えます。

次からの記事では、ファイルシステムのチェックと修復について解説します。

https://qiita.com/yu1016/items/3aaf80b00c71196ea16c

一覧

https://qiita.com/advent-calendar/2024/pig
データのバックアップと復元（連載第14回/25回）

# はじめに
データのバックアップと復元は、システムの信頼性とデータの安全性を確保するために非常に重要です。ここでは、`rsync` と `dd` の基本的な使い方を紹介します。

# コマンド説明
#### `rsync` - 高速なファイル同期とバックアップ

`rsync` コマンドは、ファイルやディレクトリを効率的に同期およびバックアップするためのツールです。特に大規模なデータセットや定期的なバックアップに適しています。

***主なオプション***
-a : アーカイブモード（再帰的にディレクトリを転送し、シンボリックリンク、デバイス、属性を保持）
-v : 詳細情報を表示
-z : データ転送時に圧縮
--delete : 同期先に存在しないファイルを削除


```powershell
rsync [オプション] ソース ディスティネーション
# ローカルディレクトリからリモートディレクトリへのバックアップ：
rsync -avz /path/to/local/ user@remote:/path/to/remote/
# リモートディレクトリからローカルディレクトリへのバックアップ：
rsync -avz user@remote:/path/to/remote/ /path/to/local/

# 特定のディレクトリをバックアップ
# /home/user/backup/ を /media/backup_drive/ にバックアップし、同期先に存在しないファイルを削除します。
rsync -av --delete /home/user/backup/ /media/backup_drive/
```
#### `dd` - ディスクイメージの作成と復元
`dd` コマンドは、低レベルのコピーを行うためのツールで、ディスクイメージの作成や復元に使用されます。

***主なオプション***
if : 入力ファイル
of : 出力ファイル
bs : ブロックサイズを指定
count : コピーするブロック数を指定

```powershell
dd if=入力ファイル of=出力ファイル [オプション]
# ディスク全体のバックアップを作成：
sudo dd if=/dev/sda of=/path/to/backup.img bs=4M
# ディスクイメージを復元：
sudo dd if=/path/to/backup.img of=/dev/sda bs=4M

# USBドライブのイメージを作成
# このコマンドは、USBドライブ（例：/dev/sdb）のイメージを作成します。
sudo dd if=/dev/sdb of=/path/to/usb_backup.img bs=4M
# ディスクイメージを新しいディスクに復元
# このコマンドは、作成したディスクイメージを新しいディスク（例：/dev/sdb）に復元します。
sudo dd if=/path/to/backup.img of=/dev/sdb bs=4M
```

# おわりに
データのバックアップと復元の基本的なコマンドを使用することで、データの保護とリカバリーが効率的に行えます。
次の記事では、システムのシャットダウンと再起動について説明します。

https://qiita.com/yu1016/items/d7cd027dab0266896785

一覧

https://qiita.com/advent-calendar/2024/pig
Label Studioで作成したアノテーションJSONをCreate ML用に変換する方法

Create MLでオブジェクト検出用のモデルを作成する際、Annotation JSONが必要です。しかし、Label Studioで作成したJSONデータはそのままでは使用できません。Appleが要求する形式に変換する必要があります。

この記事では、その変換方法について説明します。Label Studioやアノテーション作成に関する基本的な知識がある前提です。

### 手順

1. **Label Studioでアノテーション作成**  
   Label Studioを起動し、アノテーションを作成します。

2. **アノテーションのエクスポート**  
   作成が完了したら、`Export`ボタンを押し、JSONを書き出します。

3. **YOLO形式でデータを書き出し**  
   書き出されたJSONには、画像ファイル名が変換された画像が含まれないため、YOLO形式でデータを書き出します。この操作で変換された画像も取得できます。

4. **PythonスクリプトでCreate ML用JSONに変換**  
   以下のPythonスクリプトを使用して、Label StudioのJSONをCreate ML用JSONに変換します。

```python:craeteML_annotaion_converter.python
import json
import os
import sys

if len(sys.argv) != 4:
    print("Usage: python craeteML_annotaion_converter.py <input_json> <output_json_path> <output_json_file>")
    sys.exit(1)

input_json = sys.argv[1]
output_json_path = sys.argv[2]
output_json_file = sys.argv[3]

with open(input_json, "r") as f:
    original_data = json.load(f)

create_ml_data = []

for item in original_data:
    image_name = item["data"]["image"]
    image_name = os.path.basename(image_name)
    annotations = []
    
    for annotation in item["annotations"]:
        for result in annotation["result"]:
            if result["type"] == "rectanglelabels":
                value = result["value"]
                label = value["rectanglelabels"][0]

                x_center = value["x"] / 100 * result["original_width"]
                y_center = value["y"] / 100 * result["original_height"]
                width = value["width"] / 100 * result["original_width"]
                height = value["height"] / 100 * result["original_height"]

                annotations.append({
                    "label": label,
                    "coordinates": {
                        "x": int(x_center),
                        "y": int(y_center),
                        "width": int(width),
                        "height": int(height)
                    }
                })
            else:
                print(f"Skipping result")
    
    create_ml_data.append({
        "imagefilename": image_name,
        "annotation": annotations
    })

output_path = os.path.join(output_json_path, output_json_file)
with open(output_path, "w") as f:
    json.dump(create_ml_data, f, indent=4)

print(f"Converted data saved to {output_json_file}")
```

### 実行方法

1. 上記のコードを任意のファイル名（例: `createml_annotation_converter.py`）で保存します。
2. ターミナルで以下のコマンドを実行します。

```bash
python createml_annotation_converter.py <Label Studioで書き出したJSONのフルパス> <出力先ディレクトリ> <出力ファイル名>
```

### 注意点

- スクリプトはすべてのケースに対応していないため、アノテーション方法やJSONフォーマットによっては変換に失敗する場合があります。

### 変換後のデータをCreate MLで利用

1. 適当なフォルダを作成し、以下を格納します:
    - 変換したJSON
    - アノテーション対象の画像
2. フォルダをCreate MLのTraining Dataとしてアップロードすればトレーニング可能です。

### AppleのAnnotation JSONフォーマット

公式ドキュメント:  
[Building an Object Detector Data Source](https://developer.apple.com/documentation/createml/building-an-object-detector-data-source)

<br><br>
必要な方の参考になれば幸いです！
ポイントスケールの定規PDFを作る 

# はじめに

PDFの内部単位はポイント（DTPポイント：1/72 inch）です。

PDF帳票の生成や解析などをするときに、ポイント単位の定規があると便利です。

売ってないかなと思って探してみましたが、見つけるのが面倒なので定規PDFを生成してプリントアウトすることにしました。

# 環境

Python3 + reportlab を選びました。

# くふうしたところ

A4の長辺方向は297mmですが、できれば300mm欲しいところです。

そこで、定規の絵を斜めに描くことで、30cmの定規を作ります。

折って両面使えるようにします。

4辺使えるようになるので、おまけで mm と inch のスケールも描きます。

換算表としても使えますね。

12inch（約305mm） がギリギリ収まるのでその長さにします。

斜めだと折るときにズレやすいので、目印も描きます。


# プログラム

```createPointRulerPdf.py
# 
# ポイントスケールの定規PDFを作る 
# 
# Python 3 (tested 3.12.7)
# reportlab-4.2.5
#
from reportlab.pdfgen import canvas
from reportlab.lib.pagesizes import A4, portrait
import os

# ファイル名
file = "PointRuler.pdf"
# パスをデスクトップにする
file_path = os.path.expanduser("~") + "/Desktop/" + file

# A4の新規PDFファイルを作成
page = canvas.Canvas(file_path, pagesize=portrait(A4))

# 回転など
page.rotate(-31)
page.translate(40, 82) 

page.setStrokeColorRGB(0.0, 0.0, 0.0)
page.setFont("Helvetica", 9)

# 中心線
page.setLineWidth(0.1)
page.line(0,0,0,860)

w1 = 72 # 定規幅
w2 = 36 # ↑の半分
mt = 8  # テキスト位置
m1 = 5  # 目盛(短)
m2 = 10 # 目盛(長)

# 主目盛
page.setLineWidth(0.5)
# 10ptごと
for i in range(0,860+1,10) :
    page.line(-w2,i,w2,i)
    page.drawString(mt, i, str(i))
    page.drawRightString(-mt, i, str(i))

# 10mmごと
for i in range(0,300+1,10) :
    y = i*72/25.4
    page.line(w2,y,w1,y)
    page.drawRightString(w1-mt, y, str(i))

# 1inchごと
for i in range(0,12+1) :
    y = i*72
    page.line(-w2,y,-w1,y)
    page.drawString(-w1+mt, y, str(i))

# 副目盛
page.setLineWidth(0.25)
# 5ptごと(5,15,25...)
for i in range(5,860,10) :
    page.line(-m1,i,m1,i)

# 1mmごと
for i in range(0,305+1) :
    y = i*72/25.4
    page.line(w1-m1,y,w1,y)

# 5mmごと(5,15,25...)
for i in range(5,305+1,10) :
    y = i*72/25.4
    page.line(w1-m2,y,w1,y)

# 1inchごと
for i in range(1,120) :
    y = i*7.2
    page.line(-w1+m1,y,-w1,y)

# 5inchごと(5,15,25...)
for i in range(5,120,5) :
    y = i*7.2
    page.line(-w1+m2,y,-w1,y)

# 折り曲げ目印
y = 430
a = 300
b = 30
page.line(-a-b,y,-a+b,y)
page.line(-a,y+b,-a,y-b)

page.line(a-b,y,a+b,y)
page.line(a,y+b,a,y-b)

# 保存
page.save()
```

キャンバスをまるごと斜めにしているので、定規を描画するところでは斜めを意識せず描画できます。

# できあがり

完成PDFを添付しようと思いましたが、Qiitaでは画像以外は置けません。

コレを必要としている方は上記プログラムを動かせると思うので、作ってみてください。

一応、画像だけ置いときます。

![PointRuler.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104360/78029e8d-76f6-abf9-2814-34a1d972485a.png)

# おわりに

ポイントスケールの定規PDFを作ってみました。

間取り図面の縮尺が1/60だったりします。レイアウトを検討するにあたり三角スケールを買いたいところですが、使用頻度を考えると地味に高いです。

このプログラムを応用すれば、お好みの尺度の定規が作れますね。
新卒エンジニアを２ヶ月経験しての反省

# はじめに
新卒エンジニアとしての初めての2ヶ月を振り返り、技術的なスキルやマインドセットの反省点を整理しました。これを通して、次のステップに進むための糧にしていきたいと思います。

## 技術力の振り返り

### JavaScript・TypeScriptの基礎力不足
JavaScriptやTypeScriptを仕事で使う中で、基本的な文法や設計パターンの理解が十分でない場面が多々ありました。例えば、Promiseや非同期処理の実装、型定義の深い理解がまだ甘いと感じています。  
これらの知識はコードの可読性や保守性にも影響を与えるため、以下のように改善していきたいです。
- ドキュメントや公式リファレンスを継続的に読む
- 個人プロジェクトで積極的にTypeScriptを活用

### エンティティとユースケースの理解不足
業務で扱うドメインモデル（エンティティ）やユースケースを正しく理解する重要性を痛感しました。特に、クリーンアーキテクチャの考え方を実践する中で、エンティティとユースケースの役割を混同する場面がありました。  
改善のためには、以下のアクションを取ります。
- クリーンアーキテクチャやDDDの書籍を読む
- 小さなシステムを自作して、エンティティ・ユースケースの設計を練習する

## 人間力の反省

### 自由度の高さと自己管理の重要性
私の会社はフレックス制で、比較的自由な働き方ができます。しかし、新卒エンジニアとしてこの環境にいると、自己管理能力の不足が浮き彫りになります。例えば、出社時間を遅めに設定してしまい、結果として集中できる時間が少なくなる日もありました。  
今後は、以下のような取り組みをしていきます。
- 朝型の生活を心がける（早めに出社して集中時間を確保）
- 没頭できる環境を自ら作る努力をする

自由は働きやすさに直結しますが、それを活かすには高い自己管理能力が不可欠です。環境に流されず、自分でルールを作り、それを守る意識を持ちたいと思います。

### 先輩への質問と自己解決のバランス
先輩に質問することは効率的ですが、何でもかんでも聞くのは成長の妨げになります。一方で、自分だけで解決しようとして時間を浪費する場面もありました。  
次回からは以下を実践します。
- **質問前のリサーチを徹底**し、それでも解決できなかった場合のみ質問する
- 質問内容をメモしておき、次回以降の学びに活かす

### 時間管理の重要性

作業に時間を測って取り組む重要性を改めて感じました。思考が止まるのは自然なことですが、ダラダラしてしまうのを防ぐためには、意図的に自分を追い込む必要があります。  
- **ポモドーロ・テクニック**など短時間集中の手法を取り入れる
- 作業の見積もりを立てて、進捗を振り返る

## まとめ

この2ヶ月間を振り返り、技術力、マインド、時間管理のいずれにも改善の余地があることが分かりました。次のステップに向けて、以下を目標とします。
1. JavaScript・TypeScriptのスキルアップ
2. 自己管理能力の向上
3. 先輩への質問と自己解決のバランスを意識
4. 時間管理の徹底

新卒の特権である吸収力を活かし、さらに成長していきたいと思います。
【Laravel】－初学者向け　Laravel初期設定について①

今回はLaravelの初期設定について、説明していきたいと思います。

Laravelの初期設定は、以下となります。

* タイムゾーン
* 言語設定
* デバッグバー

# タイムゾーンについて

まずは、タイムゾーンについて設定していきます。

* 以下パスに移動
```
config/app.php
```

* `UTC`を`Asia/Tokyo`に修正

■修正前
```
72行目 `timezone` ⇒ `UTC`,
```


■修正後
```
72行目 `timezone` ⇒ `Asia/Tokyo`,
```

* 英語の`en`を日本語の`ja`に修正
（エラーメッセージなどが出た時に日本語でエラーメッセージが表示できる）

■修正前
```
85行目 `locale`⇒`en`,
```

■修正後
```
85行目 `locale`⇒`ja`,
```


# デバッグバーについて

デバッグバーは、Laravelのホームページに下記を表示させる設定となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929458/261f222f-82bd-03b6-6f48-ca11975d5e5e.png)



* コマンドプロンプトを開き、デバッグバーのインストール
※簡易サーバー（php artisan serve）が動いている場合は停止してからインストールする
※※簡易サーバーの止め方は、「Ctrl＋C」で停止可能
```
composer require barryvdh/laravel-debugbar:^3.7
```

* インストール後、「composer.json」に追記されるため、ファイルの中身を確認
下記が追記されていたらOK！
```
"barryvdh/laravel-debugbar": "3.7",
```

* コマンドプロンプトに戻り、再度簡易サーバー（php artisan serve）を起動
```
php artisan serve
```

* chromeに「http://127.0.0.1:8000」にアクセス
左下にLaravelのアイコンが表示されるため、下記をクリック
![laravel.248x256.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929458/2b3f8d7c-082f-683e-e271-450e8e02af04.png)

Laravelのホームページにデバッグバーが表示されたらOK！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929458/261f222f-82bd-03b6-6f48-ca11975d5e5e.png)


# 補足 デバッグバーの表示切り替え
補足として、下記デバッグバーの説明をいたします。

* 「.env」ファイルの中の「APP_DEBUG=true」を「false」にすると非表示になる


■修正前
```
APP_DEBUG=true
```

■修正後
```
APP_DEBUG=false
```

* 簡易サーバー（php artisan serve）が動いている場合は停止し
再度簡易サーバー（php artisan serve）を起動
```
php artisan serve
```

* chromeに「http://127.0.0.1:8000」にアクセス
左下にLaravelのアイコンが非表示になっていればOK
![laravel.248x256.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929458/2b3f8d7c-082f-683e-e271-450e8e02af04.png)
開発事業部とCS間における良好な関係構築について

# はじめに

こんにちは！

アドベントカレンダー初参加となります、グリーCS歴5年目に突入しましたsea_saltです。
現在はゲームタイトルのCS（二次対応チーム）を担当しています。
日々の業務で感じたことや、自分の考えをご紹介できればと思っていますので、どうぞよろしくお願いします！

今回、「開発事業部⇔CS間での良好な関係構築」についてお話しようと思います。

# ざっくりCSってどんなところ？

CS＝カスタマーサポートの略（カスタマーサービスと略される場合もあります）となり、新規サービスリリース時におけるCSチームの立ち上げや、お客さまの声を開発事業部へお届けしていくなど、
ゲームをご利用いただくお客さまとゲームを作っている開発事業部の橋渡しとなるようなチームです。

私もご利用のお客さまの利便性向上など、お喜びいただけるようなサービス提供に努めるべく日々サポートを行っています。
時にはお客さまから厳しいお声をいただくこともありますが、嬉しいお声をいただけるとついつい涙ぐんでしまったり…CSを担当していてよかったなぁと感じることもたくさんあります♪

本記事では、開発事業部と良好な関係を築くことの重要性、どのようなことを意識できると良いか、という点をテーマに紹介していきます。

# 開発事業部との関係性

お客さまと開発事業部との間に立って業務を行っている我々CSですが、やはり開発事業部との関係性はとても重要だと考えており、理由としては主に以下4つがあります。

**①信頼の向上**
信頼関係が深まることで、情報共有や連携がスムーズに進む

**②効率的なコミュニケーション**
良好な関係があれば、相手の意図を正確に理解しやすくなり、迅速な意思決定やトラブルの解決に繋がる

**③チームワークの強化**
開発事業部とCS、お互い一つになるワンチームとして共通の目標に向かって協力しやすくなる

**④成長と学びの機会**
他者（事業部）との関係を通じて多様な視点やスキルの触れることができ、自分自身の成長にも繋がる

上記4つの要素により、良好な関係を築くことで開発事業部・CSともに一丸となって課題の解決に取り組むことができるようになると考えます。

具体的には、<INS>開発事業部からCSへ積極的に意見を求めてくれるようになる⇒CS観点での意見や提案を事業部側へ連携する⇒お客さま目線での観点が追加</INS>され、より良いサービスを提供することに繋がるのではないでしょうか。

# 良好な関係を築くために

信頼関係を築くために具体的に意識しているポイント・実践していることとしては以下があります。

**・日々の着信するお問い合わせ内容から問題点を洗い出し、開発事業部への問題提起＆改善提案を積極的に行う**
**（お客さまから寄せられるご要望やご意見をまとめて、改善提案に繋げるのも良し）**

**・事業部側が問題に感じていることを把握し、お客さまから寄せられるお問い合わせと関連するものがあれば、そこから紐づけて問題解決に取り組んでみる**

**・不具合が疑われる内容やお客さまの温度感が高いケースなど、気になるお問い合わせを検知したら事業部へ迅速に連携を行う**

事業部側ごとにCSに何を求めているか、どういうことをして欲しいか、というところを読み取る力も必要になる場合もあるかと思います。

簡単なことではあるものの、上記を意識し積極的に事業部と関わっていくことで、自然と関係性が深まっていき信頼関係を築くことができるのではないでしょうか。

私は今後も開発事業部との信頼関係を築いていくことで、お客さまのニーズをより正確に反映したサービス提供（顧客満足度の向上）や、より良い業務の効率化実現に繋げて行きたいと思っています。

# 終わりに
CSの強みはやはりお客さまとの距離が近いというところなので、その強みを活かした提案や行動ができると良いかと思いました。

この記事が何かのお役に立てれば幸いです。
最後まで閲覧いただきありがとうございました！
JSで音声入力【コード・解説付き】


# 音声入力がしたいのだ！

なぜかずんだもん風に喋ってみました。
結構カンタンにできるので、ゆっくり解説するのだ。

＿人人人人人人人人人人人＿
＞ゆっくりしていってね!!＜
￣ＹＹＹＹＹＹＹＹＹＹＹ￣


## インストール

ゆーてもインストールは`yarn or npm`でできるのだ。
今回はReact.js+Typescriptで書いていくのだ！


```
yarn add react-speech-recognition
```

tsはこちらも
```
yarn add @type/react-speech-recognition --dev
```

もし読み込み時に👇のエラーが出た場合は以下も追加すること

```
ReferenceError: regeneratorRuntime is not defined
```
コマンド
```
yarn add regenerator-runtime
```


## コーディング

こんな感じで簡単にコーディングできるのだ！
※必要な箇所だけ抜き出しております。コードと画面で違う箇所がありますがそこはご愛嬌ということで

```tsx
import 'regenerator-runtime'; // エラーが出た場合は最初に読み込みさせる
import SpeechRecognition, { useSpeechRecognition } from "react-speech-recognition";

const {
  transcript,
  listening,
  resetTranscript,
  browserSupportsSpeechRecognition
} = useSpeechRecognition();

const [recordingInput, setRecordingInput] = useState(''); // 出力したいテキスト領域

// 読み込み中のuseEffect。リアルタイムでテキストを出力したい時は必要
useEffect(() => {
  if (listening) setRecordingInput(transcript);
}, [transcript]);


<Button
  disabled={!browserSupportsSpeechRecognition} // ブラウザ非対応の場合はdisabledに
  label={listening ? '入力停止' : '音声入力'}
  buttonColor={listening ? 'is-danger' : 'is-primary'}
  isLight
  onClick={() => {
    if (listening) {
      SpeechRecognition.stopListening(); 
      resetTranscript(); // 入力済みのテキストをリセット
    } else {
      SpeechRecognition.startListening({
        continuous: true, //ユーザーが中断するまで音声入力を実行
      });
    }
  }}
/>

<TextArea
  onChange={(e) => {
    setRecordingInput(e.target.value); // 手直ししたい時に便利かも？
  }}
  value={recordingInput}
  placeholder="音声入力の結果がこちらに表示されます"
/>

```

## 画面表示

ボタンを押すとこんな感じで表示されるのだ！

![スクリーンショット 2024-11-28 190520.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2028663/cc32f1fa-0354-443f-096b-6d0067a1dbb5.png)

許可を押すと音声が入力できるからしゃべってみるのだ！

![スクリーンショット 2024-11-28 190845.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2028663/a7769934-ad86-d391-8cb7-429605cd994e.png)
※「な」と「の」の間にスペースが入ってますが、精度的にはいいカンジ！

停止したい時はボタンを押すのだ！

これを使って色々とできることが増えるので、ぜひ活用してみるのだ！

*********************************
オブジェクティブグループではXの投稿も平日毎日行っています！
IT関連の小ネタや便利技から、日常のアニメ・ゲーム布教なども幅広く投稿してるので、
ご興味のある方は是非フォロー・いいねをお願いします。
https://x.com/obg_ocr
*********************************
Instanaのホスト検索を容易にするTips

こんにちは、去年に引き続き、今年もこちらのAdvent Calendarにエントリさせていただきます、カワノです！よろしくお願いします。

そんなわけで、この記事はInstana Observability Advent Calendar 2024 4日目のエントリになります。

## はじめに
皆さん、インフラストラクチャ・マップ見てますか？数が少ないうちはいいのですが、だんだんと数が増えてくると…「あれ？あのシステムのサーバどこだ？」となってきていませんか？すぐ探せないのは困りますよね。
本記事では、そんなお困り事を少しでも解消するためのTips的な方法をお伝えします。

## カスタム・ゾーンの設定
例えばAWS上のEC2にInstanaを導入した場合、インフラストラクチャマップ上で、そのEC2のAvailability Zone情報を使ってホストをグループ化します。下記の場合はAWS東京リージョン(ap-northeast-1c)が使われていますね。
![スクリーンショット 2024-12-01 17.45.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/cc2bb662-472a-5a72-a0e5-7ed56469a721.png)

このグループをカスタマイズするには、configuration.yaml (デフォルトは /opt/instana/agent/etc/instana) の `com.instana.plugin.generic.hardware` セクション の `availability-zone` を編集することで変更できます。

![スクリーンショット 2024-12-01 17.47.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/f6f7db74-a8cb-e5f9-4fdd-0501cf43ce95.png)

変更はただちに反映されます。この例では「HogeSystem: Tokyo Region」に変わっていますね。
![スクリーンショット 2024-12-01 17.48.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/3b21a604-0db6-7952-9f2e-00164c5af095.png)

このようにしてグループを明示することが可能です。

詳細はこちらを参照ください。
https://www.ibm.com/docs/ja/instana-observability/current?topic=cha-configuring-host-agents-by-using-agent-configuration-file#setting-custom-zones

## Tag と検索機能を組み合わせる
カスタム・ゾーンは、複数設定することはできません。でも、「本番環境/検証環境/開発環境」や「東京リージョン/大阪データセンター」、「サブシステムA/サブシステムB」なんていろんなカテゴライズ、したいですよね？
**そんな時は tags を使ってください。**
カスタムゾーンと同じく、configuration.yamlの `com.instana.plugin.host` セクションにある `tags`を編集することで、その tag を検索キーとして絞り込み表示を行うことができるんです。

![スクリーンショット 2024-12-01 21.16.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/be8bb462-b020-aabe-12d6-cc64fabeb208.png)

例えば、上記のようにtagを設定します。(tagは複数設定できます！)

その上で、検索窓に以下を入力するか、
![スクリーンショット 2024-12-01 21.18.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/d210247c-892f-4b58-a005-ea8edf3788c2.png)

もしくは 右下の「タグ」アイコンから検索したいタグ文字列を入力します。
![スクリーンショット 2024-12-01 21.18.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/4271dea0-a020-3b06-0774-ebfd6464d4a4.png)

そうすると、その tag が設定されたホストのみが抽出して表示されるんです！！
![スクリーンショット 2024-12-01 21.18.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224464/fc681878-0f70-4598-18b0-bb14e6df8322.png)

すごくシンプルですが、使いやすいと思いませんか？
この検索窓は複数の検索項目を入力できるんです。
例えば複数のホストで tag に
 - env=prod
 - env=dev
 - site=tokyo-region
 - site=osaka-datacenter
 - subsystem=a
 - subsystem=b
などと設定しておくと、本番環境(prod)のサブシステムaだけを表示したい時は
 - entity.tag: env=prod
 - entity.tag: subsystem=a
などと検索することで、見たいものだけを抽出してみることができるんです！

あっさりでしたが、こんな感じで簡単にホストの抽出が可能です。
皆さんもぜひ設定してみてください！
Firebaseイベントの登録からBigQueryでのデータ取得まで

## はじめに
[CYBIRD Advent Calendar 2024](https://qiita.com/advent-calendar/2024/cybird) の8日目担当の[@kyorokyoro](https://qiita.com/kyorokyoro)です。
クライアントエンジニアとして開発/運用を担当しております。
7日目は[@shiso_c](https://qiita.com/shiso_c)さんの[「Unity1Weekで使う時短のためのあれこれ」](https://qiita.com/shiso_c/private/42a545c4d8d93f73c30a)でした。

## 概要
アプリ内でユーザーが実行するアクションの中で、サーバーとの通信を伴わないものも多くあります。
例えば、ストーリーを読んだり、特定の画面に遷移したりするユーザーの行動は、直接的なサーバー通信なしで完結します。
しかし、これらの行動もアプリの利用状況を把握するために重要です。

Firebase Analyticsを活用することで、こうしたユーザーの行動をアプリ内で記録し、後でデータ分析に利用することができます。
具体的には、通信を介さないアクションを記録するために、イベントとしてFirebaseにログを送信し、それをBigQueryで分析する方法を取り上げます。

この記事では、Firebaseを用いてユーザーの行動（例: ストーリーの再生）を記録し、BigQueryでそのデータを集計する方法を解説します。

## 1. Firebaseでのイベント登録

Firebaseでイベントを登録することで、ユーザーのアクションをトラッキングし、後で分析することができます。イベント登録は、Firebase SDKを使って行います。

### 1-1. イベントの登録方法
Firebase Analyticsを利用して、アプリ内で発生したイベントを記録します。
たとえば、ユーザーが特定のストーリーを読んだ際に、そのイベントを記録する方法です。

```C#
var parameters = new Parameter[]
{
    new Parameter("story_cd", "xxx")
};
Firebase.Analytics.FirebaseAnalytics.LogEvent("story_read", parameters);
```

---

## 2. BigQueryからのイベントデータ取得（条件付き）

FirebaseとBigQueryを連携させることで、Firebaseで収集したイベントデータをBigQueryで分析できます。
以下は、特定の条件に基づいたデータ取得方法です。

### 2-1. ユーザー数の取得

#### 1. 日付をまたいだイベント実行をしたユニークユーザー数の取得

指定された条件でユニークユーザー数を取得するクエリです。

```SQL
SELECT
  COUNT(DISTINCT user_pseudo_id) AS unique_users
FROM
  `project_id.analytics_XXXXXXXXX.events_*`,
  UNNEST(event_params) AS event_param
WHERE
  event_name = 'story_read'
  AND event_param.key = 'story_cd'
  AND event_param.value.string_value = 'xxx'
  AND _TABLE_SUFFIX BETWEEN '20241201' AND '20241207'  -- 日付範囲を指定
```

#### 2. リピートユーザー数の取得

リピートユーザー数を取得するために、同じユーザーが複数回指定された条件でイベントを実行したかを確認する方法です。
```SQL
WITH user_event_count AS (
  SELECT
    user_pseudo_id,
    COUNT(*) AS event_count
  FROM
    `project_id.analytics_XXXXXXXXX.events_*`,
    UNNEST(event_params) AS event_param
  WHERE
    event_name = 'story_read'
    AND event_param.key = 'story_cd'
    AND event_param.value.string_value = 'xxx'
    AND _TABLE_SUFFIX BETWEEN '20241201' AND '20241207'
  GROUP BY
    user_pseudo_id
)
SELECT
  COUNT(*) AS repeat_users
FROM
  user_event_count
WHERE
  event_count > 1
```

#### 3. 日別のイベント数の取得

日別での集計に関しても、同じ条件を適用した集計方法です。
指定された条件に基づき、イベントが発生した日ごとに、その回数をカウントします。
```SQL
SELECT
  event_date,
  COUNT(*) AS event_count
FROM
  `project_id.analytics_XXXXXXXXX.events_*`,
  UNNEST(event_params) AS event_param
WHERE
  event_name = 'story_read'
  AND event_param.key = 'story_cd'
  AND event_param.value.string_value = 'xxx'
  AND _TABLE_SUFFIX BETWEEN '20241201' AND '20241207'
GROUP BY
  event_date
ORDER BY
  event_date
```

---

## 3. まとめ

この記事では、Firebaseでのイベント登録方法から、BigQueryでのデータ取得方法までを解説しました。
特定の条件に基づいてデータを集計することで、ユーザーの行動を詳細に分析することが可能です。

- Firebaseイベントの登録方法（`story_read`イベントの例）
- BigQueryを使用して、特定の条件（`story_cd = 'xxx'`）に基づくユニークユーザー数、リピートユーザー数、日別イベント数の取得方法

状況に応じてクエリを調整し、アプリのデータ集計に役立ててください。

明日の[CYBIRD Advent Calendar 2024](https://qiita.com/advent-calendar/2024/cybird)  9日目は、[@CN_30371500](https://qiita.com/CN_30371500)さんの「コンピューターの思考」です。
お楽しみに！
ESLintのプラグインのテストを作成する

# はじめに

こんにちは、エンジニアのkeitaMaxです。

前回作成したESLintのテストを作成していきます。

https://qiita.com/keitaMax/items/f6f264194cfdc1f3167f

https://qiita.com/keitaMax/items/8fe4cf652047fe457964

# やりたいこと

以下がエラーになっていて、

```ts
    const a = [1, 2, 3]
    const b = []
    a.map(i => b.push(i))
```

以下がエラーにならない、というようなことを確認するテストを作りたいと思います。

```ts
    const a = [1, 2, 3]
    const b = []
    a.foreach(i => b.push(i))
```
# Jestのインストール

以下コマンドでJestをインストールします。

```
npm install --save-dev jest
npm install --save-dev ts-jest
```

package.jsonに以下を追加します。

```json:package.json
  "scripts": {
    "build": "tsc",
    "test": "jest test/*.ts" // 追加
  },
```
# テスト作成

以下のようにtestフォルダを作成し、`notUsePushInMap.ts`をその配下に作成しました。

```
eslint-plugin-hitasura-system-develop
├─ src
│  ├─ index.ts
│  └─ rules
│     └─ notUsePushInMap.ts
└─ test
   └─ notUsePushInMap.test.ts
```

テストは以下のように記載しました。

```ts:notUsePushInMap.test.ts
const { RuleTester } = require("eslint")
const rule = require("../lib/rules/notUsePushInMap")

const tester = new RuleTester()

tester.run("rule", rule, {
  valid: [
    { code: "const a = [1, 2, 3];const b = [];a.foreach(i => b.push(i))" }
  ],
  invalid: [
    { code: "const a = [1, 2, 3];const b = [];a.map(i => b.push(i))", errors: [{ message: "Do not use push inside a map method." }] }
  ]
})
```

エラーにならないものは`valid`に、エラーになるものは`invalid`に入れてテストを書いています。

# 実行

以下のコマンドでテストを実行します。

```
npm run test 
```

```
% npm run test

> eslint-plugin-hitasura-system-develop@0.0.5 test
> jest test/*.ts

 PASS  test/notUsePushInMap.test.ts
  rule
    valid
      ✓ const a = [1, 2, 3];const b = [];a.foreach(i => b.push(i)) (16 ms)
    invalid
      ✓ const a = [1, 2, 3];const b = [];a.map(i => b.push(i)) (3 ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.019 s, estimated 2 s
Ran all test suites matching /test\/notUsePushInMap.test.ts/i.
```

テストが成功しているのがわかります。

# おわりに

この記事での質問や、間違っている、もっといい方法があるといったご意見などありましたらご指摘していただけると幸いです。

最後まで読んでいただきありがとうございました！

# 参考

https://jestjs.io/ja/docs/getting-started

https://github.com/mysticatea/eslint-plugin-node/blob/master/tests/lib/rules/exports-style.js

# 次の記事
受け身の採用・技術広報として

## はじめに
株式会社リブセンスで「採用広報」を、特に任命されたわけでもなくやっている iwtn です。普段は転職ドラフトの開発・運営をしています。
なので、採用にかっちりコミットするわけでもなく、テックブログのレビュー・運営や社外に発信をする際に技術的な観点からのサポートするなど、採用・技術広報のような役割をやんわりとやっています。

2024年ももう終わりということで今年一年を振り返ってみますと、様々な分野で広報活動が取り沙汰された一年でしたね。
昨今、少し過熱気味に思える広報の活動とその役割について、どちらかといえば個人的には受け身のスタンスなので、そのあたりについて書いてみました。

## 受け身で広報になるのか？

広報、PR、すなわちパブリックリレーションズ（Public Relations）。
言葉の意味をそのままとると、**公との関係を上手く取り持つ**感じでしょうか。

そもそも公（おおやけ）とはなんぞや、みたいな話もあるのですが、ここでは「世間一般」ぐらいの意味になります。企業やその中の人は、社会の中の一つの構成要素として活動していて、企業と世間一般とのコミュニケーションを上手くやる、ぐらいが「広報」の役割かなと思っています。

広報を「広く報せる」とすると、どうしても「知らしめる」「認知させる」ことになってしまい、強めのアピールが必要になる感じがします。
しかし、特に知名度がそもそも高くない企業だと、認知をとるために広告へ多額のコストを割くことになります。
人の認知できる量は増えないので、結果として競争が激しくなりがちです。
そのため内容も過激化しやすく……と某SNSで起こっているようなことになるわけですね。

なので個人的なスタンスとして、**社会に対して企業の中の一部を覗けるような窓を開けておく**、ような感覚でテックブログの運営をしています。
入社してみるまでは実際の様子はわからないですが、できるだけ正直に情報を公開しておこう、という感じですね。

以下の記事にあるような採用ファネルの「認知」をとっていくのは、情報量が過多になっている昨今では過当競争になりやすいので、**応募や選考まで進んでくれた方々に適切な情報を渡せる準備をしておく**イメージです。

![記事より引用](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/16864/c78a8f32-d482-4410-e3c0-fffefbda329f.png "記事より引用")
※[採用ファネルを意識すると、テックブログの記事は書きやすくなるのでは？という話](https://made.livesense.co.jp/entry/2023/12/09/090000)より引用

https://made.livesense.co.jp/entry/2023/12/09/090000

採用のミスマッチをやんわりと減らす効果ぐらいはあるんじゃないかなぁ、と思っています。興味を持ってくれた人に対して、こういうのもあるよ、別のもあるんだよ、と情報提供する感じです。

また、息切れしないように継続していくと記事がストックされ、歴史の記録として機能しはじめます。これは自分の記憶を裏打ちしてくれる材料にもなり、新しく入社してくれた人への過去の活動の紹介にもなるので、むしろ広報というよりは自身や社内のためになります。

「広く報せる」ことはできないかもしれませんが、情報を公開しておくことの価値はあると思っています。

## 広報する対象をよく見る

転職ドラフトのデータを元に、以下のような2つの記事が先月の中頃に公開されました。

https://made.livesense.co.jp/entry/2024/11/18/083000

https://made.livesense.co.jp/entry/2024/11/18/083100

特に上の「転職ドラフトの指名承諾率分析 - 提示年収を上げれば承諾されるのか -」で示されていることは、**スカウトを送った際に転職を考えている人はレジュメを読んでくれているかをとても重要視している**ということです。自分を知ってくれようとしているかが伝わると、スカウトに対して「まずは会ってみよう」となる可能性が高くなるわけですね。これは特に「採用広報」という立場で大事なことだと思っています。

広報という仕事はどちらかといえば「こちらを見てもらう」ことを重視する仕事です。
しかし、意中の相手を振り向かせるには、相手のことをよく知る必要がある、とけっこう当たり前のことを示しているわけでもあります。
しっかりと書き込まれたレジュメを読み込むのは大変な作業ですが、その分効果もあるのが数字で出ています。

## なぜノベルティは捨てられやすいのか

転職ドラフトは様々な技術カンファレンスにスポンサーをして、ブースを出しています。
そこで配るためのノベルティを作るのですが、先日このような記事がでておりました。

https://www.nikkei.com/article/DGXZQOUD117CZ0R11C24A0000000/

一時、技術カンファレンスなどでのノベルティは不要だ、のような主張もネット上で散見され、個人的にも同意できる点は多いです。

サービスや企業の中でその運営・広報をしている人は、もちろん愛着があるのでノベルティが欲しくなりますし、作れるので作ります。しかし、**それを受け取る人がどれぐらいそれを欲しがるのか、という観点が往々にして抜ける**ことがあります。私も欲しがられないノベルティをいくつも作ってきました。

なのでノベルティ作りは、アピールする対象のことも考え、受け取る人のことも考え、作る人のことも考える、となって難しくなります。
しかし、喜んで受け取ってくれる人もいたりしてそういうときは嬉しいですよね。なんとか上手くやっていけないかなぁと毎回頭を捻っています。

## まとめ

つらつらと書いてきましたが、個人的に押せ押せでいくよりは、全体の状況や対象をよく見て、関係者みんなが嬉しい広報活動を行っていければなぁと思います。
とはいえ、積極的にアピールしていくことも必要なタイミングや状況もあると思うので、そのときはそのときで頑張っていければなぁと考えております。
トナカイの動き方を思い出す、クリスマスシーズンなので

## 概要
12月はクリスマスシーズンですね。おおよそ温帯に属する日本では、トナカイを見かけることは少ないと思います。とはいえ、サンタクロースとして稼働する可能性もあるので、トナカイはどのような動きをするか、思い出しておきましょう。

## トナカイとは
https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%8A%E3%82%AB%E3%82%A4

（特に生物の）概要をつかむのに、Wikipediaの記事はとっかかりとしては悪くないと思います。偶蹄目シカ科トナカイ属の種ということなので、馬よりは鹿に近いのでしょうか。分布の項は北極圏周辺とのことで、どうりで日本では見かけません。

さて、生物の分布の状況は実際どうなのか、専門のサイトがあるようなので、そちらでも確認してみます。より細かく分けた種もあるようですが、記事からトナカイと言えば種名はRangifer tarandusのようなので、この種名でGBIF（地球規模生物多様性情報機構）を調べます。

https://www.gbif.org/species/5220114

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/580614/8a4b7887-5f03-6b56-f743-78e0c73527dd.png)

アメリカ大陸では多少南にも位置しているようですが、おおよそ北極圏周辺ですね。

## 動物の歩行、馬の例
もっと身近な動物であるところの、馬の場合はどのように動くのでしょうか。それをまとめた記事があるようです。

https://ja.wikipedia.org/wiki/%E6%AD%A9%E6%B3%95_(%E9%A6%AC%E8%A1%93)

ざっというと、常歩・速歩・駈歩・襲歩が遅い順での基本的な歩行方法のようです。この後文献を調査するにあたり、必ずしも日本語のものがあるとは限らないので、それぞれの用語を英語でメモしておきます。英語版を確認すると、

|  日本語   | 英語    |
| --- | --- |
| 歩法    | gait    |
| 常歩  | walk    |
| 速歩    | trot    |
| 駈歩    | canter    |
| 襲歩    | gallop    |

のように対応します。

## トナカイの歩行
さて、キーワードが拾えたので、文献を探します。Wikipedia記事に記述があれば良さそうですが、あまり詳しくは書いてありませんでした。en版はja版よりもよっぽど詳しいですが、雪や沼で歩行しやすいような蹄になっている、といったくらいの記述でした。

ざっと調べたところ、次が見つかりました。
Li G, Zhang R, Han D, Pang H, Yu G, Cao Q, Wang C, Kong L, Chengjin W, Dong W, Li T, Li J. Forelimb joints contribute to locomotor performance in reindeer (Rangifer tarandus) by maintaining stability and storing energy. PeerJ. 2020 Nov 11;8:e10278. doi: 10.7717/peerj.10278. PMID: 33240627; PMCID: PMC7666566.

https://pmc.ncbi.nlm.nih.gov/articles/PMC7666566/

飼育しているトナカイを使用し、センサーを付けたデータ収集エリアを歩行するように訓練した（成功した）個体を調査したようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/580614/888e8207-14ea-b0c6-bfc5-40b71ea44da2.png)

後述の関節の動きを得るために、商用のマーカーレスなモーショントラッキングシステム（Simi Motion 2D/3D）を利用しています。

## 脱線、動物の関節推定
商用のシステムもありますが、動物をモーショントラッキングするタスクに対してオープンなデータセットもあるようです。

https://www.mackenziemathislab.org/deeplabcut

例えばここの、Horse-10はウマの動きとそのアノテーションのデータセットです。（https://huggingface.co/datasets/mwmathis/Horse-30）

PaperWithCodeにリーダーボードもあるので、参考にして自前でモデルをトレーニングしたり、実装例を試したりできそうです。（https://paperswithcode.com/sota/animal-pose-estimation-on-horse-10）
タスクのカテゴリーとしては「Animal Pose Estimation」というのがありました。

## 論文に戻る


足の運びとスピードから、walk,trot1,trot2に分類しています。
この論文では、関節の動きと地面の反力から、トナカイの持つ運動特性がどのように達成されているか調べています。どうやら、トナカイは他の有蹄類よりも、歩行時の関節角度が安定していて、効率的に歩行時のエネルギーを関節に貯蔵・吸収できているようです。
トナカイの動き方に戻ると、足の運び方のパターンを見るに、馬でいうところの速歩に相当する足運びをして移動するようです。ウマでは、速歩のときに動き始めてから徐々に手首関節の角度が180°前後から閉じていきますが、トナカイの手首関節は、歩行中に角度が一定でした。足関節が柔軟性よりも安定性に寄っていることで、長距離移動により適しているとのこと。つまり動き方としては、馬のような足運び、そして各関節の動きはより少ない、ちょっと固い動き方をする、と言えるでしょう。

## 結論

トナカイは、

- 不整地（雪や沼）の移動、かつ長距離移動に特化
- ウマのような常歩や速歩で移動、関節はウマよりも固い

という動き方をします。

今回は以上です。
ファイル転送プログラムsioload.pyをLLMを使ってunirom8対応にする

## はじめに
　初代プレステのシリアルポート経由でプログラムを転送する場合、プレステ上のunirom8とwindows上のnos.exeを組み合わせて用いるのが一般的です。
　MacOSやLinux上では、monoを使ってnops.exeを動かすようです。

https://github.com/JonathanDotCel/NOTPSXSerial

　ファイル転送元をMCU搭載の小さなボードにしたい場合、windowsの実行ファイルよりはpythonプログラムの方が適しています。
　しかし、転送プログラムのsioload.pyやpypsxserial.pyとunirom8の組み合わせでは、ファイル転送できません。
　本稿では、sioload.pyを修正してunirom8との間でのファイル転送を実現した話を紹介します。
　本稿の内容には、「東海道らぐの万鹿博覧会ライトニングトーク大会 in 大阪南港」と「Unagi.py 勉強会61枚目 (Python勉強会in浜松市)」の発表内容が含まれます。

https://tokaidolug.connpass.com/event/334044/

https://pycon-shizu.connpass.com/event/337544/

## sioload.py
　sioload.pyは「sioloader v1.0」に含まれているpythonプログラムで、SIOLOAD.EXEの起動しているプレステにファイル転送する機能をもっています。SIOLOAD.EXEに対しては1036.8 kbpsの転送速度で、PSXSEIAL.EXEやUNIROM.EXEに対しては、115.2 kbpsの転送速度でデータを送ることが可能です。

https://github.com/danhans42/sioload

## 転送実験とsioload.pyの修正
　Unirom8の起動しているプレステに対して、sioload.pyを使ってファイル転送を試みます。
　ファイル転送が始まると、プレステの画面に「DOWNLOADING.EXE…」が表示されますが、sioload.pyから転送した場合、画面表示も変わりません。nops.exeでは、「SEXE」　という文字列を送ることで、unirom8側がファイル受信状態になります。
　sioserial.pyを「SEXE」を送ってからファイル転送する用修正したプログラムで転送を行いました。
「DOWNLOADING.EXE…」が表示されましたが、「CHECKSUM ERROR」が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693019/9c1d7b28-841f-9f27-bde2-fd89d67335f0.png)


```
DOWNLOADING .EXE…

CHECKSUM ERROR: CHECK YOUR CABLES!
EXPECTED: 0 CALCED: 1A3570
```
　LLMを利用して、チェックサムエラーの修正を試みますが、通り一遍のチェックサムエラーの回避法しか提案してくれません。unirom8のソースファイルは公開されていません。
　解決法が見つからないのでDISCORDのPSXDEVで相談したところ、nops.exeのソースファイルを参照するようにアドバイスを受けました。
　githubのリポジトリを見ると、「TransferLogic.cs」に転送の段取りが記載されているようですので、LLMにファイルをアップロードして解説してもらいました。
　2番目に、修正したい「sioload.py」をアップロードして、 「TransferLogic.cs」の転送の段取りを追加させるよう、LLMに指示しました。
　生成された修正後の「sioload.py」の動作を確認しました。以下は、windowsのコマンドプロンプトです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693019/cd20885a-e241-18a0-d7f9-1628e82aa123.png)

以下は、プレステの画面です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693019/795f7ebf-2d65-9305-7217-08a0c5b1613c.png)

　ファイル転送に成功し転送したプログラムが動作しましたが、エラーが出ています。
　エラーメッセージをLLMに伝えて、プログラムを修正させました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693019/289e41c3-6e19-c7ce-46e0-12db98040e37.png)

　エラーがでなくなりました。

## おわりに
　LLMを使ってプレステ用のファイル転送pythonプログラムのsioload.pyを修正しました。
　LLMを使ってプログラムを修正する場合、参照するプログラムの提示後の解説をさせることにより、精度よく修正ができるようです。プログラムが表示するエラーメッセージを伝えることも、精度良く修正する際に重要だとわかりました。
外部キー制約の親テーブルのレコードを削除したい！

## はじめに
HRBrain Advent Calendar 2024 7日目の記事です
こんにちは。イナです。
外部キー制約の親テーブルのレコードを削除したい！となったときの削除方法についてまとめました。

## そもそも外部キーとは
1. 社員と部署情報を管理したい
![スクリーンショット 2024-12-03 18.46.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3472415/34712173-38ce-ea67-2fad-5674284c1791.png)


2. 社員はどこかしらの部署に所属しているか分かるようにしたい
![スクリーンショット 2024-12-03 18.45.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3472415/8bdb88e1-265a-1dd7-bd71-e8bb820d5a94.png)

このときの部署IDが外部キー（FOREIGN KEY）になります。
外部キーとして部署のIDを紐づけておくことで、情報を辿れるようにしています。

## 外部キー制約とは
1. これから頑張るぞ！
![スクリーンショット 2024-12-03 18.49.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3472415/034b47ad-01ff-592f-7c59-ddbf4c5ed3b3.png)

2. 開発部署なくなっちゃった
![スクリーンショット 2024-12-03 18.49.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3472415/c389f080-c001-0018-082d-f515097e0bc4.png)

3. 花子さんの部署どこだろう。IDは2か。つまり、どこ!?
![スクリーンショット 2024-12-03 18.49.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3472415/3f72cbfb-e508-2389-4c2a-30c69697e4c2.png)

上記のようなケースを防ぐために、どこのテーブルのどこのIDと紐づけているかを定義してあげるのが外部キー制約です。
外部キー制約をしておけば、デフォルトだと2の段階でエラーが出るようになります。

## じゃあ、消したいときにどうすればいいの？
基本的な方法としては、以下の2つかと思います。
どちらも、親テーブルのレコードを削除する前に処理をします。

### 子テーブルのカラムをNULLにしてから削除する
__レコードは消したくない__ ときに使用します。
```sql
UPDATE 社員 SET 部署ID = NULL WHERE 部署ID = 2;
DELETE FROM 部署 WHERE ID = 2;
```

### 子テーブルのレコードを削除する
__レコードごと消したい__ ときに使用します。
```sql
DELETE FROM 社員 WHERE 部署ID = 2;
DELETE FROM 部署 WHERE ID = 2;
```

## 余談
ちなみに、外部キー制約のON DELETEのoptionで外部キーが削除されたときの動作を指定できます。
CASCADEは制約のある子テーブルのレコードをすべて削除し、SET NULLは制約のある子テーブルのレコードのカラムにNULLをセットします。
しかし、こういった設定は意図しない動作になりやすいため、 __基本的にデフォルトのままで削除時に処理をするのが望ましい__ のかなと思っています。（デフォルトではRESTRICTやNO ACTIONに設定されており、外部キー制約が適用されるものは削除しようとしたら拒否するようになっています。）

## 終わりに
今回は外部キー制約の削除方法についてまとめました。
どんなコードでもですが、意図しない動作は怖いですね...
物理削除は取り返しのつかないものなので、CASCADEやSET NULLを使う！というときは慎重に検討したいです。

## PR
良い記事が続々投稿予定ですので、弊社のAdventCalendarもぜひご覧ください。
https://qiita.com/advent-calendar/2024/hrbrain

株式会社HRBrainでは、一緒に働く仲間を募集しています。
興味を持っていただいた方は、ぜひ弊社の採用ページをご確認ください。
HRBrain文化を一緒に作っていきましょう！

www.hrbrain.co.jp