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

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

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

#github

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

​Markdown и о документации к коду.

Для разогрева после перерыва начнём с достаточно простой, но интересной темы. Для многих не очевидно что такое markdown, да и вовсе большинство знакомы с ним на основе README.md файлов на гитхабе, например. Но на самом деле это куда более масштабная технология в моём понимании. Если пойти по теории, то Markdown - это очень легкий язык разметки для обычных человеческих текстов. Большинство воспринимают этот язык разметки не слишком серьёзно, что, как мне кажется, немного ошибочно. В моём понимании markdown достоин куда больше внимания, чем многие думают.

Я говорю о нестандартных для многих способах применения. Одна из главных фишек markdown - его легкая транскрипция в другие более сложные языки разметки. А это значит, что ваш размеченный текст может быть легко преобразован в, например, HTML, XML и т.д. (для этого, кстати, есть уже готовые библиотеки почти для всех популярных языков программирования). Всё зависит от ваших задач, но чаще всего даже транскриптор писать самому далеко не обязательно. Также markdown максимально упрощён и даже имеет вокруг себя кучу графических интерфейсов, которые позволят сделать классную разметку даже компьютерному динозавру.
Всё это значит лишь то, что такой простой инструмент может стать классным подспорьем в ведении документации, отчётности, создании контента и почти любой другой работе с текстом.

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

Но в названии всё же есть о документации. К чему это я? К тому, что существует 1001 инструмент для создания документации на основе markdown. Чего только стоят, например, Swagger и Markmap. Первый позволяет максимально быстро и просто, а что главное - читаемо, создать качественную документациию к любому REST API, а второй позволит визуализировать markdown в виде интерактивного mind map. Если вам не требуется отдельный инструмент для документирования, то пользоваться markdown можно в чистом виде, тот же гитхаб сделает всё за вас и преобразует текст в понятные и красивые файлы.

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

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

Какие-то такие мысли.

#design #useful #web #github

​MongoDB - ультимативное решение для ваших проектов.

Давно хотел написать именно о монго. Люблю и обожаю её. MongoDB - система управления базами данных, основой для которой является документноориентированная модель, где каждый документ - JSON. Как уже стало, думаю, понятно, MongoDB - NoSQL база данных, обычное key/value хранилище, которое не требует описания таблиц и тому подобных ритуалов.

Основным преимуществом и недостатком MongoDB можно назвать её простоту и отсутствие каких-либо излишеств. Это прекрасно, потому что в итоге мы имеем легковестный, масштабируемый, отказоустойчивый, производительный и доступный продукт, который к тому же быстро и легко изучается с нуля. Но, в то же время, с помощью MongoDB просто нецелесообразно обрабатывать сложные структуры данных, которые часто требуются некоторым приложениям. Из-за этого приходится балансировать между функциональностью и простотой.

Если для многих иерархия SQL СУБД уже знакома (многие знают, что такое база данных, что такое таблица, колонка и тд.), то в отношении MongoDB люди иногда встают в ступор. Также не для всех понятно что такое документноориентированная модель, так что предлагаю разобрать местную иерархию:

База данных - место хранения нескольких коллекций. Это, так называемый, контейнер для наших коллекций.

Коллекция - место хранения нескольких документов. Аналог из SQL мира - таблица.

Документ - JSON. Это обычный объект (или, если угодно, словарь), который представляет из себя пары key/value.

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

[
    {
        "_id": ...,
        "name": "Denis",
        "email": "email@email.com",
        "isSubscribed": true
    },
    {
        "_id": ...,
        "code": 200,
        "status": "success"
    }
]

Как вы можете заметить, структура совершенно разная. Но стоит заметить и то, что в каждом документе присутствует поле "_id". И на самом деле это не мое желание. Это стандартное поле, которое будет в каждом документе вне зависимости от вашего желания. Если вы не зададите _id самостоятельно, то ему автоматически присвоится значение экземпляра класса ObjectId. Выглядит это примерно так:

ObjectId(4af19ef1109d)

Если вас такой _id не устраивает, то его можно задать самостоятельно при добавлении новой записи, вручную. В монго даже прекрасный автоинкремент первичного ключа не доступен. Его, конечно же, можно реализовать самостоятельно, но из коробки он конечно же недоступен.

Тогда почему же MongoDB так популярна и так часто используется? Простота. Приложение с использованием MongoDB можно развернуть за рекордно короткие сроки. Всё можно изменить в процессе, а при необходимости масштабироваться или переехать на SQL. С монго нас ничего не ограничивает (кроме малой функциональности, конечно). Это прекрасный вариант для простых и не очень приложений с коротким жизненным циклом, для прототипирования и тому подобных проектов, что не подразумевают многолетней поддержки или сложной обработки данных.

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

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

Есть, кстати, готовый класс для подключения под pyTelegramBotApi, который мы опубликовали здесь. Универсальность не заложена осознанно, все сделано для удобства разработки с использованием конкретной библиотеки.

Вот такие дела. Спасибо за прочтение и за интерес к каналу, для меня это важно ❤️

#github #web #useful #theory

​​Сказ о том, как я HTML в JPG конвертировал...

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

В общем, проблем несколько:
— Лень
— Занимает относительно много времени и не приносит удовольствия
— Посты можно оформить только с ПК
— Я счастливый обладатель MacBook на M1, так что для нормальный работы в Photoshop нужно тратиться на лицензию

Я решил найти другое решение: бесплатное, быстрое, удобное и кросс-платформенное. И нашел.

Для решения задачи я хотел использовать Python, но решение это было не лучшее. Нет нормального API для работы с DOM элементами, нужна песочница для запуска браузера, работает медленнее, а самое главное - на Python у меня гораздо меньше опыта. Я реализовал рабочий вариант на imgkit достаточно быстро, но он не устроил меня, код удалён.

Ну и, соответственно, я решил использовать node js. Я имею куда больше опыта c node и javascript, так что рабочее решение, которое по моим тестам работало быстрее решения на Python в 7.5 раз, было готово меньше чем через 20 минут.

Я быстро накатил первую попавшуюся из поиска библиотеку node-html-to-image, воспользовался неплохой документацией, сверстал максимально странный, но рабочий макет и вот, мой html конвертируется в изображение за, в среднем, 2.4 секунды. Ещё за полчаса я изучил библиотеку node-telegram-bot-api и создал на основе скрипта-генератора удобный для себя интерфейс для управления им. Теперь картинки к моим постам генерируются на бесплатном хостинге heroku, и делают они это через API бота в телеграм. Процесс выглядит так.

В итоге, процесс создания картинки максимально упрощён. Я могу оформить пост с любого устройства, где поддерживается клиент телеграмма (то есть даже с утюга), мне не нужно платить за подписку на Photoshop и я даже могу делегировать создание постов на кого-то куда проще.

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

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

Делюсь. Вот. Спасибо за прочтение, это правда важно для меня.

#blog #useful #github #design #chatbot