я не знаю, какими критериями вы руководствовались, я лишь грубо их сопоставил. Тем более Spring — это вообще комбайн решений, поэтому да, он в сравнении впереди планеты всей. Глубокий анализ я не проводил, да и не хочу, ибо на стеке java ee писал последний раз более 3х лет назад.
Но я с радостью (это без сарказма) почитал бы информацию, на которой основывается ваше мнение, если оно не ограничивается только личным опытом.
догоняющего в плане коммунити — возможно и так. В плане технологий — точно нет. Как я уже заметил, написать альтернативу тому же ASP.NET vNext как есть альтернатива в виде Spring для JEE, — задача, которая ставит сообщество в догоняющие, пока не сделает действительно достойный форк основного стека, который далеко ушел от оригинала
как только выйдет ASP.NET vNext также opensource-проектом, ничто не мешает (если лицензия позволяет, не помню, что они там заявляли) делать форки с лучшими с точки зрения коммунити решениями на базе существующей кодовой базы.
а нужна ли эти альтернативы, если в мире .NET они будут кое-как поспевать за родным стеком MS? Тем более ASP.NET с легкостью можеть потягаться со Spring.
расскажите, как разрешается следующая ситуация:
появляются новые feature-branches (fb) из dev-branch (dev). Но изменения в одной из них влияют на работу и реализацию в другой (т.е. функционально они слабо связаны, но тем не менее взаимное влияние у них имеется, например, использованием новой версии протокола, которое в одной fb обкатано, но функциональность из другой ветки может поломаться при вливании их обеих в dev). Что в таком случае делать? По описанию feature-branches друг в друга не вливаются, только лишь из/в dev. Допустим, влили мы обе fb в dev, что-то сломалось, порождается новая fb из dev типа «латание косяков после слияния fb1 и fb2» или же каждая из fb (или какая-то одна) забирает изменения из dev и латает косяки у себя с последующим возвратом изменений в dev?
В случае с asp.net проектами можно создать несколько трансформаций Web.config для каждой конфигурации. При деплое трансформация применялась к исходному Web.config (анпример, prod-база вместо dev) и уже в таком виде он публиковался на сервер/в пакет.
давным-давно кодил на php, в последнее время занимаюсь разработкой на asp.net и вот несколько удивил подход нового компилятора.
В php я имел дело с файлами исходного кода, в asp.net имею дело со сборками. И тут тебе как гром среди ясного неба: в asp.net тоже теперь исходники безо всяких сборок благодаря новому компилятору Roslyn. Даже не знаю, шаг ли это вперед или просто такое забавное совпадение, ограничивающееся только поверхностым сходством.
И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками? Связывание с ними происходит перед построением IL-кода новым компилятором? Т.е. как в случае с View в MVC: тоже имеем дело сперва с исходниками, которые потом самим IIS преобразуются в сборку?
и ещё один вопрос не в этой ветке: такие гибкие механизмы как трансформации нам дадут сразу же или придётся ждать следующей версии?
не воспринимайте первый вопрос всерьёз, он был задан исключительно из любопытства :)
что касается второго: получается нет у вас некой группы из команд разных продуктов, занимающихся генерацией новых плюшек либо возможностью и необходимостью внедрения фич одного продукта в другом?
У JetBrains'а нет отдела продаж, занимающегося в т.ч. маркетингом? Какая разница, для кого продукт. Пишут его всё равно люди одной и той же специальности. Давайте понаблюдаем за Visual Studio, какая после 2013 (которая пронумерована как 12) выйдет версия.
повторюсь, как показывают наблюдения. Примеры: Опера и Офис от MS (оба пропустили 13 версию).
Создавая продукт, «Профессионалы, которые работают с трезвой логикой, чёткими расчётами и алгоритмами», порой ведутся на различные суеверия. Надеюсь, пруфы не надо?
Есть 2 оффтоп-вопроса:
1. Как показывают наблюдения, айтишники порой люди суеверные. Как вы решились выпустить 13 версию, а не сразу 14? Знаю, что вопрос может запоздалый, вышла уже вторая минорная версия;
2. Есть какая-то связь между появлениями фич в IDEA и Resharper'е? Есть ли закономерность, что сперва они появляются в первой, а уже потом во втором? Очень понравилась штука POSTFIX CODE COMPLETION.
так я не столько о постах говорил, сколько о комментариях к ним, к этому и употребил «большим кол-вом участников» и «холивар».
Тесты как правило пишутся вперёд, поэтому о каком неоплачиваемом времени идёт речь — не совсем понимаю. В голове представляется картина, как разработчики прежде чем писать код, в нерабочее время проектируют систему и пишут по кейсам тесты. А в остальное время занимаются простым кодингом, с которым и обычный индус справится.
Что касается упорства начальства, так тут проблема возможно даже и не в использовании методологии, а неумении «продать» её применение начальству. Во всяком случае никто не мешает заложить это время в общую разработку (собственно, это и есть часть разработки). И если уж сроки всегда и строго, даже с точностью до итерации, устанавливает начальство, то это уже рабство какое-то
если тестировщиков нет, их обязанности берут на себя разработчики, но даже в таком случае данный этап располагается в самом конце очередной итерации разработки.
По поводу как проверять код — разумеется каждый склонен выбирать сам, нет какого-то уголовного кодекса по нарушению каких-то правил. Есть устоявшиеся, хорошие практики, подтвержденные и проверенные неоднократно и не вчера. Им можно следовать. Но никто не запрещает от них отходить. Только если такие отклонения идут вразрез с практиками, грешить на них точно не следует. Советую вам найти посты на хабре, посвященные тому же TDD. Там тема нашего с вами холивара развёрнута гораздо шире, глубже и большим кол-вом участников. Есть, кстати, даже целые притчи. Там уже определитесь, на чьей стороне вы, с кем согласны и с кем нет. Я свою позицию выбрал.
И нет тут единого мнения, которое устраивало бы всех.
разумеется. Но даже в таком случае это достаточно утомительное занятие и по идее вообще работа не разработчиков, а тестеров. Просто в описанном вами случае ответственность смазывается, а разработчик так вообще занят не своим делом, впридачу код пишется маленькими итерациями, каждый шаг необходимо проверять. А проверять запуском — откровенное расточительство временем.
да, но это совсем другой вид тестов. Быть может я отхожу от общепринятой терминологии, но у меня подобные тесты закрепились под название функциональные. И порой прогнать целый такой тест утомительно и отнимает уйму времени. Особенно если речь идет о приложениях с графическим интерфейсом
сделал выводы, что вы одним только взглядом сразу видите правилен код или нет, значит можете в уме его откомпилировать на предмет корректности поведения
ладно, бог с ним с этим. Вы первый человек из тех, кого я встретил, который сразу пишет корректный код без ошибок, самодокументируемый, по которому сразу понятен весь алгоритм, и при этом временнЫе затраты максимально снижены
Но я с радостью (это без сарказма) почитал бы информацию, на которой основывается ваше мнение, если оно не ограничивается только личным опытом.
появляются новые feature-branches (fb) из dev-branch (dev). Но изменения в одной из них влияют на работу и реализацию в другой (т.е. функционально они слабо связаны, но тем не менее взаимное влияние у них имеется, например, использованием новой версии протокола, которое в одной fb обкатано, но функциональность из другой ветки может поломаться при вливании их обеих в dev). Что в таком случае делать? По описанию feature-branches друг в друга не вливаются, только лишь из/в dev. Допустим, влили мы обе fb в dev, что-то сломалось, порождается новая fb из dev типа «латание косяков после слияния fb1 и fb2» или же каждая из fb (или какая-то одна) забирает изменения из dev и латает косяки у себя с последующим возвратом изменений в dev?
В php я имел дело с файлами исходного кода, в asp.net имею дело со сборками. И тут тебе как гром среди ясного неба: в asp.net тоже теперь исходники безо всяких сборок благодаря новому компилятору Roslyn. Даже не знаю, шаг ли это вперед или просто такое забавное совпадение, ограничивающееся только поверхностым сходством.
И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками? Связывание с ними происходит перед построением IL-кода новым компилятором? Т.е. как в случае с View в MVC: тоже имеем дело сперва с исходниками, которые потом самим IIS преобразуются в сборку?
и ещё один вопрос не в этой ветке: такие гибкие механизмы как трансформации нам дадут сразу же или придётся ждать следующей версии?
что касается второго: получается нет у вас некой группы из команд разных продуктов, занимающихся генерацией новых плюшек либо возможностью и необходимостью внедрения фич одного продукта в другом?
Создавая продукт, «Профессионалы, которые работают с трезвой логикой, чёткими расчётами и алгоритмами», порой ведутся на различные суеверия. Надеюсь, пруфы не надо?
1. Как показывают наблюдения, айтишники порой люди суеверные. Как вы решились выпустить 13 версию, а не сразу 14? Знаю, что вопрос может запоздалый, вышла уже вторая минорная версия;
2. Есть какая-то связь между появлениями фич в IDEA и Resharper'е? Есть ли закономерность, что сперва они появляются в первой, а уже потом во втором? Очень понравилась штука POSTFIX CODE COMPLETION.
Тесты как правило пишутся вперёд, поэтому о каком неоплачиваемом времени идёт речь — не совсем понимаю. В голове представляется картина, как разработчики прежде чем писать код, в нерабочее время проектируют систему и пишут по кейсам тесты. А в остальное время занимаются простым кодингом, с которым и обычный индус справится.
Что касается упорства начальства, так тут проблема возможно даже и не в использовании методологии, а неумении «продать» её применение начальству. Во всяком случае никто не мешает заложить это время в общую разработку (собственно, это и есть часть разработки). И если уж сроки всегда и строго, даже с точностью до итерации, устанавливает начальство, то это уже рабство какое-то
По поводу как проверять код — разумеется каждый склонен выбирать сам, нет какого-то уголовного кодекса по нарушению каких-то правил. Есть устоявшиеся, хорошие практики, подтвержденные и проверенные неоднократно и не вчера. Им можно следовать. Но никто не запрещает от них отходить. Только если такие отклонения идут вразрез с практиками, грешить на них точно не следует. Советую вам найти посты на хабре, посвященные тому же TDD. Там тема нашего с вами холивара развёрнута гораздо шире, глубже и большим кол-вом участников. Есть, кстати, даже целые притчи. Там уже определитесь, на чьей стороне вы, с кем согласны и с кем нет. Я свою позицию выбрал.
И нет тут единого мнения, которое устраивало бы всех.
Но, на самом деле. это тема холиварная :)