При проектировании системы знание анти-паттернов и подвохов зачастую оказывается более полезным, чем знание самих паттернов. Отталкиваясь от этой идеи, я решил написать данную статью, чтобы рассказать о факторах, которые, на мой взгляд, приведут к созданию ненадёжных систем. В её основе лежит мой собственный опыт проектирования преимущественно распределённых корпоративных приложений. Будет здорово, если ниже вы поделитесь собственным опытом и полезными идеями по теме. Читать полностью »
Я устал от одержимости примитивами и от чрезмерного использования примитивных типов для моделирования функциональной области.
Значение в string не лучший тип для записи адреса электронной почты или страны проживания пользователя. Эти значения заслуживают гораздо более богатых и специализированных типов. Мне нужно, чтобы существовал тип данных EmailAddress, который не может быть null. Мне нужна единая точка входа для создания нового объекта этого типа. Он должен валидироваться и нормализироваться перед возвратом нового значения. Мне нужно, чтобы этот тип данных имел полезные методы наподобие .Domain() или .NonAliasValue(), которые бы возвращали для введённого foo+bar@gmail.com значения gmail.com и foo@gmail.com. Эта полезная функциональность должна быть встроена в эти типы. Это обеспечивает безопасность, помогает предотвращать баги и существенно повышает удобство поддержки.
Читать полностью »
Вот уже 7 лет мы развиваем Okdesk — облачную help desk систему для малого и среднего бизнеса.
В свое время мы начали с одной виртуальной машины у провайдера.
Постепенно сервис взрослел, менялись приоритеты, задачи и проблемы, с которыми мы сталкивались. Сегодня Okdesk живет уже на третьей версии инфраструктуры.
В этой заметке мы расскажем о том, как и почему эволюционировала архитектура Okdesk. А во второй части поста — почему мы перешли на Kubernetes, каких результатов это позволило добиться и что планируем делать дальше.
Привет! Меня зовут Валид Панин, хочу поделиться кратким чек-листом скилов аналитика. Расскажу какие харды и соф-скилы использую в своей работе с примерами, пояснениями и списком литературы и ресурсов, которые помогут подтянуть знания. Мне бы пригодился такой чек-лист как карта развития, если бы я сейчас начинал свой путь аналитиком.
В подавляющем большинстве случаев, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.
Материал является продолжением серии предыдущих публикаций.
Читать полностью »
Подход governance as a code обеспечивает контроль соблюдения архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Правила проверки каждого артефакта, будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD, описаны специальным кодом проверки правил, имеют свой жизненный цикл, могут тестироваться и ничем не отличаются от обычного программного продукта.
Александр Токарев (Сбербанк) расскажет, как и что можно проверять в процессе разработки программного обеспечения, чтобы разрабатывать более безопасные и качественные приложения, и почему Сбербанк решил не использовать такие очевидные решения как SonarQube, а разработать собственное решение на базе Open Policy Agent без дополнительных пакетов над ним. Также Александр покажет, когда выбирать admission controller, когда использовать «чистый» Open Policy Agent, а когда можно обойтись без какого-либо контроля.
Александр поговорит о том, нужны ли стандарты, что такое язык Rego и что за крутой продукт Open Policy Agent, а также рассмотрит нетиповые кейсы его применения, как с ним работать, и как его использовать для контроля. Email Александра.
Добрый день! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ и сжать в короткие рекомендации и выводы.
Про принцип единственной ответственности (The Single Responsibility Principle, SRP) уже было написано множество статей. В большинстве из них даётся лишь поверхностное его описание мало чем отличающееся от информации в википедии. А те немногие статьи что затрагивают ключевые особенности SRP делают это вскользь, не акцентируя на них внимания и не развивая тему дальше.
Эта статья — попытка дать более глубокое объяснение принципу единственной ответственности, а также показать как его всё таки можно применять на практике. Кому интересно — добро пожаловать под кат.Читать полностью »
От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост чтобы быть правильным.
Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.
Сразу извиняюсь за возможные неточности в русскоязычных финансовых терминах — я все-таки программист, а не бухгалтер, и с русской терминологией в этой сфере недостаточно знаком.
Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".
Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи
В системе с "простой записью" числовые значения записываются только один раз. В системе с "двойной записью" каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.
Основные правила таковы:
