Проблему с gitversion ещё можно решить, если в csproj файле билд проекта изменить референс на актуальную версию тулинга, то есть с 5.5.1 на 5.6.1+ и тогда все заработает и на net5.
Интересная тема, спасибо. В общем чуть более чем полностью согласен. Моё скромное мнение заключается в том, что сложность бывает двух типов: естественная сложность автоматизируемого бизнес процесса и искусственная сложность привнесенных абстракций, фоеймверков и прочего, прочего, прочего. Задача проектирования — реализовать естественную сложность в некотором управляемом виде при этом, по возможности, не привнести искусственную сложность. Эту идею можно выразить в простом ритуале — каждый раз добавляя в дизайн приложения новый элимент, нужно спросить себя позволяет ли этот элемент упростить работу с бизнес логикой и если да, то можно ли добиться этого же результата проще? Конечно бывают крайние случаи, когда нам нужно выживать под нагрузкой например. Но тем не менее.
И не много критики.
Про Дашу и бизнес логику. Тут есть обратная сторона в картинке. 80% стека вызовов это фреймверк, то есть общий код, который ты по идее не должен трогать совсем. А вот бизнес логика это 20% которые должны быть довольно простые. Если отказаться от этих 80%, то придётся добавить к бизнес логике ручную работу с транзакциями, безопасность, работу с бд. Не факт, что получится проще.
Ну и ещё один момент. Простые решения требуют непрерывного рефакторинга. В случае, если мы написали код в методе контроллера и наше приложение осталось простым, то мы выиграли, сэкономили кучу времени. Но если приложение начало расти? Где та грань, когда нужно начинать переходить от простых решений к сложными? Когда контроллера два? Когда их 10? Проблема в том, что обычно тебя просят дописать один метод, потом второй. И каждый раз ты думаешь, что это всего то ещё одна фича, ничего страшного. А потом приходится в какой-то момент рефакторить монстра из лапши на тысячи строк кода. Собственно по этому часто и делают оверинжиниринг на будущее, потому что боятся, что потом не будет времени на рефакторинг и надо брать это время пока дают. Не сказал бы, что это хорошо. Лучше когда на каждую фичу закладывается время на рефакторинг, тогда можно идти от простых решений к сложными по необходимости и без проектирования на будущее.
посмотреть как другие люди готовят свои проекты, какую архитектуру используют, посоветовать и обсудить свои решения. а еще очень полезно когда изучаешь новый язык, например с С++ перешел на python, а там немного другой подход к разработке и проектированию, другие стандарты кодирования, другая философия, лучшей способ в данном случае быстро понять как принято писать в сообществе, это посмотреть стрим уже опытного разработчика на python.
А я и задаю эти самые вопросы на собеседование, в результате поиск сотрудников на вакантное место затягивается на месяцы(прошлый раз 4ре), да вот только работы в этим месяцы меньше не становится. А если нужен специалист с нераспространенными компетенциями, то поиски могут окончится ничем(по крайней мере в условиях ограниченного бюджета). Поэтому я и написал, что вопрос стоит довольно остро.
Во первых, что значит потребительское отношение и почему это плохо? Я работник, мне платят деньги, я решаю задачи, моя выгода работать меньше \ над интересными проектами, а получать денег больше. Я работодатель, я плачу работнику деньги за решенные задачи, моя выгода получить решенных задач больше \ решения качественней, а заплатить денег меньше. Мне кажется тут правила ясны, потребительское отношение с двух сторон. В идеальной ситуации можно прийти к компромиссу.
Второй момент, перебежки сотрудников, джунов. Может дело действительно в компании? Я бы даже осмелился предположить, что в специфики наших ИТ-компаний. Кейс из личного опыта. Пришел я джуном в компанию Х, компания большая, известная, не гос. сектор, а там ни баг-трекера, контроль версий древний и больше мешает, процесса четкого нет, тестов нет, архитектуры никакой нет, в общем классическая хаотичная разработка. Через кучу нервов, споров и перемогание сопротивления коллеги и руководства удалось внедрить Youtrack + TeamCity + Mercurial, написать тесты, поднять свой nuget-сервер и навести порядок в коде и архитектуре(хвалится этим конечно нельзя было, но уже можно было смотреть без слез). Всем в конечном итоге все понравилось, продуктивность команды повысилась, но спасибо никто не сказал. Через пару лет история повторилась только в компании Y, опять кучу нервов и сопротивления, спасибо никто не сказал. Сейчас я поумнел и ищу работодателя, который сам понимает важность налаженного процесса разработки. Супергероем который всех спасает вопреки их желанию быть больше не желаю, идет 2016 все же. Так вот, может перебежки сотрудников обусловлены не их негативными качествами, а проблемами в компаниях? Тем более, что джуны еще не обладают достаточным опытом, чтобы сформулировать и задать нужные вопросы, которые помогут понять, как на самом деле обстоят дела.
PS: на самом деле я не отрицаю обозначенные в статье проблемы, довольно много провожу собеседований, сейчас руковожу командой разработчиков, насмотрелся всякого. Проблема не добросовестных, не компетентных, не мотивированных соискателей \ сотрудников имеет место быть и стоит довольно остро. Просто считаю, что ситуацию стоит рассматривать комплексно, с разных углов.
Очень интересный момент, кстати. А как дела обстоят с dotnet core? Я так полагаю, там нет подобных ограничений, ведь он вроде как кроссплатформенный и должен запускаться в числе прочих на linux, может тогда стоит сразу ориентироваться на него?
Я не уверен, что модульность так уж нужна, это может породить проблемы — кучу пакетов реализующих одно и тоже из ныне стандартной библиотеки, ад зависимостей как следствие. Конечно для мобильных платформ и микроконтроллеров это плюс, можно поставлять и разворачивать только нужное и экономить место, но есть мнение, что память дешевле программистов. Но пока рано судить, посмотрим что будет в релизе, попадет ли туда mscorelib и самое главное в каком виде.
Я так понимаю, что основная идея core это возможность устанавливать рантаймы и упаковывать их вместе с приложениями, то есть более платформа не прибита гвоздями к ОС и стала достаточно легковесной. Это большой шаг, отсюда и новое название, хотя конечно вся эта история с переименованием очень путает.
Если смотреть какими темпами меняется api, устаревание во время разработки тут явно не грозит. ) Но в целом да, уж очень не терпится.
Вообще сейчас очень ответственный этап, излишняя спешка может оказаться фатальной в будущем. Так что как по мне, пусть уж лучше выпустят релиз через год или два, чем налажают. Споры и дебаты в такой период нормальны, даже некоторая доля хаоса и анархии, никто же не знает как будет идеально, вот и пытаются общим умом и через RCxxx выяснить.К слову большая часть изменений в RC2 мне нравится, я думаю что идут в правильном направлении.
В общем полностью согласен, но ИМХО думаю, что не на python, а на PowerShell, все же PS есть на любом виндовом сервере, все средства из коробки, нет необходимости ставить python
Ну это как публичное одобрение или порицание мировым сообществом. Есть мнение, что во время суда это решение может оказать давление на судей и присяжных, что в итоге закончится оправдательным приговором.
выглядит интересно, но есть два вопроса:
1. если не секрет, то сколько в сумме было затрачено времени и денег на производство?
2. проводились ли испытания надежности конструкции? выдержит ли два монитора + кронштейны + ноутбук и если я еще и обопрусь на столешницу вдобавок?
Проблему с gitversion ещё можно решить, если в csproj файле билд проекта изменить референс на актуальную версию тулинга, то есть с 5.5.1 на 5.6.1+ и тогда все заработает и на net5.
Интересная тема, спасибо. В общем чуть более чем полностью согласен. Моё скромное мнение заключается в том, что сложность бывает двух типов: естественная сложность автоматизируемого бизнес процесса и искусственная сложность привнесенных абстракций, фоеймверков и прочего, прочего, прочего. Задача проектирования — реализовать естественную сложность в некотором управляемом виде при этом, по возможности, не привнести искусственную сложность. Эту идею можно выразить в простом ритуале — каждый раз добавляя в дизайн приложения новый элимент, нужно спросить себя позволяет ли этот элемент упростить работу с бизнес логикой и если да, то можно ли добиться этого же результата проще? Конечно бывают крайние случаи, когда нам нужно выживать под нагрузкой например. Но тем не менее.
И не много критики.
Про Дашу и бизнес логику. Тут есть обратная сторона в картинке. 80% стека вызовов это фреймверк, то есть общий код, который ты по идее не должен трогать совсем. А вот бизнес логика это 20% которые должны быть довольно простые. Если отказаться от этих 80%, то придётся добавить к бизнес логике ручную работу с транзакциями, безопасность, работу с бд. Не факт, что получится проще.
Ну и ещё один момент. Простые решения требуют непрерывного рефакторинга. В случае, если мы написали код в методе контроллера и наше приложение осталось простым, то мы выиграли, сэкономили кучу времени. Но если приложение начало расти? Где та грань, когда нужно начинать переходить от простых решений к сложными? Когда контроллера два? Когда их 10? Проблема в том, что обычно тебя просят дописать один метод, потом второй. И каждый раз ты думаешь, что это всего то ещё одна фича, ничего страшного. А потом приходится в какой-то момент рефакторить монстра из лапши на тысячи строк кода. Собственно по этому часто и делают оверинжиниринг на будущее, потому что боятся, что потом не будет времени на рефакторинг и надо брать это время пока дают. Не сказал бы, что это хорошо. Лучше когда на каждую фичу закладывается время на рефакторинг, тогда можно идти от простых решений к сложными по необходимости и без проектирования на будущее.
вы отстали от жизни, CLR теперь запускается на всех основных платформах. )
Во первых, что значит потребительское отношение и почему это плохо? Я работник, мне платят деньги, я решаю задачи, моя выгода работать меньше \ над интересными проектами, а получать денег больше. Я работодатель, я плачу работнику деньги за решенные задачи, моя выгода получить решенных задач больше \ решения качественней, а заплатить денег меньше. Мне кажется тут правила ясны, потребительское отношение с двух сторон. В идеальной ситуации можно прийти к компромиссу.
Второй момент, перебежки сотрудников, джунов. Может дело действительно в компании? Я бы даже осмелился предположить, что в специфики наших ИТ-компаний. Кейс из личного опыта. Пришел я джуном в компанию Х, компания большая, известная, не гос. сектор, а там ни баг-трекера, контроль версий древний и больше мешает, процесса четкого нет, тестов нет, архитектуры никакой нет, в общем классическая хаотичная разработка. Через кучу нервов, споров и перемогание сопротивления коллеги и руководства удалось внедрить Youtrack + TeamCity + Mercurial, написать тесты, поднять свой nuget-сервер и навести порядок в коде и архитектуре(хвалится этим конечно нельзя было, но уже можно было смотреть без слез). Всем в конечном итоге все понравилось, продуктивность команды повысилась, но спасибо никто не сказал. Через пару лет история повторилась только в компании Y, опять кучу нервов и сопротивления, спасибо никто не сказал. Сейчас я поумнел и ищу работодателя, который сам понимает важность налаженного процесса разработки. Супергероем который всех спасает вопреки их желанию быть больше не желаю, идет 2016 все же. Так вот, может перебежки сотрудников обусловлены не их негативными качествами, а проблемами в компаниях? Тем более, что джуны еще не обладают достаточным опытом, чтобы сформулировать и задать нужные вопросы, которые помогут понять, как на самом деле обстоят дела.
PS: на самом деле я не отрицаю обозначенные в статье проблемы, довольно много провожу собеседований, сейчас руковожу командой разработчиков, насмотрелся всякого. Проблема не добросовестных, не компетентных, не мотивированных соискателей \ сотрудников имеет место быть и стоит довольно остро. Просто считаю, что ситуацию стоит рассматривать комплексно, с разных углов.
Я так понимаю, что основная идея core это возможность устанавливать рантаймы и упаковывать их вместе с приложениями, то есть более платформа не прибита гвоздями к ОС и стала достаточно легковесной. Это большой шаг, отсюда и новое название, хотя конечно вся эта история с переименованием очень путает.
Если смотреть какими темпами меняется api, устаревание во время разработки тут явно не грозит. ) Но в целом да, уж очень не терпится.
1. если не секрет, то сколько в сумме было затрачено времени и денег на производство?
2. проводились ли испытания надежности конструкции? выдержит ли два монитора + кронштейны + ноутбук и если я еще и обопрусь на столешницу вдобавок?