Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Войти c нуля в разработку мобильных приложений для iOS: план действий

После 20 лет работы в маркетинге и продажах B2B появилось желание попробовать себя в совершенно другой сфере, в которой возможна удаленная работа и фриланс.

Переход в IT — логичный выбор, но здесь меня по-настоящему привлекает только одно направление — разработка мобильных приложений. Причем не под Андроид, а для IOS.

Хочется понимать весь цикл разработки от идеи до прототипа и в конце-концов видеть конечный продукт.

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

Допустим, я быстро пройду известный вводный курс Скутаренко по Swift и параллельно — начальный курс Apple — Start Developing IOS Apps with Swift, а затем добавлю к ним 2 более сложных курса: курс IOS разработки от Стенфордского университета, который есть в ITunes U и курс Udemy — iOS 10 and Swift 3 — From Beginner to Paid Professional

Какие следующие шаги необходимо сделать после прохождения этих курсов, чтобы начать самому разрабатывать приложения или иметь возможность удаленной работы?

Что еще дополнительно следует изучить?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Интересно какие успехи у автора? уже освоил свифт и обж-с? и какую работу нашел? есть чем поделиться?

известный вводный курс Скутаренко по Swift

Не рекомендую: той Swift код не буде компілитися бо версія стара, курс не закінчений, покриває тільки синтаксис, так що толку від нього буде мало, тільки потрачений час.

Рекомендую якраз відомий курс Скутаренка по Objective-C. Код буде компілитися, курс покриває не тільки синтаксис мови, а і роботу з основними фреймворками і навчить працювати з UI. На логіку там завдання також є. Якщо виконувати всі домашки то толку від курсу буде достатньо щоб взяли джуном. Після курсу можна відносно легко перестрибнути на Swift. Мало того: на сьогодні більшість компаній вимагають окрім Swift знання і Objective-C.

І ще: рекомендую спочатку кинути всі сили щоб пройти виключно курс Скутаренка по Objective-C, а потім перевести той код на Swift. Далі, швидше за все, не потрібно буде більше ніяких книжок та курсів (маю на увазі до працевлаштування), бо краще піти джуном і на справжній роботі рости, ніж сидіти вдома ще рік і читати книжки та проходити курси.

Я не буду рассказыва о том, что в 40 лет стать iOS джуном тяжелее, чем в 18 т.к. автор видимо в курсе этого, если всё же решил стать на такой путь.

Советую я одно: учить и работать больше, чтобы пытаться зайти сразу на позицию middle (вакансий на эту позицию больше всего).

Онлайн курсов для этого будет мало, да и из всех выше перечисленных советую только курсы Скутаренка, чтобы вообще понять что к чему и протестить себя, хватит ли сил и упорства чтобы пройти этих 50 уроков и выполнить все домашки. А в остальном, советую читать книги и больше те, которые касаются не просто iOS, а программирования в целом.

Могу отметить «Совершенный Код» Макконнелла, «Рефакторинг» Фаулера, что-то для ООП (headfirst + банда четырёх). А для iOS — любые книги Ray Wenderlich.

Удачи! Всё получится.

В 40 лет легче, чем в 18. Сложнее по языковому фактору — от 40-летних требуется уровень владения на порядок выше, то что 18-летним прощается, от 40-летних воспринимается как оскорбление.

А вот учиться программировать в зрелом возрасте ощутимо проще. Мозг уже приспособлен под жёсткий отсев мусора, умеет сосредотачиваться на важном, и очень хорошо понимает собственные ограничения.

Я не спорю, что есть люди, которых в 40 лет ничему не научишь. И с вероятностью >95% утверждаю, что их ничему нельзя было научить и в 18, они выбрали противодействие обучению ещё в школе. А вот если человек с высшим образованием (с любым), и работал головой по любой специальности — то с огромной вероятностью к 40 у него обнаруживаются знания ещё на пару высших. Грубо говоря, с 40-летними ничуть не сложнее в обучении — но намного проще в отсеве.

«Совершенный Код» Макконнелла, «Рефакторинг» Фаулера, что-то для ООП (headfirst + банда четырёх)

— прекрасно подходят для растопки костра на корпоративном выезде на шашлык. Гораздо эффективнее почитать обычную книгу по логике (юристов например этому обучают), чтобы код отражал именно человеческую логику. Если код этому принципу не соответствует — значит и компьютер сделает дело неправильно. Если код нелогичен — то никакой синтаксический сахар и сверхновые фреймворки всмятку не оправдают непредсказуемый результат, пусть и покрытый тестами «на 100%». Разумеется тестами будет покрыт код. А должна покрываться — логика.

С утверждением о том, что в 40 учить проще — согласен, но это работает не в любом случае. Многое зависит от того чем занимался человек на протяжении последних лет, какие задачи решал и тд. На счёт книг для растопки костра, я бы так резок небыл, они помогают именно новичкам понять что вообще от них требуется и в какую сторону стремиться. Именно в этих книгах пытаются вдолбить читателю, что программист пишет код для людей. И неужели Вы не согласитесь, что теоретические знания шаблонов проектирования помогают программистам понять чужой код гораздо быстрее?

Нет, не соглашусь. Абсолютно любое слово, любая языковая конструкция естественных языков — является шаблоном. Повторюсь, любая. И всё что на них может быть описано — есть применение шаблонов.

Так что считать что авторы типа «лучших практик» изобрели что-то новое буквально вот всем необходимое — это не более чем поклонение авторитетам. Подумаешь, выдумали несколько десятков новых слов. Мало того, слов требующих пояснения буквально каждый раз при использовании.

Я считаю, что всё что нельзя описать естественным языком — не должно применяться в программировании как шаблон. Потому что делает код понимаемым не всеми, а только избранными — читай дорогими специалистами, в выборе которых легко ошибиться. Точно так же ОШИБКИ в коде, который не может быть описан естественным языком — имеют свойство сохраняться десятилетиями. Просто потому что они не видны невооружённым глазом.

Если вам когда-либо приходилось покрывать тестами даже простенький BiConsumer — вы догадываетесь сколько это гемора, поймать в нём всевозможные грабли. Гораздо дешевле вышвырнуть к ипеням этот шаблон и заменить на линейную логику, там где он не даёт преимуществ (практически везде).

Ещё пример: конструкция типа forEach — очень легко понятна людям. Чуть менее понятна, но легко узнаваема for(var i=0; i<something.getLength();i++) И совершенно невоспринимаема при разборе something.stream().mapToInt((s) -> Integer.parseInt(s)).doSomethingUnpredictible();

Есть миллион способов написания логики для компьютера. Хоть байткодом, хоть ассемблером, хоть битовыми масками по принципу шарманки. Но код пишется людьми, для людей, и оптимальный вариант — писать так чтобы даже шестикласснику было понятно.

ПРОТИВОПОКАЗАНО смешивать IT и бюрократию! Бюрократия — смертельная болезнь бизнес-процесса. IT — катализатор, не имеющий иммунитета к маразму. Потому единственный способ писать хороший код — устранять любым способом тех, кто пытается внести БЕСПОЛЕЗНЫЕ РИТУАЛЫ в написание кода. Лучше всего уволить. Невозможно — значит уволить тех кто не даёт. Если невозможно и это — драть когти из организации, потому что жизнь одна, и она не для того чтобы тратить время на дебилоидные ритуалы.

Если вам показать «лучшие практики» 90-х — вы будете смеяться. Точно так же через 20 лет люди будут смеяться над той х-нёй которую учат писать сейчас. Единственная причина почему этого не делают сейчас и открыто — авторитетное мнение. То есть мнение, за которое не накажут, а вот за сомнения в его правильности — запросто.

Учить это добровольно может только дятел. Просто потому, что всё что не будет использовано — забывается. Учить бесполезные вещи нужно ровно в том объёме, который требуется чтобы не попадатся бюрократической системе. И каждая содержит свой набор отсебятины. До того как в систему попал — не трогать дерьмо.

Исключения — если надо пройти собес или сертификацию. И то и другое — бюрократические процедуры, проводимые теми, кто реальной работы не выполняет и давно разучился это делать даже если и умел (маловероятно). «Вызубрить — сдать — забыть» — единственно верный алгоритм. По-другому никак.

Многие вещи действительно нужны только для собеседования, ибо используются на практике очень редко либо вообще не используются. Время идёт, а с ним появляются новые технологии и новые правила. Но вот эти правила написания кода нельзя назвать правилами, скорей рекомендации, которые можно использовать. Этим и отличается глупый программист от настоящего — умение решить для себя, использовать имеющийся паттерн или написать что-то другое, более подходящее под данную задачу. Но знание этих самых рекомендаций поможет начинающему программисту начать думать в правильном направлении, а с опытом придёт как раз осознание того, что делать «по книжке» не всегда будет верным решением. Я подчеркну, НЕ ВСЕГДА, т.е. будут случаи, когда все же советы из книг помогут неплохо так сориентироваться, а начинающий программист как раз и чаще всего подвержен дезориентированию.

Так вот, вещей «только для собеседования» не должно быть в принципе. Их учат непосредственно перед собеседованием, и только если оно надо — в смысле если начальство ещё не выгнало тупых куриц из HR и скрам-митинг-мэныджыров.

А для того чтобы писать код учат совсем другое. Настоящие шаблоны проектирования — это то что чаще всего спрашивают на StackOverflow :)

не подскажете,пожалуйста, какую книгу/пару книг лучше всего купить для изучения Java (мой уровень примерно Java Core) и посоветуйте плз книгу по логике?
На компе у меня сохранено довольно много хороших книг по Java, но мне хочется именно купить хороший справочник,чтобы в любой момент обращаться,делать пометки и т.д.(вы уже где-то писали,что имеет смысл и покупать книгу).
Как считаете, что более целесообразно — читать на англ. или русском? английский понимаю без проблем, но на русском материал воспринимается все же немного быстрее/лучше.

Если уровень Java Core — никаких книг уже не надо по самой Java, становитесь сразу на фреймворки. Хороший справочник — StackOverflow и JavaDoc :)

Когда будете писать код — в нём и будете делать пометки, по крайней мере в альфа-версиях. Из продакшена разумеется это всё придётся почистить (или не придётся).

Читать на том, который лучше понимаете. Если есть на русском или украинском — разумеется читать на них. Потому что ваша задача учить то что вы учите, отсеивая тонны воды. Отсеивать мусор на неродном языке — очень тяжело. На родном вы просто видите когда автор льёт воду ради объёма и пропускаете.

Книгу имеет смысл покупать по рекомендации, либо когда вы сами с ней могли частично ознакомиться. Потому что количество мусорной литературы просто зашкаливает. На любой заголовок всегда найдётся писака, который вам тупо перефразирует документацию и нальёт воды.

По огромному опыту программирования на Java — могу сказать что по итогу вы будете программировать НЕ на Java, а на конкретных фреймворках и библиотеках. К языку же вы просто привыкните, и 97% его «возможностей» просто не будете использовать — потому что это мусорный код, интересный лишь малому числу людей, например разработчикам библиотек.

СЛЕДУЮЩИМ после Java Core осваиваются даже не фреймворки, а IDE и утилиты. То что реально нужно чтобы работать на результат, а не толочь воду в ступе. То IDE которое вы выберете — вероятнее всего на всю жизнь, его сложно менять когда привыкаешь. Впрочем, попробовать (и убедиться) нужно обязательно. Моя рекомендация — иметь под руками IDEA и NetBeans. Idea приятен для своих проектов, а в NetBeans удобно разбираться с чужими (скачанными с гитхаба и прочих источников). Соответственно в NetBeans будет подключена свалка библиотек, которые в повседневной работе будут только мешаться. Равно как и держать постоянно кучу открытых проектов неудобно.

Первым рекомендую ставить NetBeans. И вместо написания своих проектов, взять простенькие чужие и разобраться как работают (попутно с ними экспериментируя, не боясь угробить).

А вот уже когда наиграетесь с инструментами очень хорошо, так чтобы аж нравилось — вот только тогда книги. Чтобы сразу моли применить то что прочитали, и НЕ ЧИТАТЬ те главы, которые не собираетесь применить прямо вот сейчас.

спасибо за ценные советы! а по логике может найдутся хорошие рекомендации?)

рекомендую читать при входе только на русском — понимание будет приходить быстрее и без дополнительных напрягов мозга. Знаю это по себе, так как свободно говорю на английском, но читая книги невольно нужно подглядывать в словарь. На английском успеете почитать, когда уже начнется работа и понадобятся более глубокие познания.
а если Java Core уже освоен, рекомендую начать писать учебные проекты, чтобы освоить инструменты и фреймворки по выбранному направлению. мне в этом понравились материалы Тимура Батыршинова(можно найти на просторах торрентов).
Все же на собеседовании спрашивают с чем работатать умеешь. Чем больше знаешь — тем меньше тебя придется обучать)
Удачи!

1) Начните с азов программирования. Вдруг простой вопрос алгоритмизации будет ставить вас в тупик?
2) Проверьте, что у вас есть чувство вкуса в дизайне. Даже с готовым прописанным дизайном вам необходимо самом решать мелочи по части внешнего вида. Если нет вкуса, то вам нужно работать в связки с дизайнером. С удаленной работой это значительно сложней.
3) Вам нужен Мак. Для iOS разработки это не обсуждается.
4) Получайте опыт, анализируйте его и думайте своей головой.

последние несколько лет макбук + айфон, в молодости занимался рекламой именно как заказчик для дизайнеров в том числе, надеюсь не испортил вкус за это время. А вот азы программирования изучаю, читая руководство по Питону + 2 книги для ничинающих изучать Питон. В отличие от Свифта — все сразу получается и постепенно раскладывается по полочкам.

В отличие от Свифта — все сразу получается и постепенно раскладывается по полочкам.

Ну я взял некий Swift for Windows 1.6 проигнорил требование «виндоус 10» с ходу поставил на виндоус 8.1 запустил и сразу же ж написал программу:

print("Hello")

— всё отлично получилось! И даже «постепенно раскладывается по полочкам»:

func Repeat<ItemType>(_ item: ItemType, _ times: Int) -> [ItemType] {
    var result = [ItemType]()
    for _ in 0..<times {
        result += [item]
    }
    return result
}

let resItems = Repeat("knock", 4)
for item in resItems {
    print("Item is : \(item)")
}

Отличный язычок ящетаю!

В одном месте даже «пришлось» провалиться в глубь «за синтаксический сахарок» и потом даже удалось вернуться в зад (его языка там 4-4,5 версии оказывается и они несовместимые сами с собой узнаю брата Аппле!)

Надо бы б достать с полки швейную машинку и пришить ему Foundation ну или достать с полки мак и перейти на х-код но я его не люблю как-то чтобы сильно...

Коментар порушує правила спільноти і видалений модераторами.

И знать надо особенности и iOS и Android.

Коментар порушує правила спільноти і видалений модераторами.

Тогда логичней переходить на реакт уже после опыта разработки native android и ios приложений, а иначе можно очень глубоко погрязнуть в формошлепстве.

Коментар порушує правила спільноти і видалений модераторами.

Если начинать мобильную разработку с реакта — может вырасти формошлеп, не способный ни udp сокет поднять, ни свертку битмапины сделать, ни получить видео поток с камеры и тд.

Например, Airbnb вроде тоже написан на реакте, но если отдекомпилить его андроид приложение, то можно убедиться что там полно самописаного java и kotlin кода.

Такие крупные компании могут себе позволить нанять js прогеров чисто для формошлепства и написании бизнес логики, а для voip, видео, компьютерного зрения, обработки изображений — уже нужен штат native разработчиков.

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

Начните с С для базы, потом обжектив-с, свифт (говнокод, где пишете на обжс с синтаксисом свифта), потом разберитесь чутку в функциональном программировании, потом уже снова на свифт.

Мое личное мнение, что все учебные материалы, кроме cs, которые вы выбрали, вредоносны, т.к. дают неправильное представление о базовых вещах, что прведет к тому, что вы потом пополните секту свидетелей massive view controller, которые не имеют вида, как отдельной сущности.

Пока тоже кажется сложным, скорее от отсутствия понимания основ программирования, но мне очень помогают книги по Python — сегодня утром даже серьезно задумался, что для начала надо пройти курс CS, в котором основной язык примеров — Python. А к Swift вернуться уже позже, уже с пониманием основных концепций программирования. Время позволяет. А вот C изучать вообще желания нет.

А вот C изучать вообще желания нет.

Там нечего изучать простите.

Без С и вы будете бесполезны хламом, тк не будете иметь понимания баз.

Лично я всех своих студентов мучаю с-шкой всегда. Принимать ли совет человека, 69 из 70 выпускников которого трудоустроены-дело ваше.

Свифт не кажется сложным, он по сложности недалеко от С++ ушел. Для того, чтобы на нем писать не как на обжс с синтаксисом свифта, а так же лаконично и быстро, как на обжс, нужны куча побочных теоретяеских знаний.

А можете тогда скинуть примеры open source проектов на свифте где по-вашему пишут правильно?

А можете тогда скинуть примеры open source проектов на свифте где по-вашему пишут правильно?

Сорян, в OSS почти не видел. Даже artsy и kickstarter могли бы писать лаконичнее при использовании большего количества фп концептов.

Без С и вы будете бесполезны хламом, тк не будете иметь понимания баз.

И не только. Т.к. жесткий мир мобильной разработки довольно быстро макнет ТСа в библиотеки из голого С, над которые навесить даже ОбжС интерфейсы не потрудились.
Начиная с примитивного «а вот эта кнопочка должна по параболе в нижний правый угол улетать при нажатии».

Не надо пугать чувака может превентивно?

адская смечь фп с ооп

Object Pascal ?)

Что в object pascal такого, что можно отнести к фп?

Если бы я написал Scala, было бы не так весело.

А я уже думал остал от последний тенденций, и таки добавили ФП...

Если бы я написал Scala, было бы не так весело.

Не. Таки в скала все проще. Еще и компилер умный в скале. Не крешится на валидных конструктах языка и не сообщает радостно, что выражение слишком долго компилится, поэтому компилить его не будет, а потом услужливо предалгает переписать его так, чтобы компилеру понралось.

Начните с С для базы, потом обжектив-с, свифт (говнокод, где пишете на обжс с синтаксисом свифта), потом разберитесь чутку в функциональном программировании, потом уже снова на свифт.

Навіщо людині С, з його побітовими операціями, роботою з пам’яттю і ручними низькорівневими оптимізаціями? Обж-с, як на мене, якраз привчає до говнокоду, оскільки прощає багато прорахунків на етапі дизайну, потім це все вигрібається костилями.

Свіфт — хороша сучасна мова, з широкими можливостями і строгими правилами по архітектурі. Хай топікстартер учить його спокійно, не засмічує голову різними мовами — йому ж потрібні навики для роботи, а не широкі теоретичні знання. Коли влиється в професію, буде собі вивчати альтернативи, копатися в історії і філософствувати над різними підходами.

Вы не правы.

ViewController на 3000 строк с вечными

func viewDidLoad() {
.........
self.titleLabel.text = (volodymyr?.ivanyshyn)!
self.titleLabel.textColor = .lightGray
self.btnXz.setTitle(model.smth!, for: .normal)
self.detailLabel.text = model?.dict["xz"] as! String?
.......
// еще 50 строк такого добра и (smh?.value)!

}

и
-(void)loadView{

  CGRect screenBounds = [[UIScreen mainScreen] bounds];    
  self.view = [[[UIView alloc] initWithFrame:CGRectMake(0, 0, screenBounds.size.width, screenBounds.size.height)] autorelease];
  self.view.autoresizingMask = (UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth);
  self.scrollView1 = [[[UIScrollView alloc] init] autorelease];
  self.scrollView1.frame = CGRectMake...
  [self.view addSubview:self.scrollView1];
  self.scrollView2 = [[[UIScrollView alloc] init] autorelease];
  self.scrollView2.frame = CGRectMake...
  [self.view addSubview:self.scrollView2];
и также
class XZViewController: UIViewController, UITextDelegate, UINextDelegate, Proto_Kol, ..... ,.... ,... ,.... , ...UICollectionViewDataSource, UICollectionViewDelegate, UITableView.......
со всеми прилагающимися методами и косвенными вызовами можно как на Swift сделать, так и на Objective-C.
Свіфт — хороша сучасна мова, з широкими можливостями і строгими правилами по архітектурі.

архитектура строгая лишь если программист строгий и другие члены команды работают в унисон

Тут нема що коментувати. Напишіть нормально вашу думку.

1. Не язык сам по себе делает строгую архитектуру проекта, а разработчики.
Если вы о семантике языка и синтаксических конструкциях — это другой вопрос , но также присутствует возможность выстрелить и тут себе в ногу, через (something?.smth)!

2. Плохо можно писать как на Objective C, так и на Swift. (тот же бардак и спагетти-код во ViewController, под 3000 строк)

3. По поводу:

Обж-с, як на мене, якраз привчає до говнокоду,

Не Obj-C, не Swift приучают, а бестолковые вездесущие легкодоступные туториалы низкого качества. Да что там говорить, если яблоко с порога пишет, как попало.

Звичайно, що хороший розробчик буде писати хороший код на будь-якій мові, а поганий — аналогічно. Але ми тут говоримо про несформованого програміста. От наприклад:
На обж-с якщо щось не сходиться по інтерфейсу, ліпимо `id`, `if (respondsToSelector...)` і так далі. Навіть якщо ми і хочемо все зробити красиво, в нас з коробки нетипізовані колекції. Тобто людина зразу починає писати як-небудь і компілятор все хаває.
В свіфті такі ситуації заставляють зразу думати над інтерфейсом, тому що `(something?.smth)!` буде різати очі кожного разу.
Ну і звісно, ми не чіпаємо тему багатьох плюшок, які в свіфті значно спрощують код.

PS: Про архітектуру я писав в контексті можливостей, які дає та чи інша мова.

Навіщо людині С, з його побітовими операціями, роботою з пам’яттю і ручними низькорівневими оптимізаціями?

Вопрос уровня: «Зачем человеку арифметика, есть же калькулятор.»

Обж-с, як на мене, якраз привчає до говнокоду, оскільки прощає багато прорахунків на етапі дизайну, потім це все вигрібається костилями.

Простите, но говнокод от языка не зависит.

Свіфт — хороша сучасна мова, з широкими можливостями і строгими правилами по архітектурі.

С какими такими правилами архитектуры строгими? Просто строгая типизация, а так все то же самое. Но, как известно, строгая типизация требует большего количества бойлерплейта для обеспечения тестируемости.

Про хороший и современный язык — свой код на гите не покажете?

Хай топікстартер учить його спокійно, не засмічує голову різними мовами — йому ж потрібні навики для роботи, а не широкі теоретичні знання.

Та да, просто на работу нигде не возьмут, т.к. не знает ни MRC, ни обжс и может сделать только по примерам рея вендерлиха (венец херового подхода).

Вопрос уровня: «Зачем человеку арифметика, есть же калькулятор.»

Давайте інший приклад: навіщо людині знати механіку ДВС, якщо вона хоче просто навчитися водити автомобіль. Тут в нас питання не в тому, чи взагалі потрібно вчити с, обж-с і т.д., а в тому, що людина хоче почати програмити. І моя позиція — хай починає з чогось одного, мінімального, що дасть їй практичні навички в скорому часі.

Простите, но говнокод от языка не зависит.

пхп-шнікам розкажіть :)

С какими такими правилами архитектуры строгими? Просто строгая типизация, а так все то же самое. Но, как известно, строгая типизация требует большего количества бойлерплейта для обеспечения тестируемости.

Строга типізація, різні плюшки типу дженеріків і т. д. — це все впливає на архітектуру на низькому рівні. На рахунок бойлерплейта для тестування — не в курсі, не можу нічого сказати.

Про хороший и современный язык — свой код на гите не покажете?

Ми ж тут не міряємося...

Та да, просто на работу нигде не возьмут, т.к. не знает ни MRC, ни обжс и может сделать только по примерам рея вендерлиха (венец херового подхода).

Не попаде на проект зі старим як світ легасі кодом, не розчарується в професії, з часом виросте і освоїть все, про що ви згадали.

Строга типізація, різні плюшки типу дженеріків і т. д. — це все впливає на архітектуру на низькому рівні.

От вот такого:

- (void)viewDidLoad {
    NSLog(@"ViewController1:viewDidLoad #############");
    [super viewDidLoad];
    self.view.backgroundColor = [UIColor yellowColor];
    //1.创建按钮1
    UIButton *pushButton = [UIButton buttonWithType:UIButtonTypeCustom];
    [pushButton setTitle:@"pushViewController" forState:UIControlStateNormal];
    [pushButton setTitleColor:[UIColor grayColor] forState:UIControlStateHighlighted];
    [pushButton setFrame:CGRectMake(100, 200, 200, 40)];
    [pushButton setBackgroundColor:[UIColor blueColor]];
    [pushButton addTarget:self action:@selector(pushViewController:) forControlEvents:UIControlEventTouchUpInside];
    [self.view addSubview:pushButton];
Или: github.com/...​omButton/ViewController.m
Ни свифт, ни обж-с не избавят
Не попаде на проект зі старим як світ легасі кодом, не розчарується в професії, з часом виросте і освоїть все, про що ви згадали.

Тут желательно в принципе попасть в команду к грамотным разработчикам.

Тут в нас питання не в тому, чи взагалі потрібно вчити с, обж-с і т.д., а в тому, що людина хоче почати програмити.

У вас аналогия некорректна. Правильная аналогия — начать проектировать машину, не зная ДВС.

пхп-шнікам розкажіть :)

А что рассказывать? Среди них есть отстой и сильные ребята, все, как в иос, где отстой все, кто учились по Рею Вендерлиху и дальше не развивались.

Ми ж тут не міряємося...

Мы не меряемся, я хочу оценить, насколько ваши размышления подтверждены реальностью.

Строга типізація, різні плюшки типу дженеріків і т. д. — це все впливає на архітектуру на низькому рівні. На рахунок бойлерплейта для тестування — не в курсі, не можу нічого сказати.

Все это влияет только в одну сторону. В сторону увеличения бойлерплейта. Массивные вью контроллеры в любом языке написать можно.

Как это не в курсе? А как вы тогда на свифте тесты пишете? Чтобы без бойлерплейта?

Не попаде на проект зі старим як світ легасі кодом, не розчарується в професії, з часом виросте і освоїть все, про що ви згадали.

Сорян, но это не легаси код, а современные системы. Или у вас знакомство с иос исключительно с точки зрения написания фронтов для визуализации апи без какой-либо логики и обработки данных?

В сторону увеличения бойлерплейта

Так копипаста -это же наше всё).. Некоторым людям нравится, когда все однотипно, по шаблону, путь и громоздкому, зато единообразно!

Некоторым людям нравится, когда все однотипно, по шаблону, путь и громоздкому, зато единообразно!

Ага. Насыпает статическая типизация. Все-таки, в динамических языках с посылкой сообщений и рантаймом (обжс, руби, смолтолк), очень часто можно избежать кучи геморроя чисто динамикой и метапрограммированием.

Мой совет прост и примитивен, но он работает: купить книгу. Логично, что видеокурсы — это туфта, которая покроет процентов 10 материала, и содержит процентов 99 воды. И с курсов сильно не скопипастишь, а с книги запросто.

Попроси кто тут на форуме готов тебе такую книгу продать. Обычно тем кто уже вырос из новичков книга не сильно и нужна, они больше документацию читают. А вот когда нужно постичь много сразу разных частей, одновременно или поэтапно, и так чтоб уж точно начать — только книга. Минимум одна. Максимум две.

Почему так: книгу быстро читать. Что-то можно пропустить, к чему-то вернуться. Нет необходимости всё держать в голове — можно тупо сделать закладку. Можно читать не последовательно (но лучше прочитать введение, где автор расскажет структуру книги, где о чём). Можно читать «по диагонали», чтобы быстро схватывать основные принципы.

А насчёт паттернов — скажу что всё это чисто бюрократический пистёж. Как в анекдоте — «не знаю зачем это надо, но каждая собака должна это уметь». Их невозможно понять, не имея минимум года практики. Равно как и имея более 3 лет, тогда они кажутся диссертацией эскимосов о том как неграм вести себя в условиях крайней жары.

А чому відразу не читати техн. документацію? :)

Базові алгоритми, структури данних та патерни вчити не потрібно?

Базовые алгоритмы уже вижу, что надо и уже примерно понимаю как учить. Структуры данных и патерны — пока только прочел комментарии, что учить надо, но каким опразом это оптимально делать, имея целью разработку мобильных приложений — пока не понимаю и буду очень признателен за помощь.

не потрібно.
згадайте, коли восьтаннє міняли місцями два числе без додаткової змінної, реверсили строку або реалізовували merge sort?

Но понимать чем линкед лист отличается от аррей листа, и чем они отличаются от сета надо же..

почему вы назвали именно эти структуры?
почему не красно-черное дерево или куча?
я вот использую массивы и хеши.

и потом, под «понимать» имеется в виду «слышать название» или «представлять все примущества и недостатки структуры А перед структурой В в случа С»?

Чаще их использую(кроме линкед лист). Для понимания на курсах мы их писали, как и дерево. Очень даже помогло. А дерево помогло понять рекурсию. И да, после этого больше понимания в преимуществах структуры А перед B в случаи C

Все класс, тока сроков не вижу?

Т.к. сомневаюсь, что меня в 40 лет возьмут на позицию джуна, сроков вроде «начать ходить по собеседованиям через 6 месяцев» не ставлю, более ориентирован на фриланс. Предварительно дал себе год на обучение, график пока не выработал, предварительно это около 800 часов чистого времени. Системно занимаюсь всего неделю, еще даже пошаговый план действий со сроками не прописал, вижу только цель + укрупненные недетализированные этапы + первые очевидные шаги.

Подтверждаю, не возьмут. По крайней мере 20-летние эйчарки. И не возьмут по банальной причине — вы «не сработаетесь». Хотя ни единого статистического доказательства этому нет, а есть банальнейшая безграмотность постсоветского пространства в сфере HR, где это не является нормальным образованием, а просто религия.

А вот если наработать портфолио во фрилансе — спокойно на мидла, или выше если портфолио специфично именно для вакансии (а такую и подождать не грех).

есть какая-то статистика отказов?
а то среди моих знакомых уже два «за 40» устроились джунами, а один в процессе.
хотелось бы понять, насколько эти исключения — исключения

Расскажи КУДА устроились, может и третьего возьмут.
Статистики нет, моя информация от живого общения с людьми, я привык так её добывать — тогда понятны детали.

Настоящая причина, почему HRы не берут «старых» — им самим никогда не было столько лет. Вот просто вообще никокда. И теории они не знают, как люди меняются с возрастом. Потому я считаю, что в должности HR молодым делать либо откровенно нехер, либо должны находиться под непосредственным руководством и контролем человека за 35, лучше за 40. Очень желательно мужчины — потому что у женщин происходят гормональные изменения, влияющие на принятие решений. У мужчин таких явных перемен нет, вернее они совсем другие, подходящие профессии.

У мужчины чаще другая проблема с возрастом — они спиваются. Но проверить это и найти вменяемых не проблема совсем. Например, если человек за рулём, риск того что он бухарь раз в 200 меньше. Но опять же, чтобы знать такие «мелочи», нужна теоретическая подготовка, и очень много общаться с реальными людьми и в неформальной обстановке, и в формальной вне субординации.

Так что просто порекомендуй ему в личку контакт эйчара, может и найдётся применение бойцу.

Так что просто порекомендуй ему в личку контакт эйчара

могу тебе скинуть, если надо. а ему бросать — рано. за год многое может измениться.

Расскажи КУДА устроились, может и третьего возьмут.

Ну я себе брал интернов и джунов за 40 неоднократно в моб.дев. Отличные пацаны выросли.

И рекрут у нас молодая девушка при этом. Я бы таки сказал из своего опыта общения с рекрутами, что, в основном, «не сработаются» идет не от самих рекрутов, а от тех, кто повыше.

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

потому мне и интересна какая-то статистика.
но где её взять — не представляю.

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

Причем зедсь бюрократические мифы, если руководство заказывает спецов с возрастным цензом рекрутам?

При том, что в правильно построенной организации HR знает потребности лучше руководства, работает напрямую с менеджментом проектов, а руководство осуществляет только контроль.

В бюрократической каждая вакансия утверждается минимум тремя подписями. И каждый подписывающий уверен, что два других хотя бы понимают о чём речь. А тот кто составляет — вынужден писать так, чтобы не отличалось от предыдущих подписанных, и содержало как можно меньше смысловых слов. В более зрелых бюрократиях непосредственного руководителя даже не допускают к составлению — его просто ставят перед фактом.

работает напрямую с менеджментом проектов

ПМов я также считаю руководством. И они, в основном, и выставляют возрастной ценз. Топам на возраст пофиг.

ПМ не просто руководство, а осуществляющий 80% всего руководства. По этой же причине средний уровень отсрела ПМ на испытательном сроке должен быть порядка 25%, и столько же после первого года работы. В противном случае планка падает практически до нуля и роль ПМа сводится к тому чтобы мешать.

Устроились во фронтенд или в бекенд? Или в мобайл, как хочет автор поста?

один во фронтенд, один в бекенд.

С английским как раз после 10 лет ежедневной переписки и отчетности проблем нет. Только разговорный подтянуть, т.к. сейчас общение в основном с китайцами и индусами, и техническую терминологию.

Разговорный — это не подтянуть. Это база английского. Если его не знаете — считай не знаете совсем. То есть фриланс по переписке — это можно. А в серьёзную компанию — «мы вам позвоним».

Просто мой разговорный в основном связан с переговорами на тему авиа и морских перевозок, логистики, ВЭДа и т.п. и учитывая работу на 90% с Азией — приходится пользоваться упрошенными конструкциями. Думаю, года общения с нормальным нейтивом будет достаточно, чтобы выйти на тот же уровень, что и reading/writing. А вот усвоить IT-терминологию может быть намного сложнее. И года, скорее всего, не хватит.

Нет никакой особой IT-терминологии. Если на слух воспринимаешь — этого достаточно. IT не сильно общительная профессия, тут надо слушать и понимать. А говорить надо мало.

Переход в IT — логичный выбор

продвижение приложений, SMM, PR мне кажется логичнее.

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

не, ну, на upwork пойти посмотреть, какого рода заказы могут быть "со стороны"(бо когда работаешь вроде-фриланс, но на постоянного клиента — формат отличается).

Какие следующие шаги необходимо сделать после прохождения этих курсов

найти ментора, который будет генерировать задания, приближенные к реальности.
и заодно расскажет, какие смежные области надо тянуть(UI/UX, вопросы публикации приложения, нюансы работы с виртуалками)

Продвижение приложений, менеджерская позиция и т.п. — это все-таки запасной вариант, если из меня не получится нормального разработчика. Тогда прошлый опыт + приобретенные технические навыки, думаю, дадут возможность претендовать на такие позиции.

Какие следующие шаги необходимо сделать после прохождения этих курсов, чтобы начать самому разрабатывать приложения

Можливо, «начать самому разрабатывать приложения»?

Это как раз то, что больше всего мотивирует и вдохновляет.

Можливо, «начать самому разрабатывать приложения»?

100% підтримую. Це хороший спосіб упорядкувати теоретичну інформацію з книг і курсів, заодно відсіяти «сміття». Ще добавив би: тягнути готові проекти з гіту і пробувати їх підправляти — розвиває навик читання коду.

Сделайте сначала хоть первые шаги, не нужно строить оптимистичных планов, изначально настраивайтесь на тяжелую работу, просто не будет! После прохождения курсов, пробуйте практиковаться в создании реальных приложий (например, копирование существующих с небольшими изминенениями) так сможете закрепить навык, сформировать портфолио работ. Далее пробовать искать работу. Успехов!

Спасибо, так и планирую, просто пока бегло просмотрел содержание доступных книг и курсов и подозреваю, что знаний и навыков, полученных после их прохождения, будет недостаточно, чтобы сразу создавать самому что-то нормальное. Сейчас уже вижу, что надо дополнительно срочно разбираться в ООП, возможно вообще сразу начать проходить курсы вроде CS50, алгоритмов, не связанные напрямую с разработкой приложений. Возможно, что-то еще является обязательным для изучения, только я пока об этом не догадываюсь )

Для Swift пока не так много обучающих материалов, что одновременно и плюс (не разбрасываюсь, а концентрируюсь на обучении и практике) и минус — некоторые концепции намного подробнее и понятнее объясняются в учебниках по Python.

Підписатись на коментарі