kazutomoのブログ

たまーに気が向いたらなんか書きます

iPhoneX を買ったらまず設定したい色域設定

iPhoneXを買ったんですけど、OLEDが黄色いんですよね…。

truecolorを切ると良くなるんですけど、OLEDは同じ色を出し続けると焼き付くので、
それを回避するために環境光にあわせて色を変えるというアプローチをとってるわけなので、それは生かしたいですよね。

 では、どうするか?というと、色覚異常対応の機能を使います。

f:id:kazutomo:20171105003804p:plain

f:id:kazutomo:20171105003816p:plain

f:id:kazutomo:20171105003830p:plain

f:id:kazutomo:20171105003856p:plain

f:id:kazutomo:20171105003907p:plain

ここで、青みを付けることで黄色っぽく見えるのを修正することができます。

スタンドに置くだけで充電できる無接点充電器が2000円強で買えるので、デスクにおいてみてはどうでしょう?

【ネタバレ無し】メイドインアビスを見て/読んで震えたので、紹介したい!

メイドインアビス(1) (バンブーコミックス)

実は、前期アニメの中でメイドインアビスは3話切りしてました。
ですが、振り返って、前期アニメの評価を確認してみたところ、メイドインアビスの評価が明らかに光っていたので、週末に見ました。

世界観は面白そうだとは思ったのですが、設定の重厚さに対してキャラクターがゆるふわ過ぎて、生かし切れないんだろうな。というので期待せず切ってしまっていたのですが、完全に期待を裏切られる形でした。

世界設定

とある島が舞台で、その島の中心には大穴が空いています。この大穴はアビスと呼ばれています。
アビスは不思議な世界で、見たこと無いような原生生物などがたくさんいます。
穴自体もすごく深くて、まだ底を見た人はいません。

しかも、アビスにはアビスの呪いと呼ばれる不思議な現象が発生し、上昇負荷とも呼ばれます。
アビス内で下に下る分には何の影響も無いのですが、アビス内で上に上ると様々な症状が体を蝕む。というものです。(つまり、帰り道がヤバい)

1層:軽い目まいと吐き気
2層:重い吐き気と頭痛、末端の痺れ
3層:二層に加え、平衡感覚に異常をきたし、幻覚や幻聴を見る
4層:全身に走る激痛と、穴という穴からの流血
5層:全感覚の喪失と、それに伴う意識混濁、自傷行為
6層:人間性の喪失もしくは死
7層:確実な死
深界極点:詳細不明

アビスに入れるのは探掘家のみで、探掘家もランク分けされており、ランクによって色の違う笛を持つ。
ランクによって潜れる深さが決まっており、最高ランクの白笛でも基本的に5層までしか潜らない。
5層以下に潜るときはラストダイブと呼ばれており、帰ってきた人はいない。

帰ってきた人がいないのに情報があるのは、気球のようなものを使って情報を発信しているから。(それも原生生物に阻まれて殆ど届かないんだとか)

キャラクター設定

リコ:
めがねの女の子。孤児院で育てられている。
孤児院での生活費はアビスで採掘した遺物を売って立てており、
リコは赤笛と呼ばれるランクで、1層まで潜ることが許されている。
母親は有名な白笛で、10年前にラストダイブをした母を探すためにアビスの深層を目指す。

レグ:
ロボット?の男の子。1層でリコが原生生物に襲われているのを助けた。記憶喪失。
手がワイヤーですごく伸びるし、手のひらからビームみたいなの(火葬砲)が撃てる。
なので、リコにはロボットと言われているが、人間性も高くロボットなのかは未知。
アビスの呪いの影響を受けない。

基本的に主要キャラクターはこの2人のみです。
孤児院の友達や、他の探掘家も出てきますが、この二人で深層を目指すことになります。

みどころ

思った(キャラデザの印象)以上に本格的で容赦の無い冒険。
アニメだと後半のエピソードなんかは、いろいろと唸らされるものがあります。

アニメでは原作4巻の前半までを映像化しており、原作は6巻が7月にでたところです。
ここからもわかるように、アニメは一区切りついているものの、まだまだ冒険の途中で終わってしまいます。

アニメを見たら、原作が読みたくなるのは必至。私も原作を買って一気に読んでしまいました。
アニメは非常に原作に忠実に描かれており、一部改変もあるのですが、それはそれで脚本家の意図が透けて見える変更で、すごく丁寧に作られています。
特に、アニメ化されたエピソードのハイライト部分が、マンガだとばーっと駆け抜けてしまっていた印象があったのですが、アニメだとかなり丁寧に時間をかけて演出されており、より感情移入できるようになっており、原作を補強する存在として非常に良くできていました。

さいごに

Amazon Prime Video でアニメは全話見れますので、アニメから入るのもいいでしょうし、
原作の巻数もまだ少ないので、原作から入ってもいいと思います。
とりあえず名作なので、お時間が取れるようであれば是非読んでみてはいかがでしょうか。

 

メイドインアビス 2 (バンブーコミックス)
 

 

 

第一言語をJavaからKotlinにした日

私が仕事として扱ったことのあるプログラミング言語は以下があります。

この中でも Java は特別で、15年近く愛用してきました。

Javaの優れている点

Java の優れている点として以下があるとおもいます。

信頼性の高いVM

インタープリタ言語の中にはランタイムのバージョンアップで動作が変わってしまったりすることも多く、なんたらenv といったアプリケーションを使って任意のバージョンのランタイムに固定するのが慣例となっていますが、Javaにおいては最新のJVMを入れれば大体なんとかなります。

クロスプラットフォーム動作

私は長らく Windows を開発機として使用し、Linux サーバで動作させる。ということをしてきましたが、Windows で動くけど Linux で動かない。という経験はしたことがなく、動作させるOSによって動作確認をやりなおす。というような手順を踏んだことはありません。
現在では開発機として Mac を使用していますが、その際も状況は変わっていません。

インタープリタ言語の中には高速化のためにネイティブコードをコンパイルして使用するものが多く、Windows でビルドした成果物を Linux に持っていってもアーキテクチャの違いによって動作しない。といったことが起こりえますが、Javaにおいては変なことをしなければそのようなケースはありません。

豊富なライブラリ群

これは今では多くの言語で豊富なライブラリを所有しているので、多くの場合はあまり差とは言えないかもしれません。
しかし、Java は現在も重要なポジションをしめており、多くの場合に優先してSDKやライブラリがリリースされる言語でもあります。

高速動作

Javaで記述されたプログラムは非常に高速に動作します。
また、スレッドを使って作成されたプログラムはマルチコアで動作します。
多くのプログラミング言語のランタイムがシングルコアでしか動作せず、プロセスフォークによってマルチコアに対応するしかない点を考えても、ここはかなり優位点といえます。

Javaのイマイチな点

Javaは多くの優れている点を持っているとはいえ、当然ながらイマイチな点があります。

  • ランタイムがでかい
  • VMがあたたまるまで時間がかかる
  • 言語仕様が堅い
  • NullSafety ではない
  • ストリーム処理がダサい

ランタイムがでかい

これは C/C++golang のようなネイティブコードを出力するプログラミング言語に対してのイマイチな点です。
ランタイムによって多くの恩恵を得ているのでやむを得ない面もあるのですが、省メモリ・省ディスクスペースを要求されるケースではJavaが使用できないことにつながっています。
たとえば、ニンテンドー3DS の OS 開発をした際には C++ で開発しましたが、これはJavaの入り込む余地のない世界といえます。
特にメモリの面は問題として大きく感じており、Hello World を動かすだけでも数MBのフットプリントが必要で、これはおそらく全プログラミング言語の中で最大レベルなのではないでしょうか。

VMがあたたまるまで時間がかかる

私はこの数年間 AWS Lambda を使用したアプリケーション開発を中心に仕事をしていますが、AWS Lambda でも仕様上は Java は使用できるのですが、現実的には使用できない。と感じています。
これは AWS Lambda のコールドスタート時に特に体感します。コールドスタート時にはLambda を実行してから、実際に処理が動き始めるまで約7秒の時間を要します。
それに対して、Python は100ms前後です。この差によって私は開発言語を Python にせざるを得ませんでした。

しかし、多くの場合はプログラムの起動に7秒かかろうと気にならないことのほうが多いでしょうから、これはサーバレスアーキテクチャにおける特殊なニーズといえるかもしれません。

言語仕様が堅い

Java はとにかく堅い言語です。
その堅さは多くの場合にいい結果をもたらします。
たとえば、冗長なまでの型宣言ですが、他人の書いたプログラムを見る際には、どのオブジェクトにどのような値が入っているのかすぐに特定できます。

  1. public function hoge($fuga)
  2. {
  3.   $this->fizz($fuga->piyo);
  4.   return $this->buzz($fuga->piyopiyo);
  5. }

PHP にありがちなこのようなプログラムを見つけたときの絶望感は Java で味わうことはないでしょう。
$fuga は何者なのか、hoge の戻り値は何なのか? Java であればドキュメントがなくてもソースコードによって明示されています。

一方でこの堅さは悪い面にも作用します。

もっとも揶揄されるのが Getter/Setter でしょう。
Java で開発をする上で、

  1. private String hoge;
  2. public String getHoge() {
  3.   return hoge;
  4. }
  5. public void setHoge(String hoge) {
  6.   this.hoge = hoge;
  7. }

このようなコードがあちこちに現れることを許容しなければならないでしょう。

NullSafety ではない

ぬるぽ というスラングが生まれる程度に null にまつわる不具合は多いです。
Java もこれに対して抗おうとこの値はnullかもよ?という Optional 型を導入するなど努力はしています。

しかし、null が設定されうる Optional 型など何の役にも立たちません。

  1. Optional<Hoge> nullValue = null;
  2. if(nullValue.isPresent()) { // ここでぬるぽ
  3.   nullValue.get().fuga();
  4. }

Java が本当にぬるぽ問題に対して本気で取り組む姿勢を見せるのであれば、Optional でない型には null が設定できないようにしなければならなかったのでしょうが、10年前のコードでも動くJavaのバージョンに対する良さが失われる破壊的な変更になりますので、それは避けなければならなかったのでしょう。

ストリーム処理がださい

Java でもコレクションに対するストリーム処理ができるようになりました。

  1. List<String> itemNames = items.stream()
  2.   .map(Item::getName)
  3.   .collect(Collectors.toList());

以前の foreach を使った実装に比べれば100倍ましなのは事実なのですが

.stream() とか .collect() とか所々ダサいです。

前述の Optional型 によって、さらにこのストリームはだささを増します。

  1. Optional<Item> item = items.stream()
  2.   .filter(item -> item.getId() == 1000)
  3.   .first();
  4. if(item.isPresent()) {
  5.   item.get().action()
  6. }

そして Kotlin

Kotlin は JVM で動作し、Java と混ぜて使用できます。
これによって、多くの Java の資産をそのまま受け継いで使用できます。

にもかかわらず、Java のイマイチだった点を改善し、より使いやすい言語仕様にまとめあげています。

Getter/Setter

  1. class Hoge(
  2.   val fuga: Int
  3. )
  4. val hoge = Hoge(1)
  5. print(hoge.fuga)
  6. hoge.fuga = 100 // エラー: fuga は不変(val) 宣言なので書き換えられない

さらに Kotlin ではC#のプロパティメソッドのような機能も使用できます。

  1. class Hoge(
  2.   val fuga: Int
  3. ) {
  4.   val fuga2pow
  5.     get() = Math.pow(fuga.toDouble(), 2.0)
  6. }
  7. val hoge = Hoge(1)
  8. print(hoge.fuga2pow)

.toDouble() のあたりにダサさを感じざるを得ませんが、Kotlin の設計思想として暗黙の型キャストは if(variable is Class) で判定したときにしか作用しないという方針のようなので、ここは諦めるしか無さそうです。

NullSafety

Kotlin ではデフォルトではオブジェクトに null を代入できません。
つまり、プログラム側では null チェックなどせずに安心してオブジェクトを触れます。

逆に null が入っているかもしれないときは Hoge? という型で宣言することで、Hoge型だけど null がはいっているかもよ?と宣言します。

そして、Hoge のメソッドを触るときには hoge?.action() と呼び出せば、hoge がnullでなければ actionメソッドを呼びだす。という実装になり、null チェックもダサくありません。

ストリーム処理

  1. val itemNames = items.map(Item::name)

 

  1. val item = items.filter {
  2.   item -> item.id == 1000
  3. }.firstOrNull()
  4. item?.action()

Java でダサかった部分がかなり改善されて、理想的な形になっています。

ランタイムがでかい / JMがあたたまるまで時間がかかる

このあたりは JVM の問題ですので、JVMベースの Kotlin では解決できません。
しかし、Kotlin は ver1.1 で javascript をランタイムとして動作できるようになりました。
さらに Kotlin/Native というプロジェクトでは Kotlin で書かれたプログラムをネイティブコードにコンパイルする開発が進んでいます。
近い将来、組み込み開発にも Kotlin を使用できるかもしれません。

現在では開発する対象に合わせて開発言語を選定していますが、
Kotlin を使っておけばなんでもOK。となる足音を感じています。

 

すくなくとも、現時点でも Java の代わりに Kotlin を使用する。という面においてはメリットしかありません。
そのため私は第一言語としてのJavaを捨て、Kotlin に乗り換えることを決めました。

 

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング

 

 

FF14 紅蓮のリベレーター(4.x)対応 吟遊詩人スキル回し

オメガ零式が開いて早速突撃してきたんですが、平均IL317なのにいまいちDPSが出ていない…。木人を殴っても倒せない…。
なんかおかしいんじゃないか?ということで、4.0になって全体的に変わってしまったスキル回しを改めてイチから見直したので、まとめておきます。

フローチャート 

f:id:kazutomo:20170719131852p:plain 

実際にこれで木人をしばらく回しましたが、リフルジェントアローのあたりが安定しないので、エンピリアルアローで乱れ撃ちを使ったほうがいいのかも。

賢人のバラード → 軍神パイオン → 旅人のメヌエット

基本的に歌は切らしてはいけない。リキャスト80secなのでちょっと早めに切り替えても回るけれど、詩心がたまった後半は1秒でも長く使いましょう。

旅人のメヌエット

ピッチパーフェクトはなるべく詩心が3スタックするまで我慢。

 

 

トームバイト → コースティックバイト → アイアンジョー

DoTは切れるとすごくもったいないのでなるべく切らさないように頑張る。
DoTを維持する自信がない場合はサイドワインダーは連打マクロに入れないほうがいい。

ストレートショット

ストレートショットのバフはクリティカル率10%アップで、
上記歌の詩心がつく条件がDoTでのクリティカル発生なので、DoTを切らさないこととこのバフを維持することが肝となります。 

連打マクロ

連打マクロには独立したクールダウンを持つものを押し込みました。
ブラッドレッターを入れていますが、IDなどで雑魚が沸く場合はレイン・オブ・デスとタイマーが共有なので入れないほうがいいかもです。
少なくともオメガ零式一層に関してはここでも問題ないかと。

ストレートショット効果UP

ヘヴィショットでストレートショット効果UPがProcしたらストレートショットではなくリフルジェントアローを撃つ。言わなくてもわかると思うけど。
乱れ撃ちを組み合わせると三倍界王拳になるので、リキャストしてたら使う。

その他

バトルボイス

空気を読んでみんなが攻撃できるときに歌う

地神のミンネ

やべー攻撃に合わせてMTに打つ
ギミックの処理でダメージを受けるDPS/ヒーラーでも可

オメガ零式の場合はツインボルトでMTに合わせるのが良さそう。
バフをたいてて大丈夫そうな場合はミールストームに合わせてもいいかも。

パリセード

やべー攻撃に合わせてMTに打つ
ギミックの処理でダメージを受けるDPS/ヒーラーでも可

オメガ零式はどの攻撃が痛い物理かまだ見極められてないっす

トルバドゥール

どれがいいのかわかんない。コンテンツ次第な気がするけど
賢人のバラードのHP15%UPにあわせておけば間違いない気がする!

リフレッシュ

ヒーラーの状態を見て打つ
リキャスト時間が長いので、1発めは両方のヒーラーが8割切ってたらもう使ってもいいかも。

バラードと違って使った瞬間に死んでいる場合は生き返っても反映されないので
ヒーラーが蘇生を受けた場合、生き返ったのを確認してからうつ

タクティシャン

みんなのTPをみて打つ
…んだけど、4.0の調整でTPが切れることってあんまりない感じ。

 

 

最高の電源タップを見つけた

ゲームやらITやらガジェットを仕事や趣味にしてると、どうしてもパソコンや家電製品も多くなりがちで、電源周りがカオスになりますね。

かくいう私もくっちゃくちゃになってます。

くっちゃくちゃになってるのを誤魔化すべく、テレビを壁掛けにして壁の後ろでくちゃくちゃにしてる有様です。

 

で、この間ヨドバシをブラッとしてたらいい商品を見つけました。

ヤザワコーポレーションの 差し込みフリータップです。

f:id:kazutomo:20170630105531j:plain

画像を見て分かるとおり、この電源タップにはコンセントに対が設定されていません。

どこに刺しても適切に電流がながれるようです。

これで嬉しいのはACアダプター類で幅がデカくて隣に浸食するやつですね。

ほんのちょっと浸食されたことで1口コンセントが使えなくなったりします。

ところが、この製品なら0.5口失うだけで済みます!

 

調べてみると、3年近く前には商品化されてたんですね。全然知りませんでした。

私は4大人買いしてしまいました!

 

 

電源の一括オンオフ物理スイッチ付き。(こちらは7.5口) 

ケーブル長が 1.5m 2.5m とバリエーションが用意されています。

 

Yazawa 差し込みフリータップ ベーシック 1.5m ホワイト H85015WH
 
Yazawa 差し込みフリータップ ベーシック 2.5m ホワイト H85025WH
 

カラーバリエーションもあります。

 

Yazawa 差し込みフリータップ ベーシック 1.5m ブラック H85015BK
 
Yazawa 差し込みフリータップ ベーシック 2.5m ブラック H85025BK
 

 これで効率的に配線が出来そうですね。

 

作業用BGM環境を整えた話

私はリモートワークで活動していますので、BGMを聞きながら作業をすることになんの躊躇もありません。

これまで、作業用BGMを流す方法を色々と模索してきたのですが、方針をガラッと変えました。
今回はその話をしたいとおもいます。

ステップ1 - Macで音楽を流す

作業をしている MaciTunes でライブラリにある曲を流す。というのが最初のステップでした。
とはいえ、メインのマシンは Mackbook Pro 2016 のストレージを 256GB モデルですので、あまり曲を突っ込むというものではありません。

作業中にBGMをかけたいのは外出時ではなく、デスクで作業しているときでしょう。
というわけで、iTunes のライブラリ自体は NAS にライブラリを置いて使用していました。

NAS には 仮想マシンiSCSI ボリュームなどを置くのにも使用している QNAP を使用していました。 

 Mac から iSCSI ボリュームをマウントする手順に関しては Qiita でも公開しています。

qiita.com

ステップ2 - Loop for VOX

普段 BGMを聞いてると、iPhone に曲が入ってないことに苛立ちを覚え始めました。
iPhone はストレージ容量がQNAPと比べればかなり少ないですから、全曲入れるわけにはいかないからです。

最初に目をつけたのは、Loop for VOX でした。
Loop for VOX - Infinite Music Storage FLAC and HiRes 24/192 ready

Loop for VOX は VOX というミュージックプレイヤーに付属するクラウドストレージサービスで、容量無制限でFLACのような無圧縮音源でもアップロードし放題。というサービスです。
年間99.99ドルかかりますが、ピュアオーディオ界で生きている人たちにとってはFLACを容量を気にすること無く保存して、必要に応じてiPhoneにダウンロードして聞ける。というのは魅力的だとおもいます。

ですが、私はピュアオーディオ界とは縁遠く、AAC 128kbps で十分満足しています。
なので、年間99.99ドルはちょっと高いなあ。という印象でした。

ちなみに、体験期間を過ぎて課金せずに放置してたら、どんどんディスカウントオファーが届きます。
最終的に70%OFF のディスカウントオファーが来ましたので、粘れば 29.99ドルくらいで1年間使えるとおもいます。

ステップ3 - Google Play Music

Loop for VOX を諦めた私は Google Play Music にたどり着きました。

play.google.com

Google Play Music は無料プランでも5万曲までですが、自分が持っている楽曲データをアップロードしてPCからもスマホからも聞けるように出来ます。

これでいいじゃないー。と意気揚々とアップロードして聞いていました。
しばらくはこれでも満足の行く体験が続きました。

ところが、自分が持ってるライブラリだけでは毎日聞いてると飽きてきてしまいました。
そこで、目をつけたのが聴き放題系のサービスです。

ステップ4 - Spotify

当時ちょうどサービスが始まったのが Spotify でした。

www.spotify.com

Spotify にした理由は聴き放題系のサービスとしては先進的な取り組みとして、無料プランが有ることでした。

f:id:kazutomo:20170625020838p:plain

無料プランだと曲の合間に広告が入ったりするんですが、無料っていいですよね!
で、無料プランで音楽を垂れ流してて、調子がいいな。と思ってたんです。
ある時までは…。

 とまあ、罠があってですね。PC版だと毎月15時間しか使えないみたいなんですね。ちなみに、スマホアプリからだったら時間制限はないです。
で、これでは厳しいなあ。ということで、別の方法を模索し始めました。

ステップ5 - Amazon Prime Music

そうだ。私には Amazon Prime という味方がいた!
Amazon Prime Music は Amazon Prime に加入していれば、対象楽曲が聴き放題になるサービスです。

amzn.to

これでしばらく私の作業用BGM環境は安定しました。

ステップ6 - アニュータ

ごくごく最近ですが、新しい定額音楽配信サービスが始まりました。

aniuta.co.jp

アニソンに特化したサービスです。
私はこの数年アニメをかなり見ていて、アニソンもちょいちょいiTunesなどで購入していました。

一部レーベルで不足している感もありますが、かなり網羅性が高く、月額600円であれば毎月2曲購入する感覚で聴き放題サービスが使えるということで、加入することにしました。

ところが、アニュータにはPC版のクライアントがないのです。
Spotify のあたりで薄々感づいていたのですが、いまや音楽を聴く環境としてはPCよりもスマホの方が優れているのです。

というわけで、「PCで音楽を聞いて、できるだけ同じ曲をスマホに持ち出す」という発想を変えて「スマホで流した曲をPCで聞く」というスタイルにすることにしました。

スタイルの変更

スタイルを変えるにあたって、私はPCで音楽を聞く上で何を大切にしていたのか。を考え直すことにしました。

  • 普段使っているスピーカーやヘッドホンを使えること
  • 電話がかかってきたときなど、音量の調整がMacのキーボードで行えること

たったこれだけでした。

スピーカーは B&W の MM-1 を使用しています。

Bowers & Wilkins(バウアーズ&ウィルキンス)「MM-1」 MM1-B

Bowers & Wilkins(バウアーズ&ウィルキンス)「MM-1」 MM1-B

 

普段は MM-1 で流しているのですが、集中したいときにはヘッドホンに変えています。
ヘッドホンは MDR-7506 を使っています。

SONY ステレオヘッドホン MDR-7506

SONY ステレオヘッドホン MDR-7506

 

私の iPhone は iPhone7 でイヤホンジャックがありませんので、MM-1 も ヘッドホンも直接刺すにはちょっと綺麗にまとまりません。それに、Macで音量調整が出来ません。

やはり iPhoneMac の通信は無線でするべきだろう。ということで、最初に浮かんだアイデアAir Play で Mac に音楽を飛ばせないか。でした。

Air Play

Air Play は iPhone の画面を無線でテレビに映す仕組みです。
Android の Chromecast にはオーディオだけ飛ばす仕組みがありますが、Air Play はそれはないようでした。

仕方がないので、別に必要のない画面もセットにして送ることにしました。
標準ではMacAir Play を受ける手段がないようなので、フリーソフトを探したところ、Lonely Screen というアプリケーションを見つけました。

AirPlay Receiver on Windows and OSX

しかし、これが安定しないのなんの…。
音楽を流しているとしょっちゅうプチプチ音が混ざって不快極まりないです。
もしかすると、他のサーバアプリケーションだったら問題ないのかもしれませんが、
そもそも、映像を送ってる段階で無駄が多いので Air Play は諦めることにしました。

Bluetooth

やはり、餅は餅屋。音楽を聞きたいのであれば音楽を聞くのに一般的に使われている通信を使うべきでしょう。
とはいえ、これまた MacBluetooth を受けて iPhone のスピーカーになることは出来ません。
仕方がないので、Bluetoothトランスミッターを挟むことにしました。

MM-1 は Mac と USB 接続をしていて、MM-1 の LINE IN に入れた音の音量調整も Mac 側の音量調整で制御できますので、MM-1 を通しておけば iPhone の音量調整は出来ませんが、Macの音量調整をすることで、結果的に音楽の音量調整はできそうだったからです。 

そこで、こちらの Bluetooth レシーバを購入し、MM-1 の LINE IN に繋ぎました。
あとはこの Bluetooth レシーバと iPhone をペアリングして音楽を流せば MM-1 から音楽が流れるという寸法です。
これは意図したとおり動きました。

こうして、iPhone で流した音楽をMacで聞けるようになりました。
唯一不満があるとすれば、Macのキーボードで曲送りが出来ないことです。 
Bluetoothレシーバーに曲送りボタンがついていればもう少し不満は小さかったかもしれません。

参考までに。

【書評】サーバレスシングルページアプリケーション

f:id:kazutomo:20170620130505j:plain

翻訳を担当された吉田さんより献本いただきましたので、感謝の意を込めて書評を書こうと思います。

 

この本は『サーバレスアーキテクチャ』でシングルページアプリケーションを作成する手順を順を追って解説する。というものです。
懇切丁寧というよりはかなり駆け足気味に思いましたので、初学者というよりはある程度開発経験のある開発者の人が触れるべき本でしょう。

本書は全8章構成ですが、最初の3章はシングルページアプリケーションを作成する準備のような章が続きます。
AWSのサービスはhtmlファイルを配置するためにS3を利用するくらいで、あとは js 上でモデルとビューをバインディングするなど、フロント寄りの話が続きます。

正直なところ、テーマ的に避けられなかったのだと思いますが、このあたりは時流の変化も速く、フレームワークによって差が大きい部分なのでここまで細かく説明する必要なかったのでは無いか。という気もします。

4章以降はAWSに関する話題が続きます。

  • 4章 Cognito
  • 5章 DynamoDB
  • 6章 Lambda / API Gateway

Cognito はシングルページアプリケーションでユーザ認証の仕組みを使うにはどうすればいいの?という課題への対処法に徹しており、Cognito Sync のようなデータ連係周りは一切触れていません。
内容も非常にさっぱりしているので、迷うことはないと思います。

DynamoDB は Cognito から得たIAMを使って直接AWS SDKをたたいて使うスタイルで解説されています。
他人のリソースにアクセスできないようポリシーの設定手順なども解説されています。

私の個人的な意見としては、この方法は現実的に運用が難しいと思っています。
というのも、他人のリソースにアクセスすることは IAMポリシーで制限できたとしても不正な値を書き込むことを止める手段が無いためです。

 

Lambda は実行できるようにする手順を解説することに重きをおいており、ノウハウやTIPSはほぼ無いと言っていいでしょう。
たとえば、Lambda は Python, Java, node.js が使用できる(C#はどこへ…)と記述があり、本書では node.js を使用しているけれどこれは(著者にとって)最後の選択肢でしょう。と記述しているにもかかわらず、なぜそうなのか?には触れられていません。

このあたりのディープな内容について知りたければ AWSJ の西谷さんが書かれた Lambda本 のほうが実用的なノウハウが詰まっていると思います。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

 

 API Gateway は本当におまけ程度で触れられています。著者は AWS SDK で直接 Lambda を実行すればいいじゃない。というスタンスのようです。
個人的には API Gateway はリクエストデータをトランスフォームして Lambda に渡せるところに魅力を感じていますので、このあたりの解説をしてメリットデメリットを並べてないのは少し残念かな。という印象です。

 

7章 ではサーバレスアーキテクチャでセキュリティをいかに実現するか。というテーマです。
基本的にはシングルページアプリケーションに関係なく一般的なWEBサイトでも課題となることが書かれていると思います。
DynamoDB でもクエリインジェクション対策が必要。などおそらく読者が知りたいところにも触れられています。
ただ、DoS の対処方法として S3 の前段に CloudFront をおくという解説がありますが、保護するべきところは本当にそこでしょうか?という印象を受けました。
DynamoDB とか気になる部分がほかにもある気がしました。

 

8章は運用に関する内容です。
キャパシティ管理・ログ・コスト計算といった運用時に必要となる知識について一通り触れられています。
ただ、S3のログ解析に s3 sync でローカルに持ってきていますが、せっかくなので Athena を使うとか、もう少しディープな内容に出来たような気もしますし、CloudWatch にたまったログはどうすればいいんでしょう…。

 

冒頭で感謝の意といいつつ、辛口コメントが続いてしまいましたが、これ一冊で実戦投入できるほどの知識が得られるものではなく、広く浅くシングルページアプリケーションの開発で必要な部分のみつまみ食いした結果を解説した本である。という理解をした上で読めば、現状この手の本の代わりはありませんので、いい本だと思います。