Рубрика «Анализ и проектирование систем» - 123

В наши дни NoSQL продолжает набирать популярность, но мало кто знает, что нереляционные СУБД появились гораздо раньше даже самой реляционной алгебры. 40 и даже 50 лет назад в первичном «бульоне» зарождающейся IT индустрии «варились» только NoSQL-продукты. И что самое интересное – продукты, рожденные в те сложные времена, живы до сих пор и прекрасно себя чувствуют.
Одним из таких продуктов стала СУБД GT.m, разработанная компанией Graystone Tehnologies в 70-80-х годах прошлого века. СУБД нашла широкое применение в медицине, страховании и банковской сфере.

В нашем банке мы тоже используем GT.m, и этот инструмент прекрасно справляется с обработкой большого количества транзакций. Но… Есть одна проблема: GT.m никакой для аналитики, в нем нет SQL, аналитических запросов и всего того, что делает финансового аналитика счастливым. Поэтому мы разработали собственный «велосипед» для репликации данных из GT.m в «реляционные» СУБД.

Как мы NoSQL в «реляционку» реплицировали - 1
А вот здесь должна была быть картинка с летающим велосипедом

Всех заинтересованных приглашаем под кат.
Читать полностью »

Переход от монолита к микросервисам - 1

Каждый более-менее успешный продукт приходит к состоянию, когда добавлять новые возможности в существующую кодовую базу становится тяжело настолько, что стоимость новой функциональности превосходит все возможные выгоды от ее использования. Конечно же, хороший и внимательный архитектор позаботится о приложении заранее и направит разработку в правильное русло. Самый популярный на данный момент подход подразумевает распиливание одного большого куска кода на много мелких проектиков, каждый из которых отвечает за свои определенные возможности. При проектировании такой системы нависает огромная ответственность. Нужно продумать и разработать такой тип взаимодействия между этими отдельно лежащими кусочками, чтобы будущие внесения изменений не требовали переписать все к чертям.

Понятное дело, в сети существует огромное количество экспертных статей, которые показывают нам важность такой архитектуры и рассказывают о том какую архитектуру можно назвать хорошей, а какую не очень. Существует огромное количество методов взаимодействия между отдельными програмками большого приложения со своими протоколами, версионированием протокола и документации, написания документации на программные интерфейсы, способа развертывания и синхронизации всего этого добра вместе. Безусловно, каждая такая статья или метод логичен и последователен и особенно, если описанный метод подтвержден на практике. Но беда не в том, что проектировщики не знают какую систему они хотят в итоге получить. Беда в том, как перейти к такой вот правильной архитектуре и когда же можно прекратить писать монолитное приложение и начать уже писать взрослые микросервисы, чтобы перед пацанами не было стыдно. Читать полностью »

Подготовка релиза картографических данных включают в себя запуск массовой обработки данных. Некоторые задачи хорошо ложатся на идеологию Map-Reduce. В этом случае задача инфраструктуры традиционно решается использованием Hadoop или YT

В реальности часть задач таковы, что разбиение их на маленькие подзадачи невозможно, или нецелесообразно (из-за наличия существующего решения и дорогой разработки, например). Для этого мы в Яндекс.Картах разработали и используем свою систему планирования и выполнения взаимосвязанных задач. Одним из элементов такой системы является планировщик, запускающий задачи на кластере с учетом доступных ресурсов.
Workflow Graph

Эта статья о том как мы решили эту задачу с использованием Apache Mesos.

Читать полностью »

Многие языки программирования включают в себя избыточные возможности. Развитие языка включает в себя работу по их исключению.

Существует много языков программирования, и новые продолжают появляться всё время. Лучше ли они тех, что уже существовали раньше? Очевидно, что на этот вопрос невозможно ответить, пока не будет дано чёткое определение что же такое «лучше» в отношении языков программирования.

Если вы посмотрите на исторические тренды, то заметите один из путей сделать лучший язык программирования — определить какую-нибудь избыточную возможность в уже существующем языке и спроектировать новый язык без неё.

«Совершенство достигается не тогда, когда нечего добавить, а тогда, когда нечего убрать»

Антуан де Сент-Экзюпери

В этой статье вы увидите несколько примеров возможностей различных языков программирования, которые уже общепризнанны избыточными и ещё несколько других, которые имеют те же черты и могут когда-нибудь быть отнесены к той же группе.
Читать полностью »

Наши центры разработки по стране с «телепортами» до любого города - 1
Типовое рабочее место: два монитора, дорожный ноутбук, лампа, интернет

У нас очень много работы в разработке, и далеко не вся она требует присутствия в Москве, и далеко не всех разработчиков можно легко найти в столице. Поэтому принцип довольно простой: находим разработчиков в городе, где им приятно жить, снимаем там хороший и удобно расположенный офис и просто присылаем задачи. Связь по сети, еда в ближайшем ресторане по абонементу. И все счастливы. Мы — тем, что получаем «головы», которых нет в Москве, по ценам города (разница с Москвой вполне окупает аренду офиса), а разработчики могут работать у себя и путешествовать по стране.

Наши центры разработки по стране с «телепортами» до любого города - 2
Тестировщик в Иркутске

«Телепорты» сделаны так: можно поехать в любой другой такой же центр разработки на 4 недели на пробу поработать там. С сохранением зарплаты, и ещё гостиница и питание — за счёт компании. Если «порт приписки» Москва, то, перемещаясь в другой офис, надо ещё обязательно прочитать семинар.

Проекты, над которыми работают распределённо по стране, — от автоматизации АЭС до разного прикладного софта «Ленты», Мосгорсуда, Росстата и так далее.

Всего у нас сейчас 7 таких центров — от маленького офиса на 5 человек в бизнес-центре до большой региональной команды из 30 разработчиков и тестировщиков. Но, конечно, исторически пока больше всего разработчиков и тестировщиков в Москве — около 250 человек (это один из самых больших отделов в КРОК). Однако скоро процент работающих в других городах грозит приблизиться к половине. География довольно обширная: Москва (включая отдельный небольшой офис в Троицке), Петербург, Нижний Новгород, Самара, Иркутск, Пермь, Краснодар.Читать полностью »

Нормальное взаимодействие участников Netflix обеспечивается архитектурой микросервисов и привязано персонально к каждому из наших более чем 80 миллионов участников. Сервисы принадлежат разным командам (группам), каждая из которых имеет свой собственный цикл разработки и релиза. Это означает, что необходимо иметь постоянно действующую и компетентную группу тестирования интеграции, обеспечивающую выполнение сквозных стандартов качества в ситуации, когда микросервисы вводятся в действие каждый день децентрализованно.

В качестве группы тестирования интеграции разрабатываемых продуктов мы обязаны не снижать скорость введения нового, обеспечивая в то же время контроль качества и быструю обратную связь для разработчиков. Каждая группа разработчиков отвечает за качество поставляемого ею продукта. Нашей задачей является бесперебойная работа с различными техническими группами с упором на сквозную функциональность и координацию деятельности групп. Мы представляем собой небольшую группу специалистов по тестированию интеграции в организации, насчитывающей более 200 разработчиков.

Быстрый ввод новых разработок при необходимости обеспечении требуемого качества создаёт интересные задачи для нашей команды. В настоящей статье мы рассмотрим три такие задачи:

1. Тестирование и мониторинг высокорейтинговых показов (High Impact Title = HIT = хит)
2. A/B-тестирование
3. Глобальный запуск
Читать полностью »

Привет! В связи со своей реальной задачей проанализировать возможности Qt и .NET для реализации так называемых «Назад» (Undo) и «Вперёд» (Redo), цель которых отменить действие и отменить отмену соответственно, я решил все свои мысли, идеи и задумки развернуть в этой статье, даже если они будут частично или совсем неверными (поэтому по возможности и интересу пишите в комментарии свои замечания). Хоть и на просторах Интернета спокойно можно найти хорошие (и не очень) библиотеки и примеры реализаций, более общего представления на эти вещи я нашёл не так скоро, да и то, только в ответе на StackOverflow, а этого было мне не достаточно. Во всём найденном есть моменты, которые меня порадовали, есть и которые огорчили. Пожалуй, стоит отменить все печали и радости… чтобы к ним снова вернуться… «Назад… в будущее»!

Undo и Redo — анализ и реализации - 1

Интересно? Добро пожаловать!
Читать полностью »

Несколько вещей гарантированно будут увеличиваться со временем: расстояния между звёздами, энтропия вселенной и бизнес-требования к ПО. Многие статьи пишут «Не усложняйте!», но не пишут почему или как это сделать. Вот вам 10 ясных примеров.

1. Инженерам виднее

Мы, инженеры, считаем себя умнейшими людьми. Ну, поскольку мы создаём разные штуки. И эта ошибка часто приводит к оверинжинирингу. Если вы спланировали и построили 100 модулей — Бизнес всегда попросит у вас 101-ый, о котором вы никогда не задумывались. Если вы соберётесь с силами и решите 1000 проблем — они придут к вам и выложат на стол 10 000 новых. Вы считаете, что у вас всё под контролем, а на самом деле вы даже не представляете, в каком направлении вас завтра поведёт дорога.
image
За мои 15 лет работы программистом я ещё ни разу не видел, чтобы Бизнес выдал законченные и стабильные раз и навсегда требования к ПО. Они всегда меняются, расширяются. И это природа бизнеса, а не ошибки людей, управляющих им.

Мораль: Казино (бизнес) всегда побеждает
Читать полностью »

Снижение задержек, увеличение объёма торгов и новые платформы: главные технологические тренды в развитии мировых бирж - 1

Крупнейшие фондовые биржи мира находятся в состоянии жесточайшей конкуренции и слишком сильно зависят от интересов инвесторов, ожидающих постоянного роста прибыли. В результате, биржи вынуждены искать нестандартные маркетинговые решения и способы «выделиться» среди конкурентов. Аудиторская компания Ernst & Young проанализировала стратегию ведущих фондовых бирж мира и выяснила, что помогает им развиваться.Читать полностью »

Вот уже полтора года в Яндексе для совершенствования поисковых алгоритмов и технологий машинного интеллекта применяется платформа Толока. Может показаться удивительным, но все современные технологии машинного обучения в той или иной степени нуждаются в человеческих оценках.

Люди оценивают релевантность эталонных документов поисковым запросам, чтобы на них ориентировались формулы ранжирования в поиске; люди переписывают аудиозаписи в текст, чтобы на этих данных настроился алгоритм голосового распознавания; люди размечают изображения по категориям, чтобы, натренировавшись на этих примерах, нейронная сеть дальше делала это без людей и лучше людей.

Яндекс.Толока. Как люди помогают обучать машинный интеллект - 1

Все это можно делать в Толоке, которая является краудсорсинговой платформой и помогает найти тех, кто решит вашу задачу. Сегодня она переходит в статус беты и отныне открыта для всех внешних заказчиков. Так что пришло время рассказать вам подробно о самой платформе и о том, с какими неожиданными сложностями мы сталкивались в процессе работы над ней, поделимся своими наблюдениями и объясним, как Толока может помочь именно вам.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js