Получается, у разработчиков локально одна архитектура, а на серваках совсем другая, если конечно там тоже не ARM. Мне кажется такое решение контрпродуктивно по своей сути.
Любые сочетания клавиш можно переопределить, при чём сделать это на лету. Ctrl-. жмём любые кнопки в любом порядке, ещё раз Ctrl. и нажимаем желаемую горячую клавишу, всё. На макросах можно сделать гораздо больше, там полноценный язык программирования очень простой, что позволяет автоматизировать любую рутину.
Почитал комментарии, как странно, что не упомянули одну из основных киллер-фич FAR-а: это мощнейшая интеграция с командной строкой. Это причина, почему Total Commander мне не нравится - это просто файловый менеджер, консольный запуск выполняется отдельно. А FAR это менеджер, интегрированный с консолью.
Многие удивляются, а зачем FAR? Если среди этих людей есть консольщики, для которых консоль -- рабочий инструмент, то собственно для удобной работы с консолью.
Я не люблю обезьяньи команды для вывода содержимого каталога, файлов, перехода по каталогам. Это дорого по времени, даже если команды сидят в подкорке, даже с автокомплитом. FAR быстрее.
Отключение панелей для отображения чистой консоли Ctrl-O, или ESC (после добавления хоткеев из стандартного комплекта).
Можно весь stdout направить прям в редактор, без промежуточного файла, вот так:
edit:<some command
Можно моментально перейти к файлу или папке, с включением переменных окружения:
goto:file/or/directory/path
Все консольные команды запоминаются в истории FAR. Консольные команды можно шаблонизировать с учётом что сейчас на левой панели и на правой, там целый космос что с этим можно делать.
Например, можно по-файлово применить команду к выделенным файлам, выполнить сложнейший поиск с рекурсией, посмотреть результаты поиска в панели, выполнить для найденных файлов/папок любую команду из консоли, или сделать выборку из результатов поиска, сохранить её в файл, или в буфер. Мощная функция сравнения двух каталогов с различными стратегиями.
Если использовать FAR для работы с консолью, он может существенно улучшить комфорт и производительность. Его возможности до сих пор впечатляют.
Вы говорите про экземпляр чего-то, что реализует IQueryable. Провайдер. Ну так одно другому не мешает. Вы можете сделать так: Array.Empty().AsQueryable(), затем наполнить полученный экземпляр предикатами, затем можно извлечь Expression и поместить в необходимую реализацию IQueryable.
Обычно, реализации спецификаций хранят в себе Expression. Так IQueryable тоже хранит :) Т.е. он перекрывает спецификацию и Query Object. Ну и плюс, можно делать не только предикаты, но и больше.
Но возможности LINQ просто даже близко не дотягивают до возможностей SQL. Поэтому многие разработчики даже не пользуются LINQ.
Если очень хочется, из IQueryable можно извлекать выражения и встраивать их в "подзапросы", чтобы можно было делать даже так:
public static IQueryable<Contract> ByDealer(this IQueryable<Contract> linq, int dealerId)
{
return linq.Where(p => p.Dealer.Id == dealerId);
}
public static IQueryable<Contract> ByFilifal(this IQueryable<Contract> linq, int filialId)
{
return linq.Where(p => p.Filial.Id == filialId);
}
// затем, вуаля:
var query = dbContext.Contracts.ByDealer(123).Or().ByFilial(filialId);
Такие финты можно делать, и сильно сложнее. Другое дело, что в реальности игры с LINQ, спецификациями и прочими игрушками приносят в основном вред, и совсем не приносят пользы.
Возможностей LINQ достаточно, чтобы делать простые выборки и получить до 90% типизированных запросов. Но если выйти за рамки совсем примитивных приложений, окажется, что очень нужны и часто, оконные функции, кубы, предварительные промежуточные выборки, в общем для многих задач нужен SQL. Без плясок, приколов, попытками это запихать в LINQ. И нужно оба этих мира, чтоб программист не тратил время на проектирование спецификаций, которые как окажется потом весьма слабо и плохо комбинируются, но нужны конкретные запросы и возможность без плясок использовать SQL.
Это если конечно говорить о боевых приложениях с какой-никакой нагрузкой и хоть с какой-то сложностью в логике.
Блин, IQueyrable это спецификация. Это чистая абстракция, об этом даже говорит тот факт, что это интерфейс. DbContext это репозиторий + unit of work. В чистом виде. Когда я вижу проекты, где творят какие-то generic IRepository, мне хочется плакать. Зачем нужны эти "разные репозитории"? Это для чего?
Проблема в том, Rich Domain Model это бутафория. Возьмём какой-нибудь классический пример, интернет-магазин. Объект "Заказ". По DDD, мы должны определить класс Order и всё, что можно с ним сделать, находится в этом классе. Вся бизнес-логика. Типа. Почему "типа"? Да потому что класс Order это никакой не "Заказ" и никакой не бизнес-объект, это по сути одна маленькая грань настоящего заказа, это набор полей в одной конкретной системе. В реальном же мире заказ это далеко не только запись в БД, и логикой одной приложухи дело совсем не ограничивается. Заказ может иметь даже не сотню, а тысячи сложнейших правил, некоторые вообще существуют не больше недели.
Я наблюдал, как красивое с чистое DDD-проектирование разбивалось не просто в дребезги об реальность, а в пыль, унижая всю инженерию в целом. Количество кода на простейшие задачи и правила выходят за рамки всех разумных границ. Какие красивые доменные сервисы, DDD-объекты с бизнес-правилами, репозитории, команды, гейты, события. Но отойти на пару шагов, и мы видим как красиво, изящно и мастерски, десятки человек вкручивают одну лампочку в течение месяца.
А если перестать фантазировать, и осознать, что мы управляем не Заказом, а всего лишь записью о заказе в БД, т.е. набором полей и связанных записей, то оказывается, что в основном мы работаем с состоянием. А не рулим и не описываем "правила бизнеса". Мы читаем из БД объект, показываем срез данных юзеру, принимаем ввод от юзера, проверяем что он ввёл, сравниваем с данными в БД и сохраняем новое состояние. Вот что мы делаем. А не пишем манускрипты с "правилами бизнеса" :)
Самые лучшие решения, которые мне удавалось увидеть или создать, это передача контроля и программирования правил бизнеса на "аутсорс", т.е. специалисту внедрения. Написание высшей бизнес-логики в классах, это обезьяний труд, обесценивание инженерной дисциплины.
Как по мне, стало ещё на порядок сложнее. Либо лично мне не нравятся примеры в стиле "это Алиса, она местная дурочка, а это Боб, местный эксперт-душнила", теперь думаешь о бедной Алисе, а не о задаче, и не покидает ощущения, что со мной пытаются общаться как с идиотом. Конечно сложные вещи стоит упрощать, или подбирать удачные аллегории, но без фанатизма :)
Тут вообще очень много желтухи, искажения фактов и убедительных восклицательных знаков :) Образцовая презентация для телемагазина, эти ножи не тупятся никогда!
Сайтецы на VPS хостинге за 5 баксов можно делать на чём угодно. Если на руби задача полностью решается (читаем, вся нагрузка и сложность находится в БД), это прекрасно. Тут как обычно, выбор за наличием компетенций в команде.
Руби эстетически мне очень нравится. Но не в тех случаях, когда требуется держать несколько команд на разных бекенд стеках в рамках одного проекта, этого я пока не понимаю. Да, я про появление сервисов на Go/Java/NET.
Вообще, основным звеном, который съедает ресурсы хостинга, является База Данных.
Так только на прикладах, где никакой вычислительной сложной логики нет, кроме запросов в БД или в бекенды, которые содержат действительно ценную логику с распределёнными вычислениями, высокими требованиями к надёжности.
В том же GitHub в его основе находится Erlang.
Ruby on Rails выдерживает миллиард уников в месяц!
Если запустить миллиард экземпляров ROR и распределить между ними нагрузку. Будет ещё больше. Такие графики -- от непонимания, как всё устроено.
Всё держится на безусловной вере в непогрешимость разработчика, что он не ошибается, а если даже и ошибается, то уже точно не в юнит-тестах, ведь в них нет и не может быть ошибок, и покрытие 100%. И это не просто красивый процент, а прям на каждую строку несколько строк тестов. И применение тогл фич всегда чёткое и безошибочное.
Зачем вообще бранчеваться? Почему бы с такими вводными и такими железобетонными UT/FT не отправлять изменения сразу в прод? И зачем тут QA? Это ведь подрывает доверие к разработке.
А если честно, и правда больше нечем заняться, как выдумывать и навязывать совершенно не гибкий подход к разработке? Не удивлюсь, если увижу в продаже книгу "TBD в действии", 100500 выступлений, митапов, вебинаров на эту тему.
Git очень гибкая, надёжная и удобная система. Почему бы не создавать столько веток сколько нужно в каждом конкретном случае, и даже на отрезке времени. Тот же самый git-flow, в полной мере наверное редко когда используется, но он удобен для управления процессом, и кастомизируется как угодно.
Зачем эти огороды городить? Может лучше сосредоточиться на разработке?
Кроме "матёрого сеньёра" на проекте другие инженеры работают? Паттерны не панацея, но это консолидированные и обобщённые знания, которые известны всем. Заучивать безумный список не надо, паттерны не требуется знать наизусть. С ними нужно быть знакомым, чтобы не изобретать каждый раз колесо, с которым никто в мире не знаком, а говорить с другими разработчиками на одном языке.
Тенденция, которую я всё больше наблюдаю, отказ от знаний, "я чё дурак это всё учить?", оно напрямую выливается в совершенное безумие в коде. Это уже не велосипеды в коде, что я порой наблюдаю, это адские колесницы :)
ASP.NET может самостоятельно превращать все ошибки в Problem Details, включая 500-ки, без дополнительных приседаний :) Основная проблема многих разработчиков бекенд веб-приложений, что они основательно перестали понимать, что возвращаемый ответ должен опираться на тип запроса. Если в запросе клиент говорит, что он хочет принимать html, text, не надо ему JSON впихивать.
Отсюда, пользователи иногда наблюдают вываливающиеся на них страшные JSON-ы. Это говорит о плохой экологии разработки, на лицо непонимание технологий веб, задачи решаются тупо в лоб. Ну примерно, как разработка жигулей -- ну едет же, что ещё надо?
Платформа ASP.NET, из коробки, даёт решение большинства задач и проблем. Но пилить велосипеды со своими мидлварями значительно интереснее, чем разбираться в платформе. Я это прекрасно понимаю :)
Я бы рекомендовал больше смотреть в сторону Activity.Span, так как это на порядок лучше и больше подходит для данных окружения и выполняемой операции. Наличие Exception.Data скорее жирный минус, чем плюс, так как исключения из-за этого могут мутировать, и вообще там должны быть детали ошибки, а не окружения.
Об окружении рассказывает Activity, которое элементарно переносится как в логи, в трассировку и любые другие инструменты телеметрии. Exception.Data же никуда не переносится, нигде не регистрируется и по большей части это мёртвый груз. И обрабатывать надо его строго вручную, а решения, которые помещают что-то в Data можно считать непереносимыми.
Что делать в случае нарушения правил бизнес-логики стало понятно из кода - стратегия доменных исключений. Например, когда клиент хочет забронировать уже купленное место, то бросается SeatBoughtException.
Когда стремление к чистой архитектуре приводит к грязному коду, нарушению базовых принципов кодирования в угоду красивой картинке. Бизнес-исключения, которые исключениями не являются, а это вполне ожидаемое, логичное поведение, определённое правилами бизнеса, это очень и очень плохо. Не делайте так пожалуйста.
Не-не. В данном случае именно способ проектирования создаёт проблемы, с которыми приходится бороться. Это типа "у нас на этот случай есть решение", и ворох костылей, ворох "рецептов", которые просто-напросто не нужны были вообще, пока мы не начали вкорячивать чистую архитектуру. По крайней мере, глядя на код, создаётся такое впечатление. Идеальный конь в вакууме против реальных задач реального бизнеса.
Получается, у разработчиков локально одна архитектура, а на серваках совсем другая, если конечно там тоже не ARM. Мне кажется такое решение контрпродуктивно по своей сути.
Написать плагин, кстати, совсем не сложно. Давным-давно, помню, писал плагины даже на паскале.
Любые сочетания клавиш можно переопределить, при чём сделать это на лету. Ctrl-. жмём любые кнопки в любом порядке, ещё раз Ctrl. и нажимаем желаемую горячую клавишу, всё. На макросах можно сделать гораздо больше, там полноценный язык программирования очень простой, что позволяет автоматизировать любую рутину.
Почитал комментарии, как странно, что не упомянули одну из основных киллер-фич FAR-а: это мощнейшая интеграция с командной строкой. Это причина, почему Total Commander мне не нравится - это просто файловый менеджер, консольный запуск выполняется отдельно. А FAR это менеджер, интегрированный с консолью.
Многие удивляются, а зачем FAR? Если среди этих людей есть консольщики, для которых консоль -- рабочий инструмент, то собственно для удобной работы с консолью.
Я не люблю обезьяньи команды для вывода содержимого каталога, файлов, перехода по каталогам. Это дорого по времени, даже если команды сидят в подкорке, даже с автокомплитом. FAR быстрее.
Отключение панелей для отображения чистой консоли Ctrl-O, или ESC (после добавления хоткеев из стандартного комплекта).
Можно весь stdout направить прям в редактор, без промежуточного файла, вот так:
Можно моментально перейти к файлу или папке, с включением переменных окружения:
Все консольные команды запоминаются в истории FAR. Консольные команды можно шаблонизировать с учётом что сейчас на левой панели и на правой, там целый космос что с этим можно делать.
Например, можно по-файлово применить команду к выделенным файлам, выполнить сложнейший поиск с рекурсией, посмотреть результаты поиска в панели, выполнить для найденных файлов/папок любую команду из консоли, или сделать выборку из результатов поиска, сохранить её в файл, или в буфер. Мощная функция сравнения двух каталогов с различными стратегиями.
Если использовать FAR для работы с консолью, он может существенно улучшить комфорт и производительность. Его возможности до сих пор впечатляют.
Вы говорите про экземпляр чего-то, что реализует IQueryable. Провайдер. Ну так одно другому не мешает. Вы можете сделать так: Array.Empty().AsQueryable(), затем наполнить полученный экземпляр предикатами, затем можно извлечь Expression и поместить в необходимую реализацию IQueryable.
Обычно, реализации спецификаций хранят в себе Expression. Так IQueryable тоже хранит :) Т.е. он перекрывает спецификацию и Query Object. Ну и плюс, можно делать не только предикаты, но и больше.
Но возможности LINQ просто даже близко не дотягивают до возможностей SQL. Поэтому многие разработчики даже не пользуются LINQ.
Если очень хочется, из IQueryable можно извлекать выражения и встраивать их в "подзапросы", чтобы можно было делать даже так:
Такие финты можно делать, и сильно сложнее. Другое дело, что в реальности игры с LINQ, спецификациями и прочими игрушками приносят в основном вред, и совсем не приносят пользы.
Возможностей LINQ достаточно, чтобы делать простые выборки и получить до 90% типизированных запросов. Но если выйти за рамки совсем примитивных приложений, окажется, что очень нужны и часто, оконные функции, кубы, предварительные промежуточные выборки, в общем для многих задач нужен SQL. Без плясок, приколов, попытками это запихать в LINQ. И нужно оба этих мира, чтоб программист не тратил время на проектирование спецификаций, которые как окажется потом весьма слабо и плохо комбинируются, но нужны конкретные запросы и возможность без плясок использовать SQL.
Это если конечно говорить о боевых приложениях с какой-никакой нагрузкой и хоть с какой-то сложностью в логике.
Чего это не решаются? Очень даже решаются.
Блин, IQueyrable это спецификация. Это чистая абстракция, об этом даже говорит тот факт, что это интерфейс. DbContext это репозиторий + unit of work. В чистом виде. Когда я вижу проекты, где творят какие-то generic IRepository, мне хочется плакать. Зачем нужны эти "разные репозитории"? Это для чего?
IQueryable уже сам по себе является ни чем иным, как спецификацией. Но людям нравится городить ещё 25 абстракций поверх. Никак не угомонятся :)
Проблема в том, Rich Domain Model это бутафория. Возьмём какой-нибудь классический пример, интернет-магазин. Объект "Заказ". По DDD, мы должны определить класс Order и всё, что можно с ним сделать, находится в этом классе. Вся бизнес-логика. Типа. Почему "типа"? Да потому что класс Order это никакой не "Заказ" и никакой не бизнес-объект, это по сути одна маленькая грань настоящего заказа, это набор полей в одной конкретной системе. В реальном же мире заказ это далеко не только запись в БД, и логикой одной приложухи дело совсем не ограничивается. Заказ может иметь даже не сотню, а тысячи сложнейших правил, некоторые вообще существуют не больше недели.
Я наблюдал, как красивое с чистое DDD-проектирование разбивалось не просто в дребезги об реальность, а в пыль, унижая всю инженерию в целом. Количество кода на простейшие задачи и правила выходят за рамки всех разумных границ. Какие красивые доменные сервисы, DDD-объекты с бизнес-правилами, репозитории, команды, гейты, события. Но отойти на пару шагов, и мы видим как красиво, изящно и мастерски, десятки человек вкручивают одну лампочку в течение месяца.
А если перестать фантазировать, и осознать, что мы управляем не Заказом, а всего лишь записью о заказе в БД, т.е. набором полей и связанных записей, то оказывается, что в основном мы работаем с состоянием. А не рулим и не описываем "правила бизнеса". Мы читаем из БД объект, показываем срез данных юзеру, принимаем ввод от юзера, проверяем что он ввёл, сравниваем с данными в БД и сохраняем новое состояние. Вот что мы делаем. А не пишем манускрипты с "правилами бизнеса" :)
Самые лучшие решения, которые мне удавалось увидеть или создать, это передача контроля и программирования правил бизнеса на "аутсорс", т.е. специалисту внедрения. Написание высшей бизнес-логики в классах, это обезьяний труд, обесценивание инженерной дисциплины.
Как по мне, стало ещё на порядок сложнее. Либо лично мне не нравятся примеры в стиле "это Алиса, она местная дурочка, а это Боб, местный эксперт-душнила", теперь думаешь о бедной Алисе, а не о задаче, и не покидает ощущения, что со мной пытаются общаться как с идиотом. Конечно сложные вещи стоит упрощать, или подбирать удачные аллегории, но без фанатизма :)
Чем статические функции не угодили? Класс там это просто синтаксический контейнер, модуль. Разницы никакой нет.
Тут вообще очень много желтухи, искажения фактов и убедительных восклицательных знаков :)
Образцовая презентация для телемагазина, эти ножи не тупятся никогда!
Сайтецы на VPS хостинге за 5 баксов можно делать на чём угодно. Если на руби задача полностью решается (читаем, вся нагрузка и сложность находится в БД), это прекрасно. Тут как обычно, выбор за наличием компетенций в команде.
Руби эстетически мне очень нравится. Но не в тех случаях, когда требуется держать несколько команд на разных бекенд стеках в рамках одного проекта, этого я пока не понимаю. Да, я про появление сервисов на Go/Java/NET.
Так только на прикладах, где никакой вычислительной сложной логики нет, кроме запросов в БД или в бекенды, которые содержат действительно ценную логику с распределёнными вычислениями, высокими требованиями к надёжности.
В том же GitHub в его основе находится Erlang.
Если запустить миллиард экземпляров ROR и распределить между ними нагрузку. Будет ещё больше. Такие графики -- от непонимания, как всё устроено.
Всё держится на безусловной вере в непогрешимость разработчика, что он не ошибается, а если даже и ошибается, то уже точно не в юнит-тестах, ведь в них нет и не может быть ошибок, и покрытие 100%. И это не просто красивый процент, а прям на каждую строку несколько строк тестов. И применение тогл фич всегда чёткое и безошибочное.
Зачем вообще бранчеваться? Почему бы с такими вводными и такими железобетонными UT/FT не отправлять изменения сразу в прод? И зачем тут QA? Это ведь подрывает доверие к разработке.
А если честно, и правда больше нечем заняться, как выдумывать и навязывать совершенно не гибкий подход к разработке? Не удивлюсь, если увижу в продаже книгу "TBD в действии", 100500 выступлений, митапов, вебинаров на эту тему.
Git очень гибкая, надёжная и удобная система. Почему бы не создавать столько веток сколько нужно в каждом конкретном случае, и даже на отрезке времени. Тот же самый git-flow, в полной мере наверное редко когда используется, но он удобен для управления процессом, и кастомизируется как угодно.
Зачем эти огороды городить? Может лучше сосредоточиться на разработке?
Кроме "матёрого сеньёра" на проекте другие инженеры работают? Паттерны не панацея, но это консолидированные и обобщённые знания, которые известны всем. Заучивать безумный список не надо, паттерны не требуется знать наизусть. С ними нужно быть знакомым, чтобы не изобретать каждый раз колесо, с которым никто в мире не знаком, а говорить с другими разработчиками на одном языке.
Тенденция, которую я всё больше наблюдаю, отказ от знаний, "я чё дурак это всё учить?", оно напрямую выливается в совершенное безумие в коде. Это уже не велосипеды в коде, что я порой наблюдаю, это адские колесницы :)
ASP.NET может самостоятельно превращать все ошибки в Problem Details, включая 500-ки, без дополнительных приседаний :) Основная проблема многих разработчиков бекенд веб-приложений, что они основательно перестали понимать, что возвращаемый ответ должен опираться на тип запроса. Если в запросе клиент говорит, что он хочет принимать html, text, не надо ему JSON впихивать.
Отсюда, пользователи иногда наблюдают вываливающиеся на них страшные JSON-ы. Это говорит о плохой экологии разработки, на лицо непонимание технологий веб, задачи решаются тупо в лоб. Ну примерно, как разработка жигулей -- ну едет же, что ещё надо?
Платформа ASP.NET, из коробки, даёт решение большинства задач и проблем. Но пилить велосипеды со своими мидлварями значительно интереснее, чем разбираться в платформе. Я это прекрасно понимаю :)
Я бы рекомендовал больше смотреть в сторону Activity.Span, так как это на порядок лучше и больше подходит для данных окружения и выполняемой операции. Наличие Exception.Data скорее жирный минус, чем плюс, так как исключения из-за этого могут мутировать, и вообще там должны быть детали ошибки, а не окружения.
Об окружении рассказывает Activity, которое элементарно переносится как в логи, в трассировку и любые другие инструменты телеметрии. Exception.Data же никуда не переносится, нигде не регистрируется и по большей части это мёртвый груз. И обрабатывать надо его строго вручную, а решения, которые помещают что-то в Data можно считать непереносимыми.
Когда стремление к чистой архитектуре приводит к грязному коду, нарушению базовых принципов кодирования в угоду красивой картинке. Бизнес-исключения, которые исключениями не являются, а это вполне ожидаемое, логичное поведение, определённое правилами бизнеса, это очень и очень плохо. Не делайте так пожалуйста.
Не-не. В данном случае именно способ проектирования создаёт проблемы, с которыми приходится бороться. Это типа "у нас на этот случай есть решение", и ворох костылей, ворох "рецептов", которые просто-напросто не нужны были вообще, пока мы не начали вкорячивать чистую архитектуру. По крайней мере, глядя на код, создаётся такое впечатление. Идеальный конь в вакууме против реальных задач реального бизнеса.