#htmlcsscoding

[displayblock]

OS X Yosemite ローカル作業

たまに異なることをしようとすると忘れているため、備忘録です。まず、下記を読みます。

Yosemite で Web 共有を復活させる

httpd 開始

$ sudo apachectl start

httpd 再起動

$ sudo apachectl restart

確認 URL は下記です。myName はユーザアカウント名（大文字小文字を区別する）です。

http://localhost/~myName/

SSD の OS 区画とデータ区画が異なる場合（私の場合 OS の再インストール時にデータ区画への影響を避けるため）、シンボリックリンクをはります。Sites がシンボリックリンクです。

異なる区画を指定する httpd.conf の記述が分からなかったため、シンボリックリンクを使用しています。現状、特に問題がないため、そのまま使用しています。

$ ln -s /Volumes/Data/Sites/mySite ./Sites

/Users/Myname/Sites

シンボリックリンクのはりかえる場合（プロジェクトディレクトリの変更）には、下記のコマンドを実行します。

$ ln -nfs /Volumes/Data/Sites/mySite ./Sites

シンボリックリンクの削除は rm ではなく、unlink コマンドを使用します。

Path

/private/etc/apache2/httpd.conf

/private/etc/php.ini

[displayblock]

基本的な作業工数の見積り方

見積は PHP や JavaScript と同様に、訓練が必要な "技術" です。また、企業にとっての目的のひとつは、売上をあげることであるため、これに直結する重要な技術でもあります。

見積について書きはじめると、ひとつの記事では終わらないため、ここでは金額の算出を含めず、業務における基本的な工数の見積り方について簡単に書きます。

仕様書から、すべての Web ページを箇条書きで書き出す。

仕様書の内容を理解し、それぞれの Web ページごとに時間、もしくは日数を算出する。

1 日の稼働時間は 7 時間です。

x 時間という算出だけでなく、x ～ y 時間という算出もありえます。（不透明な場合）

バッファ（予備の工数）を確保する場合は、必ず推測した工数とバッファを分けて考えてください。

バッファは工数の合計に対して確保する場合と、それぞれの Web ページごとに確保する場合があります。（後者のほうが精度が高く、理解されやすく、調整しやすい）

予定表を確認し、先行する予定の有無を確認します。その業務の対応期間は、推測工数 + バッファ + 他の予定の合計になります。

後工程にある検証期間の対応（いわゆるバグ修正や仕様変更対応）は、検証期間の長さと、自身の作業規模から勘案し、別途、検証期間の工数を算出します。（この工数は、先行する予定となるため、他の制作対応は行えないことに注意してください）

関係者と予定の調整を行い、工程を確定させます。

見積りは重要な業務の一環であるため、余りの時間で対応するのではなく、そのために時間を確保する価値があります。実作業と同様、心を落ちつけて、よく考える必要があります。

[displayblock]

Web 制作における水平展開

既存の技術や知識などを、他の分野や領域に対して適用すること。特に、ビジネスの現場などで用いられることが多い。その対義語として「垂直展開」という言い方もある。

水平展開とは 実用日本語表現辞典 では上記の定義となっておりますが、Web 制作における（というか、私がこの言葉を使用する場合の）水平展開とは、ひとつの対応箇所が見つかった場合、類似のその他の個所を探して、対応するという意味でこの言葉を使用しています。

基本的には、仕様変更にともなう機能修正、文言修正、画像修正、そして、バグ修正について、常に水平展開を意識したほうが良いです。

なぜ水平展開を意識したほうが良いかというと、指摘のあったところだけを対応する人物と、水平展開を意識しサイト全体の品質を向上できる人物、どちらが求められる人物かは言うまでもありません。

ひとの案件に対する積極性、主体性とはこうしたところに現れます。

ただし、修正箇所について Subversion リポジトリを対象に grep を実行したところ、想定外の個所や多数抽出された場合は、修正、検証コストの規模と、修正による成果をふまえ、水平展開を実施するかべきかは都度勘案する必要があります。

コーディング規約による class 名やファイル名のルール付けはこうした水平展開によるサイトの品質向上に有用です。

[displayblock]

Web 制作の手法と作業性

案件によって異なる作業性について比較、整理しました。

作業レベル

Lv. 手法 分類 反復性 導入難度 再現性 危険性 備考 1. 手動 FTP FTP アップロード × 面倒 ◎ 簡単 ◎ △ 修正レベル 2. WinSCP ミラーリング ◯ ◯ ◎ △ WinSCP の使い方 3. XAMPP ローカル開発環境 ◎ △ ？ ◎ なし 静的中心 4. VirtualBox + CentOS ローカル VM 開発環境 ◎ × ？ ◎ なし 最良

反復性 コーディングからブラウザ表示までの一連の作業の繰り返しやすさ。

導入難度 その手法を導入、運用する難易度。

再現性 案件ごとの http 出力されるまでの .htaccess や PHP による影響の受けやすさ。案件によって、再現性は異なります。例えば、システムが複雑な場合や XAMPP のように Windows の影響下にある場合は再現性が低くなります。

危険性 その手法での反復作業が、ソースコード以外の動作確認サーバ等に与える影響の大きさ

作業レベルへのコメント

それぞれの作業レベルへのコメントです。

案件によっては仕方ない場合があります。

2 回反復したら、即時 こちら を検討したほうが良いと思います。

XAMPP 固有の知識が必要な場合がありますが、Linux の知識がなく、まずローカルで開発する、という習慣を身につけてほしい場合におすすめです。

最良ですが、たまに敷居の高さを感じます。開発フェーズでは外部の共通 DB を参照するように設定すると楽です。

あと、Gulp を使えるならば gulp-sftp もありと思います。

作業を改善する

どうするべきか分かりにくかったため、項番をレベル表示に変更しました。レベルが上がるほど、反復性が高く、再現性があり、危険性も減りますが、反面、導入や運用に知識を要します。

案件ごとに作業レベルは異なりますが、技術や生産性の向上のために、より上位のレベルへの移行、または上位のレベルとの組み合わせを意識してください。

現実問題として、レベル 1 の手法を強いられている場合は、改善の余地があります。レベル 2 もしくはレベル 3 の手法へ完全移行することが難しい場合でも、組み合わせることは可能なはずです。

レベル 4 については、WordPress サイトのような導入難度が比較的低く、再現性が高い場合は、おすすめです。ただ、下記のような大規模サイトの場合は、再現性を担保しづらいため、他の手法との組み合わせが良いのではないかと思います。

例えば、10 年以上も運用され、SCM 管理下（プログラム生成されたファイルを含まない）の物理ファイルだけで 10,000 ファイル超、document root の .htaccess だけで数百行、さらに PHP での独自の URL ルーティングが施されている大規模サイトです。