(English follows Japanese) こんにちは、牧です！ 例年トーク募集を開始すると、主催としては「はたして本当に応募してくれる人がいるのかな？」不安でたまらない日々を過ごすことになるのですが... なんと今年は招待ゲスト等を除いても応募総数180前後のトーク応募がありました！すごい！倍率4倍強です！すごい！ とは言え、その180個ほどの中から40個ほどに絞るということをしなくてはならなかったので、今回のトーク審査は私がこれまで関わってきたYAPCの中でもかなり辛いものでした。 そのような訳で普段であれば採用になりそうなトークもかなりの数ばっさりと切り落とす必要がありました。残念な結果になってしまった方もおられるかとは思いますが、審査側も苦渋の決断でありました。 おおまかな採用のための条件としては以下のようなトークを探して一旦大枠を埋めました： ＊ トーク概要が書き込んで

今年も無事夏コミで『Acme大全2015』を出すことができます（予定）。「Acme大全」は、同人サークル「どんぞこ楽屋」が発酵している、AcmeカテゴリのCPANモジュールを全て紹介するというコンセプトの同人誌です。 2009年から刊行して7冊目となりましたが、 実はその「前身（『本日のAcme』）」の「前身」となるPerlの同人誌（本体は評論誌でそのうちの数ページ）をYAPC::Asia 2008年でちょこっとブースを開いて頒布させてもらったことがあります。その後もYAPC::Asiaでは賑やかしというか、さらしものというか、まあ色々な形でブースを出させてもらい、「Acme大全」等の頒布を行ってきました。 そんなわけでYAPC::Asia Tokyoと伴に歩んできた「Acme大全」の裏話。いま話さなければもうその機会は永久に失われるでしょう！ 内容 具体的には Aame大全の作り方 どう

今日も、海外から来た古参Perlエンジニアと「I used to be a Perl monger」といった話を聞きました。 Perlを使ってきて、コミュニティのみんなと繋がってきた私達。 YAPC::Asiaも終わって20年後、私達はいったい何をしているのでしょうか？ Perl 26を使っているのか、はたまた他の言語かもしれませんが、今の経験は活きているのでしょうか？ YAPC::Asia 2012で「シリコンバレーと世界のPerlエンジニア」という発表の中で「10年後も食える仕事、食えない仕事」というトークをしました。 それを踏まえて、これまで20年間Perlで食べてきた人の視点から、今回は20年後を議論していきます。

「勉強会と私どっちが大事なの！？」と言われないために 本トークでは、子持ちエンジニアがいかにして妻の協力を得て、100名規模のRubyカンファレンス「神奈川Ruby会議01」を開催したかを中心に、継続的にコミュニティを運営するため、エンジニアとして学び続けるため、発表者が家族に理解を得るために行っている努力や失敗事例についてお話します。 神奈川Ruby会議01 YAuthと家族マイレージ クリスマスと勉強会 コミュニケーションツールとしてのZaim 生活音を抑えたPodcastの収録 家庭を支える技術 Advent Calendar 2014 - Adventar

use DBIx::Schema::DSL; create_table book => columns { integer 'id', primary_key, auto_increment; varchar 'name', null; integer 'author_id', not_null; decimal 'price', 'size' => [4,2]; add_index 'author_id_idx' => ['author_id']; belongs_to 'author'; }; これはなんとPerlのコードです。記号だらけで読みづらいと言われることもあるPerlですが、このコードは余計な記号も少なく、何をやろうとしているか明確です。これは、DBIx::Schema::DSLモジュールを用いてSQLのCREATE文を定義しているコードです。 Railsの

概要 システムの性質によっては、複数の部署から非同期的に いろいろな修正要望がふってきてしまうものがあると思います。 私は過去にそういったシステムを担当したときの苦労から、 同じ臭いを感じたシステムの設計をした時、 急や頻繁な仕様変更を迫られた時に簡単に修正できる作りにしました。 それが功を奏して、この前、別のシステムの緊急対応リリース4件に加え、 特別設計を施したシステムに対する急な仕様変更対応リリース3件を バグ・トラブル無しで同時にこなすことが出来ました。 この発表では、これを実現させることができたシステム構成を、 perlで簡単に構築する方法を紹介します。 アジェンダ（仮） 1.　頑固なシステムに苦労した話 1-1.　同時多発的にふってくる修正依頼 1-2.　システムの複雑化 2.　簡単にロジック変更できる構成 2-1.　処理のプラグイン化 2-2.　設定ファイルのDSL化 2-3

A mod_perl programmer talks development method on legacy middleware. 各地での小規模な勉強会が終わると、その後の懇親会の場でさまざまな方々との出会いがあります。ありがたいことに、過去のYAPCのトークやブログ記事などで私をご存知の方もいたりして、盃を交わしながら軽い相談をされることもあります。 「Perlのスター達は最新のウェブアプリケーションフレームワークなどを謳歌していて本当にうらやましいです。自分なんて受託開発でPerl CGIを書く日々でして…」 そういう方に対して私はこう声をかけるのです。 「いやー、実際のところPerlのスター達は多くの人が注目するゆえ存在が大きく感じられるだけで、Perlで開発をしている全体の2割にも満たないと思いますよ。僕もずっとmod_perl上で開発してきましたし。日本のPerlウェブ開

江戸一番のジャスタウェイ職人であるアスカさんがAndroid/iOSでツイッタークライアントを作る方法についてお話します。 ツイッタークライアント開発の準備（開発環境・ライブラリについてサラッと） ツイッタークライアント開発で使えるデザインリソース（非デザイナー向け） ツイッタークライアント開発でしか使えないテクニック（タイムラインの制御など） サードパーティ製ツイッタークライアントの歴史と文化

昨年講演を行ったFinal Fantasy Record Keeperのウェブフロントエンドパフォーマンスチューニングの内容を土台に ウェブゲームアプリケーションに限ることなく 現場でよく問題になるケースと"RAIL"パフォーマンスモデルを元にしたパフォーマンスチューニングの方法 jQueryは悪か？DOMアクセスのパフォーマンスを考える ウェブブラウザの描画とパフォーマンス 今できるServiceWorkerを用いたUX最適化 などをご紹介します。 ※FFRKの話はありません

2011年よりYAPC::AsiaのPhoto Sponsorを務めさせて頂いている写真共有・保存サービス 30days AlbumではオブジェクトストレージとしてMogileFSを利用しています。 そして、そのストレージにS3互換仕様でアクセスするためのWeb APIが 本日 社内向けにリリースされました。 本トークでは総容量700TBを超すMogileFSクラスタの運用苦労話と、そこにどうやってS3互換APIくっつけたのかをご紹介しようと思います。 キーワード /dev/sdafまである物理サーバ MogileFS(バッド)ノウハウ Nginxでreproxy(Accel Redirect) ngx_mrubyを使った認証 RailsとMogileFS

ユニットテストや受け入れテストは普及してきましたが、セキュリティテストは忘れがちです。 Webセキュリティの脆弱性問題は未だに出ており、それを減らすために脆弱性に関しても常にテストを行い、バグ（脆弱性）に立ち向かおうというお話です。 個人のノウハウや人力に頼らず、ツールやサービスを使いこなして開発の不安を和らげ、ビジネスロジックの開発に注力できるようにしましょう。 時間があれば、筆者が立ち上げた継続的セキュリティテストサービスの話として、世界中にサービスを展開する意味、そのために機能を加えず何を捨てることにしたのかなど、ビジネスを含めたサービス開発の話もできたらと思います。 トーク内容 セキュリティテストとは Webアプリケーションセキュリティ セキュリティテストツール セキュリティテストサービス CIと連携した継続的セキュリティテスト セキュリティテストで一番重要なこと 継続的セキュリテ

あるECサイトを物理サーバからクラウド環境に移転した際の作業内容をトークで発表します。 今回のECサイトは売り上げが年間1.5億円、データ量が10TB以上でした。 元々は物理サーバ10台で運用していましたが、古いサーバのリプレイスによる運用の手間や月々のラック、回線の利用料など諸々のコストを踏まえ、クラウドサービスに移転することになりました。 作業計画と段取り サービスの移行に際してまず重要なのが作業計画です。 いつ何をどういったタイミングで実施していくのか、計画がなければ準備することができません。 ではどうやってその計画を立て実行していくのかという話をしていきます。 また、計画を元に各作業の段取りを詰めていきます。 物理サーバの配送手配、クラウドのサーバ構築手配及びWEBコンソールの確認、DNSの切り替え、諸々の解約手続きなど、やることは多岐に渡ります。 最終的な作業の流れ 今回のサービ

Perlで開発をはじめるときに「use strict」するように、MySQLでも様々な問題を未然に防ぐために、使いはじめるときに気をつけておきたいことがあります。 本トークでは、話者のこれまでの経験からMySQLを使って開発をはじめるときに、開発者/運用者が気をつけておきたいことについて話します。 取り扱うトピック Strict SQL Mode Character Set / Collation 大文字小文字を区別するかどうか ハハ=パパ問題(アクセントを区別するかどうか) ?=?問題(SMP文字を区別するかどうか) Time Zone Avoid NULL NULLの奇妙な性質 UNIQUE Constraints 区別できない文字はUNIQUE制約の影響を受ける NULLはUNIQUE制約の影響を受けない 論理削除

TL;DR 4年間やってきたCTOが語る CTOが制度設計、全エンジニアの最終評価はCTOを経由 現場の声、事業責任者の声 内容 エンジニアの技術力を評価するのって難しいですよね。 評価する側がエンジニアではない場合は特に難しいと思います。 そこで、VOYAGE GROUPでは2011年7月から技術力評価会という名のエンジニアの相互評価制度を導入しました。 約4年やってみて、わりと良い感じだと思っています。 ただ、チームごとに最適な技術を選択する方針なので Perl はもちろん、PHP、Ruby、PythonなどのLL言語、さらにErlang、Scala、Schemeなども使っていたり、ネイティブアプリ開発やデータ分析など会社内で実績・知見が溜まっていない技術もどんどん増えてきて大変という課題もあり、毎回改善を重ねてますがまだまだやれる余地があると考えてます。 このトークでは、VOYAGE

公式ドキュメントや詳しく書かれた技術書、書き散らかしたポエムから短いTipsまで。エンジニアたるもの日々さまざまな技術情報に触れ、また発信していると思います。 それが将来の自分なのか、インターネット越しの見知らぬ誰かなのか分からないけど、せっかく発信するからには読み手の役に立って欲しいと願うものだと思います。 人に読まれ、役に立つ技術情報とはどういうものなのか。技術情報共有サービスである Qiita を作る日々の中で、最近考えていることを話します。 具体的には多くのユーザをヒアリングしていく中で分かってきた、多くのエンジニアが共通してい感じる読みたいと思う文書の性質とか、そういうことを共有したいと思います。

There is a "A useful, usable" release on rakudo.org site. しかし､実際には useful なものではないのではないか､という疑念を皆さんお持ちのようです｡ そこで､実際どのあたりの機能が利用可能で､どの程度進んでいるのか､ということを､ 外野の視点からお話させていただこうと思います｡ 結局 VM はどこがサポートされてるの? thread 実際いま動くの? 起動速度はどうなの? 実行速度はどうなの? CPAN にあたる部分はどうなの? 標準ライブラリはどうなってるの? web application は書けるの? そのあたり､気になりますよね｡その辺り､お話させていただきます! Perl6 はすぐそこまで来ているぞ!!!!