小ネタ: kurado + h2o 0.9.1 でHTTP2有効にしたときのバッドノウハウ : D-7 <altijd in beweging>
更新： h2oを0.9.1から1.0.0にしたらこのハック無しでもいけたくさいです！ HTTP2使いになりたい！と思いはじめて数ヶ月。でもなかなかうまいことここぞという使い道がなかったので、2週間ほど前にとりあえず仕事でkuradoを立てた時に前段にh2oを入れて様子を見ていた。kuradoならたくさんグラフ表示されるし、HTTP2の恩恵を受けられるはず…！と思って。HTTP1モードでは当然特になんにも問題はなかったのだが、いざChromeでenable-spdy4を有効にした時になーんか… 崩れる… 具体的にはCSS、画像の類いがこない事が多いが、たまにメインのHTML部分が返ってこない。Chromeの開発者ツールやnet-internalsを見ててもただERR::connectionResetみたいなエラーが返ってくるだけで全然意味がわからなかったので、しばらくそれはそれで忘れてた。
pecoがぼちぼち成功した3つの理由 : D-7 <altijd in beweging>
さきほどちょろっとアップデートが入ったpeco v0.2.2をリリースしました（Changeログ）。 で、ついでに昨日mattnさんがpecoについてツイートしてたので流れてしまう前にまとめておく mattn@mattn_jppeco、便利だしとても完成度高いんだけど、客観的に見るとあのプロジェクトがあれだけ流行ったのには理由があると思ってる。 2014/07/22 23:17:31 mattn@mattn_jpまず、Windows をネイティブサポートしたこと。少数ユーザの様で意外と多い。Windows だけ一部機能が欠けてるという事もない。 2014/07/22 23:22:00mattn@mattn_jp次に人気が出る中、手を止めなかったこと。停滞するとユーザも飽きる。 2014/07/22 23:25:44mattn@mattn_jpそして丁寧な README とアニメーションgi
気がついたらpecoを書き始めて一月たっていた : D-7 <altijd in beweging>
pecoのv0.1.0をリリースしてから今日で丸一ヶ月がすぎました。今日という日にちょうどGitHubでのスターも1000を超え、大変うれしい次第です。ちなみに昨日の夜840くらいだったのにそれから200弱ものスターがついた。これぞまさにTJのロックスター効果： TJ Holowaychuk@tjholowaychukreally cool interactive grep-ish tool https://t.co/jH5gWNCcIz 2014/07/12 03:42:22 「percolをインストールするのにpythonの事調べるのだるい」というだけのところからmattn氏の悪魔のささやきを真に受けて始まったこのプロジェクトですが、まぁ何がよかったのかこの程度の注目を集められるレベルに到達できて大変うれしいです。自分もこのコードを書いててようやくgo-stf-serverでメタメタだ
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もない。そ
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はずっと歴史を積んでいるだろうし、色々がんばっているのだろう
超楽しい！Kinetic Sand 所感 : D-7 <altijd in beweging>
動画を見て感動して衝動買いしたKinetic Sandが届いた！ Kinetic Sandとは98%砂なんだけど、砂のようにあちこちに散らばったり汚れたりしない「室内遊び用の砂」です。よくわかんないよね。詳しくは前の記事にも書いたけど動画を見て！ 届いたタイミングではまだ子供が寝ていたので起きるのを待っていようかと 思ったが、俺が遊びたいから買ったわけで やはり大人がまず確認をするべきだなと思い 合わせて買ってあったタライに5kg分のKinetic Sandをぶちまけて色々やってみた。というわけで以下レポート： まず感触は 「湿った砂」。かといって、べたべた手に付くわけでもない（ただし、全くつかないわけでもない）。ぎゅっとしめればそれなりに固まるが、本物の砂のように完全に結合する感じではない。例えばお団子を作って軽く握っている分には形を保っていられるが、強く握りすぎてしまうとさらに固く結合
私家版の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
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系の言語別にいらないな」とふ
YAPC運営とビジネス : D-7 <altijd in beweging>
Daisuke Maki@lestrratお金以上に重要なものもあるけど、お金がなくては何もできない。誰かの利を産むことによりお金を集め、それを使って自分の野望の実現するのです。イベント運営や団体運営の究極的な目的はお金儲けではないにしろ、ひとつのビジネスを創造する事が必要なのです。 2013/09/26 12:33:49 究極的な目的がお金儲けではないので当然こういうイベントでは資金はそこまで潤沢ではありません。活動内容自体もあまりお金儲けに走ると本来喜んでもらうべき相手であるコミュニティの反感を買いますし、一部からは「お金をかけない手作り感がいい」と言われる方もいます。 まぁ言いたいことは わかります。崇高な目的を商業主義に汚されたくないというのは確かに感情としては理解できます。 しかし 自分はこれまでスタッフとして参加したり、主催者として色々やってきたりしてその辺りの「汚い」部分をち
YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
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ページを開く
