Разработка мобильных приложений *

Нам нужно сделать что-то вроде IT-профсоюза чтобы защитить людей от произвола работодателей, нанимателей и продавцов курсов.

Так как дело обстоит сейчас - никуда не годится.

IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.

Понятное дело что мы уже попривыкли к такому обращению, но разве нас это устраивает?

Меня - нет.

Причем страдаем не только мы - трудяги, но и сами наниматели и работодатели, потому что все мы в одной лодке.

Сейчас на рынке труда разработчики грызутся между собой за кость щедро брошенную со стола "хозяина". Ситуация напоминает описанную в теории игр "Дилемму заключенных"(там где про равновесие Нэша), когда напарники действуют друг-другу и себе в минус, и выигрывает всегда 3-я сторона, из-за того что напарники не имеют возможности общаться друг с другом.

Но мы то не заключенные, мы то слава богу свободные!

И у нас есть возможность общаться друг с другом и договариваться для получения обоюдовыгодных результатов.

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

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


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

Вспомнил холивары на первой работе на тему: что такое Activity?

Тогда, среди Android-разработчиков, в моде была MVC и общение было примерно такое:

"Activity - это контроллер" - говорили одни.

"Activity - это вью" - говорили другие.

"Activity - это модель" - так к сожалению никто не говорил, иначе было бы еще интереснее 😁

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

Кто из них прав?

Никто.

Или и те и другие.

Правильный же ответ такой:

Я создатель приложения и какую роль я дам этому классу(Activity) такую он и будет выполнять.

Это если смотреть со стороны архитектуры приложения.

А если смотреть со стороны OS Android, то Activity - это интерфейс через который пользовательское приложение взаимодействует с операционной системой.

Вот и всё :)

P.S. А какие холивары вспоминаются вам?)

Размышления визионера про идеи, задачи и реализацию:

Сначала появляется задача, запрос.

Затем появляется идея как эту задачу реализовать, ответ, наводка, подсвеченное решение.

Реализация идеи - это уже другая задача.

Т.к. запрос ставится обычно на конечное, сформированное решение, то в ответе тоже показывается сформированное решение.

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

И этот шаг не обязательно реализация продукта. Это может быть и использование уже чего-то существующего.

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

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

P.S. можно потренироваться на поисковых запросах, промтах к нейронкам и на задачах людям 😁

RCS (Rich Communication Services) — это эволюция SMS/MMS, протокол, который мобильные операторы и Google продвигают как «мессенджер по умолчанию». Если SMS = plain text, то RCS = полноценные интерактивные сообщения с кнопками, каруселями, картинками, видео, QR-кодами и встроенной аналитикой.

Ключевые моменты

• Протокол: работает поверх IP, а не через старую SMS-сеть, но доставляется в «стоковое» приложение сообщений (Google Messages, Samsung Messages).

• API: доступ через Google Jibe Hub (фактически, центр маршрутизации), плюс нужно согласование с операторами. Прямо в код «в лоб» не залезешь — всё через провайдеров/агрегаторов.

• Безопасность и доверие: каждая компания-отправитель проходит верификацию бренда, чтобы на экране у пользователя сообщения выглядели не как «спам», а с логотипом и цветами бренда.

• UX: разработчик не отправляет просто текст, а собирает карточку или интерактив через шаблон/SDK → пользователю приходит сообщение, похожее на push или мини-приложение внутри SMS.

То есть RCS = «SMS на стероидах», но с кучей бизнес- и бюрократических ограничений. Главная боль — доступ к API и вся регуляторка, поэтому на рынок вышли «коробочные» сервисы (как Smobi), которые берут эти сложности на себя

Кодик и ссылки у меня в канале

——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура

Первая в России конференция про ускорение разработки с помощью ИИ: реальные кейсы, судьба разработчиков и риски спагетти-кода

На Хабре до сих пор спорят про пользу вайбкодинга и вымирание профессии программиста. Тем временем бигтех уже использует AI-агентов, которые берут на себя больше, чем написание кода. В T-Tech они ведут задачи в SDLC и общаются друг с другом без дейликов, а Яндекс и Магнит обучают агентов управлять продуктами без человека. Это не эксперименты, а рабочий продакшн: релизы не откладываются на месяцы, счет идет на дни. 

Мы в Surf собрали на одной площадке тех, кто уже живёт в этой новой реальности: CTO, QA-лидов, техдиров и исследователей из Яндекса, Ozon, Surf, Сбера, T-Tech и других. Они расскажут и покажут всю подноготную своих проектов с ИИ 3 октября, на первой в России конференции по ускорению разработки с ИИ AI Boost 2025 в Москве.

О чем расскажут на встрече:

• Евгений Сатуров, CTO Mobile Surf покажет, как обучить вайбкодингу полсотню разработчиков и при этом не нажить врагов в команде.

• Александр Поломодов, технический директор T-Tech расскажет, когда автономные ИИ-агенты становятся полноценными участниками SDLC и начинают взаимодействовать друг с другом. Разберём переход от привычных AI-ассистентов вроде Cursor к ИИ-агентам.

• Мария Лещинская, Head of QA в Surf и кандидат технических наук по ИИ и ML объяснит, как shift-left подход и автогенерация автотестов помогают ускорять delivery и повышать качество продукта.

• Александр Коренев, руководитель IT-проектов в Банке «Левобережный» поделится кейсом внедрения ИИ в банковские проекты с нуля: от обучения персонала до автоматизации рабочих процессов.

• Альбина Галлямова, социобиолог из НИУ ВШЭ поделится научной подоплекой: выживут ли «обычные» разработчики в мире, где нейросети берут на себя всё больше задач?

Докладами не ограничимся — собрали экспертов на круглые столы, где обсудим самые горячие вопросы: 

1. «Внедрение ИИ vs Безопасность»
   Эксперты из Ozon, Сбера, Positive Technologies и Surf обсудят, как сочетать скорость релизов с безопасностью, где прячутся уязвимости AI-решений и зачем компании вводят ограничения на LLM.

2. «ИИ в продакшн: спасение или новый спагетти-код?»
   Представители Магнита, Яндекса, Surf и Атол расскажут, как нейросети ускоряют релизы, можно ли доверять им архитектуру и сложные задачи и как можно в этих условиях вырасти от джуна до тимлида.

Кому будет полезно:

• C-level и руководителям разработки — если ищете способы прокачать delivery и эффективность команд.

• Тимлидам и senior-разработчикам — если хотите разгрузить команду от рутины, улучшить качество кода и внедрить AI-практики в ежедневную работу.

• Продуктовым и проектным менеджерам — если планируете AI-проекты и хотите понимать, как реалистично оценивать сроки, риски и ресурсы на AI-разработку.

• ИИ-энтузиастам — если хотите разобраться и перенять лайфхаки по работе с ИИ для себя и своих проектов. И неважно, джун вы или сеньор. 

Формат и участие

Конференция пройдет 3 октября (пятница) в Москве, локация — ДК Рассвет. Начало в 12:00. Вас ждет 9 часов контента, нетворкинга и новых идей для своих проектов. А еще — возможность получить бесплатную консультацию с CTO Surf по внедрению ИИ-процессов в своих проектах.

По ссылке — регистрация и подробная программа.

🔥 Дарим специальный промокод для хабровчан со скидкой 2000 руб.: surfhabr

До встречи ;) 

Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)

Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.

Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:

(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )

1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.

2. "Strategy" - когда ты описываешь объекты как будто смотришь на описываемую систему снаружи (вид сверху), фокус на процессы взаимодействия всех объектов в жизненном цикле приложения, моделируются в первую очередь процессы и упускаются сущности.

3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)

И так же я пришел к тому что есть несколько слоев моделирования\проектирования:

(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)

1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)

2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие

3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие

(правила взаимодействия могут быть явными и неявными, когда мы описываем объекты классами с методами и функциями, по сути мы уже задаем правила и зависимости объектов, но иногда для удобства мы можем вынести эти правила в отдельные абстракции и интерфейсы, чтобы задать рамки, границы использования однородных классов и абстрагироваться от конкретной реализации, и потом удобно переиспользовать повторяющиеся действия в процессе выполнения)

На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.

К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.

Такие дела :)

Я по прежнему считаю что ООП рулит! 😁

А что думаешь ты про ООП, архитектуру и чистый код?

Делись своим опытом в комментариях, или нет..

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

Строить приложение от архитектуры - такое себе. Архитектура для приложения, а не приложение для архитектуры. Тогда архитектура будет основана на реальных задачах а не на поиске идеала.

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

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

Т.е. решение кроется в здравом смысле - описываешь приложение плюс-минус понятными человеку структурами и нужная связность и связанность образуются сами собой как следствие.

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Под капотом FinamTrade: как работает покупка акций, разработка под санкциями и будущее AI в финтехе

Привет, Хабр!

В нашем подкасте «Null на балансе» мы, как обычно, разбираем технологичные штуки на запчасти. На этот раз мы забрались в одну из самых закрытых и интересных систем — мобильный трейдинг.

У нас в гостях Борис Аксенов, руководитель управления разработки веб и мобильных приложений в «Финаме». Человек, который стоит у руля создания и эволюции FinamTrade последние 15 лет. Мы поговорили о том, о чем обычные пользователи часто не задумываются, нажимая кнопку «Купить».

О чём этот выпуск:

• Архитектура и нагрузка: Что происходит на бэкенде, в мобильном клиенте и на бирже в момент, когда вы и еще 10 000 человек одновременно отправляете заявку?

• Эволюция: Как приложение FinamTrade превращалось из простого терминала в суперапп с новостями, аналитикой и обучением? Какие технологические решения были ключевыми на этом пути?

• Боль и санкции: Самая острая тема — как изменились процессы разработки и публикации в App Store и Google Play для такого критически важного приложения в текущих реалиях? Какие инструменты и воркaунды пришли на смену привычным сервисам?

• Безопасность: Как защищаются финансовые данные и средства клиентов в эпоху мобильных угроз?

• AI и ML: Где машинное обучение и искуственный интеллект уже работают в финтехе сегодня (например, в предиктивном анализе поведения или проверке документов), а где это пока лишь хайп?

• Карьера в финтехе: Как приходят в разработку для таких высоконагруженных систем? Что мотивирует специалистов оставаться в одной компании больше 15 лет?

• А еще Борис поделился парой забавных курьезных случаев из практики и мифов о финтехе, которые заставят вас улыбнуться.

Выпуск получился по-настоящему гибридным. Он будет полезен:

1. Разработчикам и архитекторам, особенно тем, кто работает или хочет работать с высоконагруженными и отказоустойчивыми системами.

2. Специалистам по DevOps и безопасности, чтобы понять уровень требований в fintech.

3. Всем, кто интересуется карьерой в IT — история Бориса о 15-летнем пути в одной компании очень мотивирует и показывает возможный вектор роста.

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

Наш подкаст доступен на всех удобных платформах:

Youtube Music | Apple Podcast | Яндекс Музыка | Spotify | VK Музыка

Я размышлял про трудоустройство и наем, как нанять сотрудника в IT и как устроиться на работу в IT и вот к чему пришел :)

Я много встречал видео и статей "как пройти собеседование", "как получить работу" в IT.

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

По факту все сводится к семантике (привет Жаку Фреско) - каждый из нас говорит на своем языке, на языке своего опыта, на языке своего мышления, на языке своего локального карго-культа.

Или проще - люди не понимают друг-друга и только строят свои догадки относительно друг-друга.

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

О чем это говорит? О том что эйчары в заведомо выгодной позиции и диктуют условия общения. О том что эйчары не стремятся понять соискателя, найти с ним общий язык в диалоге. О том что эйчары стремятся к тому чтобы все говорили на их языке и правильно отвечали на вопрос "Расскажите о себе". Кстати, а как правильно то?) (Не все, многие)

С другой стороны, соискатели, технари, айтишники - тоже люди :)

И они так же хотят общаться привычным им способом. Они не стремятся понять нанимателя, найти с ним общий язык в диалоге. Соискатели стремятся к тому чтобы все говорили на их языке и задавали адекватные поставленным задачам вопросы, а не "расскажите о себе", и вообще, о себе они уже рассказали в резюме)). (Не все, многие)

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

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

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

Если я например хочу делать мобильные приложения, а бизнес хочет сделать себе мобильное приложение - то мы уже матчимся, подходим друг-другу для достижения наших целей, осталось только договориться о деталях. "Ты будешь делать достойное приложение 8 часов в день, 5 дней в неделю, по нашим задачам", "А ты за проделанную работу будешь платить мне достойную зарплату и содействовать в решении любых вопросов связанных с работой"

Справедлив вопрос: "а справится ли соискатель или он на словах такой герой?"
Справедлив и обратный вопрос: "а справится ли работодатель или он на словах такой герой?"

Ответ в обоих случаях очевиден: заранее неизвестно и можно только строить предположения.

Есть 3 простых способа чтобы понять, а может ли человек делать, то что он делать хочет:

1. Посмотреть на предыдущий опыт соискателя, на портфолио проектов (так же как и на предыдущий опыт работодателя, на портфолио проектов)

2. Тестовое задание, если вдруг нет портфолио, или есть сомнения по портфолио.

3. Испытательный срок, стажировка на проекте, во время которой станет действительно понятно что из себя представляет сотрудник (за одно и онбординг и притирку пройдет на лайте)

Хм.. А какое тестовое задание и испытательный срок дать работодателю? :)

(P.S. Но не один из этих способов, так же как и любые другие, не гарантирует 100% совпадения ожиданий с результатами, потому что ожидания это больше про вымысел, а результаты достигаются систематическими действиями с целью этих результатов достичь, и делают эти действия реальные люди со всеми их достоинствами и недостатками, а не идеальные кандидаты)

2ГИС на Apple Watch

Год назад мы масштабно обновили приложение для 2ГИС на Apple Watch: начали показывать на часах местоположение близких в рамках функции «Друзья на карте» и поддерживать ведение по пешему маршруту. К очередной презентации Apple решили добавить ещё полезностей. 

Теперь часы умеют вести и по маршрутам общественного транспорта — с указанием номеров маршрутов транспорта и полезными подсказками в пути. Мы сами знаем, что это особенно удобно, когда руки заняты или вокруг суета. 

Об интересных моментах реализации рассказывает разработчик Иван Гнатюк.

Маленький экран — большие задачи

Сделать маршрут общественного транспорта на часах оказалось не так уж сложно — помогли два момента: 

• Во-первых, у нас уже было приложение на watchOS 10+, где работало пешее ведение и была настроена коммуникация телефон ← → часы.

• Во-вторых, мы раньше делали отображение маршрута транспорта для Live Activity на телефоне, и смогли переиспользовать много вьюшек и бизнес-логики (а она бывает непростой).

Оставалось только собрать из уже имеющихся блоков новое отображение для часов, что мы и сделали довольно быстро. Потом мы подумали, а почему бы не сделать и новое LA для общественного транспорта на часах? Текущее отображение от Dynamic Island с телефона выглядело скучно.

Сложность в том, что мы ограничены размерами часов, причём размеры варьируются 40– 49 мм. Скролл мы здесь добавить не можем, поэтому нужно попытаться уместить весь маршрут со всеми его сегментами на маленьком экранчике, попытавшись сохранить максимум полезной информации (номер маршрута, номер выхода из метро).

На помощь пришел GeometryReader — он даёт ширину контейнера, и, зная количество и тип сегментов, мы рисуем маршрут. Если пересадок на маршруте шесть и больше, то оставляем те, что помещаются, а вместо последнего покажем «....». Но на бою нам не удалось построить такой маршрут. Если вам удастся — расскажите нам!

Разработка на настоящих часах — интересно, но непредсказуемо

Разрабатывать и собирать на настоящих часах всегда интереснее. Но с этим могут быть свои приключения. 

• Например, часы могут «отваливаться». Xcode к ним не подключается и приходится постоянно проверять настройки часов и подключение к WiFi. 

• Иногда таргет часов ни в какую не хочет устанавливаться на часы — помогает только их перезагрузка.

• А в какой то момент на часах перестал отображаться и новый LA, и простая трансляция DI. Перезагружали и часы, и телефон — ничего не помогало. Оказалось, что в какой то момент телефон обновился, а часы нет. Вот так и сломалось.

Как работает для пользователя

Для того чтобы видеть основные этапы маршрута, нужно построить маршрут на общественном транспорте в приложении на смартфоне и нажать «В путь», а на часах открыть приложение 2ГИС. В пути достаточно посматривать на часы — приложение покажет ключевую информацию с помощью Live Activities: иконки транспорта с цветом ветки метро, номер выхода, время в пути и пересадки, если они предусмотрены. Чтобы просмотреть весь маршрут, достаточно тапнуть на Live Activities и прокрутить Digital Crown.

Всё будет работать на Apple Watch с watchOS 11, iPhone с iOS 18 и в приложении 2ГИС версии 7.11 или новее. На часы отдельно ничего ставить не нужно — всё подтянется из приложения на айфоне.

Первая в России конференция про ускорение разработки с помощью ИИ

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

3 октября в Москве, в ДК «Рассвет» пройдет первая в России конференция про реальное ускорение с помощью AI. Без шаманства, без магии, без обещаний в стиле «сейчас покажу вам пару промтов в ChatGPT». Мы пригласили только тех, кто уже готов делиться конкретикой и новыми подходами в разработке с ИИ — экспертов от Яндекса, Альфа-Банка, Т-Банка и других лидеров рынка.

О чем расскажут на конференции:

• Евгений Сатуров, CTO Mobile Surf — как мы выстроили AI-boosted Delivery Platform и сделали процессы в 5 раз быстрее классического SDLC. Поговорим и про цифры: чем измерять ускорение разработки и как оценивать ROI в AI-инструменты.

• Доклады от крупных компаний: Александр Поломодов из Т-Банка, Святослав Соловьев из Альфа-Банка, Александр Толмачев (ex-Ozon Fintech) и другие мощные спикеры поделятся, как у них выстроены процессы AI-разработки. Обсудим, какие инструменты прижились, каких результатов с их помощью добились компании и как строили архитектуру проектов.

• Дискуссии AI vs. Security vs Эффективность: поговорим с экспертами от Positive Technologies, Ozon Fintech и Сбера о том, как обезопасить код и данные при тотальной автоматизации, где прячутся уязвимости AI-решений и как жить с Концепцией регулирования ИИ-2030. И ответим на вопрос — насколько ИИ влияет на скорость команд, метрики и ROI.

• Научная основа: Альбина Галлямова, научный сотрудник НИУ ВШЭ и автор проекта «Зачем мы такие?», разберет правду и мифы о возможностях искусственного интеллекта. Узнаем, как взаимодействие с LLM влияет на когнитивные способности человека.

В перерывах познакомитесь с нашим ИИ-предсказателем. Он покажет вашу профессиональную судьбу в IT и точно скажет, заменит ли вас ИИ. А после официальной части вас ждет фуршет и много общения.

Кому будет полезно?

Ждём всех, кому интересна тема ускорения разработки с помощью ИИ:

• C-level и руководителей разработки — чтобы строить полноценный AI-конвейер.

• Тимлиды и heads of dev — чтобы ускорять delivery, а не тормозить.

• Разработчики — чтобы перестать тратить дни на задачи, которые уже автоматизируются.

• PM и продакты — чтобы адекватно планировать сроки и ресурсы в AI-проектах.

Формат и участие

Конференция пройдет 3 октября (пятница) в Москве, локация — ДК Рассвет. Начало в 12:00. Вас ждет 9 часов контента, нетворкинга и новых идей для своих проектов. А еще — бесплатные консультации с CTO Surf по внедрению ИИ-процессов в вашем бизнесе.

Для участия регистрируйтесь по ссылке. Там же вы найдете программу и другие подробности.

До встречи ;) 

2ГИС зовёт на хакатон: https://hackathon.2gis.ru

4–5 октября, офлайн, Москва. Два дня, чтобы общаться, фигачить, вдохновляться и повлиять на городские сервисы!

Три трека: городские данные с ЦОДД, инклюзия с фондами «Антон тут рядом», «Продвижение», «ЛизаАлерт» и носимые устройства — часы, браслеты, AR и другие гаджеты. Будут онлайн-встречи, чтобы больше узнать про реальные задачи.

Призовой фонд: 1 000 000 рублей и шанс, что проект попадёт прямо в 2ГИС🔥

Регистрироваться можно с командой от 3 до 6 человек или самостоятельно — поможем найти команду в чате!

Я визионер, при этом занимался разработкой мобильных приложений 12 лет как технарь и вот что я выяснил для себя:

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

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

Я, например, научился разработке делая свою игру.

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

Тем кто визионер как и я могу дать совет:

Не тратьте 10 лет жизни на программирование, идите сразу в ту сторону ради чего вы это программирование осваиваете, скорее всего это будет создание своих продуктов которые можно показать и потрогать, в создание продукта, в творчество, в креатив.

Иначе будете биться об стену на "не своей" работе и периодически сильно выгорать, как это было со мной и некоторыми моими коллегами.

Либо ищите в работе возможности заниматься любимым делом, тем что вас заряжает больше чем тем что выматывает (ну как на любой работе впрочем :) )

Ключевым моментом на который стоит обратить внимание, тем кому откликается, - это быстрая обратная связь, скорость получения результата, быстрый отклик, динамика.

Рутинное долгокопание без понятного результата угнетает и забирает силы.

Долгокопание в разработке периодически возникает - это неизбежно.

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

Ну и обратите внимание на "что" и "для чего", а не на "как". Т.е. подумайте о том что вы делает и зачем, прежде чем начнете учиться и разбираться как это сделать.

Следуя этим рекомендациям, быть может, вы станете чуточку счастливее занимаясь выбранным делом.

P.S. Для тех кому откликается:

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

И как следствие: у тебя получится делать всё за что ты возьмешься, но это не значит что тебе всё это нужно делать, тем более самому.

Этот комментарий может сэкономить тебе 10-к лет жизни, или нет :)

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

Недавно Google анонсировала, что скоро смартфоны на базе Android будут работать только с приложениями, чьи разработчики подтвердили свою личность непосредственно Google. Но как это будут проверять? Напрашивается проверка по ключам подписи, но погодите-ка…

Если вы более-менее интересуетесь опенсорсом, наверняка вы слышали про “магазин” F-Droid. Что примечательно в нём — все приложения в его главном (единственном по умолчанию) репозитории собираются из исходников и подписываются одной сущностью — F-Droid. Эта особенность делает данный источник приложений уникальным в своём роде — в Google Play или RuStore каждый разработчик собирает и подписывает приложение сам.

Если Google не передумает и действительно введёт блокировку на “анонимных” разработчиков, вполне возможно, что F-Droid просто создаст единый аккаунт для своего ключа подписи, и продолжит спокойно предоставлять приложения даже на “сертифицированных” Android-девайсах.

Но наверняка вы скажете, что там распространяются приложения, неугодные Google, и будете правы. Однако они и так ломаются каждый месяц самой же корпорацией ввиду открытых исходников этих приложений и способов парсинга контента без официального API. Так что, думаю, обойдётся.

Что думаете?

App Clip в деле: сделали расписание транспорта без установки приложения и лишних мегабайт

В 2ГИС мы любим эксперименты с технологиями. Когда Apple представила App Clips — мини-версии iOS-приложений, — мы начали думать, что ж сделать такое полезное, быстрое и удобное. Появилась идея: а что если показать расписание транспорта прямо на остановке, без установки приложения? Идеально для ситуации, когда нужно получить информацию в моменте.

Пилотный проект начали с Екатеринбурга — на остановках в центре города уже появились QR-коды, по которым можно мгновенно получить расписание автобусов, трамваев и троллейбусов.

Реализация: просто, но есть нюансы

У нас была цель — запустить всё быстро и без лишней сложности. Поэтому мы пошли по самому простому пути. Однако не обошлось без сюпризов: мы столкнулись с интересной особенностью сборки и дистрибуции через App Store.

Когда собирается билд, бинарь App Clip попадает в общий application bundle — вместе с ресурсами, ассетами и иконками. Мы переживали, что это увеличит размер основного приложения для пользователей.

Однако на этапе загрузки в App Store Connect происходит app thinning (slicing) — бинарь анализируется и оптимизируется на стороне App Store. Получается, что из финальной сборки, доступной пользователю, App Clip удаляется. В результате конечный IPA, который скачивает пользователь, не увеличивается в размере, несмотря на то, что в исходном проекте ресурсы App Clip действительно включены в общий bundle.

Чтобы убедиться в этом, мы проверили это на практике:

1. Собрали билд, в котором бинарь App Clip действительно оказался в общем application bundle.

2. Загрузили его в App Store Connect.

3. После релиза скачали IPA напрямую из App Store и проанализировали содержимое.

Результат: в финальном бинаре bundle App Clip отсутствует. Пользователи получают приложение без дополнительного груза, а размер основного приложения не растёт. К слову, в официальной документации Apple этот момент описан довольно туманно, так что мы решили проверить всё на себе.

App Clips считаются не самой популярной фичей, но всё же было интересно покопаться, собрать, выкатить и посмотреть, как это работает в реальности.

Если вы пробовали App Clips — расскажите про свой опыт! Может, нашли нестандартные подходы или столкнулись с подводными камнями, о которых стоит знать другим?

Cursor теперь помогает составлять User Rules

В Cursor буквально сегодня увидел новую опцию. А именно: когда с ним работаешь по проекту и по ходу как-то его поправляешь, то внизу слева выскакивает пимпочка и предлагает занести такие вещи в User Rules.

Очень даже удобно. Не надо самому отдельно все записывать, а потом переносить.

Список инструментов low-code/no-code разработки и вайбкодинга для диплома

Всем привет. Я учусь в магистратуре ИТ-юрист и планирую писать диплом с рабочей темой "Правовые основы low-code/no-code разработки и вайбкодинга". Прошу накидать инструментов для анализа )

Основная цель работы простым языком - понять, если я разрабатываю продукт с использованием сервисов low-code/no-code (или ИИ-агентов в случае вайбкодинга), могу ли я его считать полностью своим или нет.

С правовой точки зрения задачи работы понятны - я буду анализировать лицензии, смотреть, как сервисы передают исключительные права пользователям, как обстоит ситуация с персональными данными в случае, если сервис иностранный.

Теперь передо мной стоит задача подготовить список подобных сервисов для дальнейшего анализа. Я сделала небольшую подборку и буду очень благодарна, если вы мне в комментариях подскажете еще подобные популярные платформы, которые позволяют вести разработку при отсутствии навыков программирования/либо минимальных навыках. Есть ли что-то подобное для разработки видеоигр?

• Разработка сайтов: tilda, wix, carrd, Collabza (личные кабинеты), Webflow, Craftum, Flexbe, Creatium, LPgenerator

• Автоматизация бизнес-процессов: битрикс24 (роботы), NBT, BPMSoft, ROBIN (российские решения), zapier, albato, Бипиум, Nodul, APInita

• Разработка приложений: bubble, glide, appmaster, adalo, appsfera, Stacker, QuintaDB, Directual, Bravo Studio, Thunkable, Voiceflow

• Вайб-кодинг: Cursor, Windsurf, Replit, Devin, Claude Code, Cline, GigaStudio (рус)

Обновляем список актуальных вакансий в SSP SOFT

Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):

1️⃣ Разработчика и аналитика 1C
2️⃣ Разработчика Angular
3️⃣ Middle Java Developer
4️⃣ Системного аналитика
5️⃣ Бизнес-аналитика

Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.

🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.

👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.

Пишите с резюме нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

Всегда актуальные вакансии на https://hh.ru/employer/5648224:

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта).

мои способы работы с AI контекстом (субъективное мнение):

1. пользоваться общеизвестными терминами которые точно есть в словарях

2. пользоваться только английским для кода, prd и дизайна

3. сокращать код - как показывает практика файлы больше 500-600 строк агенту труднее прочитать. Тут есть несколько стратегий:

• пользоваться препроцессорами, например можно сильно срезать времени если вместо JSX/TSX/html использовать pug

• пользоваться и писать библиотеки. есть проблема - оформляем в абстрактную библиотеку, пишем доку и readme

• предвидеть контекст - часть текста просто можно не писать, а просить догенерить, потому что получится эффект снежного кома, начинаем катить, смотрим куда катится - сокращаем

4. меняем JSON на YAML или что-то близкое - это срежет кууучу лишнего хлама в виде ; }{ "" и прочих символов

5. генерим code maps - mermaid и другие виды диаграм

6. ANSII - визуализация простых идей, но не все модели хорошо работают с этим форматом, есть проблемы с layout. например я пользуюсь gemini

7. подстраивать архитектуру и код под задачи и бизнес, не наоборот. Developer | Designer | AI as User.

8. разбивать на мелкие подприложения если нужно

Надеюсь, что пост окажется полезным :-)

Пожалуйста делитесь своими мыслями в комментариях :-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией :-) 

Спасибо за ваше время и хорошего дня!

мои способы работы с AI контекстом (субъективное мнение):

1. пользоваться общеизвестными терминами которые точно есть в словарях

2. пользоваться только английским для кода, prd и дизайна

3. сокращать код - как показывает практика файлы больше 500-600 строк агенту труднее прочитать. Тут есть несколько стратегий:

• пользоваться препроцессорами, например можно сильно срезать времени если вместо JSX/TSX/html использовать pug

• пользоваться и писать библиотеки. есть проблема - оформляем в абстрактную библиотеку, пишем доку и readme

• предвидеть контекст - часть текста просто можно не писать, а просить догенерить, потому что получится эффект снежного кома, начинаем катить, смотрим куда катится - сокращаем

4. меняем JSON на YAML или что-то близкое - это срежет кууучу лишнего хлама в виде ; }{ "" и прочих символов

5. генерим code maps - mermaid и другие виды диаграм

6. ANSII - визуализация простых идей, но не модели хорошо работают с этим форматом, есть проблемы с layout

7. подстраивать архитектуру и код под задачи и бизнес, не наоборот. Developer | Designer | AI as User.

8. разбивать на мелкие подприложения если нужно

Надеюсь, что пост окажется полезным :-)

Пожалуйста делитесь своими мыслями в комментариях :-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией :-) 

Спасибо за ваше время и хорошего дня!