Private content!This content has been marked as private by the uploader.
こんにちは。広報・マーケティング担当の中村です。 本日は引き続き開発言語Perlの世界最大級イベントであるYAPC::Asiaとスカイアークとの3年間の振り返りです。スカイアークがYAPC::Asiaのスポンサーとなってから2011年で二度目。エンジニアにとっても、スカイアークにとっても、もちろんYAPC::Asiaにとっても充実したスポンサードになるよう、スポンサー内容やノベルティ、登壇内容などを大幅にリニューアルしました。特に大きな反響を頂いた「遠方からの参加者支援制度」をまずは振り返ります。 2010年はスカイアークとして初めてのスポンサードであり、スタッフの登壇でもあったため、2011年は「もっとお祭りに参加するイメージ」を高めたいとYAPC開催の3ヶ月前より関係者で3つの骨子を肉付けしつつ企画を立てました。 もっとYAPCに貢献できるようなスポンサード内容の検討 もっと「お祭り感
TheSchwartz のような RDBMS をつかった job queue は、新規に daemon をたてたりする必要がないので楽でいいのですが、一方で job の追加の timing が storage から push でおくられてこないので、若干の delay が生じてしまうのが難点でした。 この問題を解決するために、mysql の binlog API を用いて、処理してみるハックを考えてみました。 binlog API を利用すると更新クエリを streaming で処理できるので、こういったハックも簡単にできちゃいます。おもしろい。 use 5.016000; use MySQL::BinLog; use TheSchwartz; my $sch = TheSchwartz->new(...) or die; $sch->can_do($_) for ...; $sch->w
mysql の binlog api をあつかうためのライブラリである libreplication というものがあるのですが、これの perl binding を開発しました。 https://github.com/tokuhirom/MySQL-BinLog とりあえず、examples/basic-2.cpp でやっていることができるところまでつくっておきました。 バイナリログの内容を streaming で処理できるのがおもしろいです。 以下のような用途での応用が考えられるようです。夢がひろがりんぐですね。 libreplication のセットアップ方法については riywo さんの記事をごらんください。 http://blog.riywo.com/2012/07/08/133005 はまりポイントは、streaming 開始時に ROTATE_EVENT が発生して、最新のログ
6月20日(水)17時ごろ発生した大規模障害の復旧作業において実施したデータ復旧作業にて、お客様に提供した復元データの中に、別の顧客領域のデータが混在し参照ができる可能性があることを確認いたしました。 このような事態を発生させたことにより、多大なご迷惑とご心配をおかけし深くお詫び申し上げます。 6月20日(水)17時ごろ発生した障害によりデータが消失した後、6月21日(木)9時ごろにデータ復旧プログラムにより消失データを復旧し、復元データとしてお客様に提供いたしました。 その後、専用サーバーをご利用の一部のお客様から、アクセス権限が無いデータが閲覧できるとの問い合わせがあったため、調査をしたところお客様環境内の別ユーザーのデータが閲覧できる状態となっておりました。 直ちに復元データの提供を中止し、他の顧客領域でも同様の事象が発生する可能性を調査したところ、お客様に提供した復元データの中に
Git Advent Calendar / Jun. 最終日(30日目)の記事です.29日目は「いざという時のためのgit reflog」でした. Git Advent Calendar最後なので,git操作でやりがちなミスからどう回復するかをまとめます.他にもあればコメントもらえるとマージしていきます. ブランチを切り忘れてmasterでコミットしてしまった その時点でブランチを切る&reset --hardで間違ったコミットたちをmasterから消す $ git checkout -b new-branch # masterの最新コミットを消す $ git checkout master && git reset --hard HEAD~
ちょっとmemcached & Redisについて調べたのでめも。 ちなみに、生存戦略って言葉は最近Twitterでよく見るから使ってみただけで、実際に何かは知りません。歌か何かかな。 ちなみに見ているソースについては、memcachedは1.4.6、Redisは現時点でのgitの最新(多分)。 memcachedに関して、特定のサイズのchunkを管理するslab classっていうものがあるよーん、とかは説明するとめんどくさいので飛ばします。↓の記事とかに書いてあります。 http://gihyo.jp/dev/feature/01/memcached/0002?page=1 memcached 起動時の-Lオプションが付いてる場合、初めに全部mallocしちゃう。付いていない && DONT_PREALLOC_SLABSがdefineされている場合はchunkのpreallocate
最近のモダンな JavaScript では、必ず "use strict" というのが書かれていると思います。この使い方を雰囲気ではわかってるけど、正しく理解していない場合が自分も含めて多いと思ったので書きとめたいと思います。 ちなみに、"use strict" でググると Perl のそれが出てきますが、Perl の話はしません。あとセミコロンの話もしません。 "use strict"とはそもそもなにか "use strict" は、Use Strict Directive と呼ばれています。 これは ECMA-262 の 14.1 Directive Prologues and the Use Strict Directive によって示されています。 A Use Strict Directive is an ExpressionStatement in a Directive Pro
6. ⾃⼰紹介訳書(1/2) Martin Fowler's Bliki (2003) ↓ 『アジャイルレトロスペクティブズ』 (2007) ↓ スクラムガイド (2010) ↓ 『メタプログラミングRuby』 (2010) ↓ 『ウェブオペレーション』 (2011) ↓ 『Facebookマーケティング』 (2011) ↓ 6/58 7. ⾃⼰紹介訳書(2/2) ↓ 『Clean Coder』 (2012) ↓ 『リーダブルコード』 (2012) ←【イマココ】 ↓ 『Service Design Patterns』 (2012) ↓ 『Seven Databases in Seven Weeks』 (2012) ↓ 『Running Lean』 (2012) ↓ 『...』(2012?) 7/58
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く