2014年04月22日

php.ini ってどこに?

Nginx やらyii framework やらを使う決断をしたら、AWS(Amazon Web Service) にPHPをソースからビルド&インストールするはめになった。
なれない事をやると、いろいろつまずく。
今回はその一つ、

「php.iniってどこ?」

って話。そもそも共有サーバーではそのファイルは予め設定済みで、カスタマイズしようとしても、宿借りの分際では触る事さえ許されてないもの。各ドキュメント・ルートにphp.iniを置くと読み込んでくれるが、大本はどこって話になると「/etc ?」って、探したりすることになる。

愚かにも、ビルド時の "./configure" に " --prefix" オプションを指令しなかったばっかりにどこにインストールされたものやら、さっぱり。

そんなときはには、ちゃんと便利はオプションが用意されています。その名もズバリ「php -ini」。
phpinfo() 関数の結果をそのまま出力するもので、基本的に「php --info」や「php -i」の出力も同じ。以下実行例ですが、大量の情報がダンプされるので、途中まで
$ php -ini
phpinfo()
PHP Version => 5.5.11

System => Linux ip-172-31-28-114 3.10.35-43.137.amzn1.x86_64 #1 SMP Wed Apr 2 09:36:59 UTC 2014 x86_64
Build Date => Apr 21 2014 19:20:42
Configure Command => './configure' '--enable-sigchild' '--with-openssl=shared'
'--with-kerberos' '--with-zlib=shared' '--enable-bcmath=shared' '--with-bz2=sha
red' '--with-curl=shared' '--enable-exif=shared' '--enable-ftp=shared' '--with-g
d=shared' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-gettext=shared
' '--with-gmp=shared' '--with-mhash=shared' '--with-imap=shared' '--with-imap-ss
l=shared' '--enable-intl' '--with-ldap=shared' '--enable-mbstring=shared' '--wit
h-onig' '--with-mcrypt=shared' '--with-mysql=shared,/usr' '--enable-pcntl' '--wi
th-pdo-mysql=shared' '--with-mysqli=shared' '--with-readline=shared' '--enable-s
hmop=shared' '--with-snmp=shared' '--enable-soap=shared' '--enable-sockets=share
d' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy=shared'
'--enable-wddx=shared' '--with-xsl=shared' '--enable-zip=shared' '--enable-zend
-signals' '--with-zlib-dir' '--with-freetype-dir=share' '--with-t1lib=share' '--
with-xpm-dir=shared' '--with-libdir=lib64' '--enable-fpm' '--with-tsrm-pthreads'
'--enable-maintainer-zts' '--with-pdo-mysql'
Server API => Command Line Interface
Virtual Directory Support => enabled
Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => (none)
Scan this dir for additional .ini files => (none)
Additional .ini files parsed => (none)

...


ご丁寧に、configure で指定したオプションまで出してくれてる。
そして今回の目的で注目するところは「Configuration File (php.ini) Path =>」と「Loaded Configuration File =>」
なにもしてないので「Loaded Configuration File => (none)」。
php.ini は「Configuration File (php.ini) Path 」の示すところに置きなさいということで、素直に置いてもう一度。

$ php -ini
...

Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => /usr/local/lib/php.ini

...


無事読み込んでくれたようです。

共有サーバーって、いたせりつくせりだったと実感した瞬間

ラベル:php.ini PHP
posted by ayagu at 09:59| Comment(0) | PHP | このブログの読者になる | 更新情報をチェックする

2014年04月20日

データベースのデータ移行 - MySql

プラットフォームの交換やら、ステージングから本番環境へとか、必要なときには頻繁にやるのですが、一度落ち着けばご無沙汰してしまうのが「データ移行」。

ググってはみるものの「あれ、こんなんだったけ?」となりがち。

そんな、たまにしかやらないとすぐに忘れてしまう。自分なりのベストプラクティス。

手順は以下のとおり

  1. 移行元のデーターベースをmysqldumpファイルに出力

  2. できたファイルを移行先のサーバーに転送

  3. 移行先のサーバーで、必要ならばDB名を変更してファイルをインポート



それでは、レッツ・プラクティス

1. mysqldump でデータベースをファイルにバックアップ


mysqldump はデータベースをダンプするプログラムです。移行元の旧DBからデータをダンプして、ファイルに保存します。
$ mysqldump -u [user_name] -p [old_db_name] > [old_db_name].dump

[user_name] [old_db_name] をご自分の環境にあわせて入力してください。-p オプションでパスワード入力が促されます。

2. バックアップファイルを移行先サーバーに転送


1. で作成したファイルを何らかの方法で、移行先のサーバーに転送します。メンテナンス実行期間はsshのポートを開けている所が多いとおもいますので、sftp や scp(超簡単scp) が便利だと思います。

移行先のサーバーで、DB名を変更してバックアップファイルをインポート


まずは、移行先サーバーにリモートログインして、対象DBを作成。
$ mysql -u [user_name] -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 155
Server version: 5.6.13-log MySQL Community Server (GPL)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create database [new_db_name] character set utf8;

例によって[user_name], [new_db_name]はご自分のものに変更してください。キャラクターセットは明示的に指定した方が後々問題が起こる事が少ないと思います。もちろん旧DBと合わせてくださいね。

次にバックアップファイルを[new_db_name]のデータベースに流し込みます。これにもmysql コマンドを使います。

$ mysql -u [user_name] -p [new_db_name] < [old_db_name].dump


以上です。簡単なのですが、いったん忘れてしまってググると何が正解かわからなくて混乱するものでした。

posted by ayagu at 11:07| Comment(1) | mysql | このブログの読者になる | 更新情報をチェックする

2014年04月15日

iOS7 - スクロールとちょっとだけ Auto Layout (2)

前回「iOS7 - スクロールとちょっとだけ Auto Layout (1)」でスクロールのできる画面ができました。
投稿の最後に告知しましたように、このプロジェクトにはAuto Layout に関する問題が、まだ、解決されていない状態です。

ストーリーボードをよく見ると、ドキュメントアウトラインの上部に赤い丸の白抜き矢印、キャンバスのビューにはオレンジの枠が表示されています。(図1)
これらは、制約の指定が適切でないために、正しいレイアウトの数値が算出できないことを警告しています。
incomplete_constraints.png
図1 不完全なレイアウト

ドキュメントアウトラインの赤い丸をクリックすると詳細が表示され、修正する場合のガイドとなります。(図2)
docoutline_const_error.png
図2 ドキュメントアウトライン

レイアウトの修正


とういうことで不完全なのか検証してみましょう。

前述のドキュメント・アウトラインを見ると、「スクロールのコンテンツの幅と高さが曖昧」と言うメッセージです。(図3)
ambiguous_size.png
図3 ドキュメント・アウトラインのメッセージ

これまでの作業で、ラベルやテキストフィールドが配置されているコンテンツ・ビューには、まだ、制約の設定は行っていません。
そのため、デフォルトの挙動である、Auto Resizing Maskからの制約の自動生成が行われています。

この曖昧さを解消するために、コンテンツエリアの幅と高さを制約で固定します。
図5に示すとおり、コンテンツ・ビューを選択してから、ピンツールをクリックします。WidthとHeightのチェックボックスをチェックして、[Add 2 Constraints]ボタンで追加します。
width_height_constraints.png
図5 Width,Heightの固定

2つの制約を追加したとたんに、オレンジ色の枠はブルーに変わり、ドキュメント・アウトラインのエラー・サインは消えました。(図6)
fixed_ambiguous_constraints.png
図6 制約を追加した結果

シミュレーターを起動して確認し、正常にスクロールすることを確認してください。

Auto Layout は比較的、新しく規定された概念です。デバッガーもありません、しかしスタンダードとして定着していくにつれてしかし今後は、重要な概念として安定して広く使用されるようになると思います。問題が起こっても、エラー/警告メッセージくらいしか出しませんし、デバッガーもありません。Xcode5も期待通りに動作しない時もがあります。これまでのアップルの充実した開発環境になれ親しんでいる我々には多少戸惑うものがありますが、これはスタンダードとして定着してゆくにつれて、徐々に整っていくものと思われます。

今回は、Auto Layout のごくさわりだけを紹介しましたが、機会を改めて、詳しく説明したいと思っています。

次回は、画面がスクロール可能になったのを踏まえて、キーボードに隠れたテキストフィールドを、入力可能な位置に再配置する方法を考えます。
posted by ayagu at 08:07| Comment(1) | iOS | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。