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

некоторые программисты на 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 😜

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

или Adobe AIR 😜

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

не удивляйсо

Чтобы играть на биткоины

Вопрос должен быть такой: "Кто в это ITC чате готов взяться за разработку игры под iOS с биткоинами."

И на него ты бы получил какой-то адекватный ответ.

Думал под андроид пилить, но решил под iOS

все прально решил

Я вроде Русский, просто проучилось по молдавских)))))

Ну смысл все поняли

Самый важный вопрос бюджет такой разработки и сроки?

Здесь такое не обсуждают.

Здесь обсуждают нюансы разработки программ и дымоходов.