ГАЙД по аналитике

🌟 "GraphQL. Язык запросов для современных веб-приложений". Порселло Ева, Бэнкс Алекс! 🌟 📚 Что ты найдёшь в книге? - Основы GraphQL: объяснение фундаментальных концепций, таких как схемы, запросы и мутации. - Сравнение с REST: понимание различий между GraphQL и REST API. - Оптимизация производительности: узнайте, как минимизировать количество запросов и повысить быстрое время отклика вашего приложения. - Интеграция с клиентами: как использовать GraphQL в сочетании с популярными фронтенд-фреймворками, например с React. #sa_books

Привет, сообщество! 👋 Ребята тут составили папочку с интересными каналами для БА/СА/ПО, и мы с удовольствием поучаствовали 🙂 Подписывайтесь, ведь тут сразу много крутых каналов и полезной информации. https://t.me/addlist/U7QDrTnhOMhlOGMy А если кто-то хочет со своим каналом к нам в папку - пишите @itshnik_kolya

Всем привет! Сегодня поговорим о важной теме в мире данных — ETL (Extract, Transform, Load) и рассмотрим один из мощнейших инструментов для управления этими процессами — Apache Airflow. Что такое ETL? ETL — это процесс извлечения данных из различных источников, их трансформация в нужный формат и последующая загрузка в целевую систему, будь то база данных, хранилище данных или аналитическая платформа. Этот процесс позволяет интегрировать разнородные данные в единую систему для дальнейшего анализа и принятия решений. Extract (Извлечение): Сбор данных из различных источников, таких как базы данных, файлы, API и т.д. Transform (Трансформация): Преобразование данных в нужный формат, включая очистку, нормализацию, агрегацию и другие операции. Load (Загрузка): Загрузка преобразованных данных в целевую систему. Почему это важно? Эффективный процесс ETL позволяет бизнесу: 📊 Объединять данные из различных источников для последующей обработки и использования приложениями. 🧹 Улучшать качество данных. 🚀 Ускорять процесс принятия решений на основе данных. 💰 Снижать затраты на управление данными. Организация и управление процессами ETL могут быть достаточно сложными задачами, особенно когда речь идет о больших объемах данных и множестве источников. Здесь на помощь приходит один из инструментов Apache Airflow — мощный инструмент для планирования, управления и мониторинга рабочих процессов. Как устроен Apache Airflow? Apache Airflow — это платформа для программного создания, планирования и мониторинга ETL процессов. Вот основные компоненты, которые составляют его архитектуру: 1. Scheduler (Планировщик): Планировщик отвечает за организацию выполнения задач в соответствии с определенным графиком (например, ежедневно или ежечасно). Он отслеживает DAG'и (Directed Acyclic Graphs) и запускает задачи в нужное время. 2. Executor (Исполнитель): Исполнитель отвечает за выполнение задач. Он может быть настроен на выполнение задач локально или распределенно (например, с использованием Celery Executor для распределенных вычислений). 3. DAG (Directed Acyclic Graph): DAG — это основной элемент в Airflow, который определяет последовательность выполнения задач. DAG представляет собой граф, где каждая вершина — это задача, а ребра — зависимости между задачами. 4. Task (Задача): Задача — это единичная операция в рамках DAG. Задачи могут быть различных типов: PythonOperator для выполнения Python-кода, BashOperator для выполнения команд в оболочке и многие другие. 5. Web Interface (Веб-интерфейс): Airflow предоставляет удобный веб-интерфейс для мониторинга выполнения задач, управления зависимостями и просмотра логов. Это позволяет легко отслеживать состояние выполнения рабочих процессов. 6. Metadata Database (Метаданные): Все метаданные о DAG'ах, задачах, их состояниях и логах хранятся в базе данных. Это позволяет восстанавливать состояние после перезапуска и обеспечивает целостность данных. Пример использования Apache Airflow Представьте, что вам нужно ежедневно обновлять отчет, который собирает данные из нескольких источников, очищает их и загружает в аналитическую базу данных. С помощью Airflow вы можете создать DAG, который определяет последовательность выполнения задач.

Проектирование таблиц в базе данных: 4 главных правила Привет, коллеги! За годы работы системным аналитиком мы накопили множество знаний и наблюдений, которыми хотим поделиться. Одной из важнейших задач является проектирование таблиц в базе данных. Итак, 4 главных правила, о которых стоит помнить при проектировании таблиц в БД: 1️⃣ Нормализация данных Нормализация помогает минимизировать избыточность и избежать аномалий при обновлении данных. Основные этапы нормализации: 📌 Первая нормальная форма (1NF): Все столбцы должны содержать только атомарные значения. 📌 Вторая нормальная форма (2NF): Таблицы должны быть в 1NF и все неключевые атрибуты должны полностью зависеть от первичного ключа. 📌 Третья нормальная форма (3NF): Таблицы должны быть в 2NF и все атрибуты не должны зависеть транзитивно от первичного ключа. 2️⃣ Выбор подходящих типов данных Правильный выбор типов данных — это залог эффективного хранения и обработки информации. Используйте подходящие типы данных: 📌 Целочисленные типы (INT, BIGINT) для числовых значений без дробной части. 📌 Дробные типы (FLOAT, DECIMAL) для числовых значений с дробной частью. 📌 Строковые типы (VARCHAR, TEXT) для текстовых данных. 📌 Дата и время (DATE, TIMESTAMP) для временных меток. 3️⃣ Создание индексов Индексы — это инструмент, который позволяет значительно ускорить выполнение запросов. Тем не менее, избыточные индексы могут замедлить операции вставки, обновления и удаления. Используйте индексы для: 📌 Первичных ключей (PRIMARY KEY). 📌 Внешних ключей (FOREIGN KEY). 📌 Столбцов, часто используемых в условиях WHERE, JOIN и ORDER BY. 4️⃣ Документирование структуры БД Хорошая документация — это не просто формальность. Это мощный инструмент для понимания структуры данных и их использования. Включайте в документацию: 📌 Описание таблиц и их назначения. 📌 Пояснение значений столбцов и типов данных. 📌 Описание ограничений, индексов и связей между таблицами. 📌 Примеры типичных запросов и операций с данными. Соблюдая эти правила, вы создадите базы данных, которые будут эффективными, масштабируемыми и легко поддерживаемыми. Делитесь своими мыслями и опытом в комментариях! ❓ А какие правила и техники вы используете при проектировании таблиц в своих проектах?

🚀 Привет, коллеги! Помогите собрать больше данных! 🚀 🙌 Ребята, мне нужна ваша помощь! 🙌 Чтобы получить больше информации о том, как мы, бизнес и системные аналитики, работаем и развиваемся, я провожу небольшой опрос. Поделитесь этим постом и пригласите своих знакомых аналитиков участвовать! Уже 130 человек откликнулись за первых 5 дней, но хочется собрать ещё больше ответов! 💬 📝 А пока инсайты из уже собранных ответов: 1. Продукт или аутсорс? Половина участников работает в продуктовых компаниях, а другая половина — в аутсорсе. Я была уверена, что аутсорса будет больше. 2. Самые популярные домены: - 💳 FinTech: 36 человек - 🛒 E-commerce: 27 человек - 🏥 Healthcare: 12 человек 3. Неожиданные зарплатные находки: 💸 7 человек получают *до 500 долларов*, и один из них работает уже больше года! Это меня реально удивило! 🤯 💡 Присоединяйтесь к опросу: https://docs.google.com/forms/d/e/1FAIpQLScrPvjw5kksynNHBN--nCQ2ReA4apqJoPnbXnnqzHPnvFozvQ/viewform

💡 Привет, друзья!💡 Давно не обсуждали бизнес-анализ, а ведь это важная тема! Сегодня вернёмся к истокам и поговорим о User Story Mapping (USM). Это отличный инструмент для планирования и приоритизации задач. В новом материале вы узнаете, как использовать USM для успешных проектов. 🚀

Привет сообщество бизнес и системного анализа! 👋 Сегодня мы рассмотрим ключевые модели управления доступом в информационных системах. Управление доступом - это важный аспект безопасности, который помогает обеспечить конфиденциальность, целостность и доступность данных. 1️⃣ DAC (Discretionary Access Control) - модель управления доступом, основанная на усмотрении владельца объекта или субъекта. Владелец данных определяет, кто может получить доступ к данным и какие операции могут быть выполнены. Пример: представьте, что у вас есть документ в Google Docs. Вы, как владелец документа, можете предоставить другим пользователям доступ на чтение или редактирование. Это и есть пример модели DAC, где вы определяете правила доступа на свое усмотрение. 2️⃣ MAC (Mandatory Access Control) - модель управления доступом, в которой доступ к информации контролируется системой на основе уровней безопасности (меток) как у информационных объектов, так и у пользователей. Пример: военные или государственные системы часто используют MAC. В этих системах информация классифицируется по уровням секретности (например, "секретно", "совершенно секретно"), а у пользователей есть соответствующие уровни допуска. 3️⃣ RBAC (Role-Based Access Control) - модель управления доступом, где разрешения основаны на ролях пользователей внутри системы. Пользователи получают определенные роли, и каждая роль имеет набор связанных с ней разрешений. Пример: В большинстве корпоративных систем используется RBAC. Например, в банковской системе сотрудники отдела продаж могут просматривать информацию о клиентах, но не могут совершать транзакции. Сотрудники отдела обслуживания клиентов, с другой стороны, могут совершать транзакции, но не могут изменять банковские продукты. 4️⃣ ABAC (Attribute-Based Access Control) - модель управления доступом, где разрешения основаны на атрибутах пользователей, данных и окружения. Это более гибкая и динамическая модель, которая может учитывать множество различных факторов при принятии решений о доступе. Пример: Представьте систему управления доступом в здание, которая учитывает не только ID сотрудника, но и текущее время (атрибут). Если сотрудник является ночным охранником, у него есть доступ к зданию только ночью, но не днем. Выбор модели управления доступом зависит от многих факторов, включая требования к безопасности, природу данных и операционные потребности организации. Важно провести глубокий анализ и понять, какая модель будет наиболее эффективной для вашей конкретной ситуации. Если вы проектируете систему "с нуля" то не нужно "изобретать велосипед". Существует множество готовых библиотек на различных языках программирования, которые помогут вам выстроить систему управления доступом к ресурсам вашего приложения. О некоторых из них мы расскажем в следующем посте. Если у вас есть вопросы или вы хотите поделиться своим опытом в управлении доступом, присоединяйтесь к обсуждению! 🚀 #middle_sa #authorization_system

Существуют open source библиотеки, которые позволяют автоматизировать формирование документации по API GraphQL по аналогии со Swagger по REST API. На сайте одного из таких сервисов (GraphQL Voyager) можно ознакомится с примером структуры GraphQL схемы. Она напоминает всем нам знакомую ERD модель данных. Вот некоторые из таких библиотек: 1️⃣Собственно, GraphQL Voyager, о котором упомянули ранее - это интерактивная визуальная схема вашего GraphQL API. Вы можете использовать его для исследования типов и их отношений в вашей схеме. https://graphql-kit.com/graphql-voyager/ 2️⃣ SpectaQL - это инструмент, который автоматически генерирует статическую документацию для вашего GraphQL API. Он анализирует схему GraphQL и создает документацию в формате HTML. https://github.com/anvilco/spectaql 3️⃣ MagiQL - это библиотека, которая автоматически генерирует документацию для вашего GraphQL API, используя информацию из схемы и дополнительные метаданные. Он создает интерактивную документацию с поддержкой поиска, фильтрации и навигации. https://magidoc.js.org/introduction/welcome Если у вас есть вопросы или вы хотите поделиться своим опытом определения типов в GraphQL, присоединяйтесь к обсуждению! 🚀 #GraphQL #middle_sa

Привет, сообщество бизнес и системного анализа! 👋 Сегодня мы расскажем более подробно о типах в GrapQL схеме. 🔹 Scalar types (скалярные типы) - это примитивные типы данных, которые представляют собой базовые блоки для определения полей в схемах GraphQL. Вот некоторые из них: - Int: целое число со знаком. - Float: число с плавающей точкой. - String: строка символов. - Boolean: логическое значение, истинное или ложное. - ID: уникальный идентификатор. Хотя он технически является строкой, его отдельное обозначение подчеркивает его особое использование в качестве уникального идентификатора. Скалярные типы используются для представления простых данных, таких как числа, строки и булевы значения. 🔸Object types (объектные типы) - это более сложные типы, которые представляют собой набор полей. Каждое поле может иметь скалярный тип или быть другим объектным типом, позволяя вам создавать сложные и вложенные структуры данных. Каждый тип соответствует объекту в API и определяет поля, которые могут быть запрошены. Объектные типы используются для представления сущностей в вашем API и их связей. Давайте рассмотрим пример: type User { id: ID! name: String! email: String! posts: [Post] } type Post { id: ID! title: String! content: String! author: User! } В этой схеме у нас есть два объектных типа: User и Post. В типе User у нас есть поле posts, которое является списком объектов типа Post. Это означает, что каждый пользователь может иметь несколько постов. Аналогично, в типе Post у нас есть поле author, которое является объектом типа User. Это означает, что каждый пост имеет одного автора. Чтобы указать, что поле является объектом другого типа, вы просто используете имя этого типа в определении поля. Если поле может содержать несколько объектов, вы используете квадратные скобки [] для обозначения списка. 🔹 Enumeration types (Тип перечисления) - это специальный вид скалярного типа, который ограничивает значения определенным набором констант. Используется, когда поле может принимать только ограниченный набор значений. enum Role { ADMIN USER GUEST } 🔹 Interfaces (Интерфейсы) - абстрактные типы, которые определяют общий набор полей, который должен иметь ряд объектных типов. Используются для создания общих полей между различными типами. interface Character { id: ID! name: String! } type User implements Character { id: ID! name: String! email: String! } 🔹 Root types (Корневые типы) - это особые типы, которые определяют точки входа в ваш API для операций чтения (Query), записи (Mutation) и подписки (Subscription). Используются для определения начальных точек для запросов к вашему API. type Query { user(id: ID!): User } type Mutation { createUser(name: String!, email: String!): User } О корневых типах мы расскажем подробнее в отдельном посте. #GraphQL #middle_sa

Привет сообщество! Подпишитесь на Telegram-канал нашей коллеги Анастасии! Сейчас там идет крупный разбор основ REST API, абсолютно все, что надо знать. Все полезно и просто! Также Настя пишет про вакансии для джунов, скоро будут советы по резюме. Не пропустите важную информацию! https://t.me/tosibosiba

Привет сообщество бизнес и системного анализа! 👋 Сегодня мы поговорим о проектировании схем в GraphQL. Проектирование схемы - это ключевой этап при создании GraphQL API, который включает в себя следующие шаги: 1️⃣ Определение типов: Ваша схема GraphQL начинается с определения типов. Каждый тип соответствует объекту в вашем API и определяет поля, которые могут быть запрошены. type User { id: ID! name: String! email: String! } 2️⃣ Определение запросов и мутаций: Затем вы определяете, какие запросы и мутации доступны в вашем API. Запросы используются для чтения данных, а мутации - для изменения данных. type Query { user(id: ID!): User } type Mutation { createUser(name: String!, email: String!): User } 3️⃣ Указание признака обязательных полей: В GraphQL вы можете указать, является ли поле обязательным или необязательным, используя знак восклицания (!). Это позволяет вам контролировать, какие данные должны быть предоставлены. 4️⃣ Определение связей между типами: В GraphQL вы можете определить связи между типами, что позволяет запросить связанные данные. type User { id: ID! name: String! email: String! posts: [Post]! } type Post { id: ID! title: String! content: String! author: User! } 5️⃣ Использование директив: Директивы в GraphQL позволяют вам изменять поведение вашей схемы, например, добавлять условия или управлять доступом к данным. Например, директива @deprecated позволяет пометить поля как устаревшие: type User { id: ID! name: String! email: String! oldEmail: String! @deprecated(reason: "Use `email` field instead") } Проектирование схемы в GraphQL - это процесс, который требует понимания бизнес-логики и требований к данным. Системный аналитик играет ключевую роль в этом процессе, помогая определить, какие данные должны быть доступны через API, и как они должны быть структурированы. Если у вас есть вопросы или вы хотите поделиться своим опытом проектирования схем в GraphQL, присоединяйтесь к обсуждению! В следующих постах подробнее остановимся на каждом шаге и в финале приведем пример спроектированной схемы 🚀 #GraphQL #middle_sa

🔹 Основные элементы GraphQL Типы (Types): GraphQL использует сильную типизацию. Каждый объект имеет определенный тип, что помогает обеспечить надежность и предсказуемость API. Запросы (Queries): Это операции чтения в GraphQL. Они позволяют клиенту запросить конкретные данные, которые ему нужны. Мутации (Mutations): Это операции записи в GraphQL. Они позволяют клиенту создавать, обновлять и удалять данные. Подписки (Subscriptions): Это операции реального времени в GraphQL. Они позволяют клиенту подписаться на обновления данных. 🔸 GraphQL vs REST Один конечный пункт vs множество: В отличие от REST, где у вас есть множество конечных точек, в GraphQL обычно есть только одна конечная точка. Эффективность запросов: В GraphQL вы запрашиваете только те данные, которые вам нужны, что помогает уменьшить объем передаваемых данных. Сильная типизация: GraphQL использует сильную типизацию, что помогает предотвратить многие ошибки на ранних стадиях разработки. Агрегация данных: GraphQL позволяет агрегировать данные из нескольких источников, что упрощает работу с данными. GraphQL предлагает мощный и гибкий подход к разработке API, который может быть более эффективным и удобным, чем традиционный подход REST. В следующих постах мы углубимся в каждый из этих элементов и рассмотрим, как их использовать на практике, предложим ряд инструментов, которые позволят вам спроектировать схемы, и перечислим недостатки GraphQL. Следите за обновлениями! 🚀 #GraphQL #middle_sa

Привет, сообщество! 🚀 Сегодня мы начинаем новую серию обучающих постов о GraphQL - мощном языке запросов для API, который становится все более популярным в мире веб-разработки. 🔹 Что такое GraphQL? GraphQL - это открытый стандарт, разработанный Facebook, который предоставляет эффективный и мощный альтернативный подход к REST и предлагает новые возможности для разработки API. 🔸 Как работает GraphQL? В отличие от традиционного REST API, где у вас есть множество конечных точек с фиксированными структурами данных, GraphQL имеет только одну конечную точку. Это означает, что вы запрашиваете конкретные данные, которые вам нужны, и получаете именно то, что запросили. 🔹 Почему GraphQL? Эффективность: GraphQL позволяет клиентам получать именно то, что им нужно, что помогает уменьшить количество данных, передаваемых по сети, а это в свою очередь ускоряет загрузку страниц. Скорость и стабильность: GraphQL позволяет агрегировать данные из нескольких источников, так что клиенты могут получить все, что им нужно, за один запрос. Сильная типизация: GraphQL использует сильную типизацию, что помогает предотвратить многие ошибки на ранних стадиях разработки. #GraphQL #middle_sa

Привет, сообщество! 👋 Сегодня мы продолжаем нашу серию обсуждений о диаграммах последовательностей (Sequence Diagrams) и сфокусируемся на одном из ключевых элементов - сообщениях. 🔹 Что такое сообщения в Sequence Diagram? Сообщения - это основной механизм взаимодействия между объектами в Sequence Diagram. Они представляют действия, которые один объект выполняет в отношении другого. 🔸 Типы сообщений: Существуют различные типы сообщений, которые можно использовать в Sequence Diagram: • Синхронные сообщения: Это тип сообщения, когда отправитель ждет ответа, прежде чем продолжить. Они представлены стрелкой в виде закрашенного треугольника. • Асинхронные сообщения: Отправитель не ждет ответа и продолжает выполнение сразу после отправки сообщения. Они представлены открытой стрелкой. Сообщения создания: В диаграммах последовательности сообщение создания обычно идет от одного объекта к другому и представляет собой стрелку, указывающую на линию жизни нового объекта. Эта стрелка начинается от отправителя и указывает на точку, где появляется новая линия жизни (вертикальная линия), что символизирует создание нового объекта. Сообщения удаления: Сообщение об удалении обычно представляет собой стрелку, указывающую на конец линии жизни объекта. Это означает, что объект больше не существует в контексте данного взаимодействия. После этой точки на диаграмме линия жизни объекта обычно прекращается или становится пунктирной. 🔹 Как использовать сообщения? Сообщения располагаются на горизонтальных стрелках между вертикальными жизненными линиями объектов. Порядок сообщений считывается сверху вниз - чем ниже сообщение, тем позже оно происходит во времени. Сообщения - это ключевой элемент в Sequence Diagram, и правильное использование различных типов сообщений поможет вам точно и наглядно представить взаимодействие между объектами в вашей системе. Присоединяйтесь к обсуждению и делитесь своим опытом использования сообщений в Sequence Diagram! 🚀 #sequence_diagram #UML #инструменты_sa

Ребята, привет! Мы вернулись! 🚀 Сегодня мы затронем тему диаграмм последовательностей или Sequence Diagrams. Это одна из самых популярных диаграмм в UML, которая используется для визуализации взаимодействия между объектами в определенной последовательности времени. 🔹 Что такое Sequence Diagram? Sequence Diagram - это графическое представление взаимодействия между объектами в системе в контексте времени. Она показывает, как сообщения обмениваются между объектами для достижения конкретной цели. 🔸 Ключевые элементы Sequence Diagram: Объекты: представлены в верхней части диаграммы. Жизненные линии: вертикальные линии, которые идут вниз от каждого объекта. Они показывают время жизни объекта. Сообщения: горизонтальные стрелки между жизненными линиями. Они показывают обмен сообщениями между объектами. 🔹 Почему Sequence Diagram важны? Sequence Diagrams помогают лучше понять, как система будет работать на практике. Они показывают, как данные передаются между компонентами и как эти компоненты взаимодействуют друг с другом во времени. 🔸 Когда использовать Sequence Diagram? Они особенно полезны при проектировании и документировании систем, где важно понимание временной последовательности взаимодействия между объектами. В общем, Sequence Diagrams - это мощный инструмент для визуализации и понимания сложных систем. Если вы еще не использовали их в своей работе, рекомендуем попробовать! В качестве объектов можно привести следующие примеры: 1️⃣ Пользователь (User): В контексте веб-приложения, "Пользователь" может быть объектом, который начинает взаимодействие, отправляя запросы на вход или нажимая кнопки в пользовательском интерфейсе. 2️⃣ Сервер (Server): "Сервер" может быть объектом, который получает запросы от пользователя и обрабатывает их, возможно, взаимодействуя с другими объектами в процессе. 3️⃣ База данных (Database): "База данных" может быть объектом, с которым сервер взаимодействует, чтобы получить, сохранить или обновить данные. 4️⃣ Сервис платежей (Payment Service): В контексте электронной коммерции, "Сервис платежей" может быть объектом, который обрабатывает транзакции и возвращает результаты серверу. 5️⃣ Почтовый сервер (Mail Server): "Почтовый сервер" может быть объектом, который отправляет уведомления по электронной почте пользователям по запросу от сервера. Это всего лишь несколько примеров, и в зависимости от вашего конкретного сценария и системы, объекты могут сильно варьироваться. Присоединяйтесь к обсуждению и делитесь своим опытом использования Sequence Diagrams! 💼📊 Ставьте лайки и огонечки и мы продолжим раскрывать тему🔥🔥🔥 #sequence_diagram #UML #инструменты_sa

Ребята, привет! 🙌 Уже на этой неделе, 22 сентября, впервые в России пройдет масштабная офлайн конференция "Fine day" по FineBI, на которую впервые приедут представители компании из Китая 🇨🇳. Вас жду интереснейшие дискуссии о критериях выбора BI инструмента и обмен опытом руководителей, директоров, аналитиков и всех кто не равнодушен к Self Service BI. 📍 Место проведения: г. Москва, ул. Мясницкая, д. 13 стр.11 Loft13; ⏰ Время проведения: с 15.00 до 18.50; 🖊Зарегистрироваться можно здесь. #IT_события

Ребята, привет! 🙌 Ловите ТOП-3 блога для бизнес- и системных аналитиков: 🔹 KungFu Аналитика - комьюнити людей с белым поясом по бизнес-аналитике в ИТ; 🔹 KungFu на vc.ru - контент, который встряхнёт вас новыми идеями, напомнит о базовых правилах и упростит вашу работу за счет опыта других аналитиков; 🔹KungFu – платформа на vc.ru, на которой вы можете стать частью профессионального сообщества бизнес-аналитиков и автором статей. ❗️Да, в подборке блогов - один блог, потому что закрывает все пункты ✅. Мы даже открыто говорим, что делать, если заказчик требует дичь. Подписывайтесь, забирайте полезный опыт и делитесь своим 😎.

Друзья, привет! 👋 Наши друзья из karpov.courses ищут коллег в команду саппортов со знаниями в системном анализе. Что предлагают: ✅ удаленка; ✅ гибкий график работы, главное - результат; ✅ классная команда единомышленников; ✅ любой курс школы можно пройти бесплатно 🤑; ✅ партнерские программы по английскому языку. Всем кому интересен дополнительный заработок отправить резюме можно 👉 сюда На дополнительные вопросы поможет ответить 💁🏻‍♀️ @lolituy Всем удачи! 🍀

Всем привет!✌️ Кто ходит в гости по утрам, тот поступает мУдро! 🐻🎈 …А особенно, если ты идешь в субботнее утро на ежегодную конференцию DataDriven, которую организует Яндекс.👍 Мероприятие обещает быть интересным всем, кто использует анализ данных для принятия бизнес-решений. В качестве спикеров выступают руководители структурных подразделений Яндекса. Традиционно конференция пройдет в формате онлайн и оффлайн бесплатно. ⏰ 10.30 утра, 25 июня 2022 г. 📍 Москва, улица Льва Толстого, 16, подъезд Экстрополис. Подробно о мероприятии и ссылка на регистрацию здесь 👈 P.S. А еще у Яндекс обычно потрясающие фуршеты 🍡🍢🍣😋 #IT_события