| @ブログ

最新の Rebuild.fm のエピソードを聞いてたら Automattic による Tumblr 買収の話から Medium 、 WordPress から古の Blogger 、 TypePad 、 MovableType まで話が及んで楽しかった。

エピソード内で miyagawa さんがインディーなインターネットユーザーとして独自ドメインは重要だけど、誰も使わないから当てられるサービスがなくなってきた、その意味で WordPress は独自ドメイン使えるので悪くない選択だと思う、的なことを言っていたのが印象的だった。エピソード中でも触れられていたけど、 Medium は新規登録ユーザーに対して独自ドメイン利用を利用不可能にしている模様。

ブログプラットフォームとしての知名度を高めるためには一目で「あ、このブログは Medium 使ってるんだ」とわかった方が良いはずで、となると独自ドメイン名を使われるのは良くないと判断したんだろうなぁ。

加えて Medium は確かに最近よくログインを求めてくる。旧型の iPhone 7 で見ると画面の 1/3 くらいの領域をユーザー登録導線にしてる感じ。読みづらい。なんらかのプラットフォームに乗っかると、やはりプラットフォームに「こう使って欲しい」と制約をかけられることになりがちだ。ステークホルダーが書き手、読み手、プラットフォームの三者になるので当然といえば当然か。一方でセルフホストのブログなら基本的には書き手と読み手の二者しかステークホルダーがいない。

ブログは自分で作るのが一番満足度高いと感じる。意に反して広告が出るようになることはないし、読者にログインを強要したりもしない。足りない機能があれば自分で作ればよいというのもよい1。自分はセルフホストのブログを同じドメインで 14 年やってて、最初は P_BLOG 、 そしていまは Lokka を自分で細々と改修しながら使ってる。時々更新が途絶えることはあるが、ほぼほぼ毎月一本は何かしらを書き続けることができている。サーバーの運用は発生するが、まぁプログラマーなら自宅サーバーか VPS くらい飼ってるだろうし、運用は趣味の一環かなという感じがする。

| @Mac/iPhone

Castro

以前書いたことがある Castro🎧 Overcast と Castro - portal shit!)がすごく便利になっている。

以前の記事では、 Overcast にあるチャプター移動機能やオーディオエンハンスメント・無音カット機能が Castro にはないと述べていた。しかし一年ちょい前にリリースされた Castro 3 により、有料ではあるがこれらの機能が提供されることになった。

これがめっちゃ便利。 UI は前にも述べたとおりすぐれているし、さらに購読中の Podcast のショーノートを検索する機能も今年の 1 月についた。

これもスーパー便利で、「あの Podcast の誰々がゲストで出てる回を検索して聞きたい」というありがちな要望を満たすことができる。以下は Rebuild のエピソード一覧で "higepon" で検索し、 higepon さんが出てるエピソードだけを絞り込んでる図。

Rebuild.fm で higepon さんが出演してる回で絞り込んでる様子

めっちゃ便利で最高なので是非お試し下さい。

| @Mac/iPhone

Fire

Memolist.vim の保存先を Dropbox にする運用を長年続けてきたが、 iOS の Markdown エディターの iA Writer で編集時にファイルが無限複製されるという問題があることや、最近のポリシー変更で Dropbox を無料で使い続けるのは難しそうかつお金を払うにしてもプランが高め(最安でも ¥1,500 / 月で 2TB まで使えるプランしかない)で個人では使いづらそうなので iCloud Drive を代わりに使ってみることにした。 iCloud は今のところ無料で使ってるが 50GB 使えるプランでも月額 ¥130 なので個人で使いやすい。 iCloud Drive は Windows や Linux からは使えないが、 Linux デスクトップはもう何年も使ってないし、 Mac と iPhone にロックインされた生活に不満はないので無問題。

移行の手始めにまずは iCloud Drive にターミナルでアクセスしようとするが、 cd ~/iCloud\ Drive などではたどり着けない。以下の記事を読んで調べた。

パスは ~/Library/Mobile\ Documents/com~apple~CloudDocs で良いみたい。

~/Dropbox/memolist ディレクトリを ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/ ディレクトリに移し、 .vimrc を以下のように書き換えた。

diff --git .vimrc .vimrc
index 6c4987e..56882b2 100644
--- .vimrc
+++ .vimrc
@@ -568,7 +568,7 @@

     " memolist.vim {{{

-      let g:memolist_path = "~/Dropbox/memolist"
+      let g:memolist_path = "~/Library/Mobile Documents/com~apple~CloudDocs/Documents/memolist"
       let g:memolist_unite = 1
       let g:memolist_unite_source = "file"
       let g:memolist_unite_option = "-auto-preview -start-insert"

これで Memolist.vim の Markdown ファイル保存先を iCloud Drive に移行できた。

| @散財

DSC_0380.jpg

Soundcore ( Anker のサブブランド的なやつ)の Liberty Lite を買ったところとても良かった。

これまでも Anker のイヤフォンは二つ買っている。どれも 2000 円くらいのやつだったが、イヤーピース(チップ)がポロポロ取れるやつで、何度もイヤーピースを無くしてしょうがなく左右で違うサイズのものをつけて誤魔化しながら使っており、かなりストレスが溜まっていた。

Liberty については rebuild.fm でだいぶ前に miyagawa さんが紹介していて良さそうだったので目を付けてはいたのだけど、これまで買ってきた 2000 円程度のものならいざ知らず、 6000 円近くしてまたイヤーピースが外れやすくて 1 年程度で買い換えることになったら嫌だなぁと悩んでいた。年末に Amazon を覗くとポイント還元キャンペーンをやっていたのでリストカット感覚で購入してみた。

良いところ

左右セパレートで完全ワイヤレスなのでめっちゃ楽

冷たいケーブルを首の後ろにたらんと垂らす必要がないのがこんなに快適だとは思わなかった。本体が耳からぽろっと取れるということもないし、イヤーピースもしっかりしていて簡単に外れたりしない。

遮音性が高い

ノイズキャンセリングではないが、カナル式なので耳の穴をしっかり塞いでくれて電車や街中など結構周囲の音がやかましい所で使っても音がよく聞こえる。 iPhone の標準イヤフォンでは線路脇を歩いていて電車が通るとめっちゃうるさくて何も聞こえなくなってしまうが、 Liberty であればちゃんと音楽を聴ける。

バッテリーが長持ち

直近まで使っていた Anker の SoundBuds は 3 時間くらいしかバッテリーが持たなくて、いざ聞こうとするとバッテリー切れ、ということが多かった。 Liberty Lite も本体は 3.5 時間程度だが、ケースと合わせて 12 時間バッテリーであり、使わないときはケースに入れて保管している間にケースのバッテリーから本体に充電されるので大体本体は満タン状態になっている。

悪くない音質

イヤーピースが外れるなど苦労しながらもこれまで Anker のイヤフォンを使ってきたのは値段の割に音が良いだからだった。 Liberty Light も個人的には十分満足できる音質。

残念な所

色々な機器で切り替えて使おうとするとペアリングの精度が悪くなる

例えば主に iPhone で使っていてたまに Mac でも使いたいとなると、いちいち iPhone でペアリングを解除して Mac で接続し直す必要がある。これをやってると iPhone との接続が不安定になって、接続の解除だけでなくリセットしないと iPhone と繋がらなくなるということが何度かあった。この辺は AirPods の圧勝だろうと思う(使ったことないから知らんけど)。

ケースに入れても電源が入り、 iPhone と接続されてしまう

Liberty Lite はケースに入れたら勝手に Bluetooth 接続が切れて充電が開始される仕組みだが、稀にケースに入れても iPhone との接続をキープしてしまいバッテリー切れになってしまうことがある。あるいはケースに入れて Bluetooth 接続は切れたが充電がされないこともある。買ってすぐの頃頻発していたが、しばらく使っていると起こりづらくなった。

結論

残念なところがないわけではないが、これまで使ってきた両耳が繋がってるものに比べて使い勝手もバッテリー持続時間も改善されて嬉しいという気持ちしかない。耳から外したら自動的に音楽が止まるような機能や iPhone と Mac でシームレスにペアリング先を切り替えられるような機能はないので、そういうのが欲しい人は 2 万円近く払って AirPods を買ってもらうしかないと思いますが、 Mac とモバイル機器でイヤフォンを分けてるような人には Liberty Lite は十分満足できるコストパフォーマンスの良いイヤフォンだと思います。買ってよかった。

| @雑談

昨年末に自分の両親の携帯をガラケーからスマートフォンに移行したときのことを書いておきます。

前提条件

  • 両親とも docomo でガラケーを使っていた
    • 充電器を共用できるという理由で同じ機種の色違いにしていた
    • スマートフォンに変えても同じ状況が良いと言っていた
  • docomo からはさっさとスマートフォンに移行しろというようなハガキが定期的に届きプレッシャーを感じていた
  • 自分と弟のお古の iPhone 6 ( docomo 機とSIM Lock Free 機)が余っていたのでそれを渡すことにした

回線

  • 回線は MVNO に移行してスマートフォンに変えてもガラケー時代と変わらない程度の料金で済むようにした
    • 月額料金が跳ね上がることがスマートフォンに移行できない理由の一つだった
  • キャリアはイオンモバイル経由の IIJmio にした
    • 近隣のイオンの店舗で即日 MNP が可能なため
  • docomo のキャリアメールは諦めてもらった
    • 家庭内での連絡にしか使ってなかったので Apple の Messages で問題なさそう
    • 母は LINE を使ってるかもしれない。

Apple ID とメールアドレス

  • 実家には iPad と iMac があって Apple ID も取得済みだったが夫婦共用状態だった
  • いい感じの移行は無理だと思ったので両親ともに Gmail のアドレスを取得して新たに Apple ID を作成した

感想

  • スマートフォンに移行できて喜んでいた
  • iMac と iPad を使っていたので App Store やソフトウェアアップデートの概念に慣れていたのがよかった
  • 一族郎党全て iPhone になったので写真の共有や FaceTime ができるようになり便利
    • 息子殿がじいさんばあさんに FaceTime してしりとりしたりできる
  • 渡した iPhone 6 はさすがに古すぎるので新しいのに変えてやりたい
    • 実家は山間地で寒いため冬になると iPhone 6 では急に電源が切れる
    • 3 ~ 4 万円で買えるお手軽 iPhone があれば良いのに…
  • docomo ショップのサポートに頼れなくなるので自分が全力でサポートする必要がある
    • 自分のサポート負荷を考えると両親とも同じ機種、キャリアの方が良さそう

追記 2018-12-31 09:50:16

ひとでさんの記事には バックアップの効いたソリューションに移行してほしい とあったけど自分の移行記では完全にその観点が抜け落ちていた。 uzulla さんが書かれた以下の記事の方がプラクティカルだった。

パスワード管理は自分(子どもの方)がやるという点やバックアップは iCloud に金払って任せるという点はなるほど感あった。うちの両親は iCloud でアドレス帳などはバックアップされていると思うが、写真に関しては多分バックアップ取りきれてないので正月実家に帰った時にその辺の管理を見直したい。

格安 SIM にしない方が良いという点に関してはまぁそうなんだろうけど、僕の両親の場合は大して使いもしない携帯電話に毎月 8000 円(夫婦で 16000 円)も払いたくない、今と同じくらい(夫婦で毎月 6000 円程度)でスマートフォンに移行したい、という希望があったので格安 SIM にした。

キャリアの窓口はデジタル介護施設として存在している。

面白かった。ただキャリアのサポート窓口、自分がかつて docomo や SoftBank を利用していたときに有効なサポートをしてもらった経験がほとんどないので MVNO で良いだろうという結論に達してしまった。

| @旅行/散歩

アルプス遠征で白馬に行ったとき、福岡からは松本経由で行った。前の記事に書いている通り台風の影響で縦走の予定がピストンとなったため、松本を一日観光する時間ができた。

松本には去年の秋に友達の結婚式で行っていて、そのとき市内を少し観光してすごくいいところだなと思った。前回は帰りの飛行機の時間の都合でできなかったことがいくつかあり非常に悔やまれたので、今回は前回できなかったことをやってきた。

宿泊

泊まったのは花月というホテルで、結構よいホテルのなはずなのにハイシーズンにもかかわらず低価格で泊まることができたが、部屋に入って窓を開けるとこの景色でなるほどという感じだった(これはこれで面白くてテンション上がった)。

IMG_6027.jpg

昼食 1

松本には昼過ぎに着いたのでホテルに荷物を置きに行き、 The Source Diner に行った。ここには前回も来ていて、カウンターの席に座るとお店の人が料理している様子を眺めながら食事することができる。自分も料理するの好きなので目の前で料理してくれるタイプの店はプロの慣れた手さばきが見られてとても楽しい。

DSC_5954.jpgDSC_5960.jpg

物色

あたりをうろつく。ナワテ通り外れの角にあるポーランド食器のセラミカがよくて、以前来たとき器を買うか迷ったが荷物になることや結構高いこと( 21cm の皿でも 3000 円から 5000 円くらいする)、帰りの飛行機まで時間が限られていたことで決心しきれず、買わずに帰ってきてしまった。あとあとこのことが非常に悔やまれて、もしまた松本に行く機会があればセラミカを訪ねて皿を買いたいと思っていた。

買いたい器に目星をつけたが今日は荷物になるので買わないでおく。

コーヒー 1

その後、セラミカの器でコーヒーが飲める喫茶店「カフェあげつち」でコーヒーを飲んだ。この喫茶店は 300 円でコーヒーが飲めてレトロな家具や調度品が飾ってあり休憩にちょうどよい。観光客向けというより地元の人が談笑しに来ている感じ。年季の入った建物を修復して公営の会議スペースとして利用しているようである。

松本城

そこから松本城に行った。前回も今回もお城の中には入らなかった。入り口に「ここから 30 分待ち」というような看板があったが、ああいうのがあると入るのをためらってしまう。

DSC_5962.jpg

お土産 2

夜は会社の仲良しおじさん連中と飲みに行くことにしていたので、ムラマサに行ってお土産を物色した。ここも前回来たときに気にはなったけど時間がなくて素通りしてしまった店(まつもと空港で売ってるだろうと思ってスルーしたら売ってなかった)で、寄らずに帰ったことを猛烈に後悔したので滞在中何度も訪ねて入念に物色した。シュークリームが名物のようだったが旅行者で冷蔵庫に保存することができないのでお店の人にお勧めを聞いて天守石垣サブレを買った。この手のクッキークリームサンド的なお菓子にはあまりテンションが上がらないのだが、帰ってきて食べてみたら確かにおいしかった。

DSC_5978.jpg

飲酒 1

花時計公園の横にある信州ゴールデン酒場に行った。山賊焼を食べたが焼きという名前なのに揚げてあるのにはびっくりした。あと付け合わせキャベツについてくる味噌が完全にう◯こに見えてやばかった。キンミヤハイボールがよいと foursquare の Tip にあったので頼んだらもろに甲類焼酎のアルコールにやられて悪酔いした。

IMG_6024.jpgDSC_5983.jpg

飲酒 2

二軒目はナワテ横丁にある彗星倶楽部という名前の店に行った。両腕にタトゥーを入れたお姉さんがやっててかっこよかった。つまみも全部うまかった。

IMG_6025IMG_6025

さらにもう一軒行ってそばを食べたけど泥酔し過ぎていてあまり思い出したくない…。

朝食

12:50 にバスセンター集合だったので早めにチェックアウトして朝食を食べに行ったが、目当てにしていたおきな堂はモーニング営業を取りやめており路頭に迷ってしまった。二日酔いで勘が鈍っており、ふらふらしながらナワテ通りの適当なパン屋に入ったところいまいちだった…。せっかくよいホテルに泊まってたのだから大人しくホテルの食堂のモーニングを食うべきだった。同僚によると「まるも」という喫茶店が良かったとのこと。

お土産 3

萬年屋というところで味噌を買った。信州味噌はなかなか九州では買う機会がないので面白い。二年熟成の味噌を買った。

IMG_6025

コーヒー 2

この日のメインイベントはセラミカでの器購入だったがオープンが11時なので開店まで暇をつぶす必要があった。朝食のコーヒーがいまいちだったので年季の入った外観だが今風の若い人が載ってそうなチャリンコが停めてある喫茶店に入ってコーヒーを飲んだ。

IMG_6025IMG_6025IMG_6025

セラミカで散財

11 時になり満を持してセラミカに行った。山小屋泊ですっかり朝が早くなったので 11 時はもう夕方みたいに感じる…。皿を三枚とマグカップを買った。グラタン皿も良さそうだったが流石に高すぎた(一万円オーバー)。カード払いしたが二回分割したかったのに何も聞かれず一括で決済されてしまった…。ただ買った皿はとてもよい。何でもおいしく感じる。

IMG_6031IMG_6031

昼食 2

ホテルの近くに有名なそば屋があるようだったのでセラミカで買い物をしたあと行ってみたが、 11:30 オープンで 11:35 に着いたにもかかわらずすでに満席で店の外まで列ができていた。今から並んではバスセンターの集合時刻に間に合わなくなるので仕方なく別のそば屋に入った。この日は暑かったが鴨南蛮が食べたくてだらだら汗をかきながら熱いそばを食べた。

IMG_6025

散策

そばを食べたあと、ホテルに預かってもらっていた荷物を受け取り、ホテル横の湧水場で湧き水をナルゲンボトルに汲んだ。松本は市内各所でこのように水が湧き出ているようである。重いザックを背負いバスセンターまで 10 分ほど歩いた。松本は標高 600m あるとはいえ 8 月の日中は暑く、大量に汗をかいた。

インスタグラムスポット

途中、ふとん屋のたたずまいが良すぎて写真を撮った。ここは去年来たときも見かけて写真を撮ったが、去年は一眼レフを持ってきておらず iPhone でしか写真を撮れなかったことをとても悔やんでいた。

IMG_6025 IMG_6025IMG_6025

感想

松本は岳都や学都、楽都と言われるが、確かにそうだなと思った。北アルプス登山の足がかりとなる街で市内から北アルプスの山々の姿を見ることができる。また信州大学の本部があり旧制高校の松本高等学校もあって学問の雰囲気も感じる。ナンバースクールがあった熊本(第五高等学校)よりも貫禄がある。加えて音楽が盛んなようで、街中に小澤征爾の音楽祭のポスターが貼ってあった。どうやら市をあげて音楽振興に取り組んでいるようである。

生まれ故郷の阿蘇もかつては阿蘇登山の拠点として駅前に旅館がいくつもあり栄えていたが、自動車が普及し日帰りで訪れることができるようになって 90 年代にはそれらの旅館は全て廃業してしまった。松本はきっとその時代から変わらず岳都として栄え続けているのだろう。山の高さや数が阿蘇とは全然違うとはいえ、山岳観光都市として参考にできる点は大いにあると思った。

アルプス登山がてらまた行きたい。

| @技術/プログラミング

GW 中、十分インスタンスを用意しておいたが想定を超えるアクセスがあって負荷が高まり、 Alert が飛んでくる事態となった。車を運転中に iPhone をカーステにつないでいたところ Slack がピコピコ鳴り、嫁さんから「休みなのか仕事なのかハッキリしろ!」と言われたので Alert が上がらないようにオートスケールを仕込むことにした。 いみゅーたぶるいんふらすとらくちゃー諸兄からしたら「そんなの常識じゃん」みたいな話ばかりだけど、自分でやってみて得られた知見をまとめておきます。

なおここで言っているのは EC2 インスタンスのオートスケール( EC2 Auto Scaling )であり、 AWS の様々なリソースを包括的にオートスケールする AWS Auto Scaling とは異なります。

オートスケールをやるにあたって必要なこと

1. インスタンス起動時に最新のコードを pull してきてアプリケーションを起動させる

オートスケールしてきたインスタンスだけコードが古いとエラーが発生する。

2. インスタンス停止時にアプリケーションのログファイルをどっか別のところに書き出す

Auto Scaling Group のインスタンスは Stop ではなく Terminate されるため、インスタンス破棄後もログを参照できるように S3 に上げるとかして永続化させる必要がある。 Fluentd や CloudWatch Logs に集約するのでも良い。

3. AMI を定期的にビルドする

オートスケール対象のアプリケーションは枯れていて今更新しいミドルウェアが追加されたりすることはなくてソースコードを git clone してくるだけで十分なのだが、 Gemfile に変更があった場合を想定して少しでもサービスインを早めるため( bundle install を一瞬で終わらせるため)、 master ブランチへの変更が行われなくなる定時間際のタイミングで Packer でビルドして AMI にプッシュするようにしている。

4. Launch Configuration を自動作成

AMI のプッシュが成功したら最新の AMI を利用する Launch Configuration を作成し、 Auto Scaling Group も最新の Launch Configuration を参照するように変更する。 AWS CLI でできるので自動化してある。

5. Auto Scaling Group の設定をいい感じにやる

Auto Scaling Policy を決め( CPU 使用率が一定水準を超えたらとか、 Load Balancer へのリクエスト数が一定以上になったらとか)、時間指定で Desired Count や Minimum Count を指定したければ Schedule をいい感じに組む。 AWS Management Console 上でポチポチするだけでよい。

6. deploy 対象の調整を頑張る

当初は Auto Scaling Group のインスタンスには deploy を行わない(業務時間中はオートスケールしない、夜間と土日だけオートスケールさせる)つもりだった。

autoscale-day-and-night.png

しかしメトリクスを確認すると朝の通勤時間帯や平日の昼休み時間帯などにもアクセス数が多いことがわかったので一日中 Auto Scaling Group インスタンスを稼働させることにした。となると deploy 対象が動的に増減する、ということなので Capistrano の deploy 対象もいい感じに調整しないといけない。 AWS SDK Ruby で稼働中の EC2 インスタンスの情報はわかるので、 deploy 時には動的に deploy 対象を判定するようにした。

autoscaling-all-day.png

本当は push 型 deploy をやめて pull 型 deploy にするのがナウでヤングなのだろうが、レガシーアプリケーションに対してそこまでやるのは割に合わない。そのうちコンテナで動くもっとナウでヤングなやつに置き換えるのでこういう雑な対応でお茶を濁すことにした。

注意点

冒頭に書いているけどあくまで上記は EC2 インスタンスの Auto Scaling であり、周辺のミドルウェアは Scaling されない。例えば RDS を使っていたとして、 RDS インスタンスの方は拡張されないので Connection 数が頭打ちになったり、 CPU を使うクエリが沢山流れたりしたらそこがボトルネックになって障害になってしまう。周辺ミドルウェア、インフラ構成に余力を持たせた状態で行う必要がある場合は AWS Auto Scaling の方を使うことになると思う。

所感

1 と 2 のステップはすでに実現できていたので、自分は 3 、 4 、 5 、 6 をやった。オートスケール、めっちゃむずかしいものというイメージを持っていたけど、まぁまぁすんなり行った(二日くらいで大枠はできて、連休後半には実戦投入した)。負荷に応じて EC2 インスタンスがポコポコ増えて、週末の夜にパソコンを持たずに出かけられるようになった。これで家庭円満です。