tgindex

YDC — Pizza Powered iOS

описание

Young Da Code 👨‍💻 Первый командный дайджест о мобильной разработке 🍕

← к каналу@YoungDaCode
246
подписчиков
Охват к подписчикам
179,3%
ERR
Реакции к просмотрам
1,79%
312 на 50 постов
Пересылки к просмотрам
1,85%
322
Постов в день
0,0
всего 57

Где отзываются чаще

доля реакций к просмотрам
  • 18 нояб.без подписи7,51%
  • 9 нояб.без подписи5,49%
  • 27 янв.😄 Что такое модульность и когда она нужна? Модульность это разделение кодовой базы на четко очерченные, изолированные единицы с явными границами ответственности. Каждый модуль имеет публичный интерфейс, скрывает внутреннюю реализацию и может эволюционировать независимо. Модульность нужна не всегда. Для небольших проектов и прототипов она часто создает лишние накладные расходы. В этом случае простота и скорость может быть важнее архитектурной чистоты. Но когда продукт стабилизируется и становится ясно, что кодовая база будет расти, модульность помогает управлять сложностью, задает границы владения кодом и предотвращает деградацию в тесно связанный монолит. Проектирование структуры до написания кода Архитектуру стоит продумывать до начала реализации, а не по ходу роста проекта. Простая диаграмма модулей помогает определить границы, проясняет зависимости, снижает количество реактивных решений позже. Начинать рекомендуется с базового слоя: общие модели данных, сетевой слой, фундаментальные сущности. Раннее формирование этого слоя снижает риск болезненных переделок в будущем. Три основные категории модулей 🛠️ Foundation-модули содержат общие модели, примитивы, инфраструктурные компоненты. Они не зависят ни от чего выше по иерархии и используются практически везде. Также они не должны содержать пользовательские сценарии. 🧰 Service-модули содержат переиспользуемую логику и сервисы. Они зависят от Foundation и используются фичами. Foundation-модули никогда не должны зависеть от Service-модулей, это нарушает иерархию. 🚚 Feature-модули содержат пользовательские сценарии (онбординг, оплата, профиль и т. д.). Они могут зависеть от Foundation и Services, но не должны зависеть друг от друга. Горизонтальные связи между фичами быстро разрушают архитектуру и возвращают монолитные проблемы. Модульность ради модульности Внедрение модульности как модного веяния без должного проектирования ведет к проблемам при которых возникают циклы зависимостей, универсальные сервисы, раздутые публичные API. В долгосрочной перспективе растет технический долг, а кодовую базу становится поддерживать труднее чем монолит. Хотя определенные плюсы все равно будут присутствовать. Будет меньше конфликтов на мержах и ускорится параллельная разработка. 📎 Modularity as an Architectural Choice #D #Arch #Modularity #Clean 👏5,08%
  • 17 нояб.🚀 Мажорное обновление Homebrew — 5.0! Команда выкатала крупный релиз, того самого пакетного менеджера, через который многие из нас ставят себе всё рабочее окружение. Что нового? ⚡ Параллельные загрузки: Brew теперь скачивает зависимости и пакеты быстрее, по умолчанию. 🛡️ Обновлена поддержка: Tier 1 = платформы, для которых команда гарантирует полную, стабильную поддержку и на которых тестируется всё. Теперь в Tier 1 входят: • macOS на Apple Silicon • macOS на Intel (пока ещё живёт) • Linux ARM64/AARCH64 — важный шаг, учитывая рост ARM-серверов и одноплатников. 🧬 Но, определен постепенный отход от Intel/x86_64: Это ожидаемо: Apple уходит в ARM → Brew синхронизируется. Поддержка x86_64 остаётся, но уже как наследие, не как главная платформа. 🤖 Появился MCP-сервер: Homebrew подружился с Model Context Protocol. Это ускоряет интеграцию локальных AI-инструментов с brew. 🔒 Безопасность: важное изменение: Все cask-контейнеры, которые не проходят проверку Gatekeeper, будут отключены в сентябре 2026 года. Это серьёзный шаг в сторону безопасности экосистемы: меньше неподписанных бинарей → меньше рисков. 🧰 Какие альтернативы? Если вы ищете более «мягкого» менеджера инструментов, то обратите внимание на mise. Он отлично подходит для проектов, где важно стандартизировать версии тулов и держать их рядом с кодом, а не глобально в системе. Но Homebrew остаётся удобным универсальным вариантом для локальной разработки. А вы какими пакетными менеджерами или доставщиками инструментов пользуетесь в своих проектах? 👇 #L #Homebrew #CI 👏4,60%
  • 6 февр.🤖 📡 Базовые протоколы клиент-серверного взаимодействия (без обратной связи) Хочется сделать серию постов по основам CS и system-design. Если будет отклик, масштабируем в mind-map. И начать хочется с сетевого взаимодействия. Когда мы говорим про клиент-серверные запросы в большинстве приложений, мы почти всегда имеем в виду модель request → response. Важно сразу зафиксировать: это не всегда про HTTP, хотя на практике часто выглядит именно так. В первом посте разберём основные стили взаимодействия, которые используются для однонаправленных запросов с ответом. 📌 Немного про транспорт: - SOAP — почти всегда поверх HTTP/HTTPS - REST — по определению строится поверх HTTP - GraphQL — чаще всего поверх HTTP, подписки через WebSocket (но об этом можно глубже, в другом посте) - RPC — не обязан использовать HTTP 👉 Поэтому корректнее говорить не «HTTP-протоколы», а API-стили / протоколы поверх разных транспортов. Небольшая затравка из практики: В бородатых годах я использовал Apache Thrift на Objective-C — тогда для меня это был "магический" опыт с RPC: отличный кодген, строгие контракты, минимум ручной работы. Это был классический пример RPC-подхода, задолго до хайпа gRPC, и он отлично показывал разницу между: - «я работаю с ресурсами» (REST) - и «я вызываю удалённые методы» (RPC) Детальнее про протоколы: 🔹 SOAP (Simple Object Access Protocol) Что это: Строгий протокол обмена сообщениями, основанный на XML и формальных контрактах (WSDL). Транспорт: почти всегда HTTP Когда применять: - корпоративные и интеграционные системы - среды с жёсткими требованиями к контрактам, безопасности и совместимости Почему: SOAP — это максимум формализма: строгая схема, строгие правила, минимум свободы. Цена — высокая сложность и избыточность. 📍 SOAP — это «корпоративный стандарт», а не инструмент скорости. 🔹 REST (Representational State Transfer) Что это: Архитектурный стиль, завязанный на HTTP, где всё крутится вокруг ресурсов и их состояний. Транспорт: HTTP. Когда применять: - CRUD-сценарии - публичные API - системы, где важны кэширование, простота и масштабируемость Почему: REST максимально использует возможности HTTP: методы, статусы, cache-control. Он прост, прозрачен и отлично поддерживается инструментами. 📍 REST — дефолтный выбор, если нет веской причины делать иначе. 🔹 GraphQL Что это: Язык запросов и runtime, где клиент сам описывает, какие данные ему нужны. Транспорт: - чаще всего HTTP - иногда WebSocket (но это уже про real-time) Когда применять: - сложные графы данных - разные клиенты с разными требованиями к payload - желание сократить количество запросов Почему: GraphQL снимает проблему overfetching/underfetching, но усложняет сервер и наблюдаемость. 📍 GraphQL — про гибкость клиента, а не про простоту системы. 🔹 RPC (gRPC, Thrift, JSON-RPC) Что это: Удалённый вызов процедур: клиент вызывает метод, сервер его исполняет. Транспорт: не привязан к HTTP - gRPC — HTTP - Thrift — TCP / HTTP / custom transport Когда применять: - межсервисное взаимодействие - высокая производительность - чёткие контракты и кодогенерация Почему: RPC ближе к обычному программированию: вызвал метод — получил результат. Это эффективно, но хуже ложится на публичные API и браузный мир. 📍 RPC — лучший выбор для внутренних систем и платформенных API. #L #Network #HTTP #TCP #REST #SOAP #GraphQL #RPC 👏4,58%
  • 18 нояб.без подписи4,44%
  • 16 дек.без подписи4,15%
  • 5 дек.🤓 Когда ~10 лет назад я начинал в разработке на ASP.NET, на бэке мы много работали с БД и активно использовали Specification + Repository. Это давало магическое ощущение: типобезопасно, без строковых SQL-запросов, удобно фильтровать и получать данные. Чтобы понять всю механику работы, я тогда потратил не один день на чтение документации и мучения ведущего разраба, но кайф от подхода был огромный. Позже я пытался воспроизвести то же на Symfony + PHP, и почувствовал огромную разницу работы: другие абстракции, ActiveRecord по всему проекту… В итоге (менее типизированный) почти-голый SQL на PHP, как ни странно, работал кратно быстрее, чем ASP.NET со спецификациями. На то было много причин, от местоположения арендованных серверов, до специфики работы паттернов и фильтрации, сейчас не об этом. Когда я пришёл в мобилку, первый проект тоже был с БД, и я долго объяснял тимлиду, почему типобезопасный доступ к данным - топ. На самом деле я просто хотел того же опыта, той же предсказуемости. И вот теперь — появился #Predicate, который по сути является макросом над NSPredicate. То есть всё те же плюсы типобезопасности + читабельности, но без существенного падения перформанса, по идее (посмотрим на практике). В целом, макросы всё глубже прорастают в Swift-разработку — и, имхо, делают нашу жизнь сильно лучше. #L #SwiftData #Predicate 👏4,10%
  • 26 нояб.без подписи4,00%
  • 11 нояб.без подписи4,00%
  • 21 янв.😄Рубрика кликбейт или "потраченного времени жаль" Листал свой фид, искал вдохновение о чем бы написать в канал и нашелся, на первый взгляд, идеальный кандидат на первый пост в этом году от меня О чем: Swift заменил Objective-C не потому, что тот был стар, а потому, что developers were the bottleneck 🎯Какие тейки: • разработка была секретна • в iOS 15.1 16 из 22 фиксов были связаны с управлением памятью = дорого для Apple (из-за регуляторных затрат) • в целом ошибки при работе с памятью стоили Apple $67 ярдов • последние фичи в Obj-C были как раз для совместимости с Swift 🚀В Swift Apple сняла значительную часть рисков с разработчиков (на самом деле с себя) и переложила на компилятор: • Снесла (почти) Message dispatch = меньше проверок в runtime • В целом система типов стала жестче • В Swift Concurrency отдали компилятору разгребать Data Races = убрали самый сложный тип багов • Синтаксис приведен ближе к модным Python/JS и тд = больше вкатунов 🤔 От себя В целом, история звучит складно, но • откуда тейк про 67 ярдов - не понятно, just trust bro • не припомню, чтобы по статистике от OWASP мобилки сильно страдали от memory management, как будто в топе были иные проблемы (можно вспомнить про Dirty-COW, но насколько она эксплуатируема в мобилках - инфы нет) • раз была серьезная проблема, то почему так мало персонала было привлечено к разработке и релиз состоялся только через 4 года? "Небизнесовый" подход какой-то, тот же Go за год-два сварили (чую "это другое", спорить не буду) ну и добило меня Java had solved memory safety with garbage collection — but the unpredictable pauses were unacceptable for iOS’s fluid 60fps animations как будто у дроид-коллег были большие проблемы с 60fps анимациями именно из-за сборщика мусора, напишите в комменты 🍿 По итогу ощущение такое... то-ли кликбейт, то-ли нейронка написала (длинных "—" много, да, это косвенно), грустно 😭 🍕А выводы то какие? А вот выводы автор делает как будто в отрыве от всей остальной статьи, они довольно универсальные 👉 Кооперируйтесь с компилятором - переложите на него больше работы, уменьшив число проверок в runtime 👉 Подходите к коду осознанно 👉 Код должен быть максимально явным, не допускайте двусмысленности 👉 Используйте систему типов для описания бизнес логики (отсылка на Domain Driven Design - там это важная часть) и от себя ⚡️Думайте критически, в эпоху нейронок важно фильтровать базар контент 👏 #M #Swift3,82%
  • 14 янв.без подписи3,48%