大晦日ことし買って良かったモノまとめ2018

2018年も今日で終わるので、今年買って良かったモノのまとめ。
いつ買ったかよく覚えてないものは数年前だろうがなんでも今年買ったことにします。

Philips Hue

スマートフォンや音声アシスタント、さらにIFTTTなんかからもコントロールできる電球。
色んな色を再現できる製品、というイメージが強いが、ホワイトグラデーションというのもあって コイツなら日常的に使いそうな色味だけになる代わり安い。実際使ってるのもこのくらいなので十分。

Philips Hue (ヒュー) ホワイトグラデーション シングルランプ スマート LEDライト【Amazon Echo、Google Home、Apple HomeKit、LINE対応】

使っているのは、リビング, 浴室, 洗面所。
いちおうリビング用にはスタンダードな方を使っている。ゲームや動画, 音楽にあわせて自動で色を変えたりできるので面白い。

Philips Hue(ヒュー) シングルランプv3 スマートLEDライト 【Amazon Echo、Google Home、Apple HomeKit、LINE対応】

朝起床時に徐々に照明を明るくできるとか、時間帯によって色味を変えて目の疲れを抑えるとかが便利。
また洗面所でメイクする時は 色味をコロコロ変えたりして試せるので、めちゃくちゃ顔を作りやすくなった。

何よりいちばん助けられてるのは、やっぱ電気の消し忘れが減ったことかな...

初めて設置する場合は、Bridgeの購入をお忘れなく。

Philips Hue(ヒュー) ブリッジ 929001180614

ちなみにスタンドはコレ使ってます

アッパーフロアスタンド ブラック E26 YN10AW TF-YN10AW

Qrio Lock

スマートロック製品。
いつも「鍵ちゃんと締めたっけ？」と気になりはじめると一日ストレス続きでつらかったのだけど、気になるならアプリ開けばいい、という状態になったのが精神衛生上たいへん良い。
あとは宅配ボックスの荷物を出してきた時、カギ出す必要がなくなってスムーズになったのとか。

この手のスマートロック製品の中でも特にアプリのクオリティが高いのもポイント。他のある製品はちょっと不満があった。

Qrio Lock (キュリオロック) スマホで自宅カギを解施錠できるスマートロック Q-SL2

ウチはよく帰宅難民の受け入れをしていて、その時に帰るタイミングが全く違っていても「とりあえず合鍵の権限付与」で済むようになったのも楽。鍵自体を渡すのは紛失時が怖いからね。

外出先から使いたい場合は、Qrio Hubの購入をお忘れなく。

Qrio Hub 自宅の鍵を遠隔操作 鍵の閉め忘れ防止にも 外出中でも鍵の開閉をスマホに通知(Qrio Lock, Qrio Smart Lock拡張デバイス) Q-H1

Switch Bot

スマートフォンやREST APIから物理ボタンを代わりに押してくれる製品。
前述の「帰ってくるタイミングがわからない」という問題があった時、ここにリクエストを投げてもらってオートロックを解錠している。

Switch Bot｜ワイヤレスでご家庭に機器のオンオフ操作可能なリモートロボット「スイッチボット」

外出先から使いたい場合は、Switch Linkの購入をお忘れなく。

Switch Link｜家の外からワイヤレスでご家庭に機器のオンオフ操作可能なリモートロボット「スイッチリンク」

Slack Standard

個人で使ってるSlackのプランをStandardへ上げました。
フィードの購読だったり各種通知で使っていたのだけど、これが古いものまで遡れるようになった。

何より良かったのは、シングルチャネルゲストが使えるようになったこと。前述の帰宅難民受け入れ時なんかに、各種家電のコントロールをSlackコマンド経由へ集約しておくと楽チン。アプリごとの権限管理が不要になるし、Audit Logのように誰が何をやったか後からでも確認できる。

Zapier Starter Plan

IFTTTの代替として、ZapierをStarter Planへ上げました。
より高度なタスクをコード不要で作れるので、とりあえずサクッと何か実現するためには手放せない。

4Kモニタ (テレビではない)

先日のAmazonサイバーマンデーセールで3万円台で買えるようになっていて、気絶して起きたら何故か注文済だった。

I-O DATA モニター ディスプレイ 43型 EX-LD4K431DB (4K/60Hz/DisplayPort搭載/リモコン付/3年保証/土日もサポート)

前提として独立したテレビ用STB (後述) を既に持っていて、チューナ一体型の液晶テレビは不要だった。
4Kコンテンツを鑑賞してるかというと全然そんなことはないけれど、すこし距離を取って映像を見る際にはやっぱある程度デカイモニタじゃないと文字とか見づらかった。だいぶストレス減りました。

Android TV搭載STB

チューナ内蔵なので、チューナ一体型の液晶テレビとかがいらない。今持ってるPC用モニタがそのまま流用できる。
4K出力やBS/CSの4K放送にも対応している（活用はしてない）。ついこのあいだのアップデートで録画も可能になった。

ピクセラ 4K Smart Tuner Andoroid TV搭載 チューナー Amazon Echo、Google Home対応 【日本正規代理店品】PIX-SMB400

Android TVという性質上そこそこhackableなのがポイント。自前でアプリ作って食わせられる。
またインターネット上のコンテンツを鑑賞する時にわざわざモニタの入力切替をせずとも、シームレスに変えられるのがとても良い。操作の学習コストが下がったり、機器管理の手間が減った。

電気ケトル

ひとり暮らしなので電気ポットだと量が多くて使い切れなかったり、猫舌の自分では沸騰直後だとあつくて使えなかったり。
電気ケトルを使い始めて、必要な時に必要な量だけ必要な温度でお湯が作れるようになった。何より早い。

ティファール 電気ケトル 0.8L アプレシア エージー・プラス コントロール オニキスブラック KO3208JP

お掃除もかなりラクなので、必要十分なものを使うのは大事。

チョコラBB

明らかに調子が良い。

エーザイ チョコラBB ハイパー 50ml×3本 (医薬部外品)

ESP32系開発ボード

良い暇つぶしになるし、勉強にもなるし、ちょっとした家庭用の自動化ツールにも便利。趣味なら安いコピー品で十分。

HiLetgo ESP32 ESP-32S NodeMCU開発ボード2.4GHz WiFi + Bluetoothデュアルモード

ロング用ウィッグスタンド

いままで通常サイズのウィッグスタンドを使っていて、毛先が床に着いちゃう問題で悩んでいた。もっと早く買えばよかった。

（超長）ウィッグスタンド ロングウィッグスタンド 帽子スタンド ウィッグ乾燥用 カビにくい 安定性よい 軽量 組み立て式 ２個入り

Qrio Smart Tag

MAMORIOもいいんだけど、こっちの方が多機能で確実に通知を送ってくれている印象。

Qrio Smart Tag(キュリオスマートタグ) ネイビー 探し物発見機 忘れ物防止 スマホも探せる キーファインダー スマホカメラのシャッター機能付き Q-ST1

VLAN対応スイッチングハブ

仕事で納品したのみだけど。硬質感といい重量感といい、大変素晴らしい。

NETGEAR スイッチングハブ ギガビット 5ポート 金属シャーシ VLAN QoS IGMP 日本語GUI 外部電源 ファンレス静音設計 省エネ 無償永久保証 GS105E-200JPS

ポケットモンスター Let's Go! イーブイ

イーブイがかわいいので。

ポケットモンスター Let's Go! イーブイ- Switch

配信の時は AVerMediaくん つかってます。

Switch用Proコントローラ

Joy-Conのストレスから開放された。

Nintendo Switch Proコントローラー

総評

まあまあ経済回した。

今すぐシュッとグローバルIPを取るsnippet in Kotlin + Android

雑だけど、社内用のデバッグアプリ (画面) ならこんなもんでいいと思います

findViewById<TextView>(R.id.your_ip_text_view).apply {
    Thread {
        URL("https://api.ipify.org")
                .openConnection()
                .apply { connect() }
                .getInputStream()
                .bufferedReader()
                .use { it.readText() }
                .let {
                    runOnUiThread {
                        text = it
                    }
                }
    }.start()
}

いろんな `java -version` 表示

必要になったんだけど、いろいろありすぎて困ったのでメモ。ちなみにDocker内でやった。

TL;DR

• semverじゃないのは常識
• 実行方法次第では必ずしも3行ではない
• バージョン表記は3セグメントとも限らず、4セグだったり1セグだったりもする
• underscoreが入ったりhyphenが入ったりいろいろある
• バージョン表記のquotesより後に日付が入るパターンもある

OpenJDK

6

java version "1.6.0_38"
OpenJDK Runtime Environment (IcedTea6 1.13.10) (6b38-1.13.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

7

java version "1.7.0_181"
OpenJDK Runtime Environment (IcedTea 2.6.14) (7u181-2.6.14-1~deb8u1)
OpenJDK 64-Bit Server VM (build 24.181-b01, mixed mode)

8

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

9

openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode)

10

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Debian-2)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Debian-2, mixed mode)

11

openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Debian-2)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Debian-2, mixed mode, sharing)

12

openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+19)
OpenJDK 64-Bit Server VM (build 12-ea+19, mixed mode, sharing)

Oracle JDK

7

java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

8

java version "1.8.0_192"
Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)

9

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

10

java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

AdoptOpenJDK

8

Picked up JAVA_TOOL_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_192-b12)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.192-b12, mixed mode)

9

Picked up JAVA_TOOL_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)

10

Picked up JAVA_TOOL_OPTIONS: -XX:+UseContainerSupport
openjdk version "10.0.2-adoptopenjdk" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2-adoptopenjdk+13)
OpenJDK 64-Bit Server VM (build 10.0.2-adoptopenjdk+13, mixed mode)

11

Picked up JAVA_TOOL_OPTIONS: -XX:+UseContainerSupport
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.1+13, mixed mode)

Zulu

6

openjdk version "1.6.0-119"
OpenJDK Runtime Environment (Zulu 6.22.0.3-linux64) (build 1.6.0-119-b119)
OpenJDK 64-Bit Server VM (Zulu 6.22.0.3-linux64) (build 23.77-b119, mixed mode)

7

openjdk version "1.7.0_201"
OpenJDK Runtime Environment (Zulu 7.25.0.5-linux64) (build 1.7.0_201-b02)
OpenJDK 64-Bit Server VM (Zulu 7.25.0.5-linux64) (build 24.201-b02, mixed mode)

8

openjdk version "1.8.0_192"
OpenJDK Runtime Environment (Zulu 8.33.0.1-linux64) (build 1.8.0_192-b01)
OpenJDK 64-Bit Server VM (Zulu 8.33.0.1-linux64) (build 25.192-b01, mixed mode)

9

openjdk version "9.0.7.1"
OpenJDK Runtime Environment (Zulu build 9.0.7.1+1)
OpenJDK 64-Bit Server VM (Zulu build 9.0.7.1+1, mixed mode)

10

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment Zulu10.3+5 (build 10.0.2+13)
OpenJDK 64-Bit Server VM Zulu10.3+5 (build 10.0.2+13, mixed mode)

11

openjdk version "11.0.1" 2018-10-16 LTS
OpenJDK Runtime Environment Zulu11.2+3 (build 11.0.1+13-LTS)
OpenJDK 64-Bit Server VM Zulu11.2+3 (build 11.0.1+13-LTS, mixed mode)

Amazon Corretto

8

openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-amazon-corretto-preview-b12)
OpenJDK 64-Bit Server VM (build 25.192-b12, mixed mode)

Android TV搭載チューナ内蔵STB「PIX-SMB400」のハマりどころなど

待ちに待ったピクセラのAndroid TV搭載STB「PIX-SMB400」が発売された。
これの特徴は、国内のAndroid TVでは珍しく 地上波 / BS / CS のチューナーが搭載されており、また4K出力や4K放送にも対応している。
従来のAndroid TVでチューナが搭載されているものの多くは液晶テレビと一緒になっていたため、テレビごと買い替えが必要だった中これは嬉しい。

ピクセラ 4K Smart Tuner Andoroid TV搭載 チューナー Googleアシスタント対応 【日本正規代理店品】 PIX-SMB400

いろいろハマりどころや注意すべきことがあったので、これから購入を検討される方向けにメモ。

アンテナケーブルが付属してない

箱の中にアンテナケーブルが入っていない。これはおそらく、この製品が「既存のテレビを置き換える」という用途を想定しているからと思われる。
もし未だテレビを利用したことがない場合、一緒にアンテナケーブルを買っておく必要がある。

私は以下2つを買って組み合わせ使っている。

エレコム アンテナケーブル F型端子 L-ストレート型 1m 2.5C スリムタイプ 地デジ/BS/CS対応 金メッキピン ブラック AV-ATLS10BK

HORIC アンテナ分波器 BS/CS/地デジ対応 白ケーブル2本付き(S-4C-FB) 40cm BCUV-971

LANケーブルが付属していない

同上。

iBUFFALO ツメの折れないLANケーブル UTP Cat6a ストレート フラットタイプ 1m ブラック BSLS6AFU10BK

リモコンはBluetooth接続

これはAndroid TV全般に言えることだが、赤外線ではないので注意。Nature Remoなどでリモートコントロールはできない。

電源投入時に自動でテレビが点く

一般的なAndroid TV端末は電源投入時はLauncherが表示されるが、この製品は前回点けていたテレビのチャンネルが自動で点く。
なお、スリープからの復帰時は通常通り前回のアプリ / 画面。

テレビの表示がLive Channelsではなく独自アプリ

これは国内の多くのAndorid TVが該当するが、放送の視聴はLive Channelsからではなく、搭載されている独自アプリから行う。

おそらくこのアプリとほぼ同等だが、外付けではなく内蔵チューナ用にカスタマイズされていたりとパッケージ自体は異なる模様？

スマートスピーカー連携の設定動線が一方のみ使えない

多分これは現行ファームウェア (Build OPR6.170623.013, Revision 4.4.1538216619) の不具合。

設定 → デジタル放送 → カスタム設定 → スマートスピーカー連携 の動線から設定しようとすると、途中永遠にプログレスになってしまい進まない。
TVアプリ → メニュー → 設定 → カスタム設定 → スマートスピーカー連携 から進めると、正常にログイン画面が表示される。

外部Google Assistantから「画面消して」ができない

まず前提知識として、PIX-SMB400はAndroid TV製品では珍しくスリープ（ケータイで言うなら画面ロック）機能がある。
これは大変便利で、たとえば多くのモニタには省電力機能が搭載されているため、HDMIから信号が途切れた時点でモニタのバックライトが消灯したりする。すなわち、PIX-SMB400側をスリープさせるだけであたかもモニタ自体の電源が落ちたかのような挙動を実現することができる。

PIX-SMB400上のGoogle Assistantに対し「画面消して」と言うと、画面を消す（スリープさせる）ことができる。
が、Google Home等に対し「(設定したデバイス名) の画面消して」などと言っても画面を消すことはできない。

ただし、ピクセラ製テレビのスマートスピーカーアプリを経由しようと「ピクセラテレビに繋いで」から「テレビを消して」とした場合、TVアプリを終了させる (= Launcherを表示する) ことはできる。画面をスリープにさせることはできない。

Amazon Prime Videoが観れない

これもAndroid TV製品全般に言えることだが、Amazon Prime Videoアプリが利用できない。

まれにリモコンが音声を認識しなくなる

これはリモコン側の電池を抜いて再度入れるとよい

外部端末からCastを受け付けなくなる

PIX-SMB400のChromecastへCastしようとしても、昨日までは動いたのに今日はなんか上手くいかない
スマートフォン等から手動でCastは上手くいく。が、Google HomeやスマホのGoogle AssistantアプリでCastを指示すると何も通らない。
もっと言うと、PIX-SMB400自身のGoogle Assistantが無反応なってる。

— SDKエンジニア手習い (@shuma_yoshioka) October 5, 2018

設定メニュー内のストレージとリセット → データの初期化を行ったが解決しなかった。
が、試しに本体裏側の初期化スイッチからリセットを試みたところ、上手く動作するようになった。なんだろう。

Google AssistantからCast中に「音量上げて」というと音量が下がる

これがかなり致命的な不具合。Google Home等の端末から「テレビでSpotify再生して」などと伝えてCastをしているとき、「音量上げて」と言うと音量が下がってしまう問題がある。なお、音量下げてというと正常に音が小さくなる。

定期的に放送が止まる

解決方法を調査中

所感

とりあえず購入後23時間程で気付いた点について書いた。全体としては満足度の高い商品なのだが、いかんせんFire TVをメインで利用した後ではコンテンツに乏しく感じてしまう。
他なにか気付いた点があれば追って記事を出したい。

高田馬場でコオロギを食べた

連日の40度にも達するかという気候の中では、今日はずいぶん涼しい。
都庁を間近で眺めるのは初めてで、試しに写真を撮ってみたものの、どうもこの曇り空ではうすぼんやりとした印象になってしまい、結局Twitterでシェアすることもなかった。

先週、高校時代からの友人より久々に連絡があった。彼女が連絡を寄越す時は、大概パートナーと喧嘩しただとかそういう時だ。
飲みに行こうと、彼女が提案したのはミャンマー料理専門店だった。

ミャンマー料理には馴染みが無い。どんな料理か想像が付かない。そしてどうもその店は昆虫料理を出すらしい。
虫は大の苦手なのだが、何度かためらいのメッセージをやり取りした後、興味のほうが勝った私は承諾した。

待ち合わせは夜。翌月に講師の案件が迫っていたので、日中に取引先との打ち合わせを入れる。なんでも先方が準備するはずだった資料が上がっていないらしく、当日までに準備できないかという相談だった。まあ、これが無ければ講義もままならないし、特急料金で発注頂けるのなら。

---

18時。遅れると言いつつ時間丁度にやってきた彼女は、最後に会った時から比べてずいぶんとほっそりしていた。ショートカット、ノースリーブ、薄塗りのファンデーション。いつの間にか大人びた彼女に対し、金だけ払ってジムへも通っていない小太りの自分が連れ立って歩く様子は滑稽だっただろう。

高田馬場駅からほど近い、ノングインレイという店。いつも見えるビルの1階に、こんな店があるとは。

店に入ると、白髪のおじいさんが客席に座って何か作業をしている。女性スタッフがたどたどしい日本語で人数を聞く。
2人と答えると、奥から出てきたスタッフや手前のおじいさんが矢継ぎ早に奥の席へと言う。後に調べたところ、このおじいさんはオーナーなのだという。

くすんだ緑色の内装に、壁際にテーブルが置いてある。下町の小さな食堂といったところだ。
店の中央が壁で遮られているが、カウンターキッチンでもあったのだろうか。

---

お目当ての昆虫料理はメニューの後半にあった。エキゾチックゾーンと銘打たれた料理たちは、当然ながら見慣れないものたち。
写真のとおり、小さめに掲載されているためディテールまではわからないが、それでも十分にインパクトがある。

やばい pic.twitter.com/9OcEJ4Lija

— 💥💥💥🍣💥💥💥 (@shuma_yoshioka) July 27, 2018

"いちばん食べやすいかも" という文句から「竹蟲」を選んだが、聞くと今日は無いという。この店のメニューは原則として入荷時のみの提供となり、この日は「竹蟲」と「セミの炒め」は無いのだそう。話ではこの2つとも食べやすいと聞いていたため、出鼻をくじかれた思いだ。
彼女は家でカエルを飼っている。そのためカエル肉は選びづらい。また、サナギは独特の食感がして上級者向けだと聞く。入門以前の私には厳しい。

最終的なオーダーはこうだ:

• コオロギの炒め
• お肉とお米の皮なしソーセージ (豚)
• ピータンのサラダ (正式な名称は失念)

なお、最初 皮なしソーセージ をオーダーしたところ、「今日は牛しかない」と言葉の足りない日本語で数分掛けて伝えられた。仕方なく牛を注文したのだが、何故か実際に提供されたのは豚だった。

---

さて、肝心のコオロギは明らかにメニューを上回るビジュアルだった。

コオロギを食べています pic.twitter.com/J58zjGOeTB

— 💥💥💥🍣💥💥💥 (@shuma_yoshioka) July 27, 2018

彼女曰く、コオロギにも複数の種類があるらしい。普段ペットに与えているものはもう少し小さいと言う。
この店は食料品の輸入も行っているらしい。これは所謂 "本場" のコオロギなのだろうか。

勢いよく頬張って戻しても良くないため、まずは片脚から頂く。
あれ、意外といける。もう片脚。案外薄味だ。

どこか懐かしさを感じる。間違いなく初めて食べるのに、以前食べたことがあるかのような感覚になる。
これは、サクラエビだ。パリッとした殻と、中身は空洞。味に至ってはそのもの。
触覚も食べてみる。うん、素揚げしたエビの触覚となんら変わらない。

問題は腹の部分だが、ここも案外普通である。
イメージするとしたら、蒸した葉が詰まっている感じだろうか。とは言っても臭みがあるわけでもない。食感だけである。
独特ではあるが、食べたことのない感覚ではない。

とはいえ、このビジュアルだ。味も食感も食べ慣れているとはいえ、今自分が食べているものを想像すると、一瞬えずきそうになる。
人は見た目やイメージに支配されているのだなと改めて感じる。そういう時は、飲み物で流し込む。ミャンマーのドリンクを一緒にオーダーしておいてよかった。
多分、内容を知らされず、目隠しでもさせられていれば、特段の違和感なく食べてしまうだろう。

皮なしソーセージ、これも美味しい。おそらく掛けてあるのは唐辛子の酢漬けか何かだろう。
私はすこぶる辛いものが苦手だ。ライスが欲しくなる。

ピータンの乗ったサラダだが、これは日本の食卓でも日常的に並ぶ味だと思う。ピータンこそ日常的には食べないが、鶏卵のゆで卵さえ使えば同様の具材でサラダを作ることもあるだろう。
ところでピータンの寒天のような側面には、結晶に似た柄がある。どんな反応でこうなるのだろう。

水を頼むと、琥珀色のお茶が提供される。バニラのような甘い風味があり、美味しい。なんて言うのだろう。もしなら家で飲みたい。

彼女のSNSアカウントから拝借した。

---

3品を食べ終え、腹ごなしに暗くなった高田馬場を散策する。神田川あたりを歩くだけでも、複数のミャンマー料理店を見かける。なんでも高田馬場は「リトルヤンゴン」と呼ばれるほどの大きなミャンマー人コミュニティが形成されているらしい。

30分ほど歩き、駅前まで戻り安いチェーンの居酒屋へ入る。さきほどまでの異国情緒とはうって変わって、疲れた日本人サラリーマンがスマホ片手に酒を飲んだり、スーツを着た仕事仲間と下世話な話で騒いでいる。そういえば、今日はプレミアムフライデーか。

とりあえずビール、というわけでもなく、互いに好きな酒を好きなように注文する。腹が空いているわけでもないので、簡単なナゲットだけ2人でつつき合う。何の変哲もない、スッと箸がのびる味。

世間話、共通の友人の話、アイドルの話、パートナーの話、仕事の話、2人きりだからできるオフレコの話。
最近「LGBTカップルには生産性が無い」なんて話がバズっていたが、大した金額を落とすわけでもなく長時間居座って、これこそ生産性が無いよなぁなんて考えていた。とはいえ、私は代わり映えのしないなんとなく過ぎる時間が好きだ。

彼女は化粧直しで席を立つ。偉いなぁ。学生の頃こそ化粧直しに手間を掛ける時もあったが、最近はめっきりやらなくなった。小鼻の溝が皮脂で浮いてようが、誰も気にしないだろうとパウダーをはたき直すこともなくなった。こんなんだからダメなんだろうなぁ。
自炊もしない私に、彼女がクックパッドからオススメのレシピを選んで送ってくれる。日常的に料理でもしてないと、こういった行動はできないだろう。

---

「そろそろ出ようか」といって、店を出る。2人で3,000円も飲まなかった。
せっかく高田馬場に居ても、この時間では拝島行きの西武線も出ていない。新宿まで行って、中央線で帰るか。

「なんだか名残惜しいな」なんて言われても、気の利いたアクションが取れない。互いに反対方向の山手線へ乗って、別れた。

この時間に新宿に居ると、高校生最後のクリスマスや社会人1年目の時を思い出して、虚しくなる。最後にはいつも1人になることが寂しい。

水分を失い張り付いたカラコンに忌々しさを感じながら、いっそ今日も新宿で泊まって帰ろうかなどと考えていた。

「基礎から学ぶ Vue.js」の読書感想文

急に片手間で知識が必要になったものの、プラグインとかも開発してるくせに実際のアプリケーション開発レベルの知識が皆無だったので、C&R研究所より出版されている基礎から学ぶ Vue.js (著: mio氏)を読んだ。表紙がかわいい。

基礎から学ぶ Vue.js

以下、読書感想文です。

読むとよさそうな人

• Vue.jsやほかフロントエンドフレームワークを雰囲気で使っている
• とりあえず今選んどけば安泰なフレームワークを知りたい
• なんかVue.jsつらい
• 猫がすき

向いてる用途

• 業務でVue.jsを使うために手早く全体的な知識を注入する
• 一般的な用途とそれに対応するコード片やアイデアを集める
• Vue.jsで何ができるのか知る

できるようになること

• 業務でとりあえずVue.js入れる
• 簡単なアプリを書けるようになる (に相当する機能を網羅できる)

読めない人 (前提知識)

• webpackなどを用いたモダンな開発現場の基礎を知らない人
• フレームワークの発想がわからない人
• HTML / CSS / JavaScriptを業務レベルに書けない人 (ES2015を網羅するまでは不要)

できないこと / 身につかないこと / 向いてない用途

• Vue.jsで高度なアプリケーションを書くためのハマりどころを知る
• Nuxt.jsの使い方を知る (基礎は知れるので十分だけどね)
• Vue.jsのソースコードを読めるようになる、具体的な仕組みを知る
• webpack等プロジェクトに必要な設定を組めるようになる
• TypeScriptで利用する
• Web APIの利用方法など、ビジネスロジックの作り方を知る

感想

期待以上の大変よい本だった。

本自体は終始「Vue.jsの機能をサンプルコードと一緒に紹介」というチュートリアル的な形式だが、ところどころに実際の運用にあたってのアドバイスが挿入されていたり、たとえば序盤でVue.jsのライフサイクルが紹介されていたり、各項目で関連するメソッド等APIが必ず含まれるなど、これから実際に使いはじめ、後々「こうすればよかったのに」という手戻りや後悔が無いよう配慮されていると感じた。

Vuex, Vue Routerの機能紹介も含まれており、この本一冊でアプリを作ることが十分に可能だと感じた。

一方、プロジェクトの構築がVue CLIへ完全にお任せだったりと、セットアップに関する面が手薄い。
またWeb APIの具体的な利用方法がほぼ書かれない (axiosの存在がさらっと話されて当たり前にサンプルコードに出る) など、ビジネスロジックレベルの話はほぼ無い。
これらから、おそらくある程度モダンなWebフロントエンド開発経験が既にあり、新たにVue.jsの導入を検討している開発者を想定している書籍だと感じた。

もし現場の既存システムへVue.jsの導入を検討しているなら、まずは手に取ると良いかも知れない。
集中さえできるなら、5時間もあれば優に読み切れる軽い本だ。

ちなみに、同時に Hello!! Vue.js 最新プログレッシブフレームワーク入門 (著: 那須 理也氏) を買った。重複する部分が大半な中で細かい部分を補い合えるだろう、という想定。次回はこれ。

とりあえずサクッとAndroid JetPack の Navigation Architecture Component を使ってみる

Navigation Architecture Component、使ったらいろいろ楽になった

— 心理的安全性がほしい (@shuma_yoshioka) May 13, 2018

---

いままでのAndroid開発では、たとえばディープリンクにはGradleからAndroidManifestを書き換える黒魔術を、たとえばルーティングやナビゲーションにはオレオレフレームワークもどきを作って使ってきましたが、Google I/O 2018で発表された Navigation Architecture Component を使うと大変便利でした。
とりあえず使ってみたメモです。

考え方とか構造

• シングルアクティビティ・マルチフラグメント
• 最上位の (唯一の) ActivityがToolbarや ナビゲーション用コントロール(BottomNavigation, NavigationDrawer など) を持つ
• ActivityがNavHostFragmentというのを持ち、そのさらに入れ子でアプリケーションドメインのFragmentが管理・表示される
• NavHostFragmentが内包するNavControllerというやつがルーティングをしている
  • Fragmentのinstantiateなどはこれが内部でやってくれる
• ナビゲーション定義はXMLで行い、どのアクションをするかはR.id.*で指示する
• ディープリンクも同上。権威Activityがすべて受け取り、NavControllerがよしなにルーティングする
  • を実現するために、navigationのxmlをManifest Mergerがパースし、intent-filterを書き換える

作る順序のコツ

各コンポーネントが複雑に絡み合っているので、ゼロから作っていく時は順序にコツがある気がしました。
私の所感としては、

1. Gradleに依存書く
2. 内包されるFragmentクラスと各レイアウト
3. res/navigation/*.xmlの定義
4. Activityを作る
5. Fragmentのインタラクションを繋ぎこむ

がスムーズです。

使ってみる

使ってみる。とりあえず「入力された文字をそのまま表示するアプリ」を目指します。

Gradleに依存書く

プロジェクトルートのbuild.gradleへ以下のように書きます。

buildscript {
...
    ext.navigation_architecture_component_version = '1.0.0-alpha01'
...

同ファイルのdependenciesへ以下を追加します。

buildscript {
    ...
    dependencies {
        ...
        classpath "android.arch.navigation:navigation-safe-args-gradle-plugin:${navigation_architecture_component_version}"
        ...

アプリケーションモジュールのbuild.gradle冒頭に以下プラグインを追加します。

...
apply plugin: 'androidx.navigation.safeargs'
...

同じファイルに依存するライブラリを追加します。

dependencies {
...
    implementation "android.arch.navigation:navigation-fragment:${navigation_architecture_component_version}"
    implementation "android.arch.navigation:navigation-ui:${navigation_architecture_component_version}"
...

本質から外れるけれどRelativeLayoutはdon't useでuse ConstraintLayoutらしいので、このサンプルアプリではConstraintLayoutの依存も加えます。

...
    implementation 'com.android.support.constraint:constraint-layout:1.1.0'
...

内包されるFragmentを作る

このサンプルアプリでは以下の画面を作ろうかな、

• タイトル画面
• 文字入力画面
• 結果画面 (そのまま文字が表示される)
• バージョン情報画面

これらは一般的なAndroidアプリケーション開発となんら違いが無いので、詳細な解説は飛ばします。
また、画面遷移に関わるボタンクリック時のインタラクション等はこの時点では実装しません。要は、

package jp.s64.android.prototype.myechoapplication

import android.os.Bundle
import android.support.v4.app.Fragment
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup

class *Fragment : Fragment() {

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        return inflater.inflate(R.layout.*_fragment, container, false)
    }

}

程度の記述のみです。

TitleFragment	InputFragment

ResultFragment	AboutFragment

Google I/Oのサンプルを見る限り、命名規則が従来のfragment_*.xmlやlayout_*.xmlではなく*_fragment.xmlとなっている方がこれからはイケてるみたい。

res/navigation/*.xmlの定義

キモです。resディレクトリでnavigationというディレクトリを作成し、その中に任意の名前のxmlを記述します。私の場合、app_navigation.xmlとしました。
ナビゲーションの対象とするFragmentをひととおり記述します。

<navigation ... >
...
    <fragment
        android:id="@+id/launcher_title"
        android:name="jp.s64.android.prototype.myechoapplication.TitleFragment"
        android:label="@string/title"
        tools:layout="@layout/title_fragment" />

    <fragment
        android:id="@+id/flow_input"
        android:name="jp.s64.android.prototype.myechoapplication.InputFragment"
        android:label="@string/input"
        tools:layout="@layout/input_fragment" />

    <fragment
        android:id="@+id/flow_result"
        android:name="jp.s64.android.prototype.myechoapplication.ResultFragment"
        android:label="@string/result"
        tools:layout="@layout/result_fragment" />

    <fragment
        android:id="@+id/screen_about"
        android:name="jp.s64.android.prototype.myechoapplication.AboutFragment"
        android:label="@string/about"
        tools:layout="@layout/about_fragment" />
...

各要素のandroid:idは遷移先として指定されるものなので、たとえば起動時の画面ならlauncher_*などとするのが良いです。
Aboutが操作フローから独立した画面なので暫定的にscreen_*としましたが、はたして命名のベストプラクティスはなんでしょうか...
android:labelには文字列またはstringリソースが使えます。これはToolbarに表示されるtitleです。

次にルート要素に起動時の初期画面を指定します。

<navigation
    ....
    app:startDestination="@id/launcher_title">
...

TitleからInputへ遷移できるようにします。@+id/launcher_titleのfragment要素内にactionを追加します。

<fragment
        android:id="@+id/launcher_title"
        ... >
    <action
        android:id="@+id/action_launcher_title_to_flow_input"
        app:destination="@id/flow_input" />
</fragment>

同様に、InputFragmentからResultFragmentへ遷移できるようにactionを記述します。

<fragment
        android:id="@+id/flow_input"
        ... >
    <action
        android:id="@+id/action_flow_input_to_flow_result"
        app:destination="@id/flow_result" />
</fragment>

ResultFragmentが入力された文字を受け取れるように、argumentを定義します。

<fragment
    android:id="@+id/flow_result"
    ... >
    <argument
        android:name="input_text"
        android:defaultValue="No Input!"
        app:type="string" />
</fragment>

Activityを作る

MainActivityとでもして作成します。レイアウトは例えば以下のようになります。

<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivityActivity">

    <android.support.design.widget.BottomNavigationView
        android:id="@+id/bottomNavigation"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:menu="@menu/menu_bottom_navigation" />

    <fragment
        android:id="@+id/navHost"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="match_parent"
        android:layout_height="0dp"
        app:defaultNavHost="true"
        app:layout_constraintBottom_toTopOf="@+id/bottomNavigation"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:navGraph="@navigation/app_navigation" />

</android.support.constraint.ConstraintLayout>

ポイントはNavHostFragmentが画面全体を覆っていることと、app:navGraphでさきほどのxmlを指定していること。
BottomNavigationViewまたは (DrawerLayoutで包んだ) NavigationView を使うと、app:menuで指定したメニューからよしなに遷移をしてくれます。

今回つくったres/menu/menu_bottom_navigation.xmlの内容です。

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">

    <item
        android:id="@id/launcher_title"
        android:icon="@drawable/ic_home"
        android:title="@string/title"/>

    <item
        android:id="@id/screen_about"
        android:icon="@drawable/ic_info"
        android:title="@string/about"/>

</menu>

こちらのポイントはandroid:idに指定している内容がapp_navigation.xmlの各fragmentのものであること。ここに指定したものを呼び出してくれます。

Activityのコードを書いていきます。以下のようになりました。

package jp.s64.android.prototype.myechoapplication

import android.support.v7.app.AppCompatActivity
import android.os.Bundle
import android.support.design.widget.BottomNavigationView
import androidx.navigation.fragment.NavHostFragment
import androidx.navigation.ui.NavigationUI

class MainActivity : AppCompatActivity() {

    lateinit var navHost: NavHostFragment

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main_activity)

        navHost = supportFragmentManager
                .findFragmentById(R.id.navHost) as NavHostFragment

        val bottomNavigation = findViewById<BottomNavigationView>(R.id.bottomNavigation)

        NavigationUI.setupActionBarWithNavController(this, navHost.navController)
        NavigationUI.setupWithNavController(bottomNavigation, navHost.navController)
    }

    /*
    override fun onOptionsItemSelected(item: MenuItem): Boolean {
        return NavigationUI.onNavDestinationSelected(item, navHost.navController) || super.onOptionsItemSelected(item)
    }
    */

    override fun onSupportNavigateUp(): Boolean {
        return navHost.navController.navigateUp() || super.onSupportNavigateUp()
        //return NavigationUI.navigateUp(drawer, navHost.navController) || super.onSupportNavigateUp()
    }

}

NavigationUI.setupActionBarWithNavControllerでタイトルなどActionBarを、NavigationUI.setupWithNavControllerでBottomNavigationViewのクリックイベント等をNavHostFragmentの内包するNavControllerと繋ぎ込みます。
onOptionsItemSelectedはActionBarのmenuから直接遷移させる時用の記述です。必要に応じてコメントアウトしてください。
onSupportNavigateUpはActionBarでupした際に画面スタックをpopさせるために必要です。また、Drawerを利用する場合はコメントアウトしてあるような記述を用いることで可能です。

Fragmentのインタラクションを繋ぎ込む

各画面のボタンクリック等を繋ぎます。
TitleFragmentは単に以下のような記述を追加すれば十分です。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        view.findViewById<Button>(R.id.button).setOnClickListener(Navigation.createNavigateOnClickListener(R.id.action_launcher_title_to_flow_input))
    }

createNavigateOnClickListenerには遷移先fragmentのidではなく、actionのidを指定しているのがポイントです。

対しInputFragmentでは次の画面へ値を渡す必要があります。今回の場合は以下のように記述できます。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        val editText = view.findViewById<EditText>(R.id.editText)

        view.findViewById<Button>(R.id.button2).setOnClickListener {
            Navigation.findNavController(it).navigate(
                    R.id.action_flow_input_to_flow_result,
                    ResultFragmentArgs.Builder()
                            .setInput_text(editText.text.toString())
                            .build()
                            .toBundle()
            )
        }
    }

ResultFragmentArgsはnavigation-safe-args-gradle-pluginが自動生成しているもので、navigationのxmlに記述した内容が元になっています。
同様に、ResultFragmentでも渡された値を表示できるようにします。

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        val args = ResultFragmentArgs.fromBundle(arguments)

        view.findViewById<TextView>(R.id.textView).text = args.input_text
    }

以上で基本的な機能の実装は完了です。

らくちん！

ディープリンク対応

app_navigation.xml内のfragment要素に、以下のように記述します。今回はaboutに対応するリンクにしました。

<fragment
    android:id="@+id/screen_about"
    ... >

    <deepLink app:uri="http://example.com/about"/>

</fragment>

AndroidManifest.xmlのActivity内に、以下のように記述します。

...
<activity android:name=".MainActivity">
    ...
    <nav-graph android:value="@navigation/app_navigation"/>
    ...
</activity>
...

以上で完了です。

らくちん！

所感

よさそう

※ 今回のコードはこちらに置きました