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



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

Дэн Абрамов, в мае прошлого года, писал в своём Твиттере о том, что он не понимает микрофронтенды. Он полагает, что задачи, которые они должны решать, уже решены средствами хороших компонентных моделей. «Может, микрофронтенды — это решение организационных проблем, а не технических? Например, когда две команды разработчиков не могут ни о чём договориться, в том числе — об инфраструктуре проекта», — размышляет он.

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

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

Кори Пайн

Меня зовут Эдгар (ZergsLaw), я работаю в компании, которая занимается  финтех-разработкой для b2b и b2c. Когда только устроился в компанию, то попал в команду большого финтех-проекта и получил «в нагрузку» небольшой микросервис. Мне поручили его изучить и подготовить план рефакторинга, чтобы в дальнейшем выделить отдельную команду поддержки для сервиса.



«Мой» сервис — это proxy между определенными модулями большого проекта. На первый взгляд изучить его можно за один вечер и браться за дела поважнее. Но приступив к работе я понял, что ошибся. Сервис был написан полгода назад за пару недель с задачей протестировать MVP. Всё это время он отказывался работать: терял события и данные, или переписывал их. Проект перекидывали из команды в команду, потому что никто не хотел им заниматься, даже его создатели. Теперь стало ясно почему под него искали отдельного программиста.

«Мой» сервис — это пример плохой архитектуры и изначально неправильного проектирования. Все мы понимаем, что так делать нельзя. Но почему нельзя, к каким последствиям это приводит и как попытаться все исправить, я и расскажу.

Есть много проектов типа Simple Injector для различных языков программирования, позволяющих по имени класса, интерфейса или неймспейса, а иногда и папки зарегистрировать класс или всю группу классов, объединенных этим признаком, в каком-то регистре. Это делается для цели автоматического инстанцирования объекта без явного указания его зависимостей. Такую регистрацию группы объектов по общему признаку в регистре с целью дальнейшего инстанцирования я называю автоматической регистрацией зависимостей.

Интернет наводнен статьями о том, как похудеть "просто съедая меньше чем потратил" и отчетами об успешном опыте некоторых везунчиков. Чего нету (ну или очень мало) в интернете — это отчетов о том, как миллионы людей безрезультатно пытаются просто "съесть меньше", садясь на все новомодные диеты и неизменно возвращаясь к тому, с чего начинали, а иногда и скатываясь по шкале индекса массы тела в еще более красную зону.

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

В последние несколько лет ключевое слово async и семантика асинхронного программирования проникла во многие популярные языки программирования: JavaScript, Rust, C#, и многие другие. Конечно, в Python тоже есть async/await, они появились в Python 3.5.

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

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

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

Коллеги, добрый день! Меня зовут Миша, я работаю программистом.

В настоящей статье я хочу рассказать о том, как наша команда решила применить подход CQRS & Event Sourcing в проекте, представляющем собой площадку для проведения онлайн-аукционов. А также о том, что из этого получилось, какие из нашего опыта можно сделать выводы и на какие грабли важно не наступить тем, кто отправится путем CQRS & ES.

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

Для некоторых параметров конфигурации имеет смысл не запускать приложение, если они недействительны.

Spring Boot предлагает нам удобный способ валидации параметров конфигурации. Мы собираемся связать входные значения со @ConfigurationProperties и использовать Bean Validation для их валидации.

В языках программирования меня всегда интересовало их внутреннее устройство. Как работает тот или иной оператор? Почему лучше писать так, а не иначе? Подобные вопросы не всегда помогают решить задачу «здесь и сейчас», но в долгосрочной перспективе формируют общую картину языка программирования. Сегодня я хочу поделиться результатом одного из таких погружений и ответить на вопрос, что происходит при модификации tuple'а в list'е.

После появления DeBroglie и Tessera меня много раз просили объяснить, как они работают. Генерирование может выглядеть как волшебство, но лежащие в его основе правила на самом деле просты.

Хотя Close Quarters преимущественно является многопользовательской игрой, в ней всё равно должны присутствовать сложные ИИ-боты, чтобы игроки продолжали играть при плохом Интернет-соединении или отсутствии других онлайн-игроков. Кроме того, боты играют важную вспомогательную роль в некоторых режимах игры. Поэтому они должны вести себя правдоподобно и демонстрировать набор сложных поведений, в том числе использование укрытий, применение предметов в подходящее время, обход с флангов, бросание гранат и убегание от них.

Окружение и ограничения

Игровое окружение состоит из полигонов. Большинство полигонов блокирует движение, область видимости и стрельбу, однако есть и «низкие» полигоны, только блокирующие движение. Окружение плотно заставлено препятствиями и укрытиями.

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

Honey Tokens (англ. — «медовые приметы/признаки/идентификаторы») одна из разновидностей идеи Honeypot, приманки для злоумышленников, позволяющей обнаружить факт взлома или опознать его источник. Когда атакующий уже проник в систему, он, скорее всего, выполнит действия, несвойственные обычному пользователю. Это можно использовать как способ обнаружения взлома. В статье мы рассмотрим, как легко сделать собственные триггеры для обнаружения взлома на раннем этапе. Такие ловушки полезно использовать системному администратору и даже обычному пользователю, переживающему о приватности своих данных.

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

Решил перепостить с другой площадки материал dmitrykabanov в качестве продолжения его более ранней подборки «Вышел на дистанционку — запустил подкаст: что для этого почитать».

Вы можете использовать это руководство для различных целей:

• Чтобы понять, что такое Spring Framework
• Как работают ее основные фичи: такие как внедрение зависимостей или Web MVC
• Это также исчерпывающий FAQ (Перечень часто задаваемых вопросов)

Примечание: Статья ~ 9000 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже. И даже на компьютере ешь читай этого слона по одному кусочку за раз :-)

Содержание

• Введение
• Основы внедрения зависимостей
• Контейнер Spring IOC / Dependency Injection
• Spring AOP (Аспектно-ориентированное программирование) и прокси
• Управление ресурсами Spring
• Spring Web MVC
• Дополнительные модули Spring Framework
• Spring Framework: часто задаваемые вопросы
• Заключение

Мне давно было интересно, как сжимаются данные, в том числе в Zip-файлах. Однажды я решил удовлетворить своё любопытство: узнать, как работает сжатие, и написать собственную Zip-программу. Реализация превратилась в захватывающее упражнение в программировании. Получаешь огромное удовольствие от создания отлаженной машины, которая берёт данные, перекладывает их биты в более эффективное представление, а затем собирает обратно. Надеюсь, вам тоже будет интересно об этом читать.

В статье очень подробно объясняется, как работают Zip-файлы и схема сжатия: LZ77-сжатие, алгоритм Хаффмана, алгоритм Deflate и прочее. Вы узнаете историю развития технологии и посмотрите довольно эффективные примеры реализации, написанные с нуля на С. Исходный код лежит тут: hwzip-1.0.zip.

tl;dr У 90% современных смартфонов диагональ экрана превышает пять дюймов. Появление таких дисплеев представило принципиально новые проблемы для разработчиков приложений и дизайнеров. Давайте посмотрим, как их решить.



После презентации Apple в январе 2007 года весь мир сжался до размера наших ладошек. Компания объединила iPod, телефон и браузер в едином устройстве. Apple представила на массовый рынок новый для себя класс устройств, которые нам сегодня известны как «смартфоны». Эти гаджеты работали без клавиатуры (как у BlackBerry) или стилуса (как Palm).

iPhone был спроектирован для удобной работы только одной рукой, с плавными движениями большим пальцем по экрану.

HR-специалист одной компании недавно сказал такую фразу: “разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile”. И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.

Ведь одна из целей Agile – создание комфортных условий для работы тех самых разработчиков. Agile-практики стремятся освободить разработчиков от рутины, поощряют творческий подход. Самоорганизация, минимизация бюрократии – всё это призвано упростить жизнь разработчиков. Happiness (счастье) разработчиков – одна из Agile-метрик, которую нужно повышать.

Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?

Эта работа вдохновлена статьей «Мечтают ли нейросети об электроденьгах?», где автор без преувеличения талантливо в своей доходчивости объясняет, почему использование искусственных нейросетей на голых биржевых данных не приводит к успеху. Вот особенно, на мой взгляд, удачный отрывок:

«Цена не формирует сама себя… Если рынок выразить как метафоричное озеро, то биржевой график это лишь рябь на воде. Может быть это ветер подул, может камень в воду бросили, может рыбы плеснула, может Годзилла прыгает в 200 километрах на батуте. Мы видим лишь рябь.»

Действительно, пытаться предсказать поведение ряби на следующий день, имея в распоряжении только лишь данные о поведении ряби в прошлом, видится, как минимум, самонадеянным. Не тот масштаб модели. Поведение водной глади формируется за счет множества внешних и внутренних по отношению к водоему факторов. И вот на этом моменте мое любопытство не позволило мне пройти мимо. А что если все-таки поработать с этими факторами? Что получится, если учесть их в модели данных, предназначенных для «кормежки» нейросети?

«Но как же учесть миллионы, если не миллиарды возможных факторов влияющих на наш метафорический водоем?» — спросите вы. А я отвечу, что нас не интересуют ни движение мальков, ни случайно упавший с близлежащей скалы камушек, ни мерное покачивание удочки Дяди Вити-рыбака. Нас интересует Годзилла.

Для остановки нет причин — 
Иду, скользя.
И в мире нет таких вершин,
Что взять нельзя.
В. Высоцкий

Если бы эта статья вышла не на Хабре, а в образовательном журнале, я бы начал её так: «Вспомните сайты, которые вам нравятся, на которых удобная навигация и приятный интерфейс. А знаете ли вы, что это только верхушка айсберга…». Но на Хабре это знают, пожалуй все, поэтому никакой лирики. Бэкенд любого веб-проекта — это сложная система, которая позволяет приложению быстро работать, качественно искать, шустро отдавать информацию пользователю, надёжно и безопасно хранить данные и при необходимости работать с другими внешними системами. Это как швейцарские часы: покупают их за стиль и шильдик, но ценители знают, что под сдержанным циферблатом кроется волшебный мир часового механизма. И бэкенд-разработчики — это маги механизмов, организмов, кишочек, внутренностей или как вы ещё это называете у веб-приложений. Эх, без лирики не удалось! 

Короче, сегодня разбираем очередную профессию в серии «Профессия…». Итак, а что, если пойти в бэкенд-разработчики? 

Бэкенд это всегда немного боль