TweetStandardプランの契約ができたので、早速設定。

• /etc/ssh/sshd_config

  1 2 3

  Port xxxxx # ポート番号変更 PasswordAuthentication no # パスワードログインの禁止 PermitRootLogin no # rootログインの禁止

• 必要なパッケージの導入

  1 2 3 4 5 6 7 8 9 10

  $ sudo su - # yum update # yum install zsh lv # chsh -s /bin/zsh # useradd hoge # passwd hoge # su - hoge $ chsh -s /bin/zsh $ exit # visudo

• 公開鍵の登録とsshサーバの再起動、確認
• パッケージのインストールと設定

  1 2	% sudo yum install mysql-server php-mysql % sudo vim /etc/httpd/conf/httpd.conf

• iptablesの設定
• PHPのインストール

  1 2 3 4

  $ sudo yum install php-pear-Net-Socket php-pear php-common php-gd php-devel php php-mbstring php-pear-Mail php-cli php-imap php-snmp php-pdo php-xml php-pear-Auth-SASL php-ldap php-pear-Net-SMTP php-mysql $ sudo vim /var/www/html/index.php $ sudo /sbin/service httpd restart $ sudo rm /var/www/html/index.php

• nginxのインストール

  1 2 3 4 5

  $ sudo /sbin/service httpd stop $ sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5Server/x86_64/epel-release-5-3.noarch.rpm $ sudo yum install nginx $ sudo chkconfig httpd off $ sudo chkconfig nginx on

と、ここまで設定して面倒になったので続きは後日。

 

Tweet

@yoshukiさんに献本していただきました。ありがとうございます。と言うわけで、書評を。

またもや端末識別番号問題

まず最初に残念な点を。最後の章でjpmobileを使わないで自前で機能を実装しているのですが、セッション管理に端末識別番号を利用してしまっています。これは高木さんがよく言われている由々しき問題で、エンジニアとしてはやってはいけないことのはずです。

ここまで破綻しているケータイID認証（簡単ログイン） on 高木浩光＠自宅の日記

せっかくその前の章でSession Fixationの話がでたのに、最後にそれを台無しにしてしまう内容は、少し残念でした。Railsで携帯サイト開発の初の本なのでよけいに。書評でこんなこと書いてしまうのはどうかとも思ったのですが、携帯サービス開発をしている身としては、書かざるを得ませんでした。

あと途中から、あまりRubyのコードを書かない人なのかな？と思わせる部分が見受けられました。if 〜 thenだったり、文中のメソッドがget_mobile_id()と括弧がついていたり。気になったのはその辺りでしょうか。

Railsで携帯サイト開発する人は一通り目を通すべき

とは言え、端末識別番号のこと以外ではお勧めできる本となっています。jpmobileの使い方からPCで絵文字を出す方法まで、かなり実践的な内容です。特にPCで絵文字は携帯/PC両対応のサイトを作るときには必ず出てくる問題で、それが詳しく書かれています。Railsで携帯サイト開発をする人は、一度は目を通しておいて損はしないでしょう。

そしてまとめ

これはもうjpmobile on Rails3という本を書くしかないですよね(多少違う)。先を越された感をぬぐい去れないので、@yoshukiさんとはどこかで飲み明かしたいと思いました。さてjpmobileがんばろう。

 

Tweet気になったので、How fast is FLUSH TABLES WITH READ LOCK?の意訳。

FLUSH TABLES WITH READ LOCKってどれだけ時間がかかる？

ちょっとまえのMySQLカンファレンスでバックアップソフトのベンダーのとこに行ったんだ。で、バックアップソフトについて話をし始めたんだけど、それはデータベース全体のロックを取得する、FLUSH TABLES WITH READ LOCKを使ってるということだった。でも彼は、ロックは「数ミリ秒」しかかからないと誇らしげに語ってた。バックアップソフトベンダーはそう思っているようだが、これは大きな勘違いだ。

実際にはこのコマンドがロックする時間はわからない。研究室のテスト環境ではそりゃミリ秒で終わるかも知れないが、実際にはもっと時間がかかる。数分から下手すれば数時間もかかることがあるだろう。そしてこの間、サーバは完全にロックされる(readonlyでもないんだ！)。なぜそうなのか、このコマンドが何をしてるか見てみよう。このコマンドには、いくつか重要な処理が含まれている。

ロックのリクエスト

FLUSH TABLES WITH READ LOCKコマンドは、すぐにグローバルロックを要求する。すると、そのロックが許可される前に、システムの中で動作している全てのプロセスがロックアウトされる。理論上、結局は読み出しのロックを取得するだけなのだから、このことは悪いようには見えない。他の読み出しロックだけが必要なコマンドとは、共存できるはずだ。

でも実際には、多くのテーブルは読み書きされている。最初の書き込みクエリーがグローバルロックによってブロックされると、それに続く読み出しクエリーは、その前の書き込みクエリーが要求したテーブルロックによってブロックされる。結局、実質的にテーブルは排他ロックされてしまい、新しいリクエストは全てブロックされてしまう。読み出しのクエリーでさえも！

ロックを待つ

FLUSH TABLES WITH READ LOCKがロックを取得する前に、ロックを持っている実行中のものは全て終わらなければならない。要するに、SELECTも含めて、全てのクエリーが終わる必要がある。もしすごい時間のかかるクエリーが動いていたり、テーブルロックするトランザクションがあったりすると、FLUSH TABLES WITH READ LOCKは全ての処理が終わってロックが解放されるまでブロックされることになる。これには結構な時間がかかるんじゃないかと思う。僕にとっては顧客のサーバにログインして走ってるクエリーを見ることなんて珍しくないこと。FLUSH TABLES WITH READ LOCKの前に、こういうクエリーが走っていたりすると、結果はさんざんなことになる。

このプロセスが動いているときにシステムがどう見えるかについて、例を示そう。

Id 6の接続はログインできていないことがわかる。これはMySQLのコマンドラインクライアントが-Aオプション付きで起動されていて、テーブルとカラムのリストを取り出そうとタブ補完しようとしたところだ。また「Flushing tables」と言うのも間違っている。まだテーブルをフラッシュしていない。ロックを得ようと待ってるだけなんだ。

テーブルのフラッシュ

FLUSH TABLES WITH READ LOCKがようやくロックを取得すると、データのフラッシュが始まる。でも全てのストレージエンジンに適用される訳じゃない。MyISAMは通常処理中ではディスクにデータをフラッシュしようとはしないにもかかわらずだ。MyISAMはOSが適切なときにディスクにフラッシュすることを当てにしている。結果的に、MyISAMが多いとOSのバッファにダーティーなのが多くなってしまい、フラッシュするのに結構な時間がかかってしまう。この間、システムはロックされたままになってしまい、全てが終わってようやくFLUSH TABLES WITH READ LOCKは完了し、レスポンスを返すことになる。

ロックの保持

このコマンドの最後の部分は、ロックが保持される時間。このロックはUNLOCK TABLESや他のいくつかのコマンドで解放される。FLUSH TABLES WITH READ LOCKを使っているたいていのバックアップシステムでは、ロックの間の処理は、ファイルシステムのスナップショットの初期化のような比較的短い時間で終わる。だから実際には処理の中で非常に短い時間を費やすだけのことが多い。

結論

実環境で動作するバックアップシステムは、FLUSH TABLES WITH READ LOCK willが瞬時に完了すると仮定するべきではない。非常に時間がかかる場合があるからだ。例えばMyISAMとInnoDBが混在している場合がそう。でも多くの場合は混在させたりしないし、バックアップシステムがグローバルロックを回避するように設定できるはずだ。InnoDBのみの場合だと、ロックを取得する必要はないはずだ。だからロックフリーなバックアップをとれる。バックアップベンダーはこのことを考慮して製品を開発すべきだ。

まとめ

MyISAM使っていると、FLUSH TABLES WITH READ LOCK willが瞬時に終わらない場合があるので注意。あとInnoDBだとそもそもロック取得しなくてもいいから、別の方法を使うべき。要調査。

 

Tweet型をt.binaryなどとすると、デフォルトではBLOBとなってしまい、64KiBまでしか保存できなくなってしまいます。そこで:limit => 1.megabyteとオプションで制限を大きめに書いてやると、Railsが勝手に拡張してMEDIUMBLOBにしてくれます。

 

Tweetいろいろ準備が必要なので順番に。

rootになれるようにする

基本的にはblogSetomits : GDD Phone の標準 1.6 ROM で Rootedを参考にしてます。まずAndroid SDKをインストールしてtoolsディレクトリにパスを通しておきます。あとHTCのsigned-jdd-ota-14721.zipとAuto-sign.zipは別途ダウンロードしておきましょう。

そしたら電源長押しで電源を切って、ホームボタン押しながら電源を入れます。次にホームと電源ボタンを押すとメニューがでるので、apply sdcard:update.zip [Alt+S]を選んでトラックボールをクリック。しばらくすると終わるので、reboot system now [Home+Back]を選んでクリック。またしばらくすると起動するので、rootになれるか確認。

リカバリーモード用プログラムのインストール

またしてもblogSetomits : GDD Phone の ROM を OpenEclair 1.2.2 にを参考にして作業します。ほんとにお世話になります。

次にここからrecovery-RA-sapphire-v1.6.2G-blue.imgをダウンロードします。

なんか途中でエラーメッセージが表示されるが気にせず続行。

あとは先程と同じようにリカバリーモード(HOME+電源)で起動して、WipeでFactory resetしたあと、Flash zip from sdcardから先程のzipファイルを選択して実行します。

しばらくするとアニメーションととももに起動して、晴れて新しいROMを使うことができます。

さて、これにdocomoのSIMを入れてあれこれやってみるかな。

 

Tweetやはりユーザに優しくないから。あと記事を書くことが目的で、ブログシステムとかCMSを作るのが目的じゃなかったから。

ユーザに優しいWordPress

MovableTypeと並んでCMSの双対をなしていると思われるWordPressですが、ユーザ数が多いだけあって情報もプラグインも豊富でした。また公式サイトにしっかりしたインストールマニュアルがあることもポイントの一つです。こういった「ユーザに優しい」姿勢というのが、世に広く受け入れられる事につながるのでしょう。

じゃあ、tdiaryがユーザに優しくないかというと、Rubyistにはそうではないでしょう。だってコード読めばわかるし。必要な機能がないなら自分で実装してしまえばいいですからね。でもその方向に行ってしまうと、カスタマイズに注力してしまって、なんか本末転倒な気がしてしまうのです。一時期はtdiaryで環境を作り始めたのですが、「なんかコード書いているのがメインになってきている」と感じたので諦めました。

Railsのものにしなかったのも、それと同じような理由からです。「なければ作ればいいじゃないか」と言うのもいいのですが、「なかったから別のにしました」でもいいんじゃないかと思うわけです。と言うわけで、しばらくはWordPressでPHPと戯れていたいと思います。

 

Tweet来るGo!肉の日(5月29日(土))に、TokyuRuby会議02が開催されます。それに伴い、LT発表者の募集が始まっています。

TokyuRuby会議02

一見するとすごい敷居が高そうですが、何を隠そう、単なる飲み会です(違。みんなが飲んでいる間に、好き勝手喋ることができる、LTデビューにはもってこいのイベントです。内容もRubyと言う単語が入ってさえいれば、内容は問いません。プレゼンのタイトルに「TokyuRuby会議02」とか書くと、あとは何でもいいってことですね、わかります。

ちなみに今回も司会をすることになっているので、打ち合わせさえしてもらえれば合いの手を入れることも可能です。むしろコント化してもいいかもしれません。無限に可能性が広がるLT、それがTokyuRuby会議です(言い過ぎ。

と言うわけで、肉と酒が好きな方は(そうでない方も)、是非ご応募ください。

 

TweetやっぱりApacheのメモリ消費量が多い気がしてきたのでnginxに移行しました。要点としては、mod_phpのようなものはないため、FastCGIでPHPを動作させる必要があると言うこと。

インストールは大して難しくないのですが、いかんせん日本語での情報が少ないのが難点です。基本的には公式wikiのPHP/FastCGI Exampleを参考にすれば問題ありません。以下、Debian (lenny) での作業ログです。
まずは必要なパッケージをインストールします。その前に、必要に応じてApacheを停止しておきます。

次にFastCGI用daemonのスクリプトを作成。

作成したら実行権限をつけて自動起動の設定をし、起動しておきます。

次にnginxの設定です。DebianではApacheと同じく、/etc/nginx/site-availableに設定ファイルを入れて、有効にしたいものだけ/etc/nginx/site-enabledにシンボリックリンクを張る感じになります。今回は/etc/nginx/site-available/wordpressと言うファイル作ります。

作成したらシンボリックリンクを張って、設定ファイルの構文チェックをします。ついでにデフォルト設定のシンボリックリンクは削除しておきます。

上記で問題なければ、nginxを起動して動作確認。

移行してみた感想としては、Apacheよりも何倍も高速になった気がします。恐らくはFastCGIをdaemon化したことが大きいのでしょうが、体感できる高速さはやはり魅力です。用途に応じてnginxやlighttpdなどの高速Webサーバを試してみるのもいいのではないでしょうか。

 

Tweet

と言うわけで注文しました。x68kと言われては買わざるを得ません。これで人生決まったようなもんだし。

 

Tweet最近よく、「経営者が技術者の会社がいいよねー」的な話しをするのですが、一概にそれが良いかどうかを考える時があります。

技術者のことを理解できるのは技術者だけなのか

確かに経営者が技術者だと、社員である技術者の気持ちやトレンドをよく理解してくれそうな気になります。確かにそれはあるのですが、逆に理解しすぎて本当に大事なことをおろそかにしてしまう可能性があります。技術者といっても仕事をしてお金を稼いでるわけです。それを大事にしないで、技術者のこだわりや気持ちを重視してしまうことがあるのではないかと、最近思うようになりました。

またここで言う「理解する」というのも、ちゃんと考えなくてはいけない部分です。単に「技術者側に立つ」だけでは理解した事になりません。よく「本当に貴方のことを思ってやってるんですよ」的な話がありますが、短期的ではなく長期的に見たときに、「ああ、ちゃんと理解してたんだな」となることが、「理解して」いたことになるのではないでしょうか。こういうのって人に説明し辛いし、その場ではわかってもらえないことが多いので、「まあ、とりあえずはいいか」と短期的に賛同を得られる方に進んでしまいケースが多いんじゃないかなと思ってます。

経営者と技術者を同時にできるかどうか

と言うのも、世の中で技術者主導の会社というのは結構あるのですが、うまく行っているところばかりではないと、よく聞くからです。技術者が経営者になるというのは、簡単なことではないでしょう。仙台Ruby会議02でいろんな話を聞きましたが、みなさんかなり苦労している感じでした。やはり、考え方が違う２つの職種を同時にこなそうとするのは大変で、どちらの立場もわかる苦しさがあるのだなと感じました。

ちょっと考えがまとまらないところなのですが、この点についてはいろいろと書いていきたいと思っています。