Самые старые TODO-шки
Как часто вы перекладываете задачи на будущее? Как часто делаете это в коде?
Да, такое случается. Да, это не всегда "рэд флаг".
Главная проблема — это потеря фокуса на этих задачах в workflow команды в Jire или аналогах. Со временем в проекте копится целый «кладбищенский список» комментариев, о которых никто уже не помнит — кто их добавил, какой приоритет, в чем проблема, и какое может быть решение. По итогу, TODO-шки и FIXME-ки превращаются в незаметный археологический тех. долг.
Получается забавная ситуация... Комментарий есть, но реальной пользы никакой — только лишний шум и ощущение неустроенности в проекте.
Более мы не допускаем задачи-комменты: "Либо фикси сейчас, либо заводим задачу."
Вот вам самые забавные TODO-шки с разных проектов, самой старой стукнуло 9 лет, а от других появляется улыбка :)
Я оставил TODO, позже вернусь, доделаю, апрувните
Надо срочно в релиз!
Cейчас не лагает, потом придумаем по другому.
Как часто вы перекладываете задачи на будущее? Как часто делаете это в коде?
Да, такое случается. Да, это не всегда "рэд флаг".
Главная проблема — это потеря фокуса на этих задачах в workflow команды в Jire или аналогах. Со временем в проекте копится целый «кладбищенский список» комментариев, о которых никто уже не помнит — кто их добавил, какой приоритет, в чем проблема, и какое может быть решение. По итогу, TODO-шки и FIXME-ки превращаются в незаметный археологический тех. долг.
Получается забавная ситуация... Комментарий есть, но реальной пользы никакой — только лишний шум и ощущение неустроенности в проекте.
Более мы не допускаем задачи-комменты: "Либо фикси сейчас, либо заводим задачу."
Вот вам самые забавные TODO-шки с разных проектов, самой старой стукнуло 9 лет, а от других появляется улыбка :)
20❤8🔥5
Media is too big
VIEW IN TELEGRAM
UI разработка не востребована
В последнее время всё чаще можно услышать, что полноценная работа с UI уже не так востребована: бигтехы вовсю используют бдуй, а компании поменьше «красят» кнопки на SwiftUI. И те, и другие время от времени ковыряются в багах и костылях технологий и фреймворков — еще и делают это непринуждённо, попивая смузи и коммитя строки от курсора.
Отдельно вспоминаются коллеги, которые и вовсе уверены: UIKit — легаси, а начиная с iOS 19 вообще же все depreceted? Ну и что, что скролл где-то подлагивает? Вы что, ещё на UIKit пишете?!
Спорить с такими сложно, да и бесполезно. Действительно, есть те, кто перекладывает JSON-ы для бдуя, а кто-то успешно поддерживает SwiftUI-приложение и не знает особых хлопот.
Для меня же создание сложного и красивого UI — это настоящая дофаминовая бомба
Какие критерии хорошего UI?
- Плавные переходы состояний.
- «Физическая» природа анимаций.
- Приоритет жестов над тапами.
- Простота интеграции новых экранов и элементов.
- Высокая степень кастомизации.
- Высокая степень оптимизации и низкое энергопотребление.
Что ж, мне остается радоваться, что находятся проекты (спасибо iss), в которых разработчику сталкивается с вызовом, сделать хорошо, сделать стильно, сделать удобно.
Что крутого из UI мы реализовали в нашем последнем проекте:
- Лучший BottomSheet, еще и в Open Source.
- Навигационный стек поверх карты (child UINavigationController с пробросом жестов ниже — попробуйте на досуге).
- 9 видов transitions между экранами (3 push, 3 pop, 3 swipe pop).
- Pop swipe с любой части экрана (как в Telegram): погружаемся в UIGestureRecognizerDelegate и hitTest, а там пересекающиеся PanGestures, UIScrollView, так еще и нелинейная анимация в UIPercentDrivenInteractiveTransition.
При этом практически весь контент внутри bottom sheet-ов реализован на SwiftUI, и у этого тоже свои «приколы»: мы ломали SwiftUI как могли (для ознакомления вот бамп, бамп).
Для меня iOS-разработка — это в первую очередь про UI. Крутая архитектура, DI, многомодульность, с плохим UI не имеет смысла. И да, без UIKit пока никуда :)
П.С.
- Я намеренно не касаюсь здесь архитектуры приложения, хотя интерфейс напрямую влияет и на подкапотные части — так или иначе, от жизненного цикла приложения и экранов всё равно никуда не деться.
- Я намеренно не касаюсь коммерческой части разработки, в рамках которой прибыль > код. На канале я/мы растем, как кодеры :)
В последнее время всё чаще можно услышать, что полноценная работа с UI уже не так востребована: бигтехы вовсю используют бдуй, а компании поменьше «красят» кнопки на SwiftUI. И те, и другие время от времени ковыряются в багах и костылях технологий и фреймворков — еще и делают это непринуждённо, попивая смузи и коммитя строки от курсора.
Отдельно вспоминаются коллеги, которые и вовсе уверены: UIKit — легаси, а начиная с iOS 19 вообще же все depreceted? Ну и что, что скролл где-то подлагивает? Вы что, ещё на UIKit пишете?!
Спорить с такими сложно, да и бесполезно. Действительно, есть те, кто перекладывает JSON-ы для бдуя, а кто-то успешно поддерживает SwiftUI-приложение и не знает особых хлопот.
Для меня же создание сложного и красивого UI — это настоящая дофаминовая бомба
Какие критерии хорошего UI?
- Плавные переходы состояний.
- «Физическая» природа анимаций.
- Приоритет жестов над тапами.
- Простота интеграции новых экранов и элементов.
- Высокая степень кастомизации.
- Высокая степень оптимизации и низкое энергопотребление.
Что ж, мне остается радоваться, что находятся проекты (спасибо iss), в которых разработчику сталкивается с вызовом, сделать хорошо, сделать стильно, сделать удобно.
Что крутого из UI мы реализовали в нашем последнем проекте:
- Лучший BottomSheet, еще и в Open Source.
- Навигационный стек поверх карты (child UINavigationController с пробросом жестов ниже — попробуйте на досуге).
- 9 видов transitions между экранами (3 push, 3 pop, 3 swipe pop).
- Pop swipe с любой части экрана (как в Telegram): погружаемся в UIGestureRecognizerDelegate и hitTest, а там пересекающиеся PanGestures, UIScrollView, так еще и нелинейная анимация в UIPercentDrivenInteractiveTransition.
При этом практически весь контент внутри bottom sheet-ов реализован на SwiftUI, и у этого тоже свои «приколы»: мы ломали SwiftUI как могли (для ознакомления вот бамп, бамп).
Для меня iOS-разработка — это в первую очередь про UI. Крутая архитектура, DI, многомодульность, с плохим UI не имеет смысла. И да, без UIKit пока никуда :)
П.С.
- Я намеренно не касаюсь здесь архитектуры приложения, хотя интерфейс напрямую влияет и на подкапотные части — так или иначе, от жизненного цикла приложения и экранов всё равно никуда не деться.
- Я намеренно не касаюсь коммерческой части разработки, в рамках которой прибыль > код. На канале я/мы растем, как кодеры :)
Когда думаешь, что написал код с лучшими O(n), вспомни про сына маминой подруги, который всё решил за 5 строчек с рекурсией и с внешней переменной.
Задача с LeetCode
P.S. Оба решения бьют 100% по runtime
Задача с LeetCode
P.S. Оба решения бьют 100% по runtime
🗿7💯2🌚1
От меня бегут разработчики
на собеседованиях...
И немного о накрутке опыта
Два заголовка сразу, мощно?
Для нашего приложения Dhamer (транспортное приложение для города Мекка) мы в темпе искали нового iOS-разработчика: проект горел, времени на углубленную проверку по всем фронтам особо не было. Моей задачей было оперативно найти практика, поговорить об опыте, состыковаться и поскорей начать работать – минимум теории, just do iOS.
Кандидат №1:
Кандидат уверенно рассказывал, как на прошлом проекте за полгода полностью переделал навигацию – заменил какие-то запутанные роутеры и координаторы на (естественно) "удобные". Я начал задавать соответствующие вопросы: как устроены ссылки между контроллерами и координаторами, кто кого держит, где используются сильные, а где слабые ссылки. Но в ответ – путаница, неуверенность, противоречия, retain cycle-ы на каждом предположении, это вызвало у меня некоторую настороженность.
Перешли в лайвкодинг. Я попросил набросать базовые классы навигации в его решении, роутер бахнуть, ну или координатор (Ибо реализацию на слух я так и не понял).
Кандидат пишет одну строчку:
Думает 1 минуту… И просто выходит из Zoom. Больше на связь не вышел. "Ну, не по пути"
Кандидат №2:
Буквально следующий собес, минимум теории, обсуждение опыта. Вновь детали не помнит, да и вообще, все по классике, что обсуждать. Уже и не помню, на каком вопросе про опыт, но кандидат без слов ливает с собеседования с концами. "А может токсик на собеседующем?"
Кандидат №3:
Заряженный мидл, готовый сделать с нами новое крутое приложение. Да вот не задача, в резюме у него 3 года опыта над нашим (буквально) приложением Добро.РФ, да и в разделе компания также мы ISS, прямо в hh резюме, я даже не поверил нашему hr-у, пока сам не убедился. К слову, на этапе hr-a его и завернули, ибо с нами он не работал, но пообщаться было бы интересно. Может, поставил бы личный рекорд — три сбежавших кандидата за 1 день.
Может, история была интересней, если бы я нашел этих ребят на условном ОМ (раз такой хайп вокруг них сейчас) или движухе собес-паровозиков, но нет.
Так же не нулевая вероятность, что просто токсик на собеседующем затоксичел, а нормальные ребята пошли дальше.
UPD: По итогу мы сошлись с классными разработчиками, с которыми и сделали Dhamer, о чем в следующем посте ⬇️
на собеседованиях...
И немного о накрутке опыта
Два заголовка сразу, мощно?
Для нашего приложения Dhamer (транспортное приложение для города Мекка) мы в темпе искали нового iOS-разработчика: проект горел, времени на углубленную проверку по всем фронтам особо не было. Моей задачей было оперативно найти практика, поговорить об опыте, состыковаться и поскорей начать работать – минимум теории, just do iOS.
Кандидат №1:
Кандидат уверенно рассказывал, как на прошлом проекте за полгода полностью переделал навигацию – заменил какие-то запутанные роутеры и координаторы на (естественно) "удобные". Я начал задавать соответствующие вопросы: как устроены ссылки между контроллерами и координаторами, кто кого держит, где используются сильные, а где слабые ссылки. Но в ответ – путаница, неуверенность, противоречия, retain cycle-ы на каждом предположении, это вызвало у меня некоторую настороженность.
Перешли в лайвкодинг. Я попросил набросать базовые классы навигации в его решении, роутер бахнуть, ну или координатор (Ибо реализацию на слух я так и не понял).
Кандидат пишет одну строчку:
class Router {Думает 1 минуту… И просто выходит из Zoom. Больше на связь не вышел. "Ну, не по пути"
Кандидат №2:
Буквально следующий собес, минимум теории, обсуждение опыта. Вновь детали не помнит, да и вообще, все по классике, что обсуждать. Уже и не помню, на каком вопросе про опыт, но кандидат без слов ливает с собеседования с концами. "А может токсик на собеседующем?"
Кандидат №3:
Заряженный мидл, готовый сделать с нами новое крутое приложение. Да вот не задача, в резюме у него 3 года опыта над нашим (буквально) приложением Добро.РФ, да и в разделе компания также мы ISS, прямо в hh резюме, я даже не поверил нашему hr-у, пока сам не убедился. К слову, на этапе hr-a его и завернули, ибо с нами он не работал, но пообщаться было бы интересно. Может, поставил бы личный рекорд — три сбежавших кандидата за 1 день.
Может, история была интересней, если бы я нашел этих ребят на условном ОМ (раз такой хайп вокруг них сейчас) или движухе собес-паровозиков, но нет.
Так же не нулевая вероятность, что просто токсик на собеседующем затоксичел, а нормальные ребята пошли дальше.
UPD: По итогу мы сошлись с классными разработчиками, с которыми и сделали Dhamer, о чем в следующем посте ⬇️
50🙉9🌚3👍1💯1
Мы сделали Dhamer и показались на Dubai World Trade Centre
Для нашей команды разработки это уже вторая большая MaaS платформа, до этого был 🇷🇺 Московский Транспорт, теперь 🇸🇦 Dhamer. Надеюсь, что продукты и дальше будут развиваться, и впереди новые города и страны, новые вызовы и фичи, помогающие миллионам людей удобнее пользоваться различными услугами в своем городе.
Спасибо за невероятный опыт всей команде ISS и SpectralSoft, we did it!
Отдельное спасибо нашему СТО Кириллу @issdev, на котором без малого был весь процесс, порой даже и iOS📱
UPD: Часть технических вызовов и их решений на iOS все ждут статей, но я в этом деле дотошный, так что, в лучшем случае скажу: "Не скоро"
Представляем вам новейшую технологию «Мобильность как услуга» (MaaS), разработанную для создания более интеллектуальных и взаимосвязанных транспортных систем. От мультимодальных маршрутов в реальном времени до бесперебойной интеграции автопарка и платежей — мы меняем представление о городской мобильности.
Для нашей команды разработки это уже вторая большая MaaS платформа, до этого был 🇷🇺 Московский Транспорт, теперь 🇸🇦 Dhamer. Надеюсь, что продукты и дальше будут развиваться, и впереди новые города и страны, новые вызовы и фичи, помогающие миллионам людей удобнее пользоваться различными услугами в своем городе.
Спасибо за невероятный опыт всей команде ISS и SpectralSoft, we did it!
Отдельное спасибо нашему СТО Кириллу @issdev, на котором без малого был весь процесс, порой даже и iOS
UPD: Часть технических вызовов и их решений на iOS все ждут статей, но я в этом деле дотошный, так что, в лучшем случае скажу: "Не скоро"
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥9
О деньгах, мы в Forbes Russia
Почитать подробнее — Forbes Стартап-суббота
Деньги. есть.😘
Лично я за новый офис, ну или хотя-бы кресло-массажер
Онлайн-сервис для управления автопарками и оплаты автомобильных платежей «Паркоматика» привлек 55 млн рублей от Equity Club, рассказали Forbes в компании. Средства пойдут на развитие функционала платформы, расширение команды и масштабирование бизнеса в новых регионах. «Паркоматика» включает в себя мобильное приложение для водителей, электронный диспетчер задач и инструмент бизнес-отчетности, в сервис интегрированы более 20 городских автомобильных систем.
...платформу используют 700 предприятий (более 40 000 автомобилей), среди них — «Яндекс Доставка», РЖД, Lamoda и другие. Выручка компании в 2024 году составила 94,1 млн рублей, чистая прибыль — 15,4 млн рублей, следует из СПАРКа.
Почитать подробнее — Forbes Стартап-суббота
Деньги. есть.
Лично я за новый офис, ну или хотя-бы кресло-массажер
Please open Telegram to view this post
VIEW IN TELEGRAM
25
И - Известность и общая боль Structed Cuncurency
Наш любимый Swift развивается в сторону строгого паралелизма. Однако на реальных проектах и фреймворках с тоннами легаси новый подход языка не всегда успешно накладывается на кодовую базу. Более того, часть архитектурных решений просто несовместимы с новым async видением от Apple.
Например, взять популярную библиотеку Swinject,
Cама идея регистрации объектов синхронно из общего неизолированного метода в лучшем случае небезопасна. А если у вас тысячи регистраций объектов под акторами... Ммм, в скольких случаях init у вас nonisolated? Как долго компилятор и крешрейт выдержат @preconcurrency в вашем коде?
С опытом (и чаще с болью) находятся обходные пути, хаки, которые в умелых руках делают код еще и безопасным.
Одним таким кейсом я недавно поделился в более известном iOS клубе, суть которых можно глянуть тут и тут.
Что ж, возможно, пришло время записать с Львом с канал iOS Makes Me Hate второй Workshop на тему Swift 6 и Structed Cuncurency
Ориентир на конец сентября, так что, уважаемые читатели, "Как только, так сразу"!
Наш любимый Swift развивается в сторону строгого паралелизма. Однако на реальных проектах и фреймворках с тоннами легаси новый подход языка не всегда успешно накладывается на кодовую базу. Более того, часть архитектурных решений просто несовместимы с новым async видением от Apple.
Например, взять популярную библиотеку Swinject,
Cама идея регистрации объектов синхронно из общего неизолированного метода в лучшем случае небезопасна. А если у вас тысячи регистраций объектов под акторами... Ммм, в скольких случаях init у вас nonisolated? Как долго компилятор и крешрейт выдержат @preconcurrency в вашем коде?
С опытом (и чаще с болью) находятся обходные пути, хаки, которые в умелых руках делают код еще и безопасным.
Одним таким кейсом я недавно поделился в более известном iOS клубе, суть которых можно глянуть тут и тут.
Что ж, возможно, пришло время записать с Львом с канал iOS Makes Me Hate второй Workshop на тему Swift 6 и Structed Cuncurency
Ориентир на конец сентября, так что, уважаемые читатели, "Как только, так сразу"!
🔥5