Note #62 GopherCon Russia 2020
Мои старые друзья 28 марта проводят GopherCon Russia 2020! В этому году у меня не получается поехать :(
Но! У меня есть 1 билет, который я подарю тому, кто первый напишет в чате канала(кнопка discuss), как придумали название известной консольной утилиты “grep”?
Удачи :)
P.S. подробности и регистрация на сайте: https://www.gophercon-russia.ru/
Мои старые друзья 28 марта проводят GopherCon Russia 2020! В этому году у меня не получается поехать :(
Но! У меня есть 1 билет, который я подарю тому, кто первый напишет в чате канала(кнопка discuss), как придумали название известной консольной утилиты “grep”?
Удачи :)
P.S. подробности и регистрация на сайте: https://www.gophercon-russia.ru/
Note #63 A new Go API for Protocol Buffers
В официальном #golang блоге появилась статья про новый Go API для Protocol Buffers.
Рекомендую почитать! ->
https://blog.golang.org/a-new-go-api-for-protocol-buffers
В официальном #golang блоге появилась статья про новый Go API для Protocol Buffers.
Рекомендую почитать! ->
https://blog.golang.org/a-new-go-api-for-protocol-buffers
go.dev
A new Go API for Protocol Buffers - The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Note #64 New net/url.URL.Redacted method in go 1.15
В Go1.15 появится удобный метод
Links:
[1] https://go-review.googlesource.com/c/go/+/207082/
В Go1.15 появится удобный метод
net/url.URL.Redacted
[1], по сути, похож на url.URL.String()
, только заменяет пароли на xxxxxxx
, будет удобно для логирования:package main
import (
"fmt"
"net/url"
)
func main() {
u := &url.URL{
Scheme: "https",
User: url.UserPassword("user", "password"),
Host: "example.com",
Path: "foo/bar",
}
fmt.Println(u.Redacted())
u.User = url.UserPassword("me", "newerPassword")
fmt.Println(u.Redacted())
}
// gotip run main.go
// https://user:[email protected]/foo/bar
// https://me:[email protected]/foo/bar
Links:
[1] https://go-review.googlesource.com/c/go/+/207082/
Note #65: новые темплейты в Go плайграунде!
* тесты
* поддержка нескольких файлов включая go.mod!
* можно напечатать картинку
https://play.golang.org
* тесты
* поддержка нескольких файлов включая go.mod!
* можно напечатать картинку
https://play.golang.org
Note #66: Go плайграунд теперь исполняет код в multi-threaded linux контейнере
Если у вас есть необходимость в демонстрации многопоточного кода на Go, который использует несколько горутин и которые, в свою очередь, используют один поток (thread) операционной системы или несколько потоков (threads), которые используют разные ядра. В общем теперь можно изучать go параллелизм в плайграунде 🙌
P.S. объяснение от Брэда Фицпатрика:
Это стало возможным после того, как удалили поддержку Native Client (GOOS=nacl) в Go 1.14, и теперь go плайграунд запускается с помощью gVisor.
https://github.com/golang/go/issues/25224
https://github.com/golang/playground/commit/4d362417fd14b0b8349150cb28c3e8f2e756932e
Если у вас есть необходимость в демонстрации многопоточного кода на Go, который использует несколько горутин и которые, в свою очередь, используют один поток (thread) операционной системы или несколько потоков (threads), которые используют разные ядра. В общем теперь можно изучать go параллелизм в плайграунде 🙌
package main
import (
"fmt"
"runtime"
)
func main() {
fmt.Printf("GOOS[%s] GOARCH[%s] GOMAXPROCS[%d] NumCPU[%d]", runtime.GOOS, runtime.GOARCH, runtime.GOMAXPROCS(0), runtime.NumCPU())
}
// OOS[linux] GOARCH[amd64] GOMAXPROCS[8] NumCPU[8]
P.S. объяснение от Брэда Фицпатрика:
Это стало возможным после того, как удалили поддержку Native Client (GOOS=nacl) в Go 1.14, и теперь go плайграунд запускается с помощью gVisor.
https://github.com/golang/go/issues/25224
https://github.com/golang/playground/commit/4d362417fd14b0b8349150cb28c3e8f2e756932e
Note #67 What's coming in Go 1.15
Daniel Martí aka @mvdan_ недавно выступал на онлайн конференции "Go Remote Fest" с докладом: "What's coming in Go 1.15"!
Слайды его доклада можно найти по ссылке [1] или
Top 5 изменений:
- slightly smaller binaries (0.2% но все же =)
- new linker (еще WIP но можно ужно читать/смотреть [2]
- embed tzdata with time/tzdata https://github.com/golang/go/issues/38017
- add testing.TB.TempDir https://github.com/golang/go/issues/35998
- add testing.T.Deadline https://github.com/golang/go/issues/28135
Links:
- [1] https://docs.google.com/presentation/d/1veyF0y6Ynr6AFzd9gXi4foaURlgbMxM-tmB4StDrdAM/edit#slide=id.g840eaeb4b4_0_99
- [2] https://docs.google.com/document/d/1D13QhciikbdLtaI67U6Ble5d_1nsI4befEd6_k1z91U/view
Daniel Martí aka @mvdan_ недавно выступал на онлайн конференции "Go Remote Fest" с докладом: "What's coming in Go 1.15"!
Слайды его доклада можно найти по ссылке [1] или
Top 5 изменений:
- slightly smaller binaries (0.2% но все же =)
- new linker (еще WIP но можно ужно читать/смотреть [2]
- embed tzdata with time/tzdata https://github.com/golang/go/issues/38017
- add testing.TB.TempDir https://github.com/golang/go/issues/35998
- add testing.T.Deadline https://github.com/golang/go/issues/28135
Links:
- [1] https://docs.google.com/presentation/d/1veyF0y6Ynr6AFzd9gXi4foaURlgbMxM-tmB4StDrdAM/edit#slide=id.g840eaeb4b4_0_99
- [2] https://docs.google.com/document/d/1D13QhciikbdLtaI67U6Ble5d_1nsI4befEd6_k1z91U/view
GitHub
time: add time/tzdata package and timetzdata tag to embed tzdata in program · Issue #38017 · golang/go
Go programs currently rely on the system to provide timezone information in the tzdata database, or rely on GOROOT being accessible at run time in order to read $GOROOT/lib/timezoneinfo.zip. This i...
Note #68: The Rules of Optimization Club
1. You do not optimize.
2. You do not optimize, without measuring first.
3. When the performance is not bound by the code, but by external factors, the optimization is over.
4. Only optimize code that already has full unit test coverage.
5. One factor at a time.
6. No unresolved bugs, no schedule pressure.
7. Testing will go on as long as it has to.
8. If this is your first night at Optimization Club, you have to write a test case.
from https://wiki.c2.com/?RulesOfOptimizationClub
1. You do not optimize.
2. You do not optimize, without measuring first.
3. When the performance is not bound by the code, but by external factors, the optimization is over.
4. Only optimize code that already has full unit test coverage.
5. One factor at a time.
6. No unresolved bugs, no schedule pressure.
7. Testing will go on as long as it has to.
8. If this is your first night at Optimization Club, you have to write a test case.
from https://wiki.c2.com/?RulesOfOptimizationClub
Note #69: Debugging concurrency programs in Go
Slides of my talk: "Debugging concurrency programs in Go" from @GoWayFest
https://bit.ly/2C0vJOG
Slides of my talk: "Debugging concurrency programs in Go" from @GoWayFest
https://bit.ly/2C0vJOG
Note #70: eBPF and golang
Extended BPF has a new homepage: https://ebpf.io #bpf #ebpf 🎉
Extra links:
- go binding for bcc tools https://github.com/iovisor/gobpf
- interesting article from Brendan Greg about golang bcc/BPF function tracing http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html
Extended BPF has a new homepage: https://ebpf.io #bpf #ebpf 🎉
Extra links:
- go binding for bcc tools https://github.com/iovisor/gobpf
- interesting article from Brendan Greg about golang bcc/BPF function tracing http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html
GitHub
GitHub - iovisor/gobpf: Go bindings for creating BPF programs.
Go bindings for creating BPF programs. Contribute to iovisor/gobpf development by creating an account on GitHub.
Cloud native BPF Workshop:
GH Repo: https://github.com/kinvolk/cloud-native-bpf-workshop
Slides: -> https://github.com/kinvolk/cloud-native-bpf-workshop/blob/master/slides.pdf
GH Repo: https://github.com/kinvolk/cloud-native-bpf-workshop
Slides: -> https://github.com/kinvolk/cloud-native-bpf-workshop/blob/master/slides.pdf
GitHub
GitHub - kinvolk/cloud-native-bpf-workshop
Contribute to kinvolk/cloud-native-bpf-workshop development by creating an account on GitHub.
TIL: go get -x
If you need to run
But we can run -x to show debug info TBH print the commands get eXecutes:
P.S.
If you need to run
go get
with debug info, it can surprise you because there is no -v
or —verbose
flag.But we can run -x to show debug info TBH print the commands get eXecutes:
go get -x -u github.com/gliderlabs/ssh
P.S.
-x
also works with go mod
.Note #71 The seven rules of a great Git commit message
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
https://chris.beams.io/posts/git-commit/
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
https://chris.beams.io/posts/git-commit/
Note #72 TestMain in Go 1.15 testing package no longer calls os.Exit
tl;dr
- Go1.15 has been released
- Changed the implementation of the testing package so that TestMain no longer calls os.Exit
- It is realized by changing the implementation of testing.M and modifying the template of the main function generated by go test.
Found interesting article with great examples of changes between 1.14 and 1.15 -> https://qiita.com/hgsgtk/items/40e63150affed01f6573
TIP: right click translate into English.
tl;dr
- Go1.15 has been released
- Changed the implementation of the testing package so that TestMain no longer calls os.Exit
- It is realized by changing the implementation of testing.M and modifying the template of the main function generated by go test.
Found interesting article with great examples of changes between 1.14 and 1.15 -> https://qiita.com/hgsgtk/items/40e63150affed01f6573
TIP: right click translate into English.
Qiita
Go 1.15 testing パッケージの TestMain は os.Exit を呼ばなくてよくなった - Qiita
TL;DR
Go1.15 がリリースされました
testing パッケージの実装の変更にて TestMain で os.Exit を呼ばなくてよくなりました
testing.M の実装変更及び、 go test で生成される ...
Go1.15 がリリースされました
testing パッケージの実装の変更にて TestMain で os.Exit を呼ばなくてよくなりました
testing.M の実装変更及び、 go test で生成される ...
Визуализация нового пропозала про дженерики с отличными примерами от Владимир Вивьен
https://twitter.com/vladimirvivien/status/1297595414590427142?s=21
https://twitter.com/vladimirvivien/status/1297595414590427142?s=21
Twitter
Vladimir Vivien
The #golang proposal to introduce generic functions and types (via parametric polymorphism) has been evolving nicely. This 🧵 summarizes what the latest is: - [] sqr brackets to be used for type param - type param must have a constraint - constraint `any`…
TIL: that "fallthrough" ignors the next "case" condition.
This code will print "one" and "two".
source https://twitter.com/yoavgo/status/1315622694554140673
P.S. я уже когда-то писал об этом тут https://yangx.top/golang_for_two/53
This code will print "one" and "two".
package main
import (
"fmt"
)
func main() {
a := 10
switch {
case a < 20:
fmt.Println("one")
fallthrough
case a < 10:
fmt.Println("two")
}
}
source https://twitter.com/yoavgo/status/1315622694554140673
P.S. я уже когда-то писал об этом тут https://yangx.top/golang_for_two/53
Twitter
(((ل()(ل() 'yoav))))
@tebeka מדהים איך פרטי מימוש של פטרן באסמבלי התגלגלו ככה לפיצ׳רים בשפות מודרניות.
Init time tracing coming to Go 1.16
GODEBUG=inittrace=1 prints a summary of execution time and memory allocation
information for completed package initialization work.
https://github.com/golang/go/commit/7c58ef732efd9bf0d0882bb95371ce1909924a75
GODEBUG=inittrace=1 prints a summary of execution time and memory allocation
information for completed package initialization work.
https://github.com/golang/go/commit/7c58ef732efd9bf0d0882bb95371ce1909924a75
GitHub
runtime: implement GODEBUG=inittrace=1 support · golang/go@7c58ef7
Setting inittrace=1 causes the runtime to emit a single line to standard error for
each package with init work, summarizing the execution time and memory allocation.
The emitted debug information ...
each package with init work, summarizing the execution time and memory allocation.
The emitted debug information ...
Experimental refactoring tool for Go from Russ Cox
no docs, but few interesting examples https://github.com/rsc/rf/tree/main/testdata
https://github.com/rsc/rf
no docs, but few interesting examples https://github.com/rsc/rf/tree/main/testdata
https://github.com/rsc/rf
GitHub
rf/testdata at main · rsc/rf
A refactoring tool for Go. Contribute to rsc/rf development by creating an account on GitHub.
Подъехали видео с последнего GopherCon 2020
https://www.youtube.com/playlist?list=PL2ntRZ1ySWBfUint2hCE1JRxRWChloasB
Пишите в комментариях какой больше всего доклад понравился?
https://www.youtube.com/playlist?list=PL2ntRZ1ySWBfUint2hCE1JRxRWChloasB
Пишите в комментариях какой больше всего доклад понравился?
YouTube
GopherCon 2020 - YouTube
My engineering axioms by Martin Rue:
1. Change is constant.
2. Your product is an asset, but code is a liability.
3. Duplication is less costly than premature abstraction.
4. Code should be easy to delete.
5. Existing code exerts a powerful influence.
6. Accidental complexity is one of the biggest risks.
7. Technical excellence can be shadowed by bad personal skills.
8. You are not your code. Be kind to the coder, not to the code.
9. Treat people who know less than you with respect and patience.
10. The only true authority stems from knowledge, not from position.
11. Teaching is a form of learning in disguise.
12. Lift the skills of people around you, not just yourself.
13. The longer you wait the more you'll know.
14. A good type system is worth its weight plus some.
15. The right team of people trumps everything else.
16. Stick to boring technology, unless there's a good reason not to.
17. Have the smallest team possible, but no smaller. Grow it carefully.
18. Rest.
19. Don't pick a solution until you've thought of at least one more.
20. Have opinions, but avoid expressing them in ways that cause other people to believe you won't change them.
21. It's OK to say "I don't know" or "I need to research that before I have an answer".
22. Writing throwaway code to explore a problem space is underrated.
23. Manage state carefully.
24. It's all about trade-offs.
25. A good design is one in which you can change your mind without changing too much code.
https://martinrue.com/my-engineering-axioms/
1. Change is constant.
2. Your product is an asset, but code is a liability.
3. Duplication is less costly than premature abstraction.
4. Code should be easy to delete.
5. Existing code exerts a powerful influence.
6. Accidental complexity is one of the biggest risks.
7. Technical excellence can be shadowed by bad personal skills.
8. You are not your code. Be kind to the coder, not to the code.
9. Treat people who know less than you with respect and patience.
10. The only true authority stems from knowledge, not from position.
11. Teaching is a form of learning in disguise.
12. Lift the skills of people around you, not just yourself.
13. The longer you wait the more you'll know.
14. A good type system is worth its weight plus some.
15. The right team of people trumps everything else.
16. Stick to boring technology, unless there's a good reason not to.
17. Have the smallest team possible, but no smaller. Grow it carefully.
18. Rest.
19. Don't pick a solution until you've thought of at least one more.
20. Have opinions, but avoid expressing them in ways that cause other people to believe you won't change them.
21. It's OK to say "I don't know" or "I need to research that before I have an answer".
22. Writing throwaway code to explore a problem space is underrated.
23. Manage state carefully.
24. It's all about trade-offs.
25. A good design is one in which you can change your mind without changing too much code.
https://martinrue.com/my-engineering-axioms/
Martinrue
My Engineering Axioms
A few months back I gave a talk in which I shared a list of my personal engineering axioms – things that, over the years, I've come to think of as generally true and useful to have in mind when writing code, building things, and working with others.