2000年問題に代表されるように、プログラムの制約により、
気を付けなければならない日ってのがある。

その中でも簡単におきてしまうのが、8進数の解釈の違いだ。

すなわち先頭に0がつくと8進数と認識する場合が多いが、
敢えて10進数をゼロパディングして誤認識されハマる場合がある。

日付から月を抜き出す場合「08」月とゼロパディングで抜き出す場合がある。
＃これは抜き出す関数とかの仕様による。

ただし、「7」「07」まではどちらでも同じなので露見しないのだ。

つまり「8」の数字が初めて表れる時は要注意ってことだ。

以前、『「$(())」は「expr」コマンドと同等になる、これは便利。』と書いたが
これには落とし穴があった。
8進数の扱いについてだ。

こんな感じ。
┌──────────────────────────────────────┐
│$ echo `expr 08 + 1`                                                     →9│
├──────────────────────────────────────┤
│$ echo $((08 + 1))                                    →Syntax error: 08 + 1│
└──────────────────────────────────────┘

先頭に「0」がつくと8進数と認識されるわけだが
8進数は「0～7」のみで数字を構成するから、「8」はエラーとなる。

でも、「expr」だと、10進数と解釈してくれるみたいだ。

「ブランチ」はタグ付けと同じ要領で作れる。
というか「ブランチ/タグの作成」という名称だし。。。

で、その違いはというと、管理ルールの違い。
「タグ」は静的スナップショット的なものなので、一度作成したら更新しちゃダメ。

これを更新すると、派生分岐となる
つまり、更新してしまうとめでたくも「ブランチ」に昇格となる(心の中でね)。

で、この「ブランチ」を頻繁に更新することになる、つまり派生開発が始まるととなると
その「ブランチ」をチェックアウトするってことになる。

でも、開発中のものを移行するとなる、既存フォルダを削除して新規作成、
つまりスクラップ＆ビルドが必要となる。

これは、めんどくさい。

これを解決してくれるのは右クリックメニューの「切り替え」だ。

リポジトリの位置が変わったら
右クリックメニューから「再配置」を選択して、
参照先を変更するればよい。

タグ付けしたいフォルダにて右クリックしメニューを表示し、
「ブランチ/タグの作成」を選択する。
┌──────────────────────────────────────┐
│コピー(ブランチ/タグの作成)                                                 │
├──────────────────────────────────────┤
│┌リポジトリ───────────────────────────────┐│
││コピー元の作業コピー/URL                                                ││
││svn://xxxx/trunk/xxxx                         ┌────────┐┌─┐││
││宛先パス                                      │/tags/1.0       ││..│││
││宛先のURL                                     └────────┘└─┘││
││svn://xxxx/tags/1.0                                                     ││
│└────────────────────────────────────┘│
│┌ログメッセージ─────────────────────────────┐│
││┌──────────────────────────────────┐││
│││                                                                    │││
││└──────────────────────────────────┘││
│└────────────────────────────────────┘│
│┌リポジトリ上でコピーを作成するコピー元─────────────────┐│
││○リポジトリ内の最新リビジョン                    ┌──┐┌─────┐││
││●リポジトリ内の特定リビジョン                    │1001││ログを表示│││
││○作業コピー                                      └──┘└─────┘││
│└────────────────────────────────────┘│
│                                                ┌─────┐┌─────┐│
│                                                │    OK    ││キャンセル││
│                                                └─────┘└─────┘│
└──────────────────────────────────────┘
「コピー元の作業コピー/URL」にタグ付けしたいフォルダが表示されるので
タグ付けしたコピー先(宛先)を指定する。
「宛先パス」にて、宛先を選択すると「宛先URL」が連動して再表示される。

さて、宛先だが、リポジトリ作成時に「/tags」というフォルダを生成した場合には
その下に置くのが無難であろう。

末端フォルダは未作成でもいい(自動で生成してくれる)ので、「/tags」の下に
今回のタグバージョンをフォルダ名としてフォルダを順次作成していく感じとなる。

タグ付けには通常「コミット」時と同様にログメッセージを記載することができる。

また、最新のリビジョンではなく、過去の遡ってタグ付けすることも可能。
「リポジトリ上でコピーを作成するコピー元」でそこら辺を指定する。

最後に「OK」を押すと、コピーが宛先に作成され完了となる。

「コミット」する度に、リビジョンが振られていく(カウントアップする)ので
これだけでも十分バージョン管理となるのだが、
日頃のささいな更新と、物件リリースなど区切りとなる更新は分けたいところ。

それを実現してくれるのがタグ付けだ。

といってもその実体は、履歴に目立つ印をつけるのではなく
これまでの特定のリビジョンを別フォルダにコピーするだけだ。
もちろん手作業でもできる(特定のリビジョンをエクスポートすればよい)が、
手続きに則ってやれば、その作業履歴も残る。

他にもいろいろ利点はありそうだが、まずは手続きを覚えてしまおう。

緊急度順に以下の文言を使用するとよい。
・「直ちに」対応する
・「速やかに」対応する
・「計画的に」対応する

変数一覧
print_r(array_keys(get_defined_vars()));

定数一覧
print_r(get_defined_constants(true));

関数一覧
print_r(get_defined_functions());

クラス一覧
print_r(get_declared_classes());

対象となるチェックボックスにチェックがされているか否かを判断する方法は
いろいろある。
いろいろありすぎて、どれが正解かわからない(困ったものだ)。

チェックボックスが「id="a"」だった場合、
真ならチェック有り処理を行うようなif文は、以下のパターンがありうる
①「if ($('#a').is(':checked'))」
②「if ($('#a').prop('checked'))」
③「if ($('#a').prop('checked') == true)」
④「if ($('#a').attr('checked'))」
⑤「if ($('#a').attr('checked') == true)」
⑥「if ($('#a').attr('checked') == 'checked')」
⑦「if ($('#a')[0].checked == 'checked')」


チェックボックスが「id="a"」と「id="b"」の二つで場合、
一方でもチェックがあればってパターンとなる、以下のような感じか
⑪「if ($('#a,#b').is(':checked'))」
⑫「if (($('#a').prop('checked')) || ($('#b').prop('checked')))」


ま、結論ありきで記載したが、
最速は②、汎用性では①⑪ってことになる。

「.is(':checked')」(①⑪)に(単純化して)統一するか、
セレクタの単独が保証されている場合(「$(this)」の場合など)は
「.prop('checked')」(②)を使い分けるってのがベストな選択だろう。

「positon:absolute;」により絶対位置でオブジェクトを配置する場合、
それを乗っけるお盆みたいな存在が必要だ。
その役割をするのが、「positon:relative;」の親オブジェクトとなる。
(厳密には「positon:fixed;」とかでもいいけど)
┌──────────────────────────────────────┐
│<div style="positon:relative;">                                             │
│  <div style="positon:absolute;">■</div>                                   │
│</div>                                                                      │
└──────────────────────────────────────┘
ま、こんな感じで「positon:absolute;」を
「positon:relative;」中に内包させればよい。

じゃ、divタグじゃなくてtdタグでも…ってことで、以下のようにやりがちだ。
┌──────────────────────────────────────┐
│<table><tr><td style="positon:relative;">                                   │
│  <div style="positon:absolute;">■</div>                                   │
│</td></tr></table>                                                          │
└──────────────────────────────────────┘
不思議なことにFirefoxだけおかしく表示される。

Firefoxのバグ？いやいやこれが正式、W3Cのルールなのだ。
(他ブラウザは見逃しているが、Firefoxは忠実なのだ)

つまり、table系タグには「positon:relative;」は効かない！のだ。

ということで、回避策はdivタグを一個余分に噛ませてやればよい。
┌──────────────────────────────────────┐
│<table><tr><td><div style="positon:relative;">                              │
│  <div style="positon:absolute;">■</div>                                   │
│</div></td></tr></table>                                                    │
└──────────────────────────────────────┘

こういうルールにぶち当たると、tableタグによる(不要な)段組みはやめようかなと
思えてくるのだろう。