Не оплаченный пост🖖

Решил сделать подборку своих каналов в телеграме, здесь штук 10 нет т.к. там не часто пишут посты или же с мемами каналы, но думаю с мемами вы и так найдёте.

Спасибо авторам и людям, которые их ведут и обновляют❤️

@tech_b0lt_Genona
@alexmakus
@catops
@devopslibrary
@flant_ru
@linuxgram
@opensource_findings
@hacker_news_feed
@oleg_log
@oleg_fov
@generictalks
@overtimehate
@nosingularity
@cybershit
@bykvaadm
@sqaunderhood
@evilmartians
@sudo_rmrf
@bortlog
@qaload
@lovely_it_hell
@badoo_tech
@buhtig
@opennet_ru
@razborfeeda
@automation_remarks
@experimentalchill
@itgram_channel
@manandthemachine
@good_bad_reviewer
@sec_devops
@tmfeed
@your_tech

На Полезняшки от "Разбора Полетов" ссылка битая, правильно @razborfeed
Заодно докину еще своих каналов, не упомянутых выше:
@SelectelNews и @unidataline в представлении не нуждаются))
@srv_admin --  канал линукс-админа. Так же у чувака есть блог с кучей полезных туториалов
@ITMeeting -- аггрегатор событий в IT мире
@emacsway_log -- DDD мишка
@randomstuffilike @scala_channel_ru @scalabin и @daily_ponv -- ФП
@count0_digest --  подезности про DevOps и SRE
@AwesomeKafka_ru -- канал Виктора Гамова про кафку
@sergeysova и @kamyshev_code-- фронтенд
@consensus_io -- распределенные хранилища и алгоритмы конценсуса
@dddevotion -- еще DDD
@microservices_arch @it_arch-- архитектура, микросервисы и вот это вот все

С трудом продираясь через онбординг(точнее через его отсутствие) на новом месте, с ностальгией вспоминаю галеру, где этот процесс был на высоте.
Процесс там был предельно прост: каждый вновь прибывший обязан был решить синтетический кейс(закрыть тикет в трекере), проведя его через все этапы жизненного цикла, прокоммуницировав с соответствующими людьми и попользовавшись всеми необходимыми инструментами. Почему не использовался реальный кейс? Потому что синтетический кейс во-первых уже известен куратору, что позволяет ему тратить меньше сил и времени на молодняк, а во-вторых, синтетический кейс можно сделать достаточно обширным(по охвату, а не по сложности), что бы протащить новичка через все круги ада, а реальный тикет такого масштаба не всегда попадал под руку. Должен сказать, что я и проходил сам такого рода онбординг и протаскивал через него достаточное количество людей, и от подавляющего большинства была положительная обратная связь. Да и мы видели у парней достаточно резвый вход в технику и процессы
Поделитесь плз в комментариях вашими удачными/неудачными кейсами онбординга, да и вообще мыслями по сабжу

Приходите 2 декабря на вебинар по парсерным комбинаторам на TypeScript, который я буду вести в качестве гостя коммьюнити Math.random(): https://mathrandom.com/webinar0212
Материал рассчитан на начинающую аудиторию, поэтому я начну с азов: быстренько пройдусь по крохотной части теории компиляции, разберу понятие функционального парсера и парсерных комбинаторов, и покажу, как мне изящно удалось решить задачу парсинга строки поискового запроса с булевыми операторами в ней в ~200 строк кода (а на самом деле даже меньше).

Давно у нас не было пятничных мемов

#books
Прочитал книжку А. Левенчука "Системноинженерное мышление", очень рекомендую! Не смотря на то, что я последние несколько лет очень интересовался вопросом описания и понимания больших и сложных систем, и изучил немало материала на эту тему, из книги все равно почерпнул для себя достаточно много инсайтов. Кстати, там достаточно много ссылок и на другую годную литературу.
Безусловно есть и минусы. У книги очень растянутое введение, т.о. если решите читать, то первые страниц 100(примерно треть книги) рекомендую просто пролистать

Поймал себя на том, что достаточно часто у сервисов со сложной логикой физически отделяю api от этой самой логики, связывая их мостиком из очередей. Занятно, что такой паттерн замечал у многих коллег, но мало кто смог ответить на вопрос о причинах такого разделения. Кароч, котаны, цимес такой: очень часто к api и бекенду у клиентов предъявляются разные ожидания. Апишка должна быть шустрой и всегда доступной(тот самый рыжий AP из CAP-теоремы), но при этом может отдать не особо актуальную инфу. Для бекенда, особенно работающего с денюжкой, часто важна строгая консистентность, но при этом никто не расстроится если он время от времени ненадолго приляжет(CP из CAP). У нас такие не особо нагруженные бекенды могли в кубернетисе даже без резервирования крутиться))
В самом деле, клиент не очень расстроится, если его заявка будет обрабатываться на 5 мин дольше, в случае подключения интернета у провайдера, или заказа нового иксбокса в магазине, но при этом будет недоумевать, если ему в лицо швырнуть 500кой или крутить спинером пока его заявка проходит все ваши CRM и ERP.
Вот такой вот интересный патерн. Го в комменты, делитесь своими мыслями, рассказывайте юзаете такое или нет

Интересные новости подъехали: Percona Monitoring and Management(продукт для мониторинга БД) переехал с Prometheus-based хранилища на VictoriaMetrics-based. При этом основной притензией к прому, как я понял из блога, была сложность настройки сети из-за pull-модели получения метрик. Целевым решением стал переезд на VM и использование по-дефолту push-модели
Я не берусь комментировать решения коллег из percona, но для меня это выглядит, как минимум, неоднозначно. Уверен, что парни рассмотрели альтернативы и приняли взвешенное решение, но в статье это как-то не отразилось(

пятнично-новогодний мем

Котаны, внезапно узнал, что у Нила Форда есть kata на fitness functions по аналогии с архитектурными kata Теда Ньюарта.
Скоро у всех новогодние (онлайн-)корпораты, так вот вам отличный конкурс))

Вспомнился тут интересный кейс, который в свое время заставил начать смотреть на цифры по-новому: на одном из собеcов меня попросили спроектировать систему, часть которой должна была хранить огромное количество(десятки миллионов) строковых ключей. Прирастали эти ключи тоже с приличной скоростью(десятки тысяч за день). Задача была простая: нужно уметь искать по четкому совпадению среди этих ключей.
Ну казалось бы, тут счет на миллионы, чуть ли не бигдата, надо расчехлять кликхаусы/сциллы и придумывать как бы так пошардировать что бы... вот где-то здесь мне интервьюер и предложил посчитать сколько же реально места займут наши миллионы строк. Допустим, длина ключа ограничена 100 символами: 100 * 100 000 000 ~ 10Гб
Десять гигабайт(Карл!). Вот и весь хайлоад)
Мораль сей басни: всегда надо четко(не в попугаях) оценивать нагрузку. Мне в этом плане очень нравится практика SREшного NALSD

У парней из @dddevotion вчера прошел ламповый ивент с блекджеком и кодом. Для тех кто любит(или пытается полюбить) DDD очень рекомендую!

Смеющийся испанец для меня, однозначно, мем года. А тут еще и про данные! Не могу не поделиться

Котаны, с наступающим(а кого-то и с уже наступившим) новым годом! Как говорил Конфуций: "найдите себе работу по душе, и вам не придется работать ни дня в своей жизни", вот и Вам я желаю, что бы айти приносило только удовлетворение от простого решения сложных проблем, а не головняк, фрустрацию и овертаймы! Ура, товарищи!

#kafka #performance
Отличная прошлогодняя статья про то, откуда растут ноги скорости Кафки. Если не читали, то очень советую.
В принципе ничего неожиданного (в основном, оптимизация I\O по всем фронтам), но очень круто, что кто-то собрал все такие трюки в одном месте

Кстати, котаны, только сегодня узнал о существовании вот такой вот замечательной карты от CNCF
Тут собраны и сгруппированы все плюс-минус зрелые Cloud Native технологии. Очень удобно для понимания альтернатив при выборе очередного кирпичика для решения

Список технических блогов, стоит добавить в закладки и раз в месяц почитывать

Cloudflare https://blog.cloudflare.com/
Netflix https://netflixtechblog.com/
Uber https://eng.uber.com/
Lyft https://eng.lyft.com/
Twilio https://www.twilio.com/blog
Facebook https://research.fb.com/
Twitter https://blog.twitter.com/engineering/en_us.html
Databricks https://databricks.com/blog/category/engineering
Google AI https://ai.googleblog.com/
Google Dev https://developers.googleblog.com/
Slack (already mentioned) https://slack.engineering/
Twitch https://blog.twitch.tv/en/?tag=engineering
Quora https://www.quora.com/q/quoraengineering
Discord https://blog.discord.com/engineering-posts/home

#dotnet #staticanalysis
Котаны, у Facebook есть замечательный static analysis тул под названием Infer. Если верить фейсбуку, там под капотом мат. аппарат, который позволяет детектить до 80% багла до прода.
Исторически тул работал для Java, C и Objective-C, но фейсбук внезапно добавил поддержку C# Додиезеры, возрадуйтесь!

Пссс, я тут недавно запостил давно начатый клиент для Redis на Go.

Зачем? Хотелось и другое не нравилось. У кого там были идеи по апи или еще какие-то боли из прода, подкиньте коментов/аргументов/ишью. Можно в лс. (Особо активных позову потом в чат организации)

Лайк-подписка на вырост https://github.com/cristalhq/redis