ライダーの札幌宿泊事情

北海道にツーリングに行って困った事があったのでメモ。

札幌に知人がいるので、一泊したのだけれど当初泊まる予定だった、
すすきの近くのカプセルホテルに結局泊まることが出来なかった。

その理由が、バイクの停められる場所がなかったということ。
ホテルに停める場所がないだろうというのは察していたけど、
周りのコインパーキングでも軒並み断られた。

屋内のコインパーキングは自動車の駐車しか想定していないし、
屋外のコインパーキングはすすきのが近いからいたずらされる危険ありと
夜通し預かることはしていないとのこと。
どんだけ治安悪いんだすすきの。。。
道端に自転車がいっぱい置いているけど、さすがにバイクは路駐できない。

結局、すすきのと反対側の大きめのホテルを探しなおして、
従業員の方の好意と機転でホテルの端に停めさせていただいた。

警察は違法駐車をなくすために、まず駐車場を整備すべきだと思う。
まぁ、北海道へのツーリングで札幌なんぞおしゃれに観光するなってことでしょう。

Oracleのimpで"表がありません"とエラー

真夜中の障害テスト中にドハマリしたので、メモ。

Oracleを使ったシステムを構築している。
データリカバリテストとしてテーブルを一つDROPして、
FULL=Yでexpしておいたファイルから削除したテーブルを
TABLES=で指定してimpコマンドを実行したところ、
"表がありません"とエラー出力された。
sqlplusで接続すると確かに表は作成されていなかった。

ひとまずメッセージを信じてexpしたファイルをviewで
確認したが、件のテーブルをcreateする記述が確かにあった。

結局、勘で原因がわかった。
念のためにDB全体をバックアップするため、
expはSYSTEMユーザで実行している。
ただし、テーブルは通常利用する一般ユーザで作ったものだけを
旧戻しする想定だった。

exp同様、impもSYSTEMユーザで実行したが、
対象テーブルは所有者でないため、認識できなかったようだ。
TOUSERとFROMUSERに一般ユーザを指定したところ、
テーブルが無事に戻った。

SunOS5.9に外付けHDDをマウント

業務でSunOS5.9に外付けHDDをマウントする必要があり、

かなり手間取ったのでメモ。

→結局うまくいかなかった。OpenSolarisなら問題なかったので備忘として残しておく。

◆外付けHDDの名前を調査
tail -f /var/adm/message
ls -l /dev/rdsk/ | grep storage

もしくは

rmformat

◆領域確保
fdisk [外付けHDD名]
> 3
deleteする
: 1
partision番号1を選択
: y
本当に消すかと聞かれるのでyesを選択

> 1
領域をcleateする
: C
FAT32を選択
: 100
領域を100%使用する。
: y
activeにするかと聞かれるのでyesを選択
> 5
Exitする

◆フォーマット
mkfs -F pcfs -o fat=32 [外付けHDD名]:1

◆マウント
mount -F pcfs [外付けHDD名]:1 /mnt


------------------------------------

★マウントできない時

Solaris9だとブロック型デバイスじゃないと怒られた。。。

◆領域確保
fdisk [外付けHDD名]
> 3
deleteする
: 1
partision番号1を選択
: y
本当に消すかと聞かれるのでyesを選択

> 1
領域をcleateする
: 1
Solarisを選択
: 100
領域を100%使用する。
: y
activeにするかと聞かれるのでyesを選択
> 4
Exit(update)する

◆フォーマット
newfs -f 4096 [外付けHDD名]
#外付けHDDのサイズが大きいからかフラグメントサイズを4096にしろと言われたので、-fをつけた。
 普通は要らないかも

◆マウント
mount [外付けHDD名] /mnt

クラウドの活用とテスト自動化

#もともとここは自分用のメモだけど、
 今回はさらに自分だけが対象。
 愚痴っていうか宣言というか。

最近、システム運用は実はすごく大変なんだよって
話をよく聞く。会社でもネットでもどこでも聞く。

ふざけるなよ、と。バカかと。

「お客様は神様じゃない」とか、「急な仕様変更」は受けないとか
「無理な注文には値上げ要求するべき」とか。
言ってることはよくわかる。でも

あのね、よく考えなよ。

私たちSEってなんなんだ？

「お客様の課題をIT活用で解決します」でしょ。
自分らの課題もITで解決できないのに、顧客相手に商売できるの？

システム運用が大変って話しも一周したでしょ。
そろそろ、前向いてどうやって解決するのか考えよう。

解決手段は2つ。
クラウド化とテスト自動化。

本気で24時間365日サービス提供しようと思うと、
開発はともかく、サーバ運用が大変なことになる。
常に人を張り付かせて昼夜問わずピーピーなる
ワーニングメッセージにしょぼしょぼしながら対応する。
深夜にHDDが壊れたとかなったら
タクシーで現場に駆けつけて対応だ。
私はそういうシーンがすごく好きでワクワクするんだけど、
それを長年続けると欝やモチベーション低下でチームが崩壊していく。

一挙にこれを解決するのがクラウドの活用だ。
サーバの設置不要でスケールアウトもボタンひとつ。
監視も肩代わりしてくれるどころか自動復旧までしてくれる。
まだセキュリティが甘いとか(SLA的な意味での)稼働率が不安とか
言っている人は情報が遅い。半年もしないうちに解消する。

うちの会社含め自前のクラウドを用意できていない会社は
サーバ管理は素直に諦めたほうが良い。
クラウド業界は今後は規模の勝負になる。
ノウハウもないのに下手にプライベートクラウドとか作ると痛い目みるし、
他社の方が圧倒的なサービスを提供できるのであっという間に顧客が
そちらに流れることうけあい。
てか、サーバ運用を主にやっていてい未だにパブリッククラウドを
提供する体制になっていないような会社は真面目に仕事してないだろ。

というわけで、今後はアプリ開発が主戦場になると思う。
で、テストの自動化が必要になる。

ネットサービスの台頭で今まで以上にスピードが求められてる。
それはSIerも同じ。早く出来れば安くできるから。

そして上の議論にもどるけど、急な仕様変更とか無理な注文で
テスト後戻りとかケースが増大するとかわめくバカが多い。
そして実際、障害をドカンと起こして「顧客の無理な要求で」、
とか言って、顧客も会社も自分も納得させんな。

テストの自動化をすれば解決できる。
テストのスピードアップもそうだし、
テストファーストによるテストケースを
作成してからの開発っていうシステム開発の
大前提を守ることができる。
リリース直前の仕様変更があっても高品質のテストが
数分でできれば何の問題もない。

と、いうわけで社内でテスト自動化を推していきたい。
まずはSeleniumRC導入して布教していこうと思う。
理解者もいるので、なんとか会社を盛り上げたい。

DPIの行方

以前、上司にこの話をしたらおもしろがられ、ちょくちょく聞かれるので、自分用にメモ。

DPIは悪なのか?「ネット全履歴もとに広告」総務省容認　課題は流出対策」について。
http://blogs.itmedia.co.jp/assioma/2010/06/dpi.html

上記のようにDPIは特定個人のネット履歴を収集してその人の嗜好に合った
広告を出すって言うものです。
かなり効果の高い広告を出すことができるので、注目されていますが、
壁はやっぱり個人情報保護です。
システムやってる人間から見れば、個人を特定できるような情報の収集は
まともには取得できないですし、人間が見てわかるようなもんでもないと思いますが、
一般の利用者の方には理解が得にくいことはわかります。

で、気になるのが各社の対応です。

グーグルが追求するコンテクスチュアル・ディスカバリーとは何か？
http://markethack.net/archives/51664049.html

あまり関係ない記事ですけど、Googleは積極的に活用していく、
もしくはすでに活用しはじめているな～と。

ところが、ライバル(というと違うかもしれませんが)の、MicroSoftやMozilaは

次世代Webブラウザに「Do Not Track」機能搭載へ
http://www.publickey1.jp/blog/10/internet_explorer_9firefox_4webdo_not_track.html

それを阻止(利用者の情報を保護)する動きを見せているなぁ～。

結局どっちもユーザのために動いているのは変りないと思うので、
あとはユーザがちゃんと勉強して取捨選択していかなくてはいけない局面ではないかと。

あまりちゃんとした結論のない文ですが、今後「各人にフィットした広告へ」の動きは
加速していくと思うので、DPIがおじゃんになるにしても、
SEとしてどっちに転んでも良いような知識を身につけるべきだと思いました　まる

lsyncd + ssh

業務でlsyncdで同期するWeb/ファイルサーバを作成したのでメモ。

OSはCentOS 5.5を想定。kernelは2.6.13以降必須。kernel上げずとも
inotifyを個別に入れれば大丈夫っていうブログもあるけど私の環境では動かず。
素直にkernelあげた方が良いと思う。それはそれで他の機能に多大な影響あるけど。
lsyncdは1.39で動作確認。
sshは相手先サーバでrsyncdデーモン立ち上げるのが面倒だったため。。

1. 正系ユーザの秘密鍵作成&副系へ公開鍵送付


# ssh-keygen -t rsa
: 途中の質問は全て[Enter]。(ssh公開鍵登録場所はデフォルト、パスはなし）
# scp .ssh/id_rsa.pub [ユーザ名]@副系:/home/[ユーザ名]
# ssh [ユーザ名]@副系
$ mkdir .ssh
$ cat id_rsa.pub >> .ssh/authorized_keys
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ exit
# ssh [ユーザ名]@副系
: パスワードなしでログインできることを確認
# rm id_rsa.pub

2. lsyncdインストール

# cd /usr/local/src/
# tar xvzf lsyncd-1.39.tar.gz.gz
# cd lsyncd-1.39
# ./configure
# echo $?
⇒0であること
# make
# echo $?
⇒0であること
# make install
# echo $?
⇒0であること

3. lsyncd設定ファイル配置

# vi /etc/lsyncd.conf.xml
～～～～～～～～～～～～
＜lsyncd version="1"＞
  ＜settings＞
    ＜logfile filename="/var/log/lsyncd"/＞
    ＜binary filename="/usr/bin/rsync"/＞
    ＜pidfile filename="/var/run/lsyncd.pid"/＞
    ＜callopts＞
      ＜option text="-rvz"/＞
      ＜option text="--rsh=ssh"/＞
      ＜exclude-file/＞
      ＜source/＞
      ＜destination/＞
    ＜/callopts＞
  ＜/settings＞
  ＜directory＞
    ＜source path="[同期元フォルダ]"/＞
    ＜target path="[ユーザ名]@[サーバ名]:[同期先フォルダ]"/＞
  ＜/directory＞
＜/lsyncd＞
～～～～～～～～～～～～

※上の＜＞が全角になっているので注意。。

4. lsyncd起動

# lsyncd

残：

起動スクリプト作ったり、ログローテートしたり、監視したり、動作確認したり。

  

    

    

    

    

      

      

      

      

      

    

  

  

    

    

  

【書評】「就職しない生き方」

書評は読書メーターにまとめるつもりだったけど、

「就職しない生き方」の編集があまりにもツボったので、メモ。

10人のIT絡みの自営業者(≒経営者)の声を書いてる本なんだけど、

9人目まで呼んだところで、「うおー、起業したくなってきたー！！」と

大分ミナギッてしまった。みんな楽しそうなんだもん。

高ぶりすぎてこの気持ちをどうしようって不安にすらなりつつ

10人目のひろゆきへのインタビューを読んだら一気に脱力して、

起業意識がどっかに抜けてしまった。

ものの見事にオチた。ていうか、オトされた。

編集者だれだろう？インタビュアーも同じ人かな？

10人のなかでビッグネームは堀江さんとひろゆきの二人で、

おそらく堀江さんをラストに持ってくるのが正道だろうと思う。

なのにあえてひろゆきをラストに持ってきたのは明らかに狙っている。

ギャグ狙いか何かのメッセージかはわからないけど。

堀江さんへのインタビューでもインタビュアーの心意気を感じる部分がある。

同じことやってておもしろいの？っていう堀江さんに質問に

本はすべて全く違いますからって答えているのに

銀魂13巻の団子屋の親父を思い出した。

幅広いジャンルのお菓子で勝負を仕掛けてくる異星人に

団子しか作れない親父は団子で幅広い世界を作って対抗するんだって言う。

ITって幅広い。なんにでも応用きく。どの世界にも入っていく。

でも、本だって同じ。目に見えにくいだけでITに負けない広い世界があるんだろう。

茶道や時計職人とかの一見静かな世界も理解できればとんでもなく深い世界があると思う。

要は粒度かな、と。荒くてわかりやすいほうが良いわけでもないし、

細かすぎてわかるひとだけにしかわからないほうが良いってわけでもないけど。

ちょっと思考が拡散してきたけど、この本の編集者の気持ちがよくわかる良い編集だった。