server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    #access_log  /var/log/nginx/host.access.log  main;
    #error_page  404              /404.html;

    location / {
        root   /var/www/html;
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass phpfpm;  # 上で定義したアップストリームを指定
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

location ~ \.php$の~は、正規表現を使用したパターンマッチングを行うことを意味しています。この場合、次のような内容を表しています。

• location ~ \.php$:
  • locationディレクティブは、指定されたパスに一致するリクエストに対して、特定の処理を行うために使用されます。
  • ~は、正規表現を使用することを意味します。これにより、locationブロックの条件として、指定したパターンに一致するすべてのリクエストをキャッチします。
  • \.php$は、.phpで終わるファイルパスに一致する正規表現です。
    • \.は、.をリテラルとして扱うためにエスケープされています（通常、.は正規表現で任意の1文字を表します）。
    • phpはそのまま「php」という文字列に一致します。
    • $は、文字列の終わりを示します。つまり、phpで文字列が終わることを意味します。

この設定は、リクエストされたURLが.phpで終わる場合に、locationブロック内の設定（例えば、FastCGIの設定など）を適用することを意味しています。これにより、PHPファイルに対するリクエストが適切に処理され、PHP-FPMなどのバックエンドに渡されます。

1. locationブロック内にrootとindexを指定する場合

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    location / {
        root   /var/www/html;
        index  index.php index.html index.htm;
    }
}

• 適用範囲: この場合、rootとindexの設定は、/で始まるリクエスト、つまりすべてのリクエストに適用されます。この設定により、Nginxは/var/www/htmlディレクトリをルートディレクトリとして使用し、そこからindex.phpやindex.htmlを探します。
• 特定のパスに限定: locationブロック内に設定されているため、この設定は他のlocationブロックには影響しません。たとえば、別のlocation /images/ブロックがあった場合、そのブロックには影響を与えません。

2. locationブロックの外にrootとindexを指定する場合

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    root   /usr/share/nginx/html;
    index  index.php index.html index.htm;
}

• 適用範囲: rootとindexがlocationブロックの外にある場合、これらの設定はそのserverブロック全体に適用されます。つまり、そのserverブロック内のすべてのlocationブロックにデフォルトのrootとindexの設定が適用されます。
• 全体のデフォルト設定: 他のlocationブロック内でrootやindexが明示的に設定されていない限り、これらのグローバル設定が適用されます。

違いのまとめ

• location内で設定:
  • rootとindexが特定のlocationブロックにのみ適用されます。
  • 他のlocationブロックには影響を与えません。
• location外で設定:
  • serverブロック全体にデフォルトのrootとindexが適用されます。
  • serverブロック内のすべてのlocationブロックでこの設定がデフォルトとして使用されます。ただし、locationブロック内で上書きすることが可能です。

実際の使用例

• location内で設定する場合: 特定のパス（例えば、/images/や/api/など）で異なるルートディレクトリやインデックスファイルを使用したい場合に有効です。
• location外で設定する場合: 全体のデフォルトとしてrootやindexを設定し、特別な場合にのみlocationブロック内で上書きするという使い方が一般的です。これにより、設定が簡潔になり、メンテナンスがしやすくなります。

iPod バッテリー交換について

この記事は相当古い記事です。

自分の所有しているiPodは初代発売された奴である。
容量は10GB
裏には「斉藤ノブ」さんにサインしてもらった。＾＾
渋谷の「JZ Bart」でライブを見に行った時にサインしてもらったのだ。

サインの日付が2002年　もうサインが剥げ掛けて、良く分からなくなってしまった。
最近はめっきり使用してない。
音楽をゆっくり聴く時間が無いと言ってよい。
ｳｰﾑ・・・・

旅行に行くときは持っていく事にしてる。
タイ旅行へ行ったときは活躍してくれた。
小さいスピーカーを繋いで、浜辺で音楽聴きながら、酒でも・・

大したことじゃないですが、「SoundApp」って音声ファイル再生アプリを覚えているでしょうか？
とりあえずファイルを再生させるには便利なツールです。
起動も速いし。
「メニュー」の「ファイル」から「新規プレイリスト」を開いて、
そこにMacに接続されているiPodのアイコンをドラッグします。
なんとリストにはiPodの中の曲の一覧が！
そこから、書き出しなんてことも出来ちゃいます。
今ではそういったツールがMacOS X用にあるので必要ないのですが。
一様参考までに＾＾

質問は受け付けません。面倒くさいので(笑)

さて本題です。
長らく使ってきた所為か、バッテリーがもう駄目になってしまっていて、実用に耐えない。
そこでバッテリーを交換することにした。
丁度「Newer Technology」から交換バッテリーが発売されていたからだ。
以下はiPodのバッテリー交換時の様子を記そうと思う。

購入したバッテリーの箱

まずiPodの裏蓋を外す。
Newer Technologyのバッテリーには裏蓋を外す工具が着いてくるので、それを利用したほうがいいです。

自分の場合は、バッテリーが届く前に、先走って蓋だけ開けてしまったのです。^^;
ネット上でiPodのバラシ方を検索するとテレホンカードみたいな薄いカードを隙間に差し込んで、グイっと外すと書いてあったので同じようにやりました。
これはとても大変です。簡単には開きません。
差し込んだカードがボロボロになってしまいました。^^;

カードで蓋を開ける人は、根気よく頑張ってください。壊してもイイぐらいの感じで ^^;
工具を使うと簡単に開きます。Newer Technologyのバッテリーを買うなら工具を使ってください。

蓋を取り、iPodの中身はこんな感じです。

バッテリーとハードディスクの間にグレーの色のゴムが２つ挟まっています。
自分のは本当に初期の初期だったらしく、バッテリーとゴムが接着されていました。
初期以降はただ単にゴムが挟んであるだけらしいので、簡単に取れるそうです。
バッテリーを取り外すとSONYと書いてありました。

写真はありませんが、ハードディスクは東芝製の1.8インチです。
最近では100GBのものが発売されているので、換装することも可能でしょう。
バッテリーの交換は簡単です。
単純に差し替えてください。
後は蓋を戻して、iPodのバッテリー交換完了です。

この記事は何年も前の記事です。

E-MU Proteus2000(以下 P2K)用のFreeMIDIパッチリストを作りました。

P2K Patch List 日本語版 Size:62kb
P2K Patch List Pack 日本語版 Ver1.0b1 Size:50k

FreeMIDIをインストールすれば、 MOTU社純正のパッチリストが入っているのですが、
ちょっと使い勝手が悪いと思ったので・・・
カテゴリーで音色を分別して、 さらにp2k付属のマニュアル通りにカテゴリーを日本語化し、 ユーザーバンクも加えてみました。
折角カテゴリー分けしていても、英語だとパッと見ても何の音色なのか把握しづらかったので
日本語なら分かりやすいと思って、それに挑戦してみました。
一様、ソースはパクってませんよ(笑)　全部手入力しました...（ﾁｮｳ ﾀｲﾍﾝ...)
関係者各位に感謝！！

インストール方法

1. まずシステムフォルダの第一階層に「FreeMIDI Folder」というフォルダがあります。

2. その中に「Default Names」というフォルダがあります。

3. その中の「E-mu Systems」というフォルダがあります。

4. その中の「Proteus 2000」というファイルと入れ替えてください。

5. これでOKです。

P2K Patch List Pack Ver1.0b1はマニュアル4番以降を下記と差し替えて読んでください。

6. その中にこれらのパッチリストを入れてください。必要なファイルだけでもOKです。
（始めから入っているProteus 2000のパッチリストは念のためにバックアップを取っておきましょう。）

7. FreeMIDIはこんな感じにセットアップしてください。

8. これでOKです。

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

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

1. www.conf: 通常、www.confはPHP-FPMのプール設定ファイルとして最初に読み込まれます。このファイルには、PHP-FPMの動作に関する基本的な設定が含まれています。
2. 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に存在していたとしても上書きされます。この仕組みを利用して、環境に応じた設定の調整を行うことができます。

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も最新の状態に保ってください。
これらの手順を試しても問題が解決しない場合は、カード発行会社に問い合わせて、詳細なサポートを受けることをお勧めします。

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に基づいており、日本語の特性を考慮した照合を行います。

各照合順序の意味

1. utf8mb4_ja_0900_as_cs
   • ja: 日本語に特化した照合順序であることを示しています。
   • 0900: Unicode 9.0に基づいていることを表します。
   • as: 「Accent Sensitive（アクセントを区別する）」の略。アクセントの違いを考慮して文字を比較しますが、日本語ではアクセントの概念はあまり重要ではないため、実質的に大きな影響はありません。
   • cs: 「Case Sensitive（大文字小文字を区別する）」の略。文字の大文字と小文字を区別します。
2. 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バイト文字はサポートしていません。

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

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

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

サーム・ルールの適用例

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

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

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

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