OmniAICreator/Qiita-1.07M huggingface dataset:
MSI Stealth 14 Studio A13V に Ubuntu 23.04 をインストール

# 目的
ノートPCのMSI Stealth 14 Studio A13Vには標準でWindows 11 Proがインストールされていますが、Windows 11 Proを残しつつUbuntu 23.04をホストOSとして利用したい場合に、外部ストレージにUbuntu 23.04をインストールしてデュアルブート環境を構築する方法を記載します。
※内部ストレージにUbuntu 23.04をインストールすると標準のブートローダーをデュアルブート用に書き換えることになりますが、外部ストレージにインストールする場合は標準のブートローダーを書き換える必要がないため、外部ストレージにインストールすることにしました。
※Ubuntu23.04では標準でWi-Fiのモジュールを認識しないため追加で作業を行う必要があります。

# 用意するもの
- Ubuntu 23.04をインストールする場所のまっさらなUSBメモリ (例：nvme 2TB)
- ブルーレイ／DVDドライブ
- Ubuntu 23.04のインストールメディア (例：DVD-R)
- USB Ethernetアダプタ
※Intel AX211 (Killer Wi-Fi 6E AX1675i 160MHz)を認識しないため

# Ubuntu 23.04のインストール
1. ブルーレイ／DVDドライブにインストールメディアを挿入
1. USBメモリとブルーレイ／DVDドライブをMSI Stealth 14 Studio A13Vに接続
1. F11を押しながら電源ボタンを押してブートメニューを表示
1. ブルーレイ／DVDドライブを選択してUbuntu 23.04のメディアから起動
※デスクトップ画面が表示されてインストーラーが立ち上がるまで時間がかかりますので気長に待ちます
1. Choose your language: 日本語
1. Ubuntu をインストール
1. キーボードレイアウト: 日本語
1. ネットワークに接続: 今はインターネットに接続しない
1. アプリケーションとアップデート:
   - 最小限のアプリだけをインストールする
   - グラフィックスとWi-Fi機器用のサードパーティ製ソフトウェアをインストールする
1. インストール方法を選択: 手動パーティショニング
1. 手動パーティショニング:
   1. ブートローダーをインストールするデバイスを選択してください: sda External
   ※外部ストレージを選択するとsdaにsda1 fat32 /boot/efi 1GBが作成されます
   1. 手動パーティショニング: sda 空き領域を選択後＋
   1. サイズ: デフォルトの値, 使用方法: Ext4, マウントポイント: /
1. インストールの準備完了: デバイス sda, パーティション: sda1 fat32 /boot/efi, sda2 ext4 /
1. タイムゾーンを選択してください。: Tokyo, Asia/Tokyo
1. アカウントの設定: 各自設定
1. テーマを選択してください。: 各自設定

※インストールが終わるまで待ちます
※再起動を選択するとメディアが排出されてEnterを押すと再起動します

# セキュアブートを無効化
1. Ubuntu 23.04が起動したらインストール時に設定したアカウントでログイン
1. 左下のShow AppsからTerminalを選択して起動
   ```
   sudo mokutil --disable-validation
   password length: 8~16
   input password:
   input password again:
   sudo reboot
   ```
1. Change Secure Boot stateを選択
1. パスワードの[X]文字目の入力 (Enter)
1. パスワードの[X]文字目の入力 (Enter)
1. パスワードの[X]文字目の入力 (Enter)
1. Secure Bootの無効化: Yes

# Ubuntu 23.04のインストール後
1. Ubuntu 23.04が起動したらインストール時に設定したアカウントでログイン
1. USB Ethernetアダプタを接続
※認識すると右上のスピーカーのアイコンの左側にネットワークのアイコンが表示されます
1. 左下のShow AppsからTerminalを選択して起動
1. 最新のgitとbuild-essentialパッケージをインストール
   ```
   sudo apt update
   sudo apt upgrade -y
   sudo apt install -y git build-essential
   ```
1. iwlwifi firmwareのダウンロード
   ```
   git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
   cd linux-firmware/
   sudo cp iwlwifi-* /lib/firmware/
   cd ..
   ```
1. iwlwifi backportをダウンロードしてビルドしてインストール
   ```
   git clone https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git
   cd backport-iwlwifi/
   sudo make defconfig-iwlwifi-public
   sudo make -j4
   sudo make install
   cd ..
   ```
1. initramfsを更新
   ```
   sudo update-initramfs -u
   ```
1. Ubuntu 23.04を再起動

※再起動後にWi-Fiが使えるようになっていると思います。

# デュアルブートの方法
Windowsを起動したい場合は外部ストレージを外して電源を入れます。
Ubuntuを起動したい場合は外部ストレージを付けてF11を押しながら電源を入れ、外部ストレージを選択します。
GoogleのProject IDX　生成AI（フルスタックアプリ開発）

## Project IDXとは
Project IDXは、Google2023年8月8日に発表された、開発中のモバイルやデスクトップなど、複数のプラットフォームに適応するフルスタックのWebアプリケーションを、様々なフレームワークや生成AIのサポートを活かして効率的に開発できる、Webブラウザからアクセス可能な統合開発環境です。


## Project IDXの主な特徴:
- Webブラウザから利用できる
- マルチプラットフォームに対応
- さまざまなフレームワークや言語をサポート
- 生成的AIによる開発支援機能が搭載


## 人気のあるフレームワークや言語で開発
Project IDXは、Angular、Next.js、React、Svelte、Flutterなどの人気フレームワーク向けのさまざまなテンプレートを使用して、複数のプラットフォームで動作するアプリの構築を容易にします。また、PythonやGoのサポートも近日公開予定です。GitHubから既存のアプリケーションをインポートすることもでき、ほとんどの技術スタックに対応しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225269/4a271ff4-1854-477f-328a-397829ea8b0c.png)


## 複数のプラットフォーム間でアプリを最適化
Project IDXでは、ビルトインのマルチブラウザウェブプレビュー、Androidエミュレータ、iOSシミュレータへのサポートが近日提供される予定を含め、ユーザーがアプリを見るような形で、フルスタックでマルチプラットフォームのアプリをプレビューすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225269/26725d5a-2d0f-f8ad-5cc8-e58a25d4a4dd.png)

## 生成AIによる高速なコーディング
Google組み込みのAIアシスタンスにより、コード生成、コード補完、プログラミング言語間のコード翻訳、コードの説明など、コーディングを迅速かつ効率的に行うことができます。これらすべては、コードに関するトレーニングを受けた基盤となるAIモデルである「Codey」によって提供されており、PaLM 2上に構築されています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225269/9e73c5a7-a436-187c-d8c5-44221dce204d.png)


## まとめ：
Googleが2023年8月8日に発表したProject IDXは、フルスタックのWebアプリケーションを多様なプラットフォームに適応させる統合開発環境です。Webブラウザから利用可能で、AngularやReactなどの人気フレームワークを活用してアプリを開発できます。また、AI支援による高速なコーディングやアプリのプレビュー・最適化も可能。未来の開発体験を提供するProject IDXに注目です。

参照：
https://idx.dev/
Anaconda & Ubuntu22.04LTS 環境下で Pyxel を利用してエラーで run できずハマったけど解消できた件

たまーにデータ分析学習がしたくなり、Anaconda 環境で Python の利用をしているのですが、Python の Pyxel(ピクセル) という pip 環境のレトロゲームエンジンも利用したいというのが私です。

Anaconda 環境と pip 環境は「まぜるな危険」と言われてますが、Anaconda 環境下で仮想環境 1 個作成してそこに pip から Pyxel を追加して利用してました。

中古PCを 1 台購入して Ubuntu 22.04LTS に Anaconda 23.7.2 を入れて同じように個別環境作成して、Pyxel 1.9.18 を追加して run したところ、なにかのファイルがないという長いエラーでまったく実行できず、検索しまくりで調べたら以下のコミュニティー情報で解消できたので備忘録と共有になります。
どうも、Ubuntu 環境下で個別仮想環境作成して、なにか特定のライブラリーを実行すると出る事象のようです。なので、Pyxel　利用でなくても、同じような状況（エラーが同じ、なにか Anaconda 環境下の個別環境でプログラムを実行しようとしている）であれば利用できるかもしれないです。

1 https://forum.manjaro.org/t/libgl-error-mesa-loader/69746

2 https://askubuntu.com/questions/1352158/libgl-error-failed-to-load-drivers-iris-and-swrast-in-ubuntu-20-04

順番としては2を先に実施して解消されず、1で解消したので1を先に実施すれば、1だけでも解消するかもしれないです。

Pyxelをrunで実行して出るエラーは（記録してなかったので手元にないですが）上記記事1内容と内容はほぼ同じでした。以下。

> libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  890
  Current serial number in output stream:  891
【空想】日本列島が世界から隔絶されたら、を考えてみた

:::note info
本記事は、ChatGPTほかのAIは、使っていません。あしからずw。
:::

　どうも、カーブミラーです。

　猛暑日が更新されましたね。
　　ダムの水が少なくなって、
　　　取水制限の可能性もあるとか。
　　　　ほどよい雨が欲しいところ。
***
　今回は、
　　下記の記事
[海底ケーブルが2本切断されアフリカのインターネットが大混乱に陥る、ケーブル切断にもかかわらず遅延が改善されるケースも](https://gigazine.net/news/20230818-subsea-cable-cuts-african/)
　　　を読んでいて、
　　　　ちょっと想像して
　　　　　しまった話を
　　　　　　させてください。

　ちなみに、上記記事では、
　　日本に影響があるわけでは
　　　ないようです。
***
　私は、SF好きなので、
　　そういうネタに敏感でして。

　上記記事で、
　　想像してしまったのは、
　　　日本列島と島外（世界）を
　　　　繋いでいるケーブルが
　　　　　すべて切断してしまったら
　　　　　　どうなるのか、
　　　　　　　ということ。

　もちろん、
　　衛星経由での繋がりは
　　　ありますけどね。

　もし、それもなくなり、
　　完全に世界から
　　　隔絶された日本列島。

　そうなれば、
　　インターネットも
　　　日本オンリーに。

　まぁ、その程度ならば、
　　困りそうに思えません。

　でも、本当に？

　世界中のサービスが
　　使えなくなるよね。
　　　Googleしかり、
　　　　Microsoftしかり、
　　　　　ほかにも。

　もちろん、
　　ChatGPTのOpenAIは、
　　　アメリカ。

　自社のサービスに
　　ChatGPT（GPT4も含む）を
　　　組み込んでいれば、
　　　　一気にサービス停止に。
***
　これの復旧は、
　　どのくらいかかるでしょうか？

　電波による繋がりは、
　　残されていますけど、
　　　インターネットを
　　　　行なえるほどでは
　　　　　ありません。

　ケーブルは、
　　敷設船を使って、
　　　海底に敷設されます。

　船で渡るだけでも、
　　それなりの日数が掛かります。

　つまり、
　　一日二日では、
　　　復旧しません。

　おそらく、数ヶ月は……。

　それまで、
　　日本は混乱するのでは？
***
　バカな話と、
　　笑えるでしょうか？

　日本は、昔から、
　　地震や津波に
　　　やられてきました。

　だから、
　　その対策も
　　　取られています。

　そこに
　　こうした世界からの隔絶も
　　　取り入れておいて
　　　　欲しいですね。

　個人的には、
　　どうにもできそうに
　　　ないものですからね。

　企業様、BCPにお願いしますw
LevelPlay(IronSource)を導入後に、Androidビルドが上手くいかない時の解決方法

Unityの新しい広告制御方法であるLebelPlay(IronSource)。
そのLevelPlayの導入後にAndroidのビルドが通らなくなり、覚悟していたとは言え夏休みを半分浪費（消費ではなく浪費）することになってしまったのが辛かったので、同じ苦しみを味わう人が減るように出来るだけシンプルに書き残しておきます。

★追記★
下記の手順に　7.5　を追加しました！
ExternalDependency Managerを入れた直後に、一度Resolveをしておくことが超大事…！っぽい。
★追記ここまで★

# 関連リンクと結局何が問題なのか

公式のナレッジセンターのリンクはコチラ↓

https://developers.is.com/developer-docs/unity/

一応ゼロからチャレンジしたい人の為にリンクを貼っておきます。

解決した今だからこそ思う問題点としては

* 似たような単語が多く、意味が散乱している
    →　Advertaise with Mediation、Ads Mediation、LevelPlay、IronSource …
* 日本語の情報が少ない
* 各種パッケージが保守されていない（少なくともそう思わせられる）
* エラーの原因と発生源が関連付けづらい
* 場当たり的な対処法が多い

などが挙げられるように思います。
まぁ過渡期と言えば過渡期なのかもしれませんが（この記事を書いている段階ではLevelPlayに移行した後でまだ1年経っていない？）、果たしていつしっかりと整備された環境に仕上げるのか。。

# で、結局解決するにはどうすべきか

一番キーになったのはこのスレッドの投稿

https://forum.unity.com/threads/win32exception-at-resolving-android-dependencies-cannot-find-file-gradlew-bat.1379184/#post-8839615

ここに辿り着くまでに2日ほどかかりました；
書いてある手順を書くと、下記の通りです

1\. プロジェクトから __LevelPlay(IronSource)関連を一旦完全に除去__ します
2\. Unity、UnityHubを閉じます
3\. __最新環境のJDK__ をインストールします（記事では19が最新、私の場合は21が最新でした）
4\. 環境変数「JAVA_HOME」で「C:\Program Files\Java\jdk-19（私の場合は21）」を追加
5\. Unityを起動
6\. __最新の　Google Android Dependency Manager__　をImportする
7\. プロジェクトの ProjectSettings > Android > Publishの、Custom Main Gradle Templateと、Custom Gradle Properties Templateのチェックを入れる
（追記）7.5\. **Menu > Assets > External Dependency Manager > AndroidResolver > Resolveをする事！**
8\. __最新の　 LevelPlay Mediation package__　をImportする
9\. gradleTemplate.propertiesに「android.useAndroidX=true」「android.enableJetifier=true」を追記する

となります。
以下で6、8、9をちょっとだけ補足します

## 6\.の補足
最新の Google Android Dependency Manager　はコチラに有ります(記事記載時は1.2.177

https://developers.google.com/unity/archive?hl=ja#external_dependency_manager_for_unity

名前は変わっているようで、現在は「External Dependency Manager for Unity」という名前らしい
※もうその時点で紛らわしい

## 8\.の補足
最新の　LevelPlay Mediation package　はこちら（記事記載時は7.4.0

https://developers.is.com/ironsource-mobile/unity/getting-started-ironsource-unity-plugin-japanese/

コレを導入した後で、マニュアルにもある通りにMenu > Ads Mediation > IntegrationManager　から、必要なパッケージのInstallやUpdateを行うのを忘れずに。

で、8\.が済んだ辺りで一度 Menu > Assets > External Dependency Manager > AndroidResolver > Resolveをした方が良かったです。
※SettingsをDefault指定にした方が良いかも？（ここは要検証）

## 9\.の補足
これは上の手順を辿ったところ __不要__ でした。
Dependency ManagerでResolveを行うと、自動で行ってくれるっぽいかな。

# 追加対応
されに上記手順のみではうまくビルドが通らず、何が原因かと調べた所 __NCMBのPluginsとのライブラリ競合が発生していた__ ようでした。
私のようなunity1week上がりの人間は、大体ランキング実装などでNCMBを導入しているかと思いますが、そこと相性が悪いようです。
NCMB/Plugins/Androidフォルダから、最小限に下記を削除しました

* androidx.collection.collection-1.0.0.jar
* androidx.core.core-1.2.0.aar
* com.google.android.gms.play-services-base-17.6.0.aar
* com.google.android.gms.play-services-basement-17.6.0.aar
* com.google.android.gms.play-services-tasks-17.2.1.aar

これでビルド成功です。あー、疲れた。。

# 終わりに
という事で、ビルドを通すための手順紹介でした。
そもそもビルドする前に、IronSourceにアカウント登録→アプリ登録→メールを送って承認してもらうステップなどもあり、そこもしんどいのですがそれについてはココでは範囲外という事で触れません。

普通にパッケージを入れるとDependencyManagerが古いせいかGradle関連のエラーが出まくるのが、この取っつきづらさの一番の問題なんじゃないかなぁ…とも思いつつ。

iOSのビルドは果たしてどうなるか、
わざわざ記事を残さなくとも良いくらいスムーズにいって欲しい所です。。
公開買付一覧を抽出する方法(EDINET使用)


# 概要

公開買付されている上場企業に関する資料を探す際、EDINETがとても役立ったので使い方をメモしておく

# EDINETとは？

[EDINET](https://disclosure2.edinet-fsa.go.jp/WEEK0010.aspx)は、日本の金融庁が運営する電子開示システム。上場企業などの法人が証券取引法に基づき、有価証券報告書、四半期報告書、半期報告書などの財務諸表を閲覧することができる。

# 方法

[書類詳細検索](https://disclosure2.edinet-fsa.go.jp/weee0050.aspx)ページへアクセス

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/330768/bf78c3ab-ea33-993a-dbdc-2c17ca384aa8.png)


「書類種別を指定する」にチェック
「公開買付届出書」にチェック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/330768/ffe963d0-3da7-a516-014d-79ed8de8b24d.png)



検索結果がこちら！
公開買付一覧が抽出できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/330768/7b7c61c3-f79a-0bda-b3c5-17a82c31a25c.png)

# まとめ
公開買付一覧を抽出することで、抽出結果からEDINET上にある膨大な資料にアクセスすることができるようになりました！
ニュースなどで取り上げられることが多い公開買い付けですが、提出された資料を読むことでより深く理解できるのではないかと思います。
【企業機密の漏洩を防ぐ】OpenAIのGPTBotのアクセスを禁止する方法


OpenAIのGPTBotとは、2023年8月13日に公開されましたウェブクローラーです。GPTBotは、インターネット上のテキストデータを収集し、OpenAIの言語モデルのトレーニングに使用します。

GPTBotは、プライバシーやコンテンツの品質を重視してクロールし、サイトの所有者は制御も可能です。

GPTBotがサイトにアクセスを許可すると、AIモデルがより正確になり、一般的な能力と安全性が向上します。ただし、ペイウォールへのアクセスが必要なソース、個人を特定可能な情報（PII）を収集することが知られているソース、またはポリシーに違反するテキストを含むソースはフィルタリングされます。

GPTBotのメリットとしては、以下のようなものが挙げられます。
- AIモデルのトレーニングに必要なテキストデータを大量に収集できる。
- プライバシーやコンテンツの品質を重視したクローリングが可能。
- サイトの所有者は制御が可能。

GPTBotは、今後もAIモデルの開発において重要な役割を果たしていくことが期待されています。


GPTBotのアクセスを禁止する
GPTBotがサイトへのアクセスを禁止するには、GPTBotをサイトの**robots.txt**に追加することができます。
```
User-agent: GPTBot
Disallow: /
```

GPTBotのアクセスをカスタマイズする
GPTBotにサイトの一部のみへのアクセスを許可するには、GPTBotトークンをサイトのrobots.txtに以下のように追加できます。
```
User-agent: GPTBot
Allow: /directory-1/
Disallow: /directory-2/
```

参照：
https://platform.openai.com/docs/gptbot
GA4の参照元別CV推移をBigQueryとLookerStudioで可視化する

GA4のデータをリクエストの割り当て制限を避けるために
直接コネクタで繋がずにBigqueryを介してLookerStudioで可視化した時の備忘録です。

```sql
SELECT
  DATE(timestamp_micros(event_timestamp), 'Asia/Tokyo') AS event_timestamp,
  event_name,
  traffic_source.source,
  traffic_source.medium,
  traffic_source.name,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location , 
FROM
  `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE 
  event_name = 'purchase'
```

トラフィックソースごとに時系列でCV・CVRの推移を追っていたUAでの分析環境を再現したかったものの、現状のGA4では、ユーザの初期流入経路（`traffic_source`）のみが保存されており、UAのようにセッションごとに分析はできないようです。

今年6月頃に`collected_traffic_source`が[正式サポート](https://support.google.com/firebase/answer/7029846?hl=ja#zippy=%2Ctraffic-source:~:text=collected_traffic_source)されて、イベントと同時に収集された手動トラフィックソースは保存されるみたいですが、Google広告の自動タグ設定や（utmソースを手動付与していない）オーガニック流入では反映されないと思われます。

上記コードのデータセットは[一般公開データセット](https://developers.google.cn/analytics/bigquery/web-ecommerce-demo-dataset?hl=ja)を使用していますが、23年8月時点では`collected_traffic_source`に値が格納されていませんでした。とりあえず、`traffic_source`のイベントデータをLookerStudioと繋ぎこんで可視化します。

![スクリーンショット 2023-08-20 105812.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/319121/3823a396-6bc7-3d1d-3245-4b9405bdea48.jpeg)

これまでのGA（UA）では、セッション単位で参照元別のCVを収集していましたが、GA4では初期流入経路別で収集するとなると、顧客ライフサイクルが長い商材ではチャネルごとの評価が変わってきてしまいます。

認知から獲得までの流入経路の寄与度を上手く評価するには、ファーストタッチ（GA4）やラストクリック（UA）のように偏ることなく、GAのデータドリブン アトリビューション（DDA）等を活用した方が良いかも知れません。
【プラクティス紹介】1分でさらっと分かる「ドラッカー風エクササイズ」

![dru_ex.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3526800/af8669c9-2bbd-dca3-493f-710dd461f584.jpeg)

## プラクティス名（別名）
ドラッカー風エクササイズ　（ドラエク）

## プラクティスの目的・狙い
* メンバー間の期待を擦り合わせ、円滑にチームビルディングを行う

## どんな時に使うか
* チーム立ち上げ時にスタートダッシュしたい時
* 新規メンバー参入時にすぐにキャッチアップしてもらいたい時

## 実施手順
1. まずファシリテーターが「否定や批判をしない」という場を設定する（心理的安全性の確保）
1. ホワイトボードなどに以下の4つの質問を書き、各自回答を付箋などに記入して貼っていく
1. 全員が貼れたら順番に自分の書いた付箋を説明し、感想を述べあい、相互理解を深める

| 質問 | 回答例 |
|:---|:---|
|1.自分は何が得意なのか？|新しいことにチャレンジすること|
|2.自分はどういうふうに仕事をするタイプなのか？|朝型である。マイクロマネジメントを嫌う。|
|3.自分が大切に思う価値は何か？|チームとしても個人としても成長すること|
|4.チームメンバーは自分にどんな成果を期待していると思うか？|まだできることは少ないので、できるようになるための努力をすること|

## アレンジ例
* そう思うようになったきっかけやエビソードを交えて話してもらうと簡単な経歴紹介にもなる
* メンバーに新人がいて、質問4が書きづらい場合は「成果」を「姿勢」や「目標」に読み替える
* 質問に「5.その期待はあっているか？」を追加し、皆からフィードバックしてもらう
* 質問内容を裏返した「ドラッカー風エクササイズＢ面」をやってみる（上級編）

| Ｂ面の質問 | 
|:---|
|1.自分は何が不得意なのか？|
|2.どういうふうに仕事をしてしまうか？（他人からも言われていること）|
|3.自分の地雷は何か？（踏まれると爆発すること）|
|4.むかしチームメンバーの期待に応えられなかった事件とは？|


## アンチパターン
* 心理的安全性が十分に作れていない状況で始めてしまい、書き出しが進まない

## 参考情報
書籍『アジャイルサムライ』で提唱されたプラクティス。
なお質問2の翻訳は13刷で「どうやって貢献するつもりか？」に変更されたようですが、本稿は元の翻訳に拠りました。

https://www.ohmsha.co.jp/book/9784274068560/

「ドラッカー風エクササイズＢ面」については『チームジャーニー』より引用。

https://www.shoeisha.co.jp/book/detail/9784798163635

## こぼれ話（私的コメント）
プラクティス名は『アジャイルサムライ』の著者Jonathan Rasmussonが「いかにもピーター・ドラッカーが言いそうな感じでしょ？」と茶目っ気たっぷりに名付けたもので、プラクティス自体はドラッカーさんが考案したわけではないです。ただ全く関係が無いわけでもなく、大元はドラッカーの論文から来ているそうです。そのあたりの経緯は[AgileStudioさんの解説](https://www.agile-studio.jp/post/apm-drucker-excersize)に詳しく載っています。

このプラクティスをやるとメンバー間の距離がグッと縮まるので、自己紹介代わりに使うのも効果的です。ただＢ面のエクササイズに関しては少し踏み込んだ質問なので、ある程度チームがこなれてきてから改めて行った方がよいでしょう。ネガティブな質問でも笑って話せるぐらいに気心が知れたメンバーでやると意外な一面が知れて、より関係性が深まるかもしれません。

　[アジャイルプラクティス一覧へ戻る](https://qiita.com/kakashi_h5/items/20584998c5ca4594b9ea)
Node.jsのバージョンをnode-sassのバージョンに合わせて下げた方法

自分のための備忘録です。

## エラー内容

いつものようにプロジェクトの開発環境を立ち上げようとすると、以下のエラーが出ました。
```bash
$ npm run start

# 略
ERROR in ./src/css/style.sass (./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/style.sass)
Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
Error: Cannot find module 'node-sass'
```

`node-sass`が見つからないとのことですが、`package.json`には記載があります。

```package.json
"dependencies": {
  // 略
  "node-sass": "^4.13.1",
　　　　// 略
}
```

インストールを試みると、以下のエラーが出ました。

```bash
$ npm install

> node-sass@4.13.1 install /Users/kawakami_air/project/project_name/frontend/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.13.1/darwin-x64-83_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.13.1/darwin-x64-83_binding.node": 

HTTP error 404 Not Found

Hint: If github.com is not accessible in your location
      try setting a proxy via HTTP_PROXY, e.g. 

      export HTTP_PROXY=http://example.com:1234

or configure npm proxy via

      npm config set proxy http://example.com:8080

> node-sass@4.13.1 postinstall /Users/kawakami_air/project/project_name/frontend/node_modules/node-sass
> node scripts/build.js
```

## 原因

node-sassのバージョンがNode.jsのバージョンと対応していないのが原因のようでした。

プロジェクトのNode.jsのバージョンを確認（v14.15.1）
```bash
$ nvm ls
    v14.15.1
->    system
default -> 14.15.1 (-> N/A)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v14.15.1) (default)
stable -> 14.15 (-> v14.15.1) (default)
lts/* -> lts/hydrogen (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.0 (-> N/A)
lts/hydrogen -> v18.16.0 (-> N/A)
```



node-sassのv4.13.1を確認すると、Node.jsのバージョンは13までしか対応していません。

![node-sassのバージョン対応表.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/652834/f71bed99-ec09-bc6f-b505-7f950f089445.png)

https://github.com/sass/node-sass/releases?page=2

## 解決方法
Node.jsのバージョンを下げます。
```bash
# インストール可能な Node.js のバージョン一覧を確認
nvm ls-remote
#　略

# 13に下げる
$ nvm install 13.10.1

# バージョンを切替え（これをしないと、dockerを再起動した際に元のバージョンに戻ってしまいました）
$ nvm use v13.10.1
Now using node v13.10.1 (npm v6.13.7)
```

バージョンが切替わっているのを確認（v13.10.1）
```bash
$ nvm ls
->     v13.10.1
       v14.15.1
         system
default -> 14.15.1 (-> N/A)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v14.15.1) (default)
stable -> 14.15 (-> v14.15.1) (default)
lts/* -> lts/hydrogen (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.2 (-> N/A)
lts/hydrogen -> v18.17.1 (-> N/A)
```

再度試行したら、無事成功しました！
```bash
$ npm run start
#　略
ℹ ｢wdm｣: Compiled successfully.
```

なぜNode.jsのバージョンが変わってしまっていたのかは不明です・・
Linux: ファイルが多すぎるとLSできない？

少しひっかかったのでメモ。

###### 実施環境：

```Linux:Linux
[testuser@testhost ~]$ uname -a
Linux testhost 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[testuser@testhost ~]$ echo $SHELL
/bin/bash
```

### 事象

以下のように、100万個のファイルが入っているディレクトリがあるとします。

```Linux:Linux
[root@testhost ~]# ls ./test/ | wc -l
1000000
```

このディレクトリの中のファイルの一覧をとろうとするとき、普通にディレクトリを引数に指定すれば特に問題なく ls コマンドを実行できます。

```Linux:Linux
[root@testhost ~]# ls ./test/
1.txt
10.txt
100.txt
(以下省略)
```

ところが、ファイルをワイルドカードで指定しようとすると、 ls コマンドはエラーとなってしまいます。

```Linux:Linux
[root@testhost ~]# ls ./test/*
-bash: /usr/bin/ls: 引数リストが長すぎます
```

### 原因

なぜこのようなことが起こるのか。
原因は Linux における特殊文字の展開の順序が大きく絡んできます。

細かい説明は省きますが、 ls コマンドでワイルドカードを指定した場合、 ls コマンドが実行される前にワイルドカードが展開されてしまいます。
すなわち、

```Linux:Linux
ls ./test/*
```

は

```Linux:Linux
ls ./test/1.txt ./test/10.txt ./test/100.txt (以下省略)
```

として解釈され、実行されます。
一方で、 Linux においてコマンドの引数には長さの上限があります。
そのため、大量のファイルをワイルドカードを使って ls コマンドに指定した場合、引数エラーが発生してしまうのです。
無論、このエラーは ls コマンド以外でも発生しうるので注意しましょう。

```Linux:Linux
[root@testhost ~]# rm ./test/*
-bash: /usr/bin/rm: 引数リストが長すぎます
```

### 対処法

対処法はいくつかありますが、今回は3つほど紹介します。

###### ①ワイルドカードを使用しない

一番手っ取り早いのは、ワイルドカードを使用しないことです。
例えば先ほどのようにディレクトリを指定するだけなら、きちんと ls コマンドは実行できます。

```Linux:Linux
[root@testhost ~]# ls ./test/
1.txt
10.txt
100.txt
(以下省略)
```

###### ②コマンド側でワイルドカードを展開できるコマンドを使用する

 Linux のコマンドの中には、コマンド側でワイルドカードを展開できるコマンドもいくつか存在します。

代表的なのが find コマンドです。
 find コマンドの name オプションを使用すれば、ワイルドカードをコマンド側で展開することができます。

```Linux:Linux
[root@testhost ~]# find ./test/ -name "*"
./test/
./test/1.txt
./test/2.txt
(以下省略)
```

 ls コマンドを通す必要があるなら、 xargs コマンドを使用することで対応可能です。

```Linux:Linux
[root@testhost ~]# find ./test/ -name "*" -type f | xargs ls
./test/1.txt
./test/10.txt
./test/100.txt
(以下省略)
```

###### ③ echo コマンドを使用する

実は echo コマンドを使用することでも対応可能です。
ただし、結果は改行区切りでなくスペース区切りとなります。

```Linux:Linux
[root@testhost ~]# echo ./test/*
./test/1.txt ./test/10.txt ./test/100.txt (以下省略)
```

なお、ここで使用している echo コマンドは exit コマンドや let コマンド等と同じ、「 bash の組み込みコマンドである echo コマンド」です。
 bin 配下にある echo コマンドは ls コマンド等と同じようにエラーになります。

```Linux:Linux
[root@testhost ~]# /bin/echo ./test/*
-bash: /bin/echo: 引数リストが長すぎます
```

### 補足

ちなみに、引数の長さの上限は以下のコマンドラインで確認できます。

```Linux:Linux
[root@testhost test]# getconf ARG_MAX
2097152
[root@testhost test]#
```

なお、この「2097152」は引数の個数の上限ではなく、「引数のバイト数の上限」であることに注意が必要です。
ワイルドカードを使用せずとも、例えば以下のように非常に長い文字列を1つ与えるだけで ls コマンドはエラーとなります。

```Linux:Linux
[root@testhost ~]# cat test.txt | wc -c
3154812
[root@testhost ~]#
[root@testhost ~]# ls "`cat test.txt`"
-bash: /usr/bin/ls: 引数リストが長すぎます
```
フォルダ内のファイルを自動で結合するRのコード

# 背景
　コンピュータプログラムを使って実験を行った際に、参加者一人一人のデータを、csvやtxtファイルで出力する場合があると思います。データ分析する際に、このばらばらのデータを一つのデータセットにまとめてRに読み込む方法を紹介します。

# 手順
## データ
例えば、以下のような形式でデータが記録されたcsvファイルが複数あるとします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2344524/5b350926-912d-f0df-6543-1fcfba150929.png)

## 手順
- 必要なパッケージのインストール
```
utilsパッケージ
→ read.csv関数、write.table関数を使うのに必要
```

- ファイルがあるディレクトリを選び、そのディレクトリのファイルをすべて指定します。patternという引数もあり、ここで正規表現を使えます。例えば、ドキュメントフォルダにある、"Japanese"という名前を含んでいるファイルのみを取得したい場合の例は以下です。
```pattern = ".pdf"```のように指定すれば、PDFファイルだけ取得できます。
 
```R
setwd("C:/Users/mt/Documents")
file_list <- list.files(pattern = "Japanese") 
```
ちなみに、list.files関数にpathという引数を指定すれば、一行で書けます。

```R
file_list <- list.files(path = "C:/Users/mt/Documents",
                        pattern = "Japanese")
```

- 次に示すスクリプトを実行するだけで結合できます
```R
#結合開始
bind_data <- NULL
for (i in 1:length(file_list)){   #一つ一つ、ファイルの数だけ結合する
csv_data<-read.csv(file_list[i])
bind_data<-rbind(bind_data, sapply(csv_data, as.character))
}
```

# 追記（2023/08/20）
X（旧twitter）にて、より短いコードで、より高速に実行できる、read_csv関数を教えていただきました。<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">複数のcsvファイルの読み込みはreadr::read_csv()で一発で行けますよ。<br><br># testフォルダ内のcsvファイルを全部読む場合<br>library(tidyverse)<br>file_list &lt;- list.files(&quot;test/&quot;, pattern = &quot;.csv&quot;, full.names = TRUE)<br>bind_data &lt;- read_csv(file_list, id = &quot;file_name&quot;)</p>&mdash; ボブさん (@bob3bob3) <a href="https://twitter.com/bob3bob3/status/1693085091264864549?ref_src=twsrc%5Etfw">August 20, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>ボブさん、ありがとうございます。
```R
library(tidyverse)
bind_data <- readr::read_csv(file_list, id = "file_name")
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2344524/4f14d031-2e16-f435-d279-7b0e5b34e468.png)

データセットの完成です。あとはそのまま分析するだけ。

## データセットの保存方法
任意のファイル形式で作成したデータセットを保存できます。
```R
write.table(bind_data, 
            "好きなファイル名.csv", #.csvという拡張子を忘れない
            sep = "\t", #タブで区切られているデータ。区切りごとに変える必要あり
            quote = FALSE, 
            row.names = FALSE)  #データの型で関数（write.table）変える必要あり
```
ちなみに、保存先を指定することができます。例えば、"好きなファイル名.csv"のファイル名の前に、絶対パスを指定する方法があります。以下のように指定すると、新しく作成したファイルがドキュメントに保存されます。

```R
write.table(bind_data, 
            "C:/Users/mt/Documents/好きなファイル名.csv", 
            sep = "\t", 
            quote = FALSE, 
            row.names = FALSE)  
```

~~# 最後に
改善点の一つとして、とてつもなく大量のデータがある場合、forを使うループはかなり時間がかかってしまいます。for文を使わずに同じことができる方法を探ることがあげられます。~~
参考：# 追記（2023/08/20）

# 参考資料
[ファイル読み込み色々【R言語・小技】](https://qiita.com/Ringa_hyj/items/893dc1e941dc79356c41)
Ruby on Rails：Herokuへのデプロイ方法

# はじめに
Ruby on RailsをHerokuへデプロイする方法の記事が少なかったので、まとめました。
手順さえわかれば、簡単にデプロイできるので、非常に便利です。
特に初心者は、AWSやGCPなどのクラウドサービスを使わずに、Herokuで開発することをお勧めします。
※Gitの利用が前提・必須となります。

# ログイン
はじめに、TerminalからRuby on RailsのGitリポジトリ配下に移動して、heroku loginを実行します。
```bash
heroku login
```

# スタックを作成
Herokuのスタックというものを作成する必要があります。今回はheroku-22を選択しました。
```bash
heroku create --stack heroku-22
```

スタックを作成すると、添付画像の通り、Herokuのアプリケーションが作成されます。
![スクリーンショット 2023-08-20 10.24.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263017/66e8dadf-5798-97f0-3ee1-f6a8b0ff2931.png)

選択するスタックは以下の公式ドキュメントを参照。
https://devcenter.heroku.com/ja/articles/ruby-support#unsupported-ruby-versions

# プッシュ
**herokuへのプッシュをする前に、Gitのコミットを忘れずに行ってください。**
Herokuへプッシュする際に、ローカルのブランチ（例でfeatureブランチ）をHerokuのmainブランチにプッシュする。
```bash
git push origin feature
git push heroku feature:main
```

# マイグレーション
Railsのマイグレーションを実行するには、heroku runコマンドを使います。
```bash
heroku run rake db:migrate
```

# ブラウザで確認
HerokuのアプリケーションのURLをブラウザで確認します。
```bash
heroku open
```
![スクリーンショット 2023-08-20 10.35.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263017/a4814145-f09c-6f80-df64-e19c34afd7db.png)
[Node.js]　yarnとは何か

# 目的
rails6のアプリケーションを作成した際にyarnのインストールが必要だったため、yarnについて簡単にまとめた
# yarnとは
- npmと同じで、nodeのパッケージ管理マネージャー
- rails6ではWebpackerを標準で使い、Webpackerはyarnを使うのでインストールが必要になる。


# コマンド使用方法
####  初期化
```
# packeage.json作成
yarn init
```

#### インストール
```
yarn add パッケージ名
yarn add パッケージ名@x.y.z

# devDependenciesにインストール
yarn add パッケージ名　-dev

# グローバルインストール
yarn add global パッケージ名

# すべてインストール
yarn
```

#### アップデート
```
yarn upgrade パッケージ名
yarn upgrade
```

#### アンインストール
```
yarn remove パッケージ名
```

#### 実行
```
yarn パッケージ名
```

# 比較表
|　コマンド　 |　 npm 　|　 yarn 　|
| ---- | ---- | ---- |
| 初期化 | npm init | yarn init |
| インストール | npm i | yarn add |
| アップデート | npm update | yarn upgrade |
| アンインストール  | npm remove | yarn remove |
| 実行 | npx react パッケージ名 | yarn パッケージ名 |


## 参考にさせていただいた記事
[npmとyarnについて解説](https://zenn.dev/hinoshin/articles/aadfdd7ba958a9)
【統計の基礎2】大数の法則って、ナニ？

# 目次
[1.はじめに](#1-はじめに)
[2.大数の法則って、ナニ？](#2-大数の法則って、ナニ？)
[3.大数の法則を「見える化」](#3-大数の法則を「見える化」)
[4.参考](#4-参考)
[5.おわりに](#5-おわりに)

# 1. はじめに
統計の勉強を始めた時、「大数の法則」という専門用語にぶち当たりました。「法則」と付いたので、ビビりましたが、それほど、難しいものではないようです。

自分が理解した大数の法則について、まとめてみました。

# 2. 大数の法則って、ナニ？

最近のお気に入りのChat-GPTに、「大数の法則」を聞いてみました。

**大数の法則** (Law of Large Numbers):
サンプルサイズ（試行回数）が大きくなるほど、サンプルの平均が母集団の平均に収束すること

例：サイコロを振って平均を計算する場合、サンプルサイズが大きくなると、その平均は理論的な期待値である3.5に近づいていきます。

大数の法則は、たくさんのデータを使って平均を出すと、その平均が本当の平均に近づいていくという考え方です。

今度は、コインを何回も投げる実験を考えてみましょう。

1回目の試行では、表が出る確率と裏が出る確率はちょうど半々ですが、1回だけだと偶然の要素が強く影響します。でも、たくさんの回数（たとえば100回、1000回）投げると、表が出る平均がほぼ50%に近づいてくるんです。

これは、データの数が多くなるほど、ばらつきや偶然の影響が少なくなって、実際の確率に近づくということです。これが大数の法則の考え方です。

# 3. 大数の法則を「見える化」
では、本当に「大数の法則が成立するのか？」ということについて、Pythonを使って、グラフに見える化して、見てみましょう。

以下は、コイントスの結果を使って大数の法則を示すグラフを作成しました。サンプル回数が増えるにつれて、コイントスの平均が真の確率に近づいていく様子が分かりますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76072/8b2d1b2d-0150-6920-7e8b-6c79aeb78ba1.png)

最初は、バラツキが大きいですが、600回を超える当たりから、真の確率とほぼ等しいですね。こんなこと、人手では無理ですので、コンピュータの有難さを痛感します。

コードも参考までに載せておきます。

```python
import numpy as np
import matplotlib.pyplot as plt

# コイントス関数（表：1, 裏：0）
def coin_toss():
    return np.random.randint(2)

# コイントスを行う試行回数
num_trials = 1000

# 試行回数ごとに平均を計算して保存
averages = []
total_heads = 0

for trial in range(1, num_trials + 1):
    toss = coin_toss()
    total_heads += toss
    average = total_heads / trial
    averages.append(average)

# グラフ化
plt.figure(figsize=(10, 6))
plt.axhline(y=0.5, color='r', linestyle='--', label='True Probability')
plt.plot(range(1, num_trials + 1), averages, label='Running Averages')
plt.xlabel('Number of Trials')
plt.ylabel('Average')
plt.title('Law of Large Numbers')
plt.legend()
plt.grid(True)
plt.show()
```

# 4. 参考
大数の法則には2つの主要なバリエーションがあるようです。

**弱法則**（Weak Law of Large Numbers）: サンプルサイズが無限に大きくなるとき、サンプル平均は母集団平均に確率的に近づくという法則です。つまり、確率的な収束が成り立ちます。しかし、特定のサンプルサイズに対しても比較的小さな誤差で母集団平均に近づくことが期待されます。

**強法則**（Strong Law of Large Numbers）: サンプルサイズが無限に大きくなるとき、サンプル平均は母集団平均に確実に収束するという法則です。つまり、ほぼ確実にサンプル平均が母集団平均に一致することを示す法則です。弱法則よりも強い結果を提供しますが、一般的に証明が難しいです。

# 5. おわりに
大数の法則って、なんとなく、分かっていたつもりですが、いったん、自分の中で、整理できて良かったです。

サンプルサイズが大きくなれば、サンプルの平均が本当の平均に近づくっていうのは感覚的にも分かりますが、Pythonでシミュレーションできて良かったです。

この記事が、皆さんのお役に立てば、嬉しいです。

間違った点に対するご指摘や、ご意見などがあれば、ぜひとも、お願いいたします。
マサカリ、大歓迎です！

**（追伸）**
ちなみに、目次から、上手くリンクできない項目があります。どうすれば、上手くリンクできるか、ご存じの方がいたら、教えてください。
GitHubでの(SSH)Authentication/Signing Keyの設定

CLIでの認証/署名の設定手順をメモとして書き残しておきます。あくまでも最低限動くレベルのもので、ファイル名やパスフレーズにその他色々は、それぞれ適切に設定してください。

```bash:bash
cd ~ &&\
git config --global user.name <user name> &&\
git config --global user.email <email address> &&\
git config --global user.signingkey ~/.ssh/signing-key.pub &&\
git config --global commit.gpgsign true &&\
git config --global gpg.format ssh &&\
# id_ed25519 and id_ed25519.pub are generated in ~/.ssh/
ssh-keygen -t ed25519 &&\
# signing-key and signing-key.pub are generated in ./
ssh-keygen -t ed25519 -f signing-key &&\
mv ./signing-key ./.ssh/ && mv ./signing-key.pub ./.ssh/
```

ローカルでのコミットをGitHubにプッシュして、Verifiedになっていれば署名にも成功しています。以上。
Reactでaxiosを使ってレスポンスヘッダを取得する

# やりたかったこと
Reactでaxiosを使ってレスポンスヘッダ内のハイフン付きのvalueを取得する。
ハイフン付きの場合は角かっこで取り出す必要があった。

# ダメだった書き方
```tsx:ng.tsx
axios.post(url, req_body, { headers: headers })
  .then((res) => {
    console.log(res.headers.x-subject-token);
  }
```
この書き方だとVSCodeのPrettierに怒られて保存時にこのままの形で保存されなかった。

# 成功した書き方
```tsx:ok.tsx
axios.post(url, req_body, { headers: headers })
  .then((res) => {
    console.log(res.headers["x-subject-token"]);
  }
```
PHPでPOSTされた0と''(空文字)を判定する

先日同僚にこんな質問をされました。

「POSTされた値の0と""(空文字)を反映するにはどうしたらいいですか？」

普段何気なくやってたけど、即答できなかったので考えてみました。

## 先に結論
以下の`if`で判定できます。

``` index.php
<?php
if ($_POST) {
  if ($_POST['test'] === '') {
    echo '空文字です。';
  } else if ((int)$_POST['test'] === 0) {
    echo '0です。';
  } else {
    echo 'それ以外です。';
  }
}
?>
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <form action="/" method="POST">
    <input type="text" name="test">
    <button>送信</button>
  </form>
</body>
</html>
```

判定しているのは以下の部分です。

``` PHP
<?php
if ($_POST) {
  if ($_POST['test'] === '') {
    echo '空文字です。';
  } else if ((int)$_POST['test'] === 0) {
    echo '0です。';
  } else {
    echo 'それ以外です。';
  }
}
?>
```

## 解説
まずはPOSTされている値を調べます。

``` PHP
// ""でPOSTした場合
array(1) {
 ["test"]=>
 string(0) "" 
}

// 0でPOSTした場合
array(1) {
  ["test"]=>
  string(1) "0"
}
```

`''`でPOSTした場合、`string(0) ""`が返ってくるのは予想通りですが、`0`でPOSTして`string(1) "0"`が返ってくるのは??となるかもしれません。

これは、HTMLフォームから送信されたデータは、HTTPリクエストとしてサーバーに送信される際に、文字列として扱われるためです。そういう仕様なので、そういうものだと理解しましょう。

### 参考
[フォームでPOST されたデータは全て文字列になる?PHP小話](http://ksk2aki.xsrv.jp/wp/programming/form_post_string/)
[PHPの質問です。POSTで配列を受け取ると全て文字列に変換されてし... - Yahoo!知恵袋](https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14209347674)

## 判定してみよう！
`""`と`0`は、`==`で比較するとどちらも`false`になるので、`===`で比較してやればいいです。

``` PHP
if ($_POST['test'] === '') {
  echo '空文字です。';
} else if ((int)$_POST['test'] === 0) { // (int)で型キャストして数値にする
  echo '0です。';
} else {
  echo 'それ以外です。';
}
```

これでうまく`""`と`0`を判定できます。

## ChatGPTに聞いてみた

``` 
phpでフォームを作っています。
input[type="text"]要素の''（空文字）と0 を判定したいです。
以下のコードで判定できますか？

<?php
if ($_POST) {
  if ($_POST['test'] === '') {
    echo '空文字です。';
  } else if ((int)$_POST['test'] === 0) {
    echo '0です。';
  } else {
    echo 'それ以外です。';
  }
}
?>
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <form action="/" method="POST">
    <input type="text" name="test">
    <button>送信</button>
  </form>
</body>
</html>

ChatGPT
はい、提供されたコードは、input要素の値が空文字 ('') か、または整数としての値が0かを正しく判定するためのコードです。以下でコードの詳細を確認しましょう。

ユーザがフォームを送信すると、PHPスクリプトは$_POST スーパーグローバル配列を介してデータを処理します。
最初に、フォームのinput要素の値が空文字 ('') かどうかをチェックします。もし空文字なら、'空文字です。'というメッセージが表示されます。
次に、input要素の値を整数にキャストし、その値が0と等しいかを判定します。もし0なら、'0です。'というメッセージが表示されます。
上記の条件に該当しない場合は、'それ以外です。'というメッセージが表示されます。
```

あってるみたい。
複数のコミットをまとめる方法

# 0. まとめ

1. rebase -i でコミットをまとめる（例：`git rebase -i HEAD~2`）
2. テキストエディタが開くので、集約先の `pick` はそのままにして、集約によって消したいコミットの `pick` を `s` または `squash` に変更する
    - vim の場合、`:wq` で保存して終了
3. 再度テキストエディタが開くので、残したいほうのコミットのコメントを編集。
    - vim の場合、`:wq` で保存して終了
3. `git push -f origin (ブランチ名)` でプッシュ

# 1. コミットをまとめるときに注意すること

- 共同開発のリモートブランチに安易に git push -f するのは危険なので注意すること
    - `push -f` はリモートリポジトリに既に公開されているコミット履歴を改変してしまうので、他のメンバがpushしたコミットを上書きしたり削除してしまう可能性があります。

# 2. 詳細手順

rebase -i でコミット２つをまとめたいとする。

ひとまず `git rebase -i`。
（`-i (--interactive)`で過去のコミットを編集できます）

```
$ git rebase -i HEAD~~
```  
または
```
$ git rebase -i HEAD~2
```

するとテキストエディタが開き、HEADから2つ分のコミットが表示される。

```
pick b71985f commit A
pick 32eea59 commit B

# Rebase 7a54171..32eea59 onto 7a54171 (2 commands)
（以下略）
```

集約先のコミット（残したいコミット）の `pick` はそのままにして、集約によって消したいコミットの `pick` を `s` または `squash` に変更する：

```
pick b71985f commit A
s 32eea59 commit B

# Rebase 7a54171..32eea59 onto 7a54171 (2 commands)
（以下略）
```

`:wq` で保存して終了。

すると、再度テキストエディタが開：

```
# This is a combination of 2 commits.
# This is the 1st commit message:

commit A comment

# This is the commit message #2:

commit B comment
（以下略）
```

残したいほうのコミットのコメントを好きなように編集する：

```
# This is a combination of 2 commits.
# This is the 1st commit message:

commit A comment + commit B comment

# This is the commit message #2:

# ここを消した
（以下略）
```

`:wq` で保存して終了。

最後にプッシュ：

```
git push --force-with-lease origin (ブランチ名)
```

`--force-with-lease` オプションは、リモートブランチが最後にフェッチした時点から変更されていない場合にのみ強制プッシュを実行します。これにより、他の開発者が変更を誤って上書きしてしまうリスクを軽減できます。

以上。

# 参考になる記事

- [rebase -i でコミットをまとめる](https://qiita.com/takke/items/3400b55becfd72769214)
- [【Git】離れた複数のcommit（コミット）をまとめる方法](https://www.engilaboo.com/summarize-multiple-commits/)
- [git rebaseでsquashした場合とfixupした場合の違い](https://qiita.com/shyamahira/items/47557acfe88ba392561e)
[プロトコルバッファ] protoc-gen-go: program not found or is not executable の解決方法

## 概要

Go言語で分散サービスを書く方法を学びたいと思い立ち、「[Go言語による分散サービス
―信頼性、拡張性、保守性の高いシステムの構築]」(https://www.oreilly.co.jp/books/9784873119977/) で勉強を始めました。
その中「2.4 プロトコルバッファのコンパイル」で次のエラーで困った時の解決法のメモです。

```console
~/proglog/StructureDataWithProtobuf$ protoc api/v1/*.proto --go_out=. --go_opt=paths=source_relative --proto_path=.
protoc-gen-go: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--go_out: protoc-gen-go: Plugin failed with status code 1.
```

protoc-gen-go は、プロトコルバッファ　ランタイムと呼ばれるもので、コンパイラをインストールとともに、ランタイムが必要となります。


## Protobuf コンパイラのインストール

コンパイラーとランタイムは、それぞれ異なるリポジトリで管理されているので、それぞれからダウンロードして、インストールしなければなりません。

- `https://github.com/protocolbuffers/protobuf/releases/tag/v24.1`

この実行例では、インストール先は、`/usr/lcoal/protobuf`にしました。
バージョンはリリースページを参照して、執筆時の最新を指定してあります。

```
COMPILER_VER=24.1
$ curl -OL https://github.com/protocolbuffers/protobuf/releases/download/v${COMPILER_VER}/protoc-${COMPILER_VER}-linux-x86_64.zip
$ sudo unzip protoc-${VER}-linux-x86_64.zip -d /usr/local/protobuf
```

インストールすると、下記のようにインクルードファイルも一緒に展開されます。

```
$ tree /usr/local/protobuf/
/usr/local/protobuf/
├── bin
│   └── protoc
├── include
│   └── google
│       └── protobuf
│           ├── any.proto
│           ├── api.proto
│           ├── compiler
│           │   └── plugin.proto
│           ├── descriptor.proto
│           ├── duration.proto
│           ├── empty.proto
│           ├── field_mask.proto
│           ├── source_context.proto
│           ├── struct.proto
│           ├── timestamp.proto
│           ├── type.proto
│           └── wrappers.proto
└── readme.txt
```


## Protobuf ランタイムのインストール

次のランタイムも、ビルド済の実行形式を`/usr/local/protobuf/bin`にインストールします。

- `https://github.com/protocolbuffers/protobuf-go/releases`


```
RUNTIME_VER=v1.31.0
$ curl -OL https://github.com/protocolbuffers/protobuf-go/releases/download/v1.31.0/protoc-gen-go.${RUNTIME_VER}.linux.amd64.tar.gz
$ sudo tar xzvf protoc-gen-go.${RUNTIME_VER}.linux.amd64.tar.gz -C /usr/local/protobuf/bin
```

## パスの設定

Makefileで実行できるように、PATHを追加します。

```
export PATH=$PATH:/usr/local/protobuf/bin
```


## 実行結果の確認

次のように、コマンドを実行できればOKです。

```
$ ls -la /usr/local/protobuf/bin
total 14384
drwxr-xr-x 2 root root    4096  8月 20 08:38 .
drwxr-xr-x 4 root root    4096  8月 20 07:51 ..
-r-xr-xr-x 1 root root 8532152  1月  1  1980 protoc
-rwxrwxr-x 1 root root 6184960  1月  1  1970 protoc-gen-go

$ protoc --version
libprotoc 24.1

$ protoc-gen-go --version
protoc-gen-go v1.31.0
```



## 参考リンク
- https://protobuf.dev/
- https://github.com/protocolbuffers/protobuf
- https://github.com/protocolbuffers/protobuf-go
【serverlessフレームワーク】eventsを設定したのにエンドポイント設定されない

# はじめに
プログラミング学習中の[@kat_log](https://twitter.com/kat__log "Twitter")と申します。

serverless flameworkの学習にて起きた問題の解決メモになります🙇
`serverless-api-gateway-throttling`を使用し、
serverless.ymlに、AWSのLambdaのAPIをインターネットに公開するeventsを記載したのに、npx serverless deployにてデプロイしてもエンドポイントが作られない問題が発生し、解決しました🙌
（超凡ミスでした…）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1455073/99b4d609-b9d1-40e6-bef0-0958469511c1.png)


# 結論
serverless.ymlのインデント設定ミスでした…

## 誤
```serverless.yml
  hello:
    handler: src/hello.handler
    events:
      - httpApi:
        method: get # ←←←←←←ココです
        path: /hello # ←←←←←←ココです
```

## 正
```serverless.yml
  hello:
    handler: src/hello.handler
    events:
      - httpApi:
          method: get # ←←←←←←ココです
          path: /hello # ←←←←←←ココです
```


エンドポイントが追加されました！🙌↓

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1455073/c7ea6e9b-d9bd-867d-a823-03ac75bb63f4.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1455073/e6bb1b7a-8490-5013-62e2-2b85ce13ffb7.png)

# おわりに
お読みいただきありがとうございました！
どなたかの参考になれば嬉しいです。
Linux導入してSSH設定してcygwinからshutdownして電源落ちなかった件

世の中には、失敗談があるものの、改善の方向がずれている話が多くうんざりすることがある。　


Linux導入してSSH設定してcygwinからshutdownして電源落ちなかった件は、
SSH設定してcygwinからshutdownしてみて、電源が落ちるか確認すればよかっただけ。　

どうしてそうしなかったかというと、　
SSHを設定するのが、時間的に遅かったから。　

計画的行動ではなかったとも言える。　

Terraform で Linux VM 作成して SSH するまで

https://qiita.com/e99h2121/items/00781afec389a8b8e85e

読んで、しまった、自分の事例紹介書いてなかったと思い出した。　

# 参考資料　
計算機系事故記録(computer system trouble record)
https://qiita.com/kaizen_nagoya/items/910847f01379903e40c8

系(system)障害連絡の方法(method)、手段(media)、手順(manner)
https://qiita.com/kaizen_nagoya/items/29fc83a1eb1325a866d1

「配電盤の電源を切る」
https://qiita.com/kaizen_nagoya/items/5fee2f3a4fb3cede675c

「何もしていないのに壊れた」インフラエンジニアの対応例 https://qiita.com/kaizen_nagoya/items/49c58fa6f4278717d061

今朝、Windows 10が起動しませんでした。
https://qiita.com/kaizen_nagoya/items/7abd326181d1458c2832

フルスタックエンジニア　どこからどこまで
https://qiita.com/kaizen_nagoya/items/d365e3f9e15d9b182dce

 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong. 

# 文書履歴(document history)
ver. 0.01 初稿　　20230819

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

####  Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.
【コード管理/GitHub】git pushしてもEverything up-to-dateと言われてリモートリポジトリにpushできない

# 今回の課題
ローカルの`feature/1`ブランチ内でコードを変更して以下のコマンドを実行したのだが、
`Everything up-to-date`と言われてしまい、リモートリポジトリに変更したコードを反映させることができなかった。
```cl
$ git add .
$ git commit -m "message"
$ git push origin main
```
`$ git log`でファイルの変更がcommitできていることが確認することができたので、**`$ git push`がうまく実行できていない**ことが原因のようだった。


## 解決策
結論から言うと、以下のコマンドを実行することで解決することができた。
以下のコマンドは、ローカルブランチ(`feature/1`ブランチ)のリモート追跡ブランチを設定している。
```bash
# リモート追跡ブランチを設定
$ git branch -u origin/feature/1
# git branch -u <リモート追跡ブランチ>

# リモート追跡ブランチを設定してからpushする
$ git add .
$ git commit -m "message"
$ git push origin main
```


## なぜ上記の方法で解決できたのか
今回不具合が発生した原因としては、**`feature/1`ブランチのリモート追跡ブランチ**を設定していなかったことだった。
そのため、リモート追跡ブランチの設定をしてからgit pushすることで解決することができた。

リモート追跡ブランチを設定するには、上記のようなコマンドを実行してリモート追跡ブランチを設定するか、
最初にリモートリポジトリにプッシュするときに、`$ git push -u origin <リモート追跡ブランチ>`というコマンドを実行する必要がある。

### 不具合を発生させてしまうまでの経緯
以下の流れで進めてしまったことで、
`feature/1`ブランチのリモート追跡ブランチが設定されておらず、不具合が発生してしまった。

1. `feature/1`ブランチにて`$ git push origin main`を実行。(ここでリモート追跡ブランチを設定し忘れている)
1. `feature/2`ブランチに切り替えて作業をして`$ git push origin main`を実行。
1. `feature/1`ブランチに切り替えて作業をして`$ git push origin main`を実行。<font color='red'>←ここでEverything up-to-dateが発生<font>

上記だと、各ローカルリポジトリに、リモート追跡ブランチが設定されていない。
リモート追跡ブランチの設定ができていない状況でブランチを切り替えて作業してしまったことで、
`feature/1`ブランチに戻して`$ git push origin main`を実行しても、
`feature/1`ブランチがどのリモートリポジトリにpushすればいいのか分からなくなってしまっていた。



### 不具合を発見した方法
今回は、リモート追跡ブランチを確認するコマンドを実行して、不具合を発見することができた。
`git branch -vv`を実行することで追跡しているリモートブランチを確認することができる。

例えば、今回の件は以下のように、`main`ブランチには`origin/main`を追跡するように設定されていたが、
`feature/1`ブランチと`feature/2`ブランチに追跡するリモートリポジトリが指定されていない状態となっていた。
```
feature/2            99630ef (git commit時のmessage文)
feature/1            b4cb9e2 (git commit時のmessage文)
main                 99630ef [origin/main] (git commit時のmessage文)
```
そこで、`$ git branch -u origin/feature/1`コマンドを実行することで、
以下のように`feature/1`が追跡するリモート追跡ブランチが設定することができる。
```
feature/2            99630ef (git commit時のmessage文)
feature/1            b4cb9e2 [origin/feature/1](git commit時のmessage文)
main                 99630ef [origin/main] (git commit時のmessage文)
```

# まとめ
複数のブランチを切り替えて異なる作業をする場合、
**リモート追跡ブランチ**を設定するのを忘れないようにしないと、git pushができなくなってしまう。





# おまけ：他に試したこと
### リモートリポジトリを確認
以下のコマンドを実行して、`$ git push origin main`している先が、意図しているリモートリポジトリになっているかの確認をした。
```bash
$ git remote -v
```
こちらのコマンドを実行すると以下のように返ってくるので、
ここでoriginにgit pushしたいリモートリポジトリが設定されているか確認をした。
```
origin    git@github.com:********.git (fetch)
origin    git@github.com:********.git (push)
```
※今回はoriginにpushしたいリモートリポジトリが設定できたいたので問題がなかった。
しつけ(discipline)

辞書作成、翻訳、言語教育で、辞書に掲載している訳語について、最初に教えておけば、無駄な議論、論争を避けることができる。　

先におしえておかない失敗を繰り返さないための記録です。

子供の頃は、「しつけ」という言葉が嫌いだった。

勉強しなさいという押し付けの一種だと思っていた。　

「ひょっこりほうたん島」という人形劇に出てくる歌にある。　

勉強なさい　（海賊キッドの宝の巻編） ひょうたん島

https://www.nicovideo.jp/watch/sm26582619

https://www.youtube.com/watch?v=U3FNag1IGEM

https://www.youtube.com/watch?v=yza5tEca9Is&t=7s

# 言語学　

言語学のある流派では、言葉の意味は一つで、状況の違いと、立場の違いによって、意味の捉え方の違いがあるだけだという主張がある。　

ほとんどの単語は、一つの意味で済むことがほとんど確認できている。　

発話した人の立場と、受け止めた人の立場が違えば、意味が違うのは当たり前のことだ。　

辞書に、いくつも意味が書いてあるんは、状況の違い、立場の違いを考慮して翻訳する時のための用語である。　

意味の違い、訳語の違いを載せているわけではない。　

# discipline
規律という漢語を載せている辞書がある。　
学術翻訳の場合には、漢語に置き直す方が簡単だからだろう。　

しつけという訳語を提示している辞書もある。

## 学問領域　
化学の実験では、危険を伴うことがある。　
どの範囲の実験を行うかで、どの範囲の安全教育をする必要があるかが変わる。　
　
教育では、しつけの範囲と学問領域の範囲が、１対１対応で決定できる。　

教える側は、安全教育の範囲を意識し、教わる側は、教わる教育内容の範囲を意識する。　

言葉の意味が違うわけではない。




 ＜この記事は書きかけです。順次追記します。＞
 This article is not completed. I will add some words in order.

 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong. 


# 文書履歴(document history)
ver. 0.01 初稿　　20230820

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

####  Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.
Swin Transformer: Hierarchical Vision Transformer using Shifted Windowsのメモ

# [Swin Transformer: Hierarchical Vision Transformer using Shifted Windows, Ze et al, 2021](https://arxiv.org/abs/2103.14030)

1. Introduction
    - 言語のtokenは固定スケールだが、画像ではそうではない（単語の数が固定ということ？）
    - 画像はself-attentionで2次で計算量が増えてしまう
    - →階層的な特徴マップで、画像サイズに線形計算量のSwin Transformerを提案
    - 画像を領域に区切り、その中のパッチだけでattentionする
        - 領域は変えていくので、パッチはまじりあう
        - ウィンドウ内のすべてのクエリ パッチは同じキー set1 を共有する（？？）
1. Method
    - 流れ
        1. 画像を4x4のパッチに分割→各パッチは4x4x3(ch)=48次元→C次元へ変換される(W/4×H/4×C)
        2. Swin Transformerをかける
        3. 隣接するパッチを統合(W/8×H/8×4C)
        3. 特徴変換(W/8×H/8×2C)
        3. Swin Transformerをかける
        3. 2~5を繰り返す
    - vggとかみたいに、チャネルが増えて、解像度が下がっていく
    - Shifted Window based Self-Attention
        - 普通は全パッチ間とのself-attention(global self-attention)をするので、画像だと計算量が2次で増えていく
        - ローカルウィンドウ内だけで、self-attentionすることにする
        - でもウィンドウ間の関係がとれない→ウィンドウの境界をまたぐように、別のウィンドウでもう一回ローカルself-attentionする
    - Efficient batch computation for shifted configuration
        - ウィンドウをシフトするとウィンドウ内の画像の大きさが変わって計算しづらい
        - A, B, Cみたいな部分を右下にもっていくと、ウィンドウをシフトしても、ウィンドウ内の画像の数は一緒なので、計算しやすい！(A, B, Cみたいなほんとは隣接してない部分はマスクして考慮しない)
    - Relative position bias
        - 絶対位置の全組み合わせのpeをやる代わりに、相対位置の組み合わせをpeすることで、計算量が下がる
    - Architecture Variants
        - 各モデルのバリエーションは以下。{}内は各レイヤーのswin transformerブロックの数、fig3がSwinTと思うとわかりやすい。
        - Swin-T: C = 96, layer numbers = {2, 2, 6, 2}
        - Swin-S: C = 96, layer numbers ={2, 2, 18, 2}
        - Swin-B: C = 128, layer numbers ={2, 2, 18, 2}
        - Swin-L: C = 192, layer numbers ={2, 2, 18, 2}

4. Experiments
    - image net
        - 事前学習無し
            - imagenetの結果は同様の複雑さのDeiTより良い
            - Conv系よりわずかによい
        - 事前学習あり
            - vitよりよい
    - 絶対位置埋め込みは分類精度は上がるが、ほかのタスクは下がる。

参考
- [【論文5分まとめ】Swin Transformer](https://zenn.dev/takoroy/articles/e8c9e2903096b8)
Windows ServerでDockerのexperimentalオプションを有効にする

## 手順
### 1. Dockerを一旦停止する

Powershellで以下のコマンドを実行
```
Stop-Service docker
```

### 2. daemon.jsonを変更
ファイルパスは`C:\ProgramData\docker\config\daemon.json`のはず。
`"experimental": true` を追加する。

```
{
    "experimental": true,
    "hosts":  [
                  "npipe://"
              ]
    ...
}
```

### 3. Docker再起動

```
Start-Service docker
```

### 4. 設定が変更されたことを確認

```
docker version
```

結果
```
Client:
 Version:           xx.x.x
 API version:       x.xx
 Go version:        gox.xx.x
 Git commit:        xxxxxxx
 Built:             xxxxxxxxxxxxx
 OS/Arch:           windows/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          xx.x.x
  API version:      x.xx (minimum version x.xx)
  Go version:       gox.xx.x
  Git commit:       xxxxxxxx
  Built:            xxxxxxxxxxxxxxxxx
  OS/Arch:          windows/amd64
  Experimental:     true
```

Experimental=trueになった！
Wi-Fi 6 (IEEE 802.11ax)と EasyMesh の疑問を検証してみる（その２）

# EasyMeshに興味がある

ウチでは一部の部屋に電波が届きづらい。その部屋、有線を引くにはハードルが高い。
そういうわけで、EasyMeshに興味がある。だけど、実際にどのくらい速度が出るかはさっぱり情報がない。検証する。

# 検証の概要
WSR-3200AX4Sを親機、（コントローラー）
WSR1-800AX4を子機（エージェント）として接続する。
子機のスイッチをWBモードにして親機と有線でつなぐと、マニュアル通り何もしなくても EasyMesh として構成される。この時点では親機と子機の間で通信を行うバックホール(backhaul)は有線接続ということになる。

# 親機に有線接続して速度測定

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176228/ec9e0255-2ae7-fd37-a58b-0abfc8263db2.png)


ギガビットイーサネットくらいの速度が出ている。

# 子機に有線接続して速度測定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176228/af6bb899-6583-375d-83f0-e7820989c8a9.png)

誤差がある程度。

# 有線バックホールを外して無線バックホールに切り替え

親機と子機の有線接続を切り離す。自動的に無線バックホールに切り替わる。
無線バックホールは11ax、80Mbps、2x2ストリームの1201Mbpsになっているはず。
Buffalo の管理画面からはリンク状態を確認できないので、推測です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176228/53e91b82-d625-639d-3141-6955d4e7116f.png)

黒いケーブルが外した有線バックホール。EasyMesh 、至近距離でこのくらいの速度。

# 電波が届きづらい部屋に移動
この部屋で快適にネットを使うのが、本来の目的。
部屋のすみっこ、一番親機に近い場所が電波が届きやすいのでそこに子機を設置。電波状況はこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176228/568299f7-b26b-2ab0-4d02-b7e6cc7689eb.png)





有線直結よりはもちろん遅いが、エコノミークラスの WSR-1800AX4 でこのくらいなのだから、良しとしよう。
子機もWSR-3200AX4（80Mhz4ストリーム=2400Mbps）なら、もっと出るのかもしれない。
親子ともWSR-5400AX6（160Mhz4ストリーム=4800Mbps）なら、もっともっと出るかもしれない。
いつかお金があったら試してみたい。

つづく、かもしれない。