6 вещей, которые не стоит делать в ASP.NET контроллерах

Не очень понял пункт авторизация — это как понимаю проверка прав доступа? Или же определение кто вошел в систему? Последнее кажется лучше делать именно в контроллере

Wrike переходит с Dart на новый стек. Какой?

Жаль, что некомпетентность+имя на слуху убивает здравое отношение к angular

Микрофронтенды: разделяй и властвуй

Статья описывает воду. Где примеры того, как решается задачи ssr, как дружат версии библиотек(касаемо тех, которые сложно изолировать с помощью webpack). Как происходит предотвращение повторных загрузок одинаковых библиотек(для примера был опыт использования d3 + плагины, весили в сжатом виде 1мб). Как происходит подгрузка функционала, который должен быть загружен сразу, но не является базовой. Главное еще не только в том, что решается ли, а какими жертвами.
На шарике такое проходил, извращению не было границ)

Микрофронтенды: разделяй и властвуй

Микросервисная архитектура до сих пор не имеет хороших паттернов проектирования и поддержки. У кого-то http запросы, у кого-то amq. Каждый по разному решает как содержать разные версии. Хотя в помощь идут docker, kubernetes и прочий зоопарк. Микросервисная архитектура решает вопросы масштабирования как вычислений(1000 и более нодов на приложение), так и зоны отвественности. 100, 1000 и более разработчиков в одном котле становится нормой. Мне сложно представить фронтенд, который пилят 1000 разработчиков. Я не могу представить распределенный фронтенд. Верю в то, что с развитием скорости сети и серверных мощностей, фронтенд превратится в подобие рдп. Текущий технологии не позволяют хорошо изолировать код, до сих пор ресурсы пилят с оглазкой на медленный интернет. Фронтенд, в отличии от бекенда, варится в одном котле. Положил тухлый компонент к блюду и все блюдо в унитаз. Поэтому и существуют шеф повара, которые все проверяют и контролируют. Думаю ничто не мешает выделять в сторонние модули и компоненты, которые могут лежать в разных репозиториях, вести свои версии. А главный шеф повар будет проверять их перед добавлением в общий котел

Angular Universal: проблемы реального приложения

Спасибо за статью

Реализация архитектуры Redux на MobX. Часть 1: «Проблемные места Redux»

Признаю ошибку)

Реализация архитектуры Redux на MobX. Часть 1: «Проблемные места Redux»

Мне кажется автору стоит перечитать принципы SOLID. Они относятся к ООП, а не к ФП. Для React выбрал бы скорее redux, чем Mobx. Для меня лично, обычная среда применения React небольшие и средние приложения. В подобных проектах много неопытных программистов, соответственно redux ведет их по своей простой архитектуре, позволяя избегать многих ошибок. Да и легковесность манипуляций данных в redux позволит в небольших проектах получить лучшую отдачу. В крупных проектах предпочел бы mobx, особенно касаемо проектов связанных с данными в виде дерева. Да и плюс использовал бы не React, а Аngular. Ему философия Mobx ближе)

Наследование компонентов в Angular: простой способ решить проблему с Dependency Injection

Много лет программирую на angular. Возникали также мысли наследования, но в итоге пришел к выводу, что бесполезное это дело. Костылей только больше будет. Лучше применять композицию, чем наследование

Фронтендеры — герои. Yehuda Katz объясняет почему

По большинству задач соглашусь с вами. Сам программирую и фронтенд и бекенд. На бекенде становится сложнее, когда приходится решать нетиповые задачи, правильнее сказать задачи, которые требуют больше ресурсов, чем может дать железо сервера, сетевые ограничения. Тут и начинаются танцы с бубном). На фронте проще упереться в ограничения.

Фронтендеры — герои. Yehuda Katz объясняет почему

Боюсь webassembly породит еще больше проблем, они просто будут другими), но решит текущие)

Фронтендеры — герои. Yehuda Katz объясняет почему

Деление есть, но его мало. Для примера есть SharePoint. Знания только c# будет мало, надо понимать особенности экосистемы SP. Если покопать, то причина кроется в маркетинге и попытке удешевить оплату труда разработчика, уменьшая порог вхождения. То бкенда тоже доберется). В целом кодить на фронте сложнее чем на бекенде. Большинство фронтовых заказов в области сайтиков, с которыми справляются и недопрограммситы)

Почему сеньоры ненавидят собеседования с кодингом, и что компании должны использовать вместо них

Статья классная и в точку. Сам проходил собеседования, в которых спрашивали вещи, которые не то что нельзя применять в реальной жизни, а надо бить по рукам. Лично как по мне, сеньор разработчика стоит больше спрашивать про архитектуру, давать задачи по этой тематике. Уточнять детали предыдущего опыта, какие проблемы решали, как решали. Многие моменты забываются. В университете щелкал на раз два дифференциальные уравнения, интегралы. А если сейчас дать в лоб решить уравнение, буду пеньком)

CRM: не играйте в конструкторы, это больно

Автор раскрывает различными проблемами, а в конце такой — мы крутые ребята сделали фантастику. Честно у меня вызвало отвращение к статье

CRM: не играйте в конструкторы, это больно

Прервемся на рекламу)

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

Причин отвращения от редакса много. Правильнее рииидакс), а не редукс))), без обид)

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

блок внутри try вызовит rendering два раза

Разбор вступительного теста этого года в корпоративную магистратуру JetBrains на базе Университета ИТМО

Только все забывается)

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

Распространённость в целом, не значит подходит везде). Пробовали redux, вообще не зашло. Перешли на mobx, кайфуем)

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

Не вспомню спикера, но им были сказаны классные слова. Редакс отлично вписывается в те проекты, где нет времени придумывать архитектуру или слабая команда разработки. Т.е. на молодых не надо много тратить времени на обучение, как говорится смотри документацию. В остальном редакс не дает особого профита

Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее

Что так поздно). Выступали в Иннополисе, когда снег лежал, а статью только-только выпустили)))