インターネットの普及とともに、インターネットを支える主要技術の多くを構築する OSS はより一般的なものとなりました。特に Web サービスやモバイルアプリケーションを開発する会社にとっては、コードを書く上で避けては通れないものとなりました。

OSS は小さいライブラリから、プロダクションで使用するようなフレームワーク、大規模なサービスを支えるミドルウェア、OS や言語のようなプログラミングの根幹とも言えるような要素など、ソフトウェアのコードベースの大小こそあるものの、それらは全て OSD に準拠しているものであり、誰でもコードを読むことができ、ソフトウェアによってはコントリビュートすることも可能です。

近年では GitHub の普及により、ライブラリやフレームワークについては身近なものとなりましたが、ミドルウェア、言語、OSについては GitHub を用いない開発スタイルも多く存在し、雲の上のような存在に感じるのではないかと思います。しかし、GitHub というツールの種類に関係なく、OSSというものはプログラマに身近なものです。

本発表では、Ruby というプログラミング言語のメンテナという立場から、プログラミング言語を例としてどのように開発の意思決定を行い、実装し、リリースされるかまでの一連の流れを紹介し、言語開発の見えない部分について露わにしたいと思います。

「PHP帝国は滅んでいない。新たなる希望を待ち、逆襲の機会を虎視眈々とねらっている」

遠い昔、はるか彼方の銀河系で…はなくて、去年、私は 私が愛するPHPはまだまだイケてる！ とホールで叫び、なんと皆様からベストトーク賞をいただけたYAPC::Asia Tokyo 2014から１年が経ちました。

あれからPHPに新しい事は起こったか？勿論起こりましたし、さらに 起こりつつあります！ 皆さんに是非お届けしなければ！ということで、今年もPHPの話をさせてください！

次のPHPは5.6から一気に7にバージョンアップされます 。「5.6の次が7って、おくればせながら流行にのってメジャーバージョンを切り捨てて5.7を7にしただけじゃないか？」なんてことはなく、メジャーバージョンアップにふさわしく変わります。

PHPなりに 高速に、安全に、パワフルに 生まれ変わりを果たそうとしています。その 来たるべき近未来であるPHP7 とその仲間達（周辺）について、オイシそうな所、気になる所を知っていただければと思います。

ところでPHP7は今開発中で、stable releaseは年末予定です。stableでない話に意味があるのかと思われるかもしれません。しかし、先日Alpha版がリリースされ、試していく土壌はもうできたと言えます！きっとYAPCまでにはかなりの完成度になることでしょう！（去年のYAPC::Asiaの初日に5.6がリリースされてスライドを書き直した事を思い出します…）

また、去年は「Perl Monger向け、或いはPHPをあまり知らない人向けトーク(半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応）)」でご好評をいただきましたが、 私の目標である「PHP仲間をふやすぞ！」 は進捗いまいち…、どうやらPHP仲間を増やすには、入門だけではない話をしなければならないようです！

すでにPHPを使っている方ついても、もっと実践的に、そして興味深くなるように、yumではいるApache+mod_PHPに適当にのっけただけ…、とはひと味違う、新しい感じがするPHPの構成の具体例をお話します！

また、PHPには長らく存在しなかった（$_GETとか、グローバル変数だった…）request/responseまわりがPSR-7という形で、多くのWAFがこれに準拠する動きを見せており、今後内部リクエストやテストがやりやすくなるのでは？と話題になっています。 もしこれがうまく普及すれば、PHPの泥臭さは一変する可能性を秘めていると思います。気になりますよね？

PHPは前進をつづけています！！

そう、PHPerの未来は明るいんだ！！

想定している主なトークキーワードは以下の通り

• PHPを知らない皆さんの為に5分(位)で わかった気になるPHP！
• PHPer以外も気になってるはずだ！PHPの近未来 PHP7の話！
• PHP7でサービスうごかしたら、 実際どうなの って話！
• あまり語られない構成の話、nginx+PHP、H2O +PHP！
• あのPHPにもhttp::request/responseみたいなやつがくる！(？)PSR-7の話！
• 最近動きが激しい PHPer以外は追わないだろう PHPのWAFやパラダイムの話！
• (もしかすると) PHPでも できる （けど必要あるのか）あれやこれや
• (時間が余れば) 「 It's a Trap! 」

話さない事：PHP7内部実装等の話は しません 、WAFの使い方的な話も しません 。

勿論今回も 幅広い層、特にPerl Mongerの皆様に合わせたお話をさせていただきたい と思いますが、実際に今PHPを使われている方でも興味深いように、モダンを通り越して、まだ来ていない未来の話をします。

PHPをなんとなく使っている人、PHPとか遅いんでしょ？って思ってる人、PHPは他の言語と違いすぎるから…なんて勘違い（？）している人、とにかくPHPを滅ぼすためにもヤジを飛ばしたい人。是非 応援(上のボタンのシェアやいいね！)宜しくお願い致します！

Perlワンライナー便利です

たくさんの技術があるなかで、適切な場面で適切な技術を選択するのは大切です。 自分が働いているフリークアウトはアドテクと呼ばれる業態です。Perlで業務を行っています。 弊社の業務ではログファイルなどで何十万行程度のテキストファイルからアドホックにデータを抽出・加工するような業務が頻出します。 自分はそういった場面ではPerlを選択するのが最善ではないかと思っています。

pythonで5分かかる作業を30秒で書いたワンライナーがなんとかしてくれる様子は「Practical Extraction and Report Language（実用データ取得レポート作成言語）」の面目躍如といった趣があります。

似た領域の技術にawkがありますが、かなりややこしいことまで出来るPerlワンライナーをおぼえておいても損はないはずです（-Mオプションもございます）

内容

この発表ではperlワンライナー初心者を対象にしています。ハンズオンで下記内容でやるつもりです。

• ワンライナー入門
• grep, awkの代わりにperlを使う方法
• あるあるな業務へのワンライナー例紹介

※ ハンズオンはwindows環境の動作未検証です

ハンズオン用の資料

• スライド: https://www.swipe.to/7299cm#page=Z0S6J59Zt
• $ git clone https://github.com/sakamossan/yapc_perl_oneliner_beginner.git

はてなブックマークの「トピックページ」の作り方について解説します。 トピックページとは、話題の記事の中から関連性の高い記事をまとめることにより、インターネット上で話題となったトピックを閲覧できるページです。 はてなブックマークに蓄積された過去10年分の記事データを利用することにより、過去10年間の話題から最新の話題までを閲覧できるようになっています。

「トピック」機能は、これまで何人かのエンジニアが挑戦してきましたが、トピック生成の精度が低いという問題やトピックタイトル生成が難しいという問題により実現できていませんでした。 これらの問題をElasticsearch と自然言語処理技術を活用することにより解決したので、そのアプローチを紹介します。

アジェンダ(予定)

• トピックページとは
• これまでトピックが実現できなかったのはなぜか
• Elasticsearchを用いたトピック生成
• 自然言語処理技術を用いたトピックタイトル生成
• トピックページの今後

OSSとして公開されるソフトウェアは多くありますが、そのうち広く世に出るものはあまり多くありません。また開発者コミュニティやユーザコミュニティが形成されるところまで成長するものはごく一部といって良いでしょう。

ライブラリ等ではそれでも特に問題はありませんが、高機能なミドルウェアなどになると多くのユーザがつかないとオリジナル開発者が想定した以外のユースケース発見やコーナーケースにおけるバグ発見などが十分に行われず、プロダクトの品質も上がらない、といったようなこともあります。 また日本国内では比較的よく使われても、米国を含めた国外ではあまり知られないまま、というケースも多く存在します。特にミドルウェア等については有名な巨大サービス企業が発表したものとそれ以外で顕著な差があり、開発者個人として何ができるのかを考えることも多くはないでしょうか。

このトークでは、いちソフトウェア技術者としてOSSプロダクトを作り公開しメンテナンスし、また世に広めるための活動をする中で、我々がするべきことは何か、やったほうがいいことは何かなどを、FluentdやNorikraといったソフトウェアにおける経験をもとに他の例も見ながら議論したいと思います。

• プロダクトの種類と言語の選択
• プロダクトの公開
• バージョニング
• 開発者の言語、コミュニティの言語
• コミュニティ形成の方法
• 有名人問題
• ローマへの道は一日にしてならずぢゃ

エンジニアには、なぜか「技術」についてブログに書き残すという文化があるということはここでは言うまでもないと思います。

新たに投稿されるエントリを見かけない日はなく、なんらかの技術について書かれたエントリが毎日のようにエンジニア界隈を賑わせています。

技術ブログの内容は人それぞれです。 自分が注目している流行りの技術の紹介であったり、自分が作ったソフトウェアの紹介であったりします。 ときには「ポエム」と呼ばれるような、技術を通して自分の考え方や生き方を表現したものもあります。

その技術ブログの評価システムの代表的なもののうちの１つとして、はてなブックマークがあります。 テクノロジーカテゴリのホットエントリを日常的に眺めて、技術そのものもしくはエンジニア界隈の情報を仕入れたり、エントリにつけられるブックマーク数をブログを書くモチベーションにされている方も多いのではないでしょうか。

発表者もそのうちの１人です。趣味が高じて、最近では、はてなブックマーク200users以上のブログエントリを月刊投稿する、ということを目標にしています。

技術ブログで毎月200users以上を確実に達成しようとするのは想像以上に困難です。 そもそも自身とブログへの向き合い方から見直す必要がありました。

最初は目標を達成するだけで満足していました。しかし、コンスタントに目標を達成できるようになってくると、単に200usersを達成するだけには飽きてきて、徐々にこだわりがでてきます。 こだわりとは、例えば、技術文章として格式のあるものにする、エントリタイトルで煽らない、エンジニアの採用活動につなげる、自分にできるかぎり硬派な技術について書くといったものです。

このような活動を続けていくと、200usersを目標にしていたはずが、気づけば先日書いたエントリで1000usersを達成しました。

もちろん、1000usersというのは所詮はただの数字です。 しかし、そこに到達する過程には、数字以上の意味を持たせたくなります。 「はてなブックマークはタイトルが9割」といった小手先の人気取り的なテクニックはもちろん、「煽る必要はない」、「ネガティブコメントは正攻法でねじ伏せられる」などといった技術ブログ体験を良くするためのいくつかの知見を得られました。 さらには、文章を書くという行為を通して、自身のエンジニアとしてのキャリアや生き方を考えるきっかけにもなりました。

これらの経験を元に、本発表では、以下のような方々を対象に、正攻法ではてなブックマーク1000usersを獲得するための技術、あるいはその精神について語ります。

• 技術ブログをこれから書いていきたい
• もしくは技術ブログを書くことへの意義に疑問がある
• 書いてはいるが思うようにブクマがつかない
• せっかく書いたエントリに対するネガティブコメントに悩まされている
• とにかく「今すぐ〇〇を使わないと死ぬから△△すべき10の理由」というようなタイトルをつければよいと思っている

blog: http://yuuki.hatenablog.com/

Let the festivities begin!!

Ho, ho, ho!

（編注：Perl6は今年のクリスマスのリリースに向けて準備中らしいですよ！）

Linux containers provide the ability to reliably deploy thousands of application instances in seconds, but how do we manage it all? The answer is CoreOS and Kubernetes. This talk will help attendees wrap their minds around complex topics such as distributed configuration management, service discovery, and application scheduling at scale.

昨今 Deep Learning がもてはやされていますが、その前にパーセプトロンだけではなく、私が研究で利用してきた下記のようなニューラルネットワークについて紹介したいと思います。

• 再帰的ニューラルネットワーク：
  • 系列学習を可能にするニューラルネットワークの形式の1つです。
  • また、学習方式の一つとして予測学習を紹介します
    • 特に Elman Network についてお話します
• 自己組織化マップ：
  • セルの近接性が学習に影響をおよぼすネットワークアーキテクチャのニューラルネットワークです。

上記を知った上で Deep Learning を適用することで更に様々な分野への適用などを考えられるのではないでしょうか。

はじめまして、こんにちは！jigyakkumaです！！！！！１
Infrastructure as Codeが叫ばれる昨今、ドメインやDNS管理・運用にもその波が押し寄せておりますが皆様いかがお過ごしでしょうか。

私が所属している組織では取り扱うドメイン・DNSの数が比較的多く、管理・運用でのベストプラクティスを日夜模索しながら改善を行っている状況です。
運用や管理といった分野は各社のエンジニアや担当者がそれぞれ構築した仕組みやルールで運用を行ってはいるが、ノウハウの共有や知見を得る機会があまりないと感じております。
会社で所有しているドメインやDNSについて運用の手間やトラブルなどでお困りの方も、もしかすると多いのではないでしょうか。

本トークではドメイン登録代行サービスを使用した人力による運用を経てAWS Route53にドメイン・DNSを集約するまでの背景やメリット、注意点を中心に会社としてどのように管理・運用するのがよいかを実例を交えてお話しいたします。
実体験や失敗談を時系列で追うことにより、皆様のお困りの点や今度どのようにするのがいいかなどの参考になればと思います。
また、組織×運用×仕組みといった技術以外のところについても触れながら、ドメイン・DNSをどのように管理・運用するのがよいのかを考察したいと思います。

トークテーマ（予定）

• ドメイン・DNS管理/運用の変移
• AWS Route53へドメイン・DNS管理の集約
• AWS Route53へのドメイン移管
• roadworkerによるDNS管理への移行
• CIによるroadworkerの自動化
• 組織×運用×仕組みから見るドメイン・DNS管理
• 事故った事例やトラブル

webサービスに携わるエンジニアの方々には広く知っていただきたい内容であるとは思いますが、特に以下に該当するような方に向けた内容とする予定としております。

想定する対象者

• ドメインやDNSについてなんとなく知っている方・興味のある方
• 業務やプライベートでドメインやDNSの管理に関わっている方
• ドメイン・DNSの管理でお困りの方
• 他社のドメイン・DNS管理のノウハウを知りたい方

また、この辺りのノウハウを共有させていただきつつ皆様の運用テクニックなどの情報交換が出来ればと考えております。

いまだにES5時代のJS書いてませんか？

今年6月に公開されたJavaScript仕様の超大型アップデート ES6 を紹介し、それによって変わるJSコーディングのベストプラクティスについて話します。

---

JavaScriptはWeb開発では必須のポピュラーな言語でありながら、その言語仕様は「クセ」が強いことで知られています。

関数スコープ、暗黙の型変換、プロトタイプ継承、ホイスティング、配列の「ような」オブジェクト、new、...etc

そんなJavaScriptとの長年の格闘を経て、Effective JavaScript、JavaScript: The Good Partsといったベストプラクティスが生み出され、普及していきました。

ときは流れて、今年6月に待望の最新仕様ECMAScript 6が公開されました。 ES5から5年、大幅なアップデートとなるES6は、これまであったJavaScriptの多くの落とし穴をふさいでくれます。ES5時代に使われたベストプラクティスの中には、ES6の登場によって置き換えられるものが多数あります。

このトークでは、ES6で導入された新しい機能を紹介し、それによってこれまでのベストプラクティスがどう変化するかを話します。また、各ブラウザの実装状況、トランスパイラの存在、ES6以降の仕様策定などを踏まえて、これからのES6との付き合い方についても話します。

JavaScriptのエキスパート向けではなく、Webに関わる全てのエンジニアにとって、JavaScriptの現状＆未来確認に役立つトークになればと思います。

話す内容

• ES6とは何か？
• BabelでGO!! 今すぐ使えるES6
• ES6の主要機能の紹介
• ES6時代に不要になるベストプラクティス
• ES2016, ES2017 and ...
• これからのES6との付き合い方

スピーカー

• @teppeis
• Blog, GitHub
• WEB+DB PRESS Vol.87 にてES6特集を執筆

週末兼業から始まったプロジェクト

「鍵ロボットをつくりたい」

大手メーカーとIT系ベンチャーに所属する若手エンジニアたちが、一つのハードウェアデバイスをつくるために、 会社を辞め、起業し、プロトタイプをつくり、量産機を工場でつくり、出荷するまでの駆け抜けた半年間。

今回はWebエンジニアとして生きてきた自分が、どうやって組み込みのセカイに足を踏み入れたのか、 待ち構えていたハードルをどうやって乗り越えたのか、Webエンジニアだったからできたことはなんなのか？ デジタル（ソフト）なセカイだけでは知らなかった、0から1にするまでの間のアナログ（ハード）なできごとを包み隠さず話します。

トークの内容（予定）

• Webエンジニアの組み込みの始め方、楽しさ
• Webの技術がなければできなかったハードウェアを支えた技術
• Web〜ハードの複数のレイヤーをまたがって思考することの大切さ
• Web由来の組み込みエンジニアの重要性
• 組み込みプログラミングをやるために知っておくべきこと

• 他

  　

Miiverse とは任天堂株式会社が運営しているウェブサービスであり、世界中の Wii U やニンテンドー3DS、そして PC やスマートデバイスから利用することができます。

AWS 上でマルチリージョン構成をとり大量のサーバを抱える Miiverse のデプロイを支える技術と運用上の工夫、そして株式会社はてなと任天堂株式会社が共同で開発する Git リポジトリの同期システムの構築を通して得られた経験をもとに、大規模なウェブサービスを素早くかつ安全に改善する方法を紹介します。

概要

• これまでの Miiverse のデプロイ
  • 採用している技術の紹介
  • 運用の概観
  • 運用上の tips
• Git リポジトリ同期システム
  • 背景
  • はてなにおける先行事例
  • アーキテクチャ紹介
• 新しいアーキテクチャのデプロイ
  • 現状のアーキテクチャの課題とその解決

取り上げる予定のキーワード

• マルチリージョン
• Git
• GitHub, GitHub Enterprise
• デプロイ
  • Capistrano 2
  • Cinnamon
  • Consul
• オートスケール
  • Mackerel
  • Amazon Web Services

TBD

ここ最近のフロントエンドに対しては、

---

• 流れが速すぎてついていけない
• あるライブラリを使おうと思ったら今はみんな別のライブラリを使ってると言われてもう何を使えばいいかわからない
• ビルドするのが当たり前になっていて、HTML/CSS/JavaScriptを少し修正したいだけなのにどうすればいいのかわからない
• importやclassなど自分の知っているJavaScriptでない
• せっかく覚えても半年後には使えない知識になっている

---

という意見を聞きます。果たしてそうでしょうか？

そこで本トークでは、サーバーサイドをメインで書いている人に向けてフロントエンドの今をいくつかのトピックに分けて解説します。

例外もありますが、新しいライブラリは突然何の脈絡もなく登場したわけではなくそれまでの流れを踏まえて登場しています。

本トークでは、個々のライブラリの使い方紹介ではなく、その背景や目的などに注目することで、 点 ではなく 線 でフロントエンドの流れを掴めるようにしたいと思います。 それによって今後新しい何かが登場した場合にもその意味が捉えられやすくなるのではと考えています。

変更の可能性はありますがトピックは下記のような内容を想定しています。それぞれが「なぜ生まれたのか」、「何を解決しようとしているのか」を解説します。

---

• JavaScript Framework(library)
• Isomorphic
• Functional Reactive programming
• Build tools
• ES6, types, AST
• Service Worker

---

フロントエンドは別のエンジニアがいるから関係ないと思うかもしれませんが、フロントエンドでは何が出来るのか・何が問題なのかを把握しておくことはアプリケーションの設計やサーバーサイドの開発においてもきっと役に立つはずです。

空をとぶということは有史以来の人類の夢である。それゆえ実現するには相応の困難が待ち構えている。

その中でクアッドコプター(4枚のプロペラを持った回転翼機)というジャンルは単純な機構でありながら、センサーとフィードバック制御の力で本来航空力学的に不安定であるはずの形状を制御することに成功した形態である。

昨年のトークでは、様々なIoT向けキットを紹介しつつ組み合わせてものを作る方法を提案したが、今回のトークでは既成品を利用して

• 外から自動制御する
• 内部を解析して乗っ取る
• 外骨格とパーツだけ利用して中身は取り替える

をテーマにPerlでドローン(=自立飛行する航空機)を作るのを目指す。

このトークで伝えたいこと

• クアッドコプターというジャンルの面白さ
• Perlにも得意不得意がある。不得意をいかに補うか

対象者

• どうしてもPerlでドローンを飛ばしたい人
• Perlじゃなくてもいいけれどドローンを飛ばしたい人
• Perlじゃなくてもいいけれどハードウェアを乗っ取りたい人
• 電子回路の仕組みについて興味がある人
• どうしてもPerlでいろいろ作りたいけれど別にドローンじゃなくていいけれどリアルタイムでなにかやりたい人

このトークで話すこと

• クアッドコプターの仕組み
• 外部から操作する
  • 波形を見てかーらーのー電気的介入
  • それでもダメなら例えば物理で抑えこむ
• みんな大好き電波の話
• 乗っ取るのがダメなら基板ごと入れ替える
• Perlによるハードウェア制御
  • Perlでもリアルタイムしたい！　でもイベントドリブンは嫌だ！

2015年5月の RFC 化完了以降、主要なウェブブラウザの HTTP/2 対応が急速に進んでいます。今年末までには、HTTPS トラフィックの過半は HTTP/2 を利用するようになるでしょう。

本セッションでは、先進的な HTTP/2 サーバとして注目されている H2O の主開発者である奥一穂が、HTTP/2 策定の背景と HTTP/1.1 に対する優位性、HTTP/2 時代にむけたウェブサイト設計のポイントについて説明します。

Since the completion of the standardization process in May 2015, Web browser vendors are rushing to support HTTP/2. It is likely that the majority of HTTPS traffic will be using HTTP/2 by the end of this year.

In this session, Kazuho Oku, the lead developer of H2O which is gaining world-wide attention for its advanced features in its HTTP/2 support, talks about the background of HTTP/2 specification, its advantages over HTTP/1.1, and how to architect the websites for the HTTP/2 era.

カヤックが運営しているスマートフォン向けSNS Lobi は、Amazon Web Services(AWS)上でHashicorp社が開発しているオーケストレーションツール Consul を活用し、EC2インスタンス100台規模のサーバと、AWSのマネージドサービスを利用して運用しています。

Consulの機能と、それを活用するために開発したOSSとともに実践的に運用している事例をご紹介します。

• Consulとは
  • 機能の紹介
• Consulを本番環境で運用するために
  • 構成
  • 監視
  • 高可用性のためのノウハウ
  • クラスタ障害時のリカバリ手法
• オートスケール環境で動的に増減するサーバを扱う
  • DNS interface によるホスト、サービスの名前解決
  • コマンドのホスト名補完
  • 自前オートスケールやjob管理へのconsul execの応用
• Stretcherを利用したデプロイ
  • 自作OSS
  • Consul Event, S3と連携してスケーラブルなデプロイを行う
• Consul KV Dashboard によるダッシュボード、通知システム
  • 自作OSS
  • Consul KV (key value store)を利用したリアルタイムダッシュボードWebアプリケーション
• Chefによるプロビジョニングとの連携
  • Chef-ServerとConsulを利用してノードを発見する
• Zabbixによる監視との連携

Lobiについて

• 公開コミュニティ12万以上、SDK導入アプリ590以上 (2015年2月現在)
• 言語: Perl, Go, Node.js
• ミドルウェア: Consul, Nginx, MySQL, Starlet, Fluentd, Norikra, memcached, HAProxy, dnsmasq
• AWSマネージドサービス: S3, CloudFront, Elasticache, Route53, Redshift, SQS, ElasticTranscoder, CloudWatch

I have been working remotely for more than a decade. Half of that time has been in a technical leadership capacity. I often hear people say it's obviously harder to work remotely, and very hard to be in a leadership position remotely. My experience says otherwise, and I would like to share what I have learned to make remote work an effective strategy.

This is about being a remote worker or working on a distributed team. I am convinced this is the path software organizations are rightly headed, and I am determined to help you get there. I will present the tools and vocabulary to give you the confidence to try it.

WebAudio によるコネクティビティの向上

WebAudio はウェブの世界では数少ない、リアル世界との接続方法を提供する技術の一つである。

ウェブから「ディスプレイに何かを表示する」以外の方法で、出力するだけならば何らかのユーザ同意をとることもなく、直接リアル世界と繋がると考えると、貴重な技術である。

本セッションでは WebAudio を用いてモデムの実装をしながら、音声帯域の通信信号処理について簡単な紹介をしたい。

概要

• WebAudio とは? -- WebAudio の概念(AudioNode / connect などの簡単な説明)
• 特殊なノード AnalyserNode, ScriptProcessorNode
• getMedia によるマイク音声入力
• 音声帯域での通信 -- 電話回線モデムのプロトコルは?
• 変調/復調とは? -- 原始的な変調方式
• エラー訂正
• 昨今のトピック・技術的課題 -- 超高音 (16kHz〜) 通信

喋ろうとしている/喋るかもしれないキーワード:

• WebAudio ScriptProcessorNode
• WebAudio のデバッグ方法・バッドノウハウ
• AnalyserNode はどこまで使えるか?
• 変調/復調
• 変調方式 (OOK, FSK, ASK, PSK)
• エラー訂正
• IoT との連携 (バッテリーなしデバイス)

想定観客層

• ウェブエンジニア
• WebAudio を音楽鳴らせるだけだと思ってる人
• WebAudio を触ったこともない人

概要

「データ構造やアルゴリズム、計算量について知っておく事は、プログラマにとって、とても大切なことです」といろんなところで言われています。一方で「そんなの知らなくっても降ってくるお仕事は片付けられるもんねー」というのも、まあ、たしかにそうですね、という感じがします。でも、データ構造と計算量のことを知らないでいると、カジュアルに下手なインデックスを貼ってしまったり、単純な集計のはずなのに6時間動き続けて返ってこない……のようなスクリプトを書いてしまったりすることがあるので、やっぱり、プログラマにとってデータ構造やアルゴリズム、計算量の基本を知っているというのは、とても大切なことなんじゃないかな、とわたしは思っています。少なくとも、「計算機の気持ちになってコードを読み書きする」ときの助けになることはたしかです。

でも、やっぱり計算量の話とかって、とっつきづらいですよね。「でもさー。わたし、文系なんだよね。なんか計算量がどうこうとかいうひとたちって数式でしゃべるじゃん。log とか？ アクセスログかよって思う。日本語でしゃべれって感じだよね」みたいな。わたしも文系卒なので、そんな気持ちはよくわかります。というか、わたしはそう思っていました。この発表は、そんなひとたち(つまり、昔の自分)がなるべく苦痛を感じないようにデータ構造と計算量に触れ、その後の独学独習の助けになるような基礎的な知識をつけてもらうことがゴールです。

C言語による解説が一部入るかもしれませんが、多くのサンプルコードはPerlで記述する予定なので、C言語に苦手意識のある方でも楽しんで聴いていただけるのではないかと思います。

アジェンダ（仮）

• データ構造について学ぶ前の基礎知識
• 配列
• 単方向連結リスト
• オーダー法について
• 2分木
• B木
• B+木

以上のデータ構造について見ていきながら、時間計算量について、なるべく平易に、しかし嘘をつかないように、実際の事例を交えながら学んでいきます。

対象となる方

• コードを書くことはできるけど、「このデータはメモリにどう展開されるから〜」とか言われるととたんに置いていかれるひと
• アルゴリズムやデータ構造などに対して苦手意識が強い

対象とならない方

• 上記のデータ構造をすでに理解できているひと

日本のWeb業界において古くから利用されているPerl。 そのためか、「Perlといえばベテランエンジニアのもの」といったイメージをもたれがちなのではないでしょうか。 一方、モバイルファクトリーを含め、開発言語にPerlを採用している多くの企業では、若手エンジニアが活躍しています。

本コンテンツでは、各社の若手エンジニアを招いた座談会で「Perl=ベテラン」というイメージを払拭したいと思います。 ※登壇者は各社調整中。決まり次第追記します。

登壇者（7/29追記）

• @mihyaeru21さん
• @__papix__さん
• @hisaichi5518さん

• @zoncoenさん

• ファシリテーター：@crazygirl_lover

具体的な内容

• そもそもPerl業界におけるベテラン勢の勢力とは
• こんなベテランはいやだ！
• Perl業界に期待していること、変えていきたいこと　など

発表者は，この三年間はてなブログというイケてるPerlのサービスの開発に携ってきました…

Perlの最新を追い求め続けた三年間でした…

なにも分からず，SQLをコピペし続けた数ヶ月…

つらいことも，たのしいことも，みんな分かちあったコードベース…

救いを求め，藁にもすがる思いで，朝も夜も読み続けたオブジェクト指向入門……

偶然発見して，これだと思ったドメイン駆動設計……

苦しみの軌跡と，現在最高の設計を紹介します………!!!!!!!

当時最強のフレームワーク

• それまでの，社内フレームワーク
• 鳴り物入りで登場した，当時最強のフレームワーク
• 社内でも歓迎されたが……

最強のフレームワーク vs 最強の複数人開発

• 一人でメンテナンスする限界，そして，増える開発メンバー
• 崩壊するコピペ3回ルールの行方とは……

継続デリバリー派の登場

• 毎週stagingブランチ作る派 vs stagingブランチはひとつでいいよ派
• 続々出版される継続デリバリー，その全てがみんな知ってる内容であった……

ORMからの脱却，そして，ORMへの回帰

• コピペされ続けるSQL
• さすがにこれはないじゃん感，その先に見たCommon::ネームスペース

Service層の導入

• コピペ解消層としてのService層と，その設計指針
• これオブジェクト指向ではないんでは説

オブジェクト指向入門

• 人類にはクラスは早すぎた
• オブジェクト指向入門を読んだ人間だけがインスタンスを作れる
• その実態は，ほぼ全てのメソッドをクラスメソッドで実装する暗黒時代であった

SQLからService層への変換

• 新しく書くときにちまちまリファクタリング
• 機械的に書き換えるため，静的解析や，動的解析を導入
• 必要に迫られてリファクタリングツールを開発 App::PRT (YAPC 2014参照)

そして，ドメイン駆動設計への道

• Service層の再発見
• 我々のアーキテクチャは10年前にEric Evansが発見していた
• 社内でのDDD普及期，勉強会で得た知見

銀の弾丸を拾い続けた3年間を振り返って

• 現状に満足せず，常により良いアーキテクテクチャを考えることが重要
• なかなかよいペースで拾い続けることができた
• 今後もはてなブログは最高のアーキテクチャであり続けます!!!!!!!!

This talk will be an overview to building Desktop apps with the Electron project. Electron underpins popular desktop apps like Atom, Slack, Visual Studio Code, and Mapbox Studio.

The talk is directed at anyone who has written code for the web. It will cover the following ground:

• What is electron? Node + chromium = :D
• Why did we build it?
• What’s possible with electron?
• What does an electron app look like?
• Demo using perlito to build a small app
• Demo of a larger app with a little live coding
• Jokes

Links!

• http://electron.atom.io/
• https://github.com/fglock/Perlito/
• A deeper technical set of slides on Electron (formerly atom-shell) https://speakerdeck.com/zcbenz/practice-on-embedding-node-dot-js-into-atom-editor

「esa」は esa LLC が開発・運営しているチーム向けMarkdownドキュメント共有サービスです。2015年1月に正式リリースされてから約半年、βテスト期間も含めると1年ほどになります。

本トークではエンジニア1人とデザイナー1人で開発・運営・経営・営業などを行う上で考えたこと、経験したことなどを中心に、オフの時間に趣味で作り始めたWebサービスを事業化することについてお話したいと考えています。

発表内容(予定)

• 私は誰?
• esa LLC とは
• esa.io について
• この発表はこんな人におすすめ
  • 趣味のようにプロダクトを作って生活していきたい人
  • esa.io の中のひとの考え方に興味があるひと
  • トリが好きな人 (\( ⁰⊖⁰)/)
• Before esa
  • お仕事でいろいろ
  • 趣味でいろいろ
  • いろいろやってたらいろんな人々に出会った
    • ポエム界隈 #とは
  • いろいろ試すの、大事
• Beginning of esa
  • 某サービスの試用期限が切れた
  • 毎日がハッカソン状態
  • 毎日ドックフーディング
  • 知人の会社が使ってくれることに
  • 会社にした
  • オープンβでの反省
  • esaじゃないほうの会社をやめた
• How to develop esa
  • 楽しく開発したい！！
    • ...しかし楽しさ自体はコントロールできない
  • やれることを、やる
  • 毎日 Auto Bundle Update
  • 小さく作る・素早く試す
  • Bug Fix タイムアタック
  • フィードバック駆動開発
  • 心からのドックフーディング
  • よく寝る( ˘ω˘)
  • We're Not Hiring
  • Herokuを使う
  • リリースノート駆動開発
  • 開発スケジュールを決めない
  • かわいみ
    • Tシャツ
    • ステッカー
    • twitter.com/esa_io
• ﾌﾘｶｴﾘ
  • 5年前の日記
  • Re: 5年前の日記
  • 試行錯誤しよう
• まとめ

Perl (あるいは他の言語) を用いて料理・調理を自動化するという話をします．
料理は時間と手間がかかる営みですから，21世紀に生活する我々はこれを可能な限り自動化していく必要があります．

話す内容

2015年はプログラミング料理界にとって本当にエポックメーキングな年となっています．私は大変興奮しています！

皆さんは nomikuというデバイスをご存知でしょうか．nomiku は簡単に言うと，鍋に装着して使う料理器具で鍋の中の温度を一定に保ってくれるというデバイスとなっています．これにより，人間が火加減を逐一確かめて調節するという手間を省き，機械に調理を任せることが可能となります．

そして2015年，nomiku は更なる進化を遂げました．Wi-Fi を介して操作できる nomiku WiFi が登場したのです．
このモデルは nomiku を遠隔地から操作するという機能を提供しているだけではなく，なんと Web API の利用 もサポートしています (しかもオープンソース！)．nomiku 自体がサーバとなり，調理の為の Web アプリケーションを提供しているというイメージです．

さらりと書きましたが，これはすさまじい事です！　API を利用して料理をすることが可能な時代が到来しているのです！　ワクワクするでしょう！
日頃人間がこまめに様子を見ながら「この状態になったら弱火にする」などといった風にしている操作を，「状況に応じて適宜 API を叩く」というコードを書くことで自動化することが可能となるのです．
さらに言えば，これはつまり「ソースコードを共有することで料理のレシピを共有出来る」「レシピの再現性が著しく向上する」という時代がすぐそこまで来ている事を意味しています！

本トークではそうした Web API を用いた料理・調理の自動化 が秘める可能性について，サンプルコードに Perl を使いながら発表したいと考えています．その実例として Perl を用いてローストビーフを自動化する事例を紹介予定です．
また，nomiku は「煮る」という単一の調理方法しかサポートしていませんが，そこから一歩踏み込んで「焼く」「揚げる」「蒸す」といった他の調理方法に関して自動化を応用する事についても議論したいと思います．
更なる応用として，crontab や CI などと組み合わせる事で生じる料理の自動化の広がりについても模索する予定です．

併せて，Arduino あるいはそれに準ずるデバイスを用いて nomiku クローンを実装する話についてもお話できればと考えています．

最近は microservices という言葉がバズっていますが、これから Web サービスの開発を始める人にとってみたら「 microservices ってなに？おいしいの？それって僕らの作りたい物にも役に立つの？」と思っている人が多いとおもいます。

実は、私は昔からこのアーキテクチャに基づいた考え方で数多くのサービスを作り運用してきました。それらの知見を多くの方々の知識とノウハウにになる形に落とし込んで今回は発表しようと思います。

本トークでは、そのような Web サービス開発現場の newbie から中級層の方向けに「 microservices 的なサービス設計方法」「スタートアップサービスでの現実的な microservices の取り入れ方」「それらのメリットデメリットを」「ある程度トラフィックが有るサービスでのキーポイント」などを中心として、「多人数チームでの開発方法」「サービス稼働中の仕様変更」「運用トラブル etc」などなど具体的に踏み込んだポイントまで、明日からの現場の仕事で役立つトピック満載でお送りする予定です。

触れること

• microservices とはなんぞや
  • メリット/デメリット
  • microservices 化できるサービス/できないサービスの切り分け
• 具体的な実装時のポイント(実装例は Perl を想定する)
  • サービスを細かく切り分ける勘所
  • サーバ構成の考え方
  • 柔軟性が高い構成の指針
  • URI 設計
  • API の為の Protocol
  • ハマりがちなポイント
  • 性能評価手法
  • QA/Deploy
  • リポジトリ戦略
• 運用関連
  • メンテナンスに強くするためには/実際のメンテナンス手順
  • 仕様変更の対応手法/仕様変更に伴う問題対処方法
  • ドキュメント

概要

PietはDavid Morgan-Marが考案したスタック指向プログラミング言語で、ソースコードがドット絵で表現されることが特徴です。Piet話者は文字の代わりにドットを打つことでプログラムを記述し、変数の代わりにスタックに整数を保存することで計算を行います。 このトークではプログラミング言語PietへのチュートリアルとPietでLISP処理系を実装するのは難しいねという話をします。

これは何ですか

私がPietと出会ったのは今年の3月でした。 私が所属しているサークル「京大マイコンクラブ(KMC)」では毎年3月に部員が1年の間に得た知見を発表しあう春合宿というイベントが開かれます。そこにはKMC現代表のdamaさんによる「Pietのエディタを作った話」があったのです。当時難解プログラミング言語といえばBrainf*ckおよびその派生言語しか知らなかった私にPietは大きな衝撃を与えました。スタックという高度なデータ構造。豊富な命令セット。秩序だった命令実行システム。これほどパワフルな言語機能を備え、それでもなお難解プログラミング言語でありつづけられるPietは、ただ読みにくい言語以上の奥深い何かを秘めているように感じられます。YAPC::Asia Tokyo 2015でPietによるプログラミングの楽しさ、Pietプログラムの美しさなどについて伝えられれば幸いです。

これは具体的に何ですか

• Pietとは
• Pietの言語仕様の解説
• 簡単なプログラムの実装
  • Hello, World!
  • 電卓
  • PietによるCGIアプリケーション
• LISP処理系の設計概観
• LISP処理系の実装 といった話をします。時間の都合や実装が完成しなかったなどの理由で構成は変更されることがあります。

どのようなメリットがありますか

• PietでWebアプリケーションが書けるようになります。
• Factorなど他のスタック指向プログラミング言語を学ぶ際のステップになります。

• LISP処理系を書いてみようというモチベーションが生まれます。

  PietでLISP処理系を書くのは難しい from Hideaki Nagamine

Perl6 のリリースが近づいてくる中で、いい加減触ってみるか! という方も多いと思います。 一方で、Perl6 ってライブラリが全然ないし、なにもできること無いんじゃないの? という感想をお持ちの方もいらっしゃることでしょう。 そんなことはありません。

Perl6 は JVM 上で動くんです! 実は!

JVM で動くってことはあんなライブラリ、こんなライブラリも利用できるってことなの?? ってきになってきますよね。

本セッションでは JVM で動く Perl6 を利用して、どのようなことができるのか、どの程度 java のライブラリを活用できるのか、といったことについてご紹介したいと思います。

人間は間違える生き物である

以下の問題を解決するヒントになる話をします:

• 既存のコードを誤って壊してしまうことがよくある
• 作業手順が多くよくミスをしてしまう
• 設定が正しいのかどうかよくわからないので祈りながらdeployをしている

このような問題はなにを引き起こすでしょうか？ たとえば、Webアプリケーションの開発においては、誤ったデータベースの変更や決済処理を正しい状態に戻すことは難しいでしょう。 また、iOSやAndroid向けのアプリケーションの開発においては、リリースしてしまったコードを消すことはできません。 ソフトウェアにはこのようなリスクに対する安全性が求められます。

そういった意味での、安全なアプリケーションとはなんでしょうか？ 一般的には、安全なアプリケーションであるために、以下のような要素が必要とされると思います。

• クラッシュしにくい
• オペレーションを間違えにくい
• データを破壊しにくい
• コードを書き換えても壊しにくい

このような安全性を担保するために、どのようなプラクティスがあるでしょうか？

そして、なぜこのような問題が起こってしまうのでしょうか？ 自分が無能だから？環境が悪いから？違います。 これらの問題は本来、仕組みによって解決可能な問題です。 人間は間違える生き物です。なので、間違えることを前提に仕組みを構築する必要があります。

本セッションでは安全工学の視点を取り入れつつ、具体的なヒヤリハット事例/ヒューマンエラー事例と共に、安全なアプリケーションを構築する技術とその基本的な考え方について、僕の考えを話します。 なお、セキュリティに関連する話も安全性に大きく関わるところではありますが、本セッションでは時間の都合上扱わない予定です。

トピック:

• ソフトウェアにおける「安全」とはなにか
  • ハインリッヒの法則
• 安全性を担保するための考え方
  • フォルトツリー解析
  • ポカヨケ
  • etc..
• 安全性を担保するための言語機能
  • 型制約
  • Optional
  • etc..
• 安全性を担保するためのライブラリ
  • strict.pm/warnings.pm
  • Perl::Lint/Perl::Critic/etc..
  • DBIx::TransactionManager
  • etc..
• 安全性を担保するためのプラクティス
  • assertion
  • defer/guard object
  • max reqs per child
  • 静的解析
  • テストカバレッジ
  • コードメトリクス
  • 継続的インテグレーション
  • etc..

in English

(write it if this talk is accepted)

2013年2月にスタートしたmiyagawaさんによる Podcast 「 Rebuild 」はWebエンジニアを中心に人気メディアとなりました。僕自身もRebuildに影響を受け「 だんごゆっけの平和な話 」「 wada.fm 」という2つのPodcastを開始し現在でも配信中です。こうしたPodcastを成り立たせるには

• 1. コンテンツとなる音の収録
• 1. 音の加工や収録データの形式を変換する作業など
• 1. 音声ファイル及びRSSフィードをWeb上で公開する（場合によっては番組サイトもつくる）

この3つが必要になってきます。本トークでは まず 、僕が配信している2つのPodcastを事例に、上記最後の配信部分に焦点を当てつつ「Podcastを支える技術」について紹介します。

さて、Rebuildが火付け役となり、WebやITエンジニア界隈では、僕を含めPodcastを聴いたり配信したりする人が増えたわけですが、技術的な側面を考えると 枯れた ものを利用しているにとどまりません。mp3ファイルをURLで参照出来る場所に置いて、アドレスを書いたRSSフィードをWebサーバ上などから配信する だけ なのです。やろうと思えば、Appleの「iTunes Store」上へPodcastの番組を登録し番組をアピールすることが出来ますが、しなくても立派なPodcast。AppleとGoogleが握るモバイルアプリプラットフォームに縛られる必要なんて全く無いのです。

この既成の「プラットフォーム」上メディアとPodcastでは、技術的にもアーキテクチャやインフラの側面としても「自分がどこまで面倒を見るか？」という意味合いで大きな乖離があります。Podcastの事例は、 MovableType を自分のサーバにインストールしていた時代のBlogにも言えることでしょう。例えば、昨今、Web技術の調べ事をしていると「 Qiita 」の記事がGoogleでヒットすることが多くなりました。dankogaiさんにBlogを通じてコードを「 勝手に添削 」された頃と比べると状況は変わってきている気がします。

本トークではこのように、Podcast話を皮切りに、こうしたエンジニアの表現手段の仕組みがどのように変わりつつあるか？歴史的変遷を振り返ります。そして、今、どのように 楽しむか？ を考えてみたいと思います。「こんなコード書いたんだけどどう？」「知見たまった！」「俺のポエムを聞け！」我々はコードを書きつつもネットを通じて誰かに伝えたいことがあることでしょう。当の自分も、Blogいや、Web日記から始まり、メルマガ、雑誌や書籍の執筆、Kindle本の発売、そしてPodcastと様々な形態で発信してきました。これらの経験を元にコンテンツの表現方法を探ります。また、絶版？になってしまいましたが「Blog Hacks」という書籍が示す通りメディア配信のシステムを 自らいじる 楽しさも存在しますね。

最後に、 エンジニアならコードそのものも表現しよう！ ってことでPerlの巨大ライブラリ置き場である CPAN や GitHub について言及します。これまたmiyagawaさんとのBlog上のやりとりで知って考えた、オーサーとユーザーがいる件、CPANのエコシステム、フリーライド問題などがテーマです。

ちなみに、個別具体的な技術的トピックやコードの出現率が低いトークとなりますが、これらエンジニアのためのWebメディアの 仕組み を事例と共に説明するので、特別「スピリチャルな」もしくは「エモい」トークには ならない と思われます！

---

トピックリスト（予定）

• マイクには2種類ある
• オーディオI/F
• Audacity、Levelator、lameで無料のポスプロ
• Media RSSという拡張
• Podcastの富豪的な配信の仕方とVPS1台だけで行なう方法
• フィードと静的サイトをつくるためのJekyll
• MovableTypeのパスワードがアレだった時代
• デブサミ2014「Webの現在過去未来」
• Web APIで巨人の肩に乗る
• Twitter API v1.0 廃止の件
• まぐまぐの仕組み
• 書籍のつくり方
• AWSをオンプレの構図にも似てる件
• ePubフォーマットとmobiフォーマット
• App::mookview
• Where are "Casual Perlers" ? - ゆーすけべー日記
• On module writers and users - bulknews.typepad.com
• Web上でのプレゼンスを発揮することの意味
• GitHubの時代
• pull-requestが来たと思ったらその人のBlogでソフトウェアが紹介された件
• The best of what's new on CPAN 2014
• RESTfulとURI
• facebook.comは万人に同じリソースを表しているといえるか？
• はてなブックマークの功罪、主に功

YAPC::Asia Tokyo 2015の花形、Lightning Talk です！

This will be a talk on Docker for polyglots (users of multiple programming languages) and how it can be useful.

In this day and age we frequently find ourselves programming in two, three, or more programming languages, and the dependencies or environments in which we must run them continue to get more and more fiendishly complex. For users such as us who prefer to be fluent in many languages, how can we manage this desire to use the correct tool for the correct job, and do so quickly?

This talk will talk about how Docker, a Linux container technology and orchestration platform, can help to achieve these goals, and free developers up to focus on coding instead of configuring environments or tedious tasks like managing different versions frameworks.

概要

Node.js は去年の12月にメインのコミッタの数名が抜けて io.js という fork が生まれました。彼らが何故 fork をしなければならなかったのかに関しては色んな憶測や推測があります。

Node.js 日本ユーザーグループ代表として、Node.jsをこれまでずっと追ってきた私(@yosuke_furukawa) と io.jsの技術委員会メンバーである大津さん( @jovi0608 ) からこれまでのNode.jsの歴史的な話と技術的な話、そして今後の予測を対談という形でお伝えしたいと思っています。

また、この Node.js の一連の fork 騒動は OSS というプロジェクトの特性と企業のバックアップを受けている OSS がどうあるべきかを知る一つの教材だと思います。

このトークを通じて「Node.js/io.jsに何が起きていて、これからどうなっていくのか」という事をお伝えしたいと思っています。

トピック

• Node.jsの歴史 (Node.jsとは、Node.jsが生まれた背景) (10min)
• Node/io.jsの機能的な違いと性能的な違い (10min)
• Node/io.jsのロードマップ (10min)
• 今後のNodeについて古川、大津でオープンディスカッション (30min)

発表者について

古川 陽介

• @yosuke_furukawa
• 日本 Node.js ユーザーグループ代表
• io.js collaborator 兼 evangelist

大津繁樹

• @jovi0608
• io.js 技術委員会メンバー
• http2標準化作業にも参画

For English guests:

Abstact

Some Node.js core member moved from joyent/node and io.js was born on December 2014. Developers who doesn't know Node in detail assume and imagine the reason why they leave joyent/node. But I guess there is a few developers who knows the reason properly...

So we will talk about Node.js history and technical feature, io.js comparison, the future of Node.js by open discussion with Shigeki Ohtsu(@jovi0608).

We would like to introduce "What happens Node and io.js and The prediction of the future of Node" to YAPC listeners.

Topics

• Node.js history (What is node.js and why node.js born) (10min)
• Node/io.js technical features and comparison (10min)
• Node/io.js roadmap (10min)
• Discussion about the future of Node (30min)

Biography

Yosuke Furukawa

• @yosuke_furukawa
• Japan Node.js User Group Leader
• io.js collaborator / evangelist

Shigeki Ohtsu

• @jovi0608
• io.js Technical Committee member
• working on http2 standard

※ 運営の方々へ: 可能であれば、 大津さん(@jovi0608) と対談形式で話をしたいと思っています。 ※ もしも不可能であれば、トークを分けるので連絡をください。

2014年9月に正式リリースした、はてなのサーバー管理・監視サービスであるMackerelでは、サーバーサイド言語にScala、そして、ユーザーがホストにインストールする監視agentやそのpluginはGoで書かれています。

このようにプロジェクトにおけるメインの開発言語はScalaとGoですが、部分的にはPerlやRubyも使われてもいます。もちろんクライアントサイドでJavaScriptも使っていますし、TypeScriptを使っている部分もあります。このようにMackerelはひとつのプロジェクトでありながら多様な言語が使われているというユニークな特徴を持っています。

これは面白がってたくさんの言語を使っているわけではなく、それぞれ必然性を持ってそれぞれの言語を選択しています。それらの言語がどのように適材適所に使われているか実例を交えながら紹介したいと思います。

例えば、Mackerelの中でPerlはどこで使われているのでしょうか？それは自動化スクリプトであったり、ツールであったり、テストスクリプトだったりします。別言語のプロジェクトであっても、リポジトリにおいておくちょっとしたツールを書くのにPerlは非常に適しています。特に優れた特徴として、スクリプト自体に対してテストを書きやすいことが挙げられます。

そして、生粋のPerl Mongerである私自身がMackerelに携わってScalaやGoを書く中で、Perlでの知見がどのように生きたのか、また、ScalaやGoで得られた知見をどのようにPerlにフィードバックしているか、いこうと考えているか、そしてエンジニアの私自身にどのような変化があったのかについてお話ししたいと思っています。

実は、ScalaとGoは両方Perl Mongerにとって馴染みやすい言語だと思います。

ちょっと待って下さい。ScalaとGoは共にPerlと異なる静的型付け言語であり、それでいて正反対の性質を持った言語です。それなのになぜ、Perl Mongerにとってそれらの言語が馴染みやすいのでしょうか。それについてはトークの中でお話したいと思います。

また、Mackerelはmackerel-agentというユーザーがホストにインストールする監視エージェントやその他のツールがOSSとして公開されているという面白い特徴を持っています。それらは何故OSSなのでしょうか？

そして、これらをOSSとして運用していく中で、私自身がOSSプログラマーとしてCPANに多くのコードをリリースしてきた経験が役に立つ機会もありました。それらについてもお話できればと思います。

全体として以下の様なトピックを取り上げようと考えていますが、他にも聞きたい話などがあれば盛り込みたいと思いますので是非お知らせください。

• Mackerelのプロジェクト構成
• MackerelにおけるScala/Go/Perl/Ruby/TypeScript
  • それぞれの言語をどのように適材適所で使っているのか
• Scalaにおけるリスト処理や関数の扱い、それらのPerlとの類似点
• Goの型の考え方や設計上の割り切りや節度、それらのPerlとの類似点
• Perl開発の知見がどのようにScalaやGoで役立ったか
• GoやScalaの文化でPerlに持ってくると良さそうなもの
• 小回りの効く自動化推進言語としてのPerl
  • 自動化の仕組みをちゃんとテストする
  • 自動化をブラックボックスにせず、負債化しない仕組み
• mackerel-agentをOSSにしている理由
  • プロジェクトコードをOSSにする上での運営ポリシー
  • Perlで書かれたagentリリースの自動化・可視化の仕組みについて

Google Cloud Platform (GCP)の最大の特徴は、ハードウェアやLSIのレベルから自社で設計・開発されたGoogleの謎のインフラテクノロジーから得られる圧倒的なパワーを社外のお客さまに提供している点です。例えばMapReduceに代わる新しい世代の大規模分散処理基盤であるCloud Dataflowでは、社内の広告インフラ用に開発された巨大ストリーム処理フレームワークの技術とエンジニアを投入し、Exactly Onceレベルの到達保証とリアルタイムオンメモリ処理を実現しています。さらに今年後半は、Googleの謎技術から生まれた謎サービスが続々とGCPに登場予定。YAPC Asiaの開催時点でお話できるぎりぎりの線を攻めたいと思います。

ISUCONというWebアプリケーションのパフォーマンス改善コンテストをご存知でしょうか？

ISUCONとは、「お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル」です。3人でチームを組んで参加し、レギュレーションの中であれば自由にアプリケーションに手を加え、出題者が用意したベンチマークでもっとも優れたスコアをたたき出したチームが優勝となります。2011年から4回開催されています。 発表者は2011年、2012年の2回は出題側として問題作成と調整、アプリケーションやベンチマーカーの作成に関わり、2013年、2014年は参加者として2年連続優勝をしています。そして、今年2015年も開催することが発表され、多くの注目を集めています。私も参加する予定です。

このトークではISUCONの課題作成や、問題に取り組んだ経験、また、普段からオペレーションエンジニアとして高トラフィックなWebアプリケーションの運用に携わって来ているなかで得たノウハウを紹介します。単にISUCONでよいスコアを出すということにとどまらず、業務で関わるWebアプリケーションを如何にパフォーマンスをあげ、効率よく動作させる方法や、なぜパフォーマンスの向上が重要なのかについて発表をします。

発表内容(予定)

• ISUCONとは
• 私とISUCON
• ISUCONから生まれた技術
• Webアプリケーションのパフォーマンス
• Webアプリケーションの構成要素
• Webサーバの特徴と動作
• RDBMS/NoSQL
• SQLチューニング
• パフォーマンスプロファイリング
• ISUCONで高スコアを出す方法

このトークを聞いて、ぜひISUCONにチャレンジしてください！

Perl 5.22 is here, and it's got new stuff. What kind of new stuff? Cool new stuff. You can read the fifty page perl5220delta document, or you can come listen to the Perl 5 project manager summarize the stuff you actually care about. We'll also review some of the major changes from 5.20 and just a little bit about what may be coming next year.

SpaceAppsとは

International Space Apps Challenge(SpaceApps)は、NASAなどの宇宙データを使って宇宙のアプリをつくるハッカソンです。今年は133都市にて同時開催され、参加者総数は13699人にのぼります。これは、調べた限りではGlobal Game Jamに続いて世界で2番目に大きな規模のハッカソンです。SpaceAppsは、2012年よりはじまり今年で4回を迎えます。東京を会場としたSpaceApps Tokyoも2012年より毎年開催し、スペースデブリ(宇宙ゴミ)をコレクションしたりAR表示できるアプリ宇宙のカケラ －Dear My Space Debris－ や、火星の人面岩を機械学習で探すMarsface Project (マー)など様々なアプリケーションが誕生しました。私は、2013年からSpaceApps Tokyoの運営に携わり、2014年と2015年では事務局長を務めました。

トーク内容

昨今はハッカソンブームと言われるほどいたるところでハッカソンが開催されています。イベントを運営するにあたり、@941さんの エンジニア1000人が参加した YAPC::Asia 2013 で運営事務局長として行った全てのことや、@lestrratさんのYAPC運営とビジネスといったブログ記事が非常に参考になりました。そこで私も、これまでのSpaceApps Tokyo運営で蓄積した、ハッカソン運営に必要な

• 会場探し
• 懇親会準備
• スポンサー集め
• 広報
• 無断欠席対策
• アイデアソンのファシリテーション
• チームビルディングの方法
• イベント終了後の継続したコミュニティづくり

などのノウハウをお話ししたいと思います。その他、他国の開催都市とミーティングを行ったり、昼夜がほぼ真逆のBostonとのコラボレーションチームを形成するなど、SpaceApps特有の大変さについてもお話しします。

これからハッカソンを開催したい人、イベント運営のノウハウを知りたい人、ボランタリーな組織運営に苦労している人などにとって有用となるセッションにしたいと思います。

Dockerがリリースされてからだいぶ時が経ち、
Dockerコンテナを管理するツールもサードパーティ含め星の数ほどリリースされてきました。

しかしDocker自身もその状況を黙ってはいませんでした。
現在、Dockerエコシステムを提供する機能として
公式に以下のようなサービスがリリースされています。

• Docker Machine
• Docker Compse
• Docker Swarm

本セッションではこれらのツールに関する、
以下の様なトピックについてお話する予定です。

• これらのツールは一体なんなのか？
• どういった目的でリリースされたのか？
• どのような機能を提供しているのか？
• 今後のロードマップについて
• 実際にどのようなシーンで利用できるのか？利用しているのか？
  • ※いくつかのユースケースを提示する予定
• ３兄弟が力を合わせた時、真の力が解き放たれる…（かも？

スマホ、とは手の平で動くコンピュータです。

常に持ち歩いているこの端末で自分の書いたプログラムを動かせたら面白いと思いませんか？

特にすでにサーバサイドプログラムができる皆さんは、スマホ側さえできるようになったら、 ほぼどんなアプリでも一人で作れてしまうでしょう。

このセッションではそんなことを思っているPerlプログラマーを対象として、 iOSアプリ開発の方法をひと通り説明します。(iOSだけです。ごめんなさい)

私自身も筋金入りのPerlプログラマだと思いますが、iPhoneが日本で発売されてすぐに、iOSアプリ開発に手を出しています。 その経験の中で、PerlとObjective-C(Swiftも)の共通点がいくつもあり、UIに関係ないモデル層などは、ほぼPerlの時とおなじように書ける、ということに気付きました。

というわけでまず、Perlとの比較という感じで始めたいと思ってますので、対象をPerlプログラマとしていますが、全体的には他の言語の方にも参考になると思います。

対象

• iOSアプリかいてみたいなーと思っているサーバサイド(特にPerl)エンジニア
• iOS周りに関する知識は不問
• サーバサイドプログラムについてはメモリ周りを意識してコードを書けるくらいの前提知識はあると良い。(メモリの開放タイミング、循環参照、等)

目次

• Perl to Swift のマイグレーションガイド
• UIKitのざっくり説明 (覚えるしかない)
• アプリ開発チュートリアル

概要

Webシステムを動かすサーバは、細胞と同じように、生まれて死んでいく。
そのようにシステム全体を活性化させることによって、常に綺麗なサーバを保つことができる。

それは式年遷宮という日本古来のシステムの中にある、穢れと禊という概念にも通じる。
この概念は去年のYAPCで話した通りだ。

その思想を持って構築を試みた2015年、

構築前「完全無人自動化で運用しようや」

...

構築後「冗長構成って本当に必要なんですか？」

---

トーク内容

この構築の最中に彼が見たものとは？
式年遷宮インフラストラクチャ3部作の第2部にあたる今作は
どのような思想を持ってとりかかり、どのように失敗したのか。
実体験を元にしたお話をできればと思います。

キーワード

• Consulを使おう
• consul-templateとdnsmasqとhostsファイルと順番と
• MySQL(GTID)という名の夢
• mysqlfailoverという名の現実
• Redis Sentinel、そして
• セキュリティ！セキュリティ！セキュリティ！
• 稼働率よりも不整合を止めろ！
• リアルISUCON(データセンターの向こう側へ祈りを)

以上、よろしくお願いします。

追記 (2015/08/15)

大体スライドまとまりました。

挑戦したこと
冗長化について
Redis + Redis Sentinel
Consul
MySQL + mysqlfailover
consul-template
hostsの順番
クラウドという名の混乱
対応
冗長化の終わり、そして

という内容になりそうです。色々なソフトウェアを利用し、冗長化にチャレンジしたが
アマチュアのような見積り、構成の甘さや、インフラではなくプロジェクト全体の問題などを含め
改めて実体験として経験したこと、改めて大切だと理解したことなどをお話しできればと考えています。

Webサービスを運用しているけど、インフラ担当なんていない、
サーバ管理はよーわからんが新しいことにチャレンジしてみたい！けれど失敗はしたくない、
など、インターネットにいるようなすごい人達ではなくてもチャレンジすることができるが
こういう失敗はしないようにね、という反面教師のお話を聞きに来て頂ければと思います。

当日はどうぞよろしくお願いいたします。

昨今、ビッグデータとまではいかないまでも、 大規模データを扱うシステムが増えているように思えます。

そうはいってもリソースは限られていて、、

CPUが2コアしかない・・・ メモリが8Gしかない・・・

データは5億件もあるorz

などなど、、

限られたリソースの中で、 求められる性能を出すための工夫や、 リソースが足りないことの正当性を訴えた話とか、

いろいろ意見交換できればと思います。

主にMySQL とちょっとPerlの話です。

アジェンダ(仮)

• システムの概要
• 負荷テスト
• /tmp の枯渇
• 正規化してサイズを減らした
• 負荷テストのときよりも圧倒的に遅い。。。
• indexの再構築 とupdate
• 主キーとinsert の関係
• アプリケーション側のロジックの変更
• innodb_buffer_pool_size とinsert
• 今後の課題
  
  • 増分バックアップの方法とか
  • メモリ増築しないと無理な話とか
    　

トーク概要

Microsoft Azure は Microsoft が長く育ててきたテクノロジーを総動員して提供されるパブリッククラウドです。
猛烈な機能追加が喧伝されがちなパブリッククラウド界隈ですが、その基盤がどのようになっているのかを知る機会は少ないのではないでしょうか。

本セッションでは、普段見聞きすることがあまりない "クラウドの向こう側のテクノロジ" こと Microsoft Azure のテクノロジについてお話します。
また、それだけではなく、クラウドの向こう側のテクノロジが皆様の手元に届く時代、ハイブリッドクラウドの世界についても許される限り語りつくしたいと考えています。

Microsoft Azure とその未来とは言っても、Microsoft の技術を知っていないとダメということは全くありません。
Azureを知っている方も、Azureについてこれから知りたい方も、インフラちょっとは興味あるんだけどそんなに詳しくないよ、という方にも興味を持っていただけるような内容にいたしますので、安心してお越しください。

取り上げるトピック

• Microsoft Azureって何？どういう特色があるの？機能/サービスは？
  • 僕も知らなかったAzureについてのアレコレ
• Azureのイケてる "as a Service" たち
  • リアルタイムストリーム処理基盤 "Event Hubs/Stream Analytics"
  • リアルタイムダッシュボード "PowerBI Dashboard"
• Azureの "as a Service" を支える技術
  • 手に入るクラウド "Azure Stack"
  • PaaS基盤 "Azure Service Fabric", "Azure Resource Manager"
  • Azureの物理的なサーバ "Open Compute Server"
• インフラエンジニアがクラウドに支配されるのではなく、クラウドを支配する未来

キーワード

• Azure, DataCenter, Network, SDN, SaaS/PaaS, Azure Stack, Cloud Platform System, Azure Service Fablic, Azure Resource Manager, Open Compute

スケジュール：

• 12:20 開場 + 弁当配布
• 12:30トーク開始
• 12:50 終了

株式会社Fusic様 にスポンサードしていただいているランチセッションです。

豪華お弁当を先着80名 まで無料で配布いたしますので、会場のイベントホール内で味わって下さい！その際、Fusic様より以下のプレゼンテーションを発表していただきます。

Fusicは自社サービス開発・受託開発を行っている、福岡の企業です。 開発実績についてはHPなどで社外にも発信しておりますが、一方で、社内向けの システムが相当数稼働しています。これまでも、多くの社内システムが作られ、リニューアルされ、消えていきました。本セッションでは、これを振り返るとともに、いち企業の取り組みであったり、 悪戦苦闘であったりについて、ご紹介できればと思います。

• 取り巻く社内環境について
• 社内システムの歴史と変遷
• 残る社内サービスと消える社内サービスの話
• 社内サービスを支えるインフラ環境の話
• コミュニケーションツールについて
• その他、雑多な話

ランチを食べながら聞ける程度の内容でお送りいたします。昼下がりの演芸番組を見るくらいの心構えで大丈夫です。Perl成分は薄いです。あらかじめご容赦ください。

スケジュール：

• 12:20 開場、弁当配布
• 12:30 トーク開始
• 12:50 終了

モバイルファクトリーで作られている 駅メモ などの位置情報ゲームを元に、 位置情報関連技術のご紹介をできればと思います

• 弊社での位置情報の利用例
• 位置情報関連周辺技術
  • Location API
  • Geometry type, GeoHash, GeoHex
• GeoHex (ver3) について

At GitHub, we've refactored a lot of projects in the last couple of years, some big, some small. In this talk, we'll cover some techniques for different kinds of refactorings and some nifty Ruby libraries we've made to help us out. Then we'll spend a bit of time pondering why language designers aren't helping us out with this everyday task.

nginxは近年急速にユーザ数を伸ばしているOSSのHTTPサーバです。2015年3月のNetCraftの調査結果によると現在nginxのシェアは全世界のWebサイトの十数パーセントを占めるまでになっています。

nginxがこれだけ急速な勢いでユーザ数を伸ばしている要因の一つとしてnginxのソースコードに直接手を入れることなくモジュールを開発するための仕組みが整っていることが挙げられます。HTTPサーバに求められる要件は非常に多岐に渡るため、コア開発者だけでなくユーザ開発者が自分のニーズを満たすためにHTTPサーバを拡張できるのは重要なポイントです。そして実際に多くの開発者の手によって様々な用途のモジュールが開発され、nginxの強固なエコシステムが形成されてきました。

本トークでは拙作のngx_small_lightやngx_dynamic_upstreamといったnginxモジュールの開発やngx_lua、ngx_mrubyといったnginxを軽量スクリプト言語で拡張するためのプロジェクトへのコントリビュート、過去に携わったngx_lua(とGo)による大規模な広告配信システムの開発・運用といった筆者のこれまでの数々の経験を元にnginxモジュールの実践的な開発ノウハウについて解説します。

具体的な内容は次のようになる予定です。

• nginxモジュールの開発に必要な基礎知識
• nginxモジュール開発の基本
• nginx APIプログラミング
• 既存のnginxモジュール(ngx_small_light, ngx_dynamic_upstream, ngx_lua, etc...)から見るnginxモジュール開発の実際
• Test::Nginx(CPANモジュール)を利用したnginxモジュールのテスト
• ngx_luaによるnginxモジュールの開発
• High Peformance ngx_lua

LXC (Linux Container) is getting a lot of attention these days. From the fundamental principles of Unix to some modern Linux features, we will examine how containers work and how to build your own using Perl.

• This talk will be provided by Marty Pauley (@maokt) and Miki Horiuchi (@nukamu).

Contents

• Linux / Unix fundamentals
• What is a container?
• Mount namespace
• User namespace

Unixの基本理念からLinuxの現代の機能までを踏まえ、最近話題のコンテナ技術がどう実現されているのか、また独自のコンテナをスクラッチからどのようにPerlでビルドできるのか、分析/解説します。Dockerの登場により注目を浴びつつあるLXCの技術的詳細を知りたいという方におすすめです。

トーク内容

• Linux / Unix 前提知識
• コンテナとは何か
• マウント名前空間

• ユーザ名前空間

• このトークはポーリーマーティ(@maokt)と堀内美希(@nukamu)の2名により行われます

• スライドは日本語も交える予定です

データ分析の話はそこかしこで行われてますが，それを俯瞰する話はあまりないようなので，ここらで一つ色々とまとめて喋りたいと思います．また，Treasure Dataで得た経験をもとに，機能だけでなくデータ分析基盤でよく要求される要素についても，いくつかの視点を交えて言及したいと思います． 話したいトピックリスト．

• データ分析の需要
• データ分析の流れ
• データ分析基盤に使われるソフトウェア / サービス
  • オンプレミス: Hadoop, Spark, Presto, Impala, etc
  • クラウド: Treasure Data, BigQuery, Redshift, EMR, etc
  • データ収集/同期: Fluentd, Embulk, Sqoop, etc
  • ストリーム処理系: Storm, Norikra, Dataflow, etc
  • キュー: Kafka, Amazon Kinesis, etc
  • データパイプライン/ワークフロー: Luigi, Oozie, Airflow, etc
  • 機械学習: Hivemall, Spark MLlib, etc
  • 可視化: Tableau, Metric Insights, Chartio, etc
• データ分析基盤をどう構築するか
• データ分析基盤の今後

各ソフトウェアは実装とかまで深く掘り下げず，概要や使い所・比較が中心になります．ただ，Hadoopなどは未だ誤解があったりするので，必要なソフトウェアに関しては，いくつかアドヴァンスドなトピックを入れる予定です．

ユーザーに Web サービスを提供し続けるためにはコード、インフラストラクチャー、開発プロセス、セキュリティ、データ分析などあらゆる要素を継続的にメンテナンスし続ける必要があります。

近年では Web アプリケーションが生活のあらゆる所で利用されるようになりました。その結果としてサービスの提供者である私達には先に述べたような問題の中でも OS、Web フレームワーク、言語などのセキュリティの問題の評価、対応のリードタイム短縮がより一層求められています。

私が勤務する GMO ペパボでは、上記の問題を解決するために最速で 3 分でサービスを無停止のまま大規模に運用しているサーバーを入れ替えるという Blue-Green デプロイメントの仕組みを構築しました。この仕組により、OSのディストリビュータによる脆弱性対策がなされ次第、即座にユーザーに安全な環境を提供することが可能となりました。

本発表では構築した仕組みの中から以下のトピックについて紹介します。

• VPSのように永続化を前提とした使い方をしているサーバーを Immutable にする時の考え方と事例
• Rails アプリケーションを動かすサーバーを高速にプロビジョニングする方法
• Blue-Green デプロイメントに必要とされる技術要素群と活用事例
• Immutable なインフラの監視方法

本発表では一定規模のサービスをターゲットにしますが、小規模(数台)のサービスが成長し、大規模化が必要となった際の知見についても紹介する予定です。

Parallelism and concurrency are different, though often confused. Asynchrony adds yet another concept into the mix. And there are dozens of different approaches to working with these concepts. How do we identify what kind of problem we're dealing with, and pick an approach to solving it?

In this session, I'll look at a range of different problems - some parallel, some concurrent - and show the approaches that may be taken to solve them. And, since I've been working on the Perl 6 parallelism and concurrency features, I'll show how these solutions look in Perl 6.

メリークリスマス！

私たちはチャリティーサンタというNPOのボランティアITスタッフです。

全国で1500人のボランティアで集まったサンタクロースたちが子どもらにプレゼントを届けに行くのですが、そのサンタたちの活動を支えるIT技術についてお話したいと思います。

メンバーは普段はIT系企業に勤め週末に集まってWeb・ツール等の開発を行ったり、全国の各支部のサンタ部長(!?)らとやりとりしたり、学生や主婦を含む多様で地方分散したサンタ＆トナカイたちに使ってもらえて活動を支援する仕組みづくりを行ったりしています。

そんなサンタたちがNPO、ボランティアという枠組みの中どのようにして技術を以って課題に立ち向かったかをお伝えします。

• 共用レンタルサーバでの運営からのスタート 〜 FTPでの更新からGithubバージョン管理へどのようにして転換していったか
• 仕事でのエンジニアリングとボランティアでのエンジニアリング
• スキルセットの異なるメンバーのチームビルディング
• NPOならでは、基本コスト0でやろうとすることできることできないこと 利用したツール断念したサービス
• 未経験者もまざった中でのGithubリポジトリ運用とデプロイ手法
• どこまで技術にチャレンジしてどこを妥協するか
• いにしえの技術、いにしえのコードのリファクタリング
• NPOならではのWeb決済導入選定
• 未来のサンタはこうなっている！サンタ&IT アプリのビジョン

(注: 企業における開発に活かせそうな話はないかも...)

YAPCで高度で先端な技術の話に聞き疲れしたら箸休めとしてご活用下さい！

チャリティーサンタ

ITサンタメンバー M_Ishikawa

TL;DR

• 慣れてる技術(Perl)を使いつつ、今の現場でどうアウトプットしていくか
• AdServerを支えるPerlプロダクト

の紹介をする予定です

内容

VOYAGE GROUPは様々なサービスを運営しており、それを支える技術も多種多様です。 その一つであり、私が所属するadingoが提供する事業でも様々な技術が用いられております。

このトークでは、現場ごとに異なる環境であっても、ある一つの手段(Perl)を使いつつアウトプットしてきた内容をご紹介します。

• 今もPerlの現場でPerlを使っている人
• 昔はPerlの現場だったけど、、な人
• これからPerlの現場に行く予定の人！？

上記どのパターンの方も対象になりますし、「Perl関係ない」人にもヒントになる内容もあるかと思います。

最新のイケてるものの活用事例や、革新的なプロダクトを作った！みたいな派手な内容ではありません。 どちらかというと、作業的には地味なもので簡単な事例紹介をできればと思います。

また後半にはadingoが提供するプロダクトでのPerlの活用事例も紹介できればと考えています。

目次

• PHPの現場で書いたものをPerlにバックポートした話
• Rubyの現場で暫定対応をPerlでやった話
• Perlの現場でやってた事をphpの現場でもやった話
• AdServerを支えるPerlプロダクトの紹介
• and more...

※言語間の優位差異については言及しません。

最後のYAPC::Asia、是非ともトークしたいです！

Posture for Engineers

Who cares about posture?

We do! (Or we should!) Those of us who work on computers daily may or may not realize the potential detriment to our health that is caused by sitting in the same position for long periods of time.

But standing desks!

Well, that is a good start, but our posture can still be affected negatively if we are standing all day (or if we do not have good standing posture).

What do we do about it?

Nerd out about posture! We can learn about the muscles that are weakened and those that are over-used during our everyday jobs, and what each of those muscles do for us when they are working properly. No need to learn all the names, but you can if you want. Anatomy is pretty cool. The most important thing is to understand what our bodies are capable of.

So what will this talk teach me?

At the end of this workshop you will: * Feel more confident about moving your body during the day. * Learn some yoga poses if you did not know them already. * Know at least a few exercises to do regularly that will help improve posture. * Know what each position will do for you. * Have tried something fun ^_^ * Be smiling!

Abstract

Lattice is an open source project for running containerized workloads on a cluster.

Lattice includes built-in http load-balancing, a cluster scheduler, log aggregation with log streaming and health management.

Lattice includes support for Linux Containers expressed either as Docker Images or by composing applications as binary code on top of a root file system. Lattice's container pluggability will enable other backends such as Windows or Rocket in the future.

Topic

• Born from Cloudfoundry
• Easy deploy
• Easy to use
• Live demo
• XRAY "Peer into the Lattice"

トーク概要

YAPC::Asia Tokyo は今年で10年目を迎えます。YAPC::Asia Tokyo運営に関わってきた方達をゲストとして、当時を振り返りながらただただ楽しそうにトークをするコーナーです。YAPCのスタッフ、スポンサーそして参加者の方たちへ感謝を表しつつ、この10年間を振り返ります。Perlコミュニティの良さ、楽しさが少しでも多くの人に伝わると良いなと思います。

• このトークセッションはオモロキのスポンサードで行われる特別企画です。
• boketeはPerlで動いています。

登壇ゲスト予定

2006年〜2015年のYAPC::Asia Tokyo実行委員長

ゲスト

• @miyagawa
• @takesako
• @lestrrat
• @941

進行

• @yusukebe
• @kamadango

トーク内容

• 10年間のYAPC::Asia Tokyoを数字ベースで振り返る
• 10年間のYAPC::Asia Tokyoをネタベースで振り返る
• 質疑応答

参考リンク

Perlあるある

株式会社カヤックでは今年の 1 ~ 3 月にかけて、
運用しているソーシャルゲーム 3 タイトルをオンプレミス環境から AWS に移行しました。
Perl で実装されているそれぞれのタイトルを事例に、
AWS 移行の知見を共有し、アーキテクチャについてお話ししたいと思います。
事例はソーシャルゲームですが、他の分野にも応用ができるお話しになる予定です。
全てのゲームで consul を活用していますので、consul の導入事例もお話しできると思います。

本発表では、以下のトピックについてお話しします。

• AWS 移行によるメリット・デメリット
  • 機能面、金額面
• オンプレミス環境の MySQLから RDS へ移行する際の注意点
  • MySQL のデータ移行時間を200分から95分に短縮した話し
• consul の DNS と Health Check 機能の活用方法
• consul と stretcher による AWS 的な Deploy
• Kyoto Tycoon から yrmcds への移行
  • yrmcds の監視について
  • consul lock を活用した自動 failover 機能について
  • consul lock の使用を中止するまでの経緯
• Zabbix での RDS for MySQL と ElastiCache for Redis の監視
  • マクロを使用して設定を楽に行う方法
• RDS for MySQL と ElastiCache for Redis で正常に Failover させる方法
  • DBIx::Class と Redis::Fast の場合
• Chef の運用について
• Jenkins EC2 Plugin による Spot Instance を活用したテスト
  • カーネルパラメータをチューニングしてテストを高速化に挑戦
• Mozilla::CA が返す証明書でエラーが発生するようになったので対処した話し
• etc

Brad Fitzpatrick takes a slow, buggy Go program and shows how to use Go's wonderful tooling to make it fast and correct. Learn how to debug and profile Go programs. Topics will include Go's race detector, CPU, memory, and block profiling, minimizing garbage, various compiler flags, in-memory representation of core Go data structures, etc.

50ms or die.

私が所属する FreakOut では国内 RTB 市場が勃興してから現在に至るまでの５年間弱、 Perl をメイン言語として過ごしています。

近年の RTB 市場では平行処理に長けた言語や高速な低レイヤー言語、 FPGA 等の計算力に特化したデバイスを直接扱う手法がトレンドとなっていますが、 それでも弊社のメイン言語はトレンドに流れる事なく Perl であり、市場の厳しい技術要件に立ち向かい続けています。

本セッションではところどころ歴史をひも解きながらも、今なお RTB の最前線をどうやって Perl で闘っているのか、具体的な手法や方法論をお話しできればと考えています。

• RTB の構成要素についての簡単な説明
• DSP として SSP からの入札要求にどう答えているか
  • 入札最適化について
  • 限られた処理時間、節約と活用
  • データリソースの扱い方
• ビッグデータとどう付き合うか
• その他

※ 今春まで弊社に所属していた @myfinder さんの過去の Talk と比較して、包括的でなく、より入札の細部に因った内容となる予定です。

要旨

昨年に続き、CONBU(COnference Network BUilder) は YAPC::Asia の会場ネットワークを提供しています。1 [※１] 今年の目標として「安定したネットワークを、いかに早く、そして面白く提供できるか？」を掲げており、これを達成するための取り組みについて紹介いたします。

発表内容

本トークでは、イベントやカンファレンスでのネットワーク提供に関するノウハウの紹介をします。 また、会場ネットワークの通信流量やWiFi接続数を取得できる独自APIに関する取り組み、及び活用例を紹介します。

CONBUのネットワーク提供方法

-いかにネットワークを早く上手くつくるか

-CONBU Cloud（コンクラ）に関する紹介

APIについて

-CONBU API への取り組み

-独自API を作成するモチベーション

-CONBU API の仕様

-CONBU API の活用例

発表者

東松 裕道@ CONBU / DMM.com Labo

高野 光弘@ CONBU

Talk

オープンソースエンジニアには馴染みのあまりない Windows ですが、Build 2015、Microsoft Ignite では、オープンソースのデペロッパーやインフラエンジニアに向けて、多くの発表がありました。

これまでは、Windows OS は企業内で使用されるイメージがありましたが、次期 Windows Server では Docker が統合されたり、クラウドを構築できる Azure Stack も発表されたり等、パブリックなクラウドインフラストラクチャーとしても、採用できるポテンシャルを十分に持っています。

また、クラウド分野においては、AWS がシェアでは一歩先を行っていますが、Azure の成長率は AWS の倍近い 96% と、追いつくのも時間の問題となってきています。

このトークでは、これからの Windows に期待しているオープンソースエンジニア向けに、Windows OS の基本から、Unix系OS との違いの解説をします。また、Azure の解説なども盛り込みたいと思います。

以下、予定している内容です。

• Windows OS のエディションやバージョン、アーキテクチャ等の概要
• Windows OS と Unix系OS の違い(サービス・デーモン、ファイルシステム、ネットワーク、ログ、クラスタ、開発環境、etc...)
• Windows Updateの概要
• 次期 Windows Server の新機能
• Azure の解説

※Windows で Perl も動かしてみます！

Abstract

Web は常に様々な変化/進化が起こっていますが、なかでも非常に大きな変化として HTTP/2 の登場があると考えます。

HTTP/2 のファーストドラフトから RFC7540 が出るまでの 2 年半、 そこでは、これからの Web がどうあるべきかという、数多くの議論がかわされていました。

HTTP/2 はなぜ更新され、それがどんな変化をもたらすのかを知ることは

今 Web で「今何がおこっているのか」 そして Web は「これからどこに向かって行くのか」を

考える一つの視点になり得ると思います。

HTTP/2 を追い続けた 2 年半をふりかえり、HTTP2 とその関連仕様、 そしてそれを取り巻く議論をもとに、これからの Web について考えてみたいと思います。

Topics

• HTTP/1.1 から HTTP/2
• プロトコルの現状
• 本当に移行する必要があるのか？
• Server Push
• TLS と HTTP/2
• 研究課題
• そして QUIC へ
• etc

(English follows Japanese)

「辛いことをやめよう！」

2年前、ITインフラを支えるMSPであるハートビーツが、業務改善を始めるときに決めたキーワードでした。その頃は、ちょうどAWSの活用をはじめとしたITインフラを取り巻く環境が激変している頃でした。私たちも例に漏れず、今までのやり方の延長ではなく、変化を求められる状況にあったのです。

本セッションでは、私が中心となって2年間取り組んだハートビーツの業務改善、特にMSPならではのInfrastructure as Codeの取り組みについて、主に次の3点についてお話しします。

• 1: 辛いことって結構聞きやすい
• 2: 最も必要としている人から巻き込もう
• 3: 成果の評価と今後へのつなげ方

1は、辛いことを通じて解決したい問題を、「辛さ」と「実現性」の2軸を使ってあぶり出す流れをお話しします。お固い業務分析をしなくても、わかることは多いのです。

2は、パイロットプロジェクトの選定の勘所と、そのチームの人とうまく仲良くなりつつ業務改善活動に巻き込むプロセスをお話しします。ハートビーツは管理部以外は全員エンジニアなのですが、そのメンバー全員を巻き込んで行ったやり方を、失敗談も交えながら紹介します。

3は、やる以上は定量的な評価は欠かせません。がんばった、だけでは組織の利益拡大にはつながらないからです。その評価方法と、更なる改善点の探り方についてお話しします。

対象者

こんな方に聞いて頂けたら嬉しいです。

• 日々の業務を改善したいソフトウェアエンジニア
• プロジェクトの運営を改善したいプロジェクトマネージャ
• 部署横断的に業務を改善したいとお考えの方

やり方は、ITインフラに限らず多くの開発会社にも応用して頂ける内容だと考えています。また、実際に取り組まれている方が「ほかの人はどうやっているのだろう？」と関心を抱いて頂くことも歓迎します。

Abstract in English

"Take away the pain !"

This is the keyword we defined to IT infrastructure operations two years ago.

I work for MSP company HEARTBEATS (MSP: IT Infrastructure Managed Service Provider Company). At that time, IT infrastructure business was reached a turning point when IaaS(Infrastructure as a Service) was main currents of server system. Then, we need to change our business strategy from the traditional approach.

This session, I'll talk about three themes as the person in charge of IT infrastructure operations, specially "Infrastructure as Code" that is only possible by MSP.

• 1: People WANT to talk about their problems
• 2: Involve closest person
• 3: Evaluating performance and beyond

First, I did two dimensional analysis: "Pain" and "Feasibility Solution". There is no need of complex analysis !

Second, At HEARTBEATS, employee are all engineer except for general affairs. I'll talk about conclusive factor of choice of pilot project, and a way of corporate pilot project member each other, that include some failed.

Third, we need to analyze of improvement operation. Because, wrong approach doesn't lead profit increase.

YAPC::Asia Tokyo の花形、Lightning Talkです！

Wrap up! 🎉