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

В то же время с ростом навыков увеличивается и сложность задач. Сначала они достаточно простые, в них из постановки ясно, что нужно сделать. Далее становится сложнее. Одного названия задачи недостаточно, чтобы понять, что требуется. На помощь обычно приходит более опытный член команды, который сможет объяснить, что к чему. 

В какой-то момент «бывший стажер» сам становится этим самым членом команды. Прорабатывать требования и решение задачи теперь необходимо самому. И тут начинают возникать следующие вопросы:

1. Как понять, что твоё решение действительно оптимальное?

2. Как объяснить другим своё решение?

3. Как сохранить описание и алгоритм работы решения для дальнейшего возможного переиспользования?

На все эти вопросы призван ответить проект фичи: описание решения задачи без подробностей реализации. Я расскажу про свой опыт решения задач с таким подходом и как это отражалось на работе нашей команды.

Как это было принято в нашей команде? 

• Решения о необходимости проектирования задачи обсуждалось заранее, на этапе планирования спринта. 

• Проект являлся полноценной отдельной задачей, требующей оценки. 

• Проект, как и обычная задача, проходил рецензирование. К проверке подключались наиболее компетентные в проекте коллеги: senior, тимлиды и архитекторы команды (если таковые есть).

• Документирование велось в Atlassian Confluence, там есть широкий спектр подходящих инструментов и макросов.

• Понимать задачу через проект гораздо проще, чем через реализацию. В то же время, многотомные проекты — тоже не лучший вариант. Задачи делились настолько мелко, чтобы проект не усложнял их, а, наоборот, дополнял и упрощал понимание. 

Инструменты для описания

Обычное текстовое описание

Самым простым способом описания вашего решения, безусловно, является текст. С его помощью можно достаточно просто и быстро набросать общие концепции решения, а также основные этапы алгоритма работы: нужно просто по пунктам перечислить то, что требуется сделать. Важно отметить, что сам проект, за некоторым исключением, практически не содержит кода. Он нужен для того, чтобы дать общее понимание решения, не вдаваясь глубоко в реализацию.

Фрагменты кода

Если всё-таки требуется уточнить какую-то подробность кода реализации, которая, например, не является очевидной, то можно воспользоваться фрагментами кода. В них, например, можно вложить заранее подготовленный SQL-запрос, или подчеркнуть особенности реализации на конкретной платформе

UML-диаграмма классов

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

• Описание отношений между сущностями в БД.

• Проецирование паттернов проектирования в конкретном случае.

UML достаточно удобно рисовать в https://draw.io. Там есть нужный набор блоков и разные стрелки для отображения зависимостей.

Sequence-диаграмма

Теперь ясно, как отображать отношения между классами. Но как они друг с другом взаимодействуют иногда все же остается загадкой. На подобные вопросы хорошо помогает ответить sequence‑диаграмма — она отображает последовательности вызовов разных компонентов (синхронно или асинхронно). 

Могу порекомендовать https://sequencediagram.org/. Сервис позволяет в текстовом формате отобразить sequence-диаграмму, есть много возможностей.

Блок-схема

А что делать с описанием сложных алгоритмов? Диаграмма классов не способна отображать последовательности шагов, а sequence-диаграмма больше подходит для отображения взаимодействий разных компонентов. При попытке отобразить в этом формате шаги сложного алгоритма получится каша.

В этом случае сдуваем пыль со старого, но проверенного способа — блок‑схемы алгоритмов. Такое отображение в простом формате «кубиков», «ромбиков» и «стрелок» легко раскладывает сложный алгоритм на шаги. Реализовывать его по такой схеме становится проще простого. Также могу порекомендовать использовать https://draw.io.

Визуальный стиль и разграничения

Даже если воспользоваться всеми инструментами для описания, максимально перенести текст в картинки для упрощения, то проект всё равно иногда остаётся сложным для понимания. И дело может быть в том, что в материале отсутствует структура как таковая: информация перемешана, отсутствует последовательность повествования. За этим тоже стоит следить — начинать с мелких, несвязанных вещей, чтобы позже объединить их в единое целое. Идти от частного к общему. 

Как принести такой подход в команду?

Такой подход к решению комплексных задач нравится и подходит далеко не всем командам. В то же время, я бы рекомендовал в качестве эксперимента попробовать применить этот инструмент на какой‑нибудь неприоритетной задаче и позволить команде взвесить все «за» и «против». По собственному опыту могу выделить следующие преимущества и недостатки подхода:

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

• Экономия времени во время реализации. Если на задачу имеется подготовленное, заранее описанное и согласованное решение, то автору реализации нет необходимости верхнеуровнево оценивать возможные пути реализации, за него это уже сделано. Остаётся только идти по «протоптанной тропинке» и решать задачу на уровне реализации в коде.

• Экономия времени после реализации. Например, во время ревью пулл-реквеста, у ревьюера есть возможность оценить не только стилистическое соответствие кода стандартам команды, но и проверить непосредственно логику работы. Для этого нужно обратиться к проекту и просто сверить, соответствует ли ему код.

• В оценку фичи необходимо закладывать написание проекта. Есть команды, и их большинство на рынке, в которых разработка ведётся достаточно быстро и чисто физически нет времени заниматься подобными задачами. 

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

• Требуется время на то, чтобы команда свыклась с таким подходом. Если она не очень гибкая с точки зрения внедрения новых практик, или этот инструмент не всем по душе, то полноценная его интеграция в рабочий процесс становится под вопросом.

Как рецензировать проект?

Во время рецензирования проекта стоит уделить внимание следующим вещам:

1. Проект в полной мере выполняет то, что поставлено в задаче? Этот пункт имеет самый высокий приоритет. Насколько бы крутое решение вы не придумали, если оно не отвечает поставленным требованиям — оно не подходит. В первую очередь необходимо делать упор на то, чтобы решение удовлетворяло всем функциональным требованиям, которые к нему предъявлены.

2. Проект оптимально решает задачу? Важно, чтобы описанное решение было достаточно эффективным, чтобы справляться с нагрузкой, то есть удовлетворяло всем нефункциональным требованиям. Помните о граничных случаях, которые также необходимо предусмотреть!

3. Проект написан понятным языком? Стоит уделить внимание тому, чтобы формулировки в проекте были ясными и однозначными. Чем лучше в этом плане описано решение, тем качественнее и точнее получится реализация и тем меньше ошибок придётся править в будущем. 

Пример проекта

Вот пример проекта задачи по отправке уведомлений в сервисе.

Заключение

Я постарался подробно рассказать про опыт проектирования технических задач в моей команде. Такой подход имеет свои достоинства и недостатки. Непосредственно результат зависит от вовлечённости и инициативы каждого члена команды.

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

А какой у вас подход к выполнению нетривиальных и крупных задач? Пожалуйста, расскажите о нём в комментариях!

Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM

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

Преобразование Хафа — это алгоритм, используемый для поиска геометрических фигур на изображении. На основе искомой формы выбирается определенное количество параметров. Эти параметры необходимы для определения формы. Скажем, для прямой линии y=mx+c у нас есть два параметра. Мы также можем написать линию в форме полярных координат, где два параметра — ро и тета.

Затем находим значения параметров для каждого пикселя. Для конкретной прямой должна быть уникальная пара параметров. Таким образом, все точки на этой линии будут иметь одну и ту же пару параметров.

Так мы голосуем за каждую пару параметров, полученных из пикселей изображения. Пара с наибольшим количеством голосов соответствует прямой линии. Если на изображении несколько линий, скажем, 10, мы считаем, что 10 точек, получивших наибольшее количество голосов, представляют эти линии. Затем эти линии строятся с использованием параметров.

Давайте создадим файл Python, с которым мы будем работать:

touch hough_transform.py

Посмотрим на преобразование Хафа для прямой линии. Для импорта библиотек и входного изображения:

import numpy as np import cv2 img = cv2.imread('sudoku.jpg') filtered= cv2.bilateralFilter(img,9,75,75)

Изображение, которое мы импортируем

Вызовем детектор границ Canny и функции HoughLines:

edges = cv2.Canny(filtered,50,200,apertureSize = 3) lines = cv2.HoughLines(edges,1,np.pi/180,200)

Для вывода найденных строк, если они есть:

for i in range(len(lines[:,0,0])): for rho,theta in lines[i]:     a = np.cos(theta)     b = np.sin(theta)     x0 = a*rho     y0 = b*rho     x1 = int(x0 + 1000*(-b))     y1 = int(y0 + 1000*(a))     x2 = int(x0 - 1000*(-b))     y2 = int(y0 - 1000*(a))     cv2.line(img,(x1,y1),(x2,y2),(255,0,0),2) cv2.imwrite('hough.jpg',img)

Запустим код

python hough_transform.py

Мы получили файл hough.jpg, давайте взглянем на него

Преобразование Хафа — медленный алгоритм, потому что мы голосуем за каждый пиксель и учитываем все голоса для построения линии.

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

Это ускоряет вычисления в ситуациях, когда мы можем компенсировать некоторую точность для скорости.

Давайте посмотрим на вероятностное преобразование Хафа для нахождения прямых линий:

img = cv2.imread('sudoku.jpg') filtered= cv2.bilateralFilter(img,9,75,75) edges = cv2.Canny(filtered,50,200,apertureSize = 3)

Для определения параметров HoughLinesP и вызова HoughLinesP мы используем следующие строки кода:

MinLineLength = 100 MaxLineGap = 10 lines = cv2.HoughLinesP(edges,1,np.pi/180,100,MinLineLength,MaxLineGap)

Для вывода найденных строк, если они есть:

for i in range(len(lines[:,0,0])):     for x1,y1,x2,y2 in lines[i]:         cv2.line(img,(x1,y1),(x2,y2),(255,0,0),2)  cv2.imwrite('probab_hough.jpg',img)

Запустим: python hough_transform.py

У нас появится файл probab_hough.jpg

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

Функция HoughCircles в OpenCV имеет множество параметров, поэтому было бы целесообразно обратиться к значениям параметров из документации OpenCV.

Преобразование Хафа для кругов с использованием HoughCircles:

col_img= cv2.imread('circles.jpg') img = cv2.imread('circles.jpg',0) filtered= cv2.bilateralFilter(img,9,75,75)

Изображение, которое мы импортируем

Для вызова функции HoughCircles:

circles = cv2.HoughCircles(filtered,cv2.HOUGH_GRADIENT,1,20,param1=55,param2=40,minRadius=0,maxRadius=0) circles = np.uint16(np.around(circles))

Для вывода найденных кругов:

for i in circles[0,:]:     cv2.circle(col_img,(i[0],i[1]),i[2],(0,255,0),2)     #draws the circumference of the circle     cv2.circle(col_img,(i[0],i[1]),2,(0,0,255),3)     #draws the centre of the circle  cv2.imwrite('hough_circles.jpg',col_img)

Запустим код: python hough_transform.py 

И получим hough_circles.jpg:

Заключение

Мы научились определять прямые линии и окружности с помощью преобразования Хафа. Это одна из фундаментальных концепций компьютерного зрения.

В завершение расскажу пару слов об открытом уроке, посвященном диффузионным моделям, который пройдет 12 июля. На нем вы узнаете:

• По каким принципам строится любая диффузионная модель и как устроена популярная генеративная модель Stable Diffusion;

• Какие задачи можно решать с помощью модели Stable Diffusion.

Записаться на урок можно на странице курса «Компьютерное зрение».

Меня зовут Даниил Храповицкий, я iOS‑разработчик студии СleverPumpkin, и сегодня поговорим про xcstrings в Xcode 15.

Один из самых неприятных аспектов iOS‑разработки — это локализация и плюрализация строк. Мало того, что они разбиты на разные файлы: strings и stringsdict, так ещё и работа с этими файлами для начинающего разработчика может оказаться не сильно очевидной. «Что такое %#@⁠VARIABLE@?», «Как добавлять несколько плюралок в одну строку?», «Как использовать плюралки в локализованных строках?», «Как добавлять разные переводы для разных девайсов?» — Все эти вопросы рано или поздно возникают у разработчика. После получения ответов на них каждый задаётся вопросом: «А почему всё так плохо?»

У зелёных наших братьев дела обстоят получше — у них один файл для локализации. У нас же всё так непросто, потому что формат данных достался нам из Objective‑C, где какая‑то строгость и защита от дураков были не совсем обязательны (вы вообще видели Objective‑C?). Поэтому раньше в файлах локализации можно было:

• спокойно пропустить точку с запятой, о месте в коде которой Xcode стыдливо умолчит;

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

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

Однако всё изменилось с приходом Xcode 15, где локализация и плюрализация строк были значительно улучшены. Теперь там один файл xcstrings. Это каталог, который хранит в себе все ключи и строки как для переводов на другие языки, так и для переводов для множественного числа. Важно отметить, что всё это умеет бэкпортиться на старые версии iOS путём разбиения xcstrings на .strings и .stringsdict. То есть всё равно под капотом используется старый формат, но мы, как разработчики, работаем уже с удобным для нас интерфейсом.

При создании нового xcstrings‑каталога интерфейс будет выглядеть следующим образом:

Если мы выделим язык, то нам отобразится, что каталог пустой:

Попробуем добавить строку и посмотрим, что произойдёт. Создалась строка, для которой мы можем задать ключ, локализованную строку и коммент. Состояние будет автоматически меняться для отображения информации о состоянии перевода и актуальности данной записи:

Изменим строку:

Теперь добавим перевод на русский язык:

Будет отображено, что имеется одна новая строка:

Переведём её. После добавления перевода состояние изменится на ОК.

Добавим возможность передавать туда числа. Делается это следующим образом:

Однако теперь нам необходимо добавить плюрализацию для строки, чтобы она выглядела естественно. Делается это следующим образом:

Состояние поменялось на Needs review. Это говорит о том, что строка требует нашего внимания.

После локализации двух переменных получается следующее:

Вернувшись к русскому языку, мы увидим, что строки необходимо обновить.

Обновив, мы получим следующее:

Так происходит локализация и плюрализация. В коде это можно вызвать либо через старый‑добрый NSLocalizedString:

String(format: NSLocalizedString("File instead of Files", comment: ""), 1, 2)

Либо через новомодную структуру LocalizedStringResource, но для этого необходимо немного изменить ключ — добавить в него спецификаторы форматов аргументов (%d, %lld, %@ и так далее), которые используются в строке.

Однако если мы вызовем строку этим способом, то всё будет работать не так, как мы ожидали:

String(localized: "\(2) File instead of \(1) Files")  // 2 File instead of 1 Files

А всё потому, что %d в локализованной строке — это Int16. И как бы Swift ни умел в инициализацию через литерал, он не может знать, что, указывая 2 или 1, мы имеем в виду Int16, а не Int. Поэтому он не может замэтчить переданную строку с ключом.

После этого в дело вступает ещё один нюанс работы с каталогом строк. По умолчанию для каждой строки, которая не была сопоставлена с существующим ключом, Xcode создаст новый ключ. Работает это как для новой String(localized:), так и для уже повидавшей жизнь NSLocalizedString. Это может быть удобно, если не хочется самому напрямую работать с xcstrings файлом, создавая новые ключи и прописывая в них аргументы (хотя писать локализацию строк всё равно придётся):

Однако в случае с %d , если же мы явно укажем тип, тогда всё отработает как ожидается:

String(localized: "\(Int16(2)) File instead of \(Int16(1)) Files")  // 2 Files instead of 1 File

Чтобы этого избежать, нужно указывать тип %lld, который будет нормально парситься в Int.

В дополнение есть возможность создания строк перевода для конкретного типа девайса. Например, можно задать различные переводы для iPhone и остальных устройств:

Также из интересного стоит отметить, что теперь файлы вместо привычного xml имеют json формат, что очень неожиданно для Apple. А так как файл теперь один, то такие сервисы, как POEditor, смогут нормально генерировать строки для iOS‑проектов.

Вся эта прелесть поддерживается на всех версиях iOS, но, само собой, собранных с использованием Xcode 15. Магия в том, что при компиляции всё парсится в уже привычные strings и stringsdict файлы, и в бандле будут храниться именно они.

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

Привет! Меня зовут Роман Бунин, я BI-евангелист Yandex DataLens. При росте объёма данных, что неизбежно для любой компании, загрузка дашбордов может замедляться до десятков секунд. И чем больше появляется данных, тем медленнее становятся дашборды, особенно если вы хотите строить их по детализированным таблицам. Связка базы данных ClickHouse и BI-системы Yandex DataLens — популярное решение для анализа данных: эти инструменты нативно интегрируются и быстро работают вместе. В этой статье вместе с моими коллегами, архитекторами Yandex Cloud Игорем Путятиным и Кузьмой Лешаковым, покажем, как на основе таблицы из 150 миллионов строк построить максимально быстрый дашборд, и расскажем о технических ограничениях.

Зачем делать быстрые дашборды ещё быстрее: кейс Яндекс Go

Внутри Яндекса мы сами используем дашборды и продуктовые подходы к созданию системы отчётности. Поэтому регулярно опрашиваем коллег, что важно для них при работе с дашбордами. Опрос команды Яндекс Go показал, что самое узкое место этого инструмента — быстродействие. 

В 2022 году команда Go перешла на Yandex DataLens. Раньше ребята использовали Tableau, у инструмента есть своя проприетарная база данных Hyper, но она не позволяла добиться быстродействия, которое устраивало бы пользователей. 

DataLens использует асинхронный способ отрисовки и загрузки графиков и нативно подключается к ClickHouse, что позволило команде Go добиться ускорения основной отчётности.

Сначала команда перенесла данные из своего внутреннего хранилища YT (аналог вышедшего недавно в опенсорс YTsaurus) в ClickHouse. Это позволило задействовать возможности ClickHouse, чтобы оптимально хранить и обрабатывать данные. В итоге коллегам удалось добиться быстродействия гораздо выше, чем в связке с внутренней базой данных Tableau. 

Дальше нужно было понять, какой именно запрос уходит в базу от дашборда. Асинхронная загрузка чартов, которые находятся в области зрения пользователя, удобный инспектор и быстрая работа БД, которую можно очень глубоко настроить под определённые типы запросов, позволили в 6 раз ускорить загрузку отчёта с источником в 100 миллионов строк: от 24–27 секунд в Tableau, до 4–6 секунд в DataLens. Бизнес-пользователи почувствовали и оценили этот результат.

Совместное использование ClickHouse и Yandex DataLens

Мы вдохновились опытом Яндекс Go и решили поделиться с вами советами, как оптимизировать работу дашборда. 

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

Для пользователей важна возможность просмотреть отзывы по товару:

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

Оптимизация скорости

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

Для такого сценария в качестве СУБД для поставки данных дашборду идеально подходит ClickHouse. Построение отдельных графиков и виджетов, которые используют небольшое количество полей в исходной таблице, происходит быстро благодаря колоночному хранению: сканируются только нужные колонки из исходной таблицы. Таким образом, нам не нужно создавать и поддерживать дополнительные таблицы агрегации — все графики и таблицы дашборда строятся на лету по одной таблице в ClickHouse.

Для решения задачи мы создали управляемый кластер ClickHouse в Yandex Cloud. Сервисы управляемых баз данных в Yandex Cloud позволяют развёртывать различные СУБД за пару минут — достаточно лишь выбрать нужную конфигурацию ресурсов в веб-интерфейсе и нажать кнопку «Создать кластер».

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

Диски типа local ssd не отказоустойчивы, а потому Managed ClickHouse обязал нас для надёжности создать кластер как минимум с одной репликой.

Окончательная конфигурация кластера получилась такой: два хоста, в каждом по 12 vCPU, 48 GB RAM и 368 GB local ssd storage.

Исходные данные лежат в виде CSV-файла в публичном S3-хранилище. Его загрузку в ClickHouse мы выполнили одной операцией вставки благодаря тому, что ClickHouse поддерживает внешние таблицы, загружающие данные по протоколу S3.

Таблица с отзывами хранится в ClickHouse в формате ReplicatedMergeTree. Этот формат также называется движком. В таблицах такого типа данные хранятся поколоночно, отсортированными и сжатыми. Также вместе с таблицей всегда создаётся первичный индекс по атрибутам сортировки.

В нашем дашборде применяются суммарные агрегации по всей таблице (общее количество отзывов, средняя оценка), а также агрегации по дате, по категориям и по продуктам плюс фильтрация по этим же измерениям. Для оптимизации мы выбрали сортировку данных по категории, затем по продукту. Продукт — измерение с самой высокой кардинальностью из использующихся, а категория однозначно зависит от продукта. Храня данные отсортированными подобным образом, мы добиваемся быстрой фильтрации по категориям и продуктам.

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

Для ускорения отображения дашборда мы использовали механизм проекций, который поддерживает ClickHouse. Проекции — это дополнительные структуры предагрегированных данных, которые хранятся в СУБД и привязаны к основной таблице. При выполнении запроса оптимизатор может читать данные из проекции вместо таблицы, если агрегации в запросе совпадают с агрегациями в проекции. Проекции обновляются асинхронно командой MATERIALIZE, и эта операция сопоставима по времени с запросом из таблицы, не имеющей проекции. В нашем примере это достаточно сделать однократно.

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

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

Для каждого чарта мы замерили время загрузки с помощью инспектора и собрали их в единую таблицу:

Так как чарты на дашборде загружаются асинхронно, то нельзя сказать, что дашборд грузится за какое-то конечное количество секунд. Поэтому мы замерили время загрузки каждого чарта по отдельности. 

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

На скриншоте — пример замера скорости с помощью инспектора:

Мы также поработали на стороне DataLens и дизайна дашборда:

• Вместо функции COUNTD для подсчёта уникальных пользователей использовали функцию APPROX_COUNTD.

• Для топа товаров и продуктов использовали пагинацию с ограничением на вывод одновременно 10 категорий или товаров.

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

Выводы

Для демонстрации возможностей работы ClickHouse c Yandex DataLens мы разработали дашборд, который берёт данные из таблицы в ClickHouse. Теперь все чарты загружаются в среднем за полторы-две секунды — ниже таблица со временем загрузки. Это отличный результат, которого получилось добиться, используя базовую функциональность DataLens и ClickHouse. Вы можете сами оценить скорость работы дашборда на видео ниже или попробовать его публичную версию.

В июне Figma провела ежегодную конференцию Config 2023. Во время мероприятия компания рассказала про функции, над которыми работает сейчас, и представила обновления дизайн-платформы: поддержку переменных, режим для разработчиков и анонс ИИ-функций.

DevMode

В Figma запустили бета-тест режима DevMode, который, по словам компании, уменьшает разрыв между прототипированием продукта и его разработкой. Во время конференции отметили, что изначально Figma была создана для быстрой реализации идей дизайнерами. Для этого на платформе есть инструменты, позволяющие создавать идеи и масштабировать их. При этом в Figma всё ещё есть разрыв между командой разработки, которой зачастую приходится тратить много времени на продумывание реализации прототипа и плана его дальнейшей поддержки. Эту проблему призван решить режим DevMode.

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

Вместе с этим команда добавила поддержку популярных среди разработчиков сервисов в виде расширений. Это позволит взаимодействовать с командой через Figma и меньше переключаться между рабочими приложениями. Уже сейчас заявлена поддержка Jira, Linear, GitHub, Storybook, AWS Amplify Studio, Google Relay, и Anima. Также можно разрабатывать собственные расширения, оптимизированные для специфического рабочего окружения.

С помощью DevMode добавили инструмент для отслеживания уже готовых для разработки экранов и элементов. Раньше для этого дизайнеры добавляли готовые макеты в отдельный файл, но теперь можно отмечать их с помощью кнопки Ready for development. Так разработчики могут понять, что макет больше не будет изменяться, а кроме финальной версии можно просмотреть всю историю изменений.

Также команда Figma выпустила расширение для VS Code. С его помощью разработчики могут просматривать макеты в редакторе кода и не переключаться на другое приложение.

До конца 2023 года DevMode и расширение для VS Code будут доступны бесплатно в режиме бета-теста. С 2024 года для доступа к функциям будет требоваться платная подписка Figma. В компании рассказали, что разработчикам не всегда нужны все возможности Figma, поэтому в 2024 году станет доступен новый тариф только с доступом к расширению и режиму DevMode.

Переменные

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

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

Сейчас есть поддержка следующих возможностей в переменных:

• числовые, текстовые, цветовые и логические переменные, хранящие в себе изменяемые значения;

• названия переменных и области видимости, позволяющие командам взаимодействовать с макетами;

• режимы отображения макетов в зависимости от переменных. К примеру, дизайнер может настроить переключатель «светлый/тёмный» и менять тему макета приложения одним нажатием мыши.

Работу с переменными поддерживают плагины и Figma API. Это позволяет сторонним разработчикам создавать инструменты для автоматизации и более удобного взаимодействия с переменными. Содержимым переменных можно управлять за пределами Figma, а также использовать внешние источники для обновления переменных.

Переменные и создание прототипов

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

Теперь в Figma появилась поддержка переменных в режиме создания прототипов. В компании отмечают, что процесс создания динамических прототипов стал похож на работу с формулами в редакторах таблиц. К примеру, дизайнер может указать условие «каждый клик по элементу увеличивает переменную n на n+1» или «перейти к первому экрану, если переменная n равна x, в противном случае перейти ко второму экрану».

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

Дизайнер Дэйв Уильямс (Dave Williames) рассказал в Twitter о том, как создал рабочий клон классической игры Flappy Bird в Figma. Для этого использовались новые функции прототипирования с помощью переменных. Игры поддерживает подсчёт очков текущей сессии, рекорды, псевдослучайное размещение препятствий и движения персонажа, основанные на физике. Всего пришлось использовать 46 переменных.

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

Финальный файл проекта Уильямс опубликовал на портале Figma Community. Его можно свободно использовать для изучения того, как устроены переменные в Figma и как их можно использовать для создания динамических прототипов.

Автоматическая компоновка

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

Пользователям стали доступны функции:

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

• Минимальная или максимальная высота/ширина — функции обеспечивают согласованность и целостность дизайна, гарантируя, что элементы макета никогда не станут слишком мелкими или не займут всю видимую область.

Новые функции для работы со шрифтами:

• Фильтры — в поиске можно уточнить параметры шрифта, к примеру, с засечками или без, моноширный или курсивом. Это поможет быстрее подбирать подходящий шрифт и сразу попробовать несколько похожих;

• Превью — строка выбора шрифта теперь отображает название в стиле самого шрифта, а не системного для Figma.

Приобретение Diagram

Представители Figma обращают внимание на тренды использования искусственного интеллекта в дизайне и разработке. В компании считают, что использование подобных технологий поможет ускорить процесс создания макетов. Дизайнеры смогут получать стартовые шаблоны, созданные силами ИИ, которые в процессе можно будет доводить до желаемого результата.

Figma продолжает формировать команду машинного обучения для разработки подобных функций. В рамках этого процесса компания купила сервис Diagram, основанный Джорданом Сингером (Jordan Singer). Долгое время Сингер в одиночку разрабатывал расширения для Figma на базе машинного обучения и искусственного интеллекта. Теперь команда проекта Diagram будет работать над ИИ-функциями вместе с разработчиками Figma.

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

В ближайшее время часть возможностей Diagram войдёт в стандартный пакет Figma, а обе команды разработчиков сосредоточатся на новых возможностях. Представители компании пока не называют условия использования ИИ-функций, но, вероятно, что большая часть из них будет доступна только по подписке.

Figma для образования

В прошлом году Figma объявила о партнёрстве с Google Chromebook. Компании планировали подготовить специальные версии Figma и FigJam для школьников в возрасте старше 13 лет. За последний год исследователи Figma и Google успели поработать с 50 школами в США и пообщаться с более чем 10 тыс. детей. За это время удалось выявить основные потребности школьников.

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

Записи презентаций с Figma Config 2023 опубликованы на сайте компании.