最近のこと202409某日

Page content

2024年9月某日の最近のこと

スマホ買い替えた件

4.5年くらい使ってたiPhone 11だが、6~7月くらいから調子が悪くなり、「外でキャリア回線を引けない」状態になってしまった。もともと4G回線(笑)ではあるんだが、それをそもそも受信してくれない。WiFiオフにして機内モードにしたあと10秒くらい経ってから機内モード解除すると一瞬復活するが、そのあとまたすぐ死ぬ。この状態だと施設のWiFiにも繋げず、正直スマホとしての役割を全うできていない(いわゆる「文鎮」)状態で、家族と電話やLINEできないわPayPayで買い物できないわ(オフラインで50000円までは買い物可能ではあるが…)夜ランのときに音楽聴けないわ(何故か聴けるときもあったけど理由は不明)、日常生活に支障をきたすレベルで調子が悪くなった。多分SIMカードがイカれたかなんかだろうと思い、キャリアにお願いしてSIM交換して様子見というのも考えたんだが、どうせ遅かれ早かれ機種変更するんだろうしな、というわけで、どうせだから買い替えた。

機種変更先はiPhone 15(128GB)である。256GBは在庫がなかった。別にiPhoneにはそんなにハードディスクを求めてないのでこれで十分だ。iPhone 16を待つ気もない。(すぐほしかったので)移行は思ったよりスムーズに済み、大体1~2時間ですべて終わった。基本的に必要なモンはすべてクラウド上においてあるので「移行」って作業が必要になるものがあんまりないのだ。これはPC買い替えたときも同じこと思ったけど、便利な時代になったもんだ。やったことと言えば、必要なアプリ入れて認証済ませて終わり。以上。そんくらい。

強いて言うなら、InstagramやらLinkedInやらに再度ログインする際、多要素認証の都合で旧スマホ側のアプリで反応(アクセスの承認)をしなきゃいけなかったのが、ちょっと気になったくらいだな。旧スマホは下取りに出さず(そもそも4年以上使ってたiPhone 11など下取りにだせん)そのまま持ち帰ってるのでこういうことできたが、そうじゃない場合ここで詰む気がする。みんなそういう場合どうしてるんだろうというのが少し気になった。

あと今の所機会がないので問題起きていないが、ライブチケットのダウンロードがちゃんと動作するかが地味に気になっている。機種変更時点でチケットが当選済みのライブはイープラス、ローチケ、チケットぴあの3つ。それぞれ機種変更に関してはヘルプページが用意されている。

ぴあだけなんか特殊な条件付きで移行可能らしいが、基本的にはどれも 「チケットのダウンロードは機種変更後にしろ」(ダウンロードしたまま機種変更するな) というのが基本路線のようだ。機種変更時点でダウンロード済のチケットはなかったので、問題ないだろうと判断したが、このテのやつにはトラブルが付き物なのでちょっとドキドキ。ちゃんと動いてほしい。

総合的に見て、今の所使い勝手が大きく変わった感じはしない。機体の大きさもiPhone 11と同じくらいだし、画面表示や操作性も特に変わってない(これはiOS基準だからまあ当たり前か)。なので「機種変更した」っていう実感があまりない。単に使ってたスマホがきれいになった、くらいの感想である。唯一目に見える範囲での変更点でいうと、充電ケーブルの端子がLightningからType-Cに変わったことが挙げられる。ようやくLightningから卒業だ!…しかし会社スマホやらiPadやら家族のスマホやらは未だにLightning使ってるのでなんだかんだまだLighningに依存する生活が続きそうである。むしろ俺だけType-Cになったせいでケーブル事情が一時的に悪化しそうな雰囲気すらある。まあ今後長い目で見ればType-Cに全部変わっていく(Lightningが撲滅される)はずなので気長に待とうと思う。

本栖湖でSUPしてきた件

見出しの通りなのだが、8月の中旬ごろに家族で本栖湖にSUPしに行った。よく晴れてて水もきれいで、楽しかった。ちょっと体調が本調子ではなく100%本気で楽しめたってかんじでは残念ながらなかったのだが、SUPは面白いというのがわかった。また別の所で出来るならやってみたい。

洪庵キャンプ場の駐車場からとった本栖湖の風景

本栖湖の畔で息子が座り込んでいる様子

本栖湖でSUP中の息子がSUPボートにしゃがみこんで水面をのぞき込んでいる

本栖湖でSUP中の息子がSUPボートに立ってこっちにピースしている

本栖湖でSUP中の息子

本栖湖の湖面からの写真

おまけ:信玄餅パークで食った抹茶信玄餅ソフト
信玄餅パークで食った抹茶信玄餅ソフト

毎日バンT投稿が100日を突破した件

毎日バンT生活が100日を突破!ここに投稿してます。100日っていうマイルストーンにはそこまで強い意味はないのだが、キリがいいのでこの辺で振り返っておこうと思う。記録を保管しているローカルのフォルダのスクリーンショットは以下
毎日バンT記録フォルダの1日目~51日目のスクリーンショット
毎日バンT記録フォルダの51日目~10日目のスクリーンショット

100日突破時点の集計結果は以下。これは内部的にはCSVで管理している情報なので、それに対してawkコマンドで抽出して集計しているだけである。

> awk -F, '{count[$2]++} END {for (b in count) print count[b], b}' "history.csv" | sort -nr
40 ストレイテナー
17 Nothing's Carved In Stone
8 the HIATUS
6 ELLEGARDEN
6 9mm Parabellum Bullet
5 MONOEYES
4 フェス
4 その他
3 対バン
3 ACIDMAN
1 キツネツキ
1 THE LOW-ATUS
1 SpecialThanks
1 FULLARMOR

ここで書いた通りで、Pythonのライブラリ使って画像の類似性をチェックしているほか、目検もしており、なるべく毎日「被らない」ようにTシャツ選んでいる。その検査結果からすると、現時点で重複しているのは7月7日と8月12日のテナマニTのみで、他の日の重複はなく、少なくとも100枚以上はバンT・フェスT持っていることになる。他にもまだ着ていないバンドのTシャツがいくつかある(アジカン、マンウィズ等)のと、フェスT(CDJ、Japan Jam等)はあまり着てないので、まだもう少しの間は重複せずに投稿を続けられそうではあるが、さすがに今までと同数持ってるという感じはしない。まぁ、テナーやナッシングス等の主要な「推しバンド」に関して、今後新しいライブやツアーなどの分が増えてくる分も少なからずあるが、それでも爆発的に増えることはないだろう。このあと重複せずに投稿できたとして、いって多分+20~30枚くらいじゃないかなと思う。

そうこうしてるうちに半袖の季節が終わりそうなので(むしろ早く終わってほしいくらいだが…暑いのあきた)ロンT生活になりそうだが、ロンTは半袖ほど種類が多くないので、重複は増えてきそうな気はする。見てる感じ意外に種類あったので(20~30枚らい?かな)割といいところまで重複なしでいけるかもしれない。これは実際やってみないとわからない。秋・冬の動向が楽しみである。

ただ、「半袖のまだ着てない分」や「ロンT分」を含めて考えても、合計でざっくり200枚前後といったところになるので、そう考えると「意外に枚数持ってないんだな」というのが率直な感想で、まあ200枚前後っていうのを「多い」とみるか「少ない」とみるかは人にもよると思うんだが、この企画を始める前は漠然と「300~400枚くらいあるんじゃねえの」とか思ってたんだが、全然そんなことはなかったという結果に終わりそうで、人間のそういう「定性的な数値感覚」ってのは実際あんまりアテにならないんだなというのを改めて思い知ることができた。別に棚卸が目的ではなかったんだが、意図せずその目的も果たせてスッキリしている。こういう実験は面白い。

…を自動化したい件

ところで、この企画、人間の手(つーか俺)による手動運用が主になっており、特に「重複検査」の部分はできればもっとスムーズに自動化したいという気持ちになっている。「重複検査」にはそのついでに「Twitterへの投稿」が付きまとうので、自動化するならできればそこも含めたいんだが、こっちはTwitterのAPI改悪問題もあって、おそらく実装できない(後述)。まず「重複検査」だ。

「重複検査」に関しては、上に書いた通りで既存のPythonのプログラムはあるので、これをうまい具合に活用したいんだが、今はローカルのDocker上でpythonコマンド叩いて動かしてるのと、「既に着たTシャツの画像」をローカルDISK上に保存してそれと突合する形で検査を実行しているので、自動化する場合もその実行環境が必要になる。これが実際、結構厄介であり、例えばAWS上にその実行環境を作ることを想定する場合、EBSにTシャツ画像保存してそれをECSとかにマウント?みたいな話になって、なんかちょっと大掛かりになりかねないし、実際そんなことやりたいとは思わない。Tシャツ画像はS3に置いといて…みたいなのもできなくはないが、突合する際に毎回S3からダウンロードあるいは静的ホスティングしたS3にリクエストするとかしなければならなくなり、これはこれでイマイチな気がする(費用やらセキュリティやらで気にしなければならない点がほかにも出てくるのも厄介なポイント。)画像をBase64でエンコしてDBに保存し…みたいのも考えられるが、これもなんかちょっとな……う~~~ん。という感じ。

ただ、そもそも、現在のPythonの画像の類似性検査も、なんかちょっとイマイチな部分があり、これはバンドのTシャツのデザインによるところもあるが、「黒か白を基調にして、前面にでっかくバンドのロゴがプリントされている」っていうのが割と多くて、このパターンだとバンド跨ぎで複数類似性に引っかかってくることが多い。また、写真撮った時の部屋の明るさなどでも、色判定が微妙になることがあり、これにより例えば黒Tと青Tが「類似性あり」とみなされる場合がある。結果、「目検」に頼ってる部分が割と大きく、今の機械的な類似性検査には限界を感じている。このため、これをある程度のカテゴリに分割したうえでデータ化した方が、結果的に「重複の有無」を正しく検査できそう、という気になっている。(例えば「バンド」「色」くらいを主要なカテゴリとし、それ以外の付随情報をキーワードとして保持して、検索して画像表示するといった機能性である。)今はそっち方向でなんとか機能化できないか、検討中。

あとTwitterへの投稿の自動化に関して。単発のツイートの投稿は別にそんなに難しくないのだが、この企画は「最後のリプへのリプ」を続けているため、つまり「リプ」をしなければならない。リプ自体はin_reply_to_tweet_idを指定すればできなくはなさそうなんだが(参考、まだやってみたことはない)、毎日「リプ先のツイート」が変わるため、自動化するなら「最新のリプ」を取得する処理が必要になる。で、ここがネックで実現できそうにない。というのも、改悪後のTwitter APIのFree PlanはReadの権限をもってないため、正確には現状のAPIの権限では実施できないのだ。以前ちょっとやってみた感じ、この権限の話は、ハードリミットというよりソフトリミットの節があったので、やろうと思えばある程度はreadもできそうなんだが(試してない)、「プランで許可されてない操作してやがる。ナメんな!!」みたいに変に目を付けられてBANされたりすると厄介なので、仮にできるとしてもあまり試したくない。毎日「最新のリプのツイートID」を調べて手入力することを前提にすれば、「リプする」部分は自動化できそうだが、そこまでするなら最早ブラウザやスマホアプリでやる方が手間がかからないので、そこを機能化する意味は感じない。結論、この部分は計画倒れに終わりそうである。まあでもこの話の主眼はどちらかというと「重複検査」のほうにあるので、ツイートは機能化できなくてもまぁ仕方ないかなというところはある。

というわけでこういう機能をもったWebアプリでも作ろうかなーと計画しているのだが、面倒くさくて未着手。。。漫画描いてるほうが楽しかったりするし…ただ、他にもアプリ化したいネタはいくつかあるので、この辺総まとめにして一回どっかでアプリにしたいなーという感じ。「面倒くさいな…」って思ってるといつまで経っても動かないので、近いうち気合入れて動き始めたい。という気持ち。

毎週月曜日18時に投稿している自作漫画の宣伝ポストを色々見直した(これから追加で見直す)件

毎週月曜日の18時JSTに、Twitter・Bluesky・Misskeyに対して自作漫画RESIGN THREATの宣伝ポストを行っている。これはLambda(+Cloudwatchトリガー)で実行制御している。発端はこの記事にて。ここにも書いてある通り、基本的には、 「『TwitterのOAuth Tokenを10分ごとにリフレッシュする仕組み』を構築したにも関わらず、それを使うネタがなくなっちまったので、何かに利用したい」 という思いが発端であり、つまり技術的な要素の話が多くを占めており、漫画の宣伝はオマケに過ぎない(たまたま使えそうだったので採用した、というだけである)。そういうわけで基本的には「プログラミング遊び」の範疇で色々いじくったりして遊んでいる。ここで語るのもそういう系の話である。

  • Blueskyのほうがなぜか最近OGP画像読み込んでくれないな~とふと気づいて、ちょっと調査した。もしかしてOGP画像をリンクカードに設定するロジック(参考)が、なにかで意図せず機能しなくなったのかと疑い、BlueskyのAPIの仕様変更やライブラリのEOLなど、色々調べたのだが、別に疑われる要素なし。処理をデバッグしてみると、そもそもOGP画像がとれていないことが分かった。これ、実はこの前VercelからCloudflare Pagesに乗せ換えた際、MetadataでOGP画像の設定を忘れていたのだった。(twitter:imageは指定してたんだがog:imagesは未指定だった)なので、APIとかライブラリは全く無実だった。すまんぽ。とりあえず修正して動作したことを確認。終了。はい。
  • このポストに貼ってあるリンク、今まではリンク先をトップページにしていたが、これを「最新話へのリンク」に変えた。残念なことに、アクセス解析見ていると、トップページ見て第01話見てそこで終了、っていう人をちょいちょい見かけたからだ。これを最新話にしたら定着率とかがUPするかというとそうでもない気がするが、まあ最新話のほうが多少漫画としての質も上がっているだろうし第01話よりはマシなんじゃないかなという淡い希望によるものである。まあそれはともかく、「最新話」へのリンクを設定するにあたり、「今の最新は第何話なんだ」というのを取得する必要が出てきた。今まではトップページのURLを固定で書いておけばよかったのだが、それが「現在の最新話」に応じて動的に変化させなければいけなくなった。ここで、「今の最新話なに?」を単純に返却するAPIをWebサイト側に用意して、宣伝ポスト生成側でそのAPIをコールして、毎回「最新話のリンク」を動的に生成するように変えた。直近、9/23に動作確認完了(ちょっとミスがあったのだがw)。しばらくこの仕様で様子を見ようと思う。
    • ただこれ、今考えると、Webサイト側に、「最新話にリダイレクトさせる」ようなページを作って、宣伝ポスト側にはそのURLを固定で指定したほうがスマートだったかなと、今更ながら思い至った。これ以外で使う機会がなさそうなAPIを作って露出させるのもなんか意味がわからないし。宣伝ポスト側で余計な処理(APIコール)を一つ減らせるし。強いて言うなら強制リダイレクトのページ作っちゃうとSEO的に少し不利なところがあるかもしれないのが気にはなるところか。ただ、そもそもSEOでの流入なんぞほぼ皆無のこのサイトにそんなこと気にしても…という気がしないではない。う~ん。そういうわけでそのうちこの形で再修正するかもしれない。
    • それともう一つやってみたいのが、ページごとのOGP画像指定だ。Next.jsではページごとにMetadataを指定できるので、これを使って、各話毎に固有のOGP画像を指定するように改修したい。そっちの方がSNSでの見栄えはよくなるんじゃないだろうか?と少し期待している。新都社はマルチポスト禁止にしており、「作品の1/4までならOK」という厳しい規約があるので、TwitterとかのSNSに漫画を全編置けないのだ。こういうところで漫画作品としての様態をなるべく外側に見せられたらいいなあと思っている。OGP画像を用意しなきゃならないのでこっちは少し時間がかかるが、積極的に取り組みたい改修案の一つ。こっちは近いうちに実装したい。

別の漫画を描いてみたい件

今描いてるRESIGN THREATとは別の漫画を描きたいなーと思って、ちょいちょい構想を進めているんだが、イマイチ本格的に着手できないでいる。別にRESIGN THREATに飽きたとかそういうことではなく、そもそもRESIGN THREATを描くより前から、漫画化してみたいネタはいくつかあって、それを描いてみたいという思いはあったのだ。なんなら今すぐ描き始めてもいいんだけど、実際漫画描いてみてわかったんだが、漫画描くのって結構体力を使うので、「並行して複数作品描く」というような器用なことができるように思えない。なので、RESIGN THREATが終わってから着手、というほうがきれいなのだが、RESIGN THREATが思った以上に大掛かりな作品になってしまっており、今のペースだと完結させるまでに2~3年かかってしまいそうなので、さすがにそんなに寝かせるのもな…できるならもうちょっと早く描き始めたいな…という思いもあって、葛藤している。RESIGN THREATが大掛かりになってしまったというのは想定外で、こうならないように最初の段階でだいぶスリム化させたつもりだったんだが、これでもまだ壮大にはなってしまったようだ。これは漫画作品を仕上げるうえでの力量不足というところだろう。

それと、別の作品を描くにあたっては、できれば何か、RESIGN THREATとは違う作品の特徴を付けるようにしたい。具体的にはちゃんと「トーン」を使ってみたい。今は色付けにグレーの油彩とかべた塗ペン使ってるのだが、やはり出来上がりの色味?というか表現?が、一般的に「漫画」として見られるものとどこか微妙に違う。まあ読者からするとそんなところどうでもいいかもしれないが個人的には少し気になっているのだ。そして、こういうのの練習目的としてRESIGN THREATは最適であり、実際今までもRESIGN THREATを使って色々な描き方を試したりしてきたし、これからも練習用に使っていくつもりなんだが、そのため仮に別作品でトーンを使用するならRESIGN THREATで一度練習してから、というほうがいいと思っており、そういう意味でも「RESIGN THREATが終わってから」のほうがきれいな気もしている。RESIGN THREATは(漫画内でも描いてはいるが)「練習」として割り切ってる部分があり、これは結構いろんな実験をするうえで貴重な素材だったりしているのだ。

ただ、「描きたい」という欲求は本能的なもので、実際(強さは別にして)性欲とか食欲とかと本質的には同レベルだと思っており、抑え込んでいくとストレスになるもんだと思う。漫画に限った話じゃないのだが、「これ面白そうだ」「やってみたい!」と思ったことは、あれこれ頭で考えるよりとっとと手を動かしてしまったほうが(仮に失敗することになっても)結果的には早いことが多いので、こういうことに悩んでること自体時間の無駄だとは、頭では理解してはいるのだ。ただ、無駄に考えを巡らせる少ない脳みそがそれを妨害している。こうやってブログを描いていること自体も無駄な気も薄っすらしている。なのでまあ、上にあれこれとグダグダ描いたが、そんなのガン無視でそのうち別作品描き始めるかもしれない。

その他

  • Blueskyの1000万人記念キャンペーンで自分が何番目の登録ユーザーかわかるって企画があったのでやってみたのだが、987,960番目で上位10%のユーザー、とのことだった。ここに投稿してます。登録したのが2023年9月13日らしいのでもう1年経ったのかという感じ。時の流れの速さを感じる。そして1年たらずで900万人以上ユーザーが増えたということにも驚き。俺の場合は、ギリギリ招待制の最後の方で、なぜか偶然トークンもらえて始められたのだが、そのあと割とすぐに招待制が廃止されたので、そこからのユーザー流入がものすごい勢いだったということだな。すごいねー。
  • 知らなかったんだがThreadsがAPIの提供を開始していた。なんだよ教えてくれよ。。というわけでそのうち何かやるかもしれない。ただこれお膝元が天下のMeta様だからな…Instgram Graph APIが突然死した経験があるのでThreadsにも同じ匂いを感じずにはいられない…開発ドキュメントのスタイルもInstagram Graph APIと全く同じだしな(あたりまえだけど)。突然死したとき散々このドキュメント読み漁ってなお解決しなかった過去があるので、このドキュメントのスタイル個人的にいい思い出がないんだ。悪い。まあそんなわけでちょっと慎重に考えたいところ。技術的好奇心が勝って遅かれ早かれ手を出してしまいそうではあるがな…