postgresql おすすめ本
最近mysqlよりも、postgresqlが流行ってますね！
postgresqlは、元々オプティマイザも賢くて、近年でのバージョンアップで重要な機能や、痒いところに対応しているので、かなりいい感じ。
などなど
仕事でpostgresql使うことなかったから、 サードパーティ入れないと、レプリケーションできないなど、基本機能はレベル高いが細かい機能や拡張性がないイメージが強かった。
最近では、
- heroku
など海外の大きいサービスでも使われているみたいだね〜。
というか、有名なサービスが使いだして、強化されたっていうのもある気はする。
PHPがfacebookによって、手堅くサポートされて、PHPの質が大きく上がっている気がするのと同じ。
PHPカンファレンス2014 HHVM + hack = PHP++
それは良いとして、本で学んだことを！
結構根本的な仕組みから書かれているから、とても勉強になる。
DB色々扱ったことある人で、postgresqlについて知りたい！という人には、良い本かもしれない。
構成されるプロセス
※さすがに全て記載は無理なので、わかるところは、詳細省いてあります。
- マスターサーバ (postmaster)
- 親プロセス。各プロセスをforkで起動する
- マスタープロセス以外は、全て子プロセスとして実行される
- ロガープロセス (logger process)
- チェックポイント (checkpointer process)
- ライタ (writer process)
- WALライタ (wal writer process)
- 自動バキュームランチャー (autovacuum launcher process)
- 設定にしたがって、ワーカを実行する
- 自動バキュームワーカ (autovacuum worker process)
- バキュームの実行 = 不要領域の再利用
- アナライズの実行 = 統計情報を元に、システムカタログを生成
- 統計情報コレクタ (status collector process)
- バックエンドプロセス (ユーザ名 データベース名)
root@dev:/var/log/httpd$ ps -ef | grep postgres postgres 2548 1 0 Nov01 ? 00:00:01 /usr/pgsql-9.3/bin/postmaster -p 5432 -D /var/lib/pgsql/9.3/data postgres 2591 2548 0 Nov01 ? 00:00:00 postgres: logger process postgres 2601 2548 0 Nov01 ? 00:00:00 postgres: checkpointer process postgres 2602 2548 0 Nov01 ? 00:00:01 postgres: writer process postgres 2603 2548 0 Nov01 ? 00:00:01 postgres: wal writer process postgres 2604 2548 0 Nov01 ? 00:00:01 postgres: autovacuum launcher process postgres 2605 2548 0 Nov01 ? 00:00:01 postgres: stats collector process root 13433 13146 0 04:53 pts/1 00:00:00 grep postgres
自分の環境では、バキュームワーカと、バックエンドプロセスが動いていないですね？
バックエンドプロセスは、何も要求が無い状態なので、いいのかな？
バキュームワーカは、設定ファイルの問題なのかな？ それともバキュームが動いたときだけなのかな？
メモリ
共有メモリ
- 共有バッファ
- WALバッファ
- 空き領域マップ
- 可視性マップ
プロセスメモリ
- 作業メモリ
- メンテナンス用作業メモリ
- 一時バッファ
設定ファイル
postgresql.conf
postgresqlの設定周り
- メモリ
- レプリケーション
などなど
pg_hba.conf(host-based-authentication)
認証設定用のファイル
postgresqlは、この辺りはmysqlと違うので、はじめハマる。
※上から順に評価
pg_ident.conf
外部認証の設定ファイル(ほぼ使うこと無い)
※ファイル分割し、include指示子で、統合可能
設定値の確認、変更
# 設定の確認
show all
# setで値を変更できるオプション一覧 (unitで単位も確認できる)
select name, context, unit from pg_settings where context in ('user', 'superuser');
# アクセス権やDBなど詳細情報を確認
psql -l
- すぐ反映 = user, superuser
- sighup = sighupシグナルが送信されたとき pg_ctl reloadオプションなどを使用
- postmaster = postgresql再起動
読んでて気になった時に調べたメモ
psコマンド
- aux = 一般的な現在動いているプロセスを全て表示
- a = 自分以外のユーザプロセス
- u = ユーザ名と、開始時刻表示
- x = 制御端末のないプロセス表示
- ef = 全てのプロセスをツリー状態で表示する
- e = 全プロセスを表示する？
- f = プロセスツリーを表示
拡張子
- fsm(free space map) = 空き領域を追跡するためのファイル
- vm(visibility map) = テーブルの可視性を管理するファイル
一言
こういう情報って、Qiitaにまとめるか、ブログにまとめるかとても悩む。。。
ブログってどうしても、文章的になってしまうからな〜
でも、ブログも更新したいしな〜
とりあえず、まだ読み始めなので、またpostgresqlネタで更新します。
eccubeにdebugツールをいれてみた。
全然更新できたいない。undertreeです。
EC-CUBEを触る機会が久々にあって、phpはdebugしづらいので色々いれてみた。
PHPもcomposerと、packgestが、整ってきたから、色々便利になってきたね。
とりあえず、PHPのライブラリは全然わからないので、ざっと調べてみて、
が良さそうだったのでいれてみた。
正直なところ、PHP Debug Barは、とてもいい！！
whoopsは、railsのbetter errorsっぽいから期待したけど、エラー起きたところで、print debugできないので、残念。。。
setup
whoopsは、require_base 当たりに仕込めばOK
PHP Debug Barは、色々悩んだけど、LC_Pageの
- init
- sendResponse
に追加して、
- site_frame.tpl
で、出力するように設定。
コードは簡単に記載しておきます。
※引っぱりだすのが手間なので、メイン部分だけ。多分これだけで動くはず。
documentがしっかりしているので、詳細は、PHP Debug Barのサイト見てね！
public function init()
{
...
if (DEBUG_MODE === true && class_exists("\\DebugBar\\StandardDebugBar")) {
$this->debugbar = new DebugBar\StandardDebugBar;
/**
* vendorのpublic部分だけhtml以下にコピー
* 固定リソースになってしまっているので、更新された場合は、
* applicationのroot_pathで下記を実行してください。
* cp -a vendor/maximebf/debugbar html/vendor/
*/
$requireBaseUrl = "/vendor/debugbar/src/DebugBar/Resources";
$this->debugbarRenderer = $this->debugbar->getJavascriptRenderer($requireBaseUrl);
// sample
$this->debugbar["messages"]->addMessage("debugber on!!");
}
...
public function sendResponse()
{
...
// initでdebugのinstanceが無い時は呼ばない(いろいろなところから呼ばれているので)
// sendResponseをoverrideしている部分は、表示されないので注意
if (DEBUG_MODE === true && $this->debugbarRenderer) {
$this->debugbar_header = $this->debugbarRenderer->renderHead();
$this->debugbar_render = $this->debugbarRenderer->render();
}
...
// site_frame.tpl(下記をいい感じのとこに設定)
{$debugbar_header|smarty:nodefaults}
{$debugbar_render|smarty:nodefaults}
※composerのインストール、設定は別にしてね。 autoload.php読む込むとか。
まとめ
EC-CUBEは、テストも結構かかれているし、CIの仕組みが整ってきているので、 かなりレベル上がっている気がする。
EC-CUBEの印象が悪いのは、カスタマイズの仕方があまりよくない案件を触ることが多かったからだろうか。。。
というか、PHPカンファレンス行ってから、PHPへの見方が本当に変わった気がする。
まぁー結局元凶は、言語ではなく、人だってこと。
言語は成長しているけど、人と、システム自体は意外に成長していない。ことに気づかされる。
ITの成長が早いのも関係あるが。。。
人としても、システムとしても、常に成長していける環境を作りたいと思った今日このごろでした〜〜。
※そうするには、自分はもっと早く成長しないといけないが。。。
時間もないので、駆け足でしたが、頑張ってできるだけ更新するので、よろしく！
ちなみにまだまだですが、 500pv/月 は超えそうです。 いえ〜いb
関連記事
php5.5 httpd2.4 インストール
php5.5をinstall必要があったので、メモ。
そして結論からいうと、
の通りに行えばyumから簡単にinstall可能。
remi-phpリポジトリを指定して、installするのがポイント。
そして、
- php5.5
- httpd2.4 -> 2.2
に変更。
理由は、
- httpd2.2でもいけたことと
- yumで簡単に入れられたこと
とまぁいとも簡単に完了したように見えますが、
ここにいきつくまでに、色々苦難が。。。
苦労話
そもそも、yum でも install が見つからず、make などを使って install を進めたことが問題だった。。。
することとしては、
- remiからphp55をinstall
- yumでhttpd2.2削除
- httpd2.4 install
2.までは、何も問題はなかった。が！
httpd2.4は、かなりのくせ者だった。。。
問題１ httpd2.4 依存関係 install時の postgresql93
- apr-develのバージョン1.4.0以上 (default : 1.3.9)
- distcache-develが必要（default : なし）
を入れる必要がある。
特に問題だったのが、
- apr-develのバージョン1.4.0以上 (default : 1.3.9)
これ。
rpmbuildしたときに、
apr_dbd_pgsqlが見つかりません。
意味不明。。。ものすごく悩んだが、postgresqlだったので、もしや postgresql93でpackageをいれたから、postgresqlとはパスなどが変わっているんじゃないかと。
ビンゴー！！
一度解答して、specファイルを編集し、パスを変更
--with-pgsql を削除
--with-pgsql=/usr/pgsql-9.3 を追加
再度圧縮して、rpmbuild。
いったーーー！！！b
本当手動でやると、色々大変。。。
この辺りは横着せずに、ちゃんとコンパイル時の指定可能オブションを確認するようにしないと、こういうのかなりハマるな。。。
基本yumっ子なので、この辺りの仕組みは、しっかりと理解できていないことも原因なんだろうな。。。
使うことは少ないが、根本的な知識として、一度体系的に学んでおこう。
よし、これでOKと意気揚々として、確認してたらうまくいかない。。。
問題２ libphp5.so が 作成されない
httpdから読み込む、phpもmoduleが作成されていない！！！
php55の再インストールなど色々したけどだめ。
remiからyumで入れたのが原因なのかな。と思い、コンパイルして入れようと思ったが、もうめんどくささがmaxになっていて、色々探していたら、remi-phpからのinstallにであった。
yum remove httpd
rpm -qa | grep httpd
rpm -e httpdの残骸
で、httpd関連を削除
yum remove php55*
で、php55関連を削除
// remi-phpのセットアップはページTOPのリンク参照
yum --enablerepo=remi-php55 install php
そして、サーバの設定を色々したら、うまくいった。
はぁーーーこういうのってあるよね。と。
まぁーrpm buildとか、make周りを調べたり、興味がわく機会になったのでよかったとしよう〜
今度この辺りもまとめた。
結局コンパイルでのinstallは、完了せずに終わったが、libphp5.soが生成されない問題の記事は多く出てくるので、中途半端で申し訳ないが、調べればいけると思います。
※やる人がいれば、頑張ってくださいb
念のため、資源は下記に。
rpmbuildで作っておけば、何かあったときに使えるなーと思った。 パスが違うなどあるので、個人での利用に限りますが。
今後調べたいこと
- make関連を体系的に学ぶ
- httpd2.4の特徴などについて調べる
- php5.5の設定周り
になるかな〜
とりあえず本日は、以上！
実行履歴 メモ
下記、参考リンクと、httpd2.4 install までの簡易な手順 メモなので、何が起きても保証できませんので、ご注意を〜
// rpm build setting
mkdir -p ~/rpm/{BUILD,SOURCES,SPECS,SRPMS,RPMS}
echo "%_topdir $HOME/rpm" > ~/.rpmmacros
// rpm build install
yum -y install rpm-build
// apr1.3.9 remove
sudo yum remove apr
cd ~/Donwload
// apr1.5.1 install
wget http://archive.apache.org/dist/apr/apr-1.5.1.tar.bz2
rpmbuild -tb --clean apr-1.5.1.tar.bz2
cd ../rpm/RPMS/x86_64
sudo rpm -ihv apr-1.5.1-1.x86_64.rpm apr-devel-1.5.1-1.x86_64.rpm
cd ~/Donwload
// apr1.5.3-util install
tar -jxf apr-util-1.5.3.tar.bz2
vim apr-uril-1.5.3/apr-util.spec
// --with-pgsql を削除
// --with-pgsql=/usr/pgsql-9.3 を追加
tar jcvf apr-util-1.5.3.tar.bz2 apr-util-1.5.3
rpmbuild -tb apr-util-1.5.3.tar.bz2
cd ../rpm/RPMS/x86_64
sudo rpm -ihv apr-util-*
cd ~/Donwload
// distcache install
rpmbuild --rebuild --clean distcache-1.4.5-23.src.rpm
cd ../rpm/RPMS/x86_64
rpm -ivh distcache-1.4.5-23.x86_64.rpm distcache-devel-1.4.5-23.x86_64.rpm
cd ~/Donwload
// httpd 2.4 install
sudo yum install pcre-devel lua-devel
wget http://archive.apache.org/dist/httpd/httpd-2.4.10.tar.bz2
rpmbuild -tb --clean httpd-2.4.10.tar.bz2
cd ../rpm/RPMS/x86_64
sudo rpm -ihv httpd-2.4.10-1.x86_64.rpm httpd-devel-2.4.10-1.x86_64.rpm httpd-manual-2.4.10-1.x86_64.rpm httpd-tools-2.4.10-1.x86_64.rpm mod_ssl-2.4.10-1.x86_64.rpm
ps
記事とあまり関係がないが、画像的に何か欲しいので、一冊紹介。
一番始めにサーバ周りの実践を学ぶならこれおすすめ。
あとは、Linux系のサーバコマンドリファレンス的なものを、読めばOKかな。
サーバは壊してなんぼb。※仕事ではしないでね。
ちなみに自分は、なんか変なパッケージを、yum remove して、lsコマンドも使えなくなったことがあります。。。w
サーバやってしまった集を、今度書こうかなw
PHPカンファレンス2014 HHVM + hack = PHP++
PHPカンファレンスネタも飽きてきたので、もうおおとりいきます！
HHVM + hack = PHP++
なんと！
facebook社のHHVMプロジェクト担当者直々の講演です！
もちろん、通訳の人が翻訳してくれていました！
内容は、
- HHVMについて
- hackについて
- 今後のPHP
って感じだったかな。
HHVMについて
HHVM = HipHop Virtual Machineです。
一時期話題になったのですが、まったく未知だったので、
忘れていましたが、再度聞いてこれはすごいと思いました。
概要
簡単に説明すると、
PHPの高速JIT(just in time)コンパイルです。
C++で作成されており、かなり高速みたいで、
探すといろいろベンチマークがでてきますが、だいたい、3倍くらい速くなるみたいですw
ただ、講演者の方も話していましたが、プログラムの書き方や、環境に影響されて、正しいベンチマークを取るのはかなり難しいので、実際に想定している環境を作成してみて、確認する必要があると思います。
ただ、環境を変えるだけで、3倍近く速くなったら、かなり嬉しいですね。
インストール
一応環境の構成を記載しておくと、
installは、packageとsource codeがあって、正直packageでないとしんどいです。。。
ubuntu, debianは、packageがあるので、安心です。
環境作成くらい楽チン！だと思い、centosでpackageからinstallしてみたのですが、色々エラーでてしんどいので止めました。。。
やる人は、本腰入れてやらないと断念するんで、気をつけてくださいbw
たぶん、確認するだけなら、vagrantとかに、ubuntu入れてinstallした方が楽です。
対応フレームワーク
注意点としては、全てのフレームワークに対応しているわけではないので、入れる場合は確認してください。
一応現在は、26フレームワーク 100% 対応しているので、結構使えると思います。
使っている企業
一応これが、HHVMを使っている企業サービスになります。
結構大きいところが導入してるみたいですね。
導入は苦労しそうですが、ノウハウが溜まれば強みにもなると思います。
それにfacebookは、本気なのでなくなることは無いと思います。
まず無いと思いますが、もし、facebookがつぶれてもOSSなので、どこかが引きついでやる気もします。
その他
ちなみにhhvm document関連は、かなりしっかりしています。
ただ！全て英語ですbw
さて、次は、hackについて！
hack
概要
主な機能としては、
になります。
型周りが中心で、LL言語しか触ってこなかったので、ほとんどの機能を知りませんでいた。。。
でも、引数と返り値の型指定は、いいな〜と思いました。
結構帰ってくる型が曖昧で、返却値の想定もしにくく、バグに繋がることは多い気がするので。。。
インストール
インストールは、HHVMが入っていればOKです。
使い方
チュートリアルがわかりやすので、ぜひ！
3 その他
hack document関連は、こちらも全て英語ですが、 リファレンスや、チュートリアルまであるので、わかりやすいと思います。
基本PHPの最近の機能に関しては、カバーしているみたいで、むしろ、ジェネレーターなどは、hackが先行していて、標準のPHPに入れてもらえるよう話したようです。
今後のPHP
ちょっと私自身がHHVMのインストールや、hackでコードを書いたことがないので、
正直詳しいことはかけていないのが、申し訳ないのですが、
話を聞いてても、調べていても面白そうで、今後期待できることは間違いない気がします。
機会があれば、仕事での導入を想定して、色々調べてみたいですね。
で、まとめなのですが、
facebookは、PHPをリードしてくれている素晴らしい企業です。
facebookは、ほぼ100% HHVM, hackに移行しているみたいで、
PHPにここまで力を入れているので、他の言語に移ることは、ほぼ無いとおっしゃってました。
なので、今後もfacebookの協力なサポートが期待できると思います。
それに、PHPの仕様についてをこと細かくまとめた、documentも作成してくれています。
HHVM, hackなどのdocumentといい、この徹底ぶりはすごいと思います。
安心するのと同時に、PHPも面白くなってきたな〜と感じましたね。
が、英語が結構スラスラ読めないと辛いです。。。
あぁ〜改めて学生のことにもっとちゃんと英語やっておけば良かったと思う、今日この頃でした。。。
まとめ
これで、PHPカンファレンス2014 については、終わり。
正直PHPには、ずっと使ってきて、あまり将来性を感じていなかったが、今回PHPカンファレンスに参加して、すごく考え方が変わった。
初参加だったが、とてもいい経験になった。
PHPカンファレンス過去記事一覧
※うまく過去記事リンクできなかったので。。。
面白そうなのがあったので、買ってみました。(400円 やすい！) これから読んでみますb
PHPカンファレンス2014 講演02 PHPerがAWSとであってDevOpsを目指した話
PHPカンファレンス2014 各講演の続きです！
概要
今度は、Rettyの人の話です。
Rettyとは、
食べログと同じ系統の飲食関連の口コミサイトですね。
今は、500万ユーザ近くの方に利用されているみたいです。
個人的には、スマフォアプリのクオリティは、かなり高いと思います。
行ってみたいお店とかをすぐに登録できるので、ちょっと話に上がったお店をメモっておくのには、とても使いやすいので、おすすめです。
500万ユーザにもなると、やはりサーバの運用管理などが大変みたいで、 試行錯誤して選択した、おすすめの構成や、ツールをお話してくれました。
AWSの話
※注意書き：えっと。PHP全く関係ないです。PHPのデプロイツールとかの話はまったくないので、そういう情報を当てにしている人は、申し訳ないです。
まず、サーバの経緯を話すと、
- 10万ユーザ = サーバ１台(スケールアップで対応？)
- 50万ユーザ = AWSアーキテクトにのせかえ
- 100万ユーザ = オートスケールなどを使って、スケールアウトし始める
- 200万ユーザ ~ 400万 = 本格的にAWSのアーキテクトにそった構成にする
- 500万ユーザ = AWSのアーキテクトにそって、さらに試行錯誤
という感じらしいです。
やはりあまり、はじめからAWSというのは、聞かないですね。
ある程度のコストはかかるので、はじめから、AWSという訳にはなかなかいかないのですかね？
しかし、それが影響し、64bitでないと使用できないAWSの機能も多いらしく、
AWSの本格的な移行には、かなり大変だったみたいです。
また、mysql5.5だと、5台までのレプリケーションができないなど、大規模なスケールアウトを想定するのであれば、いろいろ対応が必要になるみたいです。
時間がないので、まとめで。。。
とりあえず言えることは、
- 人を使わず、金で解決 => AWS(効率化)
- AWSを便利に使うために、運用の整備をするようになる(バージョンアップなど)
- 色々な良い恩恵が受けられる => 運用安定する
- 生活が安定する => 社員がハッピーになる
- コード書ける時間が増える => 開発もうまくいく
- サービスに注力できる => みんなハッピー
になろうということだと感じました！
また、少人数で、開発も運用もこなすことで、開発時に運用のことも考慮できるので、よりより開発が出来るのだと思います。
開発と運用グループの壁みたいなのもなくなるしね。
私もこういう環境を作れたらいいな〜と思いました。
AWSのアーキテクト周りや、mysqlのバージョンの話は、時間がないので、また書きます！！！
以上！！
遅刻する。。。
PHPカンファレンス2014 講演01 メルカリの超高速開発を支えるPHP
数日は、PHPカンファレンス2014の講演について、書いていきます。
フリマアプリ「メルカリ」の超高速開発を支える PHP
メルカリについて
CMでおなじみの「メルカリ」
CtoCのフリマアプリで、ものすごくのびているサービスですね。
フリマの今の状況
- 「Frill」（41.6％）
- 「メルカリ」（36.5％）
- 「LINE MALL」（26.9％）
ちなみに、Frillだけ聞いたこと無くて、検索したら、18禁エロゲーらしきものが、一番上に出てくるので、気をつけてくださいbw
一瞬、ん？？？ってなりました。
話は戻りまして、
メルカリは今や、日本で一番急成長しているとも言われているようです。
- 設立：2013年2月1日(1年半)
- 資本金：17億5,026万円(3/31 14億5000万調達)
- アプリダウンロード数：500万ダウンロード
- 流通総額：数十億円/月
1年半？嘘でしょ？
- 流通総額：数十億円/月
だと、おおよそで単純に考えても、10月から手数料が販売額の10%らしいので、
10億の10%だとしても、1億/月。
ECと違ってそこまで、コストかかっていないだろうか儲かっているだろうな。
10月からの手数料10%が、どこまで受け入れられるかなんだろうけど。
メルカリのシステムについて
とまぁー会社に関しては、そこそこにして、
メルカリがすごい会社だというのは、お分かり頂けたと思います。
では、言語は何を使っているのでしょうか？
は、当たり前ですが、バック(API)側に関しては、PHPを使っているみたいです。
※もしかしたら、webViewなのかな。
結構意外ですよね。
昨今スタートアップは、LL言語でも、rubyやpythonが多いけれど、あえてPHPを選択したみたいです。
PHPを選択した理由
答えは簡単で、
- 開発リソースの確保 ☆
- 役員4人全員がPHPを書けた
からだそうです。
役員が全員システム作成に関わったことがある。ということも注目したいのですが、
なにより、☆のついている、開発リソースの確保は、なるほど。と思いました。
ビジネス観点からすると、スピードというのは、とても大事で、
なぜか？というと
①ある程度のシステムというのは、簡単にまねされてしまう。
つまり、まねされるより速く作成する必要がある。
②多くのユーザを確保するため
同じようなサービスだった場合、はじめに登録した方を使い続けることが多い。
③たくさんの経験をするため
未知の領域も多いので、PDCAなどのサイクルを、高速で回す必要がある。
の３点かな？
なので、特にサービスの立ち上がりは、とてもスピードが大事なのです。
簡単にいうと、差別化が難しい時点でのどんぐりの背比べで勝つには、スピードが重要！ということなんですかね。
また、facebookでも
done is butter than prefect.
「 完璧を目指すより、まず終わらせろ 」
という習慣があるみたいです。
100点より、早めの80点ってのと同じ理由ですね。
そして、スピードを重視するには、開発リソースが必須になる訳です。
つまり、開発者がたくさんいれば、速く作れるよね。という考えです。
しかし、これはある意味、人海戦術中心的な考えなので、エンジニア界隈ではあまり好かれない方式だといます。
なので、リソースは少ないが、生産性の高いrubyやpythonが選ばれるのだと思います。
これは、とても難しい問題なのですが、メルカリさんは、ある言葉を付け加えたら、
すんなり解決しました。
それは...
「 スピードのために全てを捨ててはいけない 」
つまり、
「 テストの自動化は、必ずやるべき 」
とのことです。
Unitテスト
全てやるのではなく、未来のエンジニアを何人救えるか。という視点。
E2Eテスト
I/Oのテストなので、コードに左右されず、費用対効果が高いので、テスト自動化のメイン。
技術とビジネス両方の視点をしっかりと持っている優秀な会社だな〜。という感想でした。
システム選定の仕方(まとめ)
つまり、導入する言語の判断基準は人は、
- 開発リソースの状況
- 生産性
- Unitテストの導入は簡易か
- E2Eテストの導入は簡易か
が、大きいのかもしれないですね。
創業者で信頼できるエンジニアがいれば、生産性重視で良いかもしれませんが、
いないのであれば、PHPなど開発リソースが確保しやすい方がいいのかも知れないですね。
生産性重視でやってきて、いきなり、要の人がいなくなると、正直きついので。。。
逆にいうと、PHPはある程度つぶしが効くので、怖いっちゃ怖いですが。
でも、どの言語も常に改善されていて、生産性を高めることは、おおいに出来ると思うので、
問題は修復不可能なレガシーなシステムにしない。ということ。
そのためにも自動テストは必須項目なのかもしれないですね。
今回のネタは、以前の技術負債の話とも関連するので、良ければぜひ！
PHPカンファレンス2014!! 初参加!!
今日は、PHPカンファレンスに初めて参加してきた。
はじめのPHP5.5のメイントークに遅刻して、PHP5.5の詳細はよく聞けなかった・・・
ので、調べてまとめておきます。
追加機能
- オペコードキャッシュ
- ジェネレーター
- 例外のfinally追加
- パスワード専用のハッシュ関数
- trait(php5.4)
オペコードキャッシュ
PHPは、オペコードという内部状態に変換されたあと、実行されるのですが、 毎回オペコードに変換していると時間がかかるので、オペコードをキャッシュさせて、 実行時間を速めようというものらしいです。
今までの為替だと、APCがそれに当たるみたいですね。
簡単にいうと、
APCを本体に組み込んで、標準機能とした。
というのが、わかりやすいかもしれないです。
※正しくは、zendが作った、Zend Optimizer+（ZO+）= opcacheという機能が組み込まれたらしいです。
ちなみに、初期設定では、未使用になっているので、 php.iniで、extensionを読み込ませる必要があるみたいです。
zend_extension=opcache.so
ジェネレーター
PHPにもとうとうジェネレーターが！！
自分も詳細はうまく説明できないので、のちほどしっかり調べて記載します。
ジェネレータは、プログラムにおいて、数列の各要素の値などを次々と生成（ジェネレート）し他の手続きに渡す、という機能を持っている手続きである。値を渡す方法としては、コールバックのようにして他の手続きを呼ぶものもあれば、呼び出される度に次々と異なる値を返す関数であることもある。
by wiki
簡単に説明すると、対象の関数を呼びだしたときに、yieldと指定している部分で、 値を生成して渡す。
かつ、次回開始するときは、その地点から開始する。という感じかな。
例文をみるとわかりやすい。
どこからの記事で、ドラクエの宿屋的なイメージ。と書いてあったのが、面白かったw
※ようは、セーブできて、セーブ時点から開始することを言いたかったのだと思う。
調べていると、イテレータとの区別もしっかりあるようなので、今度ジェネレーターと一緒にまとめます。
※イテレータ = 再起処理、無名関数を含む様なループ関連などと、単純な認識しかなかったので、これを気に調べておきます。
例外のfinally追加
例外の有無に関係なく、必ず実行される部分ですね。 javaだと普通にある感じみたいです。
パスワード専用のハッシュ関数
これは地味に助かりますね。
sha1, md5などいろいろ暗号化方式があって、わかっている人はいいのですが、
適当に使う人もいなくもない気がするので、
ここまで、明示的にpassword用と分かれば、そのようなことはなくなるし、
関数名がわかりやすくていい。
それに、cryptのラッパーになっているらしく、アルゴリズムの選定、ソルトの指定などを自動で行ってくれるとのことなので、今後変わったとしても、うまくやっくれれば、いちいち関数変えなくても、レベルの高い暗号化を保てそう。
trait
これは、php5.4の機能なんだけど、絶対便利なので、記載しておきます。
単一継承しかできないPHPですが、これを使えば擬似的な多準継承的なことができます。
どっちかというと、用途としては、Mix-inに近いだと思いますが、便利です！
詳細や、事例はまた今後。
詳しく知りたい人は、比較的わかりやすく書いてありますよー。
各講演
- フリマアプリ「メルカリ」の超高速開発を支える PHP
- PHPerがAWSと出会ってDevOpsを目指した話
- PHPにおけるI/O多重化とyield
- HHVM + Hack == PHP++(※通訳あり)
に参加しました！
まず感想としては、PHPも最新のバージョンを追えば、PHPも全然ありだと思う。
あとは、結局コードを書く人の質。
最近はコードレビューが一般化してきているので、レベルの高いコードを書く人がいて、先導していれば、PHPでも全く問題ないと思う。
ただ、レガシーなシステムが多く、PHP5.2とかになると、comporse使えなくて、
ライブラリ管理しづらいし、使えないライブラリも多いから本当に困る。
最新のバージョンを追えるようにすることが、一番大事かなと感じた。
詳細は、後日少しずつ書いていきまーす。
