OmniAICreator/Qiita-1.07M huggingface dataset:
Katacodaのshell環境からホスト情報を取得する方法

# はじめに

KatacodaのPlaygroudのシナリオを作成する際、ホスト情報(サブドメイン、ホスト)は実行する度に変わるため、markdownに記載する変数が定義されています。

- [[KATACODA_HOST]]　　・・ホスト
- [[HOST_SUBDOMAIN]]　　・・サブドメイン

例えば、最初(1番目)のシナリオとして以下のように記載します。

```markdown: step1.md
起動できたら以下のURLを開いて、MQTT over WebSocket (チャット) を体験してみましょう！
https://[[HOST_SUBDOMAIN]]-1880-[[KATACODA_HOST]].environments.katacoda.com/chat
Node-REDのフローを確認したい場合は以下のURLを開いてください。
https://[[HOST_SUBDOMAIN]]-1880-[[KATACODA_HOST]].environments.katacoda.com
```

シナリオを実行すると、変数の部分はその時に実行された環境(ホスト情報)に置き換えられます。

![katacoda_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/72479/c9c37717-ebba-0dec-0dca-e480a431f74b.jpeg)

![スクリーンショット 2022-05-06 1.20.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/72479/d052f7ec-0a73-fa92-c10b-682f11d6c3df.png)

ポート番号はプログラムを実行する際にbind (Listen)するポート番号と同じため、変数は定義されていません。

# 問題点

shell環境 (Terminal)からはホスト情報を参照することができないため、例えば、プログラムからホスト情報を参照して何か処理をしたい場合、代替手段を検討する必要があります。
(envコマンドで環境変数を確認したところ、ホスト情報は設定されていませんでした)

![katacoda_3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/72479/233209ea-bf5d-f598-e30c-504dd703672c.jpeg)

# 解決方法

Katacodaのシナリオ実行環境の設定(environment)で、UIレイアウト(uilayout)の設定をterminalではなく、vscode-terminal-splitに設定すると、VS Codeエディタが起動します。

```json:index.json
{
  "title": "MQTT over WebSocket Playground",
  "description": "MQTT over WebSocket Playground",
  "details": {
    "steps": [
      {
        "title": "Step 1",
        "text": "step1.md"
      }
    ],
    "intro": {
        "text": "intro.md",
        "courseData": "background.sh",
        "code": "foreground.sh",
        "credits": ""
    },
    "finish": {
      "text": "finish.md"
    }
  },
  "environment": {
    "hideintro": true,
    "showdashboard": true,
    "dashboards": [{"name": "Node-RED", "port": 1880}],
    "uilayout": "vscode-terminal-split"
  },
  "backend": {
    "imageid": "ubuntu"
  }
}
```

![image_4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/72479/baff5181-e65a-fbc7-de8b-c8f59b66409f.jpeg)

VS Codeの設定ファイル(coder.json)の中にホスト情報が記載されていることを見つけました。

![image_5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/72479/2e3c8c90-bd7a-0829-8aed-24a9c5343017.jpeg)

### プログラムからホスト情報を参照する実装例

ホスト情報が記載されているファイル名を参照して、プログラムが使用するポート番号に変更(23000→1880)します。

```bash
$ grep url /root/.local/share/code-server/coder.json | sed 's/\// /g' | sed 's/-/ /g' |awk '{print "https://" $4 "-1880-" $6}'
167772191-1880-ollie09.environments.katacoda.com
```

プログラムからホスト情報を参照する際にファイルへアクセスするのは面倒なため、環境変数を設定します。

```bash
$ export HOSTNAME=`grep url /root/.local/share/code-server/coder.json | sed 's/\// /g' | sed 's/-/ /g' |awk '{print $4 "-1880-" $6}'`
$ echo $HOSTNAME
167772191-1880-ollie09.environments.katacoda.com
```

環境変数へ設定した後にプログラムを実行すればプログラムの中からホスト情報を参照できるようになります。

では、良きKatacodaライフを！

### 参考

MQTT over WebSocketを体験する目的でチャットシステムを作りました。
静的コンテンツ(HTML)でブラウザ(Javascript)からKatacoda環境へアクセスするため、HTML(Javascript)の中にホスト情報を埋め込む必要がありました。

https://qiita.com/kitazaki/items/37ee2fb64b12522b6c8b

https://www.katacoda.com/kitazaki/scenarios/mqtt-over-websocket-playground
VirtualBoxでNAT構成を作る

## はじめに
VirtualBoxでネットワークを組む場合、ブリッジアダプターを使うのが最も簡単だが、社内ネットワークにいると勝手にノードを増やせないこともしばしば。
なので今回はNAT構成を組んでみることにする。NAT構成にすれば自ホストをゲートウェイとするサブネットを新しく構築するので、好きなだけノードを増やすことができる。
もちろん社内ネットワークによってはできないこともあるので、ネットワーク責任者に確認をとってもらいたい。


## 設定
VirtualBoxの仮想マシンのネットワーク設定画面を開き、以下のように設定する。
|アダプター|割り当て|
|:-:|:-:|
|アダプター1|ホストオンリーアダプター|
|アダプター2|NAT (NATネットワークと間違えないように)|
|アダプター3|なし (必要な場合は適宜)|
|アダプター4|なし (必要な場合は適宜)|

ホストオンリーアダプターはホストからゲストへ、NATはゲストからホストへ通信するときに使用する。

## LinuxのIPアドレス
VirtualBoxにゲストOSをインストールしたら、ホストオンリーアダプターのほうは固定アドレス、NATのほうはDHCPで設定する。
固定アドレスにはホストネットワークマネージャーで設定されているサブネットから割り当てる。デフォルトでは 192.168.56.0/24 となっていると思う。
AWS EC2で時刻同期する際の備忘録（ubuntu20.04LTS版）

AWS EC2で時刻同期する際の備忘録です

OSは`ubuntu20.04LTS`
```
$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
```

初期では、時刻は9時間前（UTC）となっていた

```
$ date
Thu May  5 16:28:53 UTC 2022
```

`sudo timedatectl set-timezone Asia/Tokyo`を実行すればOK（JSTにする場合）

> [Ubuntu 20.04 LTS タイムゾーンの変更（時刻合わせ：timedatectl）](https://compass-note.hatenablog.com/entry/ubuntu2004LTS-timezonctl)

```
sudo timedatectl set-timezone Asia/Tokyo
```

`date`実行して期待する時刻となっていることを確認

```
$ date
Fri May  6 01:35:27 JST 2022
```

# 参考
[Ubuntu 20.04 LTS タイムゾーンの変更（時刻合わせ：timedatectl）](https://compass-note.hatenablog.com/entry/ubuntu2004LTS-timezonctl)
[Amazon EC2のタイムゾーンを日本時間に変更する方法](https://qiita.com/drapon/items/2fc5b21a9cdc31ddb152)
[AWS のタイムゾーンを UTC 協定世界時から JST 日本標準時に変更](https://hapicode.com/server/aws-timezone.html#cron-実行時間に-jst-反映-timezone-設定)
シェルスクリプトのwhileループで日付が変わったら実行する際の備忘録

シェルスクリプトのwhileループで日付が変わったら実行する際の備忘録
（`cron`や他の方法でも同じことが可能であるが、設定の手間を省きたくなるべくシェルスクリプト内で処理を完結したかった）

`date +"%Y%m%d"`により日付を取得して数値比較すればよい

```sh:test.sh
PRE_DATE="00000000"
while true
do
    # check date
    CURRENT_DATE=`date +"%Y%m%d"`    
    if [ ${CURRENT_DATE} -eq ${PRE_DATE} ];then
        echo "date not updated. ${CURRENT_DATE}"
        sleep 1
        continue
    fi
    echo "date updated !! ${PRE_DATE} --> ${CURRENT_DATE}"
    PRE_DATE=${CURRENT_DATE}
done
```

実行

```sh
$ bash test.sh
date updated !! 00000000 --> 20220505
date not updated. 20220505
date not updated. 20220505
date not updated. 20220505
date not updated. 20220505
date not updated. 20220505
date not updated. 20220505
```

もっと良い方法がある気がする、、
kubectlコマンドの(個人的)分類


# kubectlコマンド分類

Kubernetesの資格試験を受けるための準備として、以下のリファレンスを参考に、kubectlコマンドを分類してみました。
※ どのようなシーンでどのコマンドが使えるのかを覚えやすくするための分類であり、あくまで個人の独断と偏見に基づくものとなります。

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

![kubectl.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705474/581cf0a8-d8a5-4082-515e-3755310476da.jpeg)
UnityEditorを手動で入れた後にモジュールを追加する方法

UnityEditorを手動で入れた後にモジュールを追加する方法です。UnityHubだと設定ボタンから追加できますが、手動で入れると表示されないため、追加するための手順です。

# 前提
* M1 Mac（おそらくWindows、IntelMacも同じです）
* Unity2021.2.11f1

# 手順
1. 新しいプロジェクト（なんでもOK）を作成し、モジュールを追加したいバージョンのUnityで起動します。
1. BuildSettingsを開きます。
1. 追加したいPlatformを選択し、OpenDownloadPageを押すと、対象のpkgファイルがダウンロードできます。
![Build_Settings_と_avatavi__Git_.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/5f0753a6-386c-333a-5790-094f572632ca.png)
1. ダウンロードしたpkgを実行してインストールします。
    1. このソフトウェアは開けませんダイアログが出て進めない方は、下を参照ください

## このソフトウェアは開けませんダイアログが出て進めない
1. このダイアログが出る
![ダウンロード_と_Unity.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/013ea513-29f5-70f1-fba5-8deedf0be815.png)
1. pkgをダブルクリックではな、右クリックで選択し、表示されるメニューの`開く`から開く
1. 同じようなメッセージが出るが、今度は開くボタンがでてくるのでそちらを選ぶ
![ダウンロード.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/5bc3ae73-e4a9-f396-9858-5ce7bd1aab95.png)

## Androidも同じやりかたでできるんですが・・・
![Build_Settings_と_Unity_と_Unity_Hub_3_0_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/506075/ceb3c64c-8e98-e7ff-5fc7-bb516853101e.png)

### 注意！
OpenJDK, SDK, NDKを追加する方法がわかりませんでした。
LTS版の2021.3.0f1もインストールしていたので、そっちでインストールしてあったものをPrefarencesから設定しました。
CloudRunからCloudSQL / Firestore / MemoryStore(Redis) / GCSのキャッシュ性能ベンチマーク

アプリケーションを運用していると、なんかちょっと重いな、と感じることがある。そこでキャッシュを検討するのだが、Laravel on CloudRunの環境を使っていると、なにがよいのか悩んだのでベンチマークを取ってみることにした。

# 結論

| 選手 | MemoryStore(Redis) | CloudSQL | Firestore | GCS |
|:-:|:-:|:-:|:-:|:-:|
| Write | 0.0006 | 0.01  | 0.01 | 0.14  |
| Read | 0.0006 | 0.003 | 0.01 | 0.15 |
| 備考 | 固定費がかかる | 固定費がかかる | 同一キーには1秒に1回書き込み制限 | 参考程度 |

単位は秒。1000回実施時のざっくり平均から算出。だいたい予想通りであった、Redisがめちゃくちゃ速い。がしかし、固定費がかかる。サーバレスVPCコネクタとRedis自体で月に数万円の出費増となるわけである。CloudSQLだけでも数万円かかっているので悩むところである。

# 環境

- Cloud Run 1core 256MB 
- PHP 8.0 pecl grpc/protobuf/redis install
- Redisは4GBのもの
- Serverless VPC Connectorは標準スペック
- コールドスタートから10回連続で実施、各ストレージに1000回書き込み、1000回読み込みをおこなった
- GCSは参考程度なので1回書き込み、10回読み出しとした

# どう使い分けていくか

まず遅いところから言うと、たとえば認証ユーザにしかGCSの画像を読ませない、といった処理では、ファイルサイズにもよるがFirestoreにキャッシュすることで10倍程度高速化が見込めるといえる。

同様に外部APIを叩きに行く処理なんかは、レスポンスJSONをfirestoreに格納しておくのは全然ありかもしれない。1ドキュメントあたり1MB上限なのだけ注意な。

次に、Firestore/CloudSQLの取得結果だが、これはRedisを使うしか高速化しない。あるいは、マスタデータのようなものであれば、apcuのようにインスタンスごとのキャッシュもありかもしれない。

ただもしかすると、複雑な処理や大量のクエリが発生している場合、中間とりまとめをそれぞれのDB自身にキャッシュすれば、20クエリ分が1クエリで済むという可能性はある。こちらもCDNに乗せられないログイン後のページ処理で使うともしかするとありかもしれない。読み書き回数にもよるが大幅にコストが削減できる可能性がある。

## その他

もしかして、コールドスタート時はCloudSQLやRedisにつなぎに行くときにコネクション貼るのにちょっと時間がかかるんじゃないかという仮説も立てていたが、そんなことはなさそうであった。
【Swif】Unitテスト入門してみた！【コードつき】

# 目的
Unitテストに触れること
Unitテストへの抵抗を少なくすること


# 目次
テスト**される**関数
テスト**する**関数

👇 **全体コード**
ViewController.swift
UnitTest_1Tests.swift


# テストされる関数
```ViewController.swift
// 足し算, 10 + 20 -> 30
func add(num1: Int, num2: Int) -> Int {
    num1 + num2
}

// 引き算, 10 - 20 -> -10
func sub(num1: Int, num2: Int) -> Int {
    num1 - num2
}
```

# テストする関数
```UnitTest_1Tests.swift
func testAdd() throws {
    let result = Calclator().add(num1: 10, num2: 20)
        
    XCTAssertEqual(result, 30)   // 30 = 10 + 20
}
    
func testSub() throws {
    let result = Calclator().sub(num1: 10, num2: 20)
        
    XCTAssertEqual(result, -10)   // -10 = 10 - 20
}
```

# ViewController.swift

```ViewController.swift
import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .yellow   // 背景色
    }
}

// MARK: - UnitTest
struct Calclator {
    func add(num1: Int, num2: Int) -> Int {
        num1 + num2
    }
    
    func sub(num1: Int, num2: Int) -> Int {
        num1 - num2
    }
}
```


# UnitTest_1Tests.swift

Swiftファイル名が「UnitTest_1Tests.swift」となっている理由は、プロジェクト名が「UnitTest_1」であるから。

```UnitTest_1Tests.swift
import XCTest
@testable import UnitTest_1

/*
 ■ UnitTest 実行方法
    - プログラム左の実行ボタンをクリック → 楽
    - Product > Test
    - Command + U → 楽
 
 ■ 関数名: test + テストしたい関数名
 */
class UnitTest_1Tests: XCTestCase {

    func testAdd() throws {
        let result = Calclator().add(num1: 10, num2: 20)
        
        XCTAssertEqual(result, 30)   // 30 = 10 + 20
    }
    
    func testSub() throws {
        let result = Calclator().sub(num1: 10, num2: 20)
        
        XCTAssertEqual(result, -10)   // -10 = 10 - 20
    }

}
```

# 参考

https://www.youtube.com/watch?v=KmTEMu2vbAY
Rails6でScaffoldがエラーになる

### 環境
Rails 6.1.5
テンプレート：slim-rails 3.4.0

### viewのテンプレートをSlimにしている場合Scaffoldでエラーになる

いざScaffoldしようと思って
```sh:
$ rails g scaffold hoge a:string b:integer
```

とすると、modelとcontrollerは作成されるが、
```sh:
in `model_resource_name': wrong number of arguments (given 1, expected 0) (ArgumentError)
略
in `template'
```
変なエラーが出てviewが作成されない。

# 色々調べてたどり着いたのがこちら
[Rails scaffold views throws wrong number of arguments error](https://stackoverflow.com/questions/71735314/rails-scaffold-views-throws-wrong-number-of-arguments-error)

どうやら、rails6にrails7に対応している最新版のslim-rails3.4.0が入ってしまうとよろしくないらしい。

# 解決方法
slim-railsのバージョンを3.3.0に固定する

```ruby:Gemfile
#バージョン無しだと3.4.0がインストールされてしまうため3.3.0にバージョン固定
gem 'slim-rails', '3.3.0'
```

bundle install後、再度scaffold
```ruby:
$ bundle install
$ rails g scaffold hoge a:string b:integer
略
invoke    slim
      create      app/views/hoge
      create      app/views/hoge/index.html.slim
      create      app/views/hoge/edit.html.slim
      create      app/views/hoge/show.html.slim
      create      app/views/hoge/new.html.slim
      create      app/views/hoge/_form.html.slim
```
エラーが出なくなった！
Fortifyのマルチドメインの時にサブドメ使いたい時のメモ

実装は以下を参考に

https://qiita.com/nasteng/items/dfa9f6d252d887095f79

`admin`モデルを追加して`サブドメイン（admin）`で制御しようとして、
**ルーティングがFortifyのlogin（POST）ルートに飛んで、adminで登録してる情報でバリデートしてくれない…**
ということがあったので、そのメモ（いずれ書き直す）


`config/fortify.php`内の`domain`をサブドメインなしのドメインにして、fortifyの範囲を制御するで対応してみた

```php:config/fortify.php
    /*
    |--------------------------------------------------------------------------
    | Fortify Routes Prefix / Subdomain
    |--------------------------------------------------------------------------
    |
    | Here you may specify which prefix Fortify will assign to all the routes
    | that it registers with the application. If necessary, you may change
    | subdomain under which all of the Fortify routes will be available.
    |
    */

    'prefix' => '',

    // 'domain' => null,
    // 以下のようにしてみた
    'domain' => env('DOMAIN', 'localhost'),

```


なお、コメントアウト部分の英語は以下（Google翻訳）
```
ここで、Fortifyがすべてのルートに割り当てるプレフィックスを指定できます
アプリケーションに登録すること。 必要に応じて、変更することができます
すべてのFortifyルートが利用できるサブドメイン。
```

`prefix`に`web`といれたら、`localhost/web/login`となる
（ルート名の接頭辞だったらこっち使うのにな）
Requirements on Update and Configuration Management, No.887, AUTOSAR R21-11 (42) AP

Requirements on Update and Configuration Management, No.887, 

https://www.autosar.org/fileadmin/standards/adaptive/21-11/AUTOSAR_RS_UpdateAndConfigurationManagement.pdf

一覧はこちら。

AUTOSAR 21-11, 42文書読んだ。2022年5月中に半分到達予定。

https://qiita.com/kaizen_nagoya/items/648b32867635993410c8

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

https://qiita.com/kaizen_nagoya/items/9b3a1b9b8d1e8d7e288e

# 用語(terms)

|Term|Description|
|:--|:--|
|UCM| Update and Configuration Management
|UCM Master |UCM Master is distributing packages and coordinating an update campaign in a vehicle
|Backend |Backend is a server hosting Software Packages
|Platform Health Manager| The Platform Health Manager functional cluster performs health monitoring on the AUTOSAR Adaptive Platform


## 英日
日本語は仮訳

|no.|count|word|日本語|
|:----|:----|:----|:----|
|1|176|the|その|
|2|128|of|の|
|3|127|shall|しなければならない|
|4|124|rs_ucm_|rs_ucm_|
|5|120|ucm|Update and Configuration Management(短縮名）|
|6|116|to|に|
|7|112|software|ソフトウェア|
|8|107|and|と|
|9|101|autosar|AUTomotive Open System Architecture(短縮名)|
|10|82|rs_main_|rs_main_|
|11|82|update|更新|
|12|59|adaptive|適応|
|13|54|platform|土台|
|14|50|on|の上|
|15|47|requirements|要件|
|16|44|dependencies|依存関係|
|17|43|be|です|
|18|43|case|場合|
|19|43|description|説明|
|20|43|in|の中に|
|21|42|material|材料|
|22|41|support|対応|
|23|41|use|使う|
|24|40|management|管理|
|25|39|c|c|
|26|39|d|d|
|27|39|document|文書|
|28|39|rationale|理論的根拠|
|29|39|supporting|対応|
|30|38|configuration|構成|
|31|37|for|にとって|
|32|36|a|一つの|
|33|36|an|一つの|
|34|36|or|また|
|35|34|is|です|
|36|34|package|小包|
|37|33|that|それ|
|38|32|vehicle|車両|
|39|30|draft|下書き|
|40|29|installed|導入した|
|41|29|master|主人|
|42|28|r|r|
|43|26|data|与件|
|44|25|autosar_rs_updateandconfigurationmanagement|autosar_rs_updateandconfigurationmanagement|
|45|24|ap|adaptive platform(短縮名)|
|46|24|id|identifier, 識別子(短縮名）|
|47|24|provide|提供|
|48|21|application|応用|
|49|21|packages|小包|
|50|18|it|それ|
|51|17|functional|機能的|
|52|16|has|もつ|
|53|16|information|情報|
|54|15|are|です|
|55|15|by|に|
|56|15|process|処理する|
|57|14|any|どれか|
|58|14|from|から|
|59|14|functionality|機能性|
|60|14|not|いいえ|
|61|14|which|どれの|
|62|13|check|検査する|
|63|13|glossary|用語集|
|64|13|state|状態|
|65|13|this|これ|
|66|13|updates|更新|
|67|12|can|できる|
|68|12|history|歴史|
|69|12|install|導入|
|70|12|make|作る|
|71|12|new|新着|
|72|12|release|公開|
|73|12|rs_saf_|rs_saf_|
|74|12|see|見る|
|75|12|tr|technical report(短縮名）|
|76|11|installation|導入|
|77|11|s|s|
|78|11|safety|安全性|
|79|11|updated|更新した|
|80|11|version|版|
|81|11|with|と|
|82|10|after|後|
|83|10|all|すべて|
|84|10|been|その間|
|85|10|down|下|
|86|10|if|もしも|
|87|10|sure|承知しました|
|88|9|action|行動|
|89|9|clusters|房|
|90|9|have|持ってる|
|91|9|interface|界面|
|92|9|only|それだけ|
|93|9|system|系|
|94|8|campaign|運動|
|95|8|reporting|報告|
|96|8|through|終えた|
|97|8|was|だった|
|98|8|will|意思|
|99|8|work|仕事|
|100|7|activation|活性化|
|101|7|available|利用可能|
|102|7|during|その間|
|103|7|operating|操作|
|104|7|order|注文|
|105|7|other|他の|
|106|7|processing|処理|
|107|7|retrieve|取得|
|108|7|up|上|
|109|7|updating|更新|

# 参考(reference)

[1] Main Requirements
AUTOSAR_RS_Main
Design guidelines for using parallel processing technologies on Adaptive Platform, No.884, AUTOSAR R21-11 (41) AP

Design guidelines for using parallel processing technologies on Adaptive Platform, No.884, 2021-11

https://www.autosar.org/fileadmin/standards/adaptive/21-11/AUTOSAR_EXP_ParallelProcessingGuidelines.pdf


一覧はこちら。

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

https://qiita.com/kaizen_nagoya/items/9b3a1b9b8d1e8d7e288e

# 用語(terms)

|term|Description|
|:--|:--|
|ADAS |Autonomous Driving and Assistance System
|ARA |AUTOSAR Run-time for Applications
|SOA |Service-Oriented Architecture


## 英日
日本語は仮訳

|no.|count|word|日本語|
|:----|:----|:----|:----|
|1|259|the|その|
|2|134|of|の|
|3|109|processing|処理|
|4|103|parallel|平行|
|5|88|is|は|
|6|85|and|と|
|7|79|to|に|
|8|75|in|の中に|
|9|73|adaptive|適用|
|10|66|a|一つの|
|11|60|platform|土台|
|12|58|for|にとって|
|13|50|technologies|技術|
|14|42|design|設計|
|15|42|on|の上|
|16|42|that|それ|
|17|40|this|これ|
|18|38|autosar|AUTomotive Open System Architecture(短縮名)|
|19|35|are|です|
|20|35|level|水準|
|21|34|be|です|
|22|33|document|資料|
|23|33|or|また|
|24|31|service|奉仕|
|25|30|it|それ|
|26|28|application|応用|
|27|27|as|なので|
|28|26|by|に|
|29|26|data|与件|
|30|26|may|かもしれない|
|31|26|services|奉仕|
|32|25|r|r|
|33|24|based|基づく|
|34|24|not|いいえ|
|35|23|guidelines|指針|
|36|22|hardware|ハードウェア|
|37|22|using|を使用して|
|38|21|processor|処理系|
|39|21|system|系|
|40|20|model|模型|
|41|20|some|いくつかの|
|42|19|one|1|
|43|16|ap|adaptive platform(短縮名)|
|44|16|at|で|
|45|16|autosar_exp_parallelprocessingguidelines|autosar_exp_parallelprocessingguidelines|
|46|16|can|できる|
|47|16|id|identifier, 識別子(短縮名）|
|48|16|interface|界面|
|49|16|multiple|多数|
|50|16|use|使用する|
|51|16|with|と|
|52|14|accelerator|加速器|
|53|14|other|他の|
|54|14|standard|標準|
|55|14|there|そこの|
|56|13|also|また|
|57|13|asil|Automotive safety integrity level (短縮名）|
|58|13|dlp|Data Level Parallelism （短縮名）|
|59|13|example|例|
|60|13|software|ソフトウェア|
|61|13|such|そのような|
|62|12|execution|実行|
|63|12|library|図書館|
|64|12|parallelism|並列処理|
|65|11|c|c|
|66|11|from|から|
|67|11|general|全般的|
|68|11|instruction|命令|
|69|11|more|もっと|
|70|11|only|それだけ|
|71|11|process|処理する|
|72|11|used|使用済み|
|73|10|any|どれか|
|74|10|if|もしも|
|75|10|opencl|Open Computing Language(短縮名）|
|76|10|release|開放|
|77|10|thread|より糸|
|78|10|time|時間|
|79|10|which|どれの|
|80|10|will|意思|
|81|9|an|一つの|
|82|9|but|しかし|
|83|9|co|comercial(短縮形）|
|84|9|management|管理|
|85|9|non|非|
|86|9|plp|Pipeline Level Parallelism（短縮名）|
|87|9|single|一つの|
|88|9|they|それら|
|89|9|various|様々|
|90|9|work|仕事|
|91|8|architectural|建築|
|92|8|computing|計算|
|93|8|distributed|配布|
|94|8|however|でも|
|95|8|layer|層|
|96|8|os|operating system(短縮名）|
|97|8|performance|効率|
|98|8|specific|明確|
|99|8|threading|糸をよる|
|100|8|tlp|Task Level Parallelism（短縮名）|
|101|8|underneath|下に|
|102|8|uses|使う|
# 参考(reference)

[1] Glossary, AUTOSAR_TR_Glossary
[2] Main Requirements, AUTOSAR_RS_Main
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology
[4] Explanation of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign
[5] Specification of Execution Management, AUTOSAR_SWS_ExecutionManagement
BFFをとりあえず概要だけまとめてみた

現職でNext.jsを使って開発してるんですが、最初はSPAで作ってからBFF化させるという計画らしく、そもそもBFFって言葉しか知らなかったので、とりあえず概要だけまとめてみた。

### そもそもBFFとは
Backend for Frontendの略
APIサーバがビジネスのドメインロジック部分を担当するのに対して、BFFはあくまでユーザーインタフェースをサポートするサーバである。なので、開発はフロントエンドエンジニアが行う。

フロントエンド開発において「複数のAPIをまとめる（下図参照）」「サーバサイドレンダリングを行う」などが求められる機会でBFFは有効。

従来の設計（フロントから直接APIを叩く）
 Front-end ⇄ Back-end

BFFの設計（BFFがバックエンドをラップするとか、吸収するとかって言います）
 Front-end ⇄ BFF ⇄ Back-end 

![news022_02.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/173182/fc2ee438-cbde-d86f-c463-b3b6a3947d5a.jpeg)


### BFFのメリット
パフォーマンスの改善。
クライアントから複数のAPIを叩くと大量のリクエストをすることになります。BFFでAPIをひとまとめにする事ができれば、クライアントからのリクエストは1回になるので簡単。
またクライアントで欲しい形でデータを返してくれるのでクライアント側でデータの操作がなくなるので、コードがシンプルになる。 

### BFFのデメリット
BFFも一つのマイクロサービスなので、 BFF自体の開発コストが当然かかってしまう。サーバーにデプロイしメンテナンスも必要。


### 採用する技術に何がある？
・Next.jsであれば標準のAPI Routing機能を使う（Front, BFFをまとめて開発できる）
・Nest.jsを使う
・AWS AppSyncを使う
など

ちなみに必ずしもGraphQLである必要はないみたいです。REST APIでもOK。

とりあえずは概要だけまとめました、これを機に実際にトライしてみようとおもいます。
【基本情報】午後試験のアルゴリズムに勝つには

<h1>アルゴリズムって難しい…</h1>
基本情報の午後試験を解いていると、立ちはだかってくるのが「データ構造とアルゴリズム」だと思います。
<br><br>
実際私も思ったように点が取れなかった部分なので、今回は基本情報の午後試験の中でも「データ構造とアルゴリズム」に特化した記事を書いていきます。<br>
私と同じようにアルゴリズムに苦しんでいる方の一助となれたら嬉しいです。

<h1>想定している読者層</h1>
基本情報の午後試験の勉強中の人の中でも、学校などである程度プログラミングを勉強していて、if文やfor文などを理解できている方向けの記事になります。<br><br>
if文やfor文がまだわからない方は、googleで調べてみたり、paizaやProgateなどで実際に手を動かしながら覚えてみたりしてから読むと良いかもしれません。

<h1>筆者の成績と情報</h1>
私は令和4年度春期に合格しました。<br>
そのときの成績はこんな感じでした。

![87534.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2655859/1204a091-289b-175e-e4cf-5f3a0eef6558.jpeg)
ちなみに午前試験は69点でした。過去問は安定して8割解けていたのですが……。<br>
同じ試験を受けた会社の同期も難しいと言っていたので、難化していたのかもしれません。<br>
 
~~成績が悪かった言い訳じゃないよ！~~<br>
大学在学中に何度か記念受験をしていたので、初めての受験ってわけではなかったです。

<h1>試した解き方</h1>
アルゴリズムの攻略で一番大切なのは、<strong>処理の流れを追うこと</strong>です。<br>
今どんな処理を行い、その結果変数たちはどうなったのか……それを地道に追っていくのが正確に問題を解くコツです。<br>
<br>
では実際処理の流れを追うにはどうしたら良いか。<br>
<br>
実際の試験ではA4の紙1枚が配られます。<br>
そこに<strong>表を書く</strong>のです。
<br><br>
例えば、問題の中にfor文が出てきたとして、その中でたくさんの処理が行われているとします。<br>
その処理を全て頭の中でやろうとすると、どこかで必ずミスが発生します。<br>
そこで落ち着いて、i=0のときは配列hoge[i]は0で……といった変数の状態を全て表に記録します。<br>

| i | hoge[i] | huga[i] |
|:-:|:-:|:-:|
| 0 | 0 | 0 |
| 1 | 1 | 1 |
| 2 | 10 | 2 |
| 3 | 11 | 3 |

そうすることで処理の全体像が見えるとともに、「α行の処理を行った後のhoge[0]はどうなっているか」「この処理を終えた際のhuga[0]はどうなっているか」などの問題に落ち着いて答えられるようになります。<br>
この手法が特に活躍する過去問としては、R1年度秋期の設問2、3が挙げられます。<br>
<br>
こんな解き方じゃ絶対制限時間に間に合わない！って思う方もいらっしゃるかもしれません。<br>
しかし、「急がば回れ」ではありませんが、脳みそのみで処理を追うより紙に書いた方がスピーディーかつ正確に問題を解くことができ、さらに紙に途中経過が書いてある分、見直しもしやすくなります。<br>
<br>
紙のスペースが心配……という方も安心してください。試験官を手元のブザーで呼べば何度でも紙を補充してもらえます。<br>


<h1>まとめ</h1>
「データ構造とアルゴリズム」がどうしても解けないという時に、会社の先輩から教わった方法がこの<strong>処理の流れを表に記録する</strong>というものでした。<br>
現在のCBT方式での正確な配点はわかりませんが、「データ構造とアルゴリズム」だけで25点程度あるはずなので、確実に点を取っていきたいところですね。<br>
<br>
以上、22卒新人エンジニアなっしーでした。<br>
今後も記事を書いていきますので、よろしくお願いします！
gitでとあるハッシュ値のコミットが現在のブランチに存在するかどうかをコマンドラインから確認する際の備忘録

gitでとあるハッシュ値のコミットが現在のブランチに存在するかどうかをコマンドラインから確認する際の備忘録です

以下のように`git branch --contains ${ハッシュ値のコミットID}`を使えばOK

```sh
$ git branch --contains 23427b6548e7d168d2c740a258879bdedf1159ed
$ echo $?
0

$ git branch --contains 23427b6548e7d168d2c740a258879bdedf1159aa
error: no such commit 23427b6548e7d168d2c740a258879bdedf1159aa
$ echo $?
129
```

シェルスクリプトで書く場合は以下の通り

```sh:test.sh
TARGET_HASHID="23427b6548e7d168d2c740a258879bdedf1159aa"
git branch --contains "${TARGET_HASHID}"
RET=$?
if [ $RET -eq 0 ]; then
    echo "contains hashid: ${TARGET_HASHID}"
else
    echo "not contains hashid: ${TARGET_HASHID}"
fi
```

実行する

```sh
$ bash test.sh 
error: no such commit 23427b6548e7d168d2c740a258879bdedf1159aa
not contains hashid: 23427b6548e7d168d2c740a258879bdedf1159aa
```

これでいいはず、、

# 参考
https://ohbarye.hatenablog.jp/entry/2016/07/20/003903
Dockerfileコマンド一覧

・Dockerfileコマンド一覧
●FROM イメージ:タグ
Dockerイメージのベースとなるイメージを指定
例)
```
FROM ubuntu:21.10
```

●RUN コマンド
Dockerイメージをビルドするときに、コンテナ内で実行するコマンドを定義
例)
```
RUN apt update \
  $$ apt install -y apache2
=>apache2をインストールするコマンド
```
※複数のコマンドを一度にまとめて実行するときは「&&」で繋げ、複数行になるときは「\」で繋げる

●CMD ["実行ファイル", "パラメータ1", "パラメータ2"]
コンテナ実行時にデフォルトで実行するコマンドを指定
例)
```
CMD ["apachectl", "-D", "FOREGROUND"]
=>コンテナ実行時に、apacheを起動するコマンド
```
※MCDにはexec形式とshell形式の2種類がある。
　上記のものはexec形式である。

●COPY コピー元 コピー先
ローカルのファイルやディレクトリをDockerイメージにコピー
例)
```
●COPY index.html /mydir/index.html
=>ファイルをファイルにコピー
●COPY index.html /mydir/
=>ファイルをディレクトリ以下にコピー
●COPY src/ /mydir/
=>ディレクトリをディレクトリにコピー
```

●ADD コピー元 コピー先
ローカルのファイルやディレクトリをDockerイメージにコピー
※COPYと同じだが、COPY推奨

●ENV キー=値
環境変数を設定
例)
```
ENV MYSQL_USER=admin
```

●WORKDIR パス
コマンドを実行する作業ディレクトリを指定
例)
```
WORKDIR /var/www/html
```

●ENTRYPOINT ["実行ファイル", "パラメータ1", "パラメータ2"]
コマンド実行時に実行したいコマンドを指定
※CMDと似ているが、ターミナルで追記したときの挙動が異なる。
　ENTRYPOINT=>DockerfileのENTRYPOINTコマンドの内容に追加
　CMD=>DockerfikeのCMDコマンドの内容を上書き
Mac ディレクトリ　概要・コマンド

今回は、ディレクトリについてメモ程度に残していこうと思います。
実行例などは省略させていただきます。

## ディレクトリ概要
- Mac Osのディレクトリは基本的に、ディレクトリの中にディレクトリ、さらにその中にディレクトリのような階層構造になっており、このような親子関係になっている構造を**ツリー構造**と言う。
- 最上位のディレクトリ　→　**ルートディレクトリ**(`/`で表される)
- ホームディレクトリ　→ 初期のデフォルトで入っているDesktopなどが入っている階層（`~`で表される）
- カレントディレクトリ　→　現在作業しているディレクトリ（カレントワーキングディレクトリとも呼ばれる）


## パス
- 絶対パス　→　ルートから指定するパスでフルパスとも言う。
- 相対パス　→  カレントディレクトリなどから相対的な位置を表すパス
- `.`　→  カレントディレクトリを表す
- ディレクトリを表す記号まとめ

| 記号 | 意味 |
|---|---|
| /  | ルートディレクトリ  |
|  . | カレントディレクトリ  |
|  .. | 親ディレクトリ  |
|  ~ |  ホームディレクトリ |

## ドットファイル
- ドットファイルという変わったファイルがあり普段は表示されないファイルで主に設定ファイルとして用いられる。
- 表示したい場合は`lsコマンド`の`-A`オプションをつける。

## コマンド操作
| コマンド | 意味 |
|:-:|:-:|
|  mkdir　 | ディレクトリの作成 |
| rmdir  | 空のディレクトリの削除  |
|  rm | ファイルやディレクトリの削除  |
| mv  | ファイルやディレクトリの移動、名前の変更  |
|  cp | ファイルやディレクトリのコピー  |

＊削除形のコマンドのオプションで`-R`を使うときは注意が必要＊
[C#]階層化されたリソーステキストを階層に応じたリソースクラスに変換する


以下のような階層を持つリソーステキストを階層に応じたリソースクラスに変換する

```
SampleApp/Resources
│  DataAnnotationText.en.txt
│  DataAnnotationText.txt
│  resgen.proj
│  SampleMessage.en.txt
│  SampleMessage.txt
│  SharedResource.en.Designer.cs
│  SharedResource.en.resx
│  SharedResource.ja.Designer.cs
│  SharedResource.ja.resx
│  test.proj
│  ValidationMessage.en.txt
│  ValidationMessage.txt
│
├─ViewModels
│  └─Task
│          TaskEditViewModel.en.txt
│          TaskEditViewModel.txt
│          TaskListCriteria.en.txt
│          TaskListViewModel.en.txt
│          TextFile.txt
│
└─Views
    │  TestMessage.txt
    │
    ├─Shared
    └─Task
            Index.en.txt
            _Criteria.en.txt
```

## project ファイル

msbuild で resgen タスクを呼び出すようなプロジェクトファイルを作る

```xml
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTarget="All">

	<PropertyGroup>
		<Namespace>SampleApp.Resources</Namespace>
	</PropertyGroup>

	<ItemGroup>
		<ResourceText Include="**/*.txt"/>
	</ItemGroup>
	<Target Name="Build" Inputs="@(ResourceText)" Outputs="%(Identity).FileName">
		<PropertyGroup>
			<RelativeDir>%(ResourceText.RelativeDir)</RelativeDir>
		</PropertyGroup>
		<PropertyGroup Condition="$(RelativeDir) != ''">
			<Subnamespace>$(RelativeDir.Replace('\', '.'))</Subnamespace>
			<Length>$(Subnamespace.LastIndexOf('.'))</Length>
			<Namespace>$(Namespace).$(Subnamespace.Substring(0,$(Length)))</Namespace>
		</PropertyGroup>
		<GenerateResource Sources="%(ResourceText.Identity)"
			PublicClass="true"
			StronglyTypedLanguage="C#"
			StronglyTypedNamespace="$(Namespace)"
			StronglyTypedClassName="%(FileName)"
			StronglyTypedFilename="$(RelativeDir)%(FileName).Designer.cs"
			OutputResources="$(RelativeDir)%(FileName).resx">
		</GenerateResource>
	</Target>
	<Target Name="Clean" Inputs="@(ResourceText)"  Outputs="%(Identity).FileName">
		<Delete Files="%(ResourceText.RelativeDir)%(ResourceText.FileName).Designer.cs"></Delete>
		<Delete Files="%(ResourceText.RelativeDir)%(ResourceText.FileName).resx"></Delete>

	</Target>
	<Target Name="Rebuild">
		<CallTarget  Targets="Clean;Build"></CallTarget>
	</Target>
</Project>
```

相対ディレクトリの "\"(パス区切り) を "." (namespace 区切り)に変換し、最後の "." を消して基本 namespace に追加すると、階層に応じた namespace ができる。

## なぜ resx を初手から書かないか

リソーステキストを txt にするのはVSのリソースエディタがあまりにも使いづらいため。
あとエクセルなんかで管理したがる人にはエクセルからresx への変換よりtxtへの変換が圧倒的に楽だから。
【TypeScript】set "type": "module" in the package.json or use the .mjs extension.でImportできない時の対応方法

# 概要

変数のエクスポートをすると警告が出た場合の解消方法をまとめる

```ts
export const name = "hoge"
```

```bash
ts-node src/sec7.ts
(node:13731) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
```

# 解消方法

コンパイラする時のモジュールパターンを`commonjs`にすることで解消する

> CommonJSとは、サーバーサイドなどのウェブブラウザ環境外におけるJavaScriptの各種仕様を定めることを目標としたプロジェクトである

```json:tsconfig.json
{
    "module": "commonjs",
}
```
SOLID原則を具体例で説明


# SOLID原則

## S (Single Responsibility)　単一責任の原則

管理者とユーザーの処理を一緒に書いてはいけないという原則です。なぜなら、

・管理者に関するコードだけをいじっているのに、一般ユーザーの機能に影響が出る可能性があると、確認すべき範囲が広がってしまうから。
・管理者、一般ユーザーのコードがごちゃ混ぜになりコードが読みにくくなるから。

「管理者はここ、一般ユーザーはあっち」とすることで機能追加や運用、デバックがしやすくなります。

## O (Open-Closed)　オープン・クローズドの原則

何か機能を追加するとき、既存のコードを変更するのではなく新しく追加するのが好ましいという原則です。なぜなら、既存のコードの変更は既存の機能のバグを作ってしまう可能性があるから。

例えば,createDrinkメソッドがあります。１種類のフルーツから飲み物を作ります。

```ruby
  def createDrink(fruit)
    ~
  end
```
ここで、２種類のフルーツから飲み物を作りたくなった場合。
悪い例。既存のコードにfruitをもう一つ足してしまう。
```ruby
  def createDrink(fruit, fruit2)
    ~
  end
```

良い例。新しく追加することで既存の機能に影響を与えずに済みます。
```ruby
  def createDrink(fruit)
    ~
  end

  def createDrinkByTwo(fruit, fruit2)
    ~
  end
```

## L (Liskov Substitution)　リスコフの置換原則

子クラスは親クラスと同じメソッドを呼び出せるべき、という原則。

生き物で例えますと生き物クラスは子孫を残すことができます。ならばたんぽぽクラスもカブトムシクラスも人間クラスも子孫を残すことができるべき、と言うことです。逆に子にはあるが親にはないメソッドというのは問題ありません。

## I (Interface Segregation)　インターフェイス分離の原則

以下が悪い例です。

```ruby
class Ape
  def eat
    ~
  end

  def speak
    ~
  end
end

monkey = Ape.new()
human = Ape.new()
```
humanは話すことはできますがmonkeyは話せません。monkeyインスタンスでspeakを使わなければエラーが出ることはないのですが、初めてApeクラスを扱う人が戸惑ってしまうしわかりづらいのでNGです。

書くことしたら以下のような感じでしょうか

```ruby
class Ape
  def eat
    ~
  end
end

class Monkey < Ape
end

class Human < Ape
  def speak
    ~
  end
end
```

これでmonkeyが喋ることは無くなりました。


## D (Dependency Inversion)　依存性逆転の原則

具体は抽象に依存しよう、という原則です。

具体例として、具体の関数が2つあります。
```typescript
const concrete1 = () => {
  number = concrete2()
  return number * 10
}

const concrete2 = () => {
  return 100
}
```
こちらの関数、concrete1の中でconcrete2を呼び出しています。このままですとconcrete2に変更を加えたとき、concrete1に影響を出す可能性があります。concrete1がconcrete2に依存している状態です。

ここにインターフェースを加える＆concrete2を引数で受け取るようにしてみます。

```typescript
interface Abstract {
  concrete2: () => number
}

const concrete1 = ({concrete2}: {
concrete2: Abstract
}) => {
  number = concrete2()
  return number * 10
}

const concrete2: Abstract = () => {
  return 100
}
```

すると先程はconcrete1がconcrete2に依存していましたがconcrete1もconcrete2も共にinterfaceに依存しています。このようにすることで、concrete2を変更した際、知らず知らずのうちにconcrete1にバグを生むことは無くなりました。
Reactで同時に、一緒にスクロールをしたい。

### 結論

```react
const Tables = () => {
  const rightEl = useRef()
  const leftEl = useRef()

  const handleScroll = (isLeft) => {
    isLeft
      ? (rightEl.current.scrollTop = leftEl.current.scrollTop)
      : (leftEl.current.scrollTop = rightEl.current.scrollTop)
  }

  return (
    <>
      <LeftTable ref={leftEl} onScroll={handleScroll}/>
      <RightTable ref={rightEl} onScroll={handleScroll}/>
    </>
  )
}
```

### 解説

ReactではuseRefを使うことで要素を取得することができます。そして、スクロール量もその取得した要素と一緒に得られるので片方のスクロール量をもう片方のスクロール量にすることでスクロールを同期させることができます。
Pythonでオシロスコープ波形のタイミング解析(その1)

[前回](https://qiita.com/nachtele/items/e5b9e57b0375c4ad1bae)はVDS3104で保存したバイナリーデータを解析して、matplotlibで表示するようにしてみました。今回は、さらに実用的な、波形のタイミング解析ツールを作ってみました。

# タイミング解析とは
I2CやSPIなどで通信するデバイスには、データを正しく送受信するために信号エッジ(立上り/立下り)の時間関係が規定されており、それらが実際に規定値範囲内に収まっているか確認する必要があります。それを調べるのがタイミング解析です。
I2Cには信号線は2本しかありませんが、スタートコンディション、ストップコンディションといった、伝送されるデータ本体以外の状態もあり、解析すべきタイミング項目は十数項目以上あります。
以下に、Start condition hold time と、Start contditon setup timeの解析例を示します。(この例では、テスト用に生成した波形データを解析しています)

![tHD_STA_0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/3668a7ab-9976-eae4-c1b4-d992e73f1106.png)
![tSU_STA_0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/b0852aef-515f-2e2c-55dd-89fd30ac2f5a.png)

さらに、同じSDAの変化でも立上りと立下りでは特性が違います。また、マスターが送信している時には受信側であるスレーブの規定を満たす必要がありますし、スレーブが送信している時には受信側であるマスターの規定を満たす必要がありますので、それらを区別して解析する必要があります。
以下に、VDS3104で実際に採取したデータでの Data input setup time の解析例を示します。マスター→スレーブの波形(上側の2枚)とスレーブ→マスターの波形(下側の2枚）ではタイミングがかなり違っていることがわかります。

![tSU_DAT_R_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/330985a9-e2d9-de95-6f60-e51c69c003bd.png)
![tSU_DAT_F_0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/1ee4d7a8-15c0-c704-77d7-a8ae4556e099.png)
![tSU_DAT_MI_R_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/24e96bcf-7d98-5775-e02f-6bc265cbd188.png)
![tSU_DAT_MI_F_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923193/1352d729-9a38-f41d-399a-bc49fe86158b.png)

# タイミング解析ツール

ここに貼り付けるにはコードサイズが大きくなりすぎたので、githubで公開しています。
https://github.com/nachtele/TimAn

## 概要

+ オシロスコープ等の波形データについてタイミング解析するツールです。(Setup Time、Hold Time、等)
+ matplotlibにより、解析結果に基づいた波形画像を生成することができます。画像生成対象は、各解析項目について、全データ、もしくは最小値、最大値を選ぶことができます。
+ openpyxlにより、解析結果一覧と画像を張り付けたxlsxファイルを生成することができます。(LibreOffice Calc等でも開けます)
+ リスト形式の設定を作成することで、各種通信プロトコルなどに対応できます。とりあえずI2CとSPIの設定を作ってみました。
+ OWON VDSシリーズのバイナリーデータに対応したデータ読み取りモジュールを用意しています。これを差し替えれば他のオシロスコープにも対応できます。

## 対象環境

python3

## ファイル構成

+ /src
  + VdsTimAn_I2C.py (実行ファイル)VDSシリーズ用I2Cタイミング解析
  + TimAn.py  タイミング解析
  + TimAnSettings.py  解析・画像生成設定
  + TimAnMakeFig.py 波形画像生成
  + vdsDat.py   VDSシリーズ用データ読み取り
  + getArgs.py  コマンドライン引数取得
+ /test
  + Ex01_TimAn_I2C.py 波形解析テスト用(I2C)
  + Ex01_TimAn_SPI.py 波形解析テスト用(SPI)


## 使用方法

### VdsTimAn_I2C.py

OWONのVDSシリーズでバイナリーデータとして保存したI2C波形をタイミング解析する例です。
このコードでは、Ch1にSCL、Ch2にSDAを割り当てています。違う割り当ての場合は適宜書き換えてください。
出力ディレクトリー "ta_年月日_時分秒" を自動生成してそこに波形画像をpng形式で保存します。また、それらの画像を張り付けたシートと解析結果一覧のシートで構成したxlsxファイル "ta_年月日_時分秒.xlsx" を生成します。

---
    python VdsTimAn_I2C.py (データファイル名) [-s (メイン領域分割数)]
---

### Ex01_TimAn_I2C.py, Ex01_TimAn_SPI.py

波形解析のテスト用。疑似データを生成して解析・画像生成をテストするツールです(I2C, SPI用)。
TimAn.py、TimAnSettings.py、TimAnMakeFig.pyを同じディレクトリーに置いて実行してください。

---
    python Ex01_TimAn_I2C.py
---

[次回](https://qiita.com/nachtele/items/9d09e0a1f5b081b30f30)から、もう少し詳しく解説していきます。
ASP.NET Core ローカリゼーションでハマる事

## View Localization

各Viewでのリソースと共有リソースを使う場合、どちらかのリソースが読み込めない

Program.cs (Startup.cs)

```csharp
// MVC/Razor Pages
builder.Services.AddControllersWithViews()
    .AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix, option => { option.ResourcesPath = "Resources"; })

// localization
builder.Services.AddLocalization(options => options.ResourcesPath = "Resources");
```

Views/Foo/Index.cshtml

```html
@using System.Collections.Generic
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Localization
@inject IViewLocalizer Localizer
@inject IHtmlLocalizer<TaskManagerApp.SharedResource> SharedLocalizer

<p>@Localizer["foo"]</p>
<p>@SharedLocalizer["foo message"]</p>
```

SampleApp.Resources.Views.SharedResource.resx

```
foo message = なにかメッセージ
```

SampleApp.Resources.Views/Foo/Index.resx

```
foo = メッセージ
```

こうすると SharedResource が読み込めない。

### 解決

空のSampleApp.SharedResource.cs を追加する

```
namespace SampleApp{
  public class  SharedResource {}
}
```

### 原因

`options => options.ResourcesPath = "Resources"` を設定することでリソース検索パスが "SampleApp.Resources.Resources" になってしまうから。

## DataAnnotationLocalizer

```
builder.Services.AddControllersWithViews(options => {
    options.ModelMetadataDetailsProviders.Add(new CustomValidationMetadataProvider(typeof(TaskManagerApp.Resources.ValidationMessage)));
})
    .AddViewLocalization(LanguageViewLocationExpanderFormat.Suffix, option => { option.ResourcesPath = "Resources"; })
    .AddDataAnnotationsLocalization(options => { 
        options.DataAnnotationLocalizerProvider = (type, factory) => factory.Create(typeof(SampleApp.Resources.DataAnnotationText));
    });
```

これも前述と同じで SampleApp.Resources.Resources.DataAnnotationText が検索されてしまうので空の SampleApp.DataAnnotationText クラスを追加する。
React-Three-Fiber 使ってみた

## React で3Dやりたす
というわけで、react-three-fiber を使った最低限の作業を備忘録

### 準備
Typescript 版の React プロジェクト作成
react-three/fiber のインストール
```bash
  % npx create-react-app cube-sample
  % cd cube-sample
  % npm install three @react-three/fiber
```

### コード

App.js, App.css の２ファイル、Index.jsは省略

#### App.css
この設定がないと表示が小さくなってしまう
```CSS:App.css
.App {
  width: 100vw;
  height: 100vh;
}
```


#### App.js
`<mesh> </mesh>` が Three.js の `scene` に相当するっぽい。
`<mesh> </mesh>` 内に geometry と material を設定する。
`requestAnimationFrame(...) ` 的なことは `useFrame()` で対応できる。
`<Canvas></Canvas>` で `<mesh></mesh>`を挟んで
ライトの設定`<pointLight/>`なんかも入れる。

`WebGLRenderer`とかはちょっとまだ良くわからない...

```react:App.js
import { useState, useRef } from 'react';
import { Canvas, useFrame } from '@react-three/fiber';
import './App.css';

function Cube(props) {
    const [wireFrame, setWireFrame] = useState(false);
    const ref = useRef()
    useFrame(()=>{
        ref.current.rotation.x += 0.010;
        ref.current.rotation.y += 0.013;
        ref.current.rotation.z += 0.015;
    });
    return (
        <mesh {...props} ref={ref} onClick={()=>setWireFrame(!wireFrame)}>
            <boxGeometry args={[1,1,1]} />
            <meshLambertMaterial color="red" wireframe={wireFrame} />
        </mesh>
    )
}

function App() {
    return (
      <div className='App'>
          <Canvas>
            <pointLight position={[10,10,10]} />
            <Cube position={[1,1,1]} />
            <Cube position={[0,0,-1]} />
            <Cube position={[-1,1,1]} />
           </Canvas>
        </div>
    )
}

export default App;

```

`<mesh> <axesHelper scale={2} /> </mesh>` を
`<Canvas></Canvas>`内に追加すれば確認用のXYZ軸を表示できる。


### 実行画面

![スクリーンショット 0004-05-05 20.46.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481708/c84339d4-9514-9a56-9ce3-3be01489e12b.png)

### 最後に

とりあえず最低限のオブジェクトの配置とアニメーション、
イベントの取得は簡単にできることがわかった。

もう少し高度な使い方にも挑戦します。
MySQL vs. TiDB-分散トランザクションの比較検証(5): TiDBの基本

##### [前回] [MySQL vs. TiDB-分散トランザクションの比較検証(4):MySQL内部XA](https://qiita.com/mingchun_zhao/items/043937d351a74f8d5e0a)

## はじめに

MySQLの検証が長編となってしまったので、TiDBも取り上げてみます。

## TiDB(タイディービー)とは

Wikipediaの[TiDB](https://en.wikipedia.org/wiki/TiDB)定義から、

- オープンソースのNewSQLデータベース
- MySQLと互換性あり
- 水平方向のスケーラビリティ、強力な一貫性、高可用性を提供
- ハイブリッドのトランザクションと分析処理のワークロードをサポート

## TiDBのアーキテクチャー

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/d8a32d29-697a-8535-b7c4-be14917b0667.png)

※ 引用元: PingCAP社の[TiDB Architecture](https://docs.pingcap.com/tidb/stable/tidb-architecture)

### コンポーネント

#### TiDBクラスタを構成するTiDBサーバー

- 外部からのSQLリクエスト(MySQLプロトコル)を受け付ける
- スケールアウト可能
- SQL解析、最適化、分散実行計画の生成

#### PD(Placement Driver)クラスタを構成するPDサーバー

- ここが司令塔のようで、クラスタ全般(TiDBクラスタ、Storageクラスタなど)を司っている
- メタデータを管理
- PDサーバーは可用性を持ち、少なくとも3ノード必要(ノード数は奇数)

#### Storageクラスタを構成するStorageサーバー

2種類サーバーがあるようです。

##### TiKVサーバー

- データ保存用で、分散キーバリューストアエンジン
- データ保存単位はRegion
- 一つのTiKVノードに複数存在
- 分離レベルは、スナップショット分離をサポート
    - TiDBがSQLレベルで分散トランザクションをサポート可能な要因がこれだそうです
- TiKVに格納されたデータは、複数レプリカにより自動メンテされる
    - デフォルトはレプリカ三つ
- ネイティブの高可用性を持ち、自動フェールオーバー可能

##### TiFlashサーバー

- データを列指向(カラムナー)で保存
- 特殊ストレージで、主に分析処理を加速するため使用

## おわりに

一旦、TiDBのアーキテクチャと用語を抑えておきました。
次回は、いろいろ検証してみたいと思います、お楽しみに。

##### [次回] [MySQL vs. TiDB-分散トランザクションの比較検証(6): TiDBクラスタの導入](https://qiita.com/mingchun_zhao/items/8965b27fdfce7caf58e6)
Functional Cluster Shortnames, No.862, AUTOSAR 21-11 (39) AP

Functional Cluster Shortnames, No.862, 2021-11

https://www.autosar.org/fileadmin/standards/adaptive/21-11/AUTOSAR_TR_FunctionalClusterShortnames.pdf

一覧はこちら。

AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成

https://qiita.com/kaizen_nagoya/items/9b3a1b9b8d1e8d7e288e

# 用語(terms)

|SHORTNAME(used e.g. in namespaceand include structure)|Adaptive Platform Functional Cluster|
|:----|:----|
|core|Adaptive Platform Core|
|com|Communication Management|
|crypto|Cryptography|
|diag|Diagnostics|
|exec|Execution Management|
|iam|Identity and Access Management|
|idsm|Intrusion Detection System Manager|
|log|Log and Trace|
|nm|Network Management|
|n/a|not applicable|
|-|Operating System Interface|
|per|Persistency|
|phm|Platform Health Management|
|sm|State Management|
|tsync|Time Synchronization|
|ucm|Update and Configuration Management|


## 英日
日本語は仮訳

|no.|count|word|日本語|
|:----|:----|:----|:----|
|1|19|autosar|AUTomotive Open System Architecture(短縮名)|
|2|19|management|管理|
|3|14|of|の|
|4|14|short|短い|
|5|13|r|r|
|6|12|and|と|
|7|12|functional|機能的|
|8|12|release|公開|
|9|12|the|その|
|10|11|cluster|房|
|11|11|document|文書|
|12|10|names|名前|
|13|9|for|にとって|
|14|8|in|の|
|15|7|any|どれか|
|16|7|work|仕事|
|17|6|by|による|
|18|6|to|に|
|19|5|core|芯|
|20|5|name|名前|
|21|5|or|また|
|22|4|adaptive|適用|
|23|4|ap|adaptive platform(短縮名)|
|24|4|autosar_tr_functionalcluster|autosar_tr_functionalcluster|
|25|4|changed|かわった|
|26|4|id|identifier, 識別子(短縮名）|
|27|4|platform|土台|
|28|4|system|系|
|29|4|this|これ|
|30|3|be|です|
|31|3|contained|含まれています|
|32|3|from|から|
|33|3|it|それ|
|34|3|material|材料|
|35|3|new|新しい|
|36|3|no|いいえ|
|37|3|only|それだけ|
|38|3|part|部|
|39|3|time|時間|
|40|3|types|型|
|41|2|a|一つの|
|42|2|access|接続|
|43|2|applications|応用|
|44|2|automotive|自動車|
|45|2|been|その間|
|46|2|changes|変更|
|47|2|clusters|房|
|48|2|communication|通信|
|49|2|configuration|構成|
|50|2|date|日付|
|51|2|description|説明|
|52|2|detection|検出|
|53|2|developed|発展した|
|54|2|form|形|
|55|2|has|もっている|
|56|2|identity|身元|
|57|2|intellectual|知的|
|58|2|interface|界面|
|59|2|intrusion|侵入|
|60|2|is|は|
|61|2|log|記録|
|62|2|manager|管理者|
|63|2|may|かもしれない|
|64|2|means|意味|
|65|2|network|通信網|
|66|2|operating|操作|
|67|2|other|他の|
|68|2|property|財産|
|69|2|published|公開|
|70|2|purpose|目的|
|71|2|removed|削除した|
|72|2|renaming|名前変更|
|73|2|reproduced|再現|
|74|2|rights|権利|
|75|2|s|s|
|76|2|standard|標準|
|77|2|state|状態|
|78|2|status|状態|
|79|2|synchronization|同期|
|80|2|tsync|time synchronization(短縮名）|
|81|2|update|更新|
|82|2|utilized|利用|
|83|2|without|それなし|

# 参考(reference)
なし。
expressでCRUDのコードを写経していたときに「TypeError: Cannot destructure property 'username' of 'req.body' as it is undefined.」で一日ハマっていた件


# expressの「TypeError: Cannot destructure property 'username' of 'req.body' as it is undefined.」というエラーについて

# 結論（どうすればよいか）
```javascript
app.use(express.json());
```
を　`index.js`　に追加しろ

ちなみに、
```javascript
app.use(express.json);
```
ではない
なぜかは知らん

# エラー内容
TypeError: Cannot destructure property 'username' of 'req.body' as it is undefined.


# ソース
※もう直しているので再現はしません
github
https://github.com/2f0833e717/node-docker


## 実際のコンソール出力内容
```bash
> node-docker@1.0.0 dev
> nodemon -L index.js

[nodemon] 2.0.16
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node index.js`
listening on port 3000
succesfully connected to DB
/app/controllers/authController.js:6
  const { username, password } = req.body;
          ^

TypeError: Cannot destructure property 'username' of 'req.body' as it is undefined.
    at exports.signUp (/app/controllers/authController.js:6:11)
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
    at next (/app/node_modules/express/lib/router/route.js:144:13)
    at Route.dispatch (/app/node_modules/express/lib/router/route.js:114:3)
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
    at /app/node_modules/express/lib/router/index.js:284:15
    at Function.process_params (/app/node_modules/express/lib/router/index.js:346:12)
    at next (/app/node_modules/express/lib/router/index.js:280:10)
    at Function.handle (/app/node_modules/express/lib/router/index.js:175:3)
    at router (/app/node_modules/express/lib/router/index.js:47:12)
[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting `node index.js`

```

# 余談その1　写経の元ネタ
[Youtube] [Google自動翻訳]
Dockerを学ぶ-Node.jsとExpressを使用したDevOps

https://www.youtube.com/watch?v=9zUHg7xjIqQ

#  余談その2　この辺がいるっぽい気がしたが要らんかった（順不同、適当）
```javascript

const bodyparser = require("body-parser");

app.use(express.urlencoded({ extended: true }));
app.use(bodyparser.json());
app.use(bodyparser.urlencoded({ extended: true }));

      useNewUrlParser: true,
      useUnifiedTopology: true,
      useFindAndModify: false, //これは非推奨となっている

```


~~余談の余談
GW、皆さんいかがお過ごしでしょうか。やろうやろうと思って一生やらなかったDocker周りの勉強中にハマって一晩寝かしたものの、エラー内容をそのままググったら、結局ちゃんと見たらそのまんまだった系のトラブルシュートとして本件を成仏するためQiitaに投稿。この手のネタ記事は今どきはZennじゃなくてQiitaかもしれない英語分からないマンはGoogle自動翻訳に頼りすぎも良くないのかもしれないというわけで、日本語記事が一つもなかったので誰かが今後引っかかったら屍を超えていってくれ~~

# エラー対応　参考：
~~（ホントはあと10記事以上探していた）~~

https://stackoverflow.com/questions/62455716/typeerror-cannot-destructure-property-userid-of-req-body-as-it-is-undefined
React.FC と React.VFC

memo.

## 結論

- 関数コンポーネント自体の型定義。
    - 指定することで、JSX を返却していないとエラーに出来たりする。
- React v18 以降は、`React.FC`　を関数コンポーネントに指定すると良い。
    - v18 から children が除外されるから。
    - v17 までは `React.VFC` を利用する。
- children を明示的に型指定（`children: React.ReactNode`）する。

```TypeScript
// React.FC 型
export const FooProvider: FC<FooProviderProps> = (props) => {

// () => JSX.Element 型
export const FooProvider = (props: FooProviderProps) => {
```

## 参考資料

> 基本的には型推論に任せて () => JSX.Element 型のままでOK
> コンパイルのパフォーマンスや保守性を重視するなら明示的に型を指定しよう

https://kray.jp/blog/dont-have-to-use-react-fc-and-react-vfc/

https://zenn.dev/seya/articles/0317b7a61ee781

https://zenn.dev/json_hardcoder/articles/4c730bcd4344bf

https://qiita.com/cheez921/items/ad9de98c60fb63b2abe8

https://maku.blog/p/xenv4bh/
AppleScriptでメディアの再生状態を取得する

# AppleScriptの資料少ない気がする（のは気のせい？）

個人的な目的：AmazonMusicを夜は再生状態なら停止させたい。

## Amazon MusicをAppleScript（Automator）で停止させる。（22.08.02時点）

AppleScript初心者の私が分かった事は、AppleScriptを使えば、個別のアプリケーションのGUI情報の取得、アプリケーションの制御できそうな事。・・・セキュリティ的に危なくないか？と思いました。（当たり前の事を言ってる？）
「セキュリティとプライバシー」の設定は慎重に。

```AppleScript
tell application "System Events"
	tell process "Amazon Music"
		set amazonMusicState to name of menu item 1 of menu 1 of menu bar item 5 of menu bar 1
			
		if amazonMusicState is "一時停止" then
				
			tell application "Amazon Music"
				activate
				tell application "System Events"
					key code 49
				end tell
			end tell
		end if
	end tell
end tell
```

メニューバーの再生状態の表示が切り替わるので、それを利用して停止させてます。


参考資料


https://qiita.com/hann-solo/items/aedd495f91cc4963bdb7

## コントロールセンターで取得する方法


```AppleScript
tell application "System Events"
	tell its application process "ControlCenter"
		click menu bar item "コントロールセンター" of menu bar 1
		try
			set btns to button "一時停止" of window "コントロールセンター"
			set isPlaying to true
		on error
			set isPlaying to false
		end try
		click menu bar item "コントロールセンター" of menu bar 1
	end tell
end tell
```

何か他の方法がある気もします。ご指摘があれば修正します。
kintone ちょっと便利なプラグイン 編集画面表示時にレコード更新チェック

[ちょっと便利なプラグイン](https://qiita.com/rex0220/items/45883f15ccd34a68b8af)で「F41 編集画面表示時にレコード更新チェック」機能が追加されました。
詳細画面から編集画面に切り替わるときに、レコードの更新チェックを行います。

# 概要

編集画面表示時に、レコードが他で更新されているかチェックを行います。
レコードが他で更新されている場合は、ダイアログでエラー表示し、画面を再表示します。


![2022-05-05_20h00_12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/79d896d4-a0ec-2873-e964-1a286fe62f74.png)

# ちょっと便利なプラグイン設定

「F41 編集画面表示時にレコード更新チェック」をチェックして、保存してください。
![2022-05-05_19h57_57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/9810889d-fcc3-0af7-9878-0a74559bebfb.png)

# 注意事項

編集画面表示中に、レコードが他で更新された場合は、通常のエラーが表示されます。
この場合は、レコードを再表示して、再度編集をやり直してください。

![2022-05-05_20h01_28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/da170669-aba9-be44-f4a1-d572569c7693.png)
Plastic SCM 新組織の作成方法など


# この記事は何？
Unity 標準のバージョン管理システム Plastic SCM 導入の手順メモ

簡潔な日本語情報が少なく、若干手間取ったので公開
メモレベルで簡潔に書く

Plastic SCMの詳細な使い方は書かない

# 新組織の作成方法

公式トップページ（https://www.plasticscm.com/）
↓
PRICING（https://www.plasticscm.com/pricing）
↓
プランを選択
↓
必要情報を入力
↓
新組織用のクラウドストレージが用意される

（確認：https://www.plasticscm.com/dashboard/cloud に新組織が追加されているはず）

## ダッシュボード
https://www.plasticscm.com/dashboard/cloud


# 組織にメンバーを追加する
ダッシュボード（https://www.plasticscm.com/dashboard/cloud ）
↓
対象組織で
configure > User and groups
↓
Add new user
↓
Email 入力

# Unity プロジェクトに 新組織でPlastic SCMを導入

UnityのプロジェクトでPlastic SCMを導入（右上のPlastic SCMのアイコン）
↓
「新規ワークスペースを作成」と表示される
↓
「Repository Name」入力欄右の「New」ボタンを押す
↓
「新規リポジトリを作成」ウィンドウが表示される
サーバーを選べる
さっき作った新組織のサーバを選ぶ
↓
新組織のPlastic SCMで管理できる

# Unityプロジェクト　Plastic SCMのデータを消す（ローカルファイルは無傷で残る）

Unity でPlastic SCMタグを開く
↓
設定ボタン
↓
Turn off plastic scm for unity

Plastic SCMのデータ、設定などは消えるがファイルは残る
povo 2.0 でSIMの電話番号が「不明」となるのは仕様

## 経緯
　Google Pixec 5a に他の機種でアクティベートした pove 2.0 のSIMを入れたら普通に使えたので、気が付かなかったのですが、この度、セールに釣られて Pixcel 6 に機種変して 5a からSIMを外して 6 に入れ、APNの設定をしようとしたが、設定箇所にたどり着けず、Google のサポートとやりとしてなかなか解決しなかった。
　でも、電話の発信・着信、SMSの送受信、データ通信は問題なくできていることを確認した。

![SC_StatusOfNetwork.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/16491/72ffc3fa-e012-f89d-5f8c-0262d543e32c.png)


## Google Pixcel 6 で povo のAPNを設定する方法
　Google Pixcel 6 (Android 12）で、SIMの設定をしようとすると、セットされているSIMでSIM発行会社の設定が組み込まれてしまって、自分で設定することができませんでした。
povo から送られた説明では、APNを自分でセットするようになっていますが、できません。
で「設定」の中を調べ回って、APNを追加・編集する方法を見つけました。

### APN を独自に設定する手順
　「設定」から「ネットワークとインターネット」 - 「SIM」をタップした画面。の下の方にある「アクセスポイント名」をタップします。
![SC_GoAPNsetting.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/16491/b11ddfda-f8d8-6c68-5dc4-a8afdc3d1136.png)
そうすると、APNの画面が出てくるので、この画面で「＋」で追加したり、編集したりすることができます。
![SC_APN.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/16491/47ec644c-ad1e-7311-050b-9f3a9b73526c.png)

## 電話番号が「不明」となるのは仕様なのだと
　　その後、「設定」の中を探していて電話番号が「不明」となっていることに気づいた。
そこで、今度は電話番号が「不明」になっている件で Googleサポートとチャットして、povoでは電話番号が表示されないようだとの回答を得たので、povoのサポートに質問メールを送ったところ、すぐに回答がありました。その中身を抜粋すると
『***povo2.0では、システム上【電話番号が表示されない仕様】となっております。
そのため、「空白」「不明」であっても正常となります。***』
とのことです。

## povo のSIMを使っていて電話番号が「不明」と表示されてもそれが正常
　ということですので、povo のSIMを使用していて、電話番号が「不明」と表示されても心配することはありません。
　送られてきている契約書で電話番号が確認できますし、信頼できる誰かに電話をかけて発信者番号を教えて貰えばわかります。（笑）

## 公開の目的
ここに辿り着くまで、いろいろ調べたり、サポートのお世話になったりしましたので、同じ轍を踏まないよう、情報共有のためここに公開しておくことにしました。
ネット検索でヒットすることがあれば嬉しい。