#network #tcp

Блин, я только сейчас понял: remote != work from home.

Мне кажется именно отсюда и ползет отвращение у сотрудников, а у работодателей недоверие.

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

2е потому что "да он(а) на диване лежит и жрёт чипсы, вместо того, чтобы фиксить фичи".

С другой стороны, если свалить в опенспейс(или съемную хату), чтобы лишь бы не дома работать, то бонусы уменьшаются. Хотя всегда можно найти баланс.

Так как я теперь С++ программист, рано или поздно я должен был поделиться впечатлениями. Но сначала коротка история.

Давным-давно, в другой жизни, мы набирали на работу программистов. Давали простую задачку типа перевернуть строку и разрешали писать на чем угодно. Любой язык, который ты знаешь. Ведь сила, она, брат, не в языке. Show us your best self. Так вот, про языки. Приходили сишники, и программы у них получались примерно такие, как от низкоуровнего языка и ожидаешь — страх, неуверенность, кишки, расчлененка и совершенно скучные вопросы типа «а кто выделит место под результат», которые внезапно выходят на первый план и становятся шоу-стопперами. В смысле писали они хорошо и правильно, это скорее мои ощущения от языка.

А потом пришел сиплюсплюсник. Я тогда, наивный, подумал — ну примерно то же самое получится. Но нет, он как-то очень быстро и ловко накидал программу, нигде явно память не выделял, нигде даже указателей не появилось. Все чистенько и аккуратненько, как будто на Джаве писал. А когда указатели над головами не летают, сразу чувствуешь себя сильно безопаснее. И я подумал — опа! Так что, можно было? Никогда бы не стал строить свою карьеру на внимательной работе с памятью, но без нее я вполне смог бы жить.

С тех пор эта мысль у меня висела в фоне — может быть, не так плох С++, как его малюют? Может быть, там как с Джавой — плохие программисты пишут плохо и создают языку репутацию, а хорошие сидят тихонечко, пишут хорошо и проблем не знают. Но проверить эту гипотезу поводов все не подворачивалось. Отзывы тоже были противоречивые, что скорее подтверждало мою гипотезу.

И вот наконец я попробовал С++ сам. То есть я пришел немножечно сбоку в большой и старый C++ проект, а именно Skia. Да и попробовал совсем чуть-чуть. Но главное, что свою гипотезу я, кажется, проверил: неважно, насколько хорошо ты обложился умными указателями, рефкаунтерами и move конструкторами. Неважно, сколько человек писало, смотрело, ревьюило и потом использовало твой код. Неважно, насколько прожжеными плюсовиками они были, неважно, как долго компания развивает экспертизу именно в C++ и насколько хороши их best practices. Все равно рано или поздно кто-нибудь, где-нибудь, как-нибудь, что-нибудь продолбает. Это точно такая же бомба замедленного действия, как и С, а промышленный код выглядит примерно так же страшно и ничуть не менее безопасно. В Skia контрибутит 170 человек. На ней работают Chrome, Android, Flutter, Firefox и Xamarin. И я, одним глазом на нее поглядывающий, без опыта низкоуровнего программирования, без опыта С или С++, нашел за 6 месяцев два случая некорректной работы с памятью. А ведь я их даже не искал! Причем в одном случае мне пришлось объяснять, почему это баг — даже натренированный глаз, когда ему показываешь сломанный код, не всегда способен заметить ошибку.

Итог, увы, неутешительный. Людям верить нельзя. Хороший программист даже себе не должен верить. Машинам — можно. Тотальные гарантии — единственное, что нас спасет. In the long run, конечно.

Skia is a complete 2D graphic library for drawing Text, Geometries, and Images.

https://github.com/google/skia

Звучит как снятие с себя ответственности, эт удобно

Поддержка собственного сервера для Bot API

Вместе с обновлением Bot API до версии 5.0 появилась возможность запускать свой собственный сервер Bot API. После поднятия, ваш бот будет отправлять запросы на свой сервер вместо api.telegram.org.

После переключения бот сможет:
— Скачивайте файлы без ограничения размера.
— Загружать файлы размером до 2000 МБ.
— Загружать файлы, с сервера или по прямой ссылке на файл.
— Возможность использовать любой HTTP URL-адрес, локальный IP-адрес и порт для вебхуков.
— Возможность установить max_webhook_connections до 100000.
— Возможность получить локальный путь как значение поля file_path без необходимости загружать файл после запроса getFile.

Исходный код сервера Telegram Bot API распространяется по лицензии Boost Software License.

#BotAPI

Думаю для вас далеко не секрет, что преждевременная оптимизация...дада, вечная-старая тема.

Столкнулся я в PR с одним молодым и активным пареньком, которому хочется делать возвращение структуры из метода по значению (а не через указатель, как чаще бывает), ведь поинтер оказался жуткой тратой ресурсов. Честно.

Проблема вот в чем: а никто ведь и не мерял 😏 хотя на мой вопрос даже докинул ссылку на затасканую статью (https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/). и как бы все...

Угадайте, кому важнее псевдоиммутабельность и минус 1 поинтер в хипе по сравнению с консистентностью в общем проекте и соседних пакетах? плез не делайте так.

1. консистентность
2. перформанс
держите именно в таком порядке, когда 2е ДЕЙСТВИТЕЛЬНО будет важным, 1е вы СОЗНАТЕЛЬНО понизите в приоритете.

Вышел Loki 2.0
https://habr.com/ru/company/southbridge/blog/526408/

Обширная статья про то, что плохо в клауде. Как и цена, как и перф, как и вендор-локин. Ну правда в принципе.

Лонгрид чуть.

https://cerebralab.com/Is_a_billion-dollar_worth_of_server_lying_on_the_ground

UPD: случайно скинул раньше.

Таааааак. Кто пишет сервисы на gRPC (без разницы какой язык, но скорее го, хах).

Подскажите, как вы ошибки заворачиваете и вот это все около ошибок. Попытался глянуть статьи и советы, но на 100% не определился.

Тыкать сюда @olegkovalov саммари ответов будет на 100% (не как с пейперами :) ведь полезно всем знать как надо делать. Спасибо.

oopsie

"Bitcoin and Ethereum are now using up the same amount of electricity as the whole of Austria. Carrying out a payment with Visa requires about 0.002 kilowatt-hours; the same payment with bitcoin uses up 906 kWh, more than half a million times as much"

https://thecorrespondent.com/655/blockchain-the-amazing-solution-for-almost-nothing/86714927310-8f431cae

Netflix Bulldozer: Batch Data Moving from Data Warehouse to Online Key-Value Stores.

В простонародье "давайте достанем все их Хадупа в Кассандру и раздадим по рест-хттп". Забавно, но мы год назад делали тож самое. Только был еще Airflow и чуть триггеров с Кафки, а не Mesos Scheduler.

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

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

https://netflixtechblog.com/bulldozer-batch-data-moving-from-data-warehouse-to-online-key-value-stores-41bac13863f8

Ох ребятки, все плохо. Сижу я здесь играюсь с ElasticSearch и немного удивляюсь сложности текущего софта. Да наверное и не только текущего.

Тема давно избитая, софт становится больше-сложнее, но это не повод поныть вечерком. Просто колво информации в логах контейнера Эластика/Кибаны сильно демотивирует. Может даже не со стороны опс-ов, а разработчиков, ведь с этим приходится работать и что-то там дофикшивать.

Наверн это и объясняет, почему многим друзьям и знакомым интереснее писать библиотеки, чем проекты (ну приложения, думая уловили). Я в том числе.

Правда, ведь интереснее накидать пару сотен (до пары тыщ точно) строк кода, которые решают опред задачу. "Мысли о апи в ванной крутятся, пока счетчик за воду крутится" на самом деле обыденная вещь.

А, ну и главное, в написании либ больше труда, чем в приложении. YMMV как всегда, но хочется верить в лучшее. Собственно одну для ES и пишу, надеюсь даж закончить, 3 дня не отпускает.

Вернемся к ошибкам и gRPC. Пожалуй самым популярным и экосистемно-верным будет использование очевидного решения.

https://pkg.go.dev/google.golang.org/grpc/status

Вот тутъ можно глянуть как там грпц мапится на хттп https://github.com/grpc-ecosystem/grpc-gateway/blob/master/runtime/errors.go

Какие вообще коды в грпц есть https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto

3 человека упомянули Result<Response, Error> паттрн в protobuf, при помощи магического слова oneof но насколько оно вам надо - хз. Пример:

message Response {
    oneof status {
        Result success = 1;
        Error rejected = 2;
    }
}

Мы остановились на статусе и все, видно выдумывать нечего на самом деле. Еще можно через мидлвару оборачивать, но непонятно зачем (оно в нашем случае)

Пускай массы тешатся (с)
Маркс (хотя я это видел написаное на мосту, но верю в правдивость автора)

Сам чат если шо https://t.me/oleg_log_blabla

Последний выпуск @generictalks как раз был с автором канала, настоятельно советую подписаться)

(Несколько раз собирался написать этот пост и каждый раз забывал. Меня даже уже подписчики стали спрашивать почему я не писал про это (@oleg_log, спасибо!).)

Проф. Андреас Зеллер с коллегами сделал отличный проект для популяризации генеративного тестирования - интерактивная книга в формате Jupyter notebook. В книге несколько разделов, каждый из которых посвящен подходам создания и примерами использования генеративных тестов: на основе свойств (property-based), search-based, мутационный фаззинг, тестирование API, тестирование грамматик и другие темы. Все темы авторы объясняют понятным языком и приводят примеры кода, который можно запускать в самой книге (спасибо Jupyter notebook). Мне каждый раз было лень искать публикацию, в которой бы объяснялся принцип search-based тестирования, нашел описание в книге и там оказалось всё очень просто. В общем если вам интересно автоматизированное тестирование, то книга рекомендована к прочтению.

https://www.fuzzingbook.org/

#непишитетесты, генерируйте их