#えむけーろぐ

間違った事を書いていたらやさしく教えてください

何かを続けるということについて

このブログも2018年10月から毎月更新をしている*1ようで、今日の投稿を逃すとそれが途絶えてしまうということに気がつき慌てて更新している。

小さい頃からとにかく何かを続けるのが苦手だったし、今でもそうだと思っている。しかしながら、ここ数年は趣味のPodcastを筆頭に、個人開発やブログなど、なんとなく「何かを続ける」ということが出来るようになりつつあるのかなと思うようになってきた。

趣味で友人達とやっている「ゆるふわPodcast」は、2020年5月8日のEP26から今日時点でEP156まで2年4ヶ月も欠かさず毎週配信を継続することが出来ている。

yuru28.com

ブログも、まぁこうやってギリギリに書いているものだったり、「そもそもそれTwitterでいいんじゃねえの140文字以下だし」という記事を多分に含みつつも4年近く毎月更新をすることが出来ている。

そういうわけで、なぜ続けることが出来ているのか?ということについて考えを書いてみようと思う。

続けるの周期をゆるくする

いきなりしょぼいことを書いてしまうのだが、続けるの周期をゆるめにしてやれば良かったりする。

例えばこのブログがそうだ。偉そうに「4年近く毎月書いている!」なんて言っているが、毎週、毎日ブログを書いている人からしたらそんなのしょぼくて笑いが出てしまうことだろう。

実際、12月1日から25日まで一人(?)でブログを書き続ける一人アドベントカレンダーについては、2018年2019年はなんとか達成しつつもその後2020年2021年はエターナってしまっている。4年間毎月ブログ更新を続けて、2年半近く毎週Podcast更新を続けられる男が、たった25日間毎日ブログを更新することすら出来ないのだ。

でも記事を書くことそのものが仕事であるとかじゃない限り、ブログを更新する周期について人と競ったり厳しいノルマを課す必要なんて無いはずだ。なんとなく、「この内容が、このくらいの周期で、これだけ続けば自分的には続いてるって言えるな〜」と思えればそれで良いのだ。

続けるための仕組みをつくる

なんだか自己啓発っぽい見出しになってしまったが、続けるための仕組みをつくるのも重要だ。

Podcastに関しては、過去に勉強会で発表したこともあるのだけど、以下の3点を仕組み化して継続することが出来ている。

  • 収録を定期イベント化すること
  • 日々の情報収集の仕組みをつくること
  • 1エピソード30分以内に収めること
ゆるふわなPodcastのすすめ / kichijojipm-22 - Speaker Deckより

また業務で作ったイケてる仕組みとかでない限り、いや業務で作った仕組みですらたまにうまく動かないということは絶対にあるので、そうなった時にも破綻しない(=なんとか続けられる)ようにしておくことも大切だ。

プランBを考えよ、ということもあるが、それよりはもっとレベルが低い話で、例えばPodcastなんかでは「予定が合わなくても必ず決めた曜日時間にやる(欠員OKにする)」「誰も予定が合わなかったら一人回も辞さない」という割り切りをしていたりする。

気がついたら続いていた、という状態にしてみる

これはPodcastではなくブログの話になるのだが*2、ブログに関しては別に最初から毎月更新しようと思ってしたわけではない。

もちろんこうして月末に慌てて記事を書いているように、今は毎月更新しようとしてやっているものの、いつだったかに「あ、これ毎月更新してるじゃん」と気がつくまでは本当にナチュラルに毎月ブログを書いていた。

なにか思うところがあったりだとか、140文字以上だったり以下だったりのことを書きたいとなったときにブログを書いていたのだけど、それがたまたま1ヶ月周期で続いていたのだ。

なんだかこういう物事の続け方って理想的な気がしている。そういう状態になれるようなことがたくさんと言わずともいくつかあると、人生って豊かになるんでしょうね。

おわりに

もともと続けるのが苦手、とか根性がない、とかがある意味コンプレックスだったのだが、東京に出てきてからずっとお世話になっている坂上さん @madai0517 に「そんなことないよ、mkくんはブログにPodcastに色々と継続できてるじゃん!」と言っていただいてから少し自信がついてきた。「そうか〜たしかに考えてみれば色々続けられるようになってるな、自分」と思えるようになったのであった。

そういう気づきを与えてくれる人に恵まれたことに感謝しつつ、これからもいろいろきつくない程度に、楽しく何かを継続してやっていけたら良いなぁと思っています。

これで9月のノルマは達成です。

*1:Mediumにあるものも入れたらもっと長いかも。

*2:PodcastはEP26で毎週配信します宣言をした上でやっている

「ジョン・ウィリアムズ」ウインド・オーケストラ・コンサート

行ってきた。

prtimes.jp

今年の2月くらいにたまたまTwitterの広告に流れてきて一目惚れ。最近はTwitterの広告も良い仕事するようになってる。

ジョン・ウィリアムズはスターウォーズやハリーポッターなど有名な映画音楽の作曲家。コンサート内では他にもインディ・ジョーンズやジュラシックパーク、これは全く知らなかったけど11人のカウボーイという映画の曲も演奏されていた。

いやいやスターウォーズやハリーポッターはもともと好きなので約束された感動なのは当然として、他の映画音楽の演奏も大変よかったです。インディ・ジョーンズとジュラシックパーク、このコンサートに行くまでに観ようと思って観れてなかったんだけど、この気持ちが熱くノッているうちに観てしまおうと思う。

スターウォーズのメインテーマが流れたときは感動で泣きそうになった。鳥肌が立つっていうネットスラングがあって、本当は褒めるときに使うものじゃないらしいけど、あえて使うとまさに鳥肌モノだった。

 

オーケストラ・コンサートなんて小学校だか中学校だかの社会科見学以来なのだが、かなり楽しかった。

こういう、文化に触れて感情を動かすという経験はたまにしておくと良いですね。

Vue 3の素振り(Podcast管理画面 リプレイス)

はじめに

↓の続き。

blog.m6a.jp

プロフィールサイトを作って感覚を覚えたことだし、お次はユーザー認証やCRUD操作のあるアプリを作ってみようということで、趣味でやっているPodcastの管理画面をリプレイスしてみた。

できたもの

できたものはこんな感じ。

もともとRailsのMPAで作っていたものをコピーしただけなので特に代わり映えはない。

Vue 3でリプレースしたPodcast管理画面

SPAにしたので、エピソード公開時の体験は改善した気がする。エピソード一覧の画面描画時に /episodes を叩き、その後 /episodes/:id/publishing にPOSTする的な。

エピソード公開時の挙動

API: Rails

もともとRailsを使っていたので、APIはRailsで作った。

GraphQL APIを生やしても良いかなと思ったけど、そもそもPodcast画面をリプレイスする目的は仕事の技術で素振りすることだったので、仕事で使っているREST APIに。

2022年、RailsでREST APIを作るときの選択肢は色々あるけど、ひとまずRailsのController + jbuilderに。

デプロイ先: S3 + CloudFront

プロフィールサイトはVercelで作ったけど、こっちはS3 + CloudFrontに。仕事で云々、というのもあるのだけど、それ以上にVercelのProプランが20ドル/月とお高めだからというのがある。

一応無料のHobbyプランがあり十分使えるものであるものの、非営利の個人利用に限定されており、3人で有料サポータープログラムなんかも提供しているこのPodcastを商用ではないと言い張るのはフェアじゃないかなと。

さてS3へのデプロイはとてもかんたんで、GitHub Actions上でvite buildして出来た成果物(distディレクトリ以下のすべて)をs3 syncするだけ。

ブログ用

お恥ずかしながら、S3のバケットやCloudFrontの設定はAWSのWebコンソールでポチポチしました。本当はCDKとか使いたいネ……。

失敗

SPAやモバイルアプリ向けのWeb APIを作る上で考えなければいけないのが、ファイルアップロード。

S3にダイレクトアップロードするとか、ファイルアップロードがある画面のAPIだけmultipart/form-dataにするか、などいろいろあると思う。

めんどくさいのでBase 64エンコードしたMP3ファイルをJSONに詰めて送るようにしたら、無事Herokuのdynoがメモリ不足で落ちました(´・_・`)

20MB程度のMP3ファイルをBase 64エンコードしてJSONに詰めたらサーバーが落ちた様子

ちょっとした画像ファイルならともかく、20MB程度のMP3ファイルをボディに詰めるなんて無謀ですね。1リクエストで20MB相当のBase 64文字列がログにボンと流れる様子はなかなか爽快でした。

おわりに

仕事で作ってた社内向けアプリと並行してPodcastの管理画面を作っていたおかげで、プライベートの開発・仕事の開発それぞれで得た知見を双方向に適用出来てなかなか楽しかったです。良い勉強になりました。

とりあえずこの記事を公開したら、ファイルアップロードまわりをなんとかしよう……。

はてなブログのGA4対応

いつの間にかはてなブログがGA4対応していたので、設定した。

staff.hatenablog.com

さすがはてな社の解説記事だけあって、記事のとおりにやればかんたんに設定できた。追加のメタデータを送信してくれるのだが、そこはGA4上でカスタムディメンションの設定をしなければならないので注意。(これも上記記事に書いてある。)

ついでに、BigQueryにイベントデータを流す設定もしておいた。RedashからBigQueryにつなぎにいって、適当なクエリを書き、Zapier連携して毎日ブログがどれくらい読まれたかをメール送信する、なんてことができそう。

 

せっかくGA4を設定したのにこういうこと言うのもなんだけど、仕事でNext.jsを触ることになりそうなので、ブログを自作してみようかなぁという気持ちになっている。Podcastの画面を作るので忙しかった*1こと、Headless CMSでやるかCMSはRailsで自作するか迷っていることなどから、なかなか着手出来ていないのだが。

Vite + Vue 3でプロフィールサイトを再構築

はじめに

仕事でVite + Vue 3なアプリケーションを触るようになったので、素振りがてら個人のプロフィールサイトをその技術スタックで作ってみることに。

なお去年はNext.jsで同じことをやった。

blog.m6a.jp

Vite

結局これがなんなのかよくわかっていない。公式サイトによると「現代の Web プロジェクトのために、より速く無駄のない開発体験を提供することを目的としたビルドツール」とのこと。バイトと読んでしまいがちだがヴィートと読むらしい。

Vue専用ではなく、NuxtやらReactやらも選べるようだ。

npm create vite@latestしてやればあとはvueだのtypescriptだの選んでいい感じにプロジェクトのボイラープレートが完成する。

npm run devで開発サーバーを立ち上げれば、コードを書いていくだけで良い。

Vue 3

ReactやVueなんかのライブラリは生で使わずに、Next.jsやらNuxt.jsやらのフレームワークと合わせて使いたい派だったが、仕事で触っているものはVue 3をそのまま使っていたので合わせることに。

Vueは全然追いかけていなかったのだけど、Vue 2までは微妙だったTypeScriptのサポートや、いろんなコードが一つのファイル内でとっ散らかってしまうのが3では解消されているらしい。

Vue 2を全然知らないのと、Reactもそんなに得意ではないのであてにならない感想だが、<script setup>にゴニョゴニョロジックを書いて、そこで定義した変数を<template>で参照できたり、<style scoped>でそのファイル内だけに適用できるCSSを書けたり、という書き方をデフォルトで推奨してそうな感じは結構好きだった。

仲良くなれそうな気がする。

UIフレームワーク

2022年になって多少マシになってきたようなのだが、Vue 3に対応しているものが少ない印象だった。

Next.jsで使っていたChakra UIのVue 3対応版はまだまだalpha版、なんとなく聞いたことのあるVuetifyもalpha版……。

なんとなく聞いたことのあるElementUIのVue 3対応版とのことで、Element Plusというのを採用した。

element-plus.org

Chakra UIのときは、使いたいComponentをimportしてJSXに書いていく感じだったのだが、Element Plusは <el-container> やら <el-link> をimportもせずいきなり使えるので逆に違和感があった。(もちろん、main.tsというエントリポイント的なファイルで app.use(ElementPlus) するのだが)

 

正直この辺はよくわかってない。alphaだろうがなんだろうがチャレンジすべきと言われればそうだし、いやでも仕事の技術の素振りだからここでチャレンジしたいわけじゃないんだ、という言い訳だけしておく。

デプロイ

Next.jsのときと同様、Vercelを使った。

GitHubリポジトリを連携して、設定画面からViteを選べば終わり。

その他

/profile というURLを / にリダイレクトするのにvue-routerを使ったが、こいつをVercel上で使うには下記の参考記事の通り、ルートオブジェクトの指定を手動でしてやる必要があるようだった。Next.jsのときに躓かなかったのはVercelがよしなにやってくれていたからなのだろうな。

scrapbox.io

所感

出来たのはこれ。

m6a.jp

Vue文化圏のものは公式のガイドが丁寧でかつ日本語ドキュメントが豊富で良いなーと思った。

開発の体験もなかなか良い。ただこれはViteのおかげなのか、Vue 3のおかげなのか、はたまたVercelのおかげなのか。

一方で、ちょっと外れたことをやりたい時に出てくるWeb上の記事がReact前提だったりすることもあり、巣のJS力というかNode.js力というかが求められそうな感じがしている。

とりあえず今日はトップページ作っただけなのでまたこれから作品一覧ページとか諸事情で削った最新ブログエントリComponentとかを作り込んでいきたい。

GitHub ActionsのWorkflowをWeb UIから削除する

ちょっと試しに実行したりしたあと、ファイル削除したGitHub ActionsのWorkflowがいつまでもWeb上(リポジトリのActionsタブ)に残ってしまうのを消したい。

結論、そのワークフローに紐づくすべての実行履歴(Workflow run)を削除すれば良い。

削除したいWorkflowを開いて、すべてのworkflow runを削除する。たくさんあると大変そう。

すべてのworkflow runsの削除が完了すると、Workflows一覧に出てこなくなる。スッキリ。

 

ただの日記(免許更新、献血、映画、ゲーム)

ただの日記。Podcastで話そうと思うけど忘れそうなので。

 

2016年、高専5年生の夏に免許を取ってから6回目の誕生月。無事に無事故無違反でこれを迎えることが出来たので、優良運転者講習に行ってきた。

2019年の初回更新者講習のときは鮫洲まで行ったのだが、今はもう横浜市民なので二俣川へ。どこだよそれ。

www.police.pref.kanagawa.jp

鮫洲・調布などは置いておいて、こういう施設はだいたい変な場所にあるのが相場なもんだが、それでもなんでこんなところに……という感じだった。しかも、神奈川県全域をこの一箇所で受け持っているらしい。つまり、平日に地元の警察署に行けるとかそういう人でない限り、ほぼ東京な川崎に住んでいようが、ほぼ静岡な湯河原町に住んでいようが、みんな日曜の朝っぱらにこんなところまでこなきゃいけないというわけだ。

といろいろと文句を書いたけど、着いてから免許を受け取るまでの体験はなかなか良かった。役所も免許センターも選挙もワクチン接種も、有象無象の人間をいい感じに捌いていくオペレーションを考える人は本当に天才だと思うし、それを実際に回す現場の人たちもすごい。

前回の初回更新者講習は2時間で、事故の悲惨さを煽る系のビデオを見せられて気が滅入ってしまったものだったが、優良運転者講習は30分で15分のビデオを見た後に最近の道交法改正ダイジェストみたいな説明をされるだけで終わった。ビデオも若気の至りで人生大変なことに……系のものではなくむしろ「こっちがルールを守っていても路上はワンダーランドなので最悪相手がルール違反してきても対応できるような運転をしよう!」という話だった。

 

免許の更新が終わって少し時間があるなあと思っていたら、免許センターの目の前に献血ルームがあったので行ってみることに。免許の更新はだいたい半日〜1日潰す覚悟で来る人が多いと思うので、その目の前にセンターを献血ルームを作るというのは賢い戦略な気がする。

実は献血は初体験だったりする。高専にも献血バスが出張しに来ていたのだが、わりとひ弱なので血を抜かれるとすぐ体調悪くしてしまうかなぁという先入観 + 貧血疑惑(数年の時を経て貧血ではなく偏頭痛と判明)によりパスしていたのだった。

ちょっとくらい具合悪くなるかなと思ったけど、蓋を開けてみたら何の問題もなく。血も薄いのではなんて思ってたけど事前検査によると十分濃いらしい。健康に感謝。

タダジュース・タダお菓子やタダハーゲンダッツを頂いて、退散。どうやら献血ルームごとに色々と体験に差があるらしいので、また今度違うところに行ってみよう。

 

あとはまぁ先日公開されたファンタスティック・ビーストとダンブルドアの秘密を観に行ったり、夜に友人たちとゲームしたり、いろいろ。

ファンタスティック・ビーストはなんとなく3部作くらいで終わるのかなと思っていたが、ハリー・ポッター本編のように7〜8作くらいやるのかね?

 

休日ってだいたいひとつかふたつのことしかしないんだけど、今日は1日に4つも活動をしたので満足度が高く、わざわざ日記を書くに至ったのであった。