В процессе развития юнити разработчики проходят путь от “god обжектов” до проектирования сложных, гибких, абстрактных систем. Со временем эти системы обрастают своими уникальными особенностями, стандартами и инструментами. Образуя из себя фреймворк или даже движок.

Такие фреймворки зачастую имеют излишний функционал для конкретно взятых задач. Документации становится все больше и больше, да просто тонны документации! Не смотря на это, порог вхождения для вновь прибывшего на проект разраба неуклонно растет. А также есть те кто сразу же отказывается от работы на таких фреймворках, со словами “А зачем мне лезть в это абстрактное болото!?”. И я их прекрасно понимаю.

И что же получается, пытаясь избежать проблем с хард кодом мы обрели другие проблемы, так особо и не повысив скорость разработки!? Проблемы, для устранения которых, необходимо ооочень много времени. Т.е. мы прошли путь от крайности к крайности от “хард кода” к фреймворку.

Вот и мы столкнулись с той же проблемой. Но нам пришла идея пойти по другому пути. Так возникла концепция новой модульной архитектуры. Ну ладно, может не такая уж и новая, но она имеет свои уникальные особенности. И это не совсем то что вы можете найти в интернете на тему модульной архитектуры, речь пойдет немного о другом.

https://habr.com/ru/post/710912/?utm_source=habrahabr&utm_medium=rss&utm_campaign=710912

Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.

При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные протоколы. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.

Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.

https://habr.com/ru/post/709362/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709362

Меня зовут Андрей Аркаев. Я занимаюсь разработкой на Java с 2002 года. Сейчас развиваю бизнес-систему для контактных центров в Naumen. Как и многие другие бизнес-системы мы используем ORM. В статье поговорим о Hibernate, так как эта библиотека распространена для Java.

Наш продукт развивается более 15 лет и накопил в себе много кода, в том числе легаси. Мы начинали с Hibernate версии 3 и прошли через 3 больших версии.

Если посмотреть статистику привязки к версиям Hibernate в Maven Central, то окажется, что к версии 5.5 привязано 400 проектов, к 5.6 — 1200 проектов, а к свеженькой 6.1 — буквально 180 проектов. То есть 6.1 еще только набирает обороты. Уже появляются первые доклады, как всё хорошо и радужно при обновлении на новую версию, однако реальность обычно другая. Поэтому интересно разобраться, какие есть сложности и проблемы, и как переходить на эту версию.

Сделаю ремарку: эта статья не рассказывает обо всех изменениях, а только о самом интересном и важном для меня и моих проектов.

https://habr.com/ru/post/708244/?utm_source=habrahabr&utm_medium=rss&utm_campaign=708244

Вольный перевод статьи на ресурсе threedots.tech от Robert Laszczak - главного инженера в SlashID, сооснователя Three Dots Labs и создателя популярной Golang-библиотеки Watermill.

На протяжении некоторого времени я занимался руководством группы Go-разработчиков и одним из самых распространенных вопросов от начинающих специалистов был - "Какой фреймворк мне следует использовать?".

https://habr.com/ru/post/705078/?utm_source=habrahabr&utm_medium=rss&utm_campaign=705078

Общее

Умер Фредерик Брукс, отец 8-битного байта, автор "Мифического человеко-месяца", "Design of Design" и "Серебряной пули не существует".

Java, язык и платформа

SlashData провели опрос по состоянию экосистемы разработки и по нему видно, что использование Java выросло со времен 2020 года процентов на 10.

Новые JEP для Java 20:

https://habr.com/ru/post/704788/?utm_source=habrahabr&utm_medium=rss&utm_campaign=704788

React vs Vue vs Angular. Общее сравнение JavaScript фреймворков

В ходе развития веб-разработки 3 JavaScript-фреймворка стали хорошо известны всем front-end разработчикам: React, Vue и Angular.

React считается библиотекой пользовательского интерфейса, Angular - полномасштабным front-end фреймворком, предоставляющим собственные инструменты для всех связанных с разработкой веб-приложений функций, а Vue - прогрессивным фреймворком, реализованным как дополнительная разметка для HTML.

Все три фреймворка могут использоваться практически взаимозаменяемо для создания компонентных frontend-приложений с расширенными возможностями пользовательского интерфейса. Однако окончательный выбор зависит от требований проекта и предпочтений разработчика.

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

https://habr.com/ru/post/703836/?utm_source=habrahabr&utm_medium=rss&utm_campaign=703836

Стейт-менеджеры уже давно стали своеобразным мемом среди разработчиков. Бытует мнение, что фронтедеры только тем и занимаются, что вместо решения действительно важных и актуальных проблем постоянно переписывают проект с одного стейт-менеджера на другой. Благо их количество и поток новых, выходящих в open source, позволяют.

Выход есть — Signals. Решение, по словам создателей, сочетает оптимальную производительность для разработчиков и легкое внедрение во фреймворк. Под катом — подробный разбор библиотеки.

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. И я тоже не люблю выделяться из толпы, поэтому предлагаю обратить внимание на новое решение от команды Preact — Signals. Во вступительной статье создатели библиотеки заявляют о том, что сегодня создано огромное количество решений по управлению состоянием приложения, но они требуют сложной и долгой интеграции с фреймворком. Это усложняет проектирование, так как нужно постоянно держать в уме особенности стейт-менеджера. Усложняется и разработка, так как нужно тратить много времени и сил на интеграцию стейт-менеджера и библиотеки рендеринга.

https://habr.com/ru/post/702108/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702108

Текущая статья будет посвящена обзору app, app-api и app-console шаблонов, а также demo приложений.

Рассмотрим некоторые особенности конфигурирования шаблонов приложений по умолчанию, а также логику работы конфигов и расположение кодовой базы.

https://habr.com/ru/post/697676/?utm_source=habrahabr&utm_medium=rss&utm_campaign=697676

При нынешнем оттоке ИТ специалистов в разное зарубежье, государство и ИТ сообщество абсолютно естественно обратило свой взор в сторону ИТ образования, как на живительный источник, способный напитать человеческим ресурсом, перестраивающуюся ИТ-отрасль.

В результате, с одной стороны, наблюдается массовое появление курсов дополнительного образования, всячески поддерживаемого государством, с другой - происходит пересмотр системы высшего ИТ-образования, называемый модным словом «трансформация». Поскольку я, являясь директором ИТ-компании, преподаю и в ВУЗ_е, и на курсах доп. образования (то есть участвую в обоих направлениях), попробую прокомментировать, какие проблемы на мой взгляд сопровождают эти инновационные процессы и опишу возможные способы их преодоления.

Область проблем.

Касаемо массового доп. Образования. В настоящее время, чаще всего на курсы набирается разношерстный народ, вовлеченный обещаниями: «Обучение «с нуля», «зарплата от 100 тыс. в месяц». А дальше, втянутых в эту авантюру (в хорошем смысле слова), в очень сжатые сроки «бомбят» теорией с элементами самообучения по темам. Практические занятия обычно проводятся на столько бегло, что только отчасти дают представление о том, как выхваченные ранее обрывки теории соотносятся с практикой. Смотреть на самостоятельные работы, даже лучших, без сожаления невмоготу, а остальные и вовсе их не делают. Такое состояние дел в общем то приемлемо на ранних стадиях изучения темы, но страшно то, что других стадий уже и не будет, обучающиеся перескакивают дальше к следующим предметам, а организаторы курсов считают это уместным. «Участники обучения» без обиняков честно сознаются, что они просто-напросто не успевают готовить задания, да и количество их в группах таково, что преподаватели не могут физически охватить всех своим вниманием. Ведь разбор заданий, выполненных учащимся, это отдельная кропотливая работа наставника, который должен не просто указать на ошибки, а натолкнуть на мысль, что не так выполнено, почему не так и, как выполнить правильно. Когда в группе 80 человек и 1,5 часа на практическое занятие, извините это не практика, а профанация. Нет, конечно, результаты в большинстве случаев есть, люди, прошедшие через горнило таких курсов, получают определенное представление о том, как примерно могут создаваться ИТ-продукты, но для участия в их создании, они увы пока непригодны.

https://habr.com/ru/post/701378/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701378

Процесс разработки можно назвать тогда оптимальным, когда он приносит максимум прибыли с минимумом затрат. Как утверждают классики политэкономии, если одна компания выстраивает все процессы так, что ее продукт получается в два раза дешевле, чем у других, то при прочих равных она получает в два раза больше прибыль, чем другие. И так продолжается до тех пор, пока остальные не введут те же усовершенствования, и ситуация на рынке не выровняется. Цель понятна. Теперь, как этого можно добиться в разработке игр.

Одна из самых больших статей расходов в IT-компаниях — это программисты. К тому же самая сложно управляемая и контролируемая статья. Административные меры тут работают плохо, и чтобы эффективно воздействовать на программистов, нужно самому, минимум, быть программистом. Поэтому опишем чисто программистские меры и способы по снижению затрат и увеличению производительности.

https://habr.com/ru/post/697502/?utm_source=habrahabr&utm_medium=rss&utm_campaign=697502

Yii3 – пакетный фреймворк. А это значит, что вы можете использовать библиотеки из фреймворка в отвязке от экосистемы Yii. Например, такие пакеты можно подключить к Yii 2, Symfony, Laravel, к проекту без фреймворка или в любой другой PHP-проект.

В этой серии статей разберемся с основами "тройки", принципами построения фреймворка, готовыми библиотеками, инструментами для разработки, рассмотрим готовые шаблоны и demo приложения.

Кстати, чтобы следить за прогрессом существующих пакетов в Yii3 есть отдельная страничка: https://www.yiiframework.com/status/3.0.

https://habr.com/ru/post/695664/?utm_source=habrahabr&utm_medium=rss&utm_campaign=695664