Можно

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

developer.apple.com

Кто нибудь работал с Cardboard SDK?

Или с Google VR sdk?

Ну блинский

видел туториал у рэя

Что за закрепа?

Закреплённая новость

эпл уже выпустила книжечку Swift 3.1

а то опыта есть - а каждое собеседование - это какое-то хождение по мукам

Я бы тоже провалил собеседование :) Но я самоучка, весьма stackoverflow-oriented. Меня спасает только убийственная тяга к делать все правильно и не говнокодить.

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

Если интересно iOS программирование с нуля, посмотри курс Стенфорда cs193p.

Я по нему очень хорошо выучился.

Угу) смотрел тоже)

Сейчас по 3 свифту прохожу :)

Его)

Что такоe hybrid и native deveoper?

мб ксамарин, фонгап и т.д. - это гибрид а тот, кто на обж-с, свифте - натив

Сейчас по 3 свифту прохожу :)

Не вижу смысла перепроходить.

мб ксамарин, фонгап и т.д. - это гибрид а тот, кто на обж-с, свифте - натив

Спасибо! ;)

а то что не книга, половина книги циклы, создание классом и т.д.

недавно читал простенькую книжку Simon Ng - Beginning iOS 10 Programming with Swift - 2016 вроде бы beginning, а все равно несколько полезных мелочей увидел, ну и просто освежил все в памяти так что не все так плохо даже в простом

недавно читал простенькую книжку Simon Ng - Beginning iOS 10 Programming with Swift - 2016 вроде бы beginning, а все равно несколько полезных мелочей увидел, ну и просто освежил все в памяти так что не все так плохо даже в простом

а можешь скинуть сылку ?

в этом вопросе больше символов чем в google.com )

> Евгений вопросе нравится мне таких

а можешь скинуть сылку ?

https://www.google.ru/search?q=Simon+Ng+-+Beginning+iOS+10+Programming+with+Swift+-+2016&ie=utf-8&oe=utf-8&gws_rd=cr&ei=yzK5WJTXLYKhsgHD0qnQDA

https://www.google.ru/search?q=Simon+Ng+-+Beginning+iOS+10+Programming+with+Swift+-+2016&ie=utf-8&oe=utf-8&gws_rd=cr&ei=yzK5WJTXLYKhsgHD0qnQDA

спасибо

в этом вопросе больше символов чем в google.com )

Но меньше чем в запросе гуглу

сопипаст

Извиняюсь, сразу не представился. #whois Зовут Ричардом. Студент БГУИР. В программировании новичок, на данный момент в универе изучал С/С++ и Java. По личной инициативе решил опробовать Swift. Сообщество интересно как коллеги, которые могут поделятся опытом, и единомышленники, среди которых поддерживается дружеская ненапряжная атмосфера. В свою очередь я смогу делиться своим опытом по мере получения мной знаний в сфере разработки, а также просто поддержать беседу с интеллектуальными людьми. Сам из Баранович (РБ), проживаю и учусь в Минске. Про группу узнал через Гугл, забив в поисковик желаемую информацию.

@White_guardsman Офигеть, тот момент, когда узнал, что есть ещё Ричард и тоже под iOS, притом и в Беларуси

Пока что не под iOS, поправочка. ?

Пишут, что хорошие практики в разработке - это избавление от зависимости, и где-то читал правило 1 класс - 1 задача - 1 зависимость

тобишь, если в контроллере у вас допустим импорт 3-4 либ, и выполнения набора действий - то под каждый импорт надо отдельный класс делать и под каждое действие так же?

Это нереально раздувает код. Сама Apple игнорирует это правило, например.

Принцип единственной ответсвенности называется)

а каких правил вы придерживаетесь?) вот Макконел пишет, что количество строк в классе не должно превышать 300, иначе далее начинается рост в прогрессии количество возможных ошибок и сложность

а если взять какой-то контроллер, типа ТаблВью, еще делегатов наподключать, там сотня строчек выйдет ток на стандартные методы

правило телеграма

:D

Пишут, что хорошие практики в разработке - это избавление от зависимости, и где-то читал правило 1 класс - 1 задача - 1 зависимость

ну это уж слишком

некоторые программисты на RoR (ruby on rails) вообще делают методы не длиннее 5ти строк

потому что у них там сахара как в кока-коле

синтаксического

?

все такие правила очень и очень ситуативны

но есть более менее универсальные принципы

то, что выше упоминалось, это single responsibility принцип видимо

буква "S" в SOLID

также стоит посмотреть на YAGNI, KISS, DRY и SOC

из интересных акронимов

Могу сюда добавить ещё немного философии https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/

На тему того, что оверабстракции не всегда удобны и приветствуются

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

ну и опять же моим первым профессиональным языком был питон

там есть отличный дзен

>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

> Namespaces are one honking great idea -- let's do more of those! До слёз

синтаксического

И медленно все

делать распознавание объектов на фото на руби - медленно, отдавать странички в вебе - норм

Смотрел недавно бенчмарки свифтовых вебфреймворков. Руби там вообще отстой

на практике если ты не фейсбук, то вполне хватает

гитхаб на руби

твиттер был на руби

инстаграмм на джанге

рутуб был на джанге когда-то

собсна фейсбук и вконтакт - на PHP

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

Действительно

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

по крайней мере я так 11 человек выучил 5 лет назад

я кажись тоже пишу код мне понятный) и ориентируюсь в нем хорошо даже спустя год-два

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

тееестыыы

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

чинишь хвост, посыпались плавники)

залатал плавники - чешуя обсыпалась)

тут один совет - пиши больше функциональных тестов

BDD например заюзай

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

это прямо офигенное чувство

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

Всем пр! Кто может замутить игру покер под iOS

https://telegram.me/mobile_jobs

Культур

Всем пр! Кто может замутить игру покер под iOS

iOS разработчик.

iOS разработчик.

ни тока

ни тока

А я и не говорил, что только.

Он спросил "Кто?", я дал валидный ответ.

gotcha

Так-то еще может какой-нибудь Unity developer наклепать.

Или Реактер, если совсем ебанется.

или Adobe AIR ?

Если ты хотел нормального ответа, то нужно было нормальный вопрос задать.

Есть клиент, хочет покер свой)

не удивляйсо