Comments 86
Хотелось бы видеть не только список «хитрых» моментов, но и пояснение (что это, зачем это, почему в Swift это реализовано именно так). Иначе вы получите очередную волну разработчиков, которые «копипастят» ответ из вашей же статьи не разобравшись в сути происходящего. Ну или дать ссылки на статьи, где соответствующая тема раскрыта.
А пока что статья тянет на жалобу+опрос.
Два года назад? Автор статьи новичок или опытный???
А пока что статья тянет на жалобу+опрос.
Начнем с того, что буквально два года назад мобильная разработка под iOS приобрела свой неповторимый вкус, и это связано с появлением такого языка как Swift
Два года назад? Автор статьи новичок или опытный???
Добрый день. Скорее это был литературный оборот, чем точная формулировка. Да, согласен. Дату можно поправить, конечно, если это прямо очень принципиально. Эта статья пока планируется как первая из цикла статей. И если эта тема будет интересна сообществу, то каждый вопрос, безусловно, можно раскрыть более подробно, а также добавить другие вопросы, которые задаются во время собеседования.
Проблема на мой взгляд в изоляции системы. При разработке под андроид всегда можно найти фундаментальные основы на java. Под iOS же учатся кодить по youtube.
В текущей ситуации можно разве что спрашивать еще и по Objective-C. Если новичок потратил время на немодный, но лежащий в основе, язык, то скорее всего он чуть больше чем формошлепер.
В текущей ситуации можно разве что спрашивать еще и по Objective-C. Если новичок потратил время на немодный, но лежащий в основе, язык, то скорее всего он чуть больше чем формошлепер.
Изоляции как таковой нет:
Просто на остальных платформах языку приходится конкурировать с очень сильными языками (напр. Rust).
Open-source Swift can be used on Linux to build Swift libraries and applications. The open-source binary builds provide the Swift compiler and standard library, Swift REPL and debugger (LLDB), and the core libraries, so one can jump right in to Swift development.
Просто на остальных платформах языку приходится конкурировать с очень сильными языками (напр. Rust).
По факту Swift используется на одной платформе, хоть возможности и позволяют использовать не только под iOS (macOS).
Под изоляцией я имею ввиду скорее скудность учебного материала. Есть ряд простых задач (отправить запрос на сервер, сохранить в базу, отобразить), есть уроки как это сделать. Пояснений как работают запросы/БД/UI нет. Нет банды четырех или чистого когда на Swift. Соответственно новичок посмотрит пару уроков и решит что язык он знает, можно идти загребать деньги лопатой.
Под изоляцией я имею ввиду скорее скудность учебного материала. Есть ряд простых задач (отправить запрос на сервер, сохранить в базу, отобразить), есть уроки как это сделать. Пояснений как работают запросы/БД/UI нет. Нет банды четырех или чистого когда на Swift. Соответственно новичок посмотрит пару уроков и решит что язык он знает, можно идти загребать деньги лопатой.
Я бы разделил вопрос на 2 части:
- как писать хороший код на Swift?
- как работает Foundation и UIKit?
На второй вопрос можно получить достаточно много ответов, если не пугаться того же самого ObjC (см. старые публикации на objc.io). Вдобавок тот же самый AppCoda начал недавно серию публикаций по нетривиальным аспектам разработки под iOS.
Если под "чистым кодом" мы понимаем одно и то же, то есть VIP, VIPER, Clean Swift и пр.
В целом согласен, но вопросы лучше задавать более конкретно, чтобы испытуемый понимал что от него хотят. А то от стресса соискатель может в ступор впасть, даже если знания присутствуют.
Не стал об этом писать отдельный комментарий — видимо зря. Абсолютно согласен на счет "даже если знания присутствуют". Все кроме POP — это далеко не уникальные особенности Swift и соискатель может спокойно выехать на своих знаниях из JavaScript, C/C++ и прочих ЯП.
Хотя и для POP более грамотные коллеги наверняка смогут привести аналогии из других ЯП.
В целом конечно хочется, чтобы на Хабре были качественные статьи по Swift (хотя бы уровня objc.io).
Сложный вопрос, насколько глубоко нужно знать Objective-C при современном подходе к iOS разработке. Немного непонятно, почему человек так и не научился кодить и ничего не писал на Swift за 4 года.
Из ObjC нам достались такие легаси как NSObject, NSString, CoreData и @objc. К сожалению, писать на чистом Swift под iOS — это фантастика.
Пример: автогенерация классов для CoreData принуждает работать с NSSet для one-to-many связей. Можно ли использовать при ручном описании классов Set вместо NSSet? Что делать если мы хотим получить ordered set? Какова вычислительная сложность при преобразовании NSSet и Set между собой?
Соглашусь с тем, что использовать NSObject периодически приходится использовать. Но, строго говоря, это всё-таки Foundation, а не ObjC :) objc используется как костыль, а не как непосредственный кодинг на ObjC. С CoreData, безусловно, есть свои особенности. Но работать с CoreData совсем не обязательно.
Это применимо скорее к новичкам. Если человеку не интересно что было до свифта, возможно ему и программировать не интересно. Это НЕ показатель, но имхо один из маркеров. К таким маркерам можно добавить чтение книг к примеру.
а зачем писать на языке в котором breaking changes каждый год?
м… Это какие фундаментальные изменения в языке не позволяют использовать язык?
Breaking changes вынуждают каждый год править уже написанный и отлаженный код. В одной из моей team ради этого за месяц-полтора до релиза стабильной версии xcode выделялись 2-3 девелопера и занимались только этим. Подсчитайте разумность тратить 3-4 человекомесяца каждый год только на миграцию из за купертиновских рукожопов которые не могут язык стабилизировать.
Создавать новый язык — очень сложная задача. Особенно с тем объёмом легаси, который присутствует. Команда разработчиков там очень и очень сильная. Зря Вы так.
Никто собственно говоря не заставлял их изобретать велосипед, могли бы взять любой из существующих уже языков(от Go до C#) и официально 'портировать'.
Если бы МС или Оракл позволяли себе такие breaking changes их бы извиняюсь за выражение с г… ном сожрали, а эпл бои это прощают эплу раз за разом.
Стокгольмский синдром? вот и вы их оправдываете, а меж тем язык ломается каждый год, рефакторинг в IDE не работал до 4 версии, горбатое полуживое IDE у которого отваливается кодокомплит, горбатый debugger который не всегда выводил обьекты (ну к 4 версии вроде научился), баги которые не правятся годами(нет нет да напарываюсь на радары 3-4 летней давности) и тд.
Я понимаю что если формокнопошлепить цветастые морды к API наверное вы не столкнетесь с этим, но уверяю вас как платформа это горящая куча мусора.
Если бы МС или Оракл позволяли себе такие breaking changes их бы извиняюсь за выражение с г… ном сожрали, а эпл бои это прощают эплу раз за разом.
Стокгольмский синдром? вот и вы их оправдываете, а меж тем язык ломается каждый год, рефакторинг в IDE не работал до 4 версии, горбатое полуживое IDE у которого отваливается кодокомплит, горбатый debugger который не всегда выводил обьекты (ну к 4 версии вроде научился), баги которые не правятся годами(нет нет да напарываюсь на радары 3-4 летней давности) и тд.
Я понимаю что если формокнопошлепить цветастые морды к API наверное вы не столкнетесь с этим, но уверяю вас как платформа это горящая куча мусора.
любой из существующих уже языков(от Go до C#) и официально 'портировать'
Портировать языки со сборщиком мусора на мобильные платформы? Получился бы ещё один тормозной андроид.
эпл бои это прощают эплу раз за разом
Эмм, ну как-бы сразу предупреждали, что до определённой версии язык ещё в разработке. Это лучше, чем вставлять костыли, да и ObjC есть — для тех, кому нужна стабильность.
Xcode 4й версии
Кстати уже с тех пор 8 лет прошло — вы что критикуете-то?))
до 4 версии это я про свифт, даже в 8 хкоде еще не работал рефакторинг для свифта — сразу отшибало
да и механизм ARC внедрить тоже, это было бы явно проще чем костылить с нуля язык в котором async await не завезли, и к которому до сих пор выходят статьи / лекции по ускорению компиляции потому что компания автор не осилили написать вменяемый компилятор этого дела.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Ад и израиль что в 2к18 мы должны помогать тупенькому компилятору от никому не известной фирмы с купертино — компилировать код.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Ад и израиль что в 2к18 мы должны помогать тупенькому компилятору от никому не известной фирмы с купертино — компилировать код.
async await с пятой версии завезут. XCode 10 значительно ускорил сборку.
ну то есть к `пятой` версии мы по хорошему получаем функционал 1.0? с рабочим рефактором, вменяемым временем компиляции, обещанием ABI и тд
особенно радует 'продуманность' языка где 8.33% фич включают слово 'remove'
github.com/apple/swift-evolution/tree/master/proposals
github.com/apple/swift-evolution/tree/master/proposals
Что вам мешает просто не писать на Swift? Вас держат в застенках и заставляют кодить под iOS? Подмигните, скиньте адрес — мы вызовем полицию для вас.
ObjC отличный язык, но он избыточный на данный момент. Он существует как очень стабильное легаси и это хорошо.
Кто хочет "новых проблем" тот выбирает для себя Swift.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Половина из скольки? Почему они это делают?
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
Почему Apple не взяли чужой ЯП? По той же самой причине по которой появились процессоры А*, почему появился Metal и все прочее — тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?
Половина из скольки? Почему они это делают?
Половина из примерно сотни девелоперов, делают это для ускорения процесса сборки они провайдят сотни билдов ежедневно, почему они так делают я не в курсе.
тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?
у вас сбитая логическая база, в мире эпл мы УЖЕ как раз и имеем такую же огороженность как во времена раннего IE.
Спасибо за ссылку на Uber — узнал много чего вредного.
Да там же не только убер но и другие компании делают то же самое) выглядит в общем то крайне убого, но все терпят. Я таким последний раз занимался в конце 90х когда маргинальный диалект паскаля(вроде ТМТ) не мог скомпилить сложную формулу пришлось разбить на несколько частей.
Вот именно тот доклад убера www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers — радуют еще их сказки про 99.99% креш фри после переписывания на свифт, откуда такие сказки если креш/ассерт можно словить просто просто в глубинах фаундейшна не зависимо от языка, как на одной иос бетке я ловил креш потому что internal iOS логгер процессил мои объекты для своих каких то внутренних целей (видимо сбор статистики), и крешился на этом.
Если же свифт помог им добиться такого креш-фри то это было просто сборище смуззихлёбов не умеющих в обжект с его nil безопасной семантикой.
Вот именно тот доклад убера www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers — радуют еще их сказки про 99.99% креш фри после переписывания на свифт, откуда такие сказки если креш/ассерт можно словить просто просто в глубинах фаундейшна не зависимо от языка, как на одной иос бетке я ловил креш потому что internal iOS логгер процессил мои объекты для своих каких то внутренних целей (видимо сбор статистики), и крешился на этом.
Если же свифт помог им добиться такого креш-фри то это было просто сборище смуззихлёбов не умеющих в обжект с его nil безопасной семантикой.
Неожиданный nil — это плохо проработанный код. разрешённый по умолчанию полностью безотказный nil в objc — это явная недоработка старого языка. Это что-то из серии бага, возведённого в фичу. Работающий и необработанный nil — unexpected behaviour.
полностью безотказный nil в objc — это явная недоработка старого языка
это в общем то специально сделанная фича если изучить рантайм который заботливо выделяет именно столько места на стеке сколько ожидается от выражения например
someStruct zero = [nil structValue];
Работающий и необработанный nil — unexpected behaviour.
да я понял что вы любите крашится и писать guard let'ы обильно и много
Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
непонятно почему вообще компилятор настолько убогий, я не видел подобных решений для java или c#, косвенно это также говорит о качестве компилятора и его разработчиках.
Костыли и подпорки потому что маленькая никому не известная купертиновская компания не может разработать вменяемые инструменты разработки.
ну то есть к пятой версии мы по хорошему получаем функционал 1.0Из вики:
Swift: first appeared in 2014
Go: first appeared in 2009
Go как-бы пилят уже в два раза дольше, в 2013 о нём вообще мало кто слышал. Вы хотите, чтобы в Swift было всё и сразу? Кстати проблемы со временем компиляции до сих пор не преодолели даже в таком молодом и малоизвестном языке, как C++.
я не видел подобных решений для java или c#
Да, давайте теперь ещё сравним компиляцию в нейтив-код и компиляцию в байт-код.
Эм так дело собственно говоря в том что фронт компилятор свифта компилит именно в 'байт код' llvm'а ;) который является беком и компилит уже в нативный код.
По поводу Go, а не подскажите сколько там было breaking changes?
Может сравним размер и капитализацию компаний разработчиков?
Или может сравним число девелоперов в командах?
Или вы просто уклонитесь от этих неудобных вопросов и будете дальше фанбоить по эплу?:)
Ну и попробуйте найти статьи(от крупных компаний) по ускорению времени компиляции в плюсах(да черт возьми, даю вам фору — на вообще ЛЮБОМ языке кроме свифта) связанные тупо с симплификацией обычного кода(не с темплейтами).
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
По поводу Go, а не подскажите сколько там было breaking changes?
Может сравним размер и капитализацию компаний разработчиков?
Или может сравним число девелоперов в командах?
Или вы просто уклонитесь от этих неудобных вопросов и будете дальше фанбоить по эплу?:)
Ну и попробуйте найти статьи(от крупных компаний) по ускорению времени компиляции в плюсах(да черт возьми, даю вам фору — на вообще ЛЮБОМ языке кроме свифта) связанные тупо с симплификацией обычного кода(не с темплейтами).
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем? Ну это так, вопрос на общую адекватность.
а не подскажите сколько там было breaking changes
Не подскажу. До первой версии явно были.
сравним размер и капитализацию компаний разработчиков
Дело не в капитализации, а выделенном бюджете. У вас есть такие данные? Да и задачи там стояли разные: что-то Google даже не попытался вписать Go в инфраструктуру Android, просто разработал очередной язык в вакууме даже без UI библиотек.
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
толпы фанбоев без бекграунда — пытаются разрабатывать софт
Все так начинали.
ух сколько жира:
интересно а вы представляете? и как вы думаете во что интересно сложнее компилить если имеется такой замечательный инструмет как GraalVM ;)
ДО первой версии, не так ли? не между КАЖДОЙ, не так ли?
не будет, но для меня будет новостью если вы найдете статьи по ускорению компиляции плюсов симплифицированием кода. Да бог с ними с плюсами — на ЛЮБОМ другом языке кроме свифта. Сможете же? Или проигнорите во второй раз?
нормальные начинания начинались в академической среде а не среди смуззихлебов которые написать компилятор пятый год не могут.
Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем?
интересно а вы представляете? и как вы думаете во что интересно сложнее компилить если имеется такой замечательный инструмет как GraalVM ;)
Не подскажу. До первой версии явно были.
ДО первой версии, не так ли? не между КАЖДОЙ, не так ли?
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
не будет, но для меня будет новостью если вы найдете статьи по ускорению компиляции плюсов симплифицированием кода. Да бог с ними с плюсами — на ЛЮБОМ другом языке кроме свифта. Сможете же? Или проигнорите во второй раз?
Все так начинали.
нормальные начинания начинались в академической среде а не среди смуззихлебов которые написать компилятор пятый год не могут.
Проблемы «симплификации» как ее тут назвали преувеличены. Во-первых, сами разработчики придумывают себе проблемы и потом героически их решают и рассказывают на конференциях. Да, были некоторые реальные проблемы со скоростью раньше, но даже они касались скорее вырожденных случаев. Нам, например, хватает писать типы в некоторых местах (что бы компайлер не пытался резолвить их а уже точно знал) и разбивать огромное спагетти из optional chaining (в мире свифта это способ развернуть обьект который может быть nil)
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.
Проблемы «симплификации» как ее тут назвали преувеличены.
'проблема' в том что это вообще существует, все эти статьи и доклады по настройками компилятора (sic) и тому как смержить все файлы в кучу чтобы немощный компилятор быстрее проанализировал один большой файл чем кучку маленьких.
дальше — никаких проблем.
у ВАС не было, у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проект, а потом кому то приходится засучив рукава работать после таких 'работников'.
К следующей версии сделают ABI к тому же.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышу ;) вот от вас снова услышал — посмеялся и то хорошо
у C++ например вообще по годам выпуска версии
да и там точно такие же ломки апи? ;)
ABI Stability в Swift 5 — это заявленая фича github.com/apple/swift-evolution#development-major-version--swift-50
'проблема' в том что это вообще существуетТолько в тех статьях, а не в реальной жизни. Написать долго компилирующийся код можно на чем угодно ведь. Тот же Kotlin часто ставили в сравнение к Свифту, только вот на андроиде он сейчас хуже Свифта первых версий в плане скорости компиляции. А сливать все в один файл — ну так и в других языках можно, что бы линковщику облегчать работу, тоже станет быстро компайлится. А вообще все их проблемы только потому что надо раз в 2 минуты компилировать и запускать проект, потому что… а черт их знает почему они так делают. И это печально, конечно.
у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проектБыла такая же проблема, в подах чего только не было, когда увидели — были в шоке, за месяц подчистили и перевели. Но давайте будем честными, проблема тут изначально не в том что поменяли что-то в новой версии языка (потому что так же само могло все повалиться с новой SDK, будь у Вас Obj-C проект), а в том что накидали pods без разбору и с этим приходится жить.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышуЯ не слухи рассказываю все же, а что происходит в swift-evolution. Они за все время ни разу не обещали что вот прям в следующей версии все будет идеально, они определяли приоритеты и реализовывали, у них с этим все довольно строго. И изначально сказали когда речь пошла про ABI что они два года будут это делать, чем, собственно, и занимаются. Для них это тоже довольно важная вещь и не только потому что ченджи ломают все. Сейчас уже, кстати, можно в 4-м Свифте 3.2 использовать.
да и там точно такие же ломки апи? ;Я это упомянул не в плане изменений в С++ (за коим уже давно не слежу и статьи здесь на хабре про новшества нового стандарта честно говоря выглядят жутко в плане кол-ва изменений и нововведений), а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
так и я про это же, представьте какой бы вой был бы если бы оракл или мс опубликовали язык такой же степени сырости, с… вном их бы мешали все кому не лень. А в мире эплфанбоев это жрут и добавки просят. И заботливо мостырят скриптиками костыли и подпорочки чтобы этот треш хоть как то работал.
дело ж не только в компиляции тормозной (хотя и в ней тоже), дело в убогой бажной иде, дебаггере, плейграунде, в общем такое ощущение что им абсолютно начихать на своих девелоперов, все равно утрутся и дальше будуто хлебать.
Ну Xcode был не подарком и до выхода Swift. А по поводу того что Swift выкатили недоделанным и это ужасно, а все радуются все же не соглашусь. Они его показали всем и сказали, хотите — пишите на Swift. Не хотите — не пишите. И стали дорабатывать его по отзывам комьюнити, что, на мой взгляд, весьма разумное решение. Сейчас можно увидеть цели и идеи команды разработчиков и внести свои предложения на обсуждение. Имхо, это гораздо лучше, чем получить сферического коня в вакууме.
Под Swift есть несколько книг и статей от Apple + целая гора материалов по отдельным библиотекам на сайте Apple для разработчиков. По андроиду приходится искать сторонние книги и туториалы и надеяться, что автор разобрался в теме.
Чтобы отвечать на простые вопросы о свифте достаточно за пару часов пролистать официальную книгу и ты готов.
Парадокс в том, что это действительно так. Но, во-первых, это почему-то никто не делает. Во-вторых, это только самые простые вопросы на собеседовании, есть и более сложные.
Quolyk Где найти такую книгу? И как она называется?
Но данный язык отстал от современных методов разработки, Apple его не развивает, а также он отличается наличием большого количества устаревших правил, таких как отсылка сообщений nil-объектам и динамическая система типов.
Уважаемый, жгите еще про отсталость динамической системы типов и безопасность встроенного nil.
Жду аргументов в плюс подобного подхода:)
про динамизм — протокол ориентированное программирование на нем же и основанно)
а вообще кордата и kvo работает за счет isa swizzling, динамизм скорее благо чем зло.
а про нил безопастность по вашему надо крешиться? или как в свифте лепить guard let в рядок?
а вообще кордата и kvo работает за счет isa swizzling, динамизм скорее благо чем зло.
а про нил безопастность по вашему надо крешиться? или как в свифте лепить guard let в рядок?
Жду аргументов в минус подобного подхода:)
У вас в коде две проверки на выход за границу массива и обе с ошибкой.
Это вы в какой стране собеседовали? iOS вакансия только в Болгарии видна.
Интересный пример того, о чем можно поговорить при собеседовании на знание Swift (без учета Foundation и UIKit): developer.apple.com/videos/play/wwdc2018/223
Добрый день, ребята.
Я не программист, но увлекаюсь разработкой под андроид. Вот вопросы же элементарные. Я не знаю swift, но на все вопросы можно ответить, просто зная парадигму любого языка. Интерфейсы просто с другим названием, ну или передача по ссылке и по значению, ну вот везде это описано. В любой книге, по любому языку программирования, только с небольшими отличиями. Вот что это за кандидаты, что лажают в таких местах и на собеседованиях в такую крупную компанию. Ладно там резюме в интернете скачал, но у вас же должны быть HR со списком готовых вопросов/ответов, которые просто должны отсеять эту аудиторию по телефону. Просто представляю, сидит тимлид, работающий команде разработки под iOS, и к нему на собеседование приходит ЭТО.
Я не программист, но увлекаюсь разработкой под андроид. Вот вопросы же элементарные. Я не знаю swift, но на все вопросы можно ответить, просто зная парадигму любого языка. Интерфейсы просто с другим названием, ну или передача по ссылке и по значению, ну вот везде это описано. В любой книге, по любому языку программирования, только с небольшими отличиями. Вот что это за кандидаты, что лажают в таких местах и на собеседованиях в такую крупную компанию. Ладно там резюме в интернете скачал, но у вас же должны быть HR со списком готовых вопросов/ответов, которые просто должны отсеять эту аудиторию по телефону. Просто представляю, сидит тимлид, работающий команде разработки под iOS, и к нему на собеседование приходит ЭТО.
Объясните, пожалуйста, связь между
Имелось в виду то, что self сильно держит замыкание, и для избежания retain cycle внутри замыкания self держится слабо?
На деле замыкание — это reference typeи
отсюда появляются известные конструкции [weak self] in
Имелось в виду то, что self сильно держит замыкание, и для избежания retain cycle внутри замыкания self держится слабо?
"Строго говоря, в случае с value type работает принцип copy-on-write." — Не совсем так, механизм copy-on-write применен только для определенных типов Swift Standard library, для которых копирование при присвоении может вызвать проблемы с производительностью. Если Вы создаете свою структуру вам придется самому реализовывать эту механику(https://stackoverflow.com/questions/45253202/which-value-types-in-swift-supports-copy-on-write). В своей практике уже несколько раз сталкивался с тем, что люди пишут на Swift, не используя главные фичи языка(например расширения протоколов), хотя вроде сейчас много материалов на эту тему.
Они в принципе ничего не учат но зато фанбоят.
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
Опыт проведения собеседований с использованием Playground показался интересным. Вроде бы как и теорию спрашиваете, и при этом ставите разработчика в более привычные для него условия — у ноутбука. Идея с более подробными постами — лайк!
Что тут интересного? Playground все еще не стабильнен. Не знаю как будет в следующей версии, но сейчас даже когда надо быстро набросать, например, что бы проверить код для рисования какой либо картинки в контексте. Playground будет зависать каждую вторую сборку и придеться ребутить весь xCode чтобы все собралось. Так что лучше уж на бумашке код писать, тем более это полезнее
Конечно, Вы правы. Однако, на собеседовании, как правило, не просят написать что-то серьезное. За код на бумажке некоторые могут и обидиться.
Расскажите, почему вы считаете, что код на бумажке писать полезно?
Расскажите, почему вы считаете, что код на бумажке писать полезно?
Когда человек пишет на бумаге у него нет таких прелестей IDE как auto-complite и прочего. Приходится знать что ты пишешь. Даже если человек переходит на псевдокод, ему все равно необходимо хорошенько поразмыслить прежде чем что либо писать. Все это показывает какой то скил, что несомненно полезно при приеме. Понимаю, что многим это будет неприятно да и мне тоже было весьма не удобно, когда это просили. Но куда деваться? Надо же узнать о навыках кандидата. Посмотрите статью о разрабе который писал весь код на бумажке, уверен, что для него такая практика была полезна, хоть и необходима
То есть, при написании кода в IDE человек не мыслит? Это что из серии: пользуйтесь пером, а не шариковыми ручками, ведь так поступали наши деды. Можно и на перфокартах код писать с запуском куда раз в сутки, как это было в советских НИИ, но зачем. Писанина на бумаге проверяет весьма сомнительные скилы.
Код на бумажке, особенно часто это бывает ObjC, выглядит слишком непонятно: отсутствие подсветки, сплошная какофония из ObjC-style синтаксиса [[SomeClass alloc] initWithParamAndParam]; в распечатанном (или, ещё хуже, написанном от руки) виде введёт кого угодно в ступор. К тому же код на бумажке нигде никогда не используется, очень странно это использовать как тест.
наконец то хоть один практик в треде) и о боже мой он говорит ересь, что хкод глючит и виснет — как же так сжечь еретика и выпить еще смуззи во славу Кука
Спасибо, что поддержали. Надо будет продолжить.
Playground – классно! Если б он еще не вис, вообще отлично!
Добрый день!
А можете прокомментировать результаты по заданию с падающим приложением?
Первый пул-реквестер просто удалил требование наследоваться от UITableViewCell. На мой взгляд, можно было решить задачу лучше.
Немного поискав, я нашел, что проблема относится к багу в компиляторе Swift, и самое оптимальное решение — указать директиву наследования от class или AnyObject.
Данное решение оставляет требование наследоваться от UITableViewCell и решает вопрос падения приложения, единственная проблема — появляется warning, который тоже является багом компилятора, который должны будут исправить в будущем.
Ну и чтобы два раза не вставать, подскажите, кандидатов не писавших на Objective C, но понимающих код, и пишуших на Swift вы рассматриваете? Если да, то по поводу трудоустройства вам куда лучше писать, откликаться на hh.ru?
Sign up to leave a comment.
Новичок или опытный? Как нанять мобильного разработчика под iOS, который что-то действительно умеет