Интересно будет ли разработка под шарпонт онлайн такой-же, очень мягко говоря, занозой в мягком месте. И как будут обстоять дела с тестируемостью кода, а то для классического шарпона это просто беда.
Скажите пожалуйста, планируете ли вы добавить в IDEA решения типа Continuous Testing, на подобие того что команда из R# добавит в DotCover след версии? Заранее благодарен за информацию.
В опросе не было про кейс когда программирование это моя страсть но по воле судеб приходиться заниматься не программирование а черт знает чем типа vb.net, tsql и sharepoint.
Тут я с вами (увж автор) не соглашусь, readonly пресекают изменяемость на корню а вот private set просто не позволяют изменить содержимое снаружи класса. В плане читаемости, когда видишь такое дело тут же ждешь подвоха, а нет ли тут moving parts которые провоцируются внутренним поведением класса.
Скажите а можно ли моки создавать в StrictMode без особой пляски с бубном?
Кстати создатель AutoFixture, Марк Зиман сейчас активно подался на поприще F# и всячески его пропагандирует, я встречал его на одной конференции в Белгии, этой весной.
Нет вы не правы, читайте внимательнее. Все вышеуказанное в той или иной мере одно и тоже для конечного пользователя. Я право не совсем понял что вы хотели сказать этим: «Повторюсь еще раз сравнивать что лучше можно лишь в одной категории».
Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.
Ну как же, возраст не показатель, отсутствие пульса не показатель да и концептуальные упущения путешествующие из n-1 в n не показатель тогда ivy не устарел. Что тогда для вас считается основанием полагать устарел он или нет?
Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
Я не знаю, я бы не стал полагаться просто на авось в данной ситуации. Обычно мажорные релизы на то и мажорные что не соблюдают обратной совместимости, и могут все поломать включая repositories>repository и mirrorOf итд.
Мне кажется, решение это когда производитель (в данном случае мувен) гарантирует вам что данное решение им поддерживается и все будет работать как следует при переходе от версии к версии. Иначе это workaround, по моему.
Да конечно. Дальше можно углубляться в размышления что если бы… Да оппоненты у мувена сейчас есть. Ведь не реально уговорить какой нибудь сбербанк потратить кучу денег на просто переход с мувена на gradle только по прихоти программистов. А вот обновится с одной версии на другую это проходит не так болезненно.
Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.
Имеется в виду использование различных репозиториев, чем их больше тем время скачивания увеличивается. Костыль для этого сводился к установке одного центрального, буфер репозитория. Я сейчас не помню что за фирма сопровождала данный проект.
На мой взгляд он просуществовал столько лет из за отсутствия конкурентов. В нем были допущены ошибки на концептуальном уровне, и данные ошибки плавают от версии к версии, что в конце концов и парализовало развитие проекта на долгие годы. Мало того что ван Зил не хотел обращать внимание на свои упущения так он еще дальше увязал в них и тянул за собой пользователей мувена. Один из ярких примеров при переходе с 2 на 3 версию, а давай ка братец вместо того что бы скачивать половину интернета будем, внимание, скачивать ее параллельно, ведь так быстрее.
Скажите пожалуйста, планируете ли вы добавить в IDEA решения типа Continuous Testing, на подобие того что команда из R# добавит в DotCover след версии? Заранее благодарен за информацию.
Кстати создатель AutoFixture, Марк Зиман сейчас активно подался на поприще F# и всячески его пропагандирует, я встречал его на одной конференции в Белгии, этой весной.
Да и если мы уже перешли на личностное, то я, увы, вынужден покинуть данный топик. Я думаю я свою точку зрения высказал, вы свою тоже. Тема исчерпана. Всего хорошего.
Про spring source, особо не буду говорить ибо оффтоп и времени на это нет, вам так разве не кажется?
Мне кажется что мувен третей версии устарел. Я так понимаю что вам так не кажется, тогда следуя вашей логике можно сказать что ivy не устарел.
Часто бывало что команда spring не блистала дальновидностью.
Ведь cobol или coldfusion живее всех живых, и до сих пор можно видеть анонсы о поиске специалистов, кстати с очень достойной оплатой. Для исчезновения или перерождения мувена понадобится несколько десятилетий.