​Оператор in и немного о строках.

Раз уж я в прошлом посте вспомнил о списках и словарях, то научимся использовать in не только для итерации, а для булевых функций. Кстати, прошлый пост тоже советуется к прочтению.

Так вот, в дополнение к прошлому посту скажу, что через for in можно перебирать так же и символы в строке:

for char in string:
    print(char)

Как-то совсем забыл об этом, но знать точно стоит. Ну а теперь заведём переменные:

string = "Я бы любил тебя, но ты не Python"

temperature = {
    "Moscow" : 11, 
    "New York": 12,
}
names = [
    "Helen",
    "Denis", 
]

Отлично. С помощью оператора in мы можем проверить почти любое вхождение в объект, вашему вниманию вот такие записи:

>>> "любил тебя" in string // True
>>> "Moscow" in temperature // True
>>> "Helen" in names // True

Я считаю, что они интуитивно понятны. Но стоит обратить внимание вот на что:
>>> "denis" in names // False

В случае строк этот оператор чувствителен к регистру и ищет лишь полное соответствие. Если понадобится найти вхождение независимо, то можно привести строки, например, к нижнему регистру при помощи метода lower().

Удобно? Я думаю, что очень. Уж точно удобнее некоторых методов поиска для строк, так ещё и в разы читабельнее.

Спасибо за прочтение, это правда очень важно ❤️

#python

​Встроенная функция enumerate.

Гениальная и простая и очень полезная функция. Она позволяет вам пронумеровать ваши данные. Рассмотрим на самых простых для понимания примерах, а именно на строках и списках:

string = 'progway'
names = ['Denis', 'Helen', 'Mark']

enumerate(names)
>>> <enumerate object at 0x00D624C8>

list(enumerate(string))
>>> [(0, 'p'), (1, 'r'), (2, 'o'), (3, 'g'), (4, ....]
list(enumerate(names))
>>> [(0, 'Denis'), (1, 'Helen'), (2, 'Mark')]

Как вы можете видеть, функция enumerate возвращает итерируемый объект без представления для пользователя. Поэтому мы делаем списки из этих объектов через конструктор list(). Таким образом, enumerate возвращает список пронумерованных кортежей типа (num, value).

Самый тривиальный вариант применения - цикл for:

for num, name in enumerate(names, 1):
    print(f'{num}: {name}')

Как вы можете заметить, у функции enumerate я указал второй позиционный аргумент. Это число, с которого функция будет нумеровать наши данные. Изначально функция нумерует начиная с нуля, но в данном случае мы начнём с единицы.

Счастья, здоровья вам, и долгих лет жизни. А главное счастья. И здоровья. Счастья.

#python

​Что такое list comprehension в Python.

Очень удобная сущность, которая позволяет определять списки. Самое приятное тут то, что с помощью list comprehension мы определим список быстрее, чем любым другим способом, если я не ошибаюсь.
Итак, вот как выглядит полная структура:
[foo(x) if condition else bar(x) for x in sequence]

Это общая формула. Блоки else и if не обязательны, то есть наше представление списков может быть упрощёно вплоть до:
[x for x in sequence]

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

/// квадраты натуральных чисел от 1 до 10
[x ** 2 for x in range(1, 11)]

/// только чётные натуральные числа от 1 до 20
[x for x in range(1, 21) if x % 2 == 0]

Обратите внимание на то, что if тут в конце. Такая запись характерна для list comprehension без блока else

/// получить список символов из строки
[letter for letter in word]

Насчёт многочисленных условий:

/// список чисел от 1 до 200, одновременно делящихся на 2, 7 и 11
[x for x in range(1, 201) if x % 2 == 0 and x % 7 == 0 and x % 11 == 0]

Кстати, такое число всего одно: 154 = 2 * 7 * 11

/// список кортежей типа (type, num) от 1 до 5
[("Нечётное", x) if x % 2 != 0 else ("Чётное", x) for x in range(1,6)]

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

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

#python

Генераторы и comprehensions в Python.

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

Comprehensions ≠ генератор.
Я поспешил упростить теорию, но по хорошему путать эти сущности не нужно. В интернетах ваших часто встречается объяснение comprehensions именно как генераторов, но на самом деле генератор - это уже совершенно иная вещь, о которой я планировал рассказать чуть позже, так что в скором времени будет пост ещё и о них.

На самом деле верно определить list comprehensions как один из вариантов представления списка. Можно получить список в цикле for, например, а можно при помощи list comprehensions. Преимущество такого представления, как я и сказал, в скорости и краткости записи. Но так как эта запись, по сути, возвращает нам новый список, часто её называют генератором, что не верно.

Прошлый пост я поправил, в следующих постах постараюсь больше такого не допускать. Добра вам.

#python

​Представление словарей и множеств.

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

/// список
[x ** 2 for x in range(1, 11)]

/// множество
{x ** 2 for x in range(1, 11)}

/// словарь
{x: x**2 for x in range(1, 11)}

Полная формула для словарей выглядит сложнее:
{ (key if condition else defaultKey):(value if condition
else defaultValue) for key, value in sequence }

А вот для списков она аналогична list comprehensions.

#python

​Насчёт принципов программирования.

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

KISS - "Keep it simple, stupid" - принцип, который утверждает, что все компоненты программы должны оставаться простыми. Именно в такой расшифровке я дам его тут, хотя есть и немного другие варианты. Главное, что суть одна и та же.

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

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

Надеюсь, что всё верно объяснил. Если что-то не так, то моя личка открыта для всех, буду рад подискутировать 🙂

#useful #principles #theory

​Принцип проектирования DRY.

Продолжу эту полезную на мой взгляд рубрику. Сегодня поговорим о принципе DRY - "Don't repeat yourself". Акроним, который просит нас не повторяться. Суть принципа заключается в том, что каждый компонент программы должен иметь единственное и авторитетное представление.

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

При соблюдении DRY вы избегаете клонирование кода и тем самым делаете код более читабельным, выразительным и упрощаете его поддержку в будущем.

Что интересно, нарушение принципа DRY - это WET - "Write Everything Twice" или "We enjoy typing". Интересная игра слов получается.

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

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

#useful #principles #theory

​Принцип проектирования YAGNI.

YAGNI - «You aren't gonna need it» - «Вам это не понадобится».
Достаточно интересный принцип, который должен знать каждый программист. Он просто позволяет вам делать меньше. Хотя это, наверное, слишком громко сказано🙂
Принцип продвигает идею того, что именно сейчас вы должны максимально отказаться от избыточного функционала даже в том случае, если он понадобится в будущем. То есть только самое нужное, только самое необходимое и всё по очереди, постепенно.
Чем-то напоминает KISS, о котором мы говорили тут, но это всё же немного о другом. Да и в целом в принципах одно на другое частенько похоже, так что этому удивляться не стоит.

У YAGNI есть целый список правил, которые он содержит в себе. Они даже в википедии описаны неплохо, что меня убедило, полный список можете прочитать тут.

Если кратенько, то:
•‎ Тестирование существующего лучше добавления нового функционала.
•‎ Чем больше функций, тем сложнее обслуживать код.
•‎ ПО может становится неоправданно сложным.

Да и тем более, помяните Джобса с его радикальным минимализмом.
На этом кратенько вроде всё. Спасибо за прочтение ❤️

#useful #principles #theory

​SOLID - Принцип единственности ответственности.

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

Первая буква акронима и первый принцип - SRP - Single Responsibility Principle.
Принцип единственности ответственности говорит нам о том, что у модуля должна быть только одна причина для изменения, а также постулирует то, что каждый класс должен отвечать за что-то одно.
Суть заключается в том, чтобы при возникновении любых изменений в программе задействовалось как можно меньше её модулей. В идеале каждое изменение будет затрагивать только один класс.
Также нужно думать и о будущем, чтобы классы можно было легко расширять без нарушения этого принципа. Есть такой антипаттерн God object, вот его точно допускать нельзя.
Как итог получаем очень серьёзную деструктуризацию, которая помогает нам на всех этапах работы с кодом и делает его более читабельным.

О SOLID буду рассказывать очень кратенько. В целом, в этих принципах нет ничего сложного и они абсолютно легко гуглятся. А я тут поболтаю немного и на этом хватит) Но по всем вопросам всегда открыта личка, прошу.

#principles #theory

​SOLID - Принцип открытости/закрытости.

Второй принцип из группы SOLID - OCP - Open/closed principle - Принцип открытости/закрытости.
Этот принцип утверждает, что каждый элемент программы (модуль, функция, класс) должен быть открыт для расширения, но закрыт для изменения. Это ментальная сущность, скажем так.
Это совсем не значит, что нужно запретить редактирование фала и открыть его только на чтение, нет. Это означает, что все эти элементы программы способны менять свою функциональность без изменения уже написанного кода. То есть то, что мы уже написали - это закрытая для изменения часть, а то, что мы допишем для расширения функционала - это открытая для расширения часть.

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

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

Спасибо тем людям, что терпят моё долгое отсутствие и остаются читателями в любом случае. Это невозможно недооценить ❤️

#principles #theory

​SOLID - Принцип подстановки Барбары Лисков.

Почему-то я слышал мнение, что это самый сложный для понимания принцип, но по моему мнение крайне ошибочное.
LSP - Liskov substitution principle - один из самых простых принципов. Суть его заключается в том, что компоненты программы (функции, модули и т.д.) должны одинаково успешно обрабатывать как экземпляр класса родителя, так и экземпляр потомка класса не зная об этом.

Для понимания достаточно описать супер простой пример, скажем, на том же питоне:

class Person:
    def __init__(self, name):
        self.name = name

class Programmer(Person):
    def __init__(self, name, language):
        Person.__init__(self, name)
        self.language = language

person = Person('Денис')
programmer = Programmer('Макс', 'Python')

А теперь реализуем функцию, которая вернёт имя человека:

def getName(person): 
    return person.name

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

print(getName(person))  // Денис
print(getName(programmer))  // Макс

Всё прекрасно работает как с классом родителем, так и с классом наследником. Если бы было бы иначе, то такая ситуация - нарушение LSP.

В оригинале Барбара Лисков даёт определение этого принципа чисто математически. Возможно, именно из-за этого оно и кажется непонятным. Надеюсь, что я смог объяснить яснее.

Спасибо за прочтение, это важно ❤️

#principles #theory

​SOLID - Принцип разделения интерфейсов.

ISP - Interface segregation principle - один из самых простых для понимания принципов. Его суть заключается в том, что большое количество интерфейсов для разных пользователей лучше, чем один большой интерфейс для всех.

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

В этой ситуации мы рассмотрели так называемый «Узкий-Широкий интерфейс», что возможно в ситуации с двумя пользователями. В реальности же пользователей может быть больше и чтобы не нарушить этот принцип придётся выделить собственный интерфейс под каждого пользователя.

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

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

#principles #theory

​SOLID - Принцип инверсии зависимостей.

DIP - Dependency inversion principle - последний принцип из группы SOLID. Для меня самый сложный. Суть заключается в том, что программные модули верхних уровней не должны зависеть от модулей нижних уровней.

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

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

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

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

Неплохими вариантами будут:
— Книга Роберта Мартина «Чистая Архитектура»
— Серия постов на сайте makedev.ru
— Серия постов на webdevblog.ru
— Плейлист на канале Сергея Немчинского

Спасибо за прочтение, это важно ❤️

Неожиданно пропасть на 20 дней, а потом вернуться - в моём стиле.

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

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

2. Чтобы было чем делиться - нужно, чтобы что-то происходило вокруг нас. Но в моей жизни в январские каникулы не осталось ничего более, кроме как рутины, сессии и каких-то обязательств. Я так же продолжаю черпать новую информацию отовсюду, но иногда посещает чувство, что периодами меня накрывает какой-то информационыый вакуум (наверное, в простонародье - лень). Какие-то знания получать становится не так легко, а продуктивность в январе у меня заметно упала.

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

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

— MongoDB. О самой популярной NoSQL СУБД в мире и о key-value хранилищах в целом.
— О Markdown и документации к коду.
— Контекстные менеджеры.
— Асинхронный код.
— Важность архитектуры и выбор правильного архитектурного подхода в разработке ПО.
— Выгорание и отдых.
— Профессиональный логгинг вашего приложения.
— Что такое SPA.
— Что такое парсинг и сущесвует ли авторское право на контент.
— Python yeild.
— Механизм замыкания как расширение универсальности вашей программы.
— Linux, Unix, WSL и тому подобные штуки (передаю привет всем, с кем мы общались в лс на эту тему, спасибо вам).
— Bash-скрипты - почему, зачем и как.

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

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

По классике, товарищи, спасибо за прочтение. Это, кстати, не просто слова❤️

#blog

​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

Насчёт отдыха и выгорания.

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

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

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

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

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

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

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

Достаточно очевидные мысли, но понимать самому и слышать подтверждение извне — разные вещи. Как-то так.

#blog

​Что такое синхронный и асинхронный код.

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

Что же такое синхронный и асинхронный код в однопоточных языках (типа JavaScript или Python):

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

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

Но из-за асинхронного кода могут наблюдаться подобные варианты исполнения кода:

// code
setTimeout(() => {
  console.log("Сообщение сразу")
}, 1500)

console.log("Сообщение через 1500мс")

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

// console out
Сообщение через 1500мс
Сообщение сразу

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

Существует не один способ работы с асинхронным кодом, о которых мы поговорим позже. Вообще этот пост и должен был рассказать об этом подробнее сразу, но получилось как-то слишком много информации, так что пришлось поделить на несколько постов.

В общем, продолжение следует. И спасибо за прочтение спустя 40 дней с прошлого поста. Вы золото ❤️

#web #javascript

​Обработка асинхронного кода.

Этот пост - как продолжение к предыдущему, так что сначала советую прочитать именно его.

В JavaScript мы имеем несколько возможных вариантов обработки асинхронного кода:
- асинхронные callback'и,
- промисы,
- синтаксис async/await.

Callback'и в этом посте мы не будем рассматривать. Остаются промисы и синтаксис async/await, которые идет, конечно, отдельными пунктами, но вообще-то стоит понимать, что в JavaScript операторы async/await - это не более чем синтаксический сахар, надстройка над промисами. Отсюда следует и то, что промисы и новый синтаксис могут использоваться совместно.

Перепишем код с использованием промиса:

new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve(console.log("Сообщение через 1500 мс"))
  }, 1500)
}).then(() => {
  console.log("Второе сообщение");
})

Что тут происходит?
1. Мы создаём новый Promise через конструктор.
2. Внутрь конструктора мы подаём функцию, которая принимает в себя 2 параметра: resolve и reject. Это две функции. Особенно углублять не будем, но когда вызывается resolve - промис считается выполненным, а когда reject - выбрасывается ошибка.
3. Метод then вызывается от нашего промиса, принимает в себя так же функцию (которая в свою очередь так же может принимать в себя параметры, но в этом примере они не нужны). Эта функция из метода then гарантированно выполнится после промиса.

И такой код даст нам ожидаемый результат:

// console out
Сообщение через 1500 мс
Второе сообщение

И таких методов then может быть много в цепочку:

new Promise(...).then(...).then(...).then(...) ... .catch(...)

Тут вы можете заметить ещё и метод catch. Он нам нужен для обработки ошибок в промисах.

Если совсем кратко, то вот так можно описать промисы. Они необходимы для понимания того, как работает синтаксис async/await в JavaScript. И этот синтаксис не применим к нашему примеру в чистом виде, потому что функция setTimeout не возвращает Promise, а, как я и сказал выше, без промисов async/await не работает. Но промис возвращает, например, fetch запрос. Fetch позволяет нам делать HTTP запросы и позвращает промис.

Попробуем:

async function getDataFromServer() {
  // сделаем запрос
  const response = await fetch('https://jsonplaceholder.typicode.com/todos')

  // обработаем данные
  const data = await response.json()

  return data
}

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

async function getDataFromServer() {
  // сделаем запрос и преобразуем полученные данные
  return await fetch('https://jsonplaceholder.typicode.com/todos')
                      .then(response => response.json())
}

По моему, получается лаконичнее.

Примерно так. Не знаю как часто будут новые посты, но они точно будут. Надеюсь будет почаще.

#javascript #web