Go プログラミング言語仕様 本文書は，The Go Programming Language Specification version 2021/02/10 のなんちゃって日本語訳である． 原文ソース：https://github.com/golang/go/blob/master/doc/go_spec.html 訳文ソース：https://github.com/hiwane/gospec-ja．誤訳・誤字脱字などは issue かプルリクで https://hiwane.github.io/gospec-ja/ 訳注 valid/invalid は有効/無効, legal/illegal は正当/不当と訳す． letter と character を区別するため，letter は英字，character は文字と訳す． signed/unsigned 符号付き，符号なし sourc
1ticker := time.NewTicker(500 * time.Millisecond) 2done := make(chan bool) 3go func() { 4 5 6select { 7case t := <-ticker.C: 8fmt.Println("Tick at", t) 9case <-done: 10return 11} 12} 13 14 15time.Sleep(1600 * time.Millisecond) 16ticker.Stop() 17done <- true 18fmt.Println("Ticker stopped") 19 20 21 22 23if done { 24time.Sleep(10000 * time.Millisecond) Built for macOS Chime was designed to be a mode
概要 developers.cyberagent.co.jp こちらで 課金システムをマイクロサービス化した サービス自体の設計をDDDにした という対応をしました。 当時は試行錯誤の連続でしたが対応から１年程経ち、ある程度設計もfixされてきたので知見をまとめます。 知見 前提 Clean Architectureの図は多くの人が目にしているように以下の通りです。 今回話す内容は青色の部分を除いた ドメイン層：黄色の部分 ユースケース層：赤色の部分 インタフェース層：緑色の部分 です。 ディレクトリ構成 goのリポジトリの構成は以下のようにしています。 . ├── Dockerfile ├── Makefile ├── README.md ├── cmd/ ├── codes/ ├── config/ ├── docker-compose.yml ├── domain/ ├── go.m
tl;dr go/types パッケージがめちゃくちゃ便利 https://golang.org/pkg/go/types/ https://github.com/golang/example/tree/master/gotypes gouml の紹介 Goのコードを静的解析し、PlantUMLのコードを吐くパーサを開発している。 github.com 例えばGo言語で書かれたこのソースファイルを渡すと、 package main type Human struct { Name string Age Age } type Age int func (a Age) IsAdult() bool { return a >= 20 } 以下のような PlantUML コードが生成される。 package "main" { class "Age" as main.Age <<V,Orchid>>
var ErrUserNotFound = NewApplicationError("Error", 101, "not found") func NewApplicationError(level string, code int, msg string) *ApplicationError { err := &ApplicationError{ level: level, code: code, msg: msg, } return err } func main() error { user, err := userSearch() if err != nil { // return ErrUserNotFound ではなく以下のようにしたいが、複数のエラーのラップには対応していない return xerrors.Errorf(": %w: %w", ErrUserNotFound,
私がWebアプリケーションを実装するうえのエラー設計をどのようにアーキテクチャの中で実現しているかを紹介します。 以下の方針で設計しています。 アプリケーション層にレベルを付与したエラーを定義する アプリケーション層では、定義したエラーに変換する ミドルウェアは全アプリケーション共通にする 以下、サンプルコードです。 サンプルのため省略していますが、実際にはパッケージ分割やファイル分割をしています。 package main import ( "fmt" "os" "golang.org/x/xerrors" ) var ErrUnknown = &ApplicationError{ code: 100, level: "Error", msg: "unknown", } var ErrUserNotFound = &ApplicationError{ code: 101, level:
Mercari Advent Calendar 2018 の16日目はメルペイ エキスパートチームの@tenntenn お送りします。 この記事では、Goの静的解析の新しいムーブメントであるgolang.org/x/tools/go/analysisを使ったモジュール化について解説したいと思います。 「静的解析は関係ないや」と思って、タイトルを見てブラウザのタブを閉じようと思ったかもしれませんが、ほとんどのGopherには無関係ではないと思いますので、ぐっと我慢してしばらく間お付き合いください。 静的解析のモジュール化とは Goにはgo vetやgolintなど静的解析ツールが多数あります。 静的解析ツールを用いることで、プログラムを実行せずにバグになりうる箇所を検出することができます。 実際に、コードレビューを行う際にCIで静的解析ツールを実行している方も多いかと思います。 Goは標準で
Loading search index… No recent searches No results for "Query here"
Single-Page Applications (SPAs) improve user experience by offering rich UI interactions, fast feedback, and the relief of knowing you don’t need to download and install a traditional application. Browsers are now operating systems and websites are apps. While a SPA isn’t always the answer, for apps that rely on snappy user interaction they are increasingly common. To the end user, a well-designed
こんにちは、Wantedly Visitのサーバーサイドエンジニアの一條（Github: @rerost Twitter: @hazumirr）です。 みなさん、The Go Playgroundを使ってますか？ 僕は元々Railsエンジニアだったのですが、ここ最近ずっとGoを書いています。元々Goを書いていていたわけではないので、Goの動作の確認などのために、Playgroundをよく使っています。 これは非常に良くて、Railsではrails c�でコードを試していたように、PlaygroundでGoのコードを試すことができます。 ただ、Playgroundでは外部パッケージが使えず、ちょっとした動作確認などができませんでした。他のGolangエンジニアにざっくり解決策を聞いてみたところ 試すためのレポジトリを作ってしまうそのパッケージ用のテストを書く（書いたテストはすぐ捨てられるよう
The content of this page hasn't been updated for years and might refer to discontinued products and projects. At Banzai Cloud we are building a feature rich enterprise-grade application platform, built for containers on top of Kubernetes, called Pipeline. The platform itself consists of many building blocks - over 30 components - but they share one commonality: they are all developed in Golang. Ob
わかりましたか？よくわかりませんよね？まあ、godocとgo docは同じドキュメントツールですが、別のツールです。本家と元祖みたいなものとして、長らく平行で提供されてきました。ちょうどこの記事を書いている少し前にリリースされた1.11で、godocの方がウェブだけになるとリリースノートに書かれました。 また、godoc.orgのサーバーはローカルのgodocコマンドよりも機能が増えていたり、テンプレートが微妙に違ったりします。とはいえ、ドキュメントを書くときはこれらの違いはそこまで気にすることはありません。 2020/09/19追記: 現在はpkg.go.devが稼働を開始し、godoc.orgのページにアクセスするとこちらへのリダイレクトをするかどうかを問い合わせるバナーが出ます。将来的にはこちらに一本化されると思います。開発者が行うべきこと、記述すべきことは差はありません。このドキュ
はじめに メルペイ エキスパートチームのtenntennです。 メルカリグループでは、毎週金曜日にGo Fridayという社内勉強会を開催しています。 毎週やっているとそれなりに知見が溜まってくるので、定期的に”こぼれ話”としてブログを書こうという話になりました。 今回の記事では、先日のGo Fridayで話題にあがった非公開な機能を使ったテストについて扱いたいと思います。 なお、Goにおけるテストの手法やテストしやすいコードの書き方については、GopherCon 2017でも発表があったmitchellhさんの”Advanced Testing with Go”(スライド/動画)が参考になります。テーブル駆動テストやテストヘルパーなど非常に勉強になるので、まだ見たことのない方はぜひスライドや動画をご覧ください。 TL;DR Goのテストではテスト対象とテストコードを別パッケージにできる
はじめに# 最近 Rust に興味が湧いて少しずつ触ってみています。学習用に何かガッツリと取り組める題材が欲しいなぁと思い、Writing An Interpreter In Go という本にある Monkey というプログラミング言語の Go 実装を Rust で書き直す、ということをやってみました。 そして、Rust で書き直しただけでは少し物足りない感じがしたので、先の本には登場していない要素として Formatter 及び、wasm32-unknown-unknown をターゲットに Wasm へコンパイルしブラウザで動作させるところまで実装しました。 ちなみに Writing An Interpreter In Go は、既に様々な方が読まれているような有名な本なので特別紹介はしませんが、かなりの良書なので「読んだことない！」という方は是非読んでみると面白いかもしれません。 幾つ
This is the sequel to Writing An Interpreter In Go. We're picking up right where we left off and write a compiler and a virtual machine for Monkey. Runnable and tested code front and center, built from the ground up, step by step — just like before. But this time, we're going to define bytecode, compile Monkey and execute it in our very own virtual machine. It's the next step in Monkey's evolution
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
