2. Me • 長野雅広(Masahiro Nagano) • @kazeburo • Mercari, Inc. • Operations Engineer, Site Reliability • ISUCON芸人
シックス・アパートのエンジニアの重田です。 YAPC::Asia Tokyo 2015 にご来場いただきました皆様、2日間(または3日間)お疲れ様でした。 Six Apartは、コーヒースポンサーとして協賛させていただきまして、当社オリジナル紙コップを提供しました。 Twitter では多くの方が紙コップの画像とともにツイートしていただき、本当にありがとうございました。 無限コーヒーと呼ばれるコーヒーブースでは無料でコーヒーが提供されておりましたが、予定されていた数量を飲み切ることができませんでしたね。運営の勝ちでした。 さて今回は紙コップのコードにまつわる話をしたいと思います。 構想 2015年のはじめにコーヒースポンサーになることが決まり、合わせてオリジナル紙コップを提供することも決まりました。 5月頃にいよいよ紙コップのデザインを決める段階になりました。 「コード実行したら URL
自分の中では 4 回目の YAPC::Asia TOKYO に行ってきました。初めて行ったのは新潟で学生やってた時に Niigata.pm で知り合った人たちが行くというので気になり、学生枠で参加したものでした(チケット無料!)。その時にいい話が聞けたり LT ソンとかやったりして楽しかったので裏方もやってみたいと思い、上京してからは 2 年連続スタッフで参加していました。 YAPC::Asia 2013に参加したです! - ミントフレーバー緑茶 YAPC::Asia Tokyo 2014で当日スタッフをしました - ミントフレーバー緑茶 今年は最後の大花火というので、普通に参加しても当たり前のように楽しいやろ通常参加 2 回、スタッフ参加 2 回になってキリもいいやろとてきとうな理由をつけて通常参加。以下は見たトーク一覧。 見た講演 HTTP/2時代のウェブサイト設計 Perlで学ぼう!
#yapcasia みなさま長い時間大変おつかれさまでした!!!事故のないよう気をつけて帰ってそして家に着いたらブログ書いてください!!!よろしくお願いします!!!— monmon (@lesamoureuses) 2015, 8月 22 ということでブログ書いて一旦区切りを付けようと思います。 思い返すと2009年に初めてYAPCを知り一般参加者として参加、2010年からボランティアスタッフ、2013年からはコアスタッフ、今年はまたボランティアスタッフ、ということで僕の YAPC::Asia Tokyo はほぼ全てスタッフでの参加となりました。 今回の参加のきっかけ (内容見えないように荒い画像になってますがKPTの様子) 2014年9月終わりに2014年コアスタッフ + 次回あるならやりたいとを手を挙げていたメンバーでKPTのために集まり、そこで yusukebe さんは次回できない、
引き続きDay 2も参加してきました。昨日のDay 1のレポートはこちらをどうぞ。 関連記事:YAPC::Asia Day 1 レポート 〜 Miiverseのデプロイ手法、HTTP/2、Electronなど - 無印吉澤@HatenaBlog Day 2に聴講したセッションはこちら(↓)。ベストトーク賞(1日あたり2件、計4件投票できる)は、★付きの講演に投票しました。 2日目(2015-08-22)のトークスケジュール [★]Mackerel開発におけるScalaとGo、そしてPerl (Masayuki Matsuki, @songmu) 我々はどのように冗長化を失敗したのか (Kenji Naito, @kenjiskywalker) MySQLで2億件のシリアルデータと格闘したチューニングの話(斉藤 健二, @saiken3110) [★]3分でサービスのOSを入れ替える技術 (
私は Yahoo JAPAN に所属し YDN (Yahoo!ディスプレイアドネットワーク) を担当しています。 先日、この YDN の crawler を perl で一から書き直しました。 これまでの crawler のコードといえば、いわゆるレガシーコードと化していて、開発者の多くがそのコードに触るのに二の足を踏んでいる状況でした。 一方、レガシーコードとは言っても、それは要求されている仕事をなんとかこなしており、だからこそ長らく放置されてきました。 おそらくみなさんの会社にもこういったコード、システムは少なからずあるのではないでしょうか。 私は、このレガシーコードを一から書き直しました。これにどれほどの意味があるのか、という疑問も当然わきます。実際、書き直しているとき何度も自問自答しました。また一方で、以前のプログラムよりいいプログラムが本当に自分に書けるのかという不安もありました
Three years on Perl ~ The technology to developing cool web service ~ Accepted #yapcasiaE Vote! Tweet 発表者は,この三年間はてなブログというイケてるPerlのサービスの開発に携ってきました… Perlの最新を追い求め続けた三年間でした… なにも分からず,SQLをコピペし続けた数ヶ月… つらいことも,たのしいことも,みんな分かちあったコードベース… 救いを求め,藁にもすがる思いで,朝も夜も読み続けたオブジェクト指向入門…… 偶然発見して,これだと思ったドメイン駆動設計…… 苦しみの軌跡と,現在最高の設計を紹介します………!!!!!!! 当時最強のフレームワーク それまでの,社内フレームワーク 鳴り物入りで登場した,当時最強のフレームワーク 社内でも歓迎されたが…… 最強のフレームワーク vs
TL;DR 慣れてる技術(Perl)を使いつつ、今の現場でどうアウトプットしていくか AdServerを支えるPerlプロダクト の紹介をする予定です 内容 VOYAGE GROUPは様々なサービスを運営しており、それを支える技術も多種多様です。 その一つであり、私が所属するadingoが提供する事業でも様々な技術が用いられております。 このトークでは、現場ごとに異なる環境であっても、ある一つの手段(Perl)を使いつつアウトプットしてきた内容をご紹介します。 今もPerlの現場でPerlを使っている人 昔はPerlの現場だったけど、、な人 これからPerlの現場に行く予定の人!? 上記どのパターンの方も対象になりますし、「Perl関係ない」人にもヒントになる内容もあるかと思います。 最新のイケてるものの活用事例や、革新的なプロダクトを作った!みたいな派手な内容ではありません。 どちらかと
ISUCONというWebアプリケーションのパフォーマンス改善コンテストをご存知でしょうか? ISUCONとは、「お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル」です。3人でチームを組んで参加し、レギュレーションの中であれば自由にアプリケーションに手を加え、出題者が用意したベンチマークでもっとも優れたスコアをたたき出したチームが優勝となります。2011年から4回開催されています。 発表者は2011年、2012年の2回は出題側として問題作成と調整、アプリケーションやベンチマーカーの作成に関わり、2013年、2014年は参加者として2年連続優勝をしています。そして、今年2015年も開催することが発表され、多くの注目を集めています。私も参加する予定です。 このトークではISUCONの課題作成や、問題に取り組んだ経験、また、普段からオペレーションエン
(English follows Japanese) YAPC実行委員長の牧です。 今年のYAPCのゲストスピーカーの一部をサイト上で公開しました! 今回は最近はGo言語の開発の一員、そしてMemcachedやDanga::Socket等の開発でもおなじみであり、Perlユーザーにもなじみが深いBrad Fitzpatrick氏に加え、なななななんと! Rubyの親とPerlの親であるMatz氏とLarry Wall氏が同じカンファレンスに集まるという滅多にない機会がうまれる予定です! でも今年はこれだけではありません、まだ詳細は未定ですがあと2,3人ゲストスピーカーを招待する予定です。もうしばしお待ちください! なお去年に引き続き今年も海外勢のトークに関しては同時通訳をお願いして英語が苦手という皆様にも気楽に楽しんでいただけるようになる予定です。なお同時通訳はスポンサー第一弾はGitHu
YAPC::Asia Tokyo 2014で、いろんな言語を適材適所で使おう - YAPC::Asia Tokyo 2014という話をしてきました。 これまでのソフトウェアエンジニアとしての経験から、継続的に価値を提供し続けるための技術選択はどのようにあり得るのかということをずっと考えていて、「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdaysや、GMOペパボのエンジニア新人研修 #lldiverという発表でもそのあたりの問題意識に基いて話したりしてきました。今回の話は、では、それらの延長線上での、将来における技術選択の最適化について考えてみました。 もうちょっとちゃんと定量化できる感じにしたいけど、まだまだ難しそうだなあという感じ。もうちょっと深堀りして考えていきたいと思います。
初参加の YAPC で “初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略” という長ったらしくて何を言いたいのかわからないタイトルでエモーショナルにトークした。 (勢いでタイトル決めて応募した時が一番テンション上がってたので、資料作る時にはすでに落ち着いてて自分でも何が言いたかったのかタイトル見てもよく分からなくなってた。) 緊張してたし言いたいこととっちらかってて全然上手なトークじゃなかったと思うけど、数人に「僕も初心者なんですけど参考になったし頑張ろうと思いました!」みたいなこと言ってもらえて、発表後とか懇親会で話聞きにくれた人たちもいてめちゃくちゃ嬉しかった。 バリューでたので、昨日夜は最高の気分でビール飲んでた。 結局何が言いたかったのか今の Web アプリケーションとかやれることが色々あってすごい複雑だし、最低限知っておくべき知識
Attention 別枠でやっているトークが非常に面白そうですが、途中で抜けられると悲しみ。(僕も行きたい) ベストスピーカーの投票だけは何卒… ちなみにトークの最後に驚きの発表が…? Profile id: Songmu (ソンムー) Masayuki Matsuki おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ 「ブログタイトルが長い人」 https://metacpan.org/author/SONGMU 趣味はCPANizeです 夏休みが終わる 昨日のライブコーディングのお詫び 謎の500エラーでテンパる Cookie消して凌ぐ HTTP::Session2::ClientStore2のエラーハンドリングに少し問題 深夜にカッとなってpull request https://github.com/tokuhirom/HTTP-Session2
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ 何故話すのか 大企業も昔は色々な苦労を体験して成長されてきたんだな、ということを体験して その経験談を体系的に自分の中でまとめたいことが理由です。 頭ではなく、体験して、心で理解したことをお話しします。 このトークが誰かのお役に立てればと思います。 TL;DR 成長するシステムにおいてのリソース管理・未来予想・ギャップとの調整 ミスやバグは発生する、気付ける土台をつくる 必要な構成の変更・必要ではない構成の変更 可能な限りの自動化を行い、不要なオペレーションを最小限まで減らす 精神をすり減らさない為に座禅をする 概略 サービスを運用するにあたり "いかに運用する作業コストを下げるか" "お金をかけずに耐障害性を上げるか" というのは中小サービスを運用する人間にとっては
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く