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

Преобразования сами по себе стандартные: фильтрация, агрегация, сортировка. Можно взять написать все эти операции с помощью pandas к уже имеющемуся датафрейму.

Но мне так стало лень писать несколько строк кода на python, что для меня было проще написать всю логику в одном select запросе на sql 😁
Вы спросите

"нафига так делать???" чтобы применить sql данные нужно положить в базу данных

Нет, точнее не всегда) Данные остались в том же датафрейме, а обработку я сделал с помощью pandasql.

Простой пример применения и сравнения pandas VS pandasql 👇

import pandas as pd 
from pandasql import sqldf

data = {
    'product_id': [1, 2, 1, 3, 2, 3, 1],
    'sale_date': ['2023-01-01', '2023-01-02', '2023-01-03', '2023-01-01', '2023-01-02', '2023-01-03', '2023-01-04'],
    'amount': [100, 200, 150, 300, 250, 350, 400]
}

df = pd.DataFrame(data)

# логика с pandas (фильтруем по датам, группируем по product_id, считаем агрегат суммы по полю amount и сортируем по нему же)
result_df = (
    df[df['sale_date'].between('2023-01-02', '2023-01-03')]
    .groupby('product_id', as_index=False)['amount']
    .sum()
    .sort_values(by='amount', ascending=False)
)

# или применяя sqldf
query = """
    SELECT product_id, SUM(amount) as total_amount
    FROM df
    WHERE sale_date BETWEEN '2023-01-02' AND '2023-01-03'
    GROUP BY product_id
    ORDER BY total_amount DESC
"""

sql_result = sqldf(query, globals())

Я на работе настолько привык крутить все данные с помощью SQL, что в голове любые преобразования я продумываю на логике sql-запросов, а потом если все таки нужно могу переложить это на python скрипты.

Это как с разговорными языками. Если например переезжаете в другую страну и начинаете разговаривать/писать/слушать на другом языке, то у вас мозг со временем начинает мыслить на этом же языке. У меня так было с английским 🇬🇧, когда учеба и работа была полностью на английском, при этом жил в Москве, но все равно замечал что формулирую предложения сначала на английском, а потом уже осознаю что можно на русском)

P.S. sqldf применяет диалект SQLite, поэтому можно использовать все функции которые доступны для этой базы.

👍 если узнали новенькое для себя из поста

Опыт 🟰Насмотренность

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

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

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

Про насмотренность
Но я задумался, что опыта на каком-то уровне может не хватать или опыт может быть не совсем правильным/релевантным/эффективным.
Ведь задумайтесь, в одной компании ту самую задачу А все решали инструментом В, а в другой компании эту же задачу А решают другие люди, но инструментами С, D и E. И вполне возможно что твой опыт с вариантом В не самый эффективный, но исходя из опыта ты знаком только с ним и можешь даже не задумываться о том, что есть другое.

Для себя насмотренность я понимаю как "узнать, как решают одну и ту же задачу разными вариантами/подходами/инструментами другие компании/специалисты". Важно понимать, что насмотренность отличается от опыта тем, что ты можешь только посмотреть вариант решения, но не применить его, тем самым не преобразовав это в опыт.

🔎 Насмотренность - знаешь как решать разными способами, опираясь на знания и опыт других, но мог не применять эти знания. Если применил, то получил свой опыт.

🔎 Опыт - прошел путь решения сам или путем заимствования другого опыта.

Мне кажется, что насмотренность более важна для специалистов синьерного уровня, и для этого есть несколько причин:
1️⃣ есть уже наработанный свой опыт и его можно сравнивать с другим опытом через насмотренность. (Типа "я знаю как решить эту задачу и решал ее много раз, но хочу узнать как ее решали другие и сравнить свой опыт)
2️⃣ синьеры как правило являются наставниками для более младших специалистов. и лучше будет сразу в наставничестве давать более широкий опыт: "можно сделать так, а можно иначе, а в другой компании ребята делают так и можешь также попробовать"
3️⃣ опытные специалисты могут быть драйверами роста, внедряя (или пытаясь внедрить) лучшие практики с рынка. а как увидеть эти практики - с помощью насмотренности.
4️⃣ появляется своя команда и часть задач выполняется не твоими руками, а руками твоих коллег. ты можешь повлиять на результат, но не своими руками, а через передачу знаний: "смотри, можем попробовать изобрести велосипед и получить свой опыт, а можем попробовать решить как ребята на конференции рассказывали - посмотрел их решение и предложил тебе попробовать также сделать".

Финализирую:
🔹если джун - нарабатывай собственный и перенимай опыт от своих наставников
🔹если есть базовый опыт - качай насмотренность, как то же самое делают на рынке другие спецы

Делай свои sql запросы слаще!

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

Несколько примеров из SQL 👇

BETWEEN - конструкция для обозначения диапазона значений вместо конструкции с применением AND и знаков неравенства

—синтаксический сахар
WHERE price BETWEEN 10 AND 30 

—прямая логика выражения для планировщика запроса будет такая
WHERE price >= 10 AND price <= 30 

IN - конструкция для перечисления множества значений. Но для планировщика это значения с условиям оператора OR

—синтаксический сахар
WHERE customer_id IN (5, 7, 12) 

—логика для планировщика
WHERE customer_id = 5 OR customer_id = 7 OR customer_id = 12

CTE (общие табличные выражения) тоже можно отнести к синтаксическому сахару. они реально очень упрощают чтение запросов, но при этом функционал sql позволяет работать и без их использования, обходясь подзапросами.

Можете кстати проверить разные конструкции синтаксического сахара через план запроса и посмотреть во что они преобразуются 😉

Знали про само понятие как "синтаксический сахар" раньше?
👍 - знал
🤓 - узнал сейчас