MarkdownからWordやPDF生成ができるようにする (またはPandoc環境の構築方法) (2017/12版)

かつて、Pandoc環境の構築方法についてエントリを書いたこともありました。

qiita.com

2017年も終わる今では brew install pandoc で簡単にPandoc環境のインストールもできます。

しかし!我々が欲しいのは「Pandoc環境」ではなくて「Markdownから日本語なPDFを生成できる環境」なのですよ!

2017年最新のPandoc環境構築手順はコレだ!

$ docker pull k1low/alpine-pandoc-ja

これで終わり!

これでMarkdownから日本語なPDFを生成できます!

https://hub.docker.com/r/k1low/alpine-pandoc-ja/hub.docker.com

ちなみにDocker Hubデビュー作です。

使い方

使い方は、例えば以下のとおり

$ docker run -it --rm -v `pwd`:/workspace k1low/alpine-pandoc-ja pandoc input.md -f markdown -o output.pdf -V documentclass=ltjarticle -V classoption=a4j -V geometry:margin=1in --pdf-engine=lualatex

これで手元の環境を汚さずにMarkdownからPDFの出力が可能です。

http://smellman.hatenablog.com/entry/2017/05/23/044642 のエントリにあるようにテンプレートを変更して、良さ気なフォーマットでのPDFの生成もできますよ!

$ mkdir templates
$ wget https://raw.githubusercontent.com/Wandmalfarbe/pandoc-latex-template/master/eisvogel.tex -O templates/eisvogel.tex
$ docker run -it --rm -v `pwd`:/workspace -v `pwd`/templates:/root/.pandoc/templates k1low/pandoc:latest pandoc input.md -f markdown -o output.pdf -V documentclass=ltjarticle -V classoption=a4j -V geometry:margin=1in -V CJKmainfont=IPAexGothic --pdf-engine=lualatex --template eisvogel.tex --listings

Markdownバンザイ!

hubedit.comにMarkdown Editorを設置してみた

会社の開発合宿で自身専用メモサービスhubedit.comにMarkdown Editorを設置してみました。

hubedit.com

今回の目的は2つです。

  1. Markdown Editorを設置して自身のhubeditライフを便利にする
  2. Serverless Frameworkでデプロイし、ドメインACMも設定して運用しているようなサービスで
    • 次期本番環境を構築して sls deploy できるようにする
    • 本番環境を次期検証環境に切り替えてみる

Markdown Editorの選定

Markdownの表記はそのまま表示されてstyleだけ変化があるものを探しました。

Markdownの表記が消えてしまうタイプのWISYWIGなEditorは多かったが表記がそのまま残るようなEditorは少なかったです。

探したものとしては

などですが、とりあえず導入して使い勝手を見たかったので、 最も導入しやすかった+スマホでも使えた SimpleMDE を設置してみました。

Serverless Frameworkで検証環境を作る

hubeditはServerless Frameworkでデプロイできるように構築されており、AWS上では1つのCloudFormationのスタックとして管理されています。

f:id:k1LoW:20170712231630p:plain

また、GitHubのアクセストークンを一時的に保存する場所としてS3を利用しています。

ドメイン割り当て(Route53)とSSL証明書ACM+CloudFront)はServerless Framework管理外で設定しています。

スタック切り分けによる検証環境を作るのは簡単

本番で稼働しているスタックと別のスタックで動かすために、stage の切り替えで対応しました。

具体的には sls deploy -s v2 などで検証用スタックが実現できます。

serverless.yml の servicehubedit だったとしたら v2-hubedit という新しいスタックが作成されます。

この状態で新機能を追加していって、実装を進めました。

そして最終的にAPI Gatewayのカスタムドメインの向き先を変更することで、検証環境を本番環境に昇格させました。

永続データをどうするか

今回の切り替えの方法では、検証環境はCFnのスタック単位で、API GatewayAWS LambdaやS3は全く別に新しく構築することになりました。

hubeditは永続データはGitHubリポジトリのみなので問題なく切り替えは可能でしたが、永続データがあったときはどうすればいいのでしょうか?

  1. 永続データの保存先はServerless Frameworkでは管理しない(hubeditがたまたまコレ)
    • 2つのCFnに分けて永続データは永続データ用CFnで保持する
  2. API GatewayのStageで切り替えることができればあるいは。。。
    • 1つのCFnスタックに2種類以上のAPIコレクションを持つことは可能?

ここらへんはまだ個人的ベストな方法は見つかっていません。 Serverless Frameworkで永続データの管理運用をどうするのが良いか、何か良いアイデアあるかた教えて下さい。

hubedit.comの今後

とりあえず、今のところ普通に使えているのであとはAPIリクエストに伴う読み込みの遅さをいい感じで解消していきたいです。

Serverless Ninja Tips "Instant Job Queue" をしっかり紹介してみる

このエントリは、Serverless Advent Calendar 2017Fusic Advent Calendar 2017の5日目となります。

PHPカンファレンスや、Serverlessconf Tokyo 2017でも紹介したServerless Ninja Tips(名前だけかっこいい)ですが、その中で、説明するたびに伝わっていない感がある "Instant Job Queue" について紹介したいと思います。

想定するユースケース「クローラ」

サーバーレスアーキテクチャでWebページのクローラを実装するとします。

まずは、以下のような1つのLambdaファンクション(今回はWorkerと呼びます)を考えるでしょう。

  1. URLを入力として受け取って、URLにアクセスしてHTMLパース、次のURLをリストアップする
  2. リストアップしたURLを次のLambdaファンクションの入力としてinvokeする

これでだいたいクローラとしては動きそうですが、実際に動かすとどうなるでしょうか?

f:id:k1LoW:20171205093634p:plain

無限ループになってしまいます。 さらに、同時実行されるLambdaファンクションはURLをリストアップする度にどんどん多くなり、対象サーバにDoSを仕掛けてしまうことになってしまいます。 これではマズいですね。

  1. 無限ループになる
  2. 同時実行数がどんどん大きくなる

この2つを解決したいと思います。

無限ループを回避する

無限ループを回避するのは簡単です。

URLと同時に深さ( depth ) をLambdaファンクションに与えて、深さが規定に達したら次のURLのリストアップとinvokeをやめて終了すればOKです。

同時実行数を制御する "Instant Job Queue"

次は同時実行数です。

"Instant Job Queue" は、再帰構造になっているLambdaファンクションにおいて、同時実行数を簡易的に制御するためのTipsです。

f:id:k1LoW:20171205093337p:plain

フロー

仕組みとしては以下のようになります。

まず、WorkerだけでなくStarterと呼ぶLambdaファンクションを用意します。そして仕組みの真ん中にSQS(キュー)を配置します。

  1. まずStarterがURLを深さの対をエンキューする
  2. StarterはWorkerをinvoke
  3. Workerはデキューしようとする
  4. Workerはキューがなければ自身を終了する。URLと深さを受け取って、深さが規定に達していても終了する
  5. 深さ++
  6. WorkerはURLにアクセスしてHTMLパース、次のURLをリストアップする
  7. WorkerはリストアップしたURLとインクリメントした深さをそれぞれ対にしてエンキューする
  8. WorkerはWorkerをinvokeして自身を終了する

特徴

AWSのマネージドサービスのみで実現しているので「キュー待ちするWorkerのプロセス管理」などが必要ありません。

また、(本来なら採用したほうが良いであろう)Step Functions よりも安い料金で実現可能です。

具体的な実装

"Instant Job Queue" を実際に組み込んでいる実装として utsusemi があります。

github.com

(utsusemiについてもいつか紹介エントリを書こうと思います)

というわけで

"Instant Job Queue" についての紹介でした。

福岡Ruby会議02でawspecの成長と感謝について話してきました。そしてv1.0.0リリース #fukuokarb #fukuokark02

福岡Ruby会議02

「もう一度、Rubyと出会う」をテーマに福岡Ruby会議02が開催されました。

regional.rubykaigi.org

私はスタッフとスピーカーとして参加しました。

udzura さんの思いが見事に反映されたカンファレンスでした

開催を決めるとき、テーマは実行委員長である udzura さんが決めていました。これについては udzura さんのエントリを見てもらうとよいでしょう。

udzura.hatenablog.jp

「ただ地域Ruby会議を開催する」のではなく、強い思いがあって開催するという気持ちが感じられました。

その結果、(スタッフだったのでいくつかしか聞けていませんが)島田さんのエピソードや

松田さんのKeynoteなど、すごくRubyを書きたくなる発表を聞くことができました。

awspecの発表を福岡のRuby会議でしたかった

自分はスタッフとしての参加が決まっていたのですが、どうしても発表をしたくて発表応募をしました。

理由は「もう一度、Rubyと出会う」というテーマだったからです。

awspecはネットを通じたOSSに関わる人だけでなく、Fukuoka.rbというリアルのコミュニティで成長したからです。

そのFukuoka.rbが主催に関わっている福岡Ruby会議02で、そのFukuoka.rbを通じて成長したOSSの話をしたかったのです。

無事発表することができて、一段落した気がします。感謝を発表できて良かったです。

awspec v1.0.0 リリース

github.com

そして発表の最後に awspec v1.0.0 をリリースしました。

やっと v1 です。その間にaws-sdk-rubyはv3になりました。awspec v1.0.0からはaws-sdkもv3を利用します。

発表スライドに書いたようにawspecはメジャーバージョンが1になったことによりセマンティックバージョニングのルールに則って、安定したメンテナンスを目指していこうと思います。

特に今までと大きく変わるわけではないですが個人的な意識として、です。

最高の福岡Ruby会議02になりました。運営の皆様、発表者の皆様、スポンサーの皆様、参加者の皆様ありがとうございました!!

最後に

懇親会で角谷さんに言ってもらった内容が印象的で、本当にそのとおりだと思ったのでメモ。

君の、Rubyコミッタや技術的にレベルの高い会話を『怖い』といってしまう気持ちはわかる。

が、『怖い』というのは『自分がわからない、ついていけない』という事実を相手に転嫁しているだけだ。

そんな言い方で言ってはいけない

『彼らはすごい。俺はすごくない』それでいいじゃないか。

(自分が「Rubyコミッタちょっと怖い、近寄りがたい」という話をしたときの返答)

改訂新版 Emacs実践入門を読んでEmacsのカンを取り戻す

[改訂新版]Emacs実践入門―思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus)

[改訂新版]Emacs実践入門―思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus)

まさに!この俺的最高のタイミングで!改訂新版が出ました!

Emacs実践入門読んでいます

既に発売から1ヶ月以上がたっていますし、東京では出版記念イベントも開催されている中、自分は何をやっていたかというと

.emacsをいじっていました。Emacs実践入門を片手に。

改めて自分の.emacs(正しくは.emacs.d/)を見ると、動いているかわからない設定や使っているかわからない設定が多くありました。(一見して意味のわからない設定もあり、Emacs Listp力が下がっていることを実感。。。)

というわけで、1つ1つ最初から設定を作ることにしました(仕事に影響のないように、仕事のEmacsの設定はいじっていません)。

個人的には、やはり第5章以降の拡張の章からがポイントです。

これは個人的感覚なのですが、なんかインターネット上でEmacsの設定の話題が少なくなったように感じています。多分自分の興味がEmacs以外にそれていたからだとは思っているのですが、どうなんでしょう?

そういう自分のEmacs情報へのリーチ力が弱まった今、日本語で、書籍で、十分に意味の説明がついた、拡張に関する紹介を得ることができるのは最高です。

Emacs実践入門と自分の.emacsを見比べながら、「あー、そうだった!そうだった!」という気持ちでEmacs力の高まりを感じています。

ちなみに今は、syohexさんの.emacsも見ながら「良さそうーこれこれ」という感じです。

github.com

休日に趣味のようにやっているので、まだまだかかりそうです。

これからEmacsを触ろうとする人にとって勧められる書籍はこれしかない

正直、これからEmacsを始める人にとって、インターネットも含めて最良の情報はもうこの書籍しか選択肢はないのでは?と思ってしまいます。

選択肢が1つしかないのは少し残念ですが、逆に考える必要なく「これ」と言えるので良いかもです。

その先はEmacs JPのサイトとSlackチャンネルへ是非。「改訂新版 Emacs実践入門→Emacs JP」で完璧です。

http://emacs-jp.github.io/emacs-jp.github.io

Emacsで良いのか

なぜ自分が今もEmacsを使っているのかというと、「(本当に)自分の好きにカスタマイズできるから」「集中力の続かない自分にとって、カジュアルに他言語のリポジトリに移ってそのモードで書き始めたり、エディタ内でシェルを起動したりが楽」ということなんですが、そういえばいつからかEmacs Lispをあまり書かなくなりました。

なんというか、このまま興味が終わったらダメだとは感じます。止まったらダメ*1

改訂新版 Emacs実践入門をきっかけにまた自分のEmacsの向上をやっていこう、と思いました。

結局Emacs好きなんで。

最後に

今回、改訂新版 Emacs実践入門の著者である d:id:tomoya さんご恵投いただきありがとうございました。

この書籍で、日本の書籍界のEmacs情報がアップデートされたことは本当に喜ばしいことすごいことだと思います。

そういえば、初版のときもtomoyaさんに書籍をいただき、エントリを書きました。

このときの"Emacs初心者"が今の私の奥さんです。

*1:ちょいちょい引用させてもらったtadsanさんについて。エディタについての考え方について tadsanさんの考えに共感したり自分の考えを改めたりしているのが最近なのですが、自分が(tadsanさんが否定的な)鬼軍曹.elの作者だったりするので少し申し訳ないなーと思ったりもします。 同じEmacsでPHPerで、PHPの話も勉強になるのですが、php-modeもメンテナになったりと、広範囲のEmacs-PHP活動応援しています。

Serverlessconf Tokyo 2017で"Open source application and Ecosystem on Serverless Framework"というタイトルで発表してきました #serverlessconf

Serverlessconf Tokyo 2017に2日に渡って参加してきました!ワークショップも参加しました!発表もしてきました!以下レポートです!

Day1: Workshop

朝9時から夜9時までというハードコアなワークショップでした。

Serverless Tech Challenge with AWS Serverless Services

「本日のお題は

  • AWS以外のIaaS、PaaS利用禁止
  • 認証機構があること
  • 画像アップロード機能があること
  • CI/CDを回すこと
  • モニタリング機構があること

という条件のもと

  • 掲示板
  • SNS
  • マッチングアプリ
  • チャット

のどれかを作ってみよう。では、Go!」

という硬派な投げっぱなしジャーマンのようなチャレンジでした。

自分は、 comuttun さんと2人の急造チームでの参戦に。

まずは、お互いの自己紹介とAWSスキルを共有しあって、今回はサーバーレスについて自分が少し知識があったのでServerless Frameworkを使うことにしてもらいました。

Cognito User Poolを使いこなせない2人

なんと、Cognito User Poolの利用方法を2人でそれぞれ調べるというところからスタート(外部サービスが使えればOAuthとかでいろいろ省略できたのですがそれはNGだったので。。)。最悪なスタートです。

この時点で何を作るのかは未定。「とりあえず認証機構を実装できてから。話はそれから」という状況で、SAさんに質問しながら実装を進めました。

マッチングアプリとは何か

認証機構ができたところらへんで、いったんcomuttunさんが諸事情で離脱。

その間に容易に設計できそうなものとして、まずチャットを選択して設計しました。

  • チャットのメッセージ更新自体はロングポーリングで妥協。
  • コメントはJSONファイル、画像アップロードはそのまま画像ファイルで、時系列に並ぶようにS3にオブジェクトとして保存
    • /rooms/{roomName}/messages/{reversedUnixtime}.{json|jpg} (Reversed Timestamp ID)
    • 細かい情報はS3 Object Taggingに格納 (S3 Object Tagging)
  • あとはAPI Gatewayで各ルームのチャットメッセージのCRUDを作ればOK

というような、まさに今回発表予定だったTipsをフル活用した感じで設計。まあ、できそう。

掲示板やSNSはなんとなくRDBの無い世界では面倒そうということで、次設計してみるのはマッチングアプリかな?と思っていたところで、comuttunさんが合流。

チャットの設計を説明した上で、「そもそもマッチングアプリってなんだ?」という話に突入。

そう、2人ともマッチングアプリ自体を知らないという。。。

  • 「マッチングアプリってPairsとか?」
  • 「人と人をマッチングすればマッチングアプリ?」
  • 「いい感じで相手をリコメンドすればいいってことか」
  • 「要件として画像アップロード機能が必要だからセルフィーをアップロードしてもらって、Amazon Rekognitionで画像を解析して得たパラメータ使えば良いのでは?」
  • 「Male/FemaleパラメータとはHappyパラメータとかあるから良さそう」

という感じで「想像で」マッチングアプリを設計しました。

で、この時点で明らかにチャットアプリのほうが設計の精度は高くて「チャットかな」と思っていたら

comuttun 「Amazon Rekognition使ったことないし、せっかくだからマッチングアプリにしよう。面白そう」

という無謀な発言が飛び出て、ずっとコード書いてるハイテンションからか、そのまま採用されて

  • comuttun: Amazon Rekognition
  • k1LoW: API Gateway経由での画像アップロード

という分担で開発再開。

結果、見事に時間が足りず撃沈しました。

俺達はスケジュール管理ができない!あと2時間あれば機能は実装できた。。。!!

Introducing a new event-driven world with Serverless Framework

間髪入れずに次のワークショップに参加。

OSSなFaaSの体験と、Event Gatewayの体験というワークショップでした。

GCPの利用も初なのに、GKE -> k8s -> kubelessと盛りだくさんなOSS FaaS体験と、BigQuery + Event Gatewayというこれまた初体験づくしなEvent Gateway体験でした。

途中、最新VerのServerless Frameworkの不具合が発見されたりしましたが、後日 comuttun さんがなおしてPRを出していたという最高イベントも発生しました。

Day2: Conference

カンファレンスも最初から参加しました。

"サーバーレス"を語るときに僕が語ること

"サーバーレス"は未だに定義が曖昧で、たぶんこのまま曖昧のまま進んでいきそうな雰囲気ですが、「サーバ管理レスだけ考えているとPaaSに毛の生えたもので世界が終わっちゃうぜ」という話で、特に「例えばEvent Driven Architectureという文脈で考えてみようぜ」という話でした。

自分もいくつかサーバーレスなツールやアプリケーションを作りましたが、「良く」作るためにはそれなりに考える必要があります。そしてそれはいつものLAMPアプリケーションとは違うという。。

ここらへんがうまく言語化できたり体系化できたりすると、サーバーレスの世界から離れたときも活用できるアーキテクチャを得ることができそうな気がします。

個人的には、「削られた最後の1ページ」も公開して欲しかったですw

サーバレスアーキテクチャによる時系列データベースの構築と監視

個人的に楽しみにしていた発表です。

MackerelというSaaSのバックエンドの根幹になる時系列データベースを独自に再構築した、しかもAWSマネージドサービスをフル活用している、というのは個人的に非常にワクワクする話で、今までdiamondについて言及したブログエントリーや発表もずっとウォッチしていました。

それはあたかも(AWSがRDMSを新たに再構築してRDBMSの各構成要素を水平分割するという新たなアーキテクチャを編み出した)Amazon Auroraのようで、Redis -> DynamoDB -> S3という局所参照性に合わせてうまくデータが移動して保存される様は「めっちゃ考えて編み出したアーキテクチャだ」というのが分かって最高です。

そんなプロダクションで稼働しているdiamondの監視とチューニングについての今回の発表は、まさに「プロダクション」であり、勉強になりました。

Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤

www.slideshare.net

機械学習の話というよりもStep FunctionsとAWS Batchの実践的な知見の発表でした。むしろとても良かったです。

コンポーネントごとに説明があって、それぞれで活用できそうな雰囲気でした。

個人的にはこのあとスポンサーブースで聞いた「いかに管理コストを下げるか」についての熱い思いの話が面白かったです。

The mind of Serverless as a Software

slideship.com

既存のアーキテクチャの流れとServerlessはつながっているという話から、1つ1つステップを踏んで、実際に設計をしていく際の指標を「少し強めに」指し示してくれる発表でした。

FaaSとFunctional SaaSをしっかり定義した上で、それぞれのつまづきポイントを「分けて順番に」説明してくれたので、混乱せず、と同時にワードの理解もはっきりできました。

少しサーバーレスをかじった人に紹介したい資料です。

Open source application and Ecosystem on Serverless Framework

github.com

自分の発表です。

予想外に多くの方に聞いてもらえてよかったです。(書けない英語で一生懸命書いたのですが、残念、海外の方は会場に1名でした)

伝えたかったことは発表した順番とは前後しますが、

  • Serverless Frameworkはインフラからロジックまで1コマンドで展開できる強力なツール
  • 例えば、1コマンドでサーバーレスでフルマネージドなアプリケーションを展開できると、ユーザにとってはそのアプリケーションを構成する要素は気にならなくなる(=隠蔽される)
  • ユーザにとっては、あたかもその機能を提供してくれる「ミドルウェア」や「サービス」に見える(抽象化される)
  • また、例えば、1コマンドをさらにHeroku Deploy Buttonみたいにさらに簡略化すれば、OSSなサーバーレスなツールやアプリケーションの展開が広がるのでは?(そして実装してみた)
  • OSSな「サーバーレスミドルウェア」や「サーバーレスサービス」が多くでてきて開発を助ける世界が来て欲しい

という感じです。

ところで、質疑応答で「サーバーレスミドルウェアとマイクロサービスは同じでは?」という質問をもらいました。

そのとき、質問していただいた方にうまく説明できず申し訳なかったのです。

ちなみに個人的には「同じではない」というイメージです。

nekoruriさんがとてもわかりやすい説明をしてくれたのですが、「マイクロサービスは責務による分離、サーバーレスミドルウェアは機能による分離」というものです。

構成要素がマネージドサービスのみだったり(マイクロサービスではその限りではありませんが)、抽象化されて扱われるという点では同じかもしれません。

マイクロサービスは作りたいサービスの文脈に沿って分割・抽象化されているのに対して、サーバーレスミドルウェアは「ある機能を抽象化しようと構築されたもの」を指したつもりでした。

例えば、マイクロサービスの1要素は(おそらく)そのサービスの文脈に特化して実装されていますが、サーバーレスミドルウェアとして構築された「時系列データベース」は、時系列のデータを取り扱う機能を実現するために構成されているので、他の時系列を取り扱いたいサービスでも抽象化されたまま活用できる可能性があります。

もともと「サーバーレスミドルウェア」というか「抽象化されたミドルウェア」という考えは、はてなさんのdiamondに対しての発表とアーキテクチャを見て感じたことです。 1つのソースコード/サーバ上で構築されたわけではなく、マネージドサービスを横断して活用していて、それでいて「時系列データベースを作った」と表現しているのをみて「あ」と思いました。

faultlineの実装を通じて「SaaSっぽいもの(サーバーレスサービス)は作れる」という実感はありましたが( Serverless Meetup Fukuoka #1で発表 )、今回はそれをさらに推し進めて「サーバーレスミドルウェア」という世界もあるのでは?と思った次第です。

なんか、そんな、感じです。

その他

サーバーレスおじさんユニフォームをもらったり、サーバーレスの厚い本をGetしたり、スポンサーブースで時間の許す限り興味のままにいろいろ質問しまくったり最高でした。

ちなみに今回のハイライトはカンファレンス後の呑みで、1年ごしにhorike37さんにサーバーレスな相談をしたら、サーバーレス過激派の人や北海道のサーバーレスおじさんやEmacs実践入門の人にパラレルにつっこまれ、見事に爆散したことです。

Serverlessconf Tokyo 2017、カンファレンス運営の皆様、発表者の皆様、スポンサーの皆様、参加者の皆様ありがとうございました!

PHPカンファレンス2017でServerless Frameworkの話とoctopackageの紹介をしてきました #phpcon2017

今年もPHPカンファレンス2017で登壇させてもらいました。また、懇親会LTでもoctopackageの紹介(?)をしてきました。

サーバーレスアーキテクチャPHPアーキテクチャとの違いの話

この「Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見」という発表タイトルは、実はNulabさんが主催するGeeks Who Drinkで発表させていただいたものと同じです。

思えば、YAPC::Fukuoka 2017 Hakataに応募してリジェクトされて「まあそうだよね」とツイートしていたのをagataさんが拾ってくれて(!!!)実現したのが、Geeks Who Drinkでの発表でした。

nulab.connpass.com

そして、発表後にagataさんに「他でも発表したほうがいい」と言ってもらったので、PHPカンファレンス2017のCFP3つのうちの1つとして応募しました。

そしてまさかのこの内容が採択。

ただ、今回はPHPカンファレンスでの発表ということで、各ツールのデモをなくして「サーバーレスアーキテクチャに興味もってもらうこと」「LAMPアーキテクチャとの違いを感じてもらうこと」に力を入れてみました(後半は若干喋りたいことになっていますが)。


Japan PHP Conference Track3 (2) - Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見

詰め込みすぎた結果、思ったとおり質疑応答の時間はなかったです。

当日の反応としては「少しだけ」といったところでしたが、その後資料公開に反応してくれた方が多くいて安心しました。

懇親会LTと感謝

懇親会LTは、当日先着順なのですが、kaz_29さんに「どう?」と言われて、ちょっと伝えたいことがあったので応募しました。

発表者の方と動画配信チームのおかげでできたComposerプラグイン

今回紹介したoctopackageの概要はこちらをみてもらうとして、この懇親会LTでは直接感謝を伝えることができて良かったです。

動画配信があること

発表資料と動画配信があってはじめて現場にちかづく情報量になる発表もあります。動画配信は本当にありがたいです。

今年のshin1x1さんの発表などはまさにソレではないでしょうか。

かつて自分も、発表資料と動画配信を合体させて配信するというアイデアzenpreというものを作っていました。動画コンテンツを作るのがどれだけ面倒なのかは知っているつもりです。

昨年も含めて今年もooharabucyouさんが関わっていることを知ることができました。ありがとうございます。

そして、すみません。今年もooharabucyouさんの動画配信を期待している発表がいくつかあります。ベストエフォートでのんびりよろしくお願いします。

発表があること

そして、さまざまな領域の知見を共有してくれる発表者の方には感謝です。

今回はHirakuさんでした。packagist.jpやprestissimoなど、最近のPHPerの「速さ」に対する貢献は大きいです。

Composerプラグインの世界を知ることができて良かったです。

少なくとも自分は、PHPライブラリをoctopackageで効率よくリリースができるようになりました。ありがとうございます。

今年もPHPカンファレンスは最高でした

スタッフの皆様、発表者の皆様、スポンサーの皆様ありがとうございました!!

最高でした!