Прикольная статья про то, что дэшборды уже мертвы, а будущее за блокнотами по типу Jupyter notebook💪

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

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

Я совсем недавно тоже об этом всем думала, делая очередной дэшборд, которые уже просто путаются в глазах. Блокноты реально прикольная штука, но очень не универсальная. Основное, наверное, упирается в язык программирования и в то, что зачастую заказчикам этих дэшбордов важен результат, а не процесс. Поэтому все еще верю, что дэшборды штука важная и нужная, и она помогает именно communicate data, а блокноты стали бы отличным вариантом для каких-то небольших задач, потому что еще непонятно, что хуже: дэшборд с кучей страниц или блокнот с таким же количеством.

Ну и в конце статьи немножко рекламы сервиса Count (выглядит на картинках оч красиво), если кто-то пробовал, напишите, как вам, буду рада)


https://towardsdatascience.com/dashboards-are-dead-b9f12eeb2ad2

ссылку на канал ^ нашёл в подборке Ромы Бунина, там есть ещё:
https://revealthedata.com/blog/all/dataviz-channels/

Продвинутый пайтон для аналитики?
Или как же разобраться с бардаком в своих юпитер-блокнотах?

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

В результате через полгода такой практики обнаружил себя посреди кодового бардака:

какие-то куски кода я оборачиваю в функции, а что-то остаётся просто в теле программы (или как это будет по-питонячьи?)

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

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

Думал выделить в отдельный модуль общие функции и развивать там. Увидел такое в открытом коде вастрик.клуба — там есть специальная папочка-модуль Common и там всё «общее», что может потребоваться в нескольких местах
https://github.com/vas3k/vas3k.club/tree/master/common

кажется, если углубиться в пайтон, то там ещё много таких приёмников, которые могли бы сильно упростить жизнь аналитикам (и тем, кто потом релизит их код на прод!).

решил углубить свои знания в питоне — уделю этому сентябрь. Пробую сервис от JetBrains: маленькие кусочки теории, обложенные практическими задачами.
https://hyperskill.org/

а вот Фёдор Борщёв для изучения питона рекомендует прочитать от корки до корки Марка Лутца и сделать все «домашки» оттуда (пост и подкаст)

#python

нужны ли алгоритмы программистам?

холиварный выпуск Moscow Python подкаста: Григорий Петров и Злата Обуховская накидывали на вентилятор, направленный на Асю Воронцову из Яндекса.

Тезис №1: знание алгоритмов нужны только тем, кто работает с высоконагруженными сервисами, где важна эффективности. Типа ядра Линукса или поисковика Яндекса. (важно отметить: даже в самом Яндексе не все работают с хайлоадом)

Тезис №2: внедрение алгоритмов в код ухудшает его читаемость. Это важно, т.к. код больше читается, чем пишется.

Тезис №3: времязатраты на написание эффективного кода не всегда окупается. Можно потратить две недели на код, который даёт всего 5% в сравнении с уже готовой библиотекой.

Тезис №4: профилировщик — лучший друг программиста. Это снимает большинство вопросов с эффективностью. Например, он подскажет, если вдруг код зайдёт в цикл.

Тезис №5: в больших компаниях спрашивают знание алгоритмов (и умение их писать на бумажке) не только ради самого знания, но и просто как ещё один фильтр, чтобы отсеять людей, которые уже приложили усилия и вызубрили редко используемую информацию.

#data_podcast в iTunes и overcast

#python
#algorithms

Software Craftsmanship — рецепт хорошего кода от Григория Петрова
(цитата из подкаста про алгоритмы)

вместо того, чтобы учиться писать на бумажке сортировку Ахо-Корасик,
Григорий предлагает учиться писать код, который потом будет легко читать и поддерживать.

Как можно улучшить свой код:
⁃ писать читаемый код
⁃ рассказывать историю через код
⁃ давать понятные имена идентификаторам
⁃ пользоваться гитом
⁃ включать профилировщик
⁃ настроить себе Continuous Integration

#software_engineering
#python

был удивлён, когда увидел логотип Додо пиццы на техническом митапе. Задался вопросом и кроличья нора привела меня на интересный сайт dodo.dev

Так я узнал про Dodo Engineering.