2024年8月28日

コードブロックテスト

const acoustypeAscii = `
     _                          _                    
    / \\   ___ ___  _   _ ___   | |_ _   _ _ __   ___ 
   / _ \\ / __/ _ \\| | | / __|  | __| | | | '_ \\ / _ \\
  / ___ \\ (_| (_) | |_| \\__ \\  | |_| |_| | |_) |  __/
 /_/   \\_\\___\\___/ \\__,_|___/   \\__|\\__, | .__/ \\___|
                                   |___/|_|         
`;

console.log(acoustypeAscii);

2024年8月27日

docker php-fpmコンテナ設定の読込順番

www.confとzz-docker.confの両方が読み込まれる場合、後で読み込まれる設定ファイルが前の設定ファイルの設定を上書きします。

読み込み順と上書きの動作

www.conf: 通常、www.confはPHP-FPMのプール設定ファイルとして最初に読み込まれます。このファイルには、PHP-FPMの動作に関する基本的な設定が含まれています。
zz-docker.conf: 名前にzzが付いているため、一般的には後から読み込まれます。設定ファイルは通常アルファベット順に読み込まれるため、zz-docker.confが最後に読み込まれることになります。

上書きの例

www.confでlisten = 127.0.0.1:9000が設定されていても、zz-docker.confでlisten = 9000が設定されている場合、zz-docker.confの設定が最終的に適用されます。

設定が上書きされる際の注意点

後から読み込まれる設定ファイル（この場合はzz-docker.conf）に記載されている設定項目は、それ以前に読み込まれた設定ファイル（www.confなど）の対応する項目を上書きします。
これにより、特定の環境（例えば、Dockerコンテナ内）で必要な設定を、グローバル設定とは別に調整することができます。

結論

www.confが先に読み込まれ、その後にzz-docker.confが読み込まれる場合、zz-docker.confに記載されている設定は、同じ設定項目がwww.confに存在していたとしても上書きされます。この仕組みを利用して、環境に応じた設定の調整を行うことができます。

2024年8月24日

GoogleウォレットにクレジットカードをVisaタッチ決済として登録したいがiDとして登録されてしまう

Android携帯でGoogleウォレットにクレジットカードをVisaタッチ決済として登録する際に、iDとして登録されてしまう場合、以下の手順を試してみてください。
Vpassアプリを使用する: Visaのタッチ決済を設定するには、Googleウォレットアプリではなく、Vpassアプリを使用してください。Googleウォレットアプリから設定すると、iDが設定されることがあります。
デバイスの要件を確認する: 使用しているAndroidデバイスがNFC Type A/Bに対応しているか確認してください。Visaのタッチ決済は、Android 5.0以降でNFC Type A/Bが搭載されているデバイスでのみ設定可能です。
カードの選択を確認する: Vpassアプリで設定する際に、Visaのタッチ決済に対応しているカードを選択してください。対象外のカードを選択していると、設定がうまくいかないことがあります。
アプリとデバイスを最新に保つ: GoogleウォレットアプリとVpassアプリを最新のバージョンにアップデートし、デバイスのOSも最新の状態に保ってください。
これらの手順を試しても問題が解決しない場合は、カード発行会社に問い合わせて、詳細なサポートを受けることをお勧めします。

2024年8月22日

MySQLのcollation(コレーション)について

utf8mb4_general_ci、utf8mb4_unicode_ci、utf8mb4_unicode_520_ciの違いと、日本語のデータを扱う際にどれを選ぶべきかについて説明します。

1. utf8mb4_general_ci

特徴: 照合順序が比較的単純で、速度を重視していますが、一部の特殊文字の比較が正確ではない場合があります。多くの言語で十分に使用できますが、アクセントの違いや特殊な文字区別に関しては不正確です。
メリット: パフォーマンスが良い。
デメリット: 精度が低く、日本語の正確な並び替えには適していません。

2. utf8mb4_unicode_ci

特徴: Unicode標準に基づいた照合順序で、言語特有の文字を正確に処理します。多言語対応であり、日本語も適切に処理できます。
メリット: 幅広い言語に対応し、正確な文字比較が可能。
デメリット: 一部の新しいUnicode文字はサポートされていない場合があります。

3. utf8mb4_unicode_520_ci

特徴: Unicode 5.2.0標準に基づいており、utf8mb4_unicode_ciよりも新しいバージョンです。これにより、より多くのUnicode文字や最新の言語サポートが追加されています。
メリット: より正確な文字比較と新しいUnicode文字のサポート。
デメリット: utf8mb4_unicode_ciよりも若干のパフォーマンス低下がある場合がありますが、通常は無視できる程度です。

日本語データを扱う場合の選択

日本語を扱う場合は、utf8mb4_unicode_ciまたはutf8mb4_unicode_520_ciを使用するのが最適です。どちらも日本語の文字を正確に扱えますが、特に将来的な互換性や新しいUnicode文字のサポートを考慮するなら、utf8mb4_unicode_520_ciを選ぶのが良いでしょう。

結論

一般的なパフォーマンス重視: utf8mb4_general_ci
高い互換性と正確性: utf8mb4_unicode_ci
最新のUnicode対応と正確性: utf8mb4_unicode_520_ci（推奨）

utf8mb4_unicode_520_ciを選択すれば、日本語の文字の正確な比較や並び替えに対応できます。

`utf8mb4_ja_0900_as_cs` と `utf8mb4_ja_0900_as_cs_ks`

utf8mb4_ja_0900_as_cs と utf8mb4_ja_0900_as_cs_ks は、MySQL 8.0以降でサポートされている、日本語に特化した照合順序（コレーション）です。これらはUnicode 9.0に基づいており、日本語の特性を考慮した照合を行います。

各照合順序の意味

utf8mb4_ja_0900_as_cs
- ja: 日本語に特化した照合順序であることを示しています。
- 0900: Unicode 9.0に基づいていることを表します。
- as: 「Accent Sensitive（アクセントを区別する）」の略。アクセントの違いを考慮して文字を比較しますが、日本語ではアクセントの概念はあまり重要ではないため、実質的に大きな影響はありません。
- cs: 「Case Sensitive（大文字小文字を区別する）」の略。文字の大文字と小文字を区別します。
utf8mb4_ja_0900_as_cs_ks
- ks: 「Kana Sensitive（仮名を区別する）」の略。カタカナとひらがなを区別します。例えば、「あ」と「ア」を異なる文字として扱います。

適用シーン

utf8mb4_ja_0900_as_cs: 大文字小文字を区別した比較を行いたいが、カタカナとひらがなを区別しない場合に使用します。
utf8mb4_ja_0900_as_cs_ks: 大文字小文字の区別に加えて、カタカナとひらがなも区別したい場合に使用します。

日本語データを扱う場合の選択

日本語を扱う際に、カタカナとひらがなを区別する必要がある場合は、utf8mb4_ja_0900_as_cs_ksが適しています。一方、カタカナとひらがなを区別しない場合は、utf8mb4_ja_0900_as_csを選択します。

結論

日本語データの精密な処理が必要な場合、これらの照合順序を選ぶとよいでしょう。例えば、ユーザー名の重複確認で「さくら」と「サクラ」を区別したい場合は、utf8mb4_ja_0900_as_cs_ksを使用します。より柔軟な運用を求める場合は、utf8mb4_ja_0900_as_csを選ぶのが適切です。

utf8mb3とは

utf8mb3: utf8mb3はMySQLの古いバージョンのUTF-8エンコーディングで、最大3バイトの長さの文字をサポートします。実際には、基本的なマルチバイト文字（例えば、ラテン文字、ギリシャ文字、キリル文字、漢字など）をサポートしていますが、絵文字などの4バイト文字はサポートしていません。

2024年8月4日

サーム・ルール

サーム・ルールは、米国の元連邦準備制度理事会（FRB）のエコノミストであるクローディア・サーム氏が提唱した景気後退の早期警戒指標です。このルールは以下のように定義されます：

直近3ヶ月の失業率：最新の3ヶ月間の失業率の平均を計算します。
過去12ヶ月で最も低かった失業率：過去12ヶ月間の失業率のうち、最も低かった値を特定します。
差を計算：直近3ヶ月の失業率の平均から過去12ヶ月で最も低かった失業率を引きます。

この差が0.5パーセントポイントを上回る場合、景気後退の確率が高いとされます。サーム・ルールは、景気後退の初期段階での警戒を促すために設計されており、失業率が急激に上昇することが景気後退の予兆であると仮定しています。

サーム・ルールの適用例

例えば、直近3ヶ月の失業率が6%、過去12ヶ月で最も低かった失業率が5.4%であった場合：

直近3ヶ月の失業率 = 6%
過去12ヶ月で最も低かった失業率 = 5.4%
差 = 6% - 5.4% = 0.6%

この場合、差が0.5を上回るため、サーム・ルールに基づくと景気後退のリスクが高いと判断されます。

サーム・ルールはシンプルで分かりやすいため、政策立案者やエコノミストにとって有用なツールとなっています。

2024年7月24日

1TBのファイルのコピー時間(USB HDからPCへ)

1TB（1テラバイト）のデータをUSBからHD（ハードディスク）にコピーする場合の時間を、各USB規格に基づいて以下に示します。実際の速度は理論値よりも低くなることが多いため、実際の転送時間はこれよりも長くなる可能性があります。

USB2.0

理論的最大転送速度: 480 Mbps (約60 MB/s)
実際の転送速度: 約40 MB/s

1 TB = 1,000,000 MB 転送速度が40 MB/sの場合:

転送時間=1,000,000 MB40 MB/s=25,000 秒\text{転送時間} = \frac{1,000,000 \text{ MB}}{40 \text{ MB/s}} = 25,000 \text{ 秒}転送時間=40 MB/s1,000,000 MB=25,000 秒

25,000 秒 ≈ 6.94 時間

USB2.0でのデータ転送時間: 約7時間

USB3.0

理論的最大転送速度: 5 Gbps (約625 MB/s)
実際の転送速度: 約200〜400 MB/s（ここでは300 MB/sで計算）

1 TB = 1,000,000 MB 転送速度が300 MB/sの場合:

転送時間=1,000,000 MB300 MB/s=3,333.33 秒\text{転送時間} = \frac{1,000,000 \text{ MB}}{300 \text{ MB/s}} = 3,333.33 \text{ 秒}転送時間=300 MB/s1,000,000 MB=3,333.33 秒

3,333 秒 ≈ 55.56 分

USB3.0でのデータ転送時間: 約56分

USB3.1

理論的最大転送速度: 10 Gbps (約1.25 GB/s)
実際の転送速度: 約800〜1,000 MB/s（ここでは900 MB/sで計算）

1 TB = 1,000,000 MB 転送速度が900 MB/sの場合:

転送時間=1,000,000 MB900 MB/s=1,111.11 秒\text{転送時間} = \frac{1,000,000 \text{ MB}}{900 \text{ MB/s}} = 1,111.11 \text{ 秒}転送時間=900 MB/s1,000,000 MB=1,111.11 秒

1,111 秒 ≈ 18.5 分

USB3.1でのデータ転送時間: 約18.5分

USB3.2

USB3.2には複数のバージョンがありますが、以下のように計算します。

USB3.2 Gen 1x1 (USB3.0と同じ)

理論的最大転送速度: 5 Gbps (約625 MB/s)
実際の転送速度: 約400〜500 MB/s（ここでは450 MB/sで計算）

1 TB = 1,000,000 MB 転送速度が450 MB/sの場合:

転送時間=1,000,000 MB450 MB/s=2,222.22 秒\text{転送時間} = \frac{1,000,000 \text{ MB}}{450 \text{ MB/s}} = 2,222.22 \text{ 秒}転送時間=450 MB/s1,000,000 MB=2,222.22 秒

2,222 秒 ≈ 37 分

USB3.2 Gen 1x1でのデータ転送時間: 約37分

USB3.2 Gen 2x2

理論的最大転送速度: 20 Gbps (約2.5 GB/s)
実際の転送速度: 約1,500〜2,000 MB/s（ここでは1,800 MB/sで計算）

1 TB = 1,000,000 MB 転送速度が1,800 MB/sの場合:

転送時間=1,000,000 MB1,800 MB/s=555.56 秒\text{転送時間} = \frac{1,000,000 \text{ MB}}{1,800 \text{ MB/s}} = 555.56 \text{ 秒}転送時間=1,800 MB/s1,000,000 MB=555.56 秒

556 秒 ≈ 9.3 分

USB3.2 Gen 2x2でのデータ転送時間: 約9.3分

これらの時間は理論値に基づいた概算であり、実際の転送速度や環境により変動する可能性があります。

2024年7月23日

AWS CloudWatch Logsのロググループから特定の日付のログを抽出する方法

AWS CloudWatch Logsのロググループから特定の日付のログを抽出する方法について説明します。以下の手順を実行してください。

手順1: AWS CLIのインストール

まず、AWS CLIがインストールされていることを確認してください。インストールされていない場合は、以下のコマンドを使用してインストールします。

# macOS/Linux
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

# Windows
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

手順2: AWS CLIの設定

AWS CLIを使用するために、以下のコマンドを実行してAWSのアクセスキーとシークレットアクセスキーを設定します。

aws configure

手順3: CloudWatch Logsからログを抽出

特定の日付のログを抽出するには、aws logs filter-log-eventsコマンドを使用します。例えば、2024年7月22日のログを抽出する場合は、以下のようにします。

aws logs filter-log-events \
    --log-group-name <ロググループ名> \
    --start-time $(date -d "2024-07-22" +%s)000 \
    --end-time $(date -d "2024-07-23" +%s)000

上記のコマンドでは、<ロググループ名>を実際のロググループ名に置き換えてください。

手順4: フィルターを追加

必要に応じて、特定のキーワードやパターンでログをフィルタリングすることもできます。例えば、「ERROR」というキーワードを含むログを抽出するには、以下のようにします。

aws logs filter-log-events \
    --log-group-name <ロググループ名> \
    --start-time $(date -d "2024-07-22" +%s)000 \
    --end-time $(date -d "2024-07-23" +%s)000 \
    --filter-pattern "ERROR"

この方法で、指定した期間のログを簡単に抽出できます。

2024年7月13日

LLM（大規模言語モデル）RAG（Retrieval-Augmented Generation）コンテキストとは

LLM（大規模言語モデル）RAG（Retrieval-Augmented Generation）コンテキストとは、LLMが生成する回答やコンテンツを補完するために、外部データベースや検索エンジンから情報を取得する手法を指します。具体的には、以下のようなプロセスを含みます：

質問の理解: ユーザーの質問をLLMが理解し、必要な情報を把握します。
情報の検索: 外部データベース、API、または検索エンジンを使用して、関連する情報を検索します。この情報は、ユーザーの質問に直接関連する内容です。
情報の統合: 検索で得られた情報をLLMが取り込み、ユーザーに提供する回答に組み込みます。これにより、LLMは最新の情報や特定のデータに基づいた回答を生成できます。

例

例えば、ユーザーが「最新のPythonリリースの新機能を教えてください」と質問した場合：

質問の理解: LLMは「最新のPythonリリースの新機能」に関する情報を求めていることを理解します。
情報の検索: LLMはPythonの公式サイトや最新のニュース記事などから、最新のリリースに関する情報を取得します。
情報の統合: 取得した情報を基に、ユーザーに対して具体的な新機能のリストや詳細を提供します。

この手法により、LLMは自身のトレーニングデータに含まれていない最新情報や専門的なデータにもアクセスでき、より正確で有用な回答を生成することができます。

RAGのアプローチは、特に変化の早い技術分野や最新の情報が重要な分野で有効です。これにより、LLMは常に最新の情報を提供できる状態を維持できます。

「コンテキスト」とは、ある事象や情報が存在する背景や状況を指します。特に大規模言語モデル（LLM）や情報検索の分野では、コンテキストは非常に重要な概念です。

コンテキストの具体例

テキストのコンテキスト:
- 会話のコンテキスト: ある会話の前後の文脈。例えば、「彼は」という表現が出たとき、その「彼」が誰を指すのかは、前後の会話内容によって決まります。
- 文脈情報: 特定の文章が書かれた背景や状況。例えば、ニュース記事の中で「今週」という表現が出た場合、その「今週」がいつを指すのかは記事の発行日によって異なります。
システムや技術のコンテキスト:
- システム設定: あるソフトウェアがどのような環境で動作しているか、例えばオペレーティングシステム、ハードウェアの仕様、ネットワークの状態など。
- ユーザーのコンテキスト: ユーザーが特定の操作を行っている背景や状況。例えば、ユーザーがウェブサイトで検索をしているとき、そのユーザーがどのような情報を求めているか。
文化的・社会的コンテキスト:
- 文化的背景: 特定の表現や行動がどのような文化的背景を持っているか。例えば、ある国では挨拶の方法が異なる場合、その文化的コンテキストを理解することが重要です。
- 社会的状況: 社会全体の状況やトレンド。例えば、ある言葉や表現が流行している背景には、社会的な出来事やトレンドが影響している場合があります。

コンテキストの重要性

意味の正確な理解: コンテキストを理解することで、情報の意味を正確に把握することができます。例えば、同じ言葉でもコンテキストによって意味が異なる場合があります。
適切な応答: コンテキストを考慮することで、適切な応答や対応をすることができます。特にカスタマーサポートや会話型AIにおいては、ユーザーの意図を正確に理解するためにコンテキストが重要です。
情報の関連付け: コンテキストを利用することで、異なる情報同士を関連付けることができます。これにより、より豊富で関連性の高い情報を提供することができます。

大規模言語モデルにおいても、コンテキストを考慮することで、より自然で適切な回答を生成することが可能になります。例えば、RAG（Retrieval-Augmented Generation）のような技術では、外部データベースから取得した情報をコンテキストとして利用し、より精度の高い回答を提供します。

2024年7月9日

関税と税関

関税と税関は、国際貿易や旅行に関わる重要な概念ですが、それぞれ異なる役割と機能を持っています。

関税（Tariff）

定義: 関税は、輸入品に対して課される税金のことです。これは国が輸入品に対して一定の税率を適用することで、国内産業を保護したり、収入を得たりするための手段です。
目的:
- 国内産業の保護: 安価な輸入品による国内産業への影響を軽減する。
- 収入の確保: 国家の財政収入源として機能する。
- 貿易政策の手段: 特定の国との貿易を促進または抑制するために使用される。

税関（Customs）

定義: 税関は、国境を越える貨物、人、資金などの流れを監督・管理する政府機関です。税関は関税の徴収を行うとともに、輸出入の手続きや規制を管理します。
目的:
- 関税の徴収: 輸入品に対する関税の適正な徴収。
- 法令の施行: 不法輸入や密輸の防止、規制品の適正な管理。
- 国境管理: 国境を通過する人や物の監視と管理。
- 安全保障: 有害物質や危険物の流入防止。

まとめ

関税は輸入品に対して課される税金で、主に国家収入の確保や国内産業の保護を目的としています。
税関は関税の徴収を含む、国境を越える人や物の流れの監視・管理を行う政府機関です。

このように、関税と税関は密接に関連していますが、関税は税金の一種であり、税関はその徴収と管理を行う機関です。

2024年6月24日

Python Celery 非同期処理

Celeryで使われる broker と backend の役割について解説します。

Brokerとは？

broker は、タスクキューを管理するためのメッセージブローカーの役割を果たします。タスクを送信したり、ワーカーがそのタスクを取得して処理するのに使用されます。Celeryは複数のメッセージブローカーをサポートしており、一般的には以下のものが使われます。

Redis: 高速でシンプルなキーバリューストア。
RabbitMQ: 高性能なメッセージブローカー。
Amazon SQS: AWSのキューベースのメッセージングサービス。

broker URLは、メッセージブローカーへの接続情報を含みます。例えば、redis://redis:6379/0 は、Redisサーバーがホスト redis 上でポート 6379 で動作し、データベースインデックス 0 を使用することを示しています。

app = Celery('tasks', broker='redis://redis:6379/0')

Backendとは？

backend は、タスクの結果を保存し、後で結果を取得するために使用されます。タスクが非同期に実行されると、その結果をどこかに保存しておく必要があります。これを行うのが結果バックエンドです。Celeryは以下のような結果バックエンドをサポートしています。

Redis: 結果を保存するのに適しています。
Database: SQLAlchemyやDjango ORMを使用してデータベースに結果を保存できます。
Amazon S3: S3バケットに結果を保存します。
RPC: リモートプロシージャコールのバックエンド。
backend URLは、結果バックエンドへの接続情報を含みます。例えば、redis://redis:6379/1 は、Redisサーバーがホスト redis 上でポート 6379 で動作し、データベースインデックス 1 を使用することを示しています。

app = Celery('tasks', broker='redis://redis:6379/0', backend='redis://redis:6379/1')

まとめ

Broker: タスクの送信と取得を管理するメッセージブローカー。
Backend: 非同期タスクの結果を保存するストレージシステム。

これらを適切に設定することで、Celeryを使用して非同期タスクを効率的に管理し、実行できます。

読み込み順と上書きの動作

上書きの例

設定が上書きされる際の注意点

結論

1. utf8mb4_general_ci

2. utf8mb4_unicode_ci

3. utf8mb4_unicode_520_ci

日本語データを扱う場合の選択

結論

utf8mb4_ja_0900_as_cs と utf8mb4_ja_0900_as_cs_ks

各照合順序の意味

適用シーン

日本語データを扱う場合の選択

結論

utf8mb3とは

サーム・ルールの適用例

USB2.0

USB3.0

USB3.1

USB3.2

USB3.2 Gen 1x1 (USB3.0と同じ)

USB3.2 Gen 2x2

手順1: AWS CLIのインストール

手順2: AWS CLIの設定

手順3: CloudWatch Logsからログを抽出

手順4: フィルターを追加

例

コンテキストの具体例

コンテキストの重要性

関税（Tariff）

税関（Customs）

まとめ

Brokerとは？

Backendとは？

まとめ

`utf8mb4_ja_0900_as_cs` と `utf8mb4_ja_0900_as_cs_ks`