ビビりなエンジニアが大企業を辞めて起業した話 - 最速配信研究会(@yamaz)
この記事は Supership株式会社 Advent Calendar 2016 - Qiita の1日目の記事になります。遅くなりました。 Supership CTO室室長 @yamaz です。 ビビりなエンジニアが大企業を辞めて起業した話を書きます。 スケールアウトを立ち上げる前、私はヤフージャパンに務めていた。 当時私は結構な給与をもらっており、かつそこそこの立場におり、かつ仕事も面白く、普通なら辞めないような立場だった。 だけど思うところがあり、会社を辞めその後会社を作ることになった。今回はそのあたりの話をしようと思う。今から10年ほど前の話だ。 きっかけ きっかけは上司からの命令だった。 「Adsense作って。2人で」 なんとなくそれっぽいものを作ったものの、エンジニアとしての自分に疑問を持つ結果となった。 AdSenseのすばらしさとのギャップ AdSenseはすごいプロダク
30分でわかる広告エンジン(アドサーバ)の作り方 - 最速配信研究会(@yamaz)
気づいたらなんだかBlogを書かなくなって1年たとうとしてるので，近況報告も兼ねてのエントリ． 8/22に大森で開催された濱田さん主催のデータマイニング+WEB 勉強会＠東京で「30分でわかる広告エンジンの作り方」と題して発表してきた．いわゆるアドサーバの内部アーキテクチャの話。 30分でわかる広告エンジンの作り方View more presentations from yamaz2. 濱田さんから「なんか話してくださいよ」といわれて，「じゃあ広告システムってこの勉強会ではなじみがないだろうからさらりと話しますかね」みたいな軽いノリだったのに，当日はその筋(？）の方々がたくさん来ていてえらく恐縮してしまった． (おしまい) yamaz的日常 前職を辞め，会社を立ち上げてからもう4年ほどたつがやっとBlogタイトルである「最速配信研究会」というに足る事業をなんとか成立させることができた．これ
RailsとCで広告システムを作って起業した話 - 最速配信研究会(@yamaz)
4/10清澄白河で開催された大江戸ruby会議01で 「RailsとCで広告システムを作って起業した話」と題して話をしてきた。 speakerdeck.com 詳細はスライドに書いてあるが、弊社は全く後ろ盾などないスタートアップにもかかわらず、異様なまでに濃いrubyistを集めることができていて、発表後「どうやってそんなすごい人を集めることができたのか？」という質問をうけた。 実はこれも秘密はなく、「彼らは当時たまたま求職中であったり、転職したがってることをRails勉強会の後の飲み会で聞いたりしたので即スカウトした」というのが実際の所で、ぶっちゃけたところ運がよかったとしか言えない。 せいぜい教訓めいたことを言うならば「恋愛と同じく、振られた直後に隣にいるというのは割と重要だ」あたりだろうか。 大江戸Ruby会議01はとてもよい会議でした。ほんとはエンジニアを集めるのに札束が踊りまくっ
RTB用のADサーバこそ最強である必要がある件 - 最速配信研究会(@yamaz)
明日はアドテック東京というデジタルマーケティングのカンファレンスが行われる。 最近広告配信周りでRTB(RealTimeBidding)というシステムがはやりつつあるが、RTB用のADサーバこそ最強である必要があるということを述べてみたいと思う。 RTBの仕組みというのは簡単に言うと下記のような感じになる。 1. 広告サーバ(SSP)に問い合わせがあった場合、バックに接続されたRTBの広告サーバ(以下RTBサーバ)に対して問い合わせをオークション形式で行う 2. RTBサーバは来たリクエストに対していくらで購入ができるかを返し、SSPは最も高い単価をつけた広告をユーザに返し、表示する(CPMというのは広告単価だと思えばいい) 上記の処理を1つの広告表示のたびに行うので、Real Time Bidding(RTB)というわけだ。RTBのエコシステムにおいては自分の都合のよいユーザのアクセスの
ミスとかトラブルとか - 最速配信研究会(@yamaz)
UIEUEIのid:shi3zさんがミスについての話を書いておられる(会社名間違えてました.大変失礼しました. > shi3zさん). 部下が致命的なミスをするのは全面的に上司の責任 1行でまとめると「ミスは必ずおきるので,ミスを事前に検知する仕組みが必要だよ」ということなんだけど,私も前職ではありとあらゆるミスやトラブルに遭い,それに対して思うところがあるので,どう対処してきたかを書いてみようと思う. このエントリは長くなりそうなので,先に「今来た3行」でまとめるとこんな感じになる. ミスやトラブルはありとあらゆる隙間を縫っておきるので,確率的なものととらえる方がいいよ. ミスやトラブルがおきた時の影響を最少にするためにはミスやトラブルを検知することの他に,「そもそもそんなミスが起きえないようにする」,「万一そのミスがおきても大丈夫なようにする」為の仕組み作りが重要だよ. 根性論に頼るの
イベントドリブン型静的生成ブログツールの提案(その2) - 最速配信研究会(@yamaz)
イベントドリブン型静的生成ブログツールの提案 で結構な数のツッコミをいただいた(ありがとうございます). 大体の意見をまとめると. 「そんなのとっくにあるよ.」 というものであった.全部を調べたわけではないが,WordPressとHNSとMTのキャッシュシステムのソースを調べてみるとキャッシュ削除の実装としては下記のような感じだった. 毎回DBにアクセスしてキャッシュファイルとlastmodifiedの比較を行う(MT,HNS). Blogレコードのセーブ時のコールバックでキャッシュファイルを消す(WP?). 1だとWebサーバが複数台でDBが1台だとアクセスがDBに集中 しちゃうので,あまり好みではない (DBの負荷に関してはリプリケーションを作ればいいという 意見もあるだろうが,不慮の時に備えてできればサーバは いきなり投入したい). で、もっと手軽にできないものかとmod_proxy
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
最速配信研究会 - ベンチャーを志向するということ
仙石浩明の日記:ソフトウェア産業の究極の振興策 http://blog.gcd.org/archives/50816826.html ここがスタートになっていろいろ意見が出ている. スラッシュドット:日本のソフトウェア産業を振興させたいなら大企業を一つ潰せ http://slashdot.jp/article.pl?sid=06/12/11/0311248&threshold=-1 雑種路線で行こう:ベンチャーに人材が足りないのは確かだが http://d.hatena.ne.jp/mkusunok/20061212 でyamaz的にもいろいろ思うところがあるので,書いてみる.なおid:yamazの経歴は下記の通り, 田舎大学の情報系修士を修了. 外資系有名半導体メーカで1年半ほど勤務 外資系超有名ポータルで7年ほど勤務. 現在無職.立場的にはおおむねニート. この売り手優位の地合いでも，
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
