まで安定する方法がこちら。上記は空のファイルを出力した結果をファイルにリダイレクトする方法となる。バージョンによって動作が異なるため、上記コマンドが最も安定して動作する。予約ファイル名であり、どの場所からでもアクセス出来る。このファイル名でファイルを作る事は出来ない。このエントリーは前にも書いたのだが、DB破壊により消失したためもう一度書いている次第である。A.N.デスクトップに散乱したファイル達を見たことがあるかIT系に従事するプロであっても、パソコンの中のファイル整理が下手くそな人は多い。そんな人は大抵、デスクトップがメチャクチャだ。「一体あのファイルはどこにあるんだ?」と自分で作った重要なファイルすら分からなくなってしまう人もいる。探しているだけ工数の無駄である。誰も整理方法を教えてくれないそれはそうだ、誰もそんな事を教えてくれないから、思い思いの方法で勝手にやってるだけだから、そうなってしまうのだ。体系化されていないものは管理できない。幸いにして、私は開発に従事して1年目からフォルダできちんと整理する事を教わったので適当に共有しておくことにする。すればいいかとにかく「考えなくとも、見ただけで、誰でも、何が、どこに、あるか分かる」というのが最も重要なところなので、ずばり一連のプロジェクト工程の区切を名付けてあげるのが一番良い。作って、あとから必要なもの以外を削除またはWORKフォルダにでも移動すればいい。提案かユーザの要望で発生した案件の課題管理や要件整理を行う。大々的な要件定義フェーズがなくメールでポイと来た案件は、やりとりしたメールを保存してあとは課題管理表だけで済ませたりもする。ちなみに、この名前でフォルダを作る。数字を付ければどんな環境でも名前順ソートくらいは出来るので、最初だと分かる。環境移行または初期開発でよく使う。「環境定義」でも良い。実はそんな資料が無くて作るしかないパターンでも使う。サブフォルダとして更に「01.ハード」「02.ソフト」「10.構成図」なんかも考えられる。初期開発の時か、ぼんやりしたイメージの作成にしか使わない。UIとI/Oを決める。保守開発だとここからいきなり始まる場合が多い。データのセット仕様を元にして、個々の正常系&異常系のケースで結果はどうなるのか、プログラマーが実装するにあたり必要な情報を書く。設計段階でマスターとして追加するデータは決まるので、サブフォルダまたは「21.データセット」としてトップフォルダに置く場合がある。ジョブフローなんかもここに入れる。30.実装ソースコードを収める。案件によっては、プログラム設計も入る。あたりで単純フォルダ比較できるようにフォルダ構造ごと修正前と修正後で分けて保存する。差分があるファイルだけでよい。ちなみに私は「コードを書く工程」と「単体テストをする工程」は全然別物だと考えているタイプなので、「製造」とは言わない事にしている。保守開発だと単体テストと受け入れテストしかされない。必要なだけサブフォルダを作る。50.リリース最後にリリースだ。リリース判定の書類、リリース物のチェックリスト、最終的に確定したリソース(データやモジュール)、本番リリースの作業エビデンス(証跡、証憑とも言う)を入れる。60.事後対応リリース後に何かちょっとした追加作業が発生した場合ここに発生日付と共に入れる。99.WORK一時フォルダだ。