JBL PebblesをEdifier P12にアップグレードした

2017年にJBL Pebblesを購入してから、大きな不満なく使用してきましたが、もう少し良い音を楽しみたいな、と最近欲が出てきました。

また、音質とは違いますが細かい不満として、自宅では(同時に使うことはほとんど無いものの)複数台のPCを使用しており、起動するPCにPebblesのUSBケーブルを接続し直す、ということを毎回のように行っていました。

そんなわけで、もう少し音声入力方法も改善したいというのもありました。

Amazonでとにかくいろいろ検索してみました。かなり悩みました。

最初は価格コムでも高評価のEris E3.5にしようかと思ったのですが、最安で購入できそうなヨドバシだと納期が2ヶ月くらいかかるので、残念ながら候補から外しました。

次は、評価も高かったYAMAHAのNS-BP200BPに傾いたのですが、奥行きサイズ287mmが引っかかりました。120cm x 70cmの事務机の上に設置するのに問題がありました。物理的には配置可能ですが、右側にモニターアームがあり、干渉してしまうことが明らかでした。

それで、最終的にEdifier P12を購入しました。パッシブスピーカーなので、別途アンプが必要です。P12のレビュー欄でオススメされていたXY-AP15Hも購入しました。ところが、中国発送らしく、発送の連絡は来たものの、到着まで時間がかかるので、先にスピーカーだけ納入されてしまいました。どうしても音を鳴らしてみたいという欲求がありましたので、年内に納入可能だったBluetoothステレオボードも購入してしまいました。

上記2つのアンプは電源が必要なので、DC12V3A電源アダプタも購入しました。外径内径はこの商品で適合するはずです(少なくとも後者のアンプは使用確認済み)。それほど爆音で鳴らすわけでもないので、とりあえず36Wで。

到着したP12をJBL Pebblesの横に置いてみました。

到着したP12をJBL Pebblesの横に置いてみました。

中華Bluetoothアンプが奥に写っていますが、拡大したものがこちらです。

Bluetoothアンプ拡大

このアンプ、ボリュームつまみを左まで回し切ると電源が切れるようになっており、細かい配慮が気に入りました。若干芯線の露出部が長いのが怖いですが、それほどいじるわけではないので、多分ショートすることはないと見込んでカットしていません。

早速スピーカーを鳴らしてみました(まだアンプの関係でBluetooth接続のみ)。

定量的に評価できるような機材がないので、主観でしかないのですが、5年使用したPebblesより低音部が鳴っています(離れた場所で低音が聴こえるので違いがわかる)。ただ、Pebblesもバランスは高いと確認できました。聴き比べると、若干Pebblesは高音が刺さる感じ。Pebblesはボーカルに最適化されているのか、ボーカルが目立つ気がします。P12は長時間の視聴には良いのではないかと思います。クラシックを聴くなら、低音が出ている分、P12の方が圧倒的に良いように感じます。ポップスであれば、ひょっとすると好みの問題かも知れません(所詮YouTubeの音源だとそれほど違いがわからない??)。

流石に電力的にもサイズ的にも大きいので、Pebblesよりも迫力(音圧)があるような気がするようなしないような。むしろBluetoothで再生できるのがとても便利です(そこ??)。PC起動しなくてもiPadや携帯から飛ばせますし。

また、音質とは直接は関係無いですが、今回使用したBluetoothアンプは、無音期間後に音が出る場合、最初の一瞬だけ音が出ないようです。どういう仕組みでこうなっているのかわかりませんが、省電力化のために無音時にスピーカ出力を抑制しているのでしょうか。

思いの外、机上に2つスピーカーを設置しても問題なかったので、しばらく両方のスピーカーを気分で併用することにしました。もう一つのアンプが到着したら、有線接続での再生も試してみたいと思います。

2023/1/19追記: XY-AP15H到着したので使ってみました。正直なところ、Bluetoothで接続する限り、音質の違いは分かりませんでした。こちらはAUX inで3.5mmジャックが使えるのですが、どうやら本体に刺しただけで他の入力(Bluetooth, USB)が無効になってしまうようで、使い勝手は微妙な感じでした。USBについても、挿抜をしないとPCから認識されないことがあるようでした。というわけで、結局一番手軽なBluetoothで使うことになりそうなので、Bluetoothステレオボードのままでも良かったかもしれません….

でも、スピーカがエージングされたのか、自分の耳が最適化されたのか分かりませんが、やはりJBL Pebblesより音質面では満足しています。慣れた後にPebblesを聴くと安っぽく(?)感じます。セット価格でもPebblesの倍近くかかっていますので、これくらい効用がないと意味がありませんが…

モトローラ moto g52j 5G購入

前回の記事で、スマホの機種変更について触れたのですが、 XiaomiからMotorolaのmoto g52j 5Gに変えました。

Xiaomiは性能は全く問題を感じなかったのですが、購入当初から、とにかく電池の減りが早いのが気になっていました。 全く使用していなくても最低2日に一回は満充電にしないと心許ない感じでした。結局1年も使用せずにMotorolaに変えてしまいました。

2週間程度使用しましたが、電池の減りが気になることは特に無く、安心して使えています。nano SIMとしてIIJ mioの4Gタイプを、 eSIMとしてpovo 2.0を使っています。povoは電話番号維持用なので、まだ課金して使っていないのですが、 SIMを切り替えると、初めて見る5Gのマークが出てきました(いずれ課金して速度を見てみたいと思います)。 もちろんおサイフケータイも問題なく使えています。

素のAndroidだと、設定で現在の通信速度を表示することができない(違っていたら教えてください)ようで、それがちょっとした不満です。

全体としては、とても満足しています。

AWSのMFAキーを紛失して17,000円払った話

先日スマホの機種変更をした際に、AWSで使用しているMFA(Multi-Factor Authentication)キーの移行に失敗して、 解除してもらうのに(2022/9/9解除完了)17,000円の費用がかかった話です。

これまで、AWSへのルートユーザのログインには、Microsoft Authenticatorを使用して、コードを入力していました。

先日スマートフォンを買い替えた際に、当然新しい機種にもこのアプリをインストールして、 まずoutlook.comのアカウントを移行しました。 AWSのアカウントも古いスマホには表示されているのですが、「バックアップ」機能なるものがあるそうなので、新しいアプリでもAWSアカウントを後から追加できるだろう、 と思い、(どこで読んだか失念)勧めに従って古いスマホからはアプリを削除しました。

….この時点で実はかなり詰んでます。

このアプリでは、どうやら(成功しなかったので実際に確認したわけではない)古いスマホでまずバックアップを作成し、 新しいスマホにアプリをインストールして起動した直後に「回復」をしないといけないようです。 一旦「回復」せずにMicrosoftのアカウントだけ移行してしまい、新しいスマホ側でバックアップがONになっていると、 おそらく古いスマホで設定した、それ以外のアカウント情報は無くなってしまうと思われます(このあたりは若干不確か。古いスマホでAWSのアカウントが正しくバックアップされていなかった可能性もある)。

いずれにせよ、Microsoft AuthenticatorではAWSのアカウントは復活できなさそうということに気づいたので、 何らかの回避策を利用してAWSにログインできるか試してみました。 AWSのコンソールからルートユーザを選択し、メールアドレス、パスワードを入力しました。次いで、本来であればMFAのコードでログインできるのですが、 もう情報がなくなっているので、それっぽい"Sign In Using Alternative Factors of Authentication"を選択します。 すると、登録されたメールアドレスにリンクが送られてくるので、そちらをクリックします。 次いで、登録された電話番号で電話を受けて、コードを入力してログインできます。

…というのが普通なのですが、表示された電話番号下4桁を見て気づきました… もうこの電話番号解約済みだし… MFAデバイスの紛失および故障時の対応 に記載されていますが、ルートユーザのMFAデバイスの回復には、 アカウントに登録されているEメールと主要連絡先の電話番号が使えることが必須です。 これが満たされない場合、サポート依頼をせず回復することは不可能です。

というわけで、“Contact Customer Service"からヘルプ依頼を出しました。

すると、平日にAWSから電話がかかってきました。最初は上記MFAデバイス紛失時の対応方法のように、電話をかけるので、コードを入力してと言われるのですが、 そもそもそれができなくなっているので、ヘルプをお願いした旨伝えました。

すると、回復方法をメールで案内する旨伝えられます。しばらくするとメールが送られてきました。MFAを解除するには、必要書類に記入して提出せよ、との内容です。

実は、この必要書類が本題です(前書きが長かった)。

日本の企業であれば、免許証のコピー提出程度で許してくれそうですが、さすがは訴訟大国アメリカ、そうは問屋がおろしません。

主な書類は、"MFA Identity Verification Form and Affidavit“という英文フォームです。これを印刷して、公証人(Notary Public)による認証を受けてサインしてもらったものを提出しないといけません。 これは宣誓認証にあたるようです。大雑把にいうと、自分が当該アカウントを所有しており、虚偽があって第三者がAWSを訴えるような場合、自分が全責任を負う、といった内容について宣誓を求められます。

自分で記入するだけでは飽き足らず、公証人による認証まで要求するところがアメリカンです。

本場アメリカでは、州によって費用は違うようですが、(Notary Public Fees, Notary Fees: What the Notary May Charge to Perform Services in California) 最近のドル円レートで計算しても、2,000円程度で済みそうです。

2,000円程度なら、まぁ仕方ないね、で済むと思いますが…

日本だと17,000円かかります

えっ… 私のAWSのMFAロック解除にかかる費用高すぎ!?

日本公証人連合会のホームページで案内されていますが、手数料は"宣誓認証” (11,000円)に該当し、かつ"外国文の認証” (6,000円)が適用され、合計17,000円となります。 予約は必要でしたが、手続自体は30分程度もあれば完了します。

いわゆる天下りした方々が公証人になっているようで、実に美味しい商売です。

個人の実験用アカウントで、費用請求されるほど使用しているものではなかったので、放置というのも一瞬頭をよぎりましたが、 後々面倒になるのも困るため、やむなく17,000円払って書類を準備して提出しました。そもそも公証役場自体、利用するのは人生初でした。

公証役場帰りに、ちょっと遅い焼肉ランチを食べました。17,000円からすれば2,000円以下なんて誤差の範囲ですね!! (泣)…

焼肉

ちなみに、役場の女性と少し雑談した感じでは、同じような状況での公証依頼はぼちぼちあるようです。

対処方法としては、以下のように

  • AWSに登録されている電話番号は常に最新のものにしておく(MFA移行に失敗した場合にロック解除するため)
  • そもそもMFAを使用しない
  • 新しいスマホのアプリでAWSのアカウントが追加されているまで絶対に諦めない(古いアプリを消さない)。移行がうまくいかない場合、 一旦古いスマホでAWSにログインして、MFAを解除して、新しいスマホで再度有効化することができると思います(未検証)。
  • SMSベースのMFAを使用する

いくつか考えられますが、最後の方法はそろそろ使えなくなるそうです。

とにかく、AWSでMFAを使用されている場合、十分注意し、絶対に私と同じ轍を踏まないようにしてください!! 代わりに17,000円で美味しいものを食べてください!!

ORMについて変節した

ORM (Object-relational mapping)については賛否両論あると思います。 私もこの件について思うところが最近あったので、ポエムを投下します。

「ORM SQL」といった感じで検索してみると

のような記事が見つかりました。不要とほぼ断言しているものから、積極的にORMを使う派の方まで。

私もこれまではどちらかといえば、「別にSQLで書けるのに、敢えてORMを使う必要性は無いのでは」と思っていました。 ただ、最近開発をしている際に、初めてORMを使いたくなる場面に遭遇しました。

これは、端的に言えば、上の3番目の回答に挙げられているORMの機能

  • 対応するオブジェクトを通じたレコードの更新、トランザクションの一定の隠蔽

に大きな有用性を感じたためです。

これまでの開発では、コードの開発前にRDBのスキーマがほとんど決まっていたので、 レコードの更新や取得を行うSQLは(手間でも)一回だけ書けば良い場面ばかりでした。

でも、今回経験した開発では、要件が完全に決まっていない段階で開発をスタートしたのもあり、 開発がある程度進んだ段階で要件が精緻化されたところ、(ER図でいうところの)エンティティのテーブルとの対応が大幅に変わる可能性が生じました。 具体的には、現実との整合性を保つために

  • あるエンティティは、これまでの単一のテーブルから、複数のテーブルの結合とした方が良い
  • これまで2つのテーブルにマップされていたエンティティは3つのテーブルの結合とした方が良い

といった状況です。

さて、これまで真心込めたSQLで結合してマッピングしていたエンティティですが、 いざRDBスキーマが変更になると、これらも書き直さなければいけません。当然、検索(SELECT)だけでなく、 更新(UPDATE)もです。多:多でエンティティの属性を取得するためにforループを回している記述も修正する必要があります。

困った… というわけでORMの出番です。実現方法は静的コード生成だったり、実行時のリフレクションだったりしますが、 基本的にORMではエンティティ間の1:多などの関係をメタデータとして記述することで、 関数一撃で関連するエンティティを取得できるようになるわけです。

もちろん、ORMでも、RDBスキーマが変わって際の変更がゼロとはいきませんが、複数のSQLやfor文を正しく書き直す労力を考えれば、 メタデータの更新と関数呼び出しの変更程度で対応できるのであれば、相当有用であると思いました。

まとめると、スキーマが完全に決まっており、将来的にも変更されることは(ほぼ)無い、というのであれば、 SQLのみで記述してもそれほど問題にはならないかも知れません。 一方で、要件に伴ってRDBスキーマが開発中にも変更される可能性があるなら、 ORMを使用するのは保険として大変役立つのではないか、と思いました。

ThinkCentre M75q Tiny Gen2 購入

昨年末(2021/12)になりますが、LenovoのM75q Tiny Gen2を購入しました。スペックはRyzen 5650GE, Windows 10 Home, 8GB DDR4, 256GB SSDといったところです。 税込みで59,950円。楽天Rebates経由で購入したので10% 5995のポイント還元があり、到着直後にメモリとSSDはそれぞれ32GB, 1TBに交換し、8GBのDDR4は約3,000円で売却したので、実質5万円くらいになりました。増設したDDR4 (CT2K16G4SFD832A)が14,560円、SSD (WD Black SN750 SE)が12,799円かかっているので、総額では8万円弱になっていますが。

サイズ感はほとんどMac mini (M1)のような感じです。Mac miniはUSB Type-Aが2個、Thunderboltが2個とHDMI, Ethernetしかありませんが、 M75Q-q TinyはUSB Type-Aが5個、Type-Cが1個、HDMI, DisplayPort, Ethernetがあるので、拡張性は高いです。メモリやSSDの増設が自分でできるのもポイント高いですね。

Mac miniは負荷をかけても全く音が気になりませんでしたが、こちらは多少音が気になりました。CPUの消費電力の差もあるのでしょうが、 定常状態でもファンの音が聞こえることからして、構造的な違いが大きそうです。ファンの排気口を自分の方に向けて配置しているのも気になる原因かもしれませんが。

リカバリのためのUSBメモリでブートしない問題と対処

SSDを交換してから、Lenovo純正のツールでUSBメモリを使用してリカバリを実施したのですが、これでちょっとハマりました。 最初はバッファロー K32GA-BK/Nにリカバリデータを書き込んだのですが、どうやってもこのメモリだと電源起動時に認識されず、 リカバリができませんでした。

設定の問題かと思っていろいろ試しましたが、全く動作しない。検索してみたら、同じような問題にぶつかった人がいたので、 結局KIOXIA 32GB USB3.2 Gen1を購入して、こちらで試したらあっさり成功しました。

まとめ

その後、昨年内にWindows 11のアップグレードもできました。安定して動作しています。 Mac miniはメモリを16GBにCTOしていますが、それでも色々な開発ツールを動作させるとメモリ圧縮が効き出して、 動作が若干緩慢に感じることがあります。M75q Tinyは32GBにしたので、私の使用する範囲内では全くメモリには不足なく、快適そのものです。

« 2/23 »