Иван Фурсов

Если кратко: 0 — это полученные данные. Сколько инопланетян вы видели? Скорее всего, 0. NULL — это неполученные данные. Существуют ли инопланетяне? Это неизвестно. Вот я придумал шутку, сам с нее посмеялся и заинтриговал тех, кто рядом. Если я расскажу и никто не посмеется — результат будет 0 посмеявшихся человек. А если не расскажу… то неизвестно, сколько могло бы посмеяться. Это NULL. В аналитике это база: — среднее от (10, 0, 5) = 5 — среднее от (10, NULL, 5) = 7.5 Разница в 50% просто из-за того, что мы не учли «ничего» или «неизвестно»...

Пару недель назад я переписывал скрипт витрины данных. Нужно было сделать из дашборда, который каждый год приходилось обновлять вручную, дашборд, который будет автоматически подтягивать данные по годам (но об этом подробнее расскажу в другой заметке). Так вот, когда я сделал новый скрипт, то начал сравнивать данные с текущей визуализацией: где-то сходилось, а где-то были расхождения. Сначала я подумал, что где-то ошибся, но странно — много где сходится ведь. В данном проекте происходит миграция с Greenplum на ClickHouse, поэтому есть свои особенности, на которые я изначально и подумал. Одна из...

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

Мозг цепляется за первую полученную информацию и оценивает остальное относительно неё. Например, я смотрю квартиры на Авито. Вижу вариант за 4 млн. Я понимаю, что это дорого, но якорь брошен: теперь любая скидка кажется выгодой. Купив её за 3.8 млн, я буду считать, что сторговался. Но если изучить историю продаж, район и вложения в ремонт, окажется, что реальная цена — 3.3 млн. В итоге я не «сэкономил», а переплатил полмиллиона за чужие фантазии. Со своей оценкой можно обосновать цену продавцу. Если он согласится — это справедливость и экономия. Если нет — ты хотя бы не платишь за чужие иллюзии...

В SQL есть стандартный DISTINCT, который используется так: SELECT DISTINCT names FROM table. Это означает: «Дай мне все УНИКАЛЬНЫЕ имена из таблицы». Представим, что в коробке лежат джинсы, футболки и кепки. Запрос SELECT DISTINCT clothes выдаст по одному экземпляру от каждого вида: одни джинсы, одну футболку и одну кепку. Добавив описательные атрибуты, например, DISTINCT clothes, color мы получим уникальные комбинации вида и цвета.Теперь мы можем достать по одной футболке зеленого и желтого цвета, но нам может попасться хлопковая, кашемировая или шелковая. Если мы хотим достать по одной штуке...

Мне всегда было интересно что-то анализировать, в том числе в психологии. Поэтому я решил изучить «баги» мозга — ментальные искажения. Увидеть проблему — наполовину решить ее. Первое искажение — гиперболическое дисконтирование или, простыми словами: «жертвуем светлым будущим ради сомнительного настоящего». Заключается оно в склонности к неправильной оценке момента. Например: я хочу лечь в 22:00. В 21:00 иду в душ с ощущением: «как раз есть возможность лечь рано», но... я беру с собой телефон. Начинаю искать новые кроссовки для баскетбола, заказывать стельки, думать о разном абстрактном и из душа выхожу уже после 22:00 (а время прошло, вроде бы, незаметно)...

Порядок выполнения запроса в SQL СУБД выполняет запрос не в том порядке, в каком мы его пишем. На днях споткнулся на том, что оконка считала сумму по-разному с HAVING и без него. Был уверен, что WINDOW функции отрабатывают до HAVING, а оказалось, что нет... Сделал небольшую шпаргалку-напоминалку: 1. FROM & JOIN — берем данные ИЗ... 2. WHERE — ГДЕ (фильтруем строки)... 3. GROUP BY — ГРУППИРУЕМ ПО... 4. Агрегатные функции (SUM, MAX и т.д.) — считаем значения внутри групп 5...

Когда данных становится слишком много, стандартные методы JOIN начинают «захлебываться». Планировщик базы данных пытается охватить всё сразу, тратя ресурсы на лишние сканирования, даже если у вас есть индексы. Проблема «Кота Шредингера» Представьте обычный JOIN как закрытый ящик. Чтобы узнать состояние данных внутри, базе часто приходится «разбирать» весь ящик целиком. Если таблица огромная — это долго и дорого. Решение: LATERAL как «щелка в ящике» LATERAL позволяет подзапросу «заглядывать» в таблицу, стоящую слева от него. Это превращает неопределенный поиск в точечные удары...

Мы живем в эпоху погони за цифрами. Всем нужны лайки, охваты и подписчики. Когда-то я занимался музыкой и думал так же. Я нашел формат в TikTok, который «залетел»: одно видео набрало 20 млн просмотров, за ним второе. На меня подписалось 400 тысяч человек. Казалось бы — успех? Нет. Ошибка в проектировании У меня был масштаб, но не было архитектуры. Я масштабировал случайный успех, не продумав, куда этот путь ведет. Это классический пример того, как действие без понимания конечной цели превращается в бессмысленный перерасход ресурсов...

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