Дорогие ‎потенциальные‏ ‎подписчики!

Овладение ‎искусством ‎гитарного ‎аккомпанемента ‎—‏ ‎процесс ‎увлекательный‏ ‎и‏ ‎азартный! ‎Вы ‎берёте‏ ‎инструмент ‎в‏ ‎руки, ‎зажимаете ‎привычный ‎Am,‏ ‎но‏ ‎сказать ‎миру‏ ‎Вы ‎хотите‏ ‎какие-то ‎очень ‎красивые ‎слова, ‎и‏ ‎они‏ ‎так ‎и‏ ‎просятся, ‎но‏ ‎после ‎Am ‎рука ‎идёт ‎на‏ ‎Dm,‏ ‎потом‏ ‎на ‎Е,‏ ‎и ‎вы‏ ‎заходите ‎в‏ ‎тупик‏ ‎катастрофической ‎нехватки‏ ‎знаний ‎и ‎опыта. ‎Но ‎вы‏ ‎точно ‎знаете,‏ ‎что‏ ‎нужно, ‎нужно ‎нести‏ ‎в ‎мир‏ ‎красоту! ‎И ‎она ‎не‏ ‎за‏ ‎горами! ‎Нужно‏ ‎просто ‎изо‏ ‎дня ‎в ‎день ‎делать ‎какие-то‏ ‎новые‏ ‎действия, ‎опираясь‏ ‎на ‎знания‏ ‎и ‎опыт ‎того, ‎кто ‎на‏ ‎этом‏ ‎деле,‏ ‎как ‎говорится,‏ ‎«съел ‎собаку».‏ ‎И ‎вы‏ ‎ищите‏ ‎из ‎многих‏ ‎таких ‎«едоков», ‎но ‎тот ‎что-то‏ ‎не ‎то‏ ‎говорит,‏ ‎этого ‎не ‎так‏ ‎понятно, ‎а‏ ‎третий ‎вообще ‎говорит ‎заумные‏ ‎слова‏ ‎и ‎предлагает‏ ‎решения, ‎к‏ ‎которым ‎вы ‎не ‎готовы. ‎И‏ ‎вдруг‏ ‎вы ‎попадаете‏ ‎на ‎мой‏ ‎канал. ‎И ‎я ‎говорю ‎вам‏ ‎просто:‏ ‎«ПОВТОРЯЙТЕ‏ ‎ЗА ‎МНОЙ».‏ ‎Повторяя ‎красивую‏ ‎игру, ‎которую‏ ‎для‏ ‎вас ‎уже‏ ‎подготовили, ‎вы ‎рано ‎или ‎поздно‏ ‎закрепляете ‎в‏ ‎пальцах‏ ‎необходимые ‎красивости ‎и‏ ‎начинаете ‎эффективно‏ ‎применять ‎их ‎в ‎своём‏ ‎творчестве‏ ‎просто ‎чисто‏ ‎машинально. ‎И‏ ‎ЭТО ‎РАБОТАЕТ! ‎Я ‎сам ‎когда-то‏ ‎учился‏ ‎именно ‎так.‏ ‎Потом ‎вы‏ ‎начинаете ‎обосновывать ‎свои ‎решения ‎через‏ ‎знания‏ ‎теории‏ ‎музыки ‎и‏ ‎гармонии, ‎а‏ ‎это ‎уже‏ ‎путь‏ ‎к ‎совершенству.‏ ‎Но ‎начать ‎этот ‎путь ‎лучше‏ ‎с ‎быстрого‏ ‎первого‏ ‎результата, ‎опираясь ‎на‏ ‎многолетний ‎опыт‏ ‎прошедшего ‎этот ‎путь. ‎Не‏ ‎сомневаюсь,‏ ‎что ‎у‏ ‎вас ‎получится.‏ ‎Всё, ‎что ‎от ‎вас ‎требуется‏ ‎—‏ ‎минимальные ‎вложения‏ ‎— ‎200₽‏ ‎в ‎месяц ‎(это ‎сопоставимо ‎с‏ ‎тремя‏ ‎поездками‏ ‎в ‎московском‏ ‎метро ‎или‏ ‎чашечкой ‎латте‏ ‎в‏ ‎недорогой ‎московской‏ ‎кофейне), ‎а ‎также ‎некоторые ‎усилия‏ ‎в ‎копировании‏ ‎предложенных‏ ‎мною ‎моделей.

И ‎ВСЁ!

Подписывайтесь‏ ‎— ‎и‏ ‎будем ‎играть ‎красиво!

Как ‎же‏ ‎странно ‎слышать ‎«объективно ‎это ‎какая-то‏ ‎фигня» ‎или‏ ‎«ну‏ ‎объективно ‎мне ‎это‏ ‎совсем ‎не‏ ‎нравится». ‎А ‎ещё ‎корёжит‏ ‎с‏ ‎«объективно, ‎выглядит‏ ‎красиво!». ‎Что‏ ‎за ‎чушь? ‎Объективно ‎это ‎неоспоримо,‏ ‎непредвзято.‏ ‎Например, ‎ноутбук‏ ‎весит ‎два‏ ‎килограмма ‎и ‎сто ‎грамм. ‎Или‏ ‎что‏ ‎у‏ ‎отдельно ‎взятой‏ ‎машины ‎ровно‏ ‎четыре ‎колеса.‏ ‎Это‏ ‎объективно.

А ‎тяжелый‏ ‎ноутбук ‎или ‎легкий, ‎красивая ‎машина,‏ ‎или ‎страшная,‏ ‎это‏ ‎уже ‎совсем ‎не‏ ‎объективно, ‎это‏ ‎субъективно.

Програ́ммное ‎обеспе́чение

Програ́ммное‏ ‎обеспе́чение ‎обеспе́чивает ‎рабо́ту ‎компью́тера.

Мы ‎с‏ ‎вами ‎пишем‏ ‎програ́ммное‏ ‎обеспе́чение, ‎и ‎это‏ ‎совсем ‎не‏ ‎обеспече́ние ‎(как ‎некоторые ‎произносят),‏ ‎ни‏ ‎к ‎каким‏ ‎печенькам ‎ПО‏ ‎отношения ‎не ‎имеет ‎(даже ‎если‏ ‎речь‏ ‎про ‎кукисы).

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

Когда ‎вы‏ ‎пишите ‎тесты, вы ‎можете ‎столкнуться ‎с‏ ‎ситуацией, ‎что‏ ‎тест‏ ‎падает, ‎и ‎пока‏ ‎что ‎это‏ ‎ожидаемое ‎поведение ‎(например, ‎тест‏ ‎сломался,‏ ‎и ‎его‏ ‎нужно ‎починить,‏ ‎но ‎пока ‎что ‎нужно ‎пометить,‏ ‎что‏ ‎так ‎и‏ ‎задумано). ‎Для‏ ‎этого ‎в ‎pytest ‎есть ‎метка‏ ‎xfail.‏ ‎Просто‏ ‎навешиваем ‎декоратор‏ ‎xfail, и ‎если‏ ‎этот ‎тест‏ ‎упал,‏ ‎то ‎ничего‏ ‎страшного, ‎так ‎и ‎было ‎задумано‏ ‎(важно ‎не‏ ‎путать‏ ‎с ‎ожиданием ‎исключения,‏ ‎когда ‎мы‏ ‎хотим, ‎чтобы ‎произошла ‎ошибка‏ ‎в‏ ‎коде, ‎а‏ ‎не ‎в‏ ‎тесте).

Так ‎вот, ‎сегодня, ‎ковыряясь ‎в‏ ‎unittest,‏ ‎я ‎для‏ ‎себя ‎открыл‏ ‎декоратор ‎expectedFailure, и ‎у ‎меня ‎появилось‏ ‎понимание‏ ‎значения‏ ‎xfail: ‎«x»‏ ‎читается ‎как‏ ‎«ex», ‎то‏ ‎есть‏ ‎это ‎просто‏ ‎сокращение ‎для ‎«expected ‎failure».

Вот ‎так‏ ‎всё ‎просто,‏ ‎а‏ ‎я ‎и ‎не‏ ‎придавал ‎значения.

Хватит ‎путать‏ ‎git ‎и ‎GitHub ‎/ ‎GitLab

Что‏ ‎такое ‎git?‏ ‎Система‏ ‎контроля ‎версий. ‎Так‏ ‎почему ‎вы‏ ‎продолжаете ‎писать ‎«git» ‎/‏ ‎«гит»‏ ‎подразумевая ‎GitHub‏ ‎или ‎GitLab?‏ ‎Вы ‎же ‎понимаете, ‎что ‎это‏ ‎разные‏ ‎инструменты? ‎Вы‏ ‎пытаетесь ‎сэкономить‏ ‎три ‎буквы? ‎Почему ‎у ‎вас‏ ‎в‏ ‎голове‏ ‎укладывается ‎фраза‏ ‎«не ‎могу‏ ‎зайти ‎на‏ ‎git»,‏ ‎или ‎«у‏ ‎меня ‎недоступен ‎git»?

Прикиньте, ‎у ‎вас‏ ‎не ‎открывается‏ ‎интернет-магазин‏ ‎в ‎браузере, ‎и‏ ‎вы ‎пишете‏ ‎в ‎поддержку ‎«у ‎меня‏ ‎не‏ ‎работает ‎html».‏ ‎Звучит ‎странно,‏ ‎да? ‎И ‎даже ‎это ‎было‏ ‎бы‏ ‎более ‎логично,‏ ‎чем ‎путать‏ ‎git ‎и ‎сайт ‎по ‎типу‏ ‎GitHub,‏ ‎ведь‏ ‎у ‎вас‏ ‎может ‎быть‏ ‎старый ‎браузер,‏ ‎в‏ ‎котором ‎действительно‏ ‎не ‎работают ‎новые ‎фишки ‎свежего‏ ‎HTML.

Вы ‎бы‏ ‎ещё‏ ‎про ‎Bitbucket ‎писали‏ ‎«git». ‎Или,‏ ‎раз ‎название ‎начинается ‎не‏ ‎на‏ ‎«Git», ‎то‏ ‎не ‎стыкуется?‏ ‎Кстати, ‎а ‎битбакет ‎ещё ‎существует?

Он‏ ‎же‏ ‎Гога, ‎он‏ ‎же ‎Гоша,‏ ‎он ‎же ‎Юрий, ‎он ‎же‏ ‎Гора,‏ ‎он‏ ‎же ‎Жора

Запускайте ‎код‏ ‎реже

Не ‎нужно ‎запускать ‎код ‎после‏ ‎каждой ‎новой‏ ‎строчки.‏ ‎Не ‎нужно ‎запускать‏ ‎код ‎даже‏ ‎после ‎создания ‎новой ‎функции.‏ ‎Вам‏ ‎кажется, ‎что‏ ‎что-то ‎не‏ ‎так, ‎и ‎что ‎где-то ‎будет‏ ‎ошибка.‏ ‎И, ‎вероятно,‏ ‎это ‎будет‏ ‎так. ‎Особенно ‎на ‎старте. ‎Но‏ ‎не‏ ‎тратьте‏ ‎время ‎зря.‏ ‎Описывайте ‎понятные‏ ‎короткие ‎функции,‏ ‎добавляйте‏ ‎логирование, ‎ловите‏ ‎исключения. ‎И ‎при ‎запуске ‎проверяйте‏ ‎фичу ‎целиком.‏ ‎У‏ ‎вас ‎нет ‎задачи‏ ‎«написать ‎функцию».‏ ‎Есть ‎задача ‎«выполнить ‎работу‏ ‎от‏ ‎А ‎до‏ ‎Б». ‎И‏ ‎вот ‎проверяйте, ‎работает ‎ли ‎фича,‏ ‎а‏ ‎не ‎отдельная‏ ‎функция.

А ‎ещё‏ ‎пишите ‎тесты.

Полдюжины

Почему ‎не‏ ‎проще ‎сказать ‎«шесть»?

А ‎на ‎английском‏ ‎вообще ‎«half‏ ‎a‏ ‎dozen» ‎vs ‎«six».

Зачем?

Начните ‎с‏ ‎юнит-тестов. ‎Потом ‎можно ‎разобраться ‎с‏ ‎апи-тестами. ‎Про‏ ‎интеграционные‏ ‎тесы ‎даже ‎пока‏ ‎заикаться ‎не‏ ‎буду.

В ‎Python ‎начинайте ‎с‏ ‎unittest,‏ ‎потом ‎переходите‏ ‎на ‎pytest.‏ ‎С ‎pytest ‎уже ‎никуда ‎уходить‏ ‎не‏ ‎нужно, ‎это‏ ‎лучший ‎фреймворк‏ ‎для ‎тестирования.

Вы ‎задумывались,‏ ‎что ‎никто ‎уже ‎давно ‎не‏ ‎вешает ‎и‏ ‎даже‏ ‎не ‎кладёт ‎трубку?‏ ‎Мы ‎сбрасываем‏ ‎звонок, ‎отключаемся, ‎выходим ‎с‏ ‎созвона‏ ‎/ ‎встречи‏ ‎/ ‎митинга.‏ ‎Но ‎всё ‎равно ‎в ‎обиходе‏ ‎присутствует‏ ‎«повесить ‎трубку»,‏ ‎хотя ‎вешать,‏ ‎в ‎общем-то, ‎и ‎нечего, ‎и‏ ‎некуда.

Как ‎же‏ ‎я ‎не ‎люблю, ‎когда ‎один‏ ‎тип ‎можно‏ ‎обозначить‏ ‎двумя ‎расширениями. ‎Зачем‏ ‎существует ‎`.yml`,‏ ‎когда ‎есть ‎`.yaml`? ‎Кто‏ ‎и‏ ‎что ‎пытался‏ ‎сэкономить, ‎добавляя‏ ‎возможность ‎сделать ‎сокращенное ‎расширение? ‎Вот‏ ‎между‏ ‎`.doc` ‎и‏ ‎`.docx` ‎огромная‏ ‎разница. ‎А ‎зачем ‎так ‎поступили‏ ‎с‏ ‎ямлом?

Я‏ ‎обычно ‎использую‏ ‎`.yaml`. ‎Но‏ ‎когда ‎замечаю,‏ ‎что‏ ‎уже ‎написал‏ ‎`.yml`, ‎просто ‎тяжело ‎вздыхаю ‎и‏ ‎оставляю ‎как‏ ‎есть.

А‏ ‎вы ‎как ‎именуете?

Какие ‎носки‏ ‎парные? ‎Для ‎меня ‎в ‎первую‏ ‎очередь ‎это‏ ‎те,‏ ‎которые ‎одинаково ‎сидят‏ ‎на ‎ногах,‏ ‎на ‎одинаковой ‎высоте, ‎одинаково‏ ‎сдавливают‏ ‎(или ‎одинаково‏ ‎не ‎ощущаются).‏ ‎Цвет ‎или ‎рисунок ‎на ‎носках‏ ‎далеко‏ ‎не ‎первичный‏ ‎признак ‎парности.‏ ‎Более ‎того, ‎если ‎брать ‎носки‏ ‎набором‏ ‎(например‏ ‎пять ‎пар‏ ‎вместе), ‎то‏ ‎вообще ‎не‏ ‎важно,‏ ‎каких ‎они‏ ‎цветов. ‎Все ‎носки ‎из ‎одного‏ ‎набора ‎удобно‏ ‎носить‏ ‎в ‎любом ‎сочетании‏ ‎(пока ‎какие-то‏ ‎не ‎станут ‎более ‎разношенными).‏ ‎Ну‏ ‎и ‎что,‏ ‎что ‎на‏ ‎одной ‎ноге ‎красный ‎носок, ‎а‏ ‎на‏ ‎другой ‎зеленый?‏ ‎Какая ‎разница?‏ ‎Главное ‎что ‎удобно. ‎И ‎что‏ ‎носки‏ ‎без‏ ‎дырок.

У ‎вас‏ ‎есть ‎main.py, или ‎app.py, или ‎run.py. Это ‎ваш‏ ‎главный ‎модуль,‏ ‎он‏ ‎же ‎«точка ‎входа».‏ ‎Вы ‎запускаете‏ ‎своё ‎приложение ‎через ‎этот‏ ‎модуль.‏ ‎В ‎этом‏ ‎модуле ‎импортировано‏ ‎всё, ‎что ‎нужно ‎для ‎запуска‏ ‎этого‏ ‎проекта. ‎Из‏ ‎главного ‎модуля‏ ‎нельзя ‎импортировать ‎ничего ‎и ‎никогда.‏ ‎Никакой‏ ‎вложенный‏ ‎модуль ‎не‏ ‎может ‎импортировать‏ ‎из ‎главного‏ ‎модуля.‏ ‎Ваша ‎рука‏ ‎не ‎должна ‎никогда ‎даже ‎близко‏ ‎находиться ‎к‏ ‎набору‏ ‎from ‎main ‎import‏ ‎….

Почему ‎«единая‏ ‎очередь» ‎не ‎везде? ‎Например, ‎в‏ ‎продуктовом ‎магазине‏ ‎нужно‏ ‎выбрать ‎кассу, ‎где‏ ‎поменьше ‎людей,‏ ‎и ‎у ‎людей ‎корзины‏ ‎поменьше.‏ ‎Почему ‎нельзя‏ ‎выстроить ‎одну‏ ‎очередь, ‎а ‎к ‎освободившейся ‎кассе‏ ‎будет‏ ‎подходить ‎следующий‏ ‎человек ‎из‏ ‎очереди?

Подобное ‎часто ‎можно ‎встретить ‎на‏ ‎паспортном‏ ‎контроле‏ ‎в ‎аэропорту:‏ ‎ты ‎можешь‏ ‎стоять ‎двадцать‏ ‎минут‏ ‎ждать, ‎пока‏ ‎человека ‎перед ‎тобой ‎дополнительно ‎опрашивают‏ ‎и ‎тщательно‏ ‎проверяют‏ ‎его ‎документы. ‎А‏ ‎буквально ‎соседняя‏ ‎очередь ‎двигается ‎со ‎скоростью‏ ‎два‏ ‎человека ‎в‏ ‎минуту. ‎В‏ ‎аэропорту ‎Звартноц ‎(международный ‎аэропорт ‎Еревана)‏ ‎как‏ ‎раз ‎используют‏ ‎единую ‎очередь,‏ ‎там ‎даже ‎под ‎это ‎выделен‏ ‎отдельный‏ ‎человек.‏ ‎И ‎каждому‏ ‎говорят ‎«идите‏ ‎к ‎седьмому‏ ‎окошку»,‏ ‎«идите ‎к‏ ‎пятому ‎окошку».

Понятно, ‎что ‎не ‎важно,‏ ‎какое ‎распределение,‏ ‎если‏ ‎ни ‎одно ‎окошко‏ ‎/ ‎ни‏ ‎одна ‎касса ‎не ‎простаивает.‏ ‎И‏ ‎общее ‎время‏ ‎обработки ‎всё‏ ‎равно ‎не ‎изменится. ‎Но ‎время‏ ‎ожидания‏ ‎отдельного ‎человека‏ ‎может ‎сильно‏ ‎сократиться, ‎плюс ‎вклиниться ‎в ‎такую‏ ‎очередь‏ ‎будет‏ ‎заметно ‎сложнее.

Что ‎за‏ ‎долг ‎знаний? ‎Это ‎когда ‎вы‏ ‎уже ‎можете‏ ‎что-то‏ ‎сделать, ‎но ‎пока‏ ‎не ‎понимаете,‏ ‎как ‎программа ‎работает, ‎как‏ ‎вам‏ ‎удалось. ‎И‏ ‎речь ‎не‏ ‎про ‎простую ‎копипасту, ‎я ‎про‏ ‎написание‏ ‎строк ‎кода.‏ ‎Например, ‎вы‏ ‎не ‎понимаете, ‎как ‎работает ‎библиотека‏ ‎requests,‏ ‎как‏ ‎расшифровывается ‎API‏ ‎или ‎что‏ ‎такое ‎json,‏ ‎но‏ ‎уже ‎можете‏ ‎сделать ‎запрос ‎на ‎API ‎сервис‏ ‎погоды ‎и‏ ‎отправить‏ ‎прогноз ‎пользователю ‎через‏ ‎телеграм ‎бот.‏ ‎Если ‎при ‎этом ‎у‏ ‎вас‏ ‎есть ‎ощущение‏ ‎«вроде ‎работает,‏ ‎но ‎я ‎не ‎понимаю ‎как‏ ‎и‏ ‎почему», ‎то‏ ‎это ‎тот‏ ‎самый ‎долг ‎знаний.

Долг ‎знаний ‎—‏ ‎круто.‏ ‎Это‏ ‎значит, ‎что‏ ‎вы ‎движетесь‏ ‎вперед ‎и‏ ‎растёте.‏ ‎Позже, ‎когда‏ ‎придёт ‎время, ‎вы ‎разберетесь ‎со‏ ‎всем, ‎что‏ ‎было‏ ‎непонятно ‎ранее. ‎Но‏ ‎эти ‎скучные‏ ‎и ‎даже ‎нудные ‎знания‏ ‎не‏ ‎нужны ‎на‏ ‎старте, ‎когда‏ ‎в ‎вас ‎горит ‎желание ‎сделать‏ ‎что-то‏ ‎полезное ‎и‏ ‎наглядное.

Непонятно, ‎как‏ ‎работает ‎список? ‎Почему ‎он ‎расширяется,‏ ‎и‏ ‎зачем‏ ‎тогда ‎вообще‏ ‎использовать ‎кортеж?‏ ‎Не ‎страшно,‏ ‎потом‏ ‎разберетесь, ‎узнаете‏ ‎про ‎особенности ‎всего, ‎что ‎вы‏ ‎используете ‎в‏ ‎коде.‏ ‎А ‎пока ‎просто‏ ‎пишите ‎код,‏ ‎который ‎будет ‎работать. ‎Пишите‏ ‎как‏ ‎понимаете, ‎смотрите‏ ‎на ‎примеры‏ ‎из ‎документации ‎и ‎переписывайте ‎вручную‏ ‎то‏ ‎же ‎самое‏ ‎(главное ‎не‏ ‎копипастить).

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

Вы ‎не‏ ‎знаете, ‎на ‎какой ‎операционной ‎системе‏ ‎будет ‎работать‏ ‎ваше‏ ‎приложение. ‎И ‎в‏ ‎какую ‎папку‏ ‎сложат ‎ваш ‎проект. ‎Вы‏ ‎можете‏ ‎работать ‎на‏ ‎макос, ‎ваш‏ ‎коллега ‎пишет ‎на ‎винде, ‎а‏ ‎в‏ ‎продакшн ‎запустят‏ ‎на ‎убунте.

Необходимо‏ ‎надежно ‎получать ‎путь ‎к ‎файлу‏ ‎для‏ ‎чтения‏ ‎/ ‎записи,‏ ‎независимо ‎от‏ ‎платформы ‎и‏ ‎места‏ ‎хранения.

Нельзя ‎указать‏ ‎просто ‎захардкоженный ‎абсолютный ‎путь ‎к‏ ‎файлу, ‎просто‏ ‎потому‏ ‎что ‎на ‎всех‏ ‎ОС ‎будет‏ ‎разный ‎корень, ‎не ‎говоря‏ ‎уже‏ ‎о ‎разных‏ ‎именах ‎пользователя.‏ ‎Вам ‎нужно ‎знать ‎путь ‎к‏ ‎файлу‏ ‎и ‎путь‏ ‎к ‎корню,‏ ‎откуда ‎вы ‎работаете.

Вы ‎не ‎сможете‏ ‎использовать‏ ‎абсолютный‏ ‎путь ‎к‏ ‎файлу ‎в‏ ‎хранилище, ‎так‏ ‎как‏ ‎не ‎знаете‏ ‎корень ‎хранилища ‎заранее. ‎К ‎примеру,‏ ‎у ‎вас‏ ‎может‏ ‎быть ‎отдельно ‎бакет‏ ‎S3 ‎и‏ ‎отдельно ‎путь ‎к ‎файлу.‏ ‎И‏ ‎только ‎при‏ ‎обращении ‎вы‏ ‎будете ‎склеивать ‎полный ‎путь.

Абсолютный ‎путь‏ ‎тоже‏ ‎строится ‎относительно.‏ ‎Вы ‎можете‏ ‎быть ‎уверены, ‎что ‎файлы ‎вашего‏ ‎проекта‏ ‎будут‏ ‎расположены ‎именно‏ ‎в ‎таком‏ ‎виде ‎на‏ ‎любой‏ ‎ОС. ‎Поэтому‏ ‎вы ‎выбираете ‎файл ‎внутри ‎вашего‏ ‎проекта, ‎относительно‏ ‎которого‏ ‎вы ‎будете ‎строить‏ ‎абсолютный ‎путь.‏ ‎Например, ‎это ‎файл, ‎где‏ ‎вы‏ ‎читаете ‎конфигурацию.‏ ‎Берете ‎путь‏ ‎к ‎файлу, ‎через ‎него ‎получаете‏ ‎путь‏ ‎к ‎корню‏ ‎вашего ‎проекта,‏ ‎и ‎уже ‎относительно ‎этого ‎значения‏ ‎строите‏ ‎абсолютные‏ ‎пути.

И ‎да,‏ ‎вот ‎эти‏ ‎абсолютные ‎пути,‏ ‎построенные‏ ‎относительно ‎корня‏ ‎проекта, ‎удобнее ‎и ‎надежнее, ‎чем‏ ‎обычные ‎относительные‏ ‎пути.

Даже ‎если‏ ‎«ну ‎только ‎в ‎этот ‎раз».‏ ‎Нет. ‎И‏ ‎«только‏ ‎быстренько ‎для ‎отладки»‏ ‎тоже ‎нет.‏ ‎Абсолютные ‎пути ‎должны ‎быть‏ ‎всегда.‏ ‎Относительных ‎путей‏ ‎не ‎должно‏ ‎быть ‎совсем. ‎Никогда.

Чтение ‎или ‎запись‏ ‎файла?‏ ‎Указывайте ‎абсолютный‏ ‎путь.

Почему? ‎Относительный‏ ‎путь ‎вычисляется ‎относительно ‎текущей ‎рабочей‏ ‎директории.‏ ‎Абсолютный‏ ‎путь ‎вычисляется‏ ‎относительно ‎корня‏ ‎файловой ‎системы.‏ ‎Что‏ ‎реже ‎меняется?‏ ‎Вот ‎это ‎и ‎выбираем.

Список ‎ситуаций,‏ ‎когда ‎можно‏ ‎использовать‏ ‎относительные ‎пути:

•

Как ‎классно‏ ‎готовиться. ‎Например, ‎готовиться ‎снимать ‎видео.‏ ‎Так ‎и‏ ‎думаешь‏ ‎себе ‎в ‎голове,‏ ‎как ‎классно‏ ‎всё ‎расскажешь. ‎Или ‎готовиться‏ ‎писать‏ ‎пост. ‎Уже‏ ‎планируешь, ‎как‏ ‎красиво ‎изложишь ‎мысль ‎(нет).

А ‎этап‏ ‎подготовки‏ ‎перед ‎этим‏ ‎ещё ‎интереснее:‏ ‎оформить ‎заметку, ‎потом ‎понять, ‎что‏ ‎есть‏ ‎мысли‏ ‎по ‎ещё‏ ‎нескольким ‎темам,‏ ‎поэтому ‎надо‏ ‎дополнить‏ ‎список. ‎Затем‏ ‎увидеть, ‎что ‎список ‎можно ‎переоформить‏ ‎в ‎виде‏ ‎таблицы,‏ ‎переделать ‎ещё ‎раз.‏ ‎и, ‎вроде‏ ‎как, ‎это ‎называется ‎«прокрастинация»‏ ‎—‏ ‎обратная ‎сторона‏ ‎перфекционизма, ‎когда‏ ‎ты ‎делаешь ‎всё, ‎кроме ‎того,‏ ‎что‏ ‎нужно, ‎и‏ ‎находишь ‎себе‏ ‎оправдание, ‎ведь ‎надо ‎же ‎сделать‏ ‎красиво,‏ ‎верно?

Только‏ ‎этап ‎подготовки‏ ‎к ‎путешествию‏ ‎не ‎люблю.‏ ‎Каждый‏ ‎раз ‎собирать‏ ‎вещи. ‎тяжеловато.