А то по этим кусочкам кода можно лишь строить догадки о том, куда их нужно засовывать, чтобы всё заработало. Получается, что туториал какой-то не особо полезный. Не туториал, а головоломка какая-то =)
Что читая основательные работы и книги именитых авторов, что подобные авторские статьи про психологию, крайне трудно следовать совету «чтобы перестать бояться, нужно просто перестать бояться, пересилить себя, идти навстречу страху». Почти невозможно. Это утопия. Но польза во всех этих книгах и статьях точно есть — осознать проблему, либо вспомнить о ней, если осознавали раньше, и наконец воодушевиться что-то менять в жизни.
А если действительно нужно «преодолеть себя» и изменить свои устоявшиеся годами паттерны поведения, то нужно обращаться к специалисту, то есть к психологу. Но почему-то об этом в подобных статьях и книгах-как-решить-все-проблемы писать не принято. Поэтому напишу я: «Эй, ты! Да, ты, кто узнал(а) себя в этой статье! Погугли в интернете хорошего психолога (и в идеале недешевого, с ценой за консультацию от 5 тр), и иди к нему! Если уж он не поможет, то никто тебе не поможет! От хорошего психолога результат будет уже после первой консультации. Но на всякий случай морально смирись, что, возможно, потребуется около 30 тысяч и примерно месяц на то, чтобы проработать несколько корневых причин твоей прокрастинации и избегания путей к жизни, о которой мечтал(а). Это те инвестиции в себя, которые точно стократ окупятся!»
Вам не приходилось отслеживать в git какие-то правки, когда в каждом комите названия переменных меняются - считай рефакторинг?
Да, приходилось. Да вроде особых проблем не было с этим. Может, были по началу, но сейчас вроде норм. Может, у нас не такой масштаб, как у вас, поэтому нет особых проблем, не знаю.
А Фигма разве умеет гарантировать, что все ключи картинок (включая прошлые и будущие) будут например, уникальными?
Как дизайнер назовет, так оно и сохраняется из Фигмы :] Не особо народ запаривается на этот счет. То есть, иногда переименовывают, конечно, но всё равно, к сожалению, нет гарантии, что по названию картинки будет понятно, что это.
По поводу Localizable.strings - а зачем вам повторяющиеся строки в этом файле, если xcode все равно выберет одну из этих строк?
Ключи у нас уникальные, а вот значения могут быть разные. Например, сверстали два разных человека два разных экрана. Условно, один верстал онбординг, второй в это время верстал экран подписки. И там, и тут встречается одна и та же фраза на кнопке Продолжить ("Continue"). И вот один разраб в Localizable сделал строчку "onboardingContinueButton" = "Continue";, а второй сделал такую же параллельно "subscriptionContinueButton" = "Continue";. Потом когда-нибудь эти ветки слились в develop, и вот вам два одинаковых текста на разных экранах. А если таких экранов много, то вероятность повторяющегося текста еще больше растет. В общем, я к тому, что по ключам можно искать, как вы предложили, но зачем? Если уж на то пошло, можно вообще не просить никого делать нормальный нейминг, а каждый раз заниматься вот такими вот детективными расследованиями. Но зачем? Цель статьи как раз и заключается в том, чтобы побудить давать более-менее однозначные названия, а не какие-то ноунейм или абстрактные, из-за которых приходится потом тратить лишнее время на поиски. :]
Если по смыслу лучше подходит «are», я именую с «are». :] А как иначе? Язык Свифт как раз-таки и создавался похожим на просто английский язык, поэтому логично соблюдать правила языка.
UI на констрейнтах чисто кодом — постоянно. А что в этом такого? На мой взгляд, это хороший способ, ведь в коде всё прозрачно и понятно, никакой магии, всё на виду.
Предлагаю ли я переименовывать переменные всякий раз, когда меняется UI? Конечно! А какой смысл, например, оставлять в названии какой-нибудь color, когда теперь эта кнопка отвечает за size? :] Как дядюшка Боб завещал: «Видишь плохо именованную штуку — не проходи мимо, переименуй в более подходящее название». Если политика компании позволяет, конечно. У нас позволяет. :]
Касаемо вашего способа по поиску текстов и картинок там, где они присваиваются. Да, это тоже вариант, спасибо. Иногда и такой способ может выручить. А если картинки и тексты присваиваются не в месте их объявления? А если картинки присваиваются как imageView.image = UIImage(named: «тут какое-то абстрактное название с цифрой, потому что так из Фигмы сохранилось»)? Это мне каждый раз лезть в ассеты и искать там эту картинку? На мой взгляд, всё же быстрее правильно проименовать и/или написать пару строк документации, не заставляя читателя рыться в картинках и искать по всему документу (а то и вовсе снаружи документа), где там присваиваются значения у свойств. Тем более, что локализованые тексты обычно задаются в виде ключа, а содержимое ключа прописано в файле Localizable.string (а там 100500+ ключей, и содержимое порой повторяется… да ну, нет, не стоит так издеваться над проверяющим).
Убрать фазу компиляции ассетов из сборки проекта.
Компилировать ассеты самостоятельно только в случае их изменения.
Положить скомпилированные ассеты в бандл приложения при сборке.
Спасибо за уделенное время.
Говорят, что в программировании самое трудное — это выбор правильных имён. Что бы вы посоветовали в плане улучшения имён в данной статье?
И о каких ошибках идёт речь?
Супер, огонь!
Статья большая, поэтому неудивительно, что встречаются опечатки. В основном некритичные, так что ничего страшного, всё-таки такая большая работа была проделана! Но, наверное, стоит исправить хотя бы одну, критичную, чтобы не вводить новичков в заблуждение. :]
А именно, в конце в разделе «10. Функция asyncAfter (deadline: .now() + 0.1, qos: .userInteractive) c изменением приоритета» нужно в выводе написать НЕ СОВПАДАЮТ. Очевидно, пропущена частица НЕ, что меняет смысл вывода на противоположный.
Ну, и вот здесь, на мой взгляд, стоит перефразировать одно предложение:
«Барьеры GCD делают одну интересную вещь — они ожидают момента, когда очередь будет полностью пуста, перед тем как выполнить свое замыкание.»
Всё же лучше написать как-то вот так, как считаете?
«Барьеры GCD делают одну интересную вещь: они заставляют очередь временно не начинать новые задачи и ждут, пока все работающие в очереди задачи закончат свою работу, а затем выполняют свое замыкание.»
А то, когда я только начинал знакомство с многопоточностью (месяца 4 назад) и впервые прочитал эту статью, мне эти фразы вынесли мозг :]]]
Добрый день.
Использовать extention'ы удобно для тех, кто имеет опыт их использования. Это был пример скорее для них, нежели для всех.
Вам же рекомендую пропустить и не вставлять extension Waiter и extension Cook, как вы делали по порядку. Просто подправьте код, написанный ранее, добавив туда соответствующие строчки. Как раз далее я написал о том, что для для простоты мы удалим extention'ы (экстеншены) и перенесем строчки в код. И чуть ниже идут переделанные классы Waiter и Cook уже со всеми исправлениями и доработками. Надеюсь, что это помогло :)
Безусловно вы правы во всем, спасибо. Но обо всех тонкостях в одной статье не написать, да и не это было целью. Для меня главное, чтобы читатели, такие как я, у которых до конца не складывался пазл про делегаты и колбэки, наконец-то поняли «на пальцах», как это работает и когда это применяется ))
Возвращение Bool было не обязательным, конечно. Это так, для примера. Может, стоит предупредить о этом… Надо подумать. Просто не хотел бы превращать статью еще и в разбор правил построения замыканий. Она и так очень уж большая получилась, на мой взгляд ))
Благодарю за комментарий.
Я намеренно сделал несколько допущений, чтобы не усложнять. Конечно же, я надеюсь никто из изучающих Swift не будет делать force unwrapping в своих приложениях. Я полагаю, что те, кто дошел до изучения UIKit, уже знает и про опционалы, и опасность force unwrapping, и про то, что нужно делать код безопасным через optional binding (if let или guard let). Сомневаюсь, что кто-то начинает изучение Swift сразу с делегатов, не изучив опционалы и опциональные цепочки )) Поэтому эта статья будет полезна тем, кто уже столкнулся с делегатами и колбэками и теперь лишь пытается разобраться до конца и уложить кусочки пазла в целостную картину ))
А то по этим кусочкам кода можно лишь строить догадки о том, куда их нужно засовывать, чтобы всё заработало. Получается, что туториал какой-то не особо полезный. Не туториал, а головоломка какая-то =)
А есть ссылка на весь код проекта?
Ощущение, что статью писал ChatGPT. =)
Всё очень поверхностно и абстрактно. Кажется, автор сам не разобрался в теме.
Что читая основательные работы и книги именитых авторов, что подобные авторские статьи про психологию, крайне трудно следовать совету «чтобы перестать бояться, нужно просто перестать бояться, пересилить себя, идти навстречу страху». Почти невозможно. Это утопия. Но польза во всех этих книгах и статьях точно есть — осознать проблему, либо вспомнить о ней, если осознавали раньше, и наконец воодушевиться что-то менять в жизни.
А если действительно нужно «преодолеть себя» и изменить свои устоявшиеся годами паттерны поведения, то нужно обращаться к специалисту, то есть к психологу. Но почему-то об этом в подобных статьях и книгах-как-решить-все-проблемы писать не принято. Поэтому напишу я: «Эй, ты! Да, ты, кто узнал(а) себя в этой статье! Погугли в интернете хорошего психолога (и в идеале недешевого, с ценой за консультацию от 5 тр), и иди к нему! Если уж он не поможет, то никто тебе не поможет! От хорошего психолога результат будет уже после первой консультации. Но на всякий случай морально смирись, что, возможно, потребуется около 30 тысяч и примерно месяц на то, чтобы проработать несколько корневых причин твоей прокрастинации и избегания путей к жизни, о которой мечтал(а). Это те инвестиции в себя, которые точно стократ окупятся!»
Маленькая незначительная поправочка: правильно будет написать 'camelCase', потому что 'CamelCase' - это уже по сути 'PascalCase'. ?
Вам не приходилось отслеживать в git какие-то правки, когда в каждом комите названия переменных меняются - считай рефакторинг?Да, приходилось. Да вроде особых проблем не было с этим. Может, были по началу, но сейчас вроде норм. Может, у нас не такой масштаб, как у вас, поэтому нет особых проблем, не знаю.
А Фигма разве умеет гарантировать, что все ключи картинок (включая прошлые и будущие) будут например, уникальными?Как дизайнер назовет, так оно и сохраняется из Фигмы :] Не особо народ запаривается на этот счет. То есть, иногда переименовывают, конечно, но всё равно, к сожалению, нет гарантии, что по названию картинки будет понятно, что это.
По поводу Localizable.strings - а зачем вам повторяющиеся строки в этом файле, если xcode все равно выберет одну из этих строк?Ключи у нас уникальные, а вот значения могут быть разные. Например, сверстали два разных человека два разных экрана. Условно, один верстал онбординг, второй в это время верстал экран подписки. И там, и тут встречается одна и та же фраза на кнопке Продолжить ("Continue"). И вот один разраб в Localizable сделал строчку
"onboardingContinueButton" = "Continue";, а второй сделал такую же параллельно"subscriptionContinueButton" = "Continue";. Потом когда-нибудь эти ветки слились в develop, и вот вам два одинаковых текста на разных экранах. А если таких экранов много, то вероятность повторяющегося текста еще больше растет. В общем, я к тому, что по ключам можно искать, как вы предложили, но зачем? Если уж на то пошло, можно вообще не просить никого делать нормальный нейминг, а каждый раз заниматься вот такими вот детективными расследованиями. Но зачем? Цель статьи как раз и заключается в том, чтобы побудить давать более-менее однозначные названия, а не какие-то ноунейм или абстрактные, из-за которых приходится потом тратить лишнее время на поиски. :]Спасибо за комментарий!
Если по смыслу лучше подходит «are», я именую с «are». :] А как иначе? Язык Свифт как раз-таки и создавался похожим на просто английский язык, поэтому логично соблюдать правила языка.
UI на констрейнтах чисто кодом — постоянно. А что в этом такого? На мой взгляд, это хороший способ, ведь в коде всё прозрачно и понятно, никакой магии, всё на виду.
Предлагаю ли я переименовывать переменные всякий раз, когда меняется UI? Конечно! А какой смысл, например, оставлять в названии какой-нибудь color, когда теперь эта кнопка отвечает за size? :] Как дядюшка Боб завещал: «Видишь плохо именованную штуку — не проходи мимо, переименуй в более подходящее название». Если политика компании позволяет, конечно. У нас позволяет. :]
Касаемо вашего способа по поиску текстов и картинок там, где они присваиваются. Да, это тоже вариант, спасибо. Иногда и такой способ может выручить. А если картинки и тексты присваиваются не в месте их объявления? А если картинки присваиваются как imageView.image = UIImage(named: «тут какое-то абстрактное название с цифрой, потому что так из Фигмы сохранилось»)? Это мне каждый раз лезть в ассеты и искать там эту картинку? На мой взгляд, всё же быстрее правильно проименовать и/или написать пару строк документации, не заставляя читателя рыться в картинках и искать по всему документу (а то и вовсе снаружи документа), где там присваиваются значения у свойств. Тем более, что локализованые тексты обычно задаются в виде ключа, а содержимое ключа прописано в файле Localizable.string (а там 100500+ ключей, и содержимое порой повторяется… да ну, нет, не стоит так издеваться над проверяющим).
А можно как-то подробнее про эти три пункта? )
Говорят, что в программировании самое трудное — это выбор правильных имён. Что бы вы посоветовали в плане улучшения имён в данной статье?
И о каких ошибках идёт речь?
Статья большая, поэтому неудивительно, что встречаются опечатки. В основном некритичные, так что ничего страшного, всё-таки такая большая работа была проделана! Но, наверное, стоит исправить хотя бы одну, критичную, чтобы не вводить новичков в заблуждение. :]
А именно, в конце в разделе «10. Функция asyncAfter (deadline: .now() + 0.1, qos: .userInteractive) c изменением приоритета» нужно в выводе написать НЕ СОВПАДАЮТ. Очевидно, пропущена частица НЕ, что меняет смысл вывода на противоположный.
Ну, и вот здесь, на мой взгляд, стоит перефразировать одно предложение:
Всё же лучше написать как-то вот так, как считаете?
«Барьеры GCD делают одну интересную вещь: они заставляют очередь временно не начинать новые задачи и ждут, пока все работающие в очереди задачи закончат свою работу, а затем выполняют свое замыкание.»
А то, когда я только начинал знакомство с многопоточностью (месяца 4 назад) и впервые прочитал эту статью, мне эти фразы вынесли мозг :]]]
Спасибо за Ваш труд!
Использовать extention'ы удобно для тех, кто имеет опыт их использования. Это был пример скорее для них, нежели для всех.
Вам же рекомендую пропустить и не вставлять extension Waiter и extension Cook, как вы делали по порядку. Просто подправьте код, написанный ранее, добавив туда соответствующие строчки. Как раз далее я написал о том, что для для простоты мы удалим extention'ы (экстеншены) и перенесем строчки в код. И чуть ниже идут переделанные классы Waiter и Cook уже со всеми исправлениями и доработками. Надеюсь, что это помогло :)
Возвращение Bool было не обязательным, конечно. Это так, для примера. Может, стоит предупредить о этом… Надо подумать. Просто не хотел бы превращать статью еще и в разбор правил построения замыканий. Она и так очень уж большая получилась, на мой взгляд ))
Я намеренно сделал несколько допущений, чтобы не усложнять. Конечно же, я надеюсь никто из изучающих Swift не будет делать force unwrapping в своих приложениях. Я полагаю, что те, кто дошел до изучения UIKit, уже знает и про опционалы, и опасность force unwrapping, и про то, что нужно делать код безопасным через optional binding (if let или guard let). Сомневаюсь, что кто-то начинает изучение Swift сразу с делегатов, не изучив опционалы и опциональные цепочки )) Поэтому эта статья будет полезна тем, кто уже столкнулся с делегатами и колбэками и теперь лишь пытается разобраться до конца и уложить кусочки пазла в целостную картину ))