A sampling Go profiler that allows you to analyze On-CPU as well as Off-CPU (e.g. I/O) time together.

https://github.com/felixge/fgprof by twitter.com/felixge

And it's literally under 100 lines! Amazing!

Такие дела https://twitter.com/dhh/status/1275901955995385856

Какой хороший бенчмарк. Наверное. В общем меня привлёк 3й участник, да, на V lang, который я без стеснения называл скамом.

Как можно догадаться, если глянуть в код, то можно увидеть, как быстро работает echo на вашем epoll/kqueue https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/V/pico.v/main.v и https://github.com/S-YOU/picoev.v

Вопрос, зачем это бенчить оставлю открытым. Если пролистать (сильно) ниже, можно найти Go с роутером chi, выдающий "жалкие" 240к рпс. Что вполне себе хороший результат. Написано без пуллов и прочей магии, простое как палка.

Вещь конечно прикольная, но эхами меряться лучше не на публику.

Результаты конечно же https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=json

Маленькая ода для sync.Once в #go

А именно. Часто можно встретить какую-то операцию, которую нужно и можно сделать 1 раз. Это может быть и закрытие соединения в каком-то клиенте и часто инициализация каких-то вещей.

Так как многим хочется эти вещи еще и в разных горутинах дергать, приходится добавлять какие-то синхронизации. Конечно же проще всего бахнуть Mutex и забыть о проблемах, некоторые чуть изощряются и делают на каналах, на атомиках тоже, но ведь уже есть простое решение - sync.Once !

Это буквально 3 инта (мютекс 2 32битных содержит https://github.com/golang/go/blob/go1.14.4/src/sync/once.go#L18 опустим вопрос кешлиний и прочих веселостей) и на этом вся логика заканчивается. Самое главное, как по мне, что это заметно лучше читается:
- ты видишь sync.Once
- ты знаешь, что он выполнится 1 раз
- ты знаешь, что по другому его не использовать

Эт круто.

Сюда же добавлю select {} который просто заблочит горутину (часто испоользую в main), поэтому другие решения (через бесконечный цикл, чтение из неиспользуемого канала) по сути не нужны.

Что-то меня прорвало на поговорить, в @generictalks чат всплыла тема дженериков (хах, ирония) и вспомнили sync.Map с его interface{} в параметрах. Вот что посоветую я.

Оборачивайте в свой тип. Вместо обычного поля:

type Foo struct {
    idToUser sync.Map

    idToUser idToUserMap
}

type idToUserMap struct { data sync.Map }
// геттер и сеттер под конкретные типы

Внезапно вы уйдете от явных переходов от interface{} к вашему типу в методе Load, что приятно, лишний раз не ошибетесь с типом (но тесты тоже иметь, окда?). Еще тип подскажет, что же вы там мапите, это полезно.

Это наверное не супер вещь и sync.Map пихать везде не надо, я все же за явный мютекс + мапа, но как помочь другим не тупить над вашим кодом вариант - норм.

Стырю свой твит, короч.

Хороший пост от Дейва о логировании, вот прям за каждый абзац готов дать +

Правда по поводу ненадобности Warn чуть-чуть бы поспорил, но лень, можно и так жить спокойно.

https://dave.cheney.net/2015/11/05/lets-talk-about-logging

Еще про уровни логирования можно читнуть: WakeMeUpInTheMiddleOfTheNight https://divan.dev/posts/wakemeupinthemiddleofthenight/ (уже не раз на канале упоминал, стоит держать в уме).

Ах да, это все language agnostic, поэтому не думайте, что это только для Go, вещи правда полезные озвучены в этих постах.

Хорошо, что всегда можно добавить

'We had no idea how to do it': YouTube's founders, investors, and first employees tell the chaotic inside story of how it rose from failed dating site to $1.65 billion video behemoth

> YouTube's cofounders originally thought "a generic platform where we could host all the videos on the internet" was too bold of an idea. So for about a week, the site was a dating platform — until it wasn't.

> Just about every 48 hours, some emergency came up. When you have a million people watching a video a day, you can't just manually log each view anymore.

https://www.businessinsider.com/youtube-oral-history-early-days-founded-investors-employees-started-google-2020-5

Интересный вопрос на самом деле. Для тех, кто не хочет ответить в твитор, может ответить мне 👀 @olegkovalov

https://twitter.com/davidcrawshaw/status/1277111328155398145

Мы начали, сейчас будем про найм и собесы говорить https://www.youtube.com/watch?v=-r9ybGDh1qc

Я на неделю уйду оффлайн. Лейтенси подпрыгнет до 7 дней. Сорьте.

Позвращаемся к самокопанию в Телеге.

Так вот, на неделе вспомнил одну вещь, что сложные метрики сложно читать (хах, ирония). И особо решения с Прометеусом нет, но оказывается есть.

Авторы VictoriaMetrics ведь сделали свой MetricsQL и там есть оператор WITH (вспоминайте Postgres). Лучше примера уже не объяснить:

WITH (
    f(a, b) = WITH (
        f1(x) = b-x,
        f2(x) = x+x
    ) f1(a)*f2(b)
) f(foo, with(x=bar) x)

https://play.victoriametrics.com/promql/expand-with-exprs

И это очень круто. Тепепь я торчу им аналог пива, как встречу.

Lava Layer Anti-Pattern

<..> resulting in an application with three different data access solutions and different implementations of the same type of function depending on during which generation it was implemented.

https://www.infoq.com/news/2015/01/lava-layer-antipattern/

А все почему? а ведь есть разные способы сделать одну и ту же вещь. Здесь даже не проблема в языке (хотя возможность подстрекать использовать новые вещи), а скорее незаконченные миграции.

Был я в нескольких больших проектах и там как в анекдоте: v1 is deprecated, v2 is experimental.

Пожалуй я сейчас понял, почему некоторые архитекторы бежали в микросервисы: компоненты получались связанны только по http и не было видно дикой разницы между 2мя(и больше) подходами реализации.

Github же завез README для профиля.

Можно глянуть у меня https://github.com/cristaloleg

Надо всего лиш создать репо со своим никнеймом, а дальше обычный markdown. В принципе выходит миленько.

UPD: походу не у всех есть доступ

вот так оно смотрится, проверьте в верхнем-правом углу Feature preview в списке (под авой меню, пункт 4й с конца)

Daniel Marti который завёз много хороших вещей в #go и особенно в encoding/json начал собирать идеи, что можно было бы исправить в v2 этого пакета.

Пока просто набрасывание идей, без каких либо планов, что это будет сделано. Но в любом случае, в ближайшие годы будут исправления и потенциально новое апи, пора, так сказать.

https://docs.google.com/document/d/1WQGoM44HLinH4NGBEv5drGlw5_RNW-GP7DdGEpm7Y3o/edit#

У меня к вам 2 таких вопроса:

1. бекапите ли вы свои данные куда-то?
(читайте как фотки, видосы, документы, пиратскиекниги и тд), если да, то куда и как, почему и почему бросили.

2. организуете ли вы свои знания как-то? закладочки, вырезки статей, самописные документы и всё, что связано с организацией знаний (на днях тут Foam вплыл и стало интересно https://foambubble.github.io/foam/)

Если решите поделиться, то разделите ответ на п1 и п2 (интересен ответ даже на 1 из них) шлите сюда @olegkovalov потом опубликую что-то (мне еще опубликовать про тимлидство и опрос про облако надо...)

хотите кек? это работает