Большое ошибкой было погуглить что есть для пайплайнлв обработки. Сижу и тупо пялюсь на
Apache Flink
Apache Spark
Apache Beam
Apache Airflow

Что, куда, зачем, как выбирать? (А ещё есть за пределами апача куча вещей)

Какая жира неудобная. Яндекс трекер на порядок приятнее

Хаха. При принятии на работу ребята сомневались: "что-то у тебя английский слабенький, но зато питон знаешь". Посомневались, но взяли.

Пришел на работу, сдал тест - B2+.

Ну и хули?

Сложно рефакторить код, который не работает

Такое ощущение, что я снова в универе. Целый день занимаюсь хернёй, но надо обязательно присутствовать. Раз в неделю английский, надо выучить джангу и сдать экзамен по aws. Сегодня сдавал тест по английскому, результатов ещё нет.

Смотрю я на gRPC и мне одновременно представляется подход принятый в Android с AIDL файлами и то, что у нас было в ламоде для jsonrpc

На новом месте работы юзают прогу для трекинга чем я занят, которая даже размытые скриншоты делает. Так низко я ещё не падал

Человек тут в комментах защищает длину строки 200 символов. Открываю инфу - 6 лет в яндексе. Ммм, понятно

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

Проект собирается долго, потому что собирается весь мир Яндекс?
Так собирай на виртуалке.
Да, для этого ты должен настроить синхронизацию файлов проекта и не забывать переключать ветки/пуллить транк локально и удаленно одновременно.
Шелл в виртулке переключается через личный кабинет, а не через конфиги как обычно.
20гигов диска для сборки проекта мало.
Куда это у меня аллоцировано 500гигов в персональной квоте, если у меня одна виртуалка на 20?
Персональная квота не персональная, если у тебя какая-то левая роль...

У меня накипело. В четверг кинул коллегам письмо о том, какое говно у нас в коде. Даже придумали как от части его избавляться. Жаль, монорепу никуда не деть. Теперь сижу и думаю как GraphQL натянуть на чистую архитктуру.

Вчера старательно посылал начальника и объяснял ему разницу между бизнес требованиями и требованиями по реализации. И вообще что "тэги должны определять разделы, а ещё нужно API и UI" - это не требование. Практически послал его нахуй.

Проснулся в настроении "а похуй на все, буду не думая делать, что скажут и в фоне пилить эту чистую архитктуру"

Шел второй рабочий день после отпуска. Второй день меня будит мониторинг.

Эта хуйня все таки проебала часть изменений при ребейзе. Ладно ещё история пул реквеста хранится отдельно.

Ненавижу arc.

Сначала я узнал, что мерджей нет. Только ребейз.

Потом я заейбался ребейзить, потому что у меня 20 коммитов. А кто-то в транк закоммитил измененный мной файл. В результате конфликт на каждый второй мой коммит. При мердже был бы один.

Потом он проебал изменения при ребейзе. Заметил случайно

Мне предложили обновить arc. Оказалось, что apt upgrade его не обновляет, а обновляет только лаунчер. А сам Арк обновляется командой arc upgrade.

Потом выяснилось, что при обновлении его демон сам не рестартует. Хер с ним, killall.

Потом выяснилось, что он не может нормально вывести дифф между двумя несвязанными ветками. Что-то выводит, но явно что-то левое.

Я не для того пошел писать на питоне, чтобы час компилировать программу!

Я начал понимать почему у нас даже не пытаются в проекте следовать принципу Single Responsibility. У нас вся компания такая.

Например, есть утилита ya. Она умеет заливать код на пасту, создавать PR, компилировать проекты, аплоадить артефакты сборки, запускать IDE, тащить конфиги Вима и хз что ещё. А ещё монорепа, о которой все слышали.

God object - это концепция компании. Зачем делить вещи по функциональому признаку? Мы просто сделаем вещь, которая умеет всё. А если что-то не будет уметь, сделаем ещё одну, умеющую то же, что первая, но ещё и своё

Через очередь нашему сервису прилетают апдейты.
Он читает их и удаляет. Через 30 секунд попыток чтения переходит к следующему шагу
Он берет и кладёт их в новую "статическую" таблицу (в местное хранилище), сортирует и мерджит с существующей. Это занимает около минуты для добавления 10 записей к существующим 100
Он снова читает эту таблицу и проверяет статус в БД. После чего отправляет результат в другую очередь. Это занимает 5 секунд.
Он удаляет из таблицы обработанные записи с учётом особенностей хранилища. Ещё где-то за 40 секунд.
Сервис перезапускается

Вопрос: какого хрена надо так писать?
Вопрос 2: нарушения pep8, побочные эффекты функций вместе с возвращаемым значением, проверка истинности через is True и прочие чудеса в коде тоже присутствуют

Какой-то идиот задеплоил все инстансы сервиса в один ДЦ

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

Чтобы сделать юнит тесты для проги на питоне надо
Вынести все сорцы (кроме скрипта запуск) в отдельную либу со своим сборочным файлом
Сделать в отдельной папке сборочный файл для проги, где указать либу как зависимость
* В отдельной папке сделать сборочный файл с тестами, где указать либу как завивисмость и перечислить все тесты

Чтобы прогнать тесты на втором и третьем питоне надо
Вынести все тесты в либу
В отдельной папке сделать сборочный файл для второго питона, где либа будет как завивисмость
* В отдельной папке сделать сборочный файл для третьего питона, где та же либа будет как завивисмость

У нас есть очень стандартный процесс связи нескольких сервисов:

1. Сервис А кладёт данные в таблицу БД (у нас своя бд с таблицами по папочкам)
2. Сервис Б раз в 15 минут ищет новую таблицу и читает из нее данные и что-то делает с ними
3. Сервис А раз в 15 минут смотрит в другую папку на предмет появления таблицы с результатами

В результате у нас задержка получается полчаса за нефиг делать.

Это вообще нормально?