I am proud to offer this resource for free, but if you wish to give some appreciation
Rust is becoming a first class language in a variety of domains. At Discord, we’ve seen success with Rust on the client side and server side. For example, we use it on the client side for our video encoding pipeline for Go Live and on the server side for Elixir NIFs. Most recently, we drastically improved the performance of a service by switching its implementation from Go to Rust. This post expla
Created from gopherize.me base imagesThere are many cases when Go code works with different HTTP APIs or as HTTP API service. One of the standard usage in this case: we got some struct from database, send it to external API, get struct in response with different values, convert it and store to database. As other words: we don’t do many processing operations in such cases with request and response
Today I’m going to dive into the expressive power of Go channels and the select statement. To demonstrate how much can be implemented with just those two primitives I will rewrite the sync package from scratch. In doing so I’m just going to accept some compromises: This post is about expressive power, not speed. The examples will correctly express the primitives but might not be as fast as the rea
はじめに Goにおける抽象化の方法にインターフェースがあります。インタフェースをうまく使うことにより具体的な実装を隠し、疎結合な実装ができるようになります。 これにより、テストがやりやすくなったり、リファクタリングの影響範囲を小さくできるなどのメリットがあります。インターフェースがないコードは振る舞いで共通化することができないため、冗長かつ密結合なシステムになってしまいます。 今回はGoのインターフェースの基本的な考え方である "Accept interfaces, Return structs" について紹介します。 "Accept interfaces, Return structs" とは 直訳で 「インターフェースを受け入れて、構造体を返す」 ですが、この考え方はJack Lindamood氏が過去に提案したものです。 GoのCodeReviewのドキュメントには以下のように書かれ
DB接続を含むテストはツライ テスト用のデータをテストケースごとに用意しないといけない。 DBの変更結果が他のテストケースに影響を与えないようにリセットしないといけない。 DBへの変更が他のテストケースに影響を与えるので並列実行できない。 DATA-DOG/go-txdbを使うと改善できる DATA-DOG/go-txdb で生成することのできるDBコネクションには↓のような特徴があります。 sql.DBと互換性がある。 すべてのクエリが独立したトランザクション内で実行される。 .Close()を呼ぶとそのトランザクション内で実行されたクエリがすべてRollbackされる。 これをうまく使うと、テストケースごとに独立したトランザクション内でクエリを実行することができ、テスト終了後にDB変更がRollbackされるので、テストケースごとのデータ処理が必要なくなり、他のテストケースへの影響もな
2020/08/15更新: 「テストの失敗をレポートしたい」と「サブテストの一部のみ実施したい」の章を追加 はじめにTIG の辻です。今回は春の入門祭りということで Go のテストに入門してみよう!という記事です。 書いた背景ですが Go の標準ライブラリのコードリーディング会で testing パッケージにチャレンジしてみましたが、難しすぎてわからん。そもそも Go のテストって何ができるんだっけ?という話になり、基本的な内容をなるべく具体例をまじえながらまとめました。 ざっとどんなことができるんだろう、という index になれば幸いです。 TipsGo に組み込まれているテストの仕組みの中に、ベンチマークに関するテストと Example テストというサンプルコード用のテストも含まれているのですが、この 2 つは対象外にします。基礎的と思われる内容から順に並べてみました。 はじめに T
2017 06 09 tl;dr: magic is bad; global state is magic → no package level vars; no func init The single best property of Go is that it is basically non-magical. With very few exceptions, a straight-line reading of Go code leaves no ambiguity about definitions, dependency relationships, or runtime behavior. This makes Go relatively easy to read, which in turn makes it relatively easy to maintain, wh
Intro この記事は Go Advent Calendar 2014 の 15 日目の記事です。 例えばネットワークのフレーム処理的なものを書いている場合、以下のようなコードがよくでてきます。 There are many codes like this, while writing a Network Frame Parser program. var type uint8 err = binary.Read(r, binary.BigEndian, &type) if err != nil { return err } var length uint32 err = binary.Read(r, binary.BigEndian, &length) if err != nil { return err } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く