ytake blog

Web Application Developer

HHVM/Hackの開発環境を用意してみよう!(HHVM4.0以降対応)

HHVM4.0以降?

f:id:ytakezawa:20190610021605p:plain

ご存知の通り、HHVM4.0以降PHPのコードを実行させることができなくなり、
HHVM/Hackの開発環境周りも大きく変化しています。

今回は最新のHHVM4.8(LTS) が動く環境をDockerで構築する方法を紹介します。

ネット上多くの記事はHHVM3系で、
しかも3.15などの古い記事が多く現在のバージョンとは大きく異なりますので、
注意してください。
現在はCentOSなどへのインストールはサポートされていません。
(CentOSベースで構築している記事は、ほとんどすべてが古いHHVM環境です)
AWSやオンプレ環境で構築する場合は、Ubuntu18.04などで構築してください。

Dockerで環境構築

今回紹介する環境はHHVM4.0以降のみ対応になっています。
せっかくなので新しいバージョンで構築しましょう。

fastcgi or proxygen

HHVMの動作方法として、fastcgiかproxygenを選択できます。
PHP-FPMと変わらないような使い勝手が良い場合は、fastcgiを利用すると良いですが、
HHVMで用意されている多くの機能が利用できません。

proxygenを利用すると、
NginxなどのWeb Serverを利用せずに、
Goなどと同じようにアプリケーションサーバライクにHackを実行することができます。

こちらを利用すると、HHVMのAdminサーバ機能や、
Hackのコードをコンパイルして動かすモードが利用できます。

フロントにNginxを配置してproxygenにupstreamするなども対応できます。

上記の違いを踏まえてHHVMで提供されているDockerコンテナも二種類あります。

hhvm/hhvmはUbuntuベースのコンテナで、
Nginxなどのコンテナを組み合わせて利用する場合はこちらを選択できます。

hhvm/hhvm-proxygen
NginxがなくてもWebアクセスで、Hackのコードが実行できますので、
特にWebサーバが必要なければこちらだけで環境構築が整います。

今回は、hhvm-proxygenを使って環境構築をしてみましょう。

Dockerfileでcomposerインストールを記述しておくと、スムーズです。

FROM hhvm/hhvm-proxygen:4.8-latest

RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive
RUN apt install -y dnsutils iputils-ping net-tools

RUN hhvm --version && php --version
RUN cd $(mktemp -d) \ 
 && curl https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

RUN rm -rf /var/www

HHVMのphp.iniは下記の設定にしておきましょう。
hhvm-proxygenコンテナのデフォルトでは80ポートでアクセすると、
proxygenと通信することができるようになっていますが、
ポートを変えたい場合は、下記にある通り hhvm.server.port で変更します。

xdebug.enable = 1
date.timezone = Asia/Tokyo

hhvm.log.header = true
hhvm.debug.server_error_message = true
display_errors = On
html_errors = On
error_reporting = 22527

hhvm.server.fix_path_info = true
hhvm.server.type = proxygen
hhvm.server.port = 18080
hhvm.log.use_log_file = true
hhvm.server.source_root = /var/www/public

hhvm.php_file.extensions[hack]=1 
hhvm.jit=1

hhvm.server.default_document = "index.hack"
hhvm.server.error_document404 = "index.hack"
hhvm.server.utf8ize_replace = true
hhvm.log.file=stderr

hhvm.admin_server.port=19001
hhvm.admin_server.password=SomePassword

hhvm.admin_server.portはAdmin Server利用時のポートで、
hhvm.admin_server.passwordはAdmin Server利用時に必要なパスワードです。

それぞれ環境に合わせたものを設定します。

次にいくつかのミドルウェアを組み合わせてみる、などを行いたい場合は
docker-composeで利用できるようにしておくと良いでしょう。
下記はdocker-compose.yml例です。

version: '3'
services:
  hhvm:
    build:
      context: ./docker/hhvm
    volumes:
      - .:/var/www
      - ./docker/hhvm/hh.conf:/etc/hh.conf
      - ./docker/hhvm/php.ini:/etc/hhvm/php.ini
      - ./docker/hhvm/server.ini:/etc/hhvm/server.ini
    command: hhvm --mode server -vServer.AllowRunAsRoot=1
    restart: always
    tty: true
    container_name: hhvm
    ports:
      - 18080:18080
      - 19001:19001

docker-compose.ymlが置いてあるディレクトリを /var/www に配置し、
HHVMのphp.iniに hhvm.server.source_root/var/www/public にしていますので、
publicディレクトリにindex.hackファイルがあれば、
アプリケーションスクリプトのファイルとしてproxygenで実行されます。

HHVM4.0からは、Hackのファイルに .hack が利用できるようになり、
これまでの <?hh タグと続けて記述していた // strict と同じ厳格モードがデフォルトとなります。
.hack を利用する場合は、 <?hh タグは記載せずにソーソコードを記述しましょう。

これで開発・動作環境が整ったのでコンテナを起動することで、
Hackの開発環境が整います。

エディタ

Hackを開発する時のエディタは
現在Visual Studio Code + Hack Pluginの組み合わせがデファクトスタンダードです。

code.visualstudio.com

marketplace.visualstudio.com

HHVMにはLanguage Serverあり、この Hack for Visual Studio Codeと連携してサポートしてくれます。
PHPStormの様にuse文(import)を自動で書いてくれたり、などはありませんが、

コードジャンプは当然ながら、
引数のチェックやメソッド・関数のリファレンスなども当然あり、
コード補完やLintなども対応してくれます。

開発のためのLinterやCheck Styleなどのライブラリの使い方や、
実行方法がわからなくても代わりに実行してくれますので、
設定以外のタスクを記述したり、PHPDocを書いたり、
といった準備をすることはあまりありません。

HackではPHPDocを大量に記述せずとも、 静的言語のコンパイラなみの厳格さでコードを記述する必要がありますので、
PHPDocの書き方で補完のされ方が異なる、という事は一切ありません。

ライブラリ

とはいえエディタをフル活用するにはASTなどのライブラリを事前に入れておく必要がありますので、
下記のライブラリをcomposer.jsonに含めておきましょう。

HHVM-AutoloadとHack Standard Library(hsl)は、
ほとんど必須のライブラリと云ってもいいくらいものです。

オプショナルなものとして、下記のものも利用することが多いです。
hsl-experimentalは、将来的にhsl、またはHHVM本体で実装・追加予定のもの、
という立ち位置が強く、ファイルシステム・リソース操作などはhsl-experimentalにあります。

商用などでは利用せずに開発時に利用するものとしては以下のものが一般的です。

  • HackTest / A unit testing framework for Hack
  • FBExpect / A Hack library for writing unit tests expressively
  • HHAST / Mutable AST library for Hack with linting and code migrations

HackTestは、PHPサポートが切れる前にPHPUnitから移行ができる様に準備されていたもので、
FBExpectはアサーションなどが含まれます。
HackTestを使ってFBExpectでアサートをする、という組み合わせになります。
asyncでテストメソッドが実行されますので、
ひと昔前のHackUnitなどの利用は必要ありません。

HHASTはLinterなどの機能を提供しているもので、
Visual Studio Code + Hack Pluginと連携して利用できます(単体でも可)

Hack専用のhh_autoload.jsonなども事前に用意しておく必要があります。
2018年の情報ですが、
前提の知識として下記のものを読んでおくと良いでしょう。

qiita.com

Composer

ここまでのものを踏まえ、
開発初期時の composer.json は次のものを利用すると、
エディタとの組み合わせや、開発時に必要なテストライブラリなど一式が導入できます。

{
  "name": "vendor/your-project-name",
  "type": "library",
  "minimum-stability": "stable",
  "require": {
    "hhvm": "^4.0",
    "hhvm/hsl": "^4.0",
    "hhvm/hsl-experimental": "^4.0",
    "hhvm/hhvm-autoload": "^2.0.0",
    "facebook/hh-clilib": "^2.1.0"
  },
  "require-dev": {
    "hhvm/hacktest": "^1.5",
    "facebook/fbexpect": "^2.5.2",
    "hhvm/hhast": "^4.0.0"
  }
}

hhvm-autoload で利用する hh_autoload.json は次の通りです。

{
  "roots": [
    "src/"
  ],
  "devRoots": [
    "tests/"
  ]
}

次に hhvm/hhast で利用する hhast-lint.json です

{
  "roots": [
    "src/",
    "tests/"
  ],
  "builtinLinters": "all"
}

Hackを動かすために必要な .hhconfig ファイルは、
次の記述を記載しておくのが一般的かもしれません

assume_php = false
enable_experimental_tc_features = no_fallback_in_namespaces
ignored_paths = [ "vendor/.+/tests/.+" ]
safe_array = true
safe_vector_array = true
disallow_assign_by_ref = false
unsafe_rx = false

あとは $ composer install だけで
すぐに開発をはじめることができます。

エディタで補完されないな?という時に

エディタで補完が効かない、
タイプエラーで真っ赤なファイルがある、
という場合には、hh_clientを再起動してください。

再起動は次のコマンドで実行できます。

$ hh_client restart

Travisを使ってテストしたい

TravisCIを使って自動テストなどを実行したい場合は、
Travis上でDockerを利用すると様々なバージョンでテストできます。

ただし、TravisでもPHP実行環境のバージョン提供と同じ様にHHVMも多数のバージョンが用意されています。

コンテナ内でテスト実行などを行う様に下記のシェルスクリプトファイルを用意します。

#!/bin/bash
set -ex
apt update -y
DEBIAN_FRONTEND=noninteractive apt install -y php-cli zip unzip
hhvm --version
php --version

(
  cd $(mktemp -d)
  curl https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
)
composer install
hh_client

hhvm ./vendor/bin/hacktest.hack tests/

上記に合わせて.travis.ymlを次の通りにします。

sudo: required
language: generic
services:
- docker
env:
  matrix:
  - HHVM_VERSION=4.0.0
  - HHVM_VERSION=4.0.1
  - HHVM_VERSION=4.0.2
  - HHVM_VERSION=4.0.3
  - HHVM_VERSION=4.0.4
  - HHVM_VERSION=4.1.0
  - HHVM_VERSION=4.2.0
  - HHVM_VERSION=4.3.0
  - HHVM_VERSION=4.4.0
  - HHVM_VERSION=4.5.0
  - HHVM_VERSION=4.6.0
  - HHVM_VERSION=4.7.0
  - HHVM_VERSION=4.8.0
  - HHVM_VERSION=latest
install:
  - docker pull hhvm/hhvm:$HHVM_VERSION
script:
  - docker run --rm -w /var/source -v $(pwd):/var/source hhvm/hhvm:$HHVM_VERSION ./.travis.sh

例では4.0系以降のバージョンのみですが、
記載したHHVMバージョンのコンテナを起動してをテストなどを実行できますので、
柔軟に様々な要件に応えることができます。

これで最新のHHVM/Hackの開発環境を準備することができました。

これまでの、PHPがちょっと速く動く環境 という知識をアップデートして、
Hackにチャレンジしてみましょう!

事前準備が面倒な方は、下記のものを再利用すると良いでしょう。

github.com

Hack向けDIコンテナライブラリその2 公開

DI Container For HHVM/Hack

だいぶ前に作った軽量なものから、
HackのDIコンテナ向けインターフェース hack-interface-standards/container に準拠し、
HHVM4.0以降に対応しました。

github.com

下記のDIライブラリを意識していますが、作っていくと少しずつ変わっていきました。

github.com

利用方法を紹介します。

installation

インストール方法は、Composer経由で利用できます。
HHVM4.2+composer 1.8.5の組み合わせでもインストールできますので、
まだ安心してComposerを利用できます。

実際に利用する場合は、hhvm/hhvm-autoload 等も必要になりますので、
Composer経由でインストールします。

composer.jsonは下記のもので試しに動かすことができます。

{
  "name": "acme/testing",
  "minimum-stability": "stable",
  "require": {
    "hhvm": "^4.0",
    "hhvm/hhvm-autoload": "^2.0.0",
    "nazg/glue": "^1.1.2"
  }
}

HHVM/Hackのクラスマップ等はcomposer.jsonに記述しなくても、
hhvm-autoloadで吸収できますので、 hh_autoload.json を下記の通りに記述します。

{
  "roots": [
    "src/"
  ]
}

簡単な使い方

シンプルなクラスのインスタンス生成を登録します。
下記のクラスを、src/A.hack ファイルに記述します。
.hackはHHVM4.0から利用できるようになった、デフォルトで厳格モードになる拡張子です

final class A {
}

このクラスをコンテナに登録例として
src/main.hackファイルを作成してそのまま記述します。

require_once __DIR__ . '/../vendor/hh_autoload.php';

<<__EntryPoint>>
function main(): void {
  $t1 = microtime(true);
  $builder = new Nazg\Glue\ContainerBuilder();
  $container = $builder->make();
  $container->bind(A::class)
    ->to(A::class)
    ->in(Nazg\Glue\Scope::PROTOTYPE);
  $container->get(A::class);
}

上記の記述は、コンストラクタにAクラスがあれば(bind)、
Aクラスのインスタンスをそのまま渡す(to)指定で、
インスタンスは、都度インスタンス生成を行います(Nazg\Glue\Scope::PROTOTYPE enum)。
生成されたインスタンスはPSR-7と同様にgetメソッドで取得します。

enum Nazg\Glue\Scope

インスタンス生成は、enumで下記の二種が利用できます。

enum スコープ
Nazg\Glue\PROTOTYPE 都度インスタンス生成を行う
Nazg\Glue\SINGLETON 一度だけインスタンスを生成し、以降はそれを利用します

インターフェースを利用する場合

PHPの一般的なDIコンテナと同じように利用できます。

interface AInterface {
}

class A implements AInterface{
}

上記のインターフェースとクラスは、次の通りに記述してインスタンスを取得できます。

require_once __DIR__ . '/../vendor/hh_autoload.php';

<<__EntryPoint>>
function main(): void {
  $builder = new Nazg\Glue\ContainerBuilder();
  $container = $builder->make();
  $container->bind(AInterface::class)
    ->to(A::class)
    ->in(Nazg\Glue\Scope::PROTOTYPE);

  var_dump($container->get(AInterface::class));
}

bindメソッドでAInterface::class を指定し、 getメソッドでbindメソッド名を指定するだけです。

実装の裏側

getメソッドやbindメソッドなどは存在するクラス名のみを指定できます。

下記はbindメソッドのコードですが、
typename<T>を利用しこれ以外の型は利用できません。
したがってPHPライブラリなどである任意のサービス名などを使うことはできません。

  public function bind<T>(
    typename<T> $id
  ): Bind<T> {
    return new Bind($this, $id, $this->factory);
  }

依存解決

下記の場合はどうすればいいのでしょうか?

interface AInterface {
}

class A implements AInterface{
}

class B {
  public function __construct(
    public AInterface $a
  ) {}
}

複数のクラスを組み合わせる場合、
特殊なものがなければ次の記述で解決できます。

require_once __DIR__ . '/../vendor/hh_autoload.php';

<<__EntryPoint>>
function main(): void {

  $builder = new Nazg\Glue\ContainerBuilder();
  $container = $builder->make();

  $container->bind(B::class)
    ->to(B::class)
    ->in(Nazg\Glue\Scope::PROTOTYPE);
  $container->bind(AInterface::class)
    ->to(A::class)
    ->in(Nazg\Glue\Scope::PROTOTYPE);
  var_dump($container->get(B::class));
}

簡単ですね。

Provider

上記の依存解決方法では解決できないものは、
Providerインターフェースを使って依存解決を記述できます。
先ほどの例をそのまま使います。

interface AInterface {
}

class A implements AInterface{
}

class B {
  public function __construct(
    public AInterface $a
  ) {}
}

Providerインターフェースを使う場合は次の通りです。

class BProvider implements Nazg\Glue\ProviderInterface<B> {

  public function get(
    \Nazg\Glue\Container $container
  ): B {
    return new B(new A());
  }
}

Nazg\Glue\ProviderInterfaceにジェネリクスでB、
getメソッドで返却される型はジェネリクスに記述したクラスと同じ型を指定します。

Providerインターフェースを実装したクラスをコンテナに登録しなければ利用できないため、
下記の記述で登録します。

require_once __DIR__ . '/../vendor/hh_autoload.php';

<<__EntryPoint>>
function main(): void {

  $builder = new Nazg\Glue\ContainerBuilder();
  $container = $builder->make();
  $container->bind(B::class)
    ->provider(new BProvider())
    ->in(Nazg\Glue\Scope::PROTOTYPE);
  var_dump($container->get(B::class));
}

上記の登録方法を利用することで様々なインスタンス生成を行うことができます。

他にもいくつかありますが、
開発時に利用することがあれば是非色々試してみてください。

PHPerKaigi2019でHackの話をしてIRTとPHPの現場公開収録に参加しました #phperkaigi

PHPerKaigi2019!

phperkaigi.jp

2019/03/29-03/31 で開催されたPHPerKaigi2019に参加してきました。

2019/02/16に自分たちが主催したLaravel JP Conference2019から一ヶ月ちょっとという期間。

自分で委員長をやっていたという実感も湧かないままでしたが、
会場にいた方々からLaravel JP Conferenceに参加して、今回も参加しました!
というお声をいただき、少しだけ実感が湧きました。

自分たちでカンファレンスを開催してみるとわかるんですが、
PHPerKaigiはイベントとしてのクオリティも高く、
セッションの前にCM等がきちんとあったり、
自分自身も好きでbuildersconには毎年参加しているんですが、
buildersconに似た雰囲気があり、
技術系カンファレンスとしての完成度が高いなーというイベントです。

3/29

初日は残念ながら不参加・・

3/30

PHPの現場 公開収録にゲスト参加させていただきました。
当日の内容はすでに公開されています(!)

php-genba.shin1x1.com

今回は事前にいただいた質問をテーマに話していく、という内容で
いつも2時間超えになってしまうため、時間がはみ出ないようになんとか・・
収録前に新原さんとガストでご飯を食べながら話をしていたんですが、
その内容も録っておきたかったくらいなんですが、
また機会があればどこかで・・

是非聞いてTwitterなどでフィードバックをください!

その後去年に引き続き、Laravel相談会 の司会担当を。
相談会ということで参加される方の質問に答える流れになりがちなんですが、
質問を元に参加者のみなさんに話していただく、というスタイルでやりました。
PHPerKaigiに参加される方には是非双方向コミュニケーションをとっていただきたいという想いから、
一方向コミュニケーションにならないように。
むずかしいですが!

f:id:ytakezawa:20190331231955j:plain

3/31

3.31はここしばらくPHP以上に書いてるHackについての話を
去年に引き続きさせていただきました。

speakerdeck.com

仙台での発表とは違い、
Hackのことを知らない方でも「へぇー」と思ってもらえるような内容になっていたかなと思います。

f:id:ytakezawa:20190331232539j:plain

発表後にも面白い話でした!といろんな方から話しかけられて満足!

今回の話を聞いて 面白そうじゃん! と思った方は、
もう少し実践寄りな内容を扱ったペチコン仙台の資料もご覧いただければとおもいます。

speakerdeck.com

PHPerトークンについて

今回ゴールドスポンサーとしても協賛させていただきました。
会社のブログではPHPerトークンをどこかに埋めました。
どこにあるかみなさんわかりましたか?

techblog.istyle.co.jp

実は後半、唐突に始まるHackの最新バージョンを動かしてみよう、のところ
このコードを実行するとPHPerトークンが出てくるようになっています。
2進数・16進数、どちらを動かしても同じものが出力されます。
内容さえわかれば他の言語などでもゲットできますね!

また機会があればもっと意地悪なものを用意しようかなと思います!
乞うご期待!!!!!!!!!!!!?!!!!!

Laravel JP Conference2019を開催して

はじめてのカンファレンス主催

conference2019.laravel.jp

2019/02/16 にLaravelに関するカンファレンスを開催しました。

f:id:ytakezawa:20190217012856j:plain

カンファレンスはこのツイートから始まりました。

多くのスポンサー様と多くの来場者の皆さん、
スタッフの皆さんと、急遽お願いさせていただいたカメラマンの皆さん
本当にありがとうございました!

北海道から沖縄まで、沢山の来場者の方々にお越しいただきました。
初開催にして 334名のみなさんが、グランパークカンファレンスに!

f:id:ytakezawa:20190217013017j:plain

参加された方々からは、楽しかった!というフィードバックをたくさんいただけて、
開催してよかったなー、という充実感とともに疲労感・・
楽しかった、という方は今年開催されるPHP系カンファレンスにも
是非ご参加ください!
ほとんどの会場に自分もいますので、会場でお会いしましょう!

f:id:ytakezawa:20190217012944j:plain

そして当日カンファレンスが盛り上がったのは、
スピーカーのみなさんのおかげです。
ありがとうございました!

カメラマンのみなさんも急遽お願いする形になってしまいましたが、
撮影以外の作業を手伝ってくださったり、本当にありがとうございました!

そしてデザインスポンサーを引き受けてくださった、chatboxさま!
時間ないなか素晴らしいデザインをあげてくださいました。
ありがとうございました!!!!

反省点

自分の対応時間が物理的に取れないことが多く、
スタッフのみなさんに対応していただくことが結構ありました。
細々したところで、
ああしておけばよかったなぁ、とかこれやりたかったなぁ、
というのが実はいくつもあります。

コアスタッフの方々それぞれが各コミュニティで活動されている方々で、
イベントごとなどのノウハウが多くあり、
みなさんが自ら対応する場面が多かったので、
本当に助かりました・・頭が上がらないくらいです。
ありがとうございました

当日朝、渋滞に巻き込まれてしまうのをもうちょっと考慮しておけばよかった・・・

こだわり

開催前から2019以降は開催せず、一度きりのカンファレンス
として、計画していました。

なぜ一度きりなのか

特定のフレームワークを扱う上で、流行や時代の流れなどもありますが、
カンファレンスという場に足を運んで、その場でしか得られない刺激や、
みなさんの課題解決のヒントに繋げて欲しいという思いがあります。

次がある、となるとどうしても後手になりがちになってしまうため、
その時にしか得られない価値というのを大事にしたいです。

なぜ動画配信しないの?

その場でしか得られない刺激や、
みなさんの課題解決のヒントに繋げて欲しい

動画から得られるものもたくさんありますが、
やはり動画だけではわからないものがたくさんあります。
例えばロビーで聞こえてくる話題が技術的なものだったり、
マネージメントよりな話だったり、
登壇の動画だけではこうした何気ない会話を拾うことはできません。
こうしたものも是非体験してほしい、ということで
初期段階から動画配信はやらない、と決めていました。

登壇している方々は遠い存在ではありませんので、
今後もカンファレンスに参加した際には、
是非コミュニケーションの場としても活用していただきたいなーと思います!

その他色々

ネームカード

これはPHPerKaigiやbuildersconで導入されているものが、
コミュニケーションを図る上で活用するシーンが多いでしょう!ということで
中にタイムテーブルがあるのはvueFesに参加したスタッフからのアイディアです。
何回も見るのが面倒臭い場合は、アプリインストールのQRコードを使うと、
さらに良い具合になります!

f:id:ytakezawa:20190217012819j:plain

f:id:ytakezawa:20190217012842j:plain

f:id:ytakezawa:20190217012830j:plain

カンファレンスアプリ

当初Flutterで開発を進めていましたが、
日中の仕事といろんなもので時間が厳しくなってきた時に、
コアスタッフのyueguchiさんに作っていただきました!!
Monaca

Tシャツ & 手拭い

Tシャツは他のカンファレンスでも配布されているものですが、
予算の都合で現在のものになりました。
本当は背面などにも・・・。

手拭いは完全に記念品ではありますが、
Laracon自体は数カ国で開催されており、それらに負けずに日本らしいものを、
というアイディアから手拭いになりました。
飾ったり使ったり、何かに使ってみてください。

ランチ

こちらも東京といえば・・・?
ということで今半になりました。
1月に開催されたPHPカンファレンス仙台が牛タン弁当 とアナウンスされており、
自分も仙台で登壇する際にいただきましたが、美味しかったので、
負けないように!ということで。

f:id:ytakezawa:20190217013005j:plain

実は一般チケットはランチよりも安いです!
それもこれも沢山のスポンサー企業様に支えられたおかげです。
ありがとうございました!

本当に最初で最後なのか

自分で主催するLaravelのカンファレンスとしては多分最初で最後になるでしょう。
もしかしたら他の方が実行委員長としてやってくれるかもしれないですし、
やってくれないかもしれません。

Laravelに限らずもう一回ぐらいやろうかなというアイディアはあります。
言語問わずOOPカンファレンスみたいなのやりたいなぁと
海外では巨大なカンファレンスでいくつか開催されているんですよね。
もう少し時間が確保できるようになったら計画してみたいなと思います。

PHPカンファレンス仙台 に参加した

2019年最初のPHPカンファレンス!!!

Hackの話をしました。
Hackの機能の話と、DDDで用いられる実装パターンを
Hackで実践する話

speakerdeck.com

詳細はまた別エントリで。。

前日

今回は東京からではなく、前日に函館にいたので北から降ってきました。

初めてはやぶさに乗りまして。

食べたかった仙台っ子ラーメンを食べ

せり鍋はおしかった。。

当日

オミカレさまの牛タン弁当を食べながらセッションに参加

体制についての話を聞けてよかった。

来月はLaravel JP カンファレンス!

2018年振り返り

総括

今年は仕事の面でも、開発者としての面でも
いろんな出来事があって全体的にものすごく忙しい一年だった(毎年なんですけど)

blog.ytake.jp.net

登壇というアウトプットはしていた一年だったが、
ブログを書く時間を取れなかった。
が、開発に使う言語の比率がいろんな面で大きく割合が変わった。
2017年まで PHP(Hack含む 50%)、Go(30%)、他という感じだったが、 2018年は PHP(ほとんどHack 40%)、Scala(30%)、Go(20%)他と、
やりたかったScalaを選択する時間が増えてきた。
2018年はRDBMSとか所謂LAMP環境の開発がほとんどなくなり、
Apache Hadoop、Apache Spark、Apache Kafka、Apache Solr、Apache Cassandra、
AWSと機械学習、Elasticsearch などなど
とメインで使うものを大規模開発・データ処理系に思考を大きく寄せて、
これまでのいろんな考えを結合させて自分自身の今後あつかう技術を大きく変えた

あとHackのライブラリ作りに集中してた

1月

HHVM/HackのHTTPに関するフレームワークをちょこちょこ作り始めだしたのがこの時期

github.com

腰のヘルニアで入院してからの仕事復帰を果たした。

2月

Developers Summit 2018

Apache Kafkaによるスケーラブルアプリケーション開発 ということで、
2017年のペチコンで話したものをもう少し導入のための知識に寄せて話しました。

デブサミ2018 Apache Kafkaの話 - Speaker Deck

第123回 PHP勉強会@東京

最近のHHVM/Hackという話をした

Laravel JP Conference2019のはじまり

何を思ったのか忘れましたが、ここからLaravel JP Conference2019開催になりました。
開催に向けて色々協力していただいた皆さん、
スタッフに応募してくれてくださった皆さん、
スポンサー企業の皆様、
本当にありがとうございます。

3月

Laravel Meetup Tokyo Vol.10

10回目をやっと開催。。。 PHPerKaigi2018と続いてPHP週間みたいな感じで開催。
すごい盛り上がった回

PHPerKaigi2018

Hackで作るマイクロフレームワーク という話をしました。
Hackの楽しさに気付いて実際に導入したりして2~3年 ずっと話したかったHackのCFPがやっと通って話せた・・・。

Hackで作るマイクロフレームワーク - Speaker Deck

2019年も楽しみです

4月

HHVM/Hack勉強会 Vol.1

PHPerKaigiでも話したし、話し続けていこう!と思って開催
個人的にHackで大好きなShapeの話をしました。
HHVM/Hack ShapeとTypeAssertで堅実なアプリケーション - Speaker Deck

Apache Kafka Meetup Japan特装版@Yahoo! JAPAN

PHPとKafkaの話をした。

Apache Kafka with PHP App - Speaker Deck

Kafka自体の話や事例を聞き自分たちはKafkaの想定の範囲内の用途なんだ、と認識
と同時に設計がミスっていないことを再確認できてよかった・・ 下記の二つの話を聞けたのはよかった

  • "The evolution of Apache Kafka" Mr. Jun Rao
  • ”For Multitenancy; Kafka clusters for everyone at LINE”Yuto KAWAMURA

5月

インタビュー記事が公開されました。
インタビューは当然ジャージ www.rstone-jp.com

6月

PHPカンファレンス福岡2018

Event Sourcing, CQRS For PHP という話をしました。 Event Sourcing,CQRS For PHP Application - Speaker Deck

2017年から取り組んでいるデータ処理系の観点を交えながら、
DDDからの視点ではなくて、データ処理系に近い内容
Ask The Speakerにたくさん来ていただいて楽しかった・・!

7月

発表系の活動などは特にしなかった。が、
アイスタイルのCTOになったのがこの月。
技術面はこれまでも横断的に関わることが多かったんですが、
その技術を推進するための成長をどうやってするべきか、
みたいなマネージメント的な方面からも入り出した時期。
頑張ろう

今年はPHPカンファレンス関西に行けなかった。

8月

この辺りから土日はHackだったりAWS周りの開発をめっちゃする時期に突入し、
イベント登壇後のブログとかを書かなくなり、とにかく開発ばっかり

HHVM/Hack勉強会 Vol.2 初心者特集(予)

資料どっかにいってしまった・・・ Hackの始めた方、という話をした。

9月

builderscon2018

Hackの話をした
HHVM/Hackで得る問題解決力 / hhvm-hack-problem-solving - Speaker Deck

アーキテクチャ ディスカッション Vol.1

発表資料等はなく、アーキテクチャに関して質問したりテーマに沿っていろんな方と話す、
というのをどうしてもやりたくて開催

当日の様子は以下を参考にしてください。
shinkufencer.hateblo.jp

qiita.com

alexander.achanblog.mydns.jp

これに関していろんな方面の方々に来ていただいて、
参加した方々には是非また参加したいとフィードバックがあったり、
いろんな話ができたので来年も数回やりたいと思ってます。

PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応 本発売

Laravelに関する書籍で自分が執筆した書籍はこれで3冊目
今までのPHP系の書籍になかった内容にしよう、というのと
現場で使えそうなユースケースを交えて、という著者みなさんの思いが詰まった一冊。
執筆期間であろう月日の流れを見ると、
なかなかのハードスケジュールだった・・。

第130回 PHP勉強会@東京

Laravel JP Conferenceの宣伝のみ

10月

明日の開発カンファレンス 2018秋

大きなデータと戦う技術 という話をした 大きなデータと戦う技術 / fighting-large-data - Speaker Deck

アプリケーションの規模に応じて考え方や取り組みを変えていきましょう!という話
パネルディスカッションに参加せていただいて、
組織的な話だったり採用の話だったり、CTOっぽい話をした気がする・・。

11月

AWS Dev Day Tokyo 2018

マイクロサービス周辺技術のトラックで
Event Sourcing+CQRS を活用するスケーラブルアプリケーション開発 という話をした。

PHPカンファレンス福岡で話したテーマを元に、
AWSのサービスを交えたり、PHP要素をなくし、
マイクロサービスアーキテクチャを実践する上で、gRPCなど目に見えるものの裏側のデータの扱いの話がメイン
なんだかんだAWSのイベントに登壇する、というだけでめちゃくちゃ緊張した。
登壇の方々は本当に第一人者といってもいいような方々ばかりで、今までで一番緊張したイベント。
他の方々とgRPC関連の話をしていたところ、ふと思ったのは自分はほとんどAvroとThriftしか使ってないなと思った頃
このあとからgRPC使った画像処理系のAPIとかをAkka HTTPで作りはじめる

12月

PHPカンファレンス2018

PHPとApache Sparkで始めるデータ解析処理 という話をした。
データ処理系の話と機械学習とのつなぎこみとか、実践に近い話の触りだけ。
本当はHackの話をしたかった

Hack and HHVM Advent Calendar 2018

qiita.com

可能な限り書いた。
PHPから大きく分離し始めている今を伝えるのと、
Hackの言語としての魅力を伝えようとしたもの。
たいへんだった

来年

来年は1月から北海道に行ったり仙台に行ったり、
いろんなところに行くので、色んな体験だったりができそうで今から非常に楽しみ。 あとはLaravel JP Conference2019!

conference2019.laravel.jp

LaravelやPHPユーザーは是非お越しください!
いろんなところでも言っていますが、
2回目はやりません。今回のみです。

それとは別に来年はOSS周りのものをリリースする!

  • Apache Kafka PHP製Topic管理、KSQLツール
  • Hackフレームワーク バージョンアップ
  • Hack専用ライブラリ Logger、Elasticsearch周り
  • Hackエクステンション

来年も頑張りましょう

PHPカンファレンス2018でApache Sparkの話をしました #phocon

2018年のペチコンも楽しかった!

f:id:ytakezawa:20181230010118j:plain

もう二週間前の話ですが、
PHPとApache Sparkで始めるデータ解析処理 という話をしました。

speakerdeck.com

現在公開されている動画はこちら
youtu.be *分割されたものが公開されるらしい

アプリケーションを成長させるためには、  
アプリケーションの開発だけではなく、ログデータや、  
様々なメタデータを的確に利用できるようにすることが重要です。  
このセッションではこれらを叶えるためにApache Sparkによるデータ解析処理と、  
ビッグデータ対応のデータベース、  
PHPアプリケーションを組み合わせてアプリケーションをグロースさせるヒントの実装の考え方をお話しします。

トーク補足

Apache Sparkそのものについては、
たくさんの書籍や、ネット上の記事も多くありますのでその詳細は話しませんでした。
(日本国内の記事よりも海外の記事の方がおすすめです)

Apache Sparkを活用するには、まず活用のポイントを知っておかなければなりません。
小さなアプリケーションだったり、
アプリケーションからアドホックに叩きまくりたい、というケースで導入すると
ミスマッチにもなりますし、
自分たち自身で分散システムの保守・運用ができる体制や知識がないと
デメリットとなりますので、その辺りに軽く触れました。
といいつつもWebアプリケーション系に相性もいいSpark SQLを中心に、
Event SourcingとCQRSのランタイムと同時にシステムを支える考え方を交えて紹介しました。

f:id:ytakezawa:20181230012926p:plain

こうした考え方とミドルウェアの組み合わせは、
大きなアプリケーションだったり、リアルタイム性が重要なアプリケーションや、
マイクロサービスアーキテクチャ化に取り入れることもできます。
データ処理アーキテクチャのLambdaアーキテクチャやKappaアーキテクチャでは、
この処理フローを元に様々な処理を連携させていきます。
現代のアーキテクチャで導入を検討するケースも多いパターンかもしれません。
が、やはり事前にその知識が必要であったりするため、セッション自体は少し難しかったかもしれません。

後半はALS (Alternative Least Squares・交互最小二乗法)を用いたレコメンデーションの作り方について、
IBMで公開されているものを元に処理の流れと実装内容を解説しました。

github.com

実際の開発に導入する場合もこれを元に拡張していくといいかもしれません。
自分はSpark MLlibとElasticsearchとHadoopの組み合わせで、
PythonではなくScalaで実装して利用しています。
これは使えそうだ!と思ったら是非アプリケーションに導入してみてください。

アプリケーション開発をしていると、多くは実装だったり、実装のための設計だったり、
そのためのチームでのMTGだったりと、通常その辺りに時間を多く使われると思います。
が、実装や設計といったものと切り離せないデータベースや、
データ処理そのものの情報を吸収するのは難しく
枯れているからこそこれまでの情報と知識を使いがちになります。

が、サービスの規模が大きくなったり、想定外の成長を遂げるアプリケーションを支えるには
技術面における柔軟性と、状態変化に強くするための知識アップデートが必要になることも多いです。

そんな現代において、コンテンツのレコメンデーションなどに代表される機械学習や、
それを作るための大規模なデータとWebアプリケーションを結びつけるものの具体的なイメージがあれば、
アプリケーション開発へのヒントだったり、ログデータの重要性が見えてきたり、
開発者から行えるサービスへのアプローチの面白さ、みたいなのを知るきっかけになれば、
と思います。

スポンサーとしても参加

毎年登壇はしていたんですが、
今回はせっかくなのでスポンサーとしても参加しました。
会社のみなさんにも協力いただいて(自分はほとんど丸投げだった・・・)
たくさんの方がスポンサーブースに来ていただきました。
感謝

f:id:ytakezawa:20181230010136j:plain
アイスタイルブース

Laravelクイズ的なものを実はQRコードで配布していましたが、
結構ちゃんと考えないといけない内容だった為、あまり遊ばれませんでした
Laravel JP Conference2019でもやろうかな
そんな逮捕用のパネルで遊んでくれた方々。

f:id:ytakezawa:20181230010044j:plainf:id:ytakezawa:20181230010104j:plain

サイン会の様子

ありがたいことに今回は、
今年発売された PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応 のサイン会がありました。
サイン会で完売!!!
多くの方に参加していただきありがとうございました!

PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応

PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応

最後にLaravel JP Conderence2019

ペチコンでも最後に宣伝させていただきましたが、
来年開催される Laravel JP Conference2019の参加申し込みが始まっております!

conference2019.laravel.jp

タイムテーブル自体ももうすぐ公開されますが、
豪華な国内ゲストを迎えてLaravelを軸としたセッションをお届けします。
ゲストの紹介、タイムテーブルの公開は、公式Twitterアカウントをフォローしてチェックしてみてください。

twitter.com

来年は1月の仙台、Hackの話をさせていただきます!
楽しみ!!!!!