メッセージ。 - diary

まぁ、ああいうことが起こる生起確率というか、ハザードというものを考慮して、いまの設計になっているんだろうけど。しかし、ハザードを十分考慮して設計されているはずの原発があの調子なのだから、まぁ人間の見積もりというのは甘くなるものなのだ。そう考えて、低いレイヤのことも再考すべきときなんだろう。

ここ数日、書くことがない。あんな天災に比べれば、自分の考えることなんて、無為なことのように思われて、なかなか筆が進まない。

しっかし、ああいうことが起こるのを目の当たりにすると、普段しこしこ頑張っているセキュリティとか、やっぱ意味ないじゃんという気になる。というか、コンピュータのセキュリティとかは、ずいぶんレイヤの高い話なんだなきっと。そんな高いレイヤ、頑張らなくていいとは言わないけど、低いレイヤを十分頑張ったうえでないと意味がないということだ。

輪番停電の影響で、3月14日以降、15時〜22時の間はサービス停止になりそうです(自宅サーバーで運営しているため)。

いい天気！

もっともよい広告は、よい商品を作ることだ。と、強く思っている。しかし、よい商品さえ作っていれば、かってに商品が売れるのかといいうと、そうでもない。でもまぁ、まずはよい商品を作ること。というか、よい製品を作ること。よくみる間違いだけど、製品と商品は違う。その違いを見極めること。

今日はZaurusを持ってくるのを忘れた。

最近、Webを検索してても思ったような検索結果が出ないと感じることが増えたかもしれない。例のSQLの話もそうだし、使いやすい携帯の情報を探しても、あまり引っ掛からない。同じ問題で困っている人が、もっともっといるはずだと思うんだけどなぁ。

やっぱり1つには、人力検索のほうにシフトしているのかな？(ここではTwitterも人力検索に含む)たしかにいまだったら、一生懸命検索するより、Twitterで尋ねるほうが早いんじゃないかという気はする。

誤爆。

あ、でもアレなんだ。いま作っているものだと、予約完了したレコードが、その列車の何番目の購買なのか(何番目のinsertなのか)を知る必要があるのだった。どうすりゃこれを軽く実装できるのか。

そうか。idをシリアルで振っておいて、insertしたあとにcount(*) from table where id <= got_id;とかすればいいのか。

なんかイマイチ、DBMSを使ったソフトウェアの実装方法が、よく分からん。やりたいことは座席予約システムみたいな、リソースを取り合うような処理で、まぁよくあるシチュエーション。なおかつ、条件としては、複数のSQLの成功を保証する必要はない。つまりトランザクション不要。こういうとき自分は、insertを発行して成功したら処理を続け、失敗したらユーザに戻すか、失敗時処理を実行するようにしている。で、これでいいのかどうかがよく分からん。いや、あってるはずだとは思うのだが、こういうときの定石みたいのが、ググってもヒットしないのだ。トランザクションの話ばかり引っ掛かって、それ以前の話というか、基本の理屈を説明してくれてるページにたどり着けない。悪くいえば、「こうすればこうなる」的なものが多い。

あと、insertでの一意性保証方式だと、一意性が必要な要素ごとにテーブルを作らなければならなくて、これは不便だ。たとえば列車予約システムだと、ひかり105号、106号、107号と、列車ごとにテーブルを作らなきゃならなくなる。Oh!No!!!

今日はやけにキータッチに失敗する。あと、頭を使う内容を書いてるとき、打ち間違いが多くなってタイピングが遅くなる気がする。

あ、そうか。テーブル制約だっけ。あれを使えばいいのかな？

最近思ったんだけど、単純な消化項目のリストとかが目の前にあるとき、それを上から順に見ていくのが案外大事な気がする。というのも、上から順に見ていかないと、どこまでチェックしたか、分からなくなるから。「そんなん当たり前やん」とか「子供か！」って話だけど。しかし案外、いままでの自分はできていなかった気がするから。人間ってのはいま自分が何をやっているのか、どこへ向かおうとしているのか、すぐ忘れてしまう。不便な生き物だ。