きょうのつぶやき@digitune

きょうのつぶやき@digitune

ゼロダウンタイムデプロイを一般的に解くとこうなりますね。RT @ksato9700 DBの変更が絡まらなければこれでもいけるのかなー | Tomcat7 でゼロダウンタイムデプロイ - mallowlabsの備忘録 (id:mall… http://d.hatena.ne.jp/mallowlabs/20130315/tomcat7_zerodowntime_deploy (08:55 PlumeforAndroidから)

10年前に似たようなものを実装したときは、アプリのインターフェースとデータモデルを抽象化して、新セッションではなく新トランザクションから新しいクラスが利用されるようにしたっけ。あの時は確かフロントセッション側にはあまりデータは持たせず後ろに持つようにしてたからそれで大丈夫だった。 (09:01 PlumeforAndroidから)

後ろの人(当時HAOと呼んでいたが何の略だったは忘れてしまった)との通信は抽象化されててバージョンミスマッチが起きないような作り。今思うとかなり富豪的だなぁ(笑。ちなみにプロトコルはRMIだった。あの頃はRMI使いまくってたな。後ろの人は後ろの人でホットデプロイ出来る。 (09:06 PlumeforAndroidから)

ちなみにDBは後ろの人の中に完全に隠蔽されてて外からは見えない。DB更新を伴うときは、1)後ろの人を更新して新しいデータモデルに対応、2)前の人を更新して新データ投げ始める、という手順で更新していたのではなかったか。うーむ結構忘れてしまっているなぁ。 (09:10 PlumeforAndroidから)

今だとJSONを内部通信プロトコルとして使ってるようなイメージかな。RMIで実際オブジェクト投げまくってた訳で、JavaとJavaScriptの違いを除けば極めて似てる。まぁそれをJavaのような静的な型を持つ言語でやるといろいろ変態的になってしまうのだが…。 (09:15 PlumeforAndroidから)

ちなみに自分一人で作った訳じゃなくて、当時いろいろ教わっていたスーパーエンジニアな先輩と二人で、日夜そういう変態ワールドを構築していたのでした。その方はいわば僕の変態の師匠ですね＜をい。 (09:43 PlumeforAndroidから)

今日もおべんとうまかった。いつもありがとう。 (13:46 webから)