切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
PerlからGoへのシステム移行のアシスト 〜Perl XSとUnix Domain Socketを活用〜 - Mirrativ Tech Blog
こんにちは ハタ です。 Mirrativ では 2020年頃から サーバサイドの技術をPerlからGoへのシステム移行 を行っており、2024年現在でもサグラダファミリアのように移行作業は継続しています PerlとGoという2つの環境を同時に運用していますが、 基本的には 新機能は Go で実装 し、 Perlでは積極的に新規実装を行わない というスタイルで進めていました しかし、既存の機能の一部に手を加えたいとなった場合、まだまだ Perl の実装に手を加えることが一定あり、Perl から Go の機能を呼び出したいというニーズが出てきました （配信やギフトといったビジネスの根幹を支えるレガシーな実装においては顕著） そこで PerlXS を利用することで Perl から Go を直接呼び出せるようにできないかと考え検証を進めることにしました Goの -buildmode=c-shar
はじめに みなさん様々な言語でAPIサーバーを立てて負荷試験を実施したことはありますか。 私自身、業務でPythonのアプリケーションに対して負荷試験を実施した経験があります。 その際にPythonの速度観点の不安定さを目の当たりにしたと同時に、別の言語ではどのような違いが生まれるのだろうか、という疑問を持ちました。 そこで今回は、簡単ではありますがGoとRustとPythonでそれぞれAPIサーバーを立てて負荷試験をしてみます。 負荷試験対象のAPIサーバー 今回は(1) Hello, World!を返すAPI(2) ファイル読み込みAPI(3)1秒待ってから応答するAPIの3つを実装します。 (1)はAPIサーバー自体の応答速度の計測、(2)はメモリを消費する処理が生じた場合のAPIの応答速度の計測、(3)は待ち時間発生している時のAPIの応答速度の計測することが目的です。 (2)につ
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ？本当に正しく Server.Shutdown 使えている？」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
Kyoto.go #50 LT https://kyotogo.connpass.com/event/313309/
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに JCEXで実践しているAPIテストについて 単体テスト 負荷テスト なぜAPIの単体テストを行っているのか API単体テストで使用するパッケージ 実例によるAPI単体テストの環境構築 前提 ステップ１: テストしたいAPIの定義 ステップ２: テストの作成 ステップ３: APIの実装 ステップ４: DBを使ったテスト ステップ５: ヘルパー関数化 ステップ６: テーブル駆動テストに変える ステップ７: フィクスチャを使ったテスト まとめ おわりに はじめに こんにちは、enechainのGXデスクでエンジニアをしている@ejiです。 GXデスクは、『日本気候取引所 - Japan Climate Exchange』 (以下 JCEX) のサービス開発を担当しており、 私は主にBFFとバックエンドのAPIをGoで開発しています。バックエンドのAPIは gRPC を使用しています。
Go のコードで文字列の変換をする関数があり、これが Google スプレッドシート上の関数としても利用できれば検証[1]に便利かもしれないと思いました。 Google スプレッドシートでは Apps Script の関数をセル上で実行できるので、Go のコードを Wasm にビルドして JavaScript から呼び出すことができれば良いのではないかと考え、実際に試してみることにしました。 動作環境 Go 1.22.2 Apps Script の設定 Chrome V8 ランタイムを有効にする その他 macOS の pbcopy コマンド[2]を利用した手順を記載していますが、Linux 環境でも pbcopy を他の手段に置き換えることで同様に動作しました。 事前調査 Go を Wasm にビルドして GAS で動かす事例は見当たりませんでしたが、Rust を Wasm にビルドして
前置き 以前、BuildInfoからバージョンを取得する方法を紹介しました。 blog.lufia.org go installで正規の公開されたバージョンをインストールした場合は、以下の出力においてmodの行が示すように、sum.golang.orgでチェックサム等が検証されてバイナリのメタデータに埋め込まれます。 $ go version -m dotsync dotsync: go1.22.2 path github.com/lufia/dotsync mod github.com/lufia/dotsync v0.0.2 h1:JWm92Aw8pSKJ4eHiQZIsE/4rgwk3h5CjEbJ/S30wiOU= build -buildmode=exe build -compiler=gc build -trimpath=true build DefaultGODEBUG=ht
既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく、手動計装を選んだ理由を説明します。 GoアプリケーションへのOpenTelemetry計装手段 Goにおいては、OpenTelemetryの自動計装が公式で用意されていません。公式サイトにAutomaticの章がないことからわかります。おそらく、ランタイムの制約で実行時にアプリケーションの挙動を変えることが難しいのでしょう。 トレースに十分なスパンを含めるために、現状では以下の2つの計装手段があります。既存のGoアプリケーションに導入する手間や影響範囲をイメージいただくために、概要に絞って解説します。 手動計装 eBPFによる自動計装（Work In Progres） 1. 手動計装 まず、OpenTelemetryのSDKをインストールし、セットアップをします。 func main
リトライ処理を追加するとバッチが安定することがあることもそこそこあるので「avast/retry-go」を使ってみる - じゃあ、おうちで学べる
はじめに インフラエンジニアは日々の業務でプログラムを書く機会が多く、その中で処理の実行やHTTPの通信などでリトライ処理を実装する必要があることが少なくありません。リトライ処理を実装する必要は必ずしもなくても、実装することでバッチが安定することがあります。もっと言っておくとリトライ処理を実装することで、一時的なエラーによる処理の失敗を回避し、バッチ処理の安定性が向上する可能性があります。実行基盤によってジョブの再試行の自動化、最大再試行回数を設定するやPod失敗のバックオフポリシーなどとの兼ね合いを考える必要もあると思います。あとはマジでガー不のバグを引き寄せることもあるので注意が必要です。 はじめに シンプルな例 最大リトライ回数の指定 次のリトライまでの待ち時間の設定 特定の例外のみリトライするケース さいごに 今回はGolangには「retry-go」というリトライ処理を簡潔に実装
GitHub - MHNightCat/superfile: Pretty fancy and modern terminal file manager
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub - microsoft/go: The Microsoft build of the Go toolset
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. This repository, microsoft/go, contains the infrastructure Microsoft uses to build Go. The submodule named go contains the Go source code. By default, the submodule's remote URL is the official GitHub mirror of Go, golang/go. The canonical Git repository for Go source code is located at
GitHub - borgo-lang/borgo: Borgo is a statically typed language that compiles to Go.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは、CyberFight DX 事業本部で web フロントエンドエンジニアをしている久保です。CyberFight DX 事業本部は複数のエンタメサービスを開発、運用するFANTECH本部に所属しています。今回は、管理画面を対象に WebAssembly ( Wasm ) を導入した事例をご紹介します。 FANTECH 本部では技術ブログでの発信を強化しており、最近では下記のような記事を投稿しています。ぜひご一読ください。 Cloud Run サイドカーで Fastly の Prometheus Metrics を収集して Grafana で可視化する reminder-lintでFeature Flagsの削除漏れを防ぐ マルチリージョンで稼働する内製Feature Flagsの実装 私たちのプロダクト WRESTLE UNIVERSE では、ユーザー対象のキャンペーンを実施す
failureでお手軽エラーハンドリング
failureでお手軽エラーハンドリング 2024/04/23 Goのエラーハンドリング 最新事情Lunch LT morikuni
Goのソースコードを処理するツール（コードチェックやデータ生成など）を作ってみたいと思ったので、Goの構文解析に入門してみました。 まえがき ソースコードを何らかのツールにかけて処理したいことはよくあるかと思います。 例えばコードのルールチェックやフォーマットを行うとか、特定のフォーマットで書かれたコード（やコメント）から何らかのデータ（APIドキュメントなど）を自動生成するなどです。 昨今ではこのような処理を行うためのツールが多数提供されており、多くのプロジェクトで利用されています。 しかし、プロジェクトに固有なルールであるとか、独自のデータファイルを生成したいとなったとき、それら既存のツールでは対応できないこともあります。 そのような場合は「自分たちでツールを作る」ということが考えられますが、その際にはどのようにしてソースコードを処理すればよいのでしょうか？ 簡単なツールであればちょっ
はじめに 株式会社QualiArtsで「IDOLY PRIDE（以降、アイプラ）」のバックエンドエンジニアチームのリーダーをしている末吉です。 主にゲームAPIの開発やインフラの運用、チームメンバーの進捗管理や開発スケジュールの策定等を担当しています。 課金アイテムを取り扱ってるiOSアプリの場合、返金が発生することがあります。こちらはユーザー側でAppStoreに返金の申請を行うなど、様々な要因で発生します。 こちらの返金を検知をするためには、AppStoreでの仕様に合わせたシステムをプロダクト側で構築する必要があります。 そこで、本記事ではタイトルの通りGoを使用したAppStoreの返金検知システムについて紹介します。 前提として、本記事は2024年4月現在の仕様に基づいているため、今後プラットフォーム側の仕様が変更になる可能性がある点については注意してください。 全体の流れ まず
The Go Blog Secure Randomness in Go 1.22 Russ Cox and Filippo Valsorda 2 May 2024 Computers aren’t random. On the contrary, hardware designers work very hard to make sure computers run every program the same way every time. So when a program does need random numbers, that requires extra effort. Traditionally, computer scientists and programming languages have distinguished between two different ki
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
Go、Rust、Pythonで実装したAPIサーバーの負荷試験比較 - Qiita
ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法
GitHub - 1buran/rHttp: REPL for HTTP
GoでgRPCのAPIテスト環境を構築する - enechain Tech Blog
Go を Wasm にビルドして Google Apps Script で動かす
Go製バイナリを配布するためのGitHubワークフロー - Plan 9とGo言語のブログ
GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話
管理画面にWasm入れてみた | CyberAgent Developers Blog
Goの構文解析に入門してみる - Qiita
Goで実装するAppStoreの返金検知システム | QualiArtsエンジニアブログ
Secure Randomness in Go 1.22 - The Go Programming Language