Закоммитить index.png и index.PNG.
Или в конфигах писать пути без учёта регистра.
Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
Но всё это тоже решаемо.
На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
Ну так кто спорит, что требования могут быть разными и к ним можно применять разный подход. Одно дело фреймворк писать, другое интернет-магазин.
Ну вот когда надо будет делать CLI, тогда можно делать генерализацию и всё остальное. Я стараюсь максимально следовать принципам KISS и YAGNI и не усложнять пока это возможно.
Грубо говоря, CQRS удобная штука для разруливания сложных кейсов, но пихать её вообще везде глупо.
Т.е. у этого кода уже сейчас, в самой простой стадии, примерно нулевая устойчивость как к ошибочным сценариям, так и к сценариям самых базовых изменений и расширений.
Как раз его очень просто расширять и изменять. И тестировать через API. В нём просто нет кода, который нужен только для тестов. Ну а какая должна быть устойчивость? ну вернёт он пустой объект если что-то не так, ну или валидация атрибутов сработает.
1) Представим, что в вашем клиенте баг и у вас прилетает request==null, из которого возращается 500 ошибка на клиенте, причем в логах ничего нет.
Я не понимаю, что это за логи, которые не видят ошибку 500.
Валидация UserProfileRequest обычно делается за счёт атрибутов самого фреймворка. Но писать валидацию в методе контроллера — это тоже нормально.
Приложение обычно перехватывает все эксепшены и пишет их в логи. Ну если у вас какое-то публичное API, то да, имеет смысл париться тестами валидацией и сложными кейсами API (хотя IRL если клиент шлёт в API всякую хрень, то сам дурак). Но всё равно не ясно зачем это выносить на более низкий уровень.
Если нужно будет доставать связанные сущности в самом Select'е то нет смысла это куда-то выносить, ибо это будут сущности уровня API и их можно мэппить прямо в запросе. Когда и если будет навороченная логика, тогда её стоит и выносить.
LastName, FirstName, FullName, Middle Initial надо будет добавить только в одном месте. Если у вас пойдут слои, то это надо будет добавлять в куче мест, ещё и мэппить. И всё только для того, чтобы сделать тестирование. Ну если бюджеты бесконечные, то можно. А я за разумную достаточность.
Давайте покажу, что я имею в виду, на примере:
Например, есть у меня экшен контроллера, в котором я вытаскиваю из базы объекты ровно такие, какие нужны мне для view. Грубо говоря:
public async Task<ActionResult<UserProfileResponse> GetUserProfile(UserProfileRequest request)
{
return await _dbContext.Users
.Where(x => x.Id == request.Id)
.Select(x => new UserProfileResponse()
{
Id = x.Id,
Name = x.Name
}).ToListAsync();
}
Дальше генерим webClinet через nswag и дёргаем API в функциональных тестах. Просто, легко поддерживать и мало кода, а ещё можно тюнить под конкретный запрос. Вы можете потом дать джуну задачу добавить поле в UserProfileRequest и он это сможет сделать. Вы можете взять программиста, который всё перепишет на Хаскеле, но ваш тест будет работать, ибо это API вызовы. Такие высокоуровневые тесты живут, пока не поменялись требования, они совершенно не тормозять рефакторинг системы.
Для юнит-теста надо надо мокать базу, для этого надо пилить слои. Надо делать, какой-нибдуь IRepository.GetUserProfile(), делать слой данных, делать мэппинг данных из UserProfile в UserProfileResponse. (Вы же не будете класть объекты уровня Api в DAL).
Кстати, вот в случае SaveUserProfile уже мэппинг и слой абстракции не повредит, потому что там будет 100500 всяких валидаций, запросов к сторонним сервисам и прочее, так что там есть смысл выносить код save из класса контроллера. Просто чтобы спрятать сложность куда-то в отдельное место.
Проектов, в которых надо выкладывать фиксы каждый час, а значит, и апдейты — очень мало, и тем более неясно, как это делать без хорошего покрытия.
Сами же пишете про тестирование библиотек на юзерах.
Я же пишу про a/b-тестирование.
Есть много приложений (например е-магазины), где на самом деле бизнесу не нужен ваш код, бизнесу нужна конверсия. Если конверсия растёт, то код приложения работает, если конверсия падает, то стало хуже.
Говорить о том, что функциональные тесты не проверяют негативные сценарии крайне не правильно. Очень даже хорошо ими ломать всё приложение и смотреть, как оно поведёт себя.
У меня довольно большой опыт разработки самых разных приложений, и с unit-тестами есть очень много проблем. Я бы сказал, что это самый дорогой метод тестирования и часто избыточный. Практически во всех моих проектах unit-тесты забрасывались со временем, ибо они требовали очень больших ресурсов.
1. Если у вас нет unit-тестирования, то вы можете выкинуть кучу кода. Все эти интерфейсы и фабрики вам не нужны, если у вас всегда одна реализация. Скорее всего, у вас станет и меньше слоёв — меньше кода, меньше багов и меньше работы по его поддержке.
2. Юнит тесты очень сильно завязаны на реализации. Если вы захотите сделать большой рефакторинг, то тесты просто перестанут комплироваться. Чем более высокоуровневые ваши тесты, тем легче вам переписать всё целиком.
3. Замокать окружение для высокоуровневых тестов очень сложно, намного проще запустить ваше приложение в каком-то контейнере и гонять его целиком с куском реальных данных, чем поддерживать моки.
можно подумать кому-то этот PR/MR нужен. Там с той стороны сидят ребята на поддуве у facebook, microsoft или какой-другой компании и у них свой план. А на MR скорее ответят, что его как-то не так оформили или ещё как-то докопаются до мелочей.
Ложные аналогии as is.
У каждого инструменты свои плюсы и минусы. Если вы не видите минусов юнитестов на равне с их плюсами, то это очень плохо.
Да, unit-тесты на моках хорошо дают покрытие функций. Если у вас библиотека, то без unit-тестов никуда.
Если у вас большой проект, который надо постоянно менять, то поддержка Unit-тестов будет очень дорогим камнем на шее. Вы просто не вытянете саппортить тестые, потому тут приходит на помощь поведенческие тесты, которые, тоже могут дать неплохое покрытие. Да, они медленные, но зато они требуют минимум поддержки. Для частых релизов и мутных приложений такие тесты могут быть идеальными.
И если у вас проект, что надо выкладывать фиксы каждый час, то можно вообще использовать только A|B-тесты.
Разные ситуации бывают, надо уметь выбирать самое оптмимальное решение с точки зрения бизнеса.
Смысл удалённой работы в том, чтобы сделать себе максимально комфортную среду для работы.
Если ты любишь и умеешь путешествовать, то путешествуй.
Заведи себе хобби и будешь общаться с хоббистами по всему миру.
Понятно, что если только сидеть в номере где-нибудь на самуи и кодить, то будет депрессия. Выходить из дома надо. Круг общения — это не обязательно коллеги, даже наоборот, лучше если это были не коллеги.
Не факт, что SkyEng вообще нанимает программистов по ТК. Скорее заключает договора с ними, как с ИПшками. Вангую, что там говорят что-то вроде: вам как ИП, или -40% зарплаты?
Я так много работаю, просто потому что провожу время с кайфом. Другие развлечения мне менее интересны, чем поработать.
Рецепт выгорания, как есть.
На самом деле, быть трудоголиком уже года 2 как не модно.
И это крайне правильно, мозг надо переключать. Я сам программирую с детства и мне это очень нравится, но стараюсь заниматься другими делами тоже. И пробовать себя в разных сферах.
Я, кстати, однажды предъявлял Себастияну Россу, что он хотел сделать Wordpress, а сделал какого-то монстра убогого. Он мне тогда сказал, что никогда не имел в виду Wordpress, а Drupal или Jumla.
популяризации Windows как плаформы «дешевого» веб хостинга
Да. Azure, если быть точнее.
им это в какой-то степени удалось,
Абсолютно нет. Настолько нет, что Nuget плюнули и выкинули Orchard и написали всё с нуля. До версии 1.6, наверное, Орчард был очень тормозной и жрал кучу ресурсов.
совершенно другой вопрос и думаю он не к разработчикам из команды Orchard.
Цель была правильная. Только разрабы вместо решения этой задачи начали развлекаться с мега-супер-динамической системой рендеринга, которая IRL никому была не нужна. Конкретно архитектурные решения там принимал и принимает Себастиан, когда ему коммунити говорили, что «ребята, пилите нужные фичи», они и Бертраном Ле Роем пилили графический редактор для редактирования картинок.
идеи динамической компиляции и подгрузки внешних модулей в рантайме
О да, это они молодцы. Ибо это была жесть жестокая. Пример мега-фичи которая нафиг никому была не нужна.
в угоду цели написать свой аналог Wordpress.
Не. Просто хотели, чтобы модули ставились прямо на сайт из интернета. Довольно бесполезная идея. Orchard изначально забивали на обратную совместимость, а модулеписатели охладевали к орчарду и не поддерживали свои модули в актуальном состоянии.
Просто горе-ахитекторы Orchard'a не понимают одной простой вещи: сайт делает студия, делает все эти HTML, настраивает модули, компилит и выкладывает. Дальше с сайтом работают конент-редакторы, и им нужны удобные инструменты для управления контентом.
Если нужно положить какой-то виджет, то этот виджет будет дизайнить/выкладывать студия, а не контент-редактор. Динамическая настройка Layout'ов не нужна, а именно из-за этого в Orchard такая зашкаливающая сложность.
Ребята из Orchard никогда не делали сайтов и не работали в студиях. Например, они не понимают, что экспорт/импорт базы для таких систем — это очень важно. В итоге, он в орчарде очень убогий и глючный, возможно, они его всё-таки починили в 1.10, не проверял на реальной базе.
Меня эта вся история тронула довольно близко, именно потому что мы в своей студии сделали ставку на Orchard и очень сильно прогорели. Про Orchard вообще можно басни слагать, как делать не надо.
Ну Orchard всегда был хорошим бенчмарком для Rider и Resharper, вроде ребята из JetBrains его использовали для тестов.
Но из реальных проектов есть: github.com/umbraco/Umbraco-CMS — большая, функциональная, проверенная временем. Sitecore для бедных одним словом.
OrhcardCMS надо было прикопать лет эдак 5-7 назад. Это просто пример того, как программисты на деньги MS и других инвесторов пишут абсолютно over engineering поделие не для реального мира. Причём пишут его долго и мучительно.
Orchard 1.x оказался очень сложным, ребята сделали довольный безумный механизм рендеринга HTML из Shap'ов и всего такого. Чтобы разработчик в web-студии мог начать на нём сайты делать надо было много времени потратить. Вместо того, чтобы осознать, что людям не нужен сложный динамический рендеринг HTML, а нужен Django Admin, который можно подключить к ASP.NET MVC/API сайту. В итоге, Orchard 1.x — это очень сложный движок для рендеринга HTML с убогой админкой.
Но мужички не учатся на отзывах пользователей и потому запилили Orchard Core частично обратно совместимым с Orchard 1.x. Те не отказались от своих сложных концепций.
Админка, впрочем, стала немного лучше, но всё ещё ужасна, хотя они притащили туда Vue.
Лично я ожидал, что Orchard Core зерелизят несколько лет назад вместе с .net core 2, но нет, эти перфекционисты всё ещё его пилят, и вангую, что раньше 2020ого стабильного продакшен-релиза нам ждать не стоит.
В общем, не связывайтесь с Orchard'ом, ребята, я на него кучу денег и времени убил. Это очень дорогое в сопровождении и обучении поделие.
Я PHP хоронить не предлагаю, там фреймворки мощные.
Однако:
— node.js с Typescript вполне годный способ писать бэкенды. Отличная модель асинхронности.
— asp.net core с версии 2 очень годная вещь: божественный C#, простой движок похожий на node.js express, кросплатформенность, и крутая IDE Rider.
Вместо Java сейчас есть очень годный Kotlin. Для него запилили фрэймворк ktor, который очень лёгкий без ужасов spring'а.
Или в конфигах писать пути без учёта регистра.
Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
Но всё это тоже решаемо.
На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
Ну вот когда надо будет делать CLI, тогда можно делать генерализацию и всё остальное. Я стараюсь максимально следовать принципам KISS и YAGNI и не усложнять пока это возможно.
Грубо говоря, CQRS удобная штука для разруливания сложных кейсов, но пихать её вообще везде глупо.
https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
Как раз его очень просто расширять и изменять. И тестировать через API. В нём просто нет кода, который нужен только для тестов. Ну а какая должна быть устойчивость? ну вернёт он пустой объект если что-то не так, ну или валидация атрибутов сработает.
Я не понимаю, что это за логи, которые не видят ошибку 500.
Валидация UserProfileRequest обычно делается за счёт атрибутов самого фреймворка. Но писать валидацию в методе контроллера — это тоже нормально.
Приложение обычно перехватывает все эксепшены и пишет их в логи. Ну если у вас какое-то публичное API, то да, имеет смысл париться тестами валидацией и сложными кейсами API (хотя IRL если клиент шлёт в API всякую хрень, то сам дурак). Но всё равно не ясно зачем это выносить на более низкий уровень.
Если нужно будет доставать связанные сущности в самом Select'е то нет смысла это куда-то выносить, ибо это будут сущности уровня API и их можно мэппить прямо в запросе. Когда и если будет навороченная логика, тогда её стоит и выносить.
LastName, FirstName, FullName, Middle Initial надо будет добавить только в одном месте. Если у вас пойдут слои, то это надо будет добавлять в куче мест, ещё и мэппить. И всё только для того, чтобы сделать тестирование. Ну если бюджеты бесконечные, то можно. А я за разумную достаточность.
Например, есть у меня экшен контроллера, в котором я вытаскиваю из базы объекты ровно такие, какие нужны мне для view. Грубо говоря:
Дальше генерим webClinet через nswag и дёргаем API в функциональных тестах. Просто, легко поддерживать и мало кода, а ещё можно тюнить под конкретный запрос. Вы можете потом дать джуну задачу добавить поле в UserProfileRequest и он это сможет сделать. Вы можете взять программиста, который всё перепишет на Хаскеле, но ваш тест будет работать, ибо это API вызовы. Такие высокоуровневые тесты живут, пока не поменялись требования, они совершенно не тормозять рефакторинг системы.
Для юнит-теста надо надо мокать базу, для этого надо пилить слои. Надо делать, какой-нибдуь IRepository.GetUserProfile(), делать слой данных, делать мэппинг данных из UserProfile в UserProfileResponse. (Вы же не будете класть объекты уровня Api в DAL).
Кстати, вот в случае SaveUserProfile уже мэппинг и слой абстракции не повредит, потому что там будет 100500 всяких валидаций, запросов к сторонним сервисам и прочее, так что там есть смысл выносить код save из класса контроллера. Просто чтобы спрятать сложность куда-то в отдельное место.
Особенно, когда у твоего PR есть «пальцы вверх».
Сами же пишете про тестирование библиотек на юзерах.
Я же пишу про a/b-тестирование.
Есть много приложений (например е-магазины), где на самом деле бизнесу не нужен ваш код, бизнесу нужна конверсия. Если конверсия растёт, то код приложения работает, если конверсия падает, то стало хуже.
Говорить о том, что функциональные тесты не проверяют негативные сценарии крайне не правильно. Очень даже хорошо ими ломать всё приложение и смотреть, как оно поведёт себя.
У меня довольно большой опыт разработки самых разных приложений, и с unit-тестами есть очень много проблем. Я бы сказал, что это самый дорогой метод тестирования и часто избыточный. Практически во всех моих проектах unit-тесты забрасывались со временем, ибо они требовали очень больших ресурсов.
1. Если у вас нет unit-тестирования, то вы можете выкинуть кучу кода. Все эти интерфейсы и фабрики вам не нужны, если у вас всегда одна реализация. Скорее всего, у вас станет и меньше слоёв — меньше кода, меньше багов и меньше работы по его поддержке.
2. Юнит тесты очень сильно завязаны на реализации. Если вы захотите сделать большой рефакторинг, то тесты просто перестанут комплироваться. Чем более высокоуровневые ваши тесты, тем легче вам переписать всё целиком.
3. Замокать окружение для высокоуровневых тестов очень сложно, намного проще запустить ваше приложение в каком-то контейнере и гонять его целиком с куском реальных данных, чем поддерживать моки.
У каждого инструменты свои плюсы и минусы. Если вы не видите минусов юнитестов на равне с их плюсами, то это очень плохо.
Да, unit-тесты на моках хорошо дают покрытие функций. Если у вас библиотека, то без unit-тестов никуда.
Если у вас большой проект, который надо постоянно менять, то поддержка Unit-тестов будет очень дорогим камнем на шее. Вы просто не вытянете саппортить тестые, потому тут приходит на помощь поведенческие тесты, которые, тоже могут дать неплохое покрытие. Да, они медленные, но зато они требуют минимум поддержки. Для частых релизов и мутных приложений такие тесты могут быть идеальными.
И если у вас проект, что надо выкладывать фиксы каждый час, то можно вообще использовать только A|B-тесты.
Разные ситуации бывают, надо уметь выбирать самое оптмимальное решение с точки зрения бизнеса.
Если ты любишь и умеешь путешествовать, то путешествуй.
Заведи себе хобби и будешь общаться с хоббистами по всему миру.
Понятно, что если только сидеть в номере где-нибудь на самуи и кодить, то будет депрессия. Выходить из дома надо. Круг общения — это не обязательно коллеги, даже наоборот, лучше если это были не коллеги.
Рецепт выгорания, как есть.
На самом деле, быть трудоголиком уже года 2 как не модно.
И это крайне правильно, мозг надо переключать. Я сам программирую с детства и мне это очень нравится, но стараюсь заниматься другими делами тоже. И пробовать себя в разных сферах.
Я, кстати, однажды предъявлял Себастияну Россу, что он хотел сделать Wordpress, а сделал какого-то монстра убогого. Он мне тогда сказал, что никогда не имел в виду Wordpress, а Drupal или Jumla.
Да. Azure, если быть точнее.
Абсолютно нет. Настолько нет, что Nuget плюнули и выкинули Orchard и написали всё с нуля. До версии 1.6, наверное, Орчард был очень тормозной и жрал кучу ресурсов.
Цель была правильная. Только разрабы вместо решения этой задачи начали развлекаться с мега-супер-динамической системой рендеринга, которая IRL никому была не нужна. Конкретно архитектурные решения там принимал и принимает Себастиан, когда ему коммунити говорили, что «ребята, пилите нужные фичи», они и Бертраном Ле Роем пилили графический редактор для редактирования картинок.
О да, это они молодцы. Ибо это была жесть жестокая. Пример мега-фичи которая нафиг никому была не нужна.
Не. Просто хотели, чтобы модули ставились прямо на сайт из интернета. Довольно бесполезная идея. Orchard изначально забивали на обратную совместимость, а модулеписатели охладевали к орчарду и не поддерживали свои модули в актуальном состоянии.
Просто горе-ахитекторы Orchard'a не понимают одной простой вещи: сайт делает студия, делает все эти HTML, настраивает модули, компилит и выкладывает. Дальше с сайтом работают конент-редакторы, и им нужны удобные инструменты для управления контентом.
Если нужно положить какой-то виджет, то этот виджет будет дизайнить/выкладывать студия, а не контент-редактор. Динамическая настройка Layout'ов не нужна, а именно из-за этого в Orchard такая зашкаливающая сложность.
Ребята из Orchard никогда не делали сайтов и не работали в студиях. Например, они не понимают, что экспорт/импорт базы для таких систем — это очень важно. В итоге, он в орчарде очень убогий и глючный, возможно, они его всё-таки починили в 1.10, не проверял на реальной базе.
Меня эта вся история тронула довольно близко, именно потому что мы в своей студии сделали ставку на Orchard и очень сильно прогорели. Про Orchard вообще можно басни слагать, как делать не надо.
Но из реальных проектов есть:
github.com/umbraco/Umbraco-CMS — большая, функциональная, проверенная временем. Sitecore для бедных одним словом.
github.com/nopSolutions/nopCommerce — довольно мощный интернет-магазин.
Можно ещё что-нибудь отсюда посмотреть:
github.com/thangchung/awesome-dotnet-core#cms
Orchard 1.x оказался очень сложным, ребята сделали довольный безумный механизм рендеринга HTML из Shap'ов и всего такого. Чтобы разработчик в web-студии мог начать на нём сайты делать надо было много времени потратить. Вместо того, чтобы осознать, что людям не нужен сложный динамический рендеринг HTML, а нужен Django Admin, который можно подключить к ASP.NET MVC/API сайту. В итоге, Orchard 1.x — это очень сложный движок для рендеринга HTML с убогой админкой.
Но мужички не учатся на отзывах пользователей и потому запилили Orchard Core частично обратно совместимым с Orchard 1.x. Те не отказались от своих сложных концепций.
Админка, впрочем, стала немного лучше, но всё ещё ужасна, хотя они притащили туда Vue.
Лично я ожидал, что Orchard Core зерелизят несколько лет назад вместе с .net core 2, но нет, эти перфекционисты всё ещё его пилят, и вангую, что раньше 2020ого стабильного продакшен-релиза нам ждать не стоит.
В общем, не связывайтесь с Orchard'ом, ребята, я на него кучу денег и времени убил. Это очень дорогое в сопровождении и обучении поделие.
Донатить Медиазоне.
Однако:
— node.js с Typescript вполне годный способ писать бэкенды. Отличная модель асинхронности.
— asp.net core с версии 2 очень годная вещь: божественный C#, простой движок похожий на node.js express, кросплатформенность, и крутая IDE Rider.
Вместо Java сейчас есть очень годный Kotlin. Для него запилили фрэймворк ktor, который очень лёгкий без ужасов spring'а.