  |
はてなキーワード: enumとは
同じ¥500が二つに分岐する瞬間がある。
松屋のカウンターで券売機のボタンを押す¥500。配信のチャット欄でスーパーチャットを送る¥500。前者は340kcalの熱量に変わり、胃に届き、数時間後に消える。後者は配信者の口から自分のハンドルネームが発声される3秒間に変わり、鼓膜に届き、数秒後に消える。
どちらの¥500も、使われた瞬間に消滅する。だが消滅の仕方が違う。牛丼の¥500は何に変わったか説明できる。スパチャの¥500は説明できない。
----
この説明不能性には技術的な根拠がある。スーパーチャットは感情を整数に変換するプロトコルだが、仕様にセマンティクスの定義がない。
SUPERCHAT_PACKET {
amount: uint32 // defined
message: utf8[] // defined
color: enum[7] // defined
intent: ??? // UNDEFINED
}
intentフィールドが未定義のまま本番に出た。¥10,000は「愛している」かもしれないし「暇で金がある」かもしれないし「このチャットを支配したい」かもしれない。プロトコルは区別しない。金額は意味の非可逆圧縮であり、復号アルゴリズムは存在しない。
牛丼にはこの問題がない。¥500＝並盛一杯。intentフィールドは「空腹の解消」でほぼ確定している。食欲は意味の不確定性を持たない。だから誰も牛丼を買う行為に怒らない。
投げ銭文化への反発は、金額が高いから起きるのではない。intentが未定義のまま可視化されるから起きる。¥500という数字が見えた瞬間、親密さに度量衡が発生し、度量衡を持った親密さは牛丼と比較可能になる。比較可能になったものは聖域ではない。「最初から聖域など無かった」という事実が、牛丼一杯分の数字で証明されてしまう。
----
1517年、ドミニコ会士ヨハン・テッツェルは贖宥状を売った。金を払えば煉獄の年数が短縮される。罪の赦しに値段がついた。マルティン・ルターは激怒した——恩寵に値段をつけるなと。
INDULGENCE v1.0 (1517) SUPERCHAT v2.0 (2017) medium: coin medium: JPY/USD message: prayer request message: utf8[] minister: priest minister: streamer grace: years_off_purgatory grace: seconds_of_recognition
パケット構造が同一であることは偶然ではない。どちらも「値段のつかないはずのもの」に値段をつけるプロトコルだからだ。テッツェルの贖宥状は神の恩寵を、スーパーチャットは人間の承認を、それぞれ通貨単位に変換する。そしてどちらのプロトコルにも、intentフィールドが未定義のまま残されている。
だがテッツェルの実装と現行のスーパーチャットの間には、一つの決定的な差異がある。テッツェルには料金表があった。身分と罪の重さに応じた価格が事前に定まっていた。スーパーチャットにはそれがない。「あなたが決めなさい」と言われる。会衆が自分で恩寵の値段を設定する。
歴史上のどの教会もこれをやらなかった。人間は自分の救済にいくら払うべきかを決められないからだ。
料金表の不在が、牛丼を度量衡として召喚する。公式の基準単位がない以上、会衆は自力で換算表を発明しなければならない。ある者は牛丼で測り、ある者は時給で測り、ある者は「推しの笑顔何秒分」で測る。全員が異なる度量衡を使って、同じ恩寵に値段をつけている。バベルの塔の崩壊後に、全員が異なる言語で同じ神に祈っているようなものだ。
そして隣の席の人が¥10,000を投げる。わたしは¥500。牛丼一杯分。わたしの信仰は隣人の20分の1なのか。この比較が可能になること自体が地獄である。テッツェルの料金表は残酷だったが、少なくとも比較の苦痛からは解放していた。全員が同じ表を見ていたから。
----
カトリック神学の核心に聖体変化（transubstantiation）がある。パンとワインの外見——偶有性——はそのままに、実体（substantia）がキリストの肉と血に変わる。見た目はパン。本質は神。
スーパーチャットでは逆の変容が起きている。¥500の偶有性は経済的取引そのものだ。通貨単位、決済システム、プラットフォーム手数料率30%。だが送信者にとっての実体は牛丼を離れている。それは承認の要求であり、匿名性からの脱出であり、ときに悲嘆の放送であり、ときに愛の宣言である。牛丼の偶有性を保持したまま、実体が非経済的な何かに変容している。
投げ銭批判者は偶有性を読む。「¥500は¥500だ。牛丼だ。取引だ。搾取だ。」
投げ銭擁護者は変容後の実体を体験している。「金額の問題じゃない。気持ちだ。」
聖体論争 (16世紀) カトリック（実体変化説）: 実体は変化し、偶有性は残る → パンは肉である ルター（共在説）: 実体は共存し、偶有性は残る → パンの中に肉がある ツヴィングリ（象徴説）: 実体は不変、偶有性も不変 → パンはパンを表すのみ 投げ銭論争 (21世紀) 送信者: 実体は変化し、¥500の偶有性は残る → ¥500は愛である 穏健派: 実体は金銭と共存する → ¥500の中に愛がある 批判者: 実体は不変、金は金のまま → ¥500は牛丼のままである
批判者のポジションはツヴィングリの象徴説と構造的に同型である。パンはパンだ。¥500は牛丼だ。そこに超越的な何かが宿ると信じるのは幻想にすぎないと。
だが配信者がハンドルネームを読み上げた瞬間、送信者の体に起きていること——心拍の微細な変化、ドーパミンの放出、名前を呼ばれたという事実の身体的登記——は、幻想では説明がつかない。何かが起きている。偶有性の内側で。だがそれが「何」であるかは、原理的に、外部から観測できない。
だからこの論争には決着がつかない。500年前と同じく。
----
配信者は司祭職を選んでいない。プラットフォームが収益化を有効にした瞬間、叙任が起きた。ダッシュボードの「収益化」トグルをONにすること、それがこの時代の按手礼である。テッツェルは少なくとも自分が贖宥状を売っていることを知っていた。現代の司祭たちにはその自覚がない。彼らは読み上げという秘跡の執行を通じて承認という恩寵を発行している。Ex opere operato——事効的に。執行者の内面に関係なく、プロトコルが走れば恩寵は発行される。
会衆の側でも制度化は進む。常連が生まれ、ハンドルネームが記憶され、内輪の典礼が形成される。奉仕（切り抜き、ファンアート）がある。教義（推し文化のコード）がある。異端審問がある（「あいつはガチ恋勢だ」）。破門がある（BAN）。殉教者がいる（炎上して垢消しした古参）。
投げ銭文化への反発が最も激しくなる瞬間は、金額が高い時ではない。コミュニティが自分たちを教会だと気づきかけた時だ。気づきかけて、その認識を拒否する力が反発として噴出する。「いや、これはただの趣味だ」「推しているだけだ」「宗教じゃない」。否認の強度がそのまま、構造的同型性の証拠になっている。
初期キリスト教の信者たちも自分たちを「教会」とは呼ばなかった。エクレシア——集会——と呼んだ。ただの集まりだと。
----
¥500が牛丼でありかつ愛であるという命題は、パンが小麦粉でありかつ神の肉体であるという命題と同じ構造を持ち、同じ検証不能性を持つ。スーパーチャットのintentフィールドは未定義のままであり、聖体の実体が変化したかどうかを外部から観測する手段は存在せず、料金表は永遠に再発行されない。
この不確定性は投げ銭に固有のものではない。すべての価格決定に潜んでいる。ただ、スーパーチャットの¥500はそれを素手で触れるほど近くに引き寄せた。牛丼一杯という、誰にでも分かる度量衡を使って。
できないまま、¥500は今日も飛ぶ。松屋に向かう¥500と、チャット欄に向かう¥500。同じ硬貨の表と裏のように。片方はカロリーに変わり、片方はintent未定義のまま、どこかの配信者の唇を通過して、消える。
タスクタイプのENUMとタスク内容のStringと日付をDBに保存するコマンドプログラムを書いて タスク内容はタスクタイプによっては固定になる場合と任意のStringの場合がある
これで下のようなものが出たがENUM側に持たせてるので言い方の問題だと思うよ
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.println("Task type:");
for (TaskType type : TaskType.values()) {
System.out.println("- " + type.name());
}
TaskType taskType = TaskType.valueOf(scanner.nextLine().trim());
if (taskType.hasFixedContent()) {
taskContent = taskType.getFixedContent();
System.out.println("Task content fixed as: " + taskContent);
} else {
System.out.print("Enter task content: ");
taskContent = scanner.nextLine();
}
System.out.print("Enter task date (yyyy-MM-dd): ");
LocalDate taskDate = LocalDate.parse(scanner.nextLine());
Task task = new Task(taskType, taskContent, taskDate);
System.out.println("Task saved successfully.");
}
}
DAILY_REPORT("Daily report submission"),
MEETING(null),
MAINTENANCE("System maintenance task");
private final String fixedContent;
TaskType(String fixedContent) {
this.fixedContent = fixedContent;
}
public boolean hasFixedContent() {
return fixedContent != null;
}
public String getFixedContent() {
return fixedContent;
}
}
プログラミング言語のＣ＋＋に暫く離れていたが便利そうな機能が出来ていたんですね。
自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。
異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。
武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、
鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。
このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい
例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。
std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。
メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。
スマートポインタは前からあったが現在の推奨はstd::unique_ptr
(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)
列挙クラス
列挙型だが従来の列挙型と異なり変数名が外部と衝突しない
nodiscard属性が付いている関数は戻り値の受け取りが必須となる。
ちなみにstd::optional＜std::string＞ obj;のように＜＞内に書かれているのは昔からあったテンプレート機能のようです。
拡張子については、例えば Excel の拡張子が変わったとき一括対応できる、とか？
あとは普通に".txt" で取り扱ってるファイルはどれだ、って時にその定数の参照箇所を見ればもれなく分かるとか、
取り扱うファイルの種別を段階的に変えようってときも、どのファイルは変え終わっててどのファイルはまだ、とかも同じように分かる
あとはあれだ、どのスコープにおける分類なんだって話を明確にする事も出来るだろうな。
とか。
パラメータについては、複数の選択肢から選ぶ奴は enum にしろよ、とは思うが、
文字コードも大体同じような話か。
ここに定義したもの以外は登場しないよ、という保証をする事は出来るわな。
自分には6年付き合った年上の彼女がいた。名前はPHP。学生の時からの付き合いで、自分にとっては初めての彼女だった。付き合った当初は全てが新鮮で、オブジェクト指向やSOLID原則、大事なことは全て彼女から教えてもらった。（そう思われるかもしれないが、）時間が経って彼女の魅力が感じられなくなってしまったということはなくて、彼女は歳をとっても魅力的なままだった。むしろreodonlyプロパティやEnum、null safe演算子など、新しい機能が導入されてますます綺麗になっていったように思う。最近ではジェネリクスさえ導入されたようだ。彼女は本当に努力家だ。
（褒められた話ではないが一応、彼女以外の女性を全く知らなかったわけではなく、TypeScriptという若い子と少し遊んでいたこともある。TypeScriptは昔からの知り合いのJavaScriptの妹で、大雑把な姉と違って几帳面で、少しオタク気質もある個性的な子だった。よく新しい型パズルを考案して楽しそうに話してくれたが、自分には正直よく分からなかった笑。）
そんな中でも基本的には6年間PHPとずっと一緒に過ごしてきた。前述の通り彼女に何か不満があったわけではない。ただ、彼女との将来に不安を覚えるようになってしまっていた。周囲に彼女と付き合っていることを話すと、「え、まだPHPと付き合ってたんだ？（昔は人気だったけど、最近はそうでもないよね）」みたいなことを、彼女のことをよく知らない人から言われたりもした。そこまで直接的ではなかったけれど。自分も、彼女以外の女性のことをほとんど知らずにずっと彼女と付き合っていて大丈夫なのかななんて思ってしまったりしていた。
結局自分はPHPと別れて、新しい女性と付き合う決断をした。新しい彼女の名前はGo。彼女は若いのに自分の芯がしっかりしていて、みんなの憧れの格好良い女性といった人だった。そんな彼女と付き合いだして、最初は戸惑うことも多かった。
例えばこんな感じだ。
また、今まで当たり前だと思っていたPHPの良さに気づくことも多い。PHPStanを使えば静的型付け言語と同じように型安全性を担保できていたし、彼女のWeb FWには歴史が長いだけあって痒いところまで手が届く様々な機能が完備されていた。経験豊富でこちらの要望をなんでも受け止めてくれるような包容力があったことに今更気づいた。
とはいえ、いつまでも昔の彼女を引きずっていてもしょうがない。Goにはこちらに積極的に合わせてくれるような包容力はないが、彼女なりの哲学を持っていてそれ故の美しさがあると思う。そして正直、まだ彼女の10分の1も理解できていない。彼女が得意だという並行処理や、実行速度が求められるような処理も、自分はまだ実際に実装したことはない。でもこれからしっかり向き合って、Goのことをもっと理解して、実りのある交際にしていきたいと考えている。PHPと別れてGoと付き合う決断したのは自分なのだから。
時は金なりという意味か？
public class Person { BasicInfo info; float stock; float Value; public string Name(bool isSpy){ return isSpy ? info.Name : info.Name.ToSecondName(); } public string Sex(bool isNormal){ return isNormal == info.isMan ? "Man" : "Woman"; } public float Earn(bool isExtra = false){ float sexPad = info.isMan ? 1f : 0.5f; float racePad = info.isWhite ? 1f : 0.5f; var delta = DateTime.Now - info.Birth; int age = (int)(delta.TotalDays / 365); float result = Value * sexPad * racePad * age; if(isExtra){ Value += result; } return result; } enum Race{ White, Black, Yellow }; class BasicInfo{ public string Name; public int NationalId; public bool isWhite; public bool isMan; public DateTime Birth; public BasicInfo(string Name, int NationalId, Race race, bool isMan){ this.Name = Name; this.NationalId = NationalId; this.isWhite = race == Race.White; this.isMan = isMan; Birth = DateTime.Now; } }
おう！外部キー制約を語るとは、RDB を勉強しているのだな？いい心がけだ。増田は外部キー制約があると「どんなメリットがあるか知りたい」のだな？良し、答えてやろう！外部キー制約があると「変なデータが入らない」ということが開発者が『保証』できるのだ。うん、それで？って増田は思うだろう。それで、実例を挙げるけど、sex というカラムを create で作ったときに、そこに insert into で入る値が「男」「女」「その他」というデータに限りたいときが設計者にあったとする。そうすると、「 insert するのは『チンポ』でしょ？」みたいなアホを防げるだろ？もちろん、limit みたいな副クエリで実装しても構わない場合もある。型を指定して、boolean にしたい場合もある。だが、「入るのはこれだけだと思うが、後に追加で変更できる」としたら、嬉しい場合があるのじゃ。まぁ、究極的に OOP や関数型言語、または（古い）命令形言語だと、enum みたいなものなんだよ。いや、だとしたら、enum でよくね？って思うのなら、リプライくれ。答えるから。
言語によると思う
javaなら普通にオブジェクトでEnumを継承したインスタンスになるからその分メモリ使うし、enum内部で結局String持ってる（コンパイラがStringをEnumの子クラスのコンストラクタに渡す）からStringの方がリソースは無駄にならない
プログラマなんだけど、なんでも揃えようとしてる人がうざい
よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「＝＞」みたいなのの位置
揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒
10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする
面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい
だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たときに結構大きな変更してるように見えたりするからちょっとイヤ
さらに grep かけようにも空白数が不定だから正規表現にしないといけない
んだけど、まあここまでは別にいい
この揃えるときに
aaa : { bbbb : 100 ccccc: 200 }, dddd : { e: : 300 }
みたいに（フォントによっては揃ってなく見えるかも）、ネストが違うのに全部を揃えようとするの、ホントやめろ
わかりづらい
上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい
上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄
bbbb と ccccc みたいなときだけならまあ許せる
仏の顔も三度まで、
(1) 文字数を合わせようとする
上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる
きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない
5つ項目があって、4つが6文字の単語で残りの1つが4文字だったとする
無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい
揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る
beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語の比較ではミスの数が明らかに変わると思う
なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい
(2) 単語の語尾とか
(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語を勝手に変化させたものがある
例えばだが、語尾が1つを除き全部 -ly になってたとする
そうすると残り一つに無理やり ly をつける
なんなの？イン踏みたいの？ラッパーなの？？
そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある
上の時点で英語を完全無視で英語力のなさはわかっただろうが、さらにこういうのもある
過去形には ed 、複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う
プレフィックスに is つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くときに本来の形で書くとエラーでるからさらにイライラする
例えばこういうこと
readed, catched, taked, companys, boxs, mans, childs, fishs, classs
見てるとムズムズする
英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う
まあエラーメッセージで don't have ～ とすべきところを has not ～ とか書いてたくらいだからなぁ
これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、～～』みたいの出るから」と言って直させるけど、上だからどうしようもない
間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
ちょっとした事情からシステムディスクの移設をしたところかなり躓いたので、備忘録的にメモ。
時代に逆行して個人的な書き物をする場所を一切持ってないのでお借りします。
以下、Linuxなりの最低限の知識があり、バイトオーダーもわかり、細かいところは勝手に補間できる人向け。
オフセット32256バイトを1048576バイトに調整する。
得てして非AFTからAFTという状況と思われる。
コピー元が壊れかけの時はやらないほうが吉。
