俺のメモ帖

とあるインフラ系SEのメモ帖。趣味や技術的なもとか書けたらいいなぁ。

NW-A50シリーズが発表されたので過去のNW-A40・MW-A30シリーズと比較する

 

 

今年もSONY walkmanのAシリーズの新製品が発表されましたね。

 

発売日は2018/10/6ということで後半月ちょっとありますが、まずは過去のバージョンと比較して買うべきか見送るか見てましょうか。

NW-A40シリーズとNW-A30シリーズの違い

まず、NW-A40シリーズとNW-A30シリーズの違いのおさらいは以下の記事に詳細があります。

基本的にはマイナーバージョンアップ。
大きな違いは、『USB DAC機能』が追加されたこと。
あとは、対応フォーマットがちょびっと増えたこと。
外見はまったく同じ、サイズも重量も。

 

では今の価格はどうなってるでしょうか?

 NW-A30シリーズの一番安いモデルは、Amazonで19,900円。

 NW-A40シリーズの一番安いモデルは、Amazon21,600円。

 ふむ、今でも価格に1700円差があるのですな。

USB DAC機能が不要であれば、NW-A35を買って、差額に700円くらい足して64GBのSDカード買った方が幸せになれる気がしますな。

 

 

NW-A50シリーズとNW-A40シリーズの違い

では、この記事のメイン。NW-A50シリーズとNW-A40シリーズを比較してみよう。

大きな違いは、『USBレシーバー機能追加』

ざっくり言うと、スマホや他のミュージックプレイヤーからBluetoothで音楽飛ばして、NW-A50の高音質や音響効果使った再生を可能にする機能ですかね。

 

仕様表の比較結果を前回と同じく、主な差分のみまとめます。

項目 NW-A50シリーズ

NW-A40シリーズ

対応フォーマット

基本的には同じ。

以下の対応周波数が変更。
FLAC ( .flac):16, 24bit / 8-384kHz
・WAV ( .wav):16, 24, 32bit(Float/Integer) / 8-384kHz
Apple Lossless ( .mp4, .m4a):16, 24bit / 8-384kHz
AIFF ( .aif, .aiff, .afc, .aifc):16, 24, 32bit/ 8-384kHz

基本的には同じ。

A50シリーズの赤字部分が192Khzまでの対応だった。

Bluetooth機能

送信は同じ。

対応コーデック(受信) : SBC , LDAC, AAC

送信は同じ。

受信機能はなし。

Bluetoothレシーバー機能
最大外形寸法
(幅×高さ×奥行/mm)
約55.7mm x 約97.3mm x 約10.8mm 約55.9mm x 約97.5mm x 約10.9mm
充電池含む(g) 約99g

約98g

あと、仕様以外に細かい部分では以下の相違がありますか。

  • 若干のデザイン変更。
    物理ボタンを若干変更し、ボタンが丸くなり、再生・曲送り・曲戻しボタンが分離された。
    側面が今までより丸くなった。
  • 音質向上のための施策
    金入り高音質無鉛はんだをバッテリー接続部に使用。
    DSEE HXにAI技術を搭載?

うーむ・・・

変更点全体を見渡してみても、どうみても今回もマイナーバージョンアップ・・・。

せっかくの新機種なのだから、最低でも以下を実現してほしかった。

  • バッテリー大容量化
    バッテリーなんて、NW-A30シリーズの頃から2年も経つんだから、同じサイズでより大容量にすることとかできなかったのでしょうか?
  • USB Type-C採用
    相変わらずのWM-PORT・・・。時代遅れもいいところです。なんでUSB Type-Cにしなかったんだ・・・
  • 画面に時計を表示
    まあこれは自分の個人的な好みです。

結論

NW-A35を保有していますが、今回も買い替えは見送りです。

どうしても欲しい機能があるとかじゃなければいまだにA35で良いのでは?って思ってしまいますね。

ほんと最低でもUSB Type-CにIFを変更するくらいのことはやって欲しかった。

えっと、NW-A55の予約時の価格が23,630円なので、A35との差額が3700円!

やった!あと500円出せば128GBのMicroSDカードが追加できる!!
128GBあれば39,830円の64GBモデルにも勝る(笑)

 以上、超偏見に満ちた比較ですが参考になれば幸いです。

戻り値で結果を判定する場合に注意が必要なコマンド(tarやping)

バッチファイルやシェルスクリプトを作る際、コマンドの結果を戻り値で判定することは多々あると思う。

ただし、いくつかのコマンドは注意が必要な場合がある。

その例を2つほど示す。

  1. WindowsPINGコマンド
    お馴染みのネットワーク疎通確認コマンド。
    大抵は、戻り値が0だったら疎通OKって組むと思う。
    だけどこれはNG。実は戻り値0でも失敗する場合もある。

    ①成功の場合(戻り値=0)

    f:id:infrase:20180622171420j:plain

    ②失敗の場合(戻り値≠0)

    f:id:infrase:20180622171614j:plain

    ここまではよくあるパターン。大抵はこの2つを戻り値で分岐させて生存監視としている。
    でも、実は次のようなパターンも存在する。
    ③失敗の場合(戻り値=0)

    f:id:infrase:20180622171726j:plain
    宛先に到達できていないのに戻り値が0で返ってきている。

    じゃあ戻り値以外でどうやって判断するか?
    確実にそうとは言えないんだけど、以前居たプロジェクトでは標準出力の文字列で判断させた。
    日本語版のPING(WindowsXP以降のPING?)だと、正常な場合は『ラウンド トリップの概算時間 (ミリ秒):』という文字列が出力されるようだ。
    なので、以下のようにFINDとかと組み合わせて実行する。

    f:id:infrase:20180622172758j:plain

    ほかにも、「XXXからの応答」の後ろにバイト数・時間・TTLなんかが表示されていればOKっぽいので、それでもよいのかも。

  2. Linuxのtarコマンド
    こちらもお馴染みのコマンド。だけど、こっちも単純に戻り値0かそうでないかで判定すると、失敗する場合がある。
    それは、アーカイブ中にアーカイブ対象のファイルが更新された場合、警告が発生して、戻り値が1で返ってくる場合があることだ。
    そもそも、アーカイブ実行時に、対象ファイルを更新したりなんてことは、普通は行わないと思う。
    だけど、この前居たプロジェクトでは、何かまでは判別できなかったけど、稀にアーカイブ中に対象ファイルが更新されたという警告が出力されて、戻り値1で返ってきてジョブがこける事があった。
    それで、tarコマンドのことを色々調べた結果、これは特に問題ないため、戻り値1は正常終了扱いとして処理を継続するように修正した。

    一応、大きいファイルを準備して、そのファイルをアーカイブしている最中に、ファイルに追記を行う試験をしてみたところ、アーカイブされたファイル自体は、追記を行う前の状態だったため、問題がないと結論付けた。

    このときは結局、何が対象ファイルを更新しているかまでは追及しなかったんだけど、これを追及するとなると、「inotify」や「fanotify」とかで対象ファイルやディレクトリを監視しなければいけないので、結構面倒である。

 

以上、戻り値で結果を判定する場合に注意が必要なコマンドについて。

このメモはそういう事象があるたびに更新していくことにしようと思う。

 

 

仕事に使えるLinuxシェルスクリプト~bashで作る実用サンプル41

仕事に使えるLinuxシェルスクリプト~bashで作る実用サンプル41

 

少しでも参考になれば。

シャープ製加湿空気清浄機「KC-F50」「KC-G50」「KC-H50」の違いについて

我が家にある、シャープ製の加湿空気清浄機「KC-F50」。 

 

 1年くらい前に購入して、以下の記事を書きました。

infrase.hateblo.jp

 

それから、1年ほど経ってるので、当然新機種出ていますよね。
新機種「KC-H50」。 

シャープ プラズマクラスター搭載 加湿空気清浄機 KC-H50-W
 

 1年前の機種「KC-G50」。 

 

まずはメーカーサイトのスペックを比較。

まずは「KC-F50」と「KC-G50」。

仕様比較表(KC-G50/KC-F50)|空気清浄機|サポート・お問い合わせ:シャープ

そして「KC-H50」と「KC-G50」。

仕様比較表(KC-H50/KC-G50)|空気清浄機|サポート・お問い合わせ:シャープ

 

んー・・・・・違いどこよ?

スペック表をじっくり見てみた結果、違いは「KC-F50」→「KC-G50」になる際、待機時消費電力が0.4Wから0.3Wに少なくなっていることだけですね。

ほんとにこれだけしか違いがない?

わざわざ名前変えて3機種も発売する?

値段も最新機種だけやけに高いけど、それに見合った機能差があるのか?

 

そこで、思い切ってメーカーに問い合わせてみました。

メールで問い合わせを投げて10分後に電話がかかってきたwサポート早すぎw

返答に1週間とかかかるJR東日本とかに見習わせたいです。

まあそれはさておき、問い合わせ結果ですが。

  • 「KC-H50」と「KC-G50」は型名が違うだけ!!(笑)
  • 「KC-F50」は送風口が自動で開閉するけど、「KC-H50」「KC-G50」は手動。
  • 「KC-G50」は以降の機種は、「KC-F50」から以下の機能をカットしている。
    ①梅雨モード
    ②ホコリセンサー(たしかPM2.5も含まれるはず)
    ③エアコン連動
    ④デジタル切タイマー
    ⑤運転自動復帰
  • お勧めは「KC-F50」←メーカー公式サポートさんが言ってましたw

つまりは、一番古い機種の「KC-F50」が一番機能が豊富!!

いつまで古い機種を販売し続けているか不明ですが、買うなら「KC-F50」一択! 

そりゃAmazonや価格COMのランキングで1位に居続けるわけですねw

 

 まあ、メーカーサポートさんが言うには、あんまり使われてない機能だったんでカットしたとのことなので、そこまで重要視する必要はないのかもだけど。

ただ、「送風口自動開閉機能」と「ホコリセンサー」はあったほうが絶対にいいと思うんだけどな。

1年前に購入した際は、ここまで詳しく調べなかったけど、「KC-F50」購入で正解だったと思う。

しいて最新機種の利点を挙げるとすれば、メーカーのサポート期間が2年くらい長いんだろうなってことくらいか・・・。

 

以上、加湿空気清浄機購入時の参考になれば。

SJISで半角カタカナチェックに正規表現を使った際の落とし穴

フォームに、半角カタカナ限定の入力項目をおいて、入力項目チェックを正規表現を使って行った際の落とし穴。

 

まあこれも知ってる人には何を今更って感じなんだろうけど。

 

ちゃんと表示されるかわからないんだけど、
「^[ア-ンァ-ッ]*$」とか書いたんだけど、これで半角の「ア」~「ン」、「ァ」~「ョ」、「ッ」がチェックできると思って、全文字入力チェックしたんですよ。

すると、何故か「ヲ」だけチェックをすり抜ける。。。

※省いてるけど、濁点・半濁点・長音符も含んでました

原因は文字コード表見ると一目瞭然でした。

半角カタカナの文字コード上での並び順が酷い(笑)

誰がこんな並びにしたのか・・・

f:id:infrase:20180315222601j:plain

見てわかるんだけど、なんで「ヲ」が「ァ」の前にあるの・・・???

 

「^[ア-ンヲ-ッ]*$」で解決。ふざけんな。

軽く調べてみたら、以下のような情報が。

oshiete.goo.ne.jp

なんか大正時代に山下芳太郎って人がキー配列を決めたせいらしい

 

これも社内ナレッジで共有しとこ。

 

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

 

 

Javaの仕様書のShift-JISコードって記載に注意

Windowsで使われているおなじみの文字コード「Shift-JIS(SJIS)」。

だが、実は厳密にはShift-JISではなかったので、軽くはまった件。

 

知ってる人なら、なんだ今更的なことなんだろうけど。

実はWindowsで使われてるのは厳密には「SJIS」ではなく「Windows-31j(MS932もしくはCP932)」という別物の文字コードセットだったということ。

 

以下のような処理を作っていた時の話だ。

  1. 画面から文字を入力。
  2. byte配列に変換して、ホストへ送信。
  3. ホストはbyte配列をデコードし、内容をチェックして、問題なければデータを検索し、検索結果をもどす。
    認識できない文字が存在していると、エラーコードと認識できない文字自体をエラーメッセージに設定して再度Byte配列として返す。
  4. 返却された処理結果をSJISに戻して、PDFに変換して表示する。
    エラーメッセージが含まれている場合は、byte配列をSJISに戻して、画面にエラーメッセージとして表示する。

 

もうなんてことない単純な処理ですね。

ところが、システムではいくつか独自の外字が使用されていた。

また、機種依存文字は許可されない仕様だった。

そこの考慮がされていなかった。

 

そのため、以下の異常動作が発生した。

  1. 外字を入力すると、文字列 <=> Byte配列 の変換を行う際に、変換時に例外が発生する。
  2. エラーメッセージをSJISに戻すと、機種依存文字が??となってしまう。

文字コードの差を知らなかったため、コードを見てもどこにも変な箇所がない。
で、外字に関して調べたんだけど、そこで以下を知る。

  • 外字エリアって、SJISだと文字列として認識できる範囲外に登録されている。
  • Windowsで使われているのはSJISといいつつ、実はMSがSJISを独自拡張したWindows-31Jという文字コードだった。

くわしくはこのページあたり見てもらえれば。

[Java] シフトJISの扱い - Qiita

このため、外字がSJISでは実は扱えないことを知る。

 

今までそんなこと全く知らなかったわ・・・。

C#(.NET Framewrok)ではGetEncodingで使える文字コードセットは、SJIS=MS932=CP932=Windows-31Jで定義されてるようで、こっちは差がないっていうね。
というか、逆に.NET だと純粋なSJISでは扱えないってことらしい。
これ、問題にならないのかね?

 

代表的な文字としては、「髙」とかですかね。
うちの社員にもこの字使う人います。ついでに、システムではこれ外字としても登録されていたっていうね。パッと見、外字なのか機種依存文字なのかわからんので、さらにややこしかった。

 

結果として、エンコード・デコードを行ってる箇所で指定してある「SJIS」を全部「Windows-31j」書き換えることで解決した。

 

今回のような経験がないとおそらくこういう知識増えないんだろうな。
だから仕様書書いた人も全く疑問持たずにSJISって書いてたんだろうな。。。

今度社内でナレッジとして共有しよう。

 

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)

プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ)