読者です 読者をやめる 読者になる 読者になる

YAPC::Kansai 2017 OSAKA に参加した

一週間前の話であるが、YAPC::Kansai 2017 OSAKA に参加した。

yapcjapan.org

私が拝聴したのは、以下のとおり。合わせて感想も。

メールフォームからメールを送る近代的な方法

azumakuniyukiさん

www.slideshare.net

フォームからメールを送信するというのは今でもやってることだけど、それを昔はどうやっていたか、今ではどういうやり方がモダンなのか?という話。 懐かしい sendmail を使う話から、クラウドサービスである、Sendgrid を使う話へ。

新しい知識を仕入れるというよりは、過去を懐かしむ感じの内容だった。 ちょっとテーマからはそれるが、sendmail => qmail => postfix, exim というようなMTAの変遷についても語っていただけると個人的にはより楽しかったと思う。

オープンデータを利用したWebアプリ開発

立見哲也さん

www.slideshare.net

オープンデータは定期的に提供するほうが大変なんだろうな思った。

高速化の初歩

@risou さん

www.slideshare.net

素数を抽出するプログラムを題材とした高速化の話。 メモ化などのテクニックもあるが、すでにあるアルゴリズムを使うと最初から最適化されてるよねとか。

ご本人もおっしゃっていたがあくまで基本的な内容について触れたもの。 とはいえ、Tips なんかもあり、よくまとまっていた発表だった。 弾さんの「メンテナンシビリティじゃなくて、メンテナビリティ」とか「SQRTじゃなくて2乗したほうが速い」ツッコミもよかった。

Vue.jsで作るSPAから学ぶMVVM、非同期処理、その光と影

しんぺい a.k.a. 猫型蓄音機 さん

SPAを作る上でのJS上での設計思想の話。このあたりの知識はまったくないので、いい勉強になった。

Webアプリケーションのキャッシュ戦略とそのパターン

@moznion さん

speakerdeck.com

キャッシュの話。 最近、キャッシュについては必要に迫られており色々調べていたが、ちょうどいい整理になった。 キャッシュをどういうところで使うのかはアプリの要件次第といってしまえばそれまでだが、「こういうサービスにおいてこういうデータをキャッシュするとめっちゃパフォーマンスがよくなった、あるいは、全然よくならなかった」などのリアルな情報があればさらにうれしかった。

Mojoliciousではじめるマイクロサービスアーキテクチャ

@masakyst さん

こういうリアルな話はいい。 僕自身が mojolicious を使っていればさらに理解が深まっていたであろう。

Perl でわかる!サーバレス

@myfinder

Microsoftの中の人のAzureをつかったサーバーレスの話。デモもあってよかった。

利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み

@side_tana さん

Mixi のノハナというサービスがどうやって Parse.com から離脱したかという話。 非常に緊張感のある話だった。クラウドを使うのが当たり前になっているこの世の中、クラウドに依存したサービスはロックインしてしまっているとも言える。 単純にサーバを借りているだけならともかく、AWSで言えば、S3やAmazon SQSや便利なものがすぐに使えるので、どうしても使ってしまう。 使ってしまうとそのサービスはクラウドのサービスに依存していることになってしまう。とくに最近では日本は影響がなかったがS3が逝ってしまう事故もあった。

色々と考えさせられる発表だった。

TRUNCATE user;に如何にして立ち向かうか

@meru_akimbo さん

この後の発表とごっちゃになってしまってる・・・どんな話だったかな。。。(汗)

Webエンジニアに知ってほしいRDBアンチパターン

@soudai1025 さん

speakerdeck.com

一番ささったのがこの発表。もちろんベストトーク賞はこの発表に投票した(そして見事にこの発表が1位になった)

RDBアンチパターン」と題しているが要は「バックアップ」の話。 実際、今関わっているシステムで某サービスのバックアップの仕組みがちゃんと機能していないということが最近わかったということがあった。 バックアップの処理を仕込んでおいても、最初はちゃんと動いていても、今ちゃんと動いているかどうかはまったく別の話なのだ。 特に日々データ量が増えることによって、処理がタイムアウトしてしまうことや、バックアップに必要なメモリ領域・データ領域が確保できなくなるという問題がある。そこをちゃんとハンドリングしておく必要があるということだ。

またスライドにもあるように、データが小さいとリストア試験も案外簡単にそして短時間に終わる。ただデータ量が膨大だと「データの転送」に時間がかかる。復旧時間にダイレクトに関わってくるところである。

昔、毎日バックアップのリストア試験をしているサービスがあるという話を聞いたことがあるが、そこまでできるのが理想だろうなと思う。

終わりに

みんな若いのにすごいなぁ。 いつか発表する側に回れるかなぁ。