💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.
Software Architect
Схема разделения секрета Шамира
Предположим, вы решили всё время хранить ключ при себе, предоставляя доступ к хранилищу по мере необходимости. Но вы быстро поймёте, что такое решение на практике нормально не масштабируется, потому что всякий раз для открытия хранилища требуется ваше физическое присутствие. А как насчёт отпуска, которые вам обещали? Кроме того ещё более пугает вопрос: а что если вы потеряли единственный ключ?
С мыслью об отпуске вы решили сделать копию ключа и доверить её другому сотруднику. Однако вы понимаете, что это тоже не идеально. Удваивая количество ключей, вы также удвоили возможности кражи ключа.
Отчаявшись, вы уничтожаете дубликат и решаете разделить исходный ключ пополам. Теперь, вы думаете, два доверенных человека с фрагментами ключей должны физически присутствовать, чтобы собрать ключ и открыть хранилище. Это означает, что вору необходимо украсть два фрагмента, что вдвое труднее кражи одного ключа. Однако вскоре вы понимаете, что эта схема ненамного лучше, чем просто один ключ, потому что если кто-то потеряет половину ключа, полный ключ нельзя восстановить.
Типичные ошибки архитектора, или Как перестать бояться и полюбить RFC
Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.
Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами.
Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?
Знакомо? Нам тоже. Но мы смогли победить эти проблемы.
Под катом выжимка из главы и нашего выпуска, а также практический опыт Dodo Engineering, как правильно оформлять и хранить архитектурные решения.
Большой комок грязи
От переводчика: Статья Big Ball of Mud написана Брайаном Футе и Джозефом Йодером летом 1999 года. Она рассказывает о наиболее распространённых антипаттернах разработки ПО, причине их возникновения и развития. Несмотря на то, что с момента публикации прошло больше 18 лет, описанные проблемы никуда не пропали, так что большая часть написанного актуальна и по сей день. Это первая часть статьи из трёх, остальные я надеюсь выложить в ближайшее время.
Введение
В последние годы сразу несколько авторов [Garlan и Shaw, 1993] [Shaw, 1996] [Buschmann и другие, 1996] [Meszaros, 1997] представили паттерны, которые характеризуют архитектуру ПО высокого уровня, например, PIPELINE (конвейер) и LAYERED ARCHITECTURE (многоуровневая архитектура).
В идеальном мире все системы были бы образцом одного или более подобных шаблонов высокого уровня. Тем не менее, в реальной жизни все не так. Архитектура, которая на данный момент является доминирующий, до сегодняшнего дня ещё не обсуждалась. Речь идет о BIG BALL OF MUD или БОЛЬШОМ КОМКЕ ГРЯЗИ.
Как технологический радар помогает осознанному развитию корпоративной ИТ-экосистемы
Технологический радар – это удобный инструмент, который помогает компании управлять своей платформой разработки и технологической стратегией. Мы изучили радары наших партнеров и ведущих ИТ-компаний, собрали свой и теперь хотим поделиться выводами: как радар помогает бизнесу и куда движется рынок.
Архитектор в ИТ — он как философ. Все вопросы и решения может подвергнуть сомнению
Уважаемые читатели, эта статья будет для вас полезна, если:
• Вы являетесь действующим архитектором ИТ и вам необходима дискуссия с коллегами о роли архитектора;
• Вы хотите стать архитектором, но еще не осознали, кто это;
• С вами рядом работает архитектор, и вы не понимаете, чем он занимается;
• Вы не владеете английским, но давно хотели прочитать книгу западного автора по архитектуре;
• И в целом если вы интересующийся современными веяниями ИТ, а именно архитектура является популярным запросом от работодателей в виду растущих масштабов автоматизации.
Прогулка по офису
Офис «Легко» спроектирован и построен так, чтобы соответствовать меняющейся корпоративной культуре и современным подходам к работе – минимум иерархии и бюрократии, максимум командной работы, прозрачности и свободы коммуникации между сотрудниками.
Многим знакомы стандартные системы пропуска в офис, когда необходимо приложить идентификационную карту к считывающему устройству. Сотрудникам этого офиса попасть на рабочее место легче. На входе в офис можно не использовать пропуск благодаря системе EnterFace 3D, которая распознает лица за считанные секунды.
SQL ключи во всех подробностях
Прочитав шестьдесят четыре статьи, пролистав разделы пяти книг и задав кучу вопросов в IRC и StackOverflow, я (автор оригинальной статьи Joe «begriffs» Nelson), как мне кажется, собрал куски паззла воедино и теперь смогу примирить противников. Многие споры относительно ключей возникают, на самом деле, из-за неправильного понимания чужой точки зрения.
Содержание
- Что же такое «ключи»?
- Любопытный случай первичных ключей
- Выбор естественных ключей
- Искусственные ключи
- Суррогатные ключи
- Автоинкрементные BIGINT
- UUID
- Итоги и рекомендации
Давайте разделим проблему на части, а в конце соберём её снова. Для начала зададим вопрос – что же такое «ключ»?
B-tree
Введение
Деревья представляют собой структуры данных, в которых реализованы операции над динамическими множествами. Из таких операций хотелось бы выделить — поиск элемента, поиск минимального (максимального) элемента, вставка, удаление, переход к родителю, переход к ребенку. Таким образом, дерево может использоваться и как обыкновенный словарь, и как очередь с приоритетами.
Основные операции в деревьях выполняются за время пропорциональное его высоте. Сбалансированные деревья минимизируют свою высоту (к примеру, высота бинарного сбалансированного дерева с n узлами равна log n). Большинство знакомо с такими сбалансированными деревьями, как «красно-черное дерево», «AVL-дерево», «Декартово дерево», поэтому не будем углубляться.
В чем же проблема этих стандартных деревьев поиска? Рассмотрим огромную базу данных, представленную в виде одного из упомянутых деревьев. Очевидно, что мы не можем хранить всё это дерево в оперативной памяти => в ней храним лишь часть информации, остальное же хранится на стороннем носителе (допустим, на жестком диске, скорость доступа к которому гораздо медленнее). Такие деревья как красно-черное или Декартово будут требовать от нас log n обращений к стороннему носителю. При больших n это очень много. Как раз эту проблему и призваны решить B-деревья!
B-деревья также представляют собой сбалансированные деревья, поэтому время выполнения стандартных операций в них пропорционально высоте. Но, в отличие от остальных деревьев, они созданы специально для эффективной работы с дисковой памятью (в предыдущем примере – сторонним носителем), а точнее — они минимизируют обращения типа ввода-вывода.
Индексы в PostgreSQL — 1
Предисловие
В этой серии статей речь пойдет об индексах в PostgreSQL.
Любой вопрос можно рассматривать с разных точек зрения. Мы будем говорить о том, что должно интересовать прикладного разработчика, использующего СУБД: какие индексы существуют, почему в PostgreSQL их так много разных, и как их использовать для ускорения запросов. Пожалуй, тему можно было бы раскрыть и меньшим числом слов, но мы втайне надеемся на любознательного разработчика, которому также интересны и подробности внутреннего устройства, тем более, что понимание таких подробностей позволяет не только прислушиваться к чужому мнению, но и делать собственные выводы.
За скобками обсуждения останутся вопросы разработки новых типов индексов. Это требует знания языка Си и относится скорее к компетенции системного программиста, а не прикладного разработчика. По этой же причине мы практически не будем рассматривать программные интерфейсы, а остановимся только на том, что имеет значение для использования уже готовых к употреблению индексов.
В этой части мы поговорим про разделение сфер ответственности между общим механизмом индексирования, относящимся к ядру СУБД, и отдельными методами индексного доступа, которые в PostgreSQL можно добавлять как расширения. В следующей части мы рассмотрим интерфейс метода доступа и такие важные понятия, как классы и семейства операторов. После такого длинного, но необходимого введения мы подробно рассмотрим устройство и применение различных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.
Файловые дескрипторы в Greenplum
Привет, меня зовут Денис, в Arenadata я занимаюсь Greenplum — распределённой СУБД с открытым исходным кодом, разработанной на основе PostgreSQL и заточенной под аналитический профиль нагрузки. Моя работа (помимо разработки) заключается в разборе инцидентов, когда в кластерах клиентов происходит что-то непонятное для нашей технической поддержки. Такие истории обычно заканчиваются детальным внутренним разбором произошедшего, рекомендациями для клиентов и внесением правок в код Greenplum (как в наш fork, так и в upstream). Я расскажу вам про один из инцидентов, которым я занимался в последнее время. Хотя этот случай не привел к технически сложным доработкам, он является показательным примером того, как мы исследуем проблемы с Greenplum. Заодно я расскажу о подробностях внутреннего устройства Greenplum и PostgreSQL, которые не описаны в документации.
Проектируйте правильно
Проект это сложная история. Обычно это относительно сложное и длительное мероприятие, создать программный продукт и провести его через стадию активной разработки до первой реальной коммерческой эксплуатации. Лично я видел как этот путь, в среднем, занимал от 2 до 5 лет на проекте с большой командой разработчиков.
Фишка в том, что нужно обеспечить качество продукта. Нас за этим (как разработчиков) и нанимают на работу, чтобы мы правильно писали программные продукты и прикладывали усилия чтобы эффективно двигать продукт вперед. Но на выходе, причем иногда еще до реального большого релиза, продукт может обрасти таким количеством технического долга, что скорость разработки очень сильно падает, и кодовая база приобретает характеристики которые свойственны кодовым базам которые сложно поддерживать и развивать. И парадокс в том что все при этом действительно стараются сделать хороший программный продукт. То есть, как говорится, хотели как лучше, а получилось как всегда.
Под катом наблюдения и личные выводы почему это происходит.
Начало работы с нейронными сетями
В этой главе мы познакомимся с нейронными сетями и узнаем для чего они были спроектированы. Эта глава служит фундаментом для последующих глав, в то время как эта показывает базовые понятия нейронных сетей. В этой главе мы покроем следующие темы:
Бизнес-архитектура MUST HAVE
Бизнес-архитектура и ее место в компании
Простая истина: чем комфортнее и красивее город, тем более приятно и удобно в нем жить. Архитектура города – это не только архитектура конкретных зданий и сооружений, но и сама их совокупность, создающая пространственную среду для жизни и деятельности человека. И чем лучше структурировано пространство вокруг в части зданий, маршрутов, оказываемых услуг – тем нам удобнее.
Таким образом, архитектура в городе – это наука не только о строительстве и проектировании, но еще и о структурировании.
Также на предприятии. Бизнес‑архитектура – это целостная и интегрированная модель компании, которая связывает стратегические, структурные, технологические и информационныеаспекты. Она есть всегда и является частью корпоративной архитектуры.
Согласно методологии TOGAF, через бизнес-архитектуру происходит постановка бизнес-целей и управление ИТ-архитектурой. Она связывает стратегию и тактику, помогает лучше понять потребности в целом.
Идеальный каталог, оптимизация выборки данных
Введение
На очередном собеседовании меня спросили о недостатках модели данных EAV (Entity Attribute Value), я не нашёл что сказать, на мой взгляд это идеальный способ хранения произвольных данных. После короткого раздумья, я сказал что единственная проблема это невозможность построить индексы для выборок.
После собеседования я озадачился этим вопросом на несколько дней, пришёл к каким то выводам, для очистки совести чуть чуть погуглил. Нагуглил подтверждения своим мыслям, но этого мне было мало — захотелось реализации с подтверждением цифрами.
Если и вам интересно к каким выводам я пришёл и какой выигрыш от оптимизации можно получить, то добро пожаловать под кат.
Как оценить объем работ по миграции хранилища данных на Arenadata DB / Greenplum: методика и пример
Некоторое время назад многие российские компании, чей бизнес очень сильно завязан на обработке и анализе больших объемов данных (банки, ритейл, телеком) задумались о том, как можно уменьшить стоимость владения хранилищами данных, построенных на западных технологиях. События последнего времени только ускорили этот процесс. И сейчас количество компаний, для которых актуальна миграция существующих хранилищ данных, построенных на Oracle, MS SQL и других проприетарных СУБД, на решения открытого ПО и отечественных поставщиков, резко выросло, а СУБД GreenPlum фактически становится отраслевым стандартом в хранилищах данных.
При этом и компании-заказчику, и организации-исполнителю необходимо оценить бюджет проекта миграции. Первые обычно запрашивают подобную оценку у вторых.
Именно такую задачу поставил нам клиент – крупная торговая компания. После небольшого ознакомления с возможными методиками, выбор пал на метод COSMIC (Common Software Measurement International Consortium [1]), являющийся одной из разновидностей оценки функционального объема по функциональным точкам и выросший до стандарта ISO 19761. Плюсом в пользу СOSMIC стало разработанное консорциумом адаптированное руководство для оценки функционального объема хранилищ данных [2].
Каталог данных — почему без него непросто и как всё организовать с максимальной пользой
В этом посте мы расскажем, как организовали каталог данных в МКБ в текущих условиях — когда многие вендоры ушли, и по-настоящему рабочих вариантов осталось два: или пилить что-то самим с нуля, или обратиться к опенсорсным решениям.
Пилить самим — тут как всегда, это и дорого, и долго. Брать же готовую коробку и использовать ее вчистую тоже достаточно сложно, вы же не знаете наверняка и досконально, чего там и как на самом деле внутри работает.
Когда речь идет о корпоративных данных, это важно. К примеру, та же OpenMetadata — если не знать ее подкапотное устройство, работать с ней будет сложно. А разобраться сложно, потому что документация по ней на сегодня скудноватая, и экспертизы у людей на рынке еще не набралось, из-за чего до много приходится додумываться самим уже в процессе.
Под катом — немного о проблематике работы с данными (и о доверии), о плюсах, которые даст вам каталог данных, а также наша подробная инструкция для разворачивания каталога у себя.
Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры
Привет, Хабр!
Вы наверняка заметили тенденцию к усложнению программных систем: они становятся всё масштабнее и начинают состоять из множества отдельных компонентов. Внутри им как-то нужно взаимодействовать друг с другом, и способов для такой коммуникации придумано немало. Но особняком среди них стоят брокеры сообщений.
Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.
Очередь сообщений (Message Queue)
Очередь сообщений (Message Queue)
Этот пост рассказывает об очередях сообщений — почему вы должны знать о них, думать при планировании архитектуры и использовать их в вашем приложении.
Принципы работы СУБД. MVCC
В институте нас заставляли заучивать определение ACID и стоящие за ним свойства, но почему-то стороной обходились подробности реализации этой парадигмы. В данной статье я постараюсь частично заполнить этот пробел, рассказав о MVCC, которая используется в таких СУБД как Oracle, Postgres, MySQL, etc. и является весьма простой и наглядной.
Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Дата рождения
- Зарегистрирован
- Активность