Кому как не бел знать про тайные увольнения программистов в РФ ;)
Просто штурмовики Ларса потихоньку наелись европейского образа жизни, когда все деньги уходят на оплату квартиры в районе, где белых детей в школе не очень много, прям мало, а на отопление уже не хватает. Но нужно удержать их от возвращения в экономику РФ.
В ИИ куча бестолкового хайпа, который не взлетит, но перевод будет работать и синхронный и т.д. Знание языков теряет смысл и через 5 лет просто в ноль уйдёт. Ну и уж если учить, то хинди или китайский просто как тренировка мозгов ;*
Надо быть альтернативно одарённым, чтобы вместо какого нибудь минипк бушки за 50-70 баксов на Интел ххххU со всеми плюшками взрослой системы (саты, сети, псиэ и т.д.) взять это недопк за 100.
Пожалуйста, никогда не используйте в одном предложении вадин, спринг и сочетание "классные технологии".
Вадин - это такой костыль, между "прошлым и будущем", когда всем стэкхолдерам станет очевидно, что бэкендеры даже не собираются вникать в эту боль, под названием фронтэнд. И фронтэндерами, которые, когда придут, все равно все перелабают на реакт или что-то там, что у них на этой неделе модно.
Спринг - это такой забавный набор различных фреймворков и библиотек, обновление и конфигурация которых способны сожрать все рабочие дни любого количества девов. И не дай бог вам забить на ПРы реновейта или какого-нибудь депендабота на пару-тройку месяцев - хер до следующего мейджора разберётесь. А когда мейджер выйдет - будете всей фирмой 4 дня в неделю в течение 3 месяцев переписывать всю эту прелесть и по пятницам рыдать в обнимку на гриле ТГИФа, что ваша жизнь говно, вы все выгорели и когда начнётся уже эта ... ядерная война, которая заберёт все эти спринги, вадины, кубернетесы с продактонерами и тимлидами вместе взятыми в жерло термоядерного пламени :*
Как раз зашёл чтобы такой же комментарий оставить.
В сотнях проектах, которые я видел или участвовал, главное не говнокодить. Это значит уметь понять структуру приложения, если таковая есть и не ломать ее. Если ее нет, то создать ее или просто выжить в проекте. Потом эффективность и скорость по памяти и времени и т.д.
Я в да же в хл не вижу смысла лезть в настройки памяти, кроме может соотношения система/вм.
Когда-то таким пользовались через jmx. Но это ненужный гемор в проде. Какую-то экзотику - попробуй ещё поймать.
Спринг предлагает много всего для интеграционного и асептанс тестирования. А с появлением localstack - проверять всякие гипотезы в тестах стало намного проще.
Его эта фирма и не нанимала. Его нанял клиент этой фирме, что бы тот разобрался в этой помойке. Открыв этот шлак, он без дополнительных средств видит пароль в открытом виде от базы. При проверке оказывается, что пароль не от базы клиента, а от всей базы этой шараги.
Цирк уехал - клоуны остались и трудятся теперь программистами. Нам же не нужны умные, нам нужны взаимозаменяемые и желательно подешевле. Вон из той жопы миры не пойми с каким образованием вполне подойдут, ну и с местных курсов "взлед-посадка" тоже пойдут вполне. И вся цепь управленческая, которая это организовала и наняла - все они большие молодцы.
У него нет обязательств никаких перед этим цирком, он просто увидел неожиданный результат и мог запросить помощи у коллеги. Он мог в целом не осознать, что он видит, т.к. чужую базу нужно еще понять (чисто отмаз, конечно. У него, вроде, давний роман с этим софтом). Он сам не публиковал никакой информации об инциденте, это сделал еще один клоун-блогер, который, кстати, идет паровозом по этому делу.
Тут все феерично и прекрасно, поэтому клоуны все, кроме клиента, наверное. Ущерб для фирмы, безопасности в целом, карьере этого спеца и т.д.
З.Ы. Заявление действительно подала фирма-интегратор этого прекрасного решения, но я не уверен, что их не заставляет это сделать законодательство, что бы снять с себя риски наложения штрафов за сокрытия фактов утечки и т.п.
Хабр багнутый, комментарий был к другой статье и вот он тут.
Годный - этот тот, который сразу на выпуске был достаточно самостоятельным, с хорошим объемом знаний и ответственным, что бы решать любые задачи.
Остальным, в меру их испорченности, приходится н лет вытирать сопли и присматривать. Все мы такими были и это неплохо, но и нехорошо.
Расти над собой в этой области, где по многим причинам нет общепринятых эталонов и ориентиров, колоссальное количество карго и субъективщенны, жадных инвесторов систематично разрушающих рабочий рынок недоучками и такими вот "девочками-зайчиками-лидами-с-проблемами-из-мира-барби", довольно сложная задача, не находит?
Поверхностный анализ от поверхностных людей. Никто не рассматривает причины токсичности, не классифицирует токсичных коллег и не пытается работать системно.
Лучшие спецы, которых я знаю, дураку в лоб говорят, что он дурак. Те, кто клинические, бегут жаловаться. Те, кто не безнадёжен, закатывают рукава на ндцать лет и работают как не в себя.
Единицы выпускаются годными специалистами, я такого за 20 лет встретил одного.
Я люблю самонадеянных и заносчивых коллег. Если он дурак, то это видно сразу и смешно. Остальные, в кругу таких спецов, как топикстартер, должны себя хоть как-то мотивировать.
З.Ы. То, что лид да и вообще кто-то с 5+ опыта задается этими попсовыми вопросами западной культуры, говорит больше об этом человеке. У лида, который занят нормальными задачами, такие вопросы не должны всплывать вообще.
Что мешает выстроить очереди, потребление которых полностью контролируют потребители. Если даже клиенты "натуральные синхронисты" типа фронтэнда, то просто санитайз сервис делается, который изолирует синхронный от асинхронного контекста.
Ну и даже если 1. не вариант прям вообще, то по мониторингу нагрузки делается просто вертикальное и горизонтальное скалирование и нет проблем. Можно прям прописаться, что бы подов было после деплоя в 5 раз больше, чем средний уровень и они после обработки ретраев сами свернуться - KEDA
Одна из топ 5 электронной коммерции, работающих в Европе.
Про мониторинг я не словом. SLA нет, мы (как команда) не представляем платный сервис клиентам. За год, пока я с этой командой uptime 100%, остановка критических сервисов команды - это остановка основного бизнеса компании, что просто не приемлемо и они все реактивные, идемпотентные и с реплеем. У нас нет тестового окружения, только тесты, канари или двухцветный деплой. Метрики по логам из Cloud Watch и подобное используем для мониторинга наравне с графаной и ко.
Наша команда отвечает за 18 микросервисов в EKS и лямдах. Но команд таких много - с несколько десятков, которые только я знаю. На уровне CTO и т.п. нет предписаний, как строить свои системы, отсюда и разнообразие.
Под сотню инженеров в компании так работают только из команд, которые я знаю. А так - миллионы, кто сидит на ванильном AWS и использует Cloud Watch.
Вся безопасность, поиск и отображение на стороне амазона с их инструментами. Это ui обертки поверх presto на hdfs. Если искать по функциям запросов, то часто выходишь на документацию presto.
Канари или двухцветный деплой. Сервисы редко мутируют или расширяются в функционале - принцип пайпов из ФП, где расширение функционала через композицию. Одного dependabot нам уже хватает с избытком ) он в 99% случаев единственный, кто изменяет старые сервисы. UI их просто агрегируют по смыслу.
Да, конечно. Там безопасники в своем кокпите имеют массу подобного. Они шныряют по нашим access и прочим логам, делают аудиты. Вроде как конфедеративный доступ это называется, который им обеспечивает доступ и управление всеми аккаунтами команд.
Несколько десятков в графане или сразу из Cloud Watch метрик на Opsgenie.
Централизованные сервисы, которые начинают превосходить типовые конфигурации систем, ставят нетривиальные задачи перед разработчиками и увеличивают свои бюджеты нелинейно. В таких случаях всегда нужно останавливаться и осматривать индустрию на предмет уже найденных решений. Отсутствие материальной заинтересованности в экономии ресурсов в купе с определенной формой изолированности решений (зачастую изоляция из-за огромного выбора возможностей, которые до конца никто не знает) приводят к экзотичным решениям. Это обыденность в нашей профессии.
Нет, просто пишем на файловую систему (иногда кластерную) и грепаем с нее, по необходимости. 99% логов грепать не приходится вообще.
Мы переворачиваем несколько терабайт данных в день с семантикой exactly once и стоимостью меньше 10к на все в месяц в амазоне. До этого я работал в командах с гигабайтными потоками, которые только на логи пуляли больше.
Коротко: SSD на 7Gb/s и tail grep - решают все наши оперативные потребности в чтение логов. Поток таймсерий уже идет куда как более бедный, т.к. агрегируется еще в приложение.
Подробно: Если команды потребляют "несчитанные ресурсы", то они начинают их потреблять не считая. Зачем думать, сколько ты пожираешь трафика, проц. времени и памяти, когда это общие кластеры, откуда твою часть посчитать крайне сложно. Все колоссально меняется, когда команды сами платят за свою инфру. Вот тут каждый нанятый дурак виден - как прыщ на лбу. И 3 развернутых тестовых окружения со всеми интеграциями внезапно становятся неадекватно дорогими. Сейчас 7 Гб/с ссд ничего не стоят, так что даже сотню Гб логов ворочить обычным grep - работает на ура, а если тело умеет в tmux, tail и grep - то он сам себе кибана. Мы льем все в AWS на S3 и от туда достаем просто через Logs Insights. Это тоже самое, что HIVE или Presto. Оперативно ворочить нужно логами минут 15-30 и то, если там трейс через несколько систем каких-то убогих. Правильные сервисы позволяют понять, что не так, просто по своим логам, правильные сервисы идемпотенты и умеют реплей. В платежных системах логи нужно хранить дольше, но они могут уходить уже через день в более дешевые хранилища.
Есть прекрасная картинка, как из буханки хлеба сделать троллейбус, но зачем? По заголовку сразу было понятно, что люди не понимают, что они делают и денег не считают. Так оно и оказалось. Запомните и повторяйте: "эластик всегда либо ещё не нужен, либо уже слишком дорог".
Да да, а после компиляции вы проверили весь бинарный код, что компилятор не внедрил что-то "лишнее" :D
Кому как не бел знать про тайные увольнения программистов в РФ ;)
Просто штурмовики Ларса потихоньку наелись европейского образа жизни, когда все деньги уходят на оплату квартиры в районе, где белых детей в школе не очень много, прям мало, а на отопление уже не хватает. Но нужно удержать их от возвращения в экономику РФ.
Про уровни абстракций не слышали.
На верхнем уровне все просто - нужно делать деньги. Для этого им нужны инвесторы, заказчики и масштабируемость. Легко описать, попробуй сделать.
На среднем уровне нужны строители команд и продукта.
А на нижнем - компетенции в соответствующих технологиях и т.п.
Аутсорс - это когда берёшь в долг у своего продукта рубль, а отдаёшь потом 3-5, а то и 10.
В общем, не ваше это, ит бизнес строить, да и вообще бизнес.
Ориентируйтесь на специально натренированные модели для перевода типа deepl, а не универсальные модели.
В ИИ куча бестолкового хайпа, который не взлетит, но перевод будет работать и синхронный и т.д. Знание языков теряет смысл и через 5 лет просто в ноль уйдёт. Ну и уж если учить, то хинди или китайский просто как тренировка мозгов ;*
Надо быть альтернативно одарённым, чтобы вместо какого нибудь минипк бушки за 50-70 баксов на Интел ххххU со всеми плюшками взрослой системы (саты, сети, псиэ и т.д.) взять это недопк за 100.
Земля круглая и если ты кому то начинаешь сильно гадить на полянку, то не удивляйся, когда его изберут президентом, что тебе придётся отвечать.
Фейсбук тоже уже обозначили наказание в виде отчуждения ватсапа и инсты.
Се ля ви.
Пожалуйста, никогда не используйте в одном предложении вадин, спринг и сочетание "классные технологии".
Вадин - это такой костыль, между "прошлым и будущем", когда всем стэкхолдерам станет очевидно, что бэкендеры даже не собираются вникать в эту боль, под названием фронтэнд. И фронтэндерами, которые, когда придут, все равно все перелабают на реакт или что-то там, что у них на этой неделе модно.
Спринг - это такой забавный набор различных фреймворков и библиотек, обновление и конфигурация которых способны сожрать все рабочие дни любого количества девов. И не дай бог вам забить на ПРы реновейта или какого-нибудь депендабота на пару-тройку месяцев - хер до следующего мейджора разберётесь. А когда мейджер выйдет - будете всей фирмой 4 дня в неделю в течение 3 месяцев переписывать всю эту прелесть и по пятницам рыдать в обнимку на гриле ТГИФа, что ваша жизнь говно, вы все выгорели и когда начнётся уже эта ... ядерная война, которая заберёт все эти спринги, вадины, кубернетесы с продактонерами и тимлидами вместе взятыми в жерло термоядерного пламени :*
Как раз зашёл чтобы такой же комментарий оставить.
В сотнях проектах, которые я видел или участвовал, главное не говнокодить. Это значит уметь понять структуру приложения, если таковая есть и не ломать ее. Если ее нет, то создать ее или просто выжить в проекте. Потом эффективность и скорость по памяти и времени и т.д.
Я в да же в хл не вижу смысла лезть в настройки памяти, кроме может соотношения система/вм.
Когда-то таким пользовались через jmx. Но это ненужный гемор в проде. Какую-то экзотику - попробуй ещё поймать.
Спринг предлагает много всего для интеграционного и асептанс тестирования. А с появлением localstack - проверять всякие гипотезы в тестах стало намного проще.
Его эта фирма и не нанимала. Его нанял клиент этой фирме, что бы тот разобрался в этой помойке. Открыв этот шлак, он без дополнительных средств видит пароль в открытом виде от базы. При проверке оказывается, что пароль не от базы клиента, а от всей базы этой шараги.
Цирк уехал - клоуны остались и трудятся теперь программистами. Нам же не нужны умные, нам нужны взаимозаменяемые и желательно подешевле. Вон из той жопы миры не пойми с каким образованием вполне подойдут, ну и с местных курсов "взлед-посадка" тоже пойдут вполне. И вся цепь управленческая, которая это организовала и наняла - все они большие молодцы.
У него нет обязательств никаких перед этим цирком, он просто увидел неожиданный результат и мог запросить помощи у коллеги. Он мог в целом не осознать, что он видит, т.к. чужую базу нужно еще понять (чисто отмаз, конечно. У него, вроде, давний роман с этим софтом). Он сам не публиковал никакой информации об инциденте, это сделал еще один клоун-блогер, который, кстати, идет паровозом по этому делу.
Тут все феерично и прекрасно, поэтому клоуны все, кроме клиента, наверное. Ущерб для фирмы, безопасности в целом, карьере этого спеца и т.д.
З.Ы. Заявление действительно подала фирма-интегратор этого прекрасного решения, но я не уверен, что их не заставляет это сделать законодательство, что бы снять с себя риски наложения штрафов за сокрытия фактов утечки и т.п.
Не станет ни одна фирма сама раздувать подобное дело, рискуя репутацией. Это было верхом дебилизма на грани со слабоумием.
В Германии они обязаны сообщить о факте взлома и возможной утечке данных, а иначе там совсем несмешные штрафы.
И факт того, что обвинение было со стороны прокуратуры однозначно намекает, что в суд подавала не компания, а деяние признано общественно опасным.
Клоуны, короче, в этой истории почти все, но все знакомо, тут реально все так.
Хабр багнутый, комментарий был к другой статье и вот он тут.
Годный - этот тот, который сразу на выпуске был достаточно самостоятельным, с хорошим объемом знаний и ответственным, что бы решать любые задачи.
Остальным, в меру их испорченности, приходится н лет вытирать сопли и присматривать. Все мы такими были и это неплохо, но и нехорошо.
Расти над собой в этой области, где по многим причинам нет общепринятых эталонов и ориентиров, колоссальное количество карго и субъективщенны, жадных инвесторов систематично разрушающих рабочий рынок недоучками и такими вот "девочками-зайчиками-лидами-с-проблемами-из-мира-барби", довольно сложная задача, не находит?
Поверхностный анализ от поверхностных людей. Никто не рассматривает причины токсичности, не классифицирует токсичных коллег и не пытается работать системно.
Лучшие спецы, которых я знаю, дураку в лоб говорят, что он дурак. Те, кто клинические, бегут жаловаться. Те, кто не безнадёжен, закатывают рукава на ндцать лет и работают как не в себя.
Единицы выпускаются годными специалистами, я такого за 20 лет встретил одного.
Я люблю самонадеянных и заносчивых коллег. Если он дурак, то это видно сразу и смешно. Остальные, в кругу таких спецов, как топикстартер, должны себя хоть как-то мотивировать.
З.Ы. То, что лид да и вообще кто-то с 5+ опыта задается этими попсовыми вопросами западной культуры, говорит больше об этом человеке. У лида, который занят нормальными задачами, такие вопросы не должны всплывать вообще.
Что мешает выстроить очереди, потребление которых полностью контролируют потребители. Если даже клиенты "натуральные синхронисты" типа фронтэнда, то просто санитайз сервис делается, который изолирует синхронный от асинхронного контекста.
Ну и даже если 1. не вариант прям вообще, то по мониторингу нагрузки делается просто вертикальное и горизонтальное скалирование и нет проблем. Можно прям прописаться, что бы подов было после деплоя в 5 раз больше, чем средний уровень и они после обработки ретраев сами свернуться - KEDA
Одна из топ 5 электронной коммерции, работающих в Европе.
Про мониторинг я не словом. SLA нет, мы (как команда) не представляем платный сервис клиентам. За год, пока я с этой командой uptime 100%, остановка критических сервисов команды - это остановка основного бизнеса компании, что просто не приемлемо и они все реактивные, идемпотентные и с реплеем. У нас нет тестового окружения, только тесты, канари или двухцветный деплой.
Метрики по логам из Cloud Watch и подобное используем для мониторинга наравне с графаной и ко.
Наша команда отвечает за 18 микросервисов в EKS и лямдах. Но команд таких много - с несколько десятков, которые только я знаю. На уровне CTO и т.п. нет предписаний, как строить свои системы, отсюда и разнообразие.
Под сотню инженеров в компании так работают только из команд, которые я знаю. А так - миллионы, кто сидит на ванильном AWS и использует Cloud Watch.
Вся безопасность, поиск и отображение на стороне амазона с их инструментами. Это ui обертки поверх presto на hdfs. Если искать по функциям запросов, то часто выходишь на документацию presto.
Канари или двухцветный деплой. Сервисы редко мутируют или расширяются в функционале - принцип пайпов из ФП, где расширение функционала через композицию. Одного dependabot нам уже хватает с избытком ) он в 99% случаев единственный, кто изменяет старые сервисы. UI их просто агрегируют по смыслу.
Да, конечно. Там безопасники в своем кокпите имеют массу подобного. Они шныряют по нашим access и прочим логам, делают аудиты. Вроде как конфедеративный доступ это называется, который им обеспечивает доступ и управление всеми аккаунтами команд.
Несколько десятков в графане или сразу из Cloud Watch метрик на Opsgenie.
Централизованные сервисы, которые начинают превосходить типовые конфигурации систем, ставят нетривиальные задачи перед разработчиками и увеличивают свои бюджеты нелинейно. В таких случаях всегда нужно останавливаться и осматривать индустрию на предмет уже найденных решений. Отсутствие материальной заинтересованности в экономии ресурсов в купе с определенной формой изолированности решений (зачастую изоляция из-за огромного выбора возможностей, которые до конца никто не знает) приводят к экзотичным решениям. Это обыденность в нашей профессии.
Нет, просто пишем на файловую систему (иногда кластерную) и грепаем с нее, по необходимости. 99% логов грепать не приходится вообще.
Мы переворачиваем несколько терабайт данных в день с семантикой exactly once и стоимостью меньше 10к на все в месяц в амазоне. До этого я работал в командах с гигабайтными потоками, которые только на логи пуляли больше.
Коротко: SSD на 7Gb/s и tail grep - решают все наши оперативные потребности в чтение логов. Поток таймсерий уже идет куда как более бедный, т.к. агрегируется еще в приложение.
Подробно: Если команды потребляют "несчитанные ресурсы", то они начинают их потреблять не считая. Зачем думать, сколько ты пожираешь трафика, проц. времени и памяти, когда это общие кластеры, откуда твою часть посчитать крайне сложно. Все колоссально меняется, когда команды сами платят за свою инфру. Вот тут каждый нанятый дурак виден - как прыщ на лбу. И 3 развернутых тестовых окружения со всеми интеграциями внезапно становятся неадекватно дорогими.
Сейчас 7 Гб/с ссд ничего не стоят, так что даже сотню Гб логов ворочить обычным grep - работает на ура, а если тело умеет в tmux, tail и grep - то он сам себе кибана.
Мы льем все в AWS на S3 и от туда достаем просто через Logs Insights. Это тоже самое, что HIVE или Presto.
Оперативно ворочить нужно логами минут 15-30 и то, если там трейс через несколько систем каких-то убогих. Правильные сервисы позволяют понять, что не так, просто по своим логам, правильные сервисы идемпотенты и умеют реплей.
В платежных системах логи нужно хранить дольше, но они могут уходить уже через день в более дешевые хранилища.
Есть прекрасная картинка, как из буханки хлеба сделать троллейбус, но зачем? По заголовку сразу было понятно, что люди не понимают, что они делают и денег не считают. Так оно и оказалось. Запомните и повторяйте: "эластик всегда либо ещё не нужен, либо уже слишком дорог".