• Android + Redux = <3
    –1
    Настолько сильно что потом становится тяжело свести концы с концами, и понять какая цепочка экшенов отработала. Кроме того служебные расходы на перегенерацию стейта сильно превысят полезную нагрузку. Кроме того redux один не идет, к нему еще понадобится цепочка библиотек которые костыляют проблему синхронных экшенов и лишних перерисовок, всякие саги, реселекты и прочее. Вообще redux позиционирует себя как масштабируемое решение, но есть одно НО, относительно чего? А хорошо масштабируется оно относительно jquery скриптов, а относительно чистой архитектуры он наоборот создает проблему масштабирования.
  • История возникновения CUPID (критика SOLID)
    +2
    blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
    Ответ Дяди Боба на эту статью. Надеюсь тоже переведёте.
  • Архитектурный паттерн Dependency Injection в React-приложении
    +1
    Коллеги, вот DI без жирного минуса.
    habr.com/ru/post/496860
  • Software Engineer + Product Manager = Product Engineer?
    +2
    А на самом деле хороший термин что бы отделить менеджера который в жизни ни строчки не написал, но при этом руководит разработкой, от успешного программиста который в тоже время успешный менеджер.

    На моем опыте разработчики менеджеры делают гораздо более успешные продукты чем менеджеры проекта. А термин Product Engineer поможет таким людям самоопределиться и заняться своё место в продукте.
  • Рабочая станция в Docker контейнере
    0
    У меня выдалось время посмотреть конфиг. Теперь из коробки стартует с красивыми темой, обоями и ярлыками в быстром запуске.
    Так же в свете плохих новостей о центосе, заменил базовый дистрибутив на fedora. Они бинарно совместимые, так что проблем с переходом не будет.
  • Rollup: уже можно собирать приложения
    +1
    У них разные задачи:
    Gulp это Таск Менедджер — служит для организации задач, сам по себе ничего не умеет, а всю работу делает через дополнения, например тот же роллап.
    Rollup это Бандлер — служит для сборки кода в бандл.

    Раньше всякие библиотеки были не очень дружелюбны к консольным инструментам и gulp хорошо решал свою задачу по настройке и запуску таких библиотек. Сейчас же почти любая библиотека затачивается под работу из консоли, поэтому gulp и перестал пользоваться популярностью.
  • Минифицируем приватные поля в TypeScript. Доклад Яндекса
    +2
    Тоже когда то давно баловался google closure compiler и основная причина почему отказался от него это очень медленная скорость сборки, которая занимала несколько минут, в то время как browserify делал это за несколько секунд. Все таки -5% к размеру бандла не стоят +50% к времени разработки.

    Но еще меня интересует почему Яндекс считает что поддерживать старые браузеры важнее чем поддерживать самые популярные браузеры? Я имею ввиду что TS может сам скомпилировать в ES2015, rollup/webpack собрать c treeshaking без babel трансформаций, terser минифицировать с учетом оптимизаций ES2015. И все это будет весить гораздо меньше транспилированного кода и работать в 3 раза быстрее на 80% самых популярных браузерах. А для старых сделать второй бандл на es5 с трансформами babel и полифилами.
  • А почему мы не пишем код в контроллерах?
    +3
    Потому что если сложность вашего приложения превосходит туду приложение, то ваши контроллеры превращаются в помойку.
  • Переработка архитектуры React Native в 2020 году
    +1
    А доступ к нативному апи платформы (без моста) появится?
  • TS-Serializable 2: с конвертации свойств из snake case и декоратором вместо наследования
    0
    Все равно получится смешанный стиль. Потому что кроме твоего кода, есть еще апи и библиотеки в стандартном стиле.
  • Как поезд проходит путь от станции до станции: особенности маршрутизации
    0
    Вот в этом не силен. По моему все (за редким исключением) международные поезда на тягаче. В крайнем случае встроят системы для нескольких стран.
  • Как поезд проходит путь от станции до станции: особенности маршрутизации
    +1
    Кажется на границе просто меняются локомативы.
  • Чистая Архитектура для веб-приложений
    +1
    Спасибо за подсказку. Теперь буду делить сервисы на Application Services, Infrastructure Services, Domain Services. Так же выделил еще одну группу View Services с логикой для вьюхи, не связанную никак с бизнесом, не зашиваемую в компонент, не относится к паттерну helper. Например генерирует css анимации для разных вьюх на основе состояния бизнес логики. Да да, у меня и такое встречается =)
  • Чистая Архитектура для веб-приложений
    0
    Не прибит, в статье про это не рассказал, но менять можно. На один вью может приходиться несколько контроллеров, на один контроллер может приходиться несколько вью. Главное что бы интерфейс сохранялся.
  • Чистая Архитектура для веб-приложений
    0
    Да вы правы. Логика которая относится к модели нужно размещать в методах модели. В примерах кода так и было сделано. В сервисах помимо склеивание, конкретно у меня есть еще логика по обработке не связанных моделей или массива моделей. Например из массива моделей выбрать подходящие под какие либо условия. Или на основание двух разных моделей получить третью. А также случаи логики не связаны с моделями совсем. Если у вас по другому, расскажите пожалуйста как реализовано у вас.

    В статье не хотел усложнять сложными формулировками, но наверное надо будет придумать более удачное описания для этих двух слоев.
  • Чистая Архитектура для веб-приложений
    0
    Тогда может быть напишите свою статью? Как вы представляете себе ЧА в веб-приложении на любой библиотеке? Вдруг ваш подход и вправду окажется лучше. По обрывкам предложений не понятно.
  • Чистая Архитектура для веб-приложений
    0
    Хорошо. Если не нравится сравнение с ЧА, давайте по другому. Каким общепринятым названием называется архитектура в которой логика делиться на слои view, controller, model, service, viewModel, repository, entity и так далее...?

    Подход который использует VSCode я уже десять лет наблюдаю в ASP.Net. Так что вариант «своя архитектура» не учитывается.
  • Чистая Архитектура для веб-приложений
    +2
    Размеры веб приложений растут. А решений для написания больших приложений нет. Поэтому люди обращаются к практикам из других систем. Поэтому таких статей будет только больше.
  • Чистая Архитектура для веб-приложений
    0
    Боюсь если соблюдать всё что вы написали, то это отпугнет вообще всех фронтенд разработчиков. Можно конечно и интерфейс писать на каждый класс и разделение слоев делать более «эталонным» и вообще сделать все «энтерпрайзненько», но это не решит никаких проблем проекта, только раздует техдолг до огромных масштабов.

    Поэтому не надо никому доказывать что вы лучше поняли книгу, тем более что автор книги не автор этой архитектуры. И не надо так радикально подходить к соблюдению всего что написано в книге. Достаточно взять только то что решает твои проблемы и не создает проблем с поддержкой и уже получится хороший продукт.
  • Чистая Архитектура для веб-приложений
    +2
    Поступок с Angular 1, когда фреймворк просто бросили и написали другой, нанес мне психологическую травму. С тех пор я не доверяю никакому Angular =).

    Статья в первую очередь для тех кто уже писал на других платформах и хочет переключиться на веб разработку. Судя по статьям на хабре за последнее время таких весьма много. Кроме того многие Angular разработчики не видят будущего в этом фреймворке, и так же хотят перейти на более популярный с сохранением опыта.

    Я знаю что 60% разработки на реакте это редакс. А так я предложил успешную концепцию которая справляется с любой задачей по гибкости и производительности. И если хотя бы часть сообщества не побоится использовать такой подход, то это уже хороший шаг к наведению порядка на реакте.
  • Чистая Архитектура для веб-приложений
    0
    Полусайт-полуприложение. К тому же весьма дорогое по стоимости поддержке серверов. Отдать клиенту статику и отрендерить на клиенте приложение в сотни раз дешевле.
  • Чистая Архитектура для веб-приложений
    0
    Тулинг работает исправно.
    Все данные для переиспользования распологаются в сервисе.
  • Чистая Архитектура для веб-приложений
    0
    Объясняю потихоньку, вот статью даже написал. Но я не бесконечный.
  • Чистая Архитектура для веб-приложений
    0
    На самом деле это стереотип. На беке достаточно иметь защищенное АПИ, для любых клиентов и интеграций. А выдает ваш бек html или json на безопасность никак не влияет.
  • Чистая Архитектура для веб-приложений
    0
    Хорошо, допустим в VS Code это не ЧА. Тогда давайте найдем что же это за архитектура там применяется.
  • Чистая Архитектура для веб-приложений
    0
    Про организацию в том числе. Но SCREAMING ARCHITECTURE нужно рассматривать отдельно от Clean Architecture. И я считаю ее личным мнением автора книги.

    И самый главный момент, книга написана по уже имеющийся архитектуре, а не код организовали по книге.
  • Чистая Архитектура для веб-приложений
    +2
    Смотря что и как писать. Если просто провалидировал и отправил на сервер или получил с сервера и показал что пришло, то да, излишне. А если писать Приложение с большой буквы, то очень даже помогает =).
  • Чистая Архитектура для веб-приложений
    0
    Согласен что эталонной нет. В том же Asp.Net Core и JavaSpring между ними есть разница. Но тут главное не дословное следование книжке, а сама суть процесса по разделению кода.
  • Чистая Архитектура для веб-приложений
    0
    Я работаю в команде. И обычному фронту вообще тяжело понять что такое Service и почему нельзя на jquery скрипт написать. Поэтому я стараюсь не усложнять такими подробностями. Ведь в любом случае это Service =)
  • Чистая Архитектура для веб-приложений
    0
    Это скорее касается организации кода, нежели архитектуры. У Мартина есть свое мнение, у меня свое. Я стараюсь придерживаться организации кода как по ссылке. У такого подхода тоже свои глубокие корни.
  • Чистая Архитектура для веб-приложений
    +1
    Да, Мартин не является автором такого подхода, так же как и Рихтер не является автором CLR. Но Мартин написал популярную книгу рассказывающую о таком подходе и дал название такому подходу, которое стало общепринятым. И Чистая Архитектура дополняет слоистую архитектуру.
  • Чистая Архитектура для веб-приложений
    0
    Clean Architecture в коде никогда не упоминается. Суть чистой архитектуры в организации кода по слоям View, Controller, Service, Repository, Model, ViewModel. Все они у вас перед глазами сразу по ссылке.
  • Чистая Архитектура для веб-приложений
    0
    Открыть ссылку выше которая приведет прямо на исходники.
  • Чистая Архитектура для веб-приложений
    +1
    Если вы скинете ссылку на его текст, то ситуация проясниться. Пока что совсем не понятно о чем вы говорите.
    По поводу веба к счастью разработчики VS Code не посчитали это глупостью и написали на CA приложение на электроне которое не тормозит. Кроме того такой подход из коробки идет у Android и iOs, в iOs даже название Controller сохранено.
  • Чистая Архитектура для веб-приложений
    +2
    Этот подход на самом деле самый популярный на mobx. Я бы назвал его ленивый CA =)
  • Чистая Архитектура для веб-приложений
    +2
    Я ее использую не столько что бы абстрагироваться от фреймворка сколько абстрагироваться от платформы. Поскольку я пишу не только веб, но и бек, и мобилки, и настольные приложения на C#. И такой подход позволяет мне свободно переключаться между платформами и гибко реагировать на любые повороты в бизнес требованиях.
  • Чистая Архитектура для веб-приложений
    0
    Возможно вы ошиблись главой, но не могу найти такого в книге. Книгу я читал очень давно, но на сколько я помню слой представления в ней вообще не рассматривается.
  • Чистая Архитектура для веб-приложений
    +1
    В статье по ссылке нету однозначного утверждения что это плохо. К тому же я не фанат smalltalk. Моя логика в приложении исходит из соображений минимизации связанности в коде. Поэтому если бизнес правила можно поместить в 1 модель, то они помещаются в модель. Если же для решения бизнес задач необходима координация из нескольких моделей, то я размещаю ее в сервисе.
  • Рабочая станция в Docker контейнере
    0
    Спасибо большое!
    Добавил
    system «rm -fr /tmp/.X11-unix/*; rm -fr /tmp/X1-lock; rm -fr /home/headless/.Xauthority; rm -fr /home/headless/.vnc/*.log; rm -fr /home/headless/.vnc/*.pid»
    без судо, до запуска vnc. Теперь контейнер можно перезапускать.
  • Рабочая станция в Docker контейнере
    0
    Я не ставил себе цели полностью переехать в контейнеры. Поэтому с gpu не заморачивался, тем более что на хосте его нет, даже в процессоре. Но судя по таким репозиториям github.com/NVIDIA/nvidia-docker использования gpu возможно.