日記風味に綴る、YAPC::Asia Tokyo 2015までの道 : D-7 <altijd in beweging>
YAPC::Asia Tokyo 2015が終わった。厳密にはこれからスタッフ打ち上げの調整、動画関連、支払い関連、ブログ関連、写真関連の仕事がまだあるけど、まぁともかく山場は過ぎた。 今回は最大の大きさにもかかわらずいわゆるコアスタッフの面々とこれまで何回もボランティアスタッフをやってくれていた方達が次々と起こる予測していない事態や、主催の自分がセッションでの出番やMC等でいない時に進めなければいけない様々な事柄の指示を出してくれててものすごく助かった。もちろん自分も自分が指示を出せないとわかっているときはその前に責任の委譲や指示だしをやっていたけど、それ以上に自律的に動いていてくれたのでものすごく助かった。今回のYAPCは完全にスタッフのみんなの能力の勝利だった。 エモい話や将来の話とかはまたいつかするとして、このエントリではとりあえず日記風な感じで昨年9月末からの大まかなな流れを書い
Software Design 2015/3月号とWeb+DB Press vol 85 : D-7 <altijd in beweging>
Software Design 2015年3月号 ソフトウェア デザイン 2015年 03 月号 の表紙はYAPC::Asia Tokyo 2013, YAPC::Asia Tokyo 2014でもお世話になり、今年もお世話になる予定の CONBUの面々による「カンファレンスネットワークの作り方」です。普段正直ほとんど技術系の雑誌ってわざわざ買わないんだけどこの号は購入した。 本文の記事ももちろんおもしろいんだけど、個人的にはやはり「YAPC」という文字列が専門誌とは言え一般的にあちこちで流通している雑誌の表紙に載っているのが胸熱…！ 今までも雑誌にYAPC::Asia Tokyo関連の記事を載せてもらったり書いたりしたことはあったんだけど、もうYAPC本体とはなんにも関係ないところで自然？な形でこういう形でYAPCの名前が載るのがとにかく感動であった。 Web+DB Press vol
YAPC::Asia Tokyo 2015 の会場の紹介 : D-7 <altijd in beweging>
YAPC::Asia Tokyo 2015 は ななななんと！8/20-8/22にビッグサイトで開催されます！ まだまだ本番までは時間はありますが、本エントリではどどーーーーーんとその辺りを先取りして 皆様に紹介したいと思います！ もしこれを見て「スポンサーに興味あるんだけど、この会場だったら○○とかできる？」というような興味が湧いた方は是非こちらのフォームからお問い合わせください！さて、というわけで会場です。ビッグサイト！ビッグサイト、名前からして大きそうですよね！実際大きいです！ビッグです！実は僕は今回見学しにいくまでビッグサイトは行った事がありませんでした。ビッグサイトすごいですね！ 今回お借りする会場は「会議棟」です。有名なコミケとかが行われる会場は「展示棟」のほうです。会議棟は実はこの逆三角形の建物の中にあります。 入り口から入って左手に上に昇エスカレーターがあります。これで一気
dockerデビューしてみた : D-7 <altijd in beweging>
docker、触ってたけどちゃんとデプロイとかしたことなかったのでこのひと月しこしこ作業しては失敗し直しては失敗しを繰り返してて、この週末やっとデプロイした。yapcasia.orgのことなんですけどね。 以下ベストプラクティスかどうかは知らないけど、とりあえず俺が通った道筋： 最初コンテナ同士のつながりをどう定義するといいのか全然わからなくて困っていた。例えばサイトの基本はMovableTypeで構築しているんだけど、その人は当然mysqlと話すから、MT→mysqlの接続を定義するのにどういうふうに名前やポート番号を解決するの？とかnginxからMTへの接続の解決は…？とか dockerコンテナの内容はimmutableであっても、コンテナのインスタンス自体は揮発性が高いものであるから、できればシンボリックな形でそれぞれのコンテナやデーモン等の接続情報を提供して動的に解決したいわけだが
YAPC::Asia Tokyo 2014 is right around the corner... : D-7 <altijd in beweging>
このブログを普段から読んでいただいている方達は当然既知の事かと思いますが、来週YAPC::Asia Tokyo 2014というイベントが開催されます。 YAPC::Asia Tokyoは確か2006年が初開催で、その時は現在はRebuild.fmで有名な宮川さんが旗を振って開催されました。自分は最初の年からスタッフとして参加していてその後毎年同じように参加していました。 それまでも裏方をなんとなく覗き見していて運営大変だなーとは思っていたのですが、2008年の小山さんのLTの内容を見て「法人が必要だろこれ！」と決心したところからJapan Perl Association (JPA)という団体の創設とその団体によるYAPCの運営の引き継ぎをしました。本当は2009年はJPAは裏方で助けるつもりだったのにいつのまにか主催になってたけどな！ 2009年は色々あり開催こそできたものの、かなりメチ
peco（Simplistic interactive filtering tool）を作った話 : D-7 <altijd in beweging>
（pecoそのものについてはここで読むよりREADMEを見た方が早いです） 今月の初めくらいにpercolという便利なものがあるという話を聞き、「ほう、使おうかな」と思ったら普段あまり使い慣れていないpython製ツールでまるでcpanmを使うのがいやなPerlに慣れていない人のような反応で「まぁ必須アイテムじゃないし…」と思って諦めかけたところ lestratt さんはやく！ — mattn (@mattn_jp) June 6, 2014 とか言われ「そこまでいいツールなのかなー」と思ったけど、使ったことないし、まずはツールがどういうものなのかをわかるためにGoで実装する事にした（はい、本当にこういう順番です）。 pythonが駄目でなんでGoが良いかと言えば単純にバイナリ一個で済むから。それだけ。多分オリジナルのpercolはずっと歴史を積んでいるだろうし、色々がんばっているのだろう
Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>
tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね！ Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて１時間Goについてしゃべりまくってきた。1時間ぶっつけ本番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます Go事始め そもそもなんでここまでGoをガリガリ書き出したのか。 正直親父ギャグとvimで有名なあの人が「Goいいよ！」と言い出したときにはGoに対してはうさんくさい印象しかなくて特に注意すらしてなかったんだけど、そろそろ違う言語とドメインに向いてみるかーと思って探していた時に「あ、俺もうLL系の言語別にいらないな」とふ
Go所感 : D-7 <altijd in beweging>
もう一つわりとまともなプログラム書いてみて、Go 1.1について所感。あくまで個人的な感触です。 やっぱりC書いてる人向けな言語な気がひしひしとする。例外がないならないでわりと気にならなくなってきた最初すごい使うだろうと思っていたdeferを意外と使わないhttp.Requestとかはまだ貧弱な気がするstring[from:to] は結構便利murmur hashの古いバージョンが必要だったのでポートしてみたけど、Cコードをそのまま置き換えるだけで楽だった。""と``は視覚的にわかりにくいと思うんだけど、まぁ使い方わかったら重宝してる。意外とほとんど組み込みライブラリだけでできるslice.push()とかできないのすごく気になる。slice = append(slice, ...) は視覚的にすごい無駄な気がしてしょうがないんだけど、コンパイル時に最適化されてるんだろうな。とりあえずG
The Perl FoundationのGrants Committeeメンバーになりました : D-7 <altijd in beweging>
The Perl Foundation (TPF)のGrants Committeeのメンバーに選出されて就任依頼を受けたのでこれを謹んで引き受けることにしました！一応アジアからは唯一のメンバーとなっております。 Grants CommitteeはTPFから助成金の交付関連の管理をしているTPF内の委員会です。助成金を申請するにはこちらのルールに従って申請をメールするだけです。審査は年4回。現時点では助成金の上限は3000USドルと なっていますが、この上限はそのうち変更されるという噂を聞いています（そのあたりのルールまわりの審査・議論にも参加できる予定です）。 助成金の応募に関しては英語の壁だなんだはあるかとは思いますが、日本発のおもしろい技術はたくさんありますしオープンソース系の自分の仕事に対してなんらかの報酬がつくのは多少モチベーションがあがる材料にもなると思いますので、興味があれば
YAPC運営とビジネス : D-7 <altijd in beweging>
Daisuke Maki@lestrratお金以上に重要なものもあるけど、お金がなくては何もできない。誰かの利を産むことによりお金を集め、それを使って自分の野望の実現するのです。イベント運営や団体運営の究極的な目的はお金儲けではないにしろ、ひとつのビジネスを創造する事が必要なのです。 2013/09/26 12:33:49 究極的な目的がお金儲けではないので当然こういうイベントでは資金はそこまで潤沢ではありません。活動内容自体もあまりお金儲けに走ると本来喜んでもらうべき相手であるコミュニティの反感を買いますし、一部からは「お金をかけない手作り感がいい」と言われる方もいます。 まぁ言いたいことは わかります。崇高な目的を商業主義に汚されたくないというのは確かに感情としては理解できます。 しかし 自分はこれまでスタッフとして参加したり、主催者として色々やってきたりしてその辺りの「汚い」部分をち
YAPC::Asia Tokyo 2013: 今年のこれまでの道のりとクロージング : D-7 <altijd in beweging>
初めて関わったYAPC::Asia Tokyoは2006年で、具体的な数は知らないですが多分150人くらいの参加者だったらしい。そこから数えて8年目。YAPC::Asia Tokyo 2013はチケット売上げ + 招待枠 + スピーカー + スタッフで 1,131名を記録した。自分の観測漏れがなければぶっちぎりで世界最大のYAPCである。 このエントリーではクロージングで話した内容とともに、今年のYAPCが開催されるまでの流れをざざーっと書いていこうと思う。来年以降にイベントを開催したい人達に向けてなにかしらのヒントになると嬉しい。 予想来場者数・予算確定 今年は1月頃から行動開始した。これまではわりと出たところ勝負で規模・予算を決めていったのだけれども、去年まで連続して黒字を出せてたしスポンサー・チケット売上げの大枠予想がつき始めてたので、まず「来場してほしい人数」「そこから予測される予
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の技術者が集まって話すイベント」ですって言っちゃったらそれでおしまいだよね。本当は熱気が溢れるイベントなのにそれだけだとただの演説みたいに聞こえる。そんなんでスポンサーに金を出してもらえる訳がない。 そこで後任者が誰であれ（結果、今年までずってやってきてしまったわけだけど）知らない人に伝えるのにマルチメディア素材を用意しておこう！それ用の予算も組もう！という明確な意思を持って知り合いにフォトグラファーを紹介してもらって、今年まで毎年写真を撮
Perl5 Census Japan 2013をまとめてみました : D-7 <altijd in beweging>
Perl5 Census Japan 2013に回答いただいた皆様、ご協力ありがとうございました！知らなかった人のために説明しておくと、私が2013年4月7日から19日までの間アンケート形式で日本でのPerlの利用状態等を知りたいと思い回答を募りました。回答数は394でした。 なるほどねー、へー、と思いつつデータを見ていました。取り急ぎ今回はシンプルな回答の集計結果をお知らせしようと思います。これからさらに面白い解析は是非このエントリの最後にあるデータを使ってみていただけると嬉しいです。 それでは一個一個紹介していきます。まずは回答者の居住地域。圧倒的に関東優勢。調べた事ないけど、やっぱりIT系の人はほとんど東京近郊に集まってる、ということでいいんかな。ちなみに中国地方がゼロ、ってのがなかなか味わい深いｗ Perl歴。古くから広まっている言語、という事もあり10年選手が多い。 Perl熟練
ついに顕在化しはじめたPerlリスク（棒 を眺めながら仕事をしていた結果 : D-7 <altijd in beweging>
10年物の20万行ほどあるWebアプリの配信部分をPSGI化したところ、先ほど無事○○Gbps単位のピークタイムをシステムの負荷をあげすぎず（アラートをあげず）に乗り切れたようです。 関係者の皆様お疲れ様でした。ご協力ありがとうございます。 最初パフォーマンスの問題があってがっかりしたけど、良いコード書けたと思うし、最終的にはちゃんと期待してたくらいのパフォーマンスが出て良かった。 ちなみにそのWebアプリっておまえの読んでるこれだよ、これ。
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Perlのmakeフェーズの挙動 : D-7 <altijd in beweging>