С момента получения состояний и до самой смерти они были обречены падать - беднеть каждую секунду своей жизни, без шанса остановиться или начать взлетать
А работать им уже нельзя?..
Наверно, первый раз вижу обоснование, что много денег - это плохо.
Начальники, которые не понимают специфики того, чем управляют и не хотят этого понимать- крайность. Таких не то, что могила, их экскаватор не исправит.
Так ведь вы именно это и предлагаете, запрещая переход из спецов в начальники. Откуда возьмутся "начальники с пониманием специфики"?
Прошло больше трёх месяцев с начала моих поисков, и я приуныл.
Искал через коллег:
Я отправил личные сообщения всем моим коллегам.
Через пару дней я получил оффер.
Имхо, из этой офигительной истории следует, что не рынок сломан, а HH/HR работать не умеют.
Но не пойму, как из этого могут следовать выводы
Не врите в резюме…
Разработчикам без опыта будет сложнее.
Не позволяйте ИИ генерировать всё за вас.
... когда вы не были в данной ситуации разработчиком без опыта, и когда резюме либо не читают, либо читает только ИИ, который умеет только отказывать. В последней ситуации, с таким отношением работодателя, наоборот можно врать побольше, можно даже подключить ИИ, который рассказывает совершенно фантастические истории (или делает атаки на промпт собеседующего) - вряд ли это ухудшит шанс найма.
Я применял некоторые идеи "неизменяемой архитектуры" в реальных условиях, с некоторыми поправками на ограниченный объём дисков.
Применимость зависит от того, можно ли эффективно делать запросы к используемой схеме данных. В одном из вариантов использовалась таблица с сотнями миллионов записей, и запросы к ней получились вложенными, с промежуточными сортировками и join'ами. Это не работало, т.к. запросы обрабатывались за случайное время от десятков секунд до нескольких часов. В другом варианте, с применением денормализации данных под форму запроса (CQRS) запросы стали обрабатываться за ~100мс. В других задачах, менее объёмных по числу записей, проблем не возникало.
Собственно, и git, и docker примерно на тех же принципах основаны.
Типичная история успеха при внедрении скрама, неплохо.
Слышал мнение, что скрам плохо подходит для поддержки из-за спринтов (т.к. со спринтами невозможно что-то реализовать/исправить в предельно короткие сроки, минимальное время получается ~1.5 спринта). Как вы это обошли?
Забавно звучит в контексте CVE, позволяющей шарить по системе как раз из контейнера..
А вот если использовать виртуалки, то взломщик как бы изначально в тюрьме, находящейся внутри вашей квартиры!
Скорее придётся использовать какой-нибудь rustore...
А работать им уже нельзя?..
Наверно, первый раз вижу обоснование, что много денег - это плохо.
Таких любителей ощущений всё меньше и меньше. Наверно, сложно дёргать ручку механики так же хорошо, как работает 8-ступенчатый автомат.
"Эти люди" иногда так копейки экономят, что лучше бы код писали...
Что-то из сгенерированного может осесть в голове.
Первый раз в интернете?
и на 2 порядка дольшеТоже склоняюсь к такому варианту. Ну или арендовать GPU.
Т.е., возможно, никогда (сколько они служат?). ЧСХ, для датацентров с окупаемостью тоже могут быть нюансы.
А работнику что-то запрещает вникнуть в менеджмент?
string это же линия на карте...
Так ведь вы именно это и предлагаете, запрещая переход из спецов в начальники. Откуда возьмутся "начальники с пониманием специфики"?
Автор нашёл место за 2 дня, когда сменил канал поиска.
Искал через HH:
Искал через коллег:
Имхо, из этой офигительной истории следует, что не рынок сломан, а HH/HR работать не умеют.
Но не пойму, как из этого могут следовать выводы
... когда вы не были в данной ситуации разработчиком без опыта, и когда резюме либо не читают, либо читает только ИИ, который умеет только отказывать. В последней ситуации, с таким отношением работодателя, наоборот можно врать побольше, можно даже подключить ИИ, который рассказывает совершенно фантастические истории (или делает атаки на промпт собеседующего) - вряд ли это ухудшит шанс найма.
Я применял некоторые идеи "неизменяемой архитектуры" в реальных условиях, с некоторыми поправками на ограниченный объём дисков.
Применимость зависит от того, можно ли эффективно делать запросы к используемой схеме данных. В одном из вариантов использовалась таблица с сотнями миллионов записей, и запросы к ней получились вложенными, с промежуточными сортировками и join'ами. Это не работало, т.к. запросы обрабатывались за случайное время от десятков секунд до нескольких часов. В другом варианте, с применением денормализации данных под форму запроса (CQRS) запросы стали обрабатываться за ~100мс. В других задачах, менее объёмных по числу записей, проблем не возникало.
Собственно, и git, и docker примерно на тех же принципах основаны.
Отрицательно!
Для запуска непонятных программ лучше бы использовать виртуалку без интернета. Или не запускать.
Естественно. Вирусы не первый год существуют.
Типичная история успеха при внедрении скрама, неплохо.
Слышал мнение, что скрам плохо подходит для поддержки из-за спринтов (т.к. со спринтами невозможно что-то реализовать/исправить в предельно короткие сроки, минимальное время получается ~1.5 спринта). Как вы это обошли?