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が発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ

なんとなくZigを触っているのですが、ビットシフト演算が独特の挙動で面白かったです。 const n: u8 = 0b00000001; const shifted: u8 = n << 1; std.debug.print("{b}\n", .{shifted}); // => 0b00000010 これは直感的なコードでしょう。n が1バイト左にシフトしています。 さて以下のコードはどうでしょうか。 const n: u8 = 0b00000001; const shifted: u8 = n << 8; std.debug.print("{b}\n", .{shifted}); // expects 0, but... このコードは ./main.zig:5:30: error: integer value 8 cannot be coerced to type 'u3' const

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

アプリケーションの設定ファイルと言えばjsonやyamlなんかで書くことが多いと思うんですが，最近はTypeScriptで設定ファイルを書いております．このような感じ: export interface ApplicationConfig { readonly listenPort: number; readonly timeout: number; readonly apiBaseUrl: string; readonly loggerOptions: LoggerOptions; } こういう感じで設定のinterfaceを定義しておいて export class ProductionConfig implements ApplicationConfig { readonly listenPort = 5963; readonly timeout = 5000; readonly ap