コードを書く前に

個人開発をしている時など、十分にイシューを検討せずに「とりあえずコードを書く」アプローチを採ってしまうことがある。

ビジネスでバリューを生む視点においてには、プログラマにとっては耳が痛いかもしれないが「コードは書いたら負け」な場合も往々にしてある(自分はこれを開発時の座右の銘の1つにしている)

 

以下は、かの有名な本「イシューよりはじめよ」に書いてあった名言だが、とても示唆深い。

フェルミは数学にも長けていた。必要とあれば複雑な数学を駆使することもできたが、まずはその必要があるかどうか確かめようとした。最小限の努力と数学的道具で結果へたどり着く達人だった。(ハンス・ベーテ)

 

コミュニケーション力の不足を補うために、知識で武装することでアイデンティティを確立する、みたいな心理に陥ってしまうのは良くない。

フェルミに到底追いつかないような僕らが、目的への最短ルートの検討を差し置いて知識を振りかざす資格があるだろうか?という問いを、頭の片隅に入れておきたい。

【AWS EC2+RDS】SDVXDBのランキング機能について

SDVXDBのランキング機能を実装した時のメモを書きます。

これはなに

一言でいうとゲーム(SDVX)の公式サイトのランキングに辿りつきづらいからアクセスしやすくしたよという機能です。

…これだけ見ると「辿り着きづらくてもランキングをブックマークすればいいのでは」と思われるかもしれませんが、なんとランキングのリンクのURLが毎日頻繁に変わるという謎仕様で、以前から(ごく)一部の層が不便していました。

需要は比較的ニッチですが、その一部の層には痒いところに手が届く機能であるのと、エンジニア観点だとAWS活用練習のいい機会だと感じたので実装してみました。

技術選定理由

EC2

当初はECS(Fargate)でやろうとしたが、コンテナ周辺の設定でエラーが発生しどうしても解決出来なかったため、実装優先でEC2に変更。

下記動画のように最近は仮想環境の利用よりコンテナ環境の利用にトレンドが移っており、コンテナで出来るならコンテナで作業した方が良かったのだろうが、AWSもインフラも初心者ということもあり、今回はEC2を選択した(後述する作業の観点でもDockerは非現実的だったので結果的にはそれで良かった)

↑タイトルはセンセーショナルですが、内容は参考になる動画です

さらにLambdaでランキング更新機能を作ろうとしたが、途中でGUIを用いないと実装が非常に煩わしくなってしまう場面が存在したので、GUIが使用できるEC2に変更(security managerのフリートマネージャという機能を使ってGUI操作を行っていました)

※ちなみに、Lambda+RDSはアンチパターンとして見られている模様(意図しない多重アクセスが発生してしまう)。途中にproxyという踏み台サーバーを経由してRDSにアクセスする、というのが現在のベストプラクティスな模様。

RDS

AWSのデータベースにはRDS以外にもDynamoDBAuroraがありますが、今回はRDSを選択しました。

理由としては、まずRDBを選択したかったのでRDSかAuroraとなり、更にAuroraよりRDSの方が一般的な印象(根拠が論理的でないですが)なので初学者としてはこちらを触った方がいい、という判断を経てRDSとなりました。

構成図

構成としては以下の通りです。

 

つまづいたところ

RDS

セキュリティグループ周り。特に「同一セキュリティグループ内」ではなく「対象となるセキュリティグループのインバウンドルールに、許可対象のIPアドレスを追加する」という点がつまずいた点だった。(EC2+RDSの場合はワンクリックで出来るので躓かないかもしれない。Lambda+RDSの場合は注意)

VPC周りがまだ理解できていない。ローカルPCやEC2からRDSへアクセスする時に何度かアクセス遮断され、この周辺設定がボトルネックになってしまった感じがある。

よかったところ

AWSを活用するのは初めてだったが、使い方の感触が掴めたので良かった。以前からAWSに対して抱いていた苦手意識が少し薄れた。

自分はインフラエンジニアではないのだが、実務でAWSを使うことがあれば料金やセキュリティ等はいっそう気を遣わないといけないなと思った(正直な所、そうした部分は性格的に苦手ではあるのだが)。

今回触ったAWSサービス群は、仕事のみならずプライベートでも活用機会が多そうなので、手に馴染ませていきたい。

 

プロダクトの観点からすると、そもそもKONAMIの公式サイトが毎日URLが変わる謎仕様を修正してくれればこれは実装の必要がない機能なんですけどね…(小声)

【WIP】SOUNDVOLTEX BPM DATABASE 開発メモ

コンセプト

非常にニッチなアプリケーションです。ジャストアイデアドリブン/技術ドリブンで作り始めました。

技術を用いるために作り始めたアプリケーションなので、ユーザー数については考えずKPI設定等もしていません。

別で運営しているプロダクトとしてボルテ空間がありますが、こちらは「SDVX初心者が楽しめボルテにのめり込めるきっかけとなるサイト」というコンセプトを元に、具体的にペルソナ像を想定し、需要ベースで作り一定のアクセス数を維持しております。

それとは対象的に、こちらは具体的なペルソナ像も詰めず、誰か使ってくれるだろう的に放置しております。

将来的な機能追加

ただそれだけだと勿体ないので、少しは需要を考えた機能を追加し、「ニッチであるがかゆいところに手が届く」アプリケーションにすべく機能追加を考慮しています。(タイトルもBPMに限定してしまった所に違和感があるので "SOUNDVOLTEX SONG DATABASE" に変更しようかと思っています)

曲ごとに譜面画像を載せ、小節ごとにコメントを載せられる機能も出来ればいいなと思っています(実現は難しそうなので、需要とコストと経験出来る技術のバランスを見つつ)。

技術

  • React(TypeScript)
  • Next.js
  • Firebase
  • Hasura
  • Fargate

で開発しています。

選定理由

React(TypeScript)

Reactは社会人1年目に業務で数ヶ月ほど使用したため基本的な機能には馴染んでいますが、バックエンド/インフラに関してはほぼ未経験で知見がなかったため、手っ取り早く実現出来そうなHasuraを用いました。

 

バリデーションにReact Hook Formを使用。YupやZod等のライブラリもあるがメリデメ調査もせずなので未導入

Fargate

開発過程

実務でリーダー業務を担った経験が無いのですが、プロジェクト管理の真似事を行う感じでタスクを管理しました。

普段用いているJootoというタスク管理ツールを用いて工数管理を行いました。

 

現時点ではかなり経験が浅いですが、いずれアプリケーションの開発をリードできる技量や度量を身に着けてゆきたい、というのがエンジニアとしての自分の当面のビジョンです。