Portfolio '22

Aya

Ayaは元ネタがなにかすら思い出せないが、Shrineを使った簡単なファイルアップローダー用のバックエンドだった。

およそ20コミット弱で完了しており、POST /api/v1/videosのみのほぼ単機能のアプリケーションである。

アップロード用のHTMLが付属していなかったのでPostmanで適当なビデオをアップロードしてみたところ、ファイルのアップロードは今でも問題なく機能した。

ffmpegthumbnailerというコマンドでアップロード後にサムネイルを生成してくれるような実装があったけれども特に生成はできていなかった。

あとからクライアント側のコードは別のリポジトリに分かれて見つかったのだが、フロントの画面は存在せずこのサーバーにファイルを送信するスクリプトだけだった。

このような作りかけのアプリケーションがたくさんあるのですべて紹介するわけにもいかないが、この頃は単機能のアプリケーションを作って満足していたようだ。

El Condor

El CondorはWebpackerの時代に作られたアプリケーションのようだ。

私はあまりWebpackerを利用していなかったので貴重ではあるが、Yarnのバージョンが変わったりトラブルはあったもののなんとか起動はした。

Genre、LocationそしてTransactionというモデルがあり、宿泊費や交通費を記録しておくための簡易的なアプリケーションであるようだった。

モチベーションが続かなかったのか、一覧画面と各モデルのフォームのみでそれ以上の実装はなかった。今でも少し手直しすればSwiftと組み合わせてモバイルで使えるようにしたり、月毎や年毎のチャートを表示しても面白いかもしれない。

スタイルシートはほとんど変更されていないものの、最低限のフォームだけれどもchoices.js、sortablejsそしてvanillajs-datepickerといったライブラリがインストールされていてむしろ普段のフォームよりも使いやすさは感じられた。

Gominohi

日本語のタイトルは「ごみ収集日検索」で、これはHerokuで動かすことを予定したためProcfileも存在していた。

もともとは市が定期的にごみの収集日のカレンダーを定期的に配布しているのだけれども、ブラウザで確認できたら便利だと思っていた。かつてSwiftの練習題材としても扱っていたが、今回はPCのみを対象にしていたみたいだ。

もともとオープンデータとしても回収日のデータはCSV形式でダウンロードできたがダウンロードしたファイルは2021年から2022年までのデータなので2024年現在ではこのアプリケーションの検索機能はヒットしなかった。

機能は主に3つあり、今日の日付をもとに収集品目が確認できる「収集日検索」。これは前日と翌日に遡ることも可能だった。2つめは収集品目から収集日を確認できる「逆引き検索」。3つめは「カレンダー」で1ヶ月分の収集品目が記載されている。こちらは市が配布しているものに近い。

カレンダーに関しては特定のライブラリを使わずにVanilla JSで実装していた。この実装をしたときちょうどカレンダーの作り方についてもブログに書いた記憶がある。

定期的にCSVファイルをダウンロードしたり、プッシュ通知やチャットに毎日投稿しようという計画もあったが、それ以上の実装はなかった。これは今でも十分使いみちがあるので、いずれ再開しようかと思う。

Akari

Akariは完全に記憶から忘れ去られていたが、プライストラッカーのようなアプリケーションだった。

このアプリケーションを作ろうと思ったモチベーションは全く覚えていないのだが、データベースに登録してある商品ページからRakeタスク経由でページをダウンロードしてその時の最安値と送料、在庫の目安などを記録するようなものを作ろうとしていたようだ。

残念ながら非常に簡素な一覧画面と、詳細画面しか存在しないので登録は手動で行わなければならないようだった。

サンプルで登録されていたPCケースはすでに手元にあるので、早々に目的を終えて開発も停滞してしまったのだろう。

コード量は少ないし、ライブラリもほとんど使っていないので直接このアプリケーションを流用することはないのだが、今後似たようなものをまた作ってもよいかもしれない。

Jordan

JordanはRailsをバックエンドとして、Create React Appをフロントにした私の中ではいわゆる典型的な構成のアプリケーションだった。

この当時はBulletproof Reactというリポジトリを知って、その構成に大きく影響を受けていたのでサーバー側の実装よりもフロント側のコミットが多かった。普段はRailsのみで開発することが多いのだが、この頃まではずっとReactとRailsの組み合わせで多かった。

このアプリケーションはStorybookを採用していて、フロント側のコンポーネントをChakra UIやMaterial UIといったライブラリは利用せずにEmotionのみでデザインしようという野心的な構成だった。今の私は普段CSSを0から書くことはまずない。

ただし動かしてみると単純なCRUDすらできておらず、一覧を取得してカードに画像とチェックボックスを表示するだけだった。

React Queryを採用しているし、ディレクトリ構成の理解に時間がかかっていたと思うのでいざ実装しようという段階まで続かなかったのかもしれない。もちろんそれまでも何度かReactを使ってアプリケーションのデプロイはしているのだが、これに関しては必要な作業量のわりにリソースが全く足りていないので今だったらもう少し小さいスコープで作業すると思うし、Storybookをたった一人でメンテナンスし続けることは今後も不可能に思う。

こういった反動もあっておそらく2023年はReactを使わなくなってしまったのだが、今考えると必然だったのかもしれない。

Nakayama

Nakayamaはそれぞれ4つのコンテナからなるアプリケーションである。

1. Cafe: Ruby on Railsでメインのバックエンド。
2. Dober: Reactのフロントエンド。
3. Elcondor: PDFKitでPDFファイルを作成する。
4. Jordan: 画像ファイルを扱う。

プロジェクトの名称が重複しているが、全く異なるアプリケーションである

これらのコンテナはすべてRabbitMQの軽量なメッセージキューでやり取りをしている。RabbitMQは普段使わず、それぞれのコンテナでRedisベースのSidekiqやBullを利用することが多かったのだけれども、RabbitMQはサーバー1つですべてやり取りできるのではと思っていた。

おそらく記憶の限りでは私がRabbitMQを採用したのはこれ以降もうない。

単純にRabbitMQのWebのUIに慣れていないというのもあるが、SidekiqやBullと比べるとデバッグがむずかしかった。今似たようなコンセプトのアプリケーションを作るのであればそもそもRubyとNode.jsを分けようとは思わないし、もしやるなら個々のコンテナSidekiqとBullを使ったほうがずっと作りやすいと思う。

またコンテナが4つもあるものだからサーバー間のやり取りを追うのが難しい。あとはconcurrentlyというツールを使って起動はわかりやすくしているのだが、それでも4つもコンテナがあると大変である。チーム開発ならマイクロサービスのI/Oを担保できると思うのだが、少なくとも個人で開発する場合はモノリシックな構成のほうが後から見返すにも理解しやすいと思う。