Очень много перекликается с моим собственным опытом проведения собеседований на тимлидов. Особенно важно понять - какой вклад был у человека не предыдущих местах и как он его добился
Какой бы ни был навороченный инструмент - умение четко и структурировано генерировать и выражать свои мысли и есть главный скилл разработчика, а уж как он это оформляет в виде кода, блок-схемы, ТЗ или промпта в chatgpt это все вторично.
Иногда переход на (микро-)сервисную архитектуру вынуждает делать сам бизнес или развитие компании. Вот (почти) выдуманный пример: есть у нас компания со своим идеально вылизанным монолитом на java+mongodb, продает автомобили через сайт и моб приложение и все хорошо. Потом компания растет и вот она уже покупает другую компанию, небольшой, но успешный стартап по продаже трициклетов. А там внезапно php+mysql. А по бизнес требованиям надо чтобы оплата, регистрация и поиск были одинаковые. И письма приходили в едином стиле, в одном шаблоне. И вообще надо бы максимально теперь объединить эти проекты в один, как тут обойтись без (микро-)сервисов, без выделения регистрации, оплаты в отдельные сервисы?
Монолит классная штука, но надо понимать границы применимости такой архитектуры, как и микросервисной и я думаю, что хотя у монолита и выше скорость разработки, но у микросервисной выше скорость к слиянию с другим кодом и больше возможностей по аутсорсингу части проекта сторонним разработчикам. Да, в микросервисной большей boierplatинга и тулинга, но зато кода который надо держать в памяти (человека) и понимать как он работает - меньше.
Знакомые какие все ситуации :). Насчет sudo/su имхо с ключами вход по руту (а если призывают админа, то 100% придется делать что-то от рута) намного удобней.
при stop — инстанц останавливается, временное хранилище (ephemeral storage) теряется, подключенные EBS-диски остаются подключенными, elastic IP отключается. Платить в stopped состоянии надо будет только за EBS-диски, если за полгода платить, то он останется и можно будет подключиться)
Очень много перекликается с моим собственным опытом проведения собеседований на тимлидов. Особенно важно понять - какой вклад был у человека не предыдущих местах и как он его добился
а в чем страх занести бактерии на марс если цель жизни в ее распространении
magic the gathering с бустерами тоже использует гача/лутбокс механику
Какой бы ни был навороченный инструмент - умение четко и структурировано генерировать и выражать свои мысли и есть главный скилл разработчика, а уж как он это оформляет в виде кода, блок-схемы, ТЗ или промпта в chatgpt это все вторично.
в 20% текста статьи содержится 80% полезного смысла, остальное можно не читать)
Иногда переход на (микро-)сервисную архитектуру вынуждает делать сам бизнес или развитие компании. Вот (почти) выдуманный пример: есть у нас компания со своим идеально вылизанным монолитом на java+mongodb, продает автомобили через сайт и моб приложение и все хорошо. Потом компания растет и вот она уже покупает другую компанию, небольшой, но успешный стартап по продаже трициклетов. А там внезапно php+mysql. А по бизнес требованиям надо чтобы оплата, регистрация и поиск были одинаковые. И письма приходили в едином стиле, в одном шаблоне. И вообще надо бы максимально теперь объединить эти проекты в один, как тут обойтись без (микро-)сервисов, без выделения регистрации, оплаты в отдельные сервисы?
Монолит классная штука, но надо понимать границы применимости такой архитектуры, как и микросервисной и я думаю, что хотя у монолита и выше скорость разработки, но у микросервисной выше скорость к слиянию с другим кодом и больше возможностей по аутсорсингу части проекта сторонним разработчикам. Да, в микросервисной большей boierplatинга и тулинга, но зато кода который надо держать в памяти (человека) и понимать как он работает - меньше.
один "блоггер" сделал сокращенную версию https://bengrosser.com/files/Techno-Optimist-Manifesto-Andreessen-redacted-by-Grosser.pdf
а Java'у не заблочат, интересно?
Какие эмоции вызывает у вас слово «переезд»?Переезд - это боль.