Если импортные комплектующие выигрывают конкуренцию - значит их использование выгоднее. За эти переделанные 45% заплатят нашим рабочим и бизнесменам наши пассажиры. И поскольку пассажиров больше, чем рабочих и бизнесменов, то правильнее было бы использовать импортные комплектующие, так что вы говорите о сильно сомнительной "пользе".
МПСУ мягко говоря не славится своим научным коллективом в области психологии и в публикации по ссылке видно, что это скорее всего дипломная работа. Сбор данных, возможно, проведен корректно, но интерпретацию результатов в таком виде трудно воспринимать всерьез, может правда, может нет, исследование не слишком много проясняет.
По-моему норм опыт, в любом случае будет гораздо понятней современный мир, в котором цифровые технологии везде, плюс открываются возможности в разных профессиях вокруг IT - от IT-журналиста до проектного менеджера и т.п. Я в свое время будучи программистом прошел курсы проектного менеджмента, с тех пор проектным менеджером так ни разу не работал, но сейчас как техлид конечно же какие-то концепции оттуда использую при принятии решений и организации работы. Если есть время и силы учиться, конечно стоит пользоваться этой возможностью.
Ну и мне кажется, тут в итоге еще та же проблема, что у выпускников вузов: на работу не берут без опыта, а чтоб получить опыт, нужно устроиться на работу. Как-то люди выкручиваются, откуда-то же берутся новые специалисты с опытом.
Поэтому и существует скрам и подобные методологии - не для организации работы (разработчикам скрам не нужен), а чтобы дать "заказчикам сверху" ту степень предсказуемости, которая реально существует. Чтобы PM или техлид говорили с бизнесом на языке реалий и не обманывали друг друга вымышленными сроками. Команда для себя отщипнула от бэклога вот столько на ближайший спринт, еще в бэклоге есть столько-то задач, которые в принципе удалось оценить, по темпам работы, которые наблюдались раньше, похоже, что это еще на пару спринтов. И еще в бэклоге есть миллион задач, которые мы даже не видим смысла пока оценивать - но вы на стороне бизнеса можете каким-то из них поставить высокий приоритет, и тогда мы будем что-то отщипывать от них для следующего спринта.
Да "мир" это все осознает, но не глобально, а на местах: специалисты уходят из-за переработок, а новых набирать сложно или неудобно (надо учить и т.п.) - идешь навстречу пожеланиям тех, кто еще не ушел, куда деваться-то.
Между неблагосклонностью и принятием мироустройства есть много градаций и пространство для дипломатии. Китай не сильно любят на Западе, и мироустройство он критикует давно, но ASML запретили продавать ему литографы лишь недавно.
Насчет "слухов, которые опубликовала западная пресса" - почитайте материалы о SMIC в South China Morning Post, принадлежащей Alibaba Group и издающейся на английском в Гонконге. Там в частности есть цитаты ведущих китайских инженеров и управленцев в этой области. Китайцы вполне здраво оценивают свои перспективы и понимают, что без литографов ASML им будет очень трудно.
Вообще-то в Китае диктатура с момента прихода КПК к власти по большому счету. Но со времен Дэна там рост экономики, и основан он конечно же на капиталистической организации производства. Капитализм прекрасно сочетается с диктатурой. И государственный капитализм, если государство ведет себя как вменяемый инвестор, - это просто капитализм, который даже временами усилен доступом диктатора к власти. Не задумывались о том, что возможность для капиталиста воспользоваться ресурсами целой страны может быть конкурентным преимуществом?
Высшее образование не необходимо, но чрезвычайно полезно, и не столько интегралами и алгоритмами, сколько навыками ориентации в системах знаний и использования знаковых систем. В современных науках и прикладных областях знания структурированы на основе схожих принципов - определения понятий, связей частное-общее, обобщения на основе четко обозначенных признаков, разграничения разных аспектов рассмотрения проблемы, формальных моделей и т.д. Умение легко ими пользоваться нужно, чтобы быстрее разобраться в нагугленном примере - потому что его автор с большой вероятностью пользовался этими принципами. Это нужно, чтобы написать понятный для коллег код - ведь они ожидают использования этих принципов. Чтобы быстро сориентроваться в документации по новому инструменту, будь то CI-система, шаблонизатор или BI-хранилище. Чтобы понять, чего от вас хочет аналитик в техтребованиях. И так далее - чем больше у вас "набита рука" в ориентировке и использовании систем знания и знаковых систем, тем быстрее вы будете переходить к "существу вопроса", к сложным кейсам, к взвешиванию разных вариантов решения задачи - к тому, что отличает сеньора от мидла.
Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
Вы просто не улавливаете определенных культурных особенностей, формально вы все правильно пишете, и более того, описанные вами в первой статье приемы работают, но не оптимальны, вы просто, извините, задолбаетесь так работать, выгорите еще до первого повышения xD Да, решать вопросы с привлечением руководителя - это "против лома нет приема", но это долго. Красный цвет действует, но когда в ваших сообщениях все к нему привыкнут и перестанут замечать, как вы будете дальше писать - красным жирным капсом? xD И так далее. Но с другой стороны, чем больше вы будете упорствовать в своей стратегии, тем быстрее набьете нужное число шишек, чтобы ее поменять, и поскольку вы джун, то для вас это естественно. И даже не странно для джуна писать статьи о том, чего он не понимает - для вас естественно не понимать, что вы не понимаете xD Но вот что мы это читаем и возмущенно комментируем - это поистине странно. Но так, видимо, работают медиа - чем дебильней и несущественней обсуждение, тем больше желания к нему присоединиться xD
Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
Скорее всего в том типе компании, которую описывает автор поста, после такой просьбы к руководителю вам предстоит еще общение с вашим руководителем на тему "а все ли у вас в порядке, а уверены ли вы, что без чрезмерного труда справляетесь с рабочими задачами" и потом, вероятно, также общение с сотрудником HR-отдела на ту же тему, возможно с "очной ставкой" с этим самым человеком, с которым вы отказались работать. Потому что конечно же для более-менее отлаженной организации отказываться с кем-либо работать не то чтобы ненормально, но вызывает большие напряжения у менеджмента, который начинает переживать, что не все отлажено. Причем ваш руководитель будет понимать, что за той же инфой аналитик придет к нему, если вы откажетесь с ним общаться, так что вашему руководителю будет гораздо удобнее наладить ваше взаимодействие с аналитиком.
Ответом по существу будет "отказать с объяснением, почему отказано", тогда и поход к руководителю, возможно, не нужен будет. Задача аналитика, который к вам пришел, - сделать так, чтобы вам выгоднее было выдать максимум информации, чтобы от вас отвязались. Ведь его работа - собирать и агрегировать инфу, и в особенности на ранних этапах профессионального развития ему важно с вас стрясти максимум информации, чтобы как нейросеть на ее объеме обучаться.
Руководитель, кстати, скорее встанет тут на сторону аналитика по той же причине, - ему проще выдать аналитику максимум инфы, чтобы не менеджерить общение с ним до бесконечности, и потом получить адекватные требования для подготовки задач в работу, потому что от аналитиков в первую очередь зависит качество требований.
Если импортные комплектующие выигрывают конкуренцию - значит их использование выгоднее. За эти переделанные 45% заплатят нашим рабочим и бизнесменам наши пассажиры. И поскольку пассажиров больше, чем рабочих и бизнесменов, то правильнее было бы использовать импортные комплектующие, так что вы говорите о сильно сомнительной "пользе".
Излагать мысли на JS автору удается хоть и не идеально, но лучше, чем на русском языке, так что лучше ему и дальше писать код, а не статьи.
"Даже" FSR превзошла. Уоу. Про DLSS в их альтернативной реальности никто не слыхал.
МПСУ мягко говоря не славится своим научным коллективом в области психологии и в публикации по ссылке видно, что это скорее всего дипломная работа. Сбор данных, возможно, проведен корректно, но интерпретацию результатов в таком виде трудно воспринимать всерьез, может правда, может нет, исследование не слишком много проясняет.
По-моему норм опыт, в любом случае будет гораздо понятней современный мир, в котором цифровые технологии везде, плюс открываются возможности в разных профессиях вокруг IT - от IT-журналиста до проектного менеджера и т.п. Я в свое время будучи программистом прошел курсы проектного менеджмента, с тех пор проектным менеджером так ни разу не работал, но сейчас как техлид конечно же какие-то концепции оттуда использую при принятии решений и организации работы. Если есть время и силы учиться, конечно стоит пользоваться этой возможностью.
Ну и мне кажется, тут в итоге еще та же проблема, что у выпускников вузов: на работу не берут без опыта, а чтоб получить опыт, нужно устроиться на работу. Как-то люди выкручиваются, откуда-то же берутся новые специалисты с опытом.
Поэтому и существует скрам и подобные методологии - не для организации работы (разработчикам скрам не нужен), а чтобы дать "заказчикам сверху" ту степень предсказуемости, которая реально существует. Чтобы PM или техлид говорили с бизнесом на языке реалий и не обманывали друг друга вымышленными сроками. Команда для себя отщипнула от бэклога вот столько на ближайший спринт, еще в бэклоге есть столько-то задач, которые в принципе удалось оценить, по темпам работы, которые наблюдались раньше, похоже, что это еще на пару спринтов. И еще в бэклоге есть миллион задач, которые мы даже не видим смысла пока оценивать - но вы на стороне бизнеса можете каким-то из них поставить высокий приоритет, и тогда мы будем что-то отщипывать от них для следующего спринта.
Уже не идет, введена 100% пошлина на ввоз китайских автомобилей. Они оказались слишком конкурентоспособны.
Буквально то же самое хотел написать. Вообще никакой кошкожены, даже ни намека.
Да "мир" это все осознает, но не глобально, а на местах: специалисты уходят из-за переработок, а новых набирать сложно или неудобно (надо учить и т.п.) - идешь навстречу пожеланиям тех, кто еще не ушел, куда деваться-то.
Непонятно, причем тут совковые конторы и формальная информация с сайта компании, такая ситуация может случиться где угодно.
Между неблагосклонностью и принятием мироустройства есть много градаций и пространство для дипломатии. Китай не сильно любят на Западе, и мироустройство он критикует давно, но ASML запретили продавать ему литографы лишь недавно.
Насчет "слухов, которые опубликовала западная пресса" - почитайте материалы о SMIC в South China Morning Post, принадлежащей Alibaba Group и издающейся на английском в Гонконге. Там в частности есть цитаты ведущих китайских инженеров и управленцев в этой области. Китайцы вполне здраво оценивают свои перспективы и понимают, что без литографов ASML им будет очень трудно.
Вообще-то в Китае диктатура с момента прихода КПК к власти по большому счету. Но со времен Дэна там рост экономики, и основан он конечно же на капиталистической организации производства. Капитализм прекрасно сочетается с диктатурой. И государственный капитализм, если государство ведет себя как вменяемый инвестор, - это просто капитализм, который даже временами усилен доступом диктатора к власти. Не задумывались о том, что возможность для капиталиста воспользоваться ресурсами целой страны может быть конкурентным преимуществом?
У ангуляра довольно много всего изменилось. И у тайпскрипта, который нужен для ангуляра и разных других вещей, тоже прилично поменялось всего.
Высшее образование не необходимо, но чрезвычайно полезно, и не столько интегралами и алгоритмами, сколько навыками ориентации в системах знаний и использования знаковых систем. В современных науках и прикладных областях знания структурированы на основе схожих принципов - определения понятий, связей частное-общее, обобщения на основе четко обозначенных признаков, разграничения разных аспектов рассмотрения проблемы, формальных моделей и т.д. Умение легко ими пользоваться нужно, чтобы быстрее разобраться в нагугленном примере - потому что его автор с большой вероятностью пользовался этими принципами. Это нужно, чтобы написать понятный для коллег код - ведь они ожидают использования этих принципов. Чтобы быстро сориентроваться в документации по новому инструменту, будь то CI-система, шаблонизатор или BI-хранилище. Чтобы понять, чего от вас хочет аналитик в техтребованиях. И так далее - чем больше у вас "набита рука" в ориентировке и использовании систем знания и знаковых систем, тем быстрее вы будете переходить к "существу вопроса", к сложным кейсам, к взвешиванию разных вариантов решения задачи - к тому, что отличает сеньора от мидла.
Если это воспринимать как метафору, т.е. "DDD - это как микросервисная архитектура, но для наших ментальных моделей, отражаемых в коде, а не для самого кода и его технологической обвязки", то это довольно удачная метафора, не описывает все DDD, но указывает на ключевые вещи. Но у вас в статье получилось слишком буквальное сравнение, что понятно - вы старались донести действительно удачную метафору. Все возражения как мне кажется по поводу этой буквальности. Но для начала обсуждения неплохо. Скажем вы пишете в ответе на другой коммент: "И не превратится ли это "много" в очередную монструозную систему на базе кубера?" - хороший вопрос! Но бывают действительно сложные предметные области, в которых тесно переплетены многие сущности. И ведь именно для таких областей наши информационные системы могут оказаться особенно полезны - если мы хоть немного помогли справиться со сложностью, то мы герои. И вот для таких сложных случаев и нужны, скажем, паттерны из "синей книги" - там ведь не только про то, что надо разделять и властвовать, но и про связи между компонентами - как добавлять эти связи так, чтобы не получилось "монструозного кубера". На ютубе есть выступление Эванса как раз про микросервисы и DDD кстати.
Вы просто не улавливаете определенных культурных особенностей, формально вы все правильно пишете, и более того, описанные вами в первой статье приемы работают, но не оптимальны, вы просто, извините, задолбаетесь так работать, выгорите еще до первого повышения xD Да, решать вопросы с привлечением руководителя - это "против лома нет приема", но это долго. Красный цвет действует, но когда в ваших сообщениях все к нему привыкнут и перестанут замечать, как вы будете дальше писать - красным жирным капсом? xD И так далее. Но с другой стороны, чем больше вы будете упорствовать в своей стратегии, тем быстрее набьете нужное число шишек, чтобы ее поменять, и поскольку вы джун, то для вас это естественно. И даже не странно для джуна писать статьи о том, чего он не понимает - для вас естественно не понимать, что вы не понимаете xD Но вот что мы это читаем и возмущенно комментируем - это поистине странно. Но так, видимо, работают медиа - чем дебильней и несущественней обсуждение, тем больше желания к нему присоединиться xD
Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
Скорее всего в том типе компании, которую описывает автор поста, после такой просьбы к руководителю вам предстоит еще общение с вашим руководителем на тему "а все ли у вас в порядке, а уверены ли вы, что без чрезмерного труда справляетесь с рабочими задачами" и потом, вероятно, также общение с сотрудником HR-отдела на ту же тему, возможно с "очной ставкой" с этим самым человеком, с которым вы отказались работать. Потому что конечно же для более-менее отлаженной организации отказываться с кем-либо работать не то чтобы ненормально, но вызывает большие напряжения у менеджмента, который начинает переживать, что не все отлажено. Причем ваш руководитель будет понимать, что за той же инфой аналитик придет к нему, если вы откажетесь с ним общаться, так что вашему руководителю будет гораздо удобнее наладить ваше взаимодействие с аналитиком.
Ответом по существу будет "отказать с объяснением, почему отказано", тогда и поход к руководителю, возможно, не нужен будет. Задача аналитика, который к вам пришел, - сделать так, чтобы вам выгоднее было выдать максимум информации, чтобы от вас отвязались. Ведь его работа - собирать и агрегировать инфу, и в особенности на ранних этапах профессионального развития ему важно с вас стрясти максимум информации, чтобы как нейросеть на ее объеме обучаться.
Руководитель, кстати, скорее встанет тут на сторону аналитика по той же причине, - ему проще выдать аналитику максимум инфы, чтобы не менеджерить общение с ним до бесконечности, и потом получить адекватные требования для подготовки задач в работу, потому что от аналитиков в первую очередь зависит качество требований.