Вредные советы. 2. Не пихайте лямбду в переменные

Что не так?
Знаю пару разработчиков, которые как только узнали про лямбда выражения, сразу стали их пихать куда надо и не надо. Это как с регулярными выражениями:

- У нас есть проблема..
- Ее можно решить с помощью регулярных выражений!
- У нас есть две проблемы...

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

Антипаттерн

f = lambda x: 2*x

Код выше присваивает лямбда выражение, которое возвращает удвоенное входящие значение. И это полностью идентично def.

А как надо?

def f(x):
    return 2 * x

В этом случае имя результирующей функции именно f, а не дженерик <lambda>. В этом случае и дебажить проще будет, и один функционал не подменяется другим.


#вредныесоветы

Дата Инженеры vs. Дата Саентисты

Как же я не люблю этот булшит (бомбит настолько, что аж сюда написал): дата инженеры получают меньше, их работа это подносить данные, простые SQL макаки и вот это все. Или, например, как говорит автор вот этого видео: "Я знаю много Дата инженеров, они все недовольны своей работой". Да ну не доволен, уходи заниматься чем-то другим... И если FANG уже решили все свои проблемы с распределенными системами / пайплайнами и вот этим всем (в чем я сильно сомневаюсь, там вечно есть что делать), то нужно помнить, что в мире еще куча компаний, которым нужны инженеры.

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

https://www.youtube.com/watch?v=vmYaAzbv9xk

#пятничныйYoutube

Как стать программистом

Не-не-не. Это не реклама курсов по программированию с гарантией трудоустройства. Честно, если вы решили сменить профессию и рассматриваете курсы по программированию, бегите подальше от тех, кто обещает вам гарантию трудоустройства. Это все маркетинг.

А вот что действительно помогает трудоустроиться - так это работа над собой, над своими проектами, практика -> гайды/книги -> практика -> практика -> повторить. У меня есть знакомый приятель, который работал в институте физики, ему это надоело и он решил сменить направление. Пошел на курсы, поучился, после окончания не бросил и не сложил руки с фразой "Ну все, нанимайте меня", и спустя 8 месяцев он попал в уютную IT-шечку. Когда я ему предложил прийти в подкаст и рассказать свою историю, он ответил: "Ну не, мне нечего рассказывать, я ничего такого не сделал". Наоборот, ты дофига сделал.

Именно такие истории нужно рассказывать. Чтобы люди не боялись приходить в профессию, вне зависимости от пола и возраста и предыдущего опыта. И для того, чтобы поддержать вашу мотивацию, вот вам еще подборка "Как мы стали программистами" от канала @seniorsoftwarevlogger или впечатляющие истории ребят из Lamoda или такое же количество великолепных историй вот в этом треде в твиттере. Но больше всего я люблю подборку основателя FreeCodeCamp Квинси Ларсона "А не слишком ли я стар для этой фигни?"

#пятничныйYoutube

Вредные советы 3. Переопределение встроенных функций

Что не так?
У питончика есть приличное количество встроенных функций, которые доступны в интерпритаторе. Если у вас прям нет дико горящей причины их переопределить, не стоит называть другую функцию также, как встроенную или складировать что-то в переменную с таким именем. Это может вылезти в совсем неожиданном месте (и заметить будет с первого взгляда непросто) или вообще вылетать с ошибкой во время исполнения.

Антипаттерн
Посмотрите на пример ниже, в котором встроенная функция list() превратилась в переменную. Естественно, при попытке создать пустой список, используя встроенную функцию, мы получим ошибку. На таком примере это легко заметить, но когда у вас кодовая база в несколько сотен или тысяч строчек, искать придется долго.

>>> list = [1, 2, 3]
>>> list('my_string')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not callable

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

>>> numbers_list = [1, 2, 3]
>>> list('my_string')
['m', 'y', '_', 's', 't', 'r', 'i', 'n', 'g']

#вредныесоветы

Кто есть кто в этом Дата Caнса

Смешная игра слов с Игрой Престолов. Ладно, посмеялись и хватит. На самом деле, огромное количество компаний сейчас пытаются запрыгнуть на этот hype-train под названием "Data Science". Везде же большие данные, в них куча денег, надо срочно все анализировать и зарабатывать кучу денег. А вот понимания, кто им нужен и в каких количествах - нет. Экспертизы нет же в самом начале, поэтому непонятно, кого брать и кого он позовет за собой.

Тоже самое и с теми, кто приходит в профессию. Разобраться, кто и ем занимается непросто. Можно очень легко оказаться в позиции, когда вы будете делать совсем не свою работу.

Для того, чтобы отличать data analyst, data scientist и data engineer, предлагаю посмотреть прекрасное видео от одного из основателей ODS (Open Data Science) сообщесва - Алексея Натекина

https://www.youtube.com/watch?v=lDkTNURDIaY

#пятничныйYoutube

Вредные советы 4. Порядок исключений
Когда случается исключение, то Питончик ищет в порядке очереди. Первое что подошло, то и выкидывает наверх. То есть, помня про наследование классов, даже если у нас вылетит специфичное исключение, то, наткнувшись первым делом на базывай класс Exception, Питон выдаст его. Сейчас покажу на примере:

Антипаттерн
Ниже написан код, который выдает ZeroDivisionError. И мы даже обернули все это в try/except и нужное исключение прописали. Однако, до него мы никогда не доберемся, потому что ZeroDivisionError это подкласс Exception, и поэтому, когда произойдет ошибка, программа полезет смотреть в ошибки, увидит базовый класс Exception и отдаст его. Все происходит линейно и полное совпадение не нужно. В коде ниже вылетит Exception:

try:
    5 / 0
except Exception as e:
    print("Exception")
except ZeroDivisionError as e:
    print("ZeroDivisionError")

А как надо
А надо от частного к общему: сначала помещаем специфические, потом общие исключения. В таком случае мы не пропускаем детали, сваливая все в общую кучу.

try:
    5 / 0
except ZeroDivisionError as e:
    print("ZeroDivisionError")
except Exception as e:
    print("Exception")

#вредныесоветы

К чему быть готовым на собеседованиях

Я сейчас пеперпыгну почти в самый конец, в момент, когда вы уже готовы ходить по собеседованиям, но еще не начали - для вас сегодняшнее видео.
Это пятничное видео снова все с того же митапа ODS в Яндексе. На нем один из моих нынешних коллег, Валерий Бабушкин, рассказывает про типичные ошибки на собеседованиях.

И, не смотря на то, что часть советов относятся именно к карьере DS, я бы хотел заострить ваше внимание на двух других моментах:
1) Всегда знайте ваши слабые и сильные стороны.
2) Нужно знать, сколько ты хочешь денег и что тебе есть за что их платить.

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

И, конечно же, какое собеседование не проходит без вопросов про зарплаты. Есть очень много всяких техник, чтобы узнать чужую вилку (или она уже может быть известна) или уйти от вопросов про то, сколько вы зарабатываете и сколько вы хотите. Здесь я придерживаюсь следующей позиции: периодически мониторьте рынок, чтобы быть в курсе зарплатных распределений и будьте готовы объяснить, почему вы стоите столько денег, сколько вы просите. Если вы просто пытаетесь закинуть удочку повыше, авось клюнет, ничего хорошего из этого не выйдет.

#пятничныйYoutube

Ссылка на видео

Вредные советы 5. Return при создании объекта

Что не так
__init__ это специальный метод, который автоматически вызывается, когда в памяти резервируется место для объекта. Цель этого метода инициализировать экземпляр класса с его дефолтными значениями. Использование __init__ вместе с return заставляет этот метад делать что-то кроме инициализации объекта. Вся логика должна быть перенесена в отдельное от инициализации место.

Антипаттерн

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height
        self.area = width * height
        return self.area

Метод __init__ не только создает экземпляр класса Rectangle, но и возвращает его площадь. Это нарушает правило "__init__ только для создания".

А как надо?
Нет никакой причины, почему класс Rectangle должен возвращать площадь сразу после создания объекта. Логику необходимо вынести в отдельное место, смотри код ниже:

class Rectangle(object):
    def __init__(self, width, height):
        self.width = width
        self.height = height
        self._area = width * height

    @property
    def area(self):
        return self._area

Обрати внимание, что чтобы использовать декоратор @property нам понадобилось унаследовать Rectangle от object.

#ВредныеСоветы

Правило 10 000 часов

Скорее всего, вы все слышали про это правило: "Чтобы стать мастером-фломастером в чем-то, нужно потратить 10 000 часов на это". Это прям дофига времени, почти 5 лет полноценной работы с 9 до 18. Вот только тут есть маленькая особенность: столько времени нужно, чтобы стать топ 1% в чем-то. Но такие rockstar разработчики и инженеры нужны 1-2 на сотню человек в компании.

А в общем и целом компании нужны адекватные специалисты, которые понимают основы и технологии, а также способны разобраться в чем-то новом. Очень маленькому проценту людей приходится решать такие задачи, которые никто до них не делал и ответ не найти в Google или StackOverflow. Поэтому если вы сталкиваетесь с чем-то новым, скорее всего это уже известное и где-то про это даже писали, а может быть и выступали с этим на конференции. Поэтому вам осталось потратить немного времени, чтобы найти и изучить эту область до "нормального" уровня.

Так вот, этот нормальный уровень достигается примерно за 20 часов сфокусированной работы. Конечно, Kaggle-грандмастером за 20 часов вы не станете, если только не сжульничать, но начнете уже более-менее разбираться в теме и не совсем плавать в облаках, когда кто-то будет говорить про случайный лес.

Так вот, автор этого прекрасного TED видео (внимание, английский язык) приводит простые 4 правила:

1) Разбиваем большую задачу на мелкие и фокусируемся на той, что даст нам наибольший эффект
2) Не прокрастинируем, набирая кучу всего вокруг. Берем столько, чтобы было достаточно начать делать.
3) Убираем все преграды для прокрастинации
4) Обещаем себе погрузиться в это как минимум на 20 часов

Все просто и легко. Особенно мне нравится пример, который приводит автор касательно п. 2: "Я хочу научиться программировать! Поэтому я подписался на 8 пабликов по программированию, 6 ютуб каналов, скачал 20 книг из Телеграма, сейчас все это просмотрю и смогу кодить". Да вот нифига! Чтобы научиться программировать, надо программировать. Вот и весь секрет успеха.

#пятничныйYoutube
https://www.youtube.com/watch?v=5MgBikgcWnY

Вредные советы 6. Геттеры и Сеттеры, прям как в Java

Открою страшную тайну: я начинал свой путь в программировании с Java, даже кучку книжек накупил и занимался на одном известном ресурсе с инопланетянами по Java программированию. Но мне Java не понравилась своей говорливостью (verbose), поэтому я переключился на более простой в чтении язык - Python.
Питончик это не джавка (с). Если вам нужно присвоить или получить аттрибут класса или объекта, просто сделайте это. А если вам нужно перед этим еще произвести какую-то логику - используйте декоратор. Давайте не превращать Python в Java, используя геттеры (метод для получения) и сеттеры (метод для присваивания).

Антипаттерн
В Java вполне себе типичное явление для всех аттрибутов класса, которые вы хотите выставить наружу, создавать геттеры и сеттеры. Так вот, в Python этого делать не надо.

class Square(object):
    def __init__(self, length):
        self._length = length
    
    # Java стиль
    def get_length(self):
        return self._length

    # Java стиль
    def set_length(self, length):
        self._length = length

r = Square(5)
r.get_length()
r.set_length(6)

А как надо?
Берем и обращаемся.
Обратите внимание, что нижних подчеркиваний перед аттрибутами нет (смотри #вредныесоветы 1. Защищенные аттрибуты).

class Square(object):
    def __init__(self, length):
        self.length = length

r = Square(5)
r.length
r.length = 6

Использование @property декораторов
Когда мы используем "защищенные" аттрибуты класса, просто так наружу показать мы их не можем, поэтому мы используем @property декораторы, чтобы воссоздать функциональность геттеров и сеттеров.

class Square(object):
    def __init__(self, length):
        self._length = length

    @property
    def length(self):
        return self._length

    @length.setter
    def length(self, value):
        self._length = value

    @length.deleter
    def length(self):
        del self._length

r = Square(5)
r.length  # автоматически вызывается геттер
r.length = 6  # автоматически вызывается сеттер

#вредныесоветы

Что я хотел бы знать об IT в 20 лет

Я очень люблю продукт Максима Дорофеева. И да, я знаю, что часть идей не уникальна, часть адаптирована и вот это все. Однако мне удалось с ним общаться лично некоторое количество времени и это потрясающей энергии человек. Поэтому вне зависимости от того, какую тему он рассказывает, ты все равно находишь что-то интересное и полезное для себя. Сегодня очень интересная и забавная лекция (причем из очень давних): Что я хотел бы знать об IT в 20 лет. Подойдет всем, как и прожженым айтишникам, так и тем, кто только начинает свой путь.

https://www.youtube.com/watch?v=fY8hhOv7lmE

#пятничныйYoutube

Почему я ненавижу Jupyter Notebook

На одном из митапов проскочило очень интересное видео, которое я очень хотел бы показать всем сатанистам дата саентистам. Оно о том, почему их модельки так долго доезжают до прода. Причина в этом проста: Jupyter Notebook, крайне опасный враг. Вам очень повезет, если ваши DS написали свой код, в котором все ячейки надо выполнять последовательно. Но если нет....

На самом деле, конечно, Jupyter штука хорошая, чтобы быстро что-то поизучать, прототипировать, набросать или in-line графики показать. Но не более..

Кстати, сам доклад происходит на JupyterCon (конференция по Jupyter Notebook 😂), а докладчик - автор одной из самых популярных книг по DS - "Data Science from Scratch", с птичкой.

https://www.youtube.com/watch?v=7jiPeIFXb6U

#пятничныйYoutube

DE or DIE #1

Ребята из Dodo-пиццы провели на этой неделе крайне интересный митапчик: "DE or DIE" про то, кто такие data engineers, чем они занимаются, как в эту профессию приходят и как уходят. И оба доклада мне показались крайне интересными и полезными, особенно для начинающих.
Особенно хочется сказать про доклад Яндекса - в одном слайде крайне просто и наглядно пояснить то, что архитекторы обычно рисую крайне громоздко.
Обязательно посмотрите, а о следующих митапах буду объявлять здесь заранее. Главное, чтобы регистрация не закрывалась так быстро, как в этот раз.

Видео - https://youtu.be/F5wvsxus-Ig?t=1179
Слайды - ниже

Дурацкий Телеграм все перепутал! Слайды выше 👆

Вредные советы 7. Проще просить прощения, чем разрешения

Есть такой принци в Питончике: EAFP, то есть Easier to Ask for Forgiveness than Permission. На русский язык это переводится как Проще попросить прощения, чем разрешения. Что под этим подразумевается? Что все, что нам нужно - существует (файлы, папки, переменные). А если с доступом есть проблемы - это исключение. Получается довольно чистенько и однообразно.

Антипаттерн
Код ниже сначала спрашивает, есть ли файл, и, если есть, делает с ним логику.

import os

if os.path.exists("file.txt"):
    os.unlink("file.txt")

А как надо?
Считаем по умолчанию, что такой файли есть и сразу пытаемся применить к нему логику. А если файла нет - выбрасываем ошибку.

import os

try:
    os.unlink("file.txt")
except OSError:
    pass # Вот тут pass тоже антипаттерн "Ошибки не должны происходить тихо", но про это в другой раз =)

#ВредныеСоветы

A data janitor is a person who works to take big data and condense it into useful amounts of information. Also known as a "data wrangler," a data janitor sifts through data for companies in the information technology industry. A multitude of start-ups rely on large amounts of data, so a data janitor works to help these businesses with this basic, but difficult process of interpreting data.

Ну все, так и буду себя именовать теперь 😂

https://en.wikipedia.org/wiki/Data_janitor

Вредные советы 8. Как не надо сравнивать с None
Если посмотреть в PEP, то нам скажут, как надо сравнивать с None и это будет if Cond is None. "Но ведь PEP это только гайдлайны, их можно нарушать!", скажете вы мне. Некоторые да, а вот некоторые не надо, потому что это нарушает читабельность кода.

Антипаттерн
Как не надо сравнивать с None:

number = None
if number == None:
    print("Работает!")

А как надо?
Все просто и по гайдлайну:

number = None

if number is None:
    print("Теперь хорошо")

Тут используется identity operator или оператор тождественности. Он вернет True только в том случае, если обе переменные указывают на один и тот же объект.

#ВредныеСоветы

Построение высокоэффективной Agile команды

1.5 года назад в моем продукте было 4 человека: product owner, delivery manager, один разработчик и один DS. Ребята получили в нагрузку от консультантов большой четверки код в Юпитере без описания работы и обещания, что вот эта методология принесет миллиарды миллиардов.😂

На сегодняшний момент нас почти 25, со своим собственным архитектором, бизнес и системными аналитиками, тестировщиками, фронт и бек разработчиками, DE, DS разной направленности. И мы несемся в светлое будующее.

Да, не без провалов.
Да, не без ошибок.
Да, не без фейлов.

Но весь проект начинался как перебрасывание csv файлов между DS и виртуальной машиной, на которой простой бек рендерил Excel-like табличку.
Сейчас это полноценные команды разработки и аналитики, CI/CD, трекинг метрик, мониторинги и, господи прости, кубернетес и автодеплой.

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

Команды не сразу строятся и не сразу становятся rockstars, и мы сами еще в середине пути. Поэтому ребятам, которым приходится немножко управлять другими и процессами постоянно изучают и подсматривают про организацию команд. Сегодня одно из таких видео - Асхат Уразбаев из ScrumTrack про построение команд.😄

https://www.youtube.com/watch?v=MEJgZpHBSDY

#пятничныйYoutube

Глобальный эксперимент по удалённой работе

Шутка уже бородатая, но все же. Каждый день мы слышим как ещё одна компания отправила своих сотрудников на WFH или work from home.

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

В связи со всей этой паникой, вот вам тред из твиттера, в котором люди показывают свои необычные рабочие места дома:

https://twitter.com/julesforrest/status/1238526424719355904?s=19

Выглядит крайне смешно и забавно =)