За последний год мы перенесли внушительную часть настроек DirectCRM в базу данных. Множество элементов промо-кампаний, которые мы до этого описывали исключительно кодом, теперь создаются и настраиваются менеджером через админку. При этом получилась очень сложная структура БД, насчитывающая десятки таблиц.
Однако, за перенос настроек в базу данных пришлось расплачиваться. Об архитектуре, позволяющий кэшировать редко меняющиеся Linq to SQL сущности, смотрите под катом.
Читать полностью »
Примечание автора: это перевод статьи Боба Мартина.
На написание этой статьи меня вдохновила статья Марка Симана (@ploeh). Статья Марка кратко и хорошо изложена. Пожалуйста, прочитайте сначала её, прежде чем продолжать читать данную.
Ловушка, о которой рассказывает Марк, это частный случай более общей ловушки, которую я называю воровством золота. Я могу продемонстрировать эту ловушку, возвращаясь обратно к статье Марка.
Заметьте, что первый тест, который написал Марк выглядел следующим образом:
[InlineData("Seven Lions Polarized" , "LIONS POLARIZED SEVEN" )]
[InlineData("seven lions polarized" , "LIONS POLARIZED SEVEN" )]
[InlineData("Polarized seven lions" , "LIONS POLARIZED SEVEN" )]
[InlineData("Au5 Crystal Mathematics", "AU5 CRYSTAL MATHEMATICS")]
[InlineData("crystal mathematics au5", "AU5 CRYSTAL MATHEMATICS")]
Он уже попал в ловушку. Почему? Потому что он уже украл золото.
Читать полностью »
Описываемая проблема в статье давно и хорошо известна, поэтому она по большей части для новичков, которые не знакомы с темой.
В ПО, которое разрабатывает наша команда используются денежные значения в рублях и копейках. Мы изначально знали, что использование примитивов для выражения денежных значений — это антипаттерн. Однако по мере разработки приложения мы всё никак не могли наткнуться на проблемы связанные с использованием примитивов, нам, видимо, везло и всё было нормально. До поры до времени.
Мы совсем забыли про эту проблему и использование примитивов типа int и decimal расползлось по всей системе. И теперь, когда мы написали первый метод, в котором прочувствовали проблему, пришлось вспомнить про это технический долг и переписать всё на использование денежной абстракции вместо примитивов.
Читать полностью »
В Caché есть несколько различных способов пройтись по коллекции и выполнить какие-нибудь действия с ее элементами. Самым простым является while-цикл. Такой способ позволяет решить поставленную задачу в императивном стиле. Разработчику приходиться явно заботиться об итераторе, о переходе к следующему элементу и о проверке выхода за пределы коллекции.
Но разве это то, о чем должен заботиться разработчик?! Разработчик должен решать поставленную перед ним задачу, за максимально короткое время с максимально хорошим качеством кода. Было бы очень здорово просто взять коллекцию и применить к ней функцию, которая выполняет необходимые действия на каждом элементе этой коллекции. Не проверять границ, не создавать итератор, не вызывать вручную функцию на каждом элементе. Такой способ решения задач называется декларативным программированием.
Declarative programming is when you write your code in such a way that it describes what you want to do, and not how you want to do it.
(c) 1800-information
Давайте подумаем, как же решить поставленную задачу декларативно, используя средства и возможности Caché.Читать полностью »
Последнее время в Email-маркетинге все чаще используются автоматические рассылки определенным группам потребителей. Типичные задачи:
В этой статье мы расскажем, как мы решали эту задачу — от написания каждой отдельной рассылки разработчиком с нуля 3 года назад, до заведения рассылок менеджером через веб-интерфейс в настоящее время. Рассказ может быть интересен не только тем, кто занимается Email-маркетингом но и вообще всем, кому приходится реализовывать периодическое выполнение сложных операций над определенными выборками потребителей (знаю, что звучит очень абстрактно, но в итоге именно такую абстрактную задачу нам и пришлось решить).
Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.
Привет!
Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI.
Добро пожаловать!Читать полностью »
Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».
Нонсенс.
Возможно, это спорный вывод, но я твердо уверен, нет места для legacy-кода в современных системах. Скажу несколько слов, прежде чем вы начнете точить свои вилы и зажжете факелы. Я имею ввиду, что не должно быть ни малейшего повода поддерживать старый функционал, вы добавляете обновления задним числом к старой версии только потому, что некоторые люди все еще используют ее. Даже если этих людей большинство — не делайте так.
Читать полностью »
Наименование: Functional Decomposition (функциональная декомпозиция)
Другие наименования: No Object-Oriented AntiPattern «No OO»
Масштаб: приложение
Рефакторинг: объектно-ориентированный реинжиниринг
Функциональная декомпозиция — хорошая практика процедурного программирования, так как она позволяет разделить приложение на отдельные функциональные модули.
К сожалению функциональную декомпозицию невозможно напрямую отразить в иерархии классов и поэтому иногда возникают проблемы, описываемые в статье.
Читать полностью »
Сегодня немного лирики: как мы решаем, что попадает в базовый функционал решения, а что нет.
Тему настоящего текста дала известная (на хабре) статья про 1С, освещавшая помимо прочего, подход уважаемой корпорации к развитию функционала коробочных конфигураций.
Нашу платформу объединяет с 1С концепция монолита (в противовес модульной схеме некоторых коллег, что на слуху), а вот подход к композиции базовой конфигурации у нас по сравнению с 1С совершенно противоположный.
Читать полностью »
В статье описываются возможные проблемы, которые могут возникнуть при модификации повторно используемых компонентов. Также приводятся рекомендации, как эти проблемы избежать. Перевод является вторым в серии (один антипаттерн — одна статья), ссылка на первый перевод находится в конце статьи.
Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)
Антипаттерн «тупик» получается в результате модификации повторно используемых компонентов, если компонент больше не поддерживается и не сопровождается его поставщиком. После внесения изменений в компонент, бремя его сопровождения перекладывается на разработчиков прикладной системы. Улучшения в повторно используемом компоненте не могут быть легко интегрированы а сделанные изменения могут стать причиной проблем при его поддержке.
Читать полностью »