#えむけーろぐ

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

近況

今月も月末ギリギリ更新だ!!!

blog.m6a.jp

2022年10月はこんな感じであった。

  • 新卒採用イベント参加 × 2
  • サバゲー × 2
  • コロナ感染

新卒採用

会社でエンジニア採用に関わっている。

事業に対するインパクトスケールを上げていくということで、担当チーム・プロダクト以外にも貢献していきましょうという話をマネージャーとしていて、まぁ手っ取り早く(?)広く貢献出来るものとして採用貢献をやってみている。

中途の面接自体は某スタートアップのA社で経験済なのだが、エンジニア志望の学生と会社の中の人としてお話してアトラクトするというのはそんなに経験が無いので良い経験だ。

また面接の方にも携わっていっているが、あの短い時間の中で人を見極めるというのはなかなか難しい。

あんまり数をこなしていない今の時点であんまり感想など書くと良くないので、少し経験を積んだらまた考えたことを書いたり話したりしてみようかなぁと思っている。

サバゲー

ブログで言及するのは初めてかも。実は今年2022年の7月くらいからサバゲーにハマっている。

夏は暑いので室内フィールド + ガスハンドガンで楽しみつつ、涼しくなってきたということで長物(いわゆるライフルタイプのもの)を購入してアウトドアフィールドにもチャレンジしてみた。

11月にも2回くらいはサバゲー行きたい。

コロナ感染

とうとう自分にも順番がまわってきた。

とはいえ幸い軽症で、デルタ株の頃に言われていた「入院するほどではないという意味では軽症だけど死ぬかと思った」というような感じもなく、症状的には風邪の延長、インフルエンザにでも罹患したときのような感じであった。

まぁワクチンを3回打っていることと、単に運が良かったということなのだろう。

その他

その他、なんだか仕事が忙しかったり、Podcastのサポーター向けSlackを開設したりという感じの10月であった。

 

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

このブログも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一覧に出てこなくなる。スッキリ。