​Что такое ifmain конструкция в Python.

Начнём с того, что конструкция выглядит так:

if __name__ == "__main__":
    do_somethink()

Здесь __name__ - это "магическая" переменная, содержащая внутри себя название файла, откуда выполняется какая-то функция или операция. Допустим, что у нас есть 2 файла: main.py и file.py.
Внутри файла file.py имеем код:

def foo():
    print(f"А я {__name__}")

В файле main.py реализуем такой код:

import file

print(f"Я {__name__}")
file.foo()

Тогда получим вывод:

>>> Я __main__
>>> А я file.py

Так вот, вышеописанная конструкция проверяет является ли файл главным в стеке вызовов. Все операции, реализованные внутри условия, не выполнятся, если этот файл не будет главным.

Если в файле file.py мы так же добавим:

if __name__ == "__main__":
    print("Привет из условия file.py")

То данный принт мы не увидим, потому что главным файлом в цепочке является файл main.py, а переменная __name__ у файла file.py равна "file.py".

Надеюсь, что объяснил понятно. Перепишу, если будут вопросы. В будущем планирую сделать ещё более подробный пост о магических методах, так что предлагаю вам читать меня чаще :)

#python

​Тернарный оператор в Python.

Есть такая полезная штука во многих языках программирования, как тернарный оператор. Чтобы понять пользу всей этой конструкции давайте рассмотрим такую задачу:
У нас есть переменная num, в которую пользователь положит число. Если num ≥ 0, то в консоль выведем "Положительное либо ноль", а иначе выведем "Отрицательное".

Реализуем код:

num = int(input())

if num >= 0:
    print("Положительное либо ноль") 
else:
    print("Отрицательное")

С помощью тернарного оператора имплементация решения этой же задачи выглядит так:

num = int(input())

print("Положительное либо ноль" if num >= 0 else "Отрицательное")

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

def abs(num):
    if num >= 0:
        return num
    return -num

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

def abs(num):
    return num if num >= 0 else -num

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

Спасибо за прочтение ❤️

#python

Ещё и блог.

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

Начну с того, что за последние несколько недель мы успели закончить и сдать сайт, который у нас с @syth0le заказывали. Прошу заметить, что это был по сути наш учебный проект и заказчик знал об этом. Так что если кто-то найдёт ошибки в коде, а они есть, ну сори. Делали как могли.

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

Во-вторых, канал. Для меня это что-то сакральное, наверное, потому что мне просто нравится помогать и делиться мыслями, это интересно. Мало того, что я надеюсь кому-то помочь, так ещё и вся эта писанина дополнительно обучает меня. Я заново прохожу материал, повторяю и изучаю. Это круто.

Если вынести последние несколько недель в чеклист, то:
• Купил курс Владилена на 120 уроков по нативному js
• Изучаю vue.js вот по этой книге, рекомендую
• Изучаю Flutter и на данный момент в работе над тем тревел проектом, о котором писал ранее.
• К лету планирую собрать команду из 6-8 человек и написать крутое веб/мобильное приложение, но об этом лучше расскажу как-нибудь отдельно
• Хейчу PHP просто потому что
• Продвигаю канал рекламкой
• Пытаюсь завести привычку писать посты на неделю вперед или что-то типа того. Посты уже полностью готовы до 31.10.20
• Стараюсь не забывать о друзьях и себе
• А, ну ещё я добавил свои стикеры, хаха. Без лишних слов, они прекрасны.

Как-то так вышло. Даже душевно вроде.

А ещё просьба. У меня постепенно иссякают идеи для постов, так как уже которую неделю я стараюсь выпускать что-то ежедневно. Писать мне нравится, так что всех неравнодушных я прошу отписаться мне в ЛС, на рассмотрение принимаются любые идеи.

#blog

​Цикл for для списков и словарей.

Я думаю многие знают стандартный способ запуска цикла for для Python через встроенную функцию range(). Записывается он вот так:

for i in range(10):
    print(i)

Но на самом деле в Python существует намного больше способов итерирования. Сегодня рассмотрим некоторые из них. Для работы нам понадобятся некоторые переменные, которые можно посмотреть тут.

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

for value in object: 
    somethink()

На конкретном примере:

for id_ in subscribersIdList:
    print(id_)

Я использую переменную id_ с нижним подчёркиванием после только для того, чтобы избежать совпадения с зарезервированным именем в Python, функцией id().

Если мы будем рассматривать словари, то всё уже гораздо интереснее. Запишем такой вариант:

for key in dict:
    somethink()

Тогда на примере:

for city in temperature:
    print(f"In {city}: {temperature[city]}°C")

Как вы можете заметить, это очень удобно, но обращаться к словарю temperature по ключу не очень удобно. Чтобы упростить работу придётся познакомиться со встроенным методом списка items(). Он возвращает нам список кортежей формата (key, value). Подробнее смотреть сноску.

Применяя этот метод получаем типовую структуру:

for key, value in dict.items():
    somethink()

На примере это будет выглядеть так:

for city, temp in temperature.items():
    print(f"In {city}: {temp}°C")

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

#python

​Оператор 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