タグ

ブックマーク / lestrrat.ldblog.jp (16)

  • 日記風味に綴る、YAPC::Asia Tokyo 2015までの道 : D-7 <altijd in beweging>

    YAPC::Asia Tokyo 2015が終わった。厳密にはこれからスタッフ打ち上げの調整、動画関連、支払い関連、ブログ関連、写真関連の仕事がまだあるけど、まぁともかく山場は過ぎた。 今回は最大の大きさにもかかわらずいわゆるコアスタッフの面々とこれまで何回もボランティアスタッフをやってくれていた方達が次々と起こる予測していない事態や、主催の自分がセッションでの出番やMC等でいない時に進めなければいけない様々な事柄の指示を出してくれててものすごく助かった。もちろん自分も自分が指示を出せないとわかっているときはその前に責任の委譲や指示だしをやっていたけど、それ以上に自律的に動いていてくれたのでものすごく助かった。今回のYAPCは完全にスタッフのみんなの能力の勝利だった。 エモい話や将来の話とかはまたいつかするとして、このエントリではとりあえず日記風な感じで昨年9月末からの大まかなな流れを書い

    日記風味に綴る、YAPC::Asia Tokyo 2015までの道 : D-7 <altijd in beweging>
  • ソーシャルコーディングの時代に置いてはエンジニア以外もレポジトリ(GitHub等)を見るべき : D-7 <altijd in beweging>

    ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。 昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。 が、21世紀に入って10年以上過ぎてい

    ソーシャルコーディングの時代に置いてはエンジニア以外もレポジトリ(GitHub等)を見るべき : D-7 <altijd in beweging>
    azumakuniyuki
    azumakuniyuki 2015/02/17
    エンジニアは信じられないほど怠ける事ができる
  • 急成長中の会社をサクッと辞めた事に関して色々言われるので書くつもりがなかった退職エントリを書く : D-7 <altijd in beweging>

    タイトルの通りなんですが、某急成長中/快進撃中のあの企業を11月末ですごくサクッとやめて、イベント運営サポート・チケット販売システムをやっているスタートアップであるPeatixにジョインしました。とりあえずインフラ周りをがっつり整備する方向。 この話をするとわりと真顔で「え、なんで?あの会社を辞めるなんてなんか事件でもあったの?!」って感じの反応をされるんだけど、そういうことではないのでそこだけ説明のため好きでもない退職転職エントリを書いている次第です。 まず、なにか事件があったわけではない。べつになーんもなかった。子供のお迎えとかをしてても基文句も言われなかったとか、色々融通を効かせてくれてたのは明らかだし、そのまま居れば皆も知ってる勢いのある企業でボチボチ高給取りでいられたかなーとは思う。 だから退職せずにもっと良い方法を模索すればよかったのかなぁとは思わないではないけど、やっぱり

    急成長中の会社をサクッと辞めた事に関して色々言われるので書くつもりがなかった退職エントリを書く : D-7 <altijd in beweging>
  • YAPC::Asia Tokyo 2015 の会場の紹介 : D-7 <altijd in beweging>

    YAPC::Asia Tokyo 2015 は ななななんと!8/20-8/22にビッグサイトで開催されます! まだまだ番までは時間はありますが、エントリではどどーーーーーんとその辺りを先取りして 皆様に紹介したいと思います! もしこれを見て「スポンサーに興味あるんだけど、この会場だったら○○とかできる?」というような興味が湧いた方は是非こちらのフォームからお問い合わせください!さて、というわけで会場です。ビッグサイト!ビッグサイト、名前からして大きそうですよね!実際大きいです!ビッグです!実は僕は今回見学しにいくまでビッグサイトは行った事がありませんでした。ビッグサイトすごいですね! 今回お借りする会場は「会議棟」です。有名なコミケとかが行われる会場は「展示棟」のほうです。会議棟は実はこの逆三角形の建物の中にあります。 入り口から入って左手に上に昇エスカレーターがあります。これで一気

    YAPC::Asia Tokyo 2015 の会場の紹介 : D-7 <altijd in beweging>
  • 欧米のYAPCの問題点とイベント運営について僕の考え : D-7 <altijd in beweging>

    今年のYAPC::Asia Tokyo 2014は海外ゲストの方々と色々話す機会があったのでかなりの時間彼らと話していた。 特にスピーカーの方々とは「日人に受けるためにはどういうアプローチがいいんだ」という相談をYAPC期間中に(今更!)聞かれて 「日人は証拠として数値の提示を求める傾向があるから、数値をもっと盛り込め」とか「おまえらの会社日だと全然知られてないんだからまずそこから変えろ」とか等々の助言をして大分彼らのトークの内容を微調整する業務があった。特にDBICのトークは(見てないけど)YAPC::EUでやったものと全く内容が違う、という報告をスピーカー人にもらった。ははは、通訳の人たちに迷惑かけたかなーw ともあれ、その流れで海外のYAPCの話。今回話した人たち全員から 「なんでYAPC::Asiaはこんなに人が集まるんだ?」「どうしたら俺たちのYAPC(EUにしろNAにし

    欧米のYAPCの問題点とイベント運営について僕の考え : D-7 <altijd in beweging>
  • Githubでpecoのアカウントを融通してもらった件 : D-7 <altijd in beweging>

    tl;dr; githubで長い事使われてないアカウントはリリースしてもらえることがあるpecoのURLが変わりましたpecoの有効な使い方があったら、ぜひWikiでシェアしてくださいpecoが何か自分の予想を超えて使われ始めているので責任を逃れるために今後の事を考えてGithub Organizationにしようかなーと思って調べてたらpecoってユーザーがすでに存在してたのでがっかりしたのが昨日の朝。 Daisuke Maki@lestrratugh. taken. no activity either. disappointment haunts all my dreams.https://t.co/04HBzVjpzw #golang #peco 2014/06/19 08:56:45 でもこのアカウント全く使われてなかったんだよね。コミットもなければstarもwatchもない。そ

    Githubでpecoのアカウントを融通してもらった件 : D-7 <altijd in beweging>
    azumakuniyuki
    azumakuniyuki 2014/06/20
    ``githubで長い事使われてないアカウントはリリースしてもらえることがある''
  • @INCとuse : D-7 <altijd in beweging>

    @INCとuse : D-7 <altijd in beweging>
  • 私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>

    なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り: これは自分の部署で初めて 番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正(例:SQL文の変更)などを自分以外の人間が施した後にサーバーを簡単に再コンパイル+再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log

    私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>
  • Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>

    tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね! Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて1時間Goについてしゃべりまくってきた。1時間ぶっつけ番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます Go事始め そもそもなんでここまでGoをガリガリ書き出したのか。 正直親父ギャグとvimで有名なあの人が「Goいいよ!」と言い出したときにはGoに対してはうさんくさい印象しかなくて特に注意すらしてなかったんだけど、そろそろ違う言語とドメインに向いてみるかーと思って探していた時に「あ、俺もうLL系の言語別にいらないな」とふ

    Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>
  • TPFによるPerl助成金の交付の変更等について : D-7 <altijd in beweging>

    ちょっと前から私が関わらせてもらっているThe Perl FoundationのGrants CommitteeはPerl関連で広い範囲において有用性が認められるプロジェクトにたいして定期的に助成金を交付しています(詳細はこちら)。基的に誰でも応募可能です(応募方法はこちら)。 この活動ルールにいくつか変更が加えられました(原文はこちら)。なおTPF Grants Committeeには現在自分とMakoto Nozaki(筆頭メンバー)さんの二人の日人が関わっておりますので、日からの応募が今までのどの時点よりも通りやすい(便宜を図るという事ではなく応募に不備があった場合などの対応について日向けの対応がちゃんとできるという意味です)ので、皆様是非ご検討ください。 なお変更内容については以下の通りです: 1. 二ヶ月おきに応募審査が行われる これまでは四半期ごとでしたが、 もっと頻繁

    TPFによるPerl助成金の交付の変更等について : D-7 <altijd in beweging>
  • YAPC運営とビジネス : D-7 <altijd in beweging>

    Daisuke Maki@lestrratお金以上に重要なものもあるけど、お金がなくては何もできない。誰かの利を産むことによりお金を集め、それを使って自分の野望の実現するのです。イベント運営や団体運営の究極的な目的はお金儲けではないにしろ、ひとつのビジネスを創造する事が必要なのです。 2013/09/26 12:33:49 究極的な目的がお金儲けではないので当然こういうイベントでは資金はそこまで潤沢ではありません。活動内容自体もあまりお金儲けに走ると来喜んでもらうべき相手であるコミュニティの反感を買いますし、一部からは「お金をかけない手作り感がいい」と言われる方もいます。 まぁ言いたいことは わかります。崇高な目的を商業主義に汚されたくないというのは確かに感情としては理解できます。 しかし 自分はこれまでスタッフとして参加したり、主催者として色々やってきたりしてその辺りの「汚い」部分をち

    YAPC運営とビジネス : D-7 <altijd in beweging>
  • 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: 今年のこれまでの道のりとクロージング : D-7 <altijd in beweging>
    azumakuniyuki
    azumakuniyuki 2013/09/25
    大変お疲れさまでした && 一番左の軸、読めない所があって気になってる。
  • YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>

    はい、というわけで自分のトークです: 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記:スライドに「ログにマーカーをつける」というのは、(コード読んでないけど)多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました: 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました! (

    YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
  • YAPC::Asia Tokyo 2013: 八木竜馬という男を紹介しておきたい。 : D-7 <altijd in beweging>

    YAPC::Asia Tokyo 2013が終わった。何個かエントリを書こうと思うが、とりあえずまずこの話から。 YAPC::Asia Tokyo 2009から主催者の立場にいるのだが、2009年に自分があちこちのスポンサーまわりをしたときにまず一番辛かったのが「YAPCってどんなイベントなの?」って言われた時に言葉でしか説明できなかったこと。「Perl技術者が集まって話すイベント」ですって言っちゃったらそれでおしまいだよね。当は熱気が溢れるイベントなのにそれだけだとただの演説みたいに聞こえる。そんなんでスポンサーに金を出してもらえる訳がない。 そこで後任者が誰であれ(結果、今年までずってやってきてしまったわけだけど)知らない人に伝えるのにマルチメディア素材を用意しておこう!それ用の予算も組もう!という明確な意思を持って知り合いにフォトグラファーを紹介してもらって、今年まで毎年写真を撮

    YAPC::Asia Tokyo 2013: 八木竜馬という男を紹介しておきたい。 : D-7 <altijd in beweging>
    azumakuniyuki
    azumakuniyuki 2013/09/23
    プロの写真家によるYAPC::Asiaの良い写真
  • Perl5 Census Japan 2013をまとめてみました : D-7 <altijd in beweging>

    Perl5 Census Japan 2013に回答いただいた皆様、ご協力ありがとうございました!知らなかった人のために説明しておくと、私が2013年4月7日から19日までの間アンケート形式で日でのPerlの利用状態等を知りたいと思い回答を募りました。回答数は394でした。 なるほどねー、へー、と思いつつデータを見ていました。取り急ぎ今回はシンプルな回答の集計結果をお知らせしようと思います。これからさらに面白い解析は是非このエントリの最後にあるデータを使ってみていただけると嬉しいです。 それでは一個一個紹介していきます。まずは回答者の居住地域。圧倒的に関東優勢。調べた事ないけど、やっぱりIT系の人はほとんど東京近郊に集まってる、ということでいいんかな。ちなみに中国地方がゼロ、ってのがなかなか味わい深いw Perl歴。古くから広まっている言語、という事もあり10年選手が多い。 Perl熟練

    Perl5 Census Japan 2013をまとめてみました : D-7 <altijd in beweging>
    azumakuniyuki
    azumakuniyuki 2013/04/23
    人口に対する割合で見ても関東は近畿の3倍以上か
  • 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

    Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
  • 1