クライアントは、Mac miniです。

サーバの方は、例によってyumで。

yum -y install git

git用の適当なディレクトリを作り、公開リポジトリを作成する。

mkdir -p /var/git/hoge.git
cd /var/git/hoge.git
git init --bare

WebDavで公開するということなので、subversion用のconfをコピーして修正してみる。

cd /etc/httpd/conf.d
cp subversion.conf git.conf # subversion.confがない場合はgit.conf作って下さい
vi git.conf

git.confを修正する。また、.htpasswdは適宜作ってください。ここではあるものとします。

Alias /git-repos/hoge /var/git/hoge.git
<Location /git-repos/hoge>
   DAV on
   SSLRequireSSL
   AuthType Basic
   AuthName "Git Repository"
   AuthUserFile /var/git/.htpasswd
   Require valid-user
</Location>

Apacheを再起動させる。

service httpd restart

作成したgitリポジトリの権限を変更など。

cd /var/git
chown -R apache. hoge.git
cd hoge.git
git update-server-info

ここまでが、サーバの作業。

こっから、クライアント（Mac mini）の作業。
まず、httpsでアクセスするにはcurlを使うみたいなんだけれど、デフォルトの状態だとhttpsのアクセスができないらしいので、portsでサクッとアンインストールする。
その後、curlのインストールパラメータを編集してから、再インストール。

sudo port uninstall curl git-core
sudo port edit curl
# configure.argsのwithout-sslをwith-sslに変更
sudo port install curl
sudo port install git-core

ベーシック認証の認証情報をファイルに書いておく。

vi ~/.netrc
machine www.example.com # 適宜変更
login <ユーザー名>
password <パスワード>

開発サーバのSSL証明書はいわゆるオレオレ証明書なので、gitコマンドにエイリアスを設定しておく。

vi ~/.bashrc
alias git='GIT_SSL_NO_VERIFY=1 git'

これで、サーバに対してcloneでリポジトリを取得しようとしたのだが、エラーが発生した。

git clone https://www.example.com/git-repos/hoge
Initialized empty Git repository in /Users/******/hoge/.git/
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://www.example.com/git-repos/hoge/info/refs?service=git-upload-pack

fatal: HTTP request failed

オレオレ証明書対策はしたと思うのだが、うまくいかなかった。
検索してみたら、.gitconfigのhttp.sslVerifyをfalseにしろって書いてあったのを見つけたのでやってみた。

git config --global http.sslVerify false
# 再びgit clone
git clone https://www.example.com/git-repos/hoge
# クローン成功
cd hoge
touch test.txt
git add test.txt
# コミット。gitなのでローカルのみ
git commit -m "test"
# サーバに変更を送りつける
git push origin master
# pushに成功したとして、再びcloneしてみる
cd ..
git clone https://www.example.com/git-repos/hoge hoge2
cd hoge2
# test.txtがあればOK
ls

コマンドラインだけでやったので、実用としてはまだ試してませんが、とりあえず通信自体は確認できたということでOKとする。

まぁなんでこんなことを書いているのかというと、制作サイドの都合（工数がないだの、改修が大き過ぎるだの）で屁理屈をいって現在の仕様でお客様をごまかしたとしても、利用者からの反応が返ってくるのはお客様なので、その時点でお客様の不信感を買ってしまうのではないかと思うからだ。ちゃんとやってくれないと思われてしまう(必要な費用を出してくれていないという点は大いにあるのだが)。もちろんやれる技術力はあるのだが、そこはコストとの相談になるので、ごまかすのではなく、やはり松竹梅的なプランを掲示してお客様主導で決定するプロセスがないとお客様は納得しないと思う。お客様が選択した結果、利用者の反応が芳しくなければ、プランをアップグレードするという方法をとらなければ、お客様も学習できないし、我々の掲示に納得してもらえない（その時点で判断材料が少ないからまともな判断ができないパターン？）。

下請けでいつも感じるのは、マネジメント層のコスト意識が強すぎて我々の提案を屁理屈に変えてしまい(必要経費すら無駄扱い？)、お客様との折衝が長期化して、いいものができないというジレンマだ。コストを最小化しようとした結果、要求が満たせず、折衝のみでコスト増大してしまうパターン。まぁ俺は常に富豪仕様にしろって言ってるつもりではない。ただ、不特定多数の利用者のサイトの場合、正しいのは利用者であってお客様でも制作サイドでもない。
お客様自身が利用者の場合は、富豪仕様でなくても運用でカバーすることが可能だが（マニュアルを作ったり）、そうでない場合はお客様にも納得してもらった上で、我々から見たら富豪仕様でも作らなければならないと思う。損して得取れ。というか、その損は損ではなく、得をとるためのコストであるので、コストかけて得取れと言いたいわけです。それと、明らかな損は、お客様が制作サイドを貶めている（ように感じる）ので明らかにモチベーションが下がります。まぁそこはマネジメント層の腕の問題かもしれない。

ネットにおいては、Win(お客様)-Win(制作サイド)では足りない。Win(利用者)-Win(お客様)-Win(制作サイド)の関係を築けるように、お客様と制作サイドで友好関係を築く努力のためにも、仕様決定プロセスの透明性を高めるべきではないかと思う。

で、そのバウンスメールをカウントして、どうも宛先がなさそうだったり、メールサーバがなさそうだったり、放置されているメールアドレスみたいだったら、データベースから対象メールアドレスを削除して無駄なメール送信をなくそう！ということみたいだ。考えられているねぇ〜。

メルマガシステムを扱ったことなかったから、参考になった。

企業・お店のサイトの構築であれば、WordPressで十分に作成可能だと思う。プラグインも豊富にあるし、イレギュラーな機能に関しては、プラグイン開発でまかなえるし、その部分の見積もりさえしっかりしていれば、お客さんにもある程度短納期でサイトを納入することができる。大体の開発がイレギュラーなものは必要ないレベルであると思う。

開発コストは落とさずに、開発期間を短くできるぶん、サイトの目的、コンセプト、ターゲッティングなどのウェブコンサルティングに力を入れて、他社との差別化を図るようにしたほうが、お客さんも我々もユーザ（お客さんのお客さん）も利益を享受できる、Win-Win-Winの形になるのではないかと思う。

しかし、ウェブコンサルティングに力を入れようとするとお客さんから見ると、そのコストが余計に見えるらしい…。俺からするとそこが一番重要なところであると思う。ウェブサイトの効果はウェブコンサルティングで決まる。都市部はどうかはわからないが、地方ではそこをないがしろにするお客さんがまだ多いようだ。そこに誘導できない我々にも問題があると思うのだが、説明しても盲目的にNOを突きつけられる場合が多々ある。目に見えないものの先にこそ、掴みたい明日があるというのに…。

まあ一言でいうと、『最も必要である箇所のコストをケチるな！』ということだ。我々もいいものを安く提供したいが、納得できない代物を格安で提供はしたくはないんだ！！それは利益が上がらないからとかじゃなく、『お客さんのためにならないもの』になっている可能性が高いからだ。それを提供し続けると、Lose-Lose-Loseになってしまう…。そんなことは絶対に避けなれければならない。

Amazonで詳しく見る by G-Tools

アジャイルプラクティスを読んでて、腑に落ちた記事があった。

「設計は指針であって、指図ではない」

これは、設計者にも開発者にも、どちらにとってもいい言葉だと感じた。理由としては、設計者は指針を書くことに注力できること。いい意味で時間の短縮ができる。

詳細仕様書でフローチャートを書いていたときに、やりたいことはわかっているのだがフローチャートにして書こうするとすごく時間がかかった。しかも悲しいことに、この時間のかかったフローチャートは、「わかりにくい」と言われてしまった！！

フローチャートではなく、フローを箇条書き形式で書き直して見てもらったら、「これならわかる」と。

『詳細』なので、詳細にしなければならないという気負いがあるが、指図になるまで詳細にすると、仕様に問題がある場合に後戻りするのが難しい。しかも、詳細設計書を書くのに異常に時間がかかるようになる。これでは本末転倒だし、プログラマの仕事とやる気を奪う事になる。
機能仕様書に載っている機能は具体的にどんな処理をするかを設計する事が詳細設計であり、どのように実装するべきかはプログラマに任せたほうがいいと思う。アジャイルプラクティスに書かれているが、

「実際にその場所を通ってみるまでは、そこがどんな様子なのか確かなことはわからない」

のである。実装を詳細設計に書いたところで、実際に実装しようとするとどうしても無理が生じる場合はありうる。以前に、指針を示さずに指図になっていた詳細設計書を受け取ったのだが、フローとSQLが間違っていたことがあった。何がしたいのかがわかっていれば、間違っている場合は報告できるし、実装も可能なのだが、このときは駄目だった。詳細設計書の修正依頼をかけても修正に時間がかかり過ぎて工数がどんどん減っていき、待ちきれずに意図を判断して実装。そして詳細設計書と実装がどんどん乖離していく…という悪循環だった。

ドキュメントは指針。そして実装方法は、『実際にその場所にいる人』に委譲したほうがいいと思う。指針を共有できれば、プログラマから設計者へのフィードバックでまた素晴らしい設計が生まれる場合もある。

Manage It! 現場開発者のための達人式プロジェクトマネジメント
	でびあんぐる オーム社 2008-10-18 売り上げランキング : 79101 おすすめ平均 プロジェクトマネージャー必見 面白いけど読みにくい ITシステム開発のPMそしてそのスポンサー必読です Amazonで詳しく見る by G-Tools

Amazonで詳しく見る by G-Tools

ドキュメントを残す人でありたいと考え、それを模索している。Wordでテンプレートを作成してみたりとか。Webアプリの開発に携わっていると、低コストで厳しい工数を要求されるので作り出してから考えるみたいになってしまいがちだ（うちの会社では…）。工数を削減するためにドキュメント作成を省いたり、あまりに簡潔なものにしてしまうのは、逆に工数の増大を招く。

ドキュメントを書かないのか、書けないのか。最初は面倒臭がって書いてくれない！と思っていたのだが、最近になって、実は書けないんじゃないだろうか？と考えるようになった。ドキュメントは書けないけど、ソースコードは書けちゃうから書けるほうに安易に手を出して、修正依頼がきて、ブツブツと文句を言っているというような。自分はそんな人間にはなりたくないので、機能仕様書を作成してコーディングに入る前に確認を取るようにしている。これは当たり前のことのように思えるのだが、できていない人が多いんじゃないか？

機能仕様書、詳細設計書の書き方を学ぼうとネットで検索してみたりもしたが、しっくりとくるテンプレートが未だ見当たらない。機能仕様書に関しては、Joel on Softwareで書かれている方法で学習していて、なかなかいいなぁと思えるので、そちらを改良していこうと思う。問題は詳細設計書で、見ていてもしっくりくるのがない。感じたのは

• 一見わかりやすそうで、そうでもない
• Excelで作られているパターンが多い
• （主観的な意見だが）読みたいと思わせてくれない作り

という点。特に最後のが重要で、せっかく作っても読まれていないということが、往々にしてある。
ということで、Wordで作ることにした。
まぁあんまり変わらんやん！って言われる可能性も高いのであるけれど、Wordでやるほうが管理上楽だし、綺麗に作る事が出来る。ドキュメントには美が必要だと思う。ドキュメントの作成にしても、最初はなかなか上達はしないので、工数もかかるだろうが、そこをちゃんと経験しないと仕様をまともに考えることがないので（頭を使わないため）、エンジニアとして実力が向上しないんじゃないだろうか？

今思うと、ドキュメント書くのが下手な人の話って、わけわからんことが多いなぁ〜と思う。何がしたいのか、何が求められているのかがブレてて、言いっぱなしで、自分でドキュメントにして形にするということがないような気がする。ドキュメントを書くプロセスを経ると、まとめるというフィルターを通した上で出来上がるので、要件もまとまるし、情報共有もスムーズになるし、他人の時間を節約することができるので費用対効果は素晴らしいものがあると思う。いいドキュメントを作成すると信頼も得られるし。

ドキュメントを作るのを面倒臭がる人は、あまりに「自分の時間」にフォーカスを当て過ぎではないだろうか？他人の時間を節約するということは、自分の時間を節約することにも繋がるので、目先の時間に捕われず、ドキュメントに時間を「投資」したほうがいいと思う。得られるのはドキュメントだけではなく、「書く力・考える力」も手に入る。そういうことが、結果的にお客さんの期待に応えることに繋がると思う。

• どういうふうに書いたら他人に喜んでもらえるドキュメントになるだろうか？
• 手戻りの発生しにくいプロセスにするにはどうすればいいのか？
• このプロジェクトの目的、解決すべき本質は何か？

これを常に考えていきたい。

エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方
	翔泳社 2008-05-22 売り上げランキング : 7760 おすすめ平均 為になった すばらしいＷｏｒｄ入門書 数少ない、明確な視点・コンセプトのWORD本 Amazonで詳しく見る by G-Tools

※開発用なので、localhostでしか動かしませんのであしからず。
設定も、全然修正しておりませんのであしからず。

■MacでPostfixとQpopperの導入の理由
開発環境としてMAMPを使っているのだが、Windows & XAMPPのときと違い、メール送信を伴うプログラムが作成できなかったため。
ならMacにPostfixとQpopper入れてしまうという作戦で行く事に決定！

■実行環境
Mac OS X 10.6.1 Snow Leopard

■参考サイト
Postfix
Mac OS Xをメールサーバーにしよう-Postfixの設定-for Leopard
Qpopper
Qpopper – やってみなけりゃ気が済まない

■では、Qpopperやってみる

1. MacPortsを使ってQpopperをインストールする。

   $ sudo port install qpopper +pam
   

2. PAM認証を使うために/private/etc/pam.d/sshdファイルをコピーしてpop3というファイルを作成する。

   $ sudo cp /private/etc/pam.d/sshd /private/etc/pam.d/pop3
   

3. 起動の設定を行う。launchdに登録するplistファイルをProperty List Editorで書くとよいらしいのだけれど、実際はQpopper – やってみなけりゃ気が済まないで公開されていたファイルをほぼコピーした。自分はcom.eudora.qpopperの箇所を、com.macports.qpopperにした。
   保存名も、com.macports.qpopper.plistにした。

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
       <key>Disabled</key>
       <false/>
       <key>KeepAlive</key>
       <true/>
       <key>Label</key>
       <string>com.macports.qpopper</string>
       <key>OnDemand</key>
       <true/>
       <key>ProgramArguments</key>
       <array>
           <string>/opt/local/sbin/popper</string>
       </array>
       <key>Sockets</key>
       <dict>
           <key>Listeners</key>
           <dict>
               <key>SockServiceName</key>
               <string>pop3</string>
           </dict>
           <key>SockType</key>
           <string>stream</string>
       </dict>
       <key>inetdCompatibility</key>
       <dict>
           <key>Wait</key>
           <false/>
       </dict>
   </dict>
   </plist>
   

4. plistファイルをコピーしたあと、launchctlに登録する。

   $ sudo cp ~/com.macports.qpopper.plist /System/Library/LaunchDaemons/
   $ sudo launchctl load /System/Library/LaunchDaemons/com.macports.qpopper.plist
   

メールをPostfixで送信して、Thunderbirdにアカウントとしてユーザ名@localhostを登録したらメール受信できたので、これで大丈夫でしょう！MAMPで動かしているCakePHP製Webアプリ経由でメール送信しても届いたのでOKと。これでアプリ開発が続けられる〜！！よっしゃ！！

■MacでPostfixとQpopperの導入の理由
開発環境としてMAMPを使っているのだが、Windows & XAMPPのときと違い、メール送信を伴うプログラムが作成できなかったため。
ならMacにPostfixとQpopper入れてしまうという作戦で行く事に決定！

■実行環境
Mac OS X 10.6.1 Snow Leopard

■参考サイト
Postfix
Mac OS Xをメールサーバーにしよう-Postfixの設定-for Leopard
Qpopper
Qpopper – やってみなけりゃ気が済まない

■では、まずPostfixやってみる

1. 実のところ、Postfixは最初から入ってるみたいだった。
   知らんかった。localhostでしか使わないので、設定もいじらず。
   ということで、ターミナルから起動させた。

   $ sudo postfix start
   

2. 一応、動作確認を行った。

   $ telnet localhost 25
   
   #
   # 繋がってるのを確認できたら、終了
   #
   
   quit
   

3. メール送信してみる。yourusernameには、Mac上のユーザ名を書くこと。
   Subjectに件名を入力し、本文を記述。書き終わったら行の先頭でピリオドを入力してreturnキーを押す。

   $ mail yourusername
   Subject: test
   test
   test
   test
   .
   EOT
   $
   

4. メールが届いているか確認する。
   ユーザはメール送信先になっていたユーザであること。
   （上記でいえば、yourusername）

   $ mail
   
   #
   # メールが届いていれば、先ほど送信したメールが表示される
   # 確認後、mailを終了する
   #
   q
   $
   

5. Postfixの自動起動を設定する。
   一旦、Postfixを停止する

   $ sudo postfix stop
   

   Macの場合、launchdというサービスを経由してデーモンを起動するらしい。
   なので、launchdにPostfixを登録するコマンドを実行する。

   $ sudo launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist
   

うーん、とりあえず、Postfixはこれでよさそう。
次回は、Qpopperについて書きます。

Amazonで詳しく見る by G-Tools

まぁ別に周囲が非生産的だと非難したいわけではなく、『自分は』生産的であろうと心がけること。綺麗ごとを並べたところで、人は動かない。何度も何度も熱く語って、自分がそのやり方を示し続け、教えて行く事によって徐々に浸透させていく。これは、自分にさしたる権限がないときの方法なんだけれども、短期的な効果はなくとも、じわじわと効いてくる。

自分にある程度の権限があるときや会議を行った上で行動するときには、スタートでみんなの意識合わせを行うことができれば、障害が少ないのかもしれない。まぁ熱心に語ることは必要だけれども。ただ権限がないとき、自分がいくら「こっちのほうが効率もよくて生産的だからみんなでそうしようぜ！」といったところで「また変な事をいってやがる。もしその方法がよかったとしても、みんな守りゃしないし、今のままでも十分だろ」ということになり、デスマーチを迎える。

リーダーでない人間がボトムアップでチームを作るのには、自分を貫き通して（意固地になるのと違うよ）、「みんなにとっていいことは、いいことなんだからやろうよ！」と訴え続けることが一番重要かなぁと思う。そうすれば、徐々に味方も増える。

まあ、リーダーシップのない人間がリーダーになったときが、一番の悲劇だ。そして、リーダーぶることがリーダーの仕事だと思ってると超やっかいですな。リーダーらしく振る舞うのと、リーダーぶるのは違いまっせ。

Apacheのログに、余計なログを出さないように設定する方法。

CustomLog logs/access_log combined env=!nolog

SetEnvIf Request_URI "\.(gif)|(jpg)|(png)|(css)|(js)$" nolog

あとは、apacheを再起動して終了！