Завершился Метамаркетинг-21
Посмотрел пару интересных выступлений, жаль не попал на Рому Бунина, говорят, было круче `marvel` 🤘
Саша Михайлов заприметил ламповые объявления - предложения работы, кажется, это действительно из прошлого, как письма писать😉
Кому интересно разбираем пирожки🥐🥯
Посмотрел пару интересных выступлений, жаль не попал на Рому Бунина, говорят, было круче `marvel` 🤘
Саша Михайлов заприметил ламповые объявления - предложения работы, кажется, это действительно из прошлого, как письма писать😉
Кому интересно разбираем пирожки🥐🥯
Forwarded from data будни (Саша Михайлов)
ламповые объявления о работе с Матемаркетинга
кажется, это не попало в официальные трансляции) выложу сюда часть, чтобы добро не продпало
кажется, это не попало в официальные трансляции) выложу сюда часть, чтобы добро не продпало
Audio
Иногда приятно, когда ваш любимый
Как сказал DS-коллега, после этого кода я уже никогда не буду прежним:
```
```
А пока вам новогоднего настроения👇🔊
jupyter-notebook издаёт любимый звук по окончании расчетов, вот ловите как можно это сделать - https://musicinformationretrieval.com/ipython_audio.htmlКак сказал DS-коллега, после этого кода я уже никогда не буду прежним:
```
import IPython.display as ipd
beep = np.sin(2*np.pi*400*np.arange(10000)/10000)
def end_sound():
return ipd.Audio(beep, rate=10000, autoplay=True)```
А пока вам новогоднего настроения👇🔊
Правильно говорят: сходи посмотри (а-ля наберись опыта), а потом решение принимай 👌
Иногда от такого способа получается потраченное время, но нам привычно думать, что время потрачено впустую, если нет положительного результата (читай нам понравилось, мы в восторге, у нас больше зп и тд..), но знание того что тебе неинтересно, тоже положительно, ибо сокращает поиск как минимум в два раза (а бинарное дерево поиска не самое худшее).
По этой причине у меня сформировались два вектора развития:
1⃣ Python Developer (Python, Django, Flask...)
2⃣ Data Engineer (SQL, ETL /Elt, Airflow и вот это вот всё 😉)
Меня можно отнести к Python evangelist, ну уж очень нравится мне язык, привет змейка 🐍
Среди прочих интересных вещей которые были на курсе Яндекс.Практикум Аналитик данных познакомился с фреймворком Dash, симбиоз Python + Flask + Plotly, отличный инструмент для быстрой разработки не только дашбордов. Со временем прокачался в сим инструменте, да так, что и в работе использую (разработал сервис для разметки данных по одному из проектов) и для собственных проектов (погодный дашборд, сервис для EDA, а об одном из будущих мы ещё поговорим).
В общем очаровал меня этот фреймфорк, а сегодня узнал еще об одном - streamlit. Посмотрел сайт, почитал - достойный тул.
Это я всё к чему, если вы хотите попробовать свои силы в разработке или вам нужен некий сервис
Иногда от такого способа получается потраченное время, но нам привычно думать, что время потрачено впустую, если нет положительного результата (читай нам понравилось, мы в восторге, у нас больше зп и тд..), но знание того что тебе неинтересно, тоже положительно, ибо сокращает поиск как минимум в два раза (а бинарное дерево поиска не самое худшее).
По этой причине у меня сформировались два вектора развития:
1⃣ Python Developer (Python, Django, Flask...)
2⃣ Data Engineer (SQL, ETL /Elt, Airflow и вот это вот всё 😉)
Меня можно отнести к Python evangelist, ну уж очень нравится мне язык, привет змейка 🐍
Среди прочих интересных вещей которые были на курсе Яндекс.Практикум Аналитик данных познакомился с фреймворком Dash, симбиоз Python + Flask + Plotly, отличный инструмент для быстрой разработки не только дашбордов. Со временем прокачался в сим инструменте, да так, что и в работе использую (разработал сервис для разметки данных по одному из проектов) и для собственных проектов (погодный дашборд, сервис для EDA, а об одном из будущих мы ещё поговорим).
В общем очаровал меня этот фреймфорк, а сегодня узнал еще об одном - streamlit. Посмотрел сайт, почитал - достойный тул.
Это я всё к чему, если вы хотите попробовать свои силы в разработке или вам нужен некий сервис
вот прям щас, а готового нет, и нет времени на изучение монстров Flask\Django (хотя у них есть свои плюшки), то можете смело смотреть в сторону Dash, streamlit или аналогичных (если о таких знаете, кидайте в комменты), почувствуете себя настоящим разработчиком и принесете пользу себе или команде😎Plotly
Dash Documentation & User Guide | Plotly
Plotly Dash User Guide & Documentation
На заре изучения Python (чего греха таить и сейчас иногда) пользовался отличным сайтом - https://pythontutor.com/visualize.html#mode=edit
Он позволяет визуализировать как работает код, что творится с переменными - позволяет лучше разобраться в работе твоего кода.
Для любимой библиотеки Pandas тоже нашёлся такой инструмент, теперь вы будите лучше понимать почему вы получили именно такой результат, куда делись данные и откуда взялись наны😜
Ловите и используйте https://pandastutor.com/index.html
Он позволяет визуализировать как работает код, что творится с переменными - позволяет лучше разобраться в работе твоего кода.
Для любимой библиотеки Pandas тоже нашёлся такой инструмент, теперь вы будите лучше понимать почему вы получили именно такой результат, куда делись данные и откуда взялись наны😜
Ловите и используйте https://pandastutor.com/index.html
У каждого, думаю, наберётся стопка вкладок с интересными статьями или вебинарами - хорошего контента много и естественно не успеваешь все переваривать.
В последнее время взял себя в руки и периодически просматриваю интересующие вещи (думаю будет несколько полезных конспектов🙃). Одним из таких источников является Moscow Python Podcast - выпуск Docs as Code - документация как код. Вообще я сторонник всего структурированного и что можно версионировать (привет git), поэтому тема была интересна.
Прозвучало несколько подходов:
- без документации 🤷♂️
- дока в Jira/Notion/Confluence...
- дока рядом с кодом
Соображений было много, но кажется ребята сошлись на одной мысли - лучше отсутствие доки, чем её неконсистентная версия, тк создаёт накладные ментальные расходы.
Наличие Docs as Code, а особенно когда интегрировано с CI/CD - также создаёт накладные расходы, мало пофиксить код, система требует пофиксить доку, но если ты не знаешь где, что и как (привет 234 markdown файла), то оказываешься в ступоре.
Вот вам тезисы:
1️⃣ Писать доку - хорошее правило
2️⃣ Пишешь доку - поддерживай
3️⃣ Если не поддерживаешь - лучше не пиши🤷♂️
4️⃣ На каком языке - английский vs русский - выбор скорее зависит от команды\продукта (если есть мждународный рынок лучше английский)
5️⃣ Без доки вход новых сотрудников усложняется
Гость программы рассказал про оригинальную методологию разработки - Literate Programming .
Написание программного кода как прозы - не знаю насколько идея работоспособна, но заслуживает внимание своей оригинальностью 😉
Вывод можно извлечь такой:
📍Принимать решение о документации надо в начале (сколько, где и как)
📍И можете оставлять нецензуршину - так веселее😉
В последнее время взял себя в руки и периодически просматриваю интересующие вещи (думаю будет несколько полезных конспектов🙃). Одним из таких источников является Moscow Python Podcast - выпуск Docs as Code - документация как код. Вообще я сторонник всего структурированного и что можно версионировать (привет git), поэтому тема была интересна.
Прозвучало несколько подходов:
- без документации 🤷♂️
- дока в Jira/Notion/Confluence...
- дока рядом с кодом
Соображений было много, но кажется ребята сошлись на одной мысли - лучше отсутствие доки, чем её неконсистентная версия, тк создаёт накладные ментальные расходы.
Наличие Docs as Code, а особенно когда интегрировано с CI/CD - также создаёт накладные расходы, мало пофиксить код, система требует пофиксить доку, но если ты не знаешь где, что и как (привет 234 markdown файла), то оказываешься в ступоре.
Вот вам тезисы:
1️⃣ Писать доку - хорошее правило
2️⃣ Пишешь доку - поддерживай
3️⃣ Если не поддерживаешь - лучше не пиши🤷♂️
4️⃣ На каком языке - английский vs русский - выбор скорее зависит от команды\продукта (если есть мждународный рынок лучше английский)
5️⃣ Без доки вход новых сотрудников усложняется
Гость программы рассказал про оригинальную методологию разработки - Literate Programming .
Написание программного кода как прозы - не знаю насколько идея работоспособна, но заслуживает внимание своей оригинальностью 😉
Вывод можно извлечь такой:
📍Принимать решение о документации надо в начале (сколько, где и как)
📍И можете оставлять нецензуршину - так веселее😉
Forwarded from Data-comics
Круговая или пироговая диаграмма (Пай-чарт)
Пай-чарт — парень хозяйственный, он интересуется бизнесом, но главная его страсть — готовка! У него не очень хорошее зрение, и сравнивать данные на глаз у него получается плохо, зато он очень наглядно может показать, сколько кусков пирога осталось в тарелке! Он опасается 3D, потому что уверен, что оно его жутко полнит. Отдельной же слабостью Пай-чарта является любовь к небольшим компаниям.
Круговая диаграмма подходит, чтобы показать, как части целого соотносятся друг с другом и с целым, но эту диаграмму надо применять осторожно.
В идеале на пай-чарте можно отразить 2–4 доли целого, отсортировав их по убыванию, начиная от «полудня» по часовой стрелке.
Мелкие доли лучше объединить в «Прочее» и разместить в конце.
Легенду не стоит убирать далеко, лучше подписать значение показателя и названия категорий прямо около секторов.
Эффекты: градиент, тени и 3D — губительны для Пай-чарта.
Не пытайтесь кодировать в пай-чарте динамику или сравнение элементов.
#диаграммки
Пай-чарт — парень хозяйственный, он интересуется бизнесом, но главная его страсть — готовка! У него не очень хорошее зрение, и сравнивать данные на глаз у него получается плохо, зато он очень наглядно может показать, сколько кусков пирога осталось в тарелке! Он опасается 3D, потому что уверен, что оно его жутко полнит. Отдельной же слабостью Пай-чарта является любовь к небольшим компаниям.
Круговая диаграмма подходит, чтобы показать, как части целого соотносятся друг с другом и с целым, но эту диаграмму надо применять осторожно.
В идеале на пай-чарте можно отразить 2–4 доли целого, отсортировав их по убыванию, начиная от «полудня» по часовой стрелке.
Мелкие доли лучше объединить в «Прочее» и разместить в конце.
Легенду не стоит убирать далеко, лучше подписать значение показателя и названия категорий прямо около секторов.
Эффекты: градиент, тени и 3D — губительны для Пай-чарта.
Не пытайтесь кодировать в пай-чарте динамику или сравнение элементов.
#диаграммки