А гугл мне расскажет как в рамках единой атомарной операции проапдейдить базу и послать месседж в натс? Ну ведь не расскажет же. Отсутствует такая возможность в природе.
Если мне не изменяет память, Nats в дефолтной конфигурации (без jetstreams), вообще доставляет только тем подписчикам кто онлайн. А если все оффлайн то никуда не доставляет.
Но вообще, потеря месседжей это обычно неизбежная ситуация. Скажем, если мы апдейтим базу и посылаем об этом нотификацию через меccедж брокер. Эти два шага же не образуют единую атомарную операцию. А значит мы можем проапдейтить бд и тут же упасть и месседж просто не будет послан, хотя стейт и изменился.
Так что надежный сервис должен обычно иметь план Б на случай потери собщений (и их дупликации кста), а если такой план есть то надежность месседж брокера не столь важна, если не доставляет постоянно боль, то ну и ладно.
Прокоментирую. Чтоб применять практики как в Нетфликс и Убер, надо быть как Нетфликс и Убер - быть очень большими и нанимать квалифицированный персонал за 300 килобаксов. А если вы маленькие, бедные и умеренно компетентные - то лучше присмотрется к технологиям попроще. Монолит, единый яп и синхронный код - отличный выбор для огромного количества юзкейзов
Вот это я и имел ввиду когда говорил про скотское отношение как к рабам — выжать и выбросить.
Что значит выбросить? С чего вдруг увольнение — это выбросить? А самому уволиться по вашему это, видимо, предательство? Работа — это сделка обмена времени сотрудника на деньги компании, и как любая честная двусторонняя сделка действует она ровно до тех пор пока интересна обеим сторонам, и любая сторона вправе прервать ее в любой момент — это честно и логично, если сотрудник имеет право сам уволиться когда пожелает, то и компании имеет право уволить сотрудника и наоборот.
Более того — компания даже не осознает, что часто это она поставила сотрудника в такие условия.
Ни в какие «такие» условия взрослого дееспособного самостоятельного человека без его желания и согласия поставить невозможно, особенно когда речь заходит об айти, ладно б вы говорили об этом в контексте угледобычи в моногороде на краю света, но в айти? как?
Да даже и с автоматизацией — это все очень-очень грустно. Хоть многие QA инженеры и бодрятся, психологическая защита, наверное, какая-то. А а у кого эта психологическая защита сдала под напором объективной реальности — выгорают и киснут. Впрочем, чего спорить, кто не может с этим жить — идут в другие направления работать.
Дерьмовая работа — главная причина выгорания, а может даже и единственная. А работа в QA (как у автора) — одна из самых наидерьмовейших в АйТи, ну может саппорт еще дерьмовее. И все советы по сути о там как Игната заставить делать дерьмовую работу радостно и с песней (никак) и как самому Игнату убедить себя делать дерьмовую работу радостно и с песней (никак). Так что гнать надо такого сотрудника без всякого сожаления, нехай на стройке бетон лопатой пойдет покидает, раз ему в теплом офисе не работается.
Это работало в старые добрые времена, когда все кодили и коммитили как хотели. А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью. Подмешать туда левого кода нет ни особой возможности ни желания. Все проблемы нынче обрабатываются явно.
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.
Хочется спросить Google: ну зачем же вы ведетесь на политиканов и бюрократов?
Я вам отвечу почему они ведутся — потому что их иначе в тюрьму посадят. Вот например какое разъяснение давал sourceforge некоторое время назад по поводу отключения некоторых стран от доступа к свободному ПО:
However, in addition to participating in the open source community, we also live in the real world, and are governed by the laws of the country in which we are located. Our need to follow those laws supersedes any wishes we might have to make our community as inclusive as possible. The possible penalties for violating these restrictions include fines and imprisonment.
Сдается мне, автор все перевернул с ног на голову, фактически придумав конспиративную торию зарождения ООП. В общем, вот моя версия: сначала были структуры данных и были функции/процедуры, дальше люди заметили, что очень часто приходится ссылку на структуру передавать в функцию, а зачастую эти фунции вообще имеют ровно один параметр — собственно эту ссылку. Дальше улучшение путем объединения структур и этих функций в единую сущность лежало на поверхности. Ну а дальше встают вопросы расширения функциональности — отсюда вырастают наследование и полиморфизм, который выводится просто из здравого смысла. ООП готово. И никаких вам размышлений о сложности приложений, банальные итеративные улучшения ради немножко удобства. Но сложные программы писать стало легче, конечно, на то они и улучшения.
Ну если менеджерам (т.е. и компании) не нужно чтоб вы находили решение, «которое повысит роизводительность труда, снизит издержки и увеличит прибыль», то вам-то это зачем?
Давайте по другому, более конкретнее. Допустим, вы хотите увеличить свою зарплату в 2 раза, какими будут ваши действия?
Не уверен зачем вам нужен ответ на такой вопрос. Оставаясь в рамках той же сферы деятельность, надо поглядеть на рынок, как далека ваша зарплата от текущих рыночных реалий, если вы долго сидели на одном месте, возможно достаточно поменять работу на аналогичную, но в другой компании. Далее, переезд в зависимости от вашего текущего положения: в СПб, в Москву, за гранцу, но там сложности визового характера. В целом, рост и зарплат и позиции гораздо проще достигается путем смена места работы. Так же должен заметить, что иногда зп в два раза повысить не реалистично.
Плоха та фирма которая желает себе сделать плохо )))
Фирма ничего не желает, а вот люди, которые там работают, тут все бывает очень по разному, кто-то банально некомпетентен на своей позиции.
Я думаю не плохо, а сделать решение в рамкам отведенного времени, и с минимальными требованиями
Бывает по разному я так полагаю, например бывает, когда планы на продукт не соответствуют имеющимся ресурсам (и количеству и качеству), начинают резать углы, предпочитают ad-hoc решения, игнорируют коннер кейзы при выборе подхода, не инвестируют в инфраструктуру, качество кода, контроль качества. Иногда творится что-то совершенно необъяснимое.
А если и говорит(не фирма, а наемный работник) «сделай плохо», то лишь бы для того, чтобы человек не занимался не по задаче или проявлял излишний перфекционизм, потому что по-другому такого человека нельзя остановить.
Бывает и так наверное. Но обычно, когда всё делают плохо о перфекционизме говорить уже не приходится.
Я говорю о том, что если вы видите что-то, что можно улучшить, почему бы нет.
Так я ведь и не возражаю. Но только строго в оплаченное работодателем время, в одобренном работодателем объеме.
Тратить 8 часов каждый день (1/3 жизни) на то чтобы делать в терминах автора «каку» — это тоже не вариант.
Почему не вариант? Автору же за это заплатили, он свое время продал, дальше этим проданным временем распоряжается начальство — сказало сделать плохо, автор сделал плохо, и даже предупредил перед этим.
А гугл мне расскажет как в рамках единой атомарной операции проапдейдить базу и послать месседж в натс? Ну ведь не расскажет же. Отсутствует такая возможность в природе.
Если мне не изменяет память, Nats в дефолтной конфигурации (без jetstreams), вообще доставляет только тем подписчикам кто онлайн. А если все оффлайн то никуда не доставляет.
Но вообще, потеря месседжей это обычно неизбежная ситуация. Скажем, если мы апдейтим базу и посылаем об этом нотификацию через меccедж брокер. Эти два шага же не образуют единую атомарную операцию. А значит мы можем проапдейтить бд и тут же упасть и месседж просто не будет послан, хотя стейт и изменился.
Так что надежный сервис должен обычно иметь план Б на случай потери собщений (и их дупликации кста), а если такой план есть то надежность месседж брокера не столь важна, если не доставляет постоянно боль, то ну и ладно.
Прокоментирую. Чтоб применять практики как в Нетфликс и Убер, надо быть как Нетфликс и Убер - быть очень большими и нанимать квалифицированный персонал за 300 килобаксов. А если вы маленькие, бедные и умеренно компетентные - то лучше присмотрется к технологиям попроще. Монолит, единый яп и синхронный код - отличный выбор для огромного количества юзкейзов
Что значит выбросить? С чего вдруг увольнение — это выбросить? А самому уволиться по вашему это, видимо, предательство? Работа — это сделка обмена времени сотрудника на деньги компании, и как любая честная двусторонняя сделка действует она ровно до тех пор пока интересна обеим сторонам, и любая сторона вправе прервать ее в любой момент — это честно и логично, если сотрудник имеет право сам уволиться когда пожелает, то и компании имеет право уволить сотрудника и наоборот.
Ни в какие «такие» условия взрослого дееспособного самостоятельного человека без его желания и согласия поставить невозможно, особенно когда речь заходит об айти, ладно б вы говорили об этом в контексте угледобычи в моногороде на краю света, но в айти? как?
Ага, пластиковый конус-колпачек к роботу приклеили.
В доступных девушках и быстрых тачках? Ну уж точно не в 80% коде каверидже.
Что значит «всего лишь»? Это так-то $1500 в месяц (в рублях -100 тысяч) — нормальная зарплата для хорошего аутсорсера из бедной страны.
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.
Я вам отвечу почему они ведутся — потому что их иначе в тюрьму посадят. Вот например какое разъяснение давал sourceforge некоторое время назад по поводу отключения некоторых стран от доступа к свободному ПО:
sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law
Не уверен зачем вам нужен ответ на такой вопрос. Оставаясь в рамках той же сферы деятельность, надо поглядеть на рынок, как далека ваша зарплата от текущих рыночных реалий, если вы долго сидели на одном месте, возможно достаточно поменять работу на аналогичную, но в другой компании. Далее, переезд в зависимости от вашего текущего положения: в СПб, в Москву, за гранцу, но там сложности визового характера. В целом, рост и зарплат и позиции гораздо проще достигается путем смена места работы. Так же должен заметить, что иногда зп в два раза повысить не реалистично.
Фирма ничего не желает, а вот люди, которые там работают, тут все бывает очень по разному, кто-то банально некомпетентен на своей позиции.
Бывает по разному я так полагаю, например бывает, когда планы на продукт не соответствуют имеющимся ресурсам (и количеству и качеству), начинают резать углы, предпочитают ad-hoc решения, игнорируют коннер кейзы при выборе подхода, не инвестируют в инфраструктуру, качество кода, контроль качества. Иногда творится что-то совершенно необъяснимое.
Бывает и так наверное. Но обычно, когда всё делают плохо о перфекционизме говорить уже не приходится.
Так я ведь и не возражаю. Но только строго в оплаченное работодателем время, в одобренном работодателем объеме.
Почему не вариант? Автору же за это заплатили, он свое время продал, дальше этим проданным временем распоряжается начальство — сказало сделать плохо, автор сделал плохо, и даже предупредил перед этим.