🍏 Сбор заявок для закрытой беты

В общем, желающих стало больше, чем ожидалось. Писать каждому в лс и ждать ответа будет долго и дорого. Поэтому вот форма

От вас нужно только:
1. email с привязанным к нему icloud
2. имя + фамилия
3. ник в телеграме для связи и уточнений

НЕ ПИШЕМ ЭТО В КОММЕНТАРИИ. СЮДА

💎 Старт беты официально начат

Сорри, что так долго. Учился делать гифку в афтер эффекте.

Итак, голодные игры начались, епта. Всем отправившим инфу скоро придет на почту приглашение в тестфлайт. Скачайте его заранее.

В первой версии будет 2 функции:
- Тесты. Они будут на время и с испытанием
- Материалы. Там можно изучить разные статьи

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

Сразу заложим вектор чего ожидать и нет. Это приложение не будет иметь цель слепой зубрежки. Идея — выжить (и выжать) из мобильного устройства все возможности для комфортного и приятного обучения и тренировок. Возможно, и игру напишем в будущем со сценарием...

Каждое испытание должно челенджить и иметь последствия. Ваш фидбэк будет приветствоваться

Заявки можно докидать сюда

💸 Средняя зп иос-ника — 280к

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

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

https://getmatch.ru/salaries/ios

💡YAGNI — «Вам это не понадобится»

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

Обычно о нем говорят так: "Это позволяет вести разработку, руководствуясь экономическими критериями — Заказчик не должен оплачивать ненужные ему функции, а разработчики не должны тратить своё оплачиваемое время на реализацию того, что не требуется".

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

Как заметили в предыдущем посте про KISS, то они с YAGNI очень похожи. Но все же есть отличия.

Если KISS нацелен на упрощение и полезен в плане работы с теми требованиями, которые имеют место быть, то YAGNI более категоричен и применяется для ограждения проектов по разработке ПО от «размывания» их рамок.

❕ Подход к реализации проектов строго по ТЗ верен с нескольких ракурсов. Заказчик не должен платить за то, что ему не надо, а продукт должен быть максимально сопровождаем и его качество не должно страдать от интеграции ненужных функций.

📔 "Чистая архитектура" Р. Мартин

Почему книги Мартина такие популярные? Быть может дело в его форме подачи. В простых вещах. Высоких стандартах. Хз.

Её я впервые взял 5 лет назад еще до начала разработки на iOS. Тогда я писал на Node.js и React. Изучал SOLID и микросервисную архитектуру.

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

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

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

#books

По каким причинам система может решить убить приложение?

🟢 lvl: jun+

Удивительно, но многие часто ограничивают свои знания о сбоях в приложениях только force unwraping'ом или дедлоком. Простой вопрос "По каким причинам у нас может вылететь приложение?" вызывает панику.

У эйпл есть куча материалов. Пройдемся по базе:

Aborts (Abnormal Exits) — Это обычно происходит, когда апка сталкивается с вызовом abort(). Чаще это какое-то нежелательное поведение или assert.

Memory Limit — ну тут все просто, память переполняется и происходит крэш

Bad Access — Неправльный доступ к памяти. Например, попытка обратиться к несуществующему индексу массива.

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

App Watchdog — внутри системы есть таймер, который определяет время запуска нашего приложения. И, если майнтред отвечает слишком долго, то происходит принудительное завершение апки

Memory Pressure — иногда апка может сдохнуть, если находится в бекграунде и при этом используемому приложению потребуется больше памяти. Тогда система завершает свернутые в фон приложения.


- Почему мое приложение убивается?
- Причины заверешения работы апки