Соглашусь, для вас это неудобная схема. Но тут, как я и писал выше, никогда не получится идеального решения, к сожалению. Во всяком случае, я его не вижу.
Странно. Так «когда понадобится» — тогда и оплатите. Зачем «про запас»? Тут я все же поддержу их политику. Например, в гугле 25 баксов, грубо говоря, можно и у родителей выпросить, а потом забивать магазин бессрочно всяким непотребством. А необходимость отдавать каждый раз некую сумму за доступ в магазин — это, своего рода, фильтр, который отсекает такого рода злоупотребления. Да, это бьет по карману, но 100% удобного решения «для всех» и не существует. Всегда кто-то будет в минусе. С точки зрения пользователя магазина я бы предпочел, чтобы он был чище и качественнее. С точки зрения разработчика — опять-таки, разработчик это переживет, это не такие существенные затраты, если вы действительно регулярно разрабатываете приложения. Не идеальное решение, но, учитывая размер аудитории пользователей, на мой взгляд, правильное.
Ага. На самом деле, ни одного профессионального разработчика (да даже и только обучающегося), если он реально делает и выкладывает свои приложения, сумма 99 баксов в год (~500р в мес на текущий момент) ну никак пугать не должна. Интернет в месяц у многих столько стоит, а то и дороже. А уж для компаний, действительно, это даже ниже рамок погрешности. А вот «мусорные» приложения действительно дороговато становится выкладывать, поэтому многое отсеивается, а еще больше — на этапе сражения с проверками и тучей требований от эппла. Результат — сравнительно неплохой по составу ассортимент магазина. Что хорошо, как мне кажется.
Серебряной пули не существует. Нативные приложения быстрее и стабильнее (и подозреваю, что еще очень надолго так и останется), чем их кросс-платформенные аналоги. Скайп — тяжелое приложение, так как используется много нативных SDK (фото, видео, аудио, изображения), поэтому вряд ли его можно реализовать на «универсальных» движках, а если и можно — то это будет ни разу не дешевле, чем распараллеливание разработки на несколько платформ. Причины — большое количество потенциальных затыков, медлительность, палки в колесах, проблемы на ровном месте и замусоривание кода всевозможными «workaround» и «hack»-элементами, специфичными для конкретных платформ. Все это идет от простой общей истины — любой «комбайн» хуже, чем узкоспециализированное устройство. Любой специалист «на все руки» в 99% случаев (кроме исключений-гениев) будет менее эффективен, чем квалифицированный специалист в своей узкой области. В разработке это применяется ровно так же.
Поддерживаю. Есть ощущение, что автор исходной статьи писал часть, отвечающую за работу с девцентром Эппла, совсем не 13 апреля 2018 (как датирована сама статья), а значительно раньше. Сейчас все делается автоматически. Даже если нужны пуши, на самом деле, в приложении придется одну галочку переключить, и один раз заглянуть в девцентр, чтобы выдать сертификат бекенду. Все. Сложности были до ввода автоматической системы подписывания приложений, но сейчас это все в прошлом. Однако автор исходной статьи, видимо, не в курсе.
В остальном, в целом, согласен с описанными для Эппла сложностями. Но без минусов не обходится нигде, пожалуй. Да и для разработчиков, которые профильно заняты iOS-разработкой, проблем разобраться обычно не составляет.
Как только видите, что ваше резюме не читали (а раз предложили з/п существенно ниже — то не читали), либо вас не уважают, тупо вежливо прощаетесь и закрываете дверь с обратной стороны. Время — штука очень ценная. А если есть время и, главное, желание сидеть и выслушивать «веселенькие предложения» — то это попахивает мазохизмом.
На мой взгляд, не зря. Вы совершили ошибку уже на моменте, когда отдали результат работы за два полных дня бесплатно, без перестраховки. Все разговоры «до» — это вообще не гарантия и не показатель. Реальную ценность имеет только материальный результат, вы его отдали, — далее все на совести «работодателя». Если он с вами сам не связался — это явно человек/компания, с которыми не стоит сотрудничать, если они даже в простом вопросе рекрутинга не могут обеспечить пунктуальное и профессиональное общение с кандидатом. P.S. Вы пишете, что «через месяц» напомнили о себе — вы серьезно месяц ждали от них ответа? Я забываю о рекрутере, как только прошел срок, им же самим объявленный (обычно пишут «мы дадим ответ в течение 1 недели», например). Срок прошел — до свидания. Если возникают проблемы уже на этапе знакомства, то уж на этапе постановки задач или выплаты зарплат в реальном сотрудничестве этих проблем станет только больше. Имхо.
Ну и получается, что единственный способ показать «свой код» — это запилить какой-нибудь свой проект и выложить исходники на какой-нибудь github
И, кстати, отличный, хорошо работающий способ. Заводите гитхаб-аккаунт, и время от времени пополняете его какими-то кусочками кода, которые со временем могут вырастать в переиспользуемую либу. Так и актуальность поддерживается, и работодатель может посмотреть недавний код, написанный именно вами, а не кем-то еще. Очень удобно.
Да, а «серебряной пули» и не существует. Всегда кто-то будет иметь возможность проиграть. Либо кто-то не доплатит, либо кто-то не доработает. Универсальной и 100% гарантии нет, так как оценка тестового задания — дело часто субъективное, а деньги и время вполне себе материальны. Впрочем, не вижу особой проблемы, если перед выполнением тестового провести хотя бы базовое собеседование. Поговорили, если остались сомнения — попросили выполнить тестовое задание с предоплатой. А если поговорили и кандидат не устроил — смысл давать ему тестовое? Если же компания в принципе работает только по системе «массово разошлем тестовые задания и посмотрим на результат» — то это ерунда, так серьезных специалистов не найти.
Не возвращать. Предоплата = 50% от полной оплаты, например. Если совсем не справились (по мнению рекрутера) — предоплата остается у вас. Если справились — просите остаток оплаты. Не заплатят — ну, и фиг бы с ними, но вы хотя бы не совсем вхолостую работали.
Так же, как при выполнении любых работ без договора. В виде результата вы сначала отдаете заказчику готовый продукт БЕЗ исходного кода. Т.е. просто демонстрируете, что все работает, любыми способами, хоть на эмуляторе показываете в режиме скайп-конференции. А после оплаты заливаете исходный код в репозиторий заказчика. Только так. Я работаю так последний год, заказчиков это всегда устраивает (если заказчик платежеспособный), и все получают необходимые гарантии.
Ох елки, дико полезное лично для меня сравнение. Прям перестал глядеть голодными глазами на новый iMac. Странно, что в компиляции больше сыграла роль частота, а не многоядерность, как при том же рендере, например, я думал, будет наоборот. SSD по скоростям просто бешеный на новом Pro, но одно это (+моник и «у меня больше ядер») не должно создавать многократную разницу в цене. По статье остался вопрос, какое точно железо присутствовало в Хаке? Можете перечислить все (вообще все, без исключения) комплектующие, чтобы конфигурация оказалась рабочей, а многострадальная Sierra запускалась и работала без вопросов? А то меня от Хаков всегда останавливал только сложный процесс подбора комплекта. Сам сижу на MacBook Pro 2015, и, похоже, нечего даже дергаться, особо быстрее на новых компах не станет.
Интересный способ, спорить не буду. Немного не понял момент про «Xcode 4», когда сейчас актуальная 9-я версия… На самом деле, шаблонную механику не люблю за счет того, что каждая новая версия Хкода (даже не мажорная) может спокойно переломать все эти шаблоны, сменив их структуру, например, да и вести учет таких шаблонов нужно руками (опять-таки, из-за апдейтов Хкода). Я решаю проблему шаблонизации проще: имею проект, который лежит в облаке архивом, и представляет собой как раз «отправную точку» для большинства новых проектов. Надо начать новый проект? Ок, я копирую свой шаблонный проект, распаковываю его, переименовываю — и готово. И никаких проблем с потенциальной поломкой при апдейте версии Хкода. А если подрубить это все к репозиторию — то еще и обновлять можно удобно (мне пока не пригодилось, но будет больше шаблонов — применю этот вариант). Так выходит значительно меньше трудозатрат при том же результате, пусть и похоже на колхоз. За статью спасибо.
Безусловно, все так. Я говорил о приемлемых сценариях работы на приложениях разного уровня сложности. Разумеется, все тестируется на разных поддерживаемых устройствах. Я лишь имею в виду, что гонка за производительностью не должна быть самоцелью (вы тоже это упоминали), оптимизация делается лишь после того, как все уже работает, а не наоборот. И необходимость этой оптимизации тоже для разных приложений и круга пользователей разная. Автолейаут может лагать)) Вопрос в том, где он лагает, и насколько это отражается на восприятии пользователем. Стремление к «60 фпс на максималках», грубо говоря, само по себе вещь хорошая, но не необходимая (да и не всегда заложенная в работы заказчиком).
Хм, я пока встречал лишь одно приложение с огромным количеством таблиц с большой вложенностью ячеек, где «автослои» существенно замедляли работу, в остальных случаях его более, чем достаточно, без лишнего усложнения серверной работы и пред-расчетов. Но я понял вашу точку зрения, спасибо.
Статья любопытная, спасибо. Все знакомое, но есть пара интересных подходов, в частности, к пред-расчету высот ячеек. Я предпочитаю выполнять расчет и размещение элементов в общем updateConstraints через SnapKit/Masonry, пользовались ли вы этим подходом, и если да, то чем он вам понравился либо не понравился? Расчет на скалярных абсолютных величинах я перестал использовать именно после перехода на полноценный autolayout в коде.
Факт. Меня так попросили сделать только 7 лет назад, на моей первой работе. Чуть не спятил, пытаясь вывести на листочке тонну фигурных и круглых скобочек. Задачу-то решил, но было ощущение, что проверяется умение писать на листочке, а не решать задачу.
Финальная картинка порадовала)) В целом, согласен со статьей. Самого уже давно раздражают шаблонные математические или логические задачи, или пренебрежение предыдущим опытом. Ты им показываешь и гитхаб, и тучу проектов, и готов предоставить части кода на отсмотр, а у тебя просят «тестовое задание» и «пару задачек решите, пожалуйста». Хорошо, что сейчас подобных рекрутеров можно сразу же разворачивать. Рынок позволяет.
В остальном, в целом, согласен с описанными для Эппла сложностями. Но без минусов не обходится нигде, пожалуй. Да и для разработчиков, которые профильно заняты iOS-разработкой, проблем разобраться обычно не составляет.
И, кстати, отличный, хорошо работающий способ. Заводите гитхаб-аккаунт, и время от времени пополняете его какими-то кусочками кода, которые со временем могут вырастать в переиспользуемую либу. Так и актуальность поддерживается, и работодатель может посмотреть недавний код, написанный именно вами, а не кем-то еще. Очень удобно.