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

​Зачем нужны абстрактные методы и классы?

Думаю, что многие знаю о существовании абстракции в языках программирования, но даже если вы не слышали об этом, то сейчас я объясню это в максимально простом виде 🙃

Давайте начну с примера из личного опыта. Может быть затяну из-за этого, но должно быть интересно. Так вот, недавно я работал в стартапе из кремниевой долины. Мы с командой создавали чат-бота, который будет работать во всех мессенджерах, будь то Telegram, VK, What's App, Viber или Facebook Messenger.

Как тут быть? У каждого мессенджера свой API со своими входными и выходными, мы столкнулись с проблемой стандартизации. Тогда мы просто взяли и написали свой интерфейс для каждого мессенджера. Стандартом интерфейса и стал абстрактный класс с абстрактными методами. Так что же это такое?

Абстрактный класс - класс, унаследованный от класса ABC и содержащий абстрактные методы.
Абстрактный метод - метод класса, задекорированный декоратором @abstractmethod и не имеющей реализации. Такой метод нужен только для объявления.

Давайте на примере, так будет яснее. Отдалённо повторим интерфейс мессенджера из нашего проекта:

from abc import ABC, abstractmethod

class Interface(ABC):

    @abstractmethod
    def send_message(self, chat_id, *args, **kwargs):
        pass

    @abstractmethod
    def send_photo(self, chat_id, txt=None, *args, **kvargs):
        pass
        
    @abstractmethod
    def send_file(self, file, txt=None, media=None):
        pass

    #  Ну и так далее

Что происходит в этом примере? Я объявил класс Interface, который унаследован от абстрактного класса ABC. В этом классе я объявил 3 абстрактных метода. У них нет реализации. Суть абстрактного класса заключается лишь в том, чтобы обязать наследника класса Interface реализовать все необходимые методы.

Потом мы реализуем класс, например Telegram, где реализуем метод send_message одним кодом, а в классе WhatsApp реализуем тот же метод совсем по другому. Нас не волнует как это работает внутри, мы лишь описываем необходимый интерфейс взаимодействия.

Надеюсь этот пример помог вам понять что это такое и немного разобраться.

#python

​Нужен ли Bootstrap.

В front-end есть такой вечный холивар на тему Bootstrap'a. Очень часто я стал слышать мнение, что на самом деле Bootstrap не нужен и надо бы верстать без него. Сегодня попробую подробнее разобраться в том вопросе.

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

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

Ну и недостатки:
1. Нужно разбираться. Много есть классов, которые необходимо знать и уметь использовать. А для их изучения нужно время, это часто отпугивает людей.
2. Многие классы вообще не используются в разработке проекта. Тем более, если проект серьезный, то функционала фреймворка будет уже недостаточно и придётся так или иначе писать собственные стили.
3. Уменьшается скорость загрузки страницы, это иногда очень значительный показатель.

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

#web #design

Зачем нужен json.

Казалось бы, вопрос вполне очевидный, но далеко не для всех. Сегодня расскажу про json и его особенности.

Итак, json - это формат передачи данных. Многие связывают его исключительно с JavaScript и WebDev, но в современном мире это далеко не так. Многие языки способны обрабатывать json и имеют для этого встроенные функции/модули. Например в Python есть встроенный пакет json, который позволит вам легко обработать этот формат и, например, перевести json в обычный питоновский словарь для облегчения работы.

Что же делает json таким популярным? Ну, очевидно, это удобство использования. Если вспоминать ближайшего конкурента, а именно xml, то лично мне json кажется более читабельным и удобным в работе. В своей практике я работал с обоими технологиями, и правды ради обе удобны. У каждой есть свои плюсы и минусы, но и сферы применения так же разнятся.
ᅠ
Но насчёт читабельности, предлагаю оформить одну и ту же структуру данных сначала в json, а затем в xml:

{
  "name": "JavaScript для чайников",
  "authors": [
    "Крис Минник", 
    "Ева Холланд"
  ],
  "publisher": {
    "name": "Диалектика",
    "email": "[email protected]",
    "site": "www.dialektika.com"
  } 
}

Вот такая произвольная структура получилась для книги, которую я читаю в данный момент, кстати. Теперь повторим ее на xml:

<book>
  <name>JavaScript для чайников</name>
  <authors>
    <author>Крис Минник</author>
    <author>Ева Холланд</author>
  </authors>
  <publisher>
    <name>Диалектика</name>
    <email>[email protected]</email>
    <site>www.dialektika.com</site>
  </publisher>
</book>

Не знаю как вам, но лично мне json кажется в разы дружелюбнее и читабельнее.

Используется же json чаще всего в случаях, когда нужно быстро получить какой-то ответ от сервера. И речь тут не только о Web. Например, в формате json ответ от сервера могут получать мобильные приложения. Ну и конечно же этот формат данных крайне популярен в REST API, о которых я писал тут.

#python #web #mobile

​Сегодня снова хочу рассказать о codeye.ru

Кто забыл или не знал, это наш с @syth0le сервис, которому сегодня официально 2 недели🥳. Мы выходим в открытое тестирование, так что была бы полезна любая помощь. Чем быстрее мы сможем отловить все баги, тем лучше получится конечный продукт.

Из изменений с последнего раза немного:
- появилась полностью функциональная мобильная версия сайта для всех типов устройств
- пофикшены найденные ранее баги
- оптимизирована загрузка страницы и фото на сайт, теперь это должно происходить быстрее

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

Больше контактов можно найти на странице codeye.ru/about

#codeye #progress

Мета-теги HTML для поиска.

Сегодня давайте быстренько и по факту. Мета-теги - это теги на странице, которые содержат в себе информацию для поиска. Настроенные мета-теги помогут найти ваш сайт в сети. Это одиночный тег, у него есть 2 параметра: name и content.

Давайте рассмотрим самые частые теги:
Description отвечает за отображаемое описание сайта в поиске.

<meta name="description" content="Telegram | @prog_way_blog">

Keywords отвечает за ключевые слова для поисковых движков.

<meta name="keywords" content="HTML, Meta">

Author устанавливает автора страницы.

<meta name="author" content="Denis Putnov">

И так далее. Существует гораздо больше тегов, конечно же, например такие интересные как:

<meta name="google-site-verification" content="TOKEN">
<meta name="yandex-verification" content="TOKEN">

Эти теги верифицируют ваш сайт в поисковых системах.
ᅠ
В целом мета-теги играют большую роль в SEO, так что для всех веб-разработчиков это must have :)

#web

Насчёт сред разработки.

Меня и правда достали споры про среды разработки. Постоянно идут разговоры об этом, вот и я решил рассказать о своём опыте. Я пользуюсь VS Code уже пол года. Не думаю, что у меня чрезмерно большой опыт, но за всё время я успел использовать PyCharm, CLion, Android Studio, Eclipse, Sublime Text, Visual Studio Code, Brackets, Notepad++, Jupiter Notebook, Atom и VS Code, соответственно. Вот такой список получился. Тут есть как и обычные редакторы кода, так и полноценные IDE. Я же остановился на VS Code и в моём понимании это что-то среднее.

Почему:
1. Легковесность. Ни одна IDE не может похвастаться такой скоростью работы, как у VS Code.
2. Лидер рынка по количеству расширений. Найти можно что угодно, тут бесспорно.
3. Универсальность. VS Code прекрасно работает как с Python, так и с Dart, JS, C, Go (и другими языками), даже поддерживает многие фреймворки. У VS Code почти идеальная поддержка Flutter и Django, например. В этом я убедился на личном опыте.

Минусов два:
1. Запуск программы. Нет из коробки возможности настроить и сохранить множество сценариев запуска программы со своими настройками, как это реализовано в PyCharm (к слову, хоть такой возможности и нет из коробки, есть плагин, позволяющий добавить это).
2. Отладка всё же не такая шикарная, как в продуктах JetBrains. Там она идеальна на мой взгляд.
ᅠ
Кстати, вот тут я пишу-пишу о том, как прекрасен VS Code, но это далеко не значит, что он - панацея. Я так же пользуюсь и Sublime Text, например (правда, он у меня как текстовый редактор вместо блокнота на винде 🤡), иногда захожу и в PyCharm, потому что отладчик там без лишних слов великолепен. Я не вижу в этом проблемы. Как обычно я и пишу, просто используйте лучшее из каждой технологии и получите идеальный вариант для вас.

Написать о моих расширениях для VS Code? Дайте фидбек @grnbows

#useful

​HTTP-Server.

Совсем коротко: недавно на паре увидел достаточно сильную вещь для вёрстки, а именно - пакет http-server на базе ноды. После установки пакета можно запустить весь проект одной командой.

Раньше я поднимал весь development сервер для разработки вёрстки, а сейчас по факту достаточно обычного http-server, который и памяти меньше кушает, и вообще молодец.

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

#web #useful

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

Это все таки блог, так что тут я пишу не только что-то полезное, а всё, что хочу, в том числе о своей жизни, а поделиться мне есть чем :)

Начнем с того, что на мне все ещё висит наш прошлый проект - заказанный у нас с @syth0le интернет-магазин. Много времени уделять этому проекту не получалось, так что сам по себе сайт по обговоренным условиям готов на процентов 70-80. После выпуска проекта обязательно закину ссылку сюда.

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

Кстати, никто не отменял мою увлеченность ботами в телеге, так что я постоянно думаю о своих упавших, но ничего не делаю 🗿

Ну и самая главная новость прошедшей недели, так сказать, - это то, что мы с товарищем серьезно засели за реализацию ещё одного собственного pet-проекта. Это приложение, реализованное на Dart/Flutter и Python REST API, в сфере путешествий. Приложение поможет пользователю уточнить некоторые нюансы о поездке, спланировать маршрут, а вот остальная информация попозже. Хватит пока на этом) На разработку дедлайн в пол года, ссылочку на маркет вкину сюда, как будет готово (если будет 🌚 )

Кстати, идей для постов вроде не мало появилось, так что как минимум в ближайшую неделю поактивничаю)

Ну и конечно же спасибо за прочтение всех этих мыслей, держи жопу❤️

#blog

​Pet-проекты.

Частенько я о них думаю, говорю, да и тут иногда в постах вспоминаю. Хочу объяснить почему у меня такой ажиотаж касательно всего этого.

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

Чаще всего многие программисты говорят, что pet-проекты очень сильно помогают в трудоустройстве и это утверждение не без правды. Наличие pet-проектов, особенно если они успешные, - это сильное конкурентное преимущество в ряде случаев. Я с этим согласен.

Но знаете, pet-проекты помогают ещё вот в чем - набраться опыта в реальной разработке хоть чего-то, понять свои проблемы и пробелы в знаниях и всё восполнить. Такие проекты помогают вам в некотором самоопределении, обучении и получении опыта.

Попробуйте, если не пробовали ранее. Даже телеграм-бота написать - уже что-то, пусть это и достаточно просто в большинстве случаев.

#useful

​Стоит ли использовать jQuery?

Тоже много слышу об этом, постоянно кто-то спорит за и против. Есть люди, которые полностью не признают библиотеку, а есть и те, кто используют её постоянно. Я немного нейтралитет в этом плане и свежим взглядом попробую описать ситуацию.

Разобраться сходу тут сложно, давайте разберём плюсы и минусы. Начну с минусов:

1. Вес. Чистый jQuery пакет весит от 80 до 255 КБ, что очень даже не мало по меркам веба, ведь это замедляет загрузку страницы. С этим согласен.

2. Медленнее. Не совсем согласен, но озвучить обязан. Считается, что jQuery медленный и что в целом сторонние библиотеки работают медленно, но я бы не стал утверждать об этом.

Да и вроде всё. Серьёзно. Больше я как-то не слышал о минусах, если что - поправьте. А что насчёт плюсов?

1. Ускорение разработки. Очень приятный синтаксис (субъективно). Код выглядит красиво и лаконично.

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

3. Много из коробки. Слишком много элементов и механик доступно всего одним вызовом, а на нативе подобный функционал будет занимать гораздо больше места. Да и к чему вообще делать что-то с нуля, если просто есть готовое? Новички никогда не напишут правильный код, а опытные программисты не напишут код на столько же оптимизированным, как это сделано в jQuery.

4. Вес. Да, это и плюс. Минифицированная версия jQuery 2.1.3 (последняя массовая на момент написания поста) весит всего 85 КБ. А вы иногда такие исходники пихаете, что это последнее, что повлияет на загрузку страницы.

Ну и казалось бы, всё - идём и используем. Я все же под сомнением. Лично мое мнение - jQuery морально устарел. Я думаю, что лучше было бы использовать что-то более прогрессивное и легко поддерживаемое, типа Angular, Vue, React. Тут и из коробки возможностей больше, и поддержки от крупных компаний. Сейчас эти фреймворки в тренде, так что я бы поступил именно так. Какое-то такое мнение.

#web #useful

Библиотечка swiper.js

Чисто случайно я всё больше и больше стал заниматься JavaScript'ом, так что сегодня хочу рассказать об одной библиотечке, с которой столкнулся. Недавно встала необходимость сделать адаптивный слайдер на сайте, а изобретать велосипед не было никакого желания. Тогда я сел в ваши вот эти интернеты и увидел там swiper.js - библиотека, которая позволяет создать и тонко настроить слайдер любой сложности.

Импортировать библиотеку в проект можно с cdn:

<link rel="stylesheet" href="https://unpkg.com/swiper/swiper-bundle.min.css">
<script src="https://unpkg.com/swiper/swiper-bundle.min.js"></script>

Далее быстро напишем скелет нашего слайдера:

<button class="swiper-button-next"></button>
<button class="swiper-button-prev"></button>
<div class="swiper-container">
    <div class="swiper-wrapper">
        <div class="swiper-slide card"></div>
        <div class="swiper-slide card"></div>
    </div>
</div>

Тут класс div.card отвечает за одну картинку в слайдере, а button элементы - за кнопки перемотки.

Теперь напишем скрипт самого слайдера и так же подключим его. У меня он выглядит так:

const slider = document.querySelector('.swiper-container');

let mySwiper = new Swiper(slider, {
    slidesPerView: 1,
    navigation: {
        nextEl: '.swiper-button-next',
        prevEl: '.swiper-button-prev',
      },
    loop: true,
    autoplay: {
        delay: 5000,
    }
})

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

#web #useful

​Ещё один оператор присвоения в Python.

Думаю мало кто знает (ведь для многих людей читать спеки - грех), но в python 3.8+ появился новый оператор присвоения - Walrus operator. Я точно не знаю как перевести его на русский, но Google Translate говорит, что это "Моржовой оператор", так что не будем перечить гуру. В чём суть?

Теперь в Python есть два оператора присваивания:

# обычное присваивание
# 1. Присваивает переменной x значение 5
x = 5

# walrus operator
# 1. Присваивает переменной x значение 5
# 2. Возвращает 5
(x := 5)

Понятнее на примере:

1. Обычное присваивание:
with open(file) as f:
    while True:
        chunk = f.read(8192)
        if not chunk:
            break
        chunk_processing(chunk)

2. Walrus operator:

with open(file) as f:
    while chink := f.read(8192):
        chunk_processing(chunk)

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

#python

​Что такое DOM и основы программирования.

Кстати, крайне часто все используют такое понятие, как DOM, но некоторые до сих пор не понимают что это. Давайте кратко и своими словами:

DOM - модель элементов в виде дерева, определяющая структуру вложенности элементов, их связи между собой. Термин применим не только к HTML, кстати. Он также применяется в XML и других сферах, но начало свое берет именно из этих двух технологий.

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

DOM сейчас - фундаментальное понятие в программировании, которое должен знать и понимать каждый. А самое главное, что оно предельно простое.

Суть поста - учите базу. Много есть вещей, которые нужно понимать. Без знания методов списка Python лучше не лезть в Django, так же как и без знания стандартных событий JS лучше не лезть в Angular. Учитесь и будьте учимы, всех благ.

#useful #web