Media is too big
VIEW IN TELEGRAM
Блин. Я, если честно, часто вообще не готовлюсь целенаправленно к собесам. Потому что ленив или тупо нет времени (что делать неправильно)
Оказывается, нужно еще готовиться к финальному интервью и заранее проработать сценарий разных кейсов по поведенческому интервью…
Ладно, потом это тоже разберем
Оказывается, нужно еще готовиться к финальному интервью и заранее проработать сценарий разных кейсов по поведенческому интервью…
Ладно, потом это тоже разберем
Изучаем как собирать нефункциональные требования для разработки мобильных приложений
В комментариях прошлого поста написали "почему разработчик должен задумываться о требованиях, если есть лид или аналитик?". Это очень популярное заблуждение, ему придерживался и я сам.
Во-первых, тимлид или другой менеджер — это чаще про общие стратегии на кварталы или даже годы. Если тимлид лезет в детали мобилки, бэк, фронт, то здесь много вопросов к доверию тимлида, его микроменджменту и самостоятельности инженеров.
Во-вторых, никто, кроме инженера, не сможет учесть множество особенностей своей платформы. На то он и эксперт, что взяв под ключ фичу, продумывает и подсвечивает все риски. Суть систем дизайна не сделать программу по готовой схеме от аналитиков и тимлидов. А собрать требования и подсветить их самому.
Здесь одни из требований — это нефункциональные требования.
Эти требования не говорят ЧТО нужно сделать, а скорее КАК. Такие требования помогают сделать нашу фичу стабильной и понятной в использовании. Автор делится ключевыми требованиями для мобильных инженеров:
🟣 Performance. Как сделать приложение более плавным, быстрым.
🟣 Security. Сделать приложение более безопасным. Использовать ли HTTPS, Keychain, криптошифрование и тп
🟣 Совместимость. Обсуждение на каких версиях будет использоваться приложение.
🟣 Надежность. Нужен ли хэндлинг ошибок и их мониторинг.
🟣 Поддерживаемость. Вопрос понятности и читаемости кода, модуляризации и CI/CD.
Интересно также почитать про лучшие практики.
В комментариях прошлого поста написали "почему разработчик должен задумываться о требованиях, если есть лид или аналитик?". Это очень популярное заблуждение, ему придерживался и я сам.
Во-первых, тимлид или другой менеджер — это чаще про общие стратегии на кварталы или даже годы. Если тимлид лезет в детали мобилки, бэк, фронт, то здесь много вопросов к доверию тимлида, его микроменджменту и самостоятельности инженеров.
Во-вторых, никто, кроме инженера, не сможет учесть множество особенностей своей платформы. На то он и эксперт, что взяв под ключ фичу, продумывает и подсвечивает все риски. Суть систем дизайна не сделать программу по готовой схеме от аналитиков и тимлидов. А собрать требования и подсветить их самому.
Здесь одни из требований — это нефункциональные требования.
Помимо функционала, важны характеристики, определяющие качество приложения — производительность, безопасность, масштабируемость, удобство использования и т.д.
Эти требования не говорят ЧТО нужно сделать, а скорее КАК. Такие требования помогают сделать нашу фичу стабильной и понятной в использовании. Автор делится ключевыми требованиями для мобильных инженеров:
Интересно также почитать про лучшие практики.
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Mastering Non-Functional Requirements for Mobile Application Development
Introduction
Forwarded from Тимур Тибеев | BigTechDream (Timur Tibeyev)
Мой коллега, Geoffrey Huntley Staff SWE at Canva, написал статью “Dear Student: Yes, AI is here, you're screwed unless you take action…” или “Дорогие студенты: AI уже здесь и вы попали, если не предпримите действий...”
В статье говорится много о том, что мы уже затрагивали на этом канале, как изменится индустрия, как изменятся уровни и как изменятся собеседования. Приведу лишь выжимку советов студентам.
⏳ Используйте время с пользой
У вас есть около года, возможно, меньше. Большинство инженеров еще не поняли потенциал AI — вам нужно воспользоваться этим моментом, пока это не случилось. Учитесь быстрее!
📚 Освойте навыки итеративной разработки
- Создавайте свои приложения, проекты, даже если это простой todo-list.
- Учитесь писать тесты, применяйте property based testing, пишите тестируемый код.
- Научитесь настраивать CI-пайплайны (что-то, кроме GitHub Actions).
- Наловчитесь эффективно использовать SCM-инструменты, такие как Git.
- А теперь совместите все навыки и научитесь выпускать софт итеративно, используя SCM, CI и тестирование.
🔍 Не идите в стартапы
Многие стартапы пойдут ко дну после текущей вспышки интереса к AI. Ищите лишь те компании, где можно хорошо заработать и многому научиться. Имейте запас наличности на случай увольнения.
🤖 Избегайте компаний, которые запрещают AI инструменты
Не отказывайтесь от AI — это ваш союзник. Найдите компании, которые поддерживают использование AI в работе.
🌟 Стремитесь стать экспертами
Фокусируйтесь на уникальных навыках, таких как создание MCPs (систем управления моделями) — на данный момент это непаханое поле. Изучите и разберите, как работают https://github.com/block/goose и https://github.com/All-Hands-AI/OpenHands.
🔧 Учите Rust
Сейчас сообщество Rust на подъеме, и это отличное время присоединиться. Это язык, который за счет своего типа способен работать лучше с LLMs.
💼 Приносите больше пользы бизнесу
Изучите боль клиентов и найдите решение для самых значимых проблем. Учитесь думать как предприниматель и разбирать, как ваша работа приносит бизнесу выгоду.
📈 Создавайте личный бренд
Создайте личный сайт, начните делиться знаниями и участвовать в общественных мероприятиях — это ваш магнит для возможностей. Публикуйте свои разработки на GitHub и MCP инструменты на ресурсах, таких как npm или [crates.io](https://crates.io/).
🤷Что это значит, Тимур?
Сейчас пора неопределенности, никто до конца не знает, что будет завтра. Но все стабилизируется и приобретет более четкие границы.
Поэтому я согласен с Geoffrey, лучше действовать на опережение и использовать AI по максимуму для своего карьерного роста.
А так, низкий спрос + AI звучит как не самое лучшее время, чтобы быть выпускником software engineering.
https://ghuntley.com/screwed/
Please open Telegram to view this post
VIEW IN TELEGRAM
Настало время уйти от теории. В прошлых постах мы углубленно разбирали почему этап сбора требований важен. Теперь мы применим наши знания на практике.
Если вы услышали мяуканье, то это не значит, что перед вами кошка. Возможно это тигр, что разорвет вам жопу. (с) Лев Бондаренко
Задачи на корзину и списком товаров — одна из классических в систем дизайне. Например, еще до всех этих хайпов, в 2023 мы решали задачу с обновлением избранного.
Сейчас попробуем порешать и найти несколько решений в такой задаче:
В приложении Авито есть два экрана:
1. Список товаров – отображает доступные товары и их количество в корзине. Можно добавлять, изменять количество или удалять товары из корзины. Внизу есть кнопка перехода в корзину с общей стоимостью, которую присылает сервер.
2. Корзина – показывает товары, добавленные в корзину. Здесь тоже можно изменять их количество или удалять.
Когда пользователь добавляет или удаляет товар, запрос отправляется на сервер. Если запросы приходят в неправильном порядке, данные могут стать неактуальными.
Здесь нет правильного решения и финальный выбор зависит от того, какие перед вами будут ограничения и компромиссы. У каждого есть свои плюсы и минусы.
Предлагайте свои решения.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Масштабирование CI/CD для iOS
В прошлом опросе сложных задач тема CI/CD заняла предпоследнее место. Проще только алгоритмы😂
Результат опроса, на мой взгляд, — кринж. Аудитория посчитала, что CI/CD и алгосы проще краски кнопок и анимаций. С этими тезисами я готов драться на ножах.
Но этот пост о другом. Автор доклада поделился отличным опытом настройки очень важной темы. Разработка таких систем как CI/CD требует множества разных скиллов связанных не только с мобильной платформой. Это полноценная mob.devops специальность, где рынок очень ценит таких разработчиков и готов щедро им платить.
Если вы хотите самостоятельно погрузиться в эту тему, то этот доклад выглядит интересным для основ.
В прошлом опросе сложных задач тема CI/CD заняла предпоследнее место. Проще только алгоритмы
Результат опроса, на мой взгляд, — кринж. Аудитория посчитала, что CI/CD и алгосы проще краски кнопок и анимаций. С этими тезисами я готов драться на ножах.
Но этот пост о другом. Автор доклада поделился отличным опытом настройки очень важной темы. Разработка таких систем как CI/CD требует множества разных скиллов связанных не только с мобильной платформой. Это полноценная mob.devops специальность, где рынок очень ценит таких разработчиков и готов щедро им платить.
Если вы хотите самостоятельно погрузиться в эту тему, то этот доклад выглядит интересным для основ.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Scalable Continuous Integration for iOS | Swift Heroes 2024 Talk
🎟️ 2025 Edition 8-9 April, Turin: https://swiftheroes.com/2025/tickets/
⏩ Chapter:
00:00 Intro
03:41 CI/CD system
07:13 Solutions
10:39 Workers solutions
13:39 ClickOps vs IaC
14:39 Setup via ClickOps
19:14 Setup via IaC
21:43 AMI creation in Packer
24:33…
⏩ Chapter:
00:00 Intro
03:41 CI/CD system
07:13 Solutions
10:39 Workers solutions
13:39 ClickOps vs IaC
14:39 Setup via ClickOps
19:14 Setup via IaC
21:43 AMI creation in Packer
24:33…
Media is too big
VIEW IN TELEGRAM
Главные навыки сеньорности — автономность и оценка сроков. Для этого нужна глубина и насмотренность. Сеньор на опыте заранее на уровне чуйки может ожидать где будут сложности.
В этой подборке мы не будем подробно разбирать большие фичи.
В ней будут точечные кейсы, где могут быть сложности в приложении:
Суть таких задач отличать заурядную задачу от потенциально проблемной.
Please open Telegram to view this post
VIEW IN TELEGRAM
Читаю книгу «искусство спора. Как читать книги» и поражаюсь актуальности и качеству многих взглядов.
Крепкое чувство, как за почти 100 лет с написания книги, техника споров и чтения книг в массовой среде не то чтобы не развилась, а деградировала.
В ит стоит дичайшее заблуждение, что споры имеют качественные доказательства своих тезисов. А дебаты дают какую-то истину.
В действительности качество текущих споров в ит — софистика и место для демагогов.
Еще главная мысль, к которой я и сам пришел, что качество спора зависит от дисциплины ума и его качества. Тут мы и занимаемся тем, что его улучшаем.
Крепкое чувство, как за почти 100 лет с написания книги, техника споров и чтения книг в массовой среде не то чтобы не развилась, а деградировала.
В ит стоит дичайшее заблуждение, что споры имеют качественные доказательства своих тезисов. А дебаты дают какую-то истину.
В действительности качество текущих споров в ит — софистика и место для демагогов.
Еще главная мысль, к которой я и сам пришел, что качество спора зависит от дисциплины ума и его качества. Тут мы и занимаемся тем, что его улучшаем.