В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:
В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.Читать полностью »
Мы очень часто используем понятие сложности, мы с ней боремся, и в то же самое время, мы создаем все более упорядоченные структуры, мы уменьшаем энтропию и утверждаем себя этим. В то же время, мы должны быть готовы к изменениям, мы должны быть адаптивными. Где точка равновесия? Что стоит за всеми этими понятиями и концептами. Может есть нечто, что объединяет это все, скрываясь от наших глаз, и в то же время находясь постоянно у нас на виду?
Продолжаем рассказывать про технические особенности реализации проекта по выпуску и обслуживанию банковских карт «МегаФона». В предыдущих постах мы говорили о карте как о финансовом продукте, о ее возможностях и об устройстве программного обеспечения, которое обеспечивает работу системы. В этом посте мы затронем вопросы, связанные с интеграцией IT-систем «банка Раунд» — партнера «МегаФона» по проекту — с IT-системами оператора. Технологическим партнером по созданию интеграционного решения, объединяющего IT-системы банка и «МегаФона», стала компания «Неофлекс» — системный интегратор с более чем двенадцатилетним опытом работы на IT-рынке.
В современном мире информационных технологий у всех — и у крупных, и у небольших компаний — существует большое количество различных API. И отказоустойчивость, несмотря на многие best practices, чаще всего не позволяет гарантировать 100%-й возможности корректно обрабатывать запросы клиентов, а также восстанавливаться после сбоя и продолжать обработку запросов, утерянных из-за сбоя. Эта проблема возникает даже у больших игроков в интернете, не говоря уже о не очень крупных компаниях.
Я работаю в компании Calltouch, и наша основная цель — добиться отказоустойчивости сервисов и получить возможность управлять данными и запросами, которые клиенты совершали в API-сервис. Нам нужна возможность быстро восстанавливать сервис после сбоя и обрабатывать запросы к сервису, у которого возникли проблемы. Начинать обработку с момента отказа. Всё это позволит приблизиться к состоянию, когда почти невозможно потерять запросы клиентов на нашей стороне.
Разбирая предложенные на рынке решения, мы открыли для себя превосходную производительность и практически безграничные возможности по управлению данными и их обработке — с очень незначительными требованиями к техническим и финансовым ресурсам.
Пошаговая инструкция по выявлению недочетов в системе безопасности веб-приложений с помощью Detectify для поиска уязвимостей.
97% проверенных TrustWave приложений уязвимы перед тем или иным видом угрозы.
Продолжение осмысления самых маленьких бесконечных множеств в архитектуре приложений через игры с зависимостями, из первых уст.
У меня есть друг, его профессия связана с электромонтажом. Когда он был моложе и циничнее, он любил травить байки про электриков, которые работали на необесточенных сетях. Конец всегда был занимательный, но печальный для главного героя. С компонентной архитектурой так же: где-нибудь не изолируешь один функционал от другого, «ударит током» и тебя, и того, кто будет после тебя. Разница в том, что изоляция в IT пока более затратное удовольствие, чем в электрике.
В этой статье мы рассмотрим результаты нескольких бенчмарков, начиная с PHP 5 и вплоть до экспериментальной JIT-ветки (сейчас в разработке). На момент написания не было известно, появится ли до PHP 8 ещё какая-то основная версия, например PHP 7.2. Но логично предположить, что возможности экспериментальной ветки как минимум будут включены в PHP 8.
К сожалению, у этого термина нет хорошего русскоязычного аналога. «Википедия» дает перевод «мультиарендность, множественная аренда». Иногда это называют «множественным владением». Эти термины могут несколько путать, так как предмет не связан по сути ни с арендой, ни с владением. Это вопрос именно архитектуры программного обеспечения и организации его эксплуатации. Причем последнее не менее важно.
Мы начали формировать наше понимание multitenancy одновременно с тем, как начали проектировать подход к облачной (сервисной) модели работы «1С:Предприятия». Это было несколько лет назад. И с тех пор наше понимание постоянно расширяется. Мы постоянно обнаруживаем у этого предмета все новые и новые аспекты (плюсы, минусы, сложности, особенности и т.п.).
При поиске кратчайшего пути на графах большого размера плохо работает традиционная оценка стоимости т.к. данные заведомо не помещаются в памяти и общая стоимость больше зависит от числа обращений к диску нежели от числа просмотренных рёбер. А число дисковых операций — весьма субъективный фактор, зависимый от сложно формализуемой пригодности графа к хранению на диске в форме удобной для конкретного алгоритма. Кроме того, очень важным становится компактность — количество информации в расчете на ребро и вершину.
Под катом представлена обобщенная эвристика к алгоритму A*, полезная именно в свете практической пригодности на больших графах при ограниченных ресурсах, например, на мобилке.
Читать полностью »
Большинство разработчиков начинает знакомство с 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 приложений по следующим причинам:
Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).Читать полностью »