Начнем с того, что буквально два года назад мобильная разработка под iOS приобрела свой неповторимый вкус, и это связано с появлением такого языка как Swift. Новый и современный язык с хорошей парадигмой, а также с очень сильной командой разработчиков сразу был оценен наиболее инициативными разработчиками. Но главный его плюс заключается в том, что именно на Swift будет делать ставку Apple, и это подтверждают утверждения Тима Кука, сделанные им публично. Поэтому проводить собеседование с учетом специфики знания Swift кажется логичным шагом.
Тем не менее, далеко не во всех компаниях вообще задают вопросы про Swift на собеседованиях. До прихода в Acronis я сам проходил собеседования в разных компаниях, и про Swift не спрашивал практически никто. Мне это показалось очень странным, так как, очевидно, мобильная разработка движется именно в этом направлении.
Возможно, проблема в том, что многие разработчики прошлого поколения «сидят» на Objective-C и не хотят уходить от знакомых парадигм. Но данный язык отстал от современных методов разработки, Apple его не развивает, а также он отличается наличием большого количества устаревших правил, таких как отсылка сообщений nil-объектам и динамическая система типов. Их сложно учитывать при написании кода и во время отладки. С переходом на Swift можно было бы избежать многих сложностей.
Несколько слов о Swift
Apple представила этот язык в 2014 году, как противовес Objective-C. У новичка обнаружилось сразу несколько плюсов. Например, Swift не требует наличия двух файлов, отлично реализована безопасность языка, уникальная работа с дженериками, проработанная модель типов данных и method dispatch. Этот язык можно смело назвать более читаемым за счет упрощенного и удобного синтаксиса.
В процессе разработки на Swift очень помогает наличие специальной среды для экспериментов под названием Playground, о пользе которой на собеседованиях мы расскажем чуть ниже.
Наконец, новый язык перспективен потому, что скорость разработки значительно выше, чем на Objective-C и C++. Он позволяет проще устранять баги и, вообще, разработка на Swift оказывается дешевле, эффективнее и перспективнее, чем на Objective-C. Поэтому сознательно ищем специалистов, которые имеют опыт «общения» на этом языке.
Разработчики и имитаторы
Конечно, можно нанять на работу выпускника вуза или даже стажера, обучив его в процессе прохождения практики. Но если вы ищете уже имеющего опыт специалиста, очень странным выглядит несоответствие заявленного опыта и реальных знаний. Например, соискатель утверждает, что «разрабатывал на Swift три года», и при этом не знает основ языка. Наверное, это объясняется желанием получить высокооплачиваемую работу, ведь сегодня спрос на разработчиков под iOS достаточно высок. Чтобы отсеять таких кандидатов мы проводим специально продуманные интервью, на которых уже попадались «специалисты», которые:
- пишут код в точности по видео-примерам с YouTube;
- копируют код с GitHub вообще без изменений;
- пишут другу в Telegram и спрашивают, как решить элементарную задачу;
- «выходят в туалет» или «срочно позвонить» после того, как объявлены условия задачи.
Факт недостаточной компетенции можно обнаружить, если использовать написание кода непосредственно во время интервью. В разных компаниях принято задавать вопросы с записями на доске, на листочке, на обрубке бумаге, или просто на слух. Но ведь в конечном счете разработчик пишет код на компьютере, и почему бы не посмотреть, как он выполняет свои непосредственные задачи вживую?
Например, наш специалист берет ноутбук и предлагает соискателю начать творить в Playground — в той самой специальной среде языка Swift. В Playground можно просто запустить код «как есть» и посмотреть на результаты его работы. Это удобно, и экономит время (ведь на техническое интервью выделяется максимум часа 2). Тогда как на С++ нужно создать проект, куда-то его сохранить, настроить, Playground позволяет исполнить код без дополнительных заморочек. Поэтому Playground прекрасно зарекомендовал себя как инструмент для собеседования, по крайней мере в Acronis.
Пять кругов…собеседования
Чтобы выяснить, может ли соискатель приступить к работе сразу после собеседования, мы задаем следующие пять практических вопросов:
1. Различия между reference type и value type
Мобильные разработчики под iOS прекрасно знают, что в языке есть разные типы переменных. Они делятся на два основных вида. А именно, одни передаются по ссылке — reference type (ссылочный тип), а другие — по значению — value type (тип значений). На интервью мы спрашиваем, в чем разница между (struct) структурой и (class) классом. Структура является value type, а класс — reference type. Увы, на такой вопрос отвечают далеко не все, а некоторая часть кандидатов даже интересуется, «почему такой странный вопрос в самом начале?». Но если задуматься, вопрос-то совсем не странный, особенно если вы планируете разрабатывать на Swift.
Экземпляры reference type при инициализации и присвоении начинают ссылаться на одну и ту же область в памяти и, как следствие, делят одно и то же значение между собой, а в случае с value type происходит копирование данных, и объекты начинают ссылаться на разные области памяти, и значения между собой они не делят. Строго говоря, в случае с value type работает принцип copy-on-write. То есть, до момента попытки изменения значения экземпляры value type будут ссылаться на один и тот же адрес, а при первом же изменении произойдёт копирование. Очевидно, что понимание этого необходимо разработчику. Код может вести себя абсолютно различно для классов и структур. Но просто знать отличия — мало. Второй уровень осознанности — разница в написании кода. Оказывается, что написать в Playground и продемонстрировать отличия в работе с reference type и value type не так-то просто, если вы не имели опыта программирования в Swift. У нас только 1 из 3 кандидатов проходит этот тест.
Для любопытствующих, различия хорошо были показаны на конференции WWDC, а также подробно рассмотрены в документации и блоге.
2. Что такое Protocol Oriented Programming?
В программировании невозможно обойтись без интерфейсов. Apple в своих языках использует термин protocol. Протоколы позволяют решить проблему множественного наследования. Protocol Oriented Programming Apple представила общественности несколько лет назад на конференции WWDC вместе со Swift, сделав упор на их важности для языка. Например, важным показателем для использования протоколов является тот факт, что в языке нет protected уровень доступа к полям.
Подразумевается, что полиморфизм должен достигаться с использованием протоколов, а не наследования. И хотя на самом деле Protocol Oriented Programming — это скорее маркетинг, в ответе на такой вопрос мы ждем, что программист начнет рассказывать об особенностях протоколов и сможет создать протокол в Playground. В сущности, чтобы описать протокол нужно три строчки. Увы, в мобильной разработке люди часто не понимают назначения протоколов, и не могут даже этого. А мы ждем чего-то простого, например:
protocol Developer {
func readManual()
var name: String { get }
}К тому же бывают обычные протоколы, а бывают generic-протоколы, которые работают с ассоциативными типами (Associated Type). И, по сути, являются близкими к шаблонам (templates) в C++. Generic-протоколы представляют собой абстрактные и специфичные вещи, которые очень редко применяются в обычном программировании. Они нужны для написания внутренних библиотек (и именно для этого используется самой Apple) или библиотек, где нужно использовать высокую степень абстракции. Хорошо если соискатель знает и об этом. Раз ссылка и два.
3. Работа с памятью
В iOS своя система работы с памятью, в которой используется подсчёт ссылок. Есть два подхода в Swift. Это ручной подсчёт ссылок (Manual Reference Counting, MRC) и автоматический подсчёт ссылок (Automatic Reference Counting, ARC). Manual Reference Counting используется при прямой работе с памятью, но обычно всё же используется ARC. В частности, разработчику важно понимать, чем отличаются сильные ссылки (strong) от слабых (weak). Это важный момент для тех языков, где нет сборщика мусора (Garbage Collector). Вот интересное письмо на тему, почему в Swift не используется Garbage Collector.
На самом деле тут все не так сложно — нужно рассказать про счетчик ссылок, о том, что объект удаляется, когда значение счетчика достигает 0 (нуля), и так далее. Но нам опять же нужно, чтобы человек показал пример в Playground. И тут у части соискателей возникает ступор. Даже если пара фраз о сильных и слабых ссылках была успешно выучена, на данном этапе становится очевидно, если у человека не было нормальной практики кодинга на Swift.
// Инициализировать
var slimer: Ghost? = Ghost(name: "Slimer")
// Создать слабую ссылку, не увеличивая счётчик
weak var weakSlimer = slimer
// Создать сильную ссылку, увеличивая счётчик
let strongSlimer = slimer
// Уменьшить счётчик ссылок
slimer = nil4. Работа с замыканиями
В Java, С++ есть лямбды, в Objective-C есть блоки, во многих языках есть свои конструкции, соответствующие понятию замыканий (closure) в Swift. Но соискатели часто не могут объяснить, как обращаться с замыканием, ведь для этого нужно понимать, как работать с памятью и системой взаимосвязей внутренних и внешних переменных. А значит — нужно хорошо знать стандартные форматы данных, управление памятью и прочие связанные моменты. Если создать замыкание в коде не представляет для соискателя особой сложности:
let completionHanlder: () -> Void = {
print("Success")
}То, например, сказать, каким типом — value или reference — является замыкание, уже достаточно сложная задача. На деле замыкание — это reference type. И именно отсюда появляются известные конструкции [weak self] in.
let completionHanlder: () -> Void = { [weak self] in
self?.close()
}Чтобы проверить умения соискателей, мы заготовили шаблон в Playground. Ниже вы можете видеть массив, который изменяется по-разному в двух потоках. И нужно ответить, какой эффект это создаст в приложении. Понимание процесса в данном случае отражает умение работать с переменными и передавать их между разными объектами.
//: Playground — noun: a place where people can play
import Foundation
import PlaygroundSupport
let queue = DispatchQueue.global()
var employees = ["Bill", "Bob", "Joe"]
queue.async {
let count = employees.count
for index in 0 ..< count {
print("\(employees[index])")
Thread.sleep(forTimeInterval: 1)
}
}
queue.async {
Thread.sleep(forTimeInterval: 0.5)
print("remove")
employees.remove(at: 0)
}
PlaygroundPage.current.needsIndefiniteExecution = trueПример взят отсюда.
5. Написать простое приложение
Любой разработчик должен уметь запустить проект. Мы даем для этого простую задачу — разработать приложение под iOS, которое просто показывает сайт Acronis. Для программиста, который действительно что-то делал на Swift, такая задача потребует 10-15 минут, которые в основном уходят на выставление настроек и проверку.
Если этот этап пройден, происходит усложнение задачи, как обычно это бывает в жизни: «приходит product-manager, который меняет условия и срочно требует доработки». Ведь именно так строится ежедневная практика любого программиста. Интересно посмотреть, как человек меняет код согласно новым условиям. В нашем простом тестовом задании мы проходим несколько итераций, например:
- Добавить навигацию в приложении
- Сделать выбор между несколькими сайтам
- Добавить архитектуру
- Написать более абстрактно
Наблюдая за такой работой в интерактивном режиме, можно узнать, как человек пользуется документацией, GitHub и другими ресурсами.
Безусловно, это далеко не все вопросы, которые задаются на собеседовании, но наши кандидаты должны справиться, в первую очередь, с решением этих базовых задач.
Заключение
Интерактивное собеседование позволяет увидеть реальное поведение разработчика, включая его soft-skills и умение общаться с менеджерами. И далеко не все специалисты, которые приходят к нам, проходят даже часть испытаний.
Мы открыты к сотрудничеству и ждем в нашу команду талантливых разработчиков.
Если вы хотите работать в мобильной разработке Acronis, рекомендую вам попрактиковаться с программированием на Swift.
А мы, тем временем, подготовим серию постов о своем опыте работы с этим языком программирования.
Подписывайтесь на наш блог, чтобы ничего не пропустить.
Конкурс
Приложение, исходники которого хранятся на Github, падает при запуске.
Задача: необходимо создать pull request с исправлением причины падения.
Первый, кто сделает этот запрос с исправлением ошибки, получит приз — Power Bank и годовую лицензию Acronis True Image 2018 с 1 Тб облачного хранилища.
Комментарии (83)
iStaZzzz
29.06.2018 14:21Проблема на мой взгляд в изоляции системы. При разработке под андроид всегда можно найти фундаментальные основы на java. Под iOS же учатся кодить по youtube.
В текущей ситуации можно разве что спрашивать еще и по Objective-C. Если новичок потратил время на немодный, но лежащий в основе, язык, то скорее всего он чуть больше чем формошлепер.smanioso
29.06.2018 14:23Изоляции как таковой нет:
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).iStaZzzz
29.06.2018 14:32По факту Swift используется на одной платформе, хоть возможности и позволяют использовать не только под iOS (macOS).
Под изоляцией я имею ввиду скорее скудность учебного материала. Есть ряд простых задач (отправить запрос на сервер, сохранить в базу, отобразить), есть уроки как это сделать. Пояснений как работают запросы/БД/UI нет. Нет банды четырех или чистого когда на Swift. Соответственно новичок посмотрит пару уроков и решит что язык он знает, можно идти загребать деньги лопатой.smanioso
29.06.2018 14:41Я бы разделил вопрос на 2 части:
- как писать хороший код на Swift?
- как работает Foundation и UIKit?
На второй вопрос можно получить достаточно много ответов, если не пугаться того же самого ObjC (см. старые публикации на objc.io). Вдобавок тот же самый AppCoda начал недавно серию публикаций по нетривиальным аспектам разработки под iOS.
Если под "чистым кодом" мы понимаем одно и то же, то есть VIP, VIPER, Clean Swift и пр.iStaZzzz
29.06.2018 14:50В целом согласен, но вопросы лучше задавать более конкретно, чтобы испытуемый понимал что от него хотят. А то от стресса соискатель может в ступор впасть, даже если знания присутствуют.
smanioso
29.06.2018 14:55Не стал об этом писать отдельный комментарий — видимо зря. Абсолютно согласен на счет "даже если знания присутствуют". Все кроме POP — это далеко не уникальные особенности Swift и соискатель может спокойно выехать на своих знаниях из JavaScript, C/C++ и прочих ЯП.
Хотя и для POP более грамотные коллеги наверняка смогут привести аналогии из других ЯП.
В целом конечно хочется, чтобы на Хабре были качественные статьи по Swift (хотя бы уровня objc.io).
VyacheslavAcronis Автор
29.06.2018 14:26Сложный вопрос, насколько глубоко нужно знать Objective-C при современном подходе к iOS разработке. Немного непонятно, почему человек так и не научился кодить и ничего не писал на Swift за 4 года.
smanioso
29.06.2018 14:35Из ObjC нам достались такие легаси как
NSObject,NSString,CoreDataи@objc. К сожалению, писать на чистом Swift под iOS — это фантастика.
Пример: автогенерация классов для CoreData принуждает работать сNSSetдля one-to-many связей. Можно ли использовать при ручном описании классовSetвместоNSSet? Что делать если мы хотим получить ordered set? Какова вычислительная сложность при преобразованииNSSetиSetмежду собой?VyacheslavAcronis Автор
29.06.2018 14:42Соглашусь с тем, что использовать NSObject периодически приходится использовать. Но, строго говоря, это всё-таки Foundation, а не ObjC :) objc используется как костыль, а не как непосредственный кодинг на ObjC. С CoreData, безусловно, есть свои особенности. Но работать с CoreData совсем не обязательно.
iStaZzzz
29.06.2018 14:36Это применимо скорее к новичкам. Если человеку не интересно что было до свифта, возможно ему и программировать не интересно. Это НЕ показатель, но имхо один из маркеров. К таким маркерам можно добавить чтение книг к примеру.
edbuwg
29.06.2018 14:42а зачем писать на языке в котором breaking changes каждый год?
VyacheslavAcronis Автор
29.06.2018 15:40м… Это какие фундаментальные изменения в языке не позволяют использовать язык?
edbuwg
29.06.2018 15:51Breaking changes вынуждают каждый год править уже написанный и отлаженный код. В одной из моей team ради этого за месяц-полтора до релиза стабильной версии xcode выделялись 2-3 девелопера и занимались только этим. Подсчитайте разумность тратить 3-4 человекомесяца каждый год только на миграцию из за купертиновских рукожопов которые не могут язык стабилизировать.
VyacheslavAcronis Автор
29.06.2018 16:01Создавать новый язык — очень сложная задача. Особенно с тем объёмом легаси, который присутствует. Команда разработчиков там очень и очень сильная. Зря Вы так.
edbuwg
29.06.2018 16:18Никто собственно говоря не заставлял их изобретать велосипед, могли бы взять любой из существующих уже языков(от Go до C#) и официально 'портировать'.
Если бы МС или Оракл позволяли себе такие breaking changes их бы извиняюсь за выражение с г… ном сожрали, а эпл бои это прощают эплу раз за разом.
Стокгольмский синдром? вот и вы их оправдываете, а меж тем язык ломается каждый год, рефакторинг в IDE не работал до 4 версии, горбатое полуживое IDE у которого отваливается кодокомплит, горбатый debugger который не всегда выводил обьекты (ну к 4 версии вроде научился), баги которые не правятся годами(нет нет да напарываюсь на радары 3-4 летней давности) и тд.
Я понимаю что если формокнопошлепить цветастые морды к API наверное вы не столкнетесь с этим, но уверяю вас как платформа это горящая куча мусора.yarric
29.06.2018 17:22любой из существующих уже языков(от Go до C#) и официально 'портировать'
Портировать языки со сборщиком мусора на мобильные платформы? Получился бы ещё один тормозной андроид.
эпл бои это прощают эплу раз за разом
Эмм, ну как-бы сразу предупреждали, что до определённой версии язык ещё в разработке. Это лучше, чем вставлять костыли, да и ObjC есть — для тех, кому нужна стабильность.
Xcode 4й версии
Кстати уже с тех пор 8 лет прошло — вы что критикуете-то?))
edbuwg
29.06.2018 17:26до 4 версии это я про свифт, даже в 8 хкоде еще не работал рефакторинг для свифта — сразу отшибало
edbuwg
29.06.2018 17:38да и механизм ARC внедрить тоже, это было бы явно проще чем костылить с нуля язык в котором async await не завезли, и к которому до сих пор выходят статьи / лекции по ускорению компиляции потому что компания автор не осилили написать вменяемый компилятор этого дела.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Ад и израиль что в 2к18 мы должны помогать тупенькому компилятору от никому не известной фирмы с купертино — компилировать код.VyacheslavAcronis Автор
29.06.2018 17:41async await с пятой версии завезут. XCode 10 значительно ускорил сборку.
edbuwg
29.06.2018 17:58ну то есть к `пятой` версии мы по хорошему получаем функционал 1.0? с рабочим рефактором, вменяемым временем компиляции, обещанием ABI и тд
edbuwg
29.06.2018 18:03особенно радует 'продуманность' языка где 8.33% фич включают слово 'remove'
github.com/apple/swift-evolution/tree/master/proposalssmanioso
29.06.2018 18:19Что вам мешает просто не писать на Swift? Вас держат в застенках и заставляют кодить под iOS? Подмигните, скиньте адрес — мы вызовем полицию для вас.
ObjC отличный язык, но он избыточный на данный момент. Он существует как очень стабильное легаси и это хорошо.
Кто хочет "новых проблем" тот выбирает для себя Swift.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Половина из скольки? Почему они это делают?
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
Почему Apple не взяли чужой ЯП? По той же самой причине по которой появились процессоры А*, почему появился Metal и все прочее — тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?edbuwg
29.06.2018 19:19+1Половина из скольки? Почему они это делают?
Половина из примерно сотни девелоперов, делают это для ускорения процесса сборки они провайдят сотни билдов ежедневно, почему они так делают я не в курсе.
тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?
у вас сбитая логическая база, в мире эпл мы УЖЕ как раз и имеем такую же огороженность как во времена раннего IE.smanioso
29.06.2018 23:50Спасибо за ссылку на Uber — узнал много чего вредного.
edbuwg
30.06.2018 09:22Да там же не только убер но и другие компании делают то же самое) выглядит в общем то крайне убого, но все терпят. Я таким последний раз занимался в конце 90х когда маргинальный диалект паскаля(вроде ТМТ) не мог скомпилить сложную формулу пришлось разбить на несколько частей.
Вот именно тот доклад убера www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers — радуют еще их сказки про 99.99% креш фри после переписывания на свифт, откуда такие сказки если креш/ассерт можно словить просто просто в глубинах фаундейшна не зависимо от языка, как на одной иос бетке я ловил креш потому что internal iOS логгер процессил мои объекты для своих каких то внутренних целей (видимо сбор статистики), и крешился на этом.
Если же свифт помог им добиться такого креш-фри то это было просто сборище смуззихлёбов не умеющих в обжект с его nil безопасной семантикой.VyacheslavAcronis Автор
30.06.2018 15:56Неожиданный nil — это плохо проработанный код. разрешённый по умолчанию полностью безотказный nil в objc — это явная недоработка старого языка. Это что-то из серии бага, возведённого в фичу. Работающий и необработанный nil — unexpected behaviour.
edbuwg
30.06.2018 21:57полностью безотказный nil в objc — это явная недоработка старого языка
это в общем то специально сделанная фича если изучить рантайм который заботливо выделяет именно столько места на стеке сколько ожидается от выражения например
someStruct zero = [nil structValue];
Работающий и необработанный nil — unexpected behaviour.
да я понял что вы любите крашится и писать guard let'ы обильно и многоVyacheslavAcronis Автор
01.07.2018 11:26Nil так или иначе все равно надо обрабатывать. Синтаксис swift позволяет это делать на раз. Во многих других языках нужно постоянно морочиться на этот счёт.
edbuwg
29.06.2018 19:33Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
непонятно почему вообще компилятор настолько убогий, я не видел подобных решений для java или c#, косвенно это также говорит о качестве компилятора и его разработчиках.
Костыли и подпорки потому что маленькая никому не известная купертиновская компания не может разработать вменяемые инструменты разработки.
yarric
29.06.2018 20:25ну то есть к
пятойверсии мы по хорошему получаем функционал 1.0Из вики:
Swift: first appeared in 2014
Go: first appeared in 2009
Go как-бы пилят уже в два раза дольше, в 2013 о нём вообще мало кто слышал. Вы хотите, чтобы в Swift было всё и сразу? Кстати проблемы со временем компиляции до сих пор не преодолели даже в таком молодом и малоизвестном языке, как C++.
я не видел подобных решений для java или c#
Да, давайте теперь ещё сравним компиляцию в нейтив-код и компиляцию в байт-код.
edbuwg
30.06.2018 09:30Эм так дело собственно говоря в том что фронт компилятор свифта компилит именно в 'байт код' llvm'а ;) который является беком и компилит уже в нативный код.
По поводу Go, а не подскажите сколько там было breaking changes?
Может сравним размер и капитализацию компаний разработчиков?
Или может сравним число девелоперов в командах?
Или вы просто уклонитесь от этих неудобных вопросов и будете дальше фанбоить по эплу?:)
Ну и попробуйте найти статьи(от крупных компаний) по ускорению времени компиляции в плюсах(да черт возьми, даю вам фору — на вообще ЛЮБОМ языке кроме свифта) связанные тупо с симплификацией обычного кода(не с темплейтами).
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)yarric
30.06.2018 10:48Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем? Ну это так, вопрос на общую адекватность.
а не подскажите сколько там было breaking changes
Не подскажу. До первой версии явно были.
сравним размер и капитализацию компаний разработчиков
Дело не в капитализации, а выделенном бюджете. У вас есть такие данные? Да и задачи там стояли разные: что-то Google даже не попытался вписать Go в инфраструктуру Android, просто разработал очередной язык в вакууме даже без UI библиотек.
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
толпы фанбоев без бекграунда — пытаются разрабатывать софт
Все так начинали.
edbuwg
30.06.2018 14:43ух сколько жира:
Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем?
интересно а вы представляете? и как вы думаете во что интересно сложнее компилить если имеется такой замечательный инструмет как GraalVM ;)
Не подскажу. До первой версии явно были.
ДО первой версии, не так ли? не между КАЖДОЙ, не так ли?
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
не будет, но для меня будет новостью если вы найдете статьи по ускорению компиляции плюсов симплифицированием кода. Да бог с ними с плюсами — на ЛЮБОМ другом языке кроме свифта. Сможете же? Или проигнорите во второй раз?
Все так начинали.
нормальные начинания начинались в академической среде а не среди смуззихлебов которые написать компилятор пятый год не могут.
khlopko
30.06.2018 15:34Проблемы «симплификации» как ее тут назвали преувеличены. Во-первых, сами разработчики придумывают себе проблемы и потом героически их решают и рассказывают на конференциях. Да, были некоторые реальные проблемы со скоростью раньше, но даже они касались скорее вырожденных случаев. Нам, например, хватает писать типы в некоторых местах (что бы компайлер не пытался резолвить их а уже точно знал) и разбивать огромное спагетти из optional chaining (в мире свифта это способ развернуть обьект который может быть nil)
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.edbuwg
30.06.2018 15:54Проблемы «симплификации» как ее тут назвали преувеличены.
'проблема' в том что это вообще существует, все эти статьи и доклады по настройками компилятора (sic) и тому как смержить все файлы в кучу чтобы немощный компилятор быстрее проанализировал один большой файл чем кучку маленьких.
дальше — никаких проблем.
у ВАС не было, у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проект, а потом кому то приходится засучив рукава работать после таких 'работников'.
К следующей версии сделают ABI к тому же.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышу ;) вот от вас снова услышал — посмеялся и то хорошо
у C++ например вообще по годам выпуска версии
да и там точно такие же ломки апи? ;)VyacheslavAcronis Автор
30.06.2018 16:02ABI Stability в Swift 5 — это заявленая фича github.com/apple/swift-evolution#development-major-version--swift-50
khlopko
30.06.2018 17:53'проблема' в том что это вообще существует
Только в тех статьях, а не в реальной жизни. Написать долго компилирующийся код можно на чем угодно ведь. Тот же Kotlin часто ставили в сравнение к Свифту, только вот на андроиде он сейчас хуже Свифта первых версий в плане скорости компиляции. А сливать все в один файл — ну так и в других языках можно, что бы линковщику облегчать работу, тоже станет быстро компайлится. А вообще все их проблемы только потому что надо раз в 2 минуты компилировать и запускать проект, потому что… а черт их знает почему они так делают. И это печально, конечно.
у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проект
Была такая же проблема, в подах чего только не было, когда увидели — были в шоке, за месяц подчистили и перевели. Но давайте будем честными, проблема тут изначально не в том что поменяли что-то в новой версии языка (потому что так же само могло все повалиться с новой SDK, будь у Вас Obj-C проект), а в том что накидали pods без разбору и с этим приходится жить.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышу
Я не слухи рассказываю все же, а что происходит в swift-evolution. Они за все время ни разу не обещали что вот прям в следующей версии все будет идеально, они определяли приоритеты и реализовывали, у них с этим все довольно строго. И изначально сказали когда речь пошла про ABI что они два года будут это делать, чем, собственно, и занимаются. Для них это тоже довольно важная вещь и не только потому что ченджи ломают все. Сейчас уже, кстати, можно в 4-м Свифте 3.2 использовать.
да и там точно такие же ломки апи? ;
Я это упомянул не в плане изменений в С++ (за коим уже давно не слежу и статьи здесь на хабре про новшества нового стандарта честно говоря выглядят жутко в плане кол-ва изменений и нововведений), а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.edbuwg
30.06.2018 22:04а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
так и я про это же, представьте какой бы вой был бы если бы оракл или мс опубликовали язык такой же степени сырости, с… вном их бы мешали все кому не лень. А в мире эплфанбоев это жрут и добавки просят. И заботливо мостырят скриптиками костыли и подпорочки чтобы этот треш хоть как то работал.
дело ж не только в компиляции тормозной (хотя и в ней тоже), дело в убогой бажной иде, дебаггере, плейграунде, в общем такое ощущение что им абсолютно начихать на своих девелоперов, все равно утрутся и дальше будуто хлебать.khlopko
01.07.2018 13:36Ну Xcode был не подарком и до выхода Swift. А по поводу того что Swift выкатили недоделанным и это ужасно, а все радуются все же не соглашусь. Они его показали всем и сказали, хотите — пишите на Swift. Не хотите — не пишите. И стали дорабатывать его по отзывам комьюнити, что, на мой взгляд, весьма разумное решение. Сейчас можно увидеть цели и идеи команды разработчиков и внести свои предложения на обсуждение. Имхо, это гораздо лучше, чем получить сферического коня в вакууме.
yarric
29.06.2018 14:58Под Swift есть несколько книг и статей от Apple + целая гора материалов по отдельным библиотекам на сайте Apple для разработчиков. По андроиду приходится искать сторонние книги и туториалы и надеяться, что автор разобрался в теме.
VyacheslavAcronis Автор
01.07.2018 11:30А чего в документации для Android не хватает? На мой взгляд, она достаточно неплохая.
Quolyk
29.06.2018 14:31Чтобы отвечать на простые вопросы о свифте достаточно за пару часов пролистать официальную книгу и ты готов.
VyacheslavAcronis Автор
29.06.2018 14:32Парадокс в том, что это действительно так. Но, во-первых, это почему-то никто не делает. Во-вторых, это только самые простые вопросы на собеседовании, есть и более сложные.
edbuwg
29.06.2018 14:36Но данный язык отстал от современных методов разработки, Apple его не развивает, а также он отличается наличием большого количества устаревших правил, таких как отсылка сообщений nil-объектам и динамическая система типов.
Уважаемый, жгите еще про отсталость динамической системы типов и безопасность встроенного nil.VyacheslavAcronis Автор
29.06.2018 14:37Жду аргументов в плюс подобного подхода:)
edbuwg
29.06.2018 14:47про динамизм — протокол ориентированное программирование на нем же и основанно)
а вообще кордата и kvo работает за счет isa swizzling, динамизм скорее благо чем зло.
а про нил безопастность по вашему надо крешиться? или как в свифте лепить guard let в рядок?VyacheslavAcronis Автор
29.06.2018 14:53Конечно, крешиться. Да guard let. Protocol Oriented Programming совсем не про это. У динамических типов, например, иначе диспетчеризация методов устроена.
edbuwg
29.06.2018 14:58Конечно, крешиться
fail fast — хорошо девелоперу и очень очень плохо юзеру
Protocol Oriented Programming — вполне про это(динамизм), не важно кто(инстанс какого класса) и каким образом имплементирует протокол, как примеры дефолтная имплементация протокола в свифте или targetForSelector в обжективе.
dizasm
29.06.2018 15:04У вас в коде две проверки на выход за границу массива и обе с ошибкой.
VyacheslavAcronis Автор
29.06.2018 15:05Вы имеете в виду пример кода в этой статье? Что именно не работает? Можно в личку или сюда в комментарии.
edbuwg
29.06.2018 15:31Это вы в какой стране собеседовали? iOS вакансия только в Болгарии видна.
VyacheslavAcronis Автор
29.06.2018 15:31Россия, Москва
edbuwg
29.06.2018 15:58В стране где между девелоперами и недевелоперами 5-10 кратная разница в ЗП оно(попытка хоть тушкой, хоть чучелом пролезть) и не не мудрено.
smanioso
29.06.2018 16:20Интересный пример того, о чем можно поговорить при собеседовании на знание Swift (без учета Foundation и UIKit): developer.apple.com/videos/play/wwdc2018/223
r3r
29.06.2018 20:05Добрый день, ребята.
Я не программист, но увлекаюсь разработкой под андроид. Вот вопросы же элементарные. Я не знаю swift, но на все вопросы можно ответить, просто зная парадигму любого языка. Интерфейсы просто с другим названием, ну или передача по ссылке и по значению, ну вот везде это описано. В любой книге, по любому языку программирования, только с небольшими отличиями. Вот что это за кандидаты, что лажают в таких местах и на собеседованиях в такую крупную компанию. Ладно там резюме в интернете скачал, но у вас же должны быть HR со списком готовых вопросов/ответов, которые просто должны отсеять эту аудиторию по телефону. Просто представляю, сидит тимлид, работающий команде разработки под iOS, и к нему на собеседование приходит ЭТО.unclejocker
30.06.2018 00:16Лид не удивится, вы просто не рекрутили сами, вам удивительно, а так то ситуация такова что ЭТО приходит… ну где то на 8 из 10 собеседований. Причем похоже от языка/платформы не зависит. Готовые вопросы-ответы как раз учатся, а в офлайне есть еще и гугл + «звонок другу».
cher11
30.06.2018 00:58Объясните, пожалуйста, связь между
На деле замыкание — это reference type
иотсюда появляются известные конструкции [weak self] in
Имелось в виду то, что self сильно держит замыкание, и для избежания retain cycle внутри замыкания self держится слабо?VyacheslavAcronis Автор
30.06.2018 09:32Да. Это и имелось в виду. Это первая статья на тему swift. Многие вещи тут представлены весьма сжато. Если эта тема покажется интересной сообществу, то можно создавать более подробные посты.
vuvashek
30.06.2018 09:29"Строго говоря, в случае с 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, не используя главные фичи языка(например расширения протоколов), хотя вроде сейчас много материалов на эту тему.
edbuwg
30.06.2018 09:36Они в принципе ничего не учат но зато фанбоят.
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
MariyaSafonova
30.06.2018 10:41Опыт проведения собеседований с использованием Playground показался интересным. Вроде бы как и теорию спрашиваете, и при этом ставите разработчика в более привычные для него условия — у ноутбука. Идея с более подробными постами — лайк!
ftp27
30.06.2018 12:42Что тут интересного? Playground все еще не стабильнен. Не знаю как будет в следующей версии, но сейчас даже когда надо быстро набросать, например, что бы проверить код для рисования какой либо картинки в контексте. Playground будет зависать каждую вторую сборку и придеться ребутить весь xCode чтобы все собралось. Так что лучше уж на бумашке код писать, тем более это полезнее
MariyaSafonova
30.06.2018 13:04Конечно, Вы правы. Однако, на собеседовании, как правило, не просят написать что-то серьезное. За код на бумажке некоторые могут и обидиться.
Расскажите, почему вы считаете, что код на бумажке писать полезно?ftp27
30.06.2018 14:09Когда человек пишет на бумаге у него нет таких прелестей IDE как auto-complite и прочего. Приходится знать что ты пишешь. Даже если человек переходит на псевдокод, ему все равно необходимо хорошенько поразмыслить прежде чем что либо писать. Все это показывает какой то скил, что несомненно полезно при приеме. Понимаю, что многим это будет неприятно да и мне тоже было весьма не удобно, когда это просили. Но куда деваться? Надо же узнать о навыках кандидата. Посмотрите статью о разрабе который писал весь код на бумажке, уверен, что для него такая практика была полезна, хоть и необходима
VyacheslavAcronis Автор
30.06.2018 14:38+2То есть, при написании кода в IDE человек не мыслит? Это что из серии: пользуйтесь пером, а не шариковыми ручками, ведь так поступали наши деды. Можно и на перфокартах код писать с запуском куда раз в сутки, как это было в советских НИИ, но зачем. Писанина на бумаге проверяет весьма сомнительные скилы.
VyacheslavAcronis Автор
30.06.2018 13:26+1Код на бумажке, особенно часто это бывает ObjC, выглядит слишком непонятно: отсутствие подсветки, сплошная какофония из ObjC-style синтаксиса [[SomeClass alloc] initWithParamAndParam]; в распечатанном (или, ещё хуже, написанном от руки) виде введёт кого угодно в ступор. К тому же код на бумажке нигде никогда не используется, очень странно это использовать как тест.
Dolbe
30.06.2018 18:28Можно дать цветные ручки и попросить в довесок воспроизвести цвета из IDE.
Шутка, если что. Не сарказм.
edbuwg
30.06.2018 15:08наконец то хоть один практик в треде) и о боже мой он говорит ересь, что хкод глючит и виснет — как же так сжечь еретика и выпить еще смуззи во славу Кука
victor-hyde-code
02.07.2018 12:13Добрый день!
А можете прокомментировать результаты по заданию с падающим приложением?
Первый пул-реквестер просто удалил требование наследоваться от
UITableViewCell. На мой взгляд, можно было решить задачу лучше.
Немного поискав, я нашел, что проблема относится к багу в компиляторе Swift, и самое оптимальное решение — указать директиву наследования от
classилиAnyObject.
Данное решение оставляет требование наследоваться от UITableViewCell и решает вопрос падения приложения, единственная проблема — появляется warning, который тоже является багом компилятора, который должны будут исправить в будущем.
Ну и чтобы два раза не вставать, подскажите, кандидатов не писавших на Objective C, но понимающих код, и пишуших на Swift вы рассматриваете? Если да, то по поводу трудоустройства вам куда лучше писать, откликаться на hh.ru?
VyacheslavAcronis Автор
02.07.2018 14:16Добрый день. Напишите, пожалуйста, на Career-RU@acronis.com с пометкой, что хабра.
smanioso
Хотелось бы видеть не только список «хитрых» моментов, но и пояснение (что это, зачем это, почему в Swift это реализовано именно так). Иначе вы получите очередную волну разработчиков, которые «копипастят» ответ из вашей же статьи не разобравшись в сути происходящего. Ну или дать ссылки на статьи, где соответствующая тема раскрыта.
А пока что статья тянет на жалобу+опрос.
Два года назад? Автор статьи новичок или опытный???
VyacheslavAcronis Автор
Добрый день. Скорее это был литературный оборот, чем точная формулировка. Да, согласен. Дату можно поправить, конечно, если это прямо очень принципиально. Эта статья пока планируется как первая из цикла статей. И если эта тема будет интересна сообществу, то каждый вопрос, безусловно, можно раскрыть более подробно, а также добавить другие вопросы, которые задаются во время собеседования.