Сайт крутится на WordPress. Но самое «мясо» — интерактивные окна уроков — это чистый HTML внутри плагина.

Почему WP. Потому что сайт на работе на WP. Там и основы узнал. До этого был на Джумле. Но это был кошмар.

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

Готово около 30 уроков. От простого «как сложить 2+2» до ВПР и работы с текстом. Денег на этом зарабатывать не планирую, рекламы нет. Делаю чисто ради интереса, диплома и прокачки скиллов.

Просьба: Ребят, сайт еще сырой. У меня глаз замылился, я уже не вижу очевидных косяков. Если вам не сложно, потыкайте палочкой:

Работают ли формулы так, как вы ожидаете? Удобно ли вообще этим пользоваться?

Совмем забыл. Сайт про эксель и понятно что в мобильной версии там особо без мышки и клавиатуры не сделаешь. Так что если решите по тестить то только на ПК. Ведь все пользователи экселя работаю на ПК.

Ссылку оставляю: эксель-тренажер.рф

Буду благодарен за любой фидбек в комментариях. Если найдете баг — пишите, буду править перед защитой, чтобы не опозориться перед комиссией.

Всем спасибо!

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

Бизнес редко приходит с чётким запросом.
Не потому что он глупый или ленивый.
А потому что бизнес живёт ощущениями, а не формулами.

Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".

Это язык боли, а не требований.

И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"

Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"

Когда бизнес не знает, что ему нужно,
аналитик не исполнитель,
аналитик - переводчик.

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

И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.

Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.

Например:

• "Продажи упали" - относительно чего?

• "Конверсия плохая" - на каком этапе?

• "Клиенты уходят" - кто именно и когда?

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

И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.

И да - бывает, что бизнес так и не может сформулировать запрос.

Тогда аналитик делает не отчёт, а гипотезу.

Я предполагаю, что проблема может быть здесь.
Давайте проверим это.

Это нормальная практика.
Гораздо честнее, чем молча строить отчёт "на всякий случай".

Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.

Это точка, где аналитика становится ценностью!

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

1. Взять только оплаченные заказы

2. Посчитать сумму заказов по пользователям

3. Оставить пользователей, у которых сумма больше 10 000

4. Отсортировать по убыванию суммы

Как это выглядит в SQL

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

1. FROM — база берёт таблицу orders

2. WHERE — отфильтровывает только status = 'paid'

3. GROUP BY — группирует строки по user_id

4. SUM(amount) — считает сумму внутри каждой группы

5. HAVING — отбрасывает группы с суммой ≤ 10 000

6. SELECT — формирует финальные колонки

7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

1. Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

• пользователей

• их суммы

• можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

- нет "текущего состояния"
- каждый запрос - это новый расчет
- описываем, что хотим получить
- оптимизатор решает как

Python

- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000

Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

• ширина столбцов не соответствует отображению Excel

• формулы ведут себя по-другому

• форматирование исчезает после конвертации

• производительность падает при увеличении размера файлов

На этом этапе вопрос уже не в том, "Как мне создать файл Excel в Python?"
Он становится "Какую библиотеку мне следует использовать?"
В этой статье сравниваются OpenPyXL, Pandas и Spire.XLS с практической точки зрения автоматизации Excel, акцентируя внимание на том, каково их использование, какие проблемы они хорошо решают и где каждая из них начинает давать сбой.

Обзор трех библиотек

На высоком уровне эти инструменты нацелены на разные нужды:

• Pandas → Обработка данных в первую очередь, Excel как выходной формат

• OpenPyXL → Низкоуровневое управление файлами Excel

• Spire.XLS → Полнофункциональный движок автоматизации Excel

Они пересекаются, но не являются взаимозаменяемыми.

Pandas: Отлично для данных, ограничено для поведения Excel

Pandas часто является первой библиотекой, которую используют разработчики для задач, связанных с Excel.

Преимущества Pandas:

• Очистка и преобразование данных

• Быстрые аналитические рабочие процессы

• Простой экспорт в Excel

Проблемы Pandas:

• Форматирование второстепенно

• Концепции Excel (макеты, стили, формулы) косвенные

• Зависит от внешних движков для поведения Excel

Следующий пример создает небольшой отчет в Excel с базовым форматированием, используя Pandas:

import pandas as pd

data = {

"Product": ["A", "B", "C"],

"Sales": [1200, 900, 1500]

}

df = pd.DataFrame(data)

with pd.ExcelWriter("report.xlsx", engine="xlsxwriter") as writer:

df.to_excel(writer, index=False, sheet_name="Report")

worksheet = writer.sheets["Report"]

worksheet.set_column("A:B", 18)

Этот фрагмент подчеркивает ключевую характеристику Pandas: форматирование Excel возможно, но оно не является родным. Вы по-прежнему думаете в терминах DataFrame, а не документов Excel.

Когда Pandas — правильный выбор:

• Excel — это просто формат доставки

• Отчеты в основном табличные

• Требования к форматированию минимальны

OpenPyXL: Точный контроль, большая сложность

OpenPyXL работает непосредственно с файлами .xlsx и детализирует структуру Excel.

Сильные стороны:

• Полный доступ к ячейкам, листам и стилям

• Нет внешней зависимости от Excel

• Тонкий контроль

Недостатки:

• Бурный код для общих задач

• Ручное управление макетом

• Проблемы с производительностью при больших файлах

Вот типичный пример OpenPyXL, который создает отформатированный файл Excel:

from openpyxl import Workbook

from openpyxl.styles import Font

wb = Workbook()

ws = wb.active

ws.title = "Report"

ws.append(["Product", "Sales"])

ws.append(["A", 1200])

ws.append(["B", 900])

ws.append(["C", 1500])

for cell in ws[1]:

cell.font = Font(bold=True)

ws.column_dimensions["A"].width = 18

ws.column_dimensions["B"].width = 18

wb.save("report.xlsx")

Этот пример демонстрирует явный, низкоуровневый подход OpenPyXL. Вы контролируете все — но вы также управляете всем.

Когда имеет смысл использовать OpenPyXL:

• Небольшие и средние файлы Excel

• Настраиваемые операции на уровне ячеек

• Среды, которые требуют только открытого программного обеспечения

Spire.XLS: Excel как документ

Spire.XLS применяет другой подход, моделируя Excel как документ со структурой и поведением, а не просто набор ячеек.

Что отличает Spire.XLS:

• Высокоуровневые API для форматирования и макета

• Встроенная поддержка формул, диаграмм и изображений

• Надежная конвертация Excel в PDF

• Предсказуемые результаты форматирования

Следующий пример создает тот же отчет, используя Spire.XLS:

from spire.xls import *

workbook = Workbook()

sheet = workbook.Worksheets[0]

sheet.Name = "Report"

sheet.Range["A1"].Text = "Product"

sheet.Range["B1"].Text = "Sales"

sheet.Range["A2"].Text = "A"

sheet.Range["B2"].NumberValue = 1200

sheet.Range["A3"].Text = "B"

sheet.Range["B3"].NumberValue = 900

sheet.Range["A4"].Text = "C"

sheet.Range["B4"].NumberValue = 1500

sheet.Range["A1:B1"].Style.Font.IsBold = True

sheet.AllocatedRange.AutoFitColumns()

workbook.SaveToFile("report.xlsx")

Этот фрагмент иллюстрирует, как Spire.XLS работает с концепциями Excel напрямую — диапазоны, стили и макет обрабатываются на более высоком уровне, что снижает количество ручного кода.

Компромиссы:

• Коммерческая лицензия

• Больший набор функций, чем у легковесных библиотек

Для производственных систем эти компромиссы часто приемлемы.

Сводка сравнения функций

Выбор правильного инструмента на практике

• Используйте Pandas, когда Excel является выходным форматом

• Используйте OpenPyXL, когда вам нужен низкоуровневый контроль

• Используйте Spire.XLS, когда Excel является конечным продуктом

Во многих реальных проектах наилучший подход — это гибридный подход:

• Pandas для подготовки данных

• Spire.XLS для форматирования, макета и доставки

Заключительные мысли

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