プログラマーですが何か?まだプログラマーですが何か?プログラマーネタとアスリートネタ中心。dotnsf誤解のないよう最初に書いておきますが、マンホールマップを始めとする僕個人が開発・運用するサービスを終了する予定がある、という意味・意図のコンテンツではありません。自分に万が一・・・なことがあったら現実問題としてユーザーに迷惑をかける形で終える形になってしまいそうだし、そろそろこういうのを気にする年齢になってきた(苦笑)ようで、同じような立場の人がいたら意見を聞きたいなあ、、とか、今はこう考えているんだけど間違ってたりしないかな、、という思いからこのブログエントリを書くことにしました。改めまして、約10年前から「知る人ぞ知る」という感じでマンホールマップという「自称世界最大の位置情報付きマンホール情報共有サービス」を運営しています。マニア向けに作ったものですが、マンホール蓋(特にデザイン性)に興味を持つ人がそこそこ増えつつあるようで、利用者からの情報を共有いただき続けています。マンホールマップ自体に利益を生む仕組みは(現在は)存在していないので、利益面に関してはプラスというよりはマイナスのサービスです。これまで色々運用形態を変えつつも、開発および運用はすべて自分一人で行っています。マンホールマップに投稿いただいた画像やテキストの著作権は投稿者にあるものと規定しています:「すべて自分一人で」の部分をより正確に表現すると「自分一人で開発・運用できる範囲でサービスを提供している」という言い方が正しいかもしれません。今後も安いネットサービスを探しつつ(笑)、細々と続けていく予定です。いう個人開発・運用サービスの場合、サービス提供開始後しばらくして「全く使われなくなる」ケースも少なからずあると思っています。使えばコストをかけずに利用状況の確認はできる時代になりました。その結果、自分以外ほぼ誰も使っていないことがわかれば、ある程度周知した上でサービスを止めてしまうことにそこまでの心理的な抵抗もないと思っています(自分の場合はこのケースが多くて、人気のないサービスを終了することへの抵抗はほぼありませんw)。そのようなサービスは本ブログエントリの対象外と考えています。その上で「個人開発・運用サービスをどうやって終わらせるべきか?」を考えました。話ですが、もし万が一、この後自分に何かがあってしまった場合、もうマンホールマップをメンテナンスできる人はいません。マンホールマップは現在はマルチクラウド上で機能ごとに稼働していますが、その(銀行口座が解約されたりして)契約が終了した時点でサーバーインスタンスも止まってしまいます。ユーザーデータを救うこともできないし、「こういう状況なので止まる前にバックアップを取ってください」と予め伝えることもできない可能性もあります。「保険がかかっていない状態」にあって、「自分が救いの手を差し伸べたい」という奇特な人がどこかに存在していたとしてもどうにもならなくなってしまう可能性すらあります。なることを避けて方法はないだろうか?と考え、3つ程案を出してみました。方法の1つは「家族や友人に託す」という方法です。これは(ケース・バイ・ケースですが、ある程度のコスト負担があることを理解した上で)そういうことを頼める家族や友人がいれば自分がやっていたように運用してもらえるのではないか、と期待しての方法です。厳密には開発ライセンスなどの権利問題を解決する必要もあり、よほど信頼できる相手と事前にそのような話し合いができていれば、という条件が付く方法です。#そういえばソースコードって相続の対象になるのかな??別の方法として「オープンソース化」も考えました。現在マンホールマップのソースコードは公開していません。上には存在しているので「多少の準備期間があれば公開」できないことはないです。ソースコードを公開することで、誰かが運用を引き継げる形だけはとっておく、というものです。この方法にも「既存データをどう扱うか」という問題点があります。ソースコードがあれば新たにマンホールマップサービスを立ち上げることはできるようになりますが、それまでに利用者から投稿いただいたデータが溜まっているデータベースにアクセスできるかどうかは別問題です。現行のマンホールマップのように僕の自宅内にデータベース・サーバーやバックアップ・サーバーがあるケースは厄介ですよね。手続き的に一番ハードルが低いと想像しているのが「法人化」です(実は大変なのかも・・)。要は個人のサービスではなく、法人のサービスという形にして、法人として(担当者が変わる形で)サービスの開発や運用を引き継ぐというものです。「法人化」が簡単だと思っているわけではありませんが、法人化されていれば別の人が引き継いでサービスを継続する上での権利的な問題は解決できると考えています。本格的に事業者する場合ははじめからこの形態なんでしょうけど、個人開発サービスでも法人化する意味はなくはないのでは、、と思うようになりました。最後が「自分がなんとかできるうちにサービスを終了する」方法です。別にお金に困っているわけでもなく、ユーザーの過疎化に悩まされているわけでもなく、でもどこかで見切りをつけてサービス終了を宣言して、各ユーザーに自分のデータだけでもバックアップしてもらう、という方法です。現実問題として、この場合の判断のタイミングは本当に難しく、いつどこで判断するかというのは正解のない決断に迫られることになると思っています。切羽詰まってサービス終了を考えているわけではないので急を要する事態ではないのですが、ただ最後のサービス終了決断以外はいずれの場合でも「ある程度のスキルを持った誰かに作業を引き継いでもらう(予めある程度の作業を教えて引き継げるようにしておく)必要がある」ことには変わりはありません。個人で興味本位から作り始めたサービスって、どういう形で終了を迎えるのが理想なんでしょうね。同じように個人開発サービスを運用されている方のご意見など、伺って参考にさせていただきたいです。なんかうまい方法ないんですかね。カスタムサービスとして登録し、利用するまで(正確には使用を終えてカスタムサービスから削除するところまで)の手順を紹介します。デプロイされて動いているものとします。以下の説明でのこのホスト名部分を実際にみなさんがデプロイしたホスト名に合わせて読み替えてください:まず最初に、以下で登録するカスタムサービスをバインドして動作確認するためのランタイムを用意しておきます。アプリケーションをプッシュします:https://github.com/dotnsf/phpEnv上記アプリケーション(index.php)はシンプルに「ランタイムサーバー上の全環境変数とその値を表示する」というアプリケーションです。プッシュ後にサーバーにアクセスすると以下のような画面になります。なっていることが確認できるはずです:ここまでで準備は完了です。カスタムサービスとして登録した上でインスタンス化し、このランタイムにバインドした上で、この環境変数がどのように変わるかを確認してみます。「サービスブローカー」(カスタムカタログのように理解してください)に登録しておく必要があります。found"(何も登録されていません)ですではサービスブローカーを新規に1つ作成します。値を指定します(詳しくは前回の記事参照)。"--space-scoped"(同一組織内のユーザーが使えるサービスとするための指定)を加えています。カスタムカタログに登録された状態になりました。同様にインスタンスを作成することができるようになっています。dotnsf-operation-service)を指定します。ランタイムにバインドしてみましょう。ランタイムの画面に移動し、接続タブの「既存に接続」をクリックします:現在利用中のサービスインスタンスの一覧が表示されます。いう名前のサービスが含まれているはずなので、これを選択して「接続」をクリックします。サービスが追加されていることを確認できます。情報として表示されていることが確認できるはずです:改めてランタイムのトップ画面にアクセス(リロード)します。情報が表示されているはずです。カスタムサービスを作成して、登録して、インスタンス化して、ランタイムとバインドして環境変数に反映させる、という一連の作業ができることを確認できました!最後に使い終わったサービスブローカーを削除する手順を紹介しておきます。サービスブローカー名このコマンドが成功すると、サービスブローカー一覧からも削除されます。カスタムサービスを作るために実装しないといけない内容や、実装後の登録方法などを紹介できたつもりです。しての登録を検討する場合に必要となる実装がどんなものかを説明しました。実装は必要になります。いったエコシステムを活性化する上での役立つ情報になれば幸いです。dotnsf前回の続きです。カスタムサービスとして利用できるように改良する、その改良内容を紹介します。);追加した箇所を赤で記載しています。サービスとして対応させる場合には少なくともこれだけの追加が必要になる、と理解してください。以下にそれぞれの内容を紹介します。2)以上でない場合はエラーとします。