CODERIKK | Дзен

CODERIKK

Немного познакомимся и я расскажу о себе и своем опыте. Меня зовут Егор, мне 26 лет 🫶🏼 Мои основные специализации: - Программист, разработчик - BI-аналитик, аналитик данных - Data Scientist (DS, DA, DE) Имею 2-а красных диплома 📕 Опубликовано 11 научных статей 📚 Зарегистрировано 3 рационализаторских предложения 📔 Большой опыт работы с библиотекой Pandas и библиотекой визуализации Matplotlib. Имею опыт работы с NLP (обработка естественного языка) в данном направлении начинал работу с машинным обучением, например, такие задачи как классификация отзывов по темам и определение настроение пользователя. Занимался парсингом новостных сайтов и отзовиков, проводил анализ отзывов и мнений, поиск ошибок и неисправностей. XML парсинг RSS лент. Разработал несколько полноценных, полнофункциональных Telegram-bot'ов на основе ИИ - Python асинхронных библиотек с использованием ChatGPT с регистрацией, верификацией по почте и различными моделями взаимодействия и сохранением контекста, с проектированием, реализации и использовании баз данных PostgreSQL и MySQL, размещенный на своём сервере под управлением системы Ubuntu. Разработал Desktop утилит для торговых предложений, отслеживания товаров внутри одного предприятия на основе разработанного графического интерфейса. Дипломы написаны по теме "Computer Vision" основной задачей которых было обнаружение и идентификация личности или объекта задачи. Также интересной задачей был поиск погрешностей и отклонений процесса за счет средств технологии Graph Mining (Process Mining). Опыт работы с Docker, в связи с переносом проекта на различные НРТК (наземных робототехнических комплексов) на основе Raspberry PI и Arduino. Опыт написание простых сайтов на основе Flask с применением SQLAlchemy. Опыт работы с Git и свои репозитории на GitHub и GitLab. Навык работы с Linux. Знание алгоритмов машинного обучения, искусственного интеллекта, статистики, ООП. Работа с Yandex Cloud и DataLens. Все это только небольшая часть моего опыта 🤭 Подпишись на мой Telegram-канал и развивайся в сфере IT без курсов, все просто и наглядно: CODERIKK

2 года назад

Новости и мысли

Квинтэссенция знаний SQL

🔹 Баланс для Data Engineer — не миф

🔹 Как не сгореть при on-call и постоянных миграциях? 🔸 Постоянные срочные инциденты и переключения контекста ломают рабочий ритм и ведут к выгоранию. Баланс нужен, чтобы сохранить качество данных и умение решать сложные баги без усталости. 🔸 Тайм-менеджмент: блоки глубокого фокуса, короткие окна для встреч и правила on-call (ограничение времени реакции, эскалации). Планируй рефакторинг вне on-call окон. ETL (Extract, Transform, Load) — ставь его в утренние окна, когда голова свежа. Mon-Fri...

1 час назад

🔹 Persona в промпте: роль «эксперт» без хаоса

🔹 Как задать в запросе роль — например «эксперт» — и зачем это нужно? 🔸 Решение проблемы: без явной persona модель даёт разный уровень детализации и стиль. Persona фиксирует очки зрения и тон, чтобы ответы были последовательны и полезны. 🔸 Помещаем роль в system message (системное сообщение): коротко опишите роль, ограничения и стиль (role-play). Пример: system: "You are a Data Engineering expert. Отвечай как практикующий инженер, стиль — технический, кратко...

1 день назад

🔹 Гонка состояний: кто успеет первым

? 🔹 Что такое race condition и почему порядок (order) операций ломает результат? 🔸 Race condition — ошибка, когда параллельные задачи меняют общее состояние без синхронизации; результат зависит от непредсказуемого порядка выполнения, и данные «теряются» или становятся неконсистентными. 🔸 Симптомы: нерепродуцируемые баги, пропавшие обновления, поведение меняется с нагрузкой; встречается в потоках, процессах, асинхронном коде и транзакциях. 🔸 Locking и mutex (mutual exclusion — взаимное исключение) решают проблему, сериализуя доступ к критической секции...

2 дня назад

🔹 Data Governance: основы

🔹 Что решает управление данными? 🔸 Управление данными предотвращает хаос: без правил разные команды дают разные отчёты, модели работают на плохих данных и интеграции ломаются. 🔸 Политики — набор правил доступа, хранения и удаления данных; они ставят рамки безопасности и соответствия. 🔸 Качество — проверки на точность, полноту и актуальность; если его нет, аналитика и автоматизация приносят ошибочные решения. 🔸 Метаданные — карточки ресурса: таблица, поля, тип, уровень чувствительности...

3 дня назад

🔹 NULL: не баг, а состояние

🔹 Как работать с NULL в SQL (Structured Query Language)? 🔸 NULL обозначает отсутствие или неизвестность значения. Без него вы не отличите "пустую строку" от "нет данных", и это ломает подсчёты, джойны и логические проверки. 🔸 Для проверки используйте IS NULL / IS NOT NULL. Сравнение с = NULL не работает — возвращает NULL, а не true/false, и даёт неверные результаты. 🔸 COALESCE возвращает первый ненулевой аргумент и подставляет дефолт вместо сложных CASE-ов — удобно при выдаче значений по умолчанию...

4 дня назад

🔹 Срезы списков и строк — быстро

🔹 Как взять часть строки или списка без копирования всей структуры? 🔸 Срез (slice) нужен, чтобы взять подпоследовательность: start:end задают границы. Это решает проблему длинных ручных циклов и лишних временных переменных. 🔸 Отрицательный индекс (negative index) считает с конца: -1 — последний элемент, -2 — предпоследний. Удобно, когда нужен конец без вызова len(). 🔸 step управляет шагом: start:end:step...

5 дней назад

🔹 Мониторинг задержек данных — гонка с часами

🔹 Как в реальном времени отслеживать data latency (задержку данных)? 🔸 Data latency нужна, чтобы заметить, когда потоки или ETL дают устаревшие данные — без этого отчёты и ML модели будут работать с «прошлой» картиной и бизнес примет неверные решения. 🔸 Как измерять: метрика lag = now() - max(event_time) по источникам/партициям; собирайте её регулярно и храните как time-series. SELECT source, now() - max(event_time) AS lag FROM events GROUP BY source; 🔸 Monitoring: в dashboard...

6 дней назад

🔹 Итоги недели: практические штрихи

🔹 Что разобрали и зачем это важно? 🔸 OLTP (Online Transaction Processing) vs OLAP (Online Analytical Processing): существуют чтобы разделять нагрузку — OLTP для быстрых операций (покупки, записи), OLAP для тяжёлой аналитики. Без разделения аналитика замедлит операции и исказит отчёты. 🔸 SQL (Structured Query Language) инъекция: проблема — неподготовленный ввод позволяет менять запросы и красть/портить данные. Защищаемся параметризированными запросами, ORM и строгой валидацией входа. 🔸 Python списки: зачем — гибкая упорядоченная коллекция для накопления и обработки данных...

6 дней назад

🔹 Пакетная обработка (batch) — просто о важном

🔹 Почему нужен batch/offline? 🔸 batch позволяет обрабатывать большие объёмы данных без требования real-time, чтобы не перегружать онлайн-систему и избежать неконсистентности данных. 🔸 Это оффлайн (offline) режим: данные собирают, накапливают и прогоняют пачками — так проще планировать ресурсы и делать тяжёлые трансформации. 🔸 Применяют для ETL (extract-transform-load), агрегирования и очистки; запускают по расписанию с помощью cron как ночную загрузку...

1 неделю назад

🔹 Прямой vs каскадный — когда что лучше

? 🔹 Делать один большой direct-запрос или разбивать в chain-of-thought шаги? 🔸 direct нужен, когда задача тривиальна: экономия времени и tokens повышает efficiency. Без этой стратегии получаешь лишние шаги и потерю скорости. 🔸 Используй direct для простых трансформаций и генерации вариантов. Direct: "Напиши 5 заголовков про Python для блога" 🔸 chain-of-thought нужен при сложных рассуждениях: планирование, отладка, проверка логики...

1 неделю назад

🔹 OLTP vs OLAP: transactional или аналитическая

? 🔹Чем отличаются OLTP (Online Transaction Processing) и OLAP (Online Analytical Processing) и зачем это нужно? 🔸 OLTP — transactional система для повседневных операций: много коротких транзакций (INSERT/UPDATE), низкая задержка, real-time ответы. Без этого приложение не сможет быстро регистрировать покупки или платежи. 🔸 OLAP — аналитическая система (обычно Data Warehouse) для сложных агрегатов и исторического анализа: оптимизирована для больших чтений и сложных JOIN/AGGREGATE, но не для частых записей...

1 неделю назад

🔹 ELT — когда трансформации в базе побеждают

🔹 Что решает ELT и чем отличается от ETL (Extract, Transform, Load)? 🔸 ELT нужен, чтобы убрать узкие места в сети и процессинге: вместо трансформаций до загрузки мы загружаем сырые данные и выполняем обработка в БД (база данных). Это сокращает движение данных и ускоряет итерации аналитиков. 🔸 Ключевое отличие: ETL трансформирует до загрузки; ELT — Extract, Load, then transformation внутри хранилища. В cloud (облаке) хранилища дают масштаб и дорогоэффективный compute для таких transformation...

1 неделю назад