PHP7からHHVMに移行する&ベンチマーク

HHVM(HipHop Virtual Machine)とは

HHVMは、Facebookが作成したPHP互換の仮想マシンです。

JITコンパイルを採用しており、パフォーマンス向上を目指しています。

割と歴史があるようで、PHP7のない2014年ごろから爆速仮想マシンと言われていたみたいですが、
PHP7が早いよすげーって感じで埋もれたようです。(2016年に日本語情報が全く無い)

でもこちらも長い時間をかけて速度向上しているようで、

今でもベンチマークをとった感じPHP7と比較しても30%以上早いんじゃ無いかという感じです。

というより早すぎてビビる。

裏でファイル情報を読み込みまくるプログラムなんかは、レスポンスが2倍くらい早くなりました。

この辺りネイティブコードが強いんだろうなという感じ。

Hack言語というAltPHPな言語も使えますが、PHP5.6ベースであり、そのままのPHPコードでも動作します。

(ここではHack言語には一切触れませんが、イメージとしてはJavaScriptとTypeScriptの関係みたいな感じです)

そのためPHP7で廃止になってしまったメソッドも含まれていますが、もちろんPHP7の機能も使えます。

ここまで利点があるのにでもやっぱり日本だと知名度無い・・・無く無い?

もう開発期間もかなり経ってますしFacebookで実運用されていることから、かなり安定しているのでは?と思うのですがね。

インストール

とりあえず公式を見ているとyumリポジトリも無くそもそもGetting Starterに無いので

「CentOSじゃなくてUbuntu/Debianを使え」って感じですが、

そんなこといってもこのサーバはCentOSなので、CentOS向けに構築します。

Ubuntu/Debianであれば、おなじみのapt-getで簡単セットアップできます。羨ましい。

building-and-installing-hhvm-on-centos-7.x

ここに書いてあるやり方で、最新バージョンではビルドが通りませんでした。

どうやら最新のバージョンでは、依存するライブラリのバージョン(GCCとか)がCentOS7の公式yumリポジトリでは古いため、

多くのライブラリやコンパイラをソースビルドする必要があるようです。

building-and-installing-hhvm-on-centos-6.6

ここに書いてある方法を実践すればCentOS6でも7でもいけると思いますが、

かなりのパッケージをソースビルドする必要があり、非常に時間がかかるためちょっと断念。

そのため、公式から現状で一番手軽に入れられるであろうプレビルド版3.15.3を使用します。

rpmを使用してインストールします。yumよりは手間ですが、ソースビルドを考えるともの凄く楽ですね。

Prebuilt-Packages-on-Centos-7.x

ここに書いてあることを実践すればすぐにインストールできました。

yum install cpp gcc-c++ cmake git psmisc {binutils,boost,jemalloc,numactl}-devel \
{ImageMagick,sqlite,tbb,bzip2,openldap,readline,elfutils-libelf,gmp,lz4,pcre}-devel \
lib{xslt,event,yaml,vpx,png,zip,icu,mcrypt,memcached,cap,dwarf}-devel \
{unixODBC,expat,mariadb}-devel lib{edit,curl,xml2,xslt}-devel \
glog-devel oniguruma-devel ocaml gperf enca libjpeg-turbo-devel openssl-devel \
mariadb mariadb-server make libc-client -y

rpm -Uvh http://mirrors.linuxeye.com/hhvm-repo/7/x86_64/hhvm-3.15.3-1.el7.centos.x86_64.rpm

hhvm --version
HipHop VM 3.15.3 (rel)
Compiler: tags/HHVM-3.15.3-0-g965cd8d30670726d88720412c3384225a2da011d
Repo schema: 7f22464926cb7fc3a19c6af88309c612a8581c55

ビルトインウェブサーバーで使用する

PHP仮想マシンなので、基本的にはPHPと同じように使えます。

テストとして、PHPと同じようにビルトインウェブサーバー機能を使ってみましょう。

PHPソースも特に変更する必要はありません。 phpinfo() も使えます。

# PHPの場合
cd ~/html/
php -S localhost:8000

# HHVMの場合
cd ~/html/
hhvm -m server -p 8000

Nginx+HHVM(FastCGI Mode)で使用

実環境するのであれば、Nginx+PHP-FPMが今の環境です。

やはり稼働も大変なんでしょう?と思いがちですが、
PHP-FPMをそのままHHVM(FastCGI Mode)に差し替えるだけでOK。

うまくやればNginx側の設定は一切変更なし or 一行変更でいけます。

設定ファイルは/etc/hhvm/server.iniで設定を行います。

しかし最初から最適化されていたりもするので、ほぼ設定なしでもそれなりに動きます。すげえぜ。

# ログディレクトリを設定
mkdir /var/log/hhvm/
chown nginx -R /var/log/hhvm/
chgrp nginx -R /var/log/hhvm/

# runディレクトリの設定
mkdir /var/run/hhvm
chown nginx -R /var/run/hhvm/
chgrp nginx -R /var/run/hhvm/

# php-fpmをストップ。この時点でPHPは動かなくなるので慎重に
systemctl stop php-fpm

# service
systemctl enable hhvm
systemctl start hhvm

/etc/hhvm/server.ini


; hhvm specific hhvm.pid_file = "/var/log/hhvm/pid" hhvm.server.port = 9001 ;hhvm.server.file_socket = /var/run/hhvm/hhvm.sock hhvm.server.type = fastcgi # 略 date.timezone = Asia/Tokyo

/etc/nginx/conf.d/nginx.conf

# 前略 ほぼ変更なし
        fastcgi_pass   127.0.0.1:9001;
        fastcgi_pass unix:/var/run/hhvm/hhvm.sock;
# 後略

WordPressでベンチマーク

簡単にApache Benchを使ったベンチマークもやってみましょう。

そのまま、このブログを対象としています。
そう、このブログは既にHHVMに移行済みです。

Nginx + php-fpm(PHP7)版

ab -n 500 -c 100 https://blog.potproject.net/

Concurrency Level:      100
Time taken for tests:   76.811 seconds
Complete requests:      500
Failed requests:        0
Total transferred:      41469000 bytes
HTML transferred:       41329000 bytes
Requests per second:    6.51 [#/sec] (mean)
Time per request:       15362.273 [ms] (mean)
Time per request:       153.623 [ms] (mean, across all concurrent requests)
Transfer rate:          527.23 [Kbytes/sec] received

Nginx + HHVM(FastCGI Mode)版

ab -n 500 -c 100 https://blog.potproject.net/

Concurrency Level:      100
Time taken for tests:   24.787 seconds
Complete requests:      500
Failed requests:        0
Total transferred:      41467500 bytes
HTML transferred:       41329000 bytes
Requests per second:    20.17 [#/sec] (mean)
Time per request:       4957.490 [ms] (mean)
Time per request:       49.575 [ms] (mean, across all concurrent requests)
Transfer rate:          1633.71 [Kbytes/sec] received

処理によっては速度はまちまちですし、場合によってはPHP7の方が早いかもしれませんが、
これだけでも爆速の恩恵がわかると思います。単純比較で3倍ですよ。こりゃ早え。

とりあえず、日本での知名度は上げたいですね。

まあ、スルーしていてどういうのかは自分も最近どういうものか知ったわけなので人のこと言えませんが・・・

(なんか名前的に難しそうで・・・HHVM/Hackだもんなあ・・・)

React Native製Mastodonクライアント「ikuradon」をgithubで公開しました。

potproject/ikuradon

React Nativeの勉強のためにちまちまと作ってたアプリなのですが、

最近、せっかくなので何かOSSとして公開したいなーと思っていたので公開します。アプリ名も安直です。

React Native、色々言われてる割には国内でのちゃんとしたアプリのソース公開も少ないので、参考になればいいんですけども。

内部のライブラリにReact Redux,React Navigationを使用しています。

Reduxは覚えるのに苦労しつつ、この実装でいいのか今もイマイチな感じがあるのですが、全体のデータを管理出来るので、Reduxか似たようなものが無いと設計段階でやはりキツいです。

まだまだ開発途中で、一部遷移が遅かったり、そもそも動かなかったりしますが、そこはちゃんと整備します。デザインも変えていくので許して。

とりあえず今のところはタイムライン表示機能とfav,boost,普通のTootとまあ本当に最低限の機能という感じ。

開発期間は割と短いし、Androidでは一切検証してなかったけど大体普通に動きます(バグあるけど)。

React Native(というかExpo)開発に関して

とりあえず、Expoが本当にすごい。

コード更新即反映即立ち上げのHot Reload機能、その他役に立つ解析機能やAPIなどかなり開発速度を早くできたのもこのおかげです。

そしてWindowsでも実機でiOSネイティブ開発出来ちゃいます。わざわざ埃被ってるMacBookを出さなくていいです。

ネックなのはデバッグモードがかなり遅いところですねえ。そのせいで本番と挙動が違う部分も出てきたりします。
この部分はアップデートとProduction Modeが追加されてかなりマシになったと思います。でもネイティブビルドと比べると遅いけどそれはしょうがない。

速度的には充分ネイティブ並みに動いてると感じます。UI自体はネイティブですし、よくあるUI部分を同期的に書いてフリーズする、みたいなことも基本無くてよろしい。
デフォルトでES6とES7の一部分をサポートとしており、JS界隈でありがちな「初期の構築いろいろあり過ぎて辛い」もなく、await/asyncが使えるのは非常に便利です。

開発は楽で楽しいんですけど=簡単に作れるってわけではないと思います。そもそもReactやRedux、ES6の知識が必要ですし。

WebSocketもデフォルトでサポートされていたので、Streaming APIの対応もすんなりいきました。100行程度でいけます。強いです。

動かし方

上でも書いたとおり、Expoというアプリを使用します。このアプリをダウンロードして、このCDNリンクからQRコードを読み込むだけ。

開発なら、cloneした後npm installからnpm startでQRコードが出てきます。これで終わり。後は同じ。

自分もこれで実機のiOSで開発しています。ほぼnpmで事足りるのでホームページからわざわざSDKダウンロードしたりすることも無し。なんともモダンって感じの開発環境です。

App StoreやGoogle Playの公開はもうちょっとできてから考えようって感じです。

また、時間があれば開発での辛いところとか書いていきます。

React Nativeのルーティングライブラリ比較

ルーティング(Router)ライブラリとは、画面遷移や戻る、進むなどを行うライブラリのことです。

WebではSPAのページを作成するときに必要なため、SPAでなければ使用することも無いと思いますが、

React Native単体ではルーター機能はほぼ無いに等しく、現在のバージョンではNavigatorIOSというAPIしかありません。

名前が示す通り、Androidでは使用できないため、これは使えません。

画面遷移を含まないアプリなんてまず無いと思いますので、RNアプリ作成するにはRouterライブラリは必須です。

RNで使用できるルーティングライブラリの上位3つを比較してみました。

主にこの3つがメインかなと思います。

一応、アプリ開発で全て触ってます。上から順に使っていった感じです。

そして、最終的にReact Navigationに落ち着きましたという記事です。

React Native Navigation

wix/react-native-navigation

★Star 4300 NativeModule使用

App-wide support for 100% native navigation with an easy cross-platform interface.

利点:

  • ネイティブの処理で遷移するため、速い。そのため、デザインもネイティブベースである。

欠点:

  • ネイティブモジュールを使用しているため、Expoを使用できない
  • ネイティブで動作するため、カスタマイズ性は低い

個人的に:
Reduxサポートはしているみたいだが、公式のredux-exampleがdeprecatedだったり、イマイチ書き方がわからなかった。ちょっとドキュメントが整備されていない?

AndroidとiOSでの表示のプレビューなどもないため、よくわからなかったという感じでした。

一番速度的には速いと思うのだが、Expoで開発したいというのもあるため、非採用

React Native Router

aksonov/react-native-router-flux

★Star 5200

First Declarative React Native Router

利点:

  • カスタマイズ性が高く作られている。NavBar/TabBar部分に独自のcomponentsを表示できる
  • react-routerライクで作られているため、使ったことのある人は入りやすい

欠点:

  • 独自な分、NavBar/TabBarっぽいデザインが用意されていない。デザインを作って指定する必要がある

個人的に:

たとえば公式APIにTabBarIOSがあるが、Androidには存在しない
そのため、iOSとAndroidでTabのデザインを分けるか、独自でデザインを作る必要が出てくる、それはやりたくないため見送り。

※ここで話しているのはv3の話です。v4ではReact Navigationがベースにカスタマイズ出来るよという感じらしいので、

デザインはReact Navigationと同じようなものが使えると思います。
v4が正式になったら、こっちのほうを採用したかも・・・

React Navigation

react-community/react-navigation

★Star 6400

Learn once, navigate anywhere.

利点:

  • ネイティブっぽいデザインがデフォルトであり、少ないコードで割とすぐにそれっぽく作れる。
  • AndroidとiOSでiOSはTabbar、AndroidはTabLayoutっぽいデザインになる。
  • Star数も一番多い。ドキュメントが豊富

欠点:

  • rnrfよりはカスタマイズ性は劣る。わかりやすいけどtitleをComponentsのstaticで指定する部分とか一部トリッキーだったりもする。

個人的に:

React Community製のライブラリ。
一番ドキュメントが充実しており、同じようにReact Community製のReduxサポートが充実していてわかりやすかった。

ネイティブっぽいデザインがデフォルトで表示され、開発しやすい。

rnrfよりはカスタマイズ性は劣るが、ネイティブっぽい表示が目的だったため現在これで開発中。

  • 動作速度重視ならReact Native Navigation
  • カスタマイズ性重視ならReact Native Router
  • 開発速度重視ならReact Navigation

という感じで、うまいこと差別化ができていると思います。

一番困るのは非常に名前が紛らわしい点でした。特にnpmは似たような名前のスパムすらあるから困る。

(今作ってるRNアプリはOSSとして公開するつもり。明日。頑張ろう。)

HTTP/2とTLSv1.3(draft-20)をnginx+OpenSSLで対応させる

せっかくなので、当サイトはhttp2に正式対応しました。

昔やったはずじゃ・・・と思っていたのですが、

http/2と似て非なるほぼ同じSPDYの対応でした。

SPDYはいつの間にやらchromeではhttp/2扱いされなくなり(googleが作ったのに)、chrome 51から非対応となってしまいました。

ということでこのブログもhttp1.1に戻っていたので、正式にhttp/2に対応しました。
この辺は別の話なのでこの記事が詳しいです。

EC2+nginxでhttp2対応できたとおもったらできてなかった話。(解決します)

ついでに、当サイトはTLSv1.3(draft-20)に対応しました(多分)。

なお、言っておきますが 現状のブラウザでは見れません。

新しくブラウザが出たとしても見れるかもわかりません。

正直まだstandardになってないですし、仕様は変更されるでしょうし、現状ここでの対応はほぼ無意味です。

ただ、TLSv1.3が正式対応になりOpenSSL1.1.1が正式リリースした時はこの記事は役立つと思います。多分。

OpenSSLのTLS1.3実装に関しては公式が使用方法を書いています。これがとても詳しいです。
Using TLS1.3 With OpenSSL

コネクションの方法など難しいところは置いておくとして、
実際に使用するところで気になるのは暗号化スイートがTLS1.3専用のものが用意されています。

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

OpenSSLの現在の実装でTLS1.3はこの5つしかサポートされていません。

これ以外を使用してTLSv1.3認証を行おうとすると、当然ですが認証に失敗します。

そのためTLS1.2以下と併用するためにはTLS1.3の時だけ上のスイートを優先する必要があります。

nginx+OpenSSLでのTLSv1.3対応

nginxのmailline versionの最新版1.13.0にて、"ssl_protocols" でTLSv1.3を選択できるようになりました。

*) Feature: the "TLSv1.3" parameter of the "ssl_protocols" directive.

そのため、おなじみの構成であるnginx+OpenSSLでTLSv1.3を使えるようになります(厳密にはなる予定です)。

使用するnginxは1.13.0、OpenSSLは1.1.1-dev(master)です。

OpenSSLはTLSv1.3が正式になったら1.1.1をリリースすると言っていますので、実際に正式になった時もこの設定で動くと思います。

OpenSSL1.1.1(dev)のインストール

リポジトリなどではなくgitからmasterを落としてビルドします。gccなどが必要です。

後、libssl.soが無いと怒られたりしたので/usr/local/lib64/に動的リンクを貼ったりpathを通したりして動きました。

cd /usr/local/src/
git clone https://github.com/openssl/openssl
cd openssl
./config enable-tls1_3
make
make test
make install

/usr/local/bin/openssl version
OpenSSL 1.1.1-dev  xx XXX xxxx

nginx 1.13.0のインストール

こちらはリポジトリはあるのですが、OpenSSLを組み込む関係でこちらもソースコードからビルドが必要です。

このやり方だとyumなどで本体に入っているnginxは削除しました。

configureのオプションは各自吟味してください。

cd /usr/local/src/
wget http://nginx.org/download/nginx-1.13.0.tar.gz
tar zxvf nginx-1.13.0.tar.gz
cd nginx-1.13.0
./configure --prefix=/etc/nginx --sbin-path=/usr/local/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3
make
make install

ここで重要なのは--with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3です。
–with-opensslは先ほどのopensslのソースコードのpathです。nginxにバンドルします。

–with-http_v2_moduleはhttp/2対応のため、–with-openssl-opt=enable-tls1_3も設定しないと動きませんでした。

なので使うだけならOpenSSL1.1.1(dev)をmake installする必要ないのですが、openssl s_clientを使用するために使います。

あとはpathを通して、nginx -V で確認します。うまくいけば下のようになっているはずです。

nginx version: nginx/1.13.0
built by gcc <略>
built with OpenSSL 1.1.1-dev  xx XXX xxxx
TLS SNI support enabled
configure arguments: <略> --with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3

nginx設定

既にSSL設定が終わっているなら、このあたりの設定を変更するとOKです。再起動も忘れずに。

ssl.conf

#TLSv1.3用設定
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:ECDHE:!COMPLEMENTOFDEFAULT';

#http2用設定
listen 443 ssl http2

SSLv1.3の接続確認

最初に言ったようにブラウザだと確認できませんでした・・・draft-18のものはchromeのchrome://flags/でTLS1.3を指定すると見れます。

https://tls13.crypto.mozilla.org/

このサイトを見るとdraft-18対応済みのchrome/firefoxでは正常に確認でき、TLS1.3と表示されているのがわかります。

対応していないとchromeでは「サポートされていないプロトコルが使用されています」というレアな画面が出ます。

OpenSSLのSSL/TLS client機能で接続確認します。1.1.1は-tls1_3オプションでTLSv1.3で接続しに行きます。
一部省略。

>openssl s_client -connect blog.potproject.net:443 -tls1_3
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:CN = potproject.net
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate

subject=CN = potproject.net

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3026 bytes and written 270 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS13-AES-128-GCM-SHA256
    Session-ID:
    Session-ID-ctx:
    Master-Key: <master-key>
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: <StartTime>
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
---

これで正しいのかイマイチわかりませんが、TLS1.3認証は出来ていることが確認できます。

TLSv1.3の正式に決まるまでもう日は近いと思うので、その時にすぐに対応できればいいな・・・

Facebook PHP SDK v3.2.3でGraph API のバージョンを変更する

今回はいつもと趣向を変えた、バッドノウハウです。

Facebook PHP SDK v3.2.3は、名前の通りFacebookのGraph APIを叩くためのSDKですが、
2015年1月の時点でdeprecated(非推奨)となっております。2年前です。

非推奨というだけで今までは使用できたのですが、このSDKはGraph APIv2.2を使用しているため、利用期限が過ぎ、完全にこのままでは使えなくなりました。

使用期限:2017年3月25日

https://developers.facebook.com/docs/apps/changelog?locale=ja_JP

なので、現在推奨されているFacebook SDK for PHP (v5)を使用しましょう。

で、本来はそこで終了なのですが、実際はそうもいかない人たちもいるようで・・・
Facebook SDK for PHP (v5)はPHP5.3非対応のため、PHP5.3の場合は、このSDKを使用しているところもあります。
PHPバージョンのシェア率を見ると、PHP5.3以下はまだ 25% も存在するようです。
自分もその被害者のため、完全にバッドノウハウなわけですが、対応方法を書いておきます。

この方法で、最新バージョンのv2.8まで動作しました。しかし、完全に動作するとは思わないほうがいいです。
何時使えなくなるかもわからない綱渡り的な状態であり、応急処置みたいなものなので、早いところPHPのバージョンを上げましょう。

参考:facebook graph api not work from 2.2 to 2.3
http://stackoverflow.com/questions/42994019/facebook-graph-api-not-work-from-2-2-to-2-3

まず、バージョンを変更します。デフォルトではv2.2を使用するようになっていますが、そこを明示的に指定することで、バージョンを指定することが出来ます。
v2.8であれば/v2.8/という風にURLを変更します。v2.3にしたほうが無難だと思います。

facebook-php-sdk/src/base_facebook.php 164行目付近

  public static $DOMAIN_MAP = array(
    'api'         => 'https://api.facebook.com/v2.8/',
    'api_video'   => 'https://api-video.facebook.com/v2.8/',
    'api_read'    => 'https://api-read.facebook.com/v2.8/',
    'graph'       => 'https://graph.facebook.com/v2.8/',
    'graph_video' => 'https://graph-video.facebook.com/v2.8/',
    'www'         => 'https://www.facebook.com/v2.8/',
  );

これだけでは動きません。Graph API v2.3から、アクセストークンを取得した時の振る舞いが変更され、配列からjsonを返すように変更されたためです。
そのため、返ってきたjsonをArrayに変換することで動くようにします。
2箇所同じような部分があるので、そこも同じように変更します。両方変更しないとユーザアクセストークンなどが取得できなかったりします。

facebook-php-sdk/src/base_facebook.php 413行目
facebook-php-sdk/src/base_facebook.php 808行目

    $response_params = array();
    parse_str($access_token_response, $response_params);

この部分を以下のように変更します。

    //$response_params = array();
    $response_params = json_decode($access_token_response, true);

これでとりあえずは指定したGraph APIで動作するようになります(v2.3,v2.8以外未確認です)。
OAuthログイン、/me/、/me/account/、/feed/などは動作確認済みです。

もう一度言いますが、PHP5.4以上の方はFacebook SDK for PHP (v5)を使用しましょう。

最近のコーディングとか

potproject.net Advent Calendar 201613日目の記事です。

まだ半分か・・・。


最近のコーディングは、結局いろいろ使ってきたりしたのですが、v1.0になってそれなりに使えるようになり、
現在はv1.7まで上がりかなり安定してきたかなということで、Visual Studio Codeを使ってます。
略してVSCode。

Visual Studio Code – Code Editing. Redefined

多分、このブログを始めたより後にできたエディタじゃないですかね?それくらい新しいエディタだと思います。
Visual Studioは有名なIDEですが、別に互換性があるとかナンバリングじゃなく、全くの別物で、こちらはテキストエディタに近いです(デバッグ機能とかあるけど)
自分が一番気に入っているエディタといえば(今は)これなんで、布教活動でもしていきます。

1.Macでも使える

Visual StudioなのでMicrosoftが開発しています。でも公式サイトにもMac版が普通に提供され、使用できます。
と思ったのですが、つい最近Visual StudioもMac対応を出す予定でしたね。
でもこっちはオープンソースなので、開発当初からWindows/Mac/Linuxとマルチプラットフォーム対応で使いやすいです。
しかも一説によればWindowsよりMacの方が動作が軽いとか聞きます・・・。それもそれでどうなんだ。

2.同じ系統のエディタであるatom.ioやBracketsよりも軽い(体感)

atom.io,Brackets,VSCode
この3つはどれもWeb技術でデスクトップアプリケーションを作れるソフトウェアであるElectronを使って作成されたエディタなのですが、
全部使った中で体感的にVSCodeが一番軽いと思っています。
atomやBracketsは新規タブを開こうとするとかなり重いような印象。しっかり図ってませんが実際軽いと思います。
他にも同じように軽いというブログもありました。やはり一番後発だから、なんですかね?
electron系エディタ戦争終了のおしらせ。codeがイチオシ

3.基本はテキストエディタなのにデバッグ機能が備わっている

これが一番おすすめの理由でもあります。基本はテキストエディタで、ビルドなんかは出来ませんが、デバッグ機能だけはデフォルトで準備されています。
でも、最初から好きな言語がデバッグできるわけではなく、用途に合った拡張機能を入れる必要がありますが、
デバッグ機能が最初から想定されているおかげで、かなり見やすくデバッグが捗る。
拡張機能は色とりどりで、MicrosoftイチオシのC#やtypescriptはもちろん、一般的なc/c++、phpやjavascript(node.js)などのWebサーバ系ソフトウェアで使える言語も可能です。
コーディングに関して、デバッグ機能は必須です。php-debugをよく使ってます。

その他、最近のエディタには当たり前になってきているgit機能、わかりやすくシンプルですがあるとかなり便利な全ファイルの文字列検索など、
大型のIDEや特化したテキストエディタとは違う、これだけは揃えておきたい、という機能がちゃんと入っているエディタと思います。
まだ初版リリース(v0.1)から1年少しでもうバージョンがv1.7にまで増えているのを考えると、かなり活発にアップデートしているという点でも魅力だと思います。

以上、宣伝でした。

サーバー移管した話

potproject.net Advent Calendar 201612日目の記事です。

今日は手抜き。


ようやく、サーバの移管がほぼ完了したのでそれに関する簡単なTipsとメモです。
今回は10分くらいで書ける記事を目指しています。ついでに前の記事の宣伝です。たまには簡単に行きましょう。

20分くらいかかってしまった・・・

WordPress移行

基本的にはWordpressのデフォルト機能として備わっている インポート/エクスポート機能 で移行しました。やはりデフォルトなので一番わかりやすくかつ簡単だと思います。
デフォルト機能なのですが、プラグインが必要だったりします。
古いサーバから管理画面より「ツール」→「エクスポート」からxmlファイルとしてエクスポート、
新しいサーバでインポートで特殊でない大体の記事は問題なく動きます。
スキンやプラグインなどは反映されませんが、そこは数も少ないので手動でした。

Webサーバ構築

この部分は記事別にいろいろまとめています。おさらいです。
自分のサーバではnginx,node.js,sinatra(ruby)と3つほどWebサーバが稼働しています。
centos7+nginx+php-fpm+php7な新しい感じの環境を構築
nginxでRackアプリケーション(sinatra)を動かす

SSL(https)対応

このあたりも(ryです。
おかげさまでSSLオンリーのサイトになりました。
これからは個人サイトといえど必須だと私は思っています。自動更新も忘れずに。
Centos+nginxでLet’s encrypt(certbot)導入と自動更新まで
[nginx]Let’s EncryptでSSLのセキュリティをA+にするまで

Mysqlのダンプ取得

Mysqlのダンプはやはりphpmyadminからエクスポートするのが楽でいいですが、コマンドならmysqldump -u USERNAME -p DBNAME > OUTPUTですね。
取得したらmysql -u USERNAME -p DBNAME < OUTPUTでインポート。たまにデータベースを先に作成する必要があったりすることもあります。その場合は“create database DBNAME“`で作成。

古いサーバはまだ残っていて、放置してるとやはりお金が無駄に取れますので、早いところ解約しなきゃ・・・