ろんぐさん最近何やってんの?遊んでんの?みたいに思われてそうですが、まぁ一応遅々としてやってはいます。まぁ胸を張って頑張っているとはいえないんですけど(笑)まぁいろいろ事情がありましてね・・・・・・。
言うて正常な人間のフリをしたうつ病患者ごっこを未だに続けていたりするので、重い身体に鞭打ってなんとかやんなきゃいけないわけですよ。
原因がはっきりしてる以上、別にカウンセリングとか受ける必要ないというか、それで救われるイメージも全く湧かないので、ただひたすらに頑張れば良いだけ、なんですけどね。
その根本的な原因を取り除きさえすればいいのにね、っていう。まぁそれができればこの2年間苦労してねえよなって感じはするのですが。まぁ分かってはもらえないはずですけど。
ただ、精神と肉体の不調を言い訳にしても事が進まないのは重々承知しているので、引きずってでもやるしかないのでございます。
ということで、最近は予約フォームと予約の変更などのロジックをぽちぽちと組み立ててはいます。
んで、一応さっき予約の変更までは完成したんですが、そこで
仕様のマズい点を見つけてしまったんですね。
・・・・・・一応解説しましょうか。
例えば、予約情報のテーブルはこんな感じにデータが入っているわけです。
で、重要なのが
host_tokenと
user_tokenという文字列カラムです。
これは何なのかっていうと、ホストとユーザーそれぞれに発行されるトークンで、予約情報へのアクセスに利用します。
なんでこういうことをしてるのかっていうと、メールから直にアクセスできるようにするためですね。
こういうメールが送られてくるんですが、このURLに用いています。このトークンを利用することで、ログインすることなしに予約の確認ができます。
このトークンはメールが覗き見されない限り本人以外に知られることはないので安全です。
さて、ここでこんな風に予約の変更画面を作ってみることにしました。
ユーザビリティを考慮して、変更前と差異があるところを強調することにしました。これを実装するために、新しく
change_beforeと
is_enableというカラムを用意することで対応しました。change_beforeは単純に変更前の予約IDを保持しておき、is_enableで、そのレコードが有効か否かってのを判定しています。
というのも、
変更は拒否されることもあるというのを仕組みとして取り入れているため、切り替えが必要になります。ホストはホテルじゃありませんので、予約の変更はあまり推奨はしていない感じにしています。
んで、こういう仕組みにした時、アクセストークンを含んだURLはどうなるでしょう。
ID変わっちゃうんだよね。
つまり
古いURLは使用不可になるんです。is_enableがfalse(つまり0)だったらそもそも取得できないようなロジックにしちゃったので。
確かに、
最新のものだけ使用可能にするという仕様にすれば解決はします。ただ、やっぱり
ユーザビリティ悪そうっていう印象がありますね。
予約の確認メールを保存しておいたけど、そこから予約の詳細が見れなくなってる・・・・・・とかだとやっぱうーんって感じなんですよ。
この課題を解決するために、いろいろ手段を考えてみます。
1.そもそもURLにIDを含めない。
2.古いURLにアクセスされた時、最新の情報まで飛ばす
3.DBを正規化する
4.URLはそのままだがIDを使わないロジックに組み替える
ざっと思いついたのがこれです。
1番の方法に関しては、まぁすっきりとした回答になります。トークンを共通化させたとしても、is_enableがtrueなのは常に1つだけというロジックのはずなので、辻褄は合います。
デメリットとしては
ロジックの作り直しが発生するといったところでしょうか。すっきりはしてますけどね。
2番の方法は、再帰的にchange_beforeカラムを検索していって、nullが返ってきた時が最新の情報のはずなのでそれを基にデータを作るというものです。
デメリットというか、採用しない理由は当然、明らかに無駄が多いからですね。将来性ゼロです。もう作り直せないという状況ならまだしも・・・・・・。
3番のDBの正規化は、「予約テーブル」と「変更テーブル」に分けてしまったらどうか、と。これならis_enableとか、
なんか臭うロジックも退避可能なのでは?って思ったんですけど、似たような構造を持つテーブルが2つあるのも、なんかなぁ、って感じですね。さらに正規化して「予約テーブル」「変更テーブル」「内容テーブル」といった、サロゲートペアって言うんでしたっけね。まぁそんな感じで管理したら無駄もないんですけど・・・・・・どうなんだろうなぁこれ。
あんまりスマートさを感じないのでこれもイヤです。
4番は1番と似たようなこと言ってますが、割と強引な案です。
URLはそのままで、トークンだけでなんとかするような処理にしちゃいましょう、と。ぶっちゃけトークンで重複が発生する可能性なんてほぼないに等しいですし、最悪重複チェックを入れれば済む話ではあります。
IDは一応値として受け取りますが、トークンを用いたwhere句で絞り込みを結局かけるので、IDを使う処理だけ間引けば実害はないんじゃないの!?というお話です。
んで、色々考えた結果1の案を採用しようかなって思い、
はぁ・・・・・・作り直しか・・・・・・。とげんなりしているのが今日、というわけです(笑)
仕様がガバガバなまま進めた僕が悪いんですけど、ちゃんと設計したら回避できたのかなぁ?どうだろう??って感じはします。
ただ、一回作ってみて、大体の処理の流れが分かってきたので、明日ちゃんと設計してみようかなーって考えてはいます。
寝ようとしたら、こんなツイートがTLに流れてきてね。
僕が同じ状況に遭遇した時、果たして止めに行くだろうかって思うと、たぶん止めないんですよね。
人が死ぬことはよくないことだ、ってみんな言うけど、どちらかというと「あっち側」の人間である僕は、この男性を"救った"ことに素直に賞賛を感じられない・・・・・・。
まず、絶望した人間の側の方から言わせてもらうと、まぁ自殺するほどの絶望に駆られる人は、「生きてること」に対する苦痛が「死への恐怖」を上回ったら死ぬし、そうでない、うわべだけの、そう、僕のような「うわべだけの自殺願望」持ちなら、どうせ放っておいてもためらうのはわかってるんですよね。
そして、本気で死にたいと願うほど、「生きてること」が苦痛なのであれば、もう解放してやれよ・・・・・・って思ってしまう。
残された人は後味が悪いかもしれない。迷惑かもしれない。
でも、じゃあ苦しんでいる人は我慢すればいいのか、と。そう思ってしまう。
「生きているということは幸せなことだ」なんて、「健常者」のエゴでしかない。僕はそれを、痛いほど知っている。
それでも、ホントは幸せになりたいから、もがくのだ。でも、もがいても、うまく行かなくて、もう全てを投げ捨てたい人もいるだろう。
生きているというその行為が、苦痛な時もままあるから。
もちろん、生死をもたもた彷徨う程度の絶望なのであれば、救ってあげた方が良いのかもなぁとか思うわけだよ。
でも、それがその人にとっての「救い」になるのかは分からない。でも、僕の中に「生からの解放」が「幸せ」という感情があるかぎり、答えは見えてこないだろうなあとは思うけど。
もうこの辺りの感覚が、世間一般からかけ離れ始めていることは自覚しているから、ツイートはしなかったけど。
どうして自分は、このような、なんだろう。「素晴らしい行動」を素直に賞賛できないのかな、って思った時、悲しい気持ちになる。
その人にとっての「幸せ」ってなんだろうなって考えちゃうとね。生きてることなんて別に幸せでもなんでもないし。ラクに死ねるのならそれで一番だと僕は今では思ってるよ。苦しくなくて、致死率100%ならさ。まぁそれがあったとしてすぐ実行はしないんだろうけど。
まぁそんな人間の気持ちなんて、世間一般には理解されないからね。僕らが変わるしかないのだ。
そんなことを考えていると、似たような状況に遭遇した時、どういうアクションを取ればいいのか分からなくなってしまうんだよね。
見てみぬフリをするのもムカつくけど、でも、エゴを振りかざして止めるのも違う気がする。苦しみを共有する者として、救いたいという気持ちはあるけど、それでも肩代わりできない苦しみも存在する。「友達になってくれ」はかなえられるけど、「借金を肩代わりしてくれ」という願いは叶えられない。
じゃあ放っておいてくれよ、って話になるのだ。
僕だって、例えばアレですよ、
「ろんぐさんにはかわいい彼女が見つかりますって^^(私はイヤだけど)」みたいなこと言われたら、普通に傷つくっていうか、
じゃあそんな傷を抉るような余計なこと言わないでくれる?って感じしちゃうもんね。
世の中は不条理が多すぎて、処理しきれないことなんてたくさんあるけど、僕はこういう問題に対する、ステキな回答が得られなくてつらいな。ほんとは、みんなに幸せになってほしいのだ。つらい気持ちのまま放置とか、したくないのだ。
でも、「見かけ上の正義」が幸せを生むとは、僕には到底思えないのだ・・・・・・。