見出し画像

かどで日記の技術の話#3「これから」(2022秋)

かどでプロジェクト公式note

技術の話中心です！！

バックエンドのこれから

機能追加もしたいところですが、リファクタリングを先にしたい所存です。
というのも開発から1年半が経ち、コードの秩序が崩れてきました……
機能を追加すると想定外の場所が壊れたりする可能性が増えてきます。
1年半前なんて初心者もいいところなコードの嵐です。
先に秩序のない世界に秩序を持たせる必要があります。

ということで、

リファクタリング

です！！！

具体的には

  1. 責務分割したコードにしてコードの見通しを上げる

  2. 外部から依存性を注入する

  3. Laravelのキューを使って時間のかかるタスクをバックグランドで行うようにする

  4. 単体テストを整備して事故を未然に防ぐ

欲を言えばクリーンアーキテクチャとかDDDとか憧れますが、まずは上記からです……

現状なんちゃってテストしか無く、500エラーで表示できない状態が起きていないかのチェックくらいしかできていません。

自分はとにかく単純ミスが多いのでテストやCIで本番環境までミスを連れて行かないようにする必要があります。
運用でカバーは絶対に事故るので……

これまでのリファクタリング

無駄なSQLクエリを消したり、データベースの構造を改善したり、古い書き方のPHPのコードを治したり、ファットなControllresからUsecaseをDIするActionsへの切り替えなど行ってきました。

でもまだリファクタリングすべき点は山積みです。

新機能

かどで日記の目的である「振り返りを楽しむ」を達成するために機能改修がまだまだ必要だと考えています。

  1. はじめてのユーザーのための案内

  2. エクスポートの種類増加(CSVだけでなくテキストやEPUBなども追加)

  3. 検索機能強化

などなど挙げれば切りがないほどClickUpの機能追加Todoにはやりたいことが詰まっています。

「エクスポートの種類増加」機能をここで挙げたのは個人開発ゆえにいつ終わるか分からないというユーザーの不安を減らすためです。
いつでも他へ移行できるようにエクスポート機能を充実させることで安心して使ってもらいたいという魂胆です。

面接で聞かれたことのある「PHPが使えない世界ではどうやってかどで日記実装する？」

とても悩ましい問題です。
脳内会議で度々脱PHPも挙げられる議題なのですが、結論PHPに戻ってきます。

正直なところ1つ外せない要素があります。

  1. 生きたフルスタックなフレームワークが揃っている

これはかどで日記の技術選定でもお話した「維持」の側面が大きいです。
全部自分で書くのはリスクが大きすぎます。
特に認証と認可。

もちろんORMへの不満があったりフルスタックなフレームワークが完璧でないことも分かります。
でもそのデメリットがあっても巨人の肩に乗るのが大きすぎるんですよ……

過去、認可制御不良のミスをしちゃったことがあります。
発行されるSQLにユーザーIDのWHEREを付け忘れて、唯一統計情報を生成していた自分の日記が他のユーザーにもSELECTされて見られる状態になっていました。
不幸中の幸いにも自分しか被害者いない訳ですが……このようなことが二度とあってはいけないので……
現在はLaravelのグローバルスコープという仕組みを用いて、ORMで呼び出す時に暗黙的に認証中のユーザーをWHEREするようにして、条件をつけ忘れても認可制御不良が絶対に起きないようにしています。

XSS攻撃やSQLインジェクション防げているのはフレームワークがよしなにしてくれる箇所が大きいです。

そういった意味でGolangを使うのはちょっとハードルが高いと感じています。
ですので「PHPが使えない世界ではどうやってかどで日記実装する？」への解答はRubyを使ったRailsによる開発と答えました。
(理想的な解答としてはモダンな言語のどの機能を使ってどうアーキテクチャを構成するかが言えると良かったのかもしれませんね……)

型が言語レベルでつよく書けたり、未定義変数にもエラー出してくれたり、暗黙的な型変換しない言語は魅力的です。
コードが人によって変わりにくい言語というのも複数人開発だと重要な要素です。個人開発なので「かどで日記」は問題ないのですが……

ちなみにPHPも型が書け、暗黙的な型変換もしないようにでき、静的解析で問題を見つけられてかなり上手く書ける言語です✌

フロントエンドのこれから

まずは兎にも角にも

仮想DOMの世界への移行

です！！

現在かどで日記ではLaravelのbladeテンプレートによる描画を行っています。
JSやCSSの合体はViteで爆速ビルドしていますが、そこ以外はサーバーサイドでHTMLを生成している形です。

当初の設計で仮想DOM系のフレームワークを用いなかった理由としては、フロントエンドの移り変わりが早すぎて長期維持が難しい点、技術力不足で断念した点の2つが大きいです。

前者の長期維持はたしかにその側面がある一方で、バックエンドとフロントエンドが密になっている状態で、逆にソースコードの見通しが悪くなる可能性がでており、長期維持が良くなっているとは言えないのです(必要十分条件じゃないみたいな……)
フロントとバックを分離することでバックエンド側だけの差し替えやフロントエンド側だけの差し替えが(技術的には)可能になり、柔軟性が増します。

とりわけNext.jsにおいては変化が落ち着いてきており(←本当かこれ)、10年を超える企業プロダクトでの採用事例も増えてきているため、そろそろ移行すべきなのかなと考えています。
ちょうど良いタイミングでNext.js 13もリリースされましたし…！

デザイン

仮想DOMへの移行のタイミングでデザインの刷新もする予定です。
現状のデザインは作成してから時間が経過しており、機能追加によるページや設定の増加に対応できていません。

またデザインとしても空間をうまく使えていない部分があるため、この機会に1から作り直しを検討しています。
デザインは固まってきました(このnoteのサムネイルがその一部)。

自然言語処理のこれから

山積みです……

リファクタリング(ファイル構成)

まず現状の最大の課題として、かどで日記の自然言語処理部分は1日記ごとに動作する訳でなく、指定したユーザーのすべての日記をまとめて処理するように作られています。

このようにしている原因は自然言語処理の重さに由来しています。
使用しているライブラリのクラスをインスタンス化するだけで相当重たい処理となり、1つ日記(数百文字)を解析するだけでも秒単位で時間を要します。

ですので現状はインスタンス化した後、ユーザーごとにまとめて未処理の日記を処理することで、初期化コストを削減しています。
またすでに統計情報を生成している日記は処理をスキップすることで無駄な処理を省いています。
そしてこれらが終わると解析した自然言語処理データを元に個別日記の処理、月ごとの日記の処理、年ごとの日記の処理、全体の日記の処理を行います。

これらはそれぞれ別ファイルで処理が書かれていますが、"ユーザーidを渡すとそのユーザーすべての個別日記の処理をするファイル"のように大枠でまとまっており、1日記だけ処理することはできません。

今後の見通しとしては1日記ごとに処理できるようにしたいというのがありますので、まず1日記ごとに処理が完結するファイル構成への移行が必要だと考えています。ファイル構成もですが、いかに軽くするかも課題です。

リファクタリング(脱DB,API化)

恐ろしいことですが、現状かどで日記ではPHPからもPythonからもDBへアクセスを行います。
マイクロサービスアーキテクチャとは反対を行き過ぎてますが、これも先の重たい処理という理由により、Python側でまとめてDBから日記を取り出して、まとめて処理してDBに書き込むことで重たい処理をメインの日記表示と切り離し、使用者の利用体験低下を防いでいます。

またAPIにせずOSコマンド呼び出しをPHPから行いPythonを動かすことで、プロセス間通信などでの認証認可の手間を省く便利さもあります。
さらに言うとコマンド引数に/dev/nullを渡すことでPHP側で自然に非同期処理ができるという強みも持ち合わせています……

ですがこれだとDBの構成を変更するとPHP側、Python側双方で処理の変更が必要になります。
さらにPython側ではORMを使わず直にSQLを書いており、より厄介な状況です。

そのため、Pythonでの自然言語処理はAPI経由で呼び出すように変更する大規模改修が必要だと考えます。
そのために

  • Python処理部分で日記ごとに単体実行できるよう構造を変更する

  • Python処理部分のDB依存の処理を無くす

  • Python処理部分にWebフレームワークを導入し、API呼び出しに対応する

  • Python処理部分を別のDockerコンテナに分離する

  • Pythonが動くAPIサーバーを構築する

  • APIに認証を備え、かどで日記本体からの実行を防ぐ

  • PHP処理部分でキューを実装し、待ちを伴う処理に対応する

  • PHP処理部分で統計情報をDBに格納する処理を実装する

とかなり長めのステップが必要です……

機能改修

自然言語処理自体はGiNZAライブラリのおかげでよしなになっているのですが、現状でも問題があります……(特に独自実装部分で)

1つ例を上げると「感情分析がゆるい」です。
具体的には否定に対応できていないなどが挙げられます。

例えば「強くない」と形容詞＋否定の場合
後者の否定を使わず形容詞の「強い」で感情極性辞書から探し、感情の数値化に使っています。
否定を加味しないため感情分析として正しい結果が望めない上、辞書ベースであるため必ずしも実情と一致しないことが挙げられます。
文脈によってはポジティブにもネガティブにもなる単語もあるため、現状の感情分析の手法そのものを見直す必要もありそうです。

他にも「日記のジャンル判定」の問題などもあり、改修すべき点も山積みです……

リファクタリング(アーキテクチャ)

各処理(固有表現抽出、感情数値化など)は既に分かれていますが、型やテストがなく、非常に扱いづらい状況です。

ときめき駆動開発で作った"アーキテクチャともいえない何か"からの脱却が必要です。

ここはバックエンドと同じ話にはなりますが、テストが書けるように責務分割したコードを書いていく必要がありそうです。

振り返りを楽しむ価値を提供するための機能

技術は手段でしかありません。現状の自然言語処理機能はおまけ程度でしか無く、正直1ユーザーとして"かどで日記の自然言語処理による機能"が役に立った記憶がありません……

  1. 検索への活用

  2. 日記閲覧時の活用

このどちらもができていないのです。
これらは要改善ポイントです……

インフラのこれから

かどで日記の技術の話#2「2022秋時点でのインフラ」でも触れていますが、「かどで日記」は現在かごやVPSを用いて運用しています。

VPSを契約して使うのは温かみがあります。
サーバーの名前だって付けれるんですよ？？？

でもそんな世界からも脱却しなきゃいけません。
今のインフラではユーザーの増加に限度があります。

VPSを選んでいる理由には

  1. 料金の変動がない(データ転送料金が掛からない)

  2. ある程度はスケールができる

  3. OS選びから好き勝手できる

があります。
1は学生なのであまりお金を掛けられない点が大きいのですが、3もかどで日記の構成上大きいです。

ですが1以外はDockerであったりですとか、そういったコンテナによる構成でも解決できるんですよ……
なので様子を見ながらどんどん現代風のインフラに仕上げていきたいです。
1に関してもインターンやアルバイトで少しずつ使えるお金は増えてきているので、あとは本人の技術力次第なのかもしれません。
初期のインフラ構築は毎度Notionで書いたドキュメントを元にやってますが、これを自動化できると快適ですのでIaCの世界も憧れます。

かどでプロジェクト全体のこれから

モバイルアプリ

日記サービスの多くはモバイルアプリのみの提供が多めです。Webでも見れるサービスもありますが、数えるほどしかありません。
日記の主戦場はモバイルであることを踏まえると新規でユーザーを増やしていくにはモバイルアプリ市場への参入が望まれます。

監視ツール

かどで日記のインフラを監視する仕組みを強化していきたい所存です。
重たい処理への対処やデータを外部に漏らさないためにも必要であると考えています。

現状はバックエンドのエラーログがSlackに飛んでくる&メインサーバーの稼働状況がAPI経由で確認できる程度の監視しかできていないので、Datadogを使ったNginxのログ解析とか、どんどん監視を強化して安全で快適なサービスを目指したいです。

かどでポータル

先日「かどでポータル」をオープンしました。これはかどで日記を始めとするかどでプロジェクト全体を統括するサイトを目指しています。
様々なサービスをユーザーとして使っていく中でブランディングってすごく大事だと感じています。
統一感のあるサービスを作っていきたいです。

作者が社会人になってから

バイト戦士の頃より可処分所得が増える可能性は高いので、ある程度趣味にもお金掛けられるのかなと考えています。そういった意味でインフラの強化をまずしたいですね……この世はクラウド時代……

さいごに

かどで日記は課題もやりたいことも山積みです。
ですがそれが私の開発継続のモチベーションとなっています。

他のサービスと比べて劣る点も多々ありますが、これからも「かどで日記」を好きになってもらえるように、日常に寄り添えるように頑張ります。

この記事が気に入ったらサポートをしてみませんか？