はてな 引退します

はてながあれなので、止めます。
このブログの記事はlilylaboのサイトに移転させます。

このブログは、記事移転が終わったら削除予定です。その他のはてなサービスは折を見て閉鎖していく予定です。

移転先サイト lilylabo http://lily.la/
ご連絡などはTwitterまで @shinjuku_pg http://twitter.com/shinjuku_pg

Zend server のMySQLが動かない in mountain lion OS X 10.8

良くわからないけど、現状だけ記録しておく。



OS X 10.8.2
Zend Server 5.6.0

MySQLに接続が出来なくなったので、動作確認をしようとしたところ、動いていない。

$ mysqladmin status
/usr/local/zend/mysql/bin/mysqladmin.client: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/usr/local/zend/mysql/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/usr/local/zend/mysql/tmp/mysql.sock' exists!
$ mysqladmin start

とやってみても、上と同じようにソケットがないって言われる。

Zend Serverごと再インストールすると直るが、恐らく再起動のタイミングで再び同じ現象に。


そこで、Zend Serverごと再起動してみる。

$ sudo  /usr/local/bin/zendctl.sh restart
Stopping Deployment [OK]
Starting Deployment [OK]
[03.10.2012 08:40:44 SYSTEM] watchdog for zdd is running.
[03.10.2012 08:40:44 SYSTEM] zdd is running.
Stopping Zend Server Monitor node [OK]
Starting Zend Server Monitor node [OK]
[03.10.2012 08:40:50 SYSTEM] watchdog for monitor is running.
[03.10.2012 08:40:50 SYSTEM] monitor is running.
-e /usr/local/zend/bin/apachectl stop [OK]
-e /usr/local/zend/bin/apachectl start [OK]
Stopping Zend Server GUI [Lighttpd] [OK]
spawn-fcgi: child spawned successfully: PID: 936
Starting Zend Server GUI [Lighttpd] [OK]
Stopping Java bridge [OK]
Starting Java bridge [OK]
Stopping JobQueue [OK]
Starting JobQueue [OK]


あれれ?MySQLでてこないよ。

良くわからないので、MySQLをzendctlから起動してみると

$ sudo  /usr/local/bin/zendctl.sh restart-mysql

 ERROR! MySQL manager or server PID file could not be found!
Starting MySQL
. SUCCESS!


MySQLのPIDみつからないよー
MySQLスタートさせるよー
成功したよ!」って感じ。



あらら?起動した。アプリケーションも正常に動作します。
なんだろなぁ〜これ。


OSの起動時にZendServerのスタートプロセスってどれが呼ばれてるのかな?こういうのどうやって調べるのか忘れた。
まあ最悪、shellファイル作ってスタートアップに登録でいけるかな。


どうも、昔もこんな現象あった気がするんだけど、どうやって解決したか覚えてないのです。デジャブかな。

CORE SERVERでIP制限とパスワード認証をサイト全体に導入する方法

備忘録です。

軽く調べたらIP制限については情報がなかったので、実際に試してちゃんと動作したのでめもめも。

とりあえず、パスワード生成して、.htpasswdに保存する。
パスワード生成はいろいろ方法があるけど、CORE SERVERのコントロールパネルから「ツール」=>「htpasswdの生成」でフォームを入力するとテキストが出てくるので、それをコピーして、認証をかけたいディレクトリに「.htpasswd」というファイルを作成して貼り付ける。「name:aisrVYJBuecKI」こんな感じのテキストです。

例えば、shinjuku_pg.com というサイト全体に認証をかけたい場合、
「/virtual/USERNAME/public_html/shinjuku_pg/.htpasswd」にファイルを作成する。「USERNAME」は自分のユーザー名に置き換えてください。
コントロールパネルのファイルマネージャからだと。USERNAMEまで省略されて表示されるので、「/public_html/shinjuku_pg/.htpasswd」ですね。

次に、.htaccessファイルを作成。
上のパスワードファイルと同じ場所に「.htaccess」というファイルを作成。

下記内容を書き込む。

order deny,allow
deny from all
allow from 123.456.789.001
allow from 123.456.789.002

AuthUserFile /virtual/USERNAME/public_html/DOMAIN.COM/.htpasswd
AuthGroupFile /dev/null
AuthName "Contact me!@shinjuku_pg"
AuthType Basic
require valid-user

allow from 123.456.789.001
のIP部分は許可したいIPに書き換える。複数のIPを許可したい場合は、alow~の行を複数書けばよい。
「USERNAME」は自分のユーザー名に置き換えてください。
「DOMAIN.COM」は制限したいドメイン名もしくはディレクトリです。
「AuthName」の項目は好きに書いてokです。

これだけで、許可したIPアドレスからしかアクセスができなくなります。許可IPからでもパスワードが必要です。

個人的にはこんな設定が必要になることなんてあり得ないんですけどね。
セキュリティ的にbasic認証なんて気休めだけど、core serverはdigest認証使えなかった気がするし仕方ないのか。せめて共有SSL使わないと。
安いサーバでセキュリティ求められてもムリですし。

Zend_DateでTwitterの日付を整形・変換

Twitterの日付フォーマットはZend_Dateでは「"EEE MMM dd HH:mm:ss Z YYYY"」となっているはずなのだが、上手くいかない。
めんどくさいので、Zend_Dateのバグと言う事にして回避策を講じてみた。

$response->created_at = "Mon Mar 14 10:27:05 +0000 2011"

$date = new Zend_Date(strtotime($response->created_at));
print_r($date->toArray());

Array
(
    [day] => 14
    [month] => 3
    [year] => 2011
    [hour] => 19
    [minute] => 27
    [second] => 05
    [timezone] => JST
    [timestamp] => 1300098425
    [weekday] => 1
    [dayofyear] => 72
    [week] => 11
    [gmtsecs] => 32400
)

とりあえず、strtotimeが優秀で、誤変換なども今のところなく動いている。
言ってしまえば、Zend_Dateを使う意味が全く無いのだが・・・

ちなみに、本来ならきっと動くはずのZend_Dateを使ったやり方。
間違いがあったら、是非ご教授頂きたいです。

$date = new Zend_Date($response->created_at, "EEE MMM dd HH:mm:ss Z YYYY");
print_r($date->toArray());

Array
(
    [day] => 14
    [month] => 3
    [year] => 0
    [hour] => 10
    [minute] => 27
    [second] => 05
    [timezone] => JST
    [timestamp] => -62161047175
    [weekday] => 5
    [dayofyear] => 73
    [week] => 11
    [gmtsecs] => 0
)

ご覧の通り、yearの判別が上手くいかないです。

MacローカルのZendFrameworkとNetBeansでコマンドラインツールが動かないときの対処

Warning: include_once(NetBeansCommandsProvider.php): failed to open stream: No such file or directory in /usr/local/zend/share/ZendFramework/library/Zend/Loader.php on line 146

コマンドラインでzfコマンドを使ったらこんなエラーが発生した。

たぶん、NetBeansZend Frameworkの設定をした時のみ発生すると思われる。
結論から言うと、ZendFFのバグで.zf.iniを修正することで回避できる。

$ vim ~/.zf.ini 

コマンドラインツールの設定を編集

php.includepath = "/Applications/NetBeans/NetBeans 6.9.1.app/Contents/Resources/NetBeans/php/zend:.:/usr/local/zend/share/ZendFramework/library:/usr/local/zend/share/pear"

上記のような内容になってるはずなので、以下の様に修正。

php.include_path = "/Applications/NetBeans/NetBeans 6.9.1.app/Contents/Resources/NetBeans/php/zend:.:/usr/local/zend/share/ZendFramework/library:/usr/local/zend/share/pear"

冒頭のphp.includepathをphp.include_pathに治すだけです。
これで、

$ zf show version
Zend Framework Version: 1.10.1

こんな風にちゃんと動きます。

ソースはこちら。
https://netbeans.org/bugzilla/show_bug.cgi?format=multiple&id=187234

パソコンの未来 自分がパソコンに求める物

chrome OSなどが出てきて、想像が膨らむパソコンの未来。
今回はWebのこっち側について考えてみる。

chrome OSは全てをWebのあっち側に持って行こうとしているとして、じゃあ、今こっち側に必要な物は何か。

まず、パソコンという箱があり、それがパソコンとして起動することは大前提だ。それにはwinは必要なくmacOSでもlinuxでも何でも良い。
パソコンが起動されて、次に必要な物はwebブラウザ。これは現状chrome一つでOKだと思う。
ブラウザ以外で今使用している自分のパソコンに入っているアプリケーションを見渡すと、サーバとのファイルのやりとりを行うftp系のツールだけは必要に感じた。それとプログラマとして開発環境はなくてはならない。

まずは、ftpによるサーバとのファイル操作について考えてみる。
私の場合、仕事でも趣味でもローカルのファイルをsftpでサーバにアップするという作業を頻繁に行う。ファイルというのは主にプログラミングのソースだ。また、ローカルのソースファイルは全てWeb上のSVNに上げている。これはバックアップというよりも、メインはSVNにあると思っている。つまりローカルにチェックアウトしたファイルは作業用の一時的な物で、いつ消えても構わない。
なので、環境が変わっても(違うパソコンからでも)常に同じ作業を行うことができる。

一度SVNからローカルにソースを落とし、修正しローカルで動作チェックを行い、サーバにアップして、SVNにも反映させる。
そんな作業になっている。
この一連の作業は、SVNから直接サービスを公開しているサーバにファイルをアップする事で改善できる。
具体的には、SVNにコミットした時点でWeb上にあるステージング環境へ自動反映させる。検証に問題がなければ、ステージングのファイル群を公開環境に反映させる。これはrsyncとかでカンタンに実現できる。

これによりローカルとwebとの接点は「SVN<−>ローカル」のみに絞られる。さらに細分化すると、SVNからのチェックアウト(若しくはアップデート)とSVNへのコミットの二つになる。
途中でsshなどによる作業も入るが、これは適当なスクリプトを作るだけでWebから行える。更にいえば、Webからssh接続を行うこともカンタンにできる。

これで一つ目のftpツールの問題は解決された。
続いて開発環境について考えてみたいと思う。

まず、自分の開発環境について定義をしておく。
私の場合、全てWebアプリケーションの開発だ。言語で言えば、php、html、cssjavascriptといった具合。たまにpythonとかperlも使うがここでは割愛。
プログラミングに使用するエディターはすべてeclipseになっている。たまに軽量なエディターも使用するが、なくてもいいのでこれまた省く事とする。
ローカルPC内にもサーバを立ち上げ動作検証を行うので、apacheやらphpやらMySQLなどその辺のものも一式入っている。
後は、動作検証用のブラウザ、コマンドラインからphpを動かしたりするときのターミナルが必要。
なくても良いが使っているものとし、DB設計にMySQLworkbenchなども上げられる。ほかの仕様書などのドキュメント系はほぼWebのプロジェクト管理ツール内にあるwikiで制作しているが、一応オフィスのexcelとwordも必要なツールとして数えておこう。

こんな感じの開発環境となっている。
さっそくこれらをWebに移行する事を考えてみる。

まずは消去法で。
ローカルのサーバ環境は全てあっち側に持って行ける。言うまでもないので細かい事は省略して、可能だということにしておく。
続いて、ブラウザも言うまでもなく、PCとして必要な物なのでパス。コマンドラインは前述したが、なんとでも代用がきく。
DB設計はなくてもいいし、WWW SQL Designerで代用もきく。
excelとwordもGoogleドキュメントで問題なし。もともとドキュメント系はweb上のwikiなので移行もスムーズだし、一元化できた方が能率的かつ管理も楽だ。
残るはエディターであるeclipse。エディターといっても、この中にはSVNやデバッガーも含まれる。Webに移行すると言うことでSVNは外してしまってもいいだろう。デバッガーはなくても何とかなる、、、はず。
なので、エディターとしての機能のみ考えていく。

php開発を行っている人で、エディターは秀丸だけ、とかvi系だけで行っている人もいるが、eclipseの補完機能とか、ホバーによる関数へのリンクとか、構文エラーの自動検知とか、絶対にあると作業効率が格段に増す機能はなくてはならない。使わない人の気が知れないぐらい依存している。
つまり、必要なのはweb上で使用でき、eclipse並みの高機能なエディターだ。むしろeclipseをweb上で使えることと言ってしまってもいいだろう。
残念ながら、今のところこれらのeclipseの機能はWeb上では無理だろう。作ることはできるとしても、動作が遅かったら意味がない。
不可能という言葉でこの問題解決は締めくくられてしまった。

仕方ないので、秀丸程度の機能が使えるweb上のエディターで代用ができることに無理矢理考え方を変えて、考察を続行することにした。
とりあえず、あることはある。
http://phpanywhere.net/
http://0-oo.net/sbox/web-editor
このあたり。
あとは、emacs。これはプラグインがたくさんあるから大概の機能は揃うはず。使ったことないので、なんとも、、、
ただ間違いなくマウスが使えない事は自分にとって最大のデメリットになる。コマンドラインでは複数のファイルの編集もできないし。ターミナルを複数立ち上げるとか?何か違うそれは。
emacsを使う前提だと既存のWebブラウザでは少し厳しいのではと思う。専用のターミナルで、複数タブや画面分割、複数の画面を一つのウインドウに表示するなど、犠牲にしかねる機能がある。要はpoderosa並みの機能が欲しい。まぁ理想として置いておく。

開発環境に関してはかなり多くの妥協に次ぐ妥協を重ねた結果、Web上若しくはサーバ側で動きターミナルで操作できるツールで代用ができそうだと結果に。
エディターに関しては私と同じような考え方をする人の需要が増えてこれば、きっと私が納得できるアプリケーションが作られると思う。
漠然としたイメージだと、emacsの機能をブラウザ上でグラフィカルに表示できて、軽快さが保たれればいいのだから、可能性はいくらでもあると思う。まぁあくまでphpなどのWeb言語に限った話だが。

ローカルに一切のファイルを置かず、全てあっち側で管理する。どうしても実ファイルが必要な場合は、S3とかDropBoxとかクラウド系のサービスを使う。もっと言えば、自分専用のクラウドサーバを用意しその中に全部放り込む。管理はGoogleデスクトップとかでもインストールしておけばいろいろできると思われ。
基本的な作業で必要なファイルは、wikiGoogleドキュメント、Subversionで管理するのがベストだと思う。
開発に関しては、ソースはSubversionで管理。何か作るときはサーバ上でSubversionからチェックアウトし、サーバ上でブラウザやターミナルから作業を行う。このサーバにテスト環境も構築できていれば検証もここで完結することにもなる。チェックアウト先をそのままapacheの公開Dirとしておけばよい。(※セキュリティーの問題はIP指定とかで回避ということで)
作業が終わったファイルはSVNでコミットし、コミットされたファイルは自動的にステージング環境へrsyncでアップされる。
ステージング環境の変更を本番に反映するのもftpなど使わずにrsyncで同期する。
データのバックアップなども全てサーバ間で行う。

ファイルのダウンロードなどを行う時は、ローカルにダウンロードせず直接サーバにダウンロードというかアップロードを行うこともできるはず。
mobile me(iDisk)などのようにサーバにあるディレクトリをローカルにあるように見せることもできるし可能だろう。どういう仕組みかわからないが、iDiskはローカルに実ファイルはダウンロードされないのにとっても高速に接続できる。
DropBoxなどでも似たような事ができるかもしれない。
VNPとかで、サーバ上のsambaに接続するだけでも十分かもしれない。


かもしれない、とか〜だと思う、といた表現がやたら多くなったが、一応結論として現時点でもローカルのデータを全てweb上に移行することが可能だ。
ただし、それには多少の犠牲を伴うが、これは時とともに解決されて行くであろう問題で、理想の環境がより早く実現するために私はこれからクラウド化を率先して取り入れて行く事にする。


ここでもう一つ問題定義だけしておく。
クラウドが台頭してきた理由にネットワークの高速がある。
これに対し今後、記憶媒体の大容量化+安価化が想像だにしない速度で進んだ場合、今のクラウド化と正反対の現象が起きる可能性もあるのではないか。
極端な例を挙げると、web上の全ての情報をローカルのPCの中に保存する事が出来るようになるかもしれない。
更にパソコンやネットワークの高性能化が進んだ場合、サーバを必要としなくなる事も考えられる。
数日間充電する必要のない電池ができ、パソコンそのものの飛躍的な性能アップ、WiFiMaxのような無線技術の革新が起きるとする。
するとパソコンを一つ持ち歩くだけで、常に全ての情報を蓄積し、そのパソコンから常に自分の情報も発信する。こうなると余程の膨大なトラフィックがあるサイトで無い限り、サーバの必要性はなくなるかもしれない。

そんな未来も見てみたいものです。