谷本 心 in せろ部屋 このページをアンテナに追加 RSSフィード

2017-10-30

PS3メモリーカードアダプターをPCに繋いで読み書きする

久々の投稿がゲームの、しかもニッチすぎる話題でアレですけど、備忘録として。


やりたいこと

1. PCに保存しているPS1のメモリーカードのデータを、PS1のメモリーカードに書き込む。

2. PS1のメモリーカードのデータを、PS3にコピーする。

3. PS3でPS1のゲームを起動して、メモリーカードのデータを読み込む。


背景

PS3では、PS3内に保存された仮想メモリーカードデータをUSBメモリ経由でPCにコピーできる。ただこのファイルは暗号化されているため、好き勝手できるわけではない。海外のエンジニアが復号ツールを作って公開しており、それを使えばメモリーカードのデータを閲覧することはできるのだけど、逆の暗号化ツールは作っていないため、任意のデータをPS3の仮想メモリーカードデータとして保存することができない。


要するに、USBメモリ経由で、

PS3 → PC はできるけど

PC → PS3 はできない

ということ。


ここで、PS3用のメモリーカードアダプターを使えば、任意のデータを読み書きできるようになるので、今回紹介するのはその方法。


用意するもの

1. PS3メモリーカードアダプター。プレミアがついて中古でも4000円ぐらいする。

2. Windows、今回は7の64bit版で。別にMac + Parallelsとかでも大丈夫。


手順

1. Windowsメモリーカードアダプターのデバイスドライバインストール

このサイトに書いてあることがすべて。

http://kazzx2.web.fc2.com/64bit_edit.html

ただ「64bit OSメモカアダプタドライバ」のURLが変わってるので注意。

http://www.axfc.net/uploader/so/1918620?key=DDR_KAZZ


2. MCRWwinを起動して、メモリーカードアダプターにメモリーカードを挿し、認識されればOK。


3. MCRWwinの「File(VM)」→「Read(File->VM)」を選択して、

 PCに保存しているPS1のメモリーカードのデータを指定する。

 拡張子は .mem が指定されるけど、128KBのファイルならまず読める。


4. メモリーカードへの書き込みが終わったら、メモリーカードアダプターごとPS3に接続


5. 起動後のメニュー画面からメモリーカードの管理を選んで、PS1のメモリーカードからPS3の仮想メモリーカードにコピー。

http://manuals.playstation.net/document/jp/ps3/current/game/mcsavedata.html

2017-01-11

TT-BA09で、テレビの音声をBluetoothで無線化してみた(成功編)

BABYMETALのライブが放送される時期だけWOWOWを契約する、ちょっとWOWOWにとっては迷惑気味なメイトのCERO-METALデス!


さて、普段ヘッドホンで音楽を聴くようになってから、テレビでもライブなどを観る時にはテレビのスピーカーでは物足りなくなり、ヘッドホンで聴くようになりました。ただ3mぐらいのケーブルを使ってもテレビまで近いですし、キッチンで料理や洗い物をしながらテレビを観る時になんかには使えません。

そんな背景から、テレビの音声をワイヤレスにしてヘッドホンで聴きたいなーと思っていました。


ちょうどWOWOWBABYMETAL東京ドームライブが放送される年末年始のこのタイミングで、テレビの音声をBluetoothで飛ばして、ヘッドホンで聴ける環境を作ることにしました。


何がいるの?

そもそも、テレビの音声をBluetoothで飛ばすには何が必要か、という整理からです。接続の流れはこんな感じになります。


テレビ → Bluetoothトランスミッター → Blueotoothレシーバー → ヘッドホン


テレビからの音声入力を受けてBluetoothで飛ばすものを「トランスミッター」と呼び、Bluetoothで受信をする方を「レシーバー」と呼びます。ITエンジニアの皆様方にも分かりやすく説明すると、トランスミッターがWi-Fiルーターに相当し、レシーバーWi-Fi子機に相当します。

またレシーバーとヘッドホンをケーブルで繋ぐものもあれば、ヘッドホン自体がレシーバーになるワイヤレスヘッドホンなどもあります。


製品の選び方

Bluetoothトランスミッターやレシーバーを選ぶ際の観点になるのが、次の2つです。

  • 音声入力の方式(ヘッドホンジャック、赤と白のRCAピンプラグ、光デジタルなど)
  • 対応コーデックSBCAACapt-X、LDACなど)

音声入力の方式はまぁ分かるので割愛するとして、よく分からないのがコーデックです。

ざっくり調べた感じ、次のような違いがあるようです。

  • SBC: ほとんどの機器が対応するけど、音質が悪い。
  • AAC: 主にApple製品で使われる。SBCより音質が良い。
  • apt-X: Androidや多くの機器で使われる。AACより遅延が少ない。
  • apt-X HD: apt-Xをさらに高音質にしたもの。まだ対応製品が少ない。
  • LDAC: ハイレゾ音源に対応するもの。音質は一番良いがソニー製品でしか採用されていない。

対応製品が多いapt-Xが、現在ではほぼスタンダードになってるようです。apt-Xに対応したトランスミッターはいくつかあるのですが、AACやLDACに対応した単体のトランスミッターというのは、ちょっと見つけられませんでした。


実際に買った製品

それで今回用意したのは、次の製品です。

この組み合わせで、ばっちりワイヤレスで視聴できる環境が整いました。


TT-BA09

音声のトランスミッター、レシーバーの両方に使える製品です。TaoTronics社からは似たような製品がいくつか出ているのですが、このTT-BA09は光音声入力があったので、これを選びました。ちなみにTT-BA09には音量を調整する機能がありません。


TT-BA08

上の製品と同じく音声のトランスミッター、レシーバーの両方に使える製品です。TT-BA09よりも一回り小さな製品です。

こちらはレシーバーとして使う際に音量の調整ができるようになっています。通常、光音声入力では出力側での音量調整ができず、レシーバーで音量調整する必要があるため、これを選びました。


それで、繋いでみると。

さすがは同じメーカーの同一シリーズの製品でしょうか、全く何の問題もなく接続できました。

接続はこんな流れです。


テレビ → (光音声出力) → TT-BA09 → (Bluetooth/apt-X) → TT-BA08 → (ケーブル) → ヘッドホン


Bluetoothを切断/再接続をしても、全く問題なく音声を聞くことができます。

また、テレビの音量を変えてもヘッドホンから聞こえる音量は変わらないため、テレビは消音にし、音量をTT-BA08で調整するような使い方になります。音量を調整できないレシーバーだと、こういう事ができないんですよね。


遅延とか音質は?

Bluetoothでよく言われるのが音声の遅延。

apt-Xでは40msほどの遅延があると言われており、口と声がズレるのを気にする僕としては、遅延があるのははっきり分かります。遅延があまり分からない人でも、テレビとヘッドホンの音を両方出せば、はっきりとズレていることは分かるでしょう。

ただ、そうは言っても40msですから、ズレを検出しようとしない限りは、さほど気にならない程度でした。


そして気になる音質ですが、これはとても良いです。

ショボいテレビのスピーカーに比べれば音声はクリアに聞こえ、特に海外映画などの英語もだいぶ聞き取りやすくなりました。音楽番組などもしっかり低音が聞こえるのは、さすがヘッドホンですね。

音楽番組を流しっぱなしにしながらリビングキッチンでウロウロしても、ヘッドホンで聴けるのは最高です。


・・・ということで、特にトラブルも起きることないつまらない話になったのですが、実はこの前に、別メーカーの製品との組み合わせでトラブルがありました。せっかくなので、それについては、また改めて書きたいと思います。


See you!

2016-12-08

Optimizing JavaというJavaパフォーマンス系の書籍が面白そう

急激な冷え込みのせいで「寒い!」というつぶやきがTLに散見されるこの頃ですが、皆さんお風邪など召していらっしゃらないでしょうか。

否応なしに寒いという言葉に反応してしまう、けなげなエンジニアの @ です。


このエントリーは Java Advent Calendar 2016 の8日目です。

昨日は @ さんの「Java Stream APIでハマったこと」で、

明日は @ さんの「マイクロベンチマークツール、JMHについて」でした。


今日のエントリーでは、Javaのパフォーマンス系書籍を紹介したいと思います。

Optimizing Java - O’Reilly Media

URLを見るにつけ、あのオライリー様のサイトですら拡張子が由緒正しい .do なのですから、日本のSIerがStrutsを使うことをどうして否定できましょうか。

いえ、今日はそんな話題ではありません。


紹介したいのは上のリンク先の本、「Optimizing Java - Practical Techniques for Improved Performance Tuning」です。名前の通り、Javaのパフォーマンスに関する書籍です。まだEarly Releaseの段階で、全体の1/3ほどしか書かれていませんが、現状の版を入手したので紹介したいと思います。


ここまでで、「あれ、なんか似たような本がなかったっけ」と思った方がいらっしゃるかも知れません。そう、オライリー社からは2015年に「Javaパフォーマンス」という書籍が出版されています。

Javaパフォーマンス - O’Reilly Japan

こちらの日本語版では、私も監訳者まえがきを書かせて頂き、Java Day Tokyoで寺田佳央さんと共にサイン会を行いました。

当時はきっと「この寺田さんの横にいて本に落書きしてる人、誰なんだろう」と思われていたかも知れませんが、私を誰だと思ってるんでしょう、せろさんだぞ?


この2冊について、比較しながら紹介しましょう。


目次

「Javaパフォーマンス」の目次は、次の通りです。

1章イントロダクション
2章パフォーマンステストのアプローチ
3章Javaパフォーマンスのツールボックス
4章JITコンパイラのしくみ
5章ガベージコレクションの基礎
6章ガベージコレクションのアルゴリズム
7章ヒープのベストプラクティス
8章ネイティブメモリのベストプラクティス
9章スレッドと同期のパフォーマンス
10章Java EEのパフォーマンス
11章データベースのベストプラクティス
12章Java SEのAPIのパフォーマンス

JavaのメモリやGC、スレッドに関する紹介から、SE / EEやデータベースのパフォーマンスに広げた話をしています。


一方、「Optimizing Java」の目次は次の通りです。

Chapter 1Optimization and Performance Defined
Chapter 2Overview of the JVM
Chapter 3Hardware and Operating Systems
Chapter 4Performance Testing
Chapter 5Measurement and Bottom-Up Performance
Chapter 6Monitoring and Analysis
Chapter 7Hotspot GC Deep Dive
Chapter 8Garbage Collection Monitoring and Tuning
Chapter 9Hotspot JIT Compilation
Chapter 10Java Language Performance Techniques
Chapter 11Profiling
Chapter 12Concurrent Performance Techniques
Chapter 13The Future

うん、ほとんど一緒やん?


「Optimizing Java」には、「Javaパフォーマンス」では触れられていたSEやEEの話などはないため、そこが差分になりそうにも見えます。ただ正直、「Javaパフォーマンス」の10章以降はちょっと薄口な感じでしたので、そこを飛ばせばほとんど同じ内容を網羅していると言えます。


では、何が違うんでしょうか。


Javaパフォーマンス vs Optimizing Java

僕が見た限りでは「Javaパフォーマンス」は教科書に近い内容、「Optimizing Java」はやや読み物寄りの内容になっています。

「Optimizing Java」は、現在執筆されているChapter 5までしか読めていませんが、「Javaパフォーマンス」には書かれていなかったOSやJVM周りのレイヤーの話や、テスト戦略の話など、少し目線が違った内容を書いていました。


たとえば、Javaのクラスファイルが「0xCAFEBABE」から始まっていることは、Javaに詳しい方なら既にご存じかと思います。ただ、その先はどうなっているのか。

書籍では次のように紹介されています。

  • Magic Number (0xCAFEBABE)
  • Version of Class File Format
  • Constant Pool
  • Access Flags
  • This Class Name
  • Super Class Name
  • Interfaces
  • Fields
  • Methods
  • Attributes

この先頭を取って

M V C A T S I F M A、

語呂合わせして

My Very Cute Animal Turn Savage In Full Moon Areas

なんて紹介されています。


「僕のとってもかわいい猫は、満月のエリアで凶暴になる」

・・・覚えやすいんですかね、これ?


あ、なんかふざけた本だなと思ったかも知れませんが、もちろん技術的な面もきちんと紹介されています。

あくまで上に書いたようなウィット(?)も挟みながら、Javaの領域だけでなく、必要に応じて低レイヤーにも触れて紹介する本となっているわけです。そのため、「Javaパフォーマンス」を読んだ方でも楽しめる本になるのではないかと思います。


で、いつ出るの? 日本語版は?

この本は2017年3月に出版予定となっています。


また、皆さん気になる日本語版ですが、残念ながらまだ翻訳されることは決まっていないようです。

ただ原著の人気が高かったり、この後に公開される6章以降の内容が「Javaパフォーマンス」とはまた違った切り口であり楽しめるのであれば、翻訳される可能性も十分にあるんじゃないかなと思っています。


そんなわけで、日本語版が出ることを祈りながら、このエントリーを書きました。

Stay tuned, see you!

2016-01-01

[]AWS LambdaでJavaとNode.jsとGoの簡易ベンチマークをしてみた。

あけましておめでとうございます!

現場でいつも締め切りに追われデスマーチ化している皆様方におかれましては、年賀状がデスマーチ化していたのではないかと憂慮しておりますが、いかがお過ごしですか。

エンジニアの鑑みたいな僕としましては、年始の挨拶はSNSでサクッと済ませ、年末年始は紅白など見ながらAWS Lambdaのソースコードを書いていました。


ということで、Lambda。

Lambdaを書く時に最初に悩むのは、どの言語を選択するか、なのです。


まず手を出すのは、サクッと書けるNode.js。

ただNode.jsの非同期なプログラミングになかなか馴染めず、わからん殺しをされてうんざりしていました。みんなどうしているのよとtwitterで問いかけたところ @ からPromiseを使うべしと教わり、なるほど確かにこれは便利ですナと思いつつも、これが標準で使えないぐらいLambdaのNode.jsが古いところにまたうんざりしました。


では手に馴染んでるJavaを使ってみたらどうかと思ったら、メモリイーターだし、なんとなくパフォーマンスが悪い感じでした。詳しいことは後ほどベンチマーク結果で明らかになるわけですが。


それなら消去法で残ったPythonなのですが、僕マジPython触ったことないレベルであり、これは若者たちに任せることにしているので、Pythonも選択肢から消えて。


本来、Lambdaみたいな用途にはGoが向いているはずなのだけど、いつ使えるようになるんだろうなぁなどと思って調べてみたら、Node.jsからGoを呼び出すというテクを見つけて、こりゃいいやとなりました。

http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/


ただGoを呼ぶにしてもNode.jsを経由するためのオーバーヘッドはあるわけで、じゃぁ実際にどれぐらいパフォーマンス影響があるのか、調べてみることにしました。


処理の中身

簡単に試したいだけだったので、数行で済む程度のごく簡単な処理を書いてベンチマークすることにしました。


1. 引数で渡されたJSONをパースして、中身を表示する

2. DynamoDBから1件のデータを取得する


当初は1だけだったのですが、あまり性能に差が出なかったので2を追加した感じです。そんな経緯のベンチマークなので、実装も雑ですが、とりあえずソースをGitHubに置いておきました。

https://github.com/cero-t/lambda-benchmark


実行結果
回数Java(1)Java(2)Node.jsGo
1回目218006700900600
2回目13007300800500
3回目19000500200500
4回目10001300200400
5回目500200400500
6回目400100200500
7回目400300400500

時間はいずれもミリ秒のBilled duration。


Java(1) : メモリ192MB。処理中にAmazonDynamoDBClientを初期化

Java(2) : メモリ192MB。処理前に(コンストラクタで)AmazonDynamoDBClientを初期化

Node.js : メモリ128MB

Go : メモリ128MB


メモリの実使用量は

Java : 68MB

Node.js : 29MB

Go : 15MB

でした。


考察など

正味の話、Lambdaで行っている処理などほとんどないので、性能的には大差ないかと思っていたのですが、思ったより特性が出ました。これは処理時間というよりは、関連ライブラリのロード時間な気がしますね。


Javaは最初の数回が20秒、実装を改善しても7秒とかなり遅かったのですが、ウォーミングアップが終わった後は200msぐらいまで早くなりました。呼ばれる頻度が高い処理であれば良いのでしょうけど、たまに呼ばれるような処理では、この特性はネックになる気がします。


ちなみにJavaだけは192MBで計測しましたが、最初にメモリ128MBで試したところ、30秒ぐらいで処理が強制的に中断されたり、60秒でタイムアウトするなど、計測になりませんでした。こういう所を見ても、Javaを使う時にはメモリを多め(CPU性能はメモリと比例して向上)にしなくてはいけない感じでした。


Node.jsも少しはウォーミングアップで性能が変わりますが、最初から性能は良い感じです。


Goを使った場合は性能が安定しており、ウォーミングアップしても性能が変わりません。メモリ使用量が少ないのも良いですね。Node.jsから呼び出す際のオーバーヘッドがあるせいか、性能的にはウォーミングアップ後のJavaやNode.jsに一歩劣る感じでした。


なお、Pythonの実装をしてくれる人がいらっしゃれば、プルリクしていただければ、データを追加したいと思います。


結論

繰り返しになりますが、雑なベンチマークなので特性の一部しか掴んでないと思います。

そもそもJavaだけメモリが1.5倍になっている(=CPU性能も1.5倍になっている)ので公平ではないですし。


ただ「たまに行う処理」を「少ないリソース」で行うという観点では、Goで実装するのが良さそうです。GoはそのうちLambdaでも正式サポートされそうですしね。

きちんとしたベンチマークは、また別の機会にじっくり行ってみたいと思います。


ということで、Goを使う大義名分ができたベンチマークでした!

See you!

2014-12-14

[][]MyBatisをやめて、JdbcTemplateを使うわ。

以前のエントリーで、DBアクセスにはMyBatisを選んだと書きました。

http://d.hatena.ne.jp/cero-t/20141212/1418339302


そしたら渋谷JavaのLTで @ さんに拾ってもらっちゃいました。

http://www.slideshare.net/yukung/j-ooq-shibuyajava9


そんなこともあってMyBatisイチオシなエンジニアに思われたかも知れませんが、

ごめんなさい、

あの記事はあくまでも伏線で、僕、もうMyBatis使ってないんです!


MyBatisを使って半月ぐらいして、

どうにも我慢できなくないことが出てきました。


1. Spring Bootとの連携がイマイチ

Spring BootでMyBatisを使おうとすると、

前回のエントリーで書いた通り、ちょっと設定ファイルが必要になったり、

その設定ファイルの読み込みに失敗して、謎の無限ループが起きることがあるなど、

やや不可解なことがあります。


設定ファイルの問題というなら、設定ファイルを使わず、

ソースコードだけで設定できれば良いのですが、その方法も、結局よく分かりませんでした。


まぁMyBatisAutoConfigurationとかができてからが本番というか、

ないなら自分で作るゾ、ぐらいの勢いで挑む必要があるように思いました。


2. XMLにSQLを書くと、インデントががが。

じゃぁMyBatisAutoConfigurationを作れば良いわけですが、

そういう気になれなかったのは、やっぱり、

XMLファイルにSQLを書くのが嫌だったから、でした。


だって、標準的なフォーマッタでフォーマットした瞬間、

インデントが全部消えるじゃないですか。


自動フォーマットをこよなく愛する僕としては、

フォーマットする手段がないというのは、いただけませんでした。


3. そこでJdbcTemplateですよ

じゃぁ何を使ってるのか?

で、結局、Springに標準でついているJdbcTemplateを使っています。


無設定で使えて、値のバインドは適切にできて、

NamedParameterJdbcTemplateならSQLに変数が使えて、

Entityにはアノテーションとか付けなくて良くて、

余計な機能はなくて、シンプルに使える感じでした。


ただ、もちろん、JdbcTemplateも欠点だらけです。

 ・publicフィールドに対応していない

 ・Java8のLocalDateなど、Date and Time API (JSR-310) に対応していない

 ・RowMapperを求めるAPIになっているなど、APIに古くさいものが混ざっている

 ・そもそも、SQLファイルを読み込む機能なんてない!


なので、これらを補うような

独自ラッパーでラッピングして使うことにしました。


詳しい紹介はまた改めて書くとして、モノはここに置いています。

https://github.com/cero-t/sqltemplate


独自ライブラリではなく、Spring標準のJdbcTemplateを

ちょっとだけラッピングして使っているだけなので、

政治的な意味で使いやすいかな、と思っています。