Слишком много было про 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

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

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

Давайте начну с примера из личного опыта. Может быть затяну из-за этого, но должно быть интересно. Так вот, недавно я работал в стартапе из кремниевой долины. Мы с командой создавали чат-бота, который будет работать во всех мессенджерах, будь то 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": "info@dialektika.com",
    "site": "www.dialektika.com"
  } 
}

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

<book>
  <name>JavaScript для чайников</name>
  <authors>
    <author>Крис Минник</author>
    <author>Ева Холланд</author>
  </authors>
  <publisher>
    <name>Диалектика</name>
    <email>info@dialektika.com</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