「SOUNDPEATS TrueAir ワイヤレス イヤホン」 エントリーモデルとしてはコスパ良好

SOUNDPEATS TrueAir ワイヤレス イヤホンを購入しました。
カナル型(耳に突っ込まないタイプ)でなく、耳に引っ掛けるものを探していた時に、この製品がコスパが良いらしいので買ってみました。
カナル型は耳に合わないことが多いし、耳が痛くなるので、耳に引っ掛けるタイプを探していました。
※使用状況は2週間ちょいです。

環境

• iMac 2019
• Android Xiaomi 5s

接続のしやすさ

接続してしまえばとても安定します。
ふたを開けるだけで接続されるのでとても使いやすいです。

ただ接続されるまでAndroidは難しかったです。何回試みても、接続してくれなかったので、諦めようかと思ったのですが、モバレジェ(ゲーム)を開いた瞬間繋がりました！(理由はわかりません・・・)

iMacは昔に持ってたワイヤレスイヤホンはキーボードとトラックパッドに干渉されてうまくいかなかったけど、これはそんなことは無くとても快適です。
以前のワイヤレスイヤホンは↓で格闘済み
iMac 2019 bluetoothイヤホンが接続されない時の苦肉の対処法 - TAKOYAKING’s blog

価格

安いです。
クーポンとかセールのタイミングで買えば4000円前後で買えるのではないでしょうか。正規料金は5000円くらいです。

音

こもった感じです。
iPhoneについているイヤホンみたいな音でクリアな音質ではないのは確かです。
でも耳に引っ掛けるタイプのワイヤレスイヤホンはどれもこんな音になっているような気がします。
逆に、カナル型だとクリアな音質になる傾向がある気がします。

音量操作

どこをタップしたらいいかわからないので、使いづらいと思います。
上の丸い部分をタップすると音量調整ができます。
慣れがかなり必要です。

付属の充電ケーブル

ものすごく短いのが付いてくるので、別のを用意した方がいいかもしれません。
iMacだと裏からつなぐので全然足りないです。

接続の安定具合

めちゃくちゃ良好
今のところぷつっと切れたことは無いです。

以前のワイヤレスイヤホン だとちょくちょく切れていたので、それと比べると遥かに良いです。

衛生面

カナル型(耳栓みたいなイヤホン)と比べると遥かに綺麗さを維持できます。
今のところ汚れる気配がないです。

電池の残量表示

電池の残量は減ったら赤ランプが点灯します。
見辛いですが安かったので妥協できる範囲です。

ただ充電する時、充電が完了しているか確認する方法がないので不便です。

電池のもち具合

体感的には仕様通りの時間だと思います。あんまり充電してなくても、ずっと使えているので、ここら辺は優秀だと思います。

見た目

AppleのAir Podsに酷似しています。
気になる方はやめておいた方が良いかもです。

まとめ

デザインの見た目を気にしなくて、耳にひっかけるタイプで格安のものを探しているならとても良い製品です。結構満足しています。

Unity: Addressablesでフォルダはネストできない

環境

• Addressables 1.8.4

現象

ざっくりフォルダごとにAddressablesで管理したい場合に、入れ子になったフォルダではできないようです。
ネストした状態でもUnity Editor上なら再生でき、ネストも一見できてるように見えるのですが、Androidビルドする時に以下のエラーが出るようです。

ArgumentException: An item with the same key has already been added.

以下のような構成にしてそれぞれのフォルダに対してAddressablesのチェックをonにしました。

- Prefabs (Addressablesのチェック)
  - 何かのspriteたち
  - Takoyakis (Addressablesのチェック) 
    - 何かのspriteたち

こういう構成だと、AddressablesのwindowではPrefabsとTakoyakisは別のGroupとして設定でき、別のラベルを設定できるのですが、いざビルドすると重複キーがあると怒られてしまいます。

対策

ざっくりチェックは諦めて、以下のようなツールを使って管理するのが良いかもです。
【Unity】【Addressable】Unity Addressable Importerでアドレスの設定を自動化する - LIGHT11

Unity: 落下の自前計算 (簡易版)

Cheap gravity script - Unity Answers

厳密には違いますが、簡易版で同じような動きになります。

そこまで正確に動きを計算する必要がないのでこれでいいならこれを使いたいです。

簡易重力を自前で計算した時の鉄球の動き↓

float velocity = 0;
void FixedUpdate() {
      var pos = transform.position;
      velocity += Physics2D.gravity.y * Time.fixedDeltaTime;
      pos.y += velocity * Time.fixedDeltaTime;
      transform.position = pos;
}

Unity: UniRxのUpdateAsObservable

UpdateAsObservable

Updateを実行することができる

使い方

using UniRx;
using UniRx.Triggers;

void Start() {
    this.UpdateAsObservable()
            .Subscribe(UpdateRx);
}

void UpdateRx(Unit unit) {
    Debug.Log("updating");
}

this.UpdateAsObservable()をSubscribeしてあげることで、Updateされ続けます。
そして、subscribeしたものはobject破棄のタイミングで消滅します。

便利だと思ったこと

Updateは別のscriptから初期化処理を呼び出してから呼びたい場合、

using UniRx;
using UniRx.Triggers;

public void Init() { // publicで他scriptからinit
    this.UpdateAsObservable()
            .Subscribe(UpdateRx);
}

void UpdateRx(Unit unit) {
    Debug.Log("updating");
}

こういう感じで書けるので、
Init
UpdateRx
の順番が保証できるので便利だな思いました。

Rust: getterとsetter

Rustでgetterとsetterを作りたかたったので調べました。

oop - Writing getter/setter properties in Rust - Stack Overflow
↑のサイトから拝借して、単純化してみると以下になりました。

#[derive(Default)]
struct Person {
    first_name: String,
}

impl Person {
    // Immutable access.
    fn first_name(&self) -> &String {
        &self.first_name
    }
    // Mutable access.
    fn first_name_mut(&mut self) -> &mut String {
        &mut self.first_name
    }
}

setterは関数内では値を代入せずに、&mutを返していて、受け取り元で値変更ができるようになっていました。
rustではこういうのはパターンの一つとしてあるようです。

疑問

setterで何かsetする前に値に応じて処理を行いたい場合はできないのではないでしょうか？

Rust：selfは糖衣構文

Rustのself引数まとめ - 簡潔なQ

selfは糖衣構文で&が付いていようがついてなかろうが、引数を使う時はself。
&selfで定義して、使う時は&をとったselfで使うことに少しもやっとしていたので、理解できてよかった
(&selfで定義するとselfが&selfとして利用できる糖衣構文)

struct ReactiveProperty<T> {
    value: T,
}

impl<T> ReactiveProperty<T> {
    fn value(&self) -> &T {
        &self.value // (self.valueの&)
    }

    fn value_mut(&mut self) -> &mut T {
        &mut self.value // (self.valueの&mut)
    }
}

Unityをアプデしたらエディタコンパイルが速くなっていた

環境

• Unity 2019.3.15 -> 2019.4.4
• iMac 2019

推測される原因 (予想です。)

Enter Play Modeが実装されてからソースコードを変更した時に行われるコンパイルが異常に遅くなっていました。昔なら3から5秒くらいだったのが、30秒以上かかることがざらになっていました。

推測ですがEnter Play Modeが実装されたせいで何か影響が出たのではないでしょうか？
Enter Play Modeで設定することで再生する速度はめちゃくちゃ速くなりましたが、エディタのコンパイル速度がとても遅くなったので、モヤモヤしていました。

2019.4.4に上げた

バージョンをあげると昔のようなコンパイル速度に戻っていました。

感想

いろいろ試しても全然元に戻らなく、開発効率が悪かったのですが、元に戻ってとても嬉しいです！
Enter Play Modeのおかげで再生のスピードも上がったし、コンパイル速度も元に戻ったので今のUnityのバージョンはとても嬉しいです。