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