В данной статье будет рассмотрен Service Layer в Magento 2 и сервисы (API интерфейсы) для управления сущностями, которые были описаны в предыдущей статье, посвященной проектированию и выделению доменных сущностей для системы управления складом (Inventory).
Читать полностью »
Привет! Предлагаю вашему вниманию свободный перевод статьи «Good code is its own best documentation» от Amit Shekhar.
Хороший код, как хорошая шутка — не требует объяснений.
Читать полностью »
Несмотря на то, что проблемы, связанные с дублированием кода, упоминаются довольно часто, актуальность этих проблем из года в год остается почти неизменной. Во многих популярных проектах количество клонов измеряется сотнями или даже тысячами.
В рамках данной статьи мне бы хотелось напомнить, что такое программные клоны, какие они влекут за собой проблемы и как с ними можно бороться. В статье приводятся примеры рефакторинга реальных клонов из популярного фреймворка Spring. В качестве инструментов используются Java 8, IDE IntelliJ IDEA 2017.1 и плагин Duplicate Detector 1.1.
Привет! Меня зовут Шелестов Денис. Программировать начал с 7-ми лет. В 16 лет, учась в 9-м классе, основал свой первый стартап – Всемирный рейтинг программистов, на котором сейчас зарегистрировано более 70-ти тысяч кодеров – и на первой же презентации перед инвестором привлек инвестиции. Также являюсь сооснователем еще нескольких интересных бизнесов.
Последние годы мы с командой занимаемся комплексной разработкой сайтов/сервисов/приложений, рекламой в гугле, яндексе, соц сетях и тд. Последние 2 года смотрели в сторону применения и постройки платформы на блокчейне и вот к чему наши поиски привели:
У меня дома есть ноутбук как и у Вас, который постоянно подключен к интернету и никогда почти не выключается. Как-то раз я пошел в душ, где задумался о том, что у меня в доме стоит ноутбук, который может хостить 10 сторонних сайтов одновременно. Почему? Потому что максимальная нагрузка на сторонние сайты клиентов была 500-700 в день. И тут меня еще больше осенило. Почти у каждого из нас есть либо полностью неиспользуемые (постоянно) устройства, либо используемые но не всю мощность устройства. Я сейчас говорю про миллионы компьютеров подключенных к сети и находящихся в онлайне. Почему бы не сделать такую систему, в которой серверами будут выступать компьютеры обычных людей?
У меня появилась такая идея — соединить компьютеры в единую сеть, где простые пользователи сдают в аренду мощность (и интернет) своих устройств, а кто-то кому это мощность нужна — берут в аренду нужное количество устройств. Получается, нужен какой-то продукт который будет использовать компы людей вместо серверов.
И в первую очередь я подумал — децентрализованный хостингЧитать полностью »
Одним из принципов объектно-ориентированного проектирования является программирование на уровне интерфейса, а не на уровне реализации. Видимо, из-за того что код в книгах и статьях по проектированию представлен преимущественно на Java, программисты на других языках, особенно с динамической типизацией, испытывают трудности с переносом знаний из этих книг и статей на свой рабочий язык программирования.
Часто сложность в понимании принципа "программируйте на уровне интерфейса" кроется в концентрации на инструменте, а не на смысле. Из-за наличия в Java ключевого слова interface, происходит искажение понимания принципа, и он превращается в "программируйте, используя interface". Так как в Python инструмент в виде ключевого слова interface отсутствует, некоторые питонисты пропускают этот принцип.
В книге Банды Четырех примеры приводятся на Smalltalk и C++. Оба этих языка не имеют ключевого слова interface, но это не мешает авторам применять принцип, используя имеющиеся в распоряжении конструкции языка:
У манипулирования объектами строго через интерфейс абстрактного класса есть два преимущества:
- клиенту не нужно иметь информации о конкретных типах объектов, которыми он пользуется, при условии, что все они имеют ожидаемый клиентом интерфейс;
- клиенту необязательно "знать" о классах, с помощью которых реализованы объекты. Клиенту известно только об абстрактном классе (или классах), определяющих интерфейс.
Данные преимущества настолько существенно уменьшают число зависимостей между подсистемами, что можно даже сформулировать принцип объектно-ориентированного проектирования для повторного использования: программируйте в соостветствии с интерфейсом, а не с реализацией.
Но даже приведенные в цитате преимущества не являются единственными, если посмотреть на принцип под более широким углом.
Вашему вниманию предлагается перевод статьи Рэймонда Чена из блога The Old New Thing, посвященной проблемам кода, полагающегося на порядок вычисления выражений — и всем тем, кто пишет foo(i++, a[i]);
Порядок вычисления выражений определяется конкретной реализацией, за исключением случаев, когда язык гарантирует определенный порядок вычислений. Если же в дополнение к результату вычисление выражения вызывает изменения в среде выполнения, то говорят, что данное выражение имеет побочные эффекты.
MSDN
В нашей внутренней рассылке про C# регулярно возникает дискуссионный вопрос, который касается корректной интерпретации подобных конструкций:
a -= a *= a;
p[x++] = ++x;
В ответ я спрашиваю:
Да кто вообще пишет такой код с невозмутимым видом? Одно дело, когда такое пишешь, пытаясь победить в «Международном Конкурсе запутывания кода на Си» (IOCCC, International Obfuscated C Code Contest), или если хочешь написать головоломку — но в обоих случаях понимаешь, что ты занимаешься чем-то нестандартным. Что, реально есть кто-то, кто пишет a -= a *= a и p[x++] = ++x; и думает про себя «Чёрт возьми, да я пишу действительно классный код!»
Перенос функциональности сайта, интернет-магазина или портала в мобильное приложение имеет ряд преимуществ как для владельца онлайн-сервиса, так и для его клиентов. Владелец получает дополнительный канал связи со своей целевой аудиторией и возможность персонализировать рекламные объявления, а пользователь – более удобный интерфейс, дополнительный функционал и возможность получения своевременных оповещений.
О том, какие принципы и инструменты мы используем для добавления REST API к проектам, читайте под катом.
Читать полностью »
Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.
Основная наша задача в проектировании, как это понятно из названия статьи, добиться разделения интерфейсов на Query и Command, чтобы впоследствии разделить бизнес сценарии на те, которые будут читать данные (Query интерфейсы) и на те, которые будут изменять данные (Command интерфейсы). А также обеспечить минимальное время ожидание (latency) на обновление данных, доступных через Query, после того как мы изменили данные через Command.
Читать полностью »
Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип "poka-yoke".