yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ！ nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ

pprof って go のやつでしょ？　node のプロファイルが取れるわけ無いやろ，と僕も思っていたんですが以下のライブラリを使うことで取れることがわかりました． github.com 使い方については Using the Profiler に書いてあるとおりで，アプリケーション側に const profile = await pprof.time.profile({ durationMillis: 10000, // time in milliseconds for which to // collect profile. }); const buf = await pprof.encode(profile); fs.writeFile('wall.pb.gz', buf, (err) => { if (err) throw err; }); という風に書いてあげるとwall time

github.com 今日 (2020-09-24) の時点では「ローカル環境」で動かす方法については記載がある一方で，何らかのリモートの環境に「本番」っぽく動かす方法についての記載が無いので，それを AWS 上に構築するためのメモを記します． 競技用 application のデプロイ isucon.net これを見る限り，参加者側の環境は以下の通り: アリババクラウドさんの ecs.sn1ne.large を採用しました。 CPUは2コア (Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz)、メモリは4GBの、オーバーコミットのないインスタンスです。ネットワーク帯域も100Mbpsです。 ただし、今回のアプリケーションではメモリに全ての切らない環境を再現するために、Linuxにはメモリを1GBしか認識させていません。CPUは2コアで、メモリ1GBの環境

そうは言っても障害は起きるものです．で，障害が起きて，終息したあとの振り返りとして社内向けにoutage report (障害報告書的な？) のようなものを書くと思うのですが，本記事ではそのときに気をつけていることについて書きたいと思います。 outage reportの目的 そもそもですが，outage reportを書く目的としては以下のような物があるのかなと思っています。 A: 障害が起きたという事実に関する周知 障害についてお客様からお問い合わせが来たりした時に正しい情報を届けられるようにするため B: 根本原因の洗い出し 再発防止のため C: 障害検知フローの確認 障害に対する初動までにかかる時間を短くするため D: トポロジの形成 知見の醸成 似たような問題が起きたときに，outage reportに書いてある対処法を逆引き的に利用できるようにするため outage repor

全く知らなかったのだけれど，C11の新機能として_Genericという組み込み関数が提供されていた． Generic selection - cppreference.com jameshfisher.com というのをこのブログを見て気づいたんですが， #include <stdio.h> int main() { char* x = "foo"; printf("Type of x is: %s\n", _Generic(x, char*: "string", int: "int")); return 0; } これは完全に動くコード (最初よく文章を読んでなくて，大方擬似コードだろうと侮っていたら本当に動いて驚いた)． だいたい分かると思うんですが，上記のコードは char*の引数が_Genericに渡されるとstringという文字列を出力し，intの引数が与えられるとintという文

yapcjapan.org 行ってきて，そして喋りました． スライドは以下にあります． speakerdeck.com Perlコードに別の言語のコードを埋め込んで動かしてしまう技術であるところのInlineモジュールの話です．今回のYAPCのテーマは「万国津梁」とのことだったので「じゃあPerlと他の言語をつなげるInlineモジュールの話でもすればよかろう」と短絡的に題材を選択してしまったわけですが，そのままではなかなか「引っ掛かり」が無い話になってしまったため (出オチみたいな感じになった)，色々風呂敷を広げてみました．それはそうとしてnumpyマジで速いですね．それだけ覚えて帰って下さい． 「グルー言語」の部分については碌々調べずにスライドのあるようなことを喋ったわけですが，恐らくこのような点はあるのだろうなと思っています． かつて言語側で頑張らなければならなかったコンポーネント間

私信ですが転職いたします．以下の通りです． From: LINE To: Soracom 関係各位に感謝を申し上げます．ありがとうございました． 以上です．よろしくお願いします． なお本記事は以下のレギュレーションに従いました． タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。— laiso (@laiso) 2017年8月1日 twitter.com [追記] 職場崩壊だとか，ネガティヴな方向に持って行きたがる向きが散見されますが，それらに対する回答は以下の通りです．職場崩壊なんて一切無かったし，本当に良い会社及び同僚でした．これ，キラキラレギュレーションに引っかかりますかね？ まあいいや！ ブクマ100超えたら突然見当違いなことを言って来る人が

新しくサーバ立てた時やサーバ追加した時に，そのサーバが他のホストの特定のポートと疎通できるかどうかチェックする必要が出てくる時がある．ACLとかの兼ね合い． そういうのは本番の環境だと監視のシステム等に組み込まれていたり，あるいはserverspecとかで確認されていることが多いと思うのだけれど，その場で雑に確認したくなることがあると思う．そういう時はtelnetで繋いで，quitして，というのを繰り返していく感じになりがちなのだけれど，対象となるホストの数が多くなってくるとそういうことを手でやるのも大変になってくる……というわけでこれです． $ (sleep 0.1; echo quit) | telnet $HOST $PORT) こういう風にしておくとtelnetで繋いだ後にquitを発行するということを自動でやってくれる． とはいうものの，こうすると正しく繋げているかどうかを目視で

というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技

途中の段階でプロジェクトに入った時などに，「どれがそのプロジェクトの中心となっているファイルなんだろうか」というのを手っ取り早く知りたくなる時があります．僕はあります． そこで「どのファイルが盛んに変更されているのか」という点を指標として注目すると，良い感じにそこら辺取れるのでは無いかと思って試してみました． コミット数が多いファイルは多く変更を加えられているということから，そうしたファイルはホットであるということが言えそうな気がしたので，git でファイルごとのコミット数を取ってきて，それをソートして見てやれば良いよな，という意識でやっていきました．もちろんコミットの粒度などもあるでしょうから一概にはそうとは言い切れませんが，参考にはなる気はします． 使うスクリプトは至って簡単．以下の様な感じです． git ls-files | while read file ; do commits=