Некоторое время назад мы касались вопросов функционального программирования на Swift в контексте монад и функторов (flatMap там тоже был). Теперь давайте рассмотрим концепцию flat_map в языке Python.

Ну, здесь нет built-in функции flat_map. Но её можно имплементировать самостоятельно, причём несколькими разными способами. Поэтому, вместо того чтобы дискутировать на тему на создания «pure pythonic» функции flat_map, давайте лучше рассмотрим более интересный вопрос:

Как создать функцию flat_map в python наиболее эффективным способом?

Определение

Начнём с определения. flat_map это операция, которая принимает список элементов типа A и функцию f типа A -> [B]. Функция f таким образом применяется ко всем элементам первоначального списка, и затем все результаты конкатенируются. Простой пример:

Хотя данная операция довольно простая, идея, лежащая в её основе называется «монада». Насколько я знаю, есть 4 простых способа создать flat_map в Python:

• цикл for и extend
• двойной list comprehension
• map и reduce
• map и sum

Измерение

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

a) 100 списков, каждый содержит 10 чисел типа int
b) 10 000 списков, каждый содержит 10 чисел типа int
c) 10 000 списков, каждый содержит 10 объектов (инстансов класса)

Чтобы сделать это, я буду использовать функцию check_time и дополнительную простую функцию id для её передачи в flat_map:

Весь используемый код можно найти по ссылке.

Map reduce

Наиболее «функциональный» ответ на поставленную задачу – это комбинация map и reduce. Потребуется импорт библиотеки functools (документация), так что даже при всей его крутизне, это всё таки не решение в одну строчку.

Результат:
a) 0.1230 мс
b) 1202.4405 мс
c) 3249.0119 мс

Тут map можно легко заменить на list comprehension, но особой разницы заметно не будет.

Map sum

Другое «функциональное» решение – это использовать sum. Мне нравится этот подход, но его производительность также оставляет желать лучшего. Результаты в принципе не лучше, чем в предыдущем случае.

Результат:
a) 0.1080 мс
b) 1150.4400 мс
c) 3296.3167 мс

For extend

До сих пор наши имплементации функции flat_map работали относительно быстро для малого размера списка, и были медленными для большого. Однако данная «классическая» имплементация в 1000 раз быстрее! Жаль конечно что это не решение в одну строчку. Но, наверное, это относительно небольшая цена за такую производительность.

Результат:
a) 0.0211 мс
b) 2.4535 мс
c) 2.7347 мс

Интересно то, что разница между скоростью работы flat_map в случае со списком интов и списком классов теперь не такая уж и большая.

List comprehension

Настоящий «pythonic» подход (и в принципе тоже функциональный). Единственный минус данной реализации, это слегка запутанный двойной for цикл.

Результат:
a) 0.0372 мс
b) 4.1477 мс
c) 4.5945 мс

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

Давайте посмотрим что будет если мы заменим list comprehension на generator expression в последнем примере:

Результат:
a) 0.0008 мс
b) 0.0008 мс
c) 0.0007 мс

Так вот он наш победитель? А стоп, мы не развернули само выражение. Давайте развернем, чтобы проверить его реальную производительность. Кроме того, развернем и list comprehension, для того, чтобы посмотреть как ведёт себя код в идентичных условиях:

list comprehension:
a) 0.0537 мс
b) 5.3700 мс
c) 5.7781 мс

generator expression:
a) 0.1512 мс
b) 13.0335 мс
c) 13.3203 мс

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

Заключение

Простая проблема, много решений, но только один победитель... ну или два. Я считаю разумным отдать первое место как for+extend, так и list comprehension. Первый вариант хорош тогда, когда ваша главная забота – производительность. Второй вариант – это действительно хороший выбор, когда вам нужно удобное решение в одну строчку.

Поэтому в следующий раз, когда вам нужно будет применить flat_map в Python, просто используйте list comprehension. И самое главное, не поддавайтесь соблазну использовать reduce или sum для длинных списков!

Оригинальный текст

Статья подготовлена для канала Hello World.

Вместо введения

Решил набросать небольшой пост по ООП... Вот пример композиции и агрегирования с точки зрения кода, написанного на Swift (на Python можно сделать по аналогии). Посмотрев на этот код, вы сможете оценить разницу между ними.

Кстати, в объектно-ориентированном дизайне композиция предпочтительнее наследования, о чем я говорил и в прошлой статье, и даже джавист Джошуа Блох заявлял о её важности в классической книге по Java (Effective Java).

Начать стоит вообще с того, что и агрегация и композиция – это подклассы ассоциации, ну или если можно так выразиться «частные случаи» её проявления. Ассоциация по сути говорит о взаимоотношении с объектом.

Когда мы говорим об ООП, мы всегда думаем об объектах (экземплярах класса), классе (своеобразном «blueprint'е» объектов) и отношениях между ними. Объекты связаны и взаимодействуют друг с другом с помощью методов. Если объект одного класса может использовать методы, предоставляемые объектом другого класса, то такие отношения называются ассоциациями.

Ну ладно, довольно болтологии. Как говорил Линус Торвальдс,

Talk is cheap. Show me the code.

Агрегация

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

Вот например как на картинке выше. Если инстанс (объект) класса Library будет уничтожен, books будет продолжать своё существование, и наоборот.

Если не нравится пример с книгами, вот тут мой любимый пример с машинками и двигателями. Здесь важно понимать главное, «слабая ассоциация» подразумевает, что Car не владеет Engine. Engine создается где-то вовне, и передается внутрь Car. Это и есть агрегация.

Композиция

Композиция, или «сильная ассоциация» – это такой тип отношений, когда класс именно «владеет» объектом и несёт ответственность за его время жизни.

Теперь же если инстанс (объект) класса Reader будет уничтожен (деинициализирован), вместе с ним умрёт и books. Как вы уже могли заметить, в этом примере ничего не передается внутрь Reader. Все объекты класса Book создаются внутри самого Reader.

А вот и пример с машинками. Поэтому композиция еще называется «сильной» ассоциацией, в этом случае Car именно «владеет» Engine и ответственен за время жизни его инстанса, если уничтожить инстанс класса Car, пропадет и созданный внутри него инстанс Engine.

Заключение

Грамотный выбор типа отношений между классами и объектами – залог успеха любого ООПшника! Давайте еще раз кратко подытожим все вышесказанное.

• Агрегация подразумевает такой тип отношений, в которых дочерняя структура может существовать независимо от родительской. Пример: Person (родительский класс) и Student (дочерний класс). Если Person будет удалён, Student всё равно продолжит существовать.
• Композиция подразумевает такой тип отношений, в которых дочерняя структура не может существовать отдельно от родительской. Пример: House (родительский класс) и Room (дочерний класс). Room не существует отдельно от House.

Если логика задана так, что дочерней структуре необходимо существовать вне зависимости от родительской, значит нужно использовать агрегацию. Если нет – композицию.

Статья подготовлена для канала Hello World.

Сегодня мы продолжим говорить о том, как устроена мобильная разработка крупных российских продуктов. В гостях у нас, как и в тот раз, тимлид iOS команды разработки Cardsmobile – Богдан Маншилин. В предыдущей статье мы разбирали несколько крупных российских компаний: Яндекс.Еду, Ламоду и Ultimate Guitar. Теперь мы поговорим о том, как попасть в такую компанию, а также о проблемах этих компаний.

Вот допустим, я iOS-разработчик. Как мне попасть в крупную российскую компанию?

Ну, в первую очередь нужно подать туда резюме, чтобы тебя вообще в эту компанию рассмотрели (смеётся). Хотя, конечно, вопрос очень интересный, поскольку сразу возникает ещё куча наводящих вопросов. Какой у тебя сейчас уровень? Готовы ли тебя туда рассматривать или нет? Вот, например, когда я пытался пробиться в Ultimate Guitar, мой уровень был совсем джуновским. В этой истории интересно, что мне на самом деле хотелось туда попасть. Я листал вакансии и видел, что есть компании, которые занимаются какой-то разработкой, чем-то непонятным. У них есть какие-то приложения, которыми никто не пользуется.

И вот смотрю – Ultimate Guitar. Меня тогда заинтересовало то, что я сам в то время учился играть на гитаре, и, в общем-то, продукт мне очень понравился. И я тогда подумал: окей, но как же мне, junior-разработчику, попасть в такую крутую компанию? Учитывая то, что у них было написано, что они рассматривают кандидатов от уровня middle и выше (от 3 лет опыта и выше). У меня на тот момент опыта работы был неполный год. Я подошел к этому всему с творческой точки зрения. Я решил, что если я просто скину свое резюме, где написано про неполный год опыта, где я что-то пытался делать с переменным успехом, то, скорее всего, ничего не получится. Они получают сотни таких резюме в день, и вряд ли вообще обратят на меня внимание.

Возникает вопрос: как же сделать так, чтобы на меня обратили внимание? Единственным решением, которое на тот момент я придумал, было создать, условно говоря, сайт о себе. Я знал: есть ребята, которые делают не просто резюме, а создают крутые сайты, где есть интерактив, и там можно узнать о человеке, посмотреть его портфолио. Очень часто такие сайты делали дизайнеры. Я видел как javascript-разработчик создал небольшую игру в браузере: там на машинке подъезжаешь к разным точкам и смотришь разные факты о нем. Меня это заинтересовало, и я подумал, что было бы неплохо сделать нечто подобное. Возникла идея, которую я реализовал где-то за 2 дня. Вышло, правда, немного топорно, но уже с приемлемым качеством.

Примешь синюю таблетку – и сказке конец

Это был небольшой сайт, развернутый на github pages. Написал я его следующим образом: просто взял уже готовый фреймворк, который отображал сайт с каруселью картинок, на которых я описал 5 своих soft скиллов.

Конечно это сейчас я бы их назвал soft скиллами, а тогда я описал 5 отличительных черт, характеристик самого себя.

Причём описывал я их таким образом, как будто меня описывает со стороны какой-то другой человек, например, мама, бабушка, неважно. Это выглядело максимально нагло, будто бы я такой молодец и красавчик. Кроме того, я записал аудио, где я что-то проговариваю по каждому слайду, что имею в виду под той или иной характеристикой, привожу примеры. В конце, конечно, музыка, надпись «спасибо за просмотр» и мои контакты для связи. А чтобы у рекрутеров было и нормальное резюме, я сделал главную страницу в виде Морфеуса из «Матрицы», протягивающего две таблетки – красную и синюю. На красной – презентация. А синяя была подписана как «скучное резюме». По этой ссылке и скачивалось то резюме, в котором ничего не было, год работы с такими-то фреймворками и всё.

На удивление, это сработало. История закончилась тем, что я стал единственным junior-разработчиком, которого Ultimate Guitar релоцировал из другого региона России.

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

Мешало, но не сильно. Секрет прост: работаешь с 9 утра до 9 вечера, 6 дней в неделю, иногда остаешься после работы. Вот тогда всё нормально. Тогда можешь соответствовать уровню мидла, и выполнять тот же уровень работы за день.

То есть, ты постарался и нагнал?

Работая в таком темпе, уже через год-полтора я чувствовал, что вполне соответствую позиции middle-разработчика, а потом ушёл в другую компанию.

А как у вас обстоят дела в Cardsmobile? Как попасть сейчас в вашу компанию?

В Cardsmobile, наверное, всё-таки чуть попроще (смеется). Не нужно кидать такое резюме. Хотя на данный момент, даже если junior-разработчик нам сильно понравится, мы просто физически не сможем его взять. Просто у нас немного разные подходы. Если Ultimate Guitar, в принципе, были готовы брать джунов, даже когда у них не было ресурсов на их обучение, то мы пока относимся к этому с бо́льшей ответственностью. Если мы берем джуна, значит мы будем его развивать. То есть, развиваться – это не задача самого джуна, это наша задача – передать ему знания. Джунов мы временно не рассматриваем, но на позиции middle-разработчик или senior-разработчик достаточно просто скинуть мне резюме. У нас много открытых вакансий. В связи с выходом на международные рынки (в Европу) мы расширяем штат и нанимаем много разработчиков с уровнем от мидла. То есть хотя бы от двух лет опыта работы. Вакансии можно найти на hh или спросить у меня в ЛС в Telegram.

Проблемы российских компаний

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

Для начала, давай проясним, что ты имеешь в виду под «техническими проблемами»?

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

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

А есть проблемы, условно говоря – дисфункции. Что-то системно мешает нам добиваться лучшего результата. Несколько таких примеров я могу привести из Ламоды и Ultimate Guitar того образца. Что интересно, такие дисфункции зависят от того, с какой точки на них смотреть. С одной стороны это – проблема, а с другой – преимущество. Вот например, Ламода – это компания с товарищеским стилем управления. То есть, там построен такой safe-space, разработчиков там не наказывают и относятся очень лояльно. Всех очень любят и не тревожат, и ты можешь работать в очень комфортных для себя условиях. Это плюс для Ламоды, по сути это даже является некой частью их культурного кода. Если подумать о том, что такое Ламода, то в первую очередь приходит в голову мысль, что здесь комфортно и хорошо. Есть safe-space, все очень дружелюбные и работать приятно.

Однако, с моей точки зрения подобный подход немного расхолаживает, расслабляет. Если говорить о том количестве достижений, которое у меня было в том же Ultimate Guitar, когда я был джуном, то оно гораздо больше, чем количество достижений в Ламоде. Я мог позволить себе расслабиться и спокойно работать в своём темпе, и постепенно это расхолаживало. С каждым разом я всё медленнее и медленнее работал. А вот в Ultimate Guitar того периода всё было по-другому. Интересно, что Ultimate Guitar очень активно нанимал джунов, несмотря на то, что их развитием никто особо не занимался.

Удалил ветку develop

Я вспомнил очень забавный случай. Когда я только пришел в Ultimate Guitar, в какой-то момент я не очень хорошо умел обращаться с гитом (git, система контроля версий). За весь мой год опыта работы (до Ultimate Guitar), я практически всё время работал сам, разве что иногда в паре. Мы использовали svn, и конфликтов там особо не было. Я сам коммитил и сам с собой работал в репозитории. А тут я пришёл в большую команду, и с какими-то коммитами законфликтовал. Не помню, в чём была история, но однажды, решая проблему с репозиторием, я пришел к тому, что удалил у себя ветку develop, правда, локально.

Локально?

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

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

Однако в тот момент проблема заключалась в том, что в компании была построена культура «развивайся или умри». Всё было заточено на рост, все должны были развиваться. Это было требование к каждому из сотрудников: через полгода-год ты должен стать лучше. Однако никакого прозрачного процесса, никакой помощи в развитии на тот момент не было. Были задачи. Вся помощь заключалась в том, что тебе ставили сверхамбициозные цели. То есть ставили цели таким образом, чтобы ты не мог их выполнить. А дальше сиди и разбирайся, выкручивайся сам, чтобы их выполнить. И этот подход, несмотря на то, что он должен был стимулировать людей находить новые решения, развиваться, по факту, стимулировал (лично меня) работать больше. Больше и больше. Сначала я работал с 9 утра до 9 вечера, потом в какой-то момент, когда мы пилили приложение на React-Native, я работал с 9 утра до 4 утра, и всё равно не успевал ничего сделать. Еле-еле мы успели к моменту демо этого прототипа для менеджеров Apple, и потом я, фух, выдохнул. Однако для меня цель была на тот момент неподъёмной. Даже не знаю, каким образом я её достиг. Наверное, с каким-то количеством вреда для своего здоровья...

А это вообще нормальная практика в компаниях?

Какая именно?

Ну вот, сидеть с 9 и до 9.

Наверное, не очень. Вот Ultimate Guitar сразу в этом признаётся, когда ты к ним приходишь. Они говорят, что все ребята горят проектами и работают до тех пор, пока задача не закончена. Если ты закончишь свои задачи раньше, пожалуйста, уходи раньше. Не закончишь, ну... надо закончить. Я больше такого подхода, наверное, не встречал. Они сами говорят: «мы не для всех». Для тех, кто хочет работать в таком темпе, пожалуйста: мы предоставляем амбициозные цели, а вы сами их решаете и развиваетесь. В Ламоде или Яндекс.Еде такого не встречалось. Хотя, в Яндекс.Еде, возможно, бывали моменты, когда есть какая-то срочная задача, нужно прям вот-вот её решить, к тебе приходят и говорят, вот надо. И ты сидишь и решаешь, а потом менеджер тебе пиццу заказывает.

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

А у тебя, как у тимлида, вообще какие обязанности?

Мои обязанности находятся на уровне проблем. Мне говорят: «есть такая проблема». Есть задача и она должна быть решена. Условно, ко мне приходят и говорят: «нужно, чтобы приложение было готово к выходу на европейский рынок». А дальше сиди и думай, собственно, что же означает «выход на Европу», с кем же нужно поговорить, от кого добиться требований, как это должно выглядеть, и кому эти задачи потом раздать.

Есть задача «найми 7 разработчиков». Идешь и думаешь, как же мне нанять 7 разработчиков? Может быть, тех бренд построить, может, пошерстить по контактам, может кого-то из предыдущих коллег приманить, и т.д. Таких задач довольно много, я могу их делать сам или кому-то делегировать. Вот как-то так.

Хакнул Swift

А что тебе запомнилось в каждой из компаний? Какие были интересные моменты?

В Ultimate Guitar мне очень ярко запомнился один момент. Благодаря тому, что там очень драйвовая культура, ставили амбициозные цели, и я «хакнул» Swift. В общем, задача заключалась в том, что у нас были две кастомные клавиатуры и одна нативная. Они между собой переключались. То есть, вот есть редактор аккордов, я пишу текст, слова песни. Потом я должен переключиться на клавиатуру с аккордами, или с табами, ещё с чем-то. То есть, всего 3 типа клавиатур. Эти клавиатуры должны были свайпаться слева направо. А нативная клавиатура поднималась снизу вверх. Выглядело это так: две боковые клавиатуры свайпаются слева направо, а посерединке есть пустое место, в которое приезжает снизу вверх нативная клавиатура. Выглядело максимально не очень, и мы думали, что с этим можно сделать. В iOS есть уведомление о движении клавиатуры, в которой зашита информация о том, какая будет анимация у данного действия. Перед началом анимации мы можем получить начальный и конечный фреймы клавиатуры. Однако в Swift это let константы, и никак изменить мы их не можем. Я подумал, что, если это let константы, значит, они где-то находятся в памяти, то есть хранятся в какой-то ячейке. А что, если я узнаю эту ячейку памяти и банально перетру эти значения? Просто пойду в эту ячейку памяти и запишу туда другие. В Swift есть биндинги в сишные функции, например, мне тогда понадобился memcpy. И, знаешь, это сработало. Просто банальным образом, перед началом анимации я заменил в ячейках памяти фреймы на нужные, и анимация стала работать не снизу вверх, а слева направо или справа налево, как и было нужно. В тот момент я поблагодарил себя самого за то, что я сам развиваюсь и смотрю на разные инженерные области, кроме, непосредственно, iOS.

То есть, подобный хак дальше пошел в продакшен?

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

Я кстати слышал, что некоторые разработчики Cardsmobile читают мой канал в Telegram.

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

Хорошо, тогда на этой позитивной ноте мы и закончим наш разговор. Я думаю получилось очень здорово, и спасибо за интересный рассказ, Богдан!

Спасибо за приглашение! Мне тоже было приятно.

Контакт Богдана в Telegram, если кого-то вдруг заинтересует предложение поработать в Cardsmobile.

Статья подготовлена для канала Hello World.

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

Для умников в комментах: глобальный мутабельный стейт – это плохо :)

Поэтому, тут я постараюсь осветить подробно (и с примерами), как можно использовать композицию в ООП вместо наследования, почему наследование это плохо и тому подобные нюансы крутого проггинга 😎.

Полиморфизм в Swift

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

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

Рассмотрим на примере:

Логика следующая. Допустим есть:

• Player - который Solid, Movable и Visible
• Cloud - который Movable и Visible, но не Solid
• Building - который Solid и Visible, но не Movable
• Trap - который Solid, но не Visible и не Movable

И тут мы действительно попадаем в ловушку. В каком-нибудь с++, например, не запрещено наследоваться от множества классов. В Swift множественное наследование классов запрещено (что в целом достаточно логично, если вспомнить о том, что класс – это reference type).

Подобное множественное наследование довольно опасно использовать без должного понимания сути проблемы, и обычно оно приводит к тому, что в англоязычном мире зовут the diamond problem. Кроме того, даже с идеальным пониманием механизмов наследования, данный код получится, откровенно говоря, довольно дерьмовым. Как же быть? В Swift данная проблема решается с помощью механизма протоколов и расширений.

Рассмотрим на примере Visible:

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

Логика здесь четко разнесена, есть Player, который Visible, Solid и Movable. Всё это интерфейсы, протокол содержит только описательную часть, а сама реализация протокола подвешивается в extension. И в таком случае достаточно написать extension к Visible, содержащий данную конкретную реализацию метода draw. В случае, когда нам понадобится логика Invisible, мы просто добавим этот протокол к конечной структуре/классу. Все просто!

В случае с Movable, например, всё делается абсолютно аналогично:

Далее создаем Building и добавляем в него соответствие протоколу Irremovable. И все. Никаких тебе the diamond problem.

В с++ данная проблема решается немного иначе, с помощью virtual inheritance. По сути, если не вдаваться в детали, аналогом протоколов там являются pure virtual functions. Хотя протокол это конечно скорее элемент интерфейса, и там ничего виртуального нет.

Player в данном случае будет выглядеть так:

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

Выводы

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

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

Кстати, принцип "композиция вместо наследования" (или принцип "составного повторного использования") в ООП – это принцип, согласно которому классы должны достигать полиморфного поведения и повторного использования кода посредством их композиции (путем включения экземпляров других классов, реализующих желаемую функциональность), а не путём наследования от базового класса. Это часто упоминаемый принцип ООП, например, в книге Design Patterns (1994).

Кстати а вообще причем тут синглтон? Вместо синглтона лучше использовать dependency injection. Используя композицию вместо наследования, гораздо проще менять поведение "на лету", используя например всё тот же dependency injection.

Полезные ссылки:

Inheritance vs Composition (Swift)

Composition over Inheritance (с примерами на с++)

Статья подготовлена для канала Hello World.

Данная статья является адаптацией другой статьи (доступной на английском языке), которую я прикреплю в конце.

Введение

Если вы занимаетесь программированием, то, возможно, когда вы слышите слово "Swift", то думаете о разработке мобильных приложений для iOS или MacOS. Но если вы занимаетесь deep learning, тогда вы скорее всего слышали о Swift для TensorFlow (сокращенно S4TF). Теперь вы спросите себя: "Зачем Google создавать версию TensorFlow для Swift? Ведь есть же версии для Python и C++; зачем добавлять еще один язык?". В этой статье я постараюсь ответить на эти вопросы, а также обозначить причины, по которым вам следует внимательно следить за S4TF, а также за самим языком Swift.

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

🧠 Swift имеет сильную поддержку

Swift был создан Крисом Латтнером в то время, когда он работал в Apple. После этого, Крис работал в Google Brain, одной из самых лучших исследовательских команд в мире в области искусственного интеллекта. Сам факт того, что создатель языка Swift работал в исследовательской лаборатории, занимающейся deep learning, говорит о том, что это серьезный проект.

Кстати, Крис еще и в Tesla работал. А с 2020 года занялся разработкой процессоров и микроконтроллеров на архитектуре RISC-V.

Некоторое время назад, в Google осознали, что хотя Python и является превосходным языком, он также имеет и много ограничений, которые трудно преодолеть. Для TensorFlow был необходим какой-то новый язык, и после долгих обсуждений, Swift был выбран в качестве кандидата. Я не буду вдаваться в подробности, но здесь есть документ, в котором описаны недостатки Python, и какие другие языки рассматривались в качестве кандидата для TensorFlow, и как в конечном итоге был выбран Swift.

💪 Swift для TensorFlow это больше чем просто библиотека

Swift для TensoFlow – это не просто «TF для другого языка». По сути, это еще одна ветка (в смысле git'a) самого языка Swift. Это означает, что S4TF не является библиотекой. Это самостоятельный язык со своими фичами, построенный таким образом, чтобы поддерживать ту функциональность, которая необходима для TensorFlow. Например, в S4TF есть мощная система автоматического дифференцирования, которая является одной из основ deep learning, необходимая для расчета градиентов. Сравните это с Python, где автоматическое дифференцирование вообще не является частью языка. Некоторые из тех функций, которые изначально разрабатывались как часть S4TF, позже были интегрированы в сам Swift.

⚡️Swift быстрый

Когда я впервые узнал, что Swift работает так же быстро, как C, я был поражен. Я уже знал, что C хорошо оптимизирован и позволяет достичь очень высокой скорости, но это происходит за счет микро-менеджмента памяти, что приводит к тому, что C не является безопасным, с точки зрения доступа к памяти, языком. Кроме того, C – это точно не тот язык, который очень легко выучить.

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

📦 Вы можете использовать библиотеки Python, C и C++ в Swift

Поскольку Swift для машинного обучения находится на очень ранней стадии своего существования, это означает, что библиотек машинного обучения для Swift не так много. Но не стоит слишком беспокоиться об этом, потому что Swift обладает потрясающей совместимостью с Python. Вы просто импортируете любую библиотеку Python в Swift, и это работает. Точно так же, вы можете импортировать библиотеки C и C++ в Swift (только для C++ необходимо убедиться, что хедеры написаны на простом C, без использования C++).

Подводя итог, если вам нужна конкретная функциональность, но она пока еще не реализована в Swift, вы можете импортировать соответствующий пакет Python, C или C ++. Впечатляет!

⚙️ Swift может быть очень низкоуровневым

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

В Swift все по-другому. Крис Латтнер назвал Swift «синтаксическим сахаром для компилятора LLVM». Это означает, что Swift находится практически на уровне железа, и между ним и TF нет никаких других слоев кода, написанного на C. Это также означает, что Swift работает очень быстро, как это и было описано выше. Все это приводит к тому, что вы, как разработчик, можете проверять код с очень высокого до очень низкого уровня без необходимости углубляться в C.

📈 А дальше?

Swift – это лишь небольшая часть инноваций в области deep learning, происходящих в Google. Есть еще одна вещь, которая очень тесно с этим связана: MLIR, что означает Multi-Level Intermediate Representation. MLIR будет объединяющей инфраструктурой компилятора Google, позволяющей писать код на Swift (или на любом другом поддерживаемом языке) и компилировать его под любое поддерживаемое оборудование. В настоящее время существует множество компиляторов для различного оборудования, но MLIR изменит это, позволяя не только повторно использовать код, но и писать собственные низкоуровневые компоненты компиляторов. Это также позволит исследователям применять машинное обучение для оптимизации некоторых низкоуровневых алгоритмов.

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

Представьте себе возможность использовать deep learning, чтобы помочь оптимизировать алгоритмы низкоуровневой памяти для данных (задача, аналогичная той, что пытается выполнить Halide). Более того, это всего лишь начало, будут и другие, более творческие применения машинного обучения в компиляторах!

Подведем итоги

Если вы занимаетесь deep learning, то вам, вероятно, стоит начать изучать Swift. Это даст много преимуществ по сравнению с тем же Python. Google вкладывает огромные средства в превращение Swift в ключевую компоненту своей инфраструктуры TensorFlow ML, и весьма вероятно, что Swift станет языком deep learning. Раннее знакомство с языком Swift даст вам некоторое преимущество первопроходца.

Оригинальная статья на английском.

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

Статья подготовлена для канала Hello World.

Сегодня мы поговорим о том, как устроена мобильная разработка крупных российских продуктов. У нас в гостях тимлид iOS команды разработки Cardsmobile – Богдан Маншилин.

Да, все верно, тимлид iOS разработки в Cardsmobile, мы разрабатываем приложение "Кошелёк".

Давай для начала попробуем разобраться с понятийным аппаратом. Что ты считаешь крупным продуктом, и что – российским?

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

Объясни, почему именно миллион человек в месяц?

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

А что по поводу российских продуктов?

Я считаю российскими те продукты, которые были сделаны в России. На примерах, из моего опыта разработки, крупные российские компании это:

• Ultimate Guitar, компания, базирующаяся в Калининграде, то есть полностью вся разработка в Калининграде и head офис в Калининграде, однако продукт в первую очередь используется в США;
• Lamoda и Яндекс.Еда, максимально российские продукты, как по тому, кто их использует, так и по разработчикам;
• Cardsmobile – там, где я сейчас работаю, мы разрабатываем приложение, которое используется в России. Хотя мы сейчас нацелены на Европу, однако когда мы туда выйдем, мы все равно останемся российским продуктом.

Хорошо, вот те приложения, которые ты назвал. Ты над ними работал?

Да, все верно. Работал конечно на разных позициях. В Ultimate Guitar я начинал работать как джуниор-разработчик, и там уже дорос до нормального разработчика. На самом деле сложно говорить о грейдах в Ultimate Guitar, поскольку их там просто не было. По крайней мере на тот момент компания шла по пути "холакратии", то есть не было никаких лычек "мидл", "сеньор" или еще кто-то. Вся структура была максимально плоской, за исключением того, что был один руководитель. По своим личным ощущениям, за время работы в Ultimate Guitar я стал хорошим таким мидлом.

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

Расскажи, почему покинул Яндекс.Еду и перешел в Ламоду?

Наверное, отчасти из-за карьерного роста. Хотя, если признаться честно, я пошел за своим руководителем. У нас был руководитель мобильной разработки в Яндекс.Еде, он из Ламоды и по своим причинам вернулся обратно. Какое-то время я пытался развиваться внутри Яндекс.Еды, у меня не получилось. Я не смог понять, какие же у меня там направления развития: бывало так, что я приходил на работу и не знал, чем мне заниматься, и в общем-то от такого отсутствия чётко поставленной цели я уже потянулся за своим прошлым руководителем, с которым мне нравилось работать.

Делал приложение под кофейни, где ставят печати на карточку. Как стартапер я прогорел.

Так, а как ты в Cardsmobile тогда оказался?

О, это очень интересная история. Параллельно с работой я разрабатывал еще и пет-проекты, одним из таких проектов было приложение "кофри". Идея была такая: я очень хотел сделать приложение, которое полностью бы заменило кошелек, то есть все дисконтные карты перенесло бы из моего кармана в это приложение. Я начал его разрабатывать, но в какой-то момент понял, что это приложение уже существует (это и есть приложение "Кошелек").

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

В какой-то момент я увидел на своей почте письмо от HR из Кошелька. О Кошельке я, естественно, уже давно знал, как о своём личном конкуренте. На тот момент я не рассматривал предложения о работе, меня всё устраивало в Ламоде. Но с ребятами я решил пообщаться и узнать, как у них в принципе идёт бизнес. Бизнес у них шел очень интересно: они выходили на европейские рынки, имели стратегического партнера в лице huawei, происходил рост в команде до десятков человек. Собственно, очень большие перспективы, каких не было в Ламоде. Я обсудил это со своим руководителем и понял, что интереснее было бы развиваться вместе с Кошельком.

Расскажи, на чём были написаны все те приложения, с которыми ты работал. Нативная разработка или кросс-платформа? Swift или Objective-C? React-Native или Flutter?

Всего по чуть-чуть. Я всегда был нативным разработчиком и всегда писал либо на Swift, либо на Obj-C. Первое приложение (Ultimate Guitar) было нативным, однако, когда я уходил, стратегия немного поменялась. Кстати, это, наверное, было одной из причин моего ухода – приложения стали кроссплатформенными. И я каюсь, на самом деле я приложил к этому руку. Первый прототип приложения Ultimate Guitar на React-Native разрабатывал я с ещё одним фронтенд-разработчиком, который хорошо разбирался в реакте. Это приложение очень сильно понравилось менеджерам AppStore из раздела Музыка, и в Ultimate Guitar решили разрабатывать всё на React-Native.

Это был долгий путь, к тому моменту я уже ушёл из компании, ребята набрали команду под реакт, переписали всё приложение, и у них получилось. Было много связанных с этим проблем, но они их решили. Теперь у них приложение полностью на React-Native, но кроме одной части. По сути, Ultimate Guitar – это приложение, которое отображает гитарные табулатуры, аккорды, вот это все. И экран с отображением этих табулатур довольно сложный, на React-Native всё это работало очень медленно. Поэтому ребята решили, что эту часть они напишут... нет, не нативно, а на Qt (Qt – это кроссплатформенная библиотека, написанная на С++).

А что с Ламодой и Яндекс.Едой? Они используют кроссплатформу или что-то нативное?

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

Видишь ли ты какие-то преимущества нативной разработки над кроссплатформой или наоборот?

В первую очередь это, конечно, UX. Несмотря на то, что какие-то вещи в React-Native или Flutter пытаются сделать нативными (тот же React-Native берет нативные вьюхи и их отрисовывает, но сначала он создает виртуальный интерфейс, поверх которого уже рисуется нативный), у них есть проблемы с реюзабельными коллекциями (TableView), их там не было. То есть все отображённые ячейки висели в памяти приложения, из-за чего оно могло подлагивать.

Если говорить о Flutter, то, по сути, это технология, которая говорит, что мы самостоятельно перерисовываем весь интерфейс, то есть у нас свой UIKit, который похож на то, как это выглядит нативно. Однако тут мы понимаем, что, если у нас есть какой-то UIKit, который копирует нативное решение, то он копирует либо android либо iOS. То есть есть какая-то общая, базовая часть элементов, но всё таки есть UIKit например называется кажется купертино и обычный, и это два разных кита. И если ты хочешь разработать приложение, которое на iOS не выглядит, как приложение от Гугла, а хочешь, чтобы оно выглядело нативно, то так или иначе тебе всё равно придется пилить два разных интерфейса.

Однако преимуществ от этого я больших не вижу, поскольку проблемы продолжаются и дальше. Кроме всяких нативных вьюх (которые, по сути, не являются нативными, а только на них отчасти похожи), есть ещё и такие штуки, которые не напишешь на кроссплатформе. Например, виджеты. Сейчас они на SwiftUI. На Flutter их попросту нет. Когда я писал на React-Native, была проблема с отсутствием плагина для force touch. Сейчас, конечно, force touch уже нет, но тогда пришлось самому писать этот плагин, чтобы полностью воспроизвести ту функциональность, которая уже была в приложении. Да и в принципе, даже если кроссплатформа рано или поздно начинает поддерживать новые возможности платформы, она всё равно находится в отстающей позиции. Выходит новая фича на iOS или android, и в кроссплатформе её ещё нет. А если мы хотим всё сделать быстро, ввести эту новую фичу, и чтобы нас зафичерили в AppStore, то кроссплатформа попросту не позволит этого сделать.

Что можешь сказать по поводу скорости разработки?

Это очень тонкий вопрос, мне будет сложно на него ответить однозначно, потому что я больше разрабатывал нативно и только чуть чуть пробовал кроссплатформу в Ultimate Guitar. Но должен сказать, что быстрее у меня разрабатывать на React-Native не вышло... Были какие-то вещи, которые нужно было подпиливать под android. Хотя мы делали приложение только под iOS, мы понимали, что, если будем сейчас делать и под android, то нужно бы сделать ещё вот это, вот это и вот это, дофига всего. И собственно пришлось бы делать второй интерфейс. Это первое. А второе – время от времени ты затыкаешься на том моменте, что кроссплатформа этого не поддерживает. Я частенько вижу реквесты на Flutter или React-Native, что такой-то фреймворк там не прокинут и не поддерживается до кроссплатформенного sdk, то есть нужно написать плагин, или еще что-то сделать. В общем-то, честно я не могу привести какие то метрики. По ощущениям, сильно быстрее не будет. Конечно, если мы хотим соответствовать качеству нативного приложения.

Если мы можем подзабить на качество и где-то недокрутить тот же force touch (которого уже нет), ну или виджеты, или забить на то, что где-то вьюшка некрасиво скачет, вот, например, я смотрю сейчас с точки зрения пользователя на Яндекс.Лавку и она выглядит как будто веб-вьюха, вот если мы к этому готовы, тогда на Flutter будет быстрее. Если мы хотим сделать максимально плавно, нативно и красиво, то может оказаться, что кроссплатформенно разрабатывать будет даже дольше.

То есть большие компании всё-таки выбирают именно нативный путь?

Ну, не совсем. Вот та же Яндекс.Лавка – это Flutter. Хотя тоже большая компания. Наверное, тут дело не в том, большая это компания или маленькая, а в том, в каких компаниях или проектах важен UX, а где им можно пренебречь. Яндекс.Лавка считается экспериментальным проектом, и там ребята экспериментируют с Flutter и что с этим получится. Будем ждать статью от Яндекса, где они перешли с Flutter обратно на натив, как в своё время AirBnb перешли с React-Native на нативную разработку.

Вечный хакатон vs скрамбан

Расскажи о том, какие команды работают над всеми этими продуктами? Большие или маленькие? Как устроена структура этих команд и каких процессов они придерживаются?

Довольно обширный вопрос, давай по каждой команде пройдёмся отдельно. Давай возьмем Ultimate Guitar, но я буду говорить о ней образца 2015-2016 года, когда я там работал, поскольку Ultimate Guitar всегда изменяется. Тогда это была команда из 50-60 человек (вообще всех сотрудников), и это была полная холакратия, то есть не было вообще руководителей (кроме одного), и не было процессов. Процесс назывался "вечный хакатон". Когда ты приходишь на какой-нибудь курс по процессам, тебе говорят, что процесс – это на самом деле препятствие.

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

Процесс был построен таким образом, что когда ты попадаешь в эту команду, твоя задача не только разрабатывать или рисовать дизайны, твоя задача предлагать идеи, питчить их. Ну и, образно говоря, каждый вторник, ну или раз в две недели, сотрудники компании приходили и рассказывали свои идеи. Фаундер смотрит и говорит: это фигня, а это звучит интересно, давайте сделаем. Таким образом, человек, который предложил идею, становится её заказчиком. Он берет эту идею и доводит её до продакшена. Никакого процесса тут нет, он сам находит ресурсы, обращается к разработчикам, сам её планирует. Как на хакатоне, ты придумал идею, собрал несколько человек. Сели и запилили за две ночи, примерно вот так. Очень интересно, но со своими минусами. Человек, который запитчил, должен довести всё до конца сам. Если он не самостоятельный, значит, проект сделан не будет.

Более классические примеры процессов были в Яндекс.Еде и Ламоде, они были довольно похожие. В Яндекс.Еде iOS разработчиков было примерно 5 штук, а всего в команде – более 100 человек (на всю Яндекс.Еду). Работали мы по методологии скрам, хотя я бы, наверное, назвал это скрамбан.

Scrumban – это методология, включающая в себя элементы scrum и kanban, однако Богдан называет скрамбаном любую химеру, которую придумывают менеджеры в попытке вобрать лучшее из канбана и скрама.

Это был недетерминированный процесс. В конечном итоге за основу мы взяли все-таки канбан. У нас была бесконечная борда, где в первой колонке находятся задачи в виде такого бесконечного списка.

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

Были уже и код ревью нормальные, и QA, причём мы работали по git flow. То есть, когда мы берем какую-то фичу, мы уходим в свою ветку. Пока работаем с фичой, находимся в этой ветке, здесь же был и код ревью, и происходило тестирование. Только потом заливаем это все уже в develop (название ветки). Еще у нас были спринты, ориентированные на проекты. То есть, они были регулярные – раз в 2 недели – но с упором на законченные задачи.

Обычное ретро, привязанное к спринтам, как происходит? Закрываем спринт, садимся все вместе и говорим, что в спринте было хорошо, а что плохо. В Яндекс.Еде, что интересно, мы поступали не так. Мы брали все задачи, которые к этому моменту успевали завершить (которые уже уехали в релиз), и проходились по ним. Эта задача проехала хорошо, есть по ней комментарии? Если комментариев нет, значит все окей, прилепили стикер на физическую доску и сказали что по ней комментариев нет. Если по задаче есть комментарии (не обязательно плохие), то их обсуждаем, записываем. В идеале, выписываем какие-либо поинты и тд. Это такой, в общем, процесс у нас был в Яндекс.Еде.

В Ламоде были спринты (то есть не было канбана), эти спринты мы планировали и в дальнейшем оценивали в сторипоинтах, в Еде это было в часах. То есть это был обычный скрам, без всяких интересностей. Всё как по книге. То есть, у нас есть грумминги, планинги, ретро. И все это более-менее работает. Всегда пытались посчитать велосити нашего спринта, чтобы его уметь планировать. Но это обычно не удавалось, и каждый раз мы чуть-чуть выезжали. Сложно было с планированием спринтов, хотя в целом всё работало хорошо. Больших отличий от Еды нет, кроме того, что появились спринты.

В команде на разных этапах было 7-9 человек, и она была разделена на две части. То есть было две команды по двум продуктовым направлениям. Одни занимаются конвершеном, вторые ретеншеном. Условно это два бизнесовых направления, у каждого есть продакт, за продактом закреплены разработчики (то есть те ресурсы, которые есть у продакта). Таким образом, проект был один, но задачи разные. Работали все в рамках одного проекта. Не было никаких зон ответственности, все отвечали за один проект. Где-то в момент моего ухода из Ламоды эту команду слили обратно в одну.

Нам нужно выйти на европейские рынки. Сделайте с этим что-нибудь.

Что можешь сказать по поводу разработки в Cardsmobile? Это было ближе к хакатонам или к традиционным процессам, таким как скрам, спринты?

По поводу разработки в Cardsmobile. Команд у нас много, в отличие от той же Ламоды, в которой было несколько команд по направлениям. У нас сейчас тоже есть команды по направлениям, как гораздо большие, так и гораздо меньшие (чем в Ламода). У каждой команды есть своя зона ответственности. В каждой из команд есть свои процессы. В общем, конечно, у нас скрам. Допустим, кор команда оценивает задачи в часах, другая команда может оценивать в том, в чём ей нравится, например, в сторипоинтах. Это, собственно, не совсем обычный скрам. Пока что я могу рассказать только про кор команду, потому что в кор команде я являюсь, условно говоря, заказчиком. То есть, у нас нет продакта, как такового, нам прилетают задачи на уровне "нам нужно выйти на европейские рынки, сделайте с этим что-нибудь". Мы уже тут сидим и придумываем, что же можно сделать, чтобы туда выйти. В связи с этим и процессы строим как нам удобно. Процессы выглядят таким образом: у нас есть спринты, оцениваемся мы в часах. Я, если честно, не вижу разницы между часами и сторипоинтами, даже когда мы оцениваем в часах, я считаю, что это какая-то относительная единица работы. Потому что даже если мы оценили задачу в 4 либо 40 часов, это совершенно не означает, что мы будем её делать 4 или 40 часов. Это просто-напросто подтверждается практикой.

Все равно наша велосити, в чем бы мы её не считали, в часах или поинтах, это статистически погрешная величина.

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

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

Послесловие

У Cardsmobile, кстати, есть канал. Подписывайтесь, там много всего интересного! А также, в будущем, будет и вторая часть статьи, где мы обсудим, как попасть в крупную техническую компанию, какие у этих компаний проблемы и многое другое.

Статья подготовлена для канала Hello World.

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

Попробуем разобраться в этих, довольно далеких от императивного программирования, концепциях.

Если текст покажется вам слишком сложным, вернитесь к нему еще раз после прочтения статьи по хаскелю, которую я приложу в самом конце статьи.

Значения в контексте

Попробуем сначала разобраться что такое контекст. Допустим у нас есть некоторая простая переменная, например var number = 3. Теперь давайте упакуем это значение в контекст. Представим коробку, в которую мы кладем это значение. Коробка по сути и будет являться простой концепцией контекста.

Такая коробка может иметь значение, а может и вовсе быть пустой (например как массив значений, или реальная коробка из реального мира). Оперировать с таким значением напрямую мы не можем, поскольку оно упаковано в контексте, но можно попробовать каким-либо образом "распаковать" его, если контейнер не пуст.

Значение в контексте, или же просто упакованное значение, это одно и то же.

Внимательный читатель может заметить, что прообразом подобной коробки может являться тип Optional в языке Swift, поскольку Optional может как иметь некоторое значение, так и быть nil. Для наших экспериментов создадим наш собственный Optional в виде дженерика Box<T>, имеющего два кейса:

Ничего сложного тут нет, даже если вы слабо знакомы с синтаксисом Swift. Перечисления в Swift объявляются в помощью ключевого слова enum и могут иметь различные кейсы перечисления, определяемые с помощью слова case. В данном случае мы можем либо вернуть некоторое значение типа T либо ничего. Переходим к функторам.

Функтор

Функтор – это такой тип данных, для которого определена функция map.

Теперь у нас есть значение в контексте (например целое число 7), и мы хотим добавить к нему 3. Но поскольку значение упаковано в контекст, мы не можем просто добавить к нему 3.

Box(7) + 3 -> Type Error.

Для того, чтобы выполнить подобное вычисление, нам понадобится функция, выполняющая вычисление в случае если коробка не пуста, и возвращающая "пустое" значение, если коробка пуста.

Здесь мы определили функцию add, принимающую целое значение в качестве параметра, выполняющую некоторые вычисления и возвращающую Box типа Int. Давайте перепишем его и сделаем более абстрактным (generic). Здесь на сцену выходит функция map. Такая функция принимает в качестве аргумента другую функцию с сигнатурой (T) -> U, становясь по сути независимой от типа.

Что мы в итоге имеем:

• функция map принимающая функцию (T) -> U в качестве единственного аргумента и возвращающая Box<U>
• если внутри контекста есть значение, мы применяем к нему функцию f, получаем в результате значение типа U, оборачиваем это значение обратно в контекст Box<U> и возвращаем его
• если внутри контекста нет значения, возвращаем empty

Используя функцию map можно применять любую функцию к значению, заключенному в контекст Box.

Функтор применяет функцию к значению, заключенному в контексте

Другими словами функтор – это тип данных, для которого определена функция map – функция которая знает как применить другую функцию к значению в контексте.

Аппликативный функтор

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

Итак, мы уже знаем что такое значение в контексте, и как применять к этим значениям функции с помощью функторов. Но допустим, теперь и функция тоже упакована в контекст! И как нам применить эту функцию к значению в контексте? Нужна немного более мощная вещь чем map. Расширим тип Box с помощью функции apply, которая будет переключаться между функцией в контексте и значением.

Обратим внимание на первый some case. Вложенный switch ничего не напоминает? По сути, это тот же самый map, реализованный чуть выше. Давайте немного отрефакторим код и заменим вложенный switch на map.

То есть, apply возвращает некоторое значение, помещенное в контекст только в том случае если есть некоторая функция внутри Box, и некоторое значение внутри Box. В иных случаях, возвращается empty. Теперь определим что такое аппликативный функтор.

Аппликативный функтор применяет функцию из контекста к значению из контекста.

Другими словами, аппликативный функтор – это тип, который знает как применить функцию помещенную в контекст, к значению помещенному в контекст.

Монада

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

Монада применяет функцию, помещенную в контекст и возвращающую некоторое значение (также помещенное в контекст) к значению из контекста.

Звучит вообще говоря как-то так себе, правда? Рассмотрим на примере. Определим функцию flatMap для Box и посмотрим как работают монады.

Аргумент функции flatMap возвращает Box<U>, а не просто тип U как например функция apply в аппликативном функторе.

Монады применяют функцию, которая возвращает упакованное в контекст значение, к упакованному в контекст значению.

Заключение

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

Функторы и монады в картинках

Монады за 15 минут

Англоязычный сайт по хаскелю

Попробовать Swift можно, например тут.

Статья подготовлена и написана для канала Hello World.

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

Эта рубрика создана скорее не с целью научить чему то (хотя и это тоже), но с целью поделиться своим опытом разработки мобильных приложений под конкретную платформу (iOS).

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

Какие еще аппки, дядя?

Что вообще сподвигло меня на написание данной статьи? Телеграм меня утомил. Python я использую по работе и он превратился в рутину. Кроме того, мой мак простаивал, а Swift я хотел освоить еще long long time ago... Ну допустим убедил, но что там по цифрам? Мобильный рынок огромен. Большинство людей, только разлепив глаза ото сна, берут в руки телефон. Про разработчиков всяких китайских игр-фармилок я вообще молчу.

Точные цифры я не помню, да и ни к чему вам они. Но если вам мало слов, всегда можно проверить примерный заработок того или иного мобильного приложения в sensor tower (ни разу не реклама, если что). Таким образом, немного изучив конкурентов и рынок в целом, можно влезать в разработку.

Вообще говоря, мой выбор основывался лишь на моих личных предпочтениях и только (мне просто нравится Swift), но всегда приятно увидеть цифры и заранее положить несуществующие 1-2к $ себе в карман.

MVVM

Microsoft презентовала этот шаблон в 2006 году. По сути он является новейшим из всех MV(X) шаблонов, созданный с целью устранения некоторых проблем присущих MV(X). Цель этого шаблона – разделение бизнес логики приложения и его визуальной составляющей. Если слова "бизнес логика" вас не очень то вдохновляют, то забудьте об этом. Речь по сути идет о некоторой абстрактной модели, представляющей всю логику вашего будущего приложения.

Model

Модель – это абстрактное "нечто", чаще всего речь идет о дженериках (поскольку они позволяют полностью забить на конкретный тип данных в самой модели). К примеру, если мы хотим реализовать стек, без дженериков нам бы понадобилось сразу указывать тип данных, который мы будем хранить в этом стеке. Вот пример на языке Swift, без использования дженериков:

Здесь все просто: создаем массив интов, передаем элементы в функцию и тд. Строгая типизация не позволяет нам передать сюда Float или String.

А вот здесь мы передадим абстрактный <Element>:

Поэтому дженерики еще называются don't care type. Нам абсолютно не важно что передавать, логика остается одна и та же. На самом деле в моделях важны две вещи:

1. Модель это абсолютно абстрактная вещь
2. Модель не занимается получением данных и отправкой их в VM или View (о них поговорим чуть позднее), это задача View Model

По поводу последнего поясню еще раз. Казалось бы, совершенно банальная вещь, допустим нам необходимо получить данные с API или с некоторой БД, и далее передать их для визуализации, или в целях обработки. Получать данные в таком случае будем именно во View Model (VM). Модель не работает с данными напрямую. Мы можем получить данные в VM, а затем передать их внутрь модели с помощью функций, созданных непосредственно для того, чтобы настроить модель нужным образом.

Это очень тонкий момент. Поскольку модель абстрактна, мы не можем (или можем, но не хотим), работать с данными (в контексте вышесказанного) в ней. Приведу еще один пример. Допустим, мы работаем с библиотекой книг. Наша модель будет содержать некоторую структуру, содержащую название книги, автора, и уникальный ID, чтобы удобнее было итерироваться по коллекции. Это все. Далее, во View Model вы создаете массив книг, и получаете данные с внешней API или с внутренней БД.

View Model

View Model стыкует данные и их непосредственное визуальное представление во View, кроме того обновляет состояние модели. Допустим, пользователь поменял настройки в приложении, следовательно нам нужно:

1. Уведомить модель об изменении настроек
2. Дать понять View, что уже пора бы отрисовать новый экран

Главное не забывать о модификаторах доступа. Создавая модель внутри VM, необходимо позаботиться о том, чтобы View не мог непосредственно влиять на саму модель. Например, объявить модель private, а затем настроить функции внутри VM для того, чтобы View имел необходимый уровень доступа к модели. Подобная прослойка в виде VM между Model и View позволяет избежать некоторых неприятных моментов, когда приложение становится достаточно большим.

View

Что делает View?

1. Рисует окна
2. Создает и отрисовывает анимации
3. Общается с VM

Здесь важно понимать, что MVVM подразумевает "реактивность" приложений. Это не MVC, где использовался императивный подход "отрисуй мне вот это ВОТ ЗДЕСЬ", это декларативный подход, где вы описываете какой именно результат вам нужен, а View уже сам как нибудь справляется с этим.

Реактивность подразумевает собой то, что наше приложение по сути является слушателем изменения состояний у отрисовываемых объектов. То есть, при любом изменении состояния отображаемой переменной (например текст, картинка), мы сразу же отображаем эти изменения. В Swift это называются ObservableObject, и он говорит View об изменении своего состояния, и в свою очередь View понимает что надо отобразить новое состояние.

Несколько советов

Если вы хотите влиться в разработку приложений, не столь важно android или iOS, для начала позаботьтесь о том, что вы освоили основы требуемого языка программирования, умеете работать с переменными, массивами, циклами, условными конструкциями и тд. Обеспечьте себе базис.

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

Залог успешного изучения подобных вещей состоит из нескольких шагов. Кратко я это назову условный "цикл разработки".

1. Хорошие лекции по разработке непосредственно приложений (например, Стэнфордские, не знаю есть ли подобные для андроид, но наверняка есть)
2. Как минимум одна книга (а лучше две), в которой описываются основы языка
3. Вдумчивое чтение документации
4. Практика, практика и еще раз практика

Как только с первыми двумя будет покончено, остается только 3 <--> 4. И так до бесконечности.

Если вы не знакомы с фичей, которую собираетесь реализовать, не надо копировать код со stackoverflow без понимания его работы. Лучше открыть отдельный проект и потратить лишние 4-6 часов на понимание работы данной конкретной фичи.

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

Тем, кто дочитал

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

Это не означает, что я не буду писать про Python. Последний я использую по работе, для визуализации и анализа, и иногда появляется что то интересное. В плане анализа это замечательный язык, но писать на нем приложения глупо, не так ли?

Я бы так и тянул с этими статьями, но на днях мне написали из Cardsmobile. Оказывается, некоторые разработчики читают мой канал (отдельное спасибо им за это), и у них в планах делиться своим опытом разработки.

Вот их последняя статья на тему виджетов в iOS14.

Статья подготовлена и написана для канала Hello World 😉

Одна из самых старых практик кодирования – поддерживать 80-символьную длину строки, и многие из нас следуют ей вслепую, но задумывались ли вы когда-нибудь, почему мы обычно ставим это правило на первое место?

Полагаю, что в эпоху маленьких мониторов это должно было сделать код более удобным для чтения, чтобы все содержимое могло уместиться на одном экране, или, возможно, практика пришла из эпохи перфокарт, которые раньше имели 80-символьную длину. Если учитывать прошлое, вопросов не возникает, но считаете ли вы, что это правило имеет смысл в 2020 году?

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

Я впервые узнал о правиле переноса строк после 80 символа, когда читал Oracle Code Conventions для языка программирования Java, который в последний раз пересматривался 20 апреля 1999 г.

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

Примечание: в примерах для использования в документации должна применяться более короткая длина строки – обычно не более 70 символов.

Если я правильно понял (могу ошибаться), одна из целей этого правила – однородность. Раньше я считал, что 80 символов – это глупо, но иметь возможность просматривать исходный код, написанный дюжиной разных команд за последние 7 лет, и забыть про необходимость изменять размеры окна – это действительно хорошая вещь. Устойчивая длина строки помогает быстрому чтению кода.

Поскольку я в основном работал с большими мониторами, такими как 32-дюймовый IPS-монитор LG 32MP58HQ-P с разделителем экрана, я также понимаю, что теряется много драгоценного места. Одинаковая длина строки в 80 символов просто слишком мала. Я лично использую 120, если для проекта, над которым работаю, не была утверждена длина строки, в таком случае я соблюдаю рекомендации.

Еще одна причина, по которой люди все еще используют 80-символьную длину строки, заключается в том, что они работают с несколькими файлами одновременно, в основном в VIM или в своих IDE, таких как Eclipse или IntelliJ IDEA. Например, если используется стандартная длина строки, можно разместить пару файлов и сравнить их построчно, что, на мой взгляд, является важным преимуществом. Можно даже выполнить трехстороннюю проверку слияния на одном экране без прокрутки в сторону. Кстати, не стоит решать эту проблему за счет лишних переносов.

Я понимаю, что одинаковая длина строки облегчают анализ и чтение текста, но не важно, речь идет о 80 или 120 символах.

В качестве заключения хотелось бы отметить, что одинаковая длина хороша, и ее нужно использовать, но 80 или даже 100 символов – слишком мало. Многие разработчики, по-видимому, могли бы работать со 120 или даже 150 символами. Современные широкоэкранные ЖК-мониторы высокой четкости могут легко справиться с большим количеством символов в строке.

Значительно легче читать более длинные строки, чем строки с лишними переносами, потому что лично мне труднее читать строку с переносом, чем просто видеть все в одной строке. Конечно, это просто мое предпочтение, и не все с ним согласятся.

Оригинальная статья

А что думаете вы?

Статья подготовлена для канала hello world.

Недавно я наткнулся на одну интересную вещь. Оказывается, выражение

>>> pow(3,99)

работает медленнее, чем вот это:

>>> 3**99

Эта интересная особенность подтверждается непосредственным вычислением с помощью модуля timeit:

$ python3 -m timeit 'pow(3,99)'
500000 loops, best of 5: 527 nsec per loop

$ python3 -m timeit '3**99'
500000 loops, best of 5: 460 nsec per loop

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

Наша догадка подтвердилась:

$ python3 -m timeit 'pow(3,9999)'
5000 loops, best of 5: 57.6 usec per loop

$ python3 -m timeit '3**9999'
5000 loops, best of 5: 58.9 usec per loop

В процессе изучения этого вопроса я также пользовался модулем dis. Этот модуль позволяет декомпилировать байт-код Python и проверять его.

>>> from dis import dis
>>> dis('pow(3,99)')
  1           0 LOAD_NAME                0 (pow)
              2 LOAD_CONST               0 (3)
              4 LOAD_CONST               1 (99)
              6 CALL_FUNCTION            2
              8 RETURN_VALUE

>>> dis('3**99')
  1           0 LOAD_CONST               0 (3)
              2 LOAD_CONST               1 (99)
              4 BINARY_POWER
              6 RETURN_VALUE

Декомпиляция pow в целом имеет смысл. Сначала происходит загрузка pow из пространства имен, затем загрузка 3 и 99 в регистры и, наконец, вызов функции pow. Но давайте рассмотрим еще один пример:

>>> dis('3**64')
  1           0 LOAD_CONST               0 (3433683820292512484657849089281)
              2 RETURN_VALUE

>>> dis('3**65')
  1           0 LOAD_CONST               0 (3)
              2 LOAD_CONST               1 (65)
              4 BINARY_POWER
              6 RETURN_VALUE

Воу, а вот это уже становится интересным. Почему выводы dis двух похожих функций так различаются? Ведь мы всего лишь изменили 64 на 65!

Этот вопрос относит нас к другой интересной концепции, которая носит название «свертка констант». Это означает, что когда у нас есть константное выражение, Python оценивает значение этого выражения во время компиляции, так что, когда вы запускаете программу, она не занимает много времени, потому что Python использует уже вычисленное значение. Приведу простой пример. Вот это:

def one_plue_one():
    return 1+1

превращается в это:

def one_plue_one():
    return 2

Самая распространенная реализация языка (CPython), которую вы обычно используете в своих программах, является интерпретируемой, с некоторой компиляцией. CPython компилирует исходный код на Питоне в байткод, а затем интерпретирует этот байткод, запуская его в процессе.

Так и почему же constant folding работает для числа 3**64, а не для 3**65? Может быть дело в том, что количество цифр в числе 3**65 больше, а Python ограничивает его например 30 знаками для целого числа? И да и нет.

Рассмотрим еще один, казалось бы абсурдный, пример:

>>> dis('2**66')
  1           0 LOAD_CONST               0 (2)
              2 LOAD_CONST               1 (66)
              4 BINARY_POWER
              6 RETURN_VALUE

>>> dis('4**33')
  1           0 LOAD_CONST               2 (73786976294838206464)
              2 RETURN_VALUE

Краткий ответ таков: нет никаких особых правил для constant folding. Есть только детали реализации, заключающиеся в том, что оптимизатор AST включает в себя некоторые меры предосторожности, чтобы не тратить слишком много времени или памяти на constant folding.

Подобные "меры предосторожности" для 2**66 или 4**33 основаны на количестве битов в LHS и значении RHS:

if (PyLong_Check(v) && PyLong_Check(w) && Py_SIZE(v) && Py_SIZE(w) > 0) {
    size_t vbits = _PyLong_NumBits(v);
    size_t wbits = PyLong_AsSize_t(w);
    if (vbits == (size_t)-1 || wbits == (size_t)-1) {
        return NULL;
    }
    if (vbits > MAX_INT_SIZE / wbits) {
        return NULL;
    }
}

MAX_INT_SIZE определен ранее как 128. Поскольку 2 – это 2-битное число, а 4 – 3-битное число, предполагаемый размер результата меньше для 4**33, поэтому оно проходит проверку и получает constant folding.

И еще один интересный пример. Поскольку Python производит вычисления слева направо, то выражение 1+2+3+x будет оптимизировано с помощью constant folding, а выражение x+3+2+1 – нет.

>>> dis('lambda x: 1+2+3+x')
  1           0 LOAD_CONST               0 (<code object <lambda> at 0x10a440c00, file "<dis>", line 1>)
              2 LOAD_CONST               1 ('<lambda>')
              4 MAKE_FUNCTION            0
              6 RETURN_VALUE

Disassembly of <code object <lambda> at 0x10a440c00, file "<dis>", line 1>:
  1           0 LOAD_CONST               1 (6)
              2 LOAD_FAST                0 (x)
              4 BINARY_ADD
              6 RETURN_VALUE

vs

>>> dis('lambda x: x+3+2+1')
  1           0 LOAD_CONST               0 (<code object <lambda> at 0x10a4400c0, file "<dis>", line 1>)
              2 LOAD_CONST               1 ('<lambda>')
              4 MAKE_FUNCTION            0
              6 RETURN_VALUE

Disassembly of <code object <lambda> at 0x10a4400c0, file "<dis>", line 1>:
  1           0 LOAD_FAST                0 (x)
              2 LOAD_CONST               1 (3)
              4 BINARY_ADD
              6 LOAD_CONST               2 (2)
              8 BINARY_ADD
             10 LOAD_CONST               3 (1)
             12 BINARY_ADD
             14 RETURN_VALUE

P.S. Не забывайте делиться статьями и вступать на мой канал hello world. Это поможет выпускать больше качественного материала.