tech and non-tech note

2010年7月18日日曜日

ジョウホウギジュツシャのテイギ

情報技術者の定義
http://www.k2r.org/kenji/jp-it-engineer.html

ふむふむ。

white belt

ほげ環境のときは簡単だったのに、ふが環境はわかんね！クソが！

などといったのは、white belt を締めていないからかもなーとアプレンティスシップ・パターン読んで思った。

自戒。

はじめました。

ほ「ヘイユー！某サーバ AutoScaling シチャイナヨ！」
僕「ほい」

僕「・・・ AutoScaling は別の API tool ?」「management console からは操作できず？」
ほ「ソウダヨ！」

・・・というわけでいまごろ Auto Scaling API Tools を入れた

Auto Scaling API Tools
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2535

その後
as-create-launch-config
↓
as-create-auto-scaling-group
↓
as-create-or-update-trigger

した。インスタンス側動作確認していたら
ちと不足もあり、AMI 作り直して launch-config 変更したりもした。

エントリとあんま関係ないけど、AWS の API tool どもは ~/tools 以下においていたりする

katsuji@hexley% ls -l ~/tools
total 32
drwxr-xr-x@ 11 katsuji  staff  374 12  6  2009 AutoScaling-1.0.9.0
drwxr-xr-x@ 11 katsuji  staff  374  4  6 14:05 ElasticLoadBalancing-1.0.9.3
drwxr-xr-x@ 10 katsuji  staff  340  5 19 15:14 RDSCli-1.1.005
lrwxr-xr-x   1 katsuji  staff   19  7 16 17:50 as-api-tools -> AutoScaling-1.0.9.0
lrwxr-xr-x   1 katsuji  staff   23  7 14 18:46 ec2-api-tools -> ec2-api-tools-1.3-53907
drwxrwxr-x   7 katsuji  staff  238  7  6 23:01 ec2-api-tools-1.3-53907
lrwxr-xr-x   1 katsuji  staff   28  6 25 03:09 elb-api-tools -> ElasticLoadBalancing-1.0.9.3
lrwxr-xr-x   1 katsuji  staff   14  6 25 03:08 rds-cli-tools -> RDSCli-1.1.005

新しいのがでたときは置いて symlink 張り直して古いの消す。

.zshenv には

export EC2_HOME=$HOME/tools/ec2-api-tools
export AWS_ELB_HOME=$HOME/tools/elb-api-tools
export AWS_RDS_HOME=$HOME/tools/rds-cli-tools
export AWS_AUTO_SCALING_HOME=$HOME/tools/as-api-tools

と書いて

awspath=($EC2_HOME/bin $AWS_ELB_HOME/bin $AWS_RDS_HOME/bin $AWS_AUTO_SCALING_HOME/bin)

とも書いて

path=(いろんなパス $awspath)

と書いている

AWS_CREDENTIAL_FILE, EC2_PRIVATE_KEY, EC2_CERT は個人用とそうでないのと使い分けてるので、直接 .zshenv には書いていない。

2010年7月11日日曜日

TCP/IP をもういちど

ジムショが結構近いこともあって、某~~3way~~ハンドシェイクな会社の techtalk にちょくちょくお邪魔している。
（ネタが言語以外のものも多いので参加しやすいというのも理由）

先日は Velocity 2010 のネタから 2つ、資料をみつつこれってどうなのよ、といった話。

その1
http://en.oreilly.com/velocity2010/public/schedule/detail/13096

その2
http://en.oreilly.com/velocity2010/public/schedule/detail/11792

でだ。その2 を聞いているうちに、
「ああー、ぼくってば TCP/IP に関する知識がだいぶあやふやだな」と実感。
「必要がなかったから」と言ってしまえばそうかもしれないが、ちょっとねぇ。。。

いまいちどスティーブンス本読み直すか！と思ったのでした。

これから買うならオーム社のマスタリング TCP/IP シリーズだろなー。1冊も持ってない。

2010年6月27日日曜日

review 5/28 - 6/25

疲労コンパイル気味で書いてなかった <- いいわけ
まとめて。

・Puppet
前エントリの通り、 puppet でごそごそ。

サイトで参考にしたところ
本家 http://www.puppetlabs.com/

ちなみに reductivelabs から名称が変わったのは今年のこと。
http://www.puppetlabs.com/blog/reductive-labs-home-of-puppet-changes-name-to-puppet-labs/

mizzy さんのところ
http://trac.mizzy.org/puppet
記事
http://gihyo.jp/admin/serial/01/puppet

こんな具合にした
- puppetmasterd を動かす passenger 用の ruby (Ruby Enterprise Edition) をインストール
- 前述の通り puppetmasterd は passenger 経由で動かす
- 初回起動だけは webrick. localhost 上で puppetd <-> puppetmasterd の動作を確認したら passenger に切り替えた
- puppetd は --listen --no-client --report 付きで起動、なので puppetrun することで適用
- puppetd 側の設定ファイルは namespaceauth.conf だけ

・3アプリ分本番サーバ用意
「アプリ」と書いているので何のサーバなのかわかるひとにはわかるかな。

puppet でそれなりに仕込みをしておいた後、まず直近の2アプリ分のサーバを構築。
はじめの 1アプリ分で足りてないマニフェストを書きながら構築。
つぎのアプリの分はほぼマニフェストいじらずペシペシ実行して構築。
概ね良好。
アラがちょろちょろと見えてきたので、修正のうえ3つめのアプリのサーバを構築。
3つで計50台弱。まだまだ改良の余地があるな。

こんな感じ
- とある CentOS 5.x な AMI をつかってインスタンス起動
- yum update かけたり、すこしばかり設定した上で AMI 作成する
- 作成した AMI でインスタンスを順次起動
- あとは puppetrun しまくりんぐ (アプリに必要となるブツのインストール＆設定、起動など）

Puppet により、必要なインストール＆設定はカバーしているものの
どこまで AMI に含めておくのが吉なんか、まだつかめてないな。
変に作り込むと、他の者にとってわかりづらくなりそう。
「ふつうの」サーバを構築で OSインストール直後はすべて puppet 、と考えたら AMI はあまりいじらないままでよいとも考えられる。
ただ単に時間を稼ぐなら用途別に AMI 作っておくのはアリ。ポリシーの問題。

・AWS 理解
しばらくお触りする機会が減っていたので、サーバ用意のおかげで覚えなおした。
いまごろ 169.254.169.254 知った。いいねこれ。

・某社や某社のひと来社
サーバつかいませんかといった話が何度か。
ふむ。。

・ルータ
つながらない、つながらないと。「つかえない」「つながらない」「重い」て言うのは誰でもできる。

小規模かつ「べんちゃー」なら、「よーしおらがみてやんよ！」みたいなひといてもいいけど、ここにはいない。
いつのまにやら自分が面倒みてるけど、悪くない。ある意味好き勝手できるからね。

・1年後、2年後
1年後、2年後くらいの方向をぼやーと考えるなど。

・ながっちり
なんだか遅くまで粘ってやってしまうので、早く帰ろう。
遅くまでいる -> 腹減り -> コンビニでちょっとした食料調達、のパターンが無駄。

・知らないひと
事前にマトモなお知らせがないまま人が増えてるのでなかなか気持ち悪い。
気持ち悪いので、知らせてくれと訴えておいた。近いうちに形骸化しそうではある。

・ケムリ
なんだかスモーカーが増えてきたっぽいので今度こそ eneloop でも買ってニオイに対して自衛するか。
ニオイと有害物質がなければタバコは自分でバカバカ吸っているとおもうね。

・社内勉強会
だいぶ自分の領域と違うので、すぐ役立てられる度合いが他の者よりも低いと思う。うーむ。

2010年6月19日土曜日

ピープルウエア読んでる

ベテランプログラマさんに貸してもらって、いまのところ半分くらい読んだ。

頭のヒラメキと音のキラメキは興味深いなぁ。

コード書いてる最中にヒラメキたいなら、音楽きかないほうがいいらしいよ。

　プログラマーのように専門分野の高度な知識が必要となる職種では、順序だった論理的思考を司る左脳が非常に重要である。通常の作業は大部分がここで処理され、音楽の影響はほとんど受けない。音楽のよう感覚的、直感的なものは右脳で処理されるためである。しかし、プログラマーの作業すべてが左脳で処理されるのではない。例えば、「あっ、そうだ！」という突然のヒラメキで問題が解決することもあるし、何ヶ月分、何年分もの作業時間が、独創的なヒラメキで節約できることもある。この飛躍は右脳の機能なのである。

　オフィスの騒音や音楽が、創造性やヒラメキに与える悪影響は、表面には現れてこない。ヒラメキはいつどこで起こるかわからないため、ヒラメキや独創性が低下しても認識するのは極めて困難である。また、人間の思考で何パーセントがヒラメキによるかとういう明確な分担があるわけでもない。

「おれは音楽聞きながらがはかどるんだフフン」というひとは風呂はいってるときやなにか別のことしてるときにヒラメイたりしてると思うね。
ヒラメキのいらないコーディングをするときなどはききながらのほうがはかどるとおもう。

自分自身はどーも音楽ききながら仕事はできない。聞き入ってしまうから。ははは。

2010年6月13日日曜日

iPhone 4 は見送る

・いま持ってるのは 3GS
・そもそも iPhone ユーザになった動機がユルい
・HDビデオであんなのやこんなのを撮りたい！というのは今のところない

（まず無い話だとは思ってるけど、au で出たら、話は別。）

登録: 投稿 (Atom)