Очень понравилось это репо, о том как собрать свой персональный серверочек. Красиво так по шагам, как собрать фигню без головной боли. SOPS, k3s, wireguard и всякое по мелочи.

В планах есть 1 проект и вот эта штука вполне себе пригодится. Я наверное ток packer бы добавил со своим образом виртуалки и Терраформ (хотя развитие последнего меня напрягает, как-то он сложным становится)

https://github.com/erebe/personal-server

Russ Cox: The freeze is going well, and we are looking ahead to getting large changes ready to merge when the window opens at the start of the release, as we do for all large changes. In the compiler, we are working on two different large changes:

- register ABI work to land at the start of Go 1.17 (Feb 1 2021 work begins, Aug 1 2021 release)
- type parameters work to land at the start of Go 1.18 (Aug 1 2021 work begins, Feb 1 2022 release)

https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0tyIYBAAJ

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md

Добрый вечер

Кто не уловил: "давать" подразумевается давать вот такие фции возле обычных уже провернно-рабочих:

// @experimental: bla bla
fn Foo() ...

Ну так уж и быть, "да" это 1й вариант, "не" это 2й и для тех кто ней уверен "хз"

Рим пал, центурион https://twitter.com/_alexgraf/status/1332081983879569415?s=21

type byteseq interface {
  type string, []byte
}

и мне это нравится, не будет этих []byte("foo")  и string(rawBytes) . Но меня заинтересовало другое - а что по поводу таких типовых ограничений (в дженериках) в других языках? Как-то с ходу ничего не вспомнилось :(

А вот это напомнило мне интерфейс с приватным методом, соотв определить такой можно только в пакете, где интерфейс и объявлен (как вы знаете).

type ImpossibleConstraint interface {
  comparable
  type []int
}

Только теперь такие ж штучки можно делать на уровне типов и это прикольно. Хочется придумать жизненный кейз, где это отлично зайдет (но пока не придумалось).

О, FOSDEM 2021 просыпается. Пока принятых докладов нет, но радует комнатка Zig.

Ждем 6-7 февраля значит.

https://fosdem.org/2021/schedule/tracks/

Да, вот и прошло 2 года с момента создания. Спасибо что читаете и комментируете. Как всегда самое интересное впереди. Понять бы куда двигаться.

А по случаю таких массовых гуляний - новый проект: @oleg_log_plus 🎉🎉🎉

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

Канал доступен по подписке на Патреоне https://www.patreon.com/olegkovalov (и там же детали о планах). После чего я дам вам инвайт (не забудьте указать ник в телеге)

- Повлияет ли это на основной @oleg_log в негативном ключе? конечно же нет.
- Поможет ли это ведению других проектов? (@generictalks, @good_bad_reviewer и что там еще? конечно же да.
- Приведет ли это к более сложным мемам в @profunctor_io? конечно же неизвестно.

Memory overall reduce from 298 GB RAM to 112 GB RAM per billion features. Average CPU utilization across all nodes dropped from 208 vCPUs to 72 vCPUs per 10 million rps.

И вообще вся статья неплохая, о том как ребятки поэтапно ускоряли свое хранилище ML-фич.

Как всегда это батчинг (они read-heavy), бинарная сериализация, хеширование и сжатие. И с этого часто стоить начать)

https://doordash.engineering/2020/11/19/building-a-gigascale-ml-feature-store-with-redis/

Я пока не знаю зачем оно мне, но галочку поставить стоит. Всегда хотелось держать под рукой валидный, но рандомный жсон.

Кстати советую канал, если вам интересны темы фаззинга и около.

Check your invocation logs!
Duration: 333.72 ms Billed Duration: 334 ms

Вот это уже сильно. Даже если тарификация будет по 10мс....ох...значит это не будет так смешно https://t.me/oleg_log/3846 (считайте я был инициатором изменения тарификации)

https://www.reddit.com/r/aws/comments/k48mzy/lambda_just_got_perms_billing

А вот и понятное объяснение что там случилось. А то лень читать стену текста. А кстати канал советую.

UPD: там на канале продолжение

«Все хуже и хуже... Добавление новых мощностей привело к тому, что на всех серверах число необходимых потоков превысило количество, разрешенное операционной системой»

https://t.me/profunctor_io/5907

А вообще такая проблема и у нас была. Годика 1.5 назад. У нас начал кашлять желтым статусом Elasticsearch (а он здоровый у нас)(ну был, ща я уже не там).

И если большинство сервисов не следили, что у них с логами, ну тип пишем на диск, а дальше пофиг, то мы свои не писали на диск, а сразу в инмем очередь, а потом отправляли батчами.

Ну вот эластик прилёг, очередь наполняются и продюсеры Кафки начинают приближаться к ООМ и убийству супервизором. Пришлось прыгать в ssh и менять конфиг с рестартом.

Можете не спрашивать, почему мы их не отбрасывали, мне кажется было связано с аналитикой (чтобы потом сравнить HDFS с Kafka и что вышло из неё, но могу быть чуть неправ).

Шо, тред ваших историй с переполнениями данными?

В коментах говорят есть решение лучше ×/ ⌷∘data¨ ⍸data∊⍨2020 - data

Я не уверен, где заканчивается код и начинает комментарий к решению, но вроде бы вот так.

https://twitter.com/code_report/status/1333822419996446725

3ч дебага вчера и еще 1.5ч местами не прошли даром. Получилось затащить ПР в phonenumbers (эт такой парсер-валидатор телефонов, переписанный на го с жс/жава/цпп от гугла).

Если вам будет скучно, если вы думаете, что у вас сложный таск с монго, посмотрите какая там ифология™, регулярки и кучи комментариев. О, еще тесты гляньте. Веселья на 7 2х недельных спритов.

https://github.com/nyaruka/phonenumbers/pull/71

(кстати ребятки оказались отзывчивыми, очень радует)