Продолжаем о собеседованиях

В статье Как проходит собеседование Python-разработчика: вопросы для джуниоров и мидлов (2021) предложена таблица с примерами вопросов по темам.

Например, по теме "тестирование" для джуна вопрос такой:
"Что такое TDD?"
Для миддла в той же теме вопросы уже сложнее:
"Какие тесты приходилось писать? Что такое мок-объекты? Приходилось ли использовать?". Мы, кстати, писали о Mock, с этими знаниями вы теперь middle developer, поздравляю.

Часть вопросов ужасно нелепы, типа "Где в Django применяется паттерн мост?". Но важно понимать, что на собеседовании могут спрашивать самые странные вопросы. И неплохо бы научиться на такие вопросы отвечать. Иногда ответ может быть неожиданным.

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

#skills #резюме

#codereview #quiz

Что же не так в этом коде?
В первую очередь опрос был на внимательность. Но есть и о чём порассуждать.
1. Сразу начнём с PEP8. Называть переменную List нельзя, такой формат именования используется для классов
2. Многие заметили, опечатку — создался List, срез делается по list. Но тут начинается интересное. Текущая версия кода вызовет ошибку TypeError: 'type' object is not subscriptable. Связано это с тем, что list — ключевое слово для создания списка в формате list(). Но без круглых скобок list — это сам класс list, а не экземпляр. У самого класса список не определена операция получения элемента по номеру (subscription).
3. Если код был бы такой
list_a = []
print(list_b[10:])
То мы получили бы ошибку NameError: name 'list_' is not defined.

Итого — TypeError, если мы использовали ключевое слово list и NameError, если мы использовали несуществующее название переменной. И ни одно из таких названий не должно пройти code review.

Хорошая и плохая прокрастинация

Прокрастинация — это склонность откладывать дела "на потом". Пол Грэм утверждает, что самая опасная форма прокрастинации — неосознанная. Ты "сделал много дел". Просто не тех.

Люди, которым не удается написать роман, не терпят крах со своей затеей, сидя перед чистым листом бумаги несколько дней подряд. Они терпят крах, кормя кота, отправляясь купить что-нибудь для дома, встречаясь с друзьями за чашечкой кофе и проверяя почту. "У меня нет времени на работу", — говорят они. И времени действительно нет; они об этом позаботились.

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

Возможности f-строк

В статье Python f-strings Are More Powerful Than You Might Think автор рассказывает об интересных возможностях f-строк:
— форматирование даты и времени
— различные форматы представления чисел
— выравнивание строк по ширине
— условное форматирование

Особенно удобно оказалось при логгировании и отладке выводить имена и значения переменных, используя такой синтаксис: print(f"{var = }")
#python

Нас 2^9=512 — очередное круглое число. Все помнят, что в 512 году произошло легендарное извержение Везувия. Не то, которое стёрло Помпеи с лица земли в 79 году, а одно из полусотни других извержений, но всё же событие.

Сегодня читаем Как правильно задавать вопросы, если ты начинающий айтишник.

#ToTheMoon

Разработка надёжных Python-скриптов

В статье (оригинал) показано, что нужно не забыть в поддерживаемом проекте на python:
— документацию
— разбор аргументов командной строки
— логгирование
— тесты

По каждому пункту есть вопросы. Например, для документации мы бы предложили использовать Google Docstring, для разбора аргументов — click, для логгирования — loguru. Но выбор конкретного инструмента — дискуссионный вопрос, главное — не забыть ни про один из этих элементов в своём следующем проекте, даже небольшом.
#python

Пятничное развлекательное — подборка

В этот день вместо профильного контента у нас культурный код — рекомендации фильмов, книг и мемов. Мы отдыхаем и делимся тем прекрасным, что у нас есть.

Вспомним, что мы уже обсуждали:
— ужасные интерфейсы
— 7 красных линий
— дудеизм Лебовски
— фильмы про хакеров
— цыган
— batmetal
— фильмы про реальность происходящего
— человека (Трасса 60, я и другие)
— книгу методы рационального мышления
— бобров

А какое пятничное развлекательное понравилось вам?
#fun

Пятничное развлекательное — Люди Икс

Мстители прочно вошли в современную культуру. Но новаторами в части масштабной экранизации комиксов были Люди Икс — отличная линейка комиксов, мультфильмов и фильмов, которая осталась в сердцах многих. Интересные способности мутантов, запоминающиеся персонажи, противостояние Профессора Икс и Магнето, любимый Хью Джекман в роли Росомахи — целая вселенная.

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

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

В часовом ролике Как убили людей Икс в кино восстанавливают хронологический порядок повествования в фильмах. Есть спойлеры.
#fun

Sublime Merge — графический git-клиент

Как мы писали раньше, 85% разработчиков работают с git из консоли.

Но для сложного merge c конфликтами рекомендуем использовать sublime merge. На видео демонстрируем, как sublime merge представляет состояние разных веток и позволяет в один клик выбирать нужный код для слияния.

Также sublime merge может быть полезен тем, кто только начинает осваивать git. Он дает наглядное представление об устройстве репозитория и взаимосвязях между ветками.
#procode

Магия CORS

При разработке веб-приложения в консоли браузера можно увидеть не очень информативную ошибку:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ..

В результате беглого гугления глаза разбегаются от количества разных объяснений и костылей для фикса. И часто решение сводится к "забил и поставил хедер Access-Control-Allow-Origin: *".

К сожалению, нельзя дать простое и быстрое решение этой проблемы. Мы рекомендуем статью Deep dive in CORS (перевод), где подробно, с картинками излагается история и причины возникновения CORS, где и как они применяются, и почему решение выше — плохое. В конце статьи приводятся практические советы по настройке CORS.
#procode

#codereview #quiz

Хитрости __getattr__
В примере выше мы создаём класс Users, который, по сути, скрывает внутри обычный список пользователей.

Для получения первого и последнего пользователя потребуется писать self.users[0] и self.users[-1]. Такие конструкции раскрывают внутреннее устройство класса, загрязняют код и делают его менее читабельным. Мы заставляем внешнего потребителя класса разбираться в его внутреннем устройстве.

Один из вариантов решения — декоратор @property и создание нужных атрибутов. Но для большого количества атрибутов будет спагетти из однотипных property.

Другой приём — использование динамических атрибутов. Создаём словарь, где ключом будет имя, а значением индекс в списке пользователей. Метод getattr проверяет наличие искомого атрибута среди ключей словаря, если такой есть — то возвращает пользователя по индексу из словаря.

Детали решения
Почему первый print выведет U1?
Вся суть в том, как python ищет атрибуты. Атрибут ищется в классе. В нашем случае атрибута first нет. Далее производится поиск по иерархии наследования, и тоже безуспешно. Только в этом случае вызывается магический метод __getattr__, и параметром ему передаётся имя аргумента в виде строки "first". По словарю first превратится в нулевой индекс из self.users, что соответствует выводу U1.

Почему второй print выведет new_user?
В 17 строке явно создаем атрибут first и присваиваем ему значение new_user. В 18 строке в классе будет найден атрибут first и метод getattr не будет вызываться.

Обратите внимание ещё на одну интересность. Вывод self.users.users[0] всё ещё даст U1. Получается некая несогласованность. Мы переопределили first, и это уже не первый пользователь.

Поставьте 🔥, если интересно возможное решение такой проблемы.

История поиска работы "Борис опять"

Недавно вышла интересная серия постов о поиске работы machine learning-инженером. Пожалуй, самое ценное в ней — личный опыт и нешаблонные советы автора. История ещё не закончена, автор продолжает рассказывать о своём опыте переезда и искренне делится эмоциями.

Наши мысли по мотивам этой серии статей:
1. Всегда стоит критически подходить к таким постам. Это как книги об историях успеха — что сработало для одних, не сработает для других. Особенно аспекты, связанные с нанимающей стороной — компании разные и ситуации тоже бывают разные.

2. "Нельзя врать", — говорит автор. Врать действительно нельзя, но приукрасить можно. Грань между "приукрасить" и "врать" заслуживает отдельного поста.

3. Интересно увидеть реальное CV автора. Не будем вдаваться в нюансы составления CV, но хорошей практикой считается summary часть. В ней следует тезисно рассказать кто вы, что умеете и что хотите. Автор сетует на блок CV с перечислением технологий, которыми владеешь. И что он — инженер, готовый овладеть всеми необходимыми для решения задачи навыками. Как раз об этом и стоило бы сказать в summary. Способность осваивать новое для решения задач — скилл хорошего разработчика. А блок технологий полезен для HR, которые умеют только grep-ать резюме.

4. По этой серии постов молодой разработчик сможет приземлиться, понять, что IT это не радужное место с гарантированными 300кк/с. Найти хорошо оплачиваемую работу — это труд и дисциплина.

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

6. Переговоры — важная часть собеседований. "Уметь говорить нет" выглядит простым и понятным советом, который на деле применять совсем не просто. Хорошо работает приём, будто решение принимаете не вы, и нужно обязательно посоветоваться с третьей стороной, от которой зависит финальное решение.
#devfm #edu #резюме

Миграция БД без даунтайма

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

При последовательном обновлении базы и приложения легко оказаться в рассинхронизированном состоянии, например, с обновлённой базой и старой версией приложения. Старая версия приложения не умеет работать с обновлённой базой, в результате будут сбои до тех пор, пока новая версия приложения не заменит старую.

В статье Migrating a production database without any downtime (перевод) рассказывается на примерах и с картинками, как пошагово решать проблему обратной совместимости базы данных и приложения.

#skills #database