Я ещё и женщина, то есть и репродуктивный период короткий.
Комбо собрала получается?

#мемы

Богу помолился - mvp появился (с) коллега на работе

#мемы

Ор выше гор.
Аж пожалела, что в прошлом году не приняла оффер indrive.

Даже Илон Маск в шоке

Илон Маск с нами постит мемы про то, что парни не спят, парни мониторят ситуацию с "переворотом Вагнера".

#трудовыебудни

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

Нет, конечно, про базовую проверку на типы данных/null/объем данных сложно забыть. Но вот с бизнес-смыслом иногда бывает косяк.

А теперь расскажу о том, как это выглядит на практике (по мотивам задачи у меня на работе).
Представьте ситуацию: ваша компания/команда занимается аналитикой данных. Вы высылаете требования заказчику о формате передаваемых вам данных, где четко прописано, что в необходимой выгрузке конкретно вот это поле должно отвечать за что-то. У вас при этом под эту логику заточен расчет какого-то агрегата.
И вот вы льете данные, доверяя заказчику (ну, вы же скинули требования, там все четко написано, какие проблемы могут быть).
Данные залиты, базовые дашборды с метриками подняты и вы довольные сидите курите бамбук пьете кофеёк.

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

И вот вы на батискафе (главное, чтобы это был не «Титан») совершаете погружение в пучину данных.
Начинаете проверять и понимаете, что в поле записано совершенно другое значение (не то, которое вы прописали в тербованиях заказчику). Неприятно очень знаете ли. Все это время и ваша команда, и заказчик смотрели на невалидные цифры.

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

#трудовыебудни

Я вот все сокрушалась по поводу факапа с бизнес-логикой в данных мол да как так, на ровном месте прозевать ошибку, а потом вспомнила историю из книги «Аналитическая культура»: агентство NASA потеряло орбитальныи‌ аппарат по исследованию Марса стоимостью 125 млн долл. из-за того, что команда технических специалистов корпорации Lockheed Martin (разработавшая и собравшая аппарат для NASA) использовала при расчетах английские единицы измерения [фунт, дюйм, фут], в то время как специалисты самого агентства пользовались более привычнои‌ метрическои‌ системои‌ для управления аппаратом.


хехе
http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/

#трудовыебудни

Личный бренд

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

Основные тезисы:
(порой очень очевидные, но, видимо, пока письменно не зафиксируешь - не запомнишь)

Личный бренд бывает внутренний (в пределах своей компании) и внешний.

Очень важно рассказывать о том, что ты делаешь. Можно проделать крутую работу и получить классный результат, но из-за того, что его не видно окружающим, складывается впечатление, что ничего не происходит. И не нужно бояться себя проявлять. Да, всегда будут люди в 1000 раз лучше тебя, но это вообще не должно быть проблемой.
Какие плюшки от личного бренда:
1) нетворк, инсайты. Когда начинаешь делать проект с нуля, но знаешь, что что-то подобное делали в других компаниях, то можно напрямую пингануть нужного человека.
2) можно делать какие-то совместные движухи
Качаешь личный бренд - > качаешь бренд компании. Это взаимовыгодная история.

Как работать над своим брендом
1) начинаем с цели.
Для чего тебе нужен личный бренд? Просто чтобы знали - это не ответ.
Надо именно проанализировать варианты и выбрать в какую сторону двигаться. Например, нетворкинг - одно направление, монетизация и поаышение дохода - совершенно другая история.
2) где развиваться?
Заход через тг - мягкий заход. Визитная карточка, простая история, всё понятно. Можно писать про себя, делиться реальными кейсами и тд.
3) аудитория.
Привлечение своих друзей и тд. Первая тысяча - всегда тяжело. Нужно вкладываться, дальше уже намного проще и рост органический.
4) выступления. На презентациях в слайдах можно указать мол вот я тут веду канал, подписывайтесь, ставьте лайки:)

Как начать выступать:
1) курсы часто проводят ивенты/митапы, куда очень легко залететь
2) писать статейки во вне (Vc, medium, хабр)

Я сама активненько слежу за вот этими людьми:
- Аня Подображных (продакт)
- Валерий Бабушкин (крутой ds, формировал data-driven культуру в x5)
- Виктор Кантор (тот самый с курсов по ds на курсере)
- Анатолий Карпов (легендарный курс на степике по основам статистики и основатель школы ds)
- Дмитрий Аношин (курс на youtube DataLearn, путь от завода до Амазона)
——————————————
Видосики для дегродства:
- Frying Pan (https://www.youtube.com/@FryingPan)
- Joma Tech (https://www.youtube.com/@jomaoppa)

Подкаст: [https://music.yandex.ru/album/24718255/track/114192648]

#карьера

Если достаточно долго мучить данные, они признаются [в чем угодно] (c) Рональд Круз

У меня память как у рыбки, поэтому стараюсь вести конспекты.
Дочитала на днях книгу Карла Андерсона «Аналитическая культура».
Эта ĸнига посвящена двум основным вопросам:
1) что означает для ĸомпании управление на основе данных?
2) ĸаĸ ĸомпания может ĸ нему прийти?
#книги

Недавно меня свитчнули на роль ds, так что решаемые задачи сильно поменялись. Мне такие перемены нравятся, в далёком 2018 году я как раз и начинала свой карьерный путь в качестве стажера ds.
Так вот текущая задача посвящена интересному эффекту в ритейле - каннибализации.

Каннибализация
Товары, обладающие схожими характеристиками, замещают друг друга. Спрос одного уменьшает продажи другого, то есть один товар "съедает" своего сородича.

Чем хорош эффект каннибализации:
1. У покупателей всегда есть выбор
2. Если вдруг в супермаркете один товар закончился, его заменит аналог

Чем плох эффект каннибализации:
1. Торговые полки занимает никому ненужный товар.
2. Пропадают деньги компании, которые потратились на закупку ненужного товара.
3. Менеджеры, логисты, грузчики, мерчендайзеры и продавцы зря потратили свои ресуры.

В большинстве случаев каннибализация не является преднамеренной и маркетологи хотят избежать этого, так как их цель все же привлечь новую клиентскую базу на новый продукт, а не перекинуть существующих потребителей со старого продукта на новый.
Например, компания «Вимм–Билль–Данн» выпускала всем известное молоко «Домик в деревне». Чуть позже компания добавила еще одно молоко в свой портфель брендов — «Милая Мила». На вкус они не отличались, ценовой сегмент одинаковый, рекламировались тоже примерно одинаково. С точки зрения потребителя они ничем друг от друга не отличались. Но товары начали конкурировать между собой и чтобы прекратить эффект каннибализации завод в конечном итоге перестал выпускать молоко «Милая Мила».

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

Интересное видео на тему каннибализации - https://www.youtube.com/watch?v=2djYDhQG_BM

#трудовыебудни

💻 БД под капотом.
Часть 1

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

⚙️ Основные компоненты БД (Core Components):
Диспетчер процессов. Во многих БД имеется пул процессов/потоков, которыми нужно управлять. Причём в погоне за производительностью некоторые БД используют свои собственные потоки, а не предоставляемые ОС.
Диспетчер сети. Пропускная способность сети имеет большое значение, особенно для распределённых БД.
Диспетчер файловой системы. Первым «бутылочным горлышком» любой БД является производительность дисковой подсистемы. Поэтому очень важно иметь диспетчер, который идеально работает с файловой системой ОС или даже заменяет её.
Диспетчер памяти. Чтобы избежать эпичных зависаний при чтении или записи на диск, требуется большое количество оперативной памяти. Но когда её много, вам неизбежно потребуется эффективный диспетчер памяти. Особенно когда много одновременных запросов, использующих память.
Диспетчер безопасности. Управляет аутентификацией и авторизацией пользователей.
Диспетчер клиентов. Управляет клиентскими соединениями.

🛠 Инструменты (Tools):
Диспетчер резервного копирования. Для сохранения и восстановления базы данных
Диспетчер восстановления. Обеспечивает целостность данных при перезапуске БД после падения.
Диспетчер мониторинга. Занимается протоколированием всех активностей внутри БД и используется для наблюдения за её состоянием.
Диспетчер общего управления. Хранит метаданные (вроде наименований и структуры таблиц) и используется для управления базами, схемами, табличными пространствами и т.д.

📂 Диспетчер запросов (Query Manager):
Парсер запросов. Проверяет их валидность.
Рерайтер запросов. Осуществляет предварительную оптимизацию.
Оптимизатор запросов. Оптимизирует запрос.
Исполнитель запросов. Компилирует и исполняет.

📄 Диспетчер данных (Data Manager):
Диспетчер транзакций. Занимается их обработкой.
Диспетчер кэша. Используется для отправки данных перед использованием и перед записью на диск.
Диспетчер доступа к данным. Управляет доступом к данным в дисковой подсистеме.
#трудовыебудни

Рассмотрим, как БД управляет SQL-запросами в общем виде

Часть 2

1. Диспетчер клиентов.
Когда мы подключаемся к БД:
Диспетчер сначала аутентифицирует вас (проверят логин и пароль), а потом авторизует для использования БД. Эти права доступа определяются вашим DBA. Далее диспетчер проверяет, есть ли доступный процесс (или поток), который может обработать ваш запрос. Также он сверяет, не находится ли база в состоянии высокой нагрузки. Диспетчер может подождать, пока не высвободятся нужные ресурсы. Если период ожидания закончился, а они не высвободились, диспетчер закрывает соединение с сообщением об ошибке. Если же ресурсы имеются, то диспетчер перенаправляет ваш запрос диспетчеру запросов. Поскольку диспетчер клиентов передаёт и получает данные от диспетчера запросов, то он сохраняет их в буфере частями и отправляет клиенту. При возникновении проблемы диспетчер прерывает соединение с каким-то объяснением и высвобождает ресурсы.

2. Диспетчер запросов.
Это сердце БД. Здесь все написанные запросы превращаются в быстроисполняемый код, затем происходит исполнение.
Описанный процесс состоит из нескольких этапов:
Запрос сначала проверяется на валидность (парсится).
Затем он перезаписывается с целью исключения бесполезных операций и предварительной оптимизации.
Далее производится окончательная оптимизация для повышения производительности. После этого запрос трансформируется в план исполнения и доступа к данным.
План компилируется и исполняется.

3. Диспетчер данных.
Диспетчер запросов исполняет запрос и нуждается в данных из таблиц и индексов. Он запрашивает их у диспетчера данных, но тут есть две трудности:
Реляционные БД используют транзакционную модель. Нельзя в конкретный момент времени получить любые желаемые данные, потому что в это время они могут кем-то использоваться/модифицироваться.
Извлечение данных — самая медленная операция в БД. Поэтому диспетчеру данных нужно уметь прогнозировать свою работу, чтобы своевременно заполнять буфер памяти. Как уже не раз говорилось, самым узким местом в БД является дисковая подсистема. Поэтому для увеличения производительности используется диспетчер кэша. Вместо того, чтобы получать данные напрямую от файловой системы, исполнитель запросов обращается за ними к диспетчеру кэша. Тот использует содержащийся в памяти буферный пул, что позволяет радикально увеличить производительность БД. Также большое значение имеет тип накопителей, используемых в дисковой системе.
Однако тут мы сталкиваемся с другой проблемой. Диспетчеру кэша нужно положить данные в память ДО того, как они понадобятся исполнителю запросов. Иначе тому придётся ждать их получения с медленного диска.
Исполнитель запросов знает, какие данные ему понадобятся, поскольку ему известен весь план, то, какие данные содержатся на диске и статистика.
Когда исполнитель обрабатывает первую порцию данных, он просит диспетчер кэша заранее подгрузить следующую порцию. А когда переходит к её обработке, то просит ДК подгрузить третью и подтверждает, что первую порцию можно удалить из кэша.
Диспетчер кэша хранит эти данные в буферном пуле. Он также добавляет к ним сервисную информацию (триггер, latch), чтобы знать нужны ли они ещё в буфере. Нельзя забывать, что буфер ограничен объёмом доступной памяти. То есть для загрузки одних данных нам приходится периодически удалять другие. Заполнение и очистка кэша потребляет часть ресурсов дисковой подсистемы и сети. Если у вас есть часто исполняемый запрос, то было бы контрпродуктивно каждый раз загружать и очищать используемые им данные. Для решения данной проблемы в современных БД используется стратегия замены буфера. Большинство БД (по крайне мере, SQL Server, MySQL, Oracle и DB2) используют для этого алгоритм LRU (Least Recently Used). Он предназначен для поддержания в кэше тех данных, которые недавно использовались, а значит велика вероятность, что они могут понадобиться снова.
БД так же использует и буферы записи, которые накапливают данные и сбрасывают на диск порциями, вместо последовательной записи. Это позволяет экономить операции ввода/вывода.

#трудовыебудни

Кошечка деликатно намекает, что пора сворачивать курсики и ложиться спатки 🥰

Хороший список. Я почти такие же вопросы задавала в свое время. Ну, кроме вопросов про атмосферу и что не нравится в компании, так как никогда не услышишь правдивого ответа.
Я еще прям уточняю название страховой и программу ДМС в деталях, так как любитель походить по врачам. В банке у меня был СОГАЗ и это был кайф, я делала кучу обследований в очень хорошей клинике и мне все покрыли.
Про структуру зп обычно пишут в оффере, в плане оклад + размер бонуса, но лучше тоже уточнять какие критерии выплат бонусов.
А вопрос про переработки ой как актуален. Когда-то на собесе меня прям спросили про отношение к переработкам и у меня сразу возник красный флажок.