Goのインターフェース抽象度を美しく保つ為の思考 - 好奇心に殺される。
Go Goのインターフェース抽象度を美しく保つ為の思考 Goで抽象化を適切に、そして美しく保つ為の自分の考えやTipsを紹介します。 Overview とある場面でGoのinterfaceが持つ振る舞いの抽象度について議論があり、今回はそれをアウトプットしておきます。Go初心者でinterfaceを使った設計に苦手意識を持つ人向けです。 目次 今回の目次です！下記について自分の考えをお話しします！ 振る舞いの抽象化の度合いを意識する 抽象度をどこまであげるか 引数や返り値から発生する「抽象化の漏れ」 抽象度をあげる為の統合 Getter/Setterと抽象度 それではいってみましょう！ 振る舞いの抽象化の度合いを意識する 振る舞いをinterfaceとして定義していくのがGoの抽象化ですが、そもそも 抽象化は度合いのある概念です 。この度合いを意識しないと適切なinterfaceの設計は困
なぜ Go では何百万もの Goroutine を作れるのに Java は数千のスレッドしか作れないのか?
なぜ Go では何百万もの Goroutine を作れるのに Java は数千のスレッドしか作れないのか? (この記事は Why you can have millions of Goroutines but only thousands of Java Threads の翻訳です) 経験のあるエンジニアならば JVM 言語で次のようなエラーを見たことがあるでしょう。 [error] (run-main-0) java.lang.OutOfMemoryError: unable to create native thread: [error] java.lang.OutOfMemoryError: unable to create native thread: [error] at java.base/java.lang.Thread.start0(Native Method) [erro
Goで真面目にerror handlingと向き合ってみた - Tech Do | メディアドゥの技術ブログ
The Go gopher was designed by Renée French and has a CC BY 3.0 license. メディアドゥでエンジニアをしております、武田です。 弊社では新規サービスのプロダクトをGoで開発しているのですが、必ずと言っていいほど世のGopherたちが頭を悩ませるエラーハンドリングについて、一旦方針を考えてみたので記事にまとめてみました。 きっかけ 新規サービス開発もある程度進み、staging環境で検証を進めようと思いAPIを叩いたところ… { "code": "", "message": "Table Hoge.hoge doesn't exist" } という如何ともしがたいメッセージと出くわしてしまいました。これでは全くトラブル対応ができない… 今まで目を瞑っていたけれど、 ちゃんとエラーハンドリングやろう！ 解決課題の設定 Erro
Go1.17beta1でGenericsに触れてみた - oinume journal
Go1.17beta1がダウンロードできるようになったので、Generics(Type Parameters)でStackを書いて軽く遊んだメモ。 Generics (Type Parameters)について 最新の仕様のProposalは以下を見ると良い。 実際にどんな感じのコードになるのかは、GitHubのdev.typeparams branchのコードを見ると良さそう。 Go1.17beta1のダウンロード 普段使っているgoコマンドから以下のようにGo1.17beta1をダウンロードできる。 $ go get golang.org/dl/go1.17beta1 $ go1.17beta1 download これで ~/sdk/go1.17beta1 にインストールされる。 FYI: Goは標準の機能で複数のバージョンをインストールできる。より詳しくは以下のドキュメントを読むと良い
GoのWebアプリケーションでステータスコード499を記録する | おそらくはそれさえも平凡な日々
この記事は、Go 4 Advent Calendar 2020の16日目の記事です。 さて、ある日、Goで書かれたHTTP APIサーバーのdeployをしたところ、急に500エラーの発生率が上がったことがありました。しかし幸いにもユーザー影響は出ていません。どうしたのでしょうか？ ALBログの調査 このシステムはAWSのApplication Load Balancer(ALB)からプロキシされていますが、エラーリクエストに対応するALBのログを調べるとステータスコード460が記録されていました。460を調べると以下のように書いてあります。 The load balancer received a request from a client, but the client closed the connection with the load balancer before the id
まさかPushデバッグしてないよね？ よく使うCircleCIのデバッグ方法 - VTRyo Blog
Pushデバッグってなんぞ？ 〜1年前〜 CircleCIド素人ぼく 「CircleCI configに記述したコードがうまく動かないな……でもGithubにPushして、CircleCIが動いてるところ見ないとわからん……」 などど言い出し、何度もPushしまくってcommitを荒らしたのは私です。 そんな一か八か、動くかわからないコードをPushしまくるのはやめていきたいものです。 CircleCI CLIをインストール Linux, macOS Homebrew ローカルで確認する configtest Job実行 ちょっとした注意点 You attempted to run a local build with version '2.1' of configuration. SSHする 参考 CircleCI CLIをインストール インストール方法はそこまで大変でないので、公式に書
GoでYAMLを扱うすべての人を幸せにするべく、ライブラリをスクラッチから書いた話 - Qiita
この投稿は、 Go アドベントカレンダーの 6日目のものになります。 はじめに GoでYAMLを扱う際にデファクトになっているのは、おそらく github.com/go-yaml/yaml でしょう。 実装はC言語で実装された libyaml を Go に移植しつつ、 Go ならではの機能を足す作りになっているのですが、 cgo を使わずに pure Go で移植されており、開発者の気合を感じます。 枯れている libyaml を利用していることからも、 YAML の仕様を忠実に実装していることが期待できます。 ですが、このライブラリにはいくつか使いにくい点もあり、例えば以下のようなことはできませんでした 構造体を埋め込む場合に、埋め込む型をポインタで定義できない ( ※ ポインタなしは大丈夫 ) encoding/json とコンパチの インターフェース ( MarshalYAML()
Golangのエラーハンドリングの基本 - Qiita
想定している読者 Goのエラーハンドリングについて体系だった記事が見つからなかったので、色々調べたことを整理して備忘録も兼ねて記事にしました。 以下のような方を読者対象に記事を書いています。 Goのエラーハンドリングの基本的なやり方を知りたい スタックトレースを標準エラー出力したい エラーの種類に応じてステータスコードを変えたい まずデファクトになっているエラーパッケージpkg/errorsの使い方を確認して、実際のWebアプリケーションで追加で実装しないといけないことを説明していきます。 そもそもerrorとは？ goのエラーは以下のようなエラーメッセージを返す関数を実装していれば満たせるインターフェースです。 // cf. https://golang.org/pkg/builtin/#error type error interface { Error() string } 実際には
「例外を投げない」という選択肢をとる言語 - Qiita
新しめの言語では例外を投げることを推奨しない言語が出てきているように思えるが、そうした言語が例外をどう考え、例外の代わりにどのようなアプローチを奨励しているかを調べてみた。 本稿での「例外」とは、Javaのthrow構文のようにスコープを脱出してcatchされるまでエスカレートされる「投げる例外」のことを指し、エラーを表現したオブジェクト(エラーオブジェクト)については「例外オブジェクト」と呼び区別するものとする。(この2つを同一に扱うと、例外を使わないということは、エラーオブジェクトは使わないの？という話になるため) Go言語 - 例外はコードを複雑にする Go言語では、通常、エラーは戻り値として扱われる。(本当の本当に例外的なエラーのためにpanic, recoverがあるが、ほとんど使われることがないように見受けられる。) 例外がないGoでは、どう呼び出し元にエラーを伝えているかとい
Goのカスタムエラーとその自動生成について - asterisc
はじめに この記事はGo2アドベントカレンダー14日目の記事です。 GoのErrorハンドリングについては、これまでにも様々なパターンが発表されてきました。 今回は独自定義のエラーについて、これまでのパターンをまとめた上で、その実現をeasyにするgenerrというツールを作ったので、その紹介をします。 github.com Goのカスタムエラー Goのエラーハンドリングの中で、カスタムなerror型を用いるパターンは比較的広く知られているかと思います。 その中からいくつかのパターンを紹介します。 sentinel errorsパターン Goのerrorはinterfaceとして定義されており、Error() stringのメソッドを実装さえしていれば、errorとして扱うことができます。 標準パッケージで提供されているerrorsやfmt.Errorfを用いて簡単にエラーを表現することが
Go Fridayこぼれ話：非公開（unexported）な機能を使ったテスト #golang | メルカリエンジニアリング
はじめに メルペイ エキスパートチームのtenntennです。 メルカリグループでは、毎週金曜日にGo Fridayという社内勉強会を開催しています。 毎週やっているとそれなりに知見が溜まってくるので、定期的に”こぼれ話”としてブログを書こうという話になりました。 今回の記事では、先日のGo Fridayで話題にあがった非公開な機能を使ったテストについて扱いたいと思います。 なお、Goにおけるテストの手法やテストしやすいコードの書き方については、GopherCon 2017でも発表があったmitchellhさんの”Advanced Testing with Go”(スライド/動画)が参考になります。テーブル駆動テストやテストヘルパーなど非常に勉強になるので、まだ見たことのない方はぜひスライドや動画をご覧ください。 TL;DR Goのテストではテスト対象とテストコードを別パッケージにできる
Goでchannelがcloseしてるかどうか知りたい というアンチパターン
そういえば金沢に行って来た話の2〜4日目をかいてる途中で2ヶ月くらい経ったことに気付きましたが、まぁその話はおいておいて今日はGoの話です。 さて、このタイトルを見てGoに詳しく賢明な読者の方々は「あぁまたこの話題だよ、Goでchannelがcloseしてるかどうか知りたいようなパターンはだいたい書いてるアプリの設計とかchannelの使い方が間違ってるんだからやめとけ」と眉をひそめるかもしれません。まぁちょっとまって! オレもそうなんじゃないかなぁという気はしているし、ハマリどころがありそうということはうすうす分かってるけど一応調べて考えてみてもいいじゃないか。 結局の所調べて「こうすればいいね!」ってことは分かったんですが、それも破綻する場合があるので、アンチパターンだなぁと思いつつこの記事を書くことにしました。 まずGoのchannelのナイーブさを再確認する そもそもGoのchan
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go1.13以後のエラーハンドリングについて語ろう / Let's talk about error handling after Go 1 13