Рубрика «Проектирование и рефакторинг»

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

Сложность на границе хаоса, или что общего между сексом, нейронными сетями, микросервисами и организацией компании - 1

Читать полностью »

Продолжаем рассказывать про технические особенности реализации проекта по выпуску и обслуживанию банковских карт «МегаФона». В предыдущих постах мы говорили о карте как о финансовом продукте, о ее возможностях и об устройстве программного обеспечения, которое обеспечивает работу системы. В этом посте мы затронем вопросы, связанные с интеграцией  IT-систем «банка Раунд» — партнера «МегаФона» по проекту — с IT-системами оператора. Технологическим партнером по созданию интеграционного решения, объединяющего IT-системы банка и «МегаФона», стала компания «Неофлекс» — системный интегратор с более чем двенадцатилетним опытом работы на IT-рынке.

О карте МегаФона — технические подробности, часть 2 - 1

Читать полностью »

После пяти лет работы с Node.js я многое понял. Я уже делился некоторыми историями, но в этот раз хочу рассказать о том, какие знания дались труднее всего. Баги, проблемы, сюрпризы и уроки, которые вы можете использовать в собственных проектах!

Базовые концепции

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

Классы

Когда я только начал работать с Node.js, то написал скрапер. Очень быстро я понял, что если ничего не предпринять, то он будет осуществлять много запросов параллельно. Одно это стало важным открытием. Но поскольку я ещё не полностью усвоил мощь экосистемы, то сел и написал собственный ограничитель параллелизма. Он работал и проверял, что в каждый момент времени активны не более N запросов одновременно.
Читать полностью »

Всем привет! Те, кто следит за нашим блогом, уже заметили, что мы выкладывали в открытый доступ трансляцию главного зала последних двух наших Java-конференций. Что ж, мы видим, что вам это нравится, поэтому продолжаем: в этот раз трансляция мы делаем оналйн-трансляцию второго дня конференции по мобильной разработке Mobius 2017.

Завтра с 10 утра мы начинаем бесплатную YouTube-трансляцию первого трека конференции! Первый трек – самый большой и популярный среди наших участников, – будут доклады об архитектурах мобильных приложений, кодогенерации, и кое-чем другом. В главном зале большая часть докладов посвящена Android, однако есть пара докладов и для iOS-разработчиков.

Открытая трансляция главного зала конференции Mobius 2017: Поговорим про архитектуру мобильных приложений и кое-что еще - 1

Ссылка на трансляцию и подробную программу – под катом.
Читать полностью »

Уже продолжительное время я размышляю над паттерном RxPM и даже успешно применяю его в «продакшне». Я планировал сначала выступить с этой темой на Mobius, но программный комитет отказал, поэтому публикую статью сейчас, чтобы поделиться с Android-сообществом своим видением нового паттерна.

Все знакомы с MVP и MVVM, но мало кто знает, что MVVM является логическим развитием паттерна Presentation Model. Ведь единственное отличие MVVM от PM – это автоматическое связывание данных (databinding).

В этой статье речь пойдет о паттерне Presentation Model с реактивной реализацией биндинга. Некоторые ошибочно называют его RxMVVM, но корректно будет называть его RxPM, потому что это модификация шаблона Presentation Model.

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

Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM - 1

Читать полностью »

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

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

Если микросервис перестает отвечать на запросы в результате аварии, его клиенты должны быть мгновенно перенаправлены на резервный. Для управления потоком запросов часто используют так называемые очереди сообщений (message queues).

Недавно используемая нами очередь перестала нас устраивать по параметрам отказоустойчивости и мы заменили ее. Ниже мы делимся нашим опытом выбора.

Читать полностью »

Или как мы перестали беспокоиться и научились доверять компилятору

TypeScript в Slack - 1

Когда Брендан Эйх создал самую первую версию JavaScript для Netscape Navigator 2.0 всего за десять дней, вряд ли он ожидал, в какой степени Slack Desktop App будет использовать его изобретение. Мы используем только кодовую базу JavaScript для многопоточного десктопного приложения, которое постоянно взаимодействует с нативным кодом и работает под Windows, macOS и Linux.

Управлять большими кодовыми базами JavaScript непросто. Всякий раз, когда мы мимоходом передаём объекты из JavaScript браузера Chrome в Objective-C, чтобы просто получить обратный вызов через другой поток на Node.js, нужна гарантия, что все кусочки складываются вместе. В десктопном мире маленькая ошибка может привести к сбою приложения. С этой целью мы внедрили TypeScript (статически типизированное надмножество JavaScript) и быстро поняли, как жить без волнений и с любовью к компилятору. И не только мы: опрос разработчиков на Stack Overflow показывает, что TypeScript является третьей самой любимой технологией программирования. Учитывая, насколько быстро статическая проверка типов набирает ход, мы хотим поделиться нашим опытом и методиками.
Читать полностью »

Сравнение производительности версий PHP - 1

В этой статье мы рассмотрим результаты нескольких бенчмарков, начиная с PHP 5 и вплоть до экспериментальной JIT-ветки (сейчас в разработке). На момент написания не было известно, появится ли до PHP 8 ещё какая-то основная версия, например PHP 7.2. Но логично предположить, что возможности экспериментальной ветки как минимум будут включены в PHP 8.

Читать полностью »

Идиомы Attorney-Client и Passkey для выборочного доступа к методам класса - 1 При проектировании приложений на C++ временами возникает необходимость предоставления доступа к закрытым методам класса другому классу или свободной функции. Для этого в языке C++ есть ключевое слово friend, которое предоставляет полный доступ не только к публичному интерфейсу класса, но и к закрытому, и всем деталям реализации. Таким образом friend работает по принципу «все или ничего» и «все» может быть слишком много. Например, когда есть класс Facade и несколько клиентов Client1, Client2, то может потребоваться предоставить каждому клиенту доступ только к определенному набору методов, причем каждому клиенту к своему набору, не предоставляя доступа к деталям реализации. Для решения такой задачи в C++ есть все возможности. В этой статье я расскажу про две идиомы Attorney-Client и Passkey и как их использовать с нулевыми накладными расходами.
Читать полностью »

Архитектура модульных React + Redux приложений - 1
Большинство разработчиков начинает знакомство с Redux с Todo List Project. Это приложение имеет следующую структуру:

actions/
  todos.js
components/
  todos/
    TodoItem.js
    ...
constants/
  actionTypes.js
reducers/
  todos.js
index.js
rootReducer.js

На первый взгляд такая организация кода кажется логичной, ведь она напоминает стандартные соглашения многих backend MVC-фреймворков:

app/
  controllers/
  models/
  views/

На самом деле, это неудачный выбор как для MVC, так и для React+Redux приложений по следующим причинам:

  1. С ростом приложения следить за взаимосвязью между компонентами, экшнами и редюсерами становится крайне сложно
  2. При изменении экшна или компонента с большой вероятностью потребуется внести изменения и в редюсер. Если количество файлов велико, скролить IDE вверх/вниз не удобно
  3. Такая структура потворствует копипасте в редюсерах

Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).Читать полностью »