Подумал, что serverless — плохой термин для интуитивного понимания технологии. Понятнее было бы слово serviceless, потому что сервер там вполне себе есть, а вот (микро)сервис как раз упраздняется.

В призах денег нет (даже у Профанктора были), но вдруг кто-то захочет поучаствовать.

https://slackapponlinehackathon.splashthat.com/

Столкнулись с прикольной проблемой. В Couchbase есть протокол репликации между ДЦ (XDCR). Он немного своеобразный, но рабочий. И в какой-то момент стало плохо со временем синхронизации.

Вот в чем загвоздка: когда размер документа в БД переваливает за определенный лимит (256 байт), то сперва по сети будет взята метадата документа, потом пойдет проверка надо ли его реплицировать, и только потом сам документ перешлем.

Как можете догадаться, при документах больше 256 приходится еще разок бегать по сети. Как можете догадаться, это стоило нескольки часов дебага. Да еще и в канари версии все дебажилось, было непонятно где же баг в коде.

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

Дока https://docs.couchbase.com/server/5.5/xdcr/xdcr-tuning-performance.html

Мем по теме:

Заметил, что последние годы появилось очень много поделок на udp. На самом деле даже последние лет 10. Возможно я сейчас сморожу глупое, но все же.

Когда появился udp (аж 1980), то он был действительно ненадежный (unreliable), ведь сети, да и вся эта инфраструктура была слабой и многое могло пропадать.

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

Поэтому разные http3/quic, utp(bittorrent) и тд имеют место жить и очень даже аргументированно. Конечно хттп3 нацелен на мобилки, которые все еще могут пропадать, но в среднем по сети все будет ок. Вот так мне видится.

UPD: a, b сравнимы, никаких исключений, ошибок. все компайл-тайм проверено, если хотите.

Капитанский журнал.

День 3650й

Спустя 10 лет создатель Редиса пересчитал сколько кода он пишет в день. Получилось ~29 строк в день на основном проекте и где-то 50 вместе с сайд проектами. И это довольно интересный, но ожидаемый, показатель особенно учитывая что он пишет системного уровня софт в котором думать надо намного больше чем писать. Понятно что у мясного генератора крудов показатель будет больше)


https://twitter.com/antirez/status/1227575113391976448?s=21

Очень залипательная статья про шестерёнки, математику и физику. Детальный подход к теме, лайк

https://ciechanow.ski/gears/

Go for Cloud от JBD

ТЛДР: #go хорош для клауда.

Не знал этот трюк:
The go tool can print the Go version used to build a binary:

$ go version <binary>
<binary>: go1.13.5

И этот тоже:

go version -m <binary>
<binary>: go1.13.5
<list of dependencies>

https://rakyll.org/go-cloud/

Нашел офигенную(?) штуку для кубов, со слов пары одменов с работы - они довольны.

A web-based, highly extensible platform for developers to better understand the complexity of Kubernetes clusters. https://octant.dev

https://github.com/vmware-tanzu/octant

Появилась надежда, что в #go появятся более гибки билд-флаги, аля:

// +build (!arm64 && !s390x) || (arm64 && !go1.11) || gccgo || appengine

Правда все еще очень на этапе обсуждения, но есть шанс, что до го2 случится. А может и в след релизе.

https://github.com/golang/go/issues/25348

Вот и С++20 комитет закончили обсуждать.

https://www.reddit.com/r/cpp/comments/f47x4o/202002_prague_iso_c_committee_trip_report_c20_is/

The following notable features are in C++20:
- Modules.
- Coroutines.
- Concepts.
- Ranges.
- operator<=>.
- Feature test macros.
- std::span.
- etc....

Я хочу всем порекомендовать поиграть в Google Hashcode соревнование на следующей неделе.

Это соревнование отличается от всяких ICPC тем, что задача, которую мы даём, является очень сложной. Тем не менее, она является достаточно разнообразной, чтобы люди не скатывались в какой-то один метод.

А также:

1. Она реально тяжёлая. Как минимум мы не имеем представления как её решать точно.
2. Она похожа на задачи, с которыми в Гугле сталкиваются, и это не пустые слова. У нас есть целая команда занимающаяся математической/инженерной оптимизацией. Также мы опенсорсим or-tools, которая представляет огромный набор разных утилит для оптимизационных задач -- будь то просто какие-то логические условия, будь то солверы линейного программирования. Поддержка на многих языках -- C++, Python, C#, Java. Но используйте в соревновании на свой риск, мы проверяем, что они нисколько не работают на нашей задаче.
3. Я тестировал задачу на прочность и с уверенностью говорю, что будет весело.
4. Если вы займёте топовые места, мы активно будем хайрить вас в Google.
5. Это командное соревнование. Придётся найти человека/людей, с кем стоит поиграть.