Пока следующий выпуск готовится к опубликованию, появилась мысль, а почему бы завтра не попробовать live-запись? Все равно многие дома сидят.

Завтра сообщим когда и по какому часовому поясу, но точно под вечер по CET.

Как вариант, можете закинуть вопросов и тем на завтра сюда к боту @generictalks_bot

Это приятно слышать, но это так же смешно: мы не будем выпускать новые версии, чтобы ничего не сломать. https://chromereleases.googleblog.com/2020/03/upcoming-chrome-and-chrome-os-releases.html

Будем в 19:30 по СЕТ, попробую потранслировать что-то, скорее на ютюб. Если кто-то спец по трансляции с Zoom, то можете тыкнуть меня в лс @olegkovalov

через 5ч8м начнем-с https://time.is/1930_19_Mar_2020_in_CET

1) Год назад в багбаунти программу mailru заслали баг на 10 тысяч $, из публичного описания было понятно лишь то, что ликается какая-то рандомная память https://twitter.com/disclosedh1/status/1189553870801907713
2) Полгода назад samwcyo публикует статью, как ему заплатили 40 тысяч $ за похожую багу https://samcurry.net/filling-in-the-blanks-exploiting-null-byte-buffer-overflow-for-a-40000-bounty/. Т.е. где-то что-то подставил, а в ответ рандомные куски памяти. В 2019 то году!

-- Ни в первом, ни во втором случае было непонятно, из-за чего именно раскрывалась рандомная память сервера в ответе --

3) И вот вчера появились детали из-за чего был баг #1 и, возможно, баг #2. Причина - неожиданное поведение openResty, при помощи которого можно писать скрипты на Lua в Nginx. Ожидается, что Lua в данном случае - это memory-safe язык, и подобные уязвимости ему не грозят. Но это оказалось не так и из-за этого была уязвимость. Также по ходу расследования оказалось что и "чистый" Nginx к этому уязвим, но Nginx - запатчились, а openResty - нет. Детали теперь в описании https://hackerone.com/reports/513236

Представьте себе, это как на PHP бы функция header() при подстановке %00 начала бы отдавать в ответе случайную память на сервере.

А, ну вот, мы live.

Пришлось выйти на канале Good Reviewer - Bad Reviewer, из-за правил ютюба, но это 1й раз. Чатить можно как в телеграме, так и на ютюбе, выбирайте сами)

https://www.youtube.com/watch?v=RUVEewnD5ww

Вышел Go 1.14.1 и 1.13.9 c неплохими, логично что с изменениями рантайма и нового шкедулера, хех

https://twitter.com/golang/status/1240744527087972368

https://github.com/golang/go/issues?q=milestone%3AGo1.14.1+label%3ACherryPickApproved

Оказывается гугл может в whiteboard online https://jamboard.google.com/

Посоветовали еще неплохие
https://awwapp.com/
https://mural.co/

Но гугл выигрывает (у нас) из-за GSuite и прайваси любимого. Еще вспоминается Профанктор-хакатон...

PS: дада, в Zoom тоже это есть из коробки, прям на экране рисовать можно.

Прорекламирую в тяжёлые времена.

Что почитать? Тут недавно вышла книга про Software Engineering в Google, очень подробно с кучей внутренностей, о которых я теперь могу спокойно рассказывать. Про систему сборки, документацию, тикет систему, версионирование и Piper, дизайн документы, код ревью, глобальные рефакторинги, статический анализ, CI, юнит тестирование, deprecations, code search, истории о героях и спартанцах, победах и поражениях, десятки потраченных лет лучших разработчиков в кодовой базе на пару миллиардов строк и в частности 300+ миллионов строк C++ кода. Книга-приключение, написана легко и понятно. Как по мне, любой Junior, прочитав эту книгу, находится в большом плюсе перед остальными -- в этой книге слишком много собрано правильных вещей, которые возможно только несколько компаний в мире пытаются решить на таком масштабе, а самое главное -- эта книга расскажет про практики и про то, что в итоге сработало, что не сработало и как оценивать вещи в разработке в целом.

Отмечу, что не надо идти делать так же, как написано в книге. То, что работает в Гугле, может не работать у вас или потребует огромной экспертизы и поддержки. Об этом тоже написано в книге очень хорошо -- про tradeoffs.

Я лично заказал себе hardcopy, подпишу у автора Titus Winters, который кажется не спал ночами и писал эту книгу. https://twitter.com/TitusWinters/status/1189975357778251776

А вот и сама ссылка на книгу:

https://www.amazon.com/Software-Engineering-Google-Lessons-Programming-ebook-dp-B0859PF5HB/dp/B0859PF5HB/ref=mt_kindle?_encoding=UTF8&me=&qid=

Хах, я провалил комбо с "постить каждый день в течении года", ведь вчера ничего не написал. Ну лан. Зато я глянул 70+ докладов о го (Gopher Australia, Vietnam, GoLab и другие по мелочи).

Как оказалось - интересных не очень много, эт обидно. Все либо слишком для начинающих, либо пересказ старых тем. Конечно в этом что-то есть, но всегда хочется нового контента и историй из прода.

Посоветую этот доклад о Profiling a go service in production. Довольно хорошо сделано и рассказаны интересные вещи про select и ctx.Done() (тлдр, глянуть фции для каждого в стдлиб).

https://www.youtube.com/watch?v=19bxBMPOlyA

Epidemic Calculator наверное самое полезное в текущей ситуации. А может просто вещь для прокрастинации. Стало интересно, где это еще можно применить.

http://gabgoh.github.io/COVID/index.html

Сегодня в одном чате разгорелся вопрос "а кто этот ваш multi-dc вообще?". Как можно догадаться, многим это и не надо, далеко не каждый бизнес вырос до такого, что не помещается под Франкфуртом у Digitalocean. Но зачем-то они сидят с этим кактусом.

Как еще показывает практика, архитекторы видят в multi-dc больше позитива: у нас и uptime больше будет, и молнии нам не страшны, да и вообще все так делают, вон у FAANG посмотрите.

Проблема только в том, что ДЦ довольно себе живучие, ведь в них вливают денег больше, чем некоторые эти multi-dc фирмы зарабатывают в год (вот сейчас без шуточек). И найти среди друзей, у кого на каком-то небольшом хостинге есть виртуалка, с аптаймом в пару лет - не сложно (жмем F https://xn--r1a.website/cyberhermitage/491)

А что еще интересное, что количество причин и время недоступности сервиса чаще из-за софта, чем железа. Пруфнуть числами не могу, но скажу по опыту и опыту друзей. Сколько там раз в проде летели 500 из-за кривых хотелок и желания потестить? Ну и сколько раз падал AWS ?

Но и вот скрытая угроза - а что там со сложностью разработки и поддержки этого добра? Написать distributed инжир каждый может, только вместо "ну у нас конфиг на кластер-монги" и настоящими распределенными системами все еще существует разница. Дело даже не в том, чтобы это закодить, а в том, чтобы поддерживать и знать как лечить.

Уверен, что некоторые multi-dc воспримут как возможность скейлится и иметь гибкую архитектуру, но скейлится можно и в рамках одного ДЦ, и даже очень сильно.

(еще была мысль, что подавляющее большинство бизнеса это read-heavy вещи, эти ваши ютюбы, магазины, твиторы, что дает возможность что-то кешировать и/или заполнять старыми данными, пока ДЦ тупит, а соседние возвращают статику, и эту интересную тему хочется подумать больше)

PS. multi-dc вполне можно читать как multi-cloud.

(регулярная поставка годноты от @oleg_log)
Yet another исследование модели распространения возбуждения, на этот раз по решётке. Модель примитивнейшая, но очень увлекательно и классные выводы.
Потрясен больше даже форматом, чем контентом. Прямо мечта, теперь мотивация писать статьи просто что б вставлять в текст свои интерактивные примеры
https://www.meltingasphalt.com/interactive/going-critical/

Хороший доклад о том, как развивалась архитектура ManyChat (платформа для ботов ФБ). Как с 0рпс дожить до 25к и все это делать на простом стеке, пхп стеке. Ведь связка Nginx+Redis+Postgres могут многое.

https://www.youtube.com/watch?v=RL9w_KRWhNI

Мне вот что интересно, а к чему приведет вся эта пандемия/эпидемия/карантин в ближайшые годы. Конечно же интересны эти экономики и геополитики, но я сейчас про работу.

Возможно в сознании людей и работодателей что-то изменится, все станет лампово и удаленно. Не надо будет сидеть на злостных митингах в 10человек ради 2х говорящих (дада, можно ж просто док написать), люди станут трепетнее относиться к тому, что кому-то нужно ревью, а, да и общее качество вещей может стать лучше. Делай хорошо - будет хорошо (когда дома).

Я слышал от многих, что АЙТИ фирма была совсем не готова к внезапно удаленной работе, причем фирма обычная, без супер секретных требований. Некоторые словили вирусню и получили шифрованные диски всей фирмы (1 человек занёс и понеслась, дада, все были ремоутно). Ну и другие плюшки.

Вообще интересно это все. Жаль случилось чуть раньше, чем хотелось бы мне. Не, я не связан никак с распространением COVID-19 эх..

Вообще если так подумать дальше, сравнить офис и (форсед) ремоут, то все УГ просто расползлось по домам.

- Если ревью делалось с паузой в 6ч, то оно так и делается дальше.
- Если человек из другой тимы и города не отвечал на вопросы, то так же ответа и не дождаться.
- Если в одном билде стоит 1 галочка, а в другом нет, а как правильно непонятно и доки нет, то....все остается так же. Просто опять latency вылезает везде.

Ооо! Быстромысль. Работа ремоутом отличный показатель, почему не стоит лезть в микросервисы, если вы не понимаете, куда вы лезете.

- Внезапно коммуникация хромает и это не фиксится рестартом.
- Недостаток согласования вещей и отсутствие протокола на вещи.
- Ну и любимое - задержки и опоздания. Собраться всей командой в одно время. Эт вам не монгокластер вернуть к жизни, хех.

Система аксиом Цермело — Френкеля (ZF) — наиболее широко используемый вариант аксиоматической теории множеств, являющийся фактическим стандартом для оснований математики. Сформулирована Эрнстом Цермело в 1908 году как средство преодоления парадоксов теории множеств, и уточнена Абрахамом Френкелем в 1921 году.

Это действительно смешно и страшно.

https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%A6%D0%B5%D1%80%D0%BC%D0%B5%D0%BB%D0%BE_%E2%80%94_%D0%A4%D1%80%D0%B5%D0%BD%D0%BA%D0%B5%D0%BB%D1%8F

Аж вскрикнул
via Ортем

А вот это интересная фича на самом деле. Можно не тащить с собой всю экосистему LLVM, получать легкую кросскомпиляцию из коробки и прочие штуковинки. Руки зачесались что-то попробовать.