ただのにっき

■ 本日のハンティング

旅行中に見落としてるのがあるかもしれない。

ヒトリゴトノヒビを捕獲(137)。ツッコミの削除ができないのは、「人様が書いたものをそう簡単に消してはいけない」というポリシーです(笑)。いつ復活したくなるかわからないしね。

■ 沖縄(4)

朝は珍しく沖縄抜きの和食。でも七草粥だった。そうか、7日だったのか。南国にいると、日付の感覚がなくなるよなー。

昼は空港で。パンを食べたけど、飲み物にシークヮーサーのジュースを。あと、自分へのお土産にサーターアンダギーを買って、これでほぼ沖縄食制覇か?　あ、まだ海蛇と食ってないな。

夕方、無事に帰る。夕飯は市場でおまけにもらった辛子菜と、ポークでチャーハン(笑)。

まったく、食い物の話ばかりだったな(笑)。しかし、普段にも増してツッコミをたくさんもらったので、おいしいものをたくさん食べられた。感謝です。

■ piccolo(13)

ishiiちゃんに切断してもらうヒートシンクを会社に持ってきたら、想像していたものと違っていたらしく、たいそう驚かれた。「CPUの上に載ってる黒いアレ」は、プラスチックだと思っていたらしい。プラスチックで放熱できれば、安上がりでいいですなぁ。って、昨日から何度も「銅」って言ってるやんけ!!

それはさておき、夕べからまたファンレス運用に戻している。やっぱり風切り音が気になるので。しかし、lm_sensorsの出力はなんか変だよなぁ。温度のところだけ取り出すと、こんな感じである。

temp1:       +71 sensor = thermistor
temp2:     +34.0 sensor = PII/Celeron diode
temp3:    +208.0 sensor = thermistor

temp3は明らかに変なので、数値自体の信憑性はないと考えるようになった。キャリブレーションが必要だろう。いずれにしても、temp1とtemp2は負荷に応じて上下するので、なんらかの温度を反映しているのはたしか。

temp2がCPUだとすると、temp1はM/B上のどこかだろう。CPUよりも倍も温度が高いってこと? ちなみに、筐体に触ると風呂の温度くらいの熱を持っている。CPUが30度なら、それより筐体が熱いのも変じゃないの? と思ってGoogleしてみると、piccoloユーザの日記を発見。ヒートシンクの方がケースよりも温度が低いって。あらま。

続けて読んでいくと、この人すごい。ファンを換装した上にケースに加工。さらにケース側面にまで穴。ファン付きでほとんど無音にまでたどりついている。最終的にはMP3再生中にも30度前後を保つようになったようだ。すばらしい。やっぱ、穴を加工することで風切り音はなくせるんだなぁ。それならファンレスにこだわらなくてもいいかも。うーん、ボール盤……。

追記: ↑よくよく読み進めてみると、筐体の上にファンを置いて風を送っているようだ。なんだ、本体完結じゃないのか……。ちと残念。

■ おぉ、ご本人に登場されてしまいました。情報ありがとうございます。2chのスレも全部読んでしまいましたよ。感動です。写真がぜんぶなくなってて悲しかったですが(笑)。

「piccolo、piccolo」って書いてるけど、実はSUMICOMの鏡面仕上げVer.なので(「SUper MIni COMputer」の略だって。ダサっ)、ケースを加工するとメッキがバラバラはがれてきそうなんだよね。まぁ、見てくれにはあまりこだわらないから構わないんだけど。ハンドドリルでいけますかね。

でも、どうせファンを付けるなら、CPUはヒートシンクだけにして、外しちゃったCD-ROMドライブの代わりに吸気ファンを入れて、上から排気するようにした方が好みだな。あそこに何か入れられると面白いんだが。

それより2chの方にあったALPHA UBC60-20Bってんはすごく良さげ(ちなみに25mmのは入らないはず)。ishiiちゃんの改造が失敗したら買ってみよう(笑)。やっぱ、目指すは完全ファンレス。

それからメモ: VIA Processors

■ 過酷な仕事始め(3)

今日はMLが稼動。復活の呪文はsuExec。

しかしなんだ、帰ったら何もする気がしないので、少なくとも週末までは溜まった(プライベートの)メールの返事なんて書けそうにない。もちろん、こま犬の更新なんてもってのほか。

■ iPod mini

欲しい色がない……。

いまの10GB iPod、約半分消費している状況を考えると、容量的にはこれでも十分なんだけどな。なんか質感が悪いよ、これ。アルミの携帯灰皿みたい。

■ Quake部

あんまり寒いのでバイクで行くのはやめ、車で出たのだが、東名下りが事故渋滞でピクリとも動かなかった。やっぱバイクで行くべきだったか……。もっとも、バイクで行ったら行ったで、こんどは寒さで体がこわばってしまい、ゲームどころの話じゃなくなるんだけどね。

でも、どっちにしろ的にされるのは変わらんかったか。smallが最近、めっきりニュータイプ化してしまったので、こっちがQuad付きロケットランチャーで武装していても、10回中9回は撃ち負けてしまう。どうなのよ、それって。やっぱ、夜な夜な自主練してると違うよなぁ。つーか、参加者のほとんどに負け越し……。T-ZONEミナミで日本一になったこともあるというのに。嗚呼!

■ グラコロとチーズグラコロ

ホントに復活しててワラタ。包み紙もやっつけな感じで、慌てっぷりがよくわかる。

まぁ、また味わえることを喜ぼうではないか、同盟員諸君。

■ tDiary: ruby 1.9.1対応でdefault_externalを使うのは適切か?

tDiaryのtrunkで、ruby 1.9.1対応のためにdefault_externalを設定している件に関して、ZnZさんからツッコミがあった:

default_externalの影響範囲がよくわからないけど、tdiaryのここで使うのは適切なのだろうか?

ツッコミ欄に書くには長くなるので、こっちで書いてみる。ホントは書きたくなかったんだけど、なぜかというとるびまに書くネタがなくなっちゃうから!(ぉ　もっとも、ruby 1.9のエンコードに関してちゃんと理解しているとは言いがたいし、ここでツッコミ受けたほうがいいでしょう。

実行中のruby 1.9全域に影響するエンコーディングには3種類ある(たぶん):

• scriptエンコーディング
• default_internal
• default_external

scriptエンコーディングは、*.rbファイルそのもののエンコーディングで、これはマジックコメントを入れれば対応できる。もしくはevalなどする場合には、その文字列のエンコーディングを適切に設定してやれば良い。これはOK。tDiary trunkの*.rbにはすべて以下の1行が挿入済みだ:

# -*- coding: utf-8; -*-

default_internalはrubyの内部処理(?)におけるデフォルトで、あんまり考える必要はないと思ってる。だから今のところスルー。

default_externalは、プログラムの「外界」でどんなエンコーディングが使われているかの標準値で、基本的にはインタープリターがlocaleなどを参考に起動時に決定するし、-Kなどのパラメタでも制御できる。tDiaryで問題になるのはコレ。

tDiaryが使われる状況は「ふつーのレンタルサーバ」を想定している。「外界」の環境設定はレンサバ屋さんが自分たちの都合で設定していて、ユーザには変更できないことが多い。また、tDiary設置者のリテラシを考慮すると、shebangに適切なオプションが指定されることも期待できない(そういう縛りを増やすとサポートの手間が増えて開発が滞るのである)。

また「とりあえずrubyだけ入っていれば動く」というのを最低限の環境として想定していて、それもできる限り古いrubyもサポートしたい。実際、1.8.7が入っているサーバはまだまだ少なくて、(セキュリティ的に好ましくないとはいえ)1.8.2～1.8.6がゴロゴロしているのが実態だ。この上にruby 1.9対応を付け加えるのがtDiary 2.3系開発のミッション。

default_externalに依存せずに「外界」のエンコーディングを制御する方法としては、例えばファイル等の読み出し時に下記のようにに指定する方法があるわけだが:

open( 'hoge', 'r:utf-8' )

ちょっと古いruby 1.8系だとこんなオプションは受け入れられない。そもそも、tDiaryはしばらく(EUC-JPな)2.2系と(UTF-8な)2.3系が並存するし、rubyも1.8系と1.9系が長く並存するだろう。tDiary用のプラグインを書く人には、これらの組み合わせにできるだけ対応して欲しいし(tDiary 2.2とruby 1.9の組み合わせはないけど)、そのためのハードルは低く保ちたい。

となると、以下のように書くだけで、読み込んだファイルは(ruby 1.9では)UTF-8だと認識して欲しいわけだ:

open( 'hoge' )

現在のtrunkのコードには(試行錯誤の結果として)「'r:utf-8'」が入っているが、default_externalが期待通りのデフォルト値を設定してくれることがわかれば、これは元に戻してしまいたい。

逆に言えば、利用者やプラグイン開発者の負担になることなく外界のエンコーディングをUTF-8に設定できるなら、default_externalなど使わずに済ませたい。

というのも、CGI以外のプラットフォームで他のアプリケーションと同じインタープリタ上でtDiaryを動かすような場合、default_externalを勝手に変更するのはまずいからだ。もっとも、default_externalの値に何かを期待するアプリを同じインタープリタ上で動作させるのはそもそも無茶だとは思うけど。

というわけで、利用者やプラグイン開発者に「外界」のことを意識させずにUTF-8で統一されたエンコーディングを使わせたいので、external_encodingを設定している、というのが現在の状況。

■ Kindle3向けdot by dotな自炊PDFを(真面目に)作成する

ePUB 3.0が、縦書きやルビをサポートしてそろそろ仕様確定するそうで、それはそれでめでたいんだけど、各種デバイスがいつサポートするのかもわからんし、出版サイドにノウハウがつくのにも時間がいるだろうし、普及にはしばらくかかるだろう。

いっぽう、大長編「まおゆう」を自作したPDFで読んだり、最近高橋さんが作っているSONY Reader向けの青空文庫PDFをKindleに入れてみた経験からすると、電子書籍は必ずしもリフローできるフォーマットである必要はないんじゃないかとも思い始めている。世に出回っている電子書籍端末は、3～4インチ(スマートフォン)、5～6インチ(KindleやSONY Reader)、10インチ前後(いわゆるタブレット)の3種類。だったらこれらに合わせて最低3種類のPDFを選択可能にしてくれればそれで十分じゃないのか? 字の大きさのバリエーションを2種類作ってもせいぜい6種類。これで大多数の人が使えるなら、ePUBじゃなくてもいいわな。

いずれにせよ、現時点でePUBが読めないKindleがePUB 3.0をサポートするかというと怪しいと思うので、自分にとって自炊本がソースである期間はまだしばらく続きそうだ。

というわけでベストプラクティス宣言後も、シェルスクリプトのRakefile化と並行してチマチマと最適化をしていたりして。なにせ、字がまだ汚いのだ。ちなみに最新のRakefileはGitHubで公開してある。

最近の発見(?)は、pdftoppmが吐き出す画像ファイルのデフォルトの解像度が150dpiだったこと。えーと、たしかおれ、600dpiでスキャンしてたよね? 150dpiつったら、Kindleそのものの解像度より小さいわけで、そんな画像を拡大表示してたら汚くてあたりまえだ……。というわけで「-r 300」をつけて大きめの画像を抽出するようにした(「-r 600」ならなお良いが、300でも十分な解像度である)。

それから、これをトリミングしたあとで、Kindleの画面にぴったりフィットするようにあらかじめリサイズする。けっきょくこれが一番確実なのがわかった。そのために、真っ黒な画像を使ったPDFを作り、Kindle上でどれくらいの大きさに表示されるのかチェック(ググればわかるように他の人も似たようなことをしているけど、みんな微妙に数字が違うので自分だけを信じることにした[笑])。

まず文庫や新書向けの縦持ち(ポートレイト)の場合、560x735がPDFの表示エリア。紙の書籍を画像化した場合は縦がつっかえるので、高さ735に最適化すれば良い。ImageMagicには「-resize x735」を指定する。できたPDFのスクリーンショットがこんな感じ。ちょっとノイズが乗っているけど、実際にKindle上で読んでいれば気づかない程度:

続いて大型の技術書を横持ち(ランドスケープ)で読む場合、722x535が表示エリア。こんどは横だけフィットすれば良いので、ImageMagicのオプション指定は「-resize 722」になる。これで最適化するとこんな感じ:

これならmobiな書籍と比べても遜色の無い美しさだよ。満足だ。長かったけどこれで最適化の旅はたぶんおしまい。あとはファイルサイズ削減のためにもうちょっと圧縮率を上げられないかトライするかも。

■ 金色の腹巻を編む(2)

年内には編みあがるかなーとか言ってたくせに、ようやく昨晩に完成。さっそくつけて寝てみたり。

正直、あまりうまくできなかった。イギリスゴム編はカッコイイけど、ちょっと緩めに編んでしまったので間が抜けてる感じがするし、だいたい設計にミスって少しばかり大きすぎる(つまりゆるい)。そのくせ最後の伏し目をタイトにしすぎたせいで、そこだけキツいのである。輪編みじたいはわりとうまくいったんだけど。

実用上はほぼ問題ないし色は好きだけど、そういう細かい部分で不満も少なくないから、ひょっとすると編み直すかも知れない(とか言ってると春になってしまうのである)。

■ ハンターズ・ラン (ハヤカワ文庫SF)(ジョージ・Ｒ・Ｒ・マーティン)

寝かしてる間に1年半もたっちまった。

異星のジャングルで繰り広げられる追跡劇がスリリングな冒険SF。ヒスパニック系の主人公、植民星の文化もそっち系なので異星というよりむしろその方が「異国情緒」を醸し出している気もするが、そういう面も含めて楽しいエンターテイメントだった。とくに、ストーリーを通してずっと明かされずにいる冒頭の事件の「動機」が、ラストで主人公の正義感の芽生えにカッチリはまるところなんて、なかなかの爽快感だ。主人公が頭がいいくせに感情的になると理性がすっ飛ぶタイプというあたりも、いい意味でお約束。

ただ、ジョージ・Ｒ・Ｒ・マーティンのわりには凡庸だなー、という感じも否めない。「追手」の正体が登場直後からバレバレな件(少なくともそれなりに経験を積んだSF読みにはあからさますぎる)とか、あんまり謎が謎になっていない点がいくつかあって、わくわく感を削いでいる。あとがきによれば3人の著者による30年(!)の長きにわたる合作だそうで、なんとなくぼやけた感じを受けるのはそのあたりに原因があるのかも知れない。

■ バハムートの「侵略の氷獄王と聖神矢の少女」終了

休みだったので珍しく進めていたバハの年越し討伐イベントが今日で終了。ゲームのことはあんまり書かないのだけど、なんか新年早々運を使い果たした気がしたのでメモ。

最終日を前にして報酬のSSRエイラが4枚揃ったので、あとは最後にもう1枚、デイリーミッションで取ろうかなと思っていたら(例によって)終わり間近になるとサーバが落ちまくってぜんぜん進まない。結局あと30体MVPという微妙な位置でイベント終了。まぁ4枚あるからいいけど、3枚だったら訴訟ものだよ。あいかわらずだなぁ(わかっているなら終盤にラッシュかけないでもっと早くに進めておけば良かったのである)。

で、500個近くたまってた戯玉交換をし始めたら、あと2、300個くらい残したところで4箱目のエイラが出ちゃった。これは出ないと思っていただけにラッキー。

じゃあ残りは適当に消化して……と思って箱をリセットし、5箱目に突入したらこれもすぐにエイラが出た。びっくり。ここまで出たことはないなー、こういうこともあるんだなー、じゃあネタで最後の1箱行ってみよう→出ちゃった。えー、おれ死ぬの?

結局2日目のデイリーをくわえて7枚も入手できてしまった。これで最終日のデイリーさえちゃんと取れていれば夢のSSR8Maxじゃないですか。やっぱ訴訟ものだ。

エイラかわいいよエイラ。

■ tDiary (のmasterブランチが) Herokuに直接デプロイ可能になった

もう1年近くまえ、tDiaryをHerokuボタンでデプロイ可能にしたんだけど、あれはそれ用に特殊な設定をしたherokuブランチのことだった。これはこれで良かったんだけど、通常プルリクエストはmasterブランチに対してなされるので、それをHeroku上でテストしようとするとなかなか面倒だった。

で、@machuがその「特殊な設定」をあらかじめやってくれるtDiaryのbuildpackを書いてくれ、おかげでmasterブランチでそのままデプロイ可能になった。すごい!!

これで、tdiary-coreにプルリクエストが来ると:

1. (自動的に)Travis-CIでテストが走って、
2. (自動的に)Herokuに専用のtDiaryがデプロイされ、
3. 問題なければプルリクエストをmergeすることで(自動的に)Heroku上の開発用tDiaryが最新化される

という流れができるようになった。この流れを可視化するようにHeroku上にPipelineも整備した(下図)。なんかモダンじゃね? なんといっても手元にテスト環境がなくても開発できるぞ。感動や。

で、今後新しいtDiaryインスタンスをHeroku上に作る場合はtDiary.orgやGitHub上のリポジトリにあるHerokuボタンをポチっとして必要事項を入力するだけでよくなったんだけど、以前herokuブランチで作成した日記をこの仕組みに乗せないといけない。

まずはHeroku上のtDiaryを運用するで有効になったsystem_updateプラグインでtDiaryを最新化する。実はこれで利用するブランチがherokuブランチからmasterブランチに切り替わっている。このままだと必要なBuildpackが有効になっていなくてエラーになるので、以下のコマンドでこれを切り替える(コマンドからじゃないとできないっぽいのが残念):

 heroku buildpacks:set https://github.com/tdiary/heroku-buildpack-tdiary.git -a 【対象のApp名】

(herokuコマンドはgemから入れることができる。ex. 「gem install heroku」)

続いてHerokuのdashboardで当該Appを開き、「Manual deploy」からmasterブランチをデプロイする。これで動くはず。

あとは「Automatic deploys」の対象ブランチをherokuからmasterに変えておけば、以後はmasterブランチを対象にsystem_updateプラグインが動くはずである。手元のテスト用Appはこれで移行できている。

■ ようやく初詣へ行ってきた

今年は休みも少ないうえに元旦から大阪へ行っていたりしたので、今日になってようやく初詣へ。いつもの寒川神社。

同じような人は少なくないのでは*1……と思ったけど、午後遅くになってからということもあって、そんなに大混雑ではなかった。駐車場待ちの行列はかなり長かったので、空いてると睨んで車で来た間抜けは多かったようだ(そんな甘い話があるわけがない)。

■ 「THE IDOLM@STER ニューイヤーライブ!! 初星宴舞」DAY2 LVへ行ってきた

昨日の続き。DAY2はバルト9が4連で取れたのでいつものメンバでいっしょにみた。バルトはスクリーン2つだ。現地組は3人かな。ちょっと競争率高すぎるよねぇ。

そういえば今回、ちょっと面白いなと思ったのがステージで。メインステージにはLEDスクリーンがいっさいないのね。去年のプロミでは大きなスクリーンに3Dモデルの春香が投影されて、アイマスはこっちの方向に進むのかと思っていたが、今回はゲームに登場するステージをそっくり再現することにして(細かいこだわりはすばらしかったが、地味といえば地味)、スクリーンは両サイドだけ*1。ショーアップを追い求めるシンデレラでもなく、オーソドックスなシアターのステージにこだわるミリオンでもない、実力だけで押し切る765ASの凄みを感じるステージでもある。

いつもの中里レポート:

• 9:02pm、星のステージにて。「THE IDOLM@STER ニューイヤーライブ!! 初星宴舞」２日目レポート

THE IDOLM@STER ニューイヤーライブ!! 初星宴舞 LIVE Blu-ray 絢爛装丁版 (完全生産限定)
765PRO ALLSTARS
ランティス
￥19,250

DAY2はね、まずはなんといっても「フラワーガール」。貴音でどの曲と聞かれたらノータイムで「フラワーガール」と答えるくらいに好きだけど、最近の貴音の立ち位置からしてセトリに組み込みにくいのはわかってた。なので、はらみーがみずからこの曲を選んでくれたのがほんとに嬉しい。いやー、嬉しい。貴音とコール&レスポンスライブするってシチュエーションがいいし、ライブの序盤にくるもいい。

そしてついに! 「全力アイドル」!! きたわー。MCでくぎゅが「これ聴きたかったでしょ」的なことを言ってて完全に手のひらで転がされてる感があったが、いやでもさー、一生に一度は「アイドルヤホー！」やらんと死にきれんだろ(笑)。「全力でかわいい伊織」、楽しゅうございました。また聴きたいのでお願いします。

ひさびさの若林神、歌マスからもう(例によって)全力疾走だったけど「いっぱいいっぱい」でさらにギヤをあげて大暴走で楽しすぎた上に、そのまま残って「七彩ボタン」イントロに参加する流れがもう神がかっていて泣くしかない。もちろん竜宮が(ついに)揃っての「七彩ボタン」も最高。

とにかく、来る曲くる曲、ぜんぶ「あ！それ聴きたかった!!」てのばっかりで、さすが数百曲ものレパートリーをもつ765AS、どんな組み合わせでもそのまま理想のセトリになる。強い。中でもオリジナル・メンバーによる「オーバーマスター」は感激至極。961プロのプロジェクト・フェアリーではなく、765プロで研鑽を積んだ3人でって感じがしてすばらしかった。

新曲だと「ブルウ・スタア」がクオリティ高し。やはり宏美さんの低音は効く。「ゲンキトリッパー」が聴けて嬉しい。もちろん今日やるのが確定していた問題曲「CRIMSON LOVERS」は照明やフレイム演出含めちょっととんでもないシロモノで、これアイドルのライブじゃねーだろ……っていう。

つーか終盤「9:02pm」や「細氷」含めた流れ、思い浮かんだのは「ディレ1っぽいセトリだな」だった。ミンゴスにはソロの選択権がなかったそうだけど、本人によれば実際に歌いたかった曲を指定されたとのことなので、やっぱりこのメンツで選んだ曲を並べるとディレ1っぽくなるのかもな(笑)。それを含めて、今回のライブは文字どおり温故知新で本当に面白く、楽しく、興奮した。やっぱり765プロは最強だ。

最後のMCで、仁後ちゃんが「好きって言ってくれる人が一人でもいる限り続けていきたい」と宣言。10thドーム以降、ことあるごとに「これでおわりだと思ってた」的なことを漏らすようになっていた仁後ちゃん。じっさい既婚組の半分はアイマス以外の声優仕事はなく、なかば引退しているような状況で、765プロがいつミリオンやシンデレラに代替わりしてもおかしくない。そんなな中、キングは還暦までやると息巻いて、若林神はいうまでもなくミンゴスまで苦笑いしつつもそれに乗っかるという流れのなかからの仁後ちゃんのこの発言は、重い*2。おれらも本気で付き合わんとなぁ。もとよりそのつもりだけど。長生きしよ……。

今日は食材の指定(指定とは)はとくになかったので、いつもの焼肉島津にて。現地組の一部も合流して実質的に新年会になった。今年もライブにゲームに楽しみましょう。

■ グラコロ同盟2019終了

明日から新メニューということで、公式に本日をもってグラコロ同盟2019は終了。前シーズン、トータルのカウントがだいぶ下がって、さすがにそろそろ飽きられてきたかなと思っていたら、今シーズン一気に持ち直して1000個超え*1、まーみんなよぅ食べたなぁ。おれはギリでTOP10に残れたけど、やっぱり職場近くに店舗がないのと、年末年始を挟まれると厳しい……。

サイトは一週間くらいこのままにして、あとはアーカイブしてまた休眠。来季に向けてもうちょっとメンテナンスしやすく改造したいし、そもそもhttpsにもしなきゃでやりたいことは少なくないんだけど、なかなか時間がとれないのだよなぁ。それにしても秘伝のタレみたいなコードで毎年よく動いてると感心する(おれにw)。

■ スマホを工場出荷状態にしたらストレージが13GBも空いた

2年以上同じスマホを使い続けていると、ストレージがどんどん足りなくなってきて「あぁ、もうそろそろストレージが倍くらいあるのに機種変しないと」とか思い始めるものだけど*1、実のいま使ってるアプリがそんなに容量を食ってるわけがない。いらないデータやキャッシュも消してるし。

おそらく、なにかの弾みで消え損ねたゴミファイルが残ってるんだろうなぁと思いつつ、根本的な対策をうつのが面倒で先延ばしにしていたら、とうとう「残り2%」という警告が出るようになってしまったので、意を決してやりましたよ、factory rest!!

reset前と後。どーん。

結果をみて思わず笑ってしまった。さすがにこんなに空くとは思ってなかった。もちろん後者は、元通りにアプリを入れて、それなりに使った(データが溜まった)状態の数字。どんだけゴミが溜まってたんだ*2。

最近のAndroidアプリはちゃんとOSのバックアップ機能に乗っかってくれるので、ほとんどのアプリは元の設定のまま復活してくれて、手間は最小限だった。一部の古い作りのアプリだけ明にバックアップを取ってやらないといけないのと、TwitterやSlackのようなかなりメジャーなアプリにそもそもバックアップという概念がなさそうなのがつらいけど。

そんなわけで、コイツももうしばらく延命できそうで良かった良かった。よくないけど。コンパクトなスマホのラインナップ、増えないかなぁ……。