Вы аналитик? Расскажите, как вам работается
Старые добрые осенние традиции: готовиться к Хеллоуину (если отмечаете), пересматривать «Сумерки» (если любите такое), участвовать в опросе NEWHR про рынок труда аналитиков (если вы аналитик).

Ребята каждый год проводят исследование, чтобы выяснить:
🔵уровень зарплат,
🔵лучшие места для работы,
🔵какие требования к аналитикам предъявляют работодатели,
🔵каких экспертов читают и смотрят те, кто работает с данными.
А когда они собирают все эти данные вместе с сравнивают с предыдущими годами, это позволяет посмотреть на изменения в динамике и увидеть главные тренды на рынке дата-труда.

Ну а мы их с радостью поддерживаем в этом начинании и приглашаем наших читателей принять участие в опросе. Он займет около 20 минут, а в награду вы получите ранний доступ к промежуточным результатам исследования, инвайт на закрытый стрим сс организаторами и чувство, что сделали хорошее дело.

🔜 Опрос

Valiotti Analytics — 6 лет! 🥳
Наш канал существует не сам по себе — это один из проектов дата-консалтинга Valiotti Analytics.
Мы, конечно, уже про это писали, но вдруг вы пропустили или забыли

🔜 И вот сегодня Valiotti Analytics исполняется 6 лет. За эти годы мы успели поработать над десятками проектов для заказчиков со всего мира, строили системы аналитики с нуля и разбирали тысячи строк legacy кода, радовались успехам и учились на ошибках.

В общем, это были насыщенные 6 лет, за которые компания выросла и сильно изменилась, но суть осталась та же — делать данные ближе и понятнее для бизнеса. Намерены продолжать делать это и дальше, только еще лучше. ❤️

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

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

Есть вариант называть это «вайб-инжиниринг».

В чем суть?
🔵Чтобы от ИИ получать реальную пользу (а не только едва жизнеспособный код), надо хорошо разбираться, как он работает, понимать его ограничения и выстраивать процесс.
🔵Под «выстраиванием» процесса мы понимаем использование старых добрых практик, которые применяются в нормальной, «безвайбовой» разработке. Составление грамотного плана работы и документации, настройка автоматических тестов, вдумчивое тестирование вручную, код-ревью — это все помогает не только людям, но и ИИ.
🔵Вайб-инженеру также важно реально оценивать возможности ИИ: что ему можно доверить, а что лучше сделать самому, как корректно поставить задачу и проверить качество выполнения. Человек в каком-то смысле занимает роль лида или менеджера, контролирующего своего ИИ-подчиненного.

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

Вопрос только в названии — как вам оно? Как думаете, пойдет «вайб-инжиниринг» в народ?

OpenAI представила ChatGPT Atlas
Вы никогда не думали, как было бы удобно, если бы кто-то за вас покидал покупки в корзину в онлайн-магазине, а перед этим еще сравнил, чем отличаются два на первый взгляд идентичных товара? Прочитал длинную статью и пересказал содержание? Придумал остроумный ответ в дискуссии в соцсети?

В общем, взял на себя эту сложную, нудную задачу сидения в интернете?

🔜 Что ж, если вы пользуетесь Mac’ом (остальным придется подождать), то теперь можете обзавестись таким помощником. OpenAI представила браузер ChatGPT Atlas, с прикрученным к нему ИИ-ассистентом. На картинке выше вы можете увидеть пример задачи для него — выбрать товары для похода на пляж с семьей.

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

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

Ну что скажете — будете пользоваться Atlas’ом? Или может уже пользуетесь каким-то другими ИИ-браузерами? 👀

«Мало получить инсайт — надо еще донести его понятным языком»
И другие вызовы в работе аналитика в большой компании.

В подкасте «Потом доделаю» вышел выпуск как раз для нас с вами: Роман Халкечев, руководитель аналитики Яндекс Поиска и Рекламы, рассказал, как в корпорации работают с данными. Многие компании об этом либо ничего не рассказывают, либо говорят насколько общими фразами, что лучше бы ничего не говорили. Что-то реально интересное и полезное на эту тему — как этот подкаст — появляется не так уж и часто.

Про что говорили?
🔵С какими сложностями приходится сталкиваться, как доносить ценность данных до коллег и что делать, если ваши инсайты идут вразрез с решениями бизнеса.
🔵Как ИИ влияет на работу, меняет и продукты Яндекса, и рабочие процессы внутри.
🔵Сколько у него сотрудников в управлении (спойлер: 400), чем все эти люди занимаются и как управлять такой БОЛЬШОЙ командой.
🔵Как в реальности выглядит тот самый data-driven подход, к которому все так стремятся: как принимать решения, когда данных недостаточно (да, и у Яндекса такое бывает) или слишком много.

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

🔜 Слушаем на Яндекс Музыке.

dbt 101: что нужно знать на старте и лучшие практики
dbt — отличный тул для трансформации данных и заслуженный стандарт индустрии. Мы его часто используем, потому что он сильно упрощает работу на проектах со сложной аналитикой и множеством SQL-скриптов.

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

Ну и заодно добавили парочку лучших практик, которые хорошо показывают себя на проектах. Кстати, один реальный проект тоже чуть-чуть показали.

🔜 Статья уже на Хабре!

Viz of the Day во всем многообразии
Tableau любит показывать возможности своего тула и самые крутые датавизы выставляет на всеобщее обозрение как Viz of the Day, чтобы все смотрели, впечатлялись и вдохновлялись. Эти визы дня бывают кардинально разные: про бизнес, экологию, социальные вопросы, поп-культуру. Визуально они тоже отличаются — от классических лаконичных дашбордов до дизайнерских интерактивных инфографик. Отследить какие-то закономерности в этом разнообразии раньше было не просто, но теперь эта задача стала попроще.

Амбассадор Tableau Хидеаки Ямамото собрал данные о 600 последних Viz of the Day и отобразил на инфографике. И вот на ней тренды уже видны:
🔵Большинство авторов Viz of the Day — из США и Англии, а большая часть работ — на английском языке. Есть только одно исключение на португальском.
🔵2 трети работ принадлежат людям, у которых в портфолио уже есть Viz of Day. У рекордсменки из Англии таких работ аж 11 штук.
🔵Самые популярные цвета — синий, голубой, белый и серый.

К сожалению, выделить конкретные темы по описаниям, которыми сопровождаются визы, сложно — в основном там на все лады повторяются слова «data», «viz», «explore» и так далее. Так что сказать, на какую тему надо сделать дашборд, чтобы повысить шансы засветиться в категории Viz of the Day, не получится. 😕

Очистка ИИ-слопа: современные решения современных проблем
Что мы все о плохом — ИИ отнимает работу, из-за ИИ компании реже нанимают джунов, списки профессий, которые к (тут вставить какой-нибудь год) уничтожит ИИ и так далее. Он вообще-то еще и создает рабочие места вполне успешно.

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

🔜 И именно это и привело к появлению новой ниши — очистка ИИ-слопа: так называют низкокачественный контент, сделанный с помощью искусственного интеллекта. Авторы вычитывают и переписывают ИИ-тексты, дизайнеры исправляют картинки, а программисты правят код. Уже даже появился сайт Vibecodefixers.com для поиска специально обученных людей, которые могут навести порядок в чужом вайб-коде.

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

Как выглядит кошмар аналитика
В честь Хеллоуина решили обсудить с вами кое-что действительно жуткое — страшнее приведений или клоунов.

Плохой SQL. 👻

Потому что приведений не существует, а вот кривой код очень даже реален и иметь с ним дело приходится регулярно. Для затравки нашли для вас целую подборку примеров, среди которых:
🔵нагромождение CASE WHEN, создающее хаос, в котором может разобраться только автор кода (но это не точно),
🔵несколько уровней подзапросов, разобраться в которых не может даже сам автор,
🔵вьюхи поверх вьюх поверх других вьюх — сначала это может быть удобно и красиво, но со временем система рискует стать слишком непонятной, еще и создает нагрузку на базу,
🔵попытки «подчистить» результат запроса с помощью DISTINCT для того, которые прячут проблему вместо того, чтобы ее решать.

Встречались с чем-то подобным? Или даже видели что-нибудь похуже? Делитесь в комментариях! 👀

Сделай сам: БД ключ-значение своими руками
База данных нужна, чтобы было куда удобно и компактно сложить данные, а потом — чтобы было где быстро и легко их найти.

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

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

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

Ваш PostgreSQL больше читает или пишет?
Одна из причин, почему Postgres так популярен — это его универсальность и гибкость. Мало того, что он прекрасно встроится почти в любой проект, так еще и можно оптимизировать и докрутить под свои запросы, чтобы поднять и без того высокую производительность.

Как именно его оптимизировать и докручивать, зависит от совокупности факторов, среди которых — то, каким операциям отдается приоритет: чтению или записи.

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

Операции чтения и записи «стоят» неодинаково — вторые дороже, сложнее и дольше. Следовательно, если оптимизировать PostgreSQL под свой проект, то это надо учитывать.
🔵Так, там, где больше чтения, принципиальна скорость, чтобы обеспечить пользователю максимально быстрый доступ к информации, которую он ищет. А это оптимизация индексов, кэширования и «тяжелых» SQLзапросов.
🔵А там, где нужно больше делать новые записи, важнее обеспечить вычислительные мощности, быстрое хранилище и большой объем оперативки, а еще не злоупотреблять индексами.

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

OR или не OR?
Представим, что у вас есть большая таблица applications, в которой хранятся данные о заявках пользователей, а также о людях, которые их подают (они указаны в столбце submitter_id) или рассматривают (reviewer_id). Вам нужно посчитать, со сколькими заявками взаимодействовал пользователь — неважно, отправлял или рецензировал.
Какой запрос, на ваш взгляд сработает быстрее?

SELECT COUNT(*)
FROM application
WHERE submitter_id = :user_id
   OR reviewer_id  = :user_id;

или

SELECT (
  SELECT COUNT(*) FROM application WHERE reviewer_id  = :user_id
)
+ (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
)
- (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
    AND reviewer_id = :user_id
);

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

По той же ссылке есть объяснение, почему так получается, но если кратко:
🔵Оператор AND уменьшает выборку данных, а индексы и статистика БД помогают оптимизировать его выполнение. Когда вам нужно отобрать данные по двум условиям, движок ищет сначала ищет записи, где выполняется более редкое условие и затем проходится по второму.
🔵Оператор OR либо последовательно проходится по всем данным в таблице, либо целиком одной колонке, затем по второй, чтобы их объединить. Оба варианта более «дорогие», чем просто просканировать столбец и отфильтровать лишнее

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

CREATE TABLE application_user (
  user_id        int8 NOT NULL,
  application_id int8 NOT NULL,
  user_type      enum('submitter','reviewer') NOT NULL
);

И свой изначальный запрос переделать через JOIN:

SELECT * FROM application a
  JOIN application_user au USING (application_id)
WHERE au.user_id = :user_id;

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

Вайб-кибершпионаж
Уже был и вайб-кодинг, и вайб-инжиниринг, а вот теперь — вайб-кибершпионаж с помощью ИИ.

Anthropic рассказали про операцию некой преступной группировки из Китая, которая пыталась использовать Claude для атаки на крупные технологические компании, финансовые и государственные учреждения. Злоумышленников уже остановили, а пострадавших оповестили.

🔜 Как проходила операция?
Главной задачей для человека было убедить Claude заняться взломом. Чтобы обойти внутренние ограничения ИИ, ему давали небольшие, на первый взгляд безобидные задания, чтобы он «думал», будто участвует в тестировании системы безопасности.

Это был первый этап атаки. На втором Clause изучал ИТ-инфраструктуру жертвы, чтобы найти, где хранятся самые ценные данные. Затем он искал слабые места в системе безопасности, собирал логины и пароли, создавал бекдоры. А в конце еще и писал документацию «проекта» с описанием инфраструктуры и украденными доступами. Интересно, что иногда он галлюцинировал и просто выдумывал эти доступы. Все это — с минимальным участием человека:

В целом злоумышленники смогли переложить на ИИ 80–90% всей кампании, участие человека требовались лишь эпизодически (для принятия 4–6 ключевых решений на каждую кампанию).

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

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

Как когнитивные искажения убили стартап
Вы когда-нибудь слышали про приложение Takkle?

Скорее всего, нет. Это была американская социальная сеть со спортивным уклоном. Takkle давно схлопнулась, и от нее остались только старые аккаунты в Twitter и на Youtube. Но ее недолгая история довольно любопытна.

Что случилось с Takkle, и почему это должно быть интересно?
По воспоминаниям бывшего VP по инжинирингу, одна из причин провала — это неудачное решение CTO еще на этапе разработки. Старый СТО уволился, а новый, пришедший ему на смену, сказал, что PHP никуда не годится и надо срочно все переписывать на Perl. Это был опытный специалист с серьезным резюме, который провел анализ, привел аргументы и в итоге всех убедил.

💬 Плюсом перехода стало то, что команда создала действительно выдающийся проект на Perl, которым можно гордиться. Минусами стало то, что им пришлось нанять больше людей в команду, расходы выросли, а разработка затянулась. За это время их главный конкурент, который принадлежит признанной экстремистской организации, окончательно захватил рынок. Хотя Takkle все же запустилась и какое-то время просуществовала, наверстать упущенное она так и не могла.

Сейчас сложно судить, какой могла бы быть ее судьба. Может быть, она точно так же канула бы в Лету через пару лет, а может, смогла бы найти свою нишу и вырасти во что-то большее.

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

(Ир)рациональный выбор
Решение нового СТО Takkle казалось очень даже рациональным и обоснованным: он проанализировал плюсы и минусы и даже провел презентацию. Но все эти телодвижения нужны были не для того, чтобы реально разобраться в вопросе, а чтобы обосновать уже принятое решение.

💬 То есть СТО и не думал серьезно сравнивать PHP и Perl. Он уже решил, что надо переходить на Perl, и просто хотел перетянуть на свою сторону остальных.

Такая преданность ЯП или тулу (например, БД, BI-системе и так далее) у некоторых специалистов превращается в когнитивное искажение. Они уверенны, что их выбор самый лучший и оптимальный, и даже не рассматривают альтернативы. Это мешает принимать решения рационально и может дорого обойтись компании — как это было с Takkle.

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

А что вы думаете? Сталкивались с похожими кейсами?