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

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

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 protected]",
        "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

О переходе.

Обычный пост из серии блога, где я хочу объяснить почему на канале теперь будет JavaScript (не только он).

Я думаю, многим не понравится, что с Python я резко и без особых предпосылок перескочил на JavaScript. Как говорится, ничего не предвещало беды, но пришло откуда не ждали.

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

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

Почему должно быть всё равно?
Большинство концептов, существующих в программировании, можно рассмотреть обособленно от конкретного языка. В современном мире различия не так критичны, поэтому огромная часть теории актуальна от языка к языку. Я не знаю Java или С#, но практически все книги по архитектуре приложений и тому подобным темам я прочитал с примерами на этих двух языках. И если отбросить всю предвзятую ненависть к JavaScript, которая присуща комьюнити сегодня, то на каком бы языке теория не была описана - при желании всё легко читается и понимается. Даже на JavaScript.

#blog

​Что такое область видимости переменных

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

Чтож, область видимости переменных в вашей программе - это та область, откуда переменная доступна. И тут нужно понимать, что видимость переменных распространяется исключительно наследовательным путем (в виде дерева, графа). Это значит, что переменные из области родителя доступны в детях, но не наоборот. Что за дети и родители?
Рассмотрим пример:

const fib = [ 1, 1, 2, 3 ]

const sayHello = (name) => {
  const surname = "Putnov"
  console.log(`Hello, ${name} ${surname}`)
}

{
  const channel = {
    name: "progway",
    theme: "blog"
  }
}

fib // [ 1, 1, 2, 3 ]
surname // Error: is not defined
channel // Error: is not defined

В данном случае мы видим, как области видимости создаются внутри файла.
Области видимости тут:
— весь файл
— функция sayHello
— область внутри { } с объявлением объекта channel

Если совсем упростить, то можно сказать, что область видимости в JavaScript создаётся внутри { фигурных скобок }. Если понять этот концепт тут, то в нормальных языках всё будет ещё проще.

Внизу мы пытаемся обратиться к переменным. Массив чисел Фибоначчи доступен, а вот переменные surname и channel недоступны. Это из-за того, что объявлены они в дочерних областях видимости. В обратную сторону доступ сработает, например: 

const identificators = [11, 24, 93, 8]

function foo() {
  console.log(identificators[0]) // 11 
}

foo()

Ошибки не будет, так как вызов переменной идет из области видимости родителя.

Но, JavaScript имеет разные спецификации синтаксиса и в примерах выше я использовал ES6 синтаксис. При объявлении переменной через let и const переменная не покидает пределы своей области видимости.
А теперь попробуем использовать var:

{
  var name = "progway"
  const age = "less than 1 year"
}

name // "progway"
age // Error: is not defined

Вот так вот неожиданно переменная, объявленная через ключевое слово var появляется в глобальной области видимости, чего, например, с const не происходит.

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

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

#javascript #theory

​Замыкания

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

Замыкание с точки зрения теории — это способность функции запомнить своё окружение (ссылки на переменные) в момент вызова. Это такой способ манипуляции областями видимости, который позволяет «замкнуть» переменную внутри тела функции. При помощи такой манипуляции мы можем расширить функционал обычных функций путём создания новых функций с замкнутыми в них переменными. На теории всё вообще не понятно, хотя я правда старался. Рассмотрим пример:

function sayHello(name) {
  function wrapped() {
    console.log(`Привет, ${name}`)
  }
  return wrapped
}

// создаем много функций на базе одной
const helloDenis = sayHello("Денис")
const helloKate = sayHello("Катя")
const helloMax = sayHello("Макс")

helloDenis() // Привет, Денис
helloKate() // Привет, Катя
helloMax() // Привет, Макс

Переменная name является замкнутой.

Каким образом мы добиваемся замыкания? В теле функции sayHello мы объявляем локальную функцию, которая остается доступной только внутри тела этой самой функции (из-за особенностей областей видимости). Возвращаем эту функцию. А у этой функции есть доступ к переменной name. Значение переменной при вызове sayHello замыкается, так как при каждом вызове функции sayHello внутри нее создается своя локальная переменная name, никак не зависящая от вызова этой функции снова. На практике должно быть понятнее.

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

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

#javascript #theory

​MVC на пальцах

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

MVC — это паттерн проектирования. Аббревиатура от слов Model, View, Controller. И, несмотря на такую большую распространненность и важность в целом, всё максимально просто. Суть заключается в том, что приложение разбивается на 3 блока, каждый из которых имеет свои функции. Три этих блока, соответственно, — модель, представление и контроллер.

Рассмотрим каждый из блоков отдельно:
• Модель — это блок, который отвечает за данные нашего приложения, и, по сути, во многом определяет его. Этот блок кода определяет данные и способы взаимодействия с ними.
• Представление — блок, который отвечает исключительно за представление наших данных. Этот блок кода отвечает только за то как будет выглядеть наше приложение и не несет в себе никакой бизнес-логики.
• Контроллер — блок, который организовывает взаимодействие модели и представления. В контроллере мы вешаем прослушку событий, взаимодействуем с данными и в целом организуем в этом блоке всю бизнес-логику нашего приложения.

На примере,
Ноутбук: монитор (представление), память (модель), и процессор (контроллер)
Ресторан: вкусный кофе (представление), официант (контроллер), и повар (модель)

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

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

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

#theory #patterns

​Итерирование по сущностям: map

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

Функция/метод map реализована во многих ныне используемых языках программирования. Скажем так, реализация функций map, reduce и filter дает языку хоть какое-то право называться функционально-поддерживаемым. Так вот, одна из этих функций — map, используется для перебора массива. В JavaScript это метод класса Array.

a = [1, 2, 3].map(callback, context) 

Самое важное про map:
- метод массива
- принимает в себя callback функцию и контекст
- возвращает новый массив

Метод map проитерируется по всему массиву и применит callback функцию к каждому из элементов массива с указанным контекстом context. Тут важно понимать, что контекст — не обязательный параметр. Чаще всего метод применяется без него.

Что за функцию мы применяем? Это обычная callback функция, которая принимает в себя 3 параметра: элемент, его индекс и копию итерируемого массива:

a = [1, 2, 3].map((element, index, array) => {
    console.log(`${element} is the ${index} element of ${array}`)
})

// Output: 
1 is the 0 element of 1,2,3
2 is the 1 element of 1,2,3
3 is the 2 element of 1,2,3

Но только есть один нюанс:

console.log(a)

// output
[ undefined, undefined, undefined ]

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

a = [1, 2, 3].map(element => element ** 2)
console.log(a)

// output
[1, 4, 9]

Теперь мы получили квадраты от значений массива.

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

#javascript #web #theory #useful

​А в чём все таки разница между var, let и const?

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

var - устаревший способ объявления переменных, который был актуален до выпуска ES6. Ключевое слово var объявляет переменную внутри функциональной области видимости, то есть внутри функции, что и следует из названия. Переменная, объявленная внутри функции, снаружи функции доступна не будет:

function foo() {
  var i = 0
}
console.log(i) // i is not defined

Область видимости переменных, объявленных через let и const ещё уже — она блочная:

if (true) {
  var i = 0
  let k = 0
}

console.log(i) // 0
console.log(k) // k is not defined

То есть переменные, объявленные через let и const не доступны уже за пределами блока.
Блок — область { между фигурными скобками }

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

Все остальные различия — вторичны. То, что описал здесь я — главный смысл введения новых способов объявления переменных. И спасибо за прочтение, это правда важно.

#javascript #web #theory