2022年4月、Deno に以下のバグが報告されました。 fetch API を使って 300KB ぐらいあるファイルをアップロードすると、一定確率でアップロードされたファイルが壊れるというバグの報告です。 報告者によれば、1.20.6 まではバグは発生しておらず、1.21.0 から発生するようになったという事です。1.20.6 の次のリリースが 1.21.0 なので、パッチバージョン1個分まで、バグの発生時期が特定されている状態です。 fetch 周りは自分はほぼ実装していないので「担当範囲ではない」感覚だったので、普通にスルーしていました。 自分に限らず、Deno Land コアチームの誰もこの issue にピンと来る人が居なかったようで、stale ボット (数ヶ月進捗の無い issue を自動的にクローズしようとするボット) に2回もクローズされかけていました。Deno の st

半分ネタ記事です。あんまり真面目に書きません。 項目数が多いので，気力でなんとか書きます。分類は諦めます。 他にもある！っていうのがあったらコメント欄で教えて下さい。気が向いたら追記します。 公式の TypeScript 型定義がもはや型定義を諦めている 辛い度: ★★★★★ 辛い中でもこれはかなり上位に来るやつ。 こちらに OpenAPI 形式で仕様が定義されていて， https://github.com/slackapi/node-slack-sdk/tree/main/packages/web-api/types ここに仕様に基づいて TypeScript の型定義ファイルが吐かれるようになっています。 Git 管理されていないので，実際のリリースを見てみましょう。 https://unpkg.com/@slack/web-api@6.7.2/dist/response/Reacti

はじめに Pods は Kubernetes の中でもっとも重要なリソースです。複数のコンテナとボリュームの組み合わせで Kubernetes におけるスケールの最小単位であり、アプリケーションコンテナは必ず Pods としてデプロイされます。 ここでは Pods の終了の流れについて詳しく扱います。Deployments の更新などで新しいバージョンのアプリケーションをデプロイするとき、既存の Pods は終了されます。このとき正しく Pods の終了処理を準備できていないと、ユーザのリクエストが正しく処理されずエラーが出力されているかもしれません。ワンオフなジョブと異なり、サーバとしてデプロイされる Pods はそれと比べて比較的寿命は長く、更新の頻度は少ないかもしれません。しかしサービスの価値をいち早くユーザに届けるに頻繁なデプロイは欠かせません。よりデプロイの頻度が高くなるほど P

この記事はCraft Egg Advent Calendar 2021の12日目の記事です。 昨日は@kawase_ikutaさんの「スクラムっぽいことをやって感じたこと」でした。 はじめに チャットボットや社内ツールとして細々と導入し始めていたGo言語ですが、現在は新規プロジェクトのメイン言語となるなど、社内で使われる機会が少しずつ増えつつあります。 本記事では、そんな社内ツールを作成する際にちょうど最近気になって実装を読んだgo docコマンドの仕組みについて解説していこうと思います。 ちなみに今回実装を読んだGo 1.17.3時点でgo docに関するコードはテストコードを除くと1500行弱です。 年末年始のお供としてもちょうどよいボリューム感なのでぜひみなさんも読んでみてください。 go docコマンドの使い方 まずはgo docコマンドの使い方について軽くおさらいしておきます。

この記事は2021年Goアドベントカレンダー1日目の記事です。 ファイルパーミッションでスロットするコマンドラインツールを作りました。 経緯 ある日、サーバ上のとあるファイルの実行権限を変更する事がありました。 $ ls -lah sample_cmd -rwxr--r-- 1 jiro4989 jiro4989 0 Nov 21 15:14 sample_cmd* $ chmod 0777 ./sample_cmd $ ls -lah sample_cmd -rwxrwxrwx 1 jiro4989 jiro4989 0 Nov 21 15:14 sample_cmd* この chmod 0777って数字が3つ並んでるからパチスロみたいだなーーーと唐突に思いました。1 （パチスロやったことないですが） じゃあ、「ファイルのパーミッションをスロットで設定できたらテンション上がって地 味なサ

（追記）Qiita側での修正リリース完了 こんにちは。元 @500 です。 Qiitaのご担当者様から、当該ユーザー名を取得出来ないようにする修正リリースを11月19日に行ったと連絡を頂きました。 同時に、ユーザー名の変更依頼を受けましたので、 別のユーザー名に変更し今に至ります。 この記事をご覧になった方からいろいろな意見が来ていましたので、11月12日時点の記事内容に加筆をして以下に残します。 その出会いは偶然に…… なぜか空いていた「短いユーザー名」 これまで備忘録はiCloudのメモに書いて同期していたのですが、今さらQiitaに記事を書こうと先ほどアカウントを作成しました。 私は特に共通のハンドルネームみたいなのもなく、各種サービス登録時には超適当にユーザーIDやユーザー名を決めるタイプです。 Qiitaでは3文字以上とあったので、適当にユーザー名500と打ってみたら、意外にも一

gRPCで送受信されるメッセージは、標準ではProtocol Buffersでシリアライゼーションされることになっている。一方、gRPCのwire protocolはそこは柔軟になっていて、実際、多くの実装ではシリアライゼーション形式をカスタマイズ可能だ。 たとえば、ある種のニーズのためにFlatBuffersが必要だとか、HTTP/2をサポートする標準的なツールでの解析のためにJSONのほうが可読性が良いとか、社内のバイナリ表現の一貫性のためMsgPackが必要だとか、宗教的な理由でProtobufを使えないとか、そういうときはスキーマだけprotobufで書いておいて、シリアライズは好きなようにやれば良い。 で、具体的にはそれはどうやったらできるのだろう。これが本稿の話題である。いくつかの言語で実際にJSONでシリアライズするクライアントとサーバーを書いてみたので、その結果を紹介する。

序 : プロセッサへの嫉妬 DRAMさん「最近みんなCPUやGPUにばかりうつつを抜かしやがって…。みんながやれRyz○nだの、FinFET ○nmだの盛り上がって、みんなが次世代プロセッサを楽しみにしている。新しいアーキテクチャやISAが出てきて話題も絶えない。」 DRAMさん「たしかによ…CPUはパソコンの花形だし、GPUの性能上げればゲームのグラフィックスがきれいになるよ。それに比べると俺は目立たない。」 DRAMさん「挙句の果てに、Memory wallだなんて言われて、CPUやGPUの足を引っ張る存在だと疎まれている。」 DRAMさん「だけど…だけど…俺がいなかったらパソコンは動かない…！それに、俺だって頑張ってる！お腹にviaを貫通させたりして、CPUやGPUの足を引っ張らないようにしている！」 DRAMさん「だから…だから…俺を…DRAMを…見てくれ…！！！」 対象読者 DR

1. はじめに Rapidash というGo用のキャッシュライブラリを公開しました。 以前 https://qiita.com/goccy/items/a54af6db3b8623e90c38 で紹介した Octillery 同様、弊社の負荷対策用ライブラリになります。 キャッシュというとコンテキストによって用途は様々ですが、 Rapidash はアプリケーションサーバの応答性能を向上させるために、主にデータベースの負荷分散を目的として開発したライブラリになります。 主な機能は以下のようなものです。 検索しか行わないテーブルのデータをアプリケーションサーバ起動時にデータベースからすべて吸い上げ、インデックスの定義に従ってメモリ上に B＋Tree 構造で展開する。検索時は範囲検索もできる 読み書きを行うテーブルのレコードを memcached や Redis といったキャッシュサーバに格納し

本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良

response_url を理解しよう この記事では、Slack アプリを作ったことがある人でもあまり馴染みがないかもしれない response_url という仕組みについて網羅的に説明してみたいと思います 1。 response_url は、スラッシュコマンドやショートカットのようなユーザーと Slack アプリの間で直接的なインタラクションが発生する機能のペイロードに含まれるものです。Incoming Webhooks や chat.postMessageで Slack に通知を送るだけの連携からもう一歩進んで、よりインタラクティブな Slack アプリを作るとき、この機能をうまく使うと、より良いユーザー体験を実現できるでしょう。 なお、この記事では日本語でできる限り丁寧に説明していきますが、こちらの英語のドキュメントにも多くの内容は書かれていますので、合わせて参考にしてみてください。

ffmpeg を使い、HTTP Live Streaming(HLS)をファイルに保存し、保存したファイルからストリーミングを行う方法についてffmpegmp4HLS 追記 2016/02/16 に ffmpeg version 3.0 がリリースされました。 ver 3.0 では libaacplus libvo-aacenc が削除されるなど、コーデックとコンテナの統廃合が行われたようです。 このエントリは ffmpeg version 2.x について記述しているため、 ver 3.x ではそのままでは動かない部分があるかもしれません。ご留意ください。 また、 libfdk_aac が使えない場合は、 libfaac を使用してください。 本文 ffmpeg を使い HLS を使ったストリーミングを mp4 フォーマットで保存したり、その反対に mp4 からストリーミングを行う(m3

概要 Spotify APIの楽曲レコメンド機能を使って、DJ Mix用のプレイリストを作成できるWebアプリケーションを開発しました。まずはそのアプリケーションの内容をご紹介します。 実装はTypeScript + Next.jsで行いVercelにデプロイする形にしたところ、非常に高い開発体験が得られました。後半はSpotify APIの使い方を含めて、Next.jsでの実装やVercel上での設定について書いていきます。 できたもの AUTOMISCE - Automate Your Mix with Spotify API 使い方 まず"Sign in with Spotify"ボタンでSpotifyにログインします。次に右側の検索欄で最初の曲を選んでプレイリストに追加します。するとその曲と似たテンポでかつテンション感が少し上の曲が"Upper Tracks"欄に、少し下の曲が"D

上の2つがCLIで、下の2つがブラウザです。歴史的な経緯を見てみましょう。 〜1.1: go docはバンドルされているツールで、ソースもgo本体に同梱 1.2: go docは別のリポジトリにわけられてgodocになり、go本体から外れた 1.3: godocで-analysisオプションが追加 1.5: 新しい"go doc"コマンドがgo本体に同梱 1.11: godocがウェブだけになるため、go docを使えというアナウンスが出るように 1.12: godocが-httpだけをサポートしてCLIの機能は削除予定 1.13: godocのwebサーバーが同梱されなくなって手動でのインストールが必要に 1.13～: 既存のgodoc.orgから、go modのプロキシサーバーの情報をもとにドキュメントをホスティングするpkg.go.devが運用開始 わかりましたか？よくわかりませんよ

ソケットモード（Socket Mode）とは？ Slack は、2020 年に開催された年次イベント Frontiers にて「ソケットモード」という Slack アプリの新しい通信方式を発表しました。 これまでの Slack アプリ開発では、イベント API やモーダル送信、ボタンクリック、スラッシュコマンドなどのインタラクティブな操作のハンドリングには、公開された Web エンドポイントを用意して Slack からのリクエストを受信する必要がありました。 ソケットモードは、これを WebSocket での接続に切り替えることができる機能です。昔から Slack アプリやボットに慣れ親しんでいる方であれば Hubot や RTM (Real Time Messaging) API のように接続できる方式という言い方がわかりやすいかもしれません（RTM との違いについては、こちらのコメント

Happy Elements Advent Calendar 2020 24日目の記事です。 概要 あんさんぶるスターズ！！Musicのエンジニアリーダーをしています。 複数人で音楽ゲームを行う「みんなでライブ」で使われたリアルタイム通信基盤について書きたいと思います。 今回は技術選定の段階で検討した内容について紹介し、Redis Streamsを用いたスケーラブルな基盤を提案します。 みんなでライブについて みんなでライブは、あんスタ！！Musicにおいて複数人で音楽ゲームを行うシステムです。 画面遷移の同期やスタンプ送信、コンボ数の共有などがリアルタイム通信を用いて行われています。 リアルタイム通信の技術選定について 弊社ではポーリングを用いた複数人参加のバトルや、Photonを用いた協力プレイなど実績があります。 あんスタ！！Musicのみんなでライブでは同時接続1万人以上を想定して

異常検知について勉強したのでまとめておきます。 参考文献 下記文献を大いに参考にさせていただきました： [1] Ruff, Lukas, et al. "A Unifying Review of Deep and Shallow Anomaly Detection." arXiv preprint arXiv:2009.11732 (2020). [2] 井手. "入門 機械学習による異常検知―Rによる実践ガイド" コロナ社(2015) [3] 井手,杉山. "異常検知と変化検知 (機械学習プロフェッショナルシリーズ)" 講談社サイエンティフィク(2015) [4] 比戸. "異常検知入門" Jubatus Casual Talks #2(2013) [5] Pang, Guansong, et al. "Deep learning for anomaly detection: A rev

※ 2020-12-22 追記あり はじめに この記事は GLOBIS Advent Calendar 2020 - Qiita 17日目の記事です。 GLOBIS SRE チームでは2020年初頭より、 Kubernetes (Amazon EKS) を用いたインフラ環境の全面的な刷新に取り組んでいます。この新たな環境では Infrastructure as Code で環境の9割はコード化するという目標を立てており、 Terraform を積極的に活用しています。 この記事では、そんな弊チームでの Terraform の使い方についてまとめていきます。書き始めたら書きたいことが湯水のように湧いてきてしまったので、FAQ形式でまとめてみました。気になるところを拾い読みしてみてください。 Terraform 全般 Q. Terraform で何を管理していますか AWS がメインの環境なの

これは何? この記事は、 FOLIO Advent calendar 2020 の12日目の記事です。 11日目は、paulxllさんのデータマートを一から作り直した話でした。 13日目は、Yuki Ishikawaさんです。 先日、@j5ik2oさんからお誘いいただいたので、@MinoDrivenさんと一緒にいろいろ話して来ました。 今回は、その時に紹介した内容の補足や話し足りなかったことを書いていこうかと思います。 話してきたこと 私が主に話したのは以下の2つについてでした。 データ基盤から見たときのアプリケーション側の技術的負債の見え方 データ基盤から考えるドメインオブジェクトとモデリングについて 詳細については割愛しますが、主に以下のキーワードにまつわる話と、データマネジメントの営みを疎かにすると如何に大変かを話してました。 キーワード イミュータブルデータモデル @kawasim

data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL