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

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

• Java
• C/C++
• Python
• PHP
• javascript

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

Javaの優れている点

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

• 10年前のコードも動かせる信頼性の高いVM
• クロスプラットフォーム動作
• 豊富なライブラリ群
• 高速動作

信頼性の高い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;
3. public String getHoge() {
4. 　　return hoge;
5. }
7. public void setHoge(String hoge) {
8. 　　this.hoge = hoge;
9. }

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

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. )
5. val hoge = Hoge(1)
6. print(hoge.fuga)
7. 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. }
8. val hoge = Hoge(1)
9. 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()
5. item?.action()

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

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

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

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

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

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

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

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

フローチャート 

 

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

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

基本的に歌は切らしてはいけない。リキャスト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が切れることってあんまりない感じ。

吉田の日々赤裸々。　『ファイナルファンタジーXIV』はなぜ新生できたのか (ファミ通の攻略本)

FF14 エオカフェ エオルゼアカフェ 紅蓮のリベレーター ランチョンマット

THE FAR EDGE OF FATE: FINAL FANTASY XIV ORIGINAL SOUNDTRACK【映像付サントラ/Blu-ray Disc Music】

スクエニカフェ FF14 刺繍ポーチ でぶチョコボ

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

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

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

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

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

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

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

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

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

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

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

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

私は4個大人買いしてしまいました！

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

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

Yazawa 差し込みフリータップ ブレーカーSW付 1.5m ホワイト H75115WH

Yazawa 差し込みフリータップ ブレーカーSW付 2.5m ホワイト H75125WH

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

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

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

Yazawa 差し込みフリータップ ブレーカーSW付 1.5m ブラック H75115BK

Yazawa 差し込みフリータップ ブレーカーSW付 2.5m ブラック H75125BK

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

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

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

作業用BGM環境を整えた話

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

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

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

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

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

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

QNAP TurboNAS クアッドコア1.6GHzCPU 4GBメモリ 6ベイ 2年保証 TS-653A

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

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

うっそ。時間制限なんてあったのｗ 広告はいるのにケチくさいこというなよ！ pic.twitter.com/aX0NwKBM0u

— kazutomo (@kazutomo) 2016年10月12日

 とまあ、罠があってですね。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

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

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

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

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

Air Play

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

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

AirPlay Receiver on Windows and OSX

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

Bluetooth

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

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

AUKEY Bluetoothレシーバー オーディオレシーバー 無線受信機 3.5mmステレオミニプラグ接続 BR-C1

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

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

参考までに。

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

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

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

本書は全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 ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

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

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

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

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

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

iMac Retina 5K 27-inch 2017 が届いたよ（メモリの増設方法）

MacBookPro 2016 をメインで使い続けてきましたが、スリープから復帰しなかったり、画面が乱れたり。不安定なところがチラチラあったり、メモリを16GBにしたけど、やっぱり全然足りてない…と耐えられないのでサブ機に格下げして新しくメイン機として iMac を購入しました。

スペックはこちらです。竹モデルをベースにカスタマイズしています。
メモリが64GBになっていますが、これは Apple Store では 8GB で購入して増設しました。

というのも、Apple Store でメモリを増設すると…

プラス15万円以上もかかります！！！！

 

CFD販売 ノートPC用メモリ PC4-19200(DDR4-2400) 16GBx2枚 260pin (無期限保証)(Crucial by Micron) W4N2400CM-16G

 iMac は自分でメモリの増設が出来るので、 そこは自分で手配しましょう。

support.apple.com

最近はメモリの価格が高騰していて1年前と比べると倍近くの相場になっていますが、それでも6万円前後で64GBのメモリを確保できます。10万円近い節約になりますね。

取り付け方法ですが、後ろにいかにもな場所があります。

ここはどうやったら開くのか。ですが、下の電源アダプタを指す部分の上部にボタンがあります。
ここをドライバーなどでグッと押し込むと…。

カバーが外れます。
あとはカバー裏に書かれているようにメモリを刺します。

こんな感じです。差し込みは別に固くないので力一杯押し込む必要は無いです。
できたらふたを戻します。ここが一番苦労したかもしれません。

ちゃんと認識しているのが確認できたら成功です！

ある日の日常。

なるほど。16GBでは全然足りないわけだ。

kazutomo.hatenablog.com

こちらでレビューした UltraFine 5K Display と接続して2画面で使っています。
使えない事は無いだろうけど、Apple のサイトでは一ミリも触れられてなかったと思うので、一応使えたよ報告です。

見ての通り、5Kディスプレイ2枚は非常に広大です。
仮想デスクトップを駆使して疲弊してるのであれば、この広大なフィールドを手に入れるのおすすめです。

おわり。

MacBook Pro 2016 を非純正アダプタで充電する

MacBook Pro 2016 を持ち歩いて日々過ごしているわけですけど、
出張時などにACアダプタをいちいちカバンに移し替えてあーだこーだするのが面倒です。

純正のACアダプタをもう一個買ってもいいんですが、どうせなら iPhone とかものアダプタを持ち歩くのもやめて、まとめて充電できるものにしたいです。

MacBook は40W 電源アダプタなのですが、MacBook Pro は 60W です。
この条件を満たすアダプタというのがあまり選択肢がなく、そもそも刺していても充電されずじわじわ減っていってしまう。というようなレビューも見られます。

男は度胸。と人柱になってみました。
購入したのはこちら。 

Anker PowerPort+ 5 USB-C Power Delivery (60W 5ポート Power Delivery搭載 USB&USB-C 急速充電器) 新しいMacBook / iPhone / iPad / Android 各種他対応 A2053511

 スペック上は 60W なので要件を満たしていますし、USB-C のポートも付いています。
結論から言うと、ちゃんと充電できました。

ただ、Anker PowerPort+ は他の充電器と違ってアダプタに直接電源ソケットがついてなくて、メガネケーブルを使っての接続になります。
メガネケーブルを持ち歩くのがなんだかなー。という気持ちになったのですが、このケーブルを買ってキレイに仕上げました。

モバイル電源コード RETRACTABLE POWER CORD 1.0m (電源コード（メガネ型）, White)

 ちなみに、MacBook Pro と Anker のアダプタの間は以下のケーブルを使いました。
しっかりしたケーブルで、ヘビーな用途にも耐えられそうです。 

AUKEY USB C to USB Cケーブル 新しいMacBook Proなどに対応CB-CD5

 参考にどうぞー。