Но если честно, есть некоторое ощущение хаоса. Все эти shell-штуки не сочетаются с "нормальной" разработкой. Очень странный курс развития выбрали майкрософты
Заметил, что в статье практика PR'ов в основном критикуется за "токсичность" и за времязатратность. Однако я считаю, что эта проблема возникает из попытки решить "проблему доверия" через PR
Важные решения должны быть согласованы с командой, код должен быть покрыт тестами, а код-стайл - проверяться линтером. Тогда не придется "токсить" в PR'ах в духе "а почему скобочка не там стоит?" или еще хуже "а что это ты вообще выкатываешь?". И PR соответственно будут приносить чистый профит - позволят точечно фиксить какие-нибудь косяки по невнимательности / незнании предметной области / прочих человеческих факторах
Хотелось бы отметить тенденцию работодателей вкладываться во фронт по "остаточному" принципу. Т.е. мастерить конкретный UI-фреймворк почти не имеет смысла, т.к. работодателя удовлетворит, что ты хотя бы +- понимаешь, что там на фронте происходит. Больше играет роль знание бэкенд-фреймворка и инфраструктуры вокруг него. Ну это по моему опыту
Спасибо за комментарий. Рад, что статья оказалась полезной )
Отсутствие AsyncPipe - конечно, упущение. А JsonPipe, как правило, на текущем проекте мы не используем - поэтому я и не подумал о нём. Либо через дебаггер смотрим, либо через расширение Redux DevTools (используем NGXS)
Моя придирка скорее в том, что использование терминов, заимствованных из ФП, тут ни к месту, т.к. из ФП ничего не заимствуется в итоге - в ходе всех манипуляций мы получаем обычные объекты...
А если речь идет о том, чтобы полностью конструировать бизнес-логику из таких "объектов-функций", то в таком случае речь идет больше об уходе от ООП, чем о его паттернах. Что-то отдаленно напоминающее процедурное программирование получается ( просто пытаюсь сформулировать, как правильно называется такой подход; если честно, не знаю :D )
Термин Функция-объект (Function Object, или Functor) в контексте объектно-ориентированного программирования появился как естественное развитие концепции функций как объектов из функционального программирования
Такой подход часто используется, например, для событий, коллбеков или обработки команд из UI
Удачи юзнуть "функтор" с зависимостью от EF Core как коллбек на событие, допустим
---
Тульский пряник, это не пряник, потому что уже есть мятный пряник.
Зачем изобретать тульский пряник на базе мятного пряника?
---
Еще раз повторюсь, что идея здравая. Хороший подход, который имеет место быть. Но в объяснении приплетены паттерны совсем из другой оперы с другими свойствами и предназначениями
Я прочитал и предыдущую статью, и эту, и комменты частично. Долго медитировал на счет корректности паттерна. С одной стороны, раскидать логику по разным юзкейсам - это идея здравая. С другой - чувствуется, что что-то не то... И в общем я пришел к выводу, что в статье просто описывается принип SRP: https://habr.com/ru/articles/454290/
Но это не функциональный объект, потому что:
функциональный объект в C# уже есть, это - делегат
таскать внешние зависимости из DI - это в общем-то антипаттерн для ФП; функции должны быть чистыми, иначе шибко их не закомбинируешь
Несмотря на путаницу в терминологии, идея в общем-то здравая имхо. Язык не повернется назвать антипаттерном... Если в фасад обернуть, так - вообще тема. Главное - слишком сильно не увлекаться декомпозицией, т.к. с большим количеством мелких объектов тоже проблематично работать
upd
Мой последний проект состоял из более чем 250 микросервисов, и включал в себя такие группы функций как ETL, Search, RAG, и только в части из них были использованы Function Object
Подтверждаю. В микросервисах может оказаться очень кайфово просто раскидывать по юзкейсам код. Там какой-нибудь MediatR + Minimal Api или FastEndpoints - и в путь. Нет смысла особо что-то инженерить, т.к. архитектурные границы уже были проведены на уровне сервисов
А это значит, что для парсинга законодательных проектов советы в статье не сработают.
Считаю, что это не совсем корректная критика автора. Скрейпинг того или иного ресурса - всегда разный скрипт. Это нормально, что один прием может сработать на одном сайте, но на другом - нет
Советы из статьи в принципе не работают: парсинг не так делается. Я давно жду комментарии и статьи от людей, кто и правда что то такое делает. Со scrapy, желательно.
В принципе, подход автора сработает, если владелец сайта не против, чтобы его спарсили (нет JS, капчи и прочей защиты от ботов, авторизации, щедро раскиданы ARIA-атрибуты). А если владелец сайта против, то лично у меня уже на правовом моменте опускаются руки :D (натыкался на статью на эту тему https://habr.com/ru/articles/545818). Знаю, что через Selenium успешно обходят всё это дело (даже крутых антиботов от Cloudflare). Всякие прокси, сервисы для обхода капч и кастомные драйверы для Selenium сверху прилагаются само собой. Но всё равно сфера скрейпинга в правовом плане мутная. Для себя я решил в неё не соваться. Не уверен даже, что обсуждение инструментов для скрейпинга не попадет в будущем под цензуру по аналогии с VPN. Думаю, по той же причине на хабре и статей не густо
Слежу за эпопеей с ботом самого её начала. Хотел даже посоветовать бота знакомому ролевику. Однако анлаки: он, похоже, удалил группу (возможно, полностью переехал в Дискорд)
Очень хотелось бы прочитать историю, как всё к этому пришло )
И если уже речь пошла о "нестандартных решениях", не пробовали запускать .NET MAUI на Linux? (вроде как без вайна его даже запускают)
В контексте file-based apps (https://habr.com/ru/articles/965532/, https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs) выглядит очень интересно. Возможно, некоторые команды переедут с bash / python на c#. Осталось только дождаться, когда умельцы напишут nuget-пакеты со всеми утилитами
Но если честно, есть некоторое ощущение хаоса. Все эти shell-штуки не сочетаются с "нормальной" разработкой. Очень странный курс развития выбрали майкрософты
Заметил, что в статье практика PR'ов в основном критикуется за "токсичность" и за времязатратность. Однако я считаю, что эта проблема возникает из попытки решить "проблему доверия" через PR
Важные решения должны быть согласованы с командой, код должен быть покрыт тестами, а код-стайл - проверяться линтером. Тогда не придется "токсить" в PR'ах в духе "а почему скобочка не там стоит?" или еще хуже "а что это ты вообще выкатываешь?". И PR соответственно будут приносить чистый профит - позволят точечно фиксить какие-нибудь косяки по невнимательности / незнании предметной области / прочих человеческих факторах
Хотелось бы отметить тенденцию работодателей вкладываться во фронт по "остаточному" принципу. Т.е. мастерить конкретный UI-фреймворк почти не имеет смысла, т.к. работодателя удовлетворит, что ты хотя бы +- понимаешь, что там на фронте происходит. Больше играет роль знание бэкенд-фреймворка и инфраструктуры вокруг него. Ну это по моему опыту
Спасибо за комментарий. Рад, что статья оказалась полезной )
Отсутствие AsyncPipe - конечно, упущение. А JsonPipe, как правило, на текущем проекте мы не используем - поэтому я и не подумал о нём. Либо через дебаггер смотрим, либо через расширение Redux DevTools (используем NGXS)
Моя придирка скорее в том, что использование терминов, заимствованных из ФП, тут ни к месту, т.к. из ФП ничего не заимствуется в итоге - в ходе всех манипуляций мы получаем обычные объекты...
А если речь идет о том, чтобы полностью конструировать бизнес-логику из таких "объектов-функций", то в таком случае речь идет больше об уходе от ООП, чем о его паттернах. Что-то отдаленно напоминающее процедурное программирование получается ( просто пытаюсь сформулировать, как правильно называется такой подход; если честно, не знаю :D )
Ты сам же :D
Удачи юзнуть "функтор" с зависимостью от EF Core как коллбек на событие, допустим
---
Зачем изобретать тульский пряник на базе мятного пряника?
---
Еще раз повторюсь, что идея здравая. Хороший подход, который имеет место быть. Но в объяснении приплетены паттерны совсем из другой оперы с другими свойствами и предназначениями
Я прочитал и предыдущую статью, и эту, и комменты частично. Долго медитировал на счет корректности паттерна. С одной стороны, раскидать логику по разным юзкейсам - это идея здравая. С другой - чувствуется, что что-то не то... И в общем я пришел к выводу, что в статье просто описывается принип SRP: https://habr.com/ru/articles/454290/
Но это не функциональный объект, потому что:
функциональный объект в C# уже есть, это - делегат
таскать внешние зависимости из DI - это в общем-то антипаттерн для ФП; функции должны быть чистыми, иначе шибко их не закомбинируешь
Несмотря на путаницу в терминологии, идея в общем-то здравая имхо. Язык не повернется назвать антипаттерном... Если в фасад обернуть, так - вообще тема. Главное - слишком сильно не увлекаться декомпозицией, т.к. с большим количеством мелких объектов тоже проблематично работать
upd
Подтверждаю. В микросервисах может оказаться очень кайфово просто раскидывать по юзкейсам код. Там какой-нибудь MediatR + Minimal Api или FastEndpoints - и в путь. Нет смысла особо что-то инженерить, т.к. архитектурные границы уже были проведены на уровне сервисов
Это поисковик, а не браузер )
Считаю, что это не совсем корректная критика автора. Скрейпинг того или иного ресурса - всегда разный скрипт. Это нормально, что один прием может сработать на одном сайте, но на другом - нет
В принципе, подход автора сработает, если владелец сайта не против, чтобы его спарсили (нет JS, капчи и прочей защиты от ботов, авторизации, щедро раскиданы ARIA-атрибуты). А если владелец сайта против, то лично у меня уже на правовом моменте опускаются руки :D (натыкался на статью на эту тему https://habr.com/ru/articles/545818). Знаю, что через Selenium успешно обходят всё это дело (даже крутых антиботов от Cloudflare). Всякие прокси, сервисы для обхода капч и кастомные драйверы для Selenium сверху прилагаются само собой. Но всё равно сфера скрейпинга в правовом плане мутная. Для себя я решил в неё не соваться. Не уверен даже, что обсуждение инструментов для скрейпинга не попадет в будущем под цензуру по аналогии с VPN. Думаю, по той же причине на хабре и статей не густо
Слежу за эпопеей с ботом самого её начала. Хотел даже посоветовать бота знакомому ролевику. Однако анлаки: он, похоже, удалил группу (возможно, полностью переехал в Дискорд)
Желаю-таки найти свою аудиторию ))
Да, думаю, лучше всегда пользоватся Filebeat. Проигнорировал его только потому, что он что-то вроде "необязателен" в отличие от других компонентов