  |
はてなキーワード: ロールバックとは
なぜ、街中でPK横行してないの？
鍵が見つかると IOI-xxxx が固めて入れなくなって競り合いになってる描写があった記憶
原作はAtariネタ乱発しすぎてウザいのでどこまで付き合ってやるかというトレードオフはあると思う
忘れたけど奨学金問題のように借金強制+強制労働のコンボは現実でも有り得なくはない
内部のセキュリティザル過ぎでは？
スラム爆破した後で死亡確認してなかったりAechの所在も風体も知らなかったりGoogleIOIはゆるふわなので仕方がない
天才創業者のプログラミングと高度なセキュリティと自律制御で無人運用されており誰にも手出しすることは不可能(鼻ﾎｼﾞ
sudoersに追記されてるはずだからロールバックでもしたらいいんじゃない(鼻ﾎｼﾞ
恐らく原作読むと色々な問題が氷解すると思うけどクィディッチ今昔を10冊くらい読破した気持ちになる出来なのでエンジョイして忘れるのがいいと思う 俺も見に行かないとなー
何度も何度もタイトルだけの定型文で出したり、PMを交代しろだの真摯に対応しろだの、無理に決まってんだろ。 全世界を相手にしてんだぞ。 ローカライズは日本でやってんだろうけど。
バカの一つ覚えみたいに改善を期待してアプデして文句言うだけじゃなくて、前環境へのロールバックぐらいしろよ。
win7とのデュアルブート環境だって簡単に作れるぞ。フリーソフトで。
何度も何度もクレーム送れば改善されるなんて思うなよクソ爺ども。 直っても礼の一つも言わねーっぽいし。
どこがどう見た目が悪いのか、ちゃんとそこだけキャプチャした画像でも送れよ。現状、派閥的な"おま環"みたく見えて意味不明だから。
ま、確かにupdateされるにつれて重くなってきてるけど。
先方「こういう機能作れる？」
俺「実現はできるけどその機能、使う手順間違えたら元に戻せない問題発生するから作らないほうがいいよ」
先方「大丈夫だいじょうぶ、機能使う人は特殊な訓練を受けた専門チームなので操作を間違えたりはしない！(キリッ」
後日
先方「操作間違えたよ…なんとかして！」
俺「間違えたら元に戻せないって言ったでしょ、もうどうにもならないよ」
先方「そこをなんとか！」
俺「…」
ってテンプレ展開を何度か経験してて自分の脳内で「ちんぽに負けないメソッド」って呼んでるんだけど
流石に他人にそれを言えないのでもっと他の人に言っても差し障りのない名称が無いか悩んでいる
自分で考えた中では「ルパンの予告状が来てお宝所有者が「警備は万全！ネズミ一匹侵入を許しませんわガハハ」って言う展開」がいちばん他の人にも伝わりやすいかなぁって思ってるけどどちょっと長すぎるのでもっと短くて説明しやすいやつが無いかなぁ
■初めに
■筆者について
にゃんこ大戦争で、タップジョイ（TapJoy）関係の無料ネコカン（※1）の受け取りが繰り返し実行（※2）される。
※2 発生トリガは複数り、タスクキル（アプリ再起動）で意図的に発生
iTune版「にゃんこ大戦争」Version 6.0.0 （配信日：2017年4月24日）
他プラットフォーム（Android、携帯版、3DS版、海外版）、他バージョンでは未発生
■不具合発生時期
Version 6.0.0の開発において、無料ネコカン関係の機能にデグレ（バグ）が発生
ただし、配信数日後から不具合顕在で、他トリガも存在と推測される。
＜推測１：サーバ説＞
無人管理状態に移行させるためのサーバ設定変更（TapJoy側・ポノス側のどちらかは不明）起因
サーバ設定ではなく、サーバからの配信データ（広告・インフォメーション（画面右上の○i）等）起因
② ネコカンに関する仕様に関し、会社間（ポノス・TapJoy）の情報共有が不十分
③ 社員休暇中のインシデント対応（特にインシデントレスポンス）が不十分
■今後の対処（例）
(1) 不具合事象抑制の暫定対処の実施。ネコカン増減関係の機能（ガチャ・統率力回復等）限定停止やサービス全体の一時停止など（緊急メンテ）
(2) 不具合解消バージョンの開発（Version 6.0.1）と配信。バージョンアップ実施はユーザ側選択となるので、6.0.0以前のバージョンは(1)による機能orサービス停止にてバージョンアップを促す。
(3) 不具合利用による意図的なネコカン増殖（線引きは11連×3回＝4,500ぐらいなど）実施ユーザに対してのBAN実施。BAN実施対象のうち、ロールバック同意者に対してロールバック実施（ロールバックデータを新規インストール＆データ引継機能）
(4) 不具合未発生ユーザへの不具合のお詫び実施（過去不具合以上が妥当、ネコカン30個×n倍 or プレチケ）
(5) 期間限定ネコカン7割引、プレチケ販売（数量上限3）、にゃんチケ販売（数量上限30）など、不具合のお詫び兼販売増の実施
(1)～(5)以外であっても、「傷口が広がるのを早期に止める」「ユーザの不公平感の軽減」「課金者のモチベーションダウンの抑制」「悪質行為への毅然とした対応」を希望
■最後に
長年楽しみ続けた「にゃんこ大戦争」が今回の件が「終わりの始まり」にはなってほしくありません。
自転車のマナーも、以前はそれなりの日本的秩序があったのだが、中国人やら韓国人やらが好き勝手やるようになった。それを見た日本人が、同じようにやるようになっていった。とくに若年層にとっては、当初からそういうものであり、状況の変化を知らないし疑問を抱いていない。
……というのは、俺の勝手な思い込みだ。4〜5年前から抱いている妄想だ。だが、こう思うようになったキッカケはある。ケータイ片手にピーチクパーチクと大陸語で通話しながら、信号も通行区分もお構いなしに自転車でゆくネーチャンを見てからだ。
赤信号みんなで渡ればなんとやらとか、ズルしたアイツが早く行けてるから自分もやらなきゃ損だ的な。そういうクソな気質が日本人にはあって、これは自転車に限らずいろんなところで感じるのだけれども。確たる根拠はないし、調べてみようって気にもならんので黙っていたが、道交法改正だってんで書いてみた。
今でもベトナムとかあっちのほうで見られるアジア的カオスな、日本が昭和に脱していたはずの交通事情。グローバル化はそこにロールバックしようとしている。
※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。
マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」
デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」
.... 略 ....
上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」
マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです！たぶん自分だけだったらこんなに時間かなりませんよ。」
デザイナ(「XHTMLになってない！」とか余計な所に口突っ込んできやがって！）
プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが！)
原因
マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない？」
プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」
マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ？」
マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」
.... 略 ....
プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」
マネージャ「ふざけんな！テストは今日で終わるスケジュールだろ！」
原因
プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」
マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」
マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」
マネージャ「古いフォルダからファイルをコピーすればいいだけだろ。馬鹿か」
.... 略 ....
デザイナ（間違ってファイル上書きしたのは黙っておこう）
プログラマ（ローカルにgitリポジトリあるのは黙っておこう）
原因
マネージャ「何このCodeIgniterっていうの？」
プログラマ「あ、それ最近流行ってるPHPのフレームワークで、URLのルーティングが…」
マネージャ「はぁ！？フレームワークとか使わないと開発できないわけ？これだから最近のゆとりはダメなんだよ。」
プログラマ「でも、便利ですよ？」
マネージャ「俺のプロジェクトではそういう怪しいやつは使わないから。バグがあったらお前責任取れるの？」
.... 略 ....
マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」
マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ？」
プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）
原因
運営は仕様変更など一切せずにずっと放置中だが、神運営と呼ぶ人もいる
そもそも仕様があまりに複雑かつ膨大すぎて未だに誰も完全には理解できていない
マップはとてつもなく広大だがプレイヤーが移動できる範囲はごく一部
時間は限られているが、特に決められたシナリオは存在しない謎仕様
あまりに自由度が高すぎて自分で何か目標を設定しないと何のためにプレイしてるのか分からなくなる
目標を定めレベルアップしてスキルを習得しても報われないバグが多い
しかし、コミュニケーションスキルだけはどんな場合も役に立つ最強スキルだが、プレイヤーによってはそれを習得すること自体が非常に厳しい
途中でつまらなくなってもデータをロールバックすることはできない
…という話がいつ出てくるのかと思っていたらリアルで割と同じ事が起こってるでござる。
PHPユーザー会の中の人とたまたま話したんだけど、アプリケーションのPHP5.2系からPHP5.3系への移行が滞っているようだ。
「業務でPHP5.3使ってますよー。」って言ったらむしろ驚かれた。どういうこった？
いま移行せずに、PHP5.3ってどうなるのよ？その先にあるPHP6系ってどうなるのよ？不安しかでてこない。
29才の男。こないだの続き。
結論から書く、12月25日の午前３時に俺は中国女と会話してクリスマスは終了した。少しロールバックしてみる。
メールをもらったのは12月の後半だった。前回フェイク入れたが実際の文面はこうだった。
「男さん、1*万で私を買ってくれませんか？」
おや、この子は地味なようでいてきわどい言い方をする、プレゼントはブランド物のカバンだろうか？
そのとき俺はそんな風に考えた。だが、つきあい初めから甘やかせると碌なことにならない、文面通りに答える。
「え、どうしたの？なにか相談なら乗るけど？」
そこで返信が途絶えた。一日置いて電話すると女が出た。
「どうした？」「いや、なんでもないです」声が暗い。
「なにかあったの？」「まぁちょっと・・・」「悩み事？」「まぁ・・・」「結構きつめの？」「まぁ」
「あのメールなんだけど、」「今度会ったときに話します。」「えっ？じゃあ・・・」「はい・・・」
女は本気っぽかった。会う予定を決めて電話を切った。
そういえば、女は「今は言えないけど○○なので、」みたいなメールを送ってくることが多かった。過去のメールを読み返してみる。
すると、風俗で有名でもある駅にいるだとか、副業バイトの面接予定だとか書いてきていたのを思い出した。
あれ？すべての謎が解けちゃったかもｗえ？冗談だろ？ｗｗ
空笑いした直後に脱力した。22日の昼に増田に書き込んでみた。
女は予定より早くやってきた。前日の夜、つまり増田に書き込んだ日の夜だった。
直接家に行くからと言われてたがなんとか駅前の喫茶店での待ち合わせに成功する。TSUTAYAに返却するものがあるからという言い訳でうまくいった。
静かな居酒屋に誘導して話を聞く。２杯目のお酒で口を割った女はこう言った。
「男さん。私、風俗で働こうと思ってます。」
は？意味がわからない。直感ではわかってたけど、いまいち実感がわかない。
「え？なんで？」「いろいろありまして」「いろいろって言ったっていろいろあるけど」「そうですね、いろいろありますね」
「ていうか、そんな子に見えなかったんだけど」「そうですね、仕方がないです」「なんで？理由があるの？」「まぁ、いろいろですね」
「いろいろじゃわかんねーだろ」「そうですね、いろいろありますから」「いや、だから・・・」「言えないんです。」
こんな感じで話は進まなかった。
このやりとりは省略するけど、3杯目を飲み終えた頃にようやく口を開いた。
父親の会社がうまくいってないこと、年末の運転資金がショートしていること、私の貯金を足してもあと数十万足りないこと。風俗に行く前に俺に買ってもらえばなんとかなると思ってついメールしてしまったこと。
「じゃあ、貸すよ。」というと人にお金を借りることだけはできないという。父親も人に借りたせいでこんなことになった、だからこそ借りれないらしい。参った、どう話せばいいかわからない。じゃあ、今持ってるブランド物のカバンとか財布とか服を売れば20万にはなるから売りなよ、と言ったら思い出があるので無理という。そんなこと言ってる場合じゃないだろと言ったけど全然話を聞いてくれない。長くなったのでここで切ります。
http://anond.hatelabo.jp/20070518032650
はいはい、徹底議論とか言う前にマニュアル読もうね。
MyISAM の場合
http://dev.mysql.com/doc/refman/4.1/ja/delete.html
MyISAM テーブルの場合、削除されたレコードはリンクされたリストに維持され、元のレコード位置が後続の INSERT 操作で再利用されます。使用されていないスペースを取り戻してファイルのサイズを削減するには、OPTIMIZE TABLE ステートメントまたは myisamchk ユーティリティを使用してテーブルを再編成します。
InnoDB の場合
http://dev.mysql.com/doc/refman/4.1/ja/innodb-file-space.html
削除されたレコードは、トランザクションロールバックまたは一貫した読み取りでそのレコードが必要なくなった後のパージ操作で初めて物理的に削除されることに留意してください。
