python の開発環境を作る
もはや Python の開発環境作成が面倒くさすぎて、他人には勧めないけど
必要にかられて環境を途中まで作ったので、記載しておきます。
distribute のインストール
Python のパッケージ管理ソフトcurl -O http://python-distribute.org/distribute_setup.py sudo python distribute_setup.py exec $SHELL
Pythonz
Python をホームディレクトリにインストールしてくれるソフトインストールされた場所に VirtualEnv をほげほげするように Path を通すとよいらしい
(ここではやってない。各自で調べてね)
curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash
.zshrc に下記の項目を記載する
[[ -s $HOME/.pythonz/etc/bashrc ]] && source $HOME/.pythonz/etc/bashrc rehash
Python をローカルにダウンロード
(ここで、すぐ使えるわけではない)
pythonz install 3.2.3
環境を作る
pip - ライブラリをインストールするための標準ツールvirtualenv* - rbenv 的な何か
easy_install pip sudo easy_install virtualenv sudo easy_install virtualenvwrapper rehash source /usr/local/bin/virtualenvwrapper.sh
ここで、virtualenv にローカルにダウンロードした Python を使うように
指示するとうまいことやってくれるようにできるらしい。
sakura VPS で mongodb を動かす
いろいろあって Sakura の VPS にMongoDB をインストールした。
能力とか、MongoDB の落ちやすい性質を考えると、正気の沙汰とは思えないけど
テストなので淹れるっちゃ。
公式ドキュメント通りにやると、次の二つのコマンドが必要になった。
sudo yum install ld-linux.so.2 sudo yum install libstdc++.so.6
MongoDB の起動
sudo service mongod start
MongoDB の停止
sudo service mongod stop
test 起動
mongo
A bridge too far
コーネリアス・ライアン原作の歴史映画。
たぶん三回目。
第二次世界大戦の西部戦線のお話。当時の西部戦線は、ノルマンディー上陸作戦後、大きく分けて 2つのチームがドイツを目指していた。北側はモントゴメリー、南側はパットン。フランスのノルマンディーからオランダまで進軍を続けた 2つのチームは補給線に大きな問題を抱えていた。予想よりも進軍スピードが早かった、そして、撤退するドイツ軍が港を破壊していったため海からの補給が行えず、主に長大な陸上の補給路に頼らざるを得なくなっていた。そのため、必要な物資が届かなくなり始めていたのだ。
そこで、世界でも有数の港であり、破壊もされていないオランダの港にモントゴメリーは目をつけた。その港までに辿り着くまでには主に5つの橋を渡る必要があった。様々な検討を加えた結果、パラシュート部隊で奇襲を仕掛けて橋を確保、各橋を戦車部隊が素早く渡り、歩兵部隊が各橋を守り、なるべく早くパラシュート部隊を回収するという作戦を立案した。
この作戦は、結果として、モントゴメリーの立案した作戦のなかでも最低の作戦と言われることになる。
コーネリアス・ライアンの作品は、全てにおいて念密に調査した上で書かれているのがポイント。実際に、この最低の作戦の中で何があったのか、各個人の心の動きなども描かれている。
僕はこの映画を見るたびに、戦争は嫌だな…と思う。同時に戦略ゲームや Civ を辞めないのは、病気だな、想像力が足りないなぁ、と思いながら遊ぶ。このへんは、自分の中の矛盾。
あと、作戦自体も複雑だったけど、この映画自体も複雑で、正直、三回見てもわからないところが多々ある…。
# 肩の紋章で 82 か 101 かを見分ける能力は着いた。
checkinstall を使ってインストール
削除を綺麗にしたいため checkinstall を使ってパッケージを作って
インストールするようにしている。
Sakura の VPS でも使っている。
インストール方法
sudo git clone http://checkinstall.izto.org/checkinstall.git cd checkinstall sudo chown -R user:group src cd src cd checkinstall ./configure --prefix=/usr/loca make ./checkinstall
使い方
コードを落としてきて、./configure と make をしたところで止める。
make all はしない
checkinstall -t [rpm|deb]
で、rpm なり deb が作成されるので、インストールすれば OK
まぁ、僕の手元だと毎回インストールが終わっているように見える。
rpm -ivh をしなくても…
sakura の VPS の CentOS に zsh とか git を入れた話
zsh
$ sudo yum -y install zsh
yum の -y は、質問されたら yes と答える設定
sudo
sudo を使えるようにするには、次のコマンドで編集する。# visudo
下記の部分をコメントアウト
%wheel ALL=(ALL) NOPASSWD: ALL
group の編集をする。次のコマンドで編集する。
# vigr
git
git のインストールsudo yum install git
screen
screen のインストールsudo yum install screen
yum について
yum で uninstall するには。sudo yum remove xxx
あれ？結局、全部 yum でインストールしたった。
この投稿は必要なのだろうか…
俺がアジャイルを推進するSIer の親玉なら…
ピザ屋が楽しみでしょうがないピザです。
誰がピザだ。
ピザ屋に行くまでに微妙に時間があるので、戯言・妄想を書くよ。
もしアジャイルを推進する SIer の親玉なら、これほど稼ぎどきと思うことはないな。
まず、「よーし、君をアジャイラーに変身させてあげよう。研修費用も出すよ」とする。
といっても、社内のヤル気のある人を研修で使うので、すこし費用が上がるだけ。
次に、「
アジャイルをするにはお客様のもとに行かなきゃいけないよね。
仕事のやり方を変えるということは、どういうことかわかってるよね。
全員がうちの会社にいつづけられるわけじゃないんだ。
うちの会社が研修費用も出したし、アジャイルな人間はいっぱいいるし、
もちろん、うちに仕事を出すよね。」
最終的に、
人件費や諸経費が削減され、
売上が上がり、
プロジェクトの炎上は少なくなり、
お金がもうかる。
これほど SIer の親玉にとって幸せなことはないんじゃないだろうか？
ちなみに、私個人としては、誰かにアジャイルかどうかとか言われても困るという立ち位置。
プロジェクトがうまくいって、使ってくれる人がハッピーになればアジャイルなプロセスじゃなくてもいいよ。アジャイルとはマインドですよ、マインド。アティチュードなのです。
プロセスやツールは大事だけど、それより個人の対話なのです。
包括的なドキュメントよりも、動くソフトウェアなのです。
契約交渉よりも、顧客との強調なのです。
計画に従うことよりも、変化への対応なのです。
jenkins を使うことがアジャイルな開発者ではないよ。
より変化に対応しやすくなるけどね。
とか、最近は思っています。
http://agilemanifesto.org/iso/ja/
===
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
===
