急成長中の会社をサクッと辞めた事に関して色々言われるので書くつもりがなかった退職エントリを書く : D-7 <altijd in beweging>
タイトルの通りなんですが、某急成長中／快進撃中のあの企業を11月末ですごくサクッとやめて、イベント運営サポート・チケット販売システムをやっているスタートアップであるPeatixにジョインしました。とりあえずインフラ周りをがっつり整備する方向。 この話をするとわりと真顔で「え、なんで？あの会社を辞めるなんてなんか事件でもあったの？！」って感じの反応をされるんだけど、そういうことではないのでそこだけ説明のため好きでもない退職・転職エントリを書いている次第です。 まず、なにか事件があったわけではない。べつになーんもなかった。子供のお迎えとかをしてても基本文句も言われなかったとか、色々融通を効かせてくれてたのは明らかだし、そのまま居れば皆も知ってる勢いのある企業でボチボチ高給取りでいられたかなーとは思う。 だから退職せずにもっと良い方法を模索すればよかったのかなぁとは思わないではないけど、やっぱり
YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
YAPC::Asia Tokyo 2013: 八木竜馬という男を紹介しておきたい。 : D-7 <altijd in beweging>
YAPC::Asia Tokyo 2013が終わった。何個かエントリを書こうと思うが、とりあえずまずこの話から。 YAPC::Asia Tokyo 2009から主催者の立場にいるのだが、2009年に自分があちこちのスポンサーまわりをしたときにまず一番辛かったのが「YAPCってどんなイベントなの？」って言われた時に言葉でしか説明できなかったこと。「Perlの技術者が集まって話すイベント」ですって言っちゃったらそれでおしまいだよね。本当は熱気が溢れるイベントなのにそれだけだとただの演説みたいに聞こえる。そんなんでスポンサーに金を出してもらえる訳がない。 そこで後任者が誰であれ（結果、今年までずってやってきてしまったわけだけど）知らない人に伝えるのにマルチメディア素材を用意しておこう！それ用の予算も組もう！という明確な意思を持って知り合いにフォトグラファーを紹介してもらって、今年まで毎年写真を撮
最近いれたでっかい変更とか : D-7 <altijd in beweging>
現時点ではあんまり具体的に何をしたか書けないけどブログにでっけぇ変更を入れた。システム全体の根本的な部分なので一発でキレイにとはいかなかったが、まぁ変更の規模に対して考えると妥当な感じだろう。本番化には1週間かかった。なので大分開放感がある。 具体的な事はもっと後になったら言えるが、とりあえず今の段階では Apacheモジュールを殺し、1000行近いRewriteRuleを殺し、PSGI側でミドルウェアを9個作成してPSGI側でApacheが今までやってたことを全て吸収した。 （追記 8/23 12:20）あとログがltsvになったよ！その先の事はモリス先生がやってるよ！このログもプロキシ側でログを取るのにアプリ側からの情報を組み込むとかしなきゃいけんかったので地味に面倒くさかった。わかってしまえば簡単だったけど。 パフォーマンスは正直言って、Apache版と比べて色々追加でやってることも
STF 1年後。 : D-7 <altijd in beweging>
ほぼ一年前に「STFワーカーの自律分散と適応スロットリング」という記事を書いた。 STFというAmazon S3っぽいツールの裏方のワーカーをどう「サービスの邪魔をせずに」「しかし可能な限り大量のデータを速やかに処理するか」という命題をどう解消した、と言う話。 あれからほぼ1年たって「そういえばもう大分STFなにもしてねぇな」と気づいたのでこのエントリを書き始めた。 あれ以来ワーカーの過負荷によるアラートが来たことない。あれ？と思ったらワーカーが止まっててキューがいっぱいいっぱいになっちゃった、というのもない。足りないワーカーは勝手に補充されるし、ストレージの負荷が高い時は勝手に自動的にスロットリングされる。要はもうこの1年近く俺は管理画面でフラグをちょいと変えたりグラフを見たりする意外ほぼなんにもしてない。勝手に動いている。 この協調メカニズムを作るのにMySQLだけを使って書いたのが自
2013年は残念ながらno LTThonです : D-7 <altijd in beweging>
（追記）LTthonは前夜祭でプチ復活します！公式ブログ・私のブログ dokechin@dokechin今年もLTソンあるのかな？ スピーカーは敷居が高すぎてー #yapcasia 2013/05/15 20:52:39 去年Hachioji.pmの皆様に主導してもらったLTソンはもうただひたすら発表者のいる限りLTを続けるというイベントで、参加者に対する敷居の低さなどもあってたくさんの方が発表し、刺激し合い、結果的にすばらしい企画になったと思っています。 だけど今年のYAPC::Asia Tokyo 2013ではやらない方向です。 良い企画だと思ってるのになんでか？ それは主に人の導線のせいです。去年の会場はメインホールの真横にまるでエアポケットのように広場があり、メインの企画であるセッションを聞きに行く人達の導線を邪魔しないところにとてもカジュアルな空間を作れました。視覚的にも「ああ、
Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの？」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること！ まずこのお話の前提：mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない（←ここポイント）。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう？ まずアプリケーションを組む側が「やっちまったなぁ？」な件：P
ついに顕在化しはじめたPerlリスク（棒 を眺めながら仕事をしていた結果 : D-7 <altijd in beweging>
10年物の20万行ほどあるWebアプリの配信部分をPSGI化したところ、先ほど無事○○Gbps単位のピークタイムをシステムの負荷をあげすぎず（アラートをあげず）に乗り切れたようです。 関係者の皆様お疲れ様でした。ご協力ありがとうございます。 最初パフォーマンスの問題があってがっかりしたけど、良いコード書けたと思うし、最終的にはちゃんと期待してたくらいのパフォーマンスが出て良かった。 ちなみにそのWebアプリっておまえの読んでるこれだよ、これ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
思い立って、Perl5 Census Japan 2013を作ってみた : D-7 <altijd in beweging>