Pepabo AdventCalendar 2014の10日目の記事です。昨日はあんちぽサンタ記事を見て入社したlaughkでした。明日はhisaichi5518です。 ソフトウェアのビルド方法について。 今年は特にセキュリティ関連でCVE対応が多かったり 経年したサービスのOSは刷新したいけど同じミドルウェアのバージョンを使いたかったり な時に、rpmをビルドするのはしんどい（弊社は主にRHELクローンなディストリを使っています）ということで、今年は社内でVagrantを利用した、ビルド済ソフトウェアのtarボールを作るのが流行りました。 今日はその一例としてApacheのビルドについて。サンプルのプロジェクトを tnmt/vagrant-build-apache22に置きました。 git clone https://github.com/tnmt/vagrant-build-apach

クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。 できるだけサービスを利用 例えばAmazon S3というインターネットストレージのサービスを考えてみる。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりも、S3を使った方がいい。キューイングにしても、Amazon SQSというサービスがあるので、EC2にキューイングソフトを入れて自分で管理するよりも、このサービスを使った方が良い。すでに存在しているサービスのメリット/デメリットを正確に理解し、使いこなせることが大事。利用者としては、車輪の再開発はしないほうがいい。 机上実験よりも実証実験 机上実験に終始して「このシステムでこの負荷だと、インスタンスタイプはどれを何台使えばいいのか」

2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー