О себе:
Привет. Меня зовут Путнов Денис. Почти всю свою карьеру в IT я работаю с фронтендом и менторингом людей в этой сфере. Я успел поработать в стартапе, над кучей личных проектов, дорасти до Senior уровня в компании Netcracker, а сейчас я и вовсе работаю в X5 Технологиях. Параллельно работе, я менторил большую группу людей в RS School, по знакомству помогал друзьям и их знакомым, консультировал людей абсолютно разных уровней — начиная с полного нуля и заканчивая разработчиками Senior уровня. Успел пройти несчётное количество собеседований: в поисках новой работы и лучших условий или просто с желанием оценить себя. Всё это — мой опыт, который я планирую использовать в работе над этим каналом.

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

Готовиться нужно перед любым собеседованием. Знать и помнить абсолютно всё — неподъмная задача.

Зачем?
Мой канал — это способ раскрасить ваши будни в телеграме среди потока мемов и прочих не сильно важных вещей на рынке, дать возможность оставаться актуальным разработчиком на рынке труда. Все мы знаем, что лучше читать 100 постов в год, чем 100 постов в день. Так информация усваивается очевидно лучше.

Я потратил достаточно времени на обучение других людей в сфере IT, моего персонального менторинга коснулись более 50 человек за последние 4 года, и для меня предельно ясна проблема. Вопросы у всех одинаковые. С целью решения этой проблемы я и продолжаю вести этот канал. Моя цель — собрать самые актуальные вещи с современного рынка и в понятной и простой форме подать это аудитории.

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

Ссылки:
Telegram: @denisputnov
GitHub: github.com/denisputnov
LinkedIn: linkedin.com/in/denisputnov

О Futter в целом:
Всё время, сколько я занимаюсь программированием, я помню себя человеком вечно смотрящим что-то, проходящим курсы и изучающим что-то новое.
Последние же дни я трачу на изучение Dart/Flutter тучи времени, и тут я хочу объяснить почему именно он:

1. Конечно же кроссплатформенность.
Flutter фреймворк позволяет создавать нативные кроссплатформенный приложения. Что это значит? Один и тот же код может запуститься как на Android, так и на iOS. Один Flutter-разработчик покрывает задачи сразу двух людей - разработчиков под эти две системы, что выгодно как экономически, так и организационно. Не нужно согласовывать действия разных команд, это значительно ускоряет разработку.

2. Собственная виртуальная машина.
Flutter реализует собственную виртуальную машину на языке Dart, что по моему мнению - главный аргумент в пользу этой технологии. Разработка идёт в разы быстрее. При работе с Dart VM после каждого изменения НЕ нужно компилировать весь проект с нуля, ведь виртуалка просто подменяет измененный файл в готовом скомпилированном проекте. Как результат, все изменения видны в эмуляторе за 5 секунд, чем тот же Kotlin похвастаться не может. Ему нужно полностью компилировать приложение заново после каждого изменения. Так и получается, что со среднем временем компиляции в 2 минуты (что достаточно быстро, обычно время больше) на 100 изменений в коде Flutter-разработчик посмотрит уже через 8 минут, а вот разработчик на Kotlin - чуть более чем через 3 часа.

3. Большие возможности из коробки и собственный графический движок Skia.
Flutter предлагает разработчикам какое-то немыслимое количество встроенных функций. Уже готовые меню, навигационные окна, поля ввода/вывода, декларативно-реализуемые виджеты прокрутки и сотни разных иконок - вот что такое Flutter. И почему-то не получается говорить об этом без восхищения, инструментарий и правда огромен.
А что если вам его не хватает? Есть Skia! Google купила его ещё в далёком 2005, а теперь это очень сильный и производительный движок для отрисовки UI на всех платформах. Помимо того, что движок отлично справляется с отрисовкой интерфейса (с оговоркой на ограничение в 60 fps max) в Flutter реализована поддержка инструментов Skia, благодаря чему, например, вы можете отрисовать логотип приложения/компании на системном уровне, а не просто загрузить его в качестве asset'а.

4. Flutter - это не только mobile.
Даже для многих знакомых с Flutter людей становится открытием тот факт, что существует так же Flutter-Web и Flutter-Desktop. Такой же декларативный подход, такой же огромный встроенный функционал, но уже в ваших браузерах и локально!

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

#mobile

Как-то я удивлён.
Раньше думал "Зачем вообще Flask нужен, если есть великий и могучий Django? Там и комьюнити побольше, с возможностями получше, да и огромное количество реализованных проектов и паттернов...", а сейчас сижу и изучаю Flask и выглядит это как предательство собственных принципов 🤡

Несколько мыслей о фреймворке:
• Flask легковесный и простой. Запустить лендинг или портфолио можно за 20 строк, да и в целом архитектурно всё выглядит даже примитивно.
Простые конструкции очень упрощают понимание того чем ты занят как в обучении, так и в работе.

• Быстрее Django, но медленнее Tornado или aiohttp, что вполне ожидаемо.

• Такой-же удобный шаблонизатор, как в Django.

Как итог, для своих проектов я бы брал именно Flask, что и всем теперь буду советовать. Особенно он идеален для разработки Pet-проектов, слишком уж просто с ним взаимодействовать. Что тут ещё сказать, лайк таким👍

#python #web

Пока немного познакомлю народ со своим github, а именно:
На гите у меня есть много всего интересного, конечно, но особенно я выделяю вот этот репозиторий.

Там вы найдёте различную написанную мной документацию по разным технологиям, а так же шаблоны для разработки на Python и уже готовые программы.

В общем, считаю, что достойно внимания👍

#github

​Новый сервис придумал сегодня.
В голову пришла идея нового сервиса, что будет полезен для всех программистов, и долго думать я не стал - сразу же предложил идею другу, и вот, спустя почти 7 часов, мы имеем:
- концепт-проект дизайна сервиса в Figma,
- архитектура базы данных,
- готовая домашная страница сайта,
- на половину дописанный back-end на flask,
- идею api для нашего сервиса,
- а самое главное - понимание того кому и зачем это нужно.

Проект на данный момент имеет название "Codeye", что является вольным сокращением слов Code and Eye.
Цель проекта - помочь начинающим и не только программистам получать качественную помощь и знания.

Ну и пока это все новости, что я хотел бы рассказать, в подробности уходить нет смысла. Сам жду момента, когда уже можно будет анонсировать это важное, но простое решение.👋

#progress #codeye

​Продолжаем дневник разработчика, в общем.
Сегодня на разработку было потрачено по 11 часов с каждого человека. За сегодня успели:
- арендовать хост и доменное имя,
- запустить тестовое приложение онлайн,
- пересобрать back-end, расширить базу данных,
- значительно улучшить конфиденциальность,
- на ~30% закончить вёрстку главной страницы (очень большой объем работы),
- разработать логотип и доработать общий брендинг,
- получить огромный опыт для себя.

Разрабатывать такие pet-проекты - отличный, если не лучший способ получить огромное количество знаний и удовольствия от процесса.
Настоятельно советую всем взяться за что-то, что вас мотивирует, и реализовать. Сам я к таким советам не прислушивался никогда, но стоило лишь попробовать..🍑

Кстати, брендинг вроде и правда неплохой вышел, разве нет?)

Добра.

#progress #codeye

MVP codeye сегодня,
18:00 по МСК

Ну-с, почти как и обещал.
На часах 18:11 и доступ к сайту открыт для всех желающих. Сейчас на хосте крутится самая первая наша версия, в которой процентов 20 от запланированных изначально функций. Также на данный момент у нас не настроена мобильная версия сайта, так что не все страницы отображаются адекватно.
Но в общем, дальше-то - лучше.

codeye.ru - веб-приложение, что поможет вам делиться своим кодом быстро и просто. Сервис не требует регистрации. Всё что нужно нам - это внимание, за которое мы и предлагаем какой-никакой продукт, хоть и себе в убыток.

Сейчас хотелось бы получить любой фидбэк, так что рад всех выслушать @grnbows

#codeye #progress

Слишком много было про codeye, сегодня поговорим про ботов.

Как мне кажется, сейчас есть две точки зрения на эту тему. Первая заключается в том, что боты - это панацея, а вторая, соответственно, в том, что всё это как-то непонятно. Но это только на первый взгляд.

У ботов есть очевидное преимущество - они более легкодоступны и интуитивны, чем мобильные приложения. В то время, как основной конкурент чат-ботов требует лишних манипуляций, сами чат-боты базируются на уже готовых платформах, будь то Telegram, Discord, What's App, VK или MailAgent (даже такое практикуют, ужас). Самыми развитыми платформами на данный момент являются конечно же VK и Telegram - они предлагают наибольший функционал, более стабильные и удобные API, чем конкуренты.

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

НО, это не значит "все бежим делать чат ботов". Развитие чат-ботов никогда не вытеснит приложения с рынка, но потеснить их вполне в силе. Приложения всё так же актуальны для крупных проектов, когда, например:
- необходим графический интерфейс для взаимодействия с программой (напр. фоторедакторы, навигатор и тд);
- есть потребность в полном взаимодействии с файлами устройства (органайзеры вызовов, сообщений, другого медиа);
- если речь идёт о стриминговом сервисе (представьте Spotify или YouTube как бота в Telegram, даже звучит смешно);
- требуется сложная система авторизации (банковские приложения);
- необходима сложная система фильтрации (напр. приложение интернет-магазина типа aliexpress, avito, wildberries и тд);
- ну и так далее.ᅠ

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

Как итог, помните, что каждая задача имеет своё решение. Чат-боты прекрасны, и они идеальны для несложного взаимодействия условно типа «вопрос/ответ», а приложения идеальны в более сложных и объемных задачах. Лично я считаю именно так и не отношу себя ни к одной из категорий людей, что описал выше. Но, конечно же, чат-ботов я обожаю.

Кстати, кто не знал, у меня есть два своих:

На данный момент отключены по техническим причинам, скоро будут включены снова!
@pyInfoParserBot - курсы валют и информация о коронавирусе,
@about_chat_bot - техническая информация о чате, что очень часто нужна разработчикам.

#mobile #chatbot

​На базе своих проектов я планирую реализовывать REST API, а в этом посте объясню что это такое и почему я хочу это использовать.

Дня начала введу понятия, а именно:
REST - это архитектурный стиль построения и взаимодействия приложений в сети.
API - интерфейс взаимодействия с определенным приложением.

В итоге получаем, что REST API - это способ взаимодействия с приложением в сети по определенному заранее известному стилю. Самый просто пример - API различных мессенджеров, когда посредством HTTP запроса бот отправляет сообщение пользователю.
Схематично запрос выглядит так:

api.messenger.com/send_message/token=TOKEN&chat_id=1234567&message="Hello, world"

У этого запроса, в теории, может быть ещё много переменных, что даст вам больше возможностей кастомизации. Если вы сами перейдёте по этой ссылке, то вы не увидите ничего. REST API не имеет графического интерфейса. Всё, что вы можете увидеть - это, например, ответ в json формате, как это реализовано у Telegram.

Так зачем же API другим сервисам? Ответ: для упрощения интеграции к другим приложениям. Например, банки могут реализовать API, что вернёт актуальный курс валют на момент запроса, а сервисы типа OpenWeatherMap после запроса вернут актуальную погоду в выбранном городе. А API сайта Wikipedia может вернуть текст или название любой статьи, к примеру, или произвести поиск по запросу в самом сервисе.

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

Реализовать технически это не сложно. И как раз крайне популярен в этом плане мой ныне обожаемый Flask, о котором я писал ранее.

Он отлично подходит для написания различных REST API. Касательно вашего сервиса можно реализовать любой запрос именно через него. Для этого нужен всего лишь доступ к БД и 100 строк кода на Python. Через API вы можете реализовать как добавление статей на сайт, так и интеграцию с чат-ботами. Как пример, онлайн таск-менеджер, который посредством API вашего сайта и Telegram будет отправлять пользователю различные напоминания в любимый мессенджер. Такую реализацию я уже видел.

Лично я стал бы использовать REST API как минимум из-за интеграции с мессенджерами. Это очень удобно и явно понравится пользователям. Ну и неплохо было бы реализовать и доступ к сервису посредством API для других разработчиков и сервисов, если это нужно. Почему нет?

#python #web #chatbot

Figma и разработка дизайна.

Так вышло, что вчера у нас заказали разработку интернет-магазина. Вообще в последнее время меня настигает какая-то совершенно неожиданная череда событий в жизни, но это проиcшествие не ожидал никто, конечно. Можно считать, то первый год обучения программированию закачивается первым коммерческим проектом для меня и @syth0le.

Но не в этом суть! Хочу рассказать о Figma. Этот инструмент мне казался очень популярным, но как оказалось, для некоторых людей это просто откровение.

Я использую Figma во всех своих проектах - начиная от разработки сайтов и заканчивая дизайном приложений. Мой стаж работы в Photoshop и Illustrator на данный момент - 6 лет, что огромная цифра для моего возраста (а я напомню, что мне 19). За эти 6 лет я успел закончить более 2 тысяч работ, выполнить десятки заказов на фрилансе, посотрудничать с крупными блогерами, и как бы я не любил этот инструмент, сейчас я всё сильнее отказываюсь от него и перехожу в Figma. Но почему?

1. Лаконичность инструментов и простота.
Мне явно есть с чем сравнить и я могу сказать, что тут Figma далеко впереди. Интерфейс не перегружен, но при этом есть все самые необходимые инструменты, которых хватает в 99% случаев. Интерфейс программ Adobe перегружен. Да, функций действительно больше и они достаточно полезны в некоторых ситуациях, но разработчикам UI эти инструменты просто не нужны.

2. Удобный экспорт.
Удобный экспорт - это что-то, люди с опытом меня поймут. В то время, как в Figma экспорт футажа проходит в 3 клика, в продуктах Adobe с этим огромные проблемы, о которых даже зарекаться страшно. Без перебирания всех слоёв экспортировать отдельный объект на столько удобно, как в Figma, просто невозможно.

3. Figma бесплатен.
Может и не очень актуально в потребительском секторе СНГ, но всё же, например, для бизнеса это очень серьёзный удар. Тут без комментариев.

4. Совместная работа.
Над одним проектов в едином поле может работать сразу несколько дизайнеров. Это очень удобно, в разы ускоряет процесс разработки и скорость обмена информацией.

5. Встроенная система контроля версий.
Можно посмотреть кто, когда и как что-то изменил в проекте.

6. Возможность запустить презентационный макет на смарфоне/пк.
На примере приложений: хотите посмотреть как оно будет смотреться в самом смартфоне? Просто соедините действия нужных кнопок и перемещайтесь со своего устройства по готовому макету (пункт звучит как рекламная интеграция, горжусь собой)ᅠ

7. Удобная браузерная версия, она прекрасна.
Ничем не отличается от Desktop версии, потребляет мало ресурсов. Идеально, в общем-то.

Вот такой рассказ вышел. Без лишних слов и с чистой совестью рекомендую использовать Figma всем, это очень качественный и удобный инструмент для всех дизайнеров.

#web #mobile #progress #design

Python декораторы.

Как-то долго я ходил вокруг да около, а про любимый Python забыл. Сегодня попытаюсь объяснить вам что такое декораторы.

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

1. Определим функцию say_hello(name), которая на вход получит имя человека:

python
def say_hello(name):
    print('Hello,', name)

say_hello('Денис')
>>> Hello, Денис

2. Отлично. А теперь определим декоратор, который скажет что-то приятное после приветствия:

def you_are_beautiful(func):  #  На вход поступает функция
    def wrapped(*args, **kwargs):  #  обрабатываем аргументы
        func(*args, **kwargs)  #  вызывает функцию извне
        print('Классно выглядишь сегодня ;)')
    
    return wrapped  #  возвращает функцию, но не вызывает!!!
                    #  (возвращает ссылку на функцию, без скобок)

Есть один нюанс, который нужно соблюсти - декоратор должен быть объявлен ДО декорируемой функции. А способов применить декоратор несколько, но для Python самый актуальный способ, так называемый «Синтаксический сахар», на примере:

#  сначала определяем декоратор
def you_are_beautiful(func):
    def wrapped(*args, **kwargs):
        func(*args, **kwargs)
        print('Классно выглядишь сегодня ;)')
    
    return wrapped 

#  далее определяем функцию и навешиваем декоратор
@you_are_beautiful  <-- наш декоратор
def say_hello(name):
    print('Hello,', name)

say_hello('Денис')
>>> Hello, Денис
>>> Классно выглядишь сегодня ;)

Под коробкой вызов функции выглядит так:

you_are_beautiful(say_hello('Денис'))

Ну и, соответственно, декораторов может быть навешано несколько:

@decorator1
@decorator2
@decorator3
@decorator4
def foo():
    pass

#  что при вызове, по сути, эквивалентно этому:
decorator1(decorator2(decorator3(decorator4(foo()))))

По итогу получаем задекорированную функцию. Что-то выполнилось до вызова функции, что-то после, и это очень удобно в некоторых задачах. Обещаю сделать отдельный репозиторий/папку для своих декораторов, прикреплю ссылку сюда позже, а отдельным постом оповещу. И спасибо за прочтение, это важно дня меня 🙃

#python #github

Кстати, codeye.ru мы не забросили. 🤭

Можно сказать, что торжественно объявляю начало второго тестового периода сервиса - версию с кодом v0.2:[ALPHA].

Изменения:
- добавлена подсветка синтаксиса для 11 языков (Dart, GO, Python, JS, Swift etc.)
- добавлена возможность прикреплять к описанию до 3 фото
- ну и конечно же bug-fix в вёрстке и в back-end

Сейчас сервис работает еще стабильнее, а дизайн постепенно улучшается (хотелось бы верить, ведь мобильной версии сайта все еще нет, мы в процессе)

Спасибо всем, кто помогал найти баги❤️

Ссылка ещё раз: codeye.ru
По всем багам и вопросам: @grnbows @syth0le

#codeye #progress

Сегодня будет достаточно глубокий экскурс в Python исключения.ᅠ

Для кого-то эта тема может быть очевидной, но для некоторых начинающих разработчиков эта тема всё ещё не открыта. Итак, что же такое исключения?

Действия программы, которые противоречат тем или иным правилам вызывают исключения. Например попытка поделить на ноль вызовет ZeroDivisionError, а попытка сложить строку и кортеж - TypeError.

"Отловить" ошибки можно при помощи конструкции try/except/else/finally. Например:

def division(a,b):
    try:
        return a/b
    except ZeroDivisionError:
        return None

Теперь работа программы не будет ломаться при делении на ноль, а продолжит свою работу. Но это далеко не значит, что использование блока try/except - панацея. Об этом чуть позже.

Как же создать своё исключение? Легко:

class MyOwnException(Exception):
    pass

или

class MyOwnException(Exception):
    #  разный функционал, что выполнится при исключении

Как вы видите, для создания своего исключения мы создаём новый класс, который наследуем от базового класса Exception. Чтобы выбросить это исключение в программе мы воспользуемся оператором raise:

#  какое-то условие, что вызывает исключение
raise MyOwnException('Message')
>>> __main__.MyOwnException: Message

Замечательно, удобно для программиста, быстро но теперь поговорим о том почему это плохо:

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

Я уже рассказывал вам про декораторы тут, так что вот какое решение могу предложить. Оформим собственное исключение, декоратор, что сохранит любую нашу функцию и задекорируем объявленную ранее функцию division. Вашему вниманию предлагаю такой код:

from functools import wraps

class Error(Exception):
    
    def __repr__(self):
        return 'Error'

    def __str__(self):
        return 'Error'

def safe(func):

    @wraps(func)
    def wrapped(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except:
            return Error()

    return wrapped

@safe  #  декорируем функцию
def division(a, b):
    return a / b

division(4,0)
>>> Error

Итак, что тут происходит? Для начала о @wraps. Я еще не рассказывал о нём, но этот декоратор нужен для сохранения таких параметров функции как __name__ и __doc__, так как после декорирования эти параметры переписываются. Под коробкой этот декоратор на примере можно заменить вот так вот так:

def safe(func)
  
    def wrapped(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except:
            return Error()

    wrapped.__name__ = func.__name__
    wrapped.__doc__ = func.__doc__

    return wrapped

А теперь обо всём в целом. Мы создали декоратор safe, который позволит обезопасить любую функцию от любой ошибки. При объявлении небезопасной функции с этим декоратором мы получаем абсолютно неломаемую программу, а выглядит решение ну очень уж лаконично. Кстати, в блоке except мы можем возвращать не только наш экземпляр класса Error, но и любое другое значение, которое нам будет удобно, например float('inf'), что вернёт нам бесконечность. (Кстати, в рассмотренном примере не обязательно возвращать именно экземпляр класса. С таким же успехом можно вернуть просто строку "Error", но я оставил класс для того, чтобы вы могли легко модифицировать поведение своей ошибки)

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

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

А этот декоратор был бы неплохим началом для моей коллекции декораторов, да?)

#python

​Аннотации в Python.

Типизация переменных в языках - это вечная тема для обсуждения. Кому-то нравится, статическая типизация, как в Dart, например, когда мы явно объявляем новые переменные и указываем какие типы данных они могут в себе содержать, в то время, как другим нравится динамическая типизация, как в Python, где в любой момент времени можно создать и использовать новую переменную любого типа. Сейчас не будем обсуждать что лучше, а что хуже, а поговорим о том как указать тип переменной в Python явно.

Указание типа переменной происходит по определенному синтаксису, который лучше показать, чем объяснить:

def say_hello(name: str, age: int) -> None:
    print(f"Hello, {name}. I know, you're {age} years old.")

Вот такая замечательная функция у нас появилось. Мы явно указываем, что name - это строка, age - целое число, а сама функция должна возвращать None, и теперь большинство сред разработки будут указывать нам типы переменных, когда мы захотим использовать эту функцию, НО это лишь визуальное указание, никаких изменений в ход программы это не внесёт. О чём речь? Попробуем выполнить эту функцию:

say_hello('Денис', 19)
>>> Hello, Денис. I know, you're 19 years old.

#  всё бы хорошо, но попробуем так:

say_hello([1, 2, 3], "СТРОКА")
>>> Hello, [1, 2, 3]. I know, you're СТРОКА years old.

Как вы можете заметить, функция прекрасно отработала и не выдала никакой ошибки. Но как сделать так, чтобы при неправильных типах переменных функция не выполнялась? Обычно для этого предлагают использовать функцию isinstance. На примере:

def say_hello(name: str, age: int) -> None:
    if isinstance(name, str) and isinstance(age, int):
        print(f"Hello, {name}. I know, you're {age} years old.")
    else:
        raise TypeError('Подан неверный тип переменной')

say_hello('Денис', 19)
>>> Hello, Денис. I know, you're 19 years old.

say_hello([1, 2, 3], "СТРОКА")
>>> TypeError: Подан неверный тип переменной

Теперь наша программа прервётся, если мы подадим в функцию неправильные входные параметры. Ну и, опять же, тема очень обширная, советую ознакомиться подробнее. Спасибо, что читаете ❤️

#python

​Сегодня совсем коротко, но зато со смыслом.

Думаю, многие знают, что в Python есть такие операторы, как is и ==. Оба они идейно похожи - они указывают на равенство объектов. Казалось бы, одно и то же, но давайте на примере:

#  объявим наши переменные
#  таким образом
a = [1, 2, 3]

b = a

c = [1, 2, 3]

Отлично, проверим?

a == b
>>> True
a is b
>>> True
a == c
>>> True
a is c 
>>> False

Первые три выражения дали вполне ожидаемый ответ, а с последним всё не так однозначно.
a == b == c == [1, 2, 3] , с этим не поспорить. b = a, значит b - ссылка на объект a, следовательно обе переменные ссылаются на один и тот же список [1, 2, 3] в памяти. А вот c - это уже новый объект в памяти, и пусть даже c == a, но это разные объекты. Именно поэтому a is c ⇒ False.

В этом и заключается вся разница.

#python

​Снова немного отойдём от Python'a и поговорим об инструментах.

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

Сегодня речь пойдёт о Miro - это один из лучших сервисов для построения Mind/Road Map, который я встречал. Этим сервисом я пользуюсь уже очень давно. Там я строю карты для последовательного изучения разных языков, визуализирую проект и ставлю задачи как себе, так и другим разработчикам. Кратко расскажу о преимуществах и недостатках:

1. Очевидное преимущество - это конечно же визуализация. Так проще работать со всеми входными данными и устанавливать связи. Лично я даже базу данных проектирую в Miro.

2. Коллаборативный режим. На одной доске Miro можно работать в команде в одно и то же время, синхронизация работает отлично.

3. Множество готовых шаблонов. Не нужно ничего придумывать самому, большинство шаблонов уже существует.

4. Доступ из браузера. Без лишних слов, быстро и удобно.

Но так же есть и недостатки, а именно условная бесплатность. Сервис доступен бесплатно, но только с ограничением в 3 рабочих доски. Если вы хотите вести большее количество проектов, то 3-х досок вам будет недостаточно и придётся оформить подписку.

Сервис однозначно рекомендую, особенно при создании новых проектов.

#useful

​Области видимости в Python.

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

Области видимости (О.В. в примере) в языках программирования рассматриваются как некоторые сущности, знаете. Этот термин подразумевает область программы, откуда будет доступна переменная, функция и т.п. структуры.

Из теории тут ничего особо важного да и сложного нет. Все принципы примерно похожи для большинства языков, но на примере Python:

#  глобальная O.B.

a = 5
b = 6

def foo():  #  foo О.В.
    c = 7
    return a * b

foo()
>>> 30
print(c)
>>> NameError: name 'c' is not defined

Что тут происходит? Всё просто: две переменные a и b мы объявляем в глобальной области видимости, а c в области видимости функции foo. И тут нужно понять, что области видимости работают по принципу вложенности: переменные из родителя доступны в ребёнке, но не наоборот (!).

Таким образом переменные a и b доступны в функции foo, но c не доступна в глобальной области видимости, переменная локальна.

Кстати, с областями видимости есть классная и очень интересная особенность - замкнутость. Она много где используется, например в тех-же декораторах. Может быть я напишу об этом позже, конечно, но советую самостоятельно ознакомиться, тема интересная. Ну и конечно же есть смысл посмотреть про ключевые слова global и nonlocal, но помните, что использование этих ключевых слов не очень хороший тон в программировании.

Спасибо прочтение и классный фидбек в личных сообщениях, это дорогого стоит

#python