仕事でやったことって記録に残すことがあまりなく、せいぜい職務経歴書にさらっと書く程度になってしまう。思い出せるようにポエム的な奴を描いてみることにする。
URL短縮機能とは
URLを短くする機能。以上。
だと説明が乱暴なので、どこかのメルマガで見かけたページを紹介。いくつかサービスもあるけど、ライセンスとか管理機能とか、なかなかニーズに合うものがなくて結局作ったんだけど。
URL短縮機能の実装が必要になった理由
当時のお仕事で相手にしていたサービスには、GoogleのURL短縮サービスを利用した「URL短縮機能」があった。まぁ、オフショアで作っているサービス(モジュール)であったのだが。
で、ある時、URL短縮サービスがエラーになるなぁと思ったら、程なくしてサービス終了のアナウンス。かなり利用されている機能なので、サービス終了とともに機能廃止!というわけにはいかない…のに、機能リクエストをオフショアに出している気配がない。どうするつもり?
URL短縮仕様を考える
どうしようもないタイミングになって「やって」と言われても困るので、やることにする。まずは仕様決め。
- 短縮した時の文字の長さを、GoogleのURL短縮サービスを使った時と同じにする。
提供していたサービスでは、同じメッセージを複数送れるようテンプレート機能が用意されていた。そのため、短縮した時の長さが変わってしまうとテンプレートから作った文面の長さも変わってしまう。文字数で課金されるSMSにとっては重要で、長くなるとカウントされる通数が増えてしまい、クレーム問題になりかねない。
- 日毎のアクセス数を短時間で算出できること。
提供していたサービスには短縮URLのアクセス件数を日毎に出す機能があったが、GoogleのURL短縮サービスlは累積のアクセス数しか取得できない。毎日アクセス数を取得して、前日分のデータとの差分を計算していたようだが、アクセス数取得には時間がかかり、半日経っても算出てきていないこともしばしば。顧客からの問い合わせが相次いでいた。
実装の仕様としては
- 短縮URLは、アルファベット大文字小文字+数字の62文字で構成する
- 大文字小文字を区別するよう、データベース(テーブル)を設定する
- 重複のチェックは、短縮URLを格納するカラムにユニーク制約をつければ実現できる
- 同じタイミングで短縮URLを生成しようとした時、異なる結果になるようにしたいから、生成ロジックに顧客IDを絡ませたい
- 同じURLを短縮させたいことがあるだろうから、生成ロジックに時間情報を絡ませたい
- 短縮URLを元に戻すプログラムと、URLの短縮やアクセス数を取得するプログラムは、ユーザーが異なることから別々のプログラムとする
- 短縮URLの長さと構成文字はわかっているから、それをウェブアプリケーションファイアウォールのルールに設定する
LとlとIの区別がしにくいとかあるものの、基本的に手打ちするものではないので、問題はない。構成する文字に記号も加えればより多くのURLを扱えることになるが、まぁ、それは足りなくなった時に検討すればよいだろう。
短縮URLへのアクセスが爆発的に増加することもあり得るので、必要な処理だけスケールアップできるように、独立したプログラムとした。
機能追加のリクエストは相手にしないのが重要
GoogleのURL短縮サービスではユーザーエージェント別の集計ができた?みたいで、機能追加を言ってきた人がいたけど、相手にしない。
提供しているサービスでは使っていないし、必要な機能だけを実装するのが堅牢なシステムにするコツだからだ。
そこは大人の対応で、「次のバージョンで検討します」として言って逃げる。そういった機能を追加する話は聞いていないし。使いもしない機能を要求する人はどこにでもいるので、仕様追加・変更的な話はマネージャーに回してしまうのが正解。この時はマネージャーからはなにも言われなかったから、思いつきで言っただけなんだろう。
調整はマネージャーに任せる
仕様を考えて、APIの仕様を決めたら説明資料を作り、オフショア先との調整はマネージャーに任せる。
「これが仕様です。問題があれば言ってください」
「大丈夫そうですか?では、これで作りますので」
プログラムを作ってインフラの設定をしてデプロイして…。やれるの、自分しかいなかったからしょうがない。
オフショア先での対応に結構時間がかかり、「こんなに急いで作らなくてもよかった Orz」という感じではあった。