トランザクションの終了。データベーストランザクションを確定させること。CVSでソースの更新をレポジトリに反映すること。e-Words関連する複数の処理を一つの処理単位としてまとめたもの。金融機関のコンピュータシステムにおける入出金処理のように、一連の作業を全体として一つの処理として管理するために用いる。トランザクションとして管理された処理は「すべて成功」か「すべて失敗」のいずれかであることが保証される。資金移動システムをコンピュータで処理する場合、出金処理と入金処理は「どちらも成功」か「どちらも失敗」のどちらかであることが要求される。「出金に成功して入金に失敗」すると、出金された資金が宙に浮いてしまうからである。このような場合に、出金と入金をまとめて1つのトランザクションとして管理し、どちらか一方が失敗したらもう片方も失敗させ、どちらも成功したときに初めて全体を成功と評価するのがトランザクション処理である。これを実現するシステムをTPモニタという。:何のことか判らなかったのだけど。出金のコマンドを送った後で、その「コミット通信」なるものを送らないと実際に処理がされないらしい。なると、トランザクション番号ってのはそのための一連の処理につける番号なんだろう。...単語の説明はともかく、手順ぐらいは資料に書いておいてほしかった。入出金時のレスポンス値について説明がなくて困ってたりもして。サーバが変な動作をしてたり、回線がおかしくなってたりして変な値が送られてたら、お客様のお金が大変なことになる。ならないための防止策として、アプリは「○○を△△して」と送り、サーバは「○○を△△するのか?」とレスポンス値を返し、アプリ側はその値を見て「よし、こちらの指示がちゃんと届いてる。OKや」と思ったらコミット通信をしてトランザクションとやらを終了する、という仕様にしてるのではないのかと想像するのだけど。どんな値が返ってくるのか不明では、アプリ側で対処ができない。おかしなことが起きてても、それを知る術がないから、問答無用でコミット通信を送るしかない。...なんでそのあたり書いてないのやと。これではアプリ制作者は「オラ知らね」モードで作るしかないではないか。よってガーベージを正しく回収できるかどうかをチェックする。アルゴリズム複雑なのだな...。場合、ブロック内で作った変数はスタック上に作られて(pushされて)、ブロックを抜けた段階で開放される(popされる)のであらうか。いう動作にはなってないとしたら、ブロック内で「どうせ一時的に使う変数だから」とガンガン変数を作ってるとメモリの断片化が起きて後になってから大きなメモリ領域を確保できなくなってしまう可能性があったりしないのかなと。あれば、どこかにグローバル変数でも作って、それを各ブロックで使いまわしたほうがよくなっちゃうかもしれない。オブジェクトはヒープにとられるとか、オート変数はスタックにとられるとか、そういう話もみかけた。あれば、ブロック内でガンガン変数を作っても大丈夫なのかな。:_@IT:チューニングのためのJavaVM講座(前編)「JavaVMはスタックマシン」という一文を見かけて検索したもののなんか違う話みたいで。DirectoryNameでいいのだろうか。コマンドラインで圧縮ツールを使ったことってあまりないのでよくわからなかったり。一応圧縮できてるように見える。iアプリの開発用フォルダを圧縮してバックアップ。17:221.再帰的に指定フォルダ内のフォルダも圧縮したい場合は、こうですね。..とすると良いでしょう。..「&&」なる書き方は知りませんでした。チラシをhtmlにしてほしいという要求がktから。自分、シングルタスクだからちと厳しいな...。HDDに溜まってたアニメを鑑賞と言っても作業しながらのBGVなので話はほとんど覚えてない。消化しておかないとHDD容量が...。貝の皿の回と、船に乗ってどこかに旅に出る回。して貝なのか、とか、どこに行くのか、とか、そのへんちゃんと見てないから知らないけど。朝鮮半島お得意の拉致行為!」と不遜なことを。...ギャグ担当のボディガードの人が、かなりカッコいいところを見せていてグー。いうギャップはベタでもいいから入れないと。アクションシーンの作画もかなり頑張ってるなと。お蝶婦人の回とツバメの回と巨大化の回と自販機の回と紺ガエルの必殺技の回。巨大化するというそのシチュエーションは、ウルトラマン等他作品においては高揚感のあるシーンなわけだけど、それが同じレイアウトで息もつかせず何度も出てくることによってギャグになり、他作品の真面目なイメージのソレもどこか付随して、類まれなる異常な展開になっていくあたりが秀逸。ウルトラマンから卒業したぐらい、な年齢の視聴者なら、TVの前で腹を抱えて笑い転げるのではなかろうかと想像。オチは予想がつくけど、ヒキは上手いなと。NANA、お金がない話と総集編。ドラムの人が登場する際、ドラムスティック?を持って現れるのが気になった。田舎から、ずっとスティックを持ったままで上京したのだろうか。周囲にとってはアレな人に見えそう。ドラマーだからドラムスティックを持って登場する、なら、プログラマーだったら絶えずキーボードを小脇に抱えて登場しないといかんことになるのか。あたりが適任アイテムかもしれぬ。小さいし、マニアックだし。「Linus...Linuxは、あんたが作ったOSだろ...」「ああ...心配で夜も眠れねえ...」とかそんな感じのやり取りになったり。...Linus氏はどんなキーボードを使ってるのか知りませんけど。村に入って嫌がられるところまで流した。あの世界では、侍と農民は結婚できるのだろうか。商人と農民は不釣合い云々と言ってたりもするので、なんだか見ていてモヤモヤ。サーバとの通信が全滅という報告が。...何がどう全滅なのか詳細情報はないので何が起きてるのかさっぱり推測できず。フラグを一つ用意して通信スルー版と本番の処理を切り替えて記述。とでもすれば、コンパイルの段階で、デバッグ用処理だけを残したり、逆に本番用処理だけを残したりできる。いう話を見かけたので、それを信じて記述してるのだけど。...いくらなんでもそのくらいの処理はしてくれてるのだろうなぁ。実はしてなかった、なんてことになったら泣く。そもそも、プリプロセッサがないのが、いや、eclipse上でプリプロセッサを通して作業するのがよーわからんのが問題。byte以下であること。動作確認のために記述を変えていたら、実機でのDL時に「ソフトに誤りがあります」と表示されてハマる。オーバーしてたのが原因だった。改行以外の文字数(セレクション対応)これで文字数カウントしてみたり。サーバとの通信エラーの原因について報告が。サーバから送られてくる文字列の最後に改行が入っていたらしい。アプリ側では、仕様書どおりの文字列が送られてくる場合は通信成功、それ以外は通信失敗として処理していたので、改行が入ってると「仕様書どおりじゃない」から通信失敗として扱ってたわけで。送られてきた文字列中に、区切り文字以外の制御コードが入っていたら除外するようにしてみた。sb.toString();こんな感じ。