В проекте была необходимость строго соблюдать бюджет на инфраструктуру.
Не расскажете поподробнее - почему?
У меня такая логика в голове не укладывается - ключевое мероприятие года, а руководству главное лишнюю копейку не переплатить.
Плюс, на сколько я знаком (а знаком поверхностно) с облаками - их основная фишка как раз в возможности иметь неограниченные ресурсы, а платить только за то, сколько реально израсходовал.
поскольку недооценили нагрузки, которые предстоит принять.
Практика показывает, что задачи всегда сложнее и больше, чем кажутся на первый взгляд. И на второй взгляд тоже. Возникает вопрос, а на сколько ваша команда была опытной, что она наступила на эти, классические, грабли?
Это не претензия, это больше вопрос на тему того, как вы сами себя оцениваете. Или, как это часто бывает, кто-то в команде говорил, что нужно закладывать больше, но его мнением пренебрегли, потому что "да там же все просто".
Далеко не всегда. Вот у меня есть аналогичный "долгострой", которому недавно исполнилось 30 лет. Но при паре десятков пользователей (и вдобавок базовый язык - фортран) - кому может быть интересна такая история?
Многим. Я бы послушал. Потому что истории провалов намного более поучительны, чем истории «успешного успеха»
На своей позиции я проработал пять с половиной лет. В последнее время внедрял IDM и сильно скучал. Челленджи закончились, на неизведанные территории самостоятельно заходить нельзя — только по согласованию и под контролем.
А меня поражает обратное - когда программисту хочется попробовать технологию x, и вместо того, чтобы её попробовать дома, в свое свободное время, он внедряет её на рабочем проекте. Потом увольняется, а компания остается с технологиями a+b+c + x, где последняя нафиг не сдалась и только усложняет продукт.
Как говорится работа есть, прогресса нет. И да, винить тут можно только управленцев, рабочие абсолютно не при чем.
Как-то слышал историю, об одном банке, они свой софт 5 раз за 20 лет переделывали. Каждый раз менеджеры ставили программистов в жутко сжатые сроки, разумеется, качество шло по известному месту и через несколько лет продукт невозможно было поддерживать. Его начинали переписывать с нуля, и... опять с жутко сжатыми сроками - и опять получали тот же результат. И так пять раз! Просто впечатляющее упорство наступать на одни и те же грабли.
Строители. В строительной индустрии в себестоимости квадратного метра оплата труда — 7%. Аналогичные цифры, что и в металлургии. При этом маржа строителей — 20-30%.
И до этого не сложно догадаться по другим цифрам: о все богатеющем списке forbes, и о все падающих реальных доходах россиян.
А потом с экранов удивляются, почему страна вымирает - так из населения выкачивают все соки, а уровень зарплаты - только на еду. При чем еду очень поганого качества.
Но осознать, что на рынке дефицит людей, что мигранты уже не дешевы (да и никогда не были) и начать платить по рынку, он не может. Эта мысль просто не выживает в его голове! Как можно платить людям не 15 000, а 100 000? КАК!? Ну и что, что больше никого нет и никто не идет. Да я сам буду навоз кидать, но не смогу себя пересилить!
А что если все еще хуже, и суть не в зарплатах, а в том, что человек всю свою жизнь терпел, и не может допустить и позволить, чтобы кто-то жил? Ведь если он всю жизнь терпел и страдал - то и другие должны!
И если последнее верно, то... страну не спасти. Не потому, что этого нельзя сделать, а потому что это не позволят сделать поколения тех, кто всю жизнь терпели. Как это так - мы терпели, а они жить в свое удовольствие будут?!
Как там говорится: «Больше всего на свете рабы ненавидят не своих господ, а тех, кто стал свободным.»
И лучше не будет. В перспективе у государства не останется выбора, кроме как повышать зарплаты и начать платить
Ой, не драматизируйте. Вариантов действий - масса. Одно из них, упомянуто в статье - привлекать к работе зеков. А их количество, при необходимости, государство может всегда увеличить.
Уже примерно два года я жду релиза Yii3. Я ждал, что это будет крутой монолит, как и вторая версия, но сильно доработанная и с новыми плюшками. Но, как оказалось, Yii3 идёт вообще по другому пути.
В этом пути нет ничего необычного - фреймворк делится на отдельные компоненты, каждый из которых выполняет свою задачу.
Фреймворк Symfony написан по таким принципам, и это не мешает ему иметь "структуру папочек" по умолчанию. Впрочем, как и не мешает программистам изобретать на нем велосипеды, в которых сразу и не разберешься.
Чтобы понять в чем проблема архитектуры Yii2 (помимо прочего, и, к слову, опыт написания юнит тестов очень поможет увидеть основные проблемы) - попробуйте, например, разобраться как в нем сделана защита от csrf-атак - там один метот из одного класса, другой метод из другого класса и так во всем. Задача одна - а делается она кусочками по разным частям фреймворка. Принцип, по которому сделана симфони, и по каким принципам делается Yii3 в том, что такой размазанности ответственности не будет. Есть задача - и за эту задачу отвечает один компонент, все.
Структура "папочек" как была по умолчанию, так и останется (пусть с изменениями) в Yii3. Не в том заморачиваетесь. Я бы обратил внимание на другое - 5 лет вы заниматься разработкой на фреймворках, и не начали осваивать авто-тесты - это серьезное упущение.
Кроме того, вы не можете сказать, что DDD находится в идеальном состоянии и не имеет причин для изменений. К сожалению, низкие показатели его внедрения говорят сами за себя.
Во первых, почему не могу?
Во вторых, 90% компаний надо только «чтобы работало» - разумеется, что в такой ситуации программисты идут по пути наименьшего сопротивления и делают «тяп-ляп и в продакшен».
Уж авто-тесты то далеко не везде есть, что уж говорить о DDD.
Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?
На мой взгляд, чтобы проверить качество DDD, нужно попробовать перенести бизнесовый функционал на другой фреймворк, на другую базу (например с PostgreSQL на MongoDB или обратно) - если сделать это легко - значит спроектировано хорошо. Соответственно, ограниченный контекст - это ключевое.
А это:
Как вы думаете, какую из них будет легче понять и объяснить?
Ни о чем. Регулярные споры о DDD в телеграм-каналах показывают, что у каждого свое понятие об удобном и понятном. Если в компании выделяется время на ревью кода, если никто не встает в позу «я умный, а вы ничего не шарите» - то уже хорошо.
Пришлось выполнять работу ушедших инженеров. По неизвестным причинам их не заменили новыми. Это было абсолютное безумие. Темпы оказались непосильными.
Безумие - это работать в условиях, когда вам сели на шею, и с каждым днем устраиваются на неё все удобнее.
Когда мне выписали больничный в связи с серьёзным выгоранием, пришлось сделать перерыв. Реакция гендиректора была... неожиданной: никакого сочувствия, просьба никогда больше не болеть (иначе уволит), дробление моих акций, просьба работать больше, обвинение в том, что я никогда не участвовал в жизни компании, и т. д.
Абсолютно закономерная реакция. Если для кого-то это удивительно - значит он еще очень мало понимает в жизни.
Есть пословица - «Не делай добра - не получишь зла». Мораль в том, что когда вы начинаете делать больше, чем должны, просто так, люди к этому быстро привыкают, и воспринимают как должное. А когда халява заканчивается - оказываются очень недовольны.
На мой взгляд ключевой момент здесь - сколько человек пишет кода за рабочий день. Одно дело, если 5 тысяч строк, и другое дело - если 100 строк. В первом случае ускорение набора кода повысит эффективность работы, во втором случае - толку будет ноль.
Когда-то тоже подгорало от дурацких вопросов на собеседованиях, сейчас же наоборот - радуюсь, что люди сами себя «раскрыли», в том плане, что они не понимают, чем хороший специалист отличается от плохого.
Жизненный опыт показывает, что намного проще немного побольше потратить время на поиск работы, чем ошибиться в выборе, и пойти работать в плохую компанию/команду.
Это не софт скилл. Уточнение непонятных или странных пунктов в ТЗ - это обычная работа.
Софт скиллы, это когда ТЗ нет вообще, задачу ставят на словах, и в очень абстрактной форме, а вы потом сами ходите по отделам и разбираетесь, а что вообще нужно.
Как хорошо написали выше - софт скиллы это про бардак - когда жиры нет, про ТЗ не слышали, кто за что отвечает непонятно - в таких компаниях люди без прокачанной коммуникации просто не смогут работать.
представьте ситуацию, что нанимаете себе помощника именно вы - из своей зарплаты. Пусть за 1/10 ее. И думайте - кого бы вы к себе взяли, а кого - нет.
Как раз являюсь человеком, который на свою зарплату регулярно нанимает фрилансеров, и в недавней теме про софт скиллы - сказал, что лично мне по барабану на софт скиллы людей, которых нанимаю - главное, чтобы на выходе была качественная работа (т.е. чтобы хард скиллы были хорошими)
По итогу заминусили)
Складывается впечатление, что в разных темах разный контингент читателей сидит)
Не расскажете поподробнее - почему?
У меня такая логика в голове не укладывается - ключевое мероприятие года, а руководству главное лишнюю копейку не переплатить.
Плюс, на сколько я знаком (а знаком поверхностно) с облаками - их основная фишка как раз в возможности иметь неограниченные ресурсы, а платить только за то, сколько реально израсходовал.
Практика показывает, что задачи всегда сложнее и больше, чем кажутся на первый взгляд. И на второй взгляд тоже. Возникает вопрос, а на сколько ваша команда была опытной, что она наступила на эти, классические, грабли?
Это не претензия, это больше вопрос на тему того, как вы сами себя оцениваете. Или, как это часто бывает, кто-то в команде говорил, что нужно закладывать больше, но его мнением пренебрегли, потому что "да там же все просто".
Многим. Я бы послушал. Потому что истории провалов намного более поучительны, чем истории «успешного успеха»
У меня нет своих фильмов - потому что кинематограф мне не интересен (хотя есть знакомые, которые снимали свои фанатские корокометражки)
У меня нет своих песен, потому что ни петь ни играть на музыкальных инструментах мне не интересно (хотя есть знакомые со своими музыкальными группами)
Но у меня есть свои пет-проекты, и есть куча идей в очереди на реализацию - потому что сайты и веб-разработка мне нравится.
Мораль: нет пет-проектов - ну значит программирование для вас это просто работа. А интересы у вас в других областях.
А меня поражает обратное - когда программисту хочется попробовать технологию x, и вместо того, чтобы её попробовать дома, в свое свободное время, он внедряет её на рабочем проекте. Потом увольняется, а компания остается с технологиями a+b+c + x, где последняя нафиг не сдалась и только усложняет продукт.
Учитывая, что не все строки заканчиваются на ; - то реально строк еще больше.
Делаю свою браузерную MMORPG с 2016 года - сделано еще очень мало (основная работа съедает почти все время и силы), а когда уже 100 тысяч строк.
Ну а вообще такие долгострои по своему уникальны. Одна только история их разработки заслуживает отдельной интересной истории.
Как-то слышал историю, об одном банке, они свой софт 5 раз за 20 лет переделывали. Каждый раз менеджеры ставили программистов в жутко сжатые сроки, разумеется, качество шло по известному месту и через несколько лет продукт невозможно было поддерживать. Его начинали переписывать с нуля, и... опять с жутко сжатыми сроками - и опять получали тот же результат. И так пять раз! Просто впечатляющее упорство наступать на одни и те же грабли.
В итоге, банк закрылся.
И до этого не сложно догадаться по другим цифрам: о все богатеющем списке forbes, и о все падающих реальных доходах россиян.
А потом с экранов удивляются, почему страна вымирает - так из населения выкачивают все соки, а уровень зарплаты - только на еду. При чем еду очень поганого качества.
А что если все еще хуже, и суть не в зарплатах, а в том, что человек всю свою жизнь терпел, и не может допустить и позволить, чтобы кто-то жил? Ведь если он всю жизнь терпел и страдал - то и другие должны!
И если последнее верно, то... страну не спасти. Не потому, что этого нельзя сделать, а потому что это не позволят сделать поколения тех, кто всю жизнь терпели. Как это так - мы терпели, а они жить в свое удовольствие будут?!
Как там говорится: «Больше всего на свете рабы ненавидят не своих господ, а тех, кто стал свободным.»
Ой, не драматизируйте. Вариантов действий - масса. Одно из них, упомянуто в статье - привлекать к работе зеков. А их количество, при необходимости, государство может всегда увеличить.
В этом пути нет ничего необычного - фреймворк делится на отдельные компоненты, каждый из которых выполняет свою задачу.
Фреймворк Symfony написан по таким принципам, и это не мешает ему иметь "структуру папочек" по умолчанию. Впрочем, как и не мешает программистам изобретать на нем велосипеды, в которых сразу и не разберешься.
Чтобы понять в чем проблема архитектуры Yii2 (помимо прочего, и, к слову, опыт написания юнит тестов очень поможет увидеть основные проблемы) - попробуйте, например, разобраться как в нем сделана защита от csrf-атак - там один метот из одного класса, другой метод из другого класса и так во всем. Задача одна - а делается она кусочками по разным частям фреймворка. Принцип, по которому сделана симфони, и по каким принципам делается Yii3 в том, что такой размазанности ответственности не будет. Есть задача - и за эту задачу отвечает один компонент, все.
Структура "папочек" как была по умолчанию, так и останется (пусть с изменениями) в Yii3. Не в том заморачиваетесь. Я бы обратил внимание на другое - 5 лет вы заниматься разработкой на фреймворках, и не начали осваивать авто-тесты - это серьезное упущение.
Учитывая, что масса ресурсов - невозобновляемые, думаю что идеи использования старых, но работающих телефонов/компьютеров будут нарастать с годами.
Пока мы живем в эпоху перерабатывания ресурсов в мусор, но долго это продолжаться не будет.
Во первых, почему не могу?
Во вторых, 90% компаний надо только «чтобы работало» - разумеется, что в такой ситуации программисты идут по пути наименьшего сопротивления и делают «тяп-ляп и в продакшен».
Уж авто-тесты то далеко не везде есть, что уж говорить о DDD.
На мой взгляд, чтобы проверить качество DDD, нужно попробовать перенести бизнесовый функционал на другой фреймворк, на другую базу (например с PostgreSQL на MongoDB или обратно) - если сделать это легко - значит спроектировано хорошо. Соответственно, ограниченный контекст - это ключевое.
А это:
Ни о чем. Регулярные споры о DDD в телеграм-каналах показывают, что у каждого свое понятие об удобном и понятном. Если в компании выделяется время на ревью кода, если никто не встает в позу «я умный, а вы ничего не шарите» - то уже хорошо.
Ну и не забываем про «лучшее враг хорошего»
Как пет-проект сделанный по фану, чисто по приколу - было бы вполне неплохо.
Но когда проект с таким количеством треша в результатах так помпезно презентуется... мне не понять.
P.S. Сама идея интересная, и думаю лет через 10-20 появятся вполне хорошие генераторы изображений. Но пока - это больше похоже на генератор треша.
Безумие - это работать в условиях, когда вам сели на шею, и с каждым днем устраиваются на неё все удобнее.
Абсолютно закономерная реакция. Если для кого-то это удивительно - значит он еще очень мало понимает в жизни.
Есть пословица - «Не делай добра - не получишь зла». Мораль в том, что когда вы начинаете делать больше, чем должны, просто так, люди к этому быстро привыкают, и воспринимают как должное. А когда халява заканчивается - оказываются очень недовольны.
Под разговоры о важности человеческих жизней людям запрещают посещать медицинские учреждения. Как это мило...
В итоге имеем страну не для жизни.
Жить тяжело и неуютно
Зато уютно умирать
(с)
Даже не знаю как такое прокомментировать. Умеют люди писать!
На мой взгляд ключевой момент здесь - сколько человек пишет кода за рабочий день. Одно дело, если 5 тысяч строк, и другое дело - если 100 строк. В первом случае ускорение набора кода повысит эффективность работы, во втором случае - толку будет ноль.
А может быть они об этом и не знают.
Когда-то тоже подгорало от дурацких вопросов на собеседованиях, сейчас же наоборот - радуюсь, что люди сами себя «раскрыли», в том плане, что они не понимают, чем хороший специалист отличается от плохого.
Жизненный опыт показывает, что намного проще немного побольше потратить время на поиск работы, чем ошибиться в выборе, и пойти работать в плохую компанию/команду.
Власть развращает, абсолютная власть развращает абсолютно (с)
Это не софт скилл. Уточнение непонятных или странных пунктов в ТЗ - это обычная работа.
Софт скиллы, это когда ТЗ нет вообще, задачу ставят на словах, и в очень абстрактной форме, а вы потом сами ходите по отделам и разбираетесь, а что вообще нужно.
Как хорошо написали выше - софт скиллы это про бардак - когда жиры нет, про ТЗ не слышали, кто за что отвечает непонятно - в таких компаниях люди без прокачанной коммуникации просто не смогут работать.
Как раз являюсь человеком, который на свою зарплату регулярно нанимает фрилансеров, и в недавней теме про софт скиллы - сказал, что лично мне по барабану на софт скиллы людей, которых нанимаю - главное, чтобы на выходе была качественная работа (т.е. чтобы хард скиллы были хорошими)
По итогу заминусили)
Складывается впечатление, что в разных темах разный контингент читателей сидит)