Внезапно оказалось, что новый samsung a50 не имеет защиты от воды по всяким там стандартам в отличие от a5 двухлетней давности. Надо внимательнее читать диффы список характеристик

Почему работа мечты оказалась разгребанием авгиевых конюшен?

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

Ненавижу arc.

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

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

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

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

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

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

Долго думал как сделать опцию omit-empty в сериализаторе. Запилил omit_default, которая учитывает дефолтные значения полей в датаклассе.

https://github.com/Tishka17...ADME.md#omit-default

"Pokemon - gotta catch 'em all"

try {
 doSomething(); 
} catch (Exception) {
 // Do nothing 
}

Теперь и у меня есть книжка Роберта Мартина. Правда об этой я не слышал

Нафиг нужны енумы, если я должен везде писать MyEnum.xxx.value вместо MyEnum.xxx? Кто вообще придумал такое? Грёбаный графен писали какие не очень опытные люди

Сделал arc pull, поставил собираться свой проект, в котором изменилось 5 строк на питоне.
Налил кофе, посидел в инете, почитал чужие ревью и таск трекер. Прошло полчаса, оно ещё компилируется. Да нахрен так жить

На позапрошлом месте работы я просидел 6 лет. Написал кучу говнокода. В последний год что-то в голове перещелкнуло и я половину успешно отрефакторил внедрив хоть какую-то архитектуру. Параллельно борясь с попытками коллег противостоять этому. Начал грезить о микросервисах, так как система была уже достаточно большой. Мы выстрадали и начали писать требования на проект, чтобы понимать как он должен работать.

Потом я полгода трудился в другой фирме. В этом момент я уже знал буквы solid, проникся концепцией разделения приложения на слои, хотя ещё и не до конца понял как с этим эффективно жить. Поработав с имеющимся кодом, я прочувствовал на себе чем грозит нарушение концепции типа DI. Частично мне удалось это решить, частично команда уже занималась решением этого. Мне показали микросервисы и я увидел что это действительно может работать. Идея о необходимости требований к продукту уже витала в воздухе, но пока некому было этим заняться. Мы начали возвращать непроработанные тикеты авторам. У нас было принято дежурить по своим сервисам. Ну точнее дежурному могли позвонить и попросить починить. Как правило все ошибки были связан с неудачными релизами и по ночам не звонили.

На текущем месте работы я не знаю как работать с текущим кодом. Я уже понимаю, что как бы них хотелось иметь модульную архитектуру, есть удобные популярные фреймворки нарушающие многие принципы. Но блин свой кривой фреймворк без документации, нарушающий в слове SOLID каждую букву! Вместо микросервисов у нас приложения пишущие в одну базу напрямую. Или читающие дампы(!) её из трёх разных мест. А как насчёт сервисов, которые делают одну и ту же задачу и частично (части непредсказуемы) передающих данные в в любом направлении? А как насчёт отсутствия спецификаций на всё? А тикеты, по которым не понять ничего, пока не проведешь несколько встреч со сменными командами, после которых в тикет все равно ничего не занесут? А как насчёт мониторингов, которые звонят по ночам (да почти каждую ночь) и ты знаешь, что не можешь ничего не починить, но они все равно звонят. А как насчёт собственных уникальных технологий, которые решают или непонятные никому или уже решённые другими проблемы. Интересные продукты, но имеющие свои уникальные особенности, которые не гуглятся.

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

Поехал в сервис поменять колеса. Взял номерок "60", сейчас принимают 31. Посидел час, 38... Ну, думаю, съезжу поем. Поел, потупил. Прошло чуть больше часа. Смотрю на табло - 67. Ну думаю, окей, сейчас заеду. Подхожу к мастеру, а он такой 'идите новый талон берите". Суки, теперь я 82 и ждать ещё хз сколько.

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

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

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

Как-то так

Пришло время.

Какой мудак придумал, что нельзя разрешать человеку поиграть в купленную игру, пока он не скачает обновления? Да я бы через час их без проблем запустил, а сейчас я хочу поиграть!!! В итоге полчаса ожидания, пока эта тормозная штука скачает свой гиг обновлений и поставит их на мой старенький ноут. Что ж поиграю поменьше

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

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

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

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

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

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

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

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

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

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